У кратці

Приватний ключ - це ядро, яке дозволяє нам підписувати транзакції на Ethereum, але управління ним було кошмаром, навіть у читабельній формі "seed phrases". Проте наша мета ніколи не полягала в тому, щоб перетворити блокчейн на складну гру.

Автентифікація авторизованих користувачів має вирішальне значення для безпечних транзакцій. З розвитком інтернет-безпеки та UX ми перейшли від автентифікації за допомогою пароля до біометрії, як-от розпізнавання облич і відбитків пальців. WebAuthn є ключовою розробкою в цій прогресії. У цій статті детально розглядаються три терміни:

WebAuthn: Стандарт веб-автентифікації використовує облікові дані на основі відкритого ключа, часто створені зовнішніми автентифікаторами. Це усуває потребу в паролях і забезпечує безпечну автентифікацію користувачів.

Безпечний резервуар: апаратно забезпечена безпечна область у пристроях обчислення, яка призначена для захисту чутливих даних. Версії безпечного резервуара знаходяться в пристроях з операційними системами iOS, Android та Windows. Він може слугувати як безпечний автентифікатор, реалізуючи WebAuthn, але приватний ключ, пов'язаний з SE, часто створює проблеми між пристроями.

Ключ доступу: реалізація WebAuthn на рівні операційної системи, налаштована різними постачальниками пристроїв і систем. Наприклад, ключ допуску Apple використовує ключ, що зберігається у В'язці iCloud, для синхронізації між пристроями. Однак цей підхід, як правило, прив'язаний до конкретних платформ або систем.

Як описано вище, реалізація webAuthn відповідає нашій меті для щоденних користувачів блокчейну, щоб досягти високого рівня захисту від фішингу та дружнього досвіду. Ось ідея об'єднати їх у блокчейн:

Key Layer: Користувачі автентифікуються за допомогою безшовних біометричних методів, таких як розпізнавання обличчя або відбиток пальця. Під капотом це апаратний засіб безпеки, такий як 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 більш економічно ефективним способом.

Відмова від відповідальності:

Технологічний прогрес не гарантує успіху на ринку; Не на всіх пристроях і платформах використовується ключ доступу; Використання SCA може бути дорожчим, ніж EOA; Запропоноване рішення розвивається разом з технічним прогресом.

Крипто UX – це відстій? Управління ключами – відстій!

У світі блокчейну справжній контроль над активами блокчейну не знаходиться у користувача або постачальника гаманця, а знаходиться у приватного ключа. Цей ключ є найважливішим для всього процесу виконання транзакції на Ethereum. Щоб краще зрозуміти це, давайте візьмемо EOA як приклад:

Генерація ключів: Випадкове число, вибране з еліптичної кривої secp256k1, служить приватним ключем. Цей ключ потім множиться на попередньо визначену точку на кривій, щоб згенерувати публічний ключ. Адреса Ethereum походить з останніх 20 байтів хешованого публічного ключа. 'Seed phrase' зазвичай вводиться для резервного копіювання у зручному для людини форматі, що дозволяє детерміноване похідне приватних та публічних ключів.

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

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

Як було вказано вище, приватний ключ є важливою сутністю on-chain. Спочатку Ethereum рахунки, відомі як Зовнішні Власні Рахунки (EOA), повністю покладалися лише на один приватний ключ, що створювало значні ризики, оскільки втрата ключа означала втрату доступу до рахунку.

Багато хто може подумати, що Абстракція Рахунку (AA) є рішенням у всьому, що стосується поганого користувацького досвіду, але я б сказав, що це не зовсім так. AA полягає в зміні правил валідності для програмованості, а програмованість Рахунку Смарт-контракту (SCA) робить це можливим. AA є потужним, дозволяє відправляти кілька транзакцій паралельно (абстрактний nonce), спонсорство газу та оплату газу у ERC20 (абстрактний газ), і більш відповідний для теми цієї статті, розбити фіксовану перевірку підпису (абстрактний підпис ECDSA). Замість EOA, SCA можуть призначати довільних підписантів та механізми підпису, такі як багато-підписи (multisigs) або обмежені ключі (сесійні ключі). Однак, незважаючи на гнучкість та просунутість оновлення 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 для розділення трьох спільних ресурсів:

Спільний доступ до пристрою: Browser-iFrame, мобільний - безпечний анклав.

Auth share: Збережено за допомогою приватного, посилання на приватний ідентифікатор).

Спільний доступ для відновлення: пароль користувача або зашифрований Privy, що зберігається в апаратному модулі безпеки (HSM).

Particle дозволяє користувачам увійти за допомогою соціального входу, використовуючи MPC-TSS, який має дві частки:

Спільний доступ до пристрою: browser-iFrame

Частка ключового сервера: сервер частини

Нове рішення

Ключовий шар: WebAuthn, Безпечна Сховище та Пароль

Існуючі рішення, наведені вище, відіграли ключову роль у знайомстві користувачів з 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, наприклад, Безпечний аркуш

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

Генерація ключа: З використанням криптографії з відкритим ключем створюється пара ключів відповідно до стандартів WebAuthn, як правило, з використанням кривої P-256 r1. Відкритий ключ надсилається на службу, тоді як приватний ключ НІКОЛИ не залишає Secure Enclave. Користувач ніколи не має справи з ключем у відкритому тексті, що ускладнює ймовірність компрометації приватного ключа.

Зберігання ключів: Приватний ключ зберігається в безпечному місці внутрішньої області пристрою, відокремленій підсистемі від основного процесора. Він захищає важливі дані, забезпечуючи, що навіть якщо основна система буде скомпрометована, сировинний ключ залишиться недоступним. Перешкода для компрометації безпечного резервуара дуже висока, тому найбільш чутливі типи даних, такі як Apple Pay та дані FaceID, зберігаються там. Ось докладний пояснення того, як працює внутрішня область.

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

Переваги веб-аутентифікації на основі пристрою:

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

Стійкість до рибалки: не вводьте будь-яку інформацію на потенційно скомпрометованих пристроях або веб-сайтах.

Зручний досвід: вони надають більш дружелюбний для користувача досвід. Користувачам вже не потрібно запам'ятовувати складні паролі для різних сайтів.

Недоліки вебAuthn на основі пристрою:

Обмеження пристрою: Приватний ключ не може бути експортований або відновлений, якщо пристрій втрачено або пошкоджено, перехідна робота між пристроями неможлива.

Хмарне використання WebAuthn, Passkey

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

Давайте візьмемо Passkey від Apple як приклад:

Генерація ключа: Користувальницький пристрій macOS, iOS або iPadOS як аутентифікатор генерує пару публічних та приватних ключів під час створення облікового запису. Потім він надсилає публічний ключ на сервер, а приватний ключ зберігається в ключовому ланцюжку iCloud пристрою. Дані ключового ланцюжка iCloud зашифровані за допомогою пари ключів, пов'язаних з обладнанням, і зберігаються в модулі безпеки обладнання (HSM). Ключ недоступний для Apple.

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

Переваги хмарного веб-аутентифікації pros:

Cross-device: Парольні ключі були розроблені для зручності та доступності з усіх пристроїв, які використовуються щоденно. Проте наразі вони обмежені лише до пристроїв Apple, для Android це складніше через його різноманітні версії та апаратні варіації.

Стійкість до рибальства: Те саме, що й вище.

Зручний досвід: Те саме, що і вище.

Хмарний Passkey недоліки:

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

Обмеження до платформи: Наприклад, використання ключа доступу на основі iCloud на пристрої Android є надзвичайно складним. Крім того, на відміну від традиційних методів, Apple та Google не відправляють специфічні для пристрою твердження. Це означає, що наразі неможливо перевірити тип пристрою, що згенерував ключ, що викликає питання про надійність ключа та його пов'язані метадані.

Шар облікового запису: SCA та EOA

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

Значна різниця полягає в тому, коли ми намагаємося реалізувати web2 webAuthn для web3: Web2 вимагає лише підтвердження власності, в той час як web3 також вимагає одночасного авторизування транзакції. З Passkey розробники не мають контролю над повідомленням підпису, яке, як правило, є загальним, наприклад, «увійдіть». Це може призвести до потенційного маніпулювання фронтендом, коли користувачі підписують повідомлення сліпо - це, здавалося б, невелике, але важливе питання.

Рахунки розумних контрактів (RCA), по своїй суті самі розумні контракти, функціонують як ланцюжкові сутності, здатні призначати довільних підписантів. Ця гнучкість дозволяє програмувати різні пристрої та платформи - такі як налаштування 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 suppor

Давайте зробимо крок назад, щоб зрозуміти контекст: На Ethereum приватні ключі є випадковими числами, вибраними з кривої k1, а процес підпису також використовує цю криву.

Однак, ключові пари, згенеровані відповідно до стандартів WebAuthn, використовують криву r1. Тому перевірка підпису r1 на Ethereum приблизно втричі дорожча, ніж підпис k1. Ось деякі підходи до вирішення цієї проблеми:

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

Протокольне рішення:

Рішення: EIP7212, Передвстановлене для підтримки кривої secp256r1, запропоноване командою Clave.

Оцінка: Ця пропозиція створює попередньо скомпільований контракт, який виконує перевірку підписів на еліптичній кривій “secp256r1” за заданими параметрами хешу повідомлення, компонентами r та s підпису, та координатами x, y відкритого ключа. Таким чином, будь-який ланцюжок EVM - головним чином rollups Ethereum - зможе легко інтегрувати цей попередньо скомпільований контракт. До цього часу, протокольний попередній компілювання може бути найбільш ефективним за газовою ефективністю рішенням.

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

