تجريد السلسلة Omnichain هو كتابة قواعد عبر السلسلة في العقود الذكية؟

مع زيادة عدد السلاسل العامة وسلاسل الطبقة الثانية، بدأ الطلب على الأصول المتقاطعة والتطبيقات اللامركزية في الزيادة أيضًا، ومن الطبيعي أن تكون الجسور المتقاطعة حلاً أكثر شيوعًا، لكن Omnichain، ممثلة بـ Zetachain، اتخذت مسارًا مختلفًا تمامًا. ستأخذ هذه المقالة Zetachain كمثال لشرح كيفية قيام Omminchain بكتابة قواعد عبر السلاسل في العقود الذكية لتحقيق اللامركزية في قابلية التشغيل البيني عبر السلاسل.

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

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

وفقًا لطرق المعالجة المختلفة للرسائل عبر السلسلة وطرق ترخيص التوقيع للأصول المقابلة، يمكن تقسيمها إلى الحلول التقنية التالية:

1. ** الجسور المتقاطعة: **

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

2. كاتب العدل:

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

3. عقود التجزئة الزمنية (HTLCs):

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

4. BoB (البلوكشين على البلوكشين، مثل Cosmos’ IBC):

يحقق هذا الحل التقني إمكانية التشغيل البيني عبر السلاسل من خلال إنشاء blockchain (أو طبقة) جديدة على blockchain موجود، مثل بروتوكول IBC (Inter-Blockchain Communication) في شبكة Cosmos. تسمح IBC لسلاسل الكتل المختلفة بالحفاظ على هياكل حوكمة مستقلة مع تمكين النقل الآمن للأصول والبيانات. يهدف هذا النهج إلى إنشاء شبكة إنترنت لا مركزية تعمل بتقنية البلوكشين حيث يمكن للسلاسل الفردية تبادل المعلومات والقيمة بحرية.

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

الرسائل عبر السلسلة

يعد تمرير الرسائل عبر السلاسل (CCMP) التكنولوجيا الأساسية لتحقيق قابلية التشغيل البيني عبر السلاسل، مما يضمن إمكانية تنفيذ عملية التفاعل عبر السلاسل بشكل آمن وفعال، والغرض الأساسي منها هو نقل الرسائل ونقلها بين سلاسل الكتل المختلفة لتحقيق التفاعل عبر السلسلة للأصول والبيانات. يتضمن مبدأ عملها بشكل أساسي الروابط الرئيسية التالية:

1.إنشاء الرسائل وإرسالها:

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

• بعد إنشاء الرسالة، يتم إرسالها من خلال العقد الذكي للسلسلة المصدر. سيسجل هذا العقد تفاصيل المعاملة ويؤدي إلى قفل الأصل.

2.تسليم الرسائل:

• عادة ما تكون هناك طريقتان للتسليم: التسليم المباشر والتسليم بالتتابع.

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

3. التحقق من الرسالة:

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

• تتطلب عملية التحقق عادةً إثبات بيانات سلسلة المصدر (مثل إثبات Merkle)، والذي يمكن أن يؤكد أن الرسالة تأتي من سلسلة المصدر ولم يتم العبث بها.

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

4. المعالجة والاستجابة:

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

• بعد اكتمال هذه الخطوة، يكتمل التفاعل عبر السلسلة بشكل أساسي ويمكن للمستخدمين استخدام أصولهم أو إدارتها في السلسلة المستهدفة.

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

1.جسر عبر السلسلة

تسهل الجسور عبر السلسلة نقل الأصول والمعلومات بين سلاسل الكتل المختلفة عن طريق إنشاء طبقة وسيطة. يمكن أن تكون هذه الطبقة الوسيطة:

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

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

2. كاتب العدل

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

3. عقد قفل وقت التجزئة (HTLC)

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

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

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

4. بوب

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

وفي الوقت نفسه، تواجه تقنية CCMP أيضًا العديد من التحديات الرئيسية:

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

الكفاءة وزمن الاستجابة: غالبًا ما تتضمن العمليات عبر السلسلة تأكيدات كتل متعددة، مما قد يؤدي إلى تأخيرات زمنية كبيرة.

قضايا اللامركزية والثقة: قد يكون الاعتماد على عقد الترحيل أو خدمات الطرف الثالث مخالفًا للروح اللامركزية لـ blockchain، لذا فإن تصميم آلية CCMP لامركزية وآمنة يمثل تحديًا تقنيًا.

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

