Si desea obtener RBTC, hay varias formas diferentes de hacerlo, que van desde intercambios, intercambios descentralizados e incluso intercambios entre pares: generalmente son más fáciles de usar. El propio protocolo de cadena de bloques de RSK admite un método integrado en su protocolo de cadena de bloques que permite intercambios bidireccionales entre BTC y RBTC: el RSK PowPeg. Por lo general, es más difícil de usar y está destinado a personas con conocimientos más técnicos.

Incluso si tiene la intención de utilizar esos otros servicios para obtener RBTC, sigue siendo importante conocer el PowPeg, ya que estos otros servicios dependen en última instancia del PowPeg.

Lo que hace el RSK PowPeg

Un protocolo de clavija bidireccional (2WP) es un protocolo que permite la transferencia de una criptomoneda de una cadena de bloques principal a una cadena de bloques secundaria y viceversa. Requiere baja confianza de terceros.

En el caso de RSK, la cadena de bloques principal es Bitcoin y la cadena de bloques secundaria es RSK. Cada RBTC (o fracción de RBTC) desbloqueado en la plataforma RSK requiere que BTC esté bloqueado en la cadena de bloques de Bitcoin. Este mecanismo asegura que haya una relación uno a uno entre BTC y RBTC (1 BTC = 1 RBTC), lo cual está garantizado por el protocolo RSK.

Cuando un usuario desea intercambiar entre BTC y RBTC, debe enviar la criptomoneda a la dirección especificada por el PowPeg, lo que activa un conector de entrada o de salida, que describiremos con más detalle a continuación.

Cómo funciona el RSK PowPeg

Existen algunas restricciones y validaciones realizadas cuando se realiza una transacción de entrada o salida, tales como:

  • valores mínimos aceptados,
  • formatos de dirección BTC admitidos para hacer un peg-in,
  • cantidad máxima de Bitcoins que se pueden bloquear en el PowPeg al mismo tiempo

Los usuarios no pueden elegir en qué dirección recibirán sus activos, sino que la dirección de recepción se determina utilizando la clave pública del remitente, por lo que ambas cuentas están controladas por la misma clave privada.

Tenga en cuenta que en la próxima versión de RSK (IRIS-3.0), esto cambiará parcialmente. El PowPeg permitirá al usuario especificar la dirección de recepción para los peg-ins (BTC → RBTC).

El proceso de conexión y desconexión se realiza completamente utilizando el software de billetera Bitcoin y el software de billetera RSK. La responsabilidad de realizar las comprobaciones y validaciones necesarias para el cumplimiento de las reglas de PowPeg recae en el usuario, ya que no existe una aplicación o herramienta para realizar esto.

Advertencia: el usuario debe ser consciente de esta falta de "barandillas" y aceptar el riesgo de que las transacciones puedan ser rechazadas o los montos transferidos puedan quemarse (perderse permanentemente), si cometen errores durante el proceso. Por lo tanto, solo recomendamos a los usuarios con experiencia técnica que realicen conexiones y desconexiones por su cuenta.

Ventajas:

  • 🔷Sin custodia, los usuarios no otorgan a ningún tercero la custodia de los fondos transferidos.
  • 🔷Sin tasas fijas (excepto las tasas de la transacción BTC).
  • 🔷Puede procesar montos de transacciones más grandes.
  • 🔷No se requiere registro ni KYC.

Contras:

  • 🔷Alto tiempo de espera.
    • Por razones de seguridad, es necesario que se produzca una cantidad significativa de confirmaciones de transacciones antes de que se liberen los fondos.
  • 🔷Los valores mínimos de transacción de clavija de entrada/salida permitidos son altos
    • Actualmente, las cantidades deben superar los 0,005 BTC y 0,004 RBTC, respectivamente
  • 🔷Difícil de usar para usuarios habituales sin experiencia técnica.
  • 🔷Las tarifas de la red de Bitcoin para las clavijas de salida pueden ser altas.

Recibir RBTC (peg-in) 

Peg-in es el término estándar para el proceso que transfiere bitcoins de la red Bitcoin a la red RSK.

Para realizar un peg-in, envíe los bitcoins (BTC) a la dirección de PowPeg en la red de Bitcoin y, posteriormente, informe al Bridge sobre esta transacción. El Powpeg posteriormente libera bitcoins (RBTC) en la red RSK.

Para resumir, un peg-in:

  • 🔷Convierte BTC a RBTC
  • 🔷Bloquea BTC en la red Bitcoin
  • 🔷Lanza RBTC en la red RSK

Para obtener una guía paso a paso del proceso, consulte la guía de conexión (BTC → RBTC)

Envío de RBTC (peg-out)

