Автор: ChiHaoLu (chihaolu.eth) Источник: medium Перевод: Shanoba, Golden Finance

Эта статья посвящена разработке Account Abstraction (AA) в решении Aztec Layer 2 и связанному с этим контенту. Я привожу ряд официальных ресурсов Aztec, включая официальную документацию, блоги и учебные пособия. Пожалуйста, найдите эти замечательные ресурсы в разделе ссылок в конце статьи!

Предыстория

Из-за возросшей сложности Aztec по сравнению с другими реализациями Native AA в ZK-Rollups, читателям может быть полезно иметь некоторый контекст для лучшего понимания этой статьи.

• Знакомство со смарт-контрактными кошельками и их особенностями
• Знакомство с EIP-4337
• Знакомство с нативной абстракцией аккаунта в ZK-Rollups
• Основные понятия UTXO
• Основная концепция ZK-Rollups
• Основные понятия программ доказательства с нулевым разглашением

Введение

Взгляните на ацтеков

Aztec — это сеть 2-го уровня с открытым исходным кодом, предназначенная для обеспечения масштабируемости и защиты конфиденциальности Ethereum. Aztec использует доказательства zkSNARK для обеспечения защиты конфиденциальности и масштабируемости с помощью сервиса ZK-Rollup. Пользователям Aztec не нужны какие-либо доверенные третьи стороны или дополнительные механизмы консенсуса для доступа к частным транзакциям.

Все мы знаем, что в традиционных ZK-роллапах “ZK” не обязательно означает конфиденциальность; Это означает использование доказательств с нулевым разглашением (ZKP) для доказательства того, что определенные вычисления были правильно выполнены вне сети. Однако в Aztec конфиденциальность реализована в ZK-Rollup в дополнение к масштабируемости. Если копнуть глубже, то в прошлом детали каждой транзакции были общедоступны в блокчейне, но в Aztec вход и выход каждой транзакции зашифрованы. Эти транзакции проверяются ZKP, чтобы доказать, что зашифрованная информация является точной и получена открытым текстом. Только пользователь, создающий эти частные транзакции, знает фактическую информацию в виде открытого текста.

Даже важные символы в ZK-Rollup, такие как Sequencer и Prover, не могут определить, что является открытым текстом. Вся информация о транзакции, включая отправителя, получателя, данные транзакции и сумму перевода, скрыта. Несмотря на то, что детали транзакции знают только сами пользователи, они все равно могут доверять правильности транзакции. Эта уверенность проистекает из того факта, что только законные транзакции могут генерировать действительные доказательства с нулевым разглашением, чтобы доказать их точность.

Как реализовать приватные транзакции и как проверить их основы — это большая тема, которая выходит за рамки этой статьи. Проще говоря, нам нужен «дополнительный уровень для проверки доказательств с нулевым разглашением» для проверки списков ZKP, каждый из которых проверяет частную транзакцию. Вот почему они называются «ZK-ZK-Rollups».

Что такое нуар?

В Aztec используется собственная абстракция учетной записи, что означает, что нет никакой разницы между внешней учетной записью (EOA) и контрактной учетной записью. Все аккаунты являются смарт-контрактами. Поэтому мы дадим краткий обзор экосистемы разработки контрактов Aztec, так как очень важно понимать разработку контрактов. Однако, если вы не планируете разрабатывать договор аккаунта самостоятельно, то чтение и понимание этой статьи не требует от вас включать компьютер и писать договор. Нужно просто понимать логику в коде контракта аккаунта. Вы можете исследовать глубину темы на свое усмотрение!

Noir — это язык для написания программ SNARK, похожий на Circcom и ZoKrates. Он не только позволяет автоматически генерировать контракты Solidity Verifier после создания схемы, но также может быть использован для написания собственных протоколов или даже блокчейнов. Поскольку Noir не полностью полагается на Aztec (он не компилируется в конкретную систему доказательств), вы можете достичь своих целей, внедрив бэкенд-сервер и интерфейс смарт-контрактов для системы доказательств.

В Aztec Noir используется для написания смарт-контрактов, в которых переменные (состояния) и функции могут быть защищены конфиденциальностью.

Что такое приватный статус и личные заметки

Согласно нашему пониманию публичных блокчейнов, обычно все государства являются публичными. В ацтекском языке важно понимать концепцию частного государства и то, как им управлять (добавлять, изменять, удалять). Частное состояние зашифровано и принадлежит его владельцу. Например, если я являюсь владельцем контракта, определенная переменная в этом контракте может быть зашифрована и скрыта в закрытом состоянии. Только я, как владелец этого частного состояния, могу расшифровать зашифрованный текст, чтобы получить открытый текст.

Закрытое состояние сохраняется путем присоединения только дерева базы данных. Это делается потому, что непосредственное изменение значения состояния может привести к утечке большого количества информации из диаграммы транзакций. Однако в базе данных напрямую не хранится значение закрытого состояния. Вместо этого он записывает их как личные заметки в зашифрованном виде (например, x=0 -> x=1), addr=0x00 -> addr=0x01. Таким образом, на самом деле эти приватные переменные, хотя и кажутся переменными, на самом деле состоят из набора неизменяемых приватных заметок. Это абстракция переменных. Если не понятно, идем дальше.

Если необходимо удалить закрытое состояние, можно добавить недопустимые символы, относящиеся к этому частному состоянию, в другую недопустимую базу данных, чтобы сделать ее недействительной. Если вам нужно изменить закрытое состояние, сначала сделайте его недействительным, а затем добавьте к нему новый частный комментарий.

Вскоре мы рассмотрим концепцию обнулителей. Вы можете думать об этом как о ключе, который вам нужен, чтобы связать частную заметку с ее недопустимым символом. Только владелец недействительного ключа может идентифицировать и использовать связанную с ним частную заметку.

К этому моменту опытные читатели, возможно, заметили, что эта структура очень похожа на UTXO (неизрасходованные выходные данные транзакций), и мы можем перебирать UTXO, чтобы определить текущее состояние частного состояния (хотя важно помнить, что транзакцию подписывает пользователь, а не UTXO; Мы объясним это позже).

! [TEg3TOpeZXF82AgjnmG7in3uwiZp3ZtIpGsNQvxc.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-2ad04801d9-dd1a6f-cd5cc0.webp «7128680»)

Что такое частная заметка? UTXO называется Note, и мы проходим по этому дереву заметок, чтобы получить информацию о частном состоянии. Если мы хотим изменить частное состояние, выполните следующие шаги:

1. Пользователь извлекает все личные заметки, связанные с этим частным статусом, из базы данных заметок.
2. Пользователь (который на самом деле является узлом Aztec, который он запускает) локально подтверждает существование каждой полученной аннотации в этом дереве БД.
3. Пользователь добавляет недопустимый символ, чтобы другие пользователи не могли прочитать тот же лист снова.
4. Пользователь вставляет новый лист (новый комментарий) для обновления значения этого приватного состояния.

Ацтекский механизм АА

Что такое уровень протокола и что такое прикладной уровень?

Как мы все знаем, EIP-4337 направлен на то, чтобы перенести весь процесс транзакций на прикладной уровень, реализовать открытую ретрансляционную систему и абстрагировать подпись (механизм проверки) и модель оплаты с помощью программируемой природы смарт-контрактов. Тем не менее, для Native Account Abstraction, будь то в эру StarkNet, zkSync или Aztec, которая находится в центре внимания этой статьи, определенные элементы должны быть выгравированы в протоколе уровня 2, чтобы функционировать должным образом. Например, в Aztec ключи шифрования и недействительные ключи должны быть реализованы на уровне протокола.

Понимание абстракции машинной учетной записи требует более глубокого понимания того, как работает вся цепочка (предполагая, что она называется «родной», а логика выполнения AA естественным образом связана с конкретным протоколом уровня 2). Например, в эпоху zkSync необходимо понимать системный контракт, в StarkNet — понимать, как работает секвенсор, а в Aztec — роль этих «ключей и лежащее в их основе частное состояние».

Точки входа в аккаунт и этапы верификации

В Aztec, в отличие от других реализаций абстракции учетной записи, нет строго определенного имени функции (сигнатуры функции) в качестве точки входа в контракт учетной записи (например, validateUserOp в EIP-4337, validateTransactionzkSync Era и __validate__StarkNet). Пользователь может выбрать любую функцию в контракте счета в качестве точки входа и отправить транзакцию с соответствующими параметрами.

Функция, выбранная пользователем (мы называем ее entrypoint()), должна быть приватной (выполняться в приватной среде выполнения пользователя). Он может быть вызван только из клиента владельца контракта аккаунта (кошелька пользователя). Когда entrypoint() кошелька пользователя выполняется локально, он также генерирует доказательство с нулевым разглашением. Эта аттестация информирует протокол Aztec на этапе проверки о том, что выполнение вне цепочки произошло и прошло успешно.

Ограничения этапа валидации

Это также относится к вопросу о том, следует ли вводить ограничения на то, что можно делать на этапе валидации. Хорошо известно, что, поскольку для проверки транзакций нет ограничений по стоимости (по сути, проверка транзакций является представлением функции), злоумышленник может выполнить атаку типа «отказ в обслуживании» (DOS) на мемпул, чтобы скомпрометировать сборщик (EIP-4337) или оператор/секвенсор (собственный AA). EIP-4337 определяет, какие коды операций запрещены и как ограничивается доступ к хранилищу. zkSync Era немного ослабляет использование OpCode, в то время как StarkNet вообще не разрешает вызовы внешних контрактов.

Поскольку протокол Aztec предполагает, что клиент проверяет прикрепленное доказательство с нулевым разглашением, а не фактически вызывает функцию проверки, чтобы определить, что результат равен или , trueAztecfalse, в отличие от других протоколов, не накладывает никаких ограничений на этапе проверки. Точка входа контракта в учетной записи может свободно вызывать другие контракты, получать доступ к любому хранилищу и выполнять любые вычисления.

Поток взаимодействия

Более детально, в zkSync Era и StarkNet инициировать транзакцию может только “контракт учетной записи”, потому что протокол вызывает указанную функцию в качестве точки входа, накладывая это ограничение. Тем не менее, в Aztec «все контракты» могут инициировать транзакции, поскольку нет ограничений на то, какую функцию протокол вызывает в качестве точки входа. Это означает, что в Aztec это больше не фиксированный поток взаимодействия, в котором пользователь отправляет транзакцию определенной роли (например, контракту EntryPoint в EIP-4337 или секвенсору/оператору в Native AA), а затем вызывает целевой контракт. Пользователи могут отправлять транзакции через кошелек и напрямую позволять целевому контракту завершать соответствующие взаимодействия, что значительно повышает гибкость.

Если вы знакомы с EIP-2938, еще одной реализацией AA, вы обнаружите, что Aztec больше похож на многопользовательский подход. Однако это более глубокая тема, которую вы можете исследовать самостоятельно.

Ключи в аккаунте Aztec

В Aztec каждая учетная запись обычно имеет два главных ключа: ключ подписи и мастер-ключ конфиденциальности.

Ключ подписи

Ключ подписи используется для представления полномочий пользователя на выполнение определенного действия с помощью закрытого ключа. Простой пример: пользователь записывает открытый ключ, полученный из ключа подписи, в контракте учетной записи. Затем сгенерированную подпись можно восстановить в контракте, подписав транзакцию или сообщение с помощью этого ключа подписи, чтобы проверить, соответствует ли он открытому ключу, записанному в контракте (также известному как ключ, контролируемый владельцем, который хранится в виде ключа). addressSolidity wallet).

Выбор алгоритма эллиптической кривой цифровых подписей остается за пользователем. Например, Ethereum использует secp256k1, в то время как Aztec предоставляет пример schnorr для использования. В контракте учетной записи функция entrypoint() выступает в качестве точки входа (источника вызова) и используется логикой валидации (is_valid_impl()) для проверки того, соответствует ли подпись Шнорра открытому ключу записи std::schnorr::verify_signature(…).

! [eWwFvxmMF7pNt0axLcucSvjcig6QHMXl2HKH3luz.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-3454e57f80-dd1a6f-cd5cc0.webp «7128683»)

Ключ подписи, по сути, такой же, как и ключ, контролируемый владельцем, в кошельке смарт-контракта, с которым мы знакомы, поэтому он должен быть относительно прост для понимания. На самом деле, ключи подписи не являются абсолютно необходимыми. Если разработчик учетной записи реализовал другой механизм проверки, у учетной записи может отсутствовать ключ подписи.

Мастер-ключ конфиденциальности

Мастер-ключ конфиденциальности в вашей учетной записи Aztec не подлежит передаче; Каждый аккаунт Aztec привязан к приватному мастер-ключу. Закрытый мастер-ключ извлекает публичный мастер-ключ, который затем хешируется с кодом контракта для генерации адреса контракта учетной записи.

! [9WujRrvfd8YccfQkh9kbCtz0O1GVAKvNVJI7kXtm.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-709665cdb6-dd1a6f-cd5cc0.webp «7128684»)

Мы public_master_key account_address, partial_address и в совокупности как полный адрес учетной записи. При работе с закрытым состоянием пользователь должен предоставить эти три части информации, чтобы любой мог проверить, соответствует ли открытый ключ предполагаемому адресу.

Однако, если это public_master_key приложение, которое не предназначено для обработки частного состояния и отсутствует (например, DeFi), вы можете просто заполнить это public_master_key поле 0, чтобы указать, что оно не хочет получать частные заметки.

Таким образом, в то время как Aztec позволяет нам реализовать механизм проверки и даже какой-то механизм восстановления в контракте учетной записи для повышения безопасности учетной записи, механизм, связанный с мастер-ключом конфиденциальности, печатается в протоколе и привязан к адресу. Поэтому он не является взаимозаменяемым.

Подразумевается, что этот ключ так же важен, как и закрытый ключ EOA (внешней учетной записи) в Ethereum, что делает его единой точкой отказа (SPoF) для учетной записи. Если пользователь потеряет или мастер-ключ конфиденциальности учетной записи будет украден, нет никаких сомнений в том, что учетная запись не подлежит восстановлению.

Главный ключ конфиденциальности также использует процесс, аналогичный BIP-32, для экспорта ключей шифрования и недействительных ключей. Пользователи могут использовать разные ключи шифрования и недействительные ключи в разных приложениях или действиях для обеспечения конфиденциальности и безопасности.

Ключ шифрования

Открытый ключ ключа шифрования используется для шифрования закрытой заметки, а закрытый ключ — для ее расшифровки. Например, в сценарии передачи токена, если я (отправитель токена) хочу передать токены своему другу (получателю токена), мне нужно зашифровать приватную заметку (передача токенов включает в себя изменение переменных, по сути баланс заключается в изменении приватной переменной состояния UTXO с помощью криптографического открытого ключа моего друга) и отправить ее.

С точки зрения стороннего наблюдателя, не зная криптографического закрытого ключа получателя токена, он не может расшифровать эту приватную заметку или узнать, кто является получателем токена.

Нулевой символ

Каждый раз, когда используется частная заметка, генерируется недопустимый символ, производный от этого личного комментария (зашифрованный недействительным ключом). Этот механизм используется для предотвращения двойного расходования (чтобы другие не использовали тот же метод для определения местонахождения банкноты или списания средств дважды), потому что протокол Aztec проверяет, являются ли недействительные символы уникальными. Для того, чтобы сопоставить этот недопустимый символ с закрытой заметкой, для его расшифровки требуется недействительный закрытый ключ, поэтому только его владелец может установить связь между ними.

Ацтекские транзакции

Описание концепции транзакции в Aztec может быть сложной задачей, потому что ее можно легко спутать с UTXO (Private Notes), а режим выполнения транзакции в EVM и Aztec совершенно разный.

В Aztec каждая транзакция транслируется в виде доказательства с нулевым разглашением (очевидно, из соображений конфиденциальности). Пользователи должны выполнять вычисления локально на своих узлах (приложениях-кошельках или клиентах) для создания доказательств, соответствующих транзакциям, а не просто отправлять объекты транзакций в мемпул майнера или любому оператору уровня 2 через RPC API, как мы делали раньше.

Хеши транзакций и одноразовые номера

Когда пользователь создает транзакцию локально, есть два важных элемента:

1. Адрес отправителя: Представляет собой адрес контракта учетной записи, который обрабатывает транзакцию. В этом контракте учетной записи есть точка входа, о которой мы упоминали ранее, которая служит функцией проверки для внешних сторон, чтобы проверить, санкционировано ли действие (транзакция) владельцем учетной записи.
2. Полезные данные: Сюда входит информация о транзакции, такая как подпись, адрес контракта назначения, значение, данные и т. д.

! [xReWU4p6VrxP45q5EYNXZGAziaZhIG1DTrjeO4yD.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-c9db8c15b3-dd1a6f-cd5cc0.webp «7128688»)

На уровне протокола Aztec хэш каждой действительной транзакции используется в качестве средства предотвращения многократного выполнения одной и той же транзакции. Разработчик контракта учетной записи может решить, должен ли быть одноразовый номер в контракте учетной записи и связанной с ним логике. Например, они могут устанавливать такие требования, как обеспечение того, чтобы поле nonce в транзакции было строго увеличено или чтобы транзакция могла быть обработана в любом порядке.

Поскольку на уровне протокола нет строгого требования к одноразовым номерам, Aztec не может отменить ожидающую транзакцию, отправив новую транзакцию с тем же одноразовым номером и более высокой комиссией за газ.

Выполнить запрос

Как уже говорилось ранее, пользователь может указать любую функцию в контракте счета в качестве точки входа в зависимости от ситуации, а работа в Aztec не контролируется простым торговым объектом. На самом деле, то, что сообщает учетной записи контракта, что делать, является объектом, называемым «запросом на выполнение». Объект представляет поведение пользователя, например “Вызов функции передачи контракта с 0x1234 следующих параметров”.

Пользователь инициирует транзакцию локально в кошельке, где sender_address — это адрес контракта учетной записи, содержащий соответствующие кодировочные данные функции в целевом контракте вызова полезной нагрузки transfer(), и подпись, которая может быть проверена контрактом учетной записи. Кошелек преобразует эти два элемента в запрос на выполнение.

Затем кошелек вводит закрытую заметку, ключ шифрования или недопустимый секрет в локальную виртуальную машину, чтобы имитировать этот запрос на выполнение. В процессе моделирования будет сгенерирована трассировка выполнения, которая будет передана проверяющему для создания доказательства с нулевым разглашением. Это доказательство показывает, что эти вычисления (выполнение приватных функций) действительно выполняются локально пользователем.

Благодаря этому процессу мы получаем две части информации: proof и private_data (выходные данные закрытого контура ядра для этой транзакции). Затем кошелек отправляет объект транзакции, содержащий эти два фрагмента информации, в мемпул Aztec Sequencer и завершает транзакцию.

Клиентская ZKP вместо среды выполнения типа EVM

В Aztec мы не просто вводим всю информацию в машину Тьюринга, такую как EVM, для создания обновленного состояния. Вместо этого он полагается на схему внутри каждого Dapp, чтобы определить, как должна работать информация о конфиденциальности. Это означает, что разработчики децентрализованных приложений должны иметь способ доказать состояние переменных контракта. Для примера рассмотрим баланс пользователя в контракте токена ERC-20. Если мы хотим перевести 10 токенов DAI, то контракт может иметь следующую логику:

1. Проверьте, превышает ли баланс отправителя 10 DAI (т.е. > 10 DAI).
2. Если у отправителя достаточно средств на балансе, создается недействительный символ, указывающий на уничтожение 10 DAI отправителя (что может компенсировать владение отправителем частной запиской 10 DAI).
3. Создайте новую личную заметку для получателя.
4. Широковещательная передача и шифрование всех сообщений, передаваемых с помощью 10 DAI.

С точки зрения стороннего наблюдателя, они могут видеть только новые null и комментарии, и все они зашифрованы. Итак, все знают, что новая сделка состоялась, но что именно происходит внутри, известно только вовлеченным участникам.

! [B2NwqMIhntBOllrlchIWeaetEbkSSdoTARJiM27A.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-e6bc34e04b-dd1a6f-cd5cc0.webp «7128690»)

Узнать больше о контрактах аккаунтов Aztec

Кошелек

Кошельки в Aztec являются важной частью управления взаимодействием пользователей с блокчейном и их личными данными. Вот краткое изложение задач, с которыми приходится справляться кошельку Aztec:

1. Создайте учетную запись: кошелек должен позволять пользователям создавать новые контракты учетной записи, что, по сути, означает развертывание новых контрактов учетной записи в блокчейне.
2. Управление приватным ключом: Кошелек отвечает за управление seed-фразой и приватным ключом пользователя, включая мастер-ключ конфиденциальности и ключ подписи (в зависимости от дизайна контракта учетной записи). Это управление также может быть распространено на интеграцию аппаратных кошельков.
3. Просмотр счетов: Пользователи должны иметь возможность просматривать свои учетные записи и связанные с ними статусы, включая балансы и другие частные статусы. Это означает, что кошелек должен поддерживать локальную базу данных всех личных заметок, связанных с пользователем.
4. Взаимодействуйте с децентрализованными приложениями: кошельки должны облегчать взаимодействие между пользователями и децентрализованными приложениями. Когда пользователь взаимодействует с децентрализованным приложением, децентрализованное приложение может запросить отправку транзакции из учетной записи пользователя.
5. Согласие пользователя: Dapps может потребовать согласие пользователя на отображение определенных состояний контракта, таких как баланс в контракте токена. Чтобы раскрыть эти состояния, кошелек должен иметь возможность получать запросы пользователей (так как для раскрытия балансов требуется согласие ключа пользователя).
6. Сгенерировать доказательство: Чтобы отправить транзакцию от имени пользователя, кошелек должен иметь возможность сгенерировать подтверждение локально. Это включает в себя создание и обработку доказательств действительности транзакций с нулевым разглашением.

Ключевой момент, который следует отметить, заключается в том, что кошелек должен сканировать все блоки, начиная с генезис-блока, использовать ключ пользователя для обнаружения и расшифровки соответствующих частных заметок, а затем хранить их в локальной базе данных для использования в будущем. Это имеет решающее значение для упрощения взаимодействия с пользователем и обеспечения эффективного управления частными государственными данными.

Вы упомянули еще один важный аспект Aztec, который заключается в том, что пользователи должны транслировать полный адрес. Когда кошелек создает криптобанкноту для получателя целевой транзакции, он также должен иметь возможность получить полный адрес получателя. Этого можно добиться, вручную вводя или поддерживая локальную базу данных адреса получателя. Для получения более подробной информации, пожалуйста, обратитесь к официальной документации Aztec.

Договор учетной записи

В Aztec основными задачами контракта учетной записи являются проверка подписей (подтверждение того, что транзакции санкционированы владельцем учетной записи, и, следовательно, санкционированы в более широком смысле, а не обязательно «проверены определенным алгоритмом цифровой подписи»), управление потреблением газа и вызов других контрактов.

