Flare Confidential Compute يصوت لإطلاقه على Songbird

FCC هو أول تنفيذ لـFlare 2.0 vision الذي تم عرضه في مارس 2025، والذي يوسع توافق Flare إلى ما وراء سلسلته الخاصة من خلال دمج بيئات التنفيذ الموثوقة (TEEs) مع بروتوكولات بيانات Flare. يتم الإطلاق على مراحل. تجلب هذه المرحلة الأولى عمودين من أعمدة الرؤية إلى شبكة اختبار حية: المحافظ التي تديرها البروتوكولات (Protocol Managed Wallets - PMW)، والتي تمنح البروتوكولات تنفيذًا مُتحكمًا على سلاسل خارجية بدءًا من XRPL، وإطار امتداد الحوسبة للقيام بالحوسبة القابلة للتحقق والسرية. يوفر Flare Data Connector (FDC V2) المُحدث الأدلة الموقعة السريعة التي ربط بينهما.

هذا هو العمارة التي نشرتها Flare قبل عام، وتصل الآن إلى المطورين.

الأصل

حددت Flare 2.0 ثلاثة أشياء أرادت Flare توسيعها دون التخلي عن اللامركزية: التنفيذ عبر السلاسل، البيانات عالية النزاهة، والحوسبة الكبيرة. سميت طريقتين لتوفيرها، كلاهما مبنيان على TEEs وبروتوكولات بيانات Flare. سيتولى Protocol Managed Wallets تنفيذًا عبر السلاسل. سيتولى Verifiable Compute جانب الحوسبة.

توفر FCC كليهما. إطلاق Songbird يطلق PMW لركيزة التنفيذ عبر السلاسل وإطار امتداد الحوسبة لركيزة الحوسبة القابلة للتحقق، مع FDC V2 كطبقة بيانات مُحدثة بينهما. العمارة التي أُعلنت في مارس 2025 الآن تصل إلى شبكة اختبار حية.

ما هو FCC

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

نظرًا لأن المفاتيح الخاصة تُولد وتُدار داخل تلك TEEs، تسمح هذه الطبقة للبروتوكولات على Flare بالتنفيذ على سلاسل خارجية تحت توافق Flare. FCC ليست منتجًا واحدًا. إنها النظام المحيط بـ TEEs: العقود الذكية، الترحيل، التحقق، والتطبيقات المبنية فوقها.

ما سيصبح مباشرًا على Songbird

يتطلب الأمر تصويت حوكمي لأن النشر يضيف عقودًا جديدة على السلسلة ومسؤوليات جديدة لمزودي بيانات Songbird. التصويت هو STP، وهو قائم على الرفض: يمر ما لم يتم الوصول إلى عتبة النصاب 75٪ ويكون نصف الأصوات على الأقل ضده.

إذا نجح، يصبح ثلاثة مكونات مباشرة، ومعًا يشكلون النظام العامل الموضح أعلاه.

1. العقود الذكية على Songbird. هذه تُدير تسجيل آلات TEE، وتستقبل تعليمات المستخدم، وتتحقق من النتائج. البروتوكول يُرسل التعليمات إلى TEEs لكنه لا ينشر النتائج على السلسلة. المستهلكون يجرون جلب النتائج الموقعة من TEE ويُقدمونها.
2. مزودو البيانات كمرسلين. هذه هي المسؤولية الجديدة. كل مزود مشارك يشغل عميل ترحيل وخادم التحقق FDC V2. يحملون التعليمات من Songbird إلى TEEs ويوقعون ما يرسلونه. لا تُنفّذ TEE إلا بعد أن يحصل على توقيع أغلبية مرجحة من المزودين، وهذه الخطوة التوافقية هي التي تجعل الأمر مشروعًا. كما يتعامل المزودون مع الإضافة، حيث يعبئون تعليمات المستخدم بأي بيانات إضافية تحتاجها، سواء على السلسلة أو خارجها، قبل تقديمها.
3. آلات TEE. تعمل هذه الشيفرة الامتدادية داخل آلات افتراضية سرية وتُعيد النتائج الموقعة. عند الإطلاق على Songbird تُستضيف على Google Confidential Compute وتُدار بواسطة Flare Foundation. هذه هي نقطة الانطلاق. تم تصميمها لتتنوع عبر المشغلين ومزودي الأجهزة مع مرور الوقت، وهذا ليس الحالة النهائية.

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

لماذا يهم الآن

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

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

ما يتيح الإطلاق

Flare Data Connector V2. يتحقق FDC الحالي من الأحداث الخارجية على Flare عن طريق تجميع طلبات التوثيق في جولات تستغرق تقريبًا 90 ثانية، وتوقيع جذر Merkle، ونشره على السلسلة. يزيل FDC V2 تلك الكمون الزمني للجولة من خلال معالجة كل طلب على حدة عبر FCC. توقّع TEE استجابة التوثيق بمجرد أن يحصل على ما يكفي من التأكيدات الموقعة، ويجلب المستخدم هذه النتيجة ويُرسلها. يُطلق FDC V2 بأربعة أنواع من التوثيق تغطي مدى توفر TEE والتحقق من دفع PMW. عند إطلاق Songbird يعني ذلك توثيقًا أسرع ومعالجًا فرديًا، ويعمل كطبقة إثبات تجعل Protocol Managed Wallets موثوقة.

Protocol Managed Wallets. يسمح PMW لبروتوكول على Flare بإنشاء وتشغيل محفظة على سلسلة خارجية، مُتحكمًا بها قواعد البروتوكول بدلاً من شخص أو خادم خلفي. تُولد المفاتيح وتُحتفظ بها داخل TEEs، وتُوقع فقط عندما تُرسل الأغلبية المرجحة من مزودي البيانات التعليمات. وبالتالي تُؤمن المحفظة بتوافق Flare وضمانات الأجهزة الخاصة بـ TEE معًا، ويمكن للمستخدمين المهتمين بالسلامة إضافة مُوقعين مشاركين إلى حساب PMW، مما يتطلب من TEEs جمع توقيعات كل من مزودي البيانات والموقعين المشاركين قبل التوقيع. يتخطى هذا ما هو موجود في أنظمة التفاعل الحالية ويتجه نحو تجريد السلسلة: يتفاعل المستخدم فقط مع Flare، ويُنفذ البروتوكول في كل مكان آخر. في هذه المرحلة، يُطلق PMW بدعم XRPL.

يعمل الاثنان كقدرة واحدة: التنفيذ على سلاسل خارجية من Flare، مع إثبات أن الإجراء تم. يتولى PMW التنفيذ وتوفر FDC V2 الدليل. كما صرّحت Flare 2.0، كل نموذج استخدام لـ PMW يعتمد على Flare Data Connector لإثبات حدوث المعاملة المحددة. لهذا السبب تدعم ثلاثة من أربعة أنواع توثيق إطلاق FDC V2 الـ PMW. FDC V2 ليست منتجًا منفصلًا يُصاحب PMW صدافيًا. لكن FDC V2 أكثر من طبقة إثبات PMW. إنها نسخة مُحسَّنة من Flare Data Connector بحد ذاته — توثيقات أسرع ومعالجة فردية متاحة لأي شخص يبني على Flare، وليس فقط لـ FCC.

ما يفتحه

PMW وFDC V2 هما أولى التطبيقات، ليس الهدف الكامل. يشغلان على إطار عمل تُوجد آلياته منذ البداية. عند الإطلاق، تخدم آلات TEE هذه التطبيقات النظامية فقط، وإمكانية المطورين لنشر آلات TEE الخاصة بهم وتسجيل امتدادات مخصصة موجودة في العقود لكنها تُفعَّل لاحقًا خلال فترة الانطلاق. عندما يحدث ذلك، سيُعرّف المطور امتدادًا بعقد يستقبل التعليمات، ومجموعة من آلات TEE المسجلة، وقائمة بإصدارات الشيفرة المدعومة، ويُشغل منطقًا سريًا خاصًا به بنفس ضمانات الترحيل والتوقيع التي تؤمن PMW.

المهمة الأولى لـ PMW هي أوضح مثال على أهمية ذلك. تسمح بروتوكول على Flare بالاحتفاظ بحساب XRPL وتشغيله مباشرة، وهذا هو الأساس لجلب XRP إلى التمويل اللامركزي على Flare دون طلب من المستخدمين بناء جسر. هذا أحد تطبيقات الإطار. الآلية نفسها — المفاتيح المغلقة، الشيفرة المُعتمدة، النتائج الموقعة والمُتحقَّقة — هي ما يرثه أي امتداد مستقبلي. Songbird هو المكان الذي يُثبت فيه ذلك من البداية إلى النهاية على الشبكة الرئيسية لـ Flare.

يمكن للمطورين العثور على التحليل الفني الكامل، والعمارة، ودلائل البناء خطوة بخطوة في Flare Dev Hub.

تفاصيل التصويت

فترة الإشعار: 29 يونيو - 5 يوليو، 2026

فترة التصويت: 6 يوليو - 13 يوليو، 2026

اعرض اقتراح STP.13 على: https://proposals.flare.network/STP/STP_13.html

تحليل FTSOBest

ما الذي يتم إضافته؟

• ثلاث مجموعات عقود على السلسلة في Songbird:
  1. عقود تسجيل وتحقق TEE – تدير هوية الآلات وتتحقق من النتائج الموقعة.
  2. عقود موزع مزودي البيانات – كل مزود يشغل مُتحقق FDC V2 وعميل توجيه؛ يلزم وجود أغلبية موزونة من التوقيعات قبل أن يتم تنفيذ TEE.
  3. عقود إطار الامتداد – تكشف واجهة برمجة التطبيقات لاستلام التعليمات المستخدمة من قبل طبقة الحوسبة.
• آلات TEE – آلات افتراضية سرية تُستضيف مبدئياً على Google Confidential Compute، وتُدار بواسطة مؤسسة Flare.
• FDC V2 – تستبدل نموذج الاعتماد الدفعي الذي يستغرق 90 ثانية بنموذج توقيع لكل طلب، مما يقلل زمن الاستجابة للأدلة.
• المحافظ المُدارة بروتوكولياً (PMW) – تسمح لبروتوكول Flare بامتلاك وإنفاق من محفظة XRPL، مع إنشاء المفاتيح داخل TEEs وتوقيعها خاضع لإجماع الموزعين.
• صندوق المكافآت – يتم تمويله من قبل مؤسسة Flare ورسوم الاعتماد؛ لا إصدار رموز جديدة في مرحلة الإقلاع.

الاعتمادات التقنية

• بيئات التنفيذ الموثوقة (Trusted Execution Environments) – العزل المادي ضروري لسرية المفاتيح وتوليد الأدلة.
• Flare Data Connector (FDC) V2 – يوفر طبقة إثبات التنفيذ؛ يجب أن تُشغّل خوادم المتحقق من قبل مزودي البيانات.
• إجماع الموزعين بأغلبية موزونة – يضمن تنفيذ الأمر فقط عندما يوقع عدد كافٍ من المزودين، ربط التنفيذ بإجماع Flare.
• Google Confidential Compute (مبدئياً) – يعمل كأول مشغل TEE؛ سيتطلب التنويع المستقبلي شركاء أجهزة إضافيين وتحديثات عقود.

الآثار العملية

• للمستخدمين: يمكن استخدام الأصول على XRPL في تطبيقات Flare DeFi دون جسر؛ المفاتيح الخاصة لا تغادر TEE أبدًا، مما يقلل من سطح الهجوم.
• للمطورين: يحتوي مركز المطورين (https://dev.flare.network/fcc/overview) على البنية الكاملة وأدلة خطوة بخطوة. يمكن للبنائين لاحقًا تسجيل آلات TEE الخاصة بهم وامتدادات مخصصة بمجرد رفع فترة الإقلاع لقواطع العقود.
• للشبكة: تزيد العقود الجديدة من عدد الاستدعاءات على السلسلة (التسجيل، التحقق من الاعتماد، توزيع المكافآت). ومع ذلك، يبقى استهلاك الغاز مشابهًا لاستدعاءات FDC الحالية لأن كل طلب يُعالج بشكل فردي وليس في دفعات كبيرة.

مراعاة المخاطر

• أمان النظام يعتمد على صحة عتاد TEE ونزاهة مجموعة الموزعين خلال مرحلة الإقلاع. أي اختراق للعقد الأولية في Google Confidential Compute قد يؤثر على الأدلة الأولية.
• قاعدة الأغلبية الموزونة تتطلب مجموعة موثوقة من مزودي البيانات؛ قد يؤدي نقص المشاركة إلى إبطاء التنفيذ.
• التدقيقات لا تزال مؤقتة. ستجرى تدقيقات أمان نهائية بعد التحقق من Songbird، وبالتالي هناك فترة خطر تدقيق.

إشارات خارطة الطريق (غير ملزمة)

• بعد التحقق الناجح على Songbird، تخطط Flare لإطلاق على الشبكة الرئيسية باستخدام نفس العقود.
• ستمكن المراحل المستقبلية البنائين من نشر مشغلي TEE وامتداداتهم الخاصة، مما يوسع الدعم إلى ما وراء XRPL.

النقاط الأساسية

1. يجلب FCC حوسبة سرية وقابلة للتحقق إلى Flare عبر TEEs.
2. توفر PMW محافظًا خاضعة للسيطرة على السلسلة على XRPL، تجسر فجوة إصدار الأصول.
3. تقدم FDC V2 اعتمادًا أسرع لكل طلب، محسّنًا زمن استجابة الأدلة لجميع التطبيقات.
4. الإطلاق هو اختبار تجريبي؛ نجاحه سيوجه نشر الشبكة الرئيسية ورؤية Flare 2.0 الأوسع.