Em resumo: dez vezes a eficiência de execução, um décimo da carga de trabalho

A Aperture está criando um novo chatbot UX alimentado por uma infraestrutura de Intents subjacente que permitirá que os usuários "declarem suas metas" em linguagem natural e acessem uma rede de solucionadores para receber melhor execução e melhores preços do que o que é possível sob o paradigma transacional atual.

A experiência do usuário: Aperture LLM alimentado por um Intents DSL

Para começar, vamos começar com a pedra angular de qualquer movimento de adoção em massa: a experiência do usuário (UX).

O DeFi UX atual está centrado em uma abordagem transacional que exige que usuários com diferentes conhecimentos técnicos assinem um delta ou uma mudança de estado, esperando que a mudança produza o "estado final" que eles tinham em mente. Com o Intents, colocamos esse "estado final" na frente e no centro como o ponto focal da experiência do usuário.

Usando o poder dos LLMs modernos e uma linguagem de programação proprietária orientada a Intents, buscamos aprimorar a expressividade das Intents do usuário. Isso permitirá que os usuários articulem suas metas e preferências transacionais de forma mais intuitiva e eficiente, aproveitando assim o potencial do blockchain com mais facilidade e precisão.

Imagine um usuário que não entende os princípios da tecnologia blockchain e se depara com uma série de "botões" na interface DeFi tradicional. A abordagem do Aperture de "permitir que o usuário expresse em linguagem natural o que deseja" é mais simples. Por trás disso está a necessidade de converter a linguagem natural em código de blockchain - é aqui que as linguagens específicas de domínio (DSL) entram em ação.

Uma linguagem específica de domínio (DSL) é uma linguagem de computador especializada e adaptada a um domínio de aplicativo específico, diferenciando-a das linguagens de uso geral (GPL), que são aplicáveis em um amplo espectro de domínios. O projeto e a utilização de DSLs são parte integrante da engenharia de domínio, geralmente envolvendo a criação de novas DSLs ou a adaptação das existentes para expressar problemas e soluções de forma mais eficaz em um domínio específico.

No Aperture, a DSL é elaborada com foco na legibilidade humana, crucial para apoiar a expressão de intenções claras e intuitivas. Essa abordagem difere de outras DSLs que podem priorizar aspectos como eficiência programática ou otimização em nível de máquina.

No Aperture, o LLM preenche a lacuna entre a funcionalidade técnica e as interfaces fáceis de usar, permitindo que o usuário expresse em linguagem natural sua intenção e tenha essa mesma intenção espelhada de volta para ele em uma DSL altamente legível que pode então ser apresentada aos solucionadores como a "declaração de verdade" desse usuário.

Vamos usar uma analogia do mundo real: A UX de tradução de LLM para DSL é semelhante a um cliente que faz um pedido em uma pizzaria por telefone. O cliente pode fazer o pedido em uma linguagem bem coloquial: "Me dê a pizza com todas as carnes no tamanho que o senhor quiser". O operador do outro lado pode responder: "O senhor quer a nossa pizza Meat Lover's em tamanho Extra Large? O usuário entende facilmente essa conversão e concorda: "Sim, eu não sabia o nome dela, mas é essa que eu quero".

Na cadeia, essa interação se desenrolaria de maneira semelhante. O usuário pode começar declarando seu objetivo final -

"O senhor pode reequilibrar meus LPs ETH-GMX em todas as minhas cadeias EVM para que 80% se concentrem na configuração de melhor desempenho e os 20% restantes do meu capital LP sejam divididos igualmente entre os pools restantes?"

A tradução da DSL pode espelhar de volta para o usuário -

Ativos elegíveis: Pares ETH-GMX na Mainnet, Arbitrum e Avalanche;

Ações permitidas: Bridge, Remover liquidez, Trocar ETH ou GMX, Adicionar liquidez;

Meta final 1: Reequilibrar as posições de liquidez para concentrar 80% do capital de ativos elegíveis na posição com a maior APR à vista com base nos dados do APY Vision;

Meta final 2: Reequilibrar as posições de liquidez para concentrar 20% do capital de ativos elegíveis nos pools existentes não utilizados na Meta final 1;

Assinar a declaração de intenção se estiver correto

A conversão do LLM codificará a linguagem coloquial na terminologia padronizada da DSL, que pode ser aproveitada pelos solucionadores de forma previsível e replicável.

A infraestrutura subjacente

A Intent Infrastructure pode ser dividida em vários componentes:

Câmara de Compensação de Intenções (Mempool): serve como uma área de preparação preliminar para as intenções do usuário. Ele foi projetado para organizar e enfileirar com eficiência essas intenções para processamento, usando algoritmos que priorizam com base em vários critérios, como urgência e requisitos de recursos. A Câmara de Compensação garante o gerenciamento seguro e ordenado das intenções antes que elas sejam confirmadas no blockchain.

ZK-Simulate for Data Validity: esse é um recurso necessário para validar determinadas intenções e soluções correspondentes que dependerão de dados fora da cadeia. Uma prova de conhecimento zero pode ser usada para verificar a validade desses dados. Utilizando ferramentas criptográficas avançadas, como Brevis ou Axiom, o Aperture pode gerar ZKPs para dados históricos na cadeia que fazem parte da solução proposta pelo solucionador. Esse método permite a verificação rigorosa dos resultados do solucionador, garantindo que eles sejam precisos, completos e estejam em conformidade com as restrições e intenções especificadas, sem comprometer a confidencialidade dos dados da transação.

