Polkadot JAM: Evolusi Skala dan Penggunaan Core

1. Latar Belakang Di bahagian ini, konsep berikut akan digunakan, dan kami mengandaikan anda memahaminya.

• Rantaian blok sebagai Fungsi Peralihan Keadaan (State Transition Function)
• Pemahaman mengenai "Keadaan" (State) Kedua-dua konsep ini dijelaskan di sini.
• Keselamatan Ekonomi (Economic Security) dan Bukti Pegangan (Proof of Stake) Kandungan ini dijelaskan dalam kuliah PBA dan video.

2. Pendahuluan: Polkadot 1.0 Pertama, mari kita ringkaskan ciri paling inovatif Polkadot 1.0 seperti berikut.

Aspek Sosial: Polkadot boleh dilihat sebagai satu DAO besar dari segi semua aspek. Tadbir urus rangkaian, termasuk kemas kini masa jalan tanpa fork (fork-less runtime upgrade), berjalan sepenuhnya di atas rantaian secara autonomi. Suruhanjaya Sekuriti dan Bursa A.S. (SEC) menganggap DOT sebagai perisian, bukan sekuriti. Kebanyakan pembangunan rangkaian diuruskan oleh Polkadot Fellowship, bukan syarikat perakaunan (contohnya Parity).

Aspek Teknikal:

• Perkongsian keselamatan dan pelaksanaan yang dicincang (sharded execution) iaitu teknik membahagikan data rangkaian rantaian blok kepada "serpihan" (shard) untuk diproses.
• Menggunakan meta-protokol berasaskan WASM. Dengan menyimpan kod rantaian blok dalam bentuk baitkod dalam keadaan, kebanyakan kemas kini boleh dijalankan tanpa fork. Ini membolehkan bukan sahaja penshardingan di Polkadot, tetapi juga penshardingan heterogen. Untuk perincian lanjut, sila rujuk Heterogeneity. Sekarang, mari kita lihat pelaksanaan yang dicincang dengan lebih terperinci.

3. Teras Pelaksanaan yang Dicincang: Core Dalam artikel ini, kita membincangkan rangkaian L1 yang menganjurkan L2 "rantaian blok" yang berbeza seperti Polkadot atau Ethereum. Oleh itu, L2 dan Parachain akan dianggap sebagai sinonim.

Masalah utma penskalaan rantaian blok boleh diringkaskan seperti berikut. Terdapat sekumpulan pengesah (validators), dan kod yang mereka jalankan dijamin kepercayaannya melalui konsep kripto-ekonomi yang dikenali sebagai Bukti Pegangan. Pengesah pada dasarnya perlu melaksanakan semula keseluruhan kerja antara satu sama lain. Dalam erti kata lain, sistem ini tidak dapat diskalakan selama ia memaksa semua pengesah untuk sentiasa melaksanakan semula segala-galanya. Perlu diingat bahawa selagi prinsip pelaksanaan semula yang disebutkan dalam perenggan sebelum ini dikekalkan, penambahan bilangan pengesah dalam model ini tidak akan meningkatkan keupayaan pemprosesan sistem.

Penerangan di atas menerangkan ciri-ciri rantaian blok monolitik yang bertentangan dengan penshardingan. Input (contohnya: blok) diproses satu demi satu oleh semua pengesah rangkaian. Jika sistem seperti ini mahu menganjurkan lebih banyak L2 di L1, semua pengesah mesti melaksanakan semula kerja semua L2. Sudah tentu, penskalaan tidak boleh diharapkan dalam sistem sedemikian. Satu cara untuk memintas masalah ini adalah melalui Optimistic Rollup, iaitu memastikan pelaksanaan semula (atau bukti penipuan, fraud proof) hanya berlaku apabila seseorang mendakwa berlaku penipuan. Rollup berasaskan SNARK membolehkan semua pengesah mengesahkan bukti SNARK berdasarkan fakta bahawa kos pengesahan adalah jauh lebih murah berbanding menjana bukti SNARK. Untuk maklumat lanjut, sila rujuk Peta Ruang Penskalaan (Scalability Space Map) dalam lampiran.

Penyelesaian mudah untuk penshardingan adalah dengan membahagikan sekumpulan pengesah kepada subset yang lebih kecil, dan subset kecil ini melaksanakan semula blok L2. Apakah masalah pendekatan ini? Iaitu kita sedang mencincangkan pelaksanaan dan keselamatan ekonomi rangkaian. Keselamatan L2 sudah lemah berbanding L1, dan semakin banyak kita menghancurkan kumpulan pengesah kepada shard yang lebih banyak, keselamatan pasti akan semakin lemah.

Berbeza dengan Optimistic Rollup yang tidak dapat melaksanakan semula transaksi pada setiap masa, Polkadot direka untuk mencincangkan transaksi. Ini membolehkan subset pengesah melaksanakan semula blok L2, sambil menyediakan bukti kripto-ekonomi kepada semua peserta rangkaian bahawa kesahihan blok L2 adalah selamat seolah-olah seluruh kumpulan pengesah telah melaksanakan semula blok tersebut. Ini dimungkinkan melalui mekanisme ELVES yang diumumkan baru-baru ini. ELVES juga boleh dilihat sebagai mekanisme "Cynical Rollup". Pengesah mengulangi proses mendapatkan pengesahan kesahihan blok L2 daripada pengesah lain beberapa kali, dan ini mengesahkan kemungkinan tinggi blok L2 itu sah. Jika berlaku pertikaian, keseluruhan kumpulan pengesah akan diminta untuk menyertai dalam masa singkat, perkara ini dijelaskan dengan baik oleh Rob Habermeier, salah seorang pengasas bersama Polkadot.

Fakta bahawa Polkadot boleh mempunyai kedua-dua ciri "pelaksanaan yang dicincang" dan "keselamatan perkongsian", yang biasanya dianggap saling eksklusif, adalah berkat mekanisme ELVES, dan ini juga merupakan pencapaian teknikal utama Polkadot 1.0 dalam penskalaan.

Sekarang, mari kita beralih kepada perbandingan "teras". Rantaian blok dengan pelaksanaan-cincang (execution-sharded) boleh dianalogikan dengan CPU. Sama seperti CPU mempunyai banyak teras yang boleh memproses arahan secara selari, Polkadot juga boleh memproses blok L2 secara selari. Atas sebab ini, di Polkadot, L2 dipanggil parachain[1], dan persekitaran di mana subset pengesah melaksanakan satu blok L2 dipanggil "teras". Teras individu boleh diringkaskan sebagai "kumpulan pengesah yang bekerjasama". Jika rantaian blok monolitik hanya boleh memproses satu blok pada mana-mana slot masa, Polkadot boleh memproses satu blok rantaian geganti (relay chain) dan satu blok parachain bagi setiap teras dan slot masa.

3.1. Heterogeneity

Setakat ini kita hanya bercakap tentang penskalaan dan pelaksanaan yang dicincang di Polkadot, tetapi satu fakta penting ialah setiap shard di Polkadot adalah aplikasi yang berasingan sepenuhnya[2]. Ini dilaksanakan dengan menggunakan meta-protokol yang disimpan sebagai baitkod, di mana meta-protokol bermaksud protokol di mana definisi rantaian blok disimpan dalam keadaan rantaian blok dalam bentuk baitkod. Dalam Polkadot 1.0, WASM digunakan sebagai baitkod, dan dalam JAM, PVM/RISC-V telah diadopsi. Kesimpulannya, inilah sebabnya Polkadot dipanggil rantaian blok yang dicincang secara heterogen (heterogeneous sharded blockchain). Setiap L2 boleh dikatakan sebagai aplikasi yang berasingan dan sepenuhnya berbeza antara satu sama lain.

4. Polkadot 2.0 Polkadot 2.0 menekankan untuk menjadikan penggunaan teras lebih fleksibel. Dalam model Polkadot sedia ada, satu teras boleh disewa selama 6 bulan hingga maksimum 2 tahun pada satu masa. Ini adalah model yang sesuai untuk perniagaan dengan sumber yang banyak, tetapi tidak untuk pasukan kecil. Fungsi yang menjadikan penggunaan teras Polkadot lebih fleksible dipanggil "masa teras lincah" (agile coretime), di mana teras Polkadot boleh disewa dari satu blok hingga maksimum sebulan pada satu masa, dan jika anda ingin menyewa jangka panjang, had harga (price cap) juga dijamin. Pada masa ini, Polkadot 2.0 sedang berjalan bersama fungsi-fungsi lain, jadi kita akan meninggalkan penerangan lanjut di sini.

5. Dalam Teras vs. Rantaian (On-chain) Untuk memahami JAM (Polkadot 3.0), anda perlu memahami apa yang berlaku di teras Polkadot apabila blok L2 memasukinya. Berikut adalah kandungan yang sangat dipermudahkan.

Teras pada asasnya terdiri daripada sekumpulan pengesah. "Menghantar data ke teras" bermaksud data tersebut telah diserahkan kepada kumpulan pengesah.

0. Satu blok L2 dan subset keadaan L2 yang berkaitan dihantar ke teras. Ini adalah satu-satunya data yang diperlukan untuk memproses blok L2[3].
1. Subset pengesah yang membentuk teras melaksanakan semula blok L2 dan menjalankan tugas berkaitan konsensus.
2. Pengesah teras membolehkan pengesah lain (di luar teras) menggunakan data yang diperlukan untuk melaksanakan semula. Mengikut peraturan ELVES, lebih banyak pengesah mungkin mahu melaksanakan semula blok L2, dan data ini diperlukan ketika itu. Ingat bahawa semua kerja ini berlaku di luar fungsi peralihan keadaan dan blok utama Polkadot.

Semua proses yang dijelaskan setakat ini berlaku di dalam teras dan lapisan ketersediaan data.

3. Keadaan terkini yang dihantar oleh L2 disimpan dalam keadaan rantaian geganti Polkadot. Tugas ini jauh lebih murah daripada melaksanakan semula blok L2, memberi kesan kepada keadaan Polkadot utama, direkodkan dalam blok Polkadot, dan diproses oleh semua pengesah Polkadot.

Sebagai tambahan kepada penerangan di atas, mari kita lihat lebih lanjut tentang kerja yang dilakukan oleh Polkadot:

Di poin 1, kita melihat bahawa Polkadot mempunyai kaedah pemprosesan yang berbeza daripada fungsi peralihan keadaan rantaian blok biasa. Biasanya, apabila semua pengesah rangkaian melaksanakan kerja, keadaan rantaian blok utama dikemaskini sebagai hasilnya, dan ini dipanggil operasi rantaian (on-chain operation). Ini adalah tugas yang berkaitan dengan poin 3. Namun, apa yang berlaku di dalam teras (poin 1) adalah berbeza. Kaedah pengiraan rantaian blok baru ini dipanggil pemprosesan dalam teras (in-core execution).

Dari poin 2, kita boleh menunjukkan bahawa Polkadot sudah menyediakan lapisan ketersediaan data (DA) asli, dan L2 secara automatik menggunakannya untuk jangka masa tertentu sebagai bukti pemprosesan. Dan data yang boleh naik ke lapisan DA ini[4] adalah tetap, dan data ini adalah bukti yang sentiasa diperlukan untuk melaksanakan semula blok L2. Selain itu, kod parachain tidak boleh membaca data dari lapisan DA. Kandungan di atas menjadi asas untuk memahami fungsi JAM. Ringkasannya adalah seperti berikut.

• Pemprosesan Dalam Teras (In-core execution): Berlaku di dalam teras. Mempunyai kelimpahan sumber dan kebolehskalaan, dan mempunyai keselamatan setara dengan "pemprosesan rantaian" berdasarkan kripto-ekonomi dan ELVES.
• Pemprosesan Rantaian (On-chain execution): Ini adalah kerja pengesah. Keselamatan disimpan oleh pengesah yang mempunyai insentif ekonomi, dan lebih mahal dan terhad kerana semua orang memproses segala-galanya.
• Ketersediaan Data: Pengesah Polkadot menyediakan data yang boleh digunakan untuk tempoh tertentu kepada pengesah lain.

6. JAM (Polkadot 3.0) Jika anda memahami kandungan yang dijelaskan sebelum ini, konsep JAM akan lebih mudah difahami. JAM sangat dipengaruhi oleh Polkadot, sepenuhnya serasi dengan Polkadot, dan merupakan protokol baru yang bertujuan untuk menggantikan rantaian geganti Polkadot dan menjadikan penggunaan teras secara asasnya tidak berat sebelah (un-opinionated[5]). JAM adalah berdasarkan Polkadot 2.0. Ia bertujuan untuk meningkatkan kebolehgunaan teras Polkadot dengan cara yang lebih fleksibel dan tidak berat sebelah secara asasnya berbanding masa teras lincah. Dalam Polkadot 2.0, penempatan teras L2 adalah lebih cair.

Teras JAM adalah bahawa sebarang aplikasi yang tidak terhad kepada format rantaian blok/L2 boleh digunakan pada teras Polkadot. Ini mungkin terutamanya kerana ia menyediakan tiga elemen yang dijelaskan dalam bahagian sebelumnya kepada pembangun, iaitu pemprosesan dalam teras dan rantaian, serta ketersediaan data. Dalam erti kata lain, JAM menyediakan fungsi berikut kepada pembangun.

• Boleh memprogramkan kerja yang dilakukan dalam teras dan rantaian.
• Boleh membaca dan memasukkan data sebarangan di lapisan DA Polkadot.

Setakat ini kita telah melihat kandungan asas arah yang ditempuh oleh JAM. Sudah tentu banyak perkara yang dipermudahkan, dan protokol sedang berkembang. Berdasarkan penerangan setakat ini, mari kita lihat kandungan JAM dengan lebih terperinci.

6.1. Perkhidmatan dan Item Kerja

Dalam sistem JAM, apa yang dahulunya dipanggil L2/Parachain kini dipanggil Perkhidmatan (Service), dan blok/transaksi dipanggil Item Kerja (Work-Item) atau Pakej Kerja (Work-Package). Sebagai tambahan, item kerja milik perkhidmatan, dan pakej kerja merujuk kepada kumpulan item kerja. Kedua-dua istilah ini dipilih sebagai istilah umum untuk merangkumi kes penggunaan yang tidak terhad kepada rantaian blok/L2.

Perkhidmatan boleh dijelaskan oleh tiga titik masuk, di mana dua daripadanya adalah fn refine() dan fn accumulate()[6]. Yang pertama menerangkan apa yang dilakukan oleh perkhidmatan dalam teras, dan yang kedua menerangkan apa yang dilakukan oleh perkhidmatan di rantaian. Akhirnya, nama kedua-dua titik masuk berkaitan dengan nama protokol JAM (Join Accumulate Machine). Join merujuk kepada fn refine(), di mana semua teras Polkadot menjalankan banyak kerja untuk pelbagai perkhidmatan secara selari. Dalam Join, data ditapis menjadi subset yang lebih kecil dan diserahkan ke peringkat seterusnya. Accumulate adalah keputusan proses sebelum ini dikumpulkan ke dalam keadaan JAM utama, yang sepadan dengan pelaksanaan rantaian.

💡Item kerja boleh menentukan secara khusus kod mana yang akan dilaksanakan dalam teras dan rantaian, serta cara, kandungan, dan sama ada untuk membaca dan menulis data dari Tasik Data Teragih (Distributed Data Lake).

6.2. Kuasi-Konsisten

Menurut bahan sedia ada mengenai XCM, iaitu bahasa komunikasi antara parachain Polkadot, semua komunikasi adalah tidak segerak (asynchronous).

Dengan kata lain, mesej dihantar tanpa menunggu respons. Asinkroni (Asynchrony) adalah ciri sistem yang tidak koheren (incoherent), dan merupakan masalah utama bagi sistem yang melaksanakan sharding secara kekal seperti Polkadot 1.0, Polkadot 2.0, dan kumpulan L2 sedia ada Ethereum. Walau bagaimanapun, seperti yang dijelaskan dalam bahagian 2.4 Gray Paper, sistem yang sentiasa serentak (synchronous) dan sepenuhnya koheren untuk semua peserta sukar untuk berkembang tanpa mengorbankan keumuman (generality), aksesibiliti (accessibility), dan daya tahan (resilience).

ℹ️ Synchronous (Serentak) ~ Coherent (Koheren) || Asynchronous (Asinkron) ~ Incoherent (Tidak Koheren)

Di sinilah kelebihan JAM menonjol lagi. JAM memperkenalkan pelbagai ciri (property) untuk mencapai titik keseimbangan baharu yang dikenali sebagai sistem semi-koheren. Ini bermaksud, pelbagai subsistem yang sering berkomunikasi diberi peluang untuk mencipta persekitaran yang koheren, tetapi ini tidak dipaksa ke atas seluruh sistem. Perkara ini dijelaskan secara terperinci dalam temubual bersama Dr. Gavin Wood, penulis Gray Paper.

Perspektif lain adalah melihat Polkadot, dan JAM, sebagai sistem sharding di mana sempadan antara shard adalah cecair dan ditentukan pada setiap masa. Polkadot sentiasa merupakan rantaian blok yang disatukan secara kekal (sharded) dan sepenuhnya heterogen. Kini, sebagai tambahan kepada sharding dan heterogenitas, ia akan menjadi rantaian blok di mana sempadan sharding ditentukan secara cecair, seperti yang digelar oleh @gavofyork sebagai sistem semi-koheren di

— Kian Paimani (@kianenigma) May 15, 2024

Ciri-ciri yang membolehkan ini adalah seperti berikut: pelaksanaan dalam teras selari (parallel in-core execution) yang tanpa keadaan (state-less) di mana hanya perkhidmatan pada teras yang sama dalam blok tertentu boleh berinteraksi secara serentak, serta akses kepada pelaksanaan on-chain yang membolehkan satu perkhidmatan mengakses keputusan semua perkhidmatan yang wujud merentasi keseluruhan teras.

JAM tidak memaksa penjadualan perkhidmatan tertentu. Perkhidmatan yang kerap berkomunikasi boleh memberikan insentif ekonomi kepada penyusun (sequencers) untuk menghasilkan pakej kerja yang mengandungi item kerja perkhidmatan yang kerap berkomunikasi. Mereka boleh berkomunikasi seolah-olah mereka berada dalam persekitaran serentak sementara wujud pada teras yang sama.

Perkhidmatan JAM boleh mengakses lapisan DA, dan juga boleh menggunakannya sebagai lapisan data yang sangat murah tetapi sementara. Setelah data dihantar ke DA, ia disebarkan dengan serta-merta ke semua teras dan boleh digunakan dengan segera pada teras yang sama. Akibatnya, perkhidmatan JAM boleh menikmati aksesibiliti data yang tinggi melalui penjadualan kendiri mereka pada teras yang sama dalam blok berturut-turut [7].

Perlu diingat bahawa perkara di atas adalah fungsi yang mungkin dalam JAM, tetapi tidak dipaksa pada lapisan protokol. Sesetengah antara muka secara teorinya adalah asinkron, tetapi dalam praktikalnya ia mungkin boleh beroperasi secara serentak melalui abstraksi dan insentif yang halus. Contoh yang menunjukkan ini adalah CorePlay yang akan dijelaskan dalam bahagian seterusnya.

6. 3. CorePlay

Bahagian ini menerangkan idea eksperimen JAM iaitu CorePlay. CorePlay adalah model baharu untuk pengaturcaraan kontrak pintar, yang pada masa penulisan ini belum ditakrifkan dengan jelas [8] dan masih berada pada peringkat idea. Untuk memahami CorePlay, kita perlu terlebih dahulu melihat mesin maya JAM, iaitu PVM.

6. 3. 1. PVM

PVM adalah elemen penting bagi JAM dan CorePlay. Penerangan teknikal yang terperinci tentang PVM telah dijelaskan dengan baik dalam Gray Paper yang ditulis oleh pakar bidang tersebut, jadi di sini kita hanya akan menerangkan beberapa ciri PVM:

• Pengukuran penggunaan sumber yang cekap
• Keupayaan untuk menghentikan dan menyambung semula pelaksanaan

Yang terakhir ini adalah penting untuk CorePlay. CorePlay adalah kes penggunaan primitif cecair JAM untuk mencipta persekitaran kontrak pintar yang boleh dikembangkan dengan antara muka pengaturcaraan. CorePlay mencadangkan kaedah untuk membolehkan antara muka pengaturcaraan yang serentak dengan menyebarkan kontrak pintar berdasarkan pelaku (actor-based) terus ke teras JAM.

Kod dengan fn main() biasa, dan berkomunikasi menggunakan let _result = other_coreplay_actor(data). await?. Jika other_coreplay_actor berada pada teras yang sama dalam blok JAM tersebut, panggilan ini adalah serentak; jika berada pada teras lain, pelaku akan digantung dan disambung semula pada blok JAM seterusnya. Ini adalah mungkin kerana perkhidmatan JAM, penjadualan yang fleksibel, dan ciri-ciri PVM.

6. 4. Perkhidmatan CoreChain

