Bukti Zero-Knowledge: Penerapannya di Solana

Pendahuluan

Ini adalah artikel kedua dalam seri pengantar tentang bukti zero-knowledge. Saya sangat menyarankan Anda membaca Bukti Zero-Knowledge: Pengantar tentang Dasar-Dasarnya sebelum membaca artikel ini karena artikel tersebut memberikan konteks yang diperlukan mengenai teori, matematika, dan kriptografi yang mendasari analisis dalam artikel ini. Artikel ini mengasumsikan Anda telah memahami hal-hal tersebut. Jadi, jika belum mengenal bukti zero-knowledge, saya sangat menyarankan Anda membaca artikel tersebut terlebih dahulu. Tujuan artikel ini adalah membekali Anda dengan pengetahuan yang diperlukan untuk berkontribusi dalam pembahasan bukti zero-knowledge di Solana, bahkan untuk mulai mengembangkan primitif zero-knowledge baru yang inovatif.

Dengan pengetahuan baru ini, akhirnya kita dapat bertanya: apa itu bukti zero-knowledge? Bagaimana bukti tersebut digunakan di Solana?

Apa Itu Bukti Zero-Knowledge?

Setelah memahami teori, matematika, dan kriptografi yang diperlukan, kini saatnya bertanya: apa sebenarnya bukti zero-knowledge itu?

Bukti zero-knowledge adalah proses kriptografis yang memungkinkan satu pihak membuktikan kepada pihak lain bahwa suatu pernyataan benar tanpa mengungkapkan informasi tambahan apa pun selain fakta bahwa pernyataan tersebut memang benar. Bukti ini harus andal secara statistik, lengkap, dan aman dari kebocoran informasi.

Ada dua jenis pernyataan yang mungkin ingin dibuktikan secara zero-knowledge. Secara garis besar,

• Pernyataan tentang fakta (misalnya, graf tertentu ini memiliki pewarnaan tiga warna)
• Pernyataan tentang pengetahuan (misalnya, saya mengetahui faktorisasi N)

Pernyataan pertama pada akhirnya berkaitan dengan sifat intrinsik alam semesta—sesuatu yang secara fundamental benar, seperti 1 + 1 = 2. Pernyataan kedua disebut sebagai bukti pengetahuan. Artinya, pernyataan tersebut melampaui sekadar membuktikan bahwa sesuatu itu benar dan bergantung pada apa yang diketahui Pembukti.

Seperti disebutkan sebelumnya, untuk membuktikan pernyataan tersebut, bukti kita dapat bersifat interaktif atau noninteraktif. Dalam bukti zero-knowledge interaktif, Pembukti dan Pemverifikasi menjalani serangkaian putaran hingga Pemverifikasi yakin tanpa keraguan yang wajar. Zcash menggunakan bukti zero-knowledge noninteraktif agar pengguna dapat melakukan transaksi anonim. 

Sebaliknya, dalam bukti zero-knowledge noninteraktif, bukti disampaikan secara offline tanpa komunikasi langsung antara Pembukti dan Pemverifikasi. Di sini, Pembukti menghasilkan bukti yang merangkum seluruh informasi yang diperlukan, lalu Pemverifikasi dapat memverifikasinya secara mandiri tanpa interaksi lebih lanjut. Filecoin menggunakan bukti zero-knowledge noninteraktif untuk membuktikan bahwa pengguna telah menyimpan data tanpa mengungkapkan data itu sendiri. 

 zk-SNARK dan Sirkuit

zk-SNARK adalah Succinct Non-interactive ARgument of Knowledge. Bukti zero-knowledge ini sangat efisien dan ringkas, atau succinct. Suatu bukti dianggap ringkas jika ukuran bukti dan waktu yang diperlukan untuk memverifikasinya bertumbuh lebih lambat daripada komputasi yang diverifikasi. Karena itu, jika menginginkan bukti yang ringkas, kita tidak dapat meminta pemverifikasi melakukan pekerjaan pada setiap putaran hashing karena waktu verifikasi akan menjadi sebanding dengan komputasinya. Bukti ringkas dapat dibuat berkat polinomial dan heuristik Fiat-Shamir.

Terlepas dari kompleksitas pernyataan yang hendak dibuktikan, zk-SNARK mempertahankan ukuran bukti yang kecil dan waktu verifikasi yang relatif singkat. Inilah yang membuat zk-SNARK sangat menarik bagi rollup. Kita memiliki metode untuk membuktikan bahwa seluruh transaksi pada L2 tertentu valid, dengan bukti yang cukup kecil untuk diverifikasi di L1. Protokol seperti Mina melangkah lebih jauh dengan menggunakan bukti rekursif, sehingga dapat memverifikasi seluruh riwayat chain dengan bukti berukuran konstan. Pickles adalah sistem bukti baru Mina beserta toolkit terkait, sekaligus zk-SNARK pertama yang digunakan dan mampu melakukan komposisi rekursif tanpa trusted setup. Perhatikan bahwa komposisi rekursif yang dimaksud merujuk pada sirkuit.

Sirkuit menggambarkan komputasi yang ingin Anda buktikan. Sirkuit merupakan rangkaian operasi matematika yang menerima sejumlah input untuk menghasilkan output. Dalam bukti zero-knowledge, sirkuit digunakan untuk merepresentasikan komputasi yang telah dilakukan dengan benar tanpa mengungkapkan input komputasi tersebut. Alur kerja umumnya adalah sebagai berikut:

• Menulis dan Mengompilasi Sirkuit — Kita perlu menulis dan mengompilasi sirkuit. Bentuknya dapat sesederhana membuat sirkuit aritmetika pada medan hingga yang ditentukan oleh bilangan prima p = 7 dan komputasi x * y = z. Gagasan umumnya adalah merepresentasikan komputasi yang akan dibuktikan sebagai sekumpulan batasan antarvariabel, mereduksi batasan tersebut menjadi persamaan polinomial, dan menulis kode yang memetakan seluruh nilai dengan cara tertentu ke struktur aljabar baru (yaitu homomorfisme). Proses kompilasi akan menghasilkan beberapa artefak, termasuk kumpulan batasan yang ditentukan oleh sirkuit serta skrip atau berkas biner yang digunakan pada tahap berikutnya
• Upacara Trusted Setup — Upacara mungkin perlu dijalankan, tergantung pada jenis zk-SNARK yang digunakan untuk menghasilkan kunci pembuktian dan verifikasi
• Menjalankan Sirkuit — Sirkuit harus dijalankan menggunakan skrip atau berkas biner yang dihasilkan selama kompilasi, seolah-olah sirkuit tersebut merupakan suatu program. Pengguna memasukkan input publik dan privat, lalu nilai semua variabel perantara dan output dihitung. Witness, yang juga dikenal sebagai trace, adalah catatan seluruh langkah komputasi
• Menghasilkan Bukti — Dengan kunci pembuktian dari langkah kedua dan witness dari langkah ketiga, pembukti dapat menghasilkan bukti zero-knowledge bahwa seluruh batasan yang ditentukan dalam sirkuit terpenuhi, sembari hanya mengungkapkan nilai output. Bukti ini dikirimkan kepada pemverifikasi
• Memverifikasi Bukti — Pemverifikasi menggunakan bukti yang dikirimkan dan kunci verifikasi untuk memastikan bahwa bukti tersebut benar bagi output publiknya

Jenis zk-SNARK tertentu, seperti Groth16, memerlukan trusted setup untuk setiap sirkuit. Hal ini dapat menjadi kendala karena Anda harus menjalankan upacara baru untuk setiap program baru. zk-SNARK lain, seperti PlonK, hanya memerlukan satu trusted setup universal sehingga menyederhanakan seluruh proses. Jenis bukti zero-knowledge lainnya, seperti zk-STARK, bahkan menghilangkan kebutuhan akan trusted setup sepenuhnya.

zk-STARK

zk-STARK adalah Scalable Transparent ARgument of Knowledge. zk-STARK diciptakan oleh StarkWare dan pertama kali diusulkan dalam makalah tahun 2018 ini sebagai alternatif zk-SNARK. Pada dasarnya, zk-STARK memungkinkan blockchain memindahkan komputasi ke satu pembukti STARK off-chain dan memverifikasi integritas komputasi tersebut menggunakan Pemverifikasi STARK on-chain. 

zk-STARK dianggap zero-knowledge karena input yang digunakan pembukti off-chain tidak diekspos ke blockchain sehingga privasi pengguna tetap terjaga. zk-STARK bersifat skalabel karena memindahkan komputasi ke luar chain secara signifikan mengurangi biaya verifikasi L1. Bukti zk-STARK juga berskala linear, sedangkan zk-SNARK hanya berskala kuasilinear. Selain itu, zk-STARK tidak bergantung pada upacara trusted setup yang rumit, yang menurut penciptanya rentan terhadap limbah beracun—bukti tidak valid yang dapat diterima pemverifikasi jika upacara tidak dilakukan dengan benar. Sebagai gantinya, zk-STARK menggunakan keacakan yang dapat diverifikasi secara publik untuk menyiapkan interaksi antara pembukti dan pemverifikasi. Bukti ini juga hanya dapat dihasilkan oleh pembukti off-chain yang benar-benar menjalankan komputasi, beserta input tambahan yang diperlukan.

zk-STARK mengatasi keterbatasan zk-SNARK dengan menjadi argumen pengetahuan yang skalabel dan transparan. Asumsi kriptografisnya juga jauh lebih sederhana dan sepenuhnya menghindari kebutuhan akan elemen seperti kurva eliptik. Sebagai gantinya, zk-STARK hanya mengandalkan hash dan teori informasi, sehingga tahan terhadap komputasi kuantum. Namun, ukuran buktinya dapat mencapai beberapa ratus kilobyte, yang dapat membatasi kelayakannya di lingkungan dengan bandwidth atau penyimpanan terbatas, seperti blockchain. Perhatikan bahwa beberapa konfigurasi pembuktian dan zkVM yang lebih kompleks akan menggunakan kombinasi pembuktian zk-STARK secara rekursif ke dalam zk-SNARK hanya untuk tahap verifikasi akhir.

ZK Compression

Masalah Pertumbuhan State

Salah satu masalah Solana yang paling mendesak adalah masalah pertumbuhan state. Sebagai konteks, state Solana disimpan pada disk full node di Accounts DB. Ini merupakan penyimpanan key-value, dengan setiap entri dalam basis data disebut sebagai account. Setiap account memiliki alamat berukuran 32 byte, sedangkan jumlah data yang dapat disimpan bervariasi dari 0 hingga 10 MB. Saat ini, penyimpanan data sebesar 10 MB memerlukan biaya sekitar 70 SOL, baik data tersebut disimpan dalam satu account berukuran 10 MB maupun seribu account berukuran 10 KB. Setiap hari, sekitar satu juta account baru ditambahkan ke chain. Menurut postingan Toly tentang masalah pertumbuhan state, hal ini membuat total state melampaui 500 juta account. Seiring pertumbuhan Solana, kondisi ini akan menimbulkan sejumlah tantangan, khususnya ukuran snapshot tanpa batas, keterbatasan bandwidth PCI, pengindeksan account, serta pengelolaan memori dan disk yang mahal. 

Ukuran full snapshot saat ini sekitar 70 GB, yang masih dapat ditangani oleh perangkat keras yang tersedia. Namun, pertumbuhan berkelanjutan pada akhirnya akan menyebabkan inefisiensi pengelolaan state dan potensi kemacetan. Seiring bertambahnya ukuran snapshot, waktu yang diperlukan untuk melakukan cold boot pada sistem baru setelah kegagalan perangkat keras menjadi jauh lebih lama. Kondisi ini dapat merugikan jika jaringan perlu dimulai ulang. 

Bandwidth Peripheral Component Interconnect (PCI) mengacu pada laju transfer data antara CPU dan perangkat periferal, seperti kartu grafis, kartu jaringan, dan perangkat penyimpanan. PCI Express (PCIe) adalah standar antarmuka berkecepatan tinggi yang dirancang untuk menggantikan standar PCI lama dan menyediakan laju transfer data yang lebih tinggi. Bandwidth PCI terbaru dapat mencapai kecepatan 1 TB, atau 128 GB/dtk. Meskipun terdengar besar, angka ini tidak terlalu besar dalam konteks Solana. Jika sebuah transaksi membaca atau menulis 128 MB, bandwidth PCI 128 GB/dtk akan membatasi Solana hingga 1.000 transaksi per detik (TPS). Namun, sebagian besar transaksi mengakses memori terbaru yang telah dimuat dan disimpan dalam cache RAM validator. Meski demikian, memori state yang efisien sangat penting agar throughput tinggi dapat dipertahankan ketika Solana berkembang. Jika tidak, bandwidth ini dapat dengan cepat menjadi faktor pembatas.

Setiap validator harus memelihara indeks seluruh account yang ada. Hal ini karena pembuatan account baru memerlukan bukti bahwa account tersebut belum ada. Dengan total state yang melampaui 500 juta account, bahkan indeks minimal (yaitu kunci 32 byte dan hash data 32 byte per entri) akan membutuhkan RAM sekitar 32 GB. Penyimpanan state ini mahal dan harus dikelola dengan cermat untuk mencegah penurunan performa. Seiring pertumbuhan state Solana, perbedaan antara penggunaan memori cepat dan mahal (yaitu RAM) untuk operasi tertentu dan memori yang lebih lambat dan murah (yaitu disk) menjadi sangat penting.

Transaksi dan Pertumbuhan State

Setiap transaksi Solana harus menentukan semua account yang dibaca dan ditulisnya. Ukuran transaksi saat ini dibatasi hingga 1.232 byte dan harus mencakup hal-hal berikut:

• Header (3 byte)
• Tanda tangan (masing-masing 64 byte)
• Alamat account (masing-masing 32 byte)
• Data instruksi (ukuran arbitrer)
• Blockhash terbaru (32 byte)

Berikut hal-hal yang terjadi saat suatu transaksi dijalankan:

• Pemeriksaan Kewajaran — Hanya transaksi terbaru yang valid, serta pemeriksaan deduplikasi, struktur, biaya, dan tanda tangan dilakukan terhadap transaksi
• Pemuatan Program — Bytecode program dimuat berdasarkan alamat program, lalu Solana Virtual Machine (SVM) dibuat
• Pemuatan Account — Semua account yang dirujuk transaksi diperiksa dan dimuat dari penyimpanan ke memori, lalu diteruskan ke SVM
• Eksekusi — Bytecode program dijalankan
• Sinkronisasi — Setiap account yang diubah disinkronkan kembali ke penyimpanan

Siklus hidup ini menimbulkan sejumlah tantangan seiring pertumbuhan state. Secara khusus, state on-chain berbiaya mahal, sedangkan makin banyak account yang disimpan di disk akan menghasilkan snapshot dan indeks yang lebih besar. Selain itu, tidak semua account sering diakses sehingga pengenaan biaya sumber daya secara berkelanjutan menjadi tidak efisien.

Menyederhanakan Pengelolaan State dengan ZK Compression

Alih-alih menyimpan semua account di disk dan membacanya saat diperlukan, transaksi dapat menyertakan data account sebagai bagian dari payload transaksi. Kita dapat memastikan bahwa pengguna yang mengirimkan transaksi memberikan state yang benar dengan menggunakan Merkle tree. Bukti Merkle merupakan cara untuk membuat commitment atas suatu data. Dengan demikian, bukti dapat diverifikasi terhadap commitment untuk memastikan bahwa state yang benar telah diberikan dan pengguna tidak berbohong mengenai state tersebut. 

Meskipun aman, bukti ini dapat berukuran cukup besar. Misalnya, jika sebuah tree berisi 100 ribu account, ukuran buktinya akan mencapai 544 byte. Menyediakan bukti untuk beberapa account dapat dengan cepat melampaui batas ukuran transaksi sebesar 1.232 byte. Untungnya, kita dapat mengatasinya dengan menggunakan sistem bukti yang lebih efisien. Penggunaan commitment dengan ukuran bukti konstan, seperti commitment KZG atau Pedersen, akan mengurangi ukuran bukti sehingga lebih layak disertakan dalam batas ukuran transaksi.

ZK Compression hanyalah mekanisme untuk mengatasi masalah ukuran bukti Merkle—sebuah cara untuk membuktikan bahwa suatu komputasi telah dilakukan dengan benar tanpa biaya penyimpanan on-chain terkait, dengan memanfaatkan ledger Solana.

Apa Itu ZK Compression?

ZK Compression adalah primitif baru yang memungkinkan developer mengompresi state on-chain untuk mengurangi biaya state hingga beberapa orde besaran, sekaligus mempertahankan keamanan, performa, dan komposabilitas. Sebagai contoh, pembuatan 100 token account saat ini memerlukan biaya ~0,2 SOL. Dengan ZK Compression, biayanya berkurang 5.000 kali menjadi ~0,00004. 

ZK Compression memanfaatkan bukti zero-knowledge untuk memvalidasi transisi state tanpa mengekspos data yang mendasarinya. ZK Compression melakukannya dengan mengelompokkan beberapa account ke dalam satu Merkle root yang dapat diverifikasi dan disimpan secara on-chain, sedangkan data dasarnya disimpan di ledger. Bukti validitas adalah bukti zero-knowledge ringkas yang digunakan untuk membuktikan keberadaan sejumlah n account sebagai leaf dalam sejumlah m state tree, dengan mempertahankan ukuran bukti konstan sebesar 128 byte. Bukti ini dihasilkan secara off-chain dan diverifikasi secara on-chain sehingga mengurangi beban komputasi Solana secara keseluruhan. Untuk sistem pembuktinya, ZK Compression menggunakan Groth16, zk-SNARK berbasis pairing yang terkenal.

Namun, account ini bukanlah account Solana biasa. Account tersebut merupakan compressed account.

Model Compressed Account

State terkompresi ZK disimpan dalam compressed account. Account ini serupa dengan account Solana biasa, tetapi memiliki beberapa perbedaan utama yang meningkatkan efisiensi dan skalabilitas:

• Identifikasi Hash — Setiap compressed account dapat diidentifikasi melalui hash-nya
• Perubahan Hash saat Penulisan — Setiap operasi penulisan ke compressed account akan mengubah hash-nya
• Alamat Opsional — Alamat dapat ditetapkan secara opsional sebagai ID unik permanen compressed account. Hal ini berguna untuk kasus penggunaan tertentu, seperti NFT. Kolom ini bersifat opsional untuk menghindari overhead komputasi karena compressed account dapat dirujuk melalui hash-nya
• Sparse State Tree — Semua compressed account disimpan dalam Merkle tree, sedangkan hanya state root tree tersebut (yaitu Merkle root) yang disimpan dalam ruang account on-chain. Secara lebih spesifik, state tree adalah concurrent Merkle tree berbasis hash Poseidon

Compressed Program-Derived Address (PDA) dapat diidentifikasi melalui alamat unik dan persistennya. Tata letaknya serupa dengan account PDA biasa, dengan kolom Data, Lamports, Owner, dan Address. Namun, tidak seperti PDA biasa, kolom Data mengabadikan struktur AccountData dengan kolom Discriminator, Data, dan DataHash.

Node

Berbagai jenis node berperan penting dalam mendukung ZK Compression. Siapa pun dapat menjalankan node Photon RPC, node Prover, atau node Light Forester untuk terhubung ke Devnet dan Mainnet-Beta. Untuk pengembangan lokal, perintah ZK Compression CLI test-validator menjalankan cluster Solana dengan satu node yang mencakup seluruh node terkait (yaitu Photon RPC dan Prover), serta program sistem, account, dan fitur runtime.

Node Photon RPC mengindeks program kompresi. Hal ini memungkinkan klien membaca dan membuat transaksi yang berinteraksi dengan state terkompresi. Pengindeks kompresi kanonis bernama Photon dan disediakan oleh Helius. Jenis node ini dapat dijalankan secara lokal dengan konfigurasi minimal dan harus diarahkan ke RPC yang sudah ada. 

Node Prover digunakan untuk menghasilkan bukti validitas bagi penyertaan state. Endpoint getValidityProof dari spesifikasi ZK Compression RPC API dapat digunakan untuk mengambil bukti. Node Prover dapat dioperasikan sebagai node mandiri atau digabungkan dengan RPC lain. Perhatikan bahwa implementasi Photon RPC kanonis menyertakan node Prover.

Node Light Forester mengelola pembuatan, rollover, dan pembaruan state tree bersama maupun yang dimiliki program. Node ini ditujukan bagi developer yang mungkin ingin state tree milik programnya sendiri dilayani oleh jaringan node Light Forester.

Asumsi Kepercayaan

Siapa pun dapat menjalankan salah satu node yang disebutkan di atas, serta menyimpan data mentah yang diperlukan untuk menghasilkan bukti dan mengirimkan transaksi. Hal ini memperkenalkan asumsi kepercayaan yang memengaruhi liveness state terkompresi. Secara khusus, jika data hilang atau tertunda, transaksi tidak dapat dikirimkan kecuali data tersebut disimpan secara pribadi. Karena hanya diperlukan satu node jujur untuk menyediakan data dan bukti dapat diverifikasi sendiri, masalahnya terletak pada liveness dan potensi penyensoran, bukan keamanan.

Selain itu, fakta bahwa program yang memverifikasi compressed account saat ini dapat di-upgrade memperkenalkan asumsi kepercayaan lainnya. Kemampuan ini memungkinkan program dimodifikasi untuk memperbaiki masalah atau disesuaikan dengan kebutuhan baru. Namun, program tersebut dapat dijadikan immutable atau dibekukan pada masa mendatang setelah mencapai kondisi yang stabil dan aman.

Asumsi kepercayaan liveness lainnya adalah penggunaan node Forester. Node ini mempertahankan kemajuan state root dan mengelola antrean nullifier dengan mengosongkannya serta memajukan state root secara asinkron. Di sini, hash account diganti dengan nol untuk meniadakannya. Pemisahan antara kemajuan dan peniadaan ini memastikan finalitas instan bagi transisi state terkompresi, sekaligus menjaga transaksi tetap berada dalam batas ukuran Solana. Karena antrean nullifier memiliki ukuran konstan, node Forester sangat penting bagi liveness protokol. Antrean yang penuh akan menyebabkan kegagalan liveness bagi state tree terkait. Untungnya, node Forester mencegahnya dengan mengosongkan antrean. Namun, tetap diperlukan orang yang menjalankan node ini untuk membantu menjaga integritas dan liveness protokol. Tanpa node tersebut, ZK Compression hanya dapat mendukung sekitar dua ribu account/alamat.

Keterbatasan 

Bahkan ketika tidak ada sesuatu yang perlu disembunyikan, bukti zero-knowledge mengubah masalah yang membutuhkan beberapa langkah komputasi menjadi masalah yang hanya memerlukan verifikasi satu bukti untuk memastikan komputasi telah dilakukan dengan benar. Komputasi ini tidak harus sekadar menentukan apakah leaf tertentu termasuk dalam tree tertentu—komputasinya dapat bersifat arbitrer. Namun, kemampuan ini memiliki biaya.

Sebelum menggunakan ZK Compression, pertimbangkan hal-hal berikut:

• Ukuran Transaksi Lebih Besar — ZK Compression memerlukan 128 byte untuk bukti validitas serta untuk data yang akan dibaca/ditulis secara on-chain dan dikirimkan
• Penggunaan Compute Unit Lebih Tinggi — ZK Compression secara signifikan meningkatkan penggunaan compute unit (CU) karena memerlukan ~100 ribu CU untuk verifikasi bukti validitas, ~100 ribu CU untuk penggunaan sistem, dan ~6 ribu CU per compressed account yang dibaca atau ditulis
• Biaya State per Transaksi — Setiap operasi penulisan menimbulkan sedikit biaya jaringan karena harus meniadakan state compressed account sebelumnya dan menambahkan state terkompresi baru ke state tree. Dengan demikian, sangat mungkin biaya seumur hidup satu compressed account melampaui account biasa yang setara jika memerlukan banyak pembaruan state

Penggunaan account biasa mungkin lebih sesuai jika:

• Account sering diperbarui
• Jumlah penulisan ke account sepanjang masa pakainya akan besar (yaitu >1.000 kali)
• Account menyimpan data dalam jumlah besar yang harus diakses dalam transaksi on-chain

Manfaat

ZK Compression adalah primitif yang skalabel, aman, efisien, dan fleksibel. Primitif ini secara langsung mengatasi masalah pertumbuhan state Solana serta mendukung beragam aplikasi dan kasus penggunaan. Keunggulannya yang paling terlihat mungkin adalah pengurangan biaya state. ZK Compression memungkinkan aplikasi dengan mudah berkembang hingga jutaan pengguna dengan menyimpan state secara aman di ruang ledger yang lebih murah, sekaligus meminimalkan penyimpanan on-chain melalui sidik jari state. Sebagai contoh, dengan asumsi harga SOL sebesar $130 USD, pencetakan 10.000 token account akan memerlukan biaya sekitar $2.600. ZK Compression menurunkannya menjadi kurang dari lima puluh sen.

ZK Compression juga sangat sesuai dengan spesifikasi Solana saat ini. Sebagai contoh, struktur compressed account hampir sama dengan account Solana biasa. ZK Compression juga mendukung inovasi khusus Solana seperti paralelisme. Artinya, dua transaksi dalam state tree yang sama (yaitu commitment) yang mengakses compressed account berbeda dapat dijalankan secara paralel. Selain itu, ZK Compression memperkuat komposabilitas atomik sinkron. Sebagai contoh, transaksi yang mencantumkan n compressed account dan m account biasa merupakan konfigurasi yang sepenuhnya valid. Instruksi yang merujuk ke compressed account dapat memanggil instruksi atau program lain yang merujuk ke account biasa. Hal ini tetap berlaku meskipun account dikompresi dalam state tree yang berbeda. Jika satu instruksi gagal, seluruh transaksi akan di-roll back, sedangkan perubahan dapat terlihat dari satu instruksi ke instruksi berikutnya. Ini berbeda dengan ZK rollup, yang tidak dapat saling memanggil secara sinkron atau atomik kecuali menggunakan kunci. Perbedaan ini tentu mendorong perbandingan antara ZK Compression dan rollup.

ZK Compression Bukan Rollup

ZK Compression bukanlah rollup. Meskipun keduanya mengandalkan teknologi yang sama, implementasinya berbeda. Ada dua jenis rollup:

• Optimistic Rollup — Semua transaksi dianggap valid selama jangka waktu tertentu, lalu bukti penipuan digunakan untuk membuktikan transaksi palsu dalam periode tersebut
• Zero-Knowledge Rollup — Transaksi langsung dibuktikan valid atau tidak valid menggunakan bukti validitas

Seluruh state zero-knowledge rollup direpresentasikan sebagai satu root pada base layer (yaitu Ethereum). Hal ini memunculkan sejumlah klaim bahwa ZK Compression sebenarnya adalah rollup. Namun, ada beberapa perbedaan penting.

Pertimbangkan skenario yang melibatkan 500 transaksi pada ZK rollup. Dalam kasus ini, seluruh rollup diperlakukan sebagai satu sirkuit. Seluruh 500 transaksi diverifikasi bersama-sama dan menghasilkan satu bukti yang mengonfirmasi bahwa state root telah berubah dari A menjadi B. Setelah bukti ini diverifikasi, smart contract yang mengelola interaksi antara L1 dan L2 akan memperbarui state root. Sebaliknya, dengan ZK Compression, masing-masing dari 500 transaksi menghasilkan buktinya sendiri untuk memverifikasi kebenaran data account. Transaksi tersebut dijalankan oleh SVM itu sendiri, dan account diperlakukan sebagai account “biasa” setelah setiap bukti divalidasi.

Jika kita mengklasifikasikan ZK Compression sebagai rollup, hal tersebut menyiratkan bahwa setiap Merkle root yang disimpan di Solana dapat dianggap sebagai rollup berbasis validitas. Jika melihat seluruh root cNFT terkompresi yang saat ini ada di Solana, terdapat sekitar 4–5 ribu rollup berbasis validitas, tergantung apakah kita menghitung Merkle tree tanpa mint.

Dengan demikian, jelas bahwa ZK Compression merupakan solusi unik yang disesuaikan dengan arsitektur Solana. ZK Compression adalah primitif baru yang berbeda dari ZK rollup. Primitif ini meningkatkan skalabilitas dan efisiensi tanpa kompleksitas dan pemisahan yang dimiliki rollup.

Masa Depan ZK di Solana dan Interoperabilitas

Kondisi ZK Saat Ini di Solana

Salah satu tugas penulisan pertama saya di Helius adalah membahas pembaruan v1.16 Solana. Saya sangat antusias mempelajari dukungan runtime yang lebih baik untuk bukti zero-knowledge dan membahasnya dalam artikel tersebut. Namun, peningkatan ini ditunda. Saya kemudian melakukan kesalahan dengan membahas peningkatan tersebut lagi secara lebih mendetail dalam artikel pembaruan v1.17, tetapi peningkatannya kembali ditunda. Saya bahkan tidak membahasnya dalam artikel pembaruan v1.18. Tentu saja saya kecewa, dan orang lain juga mengungkapkan rasa frustrasinya. 

Terlepas dari sentimen ini, komunitas developer ZK di Solana mulai tumbuh meskipun masih kecil. Awalnya, Light Protocol berfokus pada eksekusi program privat dalam bentuk PSP (Private Solana Programs), sebelum kemudian memusatkan fokusnya pada ZK Compression. Dark protocol juga merupakan protokol privasi futarkis yang dibangun di Solana. Protokol ini tidak memiliki tim pusat dan kontribusinya dilakukan melalui proposal. Arcium, yang sebelumnya dikenal sebagai Elusiv, menggunakan Multiparty computation eXecution Environments (MXE) untuk mendukung jaringan komputasi rahasia dan terparalelisasi miliknya. Bonsol adalah "koprosesor" zero-knowledge yang memungkinkan developer menjalankan risc0 image apa pun dan memverifikasinya di Solana (yaitu komputasi off-chain yang dapat diverifikasi). Tutorial dan daftar tautan terkait bukti zero-knowledge juga telah beredar.

Yang paling menonjol, ZK Token Proof Program memverifikasi beberapa bukti zero-knowledge yang dirancang untuk bekerja dengan commitment Pedersen dan Enkripsi Twisted ElGamal pada curve25519. Program ini mendukung Confidential Transfers, yang menggunakan bukti zero-knowledge untuk mengenkripsi saldo dan jumlah transaksi token SPL. Tujuannya adalah kerahasiaan, bukan anonimitas. Enkripsi homomorfik memungkinkan komputasi dilakukan pada data terenkripsi tanpa perlu mendekripsinya. Untuk melakukannya, Confidential Transfers menggunakan Enkripsi Twisted ElGamal bagi operasi matematika tersembunyi pada ciphertext dan Protokol Sigma untuk memvalidasi transfer tersebut tanpa mengungkapkan informasi sensitif. Hanya pemegang account yang memiliki kunci dekripsi yang dapat melihat saldo terenkripsinya. Namun, Global Auditor System memungkinkan akses baca selektif untuk kepatuhan dan audit melalui kunci dekripsi terpisah. 

ZK Token Proof Program saat ini merupakan fitur yang diblokir karena disahkannya SIMD-0153: ZK ElGamal Proof Program. SIMD baru ini bertujuan menghentikan penggunaan ZK Token Proof Program yang dirancang khusus untuk program SPL Token dan menggantinya dengan program bukti zero-knowledge yang lebih umum serta tidak bergantung pada aplikasi tertentu. SIMD tersebut telah digabungkan dengan dukungan dari Anza dan tim Firedancer.

Namun, keadaan mulai berubah. Solana berkembang menjadi raksasa ZK karena peningkatan ini akhirnya hadir di Devnet dan Mainnet-Beta. Kini ada tiga syscall ZK yang aktif di Solana.

Syscall Poseidon

Poseidon adalah keluarga fungsi hash yang dirancang khusus untuk bukti zero-knowledge dan digunakan dalam proyek seperti Zcash, Mina, dan Light Protocol. Dibandingkan fungsi hashing tradisional yang bersifat umum seperti SHA-256, Poseidon lebih efisien secara komputasi untuk bukti zero-knowledge. 

Fungsi hash Poseidon ramah terhadap zero-knowledge karena:

• Menjalankan operasi aritmetika secara efisien
• Memerlukan lebih sedikit langkah untuk menghasilkan bukti (yaitu memiliki kompleksitas sirkuit yang lebih rendah), berkat desain yang ramah aritmetika, S-box yang dioptimalkan, dan jumlah putaran yang rendah
• Menggunakan algoritme yang menangani rangkaian bit dengan panjang berapa pun sehingga sangat serbaguna

Sebelumnya, menghitung hash Poseidon dalam satu transaksi terlalu mahal. Namun, hal ini berubah pada epoch 644 dengan aktivasi syscall Poseidon (yaitu pemanggilan sistem yang menerima input slice byte 2D dan menghitung hash Poseidon terkait sebagai output). Perkembangan ini menarik karena ZK Compression mengandalkan hashing Poseidon untuk state tree-nya.

Syscall Poseidon menghitung hash menggunakan kurva BN254 dengan parameter berikut:

• S-box — Kotak substitusi x5
• Input — 1 ≤ n ≤ 12
• Lebar — 2 ≤ t ≤ 13
• Putaran — 8 putaran penuh dan putaran parsial tergantung pada t: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

Output-nya adalah hasil hash Posiedon yang dikodekan sebagai 32 byte dalam endianness yang ditentukan.

Perhatikan bahwa varian khusus yang digunakan untuk syscall ini adalah Poseidon dengan S-box x5 dan parameter yang disesuaikan untuk kurva BN254. Crate light-poseidon akan memfasilitasi komputasi hash tersebut. Crate itu sendiri telah diaudit dan kompatibel dengan Circom.

Syscall alt_bn128

alt_bn128 mengacu pada implementasi kurva eliptik Barreto-Naehrig (BN-128), sebuah kurva yang ramah pairing dan memungkinkan pembuktian serta komputasi zk-SNARK yang efisien. Kurva ini sangat penting bagi berbagai sistem bukti zero-knowledge, termasuk Groth16, yang digunakan ZK Compression untuk memvalidasi transisi state. Syscall ini secara signifikan mengurangi ruang yang diperlukan untuk setiap bukti serta memberikan optimasi ruang dan waktu yang sangat penting bagi bukti on-chain yang efisien. 

Syscall sol_alt_bn128_group_op menghitung operasi pada kurva alt_bn128, termasuk penjumlahan titik di G1 (G1 berarti sekelompok titik pada kurva eliptik tertentu), perkalian skalar di G1, dan pairing:

• Input — Titik dan skalar yang diserialisasi dalam format big endian
• Operasi — Penjumlahan titik di G1, perkalian skalar di G1, pairing (1 titik di G1 dan 1 titik di G2)
• Output — Titik di G1 atau hasil pairing yang diserialisasi sebagai bilangan bulat 256-bit

Syscall sol_alt_bn128_compression mengompresi atau mendekompresi titik dalam grup G1 atau G2 pada kurva alt_bn128, lalu mengembalikan titik tersebut dalam format big endian standar.

Syscall ini saat ini aktif di testnet dan tampaknya akan tersedia di Devnet setelah bug pada tahap kompilasi ulang program yang dimuat diselesaikan, sesuai SIMD-0075: Secp256r1 Precompile. Proposal ini bertujuan menyederhanakan kode kesalahan untuk syscall alt_bn128 serta syscall Poseidon, memastikan konsistensi, dan mengurangi risiko kegagalan konsensus akibat validator mengembalikan kode kesalahan yang berbeda.

Syscall alt_bn128 dapat digunakan untuk commitment vektor biasa dengan ukuran bukti konstan, seperti commitment KZG. Karena itu, syscall tersebut akan berfungsi dengan kurva ramah pairing apa pun dan tidak memerlukan sirkuit pembukti ZK. 

Interoperabilitas

Solana adalah chain ZK. Solana merupakan blockchain Layer 1 berperforma tinggi dengan biaya rendah dan dukungan runtime untuk operasi kurva eliptik. Implementasi dan dukungan untuk syscall terkait bukti zero-knowledge mendorong inovasi, sehingga primitif dan aplikasi baru seperti ZK Compression dapat dibangun di atas Solana.

Hadirnya syscall alt_bn128 mempersempit kesenjangan komposabilitas antara Solana dan kontrak berbasis Solidity yang mengandalkan kontrak prakompilasi untuk operasi kurva eliptik sebagaimana ditetapkan dalam EIP-196, EIP-197, dan EIP-198. Operasi ini memfasilitasi verifikasi bukti zk-SNARK dalam batas gas Ethereum. Dengan demikian, kontrak Solidity yang mengandalkan operasi kurva eliptik tersebut kini dapat lebih mudah beralih ke, atau bahkan berinteroperasi dengan, Solana.

SIMD-0075 sangat penting bagi solusi interoperabilitas. Setelah sepenuhnya diimplementasikan, SIMD ini akan memungkinkan proyek seperti blobsream-solana yang akan datang (yang mengalirkan DA dari Celestia ke Solana) menggunakan pembuatan bukti off-chain dan verifikasi on-chain untuk menyimpan commitment Merkle. Tanpa syscall ini, bukti Groth16 tidak mungkin diverifikasi di Solana. Selain itu, syscall ini meningkatkan bridging dan interoperabilitas dengan kebutuhan kepercayaan yang minimal, sehingga blockchain lain dapat berinteraksi dengan Solana secara lancar dan aman.  

Toly benar—dengan seluruh peningkatan runtime Solana ini, Solana adalah L2 Ethereum. Dalam waktu dekat, tidak ada yang dapat menghalangi Anda mengirimkan seluruh blok Solana ke suatu kontrak bridge validasi data di Ethereum. Sebaliknya, tidak ada yang dapat menghalangi Anda mengirimkan seluruh blok Ethereum ke suatu program bridge validasi data di Solana. Interoperabilitas dua arah yang dipercepat oleh bukti zero-knowledge, bukan bridge usang, merupakan masa depan Solana yang cerah dan berkembang.

Kesimpulan

Bukti zero-knowledge tidak diragukan lagi merupakan salah satu primitif paling canggih, jika bukan yang paling canggih, yang dikembangkan oleh para kriptografer. Hal ini menjadi jelas setelah menelaah teori, matematika, dan kriptografi yang mendasari konsep tersebut dalam artikel pertama dengan berangkat dari prinsip-prinsip dasar. Potensi penerapannya tidak terbatas, mulai dari fog of war yang sesungguhnya untuk game on-chain hingga pembuktian bahwa sekumpulan transaksi pada L2 menghasilkan transisi state tertentu.

Seri dua bagian ini sebenarnya dapat dengan mudah diperluas hingga lebih dari lima puluh halaman dengan membahas seluk-beluk enkripsi homomorfik, pemrograman sirkuit dalam Circom, dan analisis berbagai skema commitment. Namun, tujuan artikel-artikel ini adalah mengedukasi pembaca tentang dasar-dasar bukti zero-knowledge agar mereka dapat menggunakan pengetahuan baru tersebut dan menerapkannya di Solana. 

Solana berkembang menjadi raksasa ZK. Mulai dari peluncuran ZK Compression hingga berbagai syscall yang akan segera aktif, arti pentingnya tidak dapat diremehkan. Meskipun primitif seperti ZK Compression mengabstraksikan seluruh kompleksitas bukti zero-knowledge bagi developer pada umumnya, pemahaman atas dasar-dasarnya sangat berharga untuk memajukan diskusi dan pengembangannya di Solana. 

Jika Anda sudah membaca sejauh ini, terima kasih, anon! Pastikan Anda memasukkan alamat email di bawah agar tidak pernah melewatkan kabar terbaru tentang Solana. Siap mempelajari lebih dalam? Jelajahi artikel terbaru di blog Helius dan lanjutkan perjalanan Solana Anda hari ini.

Sumber Daya Tambahan

• Pengantar Perkiraan tentang Cara Kerja zk-SNARK oleh Vitalik
• POSEIDON: Fungsi HAsh Baru untuk Sistem Bukti Zero-Knowledge (Versi Terbaru)
• SIMD-0075: Secp256r1 Precompile
• Memahami Perbedaan antara zk-SNARK dan zk-STARK
• Dokumentasi ZK Compression