ikon_instal_ios_web ikon_instal_ios_web ikon_instal_android_web

Tentang dampak Vitalik dan berbagai peta jalan pada proses tata kelola Ethereum

Analisis7 bulan yang lalu发布 6086cf...
81 0

Artikel asli oleh Derek Chiang, CEO ZeroDev

Terjemahan asli: Faust, Geekweb3

Abstrak: Artikel ini merupakan pendapat CEO ZeroDev Derek Chiang mengenai masalah tersebut setelah Vitalik Buterin mengusulkan EIP-7702 untuk menyeimbangkan kontradiksi antara ERC-4337 dan EIP-3074. Berdasarkan pengalaman pribadi pendiri proyek di ekosistem AA, artikel ini secara objektif menunjukkan model tata kelola saat ini dan titik lemah Ethereum, dan mengemukakan:

Salah satu dari berbagai konflik tata kelola di Ethereum adalah bahwa peta jalan yang ditentukan oleh peneliti bertentangan dengan pandangan tim pengembangan klien seperti Geth, dan Vitalik telah menjadi pembuat keputusan akhir dalam kapasitas yang mirip dengan CTO.

Setelah memberikan evaluasi positif terhadap peran Vitalik, Derek menunjukkan perbaikan apa yang harus dilakukan Ethereum dalam model tata kelolanya, yang memiliki arti penting referensi yang besar baik bagi komunitas Ethereum maupun komunitas Bitcoin.

Tentang dampak Vitalik dan berbagai peta jalan pada proses tata kelola Ethereum

Konten: Jika Anda belum tahu tentang Ethereum AA (Account Abstraction) sebelumnya, berikut ulasan singkatnya:

Beberapa minggu lalu, proposal EIP-3074 disetujui oleh pengembang inti Ethereum dan akan disertakan dalam hard fork Pectra berikutnya. Proposal tersebut akan membawa dua opcode baru ke EVM, memberikan akun Ethereum EOA pengalaman AA yang hampir asli.

Sejak saat itu, banyak orang di komunitas ERC-4337, terutama para pengusul 4337, telah menentang keras EIP-3074, dengan alasan kekhawatiran bahwa usulan tersebut akan menimbulkan banyak risiko keamanan dan tidak sesuai dengan peta jalan Ethereum AA. Dalam peta jalan Ethereum sebelumnya, dinyatakan dengan jelas bahwa ERC-4337 dan usulan serupa 7560 (juga dikenal sebagai nativeAA) adalah inti dari usulan tersebut.

Pada awal bulan Mei, Vitalik mengusulkan EIP-7702 sebagai pengganti EIP-3074, yang mencapai keseimbangan antara 4337 dan 3074 – yang dapat menghadirkan pengalaman AA kepada pengguna EOA, tetapi dengan cara yang lebih kompatibel dengan ERC-4337 dan kompatibel dengan Solusi Akhir AA 7560.

Saat ini, pengembang inti Ethereum tengah mempertimbangkan EIP-7702. Hasil diskusi awal dan sentimen komunitas saat ini menunjukkan bahwa EIP-7702 kemungkinan akan menggantikan EIP-3074 yang disebutkan di atas.

Secara pribadi, saya sangat senang dengan hasil ini: Pengguna EOA akan segera dapat mencoba berbagai produk dalam ekosistem ERC-4337 dan menikmati sebagian besar manfaat AA. Namun, saya merasa bahwa ada cara yang lebih baik untuk mencapai hasil di atas, yang telah ditunjukkan oleh banyak orang dalam beberapa minggu terakhir. Saya merasa bahwa jika ada proses tata kelola yang lebih baik, kami dapat menghemat banyak energi dan mencapai hasil yang diinginkan dengan lebih cepat.

Dalam artikel ini, saya ingin:

  • Mengidentifikasi apa yang salah dalam proses tata kelola

  • Mengusulkan model mental untuk memikirkan tata kelola Ethereum

  • Memberikan saran perbaikan untuk menghindari insiden tata kelola serupa di masa mendatang

Ringkasan dan refleksi atas insiden EIP-3074

Kisah yang disebutkan di atas membuat banyak orang tidak senang karena alasan berikut:

Butuh waktu bertahun-tahun untuk mendapatkan persetujuan EIP-3074. Setelah 3074 akhirnya disetujui, pengembang inti Ethereum menghadapi tentangan keras dari komunitas 4337.

Di sisi lain, penulis ERC-4337 telah berulang kali menyampaikan kekhawatiran 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 proses-proses di atas:

  • Pembahasan mengenai EIP dapat memakan waktu beberapa tahun, dan itu hal yang normal.

  • Adalah hal yang normal apabila EIP ditolak setelah disetujui.

  • Persetujuan dapat dibatalkan setelah EIP disetujui jika masalah baru ditemukan.

Namun, semuanya bisa berjalan lebih lancar. Mari kita bayangkan jika semuanya berjalan seperti ini:

Saat membahas 3074, komunitas 4337 secara aktif berinteraksi dengan pengembang inti Ethereum. Jika premis ini benar, hanya ada dua kemungkinan hasil:

  • Setelah mempertimbangkan masukan komunitas 4337, proposal 3074 disetujui (dan dapat dimodifikasi), dalam hal ini komunitas 4337 akan menerima 3074 dan tim inti Ethereum tidak perlu menarik 3074.

  • Atau, mungkin 3074 tidak pernah disetujui, tetapi komunitas 4337 dan tim inti Ethereum bersatu untuk membuat proposal yang memuaskan semua orang, seperti 7702.

Suara semua orang didengar, dan tidak ada perubahan dramatis. Itu akan menyenangkan—jadi mengapa tidak?

Apa yang salah?

Melihat kembali keseluruhan prosesnya, kedua pihak saling menyalahkan.

Pengembang inti Ethereum (dan penulis EIP-3074) yakin bahwa ini adalah kesalahan pendukung 4337 karena mereka tidak berpartisipasi aktif dalam proses diskusi Semua Pengembang Inti (ACD), di mana EIP menjalani pertimbangan panjang sebelum diterima dan diimplementasikan oleh tim pengembangan klien Ethereum seperti Geth.

Beberapa orang berpendapat bahwa para pendukung 4337 dapat berpartisipasi dan menyampaikan pendapat mereka selama peninjauan proposal 3074, daripada menunggu hingga 3074 disetujui. Lagi pula, seluruh proses ACD terdokumentasi dengan baik, pertemuannya terbuka untuk semua orang, dan orang-orang seperti Tim Beiko secara aktif memposting tweet ringkasan setelah setiap pertemuan ACD. Jadi, jika para pendukung 4337 sangat peduli dengan topik ini, mengapa mereka tidak berpartisipasi secara aktif dan segera dalam pertemuan yang relevan?

Di sisi lain, anggota inti 4337 menunjukkan bahwa mereka telah menghadiri pertemuan ACD dan menentang 3074 sebisa mungkin, tetapi pengembang inti Ethereum tidak mendengarkan. Sedangkan untuk anggota komunitas 4337, sebagian besar dari mereka merasa bahwa hal itu terjadi secara tiba-tiba – banyak orang mengira bahwa 3074 sudah mati, dan mereka bahkan tidak tahu bahwa 3074 kemungkinan besar akan disetujui.

Banyak orang yang menyatakan bahwa seluruh proses pertemuan ACD tidak transparan dan tidak bersahabat bagi mereka yang serius di komunitas Ethereum tetapi tidak dapat mengikuti perkembangan pembaruan ACD secara tepat waktu. Sebagian orang juga percaya bahwa ACD harus secara proaktif mencari masukan dari para pemangku kepentingan (di sini merujuk pada komunitas 4337).

