Pesquisadores da Ethereum estão explorando um design proposto que move dados de 'payloads' de execução para 'blobs' publicados juntamente com os blocos, visando reduzir as demandas de largura de banda e permitir maior escalabilidade.

Numa publicação de pesquisa recente intitulada "Blocks Are Dead. Long Live Blobs" (Blocos Morreram. Viva os Blobs), coautoria de Toni Wahrstatter e outros colaboradores da Ethereum, os autores apresentam a EIP-8142, ou “Block-in-Blobs” — uma proposta preliminar introduzida pela primeira vez este ano.

O design codificaria dados de transação diretamente em 'blobs' — um formato de dados introduzido na atualização EIP-4844 da Ethereum — em vez de exigir que os validadores baixem e reexecutem 'payloads' de execução completos.

A ideia visa um gargalo na arquitetura da Ethereum, de acordo com os pesquisadores.

O aumento dos tamanhos dos blocos, juntamente com limites de 'gas' mais altos, significa que os validadores devem baixar e verificar um conjunto de dados crescente. Isso aumenta a pressão sobre a largura de banda e limita a escalabilidade.

Em março de 2024, os 'blobs' foram introduzidos como parte do roteiro de disponibilidade de dados da Ethereum durante a atualização Dencun.

Entregues via EIP-4844, também conhecida como 'proto-danksharding', os 'blobs' são projetados para transportar grandes blocos de dados de forma mais eficiente do que o 'calldata' de transações padrão.

Em vez de armazenar todos os detalhes da transação diretamente na 'onchain' e exigir que os validadores processem esses dados, os 'blobs' permitem que os dados sejam comprometidos criptograficamente e verificados sem replicação total em toda a rede.

Block-in-Blobs

A EIP-8142 estende essa ideia ainda mais.

Em vez de tratar os 'blobs' como uma camada de dados auxiliar, a proposta move os dados principais do 'payload' de execução — já codificados no formato RLP padrão da Ethereum — para os próprios 'blobs'.

Os validadores verificariam então os compromissos criptográficos para esses 'blobs' e, com o tempo, contariam com a amostragem de disponibilidade de dados. Desta forma, podem verificar pequenas porções de dados para garantir que o conjunto de dados completo existe sem o descarregar por completo.

A mudança torna-se particularmente relevante num futuro onde os sistemas zkEVM lidam com a verificação de execução.

Provas de conhecimento zero ('zero-knowledge proofs') podem confirmar que as transações foram processadas corretamente, eliminando a necessidade de os validadores reexecutarem cada transação.

No entanto, essas provas por si só não garantem que os dados da transação estejam realmente disponíveis. "Sob zkEVM, os validadores verificam provas, não transações diretamente", escreveu Wahrstatter. Ele também observou que, sem um mecanismo separado, os dados poderiam ser retidos, embora ainda passassem nas verificações de consenso.

O 'Block-in-Blobs' foi projetado para fechar essa lacuna, argumenta a proposta.

Ao incorporar dados de transação em 'blobs' com compromissos criptográficos, a proposta torna a disponibilidade de dados explícita em vez de implícita, permitindo que os validadores amostrem dados em vez de os descarregarem na íntegra, preservando as garantias de segurança.

Existem também implicações mais amplas para como a Ethereum contabiliza os dados.

Hoje, a Ethereum ainda separa o 'gas' de execução do uso de dados de 'blob'. Sob o novo modelo, ambos poderiam ser unificados num único sistema de "data gas". Se implementado com sucesso, os pesquisadores dizem que isso alinharia os custos em todas as formas de disponibilidade de dados e evitaria limites sobrepostos.

ERC-8211 da Biconomy

Separadamente, estão em andamento esforços para melhorar a forma como as próprias transações são estruturadas e executadas.

A Biconomy, em colaboração com a área de UX da Ethereum Foundation, propôs a ERC-8211, um padrão que transforma transações em fluxos de trabalho programáveis.

Em vez de parâmetros fixos definidos na assinatura, a ERC-8211 permite que as transações busquem dados 'onchain' em tempo real, validem condições e executem múltiplas etapas em sequência com uma única assinatura. O objetivo é reduzir transações falhas e permitir interações mais complexas e impulsionadas por agentes em protocolos DeFi, conforme explicado no 'thread' da Biconomy no X.

Ambos os desenvolvimentos inserem-se numa onda mais ampla de experimentação em todo o ecossistema da Ethereum. Os pesquisadores delinearam caminhos de atualização plurianuais até ao final da década, após o lançamento do 'hard-fork' duplo do ano passado.