Elrond is especially designed to bring a 1000x overall improvement by being scalable, efficient and secure while maintaining a sufficiently decentralized setting.
To achieve this we introduce a novel Adaptive State Sharding mechanism, enabling linear scalability as more nodes join the network by parallelizing transaction processing.
The first blockchain consensus algorithm based on Proof of Work (PoW) is used in Bitcoin, Ethereum and other blockchain platforms. In Proof of Work each node is required to solve a mathematical puzzle (hard to calculate but easy to verify). The first node that finishes the puzzle will collect the reward. Proof of Work mechanisms successfully prevent double-spending, DDoS and Sybil attacks at the cost of high energy consumption.
Proof of Stake (PoS) is a novel and more efficient consensus mechanism proposed as an alternative to the intensive energy and computational use in Proof of Work consensus mechanisms.
Elrond’s approach to consensus is made by combining random validators selection, eligibility through stake and rating, with an optimal dimension for the consensus group. We call this Secure Proof of Stake (SPoS).
Elrond is built to ensure resistance to known security problems like Sybil attack, Rogue-key attack, Nothing at Stake attack and others. We are achieving this by combining the following aspects:
The source of randomness is composed of the last block's aggregated signature and the round’s number. Being a collective signature, each node that participates in the process alters the final signature data. Even if the block proposer can control which transactions will be included in a block, the signature cannot be influenced in a predictable way. This is because the aggregated signature is created by multiple parties.
After each epoch, a third of the nodes from each shard are redistributed uniformly and non-deterministically across the other shards, to prevent collusion. This method adds bootstrapping time for the nodes that were redistributed, but the pruning mechanism will decrease this time to a feasible amount.
After each round a new set of validators are selected using last committed block’s signature, current round and the eligible nodes list. In case of network desynchronization due to the delays in message propagation, the protocol has a recovery mechanism the same members will be chosen, based on the signature of the last block, but with a different block proposer that variates with the round r. This avoids forking and allows synchronization on last block. The small time window (round time) in which the validators group is known, minimizes the attack vectors.
Beside stake, the node’s rating influences the chances to be selected as part of the consensus group. If the block proposer is honest and its block gets committed in the blockchain, it will have its rating increased, otherwise, it’s rating will be decreased. This way, each possible validator is incentivized to be honest, run the most up-to-date client software version, increase its service availability and thus ensuring the network functions as designed.
The nodes that were distributed in sibling shards on the tree’s lowest level keep track of each other’s blockchain data and application state. By introducing the concept of shard redundancy, when the number of nodes in the network decreases, some of the sibling shards will need to be merged. The targeted nodes will instantly initiate the process of shard merging.
Elrond assumes a byzantine adversarial model, where at least ⅔ +1 of the eligible nodes are honest (untampered code, synchronized). The protocol permits the existence of adversaries that have stake or good rating, delay or send conflicting messages, compromise other nodes, have bugs or collude among themselves, but as long as 2/3 +1 of the nodes eligible validators in a shard are honest/not compromised, the protocol can achieve consensus.
The protocol assumes highly adaptive adversaries, which however cannot adapt faster than a round’s timeframe. The computational power of an adversary is bounded, therefore the cryptographic assumptions granted by the security level of the chosen primitives hold firmly within the complexity class of problems solvable by a Turing machine in polynomial time.
The network of honest nodes is assumed to form a well connected graph and the propagation of their messages is done in a bounded time ∆.
1) Sybil attacks: mitigated through the stake locking when joining the network. This way the generation of new identities has a cost equal to the minimum stake;
2) Nothing at stake: removed through the need of multiple signatures, not just the proposer one, and the stake slashing, if a consensus group tries to append blocks on different forks. The reward per block compared to the stake locked will discourage such behavior;
3) Long range attacks: mitigated by our pruning mechanism and the use of a randomly selected consensus group every round (and not just a single proposer);
4) DDoS attacks: the consensus group is randomly sampled every round (few seconds) so a time to DDoS is almost impossible. We are implementing a built-in filtering mechanism for duplicate or malicious messages.
Other attack vectors we have taken into consideration are: single shard takeover attack, transaction censorship, double spend, bribery attacks, etc.
The Elrond Virtual Machine’s implementation will hide the underlying architecture isolating the smart contract developers from system internals ensuring a proper abstraction layer.
In Elrond, cross chain interoperability can be implemented by using an adapter mechanism at the Virtual Machine level. This approach requires specialized adapters for each chain that is non EVM compatible and wants to operate with Elrond.
Compared to Ethereum, Elrond eliminates both energy and computational waste from PoW algorithms by implementing a SPoS consensus while using transaction processing parallelism through sharding.
Compared to Algorand, Elrond doesn’t have a single blockchain, instead it increases transaction’s throughput using sharding. Elrond also improves on Algorand’s idea of random selection by reducing the selection time of the consensus group from max 12 seconds to less than a second, but assumes that the adversaries cannot adapt within a round.
Compared to Zilliqa, Elrond pushes the limits of sharding by using not only transaction sharding but also state sharding. Elrond completely eliminates the PoW mechanism and uses SPoS for consensus. Both architectures are building their own smart contract engine, but Elrond aims for EVM compliance to achieve interoperability between blockchains.
Adaptive State Sharding
The optimal approach for blockchain sharding, needs to take into consideration advantages from all three sharding types (network/communication, transaction/processing, state/storage). Elrond’s approach to scalability and increased throughput, called “Adaptive State Sharding”, combines all three sharding types into a solution that will improve communication inside the shards, increase performance through parallel processing, reduce storage and scale almost linearly.
Allowing the number of shards to change dynamically according to the available resources (validator nodes) and network usage has a huge impact not only on the throughput, but also on efficiency. Our adaptive state sharding mechanism is based on a binary tree structure, once the number of shards has been computed; this number is used for a deterministic mapping of account addresses to shards. Transaction dispatching in shards is done also deterministically through the mapping of the sender and receiver account addresses to the designated shards. The almost linear scalability of our solution provides the backbone for surpassing the throughput of centralized counterparts
Secure Proof of Stake
Elrond has proposed a novel approach to consensus called “Secure Proof of Stake” combining eligibility through stake and rating, random validator selection and an optimal dimension for the consensus group.
The consensus protocol starts by randomly sampling a smaller consensus group out of all eligible validators in the shard (for reduced communication) using a randomness source derived from the previous block’s signature. The randomness source is unpredictable before the signing of the previous block. The sampling is deterministic, meaning that every node can compute the list of validators in the consensus group and the first node to be selected is the block proposer.
The block proposer aggregates transactions into a new block and sends this block to the validators in the consensus group for verification. Each validator will verify the validity of the block, process the transactions and if everything checks out will participate in the pBFT consensus. The voting in the pBFT is done for every validator by sending a signature for a multisignature scheme. If the proposer collects more than 2/3 + 1 signatures from the consensus group members, the block is considered validated, the aggregated signature can be added to the block and the block disseminated in the entire shard. The next consensus group will be randomly sampled using the new signature.
The idea of decentralization and genuine blockchain interoperability are very close related to each other. Currently most of the interconnection and interoperability between different blockchains are conducted through exchanges and third party trading platforms. This defeats the purpose of blockchains not having third parties, while deteriorating the seamless and secured course of transactions’ processing. There is no “one protocol to rule them all” that will be adopted by all other blockchains, but Elrond’s approach will narrow the gap between most important blockchains.
In the first step, we target Ethereum Virtual Machine compliance: the ability to run smart contracts written in Solidity for Ethereum with little or no modifications, on the Elrond Virtual Machine. Our VM’s implementation will hide the underlying architecture isolating the developers of smart contracts from system internals ensuring a proper abstraction layer.
In the second step, we target Ethereum interoperability: the ability to exchange seamlessly Ethereum and Elrond without a trusted third-party. This way, transactions between Elrond, Ethereum and ERC20 tokens could be processed securely without a centralized exchange, where the user must have an account, does not hold the private key for his account and also maybe go through a KYC process where the anonymity is lost.
Important aspects that we will take into consideration when building our “bridges” are privacy and security. Processing transactions that go through our bridges will be intrinsically secured by multi party computations of the private keys associated to the temporary bridge accounts.
In the third step, we would go further with the interconnection and interoperability, targeting other important blockchains, both public and private, by expanding our bridges. This approach requires specialized adapters for each chain that is non EVM compatible and wants to operate with Elrond.
Elrond Protoype PoC - v0.5
In it we’ve basically built technical backbone containing a communication p2p module for direct messaging, information broadcast and channel communication; cryptographic module dealing with signing and verification for transactions with Schnorr scheme and Bellare and Neven’s multi-signature method for blocks; data module to define and describe how the different data types (blocks, transactions, accounts, etc) are connected to each other and stored in the system; execution engine used to process transactions and assemble blocks while replicating the state across the network to ensure consistency and security; chronology module used for synchronization and time-passing perspective, ensuring a well structured bootstrapping process and proper timeouts; consensus module using a rudimentary consensus in a round-robin setting, allowing everyone to take turns in proposing and validating blocks, running independent consensus groups in each shard; sharding module using communication topics and enabling both intra-shard and cross-shard transactions.
Since the release of the PoC (July 2018), we moved forward and started working on the first version of the testnet. Although we learned a lot by developing the prototype, the PoC was left behind and we started coding the testnet from zero. If the the PoC was written in Java, for the testnet we have chosen Go.
We are working around the clock to deliver the testnet within the established timeframe.
Elrond Technical Roadmap