นี่คือความต่อเนื่องของ เธรดเริ่มต้นเกี่ยวกับการกำกับดูแลแบบคู่ 18 เธรดที่เชื่อมโยงมีบริบทที่สำคัญ ดังนั้นโปรดอ่านหากคุณมีเวลา

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

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

ปัญหา

ปัจจุบัน รหัสโปรโตคอล Lido และพารามิเตอร์ได้รับการควบคุมโดย Lido DAO ผ่านการลงคะแนนโทเค็น LDO โปรโตคอลจะคิดค่าธรรมเนียม 5% จากรางวัลการปักหลักและส่งต่อไปยังคลัง DAO (อีก 5% จะแจกจ่ายให้กับผู้ให้บริการโหนดที่เข้าร่วมในโปรโตคอล)

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

สิ่งนี้สามารถสรุปได้ว่าเป็นปัญหาหลัก-ตัวแทน (PAP) ระหว่าง DAO (ตัวแทน) และผู้ใช้โปรโตคอล (หลัก) ปัญหานี้เกิดขึ้นเนื่องจากผู้ถือ LDO ไม่มีแรงจูงใจเหมือนกับผู้ใช้

ยิ่งไปกว่านั้น ตามที่ Vitalik เน้นย้ำในบทความเรื่อง Moving Beyond Coin Vote 9 ของเขา PAP นั้นยิ่งเลวร้ายลงจากข้อเท็จจริงที่ว่าผลประโยชน์ทางเศรษฐกิจในรายได้ของโปรโตคอลสามารถแยกออกจากอำนาจการกำกับดูแลได้ เราอาจบิดเบือนแรงจูงใจของผู้ถือโทเค็น DAO โดยการติดสินบนพวกเขาหรือ ยืมโทเค็นการลงคะแนน DAO ในตลาดเปิดเพื่อพยายามได้รับอำนาจการลงคะแนนที่เพียงพอสำหรับการผลักดันการเปลี่ยนแปลงที่ขัดต่อผลประโยชน์ของทั้ง DAO และผู้ใช้โปรโตคอล

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

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

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

ปัจจัยที่สองคือผู้ใช้ส่วนสำคัญเลือกการวางเดิมพันสภาพคล่องเนื่องจากพวกเขาต้องการปรับใช้เงินทุนที่เดิมพันไว้กับกิจกรรมทางเศรษฐกิจรูปแบบอื่น ๆ ส่งผลให้โทเค็นการปักหลักของเหลว (LST) ถูกนำมาใช้กันอย่างแพร่หลายใน DeFi รวมถึงโปรโตคอลที่จำเป็นต้องมี เวลาเพิ่มเติมในการถอนตัว (เช่น ตลาดสินเชื่อ) นี่เป็นการเพิ่มการพึ่งพาภายนอกอีกหนึ่งรายการที่สามารถป้องกันไม่ให้ผู้ใช้ออกจากโปรโตคอลภายในกรอบเวลาที่กำหนดไว้ล่วงหน้า

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

Lido DAO ได้สร้างโปรโตคอลการกำกับดูแลจำนวนหนึ่งเพื่อลดความไม่สมดุลของข้อมูล (เช่น กรอบงาน GOOSE, กลุ่มการกำกับดูแลย่อยของผู้ดำเนินการโหนด, กรอบงาน LIP, ความมุ่งมั่นในจำนวนการตรวจสอบขั้นต่ำของการเปลี่ยนแปลงรหัสเมนเน็ตใดๆ) แต่ทั้งหมดล้วนเป็น ข้อตกลงชั้นทางสังคมระหว่างผู้ถือ LDO ปัจจุบัน จึงไม่สามารถป้องกันจากการโจมตี DAO จากภายนอกได้

ไปสู่การแก้ปัญหา

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

การลดขอบเขตการกำกับดูแลให้เหลือน้อยที่สุดเป็นสิ่งที่ผู้ร่วมโครงการมองว่ามีความจำเป็นในปีต่อๆ ไป อย่างไรก็ตาม จนกว่าข้อกำหนด Ethereum จะแข็งตัว ความสามารถในการอัปเกรดโค้ดจะลดลงได้ในระดับหนึ่งเท่านั้น (เช่น ดู EIP-7002 5, EIP-7251 6) นอกจากนี้ รหัสที่ไม่เปลี่ยนรูปใดๆ จะต้องได้รับการตรวจสอบอย่างเป็นทางการในระดับไบต์โค้ด เพื่อไม่ให้เกิดข้อผิดพลาดของคอมไพเลอร์ที่ก่อให้เกิดช่องโหว่ที่ไม่สามารถแก้ไขได้

นอกจากนี้ยังมีชั้น fungibility ของโปรโตคอลที่ทำหน้าที่เป็นกลไกการประเมินความเสี่ยง/รางวัล และกระจาย ETH ระหว่างชุดย่อยของเครื่องมือตรวจสอบที่แตกต่างกันในลักษณะที่สร้างสมดุลระหว่างผลตอบแทนและความเสี่ยงของชุดเครื่องมือตรวจสอบผลลัพธ์ ความเสี่ยงที่นี่รวมถึงความเสี่ยงส่วนท้ายที่ชุดตรวจสอบความถูกต้องสร้างขึ้นสำหรับเครือข่าย Ethereum เช่น การเซ็นเซอร์และความเสี่ยงที่สัมพันธ์กันอย่างเจ็บแสบ มีการวิจัยอย่างต่อเนื่อง (ดู รายงานนี้ 6 สำหรับการทำซ้ำครั้งล่าสุด) ว่าความเสี่ยงเหล่านี้สามารถประมาณได้โดยโปรโตคอลด้วยความช่วยเหลือของอุปกรณ์ oracle ที่ไม่น่าเชื่อถือซึ่งนำข้อมูลที่จำเป็นมาสู่เครือข่าย แต่เป็นความพยายามในระยะยาวและยังไม่ชัดเจนว่า ผลลัพธ์ที่ต้องการสามารถบรรลุผลได้จริง จนกว่าโปรโตคอลจะมีการใช้กลไกที่ไร้ความน่าเชื่อถือ จะต้องมีการกำกับดูแลในระดับชั้นที่เข้ากันได้

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

ตอนนี้เราได้กำหนดไว้แล้วว่าโปรโตคอลจะต้องอยู่ภายใต้การกำกับดูแลบางประเภทอย่างน้อยในระยะกลาง มาดูกันว่าเราจะย่อ <a href="https://notes.ethereum.org/@mikeneuder/magnitude ได้อย่างไร -และทิศทาง">ที่ ความเสี่ยงที่การกำกับดูแลนี้สร้างขึ้น 1.

ธรรมาภิบาลแบบคู่

ตามที่เน้นไว้ในส่วนแรก ปัญหาทั่วไปสามารถแบ่งออกเป็น 1) การมีอยู่ของ PAP และ 2) ประสิทธิภาพที่จำกัดของการลงคะแนนเสียงด้วยเท้า ตามหลักการแล้ว เราอยากจะแนะนำกลไกบางอย่างที่ปรับปรุงทั้งการจัดตำแหน่งระหว่าง DAO และผู้ใช้โปรโตคอล และประสิทธิภาพของการลงคะแนนเสียงด้วยเท้า

นั่นคือจุดที่เรามาถึงข้อเสนอการออกแบบการกำกับดูแลแบบคู่ มีจุดมุ่งหมายเพื่อการปรับปรุงต่อไปนี้:

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

ภาพรวมของการออกแบบกลไกที่นำเสนอและแนวคิดบางประการสำหรับการวิจัยในอนาคตเกี่ยวกับการลดความเสี่ยงด้านการกำกับดูแลมีอยู่ในหมายเหตุนี้: <a href="https://hackmd.io/ @skozin /r17mlW2la"">https://hackmd io/@skozin/r17mlW2la 37 .

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

อีกทิศทางหนึ่งของการวิจัยในอนาคตคือการสำรวจการ กำกับดูแลที่ไม่ใช่โทเค็นและการกำกับดูแลแบบไฮบริด 2

ขั้นตอนถัดไป

จากที่นี่ มีหลายสิ่งที่ต้องเกิดขึ้นก่อนที่การออกแบบจะเสร็จสิ้น ส่งผลให้มีข้อเสนอการปรับปรุง Lido (LIP) ที่เป็นทางการมากขึ้น ซึ่งจะถูกส่งสำหรับการลงคะแนนเสียงของ DAO และเอกสารบันทึกการตัดสินใจด้านสถาปัตยกรรม (ADR) ที่เกี่ยวข้อง:

1. การประเมินความแข็งแกร่งของกลไกที่เสนอผ่านการจำลองสถานการณ์และการโจมตี
2. การประเมินการใช้งานจริงของกลไกผ่านการสร้างต้นแบบโค้ด
3. การรวบรวมคำติชมของชุมชน

หัวข้อนี้มีจุดมุ่งหมายเพื่อให้บรรลุผลสำเร็จใน 3 ข้อ ในขณะที่ผู้ร่วมโครงการดำเนินการในวันที่ 1 และ 2 (ทั้งสองอยู่ระหว่างดำเนินการ) ดังนั้นข้อเสนอแนะใดๆ ก็ตามจะได้รับการชื่นชมอย่างสูง!

สิ่งสำคัญคือต้องเน้นว่า แม้ว่าการกำกับดูแลแบบคู่ (ในความคิดของฉัน) จะเป็นขั้นตอนสำคัญในการลดความเสี่ยงด้านการกำกับดูแลของโปรโตคอล แต่ก็ไม่ใช่ขั้นตอนสุดท้าย แนวคิดบางประการสำหรับการปรับปรุงเพิ่มเติมสามารถพบได้ในเอกสารการออกแบบกลไกที่ลิงก์ด้านบน และฉันขอเชิญทุกคนที่สนใจหารือเกี่ยวกับสิ่งเหล่านั้นและการปรับปรุงที่เป็นไปได้อื่นๆ โดยการโพสต์หัวข้อในฟอรั่มนี้

ข้อสงวนสิทธิ์：

1. บทความนี้พิมพ์ซ้ำจาก [lido] ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [skozin] หากมีการคัดค้านการพิมพ์ซ้ำนี้ โปรดติดต่อทีมงาน Gate Learn แล้วพวกเขาจะจัดการโดยเร็วที่สุด
2. การปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นดำเนินการโดยทีมงาน Gate Learn เว้นแต่จะกล่าวถึง ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว