رؤية المحفظة المثالية لإثيريوم: ترقية شاملة من تجربة عبر السلاسل إلى حماية الخصوصية
إحدى الطبقات الأساسية في بنية إثيريوم التحتية هي المحفظة، ولكنها غالبًا ما يتم التقليل من قيمتها من قبل الباحثين والمطورين الرئيسيين من المستوى الأول. المحفظة هي النافذة بين المستخدم وعالم إثيريوم، حيث يمكن للمستخدمين الاستفادة فقط من أي خصائص لامركزية أو مقاومة للرقابة أو أمان أو خصوصية أو غيرها من الخصائص التي تقدمها إثيريوم وتطبيقاتها، بشرط أن تكون المحفظة نفسها تتمتع بهذه الخصائص.
مؤخراً، حققت محفظة إثيريوم تقدمًا كبيرًا في تحسين تجربة المستخدم والأمان والوظائف. الغرض من هذه المقالة هو تقديم بعض الآراء حول الخصائص التي ينبغي أن تمتلكها المحفظة المثالية لإثيريوم. هذه ليست قائمة كاملة؛ بل تعكس ميول القراصنة المشفرة، مع التركيز على الأمان والخصوصية، ومن المؤكد تقريبًا أنها غير مكتملة من حيث تجربة المستخدم. ومع ذلك، فإن قائمة الأمنيات في تحسين تجربة المستخدم ليست فعالة مثل نشر وتكرار بناءً على الملاحظات، لذلك فإن التركيز على خصائص الأمان والخصوصية هو الأكثر قيمة.
تجربة المستخدم في交易 عبر السلاسل L2
الآن يوجد خارطة طريق أكثر تفصيلاً لتحسين تجربة المستخدم عبر السلاسل L2، تحتوي هذه الخارطة على جزء قصير المدى وجزء طويل المدى. هنا سنتحدث عن الجزء قصير المدى: الأفكار التي يمكن تنفيذها نظرياً حتى اليوم.
الفكرة الأساسية هي (i) إدماج إرسال عبر L2، وكذلك (ii) عنوان محدد على السلسلة وطلبات الدفع. يجب أن تكون المحفظة قادرة على تقديم عنوان للمستخدم، متبعة أسلوب مسودات ERC ذات الصلة.
عندما يقدم شخص ما ( أو بعض التطبيقات ) عنوانًا بهذا التنسيق للمستخدم، يجب أن يكون المستخدم قادرًا على لصقه في حقل "المستلم" في المحفظة، ثم النقر على "إرسال". يجب على المحفظة معالجة البيانات المرسلة تلقائيًا بأي شكل ممكن:
إذا كان لدى المستخدم بالفعل ما يكفي من نوع الرموز المطلوبة على السلسلة المستهدفة، يرجى إرسال الرموز مباشرة.
إذا كان لدى المستخدم نوع العملة المطلوبة على سلسلة أخرى ( أو عدة سلاسل أخرى )، فإن استخدام البروتوكول المعني ( يعد في الواقع DEX عبر السلاسل ) لإرسال العملات.
إذا كان لدى المستخدم أنواع مختلفة من الرموز على نفس السلسلة أو سلاسل أخرى، يجب استخدام بورصات لامركزية لتحويلها إلى العملات الصحيحة من النوع الصحيح على السلسلة الصحيحة وإرسالها. يجب أن يتطلب هذا إذنًا صريحًا من المستخدم: سيرى المستخدم مقدار الرسوم التي دفعها، بالإضافة إلى مقدار الرسوم التي تلقاها المستلم.
المحتوى أعلاه ينطبق على "يجب على المستخدم نسخ ولصق العنوان ( أو ENS، على سبيل المثال، vitalik.eth @ optimism.eth) إذا كان شخص ما يدفع للمستخدم" حالة الاستخدام. إذا طلب dapp إيداع، فإن العملية المثالية هي توسيع واجهة برمجة تطبيقات web3 والسماح لـ dapp بإصدار طلبات الدفع الخاصة بالسلاسل. بعد ذلك، ستتمكن المحفظة من تلبية هذا الطلب بأي طريقة مطلوبة. لتحسين تجربة المستخدم، يجب أيضًا توحيد طلب getAvailableBalance، ويجب على المحفظة أن تأخذ في الاعتبار بجدية السلاسل التي سيتم تخزين أصول المستخدمين عليها بشكل افتراضي، من أجل زيادة الأمان وسهولة التحويل.
يمكن أيضًا إدخال طلبات الدفع المحددة بسلسلة في رمز الاستجابة السريعة، حيث يمكن للمحفظة المحمولة مسح رمز الاستجابة السريعة. في سيناريوهات الدفع من المستهلكين وجهًا لوجه ( أو عبر الإنترنت )، سيصدر المستلم رمز QR أو استدعاء API من web3، مما يدل على "أريد X وحدة من رموز YZ على السلسلة، مع معرف مرجعي أو استدعاء W"، وستكون المحفظة قادرة على تلبية هذا الطلب بحرية بأي طريقة. خيار آخر هو بروتوكول رابط المطالبة، حيث تقوم محفظة المستخدم بإنشاء رمز QR أو URL يحتوي على تفويض المطالبة للحصول على مبلغ معين من الأموال من عقدهم على السلسلة، وعمل المستلم هو معرفة كيفية نقل هذه الأموال إلى محفظتهم الخاصة.
موضوع آخر ذو صلة هو دفع الغاز. إذا تلقى المستخدم الأصول على L2 بدون وجود ETH، ويحتاج إلى إرسال معاملة على ذلك L2، يجب أن تكون المحفظة قادرة على استخدام البروتوكول تلقائيًا لدفع الغاز على السلسلة في الأماكن التي يمتلك فيها المستخدم ETH. إذا كانت المحفظة ترغب في أن يقوم المستخدم بعمليات أكثر في المستقبل على L2، يجب عليها أيضًا استخدام DEX فقط للإرسال، على سبيل المثال، قيمة ETH التي تبلغ عدة ملايين من الغاز، حتى تتمكن المعاملات المستقبلية من إنفاق الغاز مباشرة هناك لأنه سيكون أرخص.
أمان الحساب
إحدى طرق تصور التحديات الأمنية للحساب هي أن المحفظة الجيدة يجب أن تعمل في جانبين: (i) حماية المستخدم من هجمات القرصنة أو الهجمات الخبيثة من مطوري المحفظة، و (ii) حماية المستخدم من تأثير أخطائه الخاصة.
الحل المفضل لذلك، على مدى أكثر من عشر سنوات، كان استعادة الحسابات الاجتماعية والمحافظ متعددة التوقيع، مع التحكم في الوصول المتدرج. تحتوي حسابات المستخدمين على طبقتين من المفاتيح: المفتاح الرئيسي و N من الأوصياء ( على سبيل المثال N = 5). المفتاح الرئيسي هو القادر على إجراء العمليات ذات القيمة المنخفضة وغير المالية. يحتاج معظم الأوصياء إلى تنفيذ (i) العمليات عالية القيمة، مثل إرسال القيمة الكاملة في الحساب، أو (ii) تغيير المفتاح الرئيسي أو أي وصي. إذا لزم الأمر، يمكن السماح للمفتاح الرئيسي بتنفيذ العمليات عالية القيمة من خلال قفل زمني.
هذه هي التصميمات الأساسية، ويمكن توسيعها. يمكن أن تساعد مفاتيح الجلسة وآليات الأذونات ذات الصلة في دعم التوازن بين الراحة والأمان في التطبيقات المختلفة. يمكن أن تساعد الهياكل المعقدة للوصي، مثل تلك التي تحتوي على فترات قفل زمنية متعددة تحت عتبات مختلفة، في زيادة فرص استعادة الحسابات الشرعية بنجاح، مع تقليل مخاطر السرقة إلى الحد الأدنى.
من يجب أن يكون الوصي أو ما هو؟
بالنسبة لمستخدمي العملات المشفرة ذوي الخبرة في مجتمع المستخدمين المتمرسين، فإن خيارًا قابلاً للتطبيق هو مفاتيح الأصدقاء والعائلة للمستخدم. إذا طلب المستخدم من الجميع تزويده بعنوان جديد، فلن يحتاج أحد إلى معرفة من هم - في الواقع، حتى الوصي على المستخدم لا يحتاج إلى معرفة من هم بعضهم البعض. إذا لم يقوموا بإخطار المستخدم، فإن احتمال تآمرهم ضئيل. ومع ذلك، فإن هذا الخيار غير متاح لمعظم المستخدمين الجدد.
الخيار الثاني هو الوصي المؤسسي: الشركات التي تقدم خدمة توقيع المعاملات فقط عند استلام طلب من المستخدم لمعلومات تأكيد أخرى: مثل رمز التأكيد، أو مكالمة فيديو للمستخدمين ذوي القيمة العالية. لقد حاول الناس منذ فترة طويلة إنشاء هذه، مثل تقديم CryptoCorp في عام 2013. ومع ذلك، حتى الآن، لم تكن هذه الشركات ناجحة جدًا.
الخيار الثالث هو أجهزة شخصية متعددة ( مثل الهواتف، أجهزة الكمبيوتر المكتبية، والمحفظة الصلبة ). يمكن أن تعمل هذه الطريقة، لكنها قد تكون صعبة الإعداد والإدارة للمستخدمين غير المتمرسين. هناك أيضًا خطر فقدان الأجهزة أو سرقتها في نفس الوقت، خاصةً عندما تكون في نفس الموقع.
مؤخراً، بدأنا نرى المزيد من الحلول المعتمدة على المفتاح الشامل. يمكن نسخ المفتاح احتياطيًا فقط على جهاز المستخدم، مما يجعله حل جهاز شخصي، ويمكن أيضًا نسخه احتياطيًا في السحابة، مما يجعل أمانه يعتمد على افتراضات معقدة حول أمان كلمة المرور المختلطة، والمؤسسات، والأجهزة الموثوقة. في الواقع، المفتاح هو إضافة أمنية قيمة للمستخدمين العاديين، لكن الاعتماد عليها وحدها ليس كافيًا لحماية مدخرات المستخدم مدى الحياة.
لحسن الحظ، مع ZK-SNARK، لدينا خيار رابع: هوية مركزية محمولة بواسطة ZK. هذا النوع يشمل zk-email، Anon Aadhaar، Myna Wallet، وغيرها. بشكل أساسي، يمكن للمستخدمين استخدام أشكال متعددة ( للشركات أو الحكومة ) الهوية المركزية، وتحويلها إلى عنوان إثيريوم، حيث يمكن للمستخدمين إرسال المعاملات فقط من خلال إنشاء دليل يثبت ملكية الهوية المركزية باستخدام ZK-SNARK.
مع هذا الإضافة، أصبح لدينا الآن مجموعة واسعة من الخيارات، ويمتاز ID المركزي المحزم بـ ZK ب"صداقة المبتدئين" الفريدة.
لتحقيق ذلك، يحتاج إلى تنفيذ واجهة مستخدم مبسطة ومتكاملة: يجب أن يكون المستخدمون قادرين فقط على تحديد رغبتهم في استخدام "example@gmail.com" كوصي، ويجب أن يتم إنشاء عنوان zk-email إيثيريوم المقابل تلقائيًا تحت الغطاء. يجب أن يكون المستخدمون المتقدمون قادرين على إدخال بريدهم الإلكتروني ( وأي قيم ملح خصوصية قد تكون محفوظة في هذا البريد الإلكتروني ) في تطبيقات الطرف الثالث مفتوحة المصدر، وتأكيد أن العنوان الناتج صحيح. ينبغي أن يكون الأمر نفسه بالنسبة لأي نوع آخر من الوصايا المدعومة.
يرجى ملاحظة أن zk-email تواجه اليوم تحديًا عمليًا يتمثل في اعتمادها على توقيع DKIM، الذي يستخدم مفتاحًا يتغير كل بضعة أشهر، وهذه المفاتيح نفسها لم يتم توقيعها من قبل أي جهة أخرى. وهذا يعني أن zk-email اليوم تتطلب درجة معينة من الثقة تتجاوز مزود الخدمة نفسه؛ إذا استخدمت zk-email TLSNotary للتحقق من المفاتيح المحدثة داخل الأجهزة الموثوقة، يمكن تقليل هذا الأمر، ولكن هذا ليس مثاليًا. نأمل أن تبدأ مزودات البريد الإلكتروني في توقيع مفاتيح DKIM الخاصة بها مباشرة. اليوم، يُنصح وصي باستخدام zk-email، ولكن لا يُنصح معظم الأوصياء بذلك: عدم تخزين الأموال في zk-email يعني أن الإعداد الذي يتعذر على المستخدمين استخدام أموالهم.
المستخدمون الجدد والمحفظة داخل التطبيق
المستخدمون الجدد في الواقع لا يرغبون في إدخال عدد كبير من الأوصياء عند التسجيل لأول مرة. لذلك، يجب أن توفر المحفظة خيارًا بسيطًا للغاية لهم. إحدى الطرق الطبيعية هي استخدام zk-email على عنوان بريدهم الإلكتروني، مع مفتاح ( المخزن محليًا على جهاز المستخدم والذي قد يكون مفتاحًا شاملاً ) ومفتاح النسخ الاحتياطي المحتفظ به من قبل المزود، لإجراء اختيار 2 من 3. مع تزايد خبرة المستخدم أو تراكم المزيد من الأصول، يجب في مرحلة ما أن يتم تحفيزهم لإضافة المزيد من الأوصياء.
المحفظة المدمجة في التطبيقات أمر لا مفر منه، لأن التطبيقات التي تحاول جذب المستخدمين غير المشفرين لا ترغب في أن يقوم المستخدمون بتنزيل تطبيقين جديدين في وقت واحد ( تطبيق نفسه، بالإضافة إلى المحفظة ايثر ) مما يؤدي إلى تجربة مستخدم مربكة. ومع ذلك، ينبغي أن يكون لدى العديد من مستخدمي محافظ التطبيقات القدرة على ربط جميع محافظهم معًا، بحيث يحتاجون فقط إلى القلق بشأن "مشكلة التحكم في الوصول" واحدة. أبسط طريقة هي اعتماد خطة هرمية، حيث توجد عملية "رابط" سريعة، تتيح للمستخدمين تعيين محفظتهم الرئيسية كوصي على جميع محافظ التطبيقات الداخلية. بعض العملاء قد دعموا ذلك بالفعل.
بشكل افتراضي، قد يتم التحكم في استعادة بعض حسابات المستخدمين داخل التطبيق بواسطة فريق تطوير التطبيق. ومع ذلك، يمكن للمستخدمين "استعادة" حساباتهم وتغيير الاستعادة إلى عنوانهم الخاص.
حماية المستخدمين من الاحتيال والتهديدات الخارجية الأخرى
بالإضافة إلى أمان الحساب، فإن المحفظة الحالية تقوم بالكثير من العمل لتحديد العناوين المزيفة، والمخادعة، والاحتيال، وغيرها من التهديدات الخارجية، وتسعى جهدها لحماية المستخدمين من هذه التهديدات. في الوقت نفسه، لا تزال العديد من التدابير بدائية إلى حد ما: على سبيل المثال، تتطلب النقر لإرسال ايثر أو رموز أخرى إلى أي عنوان جديد، بغض النظر عما إذا كان المستخدم يرسل 100 دولار أم لا.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 13
أعجبني
13
6
مشاركة
تعليق
0/400
HackerWhoCares
· 07-28 09:01
يجب أن نأخذ في الاعتبار الأمان والتجربة معًا.
شاهد النسخة الأصليةرد0
BoredWatcher
· 07-28 08:33
المحفظة كان يجب أن يتم ترقيتها منذ زمن!
شاهد النسخة الأصليةرد0
TokenUnlocker
· 07-25 09:53
المحفظة才是第一生产力！
شاهد النسخة الأصليةرد0
BottomMisser
· 07-25 09:53
الأمان؟ التحديثات المتكررة؟ دع المحفظة لا تُسرق أولاً ثم نتحدث.
محفظة إثيريوم المثالية: تجربة عبر السلاسل، ترقية شاملة في الأمان والخصوصية
رؤية المحفظة المثالية لإثيريوم: ترقية شاملة من تجربة عبر السلاسل إلى حماية الخصوصية
إحدى الطبقات الأساسية في بنية إثيريوم التحتية هي المحفظة، ولكنها غالبًا ما يتم التقليل من قيمتها من قبل الباحثين والمطورين الرئيسيين من المستوى الأول. المحفظة هي النافذة بين المستخدم وعالم إثيريوم، حيث يمكن للمستخدمين الاستفادة فقط من أي خصائص لامركزية أو مقاومة للرقابة أو أمان أو خصوصية أو غيرها من الخصائص التي تقدمها إثيريوم وتطبيقاتها، بشرط أن تكون المحفظة نفسها تتمتع بهذه الخصائص.
مؤخراً، حققت محفظة إثيريوم تقدمًا كبيرًا في تحسين تجربة المستخدم والأمان والوظائف. الغرض من هذه المقالة هو تقديم بعض الآراء حول الخصائص التي ينبغي أن تمتلكها المحفظة المثالية لإثيريوم. هذه ليست قائمة كاملة؛ بل تعكس ميول القراصنة المشفرة، مع التركيز على الأمان والخصوصية، ومن المؤكد تقريبًا أنها غير مكتملة من حيث تجربة المستخدم. ومع ذلك، فإن قائمة الأمنيات في تحسين تجربة المستخدم ليست فعالة مثل نشر وتكرار بناءً على الملاحظات، لذلك فإن التركيز على خصائص الأمان والخصوصية هو الأكثر قيمة.
تجربة المستخدم في交易 عبر السلاسل L2
الآن يوجد خارطة طريق أكثر تفصيلاً لتحسين تجربة المستخدم عبر السلاسل L2، تحتوي هذه الخارطة على جزء قصير المدى وجزء طويل المدى. هنا سنتحدث عن الجزء قصير المدى: الأفكار التي يمكن تنفيذها نظرياً حتى اليوم.
الفكرة الأساسية هي (i) إدماج إرسال عبر L2، وكذلك (ii) عنوان محدد على السلسلة وطلبات الدفع. يجب أن تكون المحفظة قادرة على تقديم عنوان للمستخدم، متبعة أسلوب مسودات ERC ذات الصلة.
عندما يقدم شخص ما ( أو بعض التطبيقات ) عنوانًا بهذا التنسيق للمستخدم، يجب أن يكون المستخدم قادرًا على لصقه في حقل "المستلم" في المحفظة، ثم النقر على "إرسال". يجب على المحفظة معالجة البيانات المرسلة تلقائيًا بأي شكل ممكن:
المحتوى أعلاه ينطبق على "يجب على المستخدم نسخ ولصق العنوان ( أو ENS، على سبيل المثال، vitalik.eth @ optimism.eth) إذا كان شخص ما يدفع للمستخدم" حالة الاستخدام. إذا طلب dapp إيداع، فإن العملية المثالية هي توسيع واجهة برمجة تطبيقات web3 والسماح لـ dapp بإصدار طلبات الدفع الخاصة بالسلاسل. بعد ذلك، ستتمكن المحفظة من تلبية هذا الطلب بأي طريقة مطلوبة. لتحسين تجربة المستخدم، يجب أيضًا توحيد طلب getAvailableBalance، ويجب على المحفظة أن تأخذ في الاعتبار بجدية السلاسل التي سيتم تخزين أصول المستخدمين عليها بشكل افتراضي، من أجل زيادة الأمان وسهولة التحويل.
يمكن أيضًا إدخال طلبات الدفع المحددة بسلسلة في رمز الاستجابة السريعة، حيث يمكن للمحفظة المحمولة مسح رمز الاستجابة السريعة. في سيناريوهات الدفع من المستهلكين وجهًا لوجه ( أو عبر الإنترنت )، سيصدر المستلم رمز QR أو استدعاء API من web3، مما يدل على "أريد X وحدة من رموز YZ على السلسلة، مع معرف مرجعي أو استدعاء W"، وستكون المحفظة قادرة على تلبية هذا الطلب بحرية بأي طريقة. خيار آخر هو بروتوكول رابط المطالبة، حيث تقوم محفظة المستخدم بإنشاء رمز QR أو URL يحتوي على تفويض المطالبة للحصول على مبلغ معين من الأموال من عقدهم على السلسلة، وعمل المستلم هو معرفة كيفية نقل هذه الأموال إلى محفظتهم الخاصة.
موضوع آخر ذو صلة هو دفع الغاز. إذا تلقى المستخدم الأصول على L2 بدون وجود ETH، ويحتاج إلى إرسال معاملة على ذلك L2، يجب أن تكون المحفظة قادرة على استخدام البروتوكول تلقائيًا لدفع الغاز على السلسلة في الأماكن التي يمتلك فيها المستخدم ETH. إذا كانت المحفظة ترغب في أن يقوم المستخدم بعمليات أكثر في المستقبل على L2، يجب عليها أيضًا استخدام DEX فقط للإرسال، على سبيل المثال، قيمة ETH التي تبلغ عدة ملايين من الغاز، حتى تتمكن المعاملات المستقبلية من إنفاق الغاز مباشرة هناك لأنه سيكون أرخص.
أمان الحساب
إحدى طرق تصور التحديات الأمنية للحساب هي أن المحفظة الجيدة يجب أن تعمل في جانبين: (i) حماية المستخدم من هجمات القرصنة أو الهجمات الخبيثة من مطوري المحفظة، و (ii) حماية المستخدم من تأثير أخطائه الخاصة.
الحل المفضل لذلك، على مدى أكثر من عشر سنوات، كان استعادة الحسابات الاجتماعية والمحافظ متعددة التوقيع، مع التحكم في الوصول المتدرج. تحتوي حسابات المستخدمين على طبقتين من المفاتيح: المفتاح الرئيسي و N من الأوصياء ( على سبيل المثال N = 5). المفتاح الرئيسي هو القادر على إجراء العمليات ذات القيمة المنخفضة وغير المالية. يحتاج معظم الأوصياء إلى تنفيذ (i) العمليات عالية القيمة، مثل إرسال القيمة الكاملة في الحساب، أو (ii) تغيير المفتاح الرئيسي أو أي وصي. إذا لزم الأمر، يمكن السماح للمفتاح الرئيسي بتنفيذ العمليات عالية القيمة من خلال قفل زمني.
هذه هي التصميمات الأساسية، ويمكن توسيعها. يمكن أن تساعد مفاتيح الجلسة وآليات الأذونات ذات الصلة في دعم التوازن بين الراحة والأمان في التطبيقات المختلفة. يمكن أن تساعد الهياكل المعقدة للوصي، مثل تلك التي تحتوي على فترات قفل زمنية متعددة تحت عتبات مختلفة، في زيادة فرص استعادة الحسابات الشرعية بنجاح، مع تقليل مخاطر السرقة إلى الحد الأدنى.
من يجب أن يكون الوصي أو ما هو؟
بالنسبة لمستخدمي العملات المشفرة ذوي الخبرة في مجتمع المستخدمين المتمرسين، فإن خيارًا قابلاً للتطبيق هو مفاتيح الأصدقاء والعائلة للمستخدم. إذا طلب المستخدم من الجميع تزويده بعنوان جديد، فلن يحتاج أحد إلى معرفة من هم - في الواقع، حتى الوصي على المستخدم لا يحتاج إلى معرفة من هم بعضهم البعض. إذا لم يقوموا بإخطار المستخدم، فإن احتمال تآمرهم ضئيل. ومع ذلك، فإن هذا الخيار غير متاح لمعظم المستخدمين الجدد.
الخيار الثاني هو الوصي المؤسسي: الشركات التي تقدم خدمة توقيع المعاملات فقط عند استلام طلب من المستخدم لمعلومات تأكيد أخرى: مثل رمز التأكيد، أو مكالمة فيديو للمستخدمين ذوي القيمة العالية. لقد حاول الناس منذ فترة طويلة إنشاء هذه، مثل تقديم CryptoCorp في عام 2013. ومع ذلك، حتى الآن، لم تكن هذه الشركات ناجحة جدًا.
الخيار الثالث هو أجهزة شخصية متعددة ( مثل الهواتف، أجهزة الكمبيوتر المكتبية، والمحفظة الصلبة ). يمكن أن تعمل هذه الطريقة، لكنها قد تكون صعبة الإعداد والإدارة للمستخدمين غير المتمرسين. هناك أيضًا خطر فقدان الأجهزة أو سرقتها في نفس الوقت، خاصةً عندما تكون في نفس الموقع.
مؤخراً، بدأنا نرى المزيد من الحلول المعتمدة على المفتاح الشامل. يمكن نسخ المفتاح احتياطيًا فقط على جهاز المستخدم، مما يجعله حل جهاز شخصي، ويمكن أيضًا نسخه احتياطيًا في السحابة، مما يجعل أمانه يعتمد على افتراضات معقدة حول أمان كلمة المرور المختلطة، والمؤسسات، والأجهزة الموثوقة. في الواقع، المفتاح هو إضافة أمنية قيمة للمستخدمين العاديين، لكن الاعتماد عليها وحدها ليس كافيًا لحماية مدخرات المستخدم مدى الحياة.
لحسن الحظ، مع ZK-SNARK، لدينا خيار رابع: هوية مركزية محمولة بواسطة ZK. هذا النوع يشمل zk-email، Anon Aadhaar، Myna Wallet، وغيرها. بشكل أساسي، يمكن للمستخدمين استخدام أشكال متعددة ( للشركات أو الحكومة ) الهوية المركزية، وتحويلها إلى عنوان إثيريوم، حيث يمكن للمستخدمين إرسال المعاملات فقط من خلال إنشاء دليل يثبت ملكية الهوية المركزية باستخدام ZK-SNARK.
مع هذا الإضافة، أصبح لدينا الآن مجموعة واسعة من الخيارات، ويمتاز ID المركزي المحزم بـ ZK ب"صداقة المبتدئين" الفريدة.
لتحقيق ذلك، يحتاج إلى تنفيذ واجهة مستخدم مبسطة ومتكاملة: يجب أن يكون المستخدمون قادرين فقط على تحديد رغبتهم في استخدام "example@gmail.com" كوصي، ويجب أن يتم إنشاء عنوان zk-email إيثيريوم المقابل تلقائيًا تحت الغطاء. يجب أن يكون المستخدمون المتقدمون قادرين على إدخال بريدهم الإلكتروني ( وأي قيم ملح خصوصية قد تكون محفوظة في هذا البريد الإلكتروني ) في تطبيقات الطرف الثالث مفتوحة المصدر، وتأكيد أن العنوان الناتج صحيح. ينبغي أن يكون الأمر نفسه بالنسبة لأي نوع آخر من الوصايا المدعومة.
يرجى ملاحظة أن zk-email تواجه اليوم تحديًا عمليًا يتمثل في اعتمادها على توقيع DKIM، الذي يستخدم مفتاحًا يتغير كل بضعة أشهر، وهذه المفاتيح نفسها لم يتم توقيعها من قبل أي جهة أخرى. وهذا يعني أن zk-email اليوم تتطلب درجة معينة من الثقة تتجاوز مزود الخدمة نفسه؛ إذا استخدمت zk-email TLSNotary للتحقق من المفاتيح المحدثة داخل الأجهزة الموثوقة، يمكن تقليل هذا الأمر، ولكن هذا ليس مثاليًا. نأمل أن تبدأ مزودات البريد الإلكتروني في توقيع مفاتيح DKIM الخاصة بها مباشرة. اليوم، يُنصح وصي باستخدام zk-email، ولكن لا يُنصح معظم الأوصياء بذلك: عدم تخزين الأموال في zk-email يعني أن الإعداد الذي يتعذر على المستخدمين استخدام أموالهم.
المستخدمون الجدد والمحفظة داخل التطبيق
المستخدمون الجدد في الواقع لا يرغبون في إدخال عدد كبير من الأوصياء عند التسجيل لأول مرة. لذلك، يجب أن توفر المحفظة خيارًا بسيطًا للغاية لهم. إحدى الطرق الطبيعية هي استخدام zk-email على عنوان بريدهم الإلكتروني، مع مفتاح ( المخزن محليًا على جهاز المستخدم والذي قد يكون مفتاحًا شاملاً ) ومفتاح النسخ الاحتياطي المحتفظ به من قبل المزود، لإجراء اختيار 2 من 3. مع تزايد خبرة المستخدم أو تراكم المزيد من الأصول، يجب في مرحلة ما أن يتم تحفيزهم لإضافة المزيد من الأوصياء.
المحفظة المدمجة في التطبيقات أمر لا مفر منه، لأن التطبيقات التي تحاول جذب المستخدمين غير المشفرين لا ترغب في أن يقوم المستخدمون بتنزيل تطبيقين جديدين في وقت واحد ( تطبيق نفسه، بالإضافة إلى المحفظة ايثر ) مما يؤدي إلى تجربة مستخدم مربكة. ومع ذلك، ينبغي أن يكون لدى العديد من مستخدمي محافظ التطبيقات القدرة على ربط جميع محافظهم معًا، بحيث يحتاجون فقط إلى القلق بشأن "مشكلة التحكم في الوصول" واحدة. أبسط طريقة هي اعتماد خطة هرمية، حيث توجد عملية "رابط" سريعة، تتيح للمستخدمين تعيين محفظتهم الرئيسية كوصي على جميع محافظ التطبيقات الداخلية. بعض العملاء قد دعموا ذلك بالفعل.
بشكل افتراضي، قد يتم التحكم في استعادة بعض حسابات المستخدمين داخل التطبيق بواسطة فريق تطوير التطبيق. ومع ذلك، يمكن للمستخدمين "استعادة" حساباتهم وتغيير الاستعادة إلى عنوانهم الخاص.
حماية المستخدمين من الاحتيال والتهديدات الخارجية الأخرى
بالإضافة إلى أمان الحساب، فإن المحفظة الحالية تقوم بالكثير من العمل لتحديد العناوين المزيفة، والمخادعة، والاحتيال، وغيرها من التهديدات الخارجية، وتسعى جهدها لحماية المستخدمين من هذه التهديدات. في الوقت نفسه، لا تزال العديد من التدابير بدائية إلى حد ما: على سبيل المثال، تتطلب النقر لإرسال ايثر أو رموز أخرى إلى أي عنوان جديد، بغض النظر عما إذا كان المستخدم يرسل 100 دولار أم لا.