By Sergio Demian Lerner, IOV Labs Chief Innovation Scientist

[TL;DR] Inventamos um novo tipo de sidechain de mineração mesclada que chamamos de SyncChain, que permite peg-ins e peg-out rápidos (entre o Bitcoin e a RSK, isso é tão baixo quanto 30 minutos para peg-ins e tão baixo quanto 2 horas para peg-outs) e pode ser parametrizado para proteger incondicionalmente o peg de gastos duplos. Isso representa uma grande melhoria em relação às sidechains existentes, que exigem centenas de confirmações de blocos e cuja segurança é baseada apenas em suposições criptoeconômicas. O protocolo da SyncChain, construído sobre algumas ideias que publicamos em 2016, é ortogonal ao método usado para desbloquear peg-outs, um design interessante é criar uma SyncChain federada. Finalmente, discutimos os prós e contras de a RSK migrar de um Bitcoin SPV-sidechain para um Bitcoin SyncChain e estabelecemos um plano provisório para uma atualização da rede SyncChain. 

Introdução

Quando a RSK foi inicialmente projetada, um dos objetivos do projeto era manter a RSK independente do Bitcoin, tanto quanto possível, para evitar que falhas no Bitcoin afetassem a RSK. Durante o período 2015-2016, o Bitcoin estava sob pressão contínua e ameaças de hard-forks contenciosos, e as taxas de transação aumentaram consideravelmente, impedindo o uso do Bitcoin para inclusão financeira, o que requer pagamentos baratos. Por essas razões, a RSK adotou um consenso de mineração de mesclagem por ser um protocolo overlay semelhante a contraparte. A mineração de mesclagem oferece independência completa (incluindo as reversões do bloco de Bitcoin), enquanto as overlays não. Usamos provas de SPV para comprovar o consenso estrangeiro, exatamente pelo mesmo motivo. 

O risco de o Bitcoin ser despedaçado se diluiu com o tempo. Portanto, podemos reconsiderar os requisitos para o peg de duas vias e reexaminar o espaço de design em busca de melhores alternativas.

A segurança da ponte SPV

 

Em várias postagens anteriores, analisamos como funciona o peg da RSK. Uma das propriedades do peg da RSK é que a reversão da blockchain do Bitcoin não implica a reversão da blockchain da RSK. Portanto, para evitar um gasto duplo, a RSK exige a mais alta garantia de que o blockchain do Bitcoin não reverterá além da transação de peg-out, como aguardar 100 confirmações de bloco do Bitcoin. Vamos supor que o envolvimento na mineração de mesclagem seja de cerca de 50%, e exista um grande pool de mineração maliciosa que chamaremos de Mallory, que possui 51% do hashrate da RSK (25% do hashrate do Bitcoin). O Mallory poderia tentar usar todo o seu hashrate para criar uma blockchain somente de cabeçalho falsa e alimentá-la na ponte, fazendo com que a ponte aceitasse qualquer transação falsa que o Mallory afirmasse. Essa cadeia de cabeçalho falsa não seria uma blockchain do Bitcoin válida e, portanto, o Mallory não interromperia essa blockchain, mas ela não conseguiria coletar recompensas em bloco durante a preparação do ataque. No momento, a RSK está protegida contra esse ataque porque os funcionários da federação não emitirão uma mensagem de registro de peg-in se a melhor cadeia local não corresponder à melhor cadeia do Bitcoin carregada no contrato de ponte. No entanto, podemos pensar que, se o peg-in baseado em SPV fosse descentralizado ao máximo removendo a intervenção da federação, o ataque poderia ser bem-sucedido. Chamamos isso de ataque de “peg-in falso”. O custo para realizar um peg-in falso para o Mallory em uma variante desprotegida da RSK é de cerca de 10 milhões de dólares em eletricidade. Embora o ataque de peg-in falso pareça facilmente atribuível ao “minerador desaparecido”, observando as bases de moedas do bitcoin, o Mallory poderia alegar que seus sistemas foram hackeados e transferir a culpa para uma parte desconhecida. 

