On the Origin of æternity

Published in

On The Origin of Smart Contract Platforms

14 min readJul 13, 2018

This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at æternity and the ways it could supplant today’s dominant platform, Ethereum.

æternity is a decentralized, trustless smart contracts platform that is designed to provide better scalability, governance, smart contract security, privacy, and access to real world data than Ethereum. The project shares many similarities with Ethereum, including a Proof of Work (PoW) blockchain and support for Solidity contracts running on an EVM-compatible virtual machine. In contrast to Ethereum, which is featureless by design, æternity has opted to include certain features in the platform as “first class objects” to simplify the development of decentralized applications (dApps, or æpps in æternity lingo).

The æternity platform is written in Erlang, a concurrent, functional language that is designed for 0% downtime. Erlang provides built-in support for hot code loading, which allows new features and bug fixes to be deployed while the system is running. The æternity core development team consists of several Erlang developers, many of whom came to the project by way of a partnership with the Erlang Solutions consultancy.

The æternity project was founded in Liechtenstein in late 2016 by Yanislav Malahov. Malahov had been working to build more generalized functionality on top of Bitcoin for many years, having, in 2013, collaborated with a teenage Vitalik Buterin on the colored coins-based Keidom project, now known as ascribe.io. In January 2017 Malahov and coauthors Zack Hess and Jack Petterson published the original æternity white paper, which describes some of the early goals and ideas for the project (though much has since changed).

From April to June 2017 æternity ran a successful token sale raising 224,750 ETH and 1456 BTC (worth roughly 50 million USD at the time of completion). Just weeks later æternity had the misfortune of being one of three wallets drained by an attacker exploiting a vulnerability in the Parity Multisig wallet. As a result, æternity lost 82000 ETH, nearly 40% of the total raised.

In the second half of 2017, two coauthors of the original white paper, lead developer Hess and smart contract language guru Petterson, left the æternity project. A second white paper titled “æternity Reimagined” was started by then CTO Joel Reymont, but was soon abandoned when Reymont also left the project in November 2017. Despite these setbacks, æternity managed to launch its Epoch testnet in Dec 2017 and has continuously been updating the testnet with new features since. A full-featured mainnet launch is currently scheduled for August 2018.

In May 2018 æternity announced the launch of æternity Starfleet, a project incubator providing resources and support to blockchain projects that will likely be building applications on the æternity platform. Shortly thereafter æternity released a two part list of 17 projects selected for participation in the first wave of Starfleet incubation. Many of these projects are based in Sofia Bulgaria, where Starfleet’s cooperating partners æternity Ventures and Software University are based.

Although the project does not yet have a running mainnet or an up-to-date white paper, many of æternity’s ideas are in the process of being fleshed out on their Epoch testnet. There is enough documentation about these ideas to compare æternity’s design to that of Ethereum and assess the threat æternity poses to Ethereum’s dominance. Let’s see how they match up.

Scalability

Scalability is a well-known problem with Ethereum, and nearly every platform we’ve looked at in this series is looking to scale transaction throughput at the blockchain layer with some type of Proof of Stake (PoS) based consensus algorithm. In contrast, æternity implements a Proof of Work (PoW) based consensus protocol and is primarily focused on scaling with layer 2 solutions.

æternity’s PoW is based on the Cuckoo Cycle algorithm, a memory bound puzzle, which is believed to be ASIC-resistant. This means that the algorithm is designed with a memory bottleneck so that running it on an Application Specific Integrated Circuit (ASIC) does not provide a significant efficiency gain over a CPU or GPU, so that anyone with general purpose hardware, such as a mobile phone, can participate in the consensus process.

The æternity vision of users mining on their mobile phones was set back when cryptocurrency mining on iPhones was banned by Apple. Nonetheless, æternity’s PoW algorithm might be closer to realizing Satoshi’s egalitarian vision of “one-CPU-one-vote” than Ethereum’s. The EthHash algorithm used in Ethereum was also believed to be ASIC-resistant, but Bitmain has recently announced an Ethash ASIC miner, which will begin shipping in late July. The impact these miners will have is uncertain, but they will not (as some have claimed) be rendered obsolete by the upcoming deployment of Casper the Friendly Finality Gadget or reduction of the block reward.

