Con el lanzamiento de la plataforma Lisk, habrá un cambio de terminología de prueba de participación delegada (DPoS) a prueba de participación (PoS). En esta publicación describimos el motivo de este cambio.

En 2014, DPoS nació cuando se implementó en el proyecto BitShares. Se describió como una evolución de PoS, con la principal diferencia de que las partes interesadas podían apostar sus monedas votando qué validador(es) deseaban proteger la red. Desde entonces, se han implementado varias versiones de DPoS en otros proyectos, como TRON, EOS, Nano y, por supuesto, Lisk.

Con el tiempo, los algoritmos de consenso dentro de todos los proyectos de blockchain han seguido evolucionando. Muchos otros proyectos que utilizan PoS, como Cosmos y Avalanche , han hecho que ciertas características sean estándar, como apostar peso en un número limitado de validadores. Estos estándares han hecho que DPoS sea mucho menos único que PoS.

Lisk mismo ha visto muchos cambios en su consenso. Por ejemplo, LIP 0023 introdujo una nueva definición de ponderación de votos, entre otras cosas. Muchos de estos cambios han desdibujado las líneas entre los algoritmos PoS y DPoS, que ya comparten muchas características.

Estos cambios están en curso, ya que Lisk actualizará nuevamente su consenso con los siguientes LIP:

• LABIO 0070
  • Introducir un mecanismo de reparto de recompensas
• LABIO 0071
  • Introducir el módulo de recompensas de bloques dinámicos

Con la adición de estos LIP, junto con la continua evolución y estandarización de la tecnología y la terminología de blockchain, hemos concluido que ya no existe una diferencia significativa entre el algoritmo DPoS de Lisk y lo que la industria describiría hoy como PoS.

Sobre la motivación detrás del cambio de terminología lo vemos en el foro de Lisk Research .

Motivación

Las principales motivaciones para el cambio de terminología son las siguientes:

• 🔴Lisk originalmente comenzó con un protocolo DPoS con 101 delegados y 101 votos que estaba muy cerca del protocolo DPoS concebido por Dan Larimer en 2014 y utilizado por primera vez en BitShares. Como parte de Lisk Core 3.0, ya cambiamos y mejoramos mucho el protocolo para hacerlo más sólido, justo y eficiente (ver LIP 0022 , LIP 0023 y LIP 0024 para más detalles). Para el próximo lanzamiento de Mainnet, estamos agregando recompensas compartidas (ver LIP 0070) y recompensas de bloques dinámicos (ver LIP 0071) al protocolo, alejándose más del protocolo DPoS original y mucho más cerca de los protocolos PoS como Ethereum 2.0, Cardano o Cosmos.

• 🔴Desde el lanzamiento de Lisk en 2016, la industria de la cadena de bloques ha evolucionado mucho y los "validadores" y el "replanteo" se han convertido en el estándar de la industria. De hecho, incluso nuestra propia comunidad ya usa con frecuencia los términos "validadores" y "participación" en lugar de "delegados" y "votación". Por lo tanto, creemos que es mucho mejor adaptarse al estándar de la industria, lo que también mejorará la accesibilidad y simplificará la incorporación de nuevos usuarios.

Esto también afectará a otros términos a través de los ecosistemas de Lisk. A continuación se muestra una tabla que enumera todos los cambios que se están produciendo:

En este articulo presentamos un resumen del desarrollado por Sergio Demián Lerner, Director Científico de Innovación de Rootstock (RSK) y uno de los mejores desarrolladores, donde presenta de forma clara los detalles técnicos del  puente RSK-Eth y el protocolo descentralizado subyacente que lo impulsa.

Tender puentes entre blockchains de manera totalmente descentralizada y no confiable es uno de los puntos fundamentales de la investigación de blockchain. En IOV Labs creamos el primer puente federado sólido en 2016 que ha estado impulsando el conector 1:1 entre RSK y Bitcoin. En la actualidad, estamos trabajando en un puente totalmente descentralizado entre RSK y Ethereum.

Introducción

Para comprender cómo mover tokens entre blockchains, en primer lugar debemos revisar los términos que suelen usarse y su historia. El término conector bidireccional (también conector 1:1) hace referencia a un sistema que intenta hacer que dos tokens de dos blockchains por separado sean económicamente equivalentes. Cuando la demanda de un lado aumenta, el conector bidireccional debe permitir que las tokens ingresen desde el otro lado, de modo que se mantenga la equivalencia de precio. En 2013, antes de que se diseñara dicho sistema, se vislumbró un futuro en el que Bitcoin podría tener varias cadenas laterales satélite conectadas a la cadena principal con conectores bidireccionales. La cadena lateral se concibió como una blockchain por separado cuyo activo nativo es extranjero y, por lo tanto, las tarifas por transacciones se abonan en este activo extranjero. Al no tener emisión de moneda interna, los bloques no pagan un subsidio a los mineros de cadenas laterales. Sin embargo, ante la falta de un diseño de conector bidireccional probado, el término “cadena lateral” era poco claro. En 2014, Blockstream intentó lograr una solución basada en UTXO sin estado. El diseño se implementó en el código de base de cadena lateral original de Elements. Sin embargo, este enfoque se abandonó luego debido a problemas inherentes de seguridad y censura y Elements optó por un conector federado y se convirtió en la cadena lateral Liquid. Por lo tanto, el término cadena lateral no determina el sistema de comunicación real que lleva a cabo la transferencia de activos que mantiene al conector 1:1. Con el advenimiento de las blockchains de tokens múltiples, un sistema de interoperabilidad para administrar un conector bidireccional se convirtió en un puente de tokens. Un puente de tokens puede conectar a dos blockchains arbitrarias en las que ninguna sea una cadena lateral de la otra. 

El primer puente de tokens listo para la producción se implementó de manera integrada en la cadena lateral RSK lanzada en 2017. El puente RSK es híbrido: la dirección de Bitcoin a RSK se basa totalmente en SPV y cuenta con control de estado. Esto significa que se alcanzan las propiedades de descentralización y la resistencia a la censura deseadas, a la vez que se federa la dirección de RSK a Bitcoin. Dado que Bitcoin no puede verificar el consenso de RSK, no se puede implementar una solución descentralizada y resistente a la censura para la transferencia de bitcoins desde RSK a Bitcoin: una implementación dúplex es imposible. Sin embargo, el conector actual RSK-Bitcoin, que se muestra en el siguiente diagrama, constituye una de las mejores soluciones posibles.

El conector bidireccional híbrido SPV federado de RSK

El puente RSK-Bitcoin nunca fue hackeado y cuenta con un tiempo de actividad récord del 100 %. El puente RSK-Bitcoin utiliza Módulos de Seguridad de Hardware (HMS, por sus iniciales en inglés) para proteger las claves privadas de una multifirma grande. Los HMS evolucionaron con el correr del tiempo y la nueva generación de HSM de RSK sincroniza con la mejor cadena al verificar la prueba de trabajo de la cadena. El resultado indica que ni siquiera la mayoría de los funcionarios de la federación puede engañar o censurar las transacciones de conectores. Sin embargo, un puente federado presenta desventajas: todavía se basa en un pequeño grupo de entidades que necesitan mantener los HSM bien conectados a la red así como en la honestidad de las empresas que fabrican los HMS de que no introduzcan canales encubiertos, generadores de números aleatorios tendenciosos o backdoors. En un mundo de protocolos descentralizados, los puentes federados deberían existir únicamente hasta que se creen mejores sistemas descentralizados para reemplazarlos. Un puente descentralizado verdaderamente seguro entre dos blockchains debe basarse en cada blockchain al verificar el consenso de la otra de manera breve.

Tender un puente de tokens con los clientes ligeros de SPV 

