رؤية المحفظة المثالية: ترقية شاملة من تجربة عبر السلاسل إلى حماية الخصوصية
تعتبر طبقة المحفظة في مجموعة بنية الإيثريوم التحتية أمرًا بالغ الأهمية، ولكن غالبًا ما يتم التقليل من شأنها من قبل الباحثين والمطورين الرئيسيين. المحفظة هي نافذة تفاعل المستخدم مع عالم الإيثريوم، فقط عندما تمتلك المحفظة نفسها الخصائص المناسبة، يمكن للمستخدمين حقًا الاستمتاع بالخصائص اللامركزية، ومقاومة الرقابة، والأمان، والخصوصية التي تقدمها الإيثريوم وتطبيقاتها.
مؤخراً، حققت المحفظة الخاصة بالإيثريوم تقدماً ملحوظاً في تحسين تجربة المستخدم، والأمان، والوظائف. يهدف هذا المقال إلى استكشاف بعض الخصائص التي يجب أن تتوفر في المحفظة المثالية للإيثريوم. هذه ليست قائمة شاملة، بل تعكس ميول الكاتب نحو ثقافة الـ crypto punk، مع التركيز على الأمان والخصوصية. على الرغم من أن تجربة المستخدم قد لا تكون شاملة، إلا أنه بالنظر إلى أن تحسين تجربة المستخدم يتناسب أكثر مع النشر والتكرار، فسوف يركز هذا المقال على خصائص الأمان والخصوصية.
تجربة المستخدم في عبر السلاسل L2
يوجد حاليًا خارطة طريق متزايدة التفصيل لتحسين تجربة المستخدمين عبر السلاسل L2، بما في ذلك أجزاء قصيرة وطويلة المدى. هنا يتم مناقشة الأفكار القابلة للتنفيذ في المدى القصير.
الفكرة الأساسية هي: ( وظيفة إرسال عبر L2 مدمجة، ) عنوان محدد لل سلسلة وطلب الدفع. يجب أن توفر المحفظة للمستخدم عنوانًا يتبع تنسيق مسودة ERC معين.
عندما يتلقى المستخدم عنوانًا بهذا التنسيق، كل ما عليه هو لصقه في حقل "المستلم" في المحفظة والنقر على "إرسال"، وستقوم المحفظة بمعالجة عملية الإرسال تلقائيًا:
إذا كانت هناك رموز كافية مطلوبة على سلسلة الهدف, أرسل مباشرة
إذا كان هناك توكن مطلوب على سلاسل أخرى، استخدم بروتوكول DEX عبر السلاسل للإرسال
إذا كان هناك أنواع أخرى من الرموز، أرسلها بعد تحويلها باستخدام DEX
بالنسبة لمشهد طلب الودائع من dapp، فإن العملية المثالية هي توسيع واجهة برمجة تطبيقات web3، مما يسمح لـ dapp بإصدار طلبات دفع معينة بسلاسل. يمكن للمحفظة التعامل مع هذه الطلبات بمرونة. من أجل تجربة مستخدم جيدة، من الضروري أيضًا توحيد طلبات استعلام الرصيد المتاح، ويجب على المحفظة أن تأخذ بعين الاعتبار بعناية السلاسل التي سيتم تخزين أصول المستخدمين عليها بشكل افتراضي.
يمكن أيضًا تضمين طلبات الدفع المحددة على السلسلة في رمز الاستجابة السريعة ليقوم المحفظة المحمولة بمسحها. في سيناريوهات الدفع وجهًا لوجه أو عبر الإنترنت، يمكن للجهة المتلقية إصدار رمز الاستجابة السريعة أو استدعاء واجهة برمجة التطبيقات web3، مشيرةً إلى "أرغب في استلام Y وحدة من Z الرموز على السلسلة X، مع معرف مرجعي W". يمكن للمحفظة اختيار الطريقة التي تلبي هذا الطلب بحرية.
موضوع آخر ذي صلة هو دفع رسوم الغاز. إذا تلقى المستخدم أصولًا على L2 معين ولكن ليس لديه ETH لدفع رسوم الغاز، يجب أن تكون المحفظة قادرة على استخدام البروتوكول تلقائيًا لدفع رسوم الغاز من سلاسل أخرى تحتوي على ETH. إذا كان من المتوقع أن يقوم المستخدم بإجراء المزيد من المعاملات على تلك L2 في المستقبل، يمكن أيضًا إرسال كمية كافية من ETH من خلال DEX لدفع رسوم الغاز مباشرة على تلك السلسلة في المستقبل لأن ذلك يكون أقل تكلفة.
أمان الحساب
طريقة مفهوم الأمان للحسابات هي أن المحفظة الجيدة يجب أن تعمل في جانبين: (1) حماية المستخدم من هجمات أو تصرفات خبيثة لمطوري المحفظة، (2) حماية المستخدم من تأثير أخطائه الخاصة.
على مر السنين، كانت الحلول المفضلة للكاتب هي استعادة اجتماعية ذات تحكم وصول متدرج ومحفظة متعددة التوقيعات. تحتوي حسابات المستخدمين على طبقتين من المفاتيح: المفتاح الرئيسي و N من الأوصياء ( حيث N=5). يمكن للمفتاح الرئيسي تنفيذ العمليات ذات القيمة المنخفضة وغير المالية. يحتاج معظم الأوصياء إلى تنفيذ العمليات ذات القيمة العالية، مثل إرسال جميع أموال الحساب، (2) تغيير المفتاح الرئيسي أو أي وصي. إذا لزم الأمر، يمكن أيضًا السماح للمفتاح الرئيسي بتنفيذ العمليات ذات القيمة العالية من خلال قفل زمني.
هذا هو التصميم الأساسي، ويمكن توسيعه بشكل أكبر. يمكن أن تساعد مفاتيح الجلسة وآلية الأذونات في تحقيق التوازن بين الراحة والأمان بين التطبيقات المختلفة. يمكن أن تزيد الهياكل الأكثر تعقيدًا للوصي، مثل تعيين عدة فترات قفل زمنية تحت عتبات مختلفة، من فرص استعادة الحساب بشكل قانوني، مع تقليل مخاطر السرقة.
اختيار الوصي
بالنسبة للمستخدمين ذوي الخبرة في التشفير، فإن خيارًا قابلاً للتطبيق هو استخدام مفاتيح الأصدقاء والعائلة كأوصياء. إذا قدم كل شخص عنوانًا جديدًا، فلن يحتاجوا حتى إلى معرفة هويات بعضهم البعض، مما يقلل من احتمالية التواطؤ. لكن بالنسبة لمعظم المستخدمين الجدد، فإن هذا الخيار ليس قابلاً للتطبيق.
الخيار الثاني هو الوصي المؤسسي: يقدم خدمة توقيع المعاملات فقط عند استلام معلومات تأكيد إضافية مثل رمز التأكيد أو مكالمة فيديو (. هذه المحاولة موجودة منذ فترة طويلة، لكنها ليست ناجحة جداً حتى الآن.
الخيار الثالث هو استخدام عدة أجهزة شخصية ) مثل الهواتف المحمولة، أجهزة الكمبيوتر، والمحافظ الرقمية المادية (. هذه الطريقة ممكنة ولكنها قد تكون صعبة في الإعداد والإدارة للمستخدمين الجدد، كما أن هناك خطر فقدان الأجهزة أو سرقتها في نفس الوقت.
ظهرت مؤخرًا المزيد من الحلول القائمة على المفتاح الشامل. يمكن نسخ المفتاح احتياطيًا فقط على الجهاز، أو يمكن نسخه احتياطيًا في السحابة، وتعتمد الأمان على افتراضات معقدة حول التشفير المختلط، والجهات، والأجهزة الموثوقة. على الرغم من أنها تمثل مكسبًا أمنيًا ثمينًا للمستخدمين العاديين، إلا أن الاعتماد عليها وحدها ليس كافيًا لحماية جميع أصول المستخدم.
لحسن الحظ، فإن تقنية ZK-SNARK توفر لنا الخيار الرابع: الهوية المركزية المحاطة بـ ZK. وهذا يشمل zk-email، Anon Aadhaar، Myna Wallet وغيرها. الفكرة الأساسية هي تحويل أشكال مختلفة من الهوية المركزية للشركات أو الحكومات ) إلى عنوان إيثيريوم، حيث يمكن للمستخدمين إرسال المعاملات فقط من خلال توليد إثبات يمتلكون فيه الهوية المركزية باستخدام ZK-SNARK.
تحتاج هذه الخطة إلى تحقيقها من خلال واجهة مستخدم مبسطة ومتكاملة: يجب أن يكون المستخدم قادرًا على تحديد عنوان البريد الإلكتروني الذي يرغب في استخدامه كوصي، وسيقوم النظام تلقائيًا في الخلفية بإنشاء عنوان zk-email إيثيريوم المقابل. يجب أن يكون المستخدمون المتقدمون قادرين على إدخال البريد الإلكتروني ( وأي قيم ملح خصوصية محتملة محفوظة ) في تطبيقات الطرف الثالث مفتوحة المصدر، والتحقق من صحة العنوان الناتج. وينبغي أن يكون الأمر كذلك بالنسبة لأنواع الأوصياء المدعومة الأخرى.
من المهم ملاحظة أن التحدي العملي الحالي الذي يواجه zk-email هو اعتماده على مفاتيح توقيع DKIM التي تتغير كل بضعة أشهر، وهذه المفاتيح نفسها لم يتم توقيعها من قبل أي جهة أخرى. هذا يعني أن zk-email الحالي يحتاج إلى الثقة في المزود نفسه إلى حد ما. إذا تم استخدام TLSNotary للتحقق من المفاتيح المحدثة داخل الأجهزة الموثوقة، يمكن تقليل هذه الاعتماد، لكن لا يزال الأمر غير مثالي. نأمل أن تبدأ مزودات البريد الإلكتروني في التوقيع مباشرة على مفاتيح DKIM الخاصة بها. في الوقت الحالي، يُوصى باستخدام zk-email كواحد من الأوصياء، لكن لا يُنصح بأن يستخدم معظم الأوصياء ذلك: لا تخزن الأموال في إعدادات zk-email حيث لا يمكنك استخدام الأموال إذا ظهرت مشاكل.
المستخدمون الجدد والمحفظة داخل التطبيق
لا يرغب المستخدمون الجدد فعليًا في إدخال الكثير من معلومات الوصي عند التسجيل لأول مرة. لذلك، يجب أن توفر المحفظة لهم خيارًا بسيطًا جدًا. تتمثل الطريقة الطبيعية في استخدام zk-email لعنوان البريد الإلكتروني، والمفتاح المخزن محليًا على جهاز المستخدم (، وقد يكون المفتاح الشامل )، بالإضافة إلى مفتاح النسخ الاحتياطي المحتفظ به من قِبل المزود، لإجراء اختيار من 2 من 3. مع تراكم المزيد من الخبرة أو الأصول للمستخدم، يجب أن يتم تنبيههم في الوقت المناسب لإضافة المزيد من الوصيين.
من المستحيل دمج المحفظة في التطبيق، لأن التطبيقات الموجهة لمستخدمي غير التشفير لا ترغب في أن يقوم المستخدمون بتحميل تطبيقين جديدين في نفس الوقت، مما يؤدي إلى تجربة مستخدم مربكة، ( التطبيق نفسه بالإضافة إلى محفظة إيثريوم ). ومع ذلك، يجب أن يكون لدى العديد من مستخدمي المحافظ الداخلية القدرة على ربط جميع المحافظ معًا، بحيث يمكنهم التركيز على "مشكلة التحكم بالوصول" واحدة فقط. أسهل طريقة هي اعتماد خطة طبقية، من خلال عملية "رابط" سريعة، تسمح للمستخدمين بتعيين المحفظة الرئيسية كوصي على جميع المحافظ الداخلية.
حماية المستخدمين من الاحتيال والتهديدات الخارجية الأخرى
بالإضافة إلى أمان الحساب، تعمل المحفظة الحديثة على التعرف على العناوين المزيفة، والاحتيال عبر الإنترنت، والتهديدات الخارجية الأخرى، وتبذل جهودًا لحماية المستخدمين من هذه التهديدات. في الوقت نفسه، لا تزال العديد من التدابير بدائية إلى حد ما، مثل الحاجة إلى النقر على تأكيد سواء أكان الإرسال 100 دولار أو 100000 دولار. لا يوجد حل مثالي واحد في هذا الجانب، بل يتطلب الأمر مجموعة من التحسينات المستمرة لمواجهة فئات مختلفة من التهديدات. من المجدي الاستمرار في العمل في هذا المجال.
الخصوصية
لقد حان الوقت لأخذ خصوصية الإيثريوم على محمل الجد. لقد أصبحت تقنية ZK-SNARK متقدمة للغاية، ولا تعتمد على أبواب خلفية لتقليل مخاطر التنظيم، وتقنية الخصوصية ( مثل برك الخصوصية ) أصبحت أكثر نضجًا، والبنية التحتية من الطبقة الثانية مثل Waku وERC-4337 mempools أصبحت مستقرة أيضًا. ومع ذلك، لا يزال يتعين على المستخدمين حاليًا تنزيل واستخدام "المحفظة" الخاصة للقيام بالتحويلات السرية على الإيثريوم، مما يزيد من عدم الراحة ويقلل من عدد الأشخاص الراغبين في إجراء التحويلات السرية. الحل هو دمج التحويلات السرية مباشرة في المحفظة.
تنفيذ بسيط هو: يمكن للمحفظة تخزين جزء من أصول المستخدم ك"رصيد خاص" في حوض الخصوصية. عند نقل الأموال، سيتم الخروج تلقائيًا من حوض الخصوصية. إذا احتاج المستخدم إلى استلام الأموال، يمكن للمحفظة توليد عنوان غير مرئي تلقائيًا.
بالإضافة إلى ذلك، يمكن أن تقوم المحفظة بإنشاء عنوان جديد تلقائيًا لكل تطبيق يشارك فيه المستخدم. ستأتي الإيداعات من مجموعة الخصوصية، وستدخل السحوبات مباشرة إلى مجموعة الخصوصية. وهذا يسمح للمستخدم بفصل أنشطته في تطبيق واحد عن الأنشطة في التطبيقات الأخرى.
هذه التقنية ليست فقط وسيلة طبيعية لحماية نقل أصول الخصوصية، ولكنها أيضًا وسيلة طبيعية لحماية الهوية الخصوصية. الهوية قد حدثت على السلسلة: أي استخدام لتطبيقات مقيدة بالهوية، محادثات مقيدة بالرموز، بروتوكولات تتبع إيثريوم، كلها تمثل هوية على السلسلة. نأمل أن يحمي هذا النظام البيئي الخصوصية أيضًا. هذا يعني أن أنشطة المستخدمين على السلسلة لا ينبغي أن تتركز في مكان واحد: يجب تخزين كل مشروع بشكل منفصل، ويجب أن تكون المحفظة الخاصة بالمستخدم هي المكان الوحيد الذي يمتلك "عرضًا عالميًا"، حيث يمكن رؤية جميع الأدلة في وقت واحد. النظام البيئي الأصلي الذي يملك فيه كل مستخدم حسابات متعددة يساعد في تحقيق هذا الهدف، وكذلك بروتوكولات الأدلة خارج السلسلة مثل EAS وZupass.
هذا يمثل رؤية عملية لخصوصية الإيثيريوم على المدى المتوسط. على الرغم من أنه يمكن إدخال بعض الميزات على L1 و L2 لجعل نقل الخصوصية أكثر كفاءة وموثوقية، إلا أنه يمكن تحقيق ذلك الآن. يعتقد بعض المدافعين عن الخصوصية أن الحل الوحيد المقبول هو الخصوصية الكاملة لكل شيء: تشفير EVM بالكامل. قد تكون هذه النتيجة المثالية على المدى الطويل، ولكنها تتطلب إعادة تفكير أكثر جوهرية في نموذج البرمجة، ولم تصل بعد إلى مستوى النضج الذي يمكن نشره على الإيثيريوم. نحن بحاجة فعلاً إلى خصوصية افتراضية للحصول على مجموعة مجهولة كبيرة بما فيه الكفاية. ومع ذلك، فإن التركيز أولاً على التحويلات بين ( والحسابات )، وكذلك الهوية وحالات الاستخدام المتعلقة بالهوية ( مثل إثبات الخصوصية ) هي خطوة عملية أولى، وأسهل في التنفيذ، ويمكن للمحفظة البدء في استخدامها الآن.
يجب أن تصبح المحفظة الأثيرية أيضًا محفظة بيانات
أي حل خصوصية فعال سيؤدي إلى إنشاء سلسلة تخزين للمستخدمين
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 16
أعجبني
16
6
مشاركة
تعليق
0/400
BlockTalk
· منذ 14 س
لا أستطيع الانتظار لتجربة الجمع.
شاهد النسخة الأصليةرد0
BoredApeResistance
· منذ 15 س
قولها جيدًا ليس أفضل من إعطاء المزيد من غاز الرسوم.
محفظة إثيريوم المثالية: ترقية شاملة عبر السلاسل والأمان والخصوصية
رؤية المحفظة المثالية: ترقية شاملة من تجربة عبر السلاسل إلى حماية الخصوصية
تعتبر طبقة المحفظة في مجموعة بنية الإيثريوم التحتية أمرًا بالغ الأهمية، ولكن غالبًا ما يتم التقليل من شأنها من قبل الباحثين والمطورين الرئيسيين. المحفظة هي نافذة تفاعل المستخدم مع عالم الإيثريوم، فقط عندما تمتلك المحفظة نفسها الخصائص المناسبة، يمكن للمستخدمين حقًا الاستمتاع بالخصائص اللامركزية، ومقاومة الرقابة، والأمان، والخصوصية التي تقدمها الإيثريوم وتطبيقاتها.
مؤخراً، حققت المحفظة الخاصة بالإيثريوم تقدماً ملحوظاً في تحسين تجربة المستخدم، والأمان، والوظائف. يهدف هذا المقال إلى استكشاف بعض الخصائص التي يجب أن تتوفر في المحفظة المثالية للإيثريوم. هذه ليست قائمة شاملة، بل تعكس ميول الكاتب نحو ثقافة الـ crypto punk، مع التركيز على الأمان والخصوصية. على الرغم من أن تجربة المستخدم قد لا تكون شاملة، إلا أنه بالنظر إلى أن تحسين تجربة المستخدم يتناسب أكثر مع النشر والتكرار، فسوف يركز هذا المقال على خصائص الأمان والخصوصية.
تجربة المستخدم في عبر السلاسل L2
يوجد حاليًا خارطة طريق متزايدة التفصيل لتحسين تجربة المستخدمين عبر السلاسل L2، بما في ذلك أجزاء قصيرة وطويلة المدى. هنا يتم مناقشة الأفكار القابلة للتنفيذ في المدى القصير.
الفكرة الأساسية هي: ( وظيفة إرسال عبر L2 مدمجة، ) عنوان محدد لل سلسلة وطلب الدفع. يجب أن توفر المحفظة للمستخدم عنوانًا يتبع تنسيق مسودة ERC معين.
عندما يتلقى المستخدم عنوانًا بهذا التنسيق، كل ما عليه هو لصقه في حقل "المستلم" في المحفظة والنقر على "إرسال"، وستقوم المحفظة بمعالجة عملية الإرسال تلقائيًا:
بالنسبة لمشهد طلب الودائع من dapp، فإن العملية المثالية هي توسيع واجهة برمجة تطبيقات web3، مما يسمح لـ dapp بإصدار طلبات دفع معينة بسلاسل. يمكن للمحفظة التعامل مع هذه الطلبات بمرونة. من أجل تجربة مستخدم جيدة، من الضروري أيضًا توحيد طلبات استعلام الرصيد المتاح، ويجب على المحفظة أن تأخذ بعين الاعتبار بعناية السلاسل التي سيتم تخزين أصول المستخدمين عليها بشكل افتراضي.
يمكن أيضًا تضمين طلبات الدفع المحددة على السلسلة في رمز الاستجابة السريعة ليقوم المحفظة المحمولة بمسحها. في سيناريوهات الدفع وجهًا لوجه أو عبر الإنترنت، يمكن للجهة المتلقية إصدار رمز الاستجابة السريعة أو استدعاء واجهة برمجة التطبيقات web3، مشيرةً إلى "أرغب في استلام Y وحدة من Z الرموز على السلسلة X، مع معرف مرجعي W". يمكن للمحفظة اختيار الطريقة التي تلبي هذا الطلب بحرية.
موضوع آخر ذي صلة هو دفع رسوم الغاز. إذا تلقى المستخدم أصولًا على L2 معين ولكن ليس لديه ETH لدفع رسوم الغاز، يجب أن تكون المحفظة قادرة على استخدام البروتوكول تلقائيًا لدفع رسوم الغاز من سلاسل أخرى تحتوي على ETH. إذا كان من المتوقع أن يقوم المستخدم بإجراء المزيد من المعاملات على تلك L2 في المستقبل، يمكن أيضًا إرسال كمية كافية من ETH من خلال DEX لدفع رسوم الغاز مباشرة على تلك السلسلة في المستقبل لأن ذلك يكون أقل تكلفة.
أمان الحساب
طريقة مفهوم الأمان للحسابات هي أن المحفظة الجيدة يجب أن تعمل في جانبين: (1) حماية المستخدم من هجمات أو تصرفات خبيثة لمطوري المحفظة، (2) حماية المستخدم من تأثير أخطائه الخاصة.
على مر السنين، كانت الحلول المفضلة للكاتب هي استعادة اجتماعية ذات تحكم وصول متدرج ومحفظة متعددة التوقيعات. تحتوي حسابات المستخدمين على طبقتين من المفاتيح: المفتاح الرئيسي و N من الأوصياء ( حيث N=5). يمكن للمفتاح الرئيسي تنفيذ العمليات ذات القيمة المنخفضة وغير المالية. يحتاج معظم الأوصياء إلى تنفيذ العمليات ذات القيمة العالية، مثل إرسال جميع أموال الحساب، (2) تغيير المفتاح الرئيسي أو أي وصي. إذا لزم الأمر، يمكن أيضًا السماح للمفتاح الرئيسي بتنفيذ العمليات ذات القيمة العالية من خلال قفل زمني.
هذا هو التصميم الأساسي، ويمكن توسيعه بشكل أكبر. يمكن أن تساعد مفاتيح الجلسة وآلية الأذونات في تحقيق التوازن بين الراحة والأمان بين التطبيقات المختلفة. يمكن أن تزيد الهياكل الأكثر تعقيدًا للوصي، مثل تعيين عدة فترات قفل زمنية تحت عتبات مختلفة، من فرص استعادة الحساب بشكل قانوني، مع تقليل مخاطر السرقة.
اختيار الوصي
بالنسبة للمستخدمين ذوي الخبرة في التشفير، فإن خيارًا قابلاً للتطبيق هو استخدام مفاتيح الأصدقاء والعائلة كأوصياء. إذا قدم كل شخص عنوانًا جديدًا، فلن يحتاجوا حتى إلى معرفة هويات بعضهم البعض، مما يقلل من احتمالية التواطؤ. لكن بالنسبة لمعظم المستخدمين الجدد، فإن هذا الخيار ليس قابلاً للتطبيق.
الخيار الثاني هو الوصي المؤسسي: يقدم خدمة توقيع المعاملات فقط عند استلام معلومات تأكيد إضافية مثل رمز التأكيد أو مكالمة فيديو (. هذه المحاولة موجودة منذ فترة طويلة، لكنها ليست ناجحة جداً حتى الآن.
الخيار الثالث هو استخدام عدة أجهزة شخصية ) مثل الهواتف المحمولة، أجهزة الكمبيوتر، والمحافظ الرقمية المادية (. هذه الطريقة ممكنة ولكنها قد تكون صعبة في الإعداد والإدارة للمستخدمين الجدد، كما أن هناك خطر فقدان الأجهزة أو سرقتها في نفس الوقت.
ظهرت مؤخرًا المزيد من الحلول القائمة على المفتاح الشامل. يمكن نسخ المفتاح احتياطيًا فقط على الجهاز، أو يمكن نسخه احتياطيًا في السحابة، وتعتمد الأمان على افتراضات معقدة حول التشفير المختلط، والجهات، والأجهزة الموثوقة. على الرغم من أنها تمثل مكسبًا أمنيًا ثمينًا للمستخدمين العاديين، إلا أن الاعتماد عليها وحدها ليس كافيًا لحماية جميع أصول المستخدم.
لحسن الحظ، فإن تقنية ZK-SNARK توفر لنا الخيار الرابع: الهوية المركزية المحاطة بـ ZK. وهذا يشمل zk-email، Anon Aadhaar، Myna Wallet وغيرها. الفكرة الأساسية هي تحويل أشكال مختلفة من الهوية المركزية للشركات أو الحكومات ) إلى عنوان إيثيريوم، حيث يمكن للمستخدمين إرسال المعاملات فقط من خلال توليد إثبات يمتلكون فيه الهوية المركزية باستخدام ZK-SNARK.
تحتاج هذه الخطة إلى تحقيقها من خلال واجهة مستخدم مبسطة ومتكاملة: يجب أن يكون المستخدم قادرًا على تحديد عنوان البريد الإلكتروني الذي يرغب في استخدامه كوصي، وسيقوم النظام تلقائيًا في الخلفية بإنشاء عنوان zk-email إيثيريوم المقابل. يجب أن يكون المستخدمون المتقدمون قادرين على إدخال البريد الإلكتروني ( وأي قيم ملح خصوصية محتملة محفوظة ) في تطبيقات الطرف الثالث مفتوحة المصدر، والتحقق من صحة العنوان الناتج. وينبغي أن يكون الأمر كذلك بالنسبة لأنواع الأوصياء المدعومة الأخرى.
من المهم ملاحظة أن التحدي العملي الحالي الذي يواجه zk-email هو اعتماده على مفاتيح توقيع DKIM التي تتغير كل بضعة أشهر، وهذه المفاتيح نفسها لم يتم توقيعها من قبل أي جهة أخرى. هذا يعني أن zk-email الحالي يحتاج إلى الثقة في المزود نفسه إلى حد ما. إذا تم استخدام TLSNotary للتحقق من المفاتيح المحدثة داخل الأجهزة الموثوقة، يمكن تقليل هذه الاعتماد، لكن لا يزال الأمر غير مثالي. نأمل أن تبدأ مزودات البريد الإلكتروني في التوقيع مباشرة على مفاتيح DKIM الخاصة بها. في الوقت الحالي، يُوصى باستخدام zk-email كواحد من الأوصياء، لكن لا يُنصح بأن يستخدم معظم الأوصياء ذلك: لا تخزن الأموال في إعدادات zk-email حيث لا يمكنك استخدام الأموال إذا ظهرت مشاكل.
المستخدمون الجدد والمحفظة داخل التطبيق
لا يرغب المستخدمون الجدد فعليًا في إدخال الكثير من معلومات الوصي عند التسجيل لأول مرة. لذلك، يجب أن توفر المحفظة لهم خيارًا بسيطًا جدًا. تتمثل الطريقة الطبيعية في استخدام zk-email لعنوان البريد الإلكتروني، والمفتاح المخزن محليًا على جهاز المستخدم (، وقد يكون المفتاح الشامل )، بالإضافة إلى مفتاح النسخ الاحتياطي المحتفظ به من قِبل المزود، لإجراء اختيار من 2 من 3. مع تراكم المزيد من الخبرة أو الأصول للمستخدم، يجب أن يتم تنبيههم في الوقت المناسب لإضافة المزيد من الوصيين.
من المستحيل دمج المحفظة في التطبيق، لأن التطبيقات الموجهة لمستخدمي غير التشفير لا ترغب في أن يقوم المستخدمون بتحميل تطبيقين جديدين في نفس الوقت، مما يؤدي إلى تجربة مستخدم مربكة، ( التطبيق نفسه بالإضافة إلى محفظة إيثريوم ). ومع ذلك، يجب أن يكون لدى العديد من مستخدمي المحافظ الداخلية القدرة على ربط جميع المحافظ معًا، بحيث يمكنهم التركيز على "مشكلة التحكم بالوصول" واحدة فقط. أسهل طريقة هي اعتماد خطة طبقية، من خلال عملية "رابط" سريعة، تسمح للمستخدمين بتعيين المحفظة الرئيسية كوصي على جميع المحافظ الداخلية.
حماية المستخدمين من الاحتيال والتهديدات الخارجية الأخرى
بالإضافة إلى أمان الحساب، تعمل المحفظة الحديثة على التعرف على العناوين المزيفة، والاحتيال عبر الإنترنت، والتهديدات الخارجية الأخرى، وتبذل جهودًا لحماية المستخدمين من هذه التهديدات. في الوقت نفسه، لا تزال العديد من التدابير بدائية إلى حد ما، مثل الحاجة إلى النقر على تأكيد سواء أكان الإرسال 100 دولار أو 100000 دولار. لا يوجد حل مثالي واحد في هذا الجانب، بل يتطلب الأمر مجموعة من التحسينات المستمرة لمواجهة فئات مختلفة من التهديدات. من المجدي الاستمرار في العمل في هذا المجال.
الخصوصية
لقد حان الوقت لأخذ خصوصية الإيثريوم على محمل الجد. لقد أصبحت تقنية ZK-SNARK متقدمة للغاية، ولا تعتمد على أبواب خلفية لتقليل مخاطر التنظيم، وتقنية الخصوصية ( مثل برك الخصوصية ) أصبحت أكثر نضجًا، والبنية التحتية من الطبقة الثانية مثل Waku وERC-4337 mempools أصبحت مستقرة أيضًا. ومع ذلك، لا يزال يتعين على المستخدمين حاليًا تنزيل واستخدام "المحفظة" الخاصة للقيام بالتحويلات السرية على الإيثريوم، مما يزيد من عدم الراحة ويقلل من عدد الأشخاص الراغبين في إجراء التحويلات السرية. الحل هو دمج التحويلات السرية مباشرة في المحفظة.
تنفيذ بسيط هو: يمكن للمحفظة تخزين جزء من أصول المستخدم ك"رصيد خاص" في حوض الخصوصية. عند نقل الأموال، سيتم الخروج تلقائيًا من حوض الخصوصية. إذا احتاج المستخدم إلى استلام الأموال، يمكن للمحفظة توليد عنوان غير مرئي تلقائيًا.
بالإضافة إلى ذلك، يمكن أن تقوم المحفظة بإنشاء عنوان جديد تلقائيًا لكل تطبيق يشارك فيه المستخدم. ستأتي الإيداعات من مجموعة الخصوصية، وستدخل السحوبات مباشرة إلى مجموعة الخصوصية. وهذا يسمح للمستخدم بفصل أنشطته في تطبيق واحد عن الأنشطة في التطبيقات الأخرى.
هذه التقنية ليست فقط وسيلة طبيعية لحماية نقل أصول الخصوصية، ولكنها أيضًا وسيلة طبيعية لحماية الهوية الخصوصية. الهوية قد حدثت على السلسلة: أي استخدام لتطبيقات مقيدة بالهوية، محادثات مقيدة بالرموز، بروتوكولات تتبع إيثريوم، كلها تمثل هوية على السلسلة. نأمل أن يحمي هذا النظام البيئي الخصوصية أيضًا. هذا يعني أن أنشطة المستخدمين على السلسلة لا ينبغي أن تتركز في مكان واحد: يجب تخزين كل مشروع بشكل منفصل، ويجب أن تكون المحفظة الخاصة بالمستخدم هي المكان الوحيد الذي يمتلك "عرضًا عالميًا"، حيث يمكن رؤية جميع الأدلة في وقت واحد. النظام البيئي الأصلي الذي يملك فيه كل مستخدم حسابات متعددة يساعد في تحقيق هذا الهدف، وكذلك بروتوكولات الأدلة خارج السلسلة مثل EAS وZupass.
هذا يمثل رؤية عملية لخصوصية الإيثيريوم على المدى المتوسط. على الرغم من أنه يمكن إدخال بعض الميزات على L1 و L2 لجعل نقل الخصوصية أكثر كفاءة وموثوقية، إلا أنه يمكن تحقيق ذلك الآن. يعتقد بعض المدافعين عن الخصوصية أن الحل الوحيد المقبول هو الخصوصية الكاملة لكل شيء: تشفير EVM بالكامل. قد تكون هذه النتيجة المثالية على المدى الطويل، ولكنها تتطلب إعادة تفكير أكثر جوهرية في نموذج البرمجة، ولم تصل بعد إلى مستوى النضج الذي يمكن نشره على الإيثيريوم. نحن بحاجة فعلاً إلى خصوصية افتراضية للحصول على مجموعة مجهولة كبيرة بما فيه الكفاية. ومع ذلك، فإن التركيز أولاً على التحويلات بين ( والحسابات )، وكذلك الهوية وحالات الاستخدام المتعلقة بالهوية ( مثل إثبات الخصوصية ) هي خطوة عملية أولى، وأسهل في التنفيذ، ويمكن للمحفظة البدء في استخدامها الآن.
يجب أن تصبح المحفظة الأثيرية أيضًا محفظة بيانات
أي حل خصوصية فعال سيؤدي إلى إنشاء سلسلة تخزين للمستخدمين