Add tooling for Lens verification

[fedgiac]

Description

Adds tooling needed to fully verify a deployment on Lens.

It uses the same verification procedure from 0ae8a26, but it uses the new-chain-deployment branch to guarantee that the metadata matches as well (and so the full verification works, not just the partial one).

I took the verification URL from internal discussion with the Lens team.

The commands are:

npx hardhat verify --network lens 0xC92E8bdf79f0507f65a392b0ab4667716BFE0110 0xBA12222222228d8Ba445958a75a0704d566BF2C8
npx hardhat verify --network lens 0x9008d19f58aabd9ed0d60971565aa8510560ab41 0x2c4c28DDBdAc9C5E7055b4C863b72eA0149D8aFE 0xBA12222222228d8Ba445958a75a0704d566BF2C8
npx hardhat verify --network lens 0x9E7Ae8Bdba9AA346739792d219a808884996Db67

Note that I added Sourcify verification as well despite Sourcify not supporting Lens. That's more for future tricky deployments since it can turn out to be handy.

I was unable to verify the authenticator itself. That's because it's a proxy and the proxy artifacts aren't available for the script to pick up. In particular, the following command does not work:

npx hardhat verify --network lens 0x2c4c28DDBdAc9C5E7055b4C863b72eA0149D8aFE 0x9E7Ae8Bdba9AA346739792d219a808884996Db67 0x6Fb5916c0f57f88004d5b5EB25f6f4D77353a1eD 0x7f7120fe0000000000000000000000006fb5916c0f57f88004d5b5eb25f6f4d77353a1ed

Test Plan

Check out the vault relayer, the settlement contract, and the allow list authentication implementation.

Extra chores

GitHub deprecated the action we rely on (1, 2). To fix that I just copied what we do on main.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​ethersproject/​keccak256@​5.3.0 ⏵ 5.8.0
	picocolors@​1.1.1
	strip-ansi@​6.0.0 ⏵ 6.0.1
	@​ethersproject/​base64@​5.3.0 ⏵ 5.8.0
	string-width@​4.2.2 ⏵ 4.2.3
	@​ethersproject/​constants@​5.3.0 ⏵ 5.8.0
	@​ethersproject/​logger@​5.8.0
	@​ethersproject/​strings@​5.3.0 ⏵ 5.8.0
	@​ethersproject/​signing-key@​5.3.0 ⏵ 5.8.0	+1		+1
	@​ethersproject/​transactions@​5.3.0 ⏵ 5.8.0	+1		+1
	@​ethersproject/​bytes@​5.3.0 ⏵ 5.8.0	+1		+1
	@​ethersproject/​hash@​5.3.0 ⏵ 5.8.0			+1
	@​ethersproject/​abstract-provider@​5.3.0 ⏵ 5.8.0	+1		+1
	@​ethersproject/​networks@​5.3.0 ⏵ 5.8.0	+1		+1
	@​ethersproject/​bignumber@​5.3.0 ⏵ 5.8.0	+1		+1
	@​ethersproject/​properties@​5.3.0 ⏵ 5.8.0	+1		+1
	@​ethersproject/​abstract-signer@​5.3.0 ⏵ 5.8.0	+1		+1
	@​ethersproject/​web@​5.3.0 ⏵ 5.8.0	+1		+1
	@​ethersproject/​abi@​5.3.0 ⏵ 5.8.0	+1		+1
	ansi-regex@​5.0.0 ⏵ 5.0.1		+16
	table@​6.7.1 ⏵ 6.9.0	+1		+1
	nofilter@​3.1.0
	@​fastify/​busboy@​2.1.1
	cbor@​8.1.0
	undici@​5.29.0
	@​nomicfoundation/​hardhat-verify@​2.1.0

View full report

[anxolin]

I tested that:

• Addressed match!
• They are verified with EXACT MATCH
• The bytecode matched mainnet (*1)

(*1) For the settlement contract, the bytecode is slightly different for some reason.

I didn't test test the validation itself work, because the command threw an error saying that they were already validated, also --force didn't help, but I trust they were validated using that command :)

[anxolin]

🤷‍♂️

[fedgiac]

(*1) For the settlement contract, the bytecode is slightly different for some reason.

The deployment calldata is exactly the same (otherwise we can't get the same address).
The deployed calldata is expected to be different because of the different domain separator.