Fase 0 · Fondasi Kriptografi & Struktur Data

Merkle tree — verifikasi ribuan transaksi

Kalau tiap node harus mengunduh dan membandingkan ribuan transaksi satu per satu untuk memverifikasi sebuah block, blockchain tidak akan pernah skala. Merkle tree adalah trik yang membuat verifikasi itu logaritmik, bukan linear.

Sumber asli ethereum.org Resmi Rangkuman ~6 menit baca

Intisari

Merkle tree meringkas banyak data jadi satu hash akar (root) — perubahan sekecil apa pun di data mana pun mengubah root-nya.
Membuktikan satu transaksi ada di dalam block hanya butuh O(log n) hash — disebut Merkle proof — bukan seluruh data block.
Ethereum sebenarnya memakai varian yang lebih canggih: Merkle Patricia Trie, yang juga mendukung pembuktian data tidak ada, dan efisien untuk data yang sering berubah (state akun).
Block header Ethereum menyimpan tiga root terpisah: transaksi, receipt (hasil eksekusi), dan state (saldo semua akun) — masing-masing bisa diverifikasi independen.
Ini yang memungkinkan light client (mis. wallet mobile) memverifikasi transaksi tanpa mengunduh seluruh blockchain.

Masalah yang diselesaikan

Bayangkan satu block berisi 3.000 transaksi. Kamu ingin membuktikan ke orang lain bahwa transaksi tertentu benar-benar ada di block itu — tanpa mengirim 3.000 transaksi sekaligus. Merkle tree menjawabnya: susun semua transaksi jadi pohon biner berdasarkan hash, dan simpan hanya satu hash — akarnya — di header block.

Cara kerja: hash berjenjang

Daun (leaf)      H(tx1)      H(tx2)      H(tx3)      H(tx4)
                    \          /            \          /
Cabang          H(H(tx1)+H(tx2))        H(H(tx3)+H(tx4))
                            \                /
Root                    H( gabungan keduanya )   ← disimpan di block header

Tiap pasang hash digabung lalu di-hash lagi, naik satu tingkat, sampai tersisa satu hash: Merkle root. Root ini yang dicatat di block header — bukan daftar transaksinya. Ubah satu byte di tx3 mana pun di kedalaman pohon, root di paling atas ikut berubah karena avalanche effect hash yang sudah kamu pelajari di materi sebelumnya.

Merkle proof: membuktikan tanpa mengungkap semuanya

Untuk membuktikan tx3 ada di block ini, kamu hanya perlu mengirim hash "tetangga" di setiap tingkat — bukan seluruh transaksi lain:

Untuk membuktikan tx3:
  kirim: H(tx4)                    → gabung dengan H(tx3) yang kamu hitung sendiri
  kirim: H(H(tx1)+H(tx2))          → gabung dengan hasil di atas
  bandingkan hasil akhir dengan root yang tercatat di block header

Untuk 3.000 transaksi (~2¹²), proof-nya hanya butuh ~12 hash — bukan 3.000. Inilah yang membuat verifikasi Merkle proof berskala logaritmik, dan yang memungkinkan wallet ringan memverifikasi "transaksiku benar-benar tercatat" tanpa menjalankan node penuh.

Jumlah transaksi	Hash dalam proof (log₂ n)
16	4
1.000	~10
1.000.000	~20

Ethereum melangkah lebih jauh: Merkle Patricia Trie

Merkle tree biasa cocok untuk data yang tidak berubah setelah block selesai (daftar transaksi). Tapi Ethereum juga perlu merepresentasikan state — saldo dan storage setiap akun — yang berubah tiap block dan butuh dicari lewat key (address). Untuk itu Ethereum memakai Merkle Patricia Trie (MPT): gabungan trie (pencarian berdasarkan key, seperti radix tree) dengan sifat Merkle (setiap node punya hash, akar merepresentasikan seluruh isi).

Root di block header	Merepresentasikan
`transactionsRoot`	Semua transaksi di block ini
`receiptsRoot`	Hasil eksekusi tiap transaksi (sukses/gagal, event log, gas terpakai)
`stateRoot`	Saldo & storage seluruh akun di jaringan, setelah block ini diterapkan

Kenapa tiga root terpisah? Supaya ketiganya bisa diverifikasi independen. Kamu bisa membuktikan "transaksi X ada di block ini" tanpa perlu tahu apa pun soal state akun lain, dan sebaliknya bisa membuktikan saldo sebuah akun tanpa mengunduh satu pun transaksi historis. MPT bahkan mendukung pembuktian ketidakhadiran — "key ini tidak ada di trie" — yang tidak bisa dilakukan Merkle tree biasa.

Latihan: buka block apa pun di Etherscan, catat nilai stateRoot dan transactionsRoot-nya. Lalu bandingkan dua block berurutan: transactionsRoot pasti berbeda total (isi block beda), tapi renungkan kenapa stateRoot juga selalu berbeda — bahkan untuk akun yang tidak terlibat transaksi apa pun di block itu.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.