يومياً، ينتج الناس ما يصل إلى 4.02 مليون تيرابايت من البيانات الحساسة. مع تزايد تردد الأفراد في مشاركة البيانات على نطاق واسع، تتزايد الحاجة إلى حسابات خاصة لهذه البيانات. تعتمد هذه الحلول بشكل رئيسي على بنية أمازون ويب سيرفيسز (AWS)، التي تمتلك حوالي 30% من حصة سوق الحوسبة السحابية العالمية.
ومع ذلك، فإن AWS لديها عدة عيوب، تنبع أساسًا من هيكلها المركزي. حتى مع إدخال الحوسبة الآمنة المعززة من خلال AWS Nitro Enclaves، لا تزال تواجه تحديات كبيرة في اعتماد المطورين، مما يشكل عقبة عميقة أمام أمن blockchain وتطبيقات Web3.
ستقوم هذه المقالة بتحليل الوضع الحالي لـ AWS، وتقديم حل سحابي لبيئات التنفيذ الموثوقة (TEE) اللامركزية، والذي لا يحل فقط أوجه القصور في AWS، بل يتغلب أيضًا على قيود TEE الحالية الأخرى. ومع ذلك، قبل ذلك، نحتاج إلى استكشاف سبب حصول 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، مما ينتمي إلى إطار عمل مركزي للغاية. من الإنشاء إلى الإنهاء، يتم التحكم في جميع جوانب إدارة Enclave بواسطة بنية AWS التحتية، وبالنظر إلى طبيعة AWS كمزود سحابي مركزي، فإن هذا يعتبر مركزيًا في جوهره.
باختصار، توفر AWS Nitro Enclaves عزلًا قويًا من خلال بيئة تنفيذ موثوقة قائمة على الأجهزة لحماية أحمال العمل الحساسة. ومع ذلك، فإن هيكلها المركزي يقدم بعض القيود والمفاضلات.
قيود خارج AWS المركزية
بالإضافة إلى مركزية الاعتماد على نظام واحد لجميع المكونات والبيانات ، تقدم AWS Nitro Enclaves تحديات إضافية واعتبارات أمنية جديدة. تقوم AWS بتوصيل العديد من بطاقات Nitro (الأجهزة المخصصة) بوحدة المعالجة المركزية لتشغيل حمولة TEE، مما يخلق مخاطر أمنية مزدوجة: يمكن أن تحدث الثغرات الأمنية في كل من وحدة المعالجة المركزية الأساسية وبطاقة Nitro.
تتمثل إحدى المشكلات الرئيسية في Nitro Enclaves في نقص آلية تشفير الذاكرة المتكاملة. على عكس الحلول التي يتم دمج تشفير الذاكرة مباشرة في المعالج، فإن الطبيعة الخارجية لبطاقة Nitro تجعل من الصعب ضمان تشفير البيانات في الذاكرة من النهاية إلى النهاية. قد يؤدي هذا التكوين إلى كشف معلومات حساسة للتلاعب أثناء الوصول إلى الذاكرة، حيث يعتمد التشفير على التفاعل بين المعالج والأجهزة الخارجية.
بالإضافة إلى ذلك، يحتاج المطورون إلى استخدام Docker لإنشاء وتكوين صورة آلة أمازون (AMI) تحتوي على برنامج Enclave، وهذا قد يكون صعبًا بالنسبة لأولئك غير المألوفين بالتعبئة. يحتاجون أيضًا إلى استخدام AWS CLI وNitro Enclaves CLI لبدء المثيلات وإدارة Enclave، والتنقل في واجهة برمجة تطبيقات Nitro Enclaves، والاندماج مع خدمة إدارة مفاتيح AWS، مما يتطلب في بعض الأحيان فهم عملية إثبات التشفير.
تعتمد TEE على بطاقة Nitro مما يؤدي إلى إثباتات غير قابلة للتحقق، لأن قياس سلامة الكود يأتي من بطاقة Nitro، وليس من وحدة المعالجة المركزية نفسها.
تثق AWS في المطورين والمديرين لإعداد سياسات إدارة الهوية والوصول، مما قد يمكّنهم من الوصول إلى بيانات حساسة. إن صلاحياتهم العالية في الوصول تخلق مخاطر تهديدات داخلية، حيث قد يقومون بمراجعة أو تعديل البيانات.
مراجعة فرضية الثقة لـ AWS Nitro
ومع ذلك، فإن أكبر قيود هي أن AWS لم يتم تحسينه لتطبيقات اللامركزية والأنظمة البيئية، ويفتقر إلى الدعم الأصلي لحالات استخدام Web3 أو أنظمة الحوكمة.
على سبيل المثال، تفتقر AWS Nitro Enclaves إلى التخزين الدائم. على الرغم من أن هذا العزل مفيد للأمان، إلا أنه يعيق حالات الاستخدام مثل الحاجة إلى تخزين بيانات المستخدم في قاعدة بيانات المتجهات الخاصة بالوكلاء الذكيين.
إدارة المفاتيح لا تتماشى أيضًا مع سيناريو "ثقة صفرية". على الرغم من أن خدمة إدارة المفاتيح من AWS (KMS) متاحة، إلا أنها مصممة خصيصًا لـ Web2، مما يسمح للمسؤولين بالوصول إلى المفاتيح الخاصة. وهذا يتعارض مع متطلبات Web3 التي تتطلب أن يتم التحكم في المفاتيح بالكامل بواسطة الشفرة وألا يتم الكشف عنها لأي شخص (بما في ذلك المسؤولين).
تقدم Nitro Enclaves حلاً لمشكلة عدم ثقة المطورين في السحابة، لكن Web3 يتطلب تحقيق حلول بدون ثقة بين المستخدمين والمطورين والموردين. لا تدعم الترقية الآمنة للشفرة، وتتطلب ملكية لامركزية تشبه حوكمة العقود الذكية، ويجب على المطورين البناء من الصفر، مما قد يستغرق عدة أشهر، وإذا تم تنفيذها بشكل غير صحيح، قد تحتوي الشفرة على ثغرات.
بسبب نقص الوصول إلى الشبكة، فإن إعداد خدمات الويب يستغرق وقتًا وجهدًا، مما يجبر المطورين على كتابة كود كبير لتكييف التطبيقات وضمان الأمان التشفيري، وغالبًا ما لا يكون هذا مثاليًا.
لماذا يحتاج Web3 إلى TEE؟
نحن نستخدم TEE لأننا لا نستطيع الوثوق الكامل بالمطورين أو المسؤولين. يمتلك المشاركون في Web3 فلسفات مختلفة ويسعون إلى أنظمة غير موثوقة: إذا كان هناك شيء ما يجب الوثوق به ، فلا يبدو موثوقا به للغاية. لهذا السبب يعتمد المستخدمون على مشغلي الأجهزة لفحص التطبيقات وإدارتها. يمكن فصل التطبيقات لمنعها من التدخل في البيانات الحساسة أو كشطها أو تغييرها أثناء الوصول إلى الذاكرة ، حيث يعتمد التشفير على التعاون السلس بين وحدة المعالجة المركزية والأجهزة الخارجية. يحتاج المستخدمون ومزودو البيانات إلى ضمانات واضحة والتحقق من الإجراءات التي يتم تنفيذها على بياناتهم.
عند تطوير شبكة فالا، كانت نيتنا هي دمج مزايا AWS مع أمان TEE، من خلال القضاء على التعقيد عبر اللامركزية، مع تعزيز الأمان في نفس الوقت. تهدف هذه الطريقة إلى تلبية احتياجات حالات استخدام Web3. كانت النتيجة هي تقديم مفهوم السحابة اللامركزية الخاصة بـ TEE، لتوفير الأمان والتكامل للتطبيقات اللامركزية.
إنشاء سحابة TEE لامركزية
لفهم مفهوم السحابة اللامركزية TEE، يجب أولاً تعريف ما هي السحابة اللامركزية. إذن، ما هي؟
السحابة اللامركزية هي بنية تحتية للحوسبة حيث يتم تخزين البيانات ومعالجتها وإدارتها عبر شبكة من العقد المتعددة، بدلاً من تركيزها في خادم مركزي أو مركز بيانات واحد. على عكس أنظمة السحابة المركزية التقليدية مثل AWS، لا تتطلب السحابة اللامركزية كيان تحكم واحد، بل تعتمد على تقنية البلوكشين للعمل.
السحابة اللامركزية TEE
الحوسبة السحابية المعتمدة على TEE اللامركزية هي بنية تحتية حاسوبية تجمع بين TEE وشبكة من العقد اللامركزية، لتوفير حوسبة آمنة وخاصة وقابلة للتحقق. كل عقدة مزودة بـ TEE لحماية الشفرات والبيانات الحساسة من الوصول أو التلاعب من قبل مشغلي العقد.
يتكون Phala Network من شبكة لامركزية من عقد العمل، حيث يتم تجهيز كل عقدة بـ TEE. تقوم هذه العقد بتنفيذ مهام الحوسبة للمستخدمين بناءً على احتياجات العملاء، مثل تشغيل العقود الذكية أو معالجة البيانات الحساسة.
تبدأ هذه العملية عندما يقوم المستخدم بنشر تطبيقه أو مهمته على الشبكة. يتم تنفيذ المهام الحسابية داخل TEE لهذه العقد، مما يضمن أن تظل الشفرة والبيانات سرية، حتى مشغلي العقد لا يمكنهم رؤيتها أو التلاعب بها.
!
تستخدم Phala إثباتات التشفير للتحقق مما إذا كانت العمليات الحسابية داخل TEE قد تم تنفيذها بشكل صحيح. يحصل مشغلو العقد على مكافآت لتقديم خدمات صادقة وآمنة، من خلال الحوافز الاقتصادية للحفاظ على سلامة الشبكة. على الرغم من أن هذا يبدو بسيطًا، إلا أن تنفيذ هذا الحل أكثر تعقيدًا مما يبدو.
لماذا من الصعب إنشاء سحابة TEE لامركزية؟
إن TEE ليس مركزيًا أو لامركزيًا في حد ذاته، بل تعتمد درجة مركزيته على كيفية تنفيذها ونشرها في النظام. TEE هو منطقة عزل آمنة داخل المعالج، تهدف إلى حماية الشفرات والبيانات الحساسة من الوصول غير المصرح به من نظام التشغيل أو العمليات الأخرى على نفس الجهاز. يعمل TEE في نمط مركزي أو لامركزي، اعتمادًا على بنية النظام الأوسع الذي ينتمي إليه.
تاريخيا ، كان إنشاء نظام مركزي أبسط من إنشاء نظام لامركزي ، والذي واجه تحديات من حيث التنفيذ واتصال العقدة. قبل Phala Cloud ، نجحنا في إنشاء شبكة Phala اللامركزية بالكامل 1.0 (SGX). يتم الآن تطوير Phala Cloud بنفس الفلسفة ، على الرغم من أن الأمر سيستغرق وقتا. Phala هي حاليا المنصة الوحيدة التي تجمع بين TEE واللامركزية الكاملة ، على عكس مقدمي الخدمات المركزيين أو البروتوكولات اللامركزية جزئيا.
تبدو مزايا اللامركزية وTEE واضحة، لكن لا تزال غير كافية في تطوير المنتجات. تخيل أن علي بابا هي أكبر منصة للتجارة الإلكترونية في العالم، وتحتل حصة سوقية ضخمة. إذا تم إطلاق منتج جديد بضعف الوظائف وبسعر أقل، هل سيحتل السوق بأكمله؟ للأسف، لن يحدث ذلك، لأن الناس قد اعتادوا على المنتجات الحالية، حتى لو كان المنتج الجديد أفضل، سيكون لديهم تحيز تجاهه.
كان هذا أحد التحديات التي واجهناها ، ولكن بدلا من المضي قدما في ضعف التحسن ، تأكدنا من أن فالا ، التي كانت أفضل بعشر مرات من المنافسة ، كانت سهلة الاستخدام. بالإضافة إلى ذلك ، كما ذكرنا سابقا ، فإن AWS ليست مناسبة لبيئة Web3 ، ونهدف إلى سد هذه الفجوة لتطبيقات ومطوري Web3. بالإضافة إلى الميزة الواضحة للامركزية ، نريد أيضا تسليط الضوء على الاختلافات الأخرى بين Phala و AWS.
فالا كلاود وAWS
أولاً، إن إعداد Nitro Enclaves في AWS معقد. يتضمن ذلك عدة خطوات، بما في ذلك تثبيت Nitro CLI، وتحويل صور Docker إلى ملفات Enclave، ومعالجة نقل الملفات، وكلها تستغرق وقتًا طويلاً.
بالمقارنة، يسمح Phala للمطورين "بالنشر والتعديل الفوري"، وينقل بسهولة حاويات Docker الحالية إلى TEE آمن. باستخدام Dstack SDK، يحتاج المطورون فقط إلى إجراء تغييرات طفيفة لتحويل حاويات Docker إلى جهاز افتراضي سري (Confidential VM)، ويتم نشرها من خلال واجهة Cloud UI سهلة الاستخدام، مع دعم القوالب وملفات Docker Compose المخصصة.
عندما يتعلق الأمر بالأمان ، تعتمد AWS على الثقة في المطورين والمسؤولين لتكوين عناصر التحكم في الوصول وإدارة الموارد بشكل صحيح. على الرغم من أن AWS تستخدم TEE للحوسبة المعزولة، إلا أن بنيتها التحتية المركزية تتطلب أشخاصا يثقون في AWS ويديرون النظام، مما قد يؤدي إلى الوصول إلى البيانات الحساسة. يستخدم Phala نموذج انعدام الثقة ولا يثق بأي طرف افتراضيا. تظل البيانات الحساسة آمنة داخل TEE ولا يمكن الوصول إليها حتى لمشغلي العقد، مما يجعلها مناسبة لتطبيقات Web3 التي تتطلب عمليات غير موثوقة.
من منظور المنتج، تقدم AWS خدماتها بشكل رئيسي لعملاء الشركات، نظرًا لوجود عدد كبير من الشركات في مجال تكنولوجيا المعلومات التقليدية. وبالتالي، لم تتوافق تمامًا في المنتجات والتقنيات مع مقترحات القيمة الخاصة بشركات Web3 الناشئة. بالمقابل، تم بناء Phala خصيصًا للتطبيقات اللامركزية. إنها تدعم بشكل أصلي وكلاء الذكاء الاصطناعي الذين يتفاعلون مع العقود الذكية على البلوكشين بالإضافة إلى DApp لحماية الخصوصية.
بالإضافة إلى ذلك، تعتبر Phala جزءًا عميقًا من نظام blockchain البيئي من خلال شراكات مع بروتوكولات متنوعة ودمج DApps التي تأمل في الاستفادة من أمان TEE.
تم وضع Phala كطبقة تنفيذ ل Web3 الذكاء الاصطناعي ، مما يتيح للمطورين إنشاء وكلاء الذكاء الاصطناعي وإطلاقهم وتحقيق الدخل منهم يمكنهم فهم عقود blockchain الذكية والتفاعل معها بشكل آمن وخاص. نحن ندعم منصات الذكاء الاصطناعي اللامركزية مثل NEAR الذكاء الاصطناعي و Sentient من خلال الاستفادة من NVIDIA GPU TEE لتشغيل نماذج اللغات الكبيرة (LLMs) في بيئة آمنة ويمكن التحقق منها وتركز على الخصوصية. على سبيل المثال ، تسلط شراكتنا مع NOTAI الضوء على إنفاذ انعدام الثقة لوكلاء الذكاء الاصطناعي ، حيث نوفر حماية خصوصية وموثوقة من خلال TEE و RA Explorer.
نحن ندعم أيضًا تكامل التطبيقات غير المتعلقة بالذكاء الاصطناعي من خلال عقود Phat، وهي عقود ذكية منخفضة التكلفة وذات زمن استجابة منخفض مع دعم الطلبات HTTP الأصلية.
ومع ذلك، بالنظر إلى أن العديد من الفرق الأصلية في مجال التشفير تبني أيضًا TEE وطرق حسابية آمنة أخرى، كيف يمكن أن تميز Phala نفسها عن هذه الحلول؟
Phala Cloud مع حلول TEE
تظهر شبكة فالا كأول شبكة سحابية لتي إي (TEE) بالكامل وغير مركزية، حيث توفر حوسبة آمنة وخاصة وقابلة للتحقق لتطبيقات DApp. على عكس بروتوكول أواسيز وشبكة سيكريت، التي تركز على استخدام تي إي لتحقيق العقود الذكية التي تتيح الخصوصية ضمن سلاسلها الخاصة، تقدم فالا منصة حوسبة سحابية لامركزية للحوسبة غير المتصلة عبر الشبكات.
Phala مرنة وقابلة للتخصيص ، وتستفيد من مجموعة واسعة من أجهزة TEE ، بما في ذلك Intel SGX و Intel TDX و AMD SEV و NVIDIA GPU TEE. يعمل بروتوكول Marlin على تحسين أداء شبكة Web3 ولكنه لا يوفر ميزات الحوسبة أو الخصوصية ، بينما تعمل Oasis و Secret في نظام بيئي محدد ل blockchain. تم وضع Phala بشكل فريد كسحابة TEE اللامركزية الوحيدة مع دعم شامل للأجهزة وأدوات تتمحور حول المطورين مثل Dstack.
!
تتمثل ميزة Phala في أنها تقدم سحابة TEE مركزية عامة، على عكس Oasis Protocol وMarlin وSecret Network التي تركز على حالات استخدام محددة. يسمح Phala للمطورين بنشر أي تطبيق في بيئة آمنة، مثل نماذج الذكاء الاصطناعي أو خوادم الويب أو قواعد البيانات. يتم تحقيق ذلك من خلال عقود Phat وPhala Cloud، والتي تدعم النشر المبني على Docker، ويمكن الوصول إليها بنقرة واحدة إلى CPU وGPU TEE.
بالإضافة إلى ذلك، هناك الكثير من المقارنات حول أيهما أكثر ملاءمة لحالات الاستخدام المحددة، 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 عن طريق نقل بنيات الكتل إلى TEE من أجل الطلب والتنفيذ العادلين.
توجد العديد من المنتجات التي تستخدم Phala كجزء من بنيتها التحتية. سنستكشف في مقال آخر كيف تستخدم هذه المنتجات Phala وما الذي حصلت عليه من هذا التكامل.
الاستنتاج
هناك اختلافات جوهرية في نماذج الثقة في Web3 و Web2 ، مما يؤدي إلى قيود على منصات مثل AWS. في Web3 ، تكون البيانات ، بما في ذلك الرموز المميزة التي هي بيانات بشكل أساسي ، مملوكة للمستخدم حقا ، ولا يتم الوثوق بمطوري التطبيقات افتراضيا. ينبع انعدام الثقة هذا من احتمال أن يحاول المطورون الوصول إلى بيانات المستخدم أو تعديلها أو سرقتها دون إذن.
تفسر هذه النمط عدة ممارسات رئيسية في Web3:
يجب أن يتم مراجعة كود العقود الذكية بدقة لإزالة أي أبواب خلفية أو ثغرات.
ملكية العقد الذكي (أو التحكم الإداري) هي مسألة رئيسية، حيث يولي المستخدمون أهمية أكبر للشفافية بدلاً من السماح للمطورين بالتحكم غير المحدود.
في الحالة المثالية، يجب على المطورين في بيئة Web3 كتابة ونشر كود العقود الذكية، ثم التخلي عن جميع سلطاتهم وعدم الاحتفاظ بأي امتيازات على التطبيق.
على عكس العقود الذكية، يمكن لـ TEE تنفيذ جميع مبادئ الملكية والتحكم المماثلة ضمن نطاق برامج أوسع. ومع ذلك، تعمل AWS Nitro Enclaves ضمن إطار Web2، حيث يحتفظ المطورون بقدرة تسجيل الدخول والوصول إلى البيانات وتعديل التطبيقات. تم تصميم TEE الخاص بـ Phala وفقًا لمبادئ Web3، ويدعم بشكل أصلي العقود الذكية لإدارة التطبيقات المعتمدة على TEE، بما يتماشى مع نموذج الثقة اللامركزية.
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
AWS غير مناسب لـ Web3: يمكن أن يعزز سحابة TEE اللامركزية الكفاءة بمقدار 10 مرات
يومياً، ينتج الناس ما يصل إلى 4.02 مليون تيرابايت من البيانات الحساسة. مع تزايد تردد الأفراد في مشاركة البيانات على نطاق واسع، تتزايد الحاجة إلى حسابات خاصة لهذه البيانات. تعتمد هذه الحلول بشكل رئيسي على بنية أمازون ويب سيرفيسز (AWS)، التي تمتلك حوالي 30% من حصة سوق الحوسبة السحابية العالمية.
ومع ذلك، فإن AWS لديها عدة عيوب، تنبع أساسًا من هيكلها المركزي. حتى مع إدخال الحوسبة الآمنة المعززة من خلال AWS Nitro Enclaves، لا تزال تواجه تحديات كبيرة في اعتماد المطورين، مما يشكل عقبة عميقة أمام أمن blockchain وتطبيقات Web3.
ستقوم هذه المقالة بتحليل الوضع الحالي لـ AWS، وتقديم حل سحابي لبيئات التنفيذ الموثوقة (TEE) اللامركزية، والذي لا يحل فقط أوجه القصور في AWS، بل يتغلب أيضًا على قيود TEE الحالية الأخرى. ومع ذلك، قبل ذلك، نحتاج إلى استكشاف سبب حصول 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، مما ينتمي إلى إطار عمل مركزي للغاية. من الإنشاء إلى الإنهاء، يتم التحكم في جميع جوانب إدارة Enclave بواسطة بنية AWS التحتية، وبالنظر إلى طبيعة AWS كمزود سحابي مركزي، فإن هذا يعتبر مركزيًا في جوهره.
باختصار، توفر AWS Nitro Enclaves عزلًا قويًا من خلال بيئة تنفيذ موثوقة قائمة على الأجهزة لحماية أحمال العمل الحساسة. ومع ذلك، فإن هيكلها المركزي يقدم بعض القيود والمفاضلات.
قيود خارج AWS المركزية
بالإضافة إلى مركزية الاعتماد على نظام واحد لجميع المكونات والبيانات ، تقدم AWS Nitro Enclaves تحديات إضافية واعتبارات أمنية جديدة. تقوم AWS بتوصيل العديد من بطاقات Nitro (الأجهزة المخصصة) بوحدة المعالجة المركزية لتشغيل حمولة TEE، مما يخلق مخاطر أمنية مزدوجة: يمكن أن تحدث الثغرات الأمنية في كل من وحدة المعالجة المركزية الأساسية وبطاقة Nitro.
تتمثل إحدى المشكلات الرئيسية في Nitro Enclaves في نقص آلية تشفير الذاكرة المتكاملة. على عكس الحلول التي يتم دمج تشفير الذاكرة مباشرة في المعالج، فإن الطبيعة الخارجية لبطاقة Nitro تجعل من الصعب ضمان تشفير البيانات في الذاكرة من النهاية إلى النهاية. قد يؤدي هذا التكوين إلى كشف معلومات حساسة للتلاعب أثناء الوصول إلى الذاكرة، حيث يعتمد التشفير على التفاعل بين المعالج والأجهزة الخارجية.
بالإضافة إلى ذلك، يحتاج المطورون إلى استخدام Docker لإنشاء وتكوين صورة آلة أمازون (AMI) تحتوي على برنامج Enclave، وهذا قد يكون صعبًا بالنسبة لأولئك غير المألوفين بالتعبئة. يحتاجون أيضًا إلى استخدام AWS CLI وNitro Enclaves CLI لبدء المثيلات وإدارة Enclave، والتنقل في واجهة برمجة تطبيقات Nitro Enclaves، والاندماج مع خدمة إدارة مفاتيح AWS، مما يتطلب في بعض الأحيان فهم عملية إثبات التشفير.
تعتمد TEE على بطاقة Nitro مما يؤدي إلى إثباتات غير قابلة للتحقق، لأن قياس سلامة الكود يأتي من بطاقة Nitro، وليس من وحدة المعالجة المركزية نفسها.
تثق AWS في المطورين والمديرين لإعداد سياسات إدارة الهوية والوصول، مما قد يمكّنهم من الوصول إلى بيانات حساسة. إن صلاحياتهم العالية في الوصول تخلق مخاطر تهديدات داخلية، حيث قد يقومون بمراجعة أو تعديل البيانات.
مراجعة فرضية الثقة لـ AWS Nitro
ومع ذلك، فإن أكبر قيود هي أن AWS لم يتم تحسينه لتطبيقات اللامركزية والأنظمة البيئية، ويفتقر إلى الدعم الأصلي لحالات استخدام Web3 أو أنظمة الحوكمة.
على سبيل المثال، تفتقر AWS Nitro Enclaves إلى التخزين الدائم. على الرغم من أن هذا العزل مفيد للأمان، إلا أنه يعيق حالات الاستخدام مثل الحاجة إلى تخزين بيانات المستخدم في قاعدة بيانات المتجهات الخاصة بالوكلاء الذكيين.
إدارة المفاتيح لا تتماشى أيضًا مع سيناريو "ثقة صفرية". على الرغم من أن خدمة إدارة المفاتيح من AWS (KMS) متاحة، إلا أنها مصممة خصيصًا لـ Web2، مما يسمح للمسؤولين بالوصول إلى المفاتيح الخاصة. وهذا يتعارض مع متطلبات Web3 التي تتطلب أن يتم التحكم في المفاتيح بالكامل بواسطة الشفرة وألا يتم الكشف عنها لأي شخص (بما في ذلك المسؤولين).
تقدم Nitro Enclaves حلاً لمشكلة عدم ثقة المطورين في السحابة، لكن Web3 يتطلب تحقيق حلول بدون ثقة بين المستخدمين والمطورين والموردين. لا تدعم الترقية الآمنة للشفرة، وتتطلب ملكية لامركزية تشبه حوكمة العقود الذكية، ويجب على المطورين البناء من الصفر، مما قد يستغرق عدة أشهر، وإذا تم تنفيذها بشكل غير صحيح، قد تحتوي الشفرة على ثغرات.
بسبب نقص الوصول إلى الشبكة، فإن إعداد خدمات الويب يستغرق وقتًا وجهدًا، مما يجبر المطورين على كتابة كود كبير لتكييف التطبيقات وضمان الأمان التشفيري، وغالبًا ما لا يكون هذا مثاليًا.
لماذا يحتاج Web3 إلى TEE؟
نحن نستخدم TEE لأننا لا نستطيع الوثوق الكامل بالمطورين أو المسؤولين. يمتلك المشاركون في Web3 فلسفات مختلفة ويسعون إلى أنظمة غير موثوقة: إذا كان هناك شيء ما يجب الوثوق به ، فلا يبدو موثوقا به للغاية. لهذا السبب يعتمد المستخدمون على مشغلي الأجهزة لفحص التطبيقات وإدارتها. يمكن فصل التطبيقات لمنعها من التدخل في البيانات الحساسة أو كشطها أو تغييرها أثناء الوصول إلى الذاكرة ، حيث يعتمد التشفير على التعاون السلس بين وحدة المعالجة المركزية والأجهزة الخارجية. يحتاج المستخدمون ومزودو البيانات إلى ضمانات واضحة والتحقق من الإجراءات التي يتم تنفيذها على بياناتهم.
عند تطوير شبكة فالا، كانت نيتنا هي دمج مزايا AWS مع أمان TEE، من خلال القضاء على التعقيد عبر اللامركزية، مع تعزيز الأمان في نفس الوقت. تهدف هذه الطريقة إلى تلبية احتياجات حالات استخدام Web3. كانت النتيجة هي تقديم مفهوم السحابة اللامركزية الخاصة بـ TEE، لتوفير الأمان والتكامل للتطبيقات اللامركزية.
إنشاء سحابة TEE لامركزية
لفهم مفهوم السحابة اللامركزية TEE، يجب أولاً تعريف ما هي السحابة اللامركزية. إذن، ما هي؟
السحابة اللامركزية هي بنية تحتية للحوسبة حيث يتم تخزين البيانات ومعالجتها وإدارتها عبر شبكة من العقد المتعددة، بدلاً من تركيزها في خادم مركزي أو مركز بيانات واحد. على عكس أنظمة السحابة المركزية التقليدية مثل AWS، لا تتطلب السحابة اللامركزية كيان تحكم واحد، بل تعتمد على تقنية البلوكشين للعمل.
السحابة اللامركزية TEE
الحوسبة السحابية المعتمدة على TEE اللامركزية هي بنية تحتية حاسوبية تجمع بين TEE وشبكة من العقد اللامركزية، لتوفير حوسبة آمنة وخاصة وقابلة للتحقق. كل عقدة مزودة بـ TEE لحماية الشفرات والبيانات الحساسة من الوصول أو التلاعب من قبل مشغلي العقد.
يتكون Phala Network من شبكة لامركزية من عقد العمل، حيث يتم تجهيز كل عقدة بـ TEE. تقوم هذه العقد بتنفيذ مهام الحوسبة للمستخدمين بناءً على احتياجات العملاء، مثل تشغيل العقود الذكية أو معالجة البيانات الحساسة.
تبدأ هذه العملية عندما يقوم المستخدم بنشر تطبيقه أو مهمته على الشبكة. يتم تنفيذ المهام الحسابية داخل TEE لهذه العقد، مما يضمن أن تظل الشفرة والبيانات سرية، حتى مشغلي العقد لا يمكنهم رؤيتها أو التلاعب بها.
!
تستخدم Phala إثباتات التشفير للتحقق مما إذا كانت العمليات الحسابية داخل TEE قد تم تنفيذها بشكل صحيح. يحصل مشغلو العقد على مكافآت لتقديم خدمات صادقة وآمنة، من خلال الحوافز الاقتصادية للحفاظ على سلامة الشبكة. على الرغم من أن هذا يبدو بسيطًا، إلا أن تنفيذ هذا الحل أكثر تعقيدًا مما يبدو.
لماذا من الصعب إنشاء سحابة TEE لامركزية؟
إن TEE ليس مركزيًا أو لامركزيًا في حد ذاته، بل تعتمد درجة مركزيته على كيفية تنفيذها ونشرها في النظام. TEE هو منطقة عزل آمنة داخل المعالج، تهدف إلى حماية الشفرات والبيانات الحساسة من الوصول غير المصرح به من نظام التشغيل أو العمليات الأخرى على نفس الجهاز. يعمل TEE في نمط مركزي أو لامركزي، اعتمادًا على بنية النظام الأوسع الذي ينتمي إليه.
تاريخيا ، كان إنشاء نظام مركزي أبسط من إنشاء نظام لامركزي ، والذي واجه تحديات من حيث التنفيذ واتصال العقدة. قبل Phala Cloud ، نجحنا في إنشاء شبكة Phala اللامركزية بالكامل 1.0 (SGX). يتم الآن تطوير Phala Cloud بنفس الفلسفة ، على الرغم من أن الأمر سيستغرق وقتا. Phala هي حاليا المنصة الوحيدة التي تجمع بين TEE واللامركزية الكاملة ، على عكس مقدمي الخدمات المركزيين أو البروتوكولات اللامركزية جزئيا.
تبدو مزايا اللامركزية وTEE واضحة، لكن لا تزال غير كافية في تطوير المنتجات. تخيل أن علي بابا هي أكبر منصة للتجارة الإلكترونية في العالم، وتحتل حصة سوقية ضخمة. إذا تم إطلاق منتج جديد بضعف الوظائف وبسعر أقل، هل سيحتل السوق بأكمله؟ للأسف، لن يحدث ذلك، لأن الناس قد اعتادوا على المنتجات الحالية، حتى لو كان المنتج الجديد أفضل، سيكون لديهم تحيز تجاهه.
كان هذا أحد التحديات التي واجهناها ، ولكن بدلا من المضي قدما في ضعف التحسن ، تأكدنا من أن فالا ، التي كانت أفضل بعشر مرات من المنافسة ، كانت سهلة الاستخدام. بالإضافة إلى ذلك ، كما ذكرنا سابقا ، فإن AWS ليست مناسبة لبيئة Web3 ، ونهدف إلى سد هذه الفجوة لتطبيقات ومطوري Web3. بالإضافة إلى الميزة الواضحة للامركزية ، نريد أيضا تسليط الضوء على الاختلافات الأخرى بين Phala و AWS.
فالا كلاود وAWS
أولاً، إن إعداد Nitro Enclaves في AWS معقد. يتضمن ذلك عدة خطوات، بما في ذلك تثبيت Nitro CLI، وتحويل صور Docker إلى ملفات Enclave، ومعالجة نقل الملفات، وكلها تستغرق وقتًا طويلاً.
بالمقارنة، يسمح Phala للمطورين "بالنشر والتعديل الفوري"، وينقل بسهولة حاويات Docker الحالية إلى TEE آمن. باستخدام Dstack SDK، يحتاج المطورون فقط إلى إجراء تغييرات طفيفة لتحويل حاويات Docker إلى جهاز افتراضي سري (Confidential VM)، ويتم نشرها من خلال واجهة Cloud UI سهلة الاستخدام، مع دعم القوالب وملفات Docker Compose المخصصة.
عندما يتعلق الأمر بالأمان ، تعتمد AWS على الثقة في المطورين والمسؤولين لتكوين عناصر التحكم في الوصول وإدارة الموارد بشكل صحيح. على الرغم من أن AWS تستخدم TEE للحوسبة المعزولة، إلا أن بنيتها التحتية المركزية تتطلب أشخاصا يثقون في AWS ويديرون النظام، مما قد يؤدي إلى الوصول إلى البيانات الحساسة. يستخدم Phala نموذج انعدام الثقة ولا يثق بأي طرف افتراضيا. تظل البيانات الحساسة آمنة داخل TEE ولا يمكن الوصول إليها حتى لمشغلي العقد، مما يجعلها مناسبة لتطبيقات Web3 التي تتطلب عمليات غير موثوقة.
من منظور المنتج، تقدم AWS خدماتها بشكل رئيسي لعملاء الشركات، نظرًا لوجود عدد كبير من الشركات في مجال تكنولوجيا المعلومات التقليدية. وبالتالي، لم تتوافق تمامًا في المنتجات والتقنيات مع مقترحات القيمة الخاصة بشركات Web3 الناشئة. بالمقابل، تم بناء Phala خصيصًا للتطبيقات اللامركزية. إنها تدعم بشكل أصلي وكلاء الذكاء الاصطناعي الذين يتفاعلون مع العقود الذكية على البلوكشين بالإضافة إلى DApp لحماية الخصوصية.
بالإضافة إلى ذلك، تعتبر Phala جزءًا عميقًا من نظام blockchain البيئي من خلال شراكات مع بروتوكولات متنوعة ودمج DApps التي تأمل في الاستفادة من أمان TEE.
تم وضع Phala كطبقة تنفيذ ل Web3 الذكاء الاصطناعي ، مما يتيح للمطورين إنشاء وكلاء الذكاء الاصطناعي وإطلاقهم وتحقيق الدخل منهم يمكنهم فهم عقود blockchain الذكية والتفاعل معها بشكل آمن وخاص. نحن ندعم منصات الذكاء الاصطناعي اللامركزية مثل NEAR الذكاء الاصطناعي و Sentient من خلال الاستفادة من NVIDIA GPU TEE لتشغيل نماذج اللغات الكبيرة (LLMs) في بيئة آمنة ويمكن التحقق منها وتركز على الخصوصية. على سبيل المثال ، تسلط شراكتنا مع NOTAI الضوء على إنفاذ انعدام الثقة لوكلاء الذكاء الاصطناعي ، حيث نوفر حماية خصوصية وموثوقة من خلال TEE و RA Explorer.
نحن ندعم أيضًا تكامل التطبيقات غير المتعلقة بالذكاء الاصطناعي من خلال عقود Phat، وهي عقود ذكية منخفضة التكلفة وذات زمن استجابة منخفض مع دعم الطلبات HTTP الأصلية.
ومع ذلك، بالنظر إلى أن العديد من الفرق الأصلية في مجال التشفير تبني أيضًا TEE وطرق حسابية آمنة أخرى، كيف يمكن أن تميز Phala نفسها عن هذه الحلول؟
Phala Cloud مع حلول TEE
تظهر شبكة فالا كأول شبكة سحابية لتي إي (TEE) بالكامل وغير مركزية، حيث توفر حوسبة آمنة وخاصة وقابلة للتحقق لتطبيقات DApp. على عكس بروتوكول أواسيز وشبكة سيكريت، التي تركز على استخدام تي إي لتحقيق العقود الذكية التي تتيح الخصوصية ضمن سلاسلها الخاصة، تقدم فالا منصة حوسبة سحابية لامركزية للحوسبة غير المتصلة عبر الشبكات.
Phala مرنة وقابلة للتخصيص ، وتستفيد من مجموعة واسعة من أجهزة TEE ، بما في ذلك Intel SGX و Intel TDX و AMD SEV و NVIDIA GPU TEE. يعمل بروتوكول Marlin على تحسين أداء شبكة Web3 ولكنه لا يوفر ميزات الحوسبة أو الخصوصية ، بينما تعمل Oasis و Secret في نظام بيئي محدد ل blockchain. تم وضع Phala بشكل فريد كسحابة TEE اللامركزية الوحيدة مع دعم شامل للأجهزة وأدوات تتمحور حول المطورين مثل Dstack.
!
تتمثل ميزة Phala في أنها تقدم سحابة TEE مركزية عامة، على عكس Oasis Protocol وMarlin وSecret Network التي تركز على حالات استخدام محددة. يسمح Phala للمطورين بنشر أي تطبيق في بيئة آمنة، مثل نماذج الذكاء الاصطناعي أو خوادم الويب أو قواعد البيانات. يتم تحقيق ذلك من خلال عقود Phat وPhala Cloud، والتي تدعم النشر المبني على Docker، ويمكن الوصول إليها بنقرة واحدة إلى CPU وGPU TEE.
بالإضافة إلى ذلك، هناك الكثير من المقارنات حول أيهما أكثر ملاءمة لحالات الاستخدام المحددة، 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 عن طريق نقل بنيات الكتل إلى TEE من أجل الطلب والتنفيذ العادلين.
توجد العديد من المنتجات التي تستخدم Phala كجزء من بنيتها التحتية. سنستكشف في مقال آخر كيف تستخدم هذه المنتجات Phala وما الذي حصلت عليه من هذا التكامل.
الاستنتاج
هناك اختلافات جوهرية في نماذج الثقة في Web3 و Web2 ، مما يؤدي إلى قيود على منصات مثل AWS. في Web3 ، تكون البيانات ، بما في ذلك الرموز المميزة التي هي بيانات بشكل أساسي ، مملوكة للمستخدم حقا ، ولا يتم الوثوق بمطوري التطبيقات افتراضيا. ينبع انعدام الثقة هذا من احتمال أن يحاول المطورون الوصول إلى بيانات المستخدم أو تعديلها أو سرقتها دون إذن.
تفسر هذه النمط عدة ممارسات رئيسية في Web3:
ملكية العقد الذكي (أو التحكم الإداري) هي مسألة رئيسية، حيث يولي المستخدمون أهمية أكبر للشفافية بدلاً من السماح للمطورين بالتحكم غير المحدود.
على عكس العقود الذكية، يمكن لـ TEE تنفيذ جميع مبادئ الملكية والتحكم المماثلة ضمن نطاق برامج أوسع. ومع ذلك، تعمل AWS Nitro Enclaves ضمن إطار Web2، حيث يحتفظ المطورون بقدرة تسجيل الدخول والوصول إلى البيانات وتعديل التطبيقات. تم تصميم TEE الخاص بـ Phala وفقًا لمبادئ Web3، ويدعم بشكل أصلي العقود الذكية لإدارة التطبيقات المعتمدة على TEE، بما يتماشى مع نموذج الثقة اللامركزية.