Meneruskan judul asli 'Refleksi tentang Tata Kelola Ethereum Mengikuti 3074 Saga'

Abstrak: Artikel ini adalah pernyataan dari Derek Chiang, CEO ZeroDev, sebagai tanggapan atas proposal V tentang EIP-7702 untuk menyeimbangkan kontradiksi antara ERC-4337 dan EIP-3074. Ditulis dari perspektif pendiri proyek dalam ekosistem AA, secara obyektif menyoroti model tata kelola Ethereum saat ini dan poin rasa sakitnya. Derek dengan ringkas menunjukkan:

Salah satu konflik tata kelola Ethereum terletak pada perbedaan antara peta jalan yang ditentukan oleh para peneliti dan perspektif tim pengembangan klien seperti Geth. Vitalik, bertindak dalam peran yang mirip dengan CTO, akhirnya menjadi faktor penentu.

Setelah menegaskan peran Vitalik, Derek menguraikan perbaikan yang harus dilakukan Ethereum pada model tata kelolanya, menawarkan wawasan berharga bagi komunitas Ethereum dan Bitcoin.

Teks:

Jika Anda tidak terbiasa dengan peristiwa seputar Abstraksi Akun Ethereum (AA) sebelumnya, berikut adalah rekap singkatnya: Beberapa minggu yang lalu, proposal EIP-3074 disetujui oleh pengembang inti Ethereum untuk dimasukkan dalam hard fork berikutnya, "Pectra". Proposal ini memperkenalkan dua opcode baru ke Ethereum Virtual Machine (EVM), memungkinkan Ethereum Externally Owned Accounts (EOAs) untuk memiliki pengalaman AA yang hampir asli. Sejak itu, banyak anggota komunitas ERC-4337, terutama para pendukungnya, sangat menentang EIP-3074, dengan alasan kekhawatiran tentang potensi risiko keamanan dan ketidakcocokannya dengan peta jalan AA Ethereum. Dalam peta jalan Ethereum sebelumnya, ERC-4337 dan proposal serupa seperti 7560 (juga dikenal sebagai "nativeAA") adalah pusat. Pada awal Mei, Vitalik mengusulkan EIP-7702 sebagai alternatif untuk EIP-3074, mencapai keseimbangan antara 4337 dan 3074 — memberikan pengalaman AA bagi pengguna EOA sambil mempertahankan kompatibilitas dengan ERC-4337 sampai batas tertentu, serta kompatibilitas dengan "solusi AA akhir" 7560. Saat ini, pengembang inti Ethereum sedang mempertimbangkan implikasi EIP-7702, dan diskusi awal dan sentimen komunitas menunjukkan bahwa EIP-7702 kemungkinan akan menggantikan EIP-3074 yang disebutkan sebelumnya. Saya sangat puas dengan hasil ini: pengguna EOA akan segera dapat merasakan berbagai produk dalam ekosistem ERC-4337 dan menikmati sebagian besar manfaat AA. Namun, saya tidak bisa tidak merasa bahwa mungkin ada cara yang lebih baik untuk mencapai hasil ini, seperti yang telah ditunjukkan banyak orang dalam beberapa minggu terakhir. Saya percaya bahwa dengan proses tata kelola yang lebih baik, kita bisa menghemat banyak energi dan mencapai hasil yang diinginkan lebih cepat. Dalam artikel ini, saya ingin:

• Identifikasi apa yang salah dalam proses tata kelola
• Mengusulkan model pemikiran untuk tata kelola Ethereum
• Tawarkan saran untuk perbaikan untuk menghindari kecelakaan tata kelola serupa di masa depan

Kesimpulan dan Refleksi Insiden EIP-3074

Kisah yang disebutkan di atas telah membuat banyak orang tidak senang karena beberapa alasan: EIP-3074 membutuhkan waktu beberapa tahun untuk disetujui. Setelah 3074 akhirnya disetujui, pengembang inti Ethereum menghadapi tentangan kuat dari komunitas 4337. Di sisi lain, penulis ERC-4337 berulang kali menyatakan keprihatinan mereka tentang EIP-3074 kepada tim inti Ethereum, tetapi tidak berhasil. Sekarang Ethereum berencana untuk membatalkan persetujuan 3074 dan menggantinya dengan EIP lain (7702). Tidak ada yang salah dengan poin apa pun dalam proses yang disebutkan di atas:

• Itu normal untuk diskusi tentang EIP memakan waktu beberapa tahun.
• Itu normal untuk EIP yang disetujui ditolak sesudahnya.
• Jika masalah baru ditemukan, persetujuan EIP dapat dicabut setelah persetujuan.

Namun, semuanya bisa lebih lancar. Mari kita bayangkan jika hal-hal telah berkembang seperti ini: selama diskusi 3074, komunitas 4337 secara aktif terlibat dengan pengembang inti Ethereum. Jika premis ini benar, maka hanya ada dua kemungkinan hasil:

• Setelah mempertimbangkan umpan balik dari komunitas 4337, proposal 3074 disetujui (dan mungkin dimodifikasi). Dalam hal ini, komunitas 4337 akan menerima 3074, dan tim inti Ethereum tidak perlu mencabut 3074.
• Atau, 3074 tidak pernah disetujui, tetapi komunitas 4337 dan tim inti Ethereum bersama-sama mengusulkan solusi yang memuaskan semua orang, mirip dengan 7702. Suara semua orang didengar, dan tidak ada pembalikan dramatis. Ini akan ideal — jadi mengapa itu tidak terjadi?

Apa yang salah?

Melihat kembali keseluruhan proses, kedua sisi acara saling menyalahkan. Pengembang inti Ethereum (serta penulis EIP-3074) percaya itu adalah kesalahan "pendukung 4337" karena mereka tidak berpartisipasi aktif dalam proses diskusi All Core Developers (ACD). Dalam proses ini, EIP perlu menjalani pertimbangan panjang dan akhirnya diterima dan diimplementasikan oleh tim pengembangan klien Ethereum seperti Geth. Beberapa berpendapat bahwa selama periode ketika EIP-3074 sedang dipertimbangkan, "4337 pendukung" dapat berpartisipasi dan mengekspresikan pandangan mereka, alih-alih mengkritiknya setelah disetujui. Bagaimanapun, seluruh proses ACD transparan, rapat terbuka untuk semua orang, dan individu seperti Tim Beiko secara konsisten menerbitkan tweet ringkasan setelah setiap rapat ACD. Jadi, jika "4337 pendukung" sangat peduli dengan topik tersebut, mengapa mereka tidak secara aktif dan segera berpartisipasi dalam pertemuan yang relevan?

Di sisi lain, anggota inti 4337 menunjukkan bahwa mereka telah berpartisipasi dalam pertemuan ACD dan menentang 3074 sebanyak mungkin, tetapi pengembang inti Ethereum tidak mendengarkan. Adapun 4337 anggota komunitas, banyak yang merasa buta — banyak yang mengira 3074 sudah mati, dan beberapa bahkan tidak menyadari bahwa 3074 kemungkinan akan disetujui. Banyak yang menunjukkan bahwa seluruh proses pertemuan ACD buram dan tidak ramah bagi mereka yang "serius" di komunitas Ethereum tetapi tidak dapat mengikuti pembaruan ACD secara real-time. Beberapa juga percaya bahwa ACD harus secara aktif mencari umpan balik dari pemangku kepentingan (di sini mengacu pada komunitas 4337).

Namun, saya yakin tidak ada pihak yang tepat sasaran. Ada masalah yang lebih dalam di balik ini, dan kecuali kita mengatasi atau setidaknya mengakui masalah ini, kita akan terus jatuh ke dalam kecelakaan pemerintahan, diikuti oleh tuduhan kontradiktif dari kedua belah pihak, yang pada akhirnya tidak ada artinya.

Akar penyebab kecelakaan tata kelola: peta jalan

Berlawanan dengan kepercayaan populer, akar penyebab kecelakaan tata kelola terletak pada kenyataan bahwa ACD bukan satu-satunya otoritas tata kelola untuk pembaruan protokol Ethereum; Itu telah digantikan oleh otoritas pemerintahan lain. Masalahnya di sini adalah bahwa, meskipun memiliki pengaruh lebih dari ACD pada masalah inti Ethereum (seperti AA dan skalabilitas), otoritas tata kelola lainnya ini jarang diakui. Dalam artikel ini, saya akan merujuk pada jenis kekuatan ini sebagai "peta jalan." Seperti yang akan saya tunjukkan di bawah, seluruh peristiwa kegagalan tata kelola "3074-4337-7702" adalah kasus kekuatan peta jalan Ethereum yang ada yang mengesampingkan kekuatan ACD. Jika kita berbicara tentang tata kelola, ketika kita melihat bahwa kekuatan tidak berwujud mengalahkan kekuatan nyata, kita harus sangat prihatin karena hal-hal tidak berwujud seringkali sulit dijelaskan dan tidak dapat dengan mudah diperhatikan oleh banyak orang, sehingga mereka harus diekspos.

Apa itu peta jalan?

Siapa pun di komunitas Ethereum pasti sudah sering mendengar istilah "peta jalan," baik dalam "peta jalan ETH2.0" atau dalam konteks "peta jalan AA" yang terkait dengan acara ini.

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

• Pengembang Inti Bob: Saya mendukung EIP-1234, yang mengusulkan untuk meningkatkan kecepatan blok sebanyak 10 kali, meningkatkan ukuran blok sebanyak 10 kali, dan mengurangi biaya hingga 100 kali lipat.
• Pengembang Inti Lainnya: ... Apakah Anda gila?

Mari kita pikirkan ini. Mengapa tim inti Ethereum menolak apa yang diusulkan Bob? Dia hanya menyarankan cara yang tampaknya masuk akal untuk skala, sesuatu yang telah dilakukan oleh banyak rantai publik seperti Solana, Aptos, Sui, dan lainnya, mencapai TPS tinggi. Alasannya adalah bahwa EIP-1234 fiktif ini bertentangan dengan peta jalan penskalaan "rollup-centric" Ethereum. Roadmap ini menekankan bahwa, untuk desentralisasi, pengguna biasa harus dapat menjalankan node dengan biaya rendah. Oleh karena itu, EIP-1234 fiktif tidak mungkin diterima karena secara signifikan akan meningkatkan biaya menjalankan node Ethereum. Saya ingin menggunakan contoh ini untuk menggambarkan bahwa pengembang inti yang berpartisipasi dalam proses tata kelola ACD dan memutuskan pembaruan protokol dipandu oleh kekuatan tingkat yang lebih tinggi, yang saya sebut "peta jalan." Saat ini, di sekitar peta jalan Ethereum, ada "peta jalan penskalaan," "peta jalan AA," "peta jalan MEV," dan sebagainya. Mereka secara kolektif membentuk peta jalan keseluruhan Ethereum, dan pengembang inti harus membuat keputusan berdasarkan fondasi ini.

Ketika pandangan pengembang inti tidak selaras dengan peta jalan

Karena peta jalan bukan merupakan bagian formal dari proses tata kelola Ethereum, seringkali tidak ada jaminan bahwa tim inti akan mematuhinya. Selain itu, tidak ada proses formal untuk "menyetujui" peta jalan, jadi tidak semua peta jalan memiliki tingkat "ortodoksi" yang sama. Para peneliti di balik roadmap Ethereum harus bekerja keras untuk mempromosikan roadmap mereka kepada pengembang inti dan komunitas untuk mendapatkan "ortodoksi" dan dukungan dari tim pengembangan inti Ethereum. Mengenai AA dan abstraksi akun, Vitalik sendiri telah berulang kali mengadvokasi peta jalan AA 4337-sentris, tetapi secara keseluruhan, terutama tim di belakang 4337, terutama Yoav dan Dror, yang mengadvokasi peta jalan AA 4337-sentris di forum dan dalam pertemuan ACD.

Namun, terlepas dari upaya ini, beberapa pengembang inti Ethereum masih sangat menentang peta jalan AA 4337-sentris. Mereka percaya bahwa 7560 (versi asli 4337 yang akan diimplementasikan oleh klien Ethereum di masa depan) terlalu rumit dan bukan satu-satunya solusi yang layak untuk "AA endgame." Pada akhirnya, ACD memutuskan untuk menyetujui proposal 3074, meskipun ada tentangan dari tim 4337, yang percaya bahwa 3074 akan mematahkan seluruh ekosistem AA. Setelah 3074 disetujui, seluruh komunitas 4337 bereaksi keras, memaksa pengembang inti Ethereum untuk terlibat kembali dalam diskusi tentang 3074. Diskusi kemudian menemui jalan buntu, dengan penulis 4337 dan 3074 tidak dapat saling membujuk. Vitalik mengusulkan EIP-7702 sebagai alternatif dari 3074 pada menit terakhir, yang secara eksplisit mengakomodasi "AA endgame" 4337-sentris, sehingga menyelesaikan konflik dan menyelaraskan hasil akhir dengan peta jalan AA.

Peran Vitalik: CTO De Facto Ethereum

Meskipun Vitalik mengidentifikasi dirinya sebagai peneliti, cerita di atas jelas menunjukkan bahwa Vitalik memiliki kekuatan tata kelola yang berbeda dari peneliti lain. Jadi, muncul pertanyaan: Peran apa yang dimainkan Vitalik dalam tata kelola Ethereum? Secara pribadi, saya percaya mungkin tidak pantas untuk mempertimbangkan Vitalik sebagai CTO de facto dari perusahaan yang sangat besar (kebetulan, dengan asumsi Ethereum sebagai "perusahaan" tanpa CEO untuk menyelaraskan dengan kenyataan). Jika Anda pernah bekerja di perusahaan teknologi dengan lebih dari 50 karyawan, Anda akan tahu bahwa CTO tidak dapat terlibat dalam setiap keputusan teknis. Seiring pertumbuhan perusahaan, proses pengambilan keputusan untuk berbagai solusi teknis pasti menjadi terdesentralisasi — biasanya, setiap area produk / bisnis perusahaan memiliki tim khusus, yang seringkali memiliki otonomi untuk memutuskan detail solusi. Selain itu, CTO mungkin bukan ahli teratas dalam semua (atau apa pun) topik. Mungkin ada insinyur di dalam perusahaan yang lebih baik di bidang tertentu daripada CTO, jadi dalam diskusi tentang rincian teknis solusi, seringkali insinyur individu yang membuat keputusan akhir. Namun, CTO menetapkan visi teknis perusahaan. Eksekusi visi diserahkan kepada pengembang. Meskipun ini bukan analogi yang sempurna, saya percaya ini cukup merangkum peran Vitalik dalam ekosistem Ethereum. Vitalik tidak berpartisipasi dalam setiap keputusan teknis — dia mungkin tidak bisa. Dia juga bukan ahli top di setiap domain. Tetapi dia memiliki pengaruh luar biasa dalam menetapkan peta jalan untuk semua solusi Ethereum yang penting (penskalaan, AA, POS ...), bukan hanya karena keahlian teknisnya tetapi juga karena dia adalah hakim utama apakah peta jalan tersebut selaras dengan visi Ethereum (visinya).

Setiap Produk yang Sukses Dimulai dengan Visi

