Dalam pos sebelumnya kami membahas peran konsensus bukti dari metode trust minimization yang sedang berkembang ini dalam memfasilitasi jembatan antara blockchain.

Dalam artikel ini, kami akan menjelajahi bukti penyimpanan, yang mengambil konsep verifikasi minimisasi kepercayaan dan memperluasnya ke transaksi di blok-blok sejarah yang lebih tua. Kemampuan untuk memverifikasi transaksi masa lalu dan aktivitas pengguna dengan cara ini membuka sejumlah besar kasus penggunaan lintas-rantai.

Di kamiposting sebelumnya, kami memperkenalkan Proof of Consensus — pendekatan yang meminimalkan kepercayaan untuk memosting dana di seluruh blockchain. Karena pengguna jembatan biasanya ingin melihat transaksi terjadi segera pada saat terbaru, pembuktian konsensus sangat berguna karena mereka secara konstan memeriksa keadaan terbaru blockchain saat beroperasi.

Konsep minimisasi kepercayaan dalam jembatan juga dapat diterapkan dalam arah lain, yaitu kembali ke masa lalu dan menggunakan bukti pengetahuan nol untuk memverifikasi transaksi dan data dalam blok lama. Bukti penyimpanan historis ini mendukung beragam kasus penggunaan lintas-rantai, dan dalam artikel ini kami akan mencakup kasus penggunaan ini, bagaimana cara kerjanya, dan aktor yang dibangun di ruang ini.

Mengambil data historis

Ada banyak kegunaan untuk data blockchain historis. Ini dapat digunakan untuk membuktikan kepemilikan aset, perilaku pengguna, dan riwayat transaksi, dan kemudian memasukkan ini ke dalam kontrak pintar on-chain atau aplikasi.Saat tulisan ini dibuat, lebih dari 18 juta blok telah ditulis ke Ethereum.Kontrak pintar hanya dapat mengakses 256 blok terbaru (atau data dalam 30 menit terakhir), jadi "data historis" merujuk pada apa pun selain 256 blok terakhir.

Hari ini, untuk mengakses data historis, protokol sering kali melakukan kueri node arsippenyedia, yaitu pihak ketiga seperti Infura, Alchemy, atau indexer lainnya. Itu berarti mempercayai dan bergantung pada mereka dan data mereka.

Data historis

Data ini dapat, bagaimanapun, lebih santai dalam gaya yang lebih terpercaya, melalui penggunaan bukti penyimpanan.

Data historis

Namun, data ini dapat diambil dengan cara yang lebih minim kepercayaan dengan menggunakan bukti penyimpanan.

Bukti penyimpanan adalah bukti pengetahuan nol yang memungkinkan verifikasi data historis yang disimpan di blockchain. Lebih spesifik lagi, bukti penyimpanan dapat digunakan untuk membuktikan keberadaan suatu keadaan tertentu pada blok tertentu di masa lalu.Pendekatan ini tidak memerlukan kepercayaan pada pihak ketiga atau orakel; sebaliknya, kepercayaannya terbangun ke dalam bukti penyimpanan.

Bagaimana bukti penyimpanan dapat membantu memverifikasi bahwa beberapa data ada di blok historis yang lebih lama? Ini memerlukan verifikasi dua hal:

• Langkah pertama adalah memeriksa apakah blok tertentu adalah bagian dari sejarah regulasi blockchain, yaitu, blok tersebut adalah bagian valid dari sejarah rantai sumber
• Langkah kedua adalah memeriksa apakah data spesifik adalah bagian dari blok, yaitu, sebuah informasi (seperti transaksi tertentu) adalah bagian dari blok (ini dapat dibuktikan dengan menyertakan bukti Merkle)

Setelah menerima dan memverifikasi bukti tersebut, penerima (seperti kontrak pintar di rantai target) percaya pada validitas data dan dapat menjalankan rangkaian instruksi yang sesuai. Konsep ini bahkan dapat diperluas lebih jauh: perhitungan di luar rantai tambahan dapat dijalankan dengan data yang divalidasi, kemudian bukti pengetahuan nol lainnya dihasilkan untuk membuktikan data dan perhitungan.

Secara sederhana, bukti penyimpanan mendukung pengambilan data pada rantai historis dengan cara yang meminimalkan kepercayaan. Hal ini penting karena, seperti yang kami garis bawahi dalam pos pertama kami, kita melihat web3 menjadi ruang yang lebih multi-rantai dan multi-tiered dalam beberapa tahun mendatang. Kemunculan berbagai protokol lapisan 1, rollups, dan rantai aplikasi berarti aktivitas on-chain pengguna dapat tersebar di beberapa rantai. Hal ini lebih menekankan perlunya solusi interoperabilitas yang meminimalkan kepercayaan yang mempertahankan komposabilitas aset pengguna, identitas, dan riwayat transaksi di berbagai domain. Ini adalah masalah yang bisa diselesaikan oleh bukti penyimpanan.

Apa saja kasus penggunaan untuk bukti penyimpanan?

Bukti penyimpanan memungkinkan kontrak pintar untuk memeriksa transaksi atau data historis apa pun sebagai prasyarat. Hal ini membuat desain aplikasi lintas-rantai lebih fleksibel.

Pertama, menyimpan bukti dapat membuktikan data historis apa pun pada blockchain sumber, seperti

1. Saldo akun dan kepemilikan token
2. Aktivitas perdagangan pengguna atau keadaan statis
3. Harga historis dari transaksi aset selama periode waktu tertentu
4. Saldo aset real-time kolam likuiditas lintas-rantai

Bukti kemudian dapat dikirimkan ke rantai target untuk membuka berbagai kasus penggunaan lintas-rantai:

1. Memungkinkan pengguna untuk memberikan suara pada proposal tata kelola di perjanjian lapisan 2 dengan biaya lebih rendah
2. Mengizinkan pemegang NFT untuk menerima NFT baru atau manfaat komunitas di rantai baru
3. Hadiah pengguna berdasarkan riwayat dan interaksi mereka dengan dApps spesifik (misalnya melalui airdrops)
4. Pinjaman yang menawarkan tingkat bunga kustom berdasarkan transaksi dan riwayat kredit keseluruhan pengguna
5. Memicu pemulihan akun untuk akun yang tidak aktif
6. Menghitung riwayat futures swaps TWAP
7. Hitung harga tukar AMM yang lebih akurat berdasarkan kolam likuiditas multi-rantai

Pada dasarnya, bukti penyimpanan memungkinkan aplikasi untuk mengakses dan memindahkan aktivitas dan riwayat pengguna di rantai-rantai yang berbeda untuk dimasukkan ke dalam kontrak pintar atau aplikasi di rantai lain.

Kasus penggunaan bukti penyimpanan

Mari kita ambil contoh detail untuk memahami bagaimana bukti penyimpanan bekerja.

Bagaimana Proof of Storage Bekerja: Contoh Terperinci

Asumsikan “X,” yang merupakan protokol DeFi dengan token di Ethereum. Usulan tata kelola akan segera diajukan, dan mereka ingin mempromosikan pemungutan suara on-chain pada rantai target biaya yang lebih rendah. Pengguna hanya dapat memberikan suara jika mereka memiliki token X di Ethereum pada titik waktu tertentu (kami menyebutnya “snapshot”), seperti blok #17 ,000,000

Bagaimana cara pemungutan suara dilakukan saat ini di rantai?

Pendekatan saat ini adalah dengan mengajukan permintaan pada node arsip untuk mendapatkan daftar lengkap pemegang token yang memenuhi syarat di blok #17.000.000. Administrator DAO kemudian menyimpan daftar tersebut di kontrak pintar di rantai target untuk menentukan siapa yang dapat memberikan suara. Ada beberapa keterbatasan pada pendekatan ini:

1. Daftar pemilih dapat sangat panjang, dan setiap snapshot berubah, membuatnya mahal untuk menyimpan dan memperbarui setiap proposal pemungutan suara di rantai;
2. Ada kepercayaan implisit pada penyedia node arsip dan data yang disediakannya;
3. Anggota yang mengelola DAO harus dipercaya untuk tidak mencampuri daftar pemilih

Bagaimana proof of storage menyelesaikan masalah ini?

Seperti yang kami jelaskan dalam artikel 2, perhitungan yang mahal dapat dipindahkan ke bukti pengetahuan nol di luar rantai.

ZK Attestor akan menghasilkan bukti yang ringkas dan mengirimkannya ke rantai target untuk verifikasi. Untuk contoh kelayakan pemilih DAO di atas, berikut adalah:

1. Attestor menghasilkan bukti pengetahuan nol bahwa blok #17,000,000 adalah bagian dari sejarah Ethereum (seperti langkah pertama di atas).
2. Setelah membuktikan kevalidan blok, kita dapat menggunakan Merkle untuk menyertakan bukti bahwa pengguna memiliki token DAO saat blok tersebut difinalisasi (seperti pada langkah 2 di atas*)

Memverifikasi data historis untuk memungkinkan pemungutan suara lintas rantai

Bukti tersebut kemudian dikirim ke kontrak pintar di rantai target untuk verifikasi. Jika verifikasi berhasil, maka kontrak pintar pada protokol lapisan 2 memungkinkan pengguna untuk memberikan suara.

Pendekatan ini menyelesaikan beberapa isu. Ini tidak memerlukan:

Percayalah pada penyedia node arsip;

1. Biarkan kesepakatan mempertahankan daftar pemilih on-chain yang mahal;
2. Untuk pengguna mentransfer aset ke rantai tujuan

Pengaturan apa yang diperlukan untuk bukti penyimpanan?

Sejauh ini, kami telah mengabstraksikan beberapa kompleksitas bukti penyimpanan. Namun, penggunaannya juga memerlukan pengaturan awal yang hati-hati oleh penyedia layanan untuk memastikan bahwa mereka dapat digunakan tanpa harus mempercayai penyedia. Dua hal dihasilkan dan disimpan on-chain selama proses ini:

1. Bukti pengetahuan nol rantai lengkap ("janji zk"): Penyedia layanan mengelompokkan semua blok historis di rantai sumber ke dalam "blok" berukuran tetap yang kontinu (menggunakan pohon Merkle)dan menghasilkan bukti nol pengetahuan untuk setiap blok, yang digunakan untuk memverifikasi pengelompokan. Bukti-bukti ini kemudian digabungkan secara rekursif hingga diperoleh bukti nol pengetahuan akhir, sebuah 'janji zk' untuk seluruh rantai. Ini membuktikan bahwa penyedia telah dengan benar mengindeks seluruh sejarah rantai.

Janji 'zk' menjelaskan seluruh sejarah Ethereum

• **Merkle Mountain Range: ** Penyedia juga menyimpan akar Merkle Keccak dari hash blok rantai sumber (blok) yang dikelompokkan bersama dalam struktur data on-chain yang disebut Merkle Mountain Range (MMR). Struktur data ini digunakan karena mudah untuk ditanyakan dan diperbarui, dan memungkinkan penyedia untuk membuktikan secara efektif bahwa blok tertentu ada dalam sejarah rantai. MMR dibuat menggunakan hash Keccak256, hash Poseidon, atau keduanya. Hash Poseidon lebih ramah zero-knowledge dan mendukung perhitungan data historis. Validitas data dan perhitungan tersebut kemudian dapat dibuktikan melalui zero-knowledge.

Ilustrasi Rangkaian Pegunungan Merkel (MMR)

Saat blok baru ditambahkan ke rantai sumber, penyedia layanan secara teratur (seperti setiap jam atau setiap hari) memperbarui "komitmen zk" dan MMR untuk menyesuaikan diri dengan kecepatan rantai. Hal ini dilakukan agar blok masa lalu selalu terhubung ke salah satu dari 256 blok yang saat ini dapat diakses dari EVM. Hal ini memastikan bahwa data historis terhubung ke salah satu blok yang saat ini tersedia di Ethereum.

Dalam gambar di bawah, kami telah menjelaskan bagaimana menyelesaikan pengaturan:

Secara ringkas, berikut ini menunjukkan bagaimana menggunakan bukti penyimpanan setelah penyiapan selesai dalam konteks contoh pemungutan suara DAO yang telah kita bahas sebelumnya:

1. Penyedia layanan membuat dan menyimpan "janji zk" untuk seluruh rantai (yaitu sejarah Ethereum) dan MMR di rantai target
2. Penyedia memungkinkan aplikasi untuk mengambil data historis on-chain atau off-chain melalui API
3. Aplikasi voting dApp pada rantai tujuan mengirimkan kueri ke kontrak pintar penyedia untuk mencari tahu apakah pengguna memiliki token DAO pada blok #17.000.000 pada Ethereum

Penyedia akan memeriksa dua hal:

1. Blok yang ditanyakan adalah bagian dari sejarah regulasi Ethereum (langkah pertama di atas); penyedia kemudian menghasilkan bukti pengetahuan nol dari konten blok melalui Merkle Mountain Range
2. Pengguna memiliki token DAO di blok #17 ,000,000 (langkah 2 di atas); penyedia kemudian menghasilkan bukti pengetahuan nol lainnya bahwa pengguna memiliki token DAO dalam blok
3. Penyedia menggabungkan bukti yang dihasilkan di atas ke dalam bukti pengetahuan nol
4. Bukti ZK yang terakumulasi kemudian dikirim kembali ke kontrak pintar dApp pemungutan suara pada rantai target untuk memverifikasi bukti ZK dan memungkinkan pengguna untuk memberikan suara sekali verifikasi berhasil.

Pembangunan tim di bidang ini

Beberapa peserta sedang membangun kontrak pintar yang memungkinkan kontrak pintar untuk mengakses data pada rantai historis dengan cara yang meminimalkan kepercayaan.

Saat ini, Axiomberjalan di Ethereum dan berkomitmen untuk menyediakan kontrak pintar di Ethereum dan mengakses data historis Ethereum melalui bukti penyimpanan berbasis zk. Tim juga meningkatkan kemampuan komputasi off-chain berdasarkan data historis dan menggunakan pengetahuan nol untuk membuktikan akurasi data dan perhitungan tersebut.

Protokol Relikmemberikan pendekatan teknis yang mirip dengan Axiom, dan protokol berjalan di Ethereum dan zkSync Era. Relic menggunakan bukti inklusi Merkle untuk membuktikan inklusi data (berbeda dengan metode Axiom yang membuktikan inklusi Merkle dalam pengetahuan nol).

Herodotussedang berusaha menyediakan data historis tentang Ethereum untuk protokol layer 2. Implementasi uji coba kini tersedia di Starknet dan Era zkSync. Dengan pendanaan dari Yayasan OP, kami rasa kami tahu kemana tim Herodotus akan menuju selanjutnya.

Lagrange Labs Labstelah memperkenalkan bukti yang sepenuhnya dapat diperbarui melalui inovasi ZK MapReduce (ZKMR) terbarunya. Ini menggunakan janji vektor baru yang disebut Recproofsuntuk memperluas konsep keupdatean ke komputasi data.

Tim yang bekerja pada sertifikasi penyimpanan

epilog

Dalam artikel ini, kami telah menjelaskan bagaimana bukti penyimpanan dapat mendukung verifikasi data pada rantai sejarah tanpa harus percaya pihak ketiga. Hal ini membuatnya menjadi alat berharga untuk komposisi on-chain dan interoperabilitas lintas rantai.

Saat Total Locked Value (TVL) terus bermigrasi dari Ethereum ke ekosistem Tier 2, kami mengantisipasi munculnya aplikasi yang lebih ekspresif yang memanfaatkan data on-chain historis melalui bukti penyimpanan.

Sementara teknologi zero-knowledge menjadi lebih cepat dan lebih murah, terus menghasilkan bukti penyimpanan untuk menjaga biaya yang terkait dengan berada di rantai masih merupakan tantangan. Profitabilitas layanan semacam itu akan bergantung pada volume kueri yang dihasilkan oleh aplikasi kueri.

Meskipun menghadapi tantangan, pentingnya bukti konsensus dan bukti penyimpanan yang didukung oleh teknologi zero-knowledge tidak bisa diremehkan. Kami menantikan bagaimana teknologi ini akan digunakan untuk membangun masa depan multi-rantai dengan kepercayaan minimal.

Disclaimer：

1. Artikel ini dicetak ulang dari [cermin]. Semua hak cipta milik penulis asli [Jacob, Hitesh, Ji Hao]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi tim Gate Learn（gatelearn@gate.io), dan mereka akan menanganinya dengan cepat.
2. Penolakan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.