Roteiro ICM da Solana: um "show de imitação" direcionado ao Hyperliquid?
Recentemente, vários grandes nomes do ecossistema Solana se reuniram e publicaram um roteiro técnico intitulado "Internet Capital Markets, ICM(". O conceito central deste roteiro é "Application Controlled Execution, ACE)", que basicamente significa permitir que as aplicações na cadeia tenham o direito de ordenar transações de forma autônoma em milissegundos, criando uma "Wall Street on-chain" descentralizada.
Curiosamente, ao ler todo o roteiro, embora não mencione diretamente a Hyperliquid, o design está quase sempre direcionado para os pontos fortes da Hyperliquid. É como se a Solana estivesse dizendo: "O que você tem na Hyperliquid, nós também queremos ter, e vamos fazer melhor!"
É importante saber que a Hyperliquid ocupa uma posição dominante no mercado de contratos perpétuos na blockchain, com um volume de negociação que chegou a representar cerca de 65% de todo o mercado descentralizado de contratos perpétuos. É evidente que, diante de um concorrente tão forte, a Solana não está disposta a ser superada por recém-chegados, e assim lançou este roteiro ICM.
Então, o que é exatamente esse "show de imitações"? Será que a Solana consegue realmente alcançar ou até superar a Hyperliquid? Hoje vamos aprofundar essa discussão.
Contexto e Conteúdo do ICM
( Quem está liderando essa transformação?
Primeiro, vamos ver quem elaborou este roteiro. Os participantes são todos grandes jogadores do ecossistema Solana:
Solana Foundation/Labs: isto não precisa de muita explicação, o "pai" do Solana, responsável pela coordenação geral e desenvolvimento do protocolo principal.
Anza: uma empresa de desenvolvimento fundada por ex-membros da Solana Labs, um pouco como a ConsenSys do Ethereum. Eles assumiram muitos desafios técnicos centrais neste roteiro, como o novo protocolo de consenso Alpenglow.
Jito Labs: 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 outros esquemas de ordenação de transações.
Multicoin Capital: uma famosa instituição de investimento em criptomoedas, também é um dos primeiros apoiadores da Solana. Devido à sua grande posse de SOL e direitos sobre projetos do ecossistema, tem uma influência considerável na direção técnica.
DoubleZero: uma equipe focada em acelerar a comunicação na 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: O principal projeto DEX de contratos perpétuos na Solana. Anteriormente, o Drift utilizava um modelo de correspondência off-chain, o que se revelou um pouco difícil ao enfrentar o Hyperliquid completamente on-chain. Desta vez, ao participar da elaboração do roteiro, é evidente que espera-se reverter a situação com a atualização da infraestrutura.
( O problema central a ser resolvido
O roteiro foca na melhoria da microestrutura do mercado, dizendo de forma simples que o mecanismo atual de negociação on-chain não é amigável para os market makers, ou seja, os Takers que iniciam ativamente as transações se beneficiam, enquanto os Market Makers ) acabam por perder. Isso ocorre porque os Takers geralmente têm acesso às informações mais recentes e aumentam ativamente as taxas de transação para garantir que suas ordens sejam executadas em primeiro lugar, enquanto os Makers muitas vezes não têm tempo para cancelar suas ordens, sendo forçados a negociar a preços desfavoráveis.
Alguns arbitradores de alta frequência aproveitarão essa assimetria para lançar ataques de "tráfego tóxico". Por exemplo, se o preço na cadeia ainda não foi atualizado, mas o preço fora da cadeia já mudou, os arbitradores poderão consumir as ordens dos market makers a preços antigos, fazendo com que os market makers suportem as perdas. O resultado é que o Maker, para se proteger, terá que aumentar o spread de compra e venda ou reduzir a quantidade de ordens pendentes, o que leva a uma deterioração da liquidez geral do mercado.
O roteiro do ICM é equilibrar esse padrão, atraindo liquidez de alta qualidade de volta para a cadeia.
A estratégia de três passos da ICM
Solana dividiu este grande plano em três fases:
Curto prazo(1-3 meses): O principal objetivo é otimizar a experiência de negociação na cadeia existente, tornando as aplicações do livro de ordens mais utilizáveis e reduzindo a interferência maliciosa do MEV. Especificamente inclui:
O Marketplace Block Assembly da Jito Labs###BAM( teve o seu módulo lançado na mainnet. O significado deste módulo é fornecer um sistema externo temporário, permitindo que os contratos inteligentes na Solana tenham autonomia na ordenação das transações, antes do lançamento da ACE) (Application Controlled Execution) definitiva.
A equipe Anza otimizou a taxa de sucesso de "entrar na mesma Slot da negociação", reduzindo assim o deslizamento e as perdas de MEV.
Essas melhorias estão previstas para serem implementadas entre julho e setembro de 2025.
Período intermediário (3-9 meses ): Introdução de rede de alta velocidade dedicada e nova versão de consenso, reduzindo significativamente a latência e aumentando a capacidade de processamento:
Implantação da rede de fibra óptica dedicada DoubleZero, proporcionando comunicação em alta velocidade com quase zero de jitter e uma redução de atraso 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 de execução de programas assíncronos ( Execução de Programas Assíncronos, APE ), reduz o bloqueio da execução de transações no consenso.
Longo prazo (9-30 meses ): Revolução na arquitetura central do Solana, com o objetivo de ser alcançado por volta de 2027:
Líderes Conjuntos Múltiplos, MCL(: Permite que vários validadores proponham transações simultaneamente em seus próprios pipelines e, em seguida, classifiquem e combinem esses blocos paralelos com base nas taxas de prioridade. Isso pode enfraquecer o monopólio de um único empacotador e aumentar a resistência à censura.
Execução Controlada por Aplicação ), ACE( funcionalidade: realmente confere 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 a seguinte história por trás: o DEX renomado Drift na Solana foi ultrapassado pelo recém-chegado Hyperliquid com a excelente experiência de "Binance on-chain". Drift, incapaz de competir, teve que pedir ajuda a "grandes nomes" como Solana Labs, Anza e Jito. Os "grandes nomes" propuseram um plano de reforma técnica chamado ICM, afirmando que iriam replicar as habilidades principais do Hyperliquid para equipar o Drift, ajudando-o a voltar ao mercado 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. No curto prazo, o único equipamento que pode ser fornecido ao Drift é o BAM da Jito, permitindo que o Drift se vire e compare com o Hyperliquid.
Clarificado o contexto da história, nos próximos capítulos, o autor irá analisar detalhadamente quais habilidades distintivas a ICM realmente imitou e replicou da Hyperliquid.
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". Os usuários que tomam a iniciativa de consumir ordens podem, com base no preço mais recente fora da cadeia, iniciar imediatamente uma transação com ordens pendentes na cadeia e priorizar a execução ao aumentar as taxas. Os formadores de mercado frequentemente não conseguem atualizar ou cancelar suas ordens a tempo. O resultado é que os formadores de mercado são forçados a aumentar o spread ou a retirar a liquidez, tornando a profundidade do mercado pior.
) 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 cada aplicação na cadeia, permitindo que a própria aplicação decida como as transações relacionadas a ela devem ser ordenadas e executadas. Por exemplo, no futuro, ao implementar o ACE no Solana, os contratos DeFi poderão implementar as seguintes regras de ordenação de transações personalizadas:
Atualização de preços 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 as ordens sejam executadas 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 na execução de cancelamento de ordens: a aplicação pode definir que o "pedido de cancelamento" tenha prioridade sobre a nova "transação de execução", permitindo ao maker ter a oportunidade de cancelar a ordem pendente a tempo em condições de mercado desfavoráveis.
Leilão na cauda da equipe: por exemplo, após o surgimento de uma enorme ordem de compra que eleva o preço, a aplicação DeFi coloca à venda a oportunidade de "seguir logo em seguida"; quem estiver disposto a devolver o maior benefício ao protocolo ### ou ao usuário (, o protocolo DeFi permitirá que a transação dessa pessoa seja executada junto à grande ordem. A aplicação DeFi pode devolver os lucros do leilão aos usuários, transformando assim o fluxo MEV tóxico em receita benéfica.
) BAM do JITO: plano de transição
Antes do lançamento oficial da 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 enviá-la diretamente para o líder atual ).
Os nós BAM coletam transações locais e executam vários plugins ###plugin( para reordenar pacotes de transações )Bundle( com proteção de privacidade. Os plugins são executados em um ambiente seguro de TEE, ocultando o conteúdo da transação externamente 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 de cancelamento de pedidos, atualização do preço do oráculo antes da correspondência, e até mesmo execução de lances complexos dentro do aplicativo.
O Bundle de transações ordenado é então enviado para o Líder Solana para ser empacotado na blockchain.
BAM pode ser visto como um campo de provas antes da implementação do ACE na blockchain, com funcionalidades muito próximas do ACE definitivo, apenas funciona em uma rede independente fora da cadeia, e não embutido no protocolo da cadeia principal Solana.
É importante notar que a Jito anteriormente oferecia infraestrutura voltada para a extração de MEV (, como o Jito Block Engine ), cujo modelo de negócio é criar oportunidades para os arbitradores e compartilhar os lucros através da otimização da ordem das transações. Isso, de certa forma, se coloca como uma "lança" em oposição aos usuários comuns e aos que são alvo de arbitragem. No entanto, a Jito 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. Esta medida indica que a comunidade Solana tende a suprimir MEV prejudicial e a manter a equidade dos usuários.
O lançamento do BAM vai ao encontro desta ideia: essencialmente, transforma o mecanismo de ordenação originalmente utilizado para arbitragem MEV numa "escudo" para proteger os provedores de liquidez, como os formadores de mercado, por exemplo, priorizando a anulação forçada de ordens para evitar prejuízos aos formadores de mercado e introduzindo recompensas por licitação para reduzir lucros de frente. Os anteriores buscadores de MEV, se quiserem ganhar dinheiro, terão que mudar de papel, escrevendo plugins BAM para servir protocolos DeFi e lucrar com as taxas dos plugins.
( pedir conselhos ao 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. Hyperliquid é uma appchain ) dedicada, criada especificamente para serviços 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 muitos designs para proteger os formadores de mercado, como por exemplo:
Prioridade de proteção para ordens pendentes: as ordens de cancelamento e as ordens de maker são processadas com prioridade, evitando que os formadores de mercado sejam prejudicados por transações desfavoráveis sem estarem cientes. O "cancelamento prioritário" mencionado no Solana ACE já foi praticado pelo Hyperliquid durante muitos anos.
Garantia de 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 "verificação dupla". Por exemplo, quando há uma ordem pendente que é correspondida, o sistema puxará novamente o preço mais recente do oráculo para avaliar a margem de ambas as partes, garantindo que não haja risco devido ao atraso de preço. Isso é semelhante à atualização do oráculo pela ACE antes da execução da negociaçã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 manipulação de volume ou custos desnecessários.
O ACE/BAM da Solana ICM é, sem dúvida, uma "consulta" ao Hyperliquid. O Hyperliquid, como líder de CLOB na cadeia, implementou uma série de mecanismos amigáveis para os formadores de mercado através de uma cadeia exclusiva. Agora, a Solana espera usar cadeias genéricas e plugins modularizados para replicar esse efeito------ou seja, permitir que cada aplicação tenha um controle semelhante ao do Hyperliquid sobre a ordenação das transações.
Imitar Dois: Finalidade Imediata
( comparação de consenso existente
A Solana atualmente utiliza o Tower BFT, onde a confirmação e a finalização são probabilísticas e graduais: um bloco recebe 2/3 dos votos e é considerado "confirmado ) Confirmado (", mas precisa acumular cerca de 32 blocos subsequentes na cadeia, o que geralmente leva cerca de 13 segundos ) para ser ancorado como "finalizado ### Finalizado (". Para algumas aplicações ), como negociação de alta frequência ###, esse 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 duas rodadas de votação para confirmar blocos, alcançando a "finalidade instantânea".
Primeira rodada: pré-votação ( Prevotação ): Após os validadores receberem o bloco candidato transmitido pelo Proposer, eles farão uma validação rápida. Se a validação for bem-sucedida, cada validador emitirá um "voto de pré-votação" ( Prevotação ) e o transmitirá para toda a rede. Este voto representa: "Eu revisei preliminarmente, este bloco está ok."
Segunda rodada: Pré-submissão (Precommit): Uma vez que um validador coleta os Prevotes de mais de dois terços dos validadores sobre o mesmo bloco candidato, ele ganha confiança suficiente para acreditar que a maioria da rede se
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
10 gostos
Recompensa
10
5
Partilhar
Comentar
0/400
gas_guzzler
· 08-05 15:39
Copiar tarefas também é uma forma de aprendizagem. Qual é o problema?
Ver originalResponder0
RektHunter
· 08-05 15:39
Se é para copiar, que se copie, é só isso que o sol consegue fazer.
Ver originalResponder0
PaperHandSister
· 08-05 15:37
Assistindo a peça, você copia, eu copio, todos copiam.
Ver originalResponder0
GweiWatcher
· 08-05 15:28
Realmente é só copiar e colar, que fraco!
Ver originalResponder0
ApeDegen
· 08-05 15:23
Hmm, na verdade não é bem uma imitação, é uma referência.
O roteiro ICM da Solana aponta para uma nova transformação no padrão de negociação na cadeia do Hyperliquid.
Roteiro ICM da Solana: um "show de imitação" direcionado ao Hyperliquid?
Recentemente, vários grandes nomes do ecossistema Solana se reuniram e publicaram um roteiro técnico intitulado "Internet Capital Markets, ICM(". O conceito central deste roteiro é "Application Controlled Execution, ACE)", que basicamente significa permitir que as aplicações na cadeia tenham o direito de ordenar transações de forma autônoma em milissegundos, criando uma "Wall Street on-chain" descentralizada.
Curiosamente, ao ler todo o roteiro, embora não mencione diretamente a Hyperliquid, o design está quase sempre direcionado para os pontos fortes da Hyperliquid. É como se a Solana estivesse dizendo: "O que você tem na Hyperliquid, nós também queremos ter, e vamos fazer melhor!"
É importante saber que a Hyperliquid ocupa uma posição dominante no mercado de contratos perpétuos na blockchain, com um volume de negociação que chegou a representar cerca de 65% de todo o mercado descentralizado de contratos perpétuos. É evidente que, diante de um concorrente tão forte, a Solana não está disposta a ser superada por recém-chegados, e assim lançou este roteiro ICM.
Então, o que é exatamente esse "show de imitações"? Será que a Solana consegue realmente alcançar ou até superar a Hyperliquid? Hoje vamos aprofundar essa discussão.
Contexto e Conteúdo do ICM
( Quem está liderando essa transformação?
Primeiro, vamos ver quem elaborou este roteiro. Os participantes são todos grandes jogadores do ecossistema Solana:
Solana Foundation/Labs: isto não precisa de muita explicação, o "pai" do Solana, responsável pela coordenação geral e desenvolvimento do protocolo principal.
Anza: uma empresa de desenvolvimento fundada por ex-membros da Solana Labs, um pouco como a ConsenSys do Ethereum. Eles assumiram muitos desafios técnicos centrais neste roteiro, como o novo protocolo de consenso Alpenglow.
Jito Labs: 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 outros esquemas de ordenação de transações.
Multicoin Capital: uma famosa instituição de investimento em criptomoedas, também é um dos primeiros apoiadores da Solana. Devido à sua grande posse de SOL e direitos sobre projetos do ecossistema, tem uma influência considerável na direção técnica.
DoubleZero: uma equipe focada em acelerar a comunicação na 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: O principal projeto DEX de contratos perpétuos na Solana. Anteriormente, o Drift utilizava um modelo de correspondência off-chain, o que se revelou um pouco difícil ao enfrentar o Hyperliquid completamente on-chain. Desta vez, ao participar da elaboração do roteiro, é evidente que espera-se reverter a situação com a atualização da infraestrutura.
( O problema central a ser resolvido
O roteiro foca na melhoria da microestrutura do mercado, dizendo de forma simples que o mecanismo atual de negociação on-chain não é amigável para os market makers, ou seja, os Takers que iniciam ativamente as transações se beneficiam, enquanto os Market Makers ) acabam por perder. Isso ocorre porque os Takers geralmente têm acesso às informações mais recentes e aumentam ativamente as taxas de transação para garantir que suas ordens sejam executadas em primeiro lugar, enquanto os Makers muitas vezes não têm tempo para cancelar suas ordens, sendo forçados a negociar a preços desfavoráveis.
Alguns arbitradores de alta frequência aproveitarão essa assimetria para lançar ataques de "tráfego tóxico". Por exemplo, se o preço na cadeia ainda não foi atualizado, mas o preço fora da cadeia já mudou, os arbitradores poderão consumir as ordens dos market makers a preços antigos, fazendo com que os market makers suportem as perdas. O resultado é que o Maker, para se proteger, terá que aumentar o spread de compra e venda ou reduzir a quantidade de ordens pendentes, o que leva a uma deterioração da liquidez geral do mercado.
O roteiro do ICM é equilibrar esse padrão, atraindo liquidez de alta qualidade de volta para a cadeia.
A estratégia de três passos da ICM
Solana dividiu este grande plano em três fases:
Curto prazo(1-3 meses): O principal objetivo é otimizar a experiência de negociação na cadeia existente, tornando as aplicações do livro de ordens mais utilizáveis e reduzindo a interferência maliciosa do MEV. Especificamente inclui:
O Marketplace Block Assembly da Jito Labs###BAM( teve o seu módulo lançado na mainnet. O significado deste módulo é fornecer um sistema externo temporário, permitindo que os contratos inteligentes na Solana tenham autonomia na ordenação das transações, antes do lançamento da ACE) (Application Controlled Execution) definitiva.
A equipe Anza otimizou a taxa de sucesso de "entrar na mesma Slot da negociação", reduzindo assim o deslizamento e as perdas de MEV.
Essas melhorias estão previstas para serem implementadas entre julho e setembro de 2025.
Período intermediário (3-9 meses ): Introdução de rede de alta velocidade dedicada e nova versão de consenso, reduzindo significativamente a latência e aumentando a capacidade de processamento:
Implantação da rede de fibra óptica dedicada DoubleZero, proporcionando comunicação em alta velocidade com quase zero de jitter e uma redução de atraso 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 de execução de programas assíncronos ( Execução de Programas Assíncronos, APE ), reduz o bloqueio da execução de transações no consenso.
Longo prazo (9-30 meses ): Revolução na arquitetura central do Solana, com o objetivo de ser alcançado por volta de 2027:
Líderes Conjuntos Múltiplos, MCL(: Permite que vários validadores proponham transações simultaneamente em seus próprios pipelines e, em seguida, classifiquem e combinem esses blocos paralelos com base nas taxas de prioridade. Isso pode enfraquecer o monopólio de um único empacotador e aumentar a resistência à censura.
Execução Controlada por Aplicação ), ACE( funcionalidade: realmente confere 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 a seguinte história por trás: o DEX renomado Drift na Solana foi ultrapassado pelo recém-chegado Hyperliquid com a excelente experiência de "Binance on-chain". Drift, incapaz de competir, teve que pedir ajuda a "grandes nomes" como Solana Labs, Anza e Jito. Os "grandes nomes" propuseram um plano de reforma técnica chamado ICM, afirmando que iriam replicar as habilidades principais do Hyperliquid para equipar o Drift, ajudando-o a voltar ao mercado 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. No curto prazo, o único equipamento que pode ser fornecido ao Drift é o BAM da Jito, permitindo que o Drift se vire e compare com o Hyperliquid.
Clarificado o contexto da história, nos próximos capítulos, o autor irá analisar detalhadamente quais habilidades distintivas a ICM realmente imitou e replicou da Hyperliquid.
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". Os usuários que tomam a iniciativa de consumir ordens podem, com base no preço mais recente fora da cadeia, iniciar imediatamente uma transação com ordens pendentes na cadeia e priorizar a execução ao aumentar as taxas. Os formadores de mercado frequentemente não conseguem atualizar ou cancelar suas ordens a tempo. O resultado é que os formadores de mercado são forçados a aumentar o spread ou a retirar a liquidez, tornando a profundidade do mercado pior.
) 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 cada aplicação na cadeia, permitindo que a própria aplicação decida como as transações relacionadas a ela devem ser ordenadas e executadas. Por exemplo, no futuro, ao implementar o ACE no Solana, os contratos DeFi poderão implementar as seguintes regras de ordenação de transações personalizadas:
Atualização de preços 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 as ordens sejam executadas 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 na execução de cancelamento de ordens: a aplicação pode definir que o "pedido de cancelamento" tenha prioridade sobre a nova "transação de execução", permitindo ao maker ter a oportunidade de cancelar a ordem pendente a tempo em condições de mercado desfavoráveis.
Leilão na cauda da equipe: por exemplo, após o surgimento de uma enorme ordem de compra que eleva o preço, a aplicação DeFi coloca à venda a oportunidade de "seguir logo em seguida"; quem estiver disposto a devolver o maior benefício ao protocolo ### ou ao usuário (, o protocolo DeFi permitirá que a transação dessa pessoa seja executada junto à grande ordem. A aplicação DeFi pode devolver os lucros do leilão aos usuários, transformando assim o fluxo MEV tóxico em receita benéfica.
) BAM do JITO: plano de transição
Antes do lançamento oficial da 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 enviá-la diretamente para o líder atual ).
Os nós BAM coletam transações locais e executam vários plugins ###plugin( para reordenar pacotes de transações )Bundle( com proteção de privacidade. Os plugins são executados em um ambiente seguro de TEE, ocultando o conteúdo da transação externamente 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 de cancelamento de pedidos, atualização do preço do oráculo antes da correspondência, e até mesmo execução de lances complexos dentro do aplicativo.
O Bundle de transações ordenado é então enviado para o Líder Solana para ser empacotado na blockchain.
BAM pode ser visto como um campo de provas antes da implementação do ACE na blockchain, com funcionalidades muito próximas do ACE definitivo, apenas funciona em uma rede independente fora da cadeia, e não embutido no protocolo da cadeia principal Solana.
É importante notar que a Jito anteriormente oferecia infraestrutura voltada para a extração de MEV (, como o Jito Block Engine ), cujo modelo de negócio é criar oportunidades para os arbitradores e compartilhar os lucros através da otimização da ordem das transações. Isso, de certa forma, se coloca como uma "lança" em oposição aos usuários comuns e aos que são alvo de arbitragem. No entanto, a Jito 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. Esta medida indica que a comunidade Solana tende a suprimir MEV prejudicial e a manter a equidade dos usuários.
O lançamento do BAM vai ao encontro desta ideia: essencialmente, transforma o mecanismo de ordenação originalmente utilizado para arbitragem MEV numa "escudo" para proteger os provedores de liquidez, como os formadores de mercado, por exemplo, priorizando a anulação forçada de ordens para evitar prejuízos aos formadores de mercado e introduzindo recompensas por licitação para reduzir lucros de frente. Os anteriores buscadores de MEV, se quiserem ganhar dinheiro, terão que mudar de papel, escrevendo plugins BAM para servir protocolos DeFi e lucrar com as taxas dos plugins.
( pedir conselhos ao 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. Hyperliquid é uma appchain ) dedicada, criada especificamente para serviços 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 muitos designs para proteger os formadores de mercado, como por exemplo:
Prioridade de proteção para ordens pendentes: as ordens de cancelamento e as ordens de maker são processadas com prioridade, evitando que os formadores de mercado sejam prejudicados por transações desfavoráveis sem estarem cientes. O "cancelamento prioritário" mencionado no Solana ACE já foi praticado pelo Hyperliquid durante muitos anos.
Garantia de 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 "verificação dupla". Por exemplo, quando há uma ordem pendente que é correspondida, o sistema puxará novamente o preço mais recente do oráculo para avaliar a margem de ambas as partes, garantindo que não haja risco devido ao atraso de preço. Isso é semelhante à atualização do oráculo pela ACE antes da execução da negociaçã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 manipulação de volume ou custos desnecessários.
O ACE/BAM da Solana ICM é, sem dúvida, uma "consulta" ao Hyperliquid. O Hyperliquid, como líder de CLOB na cadeia, implementou uma série de mecanismos amigáveis para os formadores de mercado através de uma cadeia exclusiva. Agora, a Solana espera usar cadeias genéricas e plugins modularizados para replicar esse efeito------ou seja, permitir que cada aplicação tenha um controle semelhante ao do Hyperliquid sobre a ordenação das transações.
Imitar Dois: Finalidade Imediata
( comparação de consenso existente
A Solana atualmente utiliza o Tower BFT, onde a confirmação e a finalização são probabilísticas e graduais: um bloco recebe 2/3 dos votos e é considerado "confirmado ) Confirmado (", mas precisa acumular cerca de 32 blocos subsequentes na cadeia, o que geralmente leva cerca de 13 segundos ) para ser ancorado como "finalizado ### Finalizado (". Para algumas aplicações ), como negociação de alta frequência ###, esse 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 duas rodadas de votação para confirmar blocos, alcançando a "finalidade instantânea".
Primeira rodada: pré-votação ( Prevotação ): Após os validadores receberem o bloco candidato transmitido pelo Proposer, eles farão uma validação rápida. Se a validação for bem-sucedida, cada validador emitirá um "voto de pré-votação" ( Prevotação ) e o transmitirá para toda a rede. Este voto representa: "Eu revisei preliminarmente, este bloco está ok."
Segunda rodada: Pré-submissão (Precommit): Uma vez que um validador coleta os Prevotes de mais de dois terços dos validadores sobre o mesmo bloco candidato, ele ganha confiança suficiente para acreditar que a maioria da rede se