a16z Crypto Última pesquisa: Qual é a chave para a aplicação em larga escala de DeFi?

作者：PGarimidi, jneu_net, @MaxResnic

Compilação: Jiahun, ChainCatcher

Hoje em dia, a blockchain pode afirmar com segurança que já possui as capacidades necessárias para competir com as actuais infra-estruturas financeiras. Os sistemas de produção actuais conseguem processar dezenas de milhares de transacções por segundo, e estão prestes a assistir a um aumento de uma ordem de grandeza. No entanto, para além do throughput bruto, as aplicações financeiras exigem previsibilidade. Quer se trate de uma compra e venda, de um lance num leilão, ou do exercício de uma opção, o funcionamento normal de um sistema financeiro requer uma resposta determinística: quando é que a transacção será executada? Se a transacção enfrentar atrasos imprevisíveis (quer seja maliciosa ou acidentalmente), muitas aplicações ficarão inutilizáveis.

Para que as aplicações financeiras on-chain sejam competitivas, a blockchain tem de fornecer garantias curtas de empacotamento; por exemplo, se uma transacção válida for submetida à rede, esta tem de garantir que será empacotada o mais rapidamente possível. Por exemplo, considere um order book on-chain. Um order book eficiente mantém a liquidez de forma contínua através da manutenção, pelos market makers, de ordens de compra e venda dos activos no livro.

O principal desafio enfrentado pelos market makers é: reduzir ao máximo o spread entre compra e venda, ao mesmo tempo que evitam o risco de “selecção adversa” quando os preços das suas cotações se desviam do mercado. Para isso, os market makers têm de actualizar as suas ordens continuamente para reflectirem o estado do mundo real. Por exemplo, se um anúncio da Reserva Federal fizer o preço de um activo saltar, um market maker precisa de reagir imediatamente e actualizar as suas ordens para o novo preço. Nestas circunstâncias, se a transacção de actualização da ordem do market maker não for incluída imediatamente, este sofrerá perdas quando arbitrageurs executarem as suas ordens a preços desactualizados. O market maker terá então de alargar o spread para reduzir a sua exposição ao risco em tais eventos, o que, por sua vez, diminui a competitividade do local de negociação on-chain.

O empacotamento previsível de transacções fornece aos market makers uma garantia robusta, permitindo-lhes reagir rapidamente a eventos off-chain e manter a eficiência dos mercados on-chain.

O que temos e o que precisamos

Hoje em dia, as blockchains existentes fornecem apenas garantias robustas de finalização de empacotamento, geralmente activas num intervalo de alguns segundos. Embora estas garantias sejam suficientes para aplicações como pagamentos, são demasiado fracas para suportar grandes aplicações financeiras em que os participantes do mercado precisam de reagir em tempo real à informação.

No exemplo do order book acima: para um market maker, se as transacções dos arbitrageurs puderem ser incluídas em blocos anteriores, então a garantia de que serão empacotadas “nos próximos segundos” é essencialmente inútil. Sem garantias fortes de empacotamento, os market makers teriam de responder aumentando o spread e oferecendo preços piores aos utilizadores para lidar com o aumento do risco de selecção adversa. Isto, por sua vez, reduz significativamente a atractividade da negociação on-chain face a outros mercados que oferecem garantias mais fortes.

Para que uma blockchain realize verdadeiramente a visão de se tornar uma infra-estrutura moderna de capital markets, os construtores precisam de resolver estes problemas para que aplicações de elevado valor, como um order book, possam prosperar.

Onde é que a previsibilidade é verdadeiramente difícil?

Reforçar as garantias de empacotamento das blockchains existentes para suportar estes casos de uso é um desafio. Alguns protocolos actuais podem depender de um nó que, em qualquer momento dado, decide quais transacções serão empacotadas (“líder”). Embora isto simplifique os desafios de engenharia para construir blockchains de alto desempenho, também introduz um possível gargalo económico em que estes líderes podem capturar valor. Normalmente, dentro da janela em que um nó é seleccionado como líder, este tem poder total sobre que transacções incluir no bloco. Para uma blockchain que lide com actividade financeira de qualquer escala, o líder está numa posição privilegiada. Se este único líder decidir não empacotar uma determinada transacção, a única forma de remediar é esperar pelo próximo líder disposto a empacotar essa transacção.

Em redes sem permissão, os líderes têm motivação para capturar valor, vulgarmente conhecido como MEV. O MEV vai muito além de situações como sanduíche de transacções em AMM. Mesmo que o líder consiga apenas atrasar o empacotamento de transacções em algumas dezenas de milissegundos, isso pode proporcionar lucros substanciais e reduzir a eficiência das aplicações subjacentes. Um order book que apenas prioriza o processamento de parte das transacções dos participantes cria um ambiente de concorrência injusto para todos os outros. No pior dos casos, o líder pode tornar-se extremamente hostil, a ponto de os traders abandonarem completamente a plataforma.

Suponha que ocorre um aumento de taxas de juro: o preço do ETH cai imediatamente 5%. Cada market maker no order book apressa-se a cancelar as suas ordens pendentes e a submeter novas ordens com novos preços. Ao mesmo tempo, cada arbitrageur submete ordens para vender ETH a preços desactualizados das suas cotações. Se este order book estiver a correr num protocolo com um único líder, então esse líder terá um poder enorme. O líder pode simplesmente escolher ignorar (fiscalizar) todas as operações de cancelamento dos market makers, permitindo que os arbitrageurs obtenham lucros elevados. Alternativamente, o líder pode não verificar directamente as operações de cancelamento, mas sim atrasá-las até depois das transacções dos arbitrageurs serem executadas. O líder pode até inserir directamente as suas próprias transacções de arbitragem para aproveitar a diferença de preços.

Dois pedidos fundamentais

Perante estas vantagens, a participação activa dos market makers deixa de ser economicamente eficiente; basta haver volatilidade de preços para que sejam explorados. O problema resume-se a que os líderes têm privilégios excessivos em dois aspectos-chave: 1) o líder pode auditar (inspecionar) as transacções de qualquer outra pessoa e 2) o líder pode ver as transacções de terceiros e, com base nisso, submeter as suas próprias transacções como resposta. Qualquer uma destas falhas pode revelar-se catastrófica.

Um exemplo

Podemos identificar com precisão o problema através do seguinte exemplo. Considere um leilão com dois licitantes, Alice e Bob, em que Bob é também o líder do bloco em que o leilão ocorre. (O cenário com apenas dois licitantes é usado para simplificar; o mesmo raciocínio aplica-se a qualquer número de licitantes.)

O leilão aceita licitações durante o intervalo de tempo necessário para gerar o bloco. Suponha que vai de t=0 a t=1. Alice submete uma licitação bA no tempo tA, e Bob submete uma licitação bB no tempo tB > tA. Como Bob é o líder desse bloco, ele consegue sempre garantir que age por último. Alice e Bob também têm uma fonte de “verdade” actualizável para o preço de um activo, que ambos conseguem ler (por exemplo, o preço médio num exchange centralizado). No tempo t, assuma que este preço é pt. Assumimos que, em qualquer momento t, a expectativa do mercado sobre o preço do activo quando o leilão terminar (t=1) é sempre igual ao preço em tempo real pt. As regras do leilão são simples: o licitante entre Alice e Bob com a licitação mais alta ganha o leilão e paga o montante da sua licitação.

A necessidade de resistência à censura

Agora vejamos o que acontece quando Bob pode aproveitar a sua vantagem como líder deste leilão. Se Bob puder censurar a licitação de Alice, é óbvio que o leilão colapsa. Como não há mais licitantes, Bob só precisa de licitar um montante arbitrariamente pequeno para garantir que vence o leilão. Isto faz com que, essencialmente, o leilão liquide com um lucro de 0.

A necessidade oculta

A situação torna-se mais complexa se Bob não puder inspeccionar directamente as licitações de Alice, mas ainda assim puder vê-las antes de submeter a sua própria licitação. Neste caso, Bob tem uma estratégia simples. Quando ele licita, apenas precisa de verificar se ptB > bA. Se for verdade, então a licitação de Bob é apenas ligeiramente superior a bA; caso contrário, Bob não licita.

Ao executar esta estratégia, Bob coloca Alice numa situação de selecção adversa. O único cenário em que Alice vence é se a actualização do preço fizer com que a sua licitação acabe por ficar acima do valor esperado do activo. Sempre que Alice vence o leilão, ela espera perder dinheiro; mais valia nem sequer participar no leilão. Com todos os concorrentes a desaparecerem, Bob pode novamente licitar um montante arbitrariamente pequeno e ganhar, e o leilão obtém, na prática, um lucro de 0.

A ideia-chave aqui é que a duração deste leilão não importa. Desde que Bob possa censurar a licitação de Alice, ou que possa ver a licitação de Alice antes de licitar a sua própria, este leilão está destinado a falhar.

Os mesmos princípios deste exemplo aplicam-se a qualquer ambiente de activos de negociação de alta frequência, seja em spot, contratos perpétuos, ou exchanges de derivados: se existir um líder com o poder de Bob neste exemplo, esse líder pode levar o mercado ao colapso total. Para que produtos on-chain que sirvam estes casos de uso sejam verdadeiramente viáveis, não devem, de forma alguma, atribuir aos líderes estes poderes.

Como é que estes problemas surgem na prática hoje?

A narrativa acima pinta um cenário sombrio para qualquer protocolo on-chain de um único líder sem permissões. No entanto, por que motivo o volume de negociações em exchanges descentralizadas (DEX) em protocolos de um único líder continua a ser saudável? Na prática, duas forças combinam-se para compensar os problemas acima:

• Os líderes não aproveitam totalmente o seu poder económico, porque eles próprios normalmente investem fortemente no sucesso da blockchain subjacente;
• As aplicações já constroem mecanismos de contorno para não ficarem tão vulneráveis a estes problemas.

Embora estes dois factores tenham mantido a DeFi a funcionar até agora, a longo prazo eles não são suficientes para tornar os mercados on-chain verdadeiramente competitivos com os mercados off-chain.

Para que se torne líder numa blockchain com actividade económica substancial, é necessário muito staking. Assim, ou o próprio líder possui uma quantidade elevada de staking, ou possui reputação suficiente para que outros detentores de tokens lhe deleguem o staking. Em qualquer dos casos, grandes operadores de nós tendem a ser entidades conhecidas, com reputação em risco. Para além da reputação, o staking significa também que estes operadores têm incentivos financeiros para que a sua blockchain funcione bem. É por isso que, em larga medida, ainda não vimos líderes a capturar o seu poder de mercado como descrito acima — mas isso não significa que estes problemas não existam.

Em primeiro lugar, confiar no bom comportamento dos operadores de nós por meio de pressão social e apelar a motivações de longo prazo não é uma base sólida para o futuro financeiro. À medida que aumenta a escala da actividade financeira on-chain, também aumenta o lucro potencial dos líderes. Quanto mais cresce este potencial, mais difícil fica, a nível social, fazer com que o comportamento do líder contradiga o seu interesse imediato.

Em segundo lugar, o grau em que os líderes podem explorar o seu poder de mercado é um espectro, indo de um comportamento benigno até provocar o colapso total do mercado. Os operadores de nós podem, de forma unilateral, empurrar o nível de exploração para obter lucros mais elevados. Quando alguns operadores desafiam o patamar aceito, os outros rapidamente imitam. O comportamento de um único nó pode parecer insignificante, mas quando todos mudam, o efeito torna-se óbvio.

Talvez o melhor exemplo deste fenómeno sejam os Jogos de Timing (Timing Games): os líderes tentam anunciar o bloco o mais tarde possível, enquanto o protocolo ainda funciona, para obter recompensas mais altas. Quando os líderes são demasiado agressivos, isso aumenta o tempo de criação de blocos e faz com que ocorram saltos (jump blocks). Embora a rentabilidade destas estratégias seja amplamente conhecida, os líderes escolhem, em grande parte, não jogar esses jogos principalmente para desempenhar o papel de bons administradores da blockchain. No entanto, isto é um equilíbrio social frágil. Assim que um operador de nós começa a jogar estas estratégias para obter recompensas mais elevadas sem consequências, os restantes operadores juntam-se rapidamente.

