Proof of Personhood

This page is still work in progress

People Parties

People parties are a mechanism for obtaining proof of personhood (also referred to as proof of humanity) built on and for the Internet Computer.

Each people party takes place at one specific point in time. Prior to that time, each prospective participant commits to a location that they will visit for the time of the party. At the beginning of the party, participants are assigned to small, random subgroups, and meet in a real-time video call with other participants assigned to the same group. The video call, however, does not show the participants’ faces; instead, participants show their surroundings, proving that they are at the place they committed to. As locations chosen by different participants must have a certain minimum distance, and no participant can be physically present at two locations simultaneously, the proof of personhood even guarantees the uniqueness of the validated persons.

The main purpose of people parties is democratization. Each validated participant can designate a neuron in the Network Nervous System that receives increased voting power; this improves the relative voting power of the “many” vs. the “heavy”. It also provides additional voting rewards to all validated participants, which further motivates people to participate in the parties. The validated personhood also benefits the Internet Computer ecosystem more broadly: Open Internet Systems, which are dapps that are controlled by a decentralized governance system, will be able to profit from the improved decentralization similarly to the Internet Computer itself. And any dapp will be able to use the validation information in order to, e.g., differentiate between bots and actual human users.

People Party Canister Interface

We describe the interface supported by the people party canister here.

get_parties: () -> (vec record { PartyId; PartySpecification; }) query;
register: (id: PartyId, place: Location) -> (RegistrationResponse);
deregister: (id: PartyId) -> (DeregistrationResponse);
withdraw: (destination: AccountIdentifier) -> (WithdrawResult);
join: (id: PartyId, key: blob) -> (JoinResponse);
vote: (id: PartyId, vote: record { Vote; ParticipantName; }) -> (VoteResponse);
http_request: (request: HttpRequest) -> (HttpResponse) query;
get_person_profile: () -> (opt PersonProfile) query;
get_call_state: (id: PartyId) -> (PublicCallState) query;
get_call_result: (id: PartyId) -> (CallResult) query;

When the users enters the people party website, the frontend calls get_parties endpoint to display the information of all the parties. The user can then then register or deregister for a party by calling register and deregister endpoints. When the user registers for a party, he specifies the the Location (latitude and longitude) of where the user will be when the party starts.

get_person_profile, get_call_state and get_call_result endpoints of people party canister to obtain information about the list of parties, a person's profile, state of a call and result of a call respectively.

Party Flow

The below flow describing a call. Say the call is scheduled to start at 10am. Then the timeline should be as follows:

• Until 9:55am, users can enroll with the register endpoint. Since the assignment to groups has not been made, calling get_call_state will return what is in case 0 below.
• At 9:55am, the canister closes the registration phase and calling the register endpoint for the current party is not allowed anymore.
• From 9:55am to 10am, users are allowed to join. For this, there is a join endpoint that accepts a key – a blob. Calling get_call_state will return the result described in case 1 below.
• At 10am, the canister generates the random setup of all calls. From this time onward, calling the join endpoint is not allowed anymore, and clients are supposed to set up the WebRTC connections.
• Between 10am and 10:01am, the canister returns the call setup state as described in step 1.5 below.
• At 10:01am, the actual calls start.
• From 10:01am to 10:11am, the actual party is supposed to take place and users can submit votes. Calling get_call_state will return the result described in case 2 below.
• At 10:11am, the canister closes all calls and makes the tally. From this point onward, calling vote is not allowed anymore.
• From 10:11am, get_call_state will return the result described in case 3 below.

Personhood Score

Each identity in the Internet Computer is assigned a personhood score. If an identity hasn’t participated in any people party, its personhood score is 0. As the identity participates in people parties and is successfully validated to be a person, its personhood score increases.

Any canister will be able to query and obtain the personhood score of an identity. One can potentially use the personhood score to determine the voting power of an identity in an election/voting program.

Requirement #1

An Internet Computer user is naturally inclined to increase his voting power. He is therefore motivated to create many identities and attend a people party with each identity. This gives him control of many identities with a positive personhood score, and thereby a higher voting power. We would like to avoid this. We would like to design the personhood score in such a way that an IC user is motivated to attend each people party with the same identity rather than creating a new identity for each people party.

Requirement #2

Suppose Alice attended many parties with her identity, and Bob attended only one recent party. Alice and Bob’s personhood scores should still be close. Alice should not have a significant advantage by attending many parties.

Failed Attempt #1

Suppose personhood score of an identity = 1 if the identity is successfully validated in at least one party. This personhood score violates our Requirement #1.

Failed Attempt #2

Suppose personhood score of an identity = number of parties in which the identity is successfully validated. This personhood score violates our Requirement #2.

Successful Attempt

After a party ends, the personhood score of an identity is composed of three components:

• Recent party result (RPR): This value is 1 if the identity is accepted to be a person in the recent party. The value is 0 if the identity did not participate or is rejected in the recent party.
• Decay function of previous personhood score: The decay function is a monotonically non-increasing function. It is computed on the old personhood score (the score before the recent party started). The decay lets us give more weightage to the validation in the recent party over the previous parties.
• Bonus reward function: If the identity is accepted in the most recent party and is successfully accepted in some parties before, a bonus reward is given to the identity. This bonus component is added to incentivize IC users to participate in all the parties using the same identity rather than creating a different identity for each party.

Suppose the personhood score of an identity is PS_old before a party starts. The trust score PS_new of the identity after the party ends is calculated as follows.

PS_new = RPR * (1 + bonus(PS_old)) + decay(PS_old)

Where Recent Party Result (RPR) is 1 iff the identity is accepted in the party.

Through empirical evidence, we found that

• bonus(x) = log₁₀(1 + 0.25 * x) and
• decay(x) = log₁₀(1 + x)

work pretty well. That is,

PS_new = RPR * (1 + log₁₀(1 + 0.25 * PS_old)) + log₁₀(1 + PS_old)

Example

Consider 2 scenarios.

• Scenario A: The user enters each party with the same identity, and the user is accepted in each of the parties.
• Scenario B: The user enters each party with a new identity, and the user is accepted in each of the parties.

Let us compare the personhood scores of the user in each of the scenarios. In Scenario B, we sum up the personhood scores of all the identities controlled by the user.

Comparison of personhood scores of a user in Scenarios A & B

	Scenario A	Scenario B
Initial Score	0	0
After 1st party	1	1
After 2nd party	1.398	1.301
After 3rd party	1.510	1.415
After 4th party	1.539	1.462
After 5th party	1.546	1.482
After 6th party	1.548	1.491
After 7th party	1.548	1.494
After 8th party	1.548	1.496