AWS غير مناسب لـ Web3: يمكن لسحابة TEE اللامركزية تحسين الكفاءة 10 مرات

يقوم الأشخاص يوميًا بتوليد ما يصل إلى 402 مليون تيرابايت من البيانات الحساسة. مع تزايد إحجام الأفراد عن مشاركة بياناتهم على نطاق واسع، تتزايد الحاجة إلى إجراء عمليات حسابية خاصة على تلك البيانات. وتعتمد هذه الحلول بشكل أساسي على البنية التحتية لـ Amazon Web Services (AWS)، التي تمثل حوالي 30% من سوق الحوسبة السحابية العالمية.

ومع ذلك، فإن AWS لديها العديد من العيوب، ويرجع ذلك أساسًا إلى بنيتها المركزية. حتى مع تقديم الحوسبة الآمنة المحسنة من خلال AWS Nitro Enclaves، لا تزال هناك تحديات كبيرة في تبني المطورين، مما يشكل حاجزًا عميقًا أمام أمان blockchain وتطبيقات Web3. ستقوم هذه المقالة بتحليل الوضع الحالي لـ AWS وتقديم حل سحابي لامركزي لـ TEE لا يحل أوجه القصور في AWS فحسب، بل يتغلب أيضًا على قيود TEEs الأخرى الموجودة. ومع ذلك، قبل ذلك، نحتاج إلى استكشاف سبب اكتساب AWS ومنتجه Nitro Enclaves لهذه الشعبية الكبيرة وحصة السوق، وما هي القضايا التي تكمن وراء هذه التطورات.

AWS Nitro وTEE

تُعد AWS حاليًا منصة الحوسبة السحابية الأكثر شهرة، حيث توفر مجموعة غنية من الأدوات. باختصار، AWS هي في الأساس بنية تحتية سحابية تلبي جميع احتياجات الحوسبة للمطورين، بما في ذلك خدمات الحوسبة والتخزين وقواعد البيانات. كما نعلم جميعًا، تستحوذ AWS على حوالي 30% من حصة سوق البنية التحتية السحابية، وهي نسبة كبيرة. يستخدم ما يقرب من 48% من مهندسي البرمجيات أو المطورين AWS بطريقة ما، لذا فهو مطلوب بشكل كبير. ومع توسع الطلب وقاعدة العملاء لتشمل المؤسسات المالية الكبيرة والهيئات الحكومية والشركات الناشئة التي تحتوي على بيانات شديدة الحساسية، أثيرت تساؤلات حول أمان AWS وما إذا كانت هذه الكيانات قادرة على تخزين هذه البيانات واستخدامها بأمان للحوسبة السرية. في هذا السياق، جاءت AWS بفكرة تنفيذ TEE على منصتها لحماية البيانات قيد الاستخدام، وتكملة تشفير البيانات أثناء السكون والبيانات أثناء النقل.

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

القيود التي تتجاوز مركزية AWS

بالإضافة إلى العيوب المركزية لجميع المكونات والبيانات التي تعتمد على نظام واحد، فإن AWS Nitro Enclaves تجلب أيضًا المزيد من التحديات واعتبارات أمنية جديدة. تقوم AWS بربط بطاقات Nitro متعددة (أجهزة مخصصة) بوحدة المعالجة المركزية لتشغيل حمولات TEE، مما يؤدي إلى إنشاء مخاطر أمنية مزدوجة: قد تحتوي كل من وحدة المعالجة المركزية الأساسية وبطاقة Nitro على نقاط ضعف.

المشكلة الرئيسية في Nitro Enclaves هي عدم وجود آلية تشفير ذاكرة كاملة. على عكس الحلول التي يتم فيها دمج تشفير الذاكرة مباشرة في وحدة المعالجة المركزية، فإن الطبيعة الخارجية لبطاقة Nitro تجعل من الصعب ضمان تشفير البيانات في الذاكرة من البداية إلى النهاية. قد يؤدي هذا التكوين إلى تعريض المعلومات الحساسة للتلاعب أثناء عمليات الوصول إلى الذاكرة لأن التشفير يعتمد على التفاعل بين وحدة المعالجة المركزية والأجهزة الخارجية. بالإضافة إلى ذلك، لا يزال المطورون بحاجة إلى استخدام Docker لإنشاء وتكوين Amazon Machine Images (AMIs) التي تحتوي على برنامج Enclave، وهو أمر قد يكون صعبًا بالنسبة للأشخاص غير الملمين بالحاويات. ويحتاجون أيضًا إلى استخدام AWS CLI وNitro Enclaves CLI لتشغيل الحالات وإدارة الجيوب، والتنقل عبر واجهة برمجة تطبيقات Nitro Enclaves، والتكامل مع خدمة AWS Key Management، والتي تتطلب في بعض الأحيان فهم عملية الإثبات التشفيري. يؤدي اعتماد TEE على بطاقة Nitro إلى أدلة غير قابلة للتحقق لأن قياس سلامة الكود يأتي من بطاقة Nitro، وليس وحدة المعالجة المركزية نفسها. تعتمد AWS على المطورين والمسؤولين لتعيين سياسات إدارة الهوية والوصول، والتي قد تمنحهم إمكانية الوصول إلى بيانات حساسة. تشكل حقوق الوصول عالية المستوى التي يتمتعون بها خطر تهديد داخلي لأنهم قد يتمكنون من عرض البيانات أو التلاعب بها.

فحص افتراضات الثقة في AWS Nitro

ومع ذلك، فإن القيد الأكثر أهمية هو أن AWS غير مُحسَّن للتطبيقات والنظم البيئية اللامركزية، يفتقر إلى الدعم الأصلي لحالات استخدام Web3 أو أنظمة الحوكمة.

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

كما أن إدارة المفاتيح لا تتوافق مع سيناريو "الثقة الصفرية". على الرغم من توفر خدمة AWS Key Management Service (KMS)، إلا أنها مصممة لـ Web2 وتسمح للمسؤولين بالوصول إلى المفاتيح الخاصة. يتعارض هذا مع متطلبات Web3 التي تنص على أن المفاتيح يجب أن تكون خاضعة للتحكم الكامل بواسطة الكود ولا يجب أن تكون متاحة لأي شخص (بما في ذلك المسؤولين).

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

لماذا يحتاج Web3 إلى TEE؟

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

إنشاء سحابة TEE لامركزية

لفهم مفهوم سحابة TEE اللامركزية، يجب علينا أولاً تحديد ما هي السحابة اللامركزية. إذن ما هو الأمر؟

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

سحابة TEE اللامركزية

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

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

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

لماذا يعد إنشاء سحابة TEE لامركزية أمرًا صعبًا للغاية؟

TEE في حد ذاته ليس مركزيًا ولا لامركزيًا، ودرجة مركزيته تعتمد على كيفية تنفيذه ونشره في النظام. TEE هي منطقة آمنة ومعزولة داخل المعالج مصممة لحماية التعليمات البرمجية والبيانات الحساسة من الوصول غير المصرح به بواسطة نظام التشغيل أو العمليات الأخرى على نفس الجهاز. يعتمد ما إذا كان TEE يعمل في وضع مركزي أو لامركزي على بنية النظام الأوسع الذي يوجد فيه. تاريخيًا، كان إنشاء أنظمة مركزية أسهل من إنشاء أنظمة لامركزية لأن الأخيرة تواجه تحديات في التنفيذ والاتصال بين العقد. قبل Phala Cloud، نجحنا في إنشاء Phala Network 1.0 (SGX) اللامركزية بالكامل. يتم حاليًا تطوير Phala Cloud بنفس المفهوم، على الرغم من أن الأمر سيستغرق بعض الوقت. Phala هي المنصة الوحيدة حاليًا التي تجمع بين TEE واللامركزية الكاملة، على عكس مقدمي الخدمة المركزيين أو البروتوكولات اللامركزية جزئيًا.

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

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

Phala Cloud وAWS

أولاً، عملية إعداد AWS لـ Nitro Enclaves معقدة. يتضمن ذلك خطوات متعددة، بما في ذلك تثبيت Nitro CLI، وتحويل صورة Docker إلى ملف Enclave، ومعالجة نقل الملف، وهو أمر يستغرق وقتًا طويلاً.

على النقيض من ذلك، يسمح Phala للمطورين بنشر "الهجرة والتعديل" ونقل حاويات Docker الموجودة بسهولة إلى TEEs الآمنة. باستخدام Dstack SDK، يستطيع المطورون تحويل حاويات Docker إلى أجهزة افتراضية سرية مع الحد الأدنى من التغييرات ونشرها من خلال واجهة مستخدم سحابية سهلة الاستخدام، مع الاستمرار في دعم القوالب وملفات Docker Compose المخصصة. من حيث الأمان، تعتمد AWS على الثقة بالمطورين والمسؤولين لتكوين عناصر التحكم في الوصول وإدارة الموارد بشكل صحيح. على الرغم من أن AWS تستخدم TEEs للحوسبة المعزولة، فإن البنية الأساسية المركزية تتطلب الثقة في AWS والأشخاص الذين يديرون النظام، وهو ما قد يؤدي إلى الوصول إلى بيانات حساسة. تتبنى شركة فالا نموذج الثقة الصفرية ولا تثق بأي طرف بشكل افتراضي. تظل البيانات الحساسة آمنة داخل TEE ولا يمكن الوصول إليها حتى من قبل مشغلي العقد، مما يجعلها مناسبة لتطبيقات Web3 التي تتطلب تشغيلًا بدون ثقة. من منظور المنتج، تخدم AWS بشكل أساسي عملاء المؤسسات نظرًا لوجود عدد كبير من المؤسسات في مجال تكنولوجيا المعلومات التقليدي. ولذلك، فهي لا تلبي بشكل كامل القيمة المقترحة للشركات الناشئة التي تستخدم تقنية Web3 من حيث المنتجات والتكنولوجيا. على النقيض من ذلك، تم تصميم Phala خصيصًا للتطبيقات اللامركزية. إنه يدعم بشكل أصلي وكلاء الذكاء الاصطناعي الذين يتفاعلون مع العقود الذكية blockchain وتطبيقات DApps التي تحافظ على الخصوصية.

بالإضافة إلى ذلك، تم دمج Phala بشكل عميق في نظام blockchain البيئي من خلال الشراكات مع بروتوكولات مختلفة وعمليات التكامل لتطبيقات DApps التي تريد الاستفادة من أمان TEE. تم وضع Phala كطبقة تنفيذية لـ Web3 AI، مما يتيح للمطورين بناء وإطلاق والاستفادة من وكلاء الذكاء الاصطناعي الذين يمكنهم فهم العقود الذكية blockchain والتفاعل معها بشكل آمن وخاص. نحن ندعم منصات الذكاء الاصطناعي اللامركزية مثل NEAR AI وSentient من خلال الاستفادة من NVIDIA GPU TEE لتشغيل نماذج اللغة الكبيرة (LLMs) في بيئة آمنة وقابلة للتحقق وتركز على الخصوصية. على سبيل المثال، تسلط شراكتنا مع NOTAI الضوء على تنفيذ وكلاء الذكاء الاصطناعي بدون ثقة، حيث نقدم الثقة الكاملة وحماية الخصوصية من خلال TEE وRA Explorer.

نحن ندعم أيضًا التكامل مع التطبيقات غير المرتبطة بالذكاء الاصطناعي من خلال عقود Phat، وهي عقود ذكية منخفضة التكلفة ومنخفضة زمن الوصول مع دعم طلب HTTP الأصلي. ومع ذلك، نظرًا لأن العديد من فرق التشفير الأصلية تعمل أيضًا على بناء TEEs وطرق حوسبة آمنة أخرى، فكيف يميز Phala نفسه عن هذه الحلول؟

حلول Phala السحابية وTEE

تتميز شبكة Phala بأنها السحابة الوحيدة اللامركزية بالكامل TEE، والتي توفر الحوسبة الآمنة والخاصة والقابلة للتحقق للتطبيقات اللامركزية. على عكس بروتوكول Oasis وSecret Network، اللذين يركزان على تنفيذ العقود الذكية المدعومة بالخصوصية باستخدام TEEs في سلاسل الكتل الخاصة بكل منهما، توفر Phala منصة حوسبة سحابية لامركزية عبر الشبكات للحوسبة خارج السلسلة.

تتميز Phala بالمرونة وقابلية التخصيص، حيث تستفيد من مجموعة واسعة من أجهزة TEE، بما في ذلك Intel SGX، وIntel TDX، وAMD SEV، وNVIDIA GPU TEE. يعمل بروتوكول Marlin على تعزيز أداء شبكة Web3 ولكنه لا يوفر إمكانيات حسابية أو خصوصية، في حين تعمل Oasis وSecret ضمن أنظمة blockchain محددة. تتمتع Phala بميزة فريدة باعتبارها السحابة الوحيدة اللامركزية TEE مع دعم واسع للأجهزة وأدوات تركز على المطورين مثل Dstack.

تختلف Phala في أنها توفر سحابة TEE عامة لامركزية، على عكس بروتوكول Oasis وMarlin وSecret Network، والتي تركز على حالات استخدام محددة. يتيح Phala للمطورين نشر أي تطبيق، مثل نماذج الذكاء الاصطناعي أو خوادم الويب أو قواعد البيانات، في بيئة آمنة. ويتم تحقيق ذلك من خلال Phat Contracts وPhata Cloud، الذي يدعم النشر Dockerized ويوفر الوصول بنقرة واحدة إلى وحدات المعالجة المركزية ووحدات معالجة الرسومات TEEs.

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

تدمج Phala TEE مع MPC لإنشاء نموذج جذر الثقة اللامركزي (DeRoT)، وهو نهج متقدم لحماية التطبيقات المستندة إلى TEE. يتم تشغيل MPC داخل TEE لتقليل مخاطر تواطؤ العقد، بينما يتم إرسال أدلة كتلة TEE مع أدلة MPC للتخفيف من الأخطاء في تنفيذات دليل المعرفة الصفرية (ZKP). إن مطالبة عقد MPC بالعمل داخل TEE يعزز هذا النظام متعدد الأدلة بشكل أكبر. يستخدم نموذج DeRoT تقنيات TEE وMPC وZKP لتوزيع الثقة في الشبكة. يعمل هذا النهج على تحسين أمان التطبيقات اللامركزية التي تستخدم TEEs من خلال معالجة التهديدات المحتملة على مستوى الأجهزة أو العقدة.

إمكانية إنشاء سحابة TEE لامركزية

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

أولاً، يدعم Phala نشر نماذج الذكاء الاصطناعي داخل TEE، مما يضمن عمليات آمنة ومستقلة تتفاعل مع شبكات blockchain. يتضمن ذلك وكلاء الذكاء الاصطناعي لتحسين العقود الذكية والتفاعلات بين الوكلاء. يمكن للمطورين استخدام GPU TEE للحوسبة بالذكاء الاصطناعي لتحقيق حماية حقيقية ضد الرقابة والخصوصية. يمكن للمطورين أيضًا نقل التطبيقات التقليدية إلى بيئة آمنة وخالية من الثقة لتحسين الأمان. تتيح المنصة تحليل البيانات مع الحفاظ على الخصوصية من خلال Web3 والأدوات التحليلية التقليدية التي يمكنها تحليل البيانات دون الكشف عن معلومات المستخدم الفردية. بالإضافة إلى ذلك، يمكنه أيضًا تعزيز الحوسبة الآمنة لـ DeFi من خلال ميزات الخصوصية، مثل مراكز التداول السرية أو تداول المجمع المظلم. أخيرًا، يمكن لسحب TEE اللامركزية تنفيذ حماية MEV من خلال نقل بناء الكتلة إلى TEEs لتحقيق الترتيب والتنفيذ العادل.

هناك العديد من المنتجات التي تستخدم Phala كجزء من البنية التحتية الخاصة بها. سنتعمق أكثر في كيفية استخدام هذه المنتجات لـ Phala وما تستفيده من هذا التكامل في منشور آخر.

الخلاصة

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

يوضح هذا النموذج العديد من الممارسات الرئيسية في Web3:

1. يجب مراجعة كود العقد الذكي بدقة لإزالة الأبواب الخلفية أو الثغرات الأمنية.

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

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

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