EOS whitepaper walk-through: Parallel execution of applications, Read-Only Action Handlers, Atomic Transactions and Partial Evaluation of Blockchain State.
Read the Whitepaper here
Last time we took a board overview of how EOS plans to allow deterministic applications to be evaluated in parallel.
In this article we'll take a look at how the data structure allows for this.
Read-Only Action Handlers
Some accounts may be able to process an Action on a pass/fail basis without modifying their internal state. If this is the case, then these handlers can be executed in parallel so long as only read-only Action handlers for a particular account are included in one or more shards within a particular cycle.
Read-Only Action Handlers reads a piece of information from an account in order to determine whether or not an Action is to be performed. Because this Action does not modify any data on accounts, it can be included in one or more shards during a cycle.
Atomic Transactions with Multiple Accounts
Sometimes it is desirable to ensure that Actions are delivered to and accepted by multiple accounts atomically. In this case both Actions are placed in one transaction and both accounts will be assigned the same shard and the Actions applied sequentially.
Actions that sent out to multiple accounts can be processed simultaneously. Since the Action only affects one data-region of each account, it can be included in a single transaction, which is applied to accounts across shards that process the transaction in different account in parallel.
Partial Evaluation of Blockchain State
Scaling blockchain technology necessitates that components are modular. Everyone should not have to run everything, especially if they only need to use a small subset of the applications.
An exchange application developer runs full nodes for the purpose of displaying the exchange state to its users. This exchange application has no need for the state associated with social media applications. EOS.IO software allows any full node to pick any subset of applications to run. Actions delivered to other applications are safely ignored if your application never depends upon the state of another contract.
Currently, if one wants to run a Ethereum exchange, he or she must have the entire Ethereum blockchain downloaded in his or her node and apply each and every block update as they come in. This is a vast amount of data to store and process.
This means that if an Ethereum-based social network is operating, they must also down the social media data along with the account transaction history.
With EOS it is possible to selective choose which subset of data the node will keep and update, without having to download everything.
------------------------------------------------------------------------------------------------------------------
If you would like to know more about me and what I'm doing you can read my introduction post here.
Read my series on the Steem blockchain:
Steem: Welcome to the Matrix. Part One
Steem: Operating in the Matrix. Part Two
Steem: Construction of the Matrix. Part Three
Read my series on the EOS blockchain:
EOS whitepaper walk-through. Abstract
EOS whitepaper walk-through. Note and Disclaimer
EOS whitepaper walk-through. Overview
EOS whitepaper walk-through. Background
EOS whitepaper walk-through. Requirement.
EOS whitepaper walk-through. Consensus Algorithm. Part One, Part Two, Part Three.
EOS whitepaper walk-through. Account construct of EOS. Part One, Part Two, Part Three, Part Four.
And you can contact me in the following way:
@bluabaleno on Steem.chat