The block.one team has been working around the clock to make eos.io the most advanced blockchain software possible. While advancing the core software, we have also been working with a number of major players in the industry to migrate their platforms to make use of the eos.io software.
Constantly Evolving Design
EOS.IO is not a fixed specification, but a living design that is constantly being enhanced above and beyond our original white paper. We strive to make EOS.IO the best possible platform and to deliver it as rapidly as we can. Today we would like to discuss some of the changes that we are in the process of implementing.
Parallel Execution Ahead of Schedule
Our original roadmap called for a single threaded implementation to be complete by June 2018 and for multi-threaded development to take place thereafter. We are excited to share that work on the parallel execution engine has begun 8 months ahead of schedule and we believe that it will be ready by June 2018. The work required to make this happen includes a complete rewrite of chainbase, the underlying database technology behind Steem.
New Shard-Aware EOS.IO Database
Over the past several weeks we have implemented a new shard-aware database that is designed to enable multiple threads to access independent memory regions (called shards) at the same time. Shard data ranges are not fixed, different transactions can group different shards depending upon the necessary data access patterns.
New Multi-Threaded Key Recovery
We have developed a multi-threaded key recovery service that will accelerate the rate at which transactions can be validated compared to our existing single threaded approach.
We have been putting a lot of design work into how two blockchains will communicate with each other. This involves carefully crafting the structure of our merkle trees to make proofs meaningful and efficient. It also means restructuring our block headers and transaction headers.
Transactions now have an extra header field, a region. Think of it like a postal code indicating which blockchain the transaction is intended to be included in. By default region 0 implies the current chain and all other chains have different region codes. When a contract generates a deferred transaction for another region it is a signal for block producers to ignore that transaction. It is up to the other chains to use merkle proofs to verify the region code they have assigned themselves.
Error Handling on Deferred (Asynchronous) Transactions
Originally the EOS.IO software had no error handling for asynchronous transactions except for timeout. The reason we had this limitation was that error handlers themselves could fail. The only option for error handling was to wait for the transaction to expire without executing.
We have updated the block structure to allow producers to schedule transactions that fail for objective reasons and to execute an error handler. There are 3 possible states that a deferred transaction could be included as: success, error with successful error handler, or error with failure of error handler. Only objective failures are included, subjective failures such as using too much wall clock time will still require waiting for a timeout.
Adding Support for Apple's Secure Enclave
We are extending our support for elliptic curve keys validation to include the secp256r1 curve. This is the standard created by NIST and used by Apple, Android, and many Smart Cards. Users will have the option to pick their curves (secp256k1, is used by Bitcoin and EOS by default) and can use both (r1 and k1) if they don't know which one to trust! The most important aspect of this is that it will give every cell phone user a hardware wallet with biometric 2nd factor validation.
Implementation is ongoing, but the design decision has been made and should make EOS.IO usable in far more environments.
There is a lot of work going on here at block.one and the eos.io software is becoming better every day.
block.one is a software company and is producing the EOS.IO software as free, open source software. This software may enable those who deploy it to launch a blockchain or decentralized applications with the features described above. block.one will not be launching a public blockchain based on the EOS.IO software. It will be the sole responsibility of third parties and the community and those who wish to become block producers to implement the features and/or provide the services described above as they see fit. block.one does not guarantee that anyone will implement such features or provide such services or that the EOS.IO software will be adopted and deployed in any way.
All statements in this document, other than statements of historical facts, including any statements regarding block.one’s business strategy, plans, prospects, developments and objectives are forward looking statements. 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 contained herein 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.