Também há o ataque de dupla despesa de peg-in. Esse ataque requer informar uma melhor cadeia alternativa ao contrato-ponte e, ao mesmo tempo, isolar os funcionários da federação para fazê-los acreditar que essa melhor cadeia alternativa é a única existente. O custo do ataque ainda é de US$ 10 milhões em eletricidade, além de hackear os funcionários, mas o ganho agora não é criação arbitrária de bitcoin, mas apenas para dobrar o valor inicialmente investido.

O ataque oposto é o gasto duplo de peg-out. Nesse ataque, o Mallory executa um peg-out e depois reverte a RSK blockchain para o ponto em que a transação que comanda o peg-out está localizada. Novamente, o ataque tem um alto custo em eletricidade, mas, se a quantidade de bitcoins a serem roubados for alta o suficiente, existe o risco. Observe que a RSK possui uma ferramenta de monitoramento de rede chamada Armadillo que permite alertas descentralizados para impedir ataques de mineração de mesclagem “gratuitos”, mas esse ataque ainda é possível.

Outra desvantagem da ponte SPV é que ela requer 100 confirmações de blocos de Bitcoin (ou blocos equivalentes de RSK para a mesma dificuldade cumulativa) para peg-ins e peg-outs. Isso prejudica a usabilidade. Podemos fazer melhor do que a ponte SPV em termos de segurança e usabilidade?

A segurança dos pegs de duas vias

Para comparar designs de pegs de duas vias, definimos 8 proteções que evitam ataques de gasto duplo ou roubo simples de bitcoins pelos mineradores. Não consideramos ataques de outros grupos. Essas proteções se aplicam a qualquer sistema de peg S que aceite transferências entre cadeias através de duas blockchains de prova de trabalho. As proteções serão definidas com base em uma suposição de segurança ou no custo do ataque (uma suposição sobre o orçamento do invasor). As proteções são ordenadas da mais forte (1) para a mais fraca (8), mas um sistema pode oferecer mais de uma proteção. Um sistema S pode não ser totalmente caracterizado por uma combinação das proteções descritas, porque um sistema pode usar proteções diferentes para peg-ins e peg-outs. Como a peg-out é sempre o subprotocolo mais fraco, focaremos na segurança de peg-out para todos os protocolos apresentados nesta seção, pois os invasores escolheriam o ponto mais fraco para atacar. Além disso, um sistema pode exigir suposições diferentes para a solidez e a vivacidade, mas nessa categorização nos concentramos na solidez. Também, por uma questão de simplicidade, estamos ignorando outros ataques complementares à rede, como a viabilidade de isolar um nó. Observe que geralmente um ataque de gasto duplo não causa perda de recompensas de bloco para o invasor: se um atacante reverte um blockchain para criar uma nova melhor cadeia em particular, essa nova cadeia pagará recompensas a si mesmo, portanto, apenas as recompensas de outros mineradores são perdidas. A única exceção a essa regra é a proteção fornecida pelo Armadillo, ou alguns algoritmos de consenso (geralmente quebrados) que pontuam blocos por tempo de recepção [1][2][3].

Como o Bitcoin não pode avaliar a prova cumulativa de trabalho de outras sidechains, assumimos a existência de alguma forma de grupo estático ou dinâmico de várias assinaturas para assinar peg-outs e receber peg-ins. No entanto, ignoramos qualquer ataque que envolva detentores mal-intencionados da assinatura múltipla que receba as moedas pareadas. Assumimos que os detentores de chaves são 100% honestos ou que executam HSMs (Hardware Security Modules) que os impedem de acessar as chaves privadas, como faz a RSK.

Na tabela a seguir, comparamos a RSK com outros tipos de pegs de duas vias, mas os modificamos para conectar o Bitcoin a uma sidechain de mineração mesclada. Isso ajuda a obter uma comparação justa de protocolos.

