As cadeias de transmissão permitem que os operadores de nós de sidechain paguem mineradores para minerar – e muito mais!

Este é um editorial de opinião de Shinobi, um educador autodidata no espaço Bitcoin e host de podcast Bitcoin orientado para tecnologia.

Desta vez vou detalhar e discutir como funcionam as cadeias de transmissão; eles foram propostos inicialmente em 2015. De todas as propostas discutidas até agora, as cadeias de transmissão são as mais antigas e as mais desenvolvidas em termos de detalhes de implementação e design específicos, documentados em BIPs 300 e 301. Paul Sztorc, o criador do conceito, tinha alguns objetivos principais de design em mente e, embora isso não seja abrangente, aqui estão alguns:

• Isole cada sidechain para que qualquer falha ou problema afete apenas aqueles que o utilizam.
• Permita que as cadeias laterais sejam giradas sem precisar de um novo garfo para cada uma.
• Habilite a transferência de bitcoin para dentro e para fora de uma sidechain com um pino bidirecional.
• Permitir a experimentação livre no design que ele espera que torne obsoleta a necessidade de altcoins.

Existem dois aspectos principais de todo o design, e é por isso que existem dois BIPs separados. O primeiro é o mecanismo de pino (BIP300), que permite o funcionamento do pino de duas vias. Sztorc projetou algo chamado custódia de taxa de hash, que, nos termos mais básicos, permite que os mineradores como um grupo amorfo guardem coletivamente as moedas em todas as sidechains. O segundo é um esquema de mineração mesclado “cego”, onde o objetivo é permitir que os mineradores de bitcoin sejam os produtores de blocos em um nível de consenso sem a necessidade de validar o sidechain para fazê-lo. Ambas as peças juntas apresentam um mecanismo de peg bidirecional e uma maneira de os mineradores de bitcoin participarem da mineração das sidechains enquanto tentam mitigar o risco de centralização que apresenta.

O BIP300 especifica a lógica para a proposta de uma nova sidechain, a ativação de uma nova sidechain, a proposta de um conjunto de saques agrupados, a aprovação de tal conjunto de saques, a lógica de validação para transações de saque reais e a validação para transações de depósito.

A ativação de um novo sidechain sob a proposta do drivechain é muito semelhante ao processo de um soft fork ativado por meio de sinalização do minerador. A principal diferença é, claro, que não é realmente um soft fork - um único fork para ativar as regras de consenso do drivechain permite que os mineradores, a qualquer momento, sinalizem para ativar um novo sidechain dentro regras de consenso da cadeia de transmissão. Para propor a ativação de uma nova sidechain, um minerador deve colocar um dado OP_RETURN em sua saída coinbase que inclua um identificador exclusivo para essa sidechain, uma chave pública para usar em operações de depósito, dados de versão, descrições legíveis por humanos e hashes do cliente de software e o histórico do GitHub (não há aplicação de consenso aqui, apenas dados para referência humana).

Quando um minerador propõe ativar uma nova sidechain e incluir todos os dados necessários em sua base de moedas, torna-se uma espécie de período de “sinalização do minerador” sobre a criação ou não dessa nova sidechain do ponto de vista do consenso da mainchain. Um minerador pode usar um formato especial para incluir uma proposta em suas saídas de base de moedas, e outros mineradores podem criar outra saída seguindo um segundo formato para sinalizar a ativação. Uma nova proposta de sidechain requer que 90% dos blocos em um período de dificuldade sinalizem para ativação para que uma nova criação de sidechain seja confirmada. Isso cria o mecanismo de peg para habilitar a sidechain, mas a interação entre sidechain e mainchain é mais sutil do que isso.

Neste ponto, qualquer um pode colocar moedas na cadeia lateral. Para se conectar ao sidechain, um usuário simplesmente cria uma transação de duas entradas com sua própria entrada e o UTXO correspondente ao saldo do sidechain com uma única saída atribuindo tudo ao sidechain. Isso garante que o sidechain tenha apenas um único UTXO contendo todos os fundos bloqueados nele. As retiradas são tratadas pela votação do minerador. A mainchain não entende quem possui o quê na sidechain, e a mainchain considerará válida qualquer retirada aprovada pelos mineradores dentro do mecanismo de votação. Por causa disso, há um longo atraso no processo de retirada. Existem duas fases no processo de retirada de uma sidechain: uma proposta de retirada (pacote) e, em seguida, a fase de votação de retirada. Os mineradores devem criar uma saída OP_RETURN em sua transação de base de moedas com um hash da transação de retirada proposta para propor uma retirada. Esse hash, no entanto, semelhante ao sighash, sinaliza apenas a confirmação de parte de uma transação em vez de toda a transação. Ele não se compromete com o UTXO de entrada que representa fundos bloqueados em um drivechain ou a saída que retorna tudo que não está sendo retirado para um UTXO sidechain especial. Isso ocorre porque qualquer depósito no drivechain criaria um novo UTXO e, assim, invalidaria o compromisso com a transação de retirada quando as pessoas fossem validá-la.

A partir daqui, começa o período de votação do minerador sobre a proposta de retirada. Depois que um pacote é proposto, os mineradores podem votar para aprová-lo ou não. Cada bloco que é minerado permite que o minerador incremente um contador de aprovação, para cima ou para baixo em um, ou dois para se abster de fazer qualquer coisa. Existem algumas limitações específicas além disso, porque é possível ter mais de um pacote para uma única sidechain - se um minerador optar por votar "sim" (aumentar o contador em um) para um pacote de retirada para uma sidechain eles devo vote “não” (diminua o contador em um) para todos os outros pacotes associados a essa sidechain específica.

Isso é para garantir que não haja “retiradas duplas”, onde alguém tem uma saída em vários pacotes que pagaria mais bitcoin na cadeia principal do que é devido.

Por outro lado, os mineradores também podem votar não para cada pacote proposto. Isso deve funcionar como uma espécie de alarme para todos que um minerador validando essas retiradas (certificando-se de que são moedas de propriedade legítima na sidechain sendo retirada) notou algo inválido acontecendo. Lembre-se, um ponto-chave desse design é que os mineradores não precisam validar nada na sidechain, portanto, a menos que decidam fazê-lo, muitos mineradores podem estar votando em pacotes que não estão verificando. Essa função de alarme foi projetada para que eles sejam alertados de que devem verificar os pacotes para garantir que não ocorra uma retirada fraudulenta.

Quando um pacote atinge o limite exigido (13,150 blocos, ou cerca de 90 dias), a transação que realmente processa a retirada se torna válida e pode ser confirmada. Mas o que as pessoas fazem se os mineradores aprovam uma retirada fraudulenta que rouba dinheiro da sidechain? A proposta da Sztorc é se envolver em um soft fork ativado pelo usuário (UASF) para invalidar a transação de peg-out inválida. Isso apresenta um enorme risco em termos de consenso para a cadeia principal. O UASF em 2017 foi um movimento de alto risco que mal conseguiu e o Bitcoin era muito menor do que é hoje. Quanto maior o Bitcoin crescer, mais difícil será coordenar essas ações.

Se você se lembrar do artigo sobre cadeias espaciais, esse projeto foi baseado em mineração mesclada cega (BMM). O projeto BMM de Ruben Somsen é na verdade a segunda variante disso, sendo o primeiro o projeto de Sztorc conforme estabelecido no BIP301. A especificação BMM em drivechains é composta por duas mensagens: uma mensagem de solicitação e uma mensagem de aceitação. Ambos são coordenados respectivamente por meio de um tipo de transação especial na cadeia principal e uma saída especial na transação de base de moedas de um minerador.

A transação de solicitação é construída por quem está criando blocos de sidechain. O ponto principal do BMM é que essa pessoa pode ser alguém que não está minerando, então a transação de solicitação existe para permitir que eles paguem aos mineradores para confirmar seu bloco de sidechain proposto. A proposta do bloco sidechain constrói uma transação que inclui o hash do bloco sidechain, o ID atribuído ao sidechain quando ele foi criado e os últimos quatro bytes do cabeçalho do bloco mainchain anterior. Existem três regras de consenso adicionais aplicadas a esses tipos de transações. Primeiro, uma transação de solicitação é inválida, a menos que também haja uma saída de aceitação correspondente na transação coinbase desse bloco. Isso é para garantir que os mineradores não possam cobrar uma taxa da solicitação sem também aceitar e minerar o bloco sidechain. Segundo, para cada sidechain, apenas uma transação de solicitação pode ser incluída em um bloco de mainchain. Isso é para garantir que apenas um bloco de qualquer sidechain possa realmente ser minerado por bloco de mainchain. Por último, os últimos quatro bytes do bloco de mainchain anterior devem corresponder. Isso garante que uma solicitação seja válida apenas para ser minerada no próximo bloco, e tais transações não podem ser mineradas posteriormente e roubar dinheiro de um proponente de bloco sidechain após o bloco de outra pessoa ter sido minerado.

A saída de aceitação é muito simples: dados do cabeçalho da mensagem e o hash do bloco sidechain. Se um minerador estiver executando um nó de drivechain, ele poderá simplesmente ignorar as transações de solicitação e sempre incluir sua própria saída de aceitação em sua base de moedas para minerar seus próprios blocos de sidechain. Juntos, esses dois aspectos permitem que os mineradores operem um nó de sidechain ou outro não minerador o faça e pague ao minerador para minerar seus blocos. A ideia é que, se os próprios mineradores não executarem as sidechains e consumirem os custos extras de validação, alguém poderá fazer isso por eles. Se houver competição em não mineradores tentando ganhar taxas na sidechain, eles provavelmente continuarão oferecendo a taxa que estão dispostos a pagar aos mineradores em sua transação de solicitação até que ela represente a maioria das taxas que eles ganham, com os não mineradores. minerador mantendo apenas uma pequena porcentagem do lucro e pagando o restante aos mineradores.

Essa é a mecânica por trás de como as cadeias de transmissão funcionam. Em seguida, sidechains federadas e, depois disso, um detalhamento de todos os pontos negativos e negativos que cada design pode ter.

Este é um post convidado por Shinobi. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.