AERGO is a new blockchain protocol which launched its testnet in Dec 2018, together with a toolset and, in our opinion, an impressive developer on boarding content repository. Already from this it was clear to us that AERGO was made to actually be used by putting considerable effort into making the nodes and toolset very accessible to the developer community.
AERGO aims to cater for both public and private blockchain deployments. Originating from Blocko Inc’s experience in providing large-scale, production level private blockchain to enterprise customers, AERGO intends to enable enterprise architectures based on blockchain by combining both new and established technical approaches to build scalable distributed database systems.
Blocko has supplied more than 20 enterprise customers with its private blockchain implementation “Coinstack.” Coinstack is based on a modified Bitcoin architecture and Ethereum VM. While Coinstack performed reasonably well for larger-scale use-cases such as powering the authentication process for the multi million customer-base of a credit card provider, it also provided insights into the Bitcoin protocol’s upper limit of performance for such a use case and the Ethereum VM’s incompatibility with the enterprise architecture as well as the limited enterprise adoption of the Solidity language.
Based on the above experience Blocko started working on AERGOSQL and AERGO. AERGOSQL is a new smart contract engine capable of utilizing a relational data model and developing smart contracts using tools and languages familiar (such as SQL) to enterprise developers.
AERGO’s platform aims to enable enterprises and developers to easily design, build and deploy their own blockchain applications on a cloud platform. The product aims to offer the possibility for creators to customize their blockchain and applications to their specific needs, by giving them the choice to run across either a public or private network.
Taking into account the differing characteristics private and public blockchain implementations present, the choice between the two aims to give enterprises and developers the flexibility they desire when designing a purpose-specific application.
Hosting everything across a cloud-hosted distributed network, AERGO eliminates the need from significant overheads through the elimination of needing to establish physical infrastructure themselves to run blockchain protocols and applications.
AERGO believes that enterprise blockchains operate under different requirements than public, generic blockchains. With the deployment of Coinstack, Blocko gained first-hand exposure to the reality of enterprise blockchain adoptions, which they describe below:
• “Unlike public blockchain users, who usually operate blockchain nodes on commodity hardware, businesses tend to run blockchain on server grade hardware with vast computing power and storage”
• “Businesses want to run blockchain not only on
• “While public blockchain users run blockchain nodes at small number, businesses want to run a large number of blockchain nodes in order to take advantage of horizontal scalability and availability”
• “Businesses need more control and functionalities related to the administration of blockchain than public blockchain users” • “While most of applications
running on public blockchain are self-contained or dependent only on assets on
the blockchain itself, businesses want to connect applications running on
blockchain with many external and internal systems such as e-mail, SMS,
databases, LDAP, and public data”
AERGO’s experience matches ours from working with enterprise blockchain clients, especially in that it is necessary for enterprises to fully control infrastructure and data privacy/security of their networks. Public blockchains are not a realistic option other than for immutable zero-knowledge anchoring of ledger data. Business information needs to remain confidential and performance needs to be controlled by the enterprise entity itself.
The proposed core consensus algorithm of AERGO is Delegated Proof of Stake (DPOS). DPOS is AERGO’s preferred consensus model motivated by the following statement:
“We believe it provides the scalability and the simplicity of operation required by a core consensus; and DPOS operates under the assumption that block reorganizations can happen, which means it is an optimal algorithm for powering the underlying infrastructure of AERGO.”
In DPoS, blocks are generated only by a limited number of nodes called Block Producers (BPs). BPs are elected via voting, where the voting power is weighted by staked tokens. Blocks becomes final and irreversible when 2/3 of the BPs have voted for it, and can not be rolled back.
Since AERGO intends to provide a pluggable architecture for consensus algorithm as well, different consensus algorithm modules can be used in place of the core consensus. Notably, RAFT (for development) and PBFT (for strict-ordering) are useful for developing and running different services.
AERGO supports the creation of public and private repositories. Much like a public Github repository, a public AERGO repository is intended to be transparent to read and write, or selectively allow different permissions to anonymous users. A common configuration is to create a public AERGO repository with read-only anonymous access.
A private repository is intended to be an AERGO repository with full access control enabled, both for reading and writing the repository. A public or private repository is effectively a private blockchain in a sense that it operates independently from the AERGO public network.
AERGO intends only to allow users with adequate permission to access ledger data by providing git-like private repositories.
By creating a new branch from a remote parent branch, users are able to keep newly created blocks in a private branch, such that they are isolated from the public. Only those with sufficient permission to the specific repository housing the branch are able to access the blocks.
A specific branch can be synced with remote repositories to exchange data. In this case, the private branches of the repository can either select relevant commits from the public repository or merge the whole change set automatically.
The Merkle Bridge is an interoperability mechanism for bridging between sidechains (aka repositories) on AERGO in supposedly a efficient, effective and more decentralized way. It lets enterprises do things such as exchange assets (i.e., data) with one another using the AERGO public chain for settlement. The Merkle Bridge also allows interoperability between AERGO and Ethereum.
AERGO supports a multi-paradigm, plugin-based smart contract infrastructure.
Each contract can be executed or queried by a client-actor or another smart contract instance. Since AERGO provides a permissive interface with interoperability between smart contract implementations, contracts written for Ethereum VM, Fabric Chaincode, or AERGOSQL can be used together.
AERGOSQL provides a relational data model for storing and accessing data and SQL-like scripting language for writing smart contracts.
Using AERGOSQL, smart contracts can be written using the SQL syntax familiar to most enterprise developers.
With its pluggable architecture, AERGO is designed to support different smart contract implementations. AERGO inherits the Ethereum VM compatibility from Blocko Coinstack. Fabric Chaincode is supported through lightweight virtualization such as Docker.
AERGO supports integrating smart contracts contained inside the blockchain, as well as smart contracts that have relation to external events and factors through implementing smart oracles. The following sections of this article will cover the purely technical aspects of the AERGO product, non-technical readers are invited to skip to the ending section with conclusions.
Source Code: Github aergoio/aergo
Code structure & architecture:
Code formatting and comments:
Maintainability:
The code follows the object oriented analysis and design principles. Overall, folders and files are well named. Files are short (usually less than 300 lines) and focused. Development is straight forward and overall the code quality is high.
The code follows the configurability approach and keeps the configurable values separately so that no code changes are required if the values are changed frequently.
It is easy to add extensions with minimal changes to the existing code and the code is modular so that components can be easily replaced.
All used data types are well suited to their need from a performance perspective – such as StringBuilder, generic collection classes.
As blockchain projects always require a high level of security we are pleased to see that AERGO uses best practice methods for authentication, authorization and input data validation against security threats.
The source code is well organized in Folders with a practical naming and explanation.
A closer look at selected files:
https://github.com/aergoio/aergo/blob/develop/consensus/consensus.go
The code follows the typical Open Closed Principle and SRS (Single Responsibility Principle). Functions and classes are well built and dependencies are linked as packages.
The node source is based on TOML. Looking at these files we find similar cleanness as in the Go language source files: https://github.com/aergoio/aergo/blob/develop/node/local.toml
The github account and overall setup is clean and offers all major information. Nothing is missing or further to be desired.
Source Code screening:
The initial check of the repo shows that it follows best practice in the majority of the areas known to otherwise generate negative comments from public reviewers, such as the amount of commits, copyright information etc. Everything we see is in good shape and accessible.
The source code documentation is average, more comments would be useful especially for the purpose of onboarding new core developers. The quality of the developer onboarding website supports external developers very well.
The second part of the repo check is to install the system. For this we use for this we use two different virtual machines (OS-X and Linux) to assess different installation methods.
Docker on both platform fails (likely due to lacking dependencies). The result from the installation log:
We decide not to spend more time on the docker, as it is not mentioned in the readme.md or elsewhere in the repo. Instead we build the system from source code by following the instructions in the readme.md.
We build on OS-X 10.13.6 ( i7 2.8, 16GB RAM) and Linux (Ubuntu 17.10)
The preparation on OS-X with Homebrew runs smoothly. The onboarding developer documentation describes it well step by step.
The installation of aergo works without issues:
go get -d github.com/aergoio/aergo
cd `go env GOPATH`/src/github.com/aergoio/aergo
git submodule init
git submodule update
make
cd build && cmake -G “Unix Makefiles” -D CMAKE_BUILD_TYPE=”Release” ..
Cloning into ‘/Users/aergo/go/src/github.com/aergoio/aergo/libtool/src/lmdb’…
— Configuring done
— Generating done
— Build files have been written to: /Users/aergo/go/src/github.com/aergoio/aergo/build
. . .
[100%] Built target vendor
Scanning dependencies of target aergoluac
[100%] Built target aergoluac
Scanning dependencies of target aergocli
[100%] Built target aergocli
Scanning dependencies of target brick
[100%] Built target brick
Scanning dependencies of target aergosvr
[100%] Built target aergosvr
Scanning dependencies of target build
[100%] Built target build
The system is now built; we proceed to export the environment:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${GOPATH}/src/github.com/aergoio/aergo/libtool/lib
and start the server:
./bin/aergosvr
{“level”:”info”,”module”:”asvr”,”revision”:”2f418962″,”branch”:”develop”,”time”:”2019-03-30T17:52:40+07:00″,”message”:”AERGO SVR STARTED”}
{“level”:”info”,”module”:”asvr”,”time”:”2019-03-30T17:52:40+07:00″,”message”:”No private key file is configured, so use auto-generated pk file instead.”}
{“level”:”info”,”module”:”asvr”,”pk_file”:”/Users/aergo/.aergo/auth/aergo-peer.key”,”time”:”2019-03-30T17:52:40+07:00″,”message”:”Generate new private key file.”}
{“level”:”info”,”module”:”chain”,”time”:”2019-03-30T17:52:40+07:00″,”message”:”started signverifier”}
{“level”:”info”,”module”:”chain”,”time”:”2019-03-30T17:52:40+07:00″,”message”:”generating genesis block..”}
{“level”:”fatal”,”module”:”chain”,”error”:”mainnet will be launched soon”,”time”:”2019-03-30T17:52:40+07:00″,”message”:”failed to create a genesis block”}
Overall everything works well and as expected. We would however recommend to remove the docker (as we suspect it is outdated), and replace it with an Amazon Machine Image in order to simplify deployment.
Source Code screening
We initiate the docker:
docker run -p 7845:7845 aergo/node
Unable to find image ‘aergo/node:latest’ locally
latest: Pulling from aergo/node
c87736221ed0: Pull complete
08ec688bad14: Pull complete
d6b8619fc89f: Pull complete
9db81ca05d61: Pull complete
5936494ba3b9: Pull complete
12689c6557d2: Pull complete
4808d541b838: Pull complete
f25b5d7a87f3: Pull complete
85750a9614e4: Pull complete
Digest: sha256:aaf07ac137f1cdc13359d9aec4f7d1a80e4396b19c555efcaebe348543c1b395
Status: Downloaded newer image for aergo/node:latest
Mar 31 04:08:05 INF go/src/github.com/aergoio/aergo/vendor/github.com/spf13/cobra/command.go:766 > AERGO SVR STARTED branch=HEAD module=asvr revision=2df182d6
Mar 31 04:08:05 INF go/src/github.com/aergoio/aergo/cmd/aergosvr/aergosvr.go:152 > No private key file is configured, so use auto-generated pk file instead. module=asvr
Mar 31 04:08:05 INF go/src/github.com/aergoio/aergo/cmd/aergosvr/aergosvr.go:152 > Generate new private key file. module=asvr pk_file=/auth/aergo-peer.key
Mar 31 04:08:05 INF go/src/github.com/aergoio/aergo/chain/chainservice.go:235 > generating genesis block.. module=chain
Mar 31 04:08:05 INF go/src/github.com/aergoio/aergo/chain/chainservice.go:235 > chain initialized chain
… (truncated)
The docker works as expected and the server starts without any issue.
We proceed to by deploying an own testnet configuration:
docker run -v $(pwd)/data:/aergo/data -v /Users/ aergo /documents/aergo-develop/node/testnet.toml:/aergo/testnet.toml -p 7846:7846 aergo/node
Mar 31 07:39:18 INF go/src/github.com/aergoio/aergo/vendor/github.com/spf13/cobra/command.go:766 > AERGO SVR STARTED branch=HEAD module=asvr revision=2df182d6
Mar 31 07:39:18 INF go/src/github.com/aergoio/aergo/cmd/aergosvr/aergosvr.go:152 > No private key file is configured, so use auto-generated pk file instead. module=asvr
Mar 31 07:39:18 INF go/src/github.com/aergoio/aergo/cmd/aergosvr/aergosvr.go:152 > Generate new private key file. module=asvr pk_file=/auth/aergo-peer.key
Mar 31 07:39:18 INF go/src/github.com/aergoio/aergo/chain/chainservice.go:235 > generating genesis block.. module=chain
Mar 31 07:39:18 INF go/src/github.com/aergoio/aergo/chain/chainservice.go:235 > chain initialized chain id=“{\”public\”:true,\”mainnet\”:false,\”coinbasefee\”:\”1000000000\”,\”magic\”:\”testnet.aergo.io\”,\”consensus\”:\”dpos\”}” hash=9xHe95QhrGyUgx2ub66TmWCRgNN1LvzjrCLrFkVf5anV module=chain
Running a private local network in testmode
docker run –rm -p 7845:7845 aergo/node aergosvr –config /aergo/testmode.toml
Mar 31 08:33:54 INF go/src/github.com/aergoio/aergo/vendor/github.com/spf13/cobra/command.go:766 > AERGO SVR STARTED branch=HEAD module=asvr revision=2df182d6
Mar 31 08:33:54 WRN go/src/github.com/aergoio/aergo/vendor/github.com/spf13/cobra/command.go:766 > Running with unsafe test mode. Turn off test mode for production use! module=asvr
Mar 31 08:33:54 INF go/src/github.com/aergoio/aergo/cmd/aergosvr/aergosvr.go:152 > No private key file is configured, so use auto-generated pk file instead. module=asvr
Mar 31 08:33:54 INF go/src/github.com/aergoio/aergo/cmd/aergosvr/aergosvr.go:152 > Generate new private key file. module=asvr pk_file=/auth/aergo-peer.key
Mar 31 08:33:54 INF go/src/github.com/aergoio/aergo/chain/chainservice.go:214 > Coinbase Account is nil, so BP reward will be discarded module=chain
Mar 31 08:33:54 INF go/src/github.com/aergoio/aergo/chain/chainservice.go:235 > generating genesis block.. module=chain
Mar 31 08:33:54 INF go/src/github.com/aergoio/aergo/chain/chainservice.go:235 > chain initialized chain
… (truncated)
Everything works very well. We perform a stability test for more than 4 hours without any issues.
We proceed to connect our private network to the AERGO testnet.
docker run –rm aergo/tools aergocli -H testnet.aergo.io blockchain
{“Hash”:”2AfgMNYkuyjCcSyN6fPmKJ7ajantQ3yvhyqa8JsYi1Kj”,”Height”:171927}
Create a wallet:
docker run –rm -v $(pwd):/wallet aergo/tools aergocli account new –password your_password –path /wallet
AmNmMUdbATfbB6Zh2SxPLgNnKQ3TX4EiDzSSQdT12hqvyA3YdWtq
Aergoscan check:
We fund our wallet through faucet:
We check once again on Aergoscan if it has arrived:
Source Code screening
Smart Contract Compiling
After installing LuaJIT we create a file called helloworld.lua
— Define global variables.
state.var {
Name = state.value(),
My_map = state.map()
}
— Initialize a name in this contract.
function constructor()
— a constructor is called at a deployment, only one times
— set initial name
Name:set(“world”)
My_map[“key”] = “value”
end
— Update a name.
— @call
— @param name string: new name.
function set_name(name)
Name:set(name)
end
— Say hello.
— @query
— @return string: ‘hello ‘ + name
function hello()
return “hello “ .. Name:get()
end
— register functions to expose
abi.register(set_name, hello)
and compile it with:
./aergoluac –payload helloworld.lua
This works well and the compiled code is returned.
We subsequently deploy the contract on the network:
./aergocli contract deploy AmNmMUdbATfbB6Zh2SxPLgNnKQ3TX4EiDzSSQdT12hqvyA3YdWtq –payload L99FUNvFuwQ13WwkmBGRLqqJE2FzWaiotV4Jf35DeLaYESkPCf92qR813r19oWQWQQ7nGkJLswp7PnK9Psftm9QQrZmhyuZRQfmStDqWD5XhG7tKfDntoQuBZcRQYXTwiGQFk9a4QqB9ytWJQ2gfW5a9T6GfNeYov9nGuzrEmCUzHvBzLdGuoRYyrB66tupq8uGXvWf1ZysnUxD95L1tcn8nK6a2qB6Fcq2LJqMfwtPkRgyqTnpyVsLZsPjCgEza5Bfh9RR2yuWkyag7ZUD43oGJ8B6PeKDE3sq1aoiJxyCqffyBoo3YCm7RBp2EAsT3r4jK6RacE5gBAiq1PBvejbjFt4uRgjQ7YrKjkrZYW3MxD6GEw96jCR5LiirWou9fZtw5Xste9uwGMDyLyj2brEonUsHyCTutMdsGyfCXk6GP8TbsGpe2QBD2XLs3Tc69xMh3EPEQXaeALhs4AqjuHuUm155M6iN9GdZ9h9AQVhUBBVvikAUaKqr7M1htsKwMrbzUqpfJaQKXzxjXZxb6UNiwQVMhKu7pfBAtxp7cnXThhEEFwz784PcZ2Cspy41KevWCEF33s12NeZqAH3QnwA4aEhzNMbRSWSfVsoFnTrKgnLibS4zSzxZRCCLC1kY4DkPYFNfjSMZJ3mtpuhURLEnr3pSHECety72bKhNoXLh9tzrmhYjRbVrVkAG7BYHx5W4fqXgXajYtY22BkNmN5ForVi1GewmnrQc5dBic9R7ezaUSMcusaeaNACfqvg7ZzERXRH7GzLFjqSdTzZnmbnirifTiceYvMkYcQkt6NVGaD68U7D38AVQZAX6NpF6dyuwRzdLcqKHsnF433FxMt3Nvj5Wt9B82t8yZ3sremPgJjGk6iS5vYcSynPoLaDKYWWn4iamrXaL
We have included a short review section for the website as it is an important part of developer onboarding/adoption and is a first indicator of the project’s technical capability/professionalism.
The website is well developed with modern tools and supports mobile devices with responsive design.
SEO (Search Engine Optimization) is on an average level. Some pictures are missing the alt tag, and robots.txt/sitemap to support search engines with indexing are missing. On the other hand we see clean canonical entries and content substrates for search engines. There is room for the SEO to improve in order to increase visibility.
The copyright information on the homepage shows 2018, this should be changed to 2019.
All major communication channels are supported/linked.
We would like to point out the very clear legal information on the website, this is very rare for projects in this space.
It is clear to us after reviewing the AERGO project that it has reached a reasonably mature stage already with the current testnet implementation. Some minor flaws (such as the outdated docker) are likely to be corrected with the soon upcoming mainnet launch. Overall the team has done some very solid work to implement the specs.
We are especially impressed by the amount of work the AERGO team has put into making their product accessible to the developer community at this stage. Hats off to the team for this accomplishment.
Very few projects can compete with this level of content aimed to make the developer and installation process smooth. To us, it is a clear indication of that AERGO is serious about their product actually being adopted (which it will by default since Blocko customers intend to use it). This type of ‘last mile’ developer support is something that has long been advocated by InCodeWeTrust, but is sadly missing in the majority of blockchain related projects.
Apart from the excellent developer documentation, the toolset provided by AERGO is equally impressive, ranging from command line tools to comprehensive solutions for enterprise blockchain deployment and management. The lovely Aergoscan blockchain explorer is just the icing on the cake.
With this level of commitment to provide solutions catering for enterprises, we are excited to see what the mainnet release will include and watch the technical and commercial progress of AERGO very closely. AERGO is not a solution waiting for a problem, it is a solution to the problem.
Algorand
Aergo
V-Systems
Sparkster
Ferrum Network
Kardiachain
MagnaChain
CommerceBlock
Uranus.io
nCent Labs
Nervos
Fantom
Solana