Vitalik: ยกตัวอย่างระบบ RAI เพื่อสำรวจความเป็นไปได้ของการร่วมเดิมพันเครื่องจักร oracle
ผู้เขียนต้นฉบับ:Vitalik Buterin
รวบรวมข้อความต้นฉบับ: The Way of DeFi
ผู้เขียนต้นฉบับ:
รวบรวมข้อความต้นฉบับ: The Way of DeFi
หนึ่งในความท้าทายหลักสำหรับ RAI คือการยากที่จะหาผู้ถือ ETH ที่เต็มใจทำหน้าที่เป็น LP โดยเฉพาะอย่างยิ่งเมื่ออัตราดอกเบี้ยสูงกว่าระดับปัจจุบันประมาณ -5% ถึง -10% เหตุผลหลักที่อยู่เบื้องหลังปัญหานี้คือ ปัจจุบัน RAI CDPs แข่งขันกับการเดิมพันเพื่อเป็นแหล่งผลตอบแทน
บางคนกำลังสำรวจ RAI แบบหลายหลักประกันเพื่อแก้ปัญหานี้ ความเห็นส่วนตัวของฉันในเรื่องนี้คือ DAI ได้เติมเต็มตลาดเฉพาะกลุ่มแล้วในฐานะ Stablecoin อัลกอริทึมหลายหลักประกันโดยพลการ (รวมถึง "สินทรัพย์ในโลกแห่งความจริง") ดังนั้นจึงไม่มีเหตุผลที่ระบบนิเวศ RAI จะแข่งขันในพื้นที่นี้ ดังนั้น ในความคิดของฉัน การทำให้ RAI (หรือการฟอร์ก) หลายหลักประกันเหมาะสมก็ต่อเมื่อโดย "หลายหลักประกัน" คุณหมายถึงรูปแบบหลายหลักประกันที่แคบมาก (ETH และ ETH ที่จำนำ)
บทความนี้จะอธิบายวิธีต่างๆ สองสามวิธีในการดำเนินการนี้
คำอธิบายภาพ
Eigenlayerเครดิตรูปภาพ: สร้างโดยเครื่องมือ Maze AI
เราสามารถให้ผู้วางเดิมพัน (เดี่ยว) คนใดใช้คู่เดิมพันของพวกเขาเป็นหลักประกัน CDP ได้หรือไม่
เป็นชุดเครื่องมือที่ช่วยให้ผู้เดิมพันสามารถนำเงินเดิมพันไปใช้ซ้ำในแอปพลิเคชันอื่นๆ โดยกำหนดที่อยู่การถอนเป็นสัญญาที่คืนเงินเฉพาะเมื่อตรงตามเงื่อนไขบางประการเท่านั้น อาจเป็นไปได้ว่าสร้างเวอร์ชันของ RAI ที่ใช้ Eigenlayer: ผู้ใช้ฝาก ETH ที่จำนำไว้ใน CDP โดยตั้งค่าที่อยู่การถอนเป็นสัญญาที่จะถูกส่งคืนหลังจากชำระหนี้ RAI แล้วเท่านั้น หากผู้ใช้ถูกชำระบัญชี ตรรกะของสัญญาจะโอนความเป็นเจ้าของ ETH ไปยังผู้ชำระบัญชี (ซึ่งจะทำให้เกิดการถอนเงินทันทีเมื่อเป็นไปได้ในโปรโตคอล)
ความท้าทายหลักของแนวทางนี้คือ แม้ว่ามันจะทำงานได้ดีภายใต้สถานการณ์ปกติโดยมีบทลงโทษที่หายากมากและต่ำมาก แต่ในกรณีที่รุนแรง มันสามารถลดความปลอดภัยของระบบได้อย่างมาก โดยเฉพาะอย่างยิ่ง หากผู้โจมตีตั้งใจที่จะดำเนินการโจมตี 51% (หรือแม้แต่การโจมตีที่รุนแรงกว่านั้นที่เกี่ยวข้องกับการฟันผู้เสนอ) จากนั้น ผู้ตรวจสอบความถูกต้องทั้งหมดที่ใช้ในการโจมตีระบบจะเข้าสู่ RAI-CDP และนำ RAI ออกไปให้มากที่สุดเท่าที่จะเป็นไปได้ มีเหตุผล.
หากผู้โจมตีทำเช่นนี้ พวกเขากำลัง "ขโมย" RAI ออกจากระบบอย่างมีประสิทธิภาพ ทำให้ระบบต้องก่อหนี้ในรูปของ RAI ระบบอาจพยายามปรับสมดุลอย่างรวดเร็วโดยการประมูลเพื่อใช้ทุนสำรอง FLX หรือ ETH เพื่อซื้อ RAI คืน แต่ก็ยังมีความเสี่ยงที่จะล้มละลาย
RAI สามารถใช้เฉพาะ stETH ของ Lido ได้หรือไม่
นี่เป็นแนวทางที่ RAI อาจต้องใช้งานน้อยที่สุดในขณะที่แก้ไขปัญหาข้างต้น อย่างไรก็ตาม ฉันจะกังวลเกี่ยวกับแนวทางนี้ เนื่องจากการรวมระบบ Stake อย่าง stETH เข้าด้วยกันเพิ่มเติม จะนำไปสู่ความเสี่ยงของระบบระดับ Ethereum หากได้รับการครอบงำตลาดมากขึ้น นั่นจะนำความไว้วางใจมาสู่ระบบที่ควบคุม stETH อย่างมาก และแนะนำเวกเตอร์การโจมตีใหม่ให้กับ Ethereum stake โดยรวม สิ่งนี้เป็นจริงน้อยกว่าสำหรับ stETH มากกว่าอนุพันธ์ของการเดิมพันแบบรวมศูนย์ แต่ก็ยังมีความเสี่ยง
ด้วยเหตุผลนี้ ฉันจึงอยากลองและค้นหาวิธีใช้ Staked ETH เป็นหลักประกันเพื่อหลีกเลี่ยงผลกระทบของเครือข่ายรอบอนุพันธ์ Liquid Stake ที่โดดเด่นเพียงตัวเดียว และเนื่องจาก RAI ไม่ต้องการความสามารถในการใช้งานร่วมกันได้ของสินทรัพย์ค้ำประกัน (เนื่องจาก CDP ไม่สามารถใช้งานร่วมกันได้) RAI จึงสามารถเป็นส่วนหนึ่งของการแก้ปัญหาได้
แนวคิดที่ 1: Oracles ในฐานะผู้วางเดิมพันทุกคนที่มี RAI CDP (หรือ RAI) มีความมั่นใจสูงว่าระบบ oracle ของ RAI จะไม่ขโมยเงินของพวกเขา หาก RAI oracle เริ่มรายงานราคา ETH/USD ใกล้ศูนย์ CDP ทั้งหมดจะถูกชำระบัญชี ปล่อยให้ผู้ถือไม่มีอะไรเลย ผู้ถือ RAI (ผู้โจมตีสมมุติฐานอาจเป็นผู้ที่ใหญ่ที่สุดในบรรดาพวกเขาทั้งหมด) จะสามารถเข้ามาซื้อ CDP และรับ ETH ในราคาถูกมากด้วยเหตุผลนี้ ความไว้วางใจในระบบออราเคิลจึงควรได้รับการพิจารณาอย่างจริงจัง โดยเฉพาะอย่างยิ่ง เป็นไปไม่ได้ที่ 51% ของโทเค็นการเก็งกำไรของโปรโตคอล (ในที่นี้คือ FLX) จะโหวตเพื่อเปลี่ยนผู้ให้บริการ oracle ทันทีโดยไม่ล่าช้า (มิฉะนั้น ระบบจะไม่เสถียรในสภาพแวดล้อมที่จำนวนเงินรวมที่มีความเสี่ยง เกินมูลค่าตามราคาตลาดของ FLX run) ความคิดเห็นของฉันเองเกี่ยวกับรุ่นที่ดีที่สุดนั้นคร่าวๆ
ดังนั้น
ของ.
อย่างไรก็ตาม ข้อสังเกตที่สำคัญก็คือเนื่องจากผู้ถือ RAI นั้นไว้วางใจออราเคิลอยู่แล้วว่าจะไม่ทำให้พวกเขาเสียหายด้วยวิธีนี้ ดูเหมือนจะไม่เพิ่มความเสี่ยงของระบบหากเราไว้วางใจออราเคิลด้วยวิธีอื่นที่มีความเสี่ยงน้อยกว่าเรื่องเพศ
ทางเลือกที่เป็นธรรมชาติ: RAI เองสร้างสำเนาของ Lido ซึ่งผู้ใช้ที่สร้าง CDP สามารถเดิมพันเงินเหล่านี้ได้ โดยตั้งค่า RAI oracle เป็นคีย์เดิมพัน (บางที RAI oracle สามารถเรียกใช้ตัวตรวจสอบความถูกต้องแบบกระจายร่วมกันได้) แต่ตั้งค่า CDP เป็นที่อยู่การถอน
ระดับของความไว้วางใจที่นี่ไม่สูงอย่างที่คิด นักพยากรณ์ RAI ที่ไม่ดีอาจทำให้เงินทุนถูกบุกรุกได้ ไม่ว่าจะถูกฟันหรือรั่วไหล แต่ไม่สามารถขโมยเงินได้ โดยมีข้อยกเว้นบางประการ เช่น การโจมตี MEV แบบพิเศษที่ผู้โจมตี ถูกตัดข้อเสนอสองครั้ง
แต่ก็ยังไม่สมบูรณ์แบบ: การโจมตีที่หายากและพิเศษนี้เป็นไปได้ และไม่ชัดเจนว่านักพยากรณ์เต็มใจที่จะเป็นเดิมพัน ความเสี่ยงทางกฎหมายของการเดิมพันดูเหมือนจะสูงกว่าความเสี่ยงทางกฎหมายในการเป็นผู้ให้บริการออราเคิล ซึ่งจัดอยู่ในหมวดหมู่ "ข้อมูลเท่านั้น" ที่ชัดเจนในการพูดอย่างอิสระในเขตอำนาจศาลหลายแห่ง สิ่งนี้ยังสร้างแรงจูงใจในการโจมตีพวกเขามากขึ้นDVT 。
แนวคิดที่ 2: Oracles ในฐานะผู้วางเดิมพัน 2 ใน 2
นี่เป็นอีกทางเลือกหนึ่งที่ช่วยให้ผู้ใช้สามารถควบคุมได้มากขึ้นและไว้วางใจน้อยลงในออราเคิล แทนที่จะเป็นคีย์จำนำที่เป็นของออราเคิล คีย์จำนำคือ P + Q โดยที่ Q เป็นคีย์ที่เป็นของออราเคิล และ P เป็นคีย์ที่ถือโดยผู้ถือ CDP เนื่องจากลักษณะเฉพาะของอัลกอริทึมของลายเซ็น BLS เครื่องออราเคิลสามารถลงนามด้วย Q ผู้ถือ CDP สามารถลงนามด้วย P เอง และเพิ่มลายเซ็นทั้งสองเข้าด้วยกันเพื่อสร้างลายเซ็นที่ยืนยัน P + Q นี่คือ 2 ต่อ 2
สิ่งนี้บังคับใช้คุณสมบัติที่เชื่อถือได้ดังต่อไปนี้:
Oracle เพียงอย่างเดียวไม่สามารถยึดผู้ถือ CDP ได้
ออราเคิลเองไม่สามารถดำเนินการโจมตีผู้เสนอได้ เนื่องจากข้อเสนอแบบบล็อกต้องการลายเซ็นของผู้ถือ CDP
ไม่สามารถฟันหรือโจมตีผู้ถือ CDP ได้ ดังนั้นจึงไม่สามารถประนีประนอมหลักประกันของระบบด้วยวิธีนี้
ตัวยึด oracle หรือ CDP สามารถออฟไลน์ได้ ในกรณีนี้ อีกฝ่ายจะเรียกใช้ทางออกและออกจาก CDP โดยสูญเสียเพียงเล็กน้อย
กรณีที่รุนแรงคือเมื่อตัวยึด oracle หรือ CDP ออฟไลน์ระหว่างการรั่วไหลที่ไม่มีการใช้งาน กรณีนี้ฝ่ายใดฝ่ายหนึ่งอาจทำให้อีกฝ่ายเสียหายได้
ดำเนินการ
การออกแบบนี้เป็นกรณีพิเศษของ DVT:
นี่คือ 2 ต่อ 2 ดังนั้นจึงเป็นกรณีที่ง่ายที่สุดจากมุมมองด้านเครือข่าย
1 จาก 2 (Oracle) ให้บริการคู่ค้านับพันราย อย่างไรก็ตาม มันสามารถลงนามในข้อมูลเดียวกันและเผยแพร่เพื่อดาวน์โหลดไปยัง CDP ทั้งหมดที่ใช้งานได้
เพื่อให้การผลิตบล็อกเป็นไปอย่างอิสระ ในกรณีนี้สามารถใช้ระบบที่ผู้เสนอเลือกว่าจะลงนามอะไรและส่งไปยังออราเคิลเพื่อลงนามร่วม Oracles ไม่ควรเซ็นชื่อข้อมูลสองส่วนที่แตกต่างกันในช่องเดียวกันในโดเมนเดียวกันในเวลาเดียวกัน เนื่องจากอาจรวมกับกลอุบายที่ทำให้มองไม่เห็นเพื่อเฉือน CDP
นี่เป็นเทคโนโลยีใหม่ที่ต้องดำเนินการ ดังนั้นอาจต้องอาศัยความร่วมมือของทีมงาน DVT เพื่อให้เกิดขึ้นจริง เมื่อสร้างแล้วก็ไม่ควรใช้งานยากเกินไป
จุดอ่อนของความคิด2
ช่องโหว่ที่ใหญ่ที่สุดของระบบนี้คือการรั่วไหลที่ไม่มีการใช้งาน เนื่องจากสิ่งเหล่านี้อาจเกิดขึ้นจาก oracle แบบออฟไลน์เท่านั้น อย่างไรก็ตาม ฉันคิดว่ามันโอเคที่จะยอมรับความเสี่ยงนั้น หากยอดคงเหลือต่ำกว่า 16 ETH เครื่องมือตรวจสอบจะออกและถอน ETH โดยอัตโนมัติ ดังนั้น แทนที่จะเสนอ ETH ปกติ 1.5 เท่า เราสามารถยอมรับ ETH ที่เดิมพันด้วยข้อกำหนดหลักประกัน 2 เท่าPufferมีกรณีขอบที่หากตัวตรวจสอบความถูกต้องจำนวนมากรั่วไหลในเวลาเดียวกัน มีเพียงไม่กี่ตัวเท่านั้นที่สามารถออกได้พร้อมกัน ดังนั้นตัวตรวจสอบความถูกต้องบางส่วนจึงถูกลงโทษเพิ่มเติมสำหรับการรั่วไหลที่ต่ำกว่า 16 ETH แต่นี่เป็นการเปลี่ยนแปลงที่เป็นไปได้ในโปรโตคอลการปักหลัก ethereum หากมี ความต้องการ. แม้จะไม่มีการแก้ไข แต่ก็ต้องมีการโจมตีที่รุนแรงมาก (มากกว่า 50% ออฟไลน์) โดยที่ตัวตรวจสอบความถูกต้องจำนวนมากรั่วไหลต่ำกว่า 16 ETH ก่อนที่สัดส่วนของยอดคงเหลือที่ควบคุมโดยตัวตรวจสอบความถูกต้องที่ซื่อสัตย์จะกลับมามากกว่า 2/3
ข้อเสียเปรียบที่สำคัญอีกประการหนึ่งคือมันทำงานได้ไม่ดีนักในโลกที่ข้อกังวลหลักไม่ใช่การใช้ oracle slashing ที่เป็นอันตราย แต่เป็น oracles ที่เป็นอันตรายหรือไม่ได้ตั้งใจที่ออฟไลน์ อาจเป็นเพราะเรา (i) คาดหวังให้ oracles เป็น staker ที่มีคุณภาพต่ำ เนื่องจากเราปรับให้เหมาะสมเพื่อความซื่อสัตย์มากกว่าความเชี่ยวชาญทางเทคนิค หรือ (ii) oracles ใช้ฮาร์ดแวร์ที่เชื่อถือได้และผู้ใช้ยอมรับว่านี่เป็นสมมติฐานที่น่าเชื่อถือ (บางส่วน) (ดู
). เพื่อแก้ไขจุดอ่อนเหล่านี้ เราเสนอแนวคิดที่ 3 ด้านล่าง
แนวคิดที่ 3: ออราเคิลกึ่งเชื่อถือได้สำหรับการรักษาความปลอดภัยแบบลำดับชั้น
ในกรณีที่คุณสามารถรับประกันได้ว่าคำพยากรณ์ส่วนใหญ่มีความซื่อสัตย์ วิธีอื่นจะขจัดปัญหาความเชื่อถือที่เหลืออยู่
เรากำหนดค่าคงที่สามค่า:
N: จำนวนออราเคิลทั้งหมดในระบบออราเคิล
k 1 : จำนวน oracles ที่สามารถลงนามข้อความด้วยตัวยึด CDP (เช่น k 1 ~= 0.2 * N)
k 2 : จำนวนของ oracles ที่สามารถทำงานร่วมกันเพื่อลงนามข้อความโดยไม่มีตัวยึด CDP (เช่น k 2 ~= 0.8 * N)
เราต้องการให้ oracle รักษาคีย์ลับที่ใช้ร่วมกันสองคีย์:
Q1 ใน k 1-of-N การแบ่งปันความลับ
P + Q2 ใน k 2-of-N การแบ่งปันลับ (อันหลังสำหรับผู้ถือ CDP แต่ละราย)
สำหรับไตรมาสที่ 1 ออราเคิลสามารถลงนามร่วมกับผู้ถือ CDP และสำหรับไตรมาสที่ 2 พวกเขาสามารถลงนามโดยอิสระได้
ในกรณี k 1 + k 2 = N (เช่น k 1 = N/5 และ k 2 = 4 N/5 ) สิ่งนี้ทำให้มั่นใจได้ว่าจะไม่มีการเฉือนและการรั่วไหลที่ไม่ใช้งานเกิดขึ้นในทั้งสองกรณี:
มากกว่า k2 oracles มีความซื่อสัตย์ (เนื่องจากพวกเขาสามารถลงนามในข้อความได้อย่างอิสระ ผู้ถือ CDP ที่เป็นอันตรายจึงไม่สามารถหาองค์ประชุม k1 เพื่อลงนามร่วมกันได้)
oracles อย่างน้อย k 1 ตัวมีความซื่อสัตย์ และผู้ถือ CDP มีความซื่อสัตย์ (เนื่องจากทั้งสองกลุ่มสามารถลงนามข้อความร่วมกันได้ ในขณะที่ oracles ที่เหลือไม่สามารถลงนามหรือปิดกั้นได้)
รูปแบบนี้คล้ายกับวงล้อฝึกสอนระยะที่ 1 ของ Rollup ซึ่งสร้างการผสมผสานเชิงเส้นระหว่างรูปแบบความปลอดภัยสองรูปแบบ เพื่อเป็นหนทางในการไว้วางใจทั้งสองแบบบางส่วน แต่ไม่ควรไว้วางใจมากเกินไป
โปรดทราบว่าการออกแบบนี้สามารถมองได้ว่าเป็นแนวคิดทั่วไปของแนวคิด 1 และ 2 (หรือแม้แต่ข้อเสนอ "ผู้ถือ CDP สามารถลงนามด้วยตนเอง"): k 1 และ k 2 สามารถปรับได้ตามต้องการเพื่อสำรวจพื้นที่ทั้งหมดของการแลกเปลี่ยนว่าใครควรไว้วางใจ .
ประโยชน์ทั่วไปของแนวทางเหล่านี้ (แนวคิดที่ 1 จาก 2 หรือ 3)
น่าเชื่อถือและเป็นกลางและไม่แนะนำการพึ่งพาภายนอก: ไว้วางใจเฉพาะผู้เข้าร่วมและได้รับความไว้วางใจในระดับที่สูงขึ้น
ตระหนักถึงประโยชน์ที่ผู้ใช้สามารถจำนำและถือ CDP ได้ในเวลาเดียวกัน
หลีกเลี่ยงการอำนวยความสะดวกโดยไม่จำเป็นต่อผลกระทบเครือข่ายของอนุพันธ์ที่มีสภาพคล่องเป็นหลักประกันที่มีอยู่ ในทางกลับกัน Stablecoins ที่ดูแลโดยโปรแกรมนั้นเป็นตราสารอนุพันธ์ที่มีสภาพคล่อง (เสถียร)
เปรียบเทียบไอเดีย 1 ไอเดีย 2 และไอเดีย 3
จัดอันดับตามความง่ายในการใช้งาน ไอเดีย 1 > ไอเดีย 2 > ไอเดีย 3
จัดอันดับโดยการป้องกัน oracles ที่ไม่ดี ความคิด 3 > ความคิด 2 > ความคิด 1
จัดอันดับตามการป้องกันผู้ถือ CDP ที่ไม่ดี แนวคิด 3 > แนวคิด 2 > แนวคิด 1
