شكر خاص لدان فينلي، وكارل فلورش، وديفيد هوفمان، وفريقي Scroll وSoulWallet على التعليقات والمراجعة والاقتراحات.

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

• انتقال تحجيم L2 - ينتقل الجميع إلى القوائم المجمعة
• التحول الأمني للمحفظة - ينتقل الجميع إلى محافظ العقود الذكية
• نقل الخصوصية - التأكد من توفر تحويلات الأموال التي تحافظ على الخصوصية، والتأكد من أن جميع الأدوات الأخرى التي يتم تطويرها (التعافي الاجتماعي، والهوية، والسمعة) تحافظ على الخصوصية

مثلث التحول البيئي. يمكنك فقط اختيار 3 من 3.

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

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

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

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

ستعمل التحولات الثلاثة على إعادة تشكيل العلاقة بين المستخدمين والعناوين بشكل جذري

في عالم تحجيم L2، سيكون المستخدمون موجودين على الكثير من L2s. هل أنت عضو في exampleDAO، الذي يعيش على التفاؤل؟ إذن لديك حساب على التفاؤل! هل تحتفظ بـ CDP في نظام العملة المستقرة على ZkSync؟ إذن لديك حساب على ZkSync! هل جربت يومًا أحد التطبيقات الموجودة على Kakarot؟ إذن لديك حساب على كاكاروت! ستنتهي أيام وجود مستخدم لديه عنوان واحد فقط.

لدي ETH في أربعة أماكن، وفقًا لوجهة نظري في Brave Wallet. ونعم، Arbitrum وArbitrum Nova مختلفان. لا تقلق، سوف يصبح الأمر أكثر إرباكًا بمرور الوقت!

تضيف محافظ العقود الذكية المزيد من التعقيد، من خلال زيادة صعوبة الحصول على نفس العنوان عبر L1 وL2s المختلفة. اليوم، يستخدم معظم المستخدمين حسابات مملوكة خارجيًا، والتي يمثل عنوانها حرفيًا تجزئة للمفتاح العام المستخدم للتحقق من التوقيعات - لذلك لا يتغير شيء بين L1 وL2. ومع ذلك، مع محافظ العقود الذكية، يصبح الاحتفاظ بعنوان واحد أكثر صعوبة. على الرغم من أنه تم القيام بالكثير من العمل لمحاولة جعل العناوين عبارة عن تجزئات من التعليمات البرمجية التي يمكن أن تكون متكافئة عبر الشبكات، وأبرزها CREATE2 و ERC-2470 Singleton Factory ، إلا أنه من الصعب جعل هذا العمل مثاليًا. بعض L2s (على سبيل المثال. "النوع 4 ZK-EVMs") لا يعادل EVM تمامًا، وغالبًا ما يستخدم Solidity أو تجميع وسيط بدلاً من ذلك، مما يمنع تكافؤ التجزئة. وحتى عندما يكون من الممكن الحصول على معادلة التجزئة، فإن إمكانية تغيير ملكية المحافظ من خلال التغييرات الرئيسية تخلق عواقب أخرى غير بديهية.

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

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

1. إذا كنت تريد أن تدفع لشخص ما، كيف ستحصل على المعلومات حول كيفية الدفع له؟
2. إذا كان لدى المستخدمين العديد من الأصول المخزنة في أماكن مختلفة عبر سلاسل مختلفة، فكيف يمكنهم إجراء التغييرات الرئيسية والتعافي الاجتماعي ؟

التحولات الثلاثة والمدفوعات عبر السلسلة (والهوية)

لدي عملات معدنية على Scroll، وأريد أن أدفع ثمن القهوة (إذا كان حرف "أنا" هو أنا كاتب هذا المقال، فإن كلمة "القهوة" هي بالطبع كناية عن "الشاي الأخضر"). أنت تبيع لي القهوة، لكنك جاهز فقط لتلقي العملات المعدنية على Taiko. ماذا تفعل؟

هناك حلان أساسيان:

1. تحاول المحافظ المستلمة (التي يمكن أن تكون تجارًا، ولكن يمكن أيضًا أن تكون مجرد أفراد عاديين) جاهدة دعم كل لغة L2، ولديها بعض الوظائف الآلية لتوحيد الأموال بشكل غير متزامن.
2. يوفر المستلم L2 الخاص به إلى جانب عنوانه، وتقوم محفظة المرسل تلقائيًا بتوجيه الأموال إلى الوجهة L2 من خلال بعض أنظمة التجسير عبر L2.

