Astec
Published in

Astec

Curso Rápido de Diseño de Mecanismos para Aplicaciones Criptoeconómicas

Entendiendo los principios básicos de la criptoeconomía…

Esta es una versión traducida y adaptada del texto “A Crash Course in Mechanism Design for Cryptoeconomic Applications” publicado por Alex Evan en Blockchannel el 17 de octubre de 2017.

La criptoeconomía es la combinación entre criptografía e incentivos económicos para diseñar protocolos y aplicaciones descentralizadas robustos.

Según esta corriente de pensamiento, el Bitcoin triunfó donde otros protocolos descentralizados fallaron, no por la Prueba de Trabajo, por la idea del dinero en efectivo descentralizado ni por su algoritmo de consenso, sino porque incorporó a la criptoeconomía en el núcleo de su protocolo de consenso.

La gran visión de la criptoeconomía, por tanto, es extrapolar este éxito e incorporar incentivos criptoeconómicos en todo: transacciones, computación, almacenamiento, predicciones, etc.

Las blockchains nos permiten crear escasez y facilitar la transferencia de valor en áreas en las que sería imposible de otra forma, y por lo tanto expandir radicalmente la gama de problemas a las que pueden aplicarse incentivos económicos. Los sistemas criptoeconómicos son maneras fundamentalmente nuevas de incentivar el comportamiento humano. Y su potencial es masivo.

Aunque esto puede parecer fácil en teoría, diseñar incentivos económicos es difícil. De hecho, hay una disciplina entera de la economía que se dedica a estudiar cómo diseñar protocolos que incentivan a agentes racionales a comportarse de maneras socialmente deseables.

Se llama diseño de mecanismos.

Aunque mucha tinta se ha utilizado para escribir sobre criptoeconomía, tenemos poca evidencia de que se estén incorporando métodos formales de diseño de mecanismos en la mayoría de protocolos de blockchain (con algunas excepciones notables que discutiremos más abajo).

Esto representa una oportunidad perdida. Otros lo han expresado de manera más cruda:

El propósito de este post es introducir los conceptos básicos del diseño de mecanismos y explicar su utilidad en el mundo de las criptomonedas. Si estás trabajando en un protocolo o aplicación de blockchain, esto debería darte algunos recursos introductorios para acceder a la literatura de diseño de mecanismos.

Mi deseo es que al terminar de leer este post:

1) Estés convencido de que el diseño de mecanismos es extremadamente importante para construir sistemas descentralizados robustos;

2) Estés equipado con los recursos básicos para empezar a aprender cómo utilizar herramientas de diseño de mecanismos en tu trabajo.

Para empezar, voy a realizar una breve descripción de los conceptos clave y definiciones del diseño de mecanismos. El objetivo es hacerlo de la manera más accesible posible. No buscaremos hacer una introducción formal al diseño de mecanismos. Para esto, recomiendo la lectura de alguna de las siguientes fuentes:

Este capítulo de Vincent Conitzer; este artículo de Matthew Jackson y su curso en dos partes con colaboradores; el Capítulo 7 de este texto introductorio sobre teoría de los juegos por Fundenberg y Tirole.

¿Qué es el Diseño de Mecanismos?

Una posibilidad es pensar en el diseño de mecanismos como en teoría de los juegos inversa.

En teoría de los juegos, tomamos un juego como dado y analizamos sus resultados de acuerdo a las utilidades de los jugadores. En diseño de mecanismos, empezamos definiendo resultados deseables y trabajamos “hacia atrás” para crear un juego que incentive a los jugadores para producir esos resultados.

Otra forma de verlo es pensar en la teoría de los juegos como en el costado positivo y en el diseño de mecanismos como en el lado normativo de la misma moneda.

Por ejemplo, podrías diseñar una subasta con el objetivo de asignar un bien al participante al que le genere la mayor utilidad. Suponiendo que todos derivan algo de utilidad de ese bien, los participantes tienen un incentivo a mentir.

Entonces, ¿cómo diseñar un juego que incentive a todos a reportar sus utilidades verdaderas? ¿Deberíamos implementar ofertas abiertas o cerradas? ¿Ascendentes o descendentes?

De manera equivalente: al diseñar un proceso de votación que siempre elija al candidato que todos los votantes prefieran sobre los demás candidatos, ¿deberíamos elegir a los ganadores basándonos en la pluralidad o en la mayoría? ¿Debería haber una o múltiples rondas de votación? ¿Deberían los votantes votar una única opción u ordenar sus preferencias? Estas son algunas preguntas típicas del diseño de mecanismos.

Algunas Definiciones

Formalmente, un mecanismo incluye un conjunto finito de jugadores y un conjunto de decisiones sociales potenciales.

Pensemos en un conjunto de votantes y en el grupo de potenciales candidatos que podrían ser elegidos por la sociedad. Los jugadores poseen información privada, también conocida como señales o tipos.

El tipo de cada individuo puede representar sus preferencias (como su preferencia por el candidato A sobre el B o su valoración sobre un bien ofrecido en una subasta) pero también puede utilizarse para codificar otros tipos de de información privada (por ejemplo, sólo él sabe si el bien que está siendo vendido es de alta o baja calidad).

También podemos tener cierta distribución de probabilidad entre tipos.

Pensemos en esto en el contexto del póker: tal vez no sepamos la mano que tiene cada jugador, pero podemos saber la probabilidad de que ocurra cada mano en una baraja de 52 cartas. Como la decisión “óptima” dependerá de los tipos de individuos, típicamente podemos definir una regla de decisión, que mapea los tipos de decisiones sociales.

Las utilidades de los individuos serán una función de su tipo reportado (lo que le dicen al agregador de tipos/preferencias, que podría no ser verdad), su tipo real y el resultado de la decisión.

Además, con frecuencia incluimos funciones de transferencia donde un bien transferible (un token) es utilizado para incentivar a los jugadores, típicamente capturando las externalidades que sus acciones imponen sobre otros.

Podemos entonces vislumbrar la función de elección social, que mapea los tipos reportados a los resultados con diferentes componentes monetarios y no monetarios. De esto hablamos cuando hay referencias a utilidades “semi lineales” (las preferencias son lineales en el componente monetario/transferencia).

En la práctica, como diseñadores podemos controlar la elección del mecanismo, pero no a los jugadores ni a sus tipos. Estos últimos elementos vienen dados por el entorno.

Agregar un mecanismo convierte este entorno Bayesiano en un juego. Formalmente , un mecanismo es un par de espacios de mensaje/estrategia y una función que mapea mensajes/estrategias con las decisiones sociales resultantes y las transferencias.

El mecanismo puede ser determinístico, en caso de que siempre resulte en la misma decisión y recompensas, o puede ser probabilístico/aleatorio siguiendo cierta regla.

La tarea central de un diseño de mecanismo es especificar un mecanismo que incentive a agentes racionales a comportarse de cierta forma, basándose en su información privada, que lleve a resultados socialmente deseables.

Generalmente, se dice que un mecanismo “implementa” una función de elección social si, en equilibrio, el mapeo de tipos a resultados es el mismo que el mapeo que habría sido elegido por la función de elección social.

Podemos pedir que esto sea una implementación en estrategias dominantes (donde esto es verdad para el agentes sin importar las estrategias de los demás agentes) o simplemente una implementación en equilibrio de Bayes-Nash (donde ningún agente tiene desviaciones rentables basado en sus creencias sobre los tipos y las estrategias de los otros jugadores). El primero es un supuesto mucho más fuerte, y por lo tanto más restrictivo.

Mecanismos de Vickrey-Clarke-Groves

Un conjunto de mecanismos poderosos que encontramos con frecuencia se conocen como mecanismos de Vickrey-Clarke-Groves.

Para entenderlos, primero pensemos en una subasta con un único bien en venta. Tal vez, el diseño más evidente sería hacer que todos los participantes escriban el precio que estarían dispuestos a pagar en una hoja de papel.

Una vez que se revelan las ofertas, el jugadores que haya ofrecido el precio mayor recibe el bien y paga el valor ofertado.

Pero esta no sería una solución compatible con incentivos. Cualquier jugador que ofreciera el verdadero valor que el bien tiene para él recibiría una utilidad total de cero. Por eso, un mejor mecanismo sería asignar el bien al jugador con la oferta mayor pero hacerle pagar sólo el valor de la segunda oferta.

Esto es lo que se conoce como subasta de Vickrey. En este escenario, cada jugador tiene el incentivo de ofrecer el valor exacto que el bien tiene para él.

Una generalizacion de la subasta de Vickrey es el mecanismo pivotal (también conocido como “mecanismo de Clarke” o “mecanismo VCG”). Este funciona de la manera siguiente.

Para cada individuo, corremos el mecanismo sin él y elegimos el resultado que maximiza la utilidad de todos los demás jugadores dados sus tipos reportados. Luego, incluimos al individuo y corremos nuevamente el mecanismo. Este último es el resultado elegido.

Cada jugador paga (o cobra) la diferencia entre la suma de utilidades de los demás jugadores en los dos casos. Efectivamente, este pago es equivalente al costo o beneficio social individual.

Como el individuo no tiene forma de afectar la suma de utilidades que ocurren sin él, está efectivamente tratando de maximizar la suma de su utilidad y la de todos los demás. Y esto es exactamente igual que maximizar la utilidad social total.

Este mecanismo no sólo asegura la compatibilidad de incentivos. También garantiza la eficiencia.

Aplicaciones

Ahora que hemos revisado los ingredientes básicos del diseño de mecanismos, veamos algunas aplicaciones dentro del mundo cripto.

Una de las aplicaciones más obvias y directas del diseño de mecanismos son las ventas de tokens. La teoría de las subastas es el espacio de aplicación más desarrollado del diseño de mecanismos.

Estos mecanismos también fueron estudiados exhaustivamente en el marco de las ciencias de la computación, en parte, debido a que grandes empresas de tecnología como eBay y Google derivan la mayor parte de sus ingresos de subastas online.

Si estamos planificando una venta de tokens, podremos encontrar una solución “directo de la estantería”. También podemos encontrar algunos argumentos sobre modelos en competencia de ventas de tokens aquí, aquí y aquí.

Los mercados de predicción son otro ejemplo de un área fértil para el diseño de mecanismos. En este caso, el objetivo sería especificar mecanismos que extraigan las verdaderas creencias de agentes sobre la probabilidad de ocurrencia de diferentes eventos, con el objetivo de realizar predicciones acertadas.

Esto involucra mecanismos para prevenir situaciones en que los agentes se comportan estratégicamente o intentan manipular las creencias de otros agentes para alterar los precios de mercado a su favor.

Como con las subastas, cuando consideramos las versiones descentralizadas de los mercados de predicción, surge una serie de problemas especiales. Para más información, puedes observar proyectos como Augur o Gnosis, o ver un tratamiento más teórico de estos temas aquí y aquí.

Analizando Namecoin

Este paper de Carlsten es un gran ejemplo de cómo el diseño de mecanismos puede utilizarse para estudiar sistemas descentralizados. Lo que hace que Namecoin sea apto para diseños de mecanismos es la escasez intrínseca de nombres de dominio significativos para humanos, lo que requiere un proceso adecuado de asignación de los dominios.

Los autores utilizan una serie de ideas del diseño de mecanismos para analizar en qué falló el mecanismo de distribución de Namecoin.

Uno de los mayores desafíos del diseño de mecanismos es especificar el modelo de utilidad de los usuarios y derivar objetivos de diseño claros.

Por ejemplo, si suponemos que los agentes tienen preferencias fijas e independientes para cada nombre de dominio, entonces una subasta de Vickrey tendrá un resultado eficiente.

Pero si, de manera más realista, suponemos que los agentes tienen una utilidad marginal decreciente por los nombres (ej., para Juan Pérez, la utilidad del dominio “JuanPerez” es significativamente menor después de que ya recibió el dominio “Juan_Perez”), entonces quizá podrían alcanzar resultados similares a través del mecanismo de prioridad.

Sin embargo, si incorporamos preferencias que cambian con el tiempo, el problema de diseño se vuelve muy complejo hasta el punto que es incluso difícil articular claramente cuáles deberían ser los objetivos del sistema.

El paper también analiza los efectos de diferentes elecciones en el espacio de diseño: ¿cuán fuerte debería ser el control de un individuo sobre un nombre? ¿Cómo debería asignar nombres el mercado primario? ¿Cómo se debería redistribuir el ingreso de la venta de nombres?

Plantear el espacio de diseño metódicamente de esta manera y analizar los trade-offs económicos es una herramienta indispensable para diseñar cualquier aplicación de blockchain.

Más allá de servir como un estudio de caso de cómo el diseño de mecanismos puede utilizarse para analizar sistemas descentralizados, este análisis también revela muchos caminos prácticos para mejorar Namecoin: mayores comisiones para disuadir a los “okupas”, utilizar subastas y sistemas de pricing algorítmico para reducir la diferencia entre el precio de un nombre y su verdadero valor de mercado, y un mecanismo para que los usuarios recuperen su inversión devolviendo nombres no utilizados al mercado primario.

Desafíos Abiertos: la Fundación Ethereum

Tal vez el centro de investigación más activo sobre el uso del diseño de mecanismos en cripto sea la Fundación Ethereum.

Una buena introducción es este video de Vitalik y también este deck. Son especialmente importantes los modelos de seguridad que propone y los supuestos que utiliza. Así que es útil revisarlos brevemente aquí.

Un modelo común utilizado en la investigación tradicional es el modelo de mayoría honesta, que supone que por lo menos el 51% de los participantes son esencialmente honestos.

Vitalik y otros sostienen que este puede ser un supuesto problemático. Por lo tanto, los investigadores deberían razonar sobre seguridad bajo supuestos específicos como:

  • El nivel de coordinación entre los participantes.
  • El presupuesto del atacante (la máxima cantidad de dinero que el atacante tendría que pagar).
  • El costo del ataque (el costo real incurrido por el atacante).

Podemos pensar en diferentes modelos de seguridad fuera de las mayoría honestas. Luego, podemos pensar en implementar márgenes de seguridad criptoeconómicos (el costo económico de violar ciertas garantías del protocolo) bajo los supuestos de cada modelo.

Los modelos de mayoría descoordinada suponen que los participantes del protocolo toman decisiones de manera independiente y que ningún actor controla más que un cierto porcentaje de la red (aquí suponemos que los participantes son autointeresados y no necesariamente honestos).

Los modelos de elección coordinada, por otro lado, suponen que la mayoría (o todos) los actores se están coludiendo a través de un agente o coalición de agentes.

En el modelo de ataque por soborno, los actores toman decisiones independientes, pero hay un atacante que puede incentivar a otros actores a tomar ciertas decisiones a través de sobornos condicionales.

Para un ejemplo, mira el caso de Schelling Coin que Vitalik utiliza en ambas presentaciones. En pocas palabras, en un modelo en que los pagos sólo se hacen a actores que votan con la mayoría, un atacante podría garantizar un pago fijo mayor que aquel de votar con el consenso actual a aquellos que se desvíen del consenso y terminen en la minoría.

Si tiene un elevado presupuesto, entonces el atacante podría entonces efectivamente corromper el juego. Pero su costo real sería cero, ya que ninguno de los agentes sobornados termina votando en la mayoría.

El Bitcoin y otros protocolos de Prueba de Trabajo son, al menos en teoría, vulnerables a este tipo de ataque (aunque alguien tendría que demostrar de manera creíble que tiene un presupuesto masivo).

Introduciendo la Teoría de los Juegos Cooperativos

Esta historia de Vlad Zamfir describe la evolución del pensamiento en la investigación de Proof of Stake que llevó al equipo a decidir la implementación de un sistema de depósitos de seguridad.

Recomiendo especialmente las partes 4 y 5 donde discute la teoría de los juegos cooperativos. El punto central es la observación de que “la arquitectura de blockchain es diseño de mecanismo para mercados oligopólicos”.

Es difícil negar que hay una fuerte centralización en la tenencia de criptomonedas y en el poder de minería. Esto es difícil de modelar porque la mayoría del trabajo en diseño de mecanismos está hecha desde la teoría de los juegos no cooperativos. Pero algunos de los mecanismos más ampliamente estudiados (como el mecanismo de Groves presentado más arriba) colapsa bajo supuestos de colusión entre agentes.

