
P-Token: Terobosan Efisiensi Besar Berikutnya untuk Solana
Terima kasih banyak kepada Febo, Jacob Creech, dan 0xIchigo yang telah meninjau versi awal tulisan ini.
Pendahuluan
Salah satu faktor yang kurang mendapat perhatian di balik pesatnya adopsi Solana adalah pendekatannya terhadap token yang aman, sederhana, dan terstandardisasi. Tidak seperti banyak blockchain lain, pembuatan token di Solana tidak memerlukan deployment kontrak khusus. Sebaliknya, semuanya berjalan melalui program SPL token (alias Tokenkeg) yang telah diaudit secara menyeluruh, teruji di lapangan, dan awalnya di-deploy oleh Solana Labs. Pendekatan ini mempermudah tindakan umum seperti mencetak, membakar, dan mentransfer token. Sebagai contoh, token Solana dapat di-deploy hanya dengan satu perintah CLI.
SPL Token Program adalah program yang paling banyak digunakan di Solana (selain System program). Selama enam bulan terakhir, jumlah token fungible baru yang dibuat setiap minggu melalui program SPL token rata-rata berkisar antara 200.000 hingga 300.000. Angka ini meningkat 20 kali lipat dibandingkan dua tahun sebelumnya, yaitu September 2023, ketika pembuatan token SPL baru setiap minggu umumnya berada di bawah 10.000. Secara keseluruhan, kecuali pada 2023, setiap tahun sejak peluncuran Solana mencatat peningkatan signifikan dalam jumlah token baru yang diterbitkan, seperti ditunjukkan pada grafik di bawah ini.
Pertumbuhan transfer token SPL bahkan lebih pesat. Selama tiga bulan terakhir, jumlah transfer mingguan konsisten melampaui 650 juta dan mencapai puncak 867,8 juta pada akhir Juli. Puncak ini merupakan peningkatan 17,5 kali lipat dari titik terendah sebesar 49,4 juta transfer mingguan yang tercatat pada awal Agustus 2023.
Memperkenalkan P-Token
P-token adalah pengganti langsung program SPL Token saat ini yang dioptimalkan untuk komputasi. P-token pertama kali diusulkan oleh tim Anza pada Maret melalui SIMD-0266: Program Token yang Efisien. Program ini secara signifikan mengurangi penggunaan compute unit (CU), sekaligus tetap sepenuhnya kompatibel dengan token SPL yang sudah ada.
Karena p-token mereplikasi secara persis kumpulan instruksi dan tata letak account dari program SPL Token, program ini dapat langsung digunakan sebagai penggantinya. Artinya, p-token bukan standar token baru. Kode klien tetap berfungsi persis seperti sebelumnya. Dengan demikian, transisi ini menghasilkan peningkatan efisiensi yang signifikan tanpa memerlukan penyesuaian apa pun dari aplikasi atau pengguna.
Upaya mendorong adopsi p-token selaras dengan langkah Solana yang lebih luas untuk meningkatkan efisiensi program dan framework. Langkah ini melengkapi upaya peningkatan kapasitas jaringan, terutama melalui target 2025 untuk menggandakan blockspace yang tersedia.
Kesuksesan AMM proprietary baru-baru ini di Solana menunjukkan dampak biaya komputasi yang lebih rendah dan keunggulan program yang sangat efisien. Sebagai contoh, pembaruan oracle pada platform seperti HumidiFi telah dioptimalkan secara ekstrem hingga hanya menggunakan 143 CU. Doppler, program oracle open-source baru dari BlueShift, menurunkan biaya lebih jauh lagi menjadi hanya 21 CU.
Pinocchio
Huruf “p” dalam p-token merujuk pada Pinocchio, library tanpa dependensi yang optimal dan berkinerja tinggi untuk menulis program Solana, yang dikembangkan oleh Anza. Pinocchio berfungsi sebagai pengganti crate solana-program standar, dengan penggunaan tipe zero-copy secara luas untuk menangani data instruksi dan account. Dengan zero-copy, data tidak diduplikasi ke lokasi memori baru saat dibaca atau ditulis. Sebaliknya, state diakses langsung melalui pointer. Desain ini menghasilkan penghematan komputasi yang signifikan karena menghindari operasi memori yang tidak diperlukan, sekaligus mengurangi overhead runtime.
Pinocchio juga bersifat no_std, yang berarti tidak bergantung pada library standar Rust atau alokasi heap karena Solana Virtual Machine (SVM) sudah menyediakan lingkungan runtime. Hal ini semakin menyederhanakan eksekusi dan mengurangi dependensi, sehingga menghasilkan program yang lebih ramping dan cepat.
Peningkatan Efisiensi
CU mengukur biaya eksekusi dalam runtime Solana. Operasi terkecil, seperti penjumlahan dua bilangan bulat atau operasi bitwise, mengonsumsi 1 CU. Program dibatasi hingga 200 ribu CU per instruksi dan 1,4 juta CU per transaksi.
P-Token menghadirkan peningkatan efisiensi yang drastis dengan mengurangi konsumsi CU untuk transaksi token SPL standar sekitar 95% (peningkatan efisiensi sebesar 19 kali lipat). Eksekusi yang lebih cepat ini menghasilkan pengalaman pengguna yang lebih lancar. Sementara itu, kapasitas komputasi yang terbebas memungkinkan lebih banyak transaksi dimuat dalam setiap blok sehingga secara langsung meningkatkan throughput jaringan.
Saat ini, instruksi Token program menggunakan sekitar 10% CU di seluruh blok. Dengan memangkas biayanya menjadi hanya 5% dari tingkat saat ini, p-token dapat menurunkan porsi tersebut dari 10% menjadi 0,5% dan membuka tambahan kapasitas blok sebesar 9,5% untuk transaksi lain. P-token juga memberikan manfaat bagi program downstream, menawarkan composability yang lebih baik dengan mengurangi penggunaan CU secara keseluruhan dan menurunkan biaya cross-program invocation (CPI).
Berikut adalah data yang merinci peningkatan efisiensi CU dari instruksi p-token dibandingkan dengan program SPL Token saat ini, dalam bentuk grafik dan tabel.
| Instruksi | CU P-token | CU Spl-token | Penghematan P-token |
| initialize_mint | 105 | 2,967 | 93% |
| initialize_account | 155 | 4,527 | 94% |
| initialize_multisig | 193 | 2,973 | 88% |
| transfer | 79 | 4,645 | 95% |
| approve | 124 | 2,904 | 91% |
| revoke | 99 | 2,677 | 91% |
| set_authority | 136 | 3,167 | 92% |
| mint_to | 123 | 4,538 | 95% |
| burn | 133 | 4,753 | 93% |
| close_account | 125 | 2,916 | 91% |
| freeze_account | 149 | 4,265 | 93% |
| thaw_account | 146 | 4,267 | 93% |
| Instruksi | CU P-token | CU Spl-token | Penghematan P-token |
| transfer_checked | 111 | 6,200 | 98% |
| approve_checked | 171 | 4,458 | 96% |
| mint_to_checked | 172 | 4,545 | 96% |
| burn_checked | 136 | 4,754 | 97% |
| initialize_account2 | 172 | 4,388 | 96% |
| initialize_account3 | 248 | 4,240 | 94% |
| initialize_multisig2 | 319 | 2,826 | 89% |
| initialize_mint2 | 226 | 2,827 | 92% |
| amount_to_ui_amount | 461 | 2,499 | 82% |
| ui_amount_to_amount | 694 | 3,161 | 78% |
| initialize_immutable_owner | 38 | 1,404 | 97% |
| sync_native | 62 | 3,045 | 98% |
Optimalisasi penting lainnya, yang sebagian besar dimungkinkan oleh `no_std`, adalah pengurangan ukuran binary program dari 131 KB menjadi 95 KB.
Instruksi Tambahan
P-token mengusulkan penambahan tiga instruksi baru (`withdraw_excess_lamports`, `batch`, dan `unwrap_lamports`) ke dalam program token yang tidak tersedia dalam program SPL token asli.
Menarik Lamport Berlebih
Serupa dengan implementasi SPL Token-2022 saat ini, `withdraw_excess_lamports` memungkinkan pemulihan kelebihan SOL yang “terkunci” di mint account. Hal ini biasanya terjadi ketika pengguna secara tidak sengaja mengirim lamport ke token mint account.
Penarikan memerlukan otorisasi dari mint authority, baik signer yang ditentukan untuk mint account standar maupun multisig untuk account multisig. Karena mint authority pada sebagian besar token SPL telah dicabut, otorisasi sebagai alternatif dapat diberikan dengan menggunakan mint account itu sendiri sebagai signing authority, dengan instruksi yang ditandatangani menggunakan private key milik mint.
Dari seluruh token mint account SPL, ~869.000 menyimpan SOL melebihi ambang batas minimum bebas sewa sebesar 0,0014616 SOL. Secara keseluruhan, jumlah ini mencapai 176.961,5 SOL yang terkunci di dalam token mint account, senilai USD 36 juta berdasarkan harga saat ini. Jumlah SOL terbesar yang terkunci di token mint account biasanya terkait dengan memecoin, token lama, dan aset blue-chip utama. Jumlah SOL terbesar yang terkunci dalam mint account suatu token dimiliki oleh BOOK OF MEME ($BOME), sebuah memecoin, dengan 6.328 SOL. Adopsi p-token berpotensi memungkinkan saldo ini dibuka dan memberikan keuntungan besar bagi tim di balik token-token tersebut.
Batch
Instruksi baru kedua adalah `batch`, yang menyederhanakan interaksi CPI dengan program p-token. Alih-alih memanggil program token beberapa kali, `batch` memungkinkan sejumlah variabel instruksi token dieksekusi dalam satu panggilan. Artinya, biaya dasar CPI sebesar 1.000 unit hanya dikenakan sekali, bukan untuk setiap instruksi.
Hasilnya adalah pengurangan penggunaan komputasi yang signifikan bagi protokol yang mengandalkan beberapa CPI token dalam satu instruksi, sebuah pola yang umum di seluruh ekosistem DeFi Solana. Sebagai contoh, AMM dapat melakukan dua transfer dalam sebuah swap, atau deposit ke liquidity pool dapat melibatkan transfer sekaligus mint. Dengan menggunakan `batch`, program dapat menghemat CU secara signifikan dalam skenario ini.
Membuka Bungkus Lamport
Instruksi `unwrap_lamports` (baru-baru ini ditambahkan dalam PR terpisah) memungkinkan transfer lamport secara langsung ke account tujuan sehingga tidak perlu membuat native token account sementara.
Sebelumnya, membuka bungkus lamport dari wrapped SOL account memerlukan pembuatan lalu penutupan associated token account (ATA) untuk penerima. Dengan pembaruan ini, lamport kini dapat ditransfer langsung keluar dari native SOL account sehingga prosesnya menjadi lebih sederhana.
Jalur Cepat untuk Instruksi Transfer
Analisis penggunaan token program di mainnet menunjukkan konsentrasi yang kuat pada instruksi transfer, yang secara keseluruhan mencakup hampir separuh dari seluruh aktivitas. Lima instruksi yang paling sering digunakan adalah:
- transfer_checked (36.33%)
- transfer (13.22%)
- close_account (12.23%)
- initialize_account3 (9.98%)
- initialize_immutable_owner (9.78%)
Pola penggunaan ini menunjukkan peluang untuk lebih mengoptimalkan p-token bagi transfer dan mengurangi konsumsi CU. Sebagian besar pekerjaan optimalisasi ini dikontribusikan oleh Cavey dari Temporal (untuk pembahasan pendekatan ini secara lebih mendalam, lihat livestream X miliknya).
Untuk mencapai peningkatan ini, p-token memperkenalkan entrypoint khusus dengan jalur cepat untuk instruksi transfer dan memperbarui processor agar memprioritaskan `sync_native` dan `initialize_immutable_owner`. Bersama-sama, perubahan ini menghasilkan peningkatan efisiensi CU yang signifikan dan selaras dengan pola penggunaan yang diamati.
Logging
Dengan diperkenalkannya p-token, satu pertanyaan yang masih terbuka adalah apakah perilaku logging saat ini perlu dipertahankan. Versi proposal terbaru menyarankan penghapusan log. Di Solana, log adalah mekanisme utama untuk mengekstrak data debugging, pemantauan, dan event dari program. Dalam program token yang ada, log sangat minimal dan terbatas pada pencetakan nama instruksi yang sedang dieksekusi. Contohnya:
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA invoke [1],
Program log: Instruction: TransferChecked,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA consumed 6281 of 7738 compute units,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA successNamun, baris log yang tampak sederhana ini, `Instruction: <name>`, memerlukan sekitar 103 compute unit. Dalam praktiknya, overhead tersebut dapat mengonsumsi komputasi yang hampir setara dengan instruksinya sendiri. Sebagai contoh, logging menyumbang sekitar 40% dari total komputasi yang diperlukan untuk transfer sederhana.
Selain biayanya, log ini tidak selalu dapat diandalkan; log dapat terpotong atau dimanipulasi melalui log injection sehingga berisiko menyesatkan parser downstream. Di sisi lain, menghapus log sepenuhnya dapat merusak workflow developer dan aplikasi yang saat ini bergantung pada keberadaannya.
Penghapusan log akan meningkatkan pentingnya tim memublikasikan IDL untuk memberikan visibilitas terhadap perilaku program. Sebagai contoh, Anchor kini menerapkan hal ini dengan memublikasikan IDL untuk semua program baru secara default, kecuali dinonaktifkan secara eksplisit.
Audit
Audit program p-token sudah berlangsung untuk memastikan kompatibilitas mundur dan keamanan penuh. Agar dapat diadopsi, p-token harus secara ketat mematuhi instruksi dan tata letak account yang persis sama dengan Token program saat ini, serta mereplikasi perilakunya dengan akurat. Setiap penyimpangan akan menimbulkan risiko, yang sedang ditangani melalui pengujian menyeluruh dan audit independen.
Auditor Neodyme melakukan pengujian ekuivalensi dengan memutar ulang setiap transaksi mainnet dari beberapa bulan terakhir sebanyak dua kali: pertama menggunakan program token asli dan kedua menggunakan p-token. Hasilnya mengonfirmasi output yang identik sekaligus menunjukkan penghematan CU yang signifikan.
Menurut analisis mereka, antara 3 Agustus dan 11 Agustus 2025, p-token dapat mengurangi overhead sebesar 8,9 triliun CU dengan logging diaktifkan dan 9,14 triliun CU dengan logging dinonaktifkan. Angka-angka ini masing-masing menunjukkan penghematan sebesar 12,0% dan 12,3% dari total penggunaan blockspace.
P-token saat ini sedang menjalani audit kedua oleh Zellic dan verifikasi formal oleh Runtime Verification.
Peluncuran
Proses peluncuran p-token yang direncanakan menggunakan pendekatan bertahap. Proses ini dimulai dengan penyelesaian audit, fuzzing, dan verifikasi formal. Setelah itu, validator akan melakukan governance vote terkait adopsi p-token dan penerimaan resmi SIMD 266. Kemudian, fitur p-token akan di-deploy ke cluster dan ditempatkan di balik feature gate.
Program akan terlebih dahulu di-deploy ke account yang telah ditentukan (ptokN…UkkZ2). Setelah feature gate diaktifkan pada batas epoch, runtime di seluruh validator akan mengganti program token yang ada (Tokenkeg…VQ5DA) dengan implementasi baru menggunakan Upgradable Loader v3.
Pendekatan alternatifnya adalah men-deploy program p-token ke address baru sehingga pengguna dan aplikasi harus melakukan migrasi secara manual. Namun, opsi ini tidak diutamakan karena kemungkinan besar akan menghambat adopsi dan mengurangi manfaat secara keseluruhan, mengingat banyak pengguna akan ragu atau lambat untuk beralih.
Dampak Ekonomi
Adopsi p-token merupakan bagian dari serangkaian peningkatan yang siap memperluas kapasitas Solana secara keseluruhan dengan drastis, sehingga lebih banyak transaksi dapat dimuat ke dalam setiap blok. Peningkatan penting lainnya mencakup penggandaan blockspace menjadi 100 juta CU dan peningkatan batas CU per account dari angka tetap 12 juta menjadi 40% dari blok.
Saat ini, satu account dibatasi hingga 12 juta CU per blok. Seperti ditunjukkan dalam grafik dari Anza di bawah ini, account yang paling diperebutkan dalam setiap blok sering kali mencapai batas tersebut. P-token sendiri akan mempersulit account mencapai batas ini sehingga mengurangi frekuensi bottleneck pada hot state.
Hampir semua transaksi saat ini menyertakan priority fee atau tip Jito untuk mendorong validator memasukkannya ke dalam blok. Karena prioritas ditentukan berdasarkan biaya per CU, transaksi p-token yang mengonsumsi lebih sedikit CU seharusnya, jika faktor lainnya sama, memperoleh prioritas lebih tinggi untuk biaya atau tip yang sama. Namun, karena semua transaksi token SPL akan mendapatkan manfaat dari peningkatan p-token, dampak keseluruhannya terhadap prioritas transaksi masih perlu diamati.
Kesimpulan
Adopsi p-token, dengan asumsi lolos governance vote, merupakan langkah maju yang besar dalam meningkatkan efisiensi dan skalabilitas Solana. Dengan secara drastis mengurangi penggunaan komputasi dan menyederhanakan interaksi CPI, p-token memperkuat fondasi program yang paling banyak digunakan di jaringan sekaligus memperluas kapasitas blok secara keseluruhan. Jika berhasil, p-token dapat menjadi cetak biru untuk mengembangkan versi program lain yang banyak digunakan dan dioptimalkan dengan Pinocchio, seperti program Associated Token Account (ATA) dan bahkan System program, sehingga membuka jalan bagi runtime yang lebih cepat dan efisien.
Referensi Lebih Lanjut
- Repositori p-token - GitHub
- Repositori Pinocchio - GitHub
- Solana Program Library (SPL) - GitHub
- Kalkulator Penghematan SOL p-Token - SendAI
Artikel Terkait
Berlangganan Helius
Ikuti perkembangan terbaru dalam pengembangan Solana dan dapatkan pembaruan saat kami memublikasikan postingan