Os jogos de timing são apenas um exemplo de como os líderes podem aumentar o lucro sem explorar plenamente o seu poder de mercado. Os líderes também podem adoptar muitas outras medidas que aumentam as suas recompensas à custa das aplicações. Isoladamente, algumas destas medidas podem até ser viáveis para as aplicações, mas o fiel da balança acaba por pender para um ponto em que o custo de subir transacções on-chain supera os benefícios.

Outro factor que mantém a DeFi em funcionamento é o facto de as aplicações transferirem lógica importante para off-chain e apenas publicarem os resultados on-chain. Por exemplo, qualquer protocolo que exija leilões rápidos executa-os off-chain. Estas aplicações normalmente executam os seus mecanismos numa série de nós com permissão para evitar os problemas de líderes maliciosos. Por exemplo, o UniswapX executa o seu leilão à holandesa fora da mainnet Ethereum para concluir transacções; de forma semelhante, o CowSwap executa leilões batch off-chain.

Embora isto funcione para as aplicações, coloca a proposta de valor construída na camada base e on-chain num estado precário. No mundo em que a lógica de execução das aplicações vive off-chain, a camada base torna-se puramente uma camada de liquidação. Um dos argumentos mais fortes da DeFi é a composição (composability). Quando toda a execução ocorre no mundo off-chain, estas aplicações vivem essencialmente em ambientes isolados. Depender da execução off-chain introduz também novas suposições no modelo de confiança dessas aplicações. O funcionamento das aplicações deixa de depender apenas da actividade da cadeia subjacente; estas infra-estruturas off-chain também têm de estar operacionais.

Como obter previsibilidade

Para resolver estes problemas, precisamos que os protocolos satisfaçam duas propriedades: regras consistentes de empacotamento e ordenação, e privacidade das transacções antes da sua confirmação (para definições rigorosas destas propriedades e uma discussão mais aprofundada, consulte este artigo).

Requisito fundamental 1: resistência à censura

Resumimos a primeira propriedade como resistência à censura a curto prazo. Se qualquer transacção válida que chegue a um nó honesto for garantidamente incluída no próximo bloco possível, então o protocolo é resistente à censura a curto prazo:

Resistência à censura a curto prazo: Qualquer transacção válida que chegue a um nó honesto a tempo, será necessariamente empacotada no próximo bloco possível.

Mais especificamente, assumimos que o protocolo opera num relógio fixo, com cada bloco a ser gerado num instante definido, por exemplo, a cada 100 milissegundos. O que precisamos de garantir é que, se uma transacção chegar a um nó honesto em t=250ms, será incluída no bloco gerado em t=300ms. O adversário não deve ter o direito de escolher selectivamente quais transacções, entre as que consegue ouvir, serão empacotadas e quais serão omitidas.

A ideia por trás desta definição é que utilizadores e aplicações devem ter uma forma extremamente fiável de fazer transacções serem incluídas a qualquer momento. Não deve acontecer que um único nó, por acaso (quer devido a malícia quer a uma falha operacional simples), faça com que a transacção não seja incluída. Embora esta definição exija garantias de inclusão para transacções que cheguem a qualquer nó honesto, na prática o custo de o fazer pode ser demasiado elevado. A característica importante é que o protocolo deve ser robusto, de modo a que o comportamento do ponto de entrada on-chain seja altamente previsível e fácil de raciocinar.

Protocolo de líder único sem permissões obviamente não satisfaz esta propriedade, porque se em qualquer instante o líder único for um nó bizantino, não há outra forma de garantir a inclusão das transacções. No entanto, mesmo um conjunto de quatro nós que conseguem garantir o empacotamento de transacções em cada período melhora enormemente as opções de utilizadores e aplicações para fazer transacções serem incluídas. Vale a pena sacrificar um certo desempenho para obter um protocolo que consiga garantir de forma fiável que as aplicações prosperam. Ainda há muito trabalho a fazer para encontrar o ponto de equilíbrio correcto entre robustez e desempenho, mas as garantias fornecidas pelos protocolos existentes não são suficientes.

