DeepBook Predict: EP 2 กลไกการทำงาน
Understanding How DeepBook Predict Works Under the Hood
กลับมาต่อ EP 2 แล้วครับ ใครยังไม่ได้อ่าน EP 1 แวะไปอ่านก่อนเลยนะ เพราะ EP นี้จะต่อยอดจากตรงนั้นโดยตรง
ใน EP ที่แล้วเราคุยกันถึงภาพรวมว่า DeepBook Predict คืออะไร และต่างจาก prediction market แบบเดิมยังไง EP นี้เราจะเปิดฝาดูข้างในกันว่า protocol นี้ทำงานยังไง แต่ละ component มีหน้าที่อะไร และ flow หลักของระบบถูกออกแบบมาอย่างไร
EP นี้ยังไม่มีโค้ดนะครับ แต่จะ technical กว่า EP ก่อนหน่อย เพราะเราจะลงไปดู architecture และ mechanism ภายใน เพื่อเตรียมพื้นฐานก่อนเข้าสู่ EP ถัดไปที่เราจะเริ่มทดลอง build บน Testnet กันจริงๆ
หมายเหตุ: DeepBook Predict ที่อ้างอิงในบทความนี้ยังอยู่บน Sui Testnet และอ้างอิงจาก branch
predict-testnet-4-16ดังนั้น package ID, object layout, public server, และ entry point ต่างๆ อาจเปลี่ยนได้ก่อน Mainnet launch นะ
4 ตัวหลักที่ต้องรู้จัก
DeepBook Predict ประกอบด้วย 4 component หลักที่ทำงานร่วมกัน ได้แก่ Predict, PredictManager, OracleSVI, และ Vault
ก่อนจะลงรายละเอียดแต่ละตัว ขอให้เห็นภาพรวมก่อนว่าแต่ละ component ทำหน้าที่อะไร
Predict คือตัวกลางหลักของ protocol ทุก action สำคัญของ user ไม่ว่าจะ mint position, redeem position, supply liquidity หรือ withdraw liquidity จะต้องผ่าน object นี้
PredictManager คือ account object ประจำ user แต่ละคน ใช้สำหรับเก็บ quote balance และ position ของ user ไว้ในที่เดียว โดยข้างในจะ wrap ระบบ BalanceManager ของ DeepBook เอาไว้อีกชั้นหนึ่ง
OracleSVI คือ market state ของแต่ละ underlying asset และ expiry เช่น BTC market ที่หมดอายุสิ้นปี 2025 ก็จะมี oracle ของตัวเอง oracle นี้เก็บทั้ง spot price, forward price, SVI parameters, lifecycle status และ settlement price
Vault คือคลัง liquidity กลางของ protocol ทำหน้าที่เป็นทั้ง counterparty ของทุก trade และเป็น pool ที่ LP ฝาก quote asset เข้ามาเพื่อรับ PLP share
ถ้าอธิบายแบบ flow ง่ายๆ ทุก action จะเริ่มที่ Predict จากนั้น Predict จะอ่าน market state จาก OracleSVI, จัดการ balance และ position ผ่าน PredictManager ของ user และบันทึก exposure รวมของ protocol ไว้ใน Vault
PredictManager
ก่อนใช้งาน DeepBook Predict ได้ user ต้องมี PredictManager ของตัวเองก่อน คิดง่าย ๆ เหมือนเปิดบัญชีหนึ่งครั้ง แล้วใช้ซ้ำได้กับทุกตลาด ไม่ต้องสร้างใหม่ทุกครั้ง
ข้างใน PredictManager เก็บสองอย่าง คือ เงิน (ผ่านระบบ BalanceManager ตัวเดียวกับที่ DeepBook Spot ใช้) และ Position ทั้งหมดที่ user เปิดอยู่
จุดที่น่าสนใจคือ position ใน DeepBook Predict ไม่ได้เป็น token หรือ object แยกใน wallet เหมือน prediction market บางเจ้าที่ใช้ YES/NO token แทน position แต่เก็บเป็นแค่ "ตัวเลข" อยู่ภายใน PredictManager แทน
เหตุผลคือ model ของ Sui เอง — ทุก object มี storage cost ถ้า position แต่ละอันเป็น object แยก มีหลาย position ก็ยิ่งเปลืองค่าเก็บข้อมูล แต่พอเก็บรวมไว้ใน manager เดียว ต่อให้ user เล่นหลายตลาดก็จัดการง่ายกว่า แอปอ่าน portfolio จาก object เดียวจบ ไม่ต้องไล่หา position ทีละตัว
Position
DeepBook Predict รองรับ position หลักๆ 2 รูปแบบ คือ Binary Position และ Vertical Range
Binary Position
Binary Position คือการทาย direction ของราคาจาก strike ที่กำหนด เช่น BTC จะสูงกว่า 100,000 ดอลลาร์ไหมตอน settlement ถ้า user เลือกฝั่ง “up” แล้ว settlement price สูงกว่า strike position นั้นก็ชนะและได้ payout ตามกติกา แต่ถ้า settlement price ไม่สูงกว่า strike position นั้นก็ไม่ได้ payout ในเชิง key ของระบบ binary position จะถูกระบุด้วยข้อมูลหลักๆ คือ oracle, expiry, strike และ direction ว่าเป็น up หรือ down
Vertical Range
Vertical Range คือการทายว่าราคาจะอยู่ในช่วงที่กำหนดไว้ เช่น BTC จะอยู่ระหว่าง 90,000-110,000 ดอลลาร์ไหมตอน settlement รูปแบบนี้เหมาะกับ strategy ที่ไม่ได้ต้องการแค่ทายขึ้นหรือลง แต่ต้องการทายว่า settlement price จะอยู่ในกรอบราคาหนึ่ง ในเชิง implementation payout band ของ vertical range ถูกนิยามเป็นช่วง (lower, higher] หรือพูดง่ายๆ คือ settlement price ต้องมากกว่า lower strike และน้อยกว่าหรือเท่ากับ higher strike
สิ่งที่ทั้ง Binary Position และ Vertical Range เหมือนกันคือ ทุก position จะอิงกับ oracle, expiry และ strike หรือ range ที่ชัดเจน เพื่อให้ protocol สามารถ track exposure และคำนวณ payout ได้อย่าง deterministic
Trade Flow — ตั้งแต่ Mint ถึง Redeem
ส่วนนี้คือหัวใจของ EP นี้ครับ เรามาดูกันว่าเวลาผู้ใช้ mint position หรือ redeem position ระบบทำงานอย่างไรบ้าง
ตอน Mint หรือเปิด Position
เมื่อ user ต้องการ mint binary position หรือ vertical range ระบบจะเริ่มจากการ validate ก่อน ตัวอย่างสิ่งที่ต้องตรวจ เช่น quote asset ที่ใช้จ่ายเป็น asset ที่ protocol รองรับไหม, oracle ยังอยู่ในสถานะที่ trade ได้ไหม, trading ถูก pause อยู่หรือเปล่า, market key หรือ range key ตรงกับ oracle หรือไม่ และ manager owner เป็น signer จริงไหม
หลังจาก validate ผ่านแล้ว design ที่น่าสนใจคือ protocol จะ insert liability เข้า vault ก่อน pricing trade ตรงนี้สำคัญมากครับ เพราะถ้าคิดราคาก่อนแล้วค่อยบันทึก liability ราคาที่ user เห็นจะสะท้อน state ก่อนที่ order ของตัวเองจะกระทบ vault แต่ในความเป็นจริง การ mint position ของ user ทำให้ vault มี exposure เพิ่มขึ้นทันที ดังนั้นการบันทึก liability ก่อน แล้วค่อยคำนวณราคาจาก post-trade state ทำให้ user จ่ายราคาที่สะท้อน risk หลังจาก trade ของตัวเองถูกเพิ่มเข้าไปแล้ว
พูดง่ายๆ คือ user ไม่ได้จ่ายราคาจาก state เดิม แต่จ่ายราคาที่รวม impact จาก trade ของตัวเองเข้าไปด้วย ซึ่งเป็น design ที่ช่วยให้ pricing fair กับ vault และ LP มากขึ้น หลังจากนั้น Predict จะ collect payment จาก PredictManager ของ user, ตรวจว่า exposure รวมของ vault ยังไม่เกิน risk limit ที่กำหนดไว้ และค่อยเพิ่ม position quantity ให้ user ใน PredictManager
และสุดท้าย protocol จะ emit event ออกมา เพื่อให้ frontend, indexer หรือ analytics system สามารถ track activity ได้
ตอน Redeem หรือปิด Position
การ redeem position มี logic ที่ขึ้นอยู่กับสถานะของ oracle ถ้า oracle ยัง active อยู่ user สามารถ redeem position ได้ตาม quote ปัจจุบัน แต่ราคาที่ได้จะเป็นราคาฝั่ง bid ซึ่งปกติจะต่ำกว่าราคาฝั่ง ask ที่ใช้ตอน mint เพราะมี spread และ utilization adjustment ตาม risk ของ vault แต่ถ้า oracle settled แล้ว payout จะ deterministic มากขึ้น เพราะผลลัพธ์ของ market ถูก freeze แล้ว position ที่ชนะจะได้ payout ตาม outcome ส่วน position ที่แพ้ก็จะไม่ได้ payout
อีก feature ที่น่าสนใจคือ permissionless redeem
หลัง oracle settled แล้ว คนอื่นสามารถช่วย redeem settled position แทน owner ได้ แต่ payout จะถูกส่งกลับเข้า PredictManager ของ owner เสมอ ไม่ได้ตกไปอยู่กับคนที่กด redeem เหตุผลของ design นี้คือ protocol ต้องการให้มีคนช่วย sweep settled position ออกจาก vault เพื่อช่วยลด state ที่ไม่จำเป็น และช่วยคืน capital ให้ LP ได้เร็วขึ้นในภาพรวม
Oracle
Oracle ใน DeepBook Predict ไม่ได้เป็นแค่ price feed ธรรมดา แต่เป็น market state ของแต่ละ underlying asset และ expiry เช่น BTC expiry สิ้นปี 2025 ก็จะมี OracleSVI ของตัวเอง
OracleSVI เก็บข้อมูลสำคัญ เช่น spot price, forward price, SVI parameters, activation status, timestamp และ settlement price โดย SVI parameters จะช่วย represent volatility surface ของ market ทำให้ protocol สามารถ derive fair price ของ position หลาย strike ได้จาก oracle state โดยไม่ต้องรอ market maker มา quote ทีละ strike
ซึ่งการ design แบบนี้จะช่วยลด cold start problem ของ prediction market แบบ orderbook-based เพราะ protocol สามารถสร้างราคาเริ่มต้นให้หลาย strike ได้จาก oracle-driven model
OracleSVI มี lifecycle หลักๆ 4 สถานะ
Inactive คือสถานะหลัง oracle ถูกสร้าง แต่ยังไม่ activate จึงยัง mint position ไม่ได้
Active คือสถานะที่ market เปิดใช้งานแล้ว oracle สามารถรับ live spot, forward และ SVI update ได้ และ user สามารถ mint หรือ redeem position ได้ตามเงื่อนไขของ protocol
Pending Settlement คือสถานะหลัง expiry ผ่านไปแล้ว แต่ยังไม่ได้รับ price update หลัง expiry จึงไม่เปิดให้ mint position ใหม่ แต่ position เดิมยังรอ settlement price
Settled คือสถานะหลังได้รับ price update แรกหลัง expiry ระบบจะ freeze settlement price และ position ทั้งหมดสามารถ redeem ได้ตาม outcome ที่ deterministic แล้ว
Vault (Liquidity ของระบบ)
Vault ทำหน้าที่ 2 อย่างพร้อมกัน คือเป็น counterparty ของทุก trade และเป็น pool สำหรับ LP
Counterparty
ใน DeepBook Predict vault จะไม่มีการ match user กับ user โดยตรงแบบ orderbook ที่ต้องรออีกฝั่งหนึ่งมารับ order แต่ทุก mint คือ user ซื้อ position จาก vault และทุก redeem คือ user ขาย position คืนให้ vault ดังนั้น risk ทั้งหมดจาก position ที่เปิดอยู่จะถูกสะสมและ track อยู่ใน vault
LP Pool
ผู้ให้สภาพคล่องฝากเหรียญเข้า Vault แล้วได้ PLP (Predict Liquidity Provider) กลับมาเป็นส่วนแบ่ง โดย PLP ไม่ใช่ส่วนแบ่งของตลาดใดตลาดหนึ่ง แต่เป็นสิทธิ์ตามสัดส่วนในมูลค่ารวมของ Vault ทั้งก้อน
มูลค่า Vault = เงินที่มีอยู่ ลบด้วยภาระที่ต้องจ่ายให้ position ที่ยังค้างอยู่ (mark-to-market) ถ้า Vault กำลังแบกความเสี่ยงสูง มูลค่าก็ลด กระทบส่วนแบ่งของ LP ที่เข้า/ออก pool ตอนนั้น
และการถอนเงินก็ไม่ได้ทำได้ตามใจเสมอ ระบบต้องเช็กว่าถอนแล้ว Vault ยังมีเงินพอจ่าย position ที่อาจชนะหรือเปล่า หรือพูดง่าย ๆ คือ LP ถอนจน Vault ไม่พอจ่ายไม่ได้นั้นเอง
Storage และ Strike Matrix
อีกดีไซน์ที่น่าสนใจคือวิธีที่ Vault จัดการความเสี่ยงของแต่ละ oracle
ตอน oracle ยัง active อยู่ Vault ต้องเกาะติดความเสี่ยงของทุกเส้น strike (เช่น BTC 90k, 95k, 100k...) ยิ่งมีหลายเส้นและคนเล่นเยอะ ข้อมูลที่ต้องเก็บก็ยิ่งละเอียด
แต่พอ oracle settled แล้ว ผลของทุกเส้นกลายเป็นค่าตายตัว Vault ไม่ต้องเก็บตารางความเสี่ยงละเอียดเหมือนเดิม ระบบจึงยุบข้อมูลให้เล็กลงได้ ช่วยประหยัด storage และทำให้ Vault รองรับหลาย oracle ได้ดีขึ้น
Pricing และ Risk Management
เพราะ Vault เป็นคู่สัญญาของทุกๆโพล ระบบจึงต้องมีการคุมความเสี่ยงหลายชั้น ไม่ให้ Vault เสี่ยงเกินไป
Fair Price + Spread + Utilization — ราคาไม่ได้มาจากราคายุติธรรมอย่างเดียว แต่บวก spread และปรับตามการใช้งานของ Vault ด้วย ยิ่ง Vault แบกความเสี่ยงด้านใดด้านหนึ่งมาก ราคาฝั่งนั้นยิ่งแพง ทำหน้าที่เป็นตัวเบรกไม่ให้คนแห่เปิดฝั่งเดียวกันจน Vault เสียสมดุล
Ask Bounds — ระบบตั้งกรอบราคาขายได้ทั้งระดับรวมและรายตลาด กันไม่ให้เปิด position ที่ราคาหลังรวม spread แล้วหลุดกรอบ
Exposure Limit — ทุกครั้งที่เปิด position ระบบเช็กว่าความเสี่ยงรวมยังอยู่ในเพดานเทียบกับเงินใน Vault ถ้าเกินก็เปิดเพิ่มไม่ได้จนกว่าความเสี่ยงจะลด (เช่น มีคนปิด position หรือเงินใน Vault เพิ่ม)
Withdrawal Limiter — ฝั่ง LP ก็มีลิมิตตอนถอน ต้องเหลือเงินพอจ่าย position ที่ค้างอยู่และผ่านเพดานการถอนที่ตั้งไว้
Kill Switch — กรณีฉุกเฉิน เช่น oracle มีปัญหา ราคาเพี้ยน หรือเจอบั๊ก แอดมินสั่งหยุดเทรดได้ เพื่อกันความเสียหายลุกลาม
สรุป
ทั้งหมดนี้คือภาพรวมของ DeepBook Predict ในระดับ architecture ถ้าสรุปให้จำง่ายๆ:
Predict คือ top-level shared object ที่ทุก action หลักต้องผ่าน
PredictManager คือ account object ของ user ที่เก็บ balance และ position quantity
OracleSVI คือ market state ของ asset + expiry พร้อม lifecycle ตั้งแต่ inactive ถึง settled
Vault คือ liquidity pool และ counterparty ของทุก trade
PLP คือ share ของ LP ที่อิงกับ vault value ทั้งระบบ
Risk management ถูกออกแบบผ่าน pricing, utilization, ask bounds, exposure limit, withdrawal limiter และ kill switch
แต่ตอนทำจริงคงไม่ได้จำทั้งหมดลอง อ่านเอาพอเป็น concept แล้วกัน ให้พอเข้าใจภาพคร่าวๆในการทำงาน เดียวถึงเวลาเขียน Code ค่อยลองจับทางกันไปเรื่อยๆนะ
EP หน้าจะเริ่มลงมือกับ Testnet จริงๆละ แต่จะไม่ได้เขียนเป็นบทความเร็วๆนี้แน่นอน เพราะจะเก็บเอาไปคุยกันในงาน Event ที่จะมีวันที่ 6 June นี้ เเล้วเจอกันนะ มางมไปด้วยกัน
Reference
