Kian Paimani, pengembang inti Parity, membahas protokol JAM yang baru diusulkan oleh Polkadot dari sudut pandang teknis untuk membantu orang memahami bagaimana JAM membawa skalabilitas baru ke ekosistem Polkadot.
Menulis: Kian Paimani, Pengembang Inti Parity
Compile: Polkadot Labs
"Graph Pengetahuan Polkadot" adalah serangkaian artikel pemula kami tentang Polkadot, kami mencoba untuk memulai dari hal-hal paling dasar tentang Polkadot, memberikan pemahaman yang komprehensif tentang Polkadot. Tentu saja, ini adalah proyek yang besar dan penuh tantangan, tetapi kami berharap melalui usaha ini, orang-orang dapat memahami Polkadot dengan benar dan orang-orang yang tidak mengenal Polkadot dapat dengan mudah dan cepat mempelajari pengetahuan terkait Polkadot. *Ini adalah edisi ke-148 dari kolom ini, dan artikel ini ditulis oleh pengembang inti Parity, Kian Paimani, dari sudut pandang teknis untuk menjelaskan protokol JAM terbaru dari Polkadot, untuk membantu orang-orang memahami bagaimana JAM membawa skalabilitas baru ke dalam ekosistem Polkadot. Artikel ini ditulis dalam sudut pandang orang pertama oleh penulis.
*Berikut adalah penjelasan detail tentang Polkadot1, Polkadot2, dan bagaimana mereka berkembang menjadi JAM. (Lihat rinciannya di: ***) Artikel ini ditujukan untuk pembaca teknis, terutama mereka yang tidak terlalu familiar dengan Polkadot tetapi memiliki pemahaman tentang sistem blockchain, dan mungkin juga pembaca yang familiar dengan teknologi terkait ekosistem lainnya.
*Saya pikir, membaca artikel ini adalah bagian yang baik sebelum membaca JAM whitepaper. (Lihat detailnya di: ***)
Latar Belakang
Teks ini mengasumsikan pembaca memiliki pemahaman tentang konsep-konsep berikut:
Menggambarkan Blokchain sebagai fungsi perubahan status.
Memahami apa itu "status". (Lihat detailnya di: _sdk_docs/reference_docs/blockchain_state_machines/index.html)
Keamanan ekonomi dan Proof of Stake. (Lihat:、)
Pendahuluan: Polkadot1
Pertama, mari kita tinjau fitur paling inovatif menurut saya dari Polkadot1.
Aspek Sosial:
Polkadot adalah sebuah Organisasi Otonom yang Terdesentralisasi (DAO) yang besar. Jaringan ini menerapkan tata kelola yang sepenuhnya berbasis on-chain, yang dapat dieksekusi sendiri, termasuk peningkatan runtime tanpa fork.
Komisi Sekuritas dan Bursa Amerika Serikat (SEC) menganggap DOT sebagai perangkat lunak bukan sekuritas. (Lihat rincian di: )
Sebagian besar pengembangan jaringan dilakukan oleh Fellowship Polkadot (lihat: ) daripada perusahaan yang didukung secara finansial (seperti Parity: ).
Aspek Teknis:
Polkadot telah mewujudkan keamanan berbagi dan eksekusi Sharding.
Menggunakan protokol meta berbasis WASM (lihat: _sdk_docs/reference_docs/wasm_meta_protocol/index.html), kode blockchain disimpan dalam bentuk bytecode di dalam status. Ini memungkinkan sebagian besar peningkatan tanpa perlu fork, dan juga dapat mencapai Sharding heterogen.
Untuk informasi lebih lanjut tentang 'Sharding heterogen', silakan lihat bab terkait.
Pelaksanaan Sharding: Poin Penting
Saat ini, kami sedang membahas jaringan Layer1 yang menghosting jaringan Layer2 'blockchain' lainnya, mirip dengan Polkadot dan Ethereum. Oleh karena itu, istilah Layer2 dan Parachain dapat digunakan secara bergantian.
Masalah inti skalabilitas Blok dapat dinyatakan sebagai: ada sekelompok validator yang dapat memastikan eksekusi kode tertentu dapat dipercaya melalui ekonomi kripto Proof of Stake (Proof-of-Stake). Secara default, validator ini perlu mengeksekusi semua pekerjaan satu sama lain. Oleh karena itu, selama kita memaksa semua validator untuk selalu mengeksekusi segalanya, sistem secara keseluruhan tidak dapat ditingkatkan.
Harap diperhatikan, penambahan jumlah validator dalam model ini tidak benar-benar meningkatkan throughput sistem selama prinsip-prinsip absolut re-execution di atas tetap tidak berubah.
Tampilkan adalah sebuah rangkaian Blok tunggal (berlawanan dengan rangkaian Blok Sharding). Semua validator jaringan akan memproses masukan (yaitu Blok) satu per satu.
Dalam sistem seperti itu, jika Layer 1 ingin meng-host lebih banyak Layer 2, maka semua validator sekarang harus mengeksekusi ulang semua pekerjaan Layer 2. Jelas, pendekatan ini tidak terukur. Optimistic Rollups adalah cara untuk menghindari masalah ini, karena mereka hanya dieksekusi kembali jika seseorang mengklaim bahwa penipuan telah terjadi (bukti penipuan). Rollup berbasis SNARK menghindari masalah ini dengan mengambil keuntungan dari fakta bahwa biaya verifikasi bukti SNARK jauh lebih rendah daripada menghasilkannya, jadi masuk akal untuk mengizinkan semua validator memvalidasi bukti SNARK. Untuk informasi selengkapnya tentang ini, lihat Lampiran: Diagram Spasial Skalabilitas.
Sebuah solusi sederhana untuk Sharding adalah dengan membagi kumpulan validator menjadi subset yang lebih kecil dan membiarkan subset tersebut mengeksekusi Layer2 Blok lagi. Masalah dari pendekatan ini adalah apa? Kami sedang melakukan Sharding untuk keamanan eksekusi dan ekonomi jaringan. Keamanan Layer2 seperti ini lebih rendah daripada Layer1, dan dengan membagi kumpulan validator menjadi lebih banyak Sharding, keamanannya akan semakin menurun.
Berbeda dengan Optimistic Rollups yang tidak dapat selalu mengeksekusi ulang dengan biaya, Polkadot mempertimbangkan eksekusi Sharding saat merancangnya, sehingga sebagian validator dapat mengeksekusi ulang Layer2 Blok sambil memberikan cukup bukti ekonomi kripto kepada semua peserta jaringan untuk membuktikan keaslian Layer2 Blok dan keamanannya ketika seluruh kumpulan validator mengeksekusinya. Hal ini dicapai melalui mekanisme ELVES yang baru-baru ini dirilis. (Lihat rincian di: )
Singkatnya, ELVES dapat dianggap sebagai mekanisme "Rollups" tipe kecurigaan. Dengan beberapa putaran validator secara aktif menanyakan kepada validator lain apakah suatu Blok Layer2 valid, kita dapat dengan sangat besar kemungkinan mengkonfirmasi validitas Blok Layer2 tersebut. Pada kenyataannya, ketika terjadi perselisihan, seluruh kumpulan validator akan segera diminta untuk berpartisipasi. Pendiri bersama Polkadot, Rob Habermeier, menjelaskan hal ini secara rinci dalam sebuah artikel. (Lihat: )
ELVES memungkinkan Polkadot memiliki dua properti yang sebelumnya dianggap saling bertentangan: "Sharding Execution" dan "Shared Security". Ini adalah pencapaian teknologi utama Polkadot1 dalam hal skalabilitas.
Sekarang, mari kita lanjutkan diskusi tentang analogi 'CORE'.
Sebuah Blok yang menjalankan Sharding sangat mirip dengan CPU: seperti inti CPU yang dapat melakukan instruksi secara paralel, Polkadot dapat memproses Layer2 Blok secara paralel. Itulah mengapa Layer2 di Polkadot disebut sebagai parachain, dan lingkungan di mana subset validator yang lebih kecil mengeksekusi kembali satu Blok Layer2 disebut sebagai "core". Setiap core dapat diabstraksikan sebagai "sekelompok validator yang bekerja sama".
Anda dapat membayangkan rantai Blok tunggal sebagai hanya mengambil satu Blok dalam periode waktu yang tidak terbatas, sedangkan Polkadot mengambil satu Blok Rantai Relay dan satu Blok Rantai Paralel inti pada setiap periode waktu.
Heterogenitas
Sampai saat ini, kita hanya membahas skalabilitas dan pelaksanaan Sharding yang ditawarkan oleh Polkadot. Perlu dicatat bahwa setiap Sharding pada Polkadot sebenarnya adalah aplikasi yang benar-benar berbeda. Hal ini dicapai dengan menggunakan protokol elemen yang disimpan dalam bytecode: suatu cara untuk mendefinisikan Blokchain sebagai bytecode yang disimpan dalam status Blokchain itu sendiri. Di Polkadot 1.0, WASM digunakan sebagai bytecode pilihan, sedangkan pada JAM, digunakan PVM/RISC-V.
Secara keseluruhan, inilah mengapa Polkadot disebut sebagai blockchain fragmentasi heterogen. (Lihat: ) Setiap Layer2 adalah aplikasi yang sepenuhnya berbeda.
Polkadot2
Salah satu bagian penting dari Polkadot2 adalah membuat penggunaan inti lebih fleksibel. Dalam model Polkadot asli, masa sewa inti dapat bervariasi dari 6 bulan hingga 2 tahun, cocok untuk perusahaan yang memiliki sumber daya yang cukup, tetapi tidak cocok untuk tim kecil. Fitur yang memungkinkan inti Polkadot digunakan secara lebih fleksibel disebut sebagai "waktu inti yang tangkas" (agile coretime). Dalam mode ini, masa sewa inti Polkadot dapat sependek satu Blok, atau bahkan sampai satu bulan, dan memberikan jaminan harga maksimum bagi pengguna yang ingin menyewa dalam jangka panjang.
Fitur lain dari Polkadot 2 sedang secara bertahap terungkap dalam diskusi kami, sehingga tidak perlu dijelaskan terlalu banyak di sini.
Operasi inti internal dan on-chain
Untuk memahami JAM, pertama-tama perlu memahami apa yang terjadi ketika suatu Blok Layer2 masuk ke inti Polkadot.
Konten berikut telah disederhanakan secara signifikan.
Untuk mengingatnya, intinya terdiri dari sekelompok validator. Jadi, ketika kita mengatakan "data dikirim ke inti", sebenarnya mengacu pada data ini disampaikan ke kelompok validator tersebut.
Sebuah Blok Layer2 ditambah sebagian status Layer2 tersebut dikirim ke inti. Data ini adalah seluruh informasi yang diperlukan untuk mengeksekusi Blok Layer2 tersebut.
Sebagian validator di dalam inti akan menjalankan ulang Blok Layer2 dan melanjutkan pemrosesan tugas yang terkait dengan Konsensus.
Validator inti akan memberikan kembali data yang diperlukan kepada validator lain (validator di luar inti). Validator lainnya mungkin akan memutuskan apakah akan menjalankan ulang Blok Layer2 ini berdasarkan aturan ELVES, dan mereka memerlukan data ini untuk melakukannya.
Perhatikan, sampai saat ini, semua operasi dilakukan di luar blok utama dan fungsi perubahan status dari Polkadot. Semua ini terjadi di dalam inti dan lapisan ketersediaan data.
Pada akhirnya, sebagian kecil dari status terbaru Layer2 akan terlihat di rantai relay utama Polkadot. Berbeda dengan semua operasi sebelumnya, operasi ini jauh lebih murah daripada benar-benar mengeksekusi Blok Layer2, dan akan mempengaruhi status utama Polkadot, terlihat dalam Blok Polkadot, dan dieksekusi oleh semua validator Polkadot.
Dari konten di atas, kita dapat mendiskusikan beberapa operasi yang sedang dilakukan oleh Polkadot:
Pertama, dari Langkah 1, kita dapat menyimpulkan bahwa Polkadot memiliki cara eksekusi baru yang berbeda dari fungsi peralihan status rantai blok tradisional. Biasanya, ketika semua validator dalam jaringan melakukan pekerjaan tertentu, status rantai blok utama akan diperbarui. Kondisi ini disebut sebagai operasi on-chain (on-chain operation), itulah yang terjadi pada Langkah 3. Namun, situasi yang terjadi di dalam inti (Langkah 1) berbeda. Kami menyebut jenis komputasi rantai blok baru ini sebagai eksekusi inti (in-core execution).
Selanjutnya, dari poin kedua kita dapat menyimpulkan bahwa Polkadot telah menyediakan lapisan Data-Availability (DA) yang asli, dan Layer2 secara otomatis menggunakannya untuk memastikan bukti eksekusinya tersedia dalam jangka waktu tertentu. Namun, blok data yang dapat dipublikasikan ke lapisan DA ini tetaplah tetap, selalu menjadi bukti yang diperlukan untuk menjalankan Layer2. Selain itu, kode parachain tidak pernah membaca data lapisan DA ini.
Memahami konten di atas adalah dasar pemahaman JAM. Ringkasannya adalah sebagai berikut:
Eksekusi Inti (in-core execution): merujuk pada operasi yang terjadi di dalam inti. Ini ditandai dengan kekayaan, kemampuan untuk diperluas, dan mencapai tingkat keamanan yang sama dengan eksekusi on-chain melalui ekonomi kripto dan ELVES.
on-chain execution (eksekusi on-chain): Merujuk pada tindakan yang dilakukan oleh semua validator. Validator yang dijamin oleh keamanan ekonomi secara default memiliki keamanan yang lebih tinggi tetapi biayanya lebih tinggi dan memiliki lebih banyak batasan karena semua orang harus melakukan semua tindakan.
Ketersediaan Data (Data Availability): Validator Polkadot berjanji untuk ketersediaan data dalam jangka waktu tertentu, dan memiliki kemampuan untuk memberikan data tersebut kepada validator lainnya.
JAM
Dengan pemahaman dari bagian sebelumnya, kita dapat beralih dengan lancar ke pengenalan JAM.
JAM adalah protokol baru yang terinspirasi oleh Polkadot dan sepenuhnya kompatibel dengannya, dengan tujuan menggantikan relay chain Polkadot dan membuat penggunaan inti menjadi sepenuhnya terdesentralisasi dan tanpa batasan.
JAM dibangun di atas Polkadot2 dengan upaya untuk membuat inti Polkadot lebih mudah diakses, tetapi dengan pendekatan yang lebih fleksibel dan tanpa batasan tetap seperti agile-coretime.
Polkadot2 membuat penyebaran Layer2 menjadi lebih fleksibel secara inti.
JAM bertujuan memungkinkan setiap aplikasi untuk diterapkan pada inti Polkadot, bahkan jika aplikasi tersebut tidak seperti blockchain atau Layer2.
Ini dicapai terutama dengan mengungkapkan tiga konsep utama yang dibahas sebelumnya kepada pengembang: yaitu eksekusi on-chain, eksekusi inti, dan lapisan DA.
Dengan kata lain, di JAM, pengembang dapat mengakses:
完全Programmabilitas化核心内和on-chain的工作。
Memungkinkan data apa pun dibaca dan ditulis ke lapisan DA Polkadot.
Ini adalah deskripsi dasar untuk tujuan JAM. Tidak perlu banyak kata, di sini telah dilakukan banyak penyederhanaan, dan protokol mungkin masih akan berubah.
Dengan pemahaman dasar ini, sekarang kita dapat lebih lanjut membahas beberapa detail JAM di bab-bab berikutnya.
1 Layanan dan Item Kerja
Dalam konteks JAM, yang sebelumnya dikenal sebagai Layer2/parachain sekarang dikenal sebagai "Layanan", sedangkan yang sebelumnya dikenal sebagai Blok/transaksi sekarang dikenal sebagai "Item Kerja" atau "Paket Kerja". Secara khusus, Item Kerja terkait dengan layanan tertentu, sedangkan Paket Kerja merupakan kumpulan dari Item Kerja. Istilah-istilah ini dirancang dengan sengaja untuk cukup umum, sehingga mencakup berbagai kasus penggunaan di luar Blok/Layer2.
Sebuah layanan dideskripsikan oleh tiga titik masuk, di antaranya dua di antaranya adalah fn refine() dan fn accumulate(). Yang pertama menggambarkan konten yang dieksekusi di dalam inti layanan, sementara yang terakhir menggambarkan konten yang dieksekusi on-chain.
Terakhir, nama kedua titik masuk juga menjadi alasan protokol disebut JAM (Join Accumulate Machine). Join merujuk pada fn refine(), ketika semua inti Polkadot menangani sejumlah besar pekerjaan layanan yang berbeda secara paralel, tahap ini disebut Join. Data disaring sebelum masuk ke tahap berikutnya. Accumulate merujuk pada proses semua hasil di atas akumulasi ke status JAM utama, yaitu bagian on-chain execution.
Item kerja dapat secara tepat menentukan apa yang akan dieksekusi di dalam inti, on-chain, dan menunjukkan bagaimana/cara/ dari mana membaca/menulis konten dari Distributed Data Lake.
2 Konsistensi Setengah
Melihat kembali informasi yang ada tentang XCM (bahasa komunikasi parachain yang dipilih oleh Polkadot), semua komunikasi yang ada bersifat asinkron. Artinya, setelah pesan dikirimkan, tidak mungkin menunggu balasannya.
Asinkronitas adalah manifestasi ketidaksesuaian sistem dan merupakan kekurangan utama sistem Sharding yang permanen (seperti Polkadot 1 dan Polkadot 2 serta ekosistem Layer2 yang ada pada Ethereum).
Namun, seperti yang dijelaskan dalam Bagian 2.4 buku putih, sistem yang sepenuhnya konsisten yang selalu menjaga semua penyewanya tetap selaras hanya dapat naik ke tingkat tertentu tanpa mengorbankan universalitas, aksesibilitas, atau elastisitas. (Lihat: )
Ini juga merupakan domain lain di mana JAM unggul: dengan memperkenalkan berbagai fitur, JAM mencapai jenis keadaan tengah yang baru, yaitu sistem konsistensi paruh. Dalam sistem ini, subsistem yang berkomunikasi secara intens memiliki kesempatan untuk menciptakan lingkungan yang konsisten di antara satu sama lain tanpa memaksa seluruh sistem tetap konsisten. Ini adalah deskripsi terbaik yang diberikan oleh Dr. Gavin Wood, penulis buku abu-abu, dalam wawancaranya. (Lihat: _referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ)
Cara lain untuk memahami Polkadot/JAM adalah dengan menganggapnya sebagai sistem Sharding di mana batas-batas Sharding tersebut bersifat fluid dan ditentukan secara dinamis.
Polkadot selalu melakukan Sharding, dan benar-benar heterogen.
Sekarang, itu akan menjadi Sharding, heterogen, dan batas-batas Sharding ini dapat ditentukan secara fleksibel, seperti yang disebutkan oleh Gavin Wood dalam sistem 'semi-konsisten' di Twitter (lihat: _src=twsrc%5Etfw).
Fitur-fitur yang membuat semua ini menjadi mungkin termasuk:
Mengakses eksekusi internal inti yang stateless dan paralel, di mana layanan yang berbeda hanya dapat berinteraksi secara sinkron dengan layanan lain dalam inti yang sama dan dalam Blok khusus, serta eksekusi on-chain, di mana layanan dapat mengakses hasil dari semua layanan di semua inti.
JAM tidak menerapkan penjadwalan layanan yang khusus. Layanan yang berkomunikasi secara sering dapat memberikan insentif ekonomi kepada penjadwal mereka, menciptakan paket kerja yang berisi layanan yang berkomunikasi secara sering ini. Hal ini memungkinkan layanan-layanan ini berjalan di dalam inti yang sama, sehingga komunikasi antar layanan tersebut berjalan seperti dalam lingkungan yang sinkron.
Selain itu, layanan JAM dapat mengakses Data Layer, dan dapat menggunakannya sebagai Data Layer sementara namun sangat murah. Begitu data ditempatkan di DA, itu akhirnya akan menyebar ke semua inti, tetapi akan segera tersedia di inti yang sama. Oleh karena itu, layanan JAM dapat meningkatkan akses data dengan menjadwalkan dirinya sendiri ke inti yang sama dalam Blok yang berurutan.
Perlu diperhatikan bahwa meskipun konten di atas memungkinkan di JAM, namun tidak diterapkan secara paksa di layer protokol. Oleh karena itu, beberapa antarmuka diperkirakan secara teori adalah asinkron, tetapi melalui abstraksi yang cerdas dan insentif, dapat terlihat sinkron dalam praktiknya. Bagian selanjutnya akan membahas CorePlay sebagai contoh ini.
3 CorePlay
Bagian ini mengenalkan CorePlay, yang merupakan ide eksperimental dalam lingkungan JAM yang dapat dijelaskan sebagai model pemrograman Smart Contract baru. Pada saat penulisan artikel ini, CorePlay belum dijelaskan secara rinci dan masih dalam tahap konsepsi.
Untuk memahami CorePlay, pertama-tama kita perlu memperkenalkan Virtual Machine yang dipilih oleh JAM: PVM.
4 PVM
PVM adalah salah satu detail penting dalam JAM dan CorePlay. Detail-detail tingkat rendah dari PVM berada di luar lingkup artikel ini, sebaiknya lihat deskripsi ahli domain dalam whitepaper. Namun, untuk keperluan artikel ini, kita hanya perlu menjelaskan beberapa atribut PVM:
Pengukuran Efisien
Kemampuan untuk menunda dan melanjutkan eksekusi
Yang terakhir sangat penting bagi CorePlay.
CorePlay adalah contoh lingkungan Smart Contract yang synchronous dan scalable yang dibuat menggunakan bahasa pemrograman JAM, dengan antarmuka pemrograman yang sangat fleksibel. CorePlay menyarankan untuk langsung mendeploy Smart Contract berbasis Actor pada inti JAM, sehingga mereka dapat menikmati antarmuka pemrograman synchronous di mana mereka dapat ditulis seperti fn main() biasa, dan berkomunikasi melalui let_result=other_coreplay_actor(data).await? Jika other_coreplay_actor berada pada inti yang sama di Blok JAM, panggilan ini adalah synchronous; jika berada di inti lain, Actor tersebut akan dijeda dan dipulihkan di Blok JAM berikutnya. Hal ini menjadi mungkin karena layanan JAM dan penjadwalan yang fleksibel, serta atribut PVM.
Layanan 5 CoreChains
Terakhir, mari kita rangkum mengapa JAM sepenuhnya kompatibel dengan Polkadot. Produk utama Polkadot berjalan dengan cara waktu inti yang responsif (Agile Core Time) adalah parachain, dan produk ini berlanjut di JAM.
Dalam JAM, layanan yang diterapkan lebih awal kemungkinan akan disebut sebagai CoreChains atau Parachains. Layanan ini akan memungkinkan parachains bergaya Polkadot yang ada beroperasi di JAM.
Layanan yang lebih lanjut dapat diterapkan di JAM dan layanan CoreChains yang ada dapat berkomunikasi dengan mereka, tetapi produk Polkadot yang ada akan tetap kuat dan hanya akan membuka pintu baru bagi tim Parachain yang ada.
Lampiran: Sharding Data
Sebagian besar konten artikel ini membahas skalabilitas dari sudut pandang Sharding. Kita juga bisa melihat masalah yang sama dari sudut pandang data. Menariknya, kami menemukan bahwa ini mirip dengan kasus semi-konsistensi yang disebutkan sebelumnya: secara prinsip, sistem yang sepenuhnya konsisten lebih baik, tetapi tidak dapat diskalakan; sistem yang tidak konsisten sama sekali dapat diskalakan, tetapi tidak ideal, sedangkan JAM dengan model semi-konsistensinya mengusulkan kemungkinan baru.
Sistem yang Sepenuhnya Konsisten: Ini adalah yang kita lihat di platform Smart Contract yang sepenuhnya disinkronkan, seperti Solana atau platform yang berani hanya dideploy di Layer1 Ethereum. Semua data aplikasi disimpan on-chain, dan dapat dengan mudah diakses oleh semua aplikasi lainnya. Ini adalah atribut yang sempurna secara programatik, tetapi tidak dapat diperluas.
Sistem yang Tidak Konsisten: Data aplikasi disimpan di luar Layer1, serta dalam Sharding yang berbeda dan terisolasi. Sangat skalabel, tetapi kinerjanya kurang baik dalam hal komposabilitas. Model Rollup Polkadot dan Ethereum termasuk dalam situasi ini.
Selain menyediakan dua fungsi di atas, JAM juga memungkinkan pengembang untuk mempublikasikan data apa pun ke lapisan JAM DA, yang merupakan area tengah antara data on-chain dan off-chain. Anda dapat mengembangkan aplikasi baru yang menggunakan sebagian besar data aplikasi pada lapisan DA, sambil hanya mengubah data yang sangat penting menjadi status JAM yang persisten.
Lampiran: Peta Ruang Skalabilitas
Bagian ini menjelaskan ulang pandangan kami tentang skalabilitas dalam domain blockchain. Ini juga dijelaskan dalam buku putih dan versi yang lebih ringkas disediakan di sini.
Skalabilitas blockchain dalam banyak hal mengikuti metode yang digunakan dalam sistem terdistribusi tradisional: skalabilitas vertikal dan horizontal.
Ekspansi ke atas adalah pekerjaan yang dilakukan oleh platform seperti Solana. Melalui optimalisasi kode dan perangkat keras hingga batas maksimum untuk mencapai throughput maksimum.
Ekspansi eksternal adalah strategi yang diadopsi oleh Ethereum dan Polkadot: mengurangi jumlah pekerjaan yang perlu dilakukan oleh setiap orang. Dalam sistem terdistribusi tradisional, ini dicapai dengan menambahkan lebih banyak mesin pengganda. Di Blok, 'komputer' adalah kumpulan validator seluruh jaringan. Dengan membagi pekerjaan di antara mereka (seperti yang dilakukan oleh ELVES), atau dengan optimis mengurangi tanggung jawab mereka (seperti yang dilakukan oleh Rollups optimis), kami mengurangi beban kerja keseluruhan kumpulan validator, sehingga mencapai ekspansi sistem secara eksternal.
Dalam Blok rantai, memperluas keluar mirip dengan "mengurangi jumlah mesin yang perlu menjalankan semua operasi".
Ringkasan sebagai berikut:
Scaling up: perangkat keras berkinerja tinggi + optimalisasi blockchain monolitik.
Memperluas ke luar:
Rollups yang Optimis
Rollups berbasis SNARK
ELF: Rollup Ironis Polkadot (Cynical Rollups)
Lampiran: Perangkat Keras yang Sama, Pembaruan Kernel
Bagian ini didasarkan pada analogi yang diberikan oleh Rob Habermeier di Sub02023: Polkadot: Kernel/Userland|Sub02023-YouTube (lihat lebih lanjut di:), yang menggambarkan JAM sebagai peningkatan untuk Polkadot: pembaruan kernel pada perangkat keras yang sama.
Dalam komputer tipikal, kita dapat membagi seluruh tumpukan menjadi tiga bagian:
Hardware
Kernel
ruang pengguna
Di Polkadot, perangkat keras, yang merupakan sifat inti yang menyediakan ketersediaan komputasi dan data, telah menjadi inti, seperti yang telah dijelaskan sebelumnya.
Di dalam Polkadot, inti sebenarnya[9]Sampai saat ini telah mencakup dua bagian:
parachain（Parachains）protokol: cara penggunaan inti yang terstandarisasi dan terfiksasi untuk opini.
Sejumlah fungsi dasar, seperti Token DOT dan transferabilitasnya, stake, governance, dan lain-lain.
Keduanya ada dalam relay chain (Relay Chain) Polkadot.
Aplikasi ruang pengguna adalah contoh parachains, Token asli mereka, dan konten lain yang dibangun di atasnya.
Kita dapat memvisualisasikan proses ini sebagai berikut:
Polkadot selalu bermimpi untuk memindahkan lebih banyak fitur inti ke pengguna kelas satu mereka - parachain. Inilah tujuan yang ingin dicapai oleh Minimal Relay RFC. (Lihat: )
Ini berarti bahwa relay chain Polkadot hanya memproses parachainprotokol yang disediakan, yang pada beberapa tingkat memperkecil ruang inti.
Setelah arsitektur ini tercapai, akan lebih mudah untuk memvisualisasikan migrasi JAM. JAM akan memperkecil ruang inti Polkadot, membuatnya lebih umum. Selain itu, protokol Parachains akan dipindahkan ke ruang penggunaan karena ini adalah salah satu cara yang sedikit untuk menulis aplikasi pada inti (perangkat keras) dan inti (JAM) yang sama.
Ini juga sekali lagi menjelaskan mengapa JAM hanyalah pengganti relay chain Polkadot, bukan pengganti parachain.
Dengan kata lain, kita dapat menganggap migrasi JAM sebagai peningkatan kernel. Perangkat keras dasar tetap sama, sebagian besar konten kernel lama dipindahkan ke ruang pengguna untuk menyederhanakan sistem.
Ingin berpartisipasi dalam diskusi artikel ini, silakan posting pendapat Anda di forum:
Untuk panduan tentang bagaimana berpartisipasi dalam diskusi di forum, silakan lihat Panduan Penggunaan Forum Polkadot yang kami rilis:
"Panduan Penggunaan Forum Resmi Polkadot: Bagaimana Cara Berpartisipasi dalam Diskusi Polkadot"
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Mengungkap JAM Polkadot dari Sudut Teknis
Menulis: Kian Paimani, Pengembang Inti Parity
Compile: Polkadot Labs
"Graph Pengetahuan Polkadot" adalah serangkaian artikel pemula kami tentang Polkadot, kami mencoba untuk memulai dari hal-hal paling dasar tentang Polkadot, memberikan pemahaman yang komprehensif tentang Polkadot. Tentu saja, ini adalah proyek yang besar dan penuh tantangan, tetapi kami berharap melalui usaha ini, orang-orang dapat memahami Polkadot dengan benar dan orang-orang yang tidak mengenal Polkadot dapat dengan mudah dan cepat mempelajari pengetahuan terkait Polkadot. *Ini adalah edisi ke-148 dari kolom ini, dan artikel ini ditulis oleh pengembang inti Parity, Kian Paimani, dari sudut pandang teknis untuk menjelaskan protokol JAM terbaru dari Polkadot, untuk membantu orang-orang memahami bagaimana JAM membawa skalabilitas baru ke dalam ekosistem Polkadot. Artikel ini ditulis dalam sudut pandang orang pertama oleh penulis.
*Berikut adalah penjelasan detail tentang Polkadot1, Polkadot2, dan bagaimana mereka berkembang menjadi JAM. (Lihat rinciannya di: ***) Artikel ini ditujukan untuk pembaca teknis, terutama mereka yang tidak terlalu familiar dengan Polkadot tetapi memiliki pemahaman tentang sistem blockchain, dan mungkin juga pembaca yang familiar dengan teknologi terkait ekosistem lainnya.
*Saya pikir, membaca artikel ini adalah bagian yang baik sebelum membaca JAM whitepaper. (Lihat detailnya di: ***)
Latar Belakang
Teks ini mengasumsikan pembaca memiliki pemahaman tentang konsep-konsep berikut:
Pendahuluan: Polkadot1
Pertama, mari kita tinjau fitur paling inovatif menurut saya dari Polkadot1.
Aspek Sosial:
Aspek Teknis:
Untuk informasi lebih lanjut tentang 'Sharding heterogen', silakan lihat bab terkait.
Pelaksanaan Sharding: Poin Penting
Saat ini, kami sedang membahas jaringan Layer1 yang menghosting jaringan Layer2 'blockchain' lainnya, mirip dengan Polkadot dan Ethereum. Oleh karena itu, istilah Layer2 dan Parachain dapat digunakan secara bergantian.
Masalah inti skalabilitas Blok dapat dinyatakan sebagai: ada sekelompok validator yang dapat memastikan eksekusi kode tertentu dapat dipercaya melalui ekonomi kripto Proof of Stake (Proof-of-Stake). Secara default, validator ini perlu mengeksekusi semua pekerjaan satu sama lain. Oleh karena itu, selama kita memaksa semua validator untuk selalu mengeksekusi segalanya, sistem secara keseluruhan tidak dapat ditingkatkan.
Harap diperhatikan, penambahan jumlah validator dalam model ini tidak benar-benar meningkatkan throughput sistem selama prinsip-prinsip absolut re-execution di atas tetap tidak berubah.
Tampilkan adalah sebuah rangkaian Blok tunggal (berlawanan dengan rangkaian Blok Sharding). Semua validator jaringan akan memproses masukan (yaitu Blok) satu per satu.
Dalam sistem seperti itu, jika Layer 1 ingin meng-host lebih banyak Layer 2, maka semua validator sekarang harus mengeksekusi ulang semua pekerjaan Layer 2. Jelas, pendekatan ini tidak terukur. Optimistic Rollups adalah cara untuk menghindari masalah ini, karena mereka hanya dieksekusi kembali jika seseorang mengklaim bahwa penipuan telah terjadi (bukti penipuan). Rollup berbasis SNARK menghindari masalah ini dengan mengambil keuntungan dari fakta bahwa biaya verifikasi bukti SNARK jauh lebih rendah daripada menghasilkannya, jadi masuk akal untuk mengizinkan semua validator memvalidasi bukti SNARK. Untuk informasi selengkapnya tentang ini, lihat Lampiran: Diagram Spasial Skalabilitas.
Sebuah solusi sederhana untuk Sharding adalah dengan membagi kumpulan validator menjadi subset yang lebih kecil dan membiarkan subset tersebut mengeksekusi Layer2 Blok lagi. Masalah dari pendekatan ini adalah apa? Kami sedang melakukan Sharding untuk keamanan eksekusi dan ekonomi jaringan. Keamanan Layer2 seperti ini lebih rendah daripada Layer1, dan dengan membagi kumpulan validator menjadi lebih banyak Sharding, keamanannya akan semakin menurun.
Berbeda dengan Optimistic Rollups yang tidak dapat selalu mengeksekusi ulang dengan biaya, Polkadot mempertimbangkan eksekusi Sharding saat merancangnya, sehingga sebagian validator dapat mengeksekusi ulang Layer2 Blok sambil memberikan cukup bukti ekonomi kripto kepada semua peserta jaringan untuk membuktikan keaslian Layer2 Blok dan keamanannya ketika seluruh kumpulan validator mengeksekusinya. Hal ini dicapai melalui mekanisme ELVES yang baru-baru ini dirilis. (Lihat rincian di: )
Singkatnya, ELVES dapat dianggap sebagai mekanisme "Rollups" tipe kecurigaan. Dengan beberapa putaran validator secara aktif menanyakan kepada validator lain apakah suatu Blok Layer2 valid, kita dapat dengan sangat besar kemungkinan mengkonfirmasi validitas Blok Layer2 tersebut. Pada kenyataannya, ketika terjadi perselisihan, seluruh kumpulan validator akan segera diminta untuk berpartisipasi. Pendiri bersama Polkadot, Rob Habermeier, menjelaskan hal ini secara rinci dalam sebuah artikel. (Lihat: )
ELVES memungkinkan Polkadot memiliki dua properti yang sebelumnya dianggap saling bertentangan: "Sharding Execution" dan "Shared Security". Ini adalah pencapaian teknologi utama Polkadot1 dalam hal skalabilitas.
Sekarang, mari kita lanjutkan diskusi tentang analogi 'CORE'.
Sebuah Blok yang menjalankan Sharding sangat mirip dengan CPU: seperti inti CPU yang dapat melakukan instruksi secara paralel, Polkadot dapat memproses Layer2 Blok secara paralel. Itulah mengapa Layer2 di Polkadot disebut sebagai parachain, dan lingkungan di mana subset validator yang lebih kecil mengeksekusi kembali satu Blok Layer2 disebut sebagai "core". Setiap core dapat diabstraksikan sebagai "sekelompok validator yang bekerja sama".
Anda dapat membayangkan rantai Blok tunggal sebagai hanya mengambil satu Blok dalam periode waktu yang tidak terbatas, sedangkan Polkadot mengambil satu Blok Rantai Relay dan satu Blok Rantai Paralel inti pada setiap periode waktu.
Heterogenitas
Sampai saat ini, kita hanya membahas skalabilitas dan pelaksanaan Sharding yang ditawarkan oleh Polkadot. Perlu dicatat bahwa setiap Sharding pada Polkadot sebenarnya adalah aplikasi yang benar-benar berbeda. Hal ini dicapai dengan menggunakan protokol elemen yang disimpan dalam bytecode: suatu cara untuk mendefinisikan Blokchain sebagai bytecode yang disimpan dalam status Blokchain itu sendiri. Di Polkadot 1.0, WASM digunakan sebagai bytecode pilihan, sedangkan pada JAM, digunakan PVM/RISC-V.
Secara keseluruhan, inilah mengapa Polkadot disebut sebagai blockchain fragmentasi heterogen. (Lihat: ) Setiap Layer2 adalah aplikasi yang sepenuhnya berbeda.
Polkadot2
Salah satu bagian penting dari Polkadot2 adalah membuat penggunaan inti lebih fleksibel. Dalam model Polkadot asli, masa sewa inti dapat bervariasi dari 6 bulan hingga 2 tahun, cocok untuk perusahaan yang memiliki sumber daya yang cukup, tetapi tidak cocok untuk tim kecil. Fitur yang memungkinkan inti Polkadot digunakan secara lebih fleksibel disebut sebagai "waktu inti yang tangkas" (agile coretime). Dalam mode ini, masa sewa inti Polkadot dapat sependek satu Blok, atau bahkan sampai satu bulan, dan memberikan jaminan harga maksimum bagi pengguna yang ingin menyewa dalam jangka panjang.
Fitur lain dari Polkadot 2 sedang secara bertahap terungkap dalam diskusi kami, sehingga tidak perlu dijelaskan terlalu banyak di sini.
Operasi inti internal dan on-chain
Untuk memahami JAM, pertama-tama perlu memahami apa yang terjadi ketika suatu Blok Layer2 masuk ke inti Polkadot.
Konten berikut telah disederhanakan secara signifikan.
Untuk mengingatnya, intinya terdiri dari sekelompok validator. Jadi, ketika kita mengatakan "data dikirim ke inti", sebenarnya mengacu pada data ini disampaikan ke kelompok validator tersebut.
Sebuah Blok Layer2 ditambah sebagian status Layer2 tersebut dikirim ke inti. Data ini adalah seluruh informasi yang diperlukan untuk mengeksekusi Blok Layer2 tersebut.
Sebagian validator di dalam inti akan menjalankan ulang Blok Layer2 dan melanjutkan pemrosesan tugas yang terkait dengan Konsensus.
Validator inti akan memberikan kembali data yang diperlukan kepada validator lain (validator di luar inti). Validator lainnya mungkin akan memutuskan apakah akan menjalankan ulang Blok Layer2 ini berdasarkan aturan ELVES, dan mereka memerlukan data ini untuk melakukannya.
Perhatikan, sampai saat ini, semua operasi dilakukan di luar blok utama dan fungsi perubahan status dari Polkadot. Semua ini terjadi di dalam inti dan lapisan ketersediaan data.
Dari konten di atas, kita dapat mendiskusikan beberapa operasi yang sedang dilakukan oleh Polkadot:
Pertama, dari Langkah 1, kita dapat menyimpulkan bahwa Polkadot memiliki cara eksekusi baru yang berbeda dari fungsi peralihan status rantai blok tradisional. Biasanya, ketika semua validator dalam jaringan melakukan pekerjaan tertentu, status rantai blok utama akan diperbarui. Kondisi ini disebut sebagai operasi on-chain (on-chain operation), itulah yang terjadi pada Langkah 3. Namun, situasi yang terjadi di dalam inti (Langkah 1) berbeda. Kami menyebut jenis komputasi rantai blok baru ini sebagai eksekusi inti (in-core execution).
Selanjutnya, dari poin kedua kita dapat menyimpulkan bahwa Polkadot telah menyediakan lapisan Data-Availability (DA) yang asli, dan Layer2 secara otomatis menggunakannya untuk memastikan bukti eksekusinya tersedia dalam jangka waktu tertentu. Namun, blok data yang dapat dipublikasikan ke lapisan DA ini tetaplah tetap, selalu menjadi bukti yang diperlukan untuk menjalankan Layer2. Selain itu, kode parachain tidak pernah membaca data lapisan DA ini.
Memahami konten di atas adalah dasar pemahaman JAM. Ringkasannya adalah sebagai berikut:
JAM
Dengan pemahaman dari bagian sebelumnya, kita dapat beralih dengan lancar ke pengenalan JAM.
JAM adalah protokol baru yang terinspirasi oleh Polkadot dan sepenuhnya kompatibel dengannya, dengan tujuan menggantikan relay chain Polkadot dan membuat penggunaan inti menjadi sepenuhnya terdesentralisasi dan tanpa batasan.
JAM dibangun di atas Polkadot2 dengan upaya untuk membuat inti Polkadot lebih mudah diakses, tetapi dengan pendekatan yang lebih fleksibel dan tanpa batasan tetap seperti agile-coretime.
Ini dicapai terutama dengan mengungkapkan tiga konsep utama yang dibahas sebelumnya kepada pengembang: yaitu eksekusi on-chain, eksekusi inti, dan lapisan DA.
Dengan kata lain, di JAM, pengembang dapat mengakses:
Ini adalah deskripsi dasar untuk tujuan JAM. Tidak perlu banyak kata, di sini telah dilakukan banyak penyederhanaan, dan protokol mungkin masih akan berubah.
Dengan pemahaman dasar ini, sekarang kita dapat lebih lanjut membahas beberapa detail JAM di bab-bab berikutnya.
1 Layanan dan Item Kerja
Dalam konteks JAM, yang sebelumnya dikenal sebagai Layer2/parachain sekarang dikenal sebagai "Layanan", sedangkan yang sebelumnya dikenal sebagai Blok/transaksi sekarang dikenal sebagai "Item Kerja" atau "Paket Kerja". Secara khusus, Item Kerja terkait dengan layanan tertentu, sedangkan Paket Kerja merupakan kumpulan dari Item Kerja. Istilah-istilah ini dirancang dengan sengaja untuk cukup umum, sehingga mencakup berbagai kasus penggunaan di luar Blok/Layer2.
Sebuah layanan dideskripsikan oleh tiga titik masuk, di antaranya dua di antaranya adalah fn refine() dan fn accumulate(). Yang pertama menggambarkan konten yang dieksekusi di dalam inti layanan, sementara yang terakhir menggambarkan konten yang dieksekusi on-chain.
Terakhir, nama kedua titik masuk juga menjadi alasan protokol disebut JAM (Join Accumulate Machine). Join merujuk pada fn refine(), ketika semua inti Polkadot menangani sejumlah besar pekerjaan layanan yang berbeda secara paralel, tahap ini disebut Join. Data disaring sebelum masuk ke tahap berikutnya. Accumulate merujuk pada proses semua hasil di atas akumulasi ke status JAM utama, yaitu bagian on-chain execution.
Item kerja dapat secara tepat menentukan apa yang akan dieksekusi di dalam inti, on-chain, dan menunjukkan bagaimana/cara/ dari mana membaca/menulis konten dari Distributed Data Lake.
2 Konsistensi Setengah
Melihat kembali informasi yang ada tentang XCM (bahasa komunikasi parachain yang dipilih oleh Polkadot), semua komunikasi yang ada bersifat asinkron. Artinya, setelah pesan dikirimkan, tidak mungkin menunggu balasannya.
Asinkronitas adalah manifestasi ketidaksesuaian sistem dan merupakan kekurangan utama sistem Sharding yang permanen (seperti Polkadot 1 dan Polkadot 2 serta ekosistem Layer2 yang ada pada Ethereum).
Namun, seperti yang dijelaskan dalam Bagian 2.4 buku putih, sistem yang sepenuhnya konsisten yang selalu menjaga semua penyewanya tetap selaras hanya dapat naik ke tingkat tertentu tanpa mengorbankan universalitas, aksesibilitas, atau elastisitas. (Lihat: )
Sinkronisasi ≈ Konsistensi || Asinkronisasi ≈ Inkonsistensi
Ini juga merupakan domain lain di mana JAM unggul: dengan memperkenalkan berbagai fitur, JAM mencapai jenis keadaan tengah yang baru, yaitu sistem konsistensi paruh. Dalam sistem ini, subsistem yang berkomunikasi secara intens memiliki kesempatan untuk menciptakan lingkungan yang konsisten di antara satu sama lain tanpa memaksa seluruh sistem tetap konsisten. Ini adalah deskripsi terbaik yang diberikan oleh Dr. Gavin Wood, penulis buku abu-abu, dalam wawancaranya. (Lihat: _referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ)
Cara lain untuk memahami Polkadot/JAM adalah dengan menganggapnya sebagai sistem Sharding di mana batas-batas Sharding tersebut bersifat fluid dan ditentukan secara dinamis.
Polkadot selalu melakukan Sharding, dan benar-benar heterogen.
Sekarang, itu akan menjadi Sharding, heterogen, dan batas-batas Sharding ini dapat ditentukan secara fleksibel, seperti yang disebutkan oleh Gavin Wood dalam sistem 'semi-konsisten' di Twitter (lihat: _src=twsrc%5Etfw).
Fitur-fitur yang membuat semua ini menjadi mungkin termasuk:
Mengakses eksekusi internal inti yang stateless dan paralel, di mana layanan yang berbeda hanya dapat berinteraksi secara sinkron dengan layanan lain dalam inti yang sama dan dalam Blok khusus, serta eksekusi on-chain, di mana layanan dapat mengakses hasil dari semua layanan di semua inti.
JAM tidak menerapkan penjadwalan layanan yang khusus. Layanan yang berkomunikasi secara sering dapat memberikan insentif ekonomi kepada penjadwal mereka, menciptakan paket kerja yang berisi layanan yang berkomunikasi secara sering ini. Hal ini memungkinkan layanan-layanan ini berjalan di dalam inti yang sama, sehingga komunikasi antar layanan tersebut berjalan seperti dalam lingkungan yang sinkron.
Selain itu, layanan JAM dapat mengakses Data Layer, dan dapat menggunakannya sebagai Data Layer sementara namun sangat murah. Begitu data ditempatkan di DA, itu akhirnya akan menyebar ke semua inti, tetapi akan segera tersedia di inti yang sama. Oleh karena itu, layanan JAM dapat meningkatkan akses data dengan menjadwalkan dirinya sendiri ke inti yang sama dalam Blok yang berurutan.
Perlu diperhatikan bahwa meskipun konten di atas memungkinkan di JAM, namun tidak diterapkan secara paksa di layer protokol. Oleh karena itu, beberapa antarmuka diperkirakan secara teori adalah asinkron, tetapi melalui abstraksi yang cerdas dan insentif, dapat terlihat sinkron dalam praktiknya. Bagian selanjutnya akan membahas CorePlay sebagai contoh ini.
3 CorePlay
Bagian ini mengenalkan CorePlay, yang merupakan ide eksperimental dalam lingkungan JAM yang dapat dijelaskan sebagai model pemrograman Smart Contract baru. Pada saat penulisan artikel ini, CorePlay belum dijelaskan secara rinci dan masih dalam tahap konsepsi.
Untuk memahami CorePlay, pertama-tama kita perlu memperkenalkan Virtual Machine yang dipilih oleh JAM: PVM.
4 PVM
PVM adalah salah satu detail penting dalam JAM dan CorePlay. Detail-detail tingkat rendah dari PVM berada di luar lingkup artikel ini, sebaiknya lihat deskripsi ahli domain dalam whitepaper. Namun, untuk keperluan artikel ini, kita hanya perlu menjelaskan beberapa atribut PVM:
Yang terakhir sangat penting bagi CorePlay.
CorePlay adalah contoh lingkungan Smart Contract yang synchronous dan scalable yang dibuat menggunakan bahasa pemrograman JAM, dengan antarmuka pemrograman yang sangat fleksibel. CorePlay menyarankan untuk langsung mendeploy Smart Contract berbasis Actor pada inti JAM, sehingga mereka dapat menikmati antarmuka pemrograman synchronous di mana mereka dapat ditulis seperti fn main() biasa, dan berkomunikasi melalui let_result=other_coreplay_actor(data).await? Jika other_coreplay_actor berada pada inti yang sama di Blok JAM, panggilan ini adalah synchronous; jika berada di inti lain, Actor tersebut akan dijeda dan dipulihkan di Blok JAM berikutnya. Hal ini menjadi mungkin karena layanan JAM dan penjadwalan yang fleksibel, serta atribut PVM.
Layanan 5 CoreChains
Terakhir, mari kita rangkum mengapa JAM sepenuhnya kompatibel dengan Polkadot. Produk utama Polkadot berjalan dengan cara waktu inti yang responsif (Agile Core Time) adalah parachain, dan produk ini berlanjut di JAM.
Dalam JAM, layanan yang diterapkan lebih awal kemungkinan akan disebut sebagai CoreChains atau Parachains. Layanan ini akan memungkinkan parachains bergaya Polkadot yang ada beroperasi di JAM.
Layanan yang lebih lanjut dapat diterapkan di JAM dan layanan CoreChains yang ada dapat berkomunikasi dengan mereka, tetapi produk Polkadot yang ada akan tetap kuat dan hanya akan membuka pintu baru bagi tim Parachain yang ada.
Lampiran: Sharding Data
Sebagian besar konten artikel ini membahas skalabilitas dari sudut pandang Sharding. Kita juga bisa melihat masalah yang sama dari sudut pandang data. Menariknya, kami menemukan bahwa ini mirip dengan kasus semi-konsistensi yang disebutkan sebelumnya: secara prinsip, sistem yang sepenuhnya konsisten lebih baik, tetapi tidak dapat diskalakan; sistem yang tidak konsisten sama sekali dapat diskalakan, tetapi tidak ideal, sedangkan JAM dengan model semi-konsistensinya mengusulkan kemungkinan baru.
Sistem yang Sepenuhnya Konsisten: Ini adalah yang kita lihat di platform Smart Contract yang sepenuhnya disinkronkan, seperti Solana atau platform yang berani hanya dideploy di Layer1 Ethereum. Semua data aplikasi disimpan on-chain, dan dapat dengan mudah diakses oleh semua aplikasi lainnya. Ini adalah atribut yang sempurna secara programatik, tetapi tidak dapat diperluas.
Sistem yang Tidak Konsisten: Data aplikasi disimpan di luar Layer1, serta dalam Sharding yang berbeda dan terisolasi. Sangat skalabel, tetapi kinerjanya kurang baik dalam hal komposabilitas. Model Rollup Polkadot dan Ethereum termasuk dalam situasi ini.
Selain menyediakan dua fungsi di atas, JAM juga memungkinkan pengembang untuk mempublikasikan data apa pun ke lapisan JAM DA, yang merupakan area tengah antara data on-chain dan off-chain. Anda dapat mengembangkan aplikasi baru yang menggunakan sebagian besar data aplikasi pada lapisan DA, sambil hanya mengubah data yang sangat penting menjadi status JAM yang persisten.
Lampiran: Peta Ruang Skalabilitas
Bagian ini menjelaskan ulang pandangan kami tentang skalabilitas dalam domain blockchain. Ini juga dijelaskan dalam buku putih dan versi yang lebih ringkas disediakan di sini.
Skalabilitas blockchain dalam banyak hal mengikuti metode yang digunakan dalam sistem terdistribusi tradisional: skalabilitas vertikal dan horizontal.
Ekspansi ke atas adalah pekerjaan yang dilakukan oleh platform seperti Solana. Melalui optimalisasi kode dan perangkat keras hingga batas maksimum untuk mencapai throughput maksimum.
Ekspansi eksternal adalah strategi yang diadopsi oleh Ethereum dan Polkadot: mengurangi jumlah pekerjaan yang perlu dilakukan oleh setiap orang. Dalam sistem terdistribusi tradisional, ini dicapai dengan menambahkan lebih banyak mesin pengganda. Di Blok, 'komputer' adalah kumpulan validator seluruh jaringan. Dengan membagi pekerjaan di antara mereka (seperti yang dilakukan oleh ELVES), atau dengan optimis mengurangi tanggung jawab mereka (seperti yang dilakukan oleh Rollups optimis), kami mengurangi beban kerja keseluruhan kumpulan validator, sehingga mencapai ekspansi sistem secara eksternal.
Dalam Blok rantai, memperluas keluar mirip dengan "mengurangi jumlah mesin yang perlu menjalankan semua operasi".
Ringkasan sebagai berikut:
Lampiran: Perangkat Keras yang Sama, Pembaruan Kernel
Bagian ini didasarkan pada analogi yang diberikan oleh Rob Habermeier di Sub02023: Polkadot: Kernel/Userland|Sub02023-YouTube (lihat lebih lanjut di:), yang menggambarkan JAM sebagai peningkatan untuk Polkadot: pembaruan kernel pada perangkat keras yang sama.
Dalam komputer tipikal, kita dapat membagi seluruh tumpukan menjadi tiga bagian:
Hardware
Kernel
ruang pengguna
Di Polkadot, perangkat keras, yang merupakan sifat inti yang menyediakan ketersediaan komputasi dan data, telah menjadi inti, seperti yang telah dijelaskan sebelumnya.
Di dalam Polkadot, inti sebenarnya[9]Sampai saat ini telah mencakup dua bagian:
parachain（Parachains）protokol: cara penggunaan inti yang terstandarisasi dan terfiksasi untuk opini.
Sejumlah fungsi dasar, seperti Token DOT dan transferabilitasnya, stake, governance, dan lain-lain.
Keduanya ada dalam relay chain (Relay Chain) Polkadot.
Aplikasi ruang pengguna adalah contoh parachains, Token asli mereka, dan konten lain yang dibangun di atasnya.
Kita dapat memvisualisasikan proses ini sebagai berikut:
Polkadot selalu bermimpi untuk memindahkan lebih banyak fitur inti ke pengguna kelas satu mereka - parachain. Inilah tujuan yang ingin dicapai oleh Minimal Relay RFC. (Lihat: )
Ini berarti bahwa relay chain Polkadot hanya memproses parachainprotokol yang disediakan, yang pada beberapa tingkat memperkecil ruang inti.
Setelah arsitektur ini tercapai, akan lebih mudah untuk memvisualisasikan migrasi JAM. JAM akan memperkecil ruang inti Polkadot, membuatnya lebih umum. Selain itu, protokol Parachains akan dipindahkan ke ruang penggunaan karena ini adalah salah satu cara yang sedikit untuk menulis aplikasi pada inti (perangkat keras) dan inti (JAM) yang sama.
Ini juga sekali lagi menjelaskan mengapa JAM hanyalah pengganti relay chain Polkadot, bukan pengganti parachain.
Dengan kata lain, kita dapat menganggap migrasi JAM sebagai peningkatan kernel. Perangkat keras dasar tetap sama, sebagian besar konten kernel lama dipindahkan ke ruang pengguna untuk menyederhanakan sistem.
Ingin berpartisipasi dalam diskusi artikel ini, silakan posting pendapat Anda di forum:
Untuk panduan tentang bagaimana berpartisipasi dalam diskusi di forum, silakan lihat Panduan Penggunaan Forum Polkadot yang kami rilis:
"Panduan Penggunaan Forum Resmi Polkadot: Bagaimana Cara Berpartisipasi dalam Diskusi Polkadot"