1. Union's Transfer Lifecycle: Understanding Gas Expenditure

As part of the transfer lifecycle in a bridging operation, the user and filler both expend gas to facilitate certain parts of the operation. In this article, we analyze Union’s gas cost at different parts of the stack and elaborate on the gas cost for both the zkp-based filling (main mode) as well as the intent-based filling scenario.

<aside> đź’ˇ

If you are already familiar with Union’s communication protocols, skip to Chapter 2: Benchmarking Gas Costs here

</aside>

Union supports different communication protocols. We will be analyzing ucs03-zkgm-1, the production-ready version of general message passing, asset transfers, NFT transfers and intent-based filling [1]. The protocol leverages state lenses [2] as well as optionally intent-based filling [3], and is core infrastructure for chain abstraction technologies.

We compare EVM to EVM bridging, as that is the most common operation, as well as the most cost-prohibitive. At the moment the altVM space has cheaper gas costs, making comparisons less interesting.

Furthermore, in this article we cover the following entrypoints (smart contract functions called at various steps of a transfer):

  1. sendPacket: enqueues a packet to be sent.
  2. batchSend: called by a filler to batch the commitments, saving gas on the destination side.
  3. updateClient: updates the light client using a ZKP.
  4. recvPacket or recvIntentPacket: submits the actual packet on the destination side.
  5. acknowledgePacket: repays the filler on the source chain.
sequenceDiagram    
    critical   
			  Note over Source: sendPacket
			 	Note over Source: batchSend
        Source ->> Union: ClientUpdate
        Union ->> Destination: ClientUpdate
         Note over Destination: updateClient
        Source -->> Destination: Packet
        Note over Destination: recvPacket
    end 
    Destination ->> Union: ClientUpdate
    Union ->> Source: ClientUpdate
    Note over Source: updateClient
    Destination -->> Source: Acknowledgement
    Note over Source: acknowledgePacket

The protocol has two phases, the critical phase (marked inside the box) and the acknowledgement phase. Once the critical phase is completed, a user has access to their funds on the destination side. This is considered the most urgent part and is therefore completed as soon as possible. The acknowledgement phase is required to process refunds and for updating the filler account, which is less urgent as it does not affect user experience.