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

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

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

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth

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

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

نموذج لواجهة محتملة للمحفظة مع دعم عنوان عبر السلسلة الجانبية

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

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

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

أمان الحساب

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

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

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

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

من يجب أن تكون الحراس؟

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

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

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

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

لحسن الحظ، مع ZK-SNARKs، لدينا خيار رابع: هوية مركزية ملفوفة بتقنية ZK. يشمل هذا النوعzk البريد الإلكتروني،أنون أدهار, محفظة ماينا، والعديد من الآخرين. بشكل أساسي، يمكنك تحويل أشكال عديدة من الهوية المركزية (الشركية أو الحكومية)، وتحويلها إلى عنوان Ethereum، الذي يمكنك من خلاله إرسال المعاملات فقط عن طريق إنشاء ZK-SNARK يثبت امتلاك الهوية المركزية.

مع هذا الإضافة، لدينا الآن مجموعة واسعة من الخيارات، والهوية المركزية المغلفة بتقنية ZK هي فريدة من نوعها و"سهلة الاستخدام للمبتدئين".

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

نموذج محتمل لواجهة السلامة

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

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

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

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

بشكل افتراضي ، يتم التحكم في استرداد حساب Warpcast الخاص بك من قبل فريق Warpcast. ومع ذلك ، يمكنك "استعادة السيادة" على حسابك في Farcaster ، وتغيير الاسترداد إلى عنوانك الخاص.

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

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

الخصوصية

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

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

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

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

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

محافظ Ethereum يجب أن تصبح أيضًا محافظ بيانات

تتمثل إحدى نتائج أي حل فعال للخصوصية ، سواء للمدفوعات أو للهوية أو حالات الاستخدام الأخرى ، في أنه يخلق حاجة للمستخدم لتخزين البيانات خارج السلسلة. كان هذا واضحا في Tornado Cash ، والذي تطلب من المستخدمين حفظ كل "ملاحظة" فردية تمثل إيداع 0.1-100 ETH. تقوم بروتوكولات الخصوصية الأكثر حداثة أحيانا بحفظ البيانات المشفرة على السلسلة ، واستخدام مفتاح خاص واحد لفك تشفيرها. هذا أمر محفوف بالمخاطر ، لأنه إذا تم تسريب المفتاح في أي وقت ، أو إذا أصبحت أجهزة الكمبيوتر الكمومية قابلة للحياة ، فإن جميع البيانات تصبح عامة. الشهادات خارج السلسلة مثل EAS و Zupass لديها حاجة أكثر وضوحا لتخزين البيانات خارج السلسلة.

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

الوصول الآمن إلى السلسلة

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

1. يمكن لمزود RPC أن يحاول سرقة الأموال عن طريق تزويدهم بمعلومات زائفة ، على سبيل المثال حول أسعار السوق
2. يمكن لمزود RPC استخراج معلومات خاصة حول التطبيقات والحسابات الأخرى التي يتفاعل معها المستخدم

في الواقع، نريد أن نقوم بسد كلا من هذه الثغرات. لسد الأول، نحتاج إلى عملاء خفيفة موحدة ل L1 و L2s، التي تحقق مباشرة توافق سلسلة الكتل.هيليوسبالفعل يقوم بذلك للمستوى 1 ، وقد قام ببعض العمل الأولي لدعم بعض L2s المحددة. لتغطية جميع L2s بشكل صحيح ، ما نحتاجه هو معيار يمكن لعقد التكوين الذي يمثل L2 (يستخدم أيضًا لعناوين سلسلة محددة) أن يعلن عن وظيفة ، ربما بطريقة مشابهة لـERC-3668، الذي يحتوي على منطق الحصول على جذور الحالة الأخيرة، والتحقق من الأدلة على الحالة والإيصالات ضد تلك الجذور الحالة. وبهذه الطريقة يمكننا الحصول على عميل خفيف عالمي، مما يتيح للمحافظ التحقق بأمان من أي حالة أو أحداث على L1 و L2.

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

للحفاظ على صدق الخادم، ستكون عناصر قاعدة البيانات الفردية نفسها فروعًا ميركل، بحيث يمكن للعميل التحقق منها باستخدام عميلهم الخفيف.

PIR مكلفة للغاية حسابياً. هناك عدة طرق لتجاوز هذه المشكلة:

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

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

محافظ Ideal keystore

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

1. تحديثات المراجعة: عندما يقوم المستخدم بتغيير تكوينه، يتم إعادة بث رسالة تفويض هذا التغيير على كل سلسلة يكتشف فيها المحفظة أن لدى المستخدم أصول. من الممكن أن يتم جعل تنسيق الرسالة وقواعد التحقق مستقلة عن السلسلة، بحيث يمكن إعادة بثها تلقائياً على أكبر عدد ممكن من السلاسل.
2. ملفات المفاتيح على L1: تعيش معلومات التكوين على L1، والمحفظة على L2 تقرأها بمساعدةL1SLOAD أو REMOTESTATICCALL. بهذه الطريقة ، يتعين تحديث التكوين فقط على L1 ، ويصبح التكوين فعالًا تلقائيًا.
3. ملفات المفاتيح على L2: تعيش معلومات التكوين على L2، وتقرأ المحفظة على L2 بواسطة ZK-SNARK. هذا هو نفس الشيء كـ (2)، باستثناء أن تحديثات ملفات المفاتيح يمكن أن تكون أرخص، على الرغم من أن قراءاتها أكثر تكلفة.

الحل (3) قوي بشكل خاص لأنه يتراكم بشكل جيد مع الخصوصية. في "حل الخصوصية" العادي ، يكون لدى المستخدم سر s ، ويتم نشر "قيمة الورقة" L على السلسلة ، ويثبت المستخدم أن L = تجزئة (s ، 1) و N = تجزئة (s ، 2) لبعض الأسرار (التي لم يتم الكشف عنها أبدا) التي يتحكمون فيها. يتم نشر المبطل N ، مع التأكد من فشل النفقات المستقبلية لنفس الورقة ، دون الكشف عن L. هذا يعتمد على حفاظ المستخدم على سلامته. بدلا من ذلك ، سيقول حل الخصوصية الصديق للاسترداد: s هو موقع (مثل العنوان وفتحة التخزين) onchain ، ويجب على المستخدم إثبات استعلام الحالة: L = hash (sload (sload(s) ، 1).

أمان الشبكة اللامركزية

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

في الواقع، سنقوم بتحريك النظام البيئي إلى إصدار المحتوى على السلسلة: سيقوم المستخدم بالوصول إلى تطبيق فائق السلسلة عبر اسم ENS الخاص به، الذي سيحتوي على تجزئة IPFS للواجهة. سيكون هناك حاجة إلى عملية تحويل على السلسلة من متعدد التوقيع أو DAO لتحديث الواجهة. ستظهر المحافظ للمستخدمين ما إذا كانوا يتفاعلون مع واجهة مؤمنة بشكل أكبر على السلسلة، أو واجهة web2 أقل أمانًا. يمكن أيضًا للمحافظ أن تظهر للمستخدمين ما إذا كانوا يتفاعلون مع سلسلة آمنة (على سبيل المثال، المرحلة 1+، والتدقيقات الأمنية المتعددة).

بالنسبة للمستخدمين الذين يهتمون بالخصوصية، يمكن للمحافظ أيضًا إضافة وضع الاشتباه، الذي يتطلب من المستخدمين النقر لقبول طلبات HTTP، وليس فقط عمليات web3:

نموذج توضيحي لواجهة ممكنة لوضع الشكوك

قد يكون النهج الأكثر تقدما هو تجاوز HTML + Javascript ، وكتابة منطق الأعمال الخاص ب dapps بلغة مخصصة ، وربما تراكب رفيع نسبيا على Solidity أو Vyper. يمكن للمتصفحات بعد ذلك إنشاء واجهة مستخدم تلقائيا لأي وظائف مطلوبة. OKContractيفعل ذلك بالفعل.

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

المستقبل الطويل الأجل

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

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

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

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

تنصل:

1. تمت إعادة طبع هذه المقالة من [فيتاليك]. إذا كان هناك اعتراضات على هذا النشر المطبعي، يرجى الاتصال بـ بوابة تعلّم فريق ، وسوف يتعاملون معها على الفور.
2. تنصل المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك للكاتب ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى من قبل فريق تعلم غيت. ما لم يُذكر غير ذلك، فإن نسخ أو توزيع أو سرقة المقالات المترجمة ممنوعة.