Aspek penting, dan terus-menerus diremehkan, dari "ketidakpercayaan", "lulus tes walkaway" dan "kedaulatan diri" adalah kesederhanaan protokol. Bahkan jika sebuah protokol sangat terdesentralisasi dengan ratusan ribu node, dan memiliki 49% toleransi kesalahan bizantium, dan node sepenuhnya memverifikasi semuanya dengan peerdas dan starks yang aman untuk kuantum, jika protokol tersebut berantakan ratusan ribu baris kode dan lima bentuk kriptografi tingkat PhD, pada akhirnya protokol tersebut gagal dalam ketiga pengujian: * Ini tidak tanpa kepercayaan karena Anda harus mempercayai kelas kecil imam besar yang memberi tahu Anda sifat apa yang dimiliki protokol tersebut * Itu tidak lulus tes walkaway karena jika tim klien yang ada hilang, sangat sulit bagi tim baru untuk mencapai tingkat kualitas yang sama * Ini tidak berdaulat sendiri karena jika bahkan orang yang paling teknis tidak dapat memeriksa dan memahami hal itu, itu tidak sepenuhnya milik Anda Ini juga kurang aman, karena setiap bagian protokol, terutama jika dapat berinteraksi dengan bagian lain dengan cara yang rumit, membawa risiko protokol rusak. Salah satu ketakutan saya dengan pengembangan protokol Ethereum adalah bahwa kita bisa terlalu bersemangat untuk menambahkan fitur baru untuk memenuhi kebutuhan yang sangat spesifik, bahkan jika fitur-fitur tersebut membengkakkan protokol atau menambahkan jenis komponen baru yang berinteraksi atau kriptografi yang rumit sebagai dependensi penting. Ini bisa bagus untuk keuntungan fungsionalitas jangka pendek, tetapi sangat merusak untuk mempertahankan kedaulatan diri jangka panjang, dan menciptakan hiperstruktur terdesentralisasi seratus tahun yang melampaui naik turunnya kerajaan dan ideologi. Masalah intinya adalah bahwa jika perubahan protokol dinilai dari perspektif "seberapa besar mereka sebagai perubahan pada protokol yang ada", maka keinginan untuk mempertahankan kompatibilitas mundur berarti bahwa penambahan terjadi lebih sering daripada pengurangan, dan protokol pasti membengkak seiring waktu. Untuk mengatasi hal ini, proses pengembangan Ethereum membutuhkan fungsi "penyederhanaan" / "pengumpulan sampah" yang eksplisit. "Penyederhanaan" memiliki tiga metrik: * Meminimalkan total baris kode dalam protokol. Protokol yang ideal cocok dengan satu halaman - atau setidaknya beberapa halaman * Menghindari ketergantungan yang tidak perlu pada komponen teknis yang kompleks secara fundamental. Misalnya, protokol yang keamanannya hanya bergantung pada hash (bahkan lebih baik: tepat pada satu fungsi hash) lebih baik daripada protokol yang bergantung pada hash dan kisi. Melemparkan isogeni adalah yang terburuk dari semuanya, karena (maaf untuk kutu buku pekerja keras yang benar-benar brilian yang menemukan hal-hal itu) tidak ada yang mengerti isogen. * Menambahkan lebih banyak _invarian_: properti inti yang dapat diandalkan protokol, misalnya EIP-6780 (penghapusan penghancuran sendiri) menambahkan properti bahwa paling banyak N slot penyimpanan dapat diubah per slot, secara signifikan menyederhanakan pengembangan klien, dan EIP-7825 (batas gas per tx) menambahkan maksimum pada biaya pemrosesan satu transaksi, yang sangat membantu ZK-EVM dan eksekusi paralel. Pengumpulan sampah bisa sedikit demi sepotong, atau bisa berskala besar. Pendekatan sedikit demi sedikit mencoba mengambil fitur yang ada, dan merampingkannya sehingga lebih sederhana dan lebih masuk akal. Salah satu contohnya adalah reformasi biaya gas di Glamsterdam, yang membuat banyak biaya gas yang sebelumnya sewenang-wenang, malah bergantung pada sejumlah kecil parameter yang jelas terkait dengan konsumsi sumber daya. Salah satu pengumpulan sampah skala besar adalah mengganti PoW dengan PoS. Yang lain kemungkinan akan terjadi sebagai bagian dari konsensus Lean, membuka ruang untuk memperbaiki sejumlah besar kesalahan pada saat yang sama ( ). Pendekatan lain adalah "kompatibilitas mundur gaya Rosetta", di mana fitur yang kompleks tetapi sedikit digunakan tetap dapat digunakan tetapi "diturunkan" dari menjadi bagian dari protokol wajib dan sebaliknya menjadi kode kontrak pintar, sehingga pengembang klien baru tidak perlu repot-repot dengannya. Contoh: * Setelah kami meningkatkan ke abstraksi akun asli penuh, semua jenis tx lama dapat dihentikan, dan EOA dapat diubah menjadi dompet kontrak pintar yang kodenya dapat memproses semua jenis transaksi tersebut * Kita dapat mengganti prakompilasi yang ada (kecuali yang _benar-benar_ diperlukan) dengan kode EVM atau RISC-V yang lebih baru * Kita akhirnya dapat mengubah VM dari EVM ke RISC-V (atau VM lain yang lebih sederhana); EVM dapat diubah menjadi kontrak pintar di VM baru. Akhirnya, kami ingin menjauh dari pengembang klien yang merasa perlu menangani semua versi lama dari protokol Ethereum. Itu dapat diserahkan kepada versi klien lama yang berjalan di kontainer buruh pelabuhan. Dalam jangka panjang, saya berharap tingkat perubahan ke Ethereum bisa lebih lambat. Saya pikir karena berbagai alasan bahwa pada akhirnya itu _harus_ terjadi. Lima belas tahun pertama ini sebagian harus dilihat sebagai tahap remaja di mana kita mengeksplorasi banyak ide dan melihat apa yang berhasil dan apa yang berguna dan apa yang tidak. Kita harus berusaha untuk menghindari bagian-bagian yang tidak berguna menjadi hambatan permanen pada protokol Ethereum. Pada dasarnya, kami ingin meningkatkan Ethereum dengan cara yang terlihat seperti ini: