Título original: 7 controles de cordura antes de diseñar un token
Autor: Guy Wuollet
Compilado por: Katie Gu, Odaily Planet Daily
Los tokens son una nueva y poderosa primitiva que se puede definir de muchas maneras. El espacio de diseño de tokens es rico, pero todavía estamos en las primeras etapas de exploración.
En realidad, muchos equipos luchan por encontrar el diseño de token "correcto" para sus proyectos. Sin embargo, la industria carece de un marco de diseño probado, por lo que las generaciones posteriores se enfrentan repetidamente a los mismos desafíos que sus predecesoras. Afortunadamente, existen (algunos) ejemplos tempranos de diseño de tokens exitoso. Los modelos de tokens más efectivos tienen elementos exclusivos para sus objetivos, pero la mayoría de los diseños de tokens defectuosos comparten algunos errores comunes. Por lo tanto, este artículo discutirá por qué deberíamos considerar la investigación y el diseño de tokens en lugar de simplemente la “economía de tokens” y enumerará siete consejos para evitar trampas.
#1 Aclarar los objetivos del diseño de tokens
El mayor problema en el diseño de tokens es cómo construir un modelo de token complejo antes de que el objetivo sea claro. El primer paso debe ser identificar el objetivo y asegurarse de que todo el equipo lo comprenda completamente: ¿qué es, por qué es importante y qué es lo que realmente desea lograr? No definir rigurosamente los objetivos a menudo da como resultado un rediseño y una pérdida de tiempo. Tener objetivos claros también ayuda a evitar el problema de “crear una economía simbólica con el fin de diseñar una economía simbólica”, que es un fenómeno común en algunos diseños económicos simbólicos.
Además, el objetivo debe estar en torno al token en sí, pero esto a menudo se pasa por alto. Ejemplos de objetivos claros incluyen:
Diseñe un juego con un modelo de token que permita una escalabilidad óptima y un modelado de soporte.
Un protocolo DeFi espera diseñar un modelo de token que distribuya razonablemente el riesgo entre los participantes.
Diseñar un protocolo de reputación que garantice que el dinero no puede reemplazar directamente la reputación (por ejemplo, desvinculando la liquidez de las señales de reputación).
Diseñe una red de almacenamiento que garantice que los archivos estén disponibles con baja latencia.
Diseñar una red de stake que proporcione la máxima seguridad económica.
Diseñar un mecanismo de gobernanza que genere verdaderas preferencias de los usuarios o maximice la participación.
La lista continua. Deje que el token admita cualquier caso de uso y logre cualquier objetivo, en lugar de lo contrario.
Entonces, ¿cómo se empieza a definir un objetivo claro? Los objetivos bien definidos suelen surgir de la "misión del proyecto". Si bien la "misión del proyecto" tiende a ser abstracta y de alto nivel, las metas deben ser específicas y reducidas a su forma más básica.
Tomemos como ejemplo EIP-1559. Roughgarden estableció un objetivo claro para EIP-1559: "EIP-1559 debería mejorar la experiencia del usuario a través de una simple estimación de costos en forma de una 'mejor oferta clara' fuera de los períodos de rápido crecimiento de la demanda".
Continuó proponiendo otro objetivo claro: “¿Podemos rediseñar el mecanismo de tarifas de transacción de Ethereum para que la fijación de los precios del gas de transacción sea más ‘sedosa’, como comprar en Amazon? Idealmente, un mecanismo de publicación de precios, lo que significa un mecanismo para que cada usuario acepte o dé? subir el precio de la gasolina".
Lo que ambos ejemplos tienen en común es que usted establece un objetivo de alto nivel, proporciona una analogía relevante para ayudar a otros a comprender su objetivo y luego describe una solución de diseño que mejor respalde ese objetivo.
#2 Evaluar el trabajo existente basándose en principios fundamentales
Al crear algo nuevo, es una buena idea comenzar con algo que ya existe. Cuando se evalúan los protocolos existentes y la literatura existente, se deben evaluar objetivamente en función de sus méritos técnicos.
Los modelos de tokens a menudo se evalúan en función del precio del token o de la popularidad del proyecto asociado. Es posible que estos factores no estén relacionados con la capacidad del modelo Token para lograr los objetivos declarados. La valoración, la popularidad u otras formas simplistas de evaluar un modelo simbólico pueden llevar a que los constructores tomen "desvíos". Si asume que otros modelos de token funcionan correctamente cuando en realidad no es así, puede crear un modelo de token "intrínsecamente defectuoso".
#3 Aclara tus suposiciones
Deje claras sus suposiciones. Cuando te concentras en construir una moneda, es fácil dar por sentados los supuestos básicos. También es fácil tergiversar las suposiciones que realmente estás haciendo.
Tomemos, por ejemplo, un nuevo protocolo que supone que su cuello de botella de hardware es la velocidad de cálculo. Hacer que esta suposición forme parte del modelo de token (por ejemplo, limitando el costo del hardware necesario para participar en el protocolo) puede ayudar a alinear el diseño con el comportamiento deseado.
Sin embargo, si los diseñadores de protocolos y tokens no expresan claramente sus suposiciones, o las suposiciones que expresan son incorrectas. Los participantes que son conscientes de este desajuste tienen el potencial de extraer valor del protocolo. Los piratas informáticos suelen ser personas que comprenden un sistema mejor que las personas que lo construyeron originalmente.
Aclarar sus suposiciones facilita que las personas comprendan el diseño de su token y se aseguren de que funcione correctamente. Si no deja clara su hipótesis, no podrá probarla.
#4 Pon a prueba tus suposiciones
Hay un dicho: "No es lo que no sabes lo que te mete en problemas, sino lo que estás convencido de que no".
Los modelos de tokens suelen hacer una serie de suposiciones. Este enfoque proviene en parte del diseño de sistemas bizantinos, que fue la inspiración para blockchain. El sistema hace una suposición y construye una función que, si la suposición es cierta, garantiza una determinada producción. Por ejemplo, Bitcoin garantiza la actividad en un modelo de red síncrono, garantizando la coherencia si el 51% del poder hash en la red es honesto. Varias cadenas de bloques más pequeñas han sufrido ataques del 51%, violando la cantidad de suposiciones de honestidad requeridas por el consenso de Satoshi para que las cadenas de bloques funcionen correctamente.
Los diseñadores de tokens pueden verificar sus suposiciones de diversas formas. La elaboración de modelos estadísticos rigurosos, a menudo en forma de modelos basados en agentes, puede ayudar a probar estas hipótesis. Las hipótesis sobre el comportamiento de los usuarios a menudo también pueden verificarse hablando con los usuarios y, mejor aún, observando lo que la gente realmente hace (en lugar de decir lo que hacen). La probabilidad de una validación exitosa es mayor, especialmente con redes de prueba incentivadas que producen resultados empíricos en un entorno de pruebas. La validación formal o la auditoría intensiva también ayudarán a garantizar que el código base funcione como se esperaba.
#5 Identificar “barreras abstractas”
Una "barrera de abstracción" es la interfaz entre diferentes capas de un sistema o protocolo. Se utiliza para separar los diferentes componentes de un sistema, permitiendo diseñar, implementar y modificar cada componente de forma independiente. Las barreras de abstracción claras son útiles en todas las áreas de la ingeniería, especialmente en el diseño de software, pero son aún más necesarias para el desarrollo descentralizado y los equipos grandes que construyen sistemas complejos que los individuos no pueden entender.
En el diseño de tokens, el objetivo de eliminar las barreras de abstracción es minimizar la complejidad. Reducir las dependencias (internas) entre los diferentes componentes de un modelo de token puede generar un código más limpio, menos errores y mejores diseños de tokens.
Por ejemplo, muchas cadenas de bloques son construidas por grandes equipos de ingeniería. Un equipo podría hacer suposiciones sobre los costos del hardware a lo largo del tiempo y usarlas para determinar cuántos mineros contribuyen con hardware a la cadena de bloques a un precio simbólico determinado. Si otro equipo se basa en el precio del token como parámetro pero no conoce las suposiciones del primer equipo sobre los costos de hardware, fácilmente puede hacer suposiciones contradictorias.
En la capa de aplicación, las barreras de abstracción claras son fundamentales para lograr la componibilidad. A medida que se combinen más protocolos entre sí, la capacidad de adaptar, construir, ampliar y remezclar será cada vez más importante. Las composiciones más grandes aportan mayores posibilidades, pero también mayor complejidad. Cuando las aplicaciones quieren componer, deben comprender los detalles del protocolo de composición que utilizan.
Las suposiciones e interfaces opacas en ocasiones pueden provocar errores oscuros, especialmente en los primeros protocolos DeFi. Las barreras de abstracción difusa también aumentan la eficiencia de la comunicación requerida entre equipos que trabajan en diferentes componentes del protocolo, extendiendo así el tiempo de desarrollo. Las vagas barreras de abstracción también aumentan la complejidad del protocolo, lo que dificulta la comprensión completa de su mecánica.
Al crear barreras abstractas claras, los diseñadores de tokens pueden predecir más fácilmente cómo los cambios específicos afectarán a cada parte del diseño del token. Las barreras de abstracción claras también facilitan la extensión de un token o protocolo y crean una comunidad Builder más inclusiva y escalable.
#6 Reducir la dependencia de parámetros externos
Los parámetros externos no son inherentes al sistema, pero pueden afectar el rendimiento y el éxito general, como el coste de los recursos informáticos, el volumen de transacciones o la latencia en las primeras etapas de la creación del modelo de token.
Pero cuando un modelo de token solo funciona cuando los parámetros se mantienen dentro de un rango limitado, puede ocurrir un comportamiento inesperado. Por ejemplo, un protocolo que vende servicios y ofrece reembolsos en forma de una recompensa simbólica fija puede valer más que el costo del servicio si el precio del token es inesperadamente alto. En este caso, es bastante rentable comprar servicios ilimitados del protocolo, lo que aprovechará al máximo las recompensas y servicios simbólicos.
O, para poner otro ejemplo, las redes descentralizadas a menudo dependen de algoritmos criptográficos o acertijos computacionales que son difíciles, pero no imposibles, de resolver. La dificultad suele depender de una variable exógena, como la rapidez con la que una computadora puede calcular una función hash o una prueba de conocimiento cero. Por ejemplo, existe un protocolo que asume qué tan rápido se puede calcular una función hash determinada y paga recompensas simbólicas en consecuencia. Si alguien inventa una nueva forma de calcular una función hash más rápido, o simplemente tiene recursos enormes para resolver el problema desproporcionados con su trabajo real en el sistema, puede ser recompensado con tokens inesperadamente enormes.
#7 Revalidar supuestos
Diseñar un token debería ser como diseñar un sistema adversario. El comportamiento del usuario cambiará a medida que cambie la forma en que funciona el token.
Un error común es ajustar el modelo de token sin garantizar que el comportamiento arbitrario del usuario siga produciendo resultados aceptables. No asuma que el comportamiento del usuario seguirá siendo el mismo debido a cambios en el modelo de token. Por lo general, este tipo de error ocurre al final del proceso de diseño, cuando alguien ha dedicado mucho tiempo a definir el objetivo del token, definir su funcionalidad y validarlo para asegurarse de que funcione como se esperaba. Luego identificaron un caso especial y cambiaron el diseño del token para adaptarlo, pero olvidaron revalidar todo el modelo del token. Al solucionar un caso especial, crean otro (o varios más) consecuencias no deseadas.
Recuerde no desperdiciar su arduo trabajo; cada vez que un proyecto cambie su modelo de token, vuelva a verificar que esté funcionando como se esperaba.