ccipcapability: move interface impls #1025
Conversation
Move over the interface implementations, from the core smartcontractkit/chainlink repo, to a new go module within this repo called ccipcapability. This means that we can easily add an implementation for an interface that is newly defined without breaking builds elsewhere. Better co-location of interface and implementation also means less back and forth across repos which has historically been a big time sink. As of this commit, the ccipcapability module is importing smartcontractkit/chainlink but the goal is to not do that. However, the main sticking point is evmrelaytypes, the package that defines the EVM chainreader configuration struct. Ideally this moves to chainlink-evm at some point soon (see e.g. smartcontractkit/chainlink#16578) and we'd only have to import chainlink-evm instead. Some remaining things in chainlink would be the launcher and oraclecreator packages, which currently heavily depend on chainlink packages. They first need to be abstracted away from those so that we can safely extract them.
|
| github.com/smartcontractkit/chainlink-evm v0.0.0-20250617093943-9df97249e67b | ||
| github.com/smartcontractkit/chainlink-solana v1.1.2-0.20250611193111-99542a0c5d58 | ||
| github.com/smartcontractkit/chainlink/v2 v2.25.0 |
There was a problem hiding this comment.
We should be able to avoid importing all three of these
There was a problem hiding this comment.
How do you recommend we use them?
There was a problem hiding this comment.
I don't fully grok what the goal is in this change, but e.g. we access chain specific codecs through the Relayer interface, like these ReportCodecs: https://github.com/smartcontractkit/chainlink-common/blob/main/pkg/types/provider_ccip_ocr3.go#L12-L19
As for chainlink/v2, what packages & types are actually being used? The module comes with a ton of baggage and we can split out anything necessary so you don't have to inherit that mess.
There was a problem hiding this comment.
@jmank88 different teams are implementing CCIP for the different NonEVM chain, so we aren't really involved with how they decide to do it. The CCIP services could be in their own modules though, so there's a path to avoid the dependency in the CCIP protocol layer. They are already using a nice little driver registration service inspired by go's sql package.
| @@ -0,0 +1,229 @@ | |||
| module github.com/smartcontractkit/chainlink-ccip/ccipcapability | |||
There was a problem hiding this comment.
nit: I don't think we need the ccip prefix
| module github.com/smartcontractkit/chainlink-ccip/ccipcapability | |
| module github.com/smartcontractkit/chainlink-ccip/capability |
This sounds wrong. The configs are just encoded bytes that don't actually require importing all that baggage. We can fix this with basic types in chainlink-common. Can you link me to the types? |
Move over the interface implementations, from the core
smartcontractkit/chainlink repo, to a new go module within this repo
called ccipcapability.
This means that we can easily add an implementation for an interface
that is newly defined without breaking builds elsewhere. Better
co-location of interface and implementation also means less back and
forth across repos which has historically been a big time sink.
As of this commit, the ccipcapability module is importing
smartcontractkit/chainlink but the goal is to not do that. However, the
main sticking point is evmrelaytypes, the package that defines the EVM
chainreader configuration struct. Ideally this moves to chainlink-evm at
some point soon (see e.g.
smartcontractkit/chainlink#16578) and we'd only
have to import chainlink-evm instead.
Some remaining things in chainlink would be the launcher and
oraclecreator packages, which currently heavily depend on chainlink
packages. They first need to be abstracted away from those so that we
can safely extract them.