Автор: ChiHaoLu (chihaolu.eth) Джерело: medium Переклад: Шаноба, Golden Finance

Ця стаття присвячена розробці абстракції облікового запису (AA) у рішенні Aztec Layer 2 та пов’язаному з ним вмісту. Я цитую ряд офіційних ресурсів ацтеків, включаючи офіційну документацію, блоги та навчальні посібники. Будь ласка, знайдіть ці чудові ресурси в розділі посилань наприкінці статті!

Передісторія

У зв’язку з підвищеною складністю Aztec у порівнянні з іншими реалізаціями Native AA в ZK-Rollups, читачам може бути корисно мати певний контекст для кращого розуміння цієї статті.

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

Вступ

Погляньте на ацтеків

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

Ми всі знаємо, що в традиційних ZK-Rollups «ZK» не обов’язково означає конфіденційність; Це означає використання доказів з нульовим розголошенням (ZKP), щоб довести, що певні обчислення були виконані правильно поза мережею. Однак в Aztec конфіденційність реалізована в ZK-Rollup на додаток до масштабованості. Якщо копнути глибше, то в минулому деталі кожної транзакції були загальнодоступними в мережі, але в Aztec вхід і вихід кожної транзакції зашифровані. Ці транзакції перевіряються ZKP, щоб довести, що зашифрована інформація є точною та походить із відкритого тексту. Тільки користувач, який будує ці приватні транзакції, знає фактичну інформацію у вигляді відкритого тексту.

Навіть важливі символи ZK-Rollup, такі як Sequencer і Prover, не можуть визначити, що є відкритим текстом. Вся інформація про транзакцію, включаючи відправника, одержувача, дані про транзакцію та вартість переказу, прихована. Хоча деталі транзакції знають лише самі користувачі, вони все одно можуть довіряти правильності транзакції. Ця впевненість пов’язана з тим фактом, що тільки законні транзакції можуть генерувати дійсні докази з нульовим розголошенням, щоб довести їх точність.

Як реалізувати приватні транзакції та як перевірити їх основи – це велика тема, яка виходить за рамки цієї статті. Простіше кажучи, нам потрібен «додатковий рівень для перевірки доказів з нульовим розголошенням» для перевірки списків ZKP, кожен з яких перевіряє приватну транзакцію. Тому вони називаються «ZK-ZK-Rollups».

Що таке нуар?

В ацтекській мові використовується нативна абстракція облікового запису, що означає, що немає різниці між обліковим записом, що належить зовнішньому (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.jinse.cn/7128680_watermarknone.png «7128680»)

Що таке приватна нотатка? UTXO називається нотаткою, і ми обходимо це дерево нотаток, щоб отримати інформацію про приватну державу. Коли ми хочемо змінити приватну державу, кроки такі:

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

Механізм АА ацтеків

Що таке протокольний рівень і що таке прикладний рівень?

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

Розуміння нативної абстракції облікового запису вимагає глибшого розуміння того, як працює весь ланцюжок (припускаючи, що він називається «нативним», а логіка виконання АА природним чином пов’язана з певним протоколом Layer2). Наприклад, в епоху 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, ще однією реалізацією АА, ви побачите, що Aztec більше схожий на багатокористувацький підхід. Однак це більш глибока тема, яку ви можете дослідити самостійно.

Ключі у вашому обліковому записі Aztec

В Aztec кожен обліковий запис, як правило, має два майстер-ключі: ключ підпису та майстер-ключ конфіденційності.

Ключ підпису

Ключ підпису використовується для представлення авторизації користувача на виконання певної дії за допомогою закритого ключа. Простий приклад – коли користувач записує відкритий ключ, отриманий з ключа підпису, в договорі облікового запису. Потім згенерований підпис можна відновити в межах контракту, підписавши транзакцію або повідомлення за допомогою цього ключа підпису, щоб перевірити, чи він збігається з відкритим ключем, записаним у контракті (також відомим як ключ, контрольований власником, який зберігається у формі ключа). addressSolidity контракт гаманця).

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

! [eWwFvxmMF7pNt0axLcucSvjcig6QHMXl2HKH3luz.png] (https://img.jinse.cn/7128683_watermarknone.png «7128683»)

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

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

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

! [9WujRrvfd8YccfQkh9kbCtz0O1GVAKvNVJI7kXtm.png] (https://img.jinse.cn/7128684_watermarknone.png «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 (приватними нотатками), а режим виконання транзакції в EVM і Aztec абсолютно відрізняється.

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

Хеші та нонсети транзакцій

Коли користувач створює транзакцію локально, є два важливі елементи:

1. Адреса відправника: це адреса контракту облікового запису, який обробляє транзакцію. У цьому договорі облікового запису є точка входу, про яку ми згадували раніше, яка служить функцією перевірки для зовнішніх сторін, щоб перевірити, чи санкціонована дія (транзакція) власником облікового запису.
2. Дані корисного навантаження: сюди входить інформація про транзакцію, така як підпис, адреса контракту призначення, вартість, дані тощо.

! [xReWU4p6VrxP45q5EYNXZGAziaZhIG1DTrjeO4yD.png] (https://img.jinse.cn/7128688_watermarknone.png «7128688»)

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

Оскільки на рівні протоколу немає суворих вимог щодо nonce, Aztec не може скасувати транзакцію, що очікує на розгляд, надіславши нову транзакцію з тією самою та вищою комісією gas.

Виконати запит

Як вже говорилося раніше, користувач може вказати будь-яку функцію в договорі аккаунта в якості точки входу в залежності від ситуації, причому операція в Aztec не контролюється простим торговим об’єктом. По суті, те, що вказує контрактному рахунку, що робити, є об’єктом, який називається «запит на виконання». Об’єкт представляє поведінку користувача, наприклад “Виклик функції передачі на контракт з 0x1234 з наступних параметрів”.

Користувач ініціює транзакцію локально в гаманці, де sender_address — це адреса контракту облікового запису, що містить відповідні дані кодування функції у виклику корисного навантаження target contract transfer(), і підпис, який може бути перевірений контрактом облікового запису. Гаманець перетворює ці два елементи на запит на виконання.

Потім гаманець вводить приватну нотатку, ключ шифрування або недійсний секрет у локальну віртуальну машину, щоб імітувати цей запит на виконання. Під час процесу моделювання буде згенеровано трасування виконання, яке буде передано організатору для створення доказу з нульовим розголошенням. Цей доказ показує, що ці обчислення (виконання приватних функцій) дійсно виконуються користувачем локально.

Завдяки цьому процесу ми отримуємо дві частини інформації: доказ і private_data (вихід приватної схеми ядра для цієї транзакції). Потім гаманець надсилає об’єкт транзакції, що містить ці дві частини інформації, до мемпулу Aztec’s Sequencer і завершує транзакцію.

Клієнт-орієнтоване середовище виконання ZKP замість EVM-типу

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

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

З точки зору сторонньої людини, вони можуть бачити лише нові нікчеми та коментарі, і всі вони зашифровані. Отже, всі знають, що нова угода відбулася, але що саме відбувається всередині, відомо лише учасникам, які беруть участь у ній.

! [B2NwqMIhntBOllrlchIWeaetEbkSSdoTARJiM27A.png] (https://img.jinse.cn/7128690_watermarknone.png “7128690”)

Дізнайтеся більше про контракти на обліковий запис Aztec

Гаманець

Гаманці в Aztec є важливою частиною управління взаємодією користувачів з блокчейном та їхніми особистими даними. Ось короткий виклад завдань, з якими доводиться справлятися гаманцю Aztec:

1. Створіть обліковий запис: гаманець повинен дозволяти користувачам створювати нові контракти на облікові записи, що, по суті, означає розгортання нових контрактів на обліковий запис у блокчейні.
2. Керування приватним ключем: гаманець відповідає за керування початковою фразою користувача та приватним ключем, включаючи майстер-ключ конфіденційності та ключ підпису (залежно від дизайну контракту облікового запису). Це управління також можна поширити на інтеграцію апаратного гаманця.
3. Перегляд облікових записів: користувачі повинні мати можливість переглядати свої облікові записи та пов’язані з ними статуси, включаючи баланси та інші приватні статуси. Це означає, що гаманець повинен підтримувати локальну базу даних усіх приватних нотаток, пов’язаних з користувачем.
4. Взаємодійте з Dapps: Гаманці повинні полегшувати взаємодію між користувачами та Dapps. Коли користувач взаємодіє з децентралізованою програмою, вона може надіслати запит на надсилання транзакції з облікового запису користувача.
5. Згода користувача: Dapps можуть вимагати згоди користувача для відображення певних станів контракту, таких як баланс у контракті токена. Щоб розкрити ці стани, гаманець повинен мати можливість отримувати запити користувачів (оскільки розкриття балансів вимагає згоди ключа користувача).
6. Створіть доказ: щоб надіслати транзакцію від імені користувача, гаманець повинен мати можливість згенерувати доказ локально. Це передбачає створення та обробку доказів дійсності транзакцій з нульовим розголошенням.

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

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

Договір на обліковий запис

В Aztec основними завданнями договору облікового запису є перевірка підписів (підтвердження того, що транзакції авторизовані власником облікового запису, а отже, більш широко авторизовані, а не обов’язково «перевірені певним алгоритмом цифрового підпису»), управління споживанням газу та виклик інших контрактів.

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

! [LahY9kfNGKkYkSm5ULPlReKATiTA3K5bjFGIClh0.png] (https://img.jinse.cn/7128692_watermarknone.png «7128692»)

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

! [OskBKScb0LqWpcTMIuhBMjeSB151sFvSWbwXl.png] (https://img.jinse.cn/7128697_watermarknone.png «7128697»)

Aztec не вимагає імпорту контрактів наших облікових записів до бібліотек облікових записів EntrypointPayload і Aztec AA; Ви можете створити власну логіку контракту з обліковим записом.

! [HNskT1CkOOPiZZaAVvqlJNf7L5VxU39Fz9ir2Ica.png] (https://img.jinse.cn/7128698_watermarknone.png «7128698»)

— це контекст, об’єкт, який доступний у кожній функції в Aztec.nr. Містить всю інформацію про ядро, необхідну для виконання контекстної програми. Цитата з офіційної документації ацтеків. - Що таке фон

Вище наведено код entrypoint() бібліотеки облікових записів Aztec AA. Він відповідає за визначення того, чи авторизована операція власником облікового запису на основі функції перевірки (), визначеної в контракті облікового запису, _impl_valid і робить необхідні виклики для виконання _calls операції, необхідної для транзакції.

Це означає, що якщо ви хочете посилатися на цю бібліотеку Aztec AA, а ваш контракт облікового запису не має реалізації is_valid_impl з тим самим сигнатурою функції, цей крок не вдасться.

! [QZuhkG4BTiKMQF4hFZKGw0gi9MBlU5VGcDjyQyU9.png] (https://img.jinse.cn/7128699_watermarknone.png «7128699»)

Ще однією ключовою деталлю реалізації є використання get_auth_witness() для отримання підписів. Ви можете звернутися до наведених нижче посилань, щоб більше дізнатися про те, як працюють Свідки. Простими словами, свідок – це «дозвіл користувачеві робити те, що він хоче».

Аутентифікація свідка — це схема перевірки операцій на Aztec, за допомогою якої користувачі можуть дозволити третім сторонам, таким як протоколи або інші користувачі, виконувати дії від їхнього імені. Цитата з офіційної документації ацтеків. — Сертифіковані свідки

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

Наприклад, скажімо, є операція, яка переказує 1000 токенів з облікового запису Аліси на DeFi-платформу. У цьому випадку контракт токена повинен запитати контракт облікового запису Аліси, щоб дізнатися, чи схвалює вона «дію». Ця «дія» вимагає, щоб у гаманці Аліси (локально) був згенерований свідок автентифікації, який потім можна перевірити за допомогою контракту з її обліковим записом. Якщо контракт облікового запису успішно верифіковано, токен-контракт знатиме, що “дія” авторизована.

! [WJkuu8NWicgcHvCyH08YpHhjYtTtYiP8GbRxwwKs.png] (https://img.jinse.cn/7128700_watermarknone.png “7128700”)

Висновок

На даний момент Aztec не впровадили механізм зборів, і їхня мета також полягає в тому, щоб абстрагуватися від сплати зборів. Це означає, що для того, щоб транзакція вважалася дійсною, вона повинна довести, що вона заблокувала достатньо коштів для покриття власних комісій. Однак він не уточнює, звідки мають надходити ці кошти, що робить платежі або платежі в натуральній формі легко можливими через миттєвий обмін.