Hacia una práctica de ingeniería de tokens

septiembre 18, 2022

Metodología, Patrones y Herramientas. Serie TE Parte II.

1. Introducción

En mi artículo anterior , describí por qué necesitamos obtener incentivos correctos cuando construimos ecosistemas tokenizados. Aquí, pregunto: ¿cómo diseñamos incentivos para estos ecosistemas tokenizados? Y en realidad, dado que los incentivos son el corazón de los ecosistemas tokenizados, es realmente: ¿cómo diseñamos ecosistemas tokenizados? y, ¿cómo los analizamos y verificamos ?

Este artículo es una primera apuesta en el terreno hacia una práctica de ingeniería de tokens : la teoría, la práctica y las herramientas para analizar, diseñar y verificar ecosistemas tokenizados.

La primera sección de este artículo relaciona los diseños de tokens con otros campos y explica por qué “ingeniería”. El resto de este artículo es un intento de acercarnos a este objetivo, aprovechando los campos existentes de tres maneras principales:

  • Podemos enmarcar el diseño del token como diseño de optimización y luego usar la metodología de diseño de optimización.
  • Inspirándonos en los patrones de ingeniería de software , podemos documentar patrones emergentes para el diseño de tokens.
  • La simulación, la verificación y la exploración del espacio de diseño (herramientas CAD) para el diseño de circuitos han ayudado a los ingenieros a analizar, diseñar y verificar chips increíblemente complejos. Podemos esperar herramientas similares para ecosistemas tokenizados.

2. Ingeniería, teoría de juegos y más

Esta sección relaciona el diseño del token con otros campos.

2.1 El puente de Tacoma Narrows

En la primera semana de mis estudios de ingeniería, nuestro profesor de rostro solemne nos mostró esto:

https://www.youtube.com/watch?v=j-zczJXSxnw

¿Cómo se derrumbó el puente? Después de todo , los diseñadores anticiparon el viento. Sin embargo, no pudieron anticipar que los patrones de viento particulares establecerían una resonancia con el puente mismo. Cuando se aplica una fuerza en el momento adecuado a un sistema en resonancia, la amplitud de la resonancia crece con el tiempo. La siguiente figura ilustra, donde verde = no resonante y rojo = resonante = desastre.

El video fue para enseñar acerca de la responsabilidad . Los diseñadores del puente podrían haber evitado el desastre siendo minuciosos y aplicando la teoría, la práctica y las herramientas apropiadas. Otros profesores mostraron ese video varias veces a lo largo de mis estudios. Esas visitas culminaron en una ceremonia para recibir anillos de hierro al graduarse. Todos los ingenieros canadienses tienen estos anillos. Según la leyenda, los anillos están forjados con el metal de un puente derrumbado.

2.2 Teoría de juegos y diseño de mecanismos

La Teoría de Juegos es un campo científico que analiza los incentivos, desde un punto de vista económico. Tiene una contraparte en economía para diseñar (sintetizar) sistemas incentivados, llamado Diseño de Mecanismos . De hecho, Mechanism Design es realmente el campo para el diseño de ecosistemas tokenizados, en teoría. Los investigadores en ese campo han desarrollado una gran cantidad de grandes teorías a lo largo de los años, literalmente a niveles de calidad de premios Nobel. Estrechamente relacionada está la Teoría de Juegos Económicos .

Sin embargo, tradicionalmente no ha habido una buena manera de conciliar esa teoría con la práctica . Después de todo, ¿con qué frecuencia un economista académico (o cualquiera, en realidad) tiene la oportunidad de implementar una economía? Sin embargo, este es exactamente el problema al que nos enfrentamos al diseñar ecosistemas tokenizados. Los más cercanos probablemente sean las economías de los videojuegos y el diseño de políticas públicas .

Sin embargo, resulta que si te acercas al diseño de mecanismos con algunas restricciones prácticas , ¡terminas con el diseño de optimización! Las personas que realizan el diseño de optimización tienen una enorme cantidad de experiencia práctica en la implementación de sistemas de optimización a lo largo de los años. Incluido yo mismo: mi primera y segunda startups ( ADA , Solido ) hicieron exactamente eso, para su uso en el diseño de circuitos de grado industrial.

2.3 Otros campos relacionados

Muchos otros campos también tienen algo que decir sobre el diseño de tokens; al menos en el sentido de que los expertos de esos campos encontrarán que muchas de sus habilidades se traducen bien en el diseño de tokens. Estos incluyen todo, desde ingeniería eléctrica hasta sistemas complejos, desde economía hasta IA. Enumero algunos a continuación. Y, por supuesto, muchos de ellos tienen raíces en la buena cibernética .

2.4 Ingeniería y diseño de tokens

¿Cómo deberíamos llamar a este campo en el que diseñamos ecosistemas tokenizados? A continuación enumero algunas opciones.

Los primeros cuatro términos tienen un sesgo económico . Está bien; tiene sentido para analizar el movimiento de precios, valoraciones, etc.

Estoy formado como ingeniero eléctrico (EE). Los EE que diseñan circuitos tienen teoría, tienen práctica y construyen sistemas que simplemente funcionan , como la pantalla que está leyendo y los chips que la alimentan, hasta las luces sobre su cabeza.

La ingeniería se trata de análisis , diseño y verificación rigurosos de sistemas; todo asistido por herramientas que concilian la teoría con la práctica. La ingeniería también es una disciplina de responsabilidad : ser responsable ética y profesionalmente de las máquinas que construye, como lo ilustran las vistas del puente Tacoma Narrows y los anillos de hierro.

Vi el surgimiento de la disciplina de la ingeniería de software en los años 90; eso tenía sentido porque fomentaba el rigor y la responsabilidad.

Me encantaría ver que el diseño de ecosistemas simbólicos se convierta en una disciplina de ingeniería, junto con la ingeniería eléctrica, la ingeniería de software, la ingeniería civil, la ingeniería aeroespacial, etc. Esto implica que el diseño del ecosistema de tokens también se convertiría en un campo de análisis, diseño y verificación rigurosos. Contaría con herramientas que conciliaran la teoría con la práctica. Se guiaría por un sentido de responsabilidad. Podría ser ingeniería de tokens (fichas).

[Nota: En cuanto a “token” vs “incentivo”, “token” es más corto y más fácil de comparar con su contraparte económica “Tokenomics”.]

La siguiente imagen muestra cómo se relacionan estos campos. El objetivo es una práctica de ingeniería de fichas.

3. Diseño de tokens como diseño de optimización

El diseño de tokens es como el diseño de optimización: en un nivel alto, codifica la intención con una función de recompensas en bloque, también conocida como función objetivo, y la deja volar. Como suele ser el caso, Simon de la Rouviere vio este primero .

Se vuelve más específico que eso. El diseño de tokens es especialmente similar a los algoritmos evolutivos (EA), donde hay muchos agentes que “buscan” a la vez y no hay un control de arriba hacia abajo de lo que hace cada agente. Los agentes viven y mueren por su recompensa de bloque o aptitud. La siguiente tabla resume la relación.

Con tales similitudes, podemos usar las mejores prácticas desde la optimización/EA hasta el diseño de tokens . Esta es una gran noticia, porque muchas personas son Jedis en el diseño de EA y sistemas de optimización.

Vamos a elaborar cada fila de la tabla.

3.1 Metas

Tanto los ecosistemas tokenizados como los EA tienen metas , en forma de objetivos (cosas para maximizar o minimizar) y restricciones (cosas que se deben cumplir). Para ponerse elegante, esto puede ser incluso estocástico.

El ecosistema tokenizado podría otorgar recompensas en bloque por una función objetiva de “maximizar la tasa de hash”, mientras que un objetivo de EA podría ser “minimizar el error” al entrenar una red profunda. Las restricciones pueden ser “debe tener participación ≥ umbral para participar” o “capas de red profundas = 100”, respectivamente.

Las variantes incluyen optimización de un solo objetivo (1 objetivo, 0 restricciones), satisfacción de restricciones (0 objetivos, ≥1 restricciones) y optimización restringida multiobjetivo (≥2 objetivos, ≥1 restricciones).

3.2 Medición y prueba

Para probar/medir el éxito frente a las metas (objetivos y restricciones), un ecosistema tokenizado se basa en pruebas y un optimizador mide la aptitud utilizando, por ejemplo, un simulador .

Por ejemplo, un nodo de Bitcoin prueba que un usuario estaba aplicando hash al verificar que el nonce proporcionado por el usuario resuelve el rompecabezas criptográfico.

Un optimizador podría probar la bondad de un circuito ejecutando una simulación SPICE de las ecuaciones diferenciales del circuito; los resultados de la simulación se pueden verificar probando si realmente resolvieron las leyes de voltaje y corriente de Kirchoff.

3.3 Agentes del Sistema

En ambos sistemas, los agentes se dedican a “hacer cosas”.

En un ecosistema tokenizado, las partes interesadas de la red , como los mineros ( o los usuarios en general) hacen lo que sea necesario para ganar recompensas en bloque. Se empujan, haciendo lo que sea necesario para obtener más recompensas simbólicas. Por ejemplo, en Bitcoin, algunos agentes pueden diseñar, construir y ejecutar chips ASIC para obtener una tasa de hash más alta. Otros agentes pueden agrupar sus recursos informáticos existentes. El sistema no necesita modelar explícitamente a todas las partes interesadas en el ecosistema. Por ejemplo, Bitcoin no tiene roles específicos para bancos, naciones o empresas; es sobre todo todo acerca de los mineros.

En un EA, tiene individuos en una población. Si son “buenos”, tienen una mejor condición física. Por ejemplo, un individuo puede ser un vector de 10.000 pesos para una red neuronal. Las “acciones” de los individuos son básicamente cuando sobreviven y tienen variantes hechas de ellas, a través de operadores como cruce (por ejemplo, interpolación) o mutación (por ejemplo, perturbando aleatoriamente cada parámetro).

3.4 Reloj del sistema

Cada sistema tiene un reloj , lo que implica una dimensión de tiempo mediante la cual se avanza /se produce la convergencia. 

 Lotes. Normalmente, los agentes se procesan en lotes o épocas. Un ecosistema tokenizado genera periódicamente un nuevo bloque y otorga recompensas de bloque. El bloque nuevo apunta al bloque antiguo; y el nuevo trabajo en el sistema se agregará al nuevo bloque; y así. Esta lista enlazada de bloques implica un reloj lógico al estilo de Lamport. En los EA, cada lote es una generación en la que una población completa de individuos se actualiza a la vez. Cada bucle generacional puede incluir: evaluar a los individuos, seleccionar a los mejores, dejar que tengan hijos, repetir.

Continuo. En algunos sistemas, los agentes se procesan de forma más continua que por lotes. Estos sistemas generalmente requieren un poco más de trabajo para conceptualizarlos, pero pueden conducir a mejores propiedades para algunos problemas. Por ejemplo, en ecosistemas tokenizados, una transacción de Stellar solo necesita la validación de los participantes del segmento de quórum, o se agrega otro nodo a un DAG (gráfico acíclico dirigido) como en Iota. En EA, tenemos una evolución de estado estacionario donde se reemplaza un individuo a la vez.

3.5 Incentivos y Desincentivos

El sistema en sí no puede controlar cómo se comportan los agentes. (O al menos, no debería necesitar controlarlos). Como tal, el comportamiento de alto nivel debe ser una propiedad emergente de las acciones de abajo hacia arriba por parte de los agentes . Esto es necesario para los ecosistemas tokenizados; de lo contrario, ¡estarían centralizados! No es una necesidad absoluta para los EA, pero, sin embargo, un amplio conjunto de EA adopta este enfoque por simplicidad/elegancia o para cumplir otros objetivos de diseño.

Esto significa que el sistema solo puede recompensar o castigar el comportamiento, es decir, palos o zanahorias, incentivos y desincentivos . Al diseñar el sistema, diseñamos qué recompensas o castigos dar, y cómo darlos.

En los ecosistemas tokenizados, las recompensas toman la forma de recompensas en bloque y los castigos mediante la reducción de la apuesta. La primera suele ser la función objetivo; el último es algunas (pero no todas) restricciones.

En los EA, la recompensa y el castigo se reducen a qué individuos son seleccionados para ser padres de la próxima generación. Ejemplos: elegir al azar dos individuos y quedarse con el mejor, repitiendo hasta completar (selección de torneo); y la posibilidad de selección es proporcional a la aptitud (selección de la rueda de la ruleta). Fundamentalmente, el EA no necesita guiar a las personas, por ejemplo, proporcionando un derivado. Esta es la razón por la que un ecosistema tokenizado se parece más a un EA, en comparación con los optimizadores basados ​​en gradientes que dan directivas de arriba hacia abajo (usando gradientes para elegir nuevos individuos).

4. De la Metodología de Optimización a la Metodología de Token

4.1 Introducción

Esta sección son algunas notas iniciales para tratar el diseño de tokens como la disciplina de ingeniería en la que merece crecer.

Primero, describo una metodología estructurada para el diseño de optimización. Luego describo cómo se podría aplicar una metodología similar para el diseño de incentivos.

A continuación, describo las herramientas clave utilizadas en el diseño de circuitos: simuladores, herramientas de verificación y herramientas de exploración del espacio de diseño; y cómo podrían aplicarse para el diseño de circuitos.

Finalmente, empiezo a enumerar algunos patrones de diseño.

4.2 Metodología de optimización

Estas comunidades solo hablan parcialmente entre sí. Pero todos los practicantes de los algoritmos hacen algo muy similar. Quieren enviar sistemas de optimización que simplemente funcionen . Siguen los siguientes pasos. Algunos lo hacen implícitamente, aunque los profesionales lo hacen sistemáticamente:

  1. Formular el problema: asumen que el algoritmo “simplemente funciona” y se enfocan en formular el problema en términos de objetivos y restricciones (meta) y espacio de diseño (dónde puede explorar el optimizador, que en realidad son solo restricciones).
  2. Probar  un solucionador existente: luego ejecutan el algoritmo contra esos objetivos y lo dejan “resolver”. El código para los algoritmos de optimización a menudo se denomina simplemente ” solucionadores “. Si esto no funciona, los profesionales iterarán probando diferentes formulaciones de problemas o diferentes solucionadores y parámetros de solucionador.
  3. ¿Nuevo solucionador? Si el paso de resolución anterior no funciona, incluso después de varios intentos con varias formulaciones, entonces los profesionales consideran implementar su propio solucionador, es decir, diseñar un nuevo algoritmo de optimización.

