Frequently Asked Questions


What is Elrond?

Elrond is a complete rethinking of public blockchain infrastructure, specifically designed to be secure, efficient, scalable and interoperable. Elrond’s main contribution rests on two cornerstone building blocks:

  1. A genuine State Sharding approach: effectively partitioning the chain state into multiple shards, handled in parallel by different participating validators;
  2. Secure Proof of Stake consensus mechanism: an improved variation of Proof of Stake (PoS) that ensures long term security and distributed fairness, while eliminating the need for energy intensive PoW algorithms.

How does Elrond plan to solve the scalability issue?

In Elrond the throughput increases linearly with the number of shards in the network.

Sharding is a scaling technique inspired by traditional concepts of database optimization. Also known as horizontal partitioning, sharding divides the data into several pieces placed on different environments to be processed.

The more validators and shards, the more transactions the network can process. Elrond is performing all network services with minimal energy and computational requirements.

What is Adaptive State Sharding?

Sharding is a scaling technique inspired by traditional concepts of database optimization. Also known as horizontal partitioning, sharding divides the data into several pieces placed on different environments to be processed.

In a blockchain context, breaking the network into shards would result in more transactions being processed, verified and validated simultaneously. Each sharding level introduces a certain degree of parallelism, as a result, it becomes possible to process more transactions as the network grows. Implementing any sharding type on a blockchain architecture is extremely difficult.

We can identify 3 sharding types (levels):

  1. Network Sharding represents the process of grouping the nodes into shards.
  2. Transaction Sharding takes the complexity to the next level and deals with the distribution of transactions across different shards, but all the nodes keep the entire blockchain into their state.
  3. State sharding represents the most sophisticated part and is described as a mechanism that allows different shards to deal only with a portion of the state without replicating the data between nodes from different shards. A state sharded blockchain can be seen as a network of fully interconnected blockchains.

In order to match the current scalability needs, Elrond introduces a novel state sharding scheme, called Adaptive State Sharding, with a dynamic model that allows the network to adapt to population and demand changes without compromising security, availability and decentralization.

What is the Secure Proof of Stake (SPoS)?

In general, Proof of Stake (PoS) concept states that a node’s probability to validate block transactions is proportional to how many tokens it is staking.

Secure Proof of Stake consensus mechanism expands on Algorand’s idea of a random selection mechanism for the validators, differentiating itself through the following aspects:

  • Elrond proposes 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 last block's aggregated signature is used as the randomization factor. In contrast to Algorand’s approach, where the random committee selection can take up to 12 sec, in Elrond the time necessary for random selection of the consensus group is considerably reduced (estimated under 100 ms).
  • In addition, Elrond refines its consensus mechanism by adding a additional weight factor called rating. The node’s probability to be selected in the consensus group takes into consideration both stake and rating, promoting meritocracy.
  • Elrond uses Bellare and Neven multisignature scheme, which eliminates one communication round in the signing algorithm.

How is Elrond different from other blockchains?

  • 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 to achieve interoperability between blockchains.


Will you make Github public?

Absolutely, we are advocates of open source technology and we think the advancement of humanity stands on principles of open source technology. On the other hand we are aware that our technology is very difficult to copy because it is complex and extremely hard to replicate.

What hardware requirements are needed for running a node?

A typical node will probably need consumer-grade equipment and a super full node will probably need a multi-core server with enterprise level storage capabilities. It is expected that a super full node will need to have the capabilities of a typical consumer grade equipment multiplied by the number of shards. For a single node, the network requirements will need to be around 100Mbit/s download/upload link and for a super full node, the above mentioned requirement should be multiplied by the number of shards. We have tested the prototype on a broad range of equipments and operating systems. We have found that it works fine on a typical machine (i3 processor, 8GB RAM, SSD storage).

Is it possible to coordinate which shard nodes get into?

No, the shard each node gets allocated to is random. The new nodes (entering the system during an epoch) are kept in a pool and are allocated to shards at the end of the epoch by a pseudorandom algorithm. The shard assignment cannot be predicted ahead of time.

What is the size of a shard?

There is a trade off between security and communication overhead. For security we would want the shard to be as large as possible. For communication overhead to be minimised the number should be as low as possible. Preliminary experiments show that 300-400 nodes per shard would be a good tradeoff.

