التالي هو شرح مفصل لـ Polkadot1، Polkadot2، وكيف تطورت إلى JAM. (لمزيد من التفاصيل، انظر: https://www.navalmanack.com/almanack-of-naval-ravikant/how-to-think-clearly. يهدف هذا المقال إلى القراء الفنيين، خاصة أولئك الذين قد لا يكونون عميقين في معرفة بولكادوت ولكن لديهم بعض المعرفة بأنظمة البلوكشين وربما يكونون على دراية بالتقنيات من النظم البيئية الأخرى.
أعتقد أن هذا المقال يعتبر مقدمة جيدة لقراءة JAM Gray Paper. (لمزيد من التفاصيل، انظر: https://graypaper.com/)

المعرفة الخلفية

يفترض هذا المقال أن القارئ ملم بالمفاهيم التالية:

• وصف البلوكشين كوظيفة انتقال الحالة.
• فهم ما يعنيه "الحالة". (لمزيد من التفاصيل، انظر: https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/blockchain_state_machines/index.html)
• الأمان الاقتصادي ودليل المصالحة. (لمزيد من التفاصيل، انظر: https://polkadot-blockchain-academy.github.io/pba-book/economics/economics-of-polkadot/page.html#staking-concept،https://www.youtube.com/watch?v=suyram9vaFc)

مقدمة: بولكادوت1

دعونا نعيد زيارة أكثر الميزات الابتكارية لـPolkadot1 أولاً.

الجوانب الاجتماعية:

• بولكادوت هي منظمة لامركزية ضخمة ذاتية التنظيم (DAO). تقوم الشبكة بتنفيذ حكم كامل على السلسلة، بما في ذلك التحديثات البرمجية دون فصل.
• اعترفت SEC بـ DOT كبرمجيات، وليس أمانًا. (لمزيد من التفاصيل، انظر: https://polkadot.com/newsroom/press-releases/web3-foundation-announces-polkadot-blockchains-native-token-dot-has-morphed-and-is-software-not-a-security)
• معظم أعمال التطوير على الشبكة تتم من خلال فريق بولكادوت Fellowship (لمزيد من التفاصيل، انظر:https://polkadot-fellows.github.io/dashboard/)، بدلاً من Parity Technologies، الشركة التي تدعم المشروع مالياًhttps://www.parity.io/.

الجوانب التقنية:

• قام بولكادوت بتنفيذ أمان مشترك وتنفيذ مشتت.
• استخدام بروتوكول ميتاباسد على أساس WASM (لمزيد من التفاصيل، انظر: https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/wasm_meta_protocol/index.html) ، يتم تخزين رمز blockchain في الولاية ك bytecode. يسمح هذا بحدوث معظم الترقيات بدون شوكات ويتيح التجزئة غير المتجانسة. (انظر الأقسام ذات الصلة للحصول على مزيد من المعلومات حول "التجزئة غير المتجانسة.")

التنفيذ المتشظي: النقاط الرئيسية

حاليا ، نحن نناقش شبكة الطبقة 1 التي تستضيف شبكات "blockchain" أخرى من الطبقة 2 ، على غرار Polkadot و Ethereum. لذلك ، يمكن استخدام المصطلحين Layer 2 و Parachain بالتبادل.

يمكن تصوير القضية الأساسية لقابلية توسع سلسلة الكتل على أنها: هناك مجموعة من المحققين الذين، باستخدام العمليات المشفرة لدليل الحصة، يضمنون أن تنفيذ بعض الشيفرات موثوق به. بشكل افتراضي، يتعين على هؤلاء المحققين إعادة تنفيذ كل عمل من أعمال الآخرين. طالما أننا نفرض أن جميع المحققين يقومون دائمًا بإعادة تنفيذ كل شيء، يظل النظام بأكمله غير قابل للتوسيع.

يرجى ملاحظة أنه طالما يبقى مبدأ الإعادة التنفيذية المطلقة ثابتًا، فإن زيادة عدد المدققين في هذا النموذج لا تحسن فعليًا إنتاجية النظام.

هذا يظهر سلسلة كتل أحادية (بدلاً من مقسمة). جميع المحققين في الشبكة يعالجون المدخلات (أي الكتل) واحدة تلو الأخرى. في مثل هذا النظام، إذا أراد الطبقة 1 استضافة المزيد من الطبقات 2، فعلى جميع المحققين إعادة تنفيذ جميع أعمال الطبقات 2. ومن الواضح أن هذه الطريقة لا توسع بشكل كافي.

تعالج عمليات التجميع المتفائلة هذه المشكلة عن طريق إعادة التنفيذ فقط (إثباتات الاحتيال) عند الادعاء بالاحتيال. تعالج مجموعة التحديثات المستندة إلى SNARK هذه المشكلة من خلال الاستفادة من حقيقة أن تكلفة التحقق من صحة براهين SNARK أقل بكثير من تكلفة إنشائها ، مما يسمح لجميع المدققين بالتحقق بكفاءة من براهين SNARK. لمزيد من التفاصيل ، راجع "الملحق: مخطط مساحة قابلية التوسع".

حل مباشر للتجزئة هو تقسيم مجموعة المحققين إلى مجموعات فرعية أصغر وإعادة تنفيذ كتلة الطبقة 2. ما هي المشاكل مع هذا النهج؟ نحن نجزئ أساسا كل من التنفيذ والأمان الاقتصادي للشبكة. يحتوي هذا الحل في الطبقة 2 على أمان أقل بالمقارنة مع الطبقة 1، ويقل أمانه بشكل أكبر كلما قسمنا مجموعة المحققين إلى مزيد من الأجزاء.

على عكس تجميعات المتفائلة، حيث لا يمكن تجنب تكاليف إعادة التنفيذ دائمًا، تم تصميم Polkadot بتنفيذ مقسم في الاعتبار. يسمح بأن يقوم جزء من المحققين بإعادة تنفيذ كتلة Layer 2 مع توفير ما يكفي من الأدلة الكربتواقتصادية للشبكة بأكملها لإثبات أن كتلة Layer 2 آمنة تمامًا كما لو قام مجموع المحققين بإعادة تنفيذها. يتم تحقيق ذلك من خلال آلية جديدة (وتم تشكيلها مؤخرًا) تعرف بـ ELVES. (لمزيد من التفاصيل، انظر: https://eprint.iacr.org/2024/961)

باختصار، يمكن اعتبار ELVES آلية 'تجميع مشبوهة'. من خلال عدة جولات من المحققين النشطين الاستعلام بنشاط عن المحققين الآخرين بشأن ما إذا كان كتلة Layer 2 معينة صالحة، يمكننا تأكيد صحة الكتلة بإحتمالية عالية. في حالة وجود أي نزاع، يتم سريعاً إشراك مجموعة المحققين بالكامل. شرح مؤسس بولكادوت روب هابرماير هذا بالتفصيل في مقال. (لمزيد من التفاصيل، انظر: https://polkadot.com/blog/polkadot-v1-0-sharding-and-economic-security#approval-checking-and-finality)

تمكن ELVES Polkadot من الحصول على تنفيذ مجزأ وأمان مشترك، خاصيتان كان يُعتقد سابقًا أنهما يتنافيان. هذا هو الإنجاز التقني الأساسي لـ Polkadot1 فيما يتعلق بقابلية التوسع.

الآن، دعونا نتقدم مع المقارنة "الأساسية". يُشبه سلسلة الكتل التنفيذية المجزأة إلى حد كبير وحدة المعالجة المركزية: تمامًا كما يمكن لوحدة المعالجة المركزية أن تحتوي على عدة أنوية تنفيذ تعليمات بشكل متوازي، يمكن لـ Polkadot معالجة كتلة الطبقة 2 بشكل متوازي. هذا هو السبب في تسمية الطبقة 2 على Polkadot بـ parachain، والبيئة التي يقوم فيها مجموعات فرعية من المحققين بإعادة تنفيذ كتلة واحدة من الطبقة 2 تُسمى "نواة". يمكن تجريد كل نواة على أنها "مجموعة من المحققين المتعاونين".

يمكنك التفكير في سلسلة كتل موحدة كمعالجة كتلة واحدة في كل مرة، بينما تقوم بولكادوت بمعالجة كتلة سلسلة الريلي وكتلة باراشين لكل نواة في نفس الفترة الزمنية.

تباين

حتى الآن، لقد ناقشنا فقط قابلية التوسيع والتنفيذ المجزأ الذي يقدمه بولكادوت. من المهم أن نلاحظ أن كل من شرائح بولكادوت هي في الواقع تطبيق مختلف تمامًا. يتم تحقيق ذلك من خلال الميتابروتوكول المخزن كبايت كود: بروتوكول يخزن تعريف سلسلة الكتل نفسها كبايت كود في حالته. في بولكادوت 1.0، يتم استخدام WASM كبايت كود المفضل، بينما في JAM، يتم اعتماد PVM/RISC-V.

هذا هو السبب في أن Polkadot يُشار إليه باسم سلسلة كتل متنوعة ومفتشة. (لمزيد من التفاصيل، انظر: https://x.com/kianenigma/status/1790763921600606259) كل طبقة 2 هي تطبيق مختلف تمامًا.

Polkadot2

أحد الجوانب المهمة في Polkadot2 هو جعل استخدام النوى أكثر مرونة. في نموذج Polkadot الأصلي ، تراوحت فترات التأجير الأساسية من 6 أشهر إلى 2 سنوات ، والتي تناسب الشركات الغنية بالموارد ولكنها كانت أقل جدوى للفرق الأصغر. تسمى الميزة التي تسمح باستخدام نوى Polkadot بشكل أكثر مرونة "Agile Coretime". (لمزيد من التفاصيل، راجع: https://polkadot.com/agile-coretime) في هذا الوضع، يمكن أن تكون شروط الإيجار الأساسية قصيرة بما فيه الكفاية لمدة كتلة واحدة أو طويلة لشهر، مع حد أقصى للسعر لأولئك الذين يرغبون في التأجير لفترات أطول.

يتم الكشف تدريجيا عن الميزات الأخرى لـ Polkadot 2 كما يسير حوارنا، لذلك ليس هناك حاجة للتفصيل في هذا المجال.

العمليات داخل النواة مقابل العمليات على السلسلة

لفهم JAM، من المهم أولاً فهم ما يحدث عندما يدخل كتلة Layer 2 النواة Polkadot. التالي هو شرح مبسط.

تذكر أن النواة تتكون أساسًا من مجموعة من المحققين. لذلك عندما نقول "تم إرسال البيانات إلى النواة"، يعني أن البيانات تم تمريرها إلى هذه المجموعة من المحققين.

1. يتم إرسال كتلة الطبقة 2، جنبًا إلى جزء من حالة تلك الطبقة 2، إلى النواة. تحتوي هذه البيانات على جميع المعلومات اللازمة لتنفيذ كتلة الطبقة 2.

2. سيقوم جزء من المحققين الأساسيين بإعادة تنفيذ كتلة الطبقة 2 ومواصلة المهام المتعلقة بالتوافق.

3. يقدم هؤلاء المحققون الأساسيون البيانات المعاد تنفيذها للمحققين الآخرين خارج النواة. وفقًا لقواعد ELVES، قد يقرر هؤلاء المحققون ما إذا كانوا سيعيدون تنفيذ كتلة الطبقة 2، والتي تحتاج إلى هذه البيانات للقيام بذلك.

من المهم أن نلاحظ أنه، حتى الآن، جميع هذه العمليات تحدث خارج كتلة بولكادوت الرئيسية ووظيفة انتقال الحالة. كل شيء يحدث داخل النواة وطبقة توافر البيانات.

1. أخيرًا، يصبح جزء صغير من أحدث حالة Layer 2 مرئيًا على سلسلة البيانات الأساسية لـ Polkadot. على عكس العمليات السابقة، هذه الخطوة أرخص بكثير من إعادة تنفيذ كتلة Layer 2، وتؤثر في حالة Polkadot الرئيسية. يُعرض في كتلة Polkadot ويتم تنفيذه بواسطة جميع محققي Polkadot.

من هنا، يمكننا استكشاف بعض العمليات الرئيسية التي يقوم بتنفيذها بولكادوت:

• من الخطوة 1، يمكننا الاستنتاج بأن Polkadot قد قدم نوعًا جديدًا من التنفيذ، مختلفًا عن وظائف تحويل حالة سلسلة الكتل التقليدية. عادةً، عندما يقوم جميع محققي الشبكة بأداء مهمة ما، يتم تحديث حالة سلسلة الكتل الرئيسية. هذا ما نسميهتنفيذ على السلسلة, وهذا ما يحدث في الخطوة 3. ومع ذلك، فإن ما يحدث داخل النواة (الخطوة 1) مختلف. يُشار إلى هذا الشكل الجديد من الحسابات في سلسلة الكتل بأنهتنفيذ النواة.
• من الخطوة 2، نستنتج أن بولكادوت لديها توافر البيانات (DA)الطبقة، وتستخدم الطبقات 2 تلقائيًا لضمان بقاء أدلة تنفيذها متاحة لفترة معينة. ومع ذلك، فإن كتل البيانات التي يمكن نشرها إلى طبقة DA ثابتة، تحتوي فقط على الأدلة المطلوبة لإعادة تنفيذ الطبقة 2. علاوة على ذلك، فإن كود الباراشين لا يقرأ بيانات طبقة DA.

فهم هذا يشكل أساس فهم JAM. إليكم ملخص:

• التنفيذ في النواةيشير إلى العمليات التي تحدث داخل النواة. هذه العمليات غنية وقابلة للتوسيع، ومؤمنة من خلال الاقتصاد الرمزي وELVES، مما يوفر نفس الأمان كتنفيذ السلسلة.
• تنفيذ على السلسلة: يشير إلى العمليات التي يقوم بها جميع المحققين. هذه مضمونة اقتصاديًا بأنها آمنة بشكل افتراضي، ولكنها تكلف أكثر وتكون مقيدة أكثر نظرًا لأن الجميع يقوم بأداء جميع المهام.
• توافر البيانات: يشير إلى قدرة محققي Polkadot على ضمان توفر بيانات معينة لفترة زمنية معينة وتوفيرها لمحققين آخرين.

JAM

بفهمنا هذا، يمكننا الآن تقديم JAM.

JAM هو بروتوكول جديد مستوحى من تصميم Polkadot ومتوافق تمامًا معه، بهدف استبدال سلسلة البيانات الأساسية لـ Polkadot وجعل استخدام النواة متمامًا لامركزي وغير مقيد.

تم بناء JAM على Polkadot 2، حيث تسعى إلى جعل نشر الطبقة 2 على النواة أكثر إمكانية، مما يوفر مرونة أكبر حتى من نموذج agile-coretime.

• يتيح Polkadot 2 نشر الطبقة 2 على النواة بشكل أكثر دينامية.
• JAM تهدف إلى السماح لأي تطبيق بأن يُنشَر على نواة بولكادوت، حتى لو لم تكن تلك التطبيقات مُنظمة مثل سلاسل كتلية أو الطبقة 2.

يتم تحقيق هذا بشكل رئيسي عن طريق تعريض العناصر الأساسية الثلاث المناقشة سابقًا للمطورين: التنفيذ على السلسلة، التنفيذ في النواة، وطبقة DA.

بمعنى آخر، في JAM، يمكن للمطورين:

• برمجة المهام داخل النواة وفي السلسلة.
• اقرأ من واكتب إلى طبقة DA الخاصة بـ Polkadot مع البيانات التعسفية.

هذا يشكل نظرة عامة أساسية على أهداف JAM. من الطبيعي أن الكثير من هذا قد تم تبسيطه، ومن المحتمل أن يتطور البروتوكول بشكل أكبر.

مع هذا الفهم الأساسي، يمكننا الآن الانغماس في بعض من التفاصيل حول JAM في الفصول التالية.

الخدمات وعناصر العمل

في JAM، ما كان يُشار إليه سابقًا بأنه طبقة ٢ أو شبكات فرعية الآن تُسمىالخدمات, وما كان يُشار إليه سابقًا بأنه كتل أو معاملات يُطلق عليه الآن عناصر العملأوحزم العملعلى وجه التحديد، ينتمي عنصر العمل إلى خدمة، وحزمة العمل هي مجموعة من عناصر العمل. تم اختيار هذه المصطلحات بشكل متعمد بحيث تغطي حالات الاستخدام خارج سيناريوهات blockchain/Layer 2.

يتم وصف الخدمة بثلاث نقاط دخول، اثنان منها هما fn refine() و fn accumulate(). الأول يصف ما تقوم به الخدمة أثناء التنفيذ في النواة، والثاني يصف ما تقوم به أثناء التنفيذ على السلسلة الرئيسية.

أخيرًا، أسماء نقاط الدخول هذه هي السبب في تسمية البروتوكول بـ JAM (انضم تراكم آلة).انضميشير إلىتنقية الأصول, الذي هو المرحلة التي تقوم فيها جميع أنوية بولكادوت بمعالجة حجم كبير من العمل بشكل متوازي عبر خدمات مختلفة. بعد معالجة البيانات، تنتقل إلى المرحلة التالية.تراكميشير إلى عملية تجميع جميع هذه النتائج في الحالة الرئيسية JAM الرئيسية، والتي تحدث خلال مرحلة التنفيذ على السلسلة الرئيسية.

يمكن لعناصر العمل تحديد بدقة الشيفرة التي ينفذونها في النواة وعلى السلسلة، بالإضافة إلى كيفية قراءة أو كتابة المحتوى في بحيرة البيانات الموزعة ومن أين وإذا كانوا يفعلون ذلك.

النصف الاتساق

استعراض الوثائق الحالية حول XCM (لغة بولكادوت المختارة لتواصل الباراشين)، كل التواصل غير متزامن (لمزيد من التفاصيل، انظرهنا. هذا يعني أنه بمجرد إرسال الرسالة، لا يمكنك الانتظار للحصول على رد عليها. التواصل غير المتزامن هو أحد أعراض عدم اتساق النظام، وأحد العيوب الأساسية للأنظمة المقسمة بشكل دائم مثل بولكادوت 1، بولكادوت 2، والبيئات الطبقية 2 الحالية لإثيريوم.

ومع ذلك ، كما هو موضح في القسم 2.4 منالورقة الرمادية, نظام متسق بالكامل يبقى متزامنًا لجميع المستأجرين فقط يمكن أن يتوسع إلى درجة معينة دون التضحية بالجميعية أو الوصول أو المرونة.

• متزامن ≈ التناسق || غير متزامن ≈ عدم التناسق

هنا حيث يتميز JAM: من خلال إدخال العديد من الميزات، يحقق JAM حالة وسيطة جديدة تُعرف باسم نظام شبه متسق. في هذا النظام، يمكن للأنظمة الفرعية التي تتواصل بشكل متكرر إنشاء بيئة متسقة مع بعضها البعض، دون إجبار النظام بأكمله على البقاء متسقًا. وقد وُصِف هذا بشكل أفضل من قبل الدكتور غافين وود، مؤلف الكتيب الرمادي، في مقابلة: https://www.youtube.com/watch?t=1378&v=O3kRAVBTkfs&embeds_referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ

طريقة أخرى لفهم هذا هو عن طريق النظر إلى بولكادوت/JAM كنظام مجزأ، حيث تكون حدود هذه الشظايا سائلة ومحددة ديناميكيًا.

لقد كان بولكادوت دائمًا مقسمًا ومتنوعًا بشكل كامل.

الآن، لم يعد الأمر مجزأً ومتنوعًا فحسب، بل يمكن تحديد حدود هذه الشرائح بمرونة - ما يشير جافين وود إليه بأنه نظام "شبه متسق" في تغريداته والكتيب الرمادي. (يرجى الرجوع إلى: https://x.com/gavofyork?ref_src=twsrc%5Etfw،https://graypaper.com/)

العديد من الميزات تجعل هذه الحالة شبه الثابتة ممكنة:

1. الوصول إلى التنفيذ اللاحالي المتوازي في النواة، حيث يمكن للخدمات المختلفة التفاعل فقط بشكل متزامن مع الخدمات الأخرى ضمن نفس النواة والكتلة المحددة، بالإضافة إلى التنفيذ على السلسلة، حيث يمكن للخدمات الوصول إلى النتائج من جميع الخدمات عبر جميع النوى.
2. JAM لا تفرض أي جدول زمني محدد للخدمات. يمكن للخدمات التي تتواصل بشكل متكرر توفير حوافز اقتصادية لجدولي عملها لإنشاء حزم عمل تحتوي على هذه الخدمات التي تتواصل بانتظام. يتيح ذلك لهذه الخدمات العمل ضمن نفس النواة، مما يجعل تفاعلاتها تبدو متزامنة، على الرغم من أنها موزعة.
3. بالإضافة إلى ذلك، يمكن لخدمات JAM الوصول إلى طبقة DA واستخدامها كطبقة بيانات مؤقتة وفعالة من حيث التكلفة للغاية. بمجرد وضع البيانات في DA، ينتشر في النهاية إلى جميع النوى ولكنه متاح على الفور ضمن نفس النواة. لذلك، يمكن لخدمات JAM تحقيق درجة أعلى من الوصول إلى البيانات عن طريق جدولة أنفسها ضمن نفس النواة عبر الكتل المتتالية.

من المهم أن نلاحظ أنه في حين أن هذه القدرات ممكنة داخل JAM، إلا أنها ليست مفروضة على مستوى البروتوكول. ونتيجة لذلك، قد تكون بعض الواجهات غير متزامنة نظريًا ولكن يمكن أن تعمل بشكل متزامن في الممارسة بسبب التجريدات المعقدة والحوافز. CorePlay، الذي سيتم مناقشته في القسم التالي، هو مثال على هذه الظاهرة.

كوربلاي

تقدم هذا القسم CorePlay، وهو مفهوم تجريبي في بيئة JAM يمكن وصفه بأنه نموذج جديد لبرمجة العقود الذكية. حتى الآن من وقت كتابة هذا، لم يتم تحديد CorePlay بشكل كامل ويظل فكرة محل تكهنات.

لفهم CorePlay، نحتاج أولاً إلى تقديم الجهاز الظاهري (VM) الذي اختارته JAM: PVM.

PVM

PVM هو تفاصيل رئيسية في كل من JAM و CorePlay. تفاصيل مستوى أدنى من PVM تتجاوز نطاق هذا الوثيقة ويمكن تفسيرها بشكل أفضل من قبل خبراء المجال في Graypaper. ومع ذلك، لهذا التفسير، سنسلط الضوء على بعض سمات PVM الرئيسية:

• عداد فعال
• القدرة على إيقاف التنفيذ واستئنافه

الأخيرة مهمة بشكل خاص لـ CorePlay.

كوربلاي هو مثال على كيف يمكن استخدام المبادئ الأساسية القابلة للتكيف من جام لإنشاء بيئة عقد ذكي متزامنة وقابلة للتوسيع مع واجهة برمجة مرنة للغاية. يقترح كوربلاي أن يتم نشر العقود الذكية القائمة على الممثل مباشرةً على نوى جام، مما يتيح لها الاستفادة من واجهات البرمجة المتزامنة. يمكن للمطورين كتابة العقود الذكية كما لو كانت وظائف fn main() بسيطة، باستخدام تعبيرات مثل اسمح بـالنتيجة = other_coreplay_actor(data).await?للتواصل. إذاممثل آخر لشركة كوربلايعلى نفس JAM نواة في نفس الكتلة، هذا النداء متزامن. إذا كان على نواة أخرى، سيتم إيقاف الممثل واستئنافه في كتلة JAM لاحقة. يتم ذلك بواسطة خدمات JAM وجدولة مرنة وقدرات PVM.

خدمة CoreChains

أخيرًا، دعونا نلخص السبب الرئيسي الذي يجعل JAM متوافقًا تمامًا مع Polkadot. المنتج الرئيسي لـ Polkadot هو الباراشين المرن الأساسي الذي يستمر في JAM. من المحتمل أن تُشار إلى أوائل الخدمات المنشورة في JAM على أنها CoreChains أو Parachains، مما يتيح لباراشينات Polkadot-2 الحالية العمل على JAM.

يمكن نشر خدمات إضافية على JAM، ويمكن لخدمة CoreChains الحالية التواصل معها. ومع ذلك، ستظل منتجات Polkadot الحالية قوية، مما يفتح ببساطة أبوابًا جديدة لفرق الباراشين الحالية.

الملحق: تجزئة البيانات

معظم هذا المستند يناقش قابلية التوسع من وجهة نظر تقسيم التنفيذ. ومع ذلك، يمكننا أيضًا دراسة هذه المسألة من وجهة نظر تقسيم البيانات. ومن المثير للاهتمام أن نجد أن هذا يشبه نموذج الاستقرار النصفي المذكور سابقًا. في المبدأ، النظام السلس متفوق ولكن غير قابل للتوسيع، بينما النظام غير المتسق بشكل كامل يتوسع بشكل جيد ولكنه غير مثلى. JAM، مع نموذجه النصفي المتسق، يقدم إمكانية جديدة.

• أنظمة متسقة تماما: هذه هي المنصات حيث يتم مزامنة كل شيء، مثل Solana أو تلك التي تم نشرها حصريًا على طبقة Ethereum Layer 1. يتم تخزين بيانات التطبيق على سلسلة الكتل ويمكن الوصول إليها بسهولة من قبل جميع التطبيقات الأخرى. هذا مثالي من وجهة نظر القابلية للبرمجة ولكنه ليس قابلًا للتوسيع.
• أنظمة غير متناسقة: تم تخزين بيانات التطبيق خارج الطبقة 1 أو في شظايا معزولة مختلفة. هذا قابل للتوسيع بشكل كبير ولكن يؤدي إلى أداء ضعيف من حيث التركيب. تندرج نماذج Polkadot و Ethereum's rollup تحت هذا الفئة.

تقدم JAM شيئًا يتجاوز هذين الخيارين: فهي تسمح للمطورين بنشر البيانات التعسفية إلى طبقة JAM DA، التي تعتبر نقطة وسيطة بين بيانات السلسلة وبيانات السلسلة الخارجية. يمكن بناء تطبيقات جديدة تستغل طبقة الـ DA لمعظم بياناتها، مع الاحتفاظ فقط بالبيانات الحرجة للغاية في حالة JAM.

الملحق: منظر القابلية للتوسع

تعود هذا القسم إلى منظورنا حول قابلية توسع بلوكشين، التي تمت مناقشتها أيضًا في الكتاب الرمادي، على الرغم من تقديمها هنا بشكل أكثر اختصارًا.

توسع البلوكشين يتبع بشكل كبير الأساليب التقليدية من الأنظمة الموزعة: التوسع الرأسي والتوسع الأفقي.

التوسيع العمودي هو ما تركز عليه منصات مثل سولانا، مما يزيد من الإنتاجية عن طريق تحسين الرمز والأجهزة إلى حدودها.

التوسع الأفقي هو الاستراتيجية التي اعتمدتها Ethereum و Polkadot: تقليل عبء العمل الذي يحتاج كل مشارك إلى التعامل معه. في الأنظمة الموزعة التقليدية ، يتم تحقيق ذلك عن طريق إضافة المزيد من آلات النسخ المتماثلة. في blockchain ، "الكمبيوتر" هو شبكة كاملة من المدققين. من خلال توزيع المهام فيما بينهم (كما يفعل ELVES) أو تقليل مسؤولياتهم بتفاؤل (كما هو الحال في Optimistic Rollups) ، فإننا نقلل من عبء العمل لمجموعة المدققين بأكملها ، وبالتالي تحقيق القياس الأفقي.

في تقنية البلوكشين، يمكن تشبيه التوسيع الأفقي إلى "تقليل عدد الآلات التي تحتاج إلى أداء جميع العمليات".

في الختام:

1. تحجيم عمودي: أداء عالي للأجهزة + تحسين سلاسل الكتل الأحادية.
2. التوسيع الأفقي:
   • تكديس متفائل
   • التجميعات القائمة على SNARK
   • الجانب: لفات Polkadot الساخرة

الملحق: نفس الأجهزة، ترقية النواة

تستند هذا القسم إلى تشبيه روب هابرماير من Sub0 2023: بولكادوت: Kernel/Userland | Sub0 2023 - يوتيوب (انظر:https://www.youtube.com/watch?v=15aXYvVMxlw)، عرض JAM كترقية لـ Polkadot: تحديث للنواة على نفس الأجهزة.

في جهاز الكمبيوتر النموذجي، يمكننا تقسيم الكومة بأكملها إلى ثلاثة أجزاء:

1. الأجهزة العتادية
2. نواة
3. مساحة المستخدم

في بولكادوت، العتاد - البنية الأساسية التي توفر الحوسبة وتوفر البيانات - كان دائمًا النوى، كما ذكر سابقًا.

في بولكادوت، كانت النواة حتى الآن تتألف من جزأين رئيسيين:

1. البروتوكولات الباراشينز: وسيلة ثابتة ومتعصبة لاستخدام النوى.
2. مجموعة من وظائف مستوى منخفض, مثل رمز DOT وقابليته للتحويل والرهان والحوكمة، إلخ.

كلا هذه موجودة في سلسلة الريليه لـ Polkadot.

تطبيقات مساحة المستخدم، من ناحية أخرى، هي الباراتشين ذاتها، وحصريتها الرموز، وأي شيء يُبنى على أساسها.

يمكننا تصور هذه العملية على النحو التالي:

كان لدى بولكادوت رؤية طويلة المدى لنقل المزيد من وظائف النواة إلى مستخدميها الأساسيين - الباراشين. هذا هو بالضبط هدف الحد الأدنى لبروتوكول الإرسال. (لمزيد من التفاصيل، انظر:الحد الأدنى لرابط RFC)

هذا يعني أن سلسلة البيانات الفرعية لـ Polkadot ستتولى فقط توفير بروتوكول الباراشين، مما يقلل من مساحة النواة إلى حد ما.

بمجرد تنفيذ هذه البنية، سيكون من الأسهل تصور كيف ستبدو عملية ترحيل JAM. سيقلل JAM بشكل كبير من مساحة نواة Polkadot، مما يجعلها أكثر تنوعًا. بالإضافة إلى ذلك، ستنتقل بروتوكول Parachains إلى مساحة المستخدم، حيث أنه أحد الطرق القليلة لبناء التطبيقات على نفس النواة (الأجهزة) ونواة (JAM) نفسها.

هذا أيضًا يعزز السبب في أن JAM هو بديل لسلسلة الريلي بولكادوت، وليس للمظلات الجوية.

بمعنى آخر، يمكننا عرض ترحيل JAM كترقية للنواة. يبقى الأجهزة الأساسية دون تغيير، ويتم نقل الكثير من محتوى النواة القديمة إلى مساحة المستخدم لتبسيط النظام.

تنصيح:

1. تم نقل هذه المقالة من [معهد أبحاث البيئة بولكادوت], كل حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [معهد أبحاث البيئة بولكادوتإذا كانت هناك اعتراضات على هذا النشر مرجع، يرجى الاتصال بالبوابة تعلمالفريق، وسيتولون عليها على الفور.
2. إخلاء المسؤولية عن المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك المؤلف ولا تشكل أي نصيحة استثمارية.
3. يتم إجراء ترجمات المقال إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر غير ذلك ، فإن نسخ أو توزيع أو سرقة المقالات المترجمة ممنوع.