1

ElrondA Highly Scalable Public Blockchain via Adaptive State Sharding

and Secure Proof of Stake[Technical whitepaper — release 2 — revision 1]

Updated chapters: [5 - 13]June 19, 2019 - The Elrond Team

https://www.elrond.com/

Abstract—The advent of secure public blockchains throughBitcoin and later Ethereum, has brought forth a notable degreeof interest and capital influx, providing the premise for aglobal wave of permissionless innovation. Despite lofty promises,creating a decentralized, secure and scalable public blockchainhas proved to be a strenuous task.

This paper proposes Elrond, a novel architecture which goesbeyond state of the art by introducing a genuine state shardingscheme for practical scalability, eliminating energy and com-putational waste while ensuring distributed fairness through aSecure Proof of Stake (SPoS) consensus. Having a strong focus onsecurity, Elrond’s network is built to ensure resistance to knownsecurity problems like Sybil attack, Nothing at Stake attack andothers. In an ecosystem that strives for interconnectivity, oursolution for smart contracts offers an EVM compliant engine toensure interoperability by design.

Preliminary simulations and testnet results reflect that Elrondexceeds Visa’s average throughput and achieves an improvementbeyond three orders of magnitude or 1000x compared to theexisting viable approaches, while drastically reducing the costsof bootstrapping and storage to ensure long term sustainability.

I Introduction1 General aspects

Cryptocurrency and smart contract platforms such as Bit-coin and Ethereum have sparked considerable interest andhave become promising solutions for electronic payments,decentralized applications and potential digital stores of value.However, when compared to their centralized counterpartsin key metrics [1], the current state of affairs suggests thatpresent public blockchain iterations exhibit severe limitations,particularly with respect to scalability, hindering their main-stream adoption and delaying public use. In fact, it hasproved extremely challenging to deal with the current engi-neering boundaries imposed by the trade-offs in the blockchaintrilemma paradigm [2]. Several solutions have been proposed,but few of them have shown significant and viable results.Thus, in order to solve the scalability problem, a completerethinking of public blockchain infrastructures was required.

2 Defining the challengesSeveral challenges must be addressed properly in the pro-

cess of creating an innovative public blockchain solutiondesigned to scale:

• Full decentralization - Eliminating the need for anytrusted third party, hence removing any single point offailure;

• Robust security - Allowing secure transactions andpreventing any attacks based on known attack vectors;

• High scalability - Enabling the network to achieve aperformance at least equal to the centralized counterpart,as measured in TPS;

• Efficiency - Performing all network services with mini-mal energy and computational requirements;

• Bootstrapping and storage enhancement - Ensuring acompetitive cost for data storage and synchronization;

• Cross-chain interoperability - Enforced by design, per-mitting unlimited communication with external services.

Starting from the above challenges, we’ve created Elrondas a complete rethinking of public blockchain infrastructure,specifically designed to be secure, efficient, scalable and inter-operable. Elrond’s main contribution rests on two cornerstonebuilding blocks:

1) A genuine State Sharding approach: effectively parti-tioning the blockchain and account state into multipleshards, handled in parallel by different participatingvalidators;

2) Secure Proof of Stake consensus mechanism: animproved variation of Proof of Stake (PoS) that ensureslong term security and distributed fairness, while elimi-nating the need for energy intensive PoW algorithms.

3 Adaptive State ShardingElrond proposes a dynamically adaptive sharding mecha-

nism that enables shard computation and reorganizing basedon necessity and the number of active network nodes. Thereassignment of nodes in the shards at the beginning ofeach epoch is progressive and nondeterministic, inducing notemporary liveness penalties. Adaptive state sharding comeswith additional challenges compared to the static model. Oneof the key-points resides in how shard-splitting and shard-merging is done to prevent overall latency penalties introducedby the synchronization/communication needs when the shardnumber changes. Latency, in this case, is the communicationoverhead required by nodes, in order to retrieve the new state,once their shard address space assignment has been modified.

2

Elrond proposes a solution for this problem below, but firstsome notions have to be defined: users and nodes. Users areexternal actors and can be identified by an unique accountaddress; nodes are computers/devices in the Elrond networkthat run our protocol. Notions like users, nodes, addresses willbe further described in chapter II.1 - Entities.

Elrond solves this challenge by:1) Dividing the account address space in shards, using a

binary tree which can be built with the sole requirementof knowing the exact number of shards in a certainepoch. Using this method, the accumulated latency isreduced and the network liveness is improved in twoways. First, thanks to the designed model, the dividing ofthe account address space is predetermined by hierarchy.Hence, there is no split overhead, meaning that oneshard breaks into two shards, each of them keepingonly one half of the previous address space in additionto the associated state. Second, the latency is reducedthrough the state redundancy mechanism, as the mergeis prepared by retaining the state in the sibling nodes.

2) Introducing a technique of balancing the nodes in eachshard, to achieve overall architecture equilibrium. Thistechnique ensures a balanced workload and reward foreach node in the network.

3) Designing a built-in mechanism for automatic transac-tion routing in the corresponding shards, considerablyreduces latency as a result. The routing algorithm isdescribed in chapter IV.4 - Elrond sharding approach.

4) In order to achieve considerable improvements with re-spect to bootstrapping and storage, Elrond makes use ofa shard pruning mechanism. This ensures sustainabilityof our architecture even with a throughput of tens ofthousands of transactions per second (TPS).

4 Secure Proof of Stake (SPoS)We introduce a Secure Proof of Stake consensus mecha-

nism, that expands on Algorand’s [3] idea of a random se-lection mechanism, differentiating itself through the followingaspects:

1) Elrond introduces an improvement which reduces thelatency allowing each node in the shard to determinethe members of the consensus group (block proposer andvalidators) at the beginning of a round. This is possiblebecause the randomization factor r is stored in everyblock and is created by the block proposer using a BLSsignature [4] on the previous r.

2) The block proposer is the validator in the consensusgroup who’s hash of the public key and randomizationfactor is the smallest. In contrast to Algorand’s [3]approach, where the random committee selection cantake up to 12 seconds, in Elrond the time necessary forrandom selection of the consensus group is considerablyreduced (estimated under 100 ms) excluding networklatency. Indeed, there is no communication requirementfor this random selection process, which enables Elrondto have a newly and randomly selected group thatsucceeds in committing a new block to the ledger in

each round. The tradeoff for this enhancement relies onthe premise that an adversary cannot adapt faster thanthe round’s time frame and can choose not to proposethe block. A further improvement on the security of therandomness source, would be the use of verifiable delayfunctions (VDFs) in order to prevent any tamperingpossibilities of the randomness source until it is toolate. Currently, the research in VDFs is still ongoing- there only a few working (and poorly tested) VDFimplementations.

3) In addition to the stake factor generally used in PoSarchitectures as a sole decision input, Elrond refines itsconsensus mechanism by adding an additional weightfactor called rating. The node’s probability to be selectedin the consensus group takes into consideration bothstake and rating. The rating of a block proposer is recal-culated at the end of each epoch, except in cases whereslashing should occur, when the actual rating decreaseis done instantly, adding another layer of security bypromoting meritocracy.

4) A modified BLS multisignature scheme [5] with 2communication rounds is used by the consensus groupfor block signing

5) Elrond considers formal verification for the critical pro-tocol implementations (e.g. SPoS consensus mechanism)in order to validate the correctness of our algorithms.

II Architecture Overview1 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), usethe Elrond network to deploy signed transactions for valuetransfers or smart contracts’ execution. They can be identifiedby one of their account addresses (derived from the publickey). The nodes are represented by the devices that form theElrond network and can be passive or actively engaged inprocessing tasks. Eligible validators are active participants inElrond’s network. Specifically, they are responsible for runningconsensus, adding blocks, maintaining the state and beingrewarded for their contribution. Each eligible validator canbe uniquely identified by a public key constructed through aderivation of the address that staked the necessary amount and

Fig. 1: Relations between Elrond entities

3

the node id. Relations between entities in the Elrond protocolare shown in Fig. 1.

Furthermore, the network is divided into smaller units calledshards. An eligible validator is assigned to a shard based onan algorithm that keeps the nodes evenly distributed acrossshards, depending on the tree level. Each shard contains arandomly selected consensus group. Any block proposer isresponsible to aggregate transactions into a new block. Thevalidators are responsible to either reject, or approve theproposed block, thereby validating it and committing it to theblockchain.

2 Intrinsic token

Elrond grants access to the usage of its network throughintrinsic utility tokens called Elronds, in short ERDs. Allcosts for processing transactions, running smart contracts andrewards for various contributions to the network will be paid inERDs. References to fees, payments or balances are assumedto be in ERDs.

3 Threat model

Elrond assumes a byzantine adversarial model, where atleast 2

3n+1 of the eligible nodes in a shard are honest. Theprotocol permits the existence of adversaries that have stake orgood rating, delay or send conflicting messages, compromiseother nodes, have bugs or collude among themselves, but aslong as 2

3n+1 of the eligible validators in a shard are honest/notcompromised, the protocol can achieve consensus.

The protocol assumes highly adaptive adversaries, whichhowever cannot adapt faster than a round’s timeframe. Thecomputational power of an adversary is bounded, thereforethe cryptographic assumptions granted by the security level ofthe chosen primitives hold firmly within the complexity classof problems solvable by a Turing machine in polynomial time.

The network of honest nodes is assumed to form a wellconnected graph and the propagation of their messages is donein a bounded time ∆.

Attack vectors’ prevention1) Sybil attacks: mitigated through the stake locking when

joining the network. This way the generation of newidentities has a cost equal to the minimum stake;

2) Nothing at stake: removed through the need of multiplesignatures, not just from proposer, and the stake slashing.The reward per block compared to the stake locked willdiscourage such behavior;

3) Long range attacks: mitigated by our pruning mech-anism, the use of a randomly selected consensus groupevery round (and not just a single proposer) and stakelocking. On top of all these, our pBFT consensus algo-rithm ensures finality;

4) DDoS attacks: the consensus group is randomly sam-pled every round (few seconds); the small time framemaking DDoS almost impossible.

Other attack vectors we have taken into consideration are:shard takeover attack, transaction censorship, double spend,bribery attacks, etc.

4 ChronologyIn Elrond’s network, the timeline is split into epochs and

rounds. The epochs have a fixed duration, set to one day (canbe modified as the architecture evolves), at the end of whichthe shards reorganization and pruning is triggered. The epochsare further divided into rounds, lasting for a fixed timeframe.A new consensus group is randomly selected per shard in eachround, that can commit a maximum of one block in the shard’sledger.

New validators can join the network by locking their stake,as presented in chapter V.2 - Secure Proof of Stake. They areadded to the unassigned node pool in the current epoch e, areassigned to the waiting list of a shard at the beginning of epoche + 1, but can only become eligible validators to participatein consensus and get rewarded in the next epoch e+ 2.

The timeline aspects are further detailed in section IX.1.

III Related WorkElrond was designed upon and inspired by the ideas from

Ethereum [6], Omniledger [7], Zilliqa [8], Algorand [3] andChainSpace [9]. Our architecture goes beyond state of theart and can be seen as an augmentation of the existingmodels, improving the performance while focusing to achievea better nash equilibrium state between security, scalabilityand decentralization.

1 EthereumMuch of Ethereum’s [6] success can be attributed to the

introduction of its decentralized applications layer throughEVM [10], Solidity [11] and Web3j [12]. While Dapps havebeen one of the core features of ethereum, scalability hasproved a pressing limitation. Considerable research has beenput into solving this problem, however results have beennegligible up to this point. Still, few promising improvementsare being proposed: Casper [13] prepares an update that willreplace the current Proof of Work (PoW) consensus with aProof of Stake (PoS), while Plasma based side-chains andsharding are expected to become available in the near future,alleviating Ethereum’s scalability problem at least partially[14].

Compared to Ethereum, Elrond eliminates both energy andcomputational waste from PoW algorithms by implementing aSPoS consensus while using transaction processing parallelismthrough sharding.

2 OmniledgerOmniledger [7] proposes a novel scale-out distributed ledger

that preserves long term security under permission-less op-eration. It ensures security and correctness by using a bias-resistant public-randomness protocol for choosing large, statis-tically representative shards that process transactions. To com-mit transactions atomically across shards, Omniledger intro-duces Atomix, an efficient cross-shard commit protocol. Theconcept is a two-phase client-driven ”lock/unlock” protocolthat ensures that nodes can either fully commit a transactionacross shards, or obtain ”rejection proofs” to abort and unlock

4

the state affected by partially completed transactions. Om-niledger also optimizes performance via parallel intra-shardtransaction processing, ledger pruning via collectively-signedstate blocks, and low-latency ”trust-but-verify” validation forlow-value transactions. The consensus used in Omniledger is aBFT variation, named ByzCoinX, that increases performanceand robustness against DoS attacks.

Compared to Omniledger, Elrond has an adaptive approachon state sharding, a faster random selection of the consensusgroup and an improved security by replacing the validators’set after every round (a few seconds) not after every epoch (1day).

3 ZilliqaZilliqa [8] is the first transaction-sharding architecture that

allows the mining network to process transactions in paralleland reach a high throughput by dividing the mining networkinto shards. Specifically, its design allows a higher transactionrate as more nodes are joining the network. The key isto ensure that shards process different transactions, with nooverlaps and therefore no double-spending. Zilliqa uses pBFT[15] for consensus and PoW to establish identities and preventSybil attacks.

Compared to Zilliqa, Elrond pushes the limits of shardingby using not only transaction sharding but also state sharding.Elrond completely eliminates the PoW mechanism and usesSPoS for consensus. Both architectures are building their ownsmart contract engine, but Elrond aims not only for EVM com-pliance, so that SC written for Ethereum will run seamlesslyon our VM, but also aims to achieve interoperability betweenblockchains.

4 AlgorandAlgorand [3] proposes a public ledger that keeps the con-

venience and efficiency of centralized systems, without theinefficiencies and weaknesses of current decentralized imple-mentations. The leader and the set of verifiers are randomlychosen, based on their signature applied to the last block’squantity value. The selections are immune to manipulationsand unpredictable until the last moment. The consensus relieson a novel message-passing Byzantine Agreement that enablesthe community and the protocol to evolve without hard forks.

Compared to Algorand, Elrond doesn’t have a singleblockchain, instead it increases transaction’s throughput usingsharding. Elrond also improves on Algorand’s idea of randomselection by reducing the selection time of the consensus groupfrom over 12 seconds to less than a second, but assumes thatthe adversaries cannot adapt within a round.

5 ChainspaceChainspace [9] is a distributed ledger platform for high

integrity and transparent processing of transactions. It useslanguage agnostic and privacy-friendly smart contracts forextensibility. The sharded architecture allows a linearly scal-able transaction processing throughput using S-BAC, a noveldistributed atomic commit protocol that guarantees consistency

and offers high auditability. Privacy features are implementedthrough modern zero knowledge techniques, while the consen-sus is ensured by BFT.

Compared to Chainspace, where the TPS decreases witheach node added in a shard, Elrond’s approach is not influ-enced by the number of nodes in a shard, because the con-sensus group has a fixed size. A strong point for Chainspaceis the approach for language agnostic smart contracts, whileElrond focuses on building an abstraction layer for EVMcompliance. Both projects use different approaches for statesharding to enhance performance. However, Elrond goes astep further by anticipating the blockchain size problem inhigh throughput architectures and uses an efficient pruningmechanism. Moreover, Elrond exhibits a higher resistanceto sudden changes in node population and malicious shardtakeover by introducing shard redundancy, a new feature forsharded blockchains.

IV Scalability via Adaptive State Sharding1 Why sharding

Sharding was first used in databases and is a method for dis-tributing data across multiple machines. This scaling techniquecan be used in blockchains to partition states and transactionprocessing, so that each node would process only a fraction ofall transactions in parallel with other nodes. As long as thereis a sufficient number of nodes verifying each transaction sothat the system maintains high reliability and security, thensplitting a blockchain into shards will allow it to process manytransactions in parallel, and thus greatly improving transactionthroughput and efficiency. Sharding promises to increase thethroughput as the validator network expands, a property thatis referred to as horizontal scaling.

2 Sharding types

A comprehensive and thorough introduction [16] empha-sizes the three main types of sharding: network sharding,transaction sharding and state sharding. Network shardinghandles the way the nodes are grouped into shards and canbe used to optimize communication, as message propagationinside a shard can be done much faster than propagationto the entire network. This is the first challenge in everysharding approach and the mechanism that maps nodes toshards has to take into consideration the possible attacks froman attacker that gains control over a specific shard. Transactionsharding handles the way the transactions are mapped to theshards where they will be processed. In an account-basedsystem, the transactions could be assigned to shards based onthe sender’s address. State sharding is the most challengingapproach. In contrast to the previously described shardingmechanisms, where all nodes store the entire state, in state-sharded blockchains, each shard maintains only a portion ofthe state. Every transaction handling accounts that are indifferent shards, would need to exchange messages and updatestates in different shards. In order to increase resiliency tomalicious attacks, the nodes in the shards have to be reshuffledfrom time to time. However, moving nodes between shards

5

introduces synchronization overheads, that is, the time takenfor the newly added nodes to download the latest state. Thus,it is imperative that only a subset of all nodes should beredistributed during each epoch, to prevent down times duringthe synchronization process.

3 Sharding directions

Some sharding proposals attempt to only shard transactions[8] or only shard state [17], which increases transaction’sthroughput, either by forcing every node to store lots of statedata or to be a supercomputer [2]. Still, more recently, atleast one claim has been made about successfully performingboth transaction and state sharding, without compromising onstorage or processing power [13].

But sharding introduces some new challenges like: single-shard takeover attack, cross-shard communication, data avail-ability and the need of an abstraction layer that hides theshards. However, conditional on the fact that the aboveproblems are addressed correctly, state sharding brings con-siderable overall improvements: transaction throughput willincrease significantly due to parallel transaction processingand transaction fees will be considerably reduced. Two maincriterias widely considered to be obstacles transforming intoadvantages and incentives for mainstream adoption of theblockchain technology.

4 Elrond sharding approach

While dealing with the complexity of combining network,transaction and state sharding, Elrond’s approach was designedwith the following goals in mind:

1) Scalability without affecting availability: Increasingor decreasing the number of shards should affect anegligibly small vicinity of nodes without causing down-times, or minimizing them while updating states;

2) Dispatching and instant traceability: Finding out thedestination shard of a transaction should be determinis-tic, trivial to calculate, eliminating the need for commu-nication rounds;

3) Efficiency and adaptability: The shards should be asbalanced as possible at any given time.

Method DescriptionTo calculate an optimum number of shards Nsh in epoch

ei+1 (Nsh,i+1), we have defined one threshold coefficientfor the number of transactions in a block, θTX . VariableoptN represents the optimal number of nodes in a shard,εsh is a positive number and represents the number of nodesa shard can vary by. totalNi is the total number of nodes(eligible validators, nodes in the waiting lists and newly addednodes in the node pool) on all shards in epoch ei, whileNTXB,i is the average number of transactions in a block onall shards in epoch ei. Nsh,0 will be considered as 1. Thetotal number of shards Nsh,i+1 will change if the number ofnodes totalNi in the network changes and if the blockchainutilization needs it: if the number of nodes increases above athreshold nSplit from one epoch to another and the averagenumber of transactions per block is greater than the threshold

