Автор: @Toni Wahrstätter Переклад: DeBox Institute
Передмова
Віталік рекомендує використовувати zk-SNARK, щоб відокремити рахунки торгової логіки від рахунків, що містять активи. Це покращує конфіденційність, взаємодію з користувачем і соціальне відновлення в один клік. Дослідник Ethereum Тоні Варштеттер надає детальний аналіз цього прототипу гаманця, охоплюючи робочий процес і переваги.
Велика подяка Мету за чудові дискусії на цю тему та за розробку цього інструменту для аналізу кожного контракту та розміщення його в розрідженому дереві Merkle, яке спрощує створення прототипів, усуваючи потребу в zk-доказах на дереві patricia. Також дякую Віталіку за його чудовий внесок.
Керування декількома обліковими записами може бути складним через низку причин, зокрема соціальне відновлення, конфіденційність, рівень 2 і загальні проблеми з користувачем. Використання прихованої адреси ускладнює роботу, оскільки для кожної взаємодії потрібен новий обліковий запис. Віталік рекомендує використовувати zk-SNARK, щоб відокремити рахунки торгової логіки від рахунків, що містять активи. Це покращує конфіденційність, взаємодію з користувачем і соціальне відновлення в один клік.
Щодо наступного, я рекомендую спочатку перевірити допис Віталіка "Три трансформації", щоб отримати довідкову інформацію.
У двох словах, ми намагаємося досягти:
**Єдине соціальне відновлення без шкоди для конфіденційності. **
1. Традиційний метод
Проста, але загрозлива конфіденційність реалізація виглядає так:
Користувач надає підпис і певний намір/команду до рахунку зберігання активів.
Рахунок зберігання активів пересилає підпис до логічного рахунку зберігання.
Обліковий запис логічного зберігання отримує відкритий ключ із підпису та порівнює його зі збереженим відкритим ключем.
Якщо перевірку пройдено, логічний обліковий запис повідомить обліковий запис активів для продовження операції.
Рахунок зберігання активів виконує накази користувача.
Недоліком є те, що це відкрито пов’язує логічні облікові записи та облікові записи активів, тим самим ставлячи під загрозу конфіденційність.
2. Використовуйте ZK-SNARK
Використовуючи zk-SNARK, користувачі можуть довести, що вони мають право витрачати, не розкриваючи зв’язку між логічним рахунком холдингу та рахунком холдингу активів.
Робочий процес такий:
Користувач будує дерево Merkle локально та визначає листки, що містять його контракт.
1.1 Дерево Merkle містить значення slot0 і slot1 кожного існуючого контракту, відсортовані за датою або назвою.
1.2 Кожен користувач може створити дерево Merkle локально на основі останнього стану.
Користувач створює доказ zk, щоб довести, що він знає секрет у логічному обліковому записі. Детальний доказ пізніше.
Користувач надсилає zk-proof на рахунок зберігання активів.
Сертифікат підтвердження рахунку активів, що підтверджує таке:
4.1 Користувачі знають, де логіка.
4.2 Користувач знає секретне значення, яке хешується та зіставляється зі значенням, що зберігається в логічному обліковому записі.
4.3 Користувачі можуть реконструювати стан облікового запису, корінь дерева Merkle, який підтримується в канонічному ланцюжку (наприклад, попередньо скомпільований)
4.4 Використовуйте правильні випадкові числа (використовуються для перемикання ключів у логічних рахунках).
По суті, користувач може сказати: «У мене є підтверджений дозвіл від логічного облікового запису на виконання цієї дії, і я знаю місцезнаходження цього логічного облікового запису».
перевага
Взаємодія з користувачем: одним закритим ключем або одним налаштуванням мультипідпису можна керувати декількома обліковими записами, навіть якщо вони знаходяться на різних L2.
Відновлення: облікові записи можна легше відновити за допомогою одного оновлення контракту.
Конфіденційність: немає публічних посилань між обліковими записами.
Сумісність: це допомагає популяризувати гаманці Account Abstraction (AA) та інші функції.
Крім того, шляхом додавання ще одного контракту (агрегатора) між логікою та договором утримання активів можна надати кілька підтверджень різних рахунків утримування активів в одній транзакції, що дозволяє розглядати обліковий запис майже як UTXO. Агрегатори зможуть отримати кілька сертифікатів zk і переслати їх на відповідні рахунки активів для перевірки. Звичайно, такий агрегатор міг би створювати зв’язки — включаючи конфіденційність — між окремими рахунками активів.
Варто зазначити, що вибір між використанням SNARK (і, отже, покладенням на його безпеку) і невикористанням SNARK взагалі (і, таким чином, втратою хороших властивостей конфіденційності), не обов’язково є вибором «або-або». Компромісом може бути використання підтвердження SNARK для відкриття тимчасового вікна в логічному контракті про утримування з наступною короткою затримкою, після якої власник логічного контракту утримання може змінити значення slot0, замість того, щоб вимагати підтвердження SNARK для витрачання та таким чином змінити логіку споживання. Поточний власник контракту може використовувати затримку до відкриття вікна часу, щоб запобігти оновленню облікових даних.
технічні деталі
Налаштування zk-SNARK включає приватні елементи:
Ключ, який використовується для перевірки.
Логічна адреса холдингового рахунку – це адреса, на яку вказує рахунок активів.
Гілка Merkle для визначення значень конкретного стану.
Одноразовий номер, який дозволяє обертати ключі, роблячи старі ключі недійсними. Приватні елементи, такі як адреси та секрети договорів логічного зберігання відкритого тексту, не оприлюднюються, але використовуються для приватного зв’язування логічних холдингових рахунків і рахунків холдингу активів. Генеруючи докази для всього стану, немає потреби центральному органу будувати дерево Меркла для надання доказів.
1. Логічний балансовий рахунок
Прототип логічного холдингового рахунку може виглядати так:
твердість прагми >=0,7,0 <0,9,0;
контракт LogicHoldingAccount is Ownable { uint256 public slot0 = 0x1234; // хешований секрет uint256 public nonce = 0; // відслідковувати ключові зміни адреси публічного власника;
функція updateOwner(uint256 newValue) public onlyOwner { nonce += 1; slot0 = нове значення;
slot0: публічна змінна, яка спочатку містить хеш-значення. Лише власник знає хешований прообраз.
nonce: Лічильник, який відстежує кількість оновлень інформації про власника. Це гарантує, що старі ключі стануть недійсними.
updateOwner(uint256 newValue): функція, яка оновлює значення та додає випадкове число.
Цей контракт відстежує поточну логіку витрат власника (slot0) і дозволяє оновлення через функцію updateOwner.
2. Обліковий запис
твердість прагми >=0,7,0 <0,9,0;
контракт AssetHoldingAccount { uint256 public logicHoldingAccountHash = 1234...;
// Розмір скалярного поля, розмір базового поля, дані ключа перевірки тощо // ...
функція verifyProof( uint [2] calldata _pA, uint [2] [2] calldata _pB, uint [2] calldata _pC, uint [2] calldata _pubSignals) public view повертає (bool val) { // код складання Snarkjs для перевірки доказів... // ... }
Рахунки для зберігання активів зберігають такі активи, як ETH, і дозволяють користувачам надавати підтвердження зняття коштів. Перевіривши відповідність указаногоLogicHolder logicHoldingAccountHash, власник може переконатися, що договір про утримування активів приймає докази лише з авторизованого логічного контракту про утримання, а не будь-якого довільного контракту.
Секрет, наданий як приватний сигнал під час побудови доказу, гарантує, що лише власник облікового запису, який містить логіку витрат, може отримати доступ до коштів з рахунку зберігання активів.
3. Схема
Наступну схему було розроблено за допомогою circom, повний код можна знайти тут.
pragma circom 2.0.2;
include "./modules/merkleTree.circom";include "./modules/commitmentHasher.circom";
компонент main {public [root,logicHoldingAddressHash]} = Main(N);
Схема має загалом 7 сигналів, 2 з яких є загальнодоступними, а саме корінь дерева Merkle та хеш-адресу логічного облікового запису (який має бути хешований перед кодуванням у контракті про утримання активів, щоб запобігти спостерігачам агрегувати обліковий запис) клас) на основі тієї ж логіки, що й рахунок власника).
на закінчення
У світі, де користувачам доводиться керувати кількома обліковими записами, потреба в єдиній функції соціального відновлення стає все більш важливою. Zk-SNARK можна використовувати в гаманцях, які реалізують розділення логіки/активів, дозволяючи користувачам використовувати «логіку» облікового запису A для здійснення витрат з облікового запису B без створення зв’язку між ними. Як перший крок, докази SNARK можна використовувати для дій, які є менш ризикованими, ніж витрати на активи. Наприклад, хорошою відправною точкою може бути дозвіл користувачам ініціювати «запити на зняття коштів». Якщо власник контракту на зберігання логічних даних не заперечує, користувач може завершити запит через деякий час.
Таким чином, власник логічного холдингового контракту все ще може втрутитися, хоча й порушуючи конфіденційність, у випадку, якщо станеться щось несподіване.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Як zk-SNARKs реалізує розділення логіки транзакцій гаманця та активів
Автор: @Toni Wahrstätter Переклад: DeBox Institute
Передмова
Віталік рекомендує використовувати zk-SNARK, щоб відокремити рахунки торгової логіки від рахунків, що містять активи. Це покращує конфіденційність, взаємодію з користувачем і соціальне відновлення в один клік. Дослідник Ethereum Тоні Варштеттер надає детальний аналіз цього прототипу гаманця, охоплюючи робочий процес і переваги.
Керування декількома обліковими записами може бути складним через низку причин, зокрема соціальне відновлення, конфіденційність, рівень 2 і загальні проблеми з користувачем. Використання прихованої адреси ускладнює роботу, оскільки для кожної взаємодії потрібен новий обліковий запис. Віталік рекомендує використовувати zk-SNARK, щоб відокремити рахунки торгової логіки від рахунків, що містять активи. Це покращує конфіденційність, взаємодію з користувачем і соціальне відновлення в один клік.
У двох словах, ми намагаємося досягти:
**Єдине соціальне відновлення без шкоди для конфіденційності. **
1. Традиційний метод
Проста, але загрозлива конфіденційність реалізація виглядає так:
Недоліком є те, що це відкрито пов’язує логічні облікові записи та облікові записи активів, тим самим ставлячи під загрозу конфіденційність.
2. Використовуйте ZK-SNARK
Використовуючи zk-SNARK, користувачі можуть довести, що вони мають право витрачати, не розкриваючи зв’язку між логічним рахунком холдингу та рахунком холдингу активів.
Робочий процес такий:
1.1 Дерево Merkle містить значення slot0 і slot1 кожного існуючого контракту, відсортовані за датою або назвою.
1.2 Кожен користувач може створити дерево Merkle локально на основі останнього стану.
Користувач створює доказ zk, щоб довести, що він знає секрет у логічному обліковому записі. Детальний доказ пізніше.
Користувач надсилає zk-proof на рахунок зберігання активів.
Сертифікат підтвердження рахунку активів, що підтверджує таке:
4.1 Користувачі знають, де логіка.
4.2 Користувач знає секретне значення, яке хешується та зіставляється зі значенням, що зберігається в логічному обліковому записі.
4.3 Користувачі можуть реконструювати стан облікового запису, корінь дерева Merkle, який підтримується в канонічному ланцюжку (наприклад, попередньо скомпільований)
4.4 Використовуйте правильні випадкові числа (використовуються для перемикання ключів у логічних рахунках).
По суті, користувач може сказати: «У мене є підтверджений дозвіл від логічного облікового запису на виконання цієї дії, і я знаю місцезнаходження цього логічного облікового запису».
перевага
Крім того, шляхом додавання ще одного контракту (агрегатора) між логікою та договором утримання активів можна надати кілька підтверджень різних рахунків утримування активів в одній транзакції, що дозволяє розглядати обліковий запис майже як UTXO. Агрегатори зможуть отримати кілька сертифікатів zk і переслати їх на відповідні рахунки активів для перевірки. Звичайно, такий агрегатор міг би створювати зв’язки — включаючи конфіденційність — між окремими рахунками активів.
технічні деталі
Налаштування zk-SNARK включає приватні елементи:
1. Логічний балансовий рахунок
Прототип логічного холдингового рахунку може виглядати так:
твердість прагми >=0,7,0 <0,9,0;
контракт LogicHoldingAccount is Ownable { uint256 public slot0 = 0x1234; // хешований секрет uint256 public nonce = 0; // відслідковувати ключові зміни адреси публічного власника;
функція updateOwner(uint256 newValue) public onlyOwner { nonce += 1; slot0 = нове значення;
Цей контракт відстежує поточну логіку витрат власника (slot0) і дозволяє оновлення через функцію updateOwner.
2. Обліковий запис
твердість прагми >=0,7,0 <0,9,0;
контракт AssetHoldingAccount { uint256 public logicHoldingAccountHash = 1234...;
// Розмір скалярного поля, розмір базового поля, дані ключа перевірки тощо // ...
функція verifyProof( uint [2] calldata _pA, uint [2] [2] calldata _pB, uint [2] calldata _pC, uint [2] calldata _pubSignals) public view повертає (bool val) { // код складання Snarkjs для перевірки доказів... // ... }
// _pubSignals [0] - корінь contract-slot0||nonce Merkle дерева // _pubSignals [1] - функція адреси власника логіки hased ute( адреса, що підлягає оплаті, uint256 сума, uint [2] calldata _pA, uint [2] [2] calldata _pB, uint [2] calldata _pC, uint [2] calldata _pubSignals) public { contractRootPrecompile.getRoot(block.number) uint256 specifiedLogicHolder = _pubSignals [1] ; require(specifiedLogicHolder == logicHoldingAccountHash, "Не дозволено");
bool validProof = verifyProof(_pA, _pB, _pC, _pubSignals) == істина; if (validProof) { (bool success,) = to.call{value:amount}(""); вимагати (успіху); }}
receive() зовнішня оплата {
Рахунки для зберігання активів зберігають такі активи, як ETH, і дозволяють користувачам надавати підтвердження зняття коштів. Перевіривши відповідність указаногоLogicHolder logicHoldingAccountHash, власник може переконатися, що договір про утримування активів приймає докази лише з авторизованого логічного контракту про утримання, а не будь-якого довільного контракту.
Секрет, наданий як приватний сигнал під час побудови доказу, гарантує, що лише власник облікового запису, який містить логіку витрат, може отримати доступ до коштів з рахунку зберігання активів.
3. Схема
Наступну схему було розроблено за допомогою circom, повний код можна знайти тут.
pragma circom 2.0.2;
include "./modules/merkleTree.circom";include "./modules/commitmentHasher.circom";
шаблон Main(levels) { корінь входу сигналу; логічний вхід сигналуHoldingAddressHash; логічний вхід сигналуHoldingAddress; секрет входу сигналу; одноразовий вхід сигналу; Елементи вхідного шляху сигналу [levels] ; Індекси вхідного шляху сигналу [levels] ; компонент secretHasher = SecretHasher(); secretHasher.secret <== секрет; хешер компонента = CommitmentHasher(); hasher.logicHoldingAddress <== logicHoldingAddress; hasher.secret <== secretHasher.hashedSecret; hasher.nonce <== nonce; hasher.logicHoldingAddressHash === logicHoldingAddressHash; дерево компонентів = MerkleTreeChecker(рівні); tree.leaf <== hasher.commitment; дерево.корінь <== корінь; for ( i = 0; i < levels; i++) { tree.pathElements [i] <== pathElements [i] ; tree.pathIndices [i] <== pathIndices [i] ;
компонент main {public [root,logicHoldingAddressHash]} = Main(N);
Схема має загалом 7 сигналів, 2 з яких є загальнодоступними, а саме корінь дерева Merkle та хеш-адресу логічного облікового запису (який має бути хешований перед кодуванням у контракті про утримання активів, щоб запобігти спостерігачам агрегувати обліковий запис) клас) на основі тієї ж логіки, що й рахунок власника).
на закінчення
У світі, де користувачам доводиться керувати кількома обліковими записами, потреба в єдиній функції соціального відновлення стає все більш важливою. Zk-SNARK можна використовувати в гаманцях, які реалізують розділення логіки/активів, дозволяючи користувачам використовувати «логіку» облікового запису A для здійснення витрат з облікового запису B без створення зв’язку між ними. Як перший крок, докази SNARK можна використовувати для дій, які є менш ризикованими, ніж витрати на активи. Наприклад, хорошою відправною точкою може бути дозвіл користувачам ініціювати «запити на зняття коштів». Якщо власник контракту на зберігання логічних даних не заперечує, користувач може завершити запит через деякий час.
Таким чином, власник логічного холдингового контракту все ще може втрутитися, хоча й порушуючи конфіденційність, у випадку, якщо станеться щось несподіване.