1. Introducción

En artículos anteriores, se describe por qué es crucial diseñar bien los incentivos al construir ecosistemas tokenizados, e introduje ideas hacia una práctica de la ingeniería de tokens. Podemos usar estas herramientas para analizar ecosistemas existentes y diseñar nuevos. Este artículo hace precisamente eso con dos estudios de caso:

1. Análisis de Bitcoin

2. Diseño de Ocean Protocol

   
   

2. Estudio de caso: Análisis de Bitcoin

Hemos hablado sobre cómo las buenas prácticas de optimización pueden aplicarse al diseño de tokens. Vamos a poner esto en práctica, enmarcando a Bitcoin bajo una perspectiva de diseño por optimización. En particular, nos enfocaremos en su función objetivo.

Función objetivo de Bitcoin: maximizar la seguridad de su red.
Define “seguridad” como poder computacional (tasa de hash), lo que hace costoso revertir cambios en el registro de transacciones. Su función de recompensa de bloque expresa este objetivo al entregar tokens (BTC) a quienes mejoran la potencia computacional de la red.

La fórmula de esta función (recompensa esperada) dice que el valor esperado de tokens que un actor i recibe está en proporción a su tasa de hash y al número de tokens entregados por bloque (actualmente 3.125 BTC cada 10 minutos, reduciéndose a la mitad cada 4 años).

Aparte: Variabilidad vs. Eficiencia

Observa que la recompensa se expresa como valor esperado, E(). Es decir, cada usuario no recibe tokens en cada intervalo. De hecho, solo un usuario gana por bloque. Pero como las probabilidades son proporcionales a su tasa de hash, el valor esperado sigue siendo justo.

¿Entonces por qué aceptar esta alta variabilidad en lugar de repartir a todos por igual?

• No necesita llevar un registro detallado de aportes de cada usuario → menor uso de cómputo y ancho de banda.

• No necesita enviar BTC a cada usuario en cada intervalo → menos transacciones, mayor eficiencia.

• El sistema se simplifica y es más seguro.

El inconveniente es que para tener una posibilidad real de ganar, necesitas un alto poder de minado. Sin embargo, los mining pools reducen esta varianza. ¡Otra lección de Satoshi! 😄

¿Funcionan los incentivos de Bitcoin?

Respuesta corta: ¡increíblemente bien!
Ha incentivado inversiones de cientos de millones en ASICs personalizados, granjas de minería, mining pools, carteras, desarrolladores, comunidades, y más. Todo impulsado por las recompensas de bloque.

Esto demuestra el poder de los incentivos correctamente diseñados.

4. Estudio de caso: Diseño de Ocean Protocol

4.1 Introducción

Cuando comenzamos a hacer un diseño serio de tokens para Ocean Protocol en mayo de 2017, nos encontramos teniendo dificultades. No habíamos formulado los objetivos (objetivos y restricciones), y en su lugar simplemente estábamos observando patrones plug-and-play como los mercados descentralizados. Pero luego nos preguntamos: ¿cómo ayuda esto a los bienes comunes de datos? No lo hacía. ¿Esto necesita su propio token? No lo necesitaba. Y había otros problemas.

Así que dimos un paso atrás y nos propusimos como objetivo redactar objetivos y restricciones apropiados. A partir de ahí, las cosas comenzaron a ir mejor. Con esos objetivos escritos, probamos otros patrones plug-and-play (solvers). Encontramos nuevos problemas que los objetivos no reflejaban, así que actualizamos los objetivos. Seguimos repitiendo ese proceso iterativo. No pasó mucho tiempo antes de que hubiéramos agotado los patrones plug-and-play existentes, por lo que tuvimos que diseñar los nuestros propios; e iteramos sobre esos.

Después de hacer esto durante un tiempo, nos dimos cuenta de que habíamos estado aplicando el enfoque de diseño por optimización al diseño de tokens. Es decir: formular el problema, intentar usar patrones existentes; y si es necesario, desarrollar los propios. Así que, aunque esta entrada del blog presenta el proceso de diseño de tokens como un hecho consumado (fait accompli), en realidad lo descubrimos mientras lo hacíamos. De hecho, hemos utilizado esta metodología para otros diseños de tokens desde entonces, para ayudar a amigos en sus proyectos.

4.2 Formulación del problema de Ocean

Recuerda que la función objetivo trata sobre lograr que las personas hagan cosas. Así que, primero debemos decidir quiénes son esas personas. Debemos definir a los posibles actores interesados o agentes del sistema. La siguiente tabla describe los actores clave para la dinámica del token de Ocean.

Función objetivo. Después de las iteraciones descritas anteriormente, llegamos a una función objetivo de: maximizar la oferta de datos y servicios de IA relevantes. Esto significa incentivar la oferta no solo de datos de alta calidad con precio, sino también de datos comunes (gratuitos) de alta calidad; y de servicios de cómputo relacionados (por ejemplo, para privacidad).

Restricciones. En las iteraciones descritas anteriormente, utilizamos esta lista de verificación al considerar distintos diseños. De manera general, podemos pensar en estos elementos como restricciones:

• Para los datos con precio, ¿existe un incentivo para proveer más? ¿Para referir? ¿Buena prevención de spam?

