Pipelining Transaksi Solana: Pipeline 4-Tahap TPU

Panduan teknis ini menjelaskan pipeline 4-tahap TPU untuk pipelining transaksi Solana dan bagaimana hal itu mendukung pemrosesan paralel.

Solana menghasilkan blok baru kira-kira setiap 400 milidetik. Kebanyakan blockchain memproses transaksi satu per satu, menunggu masing-masing selesai sebelum memulai yang berikutnya. Solana tidak demikian.

Pipelining transaksi Solana adalah metode yang digunakan oleh Transaction Processing Unit Solana untuk memindahkan transaksi masuk melalui empat tahap berurutan: Fetch, SigVerify, Banking, dan Writing. Beberapa batch transaksi melewati tahap-tahap ini secara bersamaan, sehingga saat satu batch sedang ditulis ke buku besar, batch berikutnya sudah divalidasi dan batch ketiga sudah diambil. Pemrosesan paralel inilah yang memungkinkan Solana (SOL), aset asli dari blockchain Solana (Buku Besar Terdistribusi tempat semua transaksi dicatat), untuk mencapai angka throughput yang jauh melampaui kebanyakan jaringan Layer-1.

Solana dibangun oleh Anatoly Yakovenko, mantan insinyur Qualcomm yang menerbitkan Whitepaper Proof of History pada tahun 2017, memperkenalkan mekanisme jam kriptografi yang memungkinkan kecepatan pipeline tersebut. Solana Labs, organisasi berbasis di San Francisco yang mengembangkan protokol tersebut, mengimplementasikan pipelining sebagai fitur inti dari klien validator. Hasilnya adalah jaringan yang telah menjadi Platform terkemuka untuk aplikasi keuangan terdesentralisasi (DeFi), termasuk bursa terdesentralisasi, protokol peminjaman, dan pasar Derivatif On-Chain yang memerlukan finalitas transaksi di bawah satu detik.

Trilema Blockchain yang banyak dikutip menyatakan bahwa blockchain hanya dapat memprioritaskan dua dari tiga properti: skalabilitas, keamanan, dan desentralisasi. Pipelining transaksi Solana adalah jawaban arsitekturalnya terhadap dimensi skalabilitas. Artikel ini membahas apa itu pipelining, bagaimana empat tahap TPU bekerja secara mekanis, bagaimana Proof of History memungkinkan pipeline tersebut, bagaimana Gulf Stream dan Turbine membungkus Input dan output pipeline, bagaimana Sealevel memperluas prinsip pipelining ke eksekusi Kontrak Pintar, bagaimana perbandingan Solana dengan Ethereum secara arsitektural, dan di mana letak trade-off serta batas pipeline yang terdokumentasi.

Daftar Isi

1. Apa Itu Pipelining Transaksi Solana? (Dan Mengapa Hal Itu Penting bagi SOL)
2. Cara Kerja Pipeline TPU Solana: Penjelasan Empat Tahap
3. Proof of History: Jam Kriptografi yang Memungkinkan Pipelining
4. Gulf Stream: Bagaimana Transaksi Memasuki Pipeline Sebelum Siap
5. Analogi Pipeline CPU: Mengapa Arsitektur Solana Harus Terasa Akrab bagi Insinyur
6. Turbine: Bagaimana Output Pipeline Mencapai Jaringan
7. Sealevel: Pipelining yang Diperluas ke Eksekusi Kontrak Pintar
8. Solana vs. Ethereum: Perbandingan Arsitektur Pipeline
9. Keterbatasan, Kemacetan, dan Trade-off Jujur dari Arsitektur Pipeline Solana
10. Pertanyaan Umum Tentang Pipelining Transaksi Solana
11. Pipelining Transaksi Solana dan Tesis Investasi SOL

Apa Itu Pipelining Transaksi Solana? (Dan Mengapa Hal Itu Penting bagi SOL)

Pipelining transaksi Solana adalah teknik memecah pemrosesan transaksi menjadi tahap-tahap yang berbeda dan menjalankan tahap-tahap tersebut secara bersamaan di beberapa batch transaksi, sehingga tidak ada perangkat keras validator yang menganggur menunggu tahap lain selesai. Bayangkan seperti lini perakitan mobil: kendaraan yang berbeda berada di stasiun yang berbeda secara bersamaan, dan lini tersebut tidak pernah berhenti untuk satu mobil diselesaikan sepenuhnya sebelum mobil berikutnya masuk.

Solana meminjam ide ini dari prosesor komputer. CPU modern mencapai throughput tinggi melalui pipelining tingkat instruksi: saat satu instruksi sedang dijalankan, instruksi berikutnya sedang didekodekan dan instruksi setelahnya sudah diambil. Solana menerapkan logika yang sama pada transaksi di tingkat validator. Pemetaan penuh tahap CPU ke tahap TPU Solana dibahas dalam bagian analogi CPU di bawah, tetapi prinsip intinya identik: menjaga setiap tahap tetap terisi setiap saat.

Kebanyakan blockchain memproses transaksi secara berurutan, artinya validator harus menyelesaikan semua pemrosesan pada satu transaksi (atau batch) sebelum memulai yang berikutnya. Model berurutan ini menciptakan batas atas throughput yang ditentukan sepenuhnya oleh seberapa cepat satu rantai operasi dapat berjalan. Pipelining mendobrak batas tersebut dengan menjalankan beberapa operasi secara paralel di seluruh komponen perangkat keras khusus, mengurangi latensi konfirmasi (waktu antara mengirimkan transaksi dan menerima finalisasi) tanpa mengharuskan setiap tahap individu berjalan lebih cepat.

TPS teoritis Solana, menurut dokumentasi teknis Solana, adalah sekitar 65.000 transaksi per detik. Ini mewakili maksimum pipeline dalam kondisi ideal. TPS non-vote di dunia nyata secara substansial lebih rendah, biasanya berkisar antara 2.000 hingga 4.000 TPS tergantung pada beban jaringan dan komposisi transaksi. Solana menghitung transaksi vote validator secara terpisah dari transaksi non-vote yang dihasilkan pengguna; angka total TPS termasuk vote lebih tinggi tetapi kurang bermakna sebagai metrik throughput yang dihadapi pengguna. Sebagai perbandingan, Ethereum memproses sekitar 15 hingga 30 transaksi per detik di Layer-1, dan Bitcoin memproses sekitar 7 transaksi per detik.

Statistik Kunci

Pipeline TPU Solana menghasilkan blok baru setiap ~400ms, kira-kira 30x lebih cepat daripada waktu blok Ethereum yang ~12 detik. TPS Teoritis: ~65.000. TPS non-vote dunia nyata: ~2.000-4.000 (bervariasi dengan beban jaringan).

Catatan metodologi TPS: Angka ~65.000 adalah maksimum teoritis dari dokumentasi teknis Solana. Throughput non-vote dunia nyata bervariasi dengan kondisi jaringan. Transaksi vote dikecualikan dari angka 2.000-4.000. Angka Ethereum mewakili throughput Layer-1 dan mengecualikan solusi Layer-2.

Mekanisme yang memungkinkan hal ini adalah Transaction Processing Unit (TPU) Solana, sebuah pipeline empat tahap yang berjalan di dalam setiap leader validator. Bagian selanjutnya menjelaskan bagaimana pipeline tersebut beroperasi secara mekanis.

Cara Kerja Pipeline TPU Solana: Penjelasan Empat Tahap

Mekanisme di balik kecepatan Solana adalah pipeline empat tahap yang ditempatkan di dalam Transaction Processing Unit (TPU), yang berjalan di dalam leader validator untuk setiap slot, memproses beberapa batch transaksi secara bersamaan melalui perangkat keras khusus di setiap tahap.

Apa Itu Transaction Processing Unit (TPU)?

Di Solana, Transaction Processing Unit (TPU) adalah mesin pipeline di dalam setiap Node validator yang secara fisik mengeksekusi pemrosesan transaksi. Ini adalah istilah khusus domain Solana dan tidak terkait dengan Tensor Processing Unit milik Google yang digunakan dalam pembelajaran mesin.

TPU berjalan secara eksklusif pada validator pemimpin untuk setiap slot ~400ms. Validator non-pemimpin menjalankan Transaction Validation Unit (TVU), yang memutar ulang dan memverifikasi blok yang diproduksi oleh pemimpin. Solana menentukan validator mana yang bertindak sebagai pemimpin melalui Jadwal Pemimpin deterministik, yang diterbitkan sebelumnya untuk setiap epoch (kira-kira 2 hingga 3 hari), yang menetapkan slot pemimpin setiap validator berdasarkan bobot stake-nya. Jadwal inilah yang memungkinkan pra-perutean transaksi Gulf Stream, seperti yang dibahas di bagian Gulf Stream di bawah ini.

Untuk detail teknis tentang arsitektur TPU, lihat dokumentasi resmi TPU Solana) dan dokumentasi waktu slot Solana.)

Empat Tahapan Pipeline TPU Solana

Pipeline TPU memproses transaksi melalui empat tahap berurutan, masing-masing ditangani oleh perangkat keras khusus, masing-masing meneruskan outputnya ke tahap berikutnya sambil secara bersamaan menerima input baru dari tahap sebelumnya.

1. Fetch: Tumpukan jaringan menerima paket transaksi mentah melalui QUIC (protokol transport modern yang menggantikan koneksi UDP asli untuk kontrol kemacetan yang lebih baik). Tahap Fetch adalah dermaga asupan pipeline. Tahap ini menarik transaksi dari buffer pra-muat yang sudah Terisi oleh Gulf Stream sebelum slot dimulai, dan meneruskan paket yang diverifikasi ke SigVerify.

2. SigVerify: GPU memverifikasi tanda tangan kriptografi pada transaksi masuk. Setiap transaksi Solana menyertakan satu atau lebih tanda tangan digital yang harus divalidasi sebelum perubahan status apa pun dapat terjadi. Akselerasi GPU memungkinkan ribuan verifikasi tanda tangan berjalan secara paralel dalam satu tahap ini. SigVerify adalah pos pemeriksaan autentikasi: transaksi yang lolos pindah ke Banking; transaksi yang gagal dibuang.

3. Banking: CPU menerapkan transaksi yang divalidasi ke status ledger, mengeksekusi debit dan kredit akun serta memproses perubahan status Kontrak Pintar. Banking adalah departemen akuntansi dari pipeline dan tahap yang paling intensif secara komputasi. Ini juga merupakan hambatan (bottleneck) utama di bawah beban tinggi: ketika volume transaksi melebihi kapasitas pemrosesan Banking, pipeline mulai membuang transaksi daripada mengantrekannya.

4. Writing: SSD NVMe menulis entri ledger yang dikonfirmasi ke disk, dan tahap ini menyiarkan data blok yang dihasilkan ke seluruh jaringan melalui Turbine. Writing adalah tahap pengiriman dan catatan: setelah selesai, blok tersebut ada secara On-Chain dan propagasi dimulai.

Mekanik pipelining inti beroperasi di keempat tahap secara bersamaan. Saat batch N berada di Banking, batch N-1 sudah berada di Writing, dan batch N+1 sudah berada di SigVerify. Tidak ada tahap yang menunggu tahap lain menyelesaikan batch saat ini sebelum memulai batch berikutnya. Inilah cara pipeline mencapai throughput paralel: setiap bagian perangkat keras ditempati setiap saat dalam slot tersebut.

[DIAGRAM DIPERLUKAN: DIAGRAM-01] Pipeline empat tahap yang menunjukkan batch A, B, C, D pada tahap yang berbeda secara bersamaan. Batch A: Writing (SSD NVMe). Batch B: Banking (CPU). Batch C: SigVerify (GPU). Batch D: Fetch (jaringan). Panah menunjukkan perkembangan setiap batch melalui tahap-tahap DAN operasi simultan di keempat tahap.

Siapa yang Menjalankan Pipeline? Validator dan Jadwal Pemimpin

Validator Solana adalah operator Node yang secara fisik menjalankan pipeline TPU. Setiap validator adalah server khusus yang menjalankan perangkat lunak Solana, yang bertanggung jawab baik untuk memproduksi blok (jika ia adalah pemimpin saat ini) atau untuk memverifikasi dan memutar ulang blok yang diproduksi oleh pemimpin (menggunakan TVU).

Jadwal Pemimpin menetapkan validator mana yang menjalankan TPU untuk setiap slot ~400ms. Jadwal tersebut dihitung secara deterministik dari set validator tertimbang stake pada awal setiap epoch, sehingga validator mengetahui slot pemimpin mereka yang akan datang beberapa hari sebelumnya. Prediktabilitas ini memungkinkan Gulf Stream untuk melakukan pra-perutean transaksi ke pemimpin yang akan datang sebelum slotnya dimulai, memastikan buffer tahap Fetch penuh saat slot dimulai.

Menjalankan pipeline TPU menuntut perangkat keras kelas enterprise: GPU khusus untuk tahap SigVerify, CPU dengan jumlah core tinggi untuk tahap Banking, SSD NVMe enterprise untuk tahap Writing, dan jaringan bandwidth tinggi untuk tahap Fetch. Persyaratan ini secara substansial lebih tinggi daripada ambang batas perangkat keras validator Ethereum, yang menciptakan trade-off sentralisasi yang dibahas di bagian batasan. Untuk spesifikasi perangkat keras validator saat ini, lihat dokumentasi persyaratan validator Solana.)

Proof of History: Jam Kriptografi Yang Memungkinkan Pipelining

Proof of History (PoH) adalah mekanisme kriptografi yang memungkinkan pipeline Solana berjalan secepat perangkat keras memungkinkan, tanpa mengharuskan validator untuk berkomunikasi satu sama lain untuk menyepakati waktu setiap batch transaksi sebelum maju ke tahap berikutnya.

Mekanismenya bekerja sebagai berikut. PoH menghasilkan urutan hash SHA-256 yang berkelanjutan, di mana setiap hash mengambil hash sebelumnya sebagai Input. Karena komputasi SHA-256 membutuhkan jumlah waktu yang terukur dan dapat diverifikasi, urutan hash yang dihasilkan merupakan bukti kriptografi bahwa sejumlah waktu tertentu telah berlalu di antara dua peristiwa yang dicatat dalam rantai. Setiap validator dapat memverifikasi urutan ini secara independen tanpa menghubungi validator lain.

Koneksi ke pipelining bersifat langsung. Tanpa PoH, pipeline perlu berhenti sejenak di setiap tahap dan menunggu jaringan mencapai konsensus pada urutan batch transaksi saat ini sebelum tahap berikutnya dapat dimulai. Perjalanan pulang-pergi komunikasi antar-Node tersebut akan menjadi faktor latensi yang dominan, membuat waktu slot 400ms menjadi tidak mungkin pada skala jaringan. PoH menghilangkan penantian ini dengan menyediakan jam bersama yang dapat diverifikasi yang dapat diperiksa oleh semua validator secara lokal. Pipeline bergerak maju berdasarkan jam PoH, bukan pada perjalanan pulang-pergi pesan jaringan.

Anatoly Yakovenko memperkenalkan Proof of History dalam Whitepaper Proof of History) yang diterbitkan pada tahun 2017, dengan memanfaatkan latar belakangnya dalam sistem terdistribusi dari waktunya di Qualcomm.

PoH bukanlah Proof of Stake.

Proof of History BUKAN Mekanisme Konsensus Solana. Ini adalah jam kriptografi yang mengurutkan peristiwa dan membuktikan waktu yang telah berlalu. Solana menggunakan Proof of Stake (khususnya Tower BFT, implementasi dari Practical Byzantine Fault Tolerance) untuk konsensus, yang menentukan validator mana yang memenuhi syarat secara ekonomi untuk berpartisipasi dan validator mana yang memimpin setiap slot. PoH menyediakan pengurutan dan pengaturan waktu. Proof of Stake memberikan keamanan ekonomi dan resistensi Sybil. Ini adalah fungsi yang berbeda.

Untuk penjelasan lengkap tentang cara kerja Proof of History, termasuk konstruksi kriptografinya dan hubungannya dengan Mekanisme Konsensus Solana, lihat [penjelasan khusus Proof of History kami].

PoH menyediakan jamnya. Gulf Stream memastikan kotak masuk pipeline selalu penuh.

Gulf Stream: Bagaimana Transaksi Masuk ke Pipeline Sebelum Siap

Gulf Stream adalah protokol penerusan transaksi Solana, dan inilah yang memastikan tahap Fetch pipeline tidak pernah menganggur menunggu transaksi tiba. Sebagian besar blockchain menahan transaksi yang belum dikonfirmasi dalam Mempool global, tempat mereka menunggu validator mana pun untuk mengambilnya. Solana tidak memiliki Mempool global. Gulf Stream mengganti model ini dengan pra-perutean deterministik.

Mekanisme ini bekerja dalam empat langkah:

1. Jadwal Pemimpin Solana menerbitkan, sebelumnya, validator mana yang akan memimpin setiap slot ~400ms yang akan datang.
2. Ketika pengguna atau aplikasi mengirimkan transaksi, Gulf Stream merutekannya langsung ke validator yang akan memimpin slot relevan berikutnya, bukan ke pool bersama.
3. Pada saat slot pemimpin validator tersebut dimulai, buffer tahap Fetch-nya sudah terisi sebelumnya dengan transaksi.
4. Tahap Fetch menarik dari buffer pra-muat ini daripada menunggu transaksi tiba selama slot berlangsung.

Desain tanpa mempool ini menghasilkan tiga manfaat yang terukur: ini mengurangi latensi konfirmasi karena transaksi menghabiskan lebih sedikit waktu menunggu, ini menghilangkan overhead memori yang dibebankan oleh mempool global pada setiap validator, dan ini secara substansial mengurangi persyaratan memori per validator.

Konsekuensinya adalah pertukaran: karena tidak ada buffer transaksi yang persisten, transaksi yang tidak segera diambil akan dibatalkan daripada dimasukkan ke antrean. Pengguna menerima pesan error "transaksi kedaluwarsa" dan harus mengirim ulang. Di bawah beban jaringan yang tinggi, perilaku ini adalah salah satu mekanisme yang berkontribusi pada peristiwa kemacetan, seperti yang dibahas di bagian keterbatasan.

Gulf Stream terhubung langsung ke tahap Fetch.

Gulf Stream merutekan ulang transaksi ke pemimpin berikutnya menggunakan Jadwal Pemimpin yang deterministik. Ketika tahap Fetch TPU validator aktif, ia mengambil dari buffer yang telah dimuat sebelumnya, bukan dari mempool global. Inilah sebabnya mengapa pipeline Solana jarang menunggu input di tahap Fetch dalam kondisi normal.

Jika Gulf Stream adalah mekanisme input pipeline, Turbine adalah mekanisme outputnya.

Analogi Pipeline CPU: Mengapa Arsitektur Solana Seharusnya Terasa Familiar bagi Para Insinyur

Pipeline transaksi Solana meminjam prinsip arsitektur yang sama yang membuat CPU modern cepat: pipelining tingkat instruksi. Ini bukan metafora. Desainnya terinspirasi secara arsitektural oleh teknik throughput yang sama yang dijelaskan dalam teks dasar Patterson dan Hennessy, Computer Organization and Design.

Pipeline instruksi CPU bekerja sebagai berikut. Alih-alih menunggu satu instruksi menyelesaikan semua tahapan pemrosesan sebelum mengambil instruksi berikutnya, CPU memecah eksekusi menjadi tahapan-tahapan berurutan (Fetch, Decode, Execute, Write-back) dan menjalankan tahapan tersebut secara bersamaan pada instruksi yang berbeda. Saat instruksi N sedang dieksekusi, instruksi N+1 sedang didekode dan instruksi N+2 sudah diambil. Hasilnya adalah throughput meningkat sebanding dengan jumlah tahapan pipeline, tanpa mengharuskan setiap tahapan berjalan lebih cepat.

Pipeline TPU Solana menerapkan prinsip yang sama ini pada transaksi. Pemetaan antar tahapan langsung:

[DIAGRAM DIBUTUHKAN: DIAGRAM-02] Diagram perbandingan berdampingan. Sisi kiri: pipeline instruksi CPU dengan tahapan Fetch, Decode, Execute, Write-back dan panah gelombang yang menunjukkan pemrosesan instruksi bersamaan. Sisi kanan: pipeline TPU Solana dengan tahapan Fetch, SigVerify, Banking, Writing dan panah gelombang yang menunjukkan pemrosesan batch bersamaan. Garis pemetaan antara tahapan analog.

Di mana analogi berlaku: Kedua arsitektur mencapai peningkatan throughput dengan menjaga semua tahapan tetap sibuk secara bersamaan. Keduanya tidak menunggu satu item selesai sebelum memulai yang berikutnya. Keduanya memproses item dalam gelombang, dengan beberapa item pada tahapan yang berbeda pada saat tertentu. Wawasan mendasar identik: pemrosesan berurutan membuang kapasitas perangkat keras; paralelisme pipeline menghilangkan pemborosan tersebut.

Di mana analogi tidak berlaku: Tiga perbedaan penting membedakan pipeline Solana dari pipeline CPU.

Pertama, pipeline Solana beroperasi di seluruh komponen perangkat keras terdistribusi yang terhubung oleh jaringan, bukan di dalam satu chip. Kondisi jaringan memengaruhi kinerja pipeline dengan cara yang tidak memiliki analogi CPU.

Kedua, mode kegagalannya berbeda. Bahaya pipeline CPU meliputi ketergantungan data (satu instruksi memerlukan output dari instruksi sebelumnya yang belum selesai) dan prediksi cabang yang salah (prosesor mengambil instruksi melalui jalur yang salah). Bahaya pipeline Solana berbeda jenisnya: spam transaksi bertindak sebagai bahaya struktural dengan membebani tahap Banking melebihi kapasitas pemrosesannya, dan kemacetan jaringan bertindak sebagai kondisi stall yang memperlambat tahap Fetch dan Writing. Ini adalah bahaya eksternal yang didorong oleh permintaan daripada bahaya ketergantungan data internal.

Ketiga, pipeline Solana tidak memiliki kesetaraan dengan eksekusi di luar urutan. Jam Proof of History menegakkan urutan transaksi yang ketat di dalam setiap batch, sehingga pipeline tidak dapat mengurutkan ulang transaksi untuk menghindari konflik seperti halnya CPU dapat mengurutkan ulang instruksi untuk menghindari bahaya data.

Memahami analogi ini dan batasannya memisahkan pengetahuan permukaan tentang kecepatan Solana dari wawasan arsitektur yang sebenarnya.

Turbine: Bagaimana Output Pipeline Mencapai Jaringan

Turbine adalah protokol propagasi blok Solana, dan ini menangani apa yang terjadi setelah tahap Writing pipeline selesai. Jika Gulf Stream memastikan pipeline selalu terisi, Turbine memastikan output pipeline mencapai sisa jaringan seefisien mungkin.

Setelah tahap Writing mengonfirmasi sekumpulan transaksi yang dikonfirmasi ke ledger, Turbine memecah blok yang dihasilkan menjadi paket data yang lebih kecil yang disebut shreds dan menyebarkannya melalui jaringan validator yang terstruktur seperti pohon. Alih-alih menyiarkan seluruh blok ke setiap validator secara bersamaan (yang akan memerlukan bandwidth uplink yang sangat besar dari pemimpin), Turbine mendistribusikan beban propagasi ke seluruh jaringan. Setiap validator di pohon menerima sebagian shred dan meneruskannya ke validator lain lebih jauh ke bawah pohon, serupa dalam prinsipnya dengan bagaimana BitTorrent mendistribusikan file dengan memiliki banyak node yang berbagi beban distribusi. (Turbine menggunakan pohon terstruktur daripada swarm peer-to-peer, yang merupakan perbedaan penting untuk keandalan jaringan.)

Desain yang kompatibel dengan pipelining penting di sini: shred mulai disebarkan ke seluruh jaringan sementara validator pemimpin sudah memproses batch transaksi berikutnya melalui pipeline. Propagasi blok dan produksi blok berjalan secara bersamaan. Diseminasi blok N di tingkat jaringan tidak menciptakan jeda dalam produksi blok N+1.

Manfaat rekayasa adalah bahwa Solana mencapai bandwidth blok yang tinggi tanpa memerlukan uplink tingkat enterprise di setiap node validator. Hanya validator pemimpin yang menanggung beban produksi penuh; propagasi didistribusikan ke seluruh jaringan.

Pembungkus input/output di sekeliling pipeline TPU:

Gulf Stream: input pipeline (merutekan ulang transaksi ke pemimpin berikutnya sebelum slot dimulai). Turbine: output pipeline (mendistribusikan data blok yang divalidasi sebagai shred melalui jaringan pohon validator). Bersama-sama, mereka memastikan pipeline TPU tidak pernah idle di kedua ujungnya.

Turbine menangani output pipeline di tingkat blok. Sealevel memperluas prinsip pipelining lebih dalam, hingga ke lapisan eksekusi smart contract.

Sealevel: Pipelining Diperluas ke Eksekusi Smart Contract

Pipelining transaksi tidak berhenti di TPU. Sealevel memperluas prinsip pemrosesan paralel yang sama ke eksekusi smart contract, dan ini adalah salah satu keunggulan arsitektural Solana yang paling kurang dihargai.

Sealevel adalah runtime smart contract paralel Solana. Ini memungkinkan ribuan smart contract (disebut program dalam arsitektur Solana, perbedaan dari terminologi Ethereum yang penting bagi pengembang) untuk dieksekusi secara bersamaan daripada secara berurutan. EVM Ethereum (Ethereum Virtual Machine) memproses smart contract pada satu thread, yang berarti hanya satu kontrak yang dapat dieksekusi pada satu waktu per blok. Sealevel menggunakan semua core CPU yang tersedia untuk mengeksekusi beberapa program secara paralel.

Mekanisme ini bergantung pada model akun Solana. Setiap transaksi Solana harus menyatakan di muka akun mana yang akan dibaca dan ditulisnya. Sealevel menggunakan deklarasi ini untuk mengelompokkan transaksi ke dalam grup yang tidak tumpang tindih: transaksi yang mengakses akun berbeda dapat dieksekusi secara bersamaan tanpa risiko konflik status, sementara transaksi yang berbagi akun harus diproses secara berurutan untuk menjaga kebenaran.

Persyaratan deklarasi di muka ini adalah batasan desain yang harus diperhitungkan oleh pengembang Solana saat merancang program. Program harus mendeklarasikan di muka semua akun yang akan mereka akses, yang berbeda dari model akses status Ethereum yang lebih permisif di mana akses penyimpanan kontrak tidak dideklarasikan sebelumnya.

Paralel dengan pipelining TPU sangat langsung. Sama seperti pipeline TPU yang membuat keempat tahap perangkat keras tetap terisi dengan memproses batch transaksi yang berbeda pada tahap yang berbeda secara bersamaan, Sealevel membuat semua inti CPU yang tersedia tetap terisi dengan mengeksekusi program yang tidak bertentangan secara bersamaan. Prinsip menjaga semua perangkat keras tetap sibuk setiap saat diterapkan di sini pada lapisan eksekusi.

Untuk melihat lebih dalam tentang cara deklarasi akun dan model akun Solana bekerja dalam praktik, lihat artikel kami [Solana Account Model Explained].

Solana vs. Ethereum: Perbandingan Arsitektur Pipeline

Perbedaan kinerja antara Solana dan Ethereum berasal dari pilihan arsitektur mendasar: pemrosesan pipeline paralel versus eksekusi transaksi berurutan.

EVM Ethereum memproses transaksi dalam antrean single-threaded. Satu transaksi harus selesai sebelum transaksi berikutnya dimulai. Desain ini disengaja: eksekusi berurutan menyederhanakan manajemen status, membuat perilaku kontrak pintar lebih mudah dipahami, dan memungkinkan validator untuk berpartisipasi dengan perangkat keras kelas konsumen, menghasilkan kumpulan validator yang luas dan relatif terdesentralisasi. Ethereum saat ini memiliki sekitar 900.000 atau lebih validator aktif.

Sebaliknya, pipeline TPU paralel Solana memproses banyak batch transaksi secara bersamaan di empat tahap perangkat keras khusus. GPU mempercepat verifikasi tanda tangan. CPU menerapkan perubahan status secara bersamaan di seluruh program yang tidak bertentangan melalui Sealevel. SSD NVMe menangani penulisan sementara Turbine menjalankan propagasi secara paralel. Desain ini menghasilkan throughput Layer-1 yang jauh lebih tinggi, tetapi menuntut perangkat keras yang jauh lebih banyak dan menciptakan kumpulan validator yang lebih terkonsentrasi, yaitu sekitar 2.000 validator aktif.

Angka kinerja konkrit. Waktu blok Ethereum kira-kira 12 detik; waktu slot Solana kira-kira 400 milidetik. TPS Layer-1 Ethereum kira-kira 15 hingga 30; TPS non-vote dunia nyata Solana kira-kira 2.000 hingga 4.000 tergantung pada kondisi jaringan. (Bitcoin, sebagai referensi skala, memproses kira-kira 7 transaksi per detik.) Solusi Layer-2 Ethereum, termasuk Arbitrum dan Optimism, secara dramatis meningkatkan throughput efektif Ethereum melampaui baseline Layer-1-nya, konteks penting saat membandingkan angka Layer-1 mentah.

Untuk rincian terperinci tentang bagaimana arsitektur ini dibandingkan di berbagai dimensi investasi dan pengembangan, lihat perbandingan arsitektur Solana vs. Ethereum lengkap kami [https://www.bybit.com/en/wiki/article/solana-vs-ethereum-which-to-buy-now/).

Tidak ada arsitektur yang secara kategoris lebih unggul. Keduanya mewakili pertukaran yang disengaja dalam Trilema Blockchain yang banyak dikutip. Ethereum menukar throughput untuk desentralisasi dan ekosistem Layer-2 yang kaya. Solana menukar desentralisasi untuk throughput Layer-1. Pertukaran mana yang lebih baik melayani aplikasi atau tesis investasi tertentu tergantung pada persyaratan spesifik.

Keterbatasan, Kemacetan, dan Pertukaran Jujur Arsitektur Pipeline Solana

Arsitektur pipeline Solana memberikan keunggulan kinerja yang terdokumentasi, dan membawa pertukaran yang terdokumentasi. Memahami keduanya diperlukan untuk setiap evaluasi serius jaringan, baik untuk pengembangan maupun investasi.

Ketika Pipeline Terbebani: Cara Kerja Kemacetan

Kemacetan pipeline terjadi ketika volume transaksi melebihi kapasitas pemrosesan Tahap Banking. Urutan kejadiannya spesifik. Tahap Banking tertinggal dari volume transaksi yang masuk. Karena desain Gulf Stream Solana yang tanpa Mempool tidak mempertahankan buffer transaksi persisten, transaksi yang tidak dapat diproses dengan cepat akan dibuang daripada dikantrekan. Pengguna menerima pesan kesalahan "transaksi kedaluwarsa" dan harus mengirim ulang. Pada tingkat kemacetan ekstrem, validator dapat keluar dari konsensus karena pipeline tidak dapat memproses transaksi suara cukup cepat relatif terhadap total volume transaksi, menyebabkan jaringan macet.

Solana mengalami gangguan jaringan besar pada September 2021, Januari 2022, dan Mei 2022, di antara periode lainnya. Penyebabnya tidak seragam. Dalam beberapa kasus, volume transaksi yang berlebihan membebani kapasitas Tahap Banking. Dalam kasus lain, penyebabnya adalah kampanye spam transaksi yang terkoordinasi, bug perangkat lunak, atau kegagalan konsensus yang tidak terkait dengan batas throughput pipeline. Mengaitkan semua gangguan Solana dengan pipelining akan tidak akurat. Batas kapasitas pipeline, ketika terlampaui dalam kondisi tertentu, berkontribusi pada beberapa peristiwa gangguan, sementara gangguan lain memiliki akar penyebab yang terpisah.

Untuk sejarah yang terdokumentasi tentang peristiwa jaringan Solana dan penyebabnya, lihat artikel kami [Gangguan Jaringan Solana: Sejarah dan Apa Artinya bagi Investor].

Respons Arsitektural Solana terhadap Kemacetan

Solana telah melakukan beberapa perubahan arsitektur sejak 2022 untuk mengatasi kemacetan pipeline:

• Adopsi protokol QUIC: Solana mengganti koneksi UDP asli pada Tahap Fetch dengan QUIC (protokol transport modern yang menyediakan kontrol kemacetan dan manajemen koneksi yang tidak dimiliki UDP). QUIC memungkinkan Tahap Fetch untuk mengelola penyerapan transaksi dengan lebih cerdas di bawah beban tinggi, mengurangi efektivitas spam transaksi berbiaya rendah.
• Quality of Service Berbobot Stake (SWQoS): Solana memperkenalkan Quality of Service Berbobot Stake (SWQoS), yang memprioritaskan transaksi yang diteruskan dari validator dengan bobot stake lebih tinggi. Ini mengurangi kemampuan aktor dengan stake rendah untuk membanjiri pipeline dengan transaksi spam yang mengonsumsi kapasitas Tahap Banking dengan mengorbankan transaksi pengguna yang sah.
• Prioritas Biaya: Pengguna dapat melampirkan prioritas biaya ke transaksi, menandakan kesediaan untuk membayar pemrosesan yang lebih cepat melalui pipeline selama periode permintaan tinggi.
• Firedancer: Firedancer, implementasi klien validator independen yang dikembangkan oleh Jump Crypto, sedang dalam pengembangan dan bertujuan untuk secara substansial meningkatkan throughput pipeline dan meningkatkan ketahanan jaringan dengan menyediakan klien alternatif yang mengurangi risiko implementasi tunggal.

Persyaratan perangkat keras validator Solana yang tinggi menghasilkan trade-off sentralisasi yang terukur. Menjalankan pipeline TPU memerlukan GPU tingkat perusahaan untuk tahap SigVerify, CPU dengan jumlah core tinggi untuk tahap Banking, NVMe SSD tingkat perusahaan untuk tahap Writing, dan jaringan bandwidth tinggi untuk Fetch dan Turbine. Spesifikasi ini menciptakan hambatan biaya yang signifikan bagi validator rumahan.

Hasilnya adalah set validator yang lebih terkonsentrasi daripada Ethereum. Solana memiliki sekitar 2.000 validator aktif; Ethereum memiliki sekitar 900.000 atau lebih (kedua angka berfluktuasi dan harus diverifikasi terhadap data jaringan saat ini). Solana Labs dan Solana Foundation telah mengakui trade-off ini secara eksplisit: persyaratan perangkat keras adalah konsekuensi yang disengaja dari pilihan desain yang mengutamakan throughput, mewakili Posisi Solana pada poros skalabilitas-desentralisasi dari Trilema Blockchain. Apakah trade-off ini dapat diterima tergantung pada apa yang diprioritaskan oleh penilai.

Pertanyaan yang Sering Diajukan: Pipelining Transaksi Solana

Apa Itu Transaction Processing Unit (TPU) Solana?

Transaction Processing Unit (TPU) Solana adalah mesin pipeline di dalam Node validator yang memproses transaksi secara fisik. Ini adalah istilah Solana, sama sekali tidak terkait dengan Tensor Processing Unit milik Google yang digunakan dalam pembelajaran mesin. TPU hanya berjalan pada leader validator untuk setiap slot ~400ms dan beroperasi melalui empat tahap: Fetch, SigVerify, Banking, dan Writing. Validator non-leader menjalankan TVU (Transaction Validation Unit) untuk memverifikasi dan memutar ulang blok sebagai gantinya.

Apa Itu Proof of History dan Bagaimana Kaitannya dengan Pipelining?

Proof of History (PoH) adalah jam kriptografi yang menghasilkan urutan hash SHA-256 yang dapat diverifikasi dan diurutkan berdasarkan waktu. PoH memungkinkan pipelining dengan meniadakan kebutuhan validator untuk berkomunikasi dan menyetujui urutan transaksi sebelum melanjutkan setiap tahap pipeline. Tanpa PoH, keterlambatan komunikasi antar-Node akan menjadi hambatan dominan; dengan PoH, pipeline maju berdasarkan jam bersama yang dapat diverifikasi secara lokal yang tidak memerlukan putaran jaringan (network round-trip).

Apa Itu Gulf Stream di Solana?

Gulf Stream adalah protokol penerusan transaksi tanpa mempool dari Solana. Alih-alih menahan transaksi yang belum dikonfirmasi dalam kolam global, Gulf Stream menggunakan Jadwal Leader deterministik untuk merutekan transaksi secara langsung ke leader validator mendatang sebelum slotnya dimulai. Saat tahap Fetch milik leader aktif, ia menarik dari buffer yang sudah dimuat sebelumnya. Perutean awal ini adalah alasan mengapa Solana dapat mempertahankan slot time ~400ms tanpa tahap Fetch menunggu transaksi tiba.

Apa Itu Sealevel?

Sealevel adalah runtime Kontrak Pintar paralel milik Solana. Ini memungkinkan ribuan Kontrak Pintar (disebut program dalam arsitektur Solana) untuk dieksekusi secara bersamaan dengan mewajibkan setiap transaksi untuk menyatakan di awal akun mana yang akan dibaca dan ditulis. Sealevel mengidentifikasi transaksi yang tidak tumpang tindih dan menjalankannya secara paralel di semua core CPU yang tersedia, memperluas prinsip pemrosesan paralel yang sama dari pipeline TPU ke lapisan eksekusi Kontrak Pintar.

Apakah Pipelining Transaksi Solana Menyebabkan Pemadaman Jaringan?

Kemacetan pipeline telah berkontribusi pada beberapa pemadaman Solana, tetapi tidak semua. Ketika volume transaksi melebihi kapasitas tahap Banking, desain tanpa mempool menyebabkan transaksi dijatuhkan alih-alih dikantrekan, dan pada kemacetan ekstrem, validator dapat keluar dari konsensus. Solana juga mengalami pemadaman yang disebabkan oleh bug perangkat lunak, kegagalan konsensus, dan spam transaksi terkoordinasi yang tidak terkait dengan batas throughput pipeline. Adopsi QUIC dan SWQoS telah mengurangi kegagalan yang didorong oleh kemacetan sejak 2022.

Berapa TPS Nyata Solana?

TPS teoretis Solana kira-kira 65.000, mewakili maksimum pipeline di bawah kondisi ideal menurut dokumentasi teknis Solana. TPS non-vote di dunia nyata biasanya berkisar antara 2.000 hingga 4.000, tergantung pada beban jaringan, komposisi jenis transaksi, dan kinerja validator. Solana menghitung transaksi vote validator secara terpisah dari transaksi yang dihasilkan pengguna; total termasuk vote lebih tinggi tetapi kurang bermakna sebagai metrik kinerja yang dihadapi pengguna.

Bagaimana Solana Lebih Cepat Daripada Ethereum?

Pipeline TPU paralel empat tahap Solana memproses beberapa batch transaksi secara bersamaan, sementara EVM Ethereum memproses transaksi secara berurutan pada satu thread tunggal. Hasilnya: slot time Solana kira-kira 400 milidetik dibandingkan dengan waktu blok Ethereum yang ~12 detik, dan TPS Layer-1 Solana kira-kira 2.000 hingga 4.000 dibandingkan dengan Ethereum yang ~15 hingga 30. Kedua arsitektur tersebut mewakili pilihan desain yang disengaja dengan trade-off yang berbeda pada Trilema Blockchain.

Apa yang Terjadi Saat Pipeline Solana Mengalami Kemacetan?

Ketika volume transaksi melebihi kapasitas pemrosesan tahap Banking, Solana menjatuhkan transaksi alih-alih mengantrekannya, karena desain Gulf Stream yang tanpa mempool tidak mempertahankan buffer yang persisten. Transaksi yang terpengaruh mengembalikan pesan kesalahan "transaksi kedaluwarsa" dan harus dikirim ulang. Pada kemacetan yang parah, pemrosesan transaksi vote dapat tertinggal, menyebabkan validator keluar dari konsensus. QUIC dan SWQoS mengurangi dampak kemacetan yang didorong oleh spam, meskipun batas kapasitas yang mendasarinya tetap menjadi trade-off arsitektur yang diketahui.

Jelajahi SOL di Bybit

Gunakan halaman harga Solana untuk meninjau data pasar SOL saat ini, atau akses pasar spot SOL/USDT jika Trading Spot sesuai dengan tujuan Anda. Aktivitas trading Bybit tidak sama dengan mengirimkan transaksi On-Chain Solana; biaya jaringan mungkin tetap berlaku saat menyetor atau menarik SOL di jaringan Solana.

Trader Derivatif berpengalaman juga dapat meninjau pasar perpetual SOLUSDT. Derivatif melibatkan risiko tambahan dan tidak memberikan kepemilikan SOL spot.

Pipelining Transaksi Solana dan Tesis Investasi SOL

Pipelining transaksi Solana adalah inovasi arsitektur nyata, bukan klaim pemasaran. Pipeline TPU empat tahap mewakili pendekatan teknik yang koheren terhadap throughput Layer-1. Proof of History menyediakan jam kriptografi yang memungkinkan pipeline maju tanpa penundaan konsensus jaringan. Gulf Stream memuat Input pipeline terlebih dahulu. Turbine mendistribusikan output pipeline. Sealevel membawa prinsip paralelisme yang sama ke eksekusi Kontrak Pintar.

Bagi investor yang memegang atau mengevaluasi Solana (SOL), memahami pipeline berarti memahami fondasi teknis dari diferensiasi kinerja Solana. Keunggulan kecepatan arsitekturnya bersifat struktural, bukan kebetulan. Hal ini berasal dari pilihan teknik khusus tentang cara menerapkan prinsip pemrosesan paralel di setiap lapisan siklus hidup transaksi.

Pilihan teknik tersebut membawa trade-off yang nyata. Peristiwa kemacetan tahun 2021 dan 2022 menunjukkan bahwa desain tanpa mempool dan batas atas throughput tahap Banking adalah batasan nyata dalam kondisi beban yang merugikan atau ekstrem. Persyaratan perangkat keras validator yang tinggi menghasilkan set validator yang lebih terkonsentrasi daripada Ethereum, yang mewakili Posisi yang disengaja pada poros skalabilitas-desentralisasi dari Trilema Blockchain. Evolusi arsitektur Solana yang sedang berlangsung, termasuk adopsi QUIC, penerapan SWQoS, dan klien Firedancer yang sedang dikembangkan oleh Jump Kripto, mencerminkan protokol yang secara aktif bekerja untuk meningkatkan batas-batas tersebut. Ini merupakan lintasan pengembangan, bukan masalah yang sudah selesai.

Throughput pipeline Solana telah menjadikannya Platform yang berarti bagi aplikasi DeFi yang membutuhkan finalitas transaksi di bawah satu detik. Ethereum tetap menjadi pilihan arsitektur yang valid dengan prioritas berbeda: desentralisasi yang lebih luas, ekosistem Layer-2 yang matang, dan basis pengembang yang lebih besar. Kedua jaringan menempati posisi berbeda di antara blockchain produksi.

Penafian: Artikel ini hanya untuk tujuan edukasi dan bukan merupakan saran investasi, saran keuangan, saran perdagangan, atau bentuk saran lainnya. Solana (SOL) adalah Mata Uang Kripto. Mata Uang Kripto adalah aset yang sangat volatil dan mengandung risiko kerugian yang signifikan. Selalu lakukan riset Anda sendiri dan konsultasikan dengan penasihat keuangan yang berkualifikasi sebelum membuat keputusan investasi.

Bacaan terkait dari klaster topik ini:

• Solana vs. Ethereum: Perbandingan Arsitektur Lengkap: perbandingan arsitektur lengkap Solana vs. Ethereum