---
title: "ลายเซ็นแบบเกณฑ์"
description: "ลายเซ็นแบบเกณฑ์ช่วยให้องค์ประชุมสร้างลายเซ็นปกติที่ตรวจสอบได้ โดยวัสดุคีย์ส่วนตัวยังคงกระจายอยู่ อธิบาย M-of-N, DKG, การกู้คืน และความเสี่ยงในการปฏิบัติงาน"
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.

# ลายเซ็นแบบเกณฑ์

> จัดทำเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำด้านการลงทุนหรือความปลอดภัย การออกแบบแบบเกณฑ์จะลดความเสี่ยงของคีย์บางประเภทได้ต่อเมื่อโปรโตคอล การติดตั้งใช้งาน ผู้เข้าร่วม และการกู้คืนได้รับการปกป้องอย่างเป็นอิสระ

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

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

ลายเซ็นเกณฑ์จะกระจายความสามารถของคีย์ส่วนตัวให้กับหลายฝ่าย และเมื่อถึงเกณฑ์ ลายเซ็นที่ตรวจสอบได้ทั่วไปจะถูกสร้างขึ้นร่วมกัน บทความนี้จะอธิบาย M-of-N, DKG, MPC กระเป๋าสินทรัพย์ดิจิทัล และความแตกต่างด้วยลายเซ็นหลายลายเซ็น

Threshold Signature ช่วยให้ผู้เข้าร่วม N คนสามารถควบคุมลายเซ็นร่วมกันได้ ตราบใดที่ผู้เข้าร่วม M อย่างน้อยร่วมมือกัน ก็สามารถสร้างลายเซ็นที่ถูกต้องซึ่งมีลักษณะเหมือนกับลายเซ็นทั่วไปได้ โดยทั่วไปแล้วผู้เข้าร่วมที่มีการแชร์เนื้อหาคีย์น้อยกว่า M จะไม่สามารถลงนามได้อย่างอิสระและไม่สามารถกู้คืนคีย์ส่วนตัวทั้งหมดได้

โดยทั่วไปจะใช้ใน MPC กระเป๋าสินทรัพย์ดิจิทัล, การดูแลของสถาบัน, คีย์ตัวตรวจสอบ และโปรโตคอลข้ามเครือข่าย ทั้งลายเซ็นตามเกณฑ์และลายเซ็นหลายรายการบนเครือข่ายสามารถลดความเสี่ยงคีย์ส่วนตัวแบบจุดเดียวได้ แต่เลเยอร์การใช้งาน ประสิทธิภาพแบบ on-chain วิธีการกู้คืน และขอบเขตการตรวจสอบจะแตกต่างกัน

M-of-N คือนิพจน์พื้นฐานของโครงสร้างเกณฑ์:

* N คือจำนวนผู้เข้าร่วมทั้งหมดหรือการแชร์คีย์

* M คือจำนวนขั้นต่ำของ หุ้นที่จำเป็นในการกรอกลายเซ็น

ตัวอย่างเช่น สอง-of-สาม หมายความว่าทั้งสองฝ่ายสามารถลงนามได้หากพวกเขาร่วมมือกัน การรั่วไหลโดยฝ่ายหนึ่งฝ่ายเดียวไม่เพียงพอที่จะโอนสินทรัพย์ และการสูญหายของอุปกรณ์ของฝ่ายหนึ่งจะไม่ทำให้เงินทุนล็อคทันที

ลายเซ็นเกณฑ์มักจะประกอบด้วยสองขั้นตอน:

* การสร้างคีย์หรือการแบ่งส่วน: การสร้างการแบ่งปันคีย์แบบกระจาย

ลายเซ็นแบบเกณฑ์เป็นการประยุกต์ใช้การคำนวณหลายฝ่ายอย่างปลอดภัย (MPC) แต่คำทั้งสองไม่ใช่คำพ้อง กระเป๋า MPC อาจใช้โปรโตคอลนี้ ขณะที่ MPC ยังครอบคลุมการคำนวณอื่นที่ไม่เกี่ยวกับลายเซ็น การแบ่งข้อมูลสำรอง seed ก็ไม่ใช่ลายเซ็นแบบเกณฑ์หากต้องประกอบความลับก่อนใช้

