Para fazer isso, devemos oferecer preços melhores do que os da Nasdaq e devemos dar ao aplicativo a capacidade de priorizar operações de cancelamento antes da execução.
Solana visa construir uma rede de negociação descentralizada que seja mais eficiente do que a NASDAQ, mas o design de blockchain existente fica aquém das expectativas, o atual criador de mercado Solana tem uma baixa taxa de vitória na corrida de cancelamento de pedidos (muito inferior aos 13% das exchanges centralizadas), e a Jito Auctions exacerba o controle do acesso estatal por um único líder, resultando em spreads crescentes. A este respeito, propõe-se reconstruir o mecanismo de consenso e introduzir vários líderes simultâneos para otimizar a ordenação de pedidos, reduzir o custo de seleção adversa dos criadores de mercado e melhorar a eficiência de preços.
O objetivo inicial da criação da Solana era construir uma blockchain suficientemente rápida e barata para que pudesse operar um livro de ordens centralizado com limite utilizável. A versão de teste da mainnet da Solana foi lançada em março de 2020 — já se passaram cinco anos e, embora tenhamos alcançado muitas conquistas, está cada vez mais claro que ainda não conseguimos atingir esse objetivo.
A infraestrutura de blockchain existente não foi projetada para transações. Se quisermos realizar a missão original da Solana, devemos voltar ao ponto de partida, partindo dos princípios mais básicos, e projetar completamente um novo mecanismo de consenso, para no final construir uma rede descentralizada capaz de competir com a Bolsa de Valores de Nova Iorque.
O que queremos dizer ao competir com a Bolsa de Valores de Nova Iorque é que as exchanges na Solana precisam ser capazes de oferecer preços melhores do que as exchanges centralizadas. No mundo do mercado, o preço é definido pela "diferença de preço": ou seja, a diferença entre o maior preço que alguém está disposto a pagar por um ativo e o menor preço que alguém está disposto a vender o ativo.
Quanto menor for a diferença de preço, melhor será o preço obtido pelos traders, e maior será a eficiência do mercado.
A fórmula para o spread é simples. Os spreads são fixados de tal forma que o lucro esperado que um criador de mercado receberá da negociação com um operador que não seja responsável pela informação seja igual à perda esperada em que incorreria ao negociar com um operador de informação. Quando os criadores de mercado dispõem de mais informações do que as suas contrapartes, ganham dinheiro; Quando há menos informação do que a contraparte, perdem dinheiro. Os criadores de mercado geralmente ganham um pouco de dinheiro em cada negociação com investidores de varejo, mas perdem muito se forem cobertos na direção oposta quando o preço salta violentamente (espero que com pouca frequência). Esta é a origem da frase "o comerciante pega o portão e perde a melancia".
O que determina o custo da seleção reversa?
Para entender melhor a seleção adversa, precisamos entender o que os criadores de mercado de jogos estão jogando. Os criadores de mercado tomam decisões com base num "preço justo" que muda aleatoriamente ao longo do tempo. Quando o preço justo está dentro do spread bid-ask, a cotação do criador de mercado é segura porque a contraparte não pode obter lucro comendo a cotação. Mas assim que o preço justo excede o spread bid-ask, uma corrida começa: o criador de mercado tenta cancelar o pedido o mais rápido possível, e o tomador tenta pegar o pedido desatualizado antes que o criador de mercado cancele. A expectativa de um tomador bem-sucedido é a diferença entre o preço justo e a oferta desatualizada. A chave para reduzir o atrito da seleção adversa é permitir que os criadores de mercado ganhem a corrida tanto quanto possível.
Dados de uma bolsa centralizada indicam que, após uma flutuação de preços, os market makers têm apenas 13% de probabilidade de cancelar pedidos antecipadamente.
Os criadores de mercado em bolsas centralizadas têm menos probabilidade de ganhar na corrida do cancelamento, mas ainda menos em Solana. O mecanismo de leilão Jito – que é um efeito colateral de um único proponente controlando o acesso do Estado por um longo período de tempo – torna quase impossível para os criadores de mercado vencer a corrida do cancelamento. Mesmo que o criador de mercado seja mais rápido, a verdadeira decisão é quem dá lances mais altos no leilão de Jito. Isso coloca os criadores de mercado em um dilema: eles podem pagar muito dinheiro para cancelar seus pedidos, ou deixar que outra pessoa pague um preço alto para eliminá-los. De qualquer forma, eles estavam perdendo dinheiro e tiveram que aumentar o spread como resultado.
Na prática, a atual microestrutura do mercado on-chain dá aos tomadores uma vantagem de serem pioneiros em termos de seleção adversa. Para resolver esse problema, precisamos dar ao aplicativo mais flexibilidade na ordem de transações. Se quisermos reduzir o spread, o aplicativo deve ser capaz de dar aos criadores de mercado uma vantagem inicial na corrida de cancelamento de pedidos. Uma maneira de fazer isso é introduzir uma estratégia de classificação "cancelar primeiro, preencher depois". Analisamos os blocos e processamos todos os cancelamentos antes de processar todos os takes.
Podemos implementar esta estratégia no Solana imediatamente, bastando mudar a ordem de retransmissão atual de um padrão decidido pelo líder para priorizar o processamento de transações canceladas. Mas isso não resolve o problema completamente. Se ainda for um único líder a controlar, ele ainda pode optar por ignorar as transações canceladas, e assim voltamos ao ponto de partida — os formadores de mercado ainda estarão em desvantagem na corrida para cancelar.
A única maneira de resolver este problema é introduzir múltiplos líderes em paralelo (Concurrent Leaders). Assim, se um líder bloquear a anulação de transações, você pode optar por submetê-las a outro líder.
Implementação — Ordenação de Transações
A maior questão sobre os múltiplos líderes paralelos é: Como fundimos seus respetivos blocos de transação quando há um conflito? A resposta é simples: dividimos as taxas em duas categorias: taxas de inclusão e taxas de encomenda. A taxa de inclusão é paga ao validador que contém a transação, e a taxa de classificação é paga ao protocolo (burn). Quando queremos fundir os blocos de cada líder, simplesmente pegamos a união de todas as transações para todos os blocos em um slot e ordenamos de acordo com suas taxas de classificação.
Esta medida, por si só, não é suficiente. O que realmente estamos tentando alcançar é dar ao aplicativo mais flexibilidade para controlar a ordem das transações. Mais um elemento: a chamada do sistema 'get_transaction_metadata', que permite ao programa ler a taxa de classificação para a transação com a qual interage, dando ao aplicativo uma poderosa ferramenta de controle de ordenação.
!
Implementação — Mecanismo de Consenso
Os nossos objetivos de design do mecanismo de consenso incluem:
Ligação e Cegamento (Binding & Blinding): Os líderes paralelos não podem incluir informações de blocos de outros líderes em seu próprio bloco (como ataques a transações privadas), nem podem cancelar seu próprio bloco com base no conteúdo de outros blocos de líderes (por exemplo, cancelar sua própria oferta após ver outras ofertas).
Equidade de relógio (Wallclock Fairness): Os líderes em paralelo devem submeter blocos em aproximadamente o mesmo tempo real.
A seguir está um resumo das soluções mais eficazes que desenvolvemos em colaboração com Pranav Garimidi e Joachim Neu da a16z Research:
Cada líder converterá seu bloco em fragmentos de código de correção (shreds). Assim que um número suficiente de fragmentos (superior à taxa de codificação) for recuperado, o bloco poderá ser restaurado. A recuperação parcial não é possível.
Os líderes enviam os fragmentos para os nós de retransmissão na primeira camada da árvore Turbine. Cada líder enviará seu primeiro fragmento para o retransmissor 1, o segundo fragmento para o retransmissor 2, e assim por diante. Se tudo correr bem, cada retransmissor receberá fragmentos de todos os líderes.
Após o tempo limite, o relay envia uma mensagem IHAVE assinada ao líder de consenso único, informando sobre os fragmentos recebidos.
O líder de consenso então constrói um bloco que contém essas mensagens IHAVE; se não contiver uma proporção suficiente de mensagens IHAVE, esse bloco será inválido.
O líder de consenso transmite o bloco para os validadores, que começam a alcançar consenso sobre este bloco.
Este plano satisfaz as propriedades de vinculação e ofuscação com alta probabilidade, e possui uma boa equidade de relógio, embora no futuro possam surgir planos ainda melhores.
!
Conclusão
Solana foi criado com o objetivo de superar o NASDAQ. Para fazer isso, temos que oferecer um preço melhor do que o NASDAQ. Para fazer isso, devemos dar ao aplicativo a capacidade de priorizar cancelamentos antes de fechar. Para potenciar a aplicação desta capacidade, temos de impedir que os líderes revejam unilateralmente as ordens. E para fazer isso, temos que trazer vários líderes em paralelo.
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Como a Solana pode melhorar para realizar a visão de um Nasdaq na cadeia?
**Escrito por:**Max Resnick (Anza) & Anatoly Yakovenko (Solana Labs)
Compilado por: GaryMa Wu disse blockchain
Resumo
Solana visa construir uma rede de negociação descentralizada que seja mais eficiente do que a NASDAQ, mas o design de blockchain existente fica aquém das expectativas, o atual criador de mercado Solana tem uma baixa taxa de vitória na corrida de cancelamento de pedidos (muito inferior aos 13% das exchanges centralizadas), e a Jito Auctions exacerba o controle do acesso estatal por um único líder, resultando em spreads crescentes. A este respeito, propõe-se reconstruir o mecanismo de consenso e introduzir vários líderes simultâneos para otimizar a ordenação de pedidos, reduzir o custo de seleção adversa dos criadores de mercado e melhorar a eficiência de preços.
O objetivo inicial da criação da Solana era construir uma blockchain suficientemente rápida e barata para que pudesse operar um livro de ordens centralizado com limite utilizável. A versão de teste da mainnet da Solana foi lançada em março de 2020 — já se passaram cinco anos e, embora tenhamos alcançado muitas conquistas, está cada vez mais claro que ainda não conseguimos atingir esse objetivo.
A infraestrutura de blockchain existente não foi projetada para transações. Se quisermos realizar a missão original da Solana, devemos voltar ao ponto de partida, partindo dos princípios mais básicos, e projetar completamente um novo mecanismo de consenso, para no final construir uma rede descentralizada capaz de competir com a Bolsa de Valores de Nova Iorque.
O que queremos dizer ao competir com a Bolsa de Valores de Nova Iorque é que as exchanges na Solana precisam ser capazes de oferecer preços melhores do que as exchanges centralizadas. No mundo do mercado, o preço é definido pela "diferença de preço": ou seja, a diferença entre o maior preço que alguém está disposto a pagar por um ativo e o menor preço que alguém está disposto a vender o ativo.
Quanto menor for a diferença de preço, melhor será o preço obtido pelos traders, e maior será a eficiência do mercado.
A fórmula para o spread é simples. Os spreads são fixados de tal forma que o lucro esperado que um criador de mercado receberá da negociação com um operador que não seja responsável pela informação seja igual à perda esperada em que incorreria ao negociar com um operador de informação. Quando os criadores de mercado dispõem de mais informações do que as suas contrapartes, ganham dinheiro; Quando há menos informação do que a contraparte, perdem dinheiro. Os criadores de mercado geralmente ganham um pouco de dinheiro em cada negociação com investidores de varejo, mas perdem muito se forem cobertos na direção oposta quando o preço salta violentamente (espero que com pouca frequência). Esta é a origem da frase "o comerciante pega o portão e perde a melancia".
O que determina o custo da seleção reversa?
Para entender melhor a seleção adversa, precisamos entender o que os criadores de mercado de jogos estão jogando. Os criadores de mercado tomam decisões com base num "preço justo" que muda aleatoriamente ao longo do tempo. Quando o preço justo está dentro do spread bid-ask, a cotação do criador de mercado é segura porque a contraparte não pode obter lucro comendo a cotação. Mas assim que o preço justo excede o spread bid-ask, uma corrida começa: o criador de mercado tenta cancelar o pedido o mais rápido possível, e o tomador tenta pegar o pedido desatualizado antes que o criador de mercado cancele. A expectativa de um tomador bem-sucedido é a diferença entre o preço justo e a oferta desatualizada. A chave para reduzir o atrito da seleção adversa é permitir que os criadores de mercado ganhem a corrida tanto quanto possível.
Dados de uma bolsa centralizada indicam que, após uma flutuação de preços, os market makers têm apenas 13% de probabilidade de cancelar pedidos antecipadamente.
Os criadores de mercado em bolsas centralizadas têm menos probabilidade de ganhar na corrida do cancelamento, mas ainda menos em Solana. O mecanismo de leilão Jito – que é um efeito colateral de um único proponente controlando o acesso do Estado por um longo período de tempo – torna quase impossível para os criadores de mercado vencer a corrida do cancelamento. Mesmo que o criador de mercado seja mais rápido, a verdadeira decisão é quem dá lances mais altos no leilão de Jito. Isso coloca os criadores de mercado em um dilema: eles podem pagar muito dinheiro para cancelar seus pedidos, ou deixar que outra pessoa pague um preço alto para eliminá-los. De qualquer forma, eles estavam perdendo dinheiro e tiveram que aumentar o spread como resultado.
Na prática, a atual microestrutura do mercado on-chain dá aos tomadores uma vantagem de serem pioneiros em termos de seleção adversa. Para resolver esse problema, precisamos dar ao aplicativo mais flexibilidade na ordem de transações. Se quisermos reduzir o spread, o aplicativo deve ser capaz de dar aos criadores de mercado uma vantagem inicial na corrida de cancelamento de pedidos. Uma maneira de fazer isso é introduzir uma estratégia de classificação "cancelar primeiro, preencher depois". Analisamos os blocos e processamos todos os cancelamentos antes de processar todos os takes.
Podemos implementar esta estratégia no Solana imediatamente, bastando mudar a ordem de retransmissão atual de um padrão decidido pelo líder para priorizar o processamento de transações canceladas. Mas isso não resolve o problema completamente. Se ainda for um único líder a controlar, ele ainda pode optar por ignorar as transações canceladas, e assim voltamos ao ponto de partida — os formadores de mercado ainda estarão em desvantagem na corrida para cancelar.
A única maneira de resolver este problema é introduzir múltiplos líderes em paralelo (Concurrent Leaders). Assim, se um líder bloquear a anulação de transações, você pode optar por submetê-las a outro líder.
Implementação — Ordenação de Transações
A maior questão sobre os múltiplos líderes paralelos é: Como fundimos seus respetivos blocos de transação quando há um conflito? A resposta é simples: dividimos as taxas em duas categorias: taxas de inclusão e taxas de encomenda. A taxa de inclusão é paga ao validador que contém a transação, e a taxa de classificação é paga ao protocolo (burn). Quando queremos fundir os blocos de cada líder, simplesmente pegamos a união de todas as transações para todos os blocos em um slot e ordenamos de acordo com suas taxas de classificação.
Esta medida, por si só, não é suficiente. O que realmente estamos tentando alcançar é dar ao aplicativo mais flexibilidade para controlar a ordem das transações. Mais um elemento: a chamada do sistema 'get_transaction_metadata', que permite ao programa ler a taxa de classificação para a transação com a qual interage, dando ao aplicativo uma poderosa ferramenta de controle de ordenação.
!
Implementação — Mecanismo de Consenso
Os nossos objetivos de design do mecanismo de consenso incluem:
Ligação e Cegamento (Binding & Blinding): Os líderes paralelos não podem incluir informações de blocos de outros líderes em seu próprio bloco (como ataques a transações privadas), nem podem cancelar seu próprio bloco com base no conteúdo de outros blocos de líderes (por exemplo, cancelar sua própria oferta após ver outras ofertas).
Equidade de relógio (Wallclock Fairness): Os líderes em paralelo devem submeter blocos em aproximadamente o mesmo tempo real.
A seguir está um resumo das soluções mais eficazes que desenvolvemos em colaboração com Pranav Garimidi e Joachim Neu da a16z Research:
Cada líder converterá seu bloco em fragmentos de código de correção (shreds). Assim que um número suficiente de fragmentos (superior à taxa de codificação) for recuperado, o bloco poderá ser restaurado. A recuperação parcial não é possível.
Os líderes enviam os fragmentos para os nós de retransmissão na primeira camada da árvore Turbine. Cada líder enviará seu primeiro fragmento para o retransmissor 1, o segundo fragmento para o retransmissor 2, e assim por diante. Se tudo correr bem, cada retransmissor receberá fragmentos de todos os líderes.
Após o tempo limite, o relay envia uma mensagem IHAVE assinada ao líder de consenso único, informando sobre os fragmentos recebidos.
O líder de consenso então constrói um bloco que contém essas mensagens IHAVE; se não contiver uma proporção suficiente de mensagens IHAVE, esse bloco será inválido.
O líder de consenso transmite o bloco para os validadores, que começam a alcançar consenso sobre este bloco.
Este plano satisfaz as propriedades de vinculação e ofuscação com alta probabilidade, e possui uma boa equidade de relógio, embora no futuro possam surgir planos ainda melhores.
!
Conclusão
Solana foi criado com o objetivo de superar o NASDAQ. Para fazer isso, temos que oferecer um preço melhor do que o NASDAQ. Para fazer isso, devemos dar ao aplicativo a capacidade de priorizar cancelamentos antes de fechar. Para potenciar a aplicação desta capacidade, temos de impedir que os líderes revejam unilateralmente as ordens. E para fazer isso, temos que trazer vários líderes em paralelo.