المؤلف: @Web3_Mario
الملخص: كنت أبحث عن اتجاه جديد للمشروع مؤخرًا. عندما كنت أقوم بتصميم المنتج، صادفت مجموعة من التقنيات لم أتعامل معها من قبل، لذا أجريت بعض الأبحاث ورتبت تجربتي التعليمية لأشاركها معكم. بشكل عام، zkTLS هي تقنية جديدة تجمع بين إثبات عدم المعرفة (ZKP) وTLS (بروتوكول أمان طبقة النقل). في مسار Web3، يتم استخدامها بشكل أساسي في بيئة الآلة الافتراضية على السلسلة. يمكنها التحقق من صحة بيانات HTTPS خارج السلسلة التي تقدمها دون الوثوق بطرف ثالث. تتضمن الأصالة هنا ثلاثة جوانب: مصدر البيانات يأتي من مورد HTTPS معين، ولم يتم العبث بالبيانات المسترجعة، ويمكن ضمان صحة البيانات. من خلال آلية التنفيذ التشفيرية هذه، يمكن للعقود الذكية الموجودة على السلسلة الحصول على وصول موثوق إلى موارد HTTPS Web2 خارج السلسلة، مما يؤدي إلى كسر صوامع البيانات.
ما هو بروتوكول TLS
من أجل الحصول على فهم أعمق لقيمة تقنية zkTLS، من الضروري إجراء نظرة عامة موجزة على بروتوكول TLS. أولاً، يتم استخدام TLS (أمان طبقة النقل) لتوفير التشفير والمصادقة وسلامة البيانات في اتصالات الشبكة لضمان النقل الآمن للبيانات بين العملاء (مثل المتصفحات) والخوادم (مثل مواقع الويب). بالنسبة لأولئك الذين ليسوا في مجال تطوير الشبكات، قد تجد أنه عند زيارة موقع ويب، يتم وضع بادئة https في بعض أسماء النطاقات، في حين يتم وضع بادئة http في أسماء نطاقات أخرى. عند الوصول إلى الأخير، ستطالبك المتصفحات السائدة بأنه غير آمن. من المرجح أن يواجه الخيار الأول رسائل مثل "رابطك ليس رابطًا خاصًا" أو أخطاء شهادة HTTPS. السبب وراء هذه المطالبة هو توفر بروتوكول TLS.
على وجه التحديد، يستخدم بروتوكول HTTPS بروتوكول TLS المبني على بروتوكول HTTP لضمان خصوصية وسلامة نقل المعلومات وجعل صحة الخادم قابلة للتحقق. كما نعلم، HTTP هو بروتوكول شبكة ينقل نصًا عاديًا، ولا يمكنه التحقق من صحة الخادم، مما يؤدي إلى العديد من المشكلات الأمنية:
1. قد تتم مراقبة المعلومات التي يتم نقلها بينك وبين الخادم بواسطة جهة خارجية، مما يؤدي إلى تسرب الخصوصية؛
2. لا يمكنك التحقق من صحة الخادم، أي ما إذا كان طلبك قد تم اختطافه بواسطة عقد ضارة أخرى وأعاد معلومات ضارة؛
3. لا يمكنك التحقق من سلامة المعلومات المسترجعة، أي ما إذا كان فقدان البيانات قد يكون ناجمًا عن أسباب تتعلق بالشبكة؛
تم تصميم بروتوكول TLS لحل هذه المشاكل. دعوني أشرح لكم الأمر هنا. ربما يعرف بعضكم بروتوكول SSL. في الواقع، تم تطوير بروتوكول TLS استنادًا إلى إصدار SSL 3.1. لقد تم تغيير اسمه فقط بسبب بعض المشكلات المتعلقة بالأعمال، ولكنه في الواقع على نفس المنوال. لذلك، في بعض الأحيان وفي بعض السياقات، يمكن استخدام الكلمتين بالتبادل.
الفكرة الرئيسية لبروتوكول TLS لحل المشاكل المذكورة أعلاه هي:
1. الاتصالات المشفرة: استخدم التشفير المتماثل (AES، ChaCha20) لحماية البيانات ومنع التنصت.
2. مصادقة الهوية: استخدم شهادة رقمية (مثل شهادة X.509) صادرة عن جهة خارجية إلى مؤسسة معينة للتحقق من هوية الخادم ومنع هجمات الرجل في المنتصف (MITM).
3. سلامة البيانات: استخدم HMAC (رمز مصادقة رسالة التجزئة) أو AEAD (التشفير الموثق) للتأكد من عدم العبث بالبيانات.
دعونا نشرح بإيجاز التفاصيل الفنية لبروتوكول HTTPS المستند إلى بروتوكول TLS في عملية تفاعل البيانات. تنقسم العملية برمتها إلى مرحلتين. الأولى هي مرحلة المصافحة، أي أن العميل والخادم يتفاوضان على معلمات الأمان ويؤسسان جلسة مشفرة. المرحلة الثانية هي مرحلة نقل البيانات، والتي تستخدم مفتاح الجلسة للاتصالات المشفرة. تنقسم العملية المحددة إلى أربع خطوات:
1. يرسل العميل ClientHello:
يقوم العميل (مثل المتصفح) بإرسال رسالة ClientHello إلى الخادم، والتي تتضمن:
إصدارات TLS المدعومة (مثل TLS 1.3)
خوارزميات التشفير المدعومة (مجموعات التشفير، مثل AES-GCM وChaCha20)
أرقام عشوائية (Client Random) (تستخدم لتوليد المفتاح)
معلمات مشاركة المفتاح (مثل المفتاح العام ECDHE)
SNI (إشارة اسم الخادم) (اختياري، يستخدم لدعم HTTPS متعدد النطاقات)
الغرض منه هو إعلام الخادم بقدرات التشفير الخاصة بالعميل وإعداد معلمات الأمان.
2. يرسل الخادم ServerHello:
يستجيب الخادم برسالة ServerHello، والتي تتضمن:
خوارزمية التشفير المحددة
رقم عشوائي للخادم (Server Random)
شهادة الخادم (شهادة X.509)
معلمات مشاركة مفتاح الخادم (مثل المفتاح العام ECDHE)
رسالة الانتهاء (تستخدم للتأكيد على اكتمال المصافحة)
الغرض منه هو السماح للعميل بمعرفة هوية الخادم وتأكيد معايير الأمان.
3. يتحقق العميل من الخادم:
يقوم العميل بإجراء العمليات التالية:
التحقق من شهادة الخادم: تأكد من أن الشهادة صادرة عن جهة إصدار شهادات موثوقة، وتحقق مما إذا كانت الشهادة قد انتهت صلاحيتها أو تم إلغاؤها؛
حساب المفتاح المشترك: استخدم المفتاح العام ECDHE الخاص بك ومفتاح الخادم لحساب مفتاح الجلسة، والذي يستخدم للتشفير المتماثل (مثل AES-GCM) للاتصالات اللاحقة.
إرسال رسالة الانتهاء: إثبات سلامة بيانات المصافحة ومنع هجمات الرجل في المنتصف (MITM).
الغرض منه هو التأكد من أن الخادم جدير بالثقة وإنشاء مفاتيح الجلسة.
4. ابدأ الاتصال المشفر:
يتواصل العميل والخادم الآن بشكل مشفر باستخدام مفتاح الجلسة المتفق عليه.
وبالتالي، بعد هذه الخطوات الأربع، يمكن حل مشكلة بروتوكول HTTP بشكل فعال. ومع ذلك، تسببت هذه التقنية الأساسية، التي تُستخدم على نطاق واسع في شبكة Web2، في حدوث مشكلات في تطوير تطبيقات Web3، وخاصةً عندما يريد العقد الذكي الموجود على السلسلة الوصول إلى بيانات معينة خارج السلسلة. وبسبب مشكلات توفر البيانات، لن تفتح الآلة الافتراضية الموجودة على السلسلة القدرة على استدعاء البيانات الخارجية لضمان إمكانية تتبع جميع البيانات، وبالتالي ضمان أمان آلية الإجماع.
ومع ذلك، بعد سلسلة من التكرارات، وجد المطورون أن DApp لا يزال لديه طلب على البيانات خارج السلسلة، لذلك ظهرت سلسلة من مشاريع Oracle، مثل Chainlink وPyth. إنهم يكسرون ظاهرة صوامع البيانات هذه من خلال العمل كجسر تتابع بين البيانات الموجودة على السلسلة والبيانات خارج السلسلة. في الوقت نفسه، من أجل ضمان توفر بيانات التتابع، يتم تنفيذ هذه Oracles بشكل عام من خلال آلية إجماع PoS، أي أن تكلفة السلوك الضار لعقدة التتابع أعلى من الفائدة، بحيث لن تقدم معلومات خاطئة إلى السلسلة من وجهة نظر اقتصادية. على سبيل المثال، إذا أردنا الوصول إلى السعر المرجح لعملة البيتكوين (BTC) على البورصات المركزية مثل Binance و Coinbase في عقد ذكي، فنحن بحاجة إلى الاعتماد على هذه Oracles للوصول إلى البيانات وتجميعها خارج السلسلة ونقلها إلى العقد الذكي الموجود على السلسلة للتخزين قبل أن نتمكن من استخدامها.
ما هي المشكلة التي يحلها zkTLS؟
ومع ذلك، وجد الناس أن حل اكتساب البيانات المستند إلى Oracle يعاني من مشكلتين:
1. التكلفة المفرطة: نعلم أنه لضمان أن البيانات التي ترسلها Oracle إلى السلسلة أصلية ولم يتم العبث بها، يلزم وجود آلية إجماع PoS. ومع ذلك، فإن أمان آلية إجماع PoS يعتمد على مقدار الأموال المتعهد بها، مما يؤدي إلى تكاليف الصيانة. علاوة على ذلك، في ظل الظروف العادية، هناك قدر كبير من التكرار في تفاعل البيانات في آلية إجماع PoS، لأن مجموعة البيانات تحتاج إلى النقل والحساب والتلخيص بشكل متكرر في الشبكة قبل أن تتمكن من اجتياز الإجماع، مما يزيد أيضًا من تكلفة استخدام البيانات. لذلك، عادةً، من أجل جذب العملاء، ستحتفظ مشاريع Oracle فقط ببعض البيانات الأكثر شيوعًا مجانًا، مثل أسعار الأصول السائدة مثل BTC. للاحتياجات الحصرية، عليك أن تدفع ثمنها. ويؤدي هذا إلى إعاقة الابتكار في التطبيقات، وخاصة بعض المطالب الطويلة المخصصة.
2. كفاءة منخفضة للغاية: بشكل عام، يستغرق توافق آلية إثبات الحصة قدرًا معينًا من الوقت، مما يتسبب في تأخر البيانات على السلسلة. وهذا لا يناسب بعض سيناريوهات الوصول عالية التردد لأن هناك تأخيرًا كبيرًا بين البيانات التي تم الحصول عليها على السلسلة والبيانات الفعلية خارج السلسلة.
من أجل حل المشكلات المذكورة أعلاه، ظهرت تقنية zkTLS. وتتمثل فكرتها الرئيسية في تقديم خوارزمية إثبات المعرفة الصفرية ZKP، بحيث يمكن للعقد الذكي على السلسلة أن يعمل كطرف ثالث للتحقق بشكل مباشر من أن البيانات التي توفرها العقدة هي بالفعل البيانات التي تم إرجاعها بعد الوصول إلى مورد HTTPS معين ولم يتم العبث بها. يمكن أن يؤدي هذا إلى تجنب تكلفة الاستخدام العالية لـ Oracle التقليدية الناجمة عن خوارزمية الإجماع.
قد يتساءل بعض الأصدقاء عن سبب عدم تضمين القدرة على استدعاء واجهة برمجة التطبيقات Web2 بشكل مباشر في بيئة VM الموجودة على السلسلة. الإجابة هي لا، لأن السبب وراء ضرورة الاحتفاظ بالبيانات المغلقة في بيئة السلسلة هو ضمان إمكانية تتبع جميع البيانات. أي أنه في عملية الإجماع، تتمتع جميع العقد بمنطق تقييم موحد لدقة بيانات معينة أو نتيجة تنفيذ معينة، أو منطق تحقق موضوعي. يضمن هذا أنه في بيئة خالية من الثقة تمامًا، يمكن لمعظم العقد ذات النية الحسنة الاعتماد على بياناتها الزائدة عن الحاجة لتحديد صحة النتائج المباشرة. ومع ذلك، بسبب بيانات Web2، من الصعب بناء مثل هذا المنطق التقييمي الموحد، لأنه بسبب بعض تأخيرات الشبكة، تكون النتائج التي تم الحصول عليها من العقد المختلفة التي تصل إلى موارد Web2 HTTPS مختلفة، مما يضيف صعوبات إلى الإجماع، خاصة بالنسبة لبعض مناطق البيانات عالية التردد. بالإضافة إلى ذلك، هناك مشكلة رئيسية أخرى وهي أن أمان بروتوكول TLS الذي يعتمد عليه بروتوكول HTTPS يعتمد على الأرقام العشوائية التي يولدها العميل (Client Random) (لتوليد المفاتيح) ومعلمات مشاركة المفاتيح لتحقيق التفاوض مع الخادم للحصول على مفاتيح التشفير. ومع ذلك، فإننا نعلم أن بيئة السلسلة مفتوحة وشفافة. إذا احتفظ العقد الذكي بأرقام عشوائية ومعلمات مشاركة المفاتيح، فسوف يتم الكشف عن البيانات الرئيسية، وبالتالي المساس بخصوصية البيانات.
يستخدم zkTLS نهجًا آخر. وتتلخص فكرته في استبدال التكلفة العالية لتوافر البيانات القائمة على الإجماع التقليدي من Oracle بالحماية التشفيرية. على غرار تحسين OP-Rollup بواسطة ZK-Rollup في L2. على وجه التحديد، من خلال تقديم دليل المعرفة الصفرية ZKP، وحساب وتوليد الدليل للموارد التي تم الحصول عليها بواسطة عقدة التتابع خارج السلسلة التي تطلب HTTPS معينًا، ومعلومات التحقق من شهادة CA ذات الصلة، وإثبات التوقيت، وإثبات سلامة البيانات بناءً على HMAC أو AEAD، والحفاظ على معلومات التحقق اللازمة وخوارزمية التحقق على السلسلة، يمكن للعقد الذكي التحقق من صحة وفعالية وموثوقية مصدر البيانات دون الكشف عن المعلومات الرئيسية. لا تتم مناقشة تفاصيل الخوارزمية المحددة هنا، ويمكن للمهتمين دراستها بعمق بأنفسهم.
إن أكبر فائدة لهذا الحل التقني هي أنه يقلل من تكلفة تحقيق توافر موارد Web2 HTTPS. وقد أدى هذا إلى تحفيز العديد من المطالب الجديدة، وخاصة في تقليل عملية الاستحواذ على أسعار الأصول طويلة المدى على السلسلة، واستخدام مواقع الويب ذات السلطة في عالم Web2 لأداء KYC على السلسلة، وبالتالي تحسين تصميم البنية الفنية لألعاب DID وWeb3. بالطبع، يمكننا أن نجد أن zkTLS له أيضًا تأثير على شركات Web3 الحالية، وخاصةً على مشاريع Oracle السائدة الحالية. لذلك، من أجل التعامل مع هذا التأثير، تتابع شركات الصناعة العملاقة مثل Chainlink وPyth بنشاط الأبحاث في الاتجاهات ذات الصلة، في محاولة للحفاظ على موقف مهيمن في عملية التكرار التكنولوجي. وفي الوقت نفسه، سيؤدي ذلك أيضًا إلى ولادة نماذج أعمال جديدة، مثل التحول من الشحن الأصلي القائم على الوقت إلى الشحن القائم على الاستخدام، والحوسبة كخدمة، وما إلى ذلك. وبطبيعة الحال، فإن الصعوبة هنا هي نفسها التي تواجه معظم مشاريع ZK، وهي كيفية تقليل تكلفة الحوسبة وجعلها ذات قيمة تجارية.
باختصار، عند تصميم المنتجات، يمكنك أيضًا الاهتمام بتطوير zkTLS ودمج مجموعة التكنولوجيا هذه في الجوانب المناسبة. ربما يمكنك العثور على بعض الاتجاهات الجديدة في مجال الابتكار التجاري والهندسة المعمارية التقنية.
Weatherly
Anais
Alex
Miyuki
Weiliang
Catherine
Joy
Kikyo