> ## 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.
# Model state
> Apa yang termasuk state on-chain, bagaimana state itu diberi key dan versi, serta representasi state mana dari ketiganya yang otoritatif.
Ada tiga hal berbeda yang sama-sama disebut “state” di dalam mesin trading, dan mencampuradukkan ketiganya adalah cara sistem sampai pada jawaban yang berbeda-beda tergantung siapa yang ditanya. Halaman ini memisahkan ketiganya dan menyebut mana yang otoritatif.
Tiga representasi
State mesinpasar · akun · posisi · order book · lembaga kliringbertahan lintas blok · rekonstruksi
Working set blokharga mark · akun tersentuh · eksekusi · outputhidup satu blok · sebuah jurnal
State on-chainkey-value berversi, terautentikasi Merkleotoritasnya
Kegagalan yang dicegahMesin yang salinan in-memory-nya menyimpang dari apa yang terkomit terus menyajikan jawaban, dan setiap jawaban itu salah dengan cara yang baru terlihat saat penyelesaian.
state mesin harus bisa diturunkan dari catatan terkomit, tidak pernah sebaliknya
**State mesin** adalah apa yang dipegang [kernel](/id/protocol/architecture/kernel) di antara blok: metadata pasar, akun, posisi, order book, state instrumen, state lembaga kliring. Ini representasi kerja — ditata mengikuti pola akses yang benar-benar dimiliki matching dan kliring, bukan mengikuti kebutuhan penyimpanan.
**Working set blok** hanya ada selama satu blok dieksekusi: harga mark yang dipatok di awal, akun dan order mana yang tersentuh, eksekusi yang dihasilkan, output yang sedang dirakit. Isinya jurnal tentang apa yang terjadi selama blok itu berjalan.
**State on-chain** adalah hasil yang sudah terkomit: entri key-value berversi, diautentikasi oleh struktur Merkle, tahan lama dan bisa di-replay. Inilah yang di-sync node, yang menjadi acuan bukti, dan yang dibaca [indexer](/id/protocol/architecture/indexer).
**State on-chain adalah otoritasnya.** Working set blok adalah jurnal yang dipakai untuk membangun output deterministik — bukan sumber kebenaran. State mesin adalah rekonstruksi state on-chain yang dioptimalkan untuk eksekusi; representasi itu harus bisa diturunkan dari catatan yang sudah terkomit, tidak pernah sebaliknya.
Membalik urutan ini menghasilkan kegagalan yang khas dan mudah dikenali: mesin yang salinan in-memory-nya sudah menyimpang dari apa yang terkomit akan terus menyajikan jawaban, dan setiap jawaban itu salah dengan cara yang baru terlihat saat penyelesaian.
Key
State on-chain dialamatkan lewat key. State trading dikelompokkan ke dalam namespace bernama yang diberi versi secara eksplisit — misalnya konfigurasi biaya, indeks perpetual, tabel tier leverage, dan daftar peran administratif.
Sufiks versi bukan hiasan. Ketika bentuk konfigurasi berubah, konfigurasi itu pindah ke versi baru dari key-nya, dan key sebelumnya dipertahankan agar state yang ditulis dengan skema lama tetap bisa dibaca selama migrasi. Pembaca yang meng-hard-code satu versi dan tidak pernah memeriksa ulang akan diam-diam membaca konfigurasi usang setelah migrasi; pembaca yang me-resolve key yang sedang berlaku tidak akan begitu.
Inilah sebabnya konfigurasi harus dibaca dari chain, bukan dikunci di kode klien. [Layanan tier biaya](/id/protocol/architecture/programs) membaca konfigurasi biaya yang sedang berlaku pada setiap siklus persis karena alasan ini — tabel tier yang ditanam di dalam klien adalah tabel yang cepat atau lambat akan berbeda dari tabel yang sedang diterapkan jaringan.
Versi
Setiap blok yang terkomit menaikkan satu versi. Nilai state disimpan terhadap versi saat nilai itu ditulis, yang berarti store-nya bukan sekadar “state saat ini” melainkan “state pada versi mana pun”.
Properti itulah yang sekaligus memungkinkan beberapa hal:
* **Bukti** dapat dihasilkan terhadap versi tertentu, bukan hanya terhadap keadaan sekarang.
* **Replay** dapat dimulai dari versi mana pun, bukan hanya dari genesis.
* **Pembacaan** bisa bersifat historis — indexer yang merekonstruksi riwayat posisi sedang meminta versi lama, bukan memindai log.
* **Pruning** menjadi keputusan kebijakan tentang seberapa jauh ke belakang data disimpan, bukan batasan struktural.
Apa yang akhirnya terkomit
Eksekusi kernel menghasilkan dua hal per blok. Setiap transaksi membawa penulisan dan event-nya sendiri, terikat padanya. Efek yang bukan milik satu transaksi pengguna mana pun — aliran funding, pergerakan dana asuransi, penghitung di tingkat blok — masuk ke kanal sistem tersendiri.
Di antara keduanya, tidak ada yang hilang. Tidak ada efek eksekusi di dalam kernel yang tidak muncul di output transaksi maupun di kanal sistem. Kelengkapan itulah yang membuat catatan terkomit bisa diperlakukan sebagai cerita utuh, bukan ringkasannya, dan itu pula alasan event bisa dilacak balik ke transaksi penyebabnya bahkan ketika matching berjalan secara batch.
Ke mana selanjutnya
Bagaimana state yang terkomit disimpan secara fisik, diautentikasi, dan di-prune.
Bagaimana node yang belum pernah melihat chain menyusul sampai ke posisi terkini.
Tempat state mesin dan working set blok berada.
Mengubah state yang terkomit menjadi sesuatu yang bisa di-query.