Semua orang membicarakan Abstraksi Akun (AA) dan potensinya untuk merevolusi pengalaman pengguna dalam ruang blockchain. Namun, salah satu kesalahpahaman utama tentang AA adalah bahwa ia melampaui sekadar mengabstraksi biaya gas atau memungkinkan transaksi batch. Bagaimana caranya? Melalui sistem manajemen kunci yang dapat diprogram.

Sistem-sistem ini dapat memberikan keamanan tingkat perangkat keras untuk perangkat sehari-hari dan mengintegrasikan metode otentikasi Web2 ke dalam lingkungan Web3, memungkinkan kita untuk melampaui frase benih 12 kata tradisional. Hari ini, saya akan menjelaskan berbagai sistem pengelolaan kunci yang dapat digunakan oleh pengembang dan kasus penggunaan khusus di mana mereka paling berguna.

Bergerak melampaui 12 kata

Industri kita sangat menyukai istilah-istilah yang sedang trend, dan “tanpa benih” adalah salah satunya yang berhasil menarik perhatian. Meskipun kita semua sepakat bahwa mengharapkan pengguna menyimpan kunci pribadi mereka secara aman adalah tidak praktis dan telah menyebabkan kehilangan jutaan dolar, pertanyaannya tetap: jika kita tidak menampilkan frasa benih kepada pengguna, di mana kita menyimpan kunci-kunci tersebut?

Tanpa Abstraksi Akun (AA), sebagian besar solusi yang ada bergantung pada Perhitungan Multi-Pihak (MPC) untuk mendistribusikan kunci ke beberapa bagian dan membuat ambang batas untuk melakukan transaksi. Solusi-solusi ini sering mengklaim sebagai self-custodial, namun hal ini tidak sepenuhnya akurat. Sebagai contoh, Binance menyimpan satu bagian dari kunci, bertindak sebagai penjaga keamanan jika pengguna kehilangan perangkat mereka. Konfigurasi ini berarti bahwa, meskipun klaim tersebut, pengguna tidak sepenuhnya mengontrol kunci mereka, dan masih ada ketergantungan pada entitas terpusat untuk pemulihan kunci.

Selain itu, jika ada bagian kunci yang bocor, tidak ada cara untuk mencabut kunci dari akun utama. Pencabutan tidak mungkin karena Akun Milik Eksternal (EOA) tidak mendukung rotasi kunci, yang berarti kunci yang bocor akan selalu menjadi bagian dari akun. Ini merupakan risiko keamanan yang signifikan, karena kunci yang kompromi tidak dapat digantikan atau dihapus, meninggalkan akun rentan secara tidak terbatas.

Jika Anda ingin belajar lebih lanjut tentang bagaimana AA membuka jalan untuk akun yang dapat diprogram dan rotasi kunci, Anda dapatperiksa artikel saya.

1. Akun sepenuhnya dapat diprogram: Abstraksi akun

Account Abstraction memungkinkan pengembang membangun sistem manajemen kunci yang berbeda. Sebuah akun dapat dikontrol dengan beberapa kunci dan metode otentikasi yang berbeda, semua mendukung rotasi kunci. Lebih baik lagi, kekuatan kunci dapat dibedakan. Ini berarti pengguna dapat menggunakan kunci yang berbeda untuk akun yang sama, masing-masing disesuaikan untuk kasus penggunaan yang berbeda. Saya akan menjelaskan kasus penggunaan ini lebih detail nanti.

Dengan AA, dana disimpan dalam kontrak pintar, dan kepemilikan akun ditentukan oleh kontrak pintar ini. Akun yang kompatibel dengan EIP-4337 memiliki dua bagian dalam transaksinya.

1. Bagian pertama adalah verifikasi, di mana kepemilikan akun diverifikasi on-chain.
2. Bagian kedua adalah eksekusi, yang menjalankan pesan.

Kedua bagian tersebut sepenuhnya dapat diprogram; misalnya, Anda dapat menentukan dua kunci (i, ii), dan kunci pertama (i) dapat menjalankan transaksi langsung, sedangkan kunci kedua (ii) hanya dapat menjalankan transaksi setelah kunci waktu terkunci. Ini berarti bahwa kita dapat menentukan kekuatan kunci, menambahkan kunci waktu, atau mengaktifkan kondisi lain untuk menjalankan transaksi.

Jadi, ketika kita berbicara tentang akun tradisional (EOA) otentikasi sama dengan otorisasi. Dengan AA, otorisasi dapat diprogram, sehingga pengembang dapat mendefinisikan skema kontrol akses berbasis peran dan menegakkan prinsip hak istimewa paling sedikit.

Ada banyak metode otentikasi (yaitu, sistem manajemen kunci) di dunia kripto yang dapat mengaktifkan skema kontrol akses berbasis peran, dan menggunakan hanya satu kunci tidak dapat menyelesaikan semua masalah yang terkait dengan manajemen kunci. Aspek paling penting dari sistem manajemen kunci adalah: di mana kunci disimpan dan siapa yang mengotentikasi kunci tersebut.

Kelebihan dan kekurangan dari berbagai sistem manajemen kunci

Saya akan dengan cepat merangkum Passkeys (Consumer Secure Enclaves), Solusi Berbasis MPC, Solusi TEE Berbasis Cloud, Solusi Penyimpanan Aman, 12 kata tradisional dan Kunci Sesi. Setelah itu, akan menjelaskan kombinasi terbaik.

1. 12 kata tradisional - (secp256k1) -

Bitcoin dan Ethereum mendukungsecp256k1Algoritma ECC (elliptic curve cryptography) digunakan untuk membuat kunci privat dan menyimpannya pada perangkat pengguna. Metode ini banyak digunakan dalam EOAs dan juga dapat diterapkan padaakun pintarUntuk menggunakannya, aplikasi dompet menghasilkan kunci pribadi menggunakan algoritma pembangkitan kunci acak dan kemudian menyimpan kunci pribadi di penyimpanan bersama.

Menggunakan secp256k1 memiliki beberapa keuntungan: tidak ada biaya gas tambahan, murah, dan mudah diverifikasi di onchain melalui ecrecover precompile. Ini juga self-custodial karena hanya pengguna yang dapat mengakses kunci.

Namun, ada beberapa keterbatasan:

1. Menyampaikan kepada pengguna tentang cara menyimpan kunci mereka dengan aman jika mereka kehilangan perangkat mereka adalah hal yang menantang.
2. Trojan atau malware dapat mencuri kunci pribadi dari perangkat pengguna karena disimpan di penyimpanan bersama.

NIST tidak mendukung kurva secp256k1, yang berarti kurva ini tidak umum didukung oleh kerangka kerja populer dan sebagian besar perangkat keras.

2. Passkeys (Consumer Secure Enclaves)

Hampir semua perangkat modern memiliki dua komponen utama: sistem operasi (dengan penyimpanan bersama terkait) dan Secure Enclave. Sistem operasi menangani sebagian besar operasi kecuali tugas-tugas sensitif seperti melindungi data biometrik, kunci kriptografi, enkripsi, dan membuka kunci perangkat.

Para pengembang menciptakan chip mikro khusus yang disebut Secure Enclave untuk mengelola operasi sensitif ini secara terpisah. Secure Enclave berfungsi secara mirip dengan dompet perangkat keras; ia beroperasi secara independen, mengelola data sensitif secara aman, dan bahkan pemilik perangkat tidak dapat mengakses isinya. Untungnya, Secure Enclave mendukung operasi kriptografi, seperti membuat kunci pribadi dan menandatangani pesan dengan kunci tersebut. Sayangnya, Secure Enclave tidak mendukung kurva yang didukung Ethereum (secp256k1), melainkan mendukung kurva p256. Untuk mengaktifkan verifikasi P256 asli, kami (@getclave"">Tim @getclave) mengusulkanRIP-7212dan hampir semua rollup besar sekarang mendukungnya.

Dan bagian terbaik tentang Secure Enclaves adalah kita dapat membuat kunci privat di dalam Secure Enclaves hanya dengan otentikasi biometrik yang memungkinkan pengalaman onboarding dengan sekali klik dengan keamanan terbaik yang tersedia pada perangkat modern - tingkat perangkat keras. Tetapi ini juga memiliki beberapa kekurangan:

• Verifikasi P256 tanpa RIP-7212 mahal dan meningkatkan risiko bug.
• Karena kunci tidak dapat diekstrak, kemampuan pemulihan hilang di sini (Passkeys memungkinkan pemulihan terbatas tetapi tidak cukup)
• Jika domain web dari passkey, atau aplikasi Secure Enclave (SE) berhenti berfungsi, pengguna tidak dapat mengakses kunci pribadi karena Secure Enclave dirancang untuk terisolasi dan independen. Tanpa aplikasi terkait atau domain web, tidak ada cara untuk mengambil atau berinteraksi dengan kunci pribadi, sehingga pengguna tidak dapat melakukan operasi kriptografi yang diperlukan. - Saya akan menjelaskan bagaimana cara mengatasi masalah ini.

3. Solusi manajemen kunci berbasis SSS

Solusi SSS (Shamir's Secret Sharing) menciptakan cara untuk menghilangkan titik kegagalan tunggal yang dimiliki sistem manajemen kunci tradisional. Mereka pada dasarnya membagi kunci menjadi bagian-bagian yang berbeda dan menetapkan ambang batas untuk mengakses kunci. Dengan mendistribusikan bagian-bagian ini, SSS memastikan bahwa tidak ada entitas tunggal yang memiliki seluruh kunci, sehingga meningkatkan keamanan.

Mari kita periksa di mana mereka menyimpan kunci-kunci dan bagaimana mereka mencapai kuorum untuk mengakses kunci pribadi. Sebagian besar protokol yang ada menggunakan tiga bagian kunci: satu bagian disimpan di perangkat pengguna, satu disimpan di server mereka (atau dalam Jaringan MPC), dan satu disimpan sebagai cadangan. Beberapa aplikasi, seperti Google Drive, memanfaatkan solusi penyimpanan awan untuk menyimpan bagian-bagian kunci ini.

Jadi, pengguna mendellegasikan kontrol dompet mereka kepada pihak lain dengan kuorum. MPC (Multi-Party Computation) sangat kuat untuk mendellegasikan tanggung jawab pengelolaan kunci kepada pihak-pihak yang berbeda, tetapi juga memiliki beberapa kekurangan:

Sebagian besar solusi MPC membutuhkan pihak yang terpusat, dan terkadang, apa yang mereka sebut sebagai desentralisasi sebenarnya bukan desentralisasi yang sebenarnya. MPC dengan AA sangat kuat karena rotasi kunci memungkinkan, tetapi banyak solusi MPC termasuk beberapa fungsi untuk pengaturan gerbang. Juga dalam banyak kasus, kunci sebelumnya mungkin masih digunakan bahkan setelah rotasi sehingga seseorang perlu mempercayai bahwa kunci benar-benar dibuang Beberapa solusi MPC dapat menyensor pengguna, sehingga hanya mengandalkan MPC tidak selalu layak.

Salah satu kekurangan utama dari SSS adalah bahwa itu merekonstruksi kunci privat, biasanya di peramban. Ini adalah risiko keamanan besar bagi kunci teks biasa untuk tersedia di sisi klien. TSS tidak pernah merekonstruksi kunci dan menggunakan MPC untuk mengfederasikan penandatanganan di seluruh bagian kunci.

4. Solusi TEE Berbasis Awan

Saya tidak berpikir Lingkungan Eksekusi Terpercaya Berbasis Cloud (TEEs) dan solusi berbasis SSS sangat berbeda, tetapi saya masih ingin menjelaskan bagaimana mereka bekerja. Lingkungan Eksekusi Terpercaya berfungsi persis seperti yang dikodekan; mereka tidak dapat diubah (setidaknya mereka mengklaim demikian), dan TEE tidak menunjukkan apa yang ada di dalamnya bahkan kepada pemilik TEE. Mereka dirancang untuk bekerja dengan integritas - melakukan hal yang benar bahkan jika tidak ada yang melihat. Jadi, kunci tidak pernah terbuka untuk klien begitu TEE sedang melakukan pekerjaan mereka dengan benar.

Dengan memanfaatkan TEEs, kami dapat membangun lapisan pengelolaan kunci di mana pengembang dapat menggunakan metode otentikasi yang berbeda, dan TEE dapat memverifikasinya. Setelah verifikasi, TEE menandatangani pesan dengan kunci pribadi yang terkait dengan pengguna dan memverifikasinya on-chain.

Kunci privat utama yang mengendalikan dana pengguna disimpan di dalam TEE dan tidak dapat diekstrak. Hal ini mengancam desentralisasi karena jika layanan memutuskan untuk menutup atau menyensor pengguna, tidak ada yang bisa dilakukan oleh pembangun dApp.

TEE berbasis cloud terlihat menjanjikan dalam teori, tetapi di masa lalu, kami telah melihat kerentanan sepertisgx.faildi cloud TEEs. Namun, keunggulan dari TEEs adalah meskipun ada backdoor atau kerentanan, penyerang memerlukan akses fisik ke TEE, itulah mengapa perangkat keras konsumen (Secure Enclave - Passkeys) sangat kuat karena perangkat keras konsumen menyimpan kunci di dalam Secure Enclave pengguna dan hanya pemilik yang dapat mengakses kunci, sedangkan TEE Cloud menyimpan kunci di dalam cloud dan ini membuatnya rentan terhadap serangan.

Bukan lingkungan aman Anda, bukan koin Anda.

Seperti yang telah saya sebutkan, TEE memiliki beberapa kelebihan, seperti menggunakan hampir semua metode otentikasi tanpa adanya pembatas kriptografi. Namun, mereka juga memiliki beberapa kelemahan:

Jika penyedia layanan menutup server, dana pengguna akan dibekukan dan tidak ada yang dapat mengaksesnya. Kunci disimpan di dalam Cloud TEE, yang berarti mereka dapat menyensor pengguna. Bergantung hanya pada TEE untuk manajemen kunci menciptakan titik kegagalan tunggal.

Kunci Sesi: Cara baru untuk izin terbatas

Kami telah membicarakan tentang kunci permanen. Bagaimana jika kita dapat menghasilkan kunci temporal yang memiliki akses terbatas ke aset dan menghilang setelah waktu yang pengguna tentukan? Kunci Sesi memungkinkan kita melakukannya:

Di dunia web2, kunci sesi seperti sandi sementara yang digunakan selama percakapan antara dua perangkat (seperti komputer Anda dan server). Mereka dibuat di awal percakapan, digunakan untuk menjaga informasi yang dibagikan aman, dan kemudian dibuang setelah percakapan berakhir. Jadi, bahkan jika seorang peretas dengan cara tertentu mengetahui sandi ini, mereka tidak dapat menggunakannya untuk mendengarkan percakapan di masa depan karena sandi baru yang berbeda (atau kunci sesi) dibuat setiap kali.

Seperti di dunia Web3, kami mendefinisikan kunci sesi sebagai kerangka kerja yang berpotensi mengubah cara pengguna berinteraksi dengan dApps. Tujuan dari kunci sesi adalah memungkinkan pengguna untuk mengatur persetujuan awal untuk waktu tertentu dalam berbagai skenario dan melakukan transaksi tanpa tanda tangan. Namun bagaimana cara kerjanya?

Pengguna membuat izin terbatas seperti kunci sesi yang dapat menghabiskan aset hanya sebagaimana yang ditentukan oleh pengguna, untuk jangka waktu yang terbatas, dan dapat ditarik kembali kapan saja. Setelah itu, layanan backend memungkinkan pengguna melakukan transaksi dengan menandatanganinya atas nama mereka. Pengaturan ini menciptakan jendela kepercayaan sementara antara dApp dan pengguna. Ini jauh lebih baik daripada persetujuan tak terbatas karena persetujuan yang diberikan pengguna hanya untuk aset tertentu dan untuk jangka waktu yang ditentukan. Bahkan jika dApp diretas, pengguna tidak perlu khawatir tentang kunci sesi yang dibuat beberapa bulan yang lalu 🙂.

Kombinasi autentikasi dan pengelolaan kunci terbaik untuk berbagai kasus penggunaan

Saya telah menjelaskan berbagai sistem manajemen kunci dan pro dan kontra mereka. Dengan kekuatan AA, kita dapat menggabungkan sistem manajemen kunci ini dan membuat struktur yang kuat dengan sedikit kompromi. Mari kita jelaskan C.1) Passkey + pemulihan dengan kunci waktu - Clave - sebuah aplikasi fintech yang menyimpan dana berharga.

Metode otentikasi berbasis Secure Enclave (passkeys) menyediakan keamanan tingkat perangkat keras; namun, kemampuan pemulihan mereka sering kali tidak mencukupi bagi sebagian besar pengguna. Untungnya, AA memungkinkan pengembang untuk menggabungkan berbagai metode penandatanganan dan menggunakannya dalam satu akun. Dengan menambahkan penandatangan pemulihan ke akun pintar, kita dapat memecahkan masalah pemulihan yang dimiliki oleh passkeys.

Ada beberapa opsi pemulihan seperti pemulihan sosial, pemulihan universal (Pemulihan Berbasis ZK-Email), dan pemulihan berbasis MPC. Namun, menurut pendapat saya, untuk aplikasi fintech yang dirancang untuk sepenuhnya mandiri, pemulihan sosial dapat menyelesaikan sebagian besar masalah. Di Clave, kami membangun modul pemulihan sosial dan sedang mengerjakan Pemulihan Universal.

Pendekatan ini memaksimalkan keamanan, yang bagus untuk aplikasi keuangan. Tetapi memiliki kelemahan penting: aplikasi memerlukan otentikasi biometrik untuk setiap transaksi yang ingin pengguna lakukan. Bayangkan jika Anda ingin membagikan konten di aplikasi media sosial dan aplikasi tersebut muncul layar tanda tangan biometrik... mengerikan, bukan?

Aplikasi non-keuangan seperti aplikasi sosial-Fi dan permainan terdesentralisasi memerlukan cara yang lebih mudah untuk melakukan transaksi, idealnya tanpa memerlukan pengguna untuk menandatangani setiap transaksi. Bagaimana caranya? Inilah jawabannya:

1. Passkey + pemulihan dengan kunci waktu + kunci sesi — aplikasi sosial seluler

Kunci sesi memungkinkan pengguna melakukan transaksi tanpa tampilan tanda tangan. Game atau aplikasi sosial berbasis NFT dapat mewarisi kunci sesi untuk mendapatkan akses sementara dan terbatas ke aset pengguna. Jika Anda berpikir ini menambah asumsi kepercayaan tambahan, mari kita jelaskan bagaimana antarmuka depan hari ini bekerja:

Hari ini, sebagian besar pengguna bahkan tidak memeriksa apa yang mereka tandatangani saat bermain game atau berinteraksi dengan dApp. Ini berbahaya karena front-end jahat dapat menyebabkan pengguna kehilangan semua aset mereka.

Kunci sesi adalah alternatif yang lebih baik untuk ini. Pengguna dapat memeriksa berapa lama sesi akan aktif dan aset apa yang dapat diakses oleh sesi tersebut, mengurangi kebutuhan untuk mempercayai dApp. Setelah waktu sesi berakhir, pengguna tidak perlu khawatir tentang persetujuan = Tidak perlu lagirevoke.cashseperti aplikasi :)

