Resumindo: Dez vezes a eficiência de execução, um décimo da carga de trabalho

A Aperture está a construir um novo chatbot UX alimentado por uma infraestrutura de Intents subjacente que permitirá aos utilizadores "declarar os seus objectivos" em linguagem natural e aceder a uma rede de solucionadores para receber uma melhor execução e melhores preços do que o que é possível no atual paradigma transacional.

A experiência do utilizador: Aperture LLM alimentado por uma DSL de intenções

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

O atual DeFi UX está centrado numa abordagem transacional que exige que os utilizadores com diferentes conhecimentos técnicos assinem um delta ou uma alteração de estado, esperando que a alteração produza o "estado final" que tinham em mente. Com as Intenções, colocamos esse "estado final" na frente e no centro como o ponto focal da experiência do utilizador.

Utilizando o poder dos LLMs modernos e uma linguagem de programação própria orientada para as intenções, procuramos melhorar a expressividade das intenções dos utilizadores. Isto permitirá aos utilizadores articular os seus objectivos e preferências transaccionais de forma mais intuitiva e eficiente, explorando assim o potencial da cadeia de blocos com maior facilidade e precisão.

Imagine um utilizador que não compreende os princípios da tecnologia blockchain, confrontado com uma série de "botões" na interface DeFi tradicional. A abordagem do Aperture de "permitir que o utilizador expresse em linguagem natural o que pretende" é mais simples. Por detrás disto está a necessidade de converter a linguagem natural em código blockchain - é aqui que entram em jogo as Linguagens Específicas de Domínio (DSL).

Uma linguagem específica do domínio (DSL) é uma linguagem informática especializada e adaptada a um determinado domínio de aplicação, o que a distingue das linguagens de uso geral (GPL) que são aplicáveis a um vasto espetro de domínios. A conceção e a utilização de DSL fazem parte integrante da engenharia de domínios, envolvendo frequentemente a criação de novas DSL ou a adaptação de DSL existentes para exprimir problemas e soluções de forma mais eficaz num 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. Esta abordagem difere de outras DSLs que podem dar prioridade a aspectos como a eficiência programática ou a otimização ao nível da máquina.

No Aperture, o LLM preenche a lacuna entre a funcionalidade técnica e as interfaces de fácil utilização, permitindo que o utilizador expresse em linguagem natural a sua intenção e que essa mesma intenção lhe seja devolvida numa DSL altamente legível que pode depois ser apresentada aos solucionadores como a "declaração de verdade" desse utilizador.

Vamos utilizar uma analogia do mundo real: A experiência de utilizador da tradução de LLM para DSL é semelhante à de um cliente que faz um pedido numa pizzaria por telefone. O cliente pode fazer o pedido numa linguagem muito coloquial - "Dê-me a sua pizza com todas as carnes no tamanho que quiser". O operador do outro lado pode responder-lhe: "Quer a nossa piza Meat Lover's num tamanho Extra Large? O utilizador compreende facilmente esta conversão e concorda - "Sim, não sabia o nome, mas é esse que quero".

Na cadeia, esta interação desenrolar-se-ia de forma semelhante. O utilizador pode começar por declarar o seu objetivo final

"Pode reequilibrar os meus LPs ETH-GMX em todas as minhas cadeias EVM para que 80% se concentrem na configuração com melhor desempenho e os restantes 20% do meu capital LP sejam divididos uniformemente pelos restantes pools?"

A tradução DSL pode refletir-se no utilizador -

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

Acções permitidas: Ponte, Remover liquidez, Trocar ETH ou GMX, Adicionar liquidez;

Objetivo final 1: Reequilibrar as posições de liquidez para concentrar 80% do capital de activos elegíveis na posição com a TAEG à vista mais elevada com base nos dados da APY Vision;

Objetivo Final 2: Reequilibrar as posições de liquidez para concentrar 20% do capital de activos elegíveis nos conjuntos existentes não utilizados no Objetivo Final 1;

Assine a declaração de intenção se estiver correcta

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

A infraestrutura subjacente

A infraestrutura de intenções 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 dos utilizadores. Foi concebido para organizar e colocar em fila de espera estas intenções para processamento, utilizando algoritmos que estabelecem prioridades com base em vários critérios, como a urgência e os requisitos de recursos. A Câmara de Compensação assegura a gestão segura e ordenada das intenções antes de estas serem introduzidas na cadeia de blocos.

ZK-Simulate para validação de dados: este é um recurso necessário para validar determinadas intenções e soluções correspondentes que dependerão de dados fora da cadeia. Pode utilizar uma prova de conhecimento zero para verificar a validade destes dados. Utilizando ferramentas criptográficas avançadas como o Brevis ou o Axiom, o Aperture pode gerar ZKPs para dados históricos na cadeia que fazem parte da solução proposta pelo solucionador. Este método permite a verificação rigorosa dos resultados do solucionador, garantindo que são exactos, completos e cumprem 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 utilização de intenção exigirá um contrato inteligente para simular, verificar e policiar a solução proposta.

