Model Akun Solana: Panduan Teknis

Panduan Teknis Model Akun Solana ini menjelaskan kolom runtime dan aturan akses yang diandalkan oleh program, termasuk kepemilikan, akun eksekusi, akun token, pengabaian sewa, Alamat Turunan Program, Akun Token Terkait, dan Invokasi Lintas Program.

Detail implementasi seperti penanganan sewa, batas ukuran akun, dan API klien dapat berubah. Pengembang harus memeriksa dokumentasi Solana saat ini dan menanyakan parameter jaringan saat ini sebelum melakukan deployment.

Setiap transaksi di Solana menyentuh sebuah akun. Setiap token yang Anda pegang, setiap program yang Anda deploy, setiap NFT yang Anda mint: semuanya berada di dalam akun. Sebelum Anda menulis satu baris kode Solana, memahami cara kerja akun bukanlah pengetahuan latar belakang opsional. Ini adalah prasyarat untuk segalanya.

Anggap Solana sebagai lemari arsip. Setiap laci menampung sebuah map, dan setiap map memiliki label (alamatnya), isi (datanya), stempel saldo, dan nama departemen di sampulnya yang menunjukkan program mana yang berwenang untuk mengedit apa yang ada di dalamnya. Baik Anda seorang pengembang yang bermigrasi dari Ethereum, seorang peneliti yang mengevaluasi arsitektur Solana, atau seorang siswa yang membentuk model mental pertama tentang manajemen status on-chain, panduan ini mencakup gambaran lengkap: anatomi akun, jenis akun, aturan kepemilikan, mekanisme sewa, Alamat Turunan Program, perbandingan berdampingan dengan Ethereum, dan anotasi kode untuk pembangunan dalam praktik.

Ikhtisar Panduan Teknis Model Akun Solana

Model Akun Solana adalah arsitektur penyimpanan data dan manajemen status dari blockchain Solana. Setiap bagian status di Solana, termasuk saldo token, logika program, data pengguna, dan konfigurasi sistem, disimpan dalam akun diskrit yang diidentifikasi oleh kunci publik unik 256-bit. Lihat dokumentasi akun resmi Solana) untuk spesifikasi kanonik.

Setiap bagian status di Solana berada dalam sebuah akun. Program tidak menyimpan datanya sendiri; mereka membaca dan menulis ke akun yang diteruskan kepada mereka selama eksekusi. Keputusan arsitektur tunggal ini memisahkan desain Solana dari sebagian besar blockchain lainnya.

Analogi lemari arsip memetakan langsung ke struktur data: lemari adalah blockchain Solana, map adalah akun, label setiap map adalah kunci publiknya (alamat on-chain), isi setiap map adalah kolom data, stempel saldo adalah kolom lamports, dan stempel departemen di sampulnya adalah kolom pemilik yang mencatat program mana yang memiliki otorisasi tulis. Hanya departemen yang disebutkan pada stempel itu yang dapat mengubah apa yang ada di dalamnya.

Jika Anda berasal dari Ethereum, perbedaan ini penting: kontrak pintar Ethereum menyimpan statusnya sendiri secara internal, sedangkan program Solana bersifat stateless. Perbandingan lengkap ada di bagian khusus di bawah ini.

Anatomi Akun Solana

Setiap akun Solana, baik yang menyimpan SOL, kode program, atau status aplikasi, dibangun dari lima kolom yang sama.

Lima Kolom Setiap Akun Solana

Setiap akun di Solana memiliki tepat lima kolom, masing-masing dengan fungsi yang berbeda. Memahami kolom-kolom ini dalam istilah sederhana sebelum memeriksa kode akan membuat detail teknis jauh lebih mudah dipahami.

lamports: saldo SOL untuk akun ini, dinyatakan dalam Lamports (denominasi terkecil Solana, dijelaskan di bagian berikutnya). Dalam analogi lemari arsip, ini adalah nilai moneter yang tercetak di sampul map.

data: larik byte mentah (Vec<u8>) yang menyimpan status apa pun yang dibutuhkan oleh program yang memiliki. Untuk akun program, kolom ini berisi bytecode BPF yang dikompilasi. Untuk akun data, kolom ini berisi status aplikasi yang diserialisasi. Program mendefinisikan format serialisasi mereka sendiri (umumnya Borsh) untuk membaca dan menulis data terstruktur ke kolom ini. Padanan lemari arsip adalah isi fisik di dalam map.

owner: kunci publik program yang berwenang untuk memodifikasi kolom data akun ini. Tidak ada program lain yang dapat menulis ke dalamnya. Ini adalah stempel departemen di sampul map.

executable: bendera boolean. Ketika diatur ke true, akun menyimpan kode program dan dapat dieksekusi. Ketika false, akun adalah wadah data.

rent_epoch: kolom warisan yang sebelumnya melacak waktu pengumpulan sewa. Kolom ini sedang dihapus dan tidak memiliki signifikansi operasional untuk akun yang bebas sewa, yang merupakan standar produksi.

Setiap akun Solana diidentifikasi oleh kunci publik unik 256-bit yang berasal dari pasangan kunci ed25519, yang berfungsi sebagai alamat dan pengenal on-chain-nya. Ukuran kolom data maksimum untuk satu akun adalah 10 MB setelah peningkatan protokol baru-baru ini; verifikasi batas saat ini dengan dokumentasi akun Solana,) karena nilai ini telah berubah sepanjang sejarah Solana.

Lamports: Satuan Terkecil Solana

Lamport adalah denominasi SOL terkecil: 1 SOL sama dengan 1.000.000.000 Lamports (10⁹). Satuan ini dinamai dari Leslie Lamport, seorang ilmuwan komputer yang karyanya pada sistem terdistribusi dan toleransi kesalahan mendasari banyak teori komputasi terdistribusi modern. Lamports ada karena semua aritmatika on-chain, termasuk perhitungan sewa, biaya transaksi, dan saldo akun, harus menggunakan aritmatika bilangan bulat untuk menghindari kesalahan presisi floating-point. Menyatakan nilai dalam Lamports membuat setiap perhitungan menjadi tepat.

Apakah Akun Solana Sama dengan Dompet?

Akun Solana dan wallet bukanlah hal yang sama. Apa yang Anda anggap sebagai wallet, aplikasi Phantom atau Solflare di ponsel Anda, adalah perangkat lunak off-chain yang mengelola kunci pribadi. Entitas on-chain adalah akun sistem yang menyimpan saldo SOL Anda. wallet Anda mengontrol akun sistem; itu sendiri bukanlah akun. Akun token, akun program, dan akun data tidak memiliki padanan wallet: mereka murni wadah data on-chain yang tidak direpresentasikan secara langsung oleh aplikasi konsumen wallet.

Akun Solana terbagi dalam empat kategori, masing-masing didefinisikan oleh program pemiliknya dan bendera eksekusinya.

1. Akun Sistem: dimiliki oleh Program Sistem; digunakan untuk penyimpanan SOL dan dompet pengguna
2. Akun Program: akun eksekusi yang menyimpan bytecode BPF yang dikompilasi
3. Akun Data/Status: dimiliki oleh program; menyimpan status spesifik aplikasi
4. Akun Token: akun data khusus yang dimiliki oleh Program Token SPL (dengan Akun Token Terkait sebagai sub-set kanonik)

Akun Sistem

Akun sistem dimiliki oleh Program Sistem, dan dompet pengguna adalah akun sistem. Program Sistem adalah program asli Solana yang bertanggung jawab atas tiga operasi inti: membuat akun baru (mengalokasikan ruang data on-chain), menetapkan kepemilikan akun (menetapkan kolom pemilik ke program yang ditentukan), dan mentransfer SOL antar akun. Setiap akun baru di Solana dimulai sebagai akun sistem yang dimiliki oleh Program Sistem.

Program Sistem memiliki alamat yang dikenal: 11111111111111111111111111111111 (32 angka satu dalam base58). Lihat dokumentasi Program Sistem) untuk set instruksi lengkapnya. Ketika seorang pengembang membuat akun data untuk program mereka, mereka memanggil instruksi Buat Akun Program Sistem, yang menentukan ukuran data, deposit Lamport yang bebas sewa, dan kunci publik program pemilik baru.

Akun program menyimpan bytecode BPF yang dikompilasi, bukan status (state). Bendera executable pada akun-akun ini diatur ke true. Program bersifat stateless: ketika sebuah program berjalan, ia menerima daftar akun untuk dibaca atau ditulis melalui instruksi transaksi. Program tidak memelihara status internal apa pun di antara pemanggilan. Jika Anda berasal dari Ethereum, Anda mungkin mengenal kode executable On-Chain sebagai smart contract, tetapi program Solana bekerja secara mendasar secara berbeda karena tidak membawa status milik mereka sendiri. Akun program dimiliki oleh program BPF Loader. Setelah di-deploy, akun program bersifat immutable kecuali pasangan kunci otoritas peningkatan (upgrade authority) telah ditetapkan selama deployment.

Akun Data dan Status

Akun data menampung status aplikasi yang dibaca dan ditulis oleh program selama eksekusi. Bendera executable pada akun-akun ini adalah false. Bidang data menyimpan status yang ditentukan program yang diserialisasi dengan Borsh. Contohnya termasuk Posisi peminjaman pengguna dalam protokol DeFi, metadata NFT, atau penghitung aplikasi. Program pemilik adalah satu-satunya entitas yang dapat menulis ke bidang data akun ini, sebuah aturan yang dibahas secara detail di bagian kepemilikan.

Akun Token dan Akun Token Terkait

Akun token adalah akun data yang dimiliki oleh SPL Token Program, masing-masing menyimpan Saldo dari satu token spesifik untuk satu wallet spesifik. Alamat wallet tunggal dapat menampung beberapa akun token, satu untuk setiap jenis token yang dimilikinya.

Associated Token Account (ATA) adalah akun token kanonik untuk pasangan [alamat wallet, alamat mint] tertentu. ATA diturunkan secara deterministik sebagai Program Derived Address (PDA) menggunakan alamat wallet dan alamat mint token sebagai seed. Ini memastikan setiap wallet memiliki tepat satu akun "resmi" per jenis token. ATA adalah standar yang digunakan oleh wallet seperti Phantom dan Solflare, oleh bursa, dan oleh protokol: ketika Anda menerima token di UI wallet Anda, token tersebut masuk ke ATA Anda untuk token tersebut.

Jika ATA tidak ada untuk pasangan [wallet, mint] tertentu, ATA tersebut harus dibuat sebelum token dapat diterima, dan pembuatannya memerlukan biaya Deposit Lamport yang bebas sewa (rent-exempt). Inilah sebabnya mengapa beberapa transaksi menyertakan "biaya pembuatan akun" kecil di UI wallet. Untuk spesifikasi ATA lengkap, lihat dokumentasi SPL Associated Token Account.) ATA adalah akun token, tetapi tidak setiap akun token adalah ATA, dan perbedaan ini penting saat melakukan debugging program terkait token.

Kepemilikan Akun: Bagaimana Solana Mengontrol Akses Data

Kepemilikan akun di Solana adalah mekanisme otoritas tulis, bukan konsep kepemilikan aset.

Hanya program pemilik akun yang dapat memodifikasi bidang datanya. Tidak ada program lain yang dapat menulis ke dalamnya, terlepas dari apa yang diotorisasi pengguna di tingkat transaksi. Bidang pemilik di AccountInfo menyimpan Kunci Publik dari program yang memegang otoritas ini. Program non-pemilik dapat membaca bidang data secara bebas, tetapi menulis memerlukan status sebagai pemilik yang ditunjuk.

System Program menetapkan kepemilikan selama pembuatan akun. Saat pengembang membuat akun data untuk program mereka, instruksi Create Account mengatur bidang pemilik ke Kunci Publik program mereka. Kepemilikan dapat dialihkan kembali, tetapi hanya oleh program pemilik saat ini menggunakan instruksi Assign. Tidak ada pihak eksternal yang dapat mentransfer kepemilikan secara sepihak.

Pemilik vs. Otoritas: Perbedaan Kritis

Pemilik (owner) dan otoritas adalah dua konsep yang berbeda dalam manajemen akun Solana. Pemilik adalah program yang dicatat dalam bidang pemilik akun, yang berarti program yang dapat menulis ke bidang data. Otoritas (atau penandatangan) adalah pasangan kunci yang dapat menandatangani transaksi untuk akun tersebut.

Anggap akun token sebagai contoh: Kunci Pribadi wallet Anda menandatangani transaksi (Anda adalah otoritasnya), tetapi SPL Token Program adalah pemilik akun token Anda dan merupakan satu-satunya entitas yang dapat memodifikasi Saldo token Anda di bidang data. Anda dapat mengotorisasi transaksi yang memindahkan token, tetapi penulisan aktual ke bidang data dilakukan oleh Token Program, bukan oleh Anda secara langsung. Mencampuradukkan kedua konsep ini menghasilkan sebagian besar kesalahan debugging kepemilikan akun bagi pengembang baru di Solana.

Kepemilikan dalam Praktik: Contoh DEX

Program DEX hanya dapat menulis ke akun yang dimilikinya secara langsung. Untuk mentransfer token dari akun token pengguna (dimiliki oleh SPL Token Program, bukan oleh DEX), DEX tidak dapat menulis ke akun itu secara langsung. Program dapat memanggil program lain dalam transaksi yang sama, pola yang disebut Cross-Program Invocation (CPI), yang memungkinkan DEX untuk menginstruksikan Token Program untuk memindahkan token atas nama pengguna. DEX mengirimkan CPI ke Token Program, memberikan otorisasi bertanda tangan pengguna, dan Token Program melakukan penulisan ke bidang data akun token pengguna. Inilah bagaimana model kepemilikan program meluas ke interaksi antar-program. Untuk panduan lengkap, lihat panduan Cross-Program Invocation (CPI) untuk pengembang Solana.

Sewa Akun dan Pembebasan Sewa

Sewa (rent) Solana adalah mekanisme biaya penyimpanan, bukan biaya berulang.

Sewa adalah mekanisme Solana untuk menentukan harga penyimpanan On-Chain. Setiap akun harus mempertahankan Saldo SOL minimum yang sebanding dengan ukuran datanya untuk tetap aktif On-Chain. Koreksi yang terlewatkan oleh sebagian besar konten kompetitor: sewa bukanlah biaya berulang dalam praktiknya. Standar produksi adalah pembebasan sewa (rent exemption), di mana melakukan Deposit SOL yang cukup di muka untuk menutupi sekitar dua tahun penyimpanan membuat akun tersebut bebas secara permanen dari potongan sewa apa pun. Sebagian besar akun yang di-deploy beroperasi di bawah pembebasan sewa.

Pembebasan Sewa: Standar Praktis

Pembebasan sewa adalah standar produksi untuk semua akun Solana yang di-deploy. Saldo minimum untuk pembebasan sewa adalah sekitar 6.960 Lamports dikalikan dengan ukuran data akun dalam byte, ditambah jumlah dasar sekitar 890.880 Lamports untuk akun nol-byte.

Contoh perhitungan: akun data 100-byte memerlukan sekitar 890.880 + (6.960 × 100) = 1.586.880 Lamports, atau sekitar 0,00159 SOL. Angka-angka ini adalah perkiraan dan dapat berubah. Verifikasi nilai saat ini dengan perintah Solana CLI solana rent <bytes> atau dokumentasi sewa Solana.). Perubahan yang diusulkan untuk mengubah sewa menjadi model biaya transaksi belum diaktifkan saat tulisan ini dibuat; konsultasikan dokumentasi saat ini untuk Status protokol terbaru.

Apa yang Terjadi Saat Akun Kehabisan SOL?

Pembuatan akun saat ini umumnya memerlukan pendanaan bebas sewa. Pengembang harus menanyakan persyaratan RPC saat ini alih-alih mengandalkan perilaku pengumpulan sewa lama. Inilah perilaku yang memicu kekhawatiran tentang akun yang "dihapus."

Akun yang bebas sewa tidak pernah ditutup secara otomatis oleh runtime. Akun produksi selalu didanai hingga ambang batas bebas sewa, sehingga pengumpulan sampah (garbage collection) tidak memengaruhi mereka. Menutup akun secara sengaja adalah pola yang terpisah dan disengaja: program dapat menutup akun data untuk mengklaim kembali Deposit Lamport. Dalam protokol DeFi, misalnya, menutup Posisi peminjaman melepaskan SOL yang mendanai akun data posisi tersebut kembali ke pengguna. Ini adalah pola desain protokol yang umum, bukan penghapusan paksa.

