Sejak "Musim Prasasti" pada tahun 2023, teknologi Layer2 Bitcoin telah berada di garis depan revolusi Web3. Meskipun memasuki bidang tersebut lebih lambat daripada solusi Layer2 Ethereum, Bitcoin telah memanfaatkan daya tarik unik dari POW dan peluncuran lancar spot ETF, yang bebas dari risiko "sekuritisasi," untuk menarik miliaran dolar investasi ke sektor yang sedang berkembang ini hanya dalam enam bulan. Di antara ini, Merlin menonjol sebagai entitas terbesar dan paling diikuti dalam lanskap Bitcoin Layer2, mengendalikan miliaran total nilai terkunci (TVL). Berkat insentif staking yang jelas dan pengembalian yang mengesankan, Merlin dengan cepat naik ke puncak, bahkan melampaui ekosistem Blast yang terkenal dalam waktu beberapa bulan. Dengan kehebohan di sekitar Merlin yang semakin meningkat, eksplorasi infrastruktur teknisnya telah memikat pemirsa yang semakin banyak. Dalam artikel ini, Geek Web3 fokus pada mendekripsi strategi teknis di balik Merlin Chain. Dengan membongkar dokumen yang tersedia secara publik dan dasar pikiran di balik desain protokolnya, kami bertujuan untuk menjelaskan proses operasional Merlin dan meningkatkan pemahaman mengenai kerangka keamanannya, memberikan pandangan yang lebih jelas tentang bagaimana solusi Layer2 Bitcoin terkemuka ini berfungsi.

Jaringan Oracle Terdesentralisasi Merlin: Sebuah Komite DAC Off-Chain Terbuka

Untuk setiap teknologi Layer2, menangani ketersediaan data (DA) dan biaya publikasi data tetap menjadi tantangan kritis, baik itu untuk Ethereum Layer2 atau Bitcoin Layer2. Mengingat keterbatasan inheren jaringan Bitcoin, yang mengalami kesulitan dengan throughput data besar, merencanakan penggunaan efisien ruang DA berharga adalah ujian signifikan bagi kreativitas pengembang Layer2.

Tampak jelas bahwa jika proyek Layer2 langsung mempublikasikan data transaksi mentah ke blockchain Bitcoin, mereka akan gagal mencapai throughput tinggi dan biaya rendah. Solusi utama termasuk sangat mengompres data untuk mengurangi ukurannya secara signifikan sebelum mengunggahnya ke blockchain Bitcoin, atau memilih untuk mempublikasikan data di luar rantai.

Di antara mereka yang menggunakan strategi pertama, Citrea menonjol. Mereka bertujuan untuk mengunggah perubahan dalam status Layer2 selama interval tertentu, yang melibatkan pencatatan hasil perubahan status di berbagai akun, bersama dengan bukti pengetahuan nol (ZKPs) yang sesuai, ke blockchain Bitcoin. Dalam pengaturan ini, siapa pun dapat mengakses perbedaan status dan ZKPs dari mainnet Bitcoin untuk melacak perubahan status Citrea. Pendekatan ini secara efektif mengurangi ukuran data yang diunggah ke blockchain hingga lebih dari 90%.

Meskipun ini dapat sangat mengompres ukuran data, bottleneck masih jelas. Jika sejumlah besar akun mengubah status mereka dalam waktu singkat, Layer 2 harus merangkum dan mengunggah semua perubahan dalam akun-akun ini ke rantai Bitcoin. Biaya rilis data akhir tidak dapat dijaga sangat rendah. Hal ini terjadi di banyak Ethereums. Hal ini dapat dilihat di ZK Rollup.

Banyak Bitcoin Layer 2 hanya mengambil jalur kedua: langsung menggunakan solusi DA di bawah rantai Bitcoin, baik membangun lapisan DA sendiri, atau menggunakan Celestia, EigenDA, dll. B^Square, BitLayer, dan protagonis artikel ini, Merlin, semuanya menggunakan solusi ekspansi DA di luar rantai ini.

Artikel sebelumnya di web3 geek——“Analisis Rencana Jalan Teknologi Versi Baru B^2: Kebutuhan DA dan Lapisan Verifikasi di Bawah Rantai Bitcoin”, kami menyebutkan bahwa B^2 langsung meniru Celestia dan membangun jaringan DA yang mendukung fungsi pengambilan data di bawah rantai, yang disebut B^2 Hub. 'Data DA' seperti data transaksi atau perbedaan status disimpan di bawah rantai Bitcoin, dan hanya datahash / akar merkle diunggah ke Bitcoin mainnet.

