โปรโตคอลการเข้ารหัส
Commit / Reveal
สำหรับ Round (รอบ) t ผู้ใช้ i ที่มี secret ส่วนตัว s_i ∈ {0,1}^128 จะเลือกคำตอบ b_i ∈ {0,1} และเผยแพร่:
โดยที่ ‖ หมายถึงการต่อข้อมูล และ round_t คือตัวระบุ Round ที่ไม่ซ้ำกันและเปิดเผยต่อสาธารณะ
ในช่วง Reveal ผู้ใช้ i จะส่ง (s_i, b_i) แบบกระจายเสียง Round Engine และผู้ตรวจสอบบุคคลที่สามจะคำนวณ HMAC-SHA256(s_i ‖ round_t, b_i) และตรวจสอบว่าตรงกับ c_i ที่เผยแพร่ไว้ก่อนหน้านี้ การเปิดเผยที่ไม่ตรงกันจะถูกปฏิเสธ ผู้ที่ไม่เปิดเผยจะถูกคัดออกจาก Round แต่ Commit ของพวกเขาจะยังคงอยู่ใน Merkle Root เพื่อการตรวจสอบ
เหตุใดจึงใช้ HMAC แทนการแฮชแบบธรรมดา
Commit แบบธรรมดา H(s_i ‖ b_i) มีความเสี่ยงต่อการโจมตีสองรูปแบบ:
- Rainbow precomputation. หาก
s_iสั้น (UX บนมือถือจำกัดให้เราใช้ความสุ่มที่ผูกกับอุปกรณ์ไม่เกิน 16 ไบต์) ตารางที่คำนวณล่วงหน้าของH(s ‖ 0)และH(s ‖ 1)ทั่วพื้นที่ secret สามารถถอดรหัส Commit ก่อนการเปิดเผยได้ - Cross-Round replay. หากไม่มีการผูกกับ Round Commit ที่ใช้ได้ใน Round
tอาจถูกนำกลับมาใช้เป็นหลักฐานใน Roundt' ≠ t
HMAC ที่มีขนาดคีย์ที่เหมาะสม (ที่นี่ 128 บิต) และการผูกกับ Round (การต่อ round_t เข้าไปในข้อความที่มีคีย์) ช่วยขจัดปัญหาทั้งสองนี้ การสร้าง HMAC ที่มีความเทียมสุ่มภายใต้สมมติฐานมาตรฐานช่วยให้มั่นใจได้ว่าหากไม่มี s_i ความได้เปรียบของฝ่ายตรงข้ามในการแยกแยะ b_i = 0 จาก b_i = 1 นั้นน้อยมากจนไม่สามารถวัดได้
s_i มาจากไหน
อุปกรณ์ของผู้ใช้แต่ละรายจะสร้าง s_i เมื่อเข้า Round ผ่าน crypto.getRandomValues(new Uint8Array(16)) ของเบราว์เซอร์ โดยจะถูกเก็บไว้ใน session storage ของ WebApp เฉพาะในช่วง Round เท่านั้น หลังจาก Reveal จะถูกลบออก ไม่มี secret ที่ผู้ใช้พิมพ์เองเข้ามาเกี่ยวข้อง
สำหรับผู้ใช้ที่ล้าง session ระหว่าง Round จะถือว่าสละสิทธิ์ใน Round นั้น (ไม่สามารถเปิดเผย Commit ที่ไม่มีคีย์อีกต่อไป) คะแนน Reputation Score จะได้รับการอัปเดตเป็นลบเล็กน้อย
Merkle Root ของ Round
ในช่วง Settle Engine จะคำนวณ:
root จะถูกจัดคิวเพื่อการชำระบัญชีแบบกลุ่มไปยัง TON ทุก 24 ชั่วโมง ธุรกรรมเดียวบน TON สามารถ Commit root ของ Round ได้ประมาณ 5,760 รายการ (หนึ่งรายการต่อ 60 วินาที × 86,400 / 60 / 15 การตัดจำหน่าย)
ผู้เข้าร่วมคนใดก็ได้สามารถดึง Merkle proof จาก Engine และตรวจสอบการรวมของตนกับ root ที่อยู่บนเชน โดยไม่ต้องเชื่อถือ Engine
ช่วงเวลาโต้แย้ง
ช่วงเวลาโต้แย้ง 24 ชั่วโมงช่วยให้สามารถท้าทายบนเชนได้: ผู้ใช้ส่ง Merkle proof ที่แสดงว่า root บนเชนไม่ตรงกับข้อเรียกร้องของ Engine นอกเชน หากการท้าทายสำเร็จ Round จะถูกเพิกถอนและชำระบัญชีใหม่ ผู้ดำเนินการจะจ่ายค่าปรับ 1,000 $POP (โทเค็น) เข้า Treasury (คลัง) root ที่ไม่ถูกท้าทายจะกลายเป็นที่สิ้นสุด
Reputation Score (คะแนนชื่อเสียง)
r_i ∈ [0, 1] คือค่าประมาณแบบเบย์ของความซื่อสัตย์ของผู้ใช้ ซึ่งอัปเดตทุก Round:
โดยที่ λ(o_i^{(t)}) คือฟังก์ชันความน่าจะเป็นเหนือการสังเกต (การเข้าร่วม การเปิดเผยตรงเวลา การเบี่ยงเบนจากความน่าจะเป็นของส่วนน้อย เครื่องหมายความผิดปกติ) ค่าเริ่มต้น r_i = 0.5 (prior ที่ไม่มีข้อมูล)
Reputation Score จะลดลงเมื่อไม่มีการใช้งานในอัตรา δ = 0.01 / วัน Reputation Score ต้องไม่เกิน 0.99 (ความถ่อมตนเชิงญาณวิทยา) หรือต่ำกว่า 0.01 (อนุญาตให้ฟื้นตัวได้)
Reputation Score จะคูณกับตัวคูณของ Trust Ladder (บันไดความไว้วางใจ) ในการชำระบัญชี:
ข้อโต้แย้งด้านความปลอดภัยอย่างเป็นทางการ
ภายใต้สมมติฐานว่า HMAC-SHA256 เป็นฟังก์ชันเทียมสุ่ม (PRF) และ s_i เป็นแบบสุ่มสม่ำเสมอและไม่เป็นที่รู้จักของฝ่ายตรงข้าม ไม่มีฝ่ายตรงข้ามที่มีประสิทธิภาพใดสามารถ:
- แยกแยะ Commit
c_i = HMAC(s_i ‖ round_t, b_i)สำหรับb_i = 0เทียบกับb_i = 1ด้วยความได้เปรียบที่ไม่น้อยเลย (การซ่อน) - ค้นหา
(s'_i, b'_i)≠(s_i, b_i)ที่ทำให้HMAC(s'_i ‖ round_t, b'_i) = c_i(การผูกมัด ภายใต้การต้านทานการชนกันของ HMAC) - ทำนาย seed ของ Round ถัดไปโดยไม่สมคบคิดกับทั้งชุดผู้ตรวจสอบ DRAND และ TON-VRF (ดู Oracle & Randomness)
นี่คือคุณสมบัติสามประการที่จำเป็นสำหรับเกมการประสานงาน Commit / Reveal ที่ยุติธรรม โปรโตคอลไม่ต้องการสมมติฐานการเข้ารหัสเพิ่มเติมใด ๆ
การตรวจสอบและโอเพนซอร์ส
Round Engine และตรรกะการตรวจสอบเป็นโอเพนซอร์สภายใต้สัญญาอนุญาต MIT ที่เก็บอยู่ที่ github.com/cashpop-protocol/round-engine การตรวจสอบอย่างสมบูรณ์โดย Trail of Bits มีเป้าหมายใน Phase 2 (Q4 2026)