Namun, saya rasa kedua belah pihak tidak memahami inti permasalahannya. Ada masalah yang lebih dalam di balik ini, dan kecuali kita mengatasinya atau setidaknya mengakuinya, kita akan terus mengalami kecelakaan tata kelola, dengan kedua belah pihak saling menyalahkan, yang tidak ada artinya.

Mengatasi akar penyebab insiden: Sebuah peta jalan

Bertentangan dengan kepercayaan umum, akar penyebab insiden tata kelola adalah bahwa ACD bukan satu-satunya sumber daya tata kelola untuk pembaruan protokol Ethereum, melainkan digantikan oleh sumber daya tata kelola lainnya. Masalahnya di sini adalah bahwa meskipun daya tata kelola lainnya memiliki pengaruh yang lebih besar daripada ACD pada isu-isu inti Ethereum (seperti AA dan skalabilitas), hal itu jarang diakui.

Dalam artikel ini, saya menyebut kekuatan ini sebagai “peta jalan.”

Seperti yang akan saya tunjukkan di bawah, seluruh insiden kegagalan tata kelola 3074-4337-7702 adalah kasus kekuatan peta jalan Ethereum yang ada yang mengalahkan kekuatan ACD. Jika kita berbicara tentang tata kelola, ketika kita melihat bahwa ada kekuatan tak terlihat yang mengalahkan kekuatan yang terlihat, kita harus sangat khawatir tentang hal ini, karena hal-hal yang tidak terlihat seringkali sulit dijelaskan dan tidak dapat diperhatikan oleh terlalu banyak orang, jadi hal-hal tersebut harus diungkapkan.

Apa itu peta jalan?

Siapa pun di komunitas Ethereum pasti sering melihat istilah “peta jalan”, misalnya dalam “peta jalan yang berpusat pada rollup”, “peta jalan ETH 2.0”, atau dalam kasus ini “peta jalan AA”.

Tentang dampak Vitalik dan berbagai peta jalan pada proses tata kelola Ethereum

Untuk mengilustrasikan maksud saya, mari kita bayangkan sebuah adegan dari pertemuan ACD di mana para pengembang inti sedang mendiskusikan cara meningkatkan skala Ethereum:

  • Bob, pengembang inti: Saya mendukung EIP-1234, yang mengusulkan agar kita meningkatkan kecepatan produksi blok sebanyak 10 kali lipat, meningkatkan ukuran blok sebanyak 10 kali lipat, dan mengurangi biaya sebanyak 100 kali lipat.

  • Pengembang inti lainnya: …kamu gila?

Mari kita pikirkan. Mengapa tim inti Ethereum menolak apa yang dikatakan Bob? Dia hanya mengusulkan cara yang sangat masuk akal untuk memperluas kapasitas. Solana, Aptos, Sui, dan banyak rantai publik lainnya telah melakukannya dan mencapai TPS yang tinggi.

Alasannya adalah karena EIP-1234 fiktif ini melanggar peta jalan ekspansi Ethereum yang berpusat pada rollup, yang menunjukkan bahwa untuk desentralisasi, sangat penting bagi pengguna biasa untuk dapat menjalankan node dengan biaya rendah. Oleh karena itu, EIP-1234 fiktif tidak dapat diterima karena akan sangat meningkatkan biaya menjalankan node Ethereum.

Saya ingin menggunakan contoh ini untuk mengilustrasikan bahwa pengembang inti yang berpartisipasi dalam proses tata kelola ACD dan memutuskan pembaruan protokol dipandu oleh kekuatan tingkat tinggi, yang saya sebut peta jalan. Saat ini, ada peta jalan penskalaan, peta jalan AA, peta jalan MEV, dll., yang bersama-sama membentuk peta jalan Ethereum secara keseluruhan, dan pengembang inti harus membuat keputusan berdasarkan hal ini.

Ketika pendapat pengembang inti tidak konsisten dengan peta jalan

Karena peta jalan bukan bagian formal dari proses tata kelola Ethereum, sering kali tidak ada jaminan bahwa tim inti akan mematuhi peta jalan tersebut. Selain itu, tidak ada proses formal untuk menyetujui peta jalan, jadi tidak semua peta jalan memiliki legitimasi yang sama. Para peneliti di balik peta jalan Ethereum harus bekerja keras untuk mempromosikan peta jalan mereka kepada para pengembang inti dan komunitas agar memperoleh legitimasi dan dengan demikian memperoleh dukungan dari tim pengembangan inti Ethereum.

Sejauh menyangkut AA dan abstraksi akun, Vitalik sendiri telah mendorong peta jalan AA yang berpusat pada 4337 pada beberapa kesempatan, tetapi secara keseluruhan, terutama tim di belakang 4337, khususnya Yoav dan Dror, yang telah menganjurkan peta jalan AA yang berpusat pada 4337 di forum dan rapat ACD.

Tentang dampak Vitalik dan berbagai peta jalan pada proses tata kelola Ethereum

Namun, terlepas dari upaya-upaya ini, beberapa pengembang inti Ethereum masih menentang keras peta jalan AA yang berpusat pada 4337. Mereka percaya bahwa 7560 (versi asli 4337 yang akan diimplementasikan oleh klien Ethereum di masa mendatang) terlalu rumit dan bukan satu-satunya solusi yang layak untuk finalitas AA. Pada akhirnya, ACD memutuskan untuk menyetujui proposal 3074, meskipun ditentang oleh tim 4337, yang percaya bahwa 3074 akan memecah seluruh ekosistem AA.

Setelah 3074 disetujui, seluruh komunitas 4337 bereaksi keras, memaksa para pengembang inti Ethereum untuk kembali terlibat dalam diskusi 3074. Diskusi tersebut kemudian menemui jalan buntu, karena baik penulis 4337 maupun penulis 3074 tidak dapat meyakinkan satu sama lain, dan Vitalik mengusulkan EIP-7702 sebagai alternatif 3074 pada menit terakhir, yang secara eksplisit kompatibel dengan tujuan akhir AA yang berpusat pada 4337, sehingga menyelesaikan konflik dan membuat hasil akhir sesuai dengan peta jalan AA.

Peran Vitalik: CTO de facto Ethereum

Meskipun Vitalik menggambarkan dirinya sebagai seorang peneliti, cerita di atas dengan jelas menunjukkan bahwa Vitalik memiliki kekuatan tata kelola yang sangat berbeda dari peneliti lainnya. Jadi pertanyaannya adalah: peran apa yang dimainkan Vitalik dalam tata kelola Ethereum?

Secara pribadi, saya rasa mungkin tidak apa-apa untuk menganggap Vitalik sebagai CTO dari perusahaan yang sangat, sangat besar (dengan asumsi, omong-omong, bahwa “perusahaan” Ethereum tidak memiliki CEO demi konteksnya)

Jika Anda pernah bekerja di perusahaan teknologi dengan lebih dari 50 karyawan, Anda tahu bahwa mustahil bagi CTO untuk terlibat dalam setiap keputusan teknis. Ketika sebuah perusahaan mencapai ukuran tertentu, proses pengambilan keputusan untuk berbagai solusi teknis harus didesentralisasi – biasanya setiap area produk/bisnis perusahaan memiliki tim khusus, dan tim ini biasanya bebas untuk memutuskan detail solusi.

Lebih jauh lagi, CTO tidak selalu menjadi pakar utama dalam semua (atau sebagian) topik. Mungkin ada teknisi di perusahaan yang lebih baik daripada CTO dalam bidang tertentu, jadi ketika membahas detail teknis, sering kali teknisi itu sendiri yang membuat keputusan akhir.

Namun, CTO menetapkan visi teknis bagi perusahaan. Pelaksanaan visi tersebut diserahkan kepada pengembang.

