In the EOS.IO Technical White Paper, 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
Warning! This user is on my black list, likely as a known plagiarist, spammer or ID thief. Please be cautious with this post!
To get off this list, please chat with us in the #steemitabuse-appeals channel in steemit.chat.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit