Update consensus-spec.md

skalenetwork · May 2, 2024 · 8d0b5f7 · 8d0b5f7
1 parent 846aa09
commit 8d0b5f7
Showing 1 changed file with 10 additions and 10 deletions.
diff --git 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: