State Trie

Apa Itu State Trie dalam Kripto?

State trie adalah struktur data kriptografis yang menyimpan state saat ini dari sebuah blockchain sehingga dapat diperbarui, diverifikasi, dan diringkas secara efisien oleh satu root hash.

Dalam blockchain bergaya Ethereum, state trie adalah struktur yang memetakan alamat akun ke data akun seperti saldo, nonce, root penyimpanan smart contract, dan hash kode.

Dokumentasi resmi Ethereum Merkle Patricia Trie menjelaskan bahwa Ethereum memiliki satu state trie global yang diperbarui setiap kali klien memproses sebuah blok.

State trie global ini merupakan salah satu bagian terpenting dari execution layer Ethereum karena merepresentasikan state aktif jaringan setelah transaksi diterapkan.

State trie tidak sama dengan daftar transaksi historis.

Transaksi menjelaskan apa yang terjadi, sedangkan state trie menjelaskan seperti apa kondisi blockchain saat ini setelah transaksi tersebut mengubah saldo, penyimpanan kontrak, dan data akun.

Misalnya, jika pengguna mengirim ETH dari satu akun ke akun lain, transaksi dicatat dalam blok, tetapi state trie berubah karena saldo dua akun diperbarui.

Jika pengguna memanggil smart contract, transaksi dicatat dalam blok, tetapi state trie dapat berubah karena penyimpanan kontrak, saldo, dan nonce akun dapat diperbarui.

Sederhananya, state trie adalah database terautentikasi untuk state akun blockchain saat ini.

Mengapa State Trie Penting

State trie penting karena blockchain memerlukan cara yang aman untuk membuktikan state saat ini.

State blockchain dapat mencakup jutaan akun, smart contract, saldo, entri penyimpanan, dan nilai lainnya.

Node harus menyepakati state tersebut untuk menentukan apakah transaksi baru valid.

Jika pengirim tidak memiliki saldo yang cukup, transaksi seharusnya gagal.

Jika slot penyimpanan kontrak memiliki nilai tertentu, pemanggilan smart contract dapat berperilaku berbeda.

Jika nonce sudah digunakan, transaksi yang diputar ulang tidak boleh diterima.

State trie memberi klien struktur deterministik untuk menyimpan dan memeriksa nilai-nilai tersebut.

State trie juga menghasilkan satu state root yang dapat ditempatkan dalam block header.

Jika dua klien memproses blok yang sama dan mencapai state root yang sama, terdapat bukti kuat bahwa keduanya menyepakati state yang dihasilkan.

Hal ini menjadikan state trie sebagai elemen utama dalam konsensus blockchain, verifikasi, proof light client, sinkronisasi node, eksekusi smart contract, dan integritas data.

State Trie dan State Root

State root adalah root hash dari state trie setelah seluruh transaksi dalam sebuah blok diproses.

Block header Ethereum mencakup stateRoot, yang mengikat seluruh state global pada blok tersebut.

Dokumentasi Ethereum Merkle Patricia Trie menjelaskan bahwa block header execution layer Ethereum berisi root untuk state trie, transactions trie, dan receipts trie.

State root penting karena merupakan komitmen kriptografis yang ringkas terhadap database yang jauh lebih besar.

Pengguna tidak perlu mengunduh setiap nilai akun dan penyimpanan kontrak untuk memverifikasi klaim tertentu jika tersedia proof yang valid.

Sebaliknya, pengguna dapat memverifikasi bahwa suatu nilai termasuk dalam state yang dikomitmenkan oleh state root.

Jika saldo akun, root penyimpanan kontrak, nonce, atau hash kode berubah, jalur hash yang menuju root juga berubah.

Artinya, state yang berbeda seharusnya menghasilkan state root yang berbeda.

Oleh karena itu, state root merupakan sidik jari dari seluruh state blockchain pada blok tertentu.

State root membantu mengubah database state yang sangat besar menjadi satu nilai yang dapat diverifikasi.

Cara Kerja State Trie

State trie Ethereum menggunakan Merkle Patricia Trie yang dimodifikasi.

Merkle Patricia Trie menggabungkan konsep Merkle tree, radix trie, dan Patricia trie.

Trie adalah struktur key-value seperti pohon, tempat jalur dalam pohon ditentukan berdasarkan key.

Patricia trie mengompresi jalur agar pohon tidak membuang ruang untuk rantai panjang node kosong.

Merkle tree menambahkan hash kriptografis sehingga data dapat diverifikasi melalui jalur hash.

Ethereum menggabungkan fitur-fitur ini agar klien dapat menyimpan state akun, memperbaruinya secara efisien, dan memverifikasinya menggunakan root hash serta Merkle proof.

Dalam state trie Ethereum, jalurnya didasarkan pada hash Keccak-256 dari alamat akun.

Nilai yang disimpan pada jalur tersebut adalah objek akun yang dienkode dengan RLP.

Dokumentasi resmi Ethereum menyatakan bahwa objek akun Ethereum adalah array berisi empat item: nonce, balance, storageRoot, dan codeHash.

Desain ini membuat setiap akun dapat dijangkau melalui jalur kriptografis yang deterministik.

Data Apa yang Disimpan dalam State Trie?

State trie menyimpan objek akun, bukan setiap nilai penyimpanan kontrak secara langsung di dalam trie global utama.

Setiap objek akun Ethereum berisi nonce.

Setiap objek akun Ethereum berisi balance.

Setiap objek akun Ethereum berisi storageRoot.

Setiap objek akun Ethereum berisi codeHash.

Nonce membantu mencegah replay transaksi dan melacak aktivitas akun.

Balance mencatat jumlah mata uang native yang dimiliki oleh akun.

storageRoot menunjuk ke trie lain yang menyimpan penyimpanan smart contract untuk akun tersebut.

codeHash mengomitmenkan bytecode smart contract yang terkait dengan akun kontrak.

Akun yang dimiliki secara eksternal biasanya memiliki kode kosong dan penyimpanan kontrak kosong.

Akun smart contract dapat memiliki kode dan penyimpanan yang memengaruhi cara eksekusinya.

State Trie vs. Storage Trie

State trie dan storage trie saling terkait, tetapi berbeda.

State trie adalah struktur global yang memetakan alamat akun ke objek akun.

Storage trie adalah trie terpisah yang digunakan untuk penyimpanan akun smart contract tertentu.

Dokumentasi Ethereum menjelaskan bahwa terdapat storage trie terpisah untuk setiap akun yang memiliki penyimpanan kontrak.

Objek akun dalam state trie menyimpan storageRoot, yaitu root dari storage trie akun tersebut.

Artinya, state trie global tidak secara langsung memuat setiap slot penyimpanan dari setiap kontrak.

Sebaliknya, state trie memuat objek akun, dan setiap akun kontrak dapat menunjuk ke storage trie-nya sendiri.

Misalnya, kontrak token dapat menyimpan saldo pengguna dalam storage trie kontraknya sendiri.

State trie global menyimpan objek akun kontrak token, dan objek tersebut menunjuk ke root penyimpanan kontrak token.

Desain berlapis ini membantu memisahkan state tingkat akun dari penyimpanan tingkat kontrak.

State Trie vs. Transactions Trie

State trie berbeda dari transactions trie.

State trie menyimpan state akun yang dihasilkan setelah transaksi dieksekusi.

Transactions trie menyimpan transaksi yang disertakan dalam blok tertentu.

Setiap blok memiliki transactions trie sendiri.

Transactions trie tidak diperbarui secara berkelanjutan antarblok seperti state trie global.

State trie berkembang dari blok ke blok saat transaksi mengubah saldo akun dan penyimpanan kontrak.

Transaksi dapat dipahami sebagai instruksi.

State trie dapat dipahami sebagai hasil setelah instruksi diterapkan.

Perbedaan ini penting karena blockchain bukan hanya log transaksi yang terurut.

Blockchain juga merupakan state machine, tempat setiap transaksi valid memindahkan sistem dari satu state ke state berikutnya.

State Trie vs. Receipts Trie

State trie juga berbeda dari receipts trie.

Receipts trie menyimpan receipt transaksi untuk suatu blok.

Receipt mencatat hasil eksekusi seperti status, gas yang digunakan, log, dan data event.

State trie mencatat state akun akhir setelah eksekusi.

Receipt membantu aplikasi memahami apa yang terjadi selama eksekusi transaksi.

State trie membantu klien memverifikasi state blockchain yang terbentuk setelah eksekusi.

Misalnya, transaksi smart contract dapat menghasilkan event yang dicatat dalam receipt.

Transaksi yang sama juga dapat mengubah penyimpanan kontrak yang dicatat melalui state trie dan storage trie.

Kedua struktur tersebut penting, tetapi menjawab pertanyaan yang berbeda.

Receipts trie menjawab apa yang dihasilkan transaksi, sedangkan state trie menjawab seperti apa state chain saat ini.

Node Merkle Patricia Trie

Merkle Patricia Trie Ethereum yang dimodifikasi menggunakan beberapa jenis node.

Dokumentasi resmi Ethereum menjelaskan branch node, leaf node, extension node, dan empty node.

Branch node dapat menunjuk hingga 16 kemungkinan jalur child dan juga dapat menyimpan sebuah nilai.

Leaf node menyimpan jalur akhir yang dienkode beserta nilainya.

Extension node mengompresi segmen jalur bersama agar trie dapat menghindari rantai panjang node yang jarang terisi.

Desain ini berguna karena key Ethereum panjang dan jarang terisi.

Tanpa kompresi jalur, banyak pencarian akan membuang langkah pada jalur kosong atau tidak bercabang.

Dengan menggunakan extension node dan leaf node, Ethereum membuat trie lebih ringkas daripada radix trie dasar.

Dengan menggunakan hash, Ethereum menjadikan trie dapat diverifikasi secara kriptografis.

Kombinasi inilah yang membuat struktur tersebut disebut Merkle Patricia Trie yang dimodifikasi.

Encoding RLP dan Hashing

Ethereum menggunakan encoding Recursive Length Prefix, yang sering disebut RLP, untuk melakukan serialisasi banyak struktur data di execution layer.

Dalam state trie, objek akun dienkode dengan RLP sebelum ditempatkan sebagai nilai.

Node trie juga dienkode sebelum di-hash atau disimpan.

Dokumentasi Ethereum Merkle Patricia Trie menjelaskan bahwa ketika satu node mereferensikan node lain, referensi tersebut dapat berupa hash Keccak-256 dari node yang dienkode dengan RLP, bergantung pada panjang encoding.

Hal ini penting karena setiap node harus dienkode secara deterministik.

Jika dua klien mengenkode state yang sama secara berbeda, keduanya dapat menghitung root yang berbeda dan gagal mencapai kesepakatan.

Oleh karena itu, encoding deterministik merupakan detail yang sangat penting bagi konsensus.

Hashing juga membuat manipulasi terlihat karena perubahan suatu nilai mengubah hash node dan jalur hash kembali ke root.

Hasilnya adalah database key-value yang dapat diverifikasi, dengan satu root hash yang mengomitmenkan seluruh nilai yang disertakan.

Inilah fondasi kriptografis di balik state proof.

State Proof

State proof adalah proof kriptografis bahwa akun atau nilai penyimpanan tertentu ada dalam state yang dikomitmenkan oleh state root tertentu.

Proposal EIP-1186 eth_getProof menjelaskan bahwa state Ethereum berbasis Merkle tree memungkinkan verifikasi nilai akun dan penyimpanan melalui Merkle proof.

Proof biasanya berisi node yang diperlukan untuk merekonstruksi jalur dari nilai target ke state root.

Jika hash yang direkonstruksi sesuai dengan state root tepercaya, nilai tersebut dapat diverifikasi tanpa harus sepenuhnya memercayai penyedia data.

Ini berguna bagi light client, bridge, aplikasi cross-chain, wallet mobile, auditor, dan sistem smart contract yang perlu memverifikasi state eksternal.

Misalnya, proof dapat menunjukkan bahwa suatu akun memiliki saldo tertentu pada blok tertentu.

Proof juga dapat menunjukkan bahwa slot penyimpanan kontrak memiliki nilai tertentu pada blok tertentu.

State proof sangat kuat karena memungkinkan verifikasi selektif tanpa mengunduh seluruh database state.

State trie memungkinkan proof ini dibuat.

Tanpa struktur state terautentikasi, pengguna harus jauh lebih memercayai penyedia RPC dan indexer.

eth_getProof

eth_getProof adalah metode JSON-RPC Ethereum yang dirancang untuk mengembalikan nilai akun dan penyimpanan beserta Merkle proof-nya.

EIP-1186 mendefinisikan eth_getProof sebagai metode yang mengembalikan nilai akun dan nilai penyimpanan dari akun tertentu bersama data proof.

Proof dapat mencakup data accountProof yang mengikuti jalur dari state root.

Proof juga dapat mencakup data storageProof yang mengikuti jalur dari root penyimpanan kontrak.

Metode ini berguna ketika aplikasi menginginkan bukti, bukan sekadar respons RPC mentah.

Misalnya, wallet atau bridge mungkin ingin memverifikasi slot penyimpanan terhadap state root suatu blok.

Kueri saldo sederhana hanya melaporkan nilai.

Kueri proof melaporkan nilai serta data kriptografis yang diperlukan untuk memeriksanya.

Perbedaan ini penting karena penyedia RPC dapat salah, disensor, memiliki bug, atau bersifat malicious.

Merkle proof memungkinkan pengguna mengurangi tingkat kepercayaan kepada penyedia dengan memeriksa proof terhadap block header tepercaya.

State Trie dan Full Node

Full node memerlukan state saat ini untuk memverifikasi blok dan transaksi baru.

Dokumentasi resmi Ethereum archive node menjelaskan bahwa data global tentang setiap akun dan kontrak disimpan dalam database trie yang disebut state.

Full node mengikuti state terbaru jaringan agar dapat memvalidasi blok dan transaksi masuk.

Full node biasanya tidak menyimpan seluruh state historis selamanya.

Full node dapat menyimpan state terbaru dan data state terkini yang cukup untuk menangani reorganisasi chain serta operasi jaringan normal.

State historis yang lebih lama sering kali dapat dipangkas karena tidak diperlukan untuk verifikasi standar atas ujung chain terbaru.

Inilah sebabnya mengapa kueri saldo lama atau penyimpanan kontrak lama dapat sulit dilakukan pada full node biasa.

State saat ini diperlukan untuk operasi jaringan.

Seluruh state perantara historis berguna untuk analitik dan proof, tetapi jauh lebih berat untuk disimpan.

Oleh karena itu, state trie memengaruhi perangkat keras node, sinkronisasi, penyimpanan, dan desentralisasi.

State Trie dan Archive Node

Archive node menyimpan state historis, bukan hanya state saat ini dan state terkini.

Dokumentasi archive node Ethereum menjelaskan bahwa archive node menyimpan setiap state historis yang dibuat setelah setiap blok, dengan kebutuhan disk yang lebih besar sebagai pertukaran untuk kueri historis yang cepat.

Hal ini penting bagi blockchain explorer, auditor, peneliti, tim keamanan, alat pajak, penyedia analitik, dan developer dApp.

Misalnya, pengguna mungkin ingin mengetahui saldo akun pada blok dari beberapa tahun lalu.

Full node mungkin perlu mengeksekusi ulang transaksi historis untuk merekonstruksi state tersebut.

Archive node sering kali dapat mengakses state historis secara langsung dari disk.

Kecepatan ini dibayar dengan kebutuhan penyimpanan yang jauh lebih besar.

Dengan demikian, riwayat state trie bernilai tetapi mahal.

Inilah sebabnya banyak pengguna mengandalkan penyedia infrastruktur untuk kueri state historis.

Namun, ketergantungan pada penyedia dapat menambah risiko kepercayaan, ketersediaan, dan sensor.

State Trie dan Smart Contract

Smart contract sangat bergantung pada state trie dan storage trie.

Objek akun sebuah kontrak muncul dalam state trie global.

Kode kontrak dikomitmenkan melalui codeHash.

Penyimpanan persisten kontrak dikomitmenkan melalui storageRoot.

Saat smart contract dieksekusi, kontrak dapat membaca dan menulis slot penyimpanan.

Perubahan penyimpanan tersebut memperbarui storage trie kontrak.

storageRoot baru kontrak memperbarui objek akun dalam state trie global.

Objek akun yang diperbarui mengubah state root global.

Artinya, bahkan pembaruan kecil pada penyimpanan kontrak dapat mengubah state root akhir suatu blok.

Oleh karena itu, state trie merupakan bagian dari cara hasil smart contract menjadi terlihat dalam konsensus.

State Trie dan Saldo Token

Banyak saldo token disimpan dalam penyimpanan smart contract, bukan secara langsung di state trie global.

Misalnya, kontrak token fungibel dapat menyimpan mapping dari alamat pengguna ke saldo token.

Mapping tersebut berada dalam storage trie kontrak token.

State trie global menyimpan objek akun kontrak token, termasuk storageRoot untuk kontrak tersebut.

Artinya, saldo koin native dan saldo token disimpan secara berbeda.

Saldo koin native merupakan bagian dari objek akun dalam state trie global.

Saldo token biasanya merupakan nilai penyimpanan dalam storage trie kontrak token tertentu.

Perbedaan ini penting untuk proof dan audit.

Untuk membuktikan saldo koin native, account proof biasanya sudah cukup.

Untuk membuktikan saldo token, proof mungkin memerlukan account proof untuk kontrak token dan storage proof untuk slot saldo yang relevan.

State Trie dan Light Client

Light client adalah klien yang memverifikasi data blockchain tanpa menyimpan state penuh.

State trie membantu light client karena memungkinkan proof ringkas yang terkait dengan block header.

Light client dapat memercayai atau memverifikasi block header, lalu menggunakan Merkle proof untuk memeriksa nilai state tertentu.

Ini jauh lebih murah daripada menyimpan seluruh state secara lokal.

Misalnya, wallet mobile mungkin ingin memverifikasi bahwa nilai penyimpanan kontrak ada tanpa menjalankan execution node penuh.

Bridge mungkin ingin memverifikasi bahwa event penarikan atau state akun disertakan dalam state chain lain.

State trie menyediakan struktur terautentikasi yang diperlukan untuk alur kerja ini.

Namun, ukuran proof dan biaya pembuatan proof masih dapat signifikan.

Ini merupakan salah satu alasan peneliti Ethereum mengeksplorasi alternatif seperti Verkle tree.

Tujuannya adalah menjadikan verifikasi state lebih ringan dan lebih skalabel seiring waktu.

State Trie dan Stateless Client

Stateless client adalah gagasan skalabilitas blockchain jangka panjang, ketika validator atau pengguna dapat memverifikasi blok tanpa menyimpan seluruh state secara lokal.

Alih-alih setiap validator menyimpan seluruh state, blok atau transaksi akan menyertakan witness yang membuktikan state yang disentuhnya.

State trie relevan karena witness Merkle Patricia Trie saat ini dapat berukuran besar.

Witness yang besar dapat membuat verifikasi stateless tidak efisien.

Artikel Ethereum Foundation tentang struktur Verkle tree menjelaskan bahwa Verkle tree bekerja serupa dengan Merkle tree, tetapi dapat menghasilkan witness yang jauh lebih kecil melalui vector commitment.

Inilah alasan Verkle tree diteliti sebagai kemungkinan pengganti struktur komitmen state Ethereum saat ini.

State trie saat ini aman dan telah teruji, tetapi tidak dirancang untuk menghasilkan witness stateless sekecil mungkin.

Riset statelessness sebagian bertujuan mengurangi beban yang diberikan state trie pada node.

Bagi pengguna, kesimpulan praktisnya adalah desain struktur data state memengaruhi skalabilitas di masa depan.

Bagi developer, hal ini berarti pola akses state dan sistem proof dapat berkembang seiring kemajuan riset protokol.

State Trie dan Verkle Tree

Verkle tree adalah struktur komitmen state yang diusulkan dan menggunakan vector commitment, bukan hanya tautan hash.

Ethereum.org menyatakan bahwa Ethereum berencana bermigrasi ke struktur Verkle Tree di masa depan, meskipun jadwal protokol dan detail implementasi dapat berubah.

Verkle tree dirancang untuk membuat proof lebih kecil dibandingkan proof Merkle Patricia Trie.

Artikel Ethereum Foundation menjelaskan bahwa desain Verkle tree juga menggabungkan account trie dan storage trie dalam tata letak yang berbeda.

Ini akan menjadi perubahan besar karena saat ini Ethereum menggunakan state trie global ditambah storage trie per akun.

Model state berbasis Verkle dapat membuat stateless client lebih praktis.

Namun, migrasi dari state trie yang telah lama berjalan ke struktur komitmen baru bersifat kompleks.

Migrasi tersebut memengaruhi klien, proof, wallet, node, aturan eksekusi, tata letak penyimpanan, dan asumsi developer.

Karena itu, state trie merupakan fondasi saat ini sekaligus bidang utama riset protokol yang terus berlangsung.

Memahami state trie membantu pengguna memahami mengapa riset Verkle penting.

State Trie dan State Bloat

State bloat berarti state aktif blockchain menjadi lebih besar dan lebih sulit dipelihara.

State trie bertumbuh ketika lebih banyak akun, kontrak, slot penyimpanan, dan data aplikasi tetap aktif.

State yang besar meningkatkan penggunaan disk, waktu sinkronisasi, beban database, dan kebutuhan perangkat keras.

Jika node menjadi terlalu mahal untuk dijalankan, lebih sedikit pengguna dapat memverifikasi jaringan secara mandiri.

Hal ini dapat melemahkan desentralisasi.

State bloat berbeda dari pertumbuhan riwayat blockchain karena state aktif diperlukan untuk memproses transaksi baru.

Transaksi historis memang penting, tetapi state perantara lama terkadang dapat dipangkas atau dibuat ulang.

State saat ini harus tersedia untuk validasi.

Hal ini menjadikan pertumbuhan state sebagai salah satu masalah skalabilitas paling sulit bagi blockchain smart contract.

State trie adalah struktur data tempat pertumbuhan tersebut terlihat oleh klien.

State Trie dan Biaya Gas

Biaya gas sebagian dirancang untuk menetapkan harga komputasi dan akses state.

Menulis penyimpanan persisten mahal karena meningkatkan atau mengubah state yang harus dipelihara node.

Membaca state juga dapat menimbulkan biaya karena akses state memengaruhi performa eksekusi.

Saat smart contract membuat penyimpanan baru, storage trie dan state root global mungkin perlu diperbarui.

Saat smart contract menghapus penyimpanan, aturan gas dapat memberikan refund atau insentif, bergantung pada aturan protokol saat ini.

Mekanisme gas ini terkait dengan state trie karena state persisten merupakan sumber daya jaringan bersama.

Jika penulisan penyimpanan terlalu murah, aplikasi dapat membengkakkan state trie dengan data bernilai rendah.

Jika penulisan penyimpanan terlalu mahal, aplikasi yang berguna mungkin menjadi lebih sulit dibangun.

Perancang protokol harus menyeimbangkan kegunaan, keamanan, dan keberlanjutan state.

State trie berada di pusat trade-off ekonomi tersebut.

State Trie dan Penyedia RPC

Penyedia RPC menyediakan metode yang memungkinkan wallet dan aplikasi membaca state blockchain.

Metode state yang umum mencakup kueri saldo, kueri penyimpanan, kueri kode, kueri jumlah transaksi, dan pemanggilan kontrak.

Dokumentasi resmi Ethereum JSON-RPC menjelaskan metode state sebagai metode yang melaporkan data tersimpan saat ini, seperti saldo akun, data kontrak, dan estimasi gas.

Saat wallet meminta saldo akun, penyedia RPC membaca data state dari node.

Saat dApp meminta nilai kontrak, penyedia RPC dapat membaca slot penyimpanan atau mensimulasikan pemanggilan terhadap state saat ini.

Pengguna sering mengandalkan penyedia RPC tanpa memikirkan state trie di balik respons tersebut.

Namun, state trie memungkinkan nilai-nilai tersebut menjadi bagian dari state blockchain yang dapat diverifikasi.

Untuk aplikasi yang memerlukan tingkat kepercayaan tinggi, respons RPC mentah mungkin tidak cukup.

State proof dapat memberikan jaminan yang lebih kuat jika didukung dan diverifikasi dengan benar.

Hal ini penting bagi bridge, audit, alat kepatuhan, dan sistem cross-chain.

State Trie dan Blockchain Explorer

Blockchain explorer menggunakan data state untuk menampilkan saldo, kepemilikan token, penyimpanan kontrak, dampak transaksi, dan informasi akun historis.

Explorer sering mengandalkan data yang diindeks, bukan hanya kueri state trie langsung.

Pengindeksan membuat pencarian lebih cepat dan antarmuka pengguna lebih mudah dibuat.

Namun, data yang diindeks pada akhirnya berasal dari state blockchain, transaksi, log, receipt, dan hasil eksekusi.

Jika explorer menampilkan saldo akun pada blok tertentu, informasi itu terkait dengan state pada blok tersebut.

Jika explorer menampilkan saldo token, data tersebut sering diturunkan dari perubahan penyimpanan kontrak dan event.

Archive node dapat membantu explorer menjawab pertanyaan state historis dengan cepat.

Tanpa akses state historis, explorer mungkin perlu merekonstruksi state lama dari riwayat transaksi.

State trie biasanya tidak terlihat oleh pengguna explorer biasa.

Namun, state trie tetap merupakan salah satu struktur inti yang membuat data explorer dapat diverifikasi pada tingkat protokol.

State Trie dan Bridge

Bridge sering perlu memverifikasi state atau event dari lingkungan blockchain lain.

State trie dan Merkle proof dapat mendukung verifikasi ini.

Misalnya, bridge mungkin memerlukan proof bahwa pesan, nilai penyimpanan, atau state akun ada pada blok tertentu.

Jika bridge dapat memercayai block header dan memverifikasi proof, bridge dapat mengurangi ketergantungan pada penyedia data terpusat.

Inilah alasan EIP-1186 menyatakan bahwa Merkle proof penting bagi teknologi Layer 2.

State proof dapat membantu sistem memverifikasi klaim tentang saldo, slot penyimpanan, dan state kontrak.

Namun, keamanan bridge bergantung pada lebih dari sekadar struktur proof.

Keamanan juga bergantung pada verifikasi header, asumsi finality, fraud proof, validity proof, kontrol multisig, keamanan smart contract, dan desain operasional.

State trie proof yang benar sangat kuat, tetapi hanya merupakan satu bagian dari keamanan bridge.

Pengguna tidak boleh menganggap bridge aman hanya karena menyebut Merkle proof.

State Trie dan Jaringan Layer 2

Jaringan Layer 2 sering menggunakan state root, proof, dan struktur komitmen untuk merangkum eksekusi off-chain atau eksekusi pada chain terpisah.

Layer 2 dapat memublikasikan state root ke chain Layer 1.

Layer 2 dapat menggunakan fraud proof, validity proof, atau mekanisme data availability untuk membuktikan bahwa transisi state-nya valid.

Desain pastinya bergantung pada arsitektur Layer 2.

State trie Ethereum merupakan konteks penting karena menunjukkan bagaimana blockchain dapat mengomitmenkan state besar melalui root yang ringkas.

Sistem Layer 2 dapat menggunakan struktur data yang berbeda, tetapi konsepnya serupa.

State eksekusi yang besar diringkas oleh sebuah komitmen.

Pengguna dan kontrak kemudian memverifikasi klaim terhadap komitmen tersebut.

Inilah salah satu alasan state trie bukan sekadar topik klien tingkat rendah.

State trie juga menjadi bagian dari skalabilitas, desain rollup, dan verifikasi cross-chain.

State Trie dan Keamanan

State trie meningkatkan keamanan dengan membuat manipulasi state dapat dideteksi.

Jika node mengubah saldo akun tanpa mengikuti aturan transaksi yang valid, state root yang dihasilkan tidak akan cocok dengan block header yang diterima.

Jika penyedia berbohong tentang nilai penyimpanan, Merkle proof yang valid seharusnya gagal terhadap state root tepercaya.

Jika dua klien tidak sepakat tentang aturan transisi state, keduanya dapat menghitung state root yang berbeda dan menolak blok satu sama lain.

Hal ini menjadikan state trie sangat penting bagi konsensus.

Bug dalam implementasi state trie dapat serius karena dapat menyebabkan ketidaksepakatan klien atau verifikasi state yang salah.

Karena itu, execution client harus mengimplementasikan logika trie, encoding, hashing, dan pembaruan state secara cermat.

Keamanan state trie juga bergantung pada ketahanan hash kriptografis.

Jika penyerang dapat membuat dua state berbeda dengan root yang sama, mereka dapat merusak integritas proof.

State trie blockchain modern bergantung pada asumsi kriptografis yang membuat hal tersebut secara praktis tidak layak dilakukan dalam kondisi saat ini.

State Trie dan Implementasi Klien

Berbagai execution client Ethereum mengimplementasikan aturan state yang sama, tetapi dapat menggunakan database internal dan optimasi yang berbeda.

Hasil yang sangat penting bagi konsensus harus berupa state root yang sama.

Cara klien menyimpan node trie pada disk dapat berbeda.

Cara klien melakukan cache state dapat berbeda.

Cara klien memangkas state lama dapat berbeda.

Cara klien melayani kueri historis dapat berbeda.

Artinya, state trie merupakan konsep protokol sekaligus tantangan implementasi.

Pada tingkat protokol, klien harus menyepakati root dan aturan transisi.

Pada tingkat database, tim klien dapat mengoptimalkan tata letak penyimpanan, kecepatan akses, pruning, snapshot, dan perilaku sinkronisasi.

Pengguna biasanya merasakan perbedaan ini sebagai performa node, penggunaan disk, waktu sinkronisasi, dan keandalan RPC.

State Trie dan Debugging Developer

Developer sering menemui state trie secara tidak langsung melalui slot penyimpanan, account proof, dan kueri state historis.

Developer smart contract mungkin perlu mengetahui cara mapping disimpan dalam penyimpanan kontrak.

Peneliti keamanan mungkin perlu membuktikan bahwa slot penyimpanan memiliki nilai tertentu pada sebuah blok.

Developer bridge mungkin perlu memverifikasi nilai state kontrak dari lingkungan lain.

Developer wallet mungkin perlu menjelaskan mengapa kueri saldo bergantung pada block tag seperti latest atau finalized.

Developer dApp mungkin memerlukan archive node saat melakukan debugging state kontrak lama.

Memahami state trie membantu developer menafsirkan masalah ini dengan benar.

Hal ini juga membantu developer menghindari kekeliruan antara riwayat transaksi dan state saat ini.

Banyak bug muncul karena menganggap event, penyimpanan, saldo, dan state akun adalah hal yang sama.

State trie memperjelas tempat setiap bagian data disimpan.

State Trie dan Pengalaman Pengguna Umum

Sebagian besar pengguna kripto tidak pernah berinteraksi langsung dengan state trie.

Mereka berinteraksi dengan wallet, dApp, explorer, dan penyedia RPC.

Saat wallet menampilkan saldo, wallet sedang membaca state.

Saat dApp memeriksa apakah pengguna telah menyetujui token, dApp sedang membaca state penyimpanan kontrak.

Saat pemanggilan smart contract berhasil atau gagal, hasilnya bergantung pada state saat ini.

Saat explorer menampilkan nilai kontrak pada suatu blok, hal itu bergantung pada akses state atau data terindeks yang diturunkan dari state.

State trie adalah infrastruktur tersembunyi, tetapi memengaruhi aktivitas pengguna biasa setiap hari.

Jika akses state lambat, dApp dapat terasa lambat.

Jika penyedia RPC memberikan state yang salah, pengguna dapat melihat saldo yang salah atau transaksi yang gagal.

Jika state historis tidak tersedia, pengguna mungkin kesulitan mengaudit aktivitas lama.

Kesalahpahaman Umum tentang State Trie

Salah satu kesalahpahaman umum adalah bahwa state trie menyimpan setiap transaksi.

State trie menyimpan state akun saat ini, sedangkan transaksi disimpan terpisah dalam blok dan transaction trie.

Kesalahpahaman lainnya adalah bahwa penyimpanan smart contract disimpan langsung dalam state trie global.

State trie global menyimpan objek akun, sedangkan penyimpanan kontrak disimpan dalam storage trie terpisah yang direferensikan oleh nilai storageRoot.

Kesalahpahaman ketiga adalah bahwa full node selalu menyimpan setiap state historis.

Banyak full node menyimpan state saat ini dan state terkini sambil memangkas state perantara yang lebih lama.

Kesalahpahaman keempat adalah bahwa state root adalah state itu sendiri.

State root adalah komitmen kriptografis ringkas terhadap state, bukan database state lengkap.

Kesalahpahaman kelima adalah bahwa Merkle proof membuktikan setiap fakta yang mungkin tentang suatu kontrak.

Merkle proof membuktikan nilai akun atau penyimpanan tertentu terhadap root tertentu, bukan makna bisnis lengkap dari nilai tersebut.

Manfaat State Trie

Manfaat pertama state trie adalah verifiabilitas.

Pengguna dan klien dapat memverifikasi nilai state melalui proof yang terikat pada state root.

Manfaat kedua adalah determinisme.

Klien yang memproses blok valid yang sama seharusnya mencapai state root yang sama.

Manfaat ketiga adalah pencarian yang efisien.

Jalur trie memungkinkan klien menemukan data akun dan penyimpanan melalui key deterministik.

Manfaat keempat adalah bukti manipulasi.

Mengubah satu nilai akan mengubah jalur hash dan root akhir.

Manfaat kelima adalah dukungan light client.

Proof selektif dapat memverifikasi data tanpa mengunduh state penuh.

Manfaat keenam adalah struktur transisi state yang jelas.

Setiap blok mengubah state sebelumnya menjadi state baru dengan root baru.

Manfaat tersebut menjadikan state trie sebagai fondasi blockchain smart contract berbasis akun.

Keterbatasan State Trie

Keterbatasan pertama adalah pertumbuhan penyimpanan.

Seiring bertambahnya akun dan nilai penyimpanan kontrak, state menjadi lebih berat bagi node untuk disimpan dan diverifikasi.

Keterbatasan kedua adalah ukuran proof.

Proof Merkle Patricia Trie dapat lebih besar daripada yang diinginkan bagi stateless client dan verifikasi berskala tinggi.

Keterbatasan ketiga adalah kompleksitas implementasi.

Encoding trie, hashing, pruning, caching, dan penyimpanan database sulit diimplementasikan dengan benar.

Keterbatasan keempat adalah biaya state historis.

Menyimpan setiap state historis memerlukan ruang disk jauh lebih besar dibandingkan operasi full node biasa.

Keterbatasan kelima adalah kebingungan developer.

Banyak developer salah memahami perbedaan antara state, penyimpanan, transaksi, receipt, log, dan data terindeks.

Keterbatasan ini menjelaskan mengapa manajemen state tetap menjadi bidang riset dan engineering yang aktif.

State trie berfungsi, tetapi menimbulkan tantangan skalabilitas dan kegunaan yang nyata.

Praktik Terbaik untuk Developer

Pahami perbedaan antara state akun dan penyimpanan kontrak sebelum membangun sistem berbasis proof.

Gunakan dokumentasi resmi Ethereum saat mempelajari mekanisme Merkle Patricia Trie.

Gunakan eth_getProof secara cermat saat membangun sistem yang memerlukan proof akun atau penyimpanan.

Verifikasi proof terhadap block header tepercaya, bukan memercayai respons RPC secara membabi buta.

Ingat bahwa saldo token biasanya berada dalam penyimpanan kontrak, bukan langsung dalam state trie global.

Gunakan archive node atau penyedia data arsip ketika memerlukan akses cepat ke state historis lama.

Rancang smart contract untuk meminimalkan penyimpanan persisten yang tidak diperlukan.

Perhitungkan biaya gas saat menulis ke penyimpanan karena state persisten mahal.

Ikuti riset protokol seperti Verkle tree jika sistem Anda sangat bergantung pada state proof.

Jangan menganggap format proof saat ini akan tetap tidak berubah selamanya pada upgrade protokol mendatang.

Praktik Terbaik untuk Pengguna

Gunakan wallet dan explorer tepercaya, tetapi ingat bahwa tampilannya berasal dari kueri state dan data terindeks.

Periksa nomor blok saat membandingkan saldo atau nilai kontrak di berbagai alat.

Pahami bahwa saldo saat ini dan saldo historis mungkin memerlukan akses data yang berbeda.

Gunakan verifikasi berbasis proof saat diperlukan tingkat kepastian tinggi dan alat mendukungnya.

Jangan menganggap respons RPC sederhana sama dengan proof kriptografis.

Berhati-hatilah saat menggunakan bridge atau aplikasi yang mengklaim memverifikasi state dari chain lain.

Tinjau apakah aplikasi menggunakan state saat ini, state historis, log, atau pengindeksan off-chain.

Pahami bahwa perubahan penyimpanan smart contract dapat memengaruhi perilaku aplikasi meskipun transfer token tidak terlihat jelas.

Ingat bahwa transparansi blockchain bergantung pada struktur data seperti state trie.

State trie tidak terlihat oleh sebagian besar pengguna, tetapi membantu menjadikan data public chain dapat diverifikasi.

FAQ

Apa arti state trie?

State trie adalah pohon key-value kriptografis yang menyimpan state blockchain saat ini dan menghasilkan root hash yang mengomitmenkan state tersebut.

Apa itu state trie Ethereum?

State trie Ethereum adalah Merkle Patricia Trie global yang dimodifikasi dan memetakan alamat akun yang di-hash ke objek akun yang dienkode dengan RLP.

Apa yang disimpan dalam objek akun Ethereum?

Objek akun Ethereum berisi nonce, balance, storageRoot, dan codeHash.

Apa itu state root?

State root adalah root hash dari state trie setelah transaksi suatu blok dieksekusi.

Apakah state trie sama dengan storage trie?

Tidak, state trie menyimpan objek akun, sedangkan storage trie menyimpan penyimpanan kontrak untuk akun kontrak individual.

Apakah state trie sama dengan riwayat transaksi?

Tidak, state trie menyimpan state akun saat ini, sedangkan riwayat transaksi mencatat transaksi terurut yang disertakan dalam blok.

Apa itu Merkle proof?

Merkle proof adalah kumpulan node trie yang dapat membuktikan bahwa nilai tertentu disertakan dalam state yang dikomitmenkan oleh root hash.

Apa itu eth_getProof?

eth_getProof adalah metode JSON-RPC Ethereum yang mengembalikan nilai akun dan penyimpanan dengan data Merkle proof.

Mengapa archive node penting untuk state trie?

Archive node penting karena menyimpan state historis dan dapat menjawab kueri state lama lebih cepat daripada full node biasa.

Apakah Ethereum akan selalu menggunakan state trie saat ini?

Ethereum saat ini menggunakan Merkle Patricia Trie pada execution layer-nya, tetapi riset Ethereum telah mengeksplorasi Verkle tree sebagai struktur komitmen state di masa depan.

Kesimpulan

State trie adalah salah satu struktur data inti di balik blockchain smart contract berbasis akun.

State trie menyimpan state akun saat ini dan memungkinkan klien merangkum state tersebut melalui satu root kriptografis.

Dalam Ethereum, state trie global memetakan alamat akun yang di-hash ke objek akun yang berisi nonce, balance, storageRoot, dan codeHash.

Setiap kontrak kemudian dapat memiliki storage trie sendiri, yang root-nya disimpan dalam objek akun kontrak.

State root dalam setiap block header mengomitmenkan seluruh state hasil setelah semua transaksi dalam blok tersebut diproses.

Hal ini menjadikan state trie penting bagi konsensus, verifikasi, light client, proof, sinkronisasi node, eksekusi smart contract, dan integritas data blockchain.

State trie juga menimbulkan tantangan karena pertumbuhan state aktif meningkatkan penyimpanan node, ukuran proof, kompleksitas sinkronisasi, dan biaya data historis.

Tantangan ini menjelaskan mengapa archive node, state pruning, biaya gas, desain penyimpanan, eth_getProof, dan riset Verkle tree semuanya terkait dengan topik yang sama.

Bagi pengguna, state trie sebagian besar tersembunyi di balik wallet, explorer, dan dApp.

Bagi developer dan tim infrastruktur, state trie adalah konsep penting untuk memahami saldo, penyimpanan kontrak, proof, kueri historis, dan batas skalabilitas.

Dalam konteks glosarium kripto, State Trie berarti database state blockchain terautentikasi yang mencatat state akun saat ini dan menghasilkan state root yang digunakan untuk memverifikasi state tersebut.

Poin utamanya adalah bahwa state trie mengubah state blockchain yang sangat besar dan terus berubah menjadi struktur yang dapat diverifikasi oleh node, aplikasi, dan pengguna melalui root serta proof kriptografis.