Vitalik และ Yoav กรุณาตรวจสอบโพสต์นี้ แต่ความคิดเห็นเป็นของฉันเอง

หากคุณยังไม่ได้ติดตามละคร AA นี่คือบทสรุปโดยย่อ:

• เมื่อหลายสัปดาห์ก่อน EIP-3074 ซึ่งเป็นข้อเสนอที่จะนําประโยชน์มากมายของ AA มาสู่ผู้ใช้ EOA ได้รับการอนุมัติจากผู้พัฒนาหลักให้เข้าสู่ "Pectra" ซึ่งเป็นฮาร์ดฟอร์คถัดไปของ Ethereum
• ตั้งแต่นั้นมาหลายคนในชุมชน ERC-4337 โดยเฉพาะผู้เขียน 4337 เองได้รับ ผลักดันอย่างมากในปี 3074 ด้วยเหตุผลของ @yoav/3074-implications">ความกังวลเกี่ยวกับการรวมศูนย์และความเข้ากันไม่ได้กับ @yoav/AA-roadmap-May-2024">AA roadmap ซึ่งมีศูนย์กลางอยู่ที่ 4337 และลูกพี่ลูกน้อง 7560 (aka "native AA")
• เมื่อสัปดาห์ที่แล้ว Vitalik เสนอ EIP-7702 เป็นทางเลือกแทน 3074 ส่วนใหญ่บรรลุเป้าหมายเดียวกัน - นําประโยชน์มากมายของ AA มาสู่ผู้ใช้ EOA - แต่ในลักษณะที่เข้ากันได้กับ 4337 ในปัจจุบันและเข้ากันได้กับ "AA endgame" นั่นคือ 7560
• ในเวลานี้ผู้พัฒนาหลักกําลังพิจารณาเกี่ยวกับ EIP-7702 แต่การอภิปรายเบื้องต้นและความรู้สึกของชุมชนชี้ให้เห็นว่า EIP-7702 มีแนวโน้มที่จะแทนที่ EIP-3074 ใน Pectra

โดยส่วนตัวแล้วฉันมีความสุขมากกับผลลัพธ์: ผู้ใช้ EOA จะสามารถเพลิดเพลินกับประโยชน์ส่วนใหญ่ของ AA ในไม่ช้าโดยใช้เครื่องมือและอินฟาเรดที่สร้างขึ้นสําหรับ ERC-4337

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

ในบล็อกโพสต์นี้ฉันต้องการ:

• ระบุสิ่งที่ผิดพลาดกับกระบวนการ
• เสนอแบบจําลองทางจิตสําหรับการคิดเกี่ยวกับการกํากับดูแล Ethereum
• เสนอแนะการปรับปรุงเพื่อหลีกเลี่ยงความล้มเหลวในการกํากับดูแลที่คล้ายคลึงกันในอนาคต

ทําไมกระบวนการทําให้ผู้คนไม่มีความสุข

เทพนิยายทั้งหมดนี้ทําให้ผู้คนจํานวนมากไม่มีความสุขด้วยเหตุผลหลายประการ:

• ใช้เวลาหลายปีในการอนุมัติ 3074
• หลังจาก 3074 ได้รับการอนุมัติในที่สุดผู้พัฒนาหลักก็ได้รับการผลักดันจํานวนมากจากชุมชน 4337
  • ในทางกลับกันผู้เขียน 4337 เองได้แสดงความกังวลซ้ํา ๆ กับ 3074 ไปยัง devs หลักเพื่อประโยชน์
• ตอนนี้เราอยู่ในเส้นทางที่จะยกเลิกการอนุมัติ 3074 และแทนที่ด้วย EIP อื่น (7702)

ตอนนี้ไม่มีอะไรผิดปกติโดยเนื้อแท้กับข้อใดข้อหนึ่งข้างต้น:

• ไม่เป็นไรสําหรับการอภิปรายที่จะใช้เวลาหลายปี
• เป็นเรื่องปกติที่ EIP จะได้รับ pushbacks หลังจากได้รับการอนุมัติ
คุณสามารถ
• ยกเลิกการอนุมัติ EIP ได้หลังจากได้รับการอนุมัติหากมีการระบุปัญหาใหม่

อย่างไรก็ตามเราอาจเห็นพ้องต้องกันว่าสิ่งต่าง ๆ อาจราบรื่นขึ้น ลองนึกภาพว่ามันเป็นแบบนี้หรือไม่:

• ชุมชน 4337 มีส่วนร่วมอย่างแข็งขันกับนักพัฒนาหลักในขณะที่พวกเขากําลังโต้วาที 3074 ตอนนี้มีเพียงหนึ่งในสองผลลัพธ์ที่เป็นไปได้:
  • ทั้ง 3074 ได้รับการอนุมัติ (และอาจแก้ไข) หลังจากนําความคิดเห็นของชุมชน 4337 มาพิจารณาซึ่งในกรณีนี้ชุมชน 4337 จะเข้าร่วมกับ 3074 และเราจะไม่ย้อนกลับ 3074
  • หรือ, 3074 was never approved, but the 4337 community and core devs worked together towards a proposal that everyone is happy with, à la 7702.

เสียงของทุกคนได้ยินและไม่มีการกลับตัวที่น่าทึ่ง นั่นคงจะดี - แล้วทําไมมันถึงไม่เกิดขึ้น?

เกิดอะไรขึ้น?

สะท้อนให้เห็นถึงกระบวนการทั้งสองฝ่ายของการอภิปรายได้ชี้นิ้วไปที่กันและกัน

นักพัฒนาหลัก (และผู้เขียน EIP-3074) รู้สึกว่ามันเป็นความผิดของ "4337 คน" ที่พวกเขาไม่ได้มีส่วนร่วมอย่างแข็งขันกับ กระบวนการ All Core Devs (ACD) ซึ่ง EIPs ได้รับการพิจารณาเป็นเวลานานก่อนที่พวกเขาจะได้รับการยอมรับจากทีมลูกค้าในที่สุดและด้วยเหตุนี้จึงนําไปใช้ในโปรโตคอล

เมื่อถึงจุดใดในระหว่างการพิจารณานี้ข้อโต้แย้งก็เกิดขึ้น "4337 คน" อาจเข้ามาและแสดงความกังวลของพวกเขาแทนที่จะรอจนกว่า 3074 จะได้รับการอนุมัติแล้ว ท้ายที่สุดกระบวนการ ACD ได้รับการบันทึกไว้อย่างดี การประชุมเปิดให้ทุกคนและมีคนอย่าง Tim Beiko ที่ทวีตสรุปอย่างแข็งขันหลังจากการประชุม ACD ทุกครั้ง ดังนั้นถ้าคน 4337 ใส่ใจมากเกี่ยวกับปัญหานี้ทําไมพวกเขาไม่ใช้เวลาในการมีส่วนร่วม?

ทีม AA (ผู้เขียน 4337 คน) ชี้ให้เห็นว่าพวกเขาเข้าร่วมการประชุม ACD และผลักดันกลับ 3074 ทุกโอกาสที่ทําได้ แต่นักพัฒนาหลักไม่ฟัง สําหรับชุมชน 4337 พวกเขาส่วนใหญ่รู้สึกตาบอด - คนส่วนใหญ่อยู่ภายใต้ความรู้สึกว่า 3074 เสียชีวิตแล้วและไม่รู้ด้วยซ้ําว่า 3074 กําลังได้รับการพิจารณาอย่างแข็งขันเพื่อรวม

หลายคนยังรู้สึกว่ากระบวนการ ACD นั้นทึบแสงเกินไปและไม่เป็นมิตรกับการมีส่วนร่วมจากผู้ที่มี "งานจริง" และไม่สามารถติดตามการอัปเดต ACD ทั้งหมดได้ บางคนยังรู้สึกว่าควรเป็นความรับผิดชอบของ ACD ในการแสวงหาข้อเสนอแนะจากผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้องในกรณีนี้ชุมชน 4337

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

สาเหตุที่แท้จริง

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

ปัญหาคืออํานาจการกํากับดูแลอื่น ๆ ไม่ค่อยได้รับการยอมรับแม้ว่าจะมีอิทธิพลมากกว่า ACD ในเรื่องที่สําคัญที่สุดของ Ethereum เช่น AA และการปรับขนาด

ในบทความนี้ฉันจะเรียกพลังนี้ว่า "แผนงาน"

เทพนิยาย 3074/7702 ทั้งหมดนี้ตามที่ฉันจะโต้แย้งนั้นไม่มากและไม่น้อยไปกว่าตัวอย่างของพลังของแผนงานที่ครอบงําพลังของ ACD และถ้าเรากําลังพูดถึงธรรมาภิบาลเมื่อใดก็ตามที่เราสังเกตเห็นอํานาจที่มองไม่เห็นครอบงําอํานาจที่มองเห็นได้เราควรกังวลมากเพราะสิ่งที่มองไม่เห็นนั้นไม่สามารถนับได้ดังนั้นจึงต้องนํามาสู่แสงสว่าง

แผนงานคืออะไร?

ทุกคนในชุมชน Ethereum ต้องเจอคําว่า "roadmap" เป็นจํานวนมาก เช่น ใน "แผนงานแบบ rollup-centric roadmap" "ETH 2.0 roadmap" หรือในการอภิปรายนี้ "@yoav/AA-roadmap-May-2024">แผนงาน AA

การค้นหา "แผนงาน" บน Ethereum Magicians

เพื่ออธิบายประเด็นของฉันลองนึกภาพการประชุม ACD ที่นักพัฒนาหลักกําลังหารือเกี่ยวกับวิธีการปรับขนาด Ethereum:

• Core Dev Bob: ฉันสนับสนุน EIP 1234 ซึ่งเสนอว่าเรา เร่งความเร็วเวลาบล็อก 10X เพิ่มขนาดบล็อก 10X และค่าธรรมเนียมลดลง 100X
• devs หลักอื่น ๆ : ... คุณออกจากใจ * ของคุณ?

ลองคิดดูสักวินาทีที่นี่ ทําไมนักพัฒนาหลักถึงเพิ่งยิงสิ่งที่บ๊อบพูด? เขาเพิ่งเสนอรูปแบบการปรับขนาดที่ถูกต้องมาก Solana และ L1s อื่น ๆ อีกมากมายทําเพื่อเอฟเฟกต์การปรับขนาดที่ยอดเยี่ยม

แน่นอนว่าเหตุผลก็คือ EIP ในจินตนาการนี้ขัดต่อแผนงานการปรับขนาด "rollup-centric" ของ Ethereum ซึ่งกล่าวว่า เป็นสิ่งสําคัญสําหรับการกระจายอํานาจบล็อกเชนสําหรับผู้ใช้ทั่วไปเพื่อให้สามารถเรียกใช้โหนดได้ดังนั้น EIP ในจินตนาการจึงหมดคําถามเนื่องจากจะเพิ่มอุปสรรคในการเรียกใช้โหนดอย่างมาก

สิ่งที่ฉันต้องการแสดงให้เห็นด้วยตัวอย่างนี้คือนักพัฒนาหลักที่มีส่วนร่วมในกระบวนการ ACD และตัดสินใจเกี่ยวกับการอัปเดตโปรโตคอลได้รับคําแนะนําจากแรงที่สูงกว่าที่ฉันเรียกว่าแผนงาน มีแผนงานการปรับขนาดแผนงาน AA แผนงาน MEV คุณตั้งชื่อมัน - และโดยรวมแล้วพวกเขาสร้างแผนงาน Ethereum ที่นักพัฒนาหลักใช้การตัดสินใจของพวกเขา

เมื่อ core devs ไม่ตรงกับแผนงาน

เนื่องจากแผนงานไม่ได้เป็นส่วนหนึ่งของการกํากับดูแลอย่างเป็นทางการจึงไม่มีการรับประกันว่า core devs จะสอดคล้องกับพวกเขา โดยเฉพาะอย่างยิ่งเนื่องจากไม่มีกระบวนการอย่างเป็นทางการในการ "อนุมัติ" แผนงานจึงไม่ใช่ว่าแผนงานทั้งหมดจะถูกมองว่ามีความชอบธรรมเท่าเทียมกัน มันขึ้นอยู่กับนักวิจัยที่อยู่เบื้องหลังแผนงานที่จะสนับสนุนแผนงานของพวกเขาอย่างขยันขันแข็งให้กับนักพัฒนาหลักและชุมชนขนาดใหญ่เพื่อให้ได้ความชอบธรรมและดังนั้นจึงซื้อจากนักพัฒนาหลัก

ในกรณีของ AA Vitalik เองได้ผลักดันแผนงาน AA ที่เน้น 4337 บน @vbuterin/account_abstraction_roadmap">multiple โอกาส แต่โดยรวมแล้วส่วนใหญ่เป็นทีม 4337 โดยเฉพาะอย่างยิ่ง Yoav และ Dror ซึ่งเป็นแชมป์แผนงาน AA 4337 เป็นศูนย์กลางในการประชุมฟอรัมออนไลน์และการประชุม ACD