بالطبع، يمكن الجمع بين هذه الحلول: يقدم المستلم قائمة L2s التي يرغب في قبولها، وتحدد محفظة المرسل الدفع، والذي قد يتضمن إما إرسالًا مباشرًا إذا كان محظوظًا، أو عبر L2 طريق الجسر.

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

لحسن الحظ، لا يشكل الانتقال إلى محافظ العقود الذكية عبئًا كبيرًا على نظام العنونة، ولكن لا تزال هناك بعض المشكلات الفنية في أجزاء أخرى من حزمة التطبيقات التي تحتاج إلى حل. ستحتاج المحافظ إلى التحديث للتأكد من أنها لا ترسل فقط 21000 غاز مع المعاملة، وسيكون من الأهم التأكد من أن جانب استلام الدفع في المحفظة لا يتتبع فقط تحويلات ETH من EOAs، ولكن أيضًا ETH يتم إرسالها عن طريق رمز العقد الذكي. التطبيقات التي تعتمد على افتراض أن ملكية العنوان غير قابلة للتغيير (على سبيل المثال. سيتعين على NFTs التي تحظر العقود الذكية لفرض الإتاوات) إيجاد طرق أخرى لتحقيق أهدافها. ستعمل محافظ العقود الذكية أيضًا على تسهيل بعض الأمور - على وجه الخصوص، إذا حصل شخص ما على رمز غير ETH ERC20 فقط، فسيكون قادرًا على استخدام جهات الدفع ERC-4337 لدفع ثمن الغاز باستخدام هذا الرمز.

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

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

نظرة عامة تخطيطية لنظام عنوان خفي مجرد يعتمد على التشفير وZK-SNARKs.

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

التحولات الثلاثة والاسترداد الرئيسي

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

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

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

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

يمكن تنفيذ الإثبات بعدة طرق:

• وصول مباشر للقراءة فقط إلى L1 داخل L2. من الممكن تعديل L2s لمنحهم طريقة لقراءة حالة L1 مباشرة. إذا كان عقد مخزن المفاتيح موجودًا على L1، فهذا يعني أن العقود الموجودة داخل L2 يمكنها الوصول إلى مخزن المفاتيح "مجانًا".
• فروع ميركل. يمكن لفروع Merkle إثبات حالة L1 إلى L2، أو حالة L2 إلى L1، أو يمكنك الجمع بين الاثنين لإثبات أجزاء من حالة L2 إلى L2 أخرى. نقطة الضعف الرئيسية في إثباتات Merkle هي ارتفاع تكاليف الغاز بسبب طول الإثبات: من المحتمل أن يكون 5 كيلو بايت للإثبات، على الرغم من أن هذا سينخفض إلى أقل من 1 كيلو بايت في المستقبل بسبب أشجار Verkle.
• ZK-SNARKs. يمكنك تقليل تكاليف البيانات باستخدام ZK-SNARK لفرع Merkle بدلاً من الفرع نفسه. من الممكن بناء تقنيات تجميع خارج السلسلة (على سبيل المثال، أعلى EIP-4337) للحصول على ZK-SNARK واحد يتحقق من جميع إثباتات الحالة عبر السلسلة في الكتلة.
• التزامات KZG. يمكن أن تقدم إما L2s، أو المخططات المبنية فوقها، نظام عنونة متسلسل، مما يسمح لإثباتات الحالة داخل هذا النظام بأن يبلغ طولها 48 بايت فقط. كما هو الحال مع ZK-SNARKs، يمكن لنظام الحماية المتعددة دمج كل هذه البراهين في دليل واحد لكل كتلة.

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

لإضافة الخصوصية إلى مثل هذا المخطط، نقوم فقط بتشفير المؤشر، ونجري كل ما لدينا من إثبات داخل ZK-SNARKs:

مع المزيد من العمل (على سبيل المثال. باستخدام<a href="https://notes.ethereum.org/ @vbuterin /non_index_revealing_proof">هذا العمل كنقطة بداية)، يمكننا أيضًا تجريد معظم تعقيدات ZK-SNARK وإنشاء مخطط أكثر تفصيلًا يعتمد على KZG.

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

تحتاج الكثير من البنية التحتية الثانوية إلى التحديث

استخدام ENS مكلف. اليوم، في يونيو 2023، الوضع ليس سيئًا للغاية: رسوم المعاملة كبيرة، لكنها لا تزال قابلة للمقارنة برسوم نطاق ENS. كلفني تسجيل zuzalu.eth حوالي 27 دولارًا، منها 11 دولارًا رسوم المعاملات. ولكن إذا كان لدينا سوق صاعدة أخرى، فسوف ترتفع الرسوم بشكل كبير. حتى بدون زيادة أسعار ETH، فإن عودة رسوم الغاز إلى 200 جيجا واي ستؤدي إلى رفع رسوم تسجيل النطاق إلى 104 دولارات. وبالتالي، إذا أردنا أن يستخدم الأشخاص ENS فعليًا، خاصة في حالات الاستخدام مثل وسائل التواصل الاجتماعي اللامركزية حيث يطلب المستخدمون تسجيلًا شبه مجاني (ولا تمثل رسوم نطاق ENS مشكلة لأن هذه المنصات تقدم لمستخدميها نطاقات فرعية)، فنحن بحاجة إلى ENS للعمل على L2.

لحسن الحظ، قام فريق ENS بتعزيز جهوده، ويتم تنفيذ ENS على L2 بالفعل! يوفر ERC-3668 (المعروف أيضًا باسم "معيار CCIP")، جنبًا إلى جنب مع ENSIP-10 ، طريقة لجعل نطاقات ENS الفرعية على أي L2 قابلة للتحقق تلقائيًا. يتطلب معيار CCIP إعداد عقد ذكي يصف طريقة للتحقق من إثباتات البيانات على L2، والمجال (على سبيل المثال. يستخدم Optinames ecc.eth) ويمكن وضعه تحت سيطرة مثل هذا العقد. بمجرد أن يتحكم عقد CCIP في ecc.eth على L1، فإن الوصول إلى بعض النطاقات الفرعية.ecc.eth سيتضمن تلقائيًا العثور على دليل والتحقق منه (على سبيل المثال. فرع Merkle) للحالة في L2 الذي يقوم بالفعل بتخزين هذا النطاق الفرعي المحدد.

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

وتُعَد جهود ENS CCIP بمثابة قصة نجاح، وينبغي لنا أن ننظر إليها باعتبارها إشارة إلى أن الإصلاحات الجذرية من ذلك النوع الذي نحتاج إليه أصبحت ممكنة بالفعل. ولكن هناك الكثير من إصلاحات طبقة التطبيقات التي يجب القيام بها. بعض الأمثلة:

• تعتمد الكثير من التطبيقات اللامركزية على المستخدمين الذين يقدمون التوقيعات خارج السلسلة. مع الحسابات المملوكة خارجيًا (EOAs)، يكون هذا أمرًا سهلاً. يوفر ERC-1271 طريقة موحدة للقيام بذلك لمحافظ العقود الذكية. ومع ذلك، لا تزال الكثير من التطبيقات اللامركزية لا تدعم ERC-1271؛ سوف يحتاجون إلى ذلك.
• التطبيقات اللامركزية التي تستخدم "هل هذه EOA؟" للتمييز بين المستخدمين والعقود (على سبيل المثال، لمنع النقل أو فرض الإتاوات) سوف تنكسر. بشكل عام، أنصح بعدم محاولة إيجاد حل تقني بحت هنا؛ إن معرفة ما إذا كان نقل معين للتحكم في التشفير يمثل نقلًا لملكية المنفعة أم لا يمثل مشكلة صعبة وربما لا يمكن حلها دون حل بعض الآليات التي يحركها المجتمع خارج السلسلة. في الأرجح، سيتعين على التطبيقات أن تعتمد بشكل أقل على منع التحويلات وأكثر على تقنيات مثل ضرائب هاربيرجر.
• يجب تحسين كيفية تفاعل المحافظ مع مفاتيح الإنفاق والتشفير. في الوقت الحالي، غالبًا ما تستخدم المحافظ التوقيعات الحتمية لإنشاء مفاتيح خاصة بالتطبيق: يؤدي توقيع الرقم القياسي (على سبيل المثال، تجزئة اسم التطبيق) باستخدام المفتاح الخاص لـ EOA إلى إنشاء قيمة حتمية لا يمكن إنشاؤها بدون المفتاح الخاص، وبالتالي فهي آمنة. بالمعنى الفني البحت. ومع ذلك، فإن هذه التقنيات "غامضة" بالنسبة للمحفظة، مما يمنع المحفظة من تنفيذ فحوصات الأمان على مستوى واجهة المستخدم. في النظام البيئي الأكثر نضجًا، سيتعين على المحافظ التعامل مع التوقيع والتشفير والوظائف ذات الصلة بشكل أكثر وضوحًا.
• العملاء الخفيفين (على سبيل المثال. Helios) سيتعين عليها التحقق من L2s وليس L1 فقط. اليوم، يركز العملاء الخفيفون على التحقق من صحة رؤوس L1 (باستخدام بروتوكول مزامنة العميل الخفيف)، والتحقق من فروع Merkle لحالة L1 والمعاملات المتجذرة في رأس L1. غدًا، سيحتاجون أيضًا إلى التحقق من إثبات حالة L2 المتجذرة في جذر الحالة المخزن في L1 (إصدار أكثر تقدمًا من هذا سينظر في الواقع إلى التأكيدات المسبقة للمستوى الثاني).

ستحتاج المحافظ إلى تأمين الأصول والبيانات

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

لقد رأينا العلامات الأولى لمثل هذا العالم مع Zupass ، وهو نظام الهوية المعتمد على ZK-SNARK والذي تم استخدامه في Zuzalu. كان لدى المستخدمين مفتاح خاص استخدموه للمصادقة على النظام، والذي يمكن استخدامه لعمل أدلة أساسية مثل "إثبات أنني مقيم في زوزالو، دون الكشف عن أي منها". لكن نظام Zupass بدأ أيضًا في إنشاء تطبيقات أخرى في الأعلى، وأبرزها الطوابع (إصدار Zupass من POAPs).

أحد طوابع Zupass العديدة الخاصة بي، يؤكد أنني عضو فخور في فريق Cat.

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

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

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

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

لتجنب إرباك المستخدم بنظام بيزنطي متعدد مسارات الاسترداد، من المحتمل أن تحتاج المحافظ التي تدعم التعافي الاجتماعي إلى إدارة استرداد الأصول واسترداد مفاتيح التشفير.

العودة إلى الهوية

أحد المواضيع المشتركة لهذه التغييرات هو أن مفهوم "العنوان"، وهو معرف التشفير الذي تستخدمه لتمثيل "أنت" على السلسلة، يجب أن يتغير بشكل جذري. لن تعد "تعليمات كيفية التفاعل معي" مجرد عنوان ETH؛ يجب أن تكون، بشكل ما، مزيجًا من عناوين متعددة على L2s متعددة، وعناوين تعريفية خفية، ومفاتيح تشفير، وبيانات أخرى.

إحدى الطرق للقيام بذلك هي جعل ENS هويتك: يمكن أن يحتوي سجل ENS الخاص بك على كل هذه المعلومات، وإذا أرسلت لشخص ما bob.eth (أو bob.ecc.eth، أو...)، يمكنهم البحث ورؤية كل شيء يتعلق بكيفية الدفع والتفاعل معك، بما في ذلك الطرق الأكثر تعقيدًا عبر النطاقات والحفاظ على الخصوصية.

لكن هذا النهج المرتكز على ENS يعاني من نقطتي ضعف:

• إنه يربط أشياء كثيرة جدًا باسمك. اسمك ليس أنت، اسمك هو إحدى صفاتك العديدة. يجب أن يكون من الممكن تغيير اسمك دون نقل ملف تعريف الهوية الخاص بك بالكامل وتحديث مجموعة كاملة من السجلات عبر العديد من التطبيقات.
• لا يمكن أن يكون لديك أسماء غير موثوقة. إحدى ميزات تجربة المستخدم الرئيسية لأي blockchain هي القدرة على إرسال العملات المعدنية إلى الأشخاص الذين لم يتفاعلوا مع السلسلة بعد. بدون هذه الوظيفة، هناك مشكلة: التفاعل مع السلسلة يتطلب دفع رسوم المعاملات، الأمر الذي يتطلب... وجود عملات معدنية بالفعل. تحتوي عناوين ETH، بما في ذلك عناوين العقود الذكية مع CREATE2، على هذه الميزة. أسماء ENS لا تفعل ذلك، لأنه إذا قرر اثنان من Bobs خارج السلسلة أنهما bob.ecc.eth، لا توجد طريقة لاختيار أي واحد منهم سيحصل على الاسم.

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

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

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

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

تنصل:

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