zkTLS مخصص لمن يحتاجون إلى نقل قيم من صفحة ويب أو من API موثّق إلى عقد أو طرف مقابل، وليس وسيلة نقل جديدة تحل محل HTTPS. وبالمقارنة مع لقطات الشاشة أو الإفادات الذاتية، فإنه يحوّل عبارتي «وصلت الجلسة إلى الموقع المستهدف» و«يلبي الحقل شرطًا معينًا» إلى أدلة قابلة للتحقق. أما تدفقات بيانات السوق العامة والمستمرة، فغالبًا ما تعتمد على أوراكل البلوكشين؛ وترد المقارنة مع نمط التدفقات أدناه.
تغطي الأقسام التالية التعريف، وخطوات الانتقال من الجلسة إلى الإثبات، والفروقات بين MPC وProxy وTEE، وحالات الاستخدام، والمقارنة مع الأوراكل، والمخاطر، إلى جانب شروحات عامة للآليات، مثل شرح Oasis لـ zkTLS وصفحة نمط zk-TLS من EthSystems.
النقاط الرئيسية
- يحوّل zkTLS جلسة HTTPS إلى ادعاء قابل للتحقق: إذ يربط النطاق والشهادة، ويمكنه اختياريًا الإفصاح عن نتيجة شرط فقط.
- غالبًا ما يكون الاسم مضللًا: ليست كل التصاميم تستخدم إثباتات المعرفة الصفرية وقت المصافحة؛ وتُعد MPC وProxy وTEE المسارات الثلاثة الشائعة.
- لأن TLS ينتهي بمفتاح جلسة متماثل مشترك، يمكن للعميل بمفرده تزوير سجل جلسة وعرضه؛ ومن هنا تأتي الحاجة إلى الموثقين أو الوكلاء أو بيئات TEE.
- إثبات المصدر ليس إثباتًا لصحة المحتوى: إذا أعاد المصدر حقلًا خاطئًا، فقد يبقى الإثبات صالحًا من الناحية الشكلية.
- ينبغي للمتحققين التحقق من ربط النطاق/الشهادة، والشرط، وتوقيع التصديق أو جذر الثقة في مسار الإثبات.
ما هو zkTLS وما المشكلة التي يحلها؟
يعالج zkTLS فجوة في TLS التقليدي: إذ يدعم بروتوكول أمان طبقة النقل اتصالات HTTPS للمتصفحات، ويشفّر قناة العميل والخادم ويوثّقها، لكن بعد انتهاء الجلسة يصعب إقناع طرف ثالث بأن الخادم أعاد ذلك المحتوى فعلًا من دون تسليم مواد فك تشفير يمكن إساءة استخدامها أو الاعتماد على لقطات الشاشة. لذلك تواجه العقود صعوبة في استهلاك الحقول التي تظهر بعد تسجيل الدخول.
تستمد مصافحة TLS القياسية مفتاح جلسة متماثلًا: يمكن للمتصفح والخادم كليهما التشفير وفك التشفير. وإذا عرض المستخدم وحده نصًا مشفرًا مع ذلك المفتاح، فلا يمكن للأطراف الأخرى استبعاد احتمال أن المستخدم شفّر نصًا عاديًا مزيفًا ثم فك تشفيره عند الطلب؛ لذا لا يمكن للعميل المنفرد أن يكون شاهدًا موثوقًا. وهذا القيد هو ما يدفع إلى استخدام الموثقين أو الوكلاء أو بيئات TEE.
ما يوفره zkTLS هو دليل على المصدر والسلامة، وليس حكمًا نهائيًا على صحة البيانات التجارية. فإثبات أن حقل رصيد جاء من جلسة TLS لموقع ما لا ينفي إدخال بيانات خاطئًا أو صفحة تم العبث بها—وهو قريب من سرديات تدفقات المعرفة الصفرية في zkOracle وzkCoprocessor، لكنه يقع ضمن نطاق مشكلة مختلف.
كيف يعمل zkTLS؟ من جلسة HTTPS إلى ادعاء قابل للتحقق
على مستوى عام، ينتقل zkTLS من جلسة HTTPS عادية إلى إثبات قابل للتحقق: يفتح المستخدم جلسة مع المصدر؛ ويترك مسار MPC أو Proxy أو TEE أدلة قابلة للتحقق؛ ثم يُنتج إثبات إفصاح انتقائي ويُتحقق منه.
- افتح الجلسة — ابدأ TLS مع النطاق المستهدف؛ ويصبح ربط الشهادة والنطاق جزءًا من البيان اللاحق.
- شارك كشاهد أو فوّض العملية — ينضم موثق إلى المصافحة/فك التشفير عبر MPC، أو يشهد وكيل على اتجاه النص المشفر عبر Proxy، أو تنفذ بيئة TEE الطلب، بحيث لا يستطيع عميل منفرد تزوير النص المشفر المرسل من الخادم بسهولة؛ وتعامل بعض التصاميم ذلك كبروتوكول متعدد الأطراف بدلًا من تدفق عميل منفرد.
- اجلب الحقل المستهدف — ضمن الجلسة، اطلب صفحة الحساب أو API واستقبل الاستجابة المشفرة.
- أنشئ الادعاء — أنشئ إثباتًا، أو تواقيع مسار، على التزامات سجل الجلسة وهوية الخادم وشرط مثل الرصيد > الحد؛ وتحول المسارات المعتمدة على الدوائر قيود سجل الجلسة إلى مخرجات إثبات.
- أرسله للتحقق — يتحقق عقد أو طرف مقابل من الإثبات وجذور الثقة، ثم يقبله أو يرفضه.
الإفصاح الانتقائي طبقة ثانية شائعة: يمكن إثبات أن الرصيد يتجاوز حدًا معينًا من دون الإفصاح عن المبلغ الدقيق، أو استخراج حقل واحد مع إخفاء الباقي. ووفقًا لملاحظة Reclaim حول «zk» في zkTLS، غالبًا ما تكون المعرفة الصفرية للخصوصية تحسينًا إضافيًا؛ أما المتطلب الأساسي فهو إقناع طرف ثالث بأن الاستجابة جاءت فعلًا من المصدر.
الشكل 1. ينتقل zkTLS من جلسة HTTPS للعميل عبر مسار تصديق MPC/Proxy/TEE إلى إثبات إفصاح انتقائي يتحقق منه متحقق أو عقد ذكي.
ينبغي أن تغطي قائمة تحقق المتحقق أربعة عناصر على الأقل: ربط النطاق والشهادة بالمصدر المُدعى؛ وشرطًا متوافقًا مع قواعد الأعمال؛ وتوقيع مسار الإثبات أو جذر الثقة ضمن قائمة السماح؛ وما إذا كانت تغييرات بنية المصدر ستعطّل المحلل. يؤدي تجاوز أي عنصر إلى تحويل «قابل للتحقق» إلى «يبدو كإثبات»، رغم أن الهدف هو إنتاج بيانات قابلة للتحقق للعقود الذكية أو الأطراف المقابلة.
لماذا يُسمى zkTLS؟ وكيف تختلف MPC وProxy وTEE؟
«zkTLS» مصطلح شامل شائع يوحي بضرورة تشغيل إثباتات المعرفة الصفرية وقت المصافحة، لكن هذا ليس صحيحًا دائمًا. غالبًا ما يُستخدم المصطلح على نطاق واسع لبروتوكول هجين، رغم أن ليس كل تنفيذ يطابق ذلك الوصف فعليًا. كثير من التصاميم أقرب إلى Web Proofs أو تصديقات TLS: إذ ينصب التركيز على قابلية التحقق، لا على إلزامية المعرفة الصفرية داخل المصافحة.
| المسار |
الآلية الأساسية |
ملاحظات الثقة والتكلفة |
| MPC / 2PC (موثق بنمط TLSNotary) |
يُحتفظ بمفتاح الجلسة بصورة مشتركة، بحيث لا يستطيع المستخدم ولا الموثق منفردًا تزوير سجل الجلسة |
يعتمد على أمانة الموثق وتوافره؛ وزمن الاستجابة أعلى |
| Proxy |
يشهد وكيل HTTPS على ما إذا كان النص المشفر قد جاء من المتصفح أو الخادم؛ ويثبت المستخدم عبر المعرفة الصفرية فك التشفير من دون كشف المفتاح |
تكلفة تشغيلية أقل؛ ويفترض عدم تواطؤ الوكيل في الكذب بشأن الاتجاه |
| TEE |
تُنفذ الطلبات داخل بيئات تنفيذ موثوقة تشهد على سلامة الاستجابة |
تكلفة تشغيلية منخفضة؛ وتعتمد على مزود الشريحة وجذور تصديق TEE وعزل الأجهزة المقاوم للعبث |
تجيب المسارات الثلاثة عن السؤال نفسه: كيف يمكن إقناع طرف ثالث بأن النص المشفر جاء من الخادم من دون تسليم المفتاح المتماثل بما يتيح إساءة استخدامه؟ يمكن للوكلاء مراقبة اتجاه نقل البيانات من دون رؤية النص العادي. تستخدم تصاميم MPC/2PC، على نمط TLSNotary، مفاتيح مشتركة لمنع التزوير الأحادي؛ وتجمع تصاميم Proxy بين تصديقات الاتجاه وإثبات فك تشفير من جهة المستخدم؛ فيما تستضيف تصاميم TEE الجلسة ضمن عزل عتادي. يمكن أن تضاف معرفة صفرية للخصوصية فوق ذلك لإخفاء الحقول، لكن TEE ومعظم مصافحات MPC ليست معرفة صفرية على مستوى المصافحة.
اختيار المسار هو قرار يتعلق بنموذج التهديد والتكلفة: هل يُقبل موثق أو وكيل أو TEE واحد؛ وهل يجب أن تبقى الجلسات منخفضة زمن الاستجابة؛ وهل يدعم المصدر إصدارات TLS معينة فقط. وتضمن مسارات MPC أيضًا عدم احتفاظ أي عقدة منفردة بالمفتاح الكامل. اقرأ «zk» باعتبارها تسمية للبيانات القابلة للتحقق على الويب، لا تصنيفًا صارمًا لعلم التشفير.
فيمَ يمكن استخدام zkTLS؟
إحدى حالات الاستخدام التقليدية هي إثبات أن حسابًا خارج السلسلة يستوفي حدًا معينًا من دون نشر كشف الحساب كاملًا: مثل الحدود الدنيا للرصيد لأهلية الائتمان، والتحقق من رصيد البنك في سير العمل المالي دون كشف المبلغ الدقيق، وحقول التوظيف أو السمعة من بوابة تتطلب تسجيل الدخول، وتأكيد النشاط خارج السلسلة لقواعد المهام. والنمط المشترك هو وجود البيانات خلف HTTPS من دون API عامة موقعة وجاهزة.
تشمل حالات استخدام الهوية والسمات التحقق من الهوية وبيانات الاعتماد الموثقة، إلى جانب الفئات العمرية ودرجات العضوية أو التقييمات الموجزة: يرى المتحقق نتيجة شرط، لا صفحة كاملة من البيانات الخاصة. وتعرض منتجات ذات بنية بروتوكولية، مثل أوراكل zkTLS من zkPass، البيانات الخاصة القابلة للتحقق على السلسلة؛ لذا ينبغي الفصل بين كيفية تغليف البروتوكول للإثباتات وبين ما يضمنه نمط zkTLS.
وهناك فئة أخرى تتمثل في تدفقات البيانات التي تحافظ على الخصوصية: تحتاج التطبيقات إلى حقول مواقع الويب في التطبيقات على السلسلة من دون كشف النص العادي الكامل للبيانات المستخرجة لكل مراقب. هنا يوفر zkTLS إثبات حقل مع إثبات المصدر؛ لكنه يظل مختلفًا عن تدفقات الأسعار المستمرة وتجميع البيانات من مصادر متعددة المستخدمين في التمويل اللامركزي وسير العمل الأوسع بين الويب والسلسلة.
كيف يختلف zkTLS عن الأوراكل التقليدي؟
تركز الأوراكل التقليدية على كتابة الحقائق خارج السلسلة، مثل الأسعار ونتائج الأحداث، على السلاسل، غالبًا من خلال مجموعات عقد أو تدفقات متعددة المصادر. وهذا الاختلاف جزء من مشكلة الأوراكل: إدخال بيانات موثوقة من خارج السلسلة أو من الويب إلى العقود. يركز zkTLS على إثبات أن حقول جلسة HTTPS جاءت من مصدر محدد، مع الإفصاح الانتقائي اختياريًا. وتحسّن التدفقات التوافر ومقاومة التلاعب، بينما يحسّن zkTLS تحويل جلسة ويب إلى ادعاء قابل للتحقق.
عند مقارنة بنية التدفقات وافتراضات الثقة وأنماط الفشل، استخدم zkTLS مقابل الأوراكل التقليدي. والقاعدة المختصرة: لا تزال تدفقات السوق العامة والمستمرة مناسبة لشبكات الأوراكل الناضجة؛ أما حقول ما بعد تسجيل الدخول الخاصة التي تتطلب أقل قدر من الإفصاح، فتناسب zkTLS أكثر، بينما تتعامل بعض الأنظمة أيضًا مع قابلية نقل البيانات باعتبارها هدف تصميم منفصلًا—يمكن الجمع بين النهجين، لكن لا يحل أي منهما محل الآخر.
ما مزايا ومخاطر استخدام zkTLS أو الاعتماد عليه للبيانات الحساسة؟
تشمل المزايا تصدير حقول قابلة للتحقق كلما كان المستخدم لا يزال قادرًا على إكمال HTTPS مع المصدر، من دون انتظار API مخصصة للتدفقات؛ ويتيح الإفصاح الانتقائي للعقود التحقق من حقيقة من دون كشف السجل الخاص كاملًا؛ كما يمكن للعقود التحقق من الادعاءات برمجيًا.
والمخاطر ملموسة بالقدر نفسه. تشكل أمانة وتوافر الموثقين أو الوكلاء أو بيئات TEE جذور ثقة: فقد يؤدي التواطؤ أو الرفض أو التوقف إلى قبول خاطئ أو إخفاقات. وتحمل التصاميم المعتمدة على TEE أيضًا مخاطر أمنية مرتبطة بمصنّع العتاد أو جذر التصديق. أما أمانة المصدر فهي خارج نطاق البروتوكول: إذ قد تظل الصفحات الخاطئة تنتج إثباتات صالحة شكليًا. كما أن تغييرات مسار الحقل تعطل الشروط؛ ولا تغطي بعض حزم الموثقين سوى إصدارات TLS محددة.
ينبغي للجهات المعتمدة أيضًا موازنة تكلفة إنشاء الإثبات وزمن استجابة الجلسة ومخاطر الاحتفاظ بسجلات الجلسات. يحسّن zkTLS إثبات المصدر القابل للتحقق؛ لكنه لا يحوّل صفحات الويب العشوائية إلى مصادر حقيقة غير خاضعة للتدقيق.
الخلاصة
يرتقي zkTLS بجلسات HTTPS اليومية إلى ادعاءات قابلة للتحقق وقابلة للإفصاح بالحد الأدنى، بحيث تتمكن العقود من التحقق من الخادم المرتبط بنطاق الذي جاء منه الحقل، بدلًا من الثقة بلقطات الشاشة. ولا تضمن «zk» استخدام المعرفة الصفرية وقت المصافحة؛ إذ تحقق MPC وProxy وTEE السلامة وفق افتراضات ثقة مختلفة.
قبل الإطلاق، تقبّل أن العميل المنفرد الذي يملك المفتاح المتماثل يمكنه ترتيب عرض لجلسة مزيفة؛ وأن قوائم تحقق المتحققين يجب أن تغطي النطاق/الشهادة والشرط وجذور الثقة؛ وأن إثبات المصدر لا يعني صحة المحتوى؛ وأن الفرق بين الأوراكل التقليدي وzkTLS يقسم بين التدفقات المستمرة وإثباتات حقول الصفحات الخاصة. اختر المسار وفق نموذج التهديد، ودوّن مخاطر المصدر والتصديق ضمن ذلك النموذج.
الأسئلة الشائعة
ما هو zkTLS؟
zkTLS هو مجموعة من التصاميم المبنية على TLS/HTTPS القياسي، وتنتج ادعاءات يمكن لطرف ثالث التحقق منها: أي أن بيانات محددة جاءت من خادم مرتبط بنطاق وشهادة، مع إمكانية الإفصاح عن نتيجة شرط فقط. وهو يربط حقول ويب2 الخاصة بالتحقق عبر العقود من دون استبدال HTTPS.
كيف يحوّل zkTLS جلسة HTTPS إلى ادعاء قابل للتحقق؟
يفتح العميل والمصدر جلسة؛ ويشارك موثق MPC أو Proxy أو TEE كشاهد أو ينفذ التفويض، بحيث لا يستطيع عميل منفرد تزوير النص المشفر للخادم؛ ثم يُنشأ إثبات إفصاح انتقائي؛ ويتحقق المتحقق من ربط النطاق والشرط وجذور الثقة قبل القبول أو الرفض.
هل يجب أن يستخدم zkTLS إثباتات المعرفة الصفرية في مصافحة TLS؟
لا. تستخدم كثير من الأنظمة التي تحمل تسمية zkTLS، MPC أو Proxy أو TEE لتحقيق السلامة؛ وغالبًا ما تظهر إثباتات المعرفة الصفرية لاحقًا للإفصاح الانتقائي أو لإثباتات فك التشفير بنمط Proxy. وقد لا تشغل المصافحة نفسها دائرة معرفة صفرية مطلقًا—فـ«zk» تسمية شائعة.
كيف يختلف zkTLS عن الأوراكل التقليدي؟
تغذي الأوراكل التقليدية العقود باستمرار بالحقائق خارج السلسلة مع أهداف تتعلق بتعدد المصادر والتوافر؛ بينما يثبت zkTLS المصدر، والشروط الاختيارية، لحقول HTTPS على مستوى الجلسة. تدفقات البيانات العامة وحقول صفحات تسجيل الدخول الخاصة مشكلتان مختلفتان؛ راجع موضوع المقارنة—ويمكن الجمع بين النهجين.
ما المخاطر الرئيسية عند الاعتماد على zkTLS؟
تشمل المخاطر الرئيسية الموثقين أو الوكلاء أو بيئات TEE المخترقة أو غير المتاحة؛ والمصادر التي تقدم بيانات خاطئة مع بقاء الإثباتات صالحة شكليًا؛ وتغيرات بنية الصفحة التي تعطل المحللات؛ وحدود إصدارات TLS. ويزيد تجاوز التحقق من ربط النطاق وجذر الثقة من خطر القبول الخاطئ.
