You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now BN gets block data and block header by listening for events from Core's RPC. Soon, there will be a new event and endpoint there that will allow us to get the data in one request or recent block event(celestiaorg/celestia-core#940). This PR made me think about possible paths we can leverage this feature for our BN.
Revive an old idea about making DASer available on the BN by implementing CoreAvailbility or CoreGetter. That is, CoreListener notifies us about a new header, which eventually lands on DASer, which goes to the core component that requests data from the Core by its Root.
Simplifies and unifies BN data syncing maintainability because it became the same as for FN/LN
Removes obscure data storing logic in core
Requires changing the app's PR to decouple data and header events and endpoints.
Instead, make a share.Putter putter API in the share domain that allows putting EDS data into the cel-node. Also, the header broadcasting API on the header domain. The core domain would then listen for the SignedBlock/Data events from the core and use both of the APIs to add two types of data explicitly
Also, it does not require any changes to the app's PR
Also, removes obscure data storing logic in core
Enables top-level API to actually write data to cel-node and not only ready.
Personally, I like both approaches, but more inclined toward the second.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Right now BN gets block data and block header by listening for events from Core's RPC. Soon, there will be a new event and endpoint there that will allow us to get the data in one request or recent block event(celestiaorg/celestia-core#940). This PR made me think about possible paths we can leverage this feature for our BN.
CoreAvailbility
orCoreGetter
. That is,CoreListener
notifies us about a new header, which eventually lands on DASer, which goes to the core component that requests data from the Core by its Root.core
share.Putter
putter API in the share domain that allows putting EDS data into the cel-node. Also, the header broadcasting API on the header domain. The core domain would then listen for theSignedBlock/Data
events from the core and use both of the APIs to add two types of data explicitlycore
Personally, I like both approaches, but more inclined toward the second.
Beta Was this translation helpful? Give feedback.
All reactions