update docs with andromeda #1107
Conversation
| Each validator hashes together its public key and `rand_r`: | ||
|
|
||
| ``` | ||
| score_i = Hash(PK_i ‖ rand_r) |
There was a problem hiding this comment.
Concatenation, correct?
|
|
||
| ### 1.4 Two‑phase BLS consensus | ||
|
|
||
| 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: |
There was a problem hiding this comment.
Non-standard hyphen.
There was a problem hiding this comment.
And below, in other places.
| 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: | ||
|
|
||
| 1. **Prepare.** Validators check the block (state root, signatures, gas limits). If valid they sign its hash and return a 96‑byte BLS share. | ||
| 2. **Commit.** The proposer (or any validator) aggregates ≥ ⅔ of the shares into a single 96‑byte signature and broadcasts a **commit message**. |
There was a problem hiding this comment.
aggregates ≥ ⅔ - maybe use words i.e. two thirds (just an opinion, feel free to skip it)?
| Randomness must be unpredictable yet verifiable. For round `r` the seed is: | ||
|
|
||
| ``` | ||
| rand_r = BLS_sign(prev_block_hash, proposer_{r-1}) |
There was a problem hiding this comment.
Should be double-checked. Leader signs?
|
|
||
| ## 4. Confirmation blocks removed | ||
|
|
||
| *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. |
There was a problem hiding this comment.
The Metachain applied the same pattern to eliminate double‑spend risk.
Could be redundant information (there is no double spending, and for other reasons?). Also, "applies" (present simple).
| 2. **Notarisation by the Metachain.** | ||
| The Metachain includes the header & miniblock hashes of the new `shard 0` block in metablock `n + 1`, together with an **Equivalent Consensus Proof (ECP)** – a compressed BLS aggregate signature from ≥ 2⁄3 of the validator set. | ||
| 3. **Execution in the receiver’s shard.** | ||
| Nodes in `shard 1` read the metablock, fetch miniblock 1 from `shard 0`, verify the ECP, check for replay, and apply the state changes (credit the destination address). The resulting `shard 1` block (nonce `n + 2`) is finalised with its own consensus proof and notarised in the next metablock. |
There was a problem hiding this comment.
n, n+1, n+2 are somehow imprecise expressions, since the shards have unrelated sequences of nonces (in sync with respect to round).
|
|
||
| ### Why did cross‑shard execution need six rounds before Andromeda? | ||
|
|
||
| Before v1.9.6 a cross‑shard transfer had to survive **at least six separate blocks** to guarantee it could never be reverted elsewhere: |
There was a problem hiding this comment.
Maybe use Andromeda instead (or, maybe v1.9.x).
Description of the pull request (what is new / what has changed)
Did you test the changes locally ?
Which category (categories) does this pull request belong to?