Header
Title: Reduce Root Challenge Window to 60 Minutes
Author(s): Nick Pai
Status: Proposal
Submission Date: 04/11
Related Discussion: RFC
Body
Summary:
Every 90 minutes, a Dataworker proposes a batch of relayer repayments, slow fills, and expired deposits that should be issued based on the events that took place approximately since the last validated bundle. This period of events is equal to the liveness window assuming that the dataworker proposes root bundles very soon after the last one was executed. The liveness window therefore has a significant impact on relayer and LP capital efficiency and depositor UX. Reducing this window from to 60 minutes imposes very little additional security risk while adding a lot more capital efficiency to the system for all Across actors.
Overall, this proposal will be a big benefit for relayers:
- More frequent capital recycling leading to more compounding of profits
with a medium benefit for the dataworker:
- Can maintain a shorter lookback and reduce its RPC reliance
without significant downsides for relayers:
- a 60 minute challenge window is still plenty long enough to not impact volatility of repayment times because it gives challengers enough time to comfortably validate the a bundle multiple times post-probabilistic finality period for all L2s
Motivation:
The longer the challenge window for the root bundle proposal, the more costs are imposed on the following actors within the Across ecosystem:
- Relayers must maintain a longer look-back for fetching on-chain data in order to reconstruct bundles and determine upcoming refunds, slow fills, expired deposit refunds, and more bundle data.
- The Dataworker must maintain a look-back at least as old as the last known validated bundle in order to propose the next bundle. This results in more RPC requests and longer bot run-times.
- Refunds are sent less frequently to relayers
- Slow fills are executed slower for recipients
- Expired depositors are executed slower for depositors
- LP capital gets held on SpokePools for longer rather than getting returned back to the Hubpool. This reduces the compounding of fees for LPs
Specification & Implementation:
Liveness is currently set to 90 minutes, or 5400 seconds. This proposal will set the liveness to 60 minutes, or 3600 seconds.
Rationale:
The initial Across challenge window was 120 minutes, which was most recently decreased to 90 minutes. Personally, I think 45 to 30 minutes is the limit for this challenge window to remain safe for LP’s, but I maintain that 60 minutes would not affect security assumptions much.
On the other hand, the gain in capital efficiency was already significant going from 120 to 90 and I think it will also be very impactful to drop to 60. I recommend pausing again at 60 before further decreases and assessing the data for several months. Roughly, changing liveness from 90 to 60 minutes will allow Relayer capital to be recycled 33% times more frequently, slow fills and expired deposits will be refunded 33% faster, and Dataworker and Relayer implementations will be able to reduce their block lookbacks for the Deposits and Fills by 33% and save RPC costs on these expensive queries.
The reason why the 90 minute challenge window was chosen is for safety. This is a conservative amount of time for actors called Validators to evaluate a proposer’s root bundle proposal and react if they detect any misbehavior. The difference from 90 minutes to 60 minutes is small assuming it takes the validator less than 5 minutes to recompute a root bundle proposal. Empirically, 95% of validator runs using the example implementation repository will complete in << 5 minutes. This gives automated validators plenty of attempts to recompute a root bundle proposal, even when taking conservative finality assumptions into account. This also builds in enough buffer for a potential disputer to submit a dispute transaction on-chain.
In most cases, if a validator agrees with a root bundle proposal on its first run, it should continue to agree on it on following runs. The only time this changes is when chains undergo deep re-orgs or RPC’s suffer regressions and returns missing event logs. The thinking behind 60 minutes is to give a chance to validators to reconstruct the pending bundle from scratch, without relying on cached data, at least 3-5 times. If an honest validator agrees with a bundle 3 times in a row, then its very likely the root bundle proposal has proposed the “correct” bundle. This assumption gets violated if the proposer and the disputer are both relying on RPC’s that happen to be incorrect for the full liveness window. This is why both validators and proposers are usually configured to fetch data from multiple RPC providers and compare them before reacting.
Downside (Cons):
See the security concerns in section above. There is a very real tradeoff between UX, capital efficiency, and security with any decision affecting the liveness period.
Voting:
Yes: Set challenge window to 60 minutes
No: Keep challenge window at 90 minutes
Transaction Calldata:
Target: HubPool
Function: setLiveness
Parameters: 3600