Model Pemrograman Solana: Pengantar Pengembangan di Solana

Apa yang dibahas dalam artikel ini?

Pendekatan Solana terhadap komputasi terdesentralisasi berakar pada prinsip sederhana: semuanya disimpan dalam wilayah memorinya sendiri, yang dikenal sebagai account. Solana beroperasi sebagai penyimpanan key/value global dengan public key sebagai pengenal unik untuk account terkait. Account merupakan tulang punggung Solana karena menyimpan state; account menampung semuanya, mulai dari program hingga saldo token. Transaction digunakan untuk memperbarui account dan mencerminkan perubahan state.

Dalam artikel ini, kami membahas kompleksitas arsitektur Solana. Kami memulai dengan gambaran umum cluster dan konsep state, lalu membahas peran account dan program sebagai komponen dasar Solana. Setelah itu, kami mengulas cara transaction memungkinkan interaksi dinamis antara account dan program.

Pada akhir artikel ini, Anda akan memahami model pemrograman Solana secara menyeluruh. Anda akan mengenal arsitektur cluster, peran penting account dalam penyimpanan data, dan proses yang digunakan transaction untuk memperbarui data account. Selain itu, Anda akan mempelajari fitur unik Solana seperti sistem rent dan transaction berversi.

Apa itu cluster Solana?

Inti arsitektur Solana adalah cluster, yaitu sekumpulan validator yang bekerja sama untuk memproses transaction dan memelihara satu ledger. Solana memiliki beberapa cluster terpisah, masing-masing dengan tujuan tertentu:

• Localhost: cluster pengembangan lokal yang tersedia di port default 8899. Antarmuka Baris Perintah Solana (CLI) dilengkapi validator pengujian bawaan yang dapat disesuaikan dengan kebutuhan masing-masing developer tanpa memerlukan airdrop atau mengalami rate limit
• Devnet: lingkungan sandbox tanpa konsekuensi untuk pengujian dan eksperimen di Solana
• Testnet: lingkungan pengujian bagi kontributor inti Solana untuk mencoba pembaruan dan fitur baru sebelum masuk ke mainnet. Cluster ini juga digunakan sebagai lingkungan pengujian oleh developer yang ingin menjalankan uji performa
• Mainnet Beta: cluster aktif tanpa izin tempat transaction dunia nyata berlangsung. Inilah Solana yang “sebenarnya”, tempat pengguna, developer, pemegang token, dan validator berinteraksi setiap hari

Setiap cluster beroperasi secara independen dan sama sekali tidak mengetahui keberadaan cluster lainnya. Transaction yang dikirim ke cluster yang salah akan ditolak demi menjaga integritas setiap lingkungan operasional.

Bayangkan cluster sebagai heap data monolitik. Dalam ilmu komputer, heap adalah wilayah memori tempat data dapat disimpan dan diubah secara dinamis. Namun, penting untuk dicatat bahwa cluster tidak benar-benar menggunakan struktur data heap. Analogi ini berfungsi sebagai alat konseptual untuk membantu memahami bahwa cluster terdiri dari berbagai wilayah memori yang dapat dialokasikan dan dibebaskan saat diperlukan. Memahami cluster sebagai heap dinamis merupakan kunci untuk memahami cara data dikelola, diakses, dan diamankan dalam jaringan.

Anda juga dapat membayangkan heap data monolitik ini sebagai semacam gudang digital. Di sini, data seperti kotak di rak, masing-masing memiliki label unik dan aturan khusus untuk memindahkan atau mengubah isinya. Hal ini memastikan sistem yang aman dan teratur, tempat hanya perpindahan atau perubahan resmi yang diizinkan.

Smart contract, yang dikenal sebagai program di Solana, mendapat bagian gudang atau heap tersendiri yang dapat dikelola. Meskipun sebuah program dapat membaca bagian mana pun dalam gudang ini, program tersebut memerlukan izin tertentu untuk mengubah isi ruang yang bukan miliknya. Satu-satunya tindakan yang diizinkan secara universal adalah mentransfer lamport, mata uang kripto native Solana, ke ruang mana pun di dalam gudang.

Semua state berada dalam heap ini, termasuk program. Setiap wilayah memiliki program yang memilikinya dan mengelolanya sebagaimana mestinya. Sebagai contoh, program dimiliki oleh BPFLoader, program yang bertanggung jawab untuk memuat, men-deploy, dan meng-upgrade program on-chain. Kami menyebut wilayah memori ini, yaitu kotak-kotak dalam gudang digital, sebagai account.

Apa itu account?

Semua yang ada di Solana adalah account. Anggap account sebagai wadah yang menyimpan data secara persisten, seperti file di komputer. Account adalah komponen dasar model program Solana yang digunakan untuk menyimpan state (yaitu saldo account, informasi kepemilikan, apakah account menyimpan program, dan informasi rent).

Ada tiga jenis account di Solana:

• Account yang menyimpan data
• Account yang menyimpan program executable
• Account yang menyimpan program native

Berdasarkan kemampuannya, jenis account tersebut dapat dibedakan lebih lanjut menjadi:

• Account executable - account yang mampu menjalankan kode
• Account non-executable - account yang digunakan untuk menyimpan data tanpa kemampuan menjalankan kode (karena tidak menyimpan kode apa pun!)

Pada gambar di atas, terdapat beberapa contoh account executable dan non-executable. Untuk account executable, Bubblegum adalah contoh Program Account. Ini merupakan program dari Metaplex yang digunakan untuk membuat dan mengelola NFT terkompresi. Vote Program adalah contoh Native Program Account. Program ini digunakan untuk membuat dan mengelola account yang melacak state voting validator dan reward. Kami akan membahas perbedaan antara Program Account dan Native Program Account di bagian Apa itu Program?. Untuk saat ini, hal yang penting untuk diketahui adalah bahwa ada berbagai jenis account executable di Solana.

Selain itu, setiap account non-executable dapat dikategorikan sebagai Data Account. Contoh Data Account meliputi:

• Associated Token Account - account yang menyimpan informasi tentang token tertentu, saldonya, dan pemiliknya (misalnya, Alice memiliki 10 USDC)
• System Account - account yang dibuat dan dimiliki oleh System Program
• Stake Account - account yang digunakan untuk mendelegasikan token kepada validator agar berpotensi memperoleh reward

Struktur Account

Account disusun menurut struct AccountInfo:

pub struct AccountInfo<'a> {
    pub key: &'a Pubkey,
    pub lamports: Rc>,
    pub data: Rc>,
    pub owner: &'a Pubkey,
    pub rent_epoch: Epoch,
    pub is_signer: bool,
    pub is_writable: bool,
    pub executable: bool,
}

Account diidentifikasi berdasarkan alamatnya (key), yaitu public key unik sepanjang 32 byte.

Field lamports menyimpan jumlah lamport yang dimiliki account ini. Satu lamport adalah satu per satu miliar SOL, yaitu token native Solana.

data mengacu pada array byte data mentah yang disimpan oleh account ini. Field ini dapat menyimpan apa pun, mulai dari metadata aset digital hingga saldo token, dan dapat diubah oleh program.

Field owner berisi pemilik account ini, yang direpresentasikan oleh alamat program account. Ada beberapa aturan terkait kepemilikan account:

• Hanya pemilik account yang dapat mengubah datanya dan menarik lamport
• Siapa pun dapat menyetor lamport ke dalam account
• Pemilik account dapat mengalihkan kepemilikan kepada pemilik baru, asalkan data account direset menjadi nol

Field is_signer adalah nilai boolean yang menunjukkan apakah sebuah transaction telah ditandatangani oleh pemilik account terkait. Dengan kata lain, field ini memberi tahu program yang terlibat dalam transaction apakah account tersebut merupakan signer. Menjadi signer berarti account tersebut memiliki private key yang sesuai dengan public key dan berwenang menyetujui transaction yang diajukan.

Field is_writable adalah nilai boolean yang menunjukkan apakah data account dapat diubah. Solana memungkinkan transaction menetapkan account sebagai read-only untuk mendukung pemrosesan paralel. Runtime memungkinkan account read-only diakses secara bersamaan oleh program yang berbeda, sedangkan potensi konflik penulisan pada account writable ditangani menggunakan urutan pemrosesan transaction. Hal ini memastikan hanya transaction yang tidak berkonflik yang diproses secara paralel.

Field executable adalah nilai boolean yang menunjukkan apakah sebuah account dapat memproses instruction. Ya, ini berarti program disimpan di dalam account, dan kami akan membahasnya lebih lanjut di bagian berikutnya. Namun, pertama-tama kita perlu membahas konsep rent.

Field rent_epoch menunjukkan epoch berikutnya ketika account ini harus membayar rent. Sebuah epoch adalah jumlah slot selama jadwal leader berlaku. Tidak seperti file tradisional dalam sistem operasi, account di Solana memiliki masa aktif yang dinyatakan dalam jumlah lamport. Gagasan bahwa keberadaan berkelanjutan sebuah account bergantung pada saldo lamport membawa kita pada konsep rent.

Rent

Rent adalah biaya penyimpanan yang dikenakan untuk mempertahankan account di Solana dan memastikan account tetap berada dalam memori validator. Penagihan rent dinilai berdasarkan epoch, yaitu unit waktu yang ditentukan oleh slot ketika jadwal leader berlaku. Berikut cara kerja rent:

• Penagihan Rent - rent ditagih sekali setiap epoch. Rent juga dapat ditagih ketika sebuah account dirujuk oleh transaction
• Distribusi Rent - sebagian rent yang ditagih dibakar, yang berarti dihapus secara permanen dari peredaran. Sisanya didistribusikan kepada vote account setelah setiap slot
• Pembayaran Rent - jika account tidak memiliki cukup lamport untuk membayar rent, datanya akan dihapus dan alokasi account dibebaskan melalui proses yang dikenal sebagai garbage collection
• Pembebasan Rent - account dapat dibebaskan dari rent jika mempertahankan saldo minimum yang setara dengan pembayaran rent selama dua tahun. Semua account baru harus memenuhi ambang pembebasan rent ini, yang bergantung pada ukuran account
• Pengambilan Rent - pengguna dapat menutup account untuk mendapatkan kembali sisa lamport. Hal ini memungkinkan pengguna mengambil kembali rent yang tersimpan dalam account

Rent dapat diperkirakan menggunakan endpoint RPC getMinimumBalanceForRentExemption untuk ukuran account tertentu. Test Drive menyederhanakan proses ini dengan menerima panjang data account dalam usize. Subperintah rent pada CLI Solana juga dapat digunakan untuk memperkirakan jumlah minimum SOL agar sebuah account dibebaskan dari rent. Sebagai contoh, saat artikel ini ditulis, menjalankan perintah solana rent 20000 akan menghasilkan Rent-exempt minimum: 0.14009088 SOL.

Alamat di Solana

Sebenarnya ada dua “jenis” alamat di Solana. Solana menggunakan ed25519, sebuah skema tanda tangan EdDSA yang menggunakan SHA-512 (SHA-2) dan kurva eliptik Curve22519, untuk membuat alamat. Hal ini menghasilkan public key 32 byte yang berfungsi sebagai format alamat utama. Public key tersebut dapat digunakan secara langsung karena tidak di-hash.

Agar valid, sebuah alamat harus berupa titik pada kurva ed25519. Namun, tidak semua alamat harus berasal dari kurva ini. Program Derived Addresses (PDA) dibuat di luar kurva, yang berarti tidak memiliki private key terkait dan tidak dapat digunakan untuk menandatangani. PDA dibuat melalui System Program dan digunakan saat program perlu mengelola account. Bagian ini hanya dimaksudkan sebagai catatan tambahan agar Anda, sebagai pembaca, mengetahui berbagai jenis alamat di Solana. Kami akan membahas PDA dalam artikel mendatang.

Apa perbedaan account di Solana dengan account di Ethereum?

Ethereum memiliki dua jenis account utama: externally owned account (EOA) dan contract account. EOA dikendalikan oleh private key, sedangkan contract account diatur oleh kode contract dan tidak dapat memulai transaction sendiri.

EOA dan contract account menggunakan struktur account yang sama:

• Saldo - setiap account memiliki saldo yang diukur dalam Ether
• Nonce - untuk EOA, ini adalah jumlah transaction yang dikirim dari account. Untuk contract, ini adalah jumlah contract yang dibuat oleh account
• Storage Root - hash 256-bit dari root node sebuah Merkle Patricia Trie, yang merupakan encoding dari konten penyimpanan account
• CodeHash - hash kode Ethereum Virtual Machine (EVM) dari contract. Nilai ini tidak dapat diubah, yang berarti kode tidak berubah setelah dibuat meskipun state-nya dapat berubah. Perlu dicatat bahwa ada pengecualian untuk upgrade contract di Ethereum, seperti penggunaan pola proxy, tetapi hal ini berada di luar cakupan artikel. Untuk EOA, nilai ini adalah hash dari string kosong karena EOA tidak berisi kode

Solana menggunakan model account yang lebih seragam, dengan setiap account berpotensi menjadi program. Pemisahan kode dan data menciptakan lingkungan yang lebih efisien dan fleksibel. Program Solana bersifat stateless dan berinteraksi dengan berbagai data account tanpa deployment berulang. Hal ini sangat menguntungkan bagi aplikasi keuangan terdesentralisasi (DeFi), ketika pengguna ingin berinteraksi dengan beberapa protokol tanpa memindahkan aset ke berbagai program. Sebaliknya, model pemrograman Ethereum menggabungkan kode dan state menjadi satu entitas. Hal ini membuat interaksi lebih kompleks dan berpotensi lebih mahal karena kebutuhan gas untuk mengubah state.

Account Solana sebelumnya harus membayar rent sehingga perlu mempertahankan saldo minimum agar tetap aktif. Hal ini memastikan account yang tidak digunakan atau kekurangan dana pada akhirnya diambil kembali oleh jaringan, sehingga mengurangi pembengkakan state. Pembaruan terbaru membuat tidak ada lagi account yang membayar rent di mainnet—account harus dibebaskan dari rent. Sebagai perbandingan, Ethereum menggunakan gas untuk mengelola alokasi sumber daya. Dalam model ini, penyimpanan contract tetap ada tanpa batas waktu kecuali dihapus secara eksplisit. Pendekatan Solana menawarkan struktur biaya penyimpanan state yang lebih dapat diprediksi, sedangkan biaya Ethereum dapat berubah-ubah dan menjadi sangat mahal saat jaringan padat.

Di bagian berikutnya, kita akan mempelajari cara Solana memisahkan logika program dari state. Dibandingkan dengan model pemrograman Ethereum, Anda akan melihat bagaimana pendekatan modular ini mendukung operasi on-chain yang lebih efisien sekaligus memberikan struktur biaya yang transparan dan dapat diprediksi bagi developer.

Apa itu program Solana?

Program adalah account executable yang dimiliki oleh BPF Loader. Program dijalankan oleh Solana Runtime, yang dirancang untuk memproses transaction dan logika program.

Salah satu ciri khas model pemrograman Solana adalah pemisahan kode dan data. Program bersifat stateless, yang berarti tidak menyimpan state secara internal. Sebaliknya, semua data yang perlu dioperasikan disimpan dalam account terpisah, yang diteruskan ke program melalui referensi dalam transaction. Desain ini memungkinkan satu deployment program generik berinteraksi dengan berbagai account.

Program di Solana memiliki kemampuan untuk:

• Memiliki account tambahan
• Membaca dari atau menambahkan saldo ke account lain
• Mengubah data atau mengurangi saldo account yang dimilikinya

Ada dua jenis program:

• Program On-chain - program yang ditulis pengguna dan di-deploy di Solana. Program ini dapat di-upgrade oleh upgrade authority-nya, yang biasanya merupakan account yang men-deploy program
• Program Native - program yang terintegrasi ke inti Solana. Program ini menyediakan fungsionalitas dasar yang diperlukan agar validator dapat beroperasi. Program native hanya dapat di-upgrade melalui pembaruan software di seluruh jaringan. Contoh umumnya meliputi System Program, BPF Loader Program, dan Vote Program.

Program on-chain dan native dapat dipanggil oleh pengguna maupun program lain. Perbedaan utamanya terletak pada mekanisme upgrade: program on-chain dapat di-upgrade oleh upgrade authority-nya, sedangkan program native hanya dapat di-upgrade sebagai bagian dari pembaruan cluster.

Solana Labs mengelola sekelompok program on-chain pilihan yang dikenal sebagai Solana Program Library. Library ini mendukung berbagai operasi on-chain, termasuk peminjaman token dan pembuatan stake pool. Sebagai contoh, Associated Token Account Program menetapkan standar dan mekanisme untuk menghubungkan wallet pengguna ke token account masing-masing. Selain itu, SPL bersifat dinamis. Program seperti Token-2022 membangun di atas dan memperluas fungsionalitas yang disediakan oleh Token Program.

Pengembangan program di Solana biasanya dilakukan menggunakan Rust dengan bantuan Anchor, framework opinionated yang menyederhanakan pembuatan program dengan mengurangi boilerplate serta merampingkan serialisasi dan deserialisasi. Meskipun Rust lebih disukai, developer tidak dibatasi untuk menggunakannya—C, C++, dan bahasa apa pun yang menargetkan backend BPF LLVM (yaitu komponen LLVM yang memungkinkan kompilasi program menjadi bytecode BPF) dapat digunakan. Perkembangan terbaru dari Solang dan Neon Labs memungkinkan developer menggunakan Solidity dalam pengembangan program.

Program biasanya dikembangkan dan diuji di Localhost dan Devnet sebelum di-deploy ke Testnet atau Mainnet Beta. Developer dapat men-deploy program melalui Solana CLI dengan perintah solana program deploy <path to program>. Setelah dikompilasi menjadi ELF shared object yang berisi bytecode BPF, program diunggah ke cluster Solana yang ditentukan. Program yang telah di-deploy berada dalam account yang ditandai sebagai executable, dengan alamat account sebagai program_id.

Awalnya, program di Solana di-deploy dengan account berukuran dua kali ukuran program. Pembaruan Solana 1.16 memperkenalkan dukungan untuk account yang dapat diubah ukurannya guna memberikan fleksibilitas dan alokasi sumber daya yang lebih baik bagi developer. Kini, developer dapat men-deploy program dengan account yang lebih kecil, lalu memperbesar ukurannya di kemudian hari.

Seperti disebutkan di atas, program dianggap stateless karena semua data yang berinteraksi dengannya disimpan dalam account terpisah yang diteruskan sebagai referensi. Semua program memiliki satu entry point tempat pemrosesan instruction berlangsung, yang menerima program_id, array account, dan data instruction sebagai array byte. Program dijalankan oleh Solana Runtime setelah dipanggil oleh transaction.

Apa itu transaction?

Transaction merupakan tulang punggung aktivitas on-chain. Transaction berfungsi sebagai mekanisme untuk memanggil program dan menerapkan perubahan state. Transaction di Solana adalah sekumpulan instruction yang memberi tahu validator tindakan apa yang harus dilakukan, pada account mana, dan apakah mereka memiliki izin yang diperlukan untuk melakukannya.

Sebuah transaction terdiri dari tiga bagian utama:

• Array account untuk dibaca atau ditulis
• Satu atau beberapa instruction
• Satu atau beberapa tanda tangan

Transaction di Solana mengikuti struct Transaction. Struct ini menyediakan informasi yang diperlukan jaringan untuk memproses dan memvalidasi tindakan. Definisinya adalah sebagai berikut:

pub struct Transaction {
    pub signatures: Vec,
    pub message: Message,
}

Field signatures berisi sekumpulan tanda tangan yang sesuai dengan Message yang telah diserialisasi. Setiap tanda tangan dikaitkan dengan account key dari daftar account_keys milik Message, dimulai dari pembayar biaya. Pembayar biaya adalah account yang bertanggung jawab menanggung biaya transaction yang timbul saat transaction diproses. Biasanya, ini adalah account yang memulai transaction. Jumlah tanda tangan yang diperlukan sama dengan num_required_signatures, yang ditentukan dalam MessageHeader milik message.

message itu sendiri adalah struct bertipe Message. Definisinya adalah:

pub struct Message {
    pub header: MessageHeader,
    pub account_keys: Vec,
    pub recent_blockhash: Hash,
    pub instructions: Vec,
}

header milik message berisi tiga integer 8-bit unsigned: jumlah tanda tangan yang diperlukan (yaitu num_required_signatures), jumlah signer read-only, dan jumlah non-signer read-only.

Field account_keys mencantumkan semua alamat account yang terlibat dalam transaction. Account yang meminta akses read-write dicantumkan terlebih dahulu, lalu diikuti account read-only.

recent_blockhash adalah blockhash terbaru yang berisi hash SHA-256 sepanjang 32 byte. Field ini diperlukan untuk menunjukkan kapan client terakhir kali mengamati ledger dan berfungsi sebagai masa berlaku transaction terbaru. Validator akan menolak transaction dengan blockhash lama. Selain itu, penyertaan blockhash terbaru membantu mencegah transaction duplikat karena setiap transaction yang sepenuhnya identik dengan transaction sebelumnya akan ditolak. Jika karena alasan tertentu sebuah transaction perlu ditandatangani jauh sebelum dikirimkan ke jaringan, nonce transaction tahan lama dapat digunakan sebagai pengganti blockhash terbaru untuk memastikan transaction tersebut unik.

Field instructions berisi satu atau beberapa struct CompiledInstruction, yang masing-masing menentukan tindakan tertentu yang harus dilakukan oleh validator jaringan.

Instruction

Instruction adalah arahan untuk satu pemanggilan program Solana. Instruction merupakan unit logika eksekusi terkecil dalam program dan berfungsi sebagai unit operasional paling dasar di Solana. Program menafsirkan data yang diteruskan dari instruction dan beroperasi pada account yang ditentukan. Struct Instruction didefinisikan sebagai:

pub struct Instruction {
    pub program_id: Pubkey,
    pub accounts: Vec,
    pub data: Vec,
}

Field program_id menentukan public key dari program yang akan dijalankan. Ini adalah alamat program yang akan memproses instruction. Pemilik account program, yang ditunjukkan oleh public key ini, menentukan loader yang bertanggung jawab untuk menginisialisasi dan menjalankan program. Loader menandai program Solana Bytecode Format (SBF) on-chain sebagai executable setelah di-deploy. Runtime Solana akan menolak setiap transaction yang mencoba memanggil account yang tidak ditandai sebagai executable.

Field accounts mencantumkan account yang dapat dibaca atau ditulis oleh instruction. Account tersebut harus diberikan sebagai nilai AccountMeta. Setiap account yang datanya dapat diubah oleh instruction harus ditetapkan sebagai writable; jika tidak, transaction akan gagal. Hal ini karena program tidak dapat menulis ke account yang bukan miliknya atau tidak memiliki izin yang diperlukan. Aturan ini juga berlaku untuk perubahan lamport sebuah account: mengurangi lamport dari account yang tidak dimiliki program akan menyebabkan transaction gagal, sedangkan menambahkan lamport ke account mana pun diizinkan. Field accounts juga dapat menentukan account yang tidak dibaca atau ditulis oleh program. Hal ini dilakukan untuk memengaruhi penjadwalan eksekusi program oleh runtime, tetapi account tersebut akan diabaikan dalam konteks lainnya.

data adalah vektor serbaguna berisi integer 8-bit unsigned yang berfungsi sebagai input yang diteruskan ke program. Field ini sangat penting karena berisi instruction ter-encode yang akan dijalankan program.

Solana tidak bergantung pada format data instruction tertentu. Namun, Solana memiliki dukungan serialisasi bawaan melalui bincode dan borsh (Binary Object Representation Serializer for Hashing). Serialisasi adalah proses mengubah struktur data kompleks menjadi rangkaian byte datar yang dapat dikirim atau disimpan. Pemilihan cara encoding data harus mempertimbangkan overhead decoding karena seluruh proses berlangsung on-chain. Serialisasi Borsh sering lebih dipilih daripada bincode karena memiliki spesifikasi stabil, implementasi JavaScript, dan umumnya lebih efisien.

Program menggunakan fungsi helper untuk menyederhanakan pembuatan instruction yang didukung. Sebagai contoh, System Program menyediakan fungsi helper untuk membuat instruction SystemInstruction::Assign:

pub fn assign(pubkey: &Pubkey, owner: &Pubkey) -> Instruction {
    let account_metas = vec![AccountMeta::new(*pubkey, true)];
    Instruction::new(
        system_program::id(),
        &SystemInstruction::Assign { owner: *owner },
        account_metas,
    )
}

Fungsi ini membuat instruction yang, ketika diproses, akan mengubah pemilik account yang ditentukan menjadi pemilik baru yang diberikan.

Satu transaction dapat berisi beberapa instruction, yang dijalankan secara berurutan dan atomik sesuai urutan pencantumannya. Artinya, semua instruction berhasil atau tidak satu pun berhasil. Ini juga berarti bahwa urutan instruction dapat menjadi sangat penting. Program harus diperkuat agar dapat memproses setiap kemungkinan urutan instruction dengan aman untuk mencegah potensi eksploitasi.

Sebagai contoh, selama deinisialisasi, sebuah program mungkin mencoba menonaktifkan account dengan menetapkan saldo lamport-nya menjadi nol. Hal ini mengasumsikan bahwa runtime Solana akan menghapus account tersebut. Asumsi ini valid di antara transaction, tetapi tidak valid di antara instruction atau Cross-Program Invocation (kami akan membahas Cross-Program Invocation dalam artikel mendatang). Program harus secara eksplisit mengosongkan data account untuk melindungi diri dari potensi kelemahan dalam proses deinisialisasi ini. Jika tidak, penyerang dapat mengeluarkan instruction berikutnya untuk mengeksploitasi penghapusan yang diasumsikan, misalnya dengan menggunakan kembali account tersebut sebelum transaction selesai.

Apa itu transaction berversi?

Transaction di Solana menggunakan standar IPv6 Maximum Transmission Unit (MTU) untuk menjamin transmisi data yang cepat dan andal di seluruh cluster. Networking stack Solana menggunakan ukuran MTU konservatif sebesar 1280 byte. Setelah ruang untuk header disisihkan, tersedia 1232 byte untuk data packet. Oleh karena itu, ukuran transaction Solana dibatasi hingga nilai ini.

Batasan ukuran ini mendukung berbagai peningkatan jaringan, tetapi juga membatasi kompleksitas operasi yang dapat dilakukan dalam satu transaction. Karena setiap alamat account menggunakan ruang penyimpanan 32 byte, sebuah transaction dapat menyimpan hingga 35 account tanpa instruction. Pembatasan ini menimbulkan tantangan bagi kasus penggunaan yang memerlukan lebih dari 35 account tanpa tanda tangan dalam satu transaction.

Untuk mengatasinya, diperkenalkan format transaction baru yang mendukung beberapa versi format transaction. Runtime Solana saat ini mendukung dua versi transaction:

• legacy - format transaction asli
• 0 (Versi 0) - format transaction terbaru yang mencakup dukungan untuk Address Lookup Table

Versi 0 dirilis untuk mendukung Address Lookup Table (ALT). Pada dasarnya, ALT menyimpan alamat account dalam struktur data seperti tabel secara on-chain. Tabel ini merupakan account terpisah yang menyimpan alamat account dan memungkinkannya dirujuk dalam transaction menggunakan indeks u8 sebesar 1 byte. Hal ini secara signifikan mengurangi ukuran transaction karena setiap account yang disertakan hanya perlu menggunakan 1 byte, bukan 32 byte. ALT sangat berguna untuk operasi kompleks yang melibatkan banyak account, seperti yang umum ditemukan dalam aplikasi DeFi.

Diagram ini diadaptasi dari bagian Transaction Berversi dalam Solana Cookbook

Istilah “transaction berversi” mengacu pada cara Solana mendukung format transaction legacy dan Versi 0. Pendekatan ini memastikan composability sekaligus mengadopsi peningkatan runtime.

Struktur Transaction Berversi

VersionedTransaction didefinisikan sebagai:

pub struct VersionedTransaction {
    pub signatures: Vec,
    pub message: VersionedMessage,
}

Field signatures adalah daftar tanda tangan dari signer transaction. Tanda tangan tersebut berfungsi untuk mengautentikasi dan menjaga integritas transaction. message adalah konten transaction yang sebenarnya. Konten ini dienkapsulasi oleh tipe VersionedMessage, sebuah wrapper enum tipis yang menangani message legacy dan Versi 0:

pub enum VersionedMessage {
    Legacy(Message),
    V0(Message),
}

Versi message ditentukan oleh bit pertama dalam proses serialisasi. Jika bit pertama ditetapkan, 7 bit sisanya digunakan untuk menentukan versi Message yang diserialisasi, dimulai dari Versi 0. Jika bit pertama tidak ditetapkan, semua byte digunakan untuk meng-encode format Message legacy. Hal ini karena ada dua struct Message dengan nama yang sama, tetapi dipisahkan ke dalam modul berbeda, yaitu legacy dan v0.

Message merepresentasikan format internal ringkas dari sebuah transaction. Format ini digunakan untuk transmisi jaringan dan manipulasi oleh runtime. Format tersebut mencakup daftar linear semua account yang digunakan instruction transaction, MessageHeader yang merinci struktur array account, blockhash terbaru, dan encoding ringkas dari instruction dalam message. Berikut struktur struct Message v0:

pub struct Message {
    pub header: MessageHeader,
    pub account_keys: Vec,
    pub recent_blockhash: Hash,
    pub instructions: Vec,
    pub address_table_lookups: Vec,
}

Perbedaan antara message legacy dan message v0 adalah penyertaan field address_table_lookups.

Mengintegrasikan Model Pemrograman dengan Alur Transaction Solana

Model pemrograman Solana terintegrasi erat dengan sistem account dan transaction-nya. Berikut hubungan antarkonsep tersebut:

• Account sebagai State - Account di Solana berfungsi sebagai wadah state untuk program. Model pemrogramannya berfokus pada perubahan data yang tersimpan dalam wadah ini sebagai respons terhadap instruction
• Instruction - Program mendefinisikan logika untuk memproses instruction yang terdapat dalam transaction. Instruction ini adalah komponen tindakan yang berinteraksi dengan data account
• Serialisasi dan Pemrosesan - Saat sebuah transaction diserialisasi, instruction program menentukan perubahan pada state account. Proses serialisasi mengikuti desain program, baik yang menggunakan format transaction legacy maupun Versi 0
• Atomicity - Model pemrograman Solana memastikan pemrosesan instruction secara atomik. Program harus dirancang untuk menangani transaction bersamaan dengan aman dan efisien
• Skalabilitas - Model pemrograman Solana mendukung skalabilitas melalui fitur seperti Address Lookup Table (ALT). Tabel ini mengurangi ukuran transaction dan meningkatkan jumlah account yang dapat dirujuk oleh transaction

Model pemrograman Solana bukan sekadar tentang menulis kode, tetapi juga memahami cara kode tersebut berinteraksi dalam ekosistem yang lebih luas. Account sangat penting bagi model ini karena menjadi sarana utama penyimpanan dan perubahan data di jaringan. Transaction memungkinkan aktivitas on-chain dengan memberi tahu validator data apa yang perlu dibuat, diperbarui, atau dihapus. Pemahaman menyeluruh tentang aspek-aspek ini sangat penting bagi developer untuk membangun aplikasi yang dioptimalkan bagi performa dan sinergi dalam ekosistem Solana.

Kesimpulan

Selamat! Dalam artikel ini, kita telah menelusuri kompleksitas arsitektur sistem Solana dan mendalami konsep cluster sebagai heap data monolitik. Kita telah mengetahui bagaimana heap ini diatur menjadi wilayah memori terpisah yang dikenal sebagai account, yang membentuk tulang punggung model pemrograman Solana. Account menyimpan semuanya, mulai dari token pengguna hingga program yang menentukan perilaku jaringan, dan semuanya diubah melalui transaction.

Bagi developer, memahami pendekatan Solana terhadap komputasi terdesentralisasi sangatlah penting. Memahami seluk-beluk account, program, dan transaction diperlukan untuk membangun aplikasi yang memanfaatkan kemampuan Solana sepenuhnya. Ini berarti memahami sistem tempat kode dipisahkan dari state. Hasilnya adalah program stateless yang berinteraksi dengan data melalui account pada tingkat composability dan kemampuan upgrade yang belum pernah ada sebelumnya.

Bagi investor maupun pengguna biasa, memahami bagaimana desain Solana menciptakan ekosistem yang tangguh, fleksibel, dan efisien sangat penting untuk menilai kelayakan platform ini serta kemampuannya mendorong aplikasi inovatif yang hanya mungkin diwujudkan di Solana.

Jika Anda sudah membaca sejauh ini, anon, terima kasih! Siap mempelajari lebih dalam? Bergabunglah dengan Discord kami untuk mulai memprogram di Solana hari ini.

Sumber Daya Tambahan / Bacaan Lebih Lanjut

• Panduan Baris Perintah Solana
• Wiki Solana - Model Account
• Pengantar Account Abstraction
• Garbage Collection
• Address Lookup Table (ALT)
• Transaction Berversi
• Crate solana_sdk