Ini pada dasarnya memperlakukan Bitcoin sebagai papan buletin tanpa kepercayaan: siapa pun dapat membaca datahash dari rantai Bitcoin. Setelah Anda mendapatkan data DA dari penyedia data off-chain, Anda dapat memeriksa apakah itu sesuai dengan datahash on-chain, yaitu hash(data1) == datahash1? Jika ada korespondensi antara keduanya, itu berarti bahwa data yang diberikan kepada Anda oleh penyedia data off-chain itu benar.

Lapisan DA dijelaskan dalam Layer2 Bitcoin:

(Sumber Gambar: Geek web3)

Sistem ini memastikan bahwa data dari node off-chain berkorelasi dengan “petunjuk” atau bukti spesifik pada Layer1, melindungi dari masalah potensial dari lapisan DA yang memberikan informasi palsu. Namun, kekhawatiran besar muncul jika asal data—Sequencer—gagal mendistribusikan data aktual yang terkait dengan datahash. Misalkan Sequencer hanya mengirimkan datahash ke blockchain Bitcoin sementara dengan sengaja menahan data yang sesuai dari akses publik. Apa yang terjadi selanjutnya?

Pertimbangkan skenario di mana hanya ZK-Proof dan StateRoot yang dibuat publik, tetapi data DA yang mendampingi (seperti perbedaan status atau data transaksi) tidak dirilis. Meskipun memungkinkan untuk memvalidasi ZK-Proof dan memastikan transisi dari Prev_Stateroot ke New_Stateroot akurat, ini meninggalkan ketidakjelasan mengenai status akun mana yang berubah. Dalam keadaan seperti ini, meskipun aset pengguna tetap aman, kondisi jaringan sebenarnya tetap tidak jelas. Tidak ada yang tahu transaksi mana yang telah dimasukkan ke dalam blockchain atau status kontrak mana yang telah diperbarui, yang efektif membuat Layer2 tidak berfungsi, hampir seolah-olah telah menjadi offline.

Praktik ini disebut sebagai "penyembunyian data." Pada Agustus 2023, Dankrad dari Ethereum Foundation memulai diskusi di Twitter tentang konsep yang dikenal sebagai "DAC."

Dalam banyak pengaturan Ethereum Layer2 yang memanfaatkan solusi ketersediaan data di luar rantai (DA), seringkali ada beberapa node dengan hak istimewa khusus yang membentuk sebuah komite yang dikenal sebagai Komite Ketersediaan Data (DAC). Komite ini berfungsi sebagai penjamin, menjamin bahwa Sequencer memang telah melepaskan data DA lengkap (data transaksi atau perbedaan status) di luar rantai. Anggota DAC kemudian membuat tanda tangan kolektif. Jika tanda tangan kolektif ini mencapai ambang batas yang diperlukan (misalnya, 2 dari 4), kontrak-kontrak yang sesuai di Layer1 dirancang untuk mengasumsikan bahwa Sequencer telah memenuhi standar verifikasi DAC dan telah secara sungguh-sungguh melepaskan data DA lengkap di luar rantai.

Komite Ethereum Layer2 DAC sebagian besar mematuhi model Proof of Authority (POA), membatasi keanggotaan ke sekelompok node terpilih yang telah lulus KYC atau telah ditunjuk secara resmi. Pendekatan ini telah secara efektif mencap DAC sebagai ciri khas "sentralisasi" dan "blockchain konsorsium." Selain itu, dalam Ethereum Layer2s tertentu yang menggunakan pendekatan DAC, sequencer mendistribusikan data DA semata-mata ke node anggota DAC, dengan penyebaran eksternal minimal. Akibatnya, siapa pun yang mencari data DA harus mendapatkan persetujuan dari DAC, mirip dengan beroperasi dalam blockchain konsorsium.

Jelas bahwa DACs perlu didesentralisasikan. Meskipun Layer2 mungkin tidak diperlukan untuk mengunggah data DA secara langsung ke Layer1, akses keanggotaan DAC seharusnya dapat diakses secara publik untuk menghindari kolusi dan kesalahan oleh beberapa individu. (Untuk informasi lebih lanjut mengenai masalah ini, lihat diskusi sebelumnya dari Dankrad di Twitter.)

Usulan Celestia tentang BlobStream pada dasarnya bertujuan untuk menggantikan DAC terpusat dengan Celestia. Dalam model ini, sekuenser Ethereum L2 akan mengirimkan data DA ke blockchain Celestia. Jika dua pertiga dari node Celestia memvalidasi data ini, kontrak Layer2 khusus di Ethereum akan memvalidasi bahwa sekuenser telah secara akurat mempublikasikan data DA, sehingga menempatkan node Celestia sebagai penjamin. Mengingat bahwa Celestia beroperasi dengan ratusan node validator, konfigurasi DAC yang lebih besar ini dianggap relatif terdesentralisasi.

Solusi DA yang diadopsi oleh Merlin sebenarnya cukup dekat dengan BlobStream Celestia, keduanya memberikan akses terbuka ke DAC melalui POS, menjadikannya lebih terdesentralisasi. Siapa pun dapat menjalankan node DAC selama mereka melakukan staking aset yang cukup. Dalam dokumentasi Merlin, node DAC yang disebutkan di atas disebut Oracle, dan dijelaskan bahwa akan mendukung penjaminan aset BTC, MERL, dan bahkan token BRC-20 untuk mengimplementasikan mekanisme penjaminan yang fleksibel dan juga mendukung penjaminan proksi mirip dengan Lido. (Perjanjian penjaminan POS dari mesin oracle pada dasarnya adalah salah satu narasi inti Merlin selanjutnya, dan tingkat bunga penjaminan yang disediakan relatif tinggi)

Di sini kami secara singkat menjelaskan alur kerja Merlin (gambar di bawah):

1. Setelah sequencer menerima sejumlah besar permintaan transaksi, itu menggabungkannya dan menghasilkan paket data (paketa data), yang diteruskan ke node Prover dan node Oracle (DAC terdesentralisasi).

2. Node Prover Merlin terdesentralisasi dan menggunakan Prover lumoz sebagai layanan. Setelah menerima beberapa paket data, kolam penambangan Prover akan menghasilkan bukti nol pengetahuan yang sesuai. Setelah itu, ZKP akan dikirim ke node Oracle untuk diverifikasi.

3. Node Oracle akan memverifikasi apakah Bukti ZK yang dikirim oleh kolam penambangan ZK Lmuoz sesuai dengan Batch data yang dikirim oleh Sequencer. Jika kedua nya dapat dipasangkan dan tidak mengandung kesalahan lain, verifikasi dinyatakan lulus. selama proses ini, Node Oracle Terdesentralisasi akan menghasilkan multi-tanda tangan melalui tandatangan ambang dan menyatakan kepada dunia luar bahwa sequencer telah sepenuhnya mengirimkan data DA, dan ZKP yang sesuai valid dan telah lulus verifikasi dari Node Oracle.

4. Sequencer mengumpulkan hasil multi-tanda tangan dari node Oracle. Ketika jumlah tanda tangan memenuhi persyaratan ambang, informasi tanda tangan dikirim ke rantai Bitcoin, bersama dengan datahash dari data DA (pembatchan data), dan diserahkan kepada dunia luar untuk dibaca dan dikonfirmasi.

(Diagram prinsip kerja Merlin sumber: Geek web3)

1. Node Oracle melakukan pemrosesan khusus pada proses perhitungan verifikasi ZK Proof, menghasilkan komitmen Komitmen, dan mengirimkannya ke rantai Bitcoin, memungkinkan siapa pun untuk menantang 'komitmen'. Proses di sini pada dasarnya sama dengan protokol bukti penipuan bitVM. Jika tantangan berhasil, Node Oracle yang mengeluarkan Komitmen akan dikenai hukuman finansial. Tentu saja, data yang diinginkan Oracle untuk dipublikasikan ke rantai Bitcoin juga mencakup hash dari status Layer 2 saat ini - StateRoot, serta ZKP itu sendiri, yang harus dipublikasikan ke rantai Bitcoin untuk deteksi eksternal.

Referensi:“Interpretasi Minimalis BitVM: Bagaimana Memverifikasi Bukti Penipuan pada Rantai BTC”

Ada beberapa detail yang perlu dijelaskan di sini. Pertama-tama, disebutkan dalam peta jalan Merlin bahwa Oracle akan mencadangkan data DA ke Celestia di masa depan. Dengan cara ini, node Oracle dapat menghapus data historis lokal dengan benar tanpa perlu Data berkelanjutan secara lokal. Pada saat yang sama, Komitmen yang dihasilkan oleh Jaringan Oracle sebenarnya adalah akar Pohon Merkle. Tidak cukup untuk mengungkapkan akar ke dunia luar. Kumpulan data lengkap yang sesuai dengan Komitmen harus dibuat publik. Ini memerlukan menemukan platform DA pihak ketiga. Platform ini bisa menjadi Celestia atau EigenDA, atau lapisan DA lainnya.

Referensi:“Analisis Roadmap Teknologi Versi Baru B^2: Kebutuhan DA dan Lapisan Verifikasi di Bawah Rantai Bitcoin”

Analisis model keamanan: Optimistic ZKRollup+Cobo’s Layanan MPC

Di atas, kami telah secara singkat menjelaskan alur kerja Merlin, dan saya yakin Anda telah menguasai struktur dasarnya. Tidak sulit untuk melihat bahwa Merlin, B^Square, BitLayer, dan Citrea pada dasarnya mengikuti model keamanan yang sama—optimistic ZK-Rollup.

Ketika membaca kata ini untuk pertama kalinya, banyak penggemar Ethereum mungkin merasa aneh. Apa itu "Optimistic ZK-Rollup"? Dalam pemahaman komunitas Ethereum, "model teoritis" ZK Rollup sepenuhnya didasarkan pada keandalan perhitungan kriptografis dan tidak memerlukan pengenalan asumsi kepercayaan. Kata "optimistic" secara tepat mengenalkan asumsi kepercayaan, yang berarti bahwa kebanyakan waktu, orang-orang optimis bahwa Rollup tidak memiliki kesalahan dan dapat diandalkan. Begitu kesalahan terjadi, operator Rollup dapat dihukum melalui bukti kecurangan. Inilah asal mula nama Optimistic Rollup, juga dikenal sebagai OP Rollup.

Untuk ekosistem Ethereum di dasar Rollup, ZK-Rollup optimis mungkin agak tidak deskriptif, tetapi itu persis sesuai dengan situasi saat ini dari Layer 2 Bitcoin. Karena keterbatasan teknis, rantai Bitcoin tidak dapat sepenuhnya memverifikasi ZK Proof. Itu hanya dapat memverifikasi langkah tertentu dari proses perhitungan ZKP dalam keadaan khusus. Dalam premis ini, rantai Bitcoin sebenarnya hanya dapat mendukung protokol bukti penipuan. Orang Bisa ditunjukkan bahwa ada kesalahan dalam langkah perhitungan tertentu dari ZKP selama proses verifikasi off-chain, dan ditantang melalui bukti penipuan. Tentu saja, ini tidak bisa dibandingkan dengan ZK Rollup gaya Ethereum, tetapi ini sudah yang terbaik yang bisa dicapai Layer 2 Bitcoin saat ini. Model keamanan yang andal dan paling aman.

Di bawah skema ZK-Rollup optimis di atas,Asumsikan bahwa ada N orang di jaringan Layer 2 yang memiliki wewenang untuk memulai tantangan. Selama salah satu penantang N jujur dan dapat diandalkan dan dapat mendeteksi kesalahan dan memulai bukti penipuan kapan saja, transisi status Layer 2 aman. Tentu saja, Rollup optimis dengan tingkat penyelesaian yang relatif tinggi perlu memastikan bahwa jembatan penarikannya juga dilindungi oleh protokol bukti penipuan. Namun, hampir semua Bitcoin Layer 2 saat ini tidak dapat mencapai premis ini dan perlu mengandalkan multi-signature/MPC. Jadi bagaimana cara memilih multi-signature? Menandatangani solusi MPC telah menjadi masalah yang terkait erat dengan keamanan Layer 2.

Merlin memilih layanan MPC Cobo untuk solusi jembatan. Menggunakan langkah-langkah seperti isolasi dompet panas dan dingin, aset jembatan dikelola bersama oleh Cobo dan Merlin Chain. Setiap perilaku penarikan perlu ditangani bersama oleh peserta MPC dari Cobo dan Merlin Chain. Pada dasarnya, keandalan jembatan penarikan dijamin melalui dukungan kredit dari institusi. . Tentu saja, ini hanya tindakan sementara pada tahap ini. Ketika proyek secara bertahap membaik, jembatan penarikan dapat diganti dengan "jembatan optimis" dengan asumsi kepercayaan 1 / N dengan memperkenalkan BitVM dan protokol bukti penipuan. Namun, implementasi ini akan lebih sulit. Besar (hampir semua jembatan Layer 2 resmi saat ini mengandalkan multi-signature).