Motor de classificação e execução: cada grupo de intenções verificadas terá de ser classificado com base nos resultados e na pontuação do solucionador e, em seguida, executado. Um aspeto crucial deste motor de execução é a sua capacidade de impor a responsabilidade. Caso ocorram actividades nefastas, como transacções revertidas ou outros eventos maliciosos, o motor de execução foi concebido para penalizar os solucionadores responsáveis através de slashing ou outros meios. Isto não só salvaguarda a integridade das transacções como também dissuade potenciais comportamentos maliciosos por parte dos solucionadores.

A camada de aplicação: DAOs do Solver

O Solver DAO Network é uma camada de aplicação única construída sobre o Intents-Infra. O Aperture Intents-Infra permite que os DAOs do Solver se concentrem em permitir e resolver casos de utilização únicos baseados em Intents sem terem de se preocupar com as necessidades de execução subjacentes.

Os DAOs do Solver ganham acesso às intenções do utilizador encontradas na Câmara de Compensação do Aperture, apostando uma quantidade necessária de $APTR e $ETH. Um Solver DAO pode estar relacionado com um grande solucionador profissional com uma solução proprietária ou com uma rede de Solvers mais pequenos.

As soluções de novas intenções podem vir do Aperture ou de um DAO Solver de terceiros. Os DAOs do Solver acrescentam valor ao permitirem o novo caso de utilização da Intenção. Para tal, teria de submeter a lógica comercial necessária para se enquadrar no design modular do Aperture. Uma vez 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 aos Solver DAOs que procuram ativar novos casos de utilização de Intent.

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

Na cadeia vs 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 pela sua escalabilidade e velocidade. No entanto, os scripts fora da cadeia são igualmente capazes de publicar soluções rapidamente, oferecendo um caminho alternativo. Algumas intenções declaradas podem mesmo ter características que permitam aos solucionadores apresentar soluções manualmente (por exemplo, um vendedor que pretenda 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 podem, em vez disso, contar com o processo de verificação ZK da Aperture para construir confiança em torno de sua solução habilitada para script off-chain. Isto reforçará o efeito de volante para a integração de solucionadores (soluções comerciais sustentáveis, atrai mais receitas, atrai mais solucionadores).

Cofres do solucionador

Embora não seja explicitamente exigido, um Solver num determinado ecossistema pode também optar por financiar o seu requisito de staking através de um mecanismo de vault em troca de uma rev-share sobre as suas receitas de solver. Cada Solver DAO pode abrir um contrato de rev-share vault para os seus solvers implementarem (se desejarem financiamento bootstrapped).

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

Para tornar as coisas mais fáceis de digerir, tomemos o exemplo da "intenção de reivindicação de lançamento aéreo" proposta na nossa primeira publicação no blogue. Como é que um utilizador declara uma intenção de reivindicação? Como é que um Solver DAO especializado em reivindicações pode aproveitar o Solver DAO Marketplace do Aperture?

O utilizador começaria por declarar em linguagem natural:

"Reivindique todos os lançamentos aéreos elegíveis em meu nome, incluindo o custo do gás associado à reivindicação, em troca de uma taxa de 1% ou menos para o descobridor."

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

Uma vez feita esta clarificação, a intenção será traduzida da linguagem natural para a DSL de intenções codificadas e enviada de volta ao utilizador num formato legível para que este a verifique. A partir daqui, a expressão da intenção será colocada na Câmara de Compensação de Intenções, onde qualquer solucionador elegível poderá ver a declaração do utilizador.

Qualquer Solver pode agora ver o endereço do utilizador e cruzá-lo com quaisquer airdrops ou recompensas que sejam elegíveis para esse endereço. Uma função de autorização alimentada por uma carteira de abstração de conta permitiria aos Solvers reclamar quaisquer airdrops em nome do utilizador. Os solucionadores competiam entre si pela "taxa de descoberta" e pelo seu conhecimento geral dos lançamentos aéreos. Agora - a beleza das Intenções, pode haver várias soluções que ganham e são executadas se o Solver A cobre um lançamento aéreo de Dymension e o Solver B cobre um lançamento aéreo de Celestia, então ambos os Solvers podem ganhar uma taxa de descoberta do nosso utilizador.

As soluções propostas serão todas 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á então em nome do utilizador, devolvendo todos os airdrops.

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso de[chaincatcher]. *Reenvie o título original '一文读懂 Aperture'.Todos os direitos de autor pertencem ao autor original [Industry Express]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.