Penjelasan Program Derived Addresses (PDA)

Program Derived Address memecahkan masalah spesifik: bagaimana sebuah program dapat mengontrol akun tanpa ada orang yang memegang Kunci Pribadi yang sesuai.

Program Derived Address (PDA) adalah alamat akun yang dihasilkan secara deterministik yang diturunkan dari ID program dan satu atau lebih nilai seed menggunakan hashing SHA-256. PDA sengaja ditempatkan di luar kurva eliptik ed25519, yang berarti mereka tidak memiliki Kunci Pribadi yang sesuai. Hanya program pemilik yang dapat menandatangani transaksi untuk akun di alamat PDA. Lihat dokumentasi PDA Solana) untuk spesifikasi lengkap.

Semua alamat akun Solana biasa terletak di kurva eliptik ed25519. PDA sengaja ditempatkan di luar kurva tersebut. Properti di luar kurva bukanlah sebuah bug; ini adalah mekanisme desain yang membuat kunci privat secara matematis tidak ada. Tidak ada manusia, tidak ada dompet perangkat keras (hardware wallet), dan tidak ada sistem manajemen kunci yang dapat menghasilkan kunci privat untuk PDA karena kunci semacam itu tidak ada di kurva.

Mengapa PDA Penting: Pengawasan yang Dikontrol Program

Konsekuensi dari tidak adanya kunci privat adalah hanya program pemilik yang dapat mengotorisasi transaksi untuk PDA. Hal ini memungkinkan kustodi yang dikendalikan program secara trustless: program memegang wewenang atas akun tersebut tanpa bergantung pada manusia mana pun untuk menjaga kunci privat.

Bandingkan ini dengan akun keypair biasa, di mana siapa pun yang memegang kunci privat mengendalikan akun tersebut. Jika kunci hilang, akses pun hilang. Jika kunci dicuri, akun tersebut terkompromi. PDA sepenuhnya menghilangkan ketergantungan ini. Logika program adalah kustodiannya, yaitu kode yang dapat diaudit alih-alih seseorang.

Tiga Kasus Penggunaan PDA di Dunia Nyata

PDA muncul dalam tiga pola berulang di seluruh program Solana.

Akun escrow DEX: sebuah program bursa terdesentralisasi menyimpan token di PDA hingga kedua belah pihak dalam pertukaran memenuhi persyaratan yang dibutuhkan. Tidak ada perantara tepercaya yang memegang kunci pribadi untuk escrow. Logika program mengontrol pelepasan dana, dan tidak ada peserta yang dapat menarik dana di luar aturan protokol.

Tidak ada individu yang dapat melakukan "rug pull" pada otoritas pencetakan (mint authority) koleksi NFT. Otoritas pencetakan NFT bekerja dengan cara program Metaplex mengontrol pencetakan melalui PDA yang berasal dari alamat pencetakan. Karena tidak ada kunci privat untuk PDA ini, aturan pencetakan koleksi tersebut ditegakkan hanya oleh kode program setelah deployment.

Bagaimana sebuah program menyimpan data per-pengguna tanpa memelihara indeks terpusat? Penyimpanan status per-pengguna menggunakan PDA unik yang diturunkan dari [id_program, pubkey_pengguna]. Ini menghasilkan alamat akun yang deterministik dan spesifik pengguna untuk menyimpan skor game, posisi pinjaman, atau catatan staking pengguna tersebut. Program selalu tahu di mana menemukan data setiap pengguna.

Fungsi findProgramAddress() dan createProgramAddressSync() menemukan alamat off-curve yang valid dengan menguji alamat kandidat menggunakan bump seed yang bertambah hingga salah satunya berada di luar kurva.

Kapan Sebaiknya Menggunakan PDA?

Gunakan PDA kapan pun program Anda perlu mengontrol akun tanpa bergantung pada kunci pribadi manusia. Jika otoritas akun seharusnya adalah logika program daripada manusia, gunakanlah PDA. Aturan ini mencakup akun escrow, brankas protokol, otoritas mint, dan data apa pun yang harus dimiliki serta dikelola oleh program itu sendiri di antara banyak pengguna.

Solana vs. Ethereum: Perbandingan Model Akun

Perbedaan inti antara model akun Solana dan Ethereum adalah di mana state berada.

Di Ethereum, kontrak pintar bersifat stateful: mereka menyimpan statusnya sendiri secara internal bersama dengan kodenya. Kontrak Solidity menyimpan pemetaan dan variabel statusnya sendiri di dalam penyimpanan kontrak, yang dikelola oleh Ethereum Virtual Machine (EVM). Di Solana, program bersifat stateless; semua status berada di akun eksternal yang dibaca dan ditulis oleh program selama eksekusi. Jika Ethereum menjalankan program di EVM, Solana menggunakan runtime berbasis BPF yang mengeksekusi program terhadap akun yang dideklarasikan di awal dalam transaksi.

Pertukaran timbal balik ini berlaku di kedua arah. Model stateful Ethereum memberikan keuntungan pengalaman pengembang yang nyata: model mental yang lebih sederhana, tidak ada pengelolaan akun secara eksplisit, serta beban kognitif yang lebih rendah untuk berbagai kasus penggunaan. Seorang pengembang dapat menulis dan menyebarkan kontrak ERC-20 tanpa perlu memikirkan penentuan ukuran akun data, deposit bebas sewa (rent-exempt), atau derivasi PDA.

Model stateless Solana menukar kesederhanaan itu dengan paralelisme eksekusi dan pemisahan tanggung jawab. Deklarasi akun yang dibutuhkan oleh setiap transaksi adalah input untuk algoritma penjadwalan Sealevel, yang mengeksekusi transaksi yang tidak bertentangan secara bersamaan. Blockchain Layer-1 lainnya seperti Aptos dan Sui mengadopsi varian mereka sendiri dari pemisahan state berbasis sumber daya, masing-masing dengan profil tradeoff yang berbeda. Baik pendekatan Ethereum maupun Solana tidak secara kategoris lebih unggul; keduanya mencerminkan prioritas desain yang berbeda untuk beban kerja yang berbeda.

Mengapa Arsitektur Ini Penting: Sealevel dan Eksekusi Paralel

Program stateless bukan merupakan batasan desain; melainkan mekanisme yang memungkinkan eksekusi paralel.

Rantai kausalitas dari desain model akun ke performa bekerja sebagai berikut. Pertama, program Solana bersifat stateless. Kedua, karena program tidak membawa status, setiap transaksi harus mendeklarasikan semua akun yang akan diakses, baik akses baca maupun tulis, sebelum eksekusi dimulai. Ketiga, mesin eksekusi paralel Solana, Sealevel, menganalisis daftar akses akun ini sebelum penjadwalan. Keempat, transaksi yang mengakses himpunan akun yang tidak tumpang tindih tidak memiliki ketergantungan data satu sama lain dan dapat dieksekusi secara simultan di berbagai inti prosesor. Kelima, hasilnya adalah jaringan yang mampu memproses puluhan ribu transaksi per detik.

Anatoly Yakovenko merancang arsitektur Solana dengan pemrosesan transaksi paralel sebagai tujuan eksplisit, dan memisahkan logika program dari status akun adalah yang memungkinkan hal tersebut. Model akun bekerja selaras dengan inovasi arsitektur Solana lainnya, termasuk Bukti Sejarah (PoH), mekanisme jam kriptografis Solana. Untuk memahami bagaimana PoH berkontribusi pada throughput ini, lihat penjelasan cara kerja Bukti Sejarah dalam arsitektur Solana.

Membangun dengan Akun: Implementasi Pengembang

Setiap akun yang digunakan oleh program Solana harus dibuat, didanai, dan ditetapkan kepada pemilik sebelum program tersebut dapat membaca atau menulis ke akun tersebut.

Membuat Akun dengan System Program

Program Solana ditulis dalam Rust, sebuah bahasa pemrograman sistem, dan dikompilasi menjadi bytecode BPF sebelum penerapan. Membuat akun di Solana mengikuti langkah-langkah ini, masing-masing sesuai dengan parameter dalam instruksi Create Account milik System Program:

1. from_pubkey: akun yang mendanai pembuatan (pembayar)
2. new_account_pubkey: tentukan alamat akun baru
3. lamports: hitung jumlah saldo yang bebas biaya sewa berdasarkan ukuran data
4. space: tetapkan ukuran data dalam byte untuk dialokasikan ke akun
5. owner: tentukan kunci publik program yang akan memiliki dan menulis ke akun ini

// Buat akun data baru menggunakan System Program
let create_account_ix = system_instruction::create_account(
    &payer.pubkey(),         // from_pubkey: siapa yang mendanai akun ini
    &new_account.pubkey(),   // new_account_pubkey: alamat akun
    rent_exempt_balance,     // lamports: cukup untuk bebas dari biaya sewa
    data_size as u64,        // space: byte yang dialokasikan untuk data akun
    &program_id,             // owner: program yang mengontrol akun ini
);

Instruksi ini menetapkan kepemilikan akun. Setelah dieksekusi, hanya program di program_id yang dapat menulis ke bidang data akun ini.

Menggunakan Anchor Framework

Banyak program Solana dibangun menggunakan kerangka kerja Anchor, yang menyediakan makro terstruktur untuk mendefinisikan batasan akun dan instruksi program. Lihat dokumentasi Anchor) untuk referensi kerangka kerja lengkapnya.

// Anchor: tentukan batasan akun menggunakan makro #[derive(Accounts)]
#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,                        // buat akun ini jika belum ada
        payer = user,                // pengguna membayar Deposit bebas sewa
        space = 8 + MyData::LEN,    // diskriminator 8-byte + ukuran data
    )]
    pub my_account: Account<'info, MyData>,     // akun data baru
    #[account(mut)]
    pub user: Signer<'info>,                    // penanda tangan dan pembayar transaksi
    pub system_program: Program<'info, System>, // diperlukan untuk pembuatan akun
}

Anchor menangani boilerplate validasi akun secara otomatis, memverifikasi kepemilikan dan Status penanda tangan sebelum logika instruksi Anda berjalan. Memahami model akun yang mendasarinya tetap diperlukan saat men-debug kesalahan kepemilikan atau merancang struktur PDA, karena makro Anchor adalah abstraksi dari mekanika yang sama yang dijelaskan di sepanjang artikel ini.

Sumber Daya Arsitektur Solana Terkait

Pengembang yang mencari jalur implementasi yang lebih pendek dapat menggunakan panduan model akun yang berfokus pada pengembang; konvensi program token dibahas dalam tinjauan Solana Program Library. Halaman harga SOL dan pasar Spot SOL/USDT berkaitan dengan akses pasar, bukan kepemilikan akun atau otoritas program.

FAQ: Model Akun Solana: Panduan Teknis

Apa itu akun di Solana?

Akun Solana adalah kontainer data On-Chain yang diidentifikasi oleh Kunci Publik 256-bit yang unik. Setiap akun menyimpan Saldo SOL dalam Lamports, bidang data (array byte yang menampung status program atau bytecode), bidang pemilik (Kunci Publik dari program yang berwenang untuk memodifikasi data), dan bendera executable yang menunjukkan apakah akun tersebut menyimpan kode program.

Bagaimana perbedaan model akun Solana dengan Ethereum?

Di Ethereum, smart contract menyimpan statusnya sendiri secara internal bersama kodenya. Di Solana, program bersifat stateless; semua status berada di akun eksternal yang dibaca dan ditulis oleh program selama eksekusi. Pemisahan ini memungkinkan runtime Sealevel Solana untuk mendeteksi pola akses akun yang tidak tumpang tindih dan mengeksekusi beberapa transaksi secara bersamaan, memungkinkan pemrosesan paralel dalam skala besar.

Apa itu sewa (rent) di Solana?

Semua akun Solana produksi didanai hingga ambang batas bebas sewa, menjadikannya bebas dari biaya penyimpanan secara permanen. Sewa adalah mekanisme yang mendasarinya: akun harus mempertahankan Saldo SOL minimum yang proporsional dengan ukuran data mereka untuk tetap aktif On-Chain. Akun bebas sewa, yaitu yang didanai di atas ambang batas tersebut, tidak pernah ditutup secara otomatis oleh runtime.

Apa itu Program Derived Address (PDA)?

Program Derived Address (PDA) adalah alamat akun yang dibuat secara deterministik yang diturunkan dari ID program dan nilai seed menggunakan hashing SHA-256. PDA berada di luar kurva elips ed25519, sehingga tidak memiliki Kunci Pribadi yang sesuai. Hanya program pemilik yang dapat menandatangani transaksi untuk akun di alamat PDA, memungkinkan kustodi terkontrol program yang trustless untuk akun escrow, otoritas Mint, dan penyimpanan status per pengguna.

Bisakah akun Solana dihapus?

Pembuatan akun saat ini umumnya membutuhkan pendanaan bebas sewa. Pengembang harus menanyakan persyaratan RPC saat ini alih-alih mengandalkan perilaku pengumpulan sewa lama. Akun produksi yang diterapkan dengan benar selalu didanai hingga ambang batas bebas sewa dan tidak pernah dihapus secara otomatis. Program juga dapat menutup akun dengan sengaja untuk mengambil kembali Deposit SOL, sebuah pola umum dalam protokol DeFi.

Apa itu Lamports?

Lamports adalah denominasi terkecil dari SOL di Blockchain Solana: 1 SOL sama dengan 1.000.000.000 Lamports (10⁹). Dinamakan setelah Leslie Lamport, pelopor komputasi terdistribusi, Lamports digunakan untuk semua Saldo SOL, biaya transaksi, dan perhitungan sewa On-Chain. Mendenominasikan jumlah dalam Lamports menghindari kesalahan presisi floating-point yang akan muncul dari penggunaan nilai pecahan SOL dalam aritmatika On-Chain.

Apa itu System Program di Solana?

System Program adalah program asli Solana yang bertanggung jawab atas tiga operasi inti: membuat akun baru (mengalokasikan ruang data On-Chain), menetapkan kepemilikan akun (mengatur bidang pemilik ke program tertentu), dan mentransfer SOL antar akun sistem. Setiap akun Solana baru dimulai sebagai akun sistem. Pengembang memanggil instruksi Create Account milik System Program untuk menyediakan akun data bagi program mereka.

Ada berapa jenis akun di Solana?

Ada tiga jenis utama akun Solana: (1) Akun Sistem, yang dimiliki oleh System Program dan digunakan untuk Saldo SOL dan dompet pengguna; (2) Akun Program, akun executable yang menyimpan bytecode BPF yang dikompilasi; (3) Akun Data/Status, yang dimiliki oleh program dan menyimpan status khusus aplikasi. Akun Token adalah subset khusus dari akun data yang dimiliki oleh SPL Token Program.

Poin Penting dan Langkah Selanjutnya

Model akun Solana membutuhkan lebih banyak pemikiran awal daripada model stateful Ethereum, tetapi investasi kognitif itulah yang memungkinkan eksekusi paralel.

• Setiap bagian dari status di Solana berada di dalam akun; program membaca dan menulis ke akun yang diteruskan selama eksekusi, bukan penyimpanan internal
• Setiap akun memiliki lima bidang: lamports, data, owner, executable, dan rent_epoch lama
• Hanya program pemilik yang dapat memodifikasi bidang data akun; ini adalah mekanisme kontrol akses utama Solana
• Akun produksi didanai hingga ambang batas bebas sewa dan tidak pernah dikumpulkan sampahnya secara otomatis oleh runtime
• Program Derived Address memungkinkan kustodi terkontrol program yang trustless dengan menggunakan alamat di luar kurva yang tidak memiliki Kunci Pribadi
• Runtime Sealevel Solana memparalelkan eksekusi transaksi dengan menganalisis daftar akses akun yang dideklarasikan di seluruh transaksi yang tidak berkonflik

Siap untuk membangun di atas fondasi ini? Lanjutkan dengan:

• Cara kerja program Solana: panduan pengembang untuk eksekusi stateless
• Panduan framework Anchor untuk membangun program Solana
• Cross-Program Invocation (CPI) dijelaskan: cara program Solana saling memanggil
• Cara kerja Proof of History dalam arsitektur Solana

Untuk spesifikasi protokol terbaru tentang ukuran akun, perhitungan sewa, dan perilaku runtime, konsultasikan dokumen resmi akun Solana secara langsung.