Apa Itu Tingkat Komitmen Solana?

Apa itu tingkat komitmen Solana?

Tingkat komitmen Solana adalah cara terstandar untuk mengukur konsensus jaringan terhadap suatu blok atau transaksi. Saat Anda meminta status transaksi atau data akun dari node RPC Solana (misalnya getTransaction), Anda dapat menentukan tingkat komitmen untuk menunjukkan seberapa final data yang diinginkan. Solana menggunakan tingkat komitmen ini agar klien dapat menyeimbangkan latensi vs. kepastian: komitmen yang lebih rendah memberikan respons lebih cepat, sedangkan tingkat komitmen yang lebih tinggi memberikan jaminan lebih kuat kepada developer bahwa status tidak akan dikembalikan.

Solana menetapkan tiga tingkat komitmen utama (dalam urutan finalitas menurun):

Difinalisasi

Tingkat kepastian tertinggi, yang menunjukkan bahwa blok telah dikonfirmasi oleh supermayoritas stake (≥66 %), dan setidaknya 31 blok terkonfirmasi berikutnya telah dibangun di atasnya, sehingga slot tersebut memperoleh lockout maksimum sebanyak 32 suara. Transaksi yang telah difinalisasi secara efektif tidak dapat dibatalkan.

Dikonfirmasi

Tingkat menengah ketika blok telah menerima suara dari supermayoritas stake (≥66%), tetapi belum difinalisasi melalui periode pemungutan suara lanjutan yang lebih panjang sehingga semakin sulit dibatalkan. Ini sering disebut konfirmasi optimistis, yang memberikan jaminan kuat bahwa transaksi berada di “fork utama” atau chain kanonis.

Diproses

Diproses berarti transaksi baru saja diproses oleh leader dan disertakan dalam blok terbaru yang diketahui node. Namun, blok tersebut mungkin belum menerima suara dari seluruh cluster. Transaksi tersebut masih dapat dihapus jika blok itu tidak masuk ke fork mayoritas.

Tingkat-tingkat ini mewakili tahapan dalam siklus hidup transaksi. 

Transaksi yang baru dikirim akan bergerak dari Diproses → Dikonfirmasi → Difinalisasi seiring makin banyak bagian jaringan yang mengamati dan memberikan suara pada blok yang memuatnya, serta blok-blok berikutnya dibangun di atas blok tersebut. Komitmen yang lebih tinggi berarti lebih banyak node telah menyetujui penyertaan transaksi, sehingga mengurangi risiko fork atau rollback. 

Mari pelajari setiap tingkat secara mendetail.

Tingkat Komitmen Diproses

Transaksi berstatus Diproses segera setelah node validator (yaitu leader saat ini) menyertakannya ke dalam blok. Ini adalah pengakuan paling awal: transaksi telah diterima dan dimasukkan ke status ledger secara lokal.

Karakteristik utama tingkat Diproses meliputi:

• Disertakan dalam Blok: Transaksi berada dalam blok yang dihasilkan validator.
• Tidak Ada Jaminan Fork Mayoritas: Blok ini mungkin masuk atau tidak masuk ke fork mayoritas (terpanjang/terberat)
• Respons Tercepat: Memberikan respons langsung bahwa transaksi telah diproses oleh node. Ini berguna untuk pembaruan cepat di sisi klien (misalnya menampilkan transaksi tertunda di UI dompet).
• Belum Sepenuhnya Aman: Pada tahap ini, tidak ada jaminan bahwa validator lain telah melihat atau memberikan suara pada blok tersebut. Cluster masih dapat “melewati” blok ini atau menimpanya dengan fork alternatif. Dengan kata lain, Diproses = disertakan tetapi belum dikonfirmasi oleh pihak lain.

Contoh Blok yang Diproses: 

Misalnya Alice mengirim transfer di Solana. Segera setelah leader saat ini menambahkannya ke sebuah blok (slot N), transaksi ditandai sebagai Diproses. Dompet Alice mungkin langsung menampilkan transaksi sebagai tertunda/diproses. 

Namun, jika blok leader tersebut tidak diterima oleh mayoritas validator (misalnya leader lambat atau offline dan fork lain mengambil alih), transaksi Alice mungkin hilang (yaitu dihapus) karena blok yang diproses tidak menjadi bagian dari chain utama.

