Vitalik dan Yoav dengan ramah meninjau posting ini, tetapi pendapat adalah milik saya sendiri.

Jika Anda belum mengikuti drama AA, berikut rekap singkatnya:

• Beberapa minggu yang lalu, EIP-3074, sebuah proposal yang akan membawa banyak manfaat AA bagi pengguna EOA, disetujui oleh pengembang inti untuk masuk ke "Pectra," fork keras Ethereum berikutnya.
• Sejak saat itu, banyak di komunitas ERC-4337, terutama penulis 4337 sendiri, telah sangat mendorong kembali pada 3074, dengan alasan @yoav/3074-implikasi">masalah sentralisasi dan ketidakcocokannya dengan Ethereum @yoav/AA-roadmap-May-2024">AA roadmap, yang berpusat di sekitar 4337 dan sepupunya 7560 (alias "AA asli").
• Pekan lalu, Vitalik mengusulkan EIP-7702 sebagai alternatif dari 3074. Ini sebagian besar mencapai tujuan yang sama – membawa banyak manfaat AA bagi pengguna EOA – tetapi dengan cara yang lebih kompatibel dengan 4337 hari ini, dan kompatibel ke depan dengan "AA endgame" yaitu 7560.
• Pada saat ini, pengembang inti sedang mempertimbangkan EIP-7702, tetapi diskusi awal dan sentimen komunitas menunjukkan bahwa EIP-7702 kemungkinan besar akan menggantikan EIP-3074 di Pectra.

Secara pribadi, saya sangat senang dengan hasilnya: pengguna EOA akan segera dapat menikmati sebagian besar manfaat AA, menggunakan perkakas dan infra yang dibuat untuk ERC-4337.

Namun, saya tidak bisa tidak merasa bahwa cara kami mencapai hasil ini jauh dari optimal, pandangan yang telah diungkapkan banyak orang dalam beberapa minggu terakhir. Saya merasa bahwa dengan proses yang lebih baik, kita bisa secara kolektif menghemat sejumlah besar energi dan sakit kepala, dan sampai pada hasil yang diinginkan lebih cepat.

Dalam posting blog ini, saya ingin:

• Identifikasi apa yang salah dengan prosesnya.
• Usulkan model mental untuk memikirkan pemerintahan Ethereum.
• Menyarankan perbaikan untuk menghindari kegagalan tata kelola serupa di masa depan.

Mengapa prosesnya membuat orang tidak bahagia

Seluruh kisah ini membuat banyak orang tidak bahagia karena beberapa alasan:

• Butuh waktu bertahun-tahun untuk 3074 disetujui.
• Hanya setelah 3074 akhirnya disetujui, apakah pengembang inti mendapatkan banyak penolakan dari komunitas 4337.
  • 4337 penulis sendiri, di sisi lain, telah berulang kali menyuarakan keprihatinan mereka dengan 3074 untuk pengembang inti, tetapi tidak berhasil.
• Sekarang kita berada di jalur untuk membatalkan persetujuan 3074 dan menggantinya dengan EIP lain (7702).

Sekarang, tidak ada yang salah dengan hal-hal di atas:

• Tidak apa-apa untuk diskusi memakan waktu bertahun-tahun.
• Tidak apa-apa bagi EIP untuk menerima pushback setelah disetujui.
• Tidak apa-apa untuk membatalkan persetujuan EIP setelah disetujui, jika masalah baru teridentifikasi.

Namun, kita mungkin bisa sepakat bahwa segala sesuatunya bisa berjalan lebih lancar. Bayangkan jika beginilah hasilnya:

• Komunitas 4337 secara aktif melibatkan pengembang inti saat mereka memperdebatkan 3074. Sekarang, hanya satu dari dua hasil yang mungkin:
  • Entah 3074 disetujui (dan mungkin dimodifikasi) setelah mengambil umpan balik komunitas 4337 ke dalam akun, dalam hal ini komunitas 4337 akan bergabung dengan 3074 dan kami tidak akan membalikkan 3074.
  • Atau, 3074 tidak pernah disetujui, tetapi komunitas 4337 dan pengembang inti bekerja sama menuju proposal yang disukai semua orang, à la 7702.

Suara semua orang terdengar, dan tidak ada pembalikan dramatis. Itu akan menyenangkan - jadi mengapa itu tidak terjadi?

Apa yang salah?

Berkaca pada prosesnya, kedua sisi perdebatan saling menuding.

Pengembang inti (dan penulis EIP-3074) merasa bahwa itu adalah kesalahan "4337 orang" bahwa mereka tidak secara aktif terlibat dengan proses All Core Devs (ACD), di mana EIP dipertimbangkan untuk waktu yang long sebelum akhirnya diterima oleh tim klien, dan dengan demikian diimplementasikan ke dalam protokol.

Pada titik mana pun selama musyawarah ini, argumennya berlanjut, "4337 orang" bisa saja masuk dan menyatakan keprihatinan mereka, daripada menunggu sampai setelah 3074 telah disetujui. Bagaimanapun, proses ACD didokumentasikan dengan baik, pertemuan terbuka untuk semua, dan ada orang-orang seperti Tim Beiko yang secara aktif men-tweet ringkasan setelah setiap pertemuan ACD. Jadi jika 4337 orang sangat peduli dengan masalah ini, mengapa mereka tidak menghabiskan waktu untuk terlibat?

Di sisi lain, tim AA (4337 penulis) menunjukkan bahwa mereka telah menghadiri pertemuan ACD dan mendorong kembali 3074 setiap kesempatan yang mereka bisa, tetapi pengembang inti tidak mendengarkan. Adapun komunitas 4337, mereka kebanyakan merasa dibutakan - kebanyakan orang mendapat kesan bahwa 3074 sudah mati, dan bahkan tidak menyadari bahwa 3074 sedang dipertimbangkan secara aktif untuk dimasukkan.

Banyak orang juga merasa bahwa proses ACD terlalu buram dan tidak ramah untuk partisipasi dari orang-orang yang memiliki "pekerjaan nyata" dan tidak mampu mengikuti semua pembaruan ACD. Beberapa juga merasa bahwa itu harus menjadi tanggung jawab ACD untuk secara aktif mencari umpan balik dari pemangku kepentingan terkait, dalam hal ini komunitas 4337.

Ini pendapat saya, bagaimanapun, bahwa kedua belah pihak meleset dari sasaran. Ada masalah yang jauh lebih dalam di tempat kerja, dan sampai kita memperbaiki atau setidaknya mengakui masalah ini, kita akan terus mengalami kegagalan tata kelola diikuti oleh tudingan jari yang tidak produktif.

Akar Penyebab

Penyebab sebenarnya dari kegagalan tata kelola adalah bahwa, bertentangan dengan kepercayaan populer, ACD BUKAN satu-satunya kekuatan tata kelola untuk pembaruan protokol, dan dalam hal ini ditimpa oleh kekuatan tata kelola lain.

Secara problematis, kekuatan tata kelola lainnya jarang diakui, terlepas dari kenyataan bahwa ia memiliki pengaruh yang lebih besar daripada ACD pada hal-hal terpenting Ethereum, seperti AA dan penskalaan.

Pada artikel ini, saya akan menyebut kekuatan ini "peta jalan".

Seluruh kisah 3074/7702 ini, seperti yang akan saya katakan, tidak lebih dan tidak kurang dari contoh kekuatan peta jalan yang membanjiri kekuatan ACD. Dan jika kita berbicara tentang pemerintahan, maka setiap kali kita melihat kekuatan tak terlihat membanjiri kekuatan yang terlihat, kita harus sangat prihatin, karena apa yang tidak terlihat tidak dapat dipertanggungjawabkan, dan karena itu harus dibawa ke cahaya.

Apa itu roadmap?

Siapa pun di komunitas Ethereum pasti sering menemukan istilah "peta jalan", seperti dalam "peta jalan rollup-sentris," "peta jalan ETH 2.0," atau dalam debat ini "@yoav/AA-roadmap-May-2024">the AA roadmap."

Pencarian "peta jalan" di Ethereum Magicians

Untuk mengilustrasikan poin saya, mari kita bayangkan pertemuan ACD di mana pengembang inti mendiskusikan cara menskalakan Ethereum:

• Core Dev Bob: Saya dukungan EIP 1234 yang mengusulkan agar kita mempercepat waktu blok 10X, meningkatkan ukuran blok 10X &; biaya Drop 100X.
• Pengembang inti lainnya: ... Apakah Anda keluar dari * pikiran Anda?

Mari kita berpikir sejenak di sini. Mengapa pengembang inti baru saja menembak jatuh apa yang dikatakan Bob? Dia baru saja mengusulkan bentuk penskalaan yang sangat sah. Solana dan banyak L1 lainnya melakukannya, untuk efek penskalaan yang hebat.

Alasannya, tentu saja, adalah bahwa EIP imajiner ini bertentangan dengan peta jalan penskalaan "rollup-centric" milik Ethereum, yang mengatakan, antara lain, bahwa sangat penting untuk desentralisasi blockchain bagi pengguna biasa untuk dapat menjalankan node, dan oleh karena itu EIP imajiner tidak mungkin karena akan sangat meningkatkan penghalang untuk menjalankan node.

Apa yang ingin saya ilustrasikan dengan contoh ini adalah bahwa pengembang inti, yang berpartisipasi dalam proses ACD dan memutuskan pembaruan protokol, dipandu oleh kekuatan yang lebih tinggi yang saya sebut peta jalan. Ada peta jalan penskalaan, peta jalan AA, peta jalan MEV, sebut saja — dan secara kolektif mereka membentuk peta jalan Ethereum yang menjadi dasar keputusan para pengembang inti.

Ketika core devs tidak selaras dengan roadmap

Karena roadmap bukan bagian formal dari tata kelola, tidak ada jaminan bahwa core dev selaras dengan mereka. Secara khusus, karena tidak ada proses formal untuk "menyetujui" peta jalan, tidak semua peta jalan dianggap memiliki legitimasi yang sama. Terserah para peneliti di balik peta jalan untuk dengan tekun memperjuangkan peta jalan mereka ke pengembang inti dan komunitas yang lebih besar, di pesanan untuk mendapatkan legitimasi dan karena itu dukungan dari pengembang inti.

Dalam kasus AA, Vitalik sendiri telah mendorong roadmap AA 4337-sentris pada @vbuterin/akun_abstraction_roadmap">multiple occasions, tetapi secara keseluruhan sebagian besar adalah tim 4337, terutama Yoav dan Dror, yang memperjuangkan roadmap AA 4337-sentris di konferensi, forum online, dan pertemuan ACD.

Namun, terlepas dari upaya ini, ada tentangan kuat dari beberapa pengembang inti terhadap peta jalan AA 4337-sentris. Mereka merasa bahwa 7560, versi asli 4337 yang pada akhirnya harus diterapkan oleh klien, terlalu rumit dan bukan satu-satunya kandidat yang layak untuk "permainan akhir AA." Akhirnya ACD memutuskan untuk menyetujui 3074 meskipun tim 4337 keberatan bahwa itu akan memecah ekosistem AA dengan menciptakan alternatif dan @yoav/3074-implikasi">tumpukan teknologi AA yang kurang terdesentralisasi.

Namun, setelah 3074 disetujui, ada reaksi keras dari seluruh komunitas 4337, yang memaksa pengembang inti untuk terlibat kembali dalam debat 3074. Perdebatan kemudian menjadi jalan buntu di mana baik 4337 penulis maupun 3074 penulis tidak dapat meyakinkan satu sama lain, sampai Vitalik datang pada jam kesebelas dan mengusulkan EIP-7702 sebagai alternatif untuk 3074 yang secara eksplisit kompatibel dengan "AA endgame" 4337-sentris, dan dengan demikian mendorong konflik mendukung peta jalan AA.

Peran Vitalik

Meskipun Vitalik membawa dirinya sebagai peneliti, kisah ini jelas menunjukkan bahwa Vitalik membawa kekuatan tata kelola yang berbeda secara kualitatif dari peneliti lain. Jadi itu menimbulkan pertanyaan – peran apa yang dimainkan Vitalik dalam pemerintahan Ethereum?

