Mesin Virtual Solana (SVM) semakin banyak diadopsi sebagai lapisan eksekusi untuk berbagai solusi Layer-2 (L2). Namun, keterbatasan kunci dalam desain asli SVM adalah ketidakjelasan akar status globalnya. Hal ini menimbulkan tantangan signifikan bagi sistem rollup, di mana akar status global sangat penting untuk memastikan integritas, memungkinkan bukti kecurangan, dan mendukung operasi lintas lapisan.

Dalam rollup, pengusul mengirimkan akar status L2 (Merkle root) ke Layer-1 (L1) secara berkala, membentuk checkpoint untuk rantai L2. Checkpoint ini memungkinkan bukti inklusi untuk setiap status rekening, memungkinkan eksekusi tanpa status dari satu checkpoint ke yang lain. Bukti kecurangan bergantung pada mekanisme ini, karena peserta dapat memberikan bukti inklusi untuk memverifikasi input yang valid selama perselisihan. Selain itu, pohon Merkle meningkatkan keamanan jembatan kanonikal dengan memungkinkan pengguna menghasilkan bukti inklusi untuk transaksi penarikan, memastikan interaksi tanpa kepercayaan antara L2 dan L1.

Untuk mengatasi tantangan-tantangan ini, Jaringan SEGERAmengenalkan pohon Merkle ke lapisan eksekusi SVM, memungkinkan klien untuk menyediakan bukti inklusi. SOON terintegrasi dengan Proof-of-History dengan menggunakan entri unik untuk menyematkan akar keadaan secara langsung ke dalam blockchain berbasis SVM. Dengan inovasi ini, tumpukan SOON dapat mendukung rollup baru berbasis SVM dengan keamanan, skalabilitas, dan utilitas yang ditingkatkan.

Masalah Merklisasi Solana

Solana selalu dirancang dengan throughput tinggi sebagai tujuan inti, memerlukan trade-off desain yang disengaja — terutama selama pengembangan awalnya — untuk mencapai kinerja baru. Di antara trade-off ini, salah satu keputusan paling berdampak berkisar pada bagaimana dan kapan Solana akan merklisasi statusnya.

Pada akhirnya, keputusan ini menciptakan tantangan signifikan bagi klien dalam membuktikan keadaan global serta inklusi transaksi dan verifikasi pembayaran sederhana (SPV). Kurangnya akar keadaan yang di-hash secara konsisten yang mewakili keadaan SVM yang dimerkalakan menimbulkan kesulitan yang cukup besar bagi proyek-proyek seperti klien ringan dan rollups.

Mari kita lihat bagaimana merklisasi dilakukan di rantai lain dan kemudian mengidentifikasi tantangan yang ditimbulkan oleh arsitektur protokol Solana.

Pohon Merkle pada Bitcoin

Pada Bitcoin, transaksi disimpan dalam sebuah blok menggunakan sebuah pohon Merkle, yang akarnya disimpan di header blokProtokol Bitcoin akan menghash input dan output transaksi (serta beberapa metadata lainnya) menjadi sebuahID Transaksi(TxID). Untuk membuktikan status di Bitcoin, pengguna dapat dengan mudah menghitung bukti Merkle untuk memverifikasi TxID terhadap akar Merkle blok.

Proses verifikasi ini juga memvalidasi keadaan, karena Tx ID unik untuk beberapa set input dan output, yang keduanya mencerminkan perubahan keadaan alamat. Perhatikan bahwa transaksi Bitcoin juga bisa berisi skrip Taproot, yang menghasilkan output transaksi yang dapat diperiksa selama verifikasi, sering kali dengan menjalankan ulang skrip menggunakan input transaksi dan data saksi skrip, serta memvalidasi terhadap outputnya.

Pohon Merkle di Ethereum

Mirip dengan Bitcoin, Ethereum menyimpan transaksi menggunakan struktur data kustom (yang berasal dari pohon Merkle) yang disebut Pohon Merkle Patricia(MPT). Struktur data ini dirancang untuk pembaruan cepat dan optimisasi atas rangkaian data besar. Hal ini secara alami karena Ethereum memiliki input dan output yang jauh lebih banyak untuk dikelola daripada Bitcoin.

The Mesin Virtual Ethereum(EVM) bertindak sebagai mesin negara global. EVM pada dasarnya adalah lingkungan komputasi terdistribusi yang sangat besar yang mendukung yang dapat dieksekusismart contract, masing-masing di antaranya menyimpan ruang alamat mereka sendiri di memori global. Akibatnya, klien yang ingin memverifikasi status di Ethereum harus memperhitungkan bukan hanya hasil dari transaksi (log, kode pengembalian, dll.) tetapi juga perubahan pada status global akibat transaksi tersebut.

Beruntung, EVM menggunakan dengan cerdas tiga struktur trie penting, yang menyimpan akar mereka di setiap header blok.

• pusat data status: Sebuah toko nilai kunci raksasa dari semua keadaan di Ethereum, termasuk setiap alamat Ethereum dan data yang disimpan dalam setiap rekening. Untuk kontrak pintar, rekening-rekening ini menyimpan trie lain yang disebut sebuah penyimpanan trie, yang merupakan peta nilai kunci lain dari semua data kontrak pintar untuk ruang alamatnya.
• Trie transaksi: Penyimpanan nilai kunci dari semua transaksi dalam satu blok, di mana kuncinya adalah ID transaksi, dan nilainya adalah data transaksi.
• pohon penerimaan: Trie yang berisi tanda terima (status, peristiwa) dari setiap transaksi dalam blok, di-hash oleh indeks setiap transaksi dalam blok. Setiap tanda terima berisi informasi tentang eksekusi transaksi, termasuk hash state trie pasca-transaksi.

Diberikan sebuah transaksi, seorang klien dapat membuktikan inklusinya dalam sebuah blok dengan mengevaluasi akar trie transaksi (seperti Bitcoin), hasilnya dengan mengevaluasi trie kwitansi, dan perubahan keadaan global dengan mengevaluasi trie keadaan.

Pohon Merkle di Solana

Salah satu alasan tingginya throughput Solana adalah fakta bahwa Solana tidak memiliki struktur multi-pohon yang dimiliki oleh Ethereum. Pemimpin Solana memang melakukan perhitungan Merkle trees saat membuat blok, tetapi strukturnya berbeda dengan yang ada dalam EVM. Sayangnya, di situlah masalahnya bagi rollups berbasis SVM.

Solana memerkelisasi transaksi ke dalam yang disebut entri, dan bisa ada beberapa entri per slot; oleh karena itu, beberapa akar transaksi per blok. Selain itu, Solana menghitung akar Merkle dari status akun hanya sekali per epoch (sekitar 2.5 hari), dan akar ini tidak tersedia di ledger.

Sebenarnya, header blok Solana sama sekali tidak mengandung akar Merkle. Sebagai gantinya, mereka mengandung yang sebelumnya dan saat iniblockhash, yang dihitung melalui Solana’s Bukti SejarahAlgoritma (PoH). PoH membutuhkan validator untuk terus mendaftarkan “ticks” dengan cara secara rekursif melakukan hash pada entri blok, yang dapat kosong atau berisi transaksi-transaksi dalam jumlah besar. Tick (hash) terakhir dari algoritma PoH adalah blockhash dari blok tersebut.

Masalah dengan Proof of History adalah bahwa membuat pembuktian keadaan sangat sulit dilakukan dari sebuah blockhash. Solana dirancang untuk mengalirkan hash PoH untuk menjaga konsep waktu yang telah berlalu. Akar transaksi hanya tersedia untuk tik PoH yang berisi entri dengan transaksi, bukan seluruh blok, dan tidak ada akar keadaan yang disimpan di setiap entri.

Namun, ada hash lain yang dapat digunakan klien: hash bank. Terkadang disebut sebagai hash slot, hash bank tersedia di SlotHashes sysvarakun, yang dapat dikueri oleh klien. Sebuah hash bank dibuat untuk setiap blok (slot) dari beberapa input:

• Hash bank sebelumnya.
• Hash delta status akun.
• Jumlah tanda tangan transaksi di bank, dalam byte.
• Blockhash bank ini.
• Hanya sekali per epoch, hash dari semua akun dalam database akun.
• Hanya ketika klaster telah di-restart, sebuah hash dari setiap hard fork yang disebabkan oleh restart klaster.

Seperti yang bisa dilihat, hash bank kelebihan beban dengan beberapa input hash, yang menambah kompleksitas bagi klien yang mencoba membuktikan informasi tentang transaksi atau status. Selain itu, hanya hash bank untuk bank yang melakukan "hash akun epoch" - hash dari semua akun sekali per epoch - akan memiliki akar tertentu itu termasuk di dalamnya. Selain itu, akun SlotHashes sysvar dipotong menjadi 512 hash bank terakhir.

Solusi Merklisasi SOON

jaringan SOONadalah SVM L2 di atas Ethereum. Saat mengintegrasikan merklisasi ke DALAM, kami memberikan prioritas pada penggunaan solusi yang terbukti dan mapan demi stabilitas, daripada menciptakan kembali roda. Dalam memutuskan struktur data atau algoritma hashing yang akan digunakan, kami mempertimbangkan kompatibilitas mereka dengan kontrak L1 dari Optimism Stack, kemampuan mereka untuk terintegrasi dengan lancar ke dalam arsitektur Solana, dan apakah mereka dapat mencapai kinerja tinggi di bawah model akun Solana.

Kami menemukan bahwa seiring dengan bertambahnya jumlah akun, model penyimpanan Merkle Patricia Trie (MPT) berbasis LSM-Treeakan menghasilkan amplifikasi baca/tulis disk yang lebih banyak, mengakibatkan kerugian kinerja. Pada akhirnya, kami memutuskan untuk mengintegrasikan Erigon MPTdengan membangun dari hasil kerja Rust yang sangat baik yang dilakukan oleh rETHtim dan menambahkan dukungan untuk model akun Solana.

Arsitektur

Seperti yang disebutkan sebelumnya, trie status SOON adalah MPT yang dibangun untuk mendukung akun Solana. Oleh karena itu, kami telah menentukan tipe akun yang kompatibel dengan SVM untuk berfungsi sebagai data setiap simpul daun.

struct AkunTrieSolana {

lamports: u64,

data: Vec,

eksekutif: bool,

rent_epoch: u64,

pemilik: Pubkey,

}

Untuk mengaktifkan modul MPT untuk berlangganan status terbaru akun SVM secara real time, kami memperkenalkan pemberitahuan akun. Selama Tahap Perbankan, pemberi tahu akun menginformasikan modul MPT tentang perubahan status akun, dan MPT secara bertahap memperbarui perubahan ini dalam struktur trie.

Penting untuk dicatat bahwa modul MPT hanya memperbarui subtree-nya selama setiap 50 slot dan tidak menghitung state root di akhir setiap slot. Pendekatan ini diambil atas dua alasan. Pertama, menghitung state root setiap slot akan berdampak signifikan pada kinerja. Kedua, state root hanya diperlukan ketika proposer mengajukan outputRootke L1. Oleh karena itu, itu hanya perlu dihitung secara berkala, berdasarkan frekuensi pengajuan proposer.

outputRoot = keccak256(versi, state_root, withdraw_root, l2_block_hash)

Modul MPT SOON menjaga dua jenis struktur trie secara bersamaan: State Trie untuk status global dan Withdraw Trie untuk transaksi penarikan. Penyaji secara berkala menghasilkan outputRoot berdasarkan root status dan root penarikan, dan mengirimkannya ke L1.

Saat ini, SOON menghitung root state dan root penarikan sekali setiap 450 slot dan menambahkannya ke blockchain L2. Akibatnya, konsistensi data MPT di seluruh node lain dalam jaringan dapat dipastikan. Namun, struktur blok Solana tidak termasuk header blok, yang berarti tidak ada tempat untuk menyimpan root state. Mari kita perhatikan lebih dekat struktur dasar blockchain Solana dan kemudian jelajahi bagaimana SOON memperkenalkan UniqueEntry untuk menyimpan root state.

Blockchain Solana terdiri dari slot, yang dihasilkan oleh modul PoH. Sebuah slot berisi beberapa entri, dengan setiap entri termasuk tik dan transaksi. Pada lapisan jaringan dan penyimpanan, sebuah slot disimpan dan ditransmisikan menggunakan serpihansebagai unit terkecil. Serpihan dapat dikonversi menjadi dan dari entri.

[derive(Serialize, Deserialize, Debug, Default, PartialEq, Eq, Clone)

pub struct Entry {

Jumlah hash sejak ID Entri sebelumnya.

pub num_hashes: u64,

/// hash SHA-256num_hashessetelah ID Entri sebelumnya.

pub hash: Hash,

/// Sebuah daftar transaksi yang tidak terurut yang diamati sebelum ID Masuk

/// dihasilkan. Mereka mungkin telah diamati sebelum ID Entri sebelumnya tetapi

/// didorong kembali ke daftar ini untuk memastikan interpretasi yang ditentukan dari ledger.

transaksi pub: Vec,

}

Kami mengikuti struktur blockchain yang dihasilkan oleh PoH dan mempertahankan struktur shred, memungkinkan kami untuk menggunakan kembali lapisan penyimpanan, lapisan jaringan, dan kerangka kerja RPC Solana yang sudah ada. Untuk menyimpan data tambahan pada blockchain L2, kami memperkenalkan UniqueEntry. Sifat ini memungkinkan kami untuk menyesuaikan muatan entri dan menentukan aturan validasi independen untuk data.

pub const UNIQUE_ENTRY_NUM_HASHES_FLAG: u64 = 0x8000_0000_0000_0000;

/// Entri unik adalah jenis entri khusus. Yang berguna ketika kita perlu menyimpan beberapa data di

/// blockstore tetapi tidak ingin memverifikasinya.

///

/// Tata letak dari num_hashesadalah:

/// |…1 bit…|…63 bit…|

/// \ _ _/

/// \ \

/// flag bidang kustom

sifat pub UniqueEntry: Berukuran {

fn encode_to_entries(&self) -> Vec;

fn decode_from_entries(

entries: impl IntoIterator<Item = Entry>,

) -> Hasil;

}

pub fn unique_entry(custom_field: u64, hash: Hash) -> Entry {

Entri {

   num_hashes: num_hashes(custom_field),   hash,   transactions: vec![],

}

}

pub fn num_hashes(custom_field: u64) -> u64 {

assert!(custom_field < (1 << 63));

UNIQUE_ENTRY_NUM_HASHES_FLAG | custom_field

pub fn is_unique(entry: &Entry) -> bool {

entry.num_hashes & UNIQUE_ENTRY_NUM_HASHES_FLAG != 0

}

Dalam UniqueEntry, num_hashes digunakan sebagai tata letak bit, di mana flag bit pertama digunakan untuk membedakan antara Entri dan Unique Entry, dan 63 bit berikutnya digunakan untuk mendefinisikan tipe muatan. Bidang hash berfungsi sebagai muatan, yang berisi data kustom yang diperlukan.

Mari kita lihat contoh penggunaan tiga entri unik untuk menyimpan hash slot, akar status, dan akar penarikan.

/// Entri unik akar MPT.

[derive (Default, Debug, Klon, PartialEq, Eq)]

pub struct MptRoot {

pub slot: Slot,

pub state_root: B256,

pub penarikan akar: B256,

}

impl UniqueEntry untuk MptRoot {

fn encode_to_entries(&self) -> Vec {

let slot_entry = unique_entry(0, slot_to_hash(self.slot)); let state_root_entry = unique_entry(1, self.state_root.0.into(); let withdrawal_root_entry = unique_entry(2, self.withdrawal_root.0.into(); vec![slot_entry, state_root_entry, withdrawal_root_entry]

}

fn decode_from_entries(
entri: impl IntoIterator,
) -> Hasil {

let mut entries = entries.into_iter(); let entry = entries.next().ok_or(UniqueEntryError::NoMoreEntries)?; let slot = hash_to_slot(entry.hash); let entry = entries.next().ok_or(UniqueEntryError::NoMoreEntries)?; let state_root = B256::from(entry.hash.to_bytes()); let entry = entries.next().ok_or(UniqueEntryError::NoMoreEntries)?; let withdrawal_root = B256::from(entry.hash.to_bytes()); Ok(MptRoot { slot, state_root, withdrawal_root, })

}
}

Karena UniqueEntry mendefinisikan ulang semantik num_hashes, hal itu tidak dapat diproses selama tahap verifikasi PoH. Oleh karena itu, pada awal proses verifikasi, kami pertama-tama menyaring entri unik dan mengarahkannya ke alur verifikasi kustom berdasarkan jenis payload mereka. Entri reguler yang tersisa melanjutkan proses verifikasi PoH asli.

Penarikan dan Jembatan Asli

Jembatan asli adalah bagian penting dari infrastruktur solusi Layer 2, bertanggung jawab atas transmisi pesan antara L1 dan L2. Pesan dari L1 ke L2 disebut transaksi deposit, sementara pesan dari L2 ke L1 disebut transaksi penarikan.

Transaksi deposit biasanya ditangani oleh pipa derivasidan hanya memerlukan pengguna untuk mengirimkan satu transaksi tunggal di L1. Transaksi penarikan, bagaimanapun, lebih kompleks dan memerlukan pengguna untuk mengirimkan tiga transaksi untuk menyelesaikan proses:

1. Pertama, pengguna harus mengirim transaksi penarikan awal di L2.
2. Setelah outputRoot yang berisi transaksi penarikan awal ini dikirimkan ke L1 oleh penawar, pengguna perlu mengirimkan bukti inklusi untuk transaksi penarikan ke L1. Setelah verifikasi berhasil, periode tantangan dimulai.
3. Setelah periode tantangan berakhir, pengguna mengirimkan transaksi penyelesaian untuk menyelesaikan seluruh proses penarikan.

Bukti inklusi dari transaksi penarikan memastikan bahwa penarikan terjadi di L2, secara signifikan meningkatkan keamanan jembatan kanonikal.

Dalam OP Stack, hash transaksi penarikan pengguna disimpan dalam variabel status yang sesuai dengan OptimismePortal kontrak. Antarmuka RPC eth_getProof kemudian digunakan untuk memberi pengguna bukti penyertaan untuk transaksi penarikan tertentu.

Tidak seperti EVM, data kontrak SVM disimpan dalam bidang data akun, dan semua jenis akun ada di tingkat hirarki yang sama.

SOON telah memperkenalkan program jembatan asli: Bridge1111111111111111111111111111111111111. Setiap kali pengguna memulai transaksi penarikan, program jembatan menghasilkan indeks unik secara global untuk setiap transaksi penarikan dan menggunakan indeks ini sebagai seed untuk membuat yang baru Akun Yang Diambil Dari Program(PDA) untuk menyimpan transaksi penarikan yang sesuai.

[derive (Klon, Salin, Debug, PartialEq)]

struktur publik WithdrawalTransaction {

Penghitung penarikan

pub nonce: U256,

pengguna yang ingin menarik

pengirim pub: Pubkey,

alamat pengguna di L1

pub target: Alamat,

/// menarik jumlah dalam lamports

nilai publik: U256,

/// batas gas di L1

pub gas_limit: U256,

/// penarikan calldata di L1

pub data: L1WithdrawalCalldata,

}

Kami mendefinisikan struktur WithdrawalTransaction untuk menyimpan transaksi penarikan dalam bidang data dari PDA.

Desain ini bekerja dengan cara yang serupa dengan OP Stack. Setelah outputRoot yang berisi transaksi penarikan diserahkan ke L1, pengguna dapat mengirimkan bukti inklusi untuk transaksi penarikan ke L1 untuk memulai periode tantangan.

Bukti Kegagalan

Setelah pengusul mengirimkan outputRoot ke L1, itu menandakan bahwa status L2 telah diselesaikan. Jika penantang mendeteksi bahwa pengusul mengirimkan status yang salah, mereka dapat memulai tantangan untuk melindungi dana di jembatan.

Salah satu aspek paling kritis dalam membangun suatu bukti kesalahan adalah memungkinkan blockchain untuk beralih dari keadaan S1 ke keadaan S2 secara tanpa keadaan. Hal ini memastikan bahwa kontrak arbitrator di L1 dapat memutar ulang instruksi program secara tanpa keadaan untuk melakukan arbitrase.

Namun, pada awal proses ini, penantang harus membuktikan bahwa semua input awal dalam keadaan S1 valid. Input awal ini termasuk keadaan akun yang berpartisipasi (misalnya, lamports, data, pemilik, dll.). Berbeda dengan EVM, SVM secara alami memisahkan keadaan akun dari komputasi. Namun, Anza's SVM APImemungkinkan akun untuk dilewati ke SVM melalui sebuah ciri TransactionProcessingCallback, seperti yang ditunjukkan di bawah ini.

pub trait TransactionProcessingCallback {

fn account_matches_owners(&self, account: &Pubkey, owners: &[Pubkey]) -> Option;

fn get_account_shared_data(&self, pubkey: &Pubkey) -> Option;

fn add_builtin_account(&self, _name: &str, _program_id: &Pubkey) {}

}

Oleh karena itu, kita hanya perlu menggunakan status S1 bersama dengan bukti inklusi dari akun input untuk memverifikasi validitas input program tantangan.

Kesimpulan

SOON menandai tonggak kunci untuk pengembangan ekosistem SVM. Dengan mengintegrasikan merklisasi, SOON mengatasi kurangnya akar status global Solana, memungkinkan fitur penting seperti bukti inklusi untuk bukti kesalahan, penarikan aman, dan eksekusi tanpa status.

Selain itu, desain merklisasi SOON dalam SVM dapat memungkinkan klien ringan pada rantai berbasis SVM, meskipun Solana sendiri saat ini tidak mendukung klien ringan. Bahkan mungkin beberapa desain tersebut dapat membantu membawa klien ringan ke rantai utama juga.

Dengan menggunakan Pohon Merkle Patricia (MPT) untuk manajemen status, SOON berkolaborasi dengan infrastruktur Ethereum, meningkatkan interoperabilitas, dan memajukan solusi L2 berbasis SVM. Inovasi ini memperkuat ekosistem SVM dengan meningkatkan keamanan, skalabilitas, dan kompatibilitas, sambil mendorong pertumbuhan aplikasi terdesentralisasi.

Disclaimer:

1. Artikel ini dicetak ulang dari [ Medium]. Semua hak cipta milik penulis asli [@0xandrewzdan@realbuffalojoe]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi.
3. Tim Gate Learn menerjemahkan artikel ke dalam bahasa lain. Menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang kecuali disebutkan.