SRI - Add the Verifirer.sol as an zkp artifact to the BPI and env

[ognjenkurtic]

• Do it
• Extend readme
• Deploy verifier contract in deploy.ts

[ognjenkurtic]

@biscuitdey what is the status here? are we going with 3 separate verifier contracts or a single one?

[biscuitdey]

@biscuitdey what is the status here? are we going with 3 separate verifier contracts or a single one?

@ognjenkurtic We are using 3 separate verifier contracts for the 3 worksteps for now,
because the verification key values are hardcoded inside the contract.
Using one verifier contract (where we pass the verification key as a function
param) is not possible as the contract uses assembly inside solidity contract
and assembly does not accept local variables. Also, if we declare the values as
storage variables, then we would have to change the verifyFunction code it as
there is different syntax to use storage variables.

Andreas suggested that we create a single verifier contract as an improvement later on. This would require us to alter how the verification key variables are called and utilised. Do you suggest we do it now or keep it for later?

[ognjenkurtic]

I think contract per workstep is fine for now, we can stick with 3

…

On Thu, 25 Jul 2024, 06:37 Biswashree Dey, ***@***.***> wrote: @biscuitdey <https://github.com/biscuitdey> what is the status here? are we going with 3 separate verifier contracts or a single one? @ognjenkurtic <https://github.com/ognjenkurtic> We are using 3 separate verifier contracts for the 3 worksteps for now, because the verification key values are hardcoded inside the contract. Using one verifier contract (where we pass the verification key as a function param) is not possible as the contract uses assembly inside solidity contract and assembly does not accept local variables. Also, if we declare the values as storage variables, then we would have to change the verifyFunction code it as there is different syntax to use storage variables. Andreas suggested that we create a single verifier contract as an improvement later on. This would require us to alter how the verification key variables are called and utilised. Do you suggest we do it now or keep it for later? — Reply to this email directly, view it on GitHub <#815 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFU2BTPDZGQDEN7CRT54YWDZOB6JDAVCNFSM6AAAAABLC2T7E6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBZGM3DMNBXHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>