Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full Multi-query support onchain #321

Draft
wants to merge 92 commits into
base: master
Choose a base branch
from

Conversation

daveroga
Copy link
Contributor

@daveroga daveroga commented Dec 3, 2024

Implement multi-query support similar to existing requests now in Universal Verifier.

  • Manage multi-query (Query) independently and in the same way we are managing Requests in ZKPVerifierBase now (setQuery, getQuery, …). Avoid ZKP and generalize methods in Requests. setRequest, getRequest, submitResponse, …
  • Change _proofs mapping from address user to uint256 userID to keep identifier of the user.
  • Create 2 mappings for managing link between userAddress and userID . In this first version 1 userID will have only 1 address? Review best approach or if we have to keep an array of addresses.
mapping(address userAddress => uint256 userID) _user_address_to_id;
mapping(unit256 userID => address userAddress) _id_to_user_address; // check address[] ?
  • Manage Auth in specific type of requests. Auth requests.
requestId. 32 bytes (in Big Endian): 31-0x00(not used), 30-0x01(requestType), 29..0 hash calculated Id,

For requestType:
   - 0x00 - regular request
   - 0x01 - auth request
  • Define challenge based on the ethereum address in this first version
  • Figure out linkID between the Requests and Auth of the same Query.
  • Consider that more than one type of auth may be available there for specific multiRequest. And each of the multiRequests should define it’s own set of valid auth along with requests.
  • RequestId change from uint64 to uint256.

Link to Tech Spec for changes: https://www.notion.so/privado-id/Multi-query-Tech-Spec-13d4f86a875180e68fc8e3fa5362805e

@coveralls
Copy link

coveralls commented Dec 3, 2024

Pull Request Test Coverage Report for Build 12953945580

Details

  • 386 of 442 (87.33%) changed or added relevant lines in 23 files are covered.
  • 3 unchanged lines in 1 file lost coverage.
  • Overall coverage increased (+1.3%) to 85.362%

Changes Missing Coverage Covered Lines Changed/Added Lines %
contracts/validators/request/CredentialAtomicQueryV3Validator.sol 16 17 94.12%
contracts/validators/request/LinkedMultiQueryValidator.sol 47 48 97.92%
contracts/verifiers/ValidatorWhitelist.sol 7 9 77.78%
contracts/verifiers/Verifier.sol 215 219 98.17%
contracts/state/State.sol 7 15 46.67%
contracts/validators/auth/AuthV2Validator_forAuth.sol 30 38 78.95%
contracts/validators/auth/EthIdentityValidator.sol 0 13 0.0%
contracts/validators/request/AuthV2Validator.sol 0 19 0.0%
Files with Coverage Reduction New Missed Lines %
contracts/state/State.sol 3 75.71%
Totals Coverage Status
Change from base Build 12891717959: 1.3%
Covered Lines: 1238
Relevant Lines: 1361

💛 - Coveralls

@daveroga daveroga force-pushed the PID-2709-full-multi-query-support-on-chain branch from b70f050 to a02592c Compare December 5, 2024 11:33
contracts/verifiers/UniversalVerifierMultiQuery.sol Outdated Show resolved Hide resolved
contracts/verifiers/UniversalVerifierMultiQuery.sol Outdated Show resolved Hide resolved
contracts/verifiers/UniversalVerifierMultiQuery.sol Outdated Show resolved Hide resolved
contracts/verifiers/UniversalVerifierMultiQuery.sol Outdated Show resolved Hide resolved
contracts/verifiers/UniversalVerifierMultiQuery.sol Outdated Show resolved Hide resolved
contracts/verifiers/UniversalVerifierMultiQuery.sol Outdated Show resolved Hide resolved
@daveroga daveroga force-pushed the PID-2709-full-multi-query-support-on-chain branch from 5237dec to 822c81c Compare January 17, 2025 12:03
@daveroga daveroga force-pushed the PID-2709-full-multi-query-support-on-chain branch from 7819a0b to e2109e6 Compare January 17, 2025 19:36
/**
* @dev IVerifier. Interface for verification of groth16 proofs.
* @dev IVerifier. Interface for verification of groth16 proofs for validators circuits.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The description is wrong in speaking about groth16

IRequestValidator validator;
bytes params;
address creator;
uint256 verifierId;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering latest discussions, it doesn't seem we'll use the verifierId field anytime soon

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed from RequestData and RequestInfo

* @param proof proof to verify.
*/
struct AuthResponse {
string authType; //zkp-auth-v2, zkp-auth-v3, etc. will deside later
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please remove "will deside later" ? :)

