Profundidad del análisis de la escalabilidad off-chain

1. La necesidad de la expansión

La visión futura de la blockchain es la descentralización, la seguridad y la escalabilidad, pero a menudo solo se pueden lograr dos de ellas, lo que se conoce como el problema del triángulo imposible. Durante años, las personas han estado explorando cómo aumentar el rendimiento y la velocidad de las transacciones de la blockchain, garantizando al mismo tiempo la descentralización y la seguridad, es decir, resolver el problema de la escalabilidad, que es uno de los temas candentes en el proceso de desarrollo actual de la blockchain.

Definición de la descentralización, seguridad y escalabilidad de la blockchain:

• Descentralización: cualquier persona puede convertirse en un nodo y participar en la producción y validación del sistema. Cuantos más nodos haya, mayor será el grado de descentralización, asegurando que la red no esté controlada por unos pocos grandes participantes centralizados.

• Seguridad: Cuanto mayor sea el costo de obtener el control del sistema, mayor será la seguridad, y la cadena podrá resistir ataques de un mayor porcentaje de participantes.

• Escalabilidad: la capacidad de la blockchain para procesar una gran cantidad de transacciones.

El primer gran hard fork de la red Bitcoin se originó por problemas de escalabilidad. A medida que aumentaba el número de usuarios y el volumen de transacciones, la red Bitcoin, con un límite de 1MB por bloque, comenzó a enfrentar problemas de congestión; desde 2015, la comunidad de Bitcoin ha tenido desacuerdos sobre el tema de la escalabilidad, con un lado apoyando la ampliación del bloque y el otro creyendo que se debería utilizar la solución de Segregated Witness (Segwit) para optimizar la estructura de la cadena principal. El 1 de agosto de 2017, Bitcoin ABC, que apoyaba la ampliación del bloque, lanzó su sistema de cliente de 8MB, lo que llevó al primer gran hard fork en la historia de Bitcoin y dio lugar a la nueva criptomoneda BCH.

La red de Ethereum también opta por sacrificar parte de la escalabilidad para garantizar la seguridad y la descentralización de la red. Aunque la red de Ethereum no limita la cantidad de transacciones como lo hace la red de Bitcoin restringiendo el tamaño del bloque, en cambio, ha cambiado indirectamente al establecer un límite en las tarifas de combustible que puede contener un solo bloque, pero el objetivo es el mismo: lograr un consenso sin confianza y asegurar una amplia distribución de nodos.

Desde los CryptoKitties de 2017, el verano DeFi, hasta el surgimiento posterior de GameFi y NFT, las aplicaciones en cadena han ido en aumento, y la demanda del mercado por capacidad de procesamiento sigue creciendo. Sin embargo, incluso Ethereum, que es Turing completo, solo puede procesar entre 15 y 45 transacciones por segundo (TPS), lo que resulta en un aumento de los costos de transacción y un tiempo de liquidación más prolongado. La mayoría de las Dapps encuentran difícil soportar los costos operativos, y toda la red se vuelve lenta y cara para los usuarios, lo que hace urgente la solución del problema de escalabilidad de la blockchain. La solución ideal de escalabilidad es: aumentar la velocidad de transacción y la capacidad de procesamiento de la red tanto como sea posible, sin sacrificar la descentralización y la seguridad.

2. Tipos de soluciones de escalabilidad

Dividimos los planes de expansión en dos categorías principales: expansión en cadena y expansión off-chain, según el criterio de "si se cambia o no una capa de la red principal".

2.1 expansión on-chain

Concepto clave: solución para lograr la escalabilidad al cambiar un nivel del protocolo de la red principal, la principal solución actual es el sharding.

La expansión en cadena tiene diversas soluciones, este artículo no se detendrá en ello, a continuación se enumeran brevemente dos soluciones:

• La opción uno es expandir el espacio del bloque, es decir, aumentar la cantidad de transacciones empaquetadas en cada bloque, pero esto aumentará los requisitos para dispositivos de nodos de alto rendimiento, elevará el umbral de entrada para los nodos y disminuirá el grado de "descentralización".

• La opción dos es el sharding, que consiste en dividir el libro mayor de la blockchain en varias partes, donde no todos los nodos participan en el registro completo, sino que diferentes shards, es decir, diferentes nodos, son responsables de distintas anotaciones, permitiendo que el cálculo en paralelo procese múltiples transacciones al mismo tiempo; esto puede reducir la presión computacional sobre los nodos y el umbral de entrada, mejorando la velocidad de procesamiento de transacciones y el grado de descentralización; pero esto significa que la potencia computacional de toda la red se distribuye, lo que puede disminuir la "seguridad" de la red en su conjunto.

Cambiar el código de un protocolo de la red principal puede tener efectos negativos imprevisibles, ya que cualquier pequeño fallo de seguridad en la capa subyacente puede amenazar gravemente la seguridad de toda la red, lo que podría obligar a la red a realizar un fork o a interrumpir la actualización de reparaciones. Por ejemplo, el incidente de la vulnerabilidad de inflación de Zcash en 2018: el código de Zcash se basa en una modificación del código de la versión 0.11.2 de Bitcoin, en 2018 un ingeniero descubrió una grave vulnerabilidad en su código subyacente, es decir, que los tokens podían ser emitidos de manera ilimitada, y el equipo tardó 8 meses en realizar una reparación secreta, y solo después de reparar la vulnerabilidad se hizo pública la incidencia.

2.2 off-chain expansión

Concepto clave: solución de escalabilidad que no altera el protocolo de la red principal de una capa existente.

Las soluciones de escalabilidad off-chain se pueden dividir en Layer2 y otras soluciones:

3. Profundidad de la solución de expansión off-chain

3.1 Canales de Estado

3.1.1 Resumen

Los estados de canal estipulan que solo cuando el canal está abierto, cerrado o se resuelve una disputa, los usuarios necesitan interactuar con la red principal, y las interacciones entre los usuarios se realizan off-chain, con el objetivo de reducir el tiempo y el costo monetario de las transacciones de los usuarios, además de permitir un número ilimitado de transacciones.

Los canales de estado son protocolos P2P simples, adecuados para "aplicaciones basadas en turnos", por ejemplo, un juego de ajedrez entre dos personas. Cada canal es gestionado por un contrato inteligente multi-firma que opera en la cadena principal, el cual controla los activos depositados en el canal, verifica las actualizaciones de estado y arbitra las disputas entre los participantes ( según las pruebas de fraude con firma y marca de tiempo ). Después de que los participantes despliegan el contrato en la red blockchain, depositan una suma de dinero y la bloquean; una vez que ambas partes firman y confirman, el canal se abre oficialmente. El canal permite transacciones off-chain gratuitas e ilimitadas entre los participantes ( siempre que el valor neto de sus transferencias no supere el total de tokens depositados ). Los participantes envían actualizaciones de estado alternativamente al otro, esperando la firma de confirmación de la otra parte. Una vez que la otra parte firma y confirma, la actualización de estado se considera completada. Normalmente, las actualizaciones de estado acordadas por ambas partes no se suben a la cadena principal; solo en caso de disputa o al cerrar el canal se depende de la confirmación de la cadena principal. Cuando se necesita cerrar el canal, cualquiera de los participantes puede presentar una solicitud de transacción en la cadena principal; si la solicitud de salida recibe la aprobación unánime de las firmas, se ejecuta inmediatamente en la cadena, es decir, el contrato inteligente distribuye los fondos restantes bloqueados según el saldo de cada participante en el estado final del canal; si otros participantes no aprueban la firma, todos deben esperar el fin del "período de desafío" para recibir los fondos restantes.

En resumen, el esquema de canales de estado puede reducir significativamente la carga computacional de la cadena principal, aumentar la velocidad de las transacciones y disminuir los costos de transacción.

3.1.2 Línea de tiempo

• 2015/02, Joseph Poon y Thaddeus Dryja publicaron el borrador del libro blanco de la red Lightning.
• En noviembre de 2015, Jeff Coleman resumió sistemáticamente el concepto de State Channel por primera vez, proponiendo que el Payment Channel de Bitcoin es un subcaso del concepto de State Channel.
• 2016/01, Joseph Poon y Thaddeus Dryja publicaron oficialmente el documento técnico "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" que propuso el esquema de escalabilidad del Bitcoin Lightning Network Payment Channel( canal de pago), el cual se utiliza únicamente para procesar pagos de transferencias en la red de Bitcoin.
• En noviembre de 2017, se propuso la primera especificación de diseño de State Channel basada en el marco de Payment Channel llamada Sprites.
• 2018/06, Counterfactual presentó un diseño de Canales de Estado Generalizados muy detallado, que es el primer diseño completamente relacionado con canales de estado.
• 2018/10, el artículo Generalised State Channel Networks presenta los conceptos de State Channel Networks y Virtual Channels.
• 2019/02, el concepto de canales de estado se expandió a N-Party Channels, Nitro es el primer protocolo construido sobre esa idea.
• 2019/10, Pisa amplió el concepto de Watchtowers para resolver el problema de que todos los participantes necesitan estar en línea de forma continua.
• 2020/03, Hydra propuso Canales Isomórficos Rápidos.

3.1.3 Principios técnicos

La Figura 1 muestra el flujo de trabajo en una cadena tradicional: Alice y Bob interactúan con un contrato inteligente desplegado en la red principal, y los usuarios cambian el estado del contrato inteligente enviando transacciones a la cadena. La desventaja es que esto conlleva los problemas de tiempo y costo discutidos anteriormente.

