Solana Builders: ZK Compression

Properti

Sebelum mengevaluasinya dalam konteks ZK-Compression, mari kita cantumkan beberapa properti Solana yang menjadi perhatian kita:

1. Komposabilitas Atomik Sinkron
2. Konkurensi
3. Keamanan
4. Kelangsungan
5. Resistansi terhadap sensor

Asumsi Kepercayaan Awal

Kita akan menggunakan istilah "tanpa perlu kepercayaan" untuk asumsi keamanan sebuah node penuh. Definisi ini menjadi tolok ukur kita. Apa pun yang tidak dapat dilakukan sendiri oleh node penuh melibatkan asumsi kepercayaan tambahan.

Beberapa Latar Belakang

Saya akan mencoba memberikan secara singkat latar belakang yang diperlukan tentang Solana untuk memahami ZK-Compression melalui poin-poin ringkas. 

• State Solana disimpan pada disk node penuh di “AccountsDB”
• Unit penyimpanannya disebut "Akun"
• Akun memiliki alamat (masing-masing 32 byte)
• Jumlah data yang dapat disimpan sebuah akun bervariasi, antara 0 hingga 10 MB (maksimum)
• Menyimpan 10 MB di Solana memerlukan biaya sekitar 70 SOL yang dibayar oleh pembuat akun. Biaya ini terkait dengan penyimpanan, bukan jumlah akun — bisa berupa 1 akun berukuran 10 MB atau 1.000 akun berukuran 10 KB.
• Ukuran semua akun di Solana saat ini adalah 76 GB (terkompresi)
• Setiap transaksi Solana harus menentukan semua akun yang dibaca dan ditulisnya
• Transaksi Solana saat ini dibatasi hingga 1.232 byte (terdapat proposal untuk meningkatkannya)
• Setiap transaksi Solana harus menentukan sejumlah teks
  • Tanda tangan (masing-masing 64 byte)
  • Akun (masing-masing 32 byte)
  • Data instruksi (panjang bebas)
  • Blockhash terbaru (32 byte)
  • Alamat program (masing-masing 32 byte) (CPI: pemanggilan lintas program)
• Transaksi Solana menyertakan “recent blockhash” berukuran 32 byte yang harus masuk dalam 150 blok terbaru atau akan dianggap tidak valid sehingga harus ditandatangani dan dikirimkan ulang

Siklus Hidup Transaksi Normal

Saat transaksi biasanya dieksekusi, siklus hidupnya adalah sebagai berikut:

1. Pemeriksaan usia (hanya transaksi terbaru yang valid), deduplikasi, verifikasi struktur, biaya (gas), dan pemeriksaan tanda tangan dilakukan terlebih dahulu pada transaksi
2. Bytecode program dimuat berdasarkan alamat program, lalu Solana Virtual Machine (SVM) dibuat
3. Semua akun yang dirujuk oleh transaksi diperiksa, dimuat dari penyimpanan ke memori, lalu diteruskan ke SVM
4. Bytecode program dieksekusi
5. Setiap akun yang dimodifikasi disinkronkan kembali ke penyimpanan dalam state terbarunya

Motivasi utama ZK-Compression adalah:

• State on-chain mahal. Sebagai contoh, seribu akun memerlukan biaya 70 SOL, sehingga produk seperti Drip Haus cepat menjadi mahal
• Bahkan tanpa Merkelisasi state secara penuh, semakin banyak akun yang disimpan di disk berarti snapshot, indeks, dan sebagainya menjadi lebih besar
• Tidak semua akun sering diakses, sehingga tidak perlu menanggung biaya sumber daya secara berkelanjutan

Jadi, apa cara paling sederhana untuk mencapai kompresi?

Alih-alih menyimpan akun di disk dan membacanya saat diperlukan (langkah 3 dalam siklus hidup eksekusi transaksi), sebuah transaksi dapat menyertakan data akun sebagai bagian dari payload, sehingga menghemat biaya yang terkait dengan penyimpanan on-chain. Namun, hal ini memunculkan masalah baru—bagaimana Anda dapat menegakkan aturan agar pengguna tidak berbohong tentang state?

Sebagai contoh, katakanlah nilai off-chain dari akun yang menyimpan saldo token adalah 1200, dan kolom pemiliknya berisi “BYixJwV32DjeuyRww72PwZMyKcaedN533GBrv7CDh4n9”.

Jika Anda mengirimkan transaksi dengan data tersebut ke chain, bagaimana chain dapat mengetahui bahwa Anda tidak berbohong tentang jumlah token yang dimiliki alamat “BYixJwV32DjeuyRww72PwZMyKcaedN533GBrv7CDh4n9”?

Bagaimanapun, node penuh yang memproses transaksi tidak memiliki akses ke data off-chain — node tersebut mengharapkan Anda menyertakan data bersama transaksi.

Anda dapat menggunakan bukti Merkle untuk ini. Tanpa membahas bukti Merkle secara mendetail, anggaplah bukti tersebut sebagai cara untuk membuat "komitmen" terhadap sejumlah data secara terverifikasi dengan jejak penyimpanan on-chain yang kecil. Semua node penuh yang tersinkronisasi dengan chain menyimpan "komitmen" kecil tersebut. Ketika seseorang menyertakan data dalam transaksi, mereka juga dapat menyertakan "bukti" dalam transaksi yang sama untuk diverifikasi terhadap komitmen tersebut. Bukti ini aman secara kriptografis.

Apakah ada masalah dengan cara ini?

Masalahnya adalah bukti Merkle dapat berukuran besar. Jika sebuah pohon berisi 100.000 akun, ukuran bukti untuk salah satu akun tersebut adalah 17 * 32 = 544 byte. Jika Anda ingin memberikan bukti untuk beberapa akun, dalam kasus terburuk ukurannya akan dikalikan dengan ukuran bukti. Jadi, sepuluh akun dalam kasus terburuk akan memerlukan 10 * 544 = 5.440 byte. Masalah ruang ini khusus terjadi di Solana karena transaksi Solana saat ini dibatasi hingga 1.232 byte, sedangkan chain lain cenderung tidak terlalu membatasi. Lihat bagian di atas yang mencantumkan ukuran setiap komponen — program, tanda tangan, recent blockhash, dan sebagainya. Jadi, bahkan dalam kasus terbaik, Anda menggunakan setengah ukuran transaksi hanya untuk bukti Merkle. 

Ada beberapa pertanyaan yang muncul di sini.

Jika ukuran transaksi adalah 1.232 byte, bagaimana Anda mengirimkan seluruh data sebagai bagian dari transaksi?

Ini pertanyaan yang sangat bagus. ZK Compression berguna untuk jumlah akun yang sangat besar jika setiap akun berisi sedikit data. Saldo token (8 byte per token), sedikit metadata untuk NFT, dan sebagainya — data sebesar 100 byte dapat dengan mudah dimuat dalam transaksi. Data sebesar 1.000 byte sulit dimuat karena ada komponen lain yang perlu disertakan. Jika akun Anda perlu menyimpan data dalam jumlah lebih besar, metode ini (dan ZK Compression) tidak akan berfungsi.

Ada satu nuansa dalam klaim ini: logika yang sama dengan yang digunakan dalam ZK Compression dapat diterapkan pada bagian-bagian state akun. Artinya, meskipun data lengkap sebuah akun tidak dapat dimuat dalam satu payload transaksi, masih ada cara untuk mengatasinya — khususnya dengan membuat komitmen dan memberikan bukti untuk sebagian data.

Apakah bukti Merkle satu-satunya cara untuk melakukan ini?

Tidak. Bukti Merkle hanyalah salah satu jenis komitmen vektor. Ukuran komitmennya adalah 32 byte dan ukuran buktinya Log2(N) * 32 byte, dengan N sebagai ukuran vektor yang Anda jadikan komitmen. Dari sinilah kita mendapatkan angka 17 karena Log2(100000) adalah 17. Namun, ada juga komitmen dengan ukuran bukti konstan (KZG, Pedersen); bahkan, ZK-Compression menggunakan salah satu metode tersebut! 

Anda mengatakan bahwa data akun yang biasanya disimpan pada node penuh sebagai bagian dari state harus disertakan bersama transaksi. Di mana data tersebut disimpan?

Pertanyaan yang sangat bagus, dan hal ini memengaruhi asumsi kepercayaan serta properti kita. Jawabannya: di mana saja! Server RPC khusus dapat menyimpan data ini; data tersebut dapat menjadi bagian dari Filecoin atau IPFS, atau pengguna bahkan dapat menyimpannya di mesin mereka sendiri. Hal yang penting adalah selama semua elemen vektor disimpan di suatu tempat, bukti dapat dihitung saat diperlukan. Kita akan membahas implikasi lokasi penyimpanan ini pada bagian properti. 

Apakah chain lain dapat melakukan ini?

ZK-Compression secara khusus mengharuskan verifikasi zk-SNARK berbiaya rendah. Karena komputasi lebih murah daripada penyimpanan di Solana, metode ini sangat cocok digunakan. Konsep umum penggunaan komitmen vektor dan bukti untuk data yang disertakan dalam setiap transaksi juga dapat diterapkan pada chain lain. Namun, biaya komputasi yang mahal membuat pertukarannya tidak sejelas di Solana. Bahkan, biaya gas verifikasi yang terus-menerus dibandingkan dengan SSTORE satu kali justru menjadi lebih mahal pada chain berbasis EVM.

Apa itu ZK Compression?

• Jika Anda belum mengetahui apa itu ZK Compression, bagian ini akan menjelaskannya
• Jika Anda memiliki gambaran samar tentangnya, saya tetap menyarankan untuk membaca bagian ini karena ada beberapa kesalahpahaman umum
• Jika Anda tahu persis apa itu ZK Compression, saya tetap meminta Anda membacanya agar dapat mengoreksi saya jika ada yang keliru :) 

Jika Anda memahami bagian di atas, Anda telah memahami 90% tentang ZK Compression. Masalah utamanya adalah ukuran bukti Merkle. Jadi, ZK Compression pada dasarnya menggunakan suatu skema untuk membuktikan sebuah komputasi.

Jika Anda tidak tahu apa itu ZK, itu tidak terlalu penting. Anda hanya perlu mengetahui bahwa ZK merupakan cara untuk membuktikan bahwa Anda menjalankan komputasi secara "benar". Contoh sederhananya adalah Anda ingin membuktikan bahwa Anda mengalikan dua angka untuk mendapatkan angka ketiga, yaitu 4*3 = 12

“Cara ZK” untuk membuktikannya adalah dengan menggunakan fungsi berikut:

f(x,y) = x*y

Jika Anda membuat circuit untuk kode di atas, prover akan menghasilkan bukti komputasi yang benar. Circuit itu sendiri merupakan komitmen, sehingga semua orang mengetahui "komputasi" yang Anda jalankan. Namun, hal menariknya adalah mereka tidak perlu mengetahui inputnya. Setelah Anda menjalankan f(3,4), fungsi tersebut menghasilkan 12 dan "bukti". Kini siapa pun dapat mengambil 12, "bukti," dan memverifikasi bahwa Anda mengalikan DUA angka untuk mendapatkan 12. Mereka tidak tahu apakah Anda menggunakan 4,3, 6,2, atau bahkan 12,1. Kemampuan Anda menyembunyikan angka-angka tersebut sementara orang lain tetap dapat memverifikasinya merupakan asal bagian “zero knowledge”.

Mengapa saya menjelaskan hal ini?

Konsep umum ini sangat ampuh untuk membuktikan bahwa Anda telah menjalankan komputasi tertentu dan memperoleh hasil tertentu. Setelah seseorang memiliki hasil dan buktinya, mereka dapat memverifikasi apakah Anda melakukannya dengan benar tanpa benar-benar menjalankan komputasi tersebut. Hal ini berlaku untuk komputasi bebas APA PUN. Saya hanya mengalikan dua angka, tetapi Anda bahkan dapat menggunakannya untuk mengatakan, "Saya telah memverifikasi sepuluh tanda tangan ini dan semuanya valid". Ini adalah manfaat kedua dan salah satu alasan terbesar bukti zero-knowledge digunakan meskipun Anda tidak perlu “menyembunyikan” sesuatu. Anda mengubah masalah yang memerlukan 1.000 langkah komputasi (atau bahkan satu juta) menjadi masalah yang hanya memerlukan verifikasi satu bukti untuk mengetahui bahwa komputasi telah dilakukan dengan benar. Batasannya adalah pembuatan bukti memerlukan waktu.

ZK Compression menggunakan teknologi yang sama untuk menjalankan logika keanggotaan pohon Merkle yang sebenarnya. Jadi, ZK Compression memiliki circuit yang dapat menerima data akun dan sebuah bukti (128 byte), lalu memverifikasi bahwa data tersebut memang menjadi bagian dari "komitmen" di chain. (Bukti sebenarnya berukuran 256 byte, tetapi salah satu keunggulan kurva eliptik dan titik adalah jika Anda mengetahui kurvanya, Anda hanya memerlukan satu titik untuk memperoleh titik kedua).

Hal ini dilakukan terutama untuk mengurangi ukuran bukti menjadi konstan sebesar 128 byte, yang masih menyisakan cukup banyak ruang (secara relatif) bagi data akun kecil. Bukti Merkle normal berukuran Log2(N), sedangkan ukuran ZK Compression selalu konstan sehingga satu komitmen dapat mencakup akun dalam jumlah sangat besar. (Sebagai referensi, bukti Merkle untuk 100.000 akun akan berukuran sekitar 550 byte, yaitu setengah dari payload transaksi) 

Bukti ini dapat dibuat secara off-chain, tetapi harus diverifikasi secara on-chain karena program perlu mengetahui bahwa Anda memberikan data yang benar untuk sebuah akun sebelum mengizinkan eksekusi dilanjutkan. Mekanisme dasar untuk memverifikasi bukti ZK harus tersedia agar hal tersebut dapat dilakukan. Sistem prover khusus yang digunakan ZK-Compression disebut Groth16 dan sistem ini bergantung pada syscall alt_bn128, yang saat ini dibatasi oleh feature gate di mainnet dan sedang diuji.

Hal yang menarik adalah mekanisme yang digunakan ZK-Compression dapat digunakan untuk memverifikasi komputasi bebas (bukan hanya "apakah leaf ini termasuk dalam pohon yang memiliki root ini?").

Salah satu manfaat utama ZK Compression adalah menyediakan seluruh infrastruktur agar developer tidak perlu menangani bagian "ZK” sama sekali. Dari perspektif developer, mereka memperlakukannya seperti akun lain dengan kolom yang sama dan sebagainya, sehingga di dalam program akun tersebut dapat diperlakukan seperti akun biasa. Mengabstraksikan sebagian besar "keajaiban ZK" dan membebaskan developer dari keharusan menanganinya memberikan manfaat besar.

ZK Rollup

Tanpa membahas terlalu mendetail, ZK rollup umumnya menggunakan konsep yang sama dengan ZK-Compression. Kemiripan utamanya adalah seluruh state rollup direpresentasikan sebagai satu root di lapisan dasar (Ethereum). Karena itulah ada beberapa klaim bahwa ZK-Compression merupakan rollup. Namun, ada perbedaan yang sangat penting.

Mari kita pertimbangkan 100 transaksi rollup.

Seluruh ZK rollup diperlakukan sebagai circuit (seperti program perkalian yang kita gunakan sebagai contoh). Seluruh 100 transaksi diverifikasi (tanda tangan, logika kontrak, pemeriksaan deduplikasi, dan sebagainya), lalu satu bukti tunggal dibuat untuk

"Setelah menerapkan 100 transaksi, state root berubah dari A menjadi B". Setelah bukti diverifikasi, smart contract memperbarui state root dari A menjadi B.

Namun, dalam ZK-Compression, masing-masing dari 100 transaksi berisi satu bukti yang hanya memberi tahu Anda bahwa data akun sudah benar, sementara transisi state (yang dihasilkan oleh transaksi) benar-benar dieksekusi secara on-chain sebagai bagian dari SVM itu sendiri. Setelah bukti divalidasi, akun tersebut diperlakukan seperti akun biasa. Hal ini sangat penting bagi properti komposabilitas yang akan kita bahas selanjutnya.

Meninjau Kembali Properti

Sekarang kita sampai pada bagian yang menarik. Properti Solana apa saja yang tetap dipertahankan oleh ZK-Compression?

Komposabilitas Atomik Sinkron

Jika saya memiliki transaksi yang merujuk pada 2 akun terkompresi ZK dan 10 akun "normal", hal tersebut tidak merusak fitur komposabilitas. Instruksi yang merujuk pada akun terkompresi ZK dapat memanggil instruksi/program lain yang merujuk pada akun "normal" yang tidak terkompresi. Fitur ini tetap dipertahankan sepenuhnya meskipun dua akun dikompresi di bawah pohon yang berbeda. Jika satu instruksi gagal, seluruh transaksi dikembalikan ke state sebelumnya (atomik), dan perubahan dari instruksi yang dipanggil pada baris 1 dapat dilihat oleh baris 2 (sinkron).

Hal ini tidak berlaku untuk rollup karena ZK rollup tidak dapat saling memanggil secara sinkron maupun atomik (kecuali rollup mengambil kunci global dan mengizinkan rollback lintas rollup)

Paralelisme

Fitur ini memiliki beberapa dampak terhadap paralelisme dan setiap kasus perlu dipertimbangkan:

Penulisan ke beberapa akun terkompresi di bawah pohon yang sama

Setiap pohon bersifat konkuren secara mandiri. Artinya, jika pengguna membaca/menulis dari dua akun terkompresi di bawah state root yang sama, operasi tersebut dapat dieksekusi secara konkuren dan state root dapat diperbarui secara konkuren. Logika di sini akan sama dengan yang digunakan Solana untuk pembaruan pohon Merkle secara konkuren pada cNFT

Penulisan ke akun terkompresi yang sama

Setiap akun terkompresi tidak bersifat konkuren. Jika dua pengguna mencoba menulis ke akun terkompresi yang sama, salah satu transaksi akan gagal terlepas dari urutannya. Selama eksekusi normal, hasil penulisan ke akun dari instruksi sebelumnya tersedia bagi instruksi berikutnya. Namun, pada akun terkompresi ZK, bukti data akun akan menjadi tidak valid karena bukti tersebut merupakan bukti dari state sebelumnya

Hal lain yang perlu diperhatikan adalah penggunaan compute unit (CU) yang besar oleh kompresi menurunkan konkurensi maksimum per pohon karena setiap akun hanya dapat menggunakan 12 juta compute unit per blok, sesuai batas CU akun.

Asumsi Kepercayaan

Meskipun siapa pun dapat menyimpan semua data mentah yang diperlukan untuk membuat bukti dan mengirimkan transaksi, hal ini merupakan asumsi kepercayaan tambahan yang memengaruhi kelangsungan state terkompresi. Jika karena alasan tertentu data tersebut "hilang" atau terjadi penundaan, Anda tidak akan dapat mengirimkan transaksi kecuali Anda menyimpan sendiri datanya. Untungnya, ini dikenal sebagai masalah f+1, bukan masalah 3f+1 yang memerlukan toleransi kesalahan Bizantium. Masalah f+1 hanya memerlukan satu node jujur untuk menyediakan data. Karena bukti dapat "diverifikasi secara mandiri", tidak ada masalah "keamanan". Masalah utamanya adalah "kelangsungan" dan adanya vektor sensor.

Baik rollup biasa maupun ZK-Compression memerlukan bukti validitas. Namun, rollup mengodekan fungsi transisi state lengkap di dalam bukti validitas, sedangkan ZK-Compression hanya mengodekan "Apakah data akun sudah benar?" Jadi, asumsi kepercayaannya sedikit berbeda. Dalam kasus kompresi, asumsi kepercayaan terutama berlaku untuk akses state (sementara transisi state dilakukan secara penuh). Dalam kasus rollup, asumsi kepercayaan berlaku untuk fungsi transisi state lengkap (dari sudut pandang lapisan dasar). Asumsi keamanan terkait jumlah bit atau tingkat kesulitan/tidak terpecahkannya masalah yang mendasarinya tetap sama (Asumsi Bilinear Diffie-Hellman), tetapi yang berbeda adalah *apa* yang Anda percayakan kepada model keamanan tersebut — akses state dibandingkan eksekusi. Saya menyebutkannya hanya karena penting untuk mengetahui bagian mana yang diberi asumsi kepercayaan tambahan dan bagian mana yang tidak.

Saat ini, program yang memverifikasi akun terkompresi ZK dapat ditingkatkan, tetapi program tersebut dapat dibuat immutable atau dibekukan di masa mendatang karena hanya menjalankan operasi yang sangat spesifik (membuka bukti Merkle), yang sebenarnya tidak memerlukan pembaruan terus-menerus.

Selain itu, kompresi state juga dapat dicapai melalui dua cara lain.

1. Proposal untuk meningkatkan ukuran transaksi (channel proj-3x-tx di Discord Solana) sedang dikembangkan. Setelah diluncurkan, Anda dapat menggunakan bukti Merkle biasa jika ukurannya memungkinkan
2. Setelah syscall alt_bn128 tersedia, syscall tersebut juga dapat digunakan untuk komitmen vektor biasa dengan ukuran bukti konstan (KZG dapat digunakan dengan semua kurva yang mendukung pairing, termasuk alt_bn128). Cara ini tidak memerlukan circuit ZK-prover

Apa sebutannya?

Sayangnya, istilah seperti rollup, L2, dan Validium telah digunakan dengan sangat longgar sampai-sampai beberapa rollup sebenarnya bukan rollup. Rollup tersebut tidak mewarisi kelangsungan, keamanan, atau resistansi terhadap sensor dari lapisan dasar. Meskipun Helius dituduh menggunakan "istilah pemasaran", orang-orang yang sama juga menggunakan istilah "rollup" dengan sangat longgar untuk merujuk pada proyek yang mereka investasikan dengan alasan yang sama — pemasaran. Bahkan, proyek yang bukan rollup diberi label tahapan berbeda hanya agar dapat terus menyebut diri mereka rollup.

Tidak semua orang bersalah dalam hal ini—sebagian orang sangat jujur dalam menggunakan terminologi yang tepat dan telah menghabiskan waktu berbulan-bulan untuk berdebat dengan orang-orang yang menggunakan terminologi tidak tepat guna menyesatkan pengguna (apresiasi untuk Toghrul, yang secara konsisten menyerukan penggunaan terminologi tepat oleh *semua orang*).

Karena memiliki beberapa properti dan asumsi kepercayaan yang berbeda dari rollup, menyebutnya rollup dapat membingungkan pengguna. Menyebutnya Validium juga terlalu luas karena mengabaikan fakta bahwa komposabilitas atomik sinkron atau paralelisme tidak terganggu, ketersediaan data (DA) berada secara on-chain, dan belum lagi fungsi transisi state itu sendiri tidak memerlukan kepercayaan (karena node penuh mengeksekusi program yang sebenarnya secara penuh, bukan sekadar memverifikasi bukti validitas untuk eksekusi itu sendiri). Sebagian orang mungkin berpendapat bahwa bukti ZK tidak memerlukan kepercayaan, tetapi itu tidak benar — meskipun kebutuhan kepercayaannya sangat diminimalkan — secara matematis, asumsi keamanannya tidak sama (asumsi tersebut mungkin cukup untuk 99% kasus penggunaan, tetapi tetap memberlakukan asumsi kepercayaan tambahan di luar node penuh — sebagai contoh, Asumsi Bilinear Diffie Hellman untuk zk-SNARK berbasis kurva pairing). Namun, karena ZK-Compression menggunakan snark untuk memeriksa validitas akun itu sendiri, wajar untuk mengatakan bahwa ZK-Compression tidak sepenuhnya bebas dari kebutuhan kepercayaan — akun terkompresi ZK memiliki asumsi kepercayaan yang tidak dimiliki akun "normal". Jadi, posisinya berada di antara sistem tanpa perlu kepercayaan dan ZK rollup lengkap.

Jika kita menggunakan nama untuk menyimpulkan properti, saya berpendapat bahwa menyebutnya "rollup" tidak menunjukkan keberadaan properti atau asumsi kepercayaan tersebut. Mungkin perlu nama baru? ZK-Compression terdengar cukup tepat selama asumsi kepercayaannya dijelaskan dengan jelas.