MEV-Boost, o protocolo sidecar atual para extração de MEV no Ethereum, depende muito de atores centralizados chamados relés.

Propomos uma arquitetura alternativa que permite a comunicação direta e criptograficamente privada entre construtores e proponentes. É baseada em uma forma nova e não interativa de criptografia de limiar 'silenciosa' que pode usar os pares de chaves BLS existentes dos validadores.

Essencialmente, aproveitamos o comitê de atestação para privacidade e disponibilidade de dados, criptografando propostas de bloco com limite para uma fração de atestadores para o slot. Suas atestações formam a chave de descriptografia; uma vez que o limite desejado tenha sido atestado, o bloco pode ser descriptografado.

A nossa construção aborda a privacidade entre construtores e proponentes, mas não garante sozinha a validade do bloco. Pode ser combinada com outros mecanismos para replicar completamente as funcionalidades fornecidas por relés - tanto a privacidade quanto a validade do bloco. Por exemplo, esquemas de prova como Provas de Ambiente de Execução Confiável (TEE) ou Provas de Conhecimento Zero (ZK), ou mecanismos criptoeconómicos para colateralizar construtores.

Ao eliminar a necessidade de relés para fornecer privacidade ao construtor e garantir a validade do bloco, pretendemos reduzir a latência e melhorar a descentralização e a resistência à censura do Ethereum.

MEV-Boost e o Papel dos Relés

MEV-Boost é um protocolo auxiliar que intermedia entre construtores de blocos e proponentes. O papel principalO objetivo do relé é fornecer duas garantias:

• Privacidade para Construtores: O relé garante que os proponentes não consigam ver o conteúdo do bloco e roubar o MEV encontrado pelo construtor.
• Segurança para Proponentes: O relé 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).

A dependência de relés, no entanto, introduz uma centralização significativa. Aproximadamente 90% dos blocos no Ethereum são entregues através de apenas alguns poucos relés. Isso coloca alguns riscos:

• Centralização: Os construtores podem ser eficientes em termos de latência ao se co-localizarem com relés em vez de refletirem a distribuição geográfica dos proponentes. Isso mina diretamente a descentralização geográfica e a resistência à censura que de outra forma 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 relés eficientes é de cerca de 5 a 20 milissegundos. Em seguida, há a latência de comunicação entre o proponente e o construtor. Pular relés reduzirá a latência, diminuirá os riscos de execução entre domínios (por exemplo, CEX / DEX) e, em última análise, aumentará as recompensas de MEV dos proponentes.

TEE-Boost

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

Concretamente, o TEE-Boost permite aos construtores utilizar TEEs para criar provas que demonstram aos proponentes a honestidade das suas propostas e a validade dos seus blocos sem revelar o conteúdo real dos blocos aos proponentes. Os proponentes podem verificar estas provas sem executar os TEEs por si próprios em hardware convencional.

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

• [ ] TEE-Escrow: Um TEE-escrow obtém o bloco do construtor antes que o proponente o assine e o libera quando vêem o cabeçalho assinado.
• [ ] Camadas de disponibilidade de dados: os construtores publicam cargas de bloco criptografadas em uma camada de disponibilidade de dados (DA).

Ambas as abordagens têm desvantagens. A solução de caução TEE replica a dinâmica de latência de centralização semelhante à dos relés existentes.^[2]Usar 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 um TEE executado pelo proponente. O TEE do proponente só descriptografaria o bloco depois de assiná-lo. No entanto, achamos que o TEE-Boost não considera esse design porque exigiria que os proponentes (validadores) executem TEEs. Queremos que os validadores possam ser executados em hardware comum.↩

2. A dinâmica da latência pode ser evitada se os proponentes próprios executarem o TEE-Escrow como um sidecar colocado ao lado do seu nó validador. No entanto, mais uma vez, não queremos 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 bastantes atestações são reunidas, o bloco torna-se 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 Distribuída de Chaves (DKG), que construções anteriores requeriam. Em vez disso, a chave pública conjunta é calculada de forma determinística a partir das chaves públicas BLS já existentes do atestante mais alguns "sugestões" (discutidas posteriormente).

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

Mecânica:

O construtor constrói um bloco e o encripta para o comité do atestante.

O construtor constrói uma prova de TEE demonstrando três coisas ao comité do atestador: que a proposta é honesta, o bloco é válido e está encriptado corretamente.

O construtor comunica o bloco criptografado do limiar e a prova TEE (que inclui o valor da oferta) 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 atestação n-atestador para o slot atesta o bloco, ele é descriptografado.

O bloco descriptografado prossegue para finalização normalmente.

1. O efeito nos requisitos de largura de banda do proponente precisaria ser estudado. 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 ser mais difícil de resolver do que os problemas normais de spam de gossip de 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 limiar para desencriptação.

Tanto a criptografia como 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 simples (para qualquer n e t).

