حزمة الخصوصية في إيثيريوم: القراءات الخاصة، والشبكات، والتسريب الخفي

حديث قدمه آندي جوزمان، قائد فريق رعاة الخصوصية في إيثيريوم (PSE) في مؤسسة إيثيريوم، في مؤتمر إيث بولدر لعام 2026. يكشف عن نقطة عمياء رئيسية في الخصوصية في إيثيريوم: حتى المستخدمين الذين لا يقومون أبدًا بتوقيع معاملة يسربون بيانات سلوكية مفصلة من خلال الاستعلامات اليومية. يقدم حزمة الخصوصية في إيثيريوم، والتي تغطي القراءات الخاصة (PIR)، وخصوصية حركة المرور (التوجيه البصلي وشبكات الخلط)، وأعمال الأداء مثل الأشجار الثنائية الموحدة والحالة القابلة للتحقق باستخدام إثبات المعرفة الصفرية (ZK).

هذا النص هو نسخة يسهل الوصول إليها من النص الأصلي للفيديو (يفتح في علامة تبويب جديدة) الذي نشره إيث بولدر. تم تعديله قليلاً لتسهيل القراءة.

رسالة مزود RPC الخيالية (0:12)

مرحبًا بالجميع، أنا آندي، وأردت تقديم موضوع لا تتم مناقشته غالبًا في نظام إيثيريوم البيئي وهو في غاية الأهمية. كما لاحظتم ربما من الشريحة والمقدمة، فهو يتعلق بالخصوصية، وكيف أننا غير محميين بشكل كافٍ دون أن نلاحظ ذلك.

دعوني أبدأ برسالة كتبها شخص ما إليكم.

"عزيزي المستخدم القيم، شكرًا لك على الاستعلامات البالغ عددها 847 التي أجريتها هذا الشهر. لقد استمتعنا حقًا بالتعرف عليك. نحن نعلم أنك تحتفظ بـ ETH عبر ثلاث محافظ مختلفة. نعلم أنك تحققت من سعر ETH 94 مرة يوم الثلاثاء الماضي. لقد كان يومًا قاسيًا جدًا للجميع، لذا لا نلومك. لقد تحققت أيضًا من سعر BTC، وهو أمر مثير للاهتمام، لأنك لا تمتلك أي بيتكوين. هل تفكر في التنويع؟ سيبقى ذلك بيننا، وبالطبع شركائنا في التحليلات. أنت تراقب أيضًا مجمعين في يونيسواب عن كثب، وتحققت من عامل الصحة الخاص بك في آفي 14 مرة الأسبوع الماضي. قد ترغب في الاسترخاء، أو مجرد إضافة بعض ضمانات. يوم الخميس تحققت منه ثلاث مرات في غضون 12 دقيقة، وكنت قلقًا للغاية. لقد نظرت إلى أربعة أسماء ENS مختلفة، فإما أنك تبدأ مشروعًا جديدًا أو تعاني من أزمة هوية. وأنت دائمًا ما تكون هادئًا بين الساعة 11 مساءً و7 صباحًا بتوقيت الجبل."

كيف تسرب البيانات دون توقيع معاملات (1:34)

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

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

الكتابات الخاصة مقابل القراءات الخاصة (2:07)

إذن ما الذي يحدث حقًا الآن في عالم الخصوصية؟ أرى أننا نركز كثيرًا على الخصوصية على السلسلة، أو ما نسميه في PSE الكتابات الخاصة: جميع الإجراءات التي تقوم بها على السلسلة. وهذا منطقي، أليس كذلك؟ يتم تسجيل هذه الإجراءات إلى الأبد ونقلها حول العالم، لذا من المنطقي ألا تسرب عنوانك مع إجراء معين. نركز أيضًا بشكل كبير على الأدوات: مصادر البيانات، والإثباتات، ولغات النطاق المخصصة (DSLs)، واللغات التي يمكننا استخدامها لمنح المطورين المزيد من الأدوات للتعبير وبناء تطبيقات أقوى تتمتع بمزيد من الخصوصية على السلسلة.

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

للدخول في تفاصيل تقنية أكثر قليلاً: جميع مكالمات RPC، مثل eth_getBalance و eth_call و eth_getLogs، هي طلبات بنص عادي تذهب إلى مزودي RPC ويتم ربطها بعنوان IP الخاص بك.

لماذا يزيد النشاط الأكبر من خطر التصنيف (3:20)

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

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

