Новая статья дяди Виталика
Особая благодарность Дэну Финлею, Карлу Флоершу, Дэвиду Хоффману, а также командам Scroll и SoulWallet за отзывы, рецензии и предложения.
По мере того как Ethereum превращается из молодой экспериментальной технологии в зрелый технологический стек, способный действительно привнести открытый, глобальный и не требующий разрешения опыт для обычных пользователей, есть три основных технических перехода, которые стек должен пройти примерно одновременно:
1. Переход к масштабированию L2 - все переходят на роллапы.
2. Переход к безопасности кошельков - все переходят на кошельки смарт-контрактов
3. Переход к конфиденциальности - обеспечение возможности перевода средств с сохранением конфиденциальности, а также обеспечение сохранения конфиденциальности всех других разрабатываемых гаджетов (социальное восстановление, идентификация, репутация).
Без первого, Ethereum потерпит неудачу, потому что каждая транзакция стоит $3,75 ($82,48, если у нас будет еще один бычий забег), и каждый продукт, нацеленный на массовый рынок, неизбежно забывает о цепочке и принимает централизованные обходные пути для всего.
Без второго, Ethereum потерпит неудачу, потому что пользователям неудобно хранить свои средства (и нефинансовые активы), и все переходят на централизованные биржи.
Без третьего пункта Ethereum терпит крах, потому что публичное размещение всех транзакций (и POAPs, и т.д.) в открытом доступе, чтобы их мог видеть буквально каждый, является слишком высокой жертвой конфиденциальности для многих пользователей, и все переходят на централизованные решения, которые хотя бы в некоторой степени скрывают ваши данные.
Эти три перехода крайне важны по вышеуказанным причинам. Но они также сложны из-за интенсивной координации, необходимой для их правильного решения. Необходимо улучшить не только характеристики протокола; в некоторых случаях способ взаимодействия с Ethereum должен измениться довольно фундаментально, требуя глубоких изменений в приложениях и кошельках.
Эти три перехода радикально изменят отношения между пользователями и адресами
В мире с масштабированием L2 пользователи будут существовать на многих L2. Вы являетесь членом ExampleDAO, который живет на Optimism? Тогда у вас есть аккаунт на Optimism! Вы держите CDP в системе стабильных монеток на ZkSync? Тогда у вас есть аккаунт на ZkSync! Вы однажды попробовали какое-то приложение, которое случайно оказалось на Kakarot? Тогда у вас есть аккаунт на Kakarot! Времена, когда у пользователя был только один адрес, уйдут в прошлое.
У меня есть ETH в четырех местах, согласно моему представлению Brave Wallet. И да, Arbitrum и Arbitrum Nova отличаются. Не волнуйтесь, со временем все станет еще более запутанным!
У меня есть ETH в четырех местах, согласно моему представлению Brave Wallet. И да, Arbitrum и Arbitrum Nova отличаются. Не волнуйтесь, со временем все станет еще более запутанным!
Кошельки смарт-контрактов добавляют еще больше сложностей, поскольку гораздо сложнее иметь один и тот же адрес в L1 и различных L2. Сегодня большинство пользователей используют внешние учетные записи, чей адрес буквально является хэшем открытого ключа, который используется для проверки подписей - таким образом, между L1 и L2 ничего не меняется. Однако с кошельками для смарт-контрактов сохранить один адрес становится сложнее. Хотя была проделана большая работа, чтобы сделать адреса хэшами кода, которые могут быть эквивалентны в разных сетях, в частности, CREATE2 и фабрика синглтонов ERC-2470, трудно добиться идеальной работы. Некоторые L2 (например, "тип 4 ZK-EVMs") не совсем эквивалентны EVM, часто вместо них используется Solidity или промежуточная сборка, что препятствует эквивалентности хэшей. И даже когда вы можете обеспечить эквивалентность хэшей, возможность смены владельца кошелька при смене ключа создает другие неинтуитивные последствия.
Конфиденциальность требует, чтобы у каждого пользователя было еще больше адресов, и даже может изменить типы адресов, с которыми мы имеем дело. Если предложения по скрытым адресам получат широкое распространение, то вместо того, чтобы каждый пользователь имел всего несколько адресов или один адрес на L2, пользователи могут иметь один адрес на транзакцию. Другие схемы обеспечения конфиденциальности, даже такие существующие, как Tornado Cash, меняют способ хранения активов по-другому: средства многих пользователей хранятся в одном смарт-контракте (и, следовательно, по одному адресу). Чтобы отправить средства конкретному пользователю, пользователям придется полагаться на собственную внутреннюю систему адресации схемы конфиденциальности.
Как мы видели, каждый из трех переходов по-разному ослабляет ментальную модель "один пользователь ~= один адрес", и некоторые из этих эффектов отражаются на сложности выполнения переходов. Двумя особыми точками сложности являются:
1. Если вы хотите заплатить кому-то, как вы получите информацию о том, как заплатить?
2. Если у пользователей много активов, хранящихся в разных местах по разным цепочкам, как они будут осуществлять смену ключей и социальное восстановление?
Три перехода и внутрицепочечные платежи (и идентификация)
У меня есть монеты на scroll, и я хочу заплатить за кофе (если "я" - это буквально, имея в виду меня, автора этой статьи, то "кофе" - это, конечно, метонимия для "зеленого чая"). Вы продаете мне кофе, но настроены на получение монет только на Taiko. Что делать?
1. Кошельки получателей (которые могут быть торговцами, но могут быть и обычными людьми) очень стараются поддерживать каждый L2 и имеют некоторую автоматизированную функциональность для асинхронной консолидации средств.
2. Получатель предоставляет свой L2 вместе со своим адресом, а кошелек отправителя автоматически направляет средства в конечный L2 через некоторую систему кросс-L2 мостов.
Конечно, эти решения можно комбинировать: получатель предоставляет список L2, которые он готов принять, а кошелек отправителя рассчитывает платеж, который может включать либо прямую отправку, если повезет, либо кросс-L2 мостовой путь.
Но это лишь один пример ключевой проблемы, которую создают эти три перехода: такие простые действия, как оплата кому-либо, начинают требовать гораздо больше информации, чем просто 20-байтовый адрес.
Переход к кошелькам смарт-контрактов, к счастью, не является большой нагрузкой на систему адресации, но все же есть некоторые технические проблемы в других частях стека приложений, которые необходимо проработать. Кошельки необходимо будет обновить, чтобы убедиться, что они не отправляют вместе с транзакцией только 21000 газа, и еще важнее будет убедиться, что принимающая платежи сторона кошелька отслеживает не только переводы ETH от EOA, но и ETH, отправленные кодом смарт-контракта. Приложениям, которые полагаются на предположение о неизменности владения адресом (например, НФТ, запрещающие смарт-контракты для принудительного взыскания роялти), придется искать другие способы достижения своих целей. Кошельки смарт-контрактов также упростят некоторые вещи - в частности, если кто-то получает токен ERC20, не относящийся к категории ERC20, он сможет использовать платежные средства ERC-4337 для оплаты газа этим токеном.
С другой стороны, конфиденциальность снова создает серьезные проблемы, с которыми мы еще не справились. Оригинальная Tornado Cash не создавала этих проблем, поскольку не поддерживала внутренние переводы: пользователи могли только вносить средства в систему и выводить из нее. Однако как только появится возможность осуществлять внутренние переводы, пользователям придется использовать схему внутренней адресации системы конфиденциальности. На практике "платежная информация" пользователя должна содержать (i) некий "пубкей траты", обязательство хранить секрет, который получатель может использовать для траты, и (ii) некий способ отправки отправителем зашифрованной информации, которую может расшифровать только получатель, чтобы помочь ему обнаружить платеж.
Протоколы скрытых адресов опираются на концепцию мета-адресов, которые работают следующим образом: одна часть мета-адреса представляет собой закрытую версию ключа расходов отправителя, а другая часть - ключ шифрования отправителя (хотя в минимальной реализации эти два ключа могут быть одинаковыми).
Ключевой урок здесь заключается в том, что в экосистеме, дружественной к конфиденциальности, у пользователя будут как пубки трат, так и пубки шифрования, а "платежная информация" пользователя должна включать оба ключа. Кроме платежей, есть и другие веские причины для расширения в этом направлении. Например, если мы хотим использовать зашифрованную электронную почту на базе Ethereum, пользователям придется публично предоставлять некий ключ шифрования. В "мире EOA" мы могли бы повторно использовать для этого ключи учетных записей, но в безопасном мире смарт-контрактов-кошельков нам, вероятно, следует иметь более явную функциональность для этого. Это также поможет сделать идентификацию на базе Ethereum более совместимой с децентрализованными экосистемами конфиденциальности, не относящимися к Ethereum, в частности, с ключами PGP.
Три перехода и ключевое восстановление
Стандартный способ реализации смены ключей и социального восстановления в мире с большим количеством адресов на одного пользователя заключается в том, что пользователи просто запускают процедуру восстановления на каждом адресе отдельно. Это можно сделать в один клик: кошелек может включать программное обеспечение для одновременного выполнения процедуры восстановления на всех адресах пользователя. Однако даже при таком упрощении пользовательского интерфейса наивное многоадресное восстановление имеет три проблемы:
1. Непрактичность газовых затрат: эта проблема не требует пояснений.
2. Контрфактические адреса: адреса, для которых смарт-контракт еще не был опубликован (на практике это означает счет, с которого вы еще не отправили средства). Вы как пользователь имеете потенциально неограниченное количество контрфактических адресов: один или несколько на каждом L2, включая L2, которые еще не существуют, и еще целый бесконечный набор контрфактических адресов, возникающих из схем скрытых адресов.
3. Конфиденциальность: если пользователь намеренно имеет много адресов, чтобы не связывать их друг с другом, он, конечно, не хочет публично связывать их все, восстанавливая их в одно и то же время!
Решить эти проблемы непросто. К счастью, существует несколько элегантное решение, которое работает достаточно хорошо: архитектура, разделяющая логику проверки и владение активами.
Каждый пользователь имеет контракт keystore, который существует в одном месте (это может быть либо mainnet, либо конкретный L2). Затем у пользователей есть адреса на разных L2, где логика проверки каждого из этих адресов является указателем на контракт keystore. Расходование средств с этих адресов потребует доказательств, входящих в контракт keystore, показывающих текущий (или, что более реалистично, совсем недавний) открытый ключ расходования средств.
Доказательство может быть реализовано несколькими способами:
1. Прямой доступ к L1 только для чтения внутри L2. Можно модифицировать L2, чтобы дать им возможность напрямую читать состояние L1. Если контракт с хранилищем ключей находится на L1, это означает, что контракты внутри L2 могут получить доступ к хранилищу ключей "бесплатно".
2. Ветви Меркла. Ветви Меркла могут доказать состояние L1 для L2, или состояние L2 для L1, или вы можете объединить эти два способа, чтобы доказать части состояния одного L2 для другого L2. Основным недостатком доказательств 3. Меркла является высокая стоимость газа из-за длины доказательства: потенциально 5 кБ для доказательства, хотя в будущем это уменьшится до < 1 кБ благодаря деревьям Веркле.
ZK-SNARKs. Вы можете снизить затраты на данные, используя ZK-SNARK ветви Меркла вместо самой ветви. Можно построить технику агрегации вне цепи (например, на основе EIP-4337), чтобы один единственный ZK-SNARK проверял все межцепочечные доказательства состояния в блоке.
Обязательства KZG. Либо L2, либо схемы, построенные на их основе, могут ввести последовательную систему адресации, позволяя доказательствам состояния внутри этой системы быть длиной всего 48 байт. Как и в случае с ZK-SNARKs, мультидоказательная схема может объединить все эти доказательства в одно доказательство на блок.
Если мы хотим избежать одного доказательства для каждой транзакции, мы можем реализовать более легкую схему, которая требует только кросс-L2 доказательства для восстановления. Расходование средств со счета будет зависеть от ключа расходования, соответствующий pubkey которого хранится внутри этого счета, а для восстановления потребуется транзакция, копирующая текущий spend_pubkey в хранилище ключей. Средства на контрфактических адресах находятся в безопасности, даже если старые ключи не в безопасности: "активация" контрфактического адреса для превращения его в рабочий контракт потребует проведения кросс-L2 доказательства для копирования текущего ключа spend_pubkey. Эта тема на форумах Safe описывает, как может работать подобная архитектура.
Чтобы добавить конфиденциальности в такую схему, тогда мы просто шифруем указатель, а все наши доказательства делаем внутри ZK-SNARK:
При дополнительной работе (например, используя эту работу в качестве отправной точки), мы также могли бы убрать большую часть сложности ZK-SNARKs и сделать более простую схему на основе KZG.
Эти схемы могут стать сложными. С другой стороны, существует много потенциальных синергий между ними. Например, концепция "контрактов keystore" также может быть решением проблемы "адресов", упомянутой в предыдущем разделе: если мы хотим, чтобы у пользователей были постоянные адреса, которые не меняются каждый раз, когда пользователь обновляет ключ, мы можем поместить скрытые мета-адреса, ключи шифрования и другую информацию в контракт keystore, и использовать адрес контракта keystore в качестве "адреса" пользователя.
Многие объекты вторичной инфраструктуры нуждаются в обновлении
Использование ENS обходится дорого. Сегодня, в июне 2023 года, ситуация не так уж плоха: плата за транзакцию значительна, но все же сопоставима с платой за домен ENS. Регистрация zuzalu.eth обошлась мне примерно в $27, из которых $11 - плата за транзакцию. Но если у нас будет еще один "бычий" рынок, комиссии резко вырастут. Даже без роста цен на ETH, возвращение стоимости газа к 200 гвеям приведет к тому, что плата за регистрацию домена достигнет $104. И поэтому, если мы хотим, чтобы люди действительно использовали ENS, особенно в таких случаях, как децентрализованные социальные сети, где пользователи требуют почти бесплатной регистрации (и плата за домен ENS не является проблемой, поскольку эти платформы предлагают своим пользователям субдомены), нам нужно, чтобы ENS работала над L2.
К счастью, команда ENS сделала шаг навстречу, и ENS на L2 действительно состоится! Стандарт ERC-3668 (он же "стандарт CCIP") вместе с ENSIP-10 обеспечивают возможность автоматической проверки поддоменов ENS на любом L2. Стандарт CCIP требует создания смарт-контракта, который описывает метод проверки доказательств данных на L2, и домен (например, Optinames использует ecc.eth) может быть передан под контроль такого контракта. Как только контракт CCIP контролирует ecc.eth на L1, доступ к некоторому поддомену.ecc.eth будет автоматически включать поиск и проверку доказательства (например, ветви Меркла) состояния на L2, которое фактически хранит этот конкретный поддомен.
Фактически получение доказательств предполагает обращение к списку URL, хранящихся в контракте, что, конечно, похоже на централизацию, хотя я бы сказал, что это не так: это модель доверия 1of-N (недействительные доказательства отлавливаются логикой проверки в функции обратного вызова контракта CCIP, и пока хотя бы один из URL возвращает действительное доказательство, вы в порядке). Список URL-адресов может содержать десятки.
Усилия ENS CCIP - это история успеха, и ее следует рассматривать как знак того, что радикальные реформы такого рода, которые нам нужны, действительно возможны. Но необходимо провести еще много реформ на уровне приложений. Несколько примеров:
1. Многие dapps зависят от пользователей, предоставляющих подписи вне цепочки. С аккаунтами, принадлежащими внешним пользователям (EOA), это легко. ERC-1271 предоставляет стандартизированный способ сделать это для кошельков смарт-контрактов. Однако многие dapps все еще не поддерживают ERC-1271; им придется это сделать.
2. Dapps, которые используют "является ли это EOA?" для дискриминации пользователей и контрактов (например, для предотвращения передачи или принудительного взыскания роялти), сломаются. В целом, я не советую пытаться найти здесь чисто техническое решение; выяснение того, является ли конкретная передача криптографического контроля передачей бенефициарного владения, - сложная проблема и, вероятно, не решаемая без использования каких-то механизмов, управляемых сообществом вне цепочки. Скорее всего, приложениям придется меньше полагаться на предотвращение передачи и больше на такие методы, как налоги Харбергера.
3. Необходимо будет усовершенствовать взаимодействие кошельков с тратами и ключами шифрования. В настоящее время кошельки часто используют детерминированные подписи для генерации ключей для конкретных приложений: подписание стандартного nonce (например, хэша имени приложения) закрытым ключом EOA создает детерминированное значение, которое не может быть сгенерировано без закрытого ключа, и поэтому оно безопасно в чисто техническом смысле. Однако эти методы "непрозрачны" для кошелька, что не позволяет кошельку реализовать проверки безопасности на уровне пользовательского интерфейса. В более развитой экосистеме подписание, шифрование и связанные с ними функции должны будут обрабатываться кошельками более явно.
4. Легкие клиенты (например, Helios) должны будут проверять L2, а не только L1. Сегодня легкие клиенты сосредоточены на проверке достоверности заголовков L1 (с помощью протокола синхронизации легкого клиента), проверке ветвей Меркла состояния L1 и транзакций, уходящих корнями в заголовок L1. Завтра они также должны будут проверять доказательство состояния L2, уходящее корнями в корень состояния, хранящийся в L1 (более продвинутая версия этого будет фактически рассматривать предварительные подтверждения L2).
Кошельки должны будут защищать как активы, так и данные
Сегодня кошельки занимаются защитой активов. Все живет на цепи, и единственное, что кошелек должен защищать, - это закрытый ключ, который в данный момент охраняет эти активы. Если вы меняете ключ, то на следующий день можете спокойно опубликовать свой предыдущий закрытый ключ в Интернете. Однако в мире ZK это уже не так: кошелек не только защищает учетные данные для аутентификации, но и хранит ваши данные.
Первые признаки такого мира мы увидели в Zupass, системе идентификации на основе ZK-SNARK, которая использовалась в Zuzalu. У пользователей был закрытый ключ, который они использовали для аутентификации в системе, который можно было использовать для базовых доказательств типа "докажите, что я житель Зузалу, не раскрывая, какой именно". Но на систему Zupass стали накладываться и другие приложения, в первую очередь марки (версия POAPs от Zupass).
Ключевая особенность штампов по сравнению с POAP заключается в том, что штампы являются приватными: вы храните данные локально, и вы только ZK-доказываете штамп (или некоторые вычисления над штампами) кому-то, если хотите, чтобы у него была эта информация о вас. Но это создает дополнительный риск: если вы потеряете эту информацию, вы потеряете свои марки.
Конечно, проблема хранения данных может быть сведена к проблеме хранения одного ключа шифрования: какая-то третья сторона (или даже цепочка) может хранить зашифрованную копию данных. Это имеет то удобное преимущество, что ваши действия не меняют ключ шифрования и поэтому не требуют никаких взаимодействий с системой, хранящей ваш ключ шифрования. Но даже в этом случае, если вы потеряете ключ шифрования, вы потеряете все. И с другой стороны, если кто-то увидит ваш ключ шифрования, он увидит все, что было зашифровано на этом ключе.
Решение Zupass де-факто заключалось в том, чтобы поощрять людей хранить ключ на нескольких устройствах (например, ноутбуке и телефоне), поскольку вероятность того, что они потеряют доступ ко всем устройствам одновременно, ничтожно мала. Мы можем пойти дальше и использовать совместное использование секрета для хранения ключа, разделенного между несколькими хранителями.
Такое социальное восстановление через MPC не является достаточным решением для кошельков, поскольку это означает, что не только нынешние, но и предыдущие опекуны могут вступить в сговор, чтобы украсть ваши активы, что является неприемлемо высоким риском. Но утечка конфиденциальных данных - это, как правило, меньший риск, чем полная потеря активов, и человек, у которого есть сценарий использования с высокими требованиями к конфиденциальности, всегда может принять более высокий риск потери, не создавая резервную копию ключа, связанного с этими требующими конфиденциальности действиями.
Чтобы не перегружать пользователя запутанной системой многочисленных путей восстановления, кошельки, поддерживающие социальное восстановление, скорее всего, должны будут управлять как восстановлением активов, так и восстановлением ключей шифрования.
Назад к личности
Одна из общих нитей этих изменений заключается в том, что концепция "адреса", криптографического идентификатора, который вы используете для представления "себя" в цепи, должна будет радикально измениться. "Инструкции о том, как со мной взаимодействовать" больше не будут просто адресом ETH; они должны быть в какой-то форме комбинацией нескольких адресов на нескольких L2, скрытых мета-адресов, ключей шифрования и других данных.
Один из способов сделать это - сделать ENS вашей идентификацией: ваша запись ENS может просто содержать всю эту информацию, и если вы посылаете кому-то bob.eth (или bob.ecc.eth, или...), он может посмотреть и увидеть все о том, как платить и взаимодействовать с вами, включая более сложные междоменные и сохраняющие конфиденциальность способы.
Но у этого ENS-ориентированного подхода есть два слабых места:
1. Оно связывает слишком много вещей с вашим именем. Ваше имя - это не вы, ваше имя - это один из многих атрибутов вас. Должна быть возможность изменить имя без переноса всего профиля личности и обновления целой кучи записей во многих приложениях.
2. У вас не может быть надежных контрфактических имен. Одной из ключевых UX-функций любого блокчейна является возможность отправки монет людям, которые еще не взаимодействовали с цепочкой. Без такой функциональности возникает загвоздка: взаимодействие с цепочкой требует оплаты транзакций, что требует... уже наличия монет. Адреса ETH, включая адреса смарт-контрактов с CREATE2, имеют эту функцию. Имена ENS - нет, потому что если два Боба вне цепочки решат, что они bob.ecc.eth, нет возможности выбрать, кто из них получит имя.
Одно из возможных решений - поместить больше вещей в контракт keystore, упомянутый в архитектуре ранее в этом посте. Контракт keystore может содержать всю различную информацию о вас и о том, как с вами взаимодействовать (а в CCIP часть этой информации может быть вне цепи), и пользователи будут использовать свой контракт keystore в качестве основного идентификатора. Но фактические активы, которые они получают, будут храниться в самых разных местах. Контракты Keystore не привязаны к имени, и они контрфактически дружественны: вы можете создать адрес, который может быть инициализирован только контрактом Keystore, имеющим определенные фиксированные начальные параметры.
Другая категория решений связана с полным отказом от концепции адресов, обращенных к пользователю, в духе платежного протокола Биткойна. Одна из идей заключается в том, чтобы больше полагаться на прямые каналы связи между отправителем и получателем; например, отправитель может послать ссылку на требование (в виде явного URL или QR-кода), которую получатель может использовать для принятия платежа по своему усмотрению.
Независимо от того, кто действует первым - отправитель или получатель, большее доверие к кошелькам, напрямую генерирующим актуальную платежную информацию в режиме реального времени, может снизить трения. Тем не менее, постоянные идентификаторы удобны (особенно при использовании ENS), а предположение о прямой связи между отправителем и получателем на практике очень сложно, поэтому в конечном итоге мы можем увидеть комбинацию различных методов.
Во всех этих проектах первостепенное значение имеет сохранение децентрализации и понятности для пользователей. Мы должны быть уверены, что пользователи имеют легкий доступ к актуальной информации о том, каковы их текущие активы и какие сообщения были опубликованы, предназначенные для них. Эти представления должны зависеть от открытых инструментов, а не от проприетарных решений. Придется приложить немало усилий, чтобы избежать превращения усложнения платежной инфраструктуры в непрозрачную "башню абстракции", в которой разработчикам трудно разобраться в происходящем и адаптировать ее к новым условиям. Несмотря на трудности, достижение масштабируемости, безопасности кошелька и конфиденциальности для обычных пользователей имеет решающее значение для будущего Ethereum. Речь идет не только о технической осуществимости, но и о фактической доступности для обычных пользователей. Нам нужно подняться, чтобы решить эту задачу.