Это официальный пример контракта аккаунта Aztec с использованием алгоритма подписи Шнорра. Точкой входа для всех транзакций является функция entrypoint() (вы можете выбрать функцию или имя в качестве отправной точки, но в этом случае используется entrypoint()).

! [LahY9kfNGKkYkSm5ULPlReKATiTA3K5bjFGIClh0.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-be4c89f0e2-dd1a6f-cd5cc0.webp «7128692»)

Когда мы вызываем учетную запись entrypoint() с полезной нагрузкой вложения, контракт учетной записи entrypoint() вызовет библиотеку учетных записей Aztec AA entrypoint().

! [OskBKScb0LqWpcTMIuhBMjeSB151sFvSWbwXl.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-c46b7b5d32-dd1a6f-cd5cc0.webp «7128697»)

Aztec не требует, чтобы наши контракты учетных записей импортировались в библиотеки учетных записей EntrypointPayload и Aztec AA; Вы можете разработать свою собственную логику контракта учетной записи.

! [HNskT1CkOOPiZZaAVvqlJNf7L5VxU39Fz9ir2Ica.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-dbf6df09b4-dd1a6f-cd5cc0.webp «7128698»)

— это контекст, объект, доступный в каждой функции в Aztec.nr. Содержит всю информацию о ядре, необходимую для выполнения контекстного приложения. Цитата из официальной документации ацтеков. - Что такое предыстория

Выше приведен код entrypoint() библиотеки учетных записей Aztec AA. Он отвечает за определение того, авторизована ли операция владельцем учетной записи на основе функции проверки (), определенной в контракте account is_valid_impl, и выполняет необходимые вызовы для реализации _calls операции, необходимой для транзакции.

Это означает, что если вы хотите сослаться на эту библиотеку Aztec AA, а ваш контракт учетной записи не имеет реализации is_valid_impl с той же сигнатурой функции, этот шаг не будет выполнен.

! [QZuhkG4BTiKMQF4hFZKGw0gi9MBlU5VGcDjyQyU9.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-92b47183b4-dd1a6f-cd5cc0.webp «7128699»)

Еще одна ключевая деталь реализации заключается в использовании get_auth_witness() для получения подписей. Вы можете обратиться к приведенным ниже ссылкам, чтобы узнать больше о том, как работают Свидетели. Говоря простыми словами, следящий сервер — это «разрешение пользователю делать то, что он хочет».

Следящий сервер аутентификации — это схема проверки операций в Aztec, позволяющая пользователям разрешать третьим сторонам, таким как протоколы или другие пользователи, выполнять действия от их имени. Цитата из официальной документации ацтеков. — Сертифицированные свидетели

Причина, по которой он называется «свидетель», а не просто «подпись», заключается в том, что способ проверки контракта учетной записи не обязательно включает в себя проверку подписи.

Например, предположим, что есть операция, которая переводит 1000 токенов со счета Алисы на DeFi-платформу. В этом случае контракт токена должен запросить контракт учетной записи Алисы, чтобы узнать, одобряет ли она «действие». Это «действие» требует, чтобы в кошельке Алисы (локально) был сгенерирован свидетель аутентификации, который затем можно проверить с помощью контракта учетной записи. Если контракт учетной записи успешно проверен, контракт токена будет знать, что «действие» было авторизовано.

! [WJkuu8NWicgcHvCyH08YpHhjYtTtYiP8GbRxwwKs.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-a797a836e2-dd1a6f-cd5cc0.webp “7128700”)

Заключение

На данный момент Aztec не внедрил механизм оплаты, и их цель также состоит в том, чтобы абстрагироваться от уплаты сборов. Это означает, что для того, чтобы транзакция считалась действительной, она должна доказать, что она заблокировала достаточно средств для покрытия собственных комиссий. Однако в нем не уточняется, откуда должны поступать эти средства, что делает платежи или платежи в натуральной форме легко возможными посредством мгновенного обмена.