شكر خاص لكل من Dan Finlay و Karl Floersch و David Hoffman وفريق Scroll و SoulWallet على ملاحظاتهم ومراجعاتهم واقتراحاتهم.
نظرًا لأن Ethereum تنتقل من تقنية تجريبية شابة إلى مجموعة تقنية ناضجة قادرة حقًا على تقديم تجربة مفتوحة وعالمية وغير مصرح بها للمستخدمين العاديين ، فإن المكدس سيحتاج إلى المرور بثلاثة انتقالات تكنولوجية رئيسية في وقت واحد تقريبًا:
انتقال توسع L2 - ينتقل الجميع إلى المجموعات
انتقال أمان المحفظة - ينتقل الجميع إلى محافظ العقود الذكية
انتقال الخصوصية - تأكد من توفر تحويلات الأموال التي تحافظ على الخصوصية ، وتأكد من أن جميع الأدوات الأخرى قيد التطوير (التعافي الاجتماعي ، والهوية ، والسمعة) تحافظ على الخصوصية
مثلث انتقال النظام البيئي.
بدون الأول ، ستفشل Ethereum لأن كل معاملة تكلف 3.75 دولارًا (82.48 دولارًا إذا كان لدينا ارتفاع آخر) وكل منتج يستهدف السوق الشامل سوف ينسى حتماً السلسلة ويتبنى حلاً مركزياً لكل شيء.
بدون الثانية ، كانت Ethereum ستفشل لأن المستخدمين كانوا مترددين في تخزين أموالهم (والأصول غير المالية) ولجأ الجميع إلى التبادلات المركزية.
بدون الثلث ، ستفشل Ethereum لأن جميع المعاملات (و POAP ، وما إلى ذلك) حل مركزي يخفي بياناتك إلى أقصى حد.
تعتبر هذه التحولات الثلاثة حاسمة للأسباب الموضحة أعلاه. لكنها أيضًا تمثل تحديًا ، لأن معالجتها بشكل صحيح يتطلب تنسيقًا وثيقًا. ليست وظائف البروتوكول فقط هي التي تحتاج إلى تحسين ؛ في بعض الحالات ، يجب تغيير الطريقة التي نتفاعل بها مع Ethereum بشكل أساسي ، مما يتطلب تغييرات عميقة في التطبيقات والمحافظ.
** ستعيد هذه الانتقالات الثلاثة بشكل أساسي تشكيل العلاقة بين المستخدمين والعناوين **
في عالم ممتد من L2 ، سيكون المستخدمون موجودين في العديد من L2s. هل أنت عضو في موقع ExampleDAO الذي يعتمد على التفاؤل؟ إذن لديك حساب تفاؤل! هل تمتلك CDP في نظام stablecoin على ZkSync؟ إذن لديك حساب على ZkSync! هل جربت بعض التطبيقات على kakarot؟ إذن لديك حساب على Kakarot! لقد ولت الأيام التي كان للمستخدم فيها عنوان واحد فقط.
* وفقًا لعرض Brave Wallet ، لديّ ETH في أربعة أماكن. نعم ، يختلف Arbitrum و Arbitrum Nova. لا تقلق ، ستصبح أكثر فوضوية بمرور الوقت! *
تضيف محافظ العقود الذكية التعقيد وتجعل من الصعب الحصول على نفس العنوان في L1 ومختلف L2s. اليوم ، يستخدم معظم المستخدمين حسابات مملوكة خارجيًا تكون عناوينها في الواقع تجزئة للمفاتيح العامة المستخدمة للتحقق من التوقيعات - لذلك لا شيء يتغير بين L1 و L2. ومع ذلك ، مع محافظ العقود الذكية ، يصبح من الصعب حجز عنوان. في حين تم بذل الكثير من العمل لمحاولة جعل العناوين عبارة عن تجزئة من التعليمات البرمجية المكافئة عبر الشبكات ، وعلى الأخص المصانع الفردية CREATE2 و ERC-2470 ، فقد كان من الصعب جعل هذا العمل لا تشوبه شائبة. بعض L2s (مثل "النوع 4 ZK-EVM") ليست مكافئة تمامًا لـ EVM ، وعادة ما يتم استخدام التجميعات الصلبة أو المتوسطة بدلاً من ذلك لمنع تكافؤ التجزئة. حتى لو كان لديك معادلة التجزئة ، فإن إمكانية تغيير الملكية من خلال التغييرات الرئيسية لها عواقب أخرى غير بديهية.
تتطلب الخصوصية المزيد من العناوين لكل مستخدم وقد تغير حتى أنواع العناوين التي نتعامل معها. إذا تم استخدام اقتراح العنوان المتخفي على نطاق واسع ، فبدلاً من بضعة عناوين فقط لكل مستخدم ، أو عنوان واحد لكل L2 ، فقد يكون لدى المستخدمين عنوان واحد لكل معاملة. تعمل مخططات الخصوصية الأخرى ، حتى تلك الموجودة مثل Tornado Cash ، على تغيير طريقة تخزين الأصول بشكل مختلف: يتم تخزين أموال العديد من المستخدمين في نفس العقد الذكي (وبالتالي في نفس العنوان). لإرسال أموال إلى مستخدم معين ، سيحتاج المستخدم إلى الاعتماد على نظام العنونة الداخلي الخاص بنظام الخصوصية.
كما رأينا ، فإن كل من هذه التحولات الثلاثة يضعف النموذج العقلي "مستخدم واحد ~ = عنوان واحد" بطرق مختلفة ، مع بعض هذه التأثيرات تغذي مرة أخرى تعقيد تنفيذ الانتقال. نقطتان من المضاعفات الخاصة هما:
إذا كنت تريد أن تدفع لشخص ما ، فكيف تحصل على معلومات حول كيفية الدفع له؟
إذا كان لدى المستخدم العديد من الأصول عبر السلاسل المخزنة في أماكن مختلفة ، فكيف يقوم بإجراء التغييرات الرئيسية والتعافي الاجتماعي؟
ثلاث انتقالات ومدفوعات على السلسلة (وهويات)
لدي عملات معدنية في Scroll وأريد أن أدفع مقابل القهوة (إذا كانت كلمة "I" تشير حرفياً إلي بصفتي مؤلف هذا المقال ، فإن كلمة "coffee" هي بالطبع مرادف لكلمة "الشاي الأخضر"). أنت تبيع لي قهوة ، لكن يمكنك فقط الحصول على عملات معدنية على Taiko. ما يجب القيام به
هناك حلان أساسيان:
تعمل المحفظة المستلمة (التي يمكن أن تكون تاجرًا أو فردًا عاديًا) بجد لدعم كل L2 ، مع بعض الأتمتة لدمج الأموال بشكل غير متزامن.
يقدم المدفوع لأمره L2 وعنوانه ، وتقوم محفظة المرسل تلقائيًا بتوجيه الأموال إلى الوجهة L2 عبر بعض أنظمة التجسير بين L2.
بالطبع ، يمكن الجمع بين هذه الحلول: يقدم المستلم قائمة L2s التي يرغب في قبولها ، وتحدد محفظة المرسل الدفع ، والذي قد يتضمن إرسالًا مباشرًا ، أو مسارًا مرتبطًا عبر L2 إذا كان محظوظًا.
لكن هذا مجرد مثال واحد على التحدي الرئيسي الذي تقدمه هذه التحولات الثلاثة: تبدأ العمليات البسيطة مثل الدفع لشخص ما في طلب معلومات أكثر من مجرد عنوان من 20 بايت.
لحسن الحظ ، لن يؤدي الانتقال إلى محافظ العقود الذكية إلى زيادة العبء على نظام العنونة ، ولكن لا تزال هناك بعض المشكلات الفنية التي يتعين حلها في أجزاء أخرى من حزمة التطبيقات. ستحتاج المحافظ إلى التحديث للتأكد من أنها لا ترسل فقط 21000 غاز مع المعاملة ، والأهم من ذلك التأكد من أن الطرف المستلم للمحفظة لا يتتبع تحويل ETH من EOA فحسب ، بل يتتبع أيضًا ETH مرسلة بواسطة رمز العقد الذكي. يجب على التطبيقات التي تعتمد على افتراض الملكية غير القابلة للتغيير للعناوين (مثل NFTs التي تحظر العقود الذكية لفرض رسوم الإتاوة) أن تجد طرقًا أخرى لتحقيق أهدافها. ستعمل محافظ العقود الذكية أيضًا على تسهيل الأمور - لا سيما إذا تلقى شخص ما رمزًا مميزًا من غير ETH ERC20 ، فسيكون قادرًا على استخدام هذا الرمز المميز للدفع مقابل الغاز باستخدام صائدي الدفع ERC-4337.
من ناحية أخرى ، تشكل الخصوصية مرة أخرى تحديًا كبيرًا لم نواجهه حقًا بعد. لم تقدم Tornado Cash الأصلية أيًا من هذه المشكلات لأنها لا تدعم التحويلات الداخلية: يمكن للمستخدمين فقط الإيداع في النظام والانسحاب منه. ومع ذلك ، بمجرد أن تصبح عمليات النقل الداخلية ممكنة ، سيحتاج المستخدمون إلى استخدام نظام العنونة الداخلي لنظام الخصوصية. من الناحية العملية ، يجب أن تحتوي "رسالة الدفع" الخاصة بالمستخدم على (1) نوعًا من "مفتاح الإنفاق" ، ووعد بسر يمكن للمستلم استخدامه للإنفاق ، و (2) طريقة ما يمكن للمرسل من خلالها إرسال العملة المشفرة فقط المعلومات التي يمكن للمدفوع له فك شفرتها لمساعدة المستفيد على اكتشاف الدفع.
يعتمد بروتوكول العنوان الخفي على مفهوم عنوان التعريف ، والذي يعمل بهذه الطريقة: جزء من عنوان التعريف هو نسخة معماة من مفتاح إنفاق المرسل ، والجزء الآخر هو مفتاح تشفير المرسل (على الرغم من أن الحد الأدنى من التطبيقات يمكن أن يحدد كلاهما المفاتيح هي نفسها).
رسم تخطيطي لمخطط عناوين مجردة يعتمد على التشفير و ZK-SNARKs.
الدرس الأساسي هنا هو أنه في النظام البيئي الصديق للخصوصية ، سيكون لدى المستخدمين مفاتيح عامة للاستهلاك ومفاتيح عامة للتشفير ، ويجب أن تتضمن "معلومات الدفع" الخاصة بالمستخدم كلا المفتاحين. بالإضافة إلى المدفوعات ، هناك أسباب وجيهة للتوسع في هذا الاتجاه. على سبيل المثال ، إذا أردنا رسائل بريد إلكتروني مشفرة تستند إلى Ethereum ، فسيحتاج المستخدمون إلى تقديم نوع من مفتاح التشفير بشكل عام. في "عالم EOA" يمكننا إعادة استخدام مفاتيح الحساب لهذا الغرض ، ولكن في عالم محافظ العقود الذكية الآمنة ، ربما ينبغي علينا توفير وظيفة أكثر وضوحًا لهذا الغرض. يساعد هذا أيضًا في جعل الهويات المستندة إلى Ethereum أكثر توافقًا مع أنظمة الخصوصية اللامركزية غير Ethereum ، وخاصة مفاتيح PGP.
ثلاث انتقالات واستعادة المفتاح
الطريقة الافتراضية لتنفيذ التغييرات الحرجة والتعافي الاجتماعي في عالم يمتلك فيه كل مستخدم عناوين متعددة هي ببساطة أن يقوم المستخدم بتشغيل عملية الاسترداد على كل عنوان على حدة. يمكن القيام بذلك بنقرة واحدة: يمكن أن تحتوي المحافظ على برنامج يمكنه تنفيذ إجراءات الاسترداد على جميع عناوين المستخدم في وقت واحد. ومع ذلك ، حتى مع هذا التبسيط لتجربة المستخدم ، هناك ثلاث مشاكل في الاسترداد البسيط متعدد العناوين:
تكلفة الغاز غير عملية: هذا لا يحتاج إلى شرح.
العناوين المقابلة للواقع: العناوين التي لم يصدر عنها العقد الذكي بعد (في الواقع ، هذا يعني الحسابات التي لم ترسل أموالاً منها بعد). بصفتك مستخدمًا ، قد يكون لديك عدد لا حصر له من العناوين المغايرة: عنوان واحد أو أكثر في كل L2 ، بما في ذلك L2s التي لم تكن موجودة بعد ، ومجموعة أخرى لا حصر لها من العناوين المضادة الناتجة عن نظام العناوين المتخفي.
الخصوصية: إذا كان لدى المستخدم عناوين متعددة عن قصد لتجنب ربطها ببعضها البعض ، فمن المؤكد أنهم لا يريدون ربطها جميعًا علنًا عن طريق استعادتها في نفس الوقت تقريبًا!
حل هذه المشاكل صعب. لحسن الحظ ، هناك حل أنيق يؤدي أداءً جيدًا بشكل معقول: بنية تفصل بين منطق التحقق من الصحة وحيازة الأصول.
كل مستخدم لديه عقد تخزين مفاتيح موجود في مكان واحد (يمكن أن يكون الشبكة الرئيسية أو L2 محدد). بعد ذلك ، يكون لدى المستخدمين عناوين على L2s مختلفة ، حيث يكون منطق التحقق من الصحة لكل عنوان هو مؤشر لعقد مخزن المفاتيح. يتطلب الإنفاق من هذه العناوين إثباتًا للدخول في عقد مخزن المفاتيح يوضح مفتاح الإنفاق العام الحالي (أو الأحدث بشكل أكثر واقعية).
يمكن تحقيق الإثبات بعدة طرق:
الوصول المباشر للقراءة فقط L1 في L2. يمكن تعديل L2 لقراءة حالة L1 مباشرة. إذا كان عقد مخزن المفاتيح على L1 ، فهذا يعني أن العقود داخل L2 لها وصول "مجاني" إلى مخزن المفاتيح
فرع ميركل. يمكن أن تشهد فروع Merkle على حالة L1 إلى L2 ، أو حالة L2 إلى L1 ، أو يمكنك دمج الاثنين لإثبات حالة جزئية من L2 إلى حالة L2 أخرى. يتمثل الضعف الرئيسي في براهين Merkle في ارتفاع تكلفة الغاز بسبب طول الإثبات: قد يتطلب الإثبات 5 كيلو بايت ، ولكن سيتم تقليل هذا إلى <1 كيلو بايت في المستقبل بفضل أشجار Verkle.
ZK-SNARKs. يمكنك تقليل تكاليف البيانات باستخدام ZK-SNARKs of Merkle forks بدلاً من الشوكات نفسها. يمكن بناء تقنيات التجميع خارج السلسلة (على سبيل المثال ، أعلى EIP-4337) للحصول على ZK-SNARK للتحقق من جميع براهين الحالة عبر السلسلة في الكتلة.
وعد KZG. يمكن أن تقدم L2 ، أو المخططات المبنية فوقها ، نظام عنونة متسلسل ، مما يسمح بإثباتات الحالة داخل هذا النظام بطول 48 بايت فقط. مثل ZK-SNARKs ، يمكن أن تدمج مخططات الإثبات المتعددة كل هذه البراهين في برهان واحد لكل كتلة.
إذا أردنا تجنب تقديم دليل لكل معاملة ، فيمكننا تنفيذ مخطط أخف لا يتطلب سوى إثبات واحد عبر L2 للتعافي. يعتمد الإنفاق من الحساب على مفتاح الإنفاق الذي يتم تخزين مفتاحه العمومي المقابل في الحساب ، لكن الاسترداد سيتطلب معاملة لنسخ المفتاح العام للإنفاق الحالي في مخزن المفاتيح. الأموال الموجودة في العناوين غير الواقعية تكون آمنة حتى لو لم تكن مفاتيحك القديمة: "تنشيط" العنوان المضاد لتحويله إلى عقد عمل يتطلب إثباتًا متقاطعًا من المستوى الثاني لتكرار الإنفاق الحالي \ _pubkey. يصف هذا الموضوع في المنتديات الآمنة كيفية عمل بنية مشابهة.
لإضافة الخصوصية إلى مثل هذا المخطط ، نقوم ببساطة بتشفير هذا المؤشر ، ثم نقوم بعمل جميع البراهين في ZK-SNARKs:
مع مزيد من العمل (على سبيل المثال ، استخدام هذا العمل كنقطة بداية) ، يمكننا أيضًا إزالة معظم تعقيدات ZK-SNARKs وإنشاء مخطط أبسط يعتمد على KZG.
يمكن أن تصبح هذه السيناريوهات معقدة. على الجانب الإيجابي ، هناك العديد من أوجه التآزر المحتملة بينهما. على سبيل المثال ، يمكن لمفهوم "عقود مخزن المفاتيح" أن يحل أيضًا تحدي "العنوان" المذكور في القسم السابق: إذا أردنا أن يكون للمستخدمين عناوين دائمة لا تتغير في كل مرة يقوم فيها المستخدم بإعادة المفاتيح ، فيمكننا وضع عناوين التعريف المخفية ، يتم وضع مفاتيح التشفير والمعلومات الأخرى في عقد مخزن المفاتيح ، ويتم استخدام عنوان عقد مخزن المفاتيح باعتباره "عنوان" المستخدم.
يحتاج الكثير من البنية التحتية الثانوية إلى التحديث
استخدام ENS مكلف. اليوم ، في يونيو 2023 ، الأمور ليست بهذا السوء: رسوم المعاملات مرتفعة ، لكنها لا تزال قابلة للمقارنة برسوم مجال ENS. كلفني التسجيل في zuzalu.eth حوالي 27 دولارًا ، منها 11 دولارًا كانت رسوم المعاملات. ولكن إذا كان لدينا سوق صاعدة أخرى ، فسترتفع الرسوم بشدة. حتى بدون زيادة سعر ETH ، فإن إعادة رسوم الغاز إلى 200 gwei من شأنه أن يرفع رسوم TX لتسجيلات المجال إلى 104 دولارات. لذلك إذا أردنا أن يستخدم الأشخاص بالفعل ENS ، خاصةً في حالات الاستخدام مثل الوسائط الاجتماعية اللامركزية حيث يطلب المستخدمون تسجيلًا مجانيًا تقريبًا (ورسوم مجال ENS ليست مشكلة نظرًا لأن هذه الأنظمة الأساسية توفر لمستخدميها نطاقات فرعية) ، فنحن بحاجة إلى ENS في L2 للعمل .
لحسن الحظ ، صعد فريق ENS ويحدث ENS على L2! يوفر ERC-3668 (المعروف أيضًا باسم "معيار CCIP") ، جنبًا إلى جنب مع ENSIP-10 ، طريقة لجعل نطاقات ENS الفرعية على أي L2 قابلة للتحقق تلقائيًا. يتطلب معيار CCIP إنشاء عقد ذكي يصف طريقة للتحقق من إثباتات بيانات L2 ، وأن المجالات (مثل Optinames تستخدم ecc.eth) يمكن إخضاعها لسيطرة مثل هذا العقد. بمجرد أن يتحكم عقد CCIP في ecc.eth على L1 ، سيشمل الوصول إلى بعض subdomain.ecc.eth تلقائيًا البحث عن إثبات الحالة والتحقق منه (مثل فرع Merkle) في L2 حيث يتم تخزين هذا النطاق الفرعي المعين بالفعل.
في الواقع ، يتضمن الحصول على البراهين قائمة بعناوين URL المخزنة في العقد ، والتي تبدو بالتأكيد وكأنها مركزية ، لكنني أعتقد أنها ليست في الواقع: إنها نموذج ثقة 1 من N (يتم اكتشاف البراهين غير الصالحة من خلال منطق التحقق في وظيفة استعادة عقد CCIP ، طالما أن أحد عناوين URL يعرض دليلاً صالحًا ، فلا بأس بذلك). قد تحتوي قائمة عناوين URL على العشرات.
إن جهود ENS CCIP هي قصة نجاح ، ويجب أن يُنظر إليها على أنها علامة على أن نوع الإصلاح الجذري الذي نحتاجه ممكن بالفعل. ولكن لا يزال هناك العديد من إصلاحات طبقة التطبيق التي يتعين القيام بها. بعض الأمثلة:
تعتمد العديد من dapps على المستخدمين لتقديم توقيعات خارج السلسلة. مع حساب مملوك خارجيًا (EOA) ، الأمر سهل. يوفر ERC-1271 طريقة موحدة لمحافظ العقود الذكية للقيام بذلك. ومع ذلك ، لا يزال العديد من dapps لا يدعم ERC-1271 ؛ سيحتاجون إلى ذلك.
ستنتهي تطبيقات Dapps التي تستخدم "هل هذا EOA؟" للتمييز بين المستخدمين والعقود (على سبيل المثال ، منع عمليات النقل أو فرض رسوم حقوق الملكية). بشكل عام ، أنصح بعدم البحث عن حلول تقنية بحتة هنا ؛ معرفة ما إذا كان نقل معين للتحكم في التشفير هو نقل ملكية مفيدة يمثل مشكلة صعبة قد لا يتم حلها دون معالجة بعض الآليات التي يقودها المجتمع خارج السلسلة. على الأرجح ، سيتعين على التطبيقات أن تعتمد بدرجة أقل على منع التحويل وأكثر على تقنيات مثل ضرائب Harberger.
يجب تحسين كيفية تفاعل المحافظ مع مفاتيح الإنفاق والتشفير. في الوقت الحالي ، تستخدم المحافظ عادةً التوقيعات الحتمية لإنشاء مفاتيح خاصة بالتطبيق: التوقيع على رمز nonce قياسي (مثل تجزئة اسم التطبيق) باستخدام المفتاح الخاص لـ EOA يولد قيمة حتمية لا يمكن إنشاؤها بدون المفتاح الخاص ، لذلك فهو آمن بمعنى تقني بحت. ومع ذلك ، فإن هذه التقنيات "غير شفافة" للمحافظ ، مما يمنع المحافظ من تنفيذ فحوصات أمان على مستوى واجهة المستخدم. في الأنظمة البيئية الأكثر نضجًا ، يجب التعامل مع التوقيع والتشفير والوظائف ذات الصلة بشكل أكثر وضوحًا بواسطة المحافظ.
سيتعين على عملاء Light (مثل Helios) مصادقة L2 وليس L1 فقط. اليوم ، يركز العملاء الخفيفون على التحقق من صلاحية رؤوس L1 (باستخدام بروتوكول مزامنة العميل الخفيف) ، والتحقق من شوكات Merkle لحالة L1 والمعاملات المتجذرة في رؤوس L1. غدًا ، يحتاجون أيضًا إلى التحقق من إثبات حالة L2 ، المتجذر في جذر الحالة المخزن في L1 (الإصدار الأكثر تقدمًا ينظر في الواقع إلى التأكيد المسبق L2).
ستحتاج المحافظ إلى حماية الأصول والبيانات
اليوم ، تعمل المحافظ في حماية الأصول. كل شيء متصل بالسلسلة ، والشيء الوحيد الذي تحتاج المحفظة إلى حمايته هو المفاتيح الخاصة التي تؤمن هذه الأصول حاليًا. إذا قمت بتغيير مفتاحك ، يمكنك نشر مفتاحك الخاص السابق بأمان على الإنترنت في اليوم التالي. ومع ذلك ، في عالم ZK ، لم يعد هذا صحيحًا: لا تحمي المحفظة بيانات اعتماد المصادقة فحسب ، بل تحتفظ أيضًا ببياناتك.
لقد رأينا العلامات الأولى لهذا العالم مع Zupass ، وهو نظام الهوية المستند إلى ZK-SNARK الذي تستخدمه Zuzalu. يمتلك المستخدم مفتاحًا خاصًا للمصادقة على النظام ، والذي يمكن استخدامه لعمل أدلة أساسية مثل "إثبات أنني مقيم في Zuzalu دون الكشف عن أي واحد". لكن نظام Zupass بدأ أيضًا في إنشاء تطبيقات أخرى فوقه ، أبرزها ختم (إصدار Zupass من POAP).
أحد أختام Zupass العديدة التي أحملها تؤكد أنني عضو فخور في Team Cat.
الميزة الرئيسية التي تقدمها الطوابع مقارنة بـ POAP هي أن الطوابع خاصة: تحتفظ بالبيانات محليًا ، وإذا كنت تريد أن يكون لدى شخص ما معلومات عنك ، عليك فقط إثبات طابع (أو بعض الحسابات على طابع) لشخص ما. لكن هذا يزيد من المخاطر: إذا فقدت تلك المعلومات ، فستفقد الطابع.
بالطبع ، يمكن تقليل مشكلة الاحتفاظ بالبيانات إلى مشكلة الاحتفاظ بمفتاح تشفير واحد: يمكن لبعض الأطراف الثالثة (أو حتى السلسلة) الاحتفاظ بنسخة مشفرة من البيانات. يتمتع هذا بميزة ملائمة تتمثل في أن الإجراء الذي تتخذه لا يغير مفتاح التشفير ، لذلك لا يلزم أي تفاعل مع النظام الذي يحافظ على أمان مفتاح التشفير الخاص بك. ولكن حتى ذلك الحين ، إذا فقدت مفتاح التشفير ، فستفقد كل شيء. من ناحية أخرى ، إذا رأى شخص ما مفتاح التشفير الخاص بك ، فيمكنه رؤية كل شيء مشفر بهذا المفتاح.
يتمثل الحل العملي لـ Zupass في تشجيع الأشخاص على تخزين مفاتيحهم على أجهزة متعددة (مثل الكمبيوتر المحمول والهاتف) ، نظرًا لأن فرص فقدانهم للوصول إليها جميعًا في نفس الوقت ضئيلة. يمكننا الذهاب إلى أبعد من ذلك واستخدام مشاركة سرية لتخزين المفاتيح ، الموزعة بين الأوصياء المتعددين.
هذا التعافي الاجتماعي عبر MPC ليس حلاً مناسبًا للمحافظ ، لأنه لا يعني فقط أن الأوصياء الحاليين ولكن الأوصياء السابقين أيضًا يمكن أن يتواطأوا لسرقة أصولك ، وهي مخاطرة عالية بشكل غير مقبول. لكن خطر خرق الخصوصية عادة ما يكون أقل من إجمالي مخاطر فقدان الأصول ، ويمكن للأشخاص الذين لديهم حالات استخدام عالية للخصوصية أن يقبلوا دائمًا مخاطر أعلى للخسارة من خلال عدم نسخ المفاتيح المرتبطة بهذه العمليات التي تتطلب الخصوصية احتياطيًا.
لتجنب إغراق المستخدمين بالأنظمة البيزنطية بمسارات استرداد متعددة ، قد تحتاج المحافظ التي تدعم التعافي الاجتماعي إلى إدارة استرداد الأصول واسترداد مفتاح التشفير.
العودة إلى الهوية
أحد الأشياء المشتركة بين هذه التغييرات هو أن مفهوم "العنوان" ، معرف التشفير الذي تستخدمه لتمثيل "أنت" على السلسلة ، يجب أن يتغير بشكل أساسي. لن تكون "إرشادات حول كيفية التفاعل معي" مجرد عنوان ETH ؛ يجب أن تكون مزيجًا من عناوين متعددة في L2s متعددة وعناوين وصفية متخفية ومفاتيح تشفير وبيانات أخرى في شكل ما.
تتمثل إحدى الطرق في جعل ENS هويتك: يمكن أن يحتوي سجل ENS الخاص بك فقط على كل هذه المعلومات ، وإذا أرسلت شخصًا ما bob.eth (أو bob.ecc.eth ، أو ...) ، فيمكنه البحث ورؤية كل شيء عن الكيفية إنه يدفع لك ويتفاعل معك ، بما في ذلك طرق أكثر تعقيدًا عبر المجالات والحفاظ على الخصوصية.
لكن هذا النهج المتمحور حول ENS له نقطتا ضعف:
يربط الكثير من الأشياء باسم المجال الخاص بك. اسم المجال الخاص بك ليس أنت ، اسم المجال الخاص بك هو واحد من سمات كثيرة لك. يجب أن يكون من الممكن تغيير اسم المجال الخاص بك دون نقل ملف تعريف هويتك بالكامل وتحديث مجموعة كاملة من السجلات في العديد من التطبيقات.
لا يمكن أن يكون لديك ذرة غير موثوق بها. تتمثل إحدى ميزات UX الرئيسية لأي blockchain في القدرة على إرسال عملات معدنية إلى الأشخاص الذين لم يتفاعلوا بعد مع السلسلة. بدون هذه الوظيفة ، هناك مشكلة - 22: يتطلب التفاعل مع السلسلة دفع رسوم المعاملات ، الأمر الذي يتطلب ... امتلاك عملات معدنية بالفعل. تحتوي عناوين ETH ، بما في ذلك عناوين العقود الذكية مع CREATE2 ، على هذه الوظيفة. لن تكون أسماء ENS ، لأنه إذا قرر اثنان من Bobs أنهما bob.ecc.eth خارج السلسلة ، فلا توجد طريقة لاختيار أي منهما يحصل على الاسم.
يتمثل أحد الحلول الممكنة في وضع المزيد من المحتوى في عقد مخزن المفاتيح المذكور في الهندسة المعمارية سابقًا في هذه المقالة. يمكن أن يحتوي عقد مخزن المفاتيح على جميع أنواع المعلومات عنك وكيفية تفاعلك معها (بالنسبة إلى CCIP ، قد تكون بعض هذه المعلومات خارج السلسلة) ، وسيستخدم المستخدمون عقد تخزين المفاتيح كمعرف أساسي لهم. لكن الأصول الفعلية التي يتلقونها سيتم تخزينها في أماكن مختلفة. تعتبر عقود Keystore حيادية الاسم ، وهي صديقة للواقع المضاد: يمكنك إنشاء عنوان يمكن إثبات تهيئته فقط من خلال عقد keystore مع بعض المعلمات الأولية الثابتة.
هناك نوع آخر من الحلول مشابه لبروتوكول دفع Bitcoin ، حيث يتخلى تمامًا عن مفهوم العناوين الموجهة للمستخدم. تتمثل إحدى الأفكار في الاعتماد أكثر على قنوات الاتصال المباشر بين المرسل والمستلم ؛ على سبيل المثال ، يمكن للمرسل إرسال رابط مطالبة (كعنوان URL صريح أو رمز QR) يمكن للمستلم استخدامه لمتابعة استعداده لقبول الدفع.
بغض النظر عما إذا كان المرسل أو المستلم يتحرك أولاً ، فإن الاعتماد بشكل أكبر على المحافظ لإنشاء معلومات دفع محدثة بشكل مباشر في الوقت الفعلي يقلل من الاحتكاك. ومع ذلك ، فإن المعرفات المستمرة مريحة (خاصة مع ENS) ، في حين أن افتراض الاتصال المباشر بين المرسل والمستقبل أمر صعب للغاية في الممارسة العملية ، لذلك قد ينتهي بنا الأمر إلى رؤية مجموعة من التقنيات المختلفة.
في كل هذه التصميمات ، يعد جعل الأشياء منفصلة ويسهل على المستخدمين فهمها هو الأهم. نحتاج إلى التأكد من أن المستخدمين لديهم وصول سهل إلى أحدث طريقة عرض لماهية أصولهم الحالية والأخبار المنشورة لهم. يجب أن تعتمد وجهات النظر هذه على الأدوات المفتوحة ، وليس الحلول الاحتكارية. إن الحفاظ على البنية التحتية للدفع الأكثر تعقيدًا من أن تصبح "برجًا تجريدًا" مبهمًا حيث يواجه المطورون صعوبة في فهم ما يجري وتكييفه مع البيئة الجديدة سيتطلب عملاً شاقًا. على الرغم من التحديات ، فإن تحقيق قابلية التوسع وأمن المحفظة والخصوصية للمستخدمين العاديين أمر بالغ الأهمية لمستقبل Ethereum. لا يتعلق الأمر فقط بالجدوى الفنية ، بل يتعلق بإمكانية الوصول الفعلية للمستخدم العادي. نحن بحاجة للارتقاء إلى مستوى هذا التحدي.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
فيتاليك بوتيرين: التحولات الفنية الثلاثة لإيثريوم
المؤلف الأصلي: مؤسس Ethereum Vitalik Buterin
شكر خاص لكل من Dan Finlay و Karl Floersch و David Hoffman وفريق Scroll و SoulWallet على ملاحظاتهم ومراجعاتهم واقتراحاتهم.
نظرًا لأن Ethereum تنتقل من تقنية تجريبية شابة إلى مجموعة تقنية ناضجة قادرة حقًا على تقديم تجربة مفتوحة وعالمية وغير مصرح بها للمستخدمين العاديين ، فإن المكدس سيحتاج إلى المرور بثلاثة انتقالات تكنولوجية رئيسية في وقت واحد تقريبًا:
بدون الأول ، ستفشل Ethereum لأن كل معاملة تكلف 3.75 دولارًا (82.48 دولارًا إذا كان لدينا ارتفاع آخر) وكل منتج يستهدف السوق الشامل سوف ينسى حتماً السلسلة ويتبنى حلاً مركزياً لكل شيء.
بدون الثانية ، كانت Ethereum ستفشل لأن المستخدمين كانوا مترددين في تخزين أموالهم (والأصول غير المالية) ولجأ الجميع إلى التبادلات المركزية.
بدون الثلث ، ستفشل Ethereum لأن جميع المعاملات (و POAP ، وما إلى ذلك) حل مركزي يخفي بياناتك إلى أقصى حد.
تعتبر هذه التحولات الثلاثة حاسمة للأسباب الموضحة أعلاه. لكنها أيضًا تمثل تحديًا ، لأن معالجتها بشكل صحيح يتطلب تنسيقًا وثيقًا. ليست وظائف البروتوكول فقط هي التي تحتاج إلى تحسين ؛ في بعض الحالات ، يجب تغيير الطريقة التي نتفاعل بها مع Ethereum بشكل أساسي ، مما يتطلب تغييرات عميقة في التطبيقات والمحافظ.
** ستعيد هذه الانتقالات الثلاثة بشكل أساسي تشكيل العلاقة بين المستخدمين والعناوين **
في عالم ممتد من L2 ، سيكون المستخدمون موجودين في العديد من L2s. هل أنت عضو في موقع ExampleDAO الذي يعتمد على التفاؤل؟ إذن لديك حساب تفاؤل! هل تمتلك CDP في نظام stablecoin على ZkSync؟ إذن لديك حساب على ZkSync! هل جربت بعض التطبيقات على kakarot؟ إذن لديك حساب على Kakarot! لقد ولت الأيام التي كان للمستخدم فيها عنوان واحد فقط.
تضيف محافظ العقود الذكية التعقيد وتجعل من الصعب الحصول على نفس العنوان في L1 ومختلف L2s. اليوم ، يستخدم معظم المستخدمين حسابات مملوكة خارجيًا تكون عناوينها في الواقع تجزئة للمفاتيح العامة المستخدمة للتحقق من التوقيعات - لذلك لا شيء يتغير بين L1 و L2. ومع ذلك ، مع محافظ العقود الذكية ، يصبح من الصعب حجز عنوان. في حين تم بذل الكثير من العمل لمحاولة جعل العناوين عبارة عن تجزئة من التعليمات البرمجية المكافئة عبر الشبكات ، وعلى الأخص المصانع الفردية CREATE2 و ERC-2470 ، فقد كان من الصعب جعل هذا العمل لا تشوبه شائبة. بعض L2s (مثل "النوع 4 ZK-EVM") ليست مكافئة تمامًا لـ EVM ، وعادة ما يتم استخدام التجميعات الصلبة أو المتوسطة بدلاً من ذلك لمنع تكافؤ التجزئة. حتى لو كان لديك معادلة التجزئة ، فإن إمكانية تغيير الملكية من خلال التغييرات الرئيسية لها عواقب أخرى غير بديهية.
تتطلب الخصوصية المزيد من العناوين لكل مستخدم وقد تغير حتى أنواع العناوين التي نتعامل معها. إذا تم استخدام اقتراح العنوان المتخفي على نطاق واسع ، فبدلاً من بضعة عناوين فقط لكل مستخدم ، أو عنوان واحد لكل L2 ، فقد يكون لدى المستخدمين عنوان واحد لكل معاملة. تعمل مخططات الخصوصية الأخرى ، حتى تلك الموجودة مثل Tornado Cash ، على تغيير طريقة تخزين الأصول بشكل مختلف: يتم تخزين أموال العديد من المستخدمين في نفس العقد الذكي (وبالتالي في نفس العنوان). لإرسال أموال إلى مستخدم معين ، سيحتاج المستخدم إلى الاعتماد على نظام العنونة الداخلي الخاص بنظام الخصوصية.
كما رأينا ، فإن كل من هذه التحولات الثلاثة يضعف النموذج العقلي "مستخدم واحد ~ = عنوان واحد" بطرق مختلفة ، مع بعض هذه التأثيرات تغذي مرة أخرى تعقيد تنفيذ الانتقال. نقطتان من المضاعفات الخاصة هما:
إذا كنت تريد أن تدفع لشخص ما ، فكيف تحصل على معلومات حول كيفية الدفع له؟
إذا كان لدى المستخدم العديد من الأصول عبر السلاسل المخزنة في أماكن مختلفة ، فكيف يقوم بإجراء التغييرات الرئيسية والتعافي الاجتماعي؟
ثلاث انتقالات ومدفوعات على السلسلة (وهويات)
لدي عملات معدنية في Scroll وأريد أن أدفع مقابل القهوة (إذا كانت كلمة "I" تشير حرفياً إلي بصفتي مؤلف هذا المقال ، فإن كلمة "coffee" هي بالطبع مرادف لكلمة "الشاي الأخضر"). أنت تبيع لي قهوة ، لكن يمكنك فقط الحصول على عملات معدنية على Taiko. ما يجب القيام به
هناك حلان أساسيان:
بالطبع ، يمكن الجمع بين هذه الحلول: يقدم المستلم قائمة L2s التي يرغب في قبولها ، وتحدد محفظة المرسل الدفع ، والذي قد يتضمن إرسالًا مباشرًا ، أو مسارًا مرتبطًا عبر L2 إذا كان محظوظًا.
لكن هذا مجرد مثال واحد على التحدي الرئيسي الذي تقدمه هذه التحولات الثلاثة: تبدأ العمليات البسيطة مثل الدفع لشخص ما في طلب معلومات أكثر من مجرد عنوان من 20 بايت.
لحسن الحظ ، لن يؤدي الانتقال إلى محافظ العقود الذكية إلى زيادة العبء على نظام العنونة ، ولكن لا تزال هناك بعض المشكلات الفنية التي يتعين حلها في أجزاء أخرى من حزمة التطبيقات. ستحتاج المحافظ إلى التحديث للتأكد من أنها لا ترسل فقط 21000 غاز مع المعاملة ، والأهم من ذلك التأكد من أن الطرف المستلم للمحفظة لا يتتبع تحويل ETH من EOA فحسب ، بل يتتبع أيضًا ETH مرسلة بواسطة رمز العقد الذكي. يجب على التطبيقات التي تعتمد على افتراض الملكية غير القابلة للتغيير للعناوين (مثل NFTs التي تحظر العقود الذكية لفرض رسوم الإتاوة) أن تجد طرقًا أخرى لتحقيق أهدافها. ستعمل محافظ العقود الذكية أيضًا على تسهيل الأمور - لا سيما إذا تلقى شخص ما رمزًا مميزًا من غير ETH ERC20 ، فسيكون قادرًا على استخدام هذا الرمز المميز للدفع مقابل الغاز باستخدام صائدي الدفع ERC-4337.
من ناحية أخرى ، تشكل الخصوصية مرة أخرى تحديًا كبيرًا لم نواجهه حقًا بعد. لم تقدم Tornado Cash الأصلية أيًا من هذه المشكلات لأنها لا تدعم التحويلات الداخلية: يمكن للمستخدمين فقط الإيداع في النظام والانسحاب منه. ومع ذلك ، بمجرد أن تصبح عمليات النقل الداخلية ممكنة ، سيحتاج المستخدمون إلى استخدام نظام العنونة الداخلي لنظام الخصوصية. من الناحية العملية ، يجب أن تحتوي "رسالة الدفع" الخاصة بالمستخدم على (1) نوعًا من "مفتاح الإنفاق" ، ووعد بسر يمكن للمستلم استخدامه للإنفاق ، و (2) طريقة ما يمكن للمرسل من خلالها إرسال العملة المشفرة فقط المعلومات التي يمكن للمدفوع له فك شفرتها لمساعدة المستفيد على اكتشاف الدفع.
يعتمد بروتوكول العنوان الخفي على مفهوم عنوان التعريف ، والذي يعمل بهذه الطريقة: جزء من عنوان التعريف هو نسخة معماة من مفتاح إنفاق المرسل ، والجزء الآخر هو مفتاح تشفير المرسل (على الرغم من أن الحد الأدنى من التطبيقات يمكن أن يحدد كلاهما المفاتيح هي نفسها).
الدرس الأساسي هنا هو أنه في النظام البيئي الصديق للخصوصية ، سيكون لدى المستخدمين مفاتيح عامة للاستهلاك ومفاتيح عامة للتشفير ، ويجب أن تتضمن "معلومات الدفع" الخاصة بالمستخدم كلا المفتاحين. بالإضافة إلى المدفوعات ، هناك أسباب وجيهة للتوسع في هذا الاتجاه. على سبيل المثال ، إذا أردنا رسائل بريد إلكتروني مشفرة تستند إلى Ethereum ، فسيحتاج المستخدمون إلى تقديم نوع من مفتاح التشفير بشكل عام. في "عالم EOA" يمكننا إعادة استخدام مفاتيح الحساب لهذا الغرض ، ولكن في عالم محافظ العقود الذكية الآمنة ، ربما ينبغي علينا توفير وظيفة أكثر وضوحًا لهذا الغرض. يساعد هذا أيضًا في جعل الهويات المستندة إلى Ethereum أكثر توافقًا مع أنظمة الخصوصية اللامركزية غير Ethereum ، وخاصة مفاتيح PGP.
ثلاث انتقالات واستعادة المفتاح
الطريقة الافتراضية لتنفيذ التغييرات الحرجة والتعافي الاجتماعي في عالم يمتلك فيه كل مستخدم عناوين متعددة هي ببساطة أن يقوم المستخدم بتشغيل عملية الاسترداد على كل عنوان على حدة. يمكن القيام بذلك بنقرة واحدة: يمكن أن تحتوي المحافظ على برنامج يمكنه تنفيذ إجراءات الاسترداد على جميع عناوين المستخدم في وقت واحد. ومع ذلك ، حتى مع هذا التبسيط لتجربة المستخدم ، هناك ثلاث مشاكل في الاسترداد البسيط متعدد العناوين:
حل هذه المشاكل صعب. لحسن الحظ ، هناك حل أنيق يؤدي أداءً جيدًا بشكل معقول: بنية تفصل بين منطق التحقق من الصحة وحيازة الأصول.
يمكن تحقيق الإثبات بعدة طرق:
لإضافة الخصوصية إلى مثل هذا المخطط ، نقوم ببساطة بتشفير هذا المؤشر ، ثم نقوم بعمل جميع البراهين في ZK-SNARKs:
يمكن أن تصبح هذه السيناريوهات معقدة. على الجانب الإيجابي ، هناك العديد من أوجه التآزر المحتملة بينهما. على سبيل المثال ، يمكن لمفهوم "عقود مخزن المفاتيح" أن يحل أيضًا تحدي "العنوان" المذكور في القسم السابق: إذا أردنا أن يكون للمستخدمين عناوين دائمة لا تتغير في كل مرة يقوم فيها المستخدم بإعادة المفاتيح ، فيمكننا وضع عناوين التعريف المخفية ، يتم وضع مفاتيح التشفير والمعلومات الأخرى في عقد مخزن المفاتيح ، ويتم استخدام عنوان عقد مخزن المفاتيح باعتباره "عنوان" المستخدم.
يحتاج الكثير من البنية التحتية الثانوية إلى التحديث
استخدام ENS مكلف. اليوم ، في يونيو 2023 ، الأمور ليست بهذا السوء: رسوم المعاملات مرتفعة ، لكنها لا تزال قابلة للمقارنة برسوم مجال ENS. كلفني التسجيل في zuzalu.eth حوالي 27 دولارًا ، منها 11 دولارًا كانت رسوم المعاملات. ولكن إذا كان لدينا سوق صاعدة أخرى ، فسترتفع الرسوم بشدة. حتى بدون زيادة سعر ETH ، فإن إعادة رسوم الغاز إلى 200 gwei من شأنه أن يرفع رسوم TX لتسجيلات المجال إلى 104 دولارات. لذلك إذا أردنا أن يستخدم الأشخاص بالفعل ENS ، خاصةً في حالات الاستخدام مثل الوسائط الاجتماعية اللامركزية حيث يطلب المستخدمون تسجيلًا مجانيًا تقريبًا (ورسوم مجال ENS ليست مشكلة نظرًا لأن هذه الأنظمة الأساسية توفر لمستخدميها نطاقات فرعية) ، فنحن بحاجة إلى ENS في L2 للعمل .
لحسن الحظ ، صعد فريق ENS ويحدث ENS على L2! يوفر ERC-3668 (المعروف أيضًا باسم "معيار CCIP") ، جنبًا إلى جنب مع ENSIP-10 ، طريقة لجعل نطاقات ENS الفرعية على أي L2 قابلة للتحقق تلقائيًا. يتطلب معيار CCIP إنشاء عقد ذكي يصف طريقة للتحقق من إثباتات بيانات L2 ، وأن المجالات (مثل Optinames تستخدم ecc.eth) يمكن إخضاعها لسيطرة مثل هذا العقد. بمجرد أن يتحكم عقد CCIP في ecc.eth على L1 ، سيشمل الوصول إلى بعض subdomain.ecc.eth تلقائيًا البحث عن إثبات الحالة والتحقق منه (مثل فرع Merkle) في L2 حيث يتم تخزين هذا النطاق الفرعي المعين بالفعل.
إن جهود ENS CCIP هي قصة نجاح ، ويجب أن يُنظر إليها على أنها علامة على أن نوع الإصلاح الجذري الذي نحتاجه ممكن بالفعل. ولكن لا يزال هناك العديد من إصلاحات طبقة التطبيق التي يتعين القيام بها. بعض الأمثلة:
ستحتاج المحافظ إلى حماية الأصول والبيانات
اليوم ، تعمل المحافظ في حماية الأصول. كل شيء متصل بالسلسلة ، والشيء الوحيد الذي تحتاج المحفظة إلى حمايته هو المفاتيح الخاصة التي تؤمن هذه الأصول حاليًا. إذا قمت بتغيير مفتاحك ، يمكنك نشر مفتاحك الخاص السابق بأمان على الإنترنت في اليوم التالي. ومع ذلك ، في عالم ZK ، لم يعد هذا صحيحًا: لا تحمي المحفظة بيانات اعتماد المصادقة فحسب ، بل تحتفظ أيضًا ببياناتك.
لقد رأينا العلامات الأولى لهذا العالم مع Zupass ، وهو نظام الهوية المستند إلى ZK-SNARK الذي تستخدمه Zuzalu. يمتلك المستخدم مفتاحًا خاصًا للمصادقة على النظام ، والذي يمكن استخدامه لعمل أدلة أساسية مثل "إثبات أنني مقيم في Zuzalu دون الكشف عن أي واحد". لكن نظام Zupass بدأ أيضًا في إنشاء تطبيقات أخرى فوقه ، أبرزها ختم (إصدار Zupass من POAP).
الميزة الرئيسية التي تقدمها الطوابع مقارنة بـ POAP هي أن الطوابع خاصة: تحتفظ بالبيانات محليًا ، وإذا كنت تريد أن يكون لدى شخص ما معلومات عنك ، عليك فقط إثبات طابع (أو بعض الحسابات على طابع) لشخص ما. لكن هذا يزيد من المخاطر: إذا فقدت تلك المعلومات ، فستفقد الطابع.
بالطبع ، يمكن تقليل مشكلة الاحتفاظ بالبيانات إلى مشكلة الاحتفاظ بمفتاح تشفير واحد: يمكن لبعض الأطراف الثالثة (أو حتى السلسلة) الاحتفاظ بنسخة مشفرة من البيانات. يتمتع هذا بميزة ملائمة تتمثل في أن الإجراء الذي تتخذه لا يغير مفتاح التشفير ، لذلك لا يلزم أي تفاعل مع النظام الذي يحافظ على أمان مفتاح التشفير الخاص بك. ولكن حتى ذلك الحين ، إذا فقدت مفتاح التشفير ، فستفقد كل شيء. من ناحية أخرى ، إذا رأى شخص ما مفتاح التشفير الخاص بك ، فيمكنه رؤية كل شيء مشفر بهذا المفتاح.
يتمثل الحل العملي لـ Zupass في تشجيع الأشخاص على تخزين مفاتيحهم على أجهزة متعددة (مثل الكمبيوتر المحمول والهاتف) ، نظرًا لأن فرص فقدانهم للوصول إليها جميعًا في نفس الوقت ضئيلة. يمكننا الذهاب إلى أبعد من ذلك واستخدام مشاركة سرية لتخزين المفاتيح ، الموزعة بين الأوصياء المتعددين.
هذا التعافي الاجتماعي عبر MPC ليس حلاً مناسبًا للمحافظ ، لأنه لا يعني فقط أن الأوصياء الحاليين ولكن الأوصياء السابقين أيضًا يمكن أن يتواطأوا لسرقة أصولك ، وهي مخاطرة عالية بشكل غير مقبول. لكن خطر خرق الخصوصية عادة ما يكون أقل من إجمالي مخاطر فقدان الأصول ، ويمكن للأشخاص الذين لديهم حالات استخدام عالية للخصوصية أن يقبلوا دائمًا مخاطر أعلى للخسارة من خلال عدم نسخ المفاتيح المرتبطة بهذه العمليات التي تتطلب الخصوصية احتياطيًا.
لتجنب إغراق المستخدمين بالأنظمة البيزنطية بمسارات استرداد متعددة ، قد تحتاج المحافظ التي تدعم التعافي الاجتماعي إلى إدارة استرداد الأصول واسترداد مفتاح التشفير.
العودة إلى الهوية
أحد الأشياء المشتركة بين هذه التغييرات هو أن مفهوم "العنوان" ، معرف التشفير الذي تستخدمه لتمثيل "أنت" على السلسلة ، يجب أن يتغير بشكل أساسي. لن تكون "إرشادات حول كيفية التفاعل معي" مجرد عنوان ETH ؛ يجب أن تكون مزيجًا من عناوين متعددة في L2s متعددة وعناوين وصفية متخفية ومفاتيح تشفير وبيانات أخرى في شكل ما.
تتمثل إحدى الطرق في جعل ENS هويتك: يمكن أن يحتوي سجل ENS الخاص بك فقط على كل هذه المعلومات ، وإذا أرسلت شخصًا ما bob.eth (أو bob.ecc.eth ، أو ...) ، فيمكنه البحث ورؤية كل شيء عن الكيفية إنه يدفع لك ويتفاعل معك ، بما في ذلك طرق أكثر تعقيدًا عبر المجالات والحفاظ على الخصوصية.
لكن هذا النهج المتمحور حول ENS له نقطتا ضعف:
يتمثل أحد الحلول الممكنة في وضع المزيد من المحتوى في عقد مخزن المفاتيح المذكور في الهندسة المعمارية سابقًا في هذه المقالة. يمكن أن يحتوي عقد مخزن المفاتيح على جميع أنواع المعلومات عنك وكيفية تفاعلك معها (بالنسبة إلى CCIP ، قد تكون بعض هذه المعلومات خارج السلسلة) ، وسيستخدم المستخدمون عقد تخزين المفاتيح كمعرف أساسي لهم. لكن الأصول الفعلية التي يتلقونها سيتم تخزينها في أماكن مختلفة. تعتبر عقود Keystore حيادية الاسم ، وهي صديقة للواقع المضاد: يمكنك إنشاء عنوان يمكن إثبات تهيئته فقط من خلال عقد keystore مع بعض المعلمات الأولية الثابتة.
هناك نوع آخر من الحلول مشابه لبروتوكول دفع Bitcoin ، حيث يتخلى تمامًا عن مفهوم العناوين الموجهة للمستخدم. تتمثل إحدى الأفكار في الاعتماد أكثر على قنوات الاتصال المباشر بين المرسل والمستلم ؛ على سبيل المثال ، يمكن للمرسل إرسال رابط مطالبة (كعنوان URL صريح أو رمز QR) يمكن للمستلم استخدامه لمتابعة استعداده لقبول الدفع.
في كل هذه التصميمات ، يعد جعل الأشياء منفصلة ويسهل على المستخدمين فهمها هو الأهم. نحتاج إلى التأكد من أن المستخدمين لديهم وصول سهل إلى أحدث طريقة عرض لماهية أصولهم الحالية والأخبار المنشورة لهم. يجب أن تعتمد وجهات النظر هذه على الأدوات المفتوحة ، وليس الحلول الاحتكارية. إن الحفاظ على البنية التحتية للدفع الأكثر تعقيدًا من أن تصبح "برجًا تجريدًا" مبهمًا حيث يواجه المطورون صعوبة في فهم ما يجري وتكييفه مع البيئة الجديدة سيتطلب عملاً شاقًا. على الرغم من التحديات ، فإن تحقيق قابلية التوسع وأمن المحفظة والخصوصية للمستخدمين العاديين أمر بالغ الأهمية لمستقبل Ethereum. لا يتعلق الأمر فقط بالجدوى الفنية ، بل يتعلق بإمكانية الوصول الفعلية للمستخدم العادي. نحن بحاجة للارتقاء إلى مستوى هذا التحدي.