Feat/split receiver #448
Feat/split receiver #448
Conversation
…inlink-ccip into feat/split-receiver
| // 1. There is at least one account used for messaging (the first subset of accounts). This is because the first account is the program id to do the CPI | ||
| // 2. AND the logic_receiver has a value different than zeros | ||
| fn should_execute_messaging(logic_receiver: &Pubkey, remaining_accounts_empty: bool) -> bool { | ||
| !remaining_accounts_empty && *logic_receiver != Pubkey::default() |
There was a problem hiding this comment.
Should we check here for the compute Units as well?
| message.ExtraArgs.Accounts = []solana.PublicKey{ | ||
| config.CcipReceiverProgram, | ||
| config.ReceiverTargetAccountPDA, // writable (index = 1) | ||
| config.ReceiverExternalExecutionConfigPDA, // writable (index = 0) |
There was a problem hiding this comment.
It's weird why the tests did pass before this change 🤔
| // In EVM receiver means the address that all the listed tokens will transfer to and the address of the message execution. | ||
| // In Solana the receiver is split into two: | ||
| // Logic Receiver is the Program ID of the user's program that will execute the message | ||
| pub logic_receiver: Pubkey, |
There was a problem hiding this comment.
Wdyt about naming this message_receiver instead of logic_receiver? It feels closer to CCIP terminology in general, e.g. ccip use cases include "pure messaging" (thus message_receiver) vs "token transfer" vs "programmable token transfer" (which is the sum of the previous two)
Alternatively, using more of the Solana terminology, we could name it cpi_receiver
There was a problem hiding this comment.
There is actually no term for CCIP to distinguish the receiver between logic and tokens as for EVM they are both the same.
Naming them logic_receiver and token_receiver makes it impossible to have ambiguity between the two terms. Someone could argue that any CPI call is a message receiver or cpi receiver, those are more generics names.
There was a problem hiding this comment.
Looks sensible to me, but I'm still unsure about duplications between the fields in SVM2AnyMessage and the entries of remaining_accounts . Seeing as at least the logic_receiver (and potentially also token_receiver? Not sure) needs to be in remaining_accounts, maybe we should not have any Pubkey in Any2SVMRampMessage and nip the duplication in the bud. WDYT?
| receiver: Pubkey, | ||
| source_accounts: &[Pubkey], | ||
| logic_receiver: Pubkey, | ||
| extra_args_accounts: &[Pubkey], |
There was a problem hiding this comment.
I got rid of all of these here, just as a heads up to make sure what we've done works well together (I don't see why not: I don't mind rebasing on you if this gets merged first)
There was a problem hiding this comment.
This change is aming for clarity on the users and the protocol itself, it doesn't add any functionality. We need to establish an abstraction that is super clear for the users/offchain code what to send, and the receiver (token or logic) is the most sensitive part of the protocol, we can't have any missunderstanding or wrong configuration. We could only receive accounts and do all the validations, but this way we are sure that all the nodes have signed those addresses as logic and token receivers.
…inlink-ccip into feat/split-receiver
|
This pull request includes significant changes to the
ccip-routerprogram in the Solana blockchain, focusing on refactoring the receiver handling by splitting it intotoken_receiverandlogic_receiver. The changes affect multiple files, including core logic, tests, and documentation.These changes aim to improve the clarity and functionality of the
ccip-routerprogram by clearly distinguishing between the logic execution receiver and the token transfer receiver.