Introduction

This is the technical report for the Catalyst fund13 project “EUTxO L2 Interoperability”. It will be used to gather and introduce background information, but also as a delivery artifact for the various milestones.

The full list of milestones can be found here and the corresponding chapters in this document will contain documentation, instructions and links to other materials to reproduce or use our results in further work.

Background

Relevant research

• State Machines across Isomorphic Layer 2 Ledgers: The main research piece that this project evaluates - about so-called ad-hoc ledgers where individual transactions are performed across multiple L2 ledgers atomically.
  • See Logbook 2025-04-04 and Logbook 2025-03-25 for notes on the paper
• Interhead Hydra: Full virtual Hydra state channels
• SoK: Communication Across Distributed Ledgers: Overview of cross chain communication and generic model of such protocols.

Reading list

• CRATE: Cross-Rollup Atomic Transaction Execution: coordinates transactions spanning multiple rollups such that they execute in an all-or-nothing manner with 4-round finality on the Layer-1.
• Optimism’s Superchain Interoperability (2024)
• Cross-Rollup MEV: Non-Atomic Arbitrage Across L2 Blockchains

Hash Timelock Contracts (HTLC)

Setting up an HTLC allows the sender to lock an asset to be spent “accordingly” or it allows them to get back their funds after a timeout. Not much scripting is required for this construction, hence it is popularly used in Bitcoin Lightning to effectively forward payments between channels.

In Bitcoin Lightning, HTLCs are also used to swap into and out of lightning channels from the Bitcoin main chain. These atomic swaps are called Submarine Swaps and are fully trustless (no custody, no counterparty risk) because they share the same underlying chain / security model (= Bitcoin).

Adaptor signatures

Originating from ideas on Scriptless scripts where correct execution of scripts is captured by the validity of digital signatures (elliptic curve based schemes), so-called adaptor signature schemes can be used to reveal information through the actual signature. Verifiably Encrypted Signatures (VES) are a generalization of this concept onto both Schnorr and ECDSA signature schemes.

Related work about cross-chain atomic swaps between Bitcoin and Monero suggests that adaptor signatures can be used to realize unlocking on even very constrained target chains (Monero). We are in a much more comfortable position of very scriptable ledgers.

Quite low-level treatment on the signature schemes: https://medium.com/crypto-garage/adaptor-signature-schnorr-signature-and-ecdsa-da0663c2adc4

Milestone 1

Consists of two parts

1. HTLC prototype of payment between two L2s
2. Transaction design for ad-hoc ledgers

HTLC payment

Example workflow of a payment of some $USDM from Alice to Bob via one intermediary Ida using Hash-Time-Locked Contracts (HTLC).

The topology of the involved L2s is not further specified here, but could be for example two Hydra heads between Alice-Ida and Ida-Bob, or a two-party head beween Alice-Ida and both, Ida and Bob being participants of a Midgard optimistic rollup. Even multi-party heads where multiple intermediaries could share the collateral across multiple HTLC outputs are thinkable, but that would need further investigation how we can guarantee collateralization across multiple outputs.

Logbook that contains thinking, discussions, pains, joys, events, and experiences that happen while working on this project. It is supposed to be a kind of Stream of consciousness that can later be searched, linked to or reviewed. It may also be used as a very informal decision log.

2025-04-04

By @ch1bo and @SwiftlyUnmoving

• Discussing our take-aways from the paper
• Glances over the fact that script spending does not generalize easily
• Collateralization and fee structure is handwavy and could be problematic
• How to make NFTs minting policy compatible with L2s
  • Case on script context and have values for Hydra, Hydrozoa, Midgard, …?
  • Equivalent of a spending validator agreeing to be committed into L2
  • But we would need to delegate trust to Hydra, Midgard etc. when minting happens later on L1
  • On L1 we can identify that we are minting in e.g. a Hydra fanout and can green-light this if the validator set is enough
• Interfacing spending validators with L2s (on committing) is equivalent to using them for atomic transactions across L2
• Atomic transactions across L2s is kind of equal to establishing an L3 (and that same interfacing problem when going L2 -> L3)
• Spending and minting needs to be compatible with the cross ledger protocol (i.e. the wrap-perform transaction)
• Collaterizing NFTs is an issue for any cross-ledger protocol!
  • While in the L2 case, there may be a chance to avoid duplication as we share the same L1 and a dispute protocol can exist
  • However that would still mean that one party will only be refundend the collateral instead of the NFT
  • Also: What’s sufficient collateral for one NFT, who decides?
  • Too high collateral limits liquidity / reach of such an NFT (each intermediary set would need to be liquid enough)
  • Even harder to estimate for state thread tokens (which ensure contract continuity)
    • Consolidation of smart contract state is going to be hard.
• How does the ad-hoc ledger concept scale?
  • For example in doing multiple hops and routing
  • In principle, collateral should be sharable across inermediaries (per hop)
  • We should model this to see wheather the whole feasible the concept is
  • Timing within payment channel networks is adding up, is this the case here too?
• Difficulty levels of “asset under interop”
  • Easiest: one currency value (UTxO = Bitcoin)
  • Easy: multiple, fungible assets (UTxO-ma, only FT)
  • Medium: non-fungible tokens (UTxO-ma, also NFTs)
  • Hardest: fully scriptable spending and minting (EUTxO)
• Liquidity across the path
  • Lightning already has the complexity of direction in liquidity
  • In a full UTxO ledger, it is even more difficult as the assets might not be owned by the validator
  • Need to know how much collateral is available for route finding
• Do we even benefit from UTxO ledger model over an account model?
  • Maybe not?
  • Would simplify collateral allocation
  • Indidividual state channel interactions might benefit from it, but for bridging / routing funds across ledgers not so much?
  • One account for each interop protocol intermediary (= collateral available = liquidity available)
• What if liveness of L2 breaks down?
  • Wrapped UTxOs must be recoverable or performable on L1
  • We should “front load” as much work as possible in the wrapping (aka verify) transaction so that perform or dispute can always fit on L1 even
• We also mentioned in passing that the only way we could do full script verification (with simulated script context) for verify would be by side-stepping the L2 ledger and build support into Hydra/Midgard
• Also: is there a timeout before a dispute can be made? Otherwise we would race between signing perform and doing a dispute -> or is this not an issue?

2025-04-01

By @ch1bo

• Want to establish a logbook to put notes for this project
• Rendering into the mdbook like I started doing for cardano-blueprint seems useful too
• Hower, using the Github wiki as a logbook is producing less noisy commits on the main repository
• The github wiki is also a repository we can add as a submodule, i.e.

  git submodule add wiki git@github.com:cardano-scaling/eutxo-l2-interop.wiki.git
  

• Then, symlinking the the logbook.md into book/ and adding it to SUMMARY.md does the trick
• Now, only nix is choking on submodules (as always)
• Found the idea of tracking the submodule as a flake input online in this thread https://discourse.nixos.org/t/get-nix-flake-to-include-git-submodule/30324/16
• Now, we track the submodule commit also in the flake.lock, but at least the nix build works as-is.

2025-03-25

By @ch1bo

• Re-read the research paper and started a summary in the technical report
• Approach is quite “ad-hoc” indeed and borrows on generalization of HTLCs being similar “two-step commit schemes”
• Relevant other paper SoK: Communication Across Distributed Ledgers which focuses on cross chain communication, but establishes as generic model: “A generic CCC protocol consists of three main phases: commit (on X), verify (and commit on Y ), and an optional abort”
• Could improve some terminology around “utxo addresses” which seem to be rather “output references”
• Wrap + perform is basically a two stage commit similar to the above
• Script continuity of verify-perform? What if L2 closes? Need intermediaries ensure continuity somehow “on top” of running the L2 ledger?
• UTxO and UTxOma should be “embeddable” into EUTxO protocol for ad-hoc ledgers - as they do not require general scriptability
• Verifying the transaction on “wrap” sounds like side-stepping the EUTxO ledger? i.e. simulate a script context with outputs as they would on perform
• Mint tokens on wrapping -> why not on perform? to avoid burning in case of dispute
• Setting a dispute flag on the wrapped UTxO would rather be another state of the protocol!?
• What if liveness of L2s break?
• The biggest open questions remain:
  • How to collateralize NFTs?
  • How to generically wrap script UTxOs without side-stepping EUTxO ledger?
  • How to ensure script continuity of wrap + perform steps (without minting tokens ourselves; what if L2 closes)?

Demo

Diagrams & Maths

We can use mermaid diagrams (live editor):

graph LR;
    A-->B-->D;
    A-->C;

and maths using katex:

$$\mathcal{U}=(\Phi \times \mathcal{O}{)}^{\ast }$$

Alerts

cargo install mdbook-alerts

Footnotes

Additional information that would complicate the read-flow can be put into footnotes ¹.