Technical Components

From a more technical perspective, the entire solution was built having a plug-and-play architecture in mind. The solution contains multiple modules, each one following the single-responsibility principle, being isolated from the rest of the system using interfaces that ensure decoupling and flexibility. The main modules are outlined as follows:

a) Communication layer

Represents the P2P network that provides the infrastructure needed for the following operations: direct messaging, information broadcast and channel communication.

The P2P module ensures the following core services:

P2PConnectionService ensures the node connectivity and discovery

ensures the node connectivity and discovery P2PObjectService provides primitives that split the operations to send and retrieve objects over networks

provides primitives that split the operations to send and retrieve objects over networks P2PBroadcastService contains broadcast channels used to send blocks, transactions, and receipts intra- or inter-shard

contains broadcast channels used to send blocks, transactions, and receipts intra- or inter-shard P2PRequestService implements a mechanism to request missing information

b) Cryptographic layer

Deals with signing and verification for transactions with Schnorr scheme and Bellare and Neven’s multi-signature method for blocks.

The cryptographic layer provides these services:

ECCryptoService gives information about the chosen curve for EC cryptography

gives information about the chosen curve for EC cryptography SignatureService provides the primitives to sign a message and verify the signature

provides the primitives to sign a message and verify the signature MultiSignatureService provides primitives to perform multi-signing and verify a multi-signature.

c) Blockchain Core

Is the backbone data model used to store blocks, transactions, accounts and any additional information needed for the distributed ledger.

The blockchain module exposes the following sub components:

BlockchainService implements all the operations required to handle block manipulation

implements all the operations required to handle block manipulation AppPersistenceService allows temporary and persistent storage of blocks

allows temporary and persistent storage of blocks TransactionsPool has as its main purpose to buffer new transactions until they are ready to be assembled inside a block

has as its main purpose to buffer new transactions until they are ready to be assembled inside a block Blockchain abstracts the blockchain structure and decouples the data model from the access medium.

d) Execution Engine

Represents the most essential part of the architecture. This processes transactions and assembles blocks while replicating the state across the network to ensure consistency and security.

The execution engine is encapsulated in two services:

ExecutionService executes blocks and transactions and updates the application state

executes blocks and transactions and updates the application state BootstrapService ensures that a node is synchronized with the rest of the network

e) Chronology

For a synchronization and time-passing perspective, we are using an NTP (Network Time Protocol) service, currently synchronized with public servers worldwide. The time is fragmented into rounds and sub-rounds, ensuring a well structured bootstrapping process and proper timeouts.

The chronology module houses ChronologyService. This service provides primitives for world clock synchronization and different round time computations.

f) Consensus Protocol

Currently, working as a delegated proof of stake variant in a round-robin scenario, allowing everyone to take turns in either proposing or validating blocks. The consensus protocol runs independently on each shard. Note that our secure proof of stake consensus will substitute this temporary version in the next release.

The consensus module provides the following services:

ConsensusService : provides methods for consensus computation within the list of validators

: provides methods for consensus computation within the list of validators SPoSService : provides the means necessary to compute the list of validators and block proposer for the current round

: provides the means necessary to compute the list of validators and block proposer for the current round ValidatorService: provides methods to compute fitness (stake and rating) for the nodes in the eligible nodes list

g) Sharding Mechanism

Using an initial state sharding version that allows intra-shard and cross-shard transactions using communication channels. According to the formulas mentioned in the white-paper, initially, each shard gets a subset from the wallet address space.

The sharding communication part is integrated into the P2P module.

Additionally, it provides the following: