Autor original: Tim Roughgarden, jefe de investigación criptográfica de a16z
Compilación original: 0x xz, Golden Finance
El estudio profundo de un campo te enseña que los problemas del mundo real son sólo malos disfraces de problemas que se han resuelto bien. Por ejemplo, cuando enseño conceptos básicos de algoritmos, los estudiantes aprenden a identificar problemas que se reducen a cálculos de ruta más corta o programación lineal.
Este tipo de coincidencia de patrones también es eficaz en el diseño de mecanismos, que es una especie de "teoría de juegos inversos" 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 las subastas, el diseño de mercados y la teoría de la elección social.
Crypto y web3 están plagados de problemas de diseño mecánico. Se podría pensar que muchos problemas pueden resolverse aplicando material de los libros de texto, dando un nuevo giro a viejas ideas. Sin embargo, los desafíos y limitaciones únicos de los protocolos blockchain sin permiso a menudo obligan a repensar los principios fundamentales de un problema aparentemente resuelto. Esto complica el diseño de mecanismos en web3. Pero son estos desafíos los que hacen que el diseño del mecanismo web3 sea tan 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 cripto-nativos, pero una comprensión más profunda del diseño del mecanismo debería proporcionar a todos los constructores una nueva perspectiva de 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 interesen los desafíos que plantea un entorno sin permisos.
Pero primero, lo que necesitamos saber es ¿qué es el diseño de mecanismos?
El campo del diseño de mecanismos se remonta al menos a 1961, cuando el economista de la Universidad de Columbia y futuro premio Nobel William Vickrey propuso formalmente el método de subasta sellada de segundo precio. Este método 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 fue ampliamente utilizado por los coleccionistas de sellos en el siglo XIX, pero Vickrey no lo propuso oficialmente hasta 1961. y ahora a menudo se le llama "subasta Vickrey". En el modelo de subasta de Vickery, el mejor postor gana, pero paga la segunda oferta más alta. Este tipo de subasta inspira una verdadera preferencia entre los postores y entrega el lote con la estimación más alta.
La Subasta Vickery es un diseño elegante y eficiente que se ha aplicado al mundo real, adaptándose y actualizándose a nuevas situaciones, con la práctica informando a la teoría y viceversa. Al igual que Vickery Auction, la historia del diseño de mecanismos como disciplina formal es una historia de teoría y práctica entrelazadas, que es a la vez profunda y hermosa.
A diferencia de la teoría de juegos, que establece la dimensión de la interacción estratégica y explora los resultados más razonables de las acciones, el campo del diseño de mecanismos no comienza con el juego, sino con el resultado deseado. El propósito del diseño de mecanismos es aplicar ingeniería inversa a alguna forma de juego para que el resultado deseado (quizás caracterizado por eficiencia, equidad o ciertos comportamientos) esté equilibrado. En el caso de las Subastas Vickery, el objetivo final es inducir a los participantes a pagar la cantidad máxima que estén dispuestos a pagar sin penalizarlos.
Hay muchas oportunidades de aplicación para el diseño de mecanismos en Web3. Por ejemplo, un protocolo blockchain puede desear lograr resultados en los que los participantes del protocolo se comporten con integridad (sin desviarse del comportamiento esperado). Alternativamente, es posible que un protocolo desee obtener información precisa sobre los valores de las transacciones para asignar de manera eficiente espacio en bloque a las transacciones más valiosas.
Estos problemas de diseño de mecanismos siempre son desafiantes, y los desafíos son aún más singulares en un entorno blockchain.
1. Falta de confianza
Sin una parte confiable que haga cumplir los mecanismos, diseñar en el espacio blockchain se vuelve más difícil.
El objetivo de utilizar un protocolo blockchain sin permiso es que no es necesario confiar en ninguna entidad o persona en particular, solo una suposición de confianza de "nivel promedio" de que suficientes 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 producto de decisiones unilaterales de un solo nodo.
No sabes si puedes confiar en este nodo.
Es por eso que las subastas de Vickery rara vez se ven en el espacio blockchain. Una implementación ingenua de las subastas de Vickery se encontrará rápidamente 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 de "oferta cómplice" que es ligeramente más baja que la oferta del futuro ganador, lo que obliga al ganador a pagar casi toda su oferta (en lugar de la verdadera segunda oferta más alta). .
Las ofertas falsas de productores de bloques que no son de confianza hicieron que Vickery Auctions volviera al modo de subasta de primer precio, que es una de las razones por las que las subastas de primer precio son tan comunes en web3. (La última rama de la literatura sobre diseño de mecanismos tradicionales sobre "mecanismos confiables" también considera el diseño de subastas con subastadores que no son de confianza, pero desde una perspectiva diferente).
2. A veces hay colusión
Otra razón por la que es difícil diseñar un mecanismo blockchain es que habrá colusión entre los participantes de la cadena. Por ejemplo, las subastas de segundo precio pueden fácilmente confabularse con pagos de compensación. La idea 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 haga una oferta mucho más baja.
La literatura académica sobre diseño de mecanismos no se preocupa mucho por este tema. Una razón puede ser que la colusión, especialmente con los pagos de compensación, es difícil de lograr en el mundo real. Después de la colusión, el ganador puede negarse a pagar el soborno, por lo que es difícil obtener pagos de compensación creíbles. (Como dice el refrán: "No hay derecho entre ladrones").
Sin embargo, en el contexto de blockchain, los posibles coludidores a menudo pueden utilizar contratos inteligentes para proporcionar compromisos confiables para que la colusión realmente funcione. La segunda razón es la falta de un mecanismo para inhibir la colusión con los pagos de compensación: el mecanismo de "divulgación de precios", que sólo proporciona cotizaciones y nada más.
Peor aún, los usuarios del protocolo pueden coludir no sólo entre sí sino también con productores de bloques (que no son de confianza) (el equivalente a la colusión entre postores y subastadores en una subasta del mundo real).
La resistencia a este último tipo de colusión es una de las principales motivaciones para quemar 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 de los productores de bloques), los productores de bloques y los usuarios finales pueden coludir mediante pagos de compensación y escapar de cualquier precio de reserva que el mecanismo intente imponer.
3. No podemos confiar únicamente en el Estado de derecho
Evidentemente, la cuestión de la colusión no es nueva. Ha estado afectando a la mecánica de la vida real durante siglos, pero si observa la literatura sobre diseño de mecanismos, se sorprenderá al ver lo poco que aborda. Esta literatura aborda de frente las motivaciones de los actores individuales para manipular unilateralmente los mecanismos, pero en general deja la cuestión a algún concepto aún inesperado de “estado de derecho”. Por ejemplo, los participantes en el mecanismo podrían firmar un contrato legal que estipule que no coludirán. Si se descubre colusión, se remitirá a la vía legal. Los diseñadores de mecanismos pueden ayudar creando un mecanismo que haga relativamente fácil detectar la colusión.
Hay un secreto tácito en gran parte de la literatura sobre diseño de mecanismos: la confianza en el Estado de derecho. Si bien no podemos decir que no existe un estado de derecho en el ámbito de los protocolos de blockchain sin permiso (a menudo vemos que las fuerzas del orden procesan con éxito delitos en blockchains sin permiso), el grado de estado de derecho es mucho menos común 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 solucionar el problema dentro del mecanismo. Este enfoque prevalece en las decisiones de diseño de mecanismos en el campo blockchain. Específicamente en el protocolo Ethereum, abundan los ejemplos, desde EIP-1559 quemando las ganancias de la tarifa base hasta recortando a los validadores por comportarse mal en su protocolo de consenso.
4. Espacio de diseño más grande
El espacio de diseño en web3 es mayor de lo que están acostumbrados los diseñadores de mecanismos. Por tanto, los diseñadores deben repensar cualquier problema determinado. Por ejemplo, muchos mecanismos implican pagos que, en aplicaciones de diseño de mecanismos tradicionales, se realizarían en monedas fiduciarias como el dólar estadounidense. Muchos protocolos blockchain tienen su propia moneda nativa y los mecanismos dentro del protocolo son capaces de manipular estas monedas.
Imagínese si escribiera un artículo sobre el diseño de mecanismos tradicionales y parte de la descripción de su mecanismo fuera: "Imprima un montón de moneda nueva y distribúyala a un grupo de participantes. Mirando fuera del contexto de blockchain, esto es muy absurdo". Pero cuando se habla de diseño de mecanismos en el contexto de un protocolo blockchain, definitivamente se puede hacer eso. El protocolo controla la moneda, por lo que partes de la mecánica del protocolo pueden acuñar tokens o quemar tokens.
Esto significa que algunos diseños que serían imposibles sin la moneda nativa se vuelven posibles. Por ejemplo, ¿cómo se incentiva a los mineros de Bitcoin para que realicen el protocolo según lo previsto? Incentivar a estos productores de bloques mediante recompensas inflacionarias: imprimiendo nuevas monedas (Bitcoins). Sin una moneda nativa, tal diseño sería imposible.
5. La moneda nativa puede traer otros problemas
La última razón resalta el poder de la moneda nativa. Puedes hacer dos cosas con la moneda nativa: “acuñar” (la forma en que el protocolo Bitcoin acuña nuevos Bitcoins para incentivar a los mineros) y “quemar tokens” (la forma en que el mecanismo de tarifas de transacción EIP-1559 de Ethereum quema ETH para resistir la colusión). Las monedas nativas acechan un peligro que no existe 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 razón 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 de Estados Unidos. Este es un desafío completamente nuevo en el mundo del diseño web3. ¿Qué puede salir mal? Déjame contarte dos ejemplos, uno sobre la acuñación de Bitcoin y el otro sobre la quema de ETH.
Debido al uso de recompensas en bloque (incentivos para que los mineros impriman nuevas monedas), Bitcoin se ve obligado a experimentar inflación. Por tanto, también debe tener una política monetaria correspondiente que determine la tasa de inflación y cómo evoluciona en 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 en la cantidad de Bitcoins, la tasa de inflación debe acercarse a cero.
Si la tasa de inflación es realmente cero, ¿qué debería usarse para incentivar a los mineros a continuar ejecutando el protocolo y brindar seguridad a Bitcoin? Se esperaba que las tarifas de transacción compensaran la falta de recompensas en bloque, aunque las posibilidades de que esto suceda son bastante escasas. Se sabe que si las tarifas de transacción se acercan a cero, el protocolo Bitcoin sufrirá importantes problemas de seguridad.
Los científicos informáticos de la Universidad de Princeton Miles Carlston, Harry Kalodner, Matthew Weinberg y Arvind Narayanan señalaron otra diferencia entre las tarifas de transacción y las recompensas en bloque en un artículo. Si bien la recompensa del bloque es la misma para cada bloque (al menos entre dos “reducciones a la mitad” consecutivas de la recompensa del bloque), las tarifas de transacción pueden variar en órdenes de magnitud, lo que a su vez da lugar a que el protocolo introduzca una nueva inestabilidad en la teoría de los juegos. 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 fue una fuerza inflacionaria para Bitcoin, la quema de tarifas de transacción en EIP-1559 fue una fuerza deflacionaria para Ethereum. En el protocolo Ethereum (que utiliza recompensas de validación inflacionarias), hay un tira y afloja entre estas dos fuerzas, y la deflación a menudo gana. ETH es ahora una moneda deflacionaria neta, una consecuencia macroeconómica de las decisiones de diseño motivadas microeconómicamente en el mecanismo de tarifas de transacción del protocolo.
¿La deflación es buena o mala para el protocolo Ethereum? A los poseedores de ETH les encanta 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 impulsó a la opinión pública a favor de pasar al régimen de tarifas de transacción de EIP-1559.) Sin embargo, el término deflación intimida a los macroeconomistas tradicionalmente capacitados, recordando 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 requiere una mayor exploración por parte de los investigadores de blockchain: ¿por qué una moneda deflacionaria puede servir como una criptomoneda que respalda un protocolo blockchain, pero no como una moneda fiduciaria que respalda a un estado soberano?
6. No ignores la pila subyacente
En informática, una de las cosas por las que nos esforzamos es la modularidad y las abstracciones limpias, lo que nos da la capacidad de confiar en partes de un sistema. Al diseñar y analizar una parte de un sistema, es posible que necesite conocer la funcionalidad de la salida de otras partes del sistema. Pero lo ideal es que no necesites saber cómo se implementa esta funcionalidad internamente.
En los protocolos blockchain, aún no hemos alcanzado este estado ideal. Si bien a los constructores y diseñadores de mecanismos les puede gustar centrarse en la capa de aplicación, no pueden ignorar cómo opera la capa de infraestructura y sus detalles.
Por ejemplo, si está diseñando un creador de mercado automatizado, debe considerar la posibilidad de que los productores de bloques que no son de confianza sean responsables de ordenar las transacciones. Alternativamente, cuando considera diseñar un mecanismo de tarifas de transacción para un resumen (L2), no solo tiene que pagar por el consumo de recursos 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 en una capa requiere un conocimiento detallado de las otras capas. Quizás, a medida que la tecnología blockchain madure, tendremos una clara separación de las diferentes capas. Pero ciertamente aún no hemos llegado a ese punto.
7. Requerido para trabajar en un entorno informático limitado
La "computadora en el cielo" implementada por el protocolo blockchain es un entorno informático limitado. El diseño de mecanismos tradicionales sólo se centra en incentivos económicos e ignora cuestiones computacionales (por ejemplo, el famoso mecanismo de Vickrey-Clarke-Groves no es factible para problemas de asignación altamente complejos).
Cuando Nisan y Ronen propusieron el diseño de mecanismos algorítmicos en 1999, señalaron que realmente necesitamos algún tipo de trazabilidad computacional para que los mecanismos tengan sentido práctico en el mundo real. Por lo tanto, recomiendan limitar la atención a los mecanismos de cálculo y comunicación que utilizan ciertas cantidades como extensiones de funciones polinómicas (en lugar de exponenciales) como parámetros del problema.
Dado que la máquina virtual del protocolo blockchain requiere mucha computación, los mecanismos en la cadena deben ser muy livianos: el tiempo polinómico 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 Ethereum DeFi, en lugar de soluciones más tradicionales como los libros de órdenes limitadas.
8. Aún en las primeras etapas
Normalmente, cuando la gente dice que web3 está en sus primeras etapas, se refieren a oportunidades de inversión o a adopción. Pero desde una perspectiva científica, estamos incluso antes que eso. Las cosas serán cada vez más difíciles, incluso si las oportunidades son enormes.
Todos dan por sentado los beneficios de trabajar en un campo de investigación establecido. Existen modelos y definiciones generalmente aceptados. Se alcanzó consenso sobre las cuestiones más importantes. También se desarrolló una coordinación clave en torno a la medición del progreso. Existe un vocabulario común y una amplia base de conocimiento público. También hay formas de acelerar, incluidos libros de texto rigurosamente examinados, cursos en línea y otros recursos.
Al mismo tiempo, en muchos aspectos del espacio blockchain, todavía no conocemos los modelos y definiciones "correctos" para pensar con claridad y avanzar en cuestiones importantes. Por ejemplo, ¿cuáles son los conceptos más importantes 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 sin respuesta.
Para aquellos interesados en la ciencia blockchain, la inmadurez del campo es realmente un desafío. Pero involucrarse temprano (ahora) también puede generar oportunidades únicas.
El diseño de mecanismos siempre ha sido una herramienta útil en la capa de aplicaciones de Internet, como las subastas de publicidad en tiempo real o el diseño de mercado bilateral que es omnipresente en la mayoría de las aplicaciones de consumo en línea actuales, desde el comercio electrónico hasta las compras grupales.
Pero en web3, el diseño del mecanismo también informa las decisiones de diseño sobre la propia infraestructura.
Pensemos en las décadas de 1970 y 1980, cuando todavía se discutían y diseñaban protocolos de enrutamiento de Internet. Hasta donde yo sé, ningún profesional en diseño de incentivos y mecanismos tiene un asiento en la mesa. En retrospectiva, ahora nos damos cuenta de que esa persona podría haber proporcionado información útil para el diseño. Mientras tanto, en web3, con la publicación del documento técnico original de Bitcoin, los 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 "correctas" para web3 en realidad nos está diciendo que estamos en una época dorada. Las generaciones futuras de estudiantes y científicos nos envidiarán por haber estado en el lugar correcto en el momento correcto con la oportunidad de dar forma a la trayectoria de esta tecnología. Entonces, aunque puede que no haya muchos libros de texto en esta área, algún día los habrá, y lo que se describirá en estos libros es lo que estamos haciendo ahora.
