Apa Itu Preconfirmations (Preconfs) di Solana?

Siklus Hidup Transaksi di Dalam Leader

Berikut adalah penjelasan yang sengaja difokuskan pada siklus hidup transaksi di dalam leader dalam kaitannya dengan preconfirmations dan observabilitas. Untuk penjelasan lengkap mengenai siklus hidup transaksi di Solana, lihat ikhtisar teknis Solana Virtual Machine (SVM) kami.

Sebelum Mencapai Leader

Di Solana, transaksi yang telah ditandatangani dikirim langsung ke produsen blok (yaitu leader) dan leader berikutnya. Transaksi tiba melalui QUIC, dengan kapasitas koneksi yang dialokasikan berdasarkan bobot stake, sehingga transaksi yang diteruskan melalui koneksi dengan stake jauh lebih mungkin diterima saat beban tinggi.

Pada titik ini, transaksi hanya terlihat oleh pengirim dan node RPC atau layanan pendaratan transaksi yang meneruskannya ke leader saat ini dan leader berikutnya. 

Nasib transaksi pada tahap ini belum dapat diketahui. 

Tahap 1: Ingest dan SigVerify

Transaction Processing Unit (TPU) milik leader menerima transaksi masuk sebagai paket, melakukan deserialisasi, memverifikasi tanda tangannya, dan membuang duplikat. Saat beban tinggi, paket yang tidak valid dan transaksi spam dibuang sebelum menggunakan sumber daya lebih lanjut.

Transaksi yang diterima dan lolos verifikasi tanda tangan pada tahap SigVerify hanyalah sebuah kandidat; ribuan transaksi kandidat tiba per slot, dan banyak di antaranya tidak pernah masuk ke dalam blok.

Tidak ada observabilitas yang berarti pada tahap ini karena mengalirkan transaksi tersebut sama saja dengan mengalirkan noise. 

Tahap 2: Scheduler

Produksi blok berlangsung pada Banking Stage, dan sejak Agave 1.18, inti prosesnya adalah scheduler pusat: satu thread penjadwalan dengan pandangan global terhadap semua transaksi yang tertunda, yang mendistribusikan pekerjaan ke sekumpulan worker eksekusi. Gagasannya adalah bahwa satu thread dengan konteks penuh dapat mengemas blok dengan konflik lock yang jauh lebih sedikit daripada n thread yang bersaing secara agresif untuk antrean bersama.

Pada dasarnya, scheduler memproses transaksi melalui tiga langkah utama:

1. Buffering dan Prioritisasi

Transaksi yang masuk tiba di komponen receive and buffer milik scheduler. Di sana, prioritas dan biaya setiap transaksi dihitung, lalu transaksi dimasukkan ke dalam container yang diurutkan berdasarkan prioritas.

Pada saat ini, sebuah transaksi masih menjadi satu dari ribuan kemungkinan yang dapat dikeluarkan jika buffer dipenuhi pekerjaan dengan prioritas lebih tinggi.

2. Penjadwalan 

Control loop dalam controller milik scheduler berulang kali mengambil transaksi dengan prioritas tertinggi dari container, memeriksa konflik account lock, lalu mengelompokkannya ke dalam batch untuk dieksekusi.

Sejak Agave 2.3, algoritma penjadwalan yang digunakan adalah greedy scheduler. Algoritma ini menggantikan desain prio-graph sebelumnya setelah pengujian menunjukkan bahwa pendekatan greedy mengemas blok dengan overhead yang lebih rendah.

3. Distribusi 

Batch yang telah dijadwalkan dikirim melalui channel ke worker eksekusi. Leader kini telah mengalokasikan sumber daya nyata—thread worker, account lock, dan tempat di blok yang sedang dirakit—untuk transaksi khusus ini.

Pada titik ini, transaksi masih tertunda. Leader bermaksud mengeksekusinya, tetapi belum ada proses yang berjalan, sehingga belum ada hasil yang dapat dilaporkan. Preconfirmations hadir satu langkah setelahnya.

Apa perbedaan arsitektur scheduler Firedancer dengan Agave?

Firedancer mencapai titik yang sama melalui arsitektur yang sedikit berbeda. Alih-alih menggunakan thread yang berbagi memori, Firedancer menjalankan tile terisolasi yang terhubung melalui antrean memori bersama, dengan logika penjadwalannya berada di pack tile. 

Pack tile menyimpan semua transaksi yang tertunda, melacak account yang sedang digunakan oleh setiap bank tile, serta memilih transaksi tanpa konflik yang memaksimalkan biaya ke dalam microblock untuk diserahkan kepada bank tile agar dieksekusi. 

Proses serah terima yang sama terjadi, ketika transaksi terpilih berpindah dari logika pengemasan ke unit eksekusi, tempat hasilnya ditentukan.

Tahap 3: Eksekusi

Worker di Agave atau bank tile di Firedancer mengeksekusi batch transaksi yang dijadwalkan terhadap bank saat ini, memuat account, menjalankan program, dan melakukan commit atas hasilnya.

Di tahap ini pula transaksi yang dijadwalkan dapat gagal karena berbagai alasan, termasuk saldo yang tidak mencukupi, error program, pemeriksaan slippage yang memicu revert, atau kondisi runtime lainnya. Apa pun hasilnya, hasil tersebut kini hanya tersedia secara lokal di mesin leader.

Inilah saat preconfirmation dipancarkan. Leader mengalirkan setiap transaksi tepat ketika transaksi tersebut dieksekusi, beserta statusnya, sebelum hasilnya dicatat ke dalam entry dan jauh sebelum data blok meninggalkan mesin.

Inilah momen pertama dalam seluruh siklus hidup ketika hasil transaksi telah tersedia dan dapat dilaporkan. Sebelum eksekusi, hanya ada sekumpulan kandidat tertunda tanpa hasil untuk dialirkan; setelahnya, informasi tersebut sudah mulai dikemas ke dalam blok yang bergerak menuju seluruh jaringan.

Karena itu, eksekusi adalah satu-satunya tempat sinyal awal semacam ini dapat tersedia. Itulah sebabnya setiap preconfirmation membawa hasil transaksi yang sebenarnya, bukan prediksi.

Namun, preconfirmation tidak dapat memberi tahu Anda apakah blok yang memuat transaksi akan menjadi kanonis. Blok tersebut belum dipecah menjadi shred, disebarkan, atau dipilih melalui voting. 

Oleh karena itu, preconfirmations merupakan sebuah sinyal, bukan jaminan.

Tahap 4: Proof of History dan Entry

Batch yang telah dieksekusi dicatat ke dalam stream Proof of History untuk menghasilkan entry, yaitu kumpulan transaksi yang di-hash dan dijalin ke dalam jam leader yang dapat diverifikasi. Entry adalah format asli ledger, tetapi pada tahap ini hanya tersedia di mesin leader.

Observabilitas bagi siapa pun di luar leader praktis tidak ada.

Perhatikan bahwa Proof of History akan dihapus melalui pembaruan Alpenglow, karena Rotor dan Votor menghilangkan kebutuhan akan jam terdesentralisasi di Solana. Model preconfirmation tidak terpengaruh: leader akan tetap mengeksekusi transaksi sebelum menyebarkannya, sehingga sinyal paling awal yang dapat diamati tetap berupa hasil eksekusi lokal leader. 

Tahap 5: Shredding dan Penyiaran

Entry dipotong menjadi shred, atau fragmen berukuran MTU yang menggunakan erasure coding agar tahan terhadap kehilangan data. Shred ini ditandatangani dan disiarkan melalui tree berbobot stake milik Turbine.

Di sinilah akses observabilitas terbuka sepenuhnya. Shred adalah artefak pertama dari sebuah blok yang meninggalkan mesin leader. Karena itu, semua produk data awal lainnya di Solana, termasuk stream shred, dimulai di sini. Siapa pun yang merekonstruksi transaksi dari shred tergolong cepat dibandingkan dengan level commitment RPC, tetapi masih lebih lambat daripada preconfirmation karena leader telah mengeksekusi transaksi sebelum shred tersedia. 

Proses berlanjut ketika validator menjalankan ulang blok, melakukan voting, dan transaksi naik melalui level commitment processed, confirmed, dan finalized. 

Di mana posisi preconfirmations dalam jenjang latensi?

Preconfirmations adalah sinyal tercepat di Solana dibandingkan semua sinyal lainnya, termasuk shred mentah dan yang telah didekode, LaserStream, serta metode streaming data lainnya. 

Namun, preconfs paling tepat dipahami sebagai salah satu tingkat dalam jenjang latensi, di mana setiap tingkat menukar sebagian kelengkapan atau kepastian demi pengamatan yang lebih awal.

Dari yang paling awal hingga paling akhir:

Ada dua pengamatan yang dapat diambil dari tabel ini. 

Pertama, semua sinyal ini saling melengkapi, bukan secara langsung menggantikan satu sama lain.

Sebagai contoh, preconfirmations melaporkan apa yang baru saja dieksekusi oleh leader sebelum jaringan mengetahuinya, sedangkan pesan dari LaserStream menunjukkan apa yang terjadi beserta metadata lengkap.

Sistem produksi umumnya perlu menggunakan keduanya, yaitu bertindak berdasarkan preconfirmations dan menggunakan sinyal hilir untuk verifikasi.  

Kedua, jarak antartingkat tidak seragam.

Peralihan dari stream processed ke shred menghemat beberapa milidetik dalam kisaran satu digit, sedangkan peralihan dari shred ke preconfirmations melewati sisa pipeline produksi blok (yaitu pencatatan entry, shredding, dan penyebaran). Ini karena titik pengamatan berpindah dari artefak publik pertama blok ke hasil yang hanya tersedia di dalam leader. 

Hasilnya, preconfirmations sekitar 5 hingga 50 milidetik lebih cepat daripada shred. 

Model Kepercayaan Preconfirmations: Sinyal, Bukan Jaminan

Semua yang dijanjikan preconfirmation dapat dirangkum dalam satu kalimat: leader telah mengeksekusi transaksi ini dengan hasil ini. Semua yang tidak dijanjikan preconf juga berasal dari kalimat yang sama.

Transaksi yang telah dieksekusi belum tentu merupakan transaksi yang sudah masuk, yang berarti blok pembawanya belum dipecah menjadi shred, disebarkan, atau dipilih melalui voting. Blok ini masih mungkin dilewati atau dikeluarkan dari fork sebelum dikonfirmasi oleh jaringan. Hampir semua transaksi yang telah menerima preconfirmation berhasil masuk secara onchain. Namun, sistem apa pun yang bertindak berdasarkan preconfirmations harus mengonfirmasi hasil melalui pemeriksaan observabilitas lain sebelum menganggapnya final.

Cakupannya juga sengaja dibuat parsial. Preconfirmations hanya tersedia untuk slot yang leader-nya meneruskan stream transaksi terjadwal ke Helius. Oleh karena itu, cakupan bertambah sesuai porsi stake jaringan yang berpartisipasi, dan stream tersebut belum tentu berkelanjutan.

Jika layanan memerlukan cakupan berkelanjutan sebagai jaminan mutlak, pertimbangkan untuk beralih ke LaserStream atau Shred Delivery saat terjadi celah.

Karena preconfirmations dipancarkan setelah eksekusi, pelanggan melihat hasil yang sudah ditentukan, bukan order flow tertunda yang menunggu untuk dieksploitasi. Artinya, peluang untuk mendahului transaksi tersebut di dalam blok sudah tertutup. Inilah perbedaan penting antara menjual visibilitas awal dan membocorkan order flow sebelum penjadwalan: yang pertama memungkinkan pelanggan bereaksi lebih cepat daripada seluruh jaringan, sedangkan yang kedua memungkinkan mereka bertindak melawan transaksi yang sedang dialirkan. Preconfirmations sepenuhnya merupakan kategori pertama.

Sinyal ini transparan mengenai sifatnya: tidak ada komitmen ekonomi yang mendukung preconfirmation, dan memang tidak ada klaim semacam itu. Leader melaporkan hasil lokalnya, tetapi tidak mempertaruhkan apa pun untuk menjamin tindak lanjut. Untuk strategi yang didukung oleh preconfirmations, inilah kompromi yang tepat.

Sebagai contoh, bot likuidasi tidak memerlukan janji sempurna yang dapat dikenai slashing bahwa sebuah transaksi akan masuk; bot tersebut perlu mengetahui hasil transaksi tertentu beberapa milidetik sebelum pesaingnya.

Bagaimana cara kerja Helius Preconfirmations?

Helius Preconfirmations dikirim melalui satu langganan WebSocket. Klien dapat terhubung ke endpoint Gatekeeper kami (yaitu wss://beta.helius-rpc.com) dan mengirim permintaan preconfSubscribe:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "preconfSubscribe",
  "params": [
    {
      "failed": false,
      "regionInclude": ["ewr", "fra"],
      "accountInclude": ["TARGET_WALLET_ADDRESS"],
      "accountExclude": [],
      "accountRequired": []
    }
  ]
}

Filter diterapkan di sisi server berdasarkan account (yaitu include, exclude, required), wilayah, dan status, dengan dukungan untuk lookup table (LUT). Dengan demikian, pelanggan hanya menerima dan membayar transaksi terjadwal yang relevan dengan strateginya. 

Karena preconfirmations dipancarkan setelah eksekusi, filter status bekerja berdasarkan hasil nyata: failed: false, yang berarti transaksi gagal tidak pernah dialirkan atau ditagihkan.

Harga berbasis kredit, selaras dengan langganan Helius WebSocket lainnya, yaitu 10 kredit per pesan dan satu pesan per transaksi yang dialirkan. Fitur ini tersedia pada paket Professional dan yang lebih tinggi. 

Setelah itu, setiap transaksi terjadwal yang cocok dengan filter tiba sebagai frame biner ringkas. Frame tersebut terdiri dari header tetap sebesar 18 byte yang memuat versi transaksi, slot tempat transaksi dijadwalkan, indeks transaksi di dalam slot, dan statusnya, diikuti byte transaksi lengkap. 

Format ini sengaja dibuat sederhana karena header tetap dapat didekode dalam hitungan nanodetik tanpa perlu parsing JSON pada jalur kritis. Satu-satunya JSON yang diperlukan dalam pertukaran ini adalah konfirmasi langganan demi kemudahan. 

Perhatikan bahwa preconfirmation hanya mencakup separuh proses transaksi. Melihat transaksi lebih dulu hanya berguna jika respons juga masuk lebih dulu. Karena itu, kami juga meluncurkan Sender Max, tingkat Helius Sender dengan performa tertinggi.

Sender Max merutekan pengiriman (yaitu satu transaksi atau bundle atomik hingga empat transaksi) melalui setiap jalur berkecepatan tinggi yang tersedia dan memasukkannya ke buffer tip prioritas yang mengutamakan tip tertinggi. Tip minimumnya adalah 0,001 SOL.

Dapatkan sinyal dengan preconfSubscribe, masukkan transaksi dengan Sender Max.  

Apa yang dapat Anda bangun dengan preconfirmations?

Setiap strategi yang profitnya menurun pada setiap milidetik antara saat transaksi diputuskan dan saat diamati akan mendapat manfaat dari preconfs. Strategi ini mencakup, tetapi tidak terbatas pada, kasus penggunaan berikut: 

Sniping

Pembuatan pool baru dan peluncuran token terlihat tepat saat transaksi deployment dieksekusi di dalam leader. Pelaku sniping yang menggunakan preconfirmations dapat bereaksi ketika pengamat shred masih menunggu fragmen pertama blok tiba. 

Copy Trading

Pergerakan wallet target muncul dalam stream preconfirmation saat leader mengeksekusinya. Memfilter alamat target menggunakan accountInclude mengubah stream menjadi feed pencerminan khusus, yang memberikan wawasan tentang pergerakan sebelum pelaku copy trading lainnya.

Likuidasi

Pembaruan oracle yang membuat posisi merugi dapat diketahui saat pembaruan tersebut dieksekusi. Bot likuidasi yang melihatnya pada saat itu menjalankan seluruh pipeline lebih awal daripada bot yang mengamati shred atau commitment processed. Hal ini membuat preconfirmations sangat penting bagi aktivitas likuidasi.

Market Making dan propAMMs

Flow masuk yang terlihat pada saat eksekusi memberi propAMMs dan sistem kuotasi lainnya keunggulan awal untuk menetapkan ulang harga atau menarik kuotasi usang sebelum flow tersebut diketahui publik. 

Dalam setiap kasus, preconfirmations memindahkan titik reaksi strategi dari “setelah jaringan mengetahui” menjadi “saat leader mengeksekusi.”

Dapatkan Penghasilan dengan Meneruskan Preconfirmations

Cakupan preconfirmation merupakan efek jaringan, dengan validator di sisi penyedia. Validator mana pun dapat meneruskan stream-nya ke Helius dan memperoleh pendapatan, sehingga produk sampingan produksi blok menjadi sumber penghasilan terlepas dari apakah validator tersebut memonetisasi posisinya dengan cara lain.

Semakin besar stake yang berpartisipasi, semakin luas cakupannya. Validator yang tertarik untuk berpartisipasi dapat menghubungi kami dan menemukan informasi lebih lanjut dalam dokumentasi preconfirmations untuk validator kami. 

Apa perbedaan antara preconfs Ethereum dan preconfs Solana?

Preconfirmations Ethereum adalah komitmen proposer yang menjamin transaksi akan masuk ke blok mendatang, sedangkan preconfirmations Solana adalah sinyal transaksi onchain real-time untuk transaksi yang baru saja dieksekusi secara lokal oleh leader bagi blok saat ini. Yang pertama berfokus pada mengetahui lebih awal, sedangkan yang kedua berfokus pada melihat lebih awal.

Preconfirmations Ethereum

Di Ethereum, preconfirmations—yang sering ditulis sebagai based preconfs dalam literatur riset, sebuah desain yang pertama kali diuraikan oleh Justin Drake pada 2023—merupakan komitmen inklusi. Sebelum slot-nya, proposer berjanji bahwa sebuah transaksi akan disertakan dalam blok mendatang, dengan janji yang didukung oleh mekanisme ekonomi seperti slashing. 

Ada beberapa implementasi aktif: 

• MEV-Commit dari Primev, marketplace tempat wallet, searcher, dan protokol intent mengajukan bid kepada penyedia eksekusi (yaitu block builder dan sequencer) untuk mendapatkan komitmen
• ETHGas, jaringan preconfirmation yang didukung secara ekonomi
• Bolt dari Chainbound, yang menawarkan komitmen proposer tanpa izin dan kompatibel dengan MEV-Boost

Yang terpenting, preconfirmations Ethereum:

• Berkaitan dengan transaksi Anda sendiri
• Diterbitkan sebelum eksekusi
• Dioptimalkan untuk kepastian

Preconfirmations Ethereum menjamin transaksi Anda akan masuk sebelum hal itu benar-benar terjadi.

Ethereum memerlukan mekanisme ini karena cara bloknya dibuat. Sebagian besar proposer melelang pembuatan blok tepat pada waktunya melalui MEV-Boost, sehingga tidak ada hal terkait blok yang dapat dijanjikan secara kredibel hingga lelang tersebut selesai. Namun, Solana tidak pernah memiliki celah tersebut. Jadwal leader sudah diketahui sebelumnya, tidak ada mempool, dan satu leader menerima, mengurutkan, mengeksekusi, serta mengalirkan bloknya secara berkelanjutan di dalam slot. Sinyal awal yang harus diciptakan Ethereum melalui kerangka ekonomi sudah tersedia secara native dalam pipeline produksi blok Solana; sinyal tersebut hanya perlu diekspos.

Preconfirmations Solana

Preconfirmations Solana adalah sinyal onchain real-time, bukan janji untuk masa mendatang: leader melaporkan transaksi yang sudah dieksekusi sebelum transaksi tersebut disebarkan ke seluruh jaringan.

Yang terpenting, preconfirmations Solana:

• Mencakup transaksi semua orang
• Dipancarkan setelah eksekusi
• Dioptimalkan untuk latensi

Preconfirmations Solana memungkinkan Anda melihat transaksi yang telah dieksekusi beberapa milidetik sebelum transaksi tersebut diamati di seluruh jaringan melalui shred atau permintaan RPC pada level commitment standar.

Padanan Solana yang paling mirip dengan preconfirmation reservasi blockspace Ethereum adalah marketplace compute unit Raiku untuk Ahead-of-Time (AOT) Transactions, yang memungkinkan aplikasi mereservasi jaminan inklusi dalam blok mendatang.

Kesimpulan

Setiap transaksi di Solana melewati satu momen ketika nasibnya berubah dari tidak diketahui menjadi diputuskan: saat leader mengeksekusinya. Preconfirmations adalah momen tersebut, yang dialirkan sebelum seluruh jaringan dapat melihatnya. Preconfirmations berada di atas shred dalam jenjang latensi karena mengamati hasil eksekusi leader, bukan artefak publik blok. Preconfirmations adalah sinyal, bukan jaminan, karena sebuah blok belum dianggap kanonis hingga dikonfirmasi oleh jaringan.

Untuk sistem yang sensitif terhadap latensi—pelaku sniping, copy trader, likuidator, market maker, dan searcher—berlanggananlah dengan preconfSubscribe, filter account yang penting, respons sinyal dengan Sender Max, dan lakukan verifikasi melalui pemeriksaan commitment standar.

Referensi langganan lengkap, format pesan, dan contoh integrasi tersedia dalam dokumentasi preconfirmations kami.