From 8d0b5f723171acc6d1454149faf839e3ec65b588 Mon Sep 17 00:00:00 2001 From: Stan Kladko <13399135+kladkogex@users.noreply.github.com> Date: Thu, 2 May 2024 20:21:38 +0100 Subject: [PATCH] Update consensus-spec.md --- docs/consensus-spec.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/consensus-spec.md b/docs/consensus-spec.md index fc318f50..d27e49e2 100644 --- a/docs/consensus-spec.md +++ b/docs/consensus-spec.md @@ -18,17 +18,17 @@ The purpose of SKALE chain is to order `transactions` into `blocks` and then pro SKALE chain is composed of `N` network `nodes` that process user `transactions` according to the following phases -. accept and validate user `transactions` (_submission phase_) -. broadcast `transactions` to peer nodes (_broadcast phase_) -. store `transactions` into `pending queues` (_pending queue phase_) -. create `block proposal` for each `block number` and broadcast it to peers, collecting `2/3 N` `data availability signatures` and creating `DA proofs`. (_block proposal phase_) -. broadcast `DA proofs` to peers (_DA broadcast phase_) -. run `block consensus` for each `block proposal` to select a `winning proposal` (_block consensus phase_) -. sign the statement on which proposal won (`block signature share`) and broadcast it to other nodes. Wait until receipt of 2/3 of `block signature shares` and merge them +* accept and validate user `transactions` (_submission phase_) +* broadcast `transactions` to peer nodes (_broadcast phase_) +* store `transactions` into `pending queues` (_pending queue phase_) +* create `block proposal` for each `block number` and broadcast it to peers, collecting `2/3 N` `data availability signatures` and creating `DA proofs`. (_block proposal phase_) +* broadcast `DA proofs` to peers (_DA broadcast phase_) +* run `block consensus` for each `block proposal` to select a `winning proposal` (_block consensus phase_) +* sign the statement on which proposal won (`block signature share`) and broadcast it to other nodes. Wait until receipt of 2/3 of `block signature shares` and merge them into `block signature`. (_block signature phase_) -. commit the `winning proposal` if `node` has it, otherwise download it from other nodes and commit it. The `winning proposal` becomes a`committed block` (_block finalization phase_) -. process the `committed block` through `Ethereum Virtual Machine` to transition to the new `EVM state`. (_EVM processing phase_) -. store `committed blocks` and `EVM state`(_storage phase_) +* commit the `winning proposal` if `node` has it, otherwise download it from other nodes and commit it. The `winning proposal` becomes a`committed block` (_block finalization phase_) +* process the `committed block` through `Ethereum Virtual Machine` to transition to the new `EVM state`. (_EVM processing phase_) +* store `committed blocks` and `EVM state`(_storage phase_) The diagram below illustrates typical transaction flow: