ويشرح Kian Paimani ، مطور Parity الرئيسي ، بروتوكول JAM بشكل فني من منظور تقني لمساعدة الناس على فهم كيفية توفير JAM القدرة على التوسع الجديدة لنظام بولكا.
كتب بواسطة: كيان بايماني، مطور أساسي في باريتي
ترجمة: مختبرات بولكادوت
*** "معرفة بولكا الرسم البياني" **** هو مقالنا المبتدئين حول بولكا من الصفر إلى واحد. نحن نحاول أن نبدأ من الأجزاء الأساسية لبولكا ونقدم محتوى شامل لفهم بولكا بشكل كامل. بالطبع هذا مشروع ضخم ومليء بالتحديات ، ولكن نأمل من خلال هذا الجهد أن نتمكن من توعية الناس بوولكا وأن نمكن الأشخاص الذين لا يعرفون بولكا من فهم المعرفة ذات الصلة ببولكا بسرعة وسهولة. **** اليوم هو العدد 148 لهذا القسم ، وهذه المقالة هي لتفسير بروتوكول JAM الجديد الذي طرحه مطورو Parity الأساسيون Kian Paimani من وجهة نظر تقنية لمساعدة الناس على فهم كيف يمكن لـ JAM أن يجلب قدرات موسعة جديدة لنظام بولكا البيئي. يتم كتابة هذه المقالة من وجهة نظر الكاتب بالشخص الأول. ***
يتضمن ما يلي شرحًا مفصلا لـ Polkadot1 و Polkadot2 وكيفية تطورها إلى JAM. (للتفاصيل ، يرجى الرجوع إلى: ****) يستهدف هذا المقال القراء الفنيين ، وخاصة الذين ليسوا على دراية كاملة بـ Polkadot ولكن لديهم بعض المعرفة بأنظمة سلسلة الكتل ، وربما القراء الذين لديهم معرفة بتقنيات النظم البيئية الأخرى ذات الصلة. *
*أعتقد أن قراءة هذا المقال قبل قراءة كتاب JAM هو مقدمة جيدة. (انظر التفاصيل: ***)
المعرفة الخلفية
هذا النص يفترض أن يكون القارئ على دراية بمفاهيم التالية:
وصف البلوكتشين بأنها دالة تحويل الحالة.
فهم ما هو "الحالة". (لمزيد من التفاصيل ، يرجى الاطلاع على: _sdk_docs/reference_docs/blockchain_state_machines/index.html)
الأمن الاقتصادي وإثبات التخزين. (لمزيد من التفاصيل، يرجى الاطلاع على: ، )
المقدمة: بولكادوت1
أولاً، دعنا نستعرض ما أعتقده أنه أكثر السمات الابتكارية في Polkadot1.
الجانب الاجتماعي:
بولكا هو منظمة اللامركزية الضخمة (DAO). ينفذ الشبكة حكمًا مستقلًا تمامًا يعتمد على السلسلة وتنفيذ ذاتي ، بما في ذلك الترقيات الزمنية المستمرة بدون حاجة للتحويل.
اللجنة الأمنية والبورصات الأمريكية (SEC) تعتبر DOT كبرمجيات وليست أوراق مالية. (التفاصيل انظر: )
يتم إنجاز معظم أعمال تطوير الشبكة بواسطة زمالة بولكادوت (راجع: ) بدلاً من الشركات المدعومة مالياً مثل بارتي (راجع: ).
الجانب التقني:
تم تحقيق بولكا مشاركة الأمان والتنفيذ.
استخدام بروتوكول الأصل القائم على WASM (يرجى الاطلاع على التفاصيل في sdk_docs/reference_docs/wasm_meta_protocol/index.html) ، لتخزين كود سلسلة الكتل بصيغة بايت في الحالة. هذا يتيح لمعظم الترقيات ألا تحتاج إلى حدوث تشعب، ويمكن تحقيق مشاركة متنوعة.
لمزيد من المعلومات حول "مشاركات غير متجانسة"، يرجى الرجوع إلى القسم ذي الصلة.
تنفيذ المشاركة: النقاط الرئيسية
حالياً، نحن نناقش شبكة Layer1 التي تستضيف شبكات Layer2 "blockchain" الأخرى، على غرار Polkadot وEthereum. لذا، يمكن استخدام مصطلحي Layer2 وشبكة موازية (Parachain) بشكل متبادل.
مشكلة القدرة على التوسع في سلسلة الكتل يمكن تصويرها على أنها مجموعة من المدققون الذين يمكنهم ضمان تنفيذ بعض الشيفرات بشكل موثوق من خلال إثبات الحصة الاقتصادية لـ التخزين (Proof-of-Stake) . بشكل افتراضي ، يحتاج هؤلاء المدققون إلى إعادة تنفيذ كل عمل للآخرين. وبالتالي ، طالما أننا نجبر جميع المدققين على إعادة تنفيذ كل شيء في كل مرة ، فإن النظام بأكمله لن يكون قابلاً للتوسع.
يرجى ملاحظة أن زيادة عدد المدققين في هذا النموذج لن يزيد حقًا من طاقة التحمل للنظام، طالما أن مبادئ الإعادة التنفيذ المطلقة المذكورة أعلاه لا تتغير.
المعروض أعلاه هو سلسلة كتل فردية (مقابل سلسلة كتل مشاركة). يتم معالجة جميع المدققين في الشبكة بشكل فردي بالمدخلات (أي الكتلة) واحدة تلو الأخرى.
في مثل هذه الأنظمة، إذا أراد Layer1 استضافة المزيد من Layer2، فيجب على جميع المدققون إعادة تنفيذ كل عمل Layer2 الآن. من الواضح أن هذا النهج لا يمكن أن يوسع. تعتبر تقنية الـ Rollups المتفائلة وسيلة لتجنب هذه المشكلة، حيث يتم إعادة التنفيذ فقط عندما يدعي شخص ما حدوث دليل على الاحتيال. يعمل Rollups القائمة على SNARK عن طريق استغلال حقيقة أن تكلفة التحقق من دليل SNARK أقل بكثير من إنشائه، مما يسمح لجميع المدققون بالتحقق من أن دليل SNARK معقول. لمزيد من المعلومات حول هذا الموضوع، يُرجى الرجوع إلى "الملحق: رسم مساحة التوسع".
أحد الحلول البسيطة لمشكلة المشاركة هو فقط تقسيم مجموعة المدققين إلى مجموعات فرعية أصغر وإعادة تنفيذ كتل Layer2 من قبل هذه المجموعة الفرعية الأصغر. ما هي مشكلة هذا الأسلوب؟ نحن نتحدث عن تنفيذ الشبكة والأمان الاقتصادي للمشاركة. أمان Layer2 منخفض بالنسبة لـ Layer1 ومع تقسيم مجموعة المدققين إلى مزيد من المجموعات الفرعية ، سيتراجع أمانها بشكل أكبر.
على عكس Rollups الجيدة التي لا يمكن إعادة تنفيذ تكلفتها بشكل دائم، فإن بولكا تأخذ في الاعتبار مشاركة القطع عند التصميم، مما يتيح لبعض المدققين إعادة تنفيذ كتلة Layer2 وفي الوقت نفسه توفير أدلة اقتصادية كريبتو كافية لجميع مشاركي الشبكة لإثبات حقيقة هذه الكتلة Layer2 وسلامتها بالكامل عند إعادة تنفيذ مجموعة المدققين بأكملها. ويتم ذلك من خلال آلية جديدة (تم الإعلان عنها رسميًا مؤخرًا) تُعرف باسم ELVES. (يرجى الرجوع إلى التفاصيل: )
بإختصار، يمكن اعتبار ELVES آلية 'Rollups' شكلية. من خلال طرح أسئلة المدققين النشطين للمدققين الآخرين حول صحة كتلة Layer2 معينة، يمكننا تأكيد صحة تلك الكتلة Layer2 بشكل كبير. في الواقع، في حالة وجود أي نزاع، سيتم طلب مشاركة الأعضاء بالمدققين في الحال. شرح Rob Habermeier، مؤسس بولكا، هذه النقطة بالتفصيل في مقال. (للتفاصيل، يرجى الاطلاع على:)
يجعل ELVES بولكادوت قادرة على الجمع بين خاصيتين كانتا معتبرتين متنافستين سابقًا: 'مشاركة التنفيذ' و 'الأمان المشترك'. إن هذا إنجاز تقني رئيسي فيما يتعلق بقابلية التوسع لبولكادوت 1.
الآن، دعونا نواصل مناقشة التشبيه بـ "CORE".
تشبه سلسلة كتلة التي تنفذ مشاركة إلى حد كبير وحدة المعالجة المركزية: بنفس الطريقة التي يمكن أن تحتوي بها وحدة المعالجة المركزية على نوى متعددة تنفذ التعليمات بالتوازي ، يمكن ل Polkadot معالجة كتلة الطبقة 2 بالتوازي. هذا هو السبب في أن الطبقة 2 على Polkadot تسمى parachain ، وتسمى البيئة التي يتم فيها إعادة تنفيذ كتلة طبقة 2 واحدة بواسطة مجموعة فرعية أصغر من المدققون "الأساسية". يمكن تجريد كل نواة على أنها "مجموعة من المدققون التي تعمل معا".
يمكنك تصور سلسلة كتلة فردية كما لو كانت تستهلك كتلة واحدة فقط خلال فترة زمنية معينة، في حين يستهلك Polkadot سلسلة مناوبة وسلسلة موازية واحدة لكل لب في كل فترة زمنية.
التشرذم
حتى الآن، ناقشنا فقط قابلية التوسع والتنفيذ المشترك الذي يوفره بروتوكول Polkadot. يجدر بالذكر أن كل تنفيذ مشترك في Polkadot في الواقع تطبيق مختلف تمامًا. يتم ذلك عن طريق استخدام بروتوكول ميتا البلوكتشين المخزن في البايت كود: بروتوكول يعرف سلسلة الكتل كبايت كود مخزن في حالة سلسلة الكتل نفسها. في Polkadot 1.0 ، تم استخدام WASM كبايت الأولى ، بينما تم استخدام PVM/RISC-V في JAM.
باختصار ، هذا هو السبب في أن بولكا يُعرف بأنه بلوكشين ذو قطع متنوعة. (راجع: 01928374656574839201) كل Layer2 هو تطبيق مختلف تمامًا.
بولكادوت 2
جزء مهم من Polkadot2 هو جعل استخدام النواة أكثر مرونة. في نموذج Polkadot الأصلي ، يمكن تأجير النواة في أي مكان من 6 أشهر إلى 2 سنوات ، والتي كانت مناسبة للشركات ذات الموارد الجيدة ، ولكن ليس جيدا للفرق الصغيرة. تسمى ميزة Polkadot Core التي يمكن استخدامها بطريقة أكثر مرونة "Agile CoreTime". في هذا الوضع ، يمكن استئجار نواة Polkadot مقابل كتلة واحدة أو لمدة شهر ، وتوفر سقفا للسعر لأولئك الذين يرغبون في استئجارها لفترة طويلة.
سيتم عرض ميزات أخرى لـ Polkadot 2 تدريجيًا أثناء مناقشتنا هنا، لذا لا داعي للتفصيل كثيرًا.
العمليات الداخلية للنواة وعمليات السلسلة
لفهم JAM ، يجب أولاً فهم ما يحدث عندما يدخل كتلة Layer2 إلى نواة بولكا.
تم تبسيط محتوى كبير فيما يلي.
استعراض، ويتكون النواة أساسا من مجموعة من الفحص. لذلك، عندما نقول "تم إرسال البيانات إلى النواة"، فإننا في الواقع نشير إلى أن هذه البيانات تم تمريرها إلى هذه المجموعة من الفحص.
0.تم إرسال كتلة Layer2 مع جزء من حالة Layer2 إلى النواة. هذه البيانات هي جميع المعلومات المطلوبة لتنفيذ كتلة Layer2.
جزء من المحققين في النواة سيقومون بإعادة تنفيذ الكتلة Layer2 ومتابعة معالجة المهام المتعلقة بالإجماع.
يعيد المدققون الأساسيون تنفيذ البيانات المطلوبة لتزويد المدققين الآخرين (المدققين خارج النواة). قد يقرر المدققون الآخرون استنادًا إلى قواعد ELVES إعادة تنفيذ كتلة Layer2 هذه ويحتاجون إلى هذه البيانات لإكمال هذا الإجراء.
يرجى ملاحظة أن جميع العمليات حتى الآن تتم خارج كتلة بولكا ووظيفة التحول الحالية. كل شيء يحدث داخل النواة وطبقة توفر البيانات.
في النهاية، سيكون جزء صغير من الحالة الأخيرة لـ Layer2 مرئيًا على سلسلة بلوكات Polkadot الرئيسية. على عكس جميع العمليات السابقة، فإن هذه العملية أرخص بكثير من إعادة تنفيذ كتل Layer2 بالفعل، وستؤثر على الحالة الرئيسية لـ Polkadot وستكون مرئية في كتل Polkadot وستنفذها جميع المدققين. 01928374656574839201
من المحتوى أعلاه ، يمكننا مناقشة بعض العمليات التي يقوم بها بوكا:
أولاً ، من الخطوة 1 يمكننا أن نستنتج أن هناك طريقة تنفيذ جديدة في بولكا مختلفة عن وظيفة تحويل حالة سلسلة الكتل التقليدية. عادةً ما يتم تحديث حالة سلسلة الكتل الرئيسية عندما يقوم جميع المدققون بعمل معين. نطلق على هذا الحالة الداخل السلسلة (on-chain operation) وهذا هو ما يحدث في الخطوة 3. ومع ذلك ، يحدث الأمر الجديد داخل النواة (الخطوة 1) بشكل مختلف. نطلق على هذا الحساب الجديد لسلسلة الكتل الجديدة التي تقوم على النواة (in-core ution).
من النقطة 2 يمكننا استنتاج أن بولكا قدمت طبقة DA الأصلية لتوفير قابلية استخدام البيانات ، وأن Layer2 تستخدمها تلقائيًا لضمان توافر بيانات التنفيذ الخاصة بها على مدى فترة محددة. ومع ذلك ، فإن كتل البيانات التي يمكن نشرها على طبقة DA هي ثابتة ، وهي دائمًا بيانات البرهان المطلوبة لإعادة تنفيذ كتلة Layer2. بالإضافة إلى ذلك ، فإن شفرة parachain لم تقم بقراءة بيانات DA.
فهم المحتوى أعلاه هو أساس فهم JAM. يتم تلخيصها على النحو التالي:
تنفيذ في النواة (إين-كور إيوشن): يشير إلى العمليات التي تحدث داخل النواة. يتميز بأنه غني وقابل للتوسيع، ويتحقق من نفس مستوى الأمان الذي يتم تنفيذه في السلسلة من خلال الاقتصاد الرمزي و ELVES.
تنفيذ داخل السلسلة (on-chain execution): يشير إلى جميع العمليات التي يقوم بها المدققون. يتم توفير الأمان بشكل افتراضي من خلال المدققين الذين يتمتعون بالضمان الاقتصادي، ولكن تكلفة أعلى وتوجد قيود أكثر، لأن الجميع يقومون بتنفيذ جميع العمليات.
توفر البيانات (Data Availability): يلتزم المدققون في بولكا بتوفير توفر بعض البيانات خلال فترة محددة وتوفير القدرة على توفير هذه البيانات للمدققين الآخرين.
جام
من خلال فهم الجزء السابق، يمكننا الانتقال بسلاسة إلى استعراض JAM.
JAM هو بروتوكول جديد مستوحى من بولكا ومتوافق تمامًا معه، مصمم ليحل محل سلسلة بولكا ويجعل الاستخدام الأساسي مفتوحًا تمامًا وغير مركزي.
تم بناء JAM على Polkadot2 ، ويهدف إلى جعل النواة الأساسية لـ Polkadot أكثر سهولة في الوصول إليها ، ولكن بطريقة أكثر مرونة وبدون قيود ثابتة مقارنةً بـ agile-coretime.
Polkadot2 يجعل نشر Layer2 أكثر مرونة في الأساس.
*JAM تهدف إلى تمكين أي تطبيق من نشره على البولكا الأساسية، حتى لو لم يكن هذا التطبيق مشابهًا لسلسلة الكتل أو الطبقة 2.
يتم ذلك أساسا من خلال تعريض المطورين لثلاثة مفاهيم أساسية رئيسية تم مناقشتها في الجزء الأمامي: وهي التنفيذ في السلسلة، والتنفيذ النواة الأساسي، وطبقة DA.
بمعنى آخر، في JAM، يمكن للمطورين أن يتعاملوا مع:
完全قابلية البرمجة化核心内和داخل السلسلة的工作。
السماح بقراءة وكتابة أي بيانات على طبقة DA لـ Polkadot.
هذا هو وصف أساسي لبروتوكول JAM. لا داعي للكلام كثيرًا، لقد قمنا بتبسيط الأمور كثيرًا هنا، وقد يظل البروتوكول قيد التطور.
بعد فهم هذا الأساس، يمكننا الآن استكشاف بعض التفاصيل حول JAM في الفصول القادمة.
1 الخدمات والمهام العملية
في ظل خلفية JAM، يطلق على ما كان يسمى سابقًا Layer2 / parachain الآن اسم "الخدمة (Service)"، بينما يُطلق الآن على ما كان يسمى سابقًا كتلة / صفقة اسم "عنصر العمل (Work-Item)" أو "حزمة العمل (Work-Package)". على وجه الخصوص، ينتمي عنصر العمل إلى خدمة ما، في حين أن حزمة العمل هي مجموعة من عناصر العمل. تم تصميم هذه المصطلحات بشكل مقصود بأن تكون عامة بما فيه الكفاية لتغطية مجموعة متنوعة من الحالات الاستخدامية التي تتجاوز سلسلة الكتل / Layer2.
وصف الخدمة مكون من ثلاث نقاط دخول، حيث يكون اثنان منها fn refine() و fn accumulate() على التوالي. يصف الأول الخدمة التي تم تنفيذها في النواة، بينما يصف الثاني الخدمة التي تم تنفيذها داخل السلسلة.
وأخيراً، أسماء نقطتي الوصول هما أيضًا سبب تسمية البروتوكول بـ JAM (Join Accumulate Machine). Join يعني fn refine()، عندما تقوم جميع نوى بولكا بمعالجة الكمية الكبيرة من العمل المختلف للخدمات بشكل متوازٍ، فإن هذه المرحلة تسمى Join. بعد تصفية البيانات، تنتقل إلى المرحلة التالية. Accumulate تشير إلى العملية التي تتمثل في تجميع جميع النتائج المذكورة أعلاه في حالة JAM الرئيسية، أي التنفيذ داخل السلسلة.
يمكن تحديد عناصر العمل بدقة بما يتعلق بتنفيذها في النواة وداخل السلسلة وتحديد كيفية / ما إذا كان / من أين يتم قراءة وكتابة محتوى البحيرة البيانات الموزعة (Distributed Data Lake).
2 شبه متسقة
على الرغم من أنه يتم إرسال الرسائل دون أن يتم الانتظار للرد عليها بعد إرسالها، إلا أنه يتعين على المرء أن يراجع المعلومات المتاحة حول XCM (لغة الاتصال لشبكات الباراشاين المختارة من قبل بولكادوت) لفهم الاتصال الغير متزامن. (انظر للتفاصيل:)
الخاصية الغير متزامنة هي تجسيد لعدم التوافق في النظام، وهي عيب رئيسي في النظام المستمر (مثل بولكا 1 وبولكا 2 والبيئة الحالية للطبقة 2 لإيثيريوم).
ومع ذلك، كما هو موضح في الفقرة 2.4 من الكتاب الرمادي، فإن النظام الذي يحافظ دائمًا على تزامن كل مستأجر لديه، يمكن أيضًا أن يرتقي إلى مستوى معين دون التضحية بالشمولية أو الوصول أو المرونة. (للتفاصيل راجع:)
التزامن≈الاتساق||الكتابة الغير متزامنة≈عدم الاتساق
هذا هو مجال آخر تبرز فيه JAM: من خلال إدخال ميزات متعددة، أدى JAM إلى تحقيق حالة وسيطة جديدة وهي نظام شبه متسق. في هذا النظام، لديهم فرصة لخلق بيئة متسقة بين الأنظمة الفرعية التي تتواصل بشكل متكرر مع بعضها البعض، دون الحاجة إلى إجبار النظام بأكمله على البقاء متسقاً. وتلخص هذه الفكرة على أحسن وجه في مقابلة الدكتور غافين وود، مؤلف الكتاب الرمادي (لمزيد من التفاصيل، راجع الرابط التالي: _referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ).
طريقة أخرى لفهم بولكا / JAM هي أنها نظام مشاركة حيث يكون حدود هذه المشاركات متدفقة ومحددة ديناميكيًا.
بولكا دائمًا ما تكون مشاركة، وتكون متنوعة بالكامل.
الآن، سيتم تقسيمها وتشتيتها، ويمكن تحديد حدود هذه التقسيمات بمرونة، تماما كما قال غافين وود في تغريدته عن "نظام نصف الاتساق". (راجع: _src=twsrc%5Etfw)
السمات التي تجعل كل هذا ممكنًا تشمل:
زيارة تنفيذ نواة موازية وبدون حالة، حيث يمكن للخدمات المختلفة التفاعل بتزامن مع الخدمات الأخرى في نفس النواة وفي كتلة محددة فقط، وتنفيذ داخل السلسلة حيث يمكن للخدمات الوصول إلى نتائج جميع الخدمات عبر جميع النوى.
JAM لا تفرض تنفيذ أي جدول زمني خاص بالخدمة. يمكن للخدمات التي تتطلب اتصالًا متكررًا توفير حوافز اقتصادية لأجهزتها الفرز ، وإنشاء حزم عمل تحتوي على هذه الخدمات التي تتطلب اتصالًا متكررًا. هذا يتيح لهذه الخدمات أن تعمل في نفس النواة ، حيث يتم إجراء الاتصالات بينها كما لو كانت في بيئة متزامنة.
بالإضافة إلى ذلك ، يمكن لخدمة JAM الوصول إلى طبقة البيانات واستخدامها كطبقة بيانات مؤقتة ورخيصة للغاية. بمجرد وضع البيانات في DA ، ستنتشر في النهاية إلى جميع النوى ، ولكنها متاحة فورًا في نفس النواة. بالتالي ، يمكن لخدمة JAM الاستفادة من درجة أعلى من وصول البيانات عن طريق جدولة نفسها في نفس النواة في كتلة متتالية.
يجب ملاحظة أنه على الرغم من أن المحتوى أعلاه ممكن في JAM، إلا أنه ليس ملزمًا في طبقة البروتوكول. لذا، من المتوقع أن تكون بعض الواجهات غير متزامنة في نظرية، ولكن يمكن أن تظهر عملياً كمتزامنة من خلال التجربة العملية من خلال التجربة العملية. القسم التالي سيناقش CorePlay كمثال على ذلك.
3 كور بلاي
يقدم هذا القسم CorePlay، وهو فكرة تجريبية في بيئة JAM ويمكن وصفها بأنها نموذج جديد للبرمجة الذكية. في الوقت الحالي من كتابة هذا النص، لم يتم توضيح CorePlay بالتفصيل ولا يزال هو فكرة.
لفهم CorePlay ، نحتاج أولاً إلى تقديم الآلة الافتراضية التي اختارها JAM: PVM.
4 PVM
PVM هو تفاصيل مهمة في JAM و CorePlay. تفاصيل PVM على مستوى منخفض تتجاوز نطاق هذه المقالة، من الأفضل الرجوع إلى وصف الخبراء في الكتاب الأبيض. ومع ذلك، لاحتياجات هذه المقالة، نحن بحاجة فقط إلى شرح بعض خصائص PVM:
قياس فعال
القدرة على تعليق واستئناف التنفيذ
الأخير مهم بشكل خاص لـ CorePlay.
CorePlay هو مثال على إنشاء بيئة مرنة للعقود الذكية مزامنة وقابلة للتوسيع باستخدام لغة برمجة JAM. يوفر CorePlay واجهة برمجة غاية في المرونة. يُقترح نشر العقود الذكية القائمة على الممثل مباشرة على نواة JAM لتمكينها من الاستفادة من واجهة برمجة مزامنة حيث يمكن كتابة البرنامج بشكل عادي مثل fn main() والتواصل من خلال let_result=other_coreplay_actor(data).await؟. إذا كان other_coreplay_actor موجودًا على نواة JAM نفسها، فإن هذا الاستدعاء متزامن؛ وإذا كان على نواة أخرى، فسيتم تعليق الممثل واستئنافه في الكتلة التالية لـ JAM. يجعل ذلك ممكنًا بفضل خدمة JAM وجدولة مرنة، بالإضافة إلى خصائص PVM.
5 خدمة السلاسل الأساسية
أخيرًا، دعونا نلخص الأسباب الرئيسية التي تم ذكرها لجعل JAM متوافقًا تمامًا مع بولكا. المنتج الرئيسي لبولكا هو parachain الذي يعمل بطريقة الوقت الأساسية السريع، وهذا المنتج مستمر في JAM.
من المحتمل أن يُشار إلى الخدمة التي تم نشرها في JAM في وقت مبكر باسم CoreChains أو Parachains. ستسمح هذه الخدمة بتشغيل الـ parachains بنمط Polkadot -2 الحالية على JAM.
يمكن نشر خدمات إضافية على JAM ويمكن لخدمات CoreChains الحالية التواصل معها، ولكن منتجات بولكا الحالية ستظل قوية وفقط ستفتح أبوابًا جديدة لفرق Parachain الحالية.
附录：数据مشاركة
تناقش هذه المقالة معظم المحتوى من منظور المشاركة القابلة للتوسع. يمكننا أيضًا التفكير في نفس المشكلة من منظور البيانات. من المثير للاهتمام أننا نجد أن هذا مشابه لحالة الاتساق الجزئي المذكورة سابقًا: في النظرية ، يكون النظام المتسق الكامل أفضل ، ولكن غير قابل للتوسع ؛ يكون النظام غير المتساق الكامل قابل للتوسع ، ولكنه غير مثالي ، وقد أقترح JAM بنموذجه الجزئي الاتساق فرصة جديدة.
نظام متطابق تمامًا: هذا هو ما نراه على منصة العقود الذكية المتزامنة تمامًا مثل سولانا أو تلك المنصات الجريئة التي تنتشر فقط على طبقة إيثريوم Layer1. يتم تخزين جميع بيانات التطبيق في سلسلة الكتل ويمكن الوصول إليها بسهولة من جميع التطبيقات الأخرى. إنه خاصية مثالية برمجيًا ولكنها غير قابلة للتوسعة.
نظام غير متسق : يتم حفظ بيانات التطبيق في الطبقة 1 الخارجية، بالإضافة إلى مشاركة منفصلة ومختلفة. قابل للتوسيع بشكل كبير، ولكنه غير فعال من حيث القابلية للتركيب. ينطبق نموذج Rollup لـ Polkadot وEthereum في هذا الحال.
JAM بالإضافة إلى توفير الوظائف المذكورة أعلاه، يسمح أيضًا للمطورين بنشر أي بيانات إلى طبقة JAM DA، وهذا بشكل ما يعتبر منطقة وسطى بين البيانات داخل السلسلة والبيانات خارج السلسلة. يمكن كتابة تطبيقات جديدة تستخدم بيانات DA بشكل كبير، مع الاحتفاظ فقط بالبيانات الحاسمة بشكل مطول في حالة JAM.
الملحق: خريطة مساحة التوسع
يعيد هذا الجزء تفسيرنا لرؤيتنا لمجال قابلية التوسع في تقنية بلوكتشين. ويتم ذلك أيضًا في الكتاب الرمادي، وهنا يتم تقديم نسخة أكثر اختصارًا.
قابلية توسيع سلسلة الكتل تتبع إلى حد كبير الأساليب المستخدمة في أنظمة التوزيع التقليدية: التوسيع الرأسي والتوسيع الأفقي.
التوسع الصعودي هو العمل الذي يقوم به منصات مثل سولانا. من خلال تحسين الأداء الشديد للأجهزة والبرمجيات لتحقيق أقصى قدر من الإنتاجية.
التوسع هو الاستراتيجية التي تستخدمها Ethereum و Polkadot: تقليل مقدار العمل الذي يجب القيام به للجميع. في النظام الموزع التقليدي ، يتم تحقيق ذلك عن طريق إضافة المزيد من آلات النسخ المتماثل. في سلسلة كتلة ، "الكمبيوتر" عبارة عن مجموعة من المدققون للشبكة بأكملها. من خلال توزيع العمل بينهم (كما يفعل ELVES) ، أو عن طريق تقليل مسؤولياتهم بتفاؤل (كما تفعل Rollups المتفائلة) ، قمنا بتقليل عبء العمل على مجموعة المدققون بأكملها ، مما سمح للنظام بالتوسع.
في سلسلة الكتل، التوسع الخارجي يشبه "تقليل عدد الآلات اللازمة لتنفيذ جميع العمليات".
يتم تلخيصها كما يلي:
توسيع لأعلى: أجهزة عالية الأداء + تحسين سلسلة كتلية فردية.
التوسع الخارجي:
مجموعات متفائلة
مجموعات Rollups المعتمدة على SNARK
ELVES: الساخرة Rollups (Rollups الساخرة)
الملحق: نفس الأجهزة ، تحديث النواة
هذا القسم مستوحى من المقارنة التي قدمها روب هابيرماير في Sub02023: Polkadot: Kernel/Userland|Sub02023-YouTube (للمزيد من التفاصيل: )، ويظهر JAM كترقية لـ Polkadot: تحديث النواة على نفس الأجهزة.
في الحاسوب النموذجي، يمكننا تقسيم الكومة بأكملها إلى ثلاثة أجزاء:
الأجهزة
النواة
مساحة المستخدم
في بولكا، كانت الأجهزة، أي الجوهر الذي يوفر الحوسبة وتوفر البيانات، دائمًا في صميم الأمور، كما هو موضح في الأساس.
في بولكا ، النواة في الواقع[9]حتى الآن ، تم تضمين جزئين:
1.parachain（Parachains）بروتوكول: وسيلة للتفاعل المباشر والثابت مع النواة.
مجموعة من الوظائف الأساسية مثل DOT عملة وقابليتها للتحويل والتكديس والحوكمة وما إلى ذلك.
كلاهما موجود في سلسلة Relaي على Polkadot.
تطبيقات المساحة المستخدم هي مثيلات البنات الجانبية وعملاتها الأصلية والمحتوى الآخر المبني عليها.
يمكننا تصور هذه العملية على النحو التالي:
ومن المتوقع دائمًا أن تقوم بولكا بنقل المزيد من الوظائف الأساسية إلى فئة مستخدمين فريدة - parachain. هذا هو بالضبط الهدف الذي تسعى إليه Minimal Relay RFC لتحقيقه. (يرجى الرجوع إلى: )
هذا يعني أن سلسلة ريليه بولكا تعالج فقط بروتوكول الباراشين، مما يقلل إلى حد ما من المساحة النواة.
عندما تتم هذه الهيكلية، سيكون من الأسهل تصور كيفية ترحيل JAM. سيقلل JAM بشكل كبير من مساحة نواة Polkadot ويجعلها أكثر قابلية للتطبيق. بالإضافة إلى ذلك، سيتم نقل بروتوكول Parachains إلى مساحة المستخدم، لأن هذه هي واحدة من الطرق القليلة التي يمكن فيها كتابة التطبيقات على نفس النواة (الأجهزة) والنواة (JAM).
هذا يوضح مرة أخرى لماذا JAM هو بديل فقط لسلسلة بولكا الرئيسية وليس بديلًا للشبكة الفرعية.
بمعنى آخر، يمكننا أن نعتبر ترحيل JAM كترقية للنواة. يبقى الأجهزة الأساسية كما هي، ويتم نقل معظم محتوى النواة القديمة إلى مساحة المستخدم لتبسيط النظام.
للمشاركة في مناقشة هذه المقالة ، يرجى نشر آرائك في المنتدى:
بالنسبة لكيفية الانضمام إلى مناقشات المنتدى ، يرجى الاطلاع على دليل استخدام منتدى بولكا الذي قدمناه:
《كيفية المشاركة في مناقشات بولكا: دليل استخدام منتديات بولكا الرسمية》
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
كشف النقاب عن جام بولكا من الناحية التقنية
كتب بواسطة: كيان بايماني، مطور أساسي في باريتي
ترجمة: مختبرات بولكادوت
*** "معرفة بولكا الرسم البياني" **** هو مقالنا المبتدئين حول بولكا من الصفر إلى واحد. نحن نحاول أن نبدأ من الأجزاء الأساسية لبولكا ونقدم محتوى شامل لفهم بولكا بشكل كامل. بالطبع هذا مشروع ضخم ومليء بالتحديات ، ولكن نأمل من خلال هذا الجهد أن نتمكن من توعية الناس بوولكا وأن نمكن الأشخاص الذين لا يعرفون بولكا من فهم المعرفة ذات الصلة ببولكا بسرعة وسهولة. **** اليوم هو العدد 148 لهذا القسم ، وهذه المقالة هي لتفسير بروتوكول JAM الجديد الذي طرحه مطورو Parity الأساسيون Kian Paimani من وجهة نظر تقنية لمساعدة الناس على فهم كيف يمكن لـ JAM أن يجلب قدرات موسعة جديدة لنظام بولكا البيئي. يتم كتابة هذه المقالة من وجهة نظر الكاتب بالشخص الأول. ***
*أعتقد أن قراءة هذا المقال قبل قراءة كتاب JAM هو مقدمة جيدة. (انظر التفاصيل: ***)
المعرفة الخلفية
هذا النص يفترض أن يكون القارئ على دراية بمفاهيم التالية:
المقدمة: بولكادوت1
أولاً، دعنا نستعرض ما أعتقده أنه أكثر السمات الابتكارية في Polkadot1.
الجانب الاجتماعي:
الجانب التقني:
لمزيد من المعلومات حول "مشاركات غير متجانسة"، يرجى الرجوع إلى القسم ذي الصلة.
تنفيذ المشاركة: النقاط الرئيسية
حالياً، نحن نناقش شبكة Layer1 التي تستضيف شبكات Layer2 "blockchain" الأخرى، على غرار Polkadot وEthereum. لذا، يمكن استخدام مصطلحي Layer2 وشبكة موازية (Parachain) بشكل متبادل.
مشكلة القدرة على التوسع في سلسلة الكتل يمكن تصويرها على أنها مجموعة من المدققون الذين يمكنهم ضمان تنفيذ بعض الشيفرات بشكل موثوق من خلال إثبات الحصة الاقتصادية لـ التخزين (Proof-of-Stake) . بشكل افتراضي ، يحتاج هؤلاء المدققون إلى إعادة تنفيذ كل عمل للآخرين. وبالتالي ، طالما أننا نجبر جميع المدققين على إعادة تنفيذ كل شيء في كل مرة ، فإن النظام بأكمله لن يكون قابلاً للتوسع.
يرجى ملاحظة أن زيادة عدد المدققين في هذا النموذج لن يزيد حقًا من طاقة التحمل للنظام، طالما أن مبادئ الإعادة التنفيذ المطلقة المذكورة أعلاه لا تتغير.
المعروض أعلاه هو سلسلة كتل فردية (مقابل سلسلة كتل مشاركة). يتم معالجة جميع المدققين في الشبكة بشكل فردي بالمدخلات (أي الكتلة) واحدة تلو الأخرى.
في مثل هذه الأنظمة، إذا أراد Layer1 استضافة المزيد من Layer2، فيجب على جميع المدققون إعادة تنفيذ كل عمل Layer2 الآن. من الواضح أن هذا النهج لا يمكن أن يوسع. تعتبر تقنية الـ Rollups المتفائلة وسيلة لتجنب هذه المشكلة، حيث يتم إعادة التنفيذ فقط عندما يدعي شخص ما حدوث دليل على الاحتيال. يعمل Rollups القائمة على SNARK عن طريق استغلال حقيقة أن تكلفة التحقق من دليل SNARK أقل بكثير من إنشائه، مما يسمح لجميع المدققون بالتحقق من أن دليل SNARK معقول. لمزيد من المعلومات حول هذا الموضوع، يُرجى الرجوع إلى "الملحق: رسم مساحة التوسع".
أحد الحلول البسيطة لمشكلة المشاركة هو فقط تقسيم مجموعة المدققين إلى مجموعات فرعية أصغر وإعادة تنفيذ كتل Layer2 من قبل هذه المجموعة الفرعية الأصغر. ما هي مشكلة هذا الأسلوب؟ نحن نتحدث عن تنفيذ الشبكة والأمان الاقتصادي للمشاركة. أمان Layer2 منخفض بالنسبة لـ Layer1 ومع تقسيم مجموعة المدققين إلى مزيد من المجموعات الفرعية ، سيتراجع أمانها بشكل أكبر.
على عكس Rollups الجيدة التي لا يمكن إعادة تنفيذ تكلفتها بشكل دائم، فإن بولكا تأخذ في الاعتبار مشاركة القطع عند التصميم، مما يتيح لبعض المدققين إعادة تنفيذ كتلة Layer2 وفي الوقت نفسه توفير أدلة اقتصادية كريبتو كافية لجميع مشاركي الشبكة لإثبات حقيقة هذه الكتلة Layer2 وسلامتها بالكامل عند إعادة تنفيذ مجموعة المدققين بأكملها. ويتم ذلك من خلال آلية جديدة (تم الإعلان عنها رسميًا مؤخرًا) تُعرف باسم ELVES. (يرجى الرجوع إلى التفاصيل: )
بإختصار، يمكن اعتبار ELVES آلية 'Rollups' شكلية. من خلال طرح أسئلة المدققين النشطين للمدققين الآخرين حول صحة كتلة Layer2 معينة، يمكننا تأكيد صحة تلك الكتلة Layer2 بشكل كبير. في الواقع، في حالة وجود أي نزاع، سيتم طلب مشاركة الأعضاء بالمدققين في الحال. شرح Rob Habermeier، مؤسس بولكا، هذه النقطة بالتفصيل في مقال. (للتفاصيل، يرجى الاطلاع على:)
يجعل ELVES بولكادوت قادرة على الجمع بين خاصيتين كانتا معتبرتين متنافستين سابقًا: 'مشاركة التنفيذ' و 'الأمان المشترك'. إن هذا إنجاز تقني رئيسي فيما يتعلق بقابلية التوسع لبولكادوت 1.
الآن، دعونا نواصل مناقشة التشبيه بـ "CORE".
تشبه سلسلة كتلة التي تنفذ مشاركة إلى حد كبير وحدة المعالجة المركزية: بنفس الطريقة التي يمكن أن تحتوي بها وحدة المعالجة المركزية على نوى متعددة تنفذ التعليمات بالتوازي ، يمكن ل Polkadot معالجة كتلة الطبقة 2 بالتوازي. هذا هو السبب في أن الطبقة 2 على Polkadot تسمى parachain ، وتسمى البيئة التي يتم فيها إعادة تنفيذ كتلة طبقة 2 واحدة بواسطة مجموعة فرعية أصغر من المدققون "الأساسية". يمكن تجريد كل نواة على أنها "مجموعة من المدققون التي تعمل معا".
يمكنك تصور سلسلة كتلة فردية كما لو كانت تستهلك كتلة واحدة فقط خلال فترة زمنية معينة، في حين يستهلك Polkadot سلسلة مناوبة وسلسلة موازية واحدة لكل لب في كل فترة زمنية.
التشرذم
حتى الآن، ناقشنا فقط قابلية التوسع والتنفيذ المشترك الذي يوفره بروتوكول Polkadot. يجدر بالذكر أن كل تنفيذ مشترك في Polkadot في الواقع تطبيق مختلف تمامًا. يتم ذلك عن طريق استخدام بروتوكول ميتا البلوكتشين المخزن في البايت كود: بروتوكول يعرف سلسلة الكتل كبايت كود مخزن في حالة سلسلة الكتل نفسها. في Polkadot 1.0 ، تم استخدام WASM كبايت الأولى ، بينما تم استخدام PVM/RISC-V في JAM.
باختصار ، هذا هو السبب في أن بولكا يُعرف بأنه بلوكشين ذو قطع متنوعة. (راجع: 01928374656574839201) كل Layer2 هو تطبيق مختلف تمامًا.
بولكادوت 2
جزء مهم من Polkadot2 هو جعل استخدام النواة أكثر مرونة. في نموذج Polkadot الأصلي ، يمكن تأجير النواة في أي مكان من 6 أشهر إلى 2 سنوات ، والتي كانت مناسبة للشركات ذات الموارد الجيدة ، ولكن ليس جيدا للفرق الصغيرة. تسمى ميزة Polkadot Core التي يمكن استخدامها بطريقة أكثر مرونة "Agile CoreTime". في هذا الوضع ، يمكن استئجار نواة Polkadot مقابل كتلة واحدة أو لمدة شهر ، وتوفر سقفا للسعر لأولئك الذين يرغبون في استئجارها لفترة طويلة.
سيتم عرض ميزات أخرى لـ Polkadot 2 تدريجيًا أثناء مناقشتنا هنا، لذا لا داعي للتفصيل كثيرًا.
العمليات الداخلية للنواة وعمليات السلسلة
لفهم JAM ، يجب أولاً فهم ما يحدث عندما يدخل كتلة Layer2 إلى نواة بولكا.
تم تبسيط محتوى كبير فيما يلي.
استعراض، ويتكون النواة أساسا من مجموعة من الفحص. لذلك، عندما نقول "تم إرسال البيانات إلى النواة"، فإننا في الواقع نشير إلى أن هذه البيانات تم تمريرها إلى هذه المجموعة من الفحص.
0.تم إرسال كتلة Layer2 مع جزء من حالة Layer2 إلى النواة. هذه البيانات هي جميع المعلومات المطلوبة لتنفيذ كتلة Layer2.
جزء من المحققين في النواة سيقومون بإعادة تنفيذ الكتلة Layer2 ومتابعة معالجة المهام المتعلقة بالإجماع.
يرجى ملاحظة أن جميع العمليات حتى الآن تتم خارج كتلة بولكا ووظيفة التحول الحالية. كل شيء يحدث داخل النواة وطبقة توفر البيانات.
من المحتوى أعلاه ، يمكننا مناقشة بعض العمليات التي يقوم بها بوكا:
أولاً ، من الخطوة 1 يمكننا أن نستنتج أن هناك طريقة تنفيذ جديدة في بولكا مختلفة عن وظيفة تحويل حالة سلسلة الكتل التقليدية. عادةً ما يتم تحديث حالة سلسلة الكتل الرئيسية عندما يقوم جميع المدققون بعمل معين. نطلق على هذا الحالة الداخل السلسلة (on-chain operation) وهذا هو ما يحدث في الخطوة 3. ومع ذلك ، يحدث الأمر الجديد داخل النواة (الخطوة 1) بشكل مختلف. نطلق على هذا الحساب الجديد لسلسلة الكتل الجديدة التي تقوم على النواة (in-core ution).
من النقطة 2 يمكننا استنتاج أن بولكا قدمت طبقة DA الأصلية لتوفير قابلية استخدام البيانات ، وأن Layer2 تستخدمها تلقائيًا لضمان توافر بيانات التنفيذ الخاصة بها على مدى فترة محددة. ومع ذلك ، فإن كتل البيانات التي يمكن نشرها على طبقة DA هي ثابتة ، وهي دائمًا بيانات البرهان المطلوبة لإعادة تنفيذ كتلة Layer2. بالإضافة إلى ذلك ، فإن شفرة parachain لم تقم بقراءة بيانات DA.
فهم المحتوى أعلاه هو أساس فهم JAM. يتم تلخيصها على النحو التالي:
جام
من خلال فهم الجزء السابق، يمكننا الانتقال بسلاسة إلى استعراض JAM.
JAM هو بروتوكول جديد مستوحى من بولكا ومتوافق تمامًا معه، مصمم ليحل محل سلسلة بولكا ويجعل الاستخدام الأساسي مفتوحًا تمامًا وغير مركزي.
تم بناء JAM على Polkadot2 ، ويهدف إلى جعل النواة الأساسية لـ Polkadot أكثر سهولة في الوصول إليها ، ولكن بطريقة أكثر مرونة وبدون قيود ثابتة مقارنةً بـ agile-coretime.
يتم ذلك أساسا من خلال تعريض المطورين لثلاثة مفاهيم أساسية رئيسية تم مناقشتها في الجزء الأمامي: وهي التنفيذ في السلسلة، والتنفيذ النواة الأساسي، وطبقة DA.
بمعنى آخر، في JAM، يمكن للمطورين أن يتعاملوا مع:
هذا هو وصف أساسي لبروتوكول JAM. لا داعي للكلام كثيرًا، لقد قمنا بتبسيط الأمور كثيرًا هنا، وقد يظل البروتوكول قيد التطور.
بعد فهم هذا الأساس، يمكننا الآن استكشاف بعض التفاصيل حول JAM في الفصول القادمة.
1 الخدمات والمهام العملية
في ظل خلفية JAM، يطلق على ما كان يسمى سابقًا Layer2 / parachain الآن اسم "الخدمة (Service)"، بينما يُطلق الآن على ما كان يسمى سابقًا كتلة / صفقة اسم "عنصر العمل (Work-Item)" أو "حزمة العمل (Work-Package)". على وجه الخصوص، ينتمي عنصر العمل إلى خدمة ما، في حين أن حزمة العمل هي مجموعة من عناصر العمل. تم تصميم هذه المصطلحات بشكل مقصود بأن تكون عامة بما فيه الكفاية لتغطية مجموعة متنوعة من الحالات الاستخدامية التي تتجاوز سلسلة الكتل / Layer2.
وصف الخدمة مكون من ثلاث نقاط دخول، حيث يكون اثنان منها fn refine() و fn accumulate() على التوالي. يصف الأول الخدمة التي تم تنفيذها في النواة، بينما يصف الثاني الخدمة التي تم تنفيذها داخل السلسلة.
وأخيراً، أسماء نقطتي الوصول هما أيضًا سبب تسمية البروتوكول بـ JAM (Join Accumulate Machine). Join يعني fn refine()، عندما تقوم جميع نوى بولكا بمعالجة الكمية الكبيرة من العمل المختلف للخدمات بشكل متوازٍ، فإن هذه المرحلة تسمى Join. بعد تصفية البيانات، تنتقل إلى المرحلة التالية. Accumulate تشير إلى العملية التي تتمثل في تجميع جميع النتائج المذكورة أعلاه في حالة JAM الرئيسية، أي التنفيذ داخل السلسلة.
يمكن تحديد عناصر العمل بدقة بما يتعلق بتنفيذها في النواة وداخل السلسلة وتحديد كيفية / ما إذا كان / من أين يتم قراءة وكتابة محتوى البحيرة البيانات الموزعة (Distributed Data Lake).
2 شبه متسقة
على الرغم من أنه يتم إرسال الرسائل دون أن يتم الانتظار للرد عليها بعد إرسالها، إلا أنه يتعين على المرء أن يراجع المعلومات المتاحة حول XCM (لغة الاتصال لشبكات الباراشاين المختارة من قبل بولكادوت) لفهم الاتصال الغير متزامن. (انظر للتفاصيل:)
الخاصية الغير متزامنة هي تجسيد لعدم التوافق في النظام، وهي عيب رئيسي في النظام المستمر (مثل بولكا 1 وبولكا 2 والبيئة الحالية للطبقة 2 لإيثيريوم).
ومع ذلك، كما هو موضح في الفقرة 2.4 من الكتاب الرمادي، فإن النظام الذي يحافظ دائمًا على تزامن كل مستأجر لديه، يمكن أيضًا أن يرتقي إلى مستوى معين دون التضحية بالشمولية أو الوصول أو المرونة. (للتفاصيل راجع:)
التزامن≈الاتساق||الكتابة الغير متزامنة≈عدم الاتساق
هذا هو مجال آخر تبرز فيه JAM: من خلال إدخال ميزات متعددة، أدى JAM إلى تحقيق حالة وسيطة جديدة وهي نظام شبه متسق. في هذا النظام، لديهم فرصة لخلق بيئة متسقة بين الأنظمة الفرعية التي تتواصل بشكل متكرر مع بعضها البعض، دون الحاجة إلى إجبار النظام بأكمله على البقاء متسقاً. وتلخص هذه الفكرة على أحسن وجه في مقابلة الدكتور غافين وود، مؤلف الكتاب الرمادي (لمزيد من التفاصيل، راجع الرابط التالي: _referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ).
طريقة أخرى لفهم بولكا / JAM هي أنها نظام مشاركة حيث يكون حدود هذه المشاركات متدفقة ومحددة ديناميكيًا.
بولكا دائمًا ما تكون مشاركة، وتكون متنوعة بالكامل.
الآن، سيتم تقسيمها وتشتيتها، ويمكن تحديد حدود هذه التقسيمات بمرونة، تماما كما قال غافين وود في تغريدته عن "نظام نصف الاتساق". (راجع: _src=twsrc%5Etfw)
السمات التي تجعل كل هذا ممكنًا تشمل:
زيارة تنفيذ نواة موازية وبدون حالة، حيث يمكن للخدمات المختلفة التفاعل بتزامن مع الخدمات الأخرى في نفس النواة وفي كتلة محددة فقط، وتنفيذ داخل السلسلة حيث يمكن للخدمات الوصول إلى نتائج جميع الخدمات عبر جميع النوى.
JAM لا تفرض تنفيذ أي جدول زمني خاص بالخدمة. يمكن للخدمات التي تتطلب اتصالًا متكررًا توفير حوافز اقتصادية لأجهزتها الفرز ، وإنشاء حزم عمل تحتوي على هذه الخدمات التي تتطلب اتصالًا متكررًا. هذا يتيح لهذه الخدمات أن تعمل في نفس النواة ، حيث يتم إجراء الاتصالات بينها كما لو كانت في بيئة متزامنة.
بالإضافة إلى ذلك ، يمكن لخدمة JAM الوصول إلى طبقة البيانات واستخدامها كطبقة بيانات مؤقتة ورخيصة للغاية. بمجرد وضع البيانات في DA ، ستنتشر في النهاية إلى جميع النوى ، ولكنها متاحة فورًا في نفس النواة. بالتالي ، يمكن لخدمة JAM الاستفادة من درجة أعلى من وصول البيانات عن طريق جدولة نفسها في نفس النواة في كتلة متتالية.
يجب ملاحظة أنه على الرغم من أن المحتوى أعلاه ممكن في JAM، إلا أنه ليس ملزمًا في طبقة البروتوكول. لذا، من المتوقع أن تكون بعض الواجهات غير متزامنة في نظرية، ولكن يمكن أن تظهر عملياً كمتزامنة من خلال التجربة العملية من خلال التجربة العملية. القسم التالي سيناقش CorePlay كمثال على ذلك.
3 كور بلاي
يقدم هذا القسم CorePlay، وهو فكرة تجريبية في بيئة JAM ويمكن وصفها بأنها نموذج جديد للبرمجة الذكية. في الوقت الحالي من كتابة هذا النص، لم يتم توضيح CorePlay بالتفصيل ولا يزال هو فكرة.
لفهم CorePlay ، نحتاج أولاً إلى تقديم الآلة الافتراضية التي اختارها JAM: PVM.
4 PVM
PVM هو تفاصيل مهمة في JAM و CorePlay. تفاصيل PVM على مستوى منخفض تتجاوز نطاق هذه المقالة، من الأفضل الرجوع إلى وصف الخبراء في الكتاب الأبيض. ومع ذلك، لاحتياجات هذه المقالة، نحن بحاجة فقط إلى شرح بعض خصائص PVM:
الأخير مهم بشكل خاص لـ CorePlay.
CorePlay هو مثال على إنشاء بيئة مرنة للعقود الذكية مزامنة وقابلة للتوسيع باستخدام لغة برمجة JAM. يوفر CorePlay واجهة برمجة غاية في المرونة. يُقترح نشر العقود الذكية القائمة على الممثل مباشرة على نواة JAM لتمكينها من الاستفادة من واجهة برمجة مزامنة حيث يمكن كتابة البرنامج بشكل عادي مثل fn main() والتواصل من خلال let_result=other_coreplay_actor(data).await؟. إذا كان other_coreplay_actor موجودًا على نواة JAM نفسها، فإن هذا الاستدعاء متزامن؛ وإذا كان على نواة أخرى، فسيتم تعليق الممثل واستئنافه في الكتلة التالية لـ JAM. يجعل ذلك ممكنًا بفضل خدمة JAM وجدولة مرنة، بالإضافة إلى خصائص PVM.
5 خدمة السلاسل الأساسية
أخيرًا، دعونا نلخص الأسباب الرئيسية التي تم ذكرها لجعل JAM متوافقًا تمامًا مع بولكا. المنتج الرئيسي لبولكا هو parachain الذي يعمل بطريقة الوقت الأساسية السريع، وهذا المنتج مستمر في JAM.
من المحتمل أن يُشار إلى الخدمة التي تم نشرها في JAM في وقت مبكر باسم CoreChains أو Parachains. ستسمح هذه الخدمة بتشغيل الـ parachains بنمط Polkadot -2 الحالية على JAM.
يمكن نشر خدمات إضافية على JAM ويمكن لخدمات CoreChains الحالية التواصل معها، ولكن منتجات بولكا الحالية ستظل قوية وفقط ستفتح أبوابًا جديدة لفرق Parachain الحالية.
附录：数据مشاركة
تناقش هذه المقالة معظم المحتوى من منظور المشاركة القابلة للتوسع. يمكننا أيضًا التفكير في نفس المشكلة من منظور البيانات. من المثير للاهتمام أننا نجد أن هذا مشابه لحالة الاتساق الجزئي المذكورة سابقًا: في النظرية ، يكون النظام المتسق الكامل أفضل ، ولكن غير قابل للتوسع ؛ يكون النظام غير المتساق الكامل قابل للتوسع ، ولكنه غير مثالي ، وقد أقترح JAM بنموذجه الجزئي الاتساق فرصة جديدة.
نظام متطابق تمامًا: هذا هو ما نراه على منصة العقود الذكية المتزامنة تمامًا مثل سولانا أو تلك المنصات الجريئة التي تنتشر فقط على طبقة إيثريوم Layer1. يتم تخزين جميع بيانات التطبيق في سلسلة الكتل ويمكن الوصول إليها بسهولة من جميع التطبيقات الأخرى. إنه خاصية مثالية برمجيًا ولكنها غير قابلة للتوسعة.
نظام غير متسق : يتم حفظ بيانات التطبيق في الطبقة 1 الخارجية، بالإضافة إلى مشاركة منفصلة ومختلفة. قابل للتوسيع بشكل كبير، ولكنه غير فعال من حيث القابلية للتركيب. ينطبق نموذج Rollup لـ Polkadot وEthereum في هذا الحال.
JAM بالإضافة إلى توفير الوظائف المذكورة أعلاه، يسمح أيضًا للمطورين بنشر أي بيانات إلى طبقة JAM DA، وهذا بشكل ما يعتبر منطقة وسطى بين البيانات داخل السلسلة والبيانات خارج السلسلة. يمكن كتابة تطبيقات جديدة تستخدم بيانات DA بشكل كبير، مع الاحتفاظ فقط بالبيانات الحاسمة بشكل مطول في حالة JAM.
الملحق: خريطة مساحة التوسع
يعيد هذا الجزء تفسيرنا لرؤيتنا لمجال قابلية التوسع في تقنية بلوكتشين. ويتم ذلك أيضًا في الكتاب الرمادي، وهنا يتم تقديم نسخة أكثر اختصارًا.
قابلية توسيع سلسلة الكتل تتبع إلى حد كبير الأساليب المستخدمة في أنظمة التوزيع التقليدية: التوسيع الرأسي والتوسيع الأفقي.
التوسع الصعودي هو العمل الذي يقوم به منصات مثل سولانا. من خلال تحسين الأداء الشديد للأجهزة والبرمجيات لتحقيق أقصى قدر من الإنتاجية.
التوسع هو الاستراتيجية التي تستخدمها Ethereum و Polkadot: تقليل مقدار العمل الذي يجب القيام به للجميع. في النظام الموزع التقليدي ، يتم تحقيق ذلك عن طريق إضافة المزيد من آلات النسخ المتماثل. في سلسلة كتلة ، "الكمبيوتر" عبارة عن مجموعة من المدققون للشبكة بأكملها. من خلال توزيع العمل بينهم (كما يفعل ELVES) ، أو عن طريق تقليل مسؤولياتهم بتفاؤل (كما تفعل Rollups المتفائلة) ، قمنا بتقليل عبء العمل على مجموعة المدققون بأكملها ، مما سمح للنظام بالتوسع.
في سلسلة الكتل، التوسع الخارجي يشبه "تقليل عدد الآلات اللازمة لتنفيذ جميع العمليات".
يتم تلخيصها كما يلي:
الملحق: نفس الأجهزة ، تحديث النواة
هذا القسم مستوحى من المقارنة التي قدمها روب هابيرماير في Sub02023: Polkadot: Kernel/Userland|Sub02023-YouTube (للمزيد من التفاصيل: )، ويظهر JAM كترقية لـ Polkadot: تحديث النواة على نفس الأجهزة.
في الحاسوب النموذجي، يمكننا تقسيم الكومة بأكملها إلى ثلاثة أجزاء:
الأجهزة
النواة
مساحة المستخدم
في بولكا، كانت الأجهزة، أي الجوهر الذي يوفر الحوسبة وتوفر البيانات، دائمًا في صميم الأمور، كما هو موضح في الأساس.
في بولكا ، النواة في الواقع[9]حتى الآن ، تم تضمين جزئين:
1.parachain（Parachains）بروتوكول: وسيلة للتفاعل المباشر والثابت مع النواة.
كلاهما موجود في سلسلة Relaي على Polkadot.
تطبيقات المساحة المستخدم هي مثيلات البنات الجانبية وعملاتها الأصلية والمحتوى الآخر المبني عليها.
يمكننا تصور هذه العملية على النحو التالي:
ومن المتوقع دائمًا أن تقوم بولكا بنقل المزيد من الوظائف الأساسية إلى فئة مستخدمين فريدة - parachain. هذا هو بالضبط الهدف الذي تسعى إليه Minimal Relay RFC لتحقيقه. (يرجى الرجوع إلى: )
هذا يعني أن سلسلة ريليه بولكا تعالج فقط بروتوكول الباراشين، مما يقلل إلى حد ما من المساحة النواة.
عندما تتم هذه الهيكلية، سيكون من الأسهل تصور كيفية ترحيل JAM. سيقلل JAM بشكل كبير من مساحة نواة Polkadot ويجعلها أكثر قابلية للتطبيق. بالإضافة إلى ذلك، سيتم نقل بروتوكول Parachains إلى مساحة المستخدم، لأن هذه هي واحدة من الطرق القليلة التي يمكن فيها كتابة التطبيقات على نفس النواة (الأجهزة) والنواة (JAM).
هذا يوضح مرة أخرى لماذا JAM هو بديل فقط لسلسلة بولكا الرئيسية وليس بديلًا للشبكة الفرعية.
بمعنى آخر، يمكننا أن نعتبر ترحيل JAM كترقية للنواة. يبقى الأجهزة الأساسية كما هي، ويتم نقل معظم محتوى النواة القديمة إلى مساحة المستخدم لتبسيط النظام.
للمشاركة في مناقشة هذه المقالة ، يرجى نشر آرائك في المنتدى:
بالنسبة لكيفية الانضمام إلى مناقشات المنتدى ، يرجى الاطلاع على دليل استخدام منتدى بولكا الذي قدمناه:
《كيفية المشاركة في مناقشات بولكا: دليل استخدام منتديات بولكا الرسمية》