Jika mempertimbangkan Vitalik sebagai CTO Ethereum tidak cukup kontroversial, inilah bagian yang paling kontroversial: kita harus merangkul Vitalik sebagai CTO. Sebagai pendiri startup, saya percaya setiap produk yang sukses harus memiliki visi jangka panjang yang koheren — ya, Ethereum juga merupakan "produk" karena memecahkan masalah nyata bagi pengguna nyata. Visi yang koheren harus dibuat oleh beberapa orang, seperti pendiri startup, dan biasanya, hanya ada satu pendiri. Keindahan Ethereum adalah bahwa, meskipun merupakan sistem yang sangat kompleks dengan begitu banyak komponen, semua komponen ini dengan mulus bersatu untuk membentuk komputer terdesentralisasi yang berfungsi dengan baik, menyelesaikan transaksi senilai miliaran dolar setiap hari. Kami telah sampai sejauh ini bukan melalui beberapa skema desain komite tetapi karena Vitalik, dengan pandangan ke depan dan wawasannya, telah secara aktif memberikan kepemimpinan, memungkinkan kami untuk membangun Ethereum yang koheren dan anggun saat ini. Ethereum adalah ide yang diusulkan Vitalik pada tahun 2015, dan tetap demikian. Tentu saja, ini bukan untuk mengurangi kontribusi peneliti dan insinyur lain — mereka telah membuat sebagian besar pencapaian Ethereum hari ini. Namun, ini tidak bertentangan, karena Ethereum adalah realisasi dari visi Vitalik, besarnya lebih besar dari visi orang lain. Jujur, bisakah Anda mengeluh tentang ini? Ketika Anda tertarik pada keterbukaan, ketahanan sensor, dan kecepatan inovasi ekosistem Ethereum, pernahkah Anda mengeluh bahwa itu berasal dari visi Vitalik? Mungkin engkau semua tidak mengeluh karena engkau tidak memikirkannya seperti ini—tetapi sekarang setelah itu, apakah engkau keberatan dengan masalah ini?

Bagaimana cara mengatasi desentralisasi?

Tetapi Anda mungkin bertanya, bagaimana dengan desentralisasi? Jika satu orang memegang kekuasaan luar biasa atas Ethereum, bagaimana kita bisa mengatakan itu terdesentralisasi? Untuk menjawab pertanyaan ini, kita harus meninjau kembali artikel klasik Vitalik tentang arti desentralisasi. Wawasan utama dari artikel ini adalah bahwa desentralisasi datang dalam tiga jenis:

• Desentralisasi arsitektur: Berapa banyak node yang bisa gagal sebelum sistem berhenti berjalan?
• Desentralisasi logis: Dapatkah berbagai subsistem sistem berkembang secara independen sambil tetap bekerja bersama secara kohesif?
• Desentralisasi politik: Pada akhirnya, berapa banyak individu atau organisasi yang mengendalikan sistem?

Menurut definisi ini, Ethereum jelas terdesentralisasi secara arsitektural, dan orang dapat berargumen bahwa itu terdesentralisasi secara logis karena komponennya tidak memiliki kopling yang kuat (misalnya, antara lapisan konsensus dan lapisan eksekusi). Adapun desentralisasi politik, kabar baiknya adalah bahwa tidak ada individu atau organisasi yang dapat mematikan Ethereum, bahkan Vitalik. Namun, beberapa orang mungkin berpendapat bahwa tingkat desentralisasi politik Ethereum tidak setinggi yang dibayangkan karena Vitalik memainkan peran penting dalam membentuk visi dan peta jalan Ethereum.

Namun, saya percaya bahwa jika kita ingin Ethereum terus berinovasi, kita harus menerima Vitalik sebagai CTO de facto, bahkan jika itu berarti mengorbankan beberapa desentralisasi politik. Jika Ethereum menjadi "stagnan" seperti Bitcoin, blockchain yang hampir tidak berubah, maka Vitalik mungkin juga pensiun. Tetapi sebelum kita mencapai langkah terakhir itu, sangat penting untuk memiliki otoritas yang dihormati oleh semua pihak, seseorang yang dapat dipercaya untuk membuat keputusan teknis tidak hanya berdasarkan keunggulan solusi teknis yang diusulkan tetapi juga pada apakah keputusan ini selaras dengan visi Ethereum.

Tanpa seseorang seperti Vitalik, hanya dua hasil yang mungkin, diilustrasikan dengan jelas oleh cerita di sekitar EIP-3074:

Proses tata kelola Ethereum bisa jatuh ke dalam kebuntuan tanpa akhir, dengan pihak-pihak yang bertikai tidak mau berkompromi dan tidak ada yang membuat kemajuan, seperti yang ditunjukkan oleh kebuntuan dalam debat 3074 sebelum Vitalik campur tangan.

