Anagram Build menghabiskan sebagian besar waktu kami untuk meneliti primitif kripto novel dan menerapkan primitif-primitif ini dalam produk-produk tertentu. Salah satu proyek penelitian terbaru kami membawa kami ke dalam ranah Verifiable Compute (VC); tim kami memanfaatkan penelitian ini untuk membuat sistem open source baru yang disebutBonsolKami memilih area penelitian ini mengingat munculnya kasus penggunaan yang efektif yang memungkinkan VC dan upaya bersama di berbagai L1 untuk mengoptimalkan efisiensi biaya dan skalabilitas VC.

Dalam blog ini, kami memiliki dua tujuan.

• Pertama, kami ingin memastikan Anda memahami dengan lebih baik tentang VC sebagai konsep dan produk-produk yang mungkin dimungkinkan di ekosistem Solana.
• Kedua, kami ingin memperkenalkan kepada Anda penciptaan terbaru kami, Bonsol.

Apa itu Komputasi yang Dapat Diverifikasi, sih?

Istilah 'Komputasi yang Dapat Diverifikasi' mungkin tidak muncul dalam presentasi investasi perusahaan rintisan pasar bullish, tetapi istilah 'Pengetahuan Nol' muncul. Jadi, apa arti istilah-istilah ini?

Verifiable Compute (VC) sedang menjalankan beban kerja tertentu dengan cara menghasilkan pernyataan tentang cara kerjanya yang dapat diverifikasi secara publik tanpa menjalankan komputasi lagi. Zero Knowledge (ZK) adalah kemampuan untuk membuktikan pernyataan tentang data atau komputasi tanpa mengungkapkan semua data atau input ke komputasi tersebut. Istilah-istilah tersebut agak disamarkan dalam dunia nyata, ZK agak salah kaprah. Lebih banyak berkaitan dengan pemilihan informasi yang perlu dibuat publik untuk membuktikan pernyataan tentangnya. VC adalah istilah yang lebih akurat dan merupakan tujuan utama dalam banyak arsitektur sistem terdistribusi yang ada.

Bagaimana VC membantu kami membangun produk kripto yang lebih baik?

Jadi, mengapa kita ingin menambahkan sistem VC atau ZK, di atas platform seperti Solana dan Ethereum? Sepertinya jawabannya lebih tentang keamanan bagi pengembang. Pengembang sebuah sistem berperan sebagai mediator antara kepercayaan pengguna akhir pada kotak hitam dan fungsi teknis yang membuat kepercayaan itu secara objektif valid. Dengan memanfaatkan teknik ZK/VC, pengembang dapat mengurangi area serangan dalam produk yang mereka bangun. Sistem VC menggeser tempat kepercayaan ke sistem pembuktian dan beban komputasi yang sedang dibuktikan. Ini adalah inversi kepercayaan yang serupa yang terjadi saat beralih dari pendekatan klien/server web2 khas ke pendekatan blockchain web3. Kepercayaan bergeser dari bergantung pada janji perusahaan menjadi mempercayai kode sumber terbuka dan sistem kriptografi jaringan. Tidak ada sistem nol-kepercayaan yang sebenarnya dari sudut pandang pengguna, dan saya berpendapat bahwa bagi pengguna akhir, semuanya terlihat seperti kotak hitam.

Sebagai contoh, dengan menggunakan sistem login ZK, seorang pengembang akan memiliki tanggung jawab yang lebih sedikit dalam memelihara database yang aman dan infrastruktur daripada hanya sebuah sistem yang memverifikasi beberapa properti kriptografis yang tercapai. Teknik VC sedang diterapkan di banyak tempat di mana konsensus diperlukan untuk memastikan bahwa satu-satunya hal yang diperlukan untuk menciptakan konsensus adalah matematika yang valid.

Meskipun ada banyak contoh menjanjikan penggunaan VC dan ZK di lapangan, banyak dari mereka saat ini bergantung pada pengembangan yang sedang berlangsung di semua tingkat tumpukan perangkat lunak kripto untuk membuatnya cukup cepat dan efisien untuk digunakan dalam produksi.

Sebagai bagian dari pekerjaan kami di Anagram, kami memiliki kesempatan untuk berbicara dengan sejumlah pendiri / pengembang kripto untuk memahami di mana keadaan saat ini dari tumpukan perangkat lunak kripto memperlambat inovasi produk. Secara historis, percakapan kami telah membantu kami mengidentifikasi tren menarik. Secara khusus, sekelompok proyek sedang aktif memindahkan logika produk on-chain ke off-chain karena menjadi terlalu mahal, atau mereka perlu menambahkan logika bisnis yang lebih eksotis. Jadi pada akhirnya para pengembang ini mendapati diri mereka mencoba menemukan sistem dan alat untuk menyeimbangkan bagian on- dan off-chain dari produk yang mereka kembangkan yang semakin kuat. Inilah di mana VC menjadi bagian penting dari jalur ke depan dalam membantu menghubungkan dunia on- dan off-chain menggunakan metode yang dapat dipercaya dan diverifikasi.

Ayo pergi! Jadi bagaimana sistem VC/ZK bekerja hari ini?

Fungsi VC dan ZK kini utamanya dilakukan di lapisan komputasi alternatif (juga dikenal sebagai rollups, sidechains, relays, oracles, atau coprocessors) yang tersedia melalui panggilan balik ke waktu runtime kontrak cerdas. Untuk memungkinkan alur kerja ini, banyak rantai L1 memiliki upaya dalam proses untuk menyediakan pintasan di luar waktu runtime kontrak cerdas (misalnya, syscalls atau precompiles) yang memungkinkan mereka melakukan hal-hal yang seharusnya terlalu mahal di rantai.

Ada beberapa mode umum dari sistem VC saat ini. Aku akan menyebutkan empat yang paling aku ketahui. Dalam semua kecuali kasus terakhir, bukti ZK terjadi di luar rantai, tetapi di mana dan kapan bukti-bukti tersebut diverifikasi memberikan keunggulan masing-masing mode ini.

Verifikasi Penuh On-chain

Untuk sistem VC dan ZK yang dapat menghasilkan bukti kecil, seperti Groth16 atau beberapa variasi Plonk, bukti tersebut kemudian diserahkan ke rantai dan diverifikasi di rantai menggunakan kode yang telah diterapkan sebelumnya. Sistem-sistem seperti ini sekarang sangat umum, dan cara terbaik untuk mencobanya adalah dengan menggunakan Circom dan verifikasi Groth16 pada Solana atau EVM. Kekurangannya adalah bahwa sistem-sistem bukti ini cukup lambat. Mereka juga biasanya memerlukan pembelajaran bahasa baru. Untuk memverifikasi hash 256-bit di Circom, Anda sebenarnya perlu menangani secara manual masing-masing dari 256 bit tersebut. Ada banyak pustaka yang memungkinkan Anda hanya memanggil fungsi hash, tetapi di balik layar, Anda perlu mengimplementasikan ulang fungsi-fungsi ini dalam kode Circom Anda. Sistem-sistem ini bagus ketika elemen ZK dan VC dari kasus penggunaan Anda lebih kecil, dan Anda memerlukan bukti tersebut valid sebelum tindakan deterministik lainnya diambil. Bonsol termasuk dalam kategori pertama ini saat ini.

Verifikasi Off-chain

Bukti tersebut diserahkan ke rantai sehingga semua pihak dapat melihat bahwa itu ada dan kemudian dapat menggunakan komputasi di luar rantai untuk memverifikasi nantinya. Dalam mode ini, Anda dapat mendukung sistem pembuktian apa pun, tetapi karena bukti tersebut tidak terjadi di rantai, Anda tidak mendapatkan determinisme yang sama untuk tindakan apa pun yang bergantung pada pengiriman bukti. Ini bagus untuk sistem yang memiliki semacam jendela tantangan di mana pihak-pihak dapat "menolak" dan mencoba membuktikan bahwa bukti tersebut tidak benar.

Jaringan Verifikasi

Bukti tersebut dikirimkan ke jaringan verifikasi, dan jaringan verifikasi tersebut bertindak sebagai oracle untuk memanggil kontrak pintar. Anda mendapatkan determinisme, namun Anda juga perlu mempercayai jaringan verifikasi tersebut.

Verifikasi On-chain Sinkron

Mode keempat dan terakhir agak berbeda; dalam hal ini, pembuktian dan verifikasi terjadi sekaligus dan sepenuhnya on-chain. Inilah tempat di mana L1 atau kontrak pintar di L1 benar-benar mampu menjalankan skema ZK atas input pengguna yang memungkinkan eksekusi untuk dibuktikan atas data pribadi. Tidak terlalu banyak contoh yang tersebar luas tentang hal ini, dan biasanya, jenis hal yang dapat Anda lakukan dengan ini terbatas pada operasi matematika yang lebih dasar.

Recap

Keempat mode ini sedang diuji coba di berbagai ekosistem rantai, dan kita akan melihat apakah pola baru muncul dan pola mana yang menjadi dominan. Sebagai contoh, di Solana, tidak ada pemenang yang jelas, dan lanskap VC dan ZK masih sangat awal. Metode paling populer di banyak rantai, termasuk Solana, adalah mode pertama. Verifikasi sepenuhnya di rantai adalah standar emas, tetapi seperti yang dibahas, ada beberapa kelemahan. Terutama keterlambatan dan pembatasan apa yang dapat dilakukan sirkuit Anda. Saat kita menyelami Bonsol, Anda akan melihat bahwa itu mengikuti mode pertama dengan sedikit sentuhan.

Memperkenalkan Bonsol!

MasukkanBonsol, sebuah sistem VC asli Solana baru yang kami bangun di Anagram dan sumber terbuka. Bonsol memungkinkan pengembang membuat eksekutor yang dapat diverifikasi atas data pribadi dan publik dan mengintegrasikan hasilnya ke dalam kontrak pintar Solana. Perlu dicatat bahwa proyek ini bergantung pada chain tool RISC0 yang populer.

Proyek ini terinspirasi oleh pertanyaan yang diajukan oleh banyak proyek yang kami kerjakan setiap minggunya: “Bagaimana saya bisa melakukan hal ini dengan data pribadi dan membuktikannya di rantai?” Meskipun “hal” berbeda dalam setiap kasus, keinginan yang mendasarinya sama: untuk meminimalkan ketergantungan terpusat mereka.

Sebelum kita masuk ke detail sistem, mari kita mulai dengan menggambarkan kekuatan Bonsol dengan dua kasus penggunaan yang berbeda.

Skenario satu

Sebuah Dapp yang memungkinkan pengguna untuk membeli tiket undian ke dalam kolam hadiah berbagai token. Kolam hadiah tersebut "dituangkan" sekali sehari dari kolam global dengan cara yang jumlah uang di dalam kolam (jumlah setiap token) tersembunyi. Pengguna dapat membeli akses ke rentang token dalam kolam yang semakin spesifik. Tetapi ada yang menarik: begitu seorang pengguna membeli rentang tersebut, itu menjadi publik bagi semua pengguna pada saat yang sama. Pengguna kemudian harus memutuskan untuk membeli tiket. Mereka dapat memutuskan bahwa tidak sepadan untuk dibeli, atau mereka dapat mengamankan saham dalam kolam dengan membeli tiket.

Bonsol masuk ke dalam permainan ketika kolam dibuat dan ketika pengguna membayar untuk rentang menjadi dikenal. Ketika kolam dibuat/dianggarkan, program ZK mengambil masukan pribadi dari jumlah setiap token untuk dituangkan. Jenis token adalah masukan yang diketahui, dan alamat kolam adalah masukan yang diketahui. Bukti ini adalah bukti pemilihan acak dari kolam global ke dalam kolam saat ini. Bukti tersebut berisi komitmen terhadap saldo juga. Kontrak on-chain akan menerima bukti ini, memverifikasinya, dan memegang komitmen tersebut sehingga saat kolam akhirnya ditutup dan saldo dikirimkan dari kolam global ke pemilik tiket undian, mereka dapat memverifikasi bahwa jumlah token tidak berubah sejak pemilihan acak di awal kolam.

Ketika seorang pengguna membeli "pembukaan" rentang saldo token tersembunyi, program ZK mengambil saldo token aktual sebagai input pribadi dan menghasilkan rentang nilai yang dikomunikasikan bersama dengan bukti. Input publik dari program ZK ini adalah bukti penciptaan pool yang sebelumnya dikomunikasikan dan keluarannya. Dengan cara ini, seluruh sistem diverifikasi. Bukti sebelumnya harus divalidasi dalam bukti rentang, dan saldo token harus di-hash ke nilai yang sama yang dikomunikasikan dalam bukti pertama. Bukti rentang juga dikomunikasikan ke rantai dan, seperti yang sudah disebutkan sebelumnya, membuat rentang terlihat bagi semua peserta.

Meskipun ada banyak cara untuk menyelesaikan sistem tiket undian ini, properti Bonsol membuatnya cukup mudah untuk memiliki sedikit kepercayaan pada entitas yang mengadakan undian. Ini juga menyoroti interkoneksi Solana dan sistem VC. Program Solana (kontrak pintar) memainkan peran penting dalam memediasi kepercayaan tersebut karena memverifikasi bukti-bukti dan kemudian memungkinkan program untuk mengambil tindakan selanjutnya.

Skenario dua

Bonsol memungkinkan pengembang membuat primitif yang digunakan oleh sistem lain. Bonsol mengandung gagasan tentang implementasi, di mana seorang pengembang dapat membuat beberapa program ZK dan mendistribusikannya ke operator Bonsol. Operator jaringan Bonsol saat ini memiliki beberapa cara dasar untuk mengevaluasi apakah permintaan eksekusi untuk salah satu program ZK akan menguntungkan secara ekonomi. Mereka dapat melihat beberapa informasi dasar tentang seberapa banyak komputasi yang akan diambil oleh program ZK, ukuran input, dan tip yang ditawarkan oleh peminta. Seorang pengembang dapat mendistribusikan primitif yang mereka pikir banyak Dapps lain akan ingin gunakan.

Dalam konfigurasi untuk program ZK, pengembang menentukan urutan dan tipe input yang diperlukan. Pengembang dapat melepaskan InputSet yang memprediksi beberapa atau semua input. Ini berarti mereka dapat mengonfigurasi beberapa input sehingga mereka dapat membuat primitif yang dapat membantu pengguna memverifikasi komputasi atas dataset yang sangat besar.

Sebagai contoh, katakanlah bahwa seorang pengembang menciptakan sebuah sistem yang, dengan diberikan sebuah NFT, dapat membuktikan secara on-chain transfer kepemilikan termasuk kumpulan dompet tertentu. Pengembang dapat memiliki set input yang telah dikonfigurasi sebelumnya yang berisi sejumlah informasi transaksi historis. Program ZK mencari melalui set ini untuk menemukan pemilik yang sesuai. Ini adalah contoh yang dibuat-buat dan dapat dilakukan dengan berbagai cara.

Pertimbangkan contoh lain: seorang pengembang dapat menulis program ZK yang dapat memverifikasi bahwa tanda tangan keypair berasal dari keypair atau set keypair hierarkis tanpa mengungkapkan kunci publik dari keypair otoritatif tersebut. Katakanlah itu berguna bagi banyak Dapps lain, dan mereka menggunakan program ZK ini. Protokol memberikan tip penggunaan kecil kepada penulis program ZK ini. Karena kinerja sangat penting, para pengembang didorong untuk membuat program-program mereka cepat sehingga operator ingin menjalankannya, dan pengembang yang mencoba meniru karya pengembang lain perlu mengubah program tersebut dalam beberapa cara untuk dapat mendeploynya karena ada validasi dari konten program ZK. Setiap operasi yang ditambahkan ke program ZK akan memengaruhi kinerja, dan meskipun ini tentu tidak sempurna, hal ini mungkin membantu memastikan bahwa para pengembang mendapat imbalan atas inovasi.

Arsitektur Bonsol

Kasus penggunaan ini membantu menjelaskan untuk apa Bonsol berguna, tetapi mari kita lihat arsitektur saat ini, model insentif saat ini, dan alur eksekusinya.

Gambar di atas menggambarkan alur dari seorang pengguna yang perlu melakukan jenis komputasi yang dapat diverifikasi, biasanya melalui dapp yang membutuhkan hal ini agar pengguna dapat melakukan tindakan tertentu. Ini akan berupa Permintaan Eksekusi yang berisi informasi tentang ZKprogram yang dieksekusi, input atau set input, waktu di mana komputasi harus dibuktikan, dan tip (cara Relays dibayar). Permintaan diambil oleh Relays dan mereka harus bersaing untuk memutuskan apakah mereka ingin mengklaim eksekusi ini dan mulai membuktikan. Berdasarkan kemampuan operator relay tertentu, mereka mungkin memilih untuk melewatkan ini karena tipnya tidak sepadan atau zkprogram atau input terlalu besar. Jika mereka memutuskan untuk melakukan komputasi ini, mereka harus mengeksekusi klaim atasnya. Jika mereka yang pertama kali mendapatkan klaim, maka bukti mereka akan diterima hingga waktu tertentu. Jika mereka gagal menghasilkan bukti tepat waktu, node lain dapat mengklaim eksekusi. Untuk mengklaim, Relay harus menempatkan sejumlah taruhan yang saat ini sudah diprogramkan keras menjadi tip / 2 yang akan dipotong jika mereka gagal menghasilkan bukti yang benar.

Bonsol dibangun dengan tesis bahwa lebih banyak komputasi akan beralih ke lapisan di mana hal itu diuji dan diverifikasi pada rantai, dan bahwa Solana akan menjadi rantai "pilihan" bagi VC dan ZK segera. Transaksi cepat Solana, komputasi murah, dan basis pengguna yang berkembang menjadikannya tempat yang sangat baik untuk menguji gagasan-gagasan ini.

Apakah mudah untuk dibangun? Tidak sama sekali!

Ini bukan berarti tidak ada tantangan dalam membangun Bonsol. Untuk mengambil bukti Risco0 dan memverifikasinya di Solana, kita perlu membuatnya lebih kecil. Tetapi kita tidak bisa melakukannya tanpa mengorbankan properti keamanan dari bukti tersebut. Jadi kita menggunakan Circom dan membungkus Risc0 Stark yang bisa berada di sekitar ~200kb dan membungkusnya dalam bukti Groth16 yang selalu berukuran 256 byte. Untungnya, Risc0 menyediakan beberapa alat awal untuk ini, tetapi itu menambahkan banyak overhead dan ketergantungan pada sistem.

Saat kami mulai membangun Bonsol dan menggunakan perkakas yang ada untuk membungkus Stark dengan Snark, kami mencari cara untuk mengurangi ketergantungan dan meningkatkan kecepatan. Circom memungkinkan kompilasi kode Circom ke C ++ atau wasm. Kami pertama kali mencoba mengkompilasi sirkuit Circom menjadi file wasmu yang diproduksi oleh LLVM. Ini adalah cara tercepat dan paling efisien untuk membuat perkakas Groth16 portabel dan masih cepat. Kami memilih wasm karena portabilitasnya karena kode C ++ bergantung pada arsitektur cpu x86, yang berarti MacBook baru atau server berbasis Arm tidak akan dapat menggunakan ini. Tapi ini menjadi jalan buntu bagi kami di timeline yang harus kami kerjakan. Karena sebagian besar eksperimen penelitian produk kami adalah kotak waktu sampai mereka membuktikan nilainya, kami memiliki 2-4 minggu waktu pengembangan untuk menguji ide ini. Kompiler llvm wasm tidak dapat menangani kode wasm yang dihasilkan. Dengan lebih banyak pekerjaan, kami bisa melewati ini, tetapi kami mencoba banyak bendera pengoptimalan dan cara untuk membuat kompiler llvm berfungsi sebagai plugin wasmer untuk mengkompilasi kode ini ke llvm, tetapi kami tidak berhasil. Karena sirkuit Circom sekitar 1,5 juta baris kode, Anda dapat membayangkan bahwa jumlah Wasm menjadi sangat besar. Kami kemudian mengalihkan pandangan kami untuk mencoba membuat jembatan antara C ++ dan basis kode relai Rust kami. Ini juga menemui kekalahan cepat karena C ++ berisi beberapa kode perakitan khusus x86 yang tidak ingin kami mainkan. Untuk mengeluarkan sistem ke publik, kami akhirnya hanya mem-bootstrap sistem dengan cara yang menggunakan kode C ++ tetapi menghapus beberapa dependensi. Di masa depan, kami ingin memperluas lini pengoptimalan lain yang sedang kami kerjakan. Itu untuk mengambil kode C ++ dan benar-benar mengkompilasinya menjadi grafik eksekusi. Artefak C ++ dari kompilasi Circom ini sebagian besar hanya aritmatika modular di atas a bidang hinggadengan nomor prima yang sangat besar sebagai generator. Ini menunjukkan beberapa hasil yang menjanjikan untuk artefak C++ yang lebih kecil dan lebih sederhana, tetapi lebih banyak kerja yang diperlukan untuk membuatnya berfungsi dengan sistem Risc0. Hal ini disebabkan karena kode C++ yang dihasilkan memiliki sekitar 7 juta baris kode, dan generator grafik tampaknya mencapai batas ukuran tumpukan, dan menaikkan itu tampaknya menghasilkan kesalahan lain yang belum sempat kami tentukan. Meskipun beberapa jalur ini tidak berhasil, kami dapat memberikan kontribusi kepada proyek OSS dan berharap bahwa pada suatu saat kontribusi tersebut akan dimasukkan ke hulu.

Serangkaian tantangan berikutnya lebih terletak pada ruang desain. Bagian penting dari sistem ini adalah kemampuan untuk memiliki input pribadi. Input-input itu perlu berasal dari suatu tempat, dan karena keterbatasan waktu kami tidak dapat menambahkan sistem enkripsi MPC yang canggih untuk memungkinkan input pribadi berada dalam sistem dalam loop tertutup. Jadi untuk mengatasi kebutuhan ini dan membuka blokir pengembang kami menambahkan gagasan tentang server input pribadi yang perlu memvalidasi pemberi permintaan tersebut, yang divalidasi oleh tanda tangan dari payload adalah klaiman saat ini dari bukti dan melayani mereka. Saat kami memperluas Bonsol kami berencana untuk mengimplementasikan sistem dekripsi ambang batas MPC di mana node Relay dapat memungkinkan klaiman untuk mendekripsi input pribadi. Seluruh diskusi tentang input pribadi ini membawa kami ke evolusi desain yang kami rencanakan untuk tersedia di repositori Bonsol. Itu adalah Bonsolace, yang merupakan sistem yang lebih sederhana yang memungkinkan Anda sebagai pengembang untuk dengan mudah membuktikan program zk ini di infrastruktur Anda sendiri. Alih-alih membagi ke jaringan pembuktian Anda dapat membuktikannya sendiri dan memverifikasinya pada kontrak yang sama dengan yang digunakan oleh jaringan pembuktian. Kasus penggunaan ini adalah untuk kasus penggunaan data pribadi yang sangat bernilai tinggi di mana akses ke data pribadi harus diminimalkan dengan segala biaya.

Satu catatan terakhir tentang Bonsol yang belum pernah kita lihat di tempat lain yang menggunakan Risc0 adalah bahwa kita memaksa komitmen (hash) atas data masukan ke dalam program zk. Dan kita benar-benar memeriksa kontrak bahwa masukan yang harus diakui oleh pembuktian harus sesuai dengan apa yang diharapkan oleh pengguna dan dikirimkan ke dalam sistem. Ini memerlukan biaya tertentu, tetapi tanpanya berarti pembuktian dapat menipu dan menjalankan zkprogram atas masukan yang tidak ditentukan oleh pengguna. Sisanya pengembangan Bonsol masuk ke dalam pengembangan Solana normal, tetapi perlu dicatat bahwa kita dengan sengaja mencoba beberapa ide baru di sana. Pada kontrak pintar, kami menggunakan flatbuffers sebagai satu-satunya sistem serialisasi. Ini adalah teknik yang agak baru yang ingin kita lihat dikembangkan dan dibuat menjadi kerangka kerja karena sangat cocok untuk menghasilkan sdk otomatis yang lintas platform. Satu catatan terakhir tentang Bonsol adalah bahwa saat ini perlu ada pra-kompilasi untuk bekerja secara paling efisien, pra-kompilasi ini dijadwalkan untuk mendarat di Solana 1.18, tetapi sampai saat itu kita sedang berusaha untuk melihat apakah tim-tim tertarik pada penelitian ini dan melihat melampaui Bonsol ke teknologi lain.

Membungkus

Di luar Bonsol, tim membangun anagram sedang memperhatikan banyak tempat dalam domain VC. Proyek seperti Jolt, zkllvm, spartan 2, Binius adalah proyek yang sedang kami lacak, bersama dengan perusahaan yang bekerja di ruang Enkripsi Homomorfik Penuh (FHE), jika Anda tidak tahu apa itu, tetap terhubung karena kami akan membahasnya pada suatu titik.

Silakan periksa repositori Bonsol dan buat isu untuk contoh yang Anda butuhkan atau bagaimana Anda ingin memperluasnya. Ini adalah proyek yang sangat awal dan Anda memiliki kesempatan untuk membuat jejak Anda.

Jika Anda sedang mengerjakan proyek VC yang menarik, kami mendorong Anda untuk daftar di sini untuk program Anagram EIRdi mana bersama tim Anagram Anda akan dapat menguji tesis Anda, membangun perusahaan, dan menangani masalah terbesar yang mungkin terjadi. Jangan ragu untuk berkontribusi atau mengajukan pertanyaan apa pun.

Penafian：

1. Artikel ini dicetak ulang dari [ Anagram], Semua hak cipta milik penulis asli [austbot]. Jika ada keberatan terhadap cetakan ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.

2. Penolakan Tanggung Jawab Kewajiban: Pandangan dan opini yang terungkap 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.