Pengantar

Apa yang disimpan dan dirujuk oleh blockchain saat memproses transaksi disebut sebagai state. Di Ethereum, state adalah properti yang memfasilitasi konsensus node. Setiap node penuh perlu menyimpan dan memperbarui state ini selama setiap periode blok yang valid. State, seberapa penting pun mereka bagi blockchain, datang dengan kelemahan; mereka berkembang seiring waktu. Mereka menjadi masalah utama dalam blockchain, seperti Bitcoin dan Ethereum, karena peningkatan ukuran datang dengan peningkatan persyaratan perangkat keras untuk node. Ambang batas ruang membatasi beberapa node dari waktu ke waktu, menyebabkan terjadinya sentralisasi.EIP-2935mengusulkan untuk membawa tanpa status ke Ethereum, meringankan node dari beban ukuran. EIP-2935 adalah proposal perbaikan yang mencoba mencapai tanpa status dengan menyimpan dan melayani hash blok terakhir 8192 dari status untuk eksekusi tanpa status di Ethereum.

Gambaran Singkat Struktur Ethereum Saat Ini

Blok

Blok adalah kumpulan transaksi dengan referensi (hash) blok sebelumnya yang disertakan dalam rantai. Hash dalam setiap blok berasal dari data blok itu sendiri secara kriptografis. Penyertaan ini mengaitkan rantai bersama-sama dengan hash, dan pengumpulan mengimplikasikan bahwa semua peserta dalam jaringan setuju dan menyelaraskan status pada saat yang sama. Selain itu, kesepakatan tentang blok yang dikumpulkan memberi sinyal kepada Ethereum untuk memperbarui status globalnya di setiap peserta dalam jaringan sebagai node.

Alt: Perubahan status di Ethereum

Setelah blok baru ditangani dan disiarkan dengan validator di jaringan, peserta lainnya menambahkannya ke penyimpanan mereka dan memperbarui status global mereka. Validator dari setiap blok dipilih secara acak oleh Randomize Organisasi Otonom Terdesentralisasi (RANDAO)parameter. Struktur blok ini diatur secara ketat, dan proses penciptaan blok dan konsensus ditentukan dalam protokol bukti kepemilikan Ethereum.

Sebuah blok berisi beberapa bidang dalam header dan tubuhnya. Misalnya, header blok mencakup slot, proposer_index, parent_root, state_root, dan bidang tubuh. Tubuh blok mencakup randao_reveal, eth1_data, graffiti, proposer_slashings, attester_slashings, attestations, deposits, voluntary_exits, sync_aggregate, dan execution_payload. Setiap bidang memiliki parameter yang berbeda di dalamnya, dan menangani kebutuhan yang berbeda.

Ethereum’s12-detikperiode pembuatan blok, juga disebut sebagai “slot”, berasal dari memberikan cukup waktu bagi peserta jaringan untuk melakukan sinkronisasi dengan blok baru dan sepakat pada konsensus. Selama periode ini:

1. Pemilih blok secara acak memilih validator,
2. Validator mengelompokkan transaksi bersama-sama dan menjalankannya untuk menentukan keadaan global baru,
3. Mereka menyertakan informasi ini dalam blok baru dan menyiarakkannya ke sisa set validator melalui protokol gosip,
4. Validator lain menjalankan ulang transaksi untuk memastikan kevalidan dan setuju dengan perubahan status global sebagai konsensus,
5. Jika validator memverifikasi blok baru sebagai valid, mereka menambahkannya ke penyimpanan mereka.

Blok dan finalitas transaksi berarti tidak dapat diubah tanpa pembakaran ETH yang signifikan dalam jaringan terdistribusi. Ethereum memiliki pendekatan "blok pos pemeriksaan" untuk mengelola finalisasi. Blok pertama di setiap zaman diasumsikan sebagai pos pemeriksaan slot itu. Validator memilih asumsi ini untuk menjadikannya pos pemeriksaan yang valid. Jika dua pertiga dari total ETH yang dipertaruhkan dengan suara validator memilih sepasang pos pemeriksaan, pos pemeriksaan ditingkatkan menjadi dibenarkan. Pos pemeriksaan yang dibenarkan sebelumnya ditingkatkan setelah pos pemeriksaan berikutnya ditingkatkan, dan mereka menjadi final. Jika aktor jahat ingin mengembalikan blok final, ia perlu berkomitmen untuk kehilangan setidaknya sepertiga dari total pasokan ETH yang dipertaruhkan. Meskipun mekanisme disebut kebocoran ketidakaktifanada untuk mengembalikan kesimpulan dengan memberlakukan denda besar pada dana validator dan mengurangi imbalan pemberi kesaksian dalam kasus kegagalan permanen dari sejumlah besar validator.

Saat memproses blok, Ethereum menerapkan fungsi hash untuk mengambil data blok dan menguranginya menjadi string unik. Dalam fungsi hash, setiap input menghasilkan output yang unik. Nilai hash dalam blok adalah bagian yang tidak berubah. Ini dapat diubah dengan sepertiga dari total ETH yang dipertaruhkan terbakar. Namun, jumlah ini berasal dari menghitung ulang hash trie Merkle hingga checkpoint. Output dari proses hashing untuk setiap blok dikembalikan dengan parameter blockHash. Parameter blockHash mencakup semua data dalam blok.

Nilai hash blok dan parameter lain yang diperlukan disimpan dalam percobaan Merkle. Ethereum menggunakan arsitektur trie Merkle dengan berbagai versi, seperti Trie Patricia Merkle.

Pohon Merkle dan Pohon Merkle Patricia

Struktur trie, terutama Trie Merkle, sangat mendasar bagi penyimpanan blockchain. Tanpa Trie Merkle, blockchain menjadi blok tunggal yang sulit diproses setiap saat. Dengan Trie Merkle, atau secara umum arsitektur trie, blockchain mencapai kelengkapan dengan shard dasar. Ini memungkinkan mereka menjadi peserta jaringan dengan persyaratan perangkat keras yang rendah.

Merkle Tries adalah cara terstruktur untuk menghash sejumlah besar potongan dan membaginya menjadi bagian. Dengan Merkelization, data diatur dalam pasangan; masing-masing dihash bersama. Proses Merkelization diulang hingga diperoleh satu Merkle root tunggal.

Ethereum lebih memilih Merkle Patricia Tries, struktur dual Merkle trie. Itu menggunakan Binary Tries untuk penanganan data dasar, seperti data transaksi, karena pendekatan ini lebih efisien untuk situasi tersebut. Namun, Ethereum menggunakan Merkle Patricia Tries yang lebih kompleks dalam kasus-kasus kompleks, seperti penanganan state.

Dalam skenario penyimpanan data trie status, Ethereum memanfaatkan peta kunci-nilai. Kunci-kunci mewakili alamat, dan nilai-nilai mewakili deklarasi akun. Trie status lebih dinamis daripada trie biner. Oleh karena itu, akun baru dapat sering dimasukkan, dan kunci-kunci dapat sering dimasukkan dan dihapus. Proses ini memerlukan struktur data yang dapat diperbarui dengan cepat tanpa perlu menghitung ulang seluruh kumpulan data.

Akar trie bergantung hanya pada data, bukan urutannya. Memperbarui data dalam urutan yang berbeda tidak akan mengubah akar itu sendiri.

Alt: Binary Merkle Trie

Ethereum menggunakan Trie Patricia Merkle yang dimodifikasi, yang memiliki beberapa fitur dari PATRICIA (Practical Algorithm to Retrieve Information Coded in Alphanumeric)dan Merkle Trie dengan modifikasi sepanjang. Arsitektur ini bersifat deterministik dan dapat diverifikasi secara kriptografis. Satu-satunya cara untuk menghasilkan root state dalam struktur ini adalah dengan menghitungnya dari setiap bagian state secara individual. Dua state yang identik dapat dengan mudah dibuktikan dengan membandingkan root hash dan hash yang mengarah kepadanya.

Pada akhirnya, memodifikasi status dengan nilai yang berbeda tidak mungkin karena akan menghasilkan hash root status yang berbeda. Semua struktur trie dalam lapisan eksekusi Ethereum menggunakan Merkle Patricia Trie. Jaringan memiliki tiga trie: State Trie, Storage Trie, dan Transaction Trie. Selain itu, setiap blok memiliki Receipts Trie sendiri. Meskipun Merkle Patricia Tries efisien dalam banyak hal, Ethereum termotivasi untuk menggantinya dengan Verkle Tries untuk mencapai tanpa status.

Alt: Pohon Merkle Patricia

Gas

Gas adalah properti yang diperlukan dalam EVM untuk eksekusi. Karena EVM menggunakan dan membutuhkan sumber daya komputasi untuk mengeksekusi, pengembalian dari usaha tersebut dibayar dengan gas untuk memastikan keamanan EVM. Biaya gas dihitung sebagai jumlah gas yang diperlukan dikalikan dengan biaya per unit. Ini adalah nilai dinamis dan bergantung pada jenis operasi.

Alt: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

EIP-1559memperkenalkan beberapa perubahan signifikan pada mekanisme biaya transaksi. Membayar gas untuk memasukkan transaksi ke dalam blok bekerja dengan metode lelang di masa lalu. Dengan EIP-1559, ada batas minimum yang disebut biaya dasar dan tip yang disebut biaya prioritas diperkenalkan. Blok diajukan untuk dimulai dari transaksi dengan biaya prioritas tertinggi. Setelah proses blok, biaya dasar terbakar, dan biaya prioritas digunakan untuk mendorong validator.

Negara

Negara blockchain dapat didefinisikan sebagai seperangkat data (atau variabel) yang menggambarkan suatu sistem tertentu pada periode tertentu. Internet memiliki negara hampir sejak awal, tetapi disimpan di satu server. Dengan Web3, sebuah negara global dipelihara di jaringan terbuka dan terdistribusi yang diamankan melalui metode terdesentralisasi diperkenalkan. Setiap orang dapat melihat dan memverifikasi negara jaringan terdistribusi kapan pun mereka mau.

Ethereum mencakup akun, saldo, kontrak pintar yang diterapkan, dan penyimpanan terkait dalam keadaan global. Keadaan Ethereum berkembang dengan penambahan dan perubahan pada parameter-parameter ini. Pertumbuhan keadaan menjadi bermasalah ketika biaya perangkat keras untuk menyelenggarakan node penuh menjadi melarang. Menghadapi tantangan ini, Vitalik Buterin memperkenalkankonsep Ethereum tanpa negara pada tahun 2017. Metode yang diusulkan untuk memperbaiki pertumbuhan negara di Ethereum termasuk kedaluwarsa data dan negara.

Perbedaan Antara Kedaluwarsa Data dan Kedaluwarsa Status

Kedaluwarsa Data

Kedaluwarsa data atau sejarah berarti memangkas data yang tidak diperlukan dari klien setelah periode tertentu. Dengan "titik kontrol subjektivitas lemah," klien dapat menemukan cara mereka dalam penyelarasan dari genesis dan memangkas data limbah historis.

Subjektivitas mengacu pada simpul jaringan yang mengandalkan informasi sosial untuk mencapai konsensus tentang keadaan saat ini. Dalam konteks ini, subjektivitas lemah mengacu pada rantai yang dapat berkembang secara objektif dengan beberapa benih informasi awal yang diperoleh secara sosial. Namun, titik kontrol subjektivitas lemah menyiratkan bahwa semua simpul di jaringan yang bertanggung jawab atas konsensus termasuk dalam rantai kanonikal. Titik kontrol subjektivitas lemah membantu Ethereum PoS untuk memiliki keadaan terkini (titik kontrol subjektivitas lemah) dari sumber yang terpercaya untuk disinkronkan dari.

EIP-4444memberikan jalan praktis menuju@hBXHLw_9Qq2va4pRtI4bIA/ryzBaf7fJx?ref=ghost-2077.arvensis.systems">mencapai kadaluarsa data melalui subjektivitas yang lemah. Proposal ini tidak bertujuan untuk mengubah bagaimana node Ethereum menangani data status; sebaliknya, ia memodifikasi akses ke data historis.

Kadaluwarsa State

State Expiry bertujuan untuk menghapus status dari node individu jika tidak diakses baru-baru ini. Kedaluwarsa dapat diimplementasikan dengan terminasi sebagai faktor sewa atau waktu. Kedaluwarsa berarti memberlakukan biaya tambahan pada akun untuk menyimpan status. Di sisi lain, kedaluwarsa berarti membuat akun menjadi tidak aktif jika tetap tidak aktif selama periode tertentu.

Baik Data maupun Kedaluwarsa Status merupakan area penelitian terbuka. Pendekatan saat ini untuk mencapai status yang diusulkan melibatkan melewati jaringan/penyedia terpusat. Sejauh ini, keadaan tanpa keadaan yang lemah dan kedaluwarsa status telah tercapai sebagian dalam Ethereum.

Ethereum tanpa status

Pengantar tentang Statelessness dan Stateless Ethereum

Stateless Ethereum memperkenalkan konsep baru ke dalam protokol inti. Idealnya, tanpa keadaan tidak berarti bahwa keadaan tidak ada. Lebih tepatnya, itu berarti klien dapat memilih keadaan yang ingin mereka pertahankan. Ketika klien menerima blok yang divalidasi, mereka juga menerima saksi yang sesuai untuk blok tersebut. Saksi untuk setiap blok terdiri dari semua data yang diperlukan untuk mengeksekusi transaksi yang terdapat dalam blok tersebut.

EIP-161memperkenalkan pendekatan pengurangan keadaan pertama. Ethereum mengalami serangan DoS (Denial of Service), dan kerentanan ini memungkinkannya membuat akun kosong yang meningkatkan keadaan global Ethereum. EIP-161 mengusulkan untuk menghapus akun kosong dengan nilai nol (0) pada nonce mereka yang berasal dari serangan ini, dengan biaya rendah. Usulan tersebut dieksekusi, mengakibatkan revert keadaan.

Upaya lain menuju tanpa negara diajukan melalui EIP-4788. Usulan ini bertujuan untuk mengekspos akar dari blok rantai beacon di EVM. Serupa dengan pendekatan dari Jembatan Eth1-Eth2Menghubungkan rantai Beacon (lapisan konsensus) dan lapisan eksekusi, proposal ini memungkinkan akses minim kepercayaan antara EVM dan lapisan konsensus.

Karena setiap blok eksekusi mengandung root blok penanda induk, acara slot yang terlewatkan tidak perlu mengubah root blok sebelumnya. Oleh karena itu, prasyarat eksekusi menyempit menjadi mereservasi ruang kecil untuk oracle yang terdesentralisasi kepercayaan di setiap blok eksekusi. Usulan tersebut menyarankan untuk menyimpan sejarah kecil root blok dalam kontrak root untuk meningkatkan efisiensi oracle.

Tanpa negara di Ethereum dapat terjadi baik sebagai lemah maupun kuat.

Kelemahan Tanpa Keadaan

Ketidakberadaan negara yang lemah adalah sebuah status yang tidak menghilangkan kebutuhan akan penyimpanan negara di semua node. Sebaliknya, status tersebut berbeda dalam bagaimana node-node memverifikasi perubahan pada negara Ethereum. Hal ini menempatkan tanggung jawab penyimpanan negara pada penyarankan blok dan memerlukan node-node lain untuk memverifikasi blok tanpa menyimpan data negara lengkap.

Penyedia blok perlu menyimpan data status lengkap. Namun, klien verifikasi tidak perlu menyimpan data status di jaringan. Sebaliknya, mereka dapat menyimpan akar status (sebuah hash dari seluruh status). Kelemahan Tanpa Status memerlukanPemisahan Pengusul-Pembangun (PBS)danVerkle mencobaimplementasi.

Penyaji membuat saksi menggunakan data negara untuk membuktikan perubahan negara, dan validator memverifikasi bukti-bukti terhadap hash akar negara.

Keadaan Tanpa Negara yang Kuat

Keadaan tanpa negara yang kuat menghilangkan kebutuhan bagi setiap node untuk menyimpan data negara. Ini bekerja dengan memasukkan transaksi yang dikirim dan saksi yang diagregat oleh para penyusun blok. Penyusun blok hanya menyimpan negara yang sedang mereka kerjakan, menghasilkan saksi untuk akun yang relevan. Usul ini masih memerlukan pengembangan lebih lanjut dan mencakup persyaratan seperti Daftar Aksesatau EIP-2930.

Namun, beberapa perubahan dan properti dapat digunakan untuk mencapai ketiadaan keadaan. EIP-2935 mengusulkan untuk melayani hash blok historis dari negara untuk memungkinkan eksekusi tanpa keadaan.

Pengenalan untuk EIP-2935

EIP-2935 bertujuan untuk menyimpan hash blok historis di dalam state blockchain dalam slot penyimpanan khusus yang disebut HISTORY_STORAGE_ADDRESS. Proses ini akan memungkinkan eksekusi stateless dengan memfasilitasi akses mudah ke informasi historis yang diperlukan dalam klien stateless.

EIP-2935 mengusulkan untuk menyimpan 8192 hash blok historis terakhir dalam kontrak sistem untuk digunakan sebagai bagian dari logika pemrosesan blok. Masalah yang coba dipecahkan oleh usulan ini adalah asumsi EVM bahwa klien memiliki hash blok terbaru. Pendekatan berbasis asumsi ini tidak berlaku untuk Ethereum masa depan dan khususnya klien stateless.

Termasuk hash blok sebelumnya dalam keadaan akan memungkinkan pengikatan hash ini dengan fungsi hash di mata saksi. Seorang saksi kemudian akan diberikan kepada klien tanpa keadaan untuk memverifikasi eksekusi dan mencapai eksekusi tanpa keadaan. Usulan ini disebut spesiasi pra-Verkle karena dapat diimplementasikan sebelum adaptasi ke Verkle tries dalam protokol inti, dan memfasilitasi tanpa keadaan parsial.

Memperluas rentang blok yang disajikan oleh blockHash menjadi 8192 blok akan memungkinkan transisi lunak ke metode eksekusi. Rollups dapat diuntungkan dari jendela riwayat yang lebih panjang ini dengan langsung mengakses kontrak ini karena data blockHash disimpan dalam kontrak ini. Selain itu, EIP ini akan memfasilitasi validasi bukti terkait jumlah blok 8192 dari HISTORY_SERVE_WINDOW terhadap keadaan saat ini.

Memahami EIP-2935

EIP-2935 memungkinkan klien Ethereum, terutama yang tanpa keadaan, untuk dengan mudah mengakses hash blok terbaru. Untuk membuat ini berfungsi, itu memperkenalkan empat parameter baru:

• WINDOW_PELAYANAN_BLOCKHASH: Memberi tahu klien berapa banyak hash blok masa lalu yang harus mereka simpan. Nilai defaultnya adalah 256.
• HISTORY_SERVE_WINDOW: Parameter ini menentukan berapa banyak blok nilai hash yang disimpan. Nilai defaultnya adalah 8191.
• SYSTEM_ADDRESS: Alamat khusus (awalnya diperkenalkan di EIP-4788) yang bertindak sebagai "pemanggil" untuk menulis hash blok ke dalam penyimpanan.
• HISTORY_STORAGE_ADDRESS: Alamat kontrak di mana hash blok ini disimpan.

Spesifikasi proposal mengarahkan hash blok terakhir HISTORY_SERVE_WINDOW disimpan dalam penyimpanan buffer lingkaran dengan panjang HISTORY_SERVE_WINDOW.

Ring Buffer

EIP-2935 menggunakan fitur tambahan yang disebut ring buffer untuk penyimpanan sementara. Ring buffer adalah properti yang memungkinkan jaringan untuk menggunakan kembali penyimpanan yang sama untuk data yang berbeda. Penyimpanan dibatasi dalam ring buffer ke lokasi penyimpanan yang sama setiap kali. Ring buffer pada EIP-2935 digunakan hanya untuk melayani HISTORY_SERVE_WINDOW yang diperlukan, karena EIP-4788 dan akumulator state beacon memungkinkan bukti terhadap setiap leluhur.

Aturan Pemilihan Fork dan Spesifikasi

Setelah fork, ketika jaringan dimulai dengan pertimbangan EIP ini, parameter HISTORY_STORAGE_ADDRESS akan disebut sebagai SYSTEM_ADDRESS dengan input block.parent.hash (default 32 byte), batas gas sebesar 30.000.000, dan nilai 0. Proses ini akan memicu fungsi set() dari kontrak sejarah.

Proses fork pasca-proposal berbeda dari proses fork reguler. Operasi set() ini adalah operasi sistem umum, namun panggilan mengikuti konvensi-konvensi ini:

• Harus dieksekusi hingga selesai
• Tidak dihitung terhadap batas gas blok
• Tidak mengikuti mekanisme pembakaran EIP-1559
• Jika tidak ada kode di ALAMAT_PENYIMPANAN_SEJARAH, panggilan harus gagal tanpa kesalahan fatal.

Proses ini harus mengisi periode blok HISTORY_SERVE_WINDOW untuk memenuhi periode pemicu buffer cincin. Kontrak sejarah hanya akan berisi hash induk blok bercabang, yang berfungsi sebagai hash referensi dan titik awal hashing baru.

Kontrak riwayat hash blok akan memiliki dua operasi: dapatkan() dan atur(). Operasi atur() diaktifkan jika penelepon kontrak dalam transaksi sama dengan ALAMAT_SISTEM yang diperkenalkan dengan EIP-4788. Jika penelepon dan ALAMAT_SISTEM tidak sama atau tidak memenuhi syarat, operasi dapatkan() diaktifkan.

Operasi get() digunakan dalam EVM untuk menemukan hash blok. Ini memungkinkan pemanggil untuk menyediakan nomor blok yang mereka minta, jika input calldata bukan 32 byte (yang berarti itu adalah hash blok.parent.valid) dan jika permintaan berada di luar rentang ([block.number-HISTORY_SERVE_WINDOW, block.number-1]), itu mengembalikan transaksi.

set() mengambil blok masukan.parent.hash sebagai calldata ketika pemanggil memanggil kontrak dengan transaksi. Ini juga mengatur nilai penyimpanan sebagai calldata[0:32] pada blok.nomor-1 % HISTORY_SERVE_WINDOW.

HISTORY_STORAGE_ADDRESS akan diterapkan melalui EIP-4788, yang disebut di atas sebagai cara mengakses hash blok secara langsung melalui lapisan konsensus EVM. HISTORY_STORAGE_ADDRESS akan memiliki nilai nonce sebagai 1 dan dikecualikan dari standar pembersihan nonce nol EIP-161.

Logika Transisi BLOCKHASH

Salah satu kekhawatiran tentang EIP ini adalah bagaimana cara terbaik untuk beralih logika resolusi BLOCKHASH setelah fork. Dua pendekatan utama sedang dipertimbangkan:

• Tunggu HISTORY_SERVE_WINDOW blok agar seluruh sejarah relevan dapat bertahan,
• Simpan semua hash blok terakhir HISTORY_SERVE_WINDOW pada blok fork.

Pengembang memilih opsi pertama. Lebih praktis karena tidak memerlukan perubahan sementara apa pun.

Apa perbedaan antara EIP-2935 dan EIP serupa?

EIP-EIP serupa telah diajukan sebelumnya untuk mengizinkan dan mencapai eksekusi tanpa status. EIP-2935 berbeda dari proposal sebelumnya karena menargetkan kompleksitas yang disorot di bawah ini.

• Pendekatan Struktur Trie: EIP-2935 tidak menggunakan struktur mirip trie dengan beberapa lapisan dan malah memilih untuk menggunakan daftar tunggal. Sebaliknya, EIP-4444 mengusulkan pemangkasan data historis pada klien eksekusi yang lebih lama dari setahun. EIP lain dengan ambisi serupa memiliki verkle trie sebagai persyaratan.
• Menulis EIP dalam Kode EVM: EIP-2935 tidak memerlukan perubahan dalam EVM.
• Penyimpanan Hash Berurutan yang Tak Terbatas: Penyimpanan hash berurutan tak terbatas tidak efisien. EIP ini mengatasi masalah ini dengan mengelompokkan hash.

Pertimbangan Keamanan

Karena EIP-2935 menggunakan kontrak pintar, itu berisiko terhadap serangan branch poisoning. Namun, ukuran state root membuat upaya pembaruan lambat dan serangan poisoning menjadi lebih mahal.

Apa yang Dapat Dibawa?

• Membuat Sistem Oracle Tanpa Kepercayaan Lebih Cepat: Dalam oracle berbasis Uniswap v2, siapa pun yang memiliki akses node Ethereum dapat menghasilkan bukti penyimpanan Uniswap dan mengirimkannya untuk validasi on-chain. Harga rata-rata ditentukan antara blok saat ini dan blok bukti yang disediakan, dengan bukti yang divalidasi hingga 256 blok, karena blockHash mendukung hingga 256 blok. Dengan memanfaatkan EIP-2935, proses ini dapat ditingkatkan dengan memungkinkan akses ke hash blok yang lebih lama, yang berarti bukti dapat divalidasi dalam jangka waktu yang lebih lama.
• Mengizinkan Kontrak untuk Mempertimbangkan Pernyataan Status Terdahulu, Tanpa Kepercayaan: perbaikan EIP-2935 menciptakan kemungkinan untuk melihat data blockchain dari dalam EVM, tanpa kepercayaan. Klien dapat menanyakan riwayat, mengambil hash-nya, dan memverifikasinya dengan node lain. Solusi ini dapat membuat klien ringan efisien dan mudah untuk diimplementasikan.
• Menghubungkan antara L1 <> L2: Untuk memverifikasi pesan dari L2, L1 perlu mengetahui tentang akar status L2 dan hash blok. Namun, L1 dalam keadaan saat ini tidak dapat mengakses hash blok sembarangan karena batasan gas dan kendala arsitektur. EIP-2935 memungkinkan L1 untuk memverifikasi data historis sembarangan dengan kemampuan untuk menyelidiki bukti inklusi untuk peristiwa lama. Akses dan kekuatan verifikasi akan meningkat, dan kinerja penghubungannya.

Kesimpulan

EIP-2935 mewakili langkah penting menuju pencapaian tujuan jangka panjang Ethereum tanpa status. Menyimpan 8192 hash blok terakhir dalam kontrak yang didedikasikan di dalam alamat status menangani pembatasan fundamental dalam desain saat ini. Asumsi Ethereum bahwa klien secara inheren memiliki akses ke hash blok terbaru menjadi usang dalam konteks eksekusi tanpa status, di mana klien tidak lagi mempertahankan seluruh status. EIP-2935 memecahkan masalah ini dengan memperkenalkan mekanisme ringan, efisien, dan tidak mengganggu yang memungkinkan klien tanpa status untuk mengakses data historis yang diperlukan tanpa memodifikasi EVM atau bergantung pada struktur data kompleks seperti coba Verkle.

Selain eksekusi tanpa status, proposal ini membuka manfaat lebih luas di seluruh ekosistem Ethereum. Ini meningkatkan kemampuan oracle tanpa kepercayaan, memperluas kegunaan klien ringan, dan memperkuat interoperabilitas antara solusi Layer 1 dan Layer 2 dengan memungkinkan verifikasi yang dapat diandalkan terhadap data status lama. Implementasinya mengandalkan desain yang bersih dan hemat gas, menggunakan penyimpanan ring buffer dan kontrak tingkat sistem yang menghindari kebutuhan untuk hardcode ke dalam EVM, menawarkan kesederhanaan dan skalabilitas.

Saat Ethereum terus berkembang menuju desentralisasi, skalabilitas, dan aksesibilitas yang lebih besar, EIP-2935 berfungsi sebagai perbaikan dasar. Ini menjembatani kesenjangan antara arsitektur yang memiliki keadaan saat ini dan masa depan yang tidak memiliki keadaan yang diharapkan serta menyiapkan dasar untuk infrastruktur yang lebih kokoh, efisien, dan tanpa izin di seluruh ekosistem blockchain.

Penyangkalan:

1. Artikel ini dicetak ulang dari [2077penelitian]. Semua hak cipta milik penulis asli [Yiğit Yektin]. Jika ada keberatan terhadap cetakan ulang ini, harap hubungi Belajar Gatetim, 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 saran investasi apa pun.
3. Tim Gate Learn melakukan terjemahan artikel ke dalam bahasa lain. Menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang kecuali disebutkan.