Este artigo apresentará o recurso "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 explicar SUAVE, por favor, primeiro entenda o conceito de Intent.

Intenção

Experiência atual usando transações blockchain

Usando transações Ethereum como exemplo, supondo que um usuário queira trocar seus USDT por ETH, ele pode ir para a página da web do Uniswap para verificar o preço, e após definir a margem de preço permitida, assinar e enviar a transação, e então aguardar o resultado da transação.

Sua transação provavelmente terá este aspecto: 'Assino e envio esta transação, com um valor de Nonce de 23 e uma taxa de gás de 30 Gwei. Ela executará o contrato Uniswap para trocar meus 1000 USDT por 0,5 ETH, com uma variação máxima de 1%'.

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

Suponha que Alice seja uma usuária iniciante e que ela só queira trocar seu USDT por ETH, mas ela precisa ultrapassar muitos obstáculos para realizar esse pequeno desejo:

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

Cada nível é uma pergunta que os usuários novatos na verdade não precisam entender, mas são obrigados a fazer uma escolha: Onde resgatar? Você deseja definir um deslizamento? Qual porcentagem deve ser definida para o deslizamento? Você deseja ajustar a taxa de gás (taxa de manuseio)? Quantos Gwei precisam ser ajustados? Por que a transação falhou? Por que a transação está presa lá por tanto tempo (talvez seja um problema com o Nonce ou a taxa de manuseio)? 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, o Intent só requer que o usuário especifique os resultados que deseja alcançar e as condições para a execução, deixando o restante para pessoas mais profissionais.

Na Intenção, Alice especificou que 1000 USDT deveriam ser trocados por 0.5 ETH, mas considerando a taxa de manipulação, o preço foi ajustado para 0.495 ETH, e então o pedido foi assinado e enviado. A transação de Alice ficará assim: 'Eu assino e envio este pedido. Eu quero trocar 1000 USDT por 0.495 ETH. Este pedido é válido desde que eu consiga 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 usuários só precisam especificar as condições e não precisam se preocupar com como alcançá-las. Legenda:https://www.paradigm.xyz/2023/06/intents

Através do Intent, os usuários não precisam mais lidar e se preocupar com vários detalhes tediosos e confusos entre a geração, assinatura e execução de transações. Eles nem precisam entender o problema e continuar tentando quando uma transação falha. Além disso, diferentes chains terão processos e armadilhas de transação diferentes!

Por meio da Intenção, o usuário só precisa especificar as condições de execução e os resultados esperados de sua Intenção. O restante fica a cargo do Solucionador profissional para realizar a Intenção 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 a Intenção só pode ser implementada 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 de ativos.

A intenção irá melhorar muito a experiência 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 específicas de execução 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 digito o que quero consultar, e o motor de busca encontra informações relevantes para mim por meio de vários canais) ou compras online de comércio eletrônico (eu digito o que quero comprar) Alguma coisa, a empresa de comércio eletrônico 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 Imperative (“imperativo”) é usada para descrever a experiência de usar Transação, que é emitir um comando completo para completar o objetivo; enquanto a palavra “Declarative” (“Declaração”) é usada para descrever a experiência de usar Intent. Descritivo, indicando que é usado ao declarar condições de execução e resultados de execução.

Intenção no mundo da interconexão

Em aplicações entre cadeias, como pontes entre cadeias e DEX entre cadeias, porque estão envolvidas duas ou mais cadeias, os usuários têm que lidar com mais transações em cadeias diferentes.

Excluindo aplicações entre cadeias através da multi-assinatura da parte 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 da parte do projeto enviará automaticamente os ativos ao 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 concluir a operação.

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

Por meio da Intenção, as operações cross-chain só exigirão que os usuários assinem, e eles não precisarão mais se preocupar com as regras de transação e detalhes de cada cadeia. Os usuários poderão operar diferentes cadeias com a mesma experiência do usuário, e nem mesmo perceberão o fato de que existem cadeias 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 eficientemente para completar as solicitações do usuário.

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

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

Do Flashbot para MEV-Boost para SUAVE

Do Flashbot ao MEV-Boost, o espírito que eles defendem é reconhecer a existência do MEV e se esforçar para trazer atividades econômicas ocultas para o primeiro plano. Eles visam estabelecer um mercado público onde qualquer um possa participar, a fim de evitar o cenário em que alguns indivíduos silenciosamente controlam e dominam esse imenso interesse econômico, levando gradualmente à concentração de recursos em suas mãos e, em última análise, impactando a descentralização e 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 no Ethereum, também existem mercados de MEV entre cadeias e fronteiras. Este mercado de MEV entre fronteiras será muito maior do que o do Ethereum, e as transações entre cadeias terão mais oportunidades para extrair MEV do que as transações na mesma cadeia.

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

Outro fenômeno que afetará a centralização e segurança é o Fluxo de Ordem Privado: as transações dos usuários não fluem mais para o pool de transações públicas, mas diretamente para o Pesquisador ou Construtor. O Fluxo de Ordem Privado pode vir do Pesquisador ou Construtor comprando o direito de ganhar renda com as transações dos usuários, ou o Construtor fornecendo serviços atraentes, como (1) cancelamento gratuito de transações ou ordens DEX enviadas pelos usuários, ou (2) fornecendo Pré-Confirmação, antes que a transação seja recebida, o usuário tem a garantia de quão rapidamente a transação será recebida, para que o usuário não precise se preocupar se a transação será recebida e quanto tempo levará para ser recebida.

Embora o Fluxo de Ordens Privadas possa beneficiar inicialmente os usuários, a longo prazo, resultará em centralização. Os Pesquisadores/Construtores com Fluxo de Ordens Privadas 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, como não há incentivo para compartilhar o Fluxo de Ordens Privadas com novos Pesquisadores/Construtores, esses novatos estarão em desvantagem ao iniciar o jogo.

Por que os blocos das transações do usuário para o Bundle criado pelo Pesquisador precisam ser coletados por meio do Fluxo de Ordem Privada? Isso ocorre porque o conteúdo das transações e do Bundle são públicos e não criptografados. Se forem vistos e obtidos por outros, isso pode levar a danos para o usuário ou o Pesquisador. Por exemplo, outros podem extrair o MEV da transação do usuário por meio de um ataque em pinça ou desmontar o Bundle, roubando o MEV. Por isso, tanto os usuários quanto os Pesquisadores atualmente precisam confiar no Construtor, pois precisam entregar o conteúdo original da transação e do Bundle ao Construtor e confiar que o Construtor não causará nenhum dano.

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

Em primeiro lugar, ao estabelecer um mercado público que atenda MEV cross-chain, os usuários ou Searchers podem expressar suas condições de renda para transações ou pacotes neste mercado. Por exemplo, se um usuário tem duas transações que precisam ser roteadas para Ethereum e Arbitrum, respectivamente, e ambas as transações devem ser incluídas e executadas antes de um certo tempo, eles podem especificar essas condições no mercado. Os Executores no mercado (que podem ser Buscadores ou Construtores) competirão para atender a esses pedidos, a fim de ganhar recompensas. Mas como os usuários ou Searchers podem confiar em suas transações ou pacotes nesse mercado público? É aqui que entra a tecnologia de privacidade. Ao criptografar as transações, os usuários ou Buscadores não precisam mais se preocupar com possíveis danos causados por outras pessoas visualizando suas transações. Somente com a privacidade da transação é possível um Fluxo de Pedidos Abertos.

A SUAVE propõe ainda o conceito de Privacidade Programável, pelo qual os usuários ou buscadores podem escolher se divulgam partes específicas de transações ou conteúdo de pacote (como o endereço do contrato de execução da transação) em vez de se limitarem a escolher entre criptografia completa ou nenhuma criptografia.

Comparadas às transações totalmente 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 recompensas, como detalhado na seção MEV-Share do quarto artigo. Ao divulgar informações específicas, os Pesquisadores podem até colaborar entre si. O Pesquisador B pode construir em cima do pacote do Pesquisador A: o pacote do Pesquisador A segue a transação do usuário para arbitragem, e o pacote do Pesquisador B segue o pacote do Pesquisador A para arbitragem. A privacidade é essencial para um fluxo de pedidos aberto. A privacidade permite que os Pesquisadores 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 entre cadeias podem obter melhores preços, e as Intenções entre cadeias podem ser executadas de forma mais eficiente.
• Se o SUAVE for considerado um Construtor enorme, mas descentralizado, terá mais vantagens do que um Construtor centralizado, pois reúne mais Fluxos de Pedidos, o que também pode atrair mais Construtores para se juntarem ao SUAVE e pode reduzir ainda mais os riscos causados pela centralização do Construtor.
• 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

