ZK kasus penggunaan baru, diskusi mendalam tentang co-prosesor dan berbagai solusi

Karena konsep koprosesor menjadi populer dalam beberapa bulan terakhir, kasus penggunaan ZK baru ini mulai mendapat lebih banyak perhatian.

Namun, kami menemukan bahwa sebagian besar orang masih relatif belum familiar dengan konsep koprosesor, terutama penentuan posisi koprosesor secara tepat - apa itu koprosesor dan apa yang bukan, masih relatif kabur. Mengenai perbandingan solusi teknis dari beberapa track co-processor yang ada di pasaran, belum ada yang memilahnya secara sistematis. Artikel ini diharapkan dapat memberikan pemahaman yang lebih jelas kepada pasar dan pengguna tentang jalur co-processor.

1. Apa itu Co-Processor dan apa yang bukan?

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

Saya pikir apa yang dikatakan Dr. Dong Mo mungkin sangat mendekati jawaban standar—terus terang, koprosesor “memberikan kontrak pintar kemampuan untuk melakukan Dune Analytics.”

Bagaimana cara mendekonstruksi kalimat ini?

Bayangkan skenario di mana kami menggunakan Dune - Anda ingin melakukan LP di Uniswap V3 untuk mendapatkan sejumlah biaya penanganan, jadi Anda membuka Dune dan menemukan volume perdagangan terkini dari berbagai pasangan perdagangan di Uniswap, APR biaya penanganan dalam 7 hari terakhir, dan pasangan perdagangan arus utama Kisaran fluktuasi atas dan bawah, dll…

Atau mungkin ketika StepN menjadi populer, Anda mulai berspekulasi tentang sepatu dan tidak yakin kapan harus menjualnya, jadi Anda melihat data StepN di Dune setiap hari, volume transaksi harian, jumlah pengguna baru, harga dasar sepatu… dan direncanakan setelah ada pertumbuhan. Jika tren melambat atau turun, jalankan dengan cepat.

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

Data ini sangat berarti - tidak hanya membantu menilai perubahan tren, tetapi juga menggunakannya untuk menciptakan lebih banyak trik, seperti pendekatan “data besar” yang biasa digunakan oleh perusahaan Internet besar.

Misalnya, berdasarkan model dan harga sepatu yang sering dibeli dan dijual pengguna, disarankan untuk menggunakan sepatu serupa.

Misalnya, “Program Hadiah Loyalitas Pengguna” akan diluncurkan berdasarkan lamanya waktu pengguna memegang Sepatu Penciptaan untuk memberikan lebih banyak airdrop atau keuntungan kepada pengguna setia.

Misalnya, paket VIP yang mirip dengan Cex dapat diluncurkan berdasarkan TVL atau volume perdagangan yang disediakan oleh LP di Uniswap atau Trader, memberikan pengurangan biaya transaksi Trader atau peningkatan keuntungan bagi hasil LP…

Saat ini, masalahnya muncul - data besar + AI perusahaan Internet besar pada dasarnya adalah kotak hitam. Mereka dapat melakukan apapun yang mereka inginkan. Pengguna tidak dapat melihatnya dan tidak peduli.

Namun di sini, di Web3, transparansi dan ketidakpercayaan adalah kebenaran politik alami kami, dan kami menolak kotak hitam!

Jadi ketika Anda ingin mewujudkan skenario di atas, Anda akan menghadapi dilema - apakah Anda dapat mencapainya melalui cara terpusat, “secara manual” menggunakan Dune untuk menghitung data indeks di latar belakang, lalu menerapkan dan mengimplementasikannya; atau Anda dapat menulis Siapkan kontrak pintar untuk secara otomatis mengambil data ini pada rantai, menyelesaikan penghitungan, dan menyebarkan poin secara otomatis.

Yang pertama akan membawa Anda ke dalam masalah kepercayaan yang “salah secara politis”.

Biaya bahan bakar yang dihasilkan oleh rantai tersebut akan menjadi angka yang sangat besar, dan dompet (sisi proyek) Anda tidak mampu membelinya.

Inilah saatnya co-processor tampil di atas panggung. Gabungkan kedua metode tadi, dan pada saat yang sama gunakan langkah “panduan backend” untuk “menyatakan diri tidak bersalah” melalui cara teknis. Dengan kata lain, gunakan teknologi ZK untuk “mengindeks + Bagian “perhitungan” “membuktikan diri tidak bersalah”, dan kemudian memasukkannya ke kontrak pintar. Dengan cara ini, masalah kepercayaan terpecahkan dan biaya bahan bakar yang besar pun hilang. Sempurna!

Mengapa disebut “koprosesor”? Faktanya, 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 paralel skala besar, grafik perhitungan, dll. Justru karena arsitektur “ko-prosesor” inilah kita memiliki film CG, game, model AI, dll. yang luar biasa saat ini, sehingga arsitektur ko-prosesor ini sebenarnya merupakan lompatan dalam arsitektur komputasi. Kini berbagai tim co-prosesor juga berharap untuk memperkenalkan arsitektur ini ke Web3.0. Blockchain di sini mirip dengan CPU Web3.0. Baik itu L1 atau L2, mereka secara inheren tidak cocok untuk tugas “data berat” dan “logika perhitungan kompleks”, sehingga co-prosesor blockchain diperkenalkan untuk membantu menangani perhitungan tersebut, sehingga sangat memperluas kemungkinan aplikasi blockchain.

Jadi apa yang dilakukan koprosesor dapat diringkas menjadi dua hal:

1. Dapatkan data dari blockchain dan gunakan ZK untuk membuktikan bahwa data yang saya dapatkan adalah benar dan tidak dipalsukan;
2. Buatlah perhitungan yang sesuai berdasarkan data yang baru saya dapatkan, dan sekali lagi gunakan ZK untuk membuktikan bahwa hasil yang saya hitung adalah benar dan tidak palsu. Hasil perhitungannya bisa disebut dengan kontrak pintar “Biaya Rendah + Tanpa Kepercayaan”.

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

Co-processor tidak lebih dari langkah 1 diikuti dengan langkah 2. Setelah mengekstraksi data tanpa kepercayaan, lakukan penghitungan bebas kepercayaan dan selesai.

Jadi untuk menggunakan istilah yang relatif teknis untuk mendeskripsikannya secara akurat, koprosesor harus berupa superset dari Storage Proof/State Proof dan subset dari Verfiable Computation.

Satu hal yang perlu diperhatikan adalah koprosesornya 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 yang terdesentralisasi hanya menggunakan semacam mekanisme kompetisi atau konsensus untuk mencapai hal ini. Ambil, alih-alih Bukti Penyimpanan, bentuk ZK ini. Yang lebih penting adalah selain lapisan kalkulasi, ZK Rollup juga perlu mengimplementasikan lapisan penyimpanan yang mirip dengan blockchain L1. Penyimpanan ini bersifat permanen, sedangkan ZK Coprocessor bersifat “stateless”. Setelah penghitungan selesai, tidak ada status Semua yang dipertahankan.

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

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

Setelah membaca penjelasan diatas mungkin Anda ragu, apakah ZK harus digunakan sebagai coprocessor? Kedengarannya seperti "Grafik dengan tambahan ZK", dan sepertinya kami tidak memiliki "keraguan besar" tentang hasil Grafik tersebut.

Itu karena ketika Anda menggunakan Graph, uang sungguhan pada dasarnya tidak terlibat. Indeks ini melayani layanan off-chain. Apa yang Anda lihat di antarmuka pengguna front-end adalah volume transaksi, riwayat transaksi, dll. Data dapat disediakan melalui beberapa penyedia indeks data seperti Graph, Alchemy, Zettablock, dll., namun data ini tidak dapat dimasukkan kembali ke dalam kontrak pintar, karena setelah Anda memasukkannya kembali, Anda akan menambah kepercayaan tambahan pada layanan indeks. Ketika data dikaitkan dengan uang sungguhan, terutama TVL bervolume besar, kepercayaan ekstra ini menjadi penting. Bayangkan jika lain kali seorang teman meminta Anda meminjam 100 yuan, Anda bisa saja meminjamkannya tanpa berkedip. Ya, bagaimana jika saya meminta Anda meminjam 10.000 yuan, atau bahkan 1 juta yuan?

Namun sekali lagi, apakah kita benar-benar harus menggunakan ZK untuk memproses semua skenario di atas secara bersamaan? Lagi pula, kami memiliki dua rute teknis, OP dan ZK, di Rollup. ZKML yang baru-baru ini populer juga memiliki konsep OPML tentang rute cabang yang sesuai. Ditanya apakah coprocessor juga mempunyai cabang OP seperti OP-Coprocessor?

Faktanya, memang ada - tetapi kami merahasiakan detail spesifiknya untuk saat ini, dan kami akan segera merilis informasi lebih detail.

3. Koprosesor mana yang terbaik - Perbandingan beberapa solusi teknis koprosesor yang umum di pasaran

Brevis

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

Berikut ini adalah diagram arsitektur Brevis:

zkFabric: Mengumpulkan header blok dari semua blockchain yang terhubung dan menghasilkan bukti konsensus ZK yang membuktikan validitas header blok ini. Melalui zkFabric, Brevis mengimplementasikan koprosesor yang dapat dioperasikan untuk banyak rantai, yang memungkinkan satu blockchain mengakses data historis apa pun dari blockchain lain.

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

zkAggregatorRollup: Blockchain konvolusional ZK yang bertindak sebagai lapisan agregasi dan penyimpanan untuk zkFabric dan zkQueryNet. Ini memverifikasi bukti dari kedua komponen, menyimpan data terverifikasi, dan melakukan root status yang divalidasi zk ke semua blockchain yang terhubung.

ZK Fabric adalah bagian penting dalam menghasilkan bukti untuk header blok. Sangat penting untuk menjamin keamanan bagian ini. Berikut ini adalah diagram arsitektur zkFabric:

Klien ringan berbasis zero-knowledge proof (ZKP) zkFabric membuatnya benar-benar tidak dapat dipercaya, tanpa bergantung pada entitas verifikasi eksternal apa pun. Tidak perlu bergantung pada entitas verifikasi eksternal mana pun, karena keamanannya sepenuhnya berasal dari blockchain yang mendasarinya dan bukti yang dapat diandalkan secara matematis.

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

zkFabric mengandalkan asumsi keamanan blockchain dan protokol kriptografi yang mendasarinya serta asumsi keamanan dari protokol kriptografi yang mendasarinya. Namun, untuk memastikan efektivitas zkFabric, setidaknya diperlukan satu relayer yang jujur untuk menyinkronkan fork yang benar. Oleh karena itu, zkFabric menggunakan jaringan relai terdesentralisasi, bukan relai tunggal, untuk mengoptimalkan efektivitas zkFabric. Jaringan relai ini dapat memanfaatkan struktur yang ada, seperti jaringan penjaga negara di jaringan Celer.

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

Penerapan saat ini:

Protokol klien ringan yang saat ini diterapkan 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 menambahkan kumpulan uniswap khusus secara signifikan. Namun dibandingkan dengan CEX, UnisWap masih kurang memiliki kemampuan pemrosesan data yang efektif untuk membuat proyek yang mengandalkan data transaksi pengguna yang besar (seperti program loyalitas berdasarkan volume transaksi). Fungsi.

Dengan bantuan Brevis, Hook memecahkan tantangan tersebut. Hooks sekarang dapat membaca data rantai riwayat lengkap pengguna atau LP dan menjalankan penghitungan yang dapat disesuaikan dengan cara yang sepenuhnya tidak dapat dipercaya.