Un cliente ligero SPV es un sistema liviano que acepta pruebas concisas de pruebas de trabajo acumuladas con el fin de descubrir cuál es la mejor cadena de muchos candidatos posibles, con un alto nivel de seguridad criptoeconómica. Los clientes ligeros SPV son ideales para crear un puente basado en un smart contract entre dos blockchains basadas en pruebas de trabajo. Pero los clientes SPV estándar tienen muchas limitaciones, especialmente respecto de las blockchains con tasas altas de bloque. RSK produce una tasa alta de bloques (aproximadamente uno cada 30 segundos), lo que significa que la verificación de encabezado solamente entre cadenas se torna costosa, tanto en lo que respecta al espacio como al tiempo de verificación. Ethereum es peor en este sentido, debido a una tasa de bloque más alta y una verificación de la prueba de trabajo más pesada. El diagrama a continuación describe un hipotético puente descentralizado sobre la base de una verificación de consenso de encabezado solamente entre cadenas. Cada blockchain mantiene una representación de la mejor cadena de la otra blockchain en modo SPV.

Un puente SPV con control de estado hipotético

En 2015, se sabía cómo crear pruebas cortas SPV sobre la base de un juego interactivo de desafío-respuesta de encabezado de bloque. Estos juegos pueden volverse no interactivos mediante el uso de la transformación Fiat-Shamir (que más adelante se denominó Pruebas no interactivas de la prueba de trabajo o NiPoPoWs). La idea es que el prover (probador) se comprometa con una blockchain y el retador le pida al prover una cantidad de encabezados de bloque, que el prover debe revelar, junto con información que demuestre que el bloque revelado pertenece a la misma blockchain conectada. Sin embargo, no se supo cómo producir pruebas para una blockchain de dificultad variable hasta el año 2017. En 2017, se lanzó el protocolo FlyClient y finalmente se resolvió este problema. 

Protocolo no interactivo de FlyClient (simplificado)

Sin embargo, aplicar FlyClient a las blockchains existentes parecía imposible sin cambios de consenso, ya que FlyClient requiere de compromisos periódicos con todos los hashes de bloque anteriores en los encabezados de bloque. Los compromisos se organizan en un árbol (denominado MMR aumentado) y la prueba de trabajo acumulativa y las marcas de tiempo se almacenan en cada nodo intermedio del árbol MMR. 

En 2019, comenzamos a investigar cómo conectar RSK y Ethereum. Analizamos maneras de habilitar FlyClient en Ethereum sin modificar su consenso y descubrimos un método que se extiende hasta FlyClient para que lo logre y que utiliza pruebas breves. Este hallazgo se convirtió en lo que denominamos HawkClient, que pertenece a una nueva categoría de protocolos que llamamos Prueba interactiva criptoeconómica de la prueba de trabajo (CIPoPoW). El protocolo HawkClient funciona en todas las plataformas de smart contract basadas en EVM, como RSK, Ethereum y Ethereum-Classic. Desde ya que si una blockchain implementa el compromiso del árbol MMR a nivel nativo, el protocolo queda sumamente simplificado. 

Presentación de HawkClient

En palabras simples, HawkClient es un sistema de smart contract descentralizado e interactivo para mantener un smart contract en una blockchain “anfitriona” sincronizada con una blockchain “remota” extranjera, lo que permite la transferencia de información con valor monetario explícito. Dos sistemas HawkClient implementados de manera reflejada entre dos blockchains brindan los cimientos para un puente de token descentralizado, permitiendo así la transferencia de tokens de una blockchain a la otra.

Puente de token basado en dos sistemas de HawkClient reflejados

Podemos transferir tokens arbitrarios porque las transferencias de tokens son acotadas en valor, ya que las tokens tienen valuaciones de mercado conocidas en las que las transferencias brindan montos de tokens explícitos. Esto elimina la necesidad de seguridad a nivel criptográfico y permite que el puente funcione según un modelo criptoeconómico de seguridad, reduciendo los tamaños de las pruebas. En este modelo criptoeconómico, las transferencias se organizan en lotes y se aseguran con una fianza de cumplimiento.

