At a high conceptual level, the architecture consists of two layers.
The lower-level layer is a generic distributed key-value data store providing ACID database transactional properties. This data store is generic as it does not impose constraints on the type or the size of the data it handles, and is agnostic to its client execution layer. The end user does not directly interact with this layer. The implementation consists of a set of shard instances, where each instance is Raft-replicated for resilience. Data is horizontally partitioned among this set of replicated shard units - i.e. each replicated shard unit holds its own distinct subset of the full data set.
The higher level computation layer executes programs (i.e. smart contracts) and uses the lower-level key-value data store to maintain its state. The Agent is the main interface for this layer and serves the role of a transaction coordinator. This computation layer contains implementations of the Runner interface which is an abstraction for retrieving and executing context-specific bytecode. The system provides two Runner implementations (EVM and Lua) and demonstrates the flexibility of the architecture to support different program execution environments.
In contrast to the UHS-based architectures (Atomizer & 2PC), this design does not dictate a particular data model or transactional semantics. The generic computation layer allows flexibility to employ a wide range of designs with minimal changes to this underlying C++ system. Smart contracts can be deployed and re-defined, thus making it possible to make fundamental changes to the system during runtime.
This architecture enables parallel execution of generic smart contracts (where keys are independent). Therefore transaction throughput is horizontally scalable with additional server resources. For example, in contrast to the Ethereum blockchain, this system executes native value transfers and smart contract transactions (e.g. ERC20 token transfers) in parallel for independent addresses.
The Agent is the main interface for the computation layer and serves the role of a transaction coordinator. An Agent is instantiated for each new transaction, managing the transaction's lifecycle by interacting with both the Runner and the data store (via the Broker)
The Broker is the interface component for both the external Shards and the Ticket Machine. The Broker's primary role is to abstract the external set of distributed Shards as a single logical database unit, providing functions such as begin(), commit(), finish() and rollback(). The Broker is also the interface for the Ticket Machine for the Agent.
The Directory identifies the target Shard unit for each and every key-value data pair. This is a detail managed by the Broker, allowing the end-client (the Agent) to interact with the distributed Shards as a single database unit. The Directory is where the sharding logic is defined and its implementation can be designed to optimize database resources for particular use cases.
The JSON-RPC Server implements the Ethereum JSON-RPC API over HTTP. This is the external interface compatible for external Ethereum clients such as wallets (e.g. Metamask), and development tools (e.g. Hardhat, Truffle, ethers.js, web3.js)
The Runner is an abstraction for retrieving and executing context-specific bytecode. The system provides two Runner implementations (EVM and Lua) and demonstrates the flexibility of the architecture to support different program execution environments.
The lower-level data store layer implementation consists of a set of Shard instances, where each instance is Raft-replicated for resilience. Data is horizontally partitioned among this set of replicated Shard units - i.e. each replicated Shard unit holds its own distinct subset of the full data set.
The Ticket Machine is tasked with providing the system with Ticket Numbers which are a sequence of unique and increasing whole numbers. Each transaction is assigned its own unique new Ticket Number. The value of the Ticket Number conveys the relative age of the transaction which is used for database concurrency control and deadlock resolution.