Este artigo irá apresentar a funcionalidade de "Privacidade Programável" que fornece transações mais avançadas e um design de mercado MEV mais aberto e justo - SUAVE. Antes de entrar no tópico principal de explicação do SUAVE, por favor, entenda primeiro o conceito de Intenção.

Intenção

Experiência atual usando transações de blockchain

Tomando as transações Ethereum como exemplo, assumindo que um usuário queira trocar seu USDT por ETH, ele pode ir à página da web Uniswap para verificar o preço, e depois de definir o deslize de preço permitido, assinar e enviar a transação, e depois esperar pelo resultado da transação.

A transação dele provavelmente parecerá com isto: "Eu assino e envio esta transação, com um valor de Nonce de 23 e uma taxa de gás de 30 Gwei. Irá executar o contrato Uniswap para trocar os meus 1000 USDT por 0,5 ETH, com uma derrapagem máxima de 1%."

△ Nonce? Gwei? Fonte da imagem:https://www.reddit.com/r/MemeRestoration/comments/ejcvd3/confused_math_lady_4080x2663px

Suponhamos que Alice seja uma utilizadora novata e que ela apenas queira trocar o seu USDT por ETH, mas ela tem que ultrapassar muitos obstáculos para concretizar este pequeno desejo:

• O primeiro passo é encontrar o canal de troca. Suponhamos que ela pesquisa no Google e encontra a página Uniswap (pelo menos existe um menu claro de ativos digitais e um botão de troca), e depois precisa de compreender e definir a derrapagem (ou usar o predefinido).
• Após clicar no botão Trocar, a tela de assinatura da transação aparece, que contém o Nonce e Gwei da taxa de processamento.
• Finalmente ela envia a transação, mas provavelmente nada acontece e a Alice só pode esperar confusa e rezar para que a transação seja executada com sucesso.

Cada nível é uma questão que os utilizadores novatos na realidade não precisam de compreender, mas são obrigados a fazer uma escolha: Onde resgatar? Quer definir um deslize? Que percentagem deve ser definida para o deslize? Quer ajustar a taxa de gás (taxa de processamento)? A que Gwei precisa de ser ajustada? Por que falhou a transação? Por que é que a transação ficou presa durante tanto tempo (talvez seja um problema com o Nonce ou a taxa de processamento)? O que devo fazer?

Experiência de uso de transações de intenção

Ao contrário da Transação, que requer a especificação de vários detalhes de uma transação, a Intenção apenas requer que o utilizador especifique os resultados que pretende alcançar e as condições de execução, deixando o resto para pessoas mais profissionais.

Na Intent, Alice especificou que 1000 USDT devem ser trocados por 0,5 ETH, mas considerando a taxa de processamento, o preço foi ajustado para 0,495 ETH e depois o pedido foi assinado e enviado. A transação de Alice terá este aspeto: "Assino e envio este pedido. Quero trocar 1000 USDT por 0,495 ETH. Este pedido é válido desde que eu possa obter 0,495 ETH."

É muito simples, certo? Esta é a experiência de usar uma ordem de limite (Limit Order), e é também a experiência geral de usar Agregadores DEX (como 1inch e Tokenlon).

△ A diferença entre Transação (topo) e Intenção (fundo). Com a Intenção, os utilizadores apenas precisam de especificar as condições e não precisam de se preocupar com como as alcançar. Legenda:https://www.paradigm.xyz/2023/06/intents

Através da Intenção, os utilizadores já não precisam lidar e preocupar-se com vários detalhes tediosos e confusos entre a geração, assinatura e execução de transações. Eles nem sequer precisam de resolver o problema e continuar a tentar quando uma transação falha. Além disso, diferentes cadeias terão processos e armadilhas de transação diferentes!

Através do Intent, o usuário só precisa especificar as condições de execução e os resultados esperados do seu Intent. O resto é para o Solver profissional realizar o Intent do usuário - como enviar transações, monitorar transações, acelerar transações, etc. Lidando com questões problemáticas, como falha na transação, e o Intent só pode ser implementado quando as condições de execução e os resultados esperados são atendidos, para que os usuários não precisem se preocupar se um acidente causará o desaparecimento dos ativos.

A intenção irá melhorar grandemente a experiência da blockchain.

Dica de leitura 1: Na verdade, já existem muitos exemplos de uso de Intenção, como a assinatura de uma carteira multi-assinatura, o conceito de Chave de Sessão que concede a terceiros permissões de execução específicas e limites de tempo, ou um mecanismo de transação de correspondência em lote como o CowSwap. Mesmo no mundo Web2, existem vestígios de Intenção, como motores de busca (eu introduzo o que quero pesquisar, e o motor de busca encontra informações relevantes para mim através de vários canais) ou compras online em e-commerce (eu introduzo o que quero comprar), a empresa de e-commerce encontrou através de vários canais e entregou para mim). Apenas a palavra Intenção se tornou popular recentemente no mundo Web3.

Dica de leitura 2: Em inglês, a palavra Imperativo ('imperativo') é usada para descrever a experiência de usar Transação, que é emitir um comando completo para completar o objetivo; enquanto a palavra 'Declarativo' ('Declaração') é usada para descrever a experiência de usar Intenção. Descritivo, indicando que é usado ao declarar condições de execução e resultados de execução.

Intenção no mundo das cadeias cruzadas

Em aplicações cross-chain como pontes cross-chain e DEX cross-chain, porque estão envolvidas duas ou mais cadeias, os utilizadores têm de lidar com mais transações em cadeias diferentes.

Excluindo aplicações entre cadeias através da multi-assinatura do partido do projeto, pode proporcionar uma melhor experiência ao usuário (por exemplo, depois que o usuário envia uma transação na cadeia de origem, a multi-assinatura do partido do projeto enviará automaticamente os ativos para o usuário na cadeia de destino) O endereço especificado não requer que o usuário realize quaisquer operações na cadeia de destino). Outras aplicações entre cadeias mais descentralizadas como Nomad e Succinct não têm uma experiência tão boa. Os usuários podem precisar enviar transações para a cadeia de destino para completar a operação.

Portanto, a melhoria da experiência do utilizador que a Intent pode trazer é ainda mais importante e urgente no mundo das cadeias cruzadas.

Através do Intent, as operações cross-chain apenas exigirão que os utilizadores assinem, e já não precisarão de se preocupar com as regras e detalhes da transação de cada blockchain. Os utilizadores serão capazes de operar em diferentes blockchains com a mesma experiência do utilizador, e nem sequer perceberão o facto de existirem blockchains diferentes.

ELEGANTE

O nome completo da SUAVE é Single Unifying Auction for Value Expression, o objetivo é se tornar um mercado MEV unificado em várias cadeias. Neste mercado, os usuários podem expressar as condições de fechamento e recompensas de uma transação de forma eficiente. Ao mesmo tempo, os executores (Executores) competirão entre si e cooperarão de forma eficiente para completar as solicitações do usuário.

SUAVE pode servir como um pool de transações para uma blockchain e também atuar como um papel de Construtor responsável por produzir o conteúdo do bloco dessa blockchain. No entanto, SUAVE não se destina a substituir o pool de transações existente e a funcionalidade de Construtor de uma blockchain, mas sim a conectar-se de forma contínua a uma blockchain existente de forma plug and play.

Após o SUAVE ser conectado a uma blockchain, a blockchain equivale a ter um Construtor descentralizado, muito profissional e poderoso que abrange múltiplas fontes de transações blockchain. Ter múltiplas fontes de transação blockchain ao mesmo tempo proporcionará enormes vantagens no mercado MEV entre domínios que gradualmente crescerá no futuro. Construtores com esta vantagem serão mais competitivos do que construtores que operam em apenas uma cadeia.

Do Flashbot ao MEV-Boost ao SUAVE

Do Flashbot ao MEV-Boost, o espírito que eles defendem é o de reconhecer a existência do MEV e esforçar-se por trazer as atividades econômicas ocultas para o primeiro plano. Eles pretendem estabelecer um mercado público onde qualquer pessoa possa participar, a fim de evitar o cenário em que alguns indivíduos controlam e dominam silenciosamente este imenso interesse econômico, levando gradualmente à concentração de recursos em suas mãos e impactando, em última análise, a descentralização e a segurança de toda a rede blockchain.

Mas à medida que as pessoas aprendem mais e mais sobre MEV, elas gradualmente percebem que, além do mercado de MEV maduro na Ethereum, também existem mercados MEV entre cadeias e transfronteiriços. Este mercado MEV transfronteiriço será muito maior do que o da Ethereum, e as transações entre cadeias terão mais oportunidades de extrair MEV do que as transações na mesma cadeia.

Se não houvesse alguém como o Flashbot para expor o mercado MEV entre cadeias, trazê-lo à luz e permitir uma participação justa para todos, os poucos indivíduos que exploram o MEV entre cadeias teriam ainda mais vantagem, afetando assim a segurança de toda a rede blockchain.

Outro fenómeno que afetará a centralização e a segurança é o Fluxo de Ordem Privado: as transações dos utilizadores já não fluem para o pool de transações públicas, mas diretamente para o Pesquisador ou Construtor. O Fluxo de Ordem Privado pode advir do Pesquisador ou Construtor adquirindo o direito de ganhar rendimento a partir das transações dos utilizadores, ou o Construtor fornecendo serviços atrativos, como (1) cancelamento gratuito de transações ou ordens DEX enviadas pelos utilizadores, ou (2) fornecendo Pré-Confirmação, antes da transação ser recebida, o utilizador tem a garantia de quão rapidamente a transação será recebida, para que o utilizador não precise de se preocupar se a transação será recebida e quanto tempo demorará a ser recebida.

Embora o Fluxo de Ordens Privadas possa inicialmente beneficiar os utilizadores, a longo prazo, resultará em centralização. Os Pesquisadores/Construtores com Fluxo de Ordem Privada terão uma vantagem competitiva e obterão mais benefícios em comparação com aqueles sem ele, o que terá um impacto prejudicial na concorrência. Além disso, uma vez que não há incentivo para partilhar o Fluxo de Ordem Privada com novos Pesquisadores/Construtores, estes recém-chegados ficarão em desvantagem ao iniciar o jogo.

Porque é que os blocos das transações do utilizador para o Bundle criado pelo Pesquisador têm de ser recolhidos através do Fluxo de Ordem Privado? Isto acontece porque o conteúdo das transações e do Bundle é público e não encriptado. Se forem vistos e obtidos por outros, pode causar danos ao utilizador ou ao Pesquisador. Por exemplo, outros podem extrair o MEV da transação do utilizador através de um ataque em pinça ou desmantelar o Bundle, roubando o MEV. É por isso que tanto os utilizadores como os Pesquisadores têm de confiar atualmente no Construtor, uma vez que precisam de entregar o conteúdo original da transação e do Bundle ao Construtor e confiar que o Construtor não causará qualquer dano.

A emergência do SUAVE é resolver os riscos de centralização causados pelo MEV transfronteiriço e pelo Fluxo de Pedidos Privados.

Primeiro, ao estabelecer um mercado público que serve MEV entre cadeias, os utilizadores ou Pesquisadores podem expressar as suas condições de rendimento para transações ou grupos neste mercado. Por exemplo, se um utilizador tiver duas transações que precisam de ser encaminhadas para Ethereum e Arbitrum, e ambas as transações devem ser incluídas e executadas antes de determinado tempo, podem especificar essas condições no mercado. Os Executores no mercado (que podem ser Pesquisadores ou Construtores) vão competir para cumprir esses pedidos para ganhar recompensas. Mas como podem os utilizadores ou Pesquisadores confiar em lançar as suas transações ou grupos neste mercado público? É aqui que entra a tecnologia de privacidade. Ao encriptar as transações, os utilizadores ou Pesquisadores já não precisam de se preocupar com possíveis danos causados por outros a visualizar as suas transações. Apenas com a privacidade das transações é possível um Fluxo de Ordens Aberto.

SUAVE propõe ainda o conceito de Privacidade Programável, em que os utilizadores ou pesquisadores podem optar por divulgar partes específicas de transações ou conteúdos agrupados (como o endereço do contrato de execução da transação) em vez de se limitarem a escolher entre criptografia completa ou sem criptografia.

Comparadas com transações completamente criptografadas, as transações que divulgam informações específicas podem ser incorporadas em pacotes ou blocos de forma mais eficaz e rápida, e até mesmo receber comissões, como detalhado na seção MEV-Share do quarto artigo. Ao divulgar informações específicas, os Searchers podem até colaborar entre si. O Searcher B pode construir em cima do pacote do Searcher A: o pacote do Searcher A segue a transação do usuário para arbitragem, e o pacote do Searcher B segue o pacote do Searcher A para arbitragem. A privacidade é essencial para um fluxo de ordens aberto. A privacidade permite que os Searchers tenham a oportunidade de cooperar entre si, beneficiando-se mutuamente, em vez de competir por oportunidades de MEV.

Outros benefícios do SUAVE

• Através do SUAVE, as transações DEX cross-chain podem obter melhores preços, e as intenções cross-chain podem ser executadas de forma mais eficiente.
• Se SUAVE for considerado um Builder enorme mas descentralizado, terá mais vantagens do que um Builder centralizado porque reúne mais Fluxos de Pedidos, o que também pode atrair mais Builders para se juntarem à SUAVE, e pode ainda reduzir os riscos causados pela centralização do Builder.
• Através do SUAVE, cada cadeia não precisa construir sua própria piscina de transações privadas e seu próprio mercado de MEV da cadeia, e pode concentrar seus recursos e energia em resolver outros problemas ou fornecer melhores serviços.

arquitetura SUAVE

Quadro de Avisos para Preferência do Usuário

SUAVE pode ser descrito como um “quadro de avisos de Preferências do Utilizador”. O termo “Utilizador” aqui não se refere necessariamente aos utilizadores gerais de blockchain, mas os Pesquisadores também podem ser Utilizadores do SUAVE. A seguir, “Utilizador” irá referir-se aos utilizadores gerais de blockchain, e “Utilizador SUAVE” irá referir-se aos utilizadores do SUAVE.

A Preferência do Utilizador da SUAVE é como uma Intenção especializada que se concentra na ordenação de transações. Não é como as Intenções gerais que os leitores podem ver noutros lugares, que podem especificar várias condições. Tal como os utilizadores especificam preferências e condições nas Intenções, na Preferência, os Utilizadores da SUAVE especificam preferências ou condições para 'transações ou rendimentos de pacotes que entram no bloco', tais como:

• “Quero que a minha transação seja ordenada antes da transação 0xabcd e seja incluída antes do bloco 110050.” Na verdade, é exatamente como as condições especificadas pelo Bundle of Searcher ao usar o Flashbot.
• “Quero que o meu Bundle seja incluído e me traga 0,05 ETH em receita.”
• "Quero que a intenção A e a intenção B sejam incluídas no bloco 1001 da cadeia X e no bloco 50900 da cadeia Y, respectivamente." \

Dica de leitura: Os utilizadores também podem enviar transações gerais de blockchain (sem especificar qualquer Preferência) para SUAVE, ou seja, simplesmente usar SUAVE como um pool de negociação geral ou Flashbot, como enviar diretamente as suas transações de transferência de ETH ou transações Uniswap para SUAVE.

Claro, se você apenas especificar condições, não há necessidade de projetar uma nova arquitetura para fazer isso, basta usar o Flashbot original. Então, na verdade, as Preferências especificadas no SUAVE devem ser combinadas com recompensas, caso contrário, ninguém estará disposto a completar suas Preferências incondicionalmente. Naturalmente, o pré-requisito para o pagamento deve ser que as Preferências tenham sido alcançadas.

Ao transformar a designação de Preferências e recompensas em contratos inteligentes a serem cumpridos, as partes interessadas (como utilizadores ou Pesquisadores) poderão apresentar requisitos de Preferência mais detalhados e diversos, e esses requisitos são atendidos por incentivos económicos em vez de depender da bondade do Construtor.

• “Quero que a minha transação seja classificada antes da transação 0xabcd e incluída antes do bloco 110050. Se for alcançado, eu te darei 3 ETH.”
• “Quero que o meu Bundle seja incluído e me traga 0,05 ETH de rendimento. Se for alcançado, eu te darei 0,02 ETH.”
• “Quero que a Intenção A e a Intenção B sejam incluídas no 1001º bloco da cadeia X e no 50900º bloco da cadeia Y, respectivamente. Se isso for alcançado, eu te darei 1,8 ETH”.

Arquitetura

SUAVE pode ser visto como consistindo em três componentes: Ambiente de Preferência, Mercado de Execução e Construção de Blocos Descentralizada.

• O Ambiente de Preferências é um local que acomoda Preferências do Utilizador e recompensas de várias cadeias, incluindo a cadeia SUAVE e a sua pool de transações. O Utilizador SUAVE pode ser um utilizador geral ou Pesquisador.
• O Mercado de Execução é um grupo de Executores profissionais que encontram e executam Preferências do Utilizador (executando Preferências do Utilizador ao agrupá-las em Pacotes) para ganhar recompensas. O Executor pode ser Procurador ou Construtor
• A Construção de Blocos Descentralizados é o processo de montagem de vários Conjuntos em blocos para uma ou mais cadeias.

△ O PE à esquerda reúne Intenções e transações de arbitragem em várias cadeias, e em seguida, os Executores no meio tentam satisfazer essas Preferências e empacotá-las em Pacotes, entregando esses Pacotes ao papel à direita que tem o direito de produzir blocos para montar os blocos. Fonte da imagem:https://writings.flashbots.net/o-futuro-do-mev-e-suave

A SUAVE terá a sua própria cadeia e pool de transações. O SUAVE chama a cadeia de Camada de Liquidação e o pool de transações de Camada de Mensagens.

Contratos inteligentes podem ser implementados na cadeia para estabelecer contratos entre Preferência e recompensas. A piscina de transações será preenchida com transações em que o utilizador SUAVE declara a Preferência e o Executor recebe recompensas.

O ciclo de vida de uma transação SUAVE

1. Expressão de Preferência: O utilizador SUAVE especifica a preferência e faz ofertas por um ou mais dos seus Intenções/Transações.
2. Otimização de Execução: O Executor encontra um caminho de execução que satisfaça a Preferência do Utilizador e pode até encontrar o caminho ótimo para ele.
3. Acordo de Preferência: O(s) Bundle(s) do Executor foi(foram) incluído(s) com sucesso no bloco da cadeia alvo e cumpre(m) a Preferência especificada pelo Utilizador SUAVE.
4. Liquidação de pagamento: A Oracle retorna o status da cadeia de destino para a cadeia SUAVE e o executor executa o contrato inteligente. Após o contrato confirmar que a Preferência foi satisfeita, a recompensa do Usuário SUAVE é entregue ao Executor.

△ Preferência quatro passos desde o estabelecimento até a execução até a liquidação. Fonte da imagem:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

MEVM

SUAVE precisa ser capaz de escrever Preferência numa linguagem de programação e convertê-la num contrato inteligente para cumprir o contrato entre o Utilizador SUAVE e o Executor. Espera-se que o SUAVE conceba um EVM específico para MEV com base no EVM - MEVM.

MEVM irá adicionar um novo contrato de Pré-compilação e tipo de transação especificamente para MEV. As funções de Preferência do Usuário, Agrupamento de Pacotes e Construção de Blocos podem ser facilmente completadas em MEVM.

O código do programa de exemplo na figura abaixo escreve o algoritmo de Construção de Bloco de Preço de Gás Efetivo (EGP) usando contratos Solidity e pré-compilação MEVM.

EGP Block Building classifica os Bundles de acordo com o Preço do Gás fornecido por cada Bundle. Bundles com Preço do Gás mais alto serão classificados na frente do bloco:

△ A função rosa na imagem é a função Pré-compilação do MEVM, especialmente projetada para uso de MEV. Fonte da imagem:https://writings.flashbots.net/mevm-suave-centauri-and-beyond

Dica de leitura: A execução do algoritmo de construção de blocos na verdade não ocorre na cadeia SUAVE, mas o construtor de blocos simula a execução fora da cadeia (assim como o nó simulará a execução de uma transação localmente), portanto, esse processo de execução não se tornará realmente uma transação que ocupa o espaço do bloco e os recursos de computação da cadeia SUAVE, nem será limitado pelo desempenho de saída da cadeia SUAVE.

Através da compatibilidade do contrato EVM, Searcher e Searcher ou Searcher e Builder poderão cooperar através de contratos, substituindo a relação de confiança unilateral original. A cooperação também melhorará ainda mais a eficiência do Bundle e extrairá mais MEV, o que pode beneficiar todos os participantes da cadeia de suprimentos MEV. Além disso, os participantes podem usar diretamente ferramentas e infraestrutura de desenvolvimento baseadas em EVM, como RPC Provider, ferramentas de teste como Foundry, etc., e a experiência de desenvolvimento será muito boa.

Além disso, o MEVM irá fornecer a função de privacidade de transação, porque sem privacidade, não há possibilidade de cooperação. Sem privacidade, os Searchers têm que se preocupar com o roubo do seu MEV. Na fase inicial, essa privacidade será alcançada através do hardware confiável SGX. A transação será criptografada e depois enviada para o SGX para execução. Acredita-se que o SGX executará o seu código de programa designado sem roubar o MEV à vontade. No futuro, quando outras tecnologias criptográficas avançadas forem gradualmente amadurecidas, a criptografia poderá ser usada para substituir o hardware confiável. Para mais detalhes, consulte o artigo anterior emMempools Criptografadas.

Dica de leitura: No entanto, também existem desvantagens baseadas no EVM, como o EVM é muito Expressivo: Na verdade, para escrever as funções necessárias pelo MEV, você não precisa de muitos Opcodes no EVM. Permitir o uso desses Opcodes pode permitir que pessoas dispostas a escrever execuções muito complexas, e depois deixar a transação falhar no final da execução, fazendo com que o nó desperdice um monte de recursos de computação, que é um ataque de DoS. O projeto Anoma redesenha uma linguagem de programação e ambiente de execução especificamente para expressar e executar Intenções. No futuro, o SUAVE também pode usar a arquitetura da Anoma para substituir o MEVM.

Plug-N-Play SUAVE

Se o programador do bloco ou validador de uma cadeia conhece a existência de SUAVE e pretende usar SUAVE, então irá considerar SUAVE como um Construtor de Blocos. Se SUAVE fornecer um preço de licitação mais alto para os blocos que constrói, então os Mineiros ou Validadores irão usar os blocos de SUAVE. Tomando o MEV-Boost atual no Ethereum como exemplo, os blocos compostos por SUAVE serão convertidos num formato que cumpra com o mecanismo de licitação MEV-Boost através do plug-in fornecido por SUAVE. O Proponente não precisa de fazer quaisquer alterações para adotar os blocos de SUAVE.

Se o desenvolvedor de bloco ou validador de uma cadeia não conhecer a existência de SUAVE, então o Executor de SUAVE irá licitar para receber seu Pacote através das regras de taxa da cadeia.

Desafios da MEV entre cadeias

Cada cadeia tem seu próprio desenvolvedor e validador de blocos. O bloco B1 de SUAVE sendo recebido pela cadeia X não significa que o bloco B2 também será recebido com sucesso pelo Validador da cadeia Y. Os mecanismos de produção em bloco e os mercados da cadeia X e da cadeia Y são independentes. A menos que a cadeia X e a cadeia Y usem o Sequenciador Compartilhado, e o mesmo Sequenciador produza blocos para ambas as cadeias ao mesmo tempo, somente combinando SUAVE podemos garantir a Inclusão Atômica: as duas cadeias não devem "coletar transações especificadas (ou blocos) juntas". Yuan)", ou "nenhuma renda".

E mesmo que o Sequenciador Compartilhado possa garantir a Inclusão Atômica, isso não significa que a transação será executada com sucesso após ser incluída. Se ambas as transações não forem executadas com sucesso, significa que a MEV entre cadeias falhou. Supondo que um Usuário SUAVE queira concluir uma arbitragem entre cadeias, as transações em ambas as cadeias devem ser geradas em tempo real e executadas com sucesso antes que ele possa se beneficiar:

• Se o utilizador SUAVE não estiver disposto a suportar o risco de falha na execução da transação, então a sua Preferência exigirá que ambas as transações sejam executadas com êxito antes de serem concluídas, e então o Executor será pago e o Executor suportará o risco. Ele pode limitar o “resultado da execução bem-sucedida” especificando o estado na cadeia, por exemplo, especificando que um contrato deve emitir um Evento específico, ou especificando quanto o saldo do token de um determinado endereço deve ser maior do que. Em seguida, o Executor que está disposto a correr riscos tentará tornar ambas as transações em tempo real e executadas com sucesso. Se apenas uma delas acabar por ser recebida ou a execução de uma das transações “falhar”, o Executor não receberá a recompensa.
• Se o Utilizador SUAVE estiver disposto a correr riscos, então a sua Preferência pode apenas exigir que ambas as transações sejam recebidas, e também é aceitável se a execução da transação falhar (ou seja, Revert da transação). O Executor ainda tentará o seu melhor para executar ambas as transações com sucesso (a execução bem-sucedida pode resultar numa recompensa maior), mas desde que haja rendimento, pode obter a recompensa.

Tomando a imagem abaixo como exemplo, o Utilizador SUAVE pretende realizar arbitragem de transações entre cadeias cruzadas entre Rollup 1 e Rollup 2: comprar um ETH a um preço mais baixo no Rollup 1 e vender um ETH a um preço mais alto no Rollup 2.

Se ambos os negócios forem pagos em tempo real e executados com sucesso, o Utilizador SUAVE pode ganhar a diferença de preço. O Cenário 1 e 2 na tabela na imagem são "O Utilizador SUAVE está disposto a suportar o risco ele próprio" e "O Executor está disposto a suportar o risco", respetivamente.

As três últimas colunas da tabela são "recompensas para ambos os sucessos", "recompensas para apenas um sucesso" e "resultado final para apenas um sucesso":

• Recompensas para ambas as transações bem-sucedidas (o utilizador SUAVE ganha a diferença de preço):
  • Cenário 1: O utilizador SUAVE paga uma taxa de manuseamento de $50 ao Executor.
  • Cenário 2: O Utilizador SUAVE paga uma taxa de manipulação de $70 ao Executor (mais cara porque o Executor suporta o risco).
• Apenas há uma recompensa para o sucesso (O utilizador SUAVE não ganhou o spread):
  • Cenário 1: O Usuário SUAVE paga $25 de taxa de processamento ao Executor. Os próprios utilizadores da SUAVE absorvem os riscos.
  • Cenário 2: O utilizador SUAVE não tem de pagar taxas nem correr riscos.
• Apenas um resultado bem-sucedido (O usuário do SUAVE não ganhou o spread):
  • Cenário 1: O utilizador SUAVE paga uma taxa de processamento de $25 ao Executor e tem um extra de ETH em mãos.
  • Cenário 2: O utilizador SUAVE não tem que pagar taxas de manuseamento ao Executor e não terá um ETH extra em mãos. E o Executor tem mais um ETH em mãos.

△ Diferentes resultados de execução em diferentes situações. Fonte da imagem:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

A MEV cross-chain requer que os Executores tenham capital, estejam dispostos a correr riscos e tenham tecnologia suficiente para garantir receitas atómicas em tempo real e execução bem-sucedida. Este pode ser um trabalho lucrativo, mas com uma barreira relativamente alta.

Por que o SUAVE precisa de sua própria cadeia?

Porque não podemos simplesmente transferir e partilhar Preferências através da rede P2P? Porque uma rede P2P pura não pode impedir que a rede seja preenchida com inúmeras Preferências (ou seja, ataques de DoS). Se for uma cadeia, os ataques de DoS podem ser evitados através de taxas de processamento.

Por que o SUAVE não usa a cadeia existente? Porque o SUAVE precisa de sua própria função (MEV) e suas próprias configurações de cadeia, como tempo de bloco e tamanho de bloco. Se você o construir diretamente no Ethereum, encontrará problemas como custo muito alto, tempo de bloco muito longo e funções limitadas.

Além disso, porque o SUAVE precisa obter informações de outras cadeias para verificar se a Preferência é satisfeita, uma Cadeia SUAVE independente pode manter neutralidade ao reunir informações de todas as outras cadeias.

No entanto, o SUAVE tem a sua própria cadeia, o que também significa que (1) o Utilizador SUAVE pode precisar de transferir ativos de outras cadeias para a Cadeia SUAVE para usar o SUAVE e (2) o SUAVE precisa de depender da Oracle para reportar informações de outras cadeias. Isto significa que o SUAVE em si tem um requisito adicional de confiança para a Oracle. Se a Oracle não for segura, isso afetará a segurança do contrato no SUAVE.

Dica de leitura: Ainda não há muitos detalhes sobre se o SUAVE terá sua própria token, se os ativos precisam ser transferidos para a SUAVE Chain para uso, ou como transferir para a SUAVE Chain. Apenas é mencionado no vídeo e no artigo “O usuário do SUAVE deve primeiro transferir os ativos de outras chains para a SUAVE Chain antes de poder usá-lo.”

O design e o modelo de segurança da própria SUAVE Chain ainda estão em discussão. Se SUAVE Chain é um Rollup no Ethereum, então você pode usar diretamente o próprio mecanismo do Rollup para transferir ativos e ler outras informações do Rollup. Isso será melhor do que depender de outros rollups. A tecnologia cross-chain e os serviços Oracle trazem muita segurança.

Se o Validador da Cadeia SUAVE puder ser combinado com a Eigenlayer, será mais seguro e confiável usar diretamente o Validador Ethereum como o Validador da Cadeia SUAVE do que gerar um conjunto de Validadores pela própria SUAVE. Mas, é claro, esses projetos também têm desvantagens correspondentes. Para mais discussão sobre o design da Cadeia SUAVE, consulte este artigo.

