Apa Itu Transaksi Solana V1? Peningkatan 4.096 Byte

Apa itu Solana Transaction V1? Ini adalah format transaksi baru yang diusulkan yang dirancang untuk meningkatkan kapasitas transaksi Solana sambil menyederhanakan cara validator memproses transaksi.

Saat ini Solana format transaksi memiliki ukuran terserialize maksimum sebesar 1.232 byte. Batas tersebut dapat menjadi kendala bagi aplikasi yang perlu menggabungkan banyak instruksi, akun, tanda tangan, atau data ke dalam satu transaksi atom.

Format transaksi Solana V1 yang diusulkan meningkatkan envelope menjadi 4.096 byte. Namun, peningkatan ini bukan hanya batas ukuran yang lebih besar. Ini juga mengubah tata letak transaksi dengan menghapus Tabel Pencarian Alamat (ALT), memindahkan informasi biaya dan sumber daya ke dalam metadata transaksi, dan memisahkan header instruksi dari payload panjang variabelnya.

Hasilnya adalah format transaksi yang dirancang untuk memberikan lebih banyak kapasitas aplikasi sambil mengurangi beberapa pemrosesan yang bergantung pada status yang diperlukan selama penerimaan validator.

Poin Penting

• Solana Transaction V1 meningkatkan envelope transaksi dari 1.232 byte menjadi 4.096 byte.

• V1 menghapus Tabel Pencarian Alamat (ALT) dan menempatkan semua alamat akun yang dirujuk langsung di dalam transaksi.

• Peningkatan ini dapat mendukung transaksi atom yang lebih kompleks, tetapi batas 64 akun yang ada masih dapat membatasi aplikasi yang berat akun.

Apa Itu Solana Transaction V1?

Solana Transaction V1 adalah format transaksi yang diusulkan yang merancang ulang cara transaksi diserialisasi dan diproses di jaringan Solana.

Usulan ini sangat terkait dengan dua Dokumen Peningkatan Solana: SIMD-0296, yang mengusulkan ukuran transaksi yang lebih besar, dan SIMD-0385, yang memperkenalkan format transaksi V1.

Perubahan yang paling terlihat adalah peningkatan ukuran maksimum transaksi. Menurut usulan, transaksi Solana 4.096-byte dapat mencapai hingga 4.096 byte alih-alih batas 1.232-byte saat ini.

Ini memberikan ruang yang jauh lebih signifikan untuk aplikasi yang memerlukan payload transaksi yang lebih besar.

Namun, V1 juga mengubah arsitektur transaksi yang mendasarinya. Alih-alih bergantung pada Tabel Pencarian Alamat untuk mengompres alamat akun, V1 mencakup akun yang dirujuk langsung dalam transaksi.

Ini menciptakan kompromi: aplikasi mendapatkan envelope transaksi yang jauh lebih besar, tetapi beberapa ruang tambahan itu dapat dikonsumsi oleh akun yang sebelumnya diwakili melalui indeks ALT yang kompak.

BACA JUGA: Solana Airdrops September 2026: Peluang Mendatang dan Cara untuk Memenuhi Syarat

Mengapa Solana Memerlukan Transaksi yang Lebih Besar?

Batas 1.232-byte yang ada dapat membuat operasi kompleks sulit untuk dimasukkan ke dalam satu transaksi atom.

Sebuah transaksi mungkin perlu menyertakan beberapa instruksi, alamat akun, tanda tangan, dan data spesifik aplikasi. Ketika data terserialize yang digabung melebihi batas, pengembang mungkin perlu membagi operasi ke beberapa transaksi.

Itu dapat membuat beberapa alur kerja menjadi lebih rumit karena operasi yang secara teori dapat terjadi secara atom harus sebaliknya dieksekusi secara terpisah.

Peningkatan ukuran transaksi Solana yang diusulkan memberikan pengembang ruang yang jauh lebih besar untuk membangun transaksi kompleks dalam satu envelope transaksi.

Ini bisa sangat berguna untuk aplikasi keuangan terdesentralisasi, sistem routing, transaksi multisig, aplikasi privasi, dan beban kerja lain yang memerlukan banyak informasi untuk diproses bersama.

Solana V1 vs V0: Apa Perubahannya?

Perbedaan antara Solana V1 dan V0 tidak terbatas pada ukuran transaksi.

V0 menggunakan Tabel Pencarian Alamat

Transaksi versi 0 dapat menggunakan Tabel Pencarian Alamat untuk merujuk akun menggunakan indeks kompak alih-alih menyertakan setiap kunci publik 32-byte langsung dalam transaksi.

Ini berguna ketika transaksi membutuhkan banyak akun karena secara signifikan mengurangi ukuran terserialize dari bagian akun.

Namun, penggunaan ALT juga memperkenalkan persyaratan pemrosesan tambahan untuk validator. Validator perlu mengambil tabel pencarian yang relevan, memvalidasinya, menyelesaikan indeks, dan membangun kembali set akun lengkap sebelum pemrosesan transaksi selanjutnya.

V1 menghapus ketergantungan ALT

Di bawah V1, Tabel Pencarian Alamat dihapus dari format transaksi.

Sebagai gantinya, semua akun yang dirujuk disertakan langsung dalam satu array alamat in-line.

Ini membuat set akun lengkap tersedia lebih awal dalam pemrosesan transaksi dan menghapus kebutuhan untuk resolusi ALT yang bergantung pada status selama penerimaan.

Komprominya adalah setiap akun in-line membutuhkan kunci publik 32-byte yang lengkap.

Solana V1 dan Batas Transaksi 4.096 Byte

Perubahan kapasitas yang paling penting adalah pergerakan dari 1.232 byte ke 4.096 byte.

Itu mewakili lebih dari tiga kali envelope transaksi sebelumnya.

Kapasitas yang lebih besar tidak berarti setiap transaksi akan secara otomatis menjadi lebih besar. Sebaliknya, aplikasi yang memerlukan ruang tambahan dapat menggunakan ruang yang tersedia untuk instruksi yang lebih kompleks, payload data yang lebih besar, akun tambahan, atau informasi kriptografi.

Analisis beban kerja Solana saat ini menunjukkan bahwa populasi transaksi yang ada secara luas kompatibel dengan envelope 4.096-byte setelah diubah dari V0 ke struktur V1 yang diusulkan.

Namun, ruang yang tersedia tidak terdistribusi secara merata di setiap komponen transaksi.

Kapasitas instruksi umumnya memiliki ruang yang substansial, sementara kapasitas akun lebih bervariasi.

Kompromi ALT dalam Solana Transaction V1

Penghapusan Tabel Pencarian Alamat adalah kompromi terpenting dalam format baru.

Di V0, sebuah akun yang dimuat dari ALT sering kali dapat direpresentasikan menggunakan sekitar satu byte untuk indeks pencariannya. Di bawah V1, akun yang sama harus direpresentasikan dengan alamat 32-byte lengkapnya.

Akibatnya, menghapus kompresi ALT dapat secara signifikan meningkatkan ukuran terserialize dari transaksi yang menggunakan banyak alamat pencarian.

Dampaknya sangat bergantung pada bagaimana ALT digunakan.

Sebuah transaksi yang memuat banyak akun dari hanya beberapa tabel pencarian mendapatkan keuntungan yang signifikan dari kompresi ALT di bawah V0. Mengubah transaksi itu ke V1 dapat menambahkan sejumlah byte yang substansial.

Di sisi lain, transaksi yang merujuk pada banyak tabel tetapi memuat relatif sedikit alamat dari masing-masing tabel mungkin melihat peningkatan yang jauh lebih kecil. Dalam beberapa konfigurasi yang jarang, menghapus overhead ALT bahkan dapat mengimbangi sebagian dari biaya alamat tambahan.

Inilah sebabnya mengapa peningkatan transaksi Solana V1 lebih baik dipahami sebagai kompromi kapasitas daripada peningkatan sederhana tiga kali lipat dalam ruang transaksi yang dapat digunakan.

Seberapa Besar Transaksi V1?

Analisis dari sampel 30 hari transaksi Solana memberikan perkiraan tentang bagaimana transaksi V0 saat ini akan berperilaku di bawah format yang diusulkan.

Di antara transaksi V0 saat ini yang menggunakan ALTs:

• Sekitar 50% akan mengalami kurang dari sekitar 420 byte tambahan setelah konversi.

• Sekitar 90% akan mengalami kurang dari sekitar 1.400 byte tambahan.

• Transaksi ALT yang padat dapat menambahkan lebih dari 1.500 byte ketika alamat mereka dikonversi menjadi alamat V1 inline.

Bahkan setelah memperhitungkan perluasan ini, distribusi transaksi V1 yang counterfactual tetap sebagian besar di bawah amplop 4.096 byte yang diusulkan.

Ini menunjukkan bahwa amplop yang lebih besar dapat memberikan kapasitas tambahan yang berarti bagi banyak beban kerja yang ada.

Apa Yang Dapat Diaktifkan Oleh Transaksi Solana yang Lebih Besar?

Transaksi Solana yang lebih besar dapat menguntungkan aplikasi yang saat ini mengalami kesulitan untuk memuat semua operasi yang diperlukan ke dalam satu transaksi.

Potensi kasus penggunaan meliputi:

Rute DeFi yang lebih kompleks

Router perdagangan dapat menggabungkan lebih banyak operasi dan interaksi akun dalam satu transaksi, yang berpotensi membuat rute yang kompleks lebih mudah dibangun secara atomik.

Beban multisig dan kriptografi yang lebih besar

Aplikasi yang melibatkan operasi multisig, bukti, tanda tangan, atau konstruksi kriptografi berbasis data lainnya dapat diuntungkan dari ruang serial tambahan.

Logika aplikasi yang lebih canggih

Pengembang dapat memiliki lebih banyak ruang untuk data instruksi dan beberapa instruksi tingkat atas tanpa langsung mencapai batas 1.232 byte sebelumnya.

Namun, ukuran transaksi hanyalah satu batasan.

Batas 64-Akun Masih Penting

Satu detail penting adalah bahwa batas 4.096 byte tidak secara otomatis menghapus setiap batasan transaksi yang ada.

Analisis saat ini menunjukkan bahwa kapasitas instruksi umumnya memiliki ruang kepala yang substansial setelah konversi, sementara ruang kepala akun lebih heterogen.

Ini berarti aplikasi dapat memiliki ratusan byte yang tidak terpakai tetapi masih tidak dapat menambahkan interaksi protokol lain jika mencapai batas akun.

Ini sangat relevan untuk aplikasi yang berat akun DeFi Menambahkan kolam likuiditas lain, pasar, orakel, brankas, atau komponen protokol lainnya mungkin memerlukan beberapa akun baru.

Oleh karena itu, V1 menyediakan kapasitas byte yang jauh lebih besar, tetapi itu tidak berarti bahwa aplikasi memiliki kapasitas akun yang tidak terbatas.

Bagaimana Transaksi Solana V1 Mengubah Pemrosesan Validator

Satu tujuan utama dari V1 adalah untuk menyederhanakan pengambilan transaksi bagi validator.

Dalam format transaksi yang ada, validator perlu mengekstrak biaya dan persyaratan sumber daya dari instruksi transaksi. Transaksi V0 juga memerlukan resolusi ALT sebelum set akun lengkap diketahui.

V1 mengubah proses ini dengan menjadikan biaya dan permintaan sumber daya sebagai metadata transaksi kelas satu.

Ini juga menyediakan array akun inline yang lengkap, menghapus kebutuhan untuk menyelesaikan Tabel Pencarian Alamat selama pengambilan.

Header instruksi dipisahkan dari payload panjang variabel mereka juga. Ini memungkinkan validator untuk menentukan batas instruksi tanpa mem-parsing secara berurutan setiap instruksi panjang variabel sebelumnya.

Bersama-sama, perubahan ini dapat memungkinkan validator untuk mengidentifikasi informasi transaksi yang penting lebih awal dan mengurangi pemrosesan tergantung keadaan dalam jalur pengambilan.

Siapa yang Diuntungkan dari Transaksi Solana V1?

Peningkatan ini dapat mempengaruhi beberapa bagian dari ekosistem Solana.

• Pengembang mendapatkan amplop transaksi yang lebih besar untuk operasi atom yang lebih kompleks.

• Validator dan tim klien diuntungkan dari struktur transaksi yang mengekspos informasi biaya dan sumber daya lebih awal dan menghapus resolusi ALT dari pengambilan.

• Pedagang dan sistem routing dapat berpotensi membangun rute transaksi atom yang lebih kompleks.

• Dompet, SDK, dan penyedia RPC perlu mendukung model serialisasi dan pembangunan transaksi yang baru.

• Aplikasi privasi dan kriptografi dapat diuntungkan dari tambahan ruang untuk payload berbasis data.

Namun, manfaat terbesar bukan hanya bahwa transaksi menjadi lebih besar. V1 berusaha untuk membuat transaksi yang lebih besar lebih mudah bagi jaringan untuk diproses secara struktural.

Transaksi Solana V1 Dijelaskan dalam Istilah Sederhana

Cara termudah untuk memahami Transaksi Solana V1 dijelaskan adalah dengan menganggapnya sebagai desain ulang wadah transaksi.

V0 menggunakan wadah yang lebih kecil dan dapat mengompres alamat akun melalui ALTs. V1 menggunakan wadah yang jauh lebih besar tetapi menempatkan semua alamat akun langsung di dalamnya.

Pada saat yang sama, V1 mengatur ulang metadata transaksi sehingga validator dapat mengidentifikasi biaya, persyaratan sumber daya, akun, dan batas instruksi dengan lebih efisien.

Jadi, trade-off-nya sangat jelas:

V0: transaksi yang lebih kecil + alamat ALT yang terkompresi + resolusi pencarian tambahan.

V1: transaksi yang lebih besar + alamat inline + penemuan akun yang lebih sederhana selama pengambilan data.

Wadah 4.096 byte yang lebih besar memberi aplikasi lebih banyak ruang, sementara struktur baru bertujuan untuk menyederhanakan pemrosesan validator.

BACA JUGA: Solana untuk Pemula - Semua Tentang Solana (SOL)

Kesimpulan

Apa itu Solana Transaction V1? Ini adalah format transaksi yang diusulkan yang dirancang untuk memperluas kapasitas transaksi Solana dari 1.232 byte menjadi 4.096 byte sambil mengubah cara data transaksi diorganisir.

Peningkatan ini terkait erat dengan SIMD-0296 dan SIMD-0385. V1 menghapus Tabel Pencarian Alamat dari format transaksi, memindahkan permintaan biaya dan sumber daya ke dalam metadata transaksi, dan memisahkan header instruksi dari payload berdimensi variabelnya.

Trade-off terbesar adalah penghapusan ALT. Akun yang sebelumnya diwakili melalui indeks pencarian kompak harus disertakan sebagai alamat 32 byte penuh, yang berarti beberapa transaksi dapat menjadi jauh lebih besar.

Meski demikian, beban kerja yang dianalisis tampaknya secara luas kompatibel dengan wadah 4.096 byte. Peningkatan ini dapat menyediakan kapasitas tambahan yang berarti untuk aplikasi kompleks, meskipun batas 64 akun yang ada dapat tetap menjadi kendala untuk transaksi yang berat akun.

Untuk trader yang mengikuti perkembangan ekosistem Solana dan mencari untuk memperdagangkan SOL atau aset kripto lainnya, Anda dapat menjelajahi pasar di Bitrue dan daftar untuk akun Bitrue di sini.

FAQ

Apa itu Solana Transaction V1?

Solana Transaction V1 adalah format transaksi yang diusulkan yang meningkatkan ukuran transaksi maksimum menjadi 4.096 byte dan mendesain ulang serialisasi transaksi.

Seberapa besar transaksi Solana V1?

Ukuran maksimum yang diusulkan adalah 4.096 byte, dibandingkan dengan batas 1.232 byte saat ini.

Apa itu SIMD-0385?

SIMD-0385 adalah Dokumen Peningkatan Solana yang mengusulkan format Transaksi V1 dan perubahan strukturnya.

Apa itu SIMD-0296?

SIMD-0296 mengusulkan peningkatan ukuran maksimum transaksi Solana dari 1.232 byte menjadi 4.096 byte.

Apakah Solana V1 menghapus Tabel Pencarian Alamat?

Ya. V1 menghapus ketergantungan ALT dari format transaksi dan menyertakan akun yang dirujuk langsung dalam transaksi.

Pemberitahuan: Pandangan yang diungkapkan sepenuhnya milik penulis dan tidak mencerminkan pandangan platform ini. Platform ini dan afiliasinya menolak tanggung jawab atas akurasi atau kesesuaian informasi yang diberikan. Ini hanya untuk tujuan informasi dan tidak dimaksudkan sebagai saran keuangan atau investasi.