---
title: "ลายเซ็น BLS"
description: "คู่มือที่เน้นการตรวจสอบลายเซ็น Boneh-Lynn-Shacham รูปแบบการรวม ciphersuite การป้องกัน rogue key การใช้ในฉันทามติ Ethereum และความเสี่ยงของ implementation"
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.

# ลายเซ็น BLS

> จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

<a id="answer"></a>

## คำตอบโดยตรง

ลายเซ็น Boneh-Lynn-Shacham เป็นลายเซ็นดิจิทัลที่อิง pairing ในการจัดวางที่ใช้ทั่วไป secret key `sk` สร้าง public key `PK = sk * G1` ข้อความ `m` ถูก map เป็น `H(m)` ใน `G2` และลายเซ็น `sig = sk * H(m)` ตรวจสอบผ่าน `e(PK, H(m)) = e(G1, sig)` กลุ่ม encoding ชุด hash-to-curve และการแยกโดเมนที่แน่นอนเป็นตัวเลือกของ ciphersuite ไม่ใช่สัญกรณ์ที่สลับกันได้

BLS มีข้อได้เปรียบในการใช้งานที่ไม่ธรรมดา คือสามารถบวกลายเซ็นที่ถูกต้องเป็นองค์ประกอบกลุ่มขนาดคงที่หนึ่งรายการได้ วิธีนี้บีบอัดลายเซ็น แต่ไม่ได้บีบอัดรายชื่อผู้ลงนาม พิสูจน์ quorum ระบุ validator ที่ได้รับอนุญาต ป้องกัน equivocation หรือทำให้ฉันทามติ final คุณสมบัติเหล่านั้นมาจากโปรโตคอลที่อยู่รอบลายเซ็น

<a id="mechanism"></a>

## วิธีการทำงาน

1. กำหนดโปรโตคอล ciphersuite และเวอร์ชัน ได้แก่ curve กลุ่ม public key และลายเซ็น serialization ฟังก์ชัน hash-to-curve domain-separation tag และการสร้าง message root ห้ามอนุมานความเข้ากันได้จากชื่อ BLS เพียงอย่างเดียว
2. สร้าง `sk` ด้วยขั้นตอน key generation ที่กำหนด แล้วหา `PK` ปฏิเสธค่าศูนย์ infinity encoding ที่ผิดรูป ไม่เป็น canonical หรืออยู่ผิด subgroup ตามกฎ `KeyValidate` และ deserialization ที่แน่นอน
3. สร้าง bytes ของข้อความและโดเมนสำหรับลงนามให้ตรง ในฉันทามติ Ethereum signing root ผูก root ของวัตถุ SSZ เข้ากับโดเมนที่มาจากประเภท operation และข้อมูล fork ข้อความที่แสดงไม่ใช่วัตถุที่ลงนาม
4. ลงนามและตรวจสอบรายรายการด้วย scheme ที่เลือก รูปแบบ Basic message augmentation และ proof-of-possession มีการป้องกัน rogue key ต่างกัน และไม่ควรนำมาปะปนโดยไม่ตรวจสอบ
5. เลือก verifier สำหรับ aggregate ตามรูปแบบข้อความ ใช้ `FastAggregateVerify` เฉพาะ public key หลายรายการที่ผ่านการตรวจและลงนามข้อความเดียวกัน ภายใต้สมมติฐาน proof-of-possession ที่กำหนด ใช้ `AggregateVerify` สำหรับรายการ public key และข้อความที่ scheme อนุญาต
6. สร้างชุดผู้ลงนามใหม่อย่างอิสระจากข้อมูลคณะกรรมการหรือ participant bitlist ปฏิเสธดัชนีซ้ำหรือไม่มีสิทธิ ใช้น้ำหนัก stake หรือ threshold แล้วตรวจลายเซ็น aggregate ลายเซ็นรวมที่ถูกต้องยืนยันชุดที่ป้อน แต่ไม่ได้ตัดสินว่าชุดนั้นผ่านนโยบายหรือไม่
7. กระทบยอดผลกับ fork choice เงื่อนไข slashing quorum availability เวลา และ finality เก็บ input bytes โดเมน ดัชนีผู้ลงนาม เวอร์ชัน implementation และ test vectors และเปรียบเทียบไลบรารีอิสระก่อน deployment

<a id="example"></a>

## ตัวอย่างคำนวณ

