Elaborate the EB diffusion section of leios-design/README.md - #1005
Elaborate the EB diffusion section of leios-design/README.md#1005nfrisby wants to merge 7 commits into
Conversation
|
Sebastian already gave me some review on some of this, but it wasn't on a PR... I'll track that down and copy it over. |
|
|
||
| TODO refine to FreshestLast among the most recent L slots and FreshestFirst among older slots in order to also address RSK-LeiosProtocolStorm | ||
|
|
||
| #### Tolerating equivocation even despite $L_\text{hdr}$ violations |
There was a problem hiding this comment.
Reading from this point and stopping before "### Endorser block storage" might provide good context for reviewers of IntersectMBO/ouroboros-consensus#2132.
But recall: that PR only introduces diffusion of EB announcements---it doesn't already gate LeiosFetch or LeiosVoting on them.
|
PR is draft at least because some of the commits need better messages |
| @@ -548,37 +548,259 @@ The first version of the Mempool can be naive, with the block production thread | |||
|
|
|||
| ### Endorser block diffusion | |||
There was a problem hiding this comment.
I found Sebastian's original review:
A few first notes:
- I like the sections and their lengths mostly.
- The crucial attack vector / T22 description feels quite redundant with the key threats (relevant for the design) section https://github.com/input-output-hk/ouroboros-leios/blob/leios-design-updates/docs/leios-design/README.md#data-withholding -> maybe shorten and only call out any specifics?.
- One could think that the problem statement is full global diffusion of 12MB within 7+5 seconds; could be a narrative angle, but it's very much not an isolated problem statement. It's really under precondition that significant stake already has the data and could hold + validate it within 3+4 seconds.
- In short, the situation is not as dire, but your later paragraphs reflect that too.
- I don't like the bulleted paragraphs in https://github.com/input-output-hk/ouroboros-leios/blob/leios-design-updates/docs/leios-design/README.md#redundant-downloads.
- Ironic, I know 😄 .
- Can you make it shorter and keep bullets, or just make it normal paragraphs?.
- https://github.com/input-output-hk/ouroboros-leios/blob/leios-design-updates/docs/leios-design/README.md#tolerating-equivocation-even-despite-l_texthdr-violations lacks context about announcements and how they are to be relayed..
- The first half of it roughly could be in a preceding section (before EB diffusion) in which only that aspect is discussed..
- The second half of it (recovery path; what the fetching logic needs to do to deal with violations of L_hdr) makes sense in this chapter..
| As a result, opcert revocation for EB announcements is delayed until the incremented OCIN becomes immutable, after ~12 hr when Chain Growth is healthy and up to ~36 hr when it isn't. | ||
| That's tolerable: it just means a leaked key allows the attacker to equivocate (hence mostly nullify) the victim's EB announcements until their revocation becomes immutable. | ||
| Crucially, ChainSync doesn't change its behavior: it still enforces the OCIN bounds on the specific header chain, which is as precise and prompt as possible. | ||
| - (TODO hmm.. what if the attacker sends a _fresh_ announcement that uses the revoked OCIN _just before_ it becomes immutable? |
There was a problem hiding this comment.
Issue #1029 tracks this TODO.
PR IntersectMBO/ouroboros-consensus#2179 fixes this TODO (differently than the "Perhaps" listed here)
This PR significantly elaborates the "Endorser block diffusion" section of the design document.
It includes the core of the plan that came out of the last few months of LeiosFetch design. It also includes explicit and detailed discussion of bounding memory usage, etc.