Penjelasan tata kelola inti Ethereum

Sebuah presentasi oleh Nixo Rokish dari Yayasan Ethereum di ETHBoulder, yang menjelaskan tata kelola protokol inti Ethereum, bagaimana percabangan keras dikoordinasikan, kesalahpahaman umum tentang siapa yang mengendalikan Ethereum, dan cara berpartisipasi dalam proses tata kelola.

Transkrip ini adalah salinan yang dapat diakses dari transkrip video asli (opens in a new tab) yang dipublikasikan oleh EthBoulder. Transkrip ini telah sedikit diedit agar lebih mudah dibaca.

Pengantar (0:12)

Terima kasih kepada keenam teman saya yang telah hadir. Baiklah. Hari ini saya akan berbicara kepada Anda tentang tata kelola inti Ethereum. Nama saya Nixo. Saya memimpin tim dukungan protokol di EF (Yayasan Ethereum). Di antara semua mandat kami, salah satunya adalah membuat proses tata kelola menjadi lebih jelas dan lebih mudah dinavigasi bagi semua orang yang berpartisipasi dalam hal ini karena Ethereum mencakup lebih dari sekadar pengembang intinya.

Jadi, inilah garis besar pembicaraannya. Kita akan membahas apa itu tata kelola inti. Kita akan membahas kesalahpahaman, bagaimana tata kelola Ethereum saat ini berfungsi. Kita akan menyinggung bagaimana perbandingannya dengan sistem tata kelola terdesentralisasi lainnya, mengapa pembangun harus peduli, dan jalur yang dapat ditindaklanjuti untuk berpartisipasi.

Jadi, apa itu tata kelola protokol inti? Saya menjalankan sebuah node. Artinya, saya memiliki perangkat keras, sebuah komputer di rumah saya tempat saya menjalankan perangkat lunak Ethereum. Saat saya menyiapkan perangkat lunak Ethereum ini, saya harus memilih klien yang akan menjalankan perangkat lunak tersebut. Ethereum cukup unik karena memiliki banyak klien untuk keragaman klien. Tujuannya adalah jika satu klien mati, jika ada bug di satu klien, seluruh jaringan tidak akan ikut mati. Ada rantai blok lain yang memiliki klien lain. Namun, Ethereum adalah satu-satunya yang diatur sedemikian rupa sehingga benar-benar melindungi kita dari bug. Jadi, jika Anda melihat Solana, Solana memiliki klien lain, saya rasa namanya seperti GTO, tetapi adopsinya hanya 20–21%. Jadi, jika klien mayoritas mati, rantai tersebut akan mati. Dan kita telah melihat jaringan lain mati. Itulah sebabnya Ethereum adalah rantai blok yang paling tangguh dan aman.

Jadi pertanyaannya adalah bagaimana Anda memasukkan perubahan ke dalam Ethereum ketika Anda harus berkoordinasi dengan begitu banyak klien yang berbeda. Pertama, kita akan membedakan antara percabangan keras dan percabangan lunak. Percabangan lunak tidak memerlukan koordinasi seperti yang dibutuhkan oleh percabangan keras. Ethereum utamanya bekerja dengan percabangan keras. Jadi, percabangan keras pada dasarnya adalah semua klien membangun versi baru Ethereum dan memutuskan pada waktu yang telah dikonfigurasi sebelumnya untuk meluncurkan versi baru Ethereum ini. Ini masih Ethereum tetapi memiliki fitur-fitur baru. Ini memiliki fitur yang berbeda. Dan semua operator node seperti saya yang menjalankan node di rumah atau operator profesional harus menerima versi baru Ethereum tersebut. Mereka harus meningkatkan node mereka atau memperbarui node mereka untuk menyertakan perangkat lunak baru tersebut.

Lalu bagaimana mereka memutuskan fitur apa saja yang masuk ke dalam percabangan keras tersebut? Mereka harus menyepakati prioritas untuk mengalokasikan waktu dan sumber daya mereka karena mereka memiliki waktu dan sumber daya yang terbatas untuk dialokasikan di sana. Mereka memprioritaskan hal-hal seperti celah keamanan atau tambalan keamanan, hal-hal seperti UX — jika ada rantai blok lain yang bersaing dengan kita, kita harus menjadi kompetitif dengan rantai blok lainnya. Jadi salah satu hal yang mereka perhatikan adalah bahwa setiap fitur yang masuk harus kompatibel ke depan dengan potensi item peta jalan yang akan datang.