อย่างไรก็ตาม แม้จะมีความพยายามเหล่านี้ แต่ก็มีการต่อต้านอย่างรุนแรงจากผู้พัฒนาหลักบางคนที่ต่อต้านแผนงาน AA ที่เน้น 4337 เป็นศูนย์กลาง พวกเขารู้สึกว่า 7560 ซึ่งเป็นเวอร์ชันดั้งเดิมของ 4337 ที่ลูกค้าจะต้องนําไปใช้ในที่สุดนั้นซับซ้อนเกินไปและไม่ใช่ผู้สมัครเพียงคนเดียวสําหรับ "AA endgame" ในที่สุด ACD ก็ตัดสินใจอนุมัติ 3074 แม้จะมีการคัดค้านของทีม 4337 ว่าจะแยกส่วนระบบนิเวศ AA โดยการสร้างทางเลือกและ @yoav/3074-implications">less decentralized AA tech stack

อย่างไรก็ตามเมื่อ 3074 ได้รับการอนุมัติมีปฏิกิริยาที่รุนแรงจากชุมชน 4337 ทั้งหมดซึ่งบังคับให้นักพัฒนาหลักมีส่วนร่วมในการอภิปราย 3074 อีกครั้ง การถกเถียงนั้น กลายเป็นทางตันที่ทั้งผู้เขียน 4337 และผู้เขียน 3074 ไม่สามารถโน้มน้าวใจกันได้ จนกระทั่ง Vitalik เข้ามา ในชั่วโมงที่สิบเอ็ดและเสนอ EIP-7702 เป็นทางเลือกแทน 3074 ที่เข้ากันได้กับ "AA endgame" ที่เน้น 4337 อย่างชัดเจน และด้วยเหตุนี้จึงผลักดันความขัดแย้งเพื่อสนับสนุนแผนงาน AA

บทบาทของ Vitalik

แม้ว่า Vitalik จะพาตัวเองไปเป็นนักวิจัย แต่เทพนิยายนี้แสดงให้เห็นอย่างชัดเจนว่า Vitalik นําพลังการกํากับดูแลที่มีคุณภาพแตกต่างไปจากนักวิจัยคนอื่น ๆ ดังนั้นจึงทําให้เกิดคําถาม - Vitalik มีบทบาทอย่างไรในการกํากับดูแล Ethereum?

โดยส่วนตัวแล้วฉันคิดว่ามันมีประโยชน์ที่จะคิดว่า Vitalik เป็น CTO ของ บริษัท ที่มีขนาดใหญ่มาก

(สําหรับวัตถุประสงค์ของการเปรียบเทียบนี้ไม่มีซีอีโอที่ บริษัท นี้โดยวิธีการ)

หากคุณเคยทํางานที่ บริษัท เทคโนโลยีใด ๆ ที่มีพนักงานมากกว่า 50 คนคุณจะรู้ว่า CTO ไม่สามารถมีส่วนร่วมในการตัดสินใจทางเทคนิคทุกครั้ง ในระดับหนึ่งการตัดสินใจทางเทคนิคจําเป็นต้องกระจายอํานาจ - โดยทั่วไปจะมีทีมย่อยสําหรับแต่ละพื้นที่ของผลิตภัณฑ์ของ บริษัท และทีมย่อยส่วนใหญ่มีอิสระในการตัดสินใจของตนเองเกี่ยวกับรายละเอียดการใช้งานเฉพาะ

นอกจากนี้ CTO ไม่จําเป็นต้องเป็นผู้เชี่ยวชาญที่สําคัญที่สุดในทุกเรื่อง (หรือใด ๆ ) อาจมีวิศวกรใน บริษัท ที่ดีกว่า CTO ในพื้นที่เฉพาะ ดังนั้นในเรื่องของการถกเถียงทางเทคนิคมักเป็นวิศวกรที่ตัดสินใจขั้นสุดท้าย

อย่างไรก็ตาม CTO ได้กําหนดวิสัยทัศน์ทางเทคนิคของบริษัท การดําเนินการของวิสัยทัศน์ถูกทิ้งไว้ให้กับนักพัฒนา

แม้ว่านี่จะไม่ใช่การเปรียบเทียบที่สมบูรณ์แบบ แต่ฉันคิดว่ามันจับบทบาทของ Vitalik ในระบบนิเวศได้อย่างสมเหตุสมผล Vitalik ไม่ได้มีส่วนร่วมในการตัดสินใจทางเทคนิคทุกครั้ง — เขาไม่สามารถเป็นได้ เขาไม่ได้เป็นผู้เชี่ยวชาญชั้นนําในทุกด้าน แต่เขามีอิทธิพลอย่างท่วมท้นในการกําหนดแผนงานสําหรับทุกแง่มุมที่สําคัญของ Ethereum (scaling, AA, Proof-of-Stake... ) ไม่เพียงเพราะความเชี่ยวชาญด้านเทคนิคของเขา แต่ยังเป็นเพราะเขาเป็นผู้ตัดสินที่ดีที่สุดว่าแผนงานสอดคล้องกับวิสัยทัศน์ของ Ethereum หรือไม่ - วิสัยทัศน์ของเขา

ผลิตภัณฑ์ที่ประสบความสําเร็จทุกชิ้นเริ่มต้นด้วยวิสัยทัศน์

หาก Vitalik เป็น CTO ของ Ethereum นั้นไม่เป็นที่ถกเถียงกันมากพอสําหรับคุณ

เป็นความเห็นของฉันในฐานะผู้ก่อตั้งสตาร์ทอัพที่อยู่เบื้องหลังผลิตภัณฑ์ที่ประสบความสําเร็จทุกชิ้นและใช่ Ethereum เป็น "ผลิตภัณฑ์" ในแง่ที่ว่ามันแก้ปัญหาที่แท้จริงสําหรับคนจริง - ต้องมีวิสัยทัศน์ที่สอดคล้องกัน และวิสัยทัศน์ที่สอดคล้องกันจะต้องถูกกําหนดโดยคนจํานวนน้อยเช่นผู้ก่อตั้งสตาร์ทอัพและมักจะเป็นผู้ก่อตั้งเพียงคนเดียว

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

แน่นอนว่านี่ไม่ใช่การลดการมีส่วนร่วมของนักวิจัยและวิศวกรคนอื่น ๆ ซึ่งสมควรได้รับเครดิตส่วนใหญ่ในการนํา Ethereum ไปสู่ที่ที่เป็นอยู่ในปัจจุบัน อย่างไรก็ตามนั่นไม่เข้ากันกับความจริงที่ว่า Ethereum คือการตระหนักถึงวิสัยทัศน์ของ Vitalik คําสั่งของขนาดมากกว่าของคนอื่น

และความจริงคุณสามารถบ่นได้หรือไม่? เมื่อคุณถูกดึงดูดเข้าสู่ระบบนิเวศของ Ethereum ด้วยการเปิดกว้างการต่อต้านการเซ็นเซอร์และการก้าวของนวัตกรรม - คุณบ่นว่ามันเริ่มต้นด้วยวิสัยทัศน์ของ Vitalik หรือไม่? บางทีคุณอาจไม่ได้เพราะคุณไม่ได้คิดแบบนั้น - แต่ตอนนี้คุณทําแล้วคุณคิดจริงๆหรือ?

แล้วการกระจายอํานาจล่ะ?

แต่แต่คุณบอกว่าแล้วการกระจายอํานาจล่ะ? หากบุคคลหนึ่งมีอํานาจครอบงํา Ethereum เราจะอ้างว่ามีการกระจายอํานาจได้อย่างไร?

ในการตอบคําถามนี้เราต้องกลับไปที่ @VitalikButerin/the-meaning-of-decentralization-a0c92b76a274">บทความคลาสสิกนี้เกี่ยวกับความหมายของการกระจายอํานาจเขียนโดยไอไอ Vitalik ข้อมูลเชิงลึกที่สําคัญของบทความคือการกระจายอํานาจมีสามประเภท:

• การกระจายอํานาจทางสถาปัตยกรรม: มีกี่โหนดที่สามารถถูกบุกรุกก่อนที่ระบบจะหยุดทํางาน?
• การกระจายอํานาจเชิงตรรกะ: ระบบย่อยของระบบสามารถพัฒนาได้อย่างอิสระในขณะที่ทําให้ระบบทํางานได้หรือไม่? หรือพวกเขาจะต้องประสานงานอย่างใกล้ชิด?
• การกระจายอํานาจทางการเมือง: มีกี่คนหรือองค์กรที่ควบคุมระบบนี้ในที่สุด?

จากคําจํากัดความเหล่านี้ Ethereum มีการกระจายอํานาจทางสถาปัตยกรรมอย่างชัดเจนและอาจเป็นเรื่องยุติธรรมที่จะบอกว่ามีการกระจายอํานาจอย่างมีเหตุผลเนื่องจากขาดการเชื่อมต่อที่แข็งแกร่งระหว่างองค์ประกอบต่างๆ (เช่นฉันทามติกับการดําเนินการ)

ในแง่ของการกระจายอํานาจทางการเมืองข่าวดีก็คือไม่มีบุคคลหรือองค์กรใดสามารถปิด Ethereum ได้แม้แต่ Vitalik อย่างไรก็ตามอาจมีคนโต้แย้งว่า Ethereum ไม่ได้กระจายอํานาจทางการเมืองอย่างที่คิดเนื่องจากบทบาทที่โดดเด่นที่ Vitalik มีบทบาทในการกําหนดวิสัยทัศน์และกําหนดแผนงาน

อย่างไรก็ตามฉันคิดว่าถ้าเราต้องการให้ Ethereum สร้างสรรค์สิ่งใหม่ ๆ ต่อไปเราต้องยอมรับ Vitalik ในฐานะ CTO โดยพฤตินัยแม้ว่าจะหมายถึงการเสียสละการกระจายอํานาจทางการเมืองก็ตาม

หาก Ethereum เคย "ossifies" ในบล็อกเชนที่ไม่เปลี่ยนแปลงส่วนใหญ่เช่น Bitcoin Vitalik ก็สามารถเกษียณได้ แต่ก่อนที่เราจะไปถึงจุดจบนั้นสิ่งสําคัญคือต้องมีอํานาจที่ทุกฝ่ายเคารพซึ่งได้รับความไว้วางใจให้ตัดสินการตัดสินใจทางเทคนิคไม่ได้ขึ้นอยู่กับข้อดีทางเทคนิคเพียงอย่างเดียว แต่ยังขึ้นอยู่กับว่าพวกเขาสอดคล้องกับวิสัยทัศน์ของ Ethereum หรือไม่

หากไม่มีตัวเลขเช่น Vitalik ผลลัพธ์เพียงสองอย่างเท่านั้นที่เป็นไปได้ทั้งสองอย่างแสดงให้เห็นอย่างชัดเจนจากเทพนิยาย 3074 นี้:

• ธรรมาภิบาลของ Ethereum สามารถละลายเป็นกริดล็อกที่ไม่มีที่สิ้นสุดซึ่งทั้งสองฝ่ายไม่เต็มใจที่จะประนีประนอมและไม่มีใครสามารถก้าวหน้าได้ดังที่เห็นได้จากการอภิปราย 3074 ที่ทางตันจนกระทั่ง Vitalik เข้ามา
• หรือ Ethereum อาจกลายเป็นสัตว์ประหลาดแฟรงเกนสไตน์ที่มีการออกแบบที่ไม่สอดคล้องกันตามที่ระบุโดยว่าเราใกล้เคียงกับการมี 3074 และ 4337 ทําหน้าที่เป็นกอง AA คู่ขนานสองกองที่ส่วนใหญ่เข้ากันไม่ได้

บทบาทของชุมชน

เราใกล้จะมีรูปแบบทางจิตที่สมบูรณ์ของการกํากับดูแล Ethereum แต่มีสิ่งหนึ่งที่ละเลยจากการสนทนาของเราจนถึงตอนนี้ นั่นคือชุมชน

หาก Vitalik กําหนดวิสัยทัศน์ซึ่งตามมาด้วยแผนงานที่กําหนดโดยนักวิจัยซึ่งดําเนินการโดยนักพัฒนาหลัก - ชุมชนมีบทบาทอย่างไร? ไม่แน่นอนอะไร??

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

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

โมเดล VVRC ของการกํากับดูแล Ethereum

ดังนั้นที่นี่จึงเป็นแบบจําลองทางจิตที่สมบูรณ์สําหรับการกํากับดูแลของ Ethereum ซึ่งฉันเรียกค่า⇒วิสัยทัศน์⇒แผนงาน⇒โมเดลลูกค้าหรือ VVRC สั้น ๆ :

• V == ค่า == ชุมชน
• V == วิสัยทัศน์ == Vitalik
• R == Roadmaps == นักวิจัย
• C == ลูกค้า == Devs หลัก

พวกเขาทํางานร่วมกันเช่นนี้:

• ชุมชนชุมนุมกันตามค่านิยมบางอย่าง
• Vitalik แสดงวิสัยทัศน์ที่สอดคล้องกับค่านิยมเหล่านี้
• นักวิจัยจัดทําแผนงานตามวิสัยทัศน์
• นักพัฒนาหลักใช้ไคลเอ็นต์ตามแผนงาน

วาดไม่ดีโดย GPT-4o ใหม่
มันปฏิเสธที่จะวาดคําว่า "Vitalik" เนื่องจาก "นโยบายเนื้อหา"

แน่นอนว่าความเป็นจริงนั้นยุ่งเหยิงกว่าโมเดลง่ายๆ ที่สามารถจับภาพได้ ตัวอย่างเช่น devs หลักในความเป็นจริงเป็นคนเดียวที่สามารถ "ลงคะแนน" ในการตัดสินใจใด ๆ โดยอาศัยการใช้ลูกค้า Vitalik และนักวิจัยคนอื่น ๆ ทําหน้าที่ที่ปรึกษาเท่านั้นและบางครั้งข้อมูลของพวกเขาไม่ได้รับการยอมรับจาก devs หลักซึ่งเป็นสาเหตุที่ 3074 ได้รับการอนุมัติ

ที่กล่าวว่าฉันคิดว่าโมเดล VVRC จับได้อย่างสมเหตุสมผลว่าการกํากับดูแล Ethereum ทํางานอย่างไรในกรณีที่มีความสุขและขึ้นอยู่กับเราที่จะ "ดีบัก" กระบวนการเพื่อไม่ให้ล้มเหลวเหมือนที่ทํากับ 3074

เราจะปรับปรุงการกํากับดูแล Ethereum ได้อย่างไร

ตอนนี้เรามีแบบจําลองทางจิตสําหรับวิธีการทํางานของการกํากับดูแล Ethereum นี่คือแนวคิดบางประการสําหรับการปรับปรุงกระบวนการกํากับดูแลเพื่อให้เราสามารถหลีกเลี่ยงประเภทของ whiplash ที่เราประสบกับ 3074/7702

• ต้องมีการมองเห็นมากขึ้นสําหรับ EIPs ที่กําลังได้รับการพิจารณาอย่างแข็งขันเพื่อรวม ชุมชนโดยรวมไม่ควร "ประหลาดใจ" ที่ EIP ได้รับการยอมรับซึ่งเป็นกรณีของ 3074
  • ตรงกันข้ามกับสิ่งที่คุณคาดหวัง "สถานะ" ของ EIP บน ไซต์ EIPs ไม่ได้สะท้อนถึงสถานะในกระบวนการ ACD นั่นเป็นเหตุผลที่ยังคงกล่าวว่า 3074 อยู่ใน "Review" แม้ว่า devs หลักได้ลงมติอนุมัติแล้วและมีข้อบ่งชี้น้อยกว่าที่เคยได้รับการพิจารณาให้รวมไว้ตั้งแต่แรก
  ตาม
  • หลักการแล้ว EF จะทําให้ดังและชัดเจนบนโซเชียลมีเดียเมื่อ EIP กําลังจะได้รับการยอมรับเพื่อเพิ่มการรับรู้ของชุมชน
• บางครั้งผู้พัฒนาหลักสามารถประเมินผลกระทบที่ EIP โดยเฉพาะมีต่อโครงการและผู้ใช้ปลายน้ําซึ่งเป็นกรณีของ 3074 และชุมชน 4337 เนื่องจากการประชุม ACD มีเวลา จํากัด และต้องประสานงานข้ามเขตเวลาจึงเข้าใจได้ว่ามีเพียง "บุคคลที่เกี่ยวข้อง" เท่านั้นที่ควรพูดในที่ประชุม ที่กล่าวว่ามันอาจสมเหตุสมผลที่จะจัดสรรเวลาเป็นระยะ ๆ เพื่อให้สมาชิกในชุมชนแสดงความคิดเห็นเกี่ยวกับผลกระทบปลายน้ําของข้อเสนอ EIP บางอย่าง
  • หากนักวิจัยรู้สึกว่าไม่ได้รับข้อมูลจากนักพัฒนาหลักเช่นเดียวกับทีม 4337 พวกเขาสามารถนําสมาชิกในชุมชนเข้าสู่การโทรเพื่อเสริมสร้างกรณีของพวกเขา
