General Grant Proposal

# General Grant Proposal * **Project:** Block Qualified ## Project Overview :page_facing_up: ### Overview Block Qualified aims to become an open education platform where anyone can create their own learning experience, gain credentials that attest to their knowledge, or verify the qualifications of others. All of this being done directly on-chain, with verifiable data, and preserving the privacy of users via zk proofs. ### Project Details Technology stack: * Typescript * Solidity * Circom The protocol is fully open source and for now supports multiple choice, open answer and mixed tests: https://github.com/0xdeenz/bq-core. The next step is to start getting feedback from the community by creating some demo tests and getting users to attempt to solve them. To this end, I have been in contact with Wesley, part of Ethereum Foundation and owner of https://www.useweb3.xyz/, to integrate some demo tests onto his learning platform. I plan on using this feedback to improve the smart contracts by adding/removing some of the logic as we see these solving attempts develop. Introducing Semaphore into the mix could add an additional privacy layer that would enable some additional functionality: * Having a reputation system for credential issuers, where scores are submitted privately by users, but the total reputation can be accessed publicly on chain. Similar in scope to Unirep. * Proving ownership of a given credential without revealing ownership of any other credential. Right now, ownership of a credential is implemented via an ERC721 balance model, which doesn’t allow for this kind of privacy. * Proving ability to obtain a certain credential (think, a credential that is only available to holders of another credential) without revealing their identity. * Creating groups for users holding certain credentials and for those who could not attain them, with the idea they may communicate with each other for a better learning experience. * Building the infrastructure to onboard legacy credential issuers. ## Team :busts_in_silhouette: ### Team members Sergio Martínez * sergio@deenz.dev * @deenzdev ### Team Website https://deenz.dev/ ### Team's experience First iteration of Block Qualified, only supporting multiple choice tests: https://github.com/0xdeenz/bq. Built a simple payment channel based on zk proofs and using circom: https://github.com/0xdeenz/rollup-demo. Won third place at the Web3 Infinity Hackathon with a dynamic NFT project: https://devpost.com/software/dorsia-club. Discontinued decentralized and private casino project based on zk proofs and using circom: https://github.com/0xdeenz/zkcasino ### Team Code Repos * https://github.com/0xdeenz/bq-core * https://github.com/0xdeenz/bq-core-react-app ## Development Roadmap :nut_and_bolt: ### Public Repository [Current state of development of **bq2**](https://github.com/0xdeenz/bq2). ### Overview * **Total Estimated Duration:** 300 hours * **Full-time equivalent (FTE):** 0.5 * **Total Costs:** $15,000 at a base rate of $50 ### Milestone 1: V1 Launch and Scaling * **Estimated duration:** 52 hours * **FTE:** 0.5 * **Costs:** $2,600 * **Estimated delivery date:** January 30th 2023 * **Delivery date:** April 4th 2023 | Number | Deliverable | Specification | | ------ | ----------- | ------------- | | 1.0a | Documentation | The [existing documentation](https://deenz.gitbook.io/bq-core/) will be modified based on the new scaling functionality described below. Besides providing insight into the implementation, it will cover how users can gain a credential. The documentation will also cover how Semaphore is being leveraged, and mention some best practices regarding how identities should be used. The ability to prove ownership of these credentials will be added later on. **Estimated duration:** 2 hours **Completed**: [documentation](https://deenz.gitbook.io/bq2/technical-reference/) covering the technical implementation: how users can gain a credential and how Semaphore is later used. | | 1.0b | Testing Guide | The code will have proper unit-test coverage to ensure functionality and robustness of this scaling functionality described below. A simple way to run these tests will be provided. **Completed**: tests can be ran as specified in the [repository's README](https://github.com/0xdeenz/bq2#testing) | | 1.1 | V1 Launch | In collaboration with the learning platform [useWeb3](https://www.useweb3.xyz/), the [existing implementation](https://github.com/0xdeenz/bq-core) will be put to the test by creating and launching some initial credentials. The goal with this is to gather feedback regarding the existing use case, which may help in defining some future functionalities. **Estimated duration:** 5 hours, over several weeks **Completed:** launched v1 platform under [academy.useweb3](https://academy.useweb3.xyz/) | | 1.2 | Restructuring | To ensure modularity and easier scalability with Semaphore, the repository will need to be restructured. A first step will be migrating it over to Typescript. The second step will require adapting the smart contracts to make sure all of the functionality defined below can be easily built on top of deployed contracts **Estimated duration:** 10 hours **Completed:** [public repository](https://github.com/0xdeenz/bq2) in Typescript, [smart contracts](https://github.com/0xdeenz/bq2/tree/9ee9f8356a23bc9a5f763cdc55b12f5d3defbd0e/packages/contracts/contracts) updated and better modularized. | | 1.3 | Functionality: Credentials Merkle Tree | As it stands, credentials function as non-transferable ERC-721 tokens which get minted to an address of the user's choosing. To fully leverage Semaphore, credentials will need to be defined as a [Semaphore group](https://semaphore.appliedzkp.org/docs/guides/groups) (one for each credential) that is incrementally built on chain as users gain these. To this end, the main circuits, smart contracts, infrastructure and test suite will need to be adapted. **Estimated duration:** 25 hours **Completed:** As described in the [documentation](https://deenz.gitbook.io/bq2/technical-reference/circuits#the-test-circuit), the [test circuit](https://github.com/0xdeenz/bq2/blob/9ee9f8356a23bc9a5f763cdc55b12f5d3defbd0e/packages/circuits/circuits/test.circom) adds the user's identity commitment to a Semaphore group after gaining the credential. These groups are managed inside the [smart contract](https://github.com/0xdeenz/bq2/blob/9ee9f8356a23bc9a5f763cdc55b12f5d3defbd0e/packages/contracts/contracts/base/Credentials.sol). Tests can be [created](https://deenz.gitbook.io/bq2/technical-reference/contracts#creating-a-test) and [solved](https://deenz.gitbook.io/bq2/technical-reference/contracts#solving-a-test) by anyone. | | 1.4 | Feedback Review | Reviewing the feedback gathered from the V1 launch to examine other possible areas of improvement. Expect an article detailing all that was learned from this initial release, the additional improvements that the community suggested, as well as their feasibility and how they could be implemented. Because of the nature of this deliverable, it will not be constrained by deadlines. We do however expect to make frequent updates. **Estimated duration:** 10 hours, over several weeks **Completed:** Wrote a short [medium article](https://medium.com/@deenz/what-you-learn-from-deploying-an-unfinished-product-87eea3d1d5fd) detailing the lessons that were learned from this initial release. | ### Milestone 2: Studying and Building Semaphore Updates * **Estimated duration:** 52 hours -- **completed** * **FTE:** 0.5 * **Costs:** $2,600 * **Estimated delivery date:** February 13th 2023 * **Delivery date:** February 15th 2023 * **Commit**: [9ee9f83](https://github.com/0xdeenz/bq2/tree/9ee9f8356a23bc9a5f763cdc55b12f5d3defbd0e) | Number | Deliverable | Specification | | ------ | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 2.0a | Documentation | The documentation for this part will provide insight into the implementation and also cover a basic tutorial that makes use of all the new functionalities. **Estimated duration:** 2 hours **Completed**: [documentation](https://deenz.gitbook.io/bq2/guides/proofs) covering how to make use of these new functionalities. | | 2.0b | Testing Guide | The code will have proper unit-tests covering these new functionalities. A simple way to run these tests will be provided. **Completed**: tests can be ran as specified in the [repository's README](https://github.com/0xdeenz/bq2#testing) | | 2.1 | Functionality: Credential Ownership Proof | Users that have gained a credential will have the ability to anonymously prove their ownership. This will be done by using Semaphore inclusion proofs, while also including details about the credential, like the score the user obtained. A function will be created that allows users to claim that they have one or several credentials. Another function will verify these claims. This could then be used by other applications to restrict off-chain services only to credential owners. **Estimated duration:** 15 hours **Completed**: after solving a test by providing a [valid proof](https://deenz.gitbook.io/bq2/guides/proofs/bq-test-proof) making use of the [libraries](https://github.com/0xdeenz/bq2/blob/9ee9f8356a23bc9a5f763cdc55b12f5d3defbd0e/packages/lib/src/provers/generateTestProof.ts#L19), users are added to the credentials group. They can later [prove they belong](https://deenz.gitbook.io/bq2/guides/proofs/semaphore-inclusion-proof) to the group via a [Semaphore proof](https://github.com/0xdeenz/bq2/blob/9ee9f8356a23bc9a5f763cdc55b12f5d3defbd0e/packages/lib/src/provers/generateCredentialOwnershipProof.ts#L19). Similarly, they can [prove that the grade they got is over a certain threshold](https://deenz.gitbook.io/bq2/technical-reference/circuits#the-grade-claim-circuit) using the [library functions](https://github.com/0xdeenz/bq2/blob/9ee9f8356a23bc9a5f763cdc55b12f5d3defbd0e/packages/lib/src/provers/generateGradeClaimProof.ts#L22). | | 2.2 | Functionality: Credential Non-Ownership Proof | Similar to the previous case, users that could not obtain a credential would be able to prove so, and a separate function can then verify these claims. These claims may also prove ownership of some credentials and non-ownership of others. Applications may use this functionality to allow users that could not obtain a credential to communicate with each other. **Estimated duration:** 15 hours **Completed**: if the user is not successful in obtaining the credential but still provides a [valid proof](https://deenz.gitbook.io/bq2/guides/proofs/bq-test-proof) making use of the [libraries](https://github.com/0xdeenz/bq2/blob/9ee9f8356a23bc9a5f763cdc55b12f5d3defbd0e/packages/lib/src/provers/generateTestProof.ts#L19), they are added to the no-credentials group. They can later [prove they belong](https://deenz.gitbook.io/bq2/guides/proofs/semaphore-inclusion-proof) to the group via a [Semaphore proof](https://github.com/0xdeenz/bq2/blob/9ee9f8356a23bc9a5f763cdc55b12f5d3defbd0e/packages/lib/src/provers/generateCredentialOwnershipProof.ts#L19). Similarly, they can [prove that the grade they got is over a certain threshold](https://deenz.gitbook.io/bq2/technical-reference/circuits#the-grade-claim-circuit) using the [library functions](https://github.com/0xdeenz/bq2/blob/9ee9f8356a23bc9a5f763cdc55b12f5d3defbd0e/packages/lib/src/provers/generateGradeClaimProof.ts#L22). | | 2.3 | Functionality: Reputation System | Users that have gained a credential will have the ability to anonymously rate the credential issuer. The libraries will be extended to add their rating of the credential issuer to a credential ownership proof. This ownership proof will be independent from the ones above (meaning, different external nullifiers) to ensure privacy. **Estimated duration:** 20 hours **Completed**: once they have gained the credential, users can [rate the credential issuer](https://deenz.gitbook.io/bq2/guides/functionalities/credential-issuer-rating) making use of the [library functions](https://github.com/0xdeenz/bq2/blob/9ee9f8356a23bc9a5f763cdc55b12f5d3defbd0e/packages/lib/src/provers/generateRateCredentialIssuerProof.ts#L17). The reputation system will later be built at the smart contract level. | | 2.4 | Application | These functions will work separately and will be provided as part of a library that applications may use to generate and verify these proofs of ownership | ### Milestone 3: Deploying Updates Implementing Semaphore * **Estimated duration:** 41 hours * **FTE:** 0.5 * **Costs:** $2,050 * **Estimated delivery date:** February 27th 2023 * **Delivery date:** March 3rd 2023 | Number | Deliverable | Specification | | ------ | ----------- | ------------- | | 3.0a | Documentation | The documentation for this part will provide insight into the implementation and also cover a basic tutorial that makes use of all the new functionalities via some test transactions. Smart contracts will also be deployed on test networks to this end. **Estimated duration:** 1 hours **Completed**: documentation covering [how these new functionalities work](https://deenz.gitbook.io/bq2/technical-reference/contracts) and [how to make use of these new functionalities](https://deenz.gitbook.io/bq2/guides/proofs). | | 3.0b | Testing Guide | The code will have proper unit-tests covering these new functionalities. A simple way to run these tests will be provided. **Completed**: tests can be ran as specified in the [repository's README](https://github.com/0xdeenz/bq2#testing) | | 3.1 | Functionality: Credential Ownership and Non-Ownership Proofs | Following the work of the previous milestone, the verification of these ownership and non-ownership proofs will be possible to be made on-chain. A smart contract function will be created that will revert if the proof or proofs given do not correspond to the claim being made. This way, on-chain services will be able to restrict functionality to owners of a credential by directly calling these public functions. **Estimated duration:** 20 hours **Completed**: The [credentials contract](https://github.com/0xdeenz/bq2/blob/main/packages/contracts/contracts/base/Credentials.sol) has external functions to [verify credential ownership](https://github.com/0xdeenz/bq2/blob/main/packages/contracts/contracts/base/Credentials.sol) and [verify a grade claim](https://deenz.gitbook.io/bq2/technical-reference/contracts#verifying-grade-claim-proofs). Additionally, credentials can be restricted to [owners of another credential](https://deenz.gitbook.io/bq2/technical-reference/contracts#creating-a-credential-restricted-test) or to [users that obtained a grade above a threshold for another credential](https://deenz.gitbook.io/bq2/technical-reference/contracts#creating-a-grade-restricted-test). The libraries also define functions to generate proofs for these [credential restricted](https://deenz.gitbook.io/bq2/guides/proofs/bq-restricted-test-proof#credential-restricted-tests) and [grade restricted](https://deenz.gitbook.io/bq2/guides/proofs/bq-restricted-test-proof#grade-restricted-tests) credentials | | 3.2 | Functionality: Reputation System | Following the work of the previous milestone, the verification of the reputation system votes will be made on-chain. A reputation system will be built that keeps track of the rates that credential issuers have received. This will take the shape of smart contract functions allowing for owners of a credential to rate the issuer, and functions to access the global rating of an issuer. **Estimated duration:** 20 hours **Completed**: the [credentials contract](https://github.com/0xdeenz/bq2/blob/main/packages/contracts/contracts/base/Credentials.sol) allows for holders of a credential to rate the issuer, and keeps track of these rates as described in the [documentation](https://deenz.gitbook.io/bq2/technical-reference/contracts#rating-the-credential-issuer). | | 3.3 | Application | These functions will be incorporated in several smart contracts. One of these will give users the ability to rate credential issuers and track these ratings. Another smart contract will allow external calls to be made to verify the claims described above directly on-chain. Some restructuring of the work done up to this point might need to be made. | ### Milestone 4: Building a Transaction Relayer * **Estimated duration:** 52 hours * **FTE:** 0.5 * **Costs:** $2,600 * **Estimated delivery date:** March 13th 2023 * **Delivery date:** April 1st 2023 * **Commit:** [5e9114f](https://github.com/0xdeenz/bq2/tree/5e9114f499ac59f0dc98c43b230e5024a63abe87) | Number | Deliverable | Specification | | ------ | ----------- | ------------- | | 3.0a | Documentation | The documentation for this will include a tutorial that includes how a user can spin up a transaction relayer targeting some credentials. **Estimated duration**: 2 hours **Completed:** Documentation covers how to [make use of the transaction relayer](https://deenz.gitbook.io/bq2/guides/guides#sending-a-solution-transaction) and other functionalities. | | 1.0b | Testing Guide | The code will have proper unit-tests covering the functionalities of the transaction relayer. | | 4.1 | Functionality: Transaction Relayer | To allow for even greater privacy, a relayer will need to be built that simply posts the user's proof on-chain. Users will send a request with their transaction to some off-chain service that, after verification, will post the user's proof on-chain. The smart contract function being called will remain the same, it is only the sender that changes: from the users themselves to this service. **Estimated duration:** 50 hours **Completed:** The relayer is implemented as part of the [TestCredential](https://github.com/0xdeenz/bq2/blob/5e9114f499ac59f0dc98c43b230e5024a63abe87/packages/lib/src/testCredential.ts) object. The [relayer address](https://mumbai.polygonscan.com/address/0x0eb560ea2007b0791232f343b29da064a1554182) can be seen making these transactions. | | 4.2 | Application | As these proofs are only linked to the user via their identity, which remains private, meaning relayers cannot extract any information from senders. The end result is that on-chain groups are updated the same way as before, but the source of these updates is only traced back to one address. This greatly increases the privacy of the users The cost of running such relayer will not be covered. | ### Milestone 5: Building Infrastructure to Onboard Legacy Credential Issuers by Using Semaphore * **Estimated duration:** 47 hours * **FTE:** 0.5 * **Costs:** $2,350 * **Estimated delivery date:** March 27th 2023 * Delivery date: April 8th 2023 * Commit: [a6a42b8](https://github.com/0xdeenz/bq2/tree/a6a42b80425f877f60ccf91d581a9c5ac2b290f0) | Number | Deliverable | Specification | | ------ | ----------- | ------------- | | 5.0a | Documentation | The documentation for this part will provide insight into the implementation and also cover a basic tutorial that covers how to create a new Semaphore group from an existing credential. **Estimated duration**: 2 hours **Completed:** the [documentation](https://github.com/0xdeenz/bq2/blob/a6a42b80425f877f60ccf91d581a9c5ac2b290f0/docs/guides/legacy-credential.md) covers the use of the functions described below. | | 5.0b | Testing Guide | The code will have proper unit-test covering these new functionalities. A simple way to run these tests will be provided. | | 5.1 | Functionality: Creating a Legacy Credential Group | Legacy credential issuers will have the the ability to create groups from already existing legacy credential recipients. These groups will allow for the same functionality as described in the milestones above. Legacy credential recipients will have the option to provide the issuer with their own identity commitment before the group is created. **Estimated duration:** 25 hours **Completed:** credential issuers can use the [LegacyCredential](https://github.com/0xdeenz/bq2/blob/a6a42b80425f877f60ccf91d581a9c5ac2b290f0/packages/lib/src/LegacyCredential.ts) library to generate these groups from existing credentials. | | 5.2 | Functionality: Add Identities to a Legacy Credential Group | Legacy credential issuers will have the ability to add users to their groups, adding their identity commitments directly into the tree. The credential issuer will still have to verify that the user does in fact have one of their legacy credentials, which may require going through an authentication service of their own. A function to generate an identity commitment, and another function to add this identity commitment to a legacy credential group will be created. **Estimated duration:** 20 hours **Completed:** credential issuers can use the [LegacyCredential](https://github.com/0xdeenz/bq2/blob/a6a42b80425f877f60ccf91d581a9c5ac2b290f0/packages/lib/src/LegacyCredential.ts) library to update these groups. | | 5.3 | Application | These functions will work separately and will be provided as part of a library that legacy credential issuers may use to generate and manage their groups off-chain | ### Milestone 6: Deploying Updates to Onboard Legacy Credential Issuers by Using Semaphore * **Estimated duration:** 46 hours * **FTE:** 0.5 * **Costs:** $2,300 * **Estimated delivery date:** April 10th 2023 * Delivery date: April 8th 2023 * Commit: [a6a42b8](https://github.com/0xdeenz/bq2/tree/a6a42b80425f877f60ccf91d581a9c5ac2b290f0) | Number | Deliverable | Specification | | ------ | ----------- | ------------- | | 6.0a | Documentation | The documentation for this part will provide insight into the implementation and also cover a basic tutorial that makes use of all the new functionalities via some test transactions. Smart contracts will also be deployed on test networks to this end. **Estimated duration**: 1 hours **Completed:** the [documentation](https://github.com/0xdeenz/bq2/blob/a6a42b80425f877f60ccf91d581a9c5ac2b290f0/docs/technical-reference/legacy-credential-manager.md) covers the implementation of the [LegacyCredentialManager](https://github.com/0xdeenz/bq2/blob/a6a42b80425f877f60ccf91d581a9c5ac2b290f0/packages/contracts/contracts/managers/LegacyCredentialManager.sol) smart contract. | | 6.0b | Testing Guide | The code will have proper unit-test covering these new functionalities. A simple way to run these tests will be provided. | | 6.1 | Functionality: Creating a Legacy Credential Group | Legacy credential issuers will be able to publish these groups on-chain. They will share the same functionality as covered in the previous milestones, and function in a similar fashion. Previous smart contracts might need to be updated for this. The library will include functions for credential issuers to generate these groups and publish them on-chain. **Estimated duration:** 25 hours **Completed:** the [LegacyCredentialManager](https://github.com/0xdeenz/bq2/blob/a6a42b80425f877f60ccf91d581a9c5ac2b290f0/packages/contracts/contracts/managers/LegacyCredentialManager.sol) smart contract allows users to directly define groups on-chain that follow the Block Qualified logic. | | 6.2 | Functionality: Add Identities to a Legacy Credential Group | Legacy credential issuers will be able to add identity commitments from users to these published groups. The library will include functions for credential issuers to add this identity commitment to an existing group and then publish this update on-chain. **Estimated duration:** 20 hours **Completed:** the [LegacyCredentialManager](https://github.com/0xdeenz/bq2/blob/a6a42b80425f877f60ccf91d581a9c5ac2b290f0/packages/contracts/contracts/managers/LegacyCredentialManager.sol) smart contract integrates with the [LegacyCredential](https://github.com/0xdeenz/bq2/blob/a6a42b80425f877f60ccf91d581a9c5ac2b290f0/packages/lib/src/LegacyCredential.ts) library to be able to manage groups off-chain and afterwards publish updates on-chain. | | 6.4 | Application | These functions will be incorporated as part of the main smart contracts, giving legacy credential issuers the ability to create these groups and add identity commitments to it. End users will then have access to all of the core functionality already covered. | ### Milestone 7: V2 Launch and Grant Conclusion * **Estimated duration:** 10 hours * **FTE:** 0.5 * **Costs:** $500 * **Estimated delivery date:** April 17th 2023 | Number | Deliverable | Specification | | ------ | ----------- | ------------- | | 7.1 | V2 Launch | In collaboration with the learning platform [useWeb3](https://www.useweb3.xyz/), we will look to put this new implementation to the test by creating and launching some initial credentials, and also making use of all these new features. | | 7.2 | Final Article | This will cover all of the functionalities that ended up getting added to the project, the main technical challenges and how they were solved, and also give an outlook on the possible next steps. **Estimated duration:** 10 hours | ## Additional Information :heavy_plus_sign: ### What work has been done so far? The [existing implementation](https://github.com/0xdeenz/bq-core) allows users to mint a non-transferable ERC-721 to an address of their choosing when they gain a credential. This allows for some level of privacy, but severely limits how this privacy can be leveraged. For example, users cannot prove that they own a credential without revealing the address where they hold it. If the user starts gaining multiple credentials, it becomes increasingly difficult for them to have to use a fresh wallet to hold each of these. Not doing so can hurt their privacy, as revealing they hold a certain credential would also reveal all the others they hold. Using Semaphore, we can ensure users can privately obtain as many credentials as they wish, with a single private key.