Meskipun ini bukan analogi yang sempurna, menurut saya ini cukup meringkas peran Vitalik dalam ekosistem Ethereum. Vitalik tidak berpartisipasi dalam setiap keputusan teknis—dan dia juga tidak bisa. Dia bukan pakar utama di setiap bidang. Namun, dia memiliki pengaruh yang sangat besar pada peta jalan untuk semua solusi utama Ethereum (penskalaan, AA, POS…), bukan hanya karena keahlian teknisnya, tetapi karena dia adalah penilai utama apakah peta jalan tersebut sejalan dengan visi Ethereum (visinya).

Setiap produk yang sukses dimulai dengan sebuah visi

Jika pendapat saya bahwa Vitalik adalah CTO Ethereum belum cukup kontroversial, berikut bagian yang paling kontroversial: Kita harus menerima Vitalik sebagai CTO.

Sebagai pendiri perusahaan rintisan, saya percaya bahwa setiap produk yang sukses harus memiliki visi jangka panjang yang koheren di baliknya – ya, Ethereum adalah sebuah produk karena produk tersebut memecahkan masalah nyata bagi pengguna nyata. Dan visi yang koheren harus dikembangkan oleh sejumlah kecil orang, seperti pendiri perusahaan rintisan, dan biasanya hanya satu pendiri.

Keistimewaan Ethereum adalah meskipun merupakan sistem yang sangat kompleks dengan begitu banyak komponen, komponen-komponen tersebut saling cocok satu sama lain dengan sempurna untuk membentuk komputer terdesentralisasi yang berjalan lancar yang menyelesaikan transaksi bernilai miliaran dolar setiap hari.

Kita berada di sini hari ini bukan karena rencana komite tertentu, tetapi karena kepemimpinan Vitalik yang visioner, kita mampu membangun Ethereum yang koheren dan indah seperti sekarang ini. Ethereum adalah ide Vitalik pada tahun 2015, dan masih tetap demikian hingga saat ini.

Tentu saja ini bukan berarti mengabaikan kontribusi para peneliti dan teknisi lain yang telah memberikan kontribusi besar terhadap apa yang menjadikan Ethereum seperti sekarang ini. Namun, ini bukanlah kontradiksi, karena Ethereum adalah perwujudan visi Vitalik, yang jauh lebih hebat daripada visi siapa pun.

Jujur saja, bisakah Anda mengeluh tentang hal ini? Meskipun Anda tertarik dengan keterbukaan, ketahanan terhadap penyensoran, dan kecepatan inovasi ekosistem Ethereum, apakah Anda mengeluh tentang hal itu sejak visi Vitalik? Mungkin Anda tidak mengeluh karena Anda tidak memikirkannya seperti itu — tetapi sekarang Anda melakukannya, tetapi apakah Anda benar-benar keberatan dengan masalah tersebut?

Bagaimana menyelesaikan desentralisasi?

Namun, Anda bertanya, bagaimana dengan desentralisasi? Jika satu orang memiliki kekuasaan yang sangat besar atas Ethereum, bagaimana kita bisa mengatakan bahwa Ethereum terdesentralisasi?

Untuk menjawab pertanyaan ini, kita harus kembali ke artikel klasik tentang makna desentralisasi yang ditulis oleh Vitalik. Wawasan utama artikel ini adalah bahwa ada tiga jenis desentralisasi:

Tentang dampak Vitalik dan berbagai peta jalan pada proses tata kelola Ethereum

  • Desentralisasi arsitektur: Berapa banyak node yang harus gagal sebelum sistem berhenti berfungsi?

  • Desentralisasi yang logis: Dapatkah berbagai subsistem berkembang secara independen sambil tetap memungkinkan sistem keseluruhan berfungsi dengan baik, atau haruskah mereka dikoordinasikan dengan erat?

  • Desentralisasi politik: Berapa banyak orang atau organisasi yang pada akhirnya mengendalikan sistem?

Berdasarkan definisi ini, Ethereum jelas terdesentralisasi secara arsitektur, dan dapat dikatakan juga terdesentralisasi secara logis karena kurangnya keterkaitan yang kuat antara komponen-komponennya (misalnya, lapisan konsensus dan lapisan eksekusi).

Dalam hal desentralisasi politik, kabar baiknya adalah tidak ada satu pun individu atau organisasi yang dapat menutup Ethereum, bahkan Vitalik. Namun, orang dapat berpendapat bahwa Ethereum tidak terdesentralisasi secara politik seperti yang dipikirkan orang, karena Vitalik memainkan peran utama dalam mengembangkan visi dan peta jalan untuk Ethereum.

Namun, saya pikir jika kita ingin Ethereum terus berinovasi, kita harus menerima Vitalik sebagai CTO de facto, bahkan jika itu berarti mengorbankan beberapa desentralisasi politik.

Jika Ethereum benar-benar berubah menjadi blockchain yang hampir tidak dapat diubah seperti Bitcoin, maka Vitalik mungkin akan pensiun. Namun sebelum kita mencapai langkah terakhir itu, penting untuk memiliki otoritas yang dihormati semua pihak, yang dapat dipercaya, dan yang dapat membuat penilaian atas keputusan teknis berdasarkan tidak hanya pada apakah solusi teknis yang diusulkan lebih unggul, tetapi juga pada apakah keputusan ini konsisten dengan visi Ethereum.

Tanpa Vitalik, hanya ada dua kemungkinan hasil, dan kisah seputar 3074 dengan jelas menggambarkan kedua hasil ini:

  • Proses tata kelola Ethereum dapat terjebak dalam kebuntuan tanpa akhir, dengan tidak ada satu pihak pun yang bersedia berkompromi dan tidak ada seorang pun yang mampu membuat kemajuan, seperti yang ditunjukkan oleh perdebatan 3074 yang menemui jalan buntu sebelum Vitalik turun tangan.

  • Atau, Ethereum dapat menjadi Frankenstein dengan desain yang tidak koheren. 3074 dan 4337 yang disebutkan di atas mungkin tidak akan saling mengalah, dan akhirnya ekosistem AA akan sepenuhnya terbagi menjadi dua ruang paralel yang tidak kompatibel.

Tentang dampak Vitalik dan berbagai peta jalan pada proses tata kelola Ethereum

Peran masyarakat

Setelah pemikiran di atas, kami hampir menguraikan model pemikiran tata kelola Ethereum yang lengkap, tetapi sejauh ini ada satu kelalaian mencolok dalam diskusi kita – komunitas.

Jika Vitalik mendefinisikan visi Ethereum, para peneliti mendefinisikan peta jalan, dan para pengembang inti mengimplementasikan peta jalan, lalu apa peran komunitas? Tentunya bukan hal yang tidak penting, bukan?

Untungnya, komunitas sebenarnya memainkan peran yang paling penting. Alasannya adalah bahwa sebelum ada visi, ada nilai-nilai. Kita bersatu sebagai komunitas karena kita bersatu di sekitar nilai-nilai tertentu, dan visi Vitaliks pada akhirnya harus selaras dengan nilai-nilai tersebut, jika tidak, ia akan kehilangan dukungan dari komunitas.

Kami semua di komunitas Ethereum percaya bahwa memiliki komputer terdesentralisasi yang dapat diakses oleh semua orang, tahan terhadap sensor, dan dapat dipercaya adalah hal yang baik bagi dunia. Kami menjunjung tinggi dan menegaskan nilai-nilai ini setiap hari melalui pekerjaan yang kami lakukan di Ethereum, dan dengan demikian memberikan legitimasi pada visi, peta jalan, dan rangkaian kode oleh Vitalik, para peneliti, dan pengembang inti.

Model VVRC Tata Kelola Ethereum

Jadi, berikut ini adalah model mental lengkap tata kelola Ethereum, Nilai ⇒ Visi ⇒ Peta Jalan ⇒ Klien, singkatnya VVRC:

  • V==Nilai==Komunitas;

  • V==Visi==Vitalik;

  • R==Peta Jalan==Peneliti;

  • C==Klien==Pengembang inti;

