Elrond is a new blockchain architecture, designed from scratch to bring a 1000-fold cumulative improvement in throughput and execution speed. To achieve this, Elrond introduces two key innovations: a novel Adaptive State Sharding mechanism, and a Secure Proof of Stake (PoS) algorithm, enabling linear scalability with a fast, efficient, and secure consensus mechanism. Thus, Elrond can process upwards of 10,000 transactions per second (TPS), with 5-second latency, and negligible cost, attempting to become the backbone of a permissionless, borderless, globally accessible internet economy.
Elrond is built by a team of experienced entrepreneurs along with 13 engineers and researchers with significant blockchain backgrounds and technical experience at Microsoft, Google, Intel, and NTT DATA. The team includes two PhDs in CS & AI, multiple math, CS, and AI Olympiad champions, and a former member of the NEM core team.
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 architecture rests on the following key innovations:
- 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
- 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
- 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 a 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
- Secure randomness beacon with BLS signing that makes the randomness source unbiasable and unpredictable, fit to be used as a randomness beacon.
- 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
- 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.
Entities
There are two main entities in Elrond: users and nodes. Users, each holding a (finite) number of public / private (Pk/sk) key pairs (e.g. in one or multiple wallet apps), use the Elrond network to deploy signed transactions for value transfers or smart contracts’ execution. They can be identified by one of their account addresses (derived from the public key).
The nodes are represented by the devices that form the Elrond network and can be passive or actively engaged in processing tasks. Eligible validators are active participants in Elrond’s network. Specifically, they are responsible for running consensus, adding blocks, maintaining the state and being rewarded for their contribution. Each eligible validator can be uniquely identified by a public key constructed through a derivation of the address that staked the necessary amount and the node id. Relations between entities in the Elrond protocol are shown in the figure below.
Secure Proof of Stake
We introduce our Secure Proof of Stake consensus mechanism, that expands on Algorand’s idea of a random selection mechanism, differentiating itself through the following aspects:
- Elrond introduces an improvement which reduces the latency allowing each node in the shard to determine the members of the consensus group (block proposer and validators) at the beginning of a round. This is possible because the randomization factor r is stored in every block and is created by the block proposer using a BLS signature on the previous r.
- The block proposer is the validator in the consensus group who’s hash of the public key and randomization factor is the smallest. In contrast to Algorand’s approach, where the random committee selection can take up to 12 seconds, in Elrond the time necessary for random selection of the consensus group is considerably reduced (estimated under 100 ms) excluding network latency. Indeed, there is no communication requirement for this random selection process, which enables Elrond to have a newly and randomly selected group that succeeds in committing a new block to the ledger in each round. The tradeoff for this enhancement relies on the premise that an adversary cannot adapt faster than the round’s time frame and can choose not to propose the block. A further improvement on the security of the randomness source, would be the use of verifiable delay functions (VDFs) in order to prevent any tampering possibilities of the randomness source until it is too late. Currently, the research in VDFs is still ongoing — there only a few working (and poorly tested) VDF implementations.
- In addition to the stake factor generally used in PoS architectures as a sole decision input, Elrond refines its consensus mechanism by adding an additional weight factor called rating. The node’s probability to be selected in the consensus group takes into consideration both stake and rating. The rating of a block proposer is recalculated at the end of each epoch, except in cases where slashing should occur, when the actual rating decrease is done instantly, adding another layer of security by promoting meritocracy.
- A modified BLS multisignature scheme with 2 communication rounds is used by the consensus group for block signing
- Elrond considers formal verification for the critical protocol implementations (e.g. SPoS consensus mechanism) in order to validate the correctness of our algorithms.
An illustration of Elrond’s latest implementation of Secure Proof of Stake is depicted in the figure below:
Adaptive State Sharding
Sharding was first used in databases and is a method for distributing data across multiple machines. This scaling technique can be used in blockchains to partition states and transaction processing, so that each node would process only a fraction of all transactions in parallel with other nodes. As long as there is a sufficient number of nodes verifying each transaction so that the system maintains high reliability and security, then splitting a blockchain into shards will allow it to process many transactions in parallel, and thus greatly improving transaction throughput and efficiency. Sharding promises to increase the throughput as the validator network expands, a property that is referred to as horizontal scaling.
Sharding types
We emphasizes the three main types of sharding: network sharding, transaction sharding and state sharding. Network sharding handles the way the nodes are grouped into shards and can be used to optimize communication, as message propagation inside a shard can be done much faster than propagation to the entire network. This is the first challenge in every sharding approach and the mechanism that maps nodes to shards has to take into consideration the possible attacks from an attacker that gains control over a specific shard. Transaction sharding handles the way the transactions are mapped to the shards where they will be processed. In an account-based system, the transactions could be assigned to shards based on the sender’s address.
State sharding is the most challenging approach. In contrast to the previously described sharding mechanisms, where all nodes store the entire state, in state-sharded blockchains, each shard maintains only a portion of the state. Every transaction handling accounts that are in different shards, would need to exchange messages and update states in different shards. In order to increase resiliency to malicious attacks, the nodes in the shards have to be reshuffled from time to time. However, moving nodes between shards introduces synchronization overheads, that is, the time taken for the newly added nodes to download the latest state. Thus, it is imperative that only a subset of all nodes should be redistributed during each epoch, to prevent down times during the synchronization process.
Sharding directions
Some sharding proposals attempt to only shard transactions or only shard state, which increases transaction’s throughput, either by forcing every node to store lots of state data or to be a supercomputer. Still, more recently, at least one claim has been made about successfully performing both transaction and state sharding, without compromising on storage or processing power.
But sharding introduces some new challenges like: single-shard takeover attack, cross-shard communication, data availability and the need of an abstraction layer that hides the shards. However, conditional on the fact that the above problems are addressed correctly, state sharding brings considerable overall improvements: transaction throughput will increase significantly due to parallel transaction processing and transaction fees will be considerably reduced. Two main criterias widely considered to be obstacles transforming into advantages and incentives for mainstream adoption of the blockchain technology.
Elrond sharding approach
While dealing with the complexity of combining network, transaction and state sharding, Elrond’s approach was designed with the following goals in mind:
- Scalability without affecting availability: Increasing or decreasing the number of shards should affect a negligibly small vicinity of nodes without causing down-times, or minimizing them while updating states;
- Dispatching and instant traceability: Finding out the destination shard of a transaction should be deterministic, trivial to calculate, eliminating the need for communication rounds;
- Efficiency and adaptability: The shards should be as balanced as possible at any given time.
An illustration of Elrond’s Adaptive State Sharding approach is depicted in the figure below:
Chronology and node reshuffling
Proof of Stake systems tend to generally divide timeline into epochs and each epoch into smaller rounds. The timeline and terminology may differ between architectures but most of them use a similar approach.
Rounds
Each round has a fixed time duration of 5 seconds (might suffer updates after several testnet confirmation stages). During each round, a new block can be produced within every shard by a randomly selected set of block validators (including one block proposer). From one round to another the set is changed using the eligible nodes list.
Epochs
In Elrond, each epoch has a fixed duration, initially set to 24 hours (might suffer updates after several testnet confirmation stages). During this timeframe, the configuration of the shards remains unchanged. The system adapts to scalability demands between epochs by modifying the number of shards. To prevent collusion, after an epoch, the configuration of each shard needs to change. While reshuffling all nodes between shards would provide the highest security level, it would affect the system’s liveness by introducing additional latency due to bootstrapping. For this reason, at the end of each epoch, less than ⅓ of the eligible validators, belonging to a shard will be redistributed non-deterministically and uniformly to the other shards’ waiting lists.
Only prior to the start of a new epoch, the validator distribution to shards can be determined, without additional communication as displayed in the figure below:
The node shuffling process runs in multiple steps:
- The new nodes registered in the current epoch ei land in the unassigned node pool until the end of the current epoch;
- Less than ⅓ of the nodes in every shard are randomly selected to be reshuffled and are added to the assigned node pool;
- The new number of shards Nsh,i+1 is computed based on the number of nodes in the network ki and network usage;
- Nodes previously in all shard’s waiting lists, that are currently synchronized, are added to the eligible validator’s lists;
- The newly added nodes from the unassigned node pool are uniformly random distributed across all shards’ waiting lists during epoch ei+1;
- The reshuffled nodes from the assigned node pool are redistributed with higher ratios to shards’ waiting lists that will need to split in the next epoch ei+2.
As described before, the reconfiguration of shards within epochs and the arbitrary selection of validators within rounds discourages the creation of unfair coalitions, diminishes the possibility of DDoS and bribery attacks while maintaining decentralization and a high transactions throughput.
Cross-shard transactions
For an in depth example of how the cross-shard transactions are being executed and how the communication between shards and the metachain occurs, we are simplifying the entire process to just two shards and the metachain. Assuming that a user generates a transaction from his wallet, which has an address in shard 0 and wants to send ERDs to another user that has a wallet with an address in shard 1, the steps depicted in the figure below are required for processing the cross-shard transaction.
The block’s structure is represented by a block Header that contains information about the block (block nonce, round, proposer, validators timestamp etc), and a list of miniblocks for each shard that contain the actual transactions inside. Every miniblock contains all transactions that have either the sender in the current shard and the receiver in another shard or the sender in a different shard and the destination in the current shard. In our case, for a block in shard 0, there will normally be 3 miniblocks:
- miniblock 0: containing the intrashard transactions for shard 0
- miniblock 1: containing cross-shard transactions with the sender in shard 0 and destination in shard 1
- miniblock 2: containing cross-shard transactions with sender in shard 1 and destination in shard 0. These transactions were already processed in the sender shard 1 and will be finalized after the processing in the current shard.
There is no limitation on the number of miniblocks with the same sender and receiver in one block. Meaning multiple miniblocks with the same sender and receiver can appear in the same block.
Processing
Currently the atomic unit of processing in cross-shard execution is a miniblock: either all the transactions of the miniblock are processed at once or none and the miniblock’s execution will be retried in the next round.
Our cross-shard transaction strategy uses an asynchronous model. Validation and processing is done first in sender’s shard and then in receivers’ shard. Transactions are first dispatched in the sender’s shard, as it can fully validate any transaction initiated from the account in this shard — mainly the current balance. Afterwards, in the receivers’ shard, the nodes only need proof of execution offered by metachain, do signature verification and check for replay attack and finally update the balance for the receiver, adding the amount from the transaction.
Shard 0 processes both intra-shard transactions in miniblock 0 and a set of cross-shard transactions that have addresses from shard 1 as a receiver in miniblock 1. The block header and miniblocks are sent to the metachain. The metachain notarizes the block from shard 0, by creating a new metachain block (metablock) that contains the following information about each miniblock: sender shard ID, receiver shard ID, miniblock hash.
Shard 1 fetches the hash of miniblock 1 from metablock, requests the miniblock from shard 0, parses the transaction list, requests missing transactions (if any), executes the same miniblock 1 in shard 1 and sends to the metachain resulting block. After notarization the cross transaction set can be considered finalized.
The next diagram shows the number of rounds required for a transaction to be finalized. The rounds are considered between the first inclusion in a miniblock until the last miniblock is notarised.
“Both Matic and Elrond share the same core vision of facilitating the widespread mainstream adoption of blockchain. As two of the most promising performance-focused platforms on the market, together we can provide the superior blockchain infrastructure required for the acceleration of the decentralized movement. Matic is honored to be working shoulder-to-shoulder with Elrond to make the decentralized future a reality sooner.“
–Jaynti Kanani — Matic Network CEO
Elrond VM
Elrond builds its VM infrastructure on top of the K Framework, which is an executable semantic framework where programming languages, calculi, as well as type systems or formal analysis tools can be defined. K Framework has the possibility to generate interpreters that are correct-by-construction for any language defined in K. These interpreters can be generated in several programming languages, via components called K Framework “backends”. The smart contract interpreters in Elrond are generated via a Go backend. The generated interpreters are made available in the project elrond-vm, so that users can compile straight away, without the need to generate the sources first.
Additionally to the generated interpreters, the elrond-vm project also contains adapter code for the interaction with the blockchain and tests. Because Elrond supports multiple VMs, there is one VM adapter interface that is implemented by all Elrond VMs. This interface resides in project elrond-vm-common.
Supported VMs and languages
In principle any smart contract language formalized in K can become a smart contract language in Elrond. In practice, low level languages are preferred for direct support, so that the gas model is easier to map to the more atomic instructions. Higher level languages, such as Solidity are used indirectly, via a compiler that converts the high-level code into lower-level code.
There are several intermediate-level smart contract languages specified in the K Framework already, or with their specifications under development.
1. IELE VM
The first SC language supported by Elrond is IELE VM, which is an intermediate-level language, in the style of LLVM, created for the blockchain.
It was built directly in K, no other specification or implementation of it exists outside of the K framework. Its purpose is to be human readable, fast, and to overcome some limitations of EVM.
Elrond uses a slightly altered version of IELE. The changes from the original version of IELE are:
- Addresses in Elrond are 32 bytes wide, instead of the Ethereum-style 20 bytes.
- Smart contract addresses in Elrond start with 10 bytes of zeros.
- The last 2 bytes of each address indicate in which shard the account will land. When creating a new smart contract, the last 2 bytes of the smart contract address are copied from the creator, in order for the smart contract to always land in the same shard as its creator. This leaves 20 bytes for
- New smart contract accounts start with nonce 0 instead of 1.
- In the original version an account with both balance and nonce zero is considered not to exist. In Elrond, the node tells the VM which accounts exist and a smart contract with both balance and nonce 0 is possible.
Smart contract developers can program in IELE directly, but most will choose to code in Solidity and then use a Solidity to IELE compiler, as can be seen in the figure below:
Just like there are a few changes in IELE, the Solidity compiler also needed to be forked, to accommodate 32 byte addresses. This fork can be found at github.com/ElrondNetwork/solidity
Please note that this version of the compiler is still in testing mode.
2. KEVM
KEVM is a version of the Ethereum Virtual Machine(EVM), written in K. Certain vulnerabilities of EVM are fixed in the K version, or left out entirely.
The integration of KEVM is currently work in progress.
3. WASM
Web Assembly (WASM) is a binary instruction format for a stack-based virtual machine, which can be used for running smart contracts. A WASM infrastructure enables developers to write smart contracts in C/C++, Rust, C#, and others.
The integration of WASM is currently work in progress.
If you think my article is useful, please applaud. Thanks.
For more information, please visit us:
