Por Sergio Demian Lerner, cientista-chefe de inovação da RSK

Fazer a ponte entre blockchains de forma totalmente descentralizada e prescindindo de mecanismos de confiança é um dos tesouros escondidos da pesquisa blockchain. Na IOV Labs, criamos em 2016 a primeira ponte federada sólida que há 3 anos dá suporte à paridade 1:1 entre RSK e Bitcoin. Agora, trabalhamos em uma ponte totalmente descentralizada entre RSK e Ethereum. A presente postagem traz os detalhes técnicos dessa nova ponte, bem como do protocolo descentralizado subjacente que lhe dá apoio.

Introdução

Antes de mais nada, para compreendermos como movimentar tokens entre blockchains, vamos analisar alguns termos comumente usados e sua história. O termo paridade bidirecional (também paridade 1:1) se refere a um sistema que pretende tornar equivalentes economicamente dois tokens que existem em duas blockchains separadas. Quando a demanda em um dos lados aumenta, a paridade bidirecional deve permitir o fluxo de tokens do outro lado, mantendo a equivalência de preços. No ano de 2013, antes mesmo da concepção desse sistema, já se previa um futuro em que o Bitcoin pudesse ter diversas sidechains satélites conectadas à cadeia principal com paridades bidirecionais. Uma sidechain foi concebida como uma blockchain separada cujo ativo nativo é estrangeiro, acarretando, portanto, o pagamento de taxas sobre transações envolvendo esse ativo estrangeiro. Por não terem emissão interna de moedas, os blocos não pagam subsídios aos mineradores da sidechain. No entanto, por falta de um desenho de paridade bidirecional comprovado, o termo sidechain era vago. Em 2014, uma solução sem preservação de estado baseada em UTXO foi tentada pela Blockstream. O desenho foi implementado no código de base original da sidechain Elements, porém essa abordagem foi mais tarde abandonada por problemas inerentes de segurança e censura. A Elements passou a adotar uma paridade federada, tornando-se a sidechain Liquid. Portanto, o termo sidechain não determina o sistema de comunicação de fato que faz a transferência de ativos e mantém a paridade 1:1. Com o advento de blockchains de múltiplos tokens, passamos a chamar de ponte de tokens o sistema de interoperabilidade que gerencia certa paridade bidirecional. Com a ponte de tokens, é possível a conexão entre duas blockchains arbitrárias em que nenhuma é sidechain da outra. Há algumas diferenças criptoeconômicas importantes entre uma ponte de tokens que conecta blockchains independentes e outra que presta apoio a uma sidechain a respeito da disponibilidade de uma moeda independente que pode ser usada como lastro e queimada em casos de comportamento inadequado, mas não vamos nos aprofundar nessa distinção neste artigo. 

A primeira ponte de tokens pronta para funcionar foi implementada junto à sidechain RSK lançada em 2017. A ponte RSK é híbrida: a direção de Bitcoin para RSK é totalmente baseada em SPV com preservação de estado, ou seja, alcança as propriedades desejadas de descentralização e resistência à censura, ao passo que a direção de RSK para Bitcoin é federada. Como o Bitcoin não consegue verificar o consenso da RSK, não se pode implementar uma solução resistente à censura para a transferência de bitcoins da RSK para Bitcoin: uma implementação completamente duplex se torna impossível. No entanto, a atual paridade RSK–Bitcoin, demonstrada no diagrama a seguir, constitui uma das melhores soluções possíveis.

A paridade bidirecional de SPV federada híbrida RSK

A ponte RSK–Bitcoin nunca foi hackeada, contando com histórico de 100% de disponibilidade. Essa ponte usa Módulos de segurança de hardware (Hardware Security Modules – HSM) na proteção de chaves privadas de um multi-sig (múltiplas assinaturas) de grandes dimensões. Os HSMs evoluíram ao longo do tempo, de modo que a nova geração de HSMs da RSK se sincronizam com a melhor cadeia, verificando sua prova de trabalho. Dessa forma, nem mesmo a maioria dos funcionários da federação pode sabotar ou censurar as transações de paridade. Entretanto, uma ponte federada tem suas desvantagens: ainda depende de um pequeno conjunto de entidades que precisam manter os HSMs funcionando e bem conectados à rede; ainda depende da boa vontade das fabricantes de HSMs de não introduzir canais ocultos, geradores de numeração aleatória enviesados ou backdoors. Em um novo mundo de protocolos descentralizados, as pontes federadas devem existir somente até que sistemas descentralizados melhores sejam construídos para substituí-las. Uma ponte descentralizada realmente segura entre duas blockchains deve contar com cada uma das blockchains na verificação do consenso da outra de forma sucinta. 