Jadi tahun lalu ada hal yang sangat kontroversial terjadi. Anda mungkin pernah mendengarnya. Itu disebut EOF. Itu adalah EVM Object Format. Itu adalah serangkaian fitur yang dijadwalkan untuk masuk ke dalam percabangan keras Fusaka — Pectra, Fusaka, saya rasa keduanya — tetapi itu terpecah. Dan satu pemicu di antara banyak pemicu yang membuatnya dikeluarkan dari percabangan itu adalah karena Vitalik memublikasikan sebuah pos tentang potensi Ethereum untuk mengadopsi RISC-V. Banyak orang yang membacanya melihat hal itu dan berpikir, oke, jika kita mengadopsi RISC-V, fitur-fitur yang kita lihat di EOF sudah menjadi bawaan dari RISC-V. Jadi mengapa kita harus menambahkan kerumitan ini ke dalam protokol? Mengapa kita harus mengerahkan semua sumber daya pengembang klien untuk hal ini? Ini akan menjadi hal yang sia-sia jika kita akhirnya beralih ke RISC-V.

Jadi itulah yang menjadi puncak masalah pada EOF dan akhirnya dikeluarkan dari percabangan tersebut. Hal lain yang harus mereka pertimbangkan adalah bahwa fitur tersebut harus ditulis dan diuji secara ketat dalam enam bahasa yang berbeda karena klien-klien ini ditulis dalam enam bahasa yang berbeda. Jadi itu adalah matriks pengujian yang sangat besar untuk mereka kerjakan. Dan karena itu, setiap pilihan desain sekecil apa pun menjadi subjek perdebatan tanpa ada otoritas untuk menyelesaikan ketidaksepakatan. Jadi pertanyaan yang muncul adalah siapa yang memutuskan — yang merupakan inti dari tata kelola.

Kesalahpahaman (5:23)

Hal ini membawa kita pada kesalahpahaman dan kita akan membahas beberapa di antaranya. Pertama adalah Vitalik memutuskan apa yang masuk ke dalam protokol Ethereum. Perluasan dari hal itu adalah bahwa EF mengendalikan segalanya. Dan yang ketiga adalah semuanya merupakan kesepakatan di ruang tertutup — orang dalam, para OG yang membuat keputusan ini.

Jadi yang pertama: Vitalik yang memutuskan. Saya baru saja memilih sebagian dari EIP yang mandek yang ditulis oleh Vitalik. Artinya adalah Vitalik duduk, dia menulis sebuah proposal dan dia berkata saya ingin hal-hal ini masuk ke dalam Ethereum dan tidak ada yang setuju — hal-hal ini hanya diam di sana. Dia tidak dapat memasukkannya ke dalam protokol. Jadi tidak semua yang dia usulkan secara otomatis disertakan.

Salah satu perluasan dari hal itu adalah Yayasan Ethereum mengendalikan segalanya. Saya akan mengambil contoh spesifik tentang suatu waktu yang menurut saya bertentangan dengan hal itu. Pada tahun 2024 ada banyak pembicaraan tentang batas gas. Dan alasannya adalah pada tahun 2022 selama The Merge, kita menaikkan batas gas menjadi 30 juta. Itu adalah komputasi maksimal yang diizinkan dalam sebuah blok. Dan kemudian kita seolah tidak menyentuhnya untuk sementara waktu karena itu bukanlah hambatan yang membuat orang berkata, "Inilah sebabnya saya tidak pindah ke Ethereum" atau "Ini membatasi kasus penggunaan Ethereum saya saat ini."

Dan pada akhir tahun 2023, awal tahun 2024, ada narasi bahwa Solana akan datang. Solana akan mengalahkan Ethereum. Jadi orang-orang berpikir tentang apa yang dapat dilakukan Ethereum untuk berakselerasi. Dan salah satu halnya adalah mari kita tingkatkan metrik gas ini. Dan pada saat itu EF dan pengembang klien seolah berkata, "Kami punya hal lain yang harus dikhawatirkan. Tapi terima kasih." Namun dua orang ini, Eric Connor dan Mariano Conti, datang dan berkata, "Tidak, kita akan menaikkan batas gas." Batas gas adalah parameter yang dikendalikan oleh validator. Jadi mereka bisa mulai berbicara dengan validator, operator profesional, dan berkata, "Hei, naikkan batas gas Anda."

Dan pada titik tertentu ada cukup banyak adopsi sehingga EF dan klien-klien berpikir, "Oh, kita harus memperhatikan hal ini. Kita harus memastikan apa yang mereka lakukan itu aman dan bahwa nilai yang akhirnya mereka naikkan akan menjadi hal yang aman bagi jaringan." Jadi, mereka harus mengalokasikan ulang sumber daya mereka. Nethermind muncul dengan kerangka pengujian ini. EF melakukan banyak pekerjaan di Berlin. Semua pengembang klien melakukan tolok ukur untuk hal ini. Dan saya menyukai hal ini karena ini memaksa EF untuk memutuskan apa yang diprioritaskan.

Dan saya suka cuitan konyol yang saya tangkap layarnya di sini karena ini seperti beberapa outlet berita acak yang menyebut Eric Connor dan Mariano Conti sebagai pengembang inti. Mereka bukan pengembang inti. Eric Connor adalah seorang staker dan anggota komunitas. Mariano Conti adalah mantan pengembang aplikasi MakerDAO. Tetapi mereka hanya disebut pengembang inti karena pengembangan Ethereum benar-benar berada di luar dunia cara kerja perangkat lunak tradisional dan karenanya mereka melihat parameter inti sedang dimodifikasi dan mereka berpikir, "Oh, ini pasti pengembang inti." Padahal bukan. Jadi ini hanyalah contoh anggota komunitas yang datang dan berkata kami ingin melihat perubahan ini dan mewujudkannya.

Semuanya adalah kesepakatan di ruang tertutup, orang dalam, para OG — saya sedikit lebih mengerti mengapa ini adalah sebuah kesalahpahaman karena pada dasarnya Anda datang ke panggilan tata kelola ini, ada seratus orang dalam panggilan tata kelola ini. Sepertinya mereka semua sangat nyaman dengan apa yang sedang terjadi. Anda merasa tersesat. Anda tidak tahu bagaimana keputusan ini dibuat. Anda berpikir, "Apakah sudah giliran saya untuk berbicara?" Dan rasanya seperti orang-orang mendengarkan 10 orang yang sama untuk membuat keputusan ini.

Meritokrasi dan statistik partisipasi (10:18)

Namun kenyataannya, pengembangan Ethereum lebih merupakan sebuah meritokrasi daripada yang pernah saya lihat di sebagian besar pengembangan perangkat lunak. Semua orang di tangkapan layar ini — ini adalah satu dari tiga panggilan ACD acak yang saya putuskan untuk ditangkap layarnya — tidak satu pun dari orang-orang ini yang ditunjuk untuk berada di sini. Semua orang hanyalah orang-orang yang hadir. Mereka adalah para pengembang yang telah menghabiskan banyak waktu dengan protokol ini. Mereka adalah orang-orang yang diakui sebagai pengembang berbakat di ruang ini yang secara konsisten membuat keputusan yang baik, dan tidak ada seorang pun di sini yang ditunjuk untuk berada di sini.

Jadi saya baru bergabung dengan EF sedikit lebih dari setahun yang lalu. Saya mengambil statistik ini. Data ini hanya mundur hingga Maret 2025. Jadi kurang dari setahun. Rata-rata peserta All Core Dev — yaitu panggilan tata kelola — adalah 98. Jadi rata-rata ada 98 orang dalam panggilan ini. Peserta maksimal dalam satu panggilan sejak saat itu adalah 153. Saya rasa itu adalah hari di mana kami memutuskan tanggal Mainnet Pectra. Dan total peserta unik adalah 567 hanya dalam setahun terakhir. Saya sangat menyukai metrik itu karena itu menunjukkan bahwa bukan 100 orang yang sama yang menghadiri panggilan ini setiap saat. Para pengembang aplikasi, peneliti, seseorang mendengar tentang suatu fitur yang sedang dibahas, mereka muncul untuk menyuarakan penolakan atau dukungan mereka terhadapnya dan kemudian mereka tidak datang ke panggilan lain.

Bagaimana proses tata kelola bekerja (11:52)

Jadi ini adalah salindia yang agak membosankan tetapi saya pikir penting untuk dibahas — begitulah cara tata kelola Ethereum saat ini bekerja. Jadi ketika salah satu percabangan ini sedang dibahas, hal pertama yang terjadi adalah orang-orang selama jendela waktu yang dialokasikan ini dapat mengirimkan proposal utama mereka. Proposal utama adalah fitur besar yang kami ingin agar orang-orang berkumpul untuk mendukungnya pada percabangan ini. Ini bisa berupa anggota komunitas, peneliti, pengembang inti — benar-benar siapa saja yang mengirimkan salah satu proposal utama ini. Kemudian jendelanya berakhir dan pada panggilan tata kelola kami semacam membahas mana dari proposal ini yang masuk akal. Orang-orang menyampaikan argumen mereka, orang-orang berdebat dan ada konsensus seputar mana yang harus kita pilih untuk percabangan yang akan datang tersebut.

Setelah itu mereka memilih fitur-fitur minor. Jadi hal-hal yang lebih kecil yang tidak benar-benar perlu menjadi fitur utama pendorong percabangan ini. Dan sepanjang waktu ini kami memiliki devnet khusus fitur. Devnet itu seperti testnet — jaringan pengujian pribadi bagi para pengembang untuk menguji fitur-fitur ini dan memastikan bahwa fitur-fitur tersebut benar-benar berfungsi di Ethereum. Dan kemudian pada titik tertentu ada pembekuan fitur. Jadi kami telah membahas fitur-fitur utama, kami telah membahas fitur-fitur minor, kami telah menjalankan devnet khusus fitur ini yang biasanya merupakan fitur utama percabangan. Dan itu adalah pembekuan fitur dengan tanda bintang karena pada titik itu kami telah memutuskan bahwa kami tidak akan menambahkan fitur apa pun lagi ke percabangan ini. Kami akan menjalankan semua fitur bersama-sama, memastikan semuanya baik-baik saja, memastikan tidak ada yang akan rusak. Tetapi jika sesuatu mulai memperlambat segalanya, jika percabangan tertunda, jika terlalu rumit, hal-hal masih dapat dikeluarkan pada titik tersebut.

Jadi setelah sejumlah devnet — bisa dua, bisa 10 — semua klien memutuskan pada titik tertentu bahwa ini sudah stabil. Kami memercayai apa yang sedang terjadi saat ini. Kami berada di posisi yang baik. Mari kita mulai berpikir untuk merilis ini ke Mainnet Ethereum. Mereka memotong rilis klien dan kemudian ada periode 30 hari di mana tim keamanan EF mengeluarkan sayembara bug. Mereka mengontrak audit keamanan. Dan kemudian pada akhir periode 30 hari itu kami meluncurkan percabangan ke testnet. Ini adalah testnet yang mungkin pernah Anda dengar — seperti Holesky. Di sinilah para pengembang aplikasi dapat menguji hal-hal mereka sebelum percabangan ditayangkan. Dan ini umumnya minimal 14 hari masing-masing hanya untuk memastikan bahwa semuanya baik-baik saja. Kami tidak mengharapkan adanya masalah besar karena ini telah melalui devnet khusus fitur dan devnet umum sebelumnya, tetapi secara historis ini telah merusak beberapa testnet ini. Jadi ini semacam panggilan terakhir untuk menemukan dan membasmi semua bug ini.

Dan kemudian setelah testnet tanpa izin stabil, tanggal Mainnet dipilih. Setelah itu, ada penyangga 30 hari. Penyangga 30 hari ini ada karena L2 dan protokol telah meminta ini agar bersiap untuk percabangan. Jadi itu minimal 30 hari dan kemudian percabangan terjadi.

Struktur panggilan dan koordinasi (15:01)

Selama waktu ini ada beberapa seri panggilan utama yang terjadi. Ini semua adalah panggilan publik yang disiarkan langsung di YouTube. Yang utama adalah ACDE dan ACDC. E adalah untuk lapisan eksekusi — itu adalah hal-hal seperti transaksi, penerapan kontrak pintar, manajemen mempool. ACDC adalah lapisan konsensus — jadi itu adalah hal-hal validator seperti manajemen validator, pemotongan. Dan itu bergantian setiap hari Kamis. Jadi ada ACD setiap hari Kamis dan salah satunya adalah ACDE dan kemudian yang berikutnya adalah ACDC, berlanjut seperti itu.

Panggilan ACDE dan ACDC berfokus pada percabangan yang sedang kami buat saat ini dan percabangan yang sedang kami cakup untuk masa depan. Panggilan ACDT lebih mendetail dan mendalam. Itu adalah klien yang berbicara tentang bug yang tidak dapat mereka lewati atau detail implementasi yang perlu diselesaikan tentang percabangan yang sedang mereka kerjakan saat ini. Jadi saat ini percabangan berikutnya yang terjadi adalah Glamsterdam. Jadi panggilan ACDT ini didominasi oleh percakapan tentang ePBS dan daftar akses tingkat blok yang merupakan hal-hal yang akan masuk ke Glamsterdam. Dan ini adalah panggilan yang sangat teknis.

Dan kemudian ada panggilan terobosan. Panggilan terobosan adalah anggota komunitas, peneliti, pengembang yang berkata, "Hei, saya punya fitur yang ingin saya masukkan ke Ethereum dua percabangan dari sekarang." Jadi mereka menyelenggarakan panggilan mingguan, bulanan, atau dua bulanan ini di mana mereka membahas detail implementasi, mengubah dan mengulangi spesifikasi, dan secara umum menjawab semua pertanyaan yang dimiliki orang-orang, semua hal yang tidak diketahui yang telah diketahui untuk memastikan bahwa itu berada di tempat terbaik untuk disertakan dalam percabangan dua percabangan dari sekarang. Dan itu dapat dijadwalkan kapan pun fasilitator memutuskan.

Proses yang terus berkembang (15:29)

Jadi satu hal yang ingin saya tekankan kepada semua orang adalah bahwa proses ini sama sekali tidak statis. Proses yang baru saja saya jelaskan kepada Anda ini telah berjalan kurang dari setahun. Ethereum telah berjalan selama 10 tahun. Tetapi ini terus berubah dan alasan mengapa ini terus berubah adalah karena tidak ada yang memegang kendali. Dan proses ini semacam berevolusi untuk mencari tahu cara paling efisien untuk beroperasi. Dan seperti yang saya katakan efisien, tetapi reputasi yang dimiliki tata kelola Ethereum adalah sangat mandek, sulit untuk meloloskan sesuatu, membingungkan — dan itu karena ketika Anda memiliki 100 hingga 500 orang yang membuat keputusan, sejujurnya saya terkesan bahwa ini bisa berhasil sama sekali.

Jadi Tim membuat sebuah pos pada bulan April 2025 yang berjudul "Reconfiguring All Core Devs" yang akhirnya menjadi proposal tentang bagaimana segala sesuatunya bekerja saat ini. Dan alasannya adalah karena sebelum itu kami semacam memiliki narasi kohesif ini tentang apa yang harus kami fokuskan di Ethereum. Ada The Merge yang merupakan usaha besar. Semua orang sangat bersemangat. Sebagian besar orang sangat bersemangat. Para penambang tidak. Dan kemudian setelah The Merge, Anda memiliki penarikan. Jadi, kami tidak ingin orang-orang mengunci ETH mereka ke dalam kontrak dan FUD ini menjadi seperti mereka tidak akan pernah bisa mengeluarkan ETH dari sini. Jadi, kami harus merilisnya secepat mungkin. Dan kemudian ada Proto-Danksharding dan kemudian Pectra datang dan Pectra semacam campuran dari berbagai EIP yang tidak terkait dan tidak benar-benar memiliki narasi yang kohesif. Dan itu menjadi sangat besar karena orang-orang semacam hanya memasukkan banyak hal karena kurangnya kohesi sehingga harus dipecah menjadi dua percabangan yang berbeda karena tim pengujian semacam berkata, "Cakupannya terlalu besar. Kami tidak dapat menguji semua ini."

Jadi dorongan Tim untuk melakukan ini adalah, oke, kita perlu memikirkan cara untuk menjaga percabangan ini tetap fokus dan sekohesif mungkin. Dan fitur utama semacam jawaban untuk itu. Tujuannya adalah untuk merilis dengan cara yang memprioritaskan agar terasa seperti semua orang tahu tentang apa percabangan itu, sehingga mereka tidak perlu memasukkan 25 EIP yang berbeda.

Jadi tangkapan layar lainnya di bagian atas adalah Tim yang mengusulkan definisi untuk tahap penyertaan EIP ini. Dan poin yang ingin saya sampaikan dengan ini adalah terkadang Anda mendengar orang mengatakan bahwa proses ini terlalu birokratis. Tetapi apa yang sebenarnya terjadi adalah orang-orang masuk ke dalam proses tata kelola ini dan mereka bertanya, "Bagaimana cara saya memasukkan EIP?" dan orang-orang yang telah berada di sana selama 10 tahun menjawab, "Anda semacam melakukannya saja." Dan orang-orang berpikir, "Ini mengerikan." Jadi apa yang dilakukan hal-hal ini adalah mereka menggambarkan apa yang terjadi untuk memudahkan pihak luar berpartisipasi dalam proses ini, karena jika Anda baru saja datang ke sini dan Anda berpikir, "Saya punya satu EIP, saya tidak peduli dengan tata kelola Ethereum, saya hanya ingin satu EIP ini masuk" — Anda menginginkan rubrik, Anda menginginkan daftar periksa, Anda menginginkan langkah demi langkah yang sangat jelas tentang cara memasukkan EIP ini. Jadi, sebagian besar dari hal-hal ini lebih tentang menggambarkan bagaimana prosesnya bekerja daripada menciptakan aturan birokrasi yang harus diikuti orang untuk mempersulit masuknya EIP.

Hal ketiga adalah komit dari waktu ke waktu di Forkcast. Forkcast adalah produk dari tim saya, oleh Wolfram Mark, seorang pria di tim saya yang membuat ini pada pertengahan tahun lalu ketika tim saya dalam iterasinya saat ini dibentuk. Dan ini telah menjadi sumber daya kanonis bagi orang-orang untuk digunakan berinteraksi dengan percabangan, untuk melihat apa yang masuk ke dalam percabangan dan bagaimana hal itu memengaruhi mereka. Semua hal ini berusia kurang dari dua tahun. Jadi poin yang saya sampaikan adalah proses ini banyak berubah. Ini sama sekali tidak statis. Ini bukan birokrasi beku yang sulit untuk Anda masuki.

Sistem tata kelola yang sebanding (20:21)

Jadi dengan cepat saya ingin menyinggung sistem tata kelola terdesentralisasi yang paling mirip yang dapat saya lihat dengan tata kelola Ethereum. Dan poin yang ingin saya sampaikan di sini adalah bahwa ini berkelanjutan — meskipun luar biasa bahwa 100 hingga 500 orang dapat membuat keputusan, ini berkelanjutan di dunia nyata. Kita memang melihat contoh-contoh dari hal ini yang berhasil.

IETF adalah Internet Engineering Task Force. Ini adalah badan standar yang dijalankan oleh sukarelawan yang menciptakan TCP/IP, HTTP. Ini adalah organisasi yang paling bertanggung jawab atas fakta bahwa kita memiliki internet gratis saat ini. Kernel Linux — ini adalah inti dari sistem operasi Linux. Jadi itu adalah perangkat lunak sumber terbuka yang menggerakkan server internet, ponsel Android, superkomputer. Perbedaannya di sana adalah bahwa mereka semacam memiliki model diktator yang baik hati dengan Linus Torvalds. Tetapi meskipun demikian mereka memiliki lebih dari 17.000 kontributor, yang mana sangat luar biasa.

Hal-hal yang tidak mirip dengan ini: rantai blok lain yang memiliki pemungutan suara token onchain. Ethereum secara khusus menghindari segala jenis mekanisme pemungutan suara karena menurut pendapat saya itu mengarah pada jalan untuk pengambilalihan dan itu semacam menghilangkan insentif untuk membuat segala sesuatunya menjadi meritokrasi di mana orang-orang hanya memercayai orang-orang yang menulis kode terbaik. Dan kemudian ada L2. Mereka memiliki multi-sig. Mereka memiliki dewan keamanan. Ini lebih seperti posisi yang ditunjuk yang membuat keputusan ini. Dan itu memiliki pengorbanannya. Ini lebih terpusat. Meskipun bergerak lebih cepat.

Mengapa pembangun peduli (22:38)

Jadi mengapa pembangun peduli dengan tata kelola? Karena pembangun secara harfiah adalah untuk siapa Ethereum diciptakan. Ethereum tidak diciptakan untuk pengembang inti. Ini tidak diciptakan untuk validator. Terkadang orang-orang ini bingung tentang hal itu. Pengembang inti dan validator Ethereum melayani Ethereum yang melayani pembangun dan pengguna.

Dan semua orang pernah mengalami momen itu dengan AI di mana Anda terlalu mendalami detail dan AI mencoba memperbaiki hal kecil ini dan gagal untuk memperluas pandangan dan melihat keseluruhan tujuan proyek. Dan pengembang inti bisa seperti itu di mana mereka mencoba menyempurnakan proses pengembangan inti. Dan sangat penting dalam kasus itu bahwa pembangun masuk karena pengembangan inti sangat menyita waktu sehingga mereka tidak juga membangun di atas Ethereum pada sebagian besar waktu. Mereka sangat terlibat dalam pengembangan inti. Itu menyita seluruh waktu mereka. Jadi pembangun aplikasi benar-benar harus berusaha untuk masuk dan berkata, "Hei, kami membutuhkan ini. Ini sangat penting untuk Ethereum." Hanya untuk memastikan bahwa perspektif itu ada dan bahwa mereka tidak hanya terjebak dalam bekerja hanya untuk pengembang inti.

Cara berpartisipasi (24:40)

Jadi bagaimana Anda berpartisipasi atau memasukkan fitur Anda? Ini semacam saran umum, tetapi saya pikir ini yang terbaik. Bersuaralah tentang titik masalah Anda. Buka Twitter, tulis pos blog, identifikasi solusi untuk titik masalah Anda. Berspekulasilah tentang hal-hal yang dapat membantu Anda. Jika Anda menemukan orang lain yang memiliki titik masalah yang sama, umumnya Anda dapat menemukan EIP yang ada untuk mengatasi titik masalah tersebut atau meminta seseorang membantu Anda menulis EIP yang melakukan hal itu.

Satu hal yang saya sukai dari perangkat lunak sumber terbuka adalah bahwa umumnya perusahaan dengan modal yang baik akan mengalokasikan waktu dan sumber daya pengembang mereka untuk memelihara perkakas sumber terbuka yang mereka gunakan. Dan akhirnya menjadi sekelompok perusahaan berbeda yang berkolaborasi dalam memelihara hal ini dan itu bisa menjadi cara kerjanya di Ethereum juga. Jadi jika Anda memiliki titik masalah yang telah Anda identifikasi, Anda dapat menemukan pengembang Base yang memiliki titik masalah serupa, dan Base adalah organisasi dengan modal yang baik sehingga mereka mungkin bersedia mengalokasikan beberapa sumber daya untuk merilis fitur atau mengawal fitur melalui percabangan keras Ethereum.

Saya hanya akan meninggalkan beberapa sumber daya untuk Anda. Forkcast.org — di sanalah Anda dapat pergi dan melihat apa yang masuk ke dalam percabangan, bagaimana hal itu memengaruhi pemangku kepentingan tertentu. Jadi, jika Anda seorang pengembang aplikasi, ada bagian untuk pengembang aplikasi. Jika Anda seorang pengembang dompet, pengembang klien lapisan konsensus, ada bagian tentang bagaimana semua itu memengaruhi Anda. YouTube adalah tempat semua video panggilan tersebut diunggah. Video tersebut juga disematkan di halaman forkcast.org/calls di mana terdapat ringkasan, atribusi pembicara, sehingga lebih mudah untuk menavigasi panggilan tersebut. Direktori EIP, forum Ethereum Magicians tempat Anda dapat berbicara dengan orang lain tentang solusi potensial atau EIP yang ingin Anda tulis. Dan sebentar lagi tim saya akan memiliki situs dukungan protokol. Kelihatannya luar biasa. Belum siap untuk dibagikan. Email saya juga ada di sana — nixo@ethereum.org (opens email client). Itu saja.