Apa yang Sebenarnya Terjadi Ketika Kamu Mengirim Transaksi Ethereum

--> Masalah

Kamu klik “Kirim” di walletmu. UI mengonfirmasi transaksi.

Tapi kemudian… tidak ada yang terjadi.

Kadang-kadang itu terkonfirmasi dalam beberapa detik.
Kadang-kadang itu tergantung selama beberapa menit—atau gagal sepenuhnya.

Kenapa?

Sebagian besar penjelasan berhenti di “itu masuk ke blockchain.”

Itu tidak berguna jika kamu sedang membangun sistem di .

Mari kita uraikan apa yang sebenarnya terjadi di balik layar.

Model Mental (Orientasi Cepat)


Sebuah transaksi tidak dieksekusi secara instan.

Ini bergerak melalui tiga fase yang berbeda:

  • Propagasi (mempool)

  • Inklusi (usulan blok)

  • Eksekusi (transisi status)

Setiap fase menambah latensi, risiko, dan mode kegagalan.

Langkah 1: Pembuatan Transaksi

Saat Anda menekan “send”:


  • Dompet Anda menyusun sebuah transaksi:

    • untuk

    • nilai

    • gasLimit

    • maxFeePerGas

    • data (jika interaksi kontrak)

    Ia menandatangani transaksi menggunakan kunci privat Anda

Pada titik ini:
👉 Transaksi valid, tetapi belum diketahui oleh jaringan

Langkah 2: Siarkan ke Jaringan

Dompet Anda mengirim transaksi tersebut ke sebuah node.

  • Node itu:

  • Memverifikasi tanda tangan

  • Memeriksa nonce

  • Memastikan validitas dasar

Jika valid → masuk ke mempool

Langkah 3: Mempool (Tempat yang Menarik)

Mempool itu:

  • Area penahanan sementara

  • Tidak konsisten secara global

  • Berbeda di tiap node

Ini artinya:
👉 Transaksi Anda mungkin ada di beberapa node—tapi tidak di yang lain

Perilaku kunci:

  • Node memprioritaskan transaksi berdasarkan biaya

  • maxFeePerGas lebih tinggi = prioritas lebih tinggi

📊 Diagram 1: Alur Propagasi Transaksi


Diagram harus menunjukkan:

  • Dompet pengguna → Node A → Node B → Node C

  • Setiap node memiliki mempool sendiri

  • Panah yang menunjukkan propagasi gossip

  • Sorotan: “Tidak semua mempool itu identik”

Langkah 4: Usulan Blok

Validator memilih transaksi dari mempool mereka.

Mereka memilih:

  • Transaksi dengan biaya tertinggi lebih dulu

  • Transaksi yang muat dalam batas gas

Penting:
👉 Transaksi Anda bersaing dengan yang lain


Langkah 5: Eksekusi (Level EVM)


Setelah dimasukkan ke sebuah blok

  • Transaksi dieksekusi di dalam EVM

  • Perubahan status terjadi:

    • Pembaruan saldo

    • Perubahan penyimpanan kontrak pintar

Jika eksekusi gagal:

  • Gas tetap dikonsumsi

  • Perubahan status kembali (revert)

📊 Diagram 2: Alur Eksekusi


Diagram harus menunjukkan:

  • Blok → EVM → Transisi Status

  • Masukan:

    • Transaksi

    • Status saat ini


  • Keluaran:

    • Status baru

  • Sertakan “konsumsi gas” di setiap langkah

Kasus Tepi & Mode Kegagalan

Di sinilah sebagian besar artikel gagal. Mari kita gali lebih dalam.

❌ 1. Transaksi Terjebak di Mempool

  • Biaya terlalu rendah

  • Tidak pernah dipilih oleh validator

❌ 2. Transaksi Terbuang

  • Node menghapusnya karena:

    • Biaya rendah

    • Mempool meluap

❌ 3. Transaksi yang Digantikan (Replaced)

  • Nonce yang sama + biaya lebih tinggi → menggantikan yang asli

❌ 4. Eksekusi Kehabisan Gas (Out-of-Gas)

  • Eksekusi berhenti di tengah jalan

  • Status kembali (revert)

  • Gas yang terbuang

❌ 5. Reorganisasi Rantai (Reorg)

  • Blok diganti

  • Transaksi mungkin menghilang sementara


Implikasi Dunia Nyata

Untuk Pengembang:

  • Anda tidak bisa menganggap finalitas instan

  • Harus menangani status yang masih pending

Untuk UX:

  • Pengguna melihat “pending” → kebingungan

  • Estimasi biaya menjadi hal yang krusial

Untuk Desain Sistem

  • Logika percobaan ulang (retry) diperlukan

  • Pemantauan transaksi itu wajib

Inti yang perlu diingat

  • Sebuah transaksi adalah proses bertahap, bukan peristiwa tunggal

  • Mempool bersifat non-deterministik dan terfragmentasi

  • Biaya secara langsung memengaruhi peluang eksekusi

  • Kegagalan bisa terjadi di banyak lapisan

  • Sistem harus dirancang untuk ketidakpastian dan penundaan


Jika Anda membangun di Ethereum, memahami pipeline ini tidaklah opsional—ini fondasi$ETH