FROST

Bayangkan sebuah perkumpulan yang tabungannya dikelola Anna, Jan, dan Eva. Mereka memilih aturan 2 dari 3: Anna bersama Jan, Anna bersama Eva, atau Jan bersama Eva dapat menyetujui pembayaran. Masing-masing menyimpan bagian rahasia yang berbeda, yakni bagian materi kunci bersama yang dibentuk secara kriptografis. Satu bagian tidak cukup, tetapi ini juga bukan tiga salinan kata sandi yang sama. Jika Eva tidak tersedia, dua orang lainnya dapat bekerja sama. Batas yang sama berlaku bagi penyerang: memperoleh cukup bagian juga memungkinkannya menandatangani. Karena itu, pembagian hanya berguna jika pembobolan satu perangkat atau akun tidak membuka akses ke semua yang lain. [1] [2]

Anna tidak seharusnya mengonfirmasi operasi hanya karena aplikasi menampilkan permintaan tanda tangan. Ia perlu mengetahui penerima, jumlah, biaya, dan apakah uang kembalian kembali ke perkumpulan. Setiap penanda tangan memerlukan cara tepercaya untuk memeriksa transaksi sebenarnya. Hash, sidik jari kriptografis singkat dari data, tidak dengan sendirinya menjelaskan isi data kepada manusia. FROST memungkinkan kerja sama atas pesan yang sama; protokol ini tidak menilai keaslian tagihan atau apakah seseorang memahami apa yang disetujuinya. Tanda tangan yang selesai pun belum berarti pembayaran dikonfirmasi dalam blok. Blok adalah kumpulan transaksi yang dicatat dalam riwayat bersama jaringan Bitcoin. RFC 9591 adalah spesifikasi protokol yang bersifat informatif, bukan sertifikat keamanan seluruh aplikasi. [1] [2]

Taproot adalah peningkatan Bitcoin yang memungkinkan dana dibelanjakan dengan tanda tangan untuk kunci terkait atau dengan memenuhi syarat yang telah ditentukan. Tanda tangan berambang yang dibentuk dengan tepat dapat tampak seperti tanda tangan biasa dari satu kunci ketika membelanjakan dana melalui jalur kunci Taproot. Tanda tangannya saja tidak mengungkap jumlah bagian internal atau ambangnya. Ini membantu privasi dan ukuran data tanda tangan, tetapi tidak membuat seluruh transaksi atau komunikasi peserta menjadi anonim. Bitcoin memerlukan aturan BIP 340 secara tepat; FROST umum pada kurva secp256k1, dasar matematika perhitungan kunci Bitcoin, saja tidak cukup. Karena itu Zcash Foundation (ZF) menawarkan frost-secp256k1-tr khusus untuk Taproot. Penyesuaian kunci yang digunakan Taproot juga harus ditangani dengan benar. Nama kurva yang sama tidak membuktikan kompatibilitas, dan keberadaan pustaka tidak berarti setiap dompet mendukungnya. [3] [4]

Sebelum menandatangani apa pun, perkumpulan harus membuat bagian-bagiannya dengan aman. Distributor tepercaya dapat membuat kunci lengkap lalu membaginya. Namun, ada tahap sensitif: distributor mengetahui seluruh kunci, dan salinan yang disimpan dapat melewati persetujuan bersama yang direncanakan. Pilihan lain adalah DKG, pembuatan kunci terdistribusi, sehingga kunci rahasia lengkap tidak perlu muncul pada satu peserta. Proses ini memerlukan komunikasi terautentikasi dan terlindungi serta pelaksanaan protokol yang benar. Mengirim beberapa berkas lewat surel saja tidak cukup. RFC 9591 berfokus pada penandatanganan; dokumen itu tidak otomatis menjanjikan DKG di setiap produk. Bagian kunci jangka panjang juga berbeda dari bagian tanda tangan untuk satu pembayaran tertentu. [1] [2]

Penandatanganan itu sendiri berlangsung dalam dua putaran, tidak termasuk pembuatan kunci sebelumnya. Pertama, setiap peserta terpilih membuat dua nilai rahasia sekali pakai yang disebut nonce, lalu mengirim komitmen publiknya: nilai yang mengikatnya secara kriptografis pada nonce tersebut. Setelah itu ia menerima pesan bersama dan daftar komitmen, memeriksa data, lalu menghitung bagian tanda tangannya. Koordinator menggabungkan bagian-bagian itu. Faktor pengikat menghubungkan perhitungan dengan pesan tertentu, kunci publik kelompok, dan komitmen. Dengan aturan 2 dari 3, sesi dapat dimulai dengan dua peserta. Tetapi jika ketiganya dipilih untuk sesi tersebut, semuanya harus berkontribusi; peserta yang berhenti merespons tidak bisa sekadar diabaikan. [1] [3]

Nonce di sini adalah nilai rahasia untuk satu percobaan penandatanganan, bukan kata sandi yang dapat dipakai berulang kali. Penggunaan ulang dapat membocorkan materi kunci rahasia. Jika komputer Jan mengalami kegagalan setelah mengirim bagian tanda tangan, pemulihan keadaan lama tidak boleh menandai nonce yang sudah dipakai sebagai baru. Pembayaran yang belum selesai juga tidak membenarkan penggunaannya kembali. Implementasi yang aman membutuhkan keacakan yang baik, pemisahan percobaan serentak, dan penonaktifan nilai terpakai secara andal. Inilah salah satu alasan untuk tidak merakit FROST sendiri dari sembarang skrip. Matematika yang benar saja tidak melindungi data rahasia yang dikelola dengan keliru. [1]

Koordinator mengatur pesan, tetapi peran itu saja tidak memberinya kuasa menandatangani atas nama perkumpulan. Ia memerlukan kontribusi pemegang bagian yang dipilih. Meski begitu, ia dapat menahan komunikasi atau menghentikan sesi, sebagaimana kontribusi tidak valid dari peserta dapat menggagalkannya. Pemeriksaan dapat mendeteksi bagian tanda tangan yang tidak valid; mengaitkan kesalahan dengan orang tertentu memerlukan kepastian tepercaya tentang asal pesan. Menemukan masalah tidak menjamin proses selesai. Percobaan baru memerlukan kelompok berwenang yang tersedia dan nonce baru. Karena itu, perkumpulan membutuhkan rencana menghadapi gangguan dan perbedaan pendapat, bukan sekadar angka ambang di layar awal. [1] [2]

Jika Eva kehilangan perangkat, label FROST saja tidak akan memulihkan dana. Cadangan harus mempertahankan bagiannya, pengenal, data kelompok yang diperlukan, dan cara memuatnya ke perangkat lunak yang kompatibel. Ini tidak otomatis sama dengan Seed Phrase biasa, yaitu cadangan dompet berbentuk kata-kata. Pemulihan bagian dengan bantuan peserta lain dan pembaruan bagian merupakan prosedur tambahan yang harus didukung sistem tersebut. Salinan bagian Eva tetap merupakan bagian yang sama; tidak menambah suara independen. Pembaruan dengan kunci kelompok yang tetap sama juga tidak menetralkan kumpulan bagian lama yang telah dicuri dalam jumlah cukup. Sebelum memakai tabungan sungguhan, uji coba perlu mencakup pemulihan, gangguan, dan versi perangkat lunak yang tepat, bukan hanya satu tanda tangan yang berhasil. [2] [3]