Desde o advento do BTC em 2009, o Bitcoin passou por três iterações técnicas e evoluiu de um simples conceito de ativos nativos digitais para um sistema financeiro descentralizado com funções e aplicações complexas.
Este artigo é escrito pelo fundador da BEVM,** que compartilha seus insights sobre a evolução da tecnologia BTC, e também responde em detalhes como a BEVM, que é um marco fundamental no desenvolvimento da tecnologia BTC Layer 2, pode realizar a prosperidade futura do ecossistema descentralizado do BTC no nível técnico. **
Neste artigo, você aprenderá mais sobre:
A necessidade do BTC Layer 2
Como alcançar a Camada 2 do BTC?
Solução BEVM totalmente descentralizada
Homenagem às 3 grandes iterações tecnológicas revolucionárias do BTC desde o seu nascimento:
2009: O BTC nasceu, a primeira vez a usar a estrutura do blockchain para abrir aplicações de dinheiro descentralizadas.
2017: BTC Segregated Witness foi atualizado para suportar armazenamento de até 4MB, resolvendo o problema de armazenamento on-chain do BTC. Isso também fornece a base para o agora explosivo protocolo Ordinais (emissão de ativos).
2021: BTC Taproot foi atualizado para suportar o algoritmo de assinatura de limiar BTC, que fornece suporte subjacente para a tecnologia BTC Layer2 totalmente descentralizada.
Primeiro, por que você quer fazer BTC Layer2?**
1. Há demanda: A rede Bitcoin atende às necessidades de registro de ativos, mas ainda há um grande número de ativos que precisam ser liquidados on-chain (Camada 2)
Atualmente, a Camada 2 da ETH é apenas uma cópia da Camada 1 da ETH, e não há nada que a Camada 1 não possa resolver, mas os problemas de negócios reais que a Camada 2 tem que resolver.
Deve-se dizer que a ETH Layer 2 resolve o problema da ETH Layer 1: a Layer 2 resolve o problema do gás caro da Layer 1. É precisamente por causa desta exigência que a primeira aplicação de derivados da ETH no Layer2 Arbitrum, como o GMX, foi alcançada.
E a Camada 2 do BTC não é tão irrelevante quanto a Camada 2 da ETH.
Como a máquina virtual on-chain não-Turing-complete BTC só pode registrar ativos, mas não pode fazer liquidação, a Camada 1 do BTC deve precisar da Camada 2 BTC Turing-complete para liquidar ativos emitidos pela Camada 1 do BTC.
2.Capacidade: BTC pode ser transformado em uma Camada 2 totalmente descentralizada
Antes da atualização do BTC Taproot em 2021, era impossível alcançar uma Camada 2 BTC totalmente descentralizada. No entanto, após esta atualização, o algoritmo de assinatura de limiar BTC permite que o BTC suporte uma camada de computação Layer2 totalmente descentralizada.
II.Como alcançar BTC L2 descentralizado?
As Propostas de Melhoria do Bitcoin (BIPs) são documentos de design que introduzem novos recursos e informações ao Bitcoin, enquanto as atualizações taproot são uma compilação de três BIPs, ou seja, Schnorr Signature (BIP 340), Taproot (BIP 341) e Tap (BIP 342), coletivamente conhecidos como BIP Taproot.
Ele trará uma maneira mais eficiente, flexível e privada de transferir Bitcoin através do uso de assinaturas Schnorr e árvores de sintaxe abstrata de Merkel.
As assinaturas Schnorr são um esquema de assinatura digital conhecido pela sua simplicidade e segurança. As assinaturas Schnoor oferecem várias vantagens em termos de eficiência computacional, armazenamento e privacidade.
! [Fundador da BEVM: Por que e como fazer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/f2c90430573edf17b34bc2b81d6fba2e.)
O utilizador confirma a identidade do signatário através da chave pública e o conteúdo do contrato através dos dados, de modo a autenticar a validade do contrato digital.
As Assinaturas Agregadas Schnorr podem compactar e mesclar vários dados de assinatura em uma única assinatura agregada.
O verificador verifica uma única assinatura agregada com uma lista de todos os dados associados às assinaturas e chaves públicas, o que equivale a verificar de forma independente todas as assinaturas relevantes.
! [Fundador da BEVM: Por que e como fazer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/c7ed182df952263f95cd6b5da86e5aa3.)
Atualmente, a maioria dos blockchains usa o algoritmo ECDSA multisig, no qual cada nó gera uma assinatura digital independente com sua própria chave privada para dados de bloco e os transmite para outros nós. O outro nó verifica a assinatura e a grava no próximo bloco de dados.
Desta forma, quando o número de nós de consenso é grande, os dados de assinatura armazenados em cada rodada de blocos de consenso continuarão a aumentar, ocupando espaço de armazenamento.
Sempre que um novo nó se junta à rede e precisa sincronizar blocos históricos, uma grande quantidade de dados de assinatura representará um grande desafio para a largura de banda da rede.
Depois de usar a tecnologia de assinatura agregada, cada nó coletará os cartões de visita de assinatura agregada transmitidos por outros nós e, em seguida, salvará a agregação de estilhaços de assinatura, conforme mostrado na Figura 2.**
Dessa forma, quando um novo nó se junta, o bloco de histórico de sincronização só precisa baixar os dados de assinatura agregados, o que reduz muito a ocupação da largura de banda da rede e reduz o gasto de taxas de transação.
Além disso, a agregação de chaves faz com que todas as saídas Taproot pareçam semelhantes. Seja uma saída de várias assinaturas, uma saída de assinatura única ou outros contratos inteligentes complexos, todos eles parecem iguais no blockchain, então muitas análises de blockchain não estarão disponíveis, preservando a privacidade de todos os usuários do Taproot. **
! [Fundador da BEVM: Por que e como fazer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/187dbc4fe20ec85e558eb12132a2a850.)
O MAST (Merkle Abstract Syntax Tree) é uma série de scripts não sobrepostos (por exemplo, multisig ou timelock) que usam uma árvore Merkle para criptografar scripts de bloqueio complexos.
Ao gastar, apenas o script em questão e o caminho desse script até a raiz da árvore Merck precisam ser divulgados. Como mostra a Figura 3, para usar 1, você só precisa divulgar 1, 2 e hash3.
Os principais benefícios do MAST incluem:
1) Apoio a condições de despesa complexas
2) Não há necessidade de divulgar scripts não executados ou condições de gastos não acionadas, proporcionando melhor proteção de privacidade
**3) Compactar o tamanho da transação: À medida que o número de scripts aumenta, o tamanho da transação não-MAST aumenta linearmente, enquanto o tamanho da transação MAST aumenta logaritmicamente. **
No entanto, há um problema na atualização do Taproot, ou seja, o P2SH não é o mesmo que o Common Pay-to-Public-Key-Hash (P2PKH), e ainda há problemas de proteção de privacidade.
É possível fazer com que P2SH e P2PKH tenham a mesma aparência on-chain?
Para este fim, Taproot propõe uma solução que pode ser dividida em duas partes para um script com um número limitado de signatários:
A primeira parte é multisig, onde todos os signatários concordam com um determinado resultado de gasto, conhecido como "gasto colaborativo".
A segunda parte é chamada de "gastos não colaborativos" e pode ter estruturas de script muito complexas.
Estas duas partes são a relação de "ou".
Como mostrado nas Figuras 3 e 3, um multisig 2-de-2 requer que Alice e Bob sejam válidos, o que é "gasto colaborativo" e 1 e 2 são "gastos não colaborativos".
Tanto as «despesas colaborativas» como as «despesas não colaborativas» podem gastar estes resultados, quando:
Para o script de "gastos não colaborativos", adote a abordagem MAST descrita acima e use MerkleRoot para representar a raiz da árvore Merck.
Para o script de "gastos colaborativos", adota-se um algoritmo multisig baseado em assinaturas de Schnoor. Pa e Pb são usados para representar as chaves públicas de Alice e Bob, respectivamente, e Da e Db são usados para representar as chaves privadas de Alice e Bob, respectivamente.
Portanto, a chave pública agregada é P=Pa+Pb e a chave privada correspondente é Da+Db.
Combinar "despesas colaborativas" e "despesas não colaborativas" sob a forma de P2PKH, e a sua chave pública é: PP+H(P||MerkleRoot)G; a chave privada correspondente é Da+Db+H(P||MerkleRoot)。
Quando Alice e Bob concordam com "gastos colaborativos", eles usam Da+Db+H(P||MerkleRoot) requer apenas um deles para adicionar H(P||) à sua chave privadaMerkleRoot).
On-chain, isso se comporta como uma transação P2PKH, com uma chave pública e uma chave privada correspondente, sem a necessidade de divulgar o MAST subjacente.
III. Nossa solução de camada BTC totalmente descentralizada:
3.1 BTC light node + contrato de assinatura de limiar distribuído
! [Fundador da BEVM: Por que e como fazer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/d6ddaf08422a0b02bc25e45cd2f5d947.)
Neste esquema, n (n pode ser todos os validadores no BEVM) validadores fixos são selecionados para completar o contrato de custódia agregada on-chain BTC com assinatura de limiar distribuído.
A chave privada de cada validador na camada BEVM2 também é derivada de uma parte da chave privada agregada da assinatura limite do BTC, e a chave privada do limiar de n validadores é combinada no endereço da foto da assinatura agregada do BTC. **n pode ser até 1000 ou mais. **
Quando o usuário A quer cruzar a cadeia BTC para BEVM, ele só precisa enviar BTC para o contrato de custódia de agregação Bitcoin, e o usuário pode receber BTC na camada BEVM2.
Correspondentemente, quando o usuário A executa uma operação de retirada, ele só precisa interoperar com m auto-completar contratos de assinatura de limiar distribuído na assinatura agregada entre n validadores, e a transferência do contrato de depósito para o usuário A pode ser concluída em Bitcoin, e o BTC será queimado no BEVM ao mesmo tempo em que a transferência é concluída.
3.2 Implemente BTC como uma taxa de gás nativa e Camada 2 compatível com EVM
1) Princípio EVM
A Máquina Virtual Ethereum é o ambiente de tempo de execução para contratos inteligentes Ethereum. Não só é sandboxed, mas na verdade é completamente isolado.
Isso significa que o código em execução no EVM não pode acessar a rede, o sistema de arquivos e outros processos. Até mesmo o acesso entre contratos inteligentes é restrito.
A camada subjacente do Ethereum suporta a execução e invocação do contrato através do módulo EVM, e o código do contrato é obtido de acordo com o endereço do contrato quando chamado, e é carregado no EVM para operação. Normalmente, o processo de desenvolvimento de contrato inteligente é escrever código lógico em solidlidade, compilá-lo em bytecode através de um compilador e, finalmente, publicá-lo no Ethereum.
! [Fundador da BEVM: Por que e como fazer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/2d2d923b8ae9ff718bac8dedbf6a9314.)
2) Peças principais EVM
! [Fundador da BEVM: Por que e como fazer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/67f265774f666ae9ab031a29230b5b8d.)
3)Código EVM
O código EVM é o código da máquina virtual Ethereum, que se refere ao código da linguagem de programação que o Ethereum pode conter. O código EVM associado a uma conta é executado cada vez que uma mensagem é enviada para a conta e tem a capacidade de ler/escrever armazenamento e enviar mensagens por conta própria.
4)Estado de Mchine
O Estado Mchine é onde o código EVM é executado, contendo contadores de programas, pilhas e memória.
5) Armazenamento
O armazenamento é um espaço de armazenamento persistente que pode ser lido, gravado e modificado, e também é o local onde cada contrato armazena dados persistentemente. O armazenamento é um mapa enorme, com um total de 2256 slots, cada um com 32bytes cada.
6) BTC como Taxa de Gás
Deixe que o BTC transferido da rede Bitcoin seja usado como a moeda de cálculo da taxa de gás para a execução de transações no EVM.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Fundador da BEVM: Por que e como fazer BTC Layer 2?
Autor: Peter
Preâmbulo
Desde o advento do BTC em 2009, o Bitcoin passou por três iterações técnicas e evoluiu de um simples conceito de ativos nativos digitais para um sistema financeiro descentralizado com funções e aplicações complexas.
Este artigo é escrito pelo fundador da BEVM,** que compartilha seus insights sobre a evolução da tecnologia BTC, e também responde em detalhes como a BEVM, que é um marco fundamental no desenvolvimento da tecnologia BTC Layer 2, pode realizar a prosperidade futura do ecossistema descentralizado do BTC no nível técnico. **
Neste artigo, você aprenderá mais sobre:
A necessidade do BTC Layer 2
Como alcançar a Camada 2 do BTC?
Solução BEVM totalmente descentralizada
Homenagem às 3 grandes iterações tecnológicas revolucionárias do BTC desde o seu nascimento:
2009: O BTC nasceu, a primeira vez a usar a estrutura do blockchain para abrir aplicações de dinheiro descentralizadas.
2017: BTC Segregated Witness foi atualizado para suportar armazenamento de até 4MB, resolvendo o problema de armazenamento on-chain do BTC. Isso também fornece a base para o agora explosivo protocolo Ordinais (emissão de ativos).
2021: BTC Taproot foi atualizado para suportar o algoritmo de assinatura de limiar BTC, que fornece suporte subjacente para a tecnologia BTC Layer2 totalmente descentralizada.
Primeiro, por que você quer fazer BTC Layer2?**
1. Há demanda: A rede Bitcoin atende às necessidades de registro de ativos, mas ainda há um grande número de ativos que precisam ser liquidados on-chain (Camada 2)
Atualmente, a Camada 2 da ETH é apenas uma cópia da Camada 1 da ETH, e não há nada que a Camada 1 não possa resolver, mas os problemas de negócios reais que a Camada 2 tem que resolver.
Deve-se dizer que a ETH Layer 2 resolve o problema da ETH Layer 1: a Layer 2 resolve o problema do gás caro da Layer 1. É precisamente por causa desta exigência que a primeira aplicação de derivados da ETH no Layer2 Arbitrum, como o GMX, foi alcançada.
E a Camada 2 do BTC não é tão irrelevante quanto a Camada 2 da ETH.
Como a máquina virtual on-chain não-Turing-complete BTC só pode registrar ativos, mas não pode fazer liquidação, a Camada 1 do BTC deve precisar da Camada 2 BTC Turing-complete para liquidar ativos emitidos pela Camada 1 do BTC.
2.Capacidade: BTC pode ser transformado em uma Camada 2 totalmente descentralizada
Antes da atualização do BTC Taproot em 2021, era impossível alcançar uma Camada 2 BTC totalmente descentralizada. No entanto, após esta atualização, o algoritmo de assinatura de limiar BTC permite que o BTC suporte uma camada de computação Layer2 totalmente descentralizada.
II.Como alcançar BTC L2 descentralizado?
As Propostas de Melhoria do Bitcoin (BIPs) são documentos de design que introduzem novos recursos e informações ao Bitcoin, enquanto as atualizações taproot são uma compilação de três BIPs, ou seja, Schnorr Signature (BIP 340), Taproot (BIP 341) e Tap (BIP 342), coletivamente conhecidos como BIP Taproot.
Ele trará uma maneira mais eficiente, flexível e privada de transferir Bitcoin através do uso de assinaturas Schnorr e árvores de sintaxe abstrata de Merkel.
As assinaturas Schnorr são um esquema de assinatura digital conhecido pela sua simplicidade e segurança. As assinaturas Schnoor oferecem várias vantagens em termos de eficiência computacional, armazenamento e privacidade.
! [Fundador da BEVM: Por que e como fazer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/f2c90430573edf17b34bc2b81d6fba2e.)
O utilizador confirma a identidade do signatário através da chave pública e o conteúdo do contrato através dos dados, de modo a autenticar a validade do contrato digital.
As Assinaturas Agregadas Schnorr podem compactar e mesclar vários dados de assinatura em uma única assinatura agregada.
O verificador verifica uma única assinatura agregada com uma lista de todos os dados associados às assinaturas e chaves públicas, o que equivale a verificar de forma independente todas as assinaturas relevantes.
! [Fundador da BEVM: Por que e como fazer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/c7ed182df952263f95cd6b5da86e5aa3.)
Atualmente, a maioria dos blockchains usa o algoritmo ECDSA multisig, no qual cada nó gera uma assinatura digital independente com sua própria chave privada para dados de bloco e os transmite para outros nós. O outro nó verifica a assinatura e a grava no próximo bloco de dados.
Desta forma, quando o número de nós de consenso é grande, os dados de assinatura armazenados em cada rodada de blocos de consenso continuarão a aumentar, ocupando espaço de armazenamento.
Sempre que um novo nó se junta à rede e precisa sincronizar blocos históricos, uma grande quantidade de dados de assinatura representará um grande desafio para a largura de banda da rede.
Depois de usar a tecnologia de assinatura agregada, cada nó coletará os cartões de visita de assinatura agregada transmitidos por outros nós e, em seguida, salvará a agregação de estilhaços de assinatura, conforme mostrado na Figura 2.**
Dessa forma, quando um novo nó se junta, o bloco de histórico de sincronização só precisa baixar os dados de assinatura agregados, o que reduz muito a ocupação da largura de banda da rede e reduz o gasto de taxas de transação.
Além disso, a agregação de chaves faz com que todas as saídas Taproot pareçam semelhantes. Seja uma saída de várias assinaturas, uma saída de assinatura única ou outros contratos inteligentes complexos, todos eles parecem iguais no blockchain, então muitas análises de blockchain não estarão disponíveis, preservando a privacidade de todos os usuários do Taproot. **
! [Fundador da BEVM: Por que e como fazer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/187dbc4fe20ec85e558eb12132a2a850.)
O MAST (Merkle Abstract Syntax Tree) é uma série de scripts não sobrepostos (por exemplo, multisig ou timelock) que usam uma árvore Merkle para criptografar scripts de bloqueio complexos.
Ao gastar, apenas o script em questão e o caminho desse script até a raiz da árvore Merck precisam ser divulgados. Como mostra a Figura 3, para usar 1, você só precisa divulgar 1, 2 e hash3.
Os principais benefícios do MAST incluem:
1) Apoio a condições de despesa complexas
2) Não há necessidade de divulgar scripts não executados ou condições de gastos não acionadas, proporcionando melhor proteção de privacidade
**3) Compactar o tamanho da transação: À medida que o número de scripts aumenta, o tamanho da transação não-MAST aumenta linearmente, enquanto o tamanho da transação MAST aumenta logaritmicamente. **
No entanto, há um problema na atualização do Taproot, ou seja, o P2SH não é o mesmo que o Common Pay-to-Public-Key-Hash (P2PKH), e ainda há problemas de proteção de privacidade.
É possível fazer com que P2SH e P2PKH tenham a mesma aparência on-chain?
Para este fim, Taproot propõe uma solução que pode ser dividida em duas partes para um script com um número limitado de signatários:
A primeira parte é multisig, onde todos os signatários concordam com um determinado resultado de gasto, conhecido como "gasto colaborativo".
A segunda parte é chamada de "gastos não colaborativos" e pode ter estruturas de script muito complexas.
Estas duas partes são a relação de "ou".
Como mostrado nas Figuras 3 e 3, um multisig 2-de-2 requer que Alice e Bob sejam válidos, o que é "gasto colaborativo" e 1 e 2 são "gastos não colaborativos".
Tanto as «despesas colaborativas» como as «despesas não colaborativas» podem gastar estes resultados, quando:
Para o script de "gastos não colaborativos", adote a abordagem MAST descrita acima e use MerkleRoot para representar a raiz da árvore Merck.
Para o script de "gastos colaborativos", adota-se um algoritmo multisig baseado em assinaturas de Schnoor. Pa e Pb são usados para representar as chaves públicas de Alice e Bob, respectivamente, e Da e Db são usados para representar as chaves privadas de Alice e Bob, respectivamente.
Portanto, a chave pública agregada é P=Pa+Pb e a chave privada correspondente é Da+Db.
Combinar "despesas colaborativas" e "despesas não colaborativas" sob a forma de P2PKH, e a sua chave pública é: PP+H(P||MerkleRoot)G; a chave privada correspondente é Da+Db+H(P||MerkleRoot)。
Quando Alice e Bob concordam com "gastos colaborativos", eles usam Da+Db+H(P||MerkleRoot) requer apenas um deles para adicionar H(P||) à sua chave privadaMerkleRoot).
On-chain, isso se comporta como uma transação P2PKH, com uma chave pública e uma chave privada correspondente, sem a necessidade de divulgar o MAST subjacente.
III. Nossa solução de camada BTC totalmente descentralizada:
3.1 BTC light node + contrato de assinatura de limiar distribuído
! [Fundador da BEVM: Por que e como fazer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/d6ddaf08422a0b02bc25e45cd2f5d947.)
Neste esquema, n (n pode ser todos os validadores no BEVM) validadores fixos são selecionados para completar o contrato de custódia agregada on-chain BTC com assinatura de limiar distribuído.
A chave privada de cada validador na camada BEVM2 também é derivada de uma parte da chave privada agregada da assinatura limite do BTC, e a chave privada do limiar de n validadores é combinada no endereço da foto da assinatura agregada do BTC. **n pode ser até 1000 ou mais. **
Quando o usuário A quer cruzar a cadeia BTC para BEVM, ele só precisa enviar BTC para o contrato de custódia de agregação Bitcoin, e o usuário pode receber BTC na camada BEVM2.
Correspondentemente, quando o usuário A executa uma operação de retirada, ele só precisa interoperar com m auto-completar contratos de assinatura de limiar distribuído na assinatura agregada entre n validadores, e a transferência do contrato de depósito para o usuário A pode ser concluída em Bitcoin, e o BTC será queimado no BEVM ao mesmo tempo em que a transferência é concluída.
3.2 Implemente BTC como uma taxa de gás nativa e Camada 2 compatível com EVM
1) Princípio EVM
A Máquina Virtual Ethereum é o ambiente de tempo de execução para contratos inteligentes Ethereum. Não só é sandboxed, mas na verdade é completamente isolado.
Isso significa que o código em execução no EVM não pode acessar a rede, o sistema de arquivos e outros processos. Até mesmo o acesso entre contratos inteligentes é restrito.
A camada subjacente do Ethereum suporta a execução e invocação do contrato através do módulo EVM, e o código do contrato é obtido de acordo com o endereço do contrato quando chamado, e é carregado no EVM para operação. Normalmente, o processo de desenvolvimento de contrato inteligente é escrever código lógico em solidlidade, compilá-lo em bytecode através de um compilador e, finalmente, publicá-lo no Ethereum.
! [Fundador da BEVM: Por que e como fazer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/2d2d923b8ae9ff718bac8dedbf6a9314.)
2) Peças principais EVM
! [Fundador da BEVM: Por que e como fazer BTC Layer2?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/67f265774f666ae9ab031a29230b5b8d.)
3)Código EVM
O código EVM é o código da máquina virtual Ethereum, que se refere ao código da linguagem de programação que o Ethereum pode conter. O código EVM associado a uma conta é executado cada vez que uma mensagem é enviada para a conta e tem a capacidade de ler/escrever armazenamento e enviar mensagens por conta própria.
4)Estado de Mchine
O Estado Mchine é onde o código EVM é executado, contendo contadores de programas, pilhas e memória.
5) Armazenamento
O armazenamento é um espaço de armazenamento persistente que pode ser lido, gravado e modificado, e também é o local onde cada contrato armazena dados persistentemente. O armazenamento é um mapa enorme, com um total de 2256 slots, cada um com 32bytes cada.
6) BTC como Taxa de Gás
Deixe que o BTC transferido da rede Bitcoin seja usado como a moeda de cálculo da taxa de gás para a execução de transações no EVM.