Ethereum improves base layer scalability by having a relatively high block frequency (about 240 blocks/hour vs 12 in æternity). More blocks per hour equates to more transactions per second, but also more temporary forks and stale blocks. Stale blocks are valid blocks which, due to another valid block being found at the same time, do not end up in the main chain and thus do not contribute to network security and provide no reward for their miners. When such races occur block rewards more often go to better-connected miners, which, over time, economically weeds out less equipped miners and increases miner centralization. To prevent this Ethereum implements a variant of the Greedy Heaviest Observed Subtree (GHOST) rule, which rewards miners of stale blocks.

Although æternity’s Reimagined white paper describes using GHOST to improve transaction throughput, this no longer appears to be on the project’s development roadmap. Instead, æternity is employing Bitcoin-NG to scale the base layer. Bitcoin-NG obviates the need for GHOST because, even though the average time between blocks remains relatively long, Bitcoin-NG allows additional transactions to be processed during this time. The miner who finds a solution to the Cuckoo Cycle puzzle earns the right to produce a key block with their solution and then can continue producing microblocks with additional transactions until the next miner solves the puzzle and earns the right to do the same. The protocol includes a fee sharing mechanism to incentivize miners to build on the longest chain of microblocks rather than serialize existing microblock transactions into their own microblocks.

Since æternity will be deploying the world’s first Bitcoin-NG on PoW implementation, one can only speculate on the performance gains it will bring. However, based on measurements of the Waves-NG (Bitcoin-NG on PoS) implementation, we can estimate that æternity with Bitcoin-NG will have about an order of magnitude more base layer capacity than Ethereum’s non-sharded PoW implementation. However, once its first phase sharding implementation is deployed, Ethereum’s base layer capacity should increase by at least two orders of magnitude.

Layer 2 solutions are a key component of both projects’ scaling roadmaps. State channels, which scale throughput by executing most transactions off chain, are one of æternity’s built-in first class objects. State channels are a generalized form of payment channels (e.g. Lightning Network), that allow off-chain transfer of not just payments but arbitrary application state (e.g. wagers and cards in a poker game, moves and state of a chess board, etc.). For parties that interact repeatedly (e.g. playing several games of poker) state channels provide a huge boost to transaction throughput because nearly all interactions occur in off-chain transactions. There are additional benefits to participants in that off-chain transactions are nearly instant, free of gas costs, and private to the parties involved.

To use a state channel, interacting parties must initially deposit funds in a smart contract on the main chain, after which they can update state (including balances) through a series of off-chain signed transactions, and finally close out the channel by posting the last transaction with the final balances to the smart contract. The smart contract dispenses the funds to participants after some time period in which challenges may be made. Recent transactions invalidate previous ones, so if one party tries to close out with an earlier state, the other party can simply post the final state to ensure the correct payouts. Since there is a limited time for users to do this, each party must watch the blockchain for any fraudulent closing transactions.

Whereas state channels will be built-in to the æternity platform, they are not included with Ethereum. However, the Ethereum Foundation is funding L4’s research on state channels, which has produced an excellent white paper on the subject, and several third party implementations of state channels are currently being developed. State channel development exemplifies the difference between Ethereum’s featureless platform philosophy and æternity’s thesis that providing built-in features simplifies development, allowing developers to focus on their application. Whereas the early developers of state channel applications on Ethereum may have borne some hardship by having to roll their own implementations, it’s likely that open source versions of state channels will ultimately give Ethereum dApp developers as much leverage as æternity æpp developers will have. An open source defacto standard implementation on Ethereum could emerge before æternity’s mainnet goes live with built-in state channels that support the same use cases.

State channels are not the ideal solution for scaling every type of dApp. They work best when a small number of participants repeatedly transact with each other. Altcoin.io investigated using state channels to build a high speed digital currency exchange, but found Plasma, a layer 2 scaling solution based on “baby” chains, to be more suitable for maintaining state among a large number of interacting participants. Whereas built-in state channels will provide a scalability boost from day one, æternity will likely need to incorporate other solutions to cover use cases less suitable for state channels.

Governance

