المفتاح الخاص هو النواة التي تسمح لنا بتوقيع المعاملات على الإيثيريوم، لكن إدارته كانت كابوسًا، حتى في الشكل القابل للقراءة لـ 'عبارات البذور'. ومع ذلك، كان هدفنا أبدًا تحويل تقنية البلوكشين إلى لعبة معقدة.
مصادقة المستخدمين المصرح بهم أمر حاسم للمعاملات الآمنة. مع تطور أمان الإنترنت وتجربة المستخدم، لقد انتقلنا من مصادقة كلمة المرور إلى التحقق الحيوي مثل التعرف على الوجه وبصمات الأصابع. تعد WebAuthn تطورًا رئيسيًا في هذا التقدم. يناقش هذا المقال عن كثب ثلاث مصطلحات:
WebAuthn: يستخدم معيار مصادقة الويب بيانات الاعتماد المستندة إلى المفتاح العام ، والتي غالبا ما يتم إنشاؤها بواسطة مصادقين خارجيين. إنه يلغي الحاجة إلى كلمات المرور ويتيح مصادقة المستخدم الآمنة.
المخزن الآمن: منطقة آمنة مبنية على الأجهزة ضمن أجهزة الحوسبة، ويتم تصميم المخزن الآمن لحماية البيانات الحساسة. تم العثور على إصدارات من المخزن الآمن في أجهزة iOS وAndroid وWindows. يمكن أن يكون مخزن الآمن موثقًا بشكل آمن من خلال تنفيذ WebAuthn، ولكن المفتاح الخاص، المرتبط بالمخزن الآمن، في كثير من الأحيان يُعَرِضُ لتحديات عبر الأجهزة.
Passkey: تطبيق لـ WebAuthn على مستوى نظام التشغيل، مخصص من قبل مختلف مزودي الأجهزة والأنظمة. على سبيل المثال، يستخدم Passkey الخاص بـ Apple المفتاح المخزن في سلسلة مفاتيح iCloud لمزامنة الأجهزة عبر الأجهزة. ومع ذلك، يكون هذا النهج عادة مقفلاً على منصات أو أنظمة محددة.
كما هو موضح أعلاه، تتماشى تنفيذات webAuthn مع هدفنا لمستخدمي سلسلة الكتل اليوميين، لتحقيق أمان مكافحة الاحتيال على مستوى عال وتجربة ودية. إليك الفكرة لدمجها في سلسلة الكتل:
الطبقة الرئيسية: يقوم المستخدمون بالمصادقة باستخدام طرق بيومترية سلسة مثل التعرف على الوجه أو بصمة الإصبع. تحت الغطاء، إنها المعالجة الأمنية القائمة على الأجهزة مثل Secure Enclave أو خدمات السحابة مثل iCloud و Google Cloud التي تتعامل مع إدارة المفاتيح. سأتناول مشكلات الجهاز العابر ومشاكل النظام العابرة لاحقًا.
الطبقة الحسابية: يوفر حساب العقد الذكي (SCA) القدرة على تعيين الموقعين التعسفيين (على سبيل المثال SE و Passkey) وآليات العتبة. علاوة على ذلك، تعزز التصميم النمطي لها مرونة وقابلية للترقية. على سبيل المثال، يمكن لـ SCA تكييف متطلبات التوقيع الخاصة بها ديناميكيًا استنادًا إلى عوامل مثل مبلغ المعاملة أو الوقت أو عنوان IP. من ناحية أخرى، يمكن تعزيز حساب الممتلكات الخارجية التقليدي (EOA) بخدمات MPC، وتقدم مجموعتها هذه توافقًا أفضل وكفاءة تكلفة مقارنة بـ SCA، على الرغم من أنها تفتقر إلى وظائف متقدمة تقدمها SCAs، خاصة بالنسبة لتدوير المفاتيح.
طبقة التوقيع: يدعم Ethereum أصلا منحنى k1 ، لكن التحقق من توقيع WebAuthn يتحمل تكاليف أعلى ، لأنه يستخدم منحنى r1 لتوليد المفاتيح. لذلك ، فإن بعض حلول الطبقة 2 مثل zkSync ، والتخطيط على منحنى EIP-7212 r1 الأصلي يتم تجميعه مسبقا. بالإضافة إلى ذلك ، هناك خدمات الجهات الخارجية ، ومدققات الصلابة ، ومدققات المعرفة الصفرية (ZK) ، وأنظمة إدارة المفاتيح الموزعة ، لتسهيل توقيع منحنى r1 بطريقة أكثر فعالية من حيث التكلفة.
تنصيح بعدم المسؤولية:
التقدم التكنولوجي لا يضمن نجاح السوق؛ ليس جميع الأجهزة والمنصات قد اعتمدت Passkey؛ استخدام SCA قد يكون أكثر تكلفة من EOA؛ الحل المقترح يتطور مع التقدم التكنولوجي.
في مجال البلوكشين، فإن السيطرة الحقيقية على أصول البلوكشين ليست بيد المستخدم أو موفر المحفظة، وإنما تكمن في المفتاح الخاص. هذا المفتاح هو الأكثر أهمية لعملية تنفيذ عملية تحويل على إيثيريوم. لفهم هذا بشكل أفضل، دعونا نأخذ EOA كمثال:
توليد المفاتيح: يعمل رقم عشوائي محدد من المنحنى الإهليلجي secp256k1 كمفتاح خاص. ثم يتم ضرب هذا المفتاح بنقطة محددة مسبقا على المنحنى لإنشاء المفتاح العام. عنوان Ethereum مشتق من آخر 20 بايت من المفتاح العام المجزأ. عادة ما يتم تقديم "العبارة الأولية" للنسخ الاحتياطي الذي يمكن قراءته من قبل الإنسان ، مما يتيح الاشتقاق الحتمي للمفاتيح الخاصة والعامة.
توقيع المعاملات: يتم توقيع معاملة تحتوي على تفاصيل مثل عدم تكرار (رقم تسلسلي)، المبلغ، سعر الغاز، وعنوان المستلم باستخدام المفتاح الخاص. يُولد توقيع يتألف من قيم (r، s، v)، باستخدام عملية تشمل ECDSA، وهو خوارزمية توقيع رقمية تستخدم تشفير المنحنى البيضاوي وتعتمد secp256k1 كمنحنى. تُذاع التوقيع والمعاملة الأصلية على الشبكة بعد ذلك.
التحقق من المعاملات: بمجرد وصول المعاملة إلى عقدة Ethereum، تخضع لعملية التحقق في مسبح الذاكرة الخاص بالعقدة. للتحقق من الموقع، تستخدم العقدات التوقيع والمعاملة المجزأة لاشتقاق المفتاح العام للمرسل وتأكيد مصداقية المعاملة عن طريق مطابقة العنوان المشتق مع عنوان المرسل.
كما هو موضح أعلاه، فإن المفتاح الخاص Entitي هو كيان أساسي على السلسلة. في الأصل، كانت حسابات Ethereum، المعروفة باسم الحسابات المملوكة خارجيًا (EOAs)، تعتمد فقط على مفتاح خاص واحد، مما يشكل مخاطر كبيرة، حيث أن فقدان المفتاح يعني فقدان الوصول إلى الحساب.
قد يعتقد الكثيرون أن Account Abstraction (AA) هو الحل لكل ما يتعلق بتجربة المستخدم السيئة ، والتي سأقول ليس بالضبط. يتعلق AA بتغيير قواعد الصلاحية لتكون قابلة للبرمجة ، وقابلية برمجة حساب العقد الذكي (SCAs) تجعل ذلك ممكنا. AA قوي ، ويتيح إرسال معاملات متعددة بالتوازي (nonce المجردة) ، ورعاية الغاز ودفع الغاز في ERC20 (الغاز المجرد) ، وأكثر صلة بموضوع هذه المقالة ، لكسر التحقق من صحة التوقيع الثابت (توقيع ECDSA المجرد). بدلا من EOA، يمكن ل SCAs تعيين موقعين تعسفيين وآليات توقيع مثل التوقيع المتعدد (multisigs) أو مفاتيح النطاق (مفاتيح الجلسة). ومع ذلك ، على الرغم من المرونة والتقدم في قابلية الترقية ل AA ، فإن الاعتماد الأساسي على المفتاح (المفاتيح) لتوقيع المعاملات لم يتغير.
حتى عند تحويلها إلى عبارة بذور مؤلفة من 12 كلمة، يظل إدارة المفتاح الخاص تشكل تحديًا، مما يتسبب في مخاطر فقدان أو هجمات احتيال. يجب على المستخدمين التنقل بين طبقات معقدة من الحلول اللامركزية أو الاحتضان الدافئ للخدمة المركزية، ولا أحدهما مثالي.
لماذا تكون تجربة مجال العملات الرقمية سيئة؟ يعود جزء كبير من ذلك إلى سوء إدارة المفاتيح. دائمًا ما يتطلب تحقيق التوازن بين التجربة والأمان واللامركزية. يستكشف هذا المقال الحلول الأمثل المحتملة لإدارة المفتاح.
لن يكون هناك أبدًا حلاً مناسبًا للجميع، أفضل طريقة للحفاظ على المفتاح مصممة خصيصًا لسيناريوهات المستخدم المحددة، تحت تأثير عوامل مثل نوع المستخدم (مؤسسي أو فردي)، مبلغ رأس المال، تردد المعاملات، وأنواع التفاعل.
للتوضيح مسبقًا، أتجنب استخدام أساليب 'الاحتفاظ الذاتي والشبه والكامل' الشهيرة للتصنيف. في رأيي، يعني الاحتفاظ الذاتي الحقيقي توقيع عملية بشكل مستقل، دون الاعتماد على طرف آخر، وهذا ينطبق حتى لو لم تكن الحلول إيداعية بالمعنى التقليدي (مثل تخزينها في عقد الثقة التابع للعقد الذكي في العقد الليني). تصنيف الحلول على أنها 'جيدة' أو 'سيئة' استنادًا إلى نوع الاحتفاظ يعتبر بسذاجة ولا يأخذ في الاعتبار ملاءمتها المتنوعة. لتقييم أكثر دقة لأساليب إدارة المفاتيح، أقترح تحليلها من خلال ثلاث طبقات متميزة:
ما إذا كان تقسيم مسؤولية إدارة مفتاح إلى أطراف مختلفة.
نظرًا لأن الأفراد غالبًا ما يواجهون تحديات في إدارة المفتاح، يظهر توزيع مسؤولية حماية المفتاح كاستراتيجية طبيعية للتخفيف من المخاطر. تشمل هذه الفئة أساليب مثل استخدام مفاتيح متعددة للتوقيع بشكل تعاوني، كما هو الحال في أنظمة التوقيع المتعدد (التوقيع المتعدد)، وتقسيم المفتاح الخاص إلى أجزاء من خلال مخطط مشاركة سرية (SSS) أو الحساب بالأطراف المتعددة (MPC).
التوقيع المتعدد: الذي يتطلب عدة مفاتيح خاصة كاملة لتوليد تواقيع المعاملات. يتطلب هذا الأسلوب التواصل على السلسلة حول الموقعين المختلفين، مما يتسبب في زيادة رسوم المعاملات، ويؤثر على الخصوصية لأن عدد الموقعين مرئي على السلسلة.
SSS: يتم إنشاء مفتاح خاص في موقع واحد، ويوزع الوكيل قطعًا من هذا المفتاح على أطراف مختلفة. يجب على جميع الأطراف إعادة بناء المفتاح الخاص بالكامل لتوقيع عملية معينة. ومع ذلك، قد تؤدي هذه العملية المؤقتة لإعادة البناء إلى إدخال نقاط ضعف.
MPC-TSS (مخطط توقيع العتبة): كتطبيق ل MPC ، نهج تشفير يمكن العديد من الأطراف من إجراء العمليات الحسابية مع الحفاظ على خصوصية مدخلاتهم بشكل مشترك. يقوم كل طرف بشكل مستقل بإنشاء مشاركة مفتاح سرية ، ويتم توقيع المعاملات دون الحاجة إلى تلبية هذه الأطراف فعليا. يقدم رسوما أقل لأنه خارج السلسلة ، ولا توجد نقطة واحدة لخطر الفشل مثل SSS.
قم بتخزين المفتاح أو الحصص، المتأثرة بعوامل الأمان والوصول والتكلفة واللامركزية.
الخدمات السحابية المركزية مثل AWS، iCloud والخوادم الأخرى. إنها مريحة للمعاملات المتكررة، ولكنها أكثر عرضة للرقابة.
تخزين لامركزي مثل IPFS و Filecoin.
الكمبيوتر/الهاتف المحلي: يتم تخزين المفاتيح محليًا داخل تخزين المتصفح الآمن.
المحافظ الورقية: طباعة فيزيائية لمفاتيح خاصة أو رموز الاستجابة السريعة.
بيئة التنفيذ الموثوقة (TEE): TEE توفر منطقة آمنة داخل المعالج الرئيسي لتنفيذ أو تخزين البيانات الحساسة، معزولة عن نظام التشغيل الرئيسي.
المخزن الآمن: المخزن الآمن في الأجهزة الحديثة معزول عن المعالج الرئيسي لتوفير طبقة إضافية من الأمان ومصمم للحفاظ على بيانات المستخدم الحساسة آمنة حتى عندما يتعرض نواة معالج التطبيق للاختراق.
محافظ عتادية: أجهزة فيزيائية مثل ليدجر وتريزور، مصممة خصيصًا لتخزين مفاتيح خاصة بشكل آمن.
وحدة الأمان الأجهزة (HSM): تعتبر HSMs أجهزة أجهزة متخصصة مصممة لإدارة المفاتيح بشكل آمن والعمليات التشفيرية. عادة ما تستخدم في بيئات الشركات وتقدم ميزات أمان عالية المستوى.
كيفية التحقق من هوية المستخدم للوصول إلى المفتاح المخزن
يشارك المصادقة في الوصول إلى المفتاح المخزن. إنها تتعلق بالتحقق من أن الشخص الذي يحاول الوصول مخول فعلًا بذلك. إذا نظرنا إلى التاريخ، يمكننا تصنيف التاريخ مثل هذا:
شيء تعرفه: كلمات المرور، الأرقام السرية، إجابات على الأسئلة الأمنية، أو أنماط محددة.
شيء تمتلكه: تشمل البطاقات الذكية، الرموز المعتمدة على الأجهزة (كلمات المرور المؤقتة الزمنية)، أو عوامل رقمية مثل التحقق من حسابات التواصل الاجتماعي ورموز الرسائل النصية المرسلة إلى الهاتف.
شخص ما أنت: تتضمن خصائص مادية فريدة للمستخدم ، مثل بصمات الأصابع أو التعرف على الوجه (مثل Face ID من Apple أو Windows Hello) أو التعرف على الصوت أو مسح القزحية / شبكية العين.
على هذه الأساس، 2FA و MFA هما طرق تجمع بين عاملين أو أكثر، مثل رسائل SMS المرتبطة بإشعارات الدفع، لإضافة طبقات أمان إضافية إلى حسابات المستخدمين.
يُسمح لمستخدمي MetaMask باستخدام كلمة مرور للوصول إلى المفتاح المخزن في تخزين المتصفح المحلي للمستخدم.
تسمح محفظة Trust للمستخدمين باستخدام كلمة مرور أو FaceID للوصول إلى المفتاح المخزن في تخزين متصفح المستخدم المحلي، ويمكن للمستخدم أيضًا اختيار خدمة السحابة لنسخ احتياطي للمفتاح الخاص.
يسمح Privy للمستخدمين باستخدام طرق تسجيل الدخول الاجتماعية المتعددة مثل البريد الإلكتروني، باستخدام SSS لتقسيم ثلاثة أسهم:
مشاركة الجهاز: مستعرض-iFrame، الجوال- محمية الحصن.
مشاركة المصادقة: تم تخزينها بواسطة خاصية، رابط إلى معرف خاصيّ.
حصة الاستعادة: كلمة مرور المستخدم أو تشفيرها بواسطة Privy المخزنة في وحدة أمان الأجهزة (HSM).
يتيح لمستخدمي Particle استخدام تسجيل الدخول الاجتماعي، باستخدام MPC-TSS الذي يحتوي على حصتين:
مشاركة الجهاز: المتصفح - إطار الإطار
مفتاح الخادم المشترك: خادم بارتيكل
لقد كانت الحلول الحالية أعلاه حاسمة في تقديم المستخدمين إلى web3. ومع ذلك، فإنها غالبًا ما تأتي مع تحديات: يمكن نسيان كلمات المرور أو استهدافها في هجمات احتيال الصيد، وحتى 2FA، على الرغم من أنه أكثر أمانًا، يمكن أن يكون مرهقًا بخطواته المتعددة. بالإضافة إلى ذلك، ليس الجميع مرتاحين إلى إيثار طرف ثالث بإدارة المفتاح، المستخدمون مازالوا يعتمدون على توفر النظام وحية بينما تضمن بعض الخدمات أنهم لا يمكنهم الوصول إلى المفتاح.
هذا يدفعنا إلى التفكير في ما إذا كان هناك حلاً أكثر فعالية - واحد يقدم أقرب حلاً لتجربة مستخدم خالية من الثقة وعالية الأمان وسهلة الاستخدام. يقودنا هذا البحث إلى أساليب web2 الأمثل. عدة مصطلحات مرتبطة تضيق الخناق على الموضوع، كما وصفت في بداية المقال، WebAuthn هو المعيار نفسه للمصادقة، بينما تعتبر Secure Enclave و Passkey تنفيذات أو مكونات متعلقة بهذا المعيار.
WebAuthn
تقوم معيارات WebAuthn بتوحيد واجهة توثيق المستخدمين لتطبيقات الويب. يُتيح للمستخدمين تسجيل الدخول إلى حسابات الإنترنت باستخدام موثقات خارجية بدلاً من كلمة مرور. يمكن أن تكون الموثقات موثقات التجوال (Yubikey، Titan key) أو موثق أساسي (مضمن في سلسلة المفاتيح على أجهزة Apple)، وهكذا.
طور تحالف FIDO (Fast IDentity Online) في البداية التقنيات الكامنة وراء WebAuthn. تم الإعلان عنه رسميا كمعيار ويب من قبل W3C في مارس 2019 ، وإلى جانب توحيده ، اعتمدت المتصفحات الرئيسية مثل Google Chrome و Mozilla Firefox و Microsoft Edge و Apple Safari WebAuthn ، مما زاد بشكل كبير من وصوله وقابليته للاستخدام. الآن هو مدعوم من قبل العديد من الأجهزة المتقدمة.
فوائد webAuthn:
أمان محسّن: يقضي على الاعتماد على كلمات المرور، مما يقلل من الضعف أمام الاحتيال، وهجمات القوة الغاشمة، وهجمات إعادة التشغيل.
تجربة المستخدم المحسنة: تقدم عملية تسجيل الدخول بشكل أبسط وأسرع في كثير من الأحيان، غالبًا ما يكون فقط بالضغط أو التحقق البيومتري.
حماية الخصوصية: لا تتم نقل أي أسرار مشتركة أثناء المصادقة، ولا تتلقى المواقع الفردية أي معلومات تعريف شخصية.
التوسع والمعيارية: كمعيار ويب، يضمن WebAuthn التناسق والتوافق عبر المتصفحات والمنصات المختلفة.
جهاز مرتبط بـ WebAuthn، على سبيل المثال. الحصن الآمن
في الحالات الحديثة، يمكننا استخدام معالج الأجهزة كجهاز موثق، مثل الحاجز الآمن لأجهزة Apple، ومنطقة الثقة لنظام Android، وStrongbox لهاتف Google Pixel.
إنشاء مفتاح: باستخدام التشفير بالمفتاح العام، يتم إنشاء زوج مفاتيح وفقًا لمعايير WebAuthn، عادة باستخدام منحنى P-256 r1. يتم إرسال المفتاح العام إلى الخدمة، بينما لا يترك المفتاح الخاص أبدًا Secure Enclave. المستخدم لا يتعامل أبدًا مع المفتاح النصي العادي، مما يجعل من الصعب التعرض للخطر للمفتاح الخاص.
تخزين المفاتيح: يتم تخزين المفتاح الخاص بشكل آمن داخل Secure Enclave الخاص بالجهاز ، وهو نظام فرعي محصن منفصل عن المعالج الرئيسي. إنه يحمي البيانات الحساسة ، مما يضمن أنه حتى في حالة اختراق النظام الرئيسي ، تظل المواد الرئيسية الخام غير قابلة للوصول. شريط اختراق Secure Enclave مرتفع للغاية ، وبالتالي يتم تخزين أنواع البيانات الأكثر حساسية مثل بيانات Apple Pay و FaceID هناك. فيما يلي شرح متعمق لكيفية عمل SE.
المصادقة: يستخدم المستخدمون التعرف على الوجه أو بصمة الإصبع للوصول، والمهاد الآمن يستخدم المفتاح الخاص لتوقيع تحدي من الخدمة، والخدمة تتحقق باستخدام المفتاح العام.
مزايا webAuthn القائمة على الجهاز:
الأمان على مستوى الأجهزة: باستخدام الحصن الآمن، وهو مدير مفتاح معزول يعتمد على الأجهزة لتوفير طبقة إضافية من الأمان.
مقاومة الصيد: لا تشمل إدخال أي معلومات على الأجهزة أو المواقع المحتمل تعرضها للخطر.
تجربة مريحة: يوفرون تجربة أكثر ودية للمستخدم. لم يعد المستخدمون بحاجة إلى تذكر كلمات مرور معقدة لمواقع مختلفة.
عيوب تسجيل الدخول على الويب القائم على الجهاز:
قيود الجهاز: لا يمكن تصدير أو استرداد المفتاح الخاص إذا تم فقدان الجهاز أو تضرره، والتشغيل بين الأجهزة غير ممكن.
المصادقة عبر الويب القائمة على السحابة، مفتاح المرور
في مواجهة تحدي الوظائف عبر الأجهزة، قدمت الشركات التكنولوجية تنفيذًا قائمًا على السحابة لنظام webAuthn، تعتبر Passkey مألوفة على نطاق واسع بسبب Apple.
دعونا نأخذ مفتاح البابل الخاص بشركة Apple كمثال:
إنشاء المفتاح: يقوم جهاز macOS أو iOS أو iPadOS الخاص بالمستخدم، كوسيلة المصادقة، بإنشاء زوج مفتاح عام-خاص عند إنشاء المستخدم للحساب. ثم يُرسل المفتاح العام إلى الخادم، ويتم تخزين المفتاح الخاص على سلسلة مفاتيح iCloud الخاصة بالجهاز. يتم تشفير بيانات سلسلة مفاتيح iCloud بمفتاح مقترن بالأجهزة، ويتم تخزينها في وحدة أمان معدنية (HSM). المفتاح غير قابل للوصول من قبل Apple.
المزامنة عبر الأجهزة: سيكون هذا العملية نفسها كما في الوصول إلى iCloud. قم بالمصادقة على حساب iCloud، واستلم رمز SMS، وأدخل رمز المرور لأحد الأجهزة.
مزايا تقنية webAuthn القائمة على السحابة:
Cross-device: تم تصميم مفاتيح المرور لتكون مريحة ومتاحة من جميع الأجهزة المستخدمة بانتظام. ولكنها محدودة حاليًا لأجهزة Apple، أما بالنسبة لنظام Android، فإن الأمر أكثر تحديًا بسبب تنوع الإصدارات والتباينات في الأجهزة الخاصة به.
مقاومة الصيد الاحتيالي: نفس الشيء كما ذكر أعلاه.
تجربة مريحة: نفس الشيء كما هو مذكور أعلاه.
عيوب تقنية السحابية للمفتاح الرقمي:
الاعتماد على خدمة السحابة: بالمقارنة مع تسجيل الويب القائم على الجهاز، يقوم مفتاح السحابة بنقل مستوى الأمان من الأجهزة الأمنية المضمنة إلى سلسلة مفاتيح iCloud، قد يُعتبر بعض الأشخاص أنه يعتمد على خدمة السحابة. يجب مراعاة بعض الجوانب الرئيسية مثل: تعرض حساب AppleID الخاص بالمستخدم لـ iCloud؛ بينما يستخدم سلسلة مفاتيح iCloud تشفيرًا من النهاية إلى النهاية لحماية البيانات، تشكل الأخطاء التشغيلية أو الثغرات خطرًا.
القيود على المنصة: على سبيل المثال، استخدام مفتاح مرور مستند إلى iCloud على جهاز Android يعتبر تحديًا للغاية. وعلاوة على ذلك، على عكس الأساليب التقليدية، لا تقوم Apple و Google بإرسال تأكيدات خاصة بالجهاز. وهذا يعني أنه من المستحيل حاليًا التحقق من نوع الجهاز الذي أنشأ مفتاحًا، مما يثير تساؤلات حول موثوقية المفتاح والبيانات الوصفية المرتبطة به.
حتى الآن، يمكننا رؤية الحفاظ على أمان مستوى الأجهزة بينما نتناول التوافق بين الأجهزة والمنصات المختلفة كتحدي. مما لا يقل أهمية هو الخيار الاجتماعي للاستعادة، مثل إضافة حراس متعددين لتعزيز الأمان. في هذا السياق، يمكن للبلوكشين أن يوضح لنا الطريق.
هناك فجوة ملحوظة عند محاولة تنفيذ web2 webAuthn إلى web3: يتطلب Web2 فقط إثبات الملكية، بينما يتطلب web3 أيضًا تفويض الصفقة في نفس الوقت. مع Passkey، يفتقر المطورون إلى السيطرة على رسالة التوقيع، التي تكون عادةً عامة، مثل 'تسجيل الدخول'. يمكن أن يؤدي هذا إلى تلاعب محتمل في الواجهة الأمامية، حيث يقوم المستخدمون بتوقيع الرسائل بشكل عمي، وهو مصدر قلق يبدو غير مهم ولكنه حاسم.
حسابات العقود الذكية (SCA)، العقود الذكية بحد ذاتها، تعمل ككيانات على السلسلة الذاتية القدرة على تعيين الموقعين التعسفيين. تتيح هذه المرونة برمجة أجهزة ومنصات مختلفة - مثل ضبط هاتف Android و Macbook و iPhone - كموقعين. وعلاوة على ذلك، يسمح حساب العقد الذكي النمطي بالقابلية للترقية، بالتبديل بين موقعين جديدين، وتغيير حد التوقيع من 2 من بين 3 إلى تكوينات أكثر تعقيدًا.
تصوّر محفظة تكيف متطلبات أمانها استنادًا إلى السياق: تسمح بالمصادقة من مُعدٍّ واحد عندما يكون المستخدم على عنوان IP المحلي المألوف، ولكنها تتطلب مصادقة من مُعدّين متعددين للمعاملات من عناوين IP غير معروفة أو فوق قيمة معينة. مع القابلية للتعديل والقدرة على البرمجة، الخيال هو الحد الوحيد لمثل هذه الابتكارات. العديد من مزودي خدمات SCA يبنون بنشاط في هذا المجال، بما في ذلك Safe وZerodev وBiconomy وEtherspots وRhinestone، وما إلى ذلك. كما نشيد بالبنية التحتية مثل Stackup وPlimico وAlchemy التي تجعل ذلك ممكنًا.
يرجى التحقق من أبحاثي السابقة التي توفر سياقًا أشمل حول SCA.
يمكن للEOAs تحقيق الاسترداد الاجتماعي والتوافق عبر الأجهزة / المنصات من خلال خدمات MPC. على الرغم من وجود موقع الEOAs الثابت، يمكن لمزودي MPC تقسيم المفاتيح إلى حصص لتعزيز الأمان والمرونة. هذه الطريقة تفتقر إلى ميزات SCA القابلة للبرمجة والقابلة للترقية، مثل الاسترداد الزمني وإلغاء المفتاح بسهولة. ومع ذلك، فإنها ما زالت توفر قدرات فائقة عبر السلاسل عن طريق كونها سلسلة غير محددة وحاليا أكثر فعالية من SCAs. مزودي MPC الملحوظين بما في ذلك Privy, Particle Network, web3Auth, محفظة OKX, محفظة Binance، إلخ.
لنلق نظرة عامة لفهم السياق: في إيثريوم، تكون المفاتيح الخاصة أرقام عشوائية مختارة من منحنى k1، وعملية التوقيع تستخدم أيضًا هذا المنحنى.
ومع ذلك، تستخدم أزواج المفاتيح التي تم إنشاؤها وفقًا لمعايير WebAuthn منحنى r1. لذلك، فإن التحقق من توقيع r1 على Ethereum يكلف تقريبًا ثلاث مرات أكثر من توقيع k1. إليك بعض الطرق لمعالجة هذا:
الشكر لدوغان، للمزيد من المعرفة العميقة يرجى التحقق من بحثه.
حل البروتوكول:
الحل: EIP7212، المعدل المُعد مُسبقًا لدعم منحنى secp256r1 المقترح من فريق Clave.
التقييم: تقوم هذه المقترحات بإنشاء عقد معد مسبقًا يُنفذ تحقق التوقيعات في منحنى الإليبتيك "secp256r1" بواسطة معطيات تجزئة الرسالة، ومكونات r و s للتوقيع، وإحداثيات x و y للمفتاح العام. بحيث يكون بإمكان أي سلسلة EVM - وعلى رأسها تقوم أيثريوم رول أبس - بدمج هذا العقد المعد مسبقًا بسهولة. حتى الآن، قد يكون البروتوكول المعد مسبقًا هو الحل الأكثر كفاءة من حيث الغاز.
تنفيذ: zkSync
خدمة طرف ثالث
الحل: جاهز للاستخدام
التقييم: يضمن تقييم TEE التركي أن يكون المفتاح الخاص قابلًا للوصول فقط للمستخدم عبر مفتاح العبور الخاص بهم ولا يمكن الوصول إليه أبدًا من قبل Turnkey نفسه، ومع ذلك، يتطلب هذا لا يزال حيوية الخدمة.
التنفيذ: Goldfinch
حلول التحقق من صلادة العقود الذكية:
الحل: مدقق صلابة FCL، مدقق صلابة FCL مع الحساب المسبق، مدقق P256 من دايمو
التنفيذ: كلافي، محفظة واضحة
التحقق من الصفر المعرفة (ZK):
الحل: Risc0 Bonsai، هالو2-ecc من أكسيوم
التقييم: تستفيد هذه الطريقة من البراهين بدون معرفة للتحقق من الحسابات خارج آلة الحسابات الظاهرية للإيثيريوم (EVM)، مما يقلل من تكاليف الحوسبة على السلسلة.
تنفيذ: محفظة الحريق (ريسك0)، مختبرات لا تعرف شيئًا (أكسيوم)
كل من هذه الحلول تقدم طريقة مختلفة لتمكين التحقق من توقيع r1 بأسعار أرخص وممكنة في نظام الأثيريوم، وهنا تقييم من قبل Dogan.
*يرجى ملاحظة أنه اعتبارًا من ديسمبر 2023، فإن معظم هذه الحلول في مراحلها الأولى وقد تتغير أو تتحسن في أي وقت. هذه الأمثلة مخصصة فقط لأغراض التعلم؛ يرجى الرجوع دائمًا إلى مواقعهم الرسمية للحصول على معلومات دقيقة.
الأساسيات:
تجربة: https://getclave.io/
الحساب: SCA
Chain: ZkSync
عملية الصفقة:
إنشاء المفتاح: يقدم المستخدم المصادقة الحيوية مثل بصمة الإصبع أو التعرف على الوجه، حيث يتم إنشاء زوج المفتاح داخل الملجأ الآمن، والذي لا يكشف أو يترك خارجه أبدًا.
التوقيع الرئيسي: تقوم التطبيق بأخذ رسالة المعاملة المطلوبة وإرسال طلب توقيع إلى القفل الآمن، يقدم المستخدم المصادقة الحيوية للموافقة على التوقيع، ويقوم القفل الآمن بتوقيع الرسالة بالمفتاح، ويتم بثها إلى عقد البلوكشين.
وظائف إضافية: يتيح حساب العقد الذكي العديد من الوظائف القوية. أولا، رعاية الغاز. نظرا لمدير الدفع ، يمكن لأطراف أخرى مثل dApp أو المعلنين دفع رسوم الغاز للمستخدم ، مما يجعل عملية المعاملة أكثر سلاسة ، كما يمكنهم السماح للمستخدمين بدفع الغاز في ERC20 بدلا من Ether أو الرمز الأصلي. وباستخدام مفتاح الجلسة ، يمكن للمستخدم إجراء معاملة بدون توقيع في فترة زمنية.
آلية الاسترداد:
يتم تنفيذ عملية الاستعادة بواسطة عقد Clave الذكي على zkSync، حيث يمكن للمستخدم إلغاء عملية الاستعادة خلال قفل زمني لمدة 48 ساعة، لمنع الأنشطة غير المصرح بها والخبيثة.
يتم إنشاء EOA عندما يختار المستخدم النسخ الاحتياطي في السحابة، ومفتاح الخاص لـ EOA يتم تخزينه إما في iCloud أو Google Drive، يمكن للمستخدم استخدام هذا المفتاح الخاص المخزن في السحابة للوصول إلى حسابه من جهاز مختلف، ويمكن للمستخدمين إزالة أو استبدال هذا القسم الاحتياطي في أي وقت.
الاسترداد الاجتماعي: يمكن للمستخدم تعيين عنوان عنوان عائلته أو صديقه كنسخة احتياطية، إذا قدم M من N الأوصياء تأكيدًا للاسترداد، سيتم تنفيذ الاسترداد بعد 48 ساعة من التأمين إذا لم يتم الغاءه.
الأساسيات:
تجربة: https://alpha.soulwallet.io/wallet
حساب: ERC4337 SCA
Chain: Ethereum, Optimism, Arbitrum, and soon all EVM layer2
عملية العملية:
إنشاء مفتاح: يقدم المستخدمون المصادقة البيومترية مثل البصمة أو التعرف على الوجه، ويقوم نظام التشغيل بإنشاء مفتاح مرور ويقوم بنسخه احتياطيًا باستخدام خدمة السحابة. يمكنك إضافة أكثر من مفتاح مرور عبر الأجهزة والمنصات المختلفة.
إضافة الحراس (اختياري): يمكن للمستخدم تعيين عناوين EVM EOA مختلفة كحراس وإعداد عتبة لاستعادة الحساب.
إنشاء الحساب: باستخدام النشر المضاد، لا يحتاج المستخدمون إلى دفع أي رسوم حتى أول عملية تحويل
آلية الاسترداد:
مفتاح المرور: استخدم أي مفتاح مرور محدد لتسجيل الدخول إلى المحفظة باستخدام جهاز عشوائي.
استعادة حراس المعلومات: يمكن للحراس المعينين تدوير المحفظة وفقًا للحد الأدنى، وقد يتم التعامل في وقت لاحق مع قفل زمني لمنع السلوك الخبيث.
أساسيات:
عرض توضيحي: https://www.okx.com/help/what-is-an-aa-smart-contract-wallet
Chain: 30+ chains
المفتاح: MPC-TSS، 2/3
الحساب: 4337 SCA
عملية العملية:
إنشاء المفتاح: من خلال إنشاء محفظة، يحول OKX مفتاح خاص واحد إلى ثلاثة أسهم منفصلة. يتم تخزين السهم 1 في خادم OKX، ويتم تخزين السهم 2 على تخزين الجهاز المحلي للمستخدم، ويتم إنشاء السهم 3 بواسطة الجهاز، وتشفيره ويمكن نسخه إلى خدمات السحابة المفضلة على الجهاز، مثل Google Cloud، iCloud، وHuawei Cloud.
توقيع المفتاح: يمكن لمستخدم OKX استخدام تقنية MPC-TSS للحصول على التوقيع الكامل باستخدام إحدى العملتين من ثلاثة مفاتيح خاصة عند توقيع المعاملة، ولا تلتقي المفاتيح الخاصة أبدًا خلال هذه العملية.
آلية الاسترداد:
آلية 2/3: عند تسجيل خروج المستخدم، أو عند عدم توفر الجهاز، أو عند تعرض أحد المفاتيح على الجهاز للاختراق، يمكنك استخدام جهاز جديد لتسجيل الدخول إلى محفظة OKX (الحصول على حصة الخادم) والحصول على حصة الخدمة السحابية، ثم دمج هاتين الحصتين لاستعادة المحفظة، ستقوم محفظة OKX بإنشاء حصص سرية جديدة.
الأساسيات:
Demo: https://w3a.link/passkeysDemo
سلسلة: جميع EVM و Solana
Key: MPC-TSS، عادة ما يكون 2/3
الحساب: أي حساب مثل EOA، 4337 SCA أو SCA العام
عملية الصفقة:
إنشاء المفتاح: من خلال إنشاء محفظة، يتم إنشاء ثلاثة مشاركات مفتاحية. المشاركة1 هي مشاركة تسجيل الدخول الاجتماعية، يمكن للمستخدم إدخال بريدهم الإلكتروني، وشبكة لامركزية من العقد تقوم بتخزين المفتاح لكل مستخدم؛ المشاركة2 هي مشاركة الجهاز التي تُخزن على تخزين الجهاز المحلي للمستخدم؛ المشاركة3 تتم إنشاؤها بواسطة الكمبيوتر المحلي ويتم نسخها احتياطيًا عن طريق خدمات السحاب المفضلة لدى المستخدم.
توقيع المفتاح: تضمن بنية Web3Auth MPC-TSS أن مفتاح المستخدم متاح دائما ، حتى باستخدام توقيع العتبة ، لا يتم إعادة بناء المفاتيح أو تخزينها في مكان واحد.
آلية الاسترداد:
استرجاع الحد عند تسجيل خروج المستخدم، جهاز غير متاح أو أحد المفاتيح على الجهاز معرض للخطر، يمكنك استخدام طريقة تسجيل الدخول الاجتماعية لتسجيل الدخول إلى حساب webAuthn والحصول على مشاركة سحابية للمفتاح المروري، ودمج هاتين المشاركتين لاستعادة المحفظة.
معلومات أساسية:
تجربة:https://lit-pkp-auth-demo.vercel.app/
سلسلة: معظم EVM، Cosmos، Solana.
الحساب: MPC-TSS، 20 من 30 شبكة، يمكن اعتماده من قبل SCA و EOA.
عملية الصفقة:
إنشاء المفتاح: عندما يرغب المستخدم في إنشاء محفظة، يجب أن يختار أولاً طريقة المصادقة (مفتاح المرور، تسجيل الدخول الاجتماعي باستخدام oAuth)، ثم يتم إرسال طلب إلى الوسيط لإنشاء أزواج المفاتيح وتخزين منطق المصادقة في العقد الذكي. يتم إنشاء كل زوج مفاتيح جماعياً من قبل عقد Lit nodes من خلال عملية تسمى توليد المفتاح الموزع (DKG). ويعمل كشبكة لامركزية، حيث يعمل 30 عقد Lit nodes داخل TEE، حيث يحتوي كل عقد على حصة من المفتاح ولكن المفتاح الخاص لا يوجد بشكل كامل.
توقيع المفتاح: بعد استلام الطلب، تقوم العقد الخفيفة بالتحقق أو رفض الطلب بشكل مستقل ضد طريقة المصادقة المعينة، و باستخدام تقنية MPC-TSS، يتم جمع حصص المفتاح فوق الحد (20 من أصل 30) لتوليد توقيع وتجميعها بواسطة العميل لإكمال الطلب.
آلية الاسترداد:
آلية 2/3: استخدام طرق المصادقة المخزنة في العقد الذكي للوصول إلى الحساب، تقوم العقدة المضاءة بالتحقق من الطلبات وسيتم الموافقة عليها إذا كان أكثر من 2/3 من العقد يؤكدون.
مدفوعة بالحماس لطبقة2، طبقة3، وحلول توافر البيانات، نحن حريصون على تحسين أداء تقنية البلوكشين. كما نسعى لتحقيق أمان حقيقي، عبر دمج خصوصية البرهان الصفري مع طبيعة الشفافية. جميع الجهود تستهدف هدفًا واحدًا: أن نكون جاهزين للمستخدمين الحقيقيين الذين يتفاعلون بشكل متكرر مع تقنية البلوكشين ويعتمدون على العملات الرقمية في حياتهم.
من السهل أن تُقع في حلم تقنية مثالية، لكن علينا أن نسأل: أي نوع من التجربة نهدف إليه؟ نحن نتصوّر عالمًا حيث تكون العملات الرقمية مرتبطة بالحدس بدلاً من المصطلحات التقنية المربكة، حيث يقفز المستخدم إلى حفرة الأرنب دون تردد أو عناء.
تخيل مستخدمة تدعى روي: اكتشفت تطبيقًا لامعًا، وسجلت فيه بسهولة باستخدام التعرف الضوئي على الوجه أو بصمة الإصبع، مع خيار إعداد نسخ احتياطية أو وصيون. وأثناء تفاعلها مع التطبيق، تُنفذ المعاملات بسلاسة، ربما برسوم صغيرة للـ ERC20 أو حتى بدون رسوم على الإطلاق. في وقت لاحق، تُخصص إعدادات محفظتها - ربما تنشط قفل الوقت للمعاملات التلقائية، وتضيف جهازًا آخر كوقّع احتياطي، أو تُعدّل قائمتها للوصيون.
يجعل مشروعونا ذلك يحدث. من خلال دمج WebAuthn and Passkey، نقوم بتعزيز إدارة المفتاح الخاص، مما يجعلها آمنة وسهلة الاستخدام. علاوة على ذلك، يفتح SCA ككيان مجالًا للأمان والوظائف الشخصية. وأما بالنسبة لرسوم الغاز؟ تصبح أقل عبئاً، بفضل موفري Paymaster الذين يمكنهم إنشاء 'خزانة' للتبادلات أو حتى السماح للمعلنين بتغطية الرسوم للمستخدمين. في قلب هذا التطور، وخاصة بالنسبة إلى شبكة Ethereum mainnet وما يعادلها من Layer2s، يأتي ERC4337. إنه يقدم mempool بديلًا يفصل معاملات SCA عن EOAs، دون تغييرات كبيرة في البروتوكول. من ناحية أخرى، بعض شبكات Layer 2 تعتني حتى بـ SCAs بشكل أصلي، مدمجة بسلاسة في أنظمتها.
يتطلب جهودا هائلة لتسهيل كل شيء. هناك العديد من التحديات مثل خفض رسوم النشر والتحقق والتنفيذ لـ SCA؛ توحيد الواجهة لزيادة توافق الحسابات؛ مزامنة حالة الحساب عبر السلسلة؛ والعديد من الأمور الأخرى. الفضل لجميع البناة، نحن نقترب من حل اللغز يوما بعد يوم. ومشاريع العملات الرقمية مثلنا - SevenX، على استعداد لمساعدة الشركات الكبيرة في تحقيق رؤيتها.
المفتاح الخاص هو النواة التي تسمح لنا بتوقيع المعاملات على الإيثيريوم، لكن إدارته كانت كابوسًا، حتى في الشكل القابل للقراءة لـ 'عبارات البذور'. ومع ذلك، كان هدفنا أبدًا تحويل تقنية البلوكشين إلى لعبة معقدة.
مصادقة المستخدمين المصرح بهم أمر حاسم للمعاملات الآمنة. مع تطور أمان الإنترنت وتجربة المستخدم، لقد انتقلنا من مصادقة كلمة المرور إلى التحقق الحيوي مثل التعرف على الوجه وبصمات الأصابع. تعد WebAuthn تطورًا رئيسيًا في هذا التقدم. يناقش هذا المقال عن كثب ثلاث مصطلحات:
WebAuthn: يستخدم معيار مصادقة الويب بيانات الاعتماد المستندة إلى المفتاح العام ، والتي غالبا ما يتم إنشاؤها بواسطة مصادقين خارجيين. إنه يلغي الحاجة إلى كلمات المرور ويتيح مصادقة المستخدم الآمنة.
المخزن الآمن: منطقة آمنة مبنية على الأجهزة ضمن أجهزة الحوسبة، ويتم تصميم المخزن الآمن لحماية البيانات الحساسة. تم العثور على إصدارات من المخزن الآمن في أجهزة iOS وAndroid وWindows. يمكن أن يكون مخزن الآمن موثقًا بشكل آمن من خلال تنفيذ WebAuthn، ولكن المفتاح الخاص، المرتبط بالمخزن الآمن، في كثير من الأحيان يُعَرِضُ لتحديات عبر الأجهزة.
Passkey: تطبيق لـ WebAuthn على مستوى نظام التشغيل، مخصص من قبل مختلف مزودي الأجهزة والأنظمة. على سبيل المثال، يستخدم Passkey الخاص بـ Apple المفتاح المخزن في سلسلة مفاتيح iCloud لمزامنة الأجهزة عبر الأجهزة. ومع ذلك، يكون هذا النهج عادة مقفلاً على منصات أو أنظمة محددة.
كما هو موضح أعلاه، تتماشى تنفيذات webAuthn مع هدفنا لمستخدمي سلسلة الكتل اليوميين، لتحقيق أمان مكافحة الاحتيال على مستوى عال وتجربة ودية. إليك الفكرة لدمجها في سلسلة الكتل:
الطبقة الرئيسية: يقوم المستخدمون بالمصادقة باستخدام طرق بيومترية سلسة مثل التعرف على الوجه أو بصمة الإصبع. تحت الغطاء، إنها المعالجة الأمنية القائمة على الأجهزة مثل Secure Enclave أو خدمات السحابة مثل iCloud و Google Cloud التي تتعامل مع إدارة المفاتيح. سأتناول مشكلات الجهاز العابر ومشاكل النظام العابرة لاحقًا.
الطبقة الحسابية: يوفر حساب العقد الذكي (SCA) القدرة على تعيين الموقعين التعسفيين (على سبيل المثال SE و Passkey) وآليات العتبة. علاوة على ذلك، تعزز التصميم النمطي لها مرونة وقابلية للترقية. على سبيل المثال، يمكن لـ SCA تكييف متطلبات التوقيع الخاصة بها ديناميكيًا استنادًا إلى عوامل مثل مبلغ المعاملة أو الوقت أو عنوان IP. من ناحية أخرى، يمكن تعزيز حساب الممتلكات الخارجية التقليدي (EOA) بخدمات MPC، وتقدم مجموعتها هذه توافقًا أفضل وكفاءة تكلفة مقارنة بـ SCA، على الرغم من أنها تفتقر إلى وظائف متقدمة تقدمها SCAs، خاصة بالنسبة لتدوير المفاتيح.
طبقة التوقيع: يدعم Ethereum أصلا منحنى k1 ، لكن التحقق من توقيع WebAuthn يتحمل تكاليف أعلى ، لأنه يستخدم منحنى r1 لتوليد المفاتيح. لذلك ، فإن بعض حلول الطبقة 2 مثل zkSync ، والتخطيط على منحنى EIP-7212 r1 الأصلي يتم تجميعه مسبقا. بالإضافة إلى ذلك ، هناك خدمات الجهات الخارجية ، ومدققات الصلابة ، ومدققات المعرفة الصفرية (ZK) ، وأنظمة إدارة المفاتيح الموزعة ، لتسهيل توقيع منحنى r1 بطريقة أكثر فعالية من حيث التكلفة.
تنصيح بعدم المسؤولية:
التقدم التكنولوجي لا يضمن نجاح السوق؛ ليس جميع الأجهزة والمنصات قد اعتمدت Passkey؛ استخدام SCA قد يكون أكثر تكلفة من EOA؛ الحل المقترح يتطور مع التقدم التكنولوجي.
في مجال البلوكشين، فإن السيطرة الحقيقية على أصول البلوكشين ليست بيد المستخدم أو موفر المحفظة، وإنما تكمن في المفتاح الخاص. هذا المفتاح هو الأكثر أهمية لعملية تنفيذ عملية تحويل على إيثيريوم. لفهم هذا بشكل أفضل، دعونا نأخذ EOA كمثال:
توليد المفاتيح: يعمل رقم عشوائي محدد من المنحنى الإهليلجي secp256k1 كمفتاح خاص. ثم يتم ضرب هذا المفتاح بنقطة محددة مسبقا على المنحنى لإنشاء المفتاح العام. عنوان Ethereum مشتق من آخر 20 بايت من المفتاح العام المجزأ. عادة ما يتم تقديم "العبارة الأولية" للنسخ الاحتياطي الذي يمكن قراءته من قبل الإنسان ، مما يتيح الاشتقاق الحتمي للمفاتيح الخاصة والعامة.
توقيع المعاملات: يتم توقيع معاملة تحتوي على تفاصيل مثل عدم تكرار (رقم تسلسلي)، المبلغ، سعر الغاز، وعنوان المستلم باستخدام المفتاح الخاص. يُولد توقيع يتألف من قيم (r، s، v)، باستخدام عملية تشمل ECDSA، وهو خوارزمية توقيع رقمية تستخدم تشفير المنحنى البيضاوي وتعتمد secp256k1 كمنحنى. تُذاع التوقيع والمعاملة الأصلية على الشبكة بعد ذلك.
التحقق من المعاملات: بمجرد وصول المعاملة إلى عقدة Ethereum، تخضع لعملية التحقق في مسبح الذاكرة الخاص بالعقدة. للتحقق من الموقع، تستخدم العقدات التوقيع والمعاملة المجزأة لاشتقاق المفتاح العام للمرسل وتأكيد مصداقية المعاملة عن طريق مطابقة العنوان المشتق مع عنوان المرسل.
كما هو موضح أعلاه، فإن المفتاح الخاص Entitي هو كيان أساسي على السلسلة. في الأصل، كانت حسابات Ethereum، المعروفة باسم الحسابات المملوكة خارجيًا (EOAs)، تعتمد فقط على مفتاح خاص واحد، مما يشكل مخاطر كبيرة، حيث أن فقدان المفتاح يعني فقدان الوصول إلى الحساب.
قد يعتقد الكثيرون أن Account Abstraction (AA) هو الحل لكل ما يتعلق بتجربة المستخدم السيئة ، والتي سأقول ليس بالضبط. يتعلق AA بتغيير قواعد الصلاحية لتكون قابلة للبرمجة ، وقابلية برمجة حساب العقد الذكي (SCAs) تجعل ذلك ممكنا. AA قوي ، ويتيح إرسال معاملات متعددة بالتوازي (nonce المجردة) ، ورعاية الغاز ودفع الغاز في ERC20 (الغاز المجرد) ، وأكثر صلة بموضوع هذه المقالة ، لكسر التحقق من صحة التوقيع الثابت (توقيع ECDSA المجرد). بدلا من EOA، يمكن ل SCAs تعيين موقعين تعسفيين وآليات توقيع مثل التوقيع المتعدد (multisigs) أو مفاتيح النطاق (مفاتيح الجلسة). ومع ذلك ، على الرغم من المرونة والتقدم في قابلية الترقية ل AA ، فإن الاعتماد الأساسي على المفتاح (المفاتيح) لتوقيع المعاملات لم يتغير.
حتى عند تحويلها إلى عبارة بذور مؤلفة من 12 كلمة، يظل إدارة المفتاح الخاص تشكل تحديًا، مما يتسبب في مخاطر فقدان أو هجمات احتيال. يجب على المستخدمين التنقل بين طبقات معقدة من الحلول اللامركزية أو الاحتضان الدافئ للخدمة المركزية، ولا أحدهما مثالي.
لماذا تكون تجربة مجال العملات الرقمية سيئة؟ يعود جزء كبير من ذلك إلى سوء إدارة المفاتيح. دائمًا ما يتطلب تحقيق التوازن بين التجربة والأمان واللامركزية. يستكشف هذا المقال الحلول الأمثل المحتملة لإدارة المفتاح.
لن يكون هناك أبدًا حلاً مناسبًا للجميع، أفضل طريقة للحفاظ على المفتاح مصممة خصيصًا لسيناريوهات المستخدم المحددة، تحت تأثير عوامل مثل نوع المستخدم (مؤسسي أو فردي)، مبلغ رأس المال، تردد المعاملات، وأنواع التفاعل.
للتوضيح مسبقًا، أتجنب استخدام أساليب 'الاحتفاظ الذاتي والشبه والكامل' الشهيرة للتصنيف. في رأيي، يعني الاحتفاظ الذاتي الحقيقي توقيع عملية بشكل مستقل، دون الاعتماد على طرف آخر، وهذا ينطبق حتى لو لم تكن الحلول إيداعية بالمعنى التقليدي (مثل تخزينها في عقد الثقة التابع للعقد الذكي في العقد الليني). تصنيف الحلول على أنها 'جيدة' أو 'سيئة' استنادًا إلى نوع الاحتفاظ يعتبر بسذاجة ولا يأخذ في الاعتبار ملاءمتها المتنوعة. لتقييم أكثر دقة لأساليب إدارة المفاتيح، أقترح تحليلها من خلال ثلاث طبقات متميزة:
ما إذا كان تقسيم مسؤولية إدارة مفتاح إلى أطراف مختلفة.
نظرًا لأن الأفراد غالبًا ما يواجهون تحديات في إدارة المفتاح، يظهر توزيع مسؤولية حماية المفتاح كاستراتيجية طبيعية للتخفيف من المخاطر. تشمل هذه الفئة أساليب مثل استخدام مفاتيح متعددة للتوقيع بشكل تعاوني، كما هو الحال في أنظمة التوقيع المتعدد (التوقيع المتعدد)، وتقسيم المفتاح الخاص إلى أجزاء من خلال مخطط مشاركة سرية (SSS) أو الحساب بالأطراف المتعددة (MPC).
التوقيع المتعدد: الذي يتطلب عدة مفاتيح خاصة كاملة لتوليد تواقيع المعاملات. يتطلب هذا الأسلوب التواصل على السلسلة حول الموقعين المختلفين، مما يتسبب في زيادة رسوم المعاملات، ويؤثر على الخصوصية لأن عدد الموقعين مرئي على السلسلة.
SSS: يتم إنشاء مفتاح خاص في موقع واحد، ويوزع الوكيل قطعًا من هذا المفتاح على أطراف مختلفة. يجب على جميع الأطراف إعادة بناء المفتاح الخاص بالكامل لتوقيع عملية معينة. ومع ذلك، قد تؤدي هذه العملية المؤقتة لإعادة البناء إلى إدخال نقاط ضعف.
MPC-TSS (مخطط توقيع العتبة): كتطبيق ل MPC ، نهج تشفير يمكن العديد من الأطراف من إجراء العمليات الحسابية مع الحفاظ على خصوصية مدخلاتهم بشكل مشترك. يقوم كل طرف بشكل مستقل بإنشاء مشاركة مفتاح سرية ، ويتم توقيع المعاملات دون الحاجة إلى تلبية هذه الأطراف فعليا. يقدم رسوما أقل لأنه خارج السلسلة ، ولا توجد نقطة واحدة لخطر الفشل مثل SSS.
قم بتخزين المفتاح أو الحصص، المتأثرة بعوامل الأمان والوصول والتكلفة واللامركزية.
الخدمات السحابية المركزية مثل AWS، iCloud والخوادم الأخرى. إنها مريحة للمعاملات المتكررة، ولكنها أكثر عرضة للرقابة.
تخزين لامركزي مثل IPFS و Filecoin.
الكمبيوتر/الهاتف المحلي: يتم تخزين المفاتيح محليًا داخل تخزين المتصفح الآمن.
المحافظ الورقية: طباعة فيزيائية لمفاتيح خاصة أو رموز الاستجابة السريعة.
بيئة التنفيذ الموثوقة (TEE): TEE توفر منطقة آمنة داخل المعالج الرئيسي لتنفيذ أو تخزين البيانات الحساسة، معزولة عن نظام التشغيل الرئيسي.
المخزن الآمن: المخزن الآمن في الأجهزة الحديثة معزول عن المعالج الرئيسي لتوفير طبقة إضافية من الأمان ومصمم للحفاظ على بيانات المستخدم الحساسة آمنة حتى عندما يتعرض نواة معالج التطبيق للاختراق.
محافظ عتادية: أجهزة فيزيائية مثل ليدجر وتريزور، مصممة خصيصًا لتخزين مفاتيح خاصة بشكل آمن.
وحدة الأمان الأجهزة (HSM): تعتبر HSMs أجهزة أجهزة متخصصة مصممة لإدارة المفاتيح بشكل آمن والعمليات التشفيرية. عادة ما تستخدم في بيئات الشركات وتقدم ميزات أمان عالية المستوى.
كيفية التحقق من هوية المستخدم للوصول إلى المفتاح المخزن
يشارك المصادقة في الوصول إلى المفتاح المخزن. إنها تتعلق بالتحقق من أن الشخص الذي يحاول الوصول مخول فعلًا بذلك. إذا نظرنا إلى التاريخ، يمكننا تصنيف التاريخ مثل هذا:
شيء تعرفه: كلمات المرور، الأرقام السرية، إجابات على الأسئلة الأمنية، أو أنماط محددة.
شيء تمتلكه: تشمل البطاقات الذكية، الرموز المعتمدة على الأجهزة (كلمات المرور المؤقتة الزمنية)، أو عوامل رقمية مثل التحقق من حسابات التواصل الاجتماعي ورموز الرسائل النصية المرسلة إلى الهاتف.
شخص ما أنت: تتضمن خصائص مادية فريدة للمستخدم ، مثل بصمات الأصابع أو التعرف على الوجه (مثل Face ID من Apple أو Windows Hello) أو التعرف على الصوت أو مسح القزحية / شبكية العين.
على هذه الأساس، 2FA و MFA هما طرق تجمع بين عاملين أو أكثر، مثل رسائل SMS المرتبطة بإشعارات الدفع، لإضافة طبقات أمان إضافية إلى حسابات المستخدمين.
يُسمح لمستخدمي MetaMask باستخدام كلمة مرور للوصول إلى المفتاح المخزن في تخزين المتصفح المحلي للمستخدم.
تسمح محفظة Trust للمستخدمين باستخدام كلمة مرور أو FaceID للوصول إلى المفتاح المخزن في تخزين متصفح المستخدم المحلي، ويمكن للمستخدم أيضًا اختيار خدمة السحابة لنسخ احتياطي للمفتاح الخاص.
يسمح Privy للمستخدمين باستخدام طرق تسجيل الدخول الاجتماعية المتعددة مثل البريد الإلكتروني، باستخدام SSS لتقسيم ثلاثة أسهم:
مشاركة الجهاز: مستعرض-iFrame، الجوال- محمية الحصن.
مشاركة المصادقة: تم تخزينها بواسطة خاصية، رابط إلى معرف خاصيّ.
حصة الاستعادة: كلمة مرور المستخدم أو تشفيرها بواسطة Privy المخزنة في وحدة أمان الأجهزة (HSM).
يتيح لمستخدمي Particle استخدام تسجيل الدخول الاجتماعي، باستخدام MPC-TSS الذي يحتوي على حصتين:
مشاركة الجهاز: المتصفح - إطار الإطار
مفتاح الخادم المشترك: خادم بارتيكل
لقد كانت الحلول الحالية أعلاه حاسمة في تقديم المستخدمين إلى web3. ومع ذلك، فإنها غالبًا ما تأتي مع تحديات: يمكن نسيان كلمات المرور أو استهدافها في هجمات احتيال الصيد، وحتى 2FA، على الرغم من أنه أكثر أمانًا، يمكن أن يكون مرهقًا بخطواته المتعددة. بالإضافة إلى ذلك، ليس الجميع مرتاحين إلى إيثار طرف ثالث بإدارة المفتاح، المستخدمون مازالوا يعتمدون على توفر النظام وحية بينما تضمن بعض الخدمات أنهم لا يمكنهم الوصول إلى المفتاح.
هذا يدفعنا إلى التفكير في ما إذا كان هناك حلاً أكثر فعالية - واحد يقدم أقرب حلاً لتجربة مستخدم خالية من الثقة وعالية الأمان وسهلة الاستخدام. يقودنا هذا البحث إلى أساليب web2 الأمثل. عدة مصطلحات مرتبطة تضيق الخناق على الموضوع، كما وصفت في بداية المقال، WebAuthn هو المعيار نفسه للمصادقة، بينما تعتبر Secure Enclave و Passkey تنفيذات أو مكونات متعلقة بهذا المعيار.
WebAuthn
تقوم معيارات WebAuthn بتوحيد واجهة توثيق المستخدمين لتطبيقات الويب. يُتيح للمستخدمين تسجيل الدخول إلى حسابات الإنترنت باستخدام موثقات خارجية بدلاً من كلمة مرور. يمكن أن تكون الموثقات موثقات التجوال (Yubikey، Titan key) أو موثق أساسي (مضمن في سلسلة المفاتيح على أجهزة Apple)، وهكذا.
طور تحالف FIDO (Fast IDentity Online) في البداية التقنيات الكامنة وراء WebAuthn. تم الإعلان عنه رسميا كمعيار ويب من قبل W3C في مارس 2019 ، وإلى جانب توحيده ، اعتمدت المتصفحات الرئيسية مثل Google Chrome و Mozilla Firefox و Microsoft Edge و Apple Safari WebAuthn ، مما زاد بشكل كبير من وصوله وقابليته للاستخدام. الآن هو مدعوم من قبل العديد من الأجهزة المتقدمة.
فوائد webAuthn:
أمان محسّن: يقضي على الاعتماد على كلمات المرور، مما يقلل من الضعف أمام الاحتيال، وهجمات القوة الغاشمة، وهجمات إعادة التشغيل.
تجربة المستخدم المحسنة: تقدم عملية تسجيل الدخول بشكل أبسط وأسرع في كثير من الأحيان، غالبًا ما يكون فقط بالضغط أو التحقق البيومتري.
حماية الخصوصية: لا تتم نقل أي أسرار مشتركة أثناء المصادقة، ولا تتلقى المواقع الفردية أي معلومات تعريف شخصية.
التوسع والمعيارية: كمعيار ويب، يضمن WebAuthn التناسق والتوافق عبر المتصفحات والمنصات المختلفة.
جهاز مرتبط بـ WebAuthn، على سبيل المثال. الحصن الآمن
في الحالات الحديثة، يمكننا استخدام معالج الأجهزة كجهاز موثق، مثل الحاجز الآمن لأجهزة Apple، ومنطقة الثقة لنظام Android، وStrongbox لهاتف Google Pixel.
إنشاء مفتاح: باستخدام التشفير بالمفتاح العام، يتم إنشاء زوج مفاتيح وفقًا لمعايير WebAuthn، عادة باستخدام منحنى P-256 r1. يتم إرسال المفتاح العام إلى الخدمة، بينما لا يترك المفتاح الخاص أبدًا Secure Enclave. المستخدم لا يتعامل أبدًا مع المفتاح النصي العادي، مما يجعل من الصعب التعرض للخطر للمفتاح الخاص.
تخزين المفاتيح: يتم تخزين المفتاح الخاص بشكل آمن داخل Secure Enclave الخاص بالجهاز ، وهو نظام فرعي محصن منفصل عن المعالج الرئيسي. إنه يحمي البيانات الحساسة ، مما يضمن أنه حتى في حالة اختراق النظام الرئيسي ، تظل المواد الرئيسية الخام غير قابلة للوصول. شريط اختراق Secure Enclave مرتفع للغاية ، وبالتالي يتم تخزين أنواع البيانات الأكثر حساسية مثل بيانات Apple Pay و FaceID هناك. فيما يلي شرح متعمق لكيفية عمل SE.
المصادقة: يستخدم المستخدمون التعرف على الوجه أو بصمة الإصبع للوصول، والمهاد الآمن يستخدم المفتاح الخاص لتوقيع تحدي من الخدمة، والخدمة تتحقق باستخدام المفتاح العام.
مزايا webAuthn القائمة على الجهاز:
الأمان على مستوى الأجهزة: باستخدام الحصن الآمن، وهو مدير مفتاح معزول يعتمد على الأجهزة لتوفير طبقة إضافية من الأمان.
مقاومة الصيد: لا تشمل إدخال أي معلومات على الأجهزة أو المواقع المحتمل تعرضها للخطر.
تجربة مريحة: يوفرون تجربة أكثر ودية للمستخدم. لم يعد المستخدمون بحاجة إلى تذكر كلمات مرور معقدة لمواقع مختلفة.
عيوب تسجيل الدخول على الويب القائم على الجهاز:
قيود الجهاز: لا يمكن تصدير أو استرداد المفتاح الخاص إذا تم فقدان الجهاز أو تضرره، والتشغيل بين الأجهزة غير ممكن.
المصادقة عبر الويب القائمة على السحابة، مفتاح المرور
في مواجهة تحدي الوظائف عبر الأجهزة، قدمت الشركات التكنولوجية تنفيذًا قائمًا على السحابة لنظام webAuthn، تعتبر Passkey مألوفة على نطاق واسع بسبب Apple.
دعونا نأخذ مفتاح البابل الخاص بشركة Apple كمثال:
إنشاء المفتاح: يقوم جهاز macOS أو iOS أو iPadOS الخاص بالمستخدم، كوسيلة المصادقة، بإنشاء زوج مفتاح عام-خاص عند إنشاء المستخدم للحساب. ثم يُرسل المفتاح العام إلى الخادم، ويتم تخزين المفتاح الخاص على سلسلة مفاتيح iCloud الخاصة بالجهاز. يتم تشفير بيانات سلسلة مفاتيح iCloud بمفتاح مقترن بالأجهزة، ويتم تخزينها في وحدة أمان معدنية (HSM). المفتاح غير قابل للوصول من قبل Apple.
المزامنة عبر الأجهزة: سيكون هذا العملية نفسها كما في الوصول إلى iCloud. قم بالمصادقة على حساب iCloud، واستلم رمز SMS، وأدخل رمز المرور لأحد الأجهزة.
مزايا تقنية webAuthn القائمة على السحابة:
Cross-device: تم تصميم مفاتيح المرور لتكون مريحة ومتاحة من جميع الأجهزة المستخدمة بانتظام. ولكنها محدودة حاليًا لأجهزة Apple، أما بالنسبة لنظام Android، فإن الأمر أكثر تحديًا بسبب تنوع الإصدارات والتباينات في الأجهزة الخاصة به.
مقاومة الصيد الاحتيالي: نفس الشيء كما ذكر أعلاه.
تجربة مريحة: نفس الشيء كما هو مذكور أعلاه.
عيوب تقنية السحابية للمفتاح الرقمي:
الاعتماد على خدمة السحابة: بالمقارنة مع تسجيل الويب القائم على الجهاز، يقوم مفتاح السحابة بنقل مستوى الأمان من الأجهزة الأمنية المضمنة إلى سلسلة مفاتيح iCloud، قد يُعتبر بعض الأشخاص أنه يعتمد على خدمة السحابة. يجب مراعاة بعض الجوانب الرئيسية مثل: تعرض حساب AppleID الخاص بالمستخدم لـ iCloud؛ بينما يستخدم سلسلة مفاتيح iCloud تشفيرًا من النهاية إلى النهاية لحماية البيانات، تشكل الأخطاء التشغيلية أو الثغرات خطرًا.
القيود على المنصة: على سبيل المثال، استخدام مفتاح مرور مستند إلى iCloud على جهاز Android يعتبر تحديًا للغاية. وعلاوة على ذلك، على عكس الأساليب التقليدية، لا تقوم Apple و Google بإرسال تأكيدات خاصة بالجهاز. وهذا يعني أنه من المستحيل حاليًا التحقق من نوع الجهاز الذي أنشأ مفتاحًا، مما يثير تساؤلات حول موثوقية المفتاح والبيانات الوصفية المرتبطة به.
حتى الآن، يمكننا رؤية الحفاظ على أمان مستوى الأجهزة بينما نتناول التوافق بين الأجهزة والمنصات المختلفة كتحدي. مما لا يقل أهمية هو الخيار الاجتماعي للاستعادة، مثل إضافة حراس متعددين لتعزيز الأمان. في هذا السياق، يمكن للبلوكشين أن يوضح لنا الطريق.
هناك فجوة ملحوظة عند محاولة تنفيذ web2 webAuthn إلى web3: يتطلب Web2 فقط إثبات الملكية، بينما يتطلب web3 أيضًا تفويض الصفقة في نفس الوقت. مع Passkey، يفتقر المطورون إلى السيطرة على رسالة التوقيع، التي تكون عادةً عامة، مثل 'تسجيل الدخول'. يمكن أن يؤدي هذا إلى تلاعب محتمل في الواجهة الأمامية، حيث يقوم المستخدمون بتوقيع الرسائل بشكل عمي، وهو مصدر قلق يبدو غير مهم ولكنه حاسم.
حسابات العقود الذكية (SCA)، العقود الذكية بحد ذاتها، تعمل ككيانات على السلسلة الذاتية القدرة على تعيين الموقعين التعسفيين. تتيح هذه المرونة برمجة أجهزة ومنصات مختلفة - مثل ضبط هاتف Android و Macbook و iPhone - كموقعين. وعلاوة على ذلك، يسمح حساب العقد الذكي النمطي بالقابلية للترقية، بالتبديل بين موقعين جديدين، وتغيير حد التوقيع من 2 من بين 3 إلى تكوينات أكثر تعقيدًا.
تصوّر محفظة تكيف متطلبات أمانها استنادًا إلى السياق: تسمح بالمصادقة من مُعدٍّ واحد عندما يكون المستخدم على عنوان IP المحلي المألوف، ولكنها تتطلب مصادقة من مُعدّين متعددين للمعاملات من عناوين IP غير معروفة أو فوق قيمة معينة. مع القابلية للتعديل والقدرة على البرمجة، الخيال هو الحد الوحيد لمثل هذه الابتكارات. العديد من مزودي خدمات SCA يبنون بنشاط في هذا المجال، بما في ذلك Safe وZerodev وBiconomy وEtherspots وRhinestone، وما إلى ذلك. كما نشيد بالبنية التحتية مثل Stackup وPlimico وAlchemy التي تجعل ذلك ممكنًا.
يرجى التحقق من أبحاثي السابقة التي توفر سياقًا أشمل حول SCA.
يمكن للEOAs تحقيق الاسترداد الاجتماعي والتوافق عبر الأجهزة / المنصات من خلال خدمات MPC. على الرغم من وجود موقع الEOAs الثابت، يمكن لمزودي MPC تقسيم المفاتيح إلى حصص لتعزيز الأمان والمرونة. هذه الطريقة تفتقر إلى ميزات SCA القابلة للبرمجة والقابلة للترقية، مثل الاسترداد الزمني وإلغاء المفتاح بسهولة. ومع ذلك، فإنها ما زالت توفر قدرات فائقة عبر السلاسل عن طريق كونها سلسلة غير محددة وحاليا أكثر فعالية من SCAs. مزودي MPC الملحوظين بما في ذلك Privy, Particle Network, web3Auth, محفظة OKX, محفظة Binance، إلخ.
لنلق نظرة عامة لفهم السياق: في إيثريوم، تكون المفاتيح الخاصة أرقام عشوائية مختارة من منحنى k1، وعملية التوقيع تستخدم أيضًا هذا المنحنى.
ومع ذلك، تستخدم أزواج المفاتيح التي تم إنشاؤها وفقًا لمعايير WebAuthn منحنى r1. لذلك، فإن التحقق من توقيع r1 على Ethereum يكلف تقريبًا ثلاث مرات أكثر من توقيع k1. إليك بعض الطرق لمعالجة هذا:
الشكر لدوغان، للمزيد من المعرفة العميقة يرجى التحقق من بحثه.
حل البروتوكول:
الحل: EIP7212، المعدل المُعد مُسبقًا لدعم منحنى secp256r1 المقترح من فريق Clave.
التقييم: تقوم هذه المقترحات بإنشاء عقد معد مسبقًا يُنفذ تحقق التوقيعات في منحنى الإليبتيك "secp256r1" بواسطة معطيات تجزئة الرسالة، ومكونات r و s للتوقيع، وإحداثيات x و y للمفتاح العام. بحيث يكون بإمكان أي سلسلة EVM - وعلى رأسها تقوم أيثريوم رول أبس - بدمج هذا العقد المعد مسبقًا بسهولة. حتى الآن، قد يكون البروتوكول المعد مسبقًا هو الحل الأكثر كفاءة من حيث الغاز.
تنفيذ: zkSync
خدمة طرف ثالث
الحل: جاهز للاستخدام
التقييم: يضمن تقييم TEE التركي أن يكون المفتاح الخاص قابلًا للوصول فقط للمستخدم عبر مفتاح العبور الخاص بهم ولا يمكن الوصول إليه أبدًا من قبل Turnkey نفسه، ومع ذلك، يتطلب هذا لا يزال حيوية الخدمة.
التنفيذ: Goldfinch
حلول التحقق من صلادة العقود الذكية:
الحل: مدقق صلابة FCL، مدقق صلابة FCL مع الحساب المسبق، مدقق P256 من دايمو
التنفيذ: كلافي، محفظة واضحة
التحقق من الصفر المعرفة (ZK):
الحل: Risc0 Bonsai، هالو2-ecc من أكسيوم
التقييم: تستفيد هذه الطريقة من البراهين بدون معرفة للتحقق من الحسابات خارج آلة الحسابات الظاهرية للإيثيريوم (EVM)، مما يقلل من تكاليف الحوسبة على السلسلة.
تنفيذ: محفظة الحريق (ريسك0)، مختبرات لا تعرف شيئًا (أكسيوم)
كل من هذه الحلول تقدم طريقة مختلفة لتمكين التحقق من توقيع r1 بأسعار أرخص وممكنة في نظام الأثيريوم، وهنا تقييم من قبل Dogan.
*يرجى ملاحظة أنه اعتبارًا من ديسمبر 2023، فإن معظم هذه الحلول في مراحلها الأولى وقد تتغير أو تتحسن في أي وقت. هذه الأمثلة مخصصة فقط لأغراض التعلم؛ يرجى الرجوع دائمًا إلى مواقعهم الرسمية للحصول على معلومات دقيقة.
الأساسيات:
تجربة: https://getclave.io/
الحساب: SCA
Chain: ZkSync
عملية الصفقة:
إنشاء المفتاح: يقدم المستخدم المصادقة الحيوية مثل بصمة الإصبع أو التعرف على الوجه، حيث يتم إنشاء زوج المفتاح داخل الملجأ الآمن، والذي لا يكشف أو يترك خارجه أبدًا.
التوقيع الرئيسي: تقوم التطبيق بأخذ رسالة المعاملة المطلوبة وإرسال طلب توقيع إلى القفل الآمن، يقدم المستخدم المصادقة الحيوية للموافقة على التوقيع، ويقوم القفل الآمن بتوقيع الرسالة بالمفتاح، ويتم بثها إلى عقد البلوكشين.
وظائف إضافية: يتيح حساب العقد الذكي العديد من الوظائف القوية. أولا، رعاية الغاز. نظرا لمدير الدفع ، يمكن لأطراف أخرى مثل dApp أو المعلنين دفع رسوم الغاز للمستخدم ، مما يجعل عملية المعاملة أكثر سلاسة ، كما يمكنهم السماح للمستخدمين بدفع الغاز في ERC20 بدلا من Ether أو الرمز الأصلي. وباستخدام مفتاح الجلسة ، يمكن للمستخدم إجراء معاملة بدون توقيع في فترة زمنية.
آلية الاسترداد:
يتم تنفيذ عملية الاستعادة بواسطة عقد Clave الذكي على zkSync، حيث يمكن للمستخدم إلغاء عملية الاستعادة خلال قفل زمني لمدة 48 ساعة، لمنع الأنشطة غير المصرح بها والخبيثة.
يتم إنشاء EOA عندما يختار المستخدم النسخ الاحتياطي في السحابة، ومفتاح الخاص لـ EOA يتم تخزينه إما في iCloud أو Google Drive، يمكن للمستخدم استخدام هذا المفتاح الخاص المخزن في السحابة للوصول إلى حسابه من جهاز مختلف، ويمكن للمستخدمين إزالة أو استبدال هذا القسم الاحتياطي في أي وقت.
الاسترداد الاجتماعي: يمكن للمستخدم تعيين عنوان عنوان عائلته أو صديقه كنسخة احتياطية، إذا قدم M من N الأوصياء تأكيدًا للاسترداد، سيتم تنفيذ الاسترداد بعد 48 ساعة من التأمين إذا لم يتم الغاءه.
الأساسيات:
تجربة: https://alpha.soulwallet.io/wallet
حساب: ERC4337 SCA
Chain: Ethereum, Optimism, Arbitrum, and soon all EVM layer2
عملية العملية:
إنشاء مفتاح: يقدم المستخدمون المصادقة البيومترية مثل البصمة أو التعرف على الوجه، ويقوم نظام التشغيل بإنشاء مفتاح مرور ويقوم بنسخه احتياطيًا باستخدام خدمة السحابة. يمكنك إضافة أكثر من مفتاح مرور عبر الأجهزة والمنصات المختلفة.
إضافة الحراس (اختياري): يمكن للمستخدم تعيين عناوين EVM EOA مختلفة كحراس وإعداد عتبة لاستعادة الحساب.
إنشاء الحساب: باستخدام النشر المضاد، لا يحتاج المستخدمون إلى دفع أي رسوم حتى أول عملية تحويل
آلية الاسترداد:
مفتاح المرور: استخدم أي مفتاح مرور محدد لتسجيل الدخول إلى المحفظة باستخدام جهاز عشوائي.
استعادة حراس المعلومات: يمكن للحراس المعينين تدوير المحفظة وفقًا للحد الأدنى، وقد يتم التعامل في وقت لاحق مع قفل زمني لمنع السلوك الخبيث.
أساسيات:
عرض توضيحي: https://www.okx.com/help/what-is-an-aa-smart-contract-wallet
Chain: 30+ chains
المفتاح: MPC-TSS، 2/3
الحساب: 4337 SCA
عملية العملية:
إنشاء المفتاح: من خلال إنشاء محفظة، يحول OKX مفتاح خاص واحد إلى ثلاثة أسهم منفصلة. يتم تخزين السهم 1 في خادم OKX، ويتم تخزين السهم 2 على تخزين الجهاز المحلي للمستخدم، ويتم إنشاء السهم 3 بواسطة الجهاز، وتشفيره ويمكن نسخه إلى خدمات السحابة المفضلة على الجهاز، مثل Google Cloud، iCloud، وHuawei Cloud.
توقيع المفتاح: يمكن لمستخدم OKX استخدام تقنية MPC-TSS للحصول على التوقيع الكامل باستخدام إحدى العملتين من ثلاثة مفاتيح خاصة عند توقيع المعاملة، ولا تلتقي المفاتيح الخاصة أبدًا خلال هذه العملية.
آلية الاسترداد:
آلية 2/3: عند تسجيل خروج المستخدم، أو عند عدم توفر الجهاز، أو عند تعرض أحد المفاتيح على الجهاز للاختراق، يمكنك استخدام جهاز جديد لتسجيل الدخول إلى محفظة OKX (الحصول على حصة الخادم) والحصول على حصة الخدمة السحابية، ثم دمج هاتين الحصتين لاستعادة المحفظة، ستقوم محفظة OKX بإنشاء حصص سرية جديدة.
الأساسيات:
Demo: https://w3a.link/passkeysDemo
سلسلة: جميع EVM و Solana
Key: MPC-TSS، عادة ما يكون 2/3
الحساب: أي حساب مثل EOA، 4337 SCA أو SCA العام
عملية الصفقة:
إنشاء المفتاح: من خلال إنشاء محفظة، يتم إنشاء ثلاثة مشاركات مفتاحية. المشاركة1 هي مشاركة تسجيل الدخول الاجتماعية، يمكن للمستخدم إدخال بريدهم الإلكتروني، وشبكة لامركزية من العقد تقوم بتخزين المفتاح لكل مستخدم؛ المشاركة2 هي مشاركة الجهاز التي تُخزن على تخزين الجهاز المحلي للمستخدم؛ المشاركة3 تتم إنشاؤها بواسطة الكمبيوتر المحلي ويتم نسخها احتياطيًا عن طريق خدمات السحاب المفضلة لدى المستخدم.
توقيع المفتاح: تضمن بنية Web3Auth MPC-TSS أن مفتاح المستخدم متاح دائما ، حتى باستخدام توقيع العتبة ، لا يتم إعادة بناء المفاتيح أو تخزينها في مكان واحد.
آلية الاسترداد:
استرجاع الحد عند تسجيل خروج المستخدم، جهاز غير متاح أو أحد المفاتيح على الجهاز معرض للخطر، يمكنك استخدام طريقة تسجيل الدخول الاجتماعية لتسجيل الدخول إلى حساب webAuthn والحصول على مشاركة سحابية للمفتاح المروري، ودمج هاتين المشاركتين لاستعادة المحفظة.
معلومات أساسية:
تجربة:https://lit-pkp-auth-demo.vercel.app/
سلسلة: معظم EVM، Cosmos، Solana.
الحساب: MPC-TSS، 20 من 30 شبكة، يمكن اعتماده من قبل SCA و EOA.
عملية الصفقة:
إنشاء المفتاح: عندما يرغب المستخدم في إنشاء محفظة، يجب أن يختار أولاً طريقة المصادقة (مفتاح المرور، تسجيل الدخول الاجتماعي باستخدام oAuth)، ثم يتم إرسال طلب إلى الوسيط لإنشاء أزواج المفاتيح وتخزين منطق المصادقة في العقد الذكي. يتم إنشاء كل زوج مفاتيح جماعياً من قبل عقد Lit nodes من خلال عملية تسمى توليد المفتاح الموزع (DKG). ويعمل كشبكة لامركزية، حيث يعمل 30 عقد Lit nodes داخل TEE، حيث يحتوي كل عقد على حصة من المفتاح ولكن المفتاح الخاص لا يوجد بشكل كامل.
توقيع المفتاح: بعد استلام الطلب، تقوم العقد الخفيفة بالتحقق أو رفض الطلب بشكل مستقل ضد طريقة المصادقة المعينة، و باستخدام تقنية MPC-TSS، يتم جمع حصص المفتاح فوق الحد (20 من أصل 30) لتوليد توقيع وتجميعها بواسطة العميل لإكمال الطلب.
آلية الاسترداد:
آلية 2/3: استخدام طرق المصادقة المخزنة في العقد الذكي للوصول إلى الحساب، تقوم العقدة المضاءة بالتحقق من الطلبات وسيتم الموافقة عليها إذا كان أكثر من 2/3 من العقد يؤكدون.
مدفوعة بالحماس لطبقة2، طبقة3، وحلول توافر البيانات، نحن حريصون على تحسين أداء تقنية البلوكشين. كما نسعى لتحقيق أمان حقيقي، عبر دمج خصوصية البرهان الصفري مع طبيعة الشفافية. جميع الجهود تستهدف هدفًا واحدًا: أن نكون جاهزين للمستخدمين الحقيقيين الذين يتفاعلون بشكل متكرر مع تقنية البلوكشين ويعتمدون على العملات الرقمية في حياتهم.
من السهل أن تُقع في حلم تقنية مثالية، لكن علينا أن نسأل: أي نوع من التجربة نهدف إليه؟ نحن نتصوّر عالمًا حيث تكون العملات الرقمية مرتبطة بالحدس بدلاً من المصطلحات التقنية المربكة، حيث يقفز المستخدم إلى حفرة الأرنب دون تردد أو عناء.
تخيل مستخدمة تدعى روي: اكتشفت تطبيقًا لامعًا، وسجلت فيه بسهولة باستخدام التعرف الضوئي على الوجه أو بصمة الإصبع، مع خيار إعداد نسخ احتياطية أو وصيون. وأثناء تفاعلها مع التطبيق، تُنفذ المعاملات بسلاسة، ربما برسوم صغيرة للـ ERC20 أو حتى بدون رسوم على الإطلاق. في وقت لاحق، تُخصص إعدادات محفظتها - ربما تنشط قفل الوقت للمعاملات التلقائية، وتضيف جهازًا آخر كوقّع احتياطي، أو تُعدّل قائمتها للوصيون.
يجعل مشروعونا ذلك يحدث. من خلال دمج WebAuthn and Passkey، نقوم بتعزيز إدارة المفتاح الخاص، مما يجعلها آمنة وسهلة الاستخدام. علاوة على ذلك، يفتح SCA ككيان مجالًا للأمان والوظائف الشخصية. وأما بالنسبة لرسوم الغاز؟ تصبح أقل عبئاً، بفضل موفري Paymaster الذين يمكنهم إنشاء 'خزانة' للتبادلات أو حتى السماح للمعلنين بتغطية الرسوم للمستخدمين. في قلب هذا التطور، وخاصة بالنسبة إلى شبكة Ethereum mainnet وما يعادلها من Layer2s، يأتي ERC4337. إنه يقدم mempool بديلًا يفصل معاملات SCA عن EOAs، دون تغييرات كبيرة في البروتوكول. من ناحية أخرى، بعض شبكات Layer 2 تعتني حتى بـ SCAs بشكل أصلي، مدمجة بسلاسة في أنظمتها.
يتطلب جهودا هائلة لتسهيل كل شيء. هناك العديد من التحديات مثل خفض رسوم النشر والتحقق والتنفيذ لـ SCA؛ توحيد الواجهة لزيادة توافق الحسابات؛ مزامنة حالة الحساب عبر السلسلة؛ والعديد من الأمور الأخرى. الفضل لجميع البناة، نحن نقترب من حل اللغز يوما بعد يوم. ومشاريع العملات الرقمية مثلنا - SevenX، على استعداد لمساعدة الشركات الكبيرة في تحقيق رؤيتها.