Виталик рекомендует использовать zk-SNARK для отделения учетных записей торговой логики от счетов, на которых хранятся активы. Это улучшает конфиденциальность, удобство использования и возможность восстановления в один клик. Исследователь Ethereum Тони Варштеттер предоставляет подробный анализ прототипа этого кошелька, рассказывая о рабочем процессе и преимуществах.
Большое спасибо Мэтту за отличные дискуссии по этой теме и за разработку этого инструмента для анализа каждого контракта и помещения его в разреженное дерево Меркла, которое упрощает создание прототипов, устраняя необходимость в доказательствах zk на дереве Патриции. Также спасибо Виталику за его большой вклад.
Управление несколькими учетными записями может быть сложной задачей по ряду причин, включая социальное восстановление, конфиденциальность, L2 и общие проблемы с пользовательским интерфейсом. Использование скрытого адреса усложняет ситуацию, поскольку для каждого взаимодействия требуется новая учетная запись. Виталик рекомендует использовать zk-SNARK для отделения учетных записей торговой логики от счетов, на которых хранятся активы. Это улучшает конфиденциальность, удобство использования и возможность восстановления в один клик.
Для дальнейшего я рекомендую сначала просмотреть пост Виталика «Три трансформации», чтобы получить некоторую предысторию.
В двух словах, чего мы пытаемся достичь:
**Универсальное социальное восстановление без ущерба для конфиденциальности. **
1. Традиционный метод
Простая, но ставящая под угрозу конфиденциальность реализация выглядит следующим образом:
Пользователь предоставляет подпись и какое-либо намерение/команду для учетной записи хранения активов.
Счет хранения активов пересылает подпись на логический счет хранения.
Логический холдинговый счет извлекает открытый ключ из подписи и сравнивает его с сохраненным открытым ключом.
Если проверка пройдена, логическая учетная запись уведомит учетную запись хранения активов о продолжении операции.
Счет хранения активов выполняет приказы пользователя.
Недостаток заключается в том, что это публично связывает логические учетные записи и учетные записи хранения активов, тем самым ставя под угрозу конфиденциальность.
2. Используйте ZK-SNARK
Используя zk-SNARK, пользователи могут доказать, что им разрешено тратить деньги, не раскрывая связи между логическим счетом хранения и счетом хранения активов.
Рабочий процесс выглядит следующим образом:
Пользователь локально строит дерево Меркла и идентифицирует листья, содержащие его контракт.
1.1.Дерево Меркла в основном содержит значения slot0 и slot1 каждого существующего контракта, отсортированные по дате или названию.
1.2 Каждый пользователь может построить дерево Меркла локально на основе последнего состояния.
Пользователь создает доказательство zk, чтобы доказать, что он знает секрет логического временного счета. Подробное доказательство позже.
Пользователь отправляет zk-доказательство на счет хранения активов.
Сертификат проверки счета хранения активов, подтверждающий следующее:
4.1 Пользователи знают, где логика.
4.2 Пользователь знает секретное значение, которое хешируется и сопоставляется со значением, хранящимся на логическом счете хранения.
4.3 Пользователи могут реконструировать корень дерева Меркла состояния учетной записи, поддерживаемый в канонической цепочке (например, предварительно скомпилированный).
4.4. Используйте правильные случайные числа (используются для переключения ключей на логических счетах хранения).
По сути, пользователь может сказать: «У меня есть доказуемое разрешение логической учетной записи на выполнение этого действия, и я знаю местоположение этой логической учетной записи».
преимущество
Пользовательский опыт: один закрытый ключ или одна настройка с несколькими подписями могут управлять несколькими учетными записями, даже если они находятся на разных уровнях L2.
Восстановление: учетные записи можно более легко восстановить с помощью одного обновления контракта.
Конфиденциальность: нет общедоступных ссылок между учетными записями.
Совместимость: это помогает популяризировать кошельки Account Abstraction (AA) и другие функции.
Кроме того, добавив еще один (агрегаторный) контракт между логикой и контрактом на владение активами, в одной транзакции можно предоставить несколько доказательств существования различных учетных записей хранения активов, что позволяет рассматривать учетную запись почти как UTXO. Агрегаторы смогут получать несколько сертификатов ZK и пересылать их на соответствующие счета хранения активов для проверки. Конечно, такой агрегатор мог бы создавать связи (в том числе конфиденциальные) между отдельными счетами хранения активов.
Стоит отметить, что это не обязательно выбор «или-или» между использованием SNARK (и, следовательно, полагаться на его безопасность) и вообще не использовать SNARK (и, таким образом, упускать хорошие свойства конфиденциальности). Компромиссом может быть использование доказательства SNARK для открытия временного окна в контракте логического хранения с последующей небольшой задержкой, после которой владелец контракта логического хранения может изменить значение slot0, вместо того, чтобы требовать подтверждения SNARK для расходования и таким образом изменить логику потребления. Текущий владелец контракта может использовать задержку перед открытием временного окна, чтобы предотвратить обновление учетных данных.
Технические подробности
Настройка zk-SNARK включает в себя частные элементы:
*Ключ, используемый для проверки.
Логический адрес счета хранения — это адрес, на который указывает счет хранения активов.
Ветка Меркла для определения конкретных государственных ценностей.
Nonce, который позволяет выполнять ротацию ключей, делая недействительными старые ключи. Частные элементы, такие как логика открытого текста, содержащая адреса контрактов и секреты, не публикуются, но используются для частной связи логических учетных записей хранения и учетных записей хранения активов. Создавая доказательства для всего состояния, центральному органу власти не нужно строить дерево Меркла для предоставления доказательств.
1. Логический текущий счет
Прототип логического текущего счета может выглядеть следующим образом:
прагматическая надежность >=0,7,0 <0,9,0;
контракт LogicHoldingAccount является собственностью { uint256 public slot0 = 0x1234; // хешированный секрет uint256 public nonce = 0; // отслеживать ключевые изменения адреса публичного владельца;
функция updateOwner (uint256 newValue) public onlyOwner { nonce += 1; слот0 = новое значение;
slot0: общедоступная переменная, которая изначально содержит хэш-значение. Только владелец знает хешированный прообраз.
nonce: счетчик, отслеживающий количество обновлений информации о владельце. Это гарантирует, что старые ключи станут недействительными.
updateOwner(uint256 newValue): функция, которая обновляет значение и добавляет случайное число.
Этот контракт отслеживает текущую логику расходов владельца (slot0) и позволяет обновлять его с помощью функции updateOwner.
2. Текущий счет
прагматическая надежность >=0,7,0 <0,9,0;
контракт AssetHoldingAccount {uint256 public LogicHoldingAccountHash = 1234...;
// Размер скалярного поля, Размер базового поля, Данные ключа проверки и т. д. // ...
функцияverifyProof( uint [2] данные вызова _pA, uint [2] [2] данные вызова _pB, uint [2] данные вызова _pC, uint [2] calldata _pubSignals) public view return (bool val) { // Код сборки Snarkjs для проверки доказательств... // ... }
// _pubSignals [0] - корень дерева контракта-slot0||nonce Меркла // _pubSignals [1] - функция адреса держателя логики hased ute(адрес, которому выплачивается, сумма uint256, uint [2] данные вызова _pA, uint [2] [2] данные вызова _pB, uint [2] данные вызова _pC, uint [2] calldata _pubSignals) public {contractRootPrecompile.getRoot(block.number) uint256 selectedLogicHolder = _pubSignals [1] ; require(specifiedLogicHolder == logHoldingAccountHash, «Не разрешено»);
На счетах хранения активов хранятся такие активы, как ETH, и они позволяют пользователям предоставлять доказательства вывода средств. Проверив, что указанный LogicHolder соответствует logHoldingAccountHash, владелец может гарантировать, что контракт на владение активом принимает доказательства только из авторизованного логического контракта на хранение, а не из любого произвольного контракта.
Секрет, предоставленный в качестве частного сигнала при построении доказательства, гарантирует, что только владелец учетной записи, содержащей логику расходов, может получить доступ к средствам со счета хранения активов.
3. Схема
Следующая схема была разработана с использованием circom, полный код можно найти здесь.
компонент main {public [root,logicHoldingAddressHash]} = Main(N);
Схема имеет в общей сложности 7 сигналов, 2 из которых являются общедоступными, а именно корень дерева Меркла и хеш-адрес логического счета хранения (который должен быть хеширован перед кодированием в контракт на хранение активов, чтобы наблюдатели не могли агрегировать учетную запись). класс) на основе той же логики, что и для счета держателя).
в заключение
В мире, где пользователям приходится управлять несколькими учетными записями, необходимость универсальной функции социального восстановления становится все более важной. Zk-SNARK можно использовать в кошельках, которые реализуют разделение логики и активов, позволяя пользователям использовать «логику» учетной записи A для расходования средств со учетной записи B без создания связи между ними. В качестве первого шага доказательства SNARK можно использовать для действий, которые менее рискованны, чем затраты активов. Например, хорошей отправной точкой может быть разрешение пользователям инициировать «запросы на снятие средств». Если владелец контракта на хранение логики не выдвигает возражений, пользователь может завершить запрос через некоторое время.
Таким образом, владелец контракта на логическое хранение все равно может вмешаться, хотя и с нарушением конфиденциальности, в случае, если произойдет что-то неожиданное.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Комплексное социальное восстановление: как zk-SNARKs реализует разделение логики транзакций и активов кошелька?
Автор оригинала: @Toni Wahrstätter
Дата выхода: 12 сентября 2023 г.
Перевод: Исследовательский институт DeBox
Предисловие
Виталик рекомендует использовать zk-SNARK для отделения учетных записей торговой логики от счетов, на которых хранятся активы. Это улучшает конфиденциальность, удобство использования и возможность восстановления в один клик. Исследователь Ethereum Тони Варштеттер предоставляет подробный анализ прототипа этого кошелька, рассказывая о рабочем процессе и преимуществах.
Управление несколькими учетными записями может быть сложной задачей по ряду причин, включая социальное восстановление, конфиденциальность, L2 и общие проблемы с пользовательским интерфейсом. Использование скрытого адреса усложняет ситуацию, поскольку для каждого взаимодействия требуется новая учетная запись. Виталик рекомендует использовать zk-SNARK для отделения учетных записей торговой логики от счетов, на которых хранятся активы. Это улучшает конфиденциальность, удобство использования и возможность восстановления в один клик.
В двух словах, чего мы пытаемся достичь:
**Универсальное социальное восстановление без ущерба для конфиденциальности. **
1. Традиционный метод
Простая, но ставящая под угрозу конфиденциальность реализация выглядит следующим образом:
Недостаток заключается в том, что это публично связывает логические учетные записи и учетные записи хранения активов, тем самым ставя под угрозу конфиденциальность.
2. Используйте ZK-SNARK
Используя zk-SNARK, пользователи могут доказать, что им разрешено тратить деньги, не раскрывая связи между логическим счетом хранения и счетом хранения активов.
Рабочий процесс выглядит следующим образом:
1.1.Дерево Меркла в основном содержит значения slot0 и slot1 каждого существующего контракта, отсортированные по дате или названию.
1.2 Каждый пользователь может построить дерево Меркла локально на основе последнего состояния.
Пользователь создает доказательство zk, чтобы доказать, что он знает секрет логического временного счета. Подробное доказательство позже.
Пользователь отправляет zk-доказательство на счет хранения активов.
Сертификат проверки счета хранения активов, подтверждающий следующее:
4.1 Пользователи знают, где логика.
4.2 Пользователь знает секретное значение, которое хешируется и сопоставляется со значением, хранящимся на логическом счете хранения.
4.3 Пользователи могут реконструировать корень дерева Меркла состояния учетной записи, поддерживаемый в канонической цепочке (например, предварительно скомпилированный).
4.4. Используйте правильные случайные числа (используются для переключения ключей на логических счетах хранения).
По сути, пользователь может сказать: «У меня есть доказуемое разрешение логической учетной записи на выполнение этого действия, и я знаю местоположение этой логической учетной записи».
преимущество
Кроме того, добавив еще один (агрегаторный) контракт между логикой и контрактом на владение активами, в одной транзакции можно предоставить несколько доказательств существования различных учетных записей хранения активов, что позволяет рассматривать учетную запись почти как UTXO. Агрегаторы смогут получать несколько сертификатов ZK и пересылать их на соответствующие счета хранения активов для проверки. Конечно, такой агрегатор мог бы создавать связи (в том числе конфиденциальные) между отдельными счетами хранения активов.
Технические подробности
Настройка zk-SNARK включает в себя частные элементы:
*Ключ, используемый для проверки.
1. Логический текущий счет
Прототип логического текущего счета может выглядеть следующим образом:
прагматическая надежность >=0,7,0 <0,9,0;
контракт LogicHoldingAccount является собственностью { uint256 public slot0 = 0x1234; // хешированный секрет uint256 public nonce = 0; // отслеживать ключевые изменения адреса публичного владельца;
функция updateOwner (uint256 newValue) public onlyOwner { nonce += 1; слот0 = новое значение;
Этот контракт отслеживает текущую логику расходов владельца (slot0) и позволяет обновлять его с помощью функции updateOwner.
2. Текущий счет
прагматическая надежность >=0,7,0 <0,9,0;
контракт AssetHoldingAccount {uint256 public LogicHoldingAccountHash = 1234...;
// Размер скалярного поля, Размер базового поля, Данные ключа проверки и т. д. // ...
функцияverifyProof( uint [2] данные вызова _pA, uint [2] [2] данные вызова _pB, uint [2] данные вызова _pC, uint [2] calldata _pubSignals) public view return (bool val) { // Код сборки Snarkjs для проверки доказательств... // ... }
// _pubSignals [0] - корень дерева контракта-slot0||nonce Меркла // _pubSignals [1] - функция адреса держателя логики hased ute(адрес, которому выплачивается, сумма uint256, uint [2] данные вызова _pA, uint [2] [2] данные вызова _pB, uint [2] данные вызова _pC, uint [2] calldata _pubSignals) public {contractRootPrecompile.getRoot(block.number) uint256 selectedLogicHolder = _pubSignals [1] ; require(specifiedLogicHolder == logHoldingAccountHash, «Не разрешено»);
bool validProof =verifyProof(_pA, _pB, _pC, _pubSignals) == true; if (validProof) { (bool Success,) = to.call{value:amount}(""); требуют (успех); } }
get() внешняя кредиторская задолженность {
На счетах хранения активов хранятся такие активы, как ETH, и они позволяют пользователям предоставлять доказательства вывода средств. Проверив, что указанный LogicHolder соответствует logHoldingAccountHash, владелец может гарантировать, что контракт на владение активом принимает доказательства только из авторизованного логического контракта на хранение, а не из любого произвольного контракта.
Секрет, предоставленный в качестве частного сигнала при построении доказательства, гарантирует, что только владелец учетной записи, содержащей логику расходов, может получить доступ к средствам со счета хранения активов.
3. Схема
Следующая схема была разработана с использованием circom, полный код можно найти здесь.
прагма цирком 2.0.2;
включить "./modules/merkleTree.circom"; включить "./modules/commitmentHasher.circom";
шаблон Main(levels) { корень входного сигнала; логика входного сигналаHoldingAddressHash; входной сигнал logHoldingAddress; секрет ввода сигнала; входной сигнал nonce; Входной путь сигналаЭлементы [levels] ; Путь ввода сигналаИндексы [levels] ; компонент secretHasher = SecretHasher(); secretHasher.secret <== секрет; хэшер компонента = CommitmentHasher(); hasher.logicHoldingAddress <== logHoldingAddress; hasher.secret <== secretHasher.hashedSecret; hasher.nonce <== nonce; hasher.logicHoldingAddressHash === logHoldingAddressHash; дерево компонентов = MerkleTreeChecker(levels); Tree.leaf <== hasher.commitment; дерево.корень <== корень; for (i = 0; i <levels; i++) {tree.pathElements [i] <== элементы пути [i] ; Tree.pathIndices [i] <== Индексы пути [i] ;
компонент main {public [root,logicHoldingAddressHash]} = Main(N);
Схема имеет в общей сложности 7 сигналов, 2 из которых являются общедоступными, а именно корень дерева Меркла и хеш-адрес логического счета хранения (который должен быть хеширован перед кодированием в контракт на хранение активов, чтобы наблюдатели не могли агрегировать учетную запись). класс) на основе той же логики, что и для счета держателя).
в заключение
В мире, где пользователям приходится управлять несколькими учетными записями, необходимость универсальной функции социального восстановления становится все более важной. Zk-SNARK можно использовать в кошельках, которые реализуют разделение логики и активов, позволяя пользователям использовать «логику» учетной записи A для расходования средств со учетной записи B без создания связи между ними. В качестве первого шага доказательства SNARK можно использовать для действий, которые менее рискованны, чем затраты активов. Например, хорошей отправной точкой может быть разрешение пользователям инициировать «запросы на снятие средств». Если владелец контракта на хранение логики не выдвигает возражений, пользователь может завершить запрос через некоторое время.
Таким образом, владелец контракта на логическое хранение все равно может вмешаться, хотя и с нарушением конфиденциальности, в случае, если произойдет что-то неожиданное.