SyncChains: La evolución de las sidechains sobre Bitcoin

Contenido patrocinado por IOVLabs

Las sidechains sobre Bitcoin tienen su historia. El proceso para la puesta en marcha de una nueva tecnología es largo: desde la primera formulación de la idea, pasando por la formalización de la propuesta en un libro blanco, luego su desarrollo, implementación y evolución, sin mencionar las distintas variantes que una misma tecnología puede tener.

Hay muchos detalles históricos que nos ayudan a ganar una mejor perspectiva respecto al estado actual de estas soluciones y cómo podrían cambiar en el futuro.

¿Qué es una sidechain y para qué sirve?

Una cadena lateral o sidechain es una cadena de bloques que funciona con un protocolo paralelo e independiente a una cadena base (como Bitcoin) pero que permite la transferencia de monedas entre ambas cadenas, sin que se comprometa la seguridad de la cadena base.

Así, las sidechains permiten potenciar las funcionalidades de Bitcoin, pero en caso de que se explote una vulnerabilidad en el código de la sidechain, esto solo afectará a la propia sidechain y no a Bitcoin. Lo contrario también es cierto.

Por esta razón las sidechains son una herramienta para implementar y probar innovaciones en forma productiva, fuera del espacio experimental de las testnets y sin que estas innovaciones deban ser discutidas y aceptadas en consenso en la cadena base y protegiendo, además, la integridad de ella.

Entre las principales aplicaciones que puede tener una sidechain destaca la creación de contratos inteligentes de mayor complejidad que los nativos de Bitcoin (que permitan la emisión de tokens valores o de utilidad y otras herramientas de finanzas descentralizadas); aumento de la escalabilidad y de la velocidad de las transacciones a través de tokens anclados al precio del BTC; realización de transacciones confidenciales que potencien la privacidad en la red; interconectividad con casas de cambio que aumenten la eficiencia de los intercambios y disminuyan la necesidad de confianza en terceros de custodia; entre otros.

Prehistoria de las sidechains sobre Bitcoin

Como mucho de lo que ocurre en estas comunidades de código abierto, es difícil fijar con precisión cuando o quien formuló una idea en bruto que luego sería profundizada por otros en papeles técnicos.

Con todo, gracias a conversaciones en foros, sobre todo en BitcoinTalk, puede tenerse certeza de que el término es casi tan viejo como Bitcoin y hasta el propio Satoshi Nakamoto habló sidechains en diciembre de 2010.

Reflexionando sobre un sistema de nombres de dominio en Bitcoin (llamado entonces BitDNS y que posteriormente se convertiría en la primera altcoin, Namecoin), Satoshi anticipaba el concepto de la minería combinada, presente en sidechains como RSK:

“Creo que pudiera ser posible para BitDNS ser una red completamente separada y una cadena de bloques separada, y aun así compartir poder de CPU con Bitcoin. El único solapamiento es hacerlo de tal manera que los mineros puedan buscar pruebas de trabajo para las dos redes de manera simultánea. Las redes no necesitarían ninguna coordinación. Los mineros se suscribirían a las dos redes en paralelo. Escanearían por un SHA tal que, si dan con el justo, puedan resolver los dos (acertijos) a la vez. Una solución podría ser justa solo para una cadena en caso de que tenga una menor dificultad.”

También, Satoshi argumentó porqué sería mejor tener diversas cadenas paralelas protegidas por el poder de procesamiento de una cadena base, en vez de múltiples cadenas independientes:

“En vez de fragmentarse, las redes comparten y aumentan el poder de CPU total de cada otra. Esto podría solucionar el problema respecto a si hay múltiples redes, podrían poner en peligro a las otras si el poder de CPU disponible se concentra en una. En cambio, si todas las redes en el mundo comparten el poder combinado de CPU, aumentarían la fuerza total. Haría más fácil para las redes pequeñas comenzar al entrar en un base de mineros lista.”

Fue como respuesta a estos comentarios de Satoshi que el usuario nanotube –creador del primer mercado OTC de Bitcoin en 2010– escribió por primera vez el término side chain, preguntando “cuál sería el incentivo de los mineros para incluir bitDNS (y cualquier otra side chain)” en su operación de minería. A lo que Satoshi respondió que “el incentivo es obtener recompensas de las side chains adicionales por el mismo trabajo”; para el ejemplo de BitDNS, recibir nombres de dominio.

Lo dicho por Satoshi podría parecer más vinculado a minería combinada o merged mining que a una sidechain, tal como las conocemos en la actualidad. Esto pues no se hace mención a un sistema de clavija bidireccional o 2-way-peg, que permita el bloqueo de fondos en la cadena base para poder utilizar una representación de las monedas en la cadena lateral, con la posibilidad de desbloquear nuevamente las monedas en la cadena base, tras la quema de los tokens de la cadena lateral.

Esta es una de las razones por las cuales redes como Counterparty, a pesar de aprovechar el hashrate de Bitcoin, permitir el desarrollo de tokens no-fungibles como los rare pepes y hasta permitir la operatividad de dApps gracias a la integración de la Máquina Virtual de Ethereum, no son realmente sidechains por no permitir que las monedas enviadas desde la cadena base a la cadena lateral regresen posteriormente a la cadena base.

Sin embargo, el nombre de side chain perduraría en el tiempo en investigaciones subsiguientes. En el 2011, desarrolladores como el excontribuidor de Bitcoin Core, Mike Hearn, profundizaron en la idea de redes independientes aprovechando el mismo poder de hash, con la posibilidad de desbloquear los BTC utilizados.

En 2013, Alex Mizrahi, CTO de Chomaway, más conocido por su pseudónimo, killerstorm, propuso una distinción entre minería combinada y cadenas laterales, mediante una propuesta de marcas de tiempo esbozada en el 2012 por Peter Todd.

Uno de los problemas que resultaba de esa propuesta es que las reorganizaciones en Bitcoin dispararían de manera inmediata la reorganización en la cadena lateral. En ese sentido, Mizrahi establecía que las cadenas que trabajaban con minería combinada en vez de con marcas de tiempo eran más independientes.

Al final, el nombre de sidechain siguió siendo utilizado para describir cadenas laterales independientes de la cadena base, trabajaran con minería combinada (como RSK) o no (como Liquid).

El libro blanco de las sidechains

Las investigaciones sobre las sidechains tomaron un mayor impulso a finales de 2013 y principios de 2014, en la medida que el debate sobre los problemas de escalabilidad de Bitcoin comenzaba a arreciar y se buscaban alternativas ante la propuesta de aumentar el tamaño de los bloques.

Una de estas propuestas de escalabilidad fueron las sidechains. Pero estas dieron un nuevo giro cuando se incorporó la idea de una clavija bidireccional o two-way-peg que posibilitara la interoperabilidad entre cadenas. La propuesta fue realizada en octubre de 2013 por el creador de HashCash y fundador de Blockstream, Adam Back, en la lista de correo de desarrolladores de Bitcoin, tomando como referencia investigaciones previas publicadas por el desarrollador Gregory Maxwell.

Se dice que hay 2-way-peg cuando ambas monedas pueden ser intercambiadas entre cadenas de manera libre, automática, sin pagar más que las comisiones de transacción y sin incurrir en una negociación de precio.

La clavija bidireccional no limita que la sidechain pueda emitir sus propios tokens. Tampoco excluye la posibilidad de que este token, con colateral en la cadena base, pueda ser también representado en otras cadenas con las que mantenga interoperabilidad la sidechain, sin alterar el suministro de la cadena base. Lo que sí posibilita es que el token paritario pueda desbloquearse para ser redimido nuevamente en la cadena base una vez que hayan sido quemadas sus representaciones en la sidechain.

En aquel entonces, ya Back preconizaba cómo podría ser el futuro de interoperabilidad de las sidechains:

“Puedes tener múltiples cadenas laterales que compitan al nivel de Bitcoin. Tal vez una optimizada para micropagos. Puedes mover bitcoins a la sidechain de micropagos, y luego de vuelta a Bitcoin, para posteriormente enviarlos a una sidechain de contratos inteligentes”.

La discusión respecto a la propuesta se extendió durante gran parte de 2014, como prueban las respuestas y comentarios realizados por Jeff Garzik, Gregory Maxwell, Andrew Poelstra. Incluso Greg Sanders, quien desarrolló Software en GreenAddress antes de ser adquirida por Blockstream, y quien fue precisamente ingeniero de la sidechain de esta compañía, Liquid, escribió sobre sidechains y treechains (esta última propuesta mayormente trabajada por Peter Todd).

Finalmente, en octubre de 2014 se formalizaron y publicaron estas ideas en el libro blanco de sidechains. Los autores del paper fueron en su mayoría participantes en la discusión en la lista de correo, así como desarrolladores de Blockstream (Adam Back, Pieter Wuille, Matt Corallo, Luke Dashjr, Mark Friedenbach, Andrew Poelstra, Jorge Timón, Andrew Miller and Gregory Maxwell).

Implementación de las sidechains

Desde la publicación del libro blanco, hasta el lanzamiento efectivo de las primeras sidechains, pasaron casi tres años. Tras subsiguientes discusiones en la lista de correo de desarrolladores de Bitcoin, notaron riesgos de seguridad en el modelo de sidechain sin terceros de confianza expuesto en el libro blanco.

La propuesta original se basaba en un sistema de verificación de pagos simplificados (SPV) para la clavija bidireccional. El SPV es conocido por su uso en los monederos custodios de Bitcoin que no requieren que el usuario corra su propio nodo y verifique por sí mismo el cumplimiento de las reglas de la cadena.

La teoría de juegos tras el diseño basado en SPV ofrecía pocos incentivos para evitar ataques. Según Poelstra, se dieron cuenta de que “entre más dinero tienes en la sidechain, hay mayores incentivos para que alguien haga una reorganización de la blockchain”

Por esta razón, de la idea original de sidechains sin terceros de confianza, Blockstream viró hacia un sistema basado en federaciones. Así, fue Blockstream la primera en lanzar en versión beta una sidechain, Liquid, en mayo de 2017. A esto le siguió la salida en producción de RSK, en enero de 2018, quienes escogieron un sistema mixto para reducir la necesidad de confianza. Este híbrido mezcla una federación con un sistema de pruebas SPV que utiliza minería combinada. Con todo, ambas sidechains planean reducir la necesidad de confianza en futuras actualizaciones.

La arquitectura y propósito de estas dos sidechains tiene algunas diferencias, si bien ambas cumplen con los presupuestos básicos de una cadena lateral (bidireccionalidad y atomicidad en la transferencia de tokens entre cadenas; autonomía de los propietarios de los tokens; independencia del funcionamiento de ambas cadenas).

Las particularidades de cada red son producto del foco que se tuvo en consideración al momento de desarrollarlas: Liquid en traders y mercado y RSK en aplicaciones descentralizadas, desarrolladores y usuarios.

Liquid es una plataforma diseñada para proporcionar liquidez compartida a los exchanges. Se centra en la simplicidad del protocolo, la seguridad y la privacidad. RSK es una cadena lateral centrada en dApps y finanzas descentralizadas (DeFi). Por lo tanto, la intención de RSK es resolver un conjunto mucho más amplio de casos de uso, mientras que Liquid se enfoca en ser eficiente en uno.

Lo anterior en referencia a sus objetivos. Ahora, ¿cómo se diferencian sus arquitecturas?

Liquid

Al igual que RSK, Liquid mantiene un token nativo que representa al BTC en una relación de paridad 1:1, el Liquid Bitcoin o L-BTC. El sistema 2-way-peg es similar al de RSK en el sentido de que los L-BTC que circulan en Liquid son aquellos equivalentes a los BTC bloqueados en la red Bitcoin; no hay creación de nuevas monedas.

Para que los BTC sean transformados en L-BTC, la transacción en la cadena base debe alcanzar un mínimo de 102 confirmaciones para poder asegurar la solvencia de la sidechain en caso de reorganizaciones de bloques en la cadena base.

También existe una Federación, mayoritariamente conformada por exchanges, que se encarga de correr los nodos que aseguran el dinero bloqueado. Pero a nivel de consenso, a diferencia de RSK que utiliza PoW, en Liquid son los funcionarios de la Federación quienes lo administran.

Al estar encargada de ambas funciones, la Federación ha sido dividida en dos tipos de funcionarios: blocksigners, encargados de firmar los bloques de las transacciones en la sidechain; y los watchmens, responsables de validar los intercambios entre la cadena base y la cadena lateral. Este trabajo es realizado operando servidores que corren nodos tanto de Bitcoin como de Liquid con un software especializado para la interacción entre cadenas que maneja las llaves criptográficas que firman las transacciones.

Así, teniendo un número prefijado de nodos firmantes que interactúan en un contrato multifirma, se asegura una mayor velocidad en la confirmación de transacción en comparación con Bitcoin, donde el número de firmantes es dinámico y abierto. Si la seguridad de una de las llaves es comprometida, el sistema no corre peligro gracias al respaldo de la información distribuida entre el resto de los nodos.

Liquid se desarrolló sobre la base del código de Elements, una plataforma de fuente abierta también desarrollada por Blockstream para la construcción de blockchains compatibles con sidechains.

Gracias a las funcionalidades de Elements, es posible emitir activos personalizados sobre Liquid para diversos propósitos, tales como tokens valores, de utilidad o coleccionables. Precisamente, aprovechando esta posibilidad fue que se constituyó la plataforma Liquid Securities para la emisión de tokens valores y se desplegó la herramienta Liquid Swaps, la cual permite ejecutar intercambios atómicos entre los tokens que corren sobre la sidechain.

Una de las propiedades más sólidas de Liquid es su soporte nativo para Transacciones Confidenciales (CT) tanto para L-BTC como para los activos emitidos. Esta también es una tecnología desarrollada por Blockstream que oculta los montos de las transacciones a los ojos del resto de las personas en la red, excepto a aquellos involucrados en el intercambio, aunque las direcciones de salida y llegada siguen siendo visibles y por tanto sujetas a análisis de tráfico.

De Liquid también resalta su integración experimental con Lightning Network, así como con la API de mensajes satelitales de Blockstream.  De esta manera, con la configuración adecuada y operando nodos de Bitcoin, los usuarios pueden realizar micropagos en L-BTC y enviar mensajes por satélite sin depender de Internet.

Por ahora, solo los monederos Green y el Liquid Core, ambos de Blockstream, ofrecen soporte para interactuar con la red Liquid.

RSK

RSK, proyecto impulsado por IOV Labs, se define a sí misma como la “plataforma de contratos inteligentes de Bitcoin”. Es una cadena lateral que combina la robustez y seguridad del protocolo de consenso de Bitcoin junto con la flexibilidad de la Máquina Virtual Turing completa de Ethereum, de la cual la Máquina Virtual RSK (RVM) es una bifurcación.

Desde sus inicios, el foco de RSK fue llevar las potencialidades de los contratos inteligentes y las aplicaciones descentralizadas a la red Bitcoin. Esto lo consiguen mediante la utilización del mismo lenguaje de programación de Ethereum, Solidity, y la librería estándar de Web3, lo que hace a RSK compatible con Ethereum y permite a los desarrolladores interactuar con sus contratos inteligentes y herramientas.

RSK tiene como token nativo el Smart Bitcoin (RBTC) anclado 1:1 al precio del BTC y a su suministro, lo que quiere decir que solo pueden existir 21 millones de RBTC, los cuales son creados únicamente cuando se bloquean BTC en un monedero multifirma en la red Bitcoin. El RBTC es utilizado para pagar el gas requerido para la ejecución de transacciones en la red RSK, así como también puede ser usado como colateral en aplicaciones de Finanzas Descentralizadas (DeFi).

En RSK, el consenso se alcanza mediante la llamada minería fusionada o merged-mining, la cual se basa en un sistema de SPV que utiliza el encabezado de bloque de la cadena base para enlazar la cadena lateral. Así, como ambas cadenas utilizan el mismo algoritmo de consenso, el SHA256, los mineros pueden validar transacciones tanto en Bitcoin como en RSK utilizando el mismo poder de cómputo y sin recurrir en gastos extra. Esto aumenta la rentabilidad de la minería pues los mineros reciben el 80% del gas pagado en las transacciones de RSK.

En el Whitepaper de RSK se establece que, si Bitcoin tuviera contratos inteligentes Turing completo nativos la clavija bidireccional con RSK pudiera estar libre de terceros. Pero al no tener los códigos operacionales necesarios, se requiere la participación de la Federación RSK para asegurar el bloqueo de las criptomonedas.

Así, para liberar los fondos bloqueados se requiere la firma de una mayoría de los quince miembros de la Federación. Esto no implica intervención humana; el proceso se realiza de manera automatizada mediante el software del nodo de cada miembro, el cual corre en Módulo de Seguridad de Hardware (HSM por sus siglas en inglés).

También, el proceso de modificación de los miembros de la Federación es automatizado y cada miembro puede tanto aceptar como rechazar un cambio. Este proceso es realizado a través de un contrato inteligente para que sea abierto al público. La comunidad de RSK ha propuesto utilizar un modelo de drivechain que permita que los mineros participen en el aseguramiento de la clavija (peg) y así disminuir la necesidad de la Federación. RSK se encuentra trabajando en la migración hacia un modelo híbrido.

En comparación con Bitcoin, RSK puede aumentar la velocidad de confirmación a un promedio de hasta 25 transacciones por segundo. Además, desde RSK se ha desarrollado Lumino, un sistema de canales de pagos similar a Lightning Network, el cual permite la emisión de cheques respaldados en BTC y tokens que corran sobre RSK sin necesidad de confirmaciones.

En cuanto a la privacidad de las transacciones RSK puede proveer casi cualquier esquema a través de integraciones vía contrato a nivel de usuario desarrollados por terceros. Algunos ejemplos existentes son Zether, Mobius y AZTEC. Incluso, es posible lograr el conjunto de anonimato más amplio posible mediante el uso de protocolos similares a zCash sobre RSK.

Entre las aplicaciones actualmente funcionales en RSK destacan el Servicio de Nombre de Dominio de RSK (RNS), el cual convierte las direcciones públicas de los monederos de Bitcoin de una secuencia alfanumérica a una dirección legible por humanos.  Por otro lado, se ha lanzado sobre su red un ecosistema de productos vinculados a DeFI para aprovechar la volatilidad Bitcoin y al mismo tiempo emitir una stablecoin anclada al precio del dólar y colateralizada con bitcoins: Money on Chain. RSK, tiene diversos casos de uso sobre tecnología blockchain.

La red RSK es navegable a través de monederos como MyCrypto, MyEtherWallet, Cobo, Edge, Portis, MelloWallet, Ledger, Trezor, entre otras.

SyncChain

Con todo, el diseño de este tipo de sidechains aún es perfectible. El equipo de investigación de RSK ha notado elementos a mejorar que pudieran hacer más eficiente y segura su plataforma, y desde 2016 comenzó a esbozar las deficiencias en el abordaje actual de las cadenas laterales sobre Bitcoin. Esta investigación finalmente derivó en una nueva propuesta de cadena lateral a la que pudiera migrar RSK: la SyncChain.

SyncChain permite entradas y salidas de tokens entre cadenas mucho más veloces sin sacrificar por ello la seguridad contra ataques de doble gasto. Se reduce la conexión entrante de 16 horas a tan solo 30 minutos, mientras que la conexión saliente pasa de 16 horas a 1,6 horas. La importancia de esta mejora se entiende al recordar que las cadenas laterales existentes requieren cientos de confirmaciones de bloque.

Si bien la SyncChain puede tener distintas variantes, hay tres componentes imprescindibles para esta arquitectura: doble paternidad diferida; la vinculación de transacciones de conectores; y anclaje de coinbase.

La llamada doble paternidad diferida tiene como pilar la idea de que los bloques de la cadena lateral deben especificar tanto un padre de cadena lateral como un padre de cadena principal. El estado heredado antes del procesamiento del bloque en la cadena lateral corresponde a un estado después de que ambos padres hayan sido procesados, y la reversión de uno de los padres causa la reversión del bloque hijo de la cadena lateral. Con todo, al diferir la vinculación entre el bloque de la sidechain y el bloque de la cadena base, haría falta revertir un mayor número de bloques en la cadena principal antes de poder revertir bloques en la sidechain.

Para diferir de esta manera, las SyncChains requieren un algoritmo de consenso especial llamado “Algoritmo de selección de punto de control”, el cual selecciona un punto de control en la cadena principal y corrobora que esté apropiadamente validado o no, basando su decisión en las marcas de tiempo del bloque.

La vinculación de transacciones de conectores se refiere a la conexión existente entre todas las transacciones peg-in o entrantes y las peg-out o salientes. Esto se hace para reducir la superficie de ataque de doble gasto en el momento de entrar o salir de la sidechain.

En el caso de la SyncChain, para transferir tokens desde RSK a Bitcoin se crea una transacción en RSK llamada solicitud de conector saliente, la cual transfiere el RBTC al contrato inteligente del puente entre cadenas. Después de cierto número de confirmaciones de bloque en RSK, el puente crea una plantilla de transacción de salida que contiene marcadores de posición para que los funcionarios de la federación inserten sus firmas.

Luego, el puente solicita a los funcionarios de la federación que lo firmen. Este evento se denomina Solicitud de salida. La transacción de salida debe contener una salida de datos especial que comprende un OP_RETURN, el hash de bloque para el bloque A y el número de bloque de A. Llamamos a esta carga de datos acceso del punto de control de la cadena lateral. Los puntos de control de la cadena lateral junto con los puntos de control de la cadena principal producen referencias de puntos de control recíprocos.

Una vez que la mayoría de las firmas funcionales se recopilan para la transacción de salida, la transacción se transmite y se espera que se incluya pronto en la blockchain de Bitcoin.

Finalmente, respecto al anclaje de coinbase, la manera más sencilla de anclar transacciones a un bloque en específico sería agregando un nuevo opcode al protocolo de Bitcoin. Pero sin necesidad de agregar este opcode, que puede comprometer la fungibilidad de las monedas, se puede lograr el anclaje al consumir una salida de una transacción de coinbase en la transacción de conector saliente entre los bloques de transacción de salida. Si el bloque se revierte, la transacción de salida sería invalidada.

Conclusiones

SyncChain es una de las últimas propuestas que se han hecho en materia de sidechains, pudiéndose decir que representa la etapa más actual en esta breve historia de las cadenas laterales.

Hemos visto lo largo que puede ser el recorrido desde la germinación de una idea hasta su formulación en una hoja técnica y finalmente su implementación. También es evidente que la historia no se acaba cuando se implementa la red, sino que se mantiene en continua investigación para hallar mejoras en eficiencia y seguridad.

Con SyncChain no será la excepción. Si bien está dentro de los planes de RSK migrar hacia esta propuesta, no son pocos los retos que aun perciben. Aunque SyncChain ofrece muchos beneficios sobre una cadena lateral SPV, es demasiado pronto para decir cuándo y cómo RSK podría hacer la transición para convertirse en una SyncChain. Hay beneficios pero también existen riesgos en la migración. La codificación, las pruebas, las simulaciones y las auditorías de seguridad deben validar cada decisión de diseño.

Esta propuesta inicial probablemente estará sujeta a modificaciones cuando avance la investigación, tal como sucedió cuando Blockstream propuso su libro blanco de sidechains hasta el momento en que lograron implementar.

Una vez finalizadas las etapas de investigación y desarrollo, se iniciará la discusión para recibir los comentarios de la comunidad sobre la migración. Desde RSK estiman que esto suceda para 2021.