HawkClient: cómo construir un puente totalmente descentralizado entre RSK y Ethereum
Por Sergio Demián Lerner, Director Científico de Innovación de RSK
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 durante 3 años. En la actualidad, estamos trabajando en un puente totalmente descentralizado entre RSK y Ethereum. Esta publicación presenta los detalles técnicos de este nuevo puente y el protocolo descentralizado subyacente que lo impulsa.
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. Existen algunas diferencias criptoeconómicas importantes entre un puente de tokens que conecta blockchains independientes y uno que impulsa una cadena lateral respecto de la disponibilidad de una moneda independiente que pueda utilizarse como garantía y quemarse por mala conducta pero no profundizaremos sobre esta distinción en este artículo.
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. FlyClient puede ajustar la función de selección de índice de bloque para que coincida con los cambios de dificultad. Asimismo, FlyClient puede adaptarse a diferentes tamaños de pruebas, brindando diferentes límites de probabilidad de engaño según las necesidades de seguridad del cliente.
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. Al tener este sistema de oráculo, podemos ejecutar las fianzas de cumplimiento en moneda nativa en lugar de tokens, y podemos habilitar a múltiples provers sin exigirle a cada uno de ellos que deposite cada token posible.
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.
Si bien esto es solamente una simplificación del modelo de riesgo, todos los ataques identificados tienen un costo que crece de manera lineal con la dificultad acumulativa de la prueba HawkClient (que se relaciona con la dificultad de la blockchain remota) y la dificultad de la blockchain del verificador.
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. Podría demostrarse que los protocolos perezosos son seguros a nivel criptoeconómico si pudiéramos estimar el costo de un ataque de censura de transacción. Sin embargo, esta es una tarea abrumadora, ya que la censura es económica de realizar pero difícil de demostrar y generalmente imposible de atribuir a un minero específico. Los mineros ponen su reputación en peligro, pero es difícil de calcular para un observador externo.
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. Cuando una primera prueba es desafiada por una prueba competidora, el primer prover tiene la oportunidad de probar más pruebas de trabajo acumulativas para ganar la carrera y convertirse en la mejor cadena. Puede haber pruebas adicionales hasta que uno de los provers se rinda, ya que no tiene más pruebas de trabajo acumulativas para mostrar. La última prueba no desafiada será seleccionada como la mejor cadena.
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.
Dado que el árbol AMMR no almacena valores exactos de dificultad acumulativa, al presentar pruebas con muchas actualizaciones de AMMR, los límites de dificultad acumulativa en los bloques consecutivos se superpondrán. Esto significa que si el atacante es desafiado con una consulta de una indexación de bloque por una dificultad acumulativa específica x, puede utilizar esta ambigüedad para elegir uno entre varios bloques adyacentes cuyos límites de dificultad incluyen x. De esta manera, el atacante podría minar solo un bloque por cada intervalo que no se superponga, reduciendo así la cantidad de trabajo que necesita. Para impedir este ataque, el prover debe también comprometerse a un segundo árbol Merkle, el Exact Merkle Mountain Tree (EMMR), que contiene las dificultades acumulativas y los tiempos exactos para cada bloque. Este árbol se ve aumentado con dificultades acumulativas y tiempos acumulativos en cada nodo intermedio. La función original y las verificaciones que se hayan realizado en los nodos de AMMR ahora se dividen entre estos dos árboles. Para cada consulta, el prover debe mostrar la rama de AMMR y de EMMR. La rama de EMMR se utiliza para localizar el número de bloque con un compromiso acumulativo específico y luego el árbol de AMMR se cruza buscando este número de bloque. Al hacerlo, se realiza una verificación cruzada de todos los límites de dificultad de tiempo acumulativo y dificultades acumulativas. El siguiente diagrama muestra una blockchain hipotética que comienza con una dificultad acumulativa de 0 en la que la dificultad de cada bloque es un 10 estable. Por consenso, la dificultad puede aumentar o disminuir un 10 % en cada bloque. Luego de 8 bloques, la dificultad acumulativa real (80) se ha desviado de las dificultades acumulativas mínimas y máximas que podrían haberse logrado sin conocer la dificultad real de cada bloque intermedio. Solo se conoce la dificultad del último bloque. Cada casilla verde muestra la dificultad acumulativa mínima y máxima. Durante la verificación de la prueba, el árbol EMMR se utiliza para localizar los bloques y luego, se busca la rama del árbol AMMR por número de bloque. En cada paso, se verifica que el rango limitado contenga el rango exacto.
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.