O SUAVE pode ser descrito como um "quadro de avisos de Preferência do Usuário". O termo "Usuário" aqui não se refere necessariamente a usuários gerais de blockchain, mas os Buscadores também podem ser Usuários do SUAVE. A seguir, "Usuário" se referirá aos usuários gerais do blockchain, e "Usuário SUAVE" se referirá aos usuários do SUAVE.

A Preferência do Usuário da SUAVE é como um Intent especializado que se concentra na classificação de transações. Não é como os Intents gerais que os leitores podem ver em outros lugares, que podem especificar várias condições. Da mesma forma que os usuários especificam preferências e condições nos Intents, na Preferência, os Usuários da SUAVE especificam preferências ou condições para "transações ou receitas de pacotes que entram no bloco," como:

• "Quero que minha transação seja classificada antes da transação 0xabcd e incluída antes do bloco 110050." Na verdade, é exatamente como as condições especificadas pelo Bundle of Searcher ao usar o Flashbot.
• “Quero que meu Pacote seja incluído e me traga 0.05 ETH em receita.”
• “Eu 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 usuários também podem enviar transações gerais de blockchain (sem especificar qualquer preferência) para a SUAVE, ou seja, simplesmente usar o SUAVE como um pool de negociação geral ou Flashbot, como enviar diretamente suas transações de transferência de ETH ou transações de Uniswap para a SUAVE que.

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

Ao transformar a designação de Preferência e recompensas em contratos inteligentes a serem cumpridos, as partes demandantes (como usuários ou buscadores) 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 minha transação seja classificada antes da transação 0xabcd e seja incluída antes do bloco 110050. Se for alcançado, eu te darei 3 ETH.”
• “Quero que meu Pacote seja incluído e me traga 0.05 ETH de renda. 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 lhe 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 lugar que acomoda Preferências de Usuários e recompensas de várias cadeias, incluindo a cadeia SUAVE e sua piscina de transações. O Usuário SUAVE pode ser um usuário geral ou Pesquisador.
• O Mercado de Execução é um grupo de Executores profissionais que encontram e executam Preferências do Usuário (executando Preferências do Usuário ao empacotá-las em Bundles) para ganhar recompensas. O Executor pode ser um Pesquisador ou um Construtor
• Construção de Blocos Descentralizada é o processo de montagem de vários Bundles em blocos para uma ou mais cadeias.

△ O PE à esquerda reúne Intenções e transações de arbitragem em várias cadeias, e então os Executores no meio tentam satisfazer essas Preferências e as empacotam em Bundles, entregando esses Bundles para o 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

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

Contratos inteligentes podem ser implantados na cadeia para estabelecer contratos entre Preferência e recompensas. A piscina de transações será preenchida com transações em que o usuário 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 usuário SUAVE especifica a preferência e faz lances por um ou mais de 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 Usuário e pode até mesmo encontrar o caminho ótimo para ele.
3. Assentamento de Preferência: Os Pacotes do Executor foram incluídos com sucesso no bloco da cadeia alvo e atendem à Preferência especificada pelo Usuário SUAVE.
4. Pagamento de Liquidação: O Oráculo 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 é dada ao Executor.

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

MEVM

SUAVE precisa ser capaz de escrever Preferência em uma linguagem de programação e convertê-la em um contrato inteligente para cumprir o contrato entre o Usuário SUAVE e o Executor. SUAVE deve projetar um EVM específico para MEV com base no EVM - MEVM.

MEVM adicionará um novo contrato Precompile e tipo de transação especificamente para MEV. Preferência do Usuário, Pacote de Empacotamento e funções de Construção de Bloco podem ser facilmente concluídas em MEVM.

O código do programa de amostra na figura abaixo escreve o algoritmo de Construção de Bloco de Preço de Gás Efetivo (EGP) usando contratos Solidity e contratos pré-compilados do 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 Precompile do MEVM, que é 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), então esse processo de execução não se tornará realmente uma transação que ocupa o espaço do bloco e os recursos computacionais da cadeia SUAVE, nem será limitado pelo desempenho de saída da cadeia SUAVE.

