البنية التحتية الشاملة لـ Omnichain DAPP

متوسط2/29/2024, 3:40:32 AM
تتعمق هذه المقالة في الجوانب التقنية لحل ZetaChain متعدد السلسلة، موضحًا كيف يعمل كبنية تحتية أساسية لقابلية التشغيل البيني متعدد السلسلة لـ DAPPs، مما يتيح دقة ومعالجة سلسة للرسائل عبر السلسلة.

إعادة توجيه العنوان الأصلي: رؤى فنية حول ZetaChain: بنية تحتية شاملة لـ OmniChain DAPP

ZetaChain هي سلسلة عامة لنقاط البيع تعتمد على Cosmos SDK، حيث تسجل كتلها الرسائل والبيانات عبر السلاسل التي تبدأ على "سلاسل خارجية". يمكن للمستخدمين في السلاسل الخارجية مثل BTC توصيل نواياهم إلى شبكة ZetaChain عن طريق نشر الرسائل بتنسيق معين، على غرار بروتوكول Ordinals. تستخدم عقد ZetaChain آلية إجماع لتحديد الرسائل التي سيتم معالجتها وتسلسلاتها، وفي النهاية تستخدم نظام توقيع العتبة (TSS) لإنشاء توقيع رقمي على السلسلة المستهدفة. تتضمن هذه العملية تحرير الأصول من الحساب العام للسلسلة، مما يؤدي إلى بدء خطوات المعاملة اللاحقة.


تتضمن القائمة الحالية لعقد التحقق في ZetaChain العديد من أطراف المشروع والمؤسسات، مثل OKX وHashKey Cloud وDora Factory وغيرها. نظرًا لتوافق ZetaChain المتأصل مع EVM، فإنه يدعم نشر منطق العقد. يمكن لمطوري التطبيقات اللامركزية ذات السلسلة الكاملة كتابة برامج معالجة الرسائل عبر السلسلة مباشرة على ZetaChain، مما يلغي الحاجة إلى نشر عقود الأصول المؤقتة عبر سلاسل متعددة وبالتالي توفير تكاليف التطوير. من وجهة نظر المستخدم، من الناحية النظرية، يعد التفاعل مع عقود ZetaChain كافيًا، مما يلغي الحاجة إلى تفاعلات متعددة مع العقود المؤقتة بين سلاسل المصدر والهدف وتقليل تكاليف رسوم المعاملات. على غرار بعض مشاريع Intent ذات تأثير "سلسلة حفظ الأصول الشاملة"، تدعم ZetaChain نشر عقود الأصول أو بروتوكولات التمويل اللامركزي. يمكن للمستخدمين إنشاء رسائل محددة على الواجهة الأمامية للتطبيقات اللامركزية على سلاسل مختلفة للاتصال بشكل غير متزامن بعقود التمويل اللامركزي الخاصة بـ ZetaChain أو حالات الأصول. يدعم هذا الإعداد حسابات سلسلة BTC أيضًا. إنه يشبه السماح لـ ZetaChain باستضافة حساب أصول موحد عالميًا مباشرة عبر جميع السلاسل. ومع ذلك، يتطلب تحقيق هذا التأثير واجهة أمامية مخصصة لتطبيق DApp للتعاون. اعتبارًا من الآن، تتمثل الوظيفة الأساسية لـ ZetaChain في العمل كبنية تحتية أساسية لقابلية التشغيل البيني لـ Omnichain. يمكنه تحليل ومعالجة رسائل محددة عبر السلاسل ويعمل أيضًا كمنصة تنفيذ منطق الأعمال للتطبيقات اللامركزية متعددة السلاسل. يدور نموذج العمل الرئيسي حول السيناريوهات النموذجية من B إلى B إلى C.

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

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

لمعالجة مسألة قابلية التشغيل البيني للسلسلة الشاملة، اقترحت LayerZero وPolyhedra وMap Protocol وBool Network وحتى Cosmos وPolkadot حلولاً مختلفة للمراسلة عبر السلاسل. تعد ZetaChain التي تم إطلاقها مؤخرًا، والتي قدمت رمزها المميز، لاعبًا أساسيًا في مشهد البنية التحتية لـ Omnichain.

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

التحديات التي تواجه الحلول عبر السلسلة الحالية

في الواقع، إن أبسط سيناريو يحتاج الجسر عبر السلسلة إلى معالجته هو نقل الأصول عبر سلاسل مختلفة. على سبيل المثال، عند نقل الأصول من ETH إلى Polygon، تحتاج أولاً إلى نقل الأصول إلى عنوان إيداع معين على سلسلة ETH ثم الحصول على مبلغ معادل على سلسلة Polygon. ينشأ التحدي لأن العقد المضلعة لا يمكنها تأكيد ما حدث في سلسلة ETH ولا تعرف ما إذا كنت قد قمت بالفعل بإيداع المبلغ المحدد. إذا ادعى شخص ما كذبًا أنه قام بإيداع 100 USDT في عنوان ETH المعين وبدأ مطالبة بالسحب على سلسلة Polygon لتحرير 100 USDT الخاص به، فإن ذلك يؤدي إلى مشكلة "السحب من لا شيء". إن مفتاح الجسر عبر السلسلة هو حل مثل هذه المشكلة من خلال التأكد من أن جميع مطالبات السحب تتوافق مع أنشطة الإيداع الفعلية. بشكل أساسي، يتضمن ذلك إثبات السلسلة B أنه كانت هناك بالفعل معاملات N مرتبطة بالجسر عبر السلسلة في السلسلة A.


حاليًا، تميل الجسور السائدة عبر السلاسل إلى اعتماد آلية كاتب العدل، والتي تتضمن إنشاء مجموعة من عقد كاتب العدل التي تصل إلى "الإجماع" من خلال التوقيع المتعدد أو توقيعات MPC. طالما أن غالبية عقد كاتب العدل توافق على أنه يمكن الموافقة على الإجراء عبر السلسلة، فيمكن عبور أصولك بسلاسة. تستخدم بعض الجسور عبر السلسلة قفل تجزئة أكثر أمانًا أو تنفذ العقد الخفيفة لسلاسل أخرى من خلال العقود الموجودة على السلسلة. تؤكد هذه الجسور صحة الأنشطة عبر السلسلة من خلال تلقي إثباتات Merkle أو إثباتات ZK. ومع ذلك، فإن تكلفة هذه الجسور عبر السلاسل غالبًا ما تكون أعلى ويتم تحويلها في النهاية إلى رسوم معاملات المستخدمين. لذلك، لا تزال معظم الجسور عبر السلسلة تختار نموذج عقدة كاتب العدل خارج السلسلة للتوافق متعدد التوقيعات. المرجع: توضيح ما هي الاعتبارات المهمة عند تصميم الجسور عبر السلاسل؟ومن الجدير بالذكر أن الجسور عبر السلسلة القائمة على كاتب العدل غالبًا ما تواجه مخاطر كبيرة، بما في ذلك التعرض للقرصنة أو السرقة من الداخل. وفقًا لإحصائيات SlowMist Hacked، كان هناك 16 حادثًا أمنيًا يتعلق بالجسور المتقاطعة في عام 2022، مما أدى إلى خسارة إجمالية قدرها 1.21 مليار دولار. ويمثل هذا 32% من إجمالي الخسائر الناجمة عن حوادث الهجمات على السلسلة في ذلك العام، مما يسلط الضوء على مخاطر الثغرات الأمنية في الجسور عبر السلسلة.


بالإضافة إلى ذلك، تعتمد العديد من حلول الجسور عبر السلسلة الحالية في الغالب نموذج Lock-Mint، حيث يتم قفل الأصول على السلسلة A ويتم إصدار الأصول المعينة المقابلة على السلسلة B لتحقيق نقل الأصول عبر السلسلة. ومع ذلك، يتطلب تدفق معالجة الإيداع والسحب في مثل هذه الحلول تفاعلات متعددة مع عقد الأصول المعينة، مما يؤدي إلى احتكاك كبير وخسارة محتملة للأموال. بالإضافة إلى ذلك، تدعم العديد من حلول الجسور عبر السلاسل فقط عمليات نقل الأصول بين السلاسل المتوافقة مع EVM، مما يواجه تحديات في التفاعلات عبر السلاسل بين السلاسل غير المتجانسة مثل Solana وBitcoin بسبب الاختلافات في المعايير الفنية. وبالنظر إلى القضايا المتعلقة بالأمن والرسوم، غالبًا ما تكافح حلول الجسر عبر السلسلة السائدة لتحقيق النتائج المثلى ولا يمكنها ضمان نقل الأصول "عبر السلسلة الأصلية". في النظام البيئي للبيتكوين اليوم، هناك رغبة متزايدة في تجربة تفاعل سلسة ومبتكرة عبر السلاسل، مع توقع حل أكثر كفاءة. تعالج ZetaChain هذا التحدي بنهجها الفريد.

وظائف ZetaChain: البنية التحتية الأساسية لـ DAPPs القابلة للتشغيل المتبادل عبر السلاسل

تضع ZetaChain نفسها كبنية تحتية أساسية للتطبيقات اللامركزية القابلة للتشغيل المتبادل متعددة السلسلة، وهي متخصصة في دعم بروتوكولات التطبيقات المختلفة للتفاعلات عبر السلسلة - وهي نموذج للبنية التحتية الأساسية من B إلى B إلى C. إنها تستخدم آلية قبول PoS، مما يسمح للعقد بتراكم الأصول بالدخول إلى الشبكة والعمل كموثقين. تشارك جميع نقاط إثبات الحصة (PoS)، التي تستخدم تقنية TSS، في التحقق من الرسائل عبر السلسلة ومعالجتها، بهدف تعزيز الأمان قدر الإمكان. وفي الوقت نفسه، تسهل ZetaChain نشر العقود الذكية، التي تتضمن منطق الأعمال المتعلق بمقايضة الأصول. يمكن للمستخدمين إرسال رسائل بتنسيق معين على أي سلسلة، أو الاتصال بـ ZetaChain أو عقود التمويل اللامركزي المدعومة الخاصة بها على سلاسل متعددة. على سبيل المثال، في BTC، يمكن للمستخدمين الاتصال بشكل غير مباشر بوظائف DeFi على Polygon. والنتيجة هي تسهيل نقل الرسائل بين سلاسل الكتل المختلفة، وتحقيق قابلية التشغيل البيني.


يمكن للتطبيقات اللامركزية القائمة على سيناريو التشغيل البيني الشامل أن تنشر منطق أعمال تبادل الأصول على ZetaChain، مما يسهل التحويل التلقائي لرموز الغاز عبر سلاسل مختلفة للمستخدمين. على سبيل المثال، باستخدام الواجهة الأمامية لبعض التطبيقات اللامركزية متعددة الاستخدامات (omnichain DApps)، يمكنك إصدار رسالة بتنسيق محدد على BTC، على غرار بروتوكول Ordinals، للإشارة إلى استدعاء عقد على Solana. ستكتشف عقد ZetaChain هذه الرسالة، وبعد ذلك، يمكن لعقد AMM على ZetaChain حساب نسبة التبادل بين BTC وSOL تلقائيًا. ثم تقوم بعد ذلك بتحرير مبلغ معادل من SOL على سلسلة Solana، واستكمال الخطوات اللاحقة مثل عقود الاتصال، وأخيرًا، تحويل الأصول المستحقة مرة أخرى إلى عنوان BTC أو Solana الخاص بك. يُشار إلى هذه العملية باسم "قابلية التشغيل البيني للسلسلة الشاملة"، حيث تحتاج فقط إلى نشر رسالة على سلسلة واحدة للاتصال عن بعد بالتطبيقات اللامركزية على سلاسل متعددة. في هذا السياق، يمكن تصور ZetaChain على أنه "طبقة تسوية سلسلة السلاسل". في جميع سيناريوهات التفاعل متعدد السلاسل، مثل بدء مكالمة من السلسلة A إلى DApp على السلسلة B، يكون الأمر أقرب إلى تسوية السلسلة A مع ZetaChain أولاً. تقوم ZetaChain بعد ذلك بمزامنة نتائج التسوية المُجهزة مسبقًا مع الحساب المقابل في السلسلة B، واستكمال الخطوات اللاحقة. طوال هذه العملية، لا يوجد تفاعل مفرط مع رسم خرائط عقود الأصول أو الاحتكاك في رسوم المعاملات. يتم تسهيل تداول الأصول من خلال حسابات ZetaChain العامة عبر سلاسل مختلفة، مما يلغي الحاجة إلى النشر المتكرر لعقود أصول الخرائط على سلاسل مختلفة، كما هو موضح في التطبيقات التقليدية عبر السلاسل.

