Solana persegue Hyperliquid: um ambicioso espetáculo de imitação
Recentemente, ocorreu algo interessante no ecossistema Solana. A Fundação Solana, Anza, Jito Labs e outros jogadores de peso lançaram em conjunto um roteiro técnico intitulado "Internet Capital Markets ( Internet Capital Markets, ICM )". O cerne deste roteiro é o conceito de "Application Controlled Execution ( ACE )", cujo objetivo é permitir que aplicações em cadeia consigam controlar a ordenação das transações em milissegundos, criando uma "Wall Street em cadeia" descentralizada.
Embora o roteiro não mencione diretamente o Hyperliquid, uma leitura atenta revela que o design está quase sempre focado nos pontos fortes do Hyperliquid. É como se a Solana estivesse dizendo: "Você tem o Hyperliquid, nós também vamos ter, e vamos fazer melhor!"
É importante saber que a Hyperliquid ocupa uma posição dominante no mercado de contratos perpétuos on-chain, com um volume de negociação que chegou a representar cerca de 65% de todo o mercado descentralizado de contratos perpétuos. Diante de um concorrente tão forte, a Solana claramente não está disposta a ser superada, por isso lançou este roteiro ICM.
Então, o que realmente está acontecendo com este "show de imitação"? Será que a Solana pode realmente alcançar ou até superar a Hyperliquid? Vamos analisar mais a fundo.
Contexto e Conteúdo do ICM
Quem está liderando essa transformação?
Participam na elaboração do roteiro jogadores de peso do ecossistema Solana:
Solana Foundation/Labs: 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, semelhante à ConsenSys da Ethereum. Responsável por muitos avanços em tecnologia central, como o novo protocolo de consenso Alpenglow.
Jito Labs: fornecedor de infraestrutura MEV no Solana, com grande influência. Dominam a oferta de soluções de ordenação de transações como o Block Assembly Marketplace (BAM).
Multicoin Capital: uma famosa instituição de investimento em criptomoedas, apoiadora inicial da Solana. Possui uma grande quantidade de SOL e direitos sobre projetos do ecossistema, tendo 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 óptica dedicadas para melhorar a velocidade de comunicação entre os nós de validação da Solana.
Drift: Projeto DEX de contratos perpétuos líder na Solana. Anteriormente usava um modelo de correspondência off-chain, enfrentando dificuldades em comparação com o Hyperliquid totalmente on-chain, esperando reverter a situação com uma atualização de nível inferior.
O problema central a resolver
O roteiro foca na melhoria da microestrutura do mercado, principalmente para resolver o problema atual de a mecânica de negociação em cadeia não ser suficientemente amigável para os formadores de mercado. Atualmente, o Taker(, que inicia ativamente a negociação, muitas vezes está em vantagem, enquanto o Maker), que aguarda a execução da ordem, está em desvantagem. Isso ocorre porque o Taker geralmente possui as informações mais recentes e pode garantir a execução priorizada da negociação aumentando as taxas de transação, enquanto o Maker muitas vezes não consegue cancelar suas ordens a tempo, sendo forçado a negociar a preços desfavoráveis.
Alguns arbitradores de alta frequência podem aproveitar essa assimetria para lançar ataques de "fluxo tóxico". Por exemplo, quando o preço on-chain ainda não foi atualizado, mas o preço off-chain já mudou, os arbitradores podem usar o preço antigo para consumir as ordens dos formadores de mercado, fazendo com que esses últimos suportem perdas. Para se proteger, os formadores de mercado têm que aumentar o spread ou reduzir o volume de ordens, o que resulta em uma deterioração da liquidez do mercado como um todo.
O roteiro do ICM visa equilibrar esse padrão, atraindo liquidez de alta qualidade de volta para a cadeia.
( O plano em três etapas do ICM
Solana dividiu este grande plano em três fases:
Curto prazo )1-3 meses ###: principal otimização da experiência de transação na cadeia existente, tornando aplicações de livro de ordens mais fáceis de usar, reduzindo a interferência maliciosa do MEV. Inclui:
O Marketplace de Block Assembly da Jito Labs ( BAM ) foi lançado na mainnet. Este é um sistema de plug-in temporário antes do lançamento do ACE definitivo, permitindo que os contratos inteligentes Solana tenham o direito de ordenar transações de forma autônoma.
A equipe Anza otimizou a taxa de sucesso de "entrar na mesma Slot" nas transações, reduzindo o deslizamento e as perdas de MEV.
Estas melhorias devem ser 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 do consenso, reduzindo significativamente a latência e aumentando a capacidade de processamento:
Implementação de uma rede de fibra ótica dedicada DoubleZero, proporcionando comunicação de alta velocidade com quase zero de jitter e redução de latência de até 100ms para os validadores.
Lançamento do protocolo de consenso Alpenglow, reduzindo o tempo de confirmação final de cerca de 12,8 segundos para cerca de 0,15 segundos.
Desenvolvimento da Execução de Programas Assíncronos ( Asynchronous Program Execution, APE ), reduz o bloqueio da execução de transações no consenso.
Longo prazo ( 9-30 meses ): Uma atualização revolucionária na arquitetura central da Solana, com o objetivo de ser alcançada por volta de 2027:
Múltiplos Líderes Concorrentes, MCL(: Permite que vários validadores proponham transações simultaneamente em seus próprios pipelines, e então classifica e mescla esses blocos paralelos de acordo com as taxas de prioridade. Isso pode enfraquecer o monopólio de um único empacotador e aumentar a resistência à censura.
Aplicações nativas com execução controlada )Application Controlled Execution, ACE( função: realmente concede aos contratos inteligentes na blockchain o poder de controlar a ordem de execução das transações.
Analisando até aqui, a história por trás deste roteiro ICM pode ser a seguinte: o DEX tradicional Drift na Solana foi superado pelo novato Hyperliquid, que oferece uma experiência excelente de "Binance on-chain". O Drift, por si só, tem dificuldades para competir e recorre a "grandes nomes" como Solana Labs, Anza e Jito. Esses "grandes nomes" propuseram o plano de reforma técnica ICM, afirmando que vão replicar as habilidades de destaque do Hyperliquid para ajudar o Drift a recuperar a competitividade no mercado de DEX. No entanto, os "grandes nomes" também afirmaram que esta reforma técnica é extremamente desafiadora, portanto, o plano técnico foi dividido em uma estratégia de três etapas, e, recentemente, o único recurso que pode ser oferecido ao Drift é o BAM da Jito, permitindo que o Drift se adapte temporariamente e compita com o Hyperliquid.
Entendido este contexto, a seguir vamos analisar detalhadamente quais são as principais vantagens do Hyperliquid que o ICM realmente imitou e replicou.
Imitação 1: Mecanismo de Ordenação de Transações
Problema: Como mencionado anteriormente, a rede atual favorece os takers, enquanto os makers suportam o "fluxo tóxico". Os usuários que ativamente consomem ordens podem, com base nos preços mais recentes fora da cadeia, iniciar transações instantaneamente nas ordens listadas na cadeia, priorizando a execução ao aumentar as taxas de transação, enquanto os market makers muitas vezes não conseguem atualizar ou retirar ordens a tempo. O resultado é que os market makers precisam ou ampliar o spread ou simplesmente retirar a liquidez, piorando a profundidade do mercado.
) A solução definitiva da ICM: execução controlável ( ACE )
O roteiro do ICM propõe o conceito de ACE###Application Controlled Execution(, que descentraliza o direito de ordenação de transações para aplicações em várias cadeias, permitindo que as próprias aplicações decidam como as transações relacionadas a elas serão ordenadas e executadas. Por exemplo, no Solana, que implementará o ACE no futuro, os contratos DeFi poderão implementar as seguintes regras personalizadas de ordenação de transações:
Atualização de preços do Oracle: Aplicações DeFi podem inserir uma transação para obter o preço mais recente do oracle antes de combinar grandes transações, garantindo que os pedidos sejam combinados a preços razoáveis e atualizados, evitando que as cotações dos market makers sejam arbitradas com base em preços desatualizados.
Prioridade na execução de cancelamento de ordens: a aplicação pode definir que o "pedido de cancelamento" tem prioridade sobre novas "transações de execução", permitindo que o maker tenha a oportunidade de retirar a ordem pendente em tempos de mercado desfavoráveis.
Leilão de cauda da equipe: Por exemplo, após uma grande ordem de compra elevar o preço, a aplicação DeFi coloca à venda a oportunidade "imediatamente seguinte", quem estiver disposto a devolver o maior benefício ao protocolo ) ou ao usuário (, o protocolo DeFi permitirá que a transação de quem fez essa oferta seja executada após a grande ordem. As aplicações DeFi podem devolver os rendimentos do leilão aos usuários, transformando assim o fluxo tóxico de MEV em receita benéfica.
) BAM do JITO: plano de transição
Antes do lançamento oficial do ACE, a Jito Labs lançou uma solução de transição chamada Block Assembly Marketplace (BAM). O fluxo de trabalho do BAM é:
O usuário envia a transação para um nó que executa o software BAM ### em vez de enviar diretamente para o atual Leader (.
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 seguro TEE, 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 prioridade para cancelamento de pedidos, atualização dos preços do oráculo antes da correspondência, ou até mesmo executar lances complexos dentro do aplicativo.
O Bundle de transações ordenado é então enviado ao Líder Solana para ser empacotado na cadeia.
BAM pode ser visto como um campo de testes antes do ACE ser colocado na blockchain, com funcionalidades muito próximas do ACE final, apenas funciona em uma rede independente fora da cadeia, e não incorporada ao protocolo principal da Solana.
É importante notar que a Jito anteriormente fornecia infraestrutura voltada para a extração de MEV ), como o Jito Block Engine (, cujo modelo de negócios é criar oportunidades para arbitradores e compartilhar lucros otimizando a ordenação de transações. Isso, em certa medida, é uma "lâmina" que se coloca em oposição aos usuários comuns e aos arbitradores. No entanto, a Jito fechou no início de 2024 a funcionalidade de pool de memória pública ) mempool ( voltada para robôs de arbitragem, a fim de reduzir externalidades negativas como ataques de sanduíche. Esta medida indica que a comunidade Solana tende a suprimir MEV prejudicial, mantendo a equidade dos usuários.
O lançamento do BAM segue essa linha de pensamento: essencialmente transforma o mecanismo de ordenação originalmente utilizado para arbitragem MEV em um "escudo" para proteger os provedores de liquidez, como os formadores de mercado, por exemplo, forçando a prioridade de cancelamento de ordens para evitar danos aos formadores de mercado e introduzindo reembolsos por licitação para reduzir lucros obtidos em corridas. Os buscadores de MEV que anteriormente queriam lucrar terão que mudar de papel, desenvolvendo plugins do BAM para servir os protocolos DeFi e lucrando com as taxas de serviço dos plugins.
) pedir conselhos à HYPERLIQUID
A ideia mencionada sobre ACE/BAM pode ser vista como uma tentativa de alcançar o mecanismo de correspondência on-chain da Hyperliquid. Hyperliquid é uma Appchain( dedicada, projetada especificamente para servir DEX. Além disso, o HLP Vault, operado oficialmente pela Hyperliquid, é na verdade um dos maiores formadores de mercado da plataforma, portanto, não é difícil entender que as regras da cadeia da Hyperliquid são mais voltadas para os provedores de liquidez, já tendo implementado muitas proteções para os formadores de mercado, como:
Prioridade de proteção para ordens pendentes: cancelamentos e ordens de maker são processados prioritariamente, evitando que os market makers sejam prejudicados por execuções indesejadas sem serem informados. O "cancelamento prioritário" mencionado pela Solana ACE já é praticado pela Hyperliquid há muitos anos.
Garantia de preço mais recente: O processo de liquidação e correspondência da Hyperliquid enfatiza a utilização dos preços mais recentes das feeds e do status de margem para realizar uma "dupla verificação". Por exemplo, quando há uma ordem pendente sendo correspondida, o sistema irá novamente buscar o preço mais recente da oracle para avaliar as margens de ambas as partes, garantindo que não haja riscos devido a atrasos nos preços. Isso é semelhante ao que a ACE faz ao inserir atualizações da oracle antes da execução da transação.
Proteção contra auto-negociação: se o mesmo endereço comprar e vender ao mesmo tempo, o Hyperliquid cancelará automaticamente em vez de combinar, para evitar manipulação de volume ou custos desnecessários.
O ACE/BAM do ICM Solana é, sem dúvida, uma "aprendizagem" com a Hyperliquid. A Hyperliquid, como líder em CLOB na cadeia, implementou várias mecânicas amigáveis para criadores de mercado através de uma cadeia exclusiva. Agora, a Solana espera replicar esse efeito usando uma cadeia genérica e plugins modularizados — ou seja, permitir que cada aplicação tenha um controle semelhante ao da Hyperliquid sobre a ordenação das transações.
Imitação Dois: Finalidade Imediata
) Comparação de consensos existentes
A Solana atualmente utiliza o Tower BFT, a confirmação e a finalização são probabilísticas e graduais: um bloco que recebe 2/3 dos votos é considerado "confirmado ###Confirmed(", mas é necessário acumular cerca de 32 blocos subsequentes na cadeia ), normalmente cerca de 13 segundos ### para ser ancorado como "finalizado (Finalized)". Para algumas aplicações (, como negociações de alta frequência ), um tempo de confirmação final de mais de dez segundos ainda é muito longo.
HyperBFT é o algoritmo de consenso desenvolvido internamente pela Hyperliquid, inspirado no consenso HotStuff, que utiliza duas rodadas de votação para confirmar blocos, alcançando "finalidade instantânea".
Primeira rodada: pré-votação ( Prevote ): Após os validadores receberem o bloco candidato transmitido pelo Proposer, eles realizarão uma verificação rápida. Se a verificação for bem-sucedida, cada validador votará com um "pré-voto" ( Prevote ) e transmitirá para toda a rede. Este voto representa: "Eu vi preliminarmente e este bloco está correto."
Segunda rodada: pré-submissão (Precommit): uma vez que um validador coleta o Prevote de mais de dois terços dos validadores para o mesmo bloco candidato, ele ganha confiança suficiente, acreditando que a maioria dos membros da rede reconhece este bloco. Assim, o validador emitirá um voto "pré-submissão" (Precommit) mais significativo e o transmitirá. Este voto representa: "Eu vi que a maioria da rede concorda, estou pronto para registrar oficialmente este bloco no livro razão."
Quando um validador coleta Precommit de mais de dois terços dos validadores para o mesmo bloco candidato, o consenso é alcançado! Este bloco é considerado finalizado (Finalized). Ele será adicionado de forma permanente e irreversível.
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.
16 Curtidas
Recompensa
16
3
Repostar
Compartilhar
Comentário
0/400
GateUser-aa7df71e
· 07-31 07:15
A trela do cachorro também deve ter sua própria atitude.
Ver originalResponder0
BearMarketBarber
· 07-29 19:06
Não se aprende a ter estilo! É sempre aquele sabor.
Ver originalResponder0
MoonMathMagic
· 07-29 19:06
Com essa habilidade ainda quer aprender com os outros?
Solana lançou o roteiro ICM, imitando completamente as principais vantagens do Hyperliquid.
Solana persegue Hyperliquid: um ambicioso espetáculo de imitação
Recentemente, ocorreu algo interessante no ecossistema Solana. A Fundação Solana, Anza, Jito Labs e outros jogadores de peso lançaram em conjunto um roteiro técnico intitulado "Internet Capital Markets ( Internet Capital Markets, ICM )". O cerne deste roteiro é o conceito de "Application Controlled Execution ( ACE )", cujo objetivo é permitir que aplicações em cadeia consigam controlar a ordenação das transações em milissegundos, criando uma "Wall Street em cadeia" descentralizada.
Embora o roteiro não mencione diretamente o Hyperliquid, uma leitura atenta revela que o design está quase sempre focado nos pontos fortes do Hyperliquid. É como se a Solana estivesse dizendo: "Você tem o Hyperliquid, nós também vamos ter, e vamos fazer melhor!"
É importante saber que a Hyperliquid ocupa uma posição dominante no mercado de contratos perpétuos on-chain, com um volume de negociação que chegou a representar cerca de 65% de todo o mercado descentralizado de contratos perpétuos. Diante de um concorrente tão forte, a Solana claramente não está disposta a ser superada, por isso lançou este roteiro ICM.
Então, o que realmente está acontecendo com este "show de imitação"? Será que a Solana pode realmente alcançar ou até superar a Hyperliquid? Vamos analisar mais a fundo.
Contexto e Conteúdo do ICM
Quem está liderando essa transformação?
Participam na elaboração do roteiro jogadores de peso do ecossistema Solana:
Solana Foundation/Labs: 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, semelhante à ConsenSys da Ethereum. Responsável por muitos avanços em tecnologia central, como o novo protocolo de consenso Alpenglow.
Jito Labs: fornecedor de infraestrutura MEV no Solana, com grande influência. Dominam a oferta de soluções de ordenação de transações como o Block Assembly Marketplace (BAM).
Multicoin Capital: uma famosa instituição de investimento em criptomoedas, apoiadora inicial da Solana. Possui uma grande quantidade de SOL e direitos sobre projetos do ecossistema, tendo 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 óptica dedicadas para melhorar a velocidade de comunicação entre os nós de validação da Solana.
Drift: Projeto DEX de contratos perpétuos líder na Solana. Anteriormente usava um modelo de correspondência off-chain, enfrentando dificuldades em comparação com o Hyperliquid totalmente on-chain, esperando reverter a situação com uma atualização de nível inferior.
O problema central a resolver
O roteiro foca na melhoria da microestrutura do mercado, principalmente para resolver o problema atual de a mecânica de negociação em cadeia não ser suficientemente amigável para os formadores de mercado. Atualmente, o Taker(, que inicia ativamente a negociação, muitas vezes está em vantagem, enquanto o Maker), que aguarda a execução da ordem, está em desvantagem. Isso ocorre porque o Taker geralmente possui as informações mais recentes e pode garantir a execução priorizada da negociação aumentando as taxas de transação, enquanto o Maker muitas vezes não consegue cancelar suas ordens a tempo, sendo forçado a negociar a preços desfavoráveis.
Alguns arbitradores de alta frequência podem aproveitar essa assimetria para lançar ataques de "fluxo tóxico". Por exemplo, quando o preço on-chain ainda não foi atualizado, mas o preço off-chain já mudou, os arbitradores podem usar o preço antigo para consumir as ordens dos formadores de mercado, fazendo com que esses últimos suportem perdas. Para se proteger, os formadores de mercado têm que aumentar o spread ou reduzir o volume de ordens, o que resulta em uma deterioração da liquidez do mercado como um todo.
O roteiro do ICM visa equilibrar esse padrão, atraindo liquidez de alta qualidade de volta para a cadeia.
( O plano em três etapas do ICM
Solana dividiu este grande plano em três fases:
Curto prazo )1-3 meses ###: principal otimização da experiência de transação na cadeia existente, tornando aplicações de livro de ordens mais fáceis de usar, reduzindo a interferência maliciosa do MEV. Inclui:
O Marketplace de Block Assembly da Jito Labs ( BAM ) foi lançado na mainnet. Este é um sistema de plug-in temporário antes do lançamento do ACE definitivo, permitindo que os contratos inteligentes Solana tenham o direito de ordenar transações de forma autônoma.
A equipe Anza otimizou a taxa de sucesso de "entrar na mesma Slot" nas transações, reduzindo o deslizamento e as perdas de MEV.
Estas melhorias devem ser 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 do consenso, reduzindo significativamente a latência e aumentando a capacidade de processamento:
Implementação de uma rede de fibra ótica dedicada DoubleZero, proporcionando comunicação de alta velocidade com quase zero de jitter e redução de latência de até 100ms para os validadores.
Lançamento do protocolo de consenso Alpenglow, reduzindo o tempo de confirmação final de cerca de 12,8 segundos para cerca de 0,15 segundos.
Desenvolvimento da Execução de Programas Assíncronos ( Asynchronous Program Execution, APE ), reduz o bloqueio da execução de transações no consenso.
Longo prazo ( 9-30 meses ): Uma atualização revolucionária na arquitetura central da Solana, com o objetivo de ser alcançada por volta de 2027:
Múltiplos Líderes Concorrentes, MCL(: Permite que vários validadores proponham transações simultaneamente em seus próprios pipelines, e então classifica e mescla esses blocos paralelos de acordo com as taxas de prioridade. Isso pode enfraquecer o monopólio de um único empacotador e aumentar a resistência à censura.
Aplicações nativas com execução controlada )Application Controlled Execution, ACE( função: realmente concede aos contratos inteligentes na blockchain o poder de controlar a ordem de execução das transações.
Analisando até aqui, a história por trás deste roteiro ICM pode ser a seguinte: o DEX tradicional Drift na Solana foi superado pelo novato Hyperliquid, que oferece uma experiência excelente de "Binance on-chain". O Drift, por si só, tem dificuldades para competir e recorre a "grandes nomes" como Solana Labs, Anza e Jito. Esses "grandes nomes" propuseram o plano de reforma técnica ICM, afirmando que vão replicar as habilidades de destaque do Hyperliquid para ajudar o Drift a recuperar a competitividade no mercado de DEX. No entanto, os "grandes nomes" também afirmaram que esta reforma técnica é extremamente desafiadora, portanto, o plano técnico foi dividido em uma estratégia de três etapas, e, recentemente, o único recurso que pode ser oferecido ao Drift é o BAM da Jito, permitindo que o Drift se adapte temporariamente e compita com o Hyperliquid.
Entendido este contexto, a seguir vamos analisar detalhadamente quais são as principais vantagens do Hyperliquid que o ICM realmente imitou e replicou.
Imitação 1: Mecanismo de Ordenação de Transações
Problema: Como mencionado anteriormente, a rede atual favorece os takers, enquanto os makers suportam o "fluxo tóxico". Os usuários que ativamente consomem ordens podem, com base nos preços mais recentes fora da cadeia, iniciar transações instantaneamente nas ordens listadas na cadeia, priorizando a execução ao aumentar as taxas de transação, enquanto os market makers muitas vezes não conseguem atualizar ou retirar ordens a tempo. O resultado é que os market makers precisam ou ampliar o spread ou simplesmente retirar a liquidez, piorando a profundidade do mercado.
) A solução definitiva da ICM: execução controlável ( ACE )
O roteiro do ICM propõe o conceito de ACE###Application Controlled Execution(, que descentraliza o direito de ordenação de transações para aplicações em várias cadeias, permitindo que as próprias aplicações decidam como as transações relacionadas a elas serão ordenadas e executadas. Por exemplo, no Solana, que implementará o ACE no futuro, os contratos DeFi poderão implementar as seguintes regras personalizadas de ordenação de transações:
Atualização de preços do Oracle: Aplicações DeFi podem inserir uma transação para obter o preço mais recente do oracle antes de combinar grandes transações, garantindo que os pedidos sejam combinados a preços razoáveis e atualizados, evitando que as cotações dos market makers sejam arbitradas com base em preços desatualizados.
Prioridade na execução de cancelamento de ordens: a aplicação pode definir que o "pedido de cancelamento" tem prioridade sobre novas "transações de execução", permitindo que o maker tenha a oportunidade de retirar a ordem pendente em tempos de mercado desfavoráveis.
Leilão de cauda da equipe: Por exemplo, após uma grande ordem de compra elevar o preço, a aplicação DeFi coloca à venda a oportunidade "imediatamente seguinte", quem estiver disposto a devolver o maior benefício ao protocolo ) ou ao usuário (, o protocolo DeFi permitirá que a transação de quem fez essa oferta seja executada após a grande ordem. As aplicações DeFi podem devolver os rendimentos do leilão aos usuários, transformando assim o fluxo tóxico de MEV em receita benéfica.
) BAM do JITO: plano de transição
Antes do lançamento oficial do ACE, a Jito Labs lançou uma solução de transição chamada Block Assembly Marketplace (BAM). O fluxo de trabalho do BAM é:
O usuário envia a transação para um nó que executa o software BAM ### em vez de enviar diretamente para o atual Leader (.
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 seguro TEE, 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 prioridade para cancelamento de pedidos, atualização dos preços do oráculo antes da correspondência, ou até mesmo executar lances complexos dentro do aplicativo.
O Bundle de transações ordenado é então enviado ao Líder Solana para ser empacotado na cadeia.
BAM pode ser visto como um campo de testes antes do ACE ser colocado na blockchain, com funcionalidades muito próximas do ACE final, apenas funciona em uma rede independente fora da cadeia, e não incorporada ao protocolo principal da Solana.
É importante notar que a Jito anteriormente fornecia infraestrutura voltada para a extração de MEV ), como o Jito Block Engine (, cujo modelo de negócios é criar oportunidades para arbitradores e compartilhar lucros otimizando a ordenação de transações. Isso, em certa medida, é uma "lâmina" que se coloca em oposição aos usuários comuns e aos arbitradores. No entanto, a Jito fechou no início de 2024 a funcionalidade de pool de memória pública ) mempool ( voltada para robôs de arbitragem, a fim de reduzir externalidades negativas como ataques de sanduíche. Esta medida indica que a comunidade Solana tende a suprimir MEV prejudicial, mantendo a equidade dos usuários.
O lançamento do BAM segue essa linha de pensamento: essencialmente transforma o mecanismo de ordenação originalmente utilizado para arbitragem MEV em um "escudo" para proteger os provedores de liquidez, como os formadores de mercado, por exemplo, forçando a prioridade de cancelamento de ordens para evitar danos aos formadores de mercado e introduzindo reembolsos por licitação para reduzir lucros obtidos em corridas. Os buscadores de MEV que anteriormente queriam lucrar terão que mudar de papel, desenvolvendo plugins do BAM para servir os protocolos DeFi e lucrando com as taxas de serviço dos plugins.
) pedir conselhos à HYPERLIQUID
A ideia mencionada sobre ACE/BAM pode ser vista como uma tentativa de alcançar o mecanismo de correspondência on-chain da Hyperliquid. Hyperliquid é uma Appchain( dedicada, projetada especificamente para servir DEX. Além disso, o HLP Vault, operado oficialmente pela Hyperliquid, é na verdade um dos maiores formadores de mercado da plataforma, portanto, não é difícil entender que as regras da cadeia da Hyperliquid são mais voltadas para os provedores de liquidez, já tendo implementado muitas proteções para os formadores de mercado, como:
Prioridade de proteção para ordens pendentes: cancelamentos e ordens de maker são processados prioritariamente, evitando que os market makers sejam prejudicados por execuções indesejadas sem serem informados. O "cancelamento prioritário" mencionado pela Solana ACE já é praticado pela Hyperliquid há muitos anos.
Garantia de preço mais recente: O processo de liquidação e correspondência da Hyperliquid enfatiza a utilização dos preços mais recentes das feeds e do status de margem para realizar uma "dupla verificação". Por exemplo, quando há uma ordem pendente sendo correspondida, o sistema irá novamente buscar o preço mais recente da oracle para avaliar as margens de ambas as partes, garantindo que não haja riscos devido a atrasos nos preços. Isso é semelhante ao que a ACE faz ao inserir atualizações da oracle antes da execução da transação.
Proteção contra auto-negociação: se o mesmo endereço comprar e vender ao mesmo tempo, o Hyperliquid cancelará automaticamente em vez de combinar, para evitar manipulação de volume ou custos desnecessários.
O ACE/BAM do ICM Solana é, sem dúvida, uma "aprendizagem" com a Hyperliquid. A Hyperliquid, como líder em CLOB na cadeia, implementou várias mecânicas amigáveis para criadores de mercado através de uma cadeia exclusiva. Agora, a Solana espera replicar esse efeito usando uma cadeia genérica e plugins modularizados — ou seja, permitir que cada aplicação tenha um controle semelhante ao da Hyperliquid sobre a ordenação das transações.
Imitação Dois: Finalidade Imediata
) Comparação de consensos existentes
A Solana atualmente utiliza o Tower BFT, a confirmação e a finalização são probabilísticas e graduais: um bloco que recebe 2/3 dos votos é considerado "confirmado ###Confirmed(", mas é necessário acumular cerca de 32 blocos subsequentes na cadeia ), normalmente cerca de 13 segundos ### para ser ancorado como "finalizado (Finalized)". Para algumas aplicações (, como negociações de alta frequência ), um tempo de confirmação final de mais de dez segundos ainda é muito longo.
HyperBFT é o algoritmo de consenso desenvolvido internamente pela Hyperliquid, inspirado no consenso HotStuff, que utiliza duas rodadas de votação para confirmar blocos, alcançando "finalidade instantânea".
Primeira rodada: pré-votação ( Prevote ): Após os validadores receberem o bloco candidato transmitido pelo Proposer, eles realizarão uma verificação rápida. Se a verificação for bem-sucedida, cada validador votará com um "pré-voto" ( Prevote ) e transmitirá para toda a rede. Este voto representa: "Eu vi preliminarmente e este bloco está correto."
Segunda rodada: pré-submissão (Precommit): uma vez que um validador coleta o Prevote de mais de dois terços dos validadores para o mesmo bloco candidato, ele ganha confiança suficiente, acreditando que a maioria dos membros da rede reconhece este bloco. Assim, o validador emitirá um voto "pré-submissão" (Precommit) mais significativo e o transmitirá. Este voto representa: "Eu vi que a maioria da rede concorda, estou pronto para registrar oficialmente este bloco no livro razão."
Quando um validador coleta Precommit de mais de dois terços dos validadores para o mesmo bloco candidato, o consenso é alcançado! Este bloco é considerado finalizado (Finalized). Ele será adicionado de forma permanente e irreversível.