Implement Validation Process for Verifying Key Contract

[sifnoc]

The user who wants to verify their proofs on the Summa contract, can access the verifying key contract registered within the Summa contract. However, there is currently no way to ensure that the bytes correctly represent polynomials, permutations, or fixed commitments. As a result, users have no choice but to trust that the proof generated from the publicly known circuit and its verifying keys is correct, without any means to independently verify the verifying key.

Objective: We need a validation process for the verifying key contract that includes commitments, key digest and others.

Feature Description:
This issue proposes implementing a validation process for the vk_digest from the registered verifying key contract in the Summa contract, allowing it to be compared with the vk_digest generated by the user.

• The validation process should be based on the UnivariateGrandSum circuit known from the GitHub repo.
• To initiate the circuit, the N_BYTES and N_CURRENCIES parameters are required, either by reading the verifying key contract or as provided by the prover.
• The vk_digest is a hash of the entire text of parameters, which is initiated with the circuit and parameters. The hash process is detailed in this repository - halo2-solidity-verifier.
• The implementation should prioritize UX, ensuring that the comparison process is straightforward and user-friendly.

Additional Context:

• The verifying key contracts consist of multiple bytes in an assembly block, as shown below:

      constructor() {
          assembly {
              mstore(0x0000, 0x00996ed64113d5d86f42caab0f3d25466b0856015472de4bb809f168aabc2567) // vk_digest
              mstore(0x0020, 0x0000000000000000000000000000000000000000000000000000000000000011) // k
              mstore(0x0040, 0x30643640b9f82f90e83b698e5ea6179c7c05542e859533b48b9953a2f5360801) // n_inv
              mstore(0x0060, 0x304cd1e79cfa5b0f054e981a27ed7706e7ea6b06a7f266ef8db819c179c2c3ea) // omega

• This issue arose while considering this related issue: Wrong verifying key contract permutation length can be considered valid by validateVKPermutationsLength zBlock-2/summa-solvency#10

[protocolwhisper]

Hi👋🏼 correct me if I'm wrong the scope of this issue is to build the circuit that do the comparison?

[sifnoc]

Hi, correct me if I'm wrong the scope of this issue is to build the circuit that do the comparison?

No, not for the circuit. However, it could be a solidity contract if it's possible to evaluate the vk_digest from the given parameters.

The scope could also be extended to the entire verification process. The verification function logic already exists here:
https://github.com/summa-dev/halo2-solidity-verifier/blob/d33972567f83f3218257b286b541ad97ba32928c/src/codegen.rs#L169

[jkktom]

I'm interested in the issue. Can I contribute?

[sifnoc]

I saw your PR (#301) @protocolwhisper.

First of all, I apologize for not being specific enough in the initial issue description. I'd like to provide more detailed notes on the verification process to clarify things.

1. The user who wants to verify the verifying key contract should generate it from the verifier parameters, as shown here:
   

   summa-solvency/prover/bin/gen_verifier.rs

   Lines 38 to 39 in f11b1fe

   	let (params, pk, _) =
   	generate_setup_artifacts(K, Some("../backend/ptau/hermez-raw-17"), &circuit).unwrap();

   • Assume that the SRS file is publicly available, like this: https://github.com/han0110/halo2-kzg-srs, and that the K parameter is also known.

2. Users can generate the verifying key by themselves without requiring any input data, as demonstrated here:
   

   summa-solvency/prover/bin/gen_verifier.rs

   Line 60 in f11b1fe

   let (verifier_solidity, vk_verifier) = generator.render_separately().unwrap();

3. The user should be able to compare all the elements in the verifying key they generated in the previous step with the one deployed on the EVM, specifically the contract deployed with Summa.sol.

   • Assume that the user already knows the address of the verifier contract.

One key point: In V1 (master branch), the verification key is located inside the InclusionVerifier, as seen here:

summa-solvency/contracts/src/InclusionVerifier.sol

Lines 216 to 272 in 23587ad

	// Load vk into memory
	mstore(0x06c0, 0x10f28bc710a8bdd00dd701df2f5fc4f5ccdb260238eba6f819db692f79dc3dc9) // vk_digest
	mstore(0x06e0, 0x000000000000000000000000000000000000000000000000000000000000000b) // k
	mstore(0x0700, 0x305e41e912d579f5b3193badcab128321c8ee1cb70aa396331b979553d820001) // n_inv
	mstore(0x0720, 0x14c60185e75885d674db4b3f7d4a5694fa6c01aa0f53557b060bc04a4172705f) // omega
	mstore(0x0740, 0x2afd4e77273f1cb3434a4a667929058c156b21573c3f1efc882e708597d7161a) // omega_inv
	mstore(0x0760, 0x22b55603586d5fc42c6c14c2fc27a028c207da8b2c71cb33d549fa4a2be5d302) // omega_inv_to_l
	mstore(0x0780, 0x0000000000000000000000000000000000000000000000000000000000000004) // num_instances
	mstore(0x07a0, 0x0000000000000000000000000000000000000000000000000000000000000000) // has_accumulator
	mstore(0x07c0, 0x0000000000000000000000000000000000000000000000000000000000000000) // acc_offset
	mstore(0x07e0, 0x0000000000000000000000000000000000000000000000000000000000000000) // num_acc_limbs
	mstore(0x0800, 0x0000000000000000000000000000000000000000000000000000000000000000) // num_acc_limb_bits
	mstore(0x0820, 0x0000000000000000000000000000000000000000000000000000000000000001) // g1_x
	mstore(0x0840, 0x0000000000000000000000000000000000000000000000000000000000000002) // g1_y
	mstore(0x0860, 0x198e9393920d483a7260bfb731fb5d25f1aa493335a9e71297e485b7aef312c2) // g2_x_1
	mstore(0x0880, 0x1800deef121f1e76426a00665e5c4479674322d4f75edadd46debd5cd992f6ed) // g2_x_2
	mstore(0x08a0, 0x090689d0585ff075ec9e99ad690c3395bc4b313370b38ef355acdadcd122975b) // g2_y_1
	mstore(0x08c0, 0x12c85ea5db8c6deb4aab71808dcb408fe3d1e7690c43d37b4ce6cc0166fa7daa) // g2_y_2
	mstore(0x08e0, 0x26186a2d65ee4d2f9c9a5b91f86597d35f192cd120caf7e935d8443d1938e23d) // neg_s_g2_x_1
	mstore(0x0900, 0x30441fd1b5d3370482c42152a8899027716989a6996c2535bc9f7fee8aaef79e) // neg_s_g2_x_2
	mstore(0x0920, 0x16f363f103c80d7bbc8ad3c6867e0822bbc6000be91a4689755c7df40221c145) // neg_s_g2_y_1
	mstore(0x0940, 0x2b1cbb3e521edf5a622d82762a44a5e63f1e50b332d71154a4a7958d6011deff) // neg_s_g2_y_2
	mstore(0x0960, 0x010920a3471867216dc9dd6b478c16842fb5aca434fe6c9bf1622c4abd70381a) // fixed_comms[0].x
	mstore(0x0980, 0x300e30930f1a05253b28b6b139f2c38025d99b7a54e641f1d6ff2797d113c118) // fixed_comms[0].y
	mstore(0x09a0, 0x05e7899750f7abeae5d19c16666c47618fce810326b125d253dd41fb817dd65a) // fixed_comms[1].x
	mstore(0x09c0, 0x1e0e399ce46f208ab3f43aad0222f4dd37b8327b9f7afffa9cf9ee214e2460dd) // fixed_comms[1].y
	mstore(0x09e0, 0x22274e4efd4197dd6515994652d5beafcc7af94313d33e049cf5a1e464b52395) // fixed_comms[2].x
	mstore(0x0a00, 0x0ebb470e19409fcd84c0358c04300dc38cba0240141ddeb899ad9cca90167a64) // fixed_comms[2].y
	mstore(0x0a20, 0x162baf6245e2cec59bc93bc2302527d299cdb50e100f14895f170f316a2a2643) // fixed_comms[3].x
	mstore(0x0a40, 0x172a6f183e2ddc0607d23fd3daf4b23110b81d8a9d0a4e8d3d07ba24a007e04b) // fixed_comms[3].y
	mstore(0x0a60, 0x22e1cdbfffcfcf4f18cf4342edf1fb26c3b6e52ace3d5fadcf5cc2614333baa4) // fixed_comms[4].x
	mstore(0x0a80, 0x0e28df72dcc69cc6442d72f693661997480a913ac353890efd63a873959727c0) // fixed_comms[4].y
	mstore(0x0aa0, 0x01021a51384124c6844f2ba0e40e2545f26f280a79745c9164b0a56f1ee54d56) // fixed_comms[5].x
	mstore(0x0ac0, 0x2533607ba6f153a0126a8450a3cf47946933c93eaf69c996236b45603179c914) // fixed_comms[5].y
	mstore(0x0ae0, 0x1f59be81b3fd7d290930430d204c1a866937862306d75be70fedfe13e565ce0b) // fixed_comms[6].x
	mstore(0x0b00, 0x05931c531cd08b4aa937245293af81c4532fc4c01387d5b539d29f6c4ae00031) // fixed_comms[6].y
	mstore(0x0b20, 0x203b21a648fbfb96459640bbc5b41852dd1efc1209c89b635ba638dcb929da6b) // fixed_comms[7].x
	mstore(0x0b40, 0x04e7002f06f2091a44afcd311e93c22f46dd9f3207b5bcc34f0ca7652098f097) // fixed_comms[7].y
	mstore(0x0b60, 0x20ab7490b42f3f7b2b0bbe601a09d72ee93f924801d597f48cf2d443751d5f91) // fixed_comms[8].x
	mstore(0x0b80, 0x2bca2f1762946a05fb1632550c6cb12c02d18d9bee5bdd4212ca7342888720fd) // fixed_comms[8].y
	mstore(0x0ba0, 0x2aaba546cdd9969ef0aecc85b2aaa19b6e9639879962661415c8f0df426bac0c) // fixed_comms[9].x
	mstore(0x0bc0, 0x12b15327bcfbe7d9e9de1bc648ba3bdf910087362179a0b403cf70bad1c093c8) // fixed_comms[9].y
	mstore(0x0be0, 0x25909db723a8021ffe088c50525d6d260f9157be7a7c194b6f315386a46cdab8) // fixed_comms[10].x
	mstore(0x0c00, 0x25cbeae8ec2a8a2f74844f5e3276ed94079907bed6d7b1b26ed695328fe7bcae) // fixed_comms[10].y
	mstore(0x0c20, 0x26bffd26dd8f5f7679281f8d1a432690e07b15cbdf684fe456aa1277515e1730) // permutation_comms[0].x
	mstore(0x0c40, 0x015a3f09c82a770a69d67583d7049d83d69b7b8e03d38484497215cdc5979556) // permutation_comms[0].y
	mstore(0x0c60, 0x1ee4241e91ac391756b0b9893ac1e34ea95c6dd689e7dca12c62a6ce943960f1) // permutation_comms[1].x
	mstore(0x0c80, 0x10ad75f199bf1fb9335b91c20db6cd8958dcb2fe11983bc77cdb4036e57e59ca) // permutation_comms[1].y
	mstore(0x0ca0, 0x05eb5d19e589c11e0bb2200d66da829955545481885cfbc9099ec6a53e266ed2) // permutation_comms[2].x
	mstore(0x0cc0, 0x25ac1d9849f9f448cecc7ead7d48670f66bbfe7df8e248bd818a954df6936c27) // permutation_comms[2].y
	mstore(0x0ce0, 0x0743ea40f14084db2673217283aa053f986896ee7c181f52118442e99c452974) // permutation_comms[3].x
	mstore(0x0d00, 0x0203e3493a2594ece57d22cc75dd081ac68271ec7c758153cfd2152bfb5c19e3) // permutation_comms[3].y
	mstore(0x0d20, 0x1b95c5dc9bae0fb3f8208684042e57e0fcfbc3774af9ae0903ab9e9ddb4f89fd) // permutation_comms[4].x
	mstore(0x0d40, 0x1e8564e01419713739871224ce15f4c4b51e6af161d6e07a178e6545879035bf) // permutation_comms[4].y
	mstore(0x0d60, 0x1cefc889639cf98f94d831ea41c356929f9317778dda05ba0c5885401638db67) // permutation_comms[5].x
	mstore(0x0d80, 0x1e0466deb22a86d9122bc7180b7d293e47288244abf1450a5cd63a3289a457ca) // permutation_comms[5].y

However, in the V2 (v2 branch), the inclusion verifier contract has been separated, as shown here: https://github.com/summa-dev/summa-solvency/blob/v2/contracts/src/VerifyingKey.sol.

Therefore, I recommend modifying the V1 verifier contract generator to use the render_separately method, as was done in V2. This would make it more convenient to access the parameter values.

[2hyuk]

Hello! can i also contribute to this issue?

[bezze]

Hi! I've been following this issue for a while now, I've opened a PR to modify the contract templates to add a getter method por the verifying key. summa-dev/halo2-solidity-verifier#2