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 https://github.com/foundry-rs/foundry/issues/7724

[bixia]

Should #7373 be closed in favor of this?

already closed, as request

[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:

https://github.com/foundry-rs/foundry/blob/358107683da49f4f57b8ff7123c5e119af7d9544/crates/verify/src/provider.rs#L32-L37

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

here https://github.com/foundry-rs/foundry/blob/30f145ff677eb01361f7f05c3233c133d1fd0d5b/crates/verify/src/provider.rs#L66-L69

[bixia]

are the headers strictly required?

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

https://github.com/foundry-rs/foundry/blob/358107683da49f4f57b8ff7123c5e119af7d9544/crates/verify/src/provider.rs#L32-L37

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

here

https://github.com/foundry-rs/foundry/blob/30f145ff677eb01361f7f05c3233c133d1fd0d5b/crates/verify/src/provider.rs#L66-L69

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

https://github.com/foundry-rs/foundry/blob/68006b65f3df56d262a3402b7cfb4b87fed71efc/crates/verify/src/etherscan/mod.rs#L40-L40

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

https://github.com/foundry-rs/foundry/blob/68006b65f3df56d262a3402b7cfb4b87fed71efc/crates/verify/src/etherscan/mod.rs#L302-L302

[DaniPopes]

Can you also please look at https://github.com/foundry-rs/foundry/issues/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

https://github.com/foundry-rs/foundry/blob/68006b65f3df56d262a3402b7cfb4b87fed71efc/crates/verify/src/etherscan/mod.rs#L40-L40

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

https://github.com/foundry-rs/foundry/blob/68006b65f3df56d262a3402b7cfb4b87fed71efc/crates/verify/src/etherscan/mod.rs#L302-L302

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 https://github.com/foundry-rs/foundry/pull/7915