forge(verify): OKLink support

[bixia]

Motivation

To add support for the OKLink explorer contract verification. since the OKLink use almost the same API as the etherscan does for the contract verification part. the only difference is that the OKLink requires the Ok-Access-Key pass in the header, while etherscan requires the x-apiKey pass in the header.

Solution

So, basically i reuse lots of code from etherscan part, and modify accordingly, by adding the specific header.

Reference

• https://www.oklink.com/docs/zh/#explorer-rpc-api-contract-verifysourcecode

Closes #7724

[Evalir]

Should #7373 be closed in favor of this?

[bixia]

Should #7373 be closed in favor of this?

already closed, as request

[mattsse]

how is the oklink API different from etherscan?

if it's the same, we can likely reuse a lot of code

[bixia]

how is the oklink API different from etherscan?

if it's the same, we can likely reuse a lot of code

yes, it is almost the same, except for the headers

[bixia]

but for the headers, i find that the function i needed is from another crate. so i decide to copy it inside the verify function.

[mattsse]

are the headers strictly required?

if the API is compatible we can drastically simplify this, starting with a match here:

foundry/crates/verify/src/provider.rs

Lines 32 to 37 in 3581076

	match s {
	"e" | "etherscan" => Ok(VerificationProviderType::Etherscan),
	"s" | "sourcify" => Ok(VerificationProviderType::Sourcify),
	"b" | "blockscout" => Ok(VerificationProviderType::Blockscout),
	_ => Err(format!("Unknown provider: {s}")),
	}

if we need the headers then we can also add support for this by configuring the EtherscanVerificationProvider

here

foundry/crates/verify/src/provider.rs

Lines 66 to 69 in 30f145f

	impl VerificationProviderType {
	/// Returns the corresponding `VerificationProvider` for the key
	pub fn client(&self, key: &Option<String>) -> Result<Box<dyn VerificationProvider>> {
	match self {

[bixia]

are the headers strictly required?

if the API is compatible we can drastically simplify this, starting with a match here:

foundry/crates/verify/src/provider.rs

Lines 32 to 37 in 3581076

	match s {
	"e" | "etherscan" => Ok(VerificationProviderType::Etherscan),
	"s" | "sourcify" => Ok(VerificationProviderType::Sourcify),
	"b" | "blockscout" => Ok(VerificationProviderType::Blockscout),
	_ => Err(format!("Unknown provider: {s}")),
	}

if we need the headers then we can also add support for this by configuring the EtherscanVerificationProvider

here

foundry/crates/verify/src/provider.rs

Lines 66 to 69 in 30f145f

	impl VerificationProviderType {
	/// Returns the corresponding `VerificationProvider` for the key
	pub fn client(&self, key: &Option<String>) -> Result<Box<dyn VerificationProvider>> {
	match self {

yes, header is strictly required. and the headers' field name is changed to Ok-Access-Key

the main problem is that:

• most etherscan function is private, and can not be accessed out of the etherscan folder.
• the way etherscan post the request is handled over to foundry_block_explorers crate. which means i must modify the foundry_block_explorers part to add support for our specific header requirement.

to avoid this problem, inside this PR, i reuse some function from etherscan folder, and not use foundry_block_explorers as etherscan does, but rewrite in raw reqwest function.

by doing this, the modification to ur original code is minimal. all the modification is located in my oklink.rs file.

[mattsse]

by doing this, the modification to ur original code is minimal

I don't want to have effectively have the same code twice, if all we need is a few additional headers.

this can easily be supported by:

adding helper functions to set default headers here:

https://github.com/foundry-rs/block-explorers/blob/30a0476a712721b583c85e0b98a9680105e56a91/crates/block-explorers/src/lib.rs#L275

install default headers to the client here:

https://github.com/foundry-rs/block-explorers/blob/30a0476a712721b583c85e0b98a9680105e56a91/crates/block-explorers/src/lib.rs#L377

then the

foundry/crates/verify/src/etherscan/mod.rs

Line 40 in 68006b6

pub struct EtherscanVerificationProvider {

can have an additional map of headers that are then installed via the builder here:

foundry/crates/verify/src/etherscan/mod.rs

Line 302 in 68006b6

let mut builder = Client::builder();

[DaniPopes]

Can you also please look at #7733, should the API URL just be https://www.oklink.com/api here https://github.com/alloy-rs/chains/blob/14af647606c6945f433252ed96cd47397771e6ba/src/named.rs#L783 ?

[bixia]

Can you also please look at #7733, should the API URL just be https://www.oklink.com/api here https://github.com/alloy-rs/chains/blob/14af647606c6945f433252ed96cd47397771e6ba/src/named.rs#L783 ?

emm, the API url should be https://www.oklink.com/api/v5/explorer/AMOY_TESTNET/api/contract/verifysourcecode
the refer link is here:
https://www.oklink.com/docs/zh/#explorer-rpc-api-contract-getcontractcreation

[bixia]

by doing this, the modification to ur original code is minimal

I don't want to have effectively have the same code twice, if all we need is a few additional headers.

this can easily be supported by:

adding helper functions to set default headers here:

https://github.com/foundry-rs/block-explorers/blob/30a0476a712721b583c85e0b98a9680105e56a91/crates/block-explorers/src/lib.rs#L275

install default headers to the client here:

https://github.com/foundry-rs/block-explorers/blob/30a0476a712721b583c85e0b98a9680105e56a91/crates/block-explorers/src/lib.rs#L377

then the

foundry/crates/verify/src/etherscan/mod.rs

Line 40 in 68006b6

pub struct EtherscanVerificationProvider {

can have an additional map of headers that are then installed via the builder here:

foundry/crates/verify/src/etherscan/mod.rs

Line 302 in 68006b6

let mut builder = Client::builder();

i have discussed with our team member. the oklink API is not 100% compactable with etherscan API. since the etherscan API will change from time to time, oklink API may not keep up with it.
to help user who utilize foundry to verify contracts on oklink, we prefer to keep it separate and simple, and not tight to etherscan too much.

[bixia]

hi @mattsse the block_explore code layout has been transformed a lot.

should i just add another crate like the blob-explore?
i mean: it will be three explore: blob-explore, block-explore and oklink-explore.
since not only the headers, but also the url is totally different from each other between oklink and etherscan

[bixia]

close this PR in favor of #7915