Rendimiento y escalabilidad de la blockchain de Bitcoin

Bitcoin es un sistema de dinero electrónico descentralizado que hace posible el pago peer-to-peer sin pasar por un intermediario. El software original de Bitcoin fue desarrollado por Satoshi Nakamoto, y publicado bajo la licencia MIT en 2009, después de la publicación del reporte de Bitcoin, Bitcoin: A Peer-to-Peer Electronic Cash System. Bitcoin es la primera implementación exitosa de una criptomoneda distribuida. Diez años después del nacimiento de Bitcoin, en diciembre de 2019, cuenta con unos 18 millones de bitcoins en circulación y ha alcanzado unos 132,000 millones de capitalización de mercado.

En Bitcoin, una transacción es un conjunto de entradas y salidas que transfieren la propiedad de bitcoins entre pagador y beneficiario. Las entradas indican a la red de qué moneda o monedas se extraerá el pago. Esas monedas en la entrada tienen que estar sin gastar, lo que significa que no han sido utilizadas para pagar a otra persona.

Las salidas proporcionan los importes gastables de bitcoins que el pagador se compromete a pagar a los beneficiarios. Una vez realizada la transacción, las salidas se convierten en los importes no gastados para el beneficiario; permanecen sin gastar hasta que el beneficiario actual paga a otra persona con la moneda.

Cuando, por ejemplo, Alice necesita pagar a Bob 10 BTC, Alice abre su billetera Bitcoin, y escanea o copia la dirección de la transacción de Bob y crea una transacción con un pago de 10 BTC a Bob. Una vez que la transacción está firmada de forma digital y enviada, se envía a la red de blockchain de Bitcoin:

Una vez que la transacción se emite a la red de Bitcoin, el nodo contable, normalmente un nodo completo en una red P2P que recibe las transacciones, la validará según las reglas del protocolo de Bitcoin. Si la transacción es válida, el contable la agregará al pool de transacciones y transmitirá la transacción a los compañeros de la red. En una red de Bitcoin, cada 10 minutos, un subconjunto de nodos de la red, llamados “nodos de minería” o mineros, recogerán todas las transacciones válidas del pool de transacciones y crearán los bloques candidatos. También crean una transacción de Coinbase para ellos mismos para ser recompensados y cobrar las tarifas de transacción, en el caso de que ganen la carrera de minería y agreguen el bloque a la cadena, todos los nodos verificarán el nuevo bloque y lo agregarán a su propia copia de la blockchain. Mágicamente, Bob podrá ver el pago de Alice y 10 BTC en su billetera.

Una de las mayores preocupaciones en la red Bitcoin, o en general para cualquier blockchain basada en PoW es la escalabilidad. Por diseño, cada transacción tiene que ser verificada por todos los nodos, y se tarda una media de 10 minutos en crear un nuevo bloque con el tamaño de bloque limitado a 1 MB. El tamaño de los bloques y los límites de frecuencia restringen aún más el rendimiento de la red. Como resultado, un bloque de bitcoin puede albergar una media de 2,700 transacciones.

Con los sistemas de pago actuales, VISA es capaz de gestionar una media de unas 2,000 transacciones por segundo (tps), el pico diario es de unas 4,000 tps. PayPal gestionó una media de 115 tps a finales de 2014, unos 10 millones de transacciones al día.

Está claro que alcanzar una capacidad similar a la de Visa en la red de Bitcoin no es factible hoy en día. Para lograr el mayor rendimiento de la red y una mejor escalabilidad, se requiere aumentar el límite de procesamiento de transacciones de la red y realizar las mejoras de software para la red de Bitcoin.

Existe el trilema de la escalabilidad de la blockchain en cuanto a su capacidad para abordar la escalabilidad, la descentralización y la seguridad, sin comprometer ninguna de ellas. El trilema afirma que es casi imposible conseguir las tres propiedades en un sistema de blockchain.

El siguiente diagrama es una ilustración del trilema de la escalabilidad en la blockchain:

El reto desafío de la escalabilidad es encontrar una manera de lograr las tres en la capa base. Las opciones de diseño de Bitcoin favorecen la descentralización y la seguridad, pero sacrifican la escalabilidad.

Soluciones de escalabilidad de Bitcoin

Hay muchas propuestas de soluciones de escalabilidad de Bitcoin, que pueden dividirse en escalado en la cadena y escalado fuera de la cadena.

Escalado en la cadena

Las soluciones en cadena, a veces también llamadas soluciones de capa 1, consisten en buscar soluciones para resolver los problemas de escalabilidad y rendimiento en la capa base de la red de blockchain de Bitcoin. Con el escalado en la cadena, se refiere a la solución de la latencia de la red. Proporciona una forma de poder manejar más transacciones en la blockchain, SegWit es un ejemplo de esto al procesar más transacciones en un bloque de 1 MB. O bien simplemente aumentando el tamaño del bloque, como hizo Bitcoin Cash.

SegWit

SegWit es una propuesta de mejora de Bitcoin número BIP14, es la abreviatura de testigo segregado (SegWit), que significa separar la firma digital de la transacción. Fue presentado por primera vez por el desarrollador Pieter Wiulle en la conferencia Scaling Bitcoin en diciembre de 2015. El propósito de SegWit era evitar la maleabilidad de las transacciones de Bitcoin no intencionadas, permitir la transmisión opcional de datos y eludir ciertas restricciones del protocolo.

Una transacción de bitcoin se compone de tres cosas: una entrada de transacción, una salida de transacción y un importe con firmas digitales.

La entrada de la transacción es la dirección de Bitcoin de quien la envió.

La salida de la transacción es la dirección de Bitcoin de quien la recibe.

El importe es el importe de Bitcoin que fue enviado con una firma digital que verifica que el remitente es elegible para enviar las monedas.

El identificador de la transacción cambia si la firma digital cambia. Resulta que el código de Bitcoin permite que las firmas digitales sean alteradas cuando una transacción está todavía sin confirmar. Una vez que una transacción se agrega a la red, la transacción, incluida la firma, se vuelve inmutable. La alteración de la firma se hace de manera que si se ejecuta una comprobación matemática sobre ella, sigue siendo válida por la red. Sin embargo, cuando se ejecuta un algoritmo de hashing sobre ella, da un resultado diferente.

Veamos un ejemplo,

Entrada:

Transacción anterior: p9k5ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6

Índice: 0

scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10

90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Salida:

Valor: 2000000000

scriptPubKey: OP_DUP OP_HASH160 201371705fa9bd789a2fcd52d2c580b65d35549d

OP_EQUALVERIFY OP_CHECKSIG

La entrada en esta transacción importa 20 BTC desde la salida #0 en la transacción p9k5e... Luego la salida envía 20 BTC a una dirección de Bitcoin (expresada aquí en hexadecimal 2013... en lugar de la base58 normal). Cuando el receptor quiera gastar este dinero, hará referencia a la salida #0 de esta transacción en una entrada de su propia transacción.

• Transacción anterior: identificador de la transacción anterior a la dirección A;

• Índice: número de entrada (aquí tenemos solo un número de entrada 0);

• scriptSig: primera parte del script de validación (contiene la firma de la transacción);

• Valor: la cantidad de bitcoins a enviar en satoshi (un bitcoin = 100 millones de satoshi), 20 bitcoins en el ejemplo;

• scriptPubKey: segunda parte del script de validación, que también contiene la dirección del receptor B.

Para verificar que se puede gastar el importe de la transacción anterior, es necesario comprobar combinar el scriptSig de una nueva transacción con el scriptPubKey de la transacción anterior, para asegurarse de que el resultado es verdadero y válido. scriptPubKey simplemente comprueba la igualdad de la clave pública y la validez de la firma, OP_CHECKSIG.

En una transacción de Bitcoin, TXID es un hash sha256d de todos los campos de los datos de la transacción. El valor de la TXID depende de scriptSig.

Durante una transacción de proceso de un nodo minero, el nodo puede mutar scriptSig que la firma seguirá siendo válida, la transacción tendrá el mismo efecto, pero la TXID cambiará.

Por ejemplo, uno puede agregar una operación OP_NOP (que no hace nada). O para una mayor sofisticación, uno puede agregar dos operaciones: OP_DUP OP_DROP (la primera duplica la firma en la pila, y la segunda la elimina de nuevo). La firma sigue siendo válida, pero la TXID cambia.

Otro ejemplo como el valor de la firma era “3”, pero podemos cambiarlo por “03” o “3+7-7”. Matemáticamente, sigue siendo el valor de la transacción con una firma válida, pero hay diferentes resultados de hash ya que el hashing depende de cómo se escribe el valor y no del valor en sí.

Un id de transacción mutable para una transacción existente puede ser problemático por varias razones:

Si quieres construir soluciones de segunda capa sobre la red de Bitcoin, como la red, necesitas asegurarte de que nadie puede alterar la primera capa ya que se apoya en ella.

Modificar la TXID puede causar problemas si estás gastando o aceptando fondos no confirmados.

Cómo resuelve SegWit el problema:

En SegWit, toda la información maleable está separada de la transacción en un “dato testigo” separado. Al calcular la TXID, no se incluirá esta información maleable, en este caso, el identificador nunca podrá cambiar, los problemas se solucionarán. Este es un ejemplo de salida de transacciones de SegWit:

Índice 0

Detalles

Salida

Dirección

35SegwitPieWKVHieXd97mnurNi8o6CM73

Valor

1.00200000 BTC

Pkscript

OP_HASH160

2928f43af18d2d60e8a843540d8086b305341339

OP_EQUAL

Sigscript

0014a4b4ca48de0b3fffc15404a1acdc8dbaae226955

Testigo

30450221008604ef8f6d8afa892dee0f31259b6ce02dd70c545cfcfed8148179971876c54a022076d771d6e91bed212783c9b06e0de600fab2d518fad6f15a2b191d7fbd262a3e01

039d25ab79f41f75ceaf882411fd41fa670a4c672c23ffaf0e361a969cde0692e8

Podemos ver que hay información testigo, los datos incluyen toda la información maleable. Los sigscript tienen mucha menos información de hash en comparación con el ejemplo anterior sin la transacción SegWit. Esto también significa que reduce el tamaño de una transacción de Bitcoin y mejora la velocidad de las transacciones al eliminar los datos del testigo de la porción original y agregarlos como una estructura separada al final.

Estos son algunos beneficios con SegWit:

Rendimiento de los nodos: al reducirse el tamaño de la transacción, la red de Bitcoin está menos congestionada, por lo que los nodos pueden verificar los bloques, o las transacciones, más rápido.

Maleabilidad de la transacción: como hemos comentado, con SegWit, la firma se traslada de los datos de la transacción a un bloque de datos testigo. La ID de transacción (TXID) es inmutable y protege los datos de la transacción de ser pirateados.

Escalado lineal de las operaciones de hashing de la firma: al reducir el tamaño de la transacción, podemos agregar más datos de transacción para una determinada transacción como un lote. SegWit separa las firmas de las transacciones de los datos de las mismas, de modo que cada byte de una transacción solo necesita ser sometido a hashing dos veces como máximo.

Mayor seguridad para las transacciones con múltiples firmas: SegWit proporciona dos scripts diferentes; uno a una clave pública y otro dirige los pagos a un hash de script. Con la combinación de estos scripts, SegWit aumenta la seguridad al permitir una transacción con múltiples firmas.

Desarrollo superior: SegWit es ideal para el desarrollo de Bitcoin de protocolos de segunda capa, como su Lightning Network. La activación de SegWit también impulsó el trabajo de desarrollo de otras características como MAST (que permite contratos inteligentes de Bitcoin más complejos), firmas Schnorr (que permitiría otro aumento de la capacidad de transacción) y TumbleBit (una red anónima de capa superior).

Protege Lightning Network: los canales de micropagos de Lightning Network se basan en transacciones con doble firma para bloquear los depósitos iniciales. Para iniciar un pago en Lightning Network, los fondos de ambas partes se envían a una dirección con doble firma. Para evitar trampas, la transacción debe estar firmada por ambas partes antes de que se envíen los fondos allí. Ambas partes deben sincronizarse para recopilar los resultados de las transacciones en la blockchain principal. Esta ID de transacción necesaria es inmutable, ahí es donde SegWit viene al rescate.

SegWit, en teoría, puede duplicar el rendimiento de Bitcoin a aproximadamente seis TPS. Si bien es muy importante para la mejora de la red de Bitcoin, esta duplicación teórica del rendimiento de las transacciones sigue siendo demasiado baja para el uso generalizado de Bitcoin como sistema de pago.

Tamaño del bloque

Otra propuesta para mejorar la escalabilidad de Bitcoin en la cadena es aumentar el tamaño de los bloques. La idea es superficialmente simple: aumentar el tamaño de los bloques de los actuales 1 MB a, por ejemplo, 8 MB, multiplicaría por ocho el rendimiento de las transacciones. Algunas de las altcoins, como Bitcoin Cash. Los bloques de BCH eran inicialmente de 8 MB, actualmente un bloque de BCH está en 32 MB. Esto es similar al enfoque de escalado vertical para agregar más transacciones en un bloque. Sin embargo, aumentar el tamaño de los bloques significa que la blockchain puede ser muchas veces más grande y eso requeriría una mejor capacidad de computación para procesar bloques de gran tamaño. Al mismo tiempo, esto disminuiría la seguridad de la red en cierta medida debido a la disminución del poder de hash honesto efectivo. Esto también puede llevar a un escenario en el que la red se concentre en unas pocas manos ricas y, por lo tanto, puede comprometer, en última instancia, la descentralización y la seguridad, los principales principios de la blockchain.

Uno de ellos es la preocupación por la seguridad. Es una creencia común que la red es más segura si más nodos de la red participan en el procesamiento de transacciones en la blockchain. Con la mayor distribución de las cadenas de altcoin, menos nodos operarán en una determinada blockchain. Esto puede hacer que la blockchain sea menos segura, ya que una red de altcoin más pequeña puede ser más vulnerable a los ataques de red. Digamos que tenemos unos 10,000 nodos en la red más grande, se necesitarán al menos 5,001 nodos (o lo que se llama el 51%) comprometidos para lanzar un ataque a la red. Si dividimos los 10,000 nodos en 50 cadenas más pequeñas, cada cadena comprende 200 nodos, y solo se necesitan 101 nodos para derribar cualquier cadena más pequeña, que es lo que llamamos un problema de ataque del 1%. Otro problema es la integración entre cadenas. Si bien hay algunas soluciones para manejar la integración entre blockchains, la complejidad general de integrar cadenas más pequeñas y altcoins aumentará drásticamente.

Segwit2x fue una propuesta de compromiso para el debate sobre el tamaño de los bloques en 2017. En ella se sugería que se activara SegWit como primer paso y, después, se aumentara el tamaño de los bloques a 2 mb. Esta propuesta no fue aceptada por la mayoría de la red de Bitcoin.

Soluciones fuera de la cadena

De forma similar a las razones para una solución dentro de la cadena, la comunidad de Bitcoin también está buscando activamente soluciones fuera de la cadena, a veces llamadas soluciones de capa 2. En el escalamiento fuera de la cadena, la solución es desarrollar capas adicionales sobre la blockchain de Bitcoin y procesar todo tipo de transacciones con dos participantes. Estas transacciones podrían entonces ser agrupadas y enviadas como una sola transacción en la blockchain. Una de estas soluciones fuera de la cadena se llama Lightning Network.

Lightning Network

En enero de 2016, Joseph Poon y Thaddeus Dryja y presentaron en reporte: The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments (Lightning Network de Bitcoin: pagos instantáneos escalables fuera de la cadena). En este reporte se describen los contornos de Lightning Network.

Lightning es una red descentralizada que utiliza la funcionalidad de los contratos inteligentes en la blockchain para permitir los pagos instantáneos en una red de participantes.

Lightning Network es una solución de pago de “capa 2” que escala las blockchains y permite realizar pagos instantáneos sin confianza al mantener la mayoría de las transacciones fuera de la cadena.  Desarrolla una red de los llamados canales de pago, en los que dos partes realizan una transacción y se pagan mutuamente. El proceso es instantáneo y la transacción no necesita ser validada, transmitida ni almacenada por cada nodo de la red de Bitcoin, sino solo entre dos participantes.  

Al trasladar los pagos fuera de la cadena, el costo de mantenimiento de los canales se reduce sobre el volumen de pagos en ese canal, lo que permite realizar micropagos y transacciones de pequeño valor para las que, de otro modo, las tarifas de transacción en la cadena serían demasiado caras para justificarlas. Además, Lightning Network escala el rendimiento de las transacciones fuera de la cadena con los límites modernos de procesamiento de datos y latencia: los pagos pueden procesarse muy rápido.

Veamos cómo funciona Lightning Network.

Inicialmente, Alice tiene la transacción de compromiso A1, y Bob tiene la transacción de compromiso B1.

La clave de revocación de A1, K A1, solo la posee Alice;

La clave de revocación para B1, K B1, solo la posee Bob.

Supongamos que Alicia y Bob poseen cada uno 10 BTC en su cuenta. Alice quiere enviar 2 BTC a Bob.

Alice y Bob depositan montos iguales de dinero, en nuestro caso, 10 BTC y cada uno pone un candado.  Esta acción de depositar montos iguales de dinero en una caja común se registra en la blockchain en forma de “canal de pago” y a partir de entonces se abre un canal de pago entre esas dos personas.

Alice crea una nueva transacción de Bob, B2, que asigna 8 BTC a Alice y 12 BTC a Bob.

Alice firma la B2 y la envía a Bob.

Bob recibe la B2, la firma y la guarda.

Bob crea una nueva transacción de Alice, A2, que asigna 8 BTC a Alice y 12 BTC a Bob.

Bob firma la A2 y la envía a Alice.

Alice recibe la A2, la firma y se la queda.

Alice proporciona K A1, invalidando la A1, puede entonces eliminar la A1.

Bob proporciona K B1, invalidando la B1; entonces puede eliminar la B1.

En resumen, el canal de pago consiste en crear un pool de dinero mancomunado para ambas partes y luego transferir la promesa de propiedad del dinero mancomunado de la manera acordada.

Cuando Alice o Bob quieran cerrar el canal, pueden hacerlo. Cerrar el canal significaría simplemente que ambas partes recuperan su propio dinero. Esta apertura de la caja ocurre en la blockchain y se registra para siempre quién posee cuánto de la caja.

Lightning Network utiliza los Contratos de Tiempo Fijo Hash (HTLC), una clase de pagos que utiliza hashlocks y timelocks para requerir que el receptor de un pago reconozca haber recibido el pago antes de una fecha límite generando un comprobante criptográfico del pago o pierda la capacidad de reclamar el pago, devolviéndolo al pagador.

Permite el envío de transacciones entre partes que no tienen un canal directo, enrutándolo a través de varios saltos, de modo que cualquier persona conectada a Lightning Network forma parte de un sistema financiero global único e interconectado.

Veamos un ejemplo:

Alice quiere enviar un pago a Tim, pero no tiene un canal de pago con Tim.  Alice tiene un canal de pago con Bob, que tiene un canal de pago con Tim, ¿cómo puede Alice pagar a Tim?

Para esto, Tim debe crear una cadena secreta criptográfica (clave), luego la convierte en hash utilizando una función de hash como SHA-256 y, luego, la envía a Alice.  Tim también comparte ese hash con todo el mundo: Bob. Para simplificar esta ilustración escrita, representaremos el valor como V.

HTLC

Este hash V es el candado, la clave es el código para desbloquear el HTLC.