Por meio da composição do contrato EVM, Pesquisador e Pesquisador ou Pesquisador e Construtor poderão cooperar por meio de contratos, substituindo o relacionamento 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 na cadeia de suprimento de MEV. Além disso, os participantes podem usar diretamente ferramentas de desenvolvimento baseadas em EVM e infraestrutura, como Provedor RPC, ferramentas de teste como Foundry, etc., e a experiência de desenvolvimento será muito boa.

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

Dica de leitura: No entanto, também existem desvantagens baseadas no EVM, como o EVM é demasiado expressivo: na verdade, para escrever as funções necessárias pelo MEV, não são necessários muitos Opcodes no EVM. Permitir o uso desses Opcodes pode permitir que pessoas dispostas a escrever execuções muito complexas, e então deixar a transação falhar no final da execução, fazendo com que o nó desperdice um monte de recursos computacionais, 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 desenvolvedor de bloco ou Validador de uma cadeia conhece a existência do SUAVE e pretende usar o SUAVE, então ele considerará o SUAVE como um Construtor de Bloco. Se o SUAVE oferecer um preço de licitação mais alto para os blocos que constrói, então os Mineiros ou Validadores usarão os blocos do SUAVE. Tomando o MEV-Boost atual no Ethereum como exemplo, os blocos compostos pelo SUAVE serão convertidos em um formato que esteja em conformidade com o mecanismo de licitação MEV-Boost através do plug-in fornecido pelo SUAVE. O Proponente não precisa fazer nenhuma alteração para adotar os blocos do SUAVE.

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

Desafios do MEV entre cadeias

Cada cadeia tem seu próprio desenvolvedor de blocos e validador. O bloco B1 do 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 de blocos e os mercados da cadeia X e da cadeia Y são independentes. A menos que tanto a cadeia X quanto a cadeia Y usem Sequenciador Compartilhado, e o mesmo Sequenciador produza blocos para ambas as cadeias ao mesmo tempo, então somente combinando SUAVE podemos garantir a Inclusão Atômica: as duas cadeias não devem "coletar transações (ou blocos) especificados juntos". Yuan)”, ou “nenhuma receita de forma alguma”.

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 o MEV entre cadeias falhou. Supondo que um Usuário do 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 usuário SUAVE não estiver disposto a correr o risco de falha na execução da transação, então sua Preferência exigirá que ambas as transações sejam executadas com sucesso antes de serem concluídas, e então o Executor será pago e o Executor assumirá o risco. Ele pode restringir o “resultado da execução bem-sucedida” especificando o status na cadeia, por exemplo, especificando que um contrato deve emitir um Evento específico, ou especificando quanto o saldo de tokens de um determinado endereço deve ser maior 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 for recebida ou a execução de uma das transações “falhar”, o Executor não receberá a recompensa.
• Se o usuário SUAVE estiver disposto a correr riscos, então sua preferência pode exigir apenas que ambas as transações sejam recebidas e também está tudo bem se a execução da transação falhar (ou seja, reverter a transação). O Executor ainda tentará o seu melhor para executar ambas as transações com sucesso (a execução bem-sucedida pode resultar em uma recompensa maior), mas contanto que haja renda, você pode obter a recompensa.

Tomando a imagem abaixo como exemplo, o Usuário SUAVE deseja realizar arbitragem de transação 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 Usuário SUAVE pode ganhar a diferença de preço. Os cenários 1 e 2 na tabela na imagem são respectivamente "O Usuário SUAVE está disposto a arcar com o risco ele mesmo" e "O Executor está disposto a arcar com o risco".

As três colunas inferiores 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 usuário SUAVE ganha a diferença de preço):
  • Cenário 1: O usuário SUAVE paga uma taxa de manuseio de US$ 50 ao Executor.
  • Cenário 2: O usuário SUAVE paga uma taxa de manuseio de $70 ao Executor (mais cara porque o Executor assume o risco).
• Só há uma recompensa para o sucesso (o usuário SUAVE não ganhou o spread):
  • Cenário 1: O usuário SUAVE paga uma taxa de manuseio de $25 ao Executor. Os usuários SUAVE absorvem os riscos por si mesmos.
  • Cenário 2: O usuário SUAVE não precisa pagar taxas ou correr riscos.
