Кратко; не читать

Закрытый ключ — это ядро, которое позволяет нам подписывать транзакции в Ethereum, но управление им было кошмаром, даже в читаемой форме «seed-фраз». Тем не менее, наша цель никогда не заключалась в том, чтобы превратить блокчейн в сложную игру.

Аутентификация авторизованных пользователей крайне важна для безопасных транзакций. С развитием интернет-безопасности и UX мы перешли от аутентификации по паролю к биометрии, такой как распознавание лиц и отпечатков пальцев. WebAuthn является ключевым развитием в этом прогрессе. В данной статье тесно обсуждаются три термина:

WebAuthn: стандарт аутентификации веб-приложений, использующий учетные данные на основе открытого ключа, часто создаваемые внешними аутентификаторами. Он устраняет необходимость в паролях и обеспечивает безопасную аутентификацию пользователя.

Secure Enclave: аппаратная защищенная область в вычислительных устройствах, Secure Enclave предназначена для защиты конфиденциальных данных. Версии Secure Enclave можно найти на устройствах iOS, Android и Windows. Он может служить в качестве безопасного аутентификатора, реализуя WebAuthn, но закрытый ключ, привязанный к SE, часто создает проблемы между устройствами.

Passkey: Реализация WebAuthn на уровне операционной системы, настраиваемая различными поставщиками устройств и систем. Например, Passkey от Apple использует ключ, хранящийся в iCloud Keychain для синхронизации между устройствами. Однако этот подход обычно ограничен определенными платформами или системами.

Как описано выше, реализации webAuthn соответствуют нашей цели для ежедневных пользователей блокчейна, чтобы обеспечить высокий уровень защиты от фишинга и удобство использования. Вот идея объединить их в блокчейн:

Ключевой уровень: Пользователи аутентифицируются с использованием безупречных биометрических методов, таких как распознавание лица или отпечаток пальца. Под капотом это аппаратный процессор безопасности, такой как Secure Enclave или облачные сервисы, такие как iCloud и Google Cloud, обрабатывают управление ключами. Я рассмотрю вопросы межустройственной и межплатформенной совместимости позже.

Уровень учетной записи: Учетная запись смарт-контракта (SCA) предлагает возможность назначать произвольных подписантов (например, SE и Passkey) и механизмы пороговых значений. Кроме того, его модульная конструкция повышает гибкость и возможность модернизации. Например, SCA может динамически адаптировать свои требования к подписи в зависимости от таких факторов, как сумма транзакции, время или IP-адрес. С другой стороны, традиционная учетная запись, принадлежащая внешним владельцам (EOA), может быть дополнена услугами MPC, их комбинация обеспечивает лучшую совместимость и экономическую эффективность по сравнению с SCA, хотя ей не хватает расширенных функций, которые предоставляют SCA, особенно для ротации ключей.

Уровень подписи: Ethereum изначально поддерживает кривую k1, но проверка подписи WebAuthn влечет за собой более высокие затраты, поскольку он использует кривую r1 для генерации ключей. Поэтому некоторые решения уровня 2, такие как zkSync, планируют использовать собственные прекомпиляции кривых EIP-7212 r1. Кроме того, существуют сторонние сервисы, верификаторы Solidity, верификаторы с нулевым разглашением (ZK) и распределенные системы управления ключами, чтобы упростить подписание кривой r1 более экономичным способом.

Отказ от ответственности:

Технологический прогресс не гарантирует успеха на рынке; Не все устройства и платформы приняли Passkey; Использование SCA может быть дороже, чем EOA; Предлагаемое решение развивается вместе с технологическим прогрессом.

Крипто UX ужасен? Управление ключами ужасно!

В мире блокчейнов реальный контроль над активами блокчейнов находится не в руках пользователя или поставщика кошелька, а скорее лежит в частном ключе. Этот ключ является наиболее важным для всего процесса выполнения транзакции на Ethereum. Чтобы лучше понять это, давайте возьмем в качестве примера EOA:

Генерация ключа: Случайное число, выбранное из эллиптической кривой secp256k1, служит в качестве закрытого ключа. Затем этот ключ умножается на предопределенную точку на кривой, чтобы сгенерировать открытый ключ. Адрес Ethereum происходит из последних 20 байт хешированного открытого ключа. 'Семантическая фраза' обычно используется для резервного копирования, обеспечивая детерминированное происхождение закрытых и открытых ключей.

Подписание транзакций: Транзакция, содержащая детали, такие как номер (последовательный номер), сумма, цена газа и адрес получателя, подписывается с использованием закрытого ключа. Этот процесс, включающий ECDSA, алгоритм цифровой подписи, использующий эллиптическую кривую криптографии и принимающий secp256k1 в качестве кривой, генерирует подпись, состоящую из значений (r, s, v). Подпись и исходная транзакция затем транслируются в сети.

Подтверждение транзакций: Как только транзакция достигает узлов Ethereum, она проходит процесс валидации в памяти узла. Для проверки подписавшего, узлы используют подпись и хэшированную транзакцию для получения открытого ключа отправителя и подтверждения подлинности транзакции, сопоставляя производный адрес с адресом отправителя.

Как описано выше, приватный ключ является неотъемлемой сущностью on-chain. Изначально учетные записи Ethereum, известные как External Owned Accounts (EOA), полностью полагались на один единственный приватный ключ, что представляло существенные риски, так как потеря ключа означала потерю доступа к учетной записи.

Многие могут подумать, что Абстракция Счета (AA) - это решение для всего, что связано с плохим пользовательским опытом, о чем я скажу не совсем. AA заключается в изменении правил допустимости для программирования, а программирование Смарт-контрактного счета (SCAs) делает это возможным. AA мощна, позволяет отправлять несколько транзакций параллельно (абстрактный номер), спонсирование газа и оплату газа в ERC20 (абстрактный газ), и более актуально для темы данной статьи - нарушение фиксированной проверки подписи (абстрактная ECDSA-подпись). Вместо EOA, SCAs могут назначать произвольных подписантов и механизмы подписания, такие как мультиподпись (мультисиги) или ограниченные ключи (ключи сессии). Однако, несмотря на гибкость и возможность обновления AA, фундаментальная зависимость от ключа(ей) для подписи транзакции остается неизменной.

Даже при преобразовании в 12-словную фразу-семя, управление личным ключом остается сложной задачей, создающей риски потери или фишинговых атак. Пользователям необходимо маневрировать между сложными уровнями децентрализованных решений или теплым объятием централизованных сервисов, ни один из них не является идеальным.

Почему опыт крипто плохой? Большая часть этого связана с тем, что управление ключами плохое. Всегда требуются компромиссы между опытом, безопасностью и децентрализацией. В этой статье исследуются потенциальные оптимальные решения для управления ключом.

Уровни управления ключами

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

Чтобы прояснить заранее, я избегаю использования популярных методов 'самостоятельного, полусамостоятельного и полного ухода' для каталогизации. На мой взгляд, истинное самостоятельное уход означает подписание транзакции независимо, без полаганиясь на другую сторону, это действительно, даже если решение не является опекунским в традиционном смысле (как хранение в TEE децентрализованных узлов). Категоризация решений как просто 'хороших' или 'плохих' на основе типа ухода является чересчур упрощенной и не учитывает их различную пригодность. Для более тонкой оценки методов управления ключами я предлагаю анализировать их через три различных уровня.

Ответственность

Разделять ли ответственность за управление ключом между разными сторонами.

Учитывая, что часто люди сталкиваются с проблемами в управлении ключом, распределение ответственности за его сохранение возникает как естественная стратегия смягчения рисков. Эта категория включает методы, такие как использование нескольких ключей для совместного подписания, как это видно в системах множественной подписи (Multi-sig), и деление частного ключа на части с помощью Схемы Секретного Распределения(SSS) или Многозначного Вычисления (MPC).

Multi-sig: Требование нескольких полных частных ключей для генерации подписей транзакций. Этот метод требует on-chain коммуникации о различных подписантах, что приводит к увеличению размера комиссий за транзакции и влияет на конфиденциальность, поскольку количество подписантов видно on-chain.

SSS: секретный ключ генерируется в одном месте, затем дилер распределяет части этого ключа различным сторонам. Все стороны должны восстановить полный секретный ключ для подписи транзакции. Однако это временное восстановление может привести к уязвимостям.

MPC-TSS(Threshold Signature Scheme): как реализация MPC, криптографический подход, позволяющий нескольким сторонам выполнять вычисления, сохраняя их собственные входные данные в тайне совместно. Каждая сторона независимо создает секретный ключ, и транзакции подписываются без необходимости физической встречи этих сторон. Он вводит более низкие сборы, потому что это вне цепи, и отсутствует риск единой точки отказа, как в случае SSS.

Хранилище

Храните ключ или доли, подверженные влиянию факторов безопасности, доступности, стоимости и децентрализации.

Централизованные облачные сервисы, такие как AWS, iCloud и другие серверы. Они удобны для частых транзакций, но более уязвимы для цензуры.

Децентрализованное хранение, такое как IPFS и Filecoin.

Локальный компьютер/мобильное устройство: Ключи сохраняются локально в безопасном хранилище браузера.

Бумажные кошельки: Физическая распечатка частных ключей или QR-кодов.

Доверенная среда выполнения (TEE): TEE предоставляет безопасную область в основном процессоре для выполнения или хранения чувствительных данных, изолированных от основной операционной системы.

Безопасный резервуар: Безопасный резервуар на современных устройствах изолирован от основного процессора для обеспечения дополнительного уровня безопасности и предназначен для сохранения конфиденциальных данных пользователей в безопасности даже в случае компрометации ядра процессора приложений.

Аппаратные кошельки: Физические устройства, такие как Ledger и Trezor, специально разработанные для безопасного хранения закрытых ключей.

Модуль аппаратной безопасности (HSM): HSM - это специализированные аппаратные устройства, разработанные для безопасного управления ключами и криптографических операций. Они обычно используются в корпоративных средах и предлагают функции безопасности высокого уровня.

Доступ

Как проверить личность пользователя для доступа к сохраненному ключу

Аутентификация включает в себя доступ к сохраненному ключу. Речь идет о проверке того, что лицо, пытающееся получить доступ, действительно имеет на то разрешение. Оглядываясь назад на историю, мы можем классифицировать историю таким образом:

Что-то, что вы знаете: пароли, ПИН-коды, ответы на вопросы безопасности или конкретные шаблоны.

Что-то, что у вас есть: включает смарт-карты, аппаратные токены (одноразовые пароли на основе времени) или цифровые факторы, такие как проверка учетной записи в социальной сети и SMS-коды, отправленные на телефон.

Кто-то Вы Есть: Включите уникальные физические характеристики пользователя, такие как отпечатки пальцев, распознавание лица (например, Apple’s Face ID или Windows Hello), распознавание голоса или сканирование радужки/сетчатки.

На основе этих данных, 2FA и MFA - это методы, которые объединяют два или более фактора, такие как SMS в сочетании с уведомлением о нажатии, для добавления дополнительных уровней безопасности к учетным записям пользователей.

Анализ существующих игроков

MetaMask позволяет пользователям использовать пароль для доступа к ключу, хранящемуся в локальном хранилище браузера пользователя.

Trust Wallet позволяет пользователям использовать пароль или faceID для доступа к ключу, хранящемуся в локальном хранилище браузера пользователя, пользователь также может выбрать облачный сервис для резервного копирования закрытого ключа.

Privy позволяет пользователям использовать несколько методов социального входа, таких как электронная почта, используя SSS для разделения на три доли:

Совместное использование устройства: браузер-iframe, мобильный - безопасное хранилище.

Auth share: Хранится в privy, ссылка на privy id).

Доля восстановления: Пароль пользователя или зашифрованный с помощью Privy, хранящийся в аппаратном модуле безопасности (HSM).

Particle позволяет пользователям использовать социальный вход, используя MPC-TSS, который имеет две доли:

Распределение устройства: браузер-iFrame

Ключ сервера: сервер Particle

Новое решение

Ключевой уровень: WebAuthn, Secure Enclave и ключ доступа

Существующие решения выше были ключевыми в знакомстве пользователей с web3. Однако они часто сопряжены с проблемами: пароли могут быть забыты или стать объектом фишинговых атак, и даже 2FA, хоть и более безопасный, может быть громоздким из-за своих многоэтапных шагов. Кроме того, не все комфортно поручают управление ключами третьей стороне, пользователи все еще зависят от доступности и работоспособности своей системы, в то время как некоторые службы гарантируют, что они не смогут получить доступ к ключу.