Comment on lines +94 to +98
struct AuthType {
string authType;
IAuthValidator validator;
bytes params;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NatSpec is missing

Comment on lines 152 to 156
/**
* @dev Get the group of requests.
* @return Group of requests.
*/
function getGroupedRequests(uint256 groupID) external view returns (uint256[] memory);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That may be more practical to return RequestInfo[] rather than uint256[]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sure

IVerifier verifier = getVerifierByCircuitId(CIRCUIT_ID);
require(verifier != IVerifier(address(0)), "Verifier address should not be zero");
IGroth16Verifier verifier = getVerifierByCircuitId(CIRCUIT_ID);
require(verifier != IGroth16Verifier(address(0)), "Verifier address should not be zero");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

better something like g16verifier as a var name

Copy link
Contributor Author

@daveroga daveroga Jan 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed also other contracts var names following the same rule.

/// @dev Main storage structure for the contract
/// @custom:storage-location iden3.storage.EthIdentityValidator
struct EthIdentityValidatorBaseStorage {
IState state;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The IState state; can be removed as it is not used. So may be no storage at all

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are using state in the internal function _verifyEthIdentity. So we can't removed it.

Comment on lines 209 to 219
function _getRequestIfCanBeVerified(
uint64 requestId
uint256 requestId
)
internal
view
override(RequestDisableable, ValidatorWhitelist, ZKPVerifierBase)
override(RequestDisableable, ValidatorWhitelist, Verifier)
onlyEnabledRequest(requestId)
returns (IZKPVerifier.ZKPRequest storage)
returns (IVerifier.RequestData storage)
{
return super._getRequestIfCanBeVerified(requestId);
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm not missing something, you don't need the onlyEnabledRequest(requestId) modifier at Universal Verifier level. You anyway have it at RequestDisableable level.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think so. Removed the onlyEnabledRequest(requestId) at UniversalVerifier.sol level.

Comment on lines 46 to 54
struct UserAddressToIdInfo {
uint256 userID;
uint256 timestamp;
}

struct UserIdToAddressInfo {
address userAddress;
uint256 timestamp;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two structs are not used

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed

Comment on lines 226 to 234
function _setRequestWithChecks(
Request calldata request
)
internal
checkRequestExistence(request.requestId, false)
checkRequestGroupExistence(request, false)
{
_setRequest(request);
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

checkRequestExistence looks like duplicated in one of the flows that use this method.
Besides checkRequestGroupExistence is used only here and _setRequestWithChecks is used in one place only. So maybe remove _setRequestWithChecks method at all and reorganise the code

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this was old code from previous versions. Reorganized.

@daveroga daveroga force-pushed the PID-2709-full-multi-query-support-on-chain branch from fd814c2 to d952287 Compare January 21, 2025 09:20
AndriianChestnykh and others added 7 commits January 21, 2025 17:38
* LinkedMultiQuery small fixes

* Add more linked multi query tests

* Improve Linked Multi Query tests

* Scaffold verifier integration-test

* WIP

* Fix getValidatorVerification helpers method

* Fix lmk10 groth16 wrapper in constants

* Remove console from Verifier.sol
@daveroga daveroga force-pushed the PID-2709-full-multi-query-support-on-chain branch from 539badf to b18c064 Compare January 23, 2025 16:39
@daveroga daveroga force-pushed the PID-2709-full-multi-query-support-on-chain branch from c98bf44 to 109f3f8 Compare January 24, 2025 07:47
@daveroga daveroga force-pushed the PID-2709-full-multi-query-support-on-chain branch from 5256217 to a64341a Compare January 24, 2025 13:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants