Paloma Weekly Wings: March 27, 2024 - Cosmos SDK 0.50.0 End-To-End Testing Progress Report and Pigeon Feed Compass-EVM Architecture Upgrade

Your new Paloma hatchlings this week?

Welcome to the weekly update on new software design from the Paloma community of developers.

REMINDER WARNING: The Hatchling Paloma Network of “Messenger” (v1.12.2) and the Pigeon relay module are on v1.10.3. Paloma is just over one year old and its Cosmwasm and EVM contracts are still unaudited and undergoing continuous upgrades on the protocol and its smart contracts. The GRAIN token is available on the Paloma mainnet but is not yet trading on exchanges. Although the flock is flying on the messenger mainnet, it is still subject to the continued development of Paloma’s cross-chain messaging system and the security guarantees offered by the GRAIN token. We expect “Messenger” to experience weekly chain halts and chain restarts for upgrades. We also expect numerous undiscovered vulnerabilities. No one on this project controls or influences the price of GRAINs. The community will strive to preserve the mainnet state, which includes balances, but considers this mainnet high-risk. Proceed with caution.

1. Cosmos SDK 0.50.0 End-To-End Testing Progress Report

End-To-End Testing

End-to-End Testing of the Cosmos SDK 0.50.0 is almost complete. The Vitwit team provided excellent script execution testing and updates to both Pigeon and Paloma. The Paloma team will now take over the final testing and upgrade to the latest version of Cosmos SDK 0.50.5. The next phase will require that Paloma’s protocol team backport the last release for attestation enforcement as well as upgrades to attestation checking. The runway view appears that Paloma will be ready for upgrade to both mainnet and testnest within the week.

We’re excited to bring a new Paloma to the flock which will bring Paloma up to speed and capacity of the leading blockchains in the Cosmos ecosystem. We’re optimistic that we’ll be ready for mainnest within the week.

2. Pigeon Feed Compass-EVM Architecture Upgrade

We propose an upgrade to Compass-EVM architecture to allow for new functions for tracking relay activities by validators and their authenticated refund claims on each target chain. Below, we introduce the specification for the upgraded Compass-EVM for Pigeon Feed with the functions and their uses.

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.

Community Fee

The community fee is set by governance on Paloma as a fraction of the relayer_fee . Users pay the community fee on top of the relayer fee when sending a message. The community fee is paid out to relayers who handle consensus messages like valset updates.

Security Fee

The security fee is set by governance on Paloma as a fraction of the relayer_fee . Users pay the security fee on top of the relayer fee when sending a message. The security fee is paid out to Volume.

Total fee

The total fee describes the total amount of fees a user will have to pay for sending a message. It is made up like this:

relayer_fee + community_fee + security_fee

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.

Assumptions and Requirements

• User pays for fees in native gas currency (ETH, BNB, etc…)

• User deposits prior to executing jobs on Paloma by calling a deposit(byte[32]) function on compass, sending his Paloma address as payload and some funds.

• Relayers are reimbursed in GRAINs, either on Paloma or on the target chain. Liquidity pools needed

• Paloma will only serve one SLC message per user at the same time to avoid exploits on running multiple jobs without sufficient funds to pay for fees

Message lifecycle

Question: How can we can avoid the second message by embedding the entire fee structure for the message into the payload?

 Answer: We populate the fee structure with plausible dummy values which will later be replaced with the actual fees to be moved. That way, payload size and execution flow should remain consistent between the estimate and the actual call, even though the given data for the fees will be different.

Therefore, the existing message lifecycle would be altered to include the fee structure as part of the payload, like this:

# author = paloma address of user who authored the message
def submit_logic_call(consensus: Consensus, args: LogicCallArgs, fees: FeeArgs, author:bytes32, message_id: uint256, deadline: uint256)

struct FeeArgs:
    relayer_fee: uint256 # Fee amout that should go to the relayer, i.e. 0.05 ETH
    community_fee: uint256 # Fee amount that should go into the community fee pot, i.e. 0.001 ETH
    security_fee: uint256 # Fee amount that should go into the security fee pot, i.e. 0.001 ETH

Execution flow outline

1. User submits job to the consensus queue

2. Paloma populates the fee structure component, the message enters the signing stage

3. Pigeons attest the message and sign the contents

4. Once consensus on message contents, the message enters the cooking stage

5. All validators retrieve the message, build a transaction and estimate the gas.

6. All estimates are returned to Paloma, Paloma builds a median.

7. Paloma uses the on-chain fee settings for relayer, community and security fee, populates the message payload accordingly.

8. The message enters the signing stage again. This time, all pigeons sign the message including the fee data, so no further tampering is possible.

9. After signing, the message is returned to the relayer for sending.

10. Relayer queries the user deposit balance on the remote chain from the gas wallet

11. If the funds do not cover the total fees, the message is dropped.

12. Otherwise, the message is relayed.

13. Compass picks up the message, verifies the signatures & relays to the target

14. Afterwards, compass updates the gas wallet by

    1. moving the relayer_fee from the user account to the relayer account

    2. moving the commnity_fee from the user account to the community fee pot account

    3. moving the security_fee from the user account to the security fee pot account

Stay up to date and follow the Paloma public repositories and the commits of ongoing upgrades to the Paloma Cosmos-SDK blockchain and the Pigeon relay module here:

https://github.com/palomachain/paloma/releases

https://github.com/palomachain/pigeon/releases

Pigeon of the Week: Robo-Pigeon

AI-generated robo-pigeon seeing more green this week! Time to make the most of it before the market swings again. Start your bot today at https://palomabot.ai

Conclusions:

Welcome to Paloma message attestation enforcement and Cosmos SDK 0.50.0 integration testing. A new Paloma is ready to spread wings and a new fee market for validators, not yet seen in the Cosmos. We look forward to sharing the progress of testing the new Paloma as we prepare for public testnest and mainnest.

We continue to fly with the flock! COO! COO!

To learn more about Paloma, please visit https://palomachain.com

To follow the project on Github, please star the project: https://github.com/palomachain/paloma

To participate in the community, please join the Paloma Discord: https://discord.gg/HtUvgxvh5N