Deploy Protocol Contracts on LightLink Mainnet and Testnet

[vanshwassan]

Deployed and verified protocol contracts on LightLink Mainnet and LightLink Goerli Testnet.

LightLink Phoenix Mainnet:

• AccessControlRegistry

• AirnodeRrpV0

• AirnodeRrpV0DryRun

• RequesterAuthorizerWithAirnode

LightLink Pegasus Testnet:

• AccessControlRegistry

• AirnodeRrpV0

• AirnodeRrpV0DryRun

• RequesterAuthorizerWithAirnode

[Ashar2shahid]

I'm still confused on the path forward with api3dao/chains#137. Should that be reopened and merged, followed by a 4.3.0 release (4.2.0 is already released)?

Currently the chains CI runs on every chain in the package, there needs to be a flag to disable CI operation on a chain (for more fringe chains)

[bbenligiray]

These deployments shouldn't be pushed here unless the same chain is already published in @api3/chains. Non-dAPI related chain additions to @api3/chains will create overhead for the dAPI operations. I thought you were going to do this completely off-repo.

[Ashar2shahid]

I think RRP deployments should live in this repo for completeness sake, the dependency on @api3/chains should be figured out IMO rather than have RRP deployments live in some other repo. Alternatively, we can have another repo "qrng-deployments" where we do all the rrp deployments if we do not want to support this.

[dcroote]

Non-dAPI related chain additions to @api3/chains will create overhead for the dAPI operations

I thought api3/chains was the single source of truth for all chains and I lean this way:

@api3/chains should be figured out IMO rather than have RRP deployments live in some other repo

Otherwise, we then have another source of chains and chain IDs to deal with. What could work is more streamlined or automated api3/chains release process to minimize the effort involved in adding a chain.

[andreogle]

I generally don't really follow what's going on with new chain integrations, but I'm happy to help streamline any processes with @api3/chains to make it easy to work with. I tried to make the repo as developer friendly as possible to encourage contributions/PRs. The guard rails (linting checks) are also fairly strict to prevent anything from going wrong. Adding a new chain should be a fairly straightforward exercise at this point. I'm also happy to do same day releases assuming I'm available (otherwise someone else can help with this or we can automate it).

I assume this comment is the problematic one? I don't have much capacity at the moment to get too involved here, but it should be fairly straightforward to implement a new field that skips the chain in the CI. Happy to accept PRs if it's a blocker

[dcroote]

@andreogle - I find api3/chains quite dev friendly- didn't mean otherwise and apologies if it came off sounding that way. I created https://github.com/api3dao/chains/issues/153 and assigned myself to work on now so this can unblock folks.

[andreogle]

didn't mean otherwise and apologies if it came off sounding that way

I didn't take it that way at all 😄 Thanks for implementing the PR to skip provider checks 👍🏻 (cc @vanshwassan).

I also just meant that I'm happy to try to help make the repo and/or process as streamlined as possible - whatever that might look like. I'm not a primary user of it so I don't always understand where the issues/blockers are.

[dcroote]

@vanshwassan - the PR for skipping a chain in CI is merged so now https://github.com/api3dao/chains/pull/137 can be reopened, the new field added, merged, and api3/chains released. Then this PR, updated with the new api3/chains version, can be merged 😅

[vanshwassan]

The @api3/chains PR is merged and v4.3.0 is released. Updated the branch and package version.