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

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

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

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

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

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

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

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

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

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

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

أمان الحساب

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

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

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

اختيار الوصي

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

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

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

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

لحسن الحظ، مع 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. مع اكتساب المستخدمين المزيد من الخبرة أو تراكم المزيد من الأصول، ينبغي في وقت ما تنبيههم لإضافة المزيد من الأوصياء.

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

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

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

الخصوصية

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

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

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

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