Introduction
Elrond is a linearly Scalable Public Blockchain with novel Secure Proof of Stake consensus and Adaptive State Sharding. Testnet exceeded 12k TPS with only 5 shards and 65k with 20 shards! Having a strong focus on security, Elrond’s network is built to ensure resistance to known security problems like Sybil attack, Nothing at Stake attack, and others. The probability that a malicious supermajority (66%+1) is selected in the shard for the same round in the same consensus is 10^−9, even if 33% of the nodes from the shard are malicious. In Elrond, cross-chain interoperability can be implemented by using an adapter mechanism at the Virtual Machine level as proposed by Cosmos. Elrond Network will support three low-level languages: IELE VM, KEVM, and WASM.
Technology
Architecture
Threat model
Elrond assumes a byzantine adversarial model, where at least ⅔n+1 (66%+1) of the eligible nodes in a shard are honest. The protocol permits the existence of adversaries that have a stake or good rating, delay or send conflicting messages, compromise other nodes, have bugs or collude among themselves, but as long as ⅔n+1 (66%+1) of the 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 limited time ∆.
Attack vectors’ prevention
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 from the proposer, and the stake slashing. The reward per block compared to the stake locked will discourage such behavior;
3) Long-range attacks: mitigated by Elrond’s pruning mechanism, the use of a randomly selected consensus group every round (and not just a single proposer) and stake locking. On top of all these, Eltond pBFT consensus algorithm ensures finality after k blocks, where k is small;
4) DDoS attacks: the consensus group is randomly sampled every round (few seconds); the short time frame making DDoS almost impossible.
Other attack vectors Elrond has taken into consideration are: shard takeover attack, transaction censorship, double spend, bribery attacks, etc.
Adaptive State Sharding
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:
1) Scalability without affecting availability: Increasing or decreasing the number of shards should affect a negligibly small vicinity of nodes without causing downtimes, or minimizing them while updating states;
2) Dispatching and instant traceability: Finding out the destination shard of a transaction should be deterministic, trivial to calculate, eliminating the need for communication rounds;
3) Efficiency and adaptability: The shards should be as balanced as possible at any given time.
Method Description
The total number of shards will change if the number of nodes in the network changes and if the blockchain utilization needs it: if the number of nodes increases above a threshold from one epoch to another and the average number of transactions per block is greater than the threshold number or if the number of nodes decreases below a threshold.
As the main goal is to increase the throughput beyond thousands of transactions per second and to diminish the cross-shard communication, Elrond proposes a dispatching mechanism that determines automatically the shards involved in the current transaction and routes the transaction accordingly. The dispatcher will take into consideration the account address of the transaction sender/receiver. The result is the number of the shard the transaction will be dispatched to.
The entire sharding scheme is based on a binary tree structure that distributes the account addresses, favors the scalability and deals with the state transitions. A representation of the tree can be seen in Fig. 1.
The presented tree structure is merely a logical representation of the account address space used for a deterministic mapping; e.g., shard allocation, sibling computation, etc. The leaves of the binary tree represent the shards with their ID number. Starting from the root (node/shard 0), if there is only one shard/leaf (a), all account addresses are mapped to this one, and all transactions will be executed here. Further on, if the formula for an optimum number of shards dictates the necessity of 2 shards (b), the address space will be split into equal parts, according to the last bits in the address.
Sometimes, the tree can also become unbalanced if an optimum number of shards is not a power of 2. This case only affects the leaves on the last level. The structure will become balanced again when the number of shards reaches a power of 2.
The unbalancing of the binary tree causes the shards located in the lowest level to have half the address space of nodes of a shard located one level higher, so it can be argued that the active nodes allocated to these shards will have a lower fee income — block rewards are not affected. However, this problem is solved by having a third of each shard nodes redistributed randomly each epoch (detailed in the Chronology section) and having a balanced distribution of nodes according to the tree level.
Looking at the tree, starting from any leaf and going through branches towards the root, the encoding from branches represents the last n bits of the account addresses that will have their associated originating transactions processed by that leaf/shard. Going the other way around, from root to leaf, the information is related to the evolution of the structure, sibling shards, the parent shard from where they split. Using this hierarchy, the shard that will split when the optimum number of shards (hereinafter Nsh) increases or the shards that will merge when Nsh decreases can easily be calculated. The entire state sharding mechanism benefits from this structure by always keeping the address and the associated state within the same shard.
Knowing Nsh, any node can follow the redistribution process without the need for communication. The allocation of IDs for the new shards is incremental and reducing the number of shards involves that the higher numbered shards will be removed. For example, when going from Nsh to Nsh-1, two shards will be merged, the shard to be removed is the highest numbered shard (shmerge=Nsh-1). Finding the shard number that shmerge will be merged with is trivial. According to the tree structure, the resulting shard has the sibling’s number.
Shard redundancy
On the blockchain, state sharding is susceptible to shard failure when there is an insufficient number of online nodes in a shard, or the distribution is localized geographically. In the unlikely case when one shard fails (either the shard cannot be contacted — all nodes are offline, or consensus cannot be reached — more than ⅓ of nodes are not responding), there is a high risk that the entire architecture relies only on super-full nodes, which fully download every block of every shard, fully verifying everything. As displayed in Fig. 2, Elrond’s protocol has a protection mechanism that introduces a tradeoff in the state holding structure by enforcing the shards from the last tree level to also hold the state from their siblings. This mechanism reduces communication and eliminates the bootstrapping when sibling shards are merging since they already have the data.
Context switching
To preserve security in sharded public blockchains, context switching becomes crucial. This refers to the reallocation of the active nodes between shards on a fixed time interval by some random criteria. In Elrond’s approach, the context switching represents a security improvement but also increases the complexity required to maintain consistency between multiple states. The state transition has the biggest footprint on performance since the movement of active nodes requires to resync the state, blockchain, and transactions alongside the eligible nodes in the new shard. At the start of each epoch, in order to maintain liveness, only less than ⅓ of these nodes will be uniformly re-distributed across shards. This mechanism is highly effective against forming malicious groups.
Notarization (Meta) chain
All network and global data operations (node joining the network, node leaving the network, eligible validator lists computation, nodes assignment to the shard’s waiting lists, consensus agreement on a block in specific shard challenges for invalid blocks will be notarized in the metachain. The metachain consensus is run by a different shard that communicates with all other shards and facilitates cross-shard operations. Every round of every epoch, the metachain receives block headers from the other shards and, if necessary, proofs for the challenges of the invalid blocks. This information will be aggregated into blocks on the metachain on which consensus has to be run. Once the blocks are validated in the consensus group, shards can request information about blocks, miniblocks, eligible validators, nodes in waiting lists, etc., in order to securely process cross-shard transactions.
Secure Proof of Stake (SPoS)
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. The algorithm is described in the steps below:
1) Each node ni is defined as a tuple of the public key, rating (default is 0) and the locked stake. If ni wishes to participate in the consensus, it has to first register through a smart contract, by sending a transaction that contains an amount equal to the minimum required stake and other information.
2) The node ni joins the node pool and waits for the shard assignment at the end of the current epoch e. The shard assignment mechanism creates a new set of nodes containing all the nodes that joined in epoch e and all the nodes that need to be reshuffled (less than ⅓ of every shard). All nodes in this set will be reassigned to the waiting lists of shards. Wj represents j’s shard waiting list, and Nsh represents the number of shards. A node also has a secret key that by nature is not to be made public.
3) At the end of the epoch in which it has joined, the node will be moved to the list of eligible nodes (Ej) of a shard j, where e is the current epoch.
4) Each node from the list Ej can be selected as part of an optimally dimensioned consensus group (in terms of security and communication), by a deterministic function, based on the randomness source added to the previous block, the round r and a set of variation parameters. The random number, known to all shard nodes through gossip, cannot be predicted before the block is actually signed by the previous consensus group. This property makes it a good source of randomness and prevents highly adaptive malicious attacks. Elrond defines a selection function to return the set of chosen nodes (consensus group) Nchosen with the first being the block proposer, which takes the following parameters: E, r and sigr−1 — the previous block signature.
5) The block will be created by the block proposer, and the validators will co-sign it based on a modified practical Byzantine Fault Tolerance (pBFT).
6) If for any reason, the block proposer did not create a block during its allocated time slot (malicious, offline, etc.), round r will be used together with the randomness source from the last block to select a new consensus group.
If the current block proposer acts in a malicious way, the rest of the group members apply negative feedback to change its rating, decreasing or even canceling out the chances that this particular node will be selected again. When ratingModifier < 0, slashing occurs, so the node ni loses its stake.
The consensus protocol remains safe in the face of DDoS attacks by having a high number of possible validators from the list E (hundreds of nodes) and no way to predict the order of the validators before they are selected.
To reduce the communication overhead that comes with an increased number of shards, a consensus will be run on a composite block. This composite block is formed by:
- Ledger block: the block to be added into the shard’s ledger, having all intra-shard transactions and cross-shard transactions for which confirmation proof was received;
- Multiple mini-blocks: each of them holding cross-shard transactions for a different shard;
The consensus will be run only once, on the composite block containing both intra- and cross-shard transactions. After a consensus is reached, the block header of each shard is sent to the metachain for notarization.
Cryptographic Layer
BLS is an interesting signature scheme, from the Weil pairing, which bases its security on the Computational Diffie-Hellman assumption on certain elliptic curves and generates short signatures. It has several useful properties like batch verification, signature aggregation, public key aggregation, making BLS a good candidate for threshold and multi-signature schemes.
For traceability and security reasons, a consensus-based on a reduced set of validators requires the public key from each signer. In this context, Elrond’s analysis concludes that the most appropriate multi-signature scheme for block signing in Elrond is BLS multi-signature, which is faster overall than the other options due to only two communication rounds.
Block signing in Elrond
Practical signing — Round 1
The leader of the consensus group creates a block with transactions, then signs and broadcasts this block to the consensus group members.
Practical signing — Round 2
Each member of the consensus group (including the leader) who receives the block must validate it, and if found valid, it signs it with BLS and then sends the signature to the leader:
Practical signing — Round 3 The leader waits to receive the signatures for a specific timeframe. If it does not receive at least ⅔n+1 signatures in that timeframe, the consensus round is aborted. But if the leader does receive ⅔n+1 or more valid signatures, it uses them to generate the aggregated signature SigAgg.
The leader then adds the aggregated signature to the block together with the selected signers’ bitmap B, where a 1 indicates that the corresponding signer in the list L had its signature added to the aggregated signature SigAgg.
Cross-shard Execution
For an in-depth example of how the cross-shard transactions are being executed and how the communication between shards and the metachain occurs, Elrond is 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 Fig. 3 are required for processing the cross-shard transaction.
The blocks 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 contains 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 Elrond’s 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 the 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.
Elrond’s cross-shard transaction strategy uses an asynchronous model. Validation and processing are 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. Afterward, 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.
Smart Contracts
The execution of smart contracts is a key element in all future blockchain architectures. Most of the existing solutions avoid explaining the transactions and data dependency properly. This context leads to the following two scenarios:
1) When there is no direct correlation between smart contract transactions, as displayed in Fig.4, any architecture can use out of order scheduling. This means there are no additional constraints on the time and place (shard) where a smart contract is executed.
2) The second scenario refers to the parallelism induced by the transactions that involve correlated smart contracts. This case reflected in Fig. 5, adds additional pressure on the performance and considerably increases the complexity. Basically, there must be a mechanism to ensure that contracts are executed in the right order and in the right place (shard). To cover this aspect, Elrond protocol proposes a solution that assigns and moves the smart contract to the same shard where their static dependencies reside. This way most, if not all SC calls will have dependencies in the same shard and no cross-shard locking/unlocking will be needed.
Elrond focuses on the implementation of the Elrond Virtual Machine, an EVM compliant engine. The EVM compliance is extremely important for adoption purposes, due to a large number of smart contracts built on Ethereum’s platform.
The Elrond Virtual Machine’s implementation will hide the underlying architecture isolating the smart contract developers from system internals, ensuring a proper abstraction layer, as displayed in Fig. 6.
In Elrond, cross-chain interoperability can be implemented by using an adapter mechanism at the Virtual Machine level as proposed by Cosmos. This approach requires specialized adapters and an external medium for communication between adapter SC for each chain that will interoperate with Elrond. The value exchange will be operated using some specialized smart contracts acting as asset custodians, capable of taking custody of adapted chain native tokens and issuing Elrond native tokens.
VM Infrastructure
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.
The greatest advantage of using the K framework is that with it, smart contract languages can be unambiguously defined, eliminating the potential for unspecified behavior and bugs that are hard to detect.
The K Framework is executable, in the sense that the semantic specifications of languages can be directly used as working interpreters for the languages in question. More specifically, one can either run programs against the specifications using the K Framework core implementation directly, or one can generate an interpreter in several programming languages. These are also referred to as ”backends.” For the sake of execution speed and ease of interoperability, Elrond uses its own custom-built K Framework backend.
Smart contract languages
One great advantage of the K Framework is that one can generate an interpreter for any language defined in K, without the need for additional programming. This also means that interpreters produced this way are ”correct-by-construction.” There are several smart contract languages specified in the K Framework already, or with their specifications under development. Elrond Network will support three low-level languages: IELE VM, KEVM, and WASM.
• IELE VM is an intermediate-level language, in the style of LLVM, but adapted 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 — most changes are related to account address management. 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 Fig. 7.
• KEVM is a version of the Ethereum Virtual Machine (EVM), written in K. Certain vulnerabilities of EVM are fixed in the K version, or the vulnerable features are left out entirely.
• 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.
Having a language specification and generating the interpreter is only half of the challenge. The other half is integrating the generated interpreter with the Elrond network. Elrond has built a common VM interface, that enables them to plug in any VM into an Elrond node, as shown in Fig. 8. Each VM then has an adapter that implements this interface. Each contract is saved as bytecode of the VM for which it was compiled and ran on its corresponding VM.
Support for formal modeling and verification
Because the smart contract languages are formally defined in K Framework, it is possible to perform formal verification of smart contracts written in these languages. To do this, it is necessary to also formally model their requirements, which can also be performed using the K Framework.
Smart contracts on the sharded architecture
Following Ethereum’s model, Elrond has the following transaction types:
1) SC construction and deployment: transactions receiver address is empty, and the data field contains the smart contract code as byte array;
2) SC method invoking: transaction has a non-empty receiver address and that address has an associated code;
3) Payment transactions: transaction has a non-empty receiver, and that address does not have code.
Elrond’s approach to this problem is to use the asynchronous cross-shard execution model in case of smart contracts. The user creates a smart contract execution transaction. If the smart contract is not in the current shard, the transaction is treated as a payment transaction, the value of the transaction is subtracted from the sender account, and it is added to the block where the sender shard resides, into a miniblock with the destination shard where the receiver account is. The transaction is notarized by metachain, then processed by the destination shard. In the destination shard, the transaction is treated as an SC method invoking, as the receiver address is a smart contract that exists in this shard. For the smart contract call a temporary account which shadows the sender account is created, with the balance from the transaction value and the smart contract is called. After the execution, the smart contract might return results, which affect a number of accounts from different shards. All the results, which affect in-shard accounts, are executed in the same round. For those accounts which are not in the shard where the smart contract was executed, transactions called Smart Contract Results will be created, saving the smart contract execution output for each of these accounts. SCR miniblocks are created for each destination shard. These miniblocks are notarized the same way as cross-shard transactions by metachain, then processed by the respective shards, where the accounts reside. In case one smart contract calls dynamically another smart contract from another shard, this call is saved as an intermediate result and treated the same as for accounts.
The solution has multiple steps, and the finalization of a cross-shard smart contract call will need at least 5 rounds, but it does not need locking and state movement across shards.
Bootstrapping and Storage
Epochs
In Elrond Protocol, 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 Fig. 9.
The node shuffling process runs in multiple steps:
1) The new nodes registered in the current epoch ei land in the unassigned node pool until the end of the current epoch;
2) Less than ⅓ of the nodes in every shard are randomly selected to be reshuffled and are added to the assigned node pool;
3) The new number of shards Nsh,i+1 is computed based on the number of nodes in the network and network usage;
4) Nodes previously in all shard’s waiting lists that are currently synchronized are added to the eligible validator’s lists;
5) The newly added nodes from the unassigned node pool are uniformly randomly distributed across all shards’ waiting lists during epoch ei+1;
6) 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.
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.
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 high transaction throughput.
Pruning
A high throughput will lead to a distributed ledger that rapidly grows in size and increases bootstrapping cost (time+storage).
This cost can be addressed by using efficient pruning algorithms, that can summarize the blockchain’s full state in a more condensed structure. The pruning mechanism is similar to the stable checkpoints in pBFT and compresses the entire ledger state.
Elrond protocol makes use of an efficient pruning algorithm detailed below. Let us consider that e is the current epoch and a is the current shard:
1) the shard nodes keep track of the account balances of e in a Merkle tree;
2) at the end of each epoch, the block proposer creates a state block sb(a,e), which stores the hash of the Merkle tree’s root in the block’s header and the balances in the block’s body;
3) validators verify and run consensus on sb(a,e);
4) if consensus is reached, the block proposer will store sb(a,e) in the shard’s ledger, making it the genesis block for epoch e+1;
5) at the end of epoch e+1, nodes will drop the body of sb(a,e) and all blocks preceding sb(a,e).
Using this mechanism, the bootstrapping of the new nodes should be very efficient. Actually, they start only from the last valid state block and compute only the following blocks instead of its full history.
Security Evaluation
Randomness source
Elrond makes use of random numbers in its operation, e.g., for the random sampling of block proposer and validators into consensus groups and the shuffling of nodes between shards at the end of an epoch. Because these features contribute to Elrond’s security guarantees, it is therefore important to make use of random numbers that are provably unbiasable and unpredictable. In addition to these properties, the generation of random numbers also needs to be efficient so that it can be used in a scalable and high throughput blockchain architecture.
These properties can be found in some asymmetric cryptography schemes, like the BLS signing scheme. One important property of BLS is that using the same private key to sign the same message always produces the same results.
Randomness creation in Elrond
One random number is created in every round, and added by the block proposer to every block in the blockchain. This ensures that the random numbers are unpredictable, as each random number is the signature of a different block proposer over the previous randomness source. The creation of random numbers is detailed below as part of one consensus round:
1) A new consensus group is selected using the randomness source from the previous block header. The consensus group is formed by a block proposer and validators.
2) The block proposer signs the previous randomness source with BLS, adds the signature to the proposed block header as new randomness source, then broadcasts this block to the consensus group.
3) Each member of the consensus group validates the randomness source as part of block validation and sends their block signature to the block proposer.
4) Block proposer aggregates the validators block signatures and broadcasts the block with the aggregated block signature and the new randomness source to the whole shard.
The evolution of randomness source in each round can be seen as an unbiased and verifiable blockchain, where each new random number can be linked to and verified against the previous random number.
”K” block finality scheme
The signed block at round n is final, if and only if blocks n+1, n+2, …, n+k are signed. Furthermore, a final block cannot be reverted. The metachain notarizes only final blocks to ensure that a fork in one shard does not affect other shards. Shards only take into consideration the final metachain blocks, in order to not be affected if the metachain forks. Finality and correctness are verified at block creation and at block validation as well. The chosen k parameter is 1, and this ensures forks of maximum 2 blocks length. The probability that a malicious super majority (>⅔n+1) is selected in the shard for the same round in the same consensus is 10^−9, even if 33% of the nodes from the shard are malicious. In that case, they can propose a block and sign it — let’s call it block m, but it will not be notarized by the metachain. The metachain notarizes block m, only if block m+1 is built on top of it. In order to create block m+1, the next consensus group has to agree with block m. Only a malicious group will agree with block m, so the next group must have a malicious supermajority again. As the random seed for group selection cannot be tampered with, the probability of selecting one more malicious super majority group is 10^−9 (5.38*10^−10, to be exact). The probability of signing two consecutive malicious blocks equals with selecting two subgroups with at least (⅔n+1) members from the malicious group consequently. The probability for this is 10^−18. Furthermore, the consequently selected groups must be colluding; otherwise, the blocks will not be signed.
Fisherman challenge
When one invalid block is proposed by a malicious majority, the shard state root is tampered with an invalid result (after including invalid changes to the state tree). By providing the combined Merkle proof for a number of accounts, an honest node could raise a challenge with proof. The honest nodes will provide the block of transactions, the previous reduced Merkle tree with all affected accounts before applying the challenged block and the smart contract states, thus demonstrating the invalid transaction/state. If a challenge with the proof is not provided in the bounded time frame, the block is considered valid. The cost of one invalid challenge is the entire stake of the node, which raised the challenge.
The metachain detects the inconsistency, either an invalid transaction or an invalid state root, through the presented challenges and proofs. This can be traced, and the consensus group can be slashed. At the same time, the challenger can be rewarded with part of the slashed amount. Another problem is when a malicious group hides the invalid block from other nodes — non-malicious ones. However, by making it mandatory for the current consensus to propagate the produced block to the sibling shard and to the observer nodes, the data cannot be hidden anymore. The communication overhead is further reduced by sending only the intrashard miniblock to the sibling shard. The cross-shard miniblocks are always sent on different topics accessible by interested nodes. In the end, challenges can be raised by multiple honest nodes. Another security protection is given by the setup of P2P topics. The communication from one shard toward the metachain is done through a defined set of topics/channels, which can be listened to by any honest validator — the metachain will not accept any other messages from other channels. This solution introduces some delay in the metachain only in case of challenges, which are very low in number and highly improbable since if detected (high probability of being detected) the nodes risk their entire stake.
Team
According to the Elrond website, there are 18 members on the team.
Beniamin Mincu — CEO
Beniamin is an entrepreneur and early blockchain investor with more than 4 years of experience with blockchain startups. He was previously part of the NEM core team, where he led the business, marketing, and community efforts for 1,5 years, helping bootstrap the NEM blockchain from an idea to a global product. He has also invested and supported some 30 blockchain projects among which Icon, Matrix, and Zilliqa. General Partner of Metachain Capital.
Lucian Todea — COO
Lucian is a successful entrepreneur and active investor in startups and the blockchain space, with more than 15 years of experience in tech businesses. He has lead one of the fastest-growing startups in Europe and is a technology executive with significant operational, business development, general management, leadership, and international experience. He is also CEO, founder, and partner in several tech companies.
Lucian Mincu — CIO
Lucian is a skilled infrastructure engineer, with 8 years experience spanning from developing end-to-end startup products to designing and implementing highly technical yet comprehensive infrastructure and network solutions for large enterprise clients like the German State. He loves cutting edge technology and has joined the blockchain space in 2016, where he co-founded Metachain Capital and ICO Market Data.
Felix Crisan — Head of Research
The intersection of payments, big data, and distributed systems led him to Bitcoin and the blockchain industry where he Co-founded BTKO, Romania’s first Bitcoin exchange platform. Felix is currently the Co-founder and CTO of Netopia, where he implemented market-leading solutions for online and mobile payments. He has more than 20 years of working experience in IT and teaches BigData concepts and technologies, including Machine Learning and Artificial Intelligence algorithms. Bitcoin Lightning Network contributor.
Radu Chis — Head of Technology
Radu holds a Ph.D. in Computer Science, his main research spanning over Advanced Computer Architecture, Design Space Exploration and Machine Learning. He has published several scientific papers in prestigious journals and international conferences. He participated in EU funded research projects and has over 10 years of experience as a software engineer, deploying enterprise solutions for multiple sectors.
Adrian Dobrita — Head of Engineering
Adrian won 1st Place in a national Ai Multi-Agent Systems Competition. He holds a Bachelor’s degree in Computer Science and a Master’s degree in Advanced Computing Systems. He is a software engineer with more than 10 years of experience and skills in a wide range of programming languages. Adrian has worked for leading companies such as Intel, ST-Ericsson, Continental, developing industry-grade embedded software in areas such as mobile and automotive. He has also worked for several startups as a back-end developer.
Iulian Pascalau — Core Developer
Iulian holds a Bachelor’s degree in Computer Science and has designed and implemented rugged, industrial-grade software for more than 10 years. He has extensive experience in C#, ASP.NET, ABAP, Python, SQL, interfacing PLC’s, ERP systems (SAP and others) and is a passionate engineer with strong knowledge about IoT devices, network infrastructures, as well as analog and digital electronics.
Sebastian Marian — Core Developer
Sebastian is four times the winner of the 3rd place in the prestigious global AI competition RoboCup. He is a member of the RoboCup Executive Committee and was previously a member of the RoboCup Technical Committee. He has extensive experience in Multi-Agent Systems, Machine Learning, and AI. He holds a Bachelor’s degree in Computer Science and is a software engineer with more than 18 years of experience in a wide range of languages and technologies.
Mihai Dorian Stancu — Software Engineer
Mihai is a Machine Learning Ph.D. student with a creative mindset and a passion for optimization and AI. He has more than 10 years of experience in software engineering with a focus on enhanced security, reliability, and scalability. He has built enterprise software solutions and has provided his technical expertise to EESSI, a European IT system that helps social security institutions across the EU exchange information more rapidly and securely. He has a deep understanding of cryptography, blockchain architectures, and algorithms.
Corcoveanu Cristian — Software Engineer
Cristian is a full stack developer with rich programming experience in software optimization in a wide range of industrial sectors from electronics to Internet service providers. He is proficient in javascript, Reacts, Angularjs and node. Cristian holds a BS in Computer Science and loves learning how to harness new programming languages
Andrei Marinica — Software Engineer
Andrei holds a BA in Computer science and an MA in Advanced Computing Systems. He brings the team an impressive amount of know-how from his experience formed at companies such as Microsoft, BOC Group, and Qiagen. With interest in mathematics and formal models, he joins Elrond as a valuable member of the team driven to create a safe, open, and scalable platform.
Robert Sasu — Software Engineer
Robert holds a BA in Software Engineering and an MA in Engineering in Graphics, Multimedia, and Virtual Reality. In the early days as a programmer, he was three times Google Summer of Code Student. In the past few years, he developed complex algorithms for the Advanced Driver Assistance Systems of Continental. He applied for more than 20 patents in the autonomous car industry and co-founded an eMobility start-up which won an international competition.
Camil Ioan Bancioiu — Researcher
Camil holds a Bachelor’s degree in Computer Science, a Master’s degree in Advanced Computing Systems and is currently working on his Ph.D. in Machine Learning. He is very enthusiastic about theoretical Computer Science and has accumulated more than 10 years of experience as a software engineer in Scotland, Romania, and Germany, before becoming a freelance engineer and consultant.
Endre Simo — Software Engineer
Endre is a Senior Software Developer and a creative coder passionate about modern web technologies. He has interests in philosophy and political sciences. He worked for companies such as Hewlett-Packard, and among others, he is now proficient in Javascript, PHP and Go. Endre joins the Elrond team with his passion for decentralizing the web.
Beniamin Drasovean — Jr. Software Engineer
Beniamin is a junior software developer part of the Elrond team currently as an intern. He is enrolled in a 4 years Bachelors Computer Science program. Being fascinated by blockchain technology, he joins the team to learn more and become an expert in the field. He is dedicated to Elrond’s mission in creating a scalable value transfer protocol for the digital economy.
Dan Voicu — Head of Communication
Dan has a Bachelor’s degree in Politics and a Master’s degree in International Business Administration. He has strong communication skills and is especially focused on authentic community building. He firmly believes that decentralization is a very compelling means of changing the status quo.
Daniel Serb — Head of Marketing and PR
Daniel holds a Bachelor’s degree in Politics and International Relations. He worked for leading companies such as Frank Recruitment Group based in the UK, where he was responsible for building the company’s influence on the Nordic market. At Continental AG, he focused on recruitment and employer branding creating innovative marketing strategies. Throughout the years he developed skills in Software and IT recruitment, employer branding, social media, and marketing.
Larisa Oltean — UI UX Designer
Larisa holds a Master’s degree in Design. Her extensive experience as a freelancer helps her understand complex requirements and then come up with simple and logical solutions. At Elrond, she is focused on translating complex user stories into a clear and intuitive design.
And others.
Advisors
Alex Iskold — Business Advisor
New York-based entrepreneur and investor. Managing Director at Techstars, NYC. Alex was the founder/CEO at GetGlue, founder/CEO of Information Laboratory, Chief Architect at DataSynapse. Award winner and seasoned investor with presence in over 90 startups. In addition to being a serial entrepreneur, Alex also wrote hundreds of articles on ReadWriteWeb and taught an award-winning undergraduate software engineering class at New York University.
Alex Tabarrok — Economics Advisor
Professor of economics at George Mason University. He holds the Bartley J. Madden Chair in Economics at the Mercatus Center. Co-founder of Marginal Revolution University: An Online Platform for Learning Economics. Alex is the author of numerous academic papers in the fields of law and economics, criminology, regulatory policy, voting theory, and other areas in the political economy. He is a co-author of Modern Principles of Economics and co-author of the Marginal Revolution economics blog.
Raul Jordan — Technical Advisor
Ethereum core developer. He is Co-Leading Prysmatic Labs, the first Sharding Implementation for the Ethereum Protocol. He is a partner at zk Capital, a research-focused blockchain investment fund. In 2014, Raul Co-Founded Kynplex the first-ever network of its kind in the life sciences that brings together hubs of scientific innovation online. Thiel Fellow ’16. Harvard dropout.
Grigore Rosu — Technical Advisor
Grigore Roșu is a computer science professor at the University of Illinois at Urbana-Champaign (UIUC), where he leads the Formal Systems Laboratory (FSL). Previously, he was a scientist at NASA, where he coined the term runtime verification with his colleagues. He is interested in programming languages, formal methods and software engineering, and especially in how to combine these to increase the safety, security, and dependability of computing systems. Grigore got his Ph.D. from the University of California at San Diego.
Fabio C. Canesin — Technical Advisor
Co-Founder of the City of Zion and NEX, he holds an MSc in computational mechanics and variational multi-scale modeling and is a researcher engineer in the petroleum industry. Fabio has developed software in several large projects that have had deployed an impact on billions of dollars of assets. He is also co-founder and CTO of Lemonaid Learning Analytics.
Ethan Fast — Technical Advisor
CS Ph.D. from Stanford, Co-Founder of the City of Zion and NEX. Creator of Neon wallet. Ethan is an entrepreneur and research scientist with a background in HCI, AI, and blockchain. He has led more than 10 projects to publication in top venues such as CHI, UIST, EMNLP, and AAAI, where they have won multiple awards. In May 2011, Ethan founded a Y Combinator funded startup, Proxino.
Andrei Pitis — Business Advisor
VP of Engineering and Head of Bucharest Office at Fitbit. Founder and CEO at Vector Watch. Angel Investor with several tech leadership positions. He serves on board of ANIS — the most active Romanian software association and co-founded Tech Angels and Innovation Labs. From 1995 to 2015 he was an Associate Professor at Politehnica University of Bucharest.
Partnerships
NETOPIA is the biggest electronic payment processor in Romania, expecting to process in 2018 more than 13 million digital transactions with a total value of around $400 Million.
Elrond and NETOPIA aim to jointly explore the potential of integrating Elrond’s token, ERD, into the NETOPIA payment platform allowing their merchants to offer on their turn to their users and clients the possibility to acquire products and services through ERD tokens as well.
Distributed Systems Research Laboratory
Distributed Systems Research Laboratory (DSRL) part of the Technical University of Cluj-Napoca — Computer Science Department, has extensive experience in many fields of the distributed systems related research areas such as: Energy efficiency in large scale distributed systems, Machine learning, Big data analytics, IoT and blockchain technology, Ambient assisted living and Multidisciplinary optimization. The DSRL laboratory is actively involved in EU funded research and innovation projects, has an established collaboration network comprising a large number of universities and companies and has published over 100 articles in international conferences and high impact journals.
Elrond and DSRL aim to collaborate on research-education themes, namely:
- Development of research topics, including:
Analysis of the practical applicability of blockchain technology in the energy field and use case scenarios;
Jointly explore the possibility to use the platform developed by Elrond Network in the energy field;
Joint participation in research projects with national or European funding in blockchain technology;
Identifying common Masters and Doctoral themes and creating materials for academic and educational purposes.
- Knowledge transfer supporting Elrond with University led applied research
- Dissemination of results by jointly organizing scientific scholarship sessions and scientific conferences in the areas of interest.
Nash, (formerly known as NEX) is a decentralized finance platform made for exchanging digital assets, interaction with cryptocurrency wallets, and browser-based blockchain-powered web-app development. Nash also introduced the world’s first fully regulatory compliant exchange security token.
Elrond and Nash, aim to jointly explore the potential integration of the Elrond blockchain platform and tokens (ERD) into the Nash payment platform, allowing their users and clients the possibility to trade and acquire ERD tokens across different platforms. Additionally, Elrond and Nash aim to join efforts to further develop and research interoperability as one of the main connecting bridges for the ecosystem.
TypingDNA is a behavioral biometrics company, protecting online users based on how they type on their keyboards. The company’s products are successfully used by financial institutions as well as clients from other industries such as security companies and identity access management (IAM) providers.
Elrond and TypingDNA, aim to jointly explore the integration of TypingDNA biometrics solutions into the Elrond platform and future products in order to improve security and remove the friction plaguing many blockchain platforms right now.
SmartBill is an established FinTech company providing SaaS-based services to small, and medium-sized businesses for invoicing, accounting, and inventory management. It’s invoicing and accounting SaaS platform is counting more than 60 000 clients, 2 Million invoices issued each month with a total value exceeding $350 Million each month.
Elrond and SmartBill, aim to jointly explore the potential integration of the two platforms to provide to their users and clients blockchain-based features, like trust, transparency, or traceability.
Use case
There are limitless use cases for Elrond since at its core it is a platform to launch DApps. As long as someone has a new idea for an App and want to launch a decentralized one on a blockchain — it will become a potential use-case. Right now it is way too early to speculate who will become Elrond’s anchor clients.
Common DApp use-cases:
- Games
- Marketplace
- Social apps
- Supply chain
- Digital collectibles
- Voting
- Decentralized Exchanges
- Gambling
- Finance
- Development
- Media
- Wallet
- Storage
- Identity
Markets and volume
Information from Coinmarketcap.com:
Token Price (Private): $0,00050 — ROI x6,4
Token Price (IEO): $0,00065 — ROI x4,9
TA
TBA
Competitors
Elrond marks Ethereum (2.0), Zilliqa, Dfinity, Algorand, Harmony, Quarkchain, and Multivac as their competitors, and they have written a detailed comparison to each of the aforementioned companies.
If I were to outline the main differences between those companies and Elrond, they would be as follows:
- Consensus mechanism — SPoS, this novel consensus is much more efficient than PoS or HPoW;
- Sharding — not all of the competitors even use sharding, but those who use lack wholesome approach, Elrond’s adaptive state sharding is state of the art;
- Cross-shard operations — there is a larger overhead in communication compared to the Elrond architecture;
- The finality of the cross-shard transactions is much shorter in Elrond.
Token Mechanics
Elrond has chosen the same concept as Horizen: to set up a node you have to stake the exact number of tokens — 500.000 ERD (~$1600), and there is no limit on how many nodes can be operated by 1 person.
Staking rewards model:
Elrond prevents attack vectors in 2 ways: incentivizing validators to do a proper job, slashing malicious validators.
Most of the staking rewards are paid via new monetary supply emission. Based on preliminary calculations, the overall money supply increase during the 1st year will be between 8–12%.
The supply emission algorithm is a function of the number of shards, a number of nodes, supply staked, and the incentive for targeted stake locked. Please see this document for a more detailed overview of calculations.
Emission distribution will happen as follows: 90% of all newly issued ERD will go to validators, and 10% will go to the Elrond reserve pool.
The reward will be sent when the block is produced = the rewards are included in the created block. (Information was provided by Robert Sasu)
Fees model:
Currently, Elrond uses a first-price auction model, the same as Ethereum or Bitcoin. Elrond has a minimal fee because of the needed gas to process a transaction. The rest is left currently to the user to decide how much he wants to pay for the fee. The leaders will sort their transaction pool and create a block with the highest fees. But as Elrond is a high throughput system, most of the fees will stay at the minimum level, as all of them can be processed. (Information was provided by Robert Sasu)
Elrond believes that relying on transaction fees too much creates the premises for potentially large and hard to analyze game-theoretic attacks.
Still, to create a strong incentive for validators to act in the best interest of the network Elrond propose this fee model where:
- 50% are distributed to validators
- 40% are burned
- 10% are either (a) donated to the Elrond community fund or (b) also burned
Initial staking Targets
For the bootstrapping period of the network, Elrond has set 2 clear initial targets for a number of validators required for the network.
Target scenario 1:
In order to process around 11 250 TPS from the start, Elrond would require a minimum of 5 shards plus metachain. Thus the calculation for this minimum threshold would look as follows:
11 250 TPS = 6 Shards (5 shards + metachain shard) = (500 nodes * 6) * 500 000 = 3000 nodes requiring 1 500 000 000 ERD for staking.
Targeted supply staked vs. current circulating supply (as of June 2019): 20% from 37.5%
Validator rewards/year for 7.5% supply staked: 100%
Target scenario 2:
In order to process above 22 500 TPS immediately after the beginning, Elrond would require a minimum of 11 shards plus metachain. Thus the calculation for this scenario would look as follows:
22 500 TPS = 12 Shards (11 shards + metachain shard) = (500 nodes * 12) * 500.000 = 6000 nodes requiring 3.000.000.000 ERD for staking.
Targeted supply staked vs. circulating supply: 40% from 37.5%
Validator rewards/year for 15% supply staked: 71%
Node rating
Beside stake, the eligible validator’s rating influences the chance to be selected as part of the consensus group. If the block proposer is honest and its block gets committed to 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 rating is bounded, so at some point, you can no longer increase rating, new nodes will be able to catch up to older ones in terms of chance to be selected. (Information was provided by Beniamin Mincu)
Token Metrics
Total Tokens (Genesis): 20.000.000.000 ERD
Launchpad Hard Cap: $3.250.000
Total Tokens Sold: 8.800.000.000
Percentage Sold (Private + IEO): 44,00%
Token release schedule:
Private Round: 19,00%
- 7,5% at TGE
- 6 equal tranches every 3 months after IEO (15,41% every 3 months)
Initial Exchange Offering (IEO): 25,00%
- 100% at TGE
Ecosystem Rewards: 7,00% — These tokens will be used only for incentivizing users to join the platform and/or use future products and services.
- 50% at TGE
- 50% 6 months after TGE
Marketing/Grants/Accelerator Pool: 8,50% — These funds will be distributed to individuals, developers, companies or startups willing to build and/or promote interesting tools, services or dApps on top of Elrond.
- 81,17% at the TGE, 9,41% every 6 months after TGE
Community fund: 2,00% — These funds will be distributed in accordance with the decisions made by the community through the governance system.
- 33,3% at TGE
- 33,3% 6 months after TGE
- 33,3% 12 months after TGE
Advisors: 2,50%
- 100% 1 year after TGE
Team (Founders and Core team members): 19,00%
- 10% 6 months after TGE
- 10% 12 months after TGE
- 15% 18, 24, 30 and 36 months after TGE
- 20% 42 months after TGE
Company reserve: 17,00% — These tokens are retained by Elrond to support the Elrond network and ecosystem.
- 33,3% at TGE — Can only be used for staking for 1 year after TGE
- 66,6% in 3 equal tranches over 3 years, starting 1 year after TGE
ERD Token Release Schedule
The following chart represents the number and breakdown of all ERD tokens that are intended to be released into circulation on a monthly basis.
Summary
Team: Elrond has a well-diversified team with people from different backgrounds
Idea: Elrond tackles a scaling problem with novel sharding solution, which they have successfully tested
Development stage: Testnet
Whitepaper: Very good whitepaper, describes all the features in detail, the team’s competence is obvious, this document was written by professionals who know exactly what they build. There is a simple economics draft; no BusDev plan is open to the public.
Roadmap: Outlines all major milestones that the project needs to reach,
To sum up, Elrond looks like a very promising project. It has a working (in a testing environment) solution for scalability problems, and that could really disrupt the market if the same result is seen on the mainnet. Unlike most of its competitors, Elrond supports a lot of programming languages; the smart contract languages are formally defined in K Framework, it is possible to perform formal verification of smart contracts written in these languages.
Elrond is a kind of “all-rounder” type of project; it can be considered Layer 1, Layer 2, and Interoperability project. It is both a strength and weakness: Elrond has a lot of potential use-cases and can choose it’s focus further down the line, but at the same time there is a risk of becoming “Jack of all trades, master of none.”
Elrond has a lot of competitors, and they have been in the game for a longer time, so Elrond will have to act quickly and try to launch a marketing campaign that will be able to attract anchor clients and core users. Right now, it is hard to compete with Elrond tech-wise, but their next challenge and opportunity will focus on how they will attract users and developers.
Tokenomics are only in the draft right now, but the team already made significant changes to the model:
- The required stake amount was doubled from 250 000 to 500 000
- Validator rewards were recalculated for the 24-hour Epoch
- Larger holders will be able to run validator nodes on the same machine if they have more specialized hardware.
