1/ Vamos falar sobre o DCA de @MagicNewton. [Conclusão na página 4] Há discussões sobre zk, TEE, etc., e eu estava curioso sobre onde eles são usados, então guardei por enquanto. Mas eu estava curioso sobre como funciona, então tentei descobrir. A figura abaixo mostra o agente após a conclusão do DCA: 1. Prova gerada 2. Fundos movimentados 3. Prova verificada Existem três etapas como esta. [1. Prova gerada] Quando você clica em Prova gerada, ela aparece como mostrado na figura abaixo. Primeiro, há esses dados, que serão usados posteriormente. Aqui, o TEE é usado, mas você não pode ver os dados originais. [2. Fundos movimentados] Quando você clica em Fundos movidos, uma transação é exibida. É aproximadamente uma transação dizendo que KAITO foi comprado com USDC. Esta parte é um pouco complicada. Olhando para os dados de entrada, executando a função 0xd4ed377d, delegatecall é executado em um loop.
2/ É assim que se processa. O primeiro argumento está executando a função transferFrom 5000000 de 0xd29447c1. O segundo argumento também está executando a função transferFrom 4918295909822 de 0x0e9d7d22. Você pode pensar nisso como esse processo. Os internos são bastante semelhantes, mas os tokens são diferentes. stor_6_0_19, stor_5_0_19 são as diferenças. O terceiro argumento. Agora que temos os tokens, prosseguimos com a troca. USDC → LIFI diamond → swap → cbBTC → WETH → KAITO, este é o processo. Eu continuo usando lifi, mas lifi jumper é originalmente um projeto que faz ponte de cadeia cruzada. Os tokens ainda não foram lançados. Seria bom se ele clicasse ao fazer cross-chain. Trocas de cadeia única também são possíveis. No entanto, hoje em dia, parece que eles estão fazendo isso junto com magicNewton enquanto anexam a intenção. Lifi atribui intenção com @rhinestonewtf, @biconomy, etc. Então, é assim que a troca é feita. Não sei por que mudou para cbBTC e depois voltou durante a troca, mas parece que é assim que a agregação funciona.
3/ Materiais relacionados à intenção de vida (link em ALT) [ 3. prova verificada ] Execute a função proveRequest. Combine os valores gerados a partir da primeira prova gerada no terceiro argumento. No momento, isso entra em _handleSP1ZKPProof. A partir daí, ele é processado. O terceiro processo de verificação parece exigir um pouco mais de estudo! Parece que o processo de verificação de prova não aparece no agente em execução no momento e deve estar inativo para ficar visível, mas parece que está validando o que foi executado nesse meio tempo.
Mostrar original
9
7,28 mil
O conteúdo desta página é fornecido por terceiros. A menos que especificado de outra forma, a OKX não é a autora dos artigos mencionados e não reivindica direitos autorais sobre os materiais apresentados. O conteúdo tem um propósito meramente informativo e não representa as opiniões da OKX. Ele não deve ser interpretado como um endosso ou aconselhamento de investimento de qualquer tipo, nem como uma recomendação para compra ou venda de ativos digitais. Quando a IA generativa é utilizada para criar resumos ou outras informações, o conteúdo gerado pode apresentar imprecisões ou incoerências. Leia o artigo vinculado para mais detalhes e informações. A OKX não se responsabiliza pelo conteúdo hospedado em sites de terceiros. Possuir ativos digitais, como stablecoins e NFTs, envolve um risco elevado e pode apresentar flutuações significativas. Você deve ponderar com cuidado se negociar ou manter ativos digitais é adequado para sua condição financeira.