Это заставляет нас размышлять, существует ли более эффективное решение — такое, которое предлагает наиболее близкое решение к доверительному, высокоуровневой безопасности и безупречному пользовательскому опыту. Этот поиск приводит нас к оптимальным методам веб2. Несколько терминов тесно связаны с темой, как я описал в начале статьи, WebAuthn является стандартом аутентификации сам по себе, в то время как Secure Enclave и Passkey являются реализациями или компонентами, связанными с этим стандартом.

WebAuthn

Стандарт WebAuthn стандартизирует интерфейс аутентификации пользователей в веб-приложениях. Он позволяет пользователям входить в интернет-аккаунты, используя внешние аутентификаторы вместо пароля. Аутентификаторами могут быть роуминговые аутентификаторы (Yubikey, Titan key) или платформенные аутентификаторы (встроенные ключи на устройствах Apple) и так далее.

Альянс FIDO (Fast IDentity Online) изначально разработал технологии, лежащие в основе WebAuthn. Он был официально объявлен веб-стандартом W3C в марте 2019 года, и вместе с его стандартизацией крупные браузеры, такие как Google Chrome, Mozilla Firefox, Microsoft Edge и Apple Safari, приняли WebAuthn, что значительно увеличило его охват и удобство использования. Теперь его поддерживают многие передовые устройства.

Преимущества webAuthn:

Повышенная безопасность: устраняет зависимость от паролей, снижая уязвимость к фишингу, атакам перебора паролей и повторным атакам.

Улучшенный опыт пользователя: предлагает более простой и быстрый процесс входа, часто с помощью простого касания или биометрической верификации.

Защита конфиденциальности: При аутентификации не передаются общие секреты, и отдельные веб-сайты не получают никакой лично идентифицируемой информации.

Масштабируемость и стандартизация: как веб-стандарт, WebAuthn гарантирует согласованность и взаимодействие между различными браузерами и платформами.

Привязанный к устройству WebAuthn, например, Secure Enclave

В современных случаях мы можем использовать аппаратный процессор в качестве аутентификатора, например, Secure Enclave для устройств Apple, Trustzone для Android и Strongbox для Google Pixel.

Генерация ключа: С использованием криптографии с открытым ключом создается пара ключей в соответствии с стандартами WebAuthn, обычно с использованием кривой P-256 r1. Открытый ключ отправляется на службу, в то время как закрытый ключ НИКОГДА не покидает Безопасную оболочку. Пользователь никогда не имеет дело с ключом в виде обычного текста, что затрудняет компрометацию закрытого ключа.

Хранение ключей: закрытый ключ безопасно хранится в безопасном анклаве устройства, укрепленном подсистеме, отделенной от основного процессора. Он защищает чувствительные данные, гарантируя, что даже если основная система скомпрометирована, сырое ключевое материал остается недоступным. Порог для компрометации Безопасного анклава чрезвычайно высок, поэтому самые чувствительные типы данных, такие как данные Apple Pay и FaceID, хранятся там. Вот подробное объяснение того, как работает Безопасный анклав.

Аутентификация: Пользователи используют распознавание лица или отпечаток пальца для доступа, защищенный резервуар использует закрытый ключ для подписи вызова от службы, а служба проверяет с использованием открытого ключа.

Преимущества веба на основе устройства webAuthn:

Аппаратный уровень безопасности: Использование защищенного резервного копирования, изолированного аппаратного ключевого менеджера для обеспечения дополнительного уровня безопасности.

Устойчивость к фишингу: не вводите никакую информацию на потенциально скомпрометированных устройствах или веб-сайтах.

Удобный опыт: Они предоставляют более удобный опыт для пользователей. Пользователям больше не нужно запоминать сложные пароли для различных сайтов.

Недостатки веб-аутентификации на основе устройства:

Ограничения устройства: Приватный ключ нельзя экспортировать или восстановить в случае утери или повреждения устройства, операция между устройствами невозможна.

Облачный WebAuthn, Passkey

Справляясь с вызовом кросс-устройственной функциональности, техгиганты представили облачную реализацию webAuthn, Passkey широко известен благодаря Apple.

Давайте возьмем в качестве примера Passkey от Apple:

Генерация ключа: Устройство macOS, iOS или iPadOS пользователя, как аутентификатор, генерирует пару открытого и закрытого ключей, когда пользователь создает учетную запись. Затем отправляет открытый ключ на сервер, а закрытый ключ хранится в облачном ключевом хранилище устройства. Данные облачного ключевого хранилища зашифрованы с использованием аппаратно-привязанной пары ключей и хранятся в модуле аппаратной безопасности (HSM). Ключ недоступен для Apple.

Синхронизация между устройствами: Этот процесс будет аналогичен доступу к iCloud. Аутентификация в учетной записи iCloud, получение SMS-кода и ввод пароля одного из устройств.

Облачная веб-аутентификация pros:

Кросс-устройство: Парольные ключи были разработаны для удобства и доступности со всех устройств, используемых на постоянной основе. Но в настоящее время они ограничены устройствами Apple, для Android это более сложная задача из-за разнообразных версий и аппаратных вариаций.

Устойчивость к фишингу: То же, что и выше.

Удобный опыт: То же, что и выше.

Облачные недостатки ключа доступа:

Полагайтесь на облачный сервис: По сравнению с устройственным веб-аутентификацией, облачный ключ перемещает уровень безопасности с аппаратной части Secure Enclave на iCloud keychain, некоторые могут утверждать, что это кастодиально для вашего облачного сервиса. Некоторые ключевые аспекты, которые следует учитывать, включают: компрометация учетной записи AppleID пользователя с iCloud; Хотя iCloud Keychain использует конечно-конечное шифрование для защиты данных, операционные ошибки или уязвимости представляют риск.

Ограничение для платформы: Например, использование ключа доступа на основе iCloud на устройстве Android является крайне сложным. Более того, в отличие от традиционных методов, Apple и Google не отправляют утверждения, специфичные для устройства. Это означает, что в настоящее время невозможно проверить тип устройства, создавшего ключ, что вызывает вопросы о надежности ключа и связанных с ним метаданных.

Уровень учетной записи: SCA и EOA

Пока что мы видим, что обеспечение безопасности на аппаратном уровне при обеспечении совместимости между устройствами и платформами представляет собой сложную задачу. Также важен вариант социального восстановления, такой как добавление нескольких стражей для улучшения безопасности. В этом контексте блокчейн может показать нам путь.

Заметная разница при попытке реализовать web2 webAuthn в web3: Web2 требует только подтверждения владения, в то время как web3 также требует одновременного авторизирования транзакции. С Passkey разработчики не имеют контроля над подписывающим сообщением, которое обычно является общим, например, 'войти.' Это может привести к потенциальной манипуляции фронт-эндом, когда пользователи слепо подписывают сообщения - кажущаяся незначительная, но важная проблема.

Умные контрактные счета (SCA), по своей сути сами умные контракты, функционируют как цепочечные сущности, способные назначать произвольных подписантов. Эта гибкость позволяет программировать различные устройства и платформы - такие как установка на Android-телефон, Macbook и iPhone - в качестве подписантов. Более того, Модульный умный контрактный счет позволяет обновляться, заменять новых подписантов, изменять порог подписания с 2 из 3 на еще более сложные конфигурации.

Представьте кошелек, который адаптирует свои требования к безопасности в зависимости от контекста: он позволяет аутентификацию с одним подписчиком, когда пользователь находится на знакомом локальном IP-адресе, но требует нескольких подписчиков для транзакций с неизвестных IP-адресов или свыше определенной стоимости. Благодаря модульности и программированию, наше воображение - единственное ограничение для таких инноваций. Многие поставщики услуг SCA активно развивают эту область, включая Safe, Zerodev, Biconomy, Etherspots, Rhinestone и т. д. Также стоит упомянуть об инфраструктуре, такой как Stackup, Plimico, Alchemy, которые делают это возможным.

Пожалуйста, проверьте мое предыдущее исследование, которое предоставляет более полный контекст вокруг SCA.

EOA'ы могут достигать социального восстановления и совместимости между устройствами/платформами через услуги MPC. Несмотря на то, что у EOA есть фиксированные подписанты, провайдеры MPC могут разделять ключи на части для повышения безопасности и гибкости. Этот метод лишен программных и обновляемых функций SCA, таких как восстановление по времени и легкая деактивация ключа. Тем не менее, он все еще предлагает превосходные возможности межцепных связей, будучи не привязанным к цепи, и в настоящее время более экономичен, чем SCA. Отметим, что среди поставщиков MPC следует выделить Privy, Particle Network, web3Auth, кошелек OKX, кошелек Binance и т. д.

Уровень подписи: поддержка R1

Давайте вернемся назад, чтобы понять контекст: На Ethereum приватные ключи являются случайными числами, выбранными из кривой k1, и процесс подписи также использует эту кривую.

Однако ключевые пары, сгенерированные в соответствии со стандартами WebAuthn, используют кривую r1. Поэтому проверка подписи r1 на Ethereum примерно в три раза дороже, чем подпись k1. Вот некоторые способы решения этой проблемы:

Кредит Догану, для более глубокого понимания, пожалуйста, ознакомьтесь с его исследованием.

Протокольное решение:

Решение: EIP7212, Предварительная компиляция для поддержки кривой secp256r1, предложенная командой Clave.

Оценка: Этот проект создает предварительно скомпилированный контракт, который выполняет проверку подписи в эллиптической кривой "secp256r1" по заданным параметрам хэша сообщения, компонентам r и s подписи, и координатам x, y открытого ключа. Таким образом, любая цепочка EVM - в основном роллапы Ethereum - сможет легко интегрировать этот предварительно скомпилированный контракт. До сих пор протокольная предкомпиляция может быть наиболее эффективным средством газа.

Реализация: zkSync

Сервис сторонних поставщиков

Решение: Готовое

Оценка: Turkey TEE гарантирует, что закрытый ключ доступен только пользователю через их PassKey и никогда не доступен для Turnkey, однако это все равно требует активности службы.

Реализация: Goldfinch

Решения верификации Solidity:

Решение: Проверяющий код FCL на языке Solidity, Проверяющий код FCL на языке Solidity с предварительным вычислением, P256Verifier от Daimo

Реализация: Clave, Очевидный кошелек

Проверяющий с нулевым разглашением (ZK):

Решение: Risc0 Bonsai, хало2-ecc Axiom

Оценка: Этот подход использует доказательства нулевого знания для проверки вычислений за пределами Виртуальной Машины Ethereum (EVM), снижая затраты на вычисления на цепи.

Реализация: Кошелек Bonfire(Risc0), Лаборатории Know Nothing(Axiom)

Каждое из этих решений предлагает различный метод для обеспечения более дешевой и осуществимой верификации подписи r1 в экосистеме Ethereum, и вот оценка, представленная Dogan.

Пример реализации

*Обратите внимание, что по состоянию на декабрь 2023 года большинство этих решений находятся на ранних стадиях и могут быть изменены или улучшены в любое время. Эти примеры предназначены только для учебных целей; Всегда обращайтесь к их официальным сайтам для получения точной информации.

Кошелек Clave: (Безопасный веб-интерфейс Secure Enclave) + (SCA)

Основные:

Демо:https://getclave.io/

Аккаунт: SCA

Цепь: ZkSync

Процесс транзакции:

Создание ключа: пользователь предоставляет биометрическую аутентификацию, такую как отпечаток пальца или распознавание лица, внутри Secure Enclave генерируется пара ключей, которые никогда не раскрываются и не выходят наружу.

Подпись ключа: Приложение берет необходимое сообщение о транзакции и перенаправляет запрос на подписание в Безопасный аркан, пользователь предоставляет био-аутентификацию для утверждения подписи, а Безопасный аркан подписывает сообщение ключом и передает его узлам блокчейна.

Дополнительные функции: Умный контракт позволяет использовать множество мощных функций. Во-первых, спонсирование газа. Благодаря плательщику, другие стороны, такие как dApp или рекламодатели, могут оплачивать комиссию за газ пользователя, что делает процесс транзакции более плавным, и также позволяют пользователям оплачивать газ в ERC20 вместо Ether или собственного токена. А используя сеансовый ключ, пользователь может проводить транзакции без подписи в течение определенного периода времени.

Механизм восстановления:

Процесс восстановления осуществляется смарт-контрактом Clave на zkSync, пользователь может отменить восстановление в течение 48-часовой блокировки времени, чтобы предотвратить несанкционированные и злонамеренные действия.