Construindo uma ponte de tokens com clientes leves de SPV

Um cliente SPV é um sistema leve que aceita provas sucintas de prova de trabalho cumulativa a fim de descobrir qual a melhor cadeia honesta dentre as diversas candidatas com alto nível de segurança criptoeconômica. Os clientes SPV leves são ideais para a construção de uma ponte baseada em contratos inteligentes entre duas blockchains baseadas em prova de trabalho. Porém, os clientes SPV padrão têm muitas limitações, especialmente para blockchains com altas taxas de blocos. A RSK produz uma alta taxa de blocos (cerca de um a cada 30 segundos), ou seja, a verificação somente de cabeçalho entre cadeias se torna dispendiosa, tanto em termos de espaço quanto de tempo de verificação. Nesse sentido, o Ethereum é ainda pior, já que tem uma taxa de blocos mais alta e uma verificação de prova de trabalho muito mais pesada. O diagrama a seguir ilustra uma ponte descentralizada hipotética baseada na verificação de consenso somente de cabeçalho entre cadeias. Cada blockchain mantém uma representação da melhor cadeia da outra blockchain no modo SPV.

Uma hipotética ponte de SPV com preservação de estado

Lá em 2015, sabia-se em geral como criar provas SPV curtas com base em um jogo interativo de desafio e resposta do cabeçalho do bloco. Esses jogos podem se tornar não interativos por meio da transformação Fiat-Shamir (algo que vem sendo chamado de Provas não interativas da prova de trabalho, ou NiPoPoWs). A ideia é de que o provador se comprometa a uma blockchain e o desafiante solicite ao provador um número de cabeçalhos de bloco, que devem ser revelados pelo provador, junto de informações que comprovem que o bloco revelado pertence à mesma blockchain conectada. Porém, até 2017, ainda não sabíamos como produzir provas para uma blockchain de dificuldade variável. Finalmente, em 2017, o protocolo FlyClient chegou para resolver esse problema. O FlyClient é capaz de ajustar a função de seleção do índice do bloco para se adequar às mudanças de dificuldade. Também, o FlyClient pode ser calibrado para diferentes dimensões de prova, fornecendo diferentes limites de probabilidade de fraude, dependendo das necessidades de segurança do cliente.

O protocolo não interativo do FlyClient (simplificado)

Ainda assim, a aplicação do FlyClient a blockchains existentes parecia impossível sem mudanças de consenso, já que o FlyClient requer comprometimentos periódicos com todos os hashes de bloco nos cabeçalhos de bloco. Os comprometimentos são organizados em uma árvore (denominada MMR aumentada), ao passo que a prova de trabalho cumulativa e os timestamps são armazenados em cada nó intermediário da árvore MMR. 

Começamos em 2019 nossas pesquisas sobre como conectar RSK e Ethereum. Exploramos maneiras de habilitar o FlyClient no Ethereum sem qualquer modificação em seu consenso, de modo que descobrimos um método que estende o FlyClient no sentido de alcançar esse objetivo e ainda usar provas sucintas. Essa descoberta resultou no que chamamos de HawkClient, pertencente a uma nova categoria de protocolos batizada de Prova interativa criptoeconômica da prova de trabalho (CIPoPoW). O protocolo HawkClient funciona em todas as plataformas de contratos inteligentes baseadas em EVM, como RSK, Ethereum e Ethereum-Classic. É claro, se determinada blockchain não implementar o comprometimento da árvore MMR de forma nativa, o protocolo ficará sujeito a significativa simplificação. 

Apresentação do HawkClient

Em poucas palavras, o HawkClient é um sistema interativo e descentralizado de contratos inteligentes para a manutenção de um contrato inteligente em uma blockchain “anfitriã” sincronizada a uma blockchain “remota” estrangeira, permitindo a transferência de informações com valor monetário explícito. Dois sistemas HawkClient implementados de maneira espelhada entre duas blockchains fornece as bases para uma ponte de tokens descentralizada, permitindo a transferência de tokens de uma blockchain para a outra.

Uma ponte de tokens baseada em dois sistemas HawkClient espelhados

Podemos transferir tokens arbitrários porque as transferências de tokens são limitadas por valor, uma vez que os tokens têm valorizações de mercado conhecidas com as transferências, proporcionando-se montantes explícitos de token. Isso elimina a necessidade de segurança no nível criptográfico, permitindo que a ponte funcione sob um modelo criptoeconômico de segurança, reduzindo as dimensões das provas. Nesse modelo criptoeconômico, as transferências são confinadas em lotes e protegidas por uma garantia de segurança.

Um sistema HawkClient simplificado se baseia em quatro funções: os provadores, um verificador, um atualizador da Faixa de montanha de Merkle aproximada (AMMR), ou Atualizador AMMR (mais sobre essa função abaixo), bem como os usuários. Um provador se compromete com a melhor cadeia da blockchain remota e submete o comprometimento ao verificador. Depois, o verificador emite um desafio, ao passo que o provador criar uma prova de HawkClient contendo um subconjunto selecionado de cabeçalhos da melhor cadeia, também contendo provas de ligação. O subconjunto de cabeçalhos de blocos a ser recuperado é selecionado pela amostragem ao longo do espaço de dificuldade cumulativa, com base em um gerador de números pseudoaleatórios cuja semente é derivada do desafio. No caso de uma ponte de tokens, todo o processo se repetiria aproximadamente uma vez ao dia.

O verificador é um contrato inteligente implementado na blockchain anfitriã que verifica as provas do HawkClient e as usa para estender e manter uma representação da blockchain remota. O verificador é semelhante a um nó SPV da blockchain, porém funcionando em consenso. É basicamente isso que fazem a RSK e o btcrelay. O verificador irá permitir que outros provadores desafiem a prova ou apresentem provas alternativas durante um período de desafio, sendo que depois aceitará a prova com a prova de trabalho cumulativa mais alta. Todavia, partindo do modelo do btcrelay, o verificador realiza um protocolo de desafio e resposta com o provador sozinho, portanto, detendo ataques comuns de censura à transação. Os usuários interagem com as blockchains anfitriã e remota, ao passo que essa interação gera eventos na blockchain remota que são registrados nos recibos. Esses eventos são posteriormente informados à blockchain anfitriã pelo provador. Contratos inteligentes na blockchain anfitriã podem ouvir os eventos informados e interagir com eles. 

A ponte entre RSK e Ethereum

A ponte RSK–ETH conecta a RSK com o Ethereum e permite a transferência de qualquer token ERC-20 entre as duas blockchains. Ela está sendo ativamente desenvolvida pela IOV Labs. A ponte se baseia em HawkClients. Além disso, a ponte foi desenhada com um conjunto exclusivo de características. Por exemplo, permite que o provador escolha a quantia monetária da garantia de segurança que está disposto a comprometer em troca de uma autorização para fornecer uma prova de determinado tamanho, enquanto garante que a fraude será sempre uma estratégia desvantajosa. Por exemplo, o provador pode se oferecer a responder a mais perguntas do verificador, reduzindo a garantia de segurança, mas aumentando o tamanho da prova. Se as taxas de transação forem altas, o provador pode aumentar a garantia de segurança, reduzindo o tamanho da prova e as taxas de transação. Como a garantia é retalhada quando detectada fraude, essa nunca será uma estratégia racional, o que garante a segurança criptoeconômica. Além disso, o HawkClient força os comprometimentos a permanecerem na cadeia, bem como desafios a serem derivados das hashes de blocos seguintes, de modo que agressores não podem tentar milhões de diferentes comprometimentos off-line. Partindo do pressuposto de que o agressor controla menos de 50% da taxa de hash de quaisquer das blockchains envolvidas, ele somente poderia efetuar um único comprometimento. Em outras palavras, como o sistema é interativo, o agressor não consegue forçar o comprometimento off-line com facilidade a fim de obter um desafio favorável. Por exemplo, se definimos um limite na probabilidade de fraude como uma em 1 milhão, estabelecemos um enorme desencorajamento para qualquer tentativa de fraude. Esta probabilidade de fraude, que normalmente se transforma em baixa segurança criptográfica, resulta em uma segurança criptoeconômica extremamente alta. Por fim, a ponte usa um mercado de tokens especial e simplificado que serve de oráculo para a descoberta de um limite superior nos atuais preços de tokens em relação à moeda nativa. Esse mercado tem longos atrasos (na ordem de semanas) tanto para compra quanto venda, de modo que não esperamos que ele seja usado para qualquer comércio de fato, a menos que alguém tente fraudar os preços de tokens. Com esse sistema de oráculo, podemos realizar as garantias de segurança na moeda nativa em vez de tokens, além de podermos habilitar múltiplos provadores sem a exigência de que cada um deles deposite cada token possível.

