It started with a goal. A solid team with clear vision and ambition, wanting a solution to Blockchains well-known throughput problem. The months that followed saw us doing a lot of research, all the while testing constantly for possible improvements. This process was strenuous, but we have now reached a point where we are able to plainly see the value in all our efforts.

With this post, we are inviting you all to share another important milestone with us.

Introducing the Elrond prototype

Prototype

A blockchain prototype usually shows an initial proof of concept in a bulky terminal debug window, scrolling thousands of lines only to prove a miniscule technical point.


Yet, in a relatively short time frame, we’ve managed to build an advanced prototype that looks and behaves like an end product, giving us the ground on which to build with more complexity. We wanted to complete this process before the ICO in order to prove to you, our community, our team’s capabilities and long term commitment.


After several months of intensive coding, many late nights planning, and countless whiteboard-written diagrams, our team finally managed to pack a one-click, cross-platform app, marking the Elrond prototype v.0.1. This version integrates a fully running node, a wallet, and a section for stats and benchmarks.

Coding

The code was crafted in JAVA for the blockchain core, while on the user side we’ve used Node JS. The planning was made using Jira Tools. Our Github solution has 11 contributors on 2 main private repositories (core and ui), 44 branches and 653 commits. The repositories will remain private for now, but when the right time arrives they will be made public. The screenshots below speak for themselves.

The New App Experience

With a new, well-functioning user interface, Elrond V.0.1 bundles the following app sections:

1. Node

Features an intuitive configuration section, pre-populated with default values for a smooth progress. It has four guided steps:

• Intro screen — basic information and guidelines
• Instance setup — establishes the connection parameters between the current node and the network of peers with the ability to test every scenario before starting the node
• Keys — covers the key generation process for private and public keys and the initial shard allocation. A new set of keys can be generated, or the user can use an existing valid private key (previously saved)
• Summary — presents an overview over all the configuration parameters and starts the node
  
  
  
  
  

2. Wallet

This section represents a wallet with the following features:

• Displays the balance and the allocated shard for the account address
• Allows the user to perform intra-shard and cross-shard transactions between addresses
• Acts as a blockchain explorer, verifying balances for any account on the blockchain
• Displays a history of the recent transactions performed by the current address
  
  
  
  
  

3. Stats

Because tech people like to see under-the-hood details, the statistical sections offers a good perspective:

• Live and history values for the entire network and individual details for each active shard, showing information like: active number of nodes, peek and live transactions/second, average transactions per block, total number of transactions, round time
• Experimental benchmark feature that allows the early users of the prototype to test the capabilities of the network while triggering thousands of transactions
• Interactive throughput chart with live data and recent history on the network load, displayed for each active shard at a global level
  
  
  
  
  

Technical Components

From a more technical perspective, the entire solution was built having a plug-and-play architecture in mind. The solution contains multiple modules, each one following the single-responsibility principle, being isolated from the rest of the system using interfaces that ensure decoupling and flexibility. The main modules are outlined as follows:

a) Communication layer

Represents the P2P network that provides the infrastructure needed for the following operations: direct messaging, information broadcast and channel communication.
The P2P module ensures the following core services:

• P2PConnectionService ensures the node connectivity and discovery
• P2PObjectService provides primitives that split the operations to send and retrieve objects over networks
• P2PBroadcastService contains broadcast channels used to send blocks, transactions, and receipts intra- or inter-shard
• P2PRequestService implements a mechanism to request missing information
  
  
  
  
  

b) Cryptographic layer

Deals with signing and verification for transactions with Schnorr scheme and Bellare and Neven’s multi-signature method for blocks.
The cryptographic layer provides these services:

• ECCryptoService gives information about the chosen curve for EC cryptography
• SignatureService provides the primitives to sign a message and verify the signature
• MultiSignatureService provides primitives to perform multi-signing and verify a multi-signature.
  
  
  
  
  

c) Blockchain Core

Is the backbone data model used to store blocks, transactions, accounts and any additional information needed for the distributed ledger.
The blockchain module exposes the following sub components:

• BlockchainService implements all the operations required to handle block manipulation
• AppPersistenceService allows temporary and persistent storage of blocks
• TransactionsPool has as its main purpose to buffer new transactions until they are ready to be assembled inside a block
• Blockchain abstracts the blockchain structure and decouples the data model from the access medium
  
  
  
  
  

d) Execution Engine

Represents the most essential part of the architecture. This processes transactions and assembles blocks while replicating the state across the network to ensure consistency and security.
The execution engine is encapsulated in two services:

• ExecutionService executes blocks and transactions and updates the application state
• BootstrapService ensures that a node is synchronized with the rest of the network
  
  
  
  
  

e) Chronology

For a synchronization and time-passing perspective, we are using an NTP (Network Time Protocol) service, currently synchronized with public servers worldwide. The time is fragmented into rounds and sub-rounds, ensuring a well structured bootstrapping process and proper timeouts.





The chronology module houses ChronologyService. This service provides primitives for world clock synchronization and different round time computations.

f) Consensus Protocol

Currently, working as a delegated proof of stake variant in a round-robin scenario, allowing everyone to take turns in either proposing or validating blocks. The consensus protocol runs independently on each shard.
The consensus module provides the following services:

• ConsensusService: provides methods for consensus computation within the list of validators
• SPoSService: provides the means necessary to compute the list of validators and block proposer for the current round
• ValidatorService: provides methods to compute fitness (stake and rating) for the nodes in the eligible nodes list
  
  
  
  
  

g) Sharding Mechanism

Using an initial state sharding version that allows intra-shard and cross-shard transactions using communication channels. According to the formulas mentioned in the white-paper, initially, each shard gets a subset from the wallet address space.
The sharding communication part is integrated into the P2P module.
Additionally, it provides the following:

• ShardingService implements useful primitives required to manipulate the information between shards
• ShardOperation is a structure that dictates how the transactions are routed in/out shard
  
  
  
  
  

Performance

The prototype was measured in two different environments: on a local network and through Amazon Web Services. The results show that on a peer-to-peer network with just 24 active nodes distributed to two shards, the protocol exceeded the peak value of 300 transactions/second. Since we aim to make Elrond available for everyone, all the configurations for the test machines were of average values: 2–4 GB of RAM and consumer multi-core processor on maximum 2.8 Ghz.


For the pre-ICO stage, the prototype performed as expected, and we will continue with the next development step — the testnet.

Future milestones

Our current focus is on scaling the network to a significantly larger number of shards and nodes, showcasing how throughput will evolve as the network grows.


Once the network infrastructure is set up and we have precise data showing how the protocol behaves, we will enter a comprehensive planning stage. Here we will plot all the activities, sprints and deliverables of the testnet, in order to make sure that we have the optimal path towards achieving our roadmap.


Additionally, we are preparing a split from our core repo on GitHub, making the architectural interfaces public. This is in order to facilitate a more open discussion around the platform’s technical aspects.


We are open to community suggestions and we are looking forward to relevant contributions and feedback.


Once again, thank you for your support.
Best wishes,

Elrond Network Team