Secara keseluruhan, kami dapat mengatasi, Merlin memperkenalkan DAC berbasis POS, ZK-Rollup optimis berbasis BitVM, dan solusi aset kustodia MPC berbasis Cobo, menyelesaikan masalah DA dengan membuka izin DAC; memastikan keamanan transisi status dengan memperkenalkan BitVM dan protokol bukti penipuan; memastikan keandalan jembatan penarikan dengan memperkenalkan layanan MPC dari platform kustodia aset terkenal Cobo.

Strategi Pengajuan ZKP Verifikasi Dua Langkah Lumoz

Dalam diskusi sebelumnya, kita membahas kerangka keamanan Merlin dan menjelajahi konsep inovatif dari optimistic ZK-rollups. Salah satu elemen kunci dalam lintasan teknologi Merlin adalah Prover terdesentralisasi. Peran ini sangat penting dalam arsitektur ZK-Rollup, bertugas untuk menghasilkan ZK Proofs untuk batch yang dilepaskan oleh Sequencer. Pembuatan bukti pengetahuan nol (zero-knowledge proofs) membutuhkan sumber daya yang signifikan, yang merupakan tantangan besar.

Salah satu strategi dasar untuk mempercepat pembangkitan bukti ZK adalah dengan membagi dan melakukan parallelisasi tugas. Proses ini, yang dikenal sebagai paralelisasi, melibatkan memecah pembangkitan bukti ZK menjadi bagian-bagian yang berbeda. Setiap bagian ditangani oleh Prover yang berbeda, dan akhirnya, seorang Aggregator menggabungkan bukti-bukti individu ini menjadi kesatuan utuh. Pendekatan ini tidak hanya mempercepat proses tetapi juga mendistribusikan beban komputasi secara efektif.

Untuk mempercepat proses generasi bukti ZK, Merlin akan mengadopsi Solusi Prover sebagai layanan dari Lumoz, sebenarnya, ini adalah untuk mengumpulkan sejumlah besar perangkat keras bersama-sama untuk membentuk sebuah kolam penambangan, dan kemudian mengalokasikan tugas komputasi ke perangkat yang berbeda dan memberikan insentif yang sesuai, yang agak mirip dengan penambangan POW.

Dalam solusi Prover terdesentralisasi ini, ada jenis skenario serangan, yang biasa dikenal sebagai serangan front-running: Anggaplah bahwa seorang Aggregator telah membentuk ZKP, dan ia mengirim ZKP untuk mendapatkan imbalan. Setelah aggregator lain melihat konten ZKP, mereka mempublikasikan konten yang sama sebelumnya, mengklaim bahwa dia yang pertama kali menghasilkan ZKP. Bagaimana menyelesaikan situasi ini?

Mungkin solusi yang paling insting yang dipikirkan semua orang adalah dengan melakukan penugasan nomor tugas yang ditentukan untuk setiap Aggregator. Misalnya, hanya Aggregator A yang bisa mengambil tugas 1, dan yang lain tidak akan mendapatkan imbalan meskipun menyelesaikan tugas 1. Namun, ada masalah dengan pendekatan ini, yaitu tidak dapat melawan risiko titik tunggal. Jika Aggregator A mengalami kegagalan kinerja atau terputus, tugas 1 akan terhenti dan tidak dapat diselesaikan. Selain itu, metode mengalokasikan tugas kepada satu entitas tunggal ini tidak dapat meningkatkan efisiensi produksi melalui mekanisme insentif kompetitif, dan bukan pendekatan yang baik.

Polygon zkEVM pernah mengusulkan metode bernama Proof of efficiency dalam sebuah blog, yang menunjukkan bahwa cara kompetitif harus digunakan untuk mempromosikan persaingan antara berbagai Aggregator, dan insentif harus dialokasikan secara first-come, first-served. Aggregator yang pertama kali mengirimkan ZK-Proof ke rantai dapat menerima imbalan. Tentu saja, dia tidak menyebutkan bagaimana cara menyelesaikan masalah MEV front-running.

Lumoz mengadopsi metode pengiriman sertifikat ZK verifikasi dua langkah. Setelah Aggregator menghasilkan sertifikat ZK, tidak perlu mengirimkan konten lengkap terlebih dahulu, tetapi hanya mempublikasikan hash ZKP. Dengan kata lain, mempublikasikan hash (ZKP+Alamat Aggregator). Dengan cara ini, meskipun orang lain melihat nilai hash, mereka tidak mengetahui konten ZKP yang sesuai dan tidak dapat langsung melompat ke depan;

Jika seseorang hanya menyalin seluruh hash dan mempublikasikannya terlebih dahulu, tidak ada gunanya, karena hash tersebut berisi alamat aggregator X tertentu. Bahkan jika aggregator A mempublikasikan hash terlebih dahulu, ketika gambar asli dari hash terungkap, semua orang juga akan melihat bahwa alamat aggregator yang terkandung di dalamnya adalah X, bukan A.

Melalui skema pengiriman ZKP verifikasi dua langkah ini, Merlin (Lumoz) dapat mengatasi masalah front-running yang ada dalam proses pengiriman ZKP, sehingga mencapai insentif generasi bukti pengetahuan nol yang sangat kompetitif, sehingga meningkatkan kecepatan generasi ZKP.

Merlin’s Phantom: Interoperabilitas lintas-rantai

Menurut peta jalan teknologi Merlin, mereka juga akan mendukung interoperabilitas antara Merlin dan rantai EVM lainnya, jalur implementasinya pada dasarnya sama dengan ide Zetachain sebelumnya. Jika Merlin digunakan sebagai rantai sumber dan rantai EVM lainnya digunakan sebagai rantai target, ketika node Merlin merasakan permintaan interoperabilitas lintas rantai yang dikeluarkan oleh pengguna, itu akan memicu pekerjaan berikutnya pada rantai target.

Sebagai contoh, sebuah akun EOA yang dikendalikan oleh jaringan Merlin dapat diterapkan di Polygon, Ketika seorang pengguna mengeluarkan instruksi interoperabilitas lintas-rantai di Rantai Merlin, Jaringan Merlin pertama-tama memparsing kontennya dan menghasilkan data transaksi yang akan dieksekusi di rantai target, lalu Jaringan Oracle melakukan pemrosesan tanda tangan MPC pada transaksi untuk menghasilkan tanda tangan transaksi. Node Pemancar Merlin kemudian melepas transaksi tersebut di Polygon, menyelesaikan operasi lanjutan melalui aset Merlin dalam akun EOA di rantai target, seperti.

Ketika operasi yang diminta oleh pengguna selesai, aset yang sesuai akan langsung diteruskan ke alamat pengguna pada rantai target. Secara teori, itu juga dapat langsung ditransfer ke Merlin Chain. Solusi ini memiliki beberapa manfaat yang jelas: itu dapat menghindari biaya penanganan dan keausan yang disebabkan oleh kontrak jembatan lintas-rantai ketika aset tradisional lintas-rantai, dan keamanan operasi lintas-rantai secara langsung dijamin oleh Jaringan Oracle Merlin, dan tidak perlu bergantung pada infrastruktur pihak eksternal. Selama pengguna percaya Merlin Chain, perilaku interoperabilitas lintas-rantai seperti itu dapat diasumsikan tidak ada masalah.

Ringkasan

Dalam artikel ini, kami secara singkat menginterpretasikan solusi teknis umum Merlin Chain, yang kami percaya akan memungkinkan lebih banyak orang memahami alur kerja umum Merlin dan memiliki pemahaman yang lebih jelas tentang model keamanannya. Mengingat bahwa ekosistem Bitcoin saat ini sedang berkembang pesat, kami percaya bahwa jenis kegiatan popularisasi teknologi seperti ini bernilai dan dibutuhkan oleh masyarakat umum. Kami akan melakukan tindak lanjut jangka panjang pada Merlin, bitLayer, B^Square, dan proyek-proyek lainnya di masa depan, untuk analisis teknis yang lebih mendalam, jadi tetap terhubung!

Disclaimer:

1. Artikel ini direproduksi dari [geek web3]], hak cipta dimiliki oleh penulis asli [Faust], jika Anda keberatan dengan penyalinan ulang, harap hubungiTim Pembelajaran Gate, tim akan menanganinya secepat mungkin sesuai dengan prosedur yang relevan.

2. Pandangan dan opini yang diungkapkan dalam artikel ini hanya mewakili pandangan pribadi penulis dan tidak merupakan saran investasi apa pun.

3. Versi bahasa lain dari artikel diterjemahkan oleh tim Gate Learn. Tanpa referensi Gate.io, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.