Um sistema HawkClient para comunicar informações de Ethereum para RSK

Outra característica interessante da ponte RSK–Eth é que qualquer pessoa pode se tornar um provador, desde que se disponha a se comprometer com a garantia de segurança. Ainda, desenvolvemos um método muito eficiente para verificarmos provas de trabalho de ETHash sem necessidade de um opcode especial. Falaremos mais desse assunto na próxima postagem do blog.

Principais características de uma prova do HawkClient

As seções a seguir descrevem as principais características das provas do HawkClient e, em especial, como elas interagem para possibilitar a criação de uma ponte descentralizada.

Provas interativas

As provas do HawkClient são interativas. O protocolo envolve pelo menos um provador. Cada provador também tem a função de desafiar as potenciais provas falsas de outros provadores. Um provador se compromete com uma prova, e um contrato inteligente especial, que chamaremos de verificador HawkClient, escolhe uma semente de desafio da qual se deriva um conjunto de perguntas. O provador deverá então responder a essas perguntas, cujas respostas serão, em seguida, enviadas de volta ao contrato especial do verificador, que as validará.  Depois dessa fase inicial, os usuários restantes podem desafiar o provador a fornecer maior certeza ou podem se tornar, eles mesmos, provadores e enviar uma prova de blockchain com maior dificuldade cumulativa para invalidar a anterior.

Provas criptoeconômicas

As provas do HawkClient são criptoeconômicas, o que significa que há a probabilidade nada negligenciável de que o agressor seja exitoso na fraude. Para deter um ataque, o protocolo força os provadores a depositarem previamente moedas na forma de “garantias de segurança”, de modo que a recompensa esperada para o agressor em uma fraude seja inferior à recompensa esperada por seu comportamento honesto. A ponte fornece um subsistema que serve de oráculo autônomo para estabelecer os preços de tokens.

O montante monetário que a ponte consegue transferir por dia é limitado porque as blockchains baseadas em prova de trabalho correm o risco de ataques de gasto duplo. Para enganar a ponte, um agressor pode incorrer em um custo equivalente ao aluguel de 51% da taxa de hashing da blockchain por 24 horas. Portanto, pressupondo que há hardware de mineração suficiente atualmente disponível para aluguel, a quantia de dinheiro que a ponte pode transferir por período é restringida. A tabela a seguir mostra os custos aproximados de energia elétrica de ataques de 51% sustentados por 24 horas em diferentes blockchains em janeiro de 2020.

Blockchain	Custo (US$)
Bitcoin	12M
Ethereum	1.1M
RSK	6M

Como os preços da criptomoeda variam com frequência, a ponte deve ser parametrizada com uma margem de segurança suficientemente grande. Por exemplo, o valor que a ponte RSK–ETH seria capaz de transferir por dia do Ethereum para a RSK se limitaria a US$ 600.000, e a US$ 3 milhões na direção oposta.

Muito embora se trate apenas de uma simplificação do modelo de risco, todos os ataques identificados têm um custo que cresce linearmente com a dificuldade cumulativa da prova do HawkClient (o que se relaciona à dificuldade da blockchain remota) e a dificuldade da blockchain do verificador.

Provas graduais

Há dois extremos em protocolos de contratos inteligentes que precisam da verificação de insumos externos. Por um lado, há protocolos “preguiçosos” ou “otimistas”, cuja segurança depende totalmente da disponibilidade e resistência à censura da camada na cadeia. Em protocolos otimistas, um provador faz uma afirmação e a camada do contrato inteligente aguarda um desafio a ela por meio de uma prova de fraude. Eles funcionam sob o padrão de desenho “afirmação e desafio”. Se a afirmação não for desafiada dentro de um período predeterminado, presume-se que a afirmação é verdadeira. É considerado preguiçoso, pois o contrato inteligente não realiza nenhuma verificação por conta própria. Este modelo foi adotado pela TrueBit e depois pela Arbitrum. No extremo oposto, alguns protocolos “fortes” verificam cada asserção, não havendo a necessidade de desafios. Em alguns casos, usam Provas fortes de integridade de computação, tais como zk-SNARKs. A desvantagem de protocolos preguiçosos é que incentivam a censura à transação e o conluio de mineradores. Os protocolos preguiçosos poderiam se provar criptoeconomicamente seguros se pudéssemos estimar o custo de um ataque à censura da transação. Porém, é uma tarefa intimidadora, já que a censura custa pouco para fazer, mas é difícil de comprovar e, em geral, impossível de atribuir a um minerador específico. Mineradores colocam sua reputação em jogo, mas é difícil de avaliar para um observador externo.