A primeira proteção “Segurança incondicional”, o que significa que, de acordo com as regras do protocolo para S, não podem ocorrer gastos duplos. A próxima é a “Inviabilidade computacional” (2), que representa uma impossibilidade de gasto duplo em S, supondo que o invasor não possa executar uma tarefa computacional difícil. A próxima proteção é o “Bitcoin M.A.D”  (3). M.A.D. significa destruição mútua garantida. Um protocolo é protegido pelo Bitcoin M.A.D se, para realizar um gasto duplo, o invasor for forçado a reverter o mainchain, o que impactaria o preço do token nativo do mainchain e, portanto, os incentivos de longo prazo do minerador para manter o mainchain ileso também se aplicariam ao peg. O mesmo conceito pode ser aplicado à sidechain como em (5). A proteção “Consciência de ataque longo” (4) é quando a rede pode detectar antecipadamente ações maliciosas de um grupo conluio de mineradores. A RSK, mais o sistema de monitoramento Armadillo, possui uma variante criptoeconômica de Consciência de ataque longo: ou o invasor revela que está preparando um ataque ou precisa renunciar às recompensas dos blocos que produz em particular . A próxima proteção é “Perda de recompensas de bloco de Bitcoin” (7), que representa todos os sistemas criptoeconômicos baseados em provas de SPV, onde o invasor precisa extrair blocos com uma transação falsa para enganar o sistema a fim de desbloquear moedas em uma cadeia que não estavam travadas na cadeia oposta. O atual protocolo de peg da RSK (com o sistema de monitoramento Armadillo) possui essa proteção; o XCLAIM e o TBTC também possuem. As outras categorias são auto explicativas.

O design da SyncChain 

Uma SyncChain fornece uma garantia de segurança muito mais forte do que a fornecida pela criptoeconomia. Ela fornece segurança incondicional para peg-ins e peg-outs. Com uma SyncChain, podemos eliminar o risco de gasto duplo e, portanto, não sobrecarregar a rede de mineração de mesclagem. Neste white paper, descrevemos o design da SyncChain em todas as suas variantes. Neste blogspot mais curto, apresentaremos apenas as ideias por trás da SynChain e a mais simples de suas variantes. Todas as variantes são baseadas em três componentes: parentalidade dupla adiada, vinculação de transação de peg e ancoragem de base de moedas. A ideia base por trás da SyncChain (parentalidade dupla) está esboçada em um dos nossos blogposts em 2016. A ideia é que os blocos da sidechain devem especificar um pai da sidechain e um pai da mainchain. O estado herdado antes do processamento do bloco da sidechain corresponde a um estado após o processamento de ambos os pais, e a reversão de qualquer um dos pais causa a reversão do bloco filho da sidechain. Mas essa técnica não pode ser usada para uma sidechain com uma taxa de bloqueio mais alta que a mainchain, pois uma reversão do bloco da mainchain pode causar uma inversão de muitos blocos da sidechain. É necessária uma nova forma de envolvimento que suporte taxas de bloqueio mais altas, mas não sofra longas reversões.

Parentalidade dupla adiada

Parentalidade dupla é uma técnica de entrelaçar a mainchain e a sidechain. A técnica baseia-se em que cada bloco da sidechain tenha dois pais: um na sidechain e o outro na mainchain. Mas não usamos essa técnica como é, usamos uma variação de parentalidade dupla que chamamos de parentalidade dupla adiada (DDP). Primeiro, para simplificar nossa terminologia, chamaremos o pai principal de “ponto de verificação”, mas o leitor não deve confundir um ponto de verificação de sincronização com outros sistemas de ponto de verificação baseados em autoridades [4][5]. Com o DDP, o ponto de verificação está definido para ficar atrasado em um número de blocos (blocos K em média) com base nos carimbos de data e hora e na contagem de confirmação do bloco da mainchain. Por exemplo, um valor realista para K é 3, forçando os pontos de verificação a ficarem em média 30 minutos. O diagrama a seguir mostra um exemplo para K=3.

Parentalidade dupla adiada

Como descrito anteriormente, o problema com o entrelaçamento imediato é que a reversão de um bloco de Bitcoin causa automaticamente a reversão de cerca de 20 blocos de RSK, o que não é tolerável de uma perspectiva UX, mas o mais importante, é um risco de segurança de liquidação de transações. Com o ponto de verificação adiado, a RSK blockchain é revertida apenas se mais de K blocos mainchain forem revertidos. Para simplificar as explicações, ao longo deste blogpost, assumiremos que o intervalo médio de bloqueio do RSK é de 30 segundos e o intervalo médio de bloqueio do Bitcoin é de 10 minutos. Então, se a blockchain do Bitcoin for revertida em blocos R onde R>K, a RSK blockchain será revertida (R-K)*20 blocos. No diagrama a seguir, podemos ver que não há remoções surpresa no RSK se apenas um único bloco de Bitcoin for revertido.

A reversão de um único bloco de mainchain não causa reversão na SyncChain

O valor mínimo para K é 1, o que significa que um bloco só pode ser verificado se tiver um bloco adicional para confirmação.

Nós duplos

Uma SyncChain requer que cada cliente da sidechain execute uma instância do nó da mainchain e do nó específico da sidechain. A principal razão pela qual inventamos a SyncChain é impedir que uma ramificação de blockchain do Bitcoin inválida seja apresentada a um contrato de ponte baseado em SPV como uma cadeia SPV (somente cabeçalho) válida, porque uma prova de SPV pode ser ocultada da rede honesta e isso reduz a tensão do M.A.D. Para maximizar a tensão, queremos que a transparência detecte, julgue e eventualmente castigue os mineradores assim que eles começarem o bloco de mineração para um ataque e antes que o ataque termine. Portanto, devemos garantir que, independentemente dos blocos que a ponte aceite para validar um peg-in ou peg-out, esses blocos são totalmente expostos (carga útil do cabeçalho e da transação) e esses blocos podem ser incluídos na blockchain do Bitcoin, conforme definido pelo software de referência Bitcoin Core. Portanto, um nó de SyncChain deve executar o nó de referência da mainchain, junto com o nó de sidechain apenas. Em outras palavras, um nó de synchain executa uma instância de bitcoind e uma instância de rskj.

Um usuário ainda pode executar somente o nó de apenas sidechain (rskj), mas não poderá validar peg-ins e peg-outs. Nesse sentido, ele se torna automaticamente um nó “leve” do SPV, com o mesmo modelo de segurança que os clientes SPV obtêm, assim que houver uma transação de entrada ou saída. 

Para criar um pai duplo adiado, precisamos de um algoritmo de seleção de ponto de verificação (CSA). Um CSA é um algoritmo de consenso que seleciona o ponto de verificação da mainchain e valida se um ponto de verificação está selecionado corretamente. Essencialmente ele deve basear suas decisões nos carimbos de data e hora do bloco. Mas os carimbos de data e hora do bloco no Bitcoin não refletem os horários do relógio de parede e menos ainda o relógio global. O white paper da SyncChain apresenta dois algoritmos RTA simples (MedianTime11 e AdjustedTime), portanto não vamos discuti-los novamente aqui. 

Pontos de verificação e processamento de blocos

No cabeçalho do bloco da sidechain, o ponto de verificação é definido por um número do bloco de mainchain (checkPointBN) e um hash do bloco de mainchain (checkPointHash). É possível usar um cabeçalho de tamanho reduzido do resumo de hash para economizar espaço. 

Todo nó da sidechain deve executar um nó de mainchain (bitcoind no caso do RSK) para monitorar a correção dos pontos de verificação nos cabeçalhos do bloco do RSK. Se o hash do ponto de verificação do RSK não corresponder ao hash do bloco do Bitcoin referenciado pelo número do bloco, o bloco do RSK será “temporariamente inválido”. O bloco do RSK pode ser reconsiderado mais tarde se a melhor cadeia de Bitcoin se reorganizar.

Nem todo bloco de Bitcoin será um ponto de verificação: os valores de checkPointBN não cobrem todos os blocos, e haverá lacunas. Quando um bloco checkPointBN se refere a uma transação de peg-in em um bloco de Bitcoin, ou salta sobre uma transação de peg-in ignorando o bloco, o consenso do RSK determina que o bloco do RSK relacionado DEVE incluir uma transação que envia uma mensagem de peg-in para o contrato de ponte para liberar imediatamente por peg-in as moedas associadas. O consenso também exige que as transações de peg-in tenham prioridade sobre as demais, o que significa que elas as precedem no bloco. 

Vinculação de transação de peg 

Todas as transações de peg-in e de peg-out do Bitcoin são vinculadas. Isso é feito por vários motivos. Um é evitar ataques nos quais o invasor reorganiza as blockchains de Bitcoin e RSK blockchains para gastar duplamente os fundos do peg multi-sig, em que o próprio invasor fez peg-in ou peg-out. Vincular reduz bastante a superfície de ataque. Mas uma segunda razão diz respeito à forma como as peg-outs são protegidas e nos permite provar a inviabilidade de gastos duplos de peg-out. O diagrama a seguir mostra um peg-in e um peg-out de uma sidechain federada como o RSK. Os fundos de peg são protegidos por um multi-sig federado e as partes que possuem as chaves privadas desse multisig são chamadas de funcionários. Na cadeia mostrada, há duas transações internas adicionais chamadas de link-in e link-out, que explicaremos mais adiante. A linha vermelha corresponde a uma cadeia de referências usando entradas/saídas “fictícias”. Todas as transações assinadas pelos funcionários estão vinculadas a essa cadeia. Como cada transação consome uma entrada fictícia e cria uma saída fictícia, há apenas uma saída de transação não gasta o tempo todo. Chamamos esse UTXO especial de loken (abreviação de token de link). Usamos “cadeia de loken” para nos referir à cadeia de transações que consomem e criam o loken. O valor do loken será um pequeno valor acima do limite de poeira do Bitcoin.

A cadeia de loken

É necessário ter cuidado ao atualizar os funcionários da federação adicionando ou removendo membros. Isso desencadeia, no RSK, um processo longo e forçadamente demorado, em que os fundos são automaticamente transferidos de um antigo multisig de federação para um novo. Ainda não propusemos um processo de migração adaptado a um SyncChain, mas acreditamos que isso pode ser feito com segurança.

Peg-ins

O contrato inteligente de ponte, que controla todos os processos de peg-in e peg-out, comanda automaticamente funcionários para o encaminhamento das moedas recebidas na transação de entrada para um UTXO diferente, cujo endereço pode ser igual ou diferente daquele no peg-in, mas é igualmente controlado pela mesma federação. Esse encaminhamento inicial de moedas recebidas é realizado em uma transação de Bitcoin que chamamos de link-in. A transação de link-in consome o loken e cria um novo loken. O diagrama de exemplo a seguir mostra como uma transação iniciada pelo usuário (“Peg-in Tx” no diagrama) no bloco de mainchain 1 desencadeia ações da ponte quando o bloco 1 é verificado pelo bloco da sidechain A. A primeira ação é um período de espera inicial de 3 blocos de sidechain e, posteriormente, no bloco B, a ponte ordena aos funcionários da federação que assinem e transmitam a transação de Link-in, que consome imediatamente os fundos de peg-in, e os movem para o endereço final de peg de várias assinaturas.

O processo de peg-in

As moedas da sidechain são liberadas imediatamente no bloco A, mas nenhum peg-out pode ocorrer até que a transação de link seja incluída na mainchain. 

Peg-outs

Mostramos em nosso artigo anterior que uma sidechain de prova de trabalho não pode fornecer atomicidade total de peg-in e peg-out sem a colaboração dos mineradores no processo de peg in/out. O invasor pode reverter alternadamente a mainchain, depois a sidechain e depois a mainchain novamente, e finalmente conseguir manter os tokens da mainchain e os tokens da sidechain. Agora, mostraremos como a proteção criptoeconômica pode ser alcançada sem a ajuda dos mineradores e como a proteção incondicional completa pode ser alcançada com a ajuda dos mineradores.

Observamos que um sistema de sidechain totalmente federado como o Liquid, possivelmente baseado no consenso do tipo PBFT, não pode fornecer atomicidade total de peg-outs, porque possui finalização de liquidação. Depois que uma transação na Liquid for liquidada, mesmo que o Bitcoin reverta, a sidechain não reverterá para corresponder à bestchain líquida do Bitcoin.

Protocolos de peg-out

Encontramos três protocolos diferentes para obter um M.A.D. e garantias incondicionais, baseadas em diferentes suposições a serem acrescentadas ao consenso de Nakamoto padrão. Nas seções a seguir, descrevemos brevemente cada um deles.

• Peg-out para uma SyncChain de Ganhos em Cadeia mais Populosa (MPCW)
• Peg-out para SyncChain Sincronizada com T (TS)
• Peg-out para uma SyncChain GHOST-CSC (não sincronizada com T)

Em nosso artigo anterior, discutimos todas as três variantes. Neste artigo, mostraremos apenas a SynChain TS. Para mover os tokens de volta de uma conta no RSK para o Bitcoin, é criada uma transação RSK chamada Solicitação de peg-out que transfere o RBTC para o contrato inteligente da ponte. Na figura a seguir, essa transação foi incluída no bloco rotulado A. Após um pequeno número de confirmações de bloco RSK (como 3), a ponte cria um modelo de transação de Link-out contendo espaços reservados para os funcionários da federação inserirem suas assinaturas. Este modelo pode usar o padrão Partially Signed Bitcoin Transaction (PSBT) . Em seguida, a ponte solicita que os funcionários da federação assinem e esse evento é chamado de Solicitação de link-out. Isso ocorre no bloco RSK B na figura. A transação Link-out deve conter uma saída de dados especial que inclua um OP_RETURN, o hash do bloco A e o número do bloco A. Chamamos esses dados de carga útil de slot do ponto de verificação da sidechain. Esse slot pode conter um ou mais pontos de verificação reais da sidechain. Observamos que os pontos de verificação da sidechain juntamente com os pontos de verificação da mainchain produzem referências recíprocas aos pontos de verificação.

Processo de peg-out

Depois que a maioria das assinaturas funcionais é coletada para a transação de link out, a transação é transmitida e espera-se que seja incluída na blockchain do Bitcoin em breve. Na figura, isso ocorre no bloco 4 do Bitcoin. A transação de link out deve fazer parte da cadeia loken (deve consumir o loken e criar um novo loken).  Depois que a transação de link-out é incluída no bloco Bitcoin 4, o bloco 4 deve ser referenciado pelo ponto de verificação de um bloco RSK (ou ignorado por um ponto de verificação, o que causa o mesmo efeito). O ponto de verificação do bloco 4 normalmente será adiado aproximadamente 30 minutos. Na figura, o bloco 4 é referenciado no bloco RSK C. Depois, a ponte aguardará alguns blocos (166 na figura). Após o término do período de espera, a ponte criará o modelo de transação de peg-out e solicitará que os funcionários da federação o assinem. A transação de peg-out é a transação final que realmente paga ao usuário do Bitcoin a quantia necessária. Como todas as demais transações peg e link assinadas pela federação, ela se vincula à cadeia loken. A transação de peg-out será incluída em um bloco de Bitcoin, e isso ocorre no bloco 11 da figura. Após aproximadamente 30 minutos, será referenciada por um ponto de verificação RSK e o loken estará disponível para outras transações de link-in ou link-out. Todo o processo de identificação leva em média 2 horas e 10 minutos, requer duas rodadas de assinaturas de federação e produz duas transações de Bitcoin. Se uma transação de peg-in for confirmada enquanto uma transação que consome um loken estiver aguardando para ser incluída na mainchain, o peg-in será colocado na fila. De fato, muitas transações de link-in e peg-out podem ser unidas em um lote, tendo uma única entrada/saída de criação e destruição de Loken.

Segurança de peg-out

As seções a seguir apresentam alguns ataques teóricos, e mostramos como a SyncChain resiste a eles. O ataque mais importante a qualquer sistema de aceitação de criptomoedas é o gasto duplo. Para tentar um gasto duplo, o invasor pode tentar reverter o RSK, reverter o Bitcoin ou reverter ambos. Atualmente, o RSK é minado por fusão entre 35% e 50% dos mineradores de Bitcoin. Neste artigo, presumimos que o hashrate do RSK seja menor que o Bitcoin e, portanto, se um invasor reverter o Bitcoin, por causa da mineração mesclada, ele também terá a chance de reverter as duas cadeias. 

Peg-outs de gasto duplo pela reversão do RSK, apenas 

A reversão do RSK parece ser o caminho mais fácil para gasto duplo, pois assumimos que o hashrate do RSK é menor que o do Bitcoin. Vimos como as transações peg-in são sincronizadas, porque os blocos RSK dependem dos blocos Bitcoin. No entanto, na outra direção, a sincronização não é garantida. Assim, para peg-outs, forçamos a ocorrência de uma transação de link-out no Bitcoin. O registro de data e hora da transação de link-out estabelece um horizonte que o RSK não pode superar sem executar a solicitação de peg-out correspondente.