لذا كلما كان هناك هوس بالتمويل اللامركزي (DeFi) أو جنون الرموز غير القابلة للاستبدال (NFT)، يصبح الناس أكثر إهمالًا. يتم التخلي عن أمن العمليات (OpSec) بالطبع، ويصبح من الأسهل بكثير كشف هوية الأشخاص بناءً على أنماط النشاط التي يقع فيها معظم الناس.

تقديم حزمة الخصوصية في إيثيريوم (4:43)

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

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

طبقة تلو الأخرى: أين تسرب البيانات (5:41)

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

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

ثم لديك البوابات: أجهزة RPC، والوكلاء، والمُرحّلون. أنت تسرب المزيد من بيانات وصفية مرة أخرى. ثم ما يتخيله الناس كعنصر على السلسلة، وهو كلما تم الاستعلام عن الأشياء على جهاز إيثيريوم الظاهري (EVM)، مثل الحالة أو أنماط التنفيذ. على سبيل المثال، الاستعلام عن رصيد شيء ما، أو حالة عقد ذكي. وأخيرًا إجماع، حيث يوجد جميع المُدَقِّقين. اعتمادًا على ما إذا كنت تكتب على السلسلة أو تقرأ على السلسلة، فقد تتطرق أيضًا إلى مجمع الذاكرة.

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

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

القراءات الخاصة والشبكات الخاصة (8:24)

حسنًا، لدينا حزمة الخصوصية في إيثيريوم. أين يجب أن نركز؟ في هذا العرض التقديمي أريد التحدث عن هذين المجالين. القراءات الخاصة: كلما وصلت إلى حالة من على السلسلة، فإنك تتطرق إلى جميع هذه الطبقات، من التطبيق، لنفترض أنني أريد الاستعلام عن سعر ETH، إلى المحفظة، إلى البوابات، إلى عقدة تقوم بتشغيل إيثيريوم وجهاز EVM، ثم العودة. أساسًا مزود RPC أو مؤشر. والشبكات الخاصة، وهي جميع الإجراءات التي تحدث على طبقة الشبكات. هذا ما نريد تقويته.

ثلاث ركائز: البيانات، وحركة المرور، والأداء (9:05)

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

إخفاء البيانات: من الوكلاء إلى PIR (9:39)

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

هناك مستويات مختلفة من التقنيات. الأول هو لا شيء: أنت فقط تسرب كل شيء. كلما قمت بتوصيل محفظتك، فإنك تربط عنوان IP الخاص بك بالعقد الذي تستعلم عنه، بـ eth_getBalance محدد لعنوان محدد، وهذا كل شيء. حتى لو كنت تستخدم بروتوكول خصوصية، لنفترض Tornado Cash، وتريد الاستعلام عن حالة شجرة ميركل، فإما أن تضطر إلى تنزيل الشجرة بأكملها، وهو أمر غير فعال للغاية، أو تسرب المسار والأوراق التي تستعلم عنها، مما يقلل من مجموعة المجهولية الخاصة بك. لذا حتى استخدام بروتوكول خصوصية قوي مثل Tornado Cash ليس كافيًا إذا لم تقم بحماية شبكاتك وأنماط وصولك إلى البيانات.

المستوى التالي هو نوع من الوكلاء أو المُرحّلين: الكثير من الأجهزة التي لا تعرف من أين يأتي الطلب وتسترجع البيانات في النهاية. هذا ليس عمليًا جدًا، وليس منزوع الثقة تمامًا.

ثم لديك بيئات التنفيذ الموثوقة (TEEs)، وهي خطوة إلى الأمام، وهنا تقدم بعض الفرق والشركات خدمات. أعتقد أن هذه خطوة جيدة إلى الأمام ولكنها ليست كافية، مرة أخرى لأن تكلفة مهاجمة وإفساد TEEs تنخفض كثيرًا. بالنسبة لبعض حالات الاستخدام الحرجة، هذا ليس كافيًا؛ بالنسبة للعديد من الحالات اليومية قد يكون كذلك.

هناك فرق أخرى تعمل على OMAPs، أنماط الوصول إلى الخرائط الغافلة، و ORAM، ذاكرة الوصول العشوائي الغافلة. هذه تقنيات مشابهة تحاول إخفاء أجزاء مجموعة البيانات التي تحاول الوصول إليها. بدلاً من قول "أريد الرصيد من عنوان ETH هذا"، فإنك تصل بشكل عشوائي إلى أشياء مختلفة، لذلك لا يعرف الخادم.

وأود أن أجادل بأن الهدف النهائي لهذه سيكون PIR، استرجاع المعلومات الخاصة، مما يعني أن الخادم لا يعرف ما تستعلم عنه ولا يتعلم أي شيء عنه.

شرح استرجاع المعلومات الخاصة (12:03)

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

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

بنية PIR متعددة الوكلاء (12:48)

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

ماذا لو كان لدينا خدمة تقوم بتشغيل هذه البنية متعددة الوكلاء، واعتمادًا على نوع الاستعلامات ومكان وجودها في حالة إيثيريوم، فإنها تقوم بتشغيل مخطط أو آخر؟ هذا يقربنا بالفعل من شيء ممكن، وقادر على الإنتاج، ويمكن تقديمه للنظام البيئي. سيتطلب هذا شيئًا مثل واجهة برمجة تطبيقات (API) موحدة، بحيث لا يحتاج المطورون للمحافظ والمؤشرات والمستخدمين وتطبيقات لامركزية (dapps) إلى القلق بشأن المخطط المستخدم وكيفية استدعائه. لديك فقط API القياسي، وشخص آخر يقلق بشأن تفاصيل التنفيذ.

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

إليك بعض الأرقام حول مخططات PIR المختلفة: الإنتاجية، وعبء الاتصال، وما إلى ذلك. الأمر صعب، لأن التطبيقات المختلفة لها أنماط وصول مختلفة. يصل البعض إلى الكثير من الإيصالات، ويريد البعض الوصول إلى المزيد من الحالة، مثل Rotki، ويصل البعض إلى المزيد من معاملات، مثل Helios. لا يوجد حل سحري، ومن المرجح أن تكون البنية المختلطة مفيدة. نقوم أيضًا بتنظيم المعرفة، لذا إذا كان هذا يثير اهتمامك، فيمكننا مشاركته. وهنا فقط بعض الفرق العاملة في هذه المجالات. سامحني إذا كنت جزءًا من فريق ولم أقم بتضمينك؛ إذا رأى شخص ما التسجيل وكان مفقودًا، فيرجى إبلاغي ويمكنني البدء في إضافتك.

إخفاء حركة المرور: التوجيه البصلي و Tor (15:22)

لقد غطينا البيانات. الجانب الكبير الآخر هو حركة المرور. كيف نخفي حركة المرور، وما الذي نريد إخفاءه؟ بعبارات بسيطة للغاية، نريد إخفاء عناوين IP الخاصة بالعميل والخادم عن بعضهما البعض، وعن بقية العالم الذي قد يتجسس على حركة المرور. لدينا تقنيات مختلفة: خدمات البصل، وشبكات الخلط، والشبكات الخاصة الافتراضية (VPNs)، وشبكات DC-nets، وقد تكون هناك تصنيفات أخرى. سأتحدث فقط عن أول اثنتين.

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

الخلاصة هي: ماذا لو أمكن توجيه جميع حركة مرور النظام البيئي لإيثيريوم عبر شبكة Tor، إذا جاز التعبير؟ هناك خيارات أخرى أيضًا. سنساعد في حماية عنوان IP الخاص بالمرسل: لن يتم تسريب هاتفك أو حاسوبك المحمول عند إرسال معاملات أو طلب معلومات. وبالطبع سنحمي أيضًا المتلقي، الخادم. تخيل أنه في إيران أو الصين أو كوريا الشمالية أو فنزويلا، يحاول شخص ما استضافة بروتوكول تمويل لامركزي (DeFi) أو خدمة ويتم فرض رقابة عليها من قبل بلده. هذا خيار يمكن أن يحمي حياتهم. إنه يتجاوز الرقابة ويخفي أيضًا حركة المرور عن مزودي خدمة الإنترنت (ISPs)، والذين نعلم جميعًا أنهم مراقبون من قبل وكالات الاستخبارات التي تتجسس على كل شيء.

الهدف هو الحصول على بديل جاهز للاستخدام: حزمة تطوير برمجيات (SDK)، بحيث لا يحتاج مطورو المحافظ وتطبيقات لامركزية (dapps) ومزودو البنية التحتية إلى القلق بشأن تفاصيل التنفيذ. إنهم يعرفون فقط أنه إذا استخدموا SDK هذه، فسيتم تحويل حركة المرور إلى توجيه بصلي، وتشفيرها، وتقويتها.

هناك فريق أريد أن أوجه له تحية، فريق محفظة Brume، الذي بدأ Echalote، وهو تنفيذ مفتوح المصدر لـ Tor للويب. هذا موجود الآن: هناك عملاء Tor، لكنهم مكتوبون بلغة C، ويحتاجون إلى التشغيل في متصفح خاص. ماذا لو أردت إضافة هذا إلى ميتاماسك، أو إلى محفظة Kohaku، أو إلى Ambire و Rabby وجميع المحافظ الأخرى؟ نحن بحاجة إلى حزم SDKs بلغة JavaScript، وهذا ما بدأه Echalote.

بعد ذلك، لدى مشروع Tor تنفيذ جديد قيد التطوير يسمى Arti، وهو الجيل القادم من عميلهم. لكننا بحاجة إلى Arti مدمج. يعتمد Arti على لغة Rust، ويحتاج إلى تجميعه إلى WASM ليتمكن من العمل في متصفحك، حتى تتمكن من استيراده بسهولة بالغة. لدينا أساسًا تعاون مع فريق Tor: مكالمات كل أسبوع، وبعض المشاريع والشراكات معًا.

شبكات الخلط لإيثيريوم (18:16)

على جانب شبكات الخلط، أريد أن أوجه تحية للعديد من الفرق التي تقترب من هذا: فريق Nym؛ و HOPR، وهو أيضًا أحد الفرق الأولى؛ وشبكات VPNs مثل Gnosis VPN؛ واثنين آخرين كانا جديدين بالنسبة لي، مثل بروتوكول Anyone، وأعتقد أن شخصًا من هذا الفريق يجب أن يكون هنا في دنفر، بالإضافة إلى بعض الفرق الجديدة الأخرى. هناك العديد من الفرق التي تعمل على شبكات الخلط، وشبكات VPNs، ومناهج أخرى.

نريد أن نرى: ماذا لو أنشأنا شبكة خلط مصممة خصيصًا لإيثيريوم، حيث يمكننا توجيه حركة مرور RPC؟ تتمتع شبكات الخلط بضمانات قوية، لكنها تضيف الكثير من زمن الوصول. بالنسبة لبعض حالات الاستخدام، هذا جيد: لا يهم إذا استغرق الأمر وقتًا أطول قليلاً، طالما أن لديك الخصوصية. ولكن بالنسبة لأشياء مثل التمويل اللامركزي (DeFi) والتداول، فمن غير المرجح للغاية أن يتم اعتمادها إذا أضافت زمن وصول. إذن، ما هو أسرع ما يمكننا تشغيله بأعلى ضمانات الخصوصية؟ مرة أخرى، تحية لبعض هذه الفرق، وإذا كان شخص ما يعمل في هذه المجالات ولم أقم بإضافتك، فأود الدردشة معك.

الأداء: الأشجار الثنائية الموحدة وتسريع وحدة معالجة الرسومات (19:28)

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

إحداهما هي UBT. اعتمادًا على مدى مشاركتك في مقترحات تحسين إيثيريوم (EIPs) للبروتوكول، ربما تكون قد سمعت عن هذا. في الوقت الحالي لدينا شجرة ميركل باتريشيا، وهي مفيدة، ولكنها ليست مفيدة جدًا لـ ZK وأنواع أخرى من علم التشفير. هناك مقترح، EIP-7864، للانتقال ليس إلى أشجار فيركل ولكن إلى الأشجار الثنائية الموحدة. هذا أكثر كفاءة بكثير للاستعلام عن حالة ثم إجراء عمليات التشفير مثل ZK فوقها.

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

الجانب الآخر هو تسريع وحدة معالجة الرسومات (GPU). يمكننا تشغيل هذه الأشياء بشكل أسرع بكثير إذا قمنا بتحسين المستويات الأدنى من الحزمة: GPU هي إحداها، أو تسريع وحدة المعالجة المركزية (CPU) أيضًا. من المحتمل أن تعمل هذه الأشياء على الخوادم، وليس على الهواتف، لذا من المفيد جدًا أيضًا البدء في استكشاف كيف يمكننا إنشاء هذه المكتبات ذات المستوى الأدنى لتعمل بشكل أسرع بكثير.

للقيام بملخص حتى الآن: لدينا هذه الطبقات الخمس، ونريد تغطية حالات الاستخدام هذه. هناك ثلاث ركائز: البيانات، وحركة المرور، والأداء. بالنسبة للبيانات لدينا الوكلاء، و TEEs، و ORAMs، و OMAPs، و PIR. بالنسبة لحركة المرور لدينا شبكات الخلط، والتوجيه البصلي، وغيرها. بالنسبة للأداء لدينا UBT وتسريع GPU. إذا كنت ترغب في قراءة المزيد، على الأقل حول المساهمات التي تقدمها PSE، يمكنك الذهاب إلى pse.dev/research.

قياس النجاح (22:15)

إذن ما هو النجاح، وكيف يمكننا قياسه؟ بالعودة إلى هذه الطبقات: إذا أردت أن أكون قادرًا على مطالبة بأن إيثيريوم هي سلسلة الأكثر خصوصية، فما هو الهدف النهائي؟ سأحتاج إلى الشعور بالراحة لأن جميع هذه الطبقات محصنة للغاية. كيف سأقيس ذلك؟ أتوقع أن يتم استضافة المزيد من مواقع الويب والواجهات الأمامية لتطبيقات لامركزية (dapps) خلف نطاقات بصلية. أود أن تستخدم المحافظ التوجيه المجهول بشكل أصلي، والبوابات، ومزودي RPC، والمؤشرات أيضًا. وسأقيس نسبة مئوية.

السؤال هو: من بين الواجهات الأمامية الحالية للنظام البيئي لإيثيريوم، كم عدد الواجهات المستضافة خلف نطاق بصلي؟ أود أن أقول عدد قليل للغاية، 1% إن وجد. لكي أشعر بالرضا وأقول إننا فعلنا ذلك، سنحتاج على الأرجح إلى أكثر من 80% في جميع هذه الطبقات. كم عدد المحافظ في الوقت الحالي التي تقوم بتوجيه حركة المرور من خلال تقنيات التوجيه المجهول؟ عدد قليل جدًا جدًا. الشيء نفسه مع مزودي RPC: هل يقدم هؤلاء المزودون PIR؟ لا. لذا بالنسبة لي، المطالبة بالنجاح تعني أن الجهات الفاعلة في جميع هذه الطبقات تتبنى هذه الأنواع من التقنيات، على الأقل 80% من الفرق، أو حركة المرور، أو الاستعلامات.

مقارنة العقدة البصلية لبيتكوين (23:39)

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

هل يمكننا القيام بذلك بأنفسنا؟ هذه خصوصية ذات مستوى أدنى، على مستوى إجماع، ولكن هل يمكننا القول إن عقدنا الكاملة وعقد المُدَقِّقين لدينا موجودة خلف شبكة بصلية أو شبكات خلط؟ أعتقد بالتأكيد أننا يجب أن نفعل ذلك، ونحن على الأرجح عند أقل من 1%. لدينا تحديات أخرى لا يواجهونها: نحن نعمل بشكل أسرع بكثير، وإجماعنا مختلف. لكنني أود أن يكون لدي لوحات معلومات مثل هذه وأقول إن أكثر من 80% من المحافظ قد اعتمدت هذه الأنواع من التقنيات، ومزودي RPC، والمستكشفين، والواجهات الأمامية، وموازنات الحمل، وحزم SDKs أيضًا. أود أن تنمو هذه القائمة.

مقارنة إيثيريوم بـ Monero و Zcash (24:55)

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

بسبب تاريخنا الممتد لـ 10 سنوات كسلسلة عامة، أعتقد أنه سيكون من الصعب اللحاق بـ Monero و Zcash في جعل الخصوصية أصلية. لكنني أعتقد أنه يمكننا القيام بعمل جيد حقًا في الحصول على اعتماد اختياري، والتأثير ثقافيًا واجتماعيًا على الفرق والمستخدمين لاعتماد المزيد من هذه التقنيات. تواجه بيتكوين و Solana تحدياتهما الخاصة، وأعتقد أنهما ستتأخران أكثر، على الأقل في أمور الخصوصية هذه.

التحدي: النظام البيئي القابل للبرمجة الأكثر خصوصية (25:50)

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

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

لذا إذا كنت تعمل على القراءات الخاصة، أو الشبكات، أو تطبيقات PIR، أو تسريع GPU، أو هياكل البيانات، أو UBT، أو البنية التحتية، أو المُدَقِّقين، فأود الدردشة معك بعد ذلك. شكرًا جزيلاً لكم. إيثيريوم من أجل الخصوصية.