Dado que o protocolo consegue garantir empacotamento, a ordenação é, em certa medida, natural. O protocolo pode usar livremente quaisquer regras de ordenação determinísticas que preferir para garantir ordenação consistente. A solução mais simples é ordenar por priority fee, ou possivelmente permitir que as aplicações sejam flexíveis na ordenação das transacções com as quais interagem com o seu estado. A melhor forma de ordenar transacções continua a ser uma área activa de investigação, mas, em qualquer caso, as regras de ordenação só fazem sentido com base na inclusão das transacções que precisam de ser ordenadas.

Requisito fundamental 2: ocultação

Depois da resistência à censura a curto prazo, a próxima propriedade mais importante é uma forma de privacidade que chamamos de “ocultação” (“hiding”).

Ocultação: Antes do protocolo finalizar quais transacções serão empacotadas, nenhuma parte pode obter qualquer informação sobre qualquer transacção, excepto o nó que recebeu a submissão dessa transacção.

Um protocolo com a propriedade de “ocultação” pode permitir que os nós visualizem todas as transacções que lhes são submetidas em formato de texto claro, mas exigiria que o resto do protocolo permanecesse em estado cego até que a consensualização seja atingida e a ordem das transacções seja determinada no registo final. Por exemplo, o protocolo pode usar encriptação com bloqueio temporal (time-lock encryption), de modo a que o conteúdo completo dos blocos permaneça oculto até uma data limite; ou o protocolo pode usar encriptação por esquema de limiar (threshold encryption), de modo a que o bloco seja desencriptado imediatamente após o comité concordar que a confirmação se torne irreversível.

Isto significa que os nós podem abusar da informação obtida de qualquer transacção que lhes seja submetida, mas o resto do protocolo só sabe o que foi consensualizado mais tarde. Quando a informação sobre as transacções é divulgada ao resto da rede, as transacções já foram ordenadas e confirmadas, pelo que qualquer outra parte não consegue fazer front-running sobre elas. Para que esta definição seja útil, ela realmente implica que múltiplos nós possam, em qualquer período dado, fazer transacções serem incluídas.

Abandonamos a utilização de um conceito mais forte, segundo o qual o utilizador só conhece qualquer informação após a confirmação da transacção (por exemplo, em mempool encriptado), porque o protocolo precisa de tomar algumas medidas como filtro para transacções lixo. Se o conteúdo das transacções estiver totalmente oculto para toda a rede, a rede não consegue distinguir transacções lixo de transacções significativas ao filtrá-las. A única forma de resolver isto é revelar alguma metainformação não ocultada como parte da transacção, por exemplo, o endereço do pagador das taxas que são cobradas independentemente de a transacção ser válida.

No entanto, esta metainformação pode vazar informação suficiente para que o adversário explore. Por isso, preferimos que apenas um nó tenha visibilidade total das transacções, e que os outros nós na rede não tenham qualquer visibilidade. Mas isto também significa que, para que esta propriedade seja útil, é necessário que os utilizadores tenham pelo menos um nó honesto como ponto de entrada on-chain em cada período para fazer as transacções serem incluídas.

Um protocolo que tenha simultaneamente resistência à censura a curto prazo e ocultação oferece uma base ideal para construir aplicações financeiras. Voltando ao exemplo em que tentamos executar leilões on-chain, estas duas propriedades resolvem directamente a forma como Bob poderia fazer o mercado colapsar. Bob não consegue nem censurar os lances de Alice, nem utilizar os lances de Alice para fornecer informação ao seu próprio lance; isto resolve de forma exacta o problema do nosso exemplo anterior.

Com resistência à censura a curto prazo, qualquer pessoa que submeta uma transacção (seja uma transacção ou um lance de leilão) pode garantir que ela será empacotada imediatamente. Os market makers podem alterar as suas ordens; os licitantes podem licitar rapidamente; as liquidações podem ser incluídas de forma eficiente. Os utilizadores podem ter a certeza de que quaisquer operações que realizem serão executadas imediatamente. Por sua vez, isto permite que a próxima geração de aplicações financeiras realistas com baixa latência seja construída inteiramente on-chain.

Para que a blockchain concorra verdadeiramente com as infra-estruturas financeiras existentes, e até as ultrapasse, há muito mais do que apenas um problema de throughput que precisamos de resolver.