คำรับรองด้านความปลอดภัยขึ้นกับโปรโตคอลที่ใช้ แบบจำลองผู้โจมตี การสื่อสารที่ยืนยันตัวตน การสุ่ม การเก็บส่วนแบ่ง ความเป็นอิสระของผู้เข้าร่วม ห่วงโซ่อุปทานซอฟต์แวร์ กลไกนโยบาย และการกู้คืน M-of-N เพียงอย่างเดียวไม่ใช่การประเมินความปลอดภัย

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

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

M-of-N คือนิพจน์พื้นฐานของโครงสร้างขีดจำกัด:

* N คือจำนวนผู้เข้าร่วมทั้งหมดหรือการแชร์คีย์

* M คือจำนวนการแชร์ขั้นต่ำที่จำเป็นในการทำให้ลายเซ็นเสร็จสมบูรณ์

ลายเซ็นเกณฑ์มักจะประกอบด้วยสองขั้นตอน:

* การสร้างคีย์หรือการแบ่งส่วน: การสร้างการแชร์คีย์แบบกระจาย

* โปรโตคอลลายเซ็น: ผู้เข้าร่วมที่ถึงเกณฑ์แลกเปลี่ยนข้อความเพื่อสร้างลายเซ็นขั้นสุดท้าย

ในท้ายที่สุด เฉพาะคีย์สาธารณะที่เกี่ยวข้องและลายเซ็นมาตรฐานเท่านั้นที่จะเห็นบนเชน และไม่จำเป็นต้องทราบว่ามีกี่ฝ่ายที่เกี่ยวข้องอยู่เบื้องหลัง

การสร้างคีย์แบบกระจาย (DKG) อนุญาตให้ผู้เข้าร่วมร่วมกันสร้างคีย์สาธารณะและการแชร์คีย์ตามลำดับโดยไม่ต้องรวมคีย์ส่วนตัวที่สมบูรณ์ได้ตลอดเวลา

ผู้เข้าร่วมแต่ละรายต้องผูกคำขอที่แน่นอนเข้ากับเชน บัญชี จำนวน ปลายทาง ค่าธรรมเนียม nonce และบริบทนโยบายอย่างอิสระ องค์ประชุมทางการเข้ารหัสไม่ทดแทนการตรวจสอบธุรกรรม

องค์ประชุมที่เลือกแลกเปลี่ยนคำมั่น หลักฐาน และส่วนแบ่งลายเซ็น วัสดุ nonce เฉพาะโปรโตคอลต้องไม่ซ้ำและได้รับการปกป้อง เพราะการใช้ซ้ำหรืออคติอาจเปิดเผยวัสดุคีย์ บางแบบต้องประมวลผลล่วงหน้า ส่วน FROST กำหนดโปรโตคอล Schnorr แบบเกณฑ์สองรอบ

ก่อนเผยแพร่ต้องตรวจผลลัพธ์รวมด้วยคีย์สาธารณะของกลุ่ม จากนั้นผู้ดำเนินงานเก็บบันทึกที่เหมาะสม เฝ้าดูความล้มเหลว รีเฟรชส่วนแบ่งหรือหมุนคีย์ตามพิธีที่กำหนด และทดสอบการกู้คืนโดยไม่ลดเกณฑ์

โปรโตคอลแตกต่างกันตามตระกูลลายเซ็นและแบบจำลองความปลอดภัย ความเป็นเชิงเส้นทำให้โครงสร้าง Schnorr ตรงไปตรงมากว่า ส่วน ECDSA แบบเกณฑ์ต้องใช้เทคนิคหลายฝ่ายเพิ่มเติม การรวมลายเซ็น หลายลายเซ็น และลายเซ็นแบบเกณฑ์อาจดูคล้ายกันแต่มีข้ออ้างด้านการมีส่วนร่วมและความปลอดภัยต่างกัน

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

การทบทวนการปฏิบัติงานแยกเป็นห้าจุด ได้แก่ 1 การตั้งค่า 2 การสร้างคีย์ 3 การอนุมัติ 4 การลงนาม และ 5 การบำรุงรักษา

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

## ตัวอย่าง

สถาบันวางหุ้นสามหุ้นตามลำดับ:

* อุปกรณ์ฮาร์ดแวร์ของทีมการซื้อขาย

* แผนกควบคุมความเสี่ยงอิสระ

* หน่วยงานโฮสติ้งการกู้คืนความเสียหาย

การถอนเงินรายวันจำเป็นต้องมีลายเซ็นร่วมของทีมการซื้อขายและการควบคุมความเสี่ยง เมื่อสำนักงานใหญ่ล้มเหลว ทีมซื้อขายหรือบุคคลที่ได้รับอนุญาตใหม่จะร่วมมือกับฝ่ายกู้คืนระบบ

หากทั้งการซื้อขายและการควบคุมความเสี่ยงแชร์ทำงานในบัญชีคลาวด์เดียวกัน และ 2 ใน 3 กระจายอยู่ในแผนผังองค์กร ยังคงเป็นไปได้ในทางเทคนิคที่จะถูกละเมิดโดยการรั่วไหลของข้อมูลประจำตัวบนคลาวด์ ความเป็นอิสระอย่างแท้จริงจำเป็นต้องแยกอุปกรณ์ ผู้ดูแลระบบ เครือข่าย ภูมิภาค และเส้นทางการอนุมัติ

การทดสอบยืนยันว่า 1 ฝ่ายลงนามไม่ได้ ทุกชุดที่ได้รับอนุญาตซึ่งมี 2 ฝ่ายทำงานได้ และ 2 ส่วนแบ่งแรกไม่ได้ใช้การควบคุมเดียวกัน

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

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

- การฝึกซ้อมการกู้คืนควรครอบคลุมความเสียหายของอุปกรณ์ การสูญเสียบุคลากร การปิดซัพพลายเออร์ ไคลเอ็นต์ออฟไลน์ และความไม่พร้อมใช้งานของเครือข่าย การยืนยันว่ามีไฟล์สำรองข้อมูลอยู่ไม่ได้หมายความว่าสามารถกู้คืนสถานะโปรโตคอลได้
- เมื่อใช้ตัวกู้คืนเอสโครว์ ควรมีความชัดเจนว่าสามารถเปลี่ยนผู้เข้าร่วมได้อย่างอิสระ ชะลอลายเซ็น หรืออ่านความเป็นส่วนตัวของธุรกรรมหรือไม่ การอำนวยความสะดวกในการฟื้นฟูมักจะทำให้เกิดความไว้วางใจเพิ่มเติม
- ลายเซ็น BLS โดยธรรมชาติแล้วสนับสนุนการรวมกลุ่ม และการสร้างเกณฑ์นั้นค่อนข้างใช้งานง่ายและพบได้ทั่วไปในชุดฉันทามติและผู้ตรวจสอบ ECDSA มีการใช้กันอย่างแพร่หลายในหลายๆ เชน แต่โปรโตคอล ECDSA ตามเกณฑ์นั้นซับซ้อนกว่า ซึ่งเกี่ยวข้องกับการคูณเชิงโต้ตอบและการรักษาความปลอดภัย Nonce
- ลายเซ็น Schnorr มีโครงสร้างเชิงเส้นและเหมาะสำหรับ MuSig และโครงร่างขีดจำกัด แต่โปรโตคอลเฉพาะยังคงจำเป็นต้องป้องกันคีย์ที่เป็นอันตรายและการโจมตี Nonce
- เพียงเพราะเส้นโค้งด้านล่างเหมือนกัน ไม่ได้หมายความว่าการใช้งานขีดจำกัดที่แตกต่างกัน ใช้แทนกันได้ ไม่ว่าเชนจะยอมรับรูปแบบลายเซ็นขั้นสุดท้าย หลักฐานความปลอดภัยของโปรโตคอล และการใช้งานไลบรารีทั้งหมดหรือไม่ ให้ตรวจสอบทั้งหมด
- บริดจ์บางตัวได้รับอนุญาตร่วมโดยผู้ลงนาม M-of-N เพื่อทำเหรียญหรือถอนเงิน แม้ว่าจะเห็นเฉพาะลายเซ็นปกติบนเชน แต่ความปลอดภัยจะขึ้นอยู่กับกลุ่มผู้ลงนามนี้
- เมื่อทำการค้นคว้า คุณควรยืนยันว่าใครคือผู้ลงนาม ไม่ว่าจะเป็นผู้ลงนามอิสระอย่างแท้จริงหรือไม่ เกณฑ์สูงเพียงใด สามารถแทนที่คีย์สาธารณะได้หรือไม่ ใครเป็นผู้ควบคุมการหมุนเวียนคีย์ และไม่ว่าเหรียญไม่จำกัดสามารถสร้างได้เมื่อถึงเกณฑ์หรือไม่
- "การใช้ MPC" อธิบายเฉพาะ เทคโนโลยีลายเซ็น ซึ่งไม่ได้หมายความว่าสินทรัพย์ของสะพานถูกจำนองอย่างสมบูรณ์หรือไม่มีประตูหลังด้านการกำกับดูแล
- ชิ้นส่วนสำรองอาจสร้างคีย์ส่วนตัวขึ้นใหม่ในระหว่างการกู้คืน และลายเซ็นตามเกณฑ์มักจะไม่จำเป็นต้องใช้คีย์ส่วนตัวที่สมบูรณ์จึงจะปรากฏ
หากการแชร์ทั้งสามถูกควบคุมโดยบัญชีคลาวด์ ผู้ดูแลระบบ หรือซอฟต์แวร์เดียวกัน การแชร์เหล่านั้นอาจยังคงถูกบุกรุกร่วมกัน

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

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