Un sistema de HawkClient simplificado se basa en cuatro roles: los provers (probadores), un verificador, un Updater de AMMR (Merkle Mountain Range aproximado) o AMMR-Updater (más información sobre este rol abajo) y los usuarios. Un prover se compromete con la mejor cadena de la blockchain remota y entrega el compromiso al verificador. Luego, el verificador emite un desafío y el prover crea una prueba HawkClient que contiene un subconjunto seleccionado de encabezados de la mejor cadena y pruebas de enlazado. El subconjunto de encabezados de bloque que se debe recuperar se selecciona mediante muestras realizadas en el espacio de dificultad acumulativo, sobre la base de un generador de números pseudo-aleatorio cuya semilla proviene del desafío. En el caso de un puente de token, todo el proceso se repetiría aproximadamente una vez al día.

El verificador es un smart-contract implementado en la blockchain anfitriona que verifica las pruebas de HawkClient y utiliza las pruebas para prolongar y mantener una representación de la blockchain remota. El verificador es similar a un nodo SPV de blockchain, pero se ejecuta en consenso. Esto es esencialmente lo que realizan RSK y btcrelay. El verificador permitirá que otros provers desafíen la prueba o presenten pruebas alternativas durante un periodo de desafío y luego, aceptará la prueba con la prueba de trabajo acumulativa más alta. Sin embargo, desde el modelo de btcrelay, el verificador lleva a cabo un protocolo de desafío-respuesta con el prover, y por lo tanto, se desalientan los típicos ataques de censura de transacción. Los usuarios interactúan tanto con las blockchain anfitrionas como con las remotas, y esa interacción genera eventos en la blockchain remota que se registran en los recibos. Luego, el prover informa estos eventos a la blockchain anfitriona. Los smart contracts de la blockchain anfitriona pueden escuchar los eventos informados e interactuar con ellos. 

El puente RSK-Ethereum

El puente RSK-ETH conecta a RSK con Ethereum y permite la transferencia de cualquier token ERC-20 entre dos blockchains. IOV Labs está desarrollando activamente este punto. El puente se basa en HawkClients. Asimismo, el puente se diseñó con un conjunto de características únicas. Por ejemplo, le permite al prover elegir el monto monetario de la fianza de cumplimiento que está dispuesta a comprometer, a cambio de una autorización para suministrar una prueba de un tamaño específico, a la vez que garantiza que el engaño siempre sea una estrategia condenada al fracaso. Por ejemplo, el prover puede ofrecerse a responder a más consultas realizadas por el verificador, reduciendo la fianza de cumplimiento, pero aumentando el tamaño de la prueba. Si las tarifas de transacción son altas, el prover puede aumentar la fianza de cumplimiento para reducir el tamaño de la prueba y las tarifas de transacción. Dado que la fianza se reduce si se detecta un engaño, el engaño nunca constituye una estrategia racional y la seguridad criptoeconómica está garantizada. Asimismo, HawkClient exige que los compromisos sean dentro de la cadena, y que los desafíos provengan de los siguientes hashes de bloque, de modo que el atacante no pueda probar millones de compromisos diferentes fuera de línea. Si suponemos que el atacante controla menos del 50 % de la tasa de hash de cualquier blockchain involucrada, solo podría realizar un único compromiso. En otras palabras, dado que el sistema es interactivo, el atacante no puede violentar el compromiso fuera de línea para obtener un desafío favorable. A modo de ejemplo, si establecemos un límite a la probabilidad de engaño de 1 en un millón, creamos un gran factor disuasivo para cualquier intento de engaño. Esta probabilidad de engaño que generalmente se convierte en una baja seguridad criptográfica produce una seguridad criptográfica extremadamente alta. Por último, el puente utiliza un mercado de token especial y simplificado que sirve a modo de oráculo para descubrir un límite superior a los precios actuales de token, relacionados con la moneda nativa. Este mercado presenta largas demoras (de semanas) tanto para la compra como para la venta y no esperamos que se utilice para ninguna transacción real a menos que una parte intente engañar respecto de los precios de los tokens. 

