EOSIO Dawn 3.0 Now Available
Block.one is excited to announce the first feature-complete pre-release of EOSIO, Dawn 3.0. This pre-release represents a major milestone on the road to EOSIO 1.0 targeted for release in June 2018. Our world wide team of developers have been working around the clock to make EOSIO the most powerful platform for building blockchain applications. It has been four months since we released EOSIO Dawn 2.0 and we have a lot to show for it.
Building state of the art blockchain architectures is a process where designs change as we learn. Many of the features we have completed in Dawn 3.0 were not even contemplated in the original EOSIO White Paper, but were discovered in the process of building a platform that is performant, flexible, and easy to develop on.
Scalability Features
Scalability means the ability to scale to meet market demand. At every step our team has factored future scaling needs into the design. That said, Dawn 3.0 only implements a fraction of the potential optimizations that will allow EOSIO to scale. We have designed EOSIO so that future implementations can utilize parallel computation to accelerate throughput without hard forking changes.
Inter-Blockchain Communication
Inter-blockchain communication is the ultimate scalability feature — the holy grail — that the industry has been searching for with proposals such as side-chains, plasma, and sharding. Inter-blockchain communication enables one blockchain to verify the authenticity of an event on another blockchain in a provably secure manner. The goal is for inter-blockchain communication to be as secure as intra-chain communication between smart contracts and we think we have achieved that goal.
From our perspective, inter-blockchain communication is nothing more than having the ability to implement a light client as a smart contract. A light client is able to validate transactions from a blockchain without having to process the entire blockchain. This in turn means building a proof-of-stake blockchain with efficient and secure light-client validation. Light-client validation must therefore be factored into the protocol design, as it is almost impossible to implement after the fact.
Sparse Header Verification
Traditional light clients are expected to process every block header and then validate proofs relative to those block headers. Now that EOSIO can generate two blocks every second, a blockchain would require at least 2 transactions-per-second to process every block header. This does not scale for scenarios where there is relatively infrequent inter-blockchain communication. To solve this problem, we created the first blockchain with byzantine fault-tolerant sparse-header validation. Specifically, it requires more than 2/3 (e.g. 15+ out of 21) of the block producers to be corrupt in order to attempt to deceive a light client. Furthermore, light clients only need to process block headers where the set of active block producers changes and those that include relevant inter-blockchain messages. This dramatically reduces the overhead in maintaining a byzantine fault-tolerant light client, and dramatically increases the efficiency of inter-blockchain communication.
Context Free Actions
Context free actions are one of the key features that enable efficient inter-blockchain communication. They are special actions in that they can be included in a transaction yet do not depend upon blockchain state, hence they are “context-free”. An example of a context free action is the validation of a merkle proof or signature. Because these computations are context-free they can be trivially validated in parallel and the computation can be pruned from replay.
Every context-free action can also reference a special prunable data section of a transaction. This means that large merkle proofs can be pruned and their expensive computation skipped during blockchain replay.
Context free actions enable us to parallelize the vast majority of the overhead associated with inter-blockchain communication. They also enable us to parallelize and prune the overhead of computationally expensive privacy techniques such as confidential transactions, bullet proofs, and zkSNARKs.
In order to incentivize the use of context free actions, block producers will only charge users a fraction of the CPU usage when a calculation is performed as part of a context free action instead as part of a traditional transaction.
Context-Free Inline Actions as Events
One of the features EOSIO Dawn 2.0 developers were looking for was an efficient way to generate events that get processed by outside sources. In Ethereum these events are used to report structured information about the internal operation of a contract. With the addition of context-free actions, we also have the potential to do context-free inline actions. An inline action is one that is generated by contract code and executed as part of the current transaction. A context-free inline action can be processed cheaply and in parallel. Because all inline actions are also included in the merkle root, it is possible to use these actions as provable notifications to outside services and other blockchains.
Transaction Compression
There are many transactions that have a lot of compressible data. One of the most unavoidable examples of this is the contract WebAssembly code itself. Other examples include the ABI specification and the Ricardian contract associated with an account/contract. Some applications, such as social media, may also want to include compressible user generated content in the blockchain.
By utilizing transaction compression the blockchain can more efficiently store and transmit large numbers of transactions and bill users less for transactions with compressible data than transactions with incompressible data.
Interpreter & Just-In-Time Compilation
One of the biggest changes from Dawn 2.0 is the abstraction of our WebAssembly runtime environment. Dawn 3.0 now utilizes the Binaryen WebAssembly interpreter by default rather than the faster Just-in-Time (JIT) compiler. This decision reduces performance but increases stability and standards conformance while allowing us to trivially swap in the higher performant JIT environment when desired. The interpreter also solved one of the biggest challenges we faced with Dawn 2.0: the delay caused by compiling a contract. In the future we can use the interpreter to get a slower, but lower-latency, execution of freshly deployed contracts while we compile and optimize the contract in the background. This double-implementation means all of our unit tests are tested against both compiled and interpreted code, so we can discover potential non-deterministic or non-standards-conforming behavior before we deploy the hybrid approach.
Resource Metering Rate Limiting
With Dawn 3.0 we now have an entirely new resource rate limiting system. Perhaps the biggest change is the introduction of an objective instruction-counting algorithm. When we set out to build EOSIO, we had a goal to use entirely subjective rate limiting and enforcement. What we discovered was that the cost of subjective enforcement was almost identical to a more objective approach. We now utilize a hybrid solution where users are billed for objective use, but block producers place subjective wall-clock time limits on contracts as well. These subjective limits prevent abuse of variance in the objective billing.
One of the major reasons we adopted this approach was to allow individual transactions to perform many more calculations than was previously possible. It is now theoretically possible for a block to include a single transaction that takes 100 ms to run, whereas under the old model every transaction had to run in under 1 ms.
Another change to rate limiting is the separation of limits from the need to define a token. This allows EOSIO to be used in private, permissioned blockchains without any use of tokens. The public blockchain can adopt a system contract which implements the limits via staking, and the community can dynamically upgrade how resources are allocated independently from how the allocation is enforced.
500 ms Block Interval & BFT DPOS
With Dawn 3.0 we have moved from a 3 second block interval to a 0.5 second interval. This dramatically reduces the latency until confirmation. When combined with BFT DPOS, transactions can be irreversibly confirmed in under 1 second. The latency until irreversibility has major implications for inter-blockchain communication, because another blockchain must wait for irreversibility before incorporating a proof from a foreign chain. Two EOSIO-based blockchains should be able to perform a round-trip communication in under 3 seconds. A similar communication pattern on Ethereum would take 9 minutes, and on Bitcoin would take 3+ hours.
BFT DPOS has not yet been implemented as it is a non-hard-forking optimization. We will be implementing BFT DPOS prior to releasing EOSIO 1.0.
BIOS Architecture
The BIOS architecture is one of the biggest architectural changes from EOSIO Dawn 2.0. Under EOSIO Dawn 3.0, the vast majority of the blockchain business logic has moved into a smart contract which can be dynamically updated by the community without a hard fork. A bare-bones EOSIO blockchain is now a single producer without any tokens, voting, or delegated proof-of-stake. The only thing implemented in the core blockchain code is the permission system which includes the ability to create accounts, deploy contracts, and enforce resource quotas. Everything that makes the blockchain Delegated Proof of Stake including the token, voting, staking, and resource allocation is now defined by the Web Assembly based system contract.
With this new architecture, we have been able to focus development on the static non-WebAssembly portions of the blockchain. These are the portions that are most critical for stability — and most difficult to upgrade. Between the release of EOSIO Dawn 3.0 and EOSIO 1.0 we will be working out the final details of the system contract, staking, and voting.
Security Features
Security is crucial for any computing system, and we have designed EOSIO to be the most secure blockchain on the market. Security is a multi-dimensional problem that must factor in the risk of hacking, hardware failure, lost hardware, and lost passwords. Hardware wallets are good at protecting against hacking, but could nevertheless lock you out of your account if they fail. Furthermore, paper backups of hardware wallets can be lost or stolen.
Security Delayed Transactions
One of the most significant features of EOSIO Dawn 3.0 is the addition of a user-configurable delay for different actions. With this delay, a transaction must be broadcast to the blockchain for a number of hours or days before it can be applied. During this delay period the user can take measures to reset their account with higher-permission levels and then cancel the transaction. This is a significant improvement over other blockchains where you don’t know you have been hacked until it is too late to do anything about it.
Lost Password Recovery
Every account has at least two permission levels: “owner” and “active”. The owner permission level should be a N of M multisig where there is no N that doesn’t include the owner’s key(s). The owner permission level can reset the active permission any time the active key is lost or stolen.
If you lose the owner key or your multisig partners are being uncooperative, then the account active permission can request a reset of owner permission after 30 days of owner permission inactivity. The owner authority then has 7 days to challenge the request by updating the active authority.
Under this model, an account owner permission controlled by one or more hardware wallets will be secure against hacking and device failure. If the device were an Apple iPhone with hardware and Fingerprint/Face ID secured private keys, then the attacker would require compromising your multisig partners, physically stealing your phone, and stealing your fingerprint or face. Ideally your multisig partners are also using biometrically secure hardware devices.
Transaction Proposal System
Multisig is made easier when users can add and remove their permissions independently in their own time, rather than having to gather all the signatures during the limited expiration window of traditional transactions. With the proposal system, anyone can propose a transaction and the parties involved in the transaction can simply approve it. At any time between adding your approval and getting the necessary threshold, your approval can be removed.
To implement this system, we added new APIs that allow contracts to evaluate whether a set of account permissions is sufficient to authorize a transaction. This allows us to upgrade the multisig process by deploying new WebAssembly rather than requiring a hardfork.
Simplified Contract Development
One of our many goals with EOSIO is to make contract development as simple and painless as possible. If a developer knows how to write a C++ class with methods, then they should be able to write a smart contract with as little boilerplate complexity as possible.
We are pleased to have simplified our “hello world” contract down to a few simple lines of code. Our toolchain has automated the process of generating contract ABI and dispatching user actions to the methods defined on your class. Developing contracts has never been easier.
Floating Point Support
Part of simplifying smart contract development is making it easier to implement the mathematical algorithms developers need. One of the most difficult aspects of blockchain development has been the lack of floating point math and related power, root, and trig functions. Many algorithms, such as Bancor, are much easier to implement in terms of floating point rather than forcing all computations into error-prone and memory intensive fixed point.
We solved the non-deterministic nature of hardware floating point by integrating a software-floating point library that is used transparently by the WebAssembly contracts. With software floating point we get the benefits of determinism and ease of development at a cost not much greater than fixed point in complex cases. In many cases, fixed point is either more error prone or more memory intensive than the deterministic floating point representation.
C++ Standard Template Library Support
For EOSIO Dawn 3.0, we put significant effort into adding support for the majority of the C++ standard template library. This means developers can use the tools, libraries, and algorithms they are familiar with, while eliminating the potential for bugs caused by non-standard implementations of these algorithms.
Scheduled Transactions
With scheduled transactions developers, can now write contracts that operate forever — provided the contract has sufficient staked bandwidth. Other platforms require off-chain solutions to wake a contract at an appropriate time. With scheduled transactions, we gain efficiency and ease of use without requiring developers to host their own servers to keep a contract running.
Automatic Scope Detection
Under EOSIO Dawn 2.0, every transaction was required to declare which data ranges it would access. This was error prone and verbose for developers. Under Dawn 3.0, the block producers are responsible for determining which data ranges are accessed and to deconflict them. This makes all transactions smaller and moves the scheduling overhead to the block producer rather than pushing it back on the user, developer, or full nodes.
MultiIndex Database API
EOSIO Dawn 3.0 introduces a new database API that mirrors the boost::multi_index_container. With this API, it is trivial to support database tables that are sorted by multiple keys, find items, use lower/upper bound, and iterate forward and backward over the database. This new API uses an iterator interface which dramatically improves performance for scanning through a table.
It is also now possible to have indices on 64 bit, 128 bit, 256 bit, and 512 bit integers as well as 64 bit floating point (doubles). Support for string indices will be added before EOSIO 1.0 is released. This is is a significant improvement in flexibility and ease of development as it is now possible to have almost unlimited number of indexed fields on the same table.
Performance
Real-world performance is something our team has been monitoring closely, and we are very happy with the results at this time. We have benchmarked our software in several different configurations to understand the lower and upper bound of performance as we enable future optimizations. All of these tests are assuming token transfers to be apples-to-apples comparable to Bitcoin or Ethereum ERC20 token transfers in terms of computational complexity.
Worst Case — 1000 TPS
This is our baseline performance without any optimizations. We are able to sustain over 1000 TPS using a multi-node network running the interpreter with single-threaded signature verification.
Average Case — 3000 TPS
Once we turn on the JIT compiler we can sustain 3000 TPS using a multi-node network running the interpreter with single-threaded signature verification.
Best Case — 6,000 TPS
Once we implement parallel signature verification, we can assume the wall-clock-time per-signature will approach 0 as the level of parallelism and the number of signatures increase. We can simulate this environment by disabling signature verification. Under this model we can hit 6,000 TPS on a multi-node network with the JIT compiler.
Theoretical Case — 8,000 TPS
If we remove the networking code from the equation and focus only on what the CPU is capable of doing with signature verification turned off and using the JIT, then we can hit 8,000 single-threaded transactions-per-second. To go higher than this on a single chain would require implementing parallel execution of the WebAssembly, and a more advanced scheduler. In this same scenario, using the interpreter rather than the JIT, we can see 2700 TPS. This suggests that the relatively simple change of enabling the JIT will give us about 3x performance increase for transfers. These measurements were made on a MacBook 2.8Ghz i7.
Unlimited Transactions Per Second
The definition of a “transaction per second” is often an apples to oranges comparison. With inter blockchain communication we can divide the workload between as many blockchains as we want. Tokens can reliably and securely be transferred between different chains. With 1000 chains operated in parallel by the same (or different) block producers we could see millions of transactions per second. This represents a practical realization of the theoretical scaling proposals presented by other blockchains.
We strongly encourage block producers of EOSIO based public networks to operate as many chains as necessary to meet user demand. All chains could use the same token as the basis for staking and resource allocation. This will create the maximum possible network effect around a single token and leverage the trust and security of economic incentives created by high-market capitalization tokens.
Applications like exchanges, currencies, and social media can trivially balance their loads across many parallel chains.
The Road Ahead
With EOSIO Dawn 3.0 the focus was on stability of the core platform. Over the next month we will be preparing the final system contract which implements all of the staking, voting, and governance mechanics. We will also be finalizing our token standard.
Once the system contract has matured to our satisfaction we will launch a new public test network. Until then we have greatly simplified the process for starting your own test network and developing your own applications. We are shutting down the current public test network for the next couple of weeks while we prepare the new test network to minimize developer confusion.
Summary
EOSIO Dawn 3.0 is a developer release designed to be “feature complete” with stable APIs. We believe the platform is now stable enough for serious application developers to start building their applications. EOSIO has become far more powerful and easy to develop for than we had conceived a year ago.
Our team is growing and development is occurring at record pace. Our repository has been one of the top 10 most active C++ repositories in all of github for the past month. Everything is on track for a high quality public release of EOSIO 1.0 in June!
All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
Important Note: All material is provided subject to this important notice and you must familiarize yourself with its terms. The notice contains important information, limitations, and restrictions relating to our software, publications, trademarks, third-party resources and forward-looking statements. By accessing any of our material, you accept and agree to the terms of the notice.