Executor
Last updated
Last updated
There is where the real transaction processing takes place. Depending on configuration, an Arcology node cluster may have a number of Executor instances running in parallel to process transactions. Each executor comprises the following components
Generalized virtual machine instances called EU
A state snapshot shared by all member EUs
A VM adaptor to bridge VM and the state storage
Like many other key components in Arcology, the executor service supports horizontal scaling. An executor may start an arbitrary number of EUs. However, in general, the number of EUs each executor has shouldn’t exceed the number of processing cores available on the machine. Adding too many EUs in a single executor service may deteriorates overall performance.
Arcology is designed to be VM agonistic. To achieve VM neutrality, all VMs in Arcology are abstracted as EUs(Execution Unit). EU is an abstraction of a state machine dedicated to transaction processing. Different EUs are running in isolation. All state changes happened within EUs won't visible to others during the execution.This design allows multiple heterogenous VM to work on the Arcology, but he adaptor implementation is on a platform-by-platform basis.
An EU consists of the following major parts:
A native VM instance, e.g. EVM
A StateDB adaptor
A cache to record all the state transitions
A read only local snapshot
EVM support has been added to Arcology already for its popularity. Developers can still use the tools and libraries they have on the native platforms and the experience wouldn’t be any different from the original VM. There are some changes made to the original EVM implementation to help it work with Arcology smoothly.
StateDB In the original implementation, EVM access state data through the stateDB interfaces, which are native to Ethereum. We implemented a set of StateDB compatible interfaces to bypass original ones. The new adaptor redirects state accesses to the Arcology state storage instead.
Arcology concurrent programming: Arcology has a library to help with concurrent programming in native solidity. The library provides functions wrapped as native solidity smart contracts deployed at some reserved addresses. Our EVM adaptor intercepts invocations to these special smart contracts and redirect them to the Arcology's handling procedures.
Support for more VM types will be added in the future.
The VM adaptors bridges the gap between native VM and Arcology platform. To work with Arcology, each type of native VM must implement its own StateDB. In many cases, supporting a new VM type only involves in implementing a new state access adaptor and some having abilities to access Arcology’s concurrent library.
During the transaction processing, the stateDB adaptor records all state accesses from VMs and temporarily stored them in the transitions cache. When there is state access attempt, the EU always tries to read the latest states from the transitions cache first. EUs only access the local snapshot if there is a cache miss happened at the EU level.
When an execution is done, the transition cache will export the all the state access records it has collected during execution process and save them is a special data structure called transition set. Eventually, the access records will be sent to the Arbitrator asynchronously for conflict detection.
A transition set is generated when a transaction is executed, which contains the information connecting the state accesses to the transitions. Only the clear transition sets that don't cause any state inconsistency will get persisted in the State DB. The transition cache will be reset by the end of each execution cycle.
Every executor instance comes with a in-memory state snapshot to provide high speed access. The snapshot talks to the storage service only if there is a cache miss. The local state cache updates itself at the end of each blocking cycle.