- **“คีย์ส่วนตัวไม่เคยมีอยู่”** คีย์อาจไม่ถูกประกอบในการใช้งานปกติ แต่การตั้งค่า นำเข้า สำรอง ย้าย หรือกู้คืนฉุกเฉินอาจเปลี่ยนข้ออ้างนี้
- **“2-of-3 ขจัดจุดล้มเหลวเดียวทั้งหมด”** ขจัดเฉพาะความล้มเหลวของส่วนแบ่งและบริการที่เป็นอิสระจริง โครงสร้างพื้นฐานหรือนโยบายร่วมอาจสร้างจุดดังกล่าวขึ้นใหม่
- **“ลายเซ็นเดียวบนเชนพิสูจน์ว่าคนเดียวอนุมัติ”** ผลลัพธ์มักไม่เผยจำนวนผู้เข้าร่วมหรือนโยบายนอกเชนที่อนุญาตพวกเขา
- **“ลายเซ็นแบบเกณฑ์ป้องกันธุรกรรมไม่ดี”** มันบังคับใช้องค์ประชุมทางการเข้ารหัส ไม่ใช่วิจารณญาณ องค์ประชุมที่สมรู้ร่วมคิดหรือถูกหลอกอาจอนุมัติการขโมย
- **“ไลบรารี MPC ใดก็ใช้ได้กับทุกเชน”** รูปแบบ เส้นโค้ง กฎแฮช การอนุพันธ์คีย์ การเข้ารหัส สมมติฐาน และตัวตรวจสอบต้องตรงกัน

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

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

- [กระเป๋า MPC](/th/crypto/mpc-wallet/)
- [กระเป๋าหลายลายเซ็น](/th/crypto/multisig-wallet/)
- [การจัดการคีย์ส่วนตัว](/th/crypto/private-key-management/)
- [ลายเซ็น BLS](/th/crypto/bls-signature/)
- [Nonce](/th/crypto/nonce-crypto/)

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

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

- [NIST First Call for Multi-Party Threshold Schemes](https://csrc.nist.gov/pubs/ir/8214/c/final) - NIST (เข้าถึง: 2026-08-21)
- [Threshold Schemes for Cryptographic Primitives](https://doi.org/10.6028/NIST.IR.8214) - NIST (เข้าถึง: 2026-08-21)
- [RFC 9591: The FROST Protocol](https://www.rfc-editor.org/rfc/rfc9591.html) - IETF (เข้าถึง: 2026-08-21)
- [Digital Signature Standard (DSS)](https://doi.org/10.6028/NIST.FIPS.186-5) - NIST (เข้าถึง: 2026-08-21)
- [Fast Multiparty Threshold ECDSA with Fast Trustless Setup](https://doi.org/10.1145/3243734.3243859) - ACM (เข้าถึง: 2026-08-21)

Source: https://wiki.fcontext.com/th/crypto/threshold-signature/index.mdx