Introdução ao Hard Fork do Ethereum Pectra

Por NIC Lin, Médio

O hard fork do Pectra está previsto para iniciar a implantação na mainnet em março de 2025. A atualização do Pectra inclui 11 protocolos técnicos (EIPs), que são:

• EIP-2537: Pré-compilação de operações de curva BLS12-381
• EIP-2935: Manter o valor do hash do bloco histórico no Estado
• EIP-6110: Fornecer depósitos de validador on-chain
• EIP-7002: Execução de Camada Dispara Saída
• EIP-7251: Adicionar o MAX_EFFECTIVE_BALANCE
• EIP-7549: Mover o índice do comitê para fora da validação
• EIP-7623: Aumentar o custo de calldata
• EIP-7685: Solicitação de camada de execução comum
• EIP-7691: Aumentar o throughput do Blob
• EIP-7702: Configurar o código da conta EOA
• EIP-7840: Adicionar plano Blob ao ficheiro de configuração EL

Acordos Técnicos Relacionados com Staking

EIP-6110: Pré-compilação de operações de curva BLS12-381

Simplificar o processo de participação do usuário no staking para reduzir significativamente o tempo de espera.

A forma como os utilizadores participam no staking é depositando 32 ETH na camada de execução e sendo registado no registo de eventos (Event Log). Em seguida, a camada de consenso analisa o registo de eventos para determinar se alguém participou no staking, e os utilizadores que participam no staking tornam-se validadores.

No entanto, os validadores da camada de consenso primeiro precisam depositar consenso em relação a qual ponto do tempo, caso contrário, descobrirão que alguns validadores veem 5 novos depósitos, enquanto outros validadores veem apenas 3, portanto, os validadores da camada de consenso votarão em qual bloco da camada de execução (eth1data) deve ser referenciado, garantindo que todos vejam o mesmo bloco da camada de execução.

No entanto, inicialmente, ao evitar erros graves na camada de execução que possam levar a bifurcações na cadeia, o bloco de dados de execução de referência (eth1data) será um bloco de execução de cerca de 10 horas atrás, garantindo assim que os desenvolvedores da camada de consenso tenham tempo suficiente para reagir e lidar com erros graves quando ocorrerem, mas isso também significa que a participação no staking só será efetiva após mais de 10 horas.

△ CL O eth1data em 10900000 blocos, o Block Hash registrado nele é o bloco de camada de execução 21683339, apareceu nas últimas 10 horas.

Após a implementação do protocolo técnico EIP-6110, os dados de garantia do usuário no contrato inteligente se tornarão diretamente parte da camada de execução, e como os blocos da camada de execução estarão incluídos nos blocos da camada de consenso (mas não eth1data), os validadores da camada de consenso não precisarão mais considerar a questão de ‘confirmar se os blocos de memória da camada de execução a serem referenciados são os mesmos’, desde que os blocos de memória da camada de consenso obtenham confirmação de voto de mais de dois terços dos validadores, todos concordarão que estão vendo o mesmo bloco de execução. Portanto, após participar da garantia, os dados de garantia podem entrar em vigor assim que os blocos de memória da camada de execução forem processados, o que pode levar cerca de 13 minutos, e os clientes da camada de consenso podem eliminar a lógica complexa originalmente usada para lidar com os dados de garantia.

EIP-7002: Salvando hashes de bloco histórico no estado

Capaz de melhorar o processo de saída e retirada de depósitos e ganhos do validador, reduzindo o risco do validador.

Para participar do staking, você precisa de duas chaves, que são a Chave do Validador e a Credencial de Retirada.

A Chave do Validador é usada para o conteúdo de trabalho do validador, e a Credencial de Retirada é usada para o endereço onde o depósito e os ganhos serão retirados quando o validador se retirar do staking.

Se você perder a Chave do Validador, não poderá realizar o trabalho de validação e não poderá retirar o seu depósito; se perder o Certificado de Retirada, perderá todo o depósito e ganhos. Além disso, alguns usuários podem utilizar serviços de depósito de terceiros, como o Lido, ao usar essas plataformas, os usuários precisam manter o Certificado de Retirada por conta própria, enquanto a Chave do Validador é mantida e usada pelo provedor de serviços para realizar o trabalho de validação.

Ao implementar o protocolo técnico EIP-7002, os utilizadores podem invocar o contrato “Withdraw” (implantado em 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) com o seu Próprio Credencial de Retirada para sair da aposta (Sair) ou levantar a aposta e os lucros (Retirada Parcial), reduzindo assim os potenciais riscos associados ao uso de serviços de aposta de terceiros. Se um utilizador participar na aposta por conta própria mas perder a Chave do Validador, também poderá sair da aposta através deste método.

• Os parâmetros da solicitação incluem validator_pubkey e amount: validator_pubkey é a chave pública do validador, amount é a quantidade a ser retirada.
• O Withdrawal Credential do solicitante deve ser o Withdrawal Credential do validador validator_pubkey.
• Ao chamar o contrato de retirada para fazer um pedido, é necessário incluir a taxa de gás (ETH). A taxa de gás será calculada com base no número atual de pedidos de retirada. Se houver muitos pedidos, a taxa de gás aumentará.
• Se o Credential de Retirada do usuário for um contrato, você pode primeiro ir ao contrato de Retirada para obter a quantia atual da taxa de transação e então enviar a solicitação com a taxa de transação. No entanto, se o Credential de Retirada for uma conta EOA, não será possível obter a taxa de transação precisa, apenas simular offline antecipadamente e pagar uma taxa de transação excedente (não será reembolsada) para garantir que a solicitação seja bem-sucedida.

*Nota: Se a sua Credencial de Levantamento ainda estiver no formato de chave pública BLS, lembre-se de mudar primeiro para o formato de endereço EL. *

EIP-7251: Adicionar o MAX_EFFECTIVE_BALANCE

Capaz de aumentar significativamente o limite de garantia para reduzir o número de validadores, e os validadores que não atingirem o limite podem automaticamente desfrutar dos rendimentos da garantia.

Os validadores que participam da aposta de usuários devem fornecer a quantidade de ETH MAX_EFFECTIVE_BALANCE, não menos nem mais (atualmente MAX_EFFECTIVE_BALANCE é 32 ETH). Se um usuário possui 1024 ETH para apostar, pode participar da aposta 32 vezes, ativar 32 validadores e executar 32 nós validadores. O grande número de participantes ativos na aposta resultou em cerca de 1 milhão de validadores atuais e continua a aumentar. Isso não só torna os dados de estado da camada de consenso maiores, mas também aumenta significativamente a carga na camada de rede p2p da camada de consenso, porque a assinatura de dezenas de milhares de validadores deve ser continuamente transmitida e agregada na camada de rede p2p a cada Slot (a cada 12 segundos).

Após a implementação do protocolo técnico EIP-7251, o limite de depósito (MIN_ACTIVATION_BALANCE) permanece em 32 ETH, mas o limite superior (MAX_EFFECTIVE_BALANCE) será significativamente aumentado para 2048 ETH. Você pode depositar qualquer quantidade de ETH entre 32 e 2048 e obter receitas de depósito sem a necessidade de retirá-las regularmente. Depois de acumular 32 ETH, você pode continuar com um novo depósito.

Atualmente, os validadores existentes não precisam sair da aposta antes de se unirem para apostar novamente. Eles podem usar diretamente o ‘contrato de depósito combinado’ (implementado em 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) na camada de execução, e os validadores podem chamar o contrato para solicitar a combinação de depósitos usando as credenciais de retirada.

• Os parâmetros da solicitação de fusão de depósitos incluem source_pubkey e target_pubkey: ambas as chaves são a Chave do Validador do validador, o validador de origem será fundido no validador de destino.
• O Credential de Retirada que faz a solicitação deve ser o Credential de Retirada do verificador de origem.
• Ao solicitar a fusão do contrato de depósito, é necessário anexar uma taxa (ETH), que será calculada com base no número atual de solicitações. Se houver muitas solicitações, a taxa aumentará.
• Se a Credencial de Retirada do usuário for um contrato, então você pode ligar para o contrato de depósito de mesclagem para obter o valor da taxa atual e, em seguida, iniciar uma solicitação e anexar a taxa; No entanto, se a Credencial de Levantamento for uma conta EOA, não há forma de obter uma taxa precisa, pelo que só pode simular a taxa off-chain antecipadamente e pagar a taxa em excesso (que não será reembolsada) para garantir que o pedido será executado com sucesso.

Nota: Se a sua credencial de levantamento estiver no formato de chave pública BLS, primeiro terá de mudar para o formato de endereço EL.

EIP-7685: Pedido de Camada de Execução Genérica

Estabeleça um pipeline de informações CL EL-> formal para que os usuários e os serviços de staking possam enviar solicitações diretamente para a camada de consenso.

Os usuários podem enviar solicitações diretamente da camada de execução para a camada de consenso, e os serviços de staking (como o Lido) podem operar de maneira mais descentralizada. Os exemplos incluem o pedido de desparticipação do EIP-7002 e o pedido do EIP-7251 para fundir depósitos. Sem esse protocolo técnico, os usuários do Lido teriam que confiar no provedor de serviços do nó Lido para executar o depósito de unstaking ou mesclagem na camada de consenso. Com este protocolo técnico, os utilizadores do Lido podem enviar pedidos diretamente através do contrato de governação na camada de execução.

Esses pedidos serão diferenciados pelo tipo de pedido Request Type e pelo lançamento de pedidos através de contratos diferentes, e no final, esses pedidos serão escritos no bloco de memória da camada de execução, permitindo assim que a camada de consenso obtenha diretamente essas informações através do bloco de memória de execução, sem a necessidade de escrever lógica de análise separada.

EIP-6110, EIP-7002 e EIP-7251 são todos padronizados pela EIP-7685 para formular solicitações:

• EIP-6110 adicionar pedido de stake: Tipo de pedido=0, através do contrato de depósito

(0x00000000219ab540356cbb839cbe05303d7705fa) Iniciar um pedido.

• Pedido de retirada de EIP-7002: Tipo de pedido=1, através do contrato de Retirada

(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) Iniciar um pedido.

• Pedido de consolidação de depósitos EIP-7251: Tipo de pedido=2, através do contrato de consolidação

(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) Iniciar um pedido.

Protocolo técnico para melhorar a experiência de utilização

EIP-7702: Definir o código da conta EOA

Permite que a conta EOA se transforme em qualquer conta de contrato inteligente, melhorando significativamente a experiência de uso.

Existem algumas insuficiências na utilização das contas EOA, nomeadamente:

• É necessário gravar e manter a chave privada ou frase mnemônica, e o limite para o registro de novos usuários é alto.
• Uma conta EOA só pode realizar uma operação por transação, por exemplo, se você quiser ir para Uniswap para trocar USDT por ETH, você deve primeiro iniciar uma transação para aprovar USDT, e então você pode enviar outra transação para executar a troca.
• Controlo de permissões não é passível de ser submetido a uma análise mais detalhada, como delegar certas operações da conta a terceiros para serem executadas. O utilizador deve lidar pessoalmente com todos os assuntos e assinar cada transação.
• Não há mecanismo de recuperação, então você só pode manter a chave privada ou frase mnemônica por si mesmo, e se você perdê-la, você nunca será capaz de recuperar os ativos da conta.

Se for uma conta de contrato inteligente (por exemplo, Safe), todos os problemas acima podem ser resolvidos:

• Os usuários podem assinar e autorizar com a chave privada dentro do chip de segurança do telefone (ou computador), sem precisar lembrar de nenhuma chave privada ou frase de recuperação, ou também podem assinar e autorizar por e-mail, ou por outras formas de autorização diversas.
• Vários operações podem ser agrupadas em lote e executadas juntas em uma única transação, as operações complicadas do DApp original podem ser concluídas com apenas uma autorização de assinatura, uma transação.
• Pode haver um controle de permissões muito refinado, onde os usuários podem autorizar terceiros a controlar suas contas, mas ao mesmo tempo especificar ‘com quais contratos podem interagir’, ‘quais operações não podem ser executadas’, ‘quanto de ativos pode ser usado no máximo em transferências de ativos’ ou ‘quantas operações podem ser executadas no máximo a cada semana’, etc.
• Pode adicionar um mecanismo de recuperação para transferir ativos de uma conta para uma nova conta em caso de perda de palavras-chave, telefone ou email.

A proposta EIP-7702 é capacitar uma conta EOA a se transformar em uma conta de contrato. O usuário assina a mensagem de transformação com a chave privada EOA, e o conteúdo da assinatura inclui “ID de cadeia”,“endereço de contrato transformado” e “valor de Nonce EOA”:

• ID da cadeia: Usado para impedir que a assinatura da cadeia A seja repetida pela cadeia B. No entanto, se o ID da cadeia estiver definido como 0, significa que você está disposto a se transformar em cada cadeia.
• O endereço do contrato que você deseja se tornar: Se você preencher um endereço de contrato seguro, sua conta EOA se tornará um contrato seguro; Se preencher o endereço em branco (endereço(0)), significa que pretende cancelar a alteração e voltar a uma conta EOA pura.
• Valor do Nonce do EOA: usado para evitar a repetição da assinatura. Se o valor do Nonce aumentar, a assinatura original se tornará inválida.

No entanto, há algumas coisas a observar:

1. A chave privada EOA pode continuar a ser utilizada

Mesmo que a conta EOA do utilizador se torne um contrato, ele ainda pode continuar a usá-la da mesma forma que a conta EOA original. A sua conta, por exemplo, se a sua conta EOA se tornar um contrato seguro, então pode usar a interface segura, seguir o processo de transação segura e ainda usar a carteira EOA original para assinar e enviar transações. No entanto, isso também significa que a segurança da conta ainda está limitada à chave privada.

2. Continua a ser a segurança da chave privada EOA

Mesmo que o EOA do usuário se torne um multi-assinado, contanto que ele não tenha perdido a chave privada do EOA, a segurança de sua conta sempre será a segurança da chave privada do EOA: ele ainda precisa manter sua chave privada ou frase de recuperação segura, sua conta não se tornará tão segura quanto um multi-assinado.

3. O armazenamento da conta EOA não será formatado

Quando uma conta EOA se transforma em um contrato e grava dados em seu armazenamento, a menos que os dados sejam explicitamente excluídos, os dados gravados no armazenamento não serão formatados porque a conta EOA se transforma em outro contrato ou cancela a transformação, portanto, os desenvolvedores devem ter cuidado para não ler os dados deixados pelo contrato de transformação anterior, você pode consultar ERC-7201.

4. O processo EIP-7702 não inclui inicialização

Normalmente, um contrato de conta exigirá uma etapa de inicialização, que escreve sincronamente as informações do proprietário da conta (como chave pública ou endereço) durante a implantação da conta, a fim de evitar que a etapa de implantação seja antecipada (Frontrun) e resulte na perda do direito de propriedade da conta. Isso geralmente é feito pelo contrato de fábrica que implanta e inicializa a conta, mas, devido ao EIP-7702, a mudança é direta e não é realizada por uma fábrica para implantar o contrato no EOA, permitindo assim que um atacante copie a assinatura de metamorfose do usuário e envie a transação para a cadeia antes, transformando a conta em uma que o atacante pode controlar. Portanto, os desenvolvedores precisam estar cientes do EIP-7702. Possíveis medidas preventivas incluem verificar a assinatura da conta EOA dentro da função de inicialização, para que mesmo que seja antecipada, o atacante não consiga gerar a assinatura da conta EOA para concluir a inicialização.

5. Pedidos de alteração do gatekeeper da carteira

A carteira precisa proteger os usuários, interceptando e alertando os usuários quando um site malicioso de DApp solicita a assinatura de uma transação de alteração de identidade, caso contrário, se o usuário assinar uma transação maliciosa de alteração de identidade, os ativos serão transferidos instantaneamente. Aqui estão alguns exemplos de implementação de contratos de alteração de identidade:

• Conta Ithaca Segura Modificada
• Conta Ithaca

Protocolo Técnico DApp

EIP-2537: Pré-compilador de operação de curva BLS12-381

Reduza o custo e torne-o mais viável para aplicações à prova de conhecimento zero baseadas na curva BLS.

O EIP-2537 adiciona vários novos contratos de pré-compilação para fornecer operações de curva BLS baratas, tornando mais viável desenvolver aplicações à prova de conhecimento zero com base em curvas BLS.

EIP-2935: Salvar hashes de blocos históricos no Estado

Ele permite que os desenvolvedores ou nós leiam o hash de bloco de blocos de memória anteriores diretamente do armazenamento do contrato do sistema.

Se um desenvolvedor precisar provar o conteúdo de um bloco de memória anterior, por exemplo, se precisar provar que 1000 blocos de memória anteriores existem em uma transação específica durante um desafio de fraude do Optimismtic Rollup, o desafiante não pode simplesmente afirmar isso.

“Por favor, acredite em mim, há realmente esta transação antes de 1000 blocos de memória.” Ele deve apresentar provas, mas não há uma prova direta que possa provar diretamente que “os conteúdos estão incluídos nos 1000 blocos de memória anteriores”. Portanto, ele deve provar de bloco de memória em bloco de memória, até alcançar 1000 blocos de memória anteriores, e então provar que a transação existe neste bloco de memória.

!

△ Cada bloco aponta para um bloco pai, para que você possa provar qualquer bloco no histórico todo o caminho de volta.

Suppose the current memory block is numbered 10000, and the fraudulent challenge must provide the proof of the existence of a transaction X with memory block number 9000, then the challenger needs to start from the hash value of memory block 10000, first prove the hash value of the parent memory block 9999 connected to memory block 10000, and then prove memory block 9998… until memory block 9000, and finally present that the content of memory block 9000 includes transaction X.

Após o EIP-2935, haverá um contrato de sistema (implantado em 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC) que armazenará os hashes de até 8192 blocos de memória anteriores. Toda vez que um novo bloco de memória é gerado, o contrato do sistema será atualizado automaticamente para gravar o hash do bloco anterior no contrato do sistema (o hash dos blocos de memória anteriores 8192 será reescrito).

Desta forma, no exemplo do desafio de fraude do Optimismtic Rollup, o desafiante não precisa voltar ao bloco de memória anterior para provar um bloco de memória de cada vez, mas pode provar diretamente que, no estado atual da cadeia do bloco de memória 10000, o valor de um determinado armazenamento (correspondente ao bloco de memória 9000) do contrato do sistema é o valor de hash do bloco de memória 9000. Se o intervalo exceder 8192, como o bloco de memória 1000, então, no máximo, é mais uma etapa para provar o valor de hash do bloco de memória 1808 (= 10000 - 8192) e, em seguida, provar o valor de hash do bloco de memória 1000 no contrato do sistema no estado atual da cadeia do bloco de memória 1808.

Isso também abre caminho para um futuro cliente sem monitoração de estado: no futuro, os nós leves não precisarão mais armazenar os cabeçalhos de bloco de todos os blocos de memória históricos, mas só precisarão pedir a outra pessoa para fornecer provas usando o método de prova no exemplo de desafio de fraude anterior quando for necessário usar o hash de um bloco de memória no histórico ou o conteúdo do bloco de memória.

EIP-7623: : Increase calldata cost

Aumente o custo de publicação de dados com calldata para criar espaço seguro suficiente para aumentar o Limite de Gás de Bloco e o Limite de Blob.

Com a crescente demanda de publicação de dados do Rollup, a introdução do Blob no EIP-4844 para permitir que o Rollup armazene dados de forma muito barata, o aumento da quantidade de Blob tem sido uma atualização esperada pela comunidade, semelhante ao recente aumento do Limite de Gás do Bloco impulsionado pela comunidade, refletindo a necessidade do ecossistema de aumentar os recursos.

△ Cada vez mais validadores têm manifestado apoio ao aumento do Limite de Gás de Bloco.

No entanto, aumentar o Limite de Gás de Bloco ou o número de blobs colocará mais pressão na rede p2p do Ethereum à medida que a quantidade de dados transacionados se torna maior, o que tornará os invasores mais eficientes, a menos que o custo de publicação de dados aumente.

Depois que o protocolo EIP-7623 for lançado, o custo dos dados de chamada será aumentado em 2,5 vezes do original “Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas” para “Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas”.

