ข้ามไปยังเนื้อหา
Financial Context Wiki

ลายเซ็น BLS

คู่มือที่เน้นการตรวจสอบลายเซ็น Boneh-Lynn-Shacham รูปแบบการรวม ciphersuite การป้องกัน rogue key การใช้ในฉันทามติ Ethereum และความเสี่ยงของ implementation

อัปเดต

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

คำตอบโดยตรง

ลายเซ็น 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 คุณสมบัติเหล่านั้นมาจากโปรโตคอลที่อยู่รอบลายเซ็น

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

  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

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

  • การบีบอัดไม่ลบข้อมูลสมาชิก ฉันทามติ 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 และต้องตรวจสมมติฐานด้านความเชื่อถือกับความล้มเหลวแยกต่างหาก

ความเสี่ยง

  • ใช้ 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 และการไม่มีความปลอดภัยหลังยุคควอนตัมต่ำเกินไป

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

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

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

แหล่งข้อมูล

การนำทาง

ค้นหาในวิกิ...