Para todos / Como funciona
Liquidação e o registro
O conteúdo de cada bloco é publicado, em ordem, bloco 0 incluído, e a Ethereum sempre guarda ou os dados ou um compromisso com dados disponíveis em outro lugar. É isso que torna a cadeia verificável em vez de meramente afirmada.
Dois níveis de publicação
| Nível | O que guarda |
|---|---|
| Camada de disponibilidade de dados | a carga completa, por blocoendereçada por conteúdo, indexada pelo seu hash; o sequenciador verifica o resumo de confirmação antes de confiar nele |
| Caixa de entrada na Ethereum | um envelope compacto que nomeia a cargaum compromisso por meta de agendamento de 60 s, blob ou calldata escolhido a partir de preços medidos |
| Alternativa | a carga completa como calldata na Ethereumtomada sempre que o caminho de disponibilidade de dados falha, para que a cadeia continue derivável durante uma interrupção |
Imagine uma loja que guarda todo recibo numa sala de arquivo e, uma vez por minuto, envia ao banco um resumo lacrado dizendo "aqui está a impressão digital dos recibos que acabei de arquivar". O banco não consegue ler os recibos a partir da impressão digital, mas qualquer pessoa que entre na sala de arquivo pode verificar que nada foi alterado. E se a sala de arquivo alguma vez ficar inacessível, a loja envia ao banco os próprios recibos. O sequenciador da Pickle é a loja, a camada de disponibilidade de dados é a sala de arquivo, e a Ethereum é o banco.
Cada bloco selado produz uma carga de derivação com a sua lista completa de transações. A carga é armazenada numa camada de disponibilidade de dados endereçada por conteúdo, indexada pelo seu hash, e o sequenciador verifica a confirmação antes de confiar nela. Um envelope compacto que nomeia essa carga é então comprometido num contrato de caixa de entrada na Ethereum. Se o caminho de disponibilidade de dados falhar por qualquer razão, a carga completa é publicada na Ethereum como calldata.
Todo bloco é publicado, em ordem, bloco 0 incluído. A caixa de entrada aceita anexos apenas da chave de batcher designada e emite um evento indexado por lote; esse índice é a ordem total que todo verificador segue.
A carga transporta a lista completa de transações do bloco junto com o intervalo de blocos, o hash do pai, o hash do bloco e o timestamp comprometido; o timestamp é incluído porque faz parte do ambiente de execução, não só do cabeçalho, e uma réplica precisa executar contra o mesmo relógio para selar o mesmo hash. A publicação tem dois níveis: a carga para um armazenamento endereçado por conteúdo sob o seu hash, com verificação do resumo na confirmação, e um envelope para a caixa de entrada da L1 por janela de agregação. A caixa de entrada é restrita ao batcher e emite um evento indexado por anexo. O instrumento de compromisso, blob ou calldata, é selecionado por submissão a partir de preços medidos, já que neste tamanho de carga o gas de execução domina com taxas de blob baixas e o calldata simples vence com taxas altas.
O que uma carga transporta
- A lista completa de transações do bloco, para que nada sobre o bloco precise ser confiado.
- O intervalo de blocos, o hash do pai e o hash do bloco, para que a réplica saiba onde ele se encaixa e o que precisa reproduzir.
- O timestamp comprometido, porque uma transação que leu o relógio viu aquele valor, e uma réplica executando contra um relógio diferente selaria um hash diferente.
Por que um compromisso por janela
A Ethereum não recebe uma transação por bloco selado. Os dados completos vão para a camada de disponibilidade de dados por bloco; um compromisso vai para a Ethereum por janela de agregação, a uma meta de agendamento de 60 segundos. A agregação é o que mantém o custo de liquidação modelado nos poucos milhões de dólares por ano, em vez das dezenas ou centenas de milhões que um projeto de publicação por bloco acarretaria. A página dos limites dá a faixa modelada e em que ela se apoia.
Verificação independente
Qualquer operador pode rodar o mesmo binário como uma réplica. Ela não produz nada. Ela lê a caixa de entrada na Ethereum a partir do seu último índice aplicado, busca cada carga pelo seu endereço de conteúdo ou decodifica a alternativa em calldata, reexecuta cada transação em ordem contra o timestamp comprometido, sela o bloco localmente e compara o hash com o que o sequenciador comprometeu.
Em qualquer divergência, uma réplica para permanentemente
A divergência é terminal por projeto: tentar de novo selaria mais blocos e se afastaria da cadeia canônica, enterrando a causa. Uma réplica parada é o sinal de que os dados publicados e o hash comprometido discordam. Nada on-chain arbitra essa discordância; a página do modelo de confiança diz o que decorre disso.
Uma réplica sincronizada serve o RPC de leitura padrão a partir do seu próprio estado, derivado de forma independente. Seus saldos, recibos e cabeçalhos são rederivados localmente, não cópias confiadas das respostas do sequenciador. A submissão de transações é encaminhada ao sequenciador; uma réplica não aceita nada num mempool local.
De onde o histórico é lido
O sequenciador é otimizado para responder sobre o presente e guarda uma janela curta de blocos recentes. O histórico completo é indexado no banco de dados do explorador, que é alimentado continuamente pelo sequenciador e é onde qualquer coisa histórica é respondida. Ambos estão a jusante das mesmas cargas publicadas, e uma réplica pode reconstruir qualquer um deles apenas a partir da Ethereum e da camada de disponibilidade de dados.