View all News

EOSIO Dawn 4.0 Release

Last week we introduced EOSIO Dawn 4.0, today we are proud to bring you the next major pre-release of EOSIO. A lot has happened in the past week!

Feedback on Dawn 4.0 RAM Allocation

Some community members expressed concern that some people will derive unjustified profits by buying up cheap RAM before anyone else can get on the chain. To mitigate this, we recommend that those who launch a chain start out with a very limited supply of RAM and then gradually increase the RAM over the first couple of months. If the RAM supply starts out at 32GB and then grows to 1TB over a period of months then the price of RAM may rapidly drop over time to 3% of its initial pricing. Only those who really need RAM or who factor in future RAM supply when bidding will buy the initial RAM. Either way, no one will get “cheap” RAM or “free profits”.

Test Network Status

Our internal test network with nodes in Europe, Asia, and the United States has been operating well without significant issues.

Subjective CPU Resource Usage is Back

For the past several months we have been experimenting with objective CPU billing. Objective billing attempts to calculate a number of CPU instructions used by a transaction in a deterministic manner. This has the nice property of ensuring that there is complete and unambiguous consensus over what resources are consumed by a transaction. It is also the method used by many other smart contract platforms.

When we introduced EOSIO a year ago we proposed the use of Subjective Best Effort Scheduling. Under this model each block producer would measure the wall-clock-time it took to execute the transaction and charge the user accordingly. To maintain consensus over usage, the producer will report the number of microseconds they billed to the transactions.

While objective billing is nice for its ability to eliminate billing disputes and simplify consensus, it has several drawbacks which caused us to finally decide on subjective billing:

  1. Objective CPU measures slow down performance by introducing extra bookkeeping.
  2. Objective CPU measures introduce attack and denial of service vectors anytime there is inconsistency between the real cost of an action and its objective approximation.
  3. Objective CPU measures are difficult to maintain, upgrade, and introduce optimizations.

Subjective billing has its own challenges, especially in a consensus system. Fortunately we have found innovative solutions that make it practical. Some of these challenges include:

  1. Trusting producers to accurately report usage.
  2. Resolving differences of opinion among producers (caused by hardware/software/load).
  3. Dealing with a malicious producer.

With Delegated Proof of Stake it is expected that the block producers would be public entities with contractual obligations and legal repercussions for malicious behavior. It is further expected that all 21 active producers are highly approved by their the community who elected them.

Based upon this we can place an element of trust on all of them to act as cpu runtime oracles and not lie about how long a transaction takes to run. This means that under normal operating conditions we can trust that the reported runtime is within a reasonable margin of error of average runtime across all producers.

Critics of this approach may point out that a single malicious producer could construct a block with an infinite loop and report it as taking no time. To prevent this all nodes place a cap of a couple seconds of runtime for all blocks; however, even with the cap it could cause some disruption to the network. A savvy malicious producer might construct a block such that 50% of the nodes accept it and 50% reject it and thus split the network.

Our team has analysed these attack vectors and come to the realization that a block with a very long runtime is no different than a very long network delay or outage. Any consensus algorithm that is robust in the face network partitions should also be robust in the face of other subjective things. Because DPOS with BFT can withstand network partitions (like if US and China get temporarily disconnected from the broader internet), it can survive a malicious producer creating such conditions.

There are several ways that block producers can mitigate the potential for network partitions and they are the same whether the cause is cutting a fiber optic cable in the Atlantic or a malicious producer.

  1. Maintain Multiple Connections

With this approach if the connection across the Atlantic is cut, then the producer would route packets across the Pacific. When it comes to validating blocks, a producer should have several validating nodes and never have the two nodes attempt to validate the same block. In the most extreme case each producer could have dedicated nodes for processing incoming blocks from each peer producer. If one producer clogs their validating channel with an infinite loop then blocks from the other producers can still get through their independent and redundant channels. Once the irreversible block number moves past the block number of the bad block (the one with an infinite loop), the node can force the block processing to terminate and exit. It would require ⅔+ of the producers to be byzantine stop consensus from advancing.

  1. Repair or Route Around Damage

It isn’t always possible to have multiple fibre-optic cables ready to take over the moment one of them is cut. In this event a team is dispatched to repair the damaged cable and restore connectivity. This may take longer, but eventually connectivity returns and the network resumes consensus with nothing more than a little down time. When it comes to a bad producer causing mischief the other producers can simply update their configuration to blacklist the bad producer and then the network will resume its normal operations. The process of blacklisting a bad producer can even be automated any time they observe a block that takes an unreasonable amount of runtime. Worst case scenario a bad producer crafts a block right on the edge of the ban threshold such that only causes half of the producers to blacklist him. In this event the last irreversible block will cease to advance while the producers decide which pending fork to follow.

In all of the above cases users who rely on the last irreversible block for determining finality are safe from double spend attacks and the “down time” experienced by the network is likely to be less than the typical “down time” people experience from their power companies or ISP.

We believe that the governance processes and incentives of DPOS make the probability of malicious behavior leading to short-term downtime to be lower than the probability of internet connectivity issues leading to downtime for all blockchain platforms. At least with DPOS users are safe from unknowingly being on a minority chain that is unwound after reconnection. With Proof of Work chains a network split could result in double spend attacks for those who only rely on a fixed number of confirmations.

System Contract Updates

The ‘eosio.system’ contract is what provides the implementation of producer registration, voting, staking, and resource allocation. Our team has been working to provide a reference implementation that a community may choose to adopt when they create their chain. In this release the system contract has been updated to include the following:

  1. No one can unstake until 150,000,000.0000 TOKENS have cast a vote for at least one producer or proxy.
  2. If a chain wishes to allocate 10% of TOKENS to Block.one, it will rate limit unstaking to 1% per year.

Hacked Account Recovery & Lost Password Recovery

Our team created a new approach to hacked account recovery and lost password recovery that enables almost everything to be implemented in Web Assembly. We added a new intrinsic API that returns the last time a permission level was authorized by an account. With this information a smart contract can now implement the logic required to enforce 30 days of inactivity followed by 7 days notice before resetting a lost password entirely in Web Assembly.

We removed 3 hard-coded action handlers, eliminating potential bugs and making it easy to enhance with soft-updates later. The one or more implementations of lost password recovery may be provided as a separate smart contract after the release of 1.0.

Available on Github Now

EOSIO Dawn 4.0 is now available on GitHub so developers can start testing their applications.

EOSIO 1.0 Coming Soon

Our team is working around the clock to bring a stable EOSIO 1.0 to the market the first week of June. This initial release will have everything needed to allow anyone to create their own EOSIO based blockchain. We have implemented a “feature freeze” and the next few weeks will be dedicated to operating and testing internal test networks and fixing bugs discovered. Our goal is to ensure the most critical features are rock solid. After EOSIO 1.0 we will continue to enhance the EOSIO software with non-forking changes which will enable a host of usability and infrastructure improvements.


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.

Sign up to receive all the latest news & insights from EOSIO