- **การบีบอัดไม่ลบข้อมูลสมาชิก** ฉันทามติ Ethereum encode public key BLS แต่ละรายการเป็น `48 bytes` และลายเซ็นแต่ละรายการเป็น `96 bytes` สำหรับลายเซ็นข้อความเดียวกัน `512` รายการ ลายเซ็นแยกใช้ `512 * 96 = 49,152 bytes` ลายเซ็น aggregate หนึ่งรายการบวก participant bitlist ขนาด `512-bit = 64-byte` ใช้ `96 + 64 = 160 bytes` ลดลง `49,152 - 160 = 48,992 bytes` หรือ `99.6744791667%` Public key ของ validator และ mapping คณะกรรมการยังต้องมีอยู่ที่อื่น
- **การรวมข้อความเดียวกัน** สมมติ validator ที่ลงทะเบียน `17` `24` และ `91` ลงนาม signing root เดียวกัน `R` ลายเซ็นรวมเป็น `sigAgg = sig17 + sig24 + sig91` การตรวจใช้ชุด public key ที่เรียงลำดับและตรวจแล้ว `[PK17, PK24, PK91]` ใช้ `R` เดียวกันและ `FastAggregateVerify` ผลที่ถูกต้องพิสูจน์ว่าคีย์เหล่านี้ลงนาม `R` ตาม scheme ส่วนกฎอีกชุดเป็นผู้กำหนดน้ำหนักและตัดสินว่าผู้ลงนามสามรายเป็น quorum หรือไม่
- **ข้อความต่างกันต้องใช้ API ที่ถูกต้อง** คีย์ `PK1` `PK2` และ `PK3` ลงนามข้อความต่างกัน `m1` `m2` และ `m3` Verifier ต้องรักษาคู่ `[PK1, m1]` `[PK2, m2]` `[PK3, m3]` และเรียก `AggregateVerify` ที่ใช้ได้ การแทน input เหล่านี้ด้วยข้อความเดียวและ `FastAggregateVerify` เป็นการตรวจข้อกล่าวอ้างคนละอย่าง ภายใต้ Basic scheme ข้อความต้องแตกต่างกันด้วย
- **การรวมไม่ใช่ threshold signing** ในกลุ่มสมาชิก `8` ราย การรวมลายเซ็นปกติจากสมาชิก `[1, 2, 4, 6, 8]` ให้ลายเซ็นหนึ่งรายการพร้อมรายชื่อผู้ลงนามห้าราย ไม่ได้กลายเป็นลายเซ็น threshold แบบ `5-of-8` ภายใต้ group public key เดียว Threshold-BLS ที่แท้จริงต้องมี distributed key generation หรือ trusted dealer ดัชนี share และกฎ interpolation และต้องตรวจสมมติฐานด้านความเชื่อถือกับความล้มเหลวแยกต่างหาก

<a id="risks"></a>

## ความเสี่ยง

- ใช้ curve การจัดวางกลุ่ม หรือ ciphersuite ที่ต่างจากโปรโตคอล
- ลงนาม bytes ที่ serialize ต่างกัน แม้แสดงข้อความเดียวกันให้มนุษย์อ่าน
- ไม่ใส่โดเมน fork operation หรือแอปพลิเคชัน ทำให้ replay ข้ามบริบทได้
- ถือ Internet-Draft ที่หมดอายุเป็นมาตรฐานสุดท้ายที่เปลี่ยนไม่ได้
- ยอมรับ encoding จุดที่ผิดรูป ไม่เป็น canonical หรือเป็น infinity
- ข้ามการตรวจ subgroup และรับ input แบบ invalid-curve หรือ small-subgroup
- ใช้ code hash-to-curve ที่สร้างเองแทน suite และ test vectors ที่กำหนด
- สร้าง secret key ที่มี bias เป็นศูนย์ ซ้ำ รั่วไหล หรือคาดเดาได้
- ใช้คีย์ซ้ำข้ามโปรโตคอลที่มีสมมติฐาน proof-of-possession และโดเมนต่างกัน
- รวม public key ที่ไม่ได้ลงทะเบียนโดยไม่มีการป้องกัน rogue key ตาม scheme
- เรียก fast verification สำหรับข้อความเดียวกับข้อความต่างกันหรือ root ไม่สอดคล้อง
- สลับ ทำซ้ำ หรือตัดความสัมพันธ์ระหว่าง public key กับข้อความ
- เชื่อ participant bitlist โดยไม่ตรวจสมาชิกคณะกรรมการและดัชนีไม่ซ้ำ
- นับลายเซ็นแทน stake น้ำหนัก หรือ threshold ที่โปรโตคอลกำหนด
- สมมติว่า aggregate หนึ่งรายการบอกได้ว่าลายเซ็นรายใดไม่ถูกต้อง
- สับสนระหว่างการรวมทั่วไป multisignatures และ threshold signatures
- ถือความถูกต้องของลายเซ็นเป็นหลักฐาน availability ความถูกต้องของ execution หรือ finality
- มองข้าม equivocation ข้อความที่ลงโทษได้ ช่วงเวลา หรือบริบท fork choice
- พึ่งไลบรารีเดียว คุณสมบัติ CPU หรือ optimization ของ batch verification ที่ไม่ตรวจสอบ
- ประเมินต้นทุน pairing input สำหรับ denial-of-service side channels การเก็บคีย์ upgrades และการไม่มีความปลอดภัยหลังยุคควอนตัมต่ำเกินไป

<a id="misconceptions"></a>

## ความเข้าใจผิดที่พบบ่อย

- ลายเซ็น aggregate พิสูจน์ว่า validator ทุกคนเข้าร่วม
- Public key และลายเซ็น BLS ใดๆ สามารถรวมกันได้อย่างปลอดภัยโดยไม่มีกฎ proof-of-possession
- การรวมขนาดคงที่ทำให้ไม่ต้องส่งหรือสร้างข้อมูลสมาชิกผู้ลงนามใหม่
- การรวม BLS และ threshold BLS เป็น construction เดียวกัน
- ลายเซ็น BLS ที่ถูกต้องทำให้บล็อก ข้อความ bridge หรือโปรโตคอลปลอดภัยทางเศรษฐกิจและ final

<a id="related"></a>

## หัวข้อที่เกี่ยวข้อง

- [แฮชเชิงการเข้ารหัส](/th/crypto/cryptographic-hash/)
- [Proof of stake](/th/crypto/proof-of-stake/)
- [ลายเซ็น threshold](/th/crypto/threshold-signature/)

<a id="sources"></a>

## แหล่งข้อมูล

- [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/th/crypto/bls-signature/index.mdx