feat(protocol): deploy the generated Yul plonk verifier

[davidtaikocha]

ref: #12126

Not included in this PR:

• verificationKey is hard-coded in the generated PlonkVerifier, need to make it as a configurable parameter.
• public input is assembled in client software for testing purposes right now, need to move this part of logic into protocol.

[codecov]

Codecov Report

Merging #13016 (23acef5) into main (088933e) will decrease coverage by 0.38%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##             main   #13016      +/-   ##
==========================================
- Coverage   65.34%   64.97%   -0.38%     
==========================================
  Files         113      112       -1     
  Lines        3105     3095      -10     
  Branches      386      383       -3     
==========================================
- Hits         2029     2011      -18     
- Misses        999     1008       +9     
+ Partials       77       76       -1     

Flag	Coverage Δ		*Carryforward flag
bridge-ui	92.61% <ø> (ø)		Carriedforward from 088933e
protocol	56.75% <50.00%> (-0.75%)	⬇️
relayer	69.10% <ø> (ø)		Carriedforward from 088933e
ui	100.00% <ø> (ø)		Carriedforward from 088933e

*This pull request uses carry forward flags. Click here to find out more.

Impacted Files	Coverage Δ
packages/protocol/contracts/L1/ProofVerifier.sol	0.00% <0.00%> (ø)
...ckages/protocol/contracts/L1/libs/LibProposing.sol	9.23% <ø> (ø)
packages/protocol/contracts/L1/libs/LibProving.sol	0.00% <ø> (ø)
...ckages/protocol/contracts/L1/libs/LibVerifying.sol	13.33% <0.00%> (ø)
packages/protocol/contracts/libs/LibZKP.sol	0.00% <0.00%> (ø)
...ackages/protocol/contracts/test/L1/TestTaikoL1.sol	87.50% <ø> (ø)
.../contracts/test/L1/TestTaikoL1EnableTokenomics.sol	0.00% <ø> (ø)
packages/protocol/contracts/L1/TaikoL1.sol	38.00% <100.00%> (-1.22%)	⬇️
packages/protocol/contracts/L1/libs/LibUtils.sol	27.27% <100.00%> (ø)
...es/protocol/contracts/thirdparty/LibMerkleTrie.sol	83.13% <0.00%> (-7.23%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[dantaik]

• verificationKey

@davidtaikocha is there only one verification key or multiple ones?

[davidtaikocha]

• verificationKey

@davidtaikocha is there only one verification key or multiple ones?

I think right now this generated PlonkVerifier contract file is for only one verification key, but need @smtmfft to confirm.

[dantaik]

Right now, we also look up from AddressManager the verification key, if there is only one of them built into Plonk Verifier, not sure if we need this look up.

[davidtaikocha]

Right now, we also look up from AddressManager the verification key, if there is only one of them built into Plonk Verifier, not sure if we need this look up.

will also update this part of logic if needed (might in another PR if this one got merged) after @smtmfft 's confirmation.

[smtmfft]

The circuit just has some max limits (tx number, calldata size, etc), so far I think we could have only one for test purpose.
Will see if we need more after we get more statistics.
I think the only difference is the proof generation performance of the k-degree circuit, for example, if a k=18 (2**18 rows) circuit could pack 10 txs (not even possible so far) and ideally it is roughtly 2x faster then k=19 (2**19 rows) circuit which could pack 20 txs, we can use different circuits setup, i.e., k=18 for txs <= 10 & k=19 for txs in (10..20].

[Brechtpd]

Seems like some manual work to get yul support in. Is it not possible to use existing plugins like https://github.com/ControlCplusControlV/hardhat-Yul? I never used hardhat so no idea if this would be sufficient or not.

[davidtaikocha]

Seems like some manual work to get yul support in. Is it not possible to use existing plugins like https://github.com/ControlCplusControlV/hardhat-Yul? I never used hardhat so no idea if this would be sufficient or not.

yeah I tried this hardhat plugin at first, but it failed to compile our generated yulp contract and returned the error in the screenshot above, looks like it was because this plugin is using a javescript yulp compiler that hasn't been updated in two years. And since I couldn't find some other good hardhat plugin options, so I decided to write the compiling job that using the official c++ sloc compiler manually. If the script works good in our usage scenario, then maybe we also can publish it as a hardhat plugin?