A velocidade e o volume de transações da Solana: será que são realmente suficientes?
A Solana é conhecida pela sua alta velocidade de transações e grande volume de transações, mas isso significa que já atingiu a perfeição? Quando analisamos mais a fundo essas transações, uma questão chave surge: será que todas essas transações estão realmente a criar valor?
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ção em milissegundos para obter lucros. Esses chamados "traders tóxicos" usam vantagens tecnológicas para priorizar suas transações aumentando as taxas de Gas, fazendo com que suas transações sejam empacotadas antes das ordens de saída dos market makers, resultando em lucros arbitrários e perdas para os market makers. Para compensar essas perdas, os market makers são forçados a ampliar o spread de compra e venda, o que acaba sendo suportado por usuários comuns como custos adicionais.
A Solana sempre teve a visão de implementar um livro de ordens na cadeia, substituindo as exchanges centralizadas. No entanto, a existência de "traders tóxicos" tornou-se um obstáculo à realização desse sonho. Isso revelou novos desafios que a Solana enfrenta: o volume de transações não é igual à 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 utilizar leilões periódicos, os 'eaters' na verdade têm prioridade, o que faz com que comportamentos maliciosos de MEV (valor máximo extraível) afetem a equidade do mercado.
Especificamente, no mecanismo de consenso da Solana, as transações são ordenadas de acordo com a taxa de Gas paga em cada intervalo de 400 milissegundos (Slot), com as transações de maior oferta sendo executadas primeiro. Com esse mecanismo, os formadores de mercado precisam ajustar frequentemente suas cotações, cancelando e reemitindo ordens para se adaptar às mudanças nos preços do mercado.
Os traders de arbitragem de alta frequência monitorizam as discrepâncias de preço e, assim que detectam uma oportunidade, realizam a transação imediatamente. Eles podem pagar taxas mais altas para garantir que suas transações sejam executadas antes que os market makers cancelem as suas ordens, 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 deveria 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 micro.
Da mesma forma, em relação às cotações dos 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. No entanto, no intervalo atual de 400 milissegundos, o mercado pode levar a que as transações ainda sejam executadas ao preço original devido a flutuações acentuadas.
Para acordos de empréstimo, as melhores práticas são primeiro adicionar margem e depois proceder à liquidação.
Assim, uma solução ideal deve permitir que diferentes protocolos classifiquem as transações de acordo com suas próprias necessidades, que é o conceito de Execução Controlada por Aplicação (Application-Controlled Execution, ACE) que a Solana tem enfatizado.
Para enfrentar esses desafios, a Solana propôs a solução BAM (Mercado de Montagem de Blocos).
Mercado de montagem de blocos: a nova resposta da Solana
A BAM construiu uma camada de ordenação, ou camada de pré-processamento, entre a camada de aplicação e a mainnet da Solana. Ela utiliza ambientes de execução confiáveis (TEEs) para criar uma sandbox de privacidade, ordenando as transações dentro da sandbox de acordo com regras predefinidas ou o princípio de primeiro a entrar, primeiro a sair (FIFO).
Esta inovação visa servir melhor os protocolos como livros de ordens, bolsas de contratos perpétuos e dark pools.
Como o BAM muda o processo de transação da Solana?
No processo de negociação tradicional da Solana, após a confirmação da negociação pelo usuário, a negociação é enviada através do nó RPC para o nó líder do Slot atual, o líder coleta as transações do pool de transações, ordena e empacota em blocos para transmissão, e finalmente, outros nós votam para confirmar.
E nas aplicações que integram o BAM, o processo de transação é ligeiramente diferente:
O usuário confirma a transação
Transação enviada para o nó RPC
Transferência de transações para a rede BAM, ordenação realizada no ambiente TEE
O pacote de transações ordenado é enviado para o nó líder da mainnet Solana
O líder incorpora o pacote de dados BAM no bloco e o transmite.
Outros nós votam para confirmação
É importante notar que o BAM não conflita com o processo de consenso da mainnet Solana, mas atua como uma funcionalidade opcional. Ele realiza a ordenação das transações de forma "off-chain" e, em seguida, submete o pacote de transações ordenadas à mainnet Solana.
Modo de operação do BAM
O BAM suporta três modos de operação:
Solana modo padrão
Modo Block-Engine (atualmente a solução MEV da Jito, o núcleo é o mecanismo de licitação)
Modo BAM (validadores ordenados estritamente por FIFO)
As características principais do modo BAM incluem:
Utilizar ambientes de execução confiáveis (TEEs) para construir um ambiente de privacidade, garantindo a equidade na ordenação das transações.
Permitir que as aplicações construam lógica de ordenação de transações personalizada através do sistema de plugins, realizando necessidades de ordenação complexas.
Aplicações práticas do BAM
As aplicações do BAM são amplas, aqui estão alguns exemplos concretos:
Proteção de liquidação de empréstimos: executar prioritariamente a operação de colateral adicional e depois realizar a verificação de liquidação.
Combinação de transações a nível atómico: primeiro atualizar o preço do oráculo, e depois executar as transações que dependem desse preço; para o DEX de contratos, também é possível liquidar produtos derivados relacionados.
Proteção contra flutuações de preços: detecção de grandes ordens anormais e divisão em transações menores para execução em lotes, dando tempo de reação ao mercado
Proteção dos market makers: em caso de eventos inesperados, permite a cancelamento de ordens, atualização do preço do oráculo e reinserção de ordens em milissegundos, evitando arbitragem maliciosa.
A implementação do BAM melhorará significativamente a experiência de negociação na Solana, tornando a experiência das suas aplicações na mainnet mais próxima das das exchanges centralizadas.
De um modo geral, o BAM trouxe verificabilidade, proteção de privacidade e programabilidade ao processo de tratamento de transações da Solana. Isso permite que os desenvolvedores construam livros de ordens de limite central, bolsas de contratos perpétuos, dark pools e outras infraestruturas financeiras que exigem controle preciso de ordenação, execução determinística e proteção de privacidade, promovendo assim a inovação no ecossistema da 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
4
Compartilhar
Comentário
0/400
HappyToBeDumped
· 6h atrás
sol meus idiotas fizeram as pessoas de parvas
Ver originalResponder0
SingleForYears
· 6h atrás
Os usuários comuns arcam com os custos? Fazer as pessoas de parvas.
Ver originalResponder0
ruggedNotShrugged
· 6h atrás
lavar e dormir, sol fazer as pessoas de parvas, já estou a fazer.
A Solana lançou a solução BAM para melhorar a qualidade e a equidade das transações.
A velocidade e o volume de transações da Solana: será que são realmente suficientes?
A Solana é conhecida pela sua alta velocidade de transações e grande volume de transações, mas isso significa que já atingiu a perfeição? Quando analisamos mais a fundo essas transações, uma questão chave surge: será que todas essas transações estão realmente a criar valor?
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ção em milissegundos para obter lucros. Esses chamados "traders tóxicos" usam vantagens tecnológicas para priorizar suas transações aumentando as taxas de Gas, fazendo com que suas transações sejam empacotadas antes das ordens de saída dos market makers, resultando em lucros arbitrários e perdas para os market makers. Para compensar essas perdas, os market makers são forçados a ampliar o spread de compra e venda, o que acaba sendo suportado por usuários comuns como custos adicionais.
A Solana sempre teve a visão de implementar um livro de ordens na cadeia, substituindo as exchanges centralizadas. No entanto, a existência de "traders tóxicos" tornou-se um obstáculo à realização desse sonho. Isso revelou novos desafios que a Solana enfrenta: o volume de transações não é igual à 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 utilizar leilões periódicos, os 'eaters' na verdade têm prioridade, o que faz com que comportamentos maliciosos de MEV (valor máximo extraível) afetem a equidade do mercado.
Especificamente, no mecanismo de consenso da Solana, as transações são ordenadas de acordo com a taxa de Gas paga em cada intervalo de 400 milissegundos (Slot), com as transações de maior oferta sendo executadas primeiro. Com esse mecanismo, os formadores de mercado precisam ajustar frequentemente suas cotações, cancelando e reemitindo ordens para se adaptar às mudanças nos preços do mercado.
Os traders de arbitragem de alta frequência monitorizam as discrepâncias de preço e, assim que detectam uma oportunidade, realizam a transação imediatamente. Eles podem pagar taxas mais altas para garantir que suas transações sejam executadas antes que os market makers cancelem as suas ordens, 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 deveria 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 micro.
Da mesma forma, em relação às cotações dos 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. No entanto, no intervalo atual de 400 milissegundos, o mercado pode levar a que as transações ainda sejam executadas ao preço original devido a flutuações acentuadas.
Para acordos de empréstimo, as melhores práticas são primeiro adicionar margem e depois proceder à liquidação.
Assim, uma solução ideal deve permitir que diferentes protocolos classifiquem as transações de acordo com suas próprias necessidades, que é o conceito de Execução Controlada por Aplicação (Application-Controlled Execution, ACE) que a Solana tem enfatizado.
Para enfrentar esses desafios, a Solana propôs a solução BAM (Mercado de Montagem de Blocos).
Mercado de montagem de blocos: a nova resposta da Solana
A BAM construiu uma camada de ordenação, ou camada de pré-processamento, entre a camada de aplicação e a mainnet da Solana. Ela utiliza ambientes de execução confiáveis (TEEs) para criar uma sandbox de privacidade, ordenando as transações dentro da sandbox de acordo com regras predefinidas ou o princípio de primeiro a entrar, primeiro a sair (FIFO).
Esta inovação visa servir melhor os protocolos como livros de ordens, bolsas de contratos perpétuos e dark pools.
Como o BAM muda o processo de transação da Solana?
No processo de negociação tradicional da Solana, após a confirmação da negociação pelo usuário, a negociação é enviada através do nó RPC para o nó líder do Slot atual, o líder coleta as transações do pool de transações, ordena e empacota em blocos para transmissão, e finalmente, outros nós votam para confirmar.
E nas aplicações que integram o BAM, o processo de transação é ligeiramente diferente:
É importante notar que o BAM não conflita com o processo de consenso da mainnet Solana, mas atua como uma funcionalidade opcional. Ele realiza a ordenação das transações de forma "off-chain" e, em seguida, submete o pacote de transações ordenadas à mainnet Solana.
Modo de operação do BAM
O BAM suporta três modos de operação:
As características principais do modo BAM incluem:
Aplicações práticas do BAM
As aplicações do BAM são amplas, aqui estão alguns exemplos concretos:
A implementação do BAM melhorará significativamente a experiência de negociação na Solana, tornando a experiência das suas aplicações na mainnet mais próxima das das exchanges centralizadas.
De um modo geral, o BAM trouxe verificabilidade, proteção de privacidade e programabilidade ao processo de tratamento de transações da Solana. Isso permite que os desenvolvedores construam livros de ordens de limite central, bolsas de contratos perpétuos, dark pools e outras infraestruturas financeiras que exigem controle preciso de ordenação, execução determinística e proteção de privacidade, promovendo assim a inovação no ecossistema da Solana.