-
Notifications
You must be signed in to change notification settings - Fork 420
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unified writer interface for Data Availability providers [NIT-1249] #2157
Conversation
} | ||
log.Warn("Falling back to storing data on chain", "err", err) | ||
} else if err != nil { | ||
sequencerMsg, err = b.dapWriter.Store(ctx, sequencerMsg, uint64(time.Now().Add(config.DASRetentionPeriod).Unix()), []byte{}, config.DisableDapFallbackStoreDataOnChain) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems unbalanced that daprovider.Writer
is used only to write to the DAS and daprovider.Reader
is used to read both DAS and blobs. I'm not sure how you'd structure it to be symmetric, though, since on one hand posting a batch to the DAS is a separate operation to posting the batch itself to L1, and with blobs both get posted together with the L1 tx.
Additionally for blob batch posting there is some unique logic around deciding whether or not to post as a 4844 tx or not #2158 which is different to the logic around whether to post a DAS batch or not (falls back on error only), so that also would make it hard to unify.
This is just an observation, we should seek more feedback about this from others on the team.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, I could not find a way to wrap blob posting to follow a common writer interface that other DAs implement.
Might be interesting to look at Celestia's DA impl (celestiaorg@e8c888a) and see if it looks like it would be easy to adapt to this new abstraction. I think the original motivation for this work was to make it easier to plug in new DA impls. Celestia took the Anytrust code as an example and added another DA system (eg blobs, Anytrust, and now Celestia). The batch poster writes the blob directly to Celestia, and then what gets stored on L1 is an object that contains enough data to retrieve and validate the blob directly from Celestia. |
I read through the Avail DA implementation availproject#8 and it looks like it should be easy to adapt to this interface since they conform to the pattern established in the prior unified reader interface PR #2155 They have already implemented |
Likewise Celestia has implemented |
Eigenlayer is also has an implementation in progress targeting the existing interface: https://github.com/Layr-Labs/nitro/pull/1/files https://github.com/Layr-Labs/nitro/blob/afk/unifyDAInterfaces/das/eigenda/eigenda.go |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR Introduces a generic writer interface for DA providers to implement