التوقيع والترخيص للأصول عبر السلسلة

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

1.جسر عبر السلسلة

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

2. كاتب العدل

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

3. عقد قفل وقت التجزئة (HTLC)

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

4. بوب

على سبيل المثال، في بروتوكول IBC الخاص بـ Cosmos، يتم تنفيذ عملية ترخيص التوقيع من خلال البروتوكول بين السلاسل والعقود المحلية. تدير كل سلسلة بشكل مستقل آلية الأمان والترخيص الخاصة بها، مع ضمان أمان وصلاحية الرسائل عبر السلسلة من خلال البروتوكولات. ويؤكد هذا النهج على اللامركزية والاستقلالية، مما يقلل الاعتماد على كيان واحد.

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

عمارة زيتاتشين

إذا كانت DeFi تكتب القواعد المالية في العقود الذكية، وكانت الألعاب الموجودة على السلسلة تكتب قواعد اللعبة في العقود الذكية، فإن Omnichain تقوم في الواقع بكتابة قواعد عبر السلسلة في العقود الذكية، والتي تتضمن قواعد نقل الرسائل عبر السلسلة وأصول تفويض التوقيع القواعد، دعونا نتعمق في التفاصيل لنرى كيف يقوم Zetachain بذلك.

تجريد السلسلة Omnichain هو كتابة قواعد عبر السلسلة في العقود الذكية؟

ZetaChain عبارة عن blockchain PoS مبني على محرك التوافق Cosmos SDK و Tendermint PBFT. بفضل استخدام محرك الإجماع Tendermint PBFT، فإن ZetaChain قادر على تحقيق أوقات إنشاء كتل سريعة تبلغ حوالي 5 ثوانٍ ونهائية فورية (لا يلزم تأكيدات الكتلة، ولا يُسمح بإعادة التنظيم). في ظل ظروف الشبكة المثالية، يمكن أن تصل إنتاجية معاملاتها إلى أكثر من 4000 معاملة في الثانية، ولكن قد لا تصل إنتاجية المعاملات عبر السلسلة إلى هذا بسبب تأخير السلسلة الخارجية وعوامل أخرى مختلفة (مثل سرعة RPC للعقدة الخارجية، وما إلى ذلك). ) مستوى.

تتكون بنية ZetaChain من شبكة موزعة من العقد، تسمى غالبًا أدوات التحقق من الصحة. يحتوي كل مدقق ZetaChain على ZetaCore وZetaClient. ZetaCore مسؤول عن إنشاء blockchain والحفاظ على آلة الحالة المنسوخة، في حين أن ZetaClient مسؤول عن مراقبة الأحداث على السلسلة الخارجية وتوقيع المعاملات الصادرة. يتم تجميع ZetaCore وZetaClient معًا ويتم تشغيلهما بواسطة مشغلي العقد. يمكن لأي شخص يتعهد بما يكفي من رموز ZETA أن يصبح مشغل عقدة ويشارك في أعمال التحقق.

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

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

آليتان للتشغيل البيني عبر السلاسل لـ Zetachain

يدعم Zetachain آليتين للتشغيل البيني عبر السلسلة، إحداهما هي آلية الجسر التقليدية عبر السلسلة، والأخرى هي آلية العقد الذكي Omnichain.

آلية الجسر عبر السلسلة

دعونا نلقي نظرة أولاً على سير عمل آلية الجسر عبر السلسلة. تتضمن العملية برمتها بشكل أساسي الخطوات التالية:

**1. يتفاعل المستخدم مع العقد: **يعمل المستخدم وفقًا للعقد C1 من السلسلة A ويترك حدثًا أو مذكرة معاملة تحتوي على [chainID, ContractAddress, message] المحدد من قبل المستخدم. هذه الرسالة عبارة عن بيانات تطبيق مشفرة بتنسيق ثنائي.

**2. يلتقط المراقب الحدث: ** يلتقط مراقب ZetaChain (في zetaclient) هذا الحدث أو المذكرة ويبلغه إلى zetacore، المسؤول عن التحقق من صحة المعاملات الواردة.

**3. إنشاء المعاملات الصادرة: ** يقوم zetacore بتعديل متغيرات حالة CCTX (المعاملات عبر السلسلة) وOutboundTxParams لتوجيه مُوقع TSS (في zetaclient) لإنشاء المعاملات الخارجية وتوقيعها وبثها.

