MEV-Boost, o protocolo sidecar atual para extração de MEV no Ethereum, depende muito de atores centralizados chamados de retransmissões.

Propomos uma arquitetura alternativa que permite a comunicação direta, criptograficamente privada entre construtores e proponentes. Baseia-se em uma forma inovadora e não interativa de criptografia de limiar "silenciosa" que pode usar os pares de chaves BLS existentes dos validadores.

Essencialmente, nós pegamos carona no comitê de atestação para privacidade e disponibilidade de dados, criptografando propostas de bloco por limiar para uma fração de atestadores para o slot. Suas atestações formam a chave de descriptografia; uma vez que o limiar desejado atestou, o bloco pode ser descriptografado.

Nossa construção aborda a privacidade entre construtores e proponentes, mas não garante sozinha a validade do bloco. Ela pode ser combinada com outros mecanismos para replicar plenamente as funcionalidades fornecidas pelos retransmissores - tanto a privacidade quanto a validade do bloco. Por exemplo, esquemas de prova como provas do Ambiente de Execução Confiável (TEE) ou provas de Conhecimento Zero (ZK), ou mecanismos criptoeconômicos para colateralizar os construtores.

Ao remover a necessidade de retransmissões para fornecer privacidade ao construtor e garantir a validade do bloco, visamos reduzir a latência e melhorar a descentralização e a resistência à censura do Ethereum.

MEV-Boost e o Papel das Retransmissões

MEV-Boost é um protocolo de sidecar que intermedia entre os construtores de blocos e proponentes. papel principalO objetivo da retransmissão é fornecer duas garantias:

• Privacidade para construtores: O relay garante que os proponentes não possam ver o conteúdo do bloco e roubar o MEV encontrado pelo construtor.
• Segurança para proponentes: A retransmissão garante que o construtor pague o valor prometido ao proponente no lance do construtor e que o bloco seja válido (por exemplo, todas as transações pagam gás intrínseco).

No entanto, a dependência de retransmissões introduz uma centralização significativa. Aproximadamente 90% dos blocos no Ethereum são entregues através de apenas algumas retransmissões. Isso apresenta alguns riscos:

• Centralização: Os construtores podem ser eficientes em termos de latência ao se colocar com retransmissões em vez de refletir a distribuição geográfica dos proponentes. Isso mina diretamente a descentralização geográfica e a resistência à censura que obteríamos de um conjunto de validadores grande e globalmente distribuído.
• Receita: A latência média de processamento de bloco de ponta a ponta de retransmissões eficientes é de cerca de 5-20 milissegundos. Em seguida, há latência de comunicação entre o proponente e o construtor. Pular as retransmissões reduzirá a latência, diminuirá os riscos de execução entre domínios (por exemplo, CEX/DEX) e, em última instância, aumentará as recompensas MEV dos proponentes.

TEE-Boost

Uma das principais propostas para substituir os relés é "TEE-Boost“, que se baseia em TEEs (Ambientes de Execução Confiáveis). Note que os TEEs não são essenciais para o nosso esquema; é apenas útil usar o TEE-Boost como um exemplo pedagógico dos problemas que pretendemos resolver.

Concretamente, o TEE-Boost faz com que os construtores usem TEEs para criar provas que demonstrem aos proponentes a honestidade de suas propostas e a validade de seus blocos sem revelar o conteúdo real dos blocos aos proponentes. Os proponentes podem verificar essas provas sem executar TEEs em hardware de commodities.

No entanto, o TEE-Boost tem um problema de disponibilidade de dados: os construtores apenas compartilham provas TEE e cabeçalhos de bloco com os proponentes, não o conteúdo real do bloco,^[1] e pode optar por não divulgar o conteúdo do bloco mesmo depois que o proponente assina o cabeçalho (por exemplo, se as condições de mercado mudarem desfavoravelmente). As abordagens sugeridas para resolver esse problema de DA são:

• [ ] TEE-Escrow: Um TEE-escrow recebe o bloco do construtor antes do proponente assiná-lo e o libera assim que veem o cabeçalho assinado.
• [ ] Camadas de Disponibilidade de Dados: Os construtores postam cargas de bloco criptografadas em uma camada de Disponibilidade de Dados (DA).

Ambas as abordagens têm desvantagens. A solução de garantia TEE replica dinâmicas de latência de centralização semelhantes às dos relés existentes.^[2]O uso de uma camada DA externa introduz uma suposição extra-protocolo e suporta a dinâmica de latência desse protocolo externo (que também é provavelmente desfavorável).

1. Teoricamente, se os proponentes também tivessem acesso a TEEs, os construtores poderiam criptografar seus blocos para uma execução TEE realizada pelo proponente. A TEE do proponente somente descriptografaria o bloco depois que o tivesse assinado. No entanto, acreditamos que o TEE-Boost não considera esse design porque exigiria que os proponentes (validadores) executassem TEEs. Queremos que os validadores possam executar em hardware comum.↩

2. A dinâmica de latência pode ser evitada se os proponentes executarem o TEE-Escrow como um sidecar localizado ao lado de seu nó validador. No entanto, novamente, não queremos fazer com que os validadores executem TEEs.↩

Criptografia de Limiar para Alcançar Privacidade do Construtor

Propomos uma solução elegante para o problema DA do TEE-Boost: criptografia de limiar para o comitê de atestadores. Especificamente, o construtor criptografa o bloco para uma fração especificada do comitê de atestadores para esse slot. Uma vez que são reunidas testemunhas suficientes, o bloco se torna descriptografável e disponível.

A tecnologia habilitadora central é Criptografia de Limiar Silencioso. Esta técnica criptográfica permite a criptografia de limiar sem exigir uma fase de configuração interativa de geração de chaves distribuídas (DKG), que construções anteriores exigiam. Em vez disso, a chave pública conjunta é calculada deterministicamente a partir das chaves públicas BLS já existentes do atestante mais alguns 'indicadores' (discutidos posteriormente).

Isso permite uma comunicação direta de um salto entre o construtor e o validador com privacidade criptográfica. Os validadores não são obrigados a executar TEEs por si mesmos ou gerenciar qualquer material de chave novo.

Mecânica:

O construtor constrói um bloco e o criptografa para o comitê do atestante.

O construtor constrói uma prova TEE demonstrando três coisas ao comitê atestador: que o lance é honesto, o bloco é válido e está criptografado corretamente.

O construtor comunica o bloco criptografado de limite e a prova TEE (que inclui o valor do lance) ao proponente.^[3]

O proponente assina o bloco criptografado do construtor vencedor e propaga esta proposta para o conjunto de validadores.

Uma vez que a fração especificada (por exemplo, n/2 ou 2n/3) do comitê de atestantes n para o slot atesta o bloco, ele é descriptografado.

O bloco descriptografado prossegue normalmente para a finalização.

1. O efeito nos requisitos de largura de banda do proponente precisaria ser estudado. Os proponentes de baixa largura de banda podem limitar as necessidades verificando as provas antes de solicitar o corpo do bloco, ou com outras técnicas de filtragem heurística e download inteligente. Esta é uma questão em aberto, mas parece provavelmente não mais difícil de resolver do que problemas normais de spam no mempool.↩

Considerações

Desempenho

As características de desempenho da Criptografia de Limiar Silencioso são bastante favoráveis. Aqui

n é o tamanho máximo do comitê que desejamos apoiar e t é o limite para a decodificação.

A criptografia e a descriptografia parcial são de tempo constante. Com uma implementação ingênua, a criptografia leva <7 ms - e isso pode ser paralelizado. A descriptografia parcial leva <1 ms.

O tamanho do texto cifrado é um fator aditivo constante, 768 bytes, maior do que o texto claro (para qualquer n e t).

A agregação das descriptografias parciais (ou seja, descriptografia) depende do tamanho do comitê. Com n=1024, uma implementação ingênua leva <200ms. Esperamos que com n=128 (o tamanho do comitê de atestação para cada slot), isso diminuirá por um fator de 10 e que a implementação possa ser ainda mais otimizada.

Importante, o tempo de criptografia é o número-chave de desempenho a ser comparado com a latência de retransmissão. Isso é o que o construtor deve calcular no "caminho crítico" da produção de blocos. É menor do que a latência de processamento de blocos da retransmissão existente e evita a comunicação multi-hop.

Publicação de Dados

A Criptografia de Limiar Silencioso não é completamente livre. Ela requer uma sequência de referência comum na forma: (g, g)^τ,g^τ2,…,g^τn−t), similar to what’s used for the KZG polynomial commitment scheme.

Além disso, todo validador com uma chave pública BLS da forma gsk publica um conjunto de elementos de grupo que chamamos de "dicas": (g^sk⋅τ,…,g^sk⋅τn−t). Essas dicas são necessárias apenas para retransmitir chaves públicas e descriptografar textos cifrados. A criptografia usa apenas uma chave pública agregaGate de tamanho constante.

Ao escrever esta postagem, existem aproximadamente 1 milhão de validadores. Se definirmos n=128 e t=n/2, cada validador precisará postar ≈ 3 KB de dicas. Assim, armazenar as dicas de todos os validadores requer 3 GB.

Esta exigência provavelmente diminuirá substancialmente com a ativação do MaxEB, que permite aos validadores que controlam >32 ETH manter saldos maiores sob o mesmo par de chaves (em vez de dividi-los em vários depósitos de 32 ETH). A redução no conjunto de validadores que será realizada está em debate. Parece possível que possamos chegar a ~1GB.

Por último, dependendo de futuras alterações na arquitetura de consenso do Ethereum (por exemplo, reduções adicionais no tamanho do conjunto de validadores ou canalização alternativa de finalidade), o tamanho das dicas que devem ser armazenadas pode diminuir ainda mais.

Vitalidade

Ethereum quer permanecer ativo mesmo em condições adversas de rede. Um problema com esse esquema é a possibilidade de blocos que não podem ser descriptografados porque a fração especificada do comitê está offline.

