---
title: "Tanda tangan BLS"
description: "Panduan berfokus verifikasi untuk tanda tangan Boneh-Lynn-Shacham, mode agregasi, ciphersuite, pertahanan rogue key, penggunaan konsensus Ethereum, dan risiko implementasi."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Tanda tangan BLS
> 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
- [Hash kriptografis](/id/crypto/cryptographic-hash/)
- [Proof of stake](/id/crypto/proof-of-stake/)
- [Tanda tangan threshold](/id/crypto/threshold-signature/)
## Sumber
- [BLS Signatures](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-06) - Internet Research Task Force (accessed: 2026-08-12)
- [RFC 9380: Hashing to Elliptic Curves](https://www.rfc-editor.org/rfc/rfc9380.html) - RFC Editor (accessed: 2026-08-12)
- [Short Signatures from the Weil Pairing](https://doi.org/10.1007/3-540-45682-1_30) - Springer (accessed: 2026-08-12)
- [Ethereum Proof-of-Stake Consensus Specifications](https://github.com/ethereum/consensus-specs) - Ethereum Foundation (accessed: 2026-08-12)
- [Phase 0 Beacon Chain Specification](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (accessed: 2026-08-12)
- [Ethereum Annotated Specification: BLS Signatures](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#bls-signatures) - Ethereum Foundation (accessed: 2026-08-12)
- [EIP-2537: Precompile for BLS12-381 curve operations](https://eips.ethereum.org/EIPS/eip-2537) - Ethereum Improvement Proposals (accessed: 2026-08-12)
- [Consensus mechanisms](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org (accessed: 2026-08-12)
Source: https://wiki.fcontext.com/id/crypto/bls-signature/index.mdx