number of transactions per block NTXB,i > θTX or if thenumber of nodes decreases below a threshold nMerge asshown in function ComputeShardsN .

1: function COMPUTESHARDSN(totalNi+1, Nsh,i)2: nSplit← (Nsh,i + 1) ∗ (optN + εsh)3: nMerge← (Nsh,i − 1) ∗ a4: Nsh,i+1 ← Nsh,i

5: if (totalNi+1 > nSplit and NTXB,i > θTX ) then6: Nsh,i+1 ← totalNi+1/(optN + εsh)7: else if totalNi+1 < nMerge then8: Nsh,i+1 ← totalNi+1/(optN)

9: return Nsh,i+1

From one epoch to another, there is a probability that thenumber of active nodes changes. If this aspect influences thenumber of shards, anyone can calculate the two masks m1 andm2, used in transaction dispatching.

1: function COMPUTEM1ANDM2(Nsh)2: n← math.ceil(log2Nsh)3: m1 ← (1 << n)− 14: m2 ← (1 << (n− 1))− 15: return m1,m2

As the main goal is to increase the throughput beyondthousands of transactions per second and to diminish the cross-shard communication, Elrond proposes a dispatching mecha-nism which determines automatically the shards involved inthe current transaction and routes the transaction accordingly.The dispatcher will take into consideration the account address(addr) of the transaction sender/receiver. The result is thenumber of the shard (shard) the transaction will be dispatchedto.

1: function COMPUTESHARD(Nsh, addr,m1,m2)2: shard← (addr and m1)3: if shard > Nsh then4: shard← (addr and m2)5: return shard

The entire sharding scheme is based on a binary treestructure that distributes the account addresses, favors thescalability and deals with the state transitions. A representationof the tree can be seen in Fig. 2.

The presented tree structure is merely a logical represen-tation of the account address space used for a deterministicmapping; e.g. shard allocation, sibling computation etc. Theleaves of the binary tree represent the shards with their IDnumber. Starting from root (node/shard 0), if there is only oneshard/leaf (a), all account addresses are mapped to this oneand all transactions will be executed here. Further on, if theformula for Nsh dictates the necessity of 2 shards (b), theaddress space will be split in equal parts, according to the lastbits in the address.

Sometimes, the tree can also become unbalanced (c) if Nsh

is not a power of 2. This case only affects the leaves on the

6

Fig. 2: Example of a sharding tree structure

last level. The structure will become balanced again when thenumber of shards reaches a power of 2.

The unbalancing of the binary tree causes the shards locatedin the lowest level to have half the address space of nodesof a shard located one level higher, so it can be argued thatthe active nodes allocated to these shards will have a lowerfee income - block rewards are not affected. However, thisproblem is solved by having a third of each shard nodesredistributed randomly each epoch (detailed in the Chronologysection) and having a balanced distribution of nodes accordingto the tree level.

Looking at the tree, starting from any leaf and goingthrough branches towards the root, the encoding from branchesrepresents the last n bits of the account addresses that willhave their associated originating transactions processed by thatleaf/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. Usingthis hierarchy, the shard that will split when Nsh increases orthe shards that will merge when Nsh decreases can easily becalculated. The entire state sharding mechanism benefits fromthis structure by always keeping the address and the associatedstate within the same shard.

Knowing Nsh, any node can follow the redistribution pro-cess without the need of communication. The allocation ofID’s for the new shards is incremental and reducing thenumber 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 isthe highest numbered shard (shmerge=Nsh-1). Finding theshard number that shmerge will be merged with is trivial.According to the tree structure, the resulting shard has thesibling’s number:

1: function COMPUTESIBLING(shmerge, n)2: sibling ← (shmerge xor (1 << (n− 1)))3: return sibling

For shard redundancy, traceability of the state transitionsand fast scaling, it is important to determine the sibling andparent of a generic shard with number p:

1: function COMPUTEPARENTSIBLINGS(n, p,Nsh)2: mask1 ← 1 << (n− 1)3: mask2 ← 1 << (n− 2)4: sibling ← (p xor mask1)5: parent← min(p, sibling)6: if sibling ≥ Nsh then7: sibling ← (p xor mask2)8: sibling2 ← (sibling xor mask1)9: parent← min(p, sibling)

10: if sibling2 ≥ Nsh then . sibling is a shard11: return parent, sibling,NULL12: else13: . sibling is a subtree with14: . shards (sibling, sibling2)15: return parent, sibling, sibling216: else . sibling is a shard17: return parent, sibling,NULL

Shard redundancyOn blockchain, state sharding is susceptible to shard failure

when there is an insufficient number of online nodes in ashard or the distribution is localized geographically. In theunlikely case when one shard fails (either the shard cannotbe contacted - all nodes are offline, or consensus cannot bereached - more than 1

3 of nodes are not responding), there isa high risk that the entire architecture relies only on super-full nodes [2], which fully download every block of everyshard, fully verifying everything. As displayed in Fig. 3, ourprotocol has a protection mechanism that introduces a tradeoffin the state holding structure by enforcing the shards fromthe last tree level to also hold the state from their siblings.This mechanism reduces the communication and eliminatesthe bootstrapping when sibling shards are merging since theyalready have the data.

Context switchingTo preserve security in sharded public blockchains, context

switching becomes crucial [7]. This refers to the realloca-tion of the active nodes between shards on a fixed timeinterval by some random criteria. In Elrond’s approach, thecontext switching represents a security improvement, but alsoincreases the complexity required to maintain consistencybetween multiple states. The state transition has the biggest

7

Fig. 3: Shard redundancy across epochs

footprint on performance since the movement of active nodesrequires to resync the state, blockchain and transactions along-side the eligible nodes in the new shard. At the start ofeach epoch, in order to maintain liveness, only less than 1

3of these nodes will be uniformly re-distributed across shards.This mechanism is highly effective against forming maliciousgroups.

5 Notarization (Meta) chain

All network and global data operations (node joining thenetwork, node leaving the network, eligible validator listscomputation, nodes assignment to the shard’s waiting lists,consensus agreement on a block in a specific shard challengesfor invalid blocks will be notarized in the metachain. Themetachain consensus is run by a different shard that com-municates with all other shards and facilitates cross-shardoperations. Every round of every epoch, the metachain receivesblock headers from the other shards and, if necessary, proofsfor the challenges of the invalid blocks. This informationwill be aggregated into blocks on the metachain on whichconsensus has to be run. Once the blocks are validated inthe consensus group, shards can request information aboutblocks, miniblocks (see chapter VII), eligible validators, nodesin waiting lists etc., in order to securely process cross-shardtransactions. Further details about the cross-shard transactionexecution, communication between shards and metachain will

be presented in Chapter VII Cross-shard transaction process-ing.

V Consensus via Secure Proof of Stake1 Consensus Analysis

The first blockchain consensus algorithm based on Proofof Work (PoW), is used in Bitcoin, Ethereum and otherblockchain platforms. In Proof of Work each node is requiredto solve a mathematical puzzle (hard to calculate but easy toverify). And the first node that finishes the puzzle will collectthe reward [18]. Proof of Work mechanisms successfullyprevent double-spending, DDoS and Sybil attacks at the costof high energy consumption.

Proof of Stake (PoS) is a novel and more efficient con-sensus mechanism proposed as an alternative to the intensiveenergy and computational use in Proof of Work consensusmechanisms. PoS can be found in many new architectures likeCardano [19] and Algorand [3] or can be used in next versionof Ethereum. In PoS the node that proposes the next blockis selected by a combination of stake (wealth), randomnessand/or age. It mitigates the PoW energy problem but also putstwo important issues on the table: the Nothing at Stake attackand a higher centralization risk.

Proof of Meme as envisioned in Constellation [20], is analgorithm based on the node’s historical participation on thenetwork. Its behaviour is stored in a matrix of weights in theblockchain and supports changes over time. Also, it allowsnew nodes to gain trust by building up reputation. The maindrawback regarding Sybil attacks is alleviated through theNetFlow algorithm.

Delegated Proof of Stake (DPoS) found in Bitshares [21],Steemit [22] and EOS [23] is a hybrid between Proof ofAuthority and Proof of Stake in which the few nodes respon-sible for deploying new blocks are elected by stakeholders.Although it has a high throughput, the model is susceptible tohuman related social problems such as bribing and corruption.Also, a small number of delegates makes the system prone toDDoS attacks and centralization.

2 Secure Proof of Stake (SPoS)Elrond’s approach to consensus is made by combining

random validators’ selection, eligibility through stake andrating, 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 public key (Pk),rating (default is 0) and the locked stake. If ni wishesto participate in the consensus, it has to first registerthrough a smart contract, by sending a transaction thatcontains an amount equal to the minimum required stakeand other information (Pks, a public key derived fromPk and nodeid that will be used for the signing processin order not to use a real wallet address).

2) The node ni joins the node pool and waits for theshard assignment at the end of the current epoch e. Theshard assignment mechanism creates a new set of nodescontaining all the nodes that joined in epoch e and all

8

the nodes that need to be reshuffled (less than 13 of

every shard). All nodes in this set will be reassignedto the waiting lists of shards. Wj represents j’s shardwaiting list and Nsh represents the number of shards. Anode also has a secret key sk that by nature is not to bemade public.

ni = (Pki, ratingi, stakei)

ni ∈Wj , 0 ≤ j < Nsh

3) At the end of the epoch in which it has joined, the nodewill be moved to the list of eligible nodes (Ej) of ashard j, where e is the current epoch.

ni ∈Wj,e−1 → ni 6∈Wj,e, ni ∈ Ej,e

4) Each node from the list Ej can be selected as part of anoptimally dimensioned consensus group (in terms of se-curity and communication), by a deterministic function,based on the randomness source added to the previousblock, the round r and a set of variation parameters.The random number, known to all shard nodes throughgossip, cannot be predicted before the block is actuallysigned by the previous consensus group. This propertymakes it a good source of randomness and preventshighly adaptive malicious attacks. We define a selectionfunction to return the set of chosen nodes (consensusgroup) Nchosen with the first being the block proposer,that takes following parameters: E, r and sigr−1 - theprevious block signature.

Nchosen = f(E, r, sigr−1), where Nchosen ⊂ E

5) The block will be created by the block proposer and thevalidators will co-sign it based on a modified practicalByzantine Fault Tolerance (pBFT).

6) If, for any reason, the block proposer did not create ablock during its allocated time slot (malicious, offline,etc.), round r will be used together with the randomnesssource from the last block to select a new consensusgroup.

If the current block proposer acts in a malicious way, the restof the group members apply a negative feedback to change itsrating, decreasing or even cancelling out the chances that thisparticular node will be selected again. The feedback functionfor the block proposer (ni) in round number r, with parameterratingModifier ∈ Z is computed as:

feedbackfunction = ff(ni, ratingModifier, r)

When ratingModifier < 0, slashing occurs so the nodeni loses its stake.

The consensus protocol remains safe in the face of DDoSattacks by having a high number of possible validators fromthe list E (hundreds of nodes) and no way to predict the orderof the validators before they are selected.

To reduce the communication overhead that comes with anincreased number of shards, a consensus will be run on acomposite 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 shardtransactions for which confirmation proof was received;

• Multiple mini-blocks: each of them holding cross shardtransactions for a different shard;

The consensus will be run only once, on the compositeblock containing both intra- and cross-shard transactions. Afterconsensus is reached, the block header of each shard is sentto the metachain for notarization.

VI Cryptographic Layer1 Signature Analysis

Digital signatures are cryptographic primitives used toachieve information security by providing several propertieslike message authentication, data integrity and non-repudiation[24].

Most of the schemes used for existing blockchain platformsrely on the discrete logarithm (DL) problem: one-way expo-nentiation function y → αymod p. It is scientifically proventhat calculating the discrete logarithm with base is hard [25].

Elliptic curve cryptography (ECC) uses a cyclic group ofpoints instead of a cyclic group of integers. The schemereduces the computational effort, such that for key lengthsof only 160 - 256 bits, ECC provides same security level thatRSA, Elgamal, DSA and others provide for key lengths of1024 - 3072 bits (see Table 1 [24]).

The reason why ECC provides a similar security level formuch smaller parameter lengths is because existing attacks onelliptic curve groups are weaker than the existing integer DLattacks, the complexity of such algorithms require on average√p steps to solve. This means that an elliptic curve using a

prime p of 256 bit length provides on average a security of2128 steps needed to break it [24].

Both Ethereum and Bitcoin use curve cryptography, withthe ECDSA signing algorithm. The security of the algorithmis very dependent on the random number generator, becauseif the generator does not produce a different number on eachquery, the private key can be leaked [26].

Another digital signature scheme is EdDSA, a Schnorrvariant based on twisted Edwards curves that support fastarithmetic [27]. In contrast to ECDSA, it is provably non-malleable, meaning that starting from a simple signature, itis impossible to find another set of parameters that definesthe same point on the elliptic curve [28], [29]. Additionally,EdDSA doesn’t need a random number generator because it

AlgorithmFamily

Cryptosystems

Security level (bit)80 128 192 256

Integerfactorization RSA 1024 3072 7680 15360

Discretelogarithm

DH, DSA,Elgamal 1024 3072 7680 15360

Ellipticcurves

ECDH,ECDSA 160 256 384 512

Symmetrickey

AES,3DES 80 128 192 256

TABLE 1: Bit lengths of public-key algorithms for differentsecurity levels

9

uses a nonce, calculated as the hash of the private key andthe message, so the attack vector of a broken random numbergenerator that can reveal the private key is avoided.

Schnorr signature variants are gaining more attention [8],[30] due to a native multi-signature capability and beingprovably secure in the random oracle model [31]. A multi-signature scheme is a combination of a signing and verificationalgorithms, where multiple signers, each with their own privateand public keys, can sign the same message, producing a singlesignature [32], [33]. This signature can then be checked bya verifier which has access to the message and the publickeys of the signers. A sub-optimal method would be to haveeach node calculate his own signature and then concatenateall results in a single string. However, such an approach isunfeasible as the generated string size grows with the numberof signers. A practical solution would be to aggregate theoutput into a single fixed size signature, independent of thenumber of participants. There have been multiple proposalsof such schemes, most of them are susceptible to rogue-key(cancellation) attacks. One solution for this problem wouldbe to introduce a step where each signer needs to provepossession of the private key associated with its public key[34].

Bellare and Neven [35] (BN) proposed a secure multi-signature scheme without a proof of possession, in the plainpublic key model, under the discrete logarithm assumption[31]. The participants commit first to their share Ri by prop-agating its hash to all other signers so they cannot calculatea function of it. Each signer computes a different challengefor their partial signature. However, this scheme sacrifices thepublic key aggregation. In this case, the verification of theaggregated signature, requires the public key from each signer.

A recent paper by Gregory Maxwell et al. [29] proposesanother multi-signature scheme in the plain public key model[36], under the ’one more discrete logarithm’ assumption(OMDL). This approach improves the previous scheme [35] byreducing the communication rounds from 3 to 2, reintroducingthe key aggregation with a higher complexity cost.

BLS [4] is another interesting signature scheme, from theWeil pairing, which bases its security on the ComputationalDiffie-Hellman assumption on certain elliptic curves and gen-erates short signatures. It has several useful properties likebatch verification, signature aggregation, public key aggrega-tion, making BLS a good candidate for threshold and multi-signature schemes.

Dan Boneh, Manu Drijvers and Gregory Neven recentlyproposed a BLS multi-signature scheme [5], using ideas fromthe previous work of [35], [30] to provide the scheme withdefenses against rogue key attacks. The scheme supportsefficient verification with only two pairings needed to verifya multi-signature and without any proof of knowledge of thesecret key (works in the plain public key model). Anotheradvantage is that the multi-signature can be created in onlytwo communication rounds.

For traceability and security reasons, a consensus based ona reduced set of validators requires the public key from eachsigner. In this context, our analysis concludes that the mostappropriate multi-signature scheme for block signing in Elrond

is BLS multi-signature [5], which is faster overall than theother options due to only two communication rounds.

2 Block signing in ElrondFor block signing, Elrond uses curve cryptography based

on the BLS multi-signature scheme over the bn256 bilineargroup, which implements the Optimal Ate pairing over a 256-bit Barreto Naehrig curve. The bilinear pairing is defined as:

e : g0 × g1 → gt (1)

where g0, g1 and gt are elliptic curves of prime order p definedby bn256, and e is a bilinear map (i.e. pairing function). LetG0 and G1 be generators for g0 and g1. Also, let H0 be ahashing function that produces points on the curve g0:

H0 :M→ g0 (2)

where M is the set of all possible binary messages of anylength. The signing scheme used by Elrond employs a secondhasing function as well, with parameters known by all signers:

H1 :M→ Zp (3)

Each signer i has its own private/public key pair (ski, Pki),where ski is randomly chosen from Zp. For each key pair, theproperty Pki = ski ·G1 holds.

Let L = Pk1, Pk2, ..., Pkn be the set of public keys ofall possible signers during a specific round which, in thecase of Elrond, is the set of public keys of all the nodes inthe consensus group. Below, the two stages of block signingprocess is presented: signing and verification.

Practical signing - Round 1The leader of the consensus group creates a block with

transactions, then signs and broadcasts this block to theconsensus group members.

Practical signing - Round 2Each member of the consensus group (including the leader)

who receives the block must validate it, and if found valid, itsigns it with BLS and then sends the signature to the leader:

Sigi = ski ∗H0(m) (4)

where Sigi is a point on g0.

Practical signing - Round 3The leader waits to receive the signatures for a specific

timeframe. If it does not receive at least 23 · n + 1 signatures

in that timeframe, the consensus round is aborted. But if theleader does receive 2

3 · n+ 1 or more valid signatures, it usesthem to generate the aggregated signature:

SigAgg =∑i

H1(Pki) · Sigi ·B[i] (5)

where SigAgg is a point on g0.The leader then adds the aggregated signature to the block

together with the selected signers bitmap B, where a 1indicates that the corresponding signer in the list L had itssignature added to the aggregated signature SigAgg.

10

Practical verificationGiven the list of public keys L, the bitmap for the signers B,

the aggregated signature SigAgg, and a message m (block),the verifier computes the aggregated public key:

PkAgg =∑i

H1(Pki) · Pki ·Bi (6)

The result, PkAgg, is a point on g1. The final verification is

e(G1, SigAgg) == e(PkAgg,H0(m)) (7)

where e is the pairing function.

VII Cross-shard Execution

For an in depth example of how the cross-shard transactionsare being executed and how the communication betweenshards and the metachain occurs, we are simplifying the entireprocess to just two shards and the metachain. Assuming thata user generates a transaction from his wallet, which has anaddress in shard 0 and wants to send ERDs to another user thathas a wallet with an address in shard 1, the steps depicted inFig. 4 are required for processing the cross-shard transaction.

As mentioned in chapter V - Consensus via Secure Proof ofStake, the blocks structure is represented by a block Headerthat contains information about the block (block nonce, round,proposer, validators timestamp etc), and a list of miniblocksfor each shard that contain the actual transactions inside. Everyminiblock contains all transactions that have either the senderin the current shard and the receiver in another shard or thesender in a different shard and the destination in the currentshard. In our case, for a block in shard 0, there will normallybe 3 miniblocks:

• miniblock 0: containing the intrashard transactions forshard 0

• miniblock 1: containing cross-shard transactions with thesender in shard 0 and destination in shard 1

• miniblock 2: containing cross-shard transactions withsender in shard 1 and destination in shard 0. Thesetransactions were already processed in the sender shard1 and will be finalized after the processing also in thecurrent shard.

There is no limitation on the number of miniblocks withthe same sender and receiver in one block. Meaning multipleminiblocks with the same sender and receiver can appear inthe same block.

1 ProcessingCurrently the atomic unit of processing in cross-shard

execution is a miniblock: either all the transactions of theminiblock are processed at once or none and the miniblock’sexecution will be retried in the next round.

Our cross-shard transaction strategy uses and asynchronousmodel. Validation and processing is done first in sender’s shardand then in receivers’ shard. Transactions are first dispatchedin the sender’s shard, as it can fully validate any transactioninitiated from the account in this shard – mainly the currentbalance. Afterwards, in the receivers’ shard, the nodes onlyneed proof of execution offered by metachain, do signatureverification and check for replay attack and finally updatethe balance for the receiver, adding the amount from thetransaction.

Shard 0 processes both intra-shard transactions in miniblock0 and a set of cross-shard transactions that have addresses fromshard 1 as a receiver in miniblock 1. The block header andminiblocks are sent to the metachain. The metachain notarizesthe block from shard 0, by creating a new metachain block(metablock) that contains the following information about eachminiblock: sender shard ID, receiver shard ID, miniblock hash.

Fig. 4: Cross-shard transaction processing

11

Shard 1 fetches the hash of miniblock 1 from metablock,requests the miniblock from shard 0, parses the transactionlist, requests missing transactions (if any), executes the sameminiblock 1 in shard 1 and sends to the metachain resultingblock. After notarization the cross transaction set can beconsidered finalized.

The next diagram shows the number of rounds required for atransaction to be finalized. The rounds are considered betweenthe first inclusion in a miniblock until the last miniblock isnotarised.

VIII Smart ContractsThe execution of smart contracts is a key element in all

future blockchain architectures. Most of the existing solutionsavoid to properly explain the transactions and data dependency.This context leads to the following two scenarios:

1) When there is no direct correlation between smart con-tract transactions, as displayed in Fig. 5, any architecturecan use out of order scheduling. This means there areno additional constraints on the time and place (shard)where a smart contract is executed.

2) The second scenario refers to the parallelism induced bythe transactions that involve correlated smart contracts[37]. This case, reflected in Fig. 6, adds additionalpressure on the performance and considerably increasesthe complexity. Basically there must be a mechanismto ensure that contracts are executed in the right orderand on the right place (shard). To cover this aspect,Elrond protocol proposes a solution that assigns andmoves the smart contract to the same shard where theirstatic dependencies reside. This way most, if not all SCcalls will have dependencies in the same shard and nocross-shard locking/unlocking will be needed.

Elrond focuses on the implementation of the Elrond VirtualMachine, an EVM compliant engine. The EVM compliance

Fig. 5: Independent transaction processing under simplesmart contracts that can be executed out of order

Fig. 6: Mechanism for correlated smart contracts that can beexecuted only sequentially

Fig. 7: Abstraction Layer for Smart Contracts

is extremely important for adoption purposes, due to the largenumber of smart contracts built on Ethereum’s platform.

The Elrond Virtual Machine’s implementation will hide theunderlying architecture isolating the smart contract developersfrom system internals ensuring a proper abstraction layer, asdisplayed in Fig. 7.

In Elrond, cross chain interoperability can be implementedby using an adapter mechanism at the Virtual Machine level asproposed by Cosmos [38]. This approach requires specializedadapters and an external medium for communication betweenadapter SC for each chain that will interoperate with Elrond.The value exchange will be operated using some specializedsmart contracts acting as asset custodians, capable of takingcustody of adapted chain native tokens and issuing Elrondnative tokens.

1 VM InfrastructureElrond builds its VM infrastructure on top of the K Frame-

work, which is an executable semantic framework whereprogramming languages, calculi, as well as type systems orformal analysis tools can be defined [39].

The greatest advantage of using the K framework is thatwith it, smart contract languages can be unambiguously de-fined, eliminating the potential for unspecified behavior andbugs that are hard to detect.

The K Framework is executable, in the sense that the seman-tic specifications of languages can be directly used as workinginterpreters for the languages in question. More specifically,one can either run programs against the specifications usingthe K Framework core implementation directly, or one cangenerate an interpreter in several programming languages.These are also referred to as ”backends”. For the sake ofexecution speed and ease of interoperability, Elrond uses itsown custom-built K Framework backend.

2 Smart contract languagesOne great advantage of the K Framework is that one can

generate an interpreter for any language defined in K, withoutthe need for additional programming. This also means thatinterpreters produced this way are ”correct-by-construction”.

12

There are several smart contract languages specified in the KFramework already, or with their specifications under develop-ment. Elrond Network will support three low-level languages:IELE VM, KEVM, and WASM.

• IELE VM is an intermediate-level language, in the styleof LLVM, but adapted for the blockchain. It was builtdirectly in K, no other specification or implementation ofit exists outside of the K framework [40]. Its purposeis to be human readable, fast, and to overcome somelimitations of EVM. Elrond uses a slightly altered versionof IELE - most changes are related to account addressmanagement. Smart contract developers can program inIELE directly, but most will choose to code in Solidityand then use a Solidity to IELE compiler, as can be seenin Fig. 8.

• KEVM is a version of the Ethereum Virtual Machine(EVM), written in K [41]. Certain vulnerabilities of EVMare fixed in the K version, or the vulnerable features areleft out entirely.

• Web Assembly (WASM) is a binary instruction formatfor a stack-based virtual machine, which can be used forrunning smart contracts. A WASM infrastructure enablesdevelopers to write smart contracts in C/C++, Rust, C#,and others.

Having a language specification and generating the inter-preter is only half of the challenge. The other half is integratingthe generated interpreter with the Elrond network. We havebuilt a common VM interface, that enables us to plug in anyVM into an Elrond node as shown in Fig. 9. Each VM thenhas an adapter that implements this interface. Each contract issaved as bytecode of the VM for which it was compiled andruns on its corresponding VM.

3 Support for formal modelling and verificationBecause the smart contract languages are formally defined

in K Framework, it is possible to perform formal verificationof smart contracts written in these languages. To do this, itis necessary to also formally model their requirements, whichcan also be performed using the K Framework [42].

Fig. 8: Elrond VM execution

Fig. 9: Elrond VM components

4 Smart contracts on the sharded architecture

Smart contracts on sharded architectures are still in theearly stages of research and development and pose seriouschallenges. Protocols like Atomix [7] or S-BAC [9] representa starting point. Dynamic smart contract dependencies cannotbe resolved by moving the SCs into the same shard, as atdeployment time, not all the dependencies can be calculated.

Solution currently research in the space:1) A locking mechanism that allows the atomic execution

of smart contract from different shards, ensures that theinvolved SCs will be either all executed at the sametime, or none at all. This requires multiple interactionmessages and synchronization between consensuses ofdifferent shards. [9]

2) Cross-shard contract yanking proposal for Ethereum 2.0would move that smart contract code and data into thecaller shard at the execution time. Atomic execution isnot needed, but the locking mechanism is mandatoryon the moved SC, which would block the executionof SC for other transactions. The locking mechanismis simpler, but it needs to transfer the whole internalstate of the SC. [43]

Following Ethereum’s model, Elrond has the followingtransaction types:

1) SC construction and deployment: transactions receiveraddress is empty and data field contains the smartcontract code as byte array;

2) SC method invoking: transaction has a non empty re-ceiver address and that address has an associated code;

3) Payment transactions: transaction has a non empty re-ceiver and that address does not have code.

Elrond’s approach to this problem is to use asynchronouscross-shard execution model in case of smart contracts. Theuser creates a smart contract execution transaction. If thesmart contract is not in the current shard, the transaction istreated as a payment transaction, the value of the transactionis subtracted from the sender account and it is added tothe block where the sender shard resides, into a miniblockwith the destination shard where the receiver account is. Thetransaction is notarized by metachain, then processed by thedestination shard. In the destination shard, the transaction istreated as SC method invoking, as the receiver address isa smart contract which exists in this shard. For the smartcontract call a temporary account which shadows the senderaccount is created, with the balance from the transaction valueand the smart contract is called. After the execution, thesmart contract might return results which affects a number

13

of accounts from different shards. All the results, which affectin-shard accounts are executed in the same round. For thoseaccounts which are not in the shard where the smart contractwas executed, transactions called Smart Contract Results willbe created, saving the smart contract execution output foreach of these accounts. SCR miniblocks are created for eachdestination shard. These miniblocks are notarized the sameway as cross-shard transactions by metachain, then processedby the respective shards, where the accounts resides. In caseone smart contract calls dynamically another smart contractfrom another shard, this call is saved as an intermediate resultand treated the same as for accounts.

The solution has multiple steps and the finalization of across-shard smart contract call will need at least 5 rounds, butit does not need locking and state movement across shards.

IX Bootstrapping and Storage

1 Timeline division

Proof of Stake systems tend to generally divide timeline intoepochs and each epoch into smaller rounds [19]. The timelineand terminology may differ between architectures but most ofthem use a similar approach.

EpochsIn Elrond Protocol, each epoch has a fixed duration, initially

set to 24 hours (might suffer updates after several testnet con-firmation stages). During this timeframe, the configuration ofthe shards remains unchanged. The system adapts to scalabilitydemands between epochs by modifying the number of shards.To prevent collusion, after an epoch, the configuration of eachshard needs to change. While reshuffling all nodes betweenshards would provide the highest security level, it would affectthe system’s liveness by introducing additional latency due tobootstrapping. For this reason, at the end of each epoch, lessthan 1

3 of the eligible validators, belonging to a shard will beredistributed non-deterministically and uniformly to the othershards’ waiting lists.

Only prior to the start of a new epoch, the validatordistribution to shards can be determined, without additionalcommunication as displayed in Fig. 10.

The node shuffling process runs in multiple steps:

1) The new nodes registered in the current epoch ei landin the unassigned node pool until the end of the currentepoch;

2) Less than 13 of the nodes in every shard are randomly

selected to be reshuffled and are added to the assignednode pool;

3) The new number of shards Nsh,i+1 is computed basedon the number of nodes in the network ki and networkusage;

4) Nodes previously in all shard’s waiting lists, that are cur-rently synchronized, are added to the eligible validator’slists;

5) The newly added nodes from the unassigned node poolare uniformly random distributed across all shards’waiting lists during epoch ei+1;

6) The reshuffled nodes from the assigned node pool areredistributed with higher ratios to shards’ waiting liststhat will need to split in the next epoch ei+2.

RoundsEach round has a fixed time duration of 5 seconds (might

suffer updates after several testnet confirmation stages). Duringeach round, a new block can be produced within every shardby a randomly selected set of block validators (including oneblock proposer). From one round to another the set is changedusing the eligible nodes list, as detailed in the chapter IV.

As described before, the reconfiguration of shards withinepochs and the arbitrary selection of validators within roundsdiscourages the creation of unfair coalitions, diminishes thepossibility of DDoS and bribery attacks while maintainingdecentralization and a high transactions throughput.

2 Pruning

A high throughput will lead to a distributed ledgerthat rapidly grows in size and increases bootstrapping cost(time+storage), as highlighted in section XI.1.

This cost can be addressed by using efficient pruningalgorithms, that can summarize the blockchain’s full state in amore condensed structure. The pruning mechanism is similarto the stable checkpoints in pBFT [15] and compresses theentire ledger state.

Elrond protocol makes use of an efficient pruning algorithm[7] detailed below. Let us consider that e is the current epochand a is the current shard:

1) the shard nodes keep track of the account balances of ein a Merkle tree [44];

2) at the end of each epoch, the block proposer creates astate block sb(a, e), which stores the hash of the Merkletree’s root in the block’s header and the balances in theblock’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 blockfor epoch e+ 1;

5) at the end of epoch e+ 1, nodes will drop the body ofsb(a, e) and all blocks preceding sb(a, e).

Using this mechanism, the bootstrapping of the new nodesshould be very efficient. Actually, they start only from thelast valid state block and compute only the following blocksinstead of its full history.

X Security Evaluation1 Randomness source

Elrond makes use of random numbers in its operation e.g.for the random sampling of block proposer and validators intoconsensus groups and the shuffling of nodes between shardsat the end of an epoch. Because these features contributeto Elrond’s security guarantees, it is therefore important tomake use of random numbers that are provably unbiasable andunpredictable. In addition to these properties, the generation

14

Fig. 10: Shuffling the nodes at the end of each epoch

of random numbers also needs to be efficient so that it can beused in a scalable and high throughput blockchain architecture.

These properties can be found in some asymmetric cryptog-raphy schemes, like the BLS signing scheme. One importantproperty of BLS is that using the same private key to signthe same message always produces the same results. This issimilar to what is achieved using ECDSA with deterministick generation and is due to the scheme not using any randomparameters:

sig = sk ·H(m) (8)

where H is a hashing function that hashes to points on theused curve and sk is the private key.

2 Randomness creation in ElrondOne random number is created in every round, and added

by the block proposer to every block in the blockchain. Thisensures that the random numbers are unpredictable, as eachrandom number is the signature of a different block proposerover the previous randomness source. The creation of randomnumbers is detailed below as part of one consensus round:

1) New consensus group is selected using the randomnesssource from the previous block header. Consensus groupis formed by a block proposer and validators.

2) The block proposer signs the previous randomnesssource with BLS, adds the signature to the proposed

block header as new randomness source, then broadcaststhis block to the consensus group.

3) Each member of the consensus group validates therandomness source as part of block validation, and sendstheir block signature to the block proposer.

4) Block proposer aggregates the validators block signa-tures and broadcasts the block with the aggregated blocksignature and the new randomness source to the wholeshard.

The evolution of randomness source in each round can beseen as an unbiasable and verifiable blockchain, where eachnew random number can be linked to and verified against theprevious random number.

3 ”K” block finality scheme

The signed block at round n is final, if and only if blocksn+ 1, n+ 2, ..., n + k are signed. Furthermore, a final blockcannot be reverted. The metachain notarizes only final blocksto 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 andcorrectness is verified at block creation and at block validationas well. The chosen k parameter is 1 and this ensures forksof maximum 2 blocks length. The probability that a malicioussuper majority (> 2

3 · n + 1) is selected in the shard for the

15

same round in the same consensus is 10−9, even if 33% ofthe nodes from the shard are malicious. In that case they canpropose a block and sign it - let’s call it block m, but it willnot be notarized by the metachain. The metachain notarizesblock m, only if block m+ 1 is built on top of it. In order tocreate block m+1 the next consensus group has to agree withblock m. Only a malicious group will agree with block m, sothe next group must have a malicious super majority again.As the random seed for group selection cannot be tamperedwith, the probability of selecting one more malicious supermajority group is 10−9 (5.38 · 10−10, to be exact). Theprobability of signing two consecutive malicious blocks equalswith selecting two subgroups with at least ( 23 ·n+1) membersfrom the malicious group consequently. The probability forthis is 10−18. Furthermore, the consequently selected groupsmust be colluding, otherwise the blocks will not be signed.

4 Fisherman challengeWhen one invalid block is proposed by a malicious majority,

the shard state root is tampered with an invalid result (afterincluding invalid changes to the state tree). By providing thecombined merkle proof for a number of accounts, an honestnode could raise a challenge with a proof. The honest nodeswill provide the block of transactions, the previous reducedmerkle tree with all affected accounts before applying thechallenged block and the smart contract states, thus demon-strating the invalid transaction / state. If a challenge with theproof is not provided in the bounded time frame, the blockis considered valid. The cost of one invalid challenge is theentire stake of the node which raised the challenge.

The metachain detects the inconsistency, either an invalidtransaction, or an invalid state root, through the presentedchallenges and proofs. This can be traced and the consensusgroup can be slashed. At the same time the challenger can berewarded with part of the slashed amount. Another problemis when a malicious group hides the invalid block from othernodes - non-malicious ones. However, by making it mandatoryfor the current consensus to propagate the produced block tothe sibling shard and to the observer nodes, the data cannotbe hidden anymore. The communication overhead is furtherreduced by sending only the intrashard miniblock to the siblingshard. The cross shard miniblocks are always sent on differenttopics accessible by interested nodes. In the end, challengescan be raised by multiple honest nodes. Another security pro-tection is given by the setup of P2P topics. The communicationfrom one shard toward the metachain is done through a definedset of topics / channels, which can be listened to by anyhonest validator - the metachain will not accept any othermessages from other channels. This solution introduces somedelay in the metachain only in case of challenges, which arevery low in number and highly improbable since if detected(high probability of being detected) the nodes risk their entirestake.

5 Shard reorganizationAfter each epoch, less than 1

3 · n of the nodes from eachshard are redistributed uniformly and non-deterministically

across the other shards, to prevent collusion. This method addsbootstrapping overhead for the nodes that were redistributed,but doesn’t affect liveness as shuffled nodes do not participatein the consensus in the epoch they have been redistributed.The pruning mechanism will decrease this time to a feasibleamount, as explained in section IX.2.

6 Consensus group selectionAfter each round a new set of validators are selected using

the random seed of the last commited block, current round andthe eligible nodes list. In case of network desynchronizationdue to the delays in message propagation, the protocol hasa recovery mechanism, and takes into consideration both theround r and the randomness seed from the last committedblock in order to select new consensus groups every round.This avoids forking and allows synchronization on last block.

The small time window (round time) in which the validatorsgroup is known, minimizes the attack vectors.

7 Node ratingBeside stake, the eligible validator’s rating influences the

chances to be selected as part of the consensus group. If theblock proposer is honest and its block gets committed to theblockchain, it will have its rating increased, otherwise, it’srating will be decreased. This way, each possible validatoris incentivized to be honest, run the most up-to-date clientsoftware version, increase its service availability and thusensuring the network functions as designed.

8 Shard redundancyThe nodes that were distributed in sibling shards on the

tree’s lowest level (see section IV.4) keep track of each other’sblockchain data and application state. By introducing theconcept of shard redundancy, when the number of nodes inthe network decreases, some of the sibling shards will needto be merged. The targeted nodes will instantly initiate theprocess of shard merging.

XI Understanding the real problems1 Centralized vs Decentralized

Blockchain was initially instantiated as an alternative tothe centralized financial system of systems [45]. Even if thefreedom and anonymity of distributed architectures remains anundisputed advantage, the performance has to be analyzed ata global scale in a real-world environment.

