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