في أكتوبر، بدأ مصطلح "TEE (Trusted Execution Environment)" في الظهور بشكل متكرر في التغذيات X. لقد فاجأني هذا لأن TEE كان عادة ما يكون موضوعًا متخصصًا، يُناقش في الغالب في أوساط أكاديمية أمان الأنظمة. بصفتي شخصًا قام بالبحث في مختبر أمان الأنظمة، فقد سررني رؤية هذا التطور. ومع ذلك، كنت أتساءل عن سبب اكتساب TEE اهتمامًا فجأة في مجال Web3. كما لاحظت نقصًا في المحتوى المتاح الذي يشرح مفاهيم TEE للجمهور العام، مما دفعني لكتابة هذه المقالة.

TEE هو مفهوم معقد يمكن أن يكون تحديًا لفهمه بالكامل بدون خلفية في علوم الكمبيوتر. لذلك ، يبدأ هذا المقال بشرح مفاهيم TEE الأساسية ، ويشرح لماذا يهتم Web3 بالاستفادة من TEE ، ويناقش بعد ذلك مشاريع Web3 الحالية التي تنفذ TEE وقيوده.

في الختام، سيغطي هذا المقال المواضيع التالية:

• مقدمة لمفاهيم TEE ونظرة عامة على أحدث TEEs
• حالات تنفيذ TEE المتنوعة داخل نظام البيئة الويب3
• قيود تقنية TEE والتوجهات الشخصية حول هذه القيود
• مستقبل TEE في نظام الويب3 البيئي

1. ما هو TEE؟

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

المفاهيم الأساسية

تدير معظم خوادم Web2 الوصول إلى البيانات من خلال إعدادات التفويض. ومع ذلك ، نظرا لأن هذا النهج يعتمد على البرامج البحتة ، فإنه يصبح غير فعال بشكل أساسي إذا تم الحصول على امتيازات عالية المستوى. على سبيل المثال ، إذا حصل أحد المهاجمين على امتيازات على مستوى kernel في نظام تشغيل الخادم ، فمن المحتمل أن يتمكن من الوصول إلى جميع البيانات التي يتم التحكم فيها بالإذن على الخادم ، بما في ذلك مفاتيح التشفير. في مثل هذه السيناريوهات المتطرفة ، لا توجد طريقة تقريبا لمنع سرقة البيانات من خلال الأساليب القائمة على البرامج وحدها. تحاول TEE ، أو بيئة التنفيذ الموثوقة ، معالجة هذه المشكلة بشكل أساسي من خلال الأمان المستند إلى الأجهزة. غالبا ما يطلق على TEEs اسم "الحوسبة السرية" ، ولكن هذا مفهوم أوسع يتضمن آليات حسابية تضمن خصوصية بيانات المستخدم ، مثل ZK و MPC و FHE.

المصدر: جوجيتسو كايسين

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

يتطلب إنشاء جيب ومعالجة البيانات داخله مجموعات تعليمات محددة ، على غرار رموز التشغيل. تستخدم هذه الإرشادات مفاتيح التشفير المخزنة في المناطق المحمية بالأجهزة لإجراء عمليات حسابية على البيانات داخل الجيب. نظرا لأن TEE عبارة عن وحدة أمان على مستوى الأجهزة ، فإن تنفيذها يختلف حسب بائع شريحة وحدة المعالجة المركزية. على سبيل المثال ، تدعم Intel SGX ، وتدعم AMD SEV ، وتدعم ARM TrustZone. من منظور أوسع ، تشترك هذه التطبيقات في مفهوم "حماية الذاكرة من خلال التشفير على مستوى الأجهزة".

1.1. كيف تحمي TEEs البيانات

دعونا نفحص أولا كيف تعمل أكثر الوحدات الآمنة الثقة الشائعة - Intel SGX و AMD SEV و ARM TrustZone - ثم نقدم تنفيذات وحدات الثقة الآمنة الأحدث.

1.1.1. OG TEEs

إنتل SGX

تنشئ SGX وتصل إلى المحيطات على مستوى العملية. توفر الصورة التالية تمثيلاً واضحاً لكيفية عمل برنامج ممكّن بتقنية SGX.

المصدر: https://sgx101.gitbook.io/sgx101/sgx-bootstrap/enclave/interaction-between-pse-and-application-enclaves

أثناء التطوير ، يجب على المطورين التفريق بين الشفرة غير الموثوقة والشفرة الموثوقة. يتم تعيين المتغيرات أو الوظائف التي تحتاج إلى حماية بواسطة الحاوية كشفرة موثوقة ، بينما يتم تصنيف العمليات الأخرى كشفرة غير موثوقة. عندما تحتاج الشفرة غير الموثوقة إلى إدخال البيانات إلى الشفرة الموثوقة ، أو عندما يجب على الشفرة الموثوقة التفاعل مع الشفرة غير الموثوقة ، يتم استخدام syscalls خاصة تسمى ECALL و OCALL.

source: https://www.intel.com/content/www/us/ar/developer/articles/training/intel-software-guard-extensions-tutorial-part-7-refining-the-enclave.html

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

AMD SEV

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

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

source: 10.1109/SRDS.2018.00042

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

ARM ترست زون

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

يقسم TrustZone النظام إلى عالم آمن وعالم عادي على مستوى الأجهزة. يجب على المطورين الذين يستخدمون TrustZone تنفيذ وظائف الأمان الحرجة في العالم الآمن، بينما تعمل الوظائف العامة في العالم العادي. تحدث الانتقالات بين هذين العالمين من خلال استدعاءات النظام الخاصة المعروفة باسم Secure Monitor Calls، مما يشبه SGX.

تميز رئيسي يتمثل في أن مخبأ TrustZone يمتد إلى ما هو أبعد من المعالج أو الذاكرة فحسب ، فهو يشمل النظام بأكمله ، بما في ذلك حافلة النظام والأجهزة الطرفية ومراقبو المقاطعات. تستخدم Apple أيضًا TEE يسمى Secure Enclave في منتجاتها ، والذي يشبه إلى حد كبير TrustZone على المستوى العالي.

1.1.2. تيس المتقدمة

كما سنناقش لاحقًا، واجهت العديد من الـ TEEs الأصلية، بما في ذلك Intel SGX، ثغرات جانبية وتحديات تطوير بسبب قضايا هيكلية. لمعالجة هذه المشاكل، أصدرت الشركات الموردة نسخًا محسنة. مع الطلب المتزايد على الحوسبة السحابية الآمنة، بدأت منصات مثل AWS/Azure/GCP في تقديم خدمات TEE الخاصة بها. مؤخرًا، تم توسيع مفهوم TEE إلى وحدات معالجة الرسومات أيضًا. بدأ بعض حالات استخدام Web3 في تنفيذ هذه الـ TEEs المتقدمة، لذا سأشرحها بإيجاز.

Cloud TEEs: AWS Nitro, Azure Confidential Computing, Google Cloud Confidential Computing

مع الطلب المتزايد على خدمات الحوسبة السحابية، بدأت مقدمو الخدمات في تطوير حلول TEE الخاصة بهم. Nitro من AWS هو بيئة حوسبة محاصرة تعمل جنبًا إلى جنب مع حالات EC2. يحقق فصلًا فعليًا للبيئة الحاسوبية عن طريق استخدام رقاقة أمان Nitro مخصصة للتصديق وإدارة المفاتيح. يحمي Hypervisor من Nitro مناطق الذاكرة المحاصرة من خلال الوظائف المقدمة من الرقاقة، مما يحمي بشكل فعال ضد الهجمات من المستخدمين ومقدمي الخدمات السحابية.

تدعم Azure مواصفات TEE المختلفة ، بما في ذلك Intel SGX و AMD SEV-SNP وعزلها القائم على الافتراضات الخاصة بها. يوفر هذا المرونة في اختيار بيئة الأجهزة المستخدمين خيارات أكثر ولكن قد يزيد من سطح الهجوم عندما يستخدم المستخدم عدة TEE.

توفر Google Cloud خدمات الحوسبة السرية التي تستخدم بيئات التنفيذ الموثوقة (TEE)، مع التركيز على أعباء العمل الذكاء الاصطناعي/تعلم الآلة. بينما تختلف عن AWS Nitro، تقدم Google Cloud، مثل Azure، عزل قائم على الافتراضات باستخدام بنية TEE الحالية. تشمل المميزات الرئيسية دعم مسرعات الـ CPU مثل Intel AMX للتعامل مع المهام الكثيفة للذكاء الاصطناعي/تعلم الآلة، والحوسبة السرية القائمة على GPU من خلال NVIDIA، والتي سيتم التفصيل فيما بعد.

ARM CCA

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

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

إنتل TDX

قدمت إنتل تكنولوجيا TDX ، وهي تقنية تقوم بتشفير الذاكرة على مستوى VM ، مما يشبه تقنية SEV لشركة AMD. يعالج هذا الإصدار التعليقات حول قيود SGX (v1) ، بما في ذلك حدود حجم الحاوية 256 ميجابايت وتعقيد التطوير المتزايد بسبب إنشاء الحاوية على مستوى العملية. الفرق الرئيسي عن SEV هو أن TDX يثق جزئياً في نظام التشغيل ، وبالتحديد المراقب الافتراضي ، لإدارة موارد VM. بالإضافة إلى ذلك ، هناك اختلافات في آليات التشفير لكل VM.

أيه إم دي سيف-SNP

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

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

GPU TEE: NVIDIA الحوسبة السرية

تطوير TEE تم التركيز عليه تقليديًا على وحدات المعالجة المركزية بسبب اعتماده على بائعي الأجهزة. ومع ذلك ، فقد أظهرت الحاجة إلى التعامل مع العمليات الحسابية المعقدة مثل تدريب الذكاء الاصطناعي الآمن وحماية بيانات التدريب ضرورة TEE لوحدة المعالجة الرسومية. في الاستجابة ، قدمت NVIDIA ميزات الحوسبة السرية إلى وحدة المعالجة الرسومية H100 في عام 2023.

توفر NVIDIA Confidential Computing نماذج GPU مشفرة ومدارة بشكل مستقل، مما يضمن الأمان من البداية إلى النهاية عندما يتم الجمع بين وحدة المعالجة المركزية TEE. حاليًا، يتم تحقيق ذلك عن طريق التكامل مع AMD SEV-SNP أو Intel TDX لبناء خطوط الأنابيب للحوسبة السرية.

1.2. كيف نثق في TEE؟

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

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

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

2. TEE على Web3

لماذا TEE على Web3؟

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

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

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

2.1. معالج سري

مارلين

Marlin هو بروتوكول حوسبة يمكن التحقق منه مصمم لتوفير بيئة حوسبة آمنة باستخدام تقنية TEE أو ZK. أحد أهدافهم الأساسية هو تطوير شبكة لامركزية. يدير Marlin شبكتين فرعيتين: Oyster و Kalypso ، ويعمل Oyster كبروتوكول معالجة مشتركة قائم على TEE.

1) المحار CVM

يعمل Oyster CVM (Oyster for convenience) كسوق P2P TEE. يشتري المستخدمون بيئات الحوسبة AWS Nitro Enclave من خلال السوق الخارجي لـ Oyster وينشرون صور برامجهم هناك. فيما يلي هيكل مجرد لـ Oyster:

المصدر: https://docs.marlin.org/oyster/protocol/cvm/workflow/

يحمل Oyster هيكلًا مشابهًا لـ Akash. في Oyster ، يتم دور البلوكشين في التحقق مما إذا كان كل بيئة حوسبة TEE تعمل بشكل صحيح ، ويتم ذلك من خلال المراقبين المسمين بـ Providers. يقوم مقدمو الخدمة بالتحقق باستمرار من توافر Enclaves في الوقت الحقيقي وتقديم تقاريرهم إلى شبكة Oyster. يراهنون$PONDالرموز، التي قد تتعرض للحذف إذا قاموا بأنشطة خبيثة. بالإضافة إلى ذلك، هناك شبكة مركزية من الجهات، المشار إليها بـ 'المراقبين'، موجودة للإشراف على حذف موفر الخدمة. في كل حقبة، يحصل المراقبون على تعيين وظائفهم، ويقومون بإرسال طلبات تدقيق إلى الملاجئ التي تم اختيارها عشوائيًا بواسطة بذرة تم إنشاؤها داخل ملاجئ.

ومع ذلك ، فقد قامت Oyster بتنفيذ عقد يسمىNitroProverالذي يتحقق من نتائج التصديق البعيدة على السلسلة ، مما يتيح للمستخدمين التحقق من سلامة TEE المشتراة على السلسلة.

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

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

2) خادم بدون خدمة

في حين أن Oyster CVM يعمل كسوق P2P TEE ، فإن Oyster Serverless يشبه AWS Lambda (أو Function-as-a-Service) مع TEE. باستخدام Oyster Serverless ، يمكن للمستخدمين تنفيذ وظائف دون استئجار حالات ، والدفع حسب الطلب.

سيكون تدفق التنفيذ لخادم Oyster Serverless كما يلي:

1. يقوم المستخدمون بإنشاء طلبات لعقد الريلي
2. يلاحظ خادم بوابة السلسلة الفرعية طلبات المستخدم عبر الحدث
3. خادم البوابة يقوم بإعادة توجيه طلب المستخدم إلى بروتوكول البوابة
4. بروتوكول البوابة ينشئ ويعين وظيفة لبروتوكول Serverless بناءً على طلب المستخدم
5. يستمع خوادم التنفيذ إلى المهام المخصصة لبروتوكول الخادم غير القابل للتصدير، وينفذون المهمة ويقدمون الرد
6. يتم إرسال الاستجابة - نتيجة طلب المستخدم - تتم إعادتها بشكل متسلسل للمستخدم

مع Oyster Serverless، يمكن للمستخدمين إرسال طلبات واجهة برمجة تطبيقات web2 أو استدعاءات العقود الذكية من خلال عقد ذكي، في حين يتم ضمان سلامة التنفيذ من خلال TEE. يمكن للمستخدمين أيضًا الاشتراك في Serverless للتنفيذ الدوري، مما سيكون مفيدًا بشكل خاص لجلب البيانات من المصادر الخارجية.

شبكة فالا

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

تتضمن التصميم الأساسي لشبكة Phala العمال وحراس البوابة. يعمل العمال كعقدة عادية تنفذ عمليات الحساب للعملاء. من ناحية أخرى، يدير حراس البوابة مفاتيح تمكّن العمال من فك تشفير وحساب القيم الحالية المشفرة. يتعامل العمال مع قيم الحالة للعقد المشفرة عبر Intel SGX، مما يستلزم مفاتيح من حراس البوابة لقراءة أو كتابة هذه القيم.

source: https://docs.phala.network/tech-specs/blockchain

قامت Phala بتوسيع عروضها من خلال دعم SDKs لـ Confidential VMs في بيئات Intel TDX. مؤخرًا، بالتعاون مع Flashbot، قاموا بإطلاق Dstack. يتميز هذا المنتج بواجهة برمجة تطبيقات للتوثيق عن بعد للتحقق من الحالة التشغيلية لعدة صور لحاويات Docker نُشرت في Confidential VMs. يضمن التوثيق عن بعد من خلال Dstack الشفافية عبر واجهة برمجة تطبيقات مخصصة المستكشف.

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

المصدر: https://docs.phala.network/overview/phala-network/confidential-ai-inference

توضح الصورة هيكل نظام الاستدلال الذكاء الاصطناعي السري لشبكة فالا. يستخدم هذا النظام بيئات التنفيذ الموثوقة (TEEs) على مستوى الجهاز الظاهري مثل Intel TDX و AMD SEV لنشر نماذج الذكاء الاصطناعي. يقوم بإجراء الذكاء الاصطناعي الاستدلال من خلال الحوسبة السرية Nvidia وينقل النتائج بأمان إلى جيب وحدة المعالجة المركزية. قد تتحمل هذه الطريقة نفقات عامة كبيرة مقارنة بالنماذج العادية ، لأنها تتضمن جولتين من حساب الجيب. ومع ذلك ، من المتوقع أن تقدم تحسينات كبيرة في الأداء مقارنة بأساليب الاستدلال الذكاء الاصطناعي الحالية القائمة على TEE والتي تعتمد كليا على أداء وحدة المعالجة المركزية. وفقا ل ورقةتم قياس الضغط الزائد للتخمين LLM القائم على Llama3 الذي تم نشره بواسطة شبكة Phala بنسبة حوالي 6-8٪.

آخرون

في مجال الذكاء الاصطناعي X Crypto، أمثلة أخرى على استخدام TEEs كمعالجات مساعدة تشمل iExec RLC، PIN AI، وبروتوكول سوبر. تركز iExec RLC و PIN AI على حماية نماذج الذكاء الاصطناعي وبيانات التدريب من خلال TEEs، على التوالي. بينما يستعد بروتوكول سوبر لإطلاق سوق لتداول بيئات الحوسبة TEE، على غرار Marlin. ومع ذلك، لم تتوفر معلومات تقنية مفصلة حول هذه المشاريع بعد علنيًا. سنقدم التحديثات بعد إطلاق منتجاتهم.

2.2. العقود الذكية الآمنة

واحة (مسبقاً روز)

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

يتضمن طبقة التنفيذ، المسماة باراتايم، ثلاثة مكونات: الشيفرة، وهي آلة افتراضية سرية مبنية على WASM؛ سافير، وهي آلة افتراضية سرية مبنية على EVM؛ والزمرد، وهي آلة افتراضية متوافقة مع EVM القياسية. تحمي Oasis على نحو أساسي العقود الذكية وعملياتها الحسابية من التعديلات التعسفية من قبل العقد، مضمنة التأكد من أن عميل التنفيذ يعمل داخل حصن TEE. يتم توضيح هذا الهيكل في الرسم التوضيحي المرافق.

المصدر: https://docs.oasis.io/general/oasis-network/

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

تسلط Oasis الضوء على قوتها في تسهيل إنشاء DApps التي تتعامل مع المعلومات الشخصية الحساسة على سلاسل الكتل العامة ، باستخدام Paratime السري. تسمح هذه الميزة بتطوير الخدمات التي تتطلب التحقق من الهوية ، مثل SocialFi ، والإقراض الائتماني ، وخدمات تكامل CEX ، والخدمات القائمة على السمعة. يمكن لهذه التطبيقات تلقي معلومات المستخدم البيومترية أو معلومات KYC والتحقق منها بأمان داخل جيب آمن.

شبكة السرية

شبكة Secret هي سلسلة طبقة 1 ضمن نظام الكوزموس البيئي وتعد واحدة من أقدم سلاسل الكتل TEE. تستفيد من حصن Intel SGX لتشفير قيم حالة السلسلة ، ودعم المعاملات الخاصة لمستخدميها.

في شبكة Secret، يحتوي كل عقد على مفتاح سري فريد مخزن في المعقلة الخاصة بكل عقد. عندما يقوم المستخدمون بالاتصال بالعقود عبر المعاملات المشفرة بمفاتيح عامة، تقوم العقدة بفك تشفير بيانات المعاملة داخل TEE للتفاعل مع قيم الحالة للعقد. تُسجل هذه القيم المعدلة ثم في الكتل، مع البقاء مشفرة.

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

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

زمرة ، بروتوكول Quex

على عكس L1s المعتمدة على TEE التي تم تقديمها سابقًا ، توفر Clique و Quex Protocol البنية التحتية التي تمكّن التطبيقات اللامركزية العامة من تفويض الحسابات الخاصة إلى بيئة TEE خارج السلسلة. يمكن استخدام هذه النتائج على مستوى العقد الذكي. يتم استخدامها بشكل ملحوظ لآليات توزيع الحوافز التحقق منها ، ودفاتر الأوامر خارج السلسلة ، والمُهَيَّأات ، وحماية بيانات KYC.

نظام إثبات الصلاحية 2.3.

تستخدم بعض سلاسل ZK L2 أنظمة متعددة البراهين لمعالجة عدم استقرار البراهين بدون معرفة المصدر ، وغالبًا ما تدمج دلائل TEE. لم تكتمل آليات براهين بدون معرفة المصدر الحديثة بما فيه الكفاية للثقة الكاملة بأمانها ، وتتطلب الشوائب المتعلقة بالصوتية في الدوائر ZK جهودًا كبيرة للتصحيح عند حدوث الحوادث. كإجراء احتياطي ، تعتمد السلاسل التي تستخدم بروفات ZK أو ZK-EVMs بروفات TEE لاكتشاف الشوائب المحتملة عن طريق إعادة تنفيذ الكتل من خلال آلات افتراضية محلية داخل الحصون. حاليًا ، تستخدم L2s أنظمة متعددة البراهين ، بما في ذلك TEE ، وTaiko وScroll وTernoa. دعنا نفحص بإيجاز دوافعهم لاستخدام أنظمة متعددة البراهين وهياكلهم.

تايكو

تعد Taiko حاليا أبرز سلسلة تراكمية قائمة على الخطة المستقبلية. تقوم سلسلة التجميع بتفويض التسلسل إلى مقترحي كتلة Ethereum دون الحفاظ على جهاز تسلسل مركزي منفصل. وفقا لمخطط Taiko ل Based Rollup ، يقوم باحثو L2 بتكوين حزم المعاملات وتسليمها إلى L1 كدفعات. ثم يقوم مقترحو كتلة L1 بإعادة بنائها ، جنبا إلى جنب مع معاملات L1 ، لإنشاء كتل L1 والتقاط MEV.

source: https://docs.taiko.xyz/core-concepts/multi-proofs/

في Taiko ، يتم استخدام TEE ليس خلال مرحلة تركيب الكتلة ولكن في مرحلة إنتاج الإثبات ، والتي سنشرحها. Taiko ، مع هيكلها اللامركزي ، لا يتطلب التحقق من عطل متسلسل. ومع ذلك ، إذا كانت هناك علل داخل قاعدة كود عميل L2 node ، فلا يمكن لإعداد لامركزي كامل التعامل معها بسرعة. وهذا يتطلب إثباتات صحة عالية المستوى لضمان الأمان ، مما يؤدي إلى تصميم تحدي أكثر تعقيدًا بالمقارنة مع rollups الأخرى.

تمر كتل Taiko بثلاث مراحل تأكيد: مقترحة، مثبتة، ومتحققة. تعتبر الكتلة مقترحة عندما يتم التحقق من صحتها بواسطة عقد L1 لـ Taiko (عقد الإرتقاء). تصل إلى حالة مثبتة عندما يتم التحقق منها من قبل المؤكدات الموازية، وحالة متحققة عندما يتم إثبات كتلتها الأم. للتحقق من الكتل، يستخدم Taiko ثلاثة أنواع من الأدلة: دليل TEE المعتمد على SGX V2، دليل ZK المعتمد على Succinct/RiscZero، ودليل Guardian، الذي يعتمد على تعدد التوقيع المركزي.

توظف تايكو نموذج المنازعة للتحقق من الكتلة ، مما يؤسس لتسلسل هرمي للأمان بين الأدلة: TEE و ZK و ZK + TEE و Guardian. يتيح هذا الإعداد للمتحدين كسب مكافآت أكبر عند تحديد الأدلة الخاطئة التي تم إنشاؤها بواسطة نماذج طبقة أعلى. يتم تعيين الأدلة المطلوبة لكل كتلة بشكل عشوائي بالأوزان التالية: 5٪ لـ SGX + ZKP ، 20٪ لـ ZKP ، والبقية باستخدام SGX. يضمن ذلك أن يمكن للأدلة ZK الحصول دائمًا على مكافآت أعلى عند التحديات الناجحة.

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

على عكس توليد ZKproof، الذي ينطوي على تكاليف حسابية كبيرة، يتحقق توليد البرهان القائم على TEE على سلامة الحوسبة بتكلفة أقل بكثير في ظروف أمنية مماثلة. تتضمن التحقق من هذه البراهين عمليات تحقق بسيطة، مثل التأكد من تطابق توقيع ECDSA المستخدم في البرهان مع توقيع الدليل.

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

تمرير

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

المصدر: https://scroll.io/blog/scaling-security

تعتزم Scroll دعم بيئات الأجهزة المختلفة (حاليًا فقط SGX) ، بما في ذلك Intel SGX و AMD SEV و AWS Nitro ، لتقليل الاعتمادات على الأجهزة. يتناولون مشاكل الأمان المحتملة في TEE عن طريق جمع الأدلة من بيئات متنوعة باستخدام توقيعات الحد الأدنى.

Ternoa

تعطي Ternoa الأولوية للكشف عن الإجراءات الضارة من قبل كيانات L2 المركزية على معالجة الأخطاء في التنفيذ نفسه. على عكس Taiko أو Scroll ، التي تستخدم TEE Provers لاستكمال براهين ZK الحالية ، توظف Ternoa مراقبين في البيئات القائمة على TEE. يكتشف هؤلاء المراقبون الإجراءات الضارة من قبل أجهزة التسلسل والمدققين L2 ، مع التركيز على المجالات التي لا يمكن تقييمها فقط من بيانات المعاملات. ومن الأمثلة على ذلك عقد RPC التي تفرض رقابة على المعاملات بناء على عنوان IP ، أو أجهزة التسلسل التي تغير خوارزميات التسلسل ، أو الفشل في إرسال بيانات الدفعات عن قصد.

تعمل Ternoa على شبكة L2 منفصلة تسمى Integrity Verification Chain (IVC) لمهام التحقق المتعلقة بكيانات ال rollup. يقوم موفر إطار ال rollup بإرسال أحدث صورة متسلسلة إلى IVC. عندما يطلب rollup جديد نشره، يقوم IVC بإرجاع صور الخدمة المخزنة في TEE. بعد النشر، يقوم المراقبون بالتحقق بانتظام من ما إذا كان ال rollup المنشور يستخدم صورة المتسلسلة على النحو المقصود. ثم يقومون بإرسال الأدلة على النزاهة، وتضم نتائج التحقق الخاصة بهم وتقارير الشهادة من بيئة TEE الخاصة بهم، لتأكيد سلامة السلسلة.

2.3. أمان إيثريوم

2.3.1. توزيع بناء الكتل

Flashbots BuilderNet

فلاشبوتس، المعترف به على نطاق واسع كمزود حلول MEV، استكشف بشكل مستمر تطبيق بيئات التنفيذ الموثوقة (TEE) في تكنولوجيا البلوكشين. من الجهود البحثية الملحوظة:

• التحقيق في تنفيذ Geth داخل SGX Enclave وقيودها
• تنفيذ بناء كتلة قائم على SGX
• بناء سلسلة معالج TEE معتمدة على تنفيذ REVM داخل SGX Enclave، مكملة بطبقة التحقق Automata

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

يعتمد إيثيريوم نموذج الفصل بين المقترح والبناء. يقوم هذا النظام بتقسيم إنشاء الكتل إلى دورين - 1) البناة: مسؤولون عن إنشاء الكتل واستخراج MEV 2) المقترحون: يوقّعون وينشرون الكتل التي تم إنشاؤها بواسطة البناة لتوزيع أرباح MEV. هذه الهيكلية أدت إلى تواطؤ بعض التطبيقات اللامركزية مع البناة خارج السلسلة لالتقاط أرباح MEV كبيرة. نتيجة لذلك، يقوم بعض البناة، مثل Beaverbuild وTitan Builder، بإنشاء أكثر من 90% من الكتل في إيثيريوم بشكل احتكاري. في حالات شديدة، يمكن لهؤلاء البناة رقمنة المعاملات التعسفية. على سبيل المثال، تتم رقمنة المعاملات المنظمة، مثل تلك من Tornado Cash، بنشاط من قبل البناة الرئيسيين.

تعالج BuilderNet هذه المشاكل من خلال تعزيز خصوصية المعاملات وتقليل العقبات التي تواجه مشاركة بناء الكتل. يمكن تلخيص هيكلها على نحو عام كما يلي:

المصدر:https://buildernet.org/docs/architecture

تتم إدارة عقدة بناء، والتي تتلقى معاملات المستخدم (تدفق الطلب)، من قِبَل مشغلي العقدة المختلفين. كل مشغل يدير نسخ بناء مفتوحة المصدر داخل بيئات Intel TDX. يمكن للمستخدمين التحقق من بيئة TEE لكل مشغل وإرسال المعاملات المشفرة بحرية. ثم يقوم المشغلون بمشاركة تدفق الطلب الذي يتلقونه، وتقديم الكتل إلى ريلي MEV-boost، وتوزيع مكافآت الكتل على الباحثين والآخرين المشاركين في إنشاء الكتل بنجاح.

توفر هذه الهيكلة العديد من فوائد اللامركزية:

• قابلية التحقق: يعمل كل مثيل من المنشئ داخل بيئة تشغيل آمنة (TEE)، مما يتيح للمستخدمين التحقق من أن المنشئين لم يحجبوا المعاملات أو يقوموا بتعديل عملاء العملة بشكل تعسفي. سياسة توزيع المكافأة لمساهمي إنشاء الكتلة أيضًا شفافة داخل بيئة التشغيل الآمنة (TEE).
• مقاومة الرقابة: في BuilderNet، تدير عقدة Builder العديد من المشغلين، كل منهم لديه سياسات تنظيمية مختلفة. هذا التنوع يعني أنهم يختارون معاملات مختلفة للاستبعاد. حتى إذا حجب بعض المشغلين المعاملات، يمكن للآخرين اختيارها بعد ذلك. من النظرية، إذا كان هناك مشغل واحد على الأقل غير قابض، يمكن تضمين معاملات المستخدم في الكتل. يوفر BuilderNet أيضًا حلاً لمشكلات الرقابة في L2، مما يوضح أن L2s يمكنها تحقيق مقاومة أعلى للرقابة من المتتابعات المفردة من خلال تفويض بناء الكتل إلى BuilderNet. (في هذه الحالة، يمكن أن يتأثر مستوى مقاومة الرقابة بوجود مكونات إضافية تقوم بتصفية المعاملات قبل المتتابع مثل جدار الحماية).
• اللامركزية: يتحدى بناؤو البلوك الحاليون الاعتماد على البنية التحتية المركزية. تهدف BuilderNet إلى معالجة هذا الأمر من خلال دمج مختلف المنشئين، بدءًا من Beaverbuild. مع انضمام المزيد من بناء البلوك إلى BuilderNet، ستشهد بنية بلوك Ethereum PBS زيادة في اللامركزية. في الوقت الحالي، تتضمن BuilderNet فقط Beaverbuild وFlashbots وNethermind. يحتاج بناة آخرون إلى إذن للانضمام، ولكن هناك خططًا لجعل إذن نشر المشغل لا يتطلب إذنًا والقضاء على البنية التحتية المركزية بالكامل في المستقبل.

2.3.2. حماية المحقق

بوفر فاينانس

قدمت Puffer Finance أداة Secure Signer مصممة لتقليل مخاطر تقليص Ethereum للمحققين بسبب أخطاء العميل أو الأخطاء. تستخدم هذه الأداة موقعًا آمنًا معتمدًا على SGX Enclave لتعزيز الأمان.

مصدر:https://docs.puffer.fi/technology/secure-signer/

يعمل موقع Secure Signer عن طريق إنشاء وتخزين مفاتيح BLS validator داخل محيط SGX enclave ، والوصول إليها فقط عند الحاجة. منطقه بسيط: إلى جانب الأمان المقدم من Trusted Execution Environment (TEE) ، يمكنه اكتشاف أخطاء المراقب التابع أو الأعمال الخبيثة. يتم تحقيق ذلك عن طريق ضمان زيادة الفتحات بشكل صارم قبل توقيع الكتل أو الأدلة. يؤكد Puffer Finance أن هذا الإعداد يتيح للمراقبين التحصيل من مستويات الأمان المقارنة بالمحافظ الأجهزة ، وتجاوز الحمايات النموذجية التي توفرها حلول البرامج.

2.4. ترتيب L2 اللامركزية

يونيتشين

يشارك Unichain، سلسلة Uniswap Layer 2 (L2) المقرر إطلاقها في الربع الأول من العام المقبل، خططهم في الكتاب الأبيض لتمزيق آليات بناء الكتلة L2 المركزة باستخدام بيئات التنفيذ الموثوقة (TEE). على الرغم من أن المواصفات الفنية المفصلة لم تصدر بعد، إليكم ملخص لمقترحاتهم الرئيسية:

• فصل مُنشـئ المتسلسلة-بنّاء: لتعزيز الهياكل الموجودة للتجميع حيث يتم التعامل مع تسلسل وتوليد كتل L2 بواسطة مُنشئين مركزيين، تعاونت يونيتشين مع فلاشبوتس. تهدف هذه الشراكة إلى فصل مُنشئي L2 عن بنّاء الكتل. سيعمل بنّاء الكتل في يونيتشين باستخدام كود مفتوح المصدر ضمن إنتل TDX، مما يضمن الشفافية من خلال إصدار نتائج الشهادات للتنفيذ علنًا.
• Flashblock: تحدد Unichain القيود في قابلية التوسع من خلال عملية التأكيد المسبق الحالية التي توفرها أجهزة التسلسل التراكمي ، مثل التسلسل وإنشاء جذر الحالة. لمعالجة هذه الأمور ، يخططون لتقديم "Flashblocks" ، مما يتيح للمستخدمين تلقي الكتل المعلقة فور طلب المعاملات من خلال بناة TEE. ويشددون على أن التسلسل داخل TEE سيضمن أن ترتيب المعاملات يعتمد فقط على رسوم الأولوية ووقت التقديم ، دون تدخل جهاز التسلسل ، مما يسمح بتأكيد مسبق أسرع.

علاوة على ذلك، تعتزم Unichain تطوير ميزات مختلفة تعتمد على TEE، بما في ذلك مسبح ذاكرة مشفر، وعمليات مجدولة، وعقود ذكية محمية بواسطة TEE.

2.5. خاص RPC

أوتوماتا

على الرغم من أن تقنية البلوكشين حققت تفوقًا كبيرًا في الجوانب المتعلقة باللامركزية في الهيكل العماري، إلا أن العديد من العناصر لا تزال لا تتمتع بمقاومة كافية للرقابة بسبب الاعتماد على مشغلي الخادم. تهدف أوتوماتا إلى تقديم حلول تقلل من الاعتماد على مشغلي الخادم وتعريض البيانات في الهيكل العماري للبلوكشين القائم على TEE. من بين التنفيذات البارزة لـ أوتوماتا تشمل مشاريع مفتوحة المصدر.SGX Proverوالتحقق،TEE تجميعالذي يتحقق من التطابقات بين التنفيذيات المنشورة في TEE وشفرة المصدر، ومُنشئ TEEالذي يضيف الخصوصية إلى آليات بناء الكتل من خلال مسرع TEE وبناء المحافظ. بالإضافة إلى ذلك، يسمح Automata بنتائج التصديق البعيد لـ TEE بأن تُنشر على السلسلة الرئيسية، مما يتيح إمكانية التحقق العام والتكامل في العقود الذكية.

تقوم Automata حاليا بتشغيل 1RPC ، وهي خدمة RPC قائمة على TEE مصممة لحماية معلومات التعريف الخاصة بمقدمي المعاملات ، مثل IP وتفاصيل الجهاز ، من خلال جيوب آمنة. تسلط Automata الضوء على خطر أنه مع تسويق UserOp بسبب تطوير تجريد الحساب ، قد تستنتج خدمات RPC أنماط UserOp لمستخدمين محددين عبر تكامل الذكاء الاصطناعي ، مما قد يعرض الخصوصية للخطر. هيكل 1RPC واضح ومباشر. يقوم بإنشاء اتصالات آمنة مع المستخدمين ، ويتلقى المعاملات (UserOp) في TEE ، ويعالجها برمز منشور داخل الجيب. ومع ذلك ، يحمي 1RPC بيانات تعريف UserOp فقط. تظل الأطراف الفعلية المعنية ومحتويات المعاملة مكشوفة أثناء التفاعل مع نقطة الدخول على السلسلة. قد يتضمن النهج الأكثر جوهرية لضمان خصوصية المعاملات حماية طبقات mempool ومنشئ الكتل باستخدام TEE. يمكن تحقيق ذلك من خلال التكامل مع TEE Builder من Automata.

2.6. وكلاء الذكاء الاصطناعي

مصدر:https://x.com/tee_hee_he

ما جلب في النهاية لرواج TEE في web3 هو وكيل Twitter AI المستند إلى TEE. ربما قابل العديد من الناس TEE لأول مرة عندما التقوا بوكيل AI يدعى @tee_hee_heظهرت على X في نهاية أكتوبر وأطلقت عملتها الميمية على إثيريوم.@tee_hee_heهو وكيل ذكاء اصطناعي تم تطويره بالتعاون بين Nous Research ومشروع Teleport لـ Flashbots. ظهر كاستجابة للمخاوف من أن حسابات وكلاء الذكاء الاصطناعي الشائعة في ذلك الوقت لا يمكنها إثبات أنها تقوم بنقل النتائج التي تم إنشاؤها فعليًا بواسطة نماذج الذكاء الاصطناعي. صمم المطورون نموذجًا يقلل من تدخل الكيانات المركزية في عمليات مثل إعداد حساب تويتر وإنشاء محفظة العملات المشفرة ونقل نتائج نموذج الذكاء الاصطناعي.

مصدر: @tee_hee_he/setting-your-pet-rock-free-3e7895201f46"">https://medium.com/@tee_hee_he/setting-your-pet-rock-free-3e7895201f46

نفذوا وكيل الذكاء الاصطناعي في بيئة Intel TDX، مما أسفر عن توليد كلمات مرور البريد الإلكتروني والحساب X ورموز OAuth للوصول إلى تويتر من خلال محاكاة المتصفح، ثم قاموا بإزالة جميع خيارات الاسترداد.

مؤخرًا ، تم استخدام TEE في سياق مشابه لـ AI-Pool ، حيث @123skely أجريت بنجاح جمع التبرعات. في الوقت الحالي ، بعد نشر الذكاء الاصطناعي عملات meme لعقودها وعناوينها ، عادة ما تؤمن روبوتات القناصة المتفوقة تقنيا معظم السيولة وتتلاعب بالأسعار. يحاول الذكاء الاصطناعي-Pool حل هذه المشكلة من خلال إجراء الذكاء الاصطناعي نوع من البيع المسبق.

المصدر: https://x.com/0xCygaar/status/1871421277832954055

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

مصدر: https://x.com/deepwormxyz/status/1867190794354078135