Atau Ethereum bisa menjadi "Frankenstein" yang tidak koheren desain, dengan 3074 dan 4337 mungkin tidak menyerah satu sama lain, yang pada akhirnya mengakibatkan pecahnya ekosistem AA menjadi dua ruang paralel yang tidak kompatibel.

Peran Komunitas

Setelah pertimbangan di atas, kami hampir membuat sketsa pola pikir tata kelola Ethereum yang lengkap, tetapi ada kelalaian yang jelas dalam diskusi kami sejauh ini — komunitas. Jika Vitalik mendefinisikan visi Ethereum, peneliti menentukan peta jalan, dan pengembang inti menerapkan peta jalan, lalu peran apa yang dimainkan komunitas? Tentunya, itu bukan hanya duduk diam, bukan? Untungnya, komunitas memainkan peran yang paling penting. Alasannya adalah, sebelum ada visi, ada nilai-nilai. Kami datang bersama-sama sebagai sebuah komunitas karena kami bersatu di sekitar nilai-nilai tertentu, dan visi Vitalik pada akhirnya harus selaras dengan nilai-nilai ini untuk mempertahankan dukungan masyarakat. Semua orang di komunitas Ethereum percaya bahwa memiliki komputer terdesentralisasi yang dapat diakses oleh semua orang, tanpa sensor, dan netral kepercayaan bermanfaat bagi dunia. Kami menjunjung tinggi dan menegaskan nilai-nilai ini setiap hari melalui pekerjaan yang kami lakukan di Ethereum, sehingga melegitimasi visi, peta jalan, dan kode yang ditetapkan oleh Vitalik, peneliti, dan pengembang inti.

Model VVRC Tata Kelola Ethereum

Oleh karena itu, inilah pola pikir lengkap tata kelola Ethereum, disingkat VVRC:

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

Bersama-sama mereka memainkan peran berikut:

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

Tentu saja, realitas jauh lebih kompleks daripada yang dapat ditangkap oleh model sederhana mana pun. Pengembang Core Ethereum adalah satu-satunya yang benar-benar dapat "memilih" pada proposal apa pun dengan mengubah kode klien. Vitalik dan peneliti lain berfungsi sebagai penasihat, dan terkadang pendapat mereka tidak diterima oleh pengembang inti, itulah sebabnya EIP-3074 disetujui. Namun demikian, saya percaya model VVRC secara wajar menangkap mode operasional tata kelola Ethereum dalam keadaan normal, dan kita perlu "men-debug" proses ini untuk mencegah kecelakaan seperti EIP-3074 terjadi lagi.

Cara Meningkatkan Model Tata Kelola Ethereum

Sekarang kita memiliki model mental tentang bagaimana proses tata kelola Ethereum beroperasi, berikut adalah beberapa ide untuk meningkatkan proses tata kelola:

Visibilitas kemajuan diskusi untuk EIP yang sedang ditinjau harus ditingkatkan. Seluruh komunitas tidak boleh "terkejut" dengan penerimaan EIP, dan persetujuan tak terduga seperti EIP-3074 tidak boleh terulang kembali. "Status" EIP saat ini di situs web EIP tidak mencerminkan status mereka dalam proses ACD. Inilah sebabnya mengapa masih dikatakan bahwa EIP-3074 "sedang ditinjau," meskipun pengembang inti telah memilih untuk menyetujuinya, tanpa indikasi bahwa itu pernah dipertimbangkan untuk persetujuan sejak awal. Idealnya, ketika EIP akan diterima, Yayasan Ethereum harus membuat pengumuman publik yang pasti di media sosial untuk meningkatkan kesadaran di dalam komunitas.

Terkadang, pengembang inti mungkin meremehkan dampak EIP tertentu pada proyek dan pengguna hilir, seperti halnya dengan komunitas 3074 dan 4337. Karena terbatasnya waktu pertemuan ACD dan kebutuhan untuk koordinasi lintas zona waktu, hanya "personel yang relevan" yang sering dapat berbicara di pertemuan. Namun demikian, kadang-kadang masuk akal untuk mengalokasikan waktu berbicara kepada anggota masyarakat untuk mengomentari dampak proposal EIP tertentu pada proyek hilir setelah persetujuan mereka. Jika peneliti merasa bahwa pendapat mereka belum diterima oleh pengembang inti, seperti halnya dengan 4337, mereka dapat mengundang anggota masyarakat untuk memperkuat argumen mereka.

Sangat penting bagi pengembang inti dan peneliti untuk saling mengakui bahwa, terlepas dari perbedaan kekuatan, mereka berdua adalah bagian dari otoritas tata kelola Ethereum. Pengembang inti memiliki kekuatan untuk mengubah dan memperbarui klien Ethereum, yang merupakan satu-satunya cara untuk membuat perubahan pada protokol itu sendiri dan "memilih." Para peneliti biasanya memiliki lebih banyak dukungan publik untuk perubahan dan interpretasi terhadap peta jalan, berkat diskusi aktif dan penulisan ide-ide mereka.

Ketika kedua kekuatan ini berbenturan, pengembang inti mungkin cenderung secara langsung membalikkan pendapat para peneliti, seperti halnya dengan tim 4337. Namun, penggulingan seperti itu dapat menyebabkan konflik, karena ketidakstabilan muncul ketika kedua kekuatan berbenturan, sebagaimana dibuktikan oleh peristiwa dramatis setelah persetujuan EIP-3074.

Demikian juga, ketika dihadapkan dengan resistensi, peneliti mungkin cenderung menyerah pada kolaborasi dengan pengembang inti. Dalam pandangan saya, ini juga salah satu alasan untuk menciptakan proses RIP dan mengapa AA asli (7560) sekarang terutama dipromosikan sebagai RIP daripada EIP.

Sementara bereksperimen dengan pembaruan protokol pada L2 yang kontroversial untuk L1 memang memiliki manfaatnya, kami tidak dapat melihat RIP sebagai pengganti untuk berpartisipasi dalam proses tata kelola EIP. Para peneliti harus terus berkolaborasi dengan pengembang inti sampai nilai-nilai kedua belah pihak sepenuhnya selaras dengan peta jalan.

Kesimpulan

Insiden 3074/7702 mengungkapkan operasi sebenarnya dari tata kelola Ethereum — selain dari kekuatan tata kelola eksplisit yang didorong oleh proses EIP / ACD dari pengembang inti, ada juga kekuatan tata kelola implisit yang didorong oleh peta jalan yang didorong oleh para peneliti. Ketika kekuatan-kekuatan ini tidak selaras, kita melihat kebuntuan dan dorongan, dan kekuatan lain — Vitalik — mungkin perlu campur tangan dalam beberapa cara untuk mengganggu keseimbangan.

Selanjutnya, kami mengusulkan bahwa Vitalik mewakili kekuatan unik, yaitu "visi" Ethereum, yang membentuk dasar legitimasi peta jalan apa pun. Kami membandingkan Vitalik dengan CTO dari sebuah perusahaan besar dan mengakui perannya sebagai pseudo-CTO diperlukan bagi Ethereum untuk mempertahankan laju inovasinya, mencegah Ethereum berubah menjadi "Frankenstein" – seperti monster yang ditambal bersama.

Terakhir, kami menyajikan model VVRC, menggambarkan model tata kelola Ethereum: Nilai (Komunitas) ⇒ Visi (Vitalik) ⇒ Roadmap (Peneliti) ⇒ Klien (Pengembang inti). Kemudian, kami mengusulkan berbagai metode untuk "men-debug" "kesalahan" model ini.

Tata kelola Ethereum adalah "mesin pembuat mesin" — untuk membuat Ethereum berjalan dengan benar, kita harus mengaturnya dengan benar.

Sanggahan:

1. Artikel ini dicetak ulang dari [极客 Web3]. Teruskan judul asli 'Refleksi tentang tata kelola Ethereum setelah 3074 Saga'. Semua hak cipta milik penulis asli [Derek Chiang, CEO ZeroDev]. 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. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.