كيف تعمل البنية التحتية عبر السلاسل؟ استكشاف معمّق لبروتوكول Gravity للتشغيل البيني والبنية الأصلية للأورا

الأسواق
تم التحديث: 06/29/2026 04:11

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

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

تقدم Gravity إجابة معمارية مختلفة جذريًا. تم تطويرها بواسطة فريق Galxe، وتعد Gravity شبكة بلوكشين عالية الأداء ومتوافقة بالكامل مع EVM كطبقة أولى. يكمن تميزها الأساسي في الأوراكل الأصلي—آلية يعمل فيها نفس مجموعة المدققين، تحت إجماع AptosBFT، على إنتاج الكتل مع مراقبة البيانات الخارجية والتصويت وكتابة النتائج على الطبقة الأولى في الوقت ذاته. لا توجد شبكة أوراكل خارجية، ولا لجنة توقيعات متعددة مستقلة. جسر العبور ليس خدمة منفصلة؛ بل هو عقد ذكي يستقبل البيانات التي تم تقديمها مسبقًا من قبل مجموعة المدققين.

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

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

الرسائل العابرة للسلاسل: التحول من نموذج "السحب" إلى "الدفع"

تشكّل الرسائل العابرة للسلاسل الطبقة التأسيسية لجميع بروتوكولات التوافقية. في جوهرها، يتمثل التحدي في: كيف تثبت الشبكة A للشبكة B أن "حدثًا ما قد وقع"؟

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

آلية الرسائل في Gravity، المبنية على الأوراكل الأصلي، تغير هذا الإجراء جذريًا. الأوراكل الأصلي هو عقد واحد يُنشر على عنوان نظام ثابت في Gravity L1: NativeOracle → 0x0000000000000000000000000001625F4000. يتيح هذا العقد عملية أساسية، record، لا يمكن استدعاؤها إلا بواسطة SYSTEM_CALLER—هوية خاصة في وقت الإجماع، وليست حسابًا عاديًا.

تستقبل دالة record المعاملات التالية: نوع المصدر (sourceType، مثل البلوكشين)، معرف المصدر (sourceId، مثل معرف الشبكة)، رقم متسلسل (nonce)، رقم كتلة الشبكة المصدر، الحمولة (بيانات ثنائية غير واضحة)، وحد غاز الاستدعاء المرتد. هناك أيضًا متغير recordBatch لإرسال عدة أحداث من نفس المصدر ضمن معاملة واحدة.

ثلاثة خيارات تصميمية رئيسية تبرز هنا:

أولًا، حماية مركزية ضد إعادة التشغيل. يفرض الأوراكل الأصلي شرط nonce == currentNonce + 1 لكل زوج (sourceType, sourceId)—مما يضمن تسلسلًا صارمًا دون فجوات. لا يمكن إعادة تشغيل الرسائل القديمة لأن العقدة تجاوزت بالفعل رقمها المتسلسل. لم تعد معالجات التطبيقات بحاجة للاحتفاظ بخرائط أرقام متسلسلة تمت معالجتها. هذا يعني أن منطق إزالة التكرار للرسائل العابرة للسلاسل يُرفع إلى طبقة البروتوكول، بدلًا من تركه لكل عقدة تطبيقية—مما يقلل العبء الأمني على المطورين بشكل كبير.

ثانيًا، التوجيه المرتد بدلًا من الاستطلاع. يمكن لكل زوج (sourceType, sourceId) تسجيل عقدة رد نداء. عند تسجيل البيانات، يستدعي الأوراكل الأصلي دالة onOracleEvent الخاصة بالمعالج المسجل، باستخدام حد الغاز المحدد من قبل المستدعي. هناك طبقتان من التحليل: معالج افتراضي لكل نوع مصدر، يمكن تجاوزه بمعالج متخصص لمعرف مصدر معين. تدير الحوكمة السجل. يسمح هذا النموذج "الدافع" لعقود التطبيقات باستقبال الإشعارات وتنفيذ المنطق فور وصول البيانات العابرة للسلاسل، دون الحاجة للاستطلاع المستمر للحالة.

ثالثًا، تحمل أخطاء رد النداء. يعيد المعالج قيمة shouldStore: bool—المعالجات التي تستهلك الحمولة بالكامل (وتطبقها على حالتها الخاصة) يمكنها إعادة false لتجاوز التخزين وتوفير الغاز. إذا فشل المعالج أو نفد الغاز، يلتقط الأوراكل الأصلي الاستثناء، ويصدر حدث CallbackFailed(reason)، ويخزن الحمولة رغم ذلك. عملية التسجيل تنجح دائمًا، بغض النظر عن الظروف.

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

نموذج التحقق والأمان: قفل واحد، مفتاح واحد

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

تستخدم Gravity آلية تحقق إثبات الحصة (Proof-of-Stake). يقوم المدققون بتخزين رموز G للمشاركة في الإجماع وإثبات الأوراكل الأصلي. محرك الإجماع هو AptosBFT، الذي يوفر حسمًا نهائيًا عالي السرعة. تؤمن مجموعة المدققين الشبكة بعتبة ثلثي الأصوات—وهي نفس العتبة التي تضمن أصالة بيانات الأوراكل الأصلي.

ماذا يعني ذلك؟

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

من منظور الأصول العابرة للسلاسل، يقضي هذا النموذج على خطر "الموقع الخارجي للتوقيع" في الجسور التقليدية. يتكون جسر Gravity الكلاسيكي بين Ethereum وCosmos من جزأين: عقدة ذكية بلغة Solidity على Ethereum، ووحدة بلوكشين مبنية على Cosmos SDK. يودع المستخدمون الأصول على أحد الجانبين ويتم سك رموز مقابلة على الجانب الآخر. في بنية الأوراكل الأصلي لـ Gravity L1، يعد جسر الأصول بين Ethereum وGravity L1 أول تطبيق جاهز للإنتاج للأوراكل الأصلي. لا توجد شبكة أوراكل خارجية، ولا مجموعة توقيعات مستقلة فوق الإجماع.

ومن الجدير بالذكر أيضًا أن Gravity يخضع لترقية أمنية كبيرة. في يونيو 2026، أعلنت Gravity أنه كجزء من إطلاق شبكة L1 الرئيسية، سيتم الترقية من LayerZero إلى Chainlink CCIP كبنية تحتية موحدة للعبور بين السلاسل. ستصبح رموز Gravity الأصلية، G، أصلًا أصليًا عابرًا للسلاسل (CCT)، مما يمكّن المطورين من نشر الجسور عند الطلب، ونقل الأصول دون انزلاق سعري، والاستفادة من قابلية برمجة أكبر. ستعزز CCIP، بشبكة أوراكلها اللامركزية، الأمان والمرونة بشكل كبير للمطورين الذين يبنون تطبيقات عابرة للسلاسل على Gravity. توضح هذه الترقية أنه بالرغم من حفاظ Gravity على ميزة الأوراكل الأصلي الأساسية، إلا أنها تدمج أيضًا أكثر معايير العبور نضجًا في الصناعة.

تدفق الأصول العابرة للسلاسل من البداية للنهاية: شرح من ثماني خطوات

استنادًا إلى الآليات السابقة، يمكن تقسيم عملية نقل الأصول العابرة للسلاسل الكاملة (باستخدام Ethereum→Gravity L1 كمثال) إلى الخطوات التالية:

الخطوة 1: قفل الأصول من قبل المستخدم. يقوم المستخدم بإيداع ETH أو رموز ERC-20 في عقد جسر Ethereum الخاص بـ Gravity. يسجل هذا العقد حدث الإيداع، بما في ذلك عنوان المستخدم ونوع الأصل والمبلغ ومعلومات الشبكة الهدف.

الخطوة 2: حسم كتلة Ethereum. تراقب عقد مدققي Gravity باستمرار شبكة Ethereum. لا يعتمد المدققون على مرحلين خارجيين لدفع البيانات؛ بل يراقبون حالة Ethereum بشكل مستقل.

الخطوة 3: تصويت المدققين على الإجماع. في كل كتلة Gravity L1، يوقع المدققون ويبثون البيانات الخارجية التي يلاحظونها (بما في ذلك أحداث إيداع Ethereum) كجزء من حمولة الأوراكل الأصلي. تستخدم التوقيعات لنفس البيانات الخارجية نفس المفاتيح والعتبات المستخدمة في معاملات Gravity نفسها.

