As blockchains já podem afirmar, de modo convincente, que possuem a capacidade necessária para competir com a infraestrutura financeira tradicional. Sistemas em produção processam hoje dezenas de milhares de transações por segundo, com avanços significativos previstos para o futuro próximo.
No entanto, além da capacidade bruta, aplicações financeiras exigem previsibilidade. Quando uma transação é enviada — seja uma negociação, um lance em leilão ou o exercício de uma opção — é fundamental ter uma garantia confiável de quando essa transação será registrada, para o funcionamento adequado dos sistemas financeiros. Se as transações sofrem atrasos imprevisíveis (por ação adversa ou acaso), muitas aplicações tornam-se inutilizáveis. Para que aplicações financeiras onchain sejam competitivas, a cadeia precisa garantir inclusão em curto prazo: se uma transação válida for submetida à rede, ela deve ser incluída o mais rápido possível.
Por exemplo, considere um livro de ofertas onchain. Livros de ofertas eficientes exigem que criadores de mercado forneçam liquidez continuamente, mantendo ordens de compra e venda dos ativos registrados. O principal desafio enfrentado pelos criadores de mercado é manter o spread (diferença entre preços de compra e venda) o mais estreito possível, sem se expor à seleção adversa ao oferecer preços fora do padrão do mercado. Para isso, os criadores de mercado precisam atualizar suas ordens constantemente, refletindo o estado do mundo. Se um anúncio do Federal Reserve provoca uma alta nos preços dos ativos, os criadores de mercado precisam reagir instantaneamente, ajustando suas ordens para o novo preço. Se as transações dos criadores de mercado para atualizar suas ordens não forem registradas imediatamente, eles sofrerão perdas ao terem suas ordens preenchidas por arbitradores a preços desatualizados. Isso os obriga a aumentar o spread para reduzir a exposição a esses eventos, tornando os ambientes onchain menos competitivos.
A previsibilidade na inclusão de transações é o que permite aos criadores de mercado reagirem rapidamente a eventos offchain e manterem a eficiência dos mercados onchain.
O que temos versus o que precisamos
Atualmente, as cadeias existentes oferecem apenas garantias robustas de inclusão eventual, normalmente em questão de segundos. Embora essas garantias sejam suficientes para aplicações como pagamentos, são insuficientes para uma grande classe de aplicações financeiras, onde os participantes do mercado precisam reagir em tempo real às informações. Voltando ao exemplo do livro de ofertas: para criadores de mercado, a garantia de inclusão “nos próximos segundos” é irrelevante se as transações dos arbitradores podem ser registradas em blocos anteriores. Sem garantias sólidas de inclusão, os criadores de mercado precisam compensar o aumento da seleção adversa ampliando seus spreads e oferecendo preços menos vantajosos aos usuários. Isso torna a negociação onchain menos atraente em comparação a outros ambientes que oferecem garantias mais fortes.
Para que as blockchains realmente cumpram o papel de infraestrutura para modernizar os mercados de capitais, é preciso solucionar essas questões para que aplicações de alto valor, como livros de ofertas, possam prosperar.
Por que é tão difícil obter previsibilidade?
Fortalecer as garantias de inclusão nas cadeias existentes para atender a esses casos de uso é um desafio. Alguns protocolos dependem de um único nó (“líder”) que pode determinar a inclusão de transações a qualquer momento. Embora isso simplifique o desafio de engenharia para construir uma cadeia eficiente, também cria um ponto de concentração econômica, onde líderes podem extrair valor. Geralmente, durante o período em que um nó é eleito líder, ele tem total poder sobre quais transações serão incluídas em um bloco.
Em uma cadeia que processa qualquer volume de atividade financeira, o líder ocupa uma posição privilegiada. Se esse líder decidir não incluir uma transação, a única alternativa é esperar pelo próximo líder disposto a incluí-la. Em uma rede permissionless, líderes são incentivados a extrair valor, fenômeno conhecido como MEV. O MEV vai além de práticas como sanduíche em negociações de AMM. Apenas a capacidade do líder de atrasar a inclusão de transações por alguns milissegundos pode gerar lucros significativos e prejudicar a eficiência das aplicações. Um livro de ofertas que prioriza apenas um subconjunto de transações de negociadores deixa os demais em desvantagem. No pior cenário, o líder pode ser tão adverso que negociadores abandonam a plataforma.
Suponha que haja um aumento de taxa e o preço do ETH caia imediatamente 5%. Todos os criadores de mercado em um livro de ofertas correm para cancelar suas ordens antigas e criar novas ordens aos preços atualizados. Ao mesmo tempo, arbitradores enviam ordens para vender ETH nas ordens antigas. Se esse livro de ofertas estiver em um protocolo com líder único, o líder detém enorme poder. Ele pode simplesmente censurar todos os cancelamentos dos criadores de mercado, permitindo que arbitradores obtenham grandes lucros. Ou, em vez de censurar, pode atrasar os cancelamentos até que os arbitradores registrem suas transações. O líder pode até inserir suas próprias transações de arbitragem para aproveitar totalmente a discrepância de preços.
Uma história de dois desideratos: necessidade de resistência à censura e ocultação
Diante dessas vantagens, torna-se antieconômico para criadores de mercado participarem ativamente; sempre que há movimentação de preço, eles podem ser prejudicados. O problema reside no privilégio excessivo do líder em dois aspectos: 1) o líder pode censurar transações de outros, e 2) pode ver as transações alheias e submeter as próprias em resposta. Qualquer um desses pontos pode ser catastrófico.
Um exemplo
Podemos detalhar o problema com o exemplo a seguir. Considere um leilão com dois participantes, Alice e Bob, sendo Bob o líder do bloco onde ocorre o leilão. (O fato de haver apenas dois participantes é ilustrativo; o raciocínio vale para qualquer número de participantes.)
O leilão aceita lances durante o tempo de produção do bloco, digamos de t=0 a t=1. Alice envia um lance bA em tA e Bob envia um lance bB em tB > tA. Como Bob é o líder do bloco, ele sempre pode garantir que age por último. Alice e Bob têm uma fonte de verdade constantemente atualizada para o preço do ativo (por exemplo, preço médio em uma exchange centralizada). Em t, esse preço é pt. Consideramos que, em t, o preço esperado do ativo em t=1 (quando o leilão termina) é sempre pt. Ou seja, a qualquer momento, o preço que Alice e Bob esperam para o ativo ao final do leilão é igual ao preço atual. As regras do leilão são simples: quem tiver o lance mais alto vence e paga o valor ofertado.
A necessidade de resistência à censura
Agora, vejamos o que acontece quando Bob usa sua vantagem de líder no leilão. Se Bob pode censurar o lance de Alice, o leilão desmorona. Bob pode ofertar qualquer valor irrisório e garantir a vitória, já que não há outros lances. Isso faz com que o leilão se encerre com receita praticamente nula.
A necessidade de ocultação
O caso mais complexo ocorre quando Bob não pode censurar o lance de Alice, mas ainda pode vê-lo antes de fazer sua oferta. Nesse cenário, Bob adota uma estratégia simples: ao ofertar, verifica se ptB > bA. Se sim, Bob oferta um valor ligeiramente acima de bA; se não, não oferta. Ao seguir essa estratégia, Bob faz com que Alice seja selecionada adversamente. Alice só vence quando o preço se atualiza e seu lance supera o valor esperado do ativo. Sempre que vence, Alice tende a perder dinheiro e preferiria não participar do leilão. Com todos os concorrentes fora, Bob pode novamente ofertar qualquer valor e vencer, com receita nula.
O ponto central é que não importa quanto tempo o leilão dure. Enquanto Bob puder censurar ou ver o lance de Alice antes de ofertar, o leilão está fadado ao fracasso.
Os mesmos princípios desse exemplo aplicam-se a qualquer ambiente de negociação de ativos de alta frequência, seja negociação spot, perps ou exchanges de derivativos: se houver um líder com o poder de Bob, esse líder pode desestabilizar completamente o mercado. Para que produtos onchain atendam esses casos de uso, não podem conceder tais poderes ao líder.
Como esses problemas surgem na prática hoje?
O cenário acima traça um panorama negativo para negociações onchain em protocolos permissionless com líder único. Contudo, volumes de exchanges descentralizadas (DEX) em muitos desses protocolos continuam saudáveis. O que explica isso?
Na prática, dois fatores contrabalançam os problemas descritos:
- Líderes não exploram totalmente seu poder econômico, pois geralmente estão fortemente investidos no sucesso da cadeia subjacente;
- Aplicações criaram soluções alternativas para não ficarem tão vulneráveis a esses problemas.
Embora esses fatores tenham mantido o funcionamento da DeFi até agora, não serão suficientes para tornar mercados onchain verdadeiramente competitivos com seus equivalentes offchain a longo prazo.
Ser elegível como líder em uma cadeia com atividade econômica relevante exige uma grande quantidade de stake. Assim, o líder ou possui muito stake ou tem reputação suficiente para outros holders delegarem stake a ele. Em ambos os casos, grandes operadores de nós são geralmente entidades conhecidas, com reputação em jogo. Além da reputação, o stake também significa incentivo financeiro para que a cadeia prospere. Por isso, não vimos líderes explorarem integralmente seu poder de mercado conforme descrito acima — mas isso não elimina o problema.
Em primeiro lugar, depender da boa vontade dos operadores de nós por pressão social e apelo a incentivos de longo prazo não é uma base robusta para o futuro das finanças. À medida que cresce a atividade financeira onchain, aumentam os lucros potenciais dos líderes. Quanto maior esse potencial, maior a pressão sobre o layer social para conter o comportamento dos líderes contra seus interesses imediatos.
Em segundo lugar, o grau de exploração do poder de mercado pelos líderes é um espectro, do benigno ao destrutivo. Operadores de nós podem tomar decisões unilaterais para aumentar lucros. À medida que alguns testam os limites do aceitável, outros rapidamente seguem. O comportamento de um nó pode parecer irrelevante, mas quando todos mudam, o impacto é evidente.
Talvez o melhor exemplo desse fenômeno sejam os jogos de timing: quando líderes atrasam o anúncio de blocos até o último momento permitido pelo protocolo para ganhar mais recompensas. Isso pode causar tempos de bloco mais longos e blocos perdidos quando o líder é agressivo demais. Embora a lucratividade dessas estratégias fosse amplamente conhecida, líderes evitavam jogá-las principalmente por serem bons administradores da cadeia. No entanto, esse equilíbrio social era frágil. Quando um operador começou a adotar essas estratégias para obter mais recompensas sem consequências, outros rapidamente aderiram. Jogos de timing são apenas um exemplo de como líderes podem aumentar lucros sem explorar totalmente seu poder de mercado. Existem várias outras medidas que podem ser tomadas para aumentar recompensas em detrimento das aplicações. Isoladamente, essas medidas podem ser administráveis, mas eventualmente o custo de estar onchain supera os benefícios.
O outro fator que manteve a DeFi funcional é a migração de lógica importante das aplicações para fora da cadeia, postando apenas os resultados onchain. Por exemplo, qualquer protocolo que precise realizar leilões rapidamente o faz offchain. Essas aplicações geralmente executam mecanismos necessários em um conjunto permissionado de nós para evitar problemas com líderes adversos. UniswapX, por exemplo, executa leilão holandês para preencher negociações no Ethereum mainnet offchain, assim como Cowswap executa leilão em lote offchain. Embora isso funcione para as aplicações, coloca o layer base e a proposta de valor de construir onchain em posição delicada. Um cenário onde toda a lógica de execução das aplicações ocorre offchain faz com que o layer base seja usado apenas para liquidação. Um dos maiores atrativos da DeFi é a composabilidade. Em um mundo onde toda a execução ocorre offchain, essas aplicações vivem em ambientes isolados. Depender de execução offchain também adiciona novas premissas ao modelo de confiança das aplicações. Em vez de depender apenas da cadeia estar ativa, é preciso garantir que a infraestrutura offchain esteja disponível para o funcionamento dos apps.
Como obter previsibilidade
Para resolver esses problemas, o protocolo precisa atender a dois requisitos: inclusão e ordenação consistentes de transações e privacidade das transações antes da confirmação (para uma definição rigorosa e discussão estendida, consulte https://arxiv.org/abs/2509.23984, especialmente as Definições 9 e 11).
Desiderato #1: Resistência à censura
O primeiro requisito é a resistência à censura em curto prazo. Um protocolo é resistente à censura em curto prazo se qualquer transação que chega a um nó honesto é garantida de ser incluída no próximo bloco possível:
Resistência à censura em curto prazo: Qualquer transação válida que chega a um nó honesto em tempo hábil será certamente incluída no próximo bloco possível.
Mais precisamente, assumimos que o protocolo opera em relógio fixo, com produção de blocos em intervalos definidos, por exemplo, a cada 100 ms. Queremos garantir que, se uma transação chegar a um nó honesto em t=250 ms, será incluída no bloco produzido em t=300 ms. Um adversário não deve ter discricionariedade para incluir seletivamente certas transações e excluir outras. O espírito dessa definição é que usuários e aplicações tenham uma forma extremamente confiável de registrar transações a qualquer momento. Não deve ocorrer de um nó simplesmente descartar pacotes, seja por malícia ou falha operacional, impedindo o registro de uma negociação.
Embora essa definição exija garantias de inclusão para transações que chegam a qualquer nó honesto, na prática o overhead pode ser alto. O ponto importante é que o protocolo deve ser robusto, de modo que os pontos de entrada para registro onchain sejam extremamente previsíveis e fáceis de entender. Um protocolo permissionless com líder único claramente não atende a esse requisito, pois se o líder for bizantino, não há alternativa para registrar uma transação. Contudo, um conjunto de quatro nós que garante inclusão em cada slot já amplia significativamente as opções de usuários e aplicações. Vale a pena sacrificar um pouco de performance por um protocolo que permita aplicações prosperarem de forma confiável. Ainda há trabalho a ser feito para encontrar o equilíbrio ideal entre robustez e performance, mas as garantias dos protocolos atuais não são suficientes.
Se o protocolo garante inclusão, a ordenação vem quase de graça. Protocolos podem usar qualquer regra determinística para garantir ordenação consistente. A solução mais simples é ordenar por prioridade de taxa ou permitir flexibilidade para aplicações ordenarem transações que interagem com seu estado. O modo ótimo de ordenar transações ainda é objeto de pesquisa, mas, de todo modo, as regras de ordenação só importam se as transações forem registradas.
Desiderato #2: Ocultação
Após a resistência à censura em curto prazo, o requisito mais importante é que o protocolo ofereça uma forma de privacidade denominada ocultação.
Ocultação: Nenhuma parte, exceto o nó ao qual a transação é submetida, tem acesso a qualquer informação sobre a transação antes de sua inclusão ser finalizada pelo protocolo.
Um protocolo que oferece ocultação pode permitir que os nós vejam todas as transações recebidas em texto claro, mas exige que o restante do protocolo seja cego até o consenso ser finalizado e a ordem da transação no log confirmado. Por exemplo, o protocolo pode usar criptografia com timelock para ocultar todo o conteúdo do bloco até um determinado prazo; ou criptografia por limiar, de modo que o bloco seja decriptado quando um comitê concorda que está irreversivelmente confirmado.
Isso significa que um nó pode abusar das informações de qualquer transação recebida, mas o restante do protocolo não conhece o conteúdo até depois do consenso. Quando as informações são reveladas, a transação já está ordenada e confirmada, impedindo front-run. Para essa definição ser útil, é necessário que múltiplos nós possam registrar transações em cada slot.
Optamos por não adotar a noção mais forte, onde apenas o usuário conhece informações sobre sua transação antes de ser confirmada (como em mempools criptografados), pois o protocolo precisa de algum mecanismo para filtrar transações spam. Se o conteúdo for totalmente oculto, a rede não pode distinguir transações legítimas de lixo. A única alternativa seria vazar algum metadado, como endereço do pagador de taxas, que seria cobrado independentemente da validade da transação. No entanto, esse metadado pode revelar informações suficientes para um adversário explorar. Por isso, preferimos que um nó tenha total visibilidade da transação, mas nenhum outro nó na rede tenha acesso. Para que essa propriedade seja útil, o usuário precisa ter ao menos um nó honesto como ponto de entrada para registrar transações em cada slot.
Um protocolo que seja resistente à censura em curto prazo e ofereça ocultação proporciona a base ideal para aplicações financeiras. Voltando ao exemplo do leilão onchain, essas duas propriedades resolvem diretamente as formas pelas quais Bob poderia desestabilizar o mercado. Bob não pode censurar nem usar o lance de Alice para informar seu próprio lance, solucionando os problemas 1) e 2) do exemplo anterior. (Para mais detalhes, consulte este preprint recente.)
Com resistência à censura em curto prazo, qualquer pessoa que submeta uma transação — seja uma negociação ou um lance em leilão — tem garantia de inclusão instantânea. Criadores de mercado podem alterar ordens; participantes podem ofertar rapidamente; liquidações podem ser processadas de forma eficiente. Os usuários podem confiar que qualquer ação será executada imediatamente. Isso permitirá que a próxima geração de aplicações financeiras de baixa latência seja construída totalmente onchain. Para que blockchains realmente concorram com — e superem — a infraestrutura financeira existente, é preciso solucionar muito mais do que apenas a capacidade de processamento.
As opiniões expressas aqui são de funcionários individuais da AH Capital Management, L.L.C. (“a16z”) citados, e não representam as opiniões da a16z ou suas afiliadas. Certas informações contidas neste texto foram obtidas de fontes terceirizadas, incluindo empresas do portfólio de fundos geridos pela a16z. Embora provenientes de fontes consideradas confiáveis, a a16z não verificou independentemente tais informações e não faz declarações sobre a precisão atual ou permanente dessas informações, nem sobre sua adequação para determinada situação. Além disso, este conteúdo pode incluir anúncios de terceiros; a a16z não revisou tais anúncios e não endossa nenhum conteúdo publicitário aqui contido.
Você deve consultar seus próprios consultores sobre esses assuntos. Referências a quaisquer valores mobiliários ou ativos digitais são apenas ilustrativas e não constituem recomendação de investimento ou oferta de serviços de consultoria. Ademais, este conteúdo não se destina nem é direcionado a investidores ou potenciais investidores, e não pode ser utilizado sob nenhuma circunstância como base para decisão de investimento em qualquer fundo gerido pela a16z. (Uma oferta de investimento em um fundo da a16z será feita apenas por meio do memorando de colocação privada, contrato de subscrição e outros documentos relevantes desse fundo, que devem ser lidos integralmente.) Qualquer investimento ou empresa mencionada, referida ou descrita não representa todos os investimentos realizados por veículos geridos pela a16z, e não há garantia de que os investimentos serão lucrativos ou que outros investimentos futuros terão características ou resultados semelhantes. Uma lista de investimentos realizados por fundos administrados pela Andreessen Horowitz (excluindo investimentos para os quais o emissor não autorizou divulgação pública pela a16z, bem como investimentos não anunciados em ativos digitais negociados publicamente) está disponível em https://a16z.com/investment-list/.
O conteúdo refere-se apenas à data indicada. Qualquer projeção, estimativa, previsão, meta, perspectiva e/ou opinião expressa nestes materiais está sujeita a alterações sem aviso prévio e pode diferir ou ser contrária a opiniões de outros. Consulte https://a16z.com/disclosures/ para informações adicionais importantes.
Isenção de responsabilidade:
-
Este artigo é republicado de [a16zcrypto]. Todos os direitos autorais pertencem ao autor original [@PGarimidi,@jneu_net, e @MaxResnick]. Caso haja objeções a esta republicação, entre em contato com a equipe Gate Learn, que tomará as providências necessárias.
-
Isenção de responsabilidade: As opiniões e visões expressas neste artigo são exclusivamente do autor e não constituem aconselhamento de investimento.
-
As traduções do artigo para outros idiomas são realizadas pela equipe Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.
