Next

[roberts-pumpurs]

No description provided.

[cjcobb23]

why does interchain token service need special handling? Surely this is not the only existing app that will make calls to Solana.

[roberts-pumpurs]

why does interchain token service need special handling?

• Because the abi spec for ITS needs to be consistent across all chains (any evm chain needs to be able to talk to our Solana ITS and vice-versa).
• This means that we cannot force arbitrary accounts[] data to be provided by the source chain. e.g The INTERCHAIN_TOKEN does not have a place to provide such info
• Without knowing the accounts[] on the relayer, we cannot create a transaction to send (hence why we even have the extra necessity of an encoding layer)

So, how do we solve this for ITS to get the accounts, to construct a tx?

We, on the relayer, introspect into the ITS payload and query the node state. We have developed ITS in a way that allows us to deterministically compute the accounts based on the message contents. This is ITS-specific handling that allows us to not break the existing interface. Meaning that all EVM ITSs will be able to communicate with the Solana ITS.

• this is where we have the special handling on the relayer
  
• this is the code that is responsible for introspecting into the message payload and deriving the accounts

Surely this is not the only existing app that will make calls to Solana

We can handle the generic case as long as the source chain also provides the accounts[] in the message payload like our relayer can parse it. Our Memo program is a good example:

• link to Solidity code
• link to e2e test
  

Otherwise, it would require adding a patch to the relayer to add another special-case handling -- assuming the special-case handling can even be done, as it requires designing the Solana program with that in mind up-front. In many cases, the accounts cannot be computed deterministically as we did for ITS.

[cjcobb23]

also how does the relayer know to perform this logic versus the other? Are the ITS contract addresses whitelisted?

[roberts-pumpurs]

Exactly, relayer has special handling based on the destination address specified in the GMP message:

    match destination_address {
        axelar_solana_its::ID => {
            let ix = its_instruction_builder::build_its_gmp_instruction(
                signer,
                gateway_incoming_message_pda,
                gateway_message_payload_pda,
                message.clone(),
                payload,
                solana_rpc_client,
            )
            .await?;

            send_transaction(solana_rpc_client, keypair, ix).await?
        }
        _ => {
            let ix = axelar_executable::construct_axelar_executable_ix(
                message,
                &payload,
                gateway_incoming_message_pda,
                gateway_message_payload_pda,
            )?;
            send_transaction(solana_rpc_client, keypair, ix).await?
        }
    };

[cjcobb23]

After thinking more, I think this needs to be a standard part of the protocol that apps can opt out of passing the accounts. Maybe in that case they use their own relayer, or we have some system that can figure out the accounts in the general case. But our design should be flexible, this sort of seems like right now the only usable apps are the whitelisted apps.

[roberts-pumpurs]

that apps can opt out of passing the accounts