في الوقت الحالي، يبدو أن تطبيقات Omnichain المستندة إلى ZetaChain يمكن أن توفر قدرًا كبيرًا من المتاعب، مما يلغي الحاجة إلى تصميم عقود الأصول بدقة على سلاسل مختلفة. تتم معالجة جميع التفاصيل المتعلقة بتدفق الأصول الداخلة والخارجة بين سلاسل المصدر والهدف بواسطة ZetaChain. بمعنى آخر، ما عليك سوى نشر منطق الأعمال المتعلق بالمعاملات عبر السلسلة على ZetaChain. وهذا يسهل تطبيقات السلسلة الكاملة المختلفة لدعم السلاسل غير التابعة لـ EVM مثل Solana وAlgorand وBitcoin وDogeCoin في الواجهة الأمامية دون الحاجة إلى تنفيذ عقود تطبيقات مخصصة عبر السلاسل على نطاق واسع على سلاسل مختلفة. بالإضافة إلى ذلك، تدعم ZetaChain نفسها نشر عقود الأصول أو حسابات AA (الأصول المستقلة). يمكن للمستخدمين في سلاسل مختلفة إرسال رسائل بتنسيق معين لاستدعاء هذه العقود، كما لو كانوا يقومون بتشغيل حساب موحد عبر السلاسل. يتيح نهج التصميم هذا، الذي ينعكس أيضًا في Particle Chain الخاصة بـ Particle Network، للمستخدمين في النهاية مركزية سجلات البيانات الخاصة بأصولهم على ZetaChain أو Particle Chain. عند الضرورة، يمكن للمستخدمين الاتصال بشكل غير متزامن بعقود الأصول الخاصة بهم على ZetaChain عن طريق إرسال رسائل استدعاء من خلال الواجهة الأمامية للتطبيقات اللامركزية على "السلاسل الخارجية". بعد ذلك، تقوم ZetaChain، عبر الحساب العام على السلسلة الخارجية، بنقل كمية معينة من الأصول إلى العنوان المحدد من قبل المستخدم أو تتفاعل مع بروتوكول DeFi المحدد من قبل المستخدم.


تتطلب سلسلة العمليات هذه تطبيقات DApps للواجهة الأمامية المتخصصة لتنفيذها. بمعنى آخر، توفر ZetaChain نفسها الخدمات فقط باعتبارها البنية التحتية الأساسية لـ Omnichain، ويجب أن يكون هناك مدخل أمامي مخصص في نهاية التطبيق لإنشاء رسائل بتنسيق معين.

نموذج أمان ZetaChain: شبكة عقد كاتب عدل كبيرة تعتمد على نظام نقاط البيع

في النهاية، ZetaChain هي في الأساس شبكة من عقد التحقق المصممة لمعالجة الرسائل عبر السلسلة. تم بناءه على Cosmos SDK، وهو يشتمل على العديد من عقد التحقق من الصحة ويستخدم نقطة البيع كآلية قبول، وبالتالي تحقيق مقاومة ضد هجمات Sybil وضمان الأمن الأساسي.

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


(تتضمن القائمة الحالية لعقد التحقق من صحة Zetachain العديد من أطراف المشروع أو المؤسسات) يتضمن عميل Zetachian's Validator وحدتين، ZetaCore وZetaClient. تشارك وحدة ZetaCore في إنشاء كتل ZetaChain وعملية الإجماع، بينما تراقب وحدة ZetaClient الأحداث على السلاسل الخارجية وتوقع المعاملات الصادرة. هنا، يمكن فهم كلمة "صادرة" ببساطة على أنها تسجيل سجل المعاملات على ZetaChain وإرساله إلى "سلاسل خارجية" (في إشارة إلى سلاسل خارج ZetaChain). يؤدي هذا إلى تشغيل الإجراءات المقابلة على السلسلة المستهدفة، حيث يتضمن المحتوى بشكل أساسي عنوان العقد ومعرف السلسلة ومحتوى الرسالة المعلن عنها من قبل المستخدم في الرسالة، على غرار قسم السجل في معاملات إيثريوم.


على العكس من ذلك، يمكن فهم "الوارد" على أنه تسجيل الرسائل/المعاملات ذات الصلة على سلاسل خارجية خارج ZetaChain، مثل الطلبات عبر السلاسل، واستدعاء العقود الذكية على zEVM، وما إلى ذلك، على ZetaChain. من المهم ملاحظة أنه عند تشغيل عقد Validator لـ ZetaChain، يتضمن رمز العميل ثلاث وحدات: Validator، وObserver، وTSS Signer. تتمتع هذه الوحدات الثلاث بوظائف مختلفة ولكنها جميعها تنتمي إلى عميل ZetaChain.

وحدات المراقب و TSS Signer

أولاً، تحتوي جميع عقد ZetaChain على وحدة "Validator"، مع وظائف مشابهة لعقد Validator في سلاسل PoS العامة، والمشاركة في عمليات إنشاء الكتل والإجماع. بالإضافة إلى ذلك، يمكن للعقد التصويت على المقترحات الموجودة على السلسلة بناءً على نسبة الرموز المميزة (ZETA). تحتوي كتل ZetaChain على جميع السجلات والتفاعلات عبر السلاسل التي تمت معالجتها مع عقود Omnichain الذكية، والتي تعمل كسجل.

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

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

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


(في الوضع النشط، تحتاج العقد إلى تشغيل عميل العقدة الكامل للسلاسل الخارجية. في الوضع السلبي، يتم تشغيل العملاء الخفيفين فقط للسلاسل الخارجية، وتلقي الرسائل عبر السلسلة وإثباتات Merkle من عقد ZetaChain في الوضع النشط لتأكيد صحة الرسائل.

توقيع خدمات الدعم الفني

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


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


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

zEVM: منصة عقد DAPP شاملة ومتعددة السلاسل

على عكس الحلول التقليدية عبر السلاسل التي تتطلب نشر عقود أصول التعيين على كل سلسلة، تحقق ZetaChain وظائف عبر السلاسل من خلال نشر عقد ذكي مرة واحدة فقط على سلسلتها الخاصة. في ZetaChain، توجد طبقة تنفيذ متوافقة مع EVM تسمى zEVM، حيث يمكن نشر العقود الذكية عبر السلسلة مباشرة. يدعم zEVM الميزات التالية: يمكن لأي شخص إرسال بيانات المعاملات بتنسيق معين على السلسلة الخارجية واستدعاء عقد على zEVM؛ يمكن لمنطق العقد الموجود على zEVM التحكم في بيانات المعاملات الصادرة التي تم إنشاؤها على السلسلة الخارجية. تمكّن هاتان الميزتان الإضافيتان zEVM من دعم البرمجة العامة ونشر منطق أعمال محدد وتعديل الحالة ذريًا على سلاسل مختلفة. إذا حدثت عملية عبر سلسلة واكتشفت ZetaChain أن الخطوات اللاحقة لهذه العملية عبر السلسلة غير ناجحة على السلسلة المستهدفة، فيمكن التراجع عن البيانات المعدلة بواسطة معاملة عبر السلسلة في عقد ZetaChain، كما لو لم يحدث شيء . بالإضافة إلى ذلك، لا يحتاج تطبيق DAPP لتطبيق Omnichain إلى نشر عقود أصول التعيين على سلاسل مختلفة. إنها تحتاج فقط إلى استخدام العقد على سلسلة ZetaChain لإعداد منطق معالجة الرسائل عبر السلسلة مركزيًا في محطة واحدة، دون الحاجة إلى نشر العقود عبر السلسلة بشكل متكرر في شبكة متعددة السلاسل. وهذا يمكن أن يوفر بشكل كبير تكلفة تطوير DAPP كاملة السلسلة. على مستوى المستخدم، نظرًا لعدم وجود حاجة للتفاعل بشكل متكرر مع عقود الأصول المعينة على سلاسل متعددة، فإن التكلفة أقل من تكلفة الجسور الرئيسية عبر السلاسل التي تتطلب نشر عقود الأصول المعينة على سلاسل مختلفة. بالإضافة إلى ذلك، يمكن أيضًا نشر عقود DeFi الخاصة وأصول ZRC-20 أو حتى NFT على ZetaChain لمزامنة البيانات حول حالة الأصول أو نشر حسابات AA. وهذا يمنحها إمكانات النظام الأساسي الموحد لإدارة الأصول (تسجيل الحالة). نظرًا لأننا لم نعد بحاجة إلى العمل الجاد لامتلاك الأصول في سلاسل متعددة، فإن هذا السيناريو الخاص بحسابات الأصول الموحدة عبر السلسلة يمكن أن يولد المزيد من الإمكانات في المستقبل.

خاتمة

مما ناقشناه في هذه المقالة، اكتسبنا فهمًا أفضل لـ "البنية التحتية لقابلية التشغيل البيني متعددة السلسلة" الخاصة بـ ZetaChain. من خلال وحدة المراقب في عميل المدقق، تراقب ZetaChain رسائل/معاملات محددة على السلاسل الخارجية، وتبلغ عنها إلى وحدة المدقق، وتحقق الإجماع على الرسائل داخل شبكة ZetaChain، وتوزع البيانات الموجودة في الرسائل، وتولد التوقيعات الرقمية باستخدام TSS، و يؤدي إلى تشغيل عمليات المعاملات اللاحقة على السلاسل المستهدفة المقابلة، وبالتالي تحقيق التفاعلات عبر السلسلة عبر الشبكة بأكملها. في الوقت نفسه، تتيح لنا العقود الذكية متعددة الاستخدامات المستندة إلى ZetaChain التفاعل بشكل وثيق مع سلاسل الكتل المختلفة دون الحاجة إلى استخدام عقود الأصول التعيينية على سلاسل مختلفة. وهذا يلغي استدعاء منطق العقد الزائد، مما يوفر تكاليف المعاملات. بالإضافة إلى ذلك، نظرًا لأن ZetaChain متوافق مع EVM، يمكن لأي مطور DApp أو حتى مستخدمين فرديين نشر منطق معالجة الرسائل عبر السلسلة المخصص. من الناحية النظرية، يمكن للمرء نشر عقد DApp بأكمله بطريقة شاملة. لا يحتاج مطورو التطبيقات عبر السلاسل إلى نشر/تحديث منطق عقد أصول التعيين بشكل متكرر على سلاسل مختلفة، مما يلغي تكلفة التطوير الزائدة عن الحاجة.

تنصل:

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

البنية التحتية الشاملة لـ Omnichain DAPP

متوسط2/29/2024, 3:40:32 AM
تتعمق هذه المقالة في الجوانب التقنية لحل ZetaChain متعدد السلسلة، موضحًا كيف يعمل كبنية تحتية أساسية لقابلية التشغيل البيني متعدد السلسلة لـ DAPPs، مما يتيح دقة ومعالجة سلسة للرسائل عبر السلسلة.

إعادة توجيه العنوان الأصلي: رؤى فنية حول ZetaChain: بنية تحتية شاملة لـ OmniChain DAPP

ZetaChain هي سلسلة عامة لنقاط البيع تعتمد على Cosmos SDK، حيث تسجل كتلها الرسائل والبيانات عبر السلاسل التي تبدأ على "سلاسل خارجية". يمكن للمستخدمين في السلاسل الخارجية مثل BTC توصيل نواياهم إلى شبكة ZetaChain عن طريق نشر الرسائل بتنسيق معين، على غرار بروتوكول Ordinals. تستخدم عقد ZetaChain آلية إجماع لتحديد الرسائل التي سيتم معالجتها وتسلسلاتها، وفي النهاية تستخدم نظام توقيع العتبة (TSS) لإنشاء توقيع رقمي على السلسلة المستهدفة. تتضمن هذه العملية تحرير الأصول من الحساب العام للسلسلة، مما يؤدي إلى بدء خطوات المعاملة اللاحقة.


تتضمن القائمة الحالية لعقد التحقق في ZetaChain العديد من أطراف المشروع والمؤسسات، مثل OKX وHashKey Cloud وDora Factory وغيرها. نظرًا لتوافق ZetaChain المتأصل مع EVM، فإنه يدعم نشر منطق العقد. يمكن لمطوري التطبيقات اللامركزية ذات السلسلة الكاملة كتابة برامج معالجة الرسائل عبر السلسلة مباشرة على ZetaChain، مما يلغي الحاجة إلى نشر عقود الأصول المؤقتة عبر سلاسل متعددة وبالتالي توفير تكاليف التطوير. من وجهة نظر المستخدم، من الناحية النظرية، يعد التفاعل مع عقود ZetaChain كافيًا، مما يلغي الحاجة إلى تفاعلات متعددة مع العقود المؤقتة بين سلاسل المصدر والهدف وتقليل تكاليف رسوم المعاملات. على غرار بعض مشاريع Intent ذات تأثير "سلسلة حفظ الأصول الشاملة"، تدعم ZetaChain نشر عقود الأصول أو بروتوكولات التمويل اللامركزي. يمكن للمستخدمين إنشاء رسائل محددة على الواجهة الأمامية للتطبيقات اللامركزية على سلاسل مختلفة للاتصال بشكل غير متزامن بعقود التمويل اللامركزي الخاصة بـ ZetaChain أو حالات الأصول. يدعم هذا الإعداد حسابات سلسلة BTC أيضًا. إنه يشبه السماح لـ ZetaChain باستضافة حساب أصول موحد عالميًا مباشرة عبر جميع السلاسل. ومع ذلك، يتطلب تحقيق هذا التأثير واجهة أمامية مخصصة لتطبيق DApp للتعاون. اعتبارًا من الآن، تتمثل الوظيفة الأساسية لـ ZetaChain في العمل كبنية تحتية أساسية لقابلية التشغيل البيني لـ Omnichain. يمكنه تحليل ومعالجة رسائل محددة عبر السلاسل ويعمل أيضًا كمنصة تنفيذ منطق الأعمال للتطبيقات اللامركزية متعددة السلاسل. يدور نموذج العمل الرئيسي حول السيناريوهات النموذجية من B إلى B إلى C.

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

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

لمعالجة مسألة قابلية التشغيل البيني للسلسلة الشاملة، اقترحت LayerZero وPolyhedra وMap Protocol وBool Network وحتى Cosmos وPolkadot حلولاً مختلفة للمراسلة عبر السلاسل. تعد ZetaChain التي تم إطلاقها مؤخرًا، والتي قدمت رمزها المميز، لاعبًا أساسيًا في مشهد البنية التحتية لـ Omnichain.

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

التحديات التي تواجه الحلول عبر السلسلة الحالية

في الواقع، إن أبسط سيناريو يحتاج الجسر عبر السلسلة إلى معالجته هو نقل الأصول عبر سلاسل مختلفة. على سبيل المثال، عند نقل الأصول من ETH إلى Polygon، تحتاج أولاً إلى نقل الأصول إلى عنوان إيداع معين على سلسلة ETH ثم الحصول على مبلغ معادل على سلسلة Polygon. ينشأ التحدي لأن العقد المضلعة لا يمكنها تأكيد ما حدث في سلسلة ETH ولا تعرف ما إذا كنت قد قمت بالفعل بإيداع المبلغ المحدد. إذا ادعى شخص ما كذبًا أنه قام بإيداع 100 USDT في عنوان ETH المعين وبدأ مطالبة بالسحب على سلسلة Polygon لتحرير 100 USDT الخاص به، فإن ذلك يؤدي إلى مشكلة "السحب من لا شيء". إن مفتاح الجسر عبر السلسلة هو حل مثل هذه المشكلة من خلال التأكد من أن جميع مطالبات السحب تتوافق مع أنشطة الإيداع الفعلية. بشكل أساسي، يتضمن ذلك إثبات السلسلة B أنه كانت هناك بالفعل معاملات N مرتبطة بالجسر عبر السلسلة في السلسلة A.


حاليًا، تميل الجسور السائدة عبر السلاسل إلى اعتماد آلية كاتب العدل، والتي تتضمن إنشاء مجموعة من عقد كاتب العدل التي تصل إلى "الإجماع" من خلال التوقيع المتعدد أو توقيعات MPC. طالما أن غالبية عقد كاتب العدل توافق على أنه يمكن الموافقة على الإجراء عبر السلسلة، فيمكن عبور أصولك بسلاسة. تستخدم بعض الجسور عبر السلسلة قفل تجزئة أكثر أمانًا أو تنفذ العقد الخفيفة لسلاسل أخرى من خلال العقود الموجودة على السلسلة. تؤكد هذه الجسور صحة الأنشطة عبر السلسلة من خلال تلقي إثباتات Merkle أو إثباتات ZK. ومع ذلك، فإن تكلفة هذه الجسور عبر السلاسل غالبًا ما تكون أعلى ويتم تحويلها في النهاية إلى رسوم معاملات المستخدمين. لذلك، لا تزال معظم الجسور عبر السلسلة تختار نموذج عقدة كاتب العدل خارج السلسلة للتوافق متعدد التوقيعات. المرجع: توضيح ما هي الاعتبارات المهمة عند تصميم الجسور عبر السلاسل؟ومن الجدير بالذكر أن الجسور عبر السلسلة القائمة على كاتب العدل غالبًا ما تواجه مخاطر كبيرة، بما في ذلك التعرض للقرصنة أو السرقة من الداخل. وفقًا لإحصائيات SlowMist Hacked، كان هناك 16 حادثًا أمنيًا يتعلق بالجسور المتقاطعة في عام 2022، مما أدى إلى خسارة إجمالية قدرها 1.21 مليار دولار. ويمثل هذا 32% من إجمالي الخسائر الناجمة عن حوادث الهجمات على السلسلة في ذلك العام، مما يسلط الضوء على مخاطر الثغرات الأمنية في الجسور عبر السلسلة.


بالإضافة إلى ذلك، تعتمد العديد من حلول الجسور عبر السلسلة الحالية في الغالب نموذج Lock-Mint، حيث يتم قفل الأصول على السلسلة A ويتم إصدار الأصول المعينة المقابلة على السلسلة B لتحقيق نقل الأصول عبر السلسلة. ومع ذلك، يتطلب تدفق معالجة الإيداع والسحب في مثل هذه الحلول تفاعلات متعددة مع عقد الأصول المعينة، مما يؤدي إلى احتكاك كبير وخسارة محتملة للأموال. بالإضافة إلى ذلك، تدعم العديد من حلول الجسور عبر السلاسل فقط عمليات نقل الأصول بين السلاسل المتوافقة مع EVM، مما يواجه تحديات في التفاعلات عبر السلاسل بين السلاسل غير المتجانسة مثل Solana وBitcoin بسبب الاختلافات في المعايير الفنية. وبالنظر إلى القضايا المتعلقة بالأمن والرسوم، غالبًا ما تكافح حلول الجسر عبر السلسلة السائدة لتحقيق النتائج المثلى ولا يمكنها ضمان نقل الأصول "عبر السلسلة الأصلية". في النظام البيئي للبيتكوين اليوم، هناك رغبة متزايدة في تجربة تفاعل سلسة ومبتكرة عبر السلاسل، مع توقع حل أكثر كفاءة. تعالج ZetaChain هذا التحدي بنهجها الفريد.

وظائف ZetaChain: البنية التحتية الأساسية لـ DAPPs القابلة للتشغيل المتبادل عبر السلاسل

تضع ZetaChain نفسها كبنية تحتية أساسية للتطبيقات اللامركزية القابلة للتشغيل المتبادل متعددة السلسلة، وهي متخصصة في دعم بروتوكولات التطبيقات المختلفة للتفاعلات عبر السلسلة - وهي نموذج للبنية التحتية الأساسية من B إلى B إلى C. إنها تستخدم آلية قبول PoS، مما يسمح للعقد بتراكم الأصول بالدخول إلى الشبكة والعمل كموثقين. تشارك جميع نقاط إثبات الحصة (PoS)، التي تستخدم تقنية TSS، في التحقق من الرسائل عبر السلسلة ومعالجتها، بهدف تعزيز الأمان قدر الإمكان. وفي الوقت نفسه، تسهل ZetaChain نشر العقود الذكية، التي تتضمن منطق الأعمال المتعلق بمقايضة الأصول. يمكن للمستخدمين إرسال رسائل بتنسيق معين على أي سلسلة، أو الاتصال بـ ZetaChain أو عقود التمويل اللامركزي المدعومة الخاصة بها على سلاسل متعددة. على سبيل المثال، في BTC، يمكن للمستخدمين الاتصال بشكل غير مباشر بوظائف DeFi على Polygon. والنتيجة هي تسهيل نقل الرسائل بين سلاسل الكتل المختلفة، وتحقيق قابلية التشغيل البيني.


يمكن للتطبيقات اللامركزية القائمة على سيناريو التشغيل البيني الشامل أن تنشر منطق أعمال تبادل الأصول على ZetaChain، مما يسهل التحويل التلقائي لرموز الغاز عبر سلاسل مختلفة للمستخدمين. على سبيل المثال، باستخدام الواجهة الأمامية لبعض التطبيقات اللامركزية متعددة الاستخدامات (omnichain DApps)، يمكنك إصدار رسالة بتنسيق محدد على BTC، على غرار بروتوكول Ordinals، للإشارة إلى استدعاء عقد على Solana. ستكتشف عقد ZetaChain هذه الرسالة، وبعد ذلك، يمكن لعقد AMM على ZetaChain حساب نسبة التبادل بين BTC وSOL تلقائيًا. ثم تقوم بعد ذلك بتحرير مبلغ معادل من SOL على سلسلة Solana، واستكمال الخطوات اللاحقة مثل عقود الاتصال، وأخيرًا، تحويل الأصول المستحقة مرة أخرى إلى عنوان BTC أو Solana الخاص بك. يُشار إلى هذه العملية باسم "قابلية التشغيل البيني للسلسلة الشاملة"، حيث تحتاج فقط إلى نشر رسالة على سلسلة واحدة للاتصال عن بعد بالتطبيقات اللامركزية على سلاسل متعددة. في هذا السياق، يمكن تصور ZetaChain على أنه "طبقة تسوية سلسلة السلاسل". في جميع سيناريوهات التفاعل متعدد السلاسل، مثل بدء مكالمة من السلسلة A إلى DApp على السلسلة B، يكون الأمر أقرب إلى تسوية السلسلة A مع ZetaChain أولاً. تقوم ZetaChain بعد ذلك بمزامنة نتائج التسوية المُجهزة مسبقًا مع الحساب المقابل في السلسلة B، واستكمال الخطوات اللاحقة. طوال هذه العملية، لا يوجد تفاعل مفرط مع رسم خرائط عقود الأصول أو الاحتكاك في رسوم المعاملات. يتم تسهيل تداول الأصول من خلال حسابات ZetaChain العامة عبر سلاسل مختلفة، مما يلغي الحاجة إلى النشر المتكرر لعقود أصول الخرائط على سلاسل مختلفة، كما هو موضح في التطبيقات التقليدية عبر السلاسل.

في الوقت الحالي، يبدو أن تطبيقات Omnichain المستندة إلى ZetaChain يمكن أن توفر قدرًا كبيرًا من المتاعب، مما يلغي الحاجة إلى تصميم عقود الأصول بدقة على سلاسل مختلفة. تتم معالجة جميع التفاصيل المتعلقة بتدفق الأصول الداخلة والخارجة بين سلاسل المصدر والهدف بواسطة ZetaChain. بمعنى آخر، ما عليك سوى نشر منطق الأعمال المتعلق بالمعاملات عبر السلسلة على ZetaChain. وهذا يسهل تطبيقات السلسلة الكاملة المختلفة لدعم السلاسل غير التابعة لـ EVM مثل Solana وAlgorand وBitcoin وDogeCoin في الواجهة الأمامية دون الحاجة إلى تنفيذ عقود تطبيقات مخصصة عبر السلاسل على نطاق واسع على سلاسل مختلفة. بالإضافة إلى ذلك، تدعم ZetaChain نفسها نشر عقود الأصول أو حسابات AA (الأصول المستقلة). يمكن للمستخدمين في سلاسل مختلفة إرسال رسائل بتنسيق معين لاستدعاء هذه العقود، كما لو كانوا يقومون بتشغيل حساب موحد عبر السلاسل. يتيح نهج التصميم هذا، الذي ينعكس أيضًا في Particle Chain الخاصة بـ Particle Network، للمستخدمين في النهاية مركزية سجلات البيانات الخاصة بأصولهم على ZetaChain أو Particle Chain. عند الضرورة، يمكن للمستخدمين الاتصال بشكل غير متزامن بعقود الأصول الخاصة بهم على ZetaChain عن طريق إرسال رسائل استدعاء من خلال الواجهة الأمامية للتطبيقات اللامركزية على "السلاسل الخارجية". بعد ذلك، تقوم ZetaChain، عبر الحساب العام على السلسلة الخارجية، بنقل كمية معينة من الأصول إلى العنوان المحدد من قبل المستخدم أو تتفاعل مع بروتوكول DeFi المحدد من قبل المستخدم.


تتطلب سلسلة العمليات هذه تطبيقات DApps للواجهة الأمامية المتخصصة لتنفيذها. بمعنى آخر، توفر ZetaChain نفسها الخدمات فقط باعتبارها البنية التحتية الأساسية لـ Omnichain، ويجب أن يكون هناك مدخل أمامي مخصص في نهاية التطبيق لإنشاء رسائل بتنسيق معين.

نموذج أمان ZetaChain: شبكة عقد كاتب عدل كبيرة تعتمد على نظام نقاط البيع

في النهاية، ZetaChain هي في الأساس شبكة من عقد التحقق المصممة لمعالجة الرسائل عبر السلسلة. تم بناءه على Cosmos SDK، وهو يشتمل على العديد من عقد التحقق من الصحة ويستخدم نقطة البيع كآلية قبول، وبالتالي تحقيق مقاومة ضد هجمات Sybil وضمان الأمن الأساسي.

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


(تتضمن القائمة الحالية لعقد التحقق من صحة Zetachain العديد من أطراف المشروع أو المؤسسات) يتضمن عميل Zetachian's Validator وحدتين، ZetaCore وZetaClient. تشارك وحدة ZetaCore في إنشاء كتل ZetaChain وعملية الإجماع، بينما تراقب وحدة ZetaClient الأحداث على السلاسل الخارجية وتوقع المعاملات الصادرة. هنا، يمكن فهم كلمة "صادرة" ببساطة على أنها تسجيل سجل المعاملات على ZetaChain وإرساله إلى "سلاسل خارجية" (في إشارة إلى سلاسل خارج ZetaChain). يؤدي هذا إلى تشغيل الإجراءات المقابلة على السلسلة المستهدفة، حيث يتضمن المحتوى بشكل أساسي عنوان العقد ومعرف السلسلة ومحتوى الرسالة المعلن عنها من قبل المستخدم في الرسالة، على غرار قسم السجل في معاملات إيثريوم.


على العكس من ذلك، يمكن فهم "الوارد" على أنه تسجيل الرسائل/المعاملات ذات الصلة على سلاسل خارجية خارج ZetaChain، مثل الطلبات عبر السلاسل، واستدعاء العقود الذكية على zEVM، وما إلى ذلك، على ZetaChain. من المهم ملاحظة أنه عند تشغيل عقد Validator لـ ZetaChain، يتضمن رمز العميل ثلاث وحدات: Validator، وObserver، وTSS Signer. تتمتع هذه الوحدات الثلاث بوظائف مختلفة ولكنها جميعها تنتمي إلى عميل ZetaChain.

وحدات المراقب و TSS Signer

أولاً، تحتوي جميع عقد ZetaChain على وحدة "Validator"، مع وظائف مشابهة لعقد Validator في سلاسل PoS العامة، والمشاركة في عمليات إنشاء الكتل والإجماع. بالإضافة إلى ذلك، يمكن للعقد التصويت على المقترحات الموجودة على السلسلة بناءً على نسبة الرموز المميزة (ZETA). تحتوي كتل ZetaChain على جميع السجلات والتفاعلات عبر السلاسل التي تمت معالجتها مع عقود Omnichain الذكية، والتي تعمل كسجل.

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

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

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


(في الوضع النشط، تحتاج العقد إلى تشغيل عميل العقدة الكامل للسلاسل الخارجية. في الوضع السلبي، يتم تشغيل العملاء الخفيفين فقط للسلاسل الخارجية، وتلقي الرسائل عبر السلسلة وإثباتات Merkle من عقد ZetaChain في الوضع النشط لتأكيد صحة الرسائل.

توقيع خدمات الدعم الفني

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


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


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

zEVM: منصة عقد DAPP شاملة ومتعددة السلاسل

على عكس الحلول التقليدية عبر السلاسل التي تتطلب نشر عقود أصول التعيين على كل سلسلة، تحقق ZetaChain وظائف عبر السلاسل من خلال نشر عقد ذكي مرة واحدة فقط على سلسلتها الخاصة. في ZetaChain، توجد طبقة تنفيذ متوافقة مع EVM تسمى zEVM، حيث يمكن نشر العقود الذكية عبر السلسلة مباشرة. يدعم zEVM الميزات التالية: يمكن لأي شخص إرسال بيانات المعاملات بتنسيق معين على السلسلة الخارجية واستدعاء عقد على zEVM؛ يمكن لمنطق العقد الموجود على zEVM التحكم في بيانات المعاملات الصادرة التي تم إنشاؤها على السلسلة الخارجية. تمكّن هاتان الميزتان الإضافيتان zEVM من دعم البرمجة العامة ونشر منطق أعمال محدد وتعديل الحالة ذريًا على سلاسل مختلفة. إذا حدثت عملية عبر سلسلة واكتشفت ZetaChain أن الخطوات اللاحقة لهذه العملية عبر السلسلة غير ناجحة على السلسلة المستهدفة، فيمكن التراجع عن البيانات المعدلة بواسطة معاملة عبر السلسلة في عقد ZetaChain، كما لو لم يحدث شيء . بالإضافة إلى ذلك، لا يحتاج تطبيق DAPP لتطبيق Omnichain إلى نشر عقود أصول التعيين على سلاسل مختلفة. إنها تحتاج فقط إلى استخدام العقد على سلسلة ZetaChain لإعداد منطق معالجة الرسائل عبر السلسلة مركزيًا في محطة واحدة، دون الحاجة إلى نشر العقود عبر السلسلة بشكل متكرر في شبكة متعددة السلاسل. وهذا يمكن أن يوفر بشكل كبير تكلفة تطوير DAPP كاملة السلسلة. على مستوى المستخدم، نظرًا لعدم وجود حاجة للتفاعل بشكل متكرر مع عقود الأصول المعينة على سلاسل متعددة، فإن التكلفة أقل من تكلفة الجسور الرئيسية عبر السلاسل التي تتطلب نشر عقود الأصول المعينة على سلاسل مختلفة. بالإضافة إلى ذلك، يمكن أيضًا نشر عقود DeFi الخاصة وأصول ZRC-20 أو حتى NFT على ZetaChain لمزامنة البيانات حول حالة الأصول أو نشر حسابات AA. وهذا يمنحها إمكانات النظام الأساسي الموحد لإدارة الأصول (تسجيل الحالة). نظرًا لأننا لم نعد بحاجة إلى العمل الجاد لامتلاك الأصول في سلاسل متعددة، فإن هذا السيناريو الخاص بحسابات الأصول الموحدة عبر السلسلة يمكن أن يولد المزيد من الإمكانات في المستقبل.

خاتمة

مما ناقشناه في هذه المقالة، اكتسبنا فهمًا أفضل لـ "البنية التحتية لقابلية التشغيل البيني متعددة السلسلة" الخاصة بـ ZetaChain. من خلال وحدة المراقب في عميل المدقق، تراقب ZetaChain رسائل/معاملات محددة على السلاسل الخارجية، وتبلغ عنها إلى وحدة المدقق، وتحقق الإجماع على الرسائل داخل شبكة ZetaChain، وتوزع البيانات الموجودة في الرسائل، وتولد التوقيعات الرقمية باستخدام TSS، و يؤدي إلى تشغيل عمليات المعاملات اللاحقة على السلاسل المستهدفة المقابلة، وبالتالي تحقيق التفاعلات عبر السلسلة عبر الشبكة بأكملها. في الوقت نفسه، تتيح لنا العقود الذكية متعددة الاستخدامات المستندة إلى ZetaChain التفاعل بشكل وثيق مع سلاسل الكتل المختلفة دون الحاجة إلى استخدام عقود الأصول التعيينية على سلاسل مختلفة. وهذا يلغي استدعاء منطق العقد الزائد، مما يوفر تكاليف المعاملات. بالإضافة إلى ذلك، نظرًا لأن ZetaChain متوافق مع EVM، يمكن لأي مطور DApp أو حتى مستخدمين فرديين نشر منطق معالجة الرسائل عبر السلسلة المخصص. من الناحية النظرية، يمكن للمرء نشر عقد DApp بأكمله بطريقة شاملة. لا يحتاج مطورو التطبيقات عبر السلاسل إلى نشر/تحديث منطق عقد أصول التعيين بشكل متكرر على سلاسل مختلفة، مما يلغي تكلفة التطوير الزائدة عن الحاجة.

تنصل:

  1. تمت إعادة طباعة هذه المقالة من [极客 Web3]، جميع حقوق الطبع والنشر مملوكة للمؤلف الأصلي [Howe & Faust، 极客web3]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسوف يتعاملون معها على الفور.
  2. إخلاء المسؤولية: الآراء والآراء الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
  3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ أو توزيع أو سرقة المقالات المترجمة.
ابدأ التداول الآن
اشترك وتداول لتحصل على جوائز ذهبية بقيمة
100 دولار أمريكي
و
5500 دولارًا أمريكيًا
لتجربة الإدارة المالية الذهبية!