Preview of Asch Verision1.3 (part 2)
ShanQingfeng
sqf71105403@gmail.com
In former part of this article, I introduced some features and advantages of the Asch cross-chain structure to show the potential of this system from a macro perspective. In this part, I will introduce the practical advantages of developing applications with Asch system for the developers.
First, every application on the Asch is based on an independent application chain. The coupling mechanism between the application chain and the main chain is not so tight, and the application chains are also independent of each other. Therefore, it can bring us with these following benefits:
1. Errors and defects within the applications will not be spread and have any effects on the main chain or other applications. The event similar to the DAO will not happen.
2. The applications are in parallel with each other, so they will not occupy the limited and valuable bandwidth, storage and computing resources of the public chain.
3. The transaction fee can be specified by every application. An application can even choose to support several currencies as fuel costs. There is no need for the developers and users to worry about the cost.
Secondly, the reason that Asch’s application is easy to upgrade is that it does not use chain code. We can not promise that the system is perfect at the first time, especially complicated system. Currently, the chain code mechanism used by many platforms is clearly not suitable for developing large and complex service logic. So every software needs upgrading. Once contract code as chain code is submitted to the chain,it can not be modified. chain code also can be used in some simpler logic financial contracts. ETH’s chain code is difficult to upgrade, so that it can not achieve complicated service logic. Considering this,it is a paradox for ETH to propose the Turing Completeness language.
Third, Asch closed the framework way rather than a high level language in development pattern. We hope the developers can take advantage of current software systems, components and libraries rather than a immature high level language. All the people who have experiences in developing large, high performance server side programs know that the difficulty of developing these programs are not in the developing language, but in the architecture. The first thing when a server side programmer get the demand is not how to realize the algorithm or designing the class or function, he should probably need to do database selection and design the database model. I will give an practical example which we can see the difference in design principles of development model between Ethereum and Asch.
Vitalik has introduced the pseudo code of a dns service in this ppt:
data domains[](owner, ip)
def register(addr):
if not self.domains[addr].owner:
self.domains[addr].owner = msg.sender
def set_ip(addr, ip):
if self.domains[addr].owner == msg.sender:
self.domains[addr].ip = ipv
It seems really cool that a simple code could achieve a domain name service. But a person who even has a little bit experience of development will doubt it in the next few seconds. For example, does that domain keep in the memory? If the program closes, will the data be lost? If the domain keeps in the disk, which means that language is couple to database components and is likely to be a k-v database, how can I expand other fields if that is a k-v database? How to retrieval data according to different fields? What is the capacity of this database? Also, if every variable is mapped to disk, how to declare and define it if I want to store data in the memory?
Let us see how to achieve a similar application in Asch platform.
First, we need to define a data model.
// model/domain.js
module.exports = {
name: 'domains',
fields: [
{
name: 'address',
type: 'String',
not_null: true,
index: true
},
{
name: 'ip',
type: 'String',
},
{
name: 'owner',
type: 'String',
not_null: true,
},
{
name: 'suffix',
type: 'String',
not_null: true,
index: true
}
]
}
(PS: we add a “suffix” field to query all the domain names ending with a suffix.)
After that, we need to achieve core business logic.
// contract/domain.js
module.exports = {
register: (address) => {
app.sdb.create('Domain', {
address: address,
owner: this.trs.senderId,
suffix: this.address.split('.').pop()
})
},
set_ip: (address, ip) => {
app.sdb.update('Domain', {ip: ip}, {address: address})
}
}
The third step, we add some access to this service interface.
// interface/domain.js
app.route.get('/domain/:address', async function (req) {
return await app.model.Domain.findOne({address: req.params.address})
})
app.route.get('/domain/suffix/:suffix', async function (req) {
return await app.model.Domain.findAll({suffix: req.params.suffix})
})
We can see that these codes involve a lot of things besides the level of programing language. For example, the schema of model is likely to describe a relation data table. App.route.get is to create a api handler. App.model.Domain is a model interface of ORM. These are all the traditional ways which are familiar to web programmers, aren’t they? And the codes are also simple enough, flexible enough and very extensible.