Облачное резервное копирование: EOA будет создан при выборе пользователем облачного резервного копирования, приватный ключ EOA хранится либо в iCloud, либо в Google Drive, пользователь может использовать этот приватный ключ, хранящийся в облаке, для доступа к своей учетной записи с другого устройства, и пользователи могут удалить или перезаписать этот раздел резервного копирования в любое время.

Социальное восстановление: Пользователь может назначить адрес ключа своего семьи или друга в качестве резервной копии, если M из N опекунов подтвердят восстановление, восстановление будет выполнено через 48 часов после блокировки, если не отменить.

Кошелек Soul: (Пасскей) + (4337 SCA)

Основы:

Демо: https://alpha.soulwallet.io/wallet

Аккаунт: ERC4337 SCA

Цепь: Ethereum, Optimism, Arbitrum и вскоре все EVM уровня2

Процесс транзакции:

Создание ключа: Пользователи предоставляют биометрическую аутентификацию, такую как отпечаток пальца или распознавание лица, и операционная система генерирует Пасскей и резервное копирование его с использованием облачного сервиса. Вы можете добавить более одного пасскейя для использования на разных устройствах и платформах.

Добавить опекунов (необязательно): Пользователь может назначить разные адреса EVM EOA в качестве опекунов и установить порог для восстановления учетной записи.

Генерация учетной записи: С использованием контрфактического развертывания пользователь не должен платить никакую комиссию до первой транзакции

Механизм восстановления:

Пароль: Используйте любой определенный пароль для входа в кошелек с помощью любого устройства.

Восстановление стражей: Назначенные стражи могут вращать кошелек в соответствии с порогом, а позже может быть предусмотрен временной замок, чтобы предотвратить злонамеренное поведение.

OKX кошелек:(MPC-TSS + Пароль доступа) + (4337 SCA)

Основы:

Демонстрация:https://www.okx.com/help/what-is-an-aa-smart-contract-wallet

Цепь: 30+ цепей

Ключ: MPC-TSS, 2/3

Аккаунт: 4337 SCA

Процесс транзакции:

Создание ключа: Путем создания кошелька OKX преобразует один частный ключ в три отдельных части. Часть 1 хранится на сервере OKX, часть 2 хранится в локальном хранилище устройства пользователя, а часть 3 создается устройством, зашифровывается и может быть скопирована на предпочитаемые облачные службы устройства, такие как Google Cloud, iCloud и Huawei Cloud.

Подпись ключа: OKX, используя технологию MPC-TSS, пользователь может получить полную подпись, используя два из трех долей закрытого ключа при подписании транзакции, доли ключа никогда не встречаются друг с другом во время этого процесса.

Механизм восстановления:

2/3 механизм: Когда пользователь вышел из системы, устройство недоступно или один из ключей на устройстве скомпрометирован, вы можете использовать новое устройство для входа в кошелек OKX (получить общую долю сервера) и получить облачную службу, объединить эти 2 доли, чтобы восстановить кошелек, кошелек OKX сгенерирует новые секретные доли.

Web3Auth: (MPC-TSS + Passkey)+ (EOA/SCA)

Основные:

Демо: https://w3a.link/passkeysDemo

Цепь: Все EVM и Solana

Ключ: MPC-TSS, обычно 2/3

Аккаунт: Любой аккаунт, такой как EOA, 4337 SCA или общий SCA

Процесс транзакции:

Создание ключа: При создании кошелька генерируются три ключевых компонента. Share1 - это ключевой компонент для входа через социальные сети, пользователь может ввести свой адрес электронной почты, и децентрализованная сеть узлов сохраняет ключ для каждого пользователя; Share2 - это ключевой компонент устройства, который сохраняется в локальном хранилище устройства пользователя; Share3 генерируется на локальном компьютере и резервируется с использованием предпочитаемых облачных сервисов пользователя.

Подпись ключа: Архитектура Web3Auth MPC-TSS гарантирует, что ключ пользователя всегда доступен, даже при использовании пороговой подписи, ключи никогда не восстанавливаются или не хранятся в одном месте.

Механизм восстановления:

Восстановление порога При выходе пользователя, недоступности устройства или компрометации одного из ключей на устройстве вы можете использовать метод входа через социальные сети, чтобы войти в учетную запись webAuthn и получить облачное совместное использование пароля, объедините эти 2 общие доли, чтобы восстановить кошелек.

