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.
Note : this is copied from medium . This is shared just to inform people.