Prover

Apa Itu Prover dalam Kripto?

Prover adalah orang, program, node, layanan, atau sistem perangkat keras yang menghasilkan bukti kriptografis untuk menunjukkan bahwa suatu pernyataan, komputasi, batch transaksi, atau transisi state valid.

Dalam mata uang kripto, istilah ini paling sering digunakan dalam zero-knowledge proof, validity rollup, zkVM, protokol privasi, dan sistem komputasi terverifikasi.

Tugas prover adalah melakukan komputasi berat yang diperlukan untuk membuat bukti agar pihak lain dapat memverifikasinya dengan biaya lebih rendah.

Pihak lain tersebut disebut verifier.

Prover dapat menunjukkan bahwa suatu komputasi dilakukan dengan benar tanpa mengharuskan setiap verifier mengulangi seluruh komputasi.

Gagasan ini penting untuk scaling blockchain karena blockchain publik membutuhkan banyak peserta untuk menyepakati perubahan state yang valid.

Jika setiap node harus mengeksekusi ulang setiap transaksi secara terperinci, jaringan dapat menjadi lambat dan mahal.

Dengan sistem proof, prover dapat mengeksekusi atau memeriksa beban kerja besar secara off-chain, lalu mengirimkan proof ringkas ke on-chain.

Dokumentasi zero-knowledge proof Ethereum menjelaskan bahwa komputasi terverifikasi memungkinkan node mengeksekusi transaksi di luar Ethereum dan mengirimkan proof yang menunjukkan bahwa eksekusi off-chain tersebut benar.

Cara termudah memahami prover adalah sebagai mesin atau aktor yang membuat bukti matematis bahwa suatu komputasi telah dilakukan dengan benar.

Cara Kerja Prover

Prover memulai dengan pernyataan yang perlu dibuktikan.

Pernyataannya bisa sederhana, seperti membuktikan bahwa seseorang mengetahui suatu nilai rahasia.

Pernyataannya juga bisa kompleks, seperti membuktikan bahwa ribuan transaksi Layer 2 diproses sesuai aturan protokol.

Prover juga menggunakan input.

Beberapa input mungkin bersifat publik, artinya verifier dapat melihatnya.

Input lainnya mungkin bersifat privat, artinya prover menggunakannya tanpa mengungkapkannya secara langsung.

Dalam banyak sistem proof, input privat disebut witness.

Prover kemudian menjalankan algoritma pembuktian yang mengubah pernyataan, constraints, input publik, dan witness menjadi proof.

Proof biasanya jauh lebih kecil dan lebih cepat diverifikasi daripada komputasi aslinya.

Verifier memeriksa proof menggunakan algoritma verifikasi.

Jika proof valid, verifier menerima bahwa pernyataan tersebut benar berdasarkan aturan sistem proof.

Dengan demikian, blockchain dapat memercayai hasil komputasi tanpa harus memercayai prover secara pribadi.

Prover vs Verifier

Prover dan verifier memiliki peran yang berlawanan dalam sistem proof.

Prover membuat proof.

Verifier memeriksa proof.

Biasanya, tugas prover lebih berat karena pembuatan proof dapat membutuhkan banyak komputasi.

Biasanya, tugas verifier lebih ringan karena verifikasi proof dirancang agar cepat dan murah.

Asimetri ini berguna bagi blockchain karena satu prover dapat melakukan pekerjaan berat secara off-chain, sementara banyak node atau smart contract dapat memverifikasi hasilnya secara efisien.

Misalnya, dalam ZK-rollup, prover dapat menghasilkan validity proof untuk batch transaksi berukuran besar.

Verifier contract on-chain kemudian memeriksa proof tersebut sebelum menerima pembaruan state rollup.

Dokumentasi ZK-rollup Ethereum menjelaskan bahwa ZK-rollup menggunakan validity proof untuk memfinalisasi transaksi di Ethereum.

Verifier tidak perlu memercayai kejujuran prover karena proof yang tidak valid seharusnya gagal dalam verifikasi.

Prover vs Sequencer

Prover tidak sama dengan sequencer.

Sequencer mengurutkan transaksi dan biasanya membantu menyusun batch dalam sistem rollup.

Prover menghasilkan proof kriptografis bahwa batch atau transisi state tersebut valid.

Dalam beberapa sistem, organisasi yang sama dapat mengoperasikan infrastruktur sequencing dan proving.

Dalam sistem lainnya, sequencing dan proving dapat dipisahkan di antara layanan, node, market, atau peserta komunitas yang berbeda.

Perbedaan ini penting karena mengurutkan transaksi dan membuktikan kebenarannya merupakan wewenang yang berbeda.

Sequencer dapat memengaruhi urutan transaksi, latensi, dan pengalaman pengguna.

Prover dapat memengaruhi ketersediaan proof, waktu finality, dan biaya infrastruktur.

Rollup dapat kokoh secara teknis, tetapi tetap menghadapi risiko sentralisasi jika proving bergantung pada satu operator.

Riset terbaru seperti riset proving komunitas CrowdProve mengkaji bagaimana pekerjaan proving untuk ZK-rollup dapat didistribusikan ke banyak prover yang lebih kecil, alih-alih hanya mengandalkan infrastruktur terpusat.

Prover dalam Zero-Knowledge Proof

Dalam zero-knowledge proof, prover berupaya meyakinkan verifier bahwa suatu pernyataan benar tanpa mengungkapkan informasi tambahan di luar kebenaran pernyataan tersebut.

Prover mungkin mengetahui rahasia privat, data transaksi privat, atribut identitas privat, hasil komputasi privat, atau witness privat.

Proof seharusnya hanya mengungkapkan hal-hal yang memang dirancang untuk diungkapkan oleh sistem.

Misalnya, pengguna dapat membuktikan bahwa mereka mengetahui kata sandi yang valid tanpa mengungkapkan kata sandi tersebut.

Dalam kripto, pengguna dapat membuktikan bahwa transaksi mengikuti aturan tanpa mengungkapkan semua detail privatnya.

Tidak semua proof yang digunakan dalam rollup terutama ditujukan untuk privasi.

Banyak rollup menggunakan validity proof terutama untuk scaling dan memastikan kebenaran, bukan untuk menyembunyikan semua detail transaksi.

Karena itulah sebagian orang menggunakan istilah yang lebih luas, yaitu validity proof, ketika proof membuktikan eksekusi yang benar alih-alih privasi penuh.

Prover tetap merupakan komponen yang menghasilkan proof.

Penggunaan proof untuk privasi, scaling, atau keduanya bergantung pada desain protokol.

Prover dalam ZK-Rollup

Dalam ZK-rollup, prover menghasilkan proof bahwa batch transaksi off-chain telah diproses dengan benar.

Rollup mengeksekusi banyak transaksi di luar base chain.

Rollup kemudian mengirimkan data terkompresi dan validity proof ke base chain.

Base chain memverifikasi proof alih-alih mengeksekusi ulang setiap transaksi dalam batch.

Hal ini dapat mengurangi komputasi on-chain dan meningkatkan skalabilitas.

Prover merupakan salah satu bagian terpenting dalam ZK-rollup karena pengguna bergantung pada proof untuk memfinalisasi pembaruan state.

Jika pembuatan proof lambat, finality dapat tertunda.

Jika pembuatan proof mahal, biaya operasional rollup dapat meningkat.

Jika pembuatan proof terpusat, rollup mungkin terlalu bergantung pada satu penyedia infrastruktur.

Jika pembuatan proof gagal, rollup mungkin kesulitan mengirimkan pembaruan state valid yang baru.

Karena itulah desain prover, performa, desentralisasi, dan keandalannya menjadi topik utama dalam pengembangan Layer 2.

Prover dalam zkVM

zkVM adalah virtual machine zero-knowledge yang dapat membuktikan bahwa program dieksekusi dengan benar.

Alih-alih menulis circuit khusus untuk setiap tugas, developer dapat menjalankan kode di dalam virtual machine dan membuat proof bahwa kode tersebut dieksekusi dengan benar.

Dokumentasi developer RISC Zero menjelaskan komputasi terverifikasi sebagai cara untuk mendapatkan keyakinan kriptografis bahwa output data tertentu dihasilkan oleh algoritma tertentu.

Dalam zkVM, prover menjalankan program, mencatat eksekusinya, dan menghasilkan proof atas eksekusi tersebut.

Verifier kemudian dapat memeriksa proof tanpa menjalankan ulang seluruh program.

Model ini dapat membuat pengembangan ZK lebih mudah diakses karena developer dapat menggunakan bahasa pemrograman atau target virtual machine yang sudah dikenal.

Prover zkVM dapat digunakan untuk rollup, bridge, sistem identitas, aplikasi privasi, alur kerja AI terverifikasi, game terverifikasi, dan komputasi off-chain.

Namun, proving zkVM dapat membutuhkan banyak sumber daya.

Performanya bergantung pada ukuran program, penggunaan memori, sistem proof, perangkat keras, desain rekursi, dan pilihan optimasi.

Prover dalam Sistem STARK

Sistem berbasis STARK menggunakan jenis proof yang dapat diverifikasi tanpa bergantung pada asumsi trusted setup yang sama seperti beberapa sistem proof lainnya.

Dalam sistem STARK, prover mengubah komputasi menjadi proof berdasarkan kendala aljabar dan data trace.

Proof tersebut dapat menunjukkan bahwa program atau batch transaksi mengikuti aturan yang disyaratkan.

Dokumentasi SHARP dari Starknet menjelaskan verifier contract on-chain yang memverifikasi proof STARK yang dihasilkan SHARP.

SHARP adalah contoh infrastruktur proving bersama yang dapat menggabungkan dan membuktikan eksekusi dari beberapa program atau aplikasi.

Prover STARK dikenal memiliki karakteristik skalabilitas yang kuat dan keunggulan transparansi.

Bergantung pada konstruksinya, sistem ini juga dapat menghasilkan proof yang lebih besar daripada beberapa sistem SNARK.

Seperti sistem proof lainnya, kompromi praktisnya bergantung pada waktu proving, biaya verifikasi, ukuran proof, asumsi keamanan, dan pengalaman developer.

Prover adalah komponen yang menangani sebagian besar kompleksitas teknis ini agar verifier dapat memeriksa proof yang ringkas.

Prover dalam Sistem SNARK

Sistem SNARK menggunakan proof ringkas yang dapat berukuran sangat kecil dan cepat diverifikasi.

Dalam sistem SNARK, prover membuat proof ringkas bahwa suatu komputasi memenuhi serangkaian constraints.

Banyak sistem SNARK memerlukan trusted setup, meskipun desain yang lebih baru dapat mengurangi atau mengubah persyaratan tersebut.

Prover SNARK sering kali memerlukan proving key yang dihasilkan selama proses setup.

Verifier menggunakan verification key untuk memeriksa proof.

Prover SNARK dapat berguna ketika biaya verifikasi on-chain harus sangat rendah.

Hal ini penting karena blockchain base layer membebankan biaya untuk komputasi dan penyimpanan.

Proof kecil yang dapat diverifikasi dengan biaya rendah bisa membuat aplikasi canggih lebih praktis.

Namun, pembuatan proof tetap dapat mahal bagi prover.

Desain aplikasi berbasis SNARK harus menyeimbangkan ukuran proof, waktu proving, asumsi trusted setup, dan kompleksitas bagi developer.

Witness, Input Publik, dan Input Privat

Prover biasanya bekerja dengan input publik dan privat.

Input publik adalah nilai yang boleh dilihat verifier.

Input privat adalah nilai yang digunakan prover tetapi tidak diungkapkan secara langsung.

Input privat sering disebut witness.

Misalnya, dalam proof identitas privat, input publik dapat berupa ambang batas usia, sedangkan witness privat dapat berupa tanggal lahir atau data kredensial pengguna yang sebenarnya.

Dalam proof rollup, input publik dapat mencakup state root lama, state root baru, komitmen batch, atau parameter protokol.

Witness dapat mencakup detail transaksi, execution trace, Merkle path, tanda tangan, atau data komputasi perantara, bergantung pada desainnya.

Prover menggunakan witness untuk menghasilkan proof.

Verifier memeriksa apakah proof sesuai dengan input publik.

Sistem proof yang aman seharusnya tidak memungkinkan prover membuat proof valid untuk pernyataan yang salah.

Circuits dan Constraints

Banyak sistem proof mengharuskan komputasi dinyatakan sebagai circuit atau serangkaian constraints.

Circuit menjelaskan hal yang perlu dibuktikan dalam format yang dapat dipahami sistem proof.

Constraints menetapkan aturan yang harus dipenuhi oleh input valid dan langkah komputasi.

Misalnya, circuit dapat mengharuskan hash dihitung dengan benar, tanda tangan valid, atau pembaruan saldo mengikuti aturan protokol.

Prover harus menunjukkan bahwa terdapat witness yang memenuhi semua constraints.

Jika witness tidak memenuhi constraints, prover seharusnya tidak dapat menghasilkan proof valid.

Desain circuit merupakan salah satu bagian tersulit dalam pengembangan ZK.

Circuit yang ditulis dengan buruk dapat secara tidak sengaja membuktikan hal yang keliru.

Circuit juga dapat benar tetapi tidak efisien, sehingga prover menjadi lambat atau mahal.

Performa prover yang baik sering kali berawal dari desain circuit yang baik.

Execution Trace

Beberapa sistem proof menggunakan execution trace, bukan circuit khusus aplikasi yang tradisional.

Execution trace adalah catatan langkah-langkah komputasi yang dilakukan oleh program atau virtual machine.

Prover menggunakan trace untuk membuktikan bahwa setiap langkah mengikuti aturan mesin atau protokol.

Model ini umum digunakan dalam sistem STARK dan zkVM.

Pembuatan trace dapat menjadi hambatan performa utama karena program besar dapat menghasilkan trace berukuran besar.

Riset terbaru tentang virtual machine ZK berfokus pada peningkatan pembuatan trace, pipeline proving, dan akselerasi perangkat keras.

Trace yang efisien membantu mengurangi biaya dan latensi prover.

Untuk rollup, pembuatan trace yang lebih cepat dapat mempercepat pengiriman proof dan settlement.

Untuk aplikasi, trace yang lebih cepat dapat membuat komputasi terverifikasi lebih praktis bagi pengguna nyata.

Prover bertanggung jawab mengubah eksekusi mentah menjadi data yang siap digunakan untuk proof.

Performa Prover

Performa prover merupakan salah satu persoalan praktis terpenting dalam sistem kripto zero-knowledge.

Pembuatan proof dapat membutuhkan sumber daya CPU, GPU, memori, penyimpanan, dan perangkat keras khusus yang signifikan.

Beberapa sistem proof lebih cepat dalam proses proving, tetapi lebih lambat dalam verifikasi.

Beberapa sistem proof lebih lambat dalam proses proving, tetapi menghasilkan proof yang lebih kecil atau lebih murah.

Tim rollup sering mencurahkan banyak upaya rekayasa untuk mengoptimalkan pipeline prover.

Prover yang lebih cepat dapat mengurangi keterlambatan settlement.

Prover yang lebih murah dapat mengurangi biaya pengguna.

Prover yang lebih skalabel dapat mendukung lebih banyak transaksi dan aplikasi yang lebih kompleks.

Performa prover juga memengaruhi desentralisasi karena jika proving memerlukan perangkat keras yang sangat mahal, lebih sedikit peserta yang dapat menjalankan prover.

Hal ini dapat membuat jaringan lebih bergantung pada operator khusus.

Desentralisasi Prover

Desentralisasi prover berarti pembuatan proof tidak dikendalikan oleh satu pihak saja.

Dalam sistem ZK awal, infrastruktur proving sering kali terpusat karena teknologinya kompleks dan mahal untuk dioperasikan.

Seiring waktu, banyak proyek berupaya mendistribusikan proses proving secara lebih luas.

Proving terdistribusi dapat melibatkan beberapa prover, proof market, jaringan proving bersama, proving komunitas, atau persaingan antarpenyedia perangkat keras.

Proving terdesentralisasi dapat mengurangi risiko sensor, risiko liveness, dan ketergantungan pada satu operator.

Namun, pendekatan ini juga menimbulkan tantangan koordinasi.

Sistem harus menetapkan tugas proving, memverifikasi pekerjaan prover, membayar prover, mencegah spam, menangani tugas yang gagal, dan melindungi data witness sensitif jika diperlukan.

Riset proving komunitas mengkaji apakah banyak mesin yang lebih kecil dapat membantu menghasilkan proof untuk rollup.

Jika aspek ekonomi dan keamanannya berjalan baik, hal ini dapat membuat infrastruktur proving lebih terbuka.

Desentralisasi prover bukan hanya persoalan teknis karena juga bergantung pada insentif, tata kelola, akses ke perangkat keras, dan kemudahan penggunaan perangkat lunak.

Prover Market

Prover market adalah sistem tempat berbagai prover bersaing atau bekerja sama untuk menghasilkan proof bagi aplikasi.

Rollup, bridge, aplikasi zkVM, atau sistem privasi dapat mengirimkan tugas proving ke jaringan prover.

Prover dapat mengajukan penawaran untuk tugas tersebut atau dipilih berdasarkan aturan protokol.

Setelah prover menghasilkan proof yang valid, prover dapat menerima pembayaran.

Prover market dapat membantu mengurangi biaya dengan mendorong persaingan.

Prover market juga dapat meningkatkan keandalan karena aplikasi tidak terbatas pada satu server proving.

Namun, prover market memerlukan verifikasi yang kuat karena sistem harus menolak proof yang tidak valid dan menangani pekerjaan yang gagal.

Prover market juga memerlukan perlindungan privasi jika tugas proving berisi data witness sensitif.

Sebagian tugas proving dapat dialihdayakan dengan aman karena hanya melibatkan data publik.

Tugas proving lainnya memerlukan komputasi rahasia, witness terenkripsi, perangkat keras tepercaya, atau desain protokol yang cermat.

Recursive Proving

Recursive proving berarti menggunakan satu proof untuk memverifikasi proof lain, lalu membuktikan bahwa verifikasi tersebut benar.

Konsep ini mungkin terdengar abstrak, tetapi sangat berguna dalam sistem scaling.

Prover dapat menghasilkan banyak proof kecil, lalu menggabungkannya menjadi satu proof yang lebih besar.

Hal ini dapat membuat verifikasi lebih murah dan mengurangi jumlah data yang dikirimkan secara on-chain.

Recursive proof dapat membantu rollup menggabungkan banyak batch transaksi.

Recursive proof juga dapat membantu zkVM membuktikan komputasi panjang dalam bagian-bagian yang lebih kecil.

Recursive proving dapat meningkatkan skalabilitas, tetapi menambah kompleksitas teknis.

Pipeline prover harus mengelola komposisi proof, verification circuit, jadwal agregasi, dan kompromi performa.

Desain recursive proof juga dapat memengaruhi latensi karena proof akhir mungkin bergantung pada penyelesaian proof sebelumnya.

Bagi pengguna, recursive proving umumnya tidak terlihat, tetapi dapat memengaruhi kecepatan, biaya, dan finality.

Agregasi Proof

Agregasi proof adalah proses menggabungkan beberapa proof menjadi satu proof atau satu proses verifikasi.

Prover atau aggregator dapat mengambil banyak proof individual dan membuat satu proof yang mewakili semuanya.

Hal ini dapat mengurangi biaya verifikasi on-chain karena base chain memverifikasi satu proof agregat, bukan banyak proof terpisah.

Agregasi berguna untuk rollup, pool privasi, batch settlement, dan sistem pesan lintas blockchain.

Agregasi juga dapat mendukung infrastruktur proving bersama yang memungkinkan beberapa aplikasi memanfaatkan pipeline proving yang sama.

Komprominya, agregasi dapat menambah waktu tunggu karena sistem mungkin menunggu hingga cukup banyak proof terkumpul untuk digabungkan.

Agregasi juga dapat menciptakan ketergantungan pada aggregator atau layanan prover bersama.

Desain agregasi yang baik menyeimbangkan efisiensi, latensi, desentralisasi, dan keandalan.

Agregasi proof adalah salah satu alasan prover menjadi lapisan infrastruktur yang penting dalam kripto.

Semakin banyak aplikasi menggunakan ZK proof, semakin bernilai agregasi yang efisien.

Liveness Prover

Liveness prover adalah kemampuan sistem proving untuk terus menghasilkan proof saat dibutuhkan.

Jika rollup memerlukan proof untuk memfinalisasi batch, waktu henti prover dapat menunda settlement.

Jika bridge memerlukan proof untuk mencairkan dana, waktu henti prover dapat menunda penarikan.

Jika aplikasi privasi memerlukan proof untuk tindakan pengguna, waktu henti prover dapat menghalangi pengguna menyelesaikan transaksi.

Liveness bukan hanya soal keamanan matematis sistem proof.

Liveness juga berkaitan dengan kemampuan infrastruktur nyata untuk terus beroperasi saat menghadapi beban tinggi, gangguan, serangan, dan kegagalan perangkat keras.

Liveness prover dapat ditingkatkan melalui redundansi, proving terdistribusi, antrean tugas, prover cadangan, pemantauan, dan prosedur darurat yang jelas.

Pengguna perlu memahami bahwa sistem ZK mungkin meminimalkan kebutuhan untuk memercayai pihak lain terkait kebenaran, tetapi tetap bergantung pada infrastruktur proving agar dapat beroperasi tepat waktu.

Proof yang valid tidak akan membantu jika tidak ada yang membuatnya.

Karena itu, operasional prover merupakan bagian dari keandalan protokol.

Soundness Prover

Soundness adalah sifat yang memastikan prover tidak jujur seharusnya tidak dapat meyakinkan verifier bahwa pernyataan yang salah adalah benar.

Dalam kripto, soundness sangat penting karena proof palsu dapat memungkinkan transisi state tidak valid, penarikan palsu, saldo yang salah, atau tindakan tanpa izin.

Sistem proof dengan soundness yang lemah akan berbahaya meskipun cepat.

Soundness bergantung pada asumsi kriptografis, kualitas implementasi, pemilihan parameter, kebenaran circuit, dan kebenaran verifier.

Prover dapat bertindak jahat, tetapi verifier seharusnya menolak proof yang tidak valid.

Inilah alasan utama sistem proof sangat berguna.

Protokol tidak perlu memercayai kejujuran prover.

Protokol hanya perlu memastikan sistem proof dan verifier aman.

Namun, jika circuit membuktikan pernyataan yang keliru, proof dapat valid untuk circuit tersebut tetapi tetap tidak melindungi aplikasi.

Soundness harus dipertimbangkan baik pada tingkat sistem proof maupun desain aplikasi.

Kelengkapan Prover

Kelengkapan berarti prover yang jujur seharusnya dapat menghasilkan proof untuk pernyataan yang benar.

Jika suatu komputasi valid dan prover memiliki witness yang benar, sistem proving seharusnya menghasilkan proof yang diterima verifier.

Kelengkapan penting karena sistem yang menolak proof valid atau gagal menghasilkannya dengan andal tidak dapat digunakan.

Untuk rollup, kelengkapan yang buruk dapat berarti batch transaksi valid tidak dapat difinalisasi.

Untuk aplikasi privasi, pengguna yang jujur mungkin tidak dapat membuktikan tindakan yang valid.

Untuk zkVM, program yang benar mungkin gagal dibuktikan karena bug implementasi atau keterbatasan sumber daya.

Kelengkapan bergantung pada perangkat lunak yang benar, memori yang memadai, komputasi yang cukup, parameter proof yang kompatibel, dan infrastruktur yang stabil.

Dalam praktiknya, developer menguji sistem proving secara menyeluruh untuk memastikan beban kerja valid dapat dibuktikan dengan andal.

Prover harus aman terhadap proof palsu sekaligus praktis untuk menghasilkan proof yang benar.

Desain prover yang baik menyeimbangkan keamanan dan kemudahan penggunaan.

Zero-Knowledge Prover

Zero-knowledge adalah sifat proof yang tidak mengungkapkan informasi yang tidak diperlukan, selain kebenaran dari pernyataan yang dibuktikan.

Sifat ini penting ketika witness berisi data privat.

Prover mungkin mengetahui kunci rahasia, nilai transaksi tersembunyi, atribut identitas privat, atau input komputasi rahasia.

Zero-knowledge proof seharusnya memungkinkan prover membuktikan klaim yang diperlukan tanpa mengungkapkan rahasia tersebut.

Tidak semua validity proof dalam kripto memerlukan privasi yang kuat.

Beberapa sistem menggunakan teknologi proof terutama karena dapat membuat verifikasi lebih murah.

Jika privasi dibutuhkan, developer harus merancang circuit, input publik, penanganan metadata, dan antarmuka pengguna dengan cermat.

Proof dapat bersifat zero-knowledge, tetapi data lain di sekitarnya tetap dapat membocorkan informasi.

Misalnya, waktu transaksi, alamat wallet, data IP, atau pola transaksi masih dapat mengungkap perilaku pengguna.

Prover dapat melindungi witness secara matematis, tetapi seluruh aplikasi harus melindungi privasi dari sisi operasional.

Perangkat Keras untuk Prover

Prover dapat menggunakan CPU, GPU, FPGA, ASIC, atau infrastruktur cloud, bergantung pada sistem proof dan beban kerjanya.

Pembuatan proof dapat melibatkan operasi matematis berskala besar seperti aritmetika finite field, komitmen polinomial, hashing, fast Fourier transform, dan pemrosesan trace.

Tugas-tugas ini dapat memanfaatkan paralelisasi dan perangkat keras khusus.

Akselerasi perangkat keras dapat mengurangi waktu dan biaya proving.

Namun, hal ini juga dapat mendorong sentralisasi jika hanya operator dengan pendanaan besar yang mampu membeli perangkat keras proving terbaik.

Beberapa proyek berupaya mengurangi masalah ini dengan meningkatkan efisiensi perangkat lunak dan mendukung perangkat keras umum.

Proyek lainnya menggunakan klaster proving khusus untuk throughput tinggi.

Pilihan perangkat keras bergantung pada tujuan jaringan.

Sistem yang dirancang untuk throughput maksimum dapat menerima infrastruktur proving yang lebih khusus.

Sistem yang dirancang untuk partisipasi luas dapat memprioritaskan desain prover yang dapat berjalan di lebih banyak mesin yang mudah diakses.

Biaya dan Ekonomi Prover

Pengoperasian prover memerlukan biaya.

Prover membutuhkan perangkat keras, listrik, bandwidth, rekayasa, pemeliharaan, dan pemantauan.

Dalam rollup, biaya proving dapat dibayar melalui biaya transaksi, pendapatan protokol, subsidi, atau dana operator.

Dalam prover market, prover dapat dibayar langsung untuk tugas proof yang diselesaikan.

Ekonomi prover penting karena biaya proving yang tinggi dapat meningkatkan biaya pengguna.

Biaya tersebut juga dapat membatasi aplikasi yang layak dijalankan.

Game, aplikasi sosial, atau sistem pembayaran bernilai rendah mungkin tidak berjalan dengan baik jika setiap tindakan membutuhkan pembuatan proof yang mahal.

Developer sering mengoptimalkan circuit, mengelompokkan pekerjaan, mengagregasikan proof, dan menggunakan rekursi untuk mengurangi biaya proving per transaksi.

Pengguna mungkin tidak melihat biaya prover secara langsung, tetapi dapat merasakannya melalui biaya transaksi, keterlambatan settlement, atau batasan aplikasi.

Proving yang efisien merupakan salah satu kunci agar aplikasi ZK dapat digunakan secara luas.

Risiko Keamanan Prover

Risiko pertama prover adalah bug implementasi.

Prover yang memiliki bug dapat menghasilkan proof yang salah, gagal saat beban tinggi, atau mengungkap data witness sensitif.

Risiko kedua adalah proving terpusat.

Jika hanya satu operator yang dapat menghasilkan proof, sistem dapat mengalami waktu henti atau sensor jika operator tersebut gagal.

Risiko ketiga adalah kebocoran witness.

Jika layanan proving menerima input privat, keamanan yang buruk dapat mengungkap data pengguna.

Risiko keempat adalah bug circuit.

Prover dapat menghasilkan proof valid untuk circuit yang salah jika circuit tidak menerapkan aturan yang dimaksud.

Risiko kelima adalah kompromi perangkat keras.

Mesin proving yang disusupi dapat membocorkan rahasia, menunda tugas, atau menyerang infrastruktur aplikasi.

Risiko keenam adalah kegagalan ekonomi.

Jika bayaran prover tidak memadai, kapasitas proving bisa terlalu rendah.

Risiko ketujuh adalah risiko upgrade.

Perubahan pada perangkat lunak proving, circuit, atau verifier contract dapat menimbulkan kerentanan baru.

Prover dan Ketersediaan Data

Prover membuktikan kebenaran, tetapi tidak otomatis menjamin ketersediaan data.

Ketersediaan data berarti data transaksi atau state yang diperlukan untuk merekonstruksi atau memverifikasi state sistem dapat diakses pengguna atau node.

Perbedaan ini penting dalam rollup.

Validity proof dapat menunjukkan bahwa transisi state valid, tetapi pengguna juga memerlukan data yang cukup untuk mengetahui saldo, keluar dari posisi, atau membangun kembali state.

Desain rollup dan scaling yang berbeda menangani ketersediaan data dengan cara yang berbeda.

Sebagian mengirimkan data ke base chain.

Sebagian menggunakan lapisan ketersediaan data terpisah.

Sebagian menggunakan komite atau model lainnya.

Prover bertanggung jawab membuktikan suatu pernyataan, bukan menyelesaikan semua masalah ketersediaan data sendirian.

Sistem scaling yang aman memerlukan proof valid dan data yang tersedia.

Prover dan Finality

Finality berarti transaksi atau pembaruan state diterima sebagai telah diselesaikan berdasarkan aturan jaringan.

Dalam sistem berbasis validity proof, pembuatan proof dapat memengaruhi waktu finality.

Batch dapat dieksekusi dengan cepat di Layer 2, tetapi settlement akhir di base chain mungkin harus menunggu proof.

Jika prover bekerja cepat, settlement dapat berlangsung lebih awal.

Jika prover lambat atau kelebihan beban, pengguna mungkin harus menunggu lebih lama untuk konfirmasi akhir atau penarikan.

Recursive proof dan agregasi proof dapat meningkatkan efisiensi, tetapi mungkin menambah waktu tunggu untuk batching.

Finality juga bergantung pada waktu blok base chain, aturan konfirmasi, dan eksekusi verifier contract.

Prover hanyalah salah satu bagian dari pipeline finality.

Meski demikian, kecepatan prover sering menjadi salah satu hambatan paling terlihat dalam sistem ZK.

Prover yang lebih baik dapat membuat aplikasi ZK terasa lebih cepat dan andal.

Prover dan Bridge

Prover dapat digunakan dalam bridge untuk membuktikan peristiwa, transisi state, atau pesan dari satu chain ke chain lain.

Bridge berbasis proof dapat memungkinkan satu chain memverifikasi fakta tentang chain lain tanpa memercayai sekelompok signer terpusat.

Misalnya, prover dapat menghasilkan proof bahwa transaksi, state root, atau pesan tertentu valid di chain sumber.

Verifier contract di chain tujuan kemudian dapat memeriksa proof tersebut.

Hal ini dapat mengurangi asumsi kepercayaan dibandingkan dengan beberapa model bridge.

Namun, bridge berbasis proof tetap kompleks.

Bridge harus menangani reorg chain, asumsi finality, kebenaran verifier, ketersediaan data, biaya proof, dan risiko upgrade.

Prover dapat meningkatkan asumsi kepercayaan pada bridge, tetapi tidak otomatis membuat desain bridge aman.

Pengguna tetap perlu memperlakukan sistem lintas blockchain sebagai infrastruktur berisiko tinggi.

Keamanan bridge bergantung pada seluruh arsitektur, bukan hanya keberadaan prover.

Prover dan Privasi

Dalam aplikasi kripto yang berfokus pada privasi, prover dapat membantu pengguna membuktikan kepatuhan terhadap aturan sambil menyembunyikan informasi sensitif.

Misalnya, pengguna dapat membuktikan bahwa mereka memiliki kredensial tanpa mengungkapkan seluruh kredensial tersebut.

Pengguna dapat membuktikan bahwa saldo transaksi valid tanpa mengungkapkan semua detail transaksi privat.

Pengguna dapat membuktikan bahwa mereka merupakan anggota suatu grup tanpa mengungkapkan siapa anggota yang dimaksud.

Prover membuat proof menggunakan input privat.

Verifier memeriksa proof menggunakan aturan publik.

Dengan demikian, pengungkapan selektif dapat dilakukan.

Namun, privasi tidak hanya bergantung pada proof itu sendiri.

Metadata, aktivitas jaringan, waktu transaksi, penggunaan ulang alamat, fingerprinting browser, dan log aplikasi tetap dapat membocorkan informasi.

Sistem privasi yang kuat harus melindungi seluruh perjalanan pengguna, bukan hanya witness kriptografis.

Prover dan Kepatuhan

Prover dapat mendukung desain kripto yang ramah kepatuhan dengan membuktikan fakta tanpa mengungkap data privat yang tidak diperlukan.

Misalnya, pengguna dapat membuktikan bahwa mereka memenuhi persyaratan kelayakan tanpa mengungkapkan dokumen identitas lengkap secara on-chain.

Protokol dapat membuktikan bahwa suatu komputasi mengikuti seperangkat aturan tanpa mengungkap data bisnis privat.

Aplikasi keuangan dapat membuktikan bahwa transisi state memenuhi constraints akuntansi tanpa memublikasikan setiap catatan internal.

Ini bukan berarti zero-knowledge proof otomatis menyelesaikan semua masalah kepatuhan.

Persyaratan hukum berbeda-beda bergantung pada yurisdiksi dan kasus penggunaan.

Beberapa aturan mungkin tetap mewajibkan pencatatan, audit, pemeriksaan identitas, pelaporan, atau pengungkapan.

Prover dapat mengurangi paparan data yang tidak perlu, tetapi tidak menggantikan analisis hukum.

Desain kepatuhan yang baik perlu menggabungkan kriptografi, kebijakan, tata kelola, dan persetujuan pengguna.

Prover dapat memungkinkan verifikasi selektif, tetapi manusia tetap menentukan hal yang perlu dibuktikan.

Manfaat Prover

Manfaat pertama prover adalah skalabilitas.

Prover dapat memadatkan komputasi besar menjadi proof yang lebih murah untuk diverifikasi.

Manfaat kedua adalah privasi.

Jika sistem proof dirancang untuk zero-knowledge, prover dapat membuktikan fakta tentang data privat tanpa mengungkapkan data itu sendiri.

Manfaat ketiga adalah minimisasi kepercayaan.

Verifier tidak perlu memercayai kejujuran prover jika proof yang tidak valid ditolak.

Manfaat keempat adalah interoperabilitas.

Proof dapat membantu satu sistem memverifikasi fakta tentang sistem lain.

Manfaat kelima adalah kemampuan audit.

Proof dapat memberikan bukti matematis bahwa suatu komputasi mengikuti aturan yang telah ditetapkan.

Manfaat keenam adalah otomatisasi.

Smart contract dapat memverifikasi proof dan menindaklanjutinya tanpa peninjauan manual.

Manfaat ketujuh adalah efisiensi.

Agregasi proof dan rekursi dapat mengurangi biaya verifikasi berulang untuk banyak transaksi atau aplikasi.

Keterbatasan Prover

Keterbatasan pertama adalah biaya.

Pembuatan proof dapat membutuhkan banyak komputasi.

Keterbatasan kedua adalah latensi.

Pembuatan proof membutuhkan waktu dan dapat menunda settlement atau penarikan.

Keterbatasan ketiga adalah kompleksitas.

Sistem prover membutuhkan kriptografi khusus, rekayasa, dan peninjauan keamanan.

Keterbatasan keempat adalah tekanan sentralisasi.

Persyaratan perangkat keras yang tinggi dapat menyulitkan banyak pihak independen untuk menjalankan prover.

Keterbatasan kelima adalah ketergantungan pada circuit.

Proof hanya membuktikan hal yang benar-benar diperiksa oleh circuit atau program.

Keterbatasan keenam adalah kebocoran privasi di luar proof.

Zero-knowledge proof tidak otomatis menyembunyikan metadata atau mengatasi desain aplikasi yang buruk.

Keterbatasan ketujuh adalah risiko upgrade.

Perubahan pada perangkat lunak proving, circuit, atau verifier contract dapat menciptakan asumsi keamanan baru.

Cara Pengguna Memahami Prover

Sebagian besar pengguna tidak berinteraksi langsung dengan prover.

Mereka berinteraksi dengan wallet, rollup, bridge, aplikasi privasi, atau aplikasi terdesentralisasi yang menggunakan prover di balik layar.

Pengguna tetap perlu memahami peran prover karena prover memengaruhi kecepatan, biaya, finality, dan asumsi kepercayaan.

Jika rollup bergantung pada satu prover terpusat, pengguna perlu memahami apa yang terjadi jika prover tersebut offline.

Jika aplikasi privasi menggunakan layanan proving jarak jauh, pengguna perlu memahami apakah data privat dikirimkan ke layanan tersebut.

Jika bridge mengandalkan proof, pengguna perlu memahami hal yang diverifikasi oleh proof dan hal yang tidak diverifikasi.

Pengguna juga perlu memeriksa apakah verifier contract telah diaudit dan apakah sistem proving memiliki model keamanan yang jelas.

Keberadaan prover bukan jaminan keamanan ajaib.

Prover hanya bernilai jika sistem proof, circuit, verifier, ketersediaan data, dan tata kelola dirancang dengan benar.

Pengguna perlu menganggap proving sebagai salah satu lapisan keamanan, bukan keseluruhan sistem.

Praktik Terbaik bagi Developer

Developer harus mendefinisikan dengan jelas pernyataan yang harus dibuktikan prover.

Developer harus merancang circuit atau program yang menerapkan aturan yang dimaksud secara tepat.

Developer harus menggunakan sistem proving yang telah ditinjau dengan baik dan menghindari kriptografi khusus kecuali telah mendapat peninjauan ahli.

Developer harus menguji pembuatan proof dengan beban kerja realistis, edge case, dan kondisi kegagalan.

Developer harus mengukur waktu prover, penggunaan memori, kebutuhan perangkat keras, dan biaya verifikasi.

Developer harus melindungi witness privat saat proses proving melibatkan data pengguna yang sensitif.

Developer harus mendokumentasikan input publik agar pengguna dan auditor memahami hal yang benar-benar diperiksa verifier.

Jika memungkinkan, developer harus memisahkan infrastruktur prover dari wewenang admin yang tepercaya.

Developer harus menyiapkan rencana untuk mengatasi waktu henti prover, percobaan ulang tugas, pemantauan, dan fallback darurat.

Developer harus menjelaskan risiko upgrade saat mengubah circuit, proving key, verifier contract, atau perangkat lunak prover.

Kesalahpahaman Umum tentang Prover

Salah satu kesalahpahaman adalah bahwa prover harus dipercaya.

Dalam sistem proof yang dirancang dengan baik, verifier seharusnya menolak proof yang tidak valid meskipun prover tidak jujur.

Kesalahpahaman lainnya adalah bahwa prover selalu memberikan privasi.

Sebagian prover menghasilkan validity proof untuk skalabilitas tanpa menyembunyikan semua data transaksi.

Kesalahpahaman lainnya adalah bahwa pembuatan proof itu murah.

Proving dapat jauh lebih mahal daripada verifikasi dan mungkin membutuhkan infrastruktur khusus.

Kesalahpahaman lainnya adalah bahwa proof valid membuktikan segala hal tentang suatu aplikasi.

Proof hanya membuktikan pernyataan tertentu yang dikodekan dalam circuit atau program.

Kesalahpahaman lainnya adalah bahwa desentralisasi prover sudah teratasi di semua sistem.

Banyak sistem masih berupaya membangun infrastruktur proving yang lebih terbuka dan terdesentralisasi.

Kesalahpahaman lainnya adalah bahwa pengguna tidak perlu memedulikan prover.

Pengguna mungkin tidak menjalankan prover, tetapi desain prover dapat memengaruhi penarikan, finality, biaya, privasi, dan keandalan aplikasi.

FAQ

Apa arti prover dalam kripto?

Prover adalah aktor, program, node, atau layanan yang menghasilkan proof kriptografis untuk menunjukkan bahwa suatu pernyataan, komputasi, atau transisi state valid.

Apa itu prover dalam zero-knowledge proof?

Dalam zero-knowledge proof, prover membuat proof untuk meyakinkan verifier bahwa suatu pernyataan benar tanpa mengungkapkan informasi privat yang tidak diperlukan.

Apa perbedaan prover dan verifier?

Prover membuat proof, sedangkan verifier memeriksa apakah proof tersebut valid.

Mengapa prover penting bagi ZK-rollup?

Prover penting bagi ZK-rollup karena menghasilkan validity proof yang memungkinkan batch transaksi di-settle pada base chain tanpa setiap node mengeksekusi ulang semua transaksi.

Apakah prover sama dengan sequencer?

Tidak. Sequencer mengurutkan transaksi, sedangkan prover menghasilkan proof kriptografis atas eksekusi yang benar atau transisi state yang valid.

Apakah prover selalu menyembunyikan data privat?

Tidak. Sebagian prover terutama digunakan untuk skalabilitas dan memastikan kebenaran, sedangkan privasi bergantung pada apakah sistem proof dan aplikasi dirancang untuk zero-knowledge.

Bisakah prover yang tidak jujur membuat proof palsu?

Sistem proof yang aman seharusnya mencegah prover yang tidak jujur membuat proof valid untuk pernyataan yang salah.

Mengapa proving mahal?

Proving dapat mahal karena mungkin membutuhkan komputasi berskala besar, pembuatan trace yang menggunakan banyak memori, operasi polinomial, hashing, rekursi, dan perangkat keras khusus.

Apa itu witness dalam proses proving?

Witness adalah data privat atau internal yang digunakan prover untuk membuat proof tanpa harus mengungkapkan data tersebut kepada verifier.

Apa itu recursive proving?

Recursive proving adalah proses membuktikan bahwa proof lain valid, yang dapat membantu menggabungkan banyak proof menjadi proof yang lebih kecil atau lebih efisien.

Apa yang terjadi jika prover rollup offline?

Jika rollup bergantung pada prover tersebut, pengiriman proof dan settlement akhir dapat tertunda hingga kapasitas proving kembali tersedia atau prover cadangan digunakan.

Apakah prover terdesentralisasi memungkinkan?

Ya. Proving terdesentralisasi merupakan bidang pengembangan dan riset aktif, tetapi memerlukan solusi untuk penugasan pekerjaan, pembayaran, keandalan, privasi, dan verifikasi.

Kesimpulan

Prover merupakan salah satu peran infrastruktur terpenting dalam sistem proof kripto modern.

Prover menghasilkan proof kriptografis yang memungkinkan verifier memastikan kebenaran pernyataan, komputasi, batch transaksi, atau transisi state tanpa mengulangi seluruh pekerjaan yang mendasarinya.

Prover menjadi bagian penting dalam zero-knowledge proof, ZK-rollup, zkVM, sistem STARK, sistem SNARK, agregasi proof, recursive proving, protokol privasi, bridge, dan komputasi terverifikasi.

Nilai utama prover adalah memindahkan komputasi berat dari verifier sambil menjaga agar verifikasi tetap dapat dipercaya.

Hal ini dapat meningkatkan skalabilitas, mengurangi pekerjaan on-chain, mendukung privasi, dan memungkinkan desain aplikasi baru.

Namun, prover juga menghadirkan tantangan nyata.

Pembuatan proof dapat mahal, lambat, membutuhkan banyak perangkat keras, kompleks secara operasional, dan terkadang terpusat.

Manfaat proof bergantung pada pernyataan yang dibuktikan, circuit atau program yang diperiksa, verifier yang memvalidasinya, dan infrastruktur yang menjaga agar proses proving tetap berjalan.

Pelajaran terpenting bagi pengguna adalah prover membantu membuat verifikasi kriptografis lebih efisien, tetapi tidak menghilangkan semua risiko dalam rollup, bridge, aplikasi privasi, atau sistem smart contract.

Pelajaran terpenting bagi developer adalah desain prover harus aman, efisien, teruji dengan baik, memperhatikan privasi, dan terdokumentasi dengan jelas.

Cara termudah memahami prover adalah bahwa prover melakukan pekerjaan matematis yang sulit agar bagian lain dari jaringan kripto dapat memverifikasi hasilnya dengan cepat dan tanpa perlu memercayai pihak tertentu.