Panduan Pengembang untuk zkGalaxy

Ini adalah heuristik yang sangat berguna untuk membedakan pendekatan untuk mendukung zkEVM. Namun, zkEVM adalah bagian dari semua kemungkinan cara untuk membangun aplikasi tanpa pengetahuan. Untuk seorang programmer yang ingin memanfaatkan properti unik dari perhitungan zk, yaitu ringkas, nol pengetahuan, dan kebenaran, zkEVM mungkin bukan pilihan terbaik. Dengan meletakkan seluruh rangkaian alat pengembang, saya berharap dapat memberikan panduan yang membantu dalam proses pengambilan keputusan seputar tumpukan zk yang tepat untuk aplikasi Anda.

Selama satu atau dua tahun terakhir, telah terjadi banyak sekali kemajuan dalam alat zk. Mereka mendekati titik di mana pengembang perangkat lunak biasa dapat memanfaatkan properti zk yang kuat tanpa pemahaman mendalam tentang matematika dan teknik dasar yang mengintimidasi. Di sisi lain, telah terjadi proliferasi alat untuk pengguna yang kuat yang memberikan kontrol yang sangat baik kepada para ahli zk atas tumpukan zk.

Perangkat lunak modern dibangun di atas lapisan abstraksi yang tak terhitung jumlahnya untuk memaksimalkan produktivitas spesialis. Ada banyak keuntungan abstraksi dalam teknik yang agak intuitif – pengembang web tidak perlu memahami cara kerja sistem operasi secara mendalam. 

Kunci untuk membangun lapisan abstraksi yang baik dan dapat digunakan kembali adalah merangkum kompleksitas lapisan dan kemudian menyediakan antarmuka yang sederhana namun ekspresif untuk lapisan yang lebih tinggi dalam tumpukan untuk digunakan. Dilakukan dengan benar, ini memungkinkan pengembang dengan berbagai bidang keahlian dan pengetahuan untuk membuat alat yang berguna di seluruh tumpukan.

Tidak mengherankan, prinsip yang sama ini berlaku untuk sistem zk, dan lapisan abstraksi ini menjadi cukup matang bagi pemula zk untuk mulai menggunakannya dan membangun aplikasi hari ini.

Arkworks-rs adalah ekosistem pustaka Rust yang menyediakan implementasi subkomponen aplikasi zkSNARK yang efisien dan aman. Arkworks menyediakan antarmuka yang diperlukan bagi pengembang untuk menyesuaikan tumpukan perangkat lunak untuk aplikasi zk tanpa harus mengimplementasikan ulang kesamaan dengan pustaka lain yang ada.

Sebelum Arkworks, satu-satunya cara untuk membuat aplikasi zk baru adalah membangun semuanya dari awal. Keunggulan utama Arkworks-rs dibandingkan alat yang dibuat khusus dan terintegrasi secara vertikal adalah tingkat fleksibilitas, pengurangan rekayasa duplikat, dan pengurangan upaya audit. Garis antarmuka Arkworks yang masuk akal di antara komponen memungkinkan kecepatan peningkatan yang dapat menjaga tumpukan tetap relevan di tengah kecepatan inovasi dalam teknologi zk, tanpa memaksa tim untuk membangun kembali semuanya dari awal.

Arkworks adalah untuk proyek yang membutuhkan kontrol yang baik atas seluruh tumpukan perangkat lunak zk, tetapi tidak ingin membangun semua bagian yang berlebihan dari awal. Jika Anda sedang mempertimbangkan versi khusus sirkuit DSL karena, misalnya, Anda sedang membuat prototipe sistem bukti baru tetapi tidak yakin dengan skema komitmen atau kurva eliptik yang sesuai, arkworks akan memungkinkan Anda untuk dengan cepat beralih di antara beberapa opsi dengan antarmuka bersama, alih-alih daripada memulai dari awal.

Untuk membuat bukti tentang beberapa komputasi, pertama komputasi ini harus dinyatakan dalam bentuk yang dapat dipahami oleh sistem zkSNARK. Beberapa bahasa khusus domain telah menciptakan bahasa pemrograman yang memungkinkan pengembang aplikasi mengekspresikan perhitungan mereka sedemikian rupa. Ini termasuk Aztek Noir, milik Starknet Kairo, lingkaran, ZoKrates, dan milik Aleo Leo diantara yang lain. Sistem pembuktian yang mendasari dan detail matematis umumnya tidak diekspos ke pengembang aplikasi.

Pengembang zkApp harus mahir dalam menulis program mereka dalam bahasa khusus domain. Beberapa dari bahasa ini sangat mirip dengan bahasa pemrograman yang sudah dikenal, sementara yang lain cukup sulit untuk dipelajari. Mari kita jabarkan beberapa di antaranya:

Kairo – Starkware DSL diperlukan untuk membuat aplikasi di Starknet. Mengkompilasi ke dalam bahasa rakitan khusus Kairo yang dapat ditafsirkan oleh zkVM Kairo.

ZoKrates — ZoKrates adalah perangkat untuk kebutuhan umum SNARK termasuk bahasa tingkat tinggi untuk menulis sirkuit. ZoKrates juga memiliki beberapa fleksibilitas di sekitar kurva, skema pembuktian, dan backend, memungkinkan dev untuk melakukan hot-swap dengan argumen CLI sederhana.

lingkaran — Circom adalah bahasa yang dibuat khusus untuk membangun sirkuit. Saat ini, ini adalah bahasa de-facto untuk sirkuit dalam produksi. Bahasanya tidak terlalu ergonomis. Bahasa itu sendiri membuat Anda sangat menyadari fakta bahwa Anda sedang menulis sirkuit.

Leo — Leo dikembangkan sebagai bahasa untuk blockchain Aleo. Leo memiliki beberapa sintaks seperti Rust dan secara khusus dibuat untuk transisi keadaan di dalam blockchain.

Noir – Sintaks yang terinspirasi karat. Dirancang di sekitar IR daripada bahasa itu sendiri, yang berarti ia dapat memiliki tampilan depan yang sewenang-wenang. 

Pengembang aplikasi mana pun yang ingin memanfaatkan properti unik zk dalam aplikasinya. Beberapa dari bahasa ini telah diuji pertempuran dengan miliaran dolar bergerak melintasinya melalui rantai seperti ZCash dan Starknet. Sementara beberapa proyek yang akan kita diskusikan belum cukup siap untuk penggunaan produksi, menulis sirkuit Anda dalam salah satu bahasa ini saat ini merupakan strategi terbaik, kecuali jika Anda memerlukan kontrol yang lebih baik yang disediakan oleh toolkit seperti Arkworks.

Tujuan utama zkEVM adalah untuk mengambil transisi status Ethereum dan membuktikan validitasnya menggunakan bukti kebenaran pengetahuan nol yang ringkas. Seperti disebutkan dalam posting Vitalik, ada sejumlah cara untuk melakukan ini dengan perbedaan halus dan pertukaran yang sesuai. 

Perbedaan teknis utama antara semua ini adalah persis di mana dalam tumpukan bahasa perhitungan diubah menjadi bentuk (aritmetisasi) yang dapat digunakan dalam sistem pembuktian. Di beberapa zkEVM, ini terjadi pada bahasa tingkat tinggi (Solidity, Vyper, Yul), sementara pendekatan lain mencoba membuktikan EVM hingga tingkat opcode. Pengorbanan antara pendekatan ini dibahas secara mendalam di postingan Vitalik, tetapi saya akan meringkasnya dalam satu kalimat: Semakin rendah konversi/aritmetisasi yang terjadi di tumpukan, semakin besar penalti kinerja.

Tantangan utama dalam membuat bukti untuk mesin virtual adalah bahwa ukuran sirkuit bertambah secara proporsional dengan ukuran SEMUA kemungkinan instruksi untuk setiap instruksi yang dieksekusi. Hal ini terjadi karena rangkaian tidak mengetahui instruksi apa yang akan dijalankan pada setiap program, sehingga perlu mendukung semuanya.

Artinya dalam praktiknya adalah Anda membayar (dalam biaya kinerja) untuk instruksi yang paling mahal, bahkan ketika Anda hanya menjalankan instruksi yang paling sederhana. Hal ini mengarah pada trade-off langsung antara generalisasi dan kinerja–saat Anda menambahkan lebih banyak instruksi untuk generalisasi, Anda membayarnya pada setiap instruksi Anda membuktikan!

Ini adalah masalah mendasar dengan sirkuit universal, tetapi dengan perkembangan baru dalam teknologi seperti IVC (incremental verifiable compute), batasan ini dapat diperbaiki dengan memecah komputasi menjadi bagian-bagian yang lebih kecil yang masing-masing memiliki subsirkuit khusus yang lebih kecil.

Implementasi zkEVM hari ini menggunakan strategi yang berbeda untuk mengurangi dampak dari masalah ini… Misalnya, zkSync merobek operasi yang lebih mahal (kebanyakan pra-kompilasi kriptografi seperti hash dan ECDSA) dari sirkuit pembuktian eksekusi utama menjadi sirkuit terpisah yang digabungkan bersama di akhir melalui snark rekursi. zkSync mengambil pendekatan ini setelah mereka menyadari bahwa sebagian besar biaya mereka berasal dari beberapa instruksi rumit.

Pada intinya, alasan membuktikan set instruksi yang lebih setara dengan EVM lebih mahal adalah karena EVM tidak dirancang untuk perhitungan zk. Meninggalkan EVM lebih awal di tumpukan memungkinkan zkEVM berjalan pada set instruksi yang lebih dioptimalkan untuk zk, dan karenanya lebih murah untuk dibuktikan.

Pelanggan ideal untuk zkEVM adalah aplikasi kontrak pintar yang membutuhkan pesanan transaksi yang lebih murah daripada yang tersedia di L1 Ethereum. Pengembang ini belum tentu memiliki keahlian atau bandwidth untuk menulis aplikasi zk dari awal. Oleh karena itu, mereka lebih suka menulis aplikasi mereka dalam bahasa tingkat tinggi yang mereka kenal, seperti Solidity. 

Menskalakan Ethereum saat ini merupakan aplikasi teknologi zk yang paling banyak diminati.

ZkEVM adalah solusi penskalaan Ethereum yang tanpa hambatan mengurangi masalah kemacetan yang membatasi pengembang dApp L1.

Tujuan zkEVM adalah untuk mendukung pengalaman pengembang yang sedekat mungkin dengan pengembangan Ethereum saat ini. Dukungan Full Solidity berarti bahwa tim tidak perlu membangun dan memelihara banyak basis kode. Ini agak tidak praktis untuk dilakukan dengan sempurna karena zkEVM perlu menukar beberapa kompatibilitas agar dapat menghasilkan bukti dengan ukuran yang wajar dalam waktu yang wajar.

Perbedaan utama antara zkSync dan Scroll adalah di mana/ketika di tumpukan mereka melakukan aritmetisasi – yaitu, di mana mereka mengubah dari konstruksi EVM normal menjadi representasi ramah-SNARK. Untuk zkSync, ini terjadi ketika mereka mengonversi bytecode YUL menjadi set instruksi zk kustom mereka sendiri. Untuk Gulir, ini terjadi di bagian akhir, saat jejak eksekusi aktual dibuat dengan opcode EVM aktual.

Jadi, untuk zkSync, semuanya sama seperti berinteraksi dengan EVM hingga bytecode zk dibuat. Untuk Scroll, semuanya sama hingga bytecode yang sebenarnya dijalankan. Ini adalah perbedaan halus, yang menukar kinerja dengan dukungan. Misalnya, zkSync tidak akan mendukung alat bytecode EVM seperti debugger out of the box, karena ini adalah bytecode yang sama sekali berbeda. Sementara Scroll akan lebih sulit mendapatkan kinerja yang baik dari set instruksi, yang tidak dirancang untuk zk. Ada pro dan kontra untuk kedua strategi tersebut dan pada akhirnya ada banyak faktor eksogen yang akan memengaruhi kesuksesan relatif mereka.

💡 Terlepas dari namanya, LLVM bukanlah VM (mesin virtual). LLVM adalah nama seperangkat alat kompiler yang didukung oleh representasi perantara (IR) yaitu agnostik bahasa.

= nol; Yayasan (tentang nama, itu a Lelucon injeksi SQL jika Anda bertanya-tanya) sedang membangun kompiler yang dapat mengubah bahasa frontend LLVM apa pun menjadi representasi perantara yang dapat dibuktikan dalam SNARK. ZkLLVM dirancang sebagai perluasan infrastruktur LLVM yang ada, rantai alat standar industri yang mendukung banyak bahasa tingkat tinggi seperti Rust, C, C++ dll.

Seorang pengguna yang ingin membuktikan beberapa komputasi cukup mengimplementasikan komputasi tersebut dalam C++. ZkLLVM mengambil kode sumber tingkat tinggi ini yang didukung oleh kompiler dentang mereka yang dimodifikasi (saat ini C++) dan menghasilkan beberapa representasi perantara dari sirkuit. Pada titik ini, rangkaian siap dibuktikan, tetapi pengguna mungkin ingin membuktikan rangkaian berdasarkan beberapa input dinamis. Untuk menangani input dinamis, zkLLVM memiliki komponen tambahan yang disebut sebagai pemberi tugas, yang menghasilkan tabel penugasan dengan semua input dan saksi sepenuhnya diproses sebelumnya dan siap dibuktikan di samping sirkuit.

2 komponen ini adalah semua yang diperlukan untuk menghasilkan bukti. Seorang pengguna secara teoritis dapat menghasilkan bukti sendiri, tetapi karena ini adalah tugas komputasi yang agak khusus, mereka mungkin ingin membayar orang lain, yang memiliki perangkat keras, untuk melakukannya untuk mereka. Untuk mekanisme penemuan rekanan ini, =nil; Foundation juga telah membentuk 'pasar bukti' di mana para pembukti bersaing untuk membuktikan perhitungan bagi pengguna yang akan membayar mereka untuk melakukannya. Dinamika pasar bebas ini akan mengarah pada pengoptimalan tugas pembuktian yang paling berharga.

Karena setiap tugas komputasi yang akan dibuktikan adalah unik dan menghasilkan sirkuit yang berbeda, ada jumlah sirkuit yang tak terhingga yang harus dapat ditangani oleh pembukti. Generalisasi yang dipaksakan ini membuat pengoptimalan sirkuit individu menjadi sulit. Pengenalan pasar bukti memungkinkan spesialisasi pada sirkuit yang dianggap berharga oleh pasar. Tanpa pasar ini, akan sulit untuk meyakinkan seorang pembukti untuk mengoptimalkan sirkuit ini karena masalah start dingin yang alami ini.

Pertukaran lainnya adalah abstraksi klasik vs. kontrol. Pengguna yang bersedia menggunakan antarmuka yang mudah digunakan ini menyerahkan kendali atas primitif kriptografi yang mendasarinya. Bagi banyak pengguna, ini adalah trade-off yang sangat valid, karena seringkali lebih baik membiarkan ahli kriptografi membuat keputusan ini untuk Anda.

ZkVM menjelaskan superset dari semua mesin virtual zk, sedangkan zkEVM adalah jenis zkVM tertentu, yang layak didiskusikan sebagai topik terpisah karena prevalensinya saat ini. Ada beberapa proyek lain yang bekerja untuk membangun zkVM yang lebih umum yang didasarkan pada ISA selain VM crypto yang dipesan lebih dahulu.

Alih-alih membuktikan EVM, sistem dapat membuktikan arsitektur kumpulan instruksi (ISA) yang berbeda, seperti RISC-V atau WASM di VM baru. Dua proyek yang mengerjakan zkVM umum ini adalah RISC Zero dan zkWASM. Mari selami RISC Zero sedikit di sini untuk mendemonstrasikan cara kerja strategi ini dan beberapa kelebihan/kekurangannya. 

RISC Zero mampu membuktikan setiap perhitungan yang dijalankan pada arsitektur RISC-V. RISC-V adalah standar arsitektur set instruksi (ISA) sumber terbuka yang semakin populer. Filosofi RISC (reduced instruction set computer) adalah membangun set instruksi yang sangat sederhana dengan kerumitan minimal. Ini berarti bahwa pengembang di lapisan yang lebih tinggi dalam tumpukan akhirnya mengambil beban yang lebih besar dalam mengimplementasikan instruksi menggunakan arsitektur ini sambil membuat implementasi perangkat keras menjadi lebih sederhana.

Filosofi ini juga berlaku untuk komputasi umum, chip ARM telah memanfaatkan set instruksi bergaya RISC dan mulai mendominasi pasar chip seluler. Ternyata set instruksi yang lebih sederhana juga memiliki energi yang lebih besar dan efisiensi area mati.

Analogi ini berlaku cukup baik untuk efisiensi menghasilkan bukti zk. Seperti yang telah dibahas sebelumnya, saat membuktikan jejak eksekusi di zk, Anda membayar jumlah biaya semua instruksi per setiap item dalam jejak, jadi total instruksi yang lebih sederhana dan lebih sedikit lebih baik.

Dari perspektif pengembang, menggunakan RISC Zero untuk menangani bukti zk sangat mirip dengan menggunakan fungsi AWS Lambda untuk menangani arsitektur server backend. Pengembang berinteraksi dengan RISC Zero atau AWS Lambda hanya dengan menulis kode dan layanan menangani semua kerumitan backend.

Untuk RISC Zero, pengembang menulis Rust atau C++ (akhirnya apapun yang menargetkan RISC-V). Sistem kemudian mengambil file ELF yang dihasilkan selama kompilasi dan menggunakannya sebagai kode input untuk sirkuit VM. Pengembang cukup memanggil bukti yang mengembalikan tanda terima (yang berisi bukti zk dari jejak eksekusi) objek yang dapat dipanggil `verifikasi` oleh siapa saja dari mana saja. Dari sudut pandang pengembang, tidak perlu memahami cara kerja zk, sistem yang mendasarinya menangani semua kerumitan ini.

Untuk beberapa sirkuit dasar dan dapat digunakan kembali yang sangat berguna untuk aplikasi blockchain atau di tempat lain, tim mungkin telah membangun dan mengoptimalkan sirkuit ini untuk Anda. Anda cukup memberikan input untuk kasus penggunaan khusus Anda. Bukti inklusi Merkle misalnya adalah sesuatu yang umumnya dibutuhkan dalam aplikasi crypto (daftar airdrop, Tornado Cash, dll). Sebagai pengembang aplikasi, Anda selalu dapat menggunakan kembali kontrak yang telah teruji pertempuran ini dan cukup memodifikasi lapisan di atas untuk membuat aplikasi yang unik.

Misalnya, sirkuit Tornado Cash dapat digunakan kembali untuk a aplikasi airdrop pribadi atau aplikasi pemungutan suara pribadi. Manta dan Semaphore sedang membangun seluruh perangkat perangkat sirkuit umum seperti ini yang dapat digunakan dalam kontrak Soliditas dengan sedikit atau tanpa pemahaman tentang matematika bulan zk yang mendasarinya.

Seperti yang telah dibahas panjang lebar, ada segudang opsi berbeda untuk mengembangkan aplikasi zk semuanya dengan rangkaian pertukaran unik mereka sendiri. Bagan ini akan membantu meringkas matriks keputusan ini sehingga berdasarkan tingkat keahlian dan kebutuhan kinerja Anda, Anda dapat memilih alat terbaik untuk pekerjaan itu. Ini bukan daftar lengkap, saya berencana untuk menambahkan ini di masa mendatang karena saya mengetahui lebih banyak alat yang muncul di ruang angkasa.

zk berada di ujung tombak beberapa teknologi, dan membangunnya membutuhkan pemahaman mendalam tentang matematika, kriptografi, ilmu komputer, dan teknik perangkat keras. Namun, dengan semakin banyaknya lapisan abstraksi yang tersedia setiap hari, pengembang aplikasi dapat memanfaatkan kekuatan zk tanpa gelar Ph.D. Karena batasan waktu pembuktian perlahan-lahan diangkat dari waktu ke waktu melalui pengoptimalan di semua level tumpukan, kita kemungkinan akan melihat alat yang lebih sederhana untuk pengembang rata-rata.

Saya harap saya meyakinkan Anda, pengembang perangkat lunak yang ingin tahu, bahwa Anda dapat mulai menggunakan zk di aplikasi Anda hari ini. Selamat Meretas 🙂

Pengungkapan: Blockchain Capital adalah investor di beberapa protokol yang disebutkan di atas.

Pandangan yang diungkapkan dalam setiap posting blog mungkin merupakan pandangan pribadi masing-masing penulis dan tidak mencerminkan pandangan Blockchain Capital dan afiliasinya. Baik Blockchain Capital maupun penulis tidak menjamin keakuratan, kecukupan atau kelengkapan informasi yang diberikan di setiap posting blog. Tidak ada representasi atau jaminan, tersurat maupun tersirat, dibuat atau diberikan oleh atau atas nama Blockchain Capital, penulis atau orang lain mengenai keakuratan dan kelengkapan atau keadilan informasi yang terkandung dalam setiap posting blog dan tidak ada tanggung jawab atau kewajiban yang diterima untuk informasi semacam itu. Tidak ada yang terkandung dalam setiap posting blog yang merupakan investasi, peraturan, hukum, kepatuhan atau pajak atau saran lainnya juga tidak dapat diandalkan dalam membuat keputusan investasi. Posting blog tidak boleh dilihat sebagai rekomendasi saat ini atau sebelumnya atau permintaan penawaran untuk membeli atau menjual sekuritas apa pun atau untuk mengadopsi strategi investasi apa pun. Posting blog mungkin berisi proyeksi atau pernyataan berwawasan ke depan lainnya, yang didasarkan pada keyakinan, asumsi, dan ekspektasi yang dapat berubah sebagai akibat dari banyak peristiwa atau faktor yang mungkin terjadi. Jika terjadi perubahan, hasil aktual dapat berbeda secara material dari yang diungkapkan dalam pernyataan berwawasan ke depan. Semua pernyataan berwawasan ke depan hanya berbicara pada tanggal pernyataan tersebut dibuat, dan baik Blockchain Capital maupun masing-masing penulis tidak bertanggung jawab untuk memperbarui pernyataan tersebut kecuali sebagaimana diwajibkan oleh hukum. Sejauh dokumen, presentasi, atau materi lain apa pun yang diproduksi, diterbitkan, atau didistribusikan oleh Blockchain Capital direferensikan dalam entri blog apa pun, materi tersebut harus dibaca dengan hati-hati untuk setiap penafian yang disediakan di dalamnya.