Paloma Pigeon Feed Phase 03 Design

R&D
1

Overview

The Paloma network vision began with the Cosmos Gravity project work for cross-chain bridging. During our efforts on Cross-chain bridge development, we stumbled upon the ability to use the Gravity bridge to make arbitrary logic calls to smart contracts on any target chain. Some other protocols may refer to this feature as “message passing” between blockchains. We called it a “logic call” because it was usually one-way, smart contract calls from the host chain to the target chain. The host chain would send the bytecode instructions to the target chain. The contract Application Binary Interface, or the ABI, would decode and process the instructions sent to the target chain. However, message passing implies bi-directional information transmission, which no logic call protocols currently offer.

One of the key issues around arbitrary logic calls was an economic issue: Who would pay for the target chain gas required for validators to execute the logic call from their expensive RPC endpoints? How would validators know which endpoints to support and how to communicate gas costs without the ability to communicate with logic call users synchronously? How does one create a system that scales without requiring the Volume team to make decisions about relay cost refunds and settlement on each individually supported chain?

Paloma’s Pigeon Feed module aims to answer this question by creating a gas and relay performance marketplace between Pigeon validators, logic call users, and application developers. Paloma pigeons must be able to set their own desired fee for relaying. This is similar to Bitcoin, where miners can choose which transactions they will accept to create a block. Thus, Bitcoin miners are incentivized to create blocks with the transactions that pay the most fees as those with the highest priority.

Given that Paloma pigeons are setting their desired rates for gas payments on target chains, Paloma also will need to allow validators to claim those fees on the target chains, themselves. This removes the need for Paloma validators to bridge and swap their gas fees on Paloma’s decentralized exchanges. We believe that a competitive relay-gas fee market between pigeons and users will lower the costs of logic calls, which should incentivize more users to use logical calls as validators compete for message relay fees.

Below, we discuss the relay fee setting and tracking design we propose for the next Pigeon Feed, Phase 03 phase.

Terminology

User

An entity on the Paloma network that can interact with the network using an address and sign transactions using a key pair. It could be a physical person, an automated script, or a smart contract execution.

Message

An arbitrary message that any user can send to any of Paloma’s supported target chains networks will be relayed by a Paloma validator, also known as a relayer.

Relayer

A user of the Paloma network who participates in consensus and provides his services as a relayer to the network receives a fee as a reward for the logic call work attempted.

Relayer fee

A reward fee is paid by the user when sending a message and reimbursed to the relayer at a later point. It is defined as a fractional value of the estimated gas costs of a transaction containing a message to be relayed. Relayers can set different fees on each target chain, for example:

  • eth-main: 1.25 (relayer will be reimbursed by the user with 125% of the estimated gas costs)
  • op-main: 1.5 (relayer will be reimbursed by the user with 150% of the estimated gas costs)

To make a profit, the value must be greater than 1. The fee is always paid in native chain currency on the target chain.

Gas wallet

Any user who wants to relay a message must reimburse the relayer with a fee defined as a fraction of the estimated gas costs. The user pays this fee in native currency on the target chain.

This means the user will need to send their gas funds, on the target chain, into a prepaid account owned by Paloma’s compass , or directly to compass. The deposited amount is then used as payment for reimbursing relayers for any message sent by the user, as long as the balance can cover the minimum required costs.

This account (either owned by Compass or Compass itself) is called the gas wallet in the context of Pigeon Feed.

Pigeon Feed Lifecycle

Pigeon_Feed_Design
Pigeon_Feed_Design799×2271 141 KB

Risk assessment

We identify several issues about the risks created in the system from this design:

State sync

  • The Paloma Cosmos-SDK protocol does not communicate with target chains directly.
  • The Paloma protocol cannot query target chains to verify whether the relayer has made sufficient deposits.
  • Asking Pigeons to check before every Submit Logic Call (SLC) message will create a lot of noise and, most conclusively, slow down the entire protocol.
  • Keeping a shadow copy of the ledger of messages relayed and their gas paid on compass in store on Paloma allows us to check whether the user is supposed to have sufficient funds in the deposit.
  • Before the Submit Logic Call (SLC) is executed, the relayer will check with the compass whether the condition is still met. Otherwise, the relay is not attempted.
  • A slight delay is expected between the actual decrease in funds on Compass and the update on Paloma.
  • Race conditions can occur if a user sends a lot of messages in a short amount of time. They can lead to Paloma thinking the user still has enough credits on Compass to pay for the reimbursement.
  • This is largely fine since Pigeon checks with Compass before every Submit Logic Call transaction.
  • However, a case may arise in which two different Pigeons relay simultaneously for the same user, and the user has only enough funds to cover one message. The second message will fail in that case, but the relayer will have paid the gas. Who refunds?
  • The solution to avoid this is fund allocation and reservation. The downside: a lot more complexity
    • Pigeons tell Compass, “Hey, I will send you a message with ID 123. Does USER X have sufficient funds in the fee deposit to cover the refund costs of 250uCOIN?
    • Compass will respond with yes or no. If it responds with YES, then Compass needs to earmark 250uCOIN from the fee deposit of USER X as reserved for a message with ID 123. Subsequent queries for other message IDs will fail, and the original race condition is no longer possible.
    • The reserved balance will need to be unreserved after n blocks if the message is not relayed until then to avoid forever locked up funds.

Differences in paid gas and claimable reward

  • We can not know the ultimate gas cost before TX is executed
  • Potentially the eth_estimateGas will yield 100uCOIN
  • Pigeon will calculate the total fee for the relayer (i.e. 1.25 → 125uCOIN)
  • Pigeon asks compass to confirm the user has at least 125uCOIN in the fee deposit to pay for the claimable rewards
  • Compass says yes, Pigeon then sends off the message
  • Pigeon relays the message, but now the gas cost is 155uCOIN
  • The relayer will only receive 125uCOIN as reward though, effectively incurring a loss.

Updates to the consensus queue

  • SLC messages are stored in a queue on Paloma and assigned to a relayer
  • At the moment, there is no concept of relay abort, which we need in case
    • A user executes a message
    • Paloma (working against an eventually consistent shadow copy) still thinks they have sufficient fee deposit balances
    • Pigeons find they do not have the fee when they ask for live information
  • Otherwise, we’ll keep retrying for a long time, clogging the network and burning gas