Lompat ke konten
Financial Context Wiki

Mempool dan transaction pool

Panduan berbasis sudut pandang lokal node tentang penerimaan transaksi Ethereum, nonce pending dan queued, propagasi, kelayakan biaya, replacement, private order flow, inclusion, eviction, dan reorganisasi.

Diperbarui

Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

Jawaban langsung

Mempool, atau transaction pool, adalah kumpulan sementara transaksi bertanda tangan yang disimpan node di memori dan terkadang dipersistenkan, telah diterima menurut aturan validasi dan kebijakan node saat itu, tetapi belum berada pada chain kanonisnya. Mempool bukan objek konsensus, bukan antrean global, dan bukan janji inclusion. Dua node jujur dapat menyimpan transaksi berbeda karena menerima gossip berbeda, memakai client atau konfigurasi berbeda, melakukan restart, mengeluarkan entri, atau memakai jalur pengiriman publik dan privat yang berlainan.

Pada execution client Ethereum, transaksi executable dengan nonce akun berikutnya umumnya disebut pending; nonce yang lebih tinggi dan tertahan oleh gap umumnya disebut queued. Label tersebut merupakan antarmuka client, bukan state final protokol. Transaksi dapat ditolak sebelum admission, dipropagasi, diganti oleh transaksi bertanda tangan lain dengan sender dan nonce sama, dikeluarkan, dropped, berhasil included, included tetapi eksekusinya reverted, atau dipertimbangkan kembali setelah reorganisasi.

1
Membuat

Dompet membangun transaksi dengan tujuan, nilai, parameter biaya, dan data perlindungan pemutaran ulang seperti input yang dihabiskan atau nonce.

Cara kerja

  1. Tetapkan lingkungan: chain ID, execution client dan versinya, head dan base fee saat ini, jenis transaksi, sender, nonce, value, calldata, gas limit, fee cap, serta jalur pengiriman. Bedakan public gossip, relay atau builder privat, dan jalur ERC-4337 UserOperation; ketiganya tidak berbagi satu pool universal.
  2. Decode byte bertanda tangan dan jalankan pemeriksaan sebelum admission. Verifikasi tanda tangan dan sender, chain ID, jenis dan encoding, intrinsic gas, hubungan nonce, saldo untuk value ditambah eksposur biaya maksimum, field biaya, dan blob sidecar yang diwajibkan. Penolakan di sini bukan EVM REVERT dan biasanya tidak menghasilkan receipt atau biaya onchain.
  3. Petakan kebijakan pool lokal. Catat apakah client mengklasifikasikan transaksi sebagai pending atau queued, kapasitas per akun dan global, filter biaya minimum, lifetime, pengecualian akun lokal, bump replacement, serta perilaku persistensi. Flag dan default Geth mendokumentasikan Geth, bukan konsensus Ethereum atau setiap penyedia.
  4. Amati propagasi tanpa mengarang pandangan global. Bandingkan hash transaksi mentah dan byte bertanda tangan di sejumlah node independen, tetapi anggap ketiadaan bersifat ambigu: node mungkin belum menerima, menolak menurut kebijakan lokal, mengeluarkan, atau tidak mengekspos pool-nya. Jalur privat dapat melewati public gossip sambil tetap membagikan transaksi kepada operator dan builder-nya.
  5. Modelkan kelayakan dan pengurutan di candidate block. Untuk transaksi tipe 2, harga gas eksekusi adalah min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas); bila base fee melampaui maximum fee, transaksi tidak layak di bawah cap tersebut. Dependensi nonce, batas gas dan blob, validitas state, bundle builder, dan MEV dapat lebih penting daripada waktu pertama terlihat.
  6. Kelola lifecycle dengan sengaja. Tunggu, atau kirim replacement same-nonce yang terdokumentasi hanya setelah memastikan chain aktif, sender, dan kebijakan replacement. Transfer ke diri sendiri dengan nonce sama hanyalah kandidat replacement lain, bukan primitive pembatalan. Jangan mengulang transfer value hanya karena satu explorer berhenti menampilkan transaksi semula.
  7. Rekonsiliasi dengan state konsensus. Simpan setiap hash bertanda tangan dan silsilah replacement, lalu periksa receipt kanonis, block hash, status, gas terpakai, log, nonce terpakai, dan state akun atau kontrak pada tingkat confirmation atau finality yang disyaratkan. Jika reorganisasi menghapus blok, transaksi yang masih valid dapat kembali ke beberapa pool lokal, tetapi perilaku itu bergantung pada client dan state.

Contoh terhitung

  • Kelayakan fee cap. Transfer tipe 2 memiliki gasUsed = 21,000, baseFeePerGas = 32 gwei, maxPriorityFeePerGas = 3 gwei, dan maxFeePerGas = 34 gwei. Harga efektifnya min(34, 32 + 3) = 34 gwei, sehingga tip aktual 2 gwei. Biayanya 21,000 * 34 = 714,000 gwei = 0.000714 ETH, yang terbagi menjadi burn base fee 0.000672 ETH dan tip 0.000042 ETH. Jika base fee candidate block naik menjadi 35 gwei, cap 34 gwei tidak mencukupi untuk blok tersebut.
  • Nonce gap. Nonce akun kanonis adalah 10. Pool lokal menerima transaksi ber-nonce 10 dan 12, tetapi tidak menerima 11; pool dapat mengklasifikasikan 10 sebagai pending dan 12 sebagai queued. Setelah nonce 10 included, nonce kanonis menjadi 11, dan 12 tetap terhalang sampai transaksi valid dengan nonce 11 included. Terlihatnya nonce 12 di pool tidak membuatnya executable secara independen.
  • Replacement khusus kebijakan. Dalam konfigurasi pengajaran Geth dengan txpool.pricebump = 10, transaksi lama memiliki maxFeePerGas = 40 gwei dan maxPriorityFeePerGas = 2 gwei. Threshold replacement yang dihitung dengan bump 10% adalah 44 gwei dan 2.2 gwei. Proposal dengan 43 gwei dan 3 gwei masih dapat ditolak karena satu cap tidak mencapai bump; 44 gwei dan 2.2 gwei mencapai kedua threshold pengajaran. Pembulatan integer, jenis transaksi, dan logika admission persisnya bergantung versi, dan node lain dapat mempertahankan kandidat berbeda.
  • Tidak ada pool global. Node A melaporkan 120,000 hash transaksi berbeda, node B 100,000, dan irisan keduanya 80,000. Gabungannya 120,000 + 100,000 - 80,000 = 140,000; overlap Jaccard 80,000 / 140,000 = 57.1428571429%. Ada 40,000 hash yang hanya terlihat oleh A dan 20,000 hanya oleh B. Tidak satu pun jumlah itu membuktikan apa yang dilihat builder, relay privat, atau seluruh jaringan.

Risiko

  • Menandatangani atau menyiarkan pada chain ID atau jaringan yang salah.
  • Memercayai endpoint RPC yang berbahaya, stale, atau salah konfigurasi.
  • Tanda tangan, jenis transaksi, encoding, atau blob sidecar yang tidak valid.
  • Saldo tidak cukup untuk value ditambah eksposur biaya maksimum.
  • Aturan intrinsic gas atau calldata menyebabkan penolakan sebelum admission.
  • Nonce sudah terpakai atau terlalu rendah.
  • Nonce gap membuat transaksi berikutnya tetap queued.
  • Replacement same-nonce ditolak sebagai underpriced oleh kebijakan lokal.
  • Maximum fee di bawah base fee candidate block.
  • Prioritas efektif rendah atau keterbatasan resource menunda inclusion.
  • Ketidakcocokan kebijakan client, penyedia, versi, atau konfigurasi.
  • Kapasitas pool, expiry, restart, atau eviction menghapus transaksi.
  • Propagasi peer buruk, eclipse, atau perilaku relay selektif.
  • Kebocoran, sensor, outage relay privat, atau builder tidak berpartisipasi.
  • Frontrunning, sandwiching, atau MEV lain dari public order flow.
  • Pengurutan builder, bundle, atau transaksi privat mengubah execution state.
  • Simulasi menjadi stale sebelum inclusion.
  • Pengiriman duplikat tanpa pemeriksaan atau hilangnya silsilah replacement.
  • REVERT yang included, out-of-gas, atau kegagalan subcall yang tertangkap walaupun pool menerima.
  • Reorganisasi, kebingungan finality, atau memperlakukan alternate mempool ERC-4337 sebagai txpool biasa.

Kesalahpahaman umum

  • Mempool adalah satu antrean FIFO global yang selalu tersinkronisasi.
  • Hash transaksi membuktikan bahwa jaringan menerima atau mempropagasi transaksi.
  • Pending berarti included, sukses, tidak dapat dibalik, atau dana sudah diterima.
  • Biaya yang cukup tinggi menjamin inclusion dan eksekusi berhasil.
  • Jalur privat otomatis rahasia, tahan sensor, dan dijamin included.

Topik terkait

Sumber

Navigasi

Cari di wiki...