كيف تعمل البنية التحتية للسلاسل المتقاطعة؟ تحليل معمق لبروتوكول التوافقية Gravity وهندسة الأوراكل الأصلية

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

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

تقدم Gravity إجابة معمارية مختلفة تمامًا. طورتها فريق Galxe، Gravity هي سلسلة بلوكشين من الطبقة الأولى عالية الأداء ومتوافقة تمامًا مع EVM، ونقطة الاختلاف الأساسية فيها هي الأوراكل الأصلي (Native Oracle) – حيث يقوم نفس مجموعة المدققين، تحت إجماع AptosBFT، بإنشاء الكتل وفي نفس الوقت يلاحظون البيانات الخارجية، ويصوتون ويكتبون على L1. لا توجد شبكة أوراكل خارجية، ولا توجد لجنة توقيع متعددة مستقلة. الجسر عبر السلاسل ليس خدمة مستقلة، بل هو عقد يستقبل البيانات التي تم تقديمها بالفعل من قبل مجموعة المدققين.

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

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

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

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

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

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

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

ثلاثة خيارات تصميم رئيسية تستحق التوضيح:

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

ثانيًا، توجيه الاستدعاء بدلاً من الاستقصاء. يمكن تسجيل عقد استدعاء لكل زوج (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 blockchain. يقوم المستخدم بإيداع الأصول على جانب واحد، ويتم سك الرموز المقابلة على الجانب الآخر. ولكن تحت بنية الأوراكل الأصلي لـ Gravity L1، فإن جسر الأصول من Ethereum إلى Gravity L1 هو أول تطبيق إنتاجي للأوراكل الأصلي. لا توجد شبكة أوراكل خارجية، ولا توجد مجموعة مستقلة من الموقعين مضافة فوق الإجماع.

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

العملية الكاملة للأصول عبر السلاسل: ثماني خطوات من الإيداع إلى الاستلام

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

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

الخطوة الثانية: نهائية كتلة Ethereum. يستمر المدققون في Gravity في مراقبة سلسلة Ethereum. لا يعتمد المدققون على وسطاء خارجيين لدفع البيانات، بل يلاحظون حالة Ethereum بأنفسهم.

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

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

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

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

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

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

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

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

قيمة آليات التصميم تحتاج إلى قاعدة أداء لتحملها. توفر معلمات الأداء لـ Gravity جدوى عملية لقابلية التشغيل البيني عبر السلاسل:

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

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

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

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

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

اعتبارًا من 29 يونيو 2026، وفقًا لبيانات أسعار Gate، سعر Gravity (G) هو $0.003641، بارتفاع +13.78% خلال 24 ساعة، +36.62% خلال 7 أيام، و+3.72% خلال 30 يومًا. تبلغ القيمة السوقية حوالي 26.3342 مليون دولار، محتلة المرتبة 658. حجم التداول على مدار 24 ساعة هو 29.1978 مليون دولار، وإجمالي العرض هو 12.0 مليار. معنويات السوق محايدة. على مدار العام الماضي، كان تغير السعر -69.22%، وأعلى سعر تاريخي هو $0.015440.

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

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

الخاتمة: نهاية قابلية التشغيل البيني هي توحيد الثقة

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

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

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

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

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

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

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

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

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

يعتمد LayerZero على بنية العقدة فائقة الخفة (ULN)، حيث يتحقق Oracle و Relayer معًا من الرسائل عبر السلاسل؛ يستخدم Axelar شبكة تحقق PoS مستقلة وآلية تمرير رسائل عامة (GMP). تقوم Gravity بدمج التحقق من البيانات عبر السلاسل مباشرة في طبقة إجماع L1، حيث تضمن نفس مجموعة المدققين بنفس عتبة BFT في نفس الوقت حالة السلسلة وصحة البيانات عبر السلاسل.

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

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

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

تحافظ Gravity L1 تحت أعباء العمل الفعلية على إنتاجية تزيد عن 12,000 TPS لتحويلات 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 البيئي.