Akhirnya, saya akan menutup artikel ini dengan mengulangi sebab mengapa JAM disebut sebagai serasi sepenuhnya dengan Polkadot. Produk utama Polkadot, iaitu paracain gaya Masa Teras Agile (Agile Coretime), akan kekal dalam JAM. Perkhidmatan pertama yang akan digunakan dalam JAM adalah apa yang disebut sebagai CoreChain atau paracain. Ia adalah perkhidmatan yang membolehkan paracain gaya Polkadot 2.0 berjalan dalam JAM.

Lebih banyak perkhidmatan boleh digunakan dalam JAM, dan perkhidmatan CoreChain sedia ada juga boleh berkomunikasi dengan mereka, tetapi fungsi yang pernah disediakan oleh Polkadot masih akan dianggap penting, dan peluang baharu akan terbuka kepada pasukan paracain sedia ada.

Lampiran: Sharding Data

Walaupun majoriti artikel ini membincangkan kebolehskalaan dari perspektif pelaksanaan sharding, perbincangan juga boleh dilakukan dari perspektif data. Menariknya, kita akan berhadapan dengan situasi yang serupa dengan yang disebut dalam semi-koheren. Sistem yang sepenuhnya koheren mungkin lebih baik secara prinsip, tetapi sukar untuk dikembangkan. Sistem yang sepenuhnya tidak koheren boleh dikembangkan, tetapi tidak ideal.

JAM, yang mengamalkan semi-koheren, menawarkan kemungkinan baharu.

• Sistem Sepenuhnya Koheren: Dilihat pada platform kontrak pintar yang sepenuhnya serentak seperti Solana, atau platform berani yang hanya menggunakan L1 Ethereum. Semua data aplikasi disimpan pada rantaian dan mudah diakses oleh semua aplikasi lain. Ia ciri sempurna untuk kebolehaturcaraan, tetapi tiada kebolehskalaan.
• Sistem Tidak Koheren: Data aplikasi disimpan dalam shard berasingan di luar L1. Ia sangat boleh dikembangkan, tetapi lemah dari segi komposabilitas (composability). Model Polkadot dan Ethereum rollup termasuk dalam kategori ini.

JAM menyediakan kedua-duanya sekaligus, membolehkan pengaturcara menyiarkan data arbitrari pada lapisan DA JAM yang boleh dilihat sebagai zon tengah antara data on-chain dan off-chain. Ini membolehkan pembinaan jenis aplikasi yang baharu sepenuhnya dengan menggunakan kebanyakan data aplikasi pada lapisan DA, dan hanya memasukkan maklumat yang sangat penting dalam keadaan JAM.

Lampiran: Scalability Space Map

Bahagian ini menerangkan semula pandangan mengenai kebolehskalaan rantaian blok. Ia versi yang lebih ringkas daripada kandungan yang terdapat dalam Gray Paper. Kebolehskalaan dalam rantaian blok kebanyakannya mengikuti pendekatan yang digunakan dalam sistem teragih tradisional, iaitu skala naik (menegak) dan skala keluar (melintang).

Platform seperti Solana termasuk dalam skala naik. Ia mencapai keluaran maksimum dengan mengoptimumkan kod dan perkakasan. Ethereum dan Polkadot termasuk dalam skala keluar. Iaitu, mengurangkan jumlah kerja yang harus dilakukan oleh semua pihak. Dalam sistem teragih tradisional, ini dicapai dengan menambah lebih banyak mesin replika. Dalam rantaian blok, "mesin pengiraan (computation machine)" adalah keseluruhan set pengesah (validator). Kita boleh mengurangkan beban kerja set pengesah keseluruhan dengan membahagikan mereka untuk memecahkan kerja (kaedah ELVES) atau mengurangkan tanggungjawab mereka (kaedah Optimistic Rollup), dan akhirnya mengembangkan sistem secara mendatar.

💡 Skala keluar dalam rantaian blok bermaksud "mengurangkan bilangan mesin yang perlu memproses segala-galanya".

Ringkasannya adalah seperti berikut:

• Skala Naik: Pendekatan rantaian blok monolitik yang menjalankan pengoptimuman berasaskan perkakasan yang berkuasa.
• Skala Keluar:
• Optimistic Rollup
• Rollup berasaskan SNARK
• ELVES: Cynical Rollup Polkadot

Lampiran: Perkakasan Sama, Kemaskini Kernel

Bahagian ini menerangkan bagaimana JAM sebagai naik taraf Polkadot boleh dianalogikan sebagai kemaskini kernel pada perkakasan yang sama, berdasarkan pembentangan Rob Habermeier di Sub0 2023: Polkadot: Kernel/Userland | Sub0 2023 - YouTube.

Dalam komputer biasa, tumpukan sistem keseluruhan boleh dibahagikan kepada tiga bahagian berikut:

1. Perkakasan
2. Kernel
3. Ruang Pengguna

Seperti yang diterangkan sebelum ini, dalam Polkadot, Teras (Core) memainkan peranan perkakasan, iaitu entiti utama yang menyediakan pengiraan dan ketersediaan data. Kernel Polkadot secara praktikalnya [9] terdiri daripada dua perkara berikut:

• Protokol Paracain: cara yang kaku dan pendapat yang jelas untuk menggunakan teras. Satu set fungsi aras rendah seperti token DOT, fungsi pemindahan, staking, dan tadbir urus.

Kedua-dua ini kini wujud dalam rantaian perantai (relay chain) Polkadot.

Ruang Pengguna

Aplikasi merujuk kepada paracain, token asli mereka, dan segala-galanya yang dibina di atasnya. Ini boleh divisualisasikan seperti berikut:

Polkadot sentiasa mahu memindahkan fungsi teras kepada pengguna peringkat pertama, iaitu paracain. Matlamat RFC Minimum Relay (Minimal Relay RFC) juga begitu. Ini bermakna ruang kernel Polkadot akan berkurangan sedikit kerana rantaian perantai Polkadot hanya memberi tumpuan untuk menyediakan protokol kepada paracain.

Setelah seni bina ini dilaksanakan, kita boleh membayangkan dengan mudah bagaimana migrasi ke JAM akan berlaku. JAM akan mengurangkan ruang kernel Polkadot secara besar-besaran dan menjadikannya lebih boleh digunakan secara meluas. Selain itu, protokol paracain akan bergerak ke ruang pengguna, yang merupakan salah satu daripada beberapa cara untuk menulis aplikasi pada teras (perkakasan) yang sama dan JAM (kernel).

💡 Penerangan ini menekankan sekali lagi bahawa JAM menggantikan rantaian perantai Polkadot, bukan paracain. Dengan kata lain, migrasi JAM boleh dilihat sebagai peningkatan kernel. Perkakasan asal kekal, dan sebahagian besar kernel lama bergerak ke ruang pengguna untuk tujuan permudahan.

Rujukan

1. Polkadot 2.0: CorePlay, CoreChains, Corejam, Safrole, PolkaVM - Polkadot by Gavin @PBA4 - YouTube
2. Gavin Wood: The Gray Paper Interview - JAM & the Future of Polkadot - Behind the Code: Web3 Thinkers - YouTube
3. Parallel Chain. ↩︎
4. Rantaian blok atau fungsi peralihan keadaan. ↩︎
5. Dalam Polkadot 1.0, bukti keadaan L2 disebut PoV (Proof of Validity), dan gabungan bukti keadaan dengan blok paracain disebut PVF (Parachain Validation Function). ↩︎
6. Dalam Gray Paper, lapisan DA disebut sebagai Tasik Data Teragih (Distributed Data Lake, DDL). Dalam artikel ini, ia dirujuk sebagai DA atau lapisan DA untuk kemudahan. ↩︎
7. Adalah penting untuk ambil perhatian bahawa JAM hanya menggantikan rantaian perantai Polkadot. Semua aplikasi yang berjalan di atas Polkadot, termasuk paracain, kekal seperti sediaa kerana CoreChain. ↩︎
8. Yang ketiga ialah on_message, yang dipanggil apabila mesej datang dari perkhidmatan lain. ↩︎
9. Untuk butiran lanjut mengenai penjadualan perkhidmatan, rujuk bahagian "Authorization" dalam Gray Paper. ↩︎
10. Sumber terbaik untuk CorePlay adalah draf RFC ini. ↩︎
11. Perkataan "secara praktikalnya" adalah penting. Dalam video yang disebut, Rob juga memanggil protokol paracain sebagai aplikasi ruang pengguna Polkadot. Walau bagaimanapun, ini hanyalah andaian teoritis, kerana protokol paracain disatukan dalam protokol Polkadot teras, iaitu kernel itu sendiri. ↩︎