You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/developers/sc-calls-format.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -76,7 +76,7 @@ There are multiple ways of formatting the data field:
76
76
77
77
- manually convert each argument, and then join the function name, alongside the argument via the `@` character.
78
78
- use a pre-defined arguments serializer, such as [the one found in sdk-js](https://github.com/multiversx/mx-sdk-js-core/blob/main/src/smartcontracts/argSerializer.ts).
79
-
- use sdk-js's [contract calls](/sdk-and-tools/sdk-js/sdk-js-cookbook-v14/#smart-contracts).
79
+
- use sdk-js's [contract calls](/sdk-and-tools/sdk-js/sdk-js-cookbook/#smart-contracts).
80
80
- use sdk-cpp's [contract calls](https://github.com/multiversx/mx-sdk-cpp/blob/main/src/smartcontracts/contract_call.cpp).
Copy file name to clipboardExpand all lines: docs/learn/consensus.md
+106-8Lines changed: 106 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,18 +3,116 @@ id: consensus
3
3
title: Consensus
4
4
---
5
5
6
-
MultiversX'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.
6
+
# Consensus (Secure Proof‑of‑Stake – SPoS)
7
7
8
-
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.
8
+
## 1. How Consensus Works in MultiversX (post-Andromeda)
9
9
10
-
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.
10
+
Consensus is the protocol that keeps every shard and the Metachain in lock‑step, ensuring all honest participants share **one canonical history**. MultiversX uses a bespoke scheme called **Secure Proof‑of‑Stake (SPoS)**, a blend of stake‑weighted validator selection, VRF‑style randomness, and a high‑speed BLS multisignature algorithm that guarantees _single‑block finality_.
11
11
12
-
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.
12
+
Below is a step‑by‑step walk‑through of *one* six‑second block cycle (round `r`). The same engine runs independently in **every execution shard** and in the **Metachain**.
13
13
14
-
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.
14
+
### 1.1 Validator set and epochs
15
15
16
-
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.
16
+
***Validators.** Nodes that stake a minimum of 2500EGLD and run the MultiversX node client software. Each validator holds a long‑lived BLS key that is rotated only when they unbond/unstake, anyway the keys are shuffled among shards each epoch.
17
+
***Epoch.** A period of 24 hours (≈ 14 400 blocks on a 6 s cadence-round). At the start of every epoch the 400 validators in each shard are reshuffled using a deterministic permutation seeded with verifiable randomness. The composition of a shard remains fixed for the whole epoch.
17
18
18
-
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:
Because the identity of the previous proposer is only revealed at the end of round `r – 1`, no one can bias or predict `rand_r` ahead of time.
28
+
29
+
### 1.3 Proposer election
30
+
31
+
Each validator hashes together its public key and `rand_r`:
32
+
33
+
```
34
+
score_i = Hash(PK_i ‖ rand_r)
35
+
```
36
+
37
+
The lowest score wins and becomes the **proposer** for round `r`. Ties are astronomically unlikely.
38
+
39
+
### 1.4 Two‑phase BLS consensus
40
+
41
+
Once chosen, the proposer assembles a block and broadcasts it to the other 399 validators. Consensus then runs in **two BLS rounds**—`prepare` and `commit`—similar to PBFT but with aggregated signatures:
42
+
43
+
1.**Prepare.** Validators check the block (state root, signatures, gas limits). If valid they sign its hash and return a 96‑byte BLS share.
44
+
2.**Commit.** The proposer (or any validator) aggregates ≥ ⅔ of the shares into a single 96‑byte signature and broadcasts a **commit message**.
45
+
46
+
Because **all 400 validators** participate (post‑Andromeda), a share threshold of 268 guarantees Byzantine safety.
47
+
48
+
### 1.5 Equivalent Consensus Proof (ECP)
49
+
50
+
The final artefact attached to the block header is an **ECP**:
51
+
52
+
```
53
+
ECP = (agg_signature, bitmap_400)
54
+
```
55
+
56
+
*`agg_signature` – aggregated BLS signature from ≥ 268 validators.
57
+
*`bitmap_400` – 400‑bit field indicating which keys took part.
58
+
59
+
Any validator can perform the aggregation; there is no single point of failure. Because the validator set and aggregation order are deterministic inside the epoch, *exactly one* valid ECP can exist for a given block—making equivocation impossible.
60
+
61
+
### 1.6 Notarisation and finality
62
+
63
+
***Execution shards**: A block is **final the moment its ECP is broadcast**. No confirmation block is needed.
64
+
***Metachain**: Collects hashes of all shard blocks plus their ECPs, notarises them in the metablock of the next round, and itself reaches finality via the same BLS protocol.
65
+
66
+
**Latency:**~6 s for intra‑shard txs, ~18 s for cross‑shard (three‑block path).
67
+
68
+
## 2. Consensus group size: 63 → 400
69
+
70
+
| Era | Execution‑shard consensus group | Metachain |
|**Andromeda**|**All 400 validators** every round (fixed for the whole epoch) |**Unchanged** (400) |
74
+
75
+
Using the full validator set removes the need for a confirmation block; a single consensus proves majority acceptance.
76
+
77
+
## 3. Consensus flow (post‑Andromeda)
78
+
79
+
```mermaid
80
+
sequenceDiagram
81
+
participant P as Proposer
82
+
participant V as Validators (399)
83
+
participant M as Metachain
84
+
85
+
%% Round r
86
+
P->>V: ① Block proposal (header + txs)
87
+
V->>P: ② Prepare signatures (first BLS round)
88
+
P->>V: ③ Commit message (aggregated sig ≥ ⅔)
89
+
V->>M: ④ Broadcast final block + ECP
90
+
M--)P: ⑤ Block notarised (instant finality)
91
+
```
92
+
93
+
**Equivalent Consensus Proof (ECP)**
94
+
Any validator can aggregate ≥ ⅔ BLS shares into an ECP. Because aggregation order is fixed and the validator set is constant across the epoch, the proof is uniquely determined – _equivocation is impossible_.
95
+
96
+
## 4. Confirmation blocks removed
97
+
98
+
*Pre‑Andromeda*: each execution shard produced a **block** and, one round later, a **confirmation block** to seal it. The Metachain applied the same pattern to eliminate double‑spend risk.
99
+
*Andromeda*: one block is enough; once its ECP is broadcast the block is final, so no confirmation blocks are produced. This halves average time‑to‑finality.
100
+
101
+
## 5. Validator rating & selection
102
+
103
+
***Rating** still measures historical performance and influences shard assignment probability at the **epoch shuffle** step.
104
+
* Because every validator now participates in every round, rating no longer affects _per‑round_ selection but continues to impact rewards via uptime and signature participation.
105
+
106
+
## 6. Security considerations
107
+
108
+
***Byzantine tolerance**: With 400 signatures per block the network tolerates up to 133 malicious validators per shard (≈ ⅓).
109
+
***Rogue‑key protection**: Implemented via KOSK and deterministic aggregation order – enabling fast verification of 400‑party BLS signatures.
110
+
***Proposer failure**: Because ECP finalisation is permissionless, the network is no longer sensitive to a single proposer going offline.
111
+
112
+
## TL;DR
113
+
114
+
***400/400 validators** now sign every shard block.
0 commit comments