Título original: "Bedrock Explicador"
Escrito por: Oficial do Otimismo
Compilado por: Frank, Foresight News
Bedrock é o nome da primeira versão oficial do OP Stack, um conjunto de componentes modulares gratuitos e de código aberto projetados para impulsionar o crescimento do Optimism.
Resumo de melhoria
Bedrock melhora seu antecessor, incluindo:
Reduza as taxas de transação usando compactação otimizada de transações em lote e Ethereum como camada de disponibilidade de dados;
Latência reduzida no empacotamento de transações L1 em rollups por meio de melhor tratamento de reorganizações L1;
Habilite sistemas de prova modulares por meio da reutilização de código;
Melhore o desempenho do nó eliminando dívidas de design.
taxas mais baixas
Bedrock usa uma estratégia otimizada de compactação de dados para minimizar os custos de dados. Atualmente estamos avaliando o impacto dessa mudança, mas esperamos que ela reduza significativamente as taxas.
A Bedrock também elimina todos os custos de gás associados à execução do EVM ao enviar dados para L1, o que reduzirá os custos em mais 10% em comparação com as versões anteriores do protocolo.
Tempo de crédito de depósito mais curto
A Bedrock introduziu suporte para reorganizações L1 no software do nó, o que reduz significativamente o tempo que os usuários têm de esperar para que os depósitos sejam creditados.
Versões anteriores do protocolo podem levar até 10 minutos para que os depósitos sejam confirmados, enquanto com Bedrock esperamos que os depósitos sejam confirmados em 3 minutos.
Prova modular aprimorada
Bedrock abstrai o sistema de prova da pilha OP para que o rollup possa usar provas de falha ou provas de validade (como zk-SNARK) para provar a execução correta após a entrada no rollup. Essa abstração também permitirá o uso de Cannon para provar o. falha de sistema.
Melhor desempenho do nó
O desempenho do software Node é significativamente melhorado com a execução de múltiplas transações em um único "bloco" de rollup, em vez do modelo "uma transação por bloco" das versões anteriores.
Isso permite que o custo das atualizações do Merkle Trie seja distribuído por múltiplas transações, o que, nos volumes atuais de transações, reduz o crescimento dos dados estaduais em aproximadamente 15 GB por ano.
O desempenho do nó também foi melhorado, eliminando a dívida técnica das versões anteriores do protocolo, incluindo a eliminação da necessidade de um nó de "camada de transporte de dados" separado para indexar L1 e atualizando o software do nó para consultar com eficiência as transações dos dados L1.
Equivalência Ethereum aprimorada
Bedrock foi projetado desde o início para ser o mais "consistente" possível com o Ethereum, e muitos desvios do Ethereum nas versões anteriores do protocolo foram eliminados, incluindo:
Modelo “Uma transação por bloco”;
Personalize o opcode para obter informações do bloco L1;
Campos de taxa L1/L2 separados na API JSON-RPC;
Representação ERC20 personalizada de saldos ETH.
Bedrock também adicionou suporte para EIP-1559, reorganização de blockchain e outros recursos Ethereum presentes em L1.
Princípios de design
Bedrock foi construído para ser modular e escalável, reutilizando o código existente do Ethereum e visando atingir 100% de equivalência do Ethereum sempre que possível.
Modular
Ao usar interfaces e esquemas de controle de versão bem definidos, a Bedrock pode facilmente substituir diferentes componentes na pilha OP e adicionar novas funcionalidades.
Isto permite-lhe adaptar-se ao desenvolvimento futuro do ecossistema Ethereum com uma arquitetura flexível, tal como:
O nó rollup é separado do cliente de execução;
Design modular à prova de falhas.
reutilização de código
Bedrock usa a arquitetura e infraestrutura Ethereum existente sempre que possível. Essa abordagem permite que o OP Stack herde as vantagens de segurança e do efeito Lindy da base de código testada em batalha usada pela rede principal Ethereum.
Você encontrará exemplos disso em todo o design, incluindo:
cliente de execução minimamente modificado;
Contratos EVM em vez de código de cliente pré-compilado.
Equivalência Ethereum
Bedrock foi projetado para ser compatível ao máximo com as experiências existentes de desenvolvedores Ethereum, mas há algumas exceções devido a diferenças fundamentais entre L1 e rollup: diferentes modelos de taxas, tempos de bloqueio mais rápidos (2 segundos vs 12 segundos) e tipos de transações especiais, incluindo transações de depósito L1.
Essas exceções incluem:
Prova de falhas de clientes de execução Ethereum projetada para provar modificações mínimas;
Ethereum realiza reutilização de código do lado do cliente para uso por nós e ordenadores na rede L2.
protocolo
Os rollups são construídos com base na disponibilidade de dados (geralmente um blockchain L1 como o Ethereum). Na configuração mais comum, o protocolo rollup deriva uma "cadeia L2 canônica" de duas fontes principais de informação:
Os dados da transação são publicados em L1 pelo sequenciador;
As transações de depósito são submetidas por contas e contratos inteligentes ao contrato ponte em L1.
A seguir estão os componentes básicos do acordo:
Ao interagir diretamente com o contrato inteligente em L1, o depósito é escrito na "cadeia L2 padrão";
As retiradas são gravadas na "cadeia canônica L2" e acionam implicitamente interações com contratos inteligentes e contas em L1;
Os lotes são gravações de dados correspondentes aos lotes no rollup;
A derivação de bloco é como interpretar leituras de dados em L1 para entender a "cadeia canônica L2";
O sistema de prova define a finalidade das raízes de saída publicadas em L1 para que possam ser executadas (por exemplo, realizar retiradas).
depósito
O depósito é uma transação em L1 e será incluído no rollup. Por definição, é garantido que os depósitos sejam incluídos na "cadeia L2 canônica" como um meio de evitar a censura ou o controle da L2.
Qualquer mensagem entregue de L1
As transações de depósito são transações de rollup realizadas como parte de um depósito. Com Bedrock, os depósitos são transações Ethereum totalmente universais, como contas no Ethereum ou contratos inteligentes podem criar contratos de “depósito”.
Bedrock define um contrato de depósito disponível em L1: é um contrato inteligente com o qual contas L1 e contratos inteligentes podem interagir para gravar em L2. As transações de depósito em L2 são derivadas de transações emitidas por este contrato de depósito e incluem parâmetros esperados, como de, para e dados.
Consulte a seção Especificações do Contrato de Depósito para obter detalhes.
Compre gás L2 garantido em L1
Bedrock também esclareceu o mecanismo de queima de gás e o mercado de taxas de depósito. O gás gasto em transações de depósito L2 é adquirido em L1 por meio da queima de gás.
Este Gás é adquirido especificamente no mercado de taxas e há um limite rígido para a quantidade total de Gás fornecido para todas as transações de depósito em um único bloco L1. Este mecanismo é usado para evitar ataques de negação de serviço (DoS) que possam ocorrer. Ao escrever transações de L1 para L2, porque essas transações consomem muito Gás em L2, mas são muito baratas em L1.
O gás fornecido para transações de depósito é às vezes chamado de “Gás Garantido”. O Gás Garantido é o único que é pago pela queima de Gás no L1 e, portanto, não é reembolsável.
E a quantidade total de gás L1 necessária para ser queimada por unidade de gás L2 garantido depende do preço do gás L2 relatado pelo mecanismo de cobrança estilo EIP-1559. Além disso, os usuários recebem uma franquia dinâmica de gás com base na quantidade de gás L1 gasto no cálculo das atualizações do mecanismo de taxas.
Para uma explicação mais aprofundada, leia as especificações do protocolo na seção de depósito.
Retirar dinheiro
As retiradas são transações entre camadas iniciadas em L2 e concluídas por transações executadas em L1. É importante notar que as contas L2 podem usar saques para chamar contratos L1 ou transferir ETH de contas L2 para contas L1.
A retirada é iniciada chamando o contrato pré-implantado do Message Passer em L2, que registra as propriedades importantes da mensagem em seu armazenamento, e então a retirada é concluída em L1 chamando o contrato OptimismPortal para comprovar a inclusão desta mensagem de retirada.
Desta forma, os levantamentos e os depósitos são diferentes: as transacções de levantamento devem ser concluídas utilizando contratos inteligentes em L1, em vez de depender de informações derivadas de blocos.
Processo de retirada em duas etapas
Erros de validação de prova de retirada têm sido a causa raiz de muitos hacks de pontes entre cadeias nos últimos anos. A versão Bedrock introduz uma etapa adicional no processo de retirada de versões anteriores, projetada para fornecer defesa adicional contra esses tipos de erros.
No processo de retirada em duas etapas, cada retirada deve apresentar a prova Merkle correspondente à retirada 7 dias antes da saída final. Este novo mecanismo de segurança dá às ferramentas de monitoramento 7 dias completos para encontrar e detectar invalidez do certificado de retirada.
Se o certificado de retirada for considerado inválido durante esse período, os reparos inteligentes do contrato poderão ser implementados antes que os fundos sejam perdidos, o que reduz bastante o risco de comprometimento da ponte entre cadeias.
Consulte a seção Especificações do Acordo de Retirada para obter detalhes.
Lotes
No Bedrock, um formato com fio é definido para a passagem de mensagens entre L1 e L2 (ou seja, L2 deriva blocos de L1, L2 grava transações em L1), esse formato com fio é projetado para reduzir ao mínimo o custo de gravação em L1 e a complexidade do software.
Otimize a compactação de dados
Para otimizar a compactação de dados, listas de transações L2 (chamadas de batches do sequenciador) são organizadas em grupos de objetos (chamados de canais). O tamanho máximo de cada canal pode ser definido em um parâmetro configurável, que inicialmente será definido como 9,5 M. Esses canais serão definidos. espera-se que seja compactado usando a função de compactação e enviado para L1.
envio paralelo em lote
Para paralelizar mensagens de sequenciadores que enviam dados de canal compactados para L1, os canais são ainda decompostos em "quadros de canal", que são pedaços de dados de canal compactados que podem caber em uma única transação L1.
Supondo que os "frames de canal" sejam independentes entre si e a ordem seja conhecida, as transações Ethereum enviadas para L1 pelo sequenciador podem ser enviadas em paralelo, minimizando assim a complexidade do software sequenciador e permitindo o preenchimento de todo o espaço de dados disponível em L1.
Minimizando o gás Ethereum
Bedrock remove todo o gás de execução usado pelo sistema L1 para enviar dados do canal para L1 em transações chamadas “transações em lote”. Toda a lógica de verificação que ocorria anteriormente em contratos inteligentes L1 foi movida para a lógica de derivação de bloco. Em vez disso, as “transações em lote” são enviadas para um único endereço EOA no Ethereum, chamado de “endereço de caixa de entrada em lote”.
Os lotes ainda estão sujeitos a verificações de validade (ou seja, devem ser codificados corretamente), assim como as transações individuais dentro do lote (por exemplo, as assinaturas devem ser válidas), lotes inválidos e transações individuais inválidas dentro de lotes válidos são consideradas descartadas e irrelevantes para o sistema.
Nota: Ethereum será atualizado em breve para uma nova versão que inclui EIP-4844, que introduz um mercado separado de taxas de gravação de dados e aumenta o limite superior da quantidade de dados que o protocolo Ethereum está disposto a armazenar. o número de custos associados à publicação em L1.
Para uma explicação mais detalhada, leia a Especificação de formato de cabo.
Garfo de bloco
No Bedrock, o protocolo é projetado para garantir que o tempo dos depósitos em L1 esteja relacionado à derivação do bloco da "cadeia L2 canônica". O que isso faz é uma função pura de gravação de dados em L1 por meio do sequenciador, depósito e propriedades do bloco L1.
Para conseguir isso, o protocolo define estratégias para garantir depósitos, lidar com carimbos de data/hora L1 e L2 e lidar com janelas de pedidos no canal para garantir a ordem correta.
Depósito garantido em conta
Os objetivos do protocolo de derivação de bloco são definidos da seguinte forma:
Depois de decorrido cada "intervalo de bloco L2", deve haver um bloco L2 e o carimbo de data e hora do bloco L2 é sincronizado com o carimbo de data e hora do L1 (ou seja, garantindo que os depósitos sejam incluídos na ordem cronológica lógica).
No Bedrock, o conceito de "época de sequenciamento" é introduzido: é o intervalo de blocos L2 derivado de uma série de blocos L1. Cada época é identificada por um "número de época", que é igual ao número na janela de classificação. O número de sequência do bloco do primeiro bloco L1. O tamanho das épocas pode variar, sujeito a algumas restrições.
O canal derivado de lote trata o carimbo de data/hora do bloco L1 associado ao "número da época" como a âncora para determinar a ordem das transações em L2. O protocolo garante que o primeiro bloco L2 de uma época nunca ficará atrás do carimbo de data/hora do bloco L1 da época correspondente. O primeiro bloco de uma época deve conter depósitos em L1 para garantir que o depósito será processado.
Observe que na versão Bedrock, o intervalo de bloco alvo em L2 é configurado para 2 segundos.
Tratamento de carimbos de data/hora L1 e L2
Bedrock tenta resolver o problema de reconciliar carimbos de data/hora em L2 com carimbos de data/hora em L1 que existem em transações de depósito.
Ele faz isso permitindo um curto espaço de tempo para a classificação aplicar livremente carimbos de data/hora em transações L2 entre épocas.
A janela de sequenciamento é a sequência de blocos L1 a partir dos quais as épocas podem ser derivadas. Em uma janela de classificação, o primeiro bloco L1 número N contém as "transações em lote" da época.
A janela de classificação contém blocos, que dependem do tamanho da janela de classificação: um parâmetro de configuração de nível de rollup fixo deve ser pelo menos 2, aumentá-lo dará ao sequenciador mais oportunidades para classificar transações L2 em depósitos, diminuindo-o para sequenciamento. janela introduzida pelo servidor para enviar "transações em lote". Este é um compromisso entre a criação de oportunidades MEV e o aumento da complexidade do software.
Uma constante de protocolo chamada "desvio máximo do sequenciador" controla o carimbo de data / hora máximo que um bloco pode ter dentro de sua época. Com esse desvio, o sequenciador pode ter problemas temporários para se conectar ao L1.
Bloquear pipeline de garfo
A "cadeia L2 canônica" pode ser processada do zero, começando do estado de gênese L2, definindo o início da cadeia L2 para a primeira época e, em seguida, processando todas as janelas de classificação para determinar os lotes do sequenciador de acordo com a seguinte ordem simplificada e sequência correta para depositando tubos:
À prova de falhas
Após o sequenciador processar um ou mais blocos L2, as saídas dos cálculos de transação executados nesses blocos precisarão ser escritas em L1 para permitir a execução sem confiança de mensagens L2 a L1, como retiradas, etc.
No Bedrock, a saída é hash na forma de uma estrutura em árvore, minimizando o custo de comprovação de qualquer dado capturado pela saída. Os proponentes submetem periodicamente raízes de saída para L1 que servem como raízes de Merkle para toda a "cadeia canônica L2".
As futuras atualizações do OP Stack devem incluir uma especificação de uma variante à prova de falhas com ligações para incentivar os proponentes a propor raízes de saída corretas.
Para obter detalhes completos, leia a especificação do protocolo na seção Proposta de raiz de saída L2.
implemento
No Bedrock, o OP Stack depende fortemente da separação especificada de preocupações técnicas do Ethereum, espelhando a separação entre a camada de execução e a camada de consenso do Ethereum.
Portanto, Bedrock introduziu a separação entre clientes de execução e nós de rollup da mesma maneira.
Executar cliente
Clientes de execução são sistemas que sequenciadores e outros tipos de operadores de nó executam para determinar o estado da cadeia L2 canônica. Ele também executa outras funções, como lidar com transações de entrada e comunicações ponto a ponto, bem como processar o estado do sistema para lidar com consultas direcionadas a ele.
Com o Bedrock, o OP Stack visa reutilizar a especificação do cliente de execução do Ethereum e muitas de suas operações de execução. Nesta versão, Bedrock demonstrou uma modificação extremamente limitada no cliente Ethereum go-ethereum, com uma diferença de menos de 2.000 linhas de código.
Existem duas razões fundamentais para a diferença: processamento de transações de depósito e cobrança de taxas de transação.
Processar transações de depósito
Para representar transações depositadas em um rollup, é introduzido um tipo de transação adicional. A implementação dos clientes que implementam este novo tipo de transação é baseada no padrão de transação do tipo EIP-2718.
Cobrar taxas de transação
Os rollups também têm essencialmente dois tipos de taxas relacionadas à transação:
Uma é a taxa do sequenciador. O custo de operação do sequenciador é calculado usando a mesma tabela de gases e o mesmo algoritmo EIP-1559 do Ethereum, que é usado pelo protocolo para operar o sequenciador e flutua ao longo do tempo com base no congestionamento da rede.
Outra taxa de disponibilidade de dados. Os custos de disponibilidade de dados estão associados à gravação de transações em lote para L1 e destinam-se a cobrir as taxas do sequenciador para enviar transações em lote para L1.
No Bedrock, a parte da taxa de disponibilidade de dados é determinada com base nas informações do contrato inteligente do sistema rollup chamado GasPriceOracle, que é baseado nos atributos do bloco L1 inseridos no início de cada época durante o processo de derivação do bloco. é atualizada.
Bedrock especifica que ambos os custos são adicionados em um campo ao usar JSON-RPC.
nó de acúmulo
Ao contrário do Ethereum, o Bedrock não possui consenso de PoS. Em contraste, o consenso de uma “cadeia L2 canônica” é definido pela derivação em bloco. O cliente de execução do OP Stack se comunica com um novo componente que implementa a bifurcação de bloco chamado nó rollup, que se comunica com o cliente de execução usando exatamente a mesma API de mecanismo do Ethereum.
O nó rollup é um componente sem estado responsável por derivar o estado do sistema através da leitura de dados e depósitos em L1. No Bedrock, os nós rollup podem ser usados para sequenciar transações recebidas de usuários ou outros nós rollup, ou para validar transações confirmadas publicadas em L1, confiando apenas em L1.
Os vários usos dos nós de rollup estão resumidos abaixo:
Verifique a "cadeia L2 canônica"
O modo mais simples de executar nós rollup é apenas seguir a "cadeia L2 canônica". Neste modo, o nó rollup não possui pares e é estritamente usado para ler dados de L1 e interpretar os dados de acordo com as regras do protocolo de derivação de bloco.
Um propósito de tal nó é verificar se quaisquer raízes de saída compartilhadas por outros nós ou publicadas em L1 estão corretas de acordo com a definição do protocolo. Além disso, os proponentes que pretendem enviar raízes de saída para L1 podem usar optimism_outputAtBlock para gerar as raízes de saída necessárias e retornar o hash de 32 bytes correspondente à raiz de saída L2.
Para fazer isso, os nós devem apenas seguir o cabeçalho do bloco "finalizado". O termo "finalizado" refere-se ao consenso Ethereum PoS (ou seja, canônico e quase irreversível), e o cabeçalho do bloco L2 "finalizado" é a área da "cadeia L2 canônica" derivada apenas do bloco L1 "finalizado". cabeça.
Participe da rede L2
A maneira mais comum de usar um nó rollup é participar de uma rede de outros nós rollup, rastreando processos e status L2. Neste modo, o nó rollup lê simultaneamente os dados e os depósitos que observa em L1, interpreta-os em blocos e aceita transações de entrada de usuários e pares na rede de outros nós rollup.
Os nós participantes da rede podem usar os cabeçalhos de bloco seguros e inseguros do L2 com os quais estão sincronizando.
Os cabeçalhos de bloco L2 seguros representam rollups que podem ser construídos nos quais cada bloco (incluindo cabeçalhos) pode ser totalmente derivado da cadeia L1 de referência antes que L1 deva ser "finalizado" (ou seja, a reorganização ainda pode ocorrer em L1);
Os cabeçalhos de bloco L2 inseguros incluem blocos inseguros que não foram derivados de L1. Esses blocos vêm da operação do nó rollup como um sequenciador ou da sincronização insegura com o sequenciador. Isso também é chamado de cabeçalho de bloco "mais recente". Em caso de desacordo, escolha sempre o cabeçalho do bloco L2 seguro em vez do cabeçalho do bloco L2 inseguro. Quando ocorre um desentendimento, a parte insegura da cadeia se reorganiza;
Na maioria dos casos, para aplicações de usuário final, os nós de rollup na rede L2 farão referência a cabeçalhos de bloco L2 inseguros.
Classificação de transações
A terceira maneira de usar nós de rollup é ordenar transações. Neste modo, os nós rollup criarão novos blocos sobre cabeçalhos de bloco L2 inseguros. Atualmente, existe apenas um sequenciador por rede OP Stack.
O sequenciador também é responsável por publicar lotes de transações em L1 para que outros nós da rede possam sincronizar a partir dele.
Dosador
A função de um sequenciador é produzir lotes de transações; para esse propósito, os sequenciadores podem executar nós de rollup e ter processos separados que executam lotes lendo os nós de rollup confiáveis em que são executados.
Isso garante que um componente complementar da pilha OP, chamado manipulador de transação em lote, leia os dados da transação do nó rollup e os interprete em uma transação em lote a ser gravada em L1, o componente batcher é responsável pela leitura e execução por o sequenciador O nó acumula o cabeçalho do bloco L2 inseguro, cria transações em lote e as grava em L1.
Contrato de ponte padrão
Bedrock também inclui um par de contratos-ponte para os tipos mais comuns de depósitos, chamados de Contrato-Ponte Padrão. Esses contratos encapsulam contratos de depósito e retirada, fornecendo uma interface simples para depósitos e retiradas de tokens ETH e ERC-20.
Esses contratos de ponte são projetados de modo que um lado da ponte entre cadeias tenha o token nativo e o outro lado contenha um token empacotado que pode gerenciar a cunhagem e a queima. A ponte do token nativo envolve bloquear o token nativo no contrato e, em seguida, bloquear o token. token nativo na ponte de cadeia cruzada. O outro lado emite uma quantidade igual de tokens encapsulados.
Para obter mais informações, consulte a seção Especificação do protocolo de ponte cruzada padrão.
Canhão
Embora a construção e a verificação à prova de falhas sejam implementadas no Cannon, a especificação do jogo à prova de falhas e a integração do desafiante raiz de saída no nó rollup fazem parte dos marcos de especificação subsequentes.
Leitura adicional
Especificações do protocolo
A especificação do protocolo define os detalhes técnicos da pilha OP e é a fonte de verdade mais atualizada sobre o funcionamento interno do protocolo.
Diferença fundamental
Para uma análise aprofundada das diferenças entre o Bedrock e as versões anteriores, consulte Como o Bedrock é diferente.