The most relevant metric measuring performance is transac-tions per second (TPS), as seen in Table 2. A TPS comparisonof traditional centralized systems with decentralized novelarchitectures that were validated as trusted and efficient ona large scale, reflects an objective yet unsettling reality [46],[47], [48], [49].

The scalability of blockchain architectures is a criticalbut still unsolved problem. Take, for instance, the exampledetermining the data storage and bootstrapping implications ofcurrent blockchain architectures suddenly functioning at Visalevel throughput. By performing such exercises, the magnitudeof multiple secondary problems becomes obvious (see Fig.11).

16

Archi-tecture

Type DispersionTPS

(average)TPS

(max limit)

VISADistributed

virtualizationCentralized 3500 55000

PaypalDistributed

virtualizationCentralized 200 450

RipplePrivate

BlockchainPermissioned 1500 55000

NEOPrivate

BlockchainMixed 1000 10000

EthereumPublic

BlockchainDecentralized 15 25

BitcoinPublic

BlockchainDecentralized 2 7

TABLE 2: Centralized vs Decentralized TPS comparison

XII The blockchain performance paradigmThe process of designing distributed architectures on

blockchain faces several challenges, perhaps one of the mostchallenging being the struggle to maintain operability undercontextual pressure conditions. The main components thatdetermine the performance pressure are:

• complexity• system size• transaction volume

ComplexityThe first element that limits the system performance, is the

consensus protocol. A more complicated protocol determinesa bigger hotspot. In PoW consensus architectures a big perfor-mance penalty is induced by the mining complexity that aimsto keep the system decentralized and ASIC resilient [50]. Tooverrun this problem PoS makes a trade-off, simplifies thenetwork management by concentrating the computing powerto a subset of the network, but yields more complexity on thecontrol mechanism.

System sizeExpanding the number of nodes in existing validated archi-

tectures forces a serious performance degradation and inducesa higher computational price that must be paid. Shardingseems to be a good approach, but the shard size plays amajor role. Smaller shards are agile but more likely to beaffected by malicious groups, bigger shards are safer, but theirreconfiguration affects the system liveness.

Transaction volumeWith a higher relevance compared to the others, the last item

on the list represents the transaction processing performance.In order to correctly measure the impact of this criteria, thismust be analyzed considering the following two standpoints:

• C1 transaction throughput - how many transactions asystem can process per time unit, known as TPS, anoutput of a system [51];

• C2 transaction finality - how fast one particular trans-action is processed, referring to the interval between itslaunch and its finalization - an input to output path.

C1. T ransaction throughput in single chain architectures isvery low and can be increased by using workarounds suchas sidechain [52]. In a sharded architecture like ours, thetransaction throughput is influenced by the number of shards,the computing capabilities of the validators/block proposersand the messaging infrastructure [8]. In general, as displayedin Fig. 13, this goes well to the public, but despite theimportance of the metric, it provides only a fragmented view.C2. T ransaction finality - A more delicate aspect that

emphasizes that even if the system may have a throughput of1000 TPS, it may take a while to process a particular transac-tion. Beside the computing capabilities of the validators/blockproposers and the messaging infrastructure, the transactionfinality is mainly affected by the dispatching algorithm (whenthe decision is made) and the routing protocol (where shouldthe transaction be executed). Most of the existing state of theart architectures refuse to mention this aspect but from a userstandpoint this is extremely important. This is displayed in

Fig. 11: Storage Estimation - Validated distributed architectures working at an average of VISA TPS

17

Fig. 13: Transaction throughput

Fig. 14, where the total time required to execute a certaintransaction from start to end is considered.

In Elrond, the dispatching mechanism (detailed in section V)allows an improved time to finality by routing the transactionsdirectly to the right shard, mitigating the overall delays.

XIII Conclusion

1 Performance

Performance tests and simulations, presented in Fig. 12,reflect the efficiency of the solution as a highly scalabledistributed ledger. As more and more nodes join the networkour sharding approach shows a linearly increasing throughput.The chosen consensus model involves multiple communicationrounds, thus the result is highly influenced by the networkquality (speed, latency, availability). Simulations using ourtestnet using worldwide network speed averages, at its max-imum theoretical limit, suggest Elrond exceeds the averageVISA level with just 2 shards, and approaches peak VISAlevel with 16 shards.

Fig. 14: Transaction finality

2 Ongoing and future research

Our team is constantly re-evaluating and improving Elrond’sdesign, in an effort to make this one of the most com-pelling public blockchain architectures; solving scalability viaadaptive state sharding, while maintaining security and highenergy efficiency through a secure Proof of Stake consensusmechanism. Some of our next directions of improvementinclude:

1) Reinforcement learning: we aim to increase the ef-ficiency of the sharding process by allocating the fre-quently trading clients in the same shard to reduce theoverall cost;

2) AI supervision: create an AI supervisor that detectsmalicious behavioral patterns; it is still uncertain howthis feature can be integrated in the protocol withoutdisrupting the decentralization;

3) Reliability as a consensus factor: the existing protocolweighs between stake and rating but we plan to addreliability, as a metric that should be computed in adistributed manner after applying a consensus protocolon previously submitted blocks from the very recent

Fig. 12: Network throughput measured in transactions per seconds with a global network speed of 8 MB/s

18

history;4) Cross-chain interoperability: implements and con-

tribute to standards like those initiated by the De-centralized Identity Foundation [53] or the BlockchainInteroperability Alliance [54];

5) Privacy preserving transactions: use Zero-KnowledgeSuccinct Non-Interactive Argument of Knowledge [55]to protect the identity of the participants and offerauditing capabilities while preserving the privacy.

3 Overall ConclusionsElrond is the first highly scalable public blockchain that

uses the newly proposed Secure Proof of Stake algorithmin a genuine state-sharded architecture to achieve VISAlevel throughput and confirmation times of seconds. Elrond’snovel approach on adaptive state sharding improves on Om-niledger’s proposal increasing security and throughput, whilethe built-in automatic transaction routing and state redundancymechanisms considerably reduce latencies. By using a shardpruning technique the bootstrapping and storage costs arealso considerably reduced compared to other approaches. Thenewly introduced Secure Proof of Stake consensus algorithmensures distributed fairness and improves on Algorand’s ideaof random selection, reducing the time needed for the randomselection of the consensus group from 12 seconds to 100ms. Our method of combining state sharding and the veryefficient Secure Proof of Stake consensus algorithm has shownpromising results in our initial estimations, validated by ourlatest testnet results.

References[1] G. Hileman and M. Rauchs, “2017 Global Cryptocurrency

Benchmarking Study,” Social Science Research Network, Rochester,NY, SSRN Scholarly Paper ID 2965436, Apr. 2017. [Online]. Available:https://papers.ssrn.com/abstract=2965436

[2] “The Ethereum Wiki - Sharding FAQ,” 2018, original-date: 2014-02-14T23:05:17Z. [Online]. Available: https://github.com/ethereum/wiki/wiki/Sharding-FAQ

[3] Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich, “Algorand:Scaling Byzantine Agreements for Cryptocurrencies,” in Proceedings ofthe 26th Symposium on Operating Systems Principles, ser. SOSP ’17.New York, NY, USA: ACM, 2017, pp. 51–68. [Online]. Available:http://doi.acm.org/10.1145/3132747.3132757

[4] D. Boneh, B. Lynn, and H. Shacham, “Short signatures from the weilpairing,” in Advances in Cryptology – ASIACRYPT ’01, LNCS. Springer,2001, pp. 514–532.

[5] D. Boneh, M. Drijvers, and G. Neven, “Compact multi-signatures forsmaller blockchains,” in Advances in Cryptology – ASIACRYPT 2018,ser. Lecture Notes in Computer Science, vol. 11273. Springer, 2018,pp. 435–464.

[6] V. Buterin, “Ethereum: A Next-Generation Smart Contract andDecentralized Application Platform,” 2013. [Online]. Available: https://www.ethereum.org/pdfs/EthereumWhitePaper.pdf

[7] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta,and B. Ford, “OmniLedger: A Secure, Scale-Out, DecentralizedLedger via Sharding,” Tech. Rep. 406, 2017. [Online]. Available:https://eprint.iacr.org/2017/406

[8] “The ZILLIQA Technical Whitepaper,” 2017. [Online]. Available:https://docs.zilliqa.com/whitepaper.pdf

[9] M. Al-Bassam, A. Sonnino, S. Bano, D. Hrycyszyn, and G. Danezis,“Chainspace: A Sharded Smart Contracts Platform,” arXiv:1708.03778[cs], Aug. 2017, arXiv: 1708.03778. [Online]. Available: http://arxiv.org/abs/1708.03778

[10] G. Wood, “Ethereum: A Secure Decentralised GeneralisedTransaction Ledger,” 2017. [Online]. Available: https://ethereum.github.io/yellowpaper/paper.pdf

[11] “Solidity — Solidity 0.4.21 documentation.” [Online]. Available:https://solidity.readthedocs.io/en/v0.4.21/

[12] “web3j,” 2018. [Online]. Available: https://github.com/web3j[13] “Casper,” 2018. [Online]. Available: http://ethresear.ch/c/casper[14] “The State of Ethereum Scaling, March 2018 – Highlights from

EthCC on Plasma Cash, Minimum Viable Plasma, and More. . . –Medium,” 2018. [Online]. Available: https://medium.com/loom-network/the-state-of-ethereum-scaling-march-2018-74ac08198a36

