Draft: Fast withdrawals for FA tokens

Julien Coolenrequested to merge
ju@fa_fast_withdrawals into master

What

Fast withdrawals overview

This MR is part of the fast withdrawals task.

Deposits of tokens from L1 to L2 (Etherlink) are confirmed with a low latency. This is however not the case for withdrawals (moving back tokens from L2 to L1), due to the refutation period for the state of the optimistic L2. At a high level, fast withdrawals of tokens from L2 (Etherlink) to L1 are made possible thanks to liquidity providers on L1 that prepay withdrawals and receive the withdrawals back later (once the refutation period ended) in exchange for a small fee. This allows to reduce the time for withdrawals from two weeks down to a few minutes (if not less) depending on the service provider.

Workflow: !16341 (diffs)

Fast withdrawals documentation:

Changes in this MR

This merge request updates the L1 withdrawal manager contract to handle both Tez and FA token transfers by parsing tickets and dispatching to the correct entrypoint, specifically %burn for TezTickets and %withdraw for FA tokens. It also modifies the L2 precompile to emit a fast withdrawal event, craft a fast withdrawal message in the smart rollup outbox targeting the L1 withdrawal manager contract. A basic E2E test for fast withdrawal functionality is provided.

How

  • L1 contract: The contract now parses the incoming ticket to determine whether it should route the transfer to the TezTicket %burn entrypoint (for Tez transfers) or the FA %withdraw entrypoint (for FA tokens). For reference:
  • L2 precompile: Implements logic to emit a fast withdrawal event and create a fast withdrawal message in the smart rollup outbox.
  • Testing: A basic E2E test has been written, following the existing test for regular Tez fast withdrawals, to validate the fast withdrawal process for both Tez and FA tokens.

Manually testing the MR

dune exec etherlink/tezt/tests/main.exe -- evm fa_withdrawal fast_withdrawal /dal /threshold_encryption latest alpha --file evm_sequencer.ml --keep-temp

Checklist

  • Document the interface of any function added or modified (see the coding guidelines)
  • Document any change to the user interface, including configuration parameters (see node configuration)
  • Provide automatic testing (see the testing guide).
  • For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
  • Select suitable reviewers using the Reviewers field below.
  • Select as Assignee the next person who should take action on that MR
Edited by Julien Coolen

Merge request reports