Exploremos cada paso con más detalle.

Paso 1. Formular el Problema de Optimización

Busque en casi cualquier documento relacionado con la optimización y verá que muestra los objetivos y las restricciones. En ejemplos de mi propio trabajo, la ecuación (1) de este documento (en la sección 5) es una formulación para una optimización restringida de objetivos múltiples en un espacio de búsqueda definido por una gramática. Aquí hay un fragmento:

Como otro ejemplo. Las ecuaciones (1) y (2) de este documento (en la sección 2) presentan un problema de búsqueda de optimización estocástica de un solo objetivo (“maximizar el rendimiento”) en un espacio variable de valor continuo n-dimensional.

Formular un problema en objetivos, restricciones y espacio de diseño no es fácil. De hecho, después de todos estos años, sigue siendo un arte que requiere mucha creatividad. (¡Lo que significa que es divertido!) A menudo hay muchas maneras de formular un problema; y no todos son iguales. Afortunadamente, puedes mejorar con la práctica. Veo amigos en la comunidad de EA y la comunidad de diseño asistido por computadora (CAD) de circuito que tienen habilidades supremas en el arte de formular problemas. Tu sabes quien eres;)

  • Por ejemplo, una formulación puede ser fácil de resolver y otra puede ser NP-difícil y no puede garantizar nada. Este es uno de los grandes trucos que usan las personas en el campo de la optimización convexa: toman problemas que se perciben como NP-difíciles y luego aplican técnicas para convertirlos en problemas convexos (por ejemplo, operadores logarítmicos bien ubicados). Luego, estos problemas convexos se pueden resolver en tiempo polinomial usando un solucionador convexo como la programación geométrica . He encontrado el éxito en esto también; para el problema resumido en el fragmento anterior, agregué restricciones gramaticales a un problema de inducción de árbol (síntesis de circuito analógico) y vi una mejora de 1000 veces en el tiempo de ejecución, así como mejores resultados del optimizador.
  • O bien, si está utilizando un algoritmo evolutivo (EA), desea diseñar el mapeo desde el punto de diseño → aptitud de modo que los pequeños cambios en el diseño generalmente conduzcan a pequeños cambios en el comportamiento y, en última instancia, en la aptitud. (Yo llamo a estos operadores suaves 😉

Paso 2. Pruebe un solucionador existente

Idealmente, puede formular el problema de manera que pueda aplicar un solucionador o algoritmo existente. Luego, simplemente ejecútelo y vea cómo funciona.

Si funciona: ¡has terminado y puedes parar ahora!

Hay al menos dos formas en que podría no funcionar. Primero, si el solucionador no converge lo suficientemente bien, puede probar diferentes formulaciones de problemas, solucionadores o parámetros del solucionador.

En segundo lugar, el solucionador podría converger demasiado “bien”, donde encuentra un diseño que es torcido. Para abordar esto, puede modificar el problema: agregue una nueva restricción o mejore la precisión del modelo/simulador. Si se encuentra en iteraciones tediosas de agregar restricciones (” IA whack-a-mole “), entonces probablemente querrá repensar su enfoque más amplio del problema.

Paso 3. ¿Nuevo solucionador? Diseñe un nuevo algoritmo de optimización, si es necesario

A veces te encuentras con un problema en el que ninguno de los solucionadores existentes es lo suficientemente bueno. Tal vez necesite una mejor escala, o tal vez necesite manejar alguna restricción que sea difícil de modelar, o tal vez algo más. Ahí es cuando vas e investigas sobre el diseño de algoritmos. Cuando haga esto, generalmente aprovechará los componentes básicos existentes y agregará sus propias ideas. El diseño de nuevos algoritmos puede llevar una enorme cantidad de tiempo, pero si se hace bien, es posible que pueda resolver el problema en cuestión con mejoras de orden de magnitud, por ejemplo, FFX .

(Y, ¿mencioné que es divertido ?)

4.3 Metodología de tokens

Las recompensas en bloque son una manifestación de la función objetivo de la red : lo que desea minimizar o maximizar. Esto generaliza. El diseño de tokens es como el diseño de algoritmos de optimización. Por lo tanto:

Podemos abordar el diseño de tokens como un diseño de optimización.

Podemos tomar los pasos del mundo del diseño de optimización y traducirlos en el diseño de ecosistemas tokenizados.

  1. Formule el problema: escriba los objetivos y las limitaciones de su ecosistema tokenizado. Esto significa preguntar: ¿quiénes son mis partes interesadas potenciales y qué quiere cada uno de ellos? ¿Qué son los vectores de ataque? Luego, tradúzcalos en objetivos y restricciones que pueda medir.
  2. Pruebe un patrón existente: identifique si existe un solucionador existente, es decir, un patrón de diseño de red tokenizado que pueda resolver su problema. Por ejemplo, si está buscando una lista de “buenos” actores/activos/etc., ¿servirá un registro curado por token (TCR)? Me explayaré sobre esto más adelante. Si esto no funciona, pruebe diferentes formulaciones de problemas, diferentes solucionadores o parámetros de solucionador. Por ejemplo, converge en un comportamiento no deseado, por lo que agrega una restricción para evitar ese comportamiento.
  3. Nuevo patrón? Si es necesario, implemente su propio solucionador, es decir, diseñe su propia red tokenizada. Por supuesto, al hacer esto, utilice los componentes básicos existentes cuando sea posible, desde las TCR hasta el arbitraje.

5. Patrones de diseño de tokens: un punto de partida

Cada campo maduro de ingeniería tiene su corpus de bloques de construcción. Tenemos libros para patrones de diseño en arquitectura , software , circuitos analógicos y, sí, optimizadores . Pero nadie ha escrito el libro sobre patrones de diseño de fichas , todavía.

Sin embargo, los bloques de construcción están comenzando a surgir. Algunos han visto explotar su popularidad rápidamente (p. ej ., los TCR ). Los párrafos siguientes exploran estos bloques. A veces forman mecánicas de fichas básicas; a veces se involucran para resolver problemas particulares. Esta lista es solo un punto de partida.

  • Curación. Membresía binaria : Token Curated Registry (TCR), por ejemplo, para mantener una lista de buenos actores. Un subbloque de TCR es la asunción de riesgos para reducir la fricción de incorporación. Membresía de valor discreto : Stake Machines , por ejemplo, para promocionar a un actor. Membresía de valor continuo : Mercados de curación (CM) para la popularidad de un activo, definido por su curva de vinculación con las pautas de diseño aquí . Membresía jerárquica : cada etiqueta obtiene un TCR (como aquí ). Trabajo vinculado a la membresía: Mercado de pruebas seleccionadas (CPM). Curación de tokens no fungibles:Tokens Re-fungibles (RFT).
  • Identidad. Nivel inferior: clave pública, identificadores descentralizados ( DID ). Nivel medio : TCR. Nivel superior : por ejemplo , uPort , Civic , Sovrin , Authenteq , Taqanu , Estonia E-Residency . Identidad de las máquinas: por ejemplo , Spherity
  • Reputación. Los sistemas de reputación se encuentran en la intersección de la curaduría y la identidad.
  • Gobernanza/actualizaciones de software. Esto puede ser una combinación de ZeppelinOS , Aragon , Colony y más. ¿ Quizás eventualmente automatizado ?
  • Arbitraje de terceros. Por ejemplo , Mattereum .
  • Pruebas de “trabajo” humano o informático. Para datos, computación y más. Esta es la evaluación de la función objetivo. Puede ser trabajo humano como en Steemit o Augur , o trabajo de máquina como en la mayoría de los otros sistemas. El trabajo de la máquina puede ser resolver un rompecabezas (posiblemente) menos útil como en Bitcoin, o un trabajo más “útil” como la Prueba del espacio-tiempo de FileCoin . Aquí hay un desglose del trabajo útil (“integridad del servicio”) agrupado por datos y computación (desde aquí ).

Otras formas de enmarcar o agrupar bloques de construcción incluyen:

  • Cómo se distribuyen las fichas. Esto incluye la liberación de monedas por “trabajo”, de acuerdo con un programa de suministro controlado ; 100% pre-minado; quemar y menta ; ICO de recompensas ; y más.
  • Estándares de token Ethereum , como el token fungible ERC20 y el token no fungible ERC721 . El léxico simbólico de Billy Rennekamp es útil.
  • Cómo se valoran las fichas. Como medio de intercambio, depósito de valor y unidad de cuenta, por Chris Burniske .
  • Cómo se agrupan los guardianes. Para control de acceso, arbitraje o transacción de recursos, por Ryan Zurrer .
  • Cómo se organiza la pila de cómputo. Procesamiento, almacenamiento, etc. Esto tiene variantes de Fred Ehrsam , Stephan Tual y yo mismo .
  • Infraestructura de nivel 1, nivel 2, nivel N. La cadena central es el nivel 1. Los niveles superiores son para ayudar a escalar sin tener que reconciliar la cadena principal en cada transacción. enlace _
  • “ Primitivos criptoeconómicos ” de Jacob Horne. Otra etiqueta para patrones de diseño de fichas o bloques de construcción. [Publicado después de la publicación inicial de este trabajo.]

Esta enumeración de patrones es solo un punto de partida; Espero verlo crecer.

6. Necesario: herramientas para simulación, verificación y exploración espacial de diseño

6.1 Qué

Los ingenieros profesionales que construyen cosas que “simplemente funcionan” usan herramientas de software para ello. Los ingenieros de software a menudo usan entornos de diseño integrado (IDE) que son gratuitos o relativamente baratos.

Pero puedes ser mucho más sofisticado. En el diseño de circuitos, las herramientas clave son para simulación, verificación y exploración del espacio de diseño. Las agrupaciones  de herramientas pueden volverse bastante sofisticadas con el tiempo. Pero con estas herramientas, permite que un equipo de 10 ingenieros diseñe un chip de mil millones de transistores en cuestión de meses . Un buen ingeniero podría estar ejecutando herramientas por un valor de $ 1 millón (¡ese es el costo anual de la licencia!).

“Ahora estás jugando con poder”: eslogan de marketing de Nintendo en la década de 1980

Consigamos algunas herramientas eléctricas para este nuevo campo. Nosotros necesitamos:

  1. Herramientas para simular ecosistemas tokenizados . Los simuladores miden las métricas de rendimiento de un diseño dado. Un punto de partida es el modelado basado en agentes que surge de los campos de la ciencia de la complejidad y la inteligencia artificial general . Otro son los simuladores de redes que ya se utilizan para el diseño de algoritmos de consenso. Otro es modelar como un conjunto de ecuaciones diferenciales (DE), luego resolver con un solucionador de DE como SPICE .
  2. Herramientas para verificar ecosistemas tokenizados . Estos verifican que un diseño puede funcionar (según sus métricas de rendimiento) a pesar de las variables incontrolables que afectan el rendimiento. Una variable incontrolable sigue (a) un rango donde el diseño debe funcionar bien en cualquiera de los valores de la variable, o (b) una distribución de probabilidad donde el diseño debe funcionar bien en >x% de los escenarios. Estos son “rendimiento en el peor de los casos” y “rendimiento n-sigma” respectivamente. “n-sigma” es una unidad para expresar la tasa de fallas, al igual que “% de trabajo” o “% de fallas”; por lo general, los diseños apuntan a 2-sigma (funciona el 95 % del tiempo), 3-sigma (funciona el 99,7 % del tiempo) o 6 sigma (falla aproximadamente 1 en mil millones de veces).
  3. Herramientas para la exploración del espacio de diseño. Estos ayudan al diseñador a explorar el espacio de diseño, es decir, dan una idea de lo que sucede con el desempeño en el peor de los casos/n-sigma cuando se modifican las variables controlables.

6.2 Herramienta de ejemplo para simulación, de Circuit Design

La siguiente figura muestra un ejemplo de un entorno de simulador de circuito. La parte superior izquierda es un editor de esquemas para ingresar el diseño. Para circuitos analógicos, esta es la elección de resistencias, condensadores, transistores, etc. cómo están conectados; y cuales son sus medidas. Esa entrada luego se convierte automáticamente en un conjunto de ecuaciones diferenciales que luego se resuelven usando el simulador. Las otras tres ventanas muestran los resultados de varias simulaciones. En el sentido de las agujas del reloj desde la parte superior derecha se encuentran el análisis de sesgo (dc), el análisis basado en el tiempo (transitorio) y el análisis de frecuencia (ac).

6.2 Ejemplo de herramienta para verificación, de Circuit Design

Esta sección y la siguiente son ejemplos de herramientas CAD que ayudé a desarrollar y que ahora son ampliamente utilizadas por ingenieros de Sony, Qualcomm, etc.

A continuación se muestra una herramienta que verifica que el chip no fallará en una variedad de condiciones “PVT” en el peor de los casos: extremos en el voltaje de la fuente de alimentación , temperatura, carga, etc. Por lo tanto, P , V y T son las variables incontrolables .

Esta herramienta en particular encuentra el peor de los casos empleando un optimizador global que intenta optimizar hacia la falla, usando un simulador de circuito en el bucle.

6.2 Herramienta de ejemplo para la exploración del espacio de diseño, de Circuit Design

La siguiente imagen muestra una herramienta para explorar el espacio de diseño. Informa el impacto relativo de las variables en varios resultados (izquierda) y cómo las variables de diseño se asignan a los resultados (derecha). El ingeniero puede cambiar los diseños arrastrando la cruz naranja.

Estas y otras herramientas ahora se usan ampliamente para diseñar chips modernos. Los simuladores entraron en funcionamiento en la década de 1970 y las herramientas CAD en la década de 1980; y nadie ha mirado atrás. Estas herramientas son cruciales para el diseño moderno de chips. Cuesta >$50 millones fabricar un diseño en un proceso moderno; Sería, bueno, estúpido no verificar y optimizar ese diseño al mejor nivel posible antes de comprometer los $50 millones.

Sin embargo, en el mundo del diseño de tokens, estamos construyendo y desplegando lo que esperamos sean ecosistemas de miles de millones de dólares, sin apenas herramientas. Ni siquiera es 1970 todavía. ¡Espero con ansias el día en que lleguemos a este nivel para la ingeniería de tokens!

6.3 Limitaciones de las herramientas

Reconozco una diferencia clave entre los chips complejos y las economías: los humanos en el circuito. Los chips son sistemas cerrados. Los humanos hacen que el modelado de una economía sea mucho más complicado. Sin embargo, tengo la esperanza de que podamos mejorar el status quo de “nada”, porque construimos sistemas todos los días que involucran a humanos. Aquí hay algunas ideas complementarias.

Una opción es no tratar de modelar cisnes negros , sino simplemente minimizar los impactos negativos potenciales si ocurren.

O bien, podríamos tener humanos en el circuito como parte del “simulador” donde se les incentiva a idear ataques. Esto formaliza una práctica existente: las personas que diseñan tokens hacen que sus amigos sueñen con nuevos ataques, luego actualizan la lista de restricciones y luego el diseño en consecuencia. Me he encontrado en docenas de tales conversaciones.

La simulación nunca será perfecta. Por lo tanto, debemos asegurarnos de que el sistema en sí sea evolutivo , hacia la intención de la comunidad. Las herramientas para esto son la gobernanza, la participación y más. La gobernanza puede ser tan simple como hard forks, por ejemplo, para cambiar la función objetivo o agregar restricciones. El staking ayuda a convertir la suma cero en una suma positiva para la comunidad de poseedores de fichas.

6.4 Motivación extrínseca vs. intrínseca

“ La motivación extrínseca es el estímulo de una fuerza externa; el comportamiento se realiza en base a la expectativa de una recompensa externa [para convencer] a alguien de hacer algo que no haría por sí mismo. …

Intrínseco significa innato o dentro; por lo tanto, la motivación intrínseca es el estímulo o impulso que surge del interior de uno mismo. … La motivación intrínseca a menudo se asocia con recompensas intrínsecas porque las recompensas naturales de una tarea son las fuerzas motivadoras que alientan a un individuo en primer lugar”. [ Enlace ]

Este artículo se ha centrado principalmente en la motivación extrínseca: descubra para qué estamos tratando de optimizar y luego optimice directamente para eso. Sin embargo, la motivación extrínseca puede tener problemas. En educación, las recompensas extrínsecas reducen la motivación intrínseca de los niños para aprender y dificultan la autodeterminación y el pensamiento independiente. Afortunadamente existen estilos de enseñanza que fomentan la motivación intrínseca [ link ].

Para los ecosistemas tokenizados, debemos ser igualmente cuidadosos. La motivación extrínseca funciona para algunos objetivos como “maximizar la seguridad” o “maximizar el intercambio de datos”. Pero puede ser peligroso en algunos lugares. Digamos que está construyendo un sistema de reputación descentralizado. La tokenización directa de la reputación incentivaría a las personas a jugar con su reputación por dinero, lo que conduciría a todo tipo de malos comportamientos. También puede ser controlador, como hemos visto con China . Solo di no a Whuffie (por favor).

Una posible respuesta es que el sistema apoye la motivación intrínseca en lugar de la extrínseca. En el aula, esto significa tácticas como : ofrecer opciones, minimizar la presión, permitir soluciones alternativas, fomentar la originalidad y promover el éxito. Algunos de estos podrían traducirse en diseño de fichas. Un ejemplo es simplemente filtrar a los malos actores con participación económica, por ejemplo, con un TCR. O bien, podríamos promover el éxito a través de máquinas de apuestas.

7. Conclusión

Este artículo describió cómo podemos aprovechar los campos existentes para ayudar a diseñar ecosistemas tokenizados: diseño de tokens como diseño de optimización; patrones de diseño de tokens; y herramientas de diseño de tokens inspiradas en las herramientas de diseño de circuitos. El objetivo general es una práctica de ingeniería de tokens . ¡Vamos a llegar!

El siguiente artículo de esta serie aplica estas técnicas a dos casos de estudio: análisis de Bitcoin y diseño de Ocean Protocol.

Apéndice: Llamando a todos los eruditos

He notado que hay un grupo de personas en blockchain que parecen prosperar especialmente bien. Son las máquinas de aprendizaje: las personas que aprenden por diversión, construyen por diversión, que bailan entre muchos campos y construyen puentes entre ellos. Sí, los eruditos.

En este artículo, describí cómo las prácticas de optimización y otros campos podrían ayudar en el diseño de ecosistemas tokenizados. También significa que los expertos de estos campos podrían encontrar sus habilidades útiles en el nuevo y valiente mundo de las cadenas de bloques. Tengo la esperanza de que los diseñadores de microeconomías de videojuegos puedan trasladar sus habilidades. Además, al igual que en blockchain: muchas personas de IA, sistemas complejos y más son eruditos naturales.

He visto esto de primera mano. Mis propias experiencias en IA y optimización han sido extremadamente útiles para asimilar blockchain. Además, me ha resultado más fácil impulsar a las personas de IA enseñándoles el delta entre lo que saben y blockchain. ¡Simplemente describo los sistemas tokenizados como EA! Para la gente de Vida Artificial, es vida. Para los ingenieros eléctricos, son sistemas de control de retroalimentación. Etcétera.

Apéndice: Artículos y medios relacionados

Este artículo es parte de una serie:

  • Parte I. ¿Pueden las cadenas de bloques volverse deshonestas? AI Whack-A-Mole, máquinas de incentivos y vida.
  • [Este artículo] Parte II. Hacia una Práctica de Ingeniería de Tokens: Metodología, Patrones y Herramientas.
  • Parte III. Estudios de casos de ingeniería de tokens : análisis de Bitcoin, diseño de Ocean Protocol.

Aquí hay un video para el contenido de este artículo. A continuación se muestran las diapositivas. Esta charla se dictó en EthCC París en marzo de 2018.

Contenido relacionado:

Apéndice: Esfuerzos relacionados

Estoy buscando aprendizajes prácticos de los que el campo blockchain pueda aprender, con la intención de organizar y difundir las experiencias. Si lee este artículo y piensa “espere, he estado diseñando mecanismos para el campo X”, comuníquese con nosotros.

La publicación de este artículo parece haber provocado un movimiento en #tokenengineering . ¡Impresionante! 🙂 🙂 Un recurso clave es el wiki tokenengineering.net . Tiene información sobre bloques de construcción, herramientas, reuniones comunitarias y más.

Agradecimientos

Gracias a las siguientes personas por revisar este y otros artículos de la serie: Ian Grigg , Alex Lange , Simon de la Rouviere , Dimitri de Jonghe , Luis Cuende , Ryan Selkis , Kyle Samani y Bill Mydlowec . Gracias a muchos otros por las conversaciones que también influyeron en esto, incluidos Anish Mohammed , Richard Craib , Fred Ehrsam , David Krakauer , Troy McConaghy , Thomas Kolinko , Jesse Walden , Chris Burniske yBen Goertzel . Y gracias a toda la comunidad de blockchain por proporcionar un sustrato que hace posible el diseño de tokens 🙂

Ediciones

Aquí hay algunas actualizaciones desde la publicación inicial. Gracias a todos los que dieron su opinión sobre estas actualizaciones también.

  • 3 de marzo de 2018: se agregaron enlaces a los Tokens Re-Fungibles de Billy Rennekamp y al léxico de tokens . Enfatizó el artículo de Slava Balasanov sobre el diseño de la curva de unión.
  • 5 de marzo de 2018: Se agregó la sección “Limitaciones de las herramientas” según los comentarios de Bill Mydlowec y Gabriel Nergaard . Se agregó la sección “Esfuerzos relacionados”. Vinculada la idea de la gobernanza automatizada , de Miles Albert. Se agregó la sección “Motivación extrínseca versus intrínseca” a través de los comentarios de Christopher Allen . Vinculado a la teoría económica de los juegos a través de Ali Yahya . Elaborado en el paso de “agregar restricciones” para el diseño del optimizador y los pasos de diseño del token. Descripción refinada de “resonancia” a través de Troy McConaghy. Fijo “cc”.
  • 6 de marzo de 2018. Se agregó la referencia “Primitivas criptoeconómicas”. Se agregó la sugerencia de Elad Verbin de que los expertos en políticas públicas están bien preparados para la ingeniería de tokens. Se agregó un enlace a la toma de riesgos.
  • 28 de marzo de 2018. Se cambió el nombre de “Mercado de conservación de pruebas” a “Mercado de pruebas de conservación”. ¿Por qué? Es más fácil de entender.
  • 4 de junio de 2018. Se reemplazó la lista de “esfuerzos relacionados” por un enlace a la wiki de ingeniería de tokens y el hashtag #tokenengineering.
  • 5 de junio de 2018. Se actualizó la sección “artículos y medios relacionados” para enfatizar las diapositivas y el video que comunican mejor este artículo (charla de EthCC).

Fuente: Trent McConaghy https://blog.oceanprotocol.com/towards-a-practice-of-token-engineering-b02feeeff7ca