EIP-3074

تجربة استخدام أفضل وأكثر أمانا

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

علاوة على ذلك ، من خلال EIP-3074 ، لا تحتاج EOA no أطول إلى إرسال المعاملات إلى السلسلة بنفسها ، مما يلغي مشكلة الاضطرار إلى رفع ETH لدفع رسوم المعاملات.

Invoker Contract

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

سيحدد محتوى توقيع EOA بوضوح عقد Invoker (عنوان المستدعي) ويأذن بعمليات عقد Invoker هذا (الالتزام)

من المحتمل أن تبدو عملية التنفيذ الفعلية كما يلي:

1. توقع أليس باستخدام مفتاح EOA الخاص بها ثم تعطي محتوى التوقيع والتوقيع إلى Relayer
2. Relayer يجلب السلسلة إلى تنفيذ عقد Invoker
3. يتحقق Invoker من التوقيع. بعد اجتياز التحقق ، يمكنه إجراء عمليات باعتباره EOA، مثل الموافقة على USDC، ثم الانتقال إلى Uniswap إلى تبادل، وأخيرا نقل بعض USDC إلى Relayer كرسوم معالجة.

ملاحظة 1: Relayer ليست ضرورية. يمكن لأليس أيضا إحضار محتوى توقيعها الخاص وختمها إلى السلسلة.

بعد أن يتحقق Invoker من التوقيع ويبدأ في تنفيذ العملية ، سيتم تنفيذه ك Alice EOA، وهو ما يشبه الحصول على تحكم (محدود) في EOA.

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

إذا لم يكن عقد Invoker مقاوما لإعادة التشغيل، فيمكن تنفيذ نفس التفويض طوال الوقت.

للحصول على مقدمة لآلية التشغيل الفعلية ل EIP-3074 ، يرجى الرجوع إلى: مقدمة في EIP3074

Application

Batchcall

السماح للمستخدمين بدمج تنفيذ العديد من المعاملات في معاملة واحدة ، مما يوفر عملية التوقيعات المتعددة المصرح بها وبعض تكاليف الغاز.

ملاحظة: سيتطلب ذلك من dApp أيضا الدعم وظيفة Batchcall ، مثل EIP-5792 ، والتي يتم دفعها حاليا من قبل المجتمع. خلاف ذلك ، سيطالب dApp المستخدم بالتوقيع مرة واحدة فقط لكل عملية إذا كان يعامل المستخدم على أنه EOA.

Session Key

يمكن للمستخدمين أيضا السماح لطرف ثالث بالتصرف نيابة عنهم في ظل ظروف معينة. مفتاح المفوض في الرسم البياني أدناه هو الطرف الثالث المعتمد ؛ سياسة الوصول هي قيود التنفيذ ، مثل قصرها على تشغيل Uniswap فقط ، ونقل بحد أقصى 1 ETH في اليوم ، وفترة صلاحية التفويض ، وما إلى ذلك. تم تصميم هذه الشروط والتحقق منها ضمن عقد Invoker. طويل يتم تمرير الشيك ، يمكن للطرف الثالث تنفيذ العمليات باعتباره EOAللمستخدم.

يمكن منح Telegram Bot أذونات محددة لإجراء العمليات نيابة عن EOA الخاص بالمستخدم

تصريح ETH أصلي

كما طويل استيفاء الشروط (أي أن توقيع التصريح قانوني) ، يمكن إجراء نقل ETH باعتباره المفوض EOA، مما يحقق تأثير تصريح ETH الأصلي.

حد الطلب

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

عندما تكمل أليس طلب ، ستنفذ الموافقة في نفس الوقت ، مما يلغي الحاجة إلى موافقة مسبقة.

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

طويل استيفاء شرط النية ، يمكن لأي شخص بدء التنفيذ باسم EOA الخاص بالمستخدم

Social Recovery

عندما يفقد المستخدم مفتاح EOA الخاص ، يمكنها (Alice) استخدام تفويض EIP-3074 الذي وقعته ، جنبا إلى جنب مع توقيعات الشخص المفوض (الزوج والوكيل الاستئماني) لنقل جميع أصول EOA. في الواقع ، ما يتم استرداده هو الأصول (القابلة للتحويل) ، وليس السيطرة الحساب. بعد فقدان المفتاح الخاص EOA ، لا يمكن استخدام EOA أطول.

عندما يفقد المستخدم مفتاح EOA الخاص ، يمكن للأشخاص المصرح لهم الآخرين التوقيع والتفويض بنقل أصول EOA.

تأثير EIP-3074

تحسين طرق تفويض الرمز المميز ، وربما استبدال الموافقة / التصريح؟

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

يجب على المستخدم الموافقة على مبلغ كبير بما يكفي ل dApp مقدما حتى يتمكن dApp من العمل بأمواله.

ولكن من الضروري أيضا الوثوق ب dApp أو تجنب الموافقة على dApp المزيف ، والقدرة على إزالة الموافقة على الفور

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

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

ولكن في الواقع ، ليس فقط الموافقة ، فقد تم استخدام وضع التصريح كطريقة هجوم احتيال بشكل متكرر (1،2،3): وقع الضحايا عن طريق الخطأ على ما اعتقدوا أنه تصريح ل dApp ولكن تم منحه بالفعل للمهاجم.

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

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

ومع ذلك ، فإن EIP-3074 يجلب فرصة للتغيير: عندما يعرف مطورو dApp أن EOA يمكنها إجراء عمليات معقدة مختلفة من خلال Invoker ، فإن تصميم تفاعل dApp لا يحتاج أطول إلى التضحية بالأمان في طلب لتحسين تجربة المستخدم ، مثل "يوافق المستخدمون مسبقا على مبلغ كبير من المال" و "يوقع المستخدمون على رسالة تصريح للسماح بالسحب". بدلا من ذلك ، يربط المستخدمون عمليات dApp للموافقة على التنفيذ الذري وتنفيذه من خلال Invoker: إما أن يتم تنفيذ عمليات الموافقة و dApp بنجاح معا ، أو تفشل معا. لا توجد إمكانية لنجاح الموافقة وحدها ، لذلك يمكن للمستخدمين أن يكونوا واثقين من أن هذه الموافقة مخصصة لهذه العملية. ويستخدم المستخدمون تفويض التوقيع خارج السلسلة ، وبالتالي فإن تجربة المستخدم هي نفس التصريح! هذا يعني أن dApp لن يحتاج أطول إلى وضع التصريح! في المستقبل ، يمكن للمحافظ حظر أو إجراء مراجعات أكثر صرامة لطلبات توقيع التصاريح مباشرة ، دون الحاجة إلى القلق بشأن ما إذا كان ذلك سيؤدي إلى عدم استخدام المستخدمين لبعض dApps (ولكن بدوره يتم استخدامها للاحتيال).

لا يمكن للمستخدمين أطول ببساطة تفويض عنوان معين ، ولكن تفويض عنوان معين وما يجب القيام به ، وحتى رؤية نتيجة التنفيذ المحاكاة.

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

كيف يتعامل المحفظة مع EOA nonces

سيتضمن تصميم EIP-3074 الحالي قيمة EOA nonce في محتوى التوقيع ، بحيث طويل ترسل EOA معاملة إلى السلسلة للتنفيذ وتغير قيمة nonce ، سيتم إبطال جميع تراخيص EIP-3074 الأصلية.

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

إذا كان المستخدم مصرحا له بالعمل بنفسه ، فلا داعي لمنع تغيير nonce EOA على وجه التحديد ، لأنه لا يزال من المتوقع تنفيذ توقيع EIP-3074 قبل موعد نهائي معين مثل المعاملة. كل ما في الأمر أن المحفظة تحتاج إلى إدارة المزيد من معاملات EIP-3074 الخاصة ب EOA: إذا كان هناك توقيعات EIP-3074 في انتظار تحميلها على السلسلة ، فسيتعين على معاملات EOA نفسها الانتظار.

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

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

ومع ذلك ، تجدر الإشارة إلى أنه إذا أراد المستخدم إحضار محتوى توقيع EIP-3074 الخاص به إلى السلسلة ، فسيكون هناك عيبان:

1. يحتاج المستخدم إلى التوقيع مرتين: مرة لتوقيع EIP-3074 ، ومرة لتوقيع المعاملة داخل السلسلة.
2. نظرا لأن معاملة داخل السلسلة ستضيف 1 إلى nonce EOA قبل بدء تنفيذ المعاملة، يجب إضافة nonce EOA في توقيع المستخدم EIP-3074 مسبقا 1 لمطابقة EOA nonce +1 الناتجة عن السلسلة نفسها.

نظرا لأن السلسلة ستضيف 1 إلى nonce EOA أولا ، سيفشل التحقق من توقيع EIP-3074 بسبب عدم تطابق nonce EOA.

إذا أضاف المستخدمون 1 إلى nonce EOA في توقيع EIP-3074 قبل إحضاره إلى السلسلة بأنفسهم ، فيمكن متابعة التحقق بسلاسة.

ملخص وأبرز

• يسمح EIP-3074 ل EOA بالحصول على نفس قدرات التنفيذ الغنية مثل العقود ، مما يفتح العديد من سيناريوهات التطبيق الجديدة.
• لن يؤدي ذلك إلى تحسين تجربة المستخدم بشكل كبير فحسب ، بل سيغير أيضا طريقة تفويض الرمز المميز الحالية ، مما يجعلها أكثر أمانا مع الحفاظ على نفس تجربة المستخدم.
• علاوة على ذلك ، EIP-3074 هو توقيع بسيط ، ولا يتعين على المستخدمين بالضرورة إحضار التوقيع إلى السلسلة للتنفيذ ، لذلك لا داعي للقلق بشأن جمع ETH لدفع رسوم المعاملات.
• تشمل استخدامات EIP-3074 مكالمة مجمعة ومفتاح الجلسة وتصريح ETH الأصلي حد الطلب والاسترداد الاجتماعي. كان من المستحيل في السابق على EOAs تحقيق العديد منها ، وبعضها ، مثل حد الطلب ، يتطلب استخدام طرق ترخيص مسبق غير آمنة.
• سيغير EIP-3074 أيضا طريقة تفويض الرمز المميز الحالية. تسمح طريقة الموافقة مباشرة لعنوان معين بامتلاك القدرة على سحب الرموز المميزة إلى أجل غير مسمى ، وتتطلب من EOA الخاص بالمستخدم إرسال معاملة لتنفيذ الموافقة ، وبالتالي فإن تجربة المستخدم والأمان ليسا جيدين ؛ تتطلب طريقة التصريح فقط من المستخدم التوقيع ، وسيحدد كل توقيع المبلغ وفترة الصلاحية ، مما يحسن بشكل كبير من تجربة المستخدم وأمانه مقارنة بالموافقة.
• ومع ذلك ، لا يزال التصريح يستخدم بشكل متكرر في عمليات الاحتيال. عند التوقيع ، يمكن للمستخدمين فقط معرفة من يأذنون ، وكم ، وفترة الصلاحية ، لكنهم لا يعرفون الغرض من هذا التفويض. "ما هو عليه" سيكون توقيعا آخر (أو معاملة). ستسمح dApps العادية للمستخدمين بالتوقيع على التصريح و "الغرض منه" ، لكنهما سيظلان توقيعين مختلفين ، لذلك عندما يطلب منهما التوقيع على التصريح ، لا يمكن للمستخدم ولا المحفظة معرفة الغرض من استخدام هذا التصريح.
• مع EIP-3074 ، لا يحتاج المستخدمون (1) إلى الموافقة على مبلغ كبير من المال ل dApp مقدما ، ولكنهم يحتاجون فقط إلى الموافقة عندما تكون هناك عملية ، والتي لها نفس تأثير التصريح ؛ (2) إنه مجرد توقيع بسيط ولا داعي للقلق بشأن جمع ETH لدفع رسوم المعاملة ، وهي نفس رسوم التصريح ؛ (3) ترتبط كل موافقة بعملية محددة وموقعة معا ، بحيث يمكن للمستخدمين معرفة الغرض من هذه الموافقة بوضوح ، والتي ستكون أكثر أمانا من التصريح!
• من المأمول أن يتمكن EIP-3074 بنجاح من استبدال أوضاع الموافقة والتصريح الحالية وتزويد المستخدمين بطريقة تفويض أكثر أمانا.

إخلاء المسؤولية:

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