Di Batas Determinisme: Siklus Hidup Transaksi di Solana Sealevel dan Sui Object Runtime

Apa itu siklus hidup transaksi blockchain?

Blockchain memproses transaksi. Transaksi memengaruhi state (yaitu tampilan akun yang telah diperbarui pada blockchain). Memahami siklus hidup transaksi dapat menjadi gambaran paling jelas tentang filosofi desain blockchain. Hal ini memberi stakeholder teknis wawasan penting mengenai cara chain dioptimalkan untuk throughput dan keamanan, jaminan determinisme, biaya rekayasa relatif, serta potensi masalah yang mungkin muncul dalam kondisi nyata.

Pada bagian berikutnya, kita akan mengkaji berbagai tahap yang dilalui transaksi, mulai dari pengiriman hingga finalisasi, serta bagaimana proses ini memengaruhi eksekusi pada berbagai lapisan dalam kedua chain tersebut.

Siklus Hidup Transaksi Solana

Blockchain Solana dibangun dengan desain unik yang menggunakan Proof-of-Stake (PoS) sebagai mekanisme konsensus dan Proof-of-History (PoH) sebagai mekanisme pencatat waktu untuk mengurutkan transaksi secara efisien.

Model desain Solana berpusat pada akun, atau dengan kata lain, “semua yang ada di Solana adalah akun”.

Akun digunakan untuk menyimpan data, termasuk state dan binary yang dapat dieksekusi (yaitu kode program). Transaksi berisi instruksi yang mengubah state akun. Node yang berpartisipasi dalam konsensus jaringan dan memproses transaksi disebut validator. Proses pemrosesan transaksi untuk mengubah akun disebut pipelining, sedangkan posisi transaksi pada berbagai titik dalam siklus hidupnya disebut tahap.

Transaksi Solana

Di Solana, transaksi adalah sekumpulan tanda tangan dari pesan terserialisasi yang ditandatangani oleh key pertama dari key akun Message.

Pesan dalam transaksi adalah struktur data yang berisi header, key akun, blockhash terbaru, dan instruksi. Header berisi MessageHeader, yang menjelaskan susunan key akun Message.

Setiap instruksi secara eksplisit menentukan akun yang dapat diakses dan izin yang diperlukan untuk masing-masing akun. Izin ini menunjukkan apakah akun bersifat hanya-baca atau baca-tulis, serta apakah akun tersebut harus menandatangani transaksi yang memuat instruksi itu.

pub struct Message {
pub header: MessageHeader,
pub account_keys: Vec<Pubkey>,
pub recent_blockhash: Hash,
pub instructions: Vec<CompiledInstruction>,
}

Setiap instruksi memuat daftar semua akun yang dapat diaksesnya beserta izin yang diperlukan untuk setiap akun.

Sebuah Message memuat satu daftar datar bersama yang berisi semua akun yang dibutuhkan oleh seluruh instruksi dalam transaksi. Daftar datar ini dibuat saat membangun Message, lalu instruksi dikonversi menjadi sekumpulan CompiledInstructions. CompiledInstructions ini kemudian merujuk akun yang dibutuhkan dari daftar akun bersama tersebut berdasarkan indeks.

Daftar akun bersama diurutkan berdasarkan izin yang diperlukan oleh akun:

• Akun yang dapat ditulis dan merupakan penanda tangan.
• Akun yang hanya-baca dan merupakan penanda tangan.
• Akun yang dapat ditulis dan bukan penanda tangan.
• Akun yang hanya-baca dan bukan penanda tangan.

Dengan urutan ini, field pada MessageHeader menjelaskan izin yang diperlukan oleh setiap akun dalam transaksi.

pub struct MessageHeader { 
pub num_required_signatures: u8,
pub num_readonly_signed_accounts: u8,
pub num_readonly_unsigned_accounts: u8,
}

Ketika beberapa transaksi mengakses akun hanya-baca yang sama, runtime dapat memprosesnya secara paralel dalam satu entri PoH. Transaksi yang mengakses akun baca-tulis yang sama diproses secara berurutan.

Transaksi dikirim ke client melalui Gulf Stream, protokol penerusan transaksi Solana, lalu diproses melalui dua proses pipeline bertahap di validator yang disebut Transaction Processing Unit (TPU) dan Transaction Validation Unit (TVU).

Proses-proses ini bekerja bersama runtime untuk memastikan transaksi yang mengubah state akun berbeda diproses secara paralel, sedangkan transaksi yang mengubah state akun yang sama diproses secara berurutan.

TPU berjalan saat validator berada dalam mode leader (yaitu memproduksi blok), sedangkan TVU berjalan saat validator berada dalam mode validator (yaitu memvalidasi blok). Dalam kedua kasus, perangkat keras pipeline yang digunakan serupa: input jaringan, penulisan ke disk, output jaringan, dan sebagainya. Namun, penggunaan perangkat keras tersebut berbeda. Sederhananya, TPU digunakan untuk membuat entri ledger, sedangkan TVU digunakan untuk memvalidasi entri.

Secara umum, transaksi dikirim melalui client dan diproses oleh Gulf Stream melalui QUIC menuju TPU milik leader. Transaksi melewati pemeriksaan verifikasi, lalu dijadwalkan oleh banking stage untuk dieksekusi. Pembaruan state ditulis kembali ke state dalam memori milik bank. Validator memberikan suara pada blok melalui gossip, dan blok difinalisasi menggunakan Tower BFT, varian PBFT dengan mekanisme lockout berbobot stake.

Gulf Stream

Pada kebanyakan blockchain, transaksi yang dikirim pengguna “diantrekan” dalam mempool (secara harfiah berarti “memory pool”) untuk menunggu diproses oleh jaringan. Transaksi yang telah ditandatangani dapat tetap berada dalam mempool untuk waktu lama, bahkan tanpa batas, sambil menunggu eksekusi jika kondisi jaringan tidak optimal atau kondisi eksekusi tidak terpenuhi. Akibatnya, transaksi tersebut mungkin tidak pernah disertakan dalam blok mana pun.

Solana meniadakan kebutuhan akan mempool global dengan mengandalkan jadwal leader deterministik yang dipengaruhi algoritma berbobot stake, yaitu Stake-Weighted Quality of Service (SWQoS), untuk memprioritaskan pesan transaksi yang dirutekan melalui validator dengan stake.

Karena jadwal leader telah diketahui sebelumnya oleh semua node aktif, pesan transaksi dapat didistribusikan secara efisien. Dengan demikian, leader berikutnya sudah memiliki cukup transaksi untuk diproses sebelum jadwal produksi bloknya tiba. Mekanisme ini memungkinkan validator melakukan prapemrosesan transaksi dengan memverifikasi tanda tangan serta menghapus transaksi duplikat atau tidak valid sebelumnya.

Keunggulan lain Gulf Stream terlihat jika dibandingkan dengan chain tradisional yang menggunakan mempool. Pada chain tersebut, produsen blok juga harus mentransmisikan ulang transaksi yang sama dalam sebuah blok, sehingga setiap transaksi disebarkan setidaknya dua kali melalui jaringan. Solana tidak perlu membebani gossip untuk menyinkronkan transaksi tertunda, dan transaksi tidak perlu bersaing memperebutkan ruang blok melalui lelang gas. Sebaliknya, transaksi didistribusikan berdasarkan penjadwalan.

Transaction Processing Unit (TPU)

TPU adalah logika inti validator yang bertanggung jawab atas produksi blok. Transaksi diambil dari client dan diteruskan dalam paket data melalui komponen bernama QUIC streamer, yang mengalokasikan memori paket dan membaca data dari endpoint QUIC (dikenal sebagai “Fetch Stage”). Setiap stream mengirimkan paket dalam batas transmisi QUIC yang diidentifikasi oleh client (alamat IP, pubkey node) dan server.

Paket kemudian dikirim ke Sigverify Stage. Di sini, paket dideduplikasi menggunakan mekanisme load-shedding khusus untuk membuang paket berlebih. Paket yang telah dideduplikasi kemudian difilter untuk menghapus paket dengan tanda tangan tidak valid, lalu diteruskan ke banking stage.

Banking stage adalah komponen utama dalam eksekusi runtime Solana. Tahap ini menjadwalkan paket masuk, memfilternya lebih lanjut untuk mendeteksi konflik, dan mengevaluasi kelayakannya untuk diproses, ditahan, atau diteruskan secara batch. Jika mendeteksi bahwa node tersebut adalah produsen blok, tahap ini memproses paket yang ditahan dan baru diterima dengan komponen Bank. Komponen bank adalah representasi dalam memori dari keseluruhan state ledger pada slot tertentu.

Di dalam banking stage dan komponen scheduler, transaksi dilacak dalam dua state:

• State belum diproses, ketika transaksi tersedia untuk dijadwalkan
• State tertunda, ketika transaksi sedang dijadwalkan atau diproses

Setelah transaksi selesai diproses, transaksi tersebut mungkin dapat dicoba ulang. Jika dapat dicoba ulang, transaksi dikembalikan ke state belum diproses. Jika tidak, state tersebut dihapus. Transaksi valid yang telah diproses dibentuk menjadi “Entry” melalui tick PoH, digabungkan ke dalam blok, lalu disiarkan sebagai shred kepada peer jaringan melalui Turbine, protokol propagasi blok Solana. Turbine menghasilkan erasure code untuk “meregenerasi” paket data yang hilang sebelum mengirim paket ke peer jaringan yang sesuai pada Broadcast Stage.

Transaction Validation Unit (TVU)

TVU adalah logika dalam node validator non-leader yang bertanggung jawab untuk memvalidasi dan menyebarkan blok. Di TVU, paket data diproses melalui tahap-tahap multithread sebelum difinalisasi. Tahap ini mencakup pengambilan shred, verifikasi tanda tangan, transmisi ulang, dan replay.

Pada Shred Fetch Stage dan tahap verifikasi tanda tangan leader untuk shred, non-leader menerima shred dari node lain melalui UDP dan melakukan verifikasi tanda tangan secara batch. Shred yang valid ditransmisikan ulang ke node peer pada Retransmit Stage, dan setiap transaksi diputar ulang secara berurutan pada Replay Stage.

Pada replay stage, runtime dipanggil untuk mengeksekusi ulang seluruh transaksi secara deterministik. Ini memastikan semua perubahan state, atribut program, dan hash bank sama persis dengan output leader.

Jika blok dinilai valid, validator menandatangani transaksi suara dan mengirimkan suara tersebut kepada leader agar disertakan dalam blok berikutnya.

Runtime

Runtime adalah pemroses transaksi konkuren Solana yang digunakan bersama oleh TPU dan TVU. Transaksi menentukan dependensi datanya (yaitu akun yang ingin dibaca dan/atau ditulis) sejak awal untuk memungkinkan eksekusi memori dinamis secara eksplisit. Hasilnya, pembacaan state dapat diisolasi dengan baik dari eksekusi program, sehingga runtime dapat mengatur akses konkuren.

Runtime Solana menggunakan engine eksekusi bernama Sealevel untuk memastikan transaksi yang mengakses akun hanya-baca dieksekusi secara paralel. Sebaliknya, transaksi yang mengakses akun dapat-ditulis yang saling tumpang tindih diserialisasi dan dieksekusi secara berurutan.

Di dalam runtime, transaksi dieksekusi secara atomik. Semua instruksi dalam transaksi harus berhasil dieksekusi agar transaksi tersebut dapat di-commit ke bank. Jika tidak, transaksi akan gagal.

Runtime berinteraksi dengan program tertentu melalui entrypoint dengan antarmuka yang terdefinisi jelas. Entrypoint ini hanyalah fungsi Rust yang diekspos secara konsisten oleh semua program on-chain sebagai titik awal eksekusi dan berfungsi sebagai antarmuka bagi runtime Solana dan program. Engine eksekusinya memetakan public key ke akun dan merutekannya ke entrypoint ini. Namun, engine tersebut memberlakukan beberapa batasan penting untuk mengarahkan logika eksekusinya, sebagaimana ditentukan oleh arsitektur instruction set mesin virtual:

• Hanya program pemilik yang boleh mengubah isi akun.
• Total saldo seluruh akun sama sebelum dan sesudah eksekusi transaksi, tetapi ini hanya berlaku secara agregat. Lamport tidak dipertahankan untuk transfer dan burn oleh sistem.
• Setelah transaksi dieksekusi, saldo akun hanya-baca harus sama dengan saldo sebelum transaksi.
• Semua instruksi dalam transaksi dieksekusi secara atomik. Jika satu instruksi gagal, semua perubahan akun dibatalkan.

Pipeline TPU dan TVU mengikuti jalur yang sedikit berbeda saat berinteraksi dengan runtime. Runtime TPU memastikan “entry” dicatat (melalui tick PoH) sebelum memori di-commit, sedangkan runtime TVU memastikan “entry” diverifikasi sebelum runtime memproses transaksi apa pun.

Konsensus

Konsensus adalah salah satu mekanisme paling mendasar dalam sistem komputasi terdistribusi yang kompleks. Dalam siklus hidup transaksi Solana, konsensus berlangsung setelah blok dieksekusi dan divalidasi oleh TVU, tetapi sebelum difinalisasi. Gagasan inti konsensus adalah kesepakatan seragam yang memastikan peserta jaringan menyetujui hasil yang sama dan, setelah memutuskan, tidak dapat mengubah keputusan tersebut.

Secara formal, mekanisme konsensus yang toleran terhadap kegagalan harus memenuhi properti berikut:

• Kesepakatan seragam: Tidak ada dua node yang mengambil keputusan berbeda.
• Integritas: Tidak ada node yang mengambil keputusan lebih dari sekali.
• Validitas: Jika sebuah node memutuskan suatu nilai, nilai tersebut telah diusulkan oleh node lain.
• Terminasi: Setiap node yang tidak mengalami crash pada akhirnya memutuskan suatu nilai.

Secara umum, tujuan konsensus adalah membuat node menyepakati sesuatu. Di Solana, ada beberapa situasi yang mengharuskan node mencapai kesepakatan. Hal ini terutama terjadi dalam tiga skenario:

Rotasi Leader

Semua node harus menyepakati siapa yang menjadi leader karena gangguan jaringan dapat mengacaukan komunikasi dan menyebabkan skenario split-brain, yaitu beberapa node secara keliru menganggap dirinya sebagai leader pada saat yang sama.

Jadwal leader dibuat menggunakan seed yang telah ditentukan dengan algoritma berikut: tinggi tick PoH (yaitu counter yang terus meningkat secara monoton) digunakan secara berkala sebagai seed untuk algoritma pseudoacak yang stabil.

Pada ketinggian tersebut, bank mengambil sampel semua akun dengan stake dan identitas leader yang telah memberikan suara dalam jumlah tick yang dikonfigurasi cluster. Sampel ini disebut active set dan diurutkan berdasarkan bobot stake. Seed acak kemudian digunakan untuk memilih node berdasarkan bobot stake guna membuat urutan berbobot stake, yang mulai berlaku setelah jumlah tick yang dikonfigurasi cluster.

Sinkronisasi

Tanpa timestamp yang andal, validator tidak dapat menentukan urutan blok yang masuk. Solana menggunakan mekanisme bernama Proof-of-History sebagai clock kriptografis untuk mengurutkan transaksi sebelum menjalani konsensus. Menurut dokumentasi Anza tentang sinkronisasi:

“Node leader memberi "timestamp" pada blok dengan bukti kriptografis bahwa suatu durasi telah berlalu sejak bukti terakhir. Semua data yang dimasukkan ke hash dalam bukti dipastikan telah terjadi sebelum bukti dibuat. Node kemudian membagikan blok baru kepada node validator, yang dapat memverifikasi bukti tersebut. Blok dapat tiba di validator dalam urutan apa pun atau bahkan diputar ulang bertahun-tahun kemudian. Dengan jaminan sinkronisasi yang andal ini, Solana dapat membagi blok menjadi batch transaksi yang lebih kecil, yang disebut entry. Entry kemudian dialirkan kepada validator secara real-time, sebelum adanya konsep konsensus blok”.

Penting untuk diingat bahwa meskipun Proof-of-History bukan mekanisme konsensus, mekanisme ini berdampak signifikan terhadap performa konsensus Proof-of-Stake Solana.

Commit Atomik

Proses penting lain yang harus disepakati node adalah commit atomik. Dalam sistem berperforma tinggi seperti Solana, suatu transaksi dapat gagal pada sebagian node dan berhasil pada node lainnya.

Untuk mencegah eksekusi parsial, Solana memastikan atomisitas di dalam runtime sesuai prinsip ACID, sekaligus memastikan semua node menyepakati hasil transaksi: semuanya melakukan rollback (jika terjadi masalah) atau commit (jika tidak ada masalah).

Commitment di Solana mengukur finalitas blok (slot) berdasarkan jumlah validator yang memberikan suara dan kedalaman suara mereka dalam mekanisme lockout Tower BFT. Ini mencerminkan seberapa kuat jaringan telah menyepakati slot tertentu berdasarkan suara validator. Setiap validator memberikan suara pada slot (khususnya tinggi blok) dan berkomitmen untuk tidak memberikan suara pada fork yang berkonflik. Lockout dalam Tower BFT memastikan mekanisme ini diterapkan.

Solana memiliki tiga status commitment: processed, confirmed, dan finalized. Sebuah blok dinyatakan confirmed ketika supermayoritas validator dengan stake (≥66%) memberikan suara untuknya, dan dinyatakan finalized ketika setidaknya 32 blok confirmed dibangun di atasnya.

Sebagai konsekuensi langsung dari eksekusi paralel optimistis dan jadwal leader asinkron, Solana mengikuti model “eksekusi dahulu, berikan suara kemudian”: protokol tidak menunggu semua validator menyepakati blok yang baru dibuat sebelum memproduksi blok berikutnya. Hal ini juga dapat menyebabkan fork (yaitu skenario ketika dua atau lebih chain yang bersaing ada secara bersamaan). Setelah suatu slot menjadi finalized, semua fork pesaing ditinggalkan dan fork tersebut menjadi chain kanonis.

Alpenglow

Pada saat artikel ini ditulis, Solana menggunakan Tower BFT dan ledger PoH untuk memastikan jaringan mencapai state konsensus meskipun sebagian peserta mengalami kegagalan.

Baru-baru ini, tim riset Anza mengusulkan desain baru untuk protokol konsensus yang lebih sederhana dan berperforma lebih tinggi bernama Alpenglow. Alpenglow bertujuan merombak komponen lama dalam desain konsensus saat ini, termasuk Proof of History, Tower BFT, dan penggunaan gossip untuk propagasi suara.

Pada intinya, Alpenglow menggunakan Votor dan Rotor untuk mempercepat konsensus Solana:

Votor adalah mekanisme voting dua tingkat yang dirancang untuk mencapai finalitas blok dalam satu putaran jika 80% stake responsif, dan dalam dua putaran jika minimal 60% stake responsif.

Rotor menyempurnakan protokol turbine yang ada dengan menggunakan satu lapisan node relay untuk menangani penyebaran shred. Rotor juga memanfaatkan bandwidth node peserta secara proporsional terhadap stake mereka untuk mengurangi hop dan mengoptimalkan throughput Solana. 

Sui

Berbeda dengan Solana yang menggunakan model berpusat pada akun, blockchain Sui menggunakan model data berorientasi objek yang merepresentasikan data state sebagai objek dengan identifier, properti, dan metode unik.

Di Sui, smart contract juga merupakan objek yang disebut package Sui Move. Package ini memiliki identifier unik dan memanipulasi objek. Package Sui Move tersebut terdiri atas sekumpulan modul bytecode Move Sui. Setiap modul memiliki nama yang unik, dan kombinasi ID on-chain package dengan nama modul akan mengidentifikasi modul tersebut secara unik.

Meskipun detail rumit desain objek dan metadata berada di luar cakupan artikel ini, penting untuk diingat bahwa setiap objek memiliki pemilik yang menentukan bagaimana objek tersebut dapat digunakan dalam transaksi.

Objek dapat memiliki model kepemilikan berikut:

• Objek Milik Alamat: Objek milik alamat dimiliki oleh alamat 32-byte tertentu, baik berupa alamat akun maupun ID objek. Objek ini hanya dapat diakses oleh pemiliknya.
• Objek Imutabel: Objek imutabel tidak dapat diubah, ditransfer, atau dihapus. Objek ini tidak memiliki pemilik dan dapat diakses secara global oleh siapa pun.
• Objek Bersama: Objek bersama adalah objek yang dibagikan dan dapat diakses oleh semua orang.
• Objek Terbungkus: Model ini melibatkan pembungkusan suatu objek di dalam objek lain. Objek terbungkus tidak bersifat independen dan hanya dapat diakses melalui objek pembungkus.

Transaksi Sui

Di Sui, transaksi terdiri atas sekelompok perintah yang dijalankan pada input untuk menentukan hasil transaksi. Kelompok perintah ini disebut programmable transaction blocks (PTB) dan mendefinisikan semua transaksi pengguna di Sui. PTB memungkinkan pengguna memanggil beberapa fungsi Move, mengelola objek, serta mengelola “coin” dalam satu transaksi tanpa harus menerbitkan package Move baru.

Struktur PTB didefinisikan sebagai berikut:

{
    inputs: [Input],
    commands: [Command],
}

inputs adalah vektor argumen yang berupa objek atau nilai murni. Objek tersebut dapat dimiliki pengirim, dibagikan, atau bersifat imutabel. Field commands adalah vektor instruksi transaksi tingkat tinggi.

Selama eksekusi PTB, vektor input diisi dengan objek input atau byte nilai murni. Perintah transaksi kemudian dieksekusi secara berurutan, dan hasilnya disimpan dalam vektor hasil, yaitu array nilai tempat setiap nilai dapat berupa tipe Move arbitrer yang spesifik untuk setiap perintah. Berbeda dengan input, nilai tersebut tidak dibatasi pada objek atau nilai murni. Terakhir, efek transaksi diterapkan secara atomik. 

Kita tidak akan membahas bagian internal PTB Sui karena topik tersebut juga cukup rumit. Namun, perlu diperhatikan bahwa pada awal eksekusi, runtime PTB mengambil objek input yang telah dimuat dan memasukkannya ke array input. Objek tersebut telah diverifikasi oleh jaringan dengan memeriksa aturan seperti keberadaan dan kepemilikan yang valid. Byte nilai murni juga dimuat ke dalam array, tetapi baru divalidasi ketika digunakan.

Pada tahap ini, efek terhadap gas coin sangatlah penting. Di sini, anggaran gas maksimum ditarik dari gas coin. Anggaran gas maksimum biasanya ditentukan oleh pengirim saat transaksi dikirim dan menunjukkan jumlah maksimum gas yang dapat dikonsumsi transaksi tersebut. Gas yang tidak digunakan dikembalikan ke gas coin pada akhir eksekusi, meskipun pemilik coin telah berubah. Setiap perintah transaksi kemudian dieksekusi secara berurutan.

Setelah dikirim, Full node mengesahkan semua metadata yang diberikan dengan mengirimkan transaksi ke node validator (tahap Sertifikasi). Node validator melakukan semua pemeriksaan validitas yang diperlukan terhadap transaksi dan menandatanganinya untuk mengonfirmasi validitas jika seluruh pemeriksaan berhasil. Agar dianggap valid oleh node validator, transaksi harus:

• Memiliki tanda tangan pengguna yang valid.
• Memastikan inisiator transaksi memiliki akses ke semua objek input milik sendiri yang digunakan transaksi.
• Memastikan objek input bersama yang digunakan transaksi benar-benar ada.
• Memuat gas setidaknya sebanyak yang ditentukan dalam anggaran gas transaksi.

Jika semua pemeriksaan berhasil, validator mencoba mengunci semua objek inputs milik sendiri pada “transaction digest” tertentu untuk memastikan setiap input milik sendiri hanya dapat digunakan satu kali pada saat yang sama.

Jika proses penguncian berhasil, validator menandatangani transaksi dan mengembalikan tanda tangan tersebut ke Full node.

Full node Sui pada dasarnya adalah tampilan hanya-baca atas state jaringan. Berbeda dengan node validator, full node tidak dapat menandatangani transaksi, meskipun dapat memvalidasi integritas chain dengan mengeksekusi ulang transaksi yang sebelumnya di-commit oleh kuorum validator. Full node tidak hanya mengumpulkan satu tanda tangan validator, tetapi sebanyak mungkin tanda tangan validator secara paralel. Namun, hanya supermayoritas (⅔+ dari stake) yang diperlukan untuk membentuk sertifikat transaksi.

Eksekusi dan Checkpoint

Setelah transaksi mendapatkan sertifikat, transaksi dikirim ke komite validator (yaitu sekumpulan validator independen yang ditetapkan untuk setiap epoch) untuk dieksekusi. Validator tidak perlu memverifikasi ulang transaksi; validator hanya perlu memverifikasi tanda tangan pada sertifikat. Jika tanda tangan pada sertifikat valid, validator dapat memastikan bahwa transaksi tersebut valid.

Selama eksekusi, transaksi dibagi menjadi dua kategori: transaksi objek milik sendiri dan transaksi objek bersama:

Transaksi Objek Milik Sendiri

Transaksi Objek Milik Sendiri tidak mengakses objek input bersama dan langsung dieksekusi. Transaksi ini juga dikenal sebagai transaksi fastpath, yaitu dieksekusi setelah validasi lalu di-commit ke chain kanonis. Transaksi ini tidak “melewati” konsensus (transaksi fastpath pada akhirnya melewati konsensus, tetapi hanya untuk menghasilkan urutan kanonis agar dapat disertakan dalam checkpoint). Secara teknis, hal ini dimungkinkan karena tidak ada risiko penulisan yang berkonflik; hanya pemilik yang dapat mengubah objek. 

Transaksi Objek Bersama

Transaksi objek bersama mengakses objek bersama sehingga harus diurutkan melalui konsensus relatif terhadap transaksi lain yang menggunakan dan mengeksekusi objek bersama yang sama. Transaksi ini juga dikenal sebagai transaksi slowpath. Transaksi harus melewati proses konsensus penuh untuk memastikan konsistensi karena objek yang terlibat dapat diakses dan diubah oleh beberapa pengguna. 

Sebelumnya, mempool Sui, Narwhal, menghindari kemacetan umum dengan memisahkan penyebaran transaksi dari pengurutan. Narwhal menyimpan transaksi bersertifikat dan bertanda tangan dalam Directed Acyclic Graph (DAG) tanpa mengurutkannya sendiri. Bullshark kemudian menyediakan urutan konsensus.

Untuk semakin meningkatkan performa dan ketahanan, protokol HammerHead diperkenalkan sebagai peningkatan atas Bullshark dengan menerapkan pemilihan leader dinamis berbasis skor. Hal ini secara signifikan mengurangi latensi dan meningkatkan throughput, khususnya ketika terdapat leader yang bermasalah atau mengalami crash.

Dengan melanjutkan kemajuan ini, Mysticeti kini menggantikan Narwhal dan Bullshark, serta menyatukan penyebaran dan pengurutan transaksi dalam satu protokol. Mysticeti menyusun transaksi dalam urutan total, sehingga semakin menyederhanakan proses dan mencapai latensi lebih rendah serta throughput lebih tinggi. Selain itu, berkat model kepemilikan berpusat pada objek milik Sui, sebagian besar transaksi tetap independen dan tidak perlu bersaing memperebutkan slot pengurutan global.

Setelah transaksi dieksekusi, validator menandatangani efek transaksi dan mengembalikannya ke full node. Efek transaksi pada dasarnya adalah daftar semua tindakan yang dilakukan transaksi, seperti seluruh objek yang diubah, gas yang digunakan, dan status eksekusi transaksi.

Tanda tangan efek membentuk kumpulan sertifikat efek yang dihimpun full node dari supermayoritas validator, sehingga menjamin bahwa transaksi telah difinalisasi.

Saat transaksi disertakan dalam checkpoint, yang menunjukkan tahap terakhir dalam siklus hidupnya, perubahan state yang dihasilkan transaksi tersebut sudah difinalisasi dan diterapkan pada jaringan.

Untuk transaksi yang hanya melibatkan objek input milik sendiri, validator mengeksekusi dan memfinalisasi transaksi sebelum mengirimkannya ke lapisan konsensus untuk diurutkan.

Sebaliknya, transaksi yang melibatkan objek input bersama dikirim ke konsensus untuk diurutkan sebelum eksekusi dan tidak dikirim ulang untuk disertakan dalam checkpoint.

Validator mengumpulkan potongan transaksi yang lengkap dan terurut secara kausal dari lapisan konsensus, lalu menyusun checkpoint yang berisi daftar transaction digest dan digest terkait untuk efek setiap transaksi. Dengan demikian, checkpoint berfungsi sebagai catatan imutabel atas seluruh transisi state yang telah difinalisasi dalam jaringan.

Finalitas

Transaksi di Sui mencapai finalitas segera setelah supermayoritas (2𝑓 + 1) validator menerima dan ikut menandatangani sertifikat transaksi, bahkan sebelum sertifikat tersebut diurutkan oleh konsensus atau dieksekusi. Pada titik ini, tidak ada transaksi berkonflik yang dapat terjadi dan transaksi tidak dapat dibatalkan. Untuk transaksi yang hanya melibatkan objek milik sendiri, hasil eksekusi langsung diketahui saat finalitas tercapai. Untuk transaksi objek bersama, hasilnya baru ditentukan setelah sertifikat diurutkan oleh konsensus. Finalitas transaksi dicapai dalam dua perjalanan pulang-pergi jaringan.

Settlement terjadi ketika transaksi dieksekusi oleh supermayoritas validator dan sertifikat efek terbentuk. Untuk transaksi objek milik sendiri, eksekusi ini terjadi seketika tanpa menunggu konsensus. Untuk transaksi objek bersama, eksekusi dan settlement terjadi tepat setelah sertifikat diurutkan oleh konsensus. Dalam kedua kasus, settlement tidak tertunda oleh pembuatan checkpoint, sehingga latensinya lebih rendah daripada proses checkpoint.

Meskipun sertifikat transaksi merupakan indikasi kuat finalitas, hanya sertifikat efek atau penyertaan dalam checkpoint bersertifikat yang memberikan jaminan mutlak. Keduanya mewajibkan supermayoritas validator untuk mengeksekusi dan melakukan commit terhadap efek transaksi.

Secara umum, siklus hidup transaksi Sui memanfaatkan model berpusat pada objek untuk memaksimalkan paralelisme dan efisiensi. Ketika transaksi dikirim untuk sertifikasi, validator mencoba mengunci versi tertentu dari objek input yang dirujuknya.

Untuk objek milik sendiri, lock ini diperoleh seketika selama sertifikasi guna memastikan akses eksklusif dan mencegah double-spending. Untuk objek bersama, lock baru ditetapkan setelah transaksi diurutkan melalui protokol konsensus Sui.

Setelah semua lock yang diperlukan diperoleh, transaksi dijadwalkan untuk dieksekusi. Desain ini memungkinkan transaksi yang beroperasi pada kumpulan objek terpisah dieksekusi secara independen dan paralel, sehingga secara signifikan mengurangi perebutan akses dan kemacetan pada bagian state yang tidak berkaitan.

Setelah eksekusi berhasil, validator menandatangani efek transaksi. Ketika tanda tangan supermayoritas telah terkumpul, sertifikat efek terbentuk. Sertifikat ini menjadi jaminan finalitas settlement dan menunjukkan bahwa transaksi kini tidak dapat dibatalkan serta efeknya bersifat permanen.

Checkpoint bukan bagian dari jalur kritis untuk eksekusi atau finalitas transaksi. Sebaliknya, checkpoint dibuat setelah eksekusi untuk menyediakan urutan transaksi kanonis dan memfasilitasi sinkronisasi state bagi node yang tidak terlibat langsung dalam eksekusi.

Model objek Sui memungkinkan pelacakan dependensi yang akurat pada tingkat objek, sehingga tidak memerlukan sinkronisasi state global. Arsitektur ini mendukung eksekusi terdistribusi yang skalabel pada perangkat keras komoditas, alih-alih mengandalkan peningkatan performa perangkat keras untuk mencapai throughput yang lebih tinggi.

Wawasan tentang Eksekusi, Skalabilitas, dan Kompromi Desain

Seperti disebutkan sebelumnya, memahami siklus hidup transaksi dapat menjadi gambaran paling jelas tentang filosofi desain blockchain. Perbedaan siklus hidup transaksi Solana dan Sui mengungkap filosofi model eksekusi yang mendalam dalam tiga aspek penting: efisiensi eksekusi, batas skalabilitas, dan kompromi desain.

Eksekusi

Sebagai chain yang berpusat pada akun, Solana mendeteksi konflik akun secara dinamis melalui penguncian akun selama Banking Stage. Ini memastikan transaksi yang tidak mengubah akun yang sama diproses secara paralel, sedangkan transaksi yang berkonflik diproses secara berurutan.

Meskipun mekanisme deteksi akun semacam ini dapat menambah biaya runtime dalam situasi DeFi yang berat, khususnya ketika program perlu mengeksekusi logika dari program lain (mekanisme yang disebut Cross-Program Invocation), engine eksekusi Solana tetap mampu mencapai paralelisme berskala besar berkat deteksi konflik dinamis. Dengan demikian, chain dapat mengeksekusi transaksi hampir seketika dengan biaya yang sangat rendah.

Di sisi lain, Sui tidak perlu mengkhawatirkan transaksi yang berkonflik karena paralelismenya disimpulkan pada waktu kompilasi berkat model kepemilikan yang berpusat pada objek. Model objek bersama dan objek milik sendiri memungkinkan konflik disimpulkan secara statis dan mencapai biaya runtime yang nyaris nol untuk transaksi objek milik sendiri.

Batas Skalabilitas

Dalam hal penskalaan, Sui mencapai skalabilitas horizontal dan dapat diskalakan secara linear bersama partisi objek dengan memproses transaksi objek milik sendiri tanpa konsensus global. Hal ini memungkinkan finalitas nyaris seketika di bawah satu detik dan throughput yang hanya dibatasi oleh perangkat keras yang tersedia. Transaksi objek bersama memerlukan konsensus, tetapi dengan upgrade Mysticeti, transaksi tersebut kini juga mencapai finalitas di bawah satu detik dan throughput tinggi. Arsitektur Sui memungkinkan penyebaran blok dan eksekusi diskalakan secara elastis dengan menambahkan lebih banyak sumber daya, sehingga sistem mampu menangani peningkatan beban kerja secara efisien. Namun, jalur konsensus tidak seterbuka fast path untuk objek milik sendiri.

Karena menggunakan pendekatan satu leader dan fanout eksekusi yang dibatasi oleh perebutan akun, Solana tampaknya mencapai batas penskalaan horizontal akibat model state global dengan satu shard dan penyerapan transaksi per slot yang berpusat pada leader. Namun, Solana melakukan optimasi agresif di dalam batas ini melalui pipelining yang terdefinisi jelas dan dilengkapi PoH. Transaksi dapat diurutkan secara akurat, diproses dalam waktu kurang dari 400 ms, dan mencapai konfirmasi optimistis dalam waktu kurang dari satu detik. Dalam penskalaan vertikal, Solana dapat berkembang pesat seiring peningkatan perangkat keras validator, terutama core CPU dan RAM, karena hal ini sangat sesuai dengan desain dasarnya.

Penting untuk menegaskan bahwa Solana memilih penskalaan vertikal dibandingkan horizontal dan mencapai batas atas karena kompromi desain, bukan kegagalan arsitektur. Beberapa pendekatan horizontal, seperti pasar biaya lokal, subnet virtual, dan minimalisasi state melalui CMT, saat ini sedang dikembangkan.

Kompromi Desain

Solana menjamin determinisme melalui batasan runtime yang ketat, isolasi akun, dan penjadwalan leader deterministik. Resolusi perebutan akun yang dinamis dan pipelining yang terdefinisi jelas mendukung interaksi mendalam antarprogram, sehingga menghasilkan komposabilitas yang kuat.

Sui memberikan jaminan determinisme melalui jalur eksekusi bawaan yang ditentukan oleh analisis kepemilikan objek. Pada saat yang sama, model berpusat pada objek milik Sui memungkinkan komposabilitas melalui objek bersama dan programmable transaction blocks (PTB), sehingga mendukung interaksi kompleks dan operasi atomik di berbagai kontrak dan pengguna. Hal ini dimungkinkan karena pemilik suatu objek dapat berupa objek lain, yang memungkinkan interoperabilitas tingkat objek dan penyusunan objek menjadi pohon kepemilikan. Struktur semacam ini sangat berguna ketika objek sering digunakan bersama atau ketika pencarian runtime diperlukan untuk menentukan objek yang akan dioperasikan selama eksekusi.

Ringkasan

Mekanisme pemrosesan transaksi dari pengiriman hingga finalitas mendasari performa tinggi Solana dan Sui yang luar biasa. Dengan mengkaji siklus hidup transaksi, kita dapat memahami pipeline yang dirancang secara cermat untuk memastikan latensi rendah dan throughput tinggi pada kedua chain.

Solana dirancang dengan model berpusat pada akun, dan transaksi melewati serangkaian proses serta pipeline multithread untuk memastikan validitasnya. Transaksi dikirim kepada leader, yang menjalankan pipeline TPU untuk memastikan transaksi diverifikasi dan dijadwalkan dengan tepat: secara paralel jika tidak berkonflik dan secara berurutan jika berkonflik. Saat validator tidak memproduksi blok, validator menjalankan pipeline TVU untuk mereplikasi dan memvalidasi transaksi. TPU dan TVU sama-sama menggunakan runtime. Karena runtime dapat menyimpulkan akun yang tidak tumpang tindih secara deterministik sejak awal dan mengeksekusi transaksi yang tidak berkonflik secara paralel, Solana dapat memproses ribuan transaksi dalam waktu sangat singkat. Hal ini menjadikan Solana ideal untuk kasus penggunaan nyata seperti perdagangan frekuensi tinggi, DeFi dengan komposabilitas mendalam, dApp dengan infrastruktur berat, dan dApp konsumen berlatensi rendah.

Di sisi lain, Sui menggunakan model berpusat pada objek, tempat setiap objek dilacak oleh identifier unik. Dengan menyimpulkan kepemilikan objek, Sui dapat menentukan secara statis apakah transaksi dapat dieksekusi secara paralel jika menyentuh kumpulan objek yang terpisah. Melalui model jalur eksekusi ganda—yaitu memisahkan transaksi menjadi transaksi objek milik sendiri dan transaksi objek bersama, serta menggunakan checkpoint bertanda tangan agar Full node tetap sinkron—Sui dapat memproses transaksi ringan tanpa membebani lapisan konsensus, sembari tetap mencapai finalitas yang andal dan cepat serta sinkronisasi yang efisien untuk node baru. Hal ini memungkinkan penskalaan horizontal seiring peningkatan beban dan sangat berguna untuk aplikasi dengan interaksi objek berskala besar, seperti DeFi, game, bursa berpusat pada aset, dan aset yang dapat diprogram.

Referensi

• Dokumentasi Resmi Solana
• Dokumentasi Resmi Anza
• Dokumentasi Resmi Sui
• Gulf Stream: Protokol Penerusan Transaksi Solana Tanpa Mempool
• Sealevel — Pemrosesan Paralel Ribuan Smart Contract
• Cross-Program Invocation dan PDA—kombinasi dua mekanisme canggih di Anchor
• Narwhal dan Tusk: Mempool Berbasis DAG dan Konsensus BFT yang Efisien
• Memperluas Eksekusi Sui dengan Pilotfish
• SUI vs Solana - TrustWallet
• Tower BFT: Implementasi PBFT Berperforma Tinggi dari Solana
• David J DeWitt dan Jim N Gray: “Sistem database paralel: Masa depan sistem database berperforma tinggi,” Communications of the ACM, volume 35, nomor 6, halaman 85–98, Juni 1992. doi:10.1145/129888.129894
• Jim N Gray dan Leslie Lamport: “Konsensus pada Commit Transaksi,” ACM Transactions on Database Systems (TODS), volume 31, nomor 1, halaman 133–160, Maret 2006. doi:10.1145/1132863.1132867
• Leslie Lamport: “Waktu, Clock, dan Pengurutan Peristiwa dalam Sistem Terdistribusi,” Communications of the ACM, volume 21, nomor 7, halaman 558–565, Juli 1978.
• Michael J Fischer, Nancy Lynch, dan Michael S Paterson: “Kemustahilan Konsensus Terdistribusi dengan Satu Proses Bermasalah,” Journal of the ACM, volume 32, nomor 2, halaman 374–382, April 1985. doi:10.1145/3149.214121
• Kushal Babel, Andrey Chursin, George Danezis, Anastasios Kichidis, Lefteris Kokoris-Kogias, Arun Koshy, Alberto Sonnino, Mingwei Tian: “MYSTICETI: Mencapai Batas Latensi dengan DAG Tanpa Sertifikasi”, [cs.DC], Juli 2024.
• Giorgos Tsimos, Anastasios Kichidis, Alberto Sonnino, Lefteris Kokoris-Kogias: “HammerHead: Reputasi Leader untuk Penjadwalan Dinamis”, [cs.CR], September 2023.