Saya duduk di sini menulis ini pada hari terakhir interop pengembang Ethereum di Kenya, di mana kami membuat kemajuan besar dalam mengimplementasikan dan menyelesaikan detail teknis dari perbaikan Ethereum yang penting yang akan datang, terutamaPeerDAS, yang transisi pohon verkledan pendekatan terdesentralisasi untuk menyimpan sejarah dalam konteksEIP 4444Dari sudut pandang saya sendiri, terasa seperti laju pengembangan Ethereum, dan kapasitas kami untuk meluncurkan fitur-fitur besar dan penting yang secara signifikan meningkatkan pengalaman bagi operator node dan pengguna (L1 dan L2), semakin meningkat.

Tim klien Ethereum bekerja sama untuk merilis Pectra devnet.

Dengan kapasitas teknis yang lebih besar ini, satu pertanyaan penting yang harus diajukan adalah: apakah kita sedang membangun menuju tujuan yang tepat? Salah satu cara untuk memikirkan hal ini adalah serangkaian cuitan tidak senang dari pengembang inti Geth yang telah lama, Peter Szilagyi:

Ini adalah kekhawatiran yang valid. Mereka adalah kekhawatiran yang banyak orang di komunitas Ethereum telah ungkapkan. Mereka adalah kekhawatiran yang saya juga pribadi rasakan dalam banyak kesempatan. Namun, saya juga tidak berpikir bahwa situasinya sama sekali tidak berharap seperti yang tersirat dalam cuitan Peter; sebaliknya, banyak dari kekhawatiran tersebut sudah sedang ditangani oleh fitur protokol yang sudah dalam proses, dan banyak lagi dapat ditangani dengan penyesuaian yang sangat realistis terhadap peta jalan saat ini.

Untuk melihat apa artinya dalam praktik, mari kita lihat tiga contoh yang diberikan oleh Peter satu per satu. Tujuannya bukanlah untuk fokus pada Peter secara khusus; mereka adalah kekhawatiran yang banyak dibagikan di antara banyak anggota komunitas, dan penting untuk mengatasinya.

MEV, dan ketergantungan pembangun

Di masa lalu, blok Ethereum dibuat oleh para penambang, yang menggunakan algoritma yang relatif sederhana untuk membuat blok. Pengguna mengirimkan transaksi ke jaringan p2p publik yang sering disebut sebagai “mempool” (atau “txpool”). Para penambang mendengarkan mempool, dan menerima transaksi yang valid dan membayar biaya. Mereka menyertakan transaksi yang bisa mereka lakukan, dan jika tidak cukup ruang, mereka memberikan prioritas berdasarkan biaya tertinggi terlebih dahulu.

Ini adalah sistem yang sangat sederhana, dan bersahabat terhadap desentralisasi: sebagai penambang, Anda hanya perlu menjalankan perangkat lunak default, dan Anda dapat mendapatkan tingkat pendapatan biaya yang sama dari sebuah blok yang dapat Anda dapatkan dari pertanian penambangan profesional. Namun, sekitar tahun 2020, orang-orang mulai mengeksploitasi apa yang disebut nilai ekstraksi penambang (MEV): pendapatan yang hanya bisa didapatkan dengan menjalankan strategi kompleks yang sadar akan aktivitas yang terjadi di dalam berbagai protokol defi.

Sebagai contoh, pertimbangkan pertukaran terdesentralisasi seperti Uniswap. Misalkan pada waktu T, nilai tukar USD/ETH - di pertukaran terpusat dan di Uniswap - adalah $3000. Pada waktu T+11, nilai tukar USD/ETH di pertukaran terpusat naik menjadi $3005. Tetapi Ethereum belum memiliki blok berikutnya. Pada waktu T+12, blok itu ada. Siapa pun yang membuat blok dapat membuat transaksi pertama mereka menjadi serangkaian pembelian Uniswap, membeli semua ETH yang tersedia di Uniswap dengan harga dari $3000 hingga $3004. Ini adalah pendapatan tambahan, dan disebut MEV. Aplikasi selain DEXes memiliki analogi mereka sendiri terhadap masalah ini. Flash Boys 2.0 kertasditerbitkan pada tahun 2019 membahas ini secara detail.

Sebuah grafik dari kertas Flash Boys 2.0 yang menunjukkan jumlah pendapatan yang dapat ditangkap menggunakan jenis pendekatan yang dijelaskan di atas.

Permasalahannya adalah bahwa hal ini merusak alasan mengapa penambangan (atau, setelah 2022, penyusunan blok) bisa menjadi "adil": sekarang, aktor besar yang memiliki kemampuan lebih baik untuk mengoptimalkan algoritma ekstraksi semacam ini bisa mendapatkan hasil yang lebih baik per blok.

Sejak saat itu telah terjadi perdebatan antara dua strategi, yang akan saya sebut minimasi MEV dan karantina MEV. Minimasi MEV hadir dalam dua bentuk: (i) bekerja secara agresif pada alternatif bebas MEV untuk Uniswap (mis. Pertukaran sapi) dan (ii) membangun teknik dalam protokol, seperti mempool terenkripsi, yang mengurangi informasi yang tersedia untuk produsen blok, dan dengan demikian mengurangi pendapatan yang dapat mereka dapatkan. Secara khusus, mempool terenkripsi mencegah strategi seperti serangan sandwich, yang menempatkan transaksi tepat sebelum dan sesudah perdagangan pengguna untuk memanfaatkannya secara finansial ("front-running").

Karantina MEV bekerja dengan menerima MEV, namun mencoba untuk membatasi dampaknya pada sentralisasi staking dengan memisahkan pasar menjadi dua jenis pelaku: validator bertanggung jawab untuk memberikan kesaksian dan mengajukan blok, namun tugas memilih konten blok diserahkan kepada pembangun khusus melalui protokol pelelangan. Staker individu sekarang tidak perlu lagi khawatir tentang mengoptimalkan arbitrase defi mereka sendiri; mereka hanya bergabung dengan protokol pelelangan, dan menerima tawaran tertinggi. Ini disebut sebagai pemisahan proposer/pembangun (PBS). Pendekatan ini memiliki preseden dalam industri lain: salah satu alasan utama mengapa restoran dapat tetap terdesentralisasi adalah karena mereka sering bergantung pada seperangkat penyedia yang cukup terkonsentrasi untuk berbagai operasi yang memiliki ekonomi skala besar. Sejauh ini, PBS telah cukup berhasil dalam memastikan bahwa validator kecil dan validator besar berada pada bidang bermain yang adil, setidaknya sejauh MEV yang bersangkutan. Namun, ini menciptakan masalah lain: tugas memilih transaksi mana yang akan disertakan menjadi lebih terkonsentrasi.

Pandangan saya tentang ini selalu bahwa minimalisasi MEV baik dan kita harus mengejarnya (saya pribadi menggunakan Cowswap secara teratur!) - meskipun mempool terenkripsi memiliki banyak tantangan, tetapi minimalisasi MEV kemungkinan tidak akan cukup; MEV tidak akan turun ke nol, atau bahkan mendekati nol. Oleh karena itu, kita perlu semacam karantina MEV juga. Ini menciptakan tugas yang menarik: bagaimana kita membuat "kotak karantina MEV" sekecil mungkin? Bagaimana kita memberi pembangun kekuatan sekecil mungkin, sambil tetap menjaga mereka mampu menyerap peran mengoptimalkan arbitrase dan bentuk pengumpulan MEV lainnya?

Jika para pembangun memiliki kekuatan untuk mengecualikan transaksi dari sebuah blok sepenuhnya, ada serangan yang dapat dengan mudah muncul. Misalkan bahwa Anda memiliki posisi utang yang dijamin (CDP)Dalam protokol defi, didukung oleh aset yang harganya turun dengan cepat. Anda ingin meningkatkan kolateral Anda atau keluar dari CDP. Pembangun jahat bisa mencoba berkolusi untuk menolak untuk menyertakan transaksi Anda, menundanya sampai harga turun cukup sehingga mereka dapat secara paksa melikuidasi CDP Anda. Jika itu terjadi, Anda harus membayar denda besar, dan pembangun akan mendapatkan bagian besar dari itu. Jadi bagaimana kita bisa mencegah pembangun mengesampingkan transaksi dan mencapai jenis serangan ini?

Di sinilah daftar inklusi masuk.

Sumber: posting ethresear.ch ini.

Daftar inklusi memungkinkan penyusun blok (artinya, pemegang taruhan) untuk memilih transaksi yang harus masuk ke dalam blok. Pembangun masih dapat mengubah urutan transaksi atau menyisipkan transaksi mereka sendiri, tetapi mereka harus menyertakan transaksi pemegang taruhan. Pada akhirnya, daftar inklusi telah dimodifikasiuntuk membatasi blok selanjutnya daripada blok saat ini. Dalam kedua kasus tersebut, mereka menghilangkan kemampuan pembangun untuk mendorong transaksi keluar dari blok sepenuhnya.

Semua di atas adalah lubang kelinci yang dalam dari latar belakang yang rumit. Tetapi MEV adalah masalah yang rumit; bahkan deskripsi di atas melewatkan banyak nuansa penting. Seperti pepatah lama, 'kamu mungkin tidak mencari MEV, tapi MEV sedang mencari kamu'. Para peneliti Ethereum sudah cukup sejalan dengan tujuan 'meminimalkan kotak karantina', mengurangi kerusakan yang dapat dilakukan oleh para pengembang (misalnya dengan mengesampingkan atau menunda transaksi sebagai cara menyerang aplikasi tertentu) sebanyak mungkin.

Dengan demikian, saya pikir kita dapat pergi lebih jauh. Secara historis, daftar inklusi sering kali dikonsepsikan sebagai fitur 'sampingan khusus': biasanya, Anda tidak akan memikirkannya, tetapi hanya sebagai langkah kedua jika pembangun jahat mulai melakukan hal-hal gila. Sikap ini tercermin dalam keputusan desain saat ini: dalam EIP saat ini, batas gas dari daftar inklusi adalah sekitar 2,1 juta. Tetapi kita dapat membuat pergeseran filosofis dalam cara kita memikirkan tentang daftar inklusi: anggaplah daftar inklusi sebagai blok, dan anggaplah peran pembangun sebagai fungsi di samping untuk menambahkan beberapa transaksi untuk mengumpulkan MEV. Bagaimana jika pembangun yang memiliki batas gas 2,1 juta?

Saya pikir ide-ide ke arah ini - benar-benar mendorong kotak karantina menjadi sekecil mungkin - sangat menarik, dan saya mendukung untuk pergi ke arah itu. Ini adalah pergeseran dari "filosofi era 2021": dalam filosofi era 2021, kami lebih antusias dengan gagasan bahwa, karena kami sekarang memiliki pembangun, kami dapat "membebani" fungsionalitas mereka dan meminta mereka melayani pengguna dengan cara yang lebih rumit, misalnya. dengan mendukung Pasar biaya ERC-4337. Dalam filosofi baru ini, bagian validasi transaksi dari ERC-4337 harus diabadikan ke dalam protokol. Untungnya, tim ERC-4337 sudah @yoavSemakin hangat tentang arah ini.

Ringkasan: Pemikiran MEV sudah kembali ke arah memberdayakan produsen blok, termasuk memberi produsen blok wewenang untuk langsung memastikan inklusi transaksi pengguna. Proposal abstraksi akun sudah kembali ke arah menghilangkan ketergantungan pada pengirim pusat, bahkan bundlers. Namun, ada argumen yang bagus bahwa kita belum cukup jauh, dan saya pikir tekanan yang mendorong proses pengembangan untuk pergi lebih jauh ke arah itu sangat disambut.

stake cair

Saat ini, para pengepul tunggal hanya menyumbang persentase kecil dari semua pengepulan Ethereum, dan sebagian besar pengepulan dilakukan oleh berbagai penyedia - beberapa operator terpusat, dan yang lainnya adalah DAO, seperti Lido dan RocketPool.

Saya telah melakukan penelitian sendiri - berbagai jajak pendapat [1] [2], survei, percakapan tatap muka, mengajukan pertanyaan “mengapa Anda - khususnya Anda - tidak melakukan staking solo hari ini?” Bagi saya, ekosistem staking solo yang kuat jauh lebih diinginkan untuk staking Ethereum, dan salah satu hal terbaik tentang Ethereum adalah kita benar-benar mencoba mendukung ekosistem staking solo yang kuat daripada hanya menyerah pada delegasi. Namun, kita masih jauh dari hasil tersebut. Dalam jajak pendapat dan survei saya, ada beberapa tren yang konsisten:

1. Sebagian besar orang yang tidak melakukan solo staking mengutip alasan utama mereka adalah minimum 32 ETH.
2. Dari mereka yang mengutip alasan lain, yang tertinggi adalah tantangan teknis dalam menjalankan dan memelihara node validator.
3. Hilangnya ketersediaan instan ETH, risiko keamanan kunci pribadi "panas", dan hilangnya kemampuan untuk berpartisipasi secara bersamaan dalam protokol defi, adalah kekhawatiran yang signifikan tetapi lebih kecil.

Alasan utama mengapa orang tidak melakukan staking sendiri, menurut jajak pendapat Farcaster.

Ada dua pertanyaan kunci yang perlu dipecahkan dalam penelitian staking:

1. Bagaimana kita menyelesaikan kekhawatiran ini?
2. Jika, meskipun ada solusi efektif untuk sebagian besar masalah ini, kebanyakan orang masih tidak ingin melakukan staking sendiri, bagaimana kita menjaga protokol tetap stabil dan tangguh terhadap serangan meskipun kenyataan tersebut?

Banyak item penelitian dan pengembangan yang sedang berlangsung ditujukan tepat untuk memecahkan masalah-masalah ini:

1. pohon VerkleplusEIP-4444memungkinkan node staking berfungsi dengan persyaratan hard disk yang sangat rendah. Selain itu, mereka memungkinkan node staking untuk sinkronisasi hampir instan, sangat mempermudah proses setup, serta operasi seperti beralih dari satu implementasi ke implementasi lainnya. Mereka juga membuat klien ringan Ethereum jauh lebih layak, dengan mengurangi bandwidth data yang diperlukan untuk menyediakan bukti untuk setiap akses keadaan.
2. Penelitian(misalnya proposal-proposal ini)menjadi cara untuk memungkinkan seperangkat valdiator yang jauh lebih besar (memungkinkan jumlah staking minimum yang jauh lebih kecil) sambil pada saat yang sama mengurangi overhead node konsensus. Ide-ide ini dapat diimplementasikan sebagai bagian darifinalitas slot tunggalMelakukan hal ini juga membuat klien ringan lebih aman, karena mereka akan dapat memverifikasi rangkaian lengkap tanda tangan daripada mengandalkan pada komite sinkronisasi).
3. Optimisasi klien Ethereum yang terus berlanjut terus mengurangi biaya dan kesulitan menjalankan node validator, meskipun sejarah yang terus berkembang.
4. Penelitian tentangpenalti penutupandapat mengurangi kekhawatiran seputar risiko kunci pribadi, dan memungkinkan penjaga untuk secara bersamaan melakukan penjagaan ETH mereka di protokol defi jika itu yang mereka inginkan.
5. 0x01 Kredensial Penarikanmemungkinkan staker untuk menetapkan alamat ETH sebagai alamat penarikan mereka. Hal ini membuat kolam staking terdesentralisasi lebih layak, memberi mereka keunggulan dibandingkan dengan kolam staking terpusat.

Namun, sekali lagi ada lebih banyak yang bisa kita lakukan. Secara teori memungkinkan untuk memungkinkan validator menarik dana dengan lebih cepat: Casper FFG tetap aman bahkan jika kumpulan validator berubah beberapa persen setiap kali melengkapinya (yaitu, sekali per epoch). Oleh karena itu, kita bisa mengurangi periode penarikan lebih banyak jika kita berusaha untuk itu. Jika kita ingin sangat mengurangi ukuran deposit minimum, kita bisa membuat keputusan sulit untuk berkompromi di arah lain, misalnya jika kita meningkatkan waktu finalitas sebesar 4x, itu akan memungkinkan sebuah@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">Pengurangan ukuran deposit minimum 4x. Finalitas slot tunggal kemudian akan membersihkan ini dengan bergerak melampaui model "setiap penyetor berpartisipasi dalam setiap epoch" secara keseluruhan.

Bagian penting lain dari seluruh pertanyaan ini adalah ekonomi staking. Pertanyaan kunci adalah: apakah kita ingin staking menjadi kegiatan yang relatif niche, atau apakah kita ingin semua orang atau hampir semua orang melakukan staking seluruh ETH mereka? Jika semua orang melakukan staking, maka tanggung jawab apa yang ingin kita semua ambil? Jika orang-orang akhirnya hanya mendelegasikan tanggung jawab ini karena malas, itu bisa berujung pada sentralisasi. Ada pertanyaan filosofis penting dan mendalam di sini. Jawaban yang salah bisa membawa Ethereum ke jalan sentralisasi dan “menciptakan kembali sistem keuangan tradisional dengan langkah-langkah ekstra”; jawaban yang benar bisa menciptakan contoh gemilang dari ekosistem sukses dengan sejumlah solo staker yang luas dan beragam serta kolam staking yang sangat terdesentralisasi. Ini adalah pertanyaan yang berkaitan dengan ekonomi inti Ethereum dan nilai-nilai, oleh karena itu kita memerlukan partisipasi yang lebih beragam di sini.

Persyaratan perangkat keras dari node

Banyak pertanyaan kunci dalam desentralisasi Ethereum pada akhirnya berkaitan dengan pertanyaan yang telah menentukan politik blockchainselama satu dekade: seberapa mudahnya kita ingin menjadikan menjalankan sebuah node, dan bagaimana?

Hari ini, menjalankan node itu sulit. Kebanyakan orang tidak melakukannya. Pada laptop yang saya gunakan untuk menulis posting ini, saya memiliki Ethernode, dan membutuhkan 2,1 terabyte - sudah hasil dari rekayasa perangkat lunak dan optimisasi yang heroik. Saya perlu pergi dan membeli hard drive tambahan 4 TB untuk dimasukkan ke dalam laptop saya agar bisa menyimpan node ini. Kita semua ingin menjalankan node menjadi lebih mudah. Di dunia ideal saya, orang-orang dapat menjalankan node di telepon mereka.

Seperti yang saya tulis di atas, EIP-4444 dan pohon Verkle adalah dua teknologi kunci yang membuat kita mendekati ideal ini. Jika keduanya diimplementasikan, persyaratan perangkat keras dari sebuah node secara masuk akal akhirnya dapat berkurang menjadi kurang dari seratus gigabyte, dan mungkin mendekati nol jika kita menghilangkan sepenuhnya tanggung jawab penyimpanan riwayat (mungkin hanya untuk node non-staking).Jenis 1 ZK-EVMsakan menghilangkan kebutuhan untuk menjalankan perhitungan EVM sendiri, karena Anda dapat hanya memverifikasi bukti bahwa eksekusinya benar. Dalam dunia ideal saya, kita menyatukan semua teknologi ini, dan bahkan dompet ekstensi browser Ethereum (mis. Metamask, Rabby) memiliki node bawaan yang memverifikasi bukti-bukti ini, melakukan sampel ketersediaan data, dan yakin bahwa rantai tersebut benar.

Visi yang dijelaskan di atas sering disebut sebagai "The Verge".

Ini semua diketahui dan dipahami, bahkan oleh orang-orang yang mengungkapkan kekhawatiran tentang ukuran node Ethereum. Namun, ada kekhawatiran penting: jika kita memindahkan tanggung jawab untuk memelihara status dan memberikan bukti, bukankah itu merupakan sebuah vektor sentralisasi? Meskipun mereka tidak dapat menipu dengan memberikan data yang tidak valid, apakah itu tidak tetap bertentangan dengan prinsip-prinsip Ethereum untuk terlalu bergantung pada mereka?

Salah satu versi kekhawatiran yang sangat dekat adalah ketidaknyamanan banyak orang terhadap EIP-4444: jika node Ethereum reguler tidak perlu lagi menyimpan sejarah lama, maka siapa yang melakukannya? Jawaban umumnya adalah: pasti ada cukup banyak aktor besar (misalnya penjelajah blok, bursa, lapisan 2) yang memiliki insentif untuk menyimpan data tersebut, dan dibandingkan dengan 100 petabyte disimpan oleh Mesin Wayback, rantai Ethereum sangat kecil. Jadi sangat konyol untuk berpikir bahwa sejarah apa pun benar-benar akan hilang.

Namun, argumen ini bergantung pada ketergantungan pada sejumlah kecil aktor besar. Di saya taksonomi model kepercayaan, ini adalah asumsi 1-dari-N, tetapi N cukup kecil. Ini memiliki risiko ekor. Satu hal yang bisa kita lakukan sebagai gantinya adalah menyimpan riwayat lama dalam jaringan peer-to-peer, di mana setiap node hanya menyimpan persentase kecil dari data. Jenis jaringan seperti ini masih akan melakukan penyalinan yang cukup untuk memastikan kekuatan: akan ada ribuan salinan dari setiap potongan data, dan di masa depan kita bisa menggunakan pengkodean erasure (secara realistis, dengan menyimpan riwayat ke dalam EIP-4844gaya blob, yang sudah memiliki kode penghapusan yang terintegrasi) untuk meningkatkan kekuatan lebih jauh.

Blob memiliki pengkodean penghapusan dalam blob dan antara blob. Cara termudah untuk membuat penyimpanan ultra-kuat untuk seluruh sejarah Ethereum mungkin adalah dengan hanya memasukkan blok beacon dan blok eksekusi ke dalam blob.Sumber gambar: penyimpanan kode

Untuk waktu yang lama, pekerjaan ini telah ditunda; Portal JaringanAda, namun secara realistis, belum mendapat tingkat perhatian yang sebanding dengan pentingnya dalam masa depan Ethereum. Untungnya, sekarang ada minat kuat dalam momen menuju penempatan sumber daya yang jauh lebih besar ke versi Portal yang diminimalkan yang fokus pada penyimpanan terdistribusi, dan aksesibilitas, sejarah tersebut. Momentum ini harus dibangun, dan kita harus berupaya keras untuk menerapkan EIP-4444 segera, dipadukan dengan jaringan peer-to-peer terdesentralisasi yang kuat untuk menyimpan dan mengambil sejarah lama.

Untuk negara dan ZK-EVMs, pendekatan terdistribusi semacam ini lebih sulit. Untuk membangun blok yang efisien, Anda hanya perlu memiliki seluruh keadaan. Dalam hal ini, saya pribadi lebih memilih pendekatan pragmatis: kita mendefinisikan, dan tetap pada, beberapa tingkat persyaratan perangkat keras yang diperlukan untuk memiliki “node yang melakukan segalanya”, yang lebih tinggi dari biaya (ideally ever-decreasing) dari sekadar memvalidasi rantai, tetapi masih cukup rendah untuk terjangkau oleh penggemar. Kami mengandalkan asumsi 1-of-N, di mana kami memastikan bahwa N cukup besar. Sebagai contoh, ini bisa menjadi laptop konsumen kelas atas.

ZK-EVM yang terbukti kemungkinan akan menjadi bagian tersulit, dan pembuktian ZK-EVM waktu nyata kemungkinan akan memerlukan perangkat keras yang jauh lebih tangguh daripada node arsip, bahkan dengankemajuan seperti Binius, dan terburuk yang dibatasi dengan kasus gas multidimensiKita bisa bekerja keras pada jaringan pembuktian terdistribusi, di mana setiap node mengambil tanggung jawab untuk membuktikan misalnya satu persen dari eksekusi blok, dan kemudian produsen blok hanya perlu mengumpulkan seratus bukti pada akhirnya. Pohon agregasi bukti bisa membantu lebih lanjut. Tetapi jika ini tidak berfungsi dengan baik, maka kompromi lainnya adalah memperbolehkan persyaratan perangkat keras pembuktian meningkat, tetapi pastikan bahwa sebuah “node yang melakukan segalanya” dapat memverifikasi blok Ethereum secara langsung (tanpa bukti), cukup cepat untuk efektif berpartisipasi dalam jaringan.

Kesimpulan

Saya pikir benar bahwa pemikiran Ethereum era 2021 sebenarnya menjadi terlalu nyaman dengan melepaskan tanggung jawab kepada sejumlah aktor skala besar, selama ada mekanisme pasar atau sistem bukti pengetahuan nol yang ada untuk memaksa aktor terpusat bertindak jujur. Sistem-sistem seperti itu sering kali berfungsi dengan baik dalam kasus rata-rata, tetapi gagal secara kritis dalam kasus terburuk.

Kami tidak melakukan ini.

Pada saat yang sama, saya pikir penting untuk menekankan bahwa proposal protokol Ethereum saat ini sudah jauh bergerak dari jenis model tersebut, dan menganggap kebutuhan akan jaringan yang benar-benar terdesentralisasi jauh lebih serius. Ide-ide seputar node-stateless, mitigasi MEV, finalitas single-slot, dan konsep-konsep serupa, sudah jauh lebih maju ke arah ini. Setahun yang lalu, gagasan untuk melakukan sampling ketersediaan data dengan cara menyusupkan diri melalui relay sebagai node semi-terpusat sangat dipertimbangkan. Tahun ini, kita sudah melampaui kebutuhan untuk melakukan hal-hal seperti itu, dengan kemajuan yang cukup solid padaPeerDAS.

Tetapi ada banyak hal yang bisa kita lakukan untuk lebih jauh ke arah ini, pada ketiga sumbu yang saya bicarakan di atas, serta banyak sumbu penting lainnya.HeliosTelah membuat kemajuan besar dalam memberikan Ethereum sebuah "klien ringan aktual". Sekarang, kita perlu membuatnya termasuk secara default dalam dompet Ethereum, dan membuat penyedia RPC menyediakan bukti bersama dengan hasil mereka sehingga dapat divalidasi, dan memperluas teknologi klien ringan ke protokol lapisan 2. Jika Ethereum sedang mengalami peningkatan melalui peta jalan yang berpusat pada rollup, lapisan 2 perlu mendapatkan jaminan keamanan dan desentralisasi yang sama dengan lapisan 1. Dalam dunia yang berpusat pada rollup, ada banyak hal lain yang seharusnya kita ambil lebih serius; jembatan lintas-L2 desentralisasi dan efisien adalah salah satu contoh dari banyak contoh. Banyak dapps mendapatkan log mereka melalui protokol terpusat, karena pemindaian log asli Ethereum telah menjadi terlalu lambat. Kita bisa meningkatkan hal ini dengan sub-protokol terdesentralisasi yang didedikasikan;@vbuterin/parallel_post_state_roots">ini adalah salah satu proposal dari saya tentang bagaimana ini bisa dilakukan.

Ada sejumlah proyek blockchain yang hampir tak terbatas yang bertujuan untuk bidang 'kami bisa sangat cepat, kita akan memikirkan desentralisasi kemudian'. Saya tidak berpikir Ethereum harus menjadi salah satu dari proyek-proyek tersebut. Ethereum L1 dapat dan tentu harus menjadi lapisan dasar yang kuat untuk proyek-proyek lapisan 2 yang mengambil pendekatan hiper-skala, menggunakan Ethereum sebagai tulang punggung untuk desentralisasi dan keamanan. Bahkan pendekatan berbasis lapisan 2 memerlukan lapisan 1 itu sendiri memiliki skalabilitas yang cukup untuk menangani sejumlah operasi yang signifikan. Namun, kita harus memiliki rasa hormat yang mendalam terhadap sifat-sifat yang membuat Ethereum unik, dan terus bekerja untuk mempertahankan dan meningkatkan sifat-sifat tersebut seiring dengan skala pertumbuhan Ethereum.

Penafian:

1. Artikel ini dicetak ulang dari [[Vitalik Buterin]], Semua hak cipta milik penulis asli [Vitalik Buterin]. Jika ada keberatan terhadap pencetakan ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.