Dinero-B
Estoy fascinado por la cripto-anarquía de Tim May. A diferencia de las comunidades tradicionalmente asociadas con la palabra “anarquía”, en una cripto-anarquía el gobierno no es temporalmente destruido sino permanentemente prohibido y permanentemente innecesario. Es una comunidad donde la amenaza de violencia es impotente puesto que la violencia es imposible, y la violencia es imposible dado que sus participantes no pueden ser enlazados a sus verdaderos nombres o localidades físicas.
Hasta ahora no está claro, ni siquiera teóricamente, cómo tal comunidad podría operar. Una comunidad está definida por la cooperación de sus participantes y una eficiente cooperación requiere un medio de intercambio (dinero) y una manera de hacer cumplir los contratos. Tradicionalmente, estos servicios han sido provistos por el gobierno o sus instituciones patrocinadas, sólo para entidades legales. En este artículo he descrito un protocolo por el cual estos servicios pueden ser provistos de y para entidades ilocalizables.
En realidad describiré dos protocolos. El primero es impráctico, dado que hace uso pesado de un canal de transmisión anónimo sincronizado e imposible de interferir. Sin embargo, motivará al segundo y más práctico protocolo. En ambos casos, asumiré la existencia de una red ilocalizable, donde los emisores y receptores son identificados sólo a través de seudónimos digitales (por ejemplo, claves públicas) y cada mensaje es firmado por su emisor y encriptado para su receptor.
En el primer protocolo, cada participante mantiene una base de datos (separada) de cuánto dinero pertenece a cada seudónimo. Estas cuentas colectivamente definen la propiedad del dinero; cómo estas cuentas son actualizadas es el tema referente a este protocolo.
- La creación del dinero. Cualquiera puede crear dinero transmitiendo la solución a un problema computacional previamente no resuelto. Las únicas condiciones son que debe ser fácil determinar cuánto esfuerzo computacional se necesitó para resolver el problema, mientras que la solución ha de tener ningún valor, ya sea práctico o intelectual. El número de unidades monetarias creadas es igual al costo del esfuerzo computacional en términos de una cesta estándar de comodidades. Por ejemplo, si un problema toma 100 horas para ser resuelto en la computadora que lo resuelve de manera más económica, mientras que se necesitan 3 cestas estándar para comprar 100 horas de tiempo computacional en ese computador en el mercado abierto, entonces tras la transmisión de la solución a ese problema todos acreditan la cuenta del emisor por 3 unidades.
- La transferencia de dinero. Si Alice (dueña del seudónimo K_A) desea transferir X unidades de dinero a Bob (dueño del seudónimo K_B), ella emitirá el mensaje “Entrego X unidades de dinero a K_B”, firmado por K_A. Tras la transmisión de este mensaje, se debitan X unidades de la cuenta de K_A, acreditando X unidades a la cuenta de K_B, a no ser que esto creara un balance negativo en la cuenta de K_A, en cuyo caso el mensaje es ignorado.
- El efecto de los contratos. Un contrato válido debe incluir una máxima reparación en caso de incumplimiento para cada participante del mismo. Debería también incluir una parte que sirva como árbitro en caso de que haya una disputa. Todas las partes incluidas en un contrato, incluyendo el árbitro, deben de transmitir sus firmas para el mismo antes que este se vuelva efectivo. Tras la transmisión del contrato y todas las firmas, cada participante debita de la cuenta de cada parte por la cantidad de su reparación máxima, acreditando a una cuenta especial identificada por un trozo (hash) seguro del contrato por la suma de las máximas reparaciones. El contrato se vuelve efectivo si el débito por cada parte es exitoso, sin producir un balance negativo. Un contrato de muestra puede verse así:
K_A acuerda enviar a K_B la solución al problema P antes de las 0:0:0 el 1/1/2000.
K_B acuerda pagar a K_A 100 UM (unidades monetarias) antes de las 0:0:0 1/1/2000.
K_C acuerda ser el árbitro en caso de disputa. K_A acuerda pagar un máximo de 1000 UM en caso de incumplimiento. K_B acuerda pagar un máximo de 200 UM en caso de incumplimiento. K_C acuerda pagar un máximo de 500 UM en caso de disputa.
- La conclusión de contratos. Si un contrato concluye sin disputa, cada parte emite un mensaje firmado “El contrato con SHA-1, trozo H, concluye sin reparaciones.” O, posiblemente “El contrato con SHA-1 trozo H concluye con las siguientes reparaciones:…” Tras la transmisión de todas las firmas, cada participante acredita la cuenta de cada parte por el monto de su reparación máxima, remueve la cuenta del contrato, luego acredita o debita la cuenta de cada participante acordando el calendario de reparación, si es que existe alguno.
- La aplicación de contratos: Si los participantes de un contrato no pueden acordar una conclusión apropiada, incluso con la ayuda de un árbitro, cada participante transmite un calendario de reparaciones/multas sugerido y cualquier discusión o evidencia en su favor. Cada participante toma una determinación respecto a las reparaciones y/o multas concretas y modifica sus cuentas acorde a esto.
En el segundo protocolo, las cuentas de quién tiene cuánto dinero son mantenidas por un subconjunto de participantes (llamados servidores de ahora en adelante), en vez de todos. Estos servidores están enlazados a un canal de transmisión similar al estilo de Usenet. El formato de mensajes de transacción emitidos en este canal se mantiene igual que en el primer protocolo, pero los participantes afectados por cada transacción deberán verificar que el mensaje ha sido recibido y exitosamente procesado por un subgrupo de servidores seleccionado aleatoriamente.
Dado que los servidores han de ser confiables hasta cierto punto, algún mecanismo será necesario para mantenerlos honestos. A cada servidor se le requiere depositar una cierta cantidad de dinero en una cuenta especial para ser usado como multas potenciales o recompensas por pruebas de mala conducta. Además, cada servidor deberá de publicar periódicamente y comprometerse a su actual base de datos de creación y propiedad de dinero. Cada participante debería verificar que sus propios balances de cuenta son correctos y que la suma de los balances de cuenta no es mayor que la cantidad total de dinero creado. Esto previene que los servidores, incluso en casos de colusión total, expandan permanentemente y sin costo el suministro de dinero. Nuevos servidores también pueden utilizar las bases de datos publicadas para sincronizarse con los servidores existentes.
El protocolo propuesto en este artículo permite que entidades de seudónimos ilocalizables cooperen entre sí más eficientemente, al entregarles un medio de intercambio y un método de reforzar contratos. El protocolo puede probablemente ser más eficiente y seguro, pero espero que este sea un paso adelante hacia hacer de la cripto-anarquía una posibilidad tan práctica como teórica.
Apéndice A: creación de dinero-b alternativo
Una de las partes más problemáticas en el protocolo de dinero-b es la creación del dinero. Esta parte del protocolo requiere que todos los poseedores de cuentas decidan y acuerden el costo de cómputos particulares. Desafortunadamente, puesto que la tecnología computacional tiende a avanzar rápidamente y no siempre de manera pública, esta información puede no estar disponible, ser incorrecta o desfasada, todos estos factores pueden causar serios problemas para el protocolo.
Entonces, propongo un subprotocolo alternativo de creación de dinero, en el cual los poseedores de cuentas (todos aquellos en el primer protocolo, o los servidores en el segundo protocolo) en vez, decidan y acuerden la cantidad de dinero-b a ser creada en cada período, siendo el costo de la creación de ese dinero determinada por una subasta. Cada período de creación de dinero se divide en cuatro fases, como sigue:
- Planificación. Los poseedores de la cuenta computan y negocian entre sí para determinar un aumento óptimo en el suministro de dinero para el siguiente período. Haya o no consenso entre los poseedores de la cuenta, cada uno de ellos transmitirá su cuota de creación de dinero y cualquier cálculo macroeconómico hecho para respaldar las cifras.
- Licitación, Cualquiera que quiera crear dinero-b transmite una licitación en la forma de <x, y> donde x es la cantidad de dinero-b que quiere crear y y es un problema no resuelto de una clase de problemas predeterminados. Cada problema en esta clase debería de tener un costo nominal (en MIPS-por tantos años) la cual se acuerda públicamente.
- Computo. Después de ver las licitaciones, aquellos que licitaron en la fase establecida pueden ahora resolver los problemas en sus licitaciones y emitir las soluciones.
- Creación del dinero. Cada poseedor de cuenta acepta la licitación más alta (entre aquellos que realmente emitieron soluciones) en términos de coste nominal por unidad de dinero-b creada y acredita las cuentas de los licitadores de forma acorde.
Fuente: https://nakamotoinstitute.org/b-money/