مقدمة العملة

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

1. اللامركزية
2. قابلية التركيب
3. تجربة التطوير

في هذا المنشور، سأحاول شرح المشكلات التي تنشأ بسبب وجود الكثير من سلاسل التطبيقات وأيضًا طرح حل ممكن للمشكلة التي أعتبرها أنيقة ومثالية لـ Madara و Starknet. إذا كنت بالفعل على دراية جيدة بسلاسل التطبيقات والتسلسل المشترك، فلا تتردد في الانتقال إلى قسم «انتظر، إنه مجرد Polkadot من جديد».

ماذا يحدث في 100 سلسلة تطبيقات؟

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

اللامركزية المجزأة

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

قابلية التركيب

تعني قابلية التركيب بشكل أساسي التفاعل عبر التطبيقات. على Ethereum أو Starknet، هذا يعني فقط استدعاء عقد آخر ويتم التعامل مع كل شيء آخر بواسطة البروتوكول نفسه. ومع ذلك، مع سلاسل التطبيقات، يصبح هذا الأمر أكثر صعوبة. تحتوي سلاسل التطبيقات المختلفة على الكتل الخاصة بها وآليات الإجماع. في كل مرة تحاول فيها التفاعل مع سلسلة تطبيقات أخرى، تحتاج إلى فحص خوارزمية الإجماع وضمانات النهاية بعناية، وبالتالي إعداد جسر عبر السلاسل (مباشرة إلى السلسلة أو عبر L1). إذا كنت ترغب في التفاعل مع 10 سلاسل تطبيقات بتصميمات مختلفة، فستفعل ذلك 10 مرات مختلفة.

تجربة التطوير

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

يمكن لأجهزة التسلسل المشتركة حل هذه المشكلة

الآن إذا كنت تتابع مساحة سلسلة التطبيقات، فربما تكون قد سمعت بمصطلح «أجهزة التسلسل المشتركة». إنها فكرة وجود مجموعة مشتركة من المدققين لجميع السلاسل التي تهدف إلى حل المشكلات المذكورة أعلاه. هذه هي الطريقة التي تعمل بها.

اللامركزية المشتركة

يتمثل جوهر أجهزة التسلسل المشتركة في أنك لست بحاجة إلى مجموعة مختلفة من أدوات التحقق لكل سلسلة تطبيقات أو L2. بدلاً من ذلك، يمكنك الحصول على مجموعة فعالة ولامركزية حقًا من المدققين الذين يقومون بتسلسل الكتل لجميع السلاسل! تخيل الكتل التي تحتوي على معاملات من 100 سلسلة تطبيقات مختلفة. قد تعتقد أن هذا سيؤدي حقًا إلى تضخيم جهاز التسلسل لأنك تحتاج إلى أن تكون قادرًا على التعامل مع محركات التنفيذ لكل سلسلة تطبيقات.

حسنا، أنت لا تفعل ذلك!

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

1. محرك الطلبات: هذا هو المسؤول عن تسلسل المعاملات بترتيب معين. بمجرد أن يتم تحديد هذا الطلب من قبل محرك الطلب، يجب اتباعه. يتم فرض ذلك من خلال تنفيذ هذا الأمر على L1 وإجبار مدققي L1 على التحقق مما إذا كانت المعاملات قد تم تنفيذها بالترتيب المطلوب.
2. محرك التجميع: محرك التجميع هو في الأساس كل شيء آخر تقوم به المجموعة - جمع المعاملات من المستخدمين وتنفيذها وإنشاء البراهين وتحديث الحالة على L1. من الناحية المثالية، يمكن تقسيم هذا إلى المزيد من المكونات ولكننا سنتجنب ذلك بالنسبة لهذه المشاركة.

هنا، محرك الترتيب هو جهاز التسلسل المشترك ومحرك التجميع هو أساسًا كل منطق التجميع. لذا تبدو دورة حياة المعاملة كما يلي:

تقوم أجهزة التسلسل المشتركة بشكل أساسي بترتيب المعاملات عبر المجموعات وإلزامها بـ L1. وبالتالي، من خلال تحقيق اللامركزية في مجموعة أجهزة التسلسل المشتركة، فإنك تقوم بشكل أساسي بإلغاء مركزية جميع المجموعات المرتبطة بمجموعة التسلسل هذه! للحصول على فكرة أكثر تفصيلاً عن عمل أجهزة التسلسل المشتركة، يمكنك أيضًا الرجوع إلى هذه المقالة الرائعة < a href= " https://hackmd.io/@EspressoSystems/EspressoSequencer " > المقالة 17 من إعداد Espresso.

قابلية التركيب

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

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

تجربة المطور

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

في ما يلي رسم تخطيطي لكيفية ظهور سلاسل التطبيقات مع أجهزة التسلسل المشتركة

انتظر، إنه مجرد بولكادوت من جديد

بدأت Polkadot العمل على مستقبل السلاسل المتعددة قبل Ethereum بكثير. في الواقع، لقد عملوا على ذلك منذ أكثر من 5 سنوات، وإذا كنت على دراية بـ Polkadot، فربما لاحظت أن التصميم أعلاه يعيد اختراع الكثير من الأشياء التي قامت بها Polkadot بالفعل!

سلسلة الترحيل (اللامركزية المشتركة)

سلسلة Relay هي في الأساس محرك الطلب + L1 في مخطط التسلسل أعلاه. سلسلة الترحيل

1. معاملات الطلبات عبر جميع السلاسل الفرعية (التجميعات)
2. يتحقق من المعاملات التي تم تنفيذها بشكل صحيح (بدلاً من التحقق من zk، يقوم بالفعل بإعادة تشغيل كود تنفيذ المجموعة للتحقق من اختلافات الحالة)

ربما أدركت أن الترحيل هو في الأساس جهاز التسلسل المشترك الذي ناقشناه أعلاه. باستثناء حقيقة أن سلسلة الترحيل تحتاج أيضًا إلى التحقق من التنفيذ (حيث أن Polkadot هي L1) بينما نترك ذلك لـ Ethereum.

XCM وXCMP

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

كما قد تكون قد خمنت، قامت Polkadot بذلك بالفعل. XCM هو تنسيق المراسلة و XCMP هو بروتوكول المراسلة الذي يمكن لجميع سلاسل الركيزة استخدامه للتواصل مع بعضها البعض. لن أخوض في تفاصيلها ولكن يمكنك أن تقرأ عنها هنا 5.

الركيزة والركام

Substrate عبارة عن إطار تم تطويره بواسطة Parity ويمكن استخدامه لبناء سلاسل البلوكشين. في حين أن جميع السلاسل الموجودة في Polkadot تستخدم الركيزة، فإن الركيزة مبنية بالفعل بطريقة محايدة للسلسلة. يلخص الإطار جميع الجوانب الشائعة لـ blockchain بحيث يمكنك التركيز فقط على منطق التطبيق الخاص بك. كما نعلم، تم بناء مادارا على الركيزة وكذلك Polkadot و Polygon Avail والعديد من المشاريع الأخرى. علاوة على ذلك، فإن Cumulus عبارة عن برنامج وسيط فوق Substrate يسمح لك بتوصيل سلسلتك بـ Polkadot.

لذا استمرارًا في تشبيهنا كما كان من قبل، يمكن اعتبار Substrate و Cumulus كبدائل لأطر التجميع التي تسمح لك ببناء سلاسل التطبيقات وربطها بالتسلسلات المشتركة.

أجهزة التسلسل المشتركة ←
قابلية تركيب سلاسل الترحيل ← أطر/مجموعات XCM و XCMP ← الركيزة
والركام

لذا نعم، إنها لعبة Polkadot تقريبًا من جديد! بصرف النظر عن هذا، تمتلك Polkadot و Parity بعضًا من أكثر الفرق خبرة وتمويلًا والتي تواصل بناء Substrate و Polkadot لإضافة المزيد من الميزات وجعلها أكثر قابلية للتطوير. تم اختبار هذه التقنية بالفعل لسنوات ولديها الكثير من أدوات التطوير خارج الصندوق.

تسوية بولكادوت على إيثريوم؟

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

هناك! في الواقع، لقد بدأنا هذا بالفعل مع Madara. تستخدم Madara إطار Substrate للسماح لأي شخص ببناء حل L2/L3 الخاص به الذي يعمل بنظام zk فوق Ethereum. ما نحتاجه بعد ذلك هو سلسلة ترحيل Polkadot في شكل جهاز تسلسل مشترك. لذلك، إذا كان بإمكاننا إعادة استخدام سلسلة ترحيل Polkadot ولكن

1. قم بإزالة جزء التحقق كما يحدث على L1 عبر zk profes
2. قم بتخصيص ترتيب المعاملات إلى L1
3. قم بتحسين العقد وخوارزميات الإجماع لدعم Tendermint/HotStuff

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

1. مجموعة نشطة من المطورين الذين يواصلون بناء وتثقيف العالم حول Substrate
2. مجموعة أدوات مطور نشطة ومجتمع قوي
3. يمكن للكثير من الباراشيين النشطين اختيار الاستقرار على Ethereum أيضًا إذا كانوا يرغبون في القيام بذلك (رأينا Astar تفعل الشيء نفسه مؤخرًا مع Polygon CDK)

الاستنتاج

فكرتي الرئيسية وراء كتابة هذا المنشور هي فتح المناقشة بين النظام البيئي الأوسع لـ Starknet و Ethereum. أشعر أن نموذج التسلسل المشترك سيلعب دورًا مهمًا في اللامركزية ليس فقط في Starknet ولكن أيضًا في جميع سلاسل التطبيقات التي تفكر في البناء فوقها. طالما أننا واثقون من أطروحة سلسلة التطبيقات وتوسيع نطاق zk، فإن التحليل الشامل لنموذج التسلسل المشترك أمر لا مفر منه. علاوة على ذلك، بينما تتجه Madara نحو الإنتاج وبدأت Starknet عملها على اللامركزية، أشعر أن هذا الموضوع مهم الآن لمعالجته. وبالتالي، أطلب من كل شخص يقرأ هذا ترك أي ملاحظات/اقتراحات لديك حول الموضوع. نتطلع إلى قراءة أفكارك!

الملحق

بولكادوت مقابل كوزموس

تعمل شركة Cosmos، على غرار Polkadot، على حل مستقبل متعدد السلاسل لسنوات عديدة حتى الآن. ونتيجة لذلك، فقد حققت الكثير من التطورات مع Cosmos SDK و IBC ونرى أيضًا الكثير من سلاسل التطبيقات التي تعتمد على نظام Cosmos البيئي. وبالتالي، من العدل فقط التفكير في Cosmos أيضًا لهذا النهج. وجهة نظري الشخصية حول هذا الموضوع هي أن Polkadot أكثر ملاءمة لأنه يحل مشكلة أجهزة التسلسل المشتركة بينما يتطلب Cosmos من كل سلسلة تطبيقات إنشاء مجموعة التحقق الخاصة بها. علاوة على ذلك، تم تصميم Substrate دائمًا بطريقة لا تعتمد على السلسلة للسماح للمطورين ببناء سلاسل بلوكتشين بدون افتراضات حول خوارزميات الإجماع أو نظام Polkadot البيئي. وهذا أيضًا هو سبب اختيارنا Substrate لـ Madara. ومع ذلك، مع ذلك، فإن تجربتي على Cosmos محدودة وأحب أن أسمع المزيد عن هذا من الأشخاص الأكثر خبرة! يمكنك أيضًا العثور على المزيد حول المقارنة بين الشبكتين هنا

إخلاء المسؤولية：

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