Сервіс сторонніх постачальників

Рішення: Готове

Оцінка: Turkey TEE забезпечує, що приватний ключ доступний лише користувачеві через їх PassKey, і ніколи не доступний для самого Turnkey, проте це все ще потребує наявності сервісу.

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

Рішення верифікатора Solidity:

Рішення: Перевірник Solidity від FCL, Перевірник Solidity від FCL з попереднім обчисленням, P256Verifier від Daimo

Реалізація: Clave, Obvious Wallet

Перевірник з нульовим знанням (ZK):

Рішення: Risc0 Bonsai, гало2-ecc Axiom

Оцінка: Цей підхід використовує докази з нульовим відомостями, щоб перевірити обчислення поза Віртуальною Машиною Ethereum (EVM), зменшуючи витрати на обчислення на ланцюжку.

Реалізація: Бонфайр Вошет (Ріск0), Ноу Нотгінг Лабс (Аксіом)

Кожне з цих рішень пропонує різний метод для надання можливості дешево та можливо r1 перевірка підпису в екосистемі Ethereum, ось оцінка від Догана.

Випадок впровадження

*Зверніть увагу, що станом на грудень 2023 року більшість цих рішень знаходяться на ранніх стадіях і можуть змінюватися або покращуватися у будь-який час. Ці приклади призначені лише для навчальних цілей; завжди звертайтеся до їх офіційних веб-сайтів для отримання точної інформації.

Кошелек Clave: (Безпечний енклейв webAuthn) + (SCA)

Основи:

Демонстрація: https://getclave.io/

Обліковий запис: SCA

Ланцюг: ZkSync

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

Створення ключа: Користувач забезпечує біометричну аутентифікацію, таку як відбиток пальця або розпізнавання обличчя, ключова пара генерується всередині Безпечного складу, який ніколи не розголошується або не залишається за межами.

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

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

Механізм відновлення:

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

Резервне копіювання у хмарі: КОА буде створено, коли користувач обере резервне копіювання у хмарі, приватний ключ КОА зберігається або в iCloud, або в Google Drive, користувач може використовувати цей приватний ключ, збережений у хмарі, для доступу до свого облікового запису з різних пристроїв, і користувачі можуть в будь-який час видалити або перезаписати цей розділ резервного копіювання.

Соціальне відновлення: Користувач може призначити адресу клавіатури своєї родини або друга як резервне, якщо M з N опікунів підтверджують відновлення, відновлення буде виконано після блокування на 48 годин, якщо не скасувати.

Гаманець душі: (Ключ доступу) + (4337 SCA)

Основи:

Демонстрація: https://alpha.soulwallet.io/wallet

Рахунок: ERC4337 SCA

Ланцюжок: Ethereum, Optimism, Arbitrum, а також незабаром всі EVM layer2

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

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

Додати опікунів (необов'язково): Користувач може призначити різні адреси 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 та отримати спільний обмін хмарними ключами, поєднати ці два обміни для відновлення гаманця.

Протокол 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 та доступності даних, ми прагнемо покращити продуктивність блокчейну. Також, дотримуючись реальної безпеки, поєднуючи приватність доказів нульового знання з природою прозорості. Усі зусилля спрямовані на одну мету: бути готовими до реальних користувачів, які часто взаємодіють з блокчейном та впроваджують криптовалюту в своє життя.

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

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

Наші будівельники зроблять це можливим. Інтегруючи WebAuthn та Passkey, ми покращуємо управління приватним ключем, зробивши його одночасно безпечним та зручним для користувачів. На вершині ключа SCA як сутність відкриває світ персоналізованої безпеки та функціональності. Щодо газових витрат? Вони стають менш обтяжливими, завдяки постачальникам Paymaster, які можуть створити "сховище" для свопів або навіть дозволити рекламодавцям покривати витрати для користувачів. В центрі цього розвитку, зокрема для головної мережі Ethereum та її еквівалентних Layer2, є ERC4337. Він вводить альтернативний мемпул, який відрізняє транзакції SCA від EOAs, без значних переглядів протоколу. З іншого боку, деякі мережі Layer 2 навіть приймають SCAs на рівні нативності, безшовно включаючи їх до своїх систем.

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

Disclaimer：

1. Ця стаття була перепечатана з [ SevenX Ventures]. Усі авторські права належать оригінальному автору [@Rui]. Якщо є заперечення до цього видруку, будь ласка, зв'яжіться з Gate Learnкоманда, і вони вирішать це негайно.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, що належать автору і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено, копіювання, поширення або плагіатування перекладених статей заборонене.