الخطوة 4: إرسال البيانات إلى الأوراكل الأصلي. بمجرد أن تصل مجموعة المدققين إلى إجماع حول حدث خارجي (تحقيق عتبة الثلثين)، تُكتب البيانات في عقد الأوراكل الأصلي على Gravity L1 عبر استدعاء record أو recordBatch.

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

الخطوة 6: تفعيل رد النداء. يستقبل عقد جسر الأصول، المسجل كمعالج رد نداء، استدعاء onOracleEvent. يقوم العقد بتحليل الحمولة، والتحقق من نوع وكمية الأصل، وتأكيد عنوان المستلم الهدف.

الخطوة 7: سك أو تحرير الأصول. يقوم عقد جسر الأصول بسك الكمية المقابلة من الأصول المرمزة بـ G على Gravity L1 (أو يحرر رموز G مباشرة في سيناريوهات الجسر الأصلي للأصول) وينقلها إلى عنوان المستخدم على Gravity.

الخطوة 8: تأكيد الحسم النهائي. تحقق العملية بأكملها حسمًا نهائيًا دون الثانية الواحدة تحت إجماع AptosBFT الخاص بـ Gravity. يمكن للمستخدمين استلام الأصول العابرة للسلاسل خلال 200 مللي ثانية من وقت الكتلة.

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

الأساس الأدائي: أكثر من 12,000 معاملة في الثانية وحسم نهائي دون الثانية

تعتمد قيمة هذا التصميم الميكانيكي على أداء قوي. المعايير التقنية لـ Gravity تجعل التوافقية العابرة للسلاسل قابلة للتطبيق عمليًا:

تستخدم الشبكة الرئيسية لـ Gravity محرك تنفيذ EVM متوازي Grevm (مشتق من revm). تحت الأحمال الحية، تحافظ Gravity على أكثر من 12,000 معاملة في الثانية لتحويلات ERC-20، مع وقت كتلة يبلغ 200 مللي ثانية. في اختبارات مع مجموعة من 3 عقد مدققين (كل منها 8 vCPU / 16 GB)، بقي الأداء بين 9,500 و11,000 معاملة في الثانية.

الأهم من ذلك هو هيكل الرسوم. مع رسم أساسي قدره 50 Gwei، تصبح مساحة الكتلة في Gravity فعليًا سلعة عامة وليست أصلًا تنافسيًا. تبلغ تكلفة كل تحويل ERC-20 حوالي $0.0026. هذا يكسر النموذج الاقتصادي التقليدي للطبقة الأولى، الذي يعتمد على ضغط الرسوم لزيادة قيمة الرمز. ينتقل التقاط القيمة إلى الخدمات المقدمة من المدققين (إثبات الأوراكل، البيانات العابرة للسلاسل، الجسور) والتحويلات على مستوى التطبيقات.

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

تاريخيًا، منذ إطلاق شبكة Gravity Alpha الرئيسية كطبقة ثانية مبنية على Arbitrum Nitro في أغسطس 2024، عالجت أكثر من 611 مليون معاملة عبر 28.5 مليون محفظة خلال 22 شهرًا، مع متوسط وقت كتلة 1.3 ثانية. يشكل هذا إثباتًا عمليًا لإطلاق الشبكة الرئيسية للطبقة الأولى.

بيانات السوق والرموز الاقتصادية

حتى 29 يونيو 2026، ووفقًا لبيانات سوق Gate، يبلغ سعر Gravity (G) $0.003641، مع زيادة خلال 24 ساعة بنسبة %13.78+، وارتفاع أسبوعي بنسبة %36.62+، وزيادة شهرية بنسبة %3.72+. تبلغ القيمة السوقية حوالي $26.33 مليون، في المرتبة 658. حجم التداول خلال 24 ساعة هو $29.20 مليون، مع إجمالي معروض يبلغ 12 مليار. المزاج السائد في السوق محايد. خلال العام الماضي، تغير السعر بنسبة %69.22-، مع أعلى سعر تاريخي عند $0.015440.

G هو الرمز الأصلي لـ Gravity L1، مع حد أقصى للمعروض يبلغ 12 مليار، انتقل من الرمز الأصلي GAL. عند إطلاق الشبكة الرئيسية، تلقى سبعة مدققين تأسيسيين حصة تخزين أولية قدرها 7 ملايين G. تم قفل الـ 7 ملايين G المقابلة بشكل دائم في عقد GBridgeSender على شبكة Ethereum الرئيسية لدعم رموز G الأصلية على الطبقة الأولى.

يعمل G كرمز غاز للمعاملات، ويؤمن الشبكة من خلال التخزين، ويقود قرارات الحوكمة، ويحفز النمو، ويسهل المدفوعات. يشارك حاملو G في الحوكمة عبر بروتوكول G DAO.

الخلاصة: نهاية التوافقية هي توحيد الثقة

يمكن تقسيم تطور التوافقية العابرة للسلاسل إلى ثلاث مراحل.

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

المرحلة الثانية هي بروتوكولات الرسائل العامة (مثل LayerZero وAxelar)، التي تدعم استدعاءات العقود الذكية العابرة للسلاسل، لكنها لا تزال تعتمد على مزيج من الأوراكل والمرحلين الخارجيين للتحقق.

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

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

هذا لا يعني أن Gravity تقضي على جميع المخاطر. مركزية مجموعة المدققين، واستقرار نموذج الحوافز الاقتصادية للتخزين على المدى الطويل، وثغرات العقود الذكية في التطبيقات العابرة للسلاسل، والتحديات الهندسية للانتقال من LayerZero إلى Chainlink CCIP كلها تتطلب مراقبة مستمرة. بالإضافة إلى ذلك، في مايو 2026، تعرض جسر Gravity لهجوم أسفر عن خسارة تقارب $5.4 مليون—تذكير بأن حتى أكثر البنى الهندسية صلابة تتطلب اختبارات مكثفة في الواقع العملي.

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

الأسئلة الشائعة

س1: ما هو الفرق الجوهري بين Gravity وبروتوكولات العبور مثل LayerZero وAxelar؟

تستخدم LayerZero بنية Ultra Light Node (ULN)، حيث يتحقق الأوراكل والمرحلين معًا من الرسائل العابرة للسلاسل. تعتمد Axelar على شبكة تحقق إثبات الحصة مستقلة وآلية General Message Passing (GMP). تدمج Gravity التحقق من البيانات العابرة للسلاسل مباشرة في طبقة الإجماع L1، مع نفس مجموعة المدققين ونفس عتبة BFT لتأمين كل من حالة الشبكة وأصالة البيانات العابرة للسلاسل.

س2: كيف يضمن الأوراكل الأصلي في Gravity أمان البيانات العابرة للسلاسل؟

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

س3: ما هي مؤشرات الأداء الحالية لـ Gravity؟

تحافظ Gravity L1 على أكثر من 12,000 معاملة في الثانية لتحويلات ERC-20 تحت الأحمال الحية، مع أوقات كتل تبلغ 200 مللي ثانية وحسم نهائي دون الثانية. تبلغ تكلفة كل تحويل ERC-20 حوالي $0.0026. عالجت الشبكة الرئيسية Alpha أكثر من 611 مليون معاملة خلال 22 شهرًا.

س4: ماذا يعني ترقية Gravity من LayerZero إلى Chainlink CCIP؟

في يونيو 2026، أعلنت Gravity عن Chainlink CCIP كبنية تحتية موحدة للعبور بين السلاسل. سيصبح رمز G أصلًا أصليًا عابرًا للسلاسل (CCT)، مما يمكّن المطورين من نشر الجسور عند الطلب، ونقل الأصول دون انزلاق سعري، والاستفادة من قابلية برمجة أعلى. ترفع هذه الترقية معايير أمان العبور في Gravity وراحة المطورين.

س5: ما هي الوظائف الرئيسية لرمز G؟

G هو رمز الغاز والتخزين الأصلي لـ Gravity L1. يشارك المدققون في الإجماع وإثبات الأوراكل الأصلي من خلال تخزين G. يتخذ حاملو G قرارات الحوكمة عبر بروتوكول G DAO، كما يخدم G كرمز للمدفوعات والحوافز ضمن منظومة Galxe.

The content herein does not constitute any offer, solicitation, or recommendation. You should always seek independent professional advice before making any investment decisions. Please note that Gate may restrict or prohibit the use of all or a portion of the Services from Restricted Locations. For more information, please read the User Agreement
أَعجِب المحتوى