New DALC API #341
New DALC API #341
Conversation
Codecov Report
@@ Coverage Diff @@
## main #341 +/- ##
==========================================
+ Coverage 58.61% 59.12% +0.50%
==========================================
Files 44 44
Lines 7092 7180 +88
==========================================
+ Hits 4157 4245 +88
- Misses 2363 2364 +1
+ Partials 572 571 -1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
This LGTM. I've run the simple ethermint RPC tests against the CI built evmos image using the ephemeral cluster and they pass.
I'm confused how the tests are passing since the ephemeral cluster setup using an older DALC image which shouldn't have a compatible API...
IIRC in ephemeral cluster we only have single optimint node, which is an aggregator. It shouldn't sync, so it's not using changed API. Only change in part related to block submission was adding single field in |
|
Pinging all approvors (@liamsi @jbowen93 @adlerjohn @evan-forbes) ;) PR is updated. All comments addressed. |
This mock DA implementation reflects all new requirements: - use new DA API (DA height oriented) - store multiple Optimint block in single DA block (at same height) - optimint blocks may be located in non-consecutive DA blocks New mock requires Optimint to implement block height mapping, improved sync logic. Many unit tests are going to fail now. Implementing mentioned features is required to fix the tests.
This time mock mimicks actual DA layer completely. It "creates blocks" at given intervals. Block height can be incremented by more than 1.
With new DALC API, syncing logic has to be changed. Block manager has to keep track of DA height (it's also saved in state).
tzdybal
force-pushed
the
tzdybal/new_dalc_api
branch
from
2be9218
to
eb2e87c
Compare
| m.logger.Error("failed to retrieve block from DALC", "daHeight", daHeight, "errors", err.Error()) | ||
| break | ||
| } | ||
| atomic.AddUint64(&m.daHeight, 1) |
There was a problem hiding this comment.
Wait, are you sure this is the right use of atomics?
What if &m.daHeight changes in between loading it and adding 1 to it here? Then you'd be adding 2 to it.
There was a problem hiding this comment.
This is the only place where m.daHeight is changed. It's atomic change, because we're reading this variable in several other places (in other goroutines). TBH the LoadUint64 in the beginning of the loop is not necessary (normal read should be fine), but I decided to handle this variable "atomically" everywhere for consistency.
There was a problem hiding this comment.
My concern is if e.g. &m.daHeight is N, then it could be read as N in two separate threads and incremented twice to N+2, completely bypassing N+1. Is that ever possible, if is so, is it a problem?
There was a problem hiding this comment.
It's not possible right now, as there is only one thread incrementing this variable, and I don't see a reason to add more threads/goroutines.
There was a problem hiding this comment.
Not going to block on #341 (comment), but if it's an issue can you open an PR to further investigate.
This PR introduces new DALC API into optimint.
Most important changes:
Actually, there's no need to explicitly map DA layer height to Optimint height.
Resolves #281.