> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Mempool
> Bagaimana transaksi diterima, ditahan, diurutkan, dan disebarkan sebelum konsensus mengomitnya ke dalam blok.
Mempool berdiri di antara transaksi bertanda tangan dan blok yang dikomit. Mempool-lah yang memutuskan apa yang layak ditahan, dalam urutan apa transaksi seorang pengirim menjadi memenuhi syarat, peer mana yang mendengar tentang transaksi tertentu, dan apa yang dibuang ketika permintaan melebihi kapasitas.
Untuk jaringan trading, ini menopang beban dan bukan sekadar pelengkap. Lalu lintas order dan pembatalan datang dalam lonjakan, terpusat pada segelintir pengirim, dan sensitif terhadap latensi secara asimetris: pembatalan yang tiba terlambat lebih buruk daripada order yang tiba terlambat. Struktur di bawah ini ada karena antrean FIFO tunggal tidak menangani satu pun dari hal itu dengan baik.
Jalur masuk
Transaksi tertanda tangan
Validasitanda tangan · format · state akun · mampukah pengirim membayar
Dibuang dengan alasanbukan diam-diam — pengirim diberi alasan
Penyimpan transaksi
Siaran ke peer
Pembentukan batch, lalu konsensus
Validasi murah dan lokal, sehingga sumber daya mahal di hilir hanya dipakai untuk transaksi yang benar-benar bisa dieksekusi.
ditolak
diterima
Transaksi divalidasi sebelum disimpan sama sekali. Validasi bersifat murah dan lokal — tanda tangan, format, state akun, dan apakah pengirim mampu membayar apa yang dimintanya — dan validasi itu ada agar sumber daya mahal di hilir hanya dipakai untuk transaksi yang benar-benar bisa dieksekusi. Penolakan di sini mengembalikan alasan kepada pengirim alih-alih diam-diam menghilang.
Bagaimana transaksi ditahan
Transaksi yang diterima tidak disimpan sebagai satu antrean datar. Penyimpan transaksi memelihara beberapa tampilan atas himpunan yang sama, masing-masing menjawab pertanyaan yang berbeda.
Satu himpunan transaksi diterimalima tampilan, bukan lima antrean
Urutan per akunUntuk pengirim ini, mana transaksi berikutnya?
Indeks prioritasDi antara semua pengirim, apa yang lebih dulu ke konsensus?
Indeks kedaluwarsaApa yang sudah lewat tenggatnya?
Indeks lini masaApa yang belum didengar peer ini?
Tempat parkirBentuknya benar tetapi belum memenuhi syarat?
Tempat parkir adalah tempat bug integrasi menjadi terlihat: transaksi yang valid tetapi belum jadi yang berikutnya bagi pengirimnya diparkir, bukan ditolak — dan memenuhi syarat begitu celah di depannya tertutup.
| Tampilan | Pertanyaan yang dijawabnya |
| ---------------------- | ---------------------------------------------------------------------------- |
| **Urutan per akun** | Untuk pengirim ini, transaksi mana yang berikutnya? |
| **Indeks prioritas** | Di antara semua pengirim, apa yang harus ditawarkan lebih dulu ke konsensus? |
| **Indeks kedaluwarsa** | Apa yang sudah lewat tenggatnya dan harus dihapus? |
| **Indeks lini masa** | Apa yang belum didengar peer ini? |
| **Tempat parkir** | Apa yang bentuknya benar tetapi belum memenuhi syarat? |
**Tempat parkir** paling layak diperhatikan karena di situlah satu kelas bug integrasi menjadi terlihat. Transaksi bisa sepenuhnya valid tetapi tetap bukan yang berikutnya dalam antrean pengirimnya — paling sering karena transaksi terdahulu dari akun yang sama belum tiba atau belum dikomit. Transaksi seperti itu diparkir, bukan ditolak: transaksi itu tetap tersedia, dan menjadi memenuhi syarat begitu celah di depannya tertutup. Karena itu klien yang mengirim di luar urutan hanya mengalami penundaan, bukan kegagalan; tetapi klien yang tidak pernah menutup celahnya akan meninggalkan pekerjaan terparkir sampai kedaluwarsa.
**Indeks lini masa**-lah yang membuat penyebaran ke peer bersifat inkremental. Setiap peer dilacak sudah dilayani sejauh mana di sepanjang lini masa, sehingga siaran hanya mengirimkan apa yang kurang bagi peer itu, bukan mengirim ulang seluruh isi mempool. Lini masa dibagi ke dalam beberapa `bucket`, bukan satu barisan tunggal, sehingga satu pengirim berat tidak bisa memonopoli setiap slot siaran.
Penyebaran dan keadilan
Node tidak mempelajari transaksi sendiri-sendiri. Node yang menerima transaksi menyiarkannya ke peer, dan peer tidak diperlakukan sama — peer di hulu diprioritaskan agar transaksi bergerak menuju validator yang bisa menindaklanjutinya, bukan menyebar rata ke seluruh jaringan.
Keadilan dilacak dari riwayat terkini, bukan ditegakkan per pesan. Mempool menyimpan catatan bergulir tentang pengirim mana dan jenis lalu lintas mana yang belakangan memakai kapasitas, dan memakainya untuk membentuk apa yang dilayani berikutnya. Inilah mekanisme yang menjaga agar badai order-dan-pembatalan dari satu akun tidak menggusur trafik jaringan lainnya, tanpa perlu batas laju keras per akun yang justru akan menghukum market making yang sah.
Serah terima ke konsensus
Konsensus tidak mengambil transaksi dari mempool satu per satu. Transaksi dikumpulkan menjadi **batch**, batch disebarkan ke validator di latar belakang, dan setiap batch diakui sampai pengirim asalnya bisa membuktikan bahwa cukup banyak bagian jaringan memegangnya. Baru setelah itu usulan blok boleh merujuknya.
Konsekuensinya, usulan blok membawa digest batch alih-alih badan transaksi, sehingga ukuran pesan konsensus tetap datar saat throughput naik — dan blok yang dikomit selalu bisa di-replay, karena data di baliknya sudah dibuktikan tersedia sebelum dirujuk. Lihat [IntentionBFT](/id/protocol/architecture/intention-bft) untuk cara bukti itu dibentuk dan dipakai.
Ini juga alasan admisi mempool tidak sama dengan penyertaan. Transaksi yang diterima, disimpan, dan disiarkan sudah masuk antrean, tetapi belum diurutkan. Nasib sebuah transaksi belum pasti sampai konsensus mengomit blok yang memuatnya.
Apa artinya ini bagi klien
* **Penolakan saat pengiriman itu informatif.** Penolakan terjadi sebelum transaksi disimpan, dan alasannya menjelaskan sesuatu yang bisa diperbaiki klien.
* **Diam bukan berarti penolakan.** Transaksi bisa saja terparkir di belakang celah yang dibuat klien itu sendiri. Lacak apa yang sudah dikirim dan apa yang sudah dikomit; jangan menganggap bahwa tidak adanya konfirmasi berarti transaksi dibuang.
* **Urutan di dalam satu akun penting; urutan antarakun tidak.** Dua transaksi dari satu pengirim punya urutan terdefinisi. Dua transaksi dari pengirim berbeda diurutkan oleh konsensus, bukan oleh siapa yang mengirim lebih dulu.
* **Pembatalan tidak diistimewakan di mempool.** Prioritas pembatalan adalah properti [eksekusi kernel](/id/protocol/architecture/kernel), tempat pembatalan berjalan sebelum penempatan agresif di blok yang sama — bukan properti antrean.