Originalmente, se um invasor usasse todo o Block Gas Limit (30M) para colocar dados de lixo, o tamanho dos dados do bloco de memória seria de cerca de 1,79 MB (30M / 16), em comparação com o tamanho médio do bloco de memória de apenas cerca de 100 KB. Se o limite de gás de bloco for aumentado para 40M, um invasor pode gerar um bloco de memória de cerca de 2,38 MB. Quando o custo dos dados de chamada é aumentado em 2,5x, a eficiência do atacante será reduzida para um máximo de 0,72 MB para 30 M e 0,95 MB para 40 M, para que o Limite de Gás de Bloco e o Blob possam ser aumentados com mais confiança. No entanto, este protocolo técnico não quer afetar o utilizador geral que “não utiliza dados de chamada para publicar dados”, pelo que irá calcular a utilização total de gás da transação de duas formas, consoante a que for mais elevada:

1. O método original de cálculo do uso de gás da transação é calculado com o custo de calldata antigo: ou seja, os calldata são calculados na forma de “Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas”, e o gás consumido pela execução da transação e o gás consumido pelo contrato de implantação são adicionados.
2. Basta calcular a quantidade de gás calldata, mas usar o novo custo para calcular: ou seja, o calldata é calculado na forma de “Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas”, mas não inclui o gás consumido pela execução ou o gás consumido pela implantação do contrato, portanto, para os usuários que geralmente “não usam calldata para publicar dados” (como ir ao Uniswap para trocar), é o Gás principal O consumo é a parte da execução, e mesmo que os dados de chamada sejam calculados a um novo custo, ele não excederá o gás consumido pela execução, portanto, os usuários em geral não serão afetados.

O impacto real será em rollups menores, porque os blobs são de tamanho fixo e taxas fixas, então pequenos rollups são ineficientes para usar blobs, e é mais econômico usar dados de chamada, mas após o EIP-7623, o custo desses pequenos rollups aumentará em 2,5 vezes, e eles podem ter que mudar para o uso de blobs ou encontrar uma maneira de unir forças para compartilhar um blob.

EIP-7691: Aumentar o throughput de Blob

• Aumente o número de blobs e adicione mais espaço para publicação de dados para rollups. *

O EIP-7691 aumenta o número de blobs de “Destino: 3 Blobs, Máx: 6 Blobs” para “Destino: 6 Blobs, Máx: 9 Blobs” para aumentar o espaço para publicar mais dados em rollups.

Nota: Além disso, o mercado de taxas de Blob tem alguns designs que precisam de ajustes, como a velocidade de ajuste da taxa não sendo instantânea e o limite mínimo da taxa sendo muito baixo, mas isso não é um problema a ser resolvido neste protocolo técnico.

Outros Acordos Técnicos

EIP-7549: Mover índice do comitê fora da validação

Ajuste o conteúdo da votação do validador para facilitar a agregação de votos e reduzir a pressão sobre a rede P2P.

Os validadores são atribuídos aleatoriamente a um grupo de comitês e pares para cada época

Votação de blocos de memória, os votos dos validadores de cada comitê podem ser agregados, reduzindo assim a quantidade de votos transmitidos na rede p2p, mas os votos dos validadores conterão informações sobre ‘a qual comitê o validador pertence’, o que impede que os votos de diferentes comitês sejam agregados, mesmo que todos estejam votando no mesmo bloco de memória.

O EIP-7549 remove a informação de que o validador pertence ao primeiro comitê do conteúdo da votação, para que validadores de diferentes comitês possam ser agregados quando o conteúdo da votação é o mesmo, reduzindo ainda mais o número de votos aprovados na rede P2P e reduzindo a pressão sobre a rede P2P.

EIP-7840: Adicionar plano de Blob ao perfil EL

Estabelecer um perfil para o parâmetro Blob na camada de execução, poupando os nós da camada de execução do incômodo de consultar os parâmetros relacionados ao Blob nos nós da camada de consenso.

Os parâmetros relacionados a blob são atualmente armazenados nos nós da camada de consenso, mas os nós da camada de execução ainda precisam desses parâmetros em alguns casos (por exemplo, RPC eth_feeHistory), portanto, eles devem perguntar aos nós da camada de consenso.

O EIP-7840 cria um arquivo de configuração para parâmetros relacionados a blob na camada de execução, e os nós na camada de execução podem ler diretamente parâmetros relacionados a blob por meio desse arquivo de configuração sem ter que perguntar aos nós da camada de consenso.