|
| 1 | + |
| 2 | + |
| 3 | +* Reuse `relayNode` but use Leios-specific blocks. |
| 4 | +* Also need Praos layer for Ranking blocks, could be high-level/abstract. |
| 5 | + - Could start with Shelley's ChainSync with whole-blocks: overestimates ranking blocks traffic. |
| 6 | +* Actually implement Leios protocol, rather than just send blocks. |
| 7 | + - Non-block-producing nodes might skip some parts like downloading votes. |
| 8 | + - Some nodes produce transactions, with some distribution governing the timeslots. |
| 9 | + * Later: Simulation scenario might determine transactions submitted over time. |
| 10 | + - Needed structures for the node: |
| 11 | + - Mempool of valid transactions (to include in IBs). |
| 12 | + - Challenge: minimize inclusion of same/conflicting tx in separate IBs. |
| 13 | + - Set for certifiable EBs to include in RBs. |
| 14 | + * Actually we have to accumulate votes for EBs in general: only from specific slot ranges though. |
| 15 | + - Ledger state |
| 16 | + - Base chain (See Shelley's ChainDB ?) |
| 17 | + - Two sets of IBs |
| 18 | + * Validated, to relay. |
| 19 | + * Waiting to be validated, because ledger state is lagging. |
| 20 | + - IBs carry reference to RB whose ledger state is needed to validate (Discuss with research). |
| 21 | + - Blocks/Votes should be indexable by slot range, as pipelines are based on slices. |
| 22 | + * Old enough ones should be pruned: unless they are referenced (or could be?) by a RB though. |
| 23 | + - Can we throw away old non-RB-referenced but Vote2-certified EBs? Asked research in discussion. |
| 24 | + - Need to trigger tasks on new slot: |
| 25 | + * Different VRF lotteries for each of: IB, Link EB, Endorse EB, Vote1, Vote2, RB. |
| 26 | + * A slot lasts 1 second. |
0 commit comments