EOS whitepaper walk-through: Parallel execution of Applications, Best effort Scheduling.
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 talk about how block-produces can decide on which transactions to process and which to ignore.
Subjective Best Effort Scheduling
The EOS.IO software cannot obligate block producers to deliver any Action to any other account. Each block producer makes their own subjective measurement of the computational complexity and time required to process a transaction. This applies whether a transaction is generated by a user or automatically by a smart contract.
This is a big break from Ethereum. Whereas Ethereum calculates the computational cost beforehand, EOS bills the cost of computation depending on the capacity and availability of the network.
In other words, if you have paid enough requisite in Ethereum gas, you can be sure your application will run just fine. Whereas in EOS, the cost to run your application depends on how busy the network is. If you have staked enough tokens, you can be sure of some level of performance, or maybe even exceed the allocated computational capacity if the network is not busy. But you'll be restricted to only what you've paid for if the network is at maximum capacity.
This is an interesting model because it is similar to Ethereum in the sense that there is no fixed cost to run an application, and how much you pay depends on how busy the network is.
The difference is, in EOS, if you've staked tokens, you can ensure at least some base-line level performance.
update: EOS now combines a objective (computation instruction count) with a subjective (range of acceptable computation duration) measure for the cost.
On a launched blockchain adopting the EOS.IO software, at a network level all transactions are billed a computational bandwidth cost based on the number of WASM instructions executed. However, each individual block producer using the software may calculate resource usage using their own algorithm and measurements. When a block producer concludes that a transaction or account has consumed a disproportionate amount of the computational capacity they simply reject the transaction when producing their own block; however, they will still process the transaction if other block producers consider it valid.
Although each block producer, when it is their turn to produce a block, can determine whether or not to include a transaction, if other producer decides to include the same transaction they've rejected, they will still have to process it.
This forces every block producer to come to consensus and establish a base-line to determine which transactions are too computational intensive to perform and which ones are within the agreed limit to process. This effectively pushes block producers to establish a price for duration of execution, or the expected price for certain amount of computational time.
In general, so long as even 1 block producer considers a transaction as valid and under the resource usage limits then all other block producers will also accept it, but it may take up to 1 minute for the transaction to find that producer.
In some cases, a producer may create a block that includes transactions that are an order of magnitude outside of acceptable ranges. In this case the next block producer may opt to reject the block and the tie will be broken by the third producer. This is no different than what would happen if a large block caused network propagation delays. The community would notice a pattern of abuse and eventually remove votes from the rogue producer.
Given that block producers with more resources can process blocks of much larger size, they might use this to price out their competitors or to cause a delay in the network. However, he would have to convince the rest of the 20 block producers to adopt his pricing. Other producers, noticing the malicious intention of this block producer is likely to ask their voters to vote out the malicious block producer and return block to a manageable size, returning the network to normal operation.
This subjective evaluation of computational cost frees the blockchain from having to precisely and deterministically measure how long something takes to run. With this design there is no need to precisely count instructions which dramatically increases opportunities for optimization without breaking consensus.
In Ethereum, the instruction count determines the cost of running the application. This forces application developers to focus a lot of resources towards optimization. Optimizing code is an expensive exercise, because each time code is changed, the optimizing must be done again, leaving little time for experimentation.
In EOS this optimizing process is shifted from developers to block producers. This free developers to change code more frequently while maintaining a certain level of confidence that the change will not dramatically alter the cost structure of the application.
------------------------------------------------------------------------------------------------------------------
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
bitadco@gmail.com