a16z: Explorando 8 desafíos en el diseño de mecanismos blockchain

Autor original: Tim Roughgarden, director de investigación de criptomonedas en a16z

Traducción original: 0x xz, Golden Finance

Estudiar un campo en profundidad te enseña a reconocer que los problemas del mundo real son disfraces pobres de problemas bien resueltos. Por ejemplo, cuando enseñaba los conceptos básicos de algoritmos, los estudiantes aprendían a reconocer problemas que se reducían a cálculos de ruta más corta o programación lineal.

Este tipo de comparación de patrones funciona igual de bien en el diseño de mecanismos, una especie de “teoría de juegos inversa” que utiliza incentivos para lograr los resultados deseados. Las herramientas y lecciones del diseño de mecanismos son particularmente útiles en la teoría de subastas, el diseño de mercados y la teoría de la elección social.

Las criptomonedas y la Web3 están plagadas de problemas de diseño de mecanismos. Uno podría pensar que muchos de estos problemas se pueden resolver aplicando lo que está en los libros de texto, dándole un giro nuevo a viejas ideas. Sin embargo, los desafíos y limitaciones únicos de los protocolos de cadenas de bloques sin permisos a menudo obligan a repensar los fundamentos de problemas aparentemente resueltos. Esto hace que el diseño de mecanismos en la Web3 sea complejo. Pero también son estos desafíos los que hacen que el diseño de mecanismos en la Web3 sea fascinante.

En este artículo, exploraré algunos de los desafíos que enfrenta el diseño de mecanismos web3. Estos desafíos pueden resultar familiares para los usuarios nativos de criptografía, pero una comprensión más profunda del diseño de mecanismos debería brindarles a todos los desarrolladores una nueva perspectiva sobre por qué es tan difícil resolver estos problemas. Para los diseñadores de mecanismos, si están pensando en nuevas aplicaciones, es posible que les interese conocer los desafíos que plantean los entornos sin permisos.

Pero primero, ¿qué es el diseño de mecanismos?

El campo del diseño de mecanismos se remonta al menos a 1961, cuando William Vickrey, economista de la Universidad de Columbia y posteriormente premio Nobel, formalizó la subasta de oferta sellada al segundo precio. Este formato de subasta se utilizó ya en 1797, cuando el autor Johann Wolfgang von Goethe vendió el manuscrito de su poema épico Hermann y Dorothea, y era de uso común entre los coleccionistas de sellos en el siglo XIX, pero Vickrey no lo formalizó hasta 1961 y ahora se lo suele llamar subasta Vickrey. En el modelo de subasta Vickrey, el mejor postor gana, pero paga la segunda oferta más alta. Esta subasta estimula las verdaderas preferencias de los postores y entrega el artículo a la persona que estima la oferta más alta.

La subasta de Vickrey es un diseño elegante y eficiente que se ha aplicado en el mundo real, adaptado y actualizado a nuevas circunstancias, con la práctica informando a la teoría y viceversa. Al igual que la subasta de Vickrey, la historia del diseño de mecanismos como disciplina formal es una historia de la intersección de la teoría y la práctica, a la vez profunda y hermosa.

A diferencia de la teoría de juegos, que establece dimensiones de interacción estratégica y explora los resultados más plausibles de la conducta, el campo del diseño de mecanismos no comienza con juegos, sino con resultados deseados. El objetivo del diseño de mecanismos es aplicar ingeniería inversa a alguna forma de juego para que el resultado deseado (que puede caracterizarse por la eficiencia, la equidad o ciertas conductas) sea equilibrado. En el caso de una subasta Vickrey, el objetivo final es inducir a los participantes a pagar la cantidad máxima que están dispuestos a pagar sin penalizarlos.

Las oportunidades para el diseño de mecanismos en la Web3 son numerosas. Por ejemplo, un protocolo de cadena de bloques puede querer lograr un resultado en el que los participantes del protocolo se comporten de buena fe (y no se desvíen del comportamiento esperado). O puede querer obtener información precisa sobre los valores de las transacciones para asignar eficientemente espacio en bloques a las transacciones más valiosas.

Estos problemas de diseño de mecanismos siempre son desafiantes, pero los desafíos son aún más singulares en el contexto de blockchain.

1. Falta de confianza

Sin un tercero confiable que haga cumplir los mecanismos, diseñar en el espacio blockchain se vuelve mucho más difícil.

El objetivo de utilizar un protocolo de cadena de bloques sin permisos es que no es necesario confiar en ninguna entidad o persona, solo se necesita una suposición de confianza "promedio" de que una cantidad suficiente de nodos que ejecutan el protocolo son honestos.

Pero la ironía de muchas arquitecturas blockchain es que cada lote de transacciones agregadas al historial de la cadena para ser ejecutadas en la máquina virtual mantenida por el protocolo es el producto de una decisión unilateral tomada por un solo nodo.

No está claro si puedes confiar en este nodo.

Por eso, las subastas Vickrey rara vez se ven en el espacio blockchain. Implementar subastas Vickrey de manera ingenua rápidamente se topa con el problema de la manipulación por parte de productores de bloques que no son de confianza. El problema es que un productor de bloques puede crear una oferta falsa llamada "oferta ficticia" que es ligeramente inferior a la oferta del posible ganador, lo que obliga al ganador a pagar casi la totalidad de su oferta (en lugar de la segunda oferta más alta real).

Las ofertas falsas de productores de bloques que no son de confianza hacen que la subasta Vickrey vuelva a ser una subasta de primer precio, lo que es una de las razones por las que las subastas de primer precio son tan comunes en la Web3. (La última rama de la literatura de diseño de mecanismos tradicionales sobre mecanismos de confianza también considera el diseño de subastas para subastadores que no son de confianza, pero desde una perspectiva diferente).

2. Colusión

Otra razón por la que el diseño de mecanismos de blockchain es difícil es que puede haber colusiones entre los participantes de la cadena de bloques. Por ejemplo, las subastas de segundo precio pueden ser fácilmente coludidas con pagos de compensación. La razón es simple: dado que el postor ganador paga la segunda oferta más alta, el postor puede sobornar al segundo postor más alto para que ofrezca una oferta mucho más baja.

La literatura académica sobre el diseño de mecanismos no se ha preocupado demasiado por este problema. Una razón puede ser que la colusión (especialmente la colusión con pagos compensatorios) es difícil de lograr en el mundo real. Después de la colusión, el ganador puede simplemente negarse a pagar el soborno, por lo que es difícil obtener pagos compensatorios creíbles. (Como dice el refrán: No hay justicia entre ladrones).

Sin embargo, en el contexto de la cadena de bloques, los posibles colusores a menudo pueden utilizar contratos inteligentes para ofrecer compromisos fiables, lo que permite que la colusión funcione realmente. La segunda razón es la falta de un mecanismo para suprimir y compensar la colusión en los pagos: un mecanismo de divulgación de precios que solo proporcione cotizaciones y nada más.

Peor aún, los usuarios del protocolo podrían potencialmente coludirse no sólo entre ellos, sino también con productores de bloques (no confiables) (equivalente a la colusión entre los postores y el subastador en una subasta del mundo real).

La protección contra el último tipo de colusión es una de las principales motivaciones para quemar una parte de las tarifas de transacción en el mecanismo de tarifas de transacción EIP-1559 de Ethereum. Sin “quemar” (o retener de otro modo estos ingresos a los productores de bloques), los productores de bloques y los usuarios finales pueden coludirse mediante pagos compensatorios y evadir cualquier precio de reserva que el mecanismo intente imponer.

3. No podemos confiar únicamente en el estado de derecho

El problema de la colusión obviamente no es nuevo. Ha afectado a varios mecanismos de la vida real durante siglos, pero si se examina la literatura sobre diseño de mecanismos, puede sorprenderse al ver lo poco que se ha abordado el problema. La literatura sí aborda de frente los incentivos de los actores individuales para manipular unilateralmente el mecanismo, pero por lo general deja el problema en manos de alguna noción no reconocida del “estado de derecho”. Por ejemplo, los participantes en el mecanismo pueden firmar un contrato legal que estipula que no se coludirán. Si se detecta colusión, se lleva el asunto a los canales legales. Los diseñadores de mecanismos pueden ayudar creando un mecanismo que haga que sea relativamente fácil detectar la colusión.

Existe un secreto no mencionado en gran parte de la literatura sobre diseño de mecanismos: la dependencia del estado de derecho. Si bien no podemos decir que no exista estado de derecho en el ámbito de los protocolos de cadenas de bloques sin permiso (a menudo vemos que las fuerzas del orden procesan con éxito delitos en cadenas de bloques sin permiso), el alcance del estado de derecho es mucho menor que en las aplicaciones de diseño de mecanismos tradicionales.

Si no se puede confiar en el estado de derecho fuera del mecanismo, entonces es responsabilidad del diseñador resolver el problema dentro del mecanismo. Este enfoque es frecuente en las decisiones de diseño de mecanismos en el espacio blockchain. En el protocolo Ethereum en particular, abundan los ejemplos, desde la EIP-1559 que quema los ingresos de la tarifa base hasta el recorte de los validadores que se comportan mal en su protocolo de consenso.

4. Espacio de diseño más amplio

El espacio de diseño en la Web3 es más grande de lo que los diseñadores de mecanismos están acostumbrados. Por lo tanto, los diseñadores deben repensar todos los problemas existentes. Por ejemplo, muchos mecanismos implican pagos que, en las aplicaciones de diseño de mecanismos tradicionales, se realizarían en monedas fiduciarias como el dólar estadounidense. Muchos protocolos de cadena de bloques tienen sus propias monedas nativas y los mecanismos dentro de dichos protocolos pueden manipular estas monedas.

Imagínese que escribiera un artículo sobre el diseño de un mecanismo tradicional y que parte de la descripción del mecanismo fuera: imprimir un montón de moneda nueva y distribuirla entre un montón de participantes. Fuera del contexto de la cadena de bloques, esto es ridículo. Pero cuando se habla del diseño de un mecanismo en el contexto de un protocolo de cadena de bloques, se puede hacer sin dudarlo. El protocolo controla la moneda, por lo que parte del mecanismo del protocolo puede acuñar tokens o quemarlos.

Esto significa que algunos diseños que serían imposibles sin una moneda nativa se vuelven posibles. Por ejemplo, ¿cómo se incentiva a los mineros de Bitcoin para que ejecuten el protocolo según lo previsto? A través de recompensas por inflación: imprimiendo nuevas monedas (Bitcoins) para incentivar a estos productores de bloques. Sin una moneda nativa, un diseño así no sería posible.

5. Las monedas nativas pueden traer otros problemas

La razón anterior resalta el poder de las monedas nativas. Se pueden hacer dos cosas con las monedas nativas: acuñar (la forma en que el protocolo Bitcoin crea nuevos Bitcoins para incentivar a los mineros) y quemar tokens (la forma en que el mecanismo de tarifa de transacción EIP-1559 de Ethereum quema ETH para resistir la colusión). Las monedas nativas esconden peligros que no existen en el diseño de mecanismos tradicionales: las decisiones de diseño microeconómico pueden tener consecuencias macroeconómicas.

En el diseño de mecanismos tradicionales, no hay motivos para preocuparse por las fuerzas macroeconómicas. Las subastas tradicionales no han tenido un impacto significativo en la oferta monetaria o la tasa de inflación en los Estados Unidos. Este es un desafío completamente nuevo para el campo del diseño web3. ¿Qué problemas pueden surgir? Permítanme contarles dos ejemplos, uno sobre la acuñación de Bitcoin y otro sobre la quema de ETH.

Debido al uso de recompensas por bloque (que incentivan a los mineros mediante la impresión de nuevas monedas), Bitcoin se ve obligado a tener inflación. Por lo tanto, también debe tener una política monetaria correspondiente para determinar la tasa de inflación y cómo evoluciona con el tiempo. Satoshi Nakamoto también estableció un límite de suministro estricto de 21 millones de Bitcoins. Dado que existe un límite estricto para la cantidad de Bitcoins, la tasa de inflación debe acercarse a cero.

Si la tasa de inflación es realmente cero, ¿qué se debería utilizar para incentivar a los mineros a seguir utilizando el protocolo y brindar seguridad a Bitcoin? Se ha esperado que las tarifas de transacción compensen las recompensas por bloque faltantes, aunque las probabilidades de que esto suceda son bastante escasas. Es bien sabido que si las tarifas de transacción son cercanas a cero, entonces el protocolo Bitcoin sufrirá importantes problemas de seguridad.

En un artículo, los informáticos de Princeton Miles Carlston, Harry Kalodner, Matthew Weinberg y Arvind Narayanan señalaron otra diferencia entre las tarifas de transacción y las recompensas por bloque. Si bien la recompensa por bloque es la misma para cada bloque (al menos entre “reducciones a la mitad” sucesivas de la recompensa por bloque), las tarifas de transacción pueden variar en órdenes de magnitud, lo que a su vez introduce nuevas inestabilidades de teoría de juegos en el protocolo. En este sentido, la decisión macroeconómica de fijar un límite de oferta tiene consecuencias microeconómicas negativas para el protocolo y sus participantes.

Así como la acuñación de recompensas en bloque es una fuerza inflacionaria para Bitcoin, la quema de tarifas de transacción en EIP-1559 es una fuerza deflacionaria para Ethereum. En el protocolo Ethereum (que sí utiliza recompensas inflacionarias para los validadores), existe un tira y afloja entre estas dos fuerzas, en la que la deflación suele ganar. ETH es ahora una moneda deflacionaria neta, una consecuencia macroeconómica de decisiones de diseño motivadas microeconómicamente en el mecanismo de tarifas de transacción de los protocolos.

¿La deflación es buena o mala para el protocolo Ethereum? A los poseedores de ETH les gusta la deflación porque, en igualdad de condiciones, sus tokens se vuelven más valiosos con el tiempo. (De hecho, este subproducto puede ser lo que finalmente influyó en la opinión pública a favor de un cambio al mecanismo de tarifas por transacciones de EIP-1559). Sin embargo, el término deflación asusta a los macroeconomistas con formación clásica, y les recuerda la estanflación económica de Japón en la década de 1990.

¿Quién tiene razón? Personalmente, no creo que las monedas fiduciarias soberanas sean la analogía correcta para las criptomonedas como ETH. Entonces, ¿cuál es la analogía correcta? Esta sigue siendo una pregunta abierta que necesita mayor exploración por parte de los investigadores de blockchain: ¿por qué las monedas deflacionarias pueden ser criptomonedas que admitan protocolos de blockchain, pero no monedas fiduciarias que admitan estados soberanos?

6. No ignore la pila subyacente

Una de las cosas que nos esforzamos por lograr en informática es la modularidad y las abstracciones claras, que nos dan la capacidad de confiar en las partes de un sistema. Al diseñar y analizar una parte de un sistema, es posible que necesite conocer la funcionalidad que generan otras partes del sistema. Pero lo ideal es que no necesite saber cómo se implementa esta funcionalidad en segundo plano.

Aún no hemos alcanzado este estado ideal en los protocolos de blockchain. Si bien los desarrolladores y diseñadores de mecanismos pueden preferir centrarse en la capa de aplicación, no pueden ignorar cómo funciona la capa de infraestructura y sus detalles.

Por ejemplo, si está diseñando un creador de mercado automatizado, debe considerar la posibilidad de que productores de bloques no confiables sean responsables de ordenar las transacciones. O, si está considerando diseñar un mecanismo de tarifa de transacción para un rollup (L2), debe pagar no solo por el consumo de recursos de L2, sino también por todos los costos incurridos por el protocolo L1 subyacente (por ejemplo, almacenar datos de llamadas).

En ambos ejemplos, el diseño eficaz de un mecanismo para una capa requiere un conocimiento detallado de las demás capas. Tal vez, a medida que madure la tecnología blockchain, tengamos una separación clara de las diferentes capas, pero sin duda aún no hemos llegado a ese punto.

7. Requiere trabajar en un entorno computacionalmente restringido.

La computadora en el cielo implementada por el protocolo blockchain es un entorno computacionalmente limitado. El diseño de mecanismos tradicionales se centra únicamente en los incentivos económicos e ignora los problemas computacionales (por ejemplo, el famoso mecanismo Vickrey-Clark-Groves es inviable para problemas de asignación altamente complejos).

Cuando Nisan y Ronen propusieron el diseño de mecanismos algorítmicos en 1999, señalaron que necesitamos algún tipo de trazabilidad computacional para que los mecanismos tengan un significado práctico en el mundo real. Por lo tanto, propusieron restringir la atención a los mecanismos de computación y comunicación que escalan con cierta cantidad de función polinómica (no exponencial) de los parámetros del problema.

Dado que las máquinas virtuales del protocolo blockchain realizan muy pocos cálculos, los mecanismos en cadena deben ser extremadamente livianos: el tiempo polinomial y la comunicación son necesarios, pero no suficientes. Por ejemplo, la escasez es la razón principal por la que los creadores de mercado automatizados dominan por completo el mercado DeFi de Ethereum, en lugar de soluciones más tradicionales como los libros de órdenes limitadas.

8. Aún en las primeras etapas

Por lo general, cuando la gente dice que la Web3 está en sus primeras etapas, se refieren a la oportunidad de inversión o a su adopción. Pero desde una perspectiva científica, estamos incluso antes de eso. La cosa va a ponerse cada vez más difícil, aunque la oportunidad es enorme.

Todo el mundo da por sentado que trabajar en un campo de investigación maduro tiene ventajas. Hay modelos y definiciones aceptados. Existe consenso sobre las cuestiones más importantes. Existe una coordinación fundamental sobre cómo medir el progreso. Hay un vocabulario común y una gran base de conocimiento público. También hay vías para acelerar el progreso, como libros de texto con buenas críticas, cursos en línea y otros recursos.

Al mismo tiempo, en muchos aspectos del espacio blockchain, aún no conocemos los modelos y definiciones “correctos” para pensar con claridad y avanzar en problemas importantes. Por ejemplo, ¿cuál es el concepto más importante de incentivos de compatibilidad en el contexto de los protocolos blockchain? ¿Cuáles son las capas de la pila web3? ¿Cuáles son los componentes del Valor Máximo Extraíble (MEV)? Todas estas son preguntas abiertas.

Para quienes se interesan por la ciencia de la cadena de bloques, la inmadurez del campo es un desafío, pero involucrarse temprano, ahora, también presenta oportunidades únicas.

El diseño de mecanismos siempre ha sido una herramienta útil en la capa de aplicación de Internet, como en las subastas de publicidad en tiempo real o el diseño de mercado de dos caras que prevalece en la mayoría de las aplicaciones de consumo en línea actuales, desde el comercio electrónico hasta las compras grupales.

Pero en la web3, el diseño de mecanismos también informa las decisiones de diseño sobre la infraestructura misma.

Pensemos en los años 70 y 80, cuando los protocolos de enrutamiento de Internet todavía se discutían y diseñaban. Hasta donde yo sé, nadie con experiencia en el diseño de incentivos y mecanismos tenía un lugar en la mesa. En retrospectiva, ahora nos damos cuenta de que esas personas podrían haber proporcionado información útil para el diseño. Mientras tanto, en la Web3, con la publicación del libro blanco original de Bitcoin, los mecanismos de incentivos fueron parte de la discusión desde el principio.

La confusión que rodea al modelo, la definición y las métricas de éxito adecuados para la Web3 nos está indicando en realidad que estamos en una época dorada. Las futuras generaciones de estudiantes y científicos nos envidiarán por estar en el lugar correcto en el momento correcto, con la oportunidad de dar forma a la trayectoria de esta tecnología. Así que, aunque puede que no haya muchos libros de texto en este campo, algún día los habrá, y lo que esos libros describirán es el trabajo que estamos haciendo ahora.

Este artículo proviene de Internet: a16z: Explorando 8 desafíos en el diseño de mecanismos de blockchain

Relacionado: Ecología comunitaria | Conozca los cuatro aspectos más destacados del informe del primer trimestre de TRON de 2024 en un solo artículo

Messari, una de las principales organizaciones de investigación de datos criptográficos, publicó recientemente el informe TRON Q1 para 2024. El informe muestra que TRON ha tenido un buen desempeño en términos de ingresos por protocolo, deflación de TRX, TVL DeFi y monedas estables. En el primer trimestre, los ingresos por protocolo TRON aumentaron en 7,2% mes a mes, alcanzando un récord de US$128,1 millones, ocupando el tercer lugar entre todas las redes blockchain, solo superado por Ethereum y Bitcoin. Los ingresos por protocolo provienen del TRX quemado por los usuarios para obtener recursos y pagar tarifas. El informe muestra que TRX continuó manteniendo la deflación en el primer trimestre y su circulación cayó de 88,2 mil millones a aproximadamente 87,7 mil millones. La red TRON es una de las pocas redes L1 deflacionarias. En términos de DeFi, TRON también tuvo un buen desempeño. El informe muestra que el TVL de TRON DeFi…