• Há apenas um resultado bem-sucedido (o usuário SUAVE não ganhou o spread):
  • Cenário 1: O usuário SUAVE paga uma taxa de manipulação de $25 ao Executor e tem um ETH extra em mãos.
  • Cenário 2: O Usuário SUAVE não precisa pagar taxas de manuseio ao Executor e não terá um ETH extra em mãos. E o Executor tem mais um ETH na mão.

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

MEV de 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. Isso pode ser um trabalho lucrativo, mas com uma barreira relativamente alta.

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

Por que não podemos simplesmente transferir e compartilhar 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 transação.

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 possui sua própria cadeia, o que também significa que (1) o usuário do SUAVE pode precisar transferir ativos de outras cadeias para a Cadeia SUAVE para usar o SUAVE e (2) o SUAVE precisa depender do Oracle para relatar informações de outras cadeias. Isso significa que o SUAVE em si tem um requisito adicional de confiança para o Oracle. Se o Oracle não for seguro, isso afetará a segurança do contrato no SUAVE.

Dica de leitura: Ainda não há muitos detalhes sobre se a 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. Isso é mencionado apenas no vídeo e no artigo 'O usuário da SUAVE deve primeiro transferir os ativos de outras chains para a SUAVE Chain antes de poder usá-la.'

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

Se o Validador da Cadeia SUAVE puder ser combinado com o Eigenlayer, será mais seguro e confiável usar diretamente o Validador Ethereum como o Validador de Cadeia SUAVE do que gerar um conjunto de Validadores pelo próprio SUAVE. Mas é claro que esses projetos também têm deficiências correspondentes. Para mais discussões sobre o design da SUAVE Chain, 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 o Usuário SUAVE declarar sua Preferência para que o Executor veja. Se o tempo da cadeia SUAVE for maior do que a cadeia à qual está conectada (como Solana ou outro Rollup), é fácil para o Usuário SUAVE não ter tempo para permitir que o Executor SUAVE saiba que deseja que a transação seja incluída no próximo bloco de uma determinada cadeia. Um bloco foi produzido.
• Risco do Oracle: O Oracle é responsável por fornecer informações sobre outras cadeias e também pode ser responsável por transferir os ativos do usuário SUAVE para a cadeia SUAVE, portanto, a importância do Oracle não é pouca coisa.
• Experiência de uso de interoperabilidade: O usuário do SUAVE precisa transferir ativos para a cadeia SUAVE, o que também é uma falha na experiência de uso.
• Modelo econômico: SUAVE precisa emitir seus próprios ativos, como incentivar o Validador SUAVE, como prevenir que o mecanismo de incentivo econômico da SUAVE afete a segurança econômica de outras cadeias, etc.
• Tecnologia de privacidade: No curto prazo, SUAVE terá que depender de hardware confiável como SGX para fornecer funções de privacidade de transação, mas a longo prazo terá que migrar para uma abordagem mais descentralizada e segura para reduzir riscos.
• Linguagem de Preferência Adequada: O EVM é adequado como meio de expressar e executar Preferências?

Resumo e destaques

• A emergência do 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 efetivamente retroceder transações de usuários, o que leva a uma diminuição da 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, tornando o trabalho dos Pesquisadores mais fácil e melhorando a eficiência on-chain e as recompensas de Back-run.
• Com SUAVE, os usuários do SUAVE podem especificar suas intenções/preferências de 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 do SUAVE após o cumprimento.
• SUAVE terá sua própria cadeia porque P2P puro não pode prevenir ataques de DoS, e SUAVE terá suas próprias características e configurações exclusivas para a cadeia (MEV), para que as cadeias existentes não possam ser usadas diretamente. Essa cadeia será baseada em uma modificação do EVM, adicionando as funcionalidades necessárias para o MEV, chamado de MEVM.
• A 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 para exigir 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 fato de o SUAVE ser sua própria cadeia também significa que os usuários do SUAVE precisam transferir ativos para a cadeia SUAVE antes de poderem usá-lo. Além disso, um Oracle seguro é necessário para relatar informações de outras cadeias para a cadeia SUAVE a fim de verificar se as Preferências são atendidas.
• SUAVE ainda enfrenta muitos desafios técnicos e de design, como Oracle seguro, técnicas de privacidade segura, idioma de preferência e modelos econômicos, entre outros.

Aviso legal:

1. Este artigo foi reproduzido de [imToken Labs]. Todos os direitos autorais pertencem ao autor original [Nic]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção 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. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.