It has been about 1 month since block.one released EOSIO Dawn 3.0. This past month our team has been focused on cleanup and stability of the EOSIO software. A big part of this work was moving toward a proof of concept for inter-blockchain communication.
距離 block.one 發佈 EOSIO Dawn 3.0已經一個月了。 在過去的一個月裡，我們的團隊一直專注在EOSIO軟件的優化和穩定性，這其中很大一部分工作是在證明鏈間通信的可行性。
Excluding merges, 43 authors have pushed 818 commits to github. This puts EOSIO in the top 8 most active c++ projects on github in the past month. As you can see a lot is happening
One of the biggest changes in EOSIO Dawn 4.0 is that we have changed the definition of the current time from “time of head block” to “time of current block”. This change resolves a lot of corner-cases with time-based operations in the presence of missed blocks and enables much more accurate measuring of elapsed-time within smart contracts.
EOSIO Dawn 4.0最大的變化之一是我們已將當前時間的定義從“頭塊的時間”改為“當前區塊的時間”。 這種變化使得大量包含時間操作的案例可以在存在缺失區塊的情況下執行，並且更精確地計算智能合約的運行時間。
新的內存分配模型
In our testing we determined that how the EOSIO System Contract was allocating RAM (database space) to those who staked tokens would lead to shortages down the road. We switched to a market-based allocation approach using the Bancor algorithm.
Our math indicates that if 1TB of RAM was allocated on a pro-rata basis to token holders then the cost-per-byte would be $0.018 (assuming $20/token). The reality is that most token-holders don’t actually have an active need to use the RAM they might be entitled to; therefore, we are initially pricing RAM at $0.000018 per byte (assuming $20/token). New accounts require about 4KB of RAM which means they will cost about $0.10. As RAM is reserved the price will automatically increase so that the price approaches infinity before the system runs out of RAM.
Under the Dawn 3.0 system contract, you could only sell RAM for the price you paid. The goal was to disincentivize hoarding and speculation. The downside to this approach is that those who buy RAM cheaply have no financial incentive to free RAM for other users after it gets more congested. Under Dawn 4.0 the system contract now buys and sells RAM allocations at prevailing market prices. This may result in traders buying RAM today in anticipation of potential shortages tomorrow. Overall this will result in the market balancing the supply and demand for RAM over time.
Over time Moore’s law will allow block producers to upgrade to 4TB or even 16TB of RAM and this increase in supply will trickle into the the EOSIO RAM market lowering prices.
As a smart contract developer, RAM is a precious resource which is consumed by the database records you store. Due to the cost of RAM it will be important to minimize the amount of data that you store in the in-memory database and design your applications with the ability to free RAM after your users are done. For example, Steem only stores 1 weeks worth of content in RAM so that the total size doesn’t grow much over time.
Now that there is a RAM market, speculators may want to trade RAM price-volatility for profit. The EOSIO system contract makes RAM non-transferrable and charges a 1% fee on trades. The result of this fee is to offset the natural inflation of tokens by taking them out of the market. If annual trading volume of RAM equals the token supply then 100% of all block producer rewards will be covered by the RAM market fees.
High performance blockchains need all data in RAM because the time to access disk will quickly drop transaction throughput to just a couple hundred transactions per second. In order to scale RAM usage we need multiple chains with independent memory regions running on independent hardware.
EOSIO block producers can operate many different chains that all use the same token for buying RAM and staking bandwidth. The producer elections will happen on the main chain and all related side-chains will be operated by the same set of producers. Each chain can have its own 1 TB+ of RAM and decentralized applications can send messages between chains with just a couple seconds of latency.
The price of RAM will be different on all chains which will inform DAPP developers where it is cheapest to operate.
Inter Blockchain Communication (IBC) involves both chains validating merkle proofs that are 1KB+ in size and involve dozens of cryptographic hash functions and/or 15+ signature verifications. In other words, the cost of validating a message from another chain is about 15x to 30x higher than the cost of validating normal transactions.
Fortunately, validating these proofs is trivial to parallelize as they do not depend upon blockchain state. A blockchain that only processed messages from other chains could easily consume 30 CPU cores while only sustaining a couple thousand transactions per second.
It is our belief that scaling via Inter Blockchain Communication will give almost unlimited scaling potential. This approach scales RAM, network, and CPU at the same time. Considering that signature verification, context-free-action validation and IBC proofs will already saturate most CPUs with high-single-threaded throughput, optimizing for multi-threaded WASM execution will likely be bottlenecked by other resource constraints.
Under EOSIO Dawn 3.0 we made a lot of design decisions around the potential for future multi-threaded WASM execution. Unfortunately, until you actually implement a full multi-threaded implementation it is impossible to know whether we have all the corner cases covered. This means that EOSIO Dawn 3.0 had a lot of architecture complexity that was not giving any immediate benefit.
We now believe that the path of upgrading from single-threaded to multi-threaded execution is to launch a new chain with multi-threaded support run by the same block producers and staking the same native tokens. This gives the new chain complete freedom to make design tweaks as necessary to support multi-threaded operation without risking an in-place upgrade to a live chain.
With this roadmap to parallelism we can simplify EOSIO 1.0 and optimize it for maximum single-threaded performance and ease-of-development. We anticipate that the single-threaded version of EOSIO may one day achieve 5,000–10,000 TPS. We also anticipate that many applications will prefer the many-chain approach to scaling as it will lower overall costs and scale faster.
Those of you who have followed consensus algorithm debates may have heard that DPOS with the last irreversible block (LIB) algorithm (as it exists in Steem & BitShares) has the potential to fall out of consensus in certain extreme network connectivity disruptions. In the past I have dismissed this potential failure mode due to its purely theoretical nature and the relatively minimal costs and downtime. The LIB algorithm was just a metric, like the 6-block rule for Bitcoin. Pure DPOS always relied on longest-chain rule which will always reach eventual consensus. The LIB algorithm was a short-cut designed to optimize undo-history and give a confidence measure to exchanges.
EOSIO’s IBC algorithm depends upon the DPOS LIB in order to be certain of finality. The costs associated with a LIB failure and the difficulty in fixing it are much higher once you introduce IBC. Our team, specifically Bart and Arhag, have come up with an elegant improvement to the LIB algorithm which guarantees that it is impossible for two nodes to reach a different LIB without more than ⅓ of them being byzantine. Furthermore, it is possible to detect byzantine behavior of a single peer. Read more about it here.
It is the lack of finality of Bitcoin and Ethereum blocks that make inter blockchain communication with legacy chains difficult and/or very high latency. The new tweak to DPOS brings it up to a new level of byzantine fault-tolerant finality and robust in all network environments.
Some users have expressed concern over the 12 character name limit imposed on EOSIO accounts. These 12 character names are derived from base-32 encoding of a 64 bit integer. The 64 bit integer is the native machine word size and is therefore very efficient. Within a transaction we refer to account names many times, (code, scope, permissions, etc), and our database indexes are also based around these 64 bit integers. Increasing the length of an account name would have far-reaching impact on performance and architecture.
That said, our vision for blockchains is to separate the concept of accounts from identity and to establish a dynamic on-chain mapping between account names and more readable display names.
It is best to view account names as license plates where users can pick vanity plates that are easier to remember. That said, the vast majority of people should be able to find an attractive 12-character (or less) name.
Due to the potential high-value of certain names, we believe that the EOSIO system should offer a dynamic pricing model for account names. Furthermore, the ability to namespace accounts such as *.com can provide an extra layer of security for users and/or groups.
Due to the limited development time between now and the release of version 1.0 of the EOSIO software, we are going to recommend that all account names be forced to 12 characters and not contain any ‘.’ characters. The community can then upgrade the system contract (without hard fork) once a viable pricing and anti-name-squatting policy is identified. We will likely provide a model similar to BitShares where account names are priced by length and character content.
On Steem, BitShares, and EOS Dawn 3.0 and earlier it was not possible to validate a block-header without applying the full block. With EOS Dawn 4.0 we now support header-only validation. This feature is the basis of light clients and IBC and also prevents a range of attack vectors while allowing blocks to propagate across the network without waiting for each node to do full verification.
The simplest form of IBC for high-frequency communication involves light clients processing all headers and then users providing simple merkle-proofs of actions relative to a known block.
在Steem, BitShares和 EOS Dawn 3.0以及更早的版本中，如果不使用整個區塊是不能驗證區塊頭的。在EOS Dawn 4.0中，我們支持了只需要對區塊頭進行驗證。這個功能是輕客戶端和鏈間通信的基礎，同時還可以阻止一系列攻擊媒介，同時無需等待每個節點進行全節點驗證的情況下，區塊數據也可以在網絡中傳播。
We spent significant time cleaning up the process by which blocks are built and applied. Under the new model a block is created with the same sequence of API calls that are used to apply the block. This ensures the same code-paths are followed and minimizes the potential for inconsistencies between what a producer thinks is valid and what a validator thinks is valid. This cleanup makes the process of applying the block as little more than a script that replays what the producer did.
As we were implementing the IBC proof-of-concept we realized that Dawn 3.0 had a few edge cases where simple signature proofs were impossible. We wanted to make light-weight sparse-header validation as simple as possible which necessitated a refactor of how blocks are signed.
