O Imitação do Solana: Conseguirá Alcançar a Hyperliquid?
Recentemente, membros importantes do ecossistema Solana, incluindo a Fundação Solana, Anza, Jito Labs, entre outros, lançaram em conjunto um roteiro técnico intitulado "Internet Capital Markets (Internet Capital Markets, ICM)". O conceito central deste roteiro é "Application Controlled Execution (Application Controlled Execution, ACE)", que visa permitir que aplicações na cadeia tenham o controle da ordem de execução de transações em milissegundos, criando uma "Wall Street descentralizada" na cadeia.
Curiosamente, ao ler todo o roteiro, embora Hyperliquid não seja mencionado diretamente, o design está praticamente alinhado com os pontos fortes da Hyperliquid em vários aspectos. É como se a Solana estivesse dizendo: "O que você tem na Hyperliquid, nós também queremos ter, e queremos fazer melhor!"
A Hyperliquid ocupa uma posição de liderança no mercado de contratos perpétuos em cadeia, com o volume de negociação a atingir cerca de 65% de todo o mercado descentralizado de contratos perpétuos. Diante de tal concorrente, a Solana claramente não está disposta a ser superada pelos recém-chegados, por isso lançou este roteiro ICM.
Então, o que realmente está acontecendo com este "show de imitações"? Será que a Solana pode realmente alcançar ou até superar a Hyperliquid? Vamos explorar este tópico 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 do Ethereum. Eles assumiram muitas tarefas cruciais de tecnologia neste roteiro, como o novo protocolo de consenso Alpenglow.
Jito Labs: Fornecedor de infraestrutura MEV em Solana, com grande influência, quase controla o "poder de vida e morte" de todo o fluxo MEV em Solana. Desta vez, eles lideraram a oferta de soluções de ordenação de transações como o Block Assembly Marketplace (BAM).
Multicoin Capital: uma renomada instituição de investimento em criptomoedas, também é um dos primeiros apoiadores da Solana. Devido à posse de uma quantidade significativa de SOL e dos direitos dos projetos do ecossistema, tem uma considerável influência na direção técnica.
DoubleZero: uma equipa focada em acelerar a comunicação em 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.
Drift: O projeto DEX de contratos perpétuos líder na Solana. Anteriormente, o Drift utilizava um modelo de correspondência off-chain, e ao enfrentar o Hyperliquid totalmente on-chain, parecia estar em desvantagem. Desta vez, ao participar da elaboração do roteiro, é evidente que espera se reerguer com a atualização da infraestrutura subjacente.
O problema central a ser resolvido
O roteiro foca na melhoria da microestrutura do mercado, ou seja, o atual mecanismo de negociação em cadeia não é amigável para os criadores de mercado, onde os Takers, que iniciam ativamente as transações, se beneficiam, enquanto os Market Makers que aguardam para concluir as ordens acabam perdendo. Isso ocorre porque os Takers geralmente têm acesso a informações mais recentes e aumentam proativamente as taxas de transação para garantir que suas negociações sejam executadas primeiro, enquanto os Makers muitas vezes não conseguem cancelar suas ordens a tempo e são 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 cadeia ainda não foi atualizado, mas o preço fora da cadeia já mudou, o arbitrador pode consumir as ordens dos formadores de mercado a um preço antigo, fazendo com que os formadores de mercado assumam as perdas. O resultado é que o Maker, para se proteger, ou amplia o spread de compra e venda, ou reduz a quantidade de ordens pendentes, o que leva a uma piora na liquidez do mercado como um todo.
O roadmap do ICM tem como objetivo equilibrar esse padrão, atraindo liquidez de alta qualidade de volta à cadeia.
( Três passos do ICM
A Solana dividiu este grande plano em três fases:
Curto prazo )1-3 meses ###: O principal objetivo é otimizar a experiência de transação em cadeia existente, tornando as aplicações de livro de ordens mais utilizáveis e reduzindo a interferência maliciosa do MEV. Especificamente inclui:
O Marketplace Block Assembly da Jito Labs(BAM) foi lançado na mainnet. O significado deste módulo é fornecer um sistema externo temporário antes do lançamento do ACE(Application Controlled Execution), 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 slippage 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 uma rede de alta velocidade dedicada e um novo 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 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 aproximadamente 0,15 segundos.
Desenvolvimento de Execução de Programas Assíncronos (Execução de Programa Assíncrono, APE ), reduz o bloqueio da execução de transações na consensualidade.
Longo prazo (9-30 meses ): Revolucionar a arquitetura central da Solana, com o objetivo de alcançar até 2027:
Vários Líderes Concurrentes (Multiple Concurrent Leaders, MCL): Permite que vários validadores proponham transações simultaneamente em seus próprios pipelines e, em seguida, classifiquem e unam 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ções nativas (Application Controlled Execution, ACE) funcionalidade: realmente confere ao contrato inteligente na cadeia o poder de controlar a ordem de execução das transações.
Analisando até aqui, a proposta do roteiro ICM desta vez, a história por trás deve ser a seguinte: o velho DEX Drift na Solana foi superado pelo recém-chegado Hyperliquid com a excelente experiência de "Binance On-Chain". O Drift, incapaz de competir, teve que pedir ajuda aos "grandes" como Solana Labs, Anza e Jito. Os "grandes" apresentaram um plano de reforma técnica ICM, afirmando que iriam replicar todas as habilidades essenciais do Hyperliquid para o Drift, ajudando-o a lutar novamente no mercado de DEX. No entanto, os "grandes" também disseram que esta 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 poderiam fornecer ao Drift por enquanto seria o BAM do Jito, permitindo que o Drift se virasse, enquanto compara com o Hyperliquid.
Clarificado o contexto da história, nos próximos capítulos, iremos analisar detalhadamente quais as habilidades que o ICM realmente imitou e reproduziu do Hyperliquid.
Imitação 1: Mecanismo de ordenação de transações
O problema é o seguinte: como mencionado anteriormente, a cadeia atual tende a favorecer os takers, enquanto os makers suportam o "fluxo tóxico". Os usuários que compram ativamente podem iniciar uma transação em relação às ordens na cadeia com base no preço mais recente fora da cadeia, e ao aumentar a taxa de transação, têm prioridade na execução, enquanto os market makers muitas vezes não conseguem atualizar ou cancelar suas ordens a tempo. O resultado é que os market makers têm que aumentar o spread ou simplesmente retirar a liquidez, o que piora a profundidade do mercado.
( A solução definitiva da ICM: execução controlada de )ACE###
O roadmap 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 cada cadeia, permitindo que as aplicações decidam como as transações relacionadas a elas devem ser ordenadas e executadas. Por exemplo, no futuro, ao implementar o ACE na Solana, os contratos DeFi podem implementar as seguintes regras de ordenação de transações personalizadas:
Atualização de preço do Oracle inserida: as aplicações DeFi podem inserir uma transação para obter o preço mais recente do oracle antes de realizar grandes transações, garantindo que as ordens sejam executadas ao preço razoável mais recente, 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 cancelar ordens pendentes a tempo em situações desfavoráveis.
Leilão de fila: Por exemplo, após uma grande ordem de compra que eleva o preço, a aplicação DeFi colocará a oportunidade "seguinte" em leilão. 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 após a 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 da 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 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 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 de preços de oráculos antes da correspondência, e 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 blockchain.
BAM pode ser visto como um campo de testes antes da implementação do ACE na blockchain, com funcionalidades muito próximas do ACE final, apenas funcionando em uma rede independente fora do protocolo da mainnet Solana.
É importante notar que a Jito anteriormente fornecia uma infraestrutura voltada para a extração de MEV (, como o Jito Block Engine ), cujo modelo de negócios é criar oportunidades para os arbitradores através da otimização da ordenação das transações e compartilhar os lucros. Isso, de certa forma, é a "lança" que se opõe 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 ( 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 e manter a equidade dos usuários.
O lançamento do BAM está em linha com este raciocínio: ele 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 retirada de ordens para evitar danos aos formadores de mercado, introduzindo incentivos de leilão para reduzir lucros de frontrunning, entre outros. Os buscadores de MEV anteriores, se quiserem ganhar dinheiro, devem mudar de papel, desenvolvendo plugins BAM para servir os protocolos DeFi, lucrando com as taxas dos plugins.
( em busca de sabedoria da HYPERLIQUID
A abordagem ACE/BAM mencionada acima pode ser vista como uma tentativa de alcançar o mecanismo de correspondência on-chain do Hyperliquid. Hyperliquid é uma Appchain) dedicada, criada especificamente para 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 do Hyperliquid são mais voltadas para os provedores de liquidez, já implementando muitas proteções para os formadores de mercado na camada da cadeia, como:
Prioridade de proteção para ordens pendentes: as ordens de cancelamento e as ordens de maker são processadas com prioridade, evitando que os market makers sejam desfavorecidos em transações sem o seu conhecimento. A "execução prioritária de cancelamentos" mencionada pela Solana ACE já é praticada 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 e do estado da margem para realizar uma "dupla verificação". Por exemplo, quando há ordens correspondidas, o sistema irá novamente buscar o preço mais recente do oráculo para avaliar as margens de ambas as partes, garantindo que não haja riscos devido a atrasos de preço. Isso é semelhante ao ACE inserindo atualizações do oráculo antes de executar a negociação.
Proteção contra auto-negociação: se o mesmo endereço comprar e vender, o Hyperliquid cancela automaticamente em vez de combinar, para prevenir manipulação de volume ou custos desnecessários.
O ACE/BAM da ICM da Solana é, sem dúvida, uma "inspiração" da Hyperliquid. A Hyperliquid, como líder em CLOB na cadeia, implementou uma série de mecanismos favoráveis aos market makers usando uma cadeia exclusiva. A Solana agora espera replicar esse efeito com uma cadeia genérica e plugins modularizados------ou seja, permitir que cada aplicativo tenha um controle sobre a ordenação das transações semelhante ao da Hyperliquid.
Imitar Dois: Finalidade Instantânea
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 é considerado "confirmado (Confirmed)" quando recebe 2/3 dos votos, mas é necessário acumular cerca de 32 blocos subsequentes na cadeia ###, o que normalmente leva cerca de 13 segundos ( para ser ancorado como "finalizado )Finalized(". Para algumas aplicações ), como a negociação 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 duas rodadas de votação para confirmar blocos, alcançando a "finalidade instantânea".
Primeira rodada: pré-votação ) Prevote (: Após o validador receber o bloco candidato transmitido pelo Proposer, ele realizará uma verificação rápida. Se a validação for bem-sucedida, cada validador emitirá um "pré-voto" ) Prevote ( e o transmitirá para toda a rede. Este voto representa: "Eu examinei preliminarmente, este bloco está ok."
Segunda rodada: pré-submissão ) Precommit (: assim que um validador coletar os Prevotes de mais de dois terços dos validadores para o mesmo bloco candidato, ele terá confiança suficiente para acreditar que a maioria dos membros da rede reconhece esse bloco. Assim, o validador emitirá um voto de "pré-submissão" ) Precommit ( mais significativo e
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.
8 gostos
Recompensa
8
7
Partilhar
Comentar
0/400
ChainSauceMaster
· 4h atrás
Os seguidores não podem se tornar os superadores.
Ver originalResponder0
EyeOfTheTokenStorm
· 11h atrás
Plágio é plágio, mas ainda apoio o sol, afinal a quantificação deve ser de alta frequência e baixa latência.
Ver originalResponder0
MetaMaskVictim
· 08-04 13:19
Ouvir você falar é como nos velhos tempos, WETH copiando o ERC20.
Ver originalResponder0
OffchainOracle
· 08-04 13:17
o sol começou a rodar novamente, certo?
Ver originalResponder0
PessimisticLayer
· 08-04 13:09
Está a imitar de novo, a eficiência é demasiado baixa.
Ver originalResponder0
UncleLiquidation
· 08-04 12:57
Copiar os deveres de casa com intensidade, é muito real.
Ver originalResponder0
MindsetExpander
· 08-04 12:56
Se a velocidade não é tão boa quanto a dos outros, então venha e aproveite!
Análise do roteiro ICM da Solana: estratégia em três etapas em comparação com a Hyperliquid
O Imitação do Solana: Conseguirá Alcançar a Hyperliquid?
Recentemente, membros importantes do ecossistema Solana, incluindo a Fundação Solana, Anza, Jito Labs, entre outros, lançaram em conjunto um roteiro técnico intitulado "Internet Capital Markets (Internet Capital Markets, ICM)". O conceito central deste roteiro é "Application Controlled Execution (Application Controlled Execution, ACE)", que visa permitir que aplicações na cadeia tenham o controle da ordem de execução de transações em milissegundos, criando uma "Wall Street descentralizada" na cadeia.
Curiosamente, ao ler todo o roteiro, embora Hyperliquid não seja mencionado diretamente, o design está praticamente alinhado com os pontos fortes da Hyperliquid em vários aspectos. É como se a Solana estivesse dizendo: "O que você tem na Hyperliquid, nós também queremos ter, e queremos fazer melhor!"
A Hyperliquid ocupa uma posição de liderança no mercado de contratos perpétuos em cadeia, com o volume de negociação a atingir cerca de 65% de todo o mercado descentralizado de contratos perpétuos. Diante de tal concorrente, a Solana claramente não está disposta a ser superada pelos recém-chegados, por isso lançou este roteiro ICM.
Então, o que realmente está acontecendo com este "show de imitações"? Será que a Solana pode realmente alcançar ou até superar a Hyperliquid? Vamos explorar este tópico 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 do Ethereum. Eles assumiram muitas tarefas cruciais de tecnologia neste roteiro, como o novo protocolo de consenso Alpenglow.
Jito Labs: Fornecedor de infraestrutura MEV em Solana, com grande influência, quase controla o "poder de vida e morte" de todo o fluxo MEV em Solana. Desta vez, eles lideraram a oferta de soluções de ordenação de transações como o Block Assembly Marketplace (BAM).
Multicoin Capital: uma renomada instituição de investimento em criptomoedas, também é um dos primeiros apoiadores da Solana. Devido à posse de uma quantidade significativa de SOL e dos direitos dos projetos do ecossistema, tem uma considerável influência na direção técnica.
DoubleZero: uma equipa focada em acelerar a comunicação em 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.
Drift: O projeto DEX de contratos perpétuos líder na Solana. Anteriormente, o Drift utilizava um modelo de correspondência off-chain, e ao enfrentar o Hyperliquid totalmente on-chain, parecia estar em desvantagem. Desta vez, ao participar da elaboração do roteiro, é evidente que espera se reerguer com a atualização da infraestrutura subjacente.
O problema central a ser resolvido
O roteiro foca na melhoria da microestrutura do mercado, ou seja, o atual mecanismo de negociação em cadeia não é amigável para os criadores de mercado, onde os Takers, que iniciam ativamente as transações, se beneficiam, enquanto os Market Makers que aguardam para concluir as ordens acabam perdendo. Isso ocorre porque os Takers geralmente têm acesso a informações mais recentes e aumentam proativamente as taxas de transação para garantir que suas negociações sejam executadas primeiro, enquanto os Makers muitas vezes não conseguem cancelar suas ordens a tempo e são 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 cadeia ainda não foi atualizado, mas o preço fora da cadeia já mudou, o arbitrador pode consumir as ordens dos formadores de mercado a um preço antigo, fazendo com que os formadores de mercado assumam as perdas. O resultado é que o Maker, para se proteger, ou amplia o spread de compra e venda, ou reduz a quantidade de ordens pendentes, o que leva a uma piora na liquidez do mercado como um todo.
O roadmap do ICM tem como objetivo equilibrar esse padrão, atraindo liquidez de alta qualidade de volta à cadeia.
( Três passos do ICM
A Solana dividiu este grande plano em três fases:
Curto prazo )1-3 meses ###: O principal objetivo é otimizar a experiência de transação em cadeia existente, tornando as aplicações de livro de ordens mais utilizáveis e reduzindo a interferência maliciosa do MEV. Especificamente inclui:
O Marketplace Block Assembly da Jito Labs(BAM) foi lançado na mainnet. O significado deste módulo é fornecer um sistema externo temporário antes do lançamento do ACE(Application Controlled Execution), 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 slippage 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 uma rede de alta velocidade dedicada e um novo 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 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 aproximadamente 0,15 segundos.
Desenvolvimento de Execução de Programas Assíncronos (Execução de Programa Assíncrono, APE ), reduz o bloqueio da execução de transações na consensualidade.
Longo prazo (9-30 meses ): Revolucionar a arquitetura central da Solana, com o objetivo de alcançar até 2027:
Vários Líderes Concurrentes (Multiple Concurrent Leaders, MCL): Permite que vários validadores proponham transações simultaneamente em seus próprios pipelines e, em seguida, classifiquem e unam 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ções nativas (Application Controlled Execution, ACE) funcionalidade: realmente confere ao contrato inteligente na cadeia o poder de controlar a ordem de execução das transações.
Analisando até aqui, a proposta do roteiro ICM desta vez, a história por trás deve ser a seguinte: o velho DEX Drift na Solana foi superado pelo recém-chegado Hyperliquid com a excelente experiência de "Binance On-Chain". O Drift, incapaz de competir, teve que pedir ajuda aos "grandes" como Solana Labs, Anza e Jito. Os "grandes" apresentaram um plano de reforma técnica ICM, afirmando que iriam replicar todas as habilidades essenciais do Hyperliquid para o Drift, ajudando-o a lutar novamente no mercado de DEX. No entanto, os "grandes" também disseram que esta 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 poderiam fornecer ao Drift por enquanto seria o BAM do Jito, permitindo que o Drift se virasse, enquanto compara com o Hyperliquid.
Clarificado o contexto da história, nos próximos capítulos, iremos analisar detalhadamente quais as habilidades que o ICM realmente imitou e reproduziu do Hyperliquid.
Imitação 1: Mecanismo de ordenação de transações
O problema é o seguinte: como mencionado anteriormente, a cadeia atual tende a favorecer os takers, enquanto os makers suportam o "fluxo tóxico". Os usuários que compram ativamente podem iniciar uma transação em relação às ordens na cadeia com base no preço mais recente fora da cadeia, e ao aumentar a taxa de transação, têm prioridade na execução, enquanto os market makers muitas vezes não conseguem atualizar ou cancelar suas ordens a tempo. O resultado é que os market makers têm que aumentar o spread ou simplesmente retirar a liquidez, o que piora a profundidade do mercado.
( A solução definitiva da ICM: execução controlada de )ACE###
O roadmap 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 cada cadeia, permitindo que as aplicações decidam como as transações relacionadas a elas devem ser ordenadas e executadas. Por exemplo, no futuro, ao implementar o ACE na Solana, os contratos DeFi podem implementar as seguintes regras de ordenação de transações personalizadas:
Atualização de preço do Oracle inserida: as aplicações DeFi podem inserir uma transação para obter o preço mais recente do oracle antes de realizar grandes transações, garantindo que as ordens sejam executadas ao preço razoável mais recente, 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 cancelar ordens pendentes a tempo em situações desfavoráveis.
Leilão de fila: Por exemplo, após uma grande ordem de compra que eleva o preço, a aplicação DeFi colocará a oportunidade "seguinte" em leilão. 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 após a 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 da 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 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 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 de preços de oráculos antes da correspondência, e 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 blockchain.
BAM pode ser visto como um campo de testes antes da implementação do ACE na blockchain, com funcionalidades muito próximas do ACE final, apenas funcionando em uma rede independente fora do protocolo da mainnet Solana.
É importante notar que a Jito anteriormente fornecia uma infraestrutura voltada para a extração de MEV (, como o Jito Block Engine ), cujo modelo de negócios é criar oportunidades para os arbitradores através da otimização da ordenação das transações e compartilhar os lucros. Isso, de certa forma, é a "lança" que se opõe 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 ( 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 e manter a equidade dos usuários.
O lançamento do BAM está em linha com este raciocínio: ele 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 retirada de ordens para evitar danos aos formadores de mercado, introduzindo incentivos de leilão para reduzir lucros de frontrunning, entre outros. Os buscadores de MEV anteriores, se quiserem ganhar dinheiro, devem mudar de papel, desenvolvendo plugins BAM para servir os protocolos DeFi, lucrando com as taxas dos plugins.
( em busca de sabedoria da HYPERLIQUID
A abordagem ACE/BAM mencionada acima pode ser vista como uma tentativa de alcançar o mecanismo de correspondência on-chain do Hyperliquid. Hyperliquid é uma Appchain) dedicada, criada especificamente para 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 do Hyperliquid são mais voltadas para os provedores de liquidez, já implementando muitas proteções para os formadores de mercado na camada da cadeia, como:
Prioridade de proteção para ordens pendentes: as ordens de cancelamento e as ordens de maker são processadas com prioridade, evitando que os market makers sejam desfavorecidos em transações sem o seu conhecimento. A "execução prioritária de cancelamentos" mencionada pela Solana ACE já é praticada 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 e do estado da margem para realizar uma "dupla verificação". Por exemplo, quando há ordens correspondidas, o sistema irá novamente buscar o preço mais recente do oráculo para avaliar as margens de ambas as partes, garantindo que não haja riscos devido a atrasos de preço. Isso é semelhante ao ACE inserindo atualizações do oráculo antes de executar a negociação.
Proteção contra auto-negociação: se o mesmo endereço comprar e vender, o Hyperliquid cancela automaticamente em vez de combinar, para prevenir manipulação de volume ou custos desnecessários.
O ACE/BAM da ICM da Solana é, sem dúvida, uma "inspiração" da Hyperliquid. A Hyperliquid, como líder em CLOB na cadeia, implementou uma série de mecanismos favoráveis aos market makers usando uma cadeia exclusiva. A Solana agora espera replicar esse efeito com uma cadeia genérica e plugins modularizados------ou seja, permitir que cada aplicativo tenha um controle sobre a ordenação das transações semelhante ao da Hyperliquid.
Imitar Dois: Finalidade Instantânea
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 é considerado "confirmado (Confirmed)" quando recebe 2/3 dos votos, mas é necessário acumular cerca de 32 blocos subsequentes na cadeia ###, o que normalmente leva cerca de 13 segundos ( para ser ancorado como "finalizado )Finalized(". Para algumas aplicações ), como a negociação 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 duas rodadas de votação para confirmar blocos, alcançando a "finalidade instantânea".
Primeira rodada: pré-votação ) Prevote (: Após o validador receber o bloco candidato transmitido pelo Proposer, ele realizará uma verificação rápida. Se a validação for bem-sucedida, cada validador emitirá um "pré-voto" ) Prevote ( e o transmitirá para toda a rede. Este voto representa: "Eu examinei preliminarmente, este bloco está ok."
Segunda rodada: pré-submissão ) Precommit (: assim que um validador coletar os Prevotes de mais de dois terços dos validadores para o mesmo bloco candidato, ele terá confiança suficiente para acreditar que a maioria dos membros da rede reconhece esse bloco. Assim, o validador emitirá um voto de "pré-submissão" ) Precommit ( mais significativo e