Bersama-sama mereka menjalankan fungsi berikut:

  • Komunitas bersatu di sekitar nilai-nilai tertentu.

  • Vitalik mengemukakan visi yang konsisten dengan nilai-nilai ini.

  • Peneliti mengembangkan peta jalan berdasarkan visi.

  • Pengembang inti mengimplementasikan klien sesuai dengan peta jalan.

Tentu saja, kenyataan jauh lebih rumit daripada yang dapat digambarkan oleh model sederhana mana pun. Faktanya, pengembang inti Ethereum adalah satu-satunya yang benar-benar dapat memberikan suara pada proposal apa pun melalui perubahan pada kode klien. Vitalik dan peneliti lain hanya berperan sebagai penasihat, dan terkadang pendapat mereka tidak diterima oleh pengembang inti, itulah sebabnya EIP-3074 disetujui.

Meski begitu, saya rasa model VVRC cukup menggambarkan cara kerja model tata kelola Ethereum dalam situasi normal, dan kita perlu "men-debug" prosesnya agar hal itu tidak terjadi lagi seperti EIP-3074.

Cara meningkatkan model tata kelola Ethereum

Sekarang setelah kita memiliki model mental tentang cara kerja proses tata kelola Ethereum, berikut adalah beberapa ide untuk memperbaikinya.

  • Visibilitas kemajuan pembahasan EIP yang sedang dipertimbangkan harus ditingkatkan. Seluruh masyarakat tidak perlu terkejut bahwa EIP diterima, dan persetujuan mengejutkan terhadap proposal seperti 3074 tidak boleh muncul lagi.

Status EIP saat ini di situs web EIP tidak mencerminkan statusnya dalam proses ACD. Inilah sebabnya mengapa masih disebutkan bahwa 3074 berstatus sedang ditinjau, meskipun pengembang inti telah memberikan suara untuk menyetujuinya dan tidak ada indikasi bahwa hal itu dipertimbangkan untuk disetujui sejak awal.

Idealnya, ketika EIP hampir diterima, Yayasan Ethereum akan mengumumkannya dengan lantang dan jelas di media sosial untuk meningkatkan kesadaran dalam komunitas.

  • Terkadang pengembang inti mungkin meremehkan dampak EIP tertentu pada proyek dan pengguna hilir, seperti yang terjadi pada komunitas 3074 dan 4337. Karena rapat ACD terbatas waktu dan harus dikoordinasikan lintas zona waktu, rapat sering kali hanya memperbolehkan “personel terkait” untuk berbicara.

Karena itu, ada baiknya jika sesekali mengalokasikan waktu bicara bagi anggota masyarakat untuk mengomentari dampak hilir dari proposal EIP tertentu jika disahkan.

Jika peneliti merasa pendapat mereka tidak diterima oleh pengembang inti, seperti kasus 4337, mereka dapat melibatkan anggota komunitas untuk memperkuat klaim mereka.

  • Sangat penting bagi pengembang inti dan peneliti untuk saling mengakui sebagai bagian dari kekuatan tata kelola Ethereum, meskipun tingkat kekuatan mereka berbeda. Kekuatan pengembang inti untuk membuat perubahan dan pembaruan pada klien Ethereum adalah satu-satunya kekuatan yang dapat "memilih" untuk membuat perubahan pada protokol itu sendiri. Kekuatan peneliti untuk membuat perubahan dan interpretasi peta jalan sering kali mendapat lebih banyak dukungan publik, berkat para peneliti yang secara aktif berbicara dan menulis tentang ide-ide mereka.

Ketika kedua kekuatan ini berbenturan, pengembang inti mungkin cenderung mengabaikan begitu saja para peneliti, seperti halnya ketika pengembang inti mengabaikan keberatan dari tim 4337. Akan tetapi, penolakan tersebut dapat menyebabkan konflik, karena kedua kekuatan menjadi tidak stabil ketika berbenturan, seperti yang ditunjukkan oleh peristiwa dramatis yang terjadi setelah 3074 disetujui.

Demikian pula, ketika menghadapi penolakan, peneliti mungkin tergoda untuk meninggalkan kolaborasi dengan pengembang inti, yang menurut saya merupakan salah satu alasan proses RIP diciptakan dan mengapa AA asli (7560) sekarang dipromosikan terutama sebagai RIP daripada EIP.

Meskipun ada manfaat nyata dalam bereksperimen dengan pembaruan protokol pada L2 yang kontroversial untuk L1, kita tidak dapat melihat RIP sebagai pengganti partisipasi dalam proses tata kelola EIP. Peneliti harus terus bekerja dengan pengembang inti hingga nilai-nilai kedua belah pihak sepenuhnya selaras dengan peta jalan.

Kesimpulannya

Insiden 3074/7702 mengungkap cara kerja tata kelola Ethereum yang sebenarnya – selain kekuatan tata kelola eksplisit dari proses EIP/ACD yang digerakkan oleh pengembang inti, ada juga kekuatan tata kelola implisit dari peta jalan yang digerakkan oleh para peneliti. Ketika kekuatan ini tidak pada tempatnya, kita melihat kebuntuan dan gejolak, dan kekuatan lain – Vitalik – mungkin diperlukan untuk entah bagaimana memecah keseimbangan.

Kami kemudian mengusulkan bahwa Vitalik mewakili kekuatan unik, "visi" Ethereum, yang merupakan hal mendasar bagi legitimasi peta jalan apa pun. Kami membandingkan Vitalik dengan CTO sebuah perusahaan besar dan mengakui bahwa perannya sebagai CTO semu diperlukan bagi Ethereum untuk mempertahankan laju inovasi, yang dapat mencegah Ethereum merosot menjadi monster tambal sulam seperti "Frankenstein".

Akhirnya, kami mengusulkan model VVRC yang menggambarkan model tata kelola Ethereum: Nilai (komunitas) ⇒ Visi (Vitalik) ⇒ Peta jalan (peneliti) ⇒ Klien (pengembang inti). Kami kemudian mengusulkan berbagai cara untuk memperbaiki bug model ini.

Tata kelola Ethereum adalah mesin yang membuat mesin tersebut – agar Ethereum dapat berfungsi dengan baik, kita harus memiliki tata kelola yang wajar. Oleh karena itu, 3074 memberikan contoh berharga tentang kecelakaan tata kelola, dan saya berharap komunitas Ethereum dapat mempelajari beberapa pelajaran yang berguna darinya untuk meningkatkan proses tata kelola Ethereum di masa mendatang.

Tautan asli

Artikel ini bersumber dari internet: Tentang dampak Vitalik dan berbagai peta jalan pada proses tata kelola Ethereum

Terkait: Analisis Makro SignalPlus (06/05/2024): Aset berisiko berpeluang kembali naik perlahan

Untuk pertama kalinya tahun ini, data ketenagakerjaan lebih rendah dari yang diharapkan (tidak ada peningkatan yang mengejutkan), dengan perubahan ketenagakerjaan secara keseluruhan sebesar +175.000 (peningkatan rata-rata sebelumnya sekitar 275.000), dan tingkat pengangguran juga secara tak terduga meningkat dari 3,83% menjadi 3,87%. Indikator pasar kerja frekuensi tinggi lainnya juga mulai menunjukkan tanda-tanda perlambatan, seperti laporan JOLTS terkini yang menunjukkan rasio lowongan kerja terhadap pengangguran yang lebih rendah, dan perekrutan dan pemberhentian sektor swasta pada level terendah dalam beberapa tahun. Selain itu, tren perekrutan di antara usaha kecil melemah secara signifikan, dengan kedua komponen ketenagakerjaan ISM dan PMI menunjukkan kelemahan, dan pangsa perusahaan jasa dan manufaktur yang melakukan perekrutan turun ke level yang biasanya terlihat dalam resesi. Jumat lalu, kami menunjukkan bahwa data penggajian nonpertanian lebih mungkin…

© 版权声明

相关文章