Maxim Orlovsky, LNP/BP Standards Association
No artigo, propomos uma maneira de atualizar a camada 1 do Bitcoin (blockchain/timechain) sem um softfork necessário. A atualização aproveita as propriedades da validação do lado do cliente, pode ser gradual, possui uma opção de implantação sem permissão (ou seja, não exigindo suporte majoritário ou cooperação de mineiro) e terá a escalabilidade do pedido
A palavra Bitcoin adquiriu vários significados, assim os distinguimos usando termos mais específicos. Utilizamos o Bitcoin como um termo genérico de guarda-chuva que denota o sistema como um todo, que pode incluir várias camadas (incluindo algum futuro) e a idéia geral do sistema eletrônico ponto a ponto originário de Satoshi Nakamoto. Ao mesmo tempo, usamos o BTC para denotar o Bitcoin como uma escassez digital, dinheiro e moeda. Também distinguimos o consenso do Bitcoin POW (a regra de selecionar o próximo produtor de blocos), o consenso de Nakamoto (que inclui consenso de PoW aprimorado com meios de punição de mineiro criptonomia), Bitcoin Blockchain (alternativamente chamado Timechain ) como uma implementação atual específica da camada de bitcoin 1 e O protocolo Bitcoin (BP) como um conjunto de padrões, tecnologias e ferramentas para trabalhar com transações Bitcoin na cadeia (em qualquer camada possível 1).
A implementação original do Bitcoin de Satoshi Nakamoto trouxe a estranha idéia de que todo mundo precisa para verificar transações para o mundo inteiro. Essa idéia recebeu o nome de blockchain , ou, às vezes, Timechain - que se tornou um eufemismo para um livro com acesso público. A introdução do livro criou dois problemas: ausência de escalabilidade e pouca privacidade; O primeiro impede que a adoção e o efeito de rede ocorram; O outro contradiz o espírito original de Cypherpunk do Bitcoin e representa um risco civilizacional estratégico (ver inevitabilidade do Cypherpunk para uma civilização adequada e um manifesto de cifernox).
A escalabilidade e, parcialmente, os problemas de privacidade foram abordados posteriormente pela introdução de sistemas da camada 2, como Rede Lightning e outras soluções propostas. Entre eles, o menos frutífero foi a idéia de Sidechain, que herdou a maioria (se não todas) das limitações originais da tecnologia da blockchain, enquanto resolveu apenas um problema de baixa programação, criou uma caixa de areia para experimentos e, parcialmente, alguns aspectos da privacidade. Rede Lightning - uma solução de camada 2 mais bem -sucedida que já está implantada e operacional - tem seus próprios problemas de escalabilidade devido à necessidade de liquidez excessiva de colateralização, limitações da taxa de transferência de tráfego de fofocas (ambos levando à centralização da rede) e diminuição da segurança/falta de confiança sob condições de alta camada de base [..]. Outras alternativas propostas, como a Ark, requerem várias alterações na camada base (um ou dois softforks), o que apresenta desafios para a implantação. Finalmente, nenhuma das soluções de segunda camada existente ou proposta resolve os problemas de privacidade da camada base original da base Bitcoin-e outras soluções de camada 1 focada na privacidade (como a Coinjoin) ainda não protegem das autoridades legais e introduzem problemas adicionais de fungibilidade do BTC.
Assim, pode-se concluir que é a abordagem blockchain baseada em contabilidade para a construção da camada 1, que deve ser totalmente repensada para resolver os problemas acima. As primeiras idéias neste espaço vieram com as costas de Peter Todd em 2016 e 2017, quando ele apontou que os proprietários de algum estado (por exemplo, BTC ou qualquer outro contrato de estado) precisam verificar apenas uma parte da história transacional - a parte que é diretamente relacionado à sua propriedade - e omita o resto. Ele nomeou sua abordagem de validação do lado do cliente . O protocolo projetado pela Giacomo Zucco é capaz de criar ativos com essa abordagem, denominada RGB . No meu trabalho anterior na Associação de Padrões de LNP/BP, pude desenvolver ainda mais o RGB e convertê-lo no primeiro sistema genérico de contrato inteligente validado ao cliente com rico estado e computação completa de Turing, fornecendo funcionalidade suficiente para executar qualquer coisa que pode ser feito com contratos inteligentes baseados em blockchain-mas sem o livro público/blockchain armazenando qualquer dados do usuário, utilizando diretamente as propriedades anti-duplas do protocolo de consenso do Bitcoin POW. Este sistema foi desenvolvido publicamente durante quatro anos e foi lançado em abril de 2023.
Na proposta atual, demonstramos que o Bitcoin, se fornecido com uma camada validada do lado do cliente (como RGB), pode ser atualizada para um sistema sem as propriedades limitantes do livro público (blockchain) e, ao preservar o protocolo de consenso de Pow, Ele pode ser baseado em uma nova camada escalável não-blockchain 1 (codinome Prime ). Essa camada poderá hospedar um número teoricamente indefinido de transações (pelo menos bilhões por minuto), pois o armazenamento de estado, computação e validação será movido para a camada validada do lado do cliente acima. Esse design não requer rede de raios ou outras camadas de escalabilidade e pagamento na parte superior e escalas no pior cenário
O protocolo possui três opções de implantação (sem permissão, ativado por mineiro e softfork), com os dois primeiros não exigindo qualquer garfo macio (ou duro). As opções são independentes, mas também podem ser implantadas de maneira conseqüente.
A proposta oferece vários benefícios ao Bitcoin como dinheiro digital:
Algumas desvantagens relativas do sistema proposto são:
O sistema proposto (codinome Prime ) consiste em quatro componentes principais:
Esses componentes são equivalentes conjuntamente em sua funcionalidade a um livro do tipo blockchain; No entanto, em nosso design, eles ficam abstratos, fornecendo muito mais escalabilidade e privacidade do que qualquer outro sistema de blockchain.
Em sua fundação, o Prime executa um serviço de data e hora, criando uma sequência de cabeçalhos, cada um se comprometendo com uma raiz da árvore de merkle de dados externos de validação do lado do cliente:
ClassDiagram
direção lr
`Cabeçalho n` <|-` cabeçalho n+1`
classe `cabeçalho n` {
prev_commitment
Merkle_root
Merkle_tree_height
Timestamp
// Campos de Pow
tlv_extensions
}
classe `cabeçalho n+1` {
prev_commitment
Merkle_root
Merkle_tree_height
Timestamp
// Campos de Pow
tlv_extensions
}
Cada cabeçalho é equipado com uma extensão opcional de TLV, que pode ser usada para futuras atualizações de protocolo; Seu tamanho é independente do número de transações contidas na árvore Merkle dos dados validados do lado do cliente e é da ordem de 100 bytes (dependendo dos dados do TLV).
O Prime não fornece proteção contra gastos duplos; Será fornecido pela parte validada do lado do cliente do sistema. As únicas partes do sistema de registro de data e hora que são validadas (regras de consenso) são:
Os cabeçalhos principais são as únicas informações que devem estar disponíveis publicamente e globalmente; Isso pode ser alcançado usando uma rede P2P distribuída.
As árvores de Merkle Proof ( PMT ) são uma estrutura intermediária e efêmera que liga dados validados do lado do cliente aos cabeçalhos. Os PMTs são produzidos pelos mineiros e disponibilizados ao público por meio ou alguns outros meios que os cabeçalhos; No entanto, diferentemente dos cabeçalhos, eles não são obrigados a persistir. Cada usuário de rede rastreia todos os novos PMTs, extrai parte das informações relacionadas ao estado que possui, salva-as em seu próprio estoque de dados validados ao lado do cliente e descarta o restante do PMT.
Devido à natureza efêmera, à ausência de validação e à necessidade de conhecer o conteúdo de PMT para minerar o próximo cabeçalho, o tamanho do PMT não afeta a escalabilidade do sistema. Assim, o PMT pode ter um tamanho de gigabyte (múltiplo), comprometendo -se a bilhões e bilhões de transações.
As folhas das árvores contêm testemunhas de fechamento de selos de uso único: um mecanismo descrito em detalhes na próxima seção. Os PMTs são construídos de acordo com o esquema de compromisso determinístico de multiprotocolo, padrão LNPBP-4 e hoje usado no RGB para hospedar compromissos nas transações de bitcoin (protocolos na cadeia e dentro do offchain, como raios). Isso significa que cada sela de uso único tem uma colocação predefinida única no PMT, de modo que um único caminho de merkle e uma testemunha de folhas seja suficiente para provar o fechamento-ou ausência de fechamento-de uma sela de uso único específico no dado cabeçalho. Os usuários acompanham um conjunto de seus selos de uso único que ainda não foram fechados (análogo do conjunto UTXO) e extraem provas relativas de cada PMT recém-produzido. Se seus selos não foram fechados, essas são as provas de uma não operação (já que a testemunha demonstra um selo de uso único diferente sendo fechado nesse caminho).
As provas constituem uma parte crescente dependente do tempo da história validada do lado do cliente. Os requisitos de memória para um nó crescerão de maneira dependente do tempo como
onde
Isso é logaritmicamente melhor do que a escalabilidade de qualquer nó blockchain, onde os requisitos de memória estão crescendo como
onde
onde
O
onde
O protocolo de uso único impede ataques de dupla gasto ao sistema.
As selos de uso único (ou focas ) são uma forma especial de comprometimento criptográfico proposto por Peter Todd. O primitivo pode ser comparado a outras formas de compromissos criptográficos que incluem funções de hash e registro de data e hora:
Mais informações sobre a construção de selos de uso único são fornecidos no padrão LNPBP-8. O Prime usa uma forma especialmente projetada de selos de uso único, que é diferente da usada nos protocolos existentes (como o RGB).
A definição de uma sela de uso único consiste em dois componentes:
unique_id : Identificador gerado pelo usuário globalmente, que pode ser determinista gerado a partir do contrato, operação de contrato hash e número de saída da operação de contrato;spending_conditions_cmt : Compromisso (hash) das condições sob as quais o selo pode ser fechado no futuro (semelhante ao scriptPubkey na saída da transação Bitcoin). As focas são definidas no sistema de contrato inteligente validado do lado do cliente (RGB ou RGB). Cada vedação pode ter um estado atribuído (como no RGB), por exemplo, saldo do BTC ou qualquer outro dados rico. Quando um usuário gosta de atualizar esse estado-ou transferir sua propriedade para outro usuário, uma transição de estado deve ser preparada, definindo novos (s) sela (s) de uso único e o novo estado. Em seguida, uma testemunha encerrando que a sela de uso único é construído, comprometendo-se com os dados de transição do estado e fornecendo script de origem, correspondendo ao compromisso das condições de gasto e dados que satisfazem esse script/condições. A proposta abstrava de um sistema de script específico usado (pode ser simplicidade, aluvm como no RGB hoje e esperando não EVM :); O mecanismo de script pode ser especificado usando o campo version , de modo que novos motores ou códigos de operação possam ser introduzidos ao longo do tempo (consulte a seção de atualização):
ClassDiagram
direção lr
Definição <|- Testemunha: Única_id
definição de classe {
exclusivo_id
SPENDER_CONDITOS_CMT
}
Testemunha da classe {
versão
exclusivo_id
state_transition_cmt
SPENDER_CONDITIONS_SRC
satisfação_data
}
A testemunha é colocada na forma explícita dentro de uma folha de um pTree e fornecida aos mineiros, construindo o pTree e os cabeçalhos. A folha deve ser colocada dentro da árvore Merkle deterministicamente em relação ao selo unique_id , por exemplo no slot
Caminho de Merkle para a folha correspondente unique_id , juntamente com o conteúdo das folhas (fornecendo dados de testemunhas) permite verificar se cada sela de uso único foi fechado uma vez e apenas uma vez na história de um contrato inteligente-e que foi fechado satisfazendo o script condições. Observe que as provas precisam ser acumuladas para cada um unique_id de uso único, a partir do momento de sua definição até o fechamento-um requisito para provar que o selo não foi fechado no meio. Essas provas, desde que demonstrem diferentes unique_id , podem omitir as condições de gastos sensíveis à privacidade e dados fonte de satisfação, fornecendo apenas seu hash; Assim, as testemunhas históricas podem ser de tamanho fixo. Como mencionado anteriormente, para fins de escalabilidade, o histórico de provas também pode ser mais compactado usando provas de conhecimento zero.
O sistema, quando implantado com a opção sem permissão, exigirá seu próprio protocolo de consenso. A segurança do protocolo não é crítica, pois está atrelada ao Bitcoin POW Security com um mecanismo dedicado descrito abaixo. O único requisito para o consenso é ser resistente à censura, o que significa um conjunto aberto de mineradores/validadores sem identidade. Os únicos dois protocolos de consenso conhecidos por estarem satisfazendo essas propriedades são o POW e a variante de Ouroboros Crypsinous do consenso da BFT criptonomicamente protegido pelas recompensas do mineiro.
O serviço de registro de data e hora não cuida de criptomoeda, e os mineradores são recompensados com as taxas desde o dia 1. Um contrato dedicado para as taxas de mineiro é fornecido pelo RGB ou por outro protocolo de contrato inteligente validado do lado do cliente, que especifica meios de pagamento (BTC , Stablecoin ou pagamentos tokenizados). Os mineradores devem participar de uma rede P2P anônima sem permissão, onde os usuários dos protocolos publicam suas testemunhas equipadas com transações pagando uma taxa a "quem minera o próximo cabeçalho". Os mineradores incluem essas transações em sua história validada do lado do cliente e, ao fazer isso, têm a capacidade de usar os fundos ganhos no futuro.
No momento do lançamento do sistema, é criada uma saída dedicada "qualquer pessoa que pode-se" com uma quantidade de poeira de poeira é criada no Bitcoin Blockchain. As informações sobre isso UTXO se tornam parte da gênese e servem como uma definição de uma mineração de uso único . Um mineiro que resolve o Desafio de Pow deve gastar essa saída e dentro da transação de bitcoin gastos fornece um compromisso de tapret com o cabeçalho minerado e um novo selo de uso único de "qualquer pessoa" para o próximo mineiro. Isso ancora o cabeçalho criado para o Bitcoin Blockchain de uma maneira única, de modo que a única sequência de cabeçalho de registro de data e hora válido é a que segue essa sequência de selos de uso único.
Se uma parte gasta a atual mineração de uso único sem criar um compromisso-ou se comprometer com um cabeçalho sem prisioneiros de guerra, esse fechamento é considerado inválido; Nesse caso, qualquer parte pode criar uma transação especial de Bitcoin, fornecendo informações OP_RETURN identificáveis publicamente ("anúncio") sobre uma nova mineradora de uso único ( redefinição do protocolo ); Somente o primeiro anúncio OP_RETURN que é fechado com um procedimento adequado é considerado válido nas regras de consenso.
A ancoragem da POW de uso único representa um protocolo de consenso completo que pode ser executado pelo sistema sem qualquer outro consenso adicional (POW ou BFT). Como alternativa, ele pode ser combinado com um consenso secundário com uma regra de que, a menos que a segurança do segundo protocolo de consenso seja menor que a segurança do bitcoin POW, o Pow Bitcoin tem a prioridade - com um interruptor automático de volta ao consenso secundário como um consenso primário quando este condição não é atendida.
Deliberadamente não abordamos a questão da estrutura de rede P2P nesta proposta, pois vários sistemas alternativos podem coexistir e competir de maneira orientada pelo mercado. Em vez disso, como as propriedades da rede são importantes para os objetivos do projeto, definimos os requisitos gerais para a seleção de uma rede P2P:
No momento atual do tempo, não vemos uma rede atendendo às propriedades acima mencionadas; No entanto, vemos várias redes com potencial para se desenvolver em relação a eles:
Planejamos trabalhar no projeto Renostr, utilizando nosso trabalho anterior do Storm Protocol e usando a criptografia de ponta a ponta no estilo BIP-324. Outros projetos podem criar soluções alternativas, e a melhor opção deve ser selecionada pelo mercado.
Vemos três etapas - ou opções - na maneira como a solução proposta pode ser implantada no Bitcoin. Cada uma das etapas é opcional; O sistema pode operar sem nenhum ou dois deles. Além disso, cada opção tem suas próprias trocas, no entanto, se implantadas como etapas consequentes, essas compensações são gradualmente resolvidas.
O sistema pode ser lançado de forma independente do bitcoin Timechain, com o consenso ancorado à segurança do Bitcoin Pow por meio de um mecanismo dedicado baseado em selos de uso único (que descrevemos no artigo). Isso não requer alterações no lado do mineiro ou em qualquer bitcoin Soft/Hardforks, no entanto, com essa configuração BTC pode ser transferida para o novo sistema, sem confiança apenas de uma maneira - e de outra maneira exigirá uma federação.
Os mineradores de Bitcoin começam a processar transações principais e se comprometem com os cabeçalhos de serviço de timestamping na coinbase de blockchain Bitcoin - como fazem em um caso de mineração mesclada. Isso remove a necessidade de um consenso primário dedicado, mas é vulnerável a ataques de poder de hash, exigindo que a grande maioria dos mineiros se juntasse ao protocolo antes de sua implantação.
A proposta não requer nenhum softfork específico, no entanto, com as regras atuais de consenso de Bitcoin. Não pode fornecer uma maneira sem confiável para que o BTC seja movido do novo sistema Prime de volta ao Bitcoin Blockchain. Embora não vemos isso como um requisito (o Prime tem muitos benefícios sobre a blockchain, de modo que consideramos o blockchain já estar morto a longo prazo), a curto prazo isso pode apresentar um desafio para a adoção da plataforma.
Existem muitas propostas diferentes de forros suaves que podem permitir essa funcionalidade. Eles se enquadram em duas categorias principais:
A adoção de qualquer uma dessas propostas permitirá um pino sem confiança para o BTC na plataforma Prime. Nossas próprias preferências vão depois de codos op de ligação a zero, pois eles têm muitos outros benefícios e não fornecem trocas inevitáveis em DriveChains.
A atualização de um sistema validado do lado do cliente é muito diferente da atualização da Blockchain-ou da rede P2P (como um raio). Isso é causado pelo fato de que os blockchains são protocolos de consenso que são máquinas de estado totalmente replicadas, enquanto a validação do lado do cliente usa replicação parcial. Por um lado, isso torna mais simples atualizar o sistema em partes relacionadas ao estado desconhecido-mas por outro , é muito mais difícil coordenar qualquer atualização.
Em outras palavras, as atualizações de validação do lado do cliente são fundamentalmente diferentes para as forças e softforks blockchain e exigem a introdução de novos conceitos e termos.
Se algo foi inválido e se tornou válido após uma atualização (chamamos isso de alteração rápida ), todos os usuários existentes não serão afetados: eles já possuem e gerenciam o estado que é válido. No entanto, eles podem não ser capazes de interagir com os usuários executando versões mais antigas do software - um problema solucionável se seus colegas concordarem em atualizar. A atualização não apresenta riscos a esses colegas, pois eles não usarão nenhum estado que possuem - e a atualização não tocará os dados históricos.
Por outro lado, a situação em que algo era válido - e se tornou inválido sob as novas regras - é muito diferente: os usuários podem perder seu estado existente para sempre e devem se opor a uma atualização o máximo possível. Chamamos essas atualizações de recaídas e as vemos aceitáveis apenas se um bug crítico foi descoberto: a atualização será "coordenada" pelo desejo de usuários sinceros/não chefados para evitar problemas introduzidos pelo bug.
Se o sistema inspirado em RGB ou RGB for usado como um componente de contrato inteligente, as atualizações desta parte terão outro recurso distinto. O RGB isola cada programa ("contrato inteligente") em uma caixa de areia; E um contrato, uma vez emitido, não pode atualizar para a nova versão do protocolo. A única maneira de atualizar é produzir um novo contrato quando um emissor (ou partes às quais foi delegado pelos emissores, incluindo a comunidade) fará uma transferência de estado do contrato antigo para o novo - e cada um dos contratos Os proprietários concordarão com isso.
Como um benefício colateral, essa abordagem permite a introdução gradual de novos recursos, instruções etc., não possível no mundo da blockchain: emissores dos novos contratos não dependem das versões de protocolo anteriores e podem propor soluções mais avançadas sem nenhum risco de atualização adicional ou Coordenação da comunidade.
O autor agradece a Giacomo Zucco, que era a pessoa insipulando com a idéia de remover a dependência do Bitcoin no blockchain restrito e ver a validação do lado do cliente como um caminho a seguir. Várias discussões com ele e Peter Todd ao longo dos anos ajudaram a projetar muitas partes do sistema. Entre outros, o autor gostaria de mencionar Alex Kravets, Federico Tenga, Olga Ukolova, que foram os interlocutores que passaram muitas horas discutindo questões relacionadas à validação do lado do cliente, falhas de blockchain e designs sem blockchain.
