Solana equilíbrio entre velocidade de transação e criação de valor
Solana é conhecida pela sua rápida velocidade de transações e pelo grande volume de transações, mas isso significa que já alcançou a perfeição? Quando analisamos essas transações com atenção, uma questão-chave surge: será que todas essas transações estão a criar valor real?
Na verdade, uma grande parte das transações na Solana não provém de uma demanda real por transações. Uma parte considerável vem de arbitradores de alta frequência, que aproveitam a diferença de informações em milissegundos para obter lucros. Esses chamados "traders tóxicos" utilizam uma vantagem tecnológica para priorizar suas transações, aumentando as taxas de Gas quando os market makers estão prestes a cancelar ordens, completando assim a arbitragem, e fazendo com que os market makers suportem prejuízos. Para compensar essas perdas, os market makers são obrigados a aumentar o spread de compra e venda, e, no final, são os usuários comuns que arcam com esses custos adicionais.
A Solana sempre teve a visão de implementar um livro de ordens na cadeia, substituindo as exchanges centralizadas. No entanto, a presença de "traders tóxicos" tornou-se o principal obstáculo para alcançar esse objetivo. Este é o novo desafio que a Solana enfrenta atualmente: o volume de transações não é equivalente à liquidez. Um mercado verdadeiramente saudável não precisa de mais transações, mas sim de transações de maior qualidade.
Como eliminar transações tóxicas e proteger melhor a liquidez?
No sistema atual, devido ao mecanismo de consenso da Solana adotar leilões periódicos, os que fazem ordens de compra têm, na prática, prioridade, o que leva a comportamentos maliciosos de MEV (valor extraível pelo minerador) que afetam a equidade do mercado.
Especificamente, no mecanismo de consenso da Solana, as transações dentro de cada intervalo de tempo (Slot) são ordenadas de acordo com a taxa de Gas paga, com as transações que oferecem o maior preço sendo executadas primeiro. Este mecanismo de leilão ocorre a cada 400 milissegundos. Durante esse processo, os formadores de mercado precisam ajustar frequentemente suas ofertas, incluindo cancelar e recriar ordens, para se adaptar às mudanças nos preços do mercado.
Os que fazem arbitragem, especialmente os de alta frequência, monitorizam constantemente as diferenças de preço e, assim que detectam uma oportunidade, realizam a transação imediatamente. Eles podem garantir que a transação seja concluída antes que os market makers cancelem as ordens, ao pagarem taxas mais altas, o que leva os market makers a sofrerem frequentemente perdas.
Para uma exchange descentralizada (DEX) com livro de ordens, a ordem de execução ideal das transações deve ser: com a flutuação dos preços, primeiro executar todas as operações de cancelamento, depois as novas ordens de venda e, por último, as transações. No entanto, o mecanismo de consenso atual da Solana não consegue realizar isso em um nível microscópico.
O mesmo problema existe no nível das cotações dos oráculos. Idealmente, os preços dos oráculos devem ser atualizados primeiro, antes de executar transações que dependem desse preço. Mas, no intervalo atual de 400 milissegundos, o mercado pode levar a que as transações ainda sejam realizadas ao preço original devido a flutuações acentuadas.
Para protocolos de empréstimo, a melhor ordem de operação deve ser primeiro adicionar margem e, em seguida, liquidar.
Portanto, Solana precisa de um mecanismo que permita a diferentes protocolos ordenar transações com base em suas necessidades específicas. Este é o conceito de Execução Controlada por Aplicações (Application-Controlled Execution, ACE) que a Solana tem enfatizado.
Para resolver esses problemas, a Solana propôs a solução BAM (Mercado de Montagem de Blocos).
BAM: A nova resposta da Solana
BAM construiu uma camada de ordenação entre a camada de aplicação e a rede principal da Solana, que também pode ser chamada de camada de pré-processamento. Ela utiliza ambientes de execução confiáveis (TEEs) para construir uma sandbox de privacidade, onde as transações são ordenadas de acordo com regras pré-determinadas ou pelo princípio de primeiro a entrar, primeiro a sair (FIFO).
Esta inovação visa servir melhor protocolos como livros de ordens, exchanges de contratos perpétuos e dark pools.
Comparação entre o processamento de transações tradicionais da Solana e o modo BAM
Para entender melhor como o BAM constrói uma camada de ordenação entre aplicações e a mainnet da Solana, podemos comparar o fluxo de transações tradicional da Solana com o fluxo após a adoção do BAM:
Processo de negociação tradicional Solana:
O usuário confirma a transação na carteira
Transação enviada para o nó RPC
RPC envia a transação para o nó Leader da mainnet Solana no período atual
O líder coleta as transações do pool de transações, classifica, empacota em blocos e transmite.
Votação de outros nós
Processo de transação após a adoção do BAM:
O usuário confirma a transação na carteira
Transação enviada para o nó RPC
Transação encaminhada para a rede BAM, ordenada no ambiente TEE. Durante este período, os nós podem adicionar transações adicionais através de plugins (como atualizar preços de oráculos), e então gerar provas.
O pacote de dados da transação é submetido ao nó Leader da mainnet Solana
O líder inclui pacotes de dados BAM ao coletar transações, empacotando-os em blocos e transmitindo.
Outros nós votam
É importante notar que o BAM não entra em conflito com o processo de consenso da rede principal Solana, mas funciona como uma funcionalidade opcional. O BAM não opera diretamente na rede principal Solana, mas realiza a ordenação das transações "fora da cadeia" antes de agrupar as transações e enviá-las para a rede principal Solana.
Modo de ordenação de transações do BAM
BAM suporta três modos de operação:
Solana modo padrão
Modo Block-Engine: A solução MEV atual da Jito, cujo núcleo é o mecanismo de leilão.
Modo BAM: os validadores ordenam rigorosamente de acordo com o princípio de primeiro a entrar, primeiro a sair (FIFO)
As características principais do modo BAM incluem:
Ambientes de Execução Confiáveis (TEEs): utilizar TEEs para construir um ambiente de privacidade para ordenar transações, garantindo a equidade.
Sistema de plugins: Através do sistema de plugins, o BAM permite que as aplicações construam lógica de ordenação de transações personalizada. Esta ordenação personalizada baseia-se em regras predefinidas, em vez da ordenação aleatória dos nós. O sistema de plugins planeja implementar uma ordenação complexa de transações, mantendo ao mesmo tempo as garantias de segurança do ambiente TEE. Atualmente, este sistema ainda se encontra em fase de desenvolvimento inicial.
Aplicações práticas do BAM
As aplicações práticas do BAM incluem:
Proteção de liquidação de empréstimos: para os contratos de empréstimo, após detectar risco de liquidação, priorizar a execução de operações de colateral adicional, antes de realizar a verificação de liquidação.
Combinações de transações em nível atômico: para DEX, primeiro atualize o preço do oráculo e, em seguida, execute as transações que dependem desse preço. Para DEX de contratos, também é possível liquidar produtos derivados dentro da mesma janela de tempo.
Proteção contra a volatilidade de preços: Para DEX, detectar grandes ordens anormais e dividi-las em transações menores para execução em lotes, dando ao mercado tempo suficiente para reagir, evitando espirais de morte causadas por liquidações em cadeia ou arbitragem.
Proteção do market maker: Durante eventos imprevistos, é capaz de completar operações de cancelamento de ordens, atualização de preços de oráculo, e re-listagem de ordens pelo market maker em milissegundos, evitando ser alvo de arbitragem maliciosa e reduzindo o spread.
Com a implementação do BAM, espera-se que a experiência de negociação da Solana melhore significativamente, tornando a experiência das aplicações na sua mainnet mais próxima das exchanges centralizadas.
No geral, o BAM trouxe verificabilidade, proteção de privacidade e programabilidade ao processo de processamento de transações da Solana. Isso permite que os desenvolvedores construam livros de ordens centrais com limite, exchanges de contratos perpétuos, dark pools e outras infraestruturas financeiras que exigem controle de ordenação, execução determinística e garantias de privacidade, impulsionando 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.
9 Curtidas
Recompensa
9
6
Repostar
Compartilhar
Comentário
0/400
blockBoy
· 2h atrás
Ser enganado por idiotas não tem a ver com a velocidade.
Ver originalResponder0
shadowy_supercoder
· 2h atrás
Brincar com palavras é ser explorado e ainda assim se chamar de inovação.
Ver originalResponder0
ThreeHornBlasts
· 2h atrás
Não passa de um tumor rápido.
Ver originalResponder0
SchrödingersNode
· 2h atrás
Alta frequência de armadilha de cachorro, muito enganador.
Ver originalResponder0
AirdropHunter
· 2h atrás
armadilha armadilha armadilha! Arbitragem em terra firme e está tudo resolvido.
Solução BAM da Solana: equilibrar transações rápidas com a criação de valor real
Solana equilíbrio entre velocidade de transação e criação de valor
Solana é conhecida pela sua rápida velocidade de transações e pelo grande volume de transações, mas isso significa que já alcançou a perfeição? Quando analisamos essas transações com atenção, uma questão-chave surge: será que todas essas transações estão a criar valor real?
Na verdade, uma grande parte das transações na Solana não provém de uma demanda real por transações. Uma parte considerável vem de arbitradores de alta frequência, que aproveitam a diferença de informações em milissegundos para obter lucros. Esses chamados "traders tóxicos" utilizam uma vantagem tecnológica para priorizar suas transações, aumentando as taxas de Gas quando os market makers estão prestes a cancelar ordens, completando assim a arbitragem, e fazendo com que os market makers suportem prejuízos. Para compensar essas perdas, os market makers são obrigados a aumentar o spread de compra e venda, e, no final, são os usuários comuns que arcam com esses custos adicionais.
A Solana sempre teve a visão de implementar um livro de ordens na cadeia, substituindo as exchanges centralizadas. No entanto, a presença de "traders tóxicos" tornou-se o principal obstáculo para alcançar esse objetivo. Este é o novo desafio que a Solana enfrenta atualmente: o volume de transações não é equivalente à liquidez. Um mercado verdadeiramente saudável não precisa de mais transações, mas sim de transações de maior qualidade.
Como eliminar transações tóxicas e proteger melhor a liquidez?
No sistema atual, devido ao mecanismo de consenso da Solana adotar leilões periódicos, os que fazem ordens de compra têm, na prática, prioridade, o que leva a comportamentos maliciosos de MEV (valor extraível pelo minerador) que afetam a equidade do mercado.
Especificamente, no mecanismo de consenso da Solana, as transações dentro de cada intervalo de tempo (Slot) são ordenadas de acordo com a taxa de Gas paga, com as transações que oferecem o maior preço sendo executadas primeiro. Este mecanismo de leilão ocorre a cada 400 milissegundos. Durante esse processo, os formadores de mercado precisam ajustar frequentemente suas ofertas, incluindo cancelar e recriar ordens, para se adaptar às mudanças nos preços do mercado.
Os que fazem arbitragem, especialmente os de alta frequência, monitorizam constantemente as diferenças de preço e, assim que detectam uma oportunidade, realizam a transação imediatamente. Eles podem garantir que a transação seja concluída antes que os market makers cancelem as ordens, ao pagarem taxas mais altas, o que leva os market makers a sofrerem frequentemente perdas.
Para uma exchange descentralizada (DEX) com livro de ordens, a ordem de execução ideal das transações deve ser: com a flutuação dos preços, primeiro executar todas as operações de cancelamento, depois as novas ordens de venda e, por último, as transações. No entanto, o mecanismo de consenso atual da Solana não consegue realizar isso em um nível microscópico.
O mesmo problema existe no nível das cotações dos oráculos. Idealmente, os preços dos oráculos devem ser atualizados primeiro, antes de executar transações que dependem desse preço. Mas, no intervalo atual de 400 milissegundos, o mercado pode levar a que as transações ainda sejam realizadas ao preço original devido a flutuações acentuadas.
Para protocolos de empréstimo, a melhor ordem de operação deve ser primeiro adicionar margem e, em seguida, liquidar.
Portanto, Solana precisa de um mecanismo que permita a diferentes protocolos ordenar transações com base em suas necessidades específicas. Este é o conceito de Execução Controlada por Aplicações (Application-Controlled Execution, ACE) que a Solana tem enfatizado.
Para resolver esses problemas, a Solana propôs a solução BAM (Mercado de Montagem de Blocos).
BAM: A nova resposta da Solana
BAM construiu uma camada de ordenação entre a camada de aplicação e a rede principal da Solana, que também pode ser chamada de camada de pré-processamento. Ela utiliza ambientes de execução confiáveis (TEEs) para construir uma sandbox de privacidade, onde as transações são ordenadas de acordo com regras pré-determinadas ou pelo princípio de primeiro a entrar, primeiro a sair (FIFO).
Esta inovação visa servir melhor protocolos como livros de ordens, exchanges de contratos perpétuos e dark pools.
Comparação entre o processamento de transações tradicionais da Solana e o modo BAM
Para entender melhor como o BAM constrói uma camada de ordenação entre aplicações e a mainnet da Solana, podemos comparar o fluxo de transações tradicional da Solana com o fluxo após a adoção do BAM:
Processo de negociação tradicional Solana:
Processo de transação após a adoção do BAM:
É importante notar que o BAM não entra em conflito com o processo de consenso da rede principal Solana, mas funciona como uma funcionalidade opcional. O BAM não opera diretamente na rede principal Solana, mas realiza a ordenação das transações "fora da cadeia" antes de agrupar as transações e enviá-las para a rede principal Solana.
Modo de ordenação de transações do BAM
BAM suporta três modos de operação:
As características principais do modo BAM incluem:
Ambientes de Execução Confiáveis (TEEs): utilizar TEEs para construir um ambiente de privacidade para ordenar transações, garantindo a equidade.
Sistema de plugins: Através do sistema de plugins, o BAM permite que as aplicações construam lógica de ordenação de transações personalizada. Esta ordenação personalizada baseia-se em regras predefinidas, em vez da ordenação aleatória dos nós. O sistema de plugins planeja implementar uma ordenação complexa de transações, mantendo ao mesmo tempo as garantias de segurança do ambiente TEE. Atualmente, este sistema ainda se encontra em fase de desenvolvimento inicial.
Aplicações práticas do BAM
As aplicações práticas do BAM incluem:
Proteção de liquidação de empréstimos: para os contratos de empréstimo, após detectar risco de liquidação, priorizar a execução de operações de colateral adicional, antes de realizar a verificação de liquidação.
Combinações de transações em nível atômico: para DEX, primeiro atualize o preço do oráculo e, em seguida, execute as transações que dependem desse preço. Para DEX de contratos, também é possível liquidar produtos derivados dentro da mesma janela de tempo.
Proteção contra a volatilidade de preços: Para DEX, detectar grandes ordens anormais e dividi-las em transações menores para execução em lotes, dando ao mercado tempo suficiente para reagir, evitando espirais de morte causadas por liquidações em cadeia ou arbitragem.
Proteção do market maker: Durante eventos imprevistos, é capaz de completar operações de cancelamento de ordens, atualização de preços de oráculo, e re-listagem de ordens pelo market maker em milissegundos, evitando ser alvo de arbitragem maliciosa e reduzindo o spread.
Com a implementação do BAM, espera-se que a experiência de negociação da Solana melhore significativamente, tornando a experiência das aplicações na sua mainnet mais próxima das exchanges centralizadas.
No geral, o BAM trouxe verificabilidade, proteção de privacidade e programabilidade ao processo de processamento de transações da Solana. Isso permite que os desenvolvedores construam livros de ordens centrais com limite, exchanges de contratos perpétuos, dark pools e outras infraestruturas financeiras que exigem controle de ordenação, execução determinística e garantias de privacidade, impulsionando assim o desenvolvimento inovador do ecossistema Solana.