A agregação das desencriptações parciais (ou seja, desencriptação) 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 para comparar com a latência do relé. É isso que o construtor deve calcular no 'caminho crítico' da produção de bloco. É menor que a latência de processamento de bloco do relé existente e evita comunicação multi-salto.

Publicação de Dados

A Criptografia do Limiar Silencioso não é totalmente gratuita. Ela requer uma sequência de referência comum no formato: (g,g^τ,g^τ2,…,g^τn−t), semelhante ao que é usado para o esquema de compromisso polinomial KZG.

Além disso, cada 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). Estas dicas são apenas necessárias para aggreGatar chaves públicas e para decifrar textos cifrados. A encriptação apenas utiliza uma chave pública aggreGada de tamanho constante.

Ao escrever este post, existem aproximadamente 1 milhão de validadores. Se definirmos n=128 e t=n/2, cada validador precisa de publicar ≈ 3 KB de pistas. Assim, armazenar as pistas de todos os validadores requer 3 GB.

Este requisito provavelmente diminuirá substancialmente com oativação do MaxEB, que permite aos validadores que controlam >32 ETH manter saldos maiores sob a mesma chave privada (em vez de dividir 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 mudanças futuras na arquitetura de consenso do Ethereum (por exemplo, reduções adicionais no tamanho do conjunto de validadores ou encaminhamento de finalidade alternativa), o tamanho das dicas que devem ser armazenadas pode diminuir ainda mais.

Vivacidade

O Ethereum quer permanecer ativo mesmo em condições de rede adversas. 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. Existe um equilíbrio entre a privacidade (a possibilidade de desagregação e roubo de MEV) e a probabilidade do limite do comitê estar online. É maximizador de receita para os construtores terem seus blocos incluídos, em vez de serem bifurcados, então eles devem descobrir uma configuração de limite otimizada.^[4]

Além disso, o uso desse esquema de criptografia deve ser opcional. Em condições adversas de rede, nas quais não há um comitê de tamanho aceitável disponível de forma consistente, os proponentes e construtores podem recorrer a relés, construção automática ou qualquer outro mecanismo preferível, considerando a natureza do ambiente adverso.

1. A reivindicação específica aqui é que é EV negativo para um bloco do construtor ser bifurcado (eles não recebem receita dele), e altamente EV negativo para ser desagregado. Se você der ao construtor a capacidade de escolher t em [0,128], eles devem ser naturalmente incentivados a selecionar t alto o suficiente para haver um risco muito baixo de desagregação e alta probabilidade de satisfação (pelo menos t membros do comitê estarem online). Alguns blocos provavelmente seriam bifurcados mesmo em condições normais de rede, mas observamos que isso já acontece com jogos de tempo, e a vivacidade da cadeia continua aceitável.↩

Blocos Indisponíveis

Alternativamente, o comitê pode estar online, mas um construtor pode ser capaz de criar uma situação em que 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, está tudo bem bifurcar esses blocos. O conjunto mais amplo de validadores simplesmente não poderia atestar a eles ou a quaisquer blocos que os referenciam. A melhor maneira de lidar com esse tipo de erro provavelmente é fazer com que o cliente de consenso esteja ciente da possibilidade e capaz de falhar de forma graciosa. Seria necessário estudar mais sobre exatamente como lidar com isso.

Estrutura do 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 atestadores 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 mínimo possível.

Provas Puramente Criptográficas

No longo prazo, pode ser possível substituir as provas TEE por provas de Conhecimento Zero (ZK). Atualmente, as provas ZK são demasiado lentas, mas os 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. É de salientar que as provas ZK que acompanham os blocos já são um parte central da rota estratégica de longo prazo do Ethereum.

Adoção

Com o tamanho atual do conjunto de validadores e a taxa de crescimento, esse esquema pode não valer a quantidade de dados necessários para serem publicados na L1. No entanto, a Ethereum já planeja reduzir substancialmente a contagem do conjunto de validadores com o MaxEB.

A melhor abordagem provavelmente seria uma atualização juntamente com ou após 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 pistas. Por exemplo, após MaxEB, poderia ser exigido que os novos validadores publiquem pistas, e os validadores mais antigos poderiam ter 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, tanto privacidade aceitável quanto probabilidade de descriptografia).

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

Justificativa

Os relés são uma das fontes mais significativas de centralização do Ethereum, criando oportunidades para busca de aluguel e distorção da descentralização geográfica do protocolo.

Precisamos remover relés e achamos que esta é uma maneira relativamente elegante de fazê-lo. Isso requer alterações no nível de consenso, mas não é necessário novo hardware ou material de chave por parte dos validadores.

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

Aviso legal:

1. Este artigo é reproduzido a partir de [paradigma]. Todos os direitos autorais pertencem ao autor original [Charlie NoyesGuru, Vamsi Policharla]. If there are objections to this reprint, please contact the Gate Aprenderequipa e eles vão tratar disso prontamente.
2. Isenção de Responsabilidade: Os pontos de vista e opiniões expressos 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 equipa Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.