Hello Proof of Humanity community. Development for a new version of Proof of Humanity has been going on around two new big features: cross-chain compatibility and soulbound identity. With these two new features I think the new version of Proof of Humanity can be labeled as v2. In this post I’m going to give an overview of these changes. I might not be able to avoid technical details, so discussion on clarification or around these features is welcome.
Terminology
ProofOfHumanity (POH): main ProofOfHumanity contract
CrossChainProofOfHumanity (CCPOH): contract dealing with the cross-chain logic of transfering submissions / updating registration status
Primary Chain (PC): chain where the submission is registered on the POH contract. This is the chain where the submission can vouch for others on the same chain. Removals are also requested here
Cross-chain functionality
Requirements
- Unique submission primary chain
- Possibility to change primary chain
- Registration status available for multiple chains at once
- Support for multiple/different types of bridge gateways (facilitating many-to-many relationship between chains, facilitating adding chains in the future)
Added functionality
There are two possible cross-chain functions: submission updates and transfers. These can only be requested from primary chain. In order for CCPOH to mark its chain as primary, the submission must be registered on the current chain. The primary chain status for the current chain is updated on transfers and updates requests.
When requesting an update, the submission registration status is bridged to the chosen chain. This registration status is marked only in CCPOH, without interacting with the POH contract. Anyone can request a submission update for any other submission.
A submission transfer is basically a change of primary chain. The submission is manually removed from the POH contract, the relevant details (e.g. submissionID, submissionTime etc.) are bridged to the other chain and the submission is added manually to that chain’s POH. For the submission to be transferred, on the current PC it must not be in a vouching/pending state and must not have vouch in use for a submission in the pending registration phase.
In order to avoid front-running of removal request, the transfer is to be allowed at first by the submission owner, wait for a next block and then request finalizing the transfer. Bridging failures can happen. To deal with that, the transfer details are stored in CCPOH and anyone can retry the transfer. A hash of the received transfer is stored in CCPOH on the receiving chain in order to not abuse the function (if transfer hash was stored, a retried transfer would be rejected).
Special attention must be paid to profiles that failed bridging transfer. Between the failed transfer request and retrial of the failed transfer, the person can apply on any other chain. This new registration attempt should be challenged.
Soulbound identity
The new version of the Proof of Humanity contract will have soulbound functionality, bringing a new standard of one person - one unique id (rather than restricting to one address as id, different addresses being possible for the same person).
Requirements
- Unique id (QID) per human
- Functionality for anyone to recover access to their unique id
Added functionality
Thus, when a human first registers, an unique id (QID) is assigned (generated from the address). Someone can reapply with a new address to match the QID to this new address. The id must be unique per human and across chains. This requirement is secured by the arbitration process.The Submission concept/struct in the old Proof of Humanity instance is breaked into two structs:
Identity/Humanity - struct related to QID; having the relevant properties:
- owner - the address being matched to the QID
- status - None / PendingAcceptance / PendingRevokal (sort of old pending registration/removal)
- submissionTime - when someone has last claimed the QID
- requests array for claiming the QID
Submission - struct related to address; makes requests for QID; relevant props:
- contains the QID it last tried to match to
- Whether it is pending vouching for a QID (in new version the status “Vouching” is separated from the other)
- vouched for, vouched by
- Link to last request for a QID
A submission is registered when the QID of the submission corresponds to points to Identity whose owner is the submission.
Cases when someone applies to be added on the registry:
- Person was never registered
- Apply with
qid = address(otherwise must be challenged)
- Apply with
- Was registered at some point but submission was removed/expired
- Apply with
qid = last used address(otherwise must be challenged)
- Apply with
- Registered on same chain
- Restricted by contract if applying with same address
- Must be challenged if applying from different address
- Registered on different chain
- Must be challenged
- Registered person tried to transfer profile to different chain at some point but transfer failed (submission was removed on current chain and is stuck in bridge until transfer is retried)
- Must be challenged
Compatibility with old version
The new version of POH that supports adding the new functionalities to the old ProofOfHumanity submissions. Submissions on old contract won’t have to do anything as there is logic added to deal with them when required (e.g. checking submission info, removing them in case of bad voucher/transfer etc.)
This is the overview I have for now 
Some details might change in the near future. Here is the repository with the current contracts if you want to have a closer look 