إعادة توجيه العنوان الأصلي ‘كيف يمكننا جعل استخدام بيانات web2 في web3 فعلياً خاصة وقابلة للتحقق؟’

الكثير من الناس الذين يدعون أن الويب 3 هو الإنترنت الجديد يعرفونه بعبارة “قراءة، كتابة، ملكية”. أجزاء “القراءة” و”الكتابة” واضحة، ولكن عندما يتعلق الأمر بـ “الملكية” من حيث البيانات، فإننا نملك شيئًا بالكاد اليوم.

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

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

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

• لماذا يجب عليّ مشاركة كامل كشف حسابي المصرفي عندما يكفي أن يتم تأكيد مستوى دخل محدد؟

• لماذا يجب عليّ تقديم الحجز الدقيق للفندق بدلاً من إثبات أنني قمت بحجز فندق في هذا البلد فقط؟

• لماذا يجب عليّ تقديم تفاصيل جواز سفري الكاملة عندما كل ما يحتاجون إليه هو التحقق من إقامتي الدائمة في بلدي الحالي؟

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

1. Web3 لن تنجح من دون بيانات web2.

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

في عالم Ethereum، يكاد هذا الدور يكون شبه احتكاراً من قبل @chainlink مع شبكات Oracle الخاصة بهم لضمان عدم اعتمادنا على عقدة واحدة. لذلك ، نحتاج حقا إلى بيانات web2 لمزيد من حالات الاستخدام بخلاف مجرد معرفة سعر أصول معينة.

ومع ذلك ، هذا ينطبق فقط على البيانات العامة. ماذا لو أردت ربط حسابي المصرفي أو حساب Telegram بشكل آمن ومشاركة معلومات حساسة غير متاحة للجمهور ولكنها خاصة بي؟

الفكرة الأولى هي: كيف يمكننا جلب هذه البيانات إلى سلسلة كتلية مع دليل على أن البيانات الخاصة آمنة؟

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

يسمى البروتوكول الذي يؤمن الاتصال عبر شبكة الكمبيوتر TLS: أمان طبقة النقل. حتى لو لم تكن قد سمعت به ، فأنت تستخدمه يوميا. على سبيل المثال ، أثناء قراءة هذه المقالة ، سترى “https://“ في شريط عنوان المتصفح.

إذا حاولت الوصول إلى موقع الويب باستخدام اتصال “http://“ (بدون “s”) ، فسيحذرك متصفحك من أن الاتصال غير آمن. يشير الحرف “s” الموجود في الرابط إلى TLS ، والذي يؤمن اتصالك ويضمن الخصوصية ويمنع أي شخص من سرقة البيانات التي ترسلها.

2. الاتصال آمن بالفعل، هل يمكننا فقط نقله واستخدامه في الويب3؟

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

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

أحد الطرق لمشكلة التحقق هو نسخة محسنة من TLS تسمى zkTLS.

آلية عمل zkTLS مشابهة لبروتوكول TLS ولكنها تختلف قليلاً، إليك كيف يعمل:

• تزور موقعًا عبر اتصال TLS آمن وترسل الطلب المطلوب.

• يولد zkTLS دليلاً zk يتحقق من البيانات مع الكشف فقط عن التفاصيل الخاصة التي يرغب المستخدم في إثباتها، مما يحافظ على سرية كل شيء آخر.

• يتم استخدام البرهان zk المولد بعد ذلك من قبل التطبيقات الأخرى لتأكيد والتحقق من أن المعلومات المقدمة صحيحة.

عندما أقول zkTLS ، فأنا أشير إلى المشاريع التي تستخدم zkTLS ، ولكن هناك نهج مختلفة لتحقق صحة البيانات باستخدام حلول مختلفة:

1. TEE (بيئة التنفيذ الموثوقة)
2. MPC (Multi-Party Computation)
3. وكيل

ومن المثير للاهتمام أن كل نهج يقدم مجموعته الخاصة من حالات الاستخدام الفريدة. إذن ، كيف تختلف؟

3. لماذا لا يوجد معيار واحد لـ zkTLS؟ كيف تختلف؟

zkTLS ليست تقنية واحدة لأن التحقق من البيانات الشخصية على الويب دون تعريضها يمكن أن يتم من عدة زوايا، كل منها له تضحياته الخاصة. الفكرة الأساسية هي توسيع TLS مع الأدلة، ولكن كيفية إنشاء وتحقق تلك الأدلة تعتمد على الآلية الأساسية.

كما ذكرت سابقًا، تعتمد ثلاثة نهج رئيسية على استخدام TEE-TLS، MPC-TLS، أو Proxy-TLS.

تعتمد TEE على أجهزة متخصصة، مثل Intel SGX أو AWS Nitro Enclaves، لإنشاء “صندوق أسود” آمن حيث يمكن معالجة البيانات وإنشاء البراهين. يضمن الجهاز بقاء البيانات خاصة وأن الحسابات مقاومة للعبث.

في إعداد zkTLS القائم على TEE، يقوم TEE بتشغيل البروتوكول، مثبتًا تنفيذ جلسة TLS ومحتواها. المحقق هو الـ TEE نفسه، لذلك تعتمد الثقة على مصنع TEE ومقاومته للهجمات. يعتمد هذا النهج على كفاءة منخفضة للحوسبة والشبكة.

ومع ذلك، فإن لديه عيب كبير: عليك أن تثق في الشركة المصنعة للأجهزة، ويمكن أن تكسر الثغرات في TEEs (مثل الهجمات جانبية) النظام بأكمله.

يعد Proxy-TLS و MPC-TLS أكثر الأساليب المعتمدة على نطاق واسع نظرا لنطاقها الأوسع من حالات الاستخدام. مشاريع مثل@OpacityNetworkو @reclaimprotocol, التي تم بناؤها على @eigenlayer, استفد من هذه النماذج لضمان أمان البيانات والخصوصية بالإضافة إلى طبقة إضافية من الأمان الاقتصادي.

دعونا نرى مدى أمان هذه الحلول، والحالات الاستخدامية التي تمكن بروتوكولات zkTLS، وما هو متاح بالفعل اليوم.

4. ما الذي يميز MPC-TLS وشبكة Opacity؟

خلال مصافحة TLS (حيث يتفق العميل والخادم على كيفية التواصل بشكل آمن من خلال مشاركة مفاتيح التشفير)، يظل دور الموقع على حاله، ولكن عملية المتصفح تفعل شيئًا مختلفًا.

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

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

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

1. التحقق السلسلة من معرفات حسابات ويب2
2. نظام الالتزام
3. كشف المخطط
4. عينات شبكة MPC عشوائية
5. سجل يمكن التحقق من محاولات

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

يمكنك رؤية كيف يعمل التعتيم بالتفصيل أدناه:

يعمل خوادم العتامة داخل بيئة تشغيل موثوقة (TEE)، مما يجعل التواطؤ من المستحيل تقريبًا إذا كان TEE آمنًا. بالإضافة إلى TEEs، تستخدم العتامة أيضًا طبقة Eigenlayer للاستفادة من AVS، مما يتطلب من الخوادم إعادة رهان 32 stETH، مع خفض فوري للمخالفات، مما يتجنب التأخير المرتبط بفترات التبريد.

يمكنك أن ترى أن التعتيم يستخدم كلا من MPC و TEE ، ولكن نظرا لاستخدام MPC ل zkTLS بينما يتم استخدام TEE بشكل أساسي لأمان العقدة ، فإنه لا يزال يسمى MPC-TLS.

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

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

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

الفريق من @earnos_io تقوم بتطوير منصة حيث يمكن للعلامات التجارية مكافأة المستخدمين على المشاركة أو إكمال المهمة. يستخدم EarnOS تقنية Opacity لإثبات السمات عبر التطبيقات الشائعة دون الكشف عن المعلومات الشخصية ، مما يسمح للعلامات التجارية باستهداف الجماهير بينما يحافظ المستخدمون على الخصوصية ويكسبون المكافآت.

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

يمكن حتى دمج التعتيم مع عوامل الذكاء الاصطناعي ، مما يوفر المزيد من إمكانية التحقق والشفافية في مجال يواجه حاليا تحديات كبيرة. تم دمج zkTLS مؤخرا في @elizaOS, مما يسمح بالتفاعلات الذكية التي يمكن التحقق منها دون فقدان الخصوصية.

ومع ذلك ، فإن TEE-TLS و MPC-TLS هما نوعان مختلفان فقط من zkTLS ، وهناك أيضا شكل ثالث يسمى Proxy-TLS ، مع كون شبكة Reclaim هي التمثيل الأكثر شهرة لهذا النموذج. إذن ، كيف يختلف من حيث التكنولوجيا عن النوعين الآخرين ، وما هي حالات الاستخدام التي يمكن تمكينها بواسطة Proxy-TLS؟

ما الذي يميز بروكسي-TLS وبروتوكول الاسترداد؟

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

• يرسل المتصفح طلبات إلى الموقع عبر وكيل، الذي يتعامل أيضا مع ردود الموقع على الطلبات.

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

• يقوم المتصفح بعد ذلك بإنشاء دليل zk الذي يؤكد أنه يمكنه تشفير هذه البيانات باستخدام مفتاح مشترك دون الكشف عن المفتاح وعرض النتيجة.

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

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

معظم الخوادم لا تقيد الوصول بناءً على عناوين IP المتنوعة، مما يجعل هذه الطريقة قابلة للتطبيق على نطاق واسع تمامًا.

يستخدم Reclaim Protocol Proxy-TLS للتحقق الفعال من البيانات ويستخدم وكلاء لتجاوز جدران حماية Web2 التي تمنع حظر الوكيل على نطاق واسع.

ها هي كيف تعمل:

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

يستخدم Reclaim AVS التابعة لشركة Eigen لتقسيم التحقق من البيانات. يمكن لمشغلي EigenLayer أن يعملوا كشهود، ولكن سيحتاجون إلى نشر AVS الخاصة بهم لتحديد منطق التوثيق لخدمتهم.

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

نظام الاسترداد هو موطن لأكثر من 20 مشروعًا، ولكن أود التركيز على 4 منها في أسواق الأموال، وهوية رقمية، والمستهلك، وقطاع التوظيف.

@3janexyzهو أول سوق للأموال المستندة إلى الائتمان على Base، الذي يقدم خطوط ائتمان مؤمنة لمستخدمي العملات المشفرة من خلال تقييم قدرتهم على الائتمان وتدفقات نقدية مستقبلية، باستخدام بيانات مالية على السلسلة وخارجها.

يستخدم 3Jane نموذج الوكيل لإعادة استيلاء للتحقق من بيانات الائتمان من VantageScore و Cred و Coinbase و Plaid، مما يضمن خصوصية هذه البيانات.

استخدام آخر لدرجات الائتمان مع zkTLS هو من خلال @zkme_الميزة ‘s، zkCreditScore. يستخدم بروتوكول Reclaim للحصول على درجة الائتمان الأمريكية الخاصة بك بشكل آمن باستخدام zkTLS. يتيح هذا لـ zkMe التحقق من درجة ائتمان المستخدم وإنشاء رموز فريدة (SBTs) لتخزين هذه البيانات.

هل يمكن أن تكون هناك حالات استخدام أخرى بخلاف درجات الائتمان؟ بالطبع، هناك.

نستطيع أن نأخذ @zkp2pعلى سبيل المثال، وهو سوق سلع استهلاكية يستفيد من Reclaim للتحقق من بيانات مستخدمي Ticketmaster وكذلك التحقق من مدفوعات المستخدمين.

في نفس الوقت، @bondexapp، وهي واحدة من أكثر لوحات الوظائف شيوعا في مجال العملات المشفرة ، وتستخدم Reclaim للحصول على دليل على عمل الملفات الشخصية ، والتحقق من أن البيانات حقيقية وخاصة ويمكن التحقق منها.

بالنظر إلى حالات الاستخدام الممكنة عبر zkTLS ، فإن القدرة على التحقق من نصوص TLS على السلسلة تفتح بالفعل العديد من الوظائف الجديدة ، مما يسمح للمستخدمين بالتحكم في بياناتهم الخاصة دون الحاجة إلى إذن من الشركات الكبيرة.

الأهم من ذلك، تم تصميم zkTLS لضمان عدم استخدام بياناتك الشخصية ضدك. إذًا، إلى أين يتجه هذا؟

6. هل zkTLS هنا للبقاء؟

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

@Tim_Roughgarden في A16Z Crypto Podcast ، سلط الضوء على أن أدلة ZK ، المقترحة في عام 1985 ، اكتسبت شعبية فقط مع تطبيقات blockchain ، وذلك بفضل مئات المطورين الذين يعملون على تقليل حجم الإثبات والتكاليف.

والآن، تجد استخدامات لمساهمات صناعة البلوكشين في مجالات أخرى بعيدًا عن عالم العملات الرقمية نفسها.

أتوقع وقوع قصة مماثلة مع zkTLS، بدءًا من التنفيذ في Web3 ومن ثم التوسع بعد ذلك، لأنه، كما ذكرت سابقًا، حاليًا، نحن “نقرأ” و”نكتب”، لكننا نحن بالكاد محميون وبالكاد “نملك” حتى بياناتنا الخاصة.

تنصل:

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