Approximately one month after block.one released EOSIO Dawn 3.0, the team has now released Dawn 4.0. Within the past month, the team has been focused on the cleanup and stability of the EOSIO software. One of the biggest changes in EOSIO Dawn 4.0 is the definition change of the current time from “time of head block” to “time of current block”. The switch 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.
A new update in EOSIO Dawn 4.0 is the initial pricing of 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, users could only sell RAM for the price they paid. The team’s 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.
Minimizing Speculation
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 the annual trading volume of RAM equals the token supply then 100% of all block producer rewards will be covered by the RAM market fees.
Chain Complexity
The team confirms that the EOSIO Dawn 3.0 had a lot of architecture complexity that was not giving any immediate benefit, they 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, the EOS team can simplify EOSIO 1.0 and optimize it for maximum single-threaded performance and ease-of-development. They anticipate that the single-threaded version of EOSIO may one day achieve 5,000–10,000 TPS.
Display Names
Due to the limited development time between now and the release of version 1.0 of the EOSIO software, the EOS team is going to recommend that all account names be forced to 12 characters and not contain any ‘.’ characters. The community will then be able to upgrade the system contract (without hard fork) once viable pricing and anti-name-squatting policies are identified. EOS said they will likely provide a model similar to BitShares where account names are priced by length and character content.
Header-Only Validation
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 the software now supports 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 a full verification.
Exchange Integration Support
As the EOSIO 1.0 release nears, many people are asking for information concerning how exchanges will monitor an EOSIO blockchain for incoming deposits and/or validate that their out-going withdraws are accepted and irreversibly confirmed. The EOS team has now created a tutorial on using cleos (the command line eosio interface) to monitor the chain for incoming deposits. They have also created a demonstration python script that monitors deposits and withdraws. With this tutorial and example script – exchanges will have everything they need to begin integration with EOSIO based blockchains.
Lightweight Producer Schedule Change Proofs
With EOSIO Dawn 4.0 it is now possible to validate changes to the producer schedules without having to validate any block headers. When a producer signs a block they also sign the new schedule such that it is impossible for there to be two competing and validly signed Producer Schedules without ⅔+ of producers colluding or ⅓+ colluding with a very bad network split.
New Producer Pay Paradigm
There has been a lot of community discussion around producer pay and how to allocate the maximum of 5% inflation. The reference system contract that block.one will provide with EOSIO 1.0 will allocate inflation like so:
There are 21 active block producers and any number of standby producers. The top 21 divides up the 0.25% per-block rewards proportional to the number of blocks each one produces. All block producer candidates (including the top 21) also divide up the .75% per-vote rewards budget proportional to the total number of votes they receive. They can claim their share of the per-vote rewards at most once-per-day. In order to claim their share, they must qualify for at least 100 tokens/day. Producers candidates who do not qualify for at least 100 tokens/day on a per-vote basis will receive nothing.
The idea behind this algorithm is to ensure all candidate producers have sufficient pay to provide full-node services to the community and to ensure no one is in the position of receiving money that is insufficient to cover their costs. Assuming the top 200 producer candidates all received the same number of votes this would support 21 active producers and 179 stand-by producers. In reality, some producers will have significantly more votes than others which may reduce the number of paid-standby producers.
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.