تأثير EIP-3074 على المحافظ والتطبيقات اللامركزية

المؤلف:Nic @ imToken Labs

القراء المستهدفون:< /strong>مطور Blockchain

المعرفة الأساسية:

• فهم الفرق بين EOA والعقد

• فهم EVM والتنفيذ عملية العقد

• فهم الموافقة وتصميم التصريح لـ ERC-20

• < p style="text-align: left;">يمكن العثور على التفاصيل على: https://support.token.im/hc/zh-tw/articles/22181703417241

EIP-3074

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

يسمح EIP-3074 لـ EOA بنقل التحكم إلى العقد المعين، وبالتالي الحصول على نفس قدرات التنفيذ الغنية مثل العقد.

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

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

ومن خلال EIP-3074، لم يعد يتعين على EOA إرسال المعاملات إلى السلسلة نفسها، لذلك لا داعي للقلق بشأن رفع ETH أولاً لدفع ثمن المعاملة سؤال.

▶ عقد المستحضر

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

△ سيحدد محتوى توقيع EOA بوضوح عقد المستدعي (عنوان المستدعي) ويأذن بتشغيل (ارتكاب) عقد المستدعي.

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

• تقوم أليس بالتوقيع باستخدام مفتاح EOA الخاص بها، ومن ثم تعطي محتوى التوقيع والختم إلى Relayer.

• يقوم Relayer بإحضار السلسلة إلى عقد Invocer للتنفيذ.

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

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

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

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

△  إذا لم يكن عقد Invocer مضادًا للإعادة، فيمكن تنفيذ نفس التفويض طوال الوقت.

معرفة المزيد

حول EIP-3074 الفعلي للحصول على مقدمة لآلية التشغيل، يرجى الرجوع إلى: https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234

▶ الغرض

< strong>Batchcall< /strong>

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

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

للتعرف على EIP-5792، يرجى نسخ الرابط إلى متصفحك لعرضه: https://eips.ethereum.org /EIPS/eip -5792

مفتاح الجلسة

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

تم تصميم هذه الشروط والتحقق منها ضمن عقد Invocer وطالما تم تمرير الفحص، يمكن للطرف الثالث تنفيذ العمليات كهوية EOA للمستخدم.

△ يمكن منح Telegram Bot أذونات محددة لتنفيذ العمليات نيابة عن المستخدم EOA.

تصريح ETH الأصلي

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

الأمر المحدد

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

△ عندما تكمل أليس الطلب، سيتم تنفيذ الموافقة بشكل عرضي، ولا يلزم الحصول على موافقة مسبقة.

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

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

التعافي الاجتماعي

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

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

تأثير EIP-3074

▶  هل ترغب في تحسين الطريقة التي يتم بها ترخيص الأصول، أو حتى استبدال الموافقة/التصريح؟

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

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

△ يجب على المستخدم الموافقة على مبلغ أصول التطبيق اللامركزي الكبير بما يكفي مسبقًا لتسهيل استخدام التطبيق اللامركزي لأمواله للعمل.

△ ولكن من الضروري أيضًا الثقة في التطبيقات اللامركزية أو تجنب منح الموافقة على التطبيقات اللامركزية المزيفة، والقدرة على إزالة الموافقة في الوقت الفعلي.

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

معرفة المزيد

تفاصيل EIP-2612، يرجى النسخ الرابط أدناه للمتصفح للاستعلام: https://eips.ethereum.org/EIPS/eip-2612

Permit2 التفاصيل، يرجى نسخ الرابط أدناه إلى متصفحك للاستعلام:

https://medium.com/taipei-ethereum-meetup/uniswap-permit2 -مقدمة- 858ae3dddf18

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

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

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

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

معرفة المزيد

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

https:/ /x.com/realScamSniffer/status/1783027808723435727

https://x.com/realScamSniffer/status/1784932506174967970

https://x.com/realScamSniffer/status/1786738218962223226

لكن EIP -3074 يقدم فرصة للتغيير: عندما يعلم مطورو التطبيقات اللامركزية أن EOA يمكنها تنفيذ العديد من العمليات المعقدة من خلال Invocer، فإن تصميم تفاعل DApp لم يعد بحاجة إلى التضحية بالأمان من أجل تحسين تجربة المستخدم، مثل "يوافق المستخدم على مبلغ كبير من الأصول مقدمًا" و"يوقع المستخدم على رسالة تصريح للسماح بالسحب".

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

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

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

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

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

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

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

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

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

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

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

1. يحتاج المستخدمون إلى التوقيع مرتين: مرة لتوقيع EIP-3074 ومرة ​​للمعاملة على السلسلة .

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

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

△ يمكن للمستخدمين اجتياز عملية التحقق بنجاح عن طريق إجراء 1+ لـ EOA مرة واحدة في توقيع EIP-3074 قبل التحميل إلى السلسلة.

الملخص والنقاط الرئيسية

• يسمح EIP-3074 لـ EOA بالحصول على نفس إمكانات التنفيذ الغنية مثل العقود، مما يفتح العديد من سيناريوهات التطبيق الجديدة.

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

• وEIP-3074 عبارة عن توقيع بسيط، ولا يتعين على المستخدمين إحضار التوقيع إلى السلسلة للتنفيذ، لذلك يوجد لا داعي للقلق، يجب عليك أولاً جمع ETH لدفع رسوم المناولة.

• تتضمن استخدامات EIP-3074 الاتصال الجماعي ومفتاح الجلسة وتصريح ETH الأصلي وأمر الحد والاسترداد الاجتماعي. العديد من هذه الأمور من المستحيل تحقيقها في الأصل باستخدام EOA، وبعضها، مثل أمر الحد، يتطلب تفويضًا مسبقًا وطرقًا أخرى أقل أمانًا لاستخدامها.

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

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

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

• نأمل أن يتمكن EIP-3074 من استبدال أوضاع الموافقة والسماح الحالية وتزويد المستخدمين بطريقة تفويض أكثر أمانًا.