Solana já é rápido o suficiente, com volume grande o suficiente. Então, realmente é "suficiente"?
Quando examinamos aquelas transações, há uma questão que persiste: essas transações realmente estão a criar valor?
O grande volume de transações de Solana não vem de uma demanda de negociação real, mas sim de arbitradores de alta frequência que aproveitam a diferença de informação em milissegundos para obter lucro. Esses "traders tóxicos" (Toxic-takers) utilizam uma vantagem técnica, aumentando o Gas quando os criadores de mercado (Maker) estão prestes a cancelar suas ordens, fazendo com que suas transações sejam processadas primeiro, completando a arbitragem e causando perdas aos criadores de mercado. Para compensar as perdas, os criadores de mercado só podem aumentar o spread de compra e venda.
No final, os usuários comuns pagam por isso. Solana sempre teve o sonho de implementar um livro de ordens na cadeia, substituindo o CEX. Mas, assim, os "traders tóxicos" tornaram-se um obstáculo para a realização desse sonho. Esse é o novo desafio que Solana enfrenta: volume ≠ liquidez. Um mercado verdadeiramente saudável não precisa de mais transações, mas sim de melhores transações.
Como pode-se eliminar transações tóxicas e proteger melhor a liquidez?
No sistema atual, os tomadores (Takers) desfrutam de uma prioridade real devido ao mecanismo de leilão periódico do consenso Solana, o que torna o impacto malicioso do MEV uma questão de equidade de mercado.
Como entender?
No consenso atual da Solana, dentro de cada Slot de tempo, as transações são ordenadas de acordo com a taxa de Gas prioritária paga; quem oferece mais, tem sua transação executada primeiro. Este leilão é periódico, ocorrendo a cada 400 milissegundos por Slot.
Durante este processo, os formadores de mercado precisam ajustar frequentemente as cotações, cancelar e recriar ordens. Quando o preço do mercado muda, é necessário atualizar imediatamente.
Os tomadores (Takers), especialmente os arbitradores de alta frequência, monitoram as diferenças de preços e realizam a transação assim que detectam uma oportunidade. Assim, os arbitradores podem garantir uma transação ao pagar taxas mais altas antes que a ordem seja cancelada. Isso faz com que os market makers sejam frequentemente "alvos" e suportem perdas.
Para um livro de ordens DEX, a ordenação ideal deve ser a seguinte: à medida que os preços flutuam, primeiro executar todos os cancelamentos, depois executar as novas ordens pendentes e, por último, executar as transações. Isso é algo que o consenso Solana atualmente não consegue atingir em um nível micro.
E no que diz respeito ao nível de cotações das oráculos, a situação ideal é atualizar primeiro o preço do oráculo e, em seguida, executar as transações que dependem desse preço. Mas, atualmente, dentro do intervalo de 400 milissegundos, o mercado pode sofrer grandes oscilações, fazendo com que a transação ainda seja realizada com o preço original.
Para os contratos de empréstimo, é melhor primeiro suplementar a margem e depois proceder à liquidação.
Portanto, é melhor haver uma maneira de permitir que diferentes protocolos ordenem as transações de acordo com a demanda, ou seja, a execução controlada por aplicativos (Application-Controlled Execution) que a Solana tem enfatizado.
BAM (Block Assembly Marketplace, mercado de montagem de blocos) é a resposta da Solana.
A BAM construiu uma camada de ordenação, ou camada de pré-processamento, entre a aplicação na rede Solana e a mainnet.
Utilizando Ambientes de Execução Confiáveis ( Trusted Execution Environments, TEEs ) para construir uma sandbox de privacidade, onde as transações são ordenadas com base em regras de ordenação pré-determinadas, ou FIFO (primeiro a entrar, primeiro a sair).
Servir melhor os livros de ordens (CLOBs), as exchanges de contratos perpétuos (Perpetual Exchanges) e os protocolos de dark pool.
Solana geralmente compara o empacotamento de transações com o modo BAM
Como entender que o BAM construiu uma camada de ordenação entre as aplicações Solana e a mainnet? Vamos começar com uma comparação intuitiva.
Fluxo de negociação normal da Solana,
1）O usuário confirma a transação na carteira,
2）Transação enviada para o nó RPC,
3）RPC enviado ao nó líder da mainnet Solana no período de slot atual,
4）O líder coleta as transações do pool de transações, ordena, empacota em blocos e transmite.
Votação dos restantes nós.
Se uma aplicação integrar o BAM, o fluxo de transações é o seguinte,
1）O usuário confirma a transação na carteira,
Envio de transação para o nó RPC,
Transfira a transação para a rede BAM e classifique-a na privacidade TEE. Durante o processo, os nós podem adicionar transações adicionais através de plugins, como a atualização dos preços do oráculo, e em seguida gerar provas.
4）Os pacotes de dados de transação são enviados para o nó Leader da mainnet Solana,
5）O líder coleta transações, coleta o pacote de dados BAM, e o empacota em blocos para transmissão,
Votação dos restantes nós.
Portanto, na verdade, o BAM não entra em conflito com o processo de consenso da atual rede principal Solana, mas atua como uma "opcionalidade". O BAM não funciona diretamente na rede principal Solana, mas sim de uma maneira chamada "off-chain", onde a ordenação das transações é realizada antecipadamente, as transações são empacotadas e depois submetidas à rede principal Solana.
BAM volume ordenação de modo
BAM suporta três modos de operação,
1）Solana modo padrão；
2）Modo Block-Engine; a atual solução MEV da Jito, cujo núcleo é o mecanismo de licitação.
3）Modo BAM, os validadores seguem rigorosamente a ordem FIFO (primeiro a entrar, primeiro a sair).
O núcleo do modo BAM tem os seguintes pontos,
Ambientes de Execução Confiáveis TEEs: Privacidade e Equidade Utilizando Ambientes de Execução Confiáveis TEEs, construir um ambiente de privacidade para classificar transações. O outro lado da privacidade é chamado de equidade.
2）Sistema de plugins Plugin: Ordenação complexa Através do sistema de plugins, o BAM permite que as aplicações construam lógica de ordenação de transações personalizada. E essa ordenação personalizada não significa que os nós podem ordenar como quiserem, mas sim que é feita de acordo com regras previamente estabelecidas.
O plano do plugin implementa uma ordenação de transações complexa, ao mesmo tempo que mantém as garantias de segurança do ambiente TEE. Atualmente, está na fase de desenvolvimento inicial.
Como mencionado anteriormente,
Para o livro de ordens DEX, a ordenação ideal deve ser a seguinte: com as flutuações de preço, primeiro executar todos os cancelamentos, depois executar as novas ordens pendentes e, por último, executar as transações. Isso é algo que o consenso da Solana atualmente não consegue fazer em um nível micro.
E no que diz respeito à camada de preços dos oráculos, a situação é a mesma. O cenário ideal é atualizar primeiro o preço do oráculo e, em seguida, executar as transações que dependem desse preço. Mas, no atual intervalo de 400 milissegundos, o mercado pode sofrer flutuações bruscas, fazendo com que a execução ocorra ainda ao preço original.
Para acordos de empréstimo, é melhor primeiro adicionar margem e, em seguida, proceder à liquidação. Isso realmente implementa a funcionalidade de controle de execução da aplicação ACE.
Então, o que é que o BAM realmente realizou?
Por exemplo,
1）Proteção de liquidação de empréstimos
Para os protocolos de empréstimo, após detectar riscos de liquidação, priorizar a execução de operações de colaterais adicionais, antes de realizar a verificação de liquidação.
2）combinação de transações em nível atômico
Para DEX, primeiro atualize o preço do oráculo e execute as transações que dependem desse preço. Se for um DEX de contrato, também é possível liquidar os derivados relacionados. Todas as operações acima devem ser concluídas dentro da mesma janela de tempo.
3）Proteção contra flutuações de preços
Para DEX, detetar grandes ordens anormais, dividir grandes ordens em pequenos blocos, executar em lotes, dando tempo de reação ao mercado, evitando uma espiral de morte causada por liquidações em cadeia ou arbitragem.
Proteção do Market Maker
Um evento inesperado ocorre, a ordem é cancelada em milissegundos, o oráculo atualiza o preço, e o formador de mercado reinicia a ordem. Evitar a arbitragem maliciosa e reduzir o spread.
BAM estava previsto para ser lançado no final de julho.
Além disso, com a implantação do BAM, a experiência de negociação na Solana será significativamente melhorada. O BAM tornará a experiência das aplicações da mainnet Solana mais próxima das CEX.
Em suma,
O BAM trouxe verificabilidade, proteção de privacidade e programabilidade ao processo de tratamento de transações da Solana, permitindo que os desenvolvedores construam livros de ordens de limite central (CLOBs), exchanges de contratos perpétuos (Perpetual Exchanges), pools escuras (Dark Pools) e outras infraestruturas financeiras que necessitam de controle de ordenação, execução determinística e proteção de privacidade, promovendo assim o desenvolvimento inovador do ecossistema Solana.
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.
Interpretação do mercado de montagem de blocos BAM Solana: quando a velocidade já não é a única busca
Solana já é rápido o suficiente, com volume grande o suficiente. Então, realmente é "suficiente"?
Quando examinamos aquelas transações, há uma questão que persiste: essas transações realmente estão a criar valor?
O grande volume de transações de Solana não vem de uma demanda de negociação real, mas sim de arbitradores de alta frequência que aproveitam a diferença de informação em milissegundos para obter lucro. Esses "traders tóxicos" (Toxic-takers) utilizam uma vantagem técnica, aumentando o Gas quando os criadores de mercado (Maker) estão prestes a cancelar suas ordens, fazendo com que suas transações sejam processadas primeiro, completando a arbitragem e causando perdas aos criadores de mercado. Para compensar as perdas, os criadores de mercado só podem aumentar o spread de compra e venda.
No final, os usuários comuns pagam por isso. Solana sempre teve o sonho de implementar um livro de ordens na cadeia, substituindo o CEX. Mas, assim, os "traders tóxicos" tornaram-se um obstáculo para a realização desse sonho. Esse é o novo desafio que Solana enfrenta: volume ≠ liquidez. Um mercado verdadeiramente saudável não precisa de mais transações, mas sim de melhores transações.
Como pode-se eliminar transações tóxicas e proteger melhor a liquidez?
No sistema atual, os tomadores (Takers) desfrutam de uma prioridade real devido ao mecanismo de leilão periódico do consenso Solana, o que torna o impacto malicioso do MEV uma questão de equidade de mercado.
Como entender?
No consenso atual da Solana, dentro de cada Slot de tempo, as transações são ordenadas de acordo com a taxa de Gas prioritária paga; quem oferece mais, tem sua transação executada primeiro. Este leilão é periódico, ocorrendo a cada 400 milissegundos por Slot.
Durante este processo, os formadores de mercado precisam ajustar frequentemente as cotações, cancelar e recriar ordens. Quando o preço do mercado muda, é necessário atualizar imediatamente.
Os tomadores (Takers), especialmente os arbitradores de alta frequência, monitoram as diferenças de preços e realizam a transação assim que detectam uma oportunidade. Assim, os arbitradores podem garantir uma transação ao pagar taxas mais altas antes que a ordem seja cancelada. Isso faz com que os market makers sejam frequentemente "alvos" e suportem perdas.
Para um livro de ordens DEX, a ordenação ideal deve ser a seguinte: à medida que os preços flutuam, primeiro executar todos os cancelamentos, depois executar as novas ordens pendentes e, por último, executar as transações. Isso é algo que o consenso Solana atualmente não consegue atingir em um nível micro.
E no que diz respeito ao nível de cotações das oráculos, a situação ideal é atualizar primeiro o preço do oráculo e, em seguida, executar as transações que dependem desse preço. Mas, atualmente, dentro do intervalo de 400 milissegundos, o mercado pode sofrer grandes oscilações, fazendo com que a transação ainda seja realizada com o preço original.
Para os contratos de empréstimo, é melhor primeiro suplementar a margem e depois proceder à liquidação.
Portanto, é melhor haver uma maneira de permitir que diferentes protocolos ordenem as transações de acordo com a demanda, ou seja, a execução controlada por aplicativos (Application-Controlled Execution) que a Solana tem enfatizado.
BAM (Block Assembly Marketplace, mercado de montagem de blocos) é a resposta da Solana.
A BAM construiu uma camada de ordenação, ou camada de pré-processamento, entre a aplicação na rede Solana e a mainnet.
Utilizando Ambientes de Execução Confiáveis ( Trusted Execution Environments, TEEs ) para construir uma sandbox de privacidade, onde as transações são ordenadas com base em regras de ordenação pré-determinadas, ou FIFO (primeiro a entrar, primeiro a sair).
Servir melhor os livros de ordens (CLOBs), as exchanges de contratos perpétuos (Perpetual Exchanges) e os protocolos de dark pool.
Solana geralmente compara o empacotamento de transações com o modo BAM
Como entender que o BAM construiu uma camada de ordenação entre as aplicações Solana e a mainnet? Vamos começar com uma comparação intuitiva.
Fluxo de negociação normal da Solana,
1）O usuário confirma a transação na carteira,
2）Transação enviada para o nó RPC,
3）RPC enviado ao nó líder da mainnet Solana no período de slot atual,
4）O líder coleta as transações do pool de transações, ordena, empacota em blocos e transmite.
Se uma aplicação integrar o BAM, o fluxo de transações é o seguinte,
1）O usuário confirma a transação na carteira,
Envio de transação para o nó RPC,
Transfira a transação para a rede BAM e classifique-a na privacidade TEE. Durante o processo, os nós podem adicionar transações adicionais através de plugins, como a atualização dos preços do oráculo, e em seguida gerar provas.
4）Os pacotes de dados de transação são enviados para o nó Leader da mainnet Solana,
5）O líder coleta transações, coleta o pacote de dados BAM, e o empacota em blocos para transmissão,
Portanto, na verdade, o BAM não entra em conflito com o processo de consenso da atual rede principal Solana, mas atua como uma "opcionalidade". O BAM não funciona diretamente na rede principal Solana, mas sim de uma maneira chamada "off-chain", onde a ordenação das transações é realizada antecipadamente, as transações são empacotadas e depois submetidas à rede principal Solana.
BAM volume ordenação de modo
BAM suporta três modos de operação,
1）Solana modo padrão；
2）Modo Block-Engine; a atual solução MEV da Jito, cujo núcleo é o mecanismo de licitação.
3）Modo BAM, os validadores seguem rigorosamente a ordem FIFO (primeiro a entrar, primeiro a sair).
O núcleo do modo BAM tem os seguintes pontos,
2）Sistema de plugins Plugin: Ordenação complexa Através do sistema de plugins, o BAM permite que as aplicações construam lógica de ordenação de transações personalizada. E essa ordenação personalizada não significa que os nós podem ordenar como quiserem, mas sim que é feita de acordo com regras previamente estabelecidas.
O plano do plugin implementa uma ordenação de transações complexa, ao mesmo tempo que mantém as garantias de segurança do ambiente TEE. Atualmente, está na fase de desenvolvimento inicial.
Como mencionado anteriormente,
Para o livro de ordens DEX, a ordenação ideal deve ser a seguinte: com as flutuações de preço, primeiro executar todos os cancelamentos, depois executar as novas ordens pendentes e, por último, executar as transações. Isso é algo que o consenso da Solana atualmente não consegue fazer em um nível micro.
E no que diz respeito à camada de preços dos oráculos, a situação é a mesma. O cenário ideal é atualizar primeiro o preço do oráculo e, em seguida, executar as transações que dependem desse preço. Mas, no atual intervalo de 400 milissegundos, o mercado pode sofrer flutuações bruscas, fazendo com que a execução ocorra ainda ao preço original.
Para acordos de empréstimo, é melhor primeiro adicionar margem e, em seguida, proceder à liquidação. Isso realmente implementa a funcionalidade de controle de execução da aplicação ACE.
Então, o que é que o BAM realmente realizou?
Por exemplo,
1）Proteção de liquidação de empréstimos
Para os protocolos de empréstimo, após detectar riscos de liquidação, priorizar a execução de operações de colaterais adicionais, antes de realizar a verificação de liquidação.
2）combinação de transações em nível atômico
Para DEX, primeiro atualize o preço do oráculo e execute as transações que dependem desse preço. Se for um DEX de contrato, também é possível liquidar os derivados relacionados. Todas as operações acima devem ser concluídas dentro da mesma janela de tempo.
3）Proteção contra flutuações de preços
Para DEX, detetar grandes ordens anormais, dividir grandes ordens em pequenos blocos, executar em lotes, dando tempo de reação ao mercado, evitando uma espiral de morte causada por liquidações em cadeia ou arbitragem.
Um evento inesperado ocorre, a ordem é cancelada em milissegundos, o oráculo atualiza o preço, e o formador de mercado reinicia a ordem. Evitar a arbitragem maliciosa e reduzir o spread.
BAM estava previsto para ser lançado no final de julho.
Além disso, com a implantação do BAM, a experiência de negociação na Solana será significativamente melhorada. O BAM tornará a experiência das aplicações da mainnet Solana mais próxima das CEX.
Em suma,
O BAM trouxe verificabilidade, proteção de privacidade e programabilidade ao processo de tratamento de transações da Solana, permitindo que os desenvolvedores construam livros de ordens de limite central (CLOBs), exchanges de contratos perpétuos (Perpetual Exchanges), pools escuras (Dark Pools) e outras infraestruturas financeiras que necessitam de controle de ordenação, execução determinística e proteção de privacidade, promovendo assim o desenvolvimento inovador do ecossistema Solana.
Acima.