feat: add altda data source + eigenda implementation #1
Conversation
| let altda_provider = if boot.rollup_config.is_alt_da_enabled() { | ||
| // TODO: altda_provider should be a struct that contains all the altda providers, | ||
| // such that a rollup can dynamically switch between da providers if needed. | ||
| Some(OracleAltDAProvider::new_from_oracle(oracle.clone())) |
There was a problem hiding this comment.
Not really for failover, more like if some rollup decides to switch from celestia to eigenda or the other way around at some point in its existence.
| tonic.workspace = true | ||
|
|
||
| # AltDAs | ||
| eigenda-protos = { git = "https://github.com/samlaf/eigenda-protos.git" } |
There was a problem hiding this comment.
I'm actually thinking of creating a small rust dir in the eigenda repo just to publish this minimal crate with proto bindings (something like eigenda/proto/rust), wdyt?
There was a problem hiding this comment.
Can this kona repo reference the eigenda repo as a submodule and generate Rust code in kona repo? That seems less cluttered for the eigenda repo
There was a problem hiding this comment.
we could but then we have a repo to manage just for protobuf generation. Have the proto files ever changed (api changes)? Do we plan that they will change? If so how often?
nice thing with having in single repo is you can have a nice changelog file and when I go to eigen repo rust crate (it’s really just a small hidden dir, not that cluttering) I’m right next to change log file.
There was a problem hiding this comment.
But I agree that if we’re going to have an eigenDA rust client repo in the end, could also just publish a crate for the protobur independently.
| ) -> Result<Bytes, Self::Error>; | ||
|
|
||
| // TODO: should this be in a separate v2 trait? | ||
| async fn get_blob_v2(&self, blob_hashes: Bytes) -> Result<Bytes, Self::Error>; |
There was a problem hiding this comment.
Can we just let the proxy to figure that out? I remember there is a Cert version byte in the Cert
There was a problem hiding this comment.
Don't think so because eventually we'll need to make this secure aka client will need to prove the cert is valid right?
So it'll need to be aware of whether its working with v1 or v2 I would think?
There was a problem hiding this comment.
ok, just thinking about the fault proof
|
|
||
| /// The EigenDAProvider trait specifies the functionality of a data source that can provide eigenda blobs. | ||
| #[async_trait] | ||
| pub trait EigenDAProvider { |
There was a problem hiding this comment.
why do we define a trait for EigenDA, would this be one impl for AltDAProvider?
There was a problem hiding this comment.
Prob only so I can create a test implementation for testing.
This is a WIP, still lots to do, but main traits are setup I think...