Análise de prós e contras dos proponentes de múltiplas concorrências (MCP)

Autor: Maven11; Tradução: 金色财经xiaozou

Os Proponentes Concorrentes Múltiplos (Multiple Concurrent Proposers, doravante MCP) referem-se a um mecanismo que permite que vários proponentes estejam ativos ao mesmo tempo (é importante não confundi-los com o Protocolo de Múltiplos Contextos ou Computação Segura em Múltiplas Partes, embora exista de fato alguma semelhança entre eles), sendo uma solução inovadora para o problema da censura. Este artigo irá explorar por que é fundamental que vários, em vez de um único, proponente sejam responsáveis pela proposta de blocos, incluindo seu funcionamento e significado na implementação.

Embora o conceito central da MCP seja relativamente fácil de entender, atualmente quase não há adoção prática desse mecanismo no blockchain. No entanto, de certa forma, o modelo de operação das pools de mineração do Bitcoin apresenta semelhanças com os proponentes concorrentes múltiplos - qualquer pessoa que execute um nó completo do Bitcoin pode fazer com que as transações sejam incluídas na blockchain.

Por outro lado, o mecanismo de construção multiconcorrente de Solana tem algumas coisas em comum com a implementação de um MCP completo, pelo menos refletindo a ideia de vários participantes diferentes participando da construção de blocos (mas não da proposta de bloco). No Ethereum, cerca de 95% dos blocos são construídos através do MEV-Boost. Embora existam vários construtores ativos ao mesmo tempo, só pode haver um vencedor por leilão, de modo que a vantagem que Solana alcança através de vários construtores simultâneos não se sustenta aqui. Na verdade, atualmente não existe uma cadeia que permita que vários proponentes tenham o direito de propor blocos a qualquer momento.

A maneira mais intuitiva de entender o MCP é dividi-lo em duas camadas: vários proponentes fornecendo blocos simultaneamente e a fusão final desses subconjuntos de blocos.

Esses grupos de proponentes provavelmente serão sub-conselhos (semelhantes aos mecanismos existentes do Ethereum), pois não é prático ter todos os validadores envolvidos. Isto significa também que é importante assegurar que os subcomités individuais não sejam monopolizados por uma reserva de participações, caso contrário poderão surgir questões de censura e conluio. Além disso, é importante notar que os lendários stakers domésticos muitas vezes têm capacidades técnicas limitadas - MCP aumentará significativamente a complexidade do sistema.

As seguintes são as principais vantagens do MCP que merecem ser adotadas:

Razões para suportar múltiplos proponentes concorrentes:

--Aumentar a resistência à censura (particularmente importante sob os atuais constrangimentos)

--Expandir a nível do protocolo base em vez de depender de soluções externas

--Dispersão de MEV (não mais decidido por um único proponente ou construtor sobre como agrupar as transações)

Problemas que a implementação do MCP exporá diretamente:

--A competição pelo ordenamento das transações (embalagem e sequência) intensifica-se (pode levar ao surgimento do fenômeno PGA?)

--Desafios simulados resultantes de transações inválidas

--Aumento dos requisitos de hardware

--Problemas de disponibilidade de dados de transações inválidas

--é necessário introduzir ferramentas de finalização

Vamos analisar essas características item por item, começando pelos benefícios e depois avaliando se os potenciais problemas podem constituir obstáculos à implementação de blockchains públicas com uma carga técnica mais pesada.

1、As Vantagens do MCP

(1) Aumentar a resistência à censura

Atualmente, a maioria das blockchains que adotam mecanismos de finalização determinística depende de um único líder para decidir o conteúdo do bloco (com algumas variações sutis). Após a transmissão do bloco, a maioria dos validadores chega a um consenso e o incorpora na cadeia padrão. O Ethereum acelera a criação de blocos através de um mecanismo de subcomitê (mas o consenso completo do conjunto de validadores leva mais tempo). No âmbito do quadro MCP, múltiplos proponentes constroem blocos locais e, por fim, os fundem, o que significa que a entrada do bloco passa de um único agente (proponente/construtor/retratador, idealmente o MCP deveria abolir esses papéis) para um modo de múltiplos canais. Isso aumenta consideravelmente a dificuldade de censura. Quando existem múltiplos agentes de empacotamento, a resistência do sistema à censura será significativamente reforçada.

No centro do gargalo atual (note que equipes como a Flashbots estão melhorando o status quo) é que um único construtor recebe direitos de construção de blocos de um único proponente por meio de um leilão, e a recamada (confiável) à medida que o leiloeiro exacerba ainda mais a centralização. Embora o protocolo principal do Ethereum seja descentralizado, o processo de transação on-chain existente não é. Solana também está enfrentando a centralização de relés Jito / construtores e está tentando resolvê-lo com uma solução de re-staking (o primeiro re-staking de rendimento real "AVS"!). ）。 Os usuários do Bitcoin podem resolver o problema de forma autônoma (a um custo menor) executando um nó completo, mas isso vem às custas da finalidade – o Bitcoin usa a finalidade probabilística e não tem as "ferramentas de finalidade" necessárias para implementar o MCP, que depende da regra da cadeia mais longa.

(2) Expansão no nível do protocolo básico

Muitas vezes, muito desenvolvimento é terceirizado para equipes de terceiros para corrigir as falhas de design inerentes do L1 (não limitado ao Ethereum) para resolver os principais problemas de protocolo. Implementar o MCP significa lidar diretamente com problemas que, de outra forma, seriam resolvidos/causados por soluções fora da cadeia. Isso aumenta os requisitos de hardware (enquanto aumenta a resistência à censura), o que pode ser uma troca válida dependendo da necessidade de descentralização pelos usuários do protocolo. Solana, em particular, provavelmente usará essa abordagem para abordar a centralização de Jito. Além disso, como o esforço de construção de blocos é distribuído para várias partes, a demanda geral de largura de banda da rede acabará aumentando.

(3) Dispersar MEV

O efeito mais original do MCP é que ele muda o modelo original de "loteria MEV", permitindo que o MEV de um determinado bloco seja compartilhado entre vários proponentes ativos (em vez de monopolizado por um único proponente ou construtor). Os validadores (principalmente entidades empresariais) preferem um fluxo constante de receitas, e este mecanismo também é eficaz para evitar a exploração unilateral do MEV (status quo) através do rearranjo das transações. Esta característica tem um efeito sinérgico com o objetivo resistente à censura.

Nota: Se você já leu nossos artigos anteriores, pode estar familiarizado com o termo Teorema CAP: são três características básicas que um sistema distribuído deve satisfazer para operar normalmente.

C： representa a consistência (consistency), ou seja, a experiência do usuário deve permanecer uniforme entre todos os usuários, devendo sentir-se como se estivesse a interagir com uma única base de dados sempre que utiliza o sistema.

A： representa a disponibilidade (availability), ou seja, o que frequentemente chamamos de vivacidade (liveness), refere-se a todas as mensagens que precisam ser processadas pelos nós do sistema e refletidas nos blocos/consultas subsequentes, todas as instruções devem ser executadas.

P： representa a tolerância a partições (partition tolerance, ou resistência à censura), o que significa que o sistema deve manter a consistência e a disponibilidade mesmo quando sofre ataques ou quando há uma divisão na rede de nós.

MCP é uma das melhores maneiras de implementar os elementos-chave do teorema CAP (especialmente a resistência à censura) — esses elementos são frequentemente simplificados como problemas de teoria dos jogos. Lembre-se: deve-se confiar no protocolo em si, e não na teoria dos jogos.

No entanto, com as vantagens vem um custo, e a operação do teorema da PAC mostra que grandes conquistas sempre vêm com defeitos correspondentes – é quase impossível levar todas as características em conta. Vejamos, então, as questões que podem surgir com a implementação do MCP.

2、Problemas que o MCP precisa resolver

O principal problema é que o MCP, até certo ponto, pode levar a uma fase de competição dupla dentro do bloco. Primeiro, há a taxa de empacotamento de transações, e em segundo lugar, a taxa de ordenação. O tratamento da taxa de ordenação é especialmente complicado, pois na primeira fase, os produtores locais apenas têm uma visão de bloco local e não uma visão global. Isso significa que calcular com precisão a melhor oferta para uma posição específica no bloco é uma tarefa árdua.

Isto não só é difícil de operar, como o mais importante é que (sob o mecanismo de leilão) isso nos fará voltar à era do leilão prioritário de Gas (PGA). Embora a resistência à censura seja mais garantida, essencialmente revive os problemas que o MEV-Boost tentava resolver - a mediana das altas taxas de Gas em blocos competitivos, a precificação exclusiva na fase de empacotamento, entre outros fenômenos.

Além dos problemas de classificação, incluindo visões locais versus globais, há outros desafios relacionados a transações. Isso se refere especificamente ao problema causado por transações inválidas durante a propagação da visão local-global do bloco. Considerando que é impossível prever o impacto das mudanças de estado nas transações de outros proponentes no início da fase (antes que os subblocos sejam fundidos em blocos coconstruídos por vários proponentes), pode haver casos em que os proponentes passam transações inválidas entre si (o problema é exacerbado se essas transações forem carregadas na cadeia como conteúdo de disponibilidade de dados). Também é possível que um validador no conjunto MCP atual viole um limite de parâmetros (por exemplo, quebrando o valor máximo do gás). Embora isso possa ser resolvido introduzindo um árbitro (ou regra interna de protocolo) que possa filtrar transações de baixo preço com a mesma mudança de estado por taxa após a divulgação da disponibilidade de dados, isso nos leva de volta ao dilema PGA resolvido. No entanto, não usar mecanismos como leilões para dar aos buscadores/construtores controle sobre os locais dos blocos levaria a uma enxurrada de transações de spam e pioraria a latência do jogo – o que prejudicaria a possibilidade de preconfs. Ethereum (após a atualização do Pectra) e Solana têm considerações adicionais: a proposta 7702 do Ethereum faz com que as transações não sejam mais invalidadas devido a nonces, e Solana não tem nenhuma transação nonce (conta nonce ainda existe). Isso torna muito mais difícil julgar a validade de uma transação – essencialmente simulando todas as combinações para determinar o pedido correto, o que pode colocar uma enorme pressão na largura de banda da rede. Solana pode ser mais fácil de lidar com sua alta barreira de hardware à entrada, mas o Ethereum sem dúvida precisará de uma atualização de hardware. No entanto, a solução potencial do Ethereum é que o cliente de execução (não o construtor + repetidor) realmente calcule o pedido durante a fase de mesclagem de subblocos – reafirmando a necessidade de uma atualização de hardware.

Em termos de disponibilidade de dados (DA), como mencionado anteriormente, outra questão importante é que essas transações inválidas podem ser vazadas on-chain (essencialmente se tornando transações gratuitas). Isso agrava ainda mais a carga de cálculo de simulação mencionada na fase de pré-consenso - embora você possa filtrar transações inválidas durante a fase de mesclagem. Algumas das implementações existentes do FOCIL (endereço de envio em vez de transação completa) podem ser reutilizadas (a menos que dependam apenas da validação da simulação, mas a intervenção humana em vez das regras do protocolo pode interferir no processo de simulação invalidando outras transações).

