docs/leios-design: draft ATK-LeiosProtocolBurst definition #624
Conversation
|
This was my first attempt. I anticipate I still need to massage it to address all the items you listed in the TODO stub, but I welcome feedback already. |
ch1bo
left a comment
ch1bo
left a comment
There was a problem hiding this comment.
Thanks for writing this up, this is very helpful and an important exercise in our load test / mitigation design
docs/leios-design/README.md
Outdated
| In this scenario, the CIP requires that the honest nodes attempt to acquire any EB that was promptly announced within the last 12 hours. | ||
| The conservative assumption is that the honest node might later need to switch to a fork that requires having this EB, and that switch ideally wouldn't be delayed by waiting on that EB's arrival. | ||
|
|
||
| For this attack, the adversary would announce each EB promptly, but withhold the messages that actually initiate the diffusion of substantial Leios traffic throughout the honest network. |
There was a problem hiding this comment.
I like that you we are explaining in detail how the attack would be mounted, but it's not clear enough to me yet (A picture might help too):
Does this mean their block headers do include announced_eb, but they never offer them via the mini-protocols?
CIP requires that the honest nodes attempt to acquire any EB that was promptly announced within the last 12 hours.
Does this imply that any of the volatile blocks could become the tip so we need the EBs to vote on them? Why? Wouldn't EB_slot + 3*L_header + L_vote (= the voting deadline) be long passed and these EBs cannot get certified?
There was a problem hiding this comment.
Wouldn't EB_slot + 3*L_header + L_vote (= the voting deadline) be long passed and these EBs cannot get certified?
The only information this node has is that it has not acquired the EB in time to vote for it. But that's not enough information for the node to know that the EB wasn't certified in the rest of the network.
I elaborated a couple sentences to help clarify this.
There was a problem hiding this comment.
Yeah so if it is not for voting, we should only be fetching the EBs that were certified? i.e. that would make up "stale" Leios traffic and be very similar to catching up on a selected chain, no? Plus, we would be fetching the ones that were recently announced and may end up being certified, even if we'd not vote for it (from competing chain).. but that is what I would call "fresh" Leios traffic and where such optimistic fetching is most important - to quickly switch to that chain if needed (as it was even written about in the published paper).
Closes IntersectMBO/ouroboros-consensus#1767.