**4. التوقيع والبث: ** يقوم موقع TSS الخاص بـ zetaclient بإنشاء معاملة صادرة استنادًا إلى OutboundTxParams في CCTX، ويقوم بإجراء حفل توقيع مفتاح TSS، ثم يبث المعاملة الموقعة إلى blockchain الخارجي.

5. تحديث وتتبع الحالة: يتتبع هيكل CCTX أيضًا مراحل/حالة المعاملات عبر السلسلة المختلفة.

6. تأكيد المعاملة: بمجرد تضمين معاملة البث (أي “المعدنة” أو “المؤكدة”) في blockchain معين، سيقوم zetaclient بإبلاغ zetacore بهذا التأكيد ثم يقوم بتحديث حالة CCTX لاحقًا.

7. التعامل مع النجاح والفشل:

• إذا نجحت المعاملة الخارجية، تتغير حالة CCTX إلى OutboundMined، وتكتمل معالجة CCTX، ويتم إدخال حالة المحطة الطرفية.

• في حالة فشل معاملة خارجية (على سبيل المثال، تم إبطالها في سلسلة Ethereum)، يتم تحديث حالة CCTX إلى PendingRevert (إن أمكن) أو تم إحباطها (إذا لم يكن الإلغاء ممكنًا). إذا تم إدخال الحالة المجهضة، فستكتمل معالجة CCTX.

8. التعامل مع الإلغاء:

• إذا كانت الحالة الجديدة هي “PendingRevert”، فيجب تضمين OutboundTxParams الثاني بالفعل في CCTX، وتوجيه عملاء zeta إلى إنشاء معاملة صادرة “Revert” مرة أخرى إلى السلسلة الواردة والعقد، مما يسمح للعقد الداخلي بتنفيذ وظيفة التراجع على مستوى التطبيق لتنظيف حالة العقد.

• ينشئ zetaclients معاملة الإلغاء، وينفذ مراسم توقيع مفتاح TSS، ويبث المعاملة مرة أخرى إلى blockchain الوارد (السلسلة A في هذا المثال).

9. سحب التأكيد:

• بمجرد “تأكيد” معاملة الإلغاء في السلسلة أ، يقوم عملاء zetacore بالإبلاغ عن حالة المعاملة إلى zetacore.

• إذا تم عكس المعاملة بنجاح، تتغير حالة CCTX إلى تم التراجع وتكتمل المعالجة.

• في حالة فشل إلغاء المعاملة، تتغير حالة CCTX إلى تم الإلغاء وتكتمل المعالجة.

من خلال الخطوات المذكورة أعلاه، يمكننا أن نرى أن نقل الرسائل عبر السلسلة يتم بشكل أساسي من خلال الاتصال الداخلي لـ ZetaCore وZetaClient، وهي طريقة لا مركزية ولا تستخدم العقد الذكي لـ Zetachain نفسها، ولكن العقد الذكي فقط السلسلة المستهدفة، في هذه الحالة، لا يمكن تحقيق ذلك إلا إذا كانت السلسلة المستهدفة عبارة عن منصة عقد ذكية مشابهة لـ Ethereum، ويجب على كل سلسلة نشر عقد واحد على الأقل لتحقيق قابلية التشغيل البيني عبر السلسلة. إذا كانت منصة عقود غير ذكية مثل Bitcoin، فلا يمكن استخدامها. من ناحية أخرى، يتم توزيع حالة التطبيق ومنطقه عبر جميع عقود التطبيقات هذه بطريقة موزعة. تصبح مزامنة الحالة والتواصل بين السلاسل المختلفة باهظة الثمن، وبطيئة، وتعقد معالجة التراجع. من أجل حل المشاكل المذكورة أعلاه، قدمت Zetachain آلية العقد الذكي Omnichain.

آلية العقد الذكي Omnichain

عقود Omnichain الذكية هي طريقة مقترحة من قبل ZetaChain لتبسيط معالجة قابلية التشغيل البيني عبر السلسلة. يقوم بشكل أساسي بمعالجة الرسائل عبر السلاسل ويحقق قابلية التشغيل البيني عبر السلاسل من خلال الخطوات التالية:

1. استلام الأصول: يرسل المستخدم الأصول المحلية (مثل رموز ERC20) إلى عنوان TSS للسلسلة A، ويرفق رسالة تحدد [zEVMContractAddress، message]. قد يكون عنوان TSS هنا عقدًا مصممًا خصيصًا لاستضافة رموز ERC20.

2. المراقبة والإبلاغ: يراقب مراقبو ZetaChain (عملاء zetaChain) هذه المكالمة القادمة عبر السلسلة ويبلغون عنها إلى zetacore.

**3.الاستدعاء والتنفيذ: ** يستدعي zetacore وظيفة الإيداع والمكالمات () الخاصة بالعقد، والتي تستدعي بعد ذلك وظيفة onCrossChainCall () الخاصة بـ zEVMContractAddress. خلال هذه المكالمة:

• سيتم ملء المعلمة zrc20 بعنوان عقد ZRC20 الذي يدير الرمز الأجنبي الذي يرسله المستخدم في الخطوة الأولى.

• سيتم ملء معلمة المبلغ بكمية الرموز المميزة التي يرسلها المستخدم.

• ستكون معلمة الرسالة هي الرسالة التي يرسلها المستخدم في مذكرة المعاملة.

**4. تنفيذ منطق العقد: **يتم استدعاء عقد Omnichain الذكي من خلال zContract(zEVMContractAddress).onCrossChainCall(zrc20, المبلغ, رسالة). يجب أن ينفذ عقد التطبيق منطق الأعمال الخاص به في وظيفة onCrossChainCall().

5. معالجة نتائج تنفيذ العقد:

• إذا تم تنفيذ العقد بنجاح ولم يتم إخراج أي أصول خارجية، فسيتم إكمال تفاعل العقد الذكي متعدد السلسلة.

• إذا فشل تنفيذ عقد zEVM (يحدث تراجع)، يتم إنشاء CCTX لعكس المعاملة الواردة، أي إعادة نفس المبلغ من الرموز الأجنبية إلى المستخدم (مطروحًا منها الرسوم المحتملة).

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

السمات البارزة لعقود Omnichain الذكية هي:

• يتم نشره فقط على zEVM، ويتم تركيز كل المنطق والحالة في مكان واحد، مما يجعل تطوير التطبيقات وصيانتها أسهل.

• لا يتطلب نشر العقود الذكية التطبيقية على سلاسل خارجية، لذا يمكنها دعم سلاسل العقود غير الذكية مثل البيتكوين.

• بما أن جميع عمليات التراجع تتم معالجتها بواسطة بروتوكول ZetaChain، فإن عقد التطبيق لا يحتاج إلى التعامل مع منطق التراجع.

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

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

تجريد السلسلة Omnichain هو كتابة قواعد عبر السلسلة في العقود الذكية؟

آلية اعتماد توقيع Zetachain

تعتمد آلية ترخيص التوقيع الخاصة بـ ZetaChain على نظام التوقيع المتقدم متعدد الأطراف (TSS)، والذي يمكنه حل مشكلة نقطة الفشل الفردية بشكل فعال وتعزيز أمان النظام بأكمله.

تجريد السلسلة Omnichain هو كتابة قواعد عبر السلسلة في العقود الذكية؟

**1. نظام توقيع العتبة: ** يستخدم ZetaChain TSS استنادًا إلى الحساب متعدد الأطراف (MPC) يسمح هذا النظام لعدة مدققين (المدققين) بإدارة مفتاح خاص واحد لـ ECDSA/EdDSA بشكل مشترك، ولكن لا يوجد كيان واحد أو عدد صغير من المفاتيح. يتم منح المدققين السيطرة الكاملة على المفتاح الخاص. يوفر هذا الأسلوب راحة المحفظة الساخنة وأمان المحفظة الباردة.

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

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

**4. العقود الذكية وإدارة الأصول: ** نظرًا لوجود مفاتيح وعناوين TSS، فإن ZetaChain قادر على إدارة مجموعات الخزانة/الأموال المحلية على السلاسل المتصلة، بما في ذلك سلاسل العقود غير الذكية مثل Bitcoin. يؤدي هذا في الواقع إلى إضافة وظائف العقود الذكية إلى شبكة Bitcoin، وما إلى ذلك، مما يسمح للمستخدمين بتجميع الأصول معًا والسماح للعقود الذكية بإدارة هذه الأصول وفقًا لقواعد محددة مسبقًا، مثل مجمعات صانع السوق الآلي (AMM) أو مجمعات الإقراض.

**5. دعم سلاسل العقود غير الذكية: **تمكن TSS ZetaChain من دعم سلاسل العقود غير الذكية مثل Bitcoin وDogecoin، بالإضافة إلى منصات العقود الذكية حيث يكون التحقق من التوقيعات المتعددة مكلفًا.

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