Architecture overview

Elrond is a high-throughput public blockchain aimed at providing security, efficiency, scalability and interoperability, beyond the current state-of-the-art. The two most important features that set Elrond apart are Adaptive State Sharding and a Secure Proof of Stake consensus mechanism.

Elrond is a complete redesign of blockchain architecture with the aim to achieve global scalability and near instant transaction speed. Elrond's architecture rests on the following key innovations:

  1. Adaptive state sharding (transaction, data & network sharding) with a dynamically adaptive mechanism for shard merges and shard splits that takes into consideration both the available nodes/validators but also the network usage

  2. Secure Proof of Stake Consensus in just two communication rounds with modified Boneh–Lynn–Shacham ("BLS") multi-signatures among the randomly sampled validators of the consensus group

  3. High resiliency to malicious attacks due to intra and cross shard node reshuffling. Nodes inside the shard are randomly selected in the consensus group without the possibility of knowing the members more than one round in advance. Every epoch up to 1/3 of the nodes in every shard are reshuffled to other shards in order to prevent collusion

  4. Secure randomness beacon with BLS signing that makes the randomness source unbiasable and unpredictable, fit to be used as a randomness beacon.

  5. Smart contracts on a state sharded architecture with balanced load on shards is a requirement for a high-throughput blockchain platform. Balancing smart contracts in shards allows Elrond to run multiple SCs in parallel, while the cross-shard calls are handled through an asynchronous cross-shard execution model

  6. Fast finality for cross shard transactions (seconds). Not just the very high TPS is required for a high throughput blockchain solution, but also fast finality for the cross-shard transactions. This is affected by the dispatching algorithm (when the decision is made) and the routing protocol (where should the transaction be executed). Most of the existing state of the art architectures refuse to mention this aspect but from a user standpoint this is extremely important.