Hechos clave:
-
La blockchain RSK se plantea migrar de Bitcoin SPV-sidechain a una Bitcoin SyncChain.
-
La SyncChain reduce los tiempos de confirmaciĆ³n de seguridad de dĆas a horas de manera segura.
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.