-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Family Specific Transmitters #16704
base: develop
Are you sure you want to change the base?
Conversation
…P contract transmitter
…tly supporting SVM and EVM
AER Report: CI Core ran successfully ✅AER Report: Operator UI CI ran successfully ✅ |
… into CCIP-5276_family_specific_transmitters # Conflicts: # core/capabilities/ccip/ocrimpls/contract_transmitter.go # core/capabilities/ccip/oraclecreator/plugin.go
|
// ContractTransmitterFactory creates commit/execute transmitters for a specific chain family. | ||
type ContractTransmitterFactory interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels like it would make more sense to define this in ocrimpls
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thought is that this is a factory interface for different transmitters , the implementation of which exist in the impl folder ?
type ExtraDataDecoded struct { | ||
ExtraArgsDecoded map[string]any | ||
DestExecDataDecoded []map[string]any | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have doc comments on public methods, members, and types that are introduced?
offrampAddress string, | ||
defaultMethod, priceOnlyMethod string, | ||
) ocr3types.ContractTransmitter[[]byte] { | ||
return &ccipTransmitter{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we using the same exact object for all these methods? The point of the separate transmitter per family is to literally have a different implementation. I don't think this PR really improves much upon the baseline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The design intentionally uses the same underlying transmitter type, but the key is that its behavior is driven by the injected toCalldataFn. Each factory provides its own implementation of this function, which tailors the calldata encoding and ultimately the transaction submission logic to the specific chain (EVM or Solana).
While the outer object is the same for common functionality the chain-specific logic lives in the callback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like this approach at all and I was the one that (unfortunately) introduced it.
Created a
ContractTransmitterFactory
interface with two functionsNewCommitTransmitter
NewExecTransmitter
This interface has two implementation
EVMContractTransmitterFactory
andSVMContractTransmitterFactory
with chain family specificToCalldataFunc