Secara pribadi, saya merasa terbantu untuk memikirkan Vitalik sebagai CTO dari perusahaan yang sangat, sangat besar.

(Untuk tujuan analogi ini, tidak ada CEO di perusahaan ini, omong-omong.)

Jika Anda telah bekerja di perusahaan teknologi mana pun dengan lebih dari, katakanlah, 50 orang, Anda tahu bahwa CTO tidak mungkin terlibat dalam setiap keputusan teknis. Pada skala tertentu, keputusan teknis harus menjadi terdesentralisasi – biasanya ada sub tim untuk setiap area produk perusahaan, dan sub tim sebagian besar bebas untuk membuat keputusan sendiri mengenai detail implementasi tertentu.

Selain itu, CTO juga belum tentu ahli terkemuka dalam setiap (atau apapun) materi pelajaran. Mungkin ada insinyur di perusahaan yang lebih baik daripada CTO di bidang tertentu. Oleh karena itu, dalam hal perdebatan teknis, seringkali para insinyur yang membuat keputusan akhir.

Namun, CTO menetapkan visi teknis perusahaan. Eksekusi visi diserahkan kepada para pengembang.

Meskipun ini bukan analogi yang sempurna, saya pikir ini cukup menangkap peran Vitalik dalam ekosistem. Vitalik tidak terlibat dalam setiap keputusan teknis – dia tidak mungkin. Dia juga bukan ahli top di setiap bidang. Tetapi dia memiliki pengaruh luar biasa dalam menetapkan peta jalan untuk semua aspek penting Ethereum (penskalaan, AA, Proof-of-Stake...), bukan hanya karena keahlian teknisnya, tetapi juga karena dia adalah hakim utama apakah peta jalan konsisten dengan visi Ethereum - visinya.

Setiap produk yang sukses dimulai dengan visi

Jika pendapat saya bahwa Vitalik adalah CTO Ethereum tidak cukup kontroversial untuk Anda, inilah bagian yang paling kontroversial: kita harus merangkul Vitalik sebagai CTO.

Ini pendapat saya sebagai pendiri startup bahwa di balik setiap produk yang sukses – dan ya Ethereum adalah "produk" dalam arti bahwa itu memecahkan masalah nyata bagi orang-orang nyata – harus ada visi yang koheren. Dan visi yang koheren harus ditetapkan oleh sejumlah kecil orang, seperti pendiri startup, dan seringkali hanya satu pendiri.

Keindahan Ethereum adalah bahwa, meskipun itu adalah sistem yang kompleks dengan begitu banyak bagian yang bergerak, bagian-bagiannya cocok dengan indah bersama-sama menjadi komputer terdesentralisasi yang berfungsi yang memindahkan nilai miliaran dolar setiap hari. Dan cara kami sampai di sini tidak melalui desain oleh panitia. Justru karena kepemimpinan aktif Vitalik melalui visinya, kami dapat mencapai produk yang koheren dan indah yang Ethereum saat ini. Ethereum adalah gagasan Vitalik pada tahun 2015, dan tetap demikian sampai sekarang.

Ini tentu saja bukan untuk mengecilkan kontribusi para peneliti dan insinyur lain, yang pantas mendapatkan sebagian besar kredit karena membawa Ethereum ke tempat seperti sekarang ini. Namun, itu tidak bertentangan dengan fakta bahwa Ethereum adalah realisasi dari visi Vitalik, urutan besarnya lebih dari orang lain.

Dan sejujurnya, bisakah Anda mengeluh? Ketika Anda tertarik ke ekosistem Ethereum oleh keterbukaan, resistensi sensor, dan kecepatan inovasi - apakah Anda mengeluh bahwa itu dimulai dengan visi Vitalik? Mungkin Anda tidak melakukannya karena Anda tidak memikirkannya seperti itu - tetapi sekarang setelah Anda melakukannya, apakah Anda benar-benar keberatan?

Bagaimana dengan desentralisasi?

Tapi tapi, katamu, bagaimana dengan desentralisasi? Jika satu orang memiliki kekuatan yang luar biasa atas Ethereum, bagaimana kita bisa mengklaim bahwa itu terdesentralisasi?

Untuk menjawab pertanyaan ini, kita harus kembali ke @VitalikButerin/the-meaning-of-decentralization-a0c92b76a274">artikel klasik tentang arti desentralisasi, ditulis oleh, batuk batuk, Vitalik. Wawasan utama dari artikel ini adalah bahwa ada tiga jenis desentralisasi:

• Desentralisasi arsitektur: berapa banyak node yang dapat dikompromikan sebelum sistem berhenti berfungsi?
• Desentralisasi logis: dapatkah subsistem sistem berkembang secara independen sambil menjaga sistem berfungsi? Atau haruskah mereka dikoordinasikan secara erat?
• Desentralisasi politik: berapa banyak orang atau organisasi yang akhirnya mengendalikan sistem ini?

Dengan definisi ini, Ethereum jelas terdesentralisasi secara arsitektural, dan mungkin adil untuk mengatakan bahwa itu juga terdesentralisasi secara logis, mengingat kurangnya kopling yang kuat antara berbagai komponennya (misalnya konsensus vs eksekusi).

Dalam hal desentralisasi politik, kabar baiknya adalah bahwa tidak ada individu atau organisasi yang dapat menutup Ethereum, bahkan Vitalik. Namun, orang dapat berargumen bahwa Ethereum tidak terdesentralisasi secara politis seperti yang dipikirkan orang, mengingat peran penting yang dimainkan Vitalik dalam menetapkan visinya dan dengan demikian menentukan peta jalannya.

Namun, menurut pendapat saya bahwa jika kita ingin Ethereum terus berinovasi, kita harus merangkul Vitalik sebagai CTO de facto, bahkan jika itu berarti mengorbankan beberapa desentralisasi politik.

Jika Ethereum pernah "mengeras" menjadi blockchain yang sebagian besar tidak berubah seperti Bitcoin, maka Vitalik bisa pensiun. Tetapi sebelum kita mencapai permainan akhir itu, sangat penting bahwa ada otoritas yang dihormati semua pihak, yang dipercaya untuk membuat penilaian atas keputusan teknis tidak berdasarkan manfaat teknis saja, tetapi juga pada apakah mereka konsisten dengan visi Ethereum.

Tanpa sosok seperti Vitalik, hanya dua hasil yang mungkin, keduanya diilustrasikan dengan jelas oleh kisah 3074 ini:

• Ethereum pemerintahan dapat larut dalam kemacetan tanpa akhir di mana tidak ada pihak yang mau berkompromi dan tidak ada yang bisa membuat kemajuan, seperti yang terlihat dari bagaimana debat 3074 menemui jalan buntu sampai Vitalik masuk.
• Atau, Ethereum bisa berakhir menjadi monster Frankenstein dengan desain yang tidak koheren, seperti yang ditunjukkan oleh seberapa dekat kita memiliki 3074 dan 4337 yang berfungsi sebagai dua tumpukan AA paralel yang sebagian besar tidak kompatibel.

Peran komunitas

Kami sangat dekat untuk memiliki model mental yang lengkap tentang tata kelola Ethereum, tetapi ada satu kelalaian mencolok dari diskusi kami sejauh ini - komunitas.

Jika Vitalik mendefinisikan visi, yang diikuti oleh peta jalan yang ditentukan oleh para peneliti, yang pada gilirannya dilaksanakan oleh pengembang inti - peran apa yang dimainkan masyarakat? Tentunya bukan apa-apa??

Untungnya, komunitas benar-benar memainkan peran yang paling penting dari semuanya. Alasannya adalah bahwa bahkan sebelum ada visi, ada nilai-nilai. Kami semua berkumpul sebagai sebuah komunitas karena kami bersatu di sekitar nilai-nilai tertentu, yang pada akhirnya visi Vitalik harus konsisten dengan, atau akan kehilangan komunitas.

Mungkin itu asuhan Anda. Mungkin itu adalah sesuatu yang terjadi dalam pekerjaan terakhir Anda. Tetapi pada satu titik atau lainnya, kita semua di komunitas Ethereum memutuskan bahwa akan baik bagi dunia untuk memiliki komputer terdesentralisasi yang dapat diakses oleh semua orang, yang tidak dapat disensor, yaitu netral secara kredibel. Kami menegaskan dan menegaskan nilai-nilai ini setiap hari dengan pekerjaan yang kami lakukan di atas Ethereum, dan dengan demikian kami memberikan legitimasi terhadap visi, peta jalan, dan kode yang dihasilkan oleh Vitalik, peneliti, dan pengembang inti.

Model VVRC dari tata kelola Ethereum

Jadi di sini, kemudian, adalah model mental lengkap untuk tata kelola Ethereum, yang saya sebut nilai-nilai ⇒ visi ⇒ peta jalan ⇒ model klien, atau VVRC untuk short:

• V == Nilai == Komunitas
• V == Visi == Vitalik
• R == Peta Jalan == Peneliti
• C == Klien == Pengembang Inti

Bersama-sama mereka bekerja seperti ini:

• Komunitas berkumpul di sekitar nilai-nilai tertentu.
• Vitalik mengartikulasikan visi yang konsisten dengan nilai-nilai ini.
• Para peneliti datang dengan peta jalan sesuai dengan visi.
• Pengembang inti mengimplementasikan klien berdasarkan peta jalan.

Buruk ditarik oleh GPT-4o baru.
Itu menolak untuk menggambar kata "Vitalik" karena "kebijakan konten."

Tentu saja, kenyataannya jauh lebih berantakan daripada yang bisa ditangkap oleh model sederhana mana pun. Misalnya, pengembang inti pada kenyataannya adalah satu-satunya orang yang dapat "memilih" pada keputusan apa pun, berdasarkan penerapan klien. Vitalik dan peneliti lain hanya melayani peran penasehat, dan terkadang masukan mereka tidak diterima oleh pengembang inti, itulah sebabnya 3074 disetujui.

Yang mengatakan, saya pikir model VVRC cukup menangkap bagaimana tata kelola Ethereum bekerja dalam kasus bahagia, dan terserah kita untuk "men-debug" proses sehingga tidak gagal seperti yang terjadi dengan 3074.

Bagaimana kita bisa meningkatkan tata kelola Ethereum

Sekarang kita memiliki model mental tentang bagaimana tata kelola Ethereum harus bekerja, berikut adalah beberapa ide untuk meningkatkan proses tata kelola sehingga kita dapat menghindari jenis whiplash yang kita alami dengan 3074/7702.

• Harus ada lebih banyak visibilitas untuk EIP yang secara aktif dipertimbangkan untuk dimasukkan. Masyarakat luas seharusnya tidak pernah "terkejut" bahwa EIP diterima, seperti halnya dengan 3074.
  • Bertentangan dengan apa yang mungkin Anda harapkan, "status" EIP pada situs EIP tidak mencerminkan statusnya dalam proses ACD. Itu sebabnya masih dikatakan 3074 ada di "Review" meskipun pengembang inti telah memilih untuk menyetujuinya, dan bahkan ada sedikit indikasi bahwa itu pernah dipertimbangkan untuk dimasukkan di tempat pertama.
  • Idealnya, EF akan membuatnya keras dan jelas di media sosial ketika sebuah EIP akan diterima, untuk meningkatkan kesadaran masyarakat.
• Terkadang pengembang inti dapat meremehkan dampak EIP tertentu terhadap proyek &; pengguna hilir, seperti halnya dengan komunitas 3074 dan 4337. Karena pertemuan ACD terbatas dalam waktu dan harus berkoordinasi lintas zona waktu, dapat dimengerti bahwa hanya "orang yang relevan" yang boleh berbicara di pertemuan. Yang mengatakan, masuk akal untuk mengalokasikan waktu, sesekali, bagi anggota masyarakat untuk mengomentari dampak hilir dari proposal EIP tertentu.
  • Jika peneliti merasa bahwa masukan mereka tidak diterima oleh pengembang inti, seperti halnya dengan tim 4337, mereka dapat membawa anggota masyarakat ke dalam panggilan untuk memperkuat kasus mereka.
• Yang terpenting, harus ada saling pengakuan antara pengembang inti dan peneliti bahwa mereka berdua adalah kekuatan tata kelola, meskipun dengan kekuatan yang berbeda. "Kekuatan klien" dari pengembang inti adalah satu-satunya kekuatan yang benar-benar dapat "memilih" berdasarkan implementasi klien. "Kekuatan peta jalan" para peneliti biasanya menikmati lebih banyak dukungan publik berkat para peneliti yang secara aktif berbicara dan menulis tentang peta jalan mereka.
  • Ketika kedua kekuatan berselisih, mungkin tergoda bagi pengembang inti untuk hanya mengesampingkan para peneliti, seperti ketika pengembang inti mengesampingkan keberatan dari tim 4337. Namun, mengesampingkan hal itu dapat mengakibatkan whiplash karena kekuatan tidak stabil ketika mereka berada dalam konflik, seperti yang terlihat dari drama berikutnya setelah 3074 disetujui.
  • Demikian pula, ketika dihadapkan dengan resistensi, mungkin tergoda bagi para peneliti untuk menyerah begitu saja terlibat dengan pengembang inti, yang IMO adalah salah satu alasan mengapa proses RIP dibuat dan mengapa AA asli (7560) sekarang terutama didorong sebagai RIP, bukan EIP. Meskipun ada manfaat nyata untuk membantu L2 bereksperimen dengan pembaruan protokol yang terlalu kontroversial untuk L1, kami tidak dapat melihat RIP sebagai pengganti untuk terlibat dengan proses tata kelola EIP. Para peneliti harus terus terlibat dengan pengembang inti sampai mereka sepenuhnya selaras dengan peta jalan.

Kesimpulan

Kisah 3074/7702 menyoroti bagaimana tata kelola Ethereum benar-benar bekerja — bahwa selain kekuatan tata kelola eksplisit yang merupakan proses EIP/ACD yang didorong oleh pengembang inti, ada juga kekuatan tata kelola implisit dari peta jalan yang didorong oleh para peneliti. Ketika kekuatan-kekuatan ini menjadi tidak sejajar, kita melihat kemacetan dan whiplash, dan itu bisa mengambil kekuatan lain - Vitalik - untuk memberi tip keseimbangan dengan satu atau lain cara.

Kami kemudian membuat kasus bahwa Vitalik mewakili kekuatan yang berbeda yang merupakan "visi" Ethereum, yang merupakan dasar legitimasi untuk peta jalan apa pun. Kami membandingkan Vitalik dengan CTO di sebuah perusahaan besar, dan mengakui bahwa perannya sebagai pseudo-CTO diperlukan bagi Ethereum untuk menjaga laju inovasinya, tanpa merosot menjadi sistem Frankenstein dengan desain yang tidak koheren.

Akhirnya, kami menyajikan model mental untuk berpikir tentang tata kelola Ethereum sebagai VVRC: nilai (komunitas) ⇒ visi (Vitalik) ⇒ peta jalan (peneliti) ⇒ klien (pengembang inti). Kami kemudian menyarankan berbagai cara untuk memperbaiki "bug" yang terkadang menyebabkan proses menyimpang dari model ini dalam praktiknya.

Ethereum tata kelola adalah "mesin yang membangun mesin" — untuk mendapatkan Ethereum dengan benar, kita harus mendapatkan tata kelola yang benar. Dengan demikian, 3074 memberikan studi kasus yang sangat berharga ketika tata kelola salah, dan saya harap saya dapat menarik beberapa pelajaran bermanfaat darinya sehingga kami dapat meningkatkan tata kelola Ethereum untuk masa depan.

Penafian:

1. Artikel ini dicetak ulang dari [zerodev]. Semua hak cipta adalah milik penulis asli [derek]. Jika ada keberatan dengan cetak ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
2. Penafian Kewajiban: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata milik penulis dan bukan merupakan saran investasi.
3. Penerjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.