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

المؤلف: CaptainZ؛ المصدر: xlog

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

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

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

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

< li>

الجسور عبر السلاسل:

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

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

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

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

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

4.BoB (Blockchain on Blockchain، مثل Cosmos’ IBC):

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

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

تمرير الرسائل عبر السلسلة

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

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

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

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

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

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

 - المرور المباشر يعني وجود مسار اتصال مباشر بين السلسلة المصدر والسلسلة المستهدفة، ولكن هذا نادر في الممارسة العملية لأن معظم سلاسل الكتل تعمل بشكل مستقل.

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

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

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

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

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

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

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

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

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

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

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

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

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

2. كتاب العدل

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

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

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

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

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

4.BoB

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

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

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

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

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

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

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

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

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

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

2. كاتب العدل

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

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

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

4.BoB

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

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

بنية Zetachain

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

ZetaChain عبارة عن كتلة 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، ثم بث المعاملة الموقعة إلى سلسلة الكتل الخارجية.

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

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

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

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

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

8. معالجة الإلغاء:

  - إذا كانت الحالة الجديدة هي "PendingRevert"، فيجب أن يحتوي CCTX بالفعل على OutboundTxParams ثانٍ لتوجيه عملاء zetaclients لإنشاء إرجاع إلى الوارد " "إرجاع" المعاملات الصادرة للسلاسل والعقود، مما يسمح للعقود الواردة بتنفيذ وظيفة الإلغاء على مستوى التطبيق لتنظيف حالة العقد.

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

9. تأكيد الإلغاء:

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

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

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

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

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

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

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

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

**3. الاستدعاء والتنفيذ: ** يستدعي zetacore الدالة  depositAndCall()  zEVMContractAddress.onCrossChainCall() Function. أثناء هذه المكالمة:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

آلية ترخيص توقيع Zetachain

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

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

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

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

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

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

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