Our Gateway does not expect the accounts to be present (it makes no assumption about that), and all account validation happens fully within the axelar-executable crate (meaning it's on the destination contract not on the Gateway).

This means that any app can fully opt out of this. The only issue is that Axelar protocol does not specify which relayer should be used when sending a message, hence why we have this generic case. But essentially this is all off-chain work (relayer / amplifier api) to support this case, to allow people to run their own relayers.

Our axelar-executable even exposes a function for calling validate_call to the Gateway without validating the accounts (this is what ITS uses).

or we have some system that can figure out the accounts in the general case

The accounts can be fully arbitrary, there is no "generic silver bullet" that can do this. Account computation is fully application-dependant; and there are even cases where the user can create his own "user owned accounts", where he generates a keypair locally -- that is impossible to compute via some seeds from a payload. Even now, our ITS is unable to work with user-owned accounts because of this restriction. By forcing the accounts to be computed deterministically, we're handicapping the Solana dapp developers.

But our design should be flexible,

Agreed

this sort of seems like right now the only usable apps are the whitelisted apps.

I disagree with this statement, as that implies that Solana apps in general are unusable because the accounts need to be specified up-front. But the Solana dapp ecosystem is thriving.

Here are the reasons why I believe that accounts should be specified on the source chain in a payload:

1. we can support arbitrary user-owned accounts (where the publickey for an account cannot be computed deterministically from the payload).
2. Any developer who builds a dapp for Solana will also have to interact with the accounts model, it's just a part of the transaction payload that you need to send. Same as in Solidity you need to specify the method name you want to call, in Solana you need to specify the accounts. It's just a fundamental primitive that cannot be hidden from the tx payload. By hiding the accounts on the source chain (e.g. EVM chain):
   • a dapp developer still needs to compute the accounts somewhere; you are just forcing the computation over to the relayer -- which the dapp developer now also needs to build and also host
   • you are eliminating user-owned accounts from the equation
   • you are forcing the "payload" to contain all the fields that would allow for deterministic computation
   • The Solana dapp now needs to do on-chain validation of the accounts (more expensive to compute) to ensure that the ones that were provided in the tx args are indeed the same ones that it expects for a given payload, making the app development even more difficult.
3. it is less-secure, because if account validation on the destination Solana program has a bug then you can easily exploit the whole cross-chain Solana dapp.

Essentially, a dapp developer still needs a way to compute the accounts, and by removing it from the source chain you handicap the Solana dapp developers, you force arbitrary relayer development and you make the whole GMP processing less secure because each app developer also needs to worry about deterministic account computation, which makes the GMP payload design much more difficult.

---

Now I will touch on what I meant by "expensive on-chain validation of accounts".
I want to bring to your attention that the accounts model in Solana is the backbone of the whole on-chain program security model. Let's take a simplified example of a "token mint" from the SPL-token codebase

As you can see, the payload is essentially empty, all the "juicy parts" are part of the accounts model aka the storage slots. The recipient cannot be computed deterministically in the generic case because it can also be a user-owned account. For the sake of example, lets assume that the recipient can be computed based on payload params.

So if we want to build a GMP integration that has the same interface, all of the data about which accounts to use still needs to be present in the GMP payload, so now we either prefix the accounts like we do for our current axelar-executable generic case, or we move it inside the payload in some kind of structured way that allows for deterministic computation (something that we do in our Solana ITS).

So, when our destination program receives the "MintTo" message and the accounts array via its executable() interface, how can it know that the provided accounts[] is indeed the one that should correspond to the GMP message? In our example, account[1] is supposed to be the "deterministically computed recipient" of the mint operation. How can the Solana contract know that a malicious relayer didn't just provide random accounts that it pleases? The on-chain logic now needs to replicate exactly the same steps that the relayer did to compute the accounts:

• it needs to introspect the message payload on-chain and re-compute all the accounts from the GMP message, and compare them with the accounts[] array that was passed in as args. This prevents malicious relayers from sending payloads that match the source chain with different accounts[] attached.
• if the accounts need to be computed on-chain only via deterministic seeds, then you will quickly make the transaction more and more expensive, because using Pubkey::find_program_address([seeds_from_payload], program_id) is a costly operation. So you are making the whole dapp do unnecessary calculations and more expensive.

Whereas in the generic case, when the accounts are provided as part of the payload, the destination contract (via axelar-executable crate) can do a simple comparison that the accounts provided as tx args are the same ones that are specified in the payload:

[cjcobb23]

What I mean by making this a standard part of the protocol is the payload should have some sort of encoding scheme where the caller can specify whether the accounts are included or not, instead of the relayer switching on the destination address. This would allow us to possibly build a generic solution to this problem in the future, instead of having to hardcode logic in the relayer. Imagine there exists a service that the relayer can call into dynamically to get the affected accounts. When a payload is received that doesn't specify the accounts, the relayer tries to fetch the accounts from this service. We don't need to build this now, but I'd like to design our system to be able to build something like this in the future.

[roberts-pumpurs]

ok, I see your point.
The first byte is fully configurable:

#[repr(u8)
enum EncodingType { borsh = 0, abi = 1, externalCall = 2 }

so we can add a third option in the future, which the relayer can interpret and fetch the accounts from some given axelar-owned-service. It shouldn't be an issue with the current scheme to do that. But then there's the trust property of how the accounts get validated and if they get validated -- that's an extra burden to the app devs tho.

[cjcobb23]

how exactly is the caller supposed to get this information in practice?

[roberts-pumpurs]

traditionally the frontend for the user computes this. Every client interacting with a Solana contract needs to be aware of the intricacies of the programs memory layout, pre-compute the accounts and provide them up-front when creating the transaction.

Example from the docs on how to create a transaction in JS

The same applies to the querying state. You don't query the state in Solana by interacting with the contract. You fetch the raw bytes at a given account address from the chain, and then the app must know how to deserialize the contents. And it's the app's responsibility to figure out the account it even needs to fetch.

---

In practice all of the computations are completely app dependant and completely arbitrary. Same as in Solidy you may compute memory slots up-front (link to AxelarAmplifierGateway), you must do the same on Solana for every piece of storage, and the end-user must provide it in the tx args.

---

Example from the Solana spl-token npm package -- they have client side logic to compute the accounts that must be provided up-front when making the transaction. This logic must be equivalent to the one we have inside the contracts, as it's fundamental to the on-chain security checks.

[cjcobb23]

also can you remind me how wormhole handles this situation?

[roberts-pumpurs]

Wormhole.

The source chain is fully responsible for producing a payload that can be interpreted by the relayer (eg hosted by the dapp, or the frontend that performs manual relaying), including all of the accounts.

Because Wormhole can run a custom relayer for each app, it also means that the encoding of the message is entirely up to the relayer / app as well (figuring out how to retrieve the necessary accounts for the interaction).

For their token bridging, the "manual relaying", where the user is responsible for sending all txs on both chains, they have the following implementation:

• for wrapped tokens they derive the accounts "on the relayer" (aka users frontend) similarly as we do right now on the relayer for ITS. As you can see, it's custom logic that is fully relayer-specific and not a generic solution.

---

Technically, it's up to the relayer to figure out how to interpret the binary data published on the source chain -- it can very well be a bincoded Solana tx that only requires signing & publishing (a bincoded solana tx already includes all the accounts inside of it + the payload).

• But a downside of pre-encoding via bincode on the source chain is that you still end up encoding all the data and the accounts (no benefit there), and you are forced to use bincode, which Solidity does not support, meaning you cannot produce a payload fully like that on-chain. Pro: relayer only signs arbitrary data & sends the tx away; simpler code.

[cjcobb23]

Shouldn't command_id be message_id? command_id is legacy, most everywhere in amplifier uses message_id

[roberts-pumpurs]

During a refactoring ~8 months ago, the term command_id changed its meaning; you may be still referring to the old one?

While it's true that the amplifier (ampd and cosmwasm contracts) uses message_id, the reference implementation uses the term command_id for referring to a hash of source_chain + message_id.

Extract from the reference:

Amplifier guarantees that the combination of source chain and message id will always be unique and fixed for a unique message. Hence, a deterministic command id can be derived based on the source chain and message id, and mark as executed to prevent replay.

The EVM gateway derives the command id as follows. External gateways for other chains can choose to use their own encoding scheme if preferred, as long as it's deterministic and includes the same values as below.

// sourceChain is guaranteed to not contain `_` character
bytes32 commandId = keccak256(bytes(string.concat(sourceChain, '_', messageId)));

[cjcobb23]

Can a malicious relayer mess up this process? i.e. submitting bad signatures, bad proofs, some other operation, while the honest relayer is trying to submit all of the correct data?

[roberts-pumpurs]

All of the operations made by the malicious relayer will fail:

• a bad signature will revert the transaction by the malicious relayer
• a bad proof will not verify against none of the Merkle roots

as a result, the on-chain tracker PDA state will not be affected, and the honest relayer can continue sending the proper data without disturbances.

[cjcobb23]

Will the payload hash a least be logged in this situation (truncated log)?

[roberts-pumpurs]

We can make no such guarantees. The 10kb hash is shared for the whole transaction log not a single log line. A log on the same tx can technically exhaust the whole limit, altho even reaching the 10kb limit via just on-chain actions is hard to achieve but not impossible.

But yes, in cases where a user accidentally sends 10kb, we will log the payload hash and other metadata first and only then the actual payload.

[cjcobb23]

Is this validated somehow? Like what if a contract puts a different account in the first slot, and effectively spoofs the sender. Is this possible?

[cjcobb23]

oh it looks like the next line talks about the validation, but it's unclear to me how this works exactly

[roberts-pumpurs]

You can imagine it like this:

1. Gateway has logic that says "if any contract wants to do CallContract you need to generate a PDA where the seed for the account is "GATEWAY_CALL_CONTRACT""

2. The source Solana contract is then responsible for generating this PDA and generating a signature with this PDA, then sends away the call to Gateway
3. The Gateway in its "call contract" logic checks: was the PDA derived in the correct way (you can see from the code screenshot above that the derivation is deterministic based on the seed and the source program)
4. if the PDA was derived correctly, then the gateway checks if the PDA was also the signer. In Solana, PDAs are scoped to a specific program, and in this case, it's scoped to the source Solana program, meaning that the source program is the only program that can produce a signature for its own PDAs. Effectively achieving msg.sender check via on-chain signatures.