Oracle & Randomness

CashPop เลือกคำถามของแต่ละ Round (รอบ) จากคลังคำถามที่เตรียมไว้ล่วงหน้ามากกว่า 100,000 คำถาม การเลือกต้องเป็นไปตามเงื่อนไขดังนี้:

1. คาดเดาไม่ได้ ก่อนที่ Round จะเริ่มต้น (เพื่อไม่ให้บุคคลภายในสามารถประสานงานล่วงหน้าเพื่อเลือกคำตอบที่ต้องการได้)
2. ตรวจสอบได้ หลังจาก Round สิ้นสุดลง (เพื่อให้บุคคลที่สามสามารถตรวจสอบการเลือกซ้ำได้)
3. ทนทานต่อการบิดเบือน จากการถูกโจมตี Oracle ใด ๆ เพียงตัวเดียว

การสร้าง Seed

Seed ของคำถามสำหรับ Round t คือ:

$${\sigma }_t=H({\sigma }_{t-1}\parallel r_t^{\text{DRAND}}\parallel r_t^{\text{TON-VRF}})$$

โดยที่:

• σ_{t-1} คือ Seed ของ Round ก่อนหน้า (เพื่อสร้างการเชื่อมโยงเชิงสาเหตุ)
• r^{DRAND}_t คือเอาต์พุต Beacon ล่าสุดจากเครือข่าย Randomness สาธารณะ DRAND (League of Entropy: Cloudflare, Protocol Labs, EPFL และอื่น ๆ)
• r^{TON-VRF}_t คือเอาต์พุต VRF ดั้งเดิมของ TON จากชุด Validator ที่ไม่ต้องขออนุญาต

Seed จะเลือกคำถามผ่านทาง:

$$q_t=\mathcal{Q}[{\sigma }_t\mathrm{mod}|\mathcal{Q}|]$$

เหตุใดจึงใช้ DRAND + TON-VRF แบบ Hybrid

แหล่ง Randomness เดียวมีจุดที่ถูกโจมตีเพียงจุดเดียว การรวมสองแหล่งที่ บริหารจัดการโดยอิสระ เข้าด้วยกันผ่านการต่อข้อมูลและการแฮช:

• ผู้ไม่หวังดีที่ควบคุมเฉพาะ DRAND เพียงอย่างเดียวไม่สามารถทำให้ Seed เอนเอียงได้
• ผู้ไม่หวังดีที่ควบคุมเฉพาะ TON-VRF เพียงอย่างเดียวไม่สามารถทำให้ Seed เอนเอียงได้
• ผู้ไม่หวังดีจะต้องควบคุม ทั้งสองระบบพร้อมกัน ตลอดระยะเวลาของ Beacon ในหนึ่ง Round (ซึ่งมีความน่าจะเป็นต่ำมากสำหรับระบบที่รักษาความปลอดภัยด้วย Threshold สองระบบที่เป็นอิสระต่อกัน)

DRAND ใช้ BLS Threshold Signature จาก Validator สาธารณะมากกว่า 10 รายที่มีการหมุนเวียน drand-keys TON-VRF ใช้ Threshold Signature จากชุด Validator ที่ได้รับการเลือกตั้งของ TON ทั้งสองระบบไม่มีผู้ปฏิบัติงาน โครงสร้างพื้นฐาน หรือห่วงโซ่อุปทานซอฟต์แวร์ร่วมกัน

รายละเอียด DRAND Beacon

• ความถี่ของ Beacon: ทุก 3 วินาที (League of Entropy mainnet)
• ขนาด Beacon: 32 ไบต์
• การตรวจสอบ: ลายเซ็น BLS12-381, คีย์สาธารณะถูกเผยแพร่; ทุกคนสามารถตรวจสอบ Beacon แบบออฟไลน์ได้
• Lookback: CashPop ใช้ Beacon ล่าสุดที่มี Timestamp ≥ เวลาเริ่มต้นของ Round

รายละเอียด TON-VRF

• การนำไปใช้: ได้มาจากลายเซ็น BLS ของ Validator บน Hash เวลาเริ่มต้นของ Round
• การตรวจสอบ: ลายเซ็น BLS เทียบกับการหมุนเวียนคีย์สาธารณะของ Validator ที่เผยแพร่
• Lookback: เอาต์พุต VRF ที่สอดคล้องกับบล็อก Master-Chain ณ เวลาเริ่มต้นของ Round

ท่อส่งการสร้างคลังคำถาม

LLM ensemble {L1, L2, L3, ...} สร้างคำถามที่เป็นไปได้
              ↓
การลดอคติเชิงปฏิปักษ์ (Adversarial debiasing) (การลบการชี้นำทางภาษา)
              ↓
การทดสอบสอบเทียบล่วงหน้า (Calibration pretest) (ตัวจำลองประชากรสังเคราะห์ประมาณการกระจายการตอบสนอง ρ̂)
              ↓