• Para los datos comunes (gratuitos), ¿existe un incentivo para proveer más? ¿Para referir? ¿Buena prevención de spam?

• ¿El token proporciona un mayor valor marginal a los usuarios de la red frente a los inversionistas externos?

• <y más>

Además de estas preguntas, a medida que consultábamos continuamente a otros sobre posibles ataques, añadíamos cada nueva preocupación a la lista de restricciones a resolver (incluyendo un nombre memorable), y actualizábamos el diseño para abordarlas. Nuevas restricciones incluyeron: “Fugas de Datos”, “Clones de Curación”, “Ataque de Elsa y Anna”, y más. La sección de Preguntas Frecuentes del whitepaper de Ocean documenta estos casos y cómo los abordamos.

4.3 Explorando el espacio de diseño

Probamos una variedad de diseños que combinaban patrones de tokens de distintas formas, y evaluamos cada diseño (mediante experimentos mentales) frente a las restricciones enumeradas anteriormente. Algunos de los que probamos fueron:

• Solo un TCR (registro curado por tokens) para actores (como adChain). Fallo: no puede manejar datos de spam.

• Solo un TCR para datos/servicios. Fallo: no puede manejar Fugas de Datos.

• Un TCR para actores y un TCR para datos/servicios. Fallo: no puede distinguir entre datos/servicios que no son spam y los que realmente son relevantes.

• Un TCR para actores y un Mercado de Curación (CM) para datos/servicios. Fallo: no hay incentivos para hacer disponibles los datos/servicios.

Así fue como se desempeñó cada diseño candidato frente a la lista de verificación. Cada uno tuvo al menos una falla importante.

Tuvimos que recurrir al paso 3 de la metodología: diseñar nuestro propio bloque funcional. Lo que surgió fue un Mercado de Pruebas Curadas (CPM, por sus siglas en inglés; más detalles en la siguiente sección), una extensión lo más pequeña posible de un Mercado de Curación (CM). Lo probamos en dos nuevas opciones de diseño:

5. Registro de datos + CPM de datos gratuitos. Curación: apostar tokens como expresión de confianza en la reputación. CDN automática.

6. Registro de actores + CPM de datos gratuitos y con precio. Curación: apostar tokens como expresión de confianza en la reputación. CDN automática. “Mercado de Curación con Pruebas”.

La siguiente tabla añade estos dos nuevos diseños en las columnas más a la derecha. ¡Vemos que el diseño 6 cumplió con nuestros objetivos! Esto es fundamental: significa que sabíamos que podíamos detener el proceso de diseño actual (al menos por el momento).

4.4 Un nuevo patrón de token para Ocean: Mercados de Pruebas Curadas

La función objetivo de Ocean es maximizar la oferta de datos y servicios de IA relevantes.

Para manifestar esto, debemos reconocer que no podemos medir objetivamente qué es “alta calidad”. Para resolver este problema, Ocean deja la curación en manos de la comunidad: los usuarios deben “apostar con su dinero” a lo que creen que serán los conjuntos de datos más populares, utilizando un entorno de Mercado de Curación.

Luego necesitábamos reconciliar las señales de calidad con la disponibilidad de los datos. Resolvimos eso vinculando ambos elementos: popularidad predicha versus popularidad comprobada. Un usuario recibe tokens si se cumplen ambas condiciones:

• Ha predicho la popularidad de un conjunto de datos en un entorno de Mercado de Curación. Esto es la Popularidad Predicha.

• Ha demostrado que ha hecho disponible el conjunto de datos o servicio cuando fue solicitado. Por definición, cuanto más popular sea, más solicitudes habrá. Esto es la Popularidad Comprobada.

Juntas, estas condiciones forman lo que llamamos un Mercado de Pruebas Curadas (CPM). En un CPM, el mercado de curación y la prueba están estrechamente vinculados: la prueba le da fuerza a la curación, haciéndola más orientada a la acción; a su vez, la curación proporciona señales de calidad para la prueba. Los CPM son una nueva incorporación a nuestra lista creciente de bloques funcionales para el diseño de tokens. 🙂

La siguiente ecuación describe la función de recompensas en tokens de Ocean.

El primer término en el lado derecho, Sij​, refleja la creencia de un actor en la popularidad del conjunto de datos o servicio (Popularidad Predicha). El segundo término, Dj​, refleja la popularidad del conjunto de datos o servicio (Popularidad Comprobada). El tercer término, T, es la cantidad de tokens distribuidos durante ese intervalo. El cuarto término, Ri​, sirve para mitigar un vector de ataque en particular. La función de recompensa esperada E() se implementa de manera similar a la de Bitcoin. El whitepaper de Ocean detalla cómo funciona esta función de recompensa.

[Actualización – septiembre de 2021:] El diseño del token descrito en esta sección es diferente al que finalmente se implementó, debido a los aprendizajes adquiridos en el camino. Sin embargo, los objetivos siguen siendo los mismos, y aún hay ecos de este diseño en Ocean Data Farming.

5. Conclusión

Este artículo presentó estudios de caso sobre el uso de herramientas de ingeniería de tokens para analizar Bitcoin y para diseñar Ocean Protocol.

Fuente: Trent McConaghy https://blog.oceanprotocol.com/token-engineering-case-studies-b44267e68f4