Nota: Esta página está seriamente desactualizada y en gran parte sin mantenimiento; debido a incidentes pasados de edición-agresión no ha sido sometida a mucha revisión por pares.
Un nodo completo de Bitcoin podría ser modificado para escalar a tasas de transacción mucho más altas que las que se ven hoy en día, asumiendo que dicho nodo se ejecuta en servidores de alta gama en lugar de un escritorio. Bitcoin fue diseñado para soportar clientes ligeros que sólo procesan pequeñas partes de la cadena de bloques (ver verificación de pagos simplificada más abajo para más detalles sobre esto).
Por favor, tenga en cuenta que esta página existe para dar cálculos sobre la escalabilidad de un nodo completo de Bitcoin y las transacciones en la cadena de bloques sin tener en cuenta la seguridad de la red y la descentralización. No pretende discutir la escalabilidad de protocolos alternativos o intentar resumir debates filosóficos. Cree páginas alternativas si quiere hacer eso.
Nota a los lectores
Cuando los técnicos oyen hablar de cómo funciona bitcoin se detienen con frecuencia en la palabra «inundación» y dicen «¡Dios mío, eso no puede escalar!». El propósito de este artículo es tomar un ejemplo extremo, la tasa máxima de transacciones de Visa, y mostrar que bitcoin podría alcanzar técnicamente ese tipo de tasa sin ningún tipo de razonamiento cuestionable, cambios en el diseño del núcleo o superposiciones inexistentes. Como tal, es simplemente un ejemplo extremo – no un plan de cómo bitcoin crecerá para hacer frente a necesidades más amplias (como un sistema descentralizado es el público que usa bitcoin quien decidirá cómo crece bitcoin) – es sólo un argumento que muestra que el diseño del núcleo de bitcoin puede escalar mucho mejor de lo que una persona inteligente podría suponer al principio.
Dan critica con razón el análisis presentado aquí- señalando que operar a esta escala reduciría significativamente la naturaleza descentralizada de bitcoin: Si tienes que tener muchos terabytes de espacio en disco para ejecutar un nodo de «validación completa» entonces menos gente lo hará, y todos los que no lo hagan tendrán que confiar en que los que lo hagan sean honestos. Dan parece (por sus diapositivas) haber ido demasiado lejos con ese argumento: parece sugerir que esto significa que los bitcoins serán controlados por el tipo de bancos centrales que son comunes hoy en día. Su análisis falla por dos razones (y la segunda es culpa de que esta página es un poco engañosa):
Primero, incluso a la escala astronómica presentada aquí la capacidad requerida está bien dentro del ámbito de los individuos privados (ricos), y ciertamente lo sería en algún momento futuro cuando se requiera ese tipo de capacidad. Un sistema que pone a los particulares, o al menos a pequeños grupos de particulares, en pie de igualdad con los bancos centrales difícilmente podría llamarse centralizado, aunque sería menos descentralizado que el bitcoin que tenemos hoy. El sistema tampoco podría llegar a este tipo de escala sin que los usuarios de bitcoin se pusieran de acuerdo colectivamente para aumentar el tamaño máximo de los bloques, por lo que no es un resultado que pueda ocurrir sin el consentimiento de los usuarios de bitcoin.
En segundo lugar, y más importante, el supuesto escalado descrito aquí trata de que Bitcoin sustituya a la visa. Esta es una mala comparación porque el bitcoin por sí solo no es un sustituto perfecto de la visa por razones completamente ajenas al escalamiento: Bitcoin no ofrece transacciones instantáneas, ni crédito, ni varios mecanismos antifraude (que algunos quieren, aunque no todos), por ejemplo. Bitcoin es un sustituto más completo de los cheques, las transferencias bancarias, los giros postales, las monedas de oro, los certificados de depósito, las cuentas de ahorro, etc. y, si se adopta de forma generalizada, probablemente sustituya los usos de las tarjetas de crédito, que estarían mejor servidos por estas otras cosas si funcionaran mejor en línea.
Los usuarios de Bitcoin a veces pasan por alto este hecho con demasiada rapidez porque la gente se apresura a calificarlo de defecto, pero esto es injusto. Ningún sistema es ideal para todos los usos y Bitcoin tiene un espectro más amplio de cualidades que la mayoría de los instrumentos monetarios. Si la comunidad bitcoin no está dispuesta a señalar que algunas cosas se harían mejor con otros sistemas, entonces es fácil hacer argumentos de paja: Si admitimos que bitcoin puede ser usado como cera para el suelo y como cobertura del desierto, siempre habrá alguien que señale que no es la mejor cera para el suelo o la mejor cobertura del desierto.
Es trivial construir sistemas de procesamiento de pagos y de crédito _sobre_ bitcoin, tanto los clásicos (¡como la propia Visa!) como los «descentralizados» como Lightning. Estos sistemas podrían manejar mayores volúmenes de transacciones con menores costes, y liquidar con frecuencia al bitcoin que los respalda. Podrían utilizar otras técnicas con diferentes compensaciones que el bitcoin, pero seguirían estando respaldados y denominados por el bitcoin, por lo que seguirían disfrutando de su falta de control central. Vemos los inicios de esto hoy en día con los servicios de intercambio de bitcoins y carteras que permiten los pagos instantáneos entre los miembros.
Estos servicios obtendrían el beneficio de la moneda bitcoin estable y resistente a la inflación, los usuarios obtendrían los beneficios de las transacciones instantáneas, el crédito y la lucha contra el fraude, bitcoin en general disfrutaría de una escala mejorada por el volumen de transacciones descargado sin comprometer su naturaleza descentralizada. En un mundo en el que el bitcoin fuera ampliamente utilizado, los sistemas de procesamiento de pagos probablemente tendrían precios más bajos porque tendrían que competir con las transacciones de bitcoin en bruto, también podrían permitirse un precio más bajo porque la liquidación frecuente de bitcoin (y las transacciones de custodia de bitcoin de confianza cero) reducirían su riesgo. Esto es doblemente cierto porque bitcoin podría escalar para reemplazarlos por completo, incluso si eso no sería la mejor idea debido a la reducción resultante en la descentralización.
Objetivos de escalabilidad
VISA maneja en promedio alrededor de 2.000 transacciones por segundo (tps), por lo que llama a una tasa máxima diaria de 4.000 tps. Tiene una capacidad máxima de alrededor de 56.000 transacciones por segundo, sin embargo, en realidad nunca utilizan más de un tercio de esto, incluso durante los períodos pico de compras.
PayPal, por el contrario, gestionó unos 10 millones de transacciones al día para una media de 115 tps a finales de 2014.
Tomemos 4.000 tps como objetivo inicial. Obviamente, si queremos que Bitcoin escale a todas las transacciones económicas del mundo, incluyendo el dinero en efectivo, sería mucho más alto que eso, quizás más en la región de unos cientos de miles de tps. Y la necesidad de ser capaces de soportar ataques DoS (con los que VISA no tiene que lidiar) implica que querríamos escalar mucho más allá de las tasas máximas estándar. Aun así, elegir un objetivo nos permite hacer algunos cálculos básicos aunque sea un poco arbitrario.
Hoy en día la red Bitcoin está restringida a una tasa sostenida de 7 tps debido a que el protocolo bitcoin restringe el tamaño de los bloques a 1MB.
CPU
El protocolo tiene dos partes. Los nodos envían mensajes «inv» a otros nodos diciéndoles que tienen una nueva transacción. Si el nodo receptor no tiene esa transacción la solicita con un getdata.
El gran coste es la criptografía y las búsquedas en la cadena de bloques que implica la verificación de la transacción. Verificar una transacción significa algunos hashing y algunas verificaciones de firmas ECDSA. RIPEMD-160 corre a 106 megabytes/seg (llámalo 100 para simplificar) y SHA256 es más o menos lo mismo. Así que el hashing de 1 megabyte debería tomar alrededor de 10 milisegundos y el hashing de 1 kilobyte tomaría 0,01 milisegundos – lo suficientemente rápido como para que podamos ignorarlo.
Bitcoin es actualmente capaz (con un par de optimizaciones simples que son prototipos pero no se han fusionado todavía) de realizar alrededor de 8000 verificaciones de firmas por segundo en un procesador Intel Core i7-2670QM 2.2Ghz de cuatro núcleos. El número medio de entradas por transacción es de alrededor de 2, por lo que debemos reducir la tasa a la mitad. Esto significa que 4000 tps son fácilmente alcanzables en cuanto a la CPU con una sola CPU bastante normal.
Como podemos ver, esto significa que mientras a los nodos de Bitcoin se les permita maximizar al menos 4 núcleos de las máquinas en las que se ejecutan, no nos quedaremos sin capacidad de CPU para la comprobación de firmas a menos que Bitcoin esté manejando 100 veces más tráfico que PayPal. A finales de 2015 la red está manejando 1,5 transacciones/segundo, así que incluso asumiendo un enorme crecimiento en popularidad no alcanzaremos este nivel durante mucho tiempo.
Por supuesto, Bitcoin hace otras cosas más allá de la comprobación de firmas, la más obvia, gestionar la base de datos. Usamos LevelDB que hace la mayor parte del trabajo pesado en un hilo separado, y es capaz de cargas de lectura/escritura muy altas. En general, el uso de la CPU de Bitcoin está dominado por ECDSA.
Red
Supongamos una tasa media de 2000tps, así que sólo VISA. Las transacciones varían en tamaño de alrededor de 0,2 kilobytes a más de 1 kilobyte, pero es un promedio de medio kilobyte hoy.
Eso significa que usted necesita para mantenerse al día con alrededor de 8 megabits / segundo de datos de la transacción (2000tps * 512 bytes) / 1024 bytes en un kilobyte / 1024 kilobytes en un megabyte = 0,97 megabytes por segundo * 8 = 7,8 megabits / segundo.
Este tipo de ancho de banda ya es común incluso para las conexiones residenciales hoy en día, y está ciertamente en el extremo inferior de lo que los proveedores de colocación esperarían proporcionarle.
Cuando se resuelven los bloques, el protocolo actual enviará las transacciones de nuevo, incluso si un compañero ya lo ha visto en el momento de la difusión. Arreglar esto para que los bloques sean sólo listas de hashes resolvería el problema y haría que el ancho de banda necesario para la difusión de bloques fuera insignificante. Así que, aunque esta optimización no está completamente implementada hoy en día, no consideramos el ancho de banda de transmisión de bloques aquí.
Almacenamiento
Con tasas de transacción muy altas, cada bloque puede tener un tamaño de más de medio gigabyte.
No es necesario para la mayoría de los nodos de validación completa almacenar toda la cadena. En el documento de Satoshi se describe la «poda», una forma de eliminar los datos innecesarios sobre las transacciones que se gastan por completo. Esto reduce la cantidad de datos que se necesitan para un nodo de validación completa a sólo el tamaño de la salida actual no gastada, más algunos datos adicionales que se necesitan para manejar re-orgs. A partir de octubre de 2012 (bloque 203258) ha habido 7.979.231 transacciones, sin embargo, el tamaño del conjunto de salida no gastado es menos de 100MiB, que es lo suficientemente pequeño como para caber fácilmente en la memoria RAM incluso para ordenadores bastante antiguos.
Sólo un pequeño número de nodos de archivo necesitan almacenar la cadena completa que se remonta al bloque génesis. Estos nodos pueden usarse para arrancar nuevos nodos de validación completa desde cero, pero por lo demás son innecesarios.
El principal factor limitante en el rendimiento de Bitcoin son las búsquedas de disco una vez que el conjunto de salida de transacciones no gastadas deja de caber en la memoria. Una vez que los discos duros se eliminen gradualmente en favor de los SSD, es muy posible que el acceso al conjunto UTXO nunca se convierta en un cuello de botella serio.
Optimizaciones
La descripción anterior se aplica al software actual con sólo pequeñas optimizaciones asumidas (del tipo que puede y ha sido hecho por un hombre en unas pocas semanas).
Sin embargo, existe la posibilidad de realizar optimizaciones aún mayores en el futuro, a costa de cierta complejidad adicional.
CPU
Existen algoritmos para acelerar la verificación por lotes sobre firmas de curvas elípticas. Es posible verificar sus firmas simultáneamente para un speedup de 2x. Esta es una implementación algo más compleja.
Verificación de pagos simplificada
Es posible construir una implementación de Bitcoin que no verifique todo, sino que se base en la conexión a un nodo de confianza, o ponga su fe en la alta dificultad como un proxy para la prueba de validez. bitcoinj es una implementación de este modo.
En el modo de verificación de pago simplificado (SPV), llamado así por la sección del documento de Satoshi que lo describe, los clientes se conectan a un nodo completo arbitrario y descargan sólo las cabeceras de los bloques. Verifican que las cabeceras de la cadena se conectan correctamente y que la dificultad es lo suficientemente alta. A continuación, solicitan al nodo remoto transacciones que coincidan con determinados patrones (es decir, pagos a sus direcciones), que proporciona copias de esas transacciones junto con una rama Merkle que las vincula al bloque en el que aparecieron. Esto explota la estructura del árbol de Merkle para permitir la prueba de inclusión sin necesitar el contenido completo del bloque.
Como una optimización adicional, las cabeceras de los bloques que están enterradas a suficiente profundidad pueden ser desechadas después de algún tiempo (por ejemplo, usted sólo necesita almacenar hasta 2016 cabeceras).
El nivel de dificultad requerido para obtener la confianza de que el nodo remoto no le está alimentando con transacciones ficticias depende de su modelo de amenaza. Si te conectas a un nodo que se sabe que es fiable, la dificultad no importa. Si quieres elegir un nodo aleatorio, el coste para un atacante de minar una secuencia de bloques que contenga una transacción falsa debería ser mayor que el valor que se obtendría al defraudarte. Cambiando la profundidad a la que debe estar el bloque, se puede compensar el tiempo de confirmación frente al coste de un ataque.
Los programas que implementan este enfoque pueden tener una sobrecarga de almacenamiento/red fija en el caso nulo de no uso, y un uso de recursos proporcional a las transacciones recibidas/enviadas.
Ver también: Thin Client Security.
Trabajo relacionado
Hay algunas propuestas para optimizar la escalabilidad de Bitcoin. Algunas de ellas requieren una alt-chain / hard fork.
- Compresión definitiva de la blockchain – la idea de que la blockchain puede ser comprimida para lograr «nodos lite libres de confianza»
- El documento Finite Blockchain que describe la división de la blockchain en tres estructuras de datos, cada una mejor adaptada a su propósito. Las tres estructuras de datos son un blockchain finito (mantiene N bloques en el pasado), un «árbol de cuentas» que mantiene el balance de cuentas para cada dirección con un balance distinto de cero, y una «cadena de pruebas» que es una versión reducida (siempre creciente) del blockchain.
- Lightning Network, un protocolo alternativo para la compensación de transacciones en el que los nodos establecen canales de micropagos entre sí y se asientan en la cadena de bloques ocasionalmente. Los usuarios ordinarios interactúan principalmente o sólo con los canales de pago y sólo utilizan la cadena de bloques para las grandes transferencias y el almacenamiento en frío.