กรอง: |ρ̂ - 0.5| > τ → ทิ้ง
              ↓
การตรวจสอบคุณภาพโดยมนุษย์ (Human-in-loop quality review) (สุ่มตัวอย่าง 1% ของคำถามที่เป็นไปได้)
              ↓
แฮชและผูกมัดกับ Merkle Tree ของคลังคำถาม
              ↓
เผยแพร่ชุดคลังคำถามบนเชน (ผูกมัดรายเดือน)

การเผยแพร่คลังคำถามรายเดือนหมายความว่ากลุ่มคำถาม สามารถตรวจสอบได้โดยสาธารณะ: ทุกคนสามารถตรวจสอบได้ว่าคำถาม q_t ที่ถูกเลือกในวันที่ d นั้นเป็นส่วนหนึ่งของคลังคำถามที่ถูกผูกมัดก่อนวันที่ d จริงหรือไม่

เหตุใดจึงต้องลดอคติเชิงปฏิปักษ์

คำถามที่สร้างขึ้นโดยทั่วไปมักมีรูปแบบการชี้นำจากข้อมูลการฝึกของ LLM เช่น สมมติฐานทางวัฒนธรรมตะวันตก ภาษาที่จำแนกตามเพศ การอ้างอิงอายุโดยนัย เราจะเขียนคำถามที่เป็นไปได้ใหม่เพื่อลบการชี้นำดังกล่าว (เทคนิคจาก Bolukbasi et al., 2016; Caliskan et al., 2017) เป้าหมายคือคำถามที่การกระจายการตอบสนองขึ้นอยู่กับประชากรที่ถูกสำรวจ ไม่ใช่วิธีการตั้งคำถาม

เหตุใดจึงต้องทดสอบสอบเทียบล่วงหน้า

เกม Beauty Contest (การประกวดความงาม) จะให้ข้อมูลมากที่สุดเมื่อความไม่แน่นอนเชิงกลยุทธ์สูงที่สุด นั่นคือ เมื่อการตอบสนองที่คาดหวังของประชากรใกล้เคียงกับ 50/50 มากที่สุด เราจะทิ้งคำถามที่มีเอนโทรปีต่ำ (ซึ่งประชากรส่วนใหญ่จะเลือกทางใดทางหนึ่งอย่างชัดเจน) เพราะจะทำให้เกมง่ายเกินไป ค่า Threshold τ อยู่ในช่วง [0.05, 0.15] ขึ้นอยู่กับโหมดเกม

โหมดความล้มเหลวและการลดประสิทธิภาพอย่างค่อยเป็นค่อยไป

ความล้มเหลว	การตรวจจับ	การตอบสนอง
DRAND beacon หมดเวลา	การตรวจสอบสถานะ DRAND (ทุก 30 วินาที)	หยุด Rounds, แจ้งเตือนทีมปฏิบัติการ
TON-VRF validator หมดเวลา	การตรวจสอบ Masterchain ของ TON	หยุด Rounds, แจ้งเตือนทีมปฏิบัติการ
คลังคำถามไม่ตรงกัน	Merkle root ไม่ตรงกัน	หยุด Round; ซิงค์ใหม่ด้วยตนเองจากพื้นที่จัดเก็บตามรูปแบบบัญญัติ
ท่อส่ง LLM ถูกปนเปื้อน	การตรวจจับความผิดปกติทางสถิติในการกระจายการสอบเทียบ	กักกันชุดข้อมูล; ตรวจสอบโดยมนุษย์

ระบบ จะหยุดทำงานอย่างปลอดภัย: ในกรณีที่ Oracle ใด ๆ ล้มเหลว Rounds จะหยุด ไม่มีการชำระบัญชี และไม่มีการจ่ายรางวัล เงินที่ถูกฝากไว้สามารถคืนให้ผู้ใช้ได้โดยการลงคะแนนผ่าน Multisig ฉุกเฉิน

รายการตรวจสอบความสามารถในการตรวจสอบสำหรับผู้ที่สงสัย

ผู้ตรวจสอบภายนอกสามารถดำเนินการดังต่อไปนี้ได้ตลอดเวลา:

1. ดึงประวัติ Seed บนเชน
2. ดึง Merkle Root ของคลังคำถามที่เผยแพร่สำหรับเดือนนั้น
3. ดึงเอาต์พุต DRAND beacon และ TON-VRF ที่สอดคล้องกับ Timestamp ของ Round นั้น
4. คำนวณใหม่ σ_t = H(σ_{t-1} ‖ DRAND ‖ TON-VRF) และตรวจสอบว่าตรงกับ Commit บนเชน
5. คำนวณใหม่ q_t = Reservoir[σ_t mod |Q|] และตรวจสอบว่าตรงกับคำถามที่ส่งมอบ

หากขั้นตอนใดล้มเหลว Round นั้นจะเป็นโมฆะและจะมีการยื่นข้อพิพาท