رؤية المحفظة المثالية لإثيريوم: ترقية شاملة من تجربة عبر السلاسل إلى حماية الخصوصية

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

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

تجربة المستخدم في عبر السلاسل L2

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

الفكرة الأساسية هي: (1) تضمين وظيفة إرسال عبر السلاسل L2، (2) عنوان محدد لل سلسلة وطلب دفع. يجب أن توفر المحفظة للمستخدمين عنوانًا يتوافق مع أسلوب مسودة ERC المحددة.

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

• إذا كان هناك ما يكفي من الرموز المطلوبة على سلسلة الهدف، قم بإرسالها مباشرة.
• إذا كان هناك رموز مطلوبة على سلاسل أخرى، استخدم بروتوكول DEX عبر السلاسل مشابه لـ ERC-7683 للإرسال.
• إذا كان هناك أنواع مختلفة من الرموز على نفس السلسلة أو على سلاسل أخرى، يجب استخدام DEX لتحويلها إلى النوع الصحيح وإرسالها، ويتطلب ذلك إذنًا واضحًا من المستخدم.

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

يمكن أيضًا إدراج طلب الدفع المحدد على السلسلة في رمز الاستجابة السريعة ليتم مسحه بواسطة المحفظة المتنقلة. في سيناريوهات الدفع وجهًا لوجه أو عبر الإنترنت، يمكن للجهة المستقبلة إصدار رمز استجابة سريعة أو استدعاء API ويب 3 يشير إلى "أحتاج إلى وحدة Y من الرمز Z على سلسلة X، مع معرف مرجعي W"، ويمكن للمحفظة تلبية هذا الطلب بشكل مرن. خيار آخر هو بروتوكول رابط المطالبة، حيث تقوم محفظة المستخدم بإنشاء رمز استجابة سريعة أو عنوان URL يتضمن تفويض المطالبة، ويتحمل الطرف المستلم مسؤولية نقل الأموال إلى محفظته.

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

أمان الحساب

طريقة جيدة لتصور أمان الحساب هي أن المحفظة الممتازة يجب أن تعمل في جانبين: ( حماية المستخدمين من هجمات القراصنة أو الأفعال الخبيثة من مطوري المحفظة، ) حماية المستخدمين من تأثير أخطائهم الخاصة.

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

هذا هو التصميم الأساسي، ويمكن توسيعه. يمكن أن تساعد آلية المفاتيح السرية وERC-7715 وغيرها من آليات الأذونات في تحقيق توازن بين الراحة والأمان في التطبيقات المختلفة. يمكن أن تزيد الهياكل المعقدة للحراس، مثل وجود فترات قفل زمنية متعددة تحت عتبات مختلفة، من فرص استعادة الحسابات الشرعية بنجاح، مع تقليل مخاطر السرقة.

( اختيار الوصي

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

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

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

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

لحسن الحظ، مع ZK-SNARK، لدينا أيضًا الخيار الرابع: الهوية المركزية المغلفة بـ ZK. تشمل هذه الأنواع zk-email و Anon Aadhaar و Myna Wallet وغيرها. بشكل أساسي، يمكن اعتماد أشكال متعددة من الهوية المركزية ( للشركات أو الحكومات ) وتحويلها إلى عنوان إثيريوم، ويمكن للمستخدمين فقط إرسال المعاملات من خلال إنشاء إثبات ZK-SNARK يمتلك هوية مركزية.

تتمتع معرفات المركزية المغلفة بتقنية ZK ب"سهولة الاستخدام للمبتدئين" الفريدة. لتحقيق ذلك، يتطلب الأمر واجهة مستخدم مبسطة ومتكاملة: يجب على المستخدم فقط تحديد "example@gmail.com" كوصي، وينبغي أن يتم إنشاء عنوان zk-email الخاص بإيثريوم تلقائيًا في الخلفية. يجب أن يكون بإمكان المستخدمين المتقدمين إدخال بريدهم الإلكتروني ( وأي ملح خصوصية تم حفظه ) في تطبيقات الطرف الثالث مفتوحة المصدر، وتأكيد أن العنوان الناتج صحيح. وينبغي أن يكون الأمر نفسه مع أي نوع آخر من الوكلاء المدعومين.

يجب ملاحظة أن zk-email يواجه حاليًا تحديًا عمليًا يتمثل في اعتماده على توقيع DKIM، الذي يستخدم مفاتيح يتم تغييرها كل بضعة أشهر، وهذه المفاتيح نفسها لم يتم توقيعها من قبل أي جهة أخرى. وهذا يعني أن zk-email اليوم يحتاج إلى ثقة معينة في المزود نفسه؛ إذا استخدم zk-email TLSNotary للتحقق من المفاتيح المحدثة على الأجهزة الموثوقة، يمكن تقليل هذه الحالة، ولكن هذا ليس مثاليًا. نأمل أن تبدأ مزودات البريد الإلكتروني في توقيع مفاتيح DKIM الخاصة بها مباشرة. في الوقت الحالي، يُوصى باستخدام zk-email كوصي، لكن لا يُنصح باستخدامه من قبل معظم الوصاة: لا تخزن الأموال في إعداد حيث يعني تلف zk-email عدم القدرة على الوصول إلى الأموال.

( مستخدم جديد و المحفظة داخل التطبيق

المستخدمون الجدد في الواقع لا يرغبون في إدخال عدد كبير من الوكلاء عند التسجيل لأول مرة. لذلك، يجب أن توفر المحفظة لهم خيارًا بسيطًا جدًا. طريقة طبيعية هي استخدام zk-email على عنوان بريدهم الإلكتروني، والمفتاح المخزن محليًا على جهاز المستخدم ) قد يكون المفتاح الشامل ### ومفتاح النسخ الاحتياطي الذي تحتفظ به المزود، لإجراء اختيار 2 من 3. مع تراكم المزيد من الخبرة أو الأصول للمستخدمين، ينبغي في مرحلة ما تحفيزهم لإضافة المزيد من الوكلاء.

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

( حماية المستخدمين من الاحتيال والتهديدات الخارجية الأخرى

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

![فيتاليك: رؤية المحفظة المثالية، من تجربة عبر السلاسل إلى ترقية شاملة لحماية الخصوصية])https://img-cdn.gateio.im/webp-social/moments-9852b894445658cf6d25e8e105ea1445.webp###

الخصوصية

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

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

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

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

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