Lo que el Libro Blanco de Bitcoin acertó, lo que no y lo que aún T

Joseph Bonneau es profesor asistente en la Universidad de Nueva York y coautor de "Bitcoin and Criptomonedas Technologies", un popular libro de texto.

Este artículo de Opinión exclusivo es parte de la serie "Bitcoin a los 10: El Libro Blanco de Satoshi" de CoinDesk.

El libro blanco de Bitcoin ha sido reconocido, con razón, como ONE de los artículos de informática más originales e influyentes de la historia.

Ha puesto en marcha una industria de mil millones de dólares y miles de artículos posteriores.

Pero vale la pena analizar críticamente el artículo (y los elementos del diseño original de Bitcoin que se omitieron) para preguntarse: ¿en qué acertó? ¿En qué se equivocó? ¿Y a qué preguntas aún no sabemos la respuesta?

Lo que Bitcoin hizo bien

Esta puede ser la categoría más difícil de compilar.

Una señal de una idea verdaderamente exitosa es que olvidamos cómo la gente pensaba sobre el mundo antes de que surgiera. Muchas de las contribuciones más fundamentales de Bitcoin parecen obvias solo en retrospectiva.

Es fácil olvidar que las Criptomonedas fueron un tema de investigación estancado durante gran parte de la década del 2000. Tras el fracaso de numerosos intentos en la década de 1990 por construir un sistema funcional (basándose principalmente en las ideas de David Chaum en la década de 1980), se publicaron pocos artículos en el área. Muchos simplemente creían que no existía un mercado viable para una moneda no estatal.

Antes de Bitcoin, los sistemas descentralizados fueron un área de investigación activa en la década de 2000 (a menudo descritos como redes peer to peer) y la investigación sobre el anonimato estaba cobrando importancia (con el desarrollo de Tor y otros sistemas).

Pero estas no se consideraban características necesarias para un sistema de pagos. ¿Qué aportó Bitcoin ?

• Incentivos para los mineros. Una de las CORE contribuciones de Bitcoin es incentivar a los mineros mediante la inflación y las comisiones. Este modelo ha tenido éxito en general, y es justo decir que pocos lo previeron. Muchos sistemas P2P de la era pre-Bitcoin que ofrecían participación abierta (cualquiera podía gestionar un nodo) se vieron afectados por ataques Sybil y otros problemas. Hubo muchos intentos de incentivar la participación honesta, pero antes de Bitcoin ningún sistema lo consiguió.
• Clientes ligeros.El soporte de Bitcoin tanto para nodos completos como para nodos ligeros (o SPV) ha demostrado ser bastante poderoso, y la estructura de bloques incorporada en Bitcoin ha hecho que no solo sea posible sino natural implementar un cliente ligero.
• Scripting.Aunque limitada, la compatibilidad con scripts de Bitcoin (que no se aborda en el libro blanco) ha permitido varias funciones útiles, como cuentas multifirma y redes de pago. Fue acertado concebir un sistema que admitiera más que simples pagos.
• Reconocer incentivos a largo plazo.Satoshi no anticipó la minería a escala industrial ni los pools de minería, al menos noen el libro blancoPero el artículo incluye una línea muy profética sobre los riesgos de la centralización: «[Un atacante] debería encontrar más rentable seguir las reglas, reglas que le favorecen con más monedas nuevas que a todos los demás juntos, que socavar el sistema y la validez de su propia riqueza». A pesar de la gran cantidad de ataques teóricos de mineros que se han escrito desde entonces, ninguno se ha llevado a la práctica seriamente. Satoshi reconoció un principio poderoso: los mineros tienen incentivos a largo plazo para no atacar, ya que invierten en la salud del ecosistema.

Lo que Bitcoin hizo mal

Ignoraremos algunas características curiosas en retrospectiva de las primeras versiones del código de Bitcoin , como el pago por dirección IP y un sistema de comercio electrónico incorporado, que nunca vieron la luz del día.

Pero hay varias características de Bitcoin que parecen "erróneas" y que ningún sistema construido hoy debería repetirlas.