Afortunadamente, la teoría de los juegos cooperativos es un campo bien desarrollado. Generalmente, el objetivo es analizar qué tipos de coaliciones pueden ser creadas, cuáles son las recompensas bajo cada una de ellas (a través de una función llamada “función característica”) y cómo la coalición debería dividir su recompensa para alcanzar objetivos como la estabilidad.

Con frecuencia, pensamos en grandes coaliciones donde todos los agentes participan (todos minan en la cadena más grande de consenso) y pensamos sobre la distribución de recompensas bajo un esquema de transferencias llamado Shapley Value, donde cada individuo recibe su contribución marginal a la coalición.

También podríamos pensar en el set de imputaciones centrales donde las coaliciones de agentes no tienen un incentivo a desviarse y analizar la estabilidad según si este set está vacío/no vacío, único/no único.

Aplicaciones de Smart Contacts

Más allá de analizar la capa de consenso, la presentación de Vitalik también discute aplicaciones directas de diseños de mecanismo para smart contracts.

Por ejemplo, la subasta de Vickrey puede sufrir de una serie de desafíos en entornos cripto. Los usuarios podrían enviar múltiples ofertas y selectivamente abrir aquella que garantice la recompensa más alta. Podríamos responder implementando un depósito para disuadir a esos actores.

Pero entonces tendríamos que específicar un tamaño de depósito relativo a la oferta en el mecanismo, lo que puede destruir las características clave de la subasta de ofertas secretas y segundo premio.

El desafío que encuentra Vitalik es que el diseño de mecanismo con frecuencia depende de un intermediario de confianza para asegurar la corrección y privacidad para los jugadores. Una blockchain puede garantizar la corrección, pero no la privacidad.

En el entorno criptoeconómico, también hay típicamente más factores a especificar que en las aplicaciones tradicionales del diseño de mecanismos.

En entornos centralizados, con frecuencia pensamos en un agente central corriendo el mecanismo de tal forma que maximiza el beneficio sujeto a restricciones. Esto hace que las cosas sean mucho más simples de analizar.

En un entorno descentralizado, sin embargo, quizá tendríamos que definir un agente algorítmico que “corra” el mecanismo y tenemos que pensar cuidadosamente sobre el comportamiento de ese agente en el mecanismo así como en las implicancias sobre la política monetaria del protocolo.

Por ejemplo, si esperamos que el mecanismo viole la restricción de presupuesto: ¿debería el agente redistribuir ingreso hacia los jugadores? ¿Debería el excedente de monedas recaudados ser removido de circulación? ¿Debería el agente ser capaz de emitir nuevas monedas cuando hace transferencias a los jugadores?

Estas preguntas requieren un análisis cuidadoso, ya que las decisiones pueden introducir problemas indeseables en los incentivos de los jugadores (por ejemplo, maximizar el monto a ser distribuido podría ser un componente no trivial de su utilidad).

Reflexiones Finales

Aunque el diseño de mecanismos se ha convertido en un aspecto central de la investigación en ciencias de la computación, pocos emprendedores y desarrolladores parecen estar aplicando este tipo de pensamiento a diseñar protocolos de blockchain. Aun menos economistas académicos han empezado a estudiar seriamente las propiedades de teoría de los juegos de los protocolos de blockchain.

Dicho esto, tengo la esperanza de que, a medida que las enormes oportunidades de la criptoeconomía se vuelvan claras, estas comunidades separadas empezarán a converger. En el interín, espero que hayas encontrado a este artículo útil para introducir algunas de las herramientas y preguntas abiertas que definen las posibilidades del diseño de mecanismos criptoeconómicos.

--

--

Un blog sobre tecnología, innovación y transformación digital. Fintech, legaltech, blockchain e inteligencia artificial. Cómo los emprendedores utilizan las nuevas tecnologías para transformar las viejas industrias.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Federico Ast

Federico Ast

Ph.D. Blockchain & Legaltech Entrepreneur. Singularity University Alumnus. Founder at Kleros. Building the Future of Law. @federicoast / federicoast.com