Un sistema HawkClient para comunicar información de Ethereum a RSK

Otra característica interesante del puente RSK-Eth es que cualquiera puede convertirse en prover siempre que esté dispuesto a comprometer la fianza de cumplimiento. Asimismo, hemos desarrollado un método muy eficiente para verificar pruebas de trabajo de ETHash sin la necesidad de un código de operación especial. Profundizaremos sobre este tema en la próxima publicación en nuestro blog.

Características esenciales de una prueba de HawkClient

La siguiente sección describe las características principales de las pruebas de HawkClient y especialmente cómo interactúan para permitir la creación de un puente descentralizado.

Pruebas interactivas

Las pruebas de HawkClient son interactivas. El protocolo involucra al menos a un prover. Asimismo, cada prover tiene el rol de desafiar las pruebas potencialmente falsas de otros provers. Un prover se compromete con una prueba, y un smart contract especial, que nosotros denominamos verificador de HawkClient, elige una semilla de desafío de la cual deriva un conjunto de consultas. Luego, el prover debe responder estas consultas y las respuestas se envían nuevamente al smart contract verificador, que las valida.  Luego de esta fase inicial, los demás usuarios pueden desafiar al prover para que ofrezca más certeza o pueden convertirse en provers y presentar una prueba de una blockchain con mayor dificultad acumulativa para invalidar a la anterior.

Pruebas criptoeconómicas

Las pruebas de HawkClient son criptoeconómicas, lo que significa que existe una determinada probabilidad no despreciable de que el atacante logre el engaño. Para impedir un ataque, el protocolo obliga a los provers a depositar monedas con anterioridad a modo de “fianzas de cumplimiento” de forma que el pago esperado para el atacante al ejecutar el engaño sea inferior al pago esperado ante una conducta honesta. El puente ofrece un subsistema que sirve como oráculo autónomo para establecer los precios de las tokens.

El monto monetario que puede transferir el puente por día es limitado porque las blockchains basadas en pruebas de trabajo se encuentran en riesgo de ataques de doble gasto. Para engañar al puente, un atacante puede incurrir en un costo equivalente al arrendamiento del 51 % de la tasa de hash de la blockchain remota por 24 horas. Por lo tanto, suponiendo que hay suficiente hardware de minería y que actualmente esté disponible para ser arrendado, el monto de dinero que el puente puede transferir por periodo de tiempo es limitado. La siguiente tabla muestra los costos aproximados de electricidad del 51 % de ataques sostenidos durante 24 horas en blockchains diferentes desde enero de 2020.

Dado que los precios de la criptomoneda varían frecuentemente, el puente debe parametrizarse con un margen de seguridad lo suficientemente amplio. Por ejemplo, el valor que el puente RSK-ETH puede transferir por día desde Ethereum a RSK se limitaría a USD 600 mil, y en la dirección opuesta, a USD 3 millones. 

Pruebas graduales

Existen dos extremos en los protocolos de smart contracts que deben verificar las entradas externas. Por un lado, existen protocolos “perezosos” u “optimistas” cuya seguridad depende por completo de la disponibilidad y la resistencia a la censura de la capa dentro de la cadena. En los protocolos optimistas, un prover afirma una declaración y la capa del smart contract espera un desafío respecto de la afirmación, por medio de un fraude-prueba. Operan conforme al patrón de diseño “afirmar-desafiar”. Si la declaración no se objeta durante un periodo fijo determinado, entonces se asume que es verdadera. Se la considera perezosa porque el smart contract no realiza la verificación por sí mismo. TrueBit adoptó este modelo y recientemente lo hizo Arbitrum. En el otro extremo, algunos protocolos “estrictos” verifican cada afirmación externa y no hay necesidad de desafíos; en algunos casos, utilizan Pruebas de Integridad de Computación, como zk-SNARKs. Los protocolos perezosos presentan la desventaja de incentivar la censura de transacción y la colusión de mineros.  

La única desventaja de los protocolos sólidos es que son costosos en cuanto a los recursos de ejecución (gas) y este costo debe compartirse de alguna manera entre los usuarios del protocolo. En un nivel intermedio se encuentran los protocolos graduales. Los protocolos graduales comienzan con una afirmación y luego los contratos de verificación realizan un tipo de verificación probabilística para lograr un nivel inicial de certeza. Luego otros usuarios pueden desafiar la prueba, pedirle al verificador que solicite mayor certeza, brindar otra prueba competidora o esperar a que se acepte una prueba. 

Optimista, sólido y gradual para FlyClient

Para cualquier protocolo, existen también otros costos turbios como la componibilidad del ataque: ¿qué sucede si el atacante decide utilizar una única prueba para engañar a varios sistemas no relacionados? Demostrar la seguridad requeriría conocer cada sistema posible del que pueda beneficiarse. 

Compromisos de MMR esporádicos y persistentes

Si la blockchain remota no es compatible con FlyClient a nivel nativo, HawkClient puede buscar los compromisos de MMR en el almacenamiento de un smart contract fijo denominado AMMR Updater. Este contrato utiliza el código de operación BLOCKHASH para recopilar los hashes de bloque anteriores y crear un árbol actualizado. AMMR significa Approximate Merkle Mountain Range. Este árbol contiene los límites a la dificultad acumulativa real y los valores de tiempo. Los compromisos de AMMR no necesitan actualizarse en cada bloque. Se asume que se actualiza cada N bloques en promedio con llamadas externas al contrato de AMMR Updater. Una vez que se actualizan los N bloques en promedio, el tiempo por bloque será exacto (puede accederse al tiempo por bloque utilizando el código de operación BLOCKTIME), pero los tiempos por bloque de los bloques intermedios son desconocidos para el contrato. Un contrato de Ethereum no conoce la dificultad acumulativa exacta, ya que no existe dicho código de operación. Por lo tanto, cuando se considera el contrato de AMMR Updater, debe computarse un límite en la dificultad acumulativa. El protocolo garantiza que la dificultad acumulativa siempre se encontrará dentro de una ventana de error porcentual. La existencia de un límite de error se justifica porque la dificultad del bloque no puede variar mucho entre las actualizaciones de AMMR. Consideremos Ethereum, donde la dificultad del bloque puede cambiar por un factor de +-1/2048 entre los bloques. La aceptación de actualizaciones de AMMR a una distancia máxima de 256 bloques implica que la dificultad del bloque puede aumentar o disminuir hasta un 6,65 % (en el punto máximo/mínimo, alrededor del bloque 128). Sin embargo, debe alcanzar la verdadera dificultad del bloque en el último bloque, porque AAMR Updater verifica esto mediante el código de operación DIFFICULTY. Por lo tanto, AMMR Updater puede computar límites a la dificultad acumulativa en el bloque actual. En el peor de los casos, si no hubo una actualización en los 256 bloques anteriores, y la dificultad del bloque no cambió desde la última actualización, este límite representa un aumento o una disminución de hasta 3,2 % de la dificultad acumulativa de la blockchain real. Por lo tanto, incluso si se oculta la dificultad real al smart contract, puede seguirla de cerca. Asimismo, para cambiar el 3,2 % de dificultad sin ser detectado, el atacante debe minar 256 bloques o debe arreglárselas para evitar recibir consultas respecto de los 256 encabezados de bloque.

Los árboles AMMR y EMMR