Lead developer Sascha Hanse once described æternity as “a platform enabling decentralised and trustless applications, with a strong focus on governance.” Indeed, on-chain governance is another feature baked in to the æternity platform. æternity proposes to use on-chain, stake based voting to decide on protocol improvements, which can range from simple parameter changes (block size, frequency, rewards, etc.) to new feature implementations. The built-in mechanism will allow users to make proposals for software upgrades and vote on them using their stake (balance of AE tokens). Votes are weighted by the amount of stake, and users may delegate their voting stake to (presumably) more knowledgeable voters to vote on their behalf.

Like many other platforms we’ve looked at, æternity’s design is based on the belief that the less formal governance processes employed by Bitcoin and Ethereum would be improved by a more formal, on-chain governance mechanism. Indeed Bitcoin’s notorious block size debate and Ethereum’s DAO fork controversy both resulted in community splits and forked chains with thriving new currencies. Whereas the specific governance issues that fractured these communities were different, the solutions are essentially the same: getting users to agree to run compatible software that doesn’t create a fork, even when doing so is not their preference. Although æternity’s marketing team may have created some confusion by describing their platform as implementing hybrid PoW/PoS consensus, this illustrates their view that governance is essentially a separate but related consensus layer. In æternity PoW consensus is used to get nodes to agree on the order of transactions and PoS consensus (i.e. stake based voting) is used to get community participants to agree on the PoW consensus rules.

The general viability of on-chain governance is the subject of much debate. A core belief underpinning on-chain governance is that users will be more likely to go along with a decision they oppose if they believe that it was decided by a legitimate and ostensibly fair process in which all parties in the ecosystem have a say. There is empirical evidence from the real world that democratic governance systems tend to have relatively low fork rates even in the face of strong idealogical differences. However, forking a nation tends to be vastly more difficult and and expensive than forking blockchains. Still, there is a common belief among many smart contract platform designers that some formalized process will be better than none at keeping a community together and preserving the integrity of the platform’s base currency. After all, smart contract platforms do seem ideal for enabling transparent and tamper-proof electronic voting, and software upgrades are easily automated. But smart contracts also provide mechanisms that make it easier for cartels to coordinate to buy elections and automated deployments effectively neuter the voting power of node operators, who are, according to Vlad Zamfir, an “absolutely necessary” pillar of blockchain governance. Arguments against on-chain governance from Ethereum’s thought leaders have led the Ethereum community toward a more multi-faceted and less automated approach to the problem.

At present, Ethereum’s approach seems to be evolving and working relatively well. In the wake of the Parity multisig library self-destruct exploit that froze over 500,000 ETH, and the community’s rejection of various proposals to unfreeze the funds, Parity restated their commitment to keeping the community together. Whereas affected users were not made whole, damage to the greater community was minimized. Contrast this to the notoriety EOS received for the events that occurred in the first week of the platform’s existence, when the EOS Core Arbitration Forum issued multiple “Emergency Measure of Protection Orders” to freeze several presumed malicious accounts without justification. These and other problems faced by early deployments, such as cartel control of the Lisk platform indicate that significant innovation will be needed to develop a viable on-chain governance solution. Until a viable solution is deployed, one could say Ethereum’s is the worst form of government, except for all the others.

Smart Contract Security

The root cause of Ethereum’s community split and its more recent controversy over unfreezing funds is the same: exploit of Solidity code resulting in loss of funds. It seems there would be less contentious debate about how to recover funds if Ethereum smart contracts were not so easily and often exploited.

Progress on this front continues to be slow and steady in the Ethereum community. Based on lessons learned from Solidity contracts, a new smart contract language called Vyper has been developed. Vyper is a strongly typed, non-Turing complete language designed with security and auditability in mind. It does not contain many of the language constructs (e.g. function modifiers, inheritance, inline assembly, etc.) that can be misleading to developers and auditors and thus eliminates entire classes of vulnerabilities. A beta version of Vyper was recently released and it is being used in the development of a new decentralized exchange for ERC20 tokens.

The æternity project plans to support three different smart contract environments that each serve a different purpose.