منذ@tee_hee_heبعد أن قامت شركة Gate.io بفتح مصدر جميع الشفرة المطلوبة للنشر، أصبح من السهل نسبيًا نشر وتنفيذ وكلاء الذكاء الاصطناعي القائمة على TEE الموثوق بها والتي لا يمكن خداعها. مؤخرًا، قامت شبكة Phala بنشر Eliza التابعة لشركة a16z في TEE. كما أشارت a16z في تقريرها المتعلق برؤية سوق العملات المشفرة لعام 2025، من المتوقع أن يكون سوق وكلاء الذكاء الاصطناعي القائمة على TEE هو البنية التحتية الأساسية المهمة في سوق العملات الميمكوين في المستقبل.

2.7. لعبة اجتماعية

Azuki Bobu

قامت أزوكي ، وهي مشروع Ethereum NFT مشهور ، بالتعاون مع فلاشبوتس في أكتوبر الماضي لاستضافة حدث اجتماعي فريد.

المصدر: https://x.com/Azuki/status/1841906534151864557

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

مصدر: https://collective.flashbots.net/t/tee-enabled-social-games-an-experiment-with-bobu-s-magic-show/3963

تم تصميمه بواسطة Flashbots و Azuki ، وكانت هيكلة الحدث على النحو التالي:

1. توليد مفاتيح خاصة وشهادات TLS ، بالإضافة إلى مفاتيح خاصة Ethereum ، داخل Gramin-SGX.
2. أنشأ المستخدمون رموز OAuth المميزة بأذونات محدودة لنشر تغريدة واحدة وأرسلوها إلى TEE الخاص ب Flashbots عبر TLS.
3. تم إنشاء عقد على أربترام لإدارة شهادات المستخدم، مما يمنع الإنفاق المزدوج وتنفيذ نتائج الأحداث عند تحميل تغريدات المستخدم.

ضمنت Azuki موثوقية عملية الحدث عن طريق نشر صورة Docker لـ Enclave على Docker Hub. كما قاموا بتحميل البرامج النصية للتحقق من سجل شفافية الشهادات ونتائج التقارير البعيدة لبيئة TEE على GitHub. على الرغم من أن Flashbots حددت وجود مخاطر متبقية على الاعتمادات على عقد الاتصال البعيد وعقد البلوكشين ، إلا أنه يمكن التخفيف من خلال استخدام TEE RPC أو عقدات البيانات المدمجة المستندة إلى TEE مثل Unichain.

بينما لم يحقق المشروع اختراقًا تقنيًا ، إلا أنه يستحق الاهتمام لإجراء حدث اجتماعي موثوق يعتمد تمامًا على مجموعة TEE.

3. أمن TEE

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

1) آلية الشهادة المركزية

كما ذكرنا سابقا ، يمكن للمستخدمين استخدام آليات التصديق عن بعد للتحقق من سلامة جيوب TEE وأن البيانات داخل الجيوب لم يتم العبث بها. ومع ذلك ، فإن عملية التحقق هذه تعتمد حتما على خوادم الشركة المصنعة للشرائح. تختلف درجة الثقة قليلا حسب البائع - يعتمد SGX / TDX تماما على خادم التصديق الخاص ب Intel ، بينما يسمح SEV لمالكي VM بإجراء التصديق مباشرة. هذه مشكلة متأصلة في هيكل TEE ، ويعمل باحثو TEE على حل هذه المشكلة من خلال تطوير TEE مفتوح المصدر ، والذي سنذكره لاحقا.

2) هجمات قناة جانبية

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

• تسرب تدفق التحكم: قد تقوم أنظمة التشغيل أو البرامج الضارة باسترداد البيانات عن طريق استغلال المعلومات المتاحة. على سبيل المثال ، يمكنهم الاستفادة من حقيقة أن الوصول إلى بيانات ذاكرة التخزين المؤقت لوحدة المعالجة المركزية أسرع بكثير من الوصول إلى بيانات DRAM. يتيح لهم ذلك تحديد أنماط تنفيذ التعليمات البرمجية للعملية واستنتاج معلومات البرنامج الرئيسية ، مثل مفاتيح RSA. بالإضافة إلى ذلك، قد يحدث هجوم عندما يقيد نظام تشغيل ضار الوصول إلى صفحة الذاكرة، مما يتسبب في حدوث أخطاء في الصفحة في التعليمات البرمجية للجيب لكشف أنماط الوصول إلى الذاكرة. يمكن أن يؤدي التعامل مع المخزن المؤقت لهدف الفرع للتنبؤ بفروع التعليمات البرمجية وإدارتها أيضا إلى الكشف عن تدفق تنفيذ التعليمات البرمجية. علاوة على ذلك ، قد يقوم المهاجمون بشكل متكرر بتنفيذ كود الجيب في هجمات المجهر لاستنتاج المعلومات.
• تسرب البيانات: يمكن أن تؤدي الثغرات الأمنية التي تسرب بيانات Enclave إلى هجمات خطيرة ، مما قد يقوض التصديق عن بعد. والجدير بالذكر أنه تم تسريب المفاتيح السرية داخل Enclave من خلال إنشاء تطبيقات ظل تحاكي كود وبيانات Enclave ، وتنفيذ هجمات شرطة عمان السلطانية عليها (Dark-ROP). تنشأ نقاط ضعف إضافية من وحدات المعالجة المركزية Intel التي تنفذ برامج لتحسين الأداء (Foreshadow). على الرغم من أن ذاكرة Enclave محمية بالتشفير ، إلا أن البيانات التي يتم الوصول إليها عن طريق التعليمات المنفذة بشكل تخميني يمكن أن تظل لفترة وجيزة في ذاكرة التخزين المؤقت. يمكن استغلال هذا لقراءة بيانات Enclave من خلال هجمات القناة الجانبية لذاكرة التخزين المؤقت.
• هجمات الخداع: بالنسبة لـ SGX ، عندما تكتشف فحوص السلامة التلاعب في سلامة الذاكرة ، يتوقف النظام. تم استغلال هذا الثغرة في هجمات الخداع عن طريق تسبب فعليًا في فشل فحوص السلامة. يمكن للمهاجمين تسبب توقف النظام عن طريق الوصول المتكرر إلى صفوف DRAM محددة لإحداث انقلابات بت في الصفوف المجاورة ، مما يلحق ضررًا بذاكرة المحاذاة بالحاوية بشكل محتمل.

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

source: https://x.com/hdevalence/status/1613247598139428864

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

3) الاستغلالات الحقيقية / الحديثة في TEE

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

• شبكة Secret: كواحدة من ضحايا الاستغلال الحقيقي لـ TEE ، تعرض هذا المشروع القائم على SGX لهجوم تسرب AEIC الذي اكتشف في عام 2022. استهدف الهجوم مجموعة التعليمات AVX (Advanced Vector Extensions) في وحدات المعالجة المركزية الحديثة من Intel. استغل أنماط التنفيذ المتوقعة أثناء عمليات AVX لاسترداد مفاتيح التشفير المخزنة في مناطق المحيط. استخدمت شبكة Secret محصول الاتفاق بين المشاركين لفك تشفير المعاملات الخاصة. استخرج المهاجم هذا المحصول بنجاح ، مما أدى إلى فك تشفير جميع المعاملات الخاصة التاريخية على الشبكة. تم وصف المزيد من التفاصيل حول هذا الضعف في الرابط المبين في الأسفل.sgx.fail.
• التعرض لمفتاح الجذر SGX: في أغسطس ، أعلن الباحث الأمني مارك إرمولوف عن فك تشفير ناجح لمفتاح توفير الجذر ومفتاح ختم الجذر في SGX ، وهما مكونان أساسيان لنموذج ثقة التشفير الخاص ب SGX. عادة ما تكون هذه المفاتيح محمية بمنطق معقد داخل جهاز Fuse Controller الفعلي. ومع ذلك ، تم العثور على ثغرة أمنية حرجة حيث بقيت نسخ من هذه المفاتيح في المخازن المؤقتة الداخلية أثناء العمليات. على الرغم من أن امتلاك هذين المفتاحين وحدهما لا يضر تماما ب SGX ، إلا أن الحصول على مفتاح التغليف العالمي قد يعرض نظام SGX بأكمله لنقاط ضعف. على الرغم من إهمال SGX في وحدات المعالجة المركزية Intel التجارية التي تم إصدارها بعد عام 2021 ، إلا أنها لا تزال ناقل هجوم قابل للتطبيق نظرا لأن العديد من المشاريع لا تزال تستخدمها.
• ثغرة AMD SEV-SNP: أظهر AMD SEV ، وهو تطبيق TEE جديد نسبيا مع نطاق حماية واسع على مستوى الجهاز الظاهري ، تاريخيا نقاط ضعف أقل مقارنة ب SGX. ومع ذلك ، فإن قبول ورقة في IEEE S &2025 تناقش "Badram" ، وهي ثغرة أمنية تستهدف AMD SEV-SNP ، يسلط الضوء على أنه حتى تطبيقات TEE الحديثة ليست محصنة ضد العيوب الأمنية. يستغل BadRAM وحدات ذاكرة DDR4 و DDR5 لإنشاء تعرج مساحة العنوان في الذاكرة الفعلية. باستخدام Raspberry Pi Pico ، الذي يكلف حوالي 10 دولارات ، يمكن للمهاجمين تعديل رقائق الذاكرة لخداع وحدة المعالجة المركزية حول حجم الذاكرة الفعلية. هذا يتجاوز بشكل فعال آلية حماية RMP (جدول الخريطة العكسي) الخاصة ب AMD SEV-SNP. مزيد من التفاصيل حول الثغرة موصوفة في badram.eu.

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

4. الاستنتاج: المصدر المفتوح هو المستقبل

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

• المستوى 1: يوفر سرية كافية لتطبيقات الأوراق المالية والجسر، وتعتمد الأمان على سلسلة التوريد. أمثلة على ذلك تشمل SGX.
• المستوى 2: يحتفظ بمستوى الأمان 1 مع تعزيز تجربة المطور ودعم التطبيقات المتقدمة مثل تفويض حساب OAuth، كما هو الحال مع تليبورت. غرامين SGX يمثل هذا المستوى.
• المستوى 3: يوسع الأمان المستوى 1 بدعم وحدة معالجة الرسومات (GPU)، مما يتيح تطبيقات متطورة مثل التعلم الآلي الخاص والقابل للتحقق. يمثل إنتل TDX + Nvidia Confidential Computing هذا الطبقة.
• المستوى 4: يستخدم مجموعات تعليمات مفتوحة المصدر مع عمليات تصنيع قابلة للتحقق على الملأ، مما يزيل التبعيات عن موردي الأجهزة، كما يوضح OpenTEE.
• المستوى 5: يحقق حالة مثالية حيث يعمل عدة OpenTEEs معًا من خلال FHE/MPC ، محافظًا على النزاهة حتى لو تم التسلل إلى وحدات الأجهزة الفردية.

حاليًا ، تعمل مشاريع مثل Phala Network's Confidential AI Inference على المستوى 3 ، في حين يظل معظم الخدمات على المستوى 2 باستخدام cloud TEE أو Intel TDX. على الرغم من أن مشاريع Web3 TEE-based يجب أن تتقدم في نهاية المطاف إلى الأجهزة المستوى 4 ، إلا أن القيود الحالية في الأداء تجعل هذا غير عملي. ومع ذلك ، مع الشركات الرأسمالية الكبرى مثل Paradigm وفرق البحث مثل Flashbots و Nethermind التي تعمل نحو تمكين TEE ، ونظرًا لتوافق TEE مع مبادئ Web3 ، من المرجح أن يصبح البنية التحتية الأساسية الأساسية لمشاريع Web3.

حول ChainLight

مستكشف النظام البيئي هو تقرير ChainLight الذي يقدم تحليلاً داخليًا حول المشاريع الرائجة في نظام الويب 3 من وجهة نظر الأمان، والذي يتم كتابته من قبل محللينا البحثيين. بمهمة مساعدة الباحثين في مجال الأمان والمطورين في التعلم والنمو والمساهمة في جعل الويب 3 مكانًا أكثر أمانًا، نقوم بنشر تقريرنا بشكل دوري ومجاني.

لتلقي أحدث الأبحاث والتقارير التي أجراها خبراء حائزون على جوائز:

👉 تابع @ChainLight_io @c4lvin

تأسست في عام 2016، يقدم خبراء ChainLight الحائزين على جوائز حلول أمان مصممة خصيصًا لتعزيز العقد الذكي الخاص بك ومساعدتك على الازدهار على سلسلة الكتل.

إخلاء المسؤولية:

1. تمت إعادة طبع هذه المقالة من [Chainlight]. جميع حقوق النشر تنتمي إلى المؤلف الأصلي [c4lvin*]. إذا كان هناك اعتراضات على هذا النشر المطبوع ، يرجى الاتصال بـ بوابة التعلمالفريق، وسيتولون التعامل معه على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي آراء المؤلف فقط ولا تشكل نصيحة استثمارية.
3. قام فريق Gate Learn بترجمة المقالة إلى لغات أخرى. يحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها ما لم يذكر ذلك.