فيتاليك: كيف تبدو محفظتي المثالية للإيثيريوم؟

العنوان الأصلي: ما أود رؤيته في المحفظة

المؤلف: فيتاليك، مؤسس Ethereum؛ المترجم: دينغ تونغ، Golden Finance

شكر خاص ليراز سيري، يواف Weiss ومطوري ImToken وMetamask وOKX للحصول على الملاحظات والمراجعة.

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

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

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

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

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

[email protected]

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

• إذا كنت يوجد بالفعل ما يكفي من الرموز المميزة من النوع المطلوب في السلسلة المستهدفة، يرجى إرسال الرموز المميزة مباشرة؛

• إذا كان لديك رموز مميزة على سلسلة أخرى (أو عدة سلاسل أخرى) الرموز المميزة لل النوع المطلوب، يرجى استخدام ERC-7683 (في الواقع سلسلة متقاطعة DEX) والبروتوكولات الأخرى لإرسال الرموز المميزة؛

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

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

ينطبق ما ورد أعلاه على "نسخ ولصق عنوان (أو ENS، على سبيل المثال) ،Vitalik [email protected]) حتى يدفع لك شخص ما" حالة الاستخدام. إذا طلب تطبيق لامركزي إيداعًا (انظر مثال Polymarket على سبيل المثال)، فسيكون التدفق المثالي هو توسيع واجهة برمجة تطبيقات web3 والسماح للتطبيق اللامركزي بتقديم طلبات دفع خاصة بالسلسلة. ستتمكن محفظتك بعد ذلك من تلبية الطلب بأي طريقة مطلوبة. للحصول على تجربة مستخدم جيدة، يجب أيضًا توحيد طلبات getAvailableBalance، وتحتاج المحافظ إلى التفكير بعناية في السلاسل التي سيتم تخزين أصول المستخدم عليها افتراضيًا لتحقيق أقصى قدر من الأمان وسهولة النقل.

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

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

أمان الحساب

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

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

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

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

من أو ماذا يجب أن يكون الوصي؟

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

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

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

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

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

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

لهذا، يجب تحقيق ذلك من خلال واجهة مستخدم مبسطة ومتكاملة: يجب أن تكون قادرًا على تحديد أنك تريد "[email protected]" فقط كوصي، ويجب أن يتم إنشاء الرسالة المقابلة تلقائيًا zk-email ether عنوان المصنع موجود تحت الغطاء. يجب أن يكون المستخدمون المتقدمون قادرين على إدخال بريدهم الإلكتروني (وربما معلومات الخصوصية المحفوظة داخل هذا البريد الإلكتروني) في تطبيق خارجي مفتوح المصدر والتأكد من صحة العنوان الناتج. يجب أن ينطبق الأمر نفسه على أي نوع وصي آخر مدعوم.

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

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

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

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

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

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

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

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

الخصوصية

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

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

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

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

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

يجب أن تكون محافظ Ethereum بمثابة محافظ بيانات أيضًا

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

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

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

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

• قد يحاول موفر RPC سرقة الأموال عن طريق وتزويدهم بمعلومات كاذبة، مثل أسعار السوق

• RPC يمكن لمقدمي الخدمة استخراج معلومات خاصة حول التطبيقات والحسابات الأخرى التي يتفاعل معها المستخدم

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

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

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

تتطلب عملية PIR الكثير من العمليات الحسابية. هناك عدة طرق لحل هذه المشكلة:

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

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

• سجل المصلحة العامة PIR متعدد الخوادم: إذا كنت تستخدم خوادم متعددة، ويفترض أن الصدق بين هذه الخوادم هو 1 من N، فإن سجل المصلحة العامة PIR الخوارزميات عادة ما تكون أسرع.

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

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

محفظة تخزين المفاتيح المثالية

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

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

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

• مخزن المفاتيح على L2: توجد معلومات التكوين على L2 وتقرأها المحفظة على L2 باستخدام ZK-SNARK. هذا هو نفسه (2)، باستثناء أن تحديثات مخزن المفاتيح قد تكون أرخص، ولكن عمليات القراءة من ناحية أخرى تكون أكثر تكلفة.

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

أمان التطبيقات اللامركزية

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

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

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

نموذج واجهة محتمل لوضع جنون العظمة

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

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

المستقبل على المدى الطويل

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

• مصطنع الذكاء، والذي قد يقودنا إلى الانتقال من نموذج الكتابة بالنقر إلى نموذج "قل ما تريد أن تفعله وسيكتشفه الروبوت"

• العقل- واجهة الكمبيوتر، كلاهما هناك طرق "لطيفة" مثل تتبع العين، ولكن هناك أيضًا تقنيات أكثر مباشرة وحتى تدخلية (انظر: رقم 1 لهذا العام) مرضى Neuralink)؛

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

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

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