• ที่สําคัญต้องมีการยอมรับร่วมกันระหว่างนักพัฒนาหลักและนักวิจัยว่าพวกเขาทั้งสองเป็นอํานาจในการกํากับดูแลแม้ว่าจะมีจุดแข็งที่แตกต่างกัน "พลังลูกค้า" ของนักพัฒนาหลักเป็นพลังเดียวที่สามารถ "ลงคะแนน" ได้จริงโดยอาศัยการใช้ลูกค้า "พลังแผนงาน" ของนักวิจัยมักจะได้รับการสนับสนุนจากสาธารณชนมากขึ้นเนื่องจากนักวิจัยพูดและเขียนเกี่ยวกับแผนงานของพวกเขาอย่างแข็งขัน
  • เมื่อพลังทั้งสองขัดแย้งกันอาจเป็นเรื่องที่น่าดึงดูดใจสําหรับนักพัฒนาหลักที่จะแทนที่นักวิจัยเช่นเมื่อนักพัฒนาหลักเอาชนะการคัดค้านจากทีม 4337 อย่างไรก็ตามการเอาชนะเช่นนี้อาจส่งผลให้เกิดการวิพากษ์วิจารณ์เนื่องจากอํานาจไม่เสถียรเมื่ออยู่ในความขัดแย้งดังที่เห็นได้จากละครที่ตามมาหลังจาก 3074 ได้รับการอนุมัติ
  • ในทํานองเดียวกันเมื่อต้องเผชิญกับการต่อต้านอาจเป็นสิ่งล่อใจสําหรับนักวิจัยที่จะเลิกมีส่วนร่วมกับ devs หลักซึ่ง IMO เป็นเหตุผลหนึ่งว่าทําไม กระบวนการ RIP ถูกสร้างขึ้นและทําไม AA ดั้งเดิม (7560) จึงถูกผลักดันเป็นหลักในฐานะ RIP ไม่ใช่ EIP แม้ว่าจะมีประโยชน์อย่างแท้จริงในการช่วย L2s ทดลองกับการอัปเดตโปรโตคอลที่เป็นที่ถกเถียงกันมากเกินไปสําหรับ L1 แต่เราไม่สามารถมองว่า RIPs ใช้แทนการมีส่วนร่วมกับกระบวนการกํากับดูแล EIP ได้ นักวิจัยต้องมีส่วนร่วมกับนักพัฒนาหลักต่อไปจนกว่าจะสอดคล้องกับแผนงานอย่างสมบูรณ์

บทสรุป

เทพนิยาย 3074/7702 ให้ความกระจ่างเกี่ยวกับวิธีการทํางานของ Ethereum governance อย่างแท้จริง — นอกเหนือจากอํานาจการกํากับดูแลที่ชัดเจนซึ่งเป็นกระบวนการ EIP/ACD ที่ขับเคลื่อนโดย core devs แล้ว ยังมีพลังการกํากับดูแลโดยนัยของแผนงานที่ขับเคลื่อนโดยนักวิจัยอีกด้วย เมื่อพลังเหล่านี้ไม่ตรงแนวเราจะเห็น gridlocks และ whiplash และอาจใช้พลังอื่น - Vitalik - เพื่อให้สมดุลไม่ทางใดก็ทางหนึ่ง

จากนั้นเราจะทํากรณีที่ Vitalik แสดงถึงพลังที่แตกต่างนั่นคือ "วิสัยทัศน์" ของ Ethereum ซึ่งเป็นพื้นฐานของความชอบธรรมสําหรับแผนงานใด ๆ เราเปรียบเทียบ Vitalik กับ CTO ใน บริษัท ขนาดใหญ่และยอมรับว่าบทบาทของเขาในฐานะ CTO หลอกเป็นสิ่งจําเป็นสําหรับ Ethereum เพื่อให้ทันกับนวัตกรรมโดยไม่เสื่อมสภาพลงในระบบแฟรงเกนสไตน์ของการออกแบบที่ไม่สอดคล้องกัน

สุดท้ายเรานําเสนอแบบจําลองทางจิตสําหรับการคิดเกี่ยวกับการกํากับดูแล Ethereum ในฐานะ VVRC: ค่านิยม (ชุมชน) วิสัยทัศน์⇒ (Vitalik) ⇒แผนงาน (นักวิจัย) ⇒ลูกค้า (ผู้พัฒนาหลัก) จากนั้นเราขอแนะนําวิธีต่างๆในการแก้ไข "ข้อบกพร่อง" ที่บางครั้งทําให้กระบวนการเบี่ยงเบนไปจากแบบจําลองนี้ในทางปฏิบัติ

การกํากับดูแล Ethereum คือ "เครื่องจักรที่สร้างเครื่องจักร" — เพื่อให้ Ethereum ถูกต้องเราต้องได้รับการกํากับดูแลที่ถูกต้อง ด้วยเหตุนี้ 3074 จึงให้กรณีศึกษาอันล้ําค่าเมื่อการกํากับดูแลผิดพลาดและฉันหวังว่าฉันจะสามารถดึงบทเรียนที่เป็นประโยชน์จากมันเพื่อให้เราสามารถปรับปรุงการกํากับดูแล Ethereum ได้ในอนาคต

ข้อจํากัดความรับผิดชอบ:

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