Herodotus

Herodotus adalah middleware akses data kuat yang menyediakan kontrak pintar dengan fungsi berikut untuk mengakses data terkini dan historis secara sinkron pada rantai di seluruh lapisan Ethereum:

1. L1 menyatakan dari L2s
2. L2 menyatakan dari L1 dan L2 lainnya
3. L3/App-Chain menyatakan ke L2 dan L1

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

Inti dari blockchain adalah database, dimana datanya dienkripsi dan dilindungi menggunakan struktur data seperti pohon Merkle dan pohon Merkle Patricia. Yang unik dari struktur data ini adalah setelah data dimasukkan dengan aman ke dalamnya, bukti dapat dihasilkan untuk mengonfirmasi bahwa data terdapat di dalam struktur tersebut.

Penggunaan pohon Merkle dan pohon Merkle Patricia meningkatkan keamanan blockchain Ethereum. Dengan melakukan hashing data secara kriptografis pada setiap level pohon, hampir tidak mungkin mengubah data tanpa terdeteksi. Setiap perubahan pada titik data memerlukan perubahan hash yang sesuai pada pohon menjadi hash root, yang dapat dilihat secara publik di header blockchain. Fitur mendasar dari blockchain ini memberikan integritas dan kekekalan data tingkat tinggi.

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

Bukti penyimpanan seperti yang didefinisikan oleh Herodotus merupakan perpaduan dari:

1. Bukti penahanan: Bukti ini mengkonfirmasi keberadaan data spesifik dalam struktur data kriptografi (seperti pohon Merkle atau pohon Merkle Patricia), memastikan bahwa data yang dimaksud memang ada dalam kumpulan data.
2. Bukti Komputasi: Verifikasi eksekusi alur kerja multi-langkah, buktikan validitas satu atau lebih elemen dalam kumpulan data yang luas, seperti seluruh blockchain Ethereum atau agregatnya. Selain menunjukkan keberadaan data, mereka juga memverifikasi transformasi atau operasi yang diterapkan pada data tersebut.
3. Bukti tanpa pengetahuan: Menyederhanakan jumlah data yang dibutuhkan kontrak pintar untuk berinteraksi. Bukti tanpa pengetahuan memungkinkan kontrak pintar 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 pengidentifikasi unik blok dan merangkum semua isinya melalui header blok. Dalam alur kerja bukti penyimpanan, pertama-tama kita perlu menentukan dan memverifikasi hash blok dari blok yang berisi data yang kita minati. Ini adalah langkah pertama dalam keseluruhan proses.

2.Dapatkan header blok

Setelah hash blok yang relevan diperoleh, langkah selanjutnya adalah mengakses header blok. Untuk melakukan ini, header blok yang terkait dengan hash blok yang diperoleh pada langkah sebelumnya perlu di-hash. Hash dari header blok yang disediakan kemudian dibandingkan dengan hash blok yang dihasilkan:

Ada dua cara untuk mendapatkan hash:

1. Gunakan opcode BLOCKHASH untuk mengambil
2. Kueri hash blok yang telah diverifikasi dalam riwayat dari Block Hash Accumulator

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

3.Tentukan akar yang dibutuhkan (opsional)

Dengan header blok di tangan, kita dapat mempelajari isinya, khususnya:

stateRoot: Intisari kriptografi dari seluruh status blockchain pada saat blockchain terjadi.

ReceiptsRoot: Intisari terenkripsi dari semua hasil transaksi (kwitansi) di blok.

TransactionsRoot: Intisari kriptografi dari semua transaksi yang terjadi di blok.

dapat didekodekan, memungkinkan verifikasi apakah akun, tanda terima, atau transaksi tertentu termasuk dalam blok.

4.Validasi data terhadap root yang dipilih (opsional)

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

Jaringan yang didukung saat ini:

1. Dari Ethereum hingga Starknet
2. Dari Ethereum Goerli hingga Starknet Goerli
3. Dari Ethereum Goerli hingga zkSync Era Goerli

Aksioma

Axiom menyediakan cara bagi pengembang untuk menanyakan header blok, akun, atau nilai penyimpanan dari seluruh riwayat Ethereum. AXIOM memperkenalkan metode penautan baru berdasarkan kriptografi. Semua hasil yang dikembalikan oleh Axiom diverifikasi secara on-chain melalui bukti tanpa pengetahuan, yang berarti kontrak pintar dapat menggunakannya tanpa asumsi kepercayaan tambahan.

Axiom baru-baru ini merilis Halo2-repl, halo2 REPL berbasis browser yang ditulis dalam Javascript. Hal ini memungkinkan pengembang untuk menulis sirkuit ZK hanya menggunakan Javascript standar tanpa harus mempelajari bahasa baru seperti Rust, menginstal perpustakaan bukti, atau menangani dependensi.

Aksioma terdiri dari dua komponen teknologi utama:

1. AxiomV1 — Cache blockchain Ethereum, dimulai dengan Genesis.
2. AxiomV1Query — Kontrak pintar yang mengeksekusi kueri terhadap AxiomV1.

Caching blok hash di AxiomV1:

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

Pertama, akar Keccak Merkle dari 1024 hash blok berturut-turut di-cache. Akar Merkle ini diperbarui melalui bukti ZK, memverifikasi bahwa hash header blok membentuk rantai komitmen yang diakhiri 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 Pegunungan Merkle dari akar Merkle ini mulai dari blok genesis. Pegunungan Merkle dibangun secara on-chain dengan memperbarui bagian pertama dari cache, root Keccak Merkle.

Jalankan kueri di AxiomV1Query:

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

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

Perhubungan

Nexus berupaya menggunakan bukti tanpa pengetahuan untuk membangun platform universal untuk komputasi awan yang dapat diverifikasi. Saat ini arsitektur mesinnya agnostik dan mendukung risc 5/ WebAssembly/ EVM. Nexus menggunakan sistem bukti supernova. Tim menguji bahwa memori yang diperlukan untuk menghasilkan bukti adalah 6GB. Kedepannya akan dioptimalkan atas dasar ini sehingga komputer perangkat klien biasa dapat menghasilkan bukti.

Tepatnya, arsitekturnya dibagi menjadi dua bagian:

1. Nexus zero: Jaringan komputasi awan terdesentralisasi yang dapat diverifikasi dan didukung oleh bukti tanpa pengetahuan dan zkVM universal.
2. Nexus: Jaringan komputasi awan terdesentralisasi yang dapat diverifikasi dan didukung oleh komputasi multi-pihak, replikasi mesin negara, dan mesin virtual WASM universal.

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

Aplikasi Nexus berjalan pada jaringan komputasi awan terdesentralisasi, yang pada dasarnya merupakan “blockchain tanpa server” untuk tujuan umum yang terhubung langsung ke Ethereum. Oleh karena itu, aplikasi Nexus tidak mewarisi keamanan Ethereum, namun sebagai gantinya mendapatkan akses ke daya komputasi yang lebih tinggi (seperti komputasi, penyimpanan, dan I/O berbasis peristiwa) karena berkurangnya ukuran jaringannya. Aplikasi Nexus berjalan di cloud khusus yang mencapai konsensus internal dan memberikan “bukti” komputasi yang dapat diverifikasi (bukan bukti sebenarnya) melalui tanda tangan ambang batas seluruh jaringan yang dapat diverifikasi dalam Ethereum.

Aplikasi Nexus Zero memang mewarisi keamanan Ethereum, karena merupakan program universal dengan bukti tanpa pengetahuan yang dapat diverifikasi secara on-chain pada kurva elips BN-254.

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

Penafian:

1. Artikel ini dicetak ulang dari [panewslab]. Semua hak cipta milik penulis asli [ABCDE]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya milik penulis dan bukan merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.