2. Penandatangan berbasis MPC atau cloud TEE + penandatangan self-custodial untuk escape

Kelemahan dari lapisan manajemen kunci pihak ketiga berbasis MPC atau Cloud TEE adalah bahwa sebagian besar tidak self-custodial dan memiliki komponen terpusat yang signifikan. Namun, beberapa dApps memerlukan dompet tertanam tanpa overhead gas tambahan, memerlukan solusi berbasis MPC atau Cloud TEE. Menambahkan penandatangan tambahan untuk "rage quit" dapat memecahkan masalah sensor yang dimiliki sistem manajemen kunci ini dan juga mengurangi potensi masalah hukum yang mungkin dihadapi dApps ini. Anda memerlukan dompet pintar untuk membangun ini karena rotasi kunci tidak dimungkinkan dengan EOA.

Sudah ada beberapa aplikasi yang menggunakan arsitektur pengelolaan kunci ini.

3. 12 kata + Pemegang Kunci Perangkat Keras untuk memaksimalkan keamanan - Pengalaman ekstensi browser DeFi

Pengguna DeFi menyukai pengalaman ekstensi browser, dan mengubah perilaku pengguna adalah salah satu hal terberat di dunia modern. Jadi, mengapa tidak membangun alternatif yang lebih baik? Menggabungkan perangkat keras penanda (Secure Enclave atau Passkey Signer) dengan frasa bijak 12 kata yang dapat diakses melalui ekstensi juga dapat memecahkan masalah kunci pribadi yang bocor. Pendekatan ini meningkatkan keamanan tanpa perlu mengubah perilaku pengguna. Beberapa tim di industri AA sedang bekerja untuk memungkinkan ini. (mis. @myBraavos)

Akun pintar tidak cukup pintar

Bayangkan bahwa Anda adalah pengguna yang pertama kali menghasilkan EOA dengan @MetaMaskdan kemudian menemukan alternatif seperti Zerion. Anda memutuskan untuk menggunakan @zerion, dan yang perlu Anda lakukan hanyalah mengimpor frasa benih Anda—sederhana. Sekarang, bayangkan mencoba melakukan hal yang sama di Starknet, di mana semua dompet adalah akun pintar. Anda tidak bisa, karena Braavos dan Argent tidak kompatibel. Masalah ini juga ada di dalam ekosistem EIP-4337 dan @zkSyncAA asli.

Kita memerlukan standar (bukan gatekeepers) atau setidaknya cara yang lebih baik untuk mendanai dompet baru. Jika tidak, tidak akan pernah ada adopsi dompet pintar secara luas, dan pemain yang sudah ada akan tetap menjadi pembuat keputusan, mendikte praktik industri bahkan jika mereka tidak benar.

Selain itu, "rage quit" harus menjadi fitur default, karena aktor sentral di hampir semua sistem manajemen kunci dapat dimatikan. Seharusnya lebih mudah bagi pengguna untuk mengubah penandatangan atau mengganti kontrak pintar, dan hosting mandiri harus menjadi opsi default bagi pengguna. Ada dua standar akun pintar modular: ERC-6900 dan ERC-7579. Mereka berdua berusaha mencapai tujuan yang sama - untuk membuat akun pintar lebih pintar.

Terima kasih khusus kepadaDerek ,Konrad, danNoamuntuk umpan balik dan komentar!

Penafian:

1. Artikel ini dicetak ulang dari [.X]. Semua hak cipta adalah milik penulis asli [2077Penelitian]. Jika ada keberatan terhadap cetakan ulang ini, silakan hubungi Gerbang Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penyangkalan Tanggung Jawab: Pandangan dan pendapat yang terdapat dalam artikel ini sepenuhnya merupakan pandangan penulis saja dan tidak merupakan nasihat investasi.
3. Tim Pembelajaran Gate menerjemahkan artikel ke dalam bahasa lain. Menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang kecuali disebutkan.