Solana akan resmi meluncurkan fitur Transaction v1 di mainnet pada 9 September (Rabu). Fitur ini meningkatkan kapasitas maksimum transaksi dari 1.232 byte menjadi 4.096 byte, atau lebih dari tiga kali lipat. Peningkatan ini ditetapkan melalui dua proposal peningkatan Solana: SIMD-0296 (transaksi yang lebih besar) dan SIMD-0385 (format Transaction v1).
Spesifikasi teknis Transaction v1
Transaction v1 ditetapkan melalui dua proposal peningkatan Solana: SIMD-0296 mengatur batas transaksi yang lebih besar, sedangkan SIMD-0385 mendefinisikan format Transaction v1. Kedua proposal tersebut ditulis bersama oleh Jacob Creech dan Andrew Fitzgerald. Fitur baru ini telah beroperasi secara stabil selama beberapa waktu di testnet dan devnet, kemudian resmi diluncurkan di mainnet pada 9 September 2026.
Transaction v1 dirancang agar kompatibel dengan versi sebelumnya, dan format v0 yang ada tetap berlaku. Dompet dan aplikasi hanya akan menggunakan format v1 saat membutuhkan ruang transaksi yang lebih besar, sehingga tidak ada kewajiban untuk bermigrasi.
Tiga jenis skenario transaksi yang paling langsung diuntungkan oleh Transaction v1
Setelah kapasitas ditingkatkan dari 1.232 byte menjadi 4.096 byte, tiga jenis transaksi berikut akan memperoleh manfaat paling langsung:
Bukti kriptografi berukuran besar: Data verifikasi seperti bukti ZK sebelumnya sering kali harus dipecah menjadi beberapa transaksi karena melebihi batas 1.232 byte. Transaction v1 memungkinkan seluruh data verifikasi ZK dikemas dan dikirim dalam satu transaksi.
Proses persetujuan multisig: Transfer dana yang memerlukan persetujuan dari banyak penandatangan, seperti transaksi dari perbendaharaan perusahaan atau proposal DAO, membutuhkan ruang untuk setiap tanda tangan. Transaction v1 memungkinkan proses persetujuan multisig diselesaikan dalam satu transaksi.
Transfer rahasia: Sebagian mekanisme transaksi privat memerlukan lapisan enkripsi tambahan, sedangkan kapasitas sebelumnya tidak mencukupi sehingga transaksi dapat gagal atau menjadi kurang efisien. Kapasitas 4.096 byte menyediakan ruang yang memadai untuk operasi semacam ini.
Alasan penetapan batas 4.096 byte
Batas atas 4.096 byte (4 KB) ditetapkan dengan mempertimbangkan aspek perangkat keras. Ukuran ini merupakan ukuran halaman memori standar yang digunakan node validator. Jika satu transaksi melintasi beberapa halaman memori, biaya pemrosesan akan meningkat secara signifikan, sehingga tidak menguntungkan bagi upaya mempertahankan TPS tinggi Solana (jumlah transaksi per detik). Dengan demikian, 4 KB menjadi titik keseimbangan antara memperbesar kapasitas dan mempertahankan kinerja jaringan.
Batas lama sebesar 1.232 byte berasal dari desain awal jaringan Solana—setiap transaksi harus dimasukkan ke dalam paket IP berukuran sekitar 1.280 byte. Pada 2022, Solana menyesuaikan metode transmisi lalu lintas transaksi sehingga batas keras tersebut tidak lagi diperlukan. Peluncuran Transaction v1 secara resmi menghapus keterbatasan desain historis ini.
Pembaruan yang diperlukan untuk node RPC dan layanan pembacaan
Transaction v1 berdampak lebih besar pada layanan yang membaca data on-chain daripada pada proses penulisan transaksi. Semua layanan yang mengambil data blok dan transaksi—termasuk node RPC, penyedia data on-chain, serta backend dompet—harus memperbarui kode mereka. Jika tidak, layanan tersebut akan langsung mengembalikan kesalahan saat menemukan transaksi berformat v1.
Dampak konkret lainnya terdapat pada lokasi kolom biaya prioritas (priority fee): v1 menyimpan informasi biaya prioritas di kolom yang berbeda dari v0. Perangkat lunak versi lama akan menampilkan “biaya nol” saat membaca transaksi v1, meskipun pengguna sebenarnya telah membayar biaya percepatan. Jika antarmuka dompet, penjelajah blockchain, dan aplikasi transaksi tidak diperbarui, pengguna akan melihat informasi biaya yang tidak akurat.
Perbandingan kapasitas dengan Ethereum
Dari sisi desain protokol, Ethereum tidak memiliki batas ukuran transaksi pada tingkat protokol. Pengembang cukup membayar biaya gas yang lebih tinggi untuk menjalankan operasi yang intensif data dalam satu transaksi. Sebelumnya, Solana memiliki keterbatasan yang jelas terkait “berapa banyak instruksi yang dapat ditampung dalam satu transaksi”. Setelah Transaction v1 meningkatkan batas tersebut menjadi 4.096 byte, kesenjangan antara kedua jaringan menyusut. Namun, 4.096 byte masih tergolong kecil dibandingkan kapasitas Ethereum L1—transaksi DeFi kompleks di Ethereum, seperti arbitrase multi-pool atau peminjaman dan pelunasan multi-aset, sering kali melebihi angka tersebut.
Makna teknis praktisnya bagi ekosistem Solana adalah berkurangnya kebutuhan akan workaround dari pengembang. Ketika operasi sebelumnya harus dipecah menjadi beberapa transaksi, pengembang perlu menangani ketergantungan status lintas transaksi serta masalah rollback saat terjadi kegagalan. Transaction v1 memungkinkan logika kompleks diselesaikan dalam satu operasi atomik, sehingga lebih mendekati pola pemrograman tradisional.
Pertanyaan umum
Kapan Solana Transaction v1 diluncurkan, bagaimana perubahan kapasitas maksimumnya, dan proposal apa yang mendefinisikannya?
Solana Transaction v1 diluncurkan di mainnet pada 9 September 2026 (Rabu), dengan kapasitas maksimum transaksi yang meningkat dari 1.232 byte menjadi 4.096 byte (lebih dari tiga kali lipat). Peningkatan ini ditetapkan melalui dua proposal, yaitu SIMD-0296 dan SIMD-0385, yang ditulis bersama oleh Jacob Creech dan Andrew Fitzgerald, setelah sebelumnya beroperasi secara stabil di testnet dan devnet.
Mengapa batas 4.096 byte ditetapkan pada angka ini, bukan lebih tinggi?
4.096 byte merupakan ukuran halaman memori standar yang digunakan node validator. Jika satu transaksi melintasi beberapa halaman memori, biaya pemrosesan akan meningkat secara signifikan, sehingga tidak menguntungkan bagi upaya mempertahankan TPS tinggi Solana. Dengan demikian, 4 KB menjadi titik keseimbangan antara memperbesar kapasitas dan mempertahankan kinerja jaringan.
Bagaimana node RPC dan layanan pembacaan perlu diperbarui, dan apa dampak konkret perubahan kolom biaya prioritas?
Semua layanan yang mengambil data blok dan transaksi harus memperbarui kode mereka. Jika tidak, layanan tersebut akan langsung mengembalikan kesalahan saat menemukan transaksi v1. Lokasi kolom biaya prioritas pada v1 berbeda dari v0, sehingga perangkat lunak versi lama akan menampilkan “biaya nol” saat membaca transaksi tersebut, meskipun pengguna telah membayar biaya percepatan. Jika dompet dan penjelajah blockchain tidak diperbarui, informasi biaya yang ditampilkan akan menjadi tidak akurat.
