Este contenido se divide en tres partes:
El primero son los patrones de pensamiento comunes en el diseño de tokens.
En segundo lugar está la clasificación de tokens, que habla más específicamente sobre qué son realmente los tokens y cómo pensamos en desarrollar y mejorar sus capacidades.
Finalmente, está la teoría del árbol tecnológico, cómo utilizar la tecnología para que nuestros diseños sean más exitosos.
1. Modelo de pensamiento
Primero, los tokens están ahí para servir al protocolo, son solo una herramienta y parte del proceso de diseño, no deberían ser el objetivo. Si desea hacer algo descentralizado, un token podría ser parte de ello porque es excelente para brindarle a las personas la propiedad del protocolo y también mantenerlas alineadas.
Tres etapas del diseño
En mi trabajo con empresas de cartera, he identificado tres fases de un proceso de diseño exitoso.
Fase 1: Define tus objetivos. Un objetivo es una descripción concisa del resultado de un protocolo válido, que debe dejar claro si se ha logrado mediante el diseño específico. Así que deberíamos tener una distinción muy clara entre el éxito y el fracaso. Si no sabemos cuál es nuestro objetivo, debemos empezar desde cero y olvidarnos de los tokens. Lo ideal es que los objetivos sean mensurables, incluso si todavía no estamos seguros de cómo medir el éxito.
Fase 2: Introducción de restricciones. En términos generales, hay dos tipos de restricciones: restricciones intrínsecas y restricciones exógenas: las restricciones intrínsecas son aquellas que elegimos para simplificar el proceso de diseño porque es necesario hacer algunas concesiones o son concesiones en sí mismas. Por ejemplo, podemos elegir limitar las características interesantes que nos gustan. Las limitaciones endógenas pueden provenir de muchas fuentes, pero generalmente las determinan los propios diseñadores. Las limitaciones exógenas te las imponen la naturaleza, el estado de la tecnología, las regulaciones y todo tipo de cosas. Discutiré esto en detalle más adelante.
Fase 3: Mecanismo de diseño. Una vez que tenemos una restricción y un objetivo, podemos pensar explícitamente en el mecanismo que satisfará ese objetivo. Ahora bien, cada vez que consideramos un mecanismo, deberíamos tener realmente claro si viola estas restricciones y si nos acerca a este objetivo. Un protocolo será un conjunto de mecanismos que avanzan hacia un objetivo específico sujeto a algunas restricciones.
Errores comunes
(1) Énfasis excesivo en los tokens. Ya he hablado un poco de esto, pero si siempre estás pensando en recompensas o distribución de tokens en lugar de cómo mantener la alineación entre los participantes en tu sistema, probablemente no estés pensando en el protocolo, estás pensando en el token. Los tokens no son protocolos y los tokens no deberían ser su objetivo. Debería ser solo una herramienta.
¿Cómo salir de esta trampa? Pregúntese: ¿Cómo funcionaría este sistema sin tokens? Si el sistema falla por completo cuando se elimina completamente el token, es posible que haya exagerado la importancia del papel del token. Si fallan varias partes claves del sistema, la situación es mejor que la anterior. Su token es ciertamente importante y necesario para el equilibrio general, pero el sistema sigue siendo coherente sin él. Entonces, debes volver al objetivo del sistema y pensar en ello.
(2) No hay límite para el espacio de diseño. En diseño tienes tantas ideas, tantas posibilidades, que ni siquiera sabes por dónde empezar porque hay tantas cosas que se pueden hacer. Generalmente esto se debe a que los objetivos no están claros y es necesario perfeccionarlos. También puede deberse a que no comprendes las limitaciones que te impone el mundo exterior o a que aún no has aceptado esas limitaciones.
Si tienes en cuenta estas restricciones, descubrirás que el espacio de diseño se reduce y se vuelve mucho más claro. Dos preguntas que son útiles para delimitar su espacio de diseño son: ¿Cuál es el concepto poderoso que desea construir? Pueden ser algunas ideas profundas, algunas ventajas, algunos cambios en la tendencia de los tiempos, etc. Pregúntese: ¿cuál es este concepto poderoso? ¿Cómo puedes aprovecharlo al máximo y concentrarte en ello en lugar de pensar primero en todo el sistema? Otra pregunta es: ¿Cuál es la mayor debilidad de este diseño? ¿Qué te quita el sueño? ¿Es el punto en el que crees que podría no funcionar, el punto que te preocupa, la debilidad clave y las limitaciones que aceptarías para mejorarlo? Esto puede limitar significativamente el espacio de diseño.
(3) La comunidad siempre proporciona una red de seguridad. Cuando surgen desafíos al diseñar ciertas partes del sistema, es muy riesgoso dejarlos todos en manos de la comunidad para que los resuelva o esperar que fuerzas invisibles llenen los vacíos. Siempre esperas que la gente encuentre el problema y lo resuelva. Si bien los sistemas sin permisos son populares y permiten muchas innovaciones sorprendentes, no se puede predecir lo que hará la comunidad y no se debe esperar que solucionen los problemas más obvios de su sistema.
Hay algunas preguntas clave que deberías plantearte. ¿Qué esperamos realmente de nuestra comunidad y qué les estamos dando? ¿No nos preguntamos si les damos suficientes fichas? Más bien, preguntémonos: ¿Qué poder les hemos dado? ¿Qué habilidades les fueron otorgadas? ¿Qué derechos de propiedad tienen? ¿Se les da suficiente poder para equilibrar esta responsabilidad?
Si realmente esperas que arreglen algo, si esperas que otras personas ambiciosas agreguen algunas extensiones interesantes o arreglen algunos componentes del sistema, entonces debes preguntarte primero: ¿lo construirías aquí? Si no puedes, porque no tiene suficiente elevación, suficiente potencia o suficiente flexibilidad, entonces no esperes que otros lo hagan.
Taxonomía de tokens
Esta no es una lista completa, la he estado discutiendo con miembros del equipo y estoy seguro de que la revisaremos pronto, pero esto es solo para enumerar todas las capacidades que hemos visto demostrar al token hasta ahora.
Los tokens son una herramienta dentro de un protocolo, son una herramienta y un protocolo, y de manera más abstracta, son una estructura de datos. Entonces, ¿cómo vemos que se utiliza esta estructura de datos en diferentes protocolos? Se pueden agrupar en cinco categorías muy generales: Pagos, Votación, Partes interesadas, Metadatos y Reclamaciones. Estoy seguro de que con el tiempo habrá más soluciones para cada categoría, pero al menos a mí me parece intuitiva esta agrupación.
Pago
En primer lugar, como moneda interna de una comunidad o proyecto. Es diferente de los métodos de pago tradicionales como los dólares porque existe dentro de una comunidad específica que tiene control sobre la moneda, y pueden usar la política monetaria y otros medios en esa moneda interna, como que debería ser estable, debería estar vinculada al valor de algún otro activo específico, y tal vez la acuñan o la queman en función de objetivos específicos de toda la comunidad.
La segunda forma, y probablemente la más común y fácil de entender, de usar criptomonedas para pagos es como un recurso de red, que también incluye a Ethereum y Bitcoin. Usted paga por poder de procesamiento, almacenamiento o algún otro recurso de la red de criptomonedas. Contamos con EIP1559, staking, liquidez, etc. para determinar cómo se utilizan los tokens para calcular diferentes recursos dentro del sistema, especialmente recursos computacionales.
El tercer tipo de token de pago existe como moneda de juego similar. Por ejemplo, los juegos, los recursos o algunos recursos de protocolo deben ser estables y tener un precio. Porque si quieres utilizar el sistema y estos recursos son estables, el precio del token también debe ser relativamente estable. No importa si el suministro es estable, ya que solo lo estás usando para implementar una parte específica de tu aplicación.
Entonces, ¿dónde deberían colocarse las monedas estables? Por supuesto, una moneda estable se puede utilizar como pago en los tres métodos mencionados anteriormente. Pero lo que hace que una moneda estable sea una moneda estable es el mecanismo detrás de ella que la estabiliza, por lo que las monedas estables generalmente caen en la categoría de propiedad.
Propiedad
Generalmente hay dos tipos de propiedad: en cadena (depósito) y fuera de cadena (propiedad).
El primer tipo son los tokens de depósito en cadena (depósito) que representan la propiedad de otros tokens. Un ejemplo es el token Uniswap LP, que es un ERC 20 en V2 y un NFT en V3. La moneda estable DAI que surge del protocolo MAKER también es un depósito en cadena porque usted o los titulares de la bóveda lo usan para reclamar su garantía subyacente. Entonces, un token de depósito significa que puede usarse para reclamar otros tokens en un entorno fuera de la cadena.
El segundo tipo de token representa la propiedad de algún activo fuera de la cadena, por lo que podría ser algo así como un token de activo del mundo real, un token de bienes raíces o algo así. Un ejemplo más moderno es lo que ahora se llama canjeables, donde los tokens pueden intercambiarse por objetos físicos. Por ejemplo, un NFT se puede canjear por obras de arte, y este NFT representa la propiedad del patio. Incluso hay algunas ofertas divertidas si te animas a aprovecharlas. Puede utilizar objetos físicos para controlar NFT y controlar la propiedad de NFT posteriores a través de algunas funciones digitales como chips.
votar
La votación se puede utilizar para financiar proyectos, asignar recursos, realizar pagos o transferencias como grupo y realizar actualizaciones de software. También se puede utilizar como medida de consenso social, como por ejemplo elegir un líder para decidir sobre los planes futuros de un proyecto.
Estaca
Los tokens pueden diseñarse para tener derechos a recompensas a través de contratos inteligentes; No hay ningún acuerdo legal aquí, pero el funcionamiento del mecanismo significa que el token se beneficiará de algún tipo de actividad en cadena. Un ejemplo es DroneLink, si DroneLink funciona bien y los numerosos poseedores de tokens DRONE hacen su trabajo y el sistema funciona correctamente, entonces se beneficiarán de algunas recompensas, y así es como es el contrato inteligente, así es como está diseñado el protocolo, para recompensar a la comunidad por una buena gestión.
También puedes crear tokens como resultado de un acuerdo legal que te dé derecho a una recompensa. Puedes crear un token que represente una parte del capital de una empresa o una parte del capital, por supuesto habrá varios requisitos y restricciones legales.
Los tokens también se utilizan para suscribir riesgos a cambio de una rentabilidad. MAKER utiliza este principio. Si hay una pérdida en el protocolo MAKER, se generarán más tokens MAKER, lo que diluye el valor en poder de los titulares de MAKER. Al poseer tokens MAKER, los poseedores asumen cierto riesgo, lo cual es parte de lo que impulsa a los poseedores de MAKER a avanzar en la construcción de la comunidad. Si quieren ver crecer su valor en inversión, necesitan apoyar el sistema a medida que se desarrolla.
Metadatos
En primer lugar, los tokens representan la membresía y determinan si puedes acceder a un espacio particular, si estás en una comunidad particular o si estás en algún grupo. El protocolo o algunas herramientas escritas por terceros pueden aprovechar este atributo de membresía de cualquier forma, sin necesidad de permisos. Por ejemplo, algunas comunidades NFT pueden decidir que solo las personas que poseen tokens pueden unirse, como proporcionar funciones específicas a las personas que poseen este token. La membresía es un tipo interesante de metadatos que se proporcionan mediante tokens.
En segundo lugar, los tokens también representan credibilidad. Algunas personas debaten si el crédito debería ser transferible, pero yo personalmente creo que probablemente no debería serlo. Pero puede ser homogéneo en algunos casos y no homogéneo en otros. Si se refiere a tus logros, puede que no sea fungible; Si se refiere a la fuente de información, crédito o diferentes tipos de sistemas de puntuación crediticia, puede ser homogéneo. Estos son datos continuos, por lo que son una especie de metadatos.
Además, los tokens también representan identidades o referencias. ENS es un ejemplo de esto, los nombres ENS pueden apuntar a direcciones y pueden actualizarse, a diferencia del sistema DNS.
Los datos fuera de la cadena pueden ser un tipo de metadatos. Un ejemplo es un KYC fuera de la cadena o algún tipo de certificado verificable. Otro buen ejemplo es un diploma o título académico. Alguien te entrega este certificado y se vuelve públicamente visible, rastreable y auténtico. No hemos visto muchos casos en los que los permisos y las capacidades estén representados en cadena. Por ejemplo, alguna entidad le otorga explícitamente permisos, como la capacidad de llamar a una función, cambiar un fragmento de código o transferir algo en cadena. Incluso es posible usar tokens como interfaces, y ya hemos visto ejemplos de esto donde no solo puedes poner datos SVG en el URI del token, sino que también puedes poner páginas HTML completas e incluso puedes poner un poco de JavaScript. Puedes poner una interfaz en nft y controlar la interfaz, o puedes incrustar la interfaz en objetos que las personas poseen y transfieren.
Un ejemplo interesante es BEEP3R, donde creas un NFT con texto y luego puedes transmitir el texto a otros poseedores de BEEP3R al poseerlo. El texto se muestra sobre una pequeña imagen de BEEP3R. Cuando tienes un BEEP3R, también puedes enviar mensajes directamente a otros propietarios de BEEP3R, como si usaras solo XMTB.
Entonces, ¿cuál es la función de este token? Este es un token de membresía, y con este token puedes recibir mensajes. Cualquier interfaz de billetera que admita este estándar y pueda representar correctamente la URL de la animación podrá mostrar cualquier mensaje que reciba.
Este también es un token de identidad porque como titular de BP puedes recibir y enviar mensajes. Así que esto sólo sucede en ese conjunto. Este también es un token de identidad porque usan el ID de token de su BP para enviarle mensajes. Al mismo tiempo, también existe como una interfaz para ver información relacionada con el NFT.
3. Teoría del árbol tecnológico
Podemos ver que algunas áreas ya han logrado grandes avances, como los tokens como medio de pago y los recursos de red, mientras que algunas áreas aún no han tenido un desarrollo maduro, como las interfaces, los metadatos, etc. Entonces, ¿por qué es esto? No tengo una respuesta completa, pero creo que puede tener algo que ver con el árbol tecnológico, que por supuesto está lejos de estar completo.
Mi pregunta es, ¿por qué algunos productos aparecen durante ciertos períodos y por qué algunos productos aparecen durante más tiempo que otros? Tomando los protocolos de préstamo como ejemplo, es difícil imaginar que los protocolos de préstamo puedan funcionar sin monedas estables. Esto se debe a que cuando se toma una deuda en un protocolo de préstamo, se desea representarla con un activo estable porque se puede predecir el precio de este activo, por lo que necesitamos monedas estables antes de que podamos tener realmente un protocolo de préstamo.
De manera similar, también tenemos protocolos de préstamo que requieren AMM, porque si desea utilizar protocolos de préstamo para apalancamiento, especialmente los primeros protocolos de préstamo simples, debe poder tomar prestados activos, como monedas estables. Si desea intercambiar esa moneda estable por ese activo muy rápidamente y desea más exposición, entonces necesita un AMM. Los protocolos de préstamo no se desarrollaron hasta que tuvimos AMM y monedas estables en funcionamiento.
Pero ¿cómo conseguir un AMM y monedas estables que funcionen? Esto es difícil de hacer sin un estándar de token interoperable porque las monedas estables, los AMM y todos los sistemas que los rodean necesitan comprender cómo interactúan otros proyectos con ellos. Y para tener tokens ERC20, se necesitan contratos inteligentes totalmente programables. Es posible que en realidad no los necesites, pero así es como aparecieron por primera vez en Ethereum porque Ethereum se lanzó sin el estándar de token ERC20. Necesitamos una capacidad de programación completa para dejar un espacio de diseño suficientemente abierto, pero, por supuesto, esto se puede discutir más a fondo. Pero en conclusión, creo que hay un árbol tecnológico y ciertas tecnologías son prerrequisitos para otras tecnologías.
Aquí hay dos preguntas: ¿Cuáles son las tecnologías clave que desbloquearán futuras aplicaciones y protocolos? Es decir, ¿qué tecnologías necesitamos para desarrollar sistemas de reputación útiles o interfaces descentralizadas y sin confianza? Y la segunda pregunta es algo así como la primera pregunta pero a la inversa: ¿qué aplicaciones y protocolos se desbloquearán con la próxima tecnología?
Por ejemplo, la abstracción de cuentas, EIP 4844, los árboles verticales, el aprendizaje automático de conocimiento cero, etc. Estas preguntas son interesantes porque si podemos prever la llegada de una tecnología particular que alivia o introduce restricciones de diseño, ¿cómo cambia eso nuestros diseños? Si tecnologías específicas pueden aliviar las limitaciones, ¿deberíamos invertir esfuerzos en desarrollarlas?
Si piensas en las cosas como un árbol tecnológico, podría ayudarnos a razonar sobre lo que viene o lo que necesitas para llegar a un conjunto de límites que deseas. Así que, volviendo a mi punto original sobre las limitaciones, creo que la nueva tecnología alivia las limitaciones que enfrentábamos anteriormente. Por ejemplo, si no hubiera un estándar ERC20, entonces la limitación en cualquier diseño de AMM o moneda estable sería que necesitaría introducir un estándar o ser capaz de lidiar con una variedad de diseños diferentes.
Imagine diseñar un AMM de propósito general sin utilizar un estándar de token específico; Esto sería muy, muy difícil. Creo que esta sería una limitación casi insuperable, pero tener estándares de interoperabilidad significa que podemos soportar tokens ERC20 directamente, lo que restringe el espacio de diseño y lo hace posible.
Si podemos anticipar qué tecnologías surgirán en el futuro, ¿cómo afecta eso a las limitaciones en el diseño de nuestros protocolos? Si tenemos objetivos específicos o restricciones específicas, ¿qué tecnología necesitamos? La tecnología podrá aliviar estas limitaciones y hacer posibles nuevamente estos objetivos a través de nuevos mecanismos.