Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
This PR defines a tool that can run a continuous daemon that monitors confirmed challenges and outputs payable addresses and amounts for the purposes of reimbursing their gas fees and service fees from participating as honest validators. All it needs is an Ethereum L1 connection and a BOLD-enabled, Arbitrum rollup addresses to function.
It is based on the specification here
CAVEAT: This implementation is NOT production ready. It is meant to be a working proof of concept, which needs a lot more testing and robust error handling than today.
How it Works
The daemon processes all chain events related to assertion creation, edge creation, assertion confirmation, and edge confirmation from the rollup contract from the latest confirmed assertion block to the latest block, continuously. If it observes an assertion and it is a descendant of the latest confirmed, and is part of a challenge, it gets added to a
watchlist
set of hashes.Once an item in the watchlist is confirmed, an
executeReimbursement
method is called.If the confirmed item is of
assertionType
, we compute the protocol graph of edges for that assertion's challenge. Then, we compute the refinement edges at its lower challenge level that are confirmed / unconfirmed. For those that are confirmed, we reimburse gas. For the ones that are unconfirmed, we add to the watchlist and continue listening for events of confirmations.The output of
executeReimbursement
is apaymentRequest
, which will be forwarded to another goroutine that is listening for these requests. The goroutine will extract the info about the payable address, the amount they are owed based on gas expenditures and service fees, and save a pending payment JSON file to an output directory. Another party can run the same script and reproduce similar payment JSONs to cross-check the computation was correct.The main entrypoint spawns several goroutines, but the main one to follow is
processAssertionConfirmation
to understand the full flow.