Alice crea un Contrato de Hash con Tiempo de Bloqueo (HTLC) con Bob y le dice a Bob que te pagaré si puedes producir la preimagen de V en 3 días. Alice firma una transacción con un tiempo de bloqueo de 3 días después de su emisión. Bob puede canjearla con el conocimiento de V, y después es canjeable solo por Alice. El HTLC permite a Alice hacer una promesa condicional a Bob, asegurando al mismo tiempo que sus fondos no se quemarán accidentalmente si Bob nunca sabe qué es V.

Bob hace lo mismo, haciendo un HTLC que pagará a Tim si este puede producir el V en 2 días. Sin embargo, Tim, de hecho, conoce el V. Debido a que Tim es capaz de sacar la cantidad deseada de Bob utilizando su clave, Tim puede considerar el pago de Alice finalizado. Ahora, él no tiene ningún problema en decirle el V a Bob para que sean capaces de cobrar sus fondos también.

Tim revela la clave a Bob, dentro de 2 días, y Tim recibe el pago de Bob.

Bob revela la clave a Alice, dentro de 3 días, y Bob recibe el pago de Alice.

Después de que todos cooperen, todas estas transacciones ocurren dentro de Lightning Network. Todo el mundo recibe el pago de una manera mecánica. Lightning Network es casi atómica por naturaleza y bidireccional, lo que significa que o todos cobran, o nadie cobra.

En Lightning Network, cuando se emite la transacción de pago, todas las transacciones individuales serán verificadas primero, y deben coincidir con el historial de transacciones para evitar la emisión de transacciones falsas o incorrectas. También hay una penalización impuesta a las transacciones fraudulentas, en la que si Lightning Network detecta a un mal actor en el sistema, se le aplica inmediatamente una penalización. De este modo, toda la red garantiza la credibilidad y la coherencia al tiempo que desalienta el mal comportamiento.

El uso de Lightning Network tiene varias ventajas en comparación con las transacciones en la cadena:

Transacciones rápidas e instantáneas: el tiempo de liquidación de las transacciones de Lightning Network es inferior a un minuto y puede producirse en milisegundos.

Micropagos: permite microtransacciones de grandes montos.

Rendimiento de las transacciones: no hay límites fundamentales a la cantidad de pagos por segundo que pueden ocurrir según el protocolo. La cantidad de transacciones solo está limitada por la capacidad y la velocidad de cada nodo.

Privacidad: no hay registros en la blockchain. Los detalles de las transacciones individuales de pago de Lightning Network no se registran públicamente en la blockchain directamente. Los pagos pueden dirigirse a través de muchos canales secuenciales en los que cada operador de nodo podrá ver los pagos a través de sus canales, pero no podrá ver el origen ni el destino de esos fondos si no son adyacentes.

Menos congestión en la red en la cadena:

Tarifas por transacción extremadamente bajas: las tarifas por transacción en Lightning Network que se pagan a los nodos intermediarios suelen ser cantidades muy pequeñas, normalmente en milisatoshis.

Limitaciones

Lightning Network está formada por canales de pago bidireccionales entre dos nodos que combinados crean contratos inteligentes. Si en algún momento cualquiera de las partes abandona el canal, este se cerrará y se liquidará en la blockchain.

Debido a la naturaleza del mecanismo de disputa de Lightning Network, que requiere que todos los participantes tengan que supervisar siempre su canal y hacer un seguimiento del estado del libro mayor fuera de línea que se transmite a la red. Para resolver este problema se ha desarrollado el concepto de “torre de vigilancia”.

* Descargo de responsabilidad: este artículo está destinado a ser utilizado únicamente con fines de referencia. Ninguna información proporcionada a través de Bybit constituye un consejo o una recomendación de que cualquier inversión o estrategia de trading sea adecuada para una persona específica. Estas previsiones se basan en las tendencias del sector, las circunstancias de los clientes y otros factores, y conllevan riesgos, variables e incertidumbres. No existe ninguna garantía presentada o implícita en cuanto a la exactitud de las previsiones, proyecciones o declaraciones predictivas específicas en este documento. Los usuarios de este artículo aceptan que Bybit no se hace responsable de ninguna de sus decisiones de inversión. Busca asesoramiento profesional antes de realizar trading.