A verifiable time-constrained, frictionless mechanism for Proof of Humanity renewals
NOTE 1: I am not an expert in blockchain technology, nor in cryptographic security. All the ideas described on this post are from what I have been learning from a Senior Programmer perspective. Feel free to double check and send any corrections that might need fixing.
NOTE 2: I will refer by Human(s) as the submitter of the evidence (whether its in the registration or the renewal process)
A PERSONAL OPINION:
Proof of Humanity is slowly proving to be the solution for a sybil-resistant Identity protocol. I also believe that it solves the task that most governments fail of giving an Identity, which is a human right.
One task that has been tabled for months as the project moved forward, is the mechanism for renewing profiles.
There is yet not a well defined framework about how this process should be. On this post I intend to propose such mechanism to achieve this in a frictionless UX for Humans and Curators.
The proposal includes definitions on what counts as a valid renewal submission for Curators and Jurors, and some UI changes to align with this guidelines.
Before diving into the proposal, we need to better understand what we are trying to solve, and there are some ongoing discussions around several topics that need to be taken into consideration for a good mechanism; some are related to the Humans, some on the Curators/Challengers but in the end, it’s all about user experience on both ends.
What makes a good renewal process?
After several discussions with the community, some of the topics that need to be taken into consideration for achieving consensus on this matter are the following:
1. The human on the renewal video should be the same as the one on the registration video
It should be a no brainer that one of the most obvious things that the Curators should verify, is that the human on the renewal video is the same as the one on the registration submission. If this is not defined anywhere, it SHOULD be.
2. The phrase that should be said on the new renewal video
Achieving consensus on a single phrase should be relatively easy to define and can be further discussed.
Some suggested phrases can be seen on this HIP-32. Most of them make sense and its a matter for voting on a single one (or maybe even allow for multiple).
As a side note, not related to this post: Besides the proposals in english, there is this HIP related to using an alternate neutral language such as Esperanto
3. Enforce a verifiable and auditable Evidence on the time that the video was recorded
The video recording is currently the best evidence that a human uses to produce a valid registration and, their renewal.
This is what this post is all about and will tries to solve for.
Failure on implementing the right solution for this problem could allow for bad actors to take advantage.
One possible attack could be a case where a bad-actor records multiple videos of the same person at the same time, and then renew the registration, by using a different video every time, even if the human on the video has passed.
4. Curators/Challengers should have an easy way of verifying a renewal
The way Proof of Humanity deals with fake profiles is through “Curators” or “Challengers”. Anyone can participate on the task of curating the registry.
To do so, a Curator mines the entire registry looking for invalid profiles. Invalid meaning: The registration doesn’t follow the rules established by the DAO to be considered a legitimate registration, or includes some issues to be considered an invalid one.
For these Curators, the task is not easy, and the process of validating a profile should be as frictionless as possible.
5. Renewal process should be as similar as possible to the registration process (or easier if possible)
We’ve all been there. We’ve all put our ETH deposit to register the first time on Proof of Humanity, scared of losing our deposit.
To reduce friction,we should make the process of renewing a profile, as similar as possible to the registration, so that registrants know what to expect from the process, and how to act (since they’ve had a first experience with it).
It is not the objective of this post to expand on this, but I think some improvement can and should be done on this
The proposal
This post is not meant to be taken as an HIP (feel free to use as reference if it makes sense), but rather as an explanation on a possible mechanism that could solves 3 of the 5 definitions:
-
- Enforce a verifiable and auditable Evidence on the time the video was recorded
-
- Curators/Challengers should have an easy way of verifying a renewal
-
- Renewal process should be as similar as possible to the registration process
Cryptographic security
The underlying technology on which Proof of Humanity is built, a decentralized blockchain, has enough cryptographic mecanisms that can be securely used to generate auditable evidence.
We can take advantage of those mechanisms to play in our favor (our: us, humans).
The Validation Block
To make things short, the easiest way to do time validations with blockchain technology is by making use of the blocks’ timestamps.
Each block on the blockchain is created at a specific point in time, and that time gets registered on the blockchain.
This means that we can figure out at what time a specific block was created, just by fetching the block header (reading from the blockchain contract is gasless).
The block header contains specific structured information about each block INCLUDING the time it was created (See Block Header section on this post).
To refer to a block, we will use its ID which is a unique value representing the block on the blockchain.
I will refer to this as the “Validation Block” or “VB” 
Building a cryptographic evidence for a moment in time
We need to make sure that a vide was recorder at most at a specific moment in time, but that “moment” needs to be correctly defined.
We will call it video expiration date.
Video expiration date is calculated from the moment that the validation block was generated, plus a time window.
Consensus should be reach on what the right time window should be. This is a key item since it could impact on the security of the registry. I will refer to this as “Time Window” or “TW” 
🪟
Renewal Video
When recording a registration video, we are required to show a sign with our wallet’s address (screen or paper).
If we asked the humans to do the same video, but now, besides displaying the address, to write down and display the ID of the Validation Block, we would impact on the UX for the Human by adding an extra step.
Display the signed hash
Cryptography to the rescue once again!
Using code on the FRONT END we can ask the user to sign the ID of the Validation Block. The signature, can later be used to infer the address of the signer and the integrity of the Validation Block ID without revealing their private key.
We then calculate the hash of the signature and use that as the value to display on the sign of the recorded video (screen or paper). All of this can be easily done through code, so there is no extra interaction from the Human rather than writing/copying/printing a specific value…
The hash could have the same length as the address which would mantain the amount of effort required by the Human, as when they registered.
Metadata
The metadata for the renewal should be the same as the existing one for registration, but include 2 new fields called validation_block_id and validation_block_id_signature.
On these we will store the Validation Block ID and the signature that we can use later for validation of the data and the account.
Renewal Validation
With the updated metadata, anyone (including Curators) should have enough information to rebuild the hash of the signature and compare it to the one on the video.
Curators process
With this new implementation, Curators experience will be exactly the same as it is with registrations but in this case, the compared value will be hash of validation_block_signature, not the user address.
Curators shouldn’t care about the meaning, they should just care that the value is the same (as long as the UI is implemented to hold this mechanism).
Automated validations
*The remaining steps can AND SHOULD do the remaining validations by CODE on the FRONT END. Either to help curators or to warn submiters. *
Once the curator has done its job, we can automate the process of validating the cryptographic evidence, and finally check that the expiration date is greater than the submission date.
Since all the required data to make this validations are on the metadata, it can all be automated by code as follows:
Validate the signature from the metadata
We do this by infering the address of the signer using the validation_block_id and validation_block_signature fields. This is easily solvable by code since and address can be inferred from a signature.
If the resulting address is the same as the Human making the submission, we have crypotographic evidence that the wallet who signed the Validation Block is the same one making the submission on the video.
Since the hash on the video is valid, we can infer that the Block ID is the one used at the moment of recording the video.
If the resulting address is not the same as the submitter, the FRONT END should display a warning for challengers/curators. Not implementing this would require Curators to run the cryptographic proof manually, thus failing on the task of keeping UX the same
Time validation
Since all crypotographic evidence is validwe can now take care of looking to the time at which that block generated to make sure that the video was recorded within the expected time, from recording to submission.
We just search the block by it’s ID and make sure that the Expiration Date is greater than the Submission block date.
This also requires UI changes, or UX for Humans and Curators will be greatly impacted.
Implementation
Most of the development details described are relativelly simple to implement thanks to libraries that implement all of cryptographic work (such as ethers.js).
A Curator or anyone could easily build a prototype and run validations on their own.
There is also some work to make some changes to the UI to display the values for Curators to compare and finally, some warnings that would automatically be shown if any or none of the automatic validations pass.
Who should do the UI Changes?
However easy it can be for a tech saavy to build a system that runs validations, the app.proofofhumanity.id webpage is the FRONT END application of the project as most humans and Curators use that.
To make this mechanism viable while mantaining the UX for both Humans and Curators, it’s recommended that a developer is paid to make the required changes.
Humans should not expect that a developer will help putting together these solutions out ot love. (Although it could happen)
What needs to be done on the UI?
For the Human submission the user could use the same page of the Registration, with wording changes and a label that allows them to get the latest block ID, sign it, hash it and display the hash to the human to set up tyhe sign for the video.
It is recommended that the UI includes a counter that displays for how long the hash will be valid (or the Expiration Date).
ALso, some warning can easily be implemented to avoid Humans making mistakes. All the cryptographic evidence should be done at the moment of submission to help Humans avoid making honest mistakes
Thats all but
A possibility for using the same mechanism for registration
As an extra idea, this could be very well used on registration too:
Human farming is an issue that has been seen on the Proof of Humanity registry. Since being registered allows you to accrue $UBI (which at the time of this writing is worth about 0.2 USD), there is an economic incentive on having as much accounts as possible.
Time-constrained registration videos could be a way to reduce this kind of issues.
If a person wants to farm 100 people, it should take considerable time to use the video with the Validation Block not expiring. The Time Window parameter should be fine tuned so that its not a problem for honest registrants to submit their video with time, but at the same time make it hard for bad actors to take advantage of this time window.
By having cryptographic evidence of when a video was recorded, we can build more constraints around the protocol.
Bye Bye