1/ Давайте поговорим о DCA @MagicNewton. [Заключение на странице 4] Есть обсуждения о zk, TEE и т.д., и мне было любопытно, где они используются, поэтому я оставил это на потом. Но мне было интересно, как это работает, поэтому я попытался разобраться. На картинке ниже показан агент после завершения DCA: 1. Генерация доказательства 2. Перемещение средств 3. Проверка доказательства Существует три таких шага. [1. Генерация доказательства] Когда вы нажимаете на Генерация доказательства, оно появляется, как показано на картинке ниже. Сначала есть эти данные, которые будут использованы позже. Здесь используется TEE, но вы не можете увидеть оригинальные данные. [2. Перемещение средств] Когда вы нажимаете на Перемещение средств, появляется транзакция. Это примерно транзакция, говорящая о том, что KAITO был куплен за USDC. Эта часть немного сложная. Смотря на входные данные, выполняя функцию 0xd4ed377d, delegatecall выполняется в цикле.
2/ Вот как это происходит. Первый аргумент выполняет функцию transferFrom 5000000 от 0xd29447c1. Второй аргумент также выполняет функцию transferFrom 4918295909822 от 0x0e9d7d22. Вы можете представить это как этот процесс. Внутренности довольно похожи, но токены разные. stor_6_0_19, stor_5_0_19 - это различия. Третий аргумент. Теперь, когда у нас есть токены, мы продолжаем с обменом. USDC → LIFI diamond → обмен → cbBTC → WETH → KAITO, вот процесс. Я продолжаю использовать lifi, но lifi jumper изначально проект, который занимается кросс-цепочными мостами. Токены еще не вышли. Было бы здорово, если бы это сработало при выполнении кросс-цепочки. Одноцепочные обмены также возможны. Однако в последнее время кажется, что они делают это вместе с magicNewton, прикрепляя намерение. lifi прикрепляет намерение с @rhinestonewtf, @biconomy и т.д. Так что вот как происходит обмен. Я не знаю, почему это изменилось на cbBTC, а затем снова вернулось во время обмена, но, похоже, именно так работает агрегирование.
3/ Материалы, связанные с намерением lifi (ссылка в ALT) [ 3. доказательство проверено ] Выполните функцию proveRequest. Объедините значения, сгенерированные из первого доказательства, сгенерированного в третьем аргументе. Прямо сейчас это попадает в _handleSP1ZKPProof. Оттуда оно обрабатывается. Третий процесс верификации, похоже, требует немного больше изучения! Похоже, что процесс проверки доказательства не отображается в текущем работающем агенте и должен быть неактивным, чтобы быть видимым, но кажется, что он проверяет то, что было выполнено в это время.
Показать оригинал
9
7,29 тыс.
Содержание этой страницы предоставляется третьими сторонами. OKX не является автором цитируемых статей и не имеет на них авторских прав, если не указано иное. Материалы предоставляются исключительно в информационных целях и не отражают мнения OKX. Материалы не являются инвестиционным советом и призывом к покупке или продаже цифровых активов. Раздел использует ИИ для создания обзоров и кратких содержаний предоставленных материалов. Обратите внимание, что информация, сгенерированная ИИ, может быть неточной и непоследовательной. Для получения полной информации изучите соответствующую оригинальную статью. OKX не несет ответственности за материалы, содержащиеся на сторонних сайтах. Цифровые активы, в том числе стейблкоины и NFT, подвержены высокому риску, а их стоимость может сильно колебаться. Перед торговлей и покупкой цифровых активов оцените ваше финансовое состояние и принимайте только взвешенные решения.