Contratos inteligentes de verificação: cada tipo de caso de uso de intenção exigirá um contrato inteligente para simular, verificar e fiscalizar a solução proposta.

Mecanismo de classificação e execução: cada grupo de intenções verificadas precisará ser classificado com base nos resultados e na pontuação do solucionador e, em seguida, executado. Um aspecto crucial desse mecanismo de execução é sua capacidade de impor a responsabilidade. Caso ocorram atividades nefastas, como transações revertidas ou outros eventos mal-intencionados, o mecanismo de execução é projetado para penalizar os solucionadores responsáveis por meio de slashing ou outros meios. Isso não apenas protege a integridade das transações, mas também impede o possível comportamento malicioso dos solucionadores.

A camada de aplicativos: DAOs do Solver

O Solver DAO Network é uma camada de aplicativo exclusiva criada sobre o Intents-Infra. O Aperture Intents-Infra permite que os DAOs do Solver se concentrem em habilitar e resolver casos de uso exclusivos baseados em Intents sem ter que se preocupar com as necessidades de execução subjacentes.

Os DAOs do Solver obtêm acesso às intenções do usuário encontradas na Câmara de Compensação da Aperture, apostando uma quantia necessária de $APTR e $ETH. Um Solver DAO pode estar relacionado a um grande solucionador profissional com uma solução proprietária ou a uma rede de Solvers menores.

As soluções de novas intenções podem vir do Aperture ou de um Solver DAO de terceiros. Os DAOs do Solver agregam valor ao habilitar o novo caso de uso do Intent. Isso exigiria o envio da lógica comercial necessária para se encaixar no design modular do Aperture. Uma vez que isso tenha sido construído, o caso de uso agora é "declarável" a partir da Interface de Intenções do Aperture ou de uma interface de terceiros criada pelo Solver DAO.

O Aperture DAO fornecerá assistência de subsídio de $APTR para o Solver DAO que busca habilitar novos casos de uso de Intent.

Como os Solvers vão competir e que tipos de Solvers podem existir?

Na cadeia versus fora da cadeia

No competitivo ecossistema do Aperture Intents, os Solvers se diferenciam pelos métodos que empregam para publicar soluções. Embora não sejam obrigatórios, os contratos inteligentes são preferidos por sua escalabilidade e velocidade. No entanto, os scripts fora da cadeia são igualmente hábeis em postar soluções rapidamente, oferecendo uma rota alternativa. Certas intenções declaradas podem até ter características que permitam aos solucionadores enviar soluções manualmente (por exemplo, um vendedor que deseja organizar uma grande transação OTC com uma janela de licitação de 3 dias).

Manutenção de Alfa

Para Solvers com métodos de geração de soluções verdadeiramente "alfa" ou proprietários, eles podem evitar a utilização de um contrato inteligente para gerar suas soluções e, em vez disso, podem contar com o processo de verificação ZK da Aperture para criar confiança em torno de sua solução habilitada para script off-chain. Isso reforçará o efeito flywheel para a integração de solucionadores (soluções comerciais sustentáveis, atrai mais receita, atrai mais solucionadores).

Cofres do solucionador

Embora não seja explicitamente exigido, um solucionador em um determinado ecossistema também pode optar por financiar o seu requisito de staking por meio de um mecanismo de cofre em troca de uma participação nos lucros do solucionador. Cada Solver DAO pode abrir um contrato de rev-share vault para seus solvers implementarem (caso desejem um financiamento inicial).

Um exemplo: Intenção de reivindicação de lançamento aéreo

Para tornar as coisas mais fáceis de entender, vamos pegar o exemplo da "intenção de reivindicação de lançamento aéreo" proposta em nossa primeira postagem no blog. Como um usuário poderia declarar uma intenção de reivindicação? Como um Solver DAO especializado em reivindicações poderia aproveitar o Solver DAO Marketplace do Aperture?

O usuário começaria declarando em linguagem natural:

"Reivindique todos os airdrops elegíveis em meu nome, incluindo o custo do gás associado à reivindicação, em troca de uma taxa de localização de 1% ou menos."

O chatbot pode fazer perguntas de esclarecimento para obter mais informações sobre a declaração do usuário.

Uma vez feito esse esclarecimento, a intenção seria traduzida da linguagem natural para a DSL de intenções codificadas e enviada de volta ao usuário em um formato legível para verificação. A partir daí, a expressão da Intent será postada na Intents Clearing House, onde qualquer Solvers qualificado poderá visualizar a declaração do usuário.

Qualquer Solver pode agora visualizar o endereço do usuário e fazer referência cruzada com quaisquer airdrops ou recompensas reivindicáveis que sejam elegíveis para esse endereço. Uma função de permissão alimentada por uma carteira de abstração de conta permitiria que os Solvers reivindicassem quaisquer airdrops em nome do usuário. Os solucionadores competiam entre si pela "taxa do descobridor" e por seu conhecimento geral sobre lançamentos aéreos. Agora, a beleza das Intents é que pode haver várias soluções que vencem e são executadas. Se o Solver A cobrir um lançamento aéreo de Dymension e o Solver B cobrir um lançamento aéreo de Celestia, ambos os Solvers poderão ganhar uma taxa de localização do nosso usuário.

Todas as soluções propostas serão simuladas pelos contratos inteligentes da Aperture para verificar os resultados propostos e, em seguida, todas as soluções verificadas serão classificadas. O Aperture executará em nome do usuário, retornando todos os airdrops.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de[chaincatcher]. *Refira o título original '一文读懂 Aperture'.Todos os direitos autorais pertencem ao autor original [Industry Express]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn, que tratará do assunto imediatamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.