Lompat ke konten
Financial Context Wiki

Tanda tangan BLS

Panduan berfokus verifikasi untuk tanda tangan Boneh-Lynn-Shacham, mode agregasi, ciphersuite, pertahanan rogue key, penggunaan konsensus Ethereum, dan risiko implementasi.

Diperbarui

Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

Jawaban langsung

Tanda tangan Boneh-Lynn-Shacham adalah tanda tangan digital berbasis pairing. Dalam orientasi umum, kunci rahasia sk menghasilkan kunci publik PK = sk * G1; pesan m dipetakan ke H(m) dalam G2; dan tanda tangan sig = sk * H(m) diverifikasi melalui e(PK, H(m)) = e(G1, sig). Grup, encoding, suite hash-to-curve, dan pemisahan domain yang tepat adalah pilihan ciphersuite, bukan notasi yang dapat dipertukarkan.

BLS memiliki keunggulan operasional yang tidak biasa: tanda tangan valid dapat dijumlahkan menjadi satu elemen grup berukuran konstan. Ini memampatkan tanda tangan, tetapi tidak memampatkan daftar penanda tangan, membuktikan quorum, mengenali validator berwenang, mencegah equivocation, atau membuat konsensus final. Sifat tersebut berasal dari protokol di sekelilingnya.

Cara kerjanya

  1. Tetapkan protokol, ciphersuite, dan versi: kurva, grup kunci publik dan tanda tangan, serialisasi, fungsi hash-to-curve, tag pemisahan domain, dan konstruksi message root. Jangan menyimpulkan kompatibilitas hanya dari label BLS.
  2. Buat sk dengan prosedur key generation yang ditetapkan dan turunkan PK. Tolak nol, infinity, encoding cacat, nonkanonis, dan subgroup salah menurut aturan KeyValidate serta deserialisasi yang tepat.
  3. Bentuk bytes pesan dan domain penandatanganan yang tepat. Dalam konsensus Ethereum, signing root mengikat root objek SSZ ke domain yang diturunkan dari jenis operasi dan data fork; teks tampilan bukan objek yang ditandatangani.
  4. Tanda tangani dan verifikasi satu per satu dengan skema terpilih. Varian Basic, message augmentation, dan proof-of-possession memiliki pertahanan rogue key berbeda dan tidak boleh dicampur sembarangan.
  5. Pilih verifier agregat berdasarkan pola pesan. Gunakan FastAggregateVerify hanya untuk beberapa kunci publik tervalidasi yang menandatangani pesan sama dengan asumsi proof-of-possession yang diwajibkan; gunakan AggregateVerify untuk daftar kunci dan pesan yang diizinkan skema.
  6. Rekonstruksi himpunan penanda tangan secara independen dari data komite atau participant bitlist, tolak indeks duplikat atau tanpa wewenang, terapkan bobot stake atau threshold, lalu verifikasi tanda tangan agregat. Agregat valid mengautentikasi himpunan yang diberikan; ia tidak memutuskan apakah himpunan memenuhi kebijakan.
  7. Rekonsiliasi hasil dengan fork choice, kondisi slashing, quorum, availability, waktu, dan finality. Simpan input bytes, domain, indeks penanda tangan, versi implementasi, dan test vectors, serta bandingkan pustaka independen sebelum deployment.

Contoh terhitung

  • Kompresi tidak menghapus data keanggotaan. Konsensus Ethereum mengodekan setiap kunci publik BLS sebagai 48 bytes dan setiap tanda tangan sebagai 96 bytes. Untuk 512 tanda tangan pesan sama, tanda tangan terpisah memakai 512 * 96 = 49,152 bytes. Satu tanda tangan agregat beserta participant bitlist 512-bit = 64-byte memakai 96 + 64 = 160 bytes, pengurangan 49,152 - 160 = 48,992 bytes, atau 99.6744791667%. Kunci publik validator dan pemetaan komite tetap harus tersedia di tempat lain.
  • Agregasi pesan sama. Validator terdaftar 17, 24, dan 91 menandatangani signing root identik R. Tanda tangan mereka diagregasi sebagai sigAgg = sig17 + sig24 + sig91. Verifikasi memakai himpunan kunci publik tervalidasi dan berurutan [PK17, PK24, PK91], R yang sama, dan FastAggregateVerify. Hasil valid membuktikan kunci tersebut menandatangani R dalam skema; aturan terpisah menentukan bobot dan apakah tiga penanda tangan membentuk quorum.
  • Pesan berbeda memerlukan API yang benar. Kunci PK1, PK2, dan PK3 menandatangani pesan berbeda m1, m2, dan m3. Verifier harus mempertahankan pasangan [PK1, m1], [PK2, m2], [PK3, m3] dan memanggil AggregateVerify yang berlaku; menggantinya dengan satu pesan dan FastAggregateVerify memverifikasi klaim berbeda. Dalam skema Basic, pesan juga harus berbeda.
  • Agregasi bukan threshold signing. Dalam grup 8 anggota, agregasi biasa tanda tangan anggota [1, 2, 4, 6, 8] menghasilkan satu tanda tangan dan daftar lima penanda tangan. Ini tidak menjadi tanda tangan threshold 5-of-8 di bawah satu kunci publik grup. Threshold-BLS sejati memerlukan distributed key generation atau trusted dealer, indeks share, dan aturan interpolasi; asumsi kepercayaan dan kegagalannya harus diaudit terpisah.

Risiko

  • Memakai kurva, orientasi grup, atau ciphersuite yang berbeda dari protokol.
  • Menandatangani bytes serialisasi berbeda meski menampilkan pesan yang sama.
  • Menghilangkan domain fork, operasi, atau aplikasi sehingga memungkinkan replay lintas konteks.
  • Memperlakukan Internet-Draft kedaluwarsa sebagai standar final yang tidak berubah.
  • Menerima encoding titik cacat, nonkanonis, atau infinity.
  • Melewatkan pemeriksaan subgroup dan menerima input invalid-curve atau small-subgroup.
  • Memakai code hash-to-curve buatan sendiri, bukan suite dan test vectors yang ditetapkan.
  • Menghasilkan kunci rahasia bias, nol, duplikat, bocor, atau dapat diprediksi.
  • Memakai ulang kunci pada protokol dengan asumsi proof-of-possession dan domain berbeda.
  • Mengagregasi kunci publik tidak terdaftar tanpa pertahanan rogue key yang diwajibkan.
  • Memanggil verifikasi cepat pesan sama untuk pesan berbeda atau root tidak konsisten.
  • Menukar, menduplikasi, atau menghilangkan asosiasi kunci publik dengan pesan.
  • Memercayai participant bitlist tanpa memeriksa keanggotaan komite dan keunikan indeks.
  • Menghitung tanda tangan, bukan stake, bobot, atau threshold yang ditentukan protokol.
  • Menganggap satu agregat mengungkap tanda tangan individual yang tidak valid.
  • Mencampur agregasi biasa, multisignatures, dan threshold signatures.
  • Menganggap validitas tanda tangan sebagai bukti availability, kebenaran eksekusi, atau finality.
  • Mengabaikan equivocation, pesan slashable, jendela waktu, atau konteks fork choice.
  • Bergantung pada satu pustaka, fitur CPU, atau optimasi batch verification yang tidak diperiksa.
  • Meremehkan biaya pairing, input denial-of-service, side channel, kustodi kunci, upgrade, dan ketiadaan keamanan pascakuantum.

Kesalahpahaman umum

  • Tanda tangan agregat membuktikan setiap validator berpartisipasi.
  • Kunci publik dan tanda tangan BLS apa pun dapat digabungkan aman tanpa aturan proof-of-possession.
  • Agregasi berukuran konstan menghapus kebutuhan mengirim atau merekonstruksi keanggotaan penanda tangan.
  • Agregasi BLS dan threshold BLS adalah konstruksi yang sama.
  • Tanda tangan BLS valid membuat blok, pesan bridge, atau protokol aman secara ekonomi dan final.

Topik terkait

Sumber

Navigasi

Cari di wiki...