Implement DAS and query for app specific data #17
Conversation
evan-forbes
force-pushed
the
evan/sample
branch
from
8c327c0 to
135647a
Compare
|
@evan-forbes, a small note that you can already implement querying of a specific namespace and checking if DAH is available as #170 and #171 are merged. No need to wait for DASer, as it is just a component that continuously executes DASing. Also, #182 is not blocking you. |
evan-forbes
force-pushed
the
evan/sample
branch
from
6151f23 to
704409a
Compare
There was a problem hiding this comment.
Making this ready for review even though it still needs a refactor to properly utilize celestia-node, as it already contains too many changes. Instead of properly utilizing celestia-node, this version of the DALC is still downloading the entire celestia block to create the Data availability header by hand.
I'll have an issue up before this is merged describing the changes that need to be made to remedy this.
| // HeightMapper keeps track of which optimint blocks where posted to which celestia | ||
| // blocks | ||
| type HeightMapper struct { | ||
| Heights map[string]int64 | ||
| mut *sync.RWMutex | ||
| } |
There was a problem hiding this comment.
@tzdybal perhaps keeping track of optimint block height: celestia block height, belongs in optimint. I didn't want to add yet another KV database, but we will have to do something in the long term, as using a simple map and saving it as a json will obviously not be ideal for a blockchain with a few million blocks.
There was a problem hiding this comment.
I think keeping track is one of DALC functions, and Optimint should be agnostic. Also, I don't see any reason not to use KV store - it's operation won't be resource-consuming anyways.
This implementation is going to work only for aggregator node (to be super specific: DALC instance that will be used by aggregator, will also be able to serve optimint block data to other nodes). I described in #24 results of our previous conversations about locating blocks in celestia chain.
IMHO we should merge as is and create follow-up issue.
| // HeightMapper keeps track of which optimint blocks where posted to which celestia | ||
| // blocks | ||
| type HeightMapper struct { | ||
| Heights map[string]int64 | ||
| mut *sync.RWMutex | ||
| } |
There was a problem hiding this comment.
I think keeping track is one of DALC functions, and Optimint should be agnostic. Also, I don't see any reason not to use KV store - it's operation won't be resource-consuming anyways.
This implementation is going to work only for aggregator node (to be super specific: DALC instance that will be used by aggregator, will also be able to serve optimint block data to other nodes). I described in #24 results of our previous conversations about locating blocks in celestia chain.
IMHO we should merge as is and create follow-up issue.
Co-authored-by: John Adler <[email protected]>
Co-authored-by: John Adler <[email protected]>
Co-authored-by: John Adler <[email protected]>
Description
Adds DAS and fetching optimint blocks from the data availability layer.
closes: #5 #6