Como mencionado anteriormente, a implementação do MCP provavelmente exigirá a adoção de ferramentas de finalização para lidar com problemas de sincronização - como também foi sugerido na parte de simulação de ordenação anterior ao consenso. Isso também levantará questões de jogos de tempo em relação ao adiamento da proposta de blocos (fenômenos desse tipo já são visíveis nos leilões MEV-Boost), cujos efeitos incluem: o proponente pode observar outros blocos antes de construir seu próprio bloco, enviando deliberadamente transações que invalidam as transações de outros (particularmente vantajoso para os buscadores). Se regras de combate ao jogo de tempo forem muito rigorosas, isso poderá resultar na eliminação de validadores com desempenho inferior (o que implica mais casos de perda de blocos).

As possíveis soluções para enfrentar a batalha temporal podem se basear em medidas de melhoria de cadeias como a Monad, que utiliza um mecanismo de execução assíncrona (execução com atraso). Por exemplo, podem ser estabelecidas regras: o conjunto de transações de todos os proponentes ativos em um único período deve ser completo e só pode ser determinado após a construção de todo o conjunto. Isso limita significativamente a capacidade de throughput, uma vez que a probabilidade de múltiplos proponentes conterem transações idênticas é alta. A execução com atraso também significa que, mesmo que uma transação esteja "inclusa" em um sub-bloco, ainda pode não conseguir entrar no bloco final agregado, resultando em transações "inclusas mas revertidas" (o que se relaciona com o problema de dupla inclusão mencionado no início). É importante notar que isso pode exigir ferramentas de finalização específicas para executar tais operações (incluindo execução, propagação e confirmação final de blocos).

Embora estejamos a focar principalmente no Ethereum, vale a pena notar que a Solana está a avançar ativamente com o MCP. Com a chegada de Max Resnick à Anza e a declaração pública de Anatoly a apoiar a implementação, esta tendência torna-se cada vez mais clara. O artigo recente de Anatoly menciona os seguintes pontos-chave:

--O que fazer se os blocos de diferentes validadores chegarem em momentos diferentes (isso também pode ser uma disputa temporal)

--Como fundir transações (já discutido anteriormente)

--Como alocar a capacidade do bloco (limite máximo de Gas) entre validadores para maximizar a largura de banda

--Problema de desperdício de recursos (a mesma transação sendo incluída em vários sub-blocos, este problema foi mencionado anteriormente)

Os numerosos problemas associados à implementação do MCP na Solana geralmente refletem os problemas enfrentados pela Ethereum. No entanto, a Solana enfatiza mais a largura de banda e a otimização do desempenho, o que significa que, ao garantir a robustez do consenso, a gestão dos recursos do bloco e a fusão dos blocos tornam-se mais importantes.

Outro ponto-chave que mencionamos no início do artigo é que o MCP não só pode reforçar o protocolo, mas também pode ser usado para expandir o protocolo. Ele pode até integrar a serialização específica de aplicativos (ASS) na camada do protocolo através de um mecanismo de ordenação. No futuro, pode surgir um cenário onde não é mais o proponente da transação XYZ, mas sim o próprio aplicativo atuando como proponente, ordenando o conjunto de transações de acordo com suas próprias necessidades (este é exatamente o objetivo do projeto Delta) - ou, inversamente, o aplicativo fornece as regras de ordenação das transações ao proponente. Vale a pena notar que soluções que combinam a transferência do imposto MEV para a parte do aplicativo (iniciador da transação) com o MCP também estão sendo exploradas (uma vez que não é mais controlado por um único proponente, a implementação será mais simples).