O único ponto negativo de protocolos fortes é que são caros em termos de recursos de execução (gás) e este custo deve, de alguma forma, ser compartilhado pelos usuários do protocolo. Um meio termo entre eles são os protocolos graduais.  Os protocolos graduais começam com uma asserção, depois da qual o contrato de verificação realiza alguma forma de checagem probabilística para obter um grau inicial de certeza. Depois, outros usuários podem desafiar a prova, solicitar ao verificador que solicite maior certeza, fornecer outra prova concorrente ou aguardar a aceitação de uma prova. Quando a primeira prova é desafiada pela segunda prova concorrente, o primeiro provador tem a oportunidade de comprovar uma prova de trabalho mais cumulativa para vencer a corrida e se tornar a melhor cadeia. Mais provas podem se seguir, até que um dos provadores desista, não dispondo de mais provas de trabalho cumulativas para demonstrar. A última prova incontestável será escolhida como a melhor cadeia.

Otimista, forte e gradual para FlyClient

Para qualquer protocolo, há também outros custos opacos, tais como a capacidade de composição do ataque: e se o agressor decidir usar uma prova única para fraudar diversos sistemas não relacionados? Nesse caso, proporcionar segurança significaria conhecer cada possível sistema do qual alguém pudesse levar vantagem. 

Compromissos de MMR esporádicos persistentes

Se a blockchain remota não der suporte ao FlyClient de forma nativa, o HawkClient pode procurar compromissos MMR no armazenamento de um contrato inteligente denominado Atualizador AMMR. Esse contrato usa o opcode BLOCKHASH para coletar hashes de blocos passados e construir uma árvore atualizada. AMMR significa Faixa de montanha de Merkle aproximada. Essa árvore contém os limites para a real dificuldade cumulativa e valores de tempo. Os compromissos de AMMR não precisam ser atualizados em cada bloco. Pressupomos que são atualizados a cada N blocos em média com chamados externos ao contrato do Atualizador AMMR. Uma vez a cada N blocos em média, o tempo do bloco será exato (o tempo do bloco pode ser acessado usando-se o opcode BLOCKTIME), mas os tempos de bloco são desconhecidos para o contrato. Um contrato Ethereum não conhece a dificuldade cumulativa exata, não existe esse opcode. Portanto, quando o contrato do Atualizador AMMR é chamado, ele deve computar um limite na dificuldade cumulativa. O protocolo assegura que a dificuldade cumulativa irá estar sempre dentro de uma janela de erro percentual. A existência de um limite de erro é justificada, pois a dificuldade do bloco não pode variar muito entre as atualizações da AMMR. Consideremos o Ethereum, no qual a dificuldade do bloco pode mudar em fator de 1/2.048 entre os blocos. Aceitar as atualizações da AMMR a uma distância máxima de 256 blocos implica que a dificuldade do bloco pode subir ou descer até 6,65% (no ponto máximo/mínimo, em torno do bloco 128). No entanto, deve-se alcançar a dificuldade do bloco real no último bloco, pois o Atualizador AAMR o verifica usando o opcode DIFFICULTY. Portanto, o Atualizador AMMR pode computar limites para a dificuldade cumulativa no bloco atual. No pior dos casos, se não houver atualizações nos últimos 256 blocos e a dificuldade do bloco não tiver mudado desde a última atualização, esse limite representará um aumento ou diminuição de até 3,2% da dificuldade cumulativa da blockchain real. Portanto, mesmo se a dificuldade real for ocultada do contrato inteligente, ela pode seguir a dificuldade real muito de perto. Também, para mudar a dificuldade em 3,2% sem ser detectado, o agressor precisa minerar 256 blocos ou conseguir evitar que lhe sejam enviadas perguntas de 256 cabeçalhos de blocos.

