[Phase 1] HIP-XX - Explicit account management

[herniadlf]

Explicit account management

HIP: XX
title: Explicit account management
author: -
status: Draft
created: 2022-08-08

---

English version below.

Resumen simplificado

Construir un side-contract a PoH que permita identificar el nivel de registro, en especial, la implementación de un nivel 2 de registro donde se declare el manejo de cuentas. Ajustar la policy para que permita la implementación del nivel de registro “2” para reglamentar el challenge de cuentas con actividad relacionada pero no declarada.

Resumen

Esta HIP tiene tres frentes:

• Smart Contract. La construcción de un nuevo contrato inteligente bajo la misma gobernanza que el actual contrato de Proof of Humanity. El mismo identificará on-chain el “nivel de un registro” de PoH, en especial, el nivel de registro “2”, donde se admita la declaración del manejo de cuentas, con un máximo de 10 cuentas manejadas en total (configurable). Una cuenta manejada, no podrá manejar otras cuentas.
• UX/UI. (Opción 1) La integración de dicho contrato con los frontend’s actuales. (Opción 2) El diseño de un pequeño frontend nuevo que facilite la UX para dichas declaraciones. (Opción 3) Sin UI.
• Legal. La adaptación de la policy para permitir el challenge de cualquier actividad sospechosa de ser un sybil que no esté declarada en el nuevo contrato. Dicha actividad puede ser: la transferencia de UBIs, la votación en simultáneo, (otros ejemplos?)

Motivacion

Actualmente, muchos humanos se registra en proof of humanity por la integración con UBI. A su vez, los humanos que conocen UBI empiezan a pensar en registrar a conocidos o familiares, con el impulso de que todos puedan recibir la emisión del token. Para conseguir eso, lo más sencillo es conocer las claves (y, por lo tanto, controlar las cuentas) de dichos allegados. Esto implica que, de alguna manera, atrás de un address no hay exactamente un sólo humano.

El objetivo de POH es tener un registro resistente a los sybils, no está creado exclusivamente para la distribución del UBI. No hay que perder de vista la necesidad de otras dapps (como Lens, Gitcoin, etc) de asegurarse de que haya un sólo humano detrás de una address, lo que en el corto/mediano plazo será cada vez más valioso en el ecosistema de ethereum.

Frente a este aparente conflicto de intereses, esta propuesta busca construir un puente. La idea es que el registro de Proof of Humanity sea transparente en cuanto a las cuentas que son manejadas y que, en segunda instancia, sea el integrador interesado en el registro el que decida si quiere admitir dichas cuentas o no, o darles otro tratamiento especial.

Adelanto de implementación

• Smart Contract: Se introduce un nuevo SC “NivelDeRegistro”, el mismo responderá el nivel de registro de una cuenta dada:
  • 0 Para cuentas que no están registradas.
  • 1 para las cuentas registradas con propio control de la cuenta. Toda cuenta registrada hasta la fecha de implementación del contrato se asumirá de nivel 1.
  • 2 para las cuentas registradas y manejadas por otro.

Esta HIP en especial, implica la creación de un segundo SC con la implementación del nivel 2. Se escribirá un mapping donde la key será la cuenta controlada y el value la cuenta controladora. A su vez, se registrará la cantidad de cuentas que controla una misma address. Se harán las validaciones de que el controlador esté registrado en poh. Al momento de realizar una declaración, se deberá escribir al contrato NivelDeRegistro indicando a qué nivel se quiere aplicar.

• En cuanto al momento de la declaración, hay dos posibilidades:

  • Realizarlo una vez registrada la cuenta.
    • Pros:
      • Simplifica onboarding.
      • Se puede declarar sólo en caso de realizarse alguna operación que vincule cuentas.
      • Podrá escribir en el contrato sólo un perfil registrado.
    • Contras:
      • En caso de perfiles controlados maliciosamente, la declaración la va a ejecutar 100% el controlador. El controlado no es consciente.
      • Cualquier challenge sería por Removal Request, y el challenger debe poner el depósito.
  • Realizarlo antes del registro
    • Pros:
      • El manejado deberá declararlo en su video.
      • Es más fácil para un challenger checkear en período de registración, sin poner depósito.
    • Contras:
      • Dificulta onboarding, agrega una tx onchain más.
      • En caso de fallar el registro, nadie limpiará el nuevo sc.

• UX/UI: Si pensamos en que la declaración se haga una vez registrada la cuenta, la UI podría ser un NTH y que la transacción se haga directamente vía etherscan. En caso contrario, lo mejor sería incluír en la pantalla de perfil de un usuario registrado algún apartado para ejecutar dicha transacción. La última opción es armar un frontend que escale para la declaración de N niveles (más costoso en tiempo).

---

English version

Simplified summary

Build a POH side-contract that helps to identify a registration level. In particular, build the implementation of a level 2 registry where a human can declare account management. Also, adjust the policy to allow the challenge of accounts with related but undeclared activity in the level 2 registry.

Abstract

This HIP has three aspects:

• Smart Contract. Building a new smart contract under the same governance as the current Proof of Humanity contract. It will identify the level of a PoH registry, in particular, a level 2 where account management declaration is supported with a maximum of 10¿? managed accounts in total (a parameter). A managed account will not be able to manage other accounts.
• UX/UI. (Option 1) The integration of such a contract with current frontend’s. (Option 2) The design of a minimal new frontend to facilitate the UX for such statements. (Option 3) No UI.
• Legal. Policy adjustment to allow the challenge of any suspected sybil activity that is not declared in the new contract. Such activity could be: the transfer of UBIs, simultaneous voting, (other examples?)

Motivation

Currently, many humans are registering in proof of humanity because of the integration with UBI. In turn, humans who know UBI start to think about registering friends or relatives, with the impulse that everyone can receive the token drippin. To achieve that, the simplest thing to do is to know the passwords (and therefore control the accounts) of those close ones. This implies that, somehow, behind an address there is not exactly a single human.

The goal of POH is to have a sybil-resistant registry. It was not created exclusively for UBI distribution. One should not lose sight of the need for other dapps (such as Lens, Gitcoin, etc) to ensure that there is only one human behind an address, which in the short/medium term will be increasingly valuable in the ethereum ecosystem.

This proposal seeks to build a bridge between this conflict of interest. The idea is that the Proof of Humanity registry would be transparent about the accounts that are managed and that, in the second instance, it would be up to the integrator interested in the registry to decide whether or not to admit such accounts, or to give them other special treatment.

Specification (idea)

• Smart Contract: A new SC “RegistrationLevel” is introduced, which will return the registration level of a given account:
  • 0 for accounts that are not registered.
  • 1 for registered accounts with total control. Any account registered up to the date of contract implementation will be assumed to be level 1.
  • 2 for accounts registered and managed by another.

This particular HIP implies the creation of a second SC with the implementation of level 2. A mapping with the “controlled account” as a key and the “controller account” as the value. At the same time, the number of accounts controlled by the same address will be recorded. Validations will be made to ensure that the controller is registered in poh. At the moment of making a declaration, you will have to write to the contract RegisterLevel indicating to which level you want to apply it.

• As for the declaration moment, there are two possibilities:

  • Declare it once the account is registered.
    • Pros:
      • Simplifies onboarding.
      • It can be declared just before of a transaction linking accounts.
      • Only a registered address will be able to write in the contract.
    • Cons:
      • In case of maliciously controlled profiles, the declaration will be executed 100% by the controller. The controlled is not aware.
      • Any challenge would be by Removal Request, and the challenger must pay the deposit.
  • Declare it before registration.
    • Pros:
      • The handler will have to declare it in his video.
      • It is easier for a challenger to check in registration period, without paying deposit.
    • Cons:
      • Makes onboarding difficult, adds one more tx onchain.
      • In case of registration failure, no one will clean the new sc.

• UX/UI: (Option 1) It would be best to include in “my profile page” a section to execute the transaction. (Option 2) Build a frontend that scales for the declaration of N levels (more time consuming) (Option 3) If we think that the declaration is made once the account is registered, the UI could be a NTH and the transaction can be made directly via etherscan

[herniadlf]

This is my first HIP. I receive any corrections on formatting or on any technical concepts I may have wrong. This is a formalization of what was discussed in: Acceptable management of family member’s PoH account. My idea is to push most of the hip myself without asking for any grant, any help is welcome (It will surely require specific help and collaboration from other members) If this is not achieved, the HIP will not move to the next phase.

[clesaege]

The idea is good (make an extra registration option for managed accounts instead of decreasing the registry security). I let @Andrei comment on the implementation side.

[green]

Instead of implementing the proposal as a separate contract, it would be cheaper development wise to implement this explicit account management in PoH v2. @Andrei

[herniadlf]

The declaration of account management is just a “second level/layer” of the registry. The first one is the registry as is. So maybe it’s good to let the door open for further levels, delegating that responsibility to this new contract. Btw, another way to see it is “keep it simple”… and just add this second level with the “main contract”. Happy to talk with @Andrei and see how to make it

[forgeron.eth]

Side contract vs monolithic in v2

I am in favour of a side contract (instead of part of v2).

• Does not delay v2
• Keeps the existing registry more focused on strong sybil-resistance.
• Encourages each integration to rely on secondary contracts that fits their security requirements, or build new secondary contracts if needed.

UBI-specific

To me the need for managed accounts is UBI-specific, as there is no other integration which would regard a managed account as sybil-resistant as far I know. Why not let UBI DAO drive this proposal instead of PoH DAO ?

[Andrei]

I agree with @forgeron.eth that strong sibyl resistance should be priority for PoHv2 contract.
Adding in v2 contract a mechanism to specify whether an account is managed or not wouldn’t be difficult at all (need to keep in mind the contract is quite big though), but that’s probably a use case very few projects integrating PoH would use.
Keeping the main contract sybil-resistant focused and having a side-contract allowing managed accounts would be a way to solve most of the issues around managed accounts and please both sides of the debate around that.

[herniadlf]

Hi everyone. I make an update with some things discussed @ ETHLatam.

How would it prevent bad actors? i.e equitable airdrop is prepared for all humans in poh. If I have access to N accounts, I am not going to declare them, so then I get what is airdropped to the accounts I manage.

This initiative has more focus on giving transparency to the good actors. As for bad actors, any suspicious act that an account is managed by another on the blockchain (voting, funds/tokens transfered to same account, etc) that is not declared in the account management, will be a candidate for a duplicate challenge. It means that the voucher will be removed as well. This has been discussed in other threads: it’s very difficult to detect beforehand that an account is managed. With my proposal we will be able to challenge the bad actors once they revealed. Nowadays, the policy doesn’t penalize any of these actions explicitly.

Shouldn’t this proposal be taken forward by UBI DAO?

I agree that part of this proposal is more appropriate for UBI DAO. However, this proposal may even help the switch between PoHV1->PoHV2 for integrators. Below I show you my idea and how far the poh dao should be taken care of, and where the ubi dao comes into play.

This is the way any interested party ask the PoH contract if an address is registered in PoH:

With the new contract (for the moment, named RegistryLevel ), we build a proxy.

This will be all for the PoH DAO. The HIP will be completed at this point. This can also be used when POHV2 is launched to switch the contract that the proxy reads:

Then, I’ll create a UIP to build the last part of this. It will certainly need:

• an update on POH policy that make explicit the management declarations
• a front-end that let the people ‘write’/‘declare’ the managements
• the smart contract (“PoH Level 2”) that stores those declarations.
  

Why not build parallel registry only for UBI instead?

It’s a fair alternative, but I’ve discarded it. I share PROS/CONS and invite you to add new ones: (cc @0xjean.eth )

• PROS
  • Separate incumbencies in all the points where the interests of the DAOS clash regarding the registry.
  • Integrators continue to use the PoH registry without having to adapt.
  • …
• CONS
  • The wheel is reinvented. The contract would be a clone with some adjustments. I’m not sure if we can use the same arbitrator, and this sounds like hip49 which was already rejected. If same arbitrator could be used as is, it might become more viable.
  • More time consuming.
  • It need a new subgraph, something that I’m not pretty sure how to build myself.
  • …

My point of view is that my proposal has the same PROs. Even thinking about PoHV2, the integrators will already have to go through a “re-direction” of the contract. My proposal would build something scalable for V3, V4, etc, without bothering the integrators to adapt, leaving the door open for other use cases that needs something like the Level 2 registry ubi needs.

[Andrei]

It’s an interesting proposal. Here are some questions I’d need clarification around:

How would you deal with duplicates around both contracts? You could challenge someone on PoHLevel2 for being duplicate of someone on PoH, but should that also happen vice-versa? If someone registered on PoHLevel2 tries to register on PoH, should she be challenged? In that case, PoHLevel2 would have to work well and be a legitimate registry.

How would you deal with vouches on PoHLevel2, if there are vouches? Should humans registered on PoH be able to vouch for those on PoHLevel2 ? In that case PoHLevel2 should be adapted for that functionality. It would also not be possible to automatically remove sybil attack vouchers without some more complicated mechanism.

If same arbitrator could be used as is, it might become more viable.

Same arbitrator can be used, with e.g. same subcourt. The hard part I see is making sure the challenger ecosystem is functional (for PoHLevel2 to be legitimate). Thus there needs to be a good incentive for the challengers to watch the registry and a policy friendly enough. Here, others from Kleros might have more expertise.

Technical wise, there are many parts, but most of it would be reused from the current version with some alterations where needed.

[herniadlf]

I probably expressed myself wrong. The idea is a bit simpler: people who want to register at level 2 would use the same registration process that exists today. That is, at contract storage level, everything would remain in the main contract.

The trick is that you additionally declare yourself as a member of the level 2 registry, which could be saved as a simple flag in the “PoH Level 2” contract. But none of that will work conceptually well if integrators continue to check isRegistered() with the main contract. When they check if a person at level two is registered, the main contract will return true. They should query the contract I call “PoH Registry Level”. That contract will take care of filtering out humans registered at level 2, or indicating that a human is at level 2. If you are at level 2, you cannot be at level 1 (the “original” and strictest) and vice versa.

Vouches or duplicates keeps working in the same way.

Thanks for your feedback!

[herniadlf]

Here some advances that may help to explain my point of view at tech-level: https://github.com/herniadlf/ProofOfHumanityRegistryLevel

[Mads]

I like the general idea, but I would change the wording/perspective a bit.

The lowest security level is the standard PoH contract. Security level 1 (not zero, sounds bad).
If you declare Security level 1, you must also declare a managing account. Possibly, we could require a video with both the person managing the account and the person of the managed account (making it harder to manage in bad faith).

If you declare a higher security level (Security level 2), you cannot declare a managing account and you open yourself up to challenges if you appear to be supported during the video (teleprompter, etc.).

I prefer phrasing in terms of increasing security levels because we are likely to require new tests in the future, that could then get a higher security level. If you introduce a new security level all accounts can choose to upgrade or not depending on the needs of the person.

[Andrei]

Saw the pros and cons and didn’t realize they were the ones of Jean’s solution so I misunderstood the proposal lol, my bad.

[herniadlf]

Thank you @Mads , it’s a good input. I’m thinking to change the “level” as a number and use some “label” instead. You’ve made me see that those numerical levels could change over time and it’s could be hard to define which is the “most” secure or not, for example.

In addition of that, I was talking with @Andrei and he let me thinking about some changes. I’ll take a few days to think all of this because I see some bad smells with the implementation that I want to erradicate. More feedback/inputs are still welcome! Thank you all

[Mads]

Yes, I think labels are a better idea now that I think about it. Labels such as “Independent” and “Managed” for instance. It would be a more flexible system going forwards.

[Mads]

@herniadlf : I think you can move to phase-2. Seems people are both supportive and out of suggestions:)

[herniadlf]

Thanks for the support Mads However, I think these days are not the most appropriate to move forward with the proposal. In case the fork happens, and with the next poh and ubi versions coming up, I think it’s best to wait. In the meantime, I will be working on the necessary smart contracts in my spare time. In case the fork doesn’t happen, I hope to have something advanced so that this hip can move to phase 2.

One relevant change: I abandoned the idea of multiple levels/labels. I found it difficult and even unperformant to scale. I take the ‘keep it simple’ path and attack the problem I was looking to solve: separate into a strict registry and an aggregate to handle more inclusive registries. This is why, above all, I don’t see it necessary if the fork were to happen.

Greetings and be well!