Em um post recente, Max e Anatoly argumentaram que o MCP poderia alcançar spreads de compra e venda mais estreitos aplicando serialização dedicada (conceito NASDAQ descentralizado). No ambiente atual, como mencionado anteriormente, apenas um único líder pode propor blocos. Isto significa que, quando o preço flutua, a parte cotante no livro de ordens tentará reverter determinadas cotações. No modelo de proponente único de Solana, isso só pode ser feito através de leilões Jito devido ao monopólio do proponente sobre o poder. Idealmente, como mostra a Hyperliquid, as solicitações de estorno devem ser priorizadas para permitir que os criadores de mercado mantenham spreads mais baixos. Portanto, espera-se que isso seja alcançado através da ASS como uma aplicação - eles têm o monopólio do poder de leilão sob o modelo de líder único, e esse monopólio pode ser eliminado com a adoção do MPC. No entanto, é provável que essa solução ASS seja limitada a cenários de isolamento de estado. A essência da proposta é permitir que os desenvolvedores de aplicativos definam ações prioritárias (por exemplo, cancelamentos de pedidos) para contas específicas e priorizem as transações de maior prioridade (não necessariamente as transações de gorjeta mais alta, mas a força vital da liquidez) para contas específicas. A ideia central é definir um limite de taxa para negociações regulares, permitindo que certas negociações prioritárias ultrapassem o limite.

O problema das taxas de empacotamento e das taxas de ordenação discutido anteriormente parece ter uma solução no Solana. As taxas de empacotamento vão para os validadores de transações, enquanto as taxas de ordenação são pagas ao protocolo (destruição). Quando vários sub-blocos são mesclados, basta ordenar e executar o conjunto de transações mescladas de acordo com a taxa de ordenação predefinida.

O mecanismo acima funciona em estreita colaboração com o mecanismo de propagação de blocos Turbine da Solana. Os Líderes (MCP) usam fragmentos de dados (shreds) e os enviam para os nós de retransmissão na estrutura em árvore do Turbine — esses nós de retransmissão devem conter fragmentos de todos os líderes. Os nós de retransmissão enviam informações de confirmação de fragmentos a um único líder de consenso, que deve coletar uma quantidade suficiente de mensagens fragmentadas antes de transmitir e alcançar consenso.

Com o lançamento do Alpenglow, e considerando o cancelamento da arquitetura de nós de retransmissão de camada única e do mecanismo de votação on-chain (agora totalmente on-chain), a implementação específica pode ser ajustada. Essas mudanças têm o potencial de reduzir os custos operacionais dos validadores, aumentando assim o número de validadores e atraindo participantes com habilidades técnicas mais fracas. Isso é certamente benéfico para a descentralização, mas pode afetar o desempenho da cadeia. Vale a pena discutir como eles lidarão com o problema de falhas de validadores após a implementação do MCP na Solana.

**3、**Práticas de MCP em outros ecossistemas

O ecossistema Cosmos também está promovendo a implementação do MCP, e a conhecida instituição Informal Systems acaba de lançar uma especificação de múltiplos proponentes sob o modelo de consenso BFT. Eles utilizam um protocolo de difusão segura, exigindo que cada sub-bloco de um validador obtenha a confirmação de outros validadores através de um mecanismo de votação expansivo. O módulo de construção de blocos Tendermint/CometBFT, em seguida, alcança consenso sobre esse conjunto de sub-blocos, o que significa que validadores específicos gerarão um grande número de sub-blocos.

A Sei está desenvolvendo o MCP (com o objetivo de ser o primeiro projeto a ser implementado) através do projeto Sei Giga, que é parcialmente inspirado no artigo Autobahn (altamente recomendado). A ideia central é dissociar a disponibilidade de dados da classificação, acelerar a disponibilidade de dados por meio de vários canais paralelos e, finalmente, classificar para a cadeia global. Isso é um pouco diferente do conceito MCP do Ethereum, onde os validadores não sincronizam blocos por um período fixo de tempo, mas continuam a produzir blocos e mesclá-los em uma visão global.

Patrick O'Grady da Commonware também está explorando soluções relacionadas.

Por fim, o projeto Delta projetou uma camada subjacente que combina a funcionalidade de um mural resistente à censura, enquanto cada aplicativo executa seu próprio ordenamento concorrente, com os blocos gerados sendo finalmente liquidadas na camada de estado global.