O consenso de Nakamoto estabelece regras claras para todos os aspectos do manuseio de blockchain, exceto quando uma transação é considerada liquidada. Isso é deixado para cada usuário, e a única orientação fornecida é que, quanto mais confirmações de bloco, menor a probabilidade de reversão. Para garantir a inviabilidade de gastos duplos com peg-out, devemos adicionar ao consenso de Nakamoto na sidechain uma condição que deve ser atendida para aceitar transações. Primeiro, introduzimos uma definição: Um nó de rede é sincronizado em T se sua melhor cadeia local estiver acima de T segundos atrás da hora local atual. Para criar um SyncChain, precisamos que o sidechain atenda à seguinte nova condição: os nós só aceitam uma transação como liquidada se estiverem sincronizados em T. Também poderíamos aceitar a transação W se for confirmada por uma enorme quantidade de dificuldade cumulativa, mas usaremos a definição mais simples possível agora. 

Por causa da propriedade de sincronização em T, podemos ver que qualquer ataque que reverta a sidechain deve adicionar pelo menos um bloco da sidechain com o registro de data e hora após o registro de data e hora do bloco C, onde o bloco 4 está marcado.  Portanto, desde que o tempo entre o bloco 4 e o bloco C seja maior que T, a cadeia invasora (na sidechain) nunca poderá confirmar transações. Isso pressupõe que a hora local do nó não foi revertida. 

Peg-outs de gasto duplo pela reversão do bitcoin e RSK (mas reproduzindo mais tarde a transação de peg-out)

Uma maneira possível de realizar um ataque de gasto duplo é tentar reverter o blockchain do Bitcoin antes da transação de link-out e, ao mesmo tempo, reverter o blockchain do RSK antes da solicitação de peg-out, criando uma nova ramificação do Bitcoin que possui transações de link-out e peg-out, mas em um bloco muito posterior. Por exemplo, o atacante reverte 10 blocos de Bitcoin e minera outros 10 blocos sem transações de peg e, finalmente, adiciona um 11º bloco contendo o link-out e o peg-out. Assumindo mineradores racionais desonestos, uma reversão de 10 blocos custa aproximadamente US$ 1,5 milhão (1) e, portanto, seria o valor máximo que a transação de transferência pode transferir. Mas, se não queremos segurança incondicional, devemos fazer melhor com a ancoragem. Com a ancoragem, podemos impedir que a transação de link out seja movida para blocos futuros.

Ancoragem de peg-out

A maneira mais fácil de ancorar uma transação a um bloco específico seria adicionar ao Bitcoin um novo opcode OP_CHECK_INPUT_BLOCK_HASH, que recebe um hash de bloco como argumento na pilha e invalida o bloco se o hash do bloco fornecido não corresponder ao hash do bloco em que a entrada que está sendo gasta foi criada. Não acreditamos que esse novo código de operação seja aceito pela comunidade Bitcoin, pois pode produzir Bitcoins menos fungíveis que outros. Um opcode alternativo que pode fazer o mesmo truque é OP_CHECK_INPUT_BLOCK_TIME. Esse opcode invalidaria a transação se o bloco correspondente à entrada sendo gasta tivesse um carimbo de data/hora maior que o argumento do opcode. Por outro lado, esse opcode interfere muito menos com a fungibilidade. No entanto, sem nenhum novo opcode, ainda existe uma maneira de obter o mesmo resultado, consumindo nas transações de peg-out uma saída de uma transação de coinbase que existe em um bloco B entre os blocos de transações de link-out e peg-out. A transação de peg-out será inválida se B for revertida, e a única maneira de remover o link-out seria revertendo B. A desvantagem é que, como as saídas da transação de coinbase têm um período de maturidade de 100 blocos, essa ligação introduz um atraso de 100 blocos para a peg-out. Embora a transação de peg-out não possa ser incluída antes do período de 100 blocos, a transação de peg-out pode ser assinada e publicada muito antes e, portanto, o usuário tem uma garantia muito forte de que a transação de peg-out ocorrerá. Para vincular o peg-out a uma coinbase, a RSK pode solicitar que os mineradores de RSK incluam uma saída extra pagando uma quantidade de 1 satoshi (2) para um endereço de federação específico e esse satoshi é consumido na transação de peg-out.

(1): de acordo com o site crypto51.app. 

(2): Não há necessidade de ultrapassar o limite de “poeira” porque as transações de coinbase não são encaminhadas pela rede antes da inclusão em um bloco. 

Processo de peg-out com ancoragem de coinbase

Migração do RSK para uma SyncChain

Embora a SyncChain ofereça muitos benefícios sobre uma SPV Sidechain, é muito cedo para dizer quando e como o RSK poderia fazer a transição para se tornar uma SyncChain. Existem benefícios, mas também existem riscos na migração. Codificação, testes, simulações e auditorias de segurança devem validar cada decisão de projeto. No entanto, ter um design tão limpo que ofereça tantos benefícios quanto à usabilidade e à segurança é reconfortante. Assim que todas as etapas de P&D forem concluídas, abriremos a discussão para uma migração para um SyncChain e, esperançosamente, com o feedback da comunidade RSK, poderemos ver a migração em 2020 ou 2021. 

Resumo

Neste post, apresentamos o SyncChain, um novo tipo de sidechain que permite uma redução de 32x no tempo de peg-in de 16 horas para 30 minutos. O tempo para peg-out também pode ser reduzido de 16 horas para cerca de 1,6 horas, se mantivermos um limitador de taxa para que não sejam transferidos mais de 38 BTCs por hora. Também apresentamos uma variante que usa ancoragem de coinbase para fornecer segurança incondicional de peg-out, com um tempo de peg-out de 16 horas, que é menor do que o que o RSK atualmente exige atualmente apenas com segurança criptoeconômica. Também propusemos um novo opcode OP_CHECK_INPUT_BLOCK_HASH para Bitcoin que permite peg-outs com segurança incondicional em questão de horas e sem qualquer limitador de taxa. 

Mesmo que a peg atual do RSK SPV também possa obter confirmações de peg-out e peg-in mais baixas, se o engajamento de mineração de mesclagem aumentar, o SyncChain oferece um número menor de confirmações para o mesmo nível de engajamento. 

O synchain também oferece outros benefícios secundários, como: 

1. Reduz a quantidade de código que o RSK executa em consenso no rskj: agora parte dessa funcionalidade de código é fornecida diretamente pelo bitcoind. 
2. Dependendo do protocolo selecionado, ele fornece segurança incondicional ou força um ataque ao RSK a se tornar um ataque ao Bitcoin: a propriedade M.A.D. na teoria dos jogos.
3. Permite peg-ins de endereços cruzados, como investir em um financiamento coletivo diretamente do Bitcoin

O SyncChain também tem algumas desvantagens menores. Por exemplo, o SyncChain não pode fornecer uma finalização curta da liquidação. Considerando os prós e os contras, o SyncChain é certamente um protocolo superior para as sidechains do Bitcoin.

Referências

[1] Ren Zhang e Bart Preneel. Publique ou pereça: Uma defesa compatível com versões anteriores contra a mineração egoísta no bitcoin. Em Cryptographers’ Track na RSA Conference, páginas 277–292. Springer, 2017

[2] Uma proposta para modificar o consenso de Satoshi para aumentar a proteção contra 51% de ataques. Um sistema de penalidade para envio atrasado de blocos.

https://www.horizen.global/assets/files/A-Penalty-System-for-Delayed-Block-Submission-by-Horizen.pdf

[3] Atrasando a reorganização de cadeias.

https://bitslog.com/2013/06/26/the-bitcoin-eternal-choice-for-the-dark-side-attack-ecdsa/

[4] Finalidade da transação através dos pontos de verificação do registro (https://ieeexplore.ieee.org/document/8975825 ou https://github.com/MuhammadNurYanhaona/checkpoint-paper/blob/master/checkpoint-paper-reviewed.pdf)

[5] Protegendo registros de prova de trabalho por meio de ponto de verificação (https://eprint.iacr.org/2020/173.pdf)