Протокол Lit(MPC-TSS + децентрализованные узлы + Пароль)+ (EOA/SCA)

Основная информация:

Демо: https://lit-pkp-auth-demo.vercel.app/

Цепь: Большинство EVM, Cosmos, Solana.

Аккаунт: MPC-TSS, 20 из 30 сети, может быть принят как SCA, так и EOA.

Процесс транзакции:

Создание ключа: Когда пользователь хочет создать кошелек, сначала выбирается метод аутентификации (пароль, поддерживается вход через социальные сети OAuth), затем отправляется запрос к ретранслятору для создания пар ключей и сохранения логики аутентификации в смарт-контракте. Каждая пара ключей генерируется коллективно узлами Lit через процесс, называемый Распределенной Генерацией Ключей (DKG). Действуя как децентрализованная сеть, 30 узлов Lit работают внутри TEE, каждый узел хранит часть ключа, но приватный ключ никогда не существует в полном объеме.

Подписание ключа: Получив запрос, узлы Lit независимо проверяют или отклоняют запрос на основе назначенного метода аутентификации и, используя технологию MPC-TSS, 1. Ключевые доли собираются выше порога (20 из 30) для генерации подписи и объединяются клиентом для выполнения запроса.

Механизм восстановления:

Механизм 2/3: Используйте методы аутентификации, хранящиеся в смарт-контракте, чтобы получить доступ к учетной записи, узлы Lit проверяют запросы, и они будут выполнены, если более 2/3 узлов подтвердят.

Заключение:

Воодушевленные энтузиазмом в отношении решений Layer2, Layer3 и Data Availability, мы стремимся повысить производительность блокчейна. Кроме того, стремление к реальной безопасности, сочетание конфиденциальности с доказательством нулевого разглашения и прозрачности. Все усилия направлены на одну цель: быть готовыми к реальным пользователям, которые часто взаимодействуют с блокчейном и внедряют криптовалюту в свою жизнь.

Легко попасть в ловушку оптимальной технологической мечты, но мы должны спросить: на какой опыт мы рассчитываем? Мы представляем себе мир, где крипто - это скорее интуиция, чем пугающие технические термины, где пользователь без колебаний и хлопот погружается в кроличью нору.

Представьте себе пользователя Руи: она обнаруживает фантастическое dApp, легко регистрируется, используя распознавание лица или отпечаток пальца, с возможностью настройки резервного копирования или опекунов. Пока она взаимодействует с dApp, она плавно выполняет транзакции, возможно, с небольшими комиссиями ERC20 или даже без них вообще. Позже она настраивает параметры своего кошелька - возможно, активируя временную блокировку для автоматических транзакций, добавляя еще одно устройство в качестве резервного подписанта или изменяя свой список опекунов.

Наши строители делают это возможным. Интегрируя WebAuthn и Passkey, мы улучшаем управление частным ключом, делая его одновременно безопасным и удобным для пользователя. На вершине ключа SCA как сущность открывает реальность персонализированной безопасности и функциональности. А что касается газовых сборов? Они становятся менее обременительными, благодаря поставщикам Paymaster, которые могут создать 'хранилище' для свопов или даже позволить рекламодателям покрывать сборы для пользователей. В основе этой эволюции, особенно для основной сети Ethereum и ее эквивалентных Layer2s, стоит ERC4337. Он представляет альтернативный мемпул, который отделяет транзакции SCA от EOAs, без крупных изменений протокола. С другой стороны, некоторые сети Layer 2 даже естественно принимают SCAs, бесшовно включая их в свои системы.

Для того чтобы все было легко, требуется огромные усилия. Существует много препятствий, таких как снижение развертывания, проверки и исполнения сборов за SCA; Стандартизация интерфейса для увеличения совместимости учетных записей; Синхронизация состояния учетной записи межцепочно; и многое другое. Благодарность всем строителям, мы все ближе к решению головоломки с каждым днем. И криптовалютные предприятия, такие как наше - SevenX, готовы помочь крупным фирмам воплотить свою мечту.

Оговорка：

1. Эта статья перепечатана из [SevenX Ventures]. Все авторские права принадлежат оригинальному автору [@Rui]. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, принадлежат исключительно автору и не являются какими-либо инвестиционными рекомендациями.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.