> ## 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. # IntentionBFT > Konsensus: bagaimana urutan dan vektor harga tersertifikasi dikomit bersama, dan bagaimana jaringan ini ditata. IntentionBFT adalah protokol konsensus Intention — protokol BFT keluarga HotStuff yang diperluas untuk infrastruktur finansial. Keamanan berlaku tanpa syarat di bawah ambang batas kegagalan; keaktifan berlaku setelah jaringan stabil. Konsensus di sini melakukan dua hal yang tidak dilakukan konsensus chain serbaguna: mengomit **urutan** sebagai objek kelas satu, dan mengomit **vektor harga tersertifikasi** dalam peristiwa yang sama. Semua yang bisa dijamin [kernel](/id/protocol/architecture/kernel) tentang eksekusi bergantung pada tuntasnya kedua hal itu sebelum eksekusi dimulai. ## Model IntentionBFT mentoleransi lawan Byzantine yang menguasai hingga sepertiga total stake. Karena itu stake jujur selalu lebih dari dua pertiga, dan kuorum standarnya adalah himpunan validator mana pun yang gabungan stake-nya melebihi dua pertiga — yang halaman-halaman ini sebut **kuorum berbobot stake $2f+1$**. Jaringannya sinkron sebagian: sebelum titik stabilisasi, penundaan bersifat sembarang; setelahnya, penundaan antarvalidator jujur terbatas.
Sidecar oraclesatu per validator
Validasi dan tanda tangan validatorkesegaran terhadap ambang batas yang dikonfigurasi
Gossip antarvalidatorsebagai pesan jaringan konsensus
Harga tersertifikasiper epoch dan ronde
Ketersediaan harga: prasyarat produksi blokValidator hanya berhak mengusulkan blok jika bisa menyajikan observasi harga yang valid untuk ronde berjalan — sehingga tanda tangan yang mengomit transaksi juga mengomit harga yang menjadi dasar penyelesaiannya.
Apa yang tidak diklaimIni mengikat harga pada transaksi. Ini tidak membuat harganya benar — konsensus menyertifikasi bahwa kuorum validator mengirimkan observasi ini pada ronde ini, tidak lebih.
Setiap ronde punya leader yang ditunjuk. Di dalam satu ronde, usulan mengumpulkan agregat tanda tangan $2f+1$ secara berturut-turut, dan fase-fasenya di-pipeline melintasi ronde yang bersebelahan, sehingga blok mencapai finalitas dalam dua putaran pesan jaringan pada kasus umum. Di bawah responsivitas optimistik, kemajuan dibatasi oleh penundaan pesan yang sebenarnya; backoff `pacemaker` baru aktif ketika jaringan bersifat adversarial atau terpartisi.

Mengomit urutan

Urutan transaksi di dalam blok dinaikkan menjadi objek yang dikomit konsensus alih-alih dibiarkan sebagai artefak eksekusi. Hash blok mencakup muatan yang telah diurutkan, sehingga pengurutan ulang apa pun setelah konsensus membatalkan tanda tangan yang mengomitnya. Efeknya: begitu blok difinalisasi, kuorum berbobot stake $2f+1$ telah menandatangani komitmen atas urutan persis itu, dan tidak ada validator jujur yang akan menandatangani urutan berbeda atas transaksi yang sama di ronde yang sama. Digabung dengan eksekusi berurutan di atas urutan terkomit itu, inilah yang mengubah replay deterministik dari konvensi implementasi menjadi properti yang bisa diperiksa siapa pun. Keleluasaan leader di dalam satu usulan — batch tersedia mana yang disertakan dan bagaimana menyusunnya — tetap menjadi permukaan sisa, yang diredam oleh reputasi leader dan oleh kenyataan bahwa seorang leader tidak bisa memproduksi blok sama sekali tanpa observasi harga yang valid. Konstruksi fair-ordering yang lebih kuat dilacak sebagai kandidat upgrade di masa depan.

Ketersediaan batch

Pada protokol naif, leader mengusulkan blok yang muatannya membawa seluruh transaksi ronde tersebut, sehingga ukuran pesan konsensus terkopel dengan throughput. IntentionBFT memisahkan penyebaran data dari pengurutan. Validator terus-menerus menyebarkan batch transaksi di latar belakang. Setiap batch diakui sampai pengirim asalnya bisa membuktikan ketersediaan berbobot stake $2f+1$, dan baru setelah itu usulan boleh merujuknya — lewat digest, bukan lewat isinya. Pesan konsensus tetap kecil berapa pun throughput-nya, dan blok yang dikomit selalu bisa di-replay, karena tidak ada blok yang bisa merujuk data yang hanya dipegang minoritas Byzantine.

Menyertifikasi harga

Validator sekaligus pengamat harga, dan setiap blok membawa harga yang dipakai saat blok itu dieksekusi.
Validatorkonsensus · mempool · sidecar oracle · kernel · penyimpanan
Satu-satunya pemberi suara
Full node validatormengikuti dan mengeksekusi blok terkomit; tanpa suara
Pelindung — menyerap lalu lintas baca publik dan koneksi peer agar validator tidak terpapar langsung ke internet terbuka
Full node publiksiapa pun bisa menjalankan; mengikuti, melayani baca
Lapisan terbuka
Klienfront end · agen trading · market maker · indexer
Klien terhubung ke full node, bukan ke validator. Yang butuh latensi terendah dan pandangan terlengkap menjalankan full node sendiri.
Empat lapisan, menjauh dari konsensus
Alasan tiap lapisan
Setiap validator menjalankan [sidecar oracle](/id/protocol/architecture/oracle)-nya sendiri, yang mengumpulkan data venue dan menghasilkan satu harga indeks per instrumen. Validator menarik harga itu, memvalidasinya — termasuk kesegaran terhadap ambang batas yang dikonfigurasi — menandatanganinya, dan menyebarkan kiriman bertanda tangan itu ke validator lain sebagai pesan jaringan konsensus. Harga tersertifikasi dirakit per epoch dan ronde lalu dibawa di dalam blok, sehingga tanda tangan yang mengomit transaksi juga mengomit harga yang menjadi dasar penyelesaian transaksi tersebut. Validator hanya berhak mengusulkan blok jika bisa menyajikan observasi harga yang valid untuk ronde berjalan. Ketersediaan harga karenanya adalah prasyarat produksi blok, bukan input yang diharap-harap ditemukan oleh eksekusi. Ini mengikat harga pada transaksi; ini tidak membuat harganya benar. Konsensus menyertifikasi bahwa kuorum validator mengirimkan observasi ini pada ronde ini. Apakah venue yang mendasarinya akurat adalah pertanyaan terpisah, yang dibahas oleh aturan agregasi di halaman [Oracle](/id/protocol/architecture/oracle) dan dibatasi oleh [pengungkapan risiko](/id/protocol/security/risks).

Reputasi leader

Leader dipilih ronde demi ronde lewat rotasi berbobot stake yang deterministik, diperluas dengan heuristik reputasi atas jendela bergerak. Validator dengan usulan gagal berulang — menandakan ketidaktersediaan atau perilaku adversarial — diturunkan pada pemilihan berikutnya, dan slotnya dibagikan ulang ke validator yang belakangan responsif. Dengan begitu, validator yang tidak tersedia tidak menghambat kemajuan hanya karena mengklaim kepemimpinan atas slot yang ditugaskan kepadanya. Karena observasi harga menjadi syarat kelayakan mengusulkan, reputasi juga harus menghindari pemusatan kepemimpinan pada validator dengan konektivitas data pasar terbaik. Persyaratan keragaman venue — observasi diambil dari beberapa sumber independen per instrumen — menutup jalur itu.

Epoch dan rekonfigurasi

Waktu diorganisasi menjadi epoch. Di dalam satu epoch, himpunan validator dan sebagian besar parameter bersifat tetap. Pada batas epoch, keduanya dapat berubah lewat rekonfigurasi yang diotorisasi tata kelola: perubahan himpunan validator, perubahan parameter konsensus, pembaruan parameter risiko, dan tindakan darurat. Transisinya atomik — setiap validator jujur melihat transisi yang sama pada tinggi blok yang sama.

Topologi jaringan

Leader
Validator
Chain
Agregat berbobot stake 2f+1
Urutan dan harga kini tak dapat diubah
Usulkan blok — digest batch dan harga tersertifikasi
Verifikasi ketersediaan, urutan, harga
Suara
Sertifikasi ronde
Komit
**Validator** ikut serta dalam konsensus. Masing-masing menjalankan tumpukan penuh: konsensus, mempool, sidecar oracle, eksekusi kernel, dan penyimpanan. Merekalah satu-satunya peserta yang memberi suara. **Full node validator** berada tepat di belakang validator. Mereka mengikuti blok yang dikomit dan mengeksekusinya, tetapi tidak memberi suara. Tujuannya adalah pelindung — mereka menyerap lalu lintas baca publik dan koneksi peer agar validator tidak terpapar langsung ke internet terbuka. **Full node publik** adalah lapisan terbuka. Siapa pun bisa menjalankannya. Mereka mengikuti chain, mengeksekusi blok yang dikomit, melayani pembacaan, dan memasok sistem di hilir. **Klien** — front end, agen trading, market maker, indexer — terhubung ke full node, bukan ke validator. Klien yang butuh pandangan terlengkap dengan latensi terendah menjalankan full node-nya sendiri alih-alih bergantung pada milik orang lain. Node yang bergabung ke jaringan secara bawaan tidak me-replay chain dari genesis; lihat [sinkronisasi state](/id/protocol/architecture/state/sync) untuk cara node baru mengejar ketertinggalan.

Ke mana selanjutnya

Apa yang sampai ke konsensus, dalam urutan apa, dan apa yang dibuang. Apa yang terjadi pada blok setelah urutan dan harganya dikomit. Bagaimana harga indeks dihasilkan sebelum validator menandatanganinya. Mengapa himpunan validator tertutup, dan bagaimana menanyakan cara bergabung.