Peg-out es el término estándar para el proceso que transfiere bitcoins de la red RSK a la red Bitcoin.

Para realizar peg-outs, envíe los bitcoins (RBTC) al Bridge. Luego, espere el número requerido de bloques de confirmación, después de lo cual Bridge construye la transacción para liberar bitcoins (BTC) en la red de Bitcoin.

En resumen, un peg-out:

  • 🔷Convierte RBTC a BTC
  • 🔷Bloquea RBTC en la red RSK
  • 🔷Lanza BTC en la red Bitcoin

Para obtener una guía paso a paso del proceso, consulte la guía de salida (RBTC → BTC)

Obtenga RBTC usando PowPeg

Mire este video de demostración que muestra una conversión entre BTC y RBTC utilizando el protocolo PowPeg.


Fuente: developers.rsk

      

  Si desea obtener RBTC, hay varias formas diferentes de hacerlo, que van desde intercambios, intercambios descentralizados e incluso inte...



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:

Actual Próximo cambio
Prueba de participación delegada (DPoS)Prueba de participación (PoS)
DelegarValidador
VotarParticipación
VotanteApostador
Voto propioAuto-apuesta
No votarDeshacer
Delegado activoValidador activo
Delegado en esperaValidador en espera
Peso del delegadoPeso del validador
ForjadoAcuñado
Estos cambios se reflejarán en todos los proyectos de Lisk, incluidos, entre otros:

Plataformas de la comunidad de Lisk:

  • Fuente: Blog de Lisk 
  •    


Con el lanzamiento de la plataforma Lisk, habrá un cambio de terminología de prueba de participación delegada (DPoS) a prueba de participaci...


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,

   

En este articulo presentamos un resumen del desarrollado por  Sergio Demián Lerner, Director Científico de Innovación de Rootstock (RSK) y u...


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


La historia detrás de Rootstock (RSK) comienza con Sergio Demian Lerner, un argentino que es considerado como uno de los investigadores de seguridad informática y criptomonedas más reconocidos en el mundo. Lerner conoce el mundo del Bitcoin en 2011 y desde entonces se muestra muy interesado en la misma. Inicialmente su trabajo en Bitcoin le lleva auditar y ser un bug hunter (buscador de errores) de Bitcoin. Una situación que le aporta un enorme conocimiento técnico sobre la tecnología blockchain.

En 2013, siendo parte del Core de desarrollo de Bitcoin, Lerner comienza a desarrollar nuevas ideas en pro de mejorar la privacidad, la eficiencia de los pagos y la descentralización de la plataforma. Fue este proceso de investigación lo que llevó a la creación de QixCoin en ese mismo año. QixCoin era una criptomoneda con capacidad turing completa que buscaba mejorar la capacidad de Bitcoin para desplegar aplicaciones descentralizadas.

Sin embargo, la idea de QixCoin fue retrabajada y en 2015 evolucionó a la que conocemos hoy como RSK. Rootstock (RSK) brinda una experiencia de pago mejorada con confirmaciones casi instantáneas. Además, tiene la capacidad de alcanzar 300 transacciones por segundo (300 TPS) y confirmar la mayoría de los pagos en menos de 20 segundos. Todo estos sin dejar atrás las bondades de la blockchain de Bitcoin, como lo son su protocolo de consenso PoW y un proceso de minería fusionada basado en SHA-256D.

Desde entonces, RSK ha ido evolucionando como protocolo de segunda capa para ofrecer funcionalidades que Bitcoin originalmente no tiene o son limitadas.

Funcionamiento de RSK


Rootstock (RSK) es un protocolo de segunda capa del tipo sidechain o cadena lateral. Esto significa que todo el funcionamiento de RSK tiene lugar en una blockchain alterna a la blockchain de Bitcoin.

La razón para esto, es que de esta forma los desarrolladores de RSK pueden crear un sistema completamente adaptado a sus necesidades para su funcionamiento. Así se pueden alterar distintas variables de la blockchain, con la finalidad de hacer que sea más rápida o con nuevas características. Pero al final, cada interacción dentro de esta sidechain termina siempre escrita en la blockchain de Bitcoin. Esto último es lo que brinda la seguridad de RSK. Puesto que todo comienza en Bitcoin, llegas a la sidechain de RSK, y al terminar, todo queda escrito en la blockchain de Bitcoin de forma inalterable.

Y es que básicamente el funcionamiento de RSK comienza cuando los usuarios transfieren bitcoins a una sidechain de RSK. En se momento, el bitcoin transferido se transforma en RSK Smart Bitcoins (RBTC) en una proporción 1:1 con bitcoin. El token RBTC es la moneda nativa utilizada en RSK Blockchain y es usada para todos los procesos dentro de la sidechain RSK. Desde pagarle a los mineros por las transacciones hasta el procesamiento de los contratos inteligentes dentro de la plataforma.

Otra característica de RBTC, es que esta moneda no tiene una emisión estipulada. En su lugar, los RBTC se crean a partir de los bitcoins transferidos desde la blockchain de Bitcoin. Una situación que ayuda a mantener el equilibrio dentro del ecosistema económico de RSK evitando manipulaciones en el precio de su token.

Pero adicional a esto, existen una serie de partes que son vitales para el funcionamiento de RSK, y estas son:

🔴Sidechains o Cadenas laterales

Una sidechain o cadena lateral es una blockchain independiente cuya moneda nativa está vinculada al valor de una moneda perteneciente a la blockchain original. Esta vinculación es creada de forma automática mediante el uso de pruebas de pago. Dentro de esta sidechain, se puede movilizar este token nativo tal cual como si fuera una criptomoneda normal. De hecho, el funcionamiento de la sidechain es casi idéntico a una blockchain normal, incluyendo la necesidad de un protocolo de consenso, la emisión de bloques y la verificación de las transacciones. 

Esto hacer de las sidechains un tipo de protocolo de segunda capa muy usado y enfocado a brindar nuevas funcionalidades a las blockchain sin alterar el protocolo base u original de una blockchain. Por esa razón, son perfectas para implementar mejoras que de otra forma requieren grandes cambios sobre la blockchain original, pero sin afectar a la misma. 

Rootstock (RSK) está implementado como un protocolo de segunda capa que hace uso de sidechain para funcionar. Para ello, RSK implementa un conector bidireccional que permite intercambiar BTC y RBTC de forma libre y automática.

Gracias a esto, RSK puede crear canales de intercambio con Bitcoin que permiten a los usuarios acceder a las funcionalidades de RSK. Esto es posible gracias a un sistema manejado por nodos semi-confiables denominado como Federación. Son estos nodos los encargados de recibir, bloquear y proteger el bitcoin que entra a la sidechain de RSK. Por este trabajo, los nodos reciben el 1 % de las tarifas de transacción generadas en RSK. Un pequeño incentivo que sirve para cubrir los gastos de hardware, los costos de mantenimiento, y las ganancias para mantener el proceso. 

🔴RVM, el corazón de RSK

El corazón de Rootstock (RSK) reside en su máquina virtual, la RSK Virtual Machine (RVM). Gracias a ella, RSK es capaz de proveer una plataforma Turing completa sobre la cual ejecutar smart contracts o contratos inteligentes. Estos contratos son fundamentales para RSK, puesto que la finalidad de este proyecto, es proveer la estructura y capacidad para que puedan implementarse contratos inteligentes sobre Bitcoin sin mayores dificultades.

Estos contratos son ejecutados por todos los nodos completos de la red de RSK. El resultado de la ejecución de un smart contract puede ser el de mensajes entre contratos, creando transacciones monetarias y cambiando el estado de la memoria persistente de los contratos.

Otro punto a favor de RVM es su compatibilidad con Ethereum Virtual Machine (EVM). Gracias a esta compatibilidad es posible portar los contratos inteligentes de Ethereum a RSK con un mínimo de trabajo. De hecho, al hacerlo se ven beneficiados por la mayor capacidad de procesamiento de transacciones de RSK (300 TSP) con respecto a Ethreum (22 TPS). Esto significa transacciones más rápidas y mejor interacción entre contratos, DApps y los usuarios.

Pero más allá de eso, Rootstock (RSK) busca transformar RVM en una máquina virtual de alto rendimiento. Para ello están trabajando en dos puntos importantes: la paralelización de operaciones (RSKIP-4 y RSKIP-144) y la reformulación en la ejecución de instrucciones de forma dinámica y en formato bytecode. Esto significa que la nueva VM será capaz de ejecutar tareas de forma paralela y en un formato de código más optimizado y veloz, mejorando así la escalabilidad y seguridad de la misma.

🔴Merged mining o minería fusionada

La  minería  fusionada  es una forma de minería  que permite a los mineros  de Bitcoin minar simultáneamente otras criptomonedas con un costo marginal casi igual a cero. La misma infraestructura y configuración de minería que utilizan para minar Bitcoins se reutiliza para minar RSK de manera simultánea.  Esto significa que, dado que RSK recompensa a los mineros con tarifas de transacción adicionales, el incentivo para la minería fusionada es alto.

Pero el beneficio de la minería fusionada va más allá de mayores incentivos para los mineros. Esta técnica permite que RSK aproveche la red Bitcoin para ofrecer un nivel de seguridad al mismo nivel que esta criptomoneda.

Fuente: altcoinbuzz, rsk.co, cointelegraph, academy.bit2me

    


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