![](https://steemitimages.com/DQmPgU9hugYig9dCJWYfpfDkZLA5Tmshk5qhTXg7rcfzuSq/image.png)

In the [EOS.IO Technical White Paper](https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md), we proposed the EOS.IO software as the dawn of a new era of blockchain computing. The EOS.IO development team has spent the summer working very hard. Summer is over and the development of the EOS.IO software is ahead of schedule.  It can now be used with distributed network configurations. We have a lot of exciting EOS.IO software developments to report so be sure to read to the end!

# Proof of Performance
Now that the EOS.IO software can be used in distributed network configurations we can benchmark its performance. Our internal testing shows that the software is currently able to sustain over 10,000 single threaded transactions per second on a multi-node network. This puts it on track to support over 1 million transactions per second on machines with over 100 CPU cores.

## Advancements in Design
Developers will be excited to learn that our latest architectural software improvements make it easier than ever to build parallel applications that communicate with each other. 

### Shared Database Access
We have now enabled one application to read the database state of another application without requiring complex asynchronous communication. We achieve this while preserving the ability to execute in parallel by allowing each transaction to declare the scope (data range) that it needs to read or write access to.  Block producers will schedule transactions so that there are no data conflicts. 

### User Local Storage of Application Data
In addition to supporting read access across accounts, applications can now store data on other accounts. This means a currency contract can store the balance on individual user accounts rather than within its own scope. A transfer from Alice to Bob only requires read/write access to the scope of Alice and Bob and won’t affect the currency contract’s scope. This makes many classes of applications trivially parallel and enables processing of currency transfers in excess of the single threaded throughput limit. As far as we are aware, no other blockchain design supports such a scalable and easy approach to developing parallel software architecture.

### Inline Message Passing
It is now easier than ever to send a message to another application and know with certainty that it will be accepted and validated. An application can generate any number of additional messages to append to the end of the current transaction. So long as these generated messages share the same read/write scope and can execute within the allotted time, they are guaranteed to be delivered or the entire transaction will unwind.

This approach is different than the synchronous approach used by other platforms. Synchronous message delivery, which blocks execution of the current thread until it returns, creates the potential for unanticipated reentrancy. Reentrancy has been a source of numerous bugs and exploits because it is difficult for developers to ensure their contract is in a consistent state prior to making a synchronous call. With inline message passing, which delays execution until the end of the current transaction handler, developers can dispatch a message and proceed as if it succeeded. If it fails then the entire transaction will be unwound without any harmful side effects. This means your message handlers are never called in an inconsistent state.

### Deferred Message Passing
Sometimes you don’t know if a message is valid or whether there is enough time left on the clock to execute inline with the current transaction. Other times you need to send a message that accesses data outside the scope of the current transaction.  In this situation applications can request the block producers schedule a message to be delivered in the next cycle or a future block. If it is valid then your application may be notified; if it is not, then it will never be scheduled and your application can clean up after a timeout.

### Unlimited Horizontal Scaling
The latest design advancements in the EOS.IO software gives developers high single-machine performance; businesses can scale to a million transactions per second before requiring a more complex asynchronous architecture.

That said, the EOS.IO software will still support asynchronous message passing among groups of applications that do not need to share state. There are many benefits to async message passing (such as trivial cluster support), but those benefits come with the cost of greater development complexity; the EOS.IO software supports this for businesses that require several millions of transactions per second, but offers a streamlined approach for those that don’t.

# Next Generation Network Topology
**The EOS.IO software is designed to empower block producers to provide a high performance decentralized infrastructure as a service.** Application developers need more than a set of block producers aggregating transactions, they need API nodes, seed nodes, database indexes, storage, and hosting.

High performance blockchains demand high performance network architectures with very different requirements from existing blockchains. At a million transactions per second each node is required to achieve 100’s of megabytes per second per connection. This is trivial for large data centers, but inconceivable for home users.

Additionally high performance blockchains consist of heterogeneous nodes running different subsets of the blockchain and will likely prune the transaction history. This is a significant departure from prior blockchain systems where all nodes are identical and have a full history.  

A ***traditional blockchain*** consists of a dynamic set of ***randomly connected nodes*** in a mesh network. They target home users with limited bandwidth and are designed to traverse home routers (NAT) and dynamically add nodes to the network. Our observation is that this architecture is not well suited for high performance blockchain infrastructure.

The ***EOS.IO software*** starts with the assumption that ***all nodes are intentionally connected to each other***. Node operators work together to ensure the network topology is secure, well planned, and efficient. This allows block producers to establish direct (and secure) connections to each other and prevents attackers from scanning the entire network topology looking for nodes to shut down.  

The block producers will host public endpoints which anyone may connect to and subscribe to any subset of transaction data they desire.  This will minimize the bandwidth requirements for full nodes operated by non-block producers.  Nodes that do not want to trust a single block producer may either subscribe to multiple sources or wait for confirmation by ⅔ of the block producers (about 45 seconds). 

The benefit of this architecture is that new nodes can connect and synchronize at very high speeds from high bandwidth infrastructure provided by the block producers. Furthermore, this architecture is designed to facilitate efficient unidirectional streaming rather than less efficient bidirectional protocols. 

**At scale, block producers will be operating a new internet backbone powered by EOS.IO software.** Block producers will be like Tier-1 Internet providers with dedicated fiber optic connections across continents. These producers will operate data centers that Tier-2 subscribers can connect to.  Tier-2 includes anyone looking to run a full or partial node or a large application.  For example, services like block explorers, web wallets,  and crypto-currency exchanges would be Tier-2 subscribers to the block producers. 

We feel this architecture of intentional cooperative network building will enable block producers to offer a quality of service unique in the cryptocurrency industry.  

# The Road Ahead
In September of this year, block.one will be releasing EOS.IO Dawn 1.0 which should be stable enough and well documented enough for anyone to launch their own test network upon which they can build and deploy their applications.  EOS.IO Dawn 1.0 will be the first pre-release of our EOS.IO SDK (Software Development Kit).  

Those who have followed our [EOS.IO Roadmap](https://github.com/EOSIO/Documentation/blob/master/Roadmap.md) will be happy to know that ***we are ahead of schedule***.  Phase 1, The Minimal Viable Testing Environment,  which includes a standalone node, native contracts, virtual machine API, RPC interface, command line tools (eosc), and basic developer documentation is complete. We will be making a tagged release as “EOS.IO Dawn 1.0”.  This phase was scheduled to be complete in Summer 2017 which ends on September 22.  

We have already completed half of **Phase 2, the Minimal Viable Test Network**. This phase is scheduled for completion in Fall 2017 and includes working networking code, virtual machine sandboxing, resource usage and rate limiting, genesis importing, and inter blockchain communication.  At this time we already have functional distributed networks and virtual machine sandboxing.  We are confident that we will complete Phase 2 on schedule.  

EOS.IO Dawn 2.0, the next major pre-release, will come by the end of the year. EOS.IO Dawn 2.0 will include several critical features that are not present in EOS.IO Dawn 1.0 including:

- Resource Rate Limiting (preventing spam / abuse)
- Merkle Tree Generation (for cross chain communication)
- Upgrade Management and Governance
- More robust SDK
- General Infrastructure improvements
- Example Snapshot from ERC20 tokens

The goal of EOS.IO Dawn 2.0 is to be functional enough that one could launch a live blockchain. 

# One More Thing…. 

# EOS.IO Storage! 
For the first time, developers will be able to create and deploy a decentralized application and web interfaces without having to worry about bandwidth and storage costs, or even hosting any servers themselves; this enables a host of new innovative decentralized business models, such as a decentralized YouTube, Soundcloud, or other storage-intensive projects.

In addition to computational bandwidth, **native EOS.IO software-based blockchain token holders will now have access to free cloud storage**, hosting, and download bandwidth via IPFS / HTTPS; this access can be used without consuming or transferring tokens.

To achieve this, block producers will host files via IPFS/HTTPS for users and allow other users to download those files. Storage resources are paid for through blockchain emissions and are rate limited to token holders pro-rata to their holdings; like the EOS.IO bandwidth model, storage does not expend EOS.IO software-based blockchain tokens and per-token storage capacity will increase over time with block producer hardware upgrades.

The EOS.IO software storage solution can also support public hosting for those who don’t have any tokens; more details will be released at upcoming blockchain industry events occurring in Shanghai and London.

# Disclaimer
<i>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.</i>