Roteiro ICM da Solana: um "show de imitação" direcionado à Hyperliquid
Prefácio: Os grandes da Solana se reúnem
Recentemente, aconteceu algo interessante no ecossistema Solana. Importantes membros, incluindo a Fundação Solana, Anza e um conhecido laboratório, se reuniram para lançar um roteiro técnico chamado "Mercados de Capital da Internet (Internet Capital Markets, ICM)". A ideia central desse roteiro é "Execução Controlada por Aplicações (Application Controlled Execution, ACE)", ou seja, permitir que as aplicações na blockchain tenham o direito de ordenar transações autonomamente em milissegundos, criando um "Wall Street descentralizado" na blockchain.
Curiosamente, ao ler todo o roteiro, embora não mencione diretamente a Hyperliquid, o design quase em toda parte está focado nos pontos fortes da Hyperliquid. É como se a Solana estivesse dizendo: "O que a Hyperliquid tem, nós também queremos ter, e queremos fazer melhor!"
É importante saber que o Hyperliquid ocupa uma posição dominante no mercado de contratos perpétuos em blockchain, com um volume de transações que chegou a representar cerca de 65% de todo o mercado descentralizado de contratos perpétuos. É evidente que, diante de concorrentes assim, a Solana não está disposta a ser superada por novos entrantes, e por isso lançou este roteiro ICM.
Então, o que é exatamente esse "show de imitação"? Será que a Solana consegue realmente alcançar ou até superar a Hyperliquid? Hoje vamos conversar mais sobre esse assunto.
Contexto e Conteúdo do ICM
Quem está a liderar esta transformação?
Primeiro, vamos ver quem elaborou este roteiro. Os participantes são todos jogadores de peso do ecossistema Solana:
Solana Foundation/Labs: este não precisa de muitas palavras, o "pai" do Solana, responsável pela coordenação geral e desenvolvimento do protocolo central.
Anza: uma empresa de desenvolvimento fundada por ex-membros da Solana Labs, um pouco como a ConsenSys do Ethereum. Eles assumiram muitos trabalhos cruciais em tecnologia nesta folha de roteiro, como o novo protocolo de consenso Alpenglow.
Um laboratório conhecido: fornecedor de infraestrutura MEV na Solana, com grande influência, controla quase todo o fluxo MEV na Solana com o "poder de vida e morte". Desta vez, eles lideraram a oferta do Block Assembly Marketplace (BAM) e outras soluções de ordenação de transações.
Certo capital renomado: uma famosa instituição de investimento em criptomoedas, também um dos primeiros apoiadores da Solana. Devido à posse de uma grande quantidade de SOL e participações em projetos do ecossistema, também possui uma considerável influência na direção técnica.
DoubleZero: uma equipe focada em acelerar a comunicação de rede, oferecendo soluções de rede de fibra ótica dedicadas para melhorar a velocidade de comunicação entre os nós de validação da Solana.
Uma plataforma de contratos perpétuos: um projeto DEX de contratos perpétuos líder na Solana. Anteriormente, a plataforma utilizava um modelo de correspondência off-chain e, ao enfrentar o Hyperliquid totalmente on-chain, mostrava-se um pouco sobrecarregada. Desta vez, ao participar na elaboração do roteiro, é evidente que espera reverter a situação com a atualização da camada base.
A questão central a resolver
O roteiro foca na melhoria da microestrutura do mercado, resumindo, o atual mecanismo de negociação on-chain não é amigável para os Market Makers, ou seja, os participantes que aguardam ordens para serem executadas. Isso ocorre porque os Takers geralmente possuem as informações mais recentes e aumentam ativamente as taxas de negociação para garantir que suas transações sejam executadas em primeiro lugar, enquanto os Makers muitas vezes não conseguem cancelar suas ordens a tempo, sendo forçados a negociar a preços desfavoráveis.
Alguns arbitradores de alta frequência aproveitam essa assimetria para lançar ataques de "fluxo tóxico". Por exemplo, se o preço na blockchain ainda não foi atualizado, mas o preço fora da blockchain já mudou, o arbitrador pode comer as ordens do formador de mercado a preços antigos, fazendo com que o formador de mercado assuma perdas. O resultado é que o Maker, para se proteger, precisa ou aumentar o spread de compra e venda ou reduzir o volume de ordens pendentes, o que leva a uma piora na liquidez de todo o mercado.
O roteiro do ICM visa equilibrar esse padrão e atrair liquidez de alta qualidade de volta à cadeia.
O plano em três etapas do ICM
A Solana dividiu este grande plano em três fases:
Curto prazo (1-3 meses): principalmente otimizar a experiência de negociação em cadeia existente, tornando as aplicações do tipo livro de ordens mais utilizáveis e reduzindo a interferência maliciosa de MEV. Especificamente inclui:
O módulo Block Assembly Marketplace (BAM) de um laboratório conhecido foi lançado na mainnet. A importância deste módulo é fornecer um sistema externo temporário antes do lançamento do ACE (Application Controlled Execution) definitivo, permitindo que os contratos inteligentes na Solana tenham autonomia na ordenação das transações.
A equipe Anza otimizou a taxa de sucesso de "entrar na mesma Slot" para reduzir o deslizamento e as perdas de MEV.
Essas melhorias estão previstas para serem implementadas gradualmente entre julho e setembro de 2025.
Período intermediário (3-9 meses): introdução de uma rede de alta velocidade dedicada e uma nova versão de consenso, reduzindo significativamente a latência e aumentando a capacidade de processamento:
Implementação de uma rede de fibra ótica dedicada ao DoubleZero, proporcionando aos validadores comunicação de alta velocidade com quase zero jitter e redução de latência de até 100ms.
Lançamento do protocolo de consenso Alpenglow, reduzindo o tempo de confirmação final de aproximadamente 12,8 segundos para cerca de 0,15 segundos.
Desenvolvimento de Execução de Programa Assíncrono ( Asynchronous Program Execution, APE ), reduz o bloqueio da execução de transações no consenso.
Longo prazo (9-30 meses): Atualizações revolucionárias na arquitetura central da Solana, com o objetivo de serem alcançadas por volta de 2027:
Líderes Concurrentes Múltiplos, MCL(: Permite que vários validadores proponham transações simultaneamente em seus respectivos pipelines, e depois classifique esses blocos paralelos de acordo com a taxa de prioridade. Isso pode enfraquecer o monopólio de um único empacotador e aumentar a resistência à censura.
A execução controlada por aplicações nativas )Application Controlled Execution, função ACE(: realmente concede ao contrato inteligente na cadeia o poder de controlar a ordem de execução das transações.
Analisando até aqui, o autor acredita que a proposta do roteiro ICM tem uma história por trás que deve ser assim: os DEX tradicionais na Solana foram superados pelo recém-chegado Hyperliquid, que oferece uma "experiência excelente de uma plataforma de negociação on-chain". Os DEX tradicionais, incapazes de competir, tiveram que buscar ajuda de "grandes nomes" como Solana Labs e Anza. Os "grandes nomes" propuseram um plano de reforma técnica como o ICM, afirmando que iriam replicar as habilidades principais do Hyperliquid para equipar os DEX tradicionais, ajudando-os a retornar ao mercado de DEX. No entanto, os "grandes nomes" também disseram que essa reforma técnica é extremamente difícil, portanto, dividiram o plano técnico em uma estratégia de três etapas, e o único equipamento que pode ser fornecido aos DEX tradicionais no momento é o BAM de um laboratório conhecido, para que os DEX tradicionais possam se virar e competir com o Hyperliquid por enquanto.
Após esclarecer o contexto da história, nos próximos capítulos, o autor analisará detalhadamente quais habilidades características da Hyperliquid foram realmente imitadas e reproduzidas pelo ICM.
Imitar um: Mecanismo de ordenação de transações
Problema: Como mencionado anteriormente, a cadeia atual favorece os takers, enquanto os makers sofrem com "fluxo tóxico". Usuários que ativam ordens podem, com base no preço mais recente fora da cadeia, iniciar transações instantaneamente em ordens pendentes na cadeia e priorizar a execução aumentando a taxa de transação, enquanto os market makers muitas vezes não conseguem atualizar ou cancelar as ordens a tempo. O resultado é que os market makers têm que aumentar o spread ou simplesmente retirar a liquidez, piorando a profundidade do mercado.
) A solução definitiva da ICM: aplicação de execução controlável ###ACE(
O roteiro do ICM propõe o conceito de ACE (Application Controlled Execution), que descentraliza o poder de ordenação das transações para as aplicações em cada cadeia, permitindo que as aplicações decidam como as transações relacionadas a elas devem ser ordenadas e executadas. Por exemplo, no futuro, na Solana, que implementará o ACE, os contratos DeFi poderão estabelecer as seguintes regras personalizadas de ordenação de transações:
Atualização de preço do Oracle inserida: Aplicações DeFi podem inserir uma transação antes de grandes negociações para obter o preço mais recente do oráculo, garantindo que os pedidos sejam correspondidos ao preço razoável mais recente, evitando que as cotações dos formadores de mercado sejam arbitradas com base em preços desatualizados.
Prioridade de cancelamento de ordens: A aplicação pode definir que o "pedido de cancelamento" tem prioridade sobre a nova "execução de ordem", permitindo ao maker ter a oportunidade de cancelar a ordem pendente em caso de mercado desfavorável.
Leilão de cauda de equipe: por exemplo, após um grande pedido de compra elevar o preço, a aplicação DeFi colocará a oportunidade "seguinte" em leilão; quem estiver disposto a retornar o maior benefício ao protocolo (ou usuário), o protocolo DeFi permitirá que a sua transação seja executada junto ao grande pedido. As aplicações DeFi podem devolver os rendimentos do leilão aos usuários, transformando assim o fluxo MEV tóxico em receita benéfica.
) BAM de um laboratório conhecido: plano de transição
Antes do lançamento oficial da ACE, um laboratório conhecido lançou uma solução de transição chamada Block Assembly Marketplace ###BAM(. O fluxo de trabalho do BAM é:
O utilizador envia a transação para um nó que executa o software BAM (em vez de diretamente para o atual Líder).
O nó BAM coleta transações locais e executa vários plugins )plugin( para reordenar pacotes de transações (Bundle) sob proteção de privacidade (os plugins são executados em um ambiente TEE seguro, ocultando o conteúdo da transação antes da execução). Através dos plugins, os desenvolvedores de aplicativos podem personalizar várias regras de ordenação para seus contratos, como priorizar cancelamentos, atualizar o preço do oráculo antes da correspondência, e até mesmo executar lances complexos dentro do aplicativo.
O Bundle de transações ordenado é enviado ao Líder Solana para ser empacotado na cadeia.
BAM pode ser visto como um campo de testes antes da implementação do ACE na blockchain, com funcionalidades muito próximas do ACE definitivo, apenas funcionando em uma rede independente fora da rede principal do Solana.
É importante notar que um laboratório conhecido anteriormente fornecia infraestrutura voltada para a extração de MEV (como um motor de bloco), cujo modelo de negócios era criar oportunidades para arbitradores e compartilhar lucros através da otimização da ordem das transações. Isso, de certa forma, é uma "lança" que se opõe aos usuários comuns e aos que são arbitrados. No entanto, esse laboratório fechou no início de 2024 a funcionalidade de pool de memória pública para robôs de arbitragem )mempool(, a fim de reduzir externalidades negativas como ataques de sanduíche. Essa ação indica que a comunidade Solana tende a suprimir MEV prejudicial e a manter a equidade dos usuários.
A introdução do BAM segue exatamente essa linha de pensamento: essencialmente, transforma o mecanismo de ordenação originalmente usado para arbitragem MEV em um "escudo" para proteger os provedores de liquidez, como os formadores de mercado, por exemplo, forçando a retirada de ordens para evitar prejuízos aos formadores de mercado e introduzindo um sistema de devolução de lances para reduzir os lucros de quem faz front-running. Os antigos buscadores de MEV que desejam lucrar devem mudar de papel, criando plugins BAM para servir protocolos DeFi e lucrar com as taxas dos plugins.
) pedir conselhos a Hyperliquid
A abordagem ACE/BAM mencionada acima pode ser vista como uma tentativa de alcançar o mecanismo de correspondência on-chain da Hyperliquid. A Hyperliquid é uma Appchain ### dedicada, criada especialmente para serviços DEX. Além disso, o HLP Vault, operado oficialmente pela Hyperliquid, é na verdade um dos maiores formadores de mercado da plataforma, por isso não é difícil entender que as regras da cadeia da Hyperliquid tendem a favorecer os provedores de liquidez, já tendo implementado no nível da cadeia muitas proteções para os formadores de mercado, como:
Prioridade na proteção do lado da ordem: ordens de cancelamento e ordens de maker são tratadas com prioridade, evitando que os market makers sejam prejudicados em execuções desfavoráveis sem estarem cientes. O "cancelamento com prioridade de execução" mencionado pelo Solana ACE já foi praticado pela Hyperliquid há muitos anos.
Garantia do preço mais recente: O processo de liquidação e correspondência da Hyperliquid enfatiza o uso do preço mais recente e do estado da margem para realizar uma "dupla verificação". Por exemplo, quando há uma correspondência de ordens, o sistema irá buscar novamente o preço mais recente do oráculo para avaliar as margens de ambas as partes, assegurando que não haja risco devido ao atraso no preço. Isso é semelhante ao que a ACE faz ao inserir atualizações do oráculo antes da execução da transação.
Proteção contra auto-negociação: se o mesmo endereço comprar e vender simultaneamente, o Hyperliquid cancela automaticamente em vez de combinar, para evitar volume artificial ou custos desnecessários.
A ACE/BAM do ICM Solana é, sem dúvida, uma "inspiração" da Hyperliquid. A Hyperliquid, como líder em CLOB on-chain, implementou vários mecanismos favoráveis aos market makers através de uma blockchain dedicada. Agora, a Solana espera replicar esse efeito usando uma cadeia genérica e plugins modularizados ------ ou seja, permitindo que cada aplicação tenha um controle semelhante ao da Hyperliquid sobre a ordenação das transações.
Imitar dois: Finalidade imediata
( Comparação de consensos existentes
Atualmente, a Solana utiliza o Tower BFT, onde a confirmação e a finalização são probabilísticas e progressivas: um bloco que recebe 2/3 dos votos é considerado "confirmado)Confirmed###", mas é necessário acumular cerca de 32 blocos subsequentes na cadeia (geralmente cerca de 13 segundos) para ser ancorado como "finalizado(Finalized)". Para algumas aplicações (como o comércio de alta frequência), o tempo de confirmação final de alguns segundos ainda é muito longo.
HyperBFT é o algoritmo de consenso desenvolvido internamente pela Hyperliquid, inspirado no consenso HotStuff, que utiliza uma confirmação de bloco de duas rodadas de votação, alcançando a "finalidade instantânea".
Primeira rodada: Pré-votação ( Prevotação ): Os validadores, após receber o bloco candidato transmitido pelo Proposer, realizarão uma validação rápida. Se a validação for bem-sucedida, cada validador fará um voto de "pré-votação" ( Prevotação ) e o transmitirá para toda a rede. Este voto representa: "Eu verifiquei preliminarmente.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Solana ICM roteiro vs Hyperliquid: a batalha de transações na cadeia
Roteiro ICM da Solana: um "show de imitação" direcionado à Hyperliquid
Prefácio: Os grandes da Solana se reúnem
Recentemente, aconteceu algo interessante no ecossistema Solana. Importantes membros, incluindo a Fundação Solana, Anza e um conhecido laboratório, se reuniram para lançar um roteiro técnico chamado "Mercados de Capital da Internet (Internet Capital Markets, ICM)". A ideia central desse roteiro é "Execução Controlada por Aplicações (Application Controlled Execution, ACE)", ou seja, permitir que as aplicações na blockchain tenham o direito de ordenar transações autonomamente em milissegundos, criando um "Wall Street descentralizado" na blockchain.
Curiosamente, ao ler todo o roteiro, embora não mencione diretamente a Hyperliquid, o design quase em toda parte está focado nos pontos fortes da Hyperliquid. É como se a Solana estivesse dizendo: "O que a Hyperliquid tem, nós também queremos ter, e queremos fazer melhor!"
É importante saber que o Hyperliquid ocupa uma posição dominante no mercado de contratos perpétuos em blockchain, com um volume de transações que chegou a representar cerca de 65% de todo o mercado descentralizado de contratos perpétuos. É evidente que, diante de concorrentes assim, a Solana não está disposta a ser superada por novos entrantes, e por isso lançou este roteiro ICM.
Então, o que é exatamente esse "show de imitação"? Será que a Solana consegue realmente alcançar ou até superar a Hyperliquid? Hoje vamos conversar mais sobre esse assunto.
Contexto e Conteúdo do ICM
Quem está a liderar esta transformação?
Primeiro, vamos ver quem elaborou este roteiro. Os participantes são todos jogadores de peso do ecossistema Solana:
Solana Foundation/Labs: este não precisa de muitas palavras, o "pai" do Solana, responsável pela coordenação geral e desenvolvimento do protocolo central.
Anza: uma empresa de desenvolvimento fundada por ex-membros da Solana Labs, um pouco como a ConsenSys do Ethereum. Eles assumiram muitos trabalhos cruciais em tecnologia nesta folha de roteiro, como o novo protocolo de consenso Alpenglow.
Um laboratório conhecido: fornecedor de infraestrutura MEV na Solana, com grande influência, controla quase todo o fluxo MEV na Solana com o "poder de vida e morte". Desta vez, eles lideraram a oferta do Block Assembly Marketplace (BAM) e outras soluções de ordenação de transações.
Certo capital renomado: uma famosa instituição de investimento em criptomoedas, também um dos primeiros apoiadores da Solana. Devido à posse de uma grande quantidade de SOL e participações em projetos do ecossistema, também possui uma considerável influência na direção técnica.
DoubleZero: uma equipe focada em acelerar a comunicação de rede, oferecendo soluções de rede de fibra ótica dedicadas para melhorar a velocidade de comunicação entre os nós de validação da Solana.
Uma plataforma de contratos perpétuos: um projeto DEX de contratos perpétuos líder na Solana. Anteriormente, a plataforma utilizava um modelo de correspondência off-chain e, ao enfrentar o Hyperliquid totalmente on-chain, mostrava-se um pouco sobrecarregada. Desta vez, ao participar na elaboração do roteiro, é evidente que espera reverter a situação com a atualização da camada base.
A questão central a resolver
O roteiro foca na melhoria da microestrutura do mercado, resumindo, o atual mecanismo de negociação on-chain não é amigável para os Market Makers, ou seja, os participantes que aguardam ordens para serem executadas. Isso ocorre porque os Takers geralmente possuem as informações mais recentes e aumentam ativamente as taxas de negociação para garantir que suas transações sejam executadas em primeiro lugar, enquanto os Makers muitas vezes não conseguem cancelar suas ordens a tempo, sendo forçados a negociar a preços desfavoráveis.
Alguns arbitradores de alta frequência aproveitam essa assimetria para lançar ataques de "fluxo tóxico". Por exemplo, se o preço na blockchain ainda não foi atualizado, mas o preço fora da blockchain já mudou, o arbitrador pode comer as ordens do formador de mercado a preços antigos, fazendo com que o formador de mercado assuma perdas. O resultado é que o Maker, para se proteger, precisa ou aumentar o spread de compra e venda ou reduzir o volume de ordens pendentes, o que leva a uma piora na liquidez de todo o mercado.
O roteiro do ICM visa equilibrar esse padrão e atrair liquidez de alta qualidade de volta à cadeia.
O plano em três etapas do ICM
A Solana dividiu este grande plano em três fases:
Curto prazo (1-3 meses): principalmente otimizar a experiência de negociação em cadeia existente, tornando as aplicações do tipo livro de ordens mais utilizáveis e reduzindo a interferência maliciosa de MEV. Especificamente inclui:
O módulo Block Assembly Marketplace (BAM) de um laboratório conhecido foi lançado na mainnet. A importância deste módulo é fornecer um sistema externo temporário antes do lançamento do ACE (Application Controlled Execution) definitivo, permitindo que os contratos inteligentes na Solana tenham autonomia na ordenação das transações.
A equipe Anza otimizou a taxa de sucesso de "entrar na mesma Slot" para reduzir o deslizamento e as perdas de MEV.
Essas melhorias estão previstas para serem implementadas gradualmente entre julho e setembro de 2025.
Período intermediário (3-9 meses): introdução de uma rede de alta velocidade dedicada e uma nova versão de consenso, reduzindo significativamente a latência e aumentando a capacidade de processamento:
Implementação de uma rede de fibra ótica dedicada ao DoubleZero, proporcionando aos validadores comunicação de alta velocidade com quase zero jitter e redução de latência de até 100ms.
Lançamento do protocolo de consenso Alpenglow, reduzindo o tempo de confirmação final de aproximadamente 12,8 segundos para cerca de 0,15 segundos.
Desenvolvimento de Execução de Programa Assíncrono ( Asynchronous Program Execution, APE ), reduz o bloqueio da execução de transações no consenso.
Longo prazo (9-30 meses): Atualizações revolucionárias na arquitetura central da Solana, com o objetivo de serem alcançadas por volta de 2027:
Líderes Concurrentes Múltiplos, MCL(: Permite que vários validadores proponham transações simultaneamente em seus respectivos pipelines, e depois classifique esses blocos paralelos de acordo com a taxa de prioridade. Isso pode enfraquecer o monopólio de um único empacotador e aumentar a resistência à censura.
A execução controlada por aplicações nativas )Application Controlled Execution, função ACE(: realmente concede ao contrato inteligente na cadeia o poder de controlar a ordem de execução das transações.
Analisando até aqui, o autor acredita que a proposta do roteiro ICM tem uma história por trás que deve ser assim: os DEX tradicionais na Solana foram superados pelo recém-chegado Hyperliquid, que oferece uma "experiência excelente de uma plataforma de negociação on-chain". Os DEX tradicionais, incapazes de competir, tiveram que buscar ajuda de "grandes nomes" como Solana Labs e Anza. Os "grandes nomes" propuseram um plano de reforma técnica como o ICM, afirmando que iriam replicar as habilidades principais do Hyperliquid para equipar os DEX tradicionais, ajudando-os a retornar ao mercado de DEX. No entanto, os "grandes nomes" também disseram que essa reforma técnica é extremamente difícil, portanto, dividiram o plano técnico em uma estratégia de três etapas, e o único equipamento que pode ser fornecido aos DEX tradicionais no momento é o BAM de um laboratório conhecido, para que os DEX tradicionais possam se virar e competir com o Hyperliquid por enquanto.
Após esclarecer o contexto da história, nos próximos capítulos, o autor analisará detalhadamente quais habilidades características da Hyperliquid foram realmente imitadas e reproduzidas pelo ICM.
Imitar um: Mecanismo de ordenação de transações
Problema: Como mencionado anteriormente, a cadeia atual favorece os takers, enquanto os makers sofrem com "fluxo tóxico". Usuários que ativam ordens podem, com base no preço mais recente fora da cadeia, iniciar transações instantaneamente em ordens pendentes na cadeia e priorizar a execução aumentando a taxa de transação, enquanto os market makers muitas vezes não conseguem atualizar ou cancelar as ordens a tempo. O resultado é que os market makers têm que aumentar o spread ou simplesmente retirar a liquidez, piorando a profundidade do mercado.
) A solução definitiva da ICM: aplicação de execução controlável ###ACE(
O roteiro do ICM propõe o conceito de ACE (Application Controlled Execution), que descentraliza o poder de ordenação das transações para as aplicações em cada cadeia, permitindo que as aplicações decidam como as transações relacionadas a elas devem ser ordenadas e executadas. Por exemplo, no futuro, na Solana, que implementará o ACE, os contratos DeFi poderão estabelecer as seguintes regras personalizadas de ordenação de transações:
Atualização de preço do Oracle inserida: Aplicações DeFi podem inserir uma transação antes de grandes negociações para obter o preço mais recente do oráculo, garantindo que os pedidos sejam correspondidos ao preço razoável mais recente, evitando que as cotações dos formadores de mercado sejam arbitradas com base em preços desatualizados.
Prioridade de cancelamento de ordens: A aplicação pode definir que o "pedido de cancelamento" tem prioridade sobre a nova "execução de ordem", permitindo ao maker ter a oportunidade de cancelar a ordem pendente em caso de mercado desfavorável.
Leilão de cauda de equipe: por exemplo, após um grande pedido de compra elevar o preço, a aplicação DeFi colocará a oportunidade "seguinte" em leilão; quem estiver disposto a retornar o maior benefício ao protocolo (ou usuário), o protocolo DeFi permitirá que a sua transação seja executada junto ao grande pedido. As aplicações DeFi podem devolver os rendimentos do leilão aos usuários, transformando assim o fluxo MEV tóxico em receita benéfica.
) BAM de um laboratório conhecido: plano de transição
Antes do lançamento oficial da ACE, um laboratório conhecido lançou uma solução de transição chamada Block Assembly Marketplace ###BAM(. O fluxo de trabalho do BAM é:
O utilizador envia a transação para um nó que executa o software BAM (em vez de diretamente para o atual Líder).
O nó BAM coleta transações locais e executa vários plugins )plugin( para reordenar pacotes de transações (Bundle) sob proteção de privacidade (os plugins são executados em um ambiente TEE seguro, ocultando o conteúdo da transação antes da execução). Através dos plugins, os desenvolvedores de aplicativos podem personalizar várias regras de ordenação para seus contratos, como priorizar cancelamentos, atualizar o preço do oráculo antes da correspondência, e até mesmo executar lances complexos dentro do aplicativo.
O Bundle de transações ordenado é enviado ao Líder Solana para ser empacotado na cadeia.
BAM pode ser visto como um campo de testes antes da implementação do ACE na blockchain, com funcionalidades muito próximas do ACE definitivo, apenas funcionando em uma rede independente fora da rede principal do Solana.
É importante notar que um laboratório conhecido anteriormente fornecia infraestrutura voltada para a extração de MEV (como um motor de bloco), cujo modelo de negócios era criar oportunidades para arbitradores e compartilhar lucros através da otimização da ordem das transações. Isso, de certa forma, é uma "lança" que se opõe aos usuários comuns e aos que são arbitrados. No entanto, esse laboratório fechou no início de 2024 a funcionalidade de pool de memória pública para robôs de arbitragem )mempool(, a fim de reduzir externalidades negativas como ataques de sanduíche. Essa ação indica que a comunidade Solana tende a suprimir MEV prejudicial e a manter a equidade dos usuários.
A introdução do BAM segue exatamente essa linha de pensamento: essencialmente, transforma o mecanismo de ordenação originalmente usado para arbitragem MEV em um "escudo" para proteger os provedores de liquidez, como os formadores de mercado, por exemplo, forçando a retirada de ordens para evitar prejuízos aos formadores de mercado e introduzindo um sistema de devolução de lances para reduzir os lucros de quem faz front-running. Os antigos buscadores de MEV que desejam lucrar devem mudar de papel, criando plugins BAM para servir protocolos DeFi e lucrar com as taxas dos plugins.
) pedir conselhos a Hyperliquid
A abordagem ACE/BAM mencionada acima pode ser vista como uma tentativa de alcançar o mecanismo de correspondência on-chain da Hyperliquid. A Hyperliquid é uma Appchain ### dedicada, criada especialmente para serviços DEX. Além disso, o HLP Vault, operado oficialmente pela Hyperliquid, é na verdade um dos maiores formadores de mercado da plataforma, por isso não é difícil entender que as regras da cadeia da Hyperliquid tendem a favorecer os provedores de liquidez, já tendo implementado no nível da cadeia muitas proteções para os formadores de mercado, como:
Prioridade na proteção do lado da ordem: ordens de cancelamento e ordens de maker são tratadas com prioridade, evitando que os market makers sejam prejudicados em execuções desfavoráveis sem estarem cientes. O "cancelamento com prioridade de execução" mencionado pelo Solana ACE já foi praticado pela Hyperliquid há muitos anos.
Garantia do preço mais recente: O processo de liquidação e correspondência da Hyperliquid enfatiza o uso do preço mais recente e do estado da margem para realizar uma "dupla verificação". Por exemplo, quando há uma correspondência de ordens, o sistema irá buscar novamente o preço mais recente do oráculo para avaliar as margens de ambas as partes, assegurando que não haja risco devido ao atraso no preço. Isso é semelhante ao que a ACE faz ao inserir atualizações do oráculo antes da execução da transação.
Proteção contra auto-negociação: se o mesmo endereço comprar e vender simultaneamente, o Hyperliquid cancela automaticamente em vez de combinar, para evitar volume artificial ou custos desnecessários.
A ACE/BAM do ICM Solana é, sem dúvida, uma "inspiração" da Hyperliquid. A Hyperliquid, como líder em CLOB on-chain, implementou vários mecanismos favoráveis aos market makers através de uma blockchain dedicada. Agora, a Solana espera replicar esse efeito usando uma cadeia genérica e plugins modularizados ------ ou seja, permitindo que cada aplicação tenha um controle semelhante ao da Hyperliquid sobre a ordenação das transações.
Imitar dois: Finalidade imediata
( Comparação de consensos existentes
Atualmente, a Solana utiliza o Tower BFT, onde a confirmação e a finalização são probabilísticas e progressivas: um bloco que recebe 2/3 dos votos é considerado "confirmado)Confirmed###", mas é necessário acumular cerca de 32 blocos subsequentes na cadeia (geralmente cerca de 13 segundos) para ser ancorado como "finalizado(Finalized)". Para algumas aplicações (como o comércio de alta frequência), o tempo de confirmação final de alguns segundos ainda é muito longo.
HyperBFT é o algoritmo de consenso desenvolvido internamente pela Hyperliquid, inspirado no consenso HotStuff, que utiliza uma confirmação de bloco de duas rodadas de votação, alcançando a "finalidade instantânea".