• 1. Sistema Europeo de Datos de Seguridad Alimentaria (ECDSA). Si bien este algoritmo de firma era mucho mejor que, por ejemplo, RSA, es inferior a EC-Schnorr en todos los aspectos. Lo más probable es que Satoshi simplemente T esta opción (un legado de patentes de software en torno a Schnorr). Hoy en día, sería claramente ventajoso usar Schnorr en su lugar, dada su compatibilidad con la firma de umbral, o incluso con un esquema de firma más avanzado como BLS.
  2. Maleabilidad de las transacciones.Este problema involuntario ha causado problemas a protocolos como las redes de pago, además de facilitar el famoso ataque a Mt. Gox. Hoy en día, un diseño prudente utilizaría algo similar a un testigo segregado (SegWit) para garantizar que los hashes de las transacciones no sean manipulables.
  3. Características agregadas desde entonces.Obviamente, fue un error no incluir características populares como pay-to-script-hash (P2SH) y check-locktime-verify, que se agregaron desde entonces mediante bifurcaciones suaves.
  4. Divisibilidad limitada de las monedas. Bitcoin tiene un límite de 21 millones de bitcoins, pero aún más importante, tiene un límite de aproximadamente 2^52 satoshis como unidad atómica. Si Bitcoin se convirtiera en el único sistema de pago de la Tierra, proporcionaría menos de un millón de unidades por ser Human . Esto no es suficiente para abarcar tanto las transacciones diarias (incluso redondeadas al equivalente a décimas de dólar) como las grandes tenencias. Habría sido bastante económico ampliar esto con unas pocas docenas de bits adicionales, de modo que la divisibilidad nunca fuera un problema.
  5. Bloques en una cadena simple. Dado el auge de la palabra "blockchain", cabe destacar que colocar bloques en una cadena lineal es un descuido que encarece la verificación de la inclusión de un bloque antiguo en la cadena actual para un cliente ultraligero. Bitcoin coloca correctamente las transacciones en un árbol, así que ¿por qué no los propios bloques? Una lista de omisión sería otra mejora importante. Curiosamente, el proyecto de Transparencia de Certificados (diseñado independientemente de Bitcoin en la misma época) lo hace correctamente y coloca cada actualización en un árbol, mientras que pocos sucesores de Bitcoin se han desviado del diseño de la cadena lineal.
  6. Sin compromisos estatales. Todos los mineros de Bitcoin rastrean el estado del sistema como el conjunto de salidas de transacciones no gastadas (UTXO). Sin embargo, esto no se asigna a cada bloque y debe imputarse desde el historial. Esto dificulta que los clientes ligeros confirmen el estado actual y si la transacción se ha gastado. Sería bastante sencillo agregar un compromiso de UTXO a cada bloque, y muchos sistemas posteriores (como Ethereum) lo hacen.
  7. Análisis de ataque simplista. El libro blanco de Bitcoin dedica una cantidad considerable de espacio (aproximadamente una cuarta parte del texto) a analizar las probabilidades de que un minero con menos del 51 % de potencia de minado lance una bifurcación con éxito gracias a la suerte. Análisis posteriores han identificado muchos otros vectores de ataque (como la minería egoísta), y este análisis LOOKS anticuado.
  8. Una CPU, un voto. Satoshi describió Bitcoin como un sistema donde la mayoría de los participantes serían mineros que usarían sus CPU. Esto no ha sido así desde hace muchos años, ya que la minería está dominada por hardware dedicado. Si bien es discutible si la minería ASIC es un desarrollo positivo o negativo, ciertamente no es lo que se proponía en el libro blanco original.

Lo que aún no sabemos

• Rompecabezas SHA-256. El uso de pruebas computacionales basadas en hash ("prueba de trabajo") en Bitcoin ha sido ONE de los temas de debate más activos. ¿Consume demasiada energía? ¿Fomentan los ASIC la centralización? ¿Generarían las pruebas diseñadas para la minería basada en GPU o la minería limitada por almacenamiento mejores incentivos a menor costo? ¿Se WIN finalmente la prueba de participación?
• El tamaño del bloque y otros límites de parámetros.Como mínimo, el límite de bloque de 1 MB ha sido motivo de debate, al igual que (en menor medida) el intervalo de 10 minutos entre bloques. Muchos sistemas de seguimiento han prosperado con bloques más grandes o más frecuentes. ¿Resultará acertado a largo plazo el diseño conservador de Bitcoin?
• Anonimato. Los argumentos esbozados en el libro blanco sobre el anonimato que Bitcoin ofrece, ya que solo se publican claves públicas, son ahora incompletos debido al desarrollo del análisis de gráficos de transacciones. Sistemas como Transacciones Confidenciales, Monero o Zcash ofrecen mayor Privacidad criptográfica. Por otro lado, se han propuesto numerosos esquemas retrocompatibles para ofuscar la actividad en la cadena de bloques de Bitcoin mediante la mezcla. ¿Es el anonimato una característica crítica que requiere un soporte integrado que Bitcoin ignoró?
• Inflación. El diseño de Bitcoin busca evitar la inflación, pero muchos economistas han señalado que, en realidad, es deflacionario, ya que las monedas solo pueden salir de circulación cuando se pierden las claves (o cuando se vuelven inutilizables intencionalmente mediante transacciones de "prueba de quema"). La inflación cero, de hecho, requiere una pequeña emisión de nueva moneda solo para KEEP el ritmo de la moneda perdida. Si esto fue un error en Bitcoin, es posible que no nos demos cuenta durante muchos años, a medida que la inflación se reduce gradualmente.
• El cambio a las tarifas de transacción. Bitcoin programó una transición lenta: de recompensar a los mineros principalmente por inflación a recompensarlos principalmente mediante comisiones por transacción. Nadie sabe cómo se desarrollará esto, pero algunas investigaciones sugieren que podría causar una inestabilidad significativa en el mundo posinflacionario.
• Programabilidad limitada. Bitcoin impuso límites estrictos a su programabilidad para KEEP la verificación de las transacciones (y con un coste predecible). El proyecto Ethereum ha demostrado una gran demanda de un modelo de programación más completo, aunque este presenta problemas adicionales de escalabilidad. ¿Se verá perjudicado Bitcoin a largo plazo por su modelo de programación más débil?

Laberinto aéreo vía Shutterstock