[15] M. Castro and B. Liskov, “Practical Byzantine Fault Tolerance,”in Proceedings of the Third Symposium on Operating SystemsDesign and Implementation, ser. OSDI ’99. Berkeley, CA, USA:USENIX Association, 1999, pp. 173–186. [Online]. Available:http://dl.acm.org/citation.cfm?id=296806.296824

[16] Y. Jia, “Op Ed: The Many Faces of Sharding for BlockchainScalability,” 2018. [Online]. Available: https://bitcoinmagazine.com/articles/op-ed-many-faces-sharding-blockchain-scalability/

[17] “Using Merklix tree to shard block validation | Deadalnix’sden,” 2016. [Online]. Available: https://www.deadalnix.me/2016/11/06/using-merklix-tree-to-shard-block-validation/

[18] S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” p. 9,2008.

[19] “Why we are building Cardano - Introduction.” [Online]. Available:https://whycardano.com/

[20] “Constellation - a blockchain microservice operating system - WhitePaper,” 2017, original-date: 2018-01-05T20:42:05Z. [Online]. Available:https://github.com/Constellation-Labs/Whitepaper

[21] “Bitshares - Delegated Proof-of-Stake Consensus,”2014. [Online]. Available: https://bitshares.org/technology/delegated-proof-of-stake-consensus/

[22] dantheman, “DPOS Consensus Algorithm - The Missing White Paper,”May 2017. [Online]. Available: https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper

[23] “EOS.IO Technical White Paper v2,” 2018, original-date: 2017-06-06T07:55:17Z. [Online]. Available: https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md

[24] C. Paar and J. Pelzl, Understanding Cryptography: A Textbook forStudents and Practitioners. Berlin Heidelberg: Springer-Verlag, 2010.[Online]. Available: //www.springer.com/gp/book/9783642041006

[25] C. Schnorr, “Efficient signature generation by smart cards,” Journal ofCryptology, vol. 4, pp. 161–174, Jan. 1991.

[26] K. Michaelis, C. Meyer, and J. Schwenk, “Randomly Failed!The State of Randomness in Current Java Implementations,” inTopics in Cryptology – CT-RSA 2013, ser. Lecture Notes inComputer Science. Springer, Berlin, Heidelberg, Feb. 2013, pp.129–144. [Online]. Available: https://link.springer.com/chapter/10.1007/978-3-642-36095-4 9

[27] D. J. Bernstein, P. Birkner, M. Joye, T. Lange, and C. Peters, “TwistedEdwards Curves,” in Progress in Cryptology – AFRICACRYPT2008, ser. Lecture Notes in Computer Science. Springer, Berlin,Heidelberg, Jun. 2008, pp. 389–405. [Online]. Available: https://link.springer.com/chapter/10.1007/978-3-540-68164-9 26

[28] A. Poelstra, “Schnorr Signatures are Non-Malleable in the RandomOracle Model,” 2014. [Online]. Available: https://download.wpsoftware.net/bitcoin/wizardry/schnorr-mall.pdf

[29] C. Decker and R. Wattenhofer, “Bitcoin Transaction Malleability andMtGox,” arXiv:1403.6676 [cs], vol. 8713, pp. 313–326, 2014, arXiv:1403.6676. [Online]. Available: http://arxiv.org/abs/1403.6676

[30] G. Maxwell, A. Poelstra, Y. Seurin, and P. Wuille, “Simple SchnorrMulti-Signatures with Applications to Bitcoin,” Tech. Rep. 068, 2018.[Online]. Available: https://eprint.iacr.org/2018/068

[31] Y. Seurin, “On the Exact Security of Schnorr-Type Signaturesin the Random Oracle Model,” in Advances in Cryptology –EUROCRYPT 2012, ser. Lecture Notes in Computer Science. Springer,Berlin, Heidelberg, Apr. 2012, pp. 554–571. [Online]. Available:https://link.springer.com/chapter/10.1007/978-3-642-29011-4 33

[32] K. Itakura and K. Nakamura, “A public-key cryptosystem suitable fordigital multisignatures,” 1983.

[33] S. Micali, K. Ohta, and L. Reyzin, “Accountable-subgroupMultisignatures: Extended Abstract,” in Proceedings of the 8thACM Conference on Computer and Communications Security, ser.CCS ’01. New York, NY, USA: ACM, 2001, pp. 245–254. [Online].Available: http://doi.acm.org/10.1145/501983.502017

[34] T. Ristenpart and S. Yilek, “The Power of Proofs-of-Possession:Securing Multiparty Signatures against Rogue-Key Attacks,” inAdvances in Cryptology - EUROCRYPT 2007, ser. Lecture Notesin Computer Science. Springer, Berlin, Heidelberg, May 2007, pp.

19

228–245. [Online]. Available: https://link.springer.com/chapter/10.1007/978-3-540-72540-4 13

[35] M. Bellare and G. Neven, “Multi-signatures in the Plain public-KeyModel and a General Forking Lemma,” in Proceedings of the 13thACM Conference on Computer and Communications Security, ser.CCS ’06. New York, NY, USA: ACM, 2006, pp. 390–399. [Online].Available: http://doi.acm.org/10.1145/1180405.1180453

[36] D.-P. Le, A. Bonnecaze, and A. Gabillon, “Multisignatures as Secureas the Diffie-Hellman Problem in the Plain Public-Key Model,” inPairing-Based Cryptography – Pairing 2009, ser. Lecture Notes inComputer Science. Springer, Berlin, Heidelberg, Aug. 2009, pp.35–51. [Online]. Available: https://link.springer.com/chapter/10.1007/978-3-642-03298-1 3

[37] T. Dickerson, P. Gazzillo, M. Herlihy, and E. Koskinen, “AddingConcurrency to Smart Contracts,” in Proceedings of the ACMSymposium on Principles of Distributed Computing, ser. PODC ’17.New York, NY, USA: ACM, 2017, pp. 303–312. [Online]. Available:http://doi.acm.org/10.1145/3087801.3087835

[38] J. Kwon and E. Buchman, “Cosmos Network - Internet of Blockchains,”2017. [Online]. Available: https://cosmos.network/whitepaper

[39] G. Ros, u and T. F. S, erbanuta, “An overview of the k semantic frame-work,” The Journal of Logic and Algebraic Programming, vol. 79, no. 6,pp. 397–434, 2010.

[40] T. Kasampalis, D. Guth, B. Moore, T. Serbanuta, V. Serbanuta, D. Fi-laretti, G. Rosu, and R. Johnson, “Iele: An intermediate-level blockchainlanguage designed and implemented using formal semantics,” Tech.Rep., 2018.

[41] E. Hildenbrandt, M. Saxena, X. Zhu, N. Rodrigues, P. Daian, D. Guth,and G. Rosu, “Kevm: A complete semantics of the ethereum virtualmachine,” Tech. Rep., 2017.

[42] “How Formal Verification of Smart Contracts Works |RV Blog.” [Online]. Available: https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/

[43] “Cross-shard contract yanking.” [Online]. Available: https://ethresear.ch/t/cross-shard-contract-yanking/1450

[44] R. C. Merkle, “A Certified Digital Signature,” in Advances in Cryptology— CRYPTO’ 89 Proceedings, ser. Lecture Notes in Computer Science.Springer, New York, NY, Aug. 1989, pp. 218–238. [Online]. Available:https://link.springer.com/chapter/10.1007/0-387-34805-0 21

[45] A. Veysov and M. Stolbov, “Financial System Classification: FromConventional Dichotomy to a More Modern View,” Social ScienceResearch Network, Rochester, NY, SSRN Scholarly Paper ID 2114842,Jul. 2012. [Online]. Available: https://papers.ssrn.com/abstract=2114842

[46] “XRP - The Digital Asset for Payments.” [Online]. Available:https://ripple.com/xrp/

[47] “Visa - Annual Report 2017,” 2018. [Online]. Avail-able: https://s1.q4cdn.com/050606653/files/doc financials/annual/2017/Visa-2017-Annual-Report.pdf

[48] “PayPal Reports Fourth Quarter and Full Year 2017 Results(NASDAQ:PYPL),” 2018. [Online]. Available: https://investor.paypal-corp.com/releasedetail.cfm?releaseid=1055924

[49] M. Schwarz, “Crypto Transaction Speeds 2018 - All the MajorCryptocurrencies,” 2018. [Online]. Available: https://www.abitgreedy.com/transaction-speed/

[50] “The Ethereum Wiki - Mining,” 2018, original-date: 2014-02-14T23:05:17Z. [Online]. Available: https://github.com/ethereum/wiki/wiki/Mininghttps://github.com/ethereum/wiki

[51] “Transaction throughput.” [Online]. Available: https://docs.oracle.com/cd/E17276 01/html/programmer reference/transapp throughput.html

[52] W. Martino, M. Quaintance, and S. Popejoy, “Chainweb: A Proof-of-Work Parallel-Chain Architecture for Massive Throughput,” 2018.[Online]. Available: http://kadena.io/docs/chainweb-v15.pd

[53] “DIF - Decentralized Identity Foundation.” [Online]. Available:http://identity.foundation/

[54] H. I. World, “Blockchain Interoperability Alliance:ICON x Aion x Wanchain,” Dec. 2017.[Online]. Available: https://medium.com/helloiconworld/blockchain-interoperability-alliance-icon-x-aion-x-wanchain-8aeaafb3ebdd

[55] S. Goldwasser, S. Micali, and C. Rackoff, “The Knowledge Complexityof Interactive Proof-systems,” in Proceedings of the Seventeenth AnnualACM Symposium on Theory of Computing, ser. STOC ’85. NewYork, NY, USA: ACM, 1985, pp. 291–304. [Online]. Available:http://doi.acm.org/10.1145/22145.22178