Esta postagem descreverá uma abordagem bastante simples e bem integrada para fazer o armazenamento distribuído da história do Ethereum e uma extensão para armazenar o estado.
Etapa 1: coloque o conteúdo do bloco em blobs
Colocamos a história do Ethereum em bolhas. A maneira natural de fazer isso é ter uma função get_blobs(block_body) -> List(Blob) que serializa o corpo do bloco e o divide em blobs. Em seguida, exigimos que os hashes com versão do primeiro blob na lista de hash com versão do blob de um cabeçalho de bloco sejam iguais (get_versioned_hash(blob) for blob in get_blobs(block.body)).
Por conveniência, podemos separar os blobs do corpo CL dos blobs do corpo EL (ou seja, ExecutionPayload), então podemos fazer com que as provas ZK-EVM incluam apenas os hashes versionados como testemunha pública. Isso permite que um bloco seja verificado puramente por
- baixando os cabeçalhos
- fazendo uma verificação DAS para os blobs
- baixando e verificando diretamente apenas a parte CL,
- verificando a prova ZK-EVM
Quando todos os recursos do Lean Consensus forem introduzidos, a parte CL também receberá uma prova ZK, e teremos alcançado o ideal completo de ter uma cadeia que você pode verificar apenas verificando cabeçalhos, DAS e provas – total “verificabilidade em um smartwatch”.
Podemos tornar o procedimento acima mais limpo, dividindo a carga útil e ajustando algumas constantes. Particularmente, se (i) fizermos EIP-7976 e com o mesmo gasprice para bytes zero e diferentes de zero, e (ii) aumentarmos o tamanho do blob quando atualizarmos os blobs para resistentes a quantum (ou até mesmo antes), então poderemos obter a garantia de que cada pedaço de carga útil pode caber dentro de um blob (!!). Por exemplo, se definirmos o custo dos dados de chamada para 64 gases por byte, graças ao EIP-7825, teremos um limite rígido de que um tx serializado é inferior a 256 kB, portanto, se definirmos o tamanho do blob para 256 kB, obteremos essa garantia.
Também precisaremos fazer o mesmo para listas de acesso em nível de bloco, incluindo garantir que a invariante rígida “64 gases por byte” seja refletida para cada componente e para a combinação.
Etapa 2: armazenamento aleatório do histórico de blobs
Adicionamos uma regra segundo a qual cada cliente deve armazenar uma amostra selecionada aleatoriamente de cada blob que vê. Se nós:
- Defina o tamanho da amostra para 512 bytes (reduzido dos atuais 2.048) para maximizar a largura de banda do PeerDAS
- Suponha uma média agressiva de blobs de tamanho de 64.256 kB por slot (16 MB), o que é suficiente para um aumento de aproximadamente 20x no espaço de blob L2 em comparação com o status quo, ou aproximadamente 128x o limite de gás atual, ou uma mistura de ambos
Então obtemos:
- Cada cliente armazena 1/512 de cada blob, então você precisa de aproximadamente 710 nós honestos (acima de 512 devido à sobreposição) para armazenar >= 50% dos blobs para poder recuperar todos eles.
- A carga de cada cliente será (agressivos 128 blobs por slot)
512 * 62 * 31556926 / 12bytes = 80 GB por ano, o que está aproximadamente em linha com a carga extra razoável a ser imposta aos nós de consenso
A consulta de blobs pode ser feita redefinindo o mecanismo DAS existente ou criando um protocolo dedicado mais otimizado para o processo de sincronização.
Etapa 3: adicionar armazenamento
Na verdade, isso não requer nenhum trabalho. Se as listas de acesso ao nível do bloco estiverem incluídas em blobs, então já pode sincronizar blobs do estado mais recente que conhece (se necessário, o instantâneo do momento da fusão) e reproduzir as atualizações para calcular o estado atual. Se desejar, também poderíamos adicionar um mecanismo de “percorrer repetidamente a árvore da esquerda para a direita”, embora não esteja claro se vale a pena a complexidade.
Fontesethresear
