Introducing EOSIO Dawn 4.0

Daniel Larimer
May 4, 2018 · 12 min read

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.

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.

  1. Now is now Now
  2. New Market-Based RAM Allocation Model
  3. Rise of Inter-Blockchain-Communication
  4. Upgrade DPOS Last Irreversible Block Algorithm
  5. Name Squatting
  6. Header-only Validation
  7. Light Weight Producer Schedule Change Proofs
  8. Refined Producer Pay Model
  9. Producer Vote Decay
  10. Exchange Integration Support

Now is now Now

RAM Allocation Model

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.

Implications for Smart Contract Developers

Minimizing Speculation

The Rise of Inter Blockchain Communication

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.

Roadmap for Parallelism

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.

Upgrade DPOS Last Irreversible Block Algorithm

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.

Name Squatting

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.

Header-Only Validation

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.

Refactored Block Building & Applying Architecture

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 are 21 active block producers and any number of standby producers. The top 21 divide up the 0.25% per-block rewards proportional to the number of blocks each one producers. 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.

It is critical to have a minimum per-day payment so that wealthy individuals who have no intention of producing blocks don’t attempt to earn interest on their producer candidate by voting on themselves.

Producer Vote Decay

We recommend that the constitution contain language forbidding the use of automated voting bots as the purpose of vote-decay was to ensure that voters re-evaluate their decisions rather than “set-it and forget it”. While it is not possible to prove the use of bots, it will be possible to prove that people do not use smart contracts to auto-vote.

Exchange Integration Support

Availability of EOSIO Dawn 4.0

Conclusion

Disclaimer: block.one is a software company and is producing the EOS.IO software as free, open source software. This software may, among other things, enable those who deploy it to launch a blockchain or decentralized applications with various features. For more information, please visit https://github.com/eosio. block.one does not provide financial support to anyone seeking to become a block producer on any version of the EOS.IO platform that may be adopted or implemented.

block.one will not be launching a public blockchain based on the EOS.IO software. It will be the sole responsibility of third parties, the community and/or those who wish to become block producers to adopt and implement EOS.IO in the manner they choose, with the features they choose and/or providing the services as they choose. block.one does not guarantee that anyone will adopt or implement such features or provide such services or that the EOS.IO software will be adopted and implemented in any way.

Please note that this document is an expression of block.one’s vision, not a guarantee of anything. While we will try to make that vision come true, all aspects of it are subject to change in all respects in block.one’s sole discretion. We call this “forward looking statements”, which includes all statements in this document, other than statements of historical facts, such as statements regarding block.one’s business strategy, plans, prospects, developments and objectives. These statements are only predictions and reflect block.one’s current beliefs and expectations with respect to future events and are based on assumptions and are subject to risk, uncertainties and change at any time. We operate in a rapidly changing environment. New risks emerge from time to time. Given these risks and uncertainties, you are cautioned not to rely on these forward-looking statements. Actual results, performance or events may differ materially from those contained in the forward-looking statements. Some of the factors that could cause actual results, performance or events to differ materially from the forward-looking statements include, without limitation: market volatility; continued availability of capital, financing and personnel; product acceptance; the commercial success of any new products or technologies; competition; government regulation and laws; and general economic, market or business conditions. Any forward-looking statement made by block.one speaks only as of the date on which it is made and block.one is under no obligation to, and expressly disclaims any obligation to, update or alter its forward-looking statements, whether as a result of new information, subsequent events or otherwise.

The statements herein do not constitute technology, financial, investment, legal or other advice, nor do they apply to any particular situation or implementation. Please consult with experts in appropriate areas before implementing or utilizing anything contained in this document.

The ideas and information expressed herein are solely those of the author and do not necessarily reflect the positions, views or advice of block.one or any other employee of block.one.

eosio

Published by block.one,

eosio

Published by block.one, EOS.IO is a blockchain protocol that enables horizontal scaling of decentralized applications, allowing developers to efficiently create high performance distributed applications.

Daniel Larimer

Written by

Cofounder of Block.one, Steemit.com, BitShares.org, and Voice.com

eosio

Published by block.one, EOS.IO is a blockchain protocol that enables horizontal scaling of decentralized applications, allowing developers to efficiently create high performance distributed applications.