Al final se encuentra la versión en español.
- Motivation
- Secret Vote
-
Linear Delegation decay & Delegation Halving
a. Linear Delegation Decay
b. Delegation Halving
c. Exponential Delegation Decay - WIP
Motivation
Hello everyone! Following the recent discussions about delegations and votes, many ideas and proposals have come up. I’ve done some research about them because they caught my attention.
Important Disclaimer: I want to clarify first of all that I am NOT proposing any changes to the results of the last HIPS about delegations. I am NOT recommending that we make another adjustment with this matter in the short term at all. The purpose of this post is to record such discussions and evaluate the possibility of implementing them in the future. They can even be implemented by other DAOs relying on POH, it is not strictly applicable to our DAO. Please, bring ideas and contribute.
I did this research out of personal concern and to excercise some Solidity skills. Feedback is totally welcome. I am also available if there are other ideas to be investigated/tested.
Secret Vote
A short time ago, Dhadrien from sismo shared this tweet . Basically, sismo allows us to obtain a non-transferable nft on an anonymous account on the polygon network, by validating a source account registered on proof of humanity. This, in addition to a special snapshot strategy, will allow us to replicate the “secret” or “anonymous” 1h1v.
Basically we must replicate the strategy used for the Ethereum Power Users badge, which is based on the erc1155-balance-of strategy but use the TokenId referring to the PoH badge. All this on the Polygon Mainnet.
Actual Strategy for Ethereum Power Users:
{
"symbol": "Power Users ZK Badge",
"address": "0xF12494e3545D49616D9dFb78E5907E9078618a34", <- Sismo badges
"tokenId": "0x0000000000000000000000000000000000000000000000000000000000989685",
"decimals": 0
}
Strategy for Anonymous/Secret PoH voting:
{
"symbol": "Proof of Humanity ZK Badge",
"address": "0xF12494e3545D49616D9dFb78E5907E9078618a34",
"tokenId": "0x0000000000000000000000000000000000000000000000000000000000989689",
"decimals": 0
}
One important matter is about delegations. They are likely to be meaningless in an anonymous vote. On the one hand, because the delegate would have to reveal his “anonymous” address in order to be delegated. On the other hand, if we see accounts with many delegates, no matter how anonymous it is, there will be more chances to identify that it’s a member with certain influence in the dao. Of course it will never be 100% sure, but in any case it can be done at the delegate’s risk.
Cons
- Delegation issue mentioned above
- Needs that every human willing to participate makes a badge in sismo. Currently are ~100 badges claimed.
- It’s not 100% synced with the registry. If you remove your submission, the badge still works, for example.
Link to snapshot proof of concept
Linear Delegation decay & Delegation Halving
Repo: https://github.com/herniadlf/poh-delegations
From Avsa’s ideas:
A delegated vote decays exponentially over time. Say it halves every year, unless the user themselves reactivates it. This way you need to have a continuous support from your delegators and it fights apathy and inactivity. It’s something I think ENS might benefit too.
I checked first in snapshot. There is an implementation with decay over time called echelon-cached-erc1155-decay. I think it is quite possible to do something similar with our erc20 VOTE. However, such implementation does a decay for all accounts that own such erc1155. In our needs, each delegation is treated different. So, it’s complex to implement it only with a snapshot strategy (or at least I couldn’t do it).
Given that, I made an implementation of an ERC20 similar to the one we have today ($VOTE), but based on snapshot delegations contract to decrease the voting power of a delegator. In addition to this, there is the possibility of renewal, which resets the times and restores the voting power to 1. We should use the strategy erc-20-balance-of-delegator with this token. There are two different flavours:
Cons of both implementations with a contract:
- If we want this working on mainnet, along the actual registry, we must deploy a new contract. Then, every delegation renewal must pay gas costs. That costs could be a barrier for further delegations, if it increase suddenly it could be a pain.
- If we want this working on a chepear network, we must bridge the profiles using something like this. That bridging could be too expensive. Also, it could be difficult to setup the known governor that only worksalgo que también puede ser costoso. Y tenerlo en otra red dificultaría las actualizaciones vía governor que tenemos hoy en mainnet.
Linear Delegation Decay
We make the voting power of a delegate fall in a linear way.
There are two parameters we can play with: the cooldown (time during which the delegate keeps his power at 1) and the end time (which defines the gradient in which the voting power drops to 0). For example, a cooldown of 2 months and a final time of 4 months, implies that in the first 2 months the delegate will have vote 1. At 4 months, the vote will be worth 0.5. After 6 months, the vote will be worth 0.
Link to snapshot proof of concept.
Check that the result is 1.97, just a frontend issue
Delegation Halving
We apply a halving to the voting power of a delegate. In other words, for each halving period, the voting power is reduced by half.
Here we only have the parameter of the time between each halving. For example, a halving every 2 months implies that for the first 2 months the delegate has voting power 1. After 2 months, his vote becomes worth half (0.5). After 4 months, it is halved again (0.25). And so on.
1 / (2^{number_of_halvings})
Proof of concept #1: a delegated vote after a halving is worth 0.5.
Proof of concept #2: a delegated vote after a halving is worth 0.5, but if overrides it’s restored to 1.
Proof of concept #3: a delegated vote after a halving is worth 0.5, but if a delegation renewal takes place, it’s restored to 1.
Español
- Motivación
- Voto Secreto
-
Disminución lineal & Reducciones a la mitad
a. Disminución lineal
b. Reducciones por la mitad
c. Disminución exponencial - En progreso, actualizo después.
Motivación
Hola a todos! Luego de las recientes discusiones sobre delegaciones y votos, han surgido muchas ideas y propuestas. Les comparto lo que he estado investigando.
Disclaimer importante: Quiero aclarar antes que todo que NO estoy proponiendo ningún cambio a los resultados de las últimas votaciones sobre quadratic delegations ni recomiendo que realicemos otro ajuste en el short term en absoluto. El objetivo de este post es registrar dichas propuestas y evaluar la posiblidades de implementación para un futuro. Incluso, pueden ser implementadas por otras DAOs que se apoyen en POH, no es algo estrictamente aplicable a nuestra DAO. Por favor, sumen ideas!
Esta investigación la realicé por inquietud personal y para experimentar con Solidity, asi que todo feedback es bienvenido. También estoy disponible si hay otras ideas que se quieran investigar/testear.
Voto Secreto
Hace poco tiempo, Dhadrien from sismo nos compartió este tweet. Basicamente, sismo nos permite obtener un nft intransferible en una cuenta anónima en la red de polygon, a través de validar una cuenta origen registrada en proof of humanity. Esto, en conjunto de una estrategia especial en snapshot, nos permitirá replicar el 1h1v “secreto” o “anonimo”.
Basicamente debemos replicar la estrategia utilizada para el badge de Ethereum Power Users , que se basa en la estrategia erc1155-balance-of pero con el TokenId referido al badge de PoH. Todo esto en la red Polygon Mainnet.
Strategy actual para Ethereum Power Users:
{
"symbol": "Power Users ZK Badge",
"address": "0xF12494e3545D49616D9dFb78E5907E9078618a34", <- Sismo badges
"tokenId": "0x0000000000000000000000000000000000000000000000000000000000989685",
"decimals": 0
}
Strategy para PoH Anónimo/Secreto:
{
"symbol": "Proof of Humanity ZK Badge",
"address": "0xF12494e3545D49616D9dFb78E5907E9078618a34",
"tokenId": "0x0000000000000000000000000000000000000000000000000000000000989689",
"decimals": 0
}
Un punto a destacar es el de las delegaciones. Probablemente pierdan sentido en un voto anónimo. Por un lado, porque el delegado debería revelar su address “anónima” para que le deleguen. A su vez, si vemos cuentas con muchos delegados, por más anónimo que sea, habrá más posibilidades de identificar que es algún miembro con determinada influencia en la dao. Claro que nunca será 100% seguro, pero en todo caso pasa a riesgo del delegado.
Contras
- El tema de las delegaciones mencionado arriba.
- Necesita que todos los humanos que quieran participar se generen el badge anónimo en Sismo. Al momento hay ~100 badges reclamados recién.
- No está 100% sincronizado con el registro. Si das de baja tu perfil y creas otro, podés acceder a 2 badges, por ejemplo.
Link a una prueba de concepto en snapshot
Disminución lineal & Reducciones a la mitad
Repo: https://github.com/herniadlf/poh-delegations
Basado en la idea de Avsa:
A delegated vote decays exponentially over time. Say it halves every year, unless the user themselves reactivates it. This way you need to have a continuous support from your delegators and it fights apathy and inactivity. It’s something I think ENS might benefit too.
Revisé primero en snapshot. Allí existe una implementación con decay over time llamada echelon-cached-erc1155-decay. Creo que es muy posible hacer algo similar con nuestro erc20 VOTE. Sin embargo, dicha implementación hace un decay para todos las cuentas que poseen dicho erc1155. Y en nuestra idea, cada delegación es tratada de forma diferencial. Por lo tanto, no es tan sencillo de implementarlo solo con una estrategia de snapshot (o al menos yo no lo pude hacer).
Frente a eso, hice una implementación de un ERC20 similar al que tenemos hoy en día, pero que se basa en las delegaciones de snapshot para ir disminuyendo el poder de votación de un delegador. A esto se le suma la posibilidad del renewal, el cual resetea los tiempos y restaura el voting power a 1. Deberíamos usar la strategy erc-20-balance-of-delegator sobre este token. Hay dos flavours distintos:
Contras de estas implementaciones vía contrato:
- Para que viva en mainnet, donde están los registros actualmente, debemos hacer el deploy del contrato. Luego, las renovaciones tendrán costo de gas, que en mainnet puede ser costoso, siendo una barrera para la delegación.
- En caso de que viva en otra red más barata, debemos hacer algún bridge parecido a lo que se menciona en este post, algo que también puede ser costoso. Y tenerlo en otra red dificultaría las actualizaciones vía governor que tenemos hoy en mainnet.
Disminución lineal
Hacemos caer de manera lineal el poder de voto de un delegado.
Hay dos parámetros con los que podemos jugar: el cooldown (tiempo durante el cuál el delegado mantiene su poder en 1) y el tiempo final (que nos define la pendiente en la que cae el poder de voto hasta 0). Por ejemplo, un cooldown de 2 meses y un tiempo final de 4 meses, implica que en los primeros 2 meses el delegado tendrá voto 1. A los 4 meses, el votó valdrá 0.5. A los 6 meses, el voto valdrá 0.
Link a una prueba de concepto en snapshot.
Observar que el resultado es 1.97, es sólo un tema visual
Reducciones por la mitad
Aplicamos un halving al poder de voto de un delegado. En otras palabras, por cada perído de halving, el poder de voto se reduce a la mitad.
Aquí solo tenemos el parámetro del tiempo entre cada halving. Por ejemplo, un halving cada 2 meses implica que los primeros 2 meses el delegado tiene poder de voto 1. Luego de los 2 meses, su voto pasa a valer la mitad (0.5). Luego de los 4 meses, se vuelve a reducir a la mitad (0.25). Y así.
1 / (2^{cantidad_de_halvings})
Prueba de concepto #1: voto delegado luego de un halving vale la mitad.
Prueba de concepto #2: voto delegado luego de un halving vale la mitad, pero al overridear voto vuelve a valer 1.
Prueba de concepto #3: voto delegado luego de un halving vale la mitad, pero se realiza una renovación de la delegación, recuperando el voting power 1.