Como a árvore AMMR não armazena os valores exatos de dificuldade cumulativa, ao apresentar provas contendo diversas Atualizações AMMR, os limites de dificuldade cumulativa em blocos consecutivos irão se sobrepor. Isso significa que, se um agressor for desafiado com uma pergunta a uma indexação de bloco por uma dificuldade cumulativa x, ele pode se valer dessa ambiguidade para escolher um dentre os diversos blocos adjacentes cujos limites de dificuldade incluem x. Assim, o agressor pode minerar somente um bloco para cada intervalo não sobreposto, reduzindo a quantidade de trabalho necessário. Para evitar esse ataque, o provador também deve se comprometer com uma segunda árvore de Merkle, a Árvore da montanha de Merkle exata (EMMR), contendo as dificuldades e tempos cumulativos exatos para cada bloco. Essa árvore é aumentada com dificuldades cumulativas e tempos cumulativos a cada nó intermediário. A função e verificações originais que foram realizadas pelos nós de AMMR são agora divididos entre essas duas árvores. Para cada pergunta, o provador deve demonstrar o ramo AMMR e o ramo EMMR. O ramo da EMMR é usado para localizar o número do bloco com um comprometimento cumulativo específico e, então, a árvore AMMR é atravessada buscando esse número de bloco. Enquanto isso é feito, todos os limites de dificuldade cumulativa e de dificuldade de tempo cumulativo são submetidos a verificação cruzada. O diagrama a seguir exibe uma blockchain hipotética, começando com a dificuldade cumulativa 0, na qual a dificuldade de cada bloco permanece estável em 10. Por consenso, a dificuldade pode aumentar ou diminuir 10% a cada bloco. Depois de 8 blocos, a dificuldade cumulativa real (80) divergiu a partir das dificuldades cumulativas mínima e máxima que poderiam ter sido alcançadas sem que fosse conhecida a dificuldade de fato de cada bloco intermediado. Somente a dificuldade do último bloco é conhecida. Cada uma das caixas verdes mostra a dificuldade cumulativa mínima e máxima. Durante a verificação da prova, a árvore EMMR é usada para localizar blocos e, em seguida, o ramo da árvore AMMR é buscado pelo número de bloco. Em cada etapa, verifica-se se a faixa exata está confinada na faixa restrita.

As árvores da faixa de montanha de Merkle exata e aproximada

Todos os sistemas que interagem com o HawkClient devem saber o endereço do contrato do Atualizador AMMR. Qualquer pessoa pode verificar o código implantado por meio da inspeção da transação que cria o contrato do Atualizador AMMR. No entanto, há um ataque sutil. Os criadores do Atualizador AMMR podem criar um contrato semelhante com o mesmo endereço em outra blockchain que compartilha a estrutura do cabeçalho de bloco e a prova de trabalho, bem como que foi anteriormente bifurcada. Nesta blockchain, o contrato pode ter sido implantado com um bytecode de VM diferente. Para evitar esse ataque, o contrato do Atualizador MMR deve ser implantado com CREATE2 e usar o opcode CHAINID (EIP-1344) para verificar se ele está funcionando na plataforma-alvo durante a construção, abortando a construção se não estiver. Esse opcode está disponível no Ethereum desde o hard fork de Istambul.  

Resumo

Na IOV Labs, estamos trabalhando em uma ponte descentralizada que possa conectar as principais blockchains de prova de trabalho. O coração dessa ponte é o protocolo HawkClient, que é uma extensão para o FlyClient. Há diversas diferenças entre o FlyClient e o HawkClient. No HawkClient,

• As provas são interativas
• A segurança das provas é criptoeconômica, e não criptográfica
• O sistema requer garantias de segurança. Se usado para uma ponte bidirecional, podem ser requeridas garantias de segurança tanto na moeda nativa quanto em tokens
• As provas são graduais
• Os comprometimentos AMMR são esporádicos, mas persistentes, sem a necessidade de alteração do consenso da blockchain
• O provador também se compromete com uma segunda árvore EMMR contendo dificuldades cumulativas exatas. A árvore não precisa ser produzida em consenso.
• As provas envolvem um ou mais provadores e um verificador de contratos inteligentes. Tanto os provadores quanto o contrato inteligente podem se tornar desafiantes.
• A melhor cadeia é monotonicamente crescente e imutável
• O crescimento da melhor cadeia é atrasado (latência da ponta comprovada até a ponta da cadeia)

Dois sistemas HawkClient implementados de maneira espelhada entre duas blockchains formam a base da ponte RSK–ETH. A ponte está atualmente em desenvolvimento, e em breve anunciaremos a data de sua implementação na testnet da RSK. Na mesma ocasião, vamos lançar o código fonte para a comunidade, fornecendo todas as informações sobre como usá-lo a partir de carteiras e contratos inteligentes. Estamos muito empolgados em trabalhar na primeira ponte criptoeconômica genuinamente descentralizada. A ponte RSK–ETH será a primeira etapa na construção de um backbone de comunicação para todas as blockchains, disponibilizando todos os tokens de blockchain compatíveis com EVM para aplicativos DeFi no Bitcoin.