The first environment is Solidity running on an EVM-compatible virtual machine called the Æternity Ethereum Virtual Machine (AEVM). This environment allows existing Solidity smart contracts to run on æternity unmodified, making it easy for contract authors to migrate to æternity with minimal friction and preserving their investment in Solidity code and expertise. The AEVM improves on the EVM by adding a safe self-destruct mechanism that prevents destruction of libaries actively in use, a feature which would have prevented the libary self-destruct vulnerability that allowed over 500,000 ETH in 587 instances of Parity’s multisig wallet to be frozen. Whereas this feature addresses one specific, well-known security issue, Solidity has so many more that this environment should be considered as insecure as Solidity running on Ethereum’s EVM.

For contracts requiring greater security, æternity has developed a second environment that uses the Sophia programming language and Functional Typed Warded Virtual Machine (FTWVM). Sophia is a strongly typed functional programming language (a dialect of ML) that has restricted mutable state. These properties make it easier to automatically prove properties of the contract code and, like Vyper, are intended to make it maximally difficult to write misleading code. Sophia also includes a rich set of blockchain specific primitives and types, as well as standard mechanisms to interface to oracles, which are another built-in feature of the platform. The FTWVM is also designed for improved security by supporting functional languages, strong typing, and being warded (i.e. preventing overflow/underflow of arithmetic operations). It will be interesting to see how this environment compares to Vyper running on the EVM in terms of safety and programmability. Of course, by providing an EVM-compatible environment, æternity can immediately adopt Vyper (and later port it to FTWVM) if it turns out to be safer or more popular with developers.

The third smart contracts environment is aimed at eliminating the issues around decidability of contract code that introduce complexity such as gas metering. This environment consists of a restricted non-Turing complete scripting language called Varna and a very simple VM called High Level Machine (HLM). Varna is a primitive, Bitcoin Script-like language that contains no loops and so can execute within a predictable, bounded number of steps. For basic use cases (e.g. simple multisig functionality) Varna/HML will enable the development of “blindingly fast and cheap contracts with a known cost”.

To further assist developers and users æternity is also building a set of core æpps that provide foundational functionality such as account management, currency activation, app launching, and more. Built-in support for oracles, which æternity claims will be more flexible and universal than those currently being built on Ethereum, may enable a wider range of applications to be built on æternity. At a minimum, having a standard, built-in mechanism for oracle interaction simplifies the developer’s life by allowing them to focus on their application, rather than having to set up and integrate with a third-party oracle. This omakase approach to framework design was fundamental to the power and popularity of the Ruby on Rails web development platform. A key to Rails’s success, which æternity would be wise to emulate, is the ability and willingness to swap out the default components as better technologies come along.

Conclusion

The æternity project aims to provide a full featured platform that includes a number of built-in components (oracles, naming system, state channels, on-chain governance) to provide a better experience for developers and users of the system. This design philosophy is opposite that of Ethereum, which intentionally minimizes built-in features to allow innovation to come from the broader community. Remaining featureless has worked well for Ethereum because it has such a large and vibrant community. Given the current size of æternity’s community, providing key features might be the best approach to attracting developers and users to the platform near term. As the community grows and innovation flourishes, æternity could evolve to incorporate innovations coming from outside its core team.

Of all the platforms we’ve looked at so far, æternity plans to deliver the most complete set of smart contract environments, each optimized for specific classes of use cases. By providing an EVM-compatible environment, æternity should be able to support any application that can be built on Ethereum, leverage innovations coming from the Ethereum community, and minimize friction in deploying Ethereum dApps on æternity. Whereas there is essentially no security improvement in deploying on another Solidity/EVM environment, if æternity’s other environments and features bring developers and users to its platform, then the cost/benefit ratio might compel Ethereum dApp owners to do so.

There is still a lot of work to be done before these features are delivered and æternity is in position to challenge Ethereum. While that work is being done by æternity’s team of developers, innovation on layer 2 scaling solutions, oracles, prediction markets, and developer tooling in the Ethereum community continues unabated. Until æternity’s smart contract environments and features are deployed on a live mainnet with contracts securing significant value, we won’t really know whether and to what extent æternity will become a viable and/or compelling alternative to Ethereum. It will be interesting to see how things progress once æternity launches its mainnet later this year.