La Figura 2 muestra el flujo de trabajo general que siguen la mayoría de los protocolos de canales de estado: en un caso optimista, Alice y Bob necesitan realizar la misma operación que antes, pero esta vez utilizan un canal de estado en lugar de interactuar con un contrato en la cadena.

• Primer paso, Alice y Bob interactúan depositando fondos desde su EOA personal a la dirección del contrato en cadena (, 1,2), estos fondos se bloquean en el contrato hasta que se cierre el canal y el saldo se devuelva al usuario; después de que ambas partes firman la confirmación, el canal de estado entre ellos se abre oficialmente.
• En el segundo paso, Alice y Bob pueden realizar transacciones ilimitadas off-chain a través de este canal ( línea azul discontinua ), los participantes se comunican entre sí mediante mensajes firmados criptográficamente ( en lugar de comunicarse con la red blockchain ). Ambos usuarios deben firmar cada transacción para evitar el doble gasto malicioso. A través de estos mensajes, proponen actualizaciones del estado de sus cuentas y aceptan las actualizaciones de estado propuestas por el otro.
• El tercer paso, si Alice quiere cerrar el canal y terminar la transacción con Bob, Alice debe enviar al contrato el estado final de su cuenta ( interacción 3). Si Bob firma y aprueba, el contrato liberará los fondos bloqueados según el estado final y los devolverá al usuario correspondiente ( interacción 4,5). Si Bob no responde a la firma, el contrato liberará los fondos bloqueados y los devolverá al usuario correspondiente al final del período de desafío.

La Figura 3 muestra el flujo de trabajo del canal de estado en un escenario pesimista: al principio, dos participantes depositan fondos ( interacción 1, 2), y luego comienzan a intercambiar actualizaciones de estado ( línea discontinua azul ). Supongamos que en algún momento, Bob no responde a la firma de actualización de estado que Alice envió en su turno ( interacción 3), en este momento, Alice puede iniciar un desafío al presentar el último estado válido que tiene ante el contrato ( interacción 4), este estado válido también incluye la firma anterior de Bob, lo que demuestra que la última transacción ha sido aprobada por Bob y que el estado final ha sido confirmado por Bob. Luego, el contrato permite a Bob responder dentro de un período de tiempo presentando el siguiente estado al contrato; si Bob responde, ambos pueden continuar realizando transacciones dentro del canal de estado; si Bob no responde dentro de este período de tiempo, el contrato cierra automáticamente el canal de estado y devuelve los fondos a Alice ( interacción 5).

3.1.4 Ventajas y desventajas

Ventajas:

• Alta escalabilidad: se pueden realizar transacciones sin restricciones
• Baja latencia: transacciones completadas instantáneamente
• Bajo costo: las transacciones off-chain prácticamente no tienen costo
• Privacidad: las transacciones off-chain no se registran en la cadena principal.
• Disponibilidad: incluso si hay problemas con la cadena principal, los canales de estado aún se pueden usar.

Desventajas:

• Fondos bloqueados: ambas partes necesitan bloquear los fondos
• Conexión continua: los participantes deben estar en línea de manera continua para monitorear el estado del canal.
• Costo de creación de canal: Abrir un canal requiere interacción con la cadena principal, lo que implica un costo más alto.
• Cierre de retraso: cerrar el canal requiere esperar el período de desafío
• Contraparte limitada: el canal solo puede operar con una contraparte fija.
• No es adecuado para el uso a gran escala: no es amigable para los usuarios comunes

3.1.5 Aplicación

Red Lightning de Bitcoin

Resumen:

La red Lightning es un canal de pagos de bajo valor en la red Bitcoin. Su evolución técnica en general ha pasado por: la construcción de canales de pago unidireccionales mediante 2/2 multisig, la adición de RSMC( Revocable Sequence Maturity Contract) que permite la construcción de canales de pago bidireccionales, y luego la incorporación de HTLC( Hash Time Lock Contract) que expande los canales de pago a pagos entre múltiples partes, construyendo finalmente la red de pagos, es decir, la red Lightning. A través de canales de pago de bajo valor off-chain, y luego mediante intermediarios para formar una red de transacciones, se puede resolver el problema de escalabilidad de la red Bitcoin. El uso general de la red Lightning sigue el flujo de "depósito( establecer canal) → transacción en Lightning( actualizar estado del canal) → reembolso/settlement( cerrar canal)"; teóricamente, la red Lightning puede procesar un millón de transacciones por segundo.

Línea de tiempo:

• En febrero de 2015, Joseph Poon y Thaddeus Dryja publicaron el borrador del libro blanco de la red Lightning.
• En enero de 2016 se publicó la versión oficial del libro blanco y se fundó Lightning Labs;
• El 15 de marzo de 2018, Lightning Labs lanzó la primera versión de la red principal de Lightning Network Daemon (LND) versión 0.4.
• A principios de 2021, la capacidad pública de la red Lightning (TVL) era de aproximadamente 40 millones de dólares.