Resumo dos desafios da SUAVE

• Tempo de bloco da cadeia SUAVE: O tempo de bloco da cadeia SUAVE precisa ser curto o suficiente para que o Usuário SUAVE declare sua Preferência para o Executor ver. Se o tempo da cadeia SUAVE for mais longo do que a cadeia à qual está conectada (como Solana ou outro Rollup), é fácil para o Usuário SUAVE não ter tempo para informar ao Executor SUAVE que deseja que a transação seja incluída no próximo bloco de uma determinada cadeia. Um bloco foi produzido.
• Risco da Oracle: A Oracle é responsável por fornecer informações sobre outras cadeias, e também pode ser responsável pela transferência dos ativos do usuário SUAVE para a cadeia SUAVE, portanto, a importância da Oracle não é algo pequeno.
• Experiência de uso entre cadeias: O usuário SUAVE precisa transferir ativos para a SUAVE Chain, o que também é uma falha na experiência de uso.
• Modelo econômico: O SUAVE precisa emitir seus próprios ativos, como incentivar o Validador SUAVE, como evitar que o mecanismo de incentivo econômico do SUAVE afete a segurança econômica de outras cadeias, etc.
• Tecnologia de privacidade: No curto prazo, SUAVE terá de confiar em hardware confiável, como SGX, para fornecer funções de privacidade de transação, mas a longo prazo terá de mudar para uma abordagem mais descentralizada e segura para reduzir os riscos.
• Linguagem de Preferência Adequada: O EVM é adequado como meio de expressar e executar Preferências?

Resumo e destaques

• A emergência da SUAVE é (1) abordar o risco de centralização causado pela diferença nas vantagens dos Construtores que podem resultar do MEV de Domínio Cruzado, e (2) abrir a porta para a colaboração entre Buscadores / Construtores através da introdução de privacidade programável, reduzindo o risco de centralização que pode surgir do Fluxo de Ordens Privadas.
• Transações totalmente privadas dificultam o trabalho dos Pesquisadores, pois eles não podem Back-Run efetivamente as transações do usuário, o que leva a uma diminuição na eficiência on-chain. No entanto, os usuários não precisam escolher entre "privacidade" e "eficiência". Em vez disso, eles podem usar privacidade programável para escolher divulgar informações parciais, facilitando o trabalho dos Pesquisadores e melhorando a eficiência on-chain e as recompensas de Back-run.
• Com a SUAVE, os Usuários da SUAVE podem especificar suas preferências de Intenção/transações e várias condições, enquanto o restante é tratado por Executores profissionais para alcançar as condições e reivindicar as recompensas prometidas pelos Usuários da SUAVE após o cumprimento.
• SUAVE terá sua própria cadeia porque o P2P puro não pode prevenir ataques de DoS, e SUAVE terá suas próprias características e configurações únicas para a cadeia (MEV), de modo que as cadeias existentes não possam ser usadas diretamente. Esta cadeia será baseada em uma modificação do EVM, adicionando as funcionalidades necessárias para MEV, chamada MEVM.
• MEV entre cadeias é uma operação altamente desafiadora, pois requer garantir a Inclusão Atômica e garantir a “execução bem-sucedida” das transações. Os usuários do SUAVE podem especificar estados que exigem que as transações sejam executadas com sucesso antes de recompensar o Executor, transferindo assim o risco para o Executor. O Sequenciador Compartilhado pode garantir a Inclusão Atômica, mas não garante que as transações serão executadas “com sucesso.”
• O facto de o SUAVE ser a sua própria cadeia significa que os utilizadores do SUAVE precisam de transferir ativos para a cadeia SUAVE antes de poderem usar o SUAVE. Além disso, é necessário um Oracle seguro para reportar informações de outras cadeias para a cadeia SUAVE, a fim de verificar se as Preferências são satisfeitas.
• SUAVE ainda enfrenta muitos desafios técnicos e de design, como Oracle seguro, técnicas de privacidade seguras, linguagem de Preferência e modelos econômicos, entre outros.

Disclaimer：

1. Este artigo foi reproduzido a partir de [imToken Labs]. Todos os direitos autorais pertencem ao autor original [Nic]. Se houver objeções a esta reimpressão, por favor contacte o Gate Learnequipa e eles vão tratar disso 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 Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.