Allow batch submitter to intentionally commit fraud#376
Conversation
|
This is failing in the CI because of This error happens when the CTC deploy height configuration option for Geth is too early. By any chance was a change made that changed the number of contracts being deployed? It could also happen if the contract deployment failed, but we do not wait for receipts so it is impossible to know for sure There are two open PRs that address this: #51 is no longer viable based on Karl's comment re: not waiting for each receipt in order failing deployment on Goerli. I usually deploy using a Ledger, so I don't observe this because the signing time is long enough between txs to not notice the problem. Also we need to be mindful of not changing the output of the deployer such that it breaks downstream services that depend on |
|
Right now the CTC deploy height is hard coded as 8. It would be better if we could access a receipt from |
|
Problems mentioned above solved by ethereum-optimism/contracts#132 |
| )) as L2Block | ||
| batch.push(block.stateRoot) | ||
| if (block.transactions[0].from === this.fraudSubmissionAddress) { | ||
| batch.push(ethers.utils.keccak256(Date.now().toString(16))) |
There was a problem hiding this comment.
Could we push a specific root instead of a hash? Would be nice to be able to easily see exactly which root was fraudulent inside the fraud prover.
smartcontracts
left a comment
There was a problem hiding this comment.
Approving preemptively, but LGTM
6862ffb to
73ac9ff
Compare
* fix(actions): trusted sync docker publish * fix * fully qualified path
### Description Replaces #370 Removes the `op-alloy-rpc-jsonrpsee` crate since `maili` provides this functionality in `maili-rpc-jsonrpsee`.
Description
A quick change to the state root batch submission to intentionally commit fraud if we so desire. (useful for the fraud proof security drill! The point is we'd get caught if we ever did this!!)
Contributing Agreement