Is there inter-shard communication?

Yes. The processing of cross shard transactions require inter-shard communication.

Will nodes know if they are in the same shard?

Yes, the nodes will know who the other nodes in the shard are.

Do shards have to trust other shards?

There is a notarization chain which is always checked for cross shard operations. Some operations can also be verified, like if the cross shard message came from the correct group, and the group has run a pBFT on the message, etc.

The section 'Secure Proof of Stake and Consensus' states that the protocol assumes that an adversary cannot adapt faster than the round's time frame (4s). Can you clarify what is meant by this? How could one cheat if this assumption is incorrect?

The time-frame in which an adversary can act and try to influence the consensus is reduced to the time-frame of a round, which was estimated ~4 seconds in Elrond. We have another consensus group in each round, chosen based on the last block signature.

This is a short timeframe and mildly adaptive adversaries do not have a chance to act. A fast adaptive adversary could try to mount a DDoS attack on the validators, but this also takes time and from real world data regarding DDoS attacks, 4 seconds is not enough. Also these validators are randomly selected, so even if one of them is successfully DDoSed the others can still reach consensus, as ⅔+1 of them are needed.

We considered that an adversary can not immediately corrupt the leader or part of the consensus group (can not corrupt in 4s). If that happens, the leader or the validators can delay, withhold or send conflicting messages. If the assumption is incorrect and more than ⅔ validators can be bribed, they can propose invalid blocks. We are further improving the protection against all attack vectors.

Your scalability is in the number of transactions or in the number of nodes in network?

Both. Adding new nodes to the system should not hinder it but help increase throughput [TPS]. Generally speaking, the scalability we are discussing about is based on several criteria. The system must work well when there are few users and nodes, but more importantly when the system has many users and nodes. Network scaling capability can be measured in this case in time it takes from when a transaction is issued until it is committed to the blockchain, which should not increase with network size or users (it increases TPS instead, which allows keeping the waiting time in certain limits). Another criteria that affects scalability is storage size. When you have high TPS, especially when it comes to sharding, the system must be able to manage the associated data volume (a ledger that grows linearly with TPS) and here we are talking about orders of different magnitude compared to Blockchains like Bitcoin. For this, our solution is Adaptive State Sharding and not just Transaction Sharding (which would have solved the good TPS problem comparable to systems like VISA, but we would still have the storage problem). In addition to this, we also implement a pruning solution to further improve scalability on storage. Another point worth mentioning is energy waste. When the number of nodes in the network increases, one has to consider the operating energy cost, and also the cost of being able to participate in the system (the value of the node itself) - which is lower for us since we are not using POW but SPoS (we leave the whole system upgrade race behind and as long as you are not malicious you re-claim your stake).


Are you rewarding block validators?

Our fee structure is still in the research phase but we should have some initial conclusions published soon. The basic challenge is that we are trying to find a feasible way of bootstrapping the network by having a compelling economic incentive for node validators, while maintaining a competitive fee structure. More information on this will be published after our initial research has reached a conclusion. Until then we can share this information: In order to bootstrap the network and maintain a competitive fees structure, we are considering using a gradually decreasing inflation threshold to incentivize a specific (minimum) node participation rate. This will slowly transition to a self-sustained fee structure, ensuring an efficient and secure network. Based on initial calculations, this threshold will never exceed 2.5% per annum.

When are verifiers/validators rated? And how?

The leader will introduce a special transaction in the proposed block in which his account will have the rating increased by a small fraction (e.g. by 2 units). If the block gets signed by at least ⅔ validators + 1 then the leader will have its rating increased. The validators will have their ratings increased at the end of the epoch by the following rule: the validators who signed a block that was successfully added to the blockchain will have their rating increased (e.g. by 1 unit). The leader caught cheating on a block (+the validators who signed that block) will be slashed in the following rounds. The slashing occurs if some nodes will emit special transactions with proofs to signal malicious leader and validators and those transactions get included in a block. The nodes that detected the malicious leader will get rewarded and have their rating increased. Any node caught emitting false signaling transactions will have their rating decreased. If rating falls below a certain value, stake slashing will occur.

Is there an estimate of cost of redistributing a subset of nodes across shard every epoch?

The cost of redistributing a subset of nodes between shards consists in the network usage and processing power to bootstrap those nodes. The liveness of the network is estimated that will remain unaffected. We are looking into further optimizations to minimize that cost.

How is cross shard communication handled? Who validates the communication?

The communication between shards is made through dedicated channels between the consensus groups. The transaction is dispatched to the sender shard and after it’s being validated and included in a block, a receipt is broadcast along with the transaction to the receiver shard through the dedicated channel. The receipt is signed by the validators group from sender shard and the consensus group in the receiver’s shard can verify the receipt information independently.


Can a shard be attacked?

Given enough time and resources, any system can be attacked. One possible way to attack a shard would be to have more than ⅓ malicious nodes into the shard, but this is highly unlikely due to the random assignment of nodes to shards, and the assumptions that no more than ¼ of nodes in the network are malicious.

Are attacks fro quantum computing possible?

Most of the cryptographic schemes in blockchains today (ethereum, bitcoin, etc) are susceptible to attacks from quantum computers. There have been some advances in cryptography for post-quantum computing and we are investigating this field.

Does dividing the network into smaller shards make it more susceptible to Sybil attacks

All nodes are backed by their stake which does not change with the size of shards.

Is it possible to obtain a majority in one shard by pure luck?

The probability to get more than ⅓ in a shard is very low < 10^-6 and can be computed by a hypergeometric distribution.

What happens if a group of validators commit an invalid block into a shard's ledger and it's the last block of the epoch making epoch e+1 have an invalid block as that epoch’s genesis block?

As mentioned in previous answer, the invalid block will not be accepted by the shard honest nodes, so even if there is a delay in the epoch, one shard having more rounds to reach the end of an epoch with a valid block, this is prefered as opposed to reaching the end of the epoch with an invalid block.

The extra rounds will be deducted from the next epoch, so that delays do not add up. The shuffling of nodes is not affected as the moving nodes are always buffered for one epoch into a waiting list for the shard, together with the new joining nodes.

We are also considering for the last block in the epoch to run a consensus on all the eligible nodes in the shard.

How to handle the nothing at stake problem?

Elrond addresses the nothing at stake problem through a blockchain that aims to evolve without forks. The forking is avoided by the selection process inside SPoS ( Secure Proof of Stake), our consensus method detailed in Chapter V, Section 2 in the whitepaper. To overcome nothing at stake and other security problems, SPoS uses two important mechanisms: a) 2 separate selection lists (waiting and eligible) b) 2 selection parameters rating and stake. Our architecture does not encourage a block proposing competition that might produces forks, instead on every round, the group members that are proposing and signing the block are well known. On top of that, after each round the group members may perform a stake slashing for bad behavior using the feedback function based on the ratingModifier. During the development phase, as these features will confirm the mathematical theories and the efficiency of the solution, we will post further results, resistance tests and improvements.

Explain this part from the white paper: "Elrond uses Bellare and Neven multisignature scheme [4], which eliminates one communication round in the signing algorithm, because no proof of possession is needed, but maintains the same security level."

One vulnerability in digital multi-signing schemes is rogue key attack.

The vulnerability is that a signer can calculate the public key he participates in the signing with, so that it cancels out the other honest signers public keys and it ends up the only one who's signature matters, being able to produce forgeries.

For example:

Signer1 has a key pair (priv1, pub1), where priv1 is the private key of signer1 and pub1 is the public key of signer1, and generates partial signature sig1.

Signer2 has key pair (priv2, pub2) which generates the partial signature sig2

Signer2 can claim in the signing algorithm that his public key is in fact a function of the public key of signer1 and his own public key, f(pub1, pub2), so that when the aggregated signature is calculated, the first signature sig1 is canceled out from the formula, and the aggregated signature depends only on sig2.

One countermeasure for this vulnerability is to prove that you have the private key associated to the public key you participate with in the signing algorithm.

So one more round in the signing algorithm would be to sign a default message that is verifiable by the public key you will use and use this to prove your public key is not forged.

This round is called proof of possession or KOSK knowledge of secret key.

Stay informed and never miss an Elrond update!

Subscribe to receive our weekly newsletters and exciting news.

  Please use a valid email address An error occurred. Please try again. Check the captcha checkbox
Success, check your email to confirm subscription