Uma solução é permitir que o construtor decida a fração aceitável (𝑡) do comitê para descriptografia. Há um equilíbrio entre privacidade (a possibilidade de desmembramento e roubo de MEV) e a probabilidade do limiar do comitê estar online. É maximização de receita para os construtores terem seus blocos incluídos, em vez de serem bifurcados, então eles devem descobrir uma configuração de limiar otimizada.^[4]

Além disso, o uso deste esquema de criptografia deve ser opcional. Em condições de rede adversas, nas quais nenhum comitê de tamanho aceitável está disponível com qualquer consistência, os proponentes e construtores podem recorrer ao uso de retransmissões, autoconstrução ou qualquer outro mecanismo que seja preferível dada a natureza do ambiente adverso.

1. A alegação específica aqui é que é EV negativo para o bloco de um construtor ser bifurcado (eles não recebem receita com isso), e EV altamente negativo para ser desagregado. Se você der ao construtor a capacidade de escolher t em [0,128], ele deve ser naturalmente incentivado a selecionar t alto o suficiente para que haja um risco muito baixo de separação e alta probabilidade de ser satisfeito (pelo menos t membros do comitê estando on-line). Alguns blocos provavelmente seriam bifurcados mesmo em condições normais de rede, mas notamos que isso já acontece com jogos de cronometragem, e a vida da cadeia permanece aceitável. ↩

Blocos Indisponíveis

Alternativamente, o comitê pode estar online, mas um construtor pode ser capaz de criar uma situação na qual o bloco não pode ser descriptografado ou inválido após a descriptografia (por exemplo, com provas fraudulentas).

Do ponto de vista do protocolo, é aceitável bifurcar esses blocos. O conjunto de validadores mais amplo simplesmente não pode atestar a eles ou a quaisquer blocos que os referenciem. A melhor maneira de lidar com esse tipo de erro provavelmente é tornar o cliente de consenso ciente da possibilidade e capaz de falhar de maneira elegante. Seria necessário um estudo adicional sobre como exatamente fazer isso.

Estrutura de Mercado

O construtor vencedor conhece o conteúdo do bloco antes dos outros até que o limite seja atingido, o que poderia criar uma vantagem injusta nos slots subsequentes. No entanto, o comitê de testemunhas deve agir antes do final do próximo slot, e a maioria do valor do bloco está no final do slot, então os efeitos dessa vantagem devem ser o mais minimizados possível.

Provas puramente criptográficas

A longo prazo, pode ser possível substituir as provas TEE por provas de conhecimento zero (ZK). Atualmente, as provas ZK são muito lentas, mas avanços em criptografia, software e hardware especializado (ASICs) podem eventualmente tornar a geração de provas ZK viável dentro das restrições de latência necessárias. É importante notar que as provas de ZK que acompanham os blocos já são parte central do roteiro de longo prazo da Ethereum.

Adoção

Com o tamanho atual do conjunto de validadores e a taxa de crescimento, este esquema pode não valer a quantidade de dados necessária para ser publicada no L1. No entanto, o Ethereum já planeja reduzir substancialmente a contagem do conjunto de validadores com MaxEB.

A melhor abordagem provavelmente seria uma atualização ao lado ou após o MaxEB, na qual os clientes de consenso são informados da possibilidade de semântica de bloco criptografado e os validadores são incentivados a publicar dicas. Por exemplo, após o MaxEB, poderia ser exigido que os validadores recém-ingressados publiquem dicas, e os validadores mais antigos poderiam receber um incentivo para atualizar.

Os construtores começariam a usar o mecanismo assim que uma fração suficiente do conjunto de validadores o adotasse para ter tamanhos de comitê suficientes (ou seja, privacidade aceitável e probabilidade de decifração).

Se a nossa abordagem de fato tiver latência favorável em relação à retransmissão de vários saltos, o mercado deve adotá-la sem a necessidade de o protocolo impor o uso ou consagrar uma parametrização específica.

Justificativa

As relays são uma das fontes mais significativas de centralização do Ethereum, criando oportunidades para busca de aluguel e distorcendo a descentralização geográfica do protocolo.

Precisamos remover as retransmissões e achamos que esta é uma maneira relativamente elegante de fazer isso. Isso requer mudanças na camada de consenso, mas nenhum novo hardware ou material de chave é necessário por parte dos validadores.

A desvantagem é que é uma mudança complexa para a camada de consenso de um mecanismo que (se optativo, como sugerido) pode ou não ser adotado pelo mercado. No entanto, muitas mudanças potenciais no pipeline de MEV trazem questões semelhantes de adoção e otimização de receita (por exemplo, listas de inclusão). E pode haver outros casos de uso futuros que dependam do conjunto de validadores ter infraestrutura de criptografia de limite disponível.

Aviso Legal：

1. Este artigo é reeditado a partir de [paradigma]. Todos os direitos autorais pertencem ao autor original [Charlie NoyesGuru, Vamsi Policharla]. Se houver objeções a esta reedição, entre em contato com o Gate Learnequipe e eles lidarão com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.