أحب أن يتم إجراء المزيد من الأبحاث في الخصوصية على مستوى RPC.
إنه جزء غير مدروس وغير محظور من خصوصية Ethereum ويستحق الحل.
لسوء الحظ ، فإن تدوير RPCs ليس هذا الحل ، على الأقل بالشكل الموضح هنا. إليكم السبب 🧵
المشكلة 1: يجب ألا يكون أي مزود قادرا على ربط عنوان Ethereum الخاص بك بعنوان IP الخاص بك.
المشكلة 2: يجب ألا يكون أي مزود قادرا على ربط اثنين من عناوين Ethereum الخاصة بك ببعضهما البعض.
مهم بشكل خاص في سياق العناوين الخفية.
الحل الأول المقترح لا يحل أيا من المشكلتين.
في الواقع ، إنه يجعل المشكلة 1 أسوأ: بدلا من مزود واحد يعرف عناوين IP و Ethereum الخاصة بك ، يعرفهما الآن العديد من هؤلاء المزودين على حد سواء.
الحل الثاني يحل المشكلة 1 عن طريق إدخال برنامج وسيط في TEE. إنه في الأساس وكيل أعمى ، يتم توفير العمى من أجله بواسطة TEE.
لكن المشكلة 2 لا تزال دون حل: لا يزال بإمكان مقدمي الخدمة ربط عناوين Ethereum الخاصة بك ببعضهم البعض.
TEEs ليست مضادة للرصاص. ولكن حتى إذا افترضنا أنها تعمل على النحو المنشود ، فلا يزال العميل بحاجة إلى التحقق من أن البرامج الوسيطة التي يتحدثون إليها تعمل بالفعل في TEE على الإطلاق. خلاف ذلك ، لا يمكن للعميل (المحفظة) التأكد من أن البرنامج الوسيط لا يسجل كل شيء بالفعل.
يمكن للعميل التحقق من ذلك عن طريق إجراء رقصة تصديق حمل العمل. إنه ممكن ، لكنه معقد للتنفيذ.
لم أر تنفيذا حقيقيا لهذا في الممارسة العملية ، وليس من الواضح بالنسبة لي ما إذا كان ذلك سيكون أسهل في التنفيذ من مجرد دمج mixnet فعلي.
يجب أن يكون الوكيل أعمى عما يمر به. يحل التشفير هذا دون الحاجة إلى افتراضات ثقة TEE.
تعمل شبكات المزيج مثل Tor / Nym / HOPR بهذه الطريقة: قم بتشفير الحمولة في طبقات متعددة من التشفير ، حيث تقشر كل قفزة طبقة واحدة من التشفير من البصل.
لماذا لا يتم استخدام mixnets اليوم؟
- لا يطلب المستخدمون الخصوصية على مستوى RPC من مطوري محفظتهم. Walletbeat يصلح هذا.
- توقعات تجربة مستخدم RPCs < 100 مللي ثانية. تضيف Mixnets/البرامج الوسيطة زمن انتقال.
- يتطلب التكامل في محافظ المتصفح إعادة تنفيذ TLS في JS لتشفير القفزة الأخيرة.
كما أن Mixnets وحدها لا تحل المشكلة 2.
تظل المشكلة أن تدوير RPCs بسذاجة (مزود عشوائي لكل طلب) هو في الواقع أسوأ بالنسبة للخصوصية: فهذا يعني أن العديد من مقدمي الخدمة يحصلون على عرض للعديد من عناوينك بمرور الوقت.
حل أفضل: بالنسبة إلى RPC حول "العنوان" ، أرسله دائما إلى الموفر #'hash(address) modulo num_providers'.
بمعنى آخر، تنتقل الاستعلامات حول نفس العنوان إلى نفس موفر RPC.
هذا يضمن عدم معرفة أي مزود لمجموعة العناوين الكاملة الخاصة بك.
من الأفضل أيضا أن يكون لديك مزودون أكثر مما لديك عناوين. بهذه الطريقة ، يتعلم كل مزود إما أحد عناوينك أو لا شيء ؛ لا تضاعف أبدا.
لكن الحل الحقيقي؟
- قم بتشغيل العقدة الخاصة بك!
- اطلب من مطور محفظتك البدء في الاهتمام بالخصوصية على مستوى RPC.
الأشياء التي لم أقم بتغطيتها ولكنها مهمة أيضا:
- هجمات ارتباط توقيت RPC.
- المحافظ التي تبحث عن رصيد عناوين متعددة في RPC واحد.
- الطلبات غير الإيثريوم التي تسرب بيانات مماثلة. محافظ اليوم مليئة ب هؤلاء. اسألني كيف أعرف.
- L2s مع نقاط نهاية مركزية. (لول)
حتى لو بدا هذا الموضوع ناقدا لعمل @jimouris ، فإنني أريد أن أؤكد أنه لا يقصد به أن يكون غمسا.
أنا أحترم بشدة أي شخص يتقدم بالفعل لمعالجة هذه المشكلة. هذا غير مدروس ويحتاج إلى مزيد من الاهتمام ، لذلك من المشجع رؤية الأشخاص يعملون عليه.
3.09 ألف
25
المحتوى الوارد في هذه الصفحة مُقدَّم من أطراف ثالثة. وما لم يُذكَر خلاف ذلك، فإن OKX ليست مُؤلِّفة المقالة (المقالات) المذكورة ولا تُطالِب بأي حقوق نشر وتأليف للمواد. المحتوى مٌقدَّم لأغراض إعلامية ولا يُمثِّل آراء OKX، وليس الغرض منه أن يكون تأييدًا من أي نوع، ولا يجب اعتباره مشورة استثمارية أو التماسًا لشراء الأصول الرقمية أو بيعها. إلى الحد الذي يُستخدَم فيه الذكاء الاصطناعي التوليدي لتقديم مُلخصَّات أو معلومات أخرى، قد يكون هذا المحتوى الناتج عن الذكاء الاصطناعي غير دقيق أو غير مُتسِق. من فضلك اقرأ المقالة ذات الصِلة بهذا الشأن لمزيدٍ من التفاصيل والمعلومات. OKX ليست مسؤولة عن المحتوى الوارد في مواقع الأطراف الثالثة. والاحتفاظ بالأصول الرقمية، بما في ذلك العملات المستقرة ورموز NFT، فيه درجة عالية من المخاطر وهو عُرضة للتقلُّب الشديد. وعليك التفكير جيِّدًا فيما إذا كان تداوُل الأصول الرقمية أو الاحتفاظ بها مناسبًا لك في ظل ظروفك المالية.