EOS whitepaper walk-through: Scripts and Virtual Machines.
Read the Whitepaper here
Scripts & Virtual Machines
The EOS.IO software will be first and foremost a platform for coordinating the delivery of authenticated messages (called Actions) to accounts. The details of scripting language and virtual machine are implementation specific details that are mostly independent from the design of the EOS.IO technology. Any language or virtual machine that is deterministic and properly sandboxed with sufficient performance can be integrated with the EOS.IO software API.
The core innovation of blockchain technology is that of the authenticated message and distributed record of sent messages. This invention, based on cryptographic signatures ensures that no one but the owner of the private key can send an authenticated message with his or her key.
EOS recognizes this abstracts the blockchain layer from the computation and governance layer. Any deterministic programming language can be integrated with EOS.IO technology, turing complete or not.
This opens up possibilities for developers to experiment with various combination of programming languages, consensus algorithms, and governance model in their implementation of the EOS.IO technology.
Schema Defined Actions
All Actions sent between accounts are defined by a schema which is part of the blockchain consensus state. This schema allows seamless conversion between binary and JSON representation of the Actions.
Another way of stating this is that EOS actions have similar structures that are recognized, executed, and recorded on the blockchain.
Schema Defined Database
Database state is also defined using a similar schema. This ensures that all data stored by all applications is in a format that can be interpreted as human readable JSON but stored and manipulated with the efficiency of binary.
Defining a standard database schema that is human readable.
Generic Multi Index Database API
Developing smart contracts requires a defined database schema to track, store, and find data. Developers commonly need the same data sorted or indexed by multiple fields and to maintain consistency among all the indices.
This is sometimes called ABI or application Binary Interface.
Separating Authentication from Application
To maximize parallelization opportunities and minimize the computational debt associated with regenerating application state from the transaction log, EOS.IO software separates validation logic into three sections:
Validating that an Action is internally consistent;Validating that all preconditions are valid; andModifying the application state.
Validating the internal consistency of a Action is read-only and requires no access to blockchain state. This means that it can be performed with maximum parallelism. Validating preconditions, such as required balance, is read-only and therefore can also benefit from parallelism. Only modification of application state requires write access and must be processed sequentially for each application.
The EOS blockchain is designed to able to run parallel execution whenever it can. When an Action is received, its internal state is checked. This validation of internal consistency does not require access to the current blockchain state, so it can be ran in parallel.
Action that are not internally consistent are rejected and Actions that are internally consistent moves to the next cycle of computation.
Actions at this next stage might require access to the current state of the blockchain, this is a read-only action and can be processed in parallel, as no changes to the state is made at this point.
Only in this last stage, where actions want to modify account data on the blockchain, which cannot be perform in parallel, since parallelization breaks deterministic behavior, are ran in sequential steps.
Authentication is the read-only process of verifying that an Action can be applied. Application is actually doing the work. In real time both calculations are required to be performed, however once a transaction is included in the blockchain it is no longer necessary to perform the authentication operations.
Authentication, or the verification of signatures, does not depend upon the blockchain state, and can be evaluated in parallel.
Once a transaction is validated and included in the broadcast block, there is no need to validate the message again during replays. This allows anyone setting up a full nodes to run and catch up to the current network.
Useful links:
------------------------------------------------------------------------------------------------------------------
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.
EOS whitepapre walk-through. Parallel execution of applications. Part One, Part Two, Part Three, Part Four, Part Five.
EOS whitepaper walk-through. Token model and resource usage. Part One, Part Two.
EOS whitepaper walk-through. Governance.
And you can contact me in the following way:
@bluabaleno on Steem.chat