Docs

Docs

  • Develop
  • Validate
  • Integrate
  • Learn

›Technology

Welcome to Elrond

  • Welcome to Elrond

Technology

  • Architecture Overview
  • Glossary
  • Entities
  • Chronology
  • Secure Proof of Stake
  • Adaptive State Sharding
  • The Elrond WASM VM
  • Cross Shard Transactions

Wallet

  • Wallets - Overview
  • Web Wallet
  • Maiar Web Wallet Extension
  • Webhooks
  • Ledger

Tokens

  • Native Tokens
  • ESDT tokens
  • NFT tokens

Validators

  • Validators - Overview
  • System Requirements
  • Install a Mainnet Node

    • Scripts & User config
    • Installing a Validator Node
    • Optional Configurations
    • How to use the Docker Image

    Install a Testnet/Devnet Node

    • Scripts & User config
    • Installing a Validator Node
    • Manage a validator node
    • How to use the Docker Image

    Manage your keys

    • Validator Keys
    • Wallet Keys
    • Protecting your keys

    Staking, Unstaking, Unjailing

    • Staking, unstaking and unjailing
    • Staking
    • Unjailing
    • The Staking Smart Contract
  • The Delegation Manager
  • Convert An Existing Validator Into A Staking Pool
  • Merging A Validator Into An Existing Delegation Smart Contract
  • Rating
  • Elrond Node upgrades
  • Node redundancy
  • Import DB
  • Node CLI
  • Node Databases
  • Useful Links & Tools
  • FAQs

Developers

  • Developers - Overview
  • Tutorials

    • Build a dApp in 15 minutes
    • Build a Microservice for your dApp
    • The Crowdfunding Smart Contract (part 1)
    • The Crowdfunding Smart Contract (part 2)
    • The Counter Smart Contract
    • Custom Wallet Connect

    Signing Transactions

    • Signing Transactions
    • Tools for signing
    • Signing programmatically

    Gas and Fees

    • Overview
    • EGLD transfers (move balance transactions)
    • System Smart Contracts
    • User-defined Smart Contracts

    Developer reference

    • The Elrond Serialization Format
    • Smart contract annotations
    • Smart contract modules
    • Smart contract to smart contract calls
    • Smart Contract Developer Best Practices
    • Code Metadata
    • Smart Contract API Functions
    • Storage Mappers
    • Rust Testing Framework
    • Rust Testing Framework Functions Reference
    • Rust Smart Contract Debugging
    • Random Numbers in Smart Contracts

    Developers Best Practices

    • Basics
    • BigUint Operations
    • The dynamic allocation problem
    • Multi-values

    Mandos tests reference

    • Mandos Overview
    • Mandos Structure
    • Mandos Simple Values
    • Mandos Complex Values
    • Embedding Mandos code in Go
  • Constants
  • Built-In Functions
  • Account storage
  • Setup a Local Testnet
  • Set up a Local Testnet (advanced)
  • Creating Wallets

SDK and Tools

  • SDKs and Tools - Overview
  • REST API

    • REST API overview
    • api.elrond.com
    • Gateway overview
    • Addresses
    • Transactions
    • Network
    • Nodes
    • Blocks
    • Virtual Machine
    • Versions and Changelog
  • Proxy
  • Elasticsearch
  • erdpy

    • erdpy
    • Installing erdpy
    • Configuring erdpy
    • erdpy CLI
    • Deriving the Wallet PEM file
    • Sending bulk transactions
    • Writing and running erdpy scripts
    • Smart contract interactions

    erdjs

    • erdjs
    • Cookbook
    • Extending erdjs
    • Writing and testing interactions
    • Migration guides
    • Signing Providers for dApps
  • erdgo
  • erdcpp
  • erdjava
  • erdkotlin
  • erdwalletjs-cli

Integrators

  • Integrators - Overview
  • EGLD integration guide
  • ESDT tokens integration guide
  • Observing Squad
  • Accounts Management
  • Creating Transactions
  • Querying the Blockchain

Secure Proof of Stake

Elrond's approach for consensus is called Secure Proof of Stake (SPoS). It innovates in the manner in which validator nodes are selected for consensus out of a shard and also in the steps taken by the validators to complete the consensus process as efficiently as possible. Let's take a look.

At the beginning of each round, SPoS selects validators for consensus using a randomness source that can be neither predicted, nor influenced. It is surprisingly simple, requiring only to be calculated from the previous block and to be signed by the consensus leader of the current round (also known as the block proposer). The resulting signature will be the randomness source for the next round, and due to its reliance on the immediately preceding block, it cannot be known more than a round in advance.

In each round, a new consensus group is selected to propose a block. But only one validator in the group will be the block proposer. This is the validator in the consensus group which has the hash of the public key and randomness source is the smallest, numerically. The block proposer will produce the block for the round, and the rest of the consensus group will validate and sign it.

The time necessary for random selection of the consensus group is exceptionally short (around 100 ms, often less). This efficiency is a consequence of the fact that consensus selection is deterministic once the randomness source is known, thus there is no communication requirement. This allows total round times on the order of mere seconds.

There is a security advantage to having rounds this short: SPoS is built on the premise that a malevolent actor cannot adapt faster than the timeframe allowed by a round in order to influence the block that will be proposed.

Like other Proof of Stake methods, SPoS selects validator nodes for consensus based on the amount of EGLD tokens staked by their operators. Additionally, each validator has an individual rating score that is taken into account - stake alone may only influence, but not completely determine the selection for consensus. Rating expresses the past behavior of the specific validator and is taken into account during consensus selection: validators with a higher rating are more likely to be selected. The rating of a validator is recalculated at the end of each epoch, with a few specific exceptions when rating is adjusted immediately. This way, SPoS promotes meritocracy among validators, encouraging their operators to keep them running smoothly.

A modified BLS multisignature scheme with 2 communication rounds is used by the consensus group for signing the block produced by the block proposer. Refer to the animation below for a step-by-step description of this process:

img

← ChronologyAdaptive State Sharding →
Made withby the Elrond team.
GithubChat
Main siteWalletExplorerBridgeDocsGrowthMaiarMaiar Exchange