Todos los sistemas que interactúan con HawkClient deben conocer la dirección del contrato de AMMR Updater. Cualquiera puede verificar el código desplegado al inspeccionar la transacción que crea el contrato de AMMR Updater. Sin embargo, hay un ataque sutil. Los creadores de AMMR Updater pueden crear un contrato similar con la misma dirección en otra blockchain que comparta la estructura del encabezado de bloque y la prueba de trabajo y que se haya bifurcado anteriormente. En esta blockchain, el contrato podría implementarse con un bytecode de VM diferente. Para prevenir este ataque, el contrato de MMR Updater debe implementarse con CREATE2 y debe utilizar el código de operación CHAINID (EIP-1344) para verificar que se está ejecutando en la plataforma meta durante la construcción y abortar la construcción si no lo está haciendo. Este código de operación está disponible en Ethereum desde la bifurcación dura de Estambul.

Resumen

En IOV Labs estamos trabajando en un puente descentralizado que pueda conectar las principales blockchains de prueba de trabajo. El centro de este puente es el protocolo HawkClient, que es una extensión de FlyClient. Existen varias diferencias entre FlyClient y HawkClient. 

En HawkClient las pruebas son interactivas:

🔴 La seguridad de las pruebas es criptoeconómica, no criptográfica.

🔴 Los sistemas requieren fianzas de cumplimiento. Si se utiliza para un puente bidireccional, puede requerir fianzas de cumplimiento tanto en la moneda nativa como en tokens.

🔴 Las pruebas son graduales.

🔴 Los compromisos AMMR son esporádicos pero persistentes, sin la necesidad de cambiar el consenso de la blockchain.

🔴 Los provers también se comprometen con un segundo árbol EMMR que contiene dificultades acumulativas exactas. El árbol no necesita producirse en consenso.

🔴 Las pruebas implican uno o más provers y un verificador del smart contract. Tanto los provers como el smart contract pueden convertirse en retadores.

🔴 La mejor cadena aumenta de manera monotónica y es inmutable.

🔴 El crecimiento de la mejor cadena se retrasa (latencia desde la punta probada hasta la mejor punta de cadena).

Dos sistemas de HawkClient implementados de manera reflejada entre dos blockchains forman las bases del puente RSK-ETH. El puente se encuentra actualmente en desarrollo y pronto anunciaremos la fecha de su implementación en RSK testnet. Al mismo tiempo, estaremos lanzando el código fuente a la comunidad, brindando toda la información sobre cómo utilizarlo desde las wallets y los smart contracts. Estamos felices de estar trabajando en el primer puente criptoeconómico verdaderamente descentralizado. El puente RSK-ETH será el primer paso en la construcción de un pilar de comunicación para todas las blockchains, lo que hará que todas las tokens de blockchain compatibles con EVM estén disponibles para las aplicaciones DeFi on Bitcoin, en RSK.

Fuentes: coincrispy, blockstream.com/sidechains.pdf, iovlabs.org,

Rootstock (RSK) busca construir una plataforma para trabajar con smart contracs o contratos inteligentes sobre la blockchain de Bitcoin.

Para lograr esto, RSK usa un protocolo de segunda capa del tipo sidechain o cadena lateral. Esto le permite realizar una comunicación bidireccional con la blockchain de Bitcoin. Todo ello mientras le permite al usuario realizar transacciones de criptomonedas usando el token nativo de RSK. Este token nativo llamado RSK Smart Bitcoin (RBTC) es un token anclado a Bitcoin en una proporción uno-a-uno (1:1). Gracias a este token, es posible disfrutar del poderoso y flexible sistema de contratos inteligentes y otras funcionalidades adicionales que el protocolo RSK es capaz de ofrecer.

En este punto es bueno preguntarnos ¿Por qué empezó a desarrollarse este protocolo? ¿Cómo funciona este protocolo? ¿Por qué es tan importante? ¿Qué ventajas y características nos ofrece? 

Comienzo del desarrollo de RSK