Tingkat Komitmen Dikonfirmasi

Tingkat komitmen Dikonfirmasi menunjukkan bahwa blok transaksi telah diterima oleh supermayoritas cluster dan kemungkinan besar berada di chain kanonis. Secara teknis, “dikonfirmasi” berarti ≥66% validator berdasarkan bobot stake telah memberikan suara langsung pada blok tersebut. 

Karakteristik utama:

• Berada di Fork Mayoritas: Blok yang memuat transaksi diakui sebagai bagian dari fork mayoritas ledger. Artinya, jaringan menganggap blok ini sebagai blok kanonis.

• Suara Supermayoritas: Setidaknya dua pertiga dari total stake telah memberikan suara untuk mengonfirmasi blok. Suara ini dikumpulkan melalui mekanisme gossip Solana, yang berarti validator telah menyiarkan dan mengamati suara untuk blok ini di seluruh jaringan. Tahap ini memanfaatkan konfirmasi optimistis, yang diperkenalkan di Solana v1.3 dan memungkinkan node menganggap blok telah dikonfirmasi segera setelah supermayoritas memberikan suara (bahkan sebelum difinalisasi).

• Risiko Pembatalan Rendah: Dengan konsensus 66%+, sangat kecil kemungkinannya, meski bukan mustahil, fork yang berkonflik menggantikan blok ini. Semua validator jujur secara efektif telah berkomitmen pada blok ini, kecuali terjadi reorganisasi besar. Belum ada blok terkonfirmasi yang dibatalkan dalam lima tahun sejarah Solana.

• Lebih Cepat daripada Difinalisasi: Status dikonfirmasi biasanya tercapai tidak lama (dalam satu atau dua detik) setelah blok atau transaksi ditandai sebagai diproses karena validator segera memberikan suara pada blok baru. Status ini tidak menunggu banyak blok berikutnya. Karena itu, dikonfirmasi menawarkan keseimbangan yang baik antara kecepatan dan keyakinan dalam kondisi normal.

• Finalitas Optimistis: Developer sering menganggap transaksi terkonfirmasi pada dasarnya final untuk sebagian besar kebutuhan praktis, mengingat cepatnya konsensus Solana. Namun, masih ada kemungkinan kecil rollback hingga finalisasi tercapai.

Contoh Blok yang Dikonfirmasi: 

Transaksi Alice di atas menjadi Dikonfirmasi setelah validator cluster memberikan suara pada blok N. Dalam praktiknya, jika beberapa validator berikutnya (pada slot N+1, N+2, dan seterusnya) memberikan suara dan melihat blok N hingga mencapai ambang 66%, jaringan menandai blok N sebagai dikonfirmasi. Dompet Alice kini dapat dengan aman menampilkan transaksi sebagai dikonfirmasi kepada pengguna. 

Kemungkinan transfer Alice dibatalkan pada tahap ini sangat rendah (hanya jika terjadi fork langka atau masalah jaringan). Ini serupa dengan “N konfirmasi” pada chain lain, tetapi di Solana dasarnya adalah pemungutan suara berdasarkan stake, bukan jumlah tetap konfirmasi blok.

Tingkat Komitmen Difinalisasi

Transaksi berstatus Difinalisasi ketika bloknya telah menerima suara supermayoritas dan cukup banyak blok tambahan telah dibangun di atasnya. Dalam konsensus Solana, ini berarti blok mencapai lockout maksimum, biasanya setelah 32 suara (slot) berturut-turut mengonfirmasinya. Difinalisasi adalah tingkat komitmen terkuat dan menawarkan kepastian tertinggi bahwa transaksi tidak akan dibatalkan. 

Karakteristik Difinalisasi meliputi:

• Blok Tidak Dapat Dibatalkan: Cluster telah mengakui blok ini sebagai final, yang berarti blok telah di-root dalam status ledger. Validator tidak akan melakukan rollback terhadapnya dan blok tersebut secara efektif permanen.

• Supermayoritas + Lockout: Seperti Dikonfirmasi, setidaknya 66% stake mendukung blok tersebut. Selain itu, 31+ blok terkonfirmasi berikutnya telah ditambahkan setelahnya. Dengan kata lain, jaringan telah membangun chain yang dalam di atas blok ini hingga mencapai kedalaman lockout yang membuat reorganisasi tidak memungkinkan.

• Lockout Maksimum (32 suara): Mekanisme Tower BFT Solana menggandakan periode lockout suara secara eksponensial. Setelah sebuah blok mengumpulkan 32 suara di tower (artinya tetap menjadi kepala fork selama 32 slot berikutnya), blok tersebut mencapai lockout maksimum dan difinalisasi. Pada tahap ini, validator yang mencoba memberikan suara untuk fork alternatif akan melanggar aturan konsensus.

• Paling Aman, Konfirmasi Paling Lambat: Finalisasi biasanya tertinggal dari tingkat diproses dan dikonfirmasi (sekitar ~10–20 detik dalam kondisi normal karena 32 slot dengan durasi ~400 md masing-masing ≈ 13 detik). Inilah kompromi untuk kepastian Difinalisasi. Dengan menunggu finalisasi, klien menghilangkan seluruh risiko transaksi dihapus atau dibatalkan, dengan konsekuensi latensi tambahan.

• Dikonfirmasi + Dibangun di Atasnya: Cara lain memahami finalisasi: blok yang dikonfirmasi dan telah tertimbun di bawah banyak blok berikutnya. Semua node jujur telah mengunci blok ini secara terverifikasi sebagai bagian dari ledger permanen.

Contoh Blok yang Difinalisasi:

Transaksi Alice mencapai status Difinalisasi setelah jaringan terus menghasilkan blok melampaui slot N. Misalnya, pada slot N+32, supermayoritas validator telah memberikan suara pada setiap blok berurutan hingga N+32 (tanpa fork lain mengambil alih). Blok N (yang memuat transaksi Alice) kini telah difinalisasi. 

Pada tahap ini, transaksi Alice sepenuhnya permanen di ledger Solana—meskipun ia menunggu beberapa saat, status yang mencakup transfernya tidak akan berubah. 

Aplikasi yang memerlukan finalitas kuat (seperti bursa yang mencairkan dana) kini dapat bertindak dengan aman berdasarkan transaksi ini. Perlu diperhatikan, jika penyerang mencoba membatalkannya, mereka harus menguasai lebih dari 1/3 stake dan melanggar konsensus.

Tingkat Komitmen yang Tidak Lagi Digunakan

Versi Solana sebelumnya (sebelum 2021) menyediakan tingkat komitmen tambahan yang kemudian tidak lagi digunakan dan digantikan oleh tiga tingkat di atas.

Sebagai pelengkap, berikut istilah lama dan pemetaannya ke tingkat saat ini:

• recent – Tidak lagi digunakan; setara dengan Diproses. Dalam dokumentasi lama, “recent” hanya merujuk pada status terbaru yang diketahui node.

• single dan singleGossip – Tidak lagi digunakan; setara dengan Dikonfirmasi. Istilah ini merujuk pada konfirmasi yang melibatkan satu validator atau melalui gossip, sesuai dengan definisi dikonfirmasi.

• root dan max – Tidak lagi digunakan; setara dengan Difinalisasi. “Root” merujuk pada status yang telah di-root dan difinalisasi dalam cluster, sedangkan “max” merujuk pada lockout maksimum—keduanya secara efektif berarti difinalisasi.

Saat ini, developer hanya boleh menggunakan processed, confirmed, atau finalized saat menentukan tingkat komitmen. Sejak v1.5.5, Solana JSON-RPC API menggunakan istilah-istilah ini secara default dan memperlakukan istilah yang tidak lagi digunakan sebagai alias untuk tingkat yang sesuai. 

Selain itu, jika komitmen tidak ditentukan dalam permintaan RPC, default-nya adalah Finalized (yaitu node mengembalikan status paling final secara default).

Perbedaan Antar-Tingkat Komitmen

Perbedaan antara Diproses, Dikonfirmasi, dan Difinalisasi dapat dipahami berdasarkan seberapa besar bagian jaringan yang telah mengakui transaksi dan seberapa besar kemungkinannya untuk dibatalkan. Tabel berikut (diadaptasi dari dokumentasi resmi Solana) merangkum perbedaan utamanya:

Singkatnya, Diproses hanya berarti transaksi berada dalam sebuah blok (tidak lebih dari itu). Dikonfirmasi berarti cluster telah menyepakati blok tersebut (melalui suara supermayoritas), tetapi blok masih berada di dekat ujung chain. Difinalisasi berarti blok berada jauh di dalam chain dengan banyak konfirmasi—cukup dalam sehingga secara efektif tidak dapat diubah.

Cara lain untuk melihat perbedaannya adalah melalui probabilitas transaksi tetap berada dalam ledger kanonis dari waktu ke waktu. 

Segera setelah diproses, probabilitasnya belum 100% (ada kemungkinan fork atau kegagalan). Setelah dikonfirmasi oleh >66% stake, probabilitas penyertaan meningkat sangat tinggi. Saat difinalisasi dengan puluhan blok di atasnya, probabilitas penyertaan menjadi ~100%. 

Hal ini digambarkan dalam grafik berikut, yang menunjukkan bagaimana kemungkinan transaksi difinalisasi meningkat seiring bertambahnya slot dan naiknya tingkat komitmen:

Kemungkinan transaksi disertakan dalam chain kanonis final meningkat seiring waktu. Pada awalnya, di slot n (transaksi diproses), terdapat risiko bahwa transaksi dapat “dilewati” atau dikeluarkan akibat fork. Dengan konfirmasi optimistis (dikonfirmasi), kemungkinan penyertaan meningkat tajam saat validator memberikan suara. Setelah cukup banyak fork berurutan dibangun di atasnya (difinalisasi), probabilitas pembatalan secara efektif mencapai nol. Ini menunjukkan bahwa risiko rollback menurun seiring meningkatnya tingkat komitmen.

Bagaimana Solana menentukan tingkat komitmen?

Memahami cara kerja konsensus Solana “di balik layar” dapat menjelaskan alasan keberadaan tingkat komitmen ini:

Proof of History (PoH) dan Produksi Blok

Leader Solana menghasilkan blok secara berurutan dengan cepat (satu leader per slot, durasi slot ~400 md). Transaksi dialirkan ke chain hash Proof of History (PoH), yang membentuk entri dalam sebuah blok. Blok disebarkan dengan cepat ke seluruh jaringan melalui Turbine (protokol propagasi blok Solana). Saat leader menghasilkan blok yang memuat transaksi Anda, blok tersebut segera disebarkan tetapi belum dikonfirmasi—ini sesuai dengan tahap Diproses.

Pemungutan Suara (Tower BFT)

Solana menggunakan algoritma konsensus BFT bernama Tower BFT. Validator (masing-masing mengendalikan sejumlah stake) memberikan suara pada blok yang mereka yakini harus menjadi bagian ledger berikutnya. Suara itu sendiri merupakan transaksi Solana dan mencakup konsep lockout. Setiap kali validator memberikan suara pada blok di slot N, validator tersebut terkena lockout sehingga jika kemudian memberikan suara pada fork yang berkonflik, validator mungkin kehilangan kemampuan untuk memberikan suara selama beberapa waktu. 

Lockout ini berlipat ganda secara eksponensial untuk setiap suara berurutan pada fork yang sama (lockout 1, 2, 4, 8... slot) dan dibatasi pada 32 suara. Jika validator memberikan suara 32 kali berturut-turut pada suatu fork (artinya blok dari 32 slot sebelumnya masih menjadi bagian dari fork terberat), blok tersebut mencapai lockout maksimum. Mekanisme ini mendorong validator untuk tetap berada di fork mayoritas dan memfinalisasi blok.

Konfirmasi (Konfirmasi Optimistis)

Saat sebuah blok dihasilkan, validator menyiarkan suara untuk blok tersebut. Segera setelah supermayoritas (≥66%) stake memberikan suara pada sebuah blok, node Solana menganggap blok tersebut dikonfirmasi secara optimistis. Ini adalah tingkat komitmen Dikonfirmasi. Proses ini berlangsung cepat, sering kali dalam satu atau dua slot setelah blok dibuat, karena suara disebarkan melalui gossip. 

Yang penting, implementasi Solana tidak mengharuskan menunggu blok di-root ke dalam ledger; implementasi ini memercayai suara supermayoritas sebagai sinyal optimistis bahwa blok tersebut pada akhirnya akan difinalisasi (selama <33% stake tidak bertindak menyimpang). 

Inilah alasan istilah konfirmasi optimistis digunakan: berdasarkan asumsi kesalahan Byzantine normal (maksimal 1/3 tidak jujur), suara supermayoritas berarti blok tidak akan dibatalkan. Agar sebuah fork dapat menggantikannya, >33% validator harus memberikan suara pada chain alternatif, yang melanggar asumsi tersebut.

Finalisasi (Melakukan Root pada Blok)

Seiring blok baru terus dihasilkan dan menerima suara, setiap blok terkonfirmasi bergerak makin dalam di dalam fork. Setelah sebuah blok mengumpulkan suara dalam 32 slot berturut-turut setelahnya, blok mencapai lockout maksimum. Pada tahap ini, jaringan melakukan root pada blok tersebut dan menandainya sebagai final serta tidak dapat dibatalkan. Finalisasi berarti blok berada setidaknya 31 blok di belakang kepala chain dan tidak pernah ditinggalkan demi fork lain. Semua node kini menganggap blok ini bagian dari riwayat yang tidak dapat diubah (status ledger hingga slot tersebut dibekukan). 

Secara efektif, komitmen Difinalisasi setara dengan “blok memiliki ≥32 konfirmasi” dalam analogi chain PoW, tetapi Solana mencapainya melalui suara yang dikunci waktu, bukan konfirmasi proof-of-work. Aturan 32 slot merupakan konsekuensi desain Tower BFT (lockout berlipat ganda hingga 2^32) dan memberikan jaminan finalitas matematis berdasarkan asumsi toleransi kesalahan 1/3.

Pemilihan Fork & Rollback

Konsensus Solana terus mengevaluasi fork. Validator menggunakan algoritma pemilihan fork terberat (berdasarkan bobot suara stake) untuk menentukan fork yang akan dijadikan dasar pembangunan. Jika sebuah blok hanya diproses oleh sebagian validator dan tidak memperoleh suara, fork lain dapat menggantikannya. Inilah alasan transaksi Diproses dapat dihapus. 

Setelah blok dikonfirmasi oleh 2/3, fork alternatif harus didukung oleh lebih dari 1/3 stake agar dapat menang. Hal ini sangat kecil kemungkinannya dan akan menunjukkan perilaku berbahaya. 

Setelah finalisasi, fork yang memundurkan blok tersebut pada dasarnya mustahil tanpa kegagalan konsensus yang sangat besar. Bahkan jika jaringan berhenti atau diserang, membatalkan slot yang telah difinalisasi memerlukan koordinasi di luar aturan protokol.

Ringkasan mekanismenya: Diproses = blok dihasilkan (PoH), tetapi belum menerima banyak suara; Dikonfirmasi = suara cluster (Tower BFT) mencapai supermayoritas pada blok (konsensus optimistis); Difinalisasi = blok tetap bertahan sebagai “root” chain setelah lebih banyak suara (finalitas konsensus absolut). Desain Solana memastikan blok terkonfirmasi menjadi final setelah jeda singkat, sehingga menyediakan konfirmasi cepat dan finalitas absolut pada akhirnya.

Kasus Penggunaan Developer untuk Setiap Tingkat Komitmen

Memilih tingkat komitmen yang tepat sangat penting saat membangun di Solana. Setiap aplikasi memiliki kebutuhan berbeda terkait kecepatan dan kepastian. 

Berikut kasus penggunaan umum dan praktik terbaik untuk setiap tingkat:

Gunakan Diproses untuk Respons Langsung dan Operasi Nonkritis

Developer dapat menggunakan komitmen Diproses dalam skenario ketika kecepatan menjadi prioritas utama dan sebagian risiko rollback dapat diterima. Misalnya, selama pengembangan dan pengujian, Anda mungkin menginginkan konfirmasi seketika bahwa transaksi telah diterima oleh validator. 

Aplikasi UI (seperti dompet atau game) dapat secara optimistis menampilkan transaksi segera setelah diproses untuk meningkatkan pengalaman pengguna (misalnya menampilkan status “tertunda”). 

Namun, karena transaksi yang diproses tidak dijamin akan bertahan, tingkat ini tidak direkomendasikan untuk alur produksi yang kritis. Jika digunakan, tingkat ini sebaiknya hanya untuk transaksi bernilai rendah atau nonkritis yang rollback-nya tidak akan menimbulkan masalah serius.

Gunakan Dikonfirmasi untuk Sebagian Besar Transaksi

Tingkat Dikonfirmasi umumnya merupakan pilihan default yang direkomendasikan untuk banyak kasus penggunaan di Solana. Tingkat ini menawarkan jaminan keberhasilan yang kuat dengan dampak latensi minimal. 

Misalnya, aplikasi DeFi yang melakukan swap token atau pengguna yang mentransfer dana biasanya mengandalkan status dikonfirmasi: setelah transaksi dikonfirmasi, aplikasi dapat menganggapnya selesai dalam kondisi normal. Tingkat ini secara signifikan mengurangi kemungkinan transaksi dihapus dibandingkan Diproses. Praktik terbaiknya adalah menggunakan tingkat komitmen Dikonfirmasi, terutama saat meminta blockhash terbaru dan mengirim transaksi, karena memberikan keseimbangan yang lebih baik antara latensi dan keamanan.

Gunakan Difinalisasi untuk Transaksi Bernilai Tinggi dan Kritis

Saat kepastian mutlak diperlukan, seperti untuk perpindahan aset bernilai tinggi, bridge lintas chain, atau konfirmasi deposit bursa, developer sebaiknya menggunakan tingkat komitmen Difinalisasi. Ini umum digunakan dalam skenario yang tidak dapat menerima risiko rollback sekecil apa pun. 

Misalnya, bursa dapat menunggu transaksi difinalisasi sebelum mengkreditkan deposit ke akun pengguna untuk menghindari kemungkinan reorganisasi yang kemudian membatalkan deposit tersebut. 

Penggunaan lainnya adalah setelah serangkaian transaksi: developer dapat memastikan status akhir telah difinalisasi sebelum menganggap operasi kompleks selesai (misalnya dalam proses audit atau penyelesaian yang memerlukan status ledger final). 

Developer harus memahami bahwa mensyaratkan komitmen Difinalisasi akan menambah latensi dan, saat beban jaringan tinggi, dapat meningkatkan kemungkinan transaksi kedaluwarsa karena Anda pada dasarnya menunggu hash blok yang lebih lama difinalisasi. Difinalisasi sebaiknya digunakan secara selektif hanya untuk transaksi paling kritis ketika keamanan tambahan sepadan dengan kompromi latensi.

Singkatnya, Diproses terutama digunakan untuk respons cepat dan penggunaan nonproduksi, Dikonfirmasi menjadi pilihan utama untuk sebagian besar operasi karena menyeimbangkan keamanan dan performa, sedangkan Difinalisasi digunakan ketika Anda benar-benar memerlukan jaminan finalitas meski harus menunggu. 

Banyak aplikasi akan menggunakan kombinasi: menampilkan pembaruan UI saat Diproses, menganggap operasi selesai saat Dikonfirmasi, dan mencatatnya setelah Difinalisasi.

Dampak terhadap Keandalan, Performa, dan Keamanan Transaksi

Pilihan tingkat komitmen berdampak langsung pada keandalan (apakah transaksi akan bertahan?), performa (latensi), dan keamanan (risiko pembelanjaan ganda atau masalah fork):

Keandalan

Tingkat komitmen yang lebih tinggi meningkatkan keandalan pencatatan permanen suatu transaksi. Transaksi yang difinalisasi pada dasarnya memiliki keandalan 100% untuk keberadaannya dalam ledger (kecuali terjadi peristiwa luar biasa), sedangkan transaksi terkonfirmasi memiliki keandalan sangat tinggi tetapi bukan 100%, dan transaksi yang diproses memiliki keandalan lebih rendah. 

Seperti disebutkan sebelumnya, sekitar ~5% transaksi dapat dihapus jika hanya mengandalkan status diproses (akibat perubahan fork), sedangkan status dikonfirmasi menurunkan risiko tersebut hingga mendekati 0%. 

Dalam aplikasi kritis, penggunaan komitmen difinalisasi menghilangkan risiko transaksi Anda berada dalam fork yang kemudian dibuang.

Performa (Latensi)

Ada kompromi yang jelas antara kecepatan memperoleh konfirmasi dan tingkat komitmen. 

Konfirmasi Diproses hampir seketika (dalam waktu satu blok, sering kali kurang dari satu detik). 

Dikonfirmasi menambah sedikit penundaan (sekitar satu atau dua slot, mungkin tambahan ~0,5–1 detik) untuk mengumpulkan suara validator—proses ini tetap sangat cepat dan biasanya tidak terasa oleh pengguna. 

Difinalisasi menambahkan penundaan terbesar karena transaksi baru dilaporkan sebagai final setelah sekitar 30+ blok berikutnya dihasilkan. Biasanya diperlukan ~10–20 detik untuk mencapai finalitas. 

Selama periode kemacetan jaringan atau produksi blok yang lambat, penundaan ini dapat berlangsung lebih lama. Karena itu, mensyaratkan komitmen Difinalisasi dapat memperlambat pengalaman pengguna dan throughput jika digunakan secara berlebihan. Jika aplikasi menunggu finalisasi, aplikasi harus memperhitungkan waktu tambahan tersebut. Namun, ini bukan berarti transaksi itu sendiri membutuhkan waktu lebih lama untuk dieksekusi secara on-chain; artinya klien menunggu lebih lama untuk memastikan transaksi telah difinalisasi. Sementara itu, Solana tetap memproses transaksi baru.

Throughput vs. Kedaluwarsa

Dampak penting yang lebih halus berkaitan dengan kedaluwarsa transaksi dan penggunaan blockhash. Transaksi Solana menyertakan blockhash terbaru dan hanya berlaku selama ~150 slot setelah blockhash tersebut. 

Jika Anda meminta blockhash finalized untuk menandatangani transaksi, blockhash tersebut lebih lama (karena finalized tertinggal dari ujung chain), sehingga jumlah slot yang tersisa sebelum transaksi kedaluwarsa menjadi lebih sedikit. Hal ini dapat meningkatkan kemungkinan kedaluwarsa jika jaringan padat dan transaksi Anda tidak segera diproses. 

Menggunakan blockhash yang lebih baru (Confirmed) memberikan rentang waktu lebih panjang. Rekomendasi resminya adalah menggunakan Confirmed untuk getLatestBlockhash guna mengurangi risiko kedaluwarsa. 

Karena itu, menggunakan Finalized untuk preflight atau blockhash dapat sedikit mengurangi waktu yang tersedia agar transaksi Anda dipilih, sehingga memengaruhi keandalan saat beban tinggi. 

Singkatnya, komitmen Difinalisasi dapat mengorbankan sebagian liveness saat beban tinggi—Anda memperoleh kepastian, tetapi mungkin dengan konsekuensi lebih banyak transaksi mengalami timeout jika jaringan mendekati kapasitas.

Keamanan

Dari sudut pandang keamanan (misalnya pencegahan pembelanjaan ganda dan keamanan fork), Difinalisasi adalah yang paling aman. 

Setelah difinalisasi, pembatalan transaksi mengharuskan lebih dari sepertiga total stake bertindak secara berbahaya, yang kemungkinan besar akan terdeteksi dan dihukum. 

Dikonfirmasi sangat aman dalam kondisi normal (penyerang harus membuat fork yang berkonflik dan meyakinkan >33% validator untuk mendukungnya setelah supermayoritas memberikan suara, yang sangat kecil kemungkinannya tanpa serangan besar dan terkoordinasi). 

Namun, secara teori terdapat skenario ketika beberapa validator (sedikit di bawah 33%) menahan suara atau sebuah fork tepat berada di ambang batas, sehingga blok terkonfirmasi dapat menjadi yatim. Namun, desain Solana (konfirmasi optimistis) mengasumsikan mayoritas yang jujur untuk mencegah hal ini. 

Diproses memberikan keamanan paling rendah: sebelum suara masuk, tidak ada jaminan bahwa validator lain mengetahui transaksi tersebut. Leader berbahaya bahkan dapat menyertakan transaksi lalu gagal menyebarkan blok dengan benar, dan sebagainya. 

Karena itu, Diproses tidak boleh diandalkan untuk konfirmasi apa pun yang kritis bagi keamanan (status ini lebih menyerupai “notifikasi” bahwa proses telah dimulai). 

Singkatnya: Difinalisasi > Dikonfirmasi > Diproses dalam hal keamanan terhadap fork dan pembelanjaan ganda.

Penggunaan Komitmen pada Operasi Baca vs. Tulis

Saat membaca status dari Solana (misalnya memeriksa saldo akun melalui RPC), Anda juga menentukan tingkat komitmen. Jika menggunakan tingkat komitmen Diproses untuk operasi baca, Anda mungkin melihat data yang sangat mutakhir, tetapi data tersebut bisa berasal dari fork yang belum difinalisasi. Menggunakan Difinalisasi untuk operasi baca memberi Anda konsistensi mutlak (status yang disepakati semua pihak), tetapi mungkin tertinggal beberapa slot. Untuk sebagian besar kasus, menggunakan Dikonfirmasi untuk kueri status memberikan keseimbangan yang baik, sama seperti transaksi. Ini memastikan Anda tidak mengambil keputusan berdasarkan fork yang mungkin dibatalkan. 

Untuk kueri tulis (yaitu mengirim transaksi), komitmen terutama menentukan cara pustaka klien menunggu konfirmasi. Pola yang umum adalah mengirim transaksi dengan preflightCommitment tertentu (yang dapat menyimulasikan TX terhadap status terbaru), lalu menggunakan confirmTransaction dengan tingkat komitmen yang sama. Developer dapat memilih untuk menunggu konfirmasi finalized jika diperlukan.

Sebagai gambaran dengan angka nyata: berdasarkan pengukuran terbaru, Solana memproses transaksi dalam ~0,4 detik, mencapai status dikonfirmasi dalam ~0,6 detik, dan mencapai finalisasi dalam ~13 detik. 

Jika aplikasi Anda, misalnya aplikasi pembayaran, tidak dapat menunggu ~13 detik per transaksi, gunakan dikonfirmasi, yang tetap memberikan keamanan kuat. 

Jika Anda memindahkan jumlah besar antar-chain, Anda dapat memilih menunggu penuh selama ~13 detik untuk memperoleh kepastian sepenuhnya. Sebaliknya, jika Anda membangun sesuatu yang mengutamakan kecepatan dan dapat menerima sedikit risiko, seperti memperbarui UI secara optimistis, Anda dapat mengandalkan status diproses untuk memberikan pengalaman pengguna yang responsif.

Kesimpulan

Tingkat komitmen Solana—Diproses, Dikonfirmasi, dan Difinalisasi—merupakan fitur inti yang memungkinkan developer menyesuaikan keseimbangan antara kecepatan dan kepastian untuk setiap transaksi.

Diproses memberikan hasil langsung tetapi belum pasti, Dikonfirmasi memberikan jaminan nyaris final dalam satu atau dua detik (cukup untuk sebagian besar aplikasi), dan Difinalisasi menawarkan finalitas mutlak setelah menunggu lebih lama. 

Di balik layar, tingkat-tingkat ini berkaitan dengan progres konsensus Solana: mulai dari blok dihasilkan, menerima suara supermayoritas, hingga di-root dalam ledger dengan lockout maksimum.

Saat membangun di Solana, penting untuk memilih tingkat komitmen yang tepat untuk setiap tugas:

• Gunakan komitmen lebih rendah untuk respons cepat atau tindakan nonkritis
• Gunakan dikonfirmasi untuk operasi standar yang memerlukan kecepatan sekaligus keamanan
• Gunakan difinalisasi untuk kasus yang hanya dapat menerima finalitas penuh

Setiap tingkat memengaruhi keandalan penyertaan transaksi dan lamanya waktu tunggu. 

Dengan memahami makna teknisnya (66% suara, 32 blok, fork, dan lockout) serta mengikuti praktik terbaik terbaru, developer dapat memperoleh performa yang dijanjikan Solana tanpa mengorbankan konsistensi dan keamanan aplikasi mereka.

Sumber Daya Tambahan

• Dokumentasi Solana – Mengonfigurasi Komitmen Status, Tabel Status Komitmen
• Blog Helius – Konsensus di Solana (mekanisme konsensus dan finalitas)