Conversation
trianglesphere
force-pushed
the
jg/fix_l2_output_timestamps_v2
branch
from
835dc90 to
e1be3ce
Compare
| l2Header, err := d.cfg.L2Client.HeaderByNumber(ctx, nextCheckpointBlock) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("error resolving checkpoint block: %v", err) | ||
| } |
There was a problem hiding this comment.
Why not change the outputRootAtBlock RPC in the rollup-node to serve the L2 block header. That way it's always consistent. The l2 output root submitter shouldn't even need to directly talk to a L2 geth node I think
There was a problem hiding this comment.
That wouldn't solve the original issue nor a race condition on the proof. Original is that the timestamp -> block number conversion was wrong. The race condition is that we get by block number but don't check the proof against the header - the only way to do this is by checking the state root.
There was a problem hiding this comment.
FWIW, the server of the output root already does get a header and verifies the proof against the state root:
optimistic-specs/opnode/node/api.go
Line 73 in 5189b9a
It would be nice to serve the header in the same RPC response, and then the timestamp / block number can be used without extra calls with a separate RPC client to L2 geth.
There was a problem hiding this comment.
It's a good idea and you should make an issue for it.
Codecov Report
@@ Coverage Diff @@
## main #416 +/- ##
==========================================
- Coverage 53.12% 52.26% -0.87%
==========================================
Files 62 63 +1
Lines 6500 6703 +203
==========================================
+ Hits 3453 3503 +50
- Misses 2608 2764 +156
+ Partials 439 436 -3
Continue to review full report at Codecov.
|
trianglesphere
force-pushed
the
jg/fix_l2_output_timestamps_v2
branch
from
3f24a1e to
746e1d3
Compare
trianglesphere
force-pushed
the
jg/fix_l2_output_timestamps_v2
branch
from
746e1d3 to
65980a2
Compare
|
This is ready for a re-review. The test is failing because the sequencer is reorging on the L1 Info transaction between when it sequences it and when it verifies it |
| // unsafe portion of the chain which gets reorged on startup. The sequencer has an out of date view | ||
| // when it creates it's first block and uses and old L1 Origin. It then does not submit a batch | ||
| // for that block and subsequently reorgs to match what the verifier derives when running the | ||
| // reconcillation process. |
There was a problem hiding this comment.
I'd really like to know why this is happening
There was a problem hiding this comment.
I'm assuming that it starts block production prior to having a full up to date view of the L1 chain.
4 participants
Description
There was an off by one error in the L2 Output Oracle contract in the timestamp to
block number conversion. In addition, the L2 Output Submitter (op proposer) did
not recognize that there was a mismatch between the timestamp/block number in
the header and the timestamp/block number from the contract.
This bug causes problems when trying to do withdrawals.
Metadata