Эх сурвалжийг харах

doc/architecture/tx_lifetime: added real-world simulation with multiple nodes

aggstam 3 жил өмнө
parent
commit
a1c418dc60

+ 42 - 13
doc/src/architecture/tx_lifetime.md

@@ -35,12 +35,36 @@ chain:
 14. `CS` writes the state updates to their chain
 15. `CS` removes $tx$ from their `mempool`
 
-## Real-world simulation with non-instant finality and forks
+## Real-world simulation with non-instant finality
 
 The lifetime of a transaction $tx$ that passes verification and whose
 state transition is pending to be applied on top of the finalized (canonical)
 chain:
 
+1. User creates a transaction $tx$
+2. User broadcasts $tx$ to `CS`
+3. `CS` validates $tx$ state transition
+4. $tx$ enters `CS` `mempool`
+5. `CS` broadcasts $tx$ to `CP`
+6. `CP` validates $tx$ state transition
+7. $tx$ enters `CP` `mempool`
+8. `CP` proposes a block proposal containing $tx$
+9. `CP` proposes more block proposals
+10. When proposals can be finalized, `CP` validates all their transactions
+in sequence
+11. `CP` writes the state transition update of $tx$ to their chain
+12. `CP` removes $tx$ from their `mempool`
+13. `CP` broadcasts the finalizated proposals sequence
+14. `CS` receives the proposals sequence and validates transactions
+15. `CS` writes the state updates to their chain
+16. `CS` removes $tx$ from their `mempool`
+
+## Real-world simulation with non-instant finality, forks and multiple `CP` nodes
+
+The lifetime of a transaction $tx$ that passes verifications and whose
+state transition is pending to be applied on top of the finalized (canonical)
+chain:
+
 1. User creates a transaction $tx$
 2. User broadcasts $tx$ to `CS`
 3. `CS` validates $tx$ state transition against canonical chain state
@@ -48,22 +72,27 @@ chain:
 5. `CS` broadcasts $tx$ to `CP`
 6. `CP` validates $tx$ state transition against all known fork states
 7. $tx$ enters `CP` `mempool`
-8. `CP` finds which fork to extend
-9. `CP` validates all unproposed transactions in its `mempool` in sequence,
+8. `CP` broadcasts $tx$ to rest `CP` nodes
+9. Slot producer `CP` (`SCP`) node finds which fork to extend
+10. `SCP` validates all unproposed transactions in its `mempool` in sequence,
 against extended fork state, discarding invalid
-10. `CP` proposes a block proposal containing $tx$ extending the fork
-11. When/if fork can be finalized, `CP` validates all its proposals
+11. `SCP` creates a block proposal containing $tx$ extending the fork
+12. `CP` receives block proposal and validates its transactions against
+the extended fork state
+13. `SCP` proposes more block proposals extending a fork state
+14. When a fork can be finalized, `CP` validates all its proposals
 transactions in sequence, against canonical state
-12. `CP` writes the state transition update of $tx$ to their chain
-13. `CP` removes $tx$ from their `mempool`
-14. `CP` broadcasts the finalizated proposals sequence
-15. `CS` receives the proposals sequence and validates transactions
-16. `CS` writes the state updates to their chain
-17. `CS` removes $tx$ from their `mempool`
+15. `CP` writes the state transition update of $tx$ to their chain
+16. `CP` removes $tx$ from their `mempool`
+17. `CP` drop rest forks and keeps only the finalized one
+18. `CP` broadcasts the finalizated proposals sequence
+19. `CS` receives the proposals sequence and validates transactions
+20. `CS` writes the state updates to their chain
+21. `CS` removes $tx$ from their `mempool`
 
 `CP` will keep $tx$ in its `mempool` as long as it is a valid state transition
-for any fork(including canonical) until it get finalized.
+for any fork(including canonical) or it get finalized.
 
 Unproposed transactions refers to all $tx$ not included in a proposal of any fork.
 
-If a fork that can be finalized fails to validate all its transactions(11), it should be dropped.
+If a fork that can be finalized fails to validate all its transactions(14), it should be dropped.