1. Apa itu co-processor dan apa bukan?

Jika Anda diminta untuk menjelaskan koprosesor kepada orang non-teknis atau pengembang hanya dalam satu kalimat, bagaimana Anda akan menjelaskannya?

Saya pikir apa yang dikatakan Dr. Dong Mo mungkin sangat dekat dengan jawaban standar - singkatnya, co-processor memberikan kemampuan kontrak pintar untuk melakukan Analisis Dune.

Bagaimana cara mendekonstruksi kalimat ini?

Bayangkan skenario di mana kita menggunakan Dune - Anda ingin melakukan LP di Uniswap V3 untuk menghasilkan beberapa biaya penanganan, jadi Anda membuka Dune dan menemukan volume perdagangan terbaru dari berbagai pasangan perdagangan di Uniswap, APR biaya penanganan dalam 7 hari terakhir, dan pasangan perdagangan utama Rentang fluktuasi atas dan bawah, dll...

Atau mungkin ketika StepN menjadi populer, Anda mulai berspekulasi tentang sepatu, dan Anda tidak yakin kapan harus menjualnya, jadi Anda menatap data StepN di Dune setiap hari, volume transaksi harian, jumlah pengguna baru, harga lantai sepatu... dan berencana untuk sekali ada pertumbuhan. Jika tren melambat atau turun, lari cepat.

Tentu saja, Anda mungkin tidak hanya menatap data ini, tetapi tim pengembangan Uniswap dan StepN juga memperhatikan data ini.

Data ini sangat bermakna - tidak hanya dapat membantu menilai perubahan dalam tren, tetapi juga dapat digunakan untuk menciptakan trik-trik lebih, seperti pendekatan “big data” yang umum digunakan oleh perusahaan-perusahaan Internet besar.

Sebagai contoh, berdasarkan gaya dan harga sepatu yang sering dibeli dan dijual pengguna, sepatu serupa direkomendasikan.

Sebagai contoh, berdasarkan lamanya pengguna memegang sepatu Chuangshi, akan diluncurkan program “Program Hadiah Kesetiaan Pengguna” untuk memberikan pengguna setia lebih banyak airdrop atau manfaat.

Sebagai contoh, rencana VIP yang mirip dengan Cex dapat diluncurkan berdasarkan TVL atau volume perdagangan yang disediakan oleh LP atau Trader di Uniswap, memberikan manfaat pengurangan biaya transaksi Trader atau peningkatan bagi hasil biaya LP.

Mohon maaf, terjemahan teks ini tidak tersedia.

Pada saat ini, masalah muncul - ketika perusahaan Internet besar bermain dengan big data + AI, itu pada dasarnya adalah kotak hitam. Mereka bisa melakukan apa pun yang mereka inginkan. Pengguna tidak bisa melihatnya dan tidak peduli.

Namun di sisi Web3, transparansi dan ketidakpercayaan adalah politik korektur politik alami kami, dan kami menolak kotak hitam!

Jadi ketika Anda ingin mewujudkan skenario di atas, Anda akan menghadapi dilema - entah Anda dapat mencapainya melalui cara terpusat, “secara manual” menggunakan Dune untuk menghitung data indeks di latar belakang, dan kemudian mendeploy dan menerapkannya; atau Anda dapat menulis kontrak pintar untuk menangkap data ini secara otomatis di rantai, melakukan perhitungan, dan mendeploy poin secara otomatis.

Yang pertama dapat membuat Anda memiliki masalah kepercayaan yang “politik tidak benar”.

Biaya gas yang dihasilkan oleh yang terakhir di rantai akan menjadi angka yang sangat besar, dan dompet (sisi proyek) Anda tidak mampu membayarnya.

Sekarang adalah saatnya bagi co-processor untuk tampil di panggung. Gabungkan dua metode tadi, dan sekaligus gunakan langkah 'manual latar belakang' untuk 'membuktikan ketidakbersalahan diri' melalui teknis. Dengan kata lain, gunakan teknologi ZK untuk 'indeks +' di luar rantai. Bagian 'perhitungan' 'membuktikan ketidakbersalahan diri', dan kemudian mengirimkannya ke kontrak pintar. Dengan cara ini, masalah kepercayaan teratasi, dan biaya gas massal hilang. Sempurna!

Mengapa disebut sebagai 'koprosesor'? Sebenarnya, ini berasal dari 'GPU' dalam sejarah pengembangan Web2.0. Alasan mengapa GPU diperkenalkan sebagai perangkat keras komputasi terpisah dan ada secara independen dari CPU pada saat itu adalah karena arsitektur desainnya dapat menangani beberapa perhitungan yang pada dasarnya sulit untuk ditangani oleh CPU, seperti perhitungan berulang berskala besar secara paralel, perhitungan grafis, dll. . Karena arsitektur 'koprosesor' ini, kita memiliki film CG yang luar biasa, permainan, model AI, dll. saat ini, sehingga arsitektur koprosesor ini sebenarnya merupakan loncatan dalam arsitektur komputasi. Sekarang berbagai tim koprosesor juga berharap untuk memperkenalkan arsitektur ini ke dalam Web3.0. Blockchain di sini mirip dengan CPU Web3.0. Baik itu L1 maupun L2, mereka secara inheren tidak cocok untuk tugas-tugas 'data berat' dan 'logika perhitungan kompleks' seperti itu, sehingga sebuah koprosesor blockchain diperkenalkan untuk membantu menangani perhitungan tersebut, sehingga sangat memperluas kemungkinan aplikasi blockchain.

Jadi apa yang dilakukan coprocessor dapat disimpulkan menjadi dua hal:

1. Dapatkan data dari blockchain dan buktikan melalui ZK bahwa data yang saya dapatkan adalah benar dan tidak tercemar;
2. Lakukan perhitungan yang sesuai berdasarkan data yang baru saja saya peroleh, dan sekali lagi gunakan ZK untuk membuktikan bahwa hasil yang saya hitung benar dan tidak dicampur-aduk. Hasil perhitungan dapat dipanggil oleh kontrak pintar “Biaya Rendah + Tanpa Kepercayaan”.

Beberapa waktu yang lalu, Starkware memiliki konsep populer yang disebut Storage Proof, juga disebut State Proof. Pada dasarnya melakukan langkah 1, yang diwakili oleh Herodotus, Langrage, dll. Fokus teknis dari banyak jembatan lintas-rantai berbasis teknologi ZK juga ada pada langkah 1. 1 di atas.

Co-processor hanyalah menambahkan langkah 2 setelah langkah 1 selesai. Setelah mengekstrak data tanpa kepercayaan, kemudian dapat melakukan perhitungan bebas kepercayaan.

Jadi untuk menggunakan istilah teknis yang relatif untuk menggambarkannya secara akurat, coprocessor seharusnya menjadi himpunan bagian dari Storage Proof/State Proof dan himpunan bagian dari Verifiable Computation.

Satu hal yang perlu diperhatikan adalah bahwa coprocessor bukan Rollup.

Secara teknis, bukti ZK Rollup mirip dengan langkah 2 di atas, dan proses langkah 1 “mendapatkan data” diimplementasikan langsung melalui Sequencer. Bahkan Sequencer terdesentralisasi hanya menggunakan jenis mekanisme kompetisi atau konsensus tertentu. Ambil alih bukti Penyimpanan dalam bentuk ZK. Yang lebih penting adalah bahwa selain lapisan perhitungan, ZK Rollup juga perlu mengimplementasikan lapisan penyimpanan yang mirip dengan blockchain L1. Penyimpanan ini permanen, sementara ZK Coprocessor “tanpa status”. Setelah perhitungan selesai, tidak ada status yang disimpan.

Dari perspektif skenario aplikasi, koprosesor dapat dianggap sebagai plug-in layanan untuk semua Layer1/Layer2, sementara Rollup menciptakan kembali lapisan eksekusi untuk membantu memperluas lapisan penyelesaian.

2. Mengapa Anda harus menggunakan ZK? Apakah boleh menggunakan OP?

Setelah membaca di atas, Anda mungkin memiliki keraguan, apakah itu harus dilakukan dengan ZK sebagai koprocesor? Ini terdengar sangat mirip dengan “Grafik dengan ZK ditambahkan”, dan kita sepertinya tidak memiliki “keraguan besar” tentang hasil pada Grafik.

Itu karena ketika Anda menggunakan Graph, Anda pada dasarnya tidak melibatkan uang sungguhan. Indeks-indeks ini melayani layanan off-chain. Apa yang Anda lihat pada antarmuka pengguna front-end adalah volume transaksi, riwayat transaksi, dll. Data dapat disediakan melalui beberapa penyedia indeks data seperti Graph, Alchemy, Zettablock, dll., tetapi data ini tidak dapat dimasukkan kembali ke dalam kontrak cerdas, karena begitu Anda memasukkannya kembali, Anda akan menambah kepercayaan tambahan dalam layanan indeks. Ketika data terhubung dengan uang sungguhan, terutama TVL dalam jumlah besar, kepercayaan tambahan ini menjadi penting. Bayangkan saat teman meminta Anda meminjam 100 yuan, Anda mungkin akan meminjamkannya tanpa ragu. Ya, bagaimana jika saya meminta Anda meminjam 10.000 yuan, atau bahkan 1 juta yuan?

Tapi sekali lagi, apakah kita benar-benar harus menggunakan ZK untuk memproses semua skenario di atas? Setelah semua, kita memiliki dua rute teknis, OP dan ZK, di Rollup. ZKML yang belakangan ini populer juga memiliki konsep OPML dari rute cabang yang sesuai. Dalam hal ini, apakah coprocessor juga memiliki sebuah cabang OP, seperti OP-Coprocessor?

Sebenarnya, ada - tetapi kami menjaga rincian khusus ini kerahasiaan untuk saat ini, dan kami akan merilis informasi lebih detail segera.

3. Pembandingan beberapa solusi teknologi coprocessor umum di pasaran mana yang lebih baik

1. Brevis:

Arsitektur Brevis terdiri dari tiga komponen: zkFabric, zkQueryNet, dan zkAggregatorRollup.

Berikut adalah diagram arsitektur Brevis:

zkFabric: Mengumpulkan header blok dari semua blockchain yang terhubung dan menghasilkan bukti konsensus ZK yang membuktikan validitas header blok tersebut. Melalui zkFabric, Brevis menerapkan koprosesor yang dapat berinteroperabilitas untuk beberapa rantai, yang memungkinkan satu blockchain untuk mengakses data historis dari blockchain lainnya.

zkQueryNet: Sebuah pasar mesin kueri ZK terbuka yang menerima kueri data dari dApps dan memprosesnya. Kueri data memproses kueri-kueri ini menggunakan header blok yang diverifikasi dari zkFabric dan menghasilkan bukti kueri ZK. Mesin-mesin ini memiliki fungsi yang sangat spesialis dan bahasa kueri umum untuk memenuhi berbagai kebutuhan aplikasi.

zkAggregatorRollup: Sebuah blockchain konvensional ZK yang berfungsi sebagai lapisan agregasi dan penyimpanan untuk zkFabric dan zkQueryNet. Ini memverifikasi bukti dari kedua komponen, menyimpan data yang diverifikasi, dan mengkomitmenkan akar status yang divalidasi zk-nya ke semua blockchain yang terhubung.

ZK Fabric adalah bagian kunci dari menghasilkan bukti untuk header blok. Sangat penting untuk memastikan keamanan bagian ini. Berikut adalah diagram arsitektur zkFabric:

Klien ringan berbasis Zero-Knowledge Proof (ZKP) dari zkFabric membuatnya sepenuhnya bebas kepercayaan tanpa harus mengandalkan entitas verifikasi eksternal apa pun. Tidak perlu bergantung pada entitas verifikasi eksternal apa pun, karena keamanannya sepenuhnya berasal dari blockchain yang mendasarinya dan bukti matematis yang dapat diandalkan.

Jaringan Prover zkFabric mengimplementasikan sirkuit untuk setiap protokol lightclient blockchain, dan jaringan menghasilkan bukti keabsahan untuk header blok. Prover dapat memanfaatkan akselerator seperti GPU, FPGA, dan ASIC untuk meminimalkan waktu dan biaya bukti.

zkFabric bergantung pada asumsi keamanan dari blockchain dan protokol enkripsi yang mendasarinya serta asumsi keamanan dari protokol enkripsi yang mendasarinya. Namun, untuk memastikan efektivitas zkFabric, setidaknya satu relayer jujur diperlukan untuk menyinkronkan fork yang benar. Oleh karena itu, zkFabric mengadopsi jaringan relay terdesentralisasi daripada relay tunggal untuk mengoptimalkan efektivitas zkFabric. Jaringan relay ini dapat memanfaatkan struktur yang sudah ada, seperti jaringan penjagaan state dalam jaringan Celer.

Alokasi Prover: Jaringan prover adalah jaringan prover ZKP terdesentralisasi yang memilih seorang prover untuk setiap tugas generasi bukti dan membayar biaya kepada para prover tersebut.

Implementasi saat ini:

Protokol klien ringan saat ini diimplementasikan untuk berbagai blockchain termasuk Ethereum PoS, Cosmos Tendermint, dan BNB Chain berfungsi sebagai contoh dan bukti konsep.

Brevis saat ini telah bekerja sama dengan uniswap hook, yang sangat menambahkan kolam uniswap khusus. Namun, dibandingkan dengan CEX, Uniswap masih kurang memiliki kemampuan pemrosesan data yang efektif untuk membuat proyek yang mengandalkan data transaksi pengguna besar (seperti program loyalitas berdasarkan volume transaksi pengguna). Fungsi.

Dengan bantuan Brevis, hook berhasil menyelesaikan tantangan. Hook sekarang dapat membaca data rantai sejarah lengkap pengguna atau LP dan menjalankan perhitungan yang dapat disesuaikan secara sepenuhnya tanpa kepercayaan.

1. Herodotus

Herodotus adalah perantara akses data yang kuat yang menyediakan kontrak pintar dengan fungsi berikut untuk mengakses data saat ini dan historis secara sinkron di seluruh lapisan Ethereum:

Negara bagian L1 dari L2s

Negara L2 dari kedua L1 dan L2 lainnya

Negara L3/App-Chain ke L2 dan L1

Herodotus mengusulkan konsep bukti penyimpanan, yang menggabungkan bukti inklusi (memastikan keberadaan data) dan bukti komputasi (memverifikasi eksekusi alur kerja multi-langkah) untuk membuktikan bahwa kumpulan data besar (seperti seluruh blockchain Ethereum atau rollup) atau validitas elemen-elemen ganda.

Inti dari blockchain adalah database, di mana data dienkripsi dan dilindungi menggunakan struktur data seperti pohon Merkle dan pohon Merkle Patricia. Yang unik dari struktur data ini adalah bahwa begitu data aman terkomitmen pada mereka, bukti dapat dihasilkan untuk mengkonfirmasi bahwa data terdapat dalam struktur tersebut.

Penggunaan pohon Merkle dan pohon Merkle Patricia meningkatkan keamanan blockchain Ethereum. Dengan menghash secara kriptografis data di setiap level pohon, hampir tidak mungkin untuk mengubah data tanpa terdeteksi. Setiap perubahan pada titik data memerlukan mengubah hash yang sesuai pada pohon ke hash root, yang secara publik terlihat dalam header blockchain. Fitur fundamental blockchain ini memberikan tingkat integritas data yang tinggi dan ketidakubahannya.

Kedua, pohon-pohon ini memungkinkan verifikasi data yang efisien melalui bukti inklusi. Misalnya, saat memverifikasi inklusi transaksi atau status kontrak, tidak perlu mencari seluruh blockchain Ethereum tetapi hanya jalur dalam pohon Merkle yang relevan.

Bukti penyimpanan sebagaimana didefinisikan oleh Herodotus adalah sebuah fusi dari:

• Bukti penahanan: Bukti-bukti ini mengkonfirmasi keberadaan data spesifik dalam struktur data kriptografis (seperti pohon Merkle atau pohon Merkle Patricia), memastikan bahwa data yang dimaksud memang hadir dalam kumpulan data.
• Bukti Komputasi: Memverifikasi pelaksanaan alur kerja multi-langkah, membuktikan kevalidan satu atau lebih elemen dalam sebuah dataset luas, seperti seluruh blockchain Ethereum atau agregat. Selain menunjukkan keberadaan data, mereka juga memverifikasi transformasi atau operasi yang diterapkan pada data tersebut.
• Bukti pengetahuan nol: Menyederhanakan jumlah data kontrak pintar yang perlu berinteraksi. Bukti pengetahuan nol memungkinkan kontrak pintar untuk mengonfirmasi validitas klaim tanpa memproses semua data yang mendasarinya.

Alur Kerja :

1. Dapatkan hash blok

Setiap data di blockchain milik blok tertentu. Hash blok berfungsi sebagai pengenal unik blok dan merangkum semua isinya melalui header blok. Dalam alur kerja proof-of-storage, kita pertama-tama perlu menentukan dan memverifikasi hash blok dari blok yang berisi data yang kita minati. Ini adalah langkah pertama dalam seluruh proses.

1. Dapatkan header blok

Setelah hash blok yang relevan diperoleh, langkah berikutnya adalah mengakses header blok. Untuk melakukannya, header blok yang terkait dengan hash blok yang diperoleh pada langkah sebelumnya perlu di-hash. Hash dari header blok yang diberikan kemudian dibandingkan dengan hash blok yang dihasilkan:

Ada dua cara untuk mendapatkan hash:

(1) Gunakan opcode BLOCKHASH untuk mengambil

(2) Menanyakan hash blok yang telah diverifikasi dalam sejarah dari Akumulator Hash Blok

Langkah ini memastikan bahwa header blok yang sedang diproses adalah otentik. Begitu langkah ini selesai, kontrak pintar dapat mengakses nilai apa pun di header blok.

1. Tentukan akar yang diperlukan (opsional)

Dengan kepala blok di tangan, kita dapat menyelami isinya, khususnya:

stateRoot: Sebuah hash kriptografis dari seluruh status blockchain pada saat blockchain terjadi.

receiptsRoot: Digest terenkripsi dari semua hasil transaksi (kwitansi) dalam blok.

TransactionsRoot: Sebuah ringkasan kriptografis dari semua transaksi yang terjadi di blok.

dapat diuraikan, memungkinkan verifikasi apakah rekening, tanda terima, atau transaksi tertentu sudah termasuk dalam blok.

1. Validasi data terhadap root yang dipilih (opsional)

Dengan akar yang kita pilih, dan mempertimbangkan bahwa Ethereum menggunakan struktur Merkle-Patricia Trie, kita dapat menggunakan bukti inklusi Merkle untuk memverifikasi bahwa data ada dalam pohon. Langkah-langkah verifikasi akan bervariasi tergantung pada data dan kedalaman data dalam blok.

Jaringan yang saat ini didukung:

Dari Ethereum ke Starknet

Dari Ethereum Goerlike Starknet Goerli

Dari Ethereum Goerlike zkSync Era Goerli

1. Aksioma

Axiom menyediakan cara bagi pengembang untuk mengakses header blok, akun, atau nilai penyimpanan dari seluruh sejarah Ethereum. AXIOM memperkenalkan metode pengaitan baru berbasis kriptografi. Semua hasil yang dikembalikan oleh Axiom diverifikasi on-chain melalui bukti zero-knowledge, yang berarti kontrak pintar dapat menggunakannya tanpa asumsi kepercayaan tambahan.

Axiom baru-baru ini dirilisHalo2-replHalo2 REPL berbasis browser yang ditulis dalam Javascript. Ini memungkinkan pengembang menulis rangkaian ZK menggunakan hanya Javascript standar tanpa harus mempelajari bahasa baru seperti Rust, menginstal perpustakaan bukti, atau menangani dependensi.

Axiom terdiri dari dua komponen teknologi utama:

AxiomV1 — cache blockchain Ethereum, dimulai dengan Genesis.

AxiomV1Query — Kontrak pintar yang menjalankan query terhadap AxiomV1.

(1) Nilai hash blok cache di AxiomV1:

Kontrak pintar AxiomV1 menyimpan hash blok Ethereum sejak blok genesis dalam dua bentuk:

Pertama, akar Merkle Keccak dari 1024 hash blok berturut-turut disimpan dalam cache. Akar Merkle ini diperbarui melalui bukti ZK, memverifikasi bahwa hash header blok membentuk rantai komitmen yang berakhir dengan salah satu dari 256 blok terbaru yang dapat diakses langsung oleh EVM atau hash blok yang sudah ada di cache AxiomV1.

Kedua, Axiom menyimpan Rentang Pegunungan Merkle dari akar Merkle ini dimulai dari blok genesis. Rentang Pegunungan Merkle dibangun on-chain dengan memperbarui bagian pertama dari cache, akar Merkle Keccak.

(2) Jalankan kueri di AxiomV1Query:

Kontrak pintar AxiomV1Query digunakan untuk kueri batch untuk memungkinkan akses tanpa kepercayaan ke header blok Ethereum historis, akun, dan data sembarang yang disimpan di akun. Kueri dapat dilakukan on-chain dan diselesaikan on-chain melalui bukti ZK terhadap hash blok yang di-cache AxiomV1.

Bukti ZK ini memeriksa apakah data on-chain yang relevan terletak langsung di header blok, atau di trie akun atau penyimpanan blok, dengan memverifikasi bukti inklusi (atau tidak inklusi) dari Merkle-Patricia Trie.

1. Nexus

Nexus berusaha membangun platform umum untuk komputasi awan yang dapat diverifikasi menggunakan bukti pengetahuan nol. Saat ini, platform ini tidak bergantung pada arsitektur mesin tertentu dan mendukung risc 5/ WebAssembly/ EVM. Nexus menggunakan sistem bukti supernova. Tim menguji bahwa memori yang diperlukan untuk menghasilkan bukti adalah 6GB. Di masa depan, akan dioptimalkan berdasarkan ini sehingga perangkat dan komputer pengguna biasa dapat menghasilkan bukti.

Untuk lebih tepatnya, arsitektur ini dibagi menjadi dua bagian:

Nexus zero: Jaringan komputasi cloud terdesentralisasi yang dapat diverifikasi yang didukung oleh bukti pengetahuan nol dan zkVM universal.

Nexus: Jaringan komputasi awan yang terdesentralisasi yang dapat diverifikasi, didukung oleh komputasi multipihak, replikasi mesin keadaan, dan mesin virtual WASM universal.

Aplikasi Nexus dan Nexus Zero dapat ditulis dalam bahasa pemrograman tradisional, saat ini mendukung Rust, dengan lebih banyak bahasa yang akan datang.

Aplikasi Nexus berjalan pada jaringan komputasi awan terdesentralisasi, yang pada dasarnya adalah “blockchain tanpa server” serbaguna yang terhubung langsung ke Ethereum. Oleh karena itu, aplikasi Nexus tidak mewarisi keamanan Ethereum, tetapi sebagai gantinya mendapatkan akses ke daya komputasi yang lebih tinggi (seperti komputasi, penyimpanan, dan I/O yang dipicu oleh acara) karena ukuran jaringannya yang lebih kecil. Aplikasi Nexus berjalan pada awan pribadi yang mencapai konsensus internal dan memberikan “bukti” komputasi yang dapat diverifikasi (bukan bukti sejati) melalui tanda tangan ambang jaringan yang dapat diverifikasi di seluruh Ethereum.

Aplikasi Nexus Zero mewarisi keamanan dari Ethereum, karena mereka adalah program universal dengan bukti pengetahuan nol yang dapat diverifikasi on-chain pada kurva elips BN-254.

Karena Nexus dapat menjalankan biner WASM deterministik apa pun dalam lingkungan yang direplikasi, diharapkan digunakan sebagai sumber bukti validitas/dispersi/toleransi kesalahan untuk aplikasi yang dihasilkan, termasuk pengurutan zk-rollup, pengurutan optimis rollup, dan bukti Server lainnya, seperti zkVM Nexus Zero itu sendiri.

Disclaimer：

1. Artikel ini dicetak ulang dari [Medium]. Semua hak cipta milik penulis asli [ABCDE]. Jika ada keberatan terhadap pencetakan ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penolakan Tanggung Jawab Kewajiban: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran 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.