Closed adlerjohn closed 2 years ago
renaynay
commented
2 years ago @adlerjohn can you create a list of TODOs for what it would take to close this issue? Since it's only an issue to spec out the behaviour. I'm asking only for project-board purposes so I know where to shuffle this ticket.
adlerjohn
commented
2 years ago Do you think the node behavior should be turned into an ADR (with more details on the implementation)?
renaynay
commented
2 years ago It doesn't have to be super formal, but it would be nice to have a blurb consolidating the thoughts documented across several issues + a flow diagram wouldn't hurt. Wdyt?
adlerjohn
commented
2 years ago For lack of a better place to put docs, in that case an ADR is probably what we need. It can consolidate this issue and also #263
Bidon15
commented
2 years ago Closing due to work being tracked in https://github.com/celestiaorg/celestia-node/issues/528
Summary
Tracking issue: #4
Define the behavior on producing and receving a BEFP.
Impact on users
Allows BEFPs, and therefore secure partial nodes.
Cost of not doing
No secure partial nodes.
Evidence
No response
Implementation ideas
Bridge Nodes
Producing: do not produce BEFPs.
Receiving: do not process received BEFPs. May forward received BEFPs, but not strictly necessary.
Full Nodes
Producing: produce BEFP when receiving a newly-seen block on the canonical chain (i.e. either during initial sync, or new blocks with a Commit). Then halt (i.e. continue running and distributing BEFPs and old blocks, but don't accept new blocks) until manual intervention.
Receiving: do not process received BEFPs. Should forward received BEFPs, but not strictly necessary.
Light Nodes
Producing: do not produce BEFPs.
Receiving: receiving BEFPs against blocks on the canonical chain (i.e. either during initial sync, or new blocks with a Commit). If received, halt (i.e. continue running and distributing BEFPs, but don't accept new blocks) until manual intervention.
Urgency
Medium