لدى Ethereum نوعان من الحسابات: الحساب المملوك خارجيا (EOA) وحساب العقد (CA). يتم التحكم في EOAs بواسطة مفتاح خاص بينما يتم التحكم في CAs بواسطة رمز العقد الذكي الموجود فيها. لطالما كانت EOAs أكثر امتيازا من CAs لأن EOAs فقط هي التي يمكنها بدء تنفيذ المعاملات عن طريق دفع الغاز. تجريد الحساب (AA) هو اقتراح يسمح للعقد بأن يكون حسابا "عالي المستوى" ، مثل EOA، يمكنه دفع الرسوم وبدء تنفيذ المعاملة.

دافع AA هو تحسين تجربة المستخدم بشكل كبير في كيفية تفاعل المستخدمين مع سلسلة الكتل Ethereum اليوم عبر مختلف السيناريوهات مثل المحافظ والخلاطات وÐApps و DeFi. يوفر AA وظيفة طبقة الأساس في Ethereum لتحديد متى يمكن للشخص دفع الغاز الذي له أيضًا تداعيات على من يدفع ثمن الغاز وكيف يدفع عنه.

تضم تطبيق Status Messenger تطبيقًا للرسائل الخاصة بالخصوصية جنبًا إلى جنب مع محفظة Ethereum ومتصفح Web3 ÐApp. تعتبر محفظة Status حاليًا محفظة EOA التي تقيدنا من تقديم تجربة مستخدم غنية يمكن أن تقدمها محفظة العقد الذكي فقط مثل الأمان متعدد التوقيعات والاسترداد الاجتماعي وتحديد معدل الحدود والسماح / الرفض لقائمة العناوين والمعاملات الفورية بدون غاز. ومع ذلك، تتعثر تجربة مستخدمي محافظ العقود الذكية اليوم بشكل كبير بسبب تقلب أسعار الغاز والتي لا تُحل بكفاءة من قبل الموجهين الطرف الثالث. تهدف AA إلى معالجة هذه المشكلة.

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

التاريخ والدوافع

تم اقتراح تجريم الحساب أولاً كما EIP-86في عام 2017 لتنفيذ "تجريد مصدر المعاملة والتوقيع" ولكن أصول الفكرة المحفزة تعود إلى الوراء حتىبداية عام 2016، حيث اقتُرح: "بدلاً من وجود آلية في البروتوكول حيث يتم تنصيب ECDSA ونظام الرقم التسلسلي الافتراضي كالطريقة الوحيدة 'القياسية' لتأمين حساب، نتخذ خطوات أولية نحو نموذج يتحول في المدى الطويل حيث تكون جميع الحسابات عقودًا، ويمكن للعقود دفع تكاليف الغاز، ويمكن للمستخدمين تحديد نموذج أمانهم الخاص."

اعتبرت الاقتراحات الأولية صعبة التنفيذ بسبب التغييرات البروتوكولية الكثيرة المطلوبة والضمانات الأمنية التي يجب تحقيقها. في الآونة الأخيرة، اقترح فيتاليك وآخرون مسودة لـEIP-2938والتي توضح تنفيذًا أبسط بكثير من خلال الحفاظ على تغييرات البروتوكول/التوافقية في الحد الأدنى وفرض الضمانات الأمنية المطلوبة من خلال قواعد ذاكرة التخزين المؤقت للعقد. فيتاليكعرض اجتماع مجموعة هندسة إيثريوموعرض ETHOnline (مع المواد المرافقة @SamWilsn/ryhxoGp4D">1 & @SamWilsn/S1UQDOzBv">2) بقلم سام ويلسون وأنسجار ديتريشس (اثنان من مؤلفي EIP الآخرين) تقدم مقدمات رائعة حول الموضوع. يسلط هذا المقال الضوء على الجوانب الرئيسية من كل هذه المصادر.

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

إذن، لماذا هذا مفيد؟ دعونا نأخذ مثالاً على محافظ الإثريوم لتسليط الضوء على فائدة AA.

محافظ العقود الذكية: معظم محافظ الإثيريوم اليوم هي محافظ EOA التي تحمى بواسطة مفتاح خاص تم إنشاؤه من عبارة بذور. (A BIP-39العبارة البذرية أو المذكرة الكلمات هي قائمة مرتبة من 12-24 كلمة تُختار عشوائياً من قائمة تحتوي على 2048 كلمة. يوفر هذا العامل العشوائي الذي يُطلب للحصول على بذرة ثنائية تُولد باستخدام وظيفة PBKDF2. تُستخدم بذرة ثنائية ثم لتوليد أزواج المفتاح اللاسيمتري لـBIP-32من المتوقع أن يقوم المستخدم بكتابة عبارة البذور في مكان آمن لأنه قد يكون مطلوبًا لاحقًا لاستعادة المفاتيح على محفظة أخرى. ومع ذلك، تكون هذه المحافظ عرضة لسرقة المفتاح الخاص أو فقدان عبارات البذور مما يؤدي إلى فقدان أموال المستخدم.

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

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

أمثلة على محافظ العقد الذكية هي أرجونت, أوثيريوم, دابر, الدرهما, Gnosis Safe, المفرد و MYKEY. انتشار مثل هذه المحافظ يبدو أنه يزداد كما يشير لذلك ما يلي رسم بياني.

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

مركز Gnosis هو محفظة عقد ذكي متعددة التوقيعات تركز على إدارة فريق الأموال التي تتطلب عددًا أدنى (m-of-n) من أعضاء الفريق للموافقة على عملية قبل حدوثها. كما يمكنه تمكين تواقيع بدون رسوم عبر المعاملات الفرعية.

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

ومع ذلك، لديها ثلاثة عيوب رئيسية تقوم على البنية الأساسية للوسيط: (1) قد يتم اعتبارها كوسيط مركزي بإمكانية تعتيم المعاملات (2) إنها غير فعالة تقنيًا / اقتصاديًا بسبب رسوم الغاز الأساسية الإضافية 21000 المطلوبة لمعاملة الوسيط وحاجتهم العملية لتحقيق ربح فوق رسوم الغاز (3) استخدام بروتوكولات محددة للوسيط يجبر التطبيقات على الاعتماد على البنية التحتية لإيثريوم غير الأساسية مع قواعد مستخدمين أصغر وضمانات توفر غير مؤكدة.

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

تورنادو كاش: تطبيق دافع ذو صلة هو تلك المتعلقة بالخلاط مثل tornado.cashأين@tornadoتُحسِّن تورنادو خصوصية المعاملات عن طريق كسر الرابط على السلسلة بين العناوين باستخدام عقد ذكي يقبل إيداعات الإثريوم التي يمكن سحبها لاحقًا بعنوان مختلف. من المتوقع من المستخدم تقديم تجزئة سر خلال الإيداع ومن ثم تقديم دليل zkSnark أثناء السحب لإظهار معرفة السر دون الكشف عن السر أو الإيداع السابق نفسه. يقوم هذا بفصل السحب عن الإيداع.

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

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

تجريد الحساب

تجريم التجريم، كما هو مقترح في EIP-2938، يسمح للعقد أن يكون الحساب على مستوى الأعلى الذي يدفع الرسوم ويبدأ تنفيذ المعاملة. يتم تحقيق ذلك عن طريق إدخال تغييرات بروتوكولية مع نوع معاملة AA جديدة تتطلب اثنين من أكواد التشغيل الجديدة: NONCE و PAYGAS، وتغييرات في قواعد حوض الذاكرة وتمديدات لدعم الاستخدامات المتقدمة. أنواع الحسابات ما زالت اثنتين (EOA وحساب العقد) وجميع التغييرات المقترحة متوافقة مع المعاملات الحالية والعقود الذكية والبروتوكول.

تعتبر تطبيقات AA عبر فئتين: 1) تطبيقات مأهولة بمستأجر واحد مثل محافظ العقود الذكية، التي تنشئ عقدًا جديدًا لكل مستخدم 2) تطبيقات مأهولة بمستأجرات متعددة مثل tornado.cash أو Uniswap، حيث يتفاعل مستخدمون متعددون مع نفس مجموعة العقود الذكية.

دعم AA لتطبيقات متعددة المستأجرين يتطلب المزيد من البحث ويُقترح كعمل مستقبلي. لذلك سنركز على دعم AA لمستأجر واحد في هذه المقالة.

تغييرات البروتوكول

تم إدخال نوع معاملة جديد بالاضافة إلى opcode داعمة لـ NONCE و PAYGAS. هذه هي التغييرات البروتوكولية الوحيدة.

صفقة AA: يتم تقديم نوع جديد من صفقة AA AA_TX_TYPE. يتم تفسير حمولته على أنها RLP([nonce, target, data]) بدلاً من نوع الصفقة الحالي الذي يكونتم تفسير حمولته على أنها RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s]).

يتم تحديد سعر الغاز وحدة الغاز المحذوفتين في معاملة AA بواسطة عقد AA الهدف أثناء التنفيذ. تُستبدل التوقيع ECDSA المحذوف v و r و s في معاملة AA بفحوصات التحقق الخاصة بالعقد على البيانات. يتم استبدال عنوان to بعنوان العقد الهدف. يتم حذف القيمة لأن عنوان المصدر لجميع معاملات AA هو عنوان ENTRY_POINT الخاص (0xFFFF… FFFF) وليس EOA الذي يحتوي على قيمة مرتبطة به.

تتم معالجة العمليات بشكل مماثل للصفقات الحالية من خلال التحقق مما إذا كان tx.nonce == tx.target.nonce. إذا فشلت هذه الفحص ، يُعتبر الصفقة غير صالحة ولكن في حال نجاحه ، يتم زيادة tx.target.nonce ويتابع الصفقة.

تم اقتراح تكلفة الغاز الأساسية لمعاملة AA بواقع 15000 بدلاً من 21000 الحالية (لاعتبار توفير التكلفة من عدم وجود توقيع ECDSA الجوهري). علاوة على ذلك، لا توجد حدود غازية جوهرية للمعاملات AA. عند بدء التنفيذ، يتم تعيين الحد الأقصى للغاز ببساطة إلى الغاز المتبقي في الكتلة.

عملية الترميز: تقوم عملية الترميز (0x48) بدفع رقم الترميز للمستدعى، أي عقد الهدف AA، على ستاك EVM. وبالتالي يتعرض الترميز لـ EVM للسماح بالتحقق من التوقيع على جميع حقول المعاملات (بما في ذلك الترميز) كجزء من التحقق في عقد AA.

كود PAYGAS: يأخذ كود PAYGAS (0x49) عنصرين من الستاك: (أعلى) رقم الإصدار، (الثاني من الأعلى) بداية الذاكرة. يسمح الرقم الإصداري لتطبيقات المستقبل بتغيير دلالة الكود. حاليًا، الكود له الدلالة التالية:

1. تحقق من version_number == 0 (وإلا قم بإلقاء استثناء)
2. اقرأ gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
3. اقرأ gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])
4. تحقق من contract.balance >= gas_price * gas_limit (وإلا فثبّت الاستثناء)
5. تحقق من globals.transaction_fee_paid == False (وإلا فتوجيه استثناء)
6. تحقق إطار تنفيذ AA == الإطار على مستوى الأعلى، أي إذا كان تنفيذ EVM الحالي يخرج أو يعكس، يتم إنهاء تنفيذ EVM للمعاملة بأكملها (وإلا فثورة الاستثناء)
7. تعيين contract.balance -= سعر_الغاز * حد_الغاز
8. تعيين globals.transaction_fee_paid = True
9. تعيين globals.gas_price = gas_price و globals.gas_limit = gas_limit
10. تعيين سياق تنفيذ الحالي الباقي_gas = الحد الأقصى للغاز - الغاز الذي تم استهلاكه بالفعل

في نهاية تنفيذ صفقة AA، (globals.gas_limit - remaining_gas)يتم تحويل globals.gas_price إلى المُنقب ويتم استرجاع مُتبقي الغاز إلى عقد AA globals.gas_price.

PAYGAS يعمل كنقطة تفتيش تنفيذ EVM. أي إلغاءات بعد هذه النقطة ستلغي فقط حتى هنا ومن ثم يتلقى العقد أي استرداد ويتم نقل globals.gas_limit * globals.gas_price إلى المنقب.

نوع المعاملة الجديد والشفرتين الجديدتين يشكلان تغييرات على مستوى البروتوكول/التوافق والمعاني الخاصة بها نسبياً مباشرة للتفكير حولها.

قواعد Mempool

“The ميمبولتشير إلى مجموعة من هياكل البيانات في الذاكرة الداخلية لعقد Ethereum التي تخزن المعاملات المرشحة قبل أن يتم تعدينها. يطلق عليه Geth "حوض المعاملات"؛ Parity يطلق عليه "طابور المعاملات". بغض النظر عن الاسم، فهو حوض من المعاملات يجلس في الذاكرة في انتظار أن يتم تضمينه في كتلة. فكر فيها كمنطقة "انتظار" للمعاملات ليتم قبولها في كتلة.

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

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

لذلك يحتاج المُنقِبون والعُقَد بشكلٍ متوقع إلى آلية لتجنب الاعتماد على صحة معاملة AA المعلقة تأثيرًا على معاملات معلقة أخرى في mempool. إذا لم يحدث ذلك، فإن تنفيذ معاملة واحدة قد يبطل العديد/جميع معاملات AA في mempool مما يؤدي إلى هجمات DoS. ولتجنب هذا السيناريو، هناك اثنتان من القواعد المقترحة للتنفيذ (من قبل المُنقِبين والعُقَد ولكن ليست في البروتوكول نفسه) على معاملات AA في mempools:

قيد التشغيل

لمنع صحة معاملة AA من الاعتماد على أي حالة خارجية لعقد AA نفسه، فإن الترميزات التالية تعتبر غير صالحة في مرحلة التحقق (أي قبل PAYGAS): ترميزات البيئة (BLOCKHASH، COINBASE، TIMESTAMP، NUMBER، DIFFICULTY، GASLIMIT)، BALANCE (لأي حساب، بما في ذلك الهدف نفسه)، ونداء/إنشاء خارجي إلى شيء غير الهدف أو مسبقًا مجهز (CALL، CALLCODE، STATICCALL، CREATE، CREATE2)، والوصول الحالي الخارجي الذي يقرأ الشيفرة (EXTCODESIZE، EXTCODEHASH، EXTCODECOPY، DELEGATECALL) ما لم يكن العنوان الهدف.

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

قيد بادئة البايت

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

من المتوقع أن تقوم العقدة بإسقاط معاملات AA إلى عقود AA التي لا تحتوي على هذا الـ AA_PREFIX في نقاط دخول بايت‌كودها.

تضمن هاتان القيدتان المفروضتان على عقود AA معًا أن: (1) الحالة الوحيدة التي يمكن الوصول إليها منطق صحة معاملة AA هي الحالة الداخلية لعقد AA و (2) يمكن تعديل هذه الحالة فقط من قبل معاملات AA أخرى تستهدف هذا العقد AA المحدد.

يمكن إلغاء عملية تحقق AA المعلقة إلى عقد AA فقط عن طريق كتلة تحتوي على عملية AA أخرى تستهدف نفس عقد AA. ومع ذلك، نظرًا لأن هذه ليست تغييرات في البروتوكول/التوافق، فإنه يمكن للمعدنين تضمين العمليات في كتلة تخالف هذه القواعد.

التمديدات

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

1. SET_INDESTRUCTIBLE opcode ، الذي يعطل SELFDESTRUCT ويسمح لعقود AA بالاتصال بالمكتبات باستخدام DELEGATECALL بأمان في مرحلة التحقق.
2. الشيفرة IS_STATIC، التي تعيد القيمة صحيحة إذا كان السياق الحالي ثابتًا وتسمح للمتصلين بالمعاملات غير AA بتجاوز قيد بادئة البيتكود السابق وقراءة القيم من عقود AA بأمان.
3. شفرة العرض_الكحولي_الاحتياطية، التي تنشئ حدًا أدنى للغاز الذي يستهلكه عقد AA عند استدعائه من معاملة غير AA تسعى لكتابة حالة العقد. يهدف هذا إلى إجبار المهاجمين على إنفاق كمية دنيا من الغاز لتثبيط محاولات تبطيل أي معاملات AA في مجموعة الذاكرة.

هناك آخرين مثل عمليات الانتظار المتعددة، تخزين نتائج التحقق، حدود الغاز الديناميكية للتحقق والمعاملات المدعومة التي يتوجب دعمها لتطبيقات المستأجرين المتعددين وبراهين zk على سبيل المثال Tornado Cash. مناقشتهم خارج نطاق هذه المقالة.

الخطوات التالية

مواصفة تجريد الحساب EIP-2938 حاليًا في وضع مسودة ويتم مناقشتها في منتديات أبحاث Ethereum. الخطوة التالية لمواصفة تجريد الحساب هي النظر في إدراجها في أحد التحديثات الصعبة القادمة. يبدو أن مؤلفي مواصفة تجريد الحساب يهدفون إلى التحديث الصعب بعد برلين (برلين مُقررة مؤقتًا لوقت ما فيبداية عام 2021) الذي لا يوجد جدول زمني واضح في الوقت الحالي. لذلك لا زال الأمر مبكرًا في عملية EIP-2938.

وعلاوة على ذلك، ليس من الواضح أيضًا أنه سيكون من الضروري تضمين EIP-2938 في طبقة Ethereum الأساسية 1 (L1). نظرًا للمرونة النسبية لحلول الطبقة 2 (L2) (كما هو موضح في an earlierمقالة) يمكن تنفيذ تجريد الحساب على L2 معينة دون الحاجة إلى ترقية L1 بأكمله. ومع ذلك، هناك فوائد لدعم AA موحد على L1 حتى لو قامت بعض L2 بتنفيذ إصدارات AA الخاصة بها. لذلك، من المتبقي معرفة المكان والطريقة التي يتم بها تنفيذ AA.

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

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

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

ملخص

جانب أساسي من بروتوكول Ethereum هو أن حسابات المالك الخارجية (EOAs) فقط يمكنها دفع رسوم الغاز وبدء تنفيذ المعاملة. لا يمكن لحسابات العقدات (CAs) القيام بذلك. Account Abstraction (AA) هو اقتراح يهدف إلى تغيير هذا التمييز والسماح لحسابات CAs المشيدة بشكل خاص بفحص صحة نوع جديد من معاملات AA برمجياً، واتخاذ قرار بدفع رسوم الغاز نيابةً عنها وبالتالي بدء تنفيذها بفعالية دون الحاجة إلى EOA.

لديه آثار تحسينية كبيرة على تجربة المستخدم عبر مختلف السيناريوهات مثل المحافظ والخلاطات وÐApps و DeFi دون الاعتماد على التركيبات المركزية وغير الفعالة التي تعتمد على المرسلين. يمكن دعم السيناريوهات الأساسية المخصصة، مثل محافظ العقود الذكية، بأمان من خلال AA بإدخال نوع جديد من المعاملات، ونوعين جديدين من التعليمات البرمجية وقاعدتين جديديتين لحوض الذاكرة. تتطلب التطبيقات المتعددة المستأجرين المتقدمة، مثل Tornado Cash، تمديدات لهذه التغييرات في البروتوكول وقواعد العقد.

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

تقليل الاحتكاك وتحسين تجربة المستخدم في Web3 أمرٌ أساسي لجميع المشاريع في هذا النظام البيئي. قد يلعب التجريف الحسابي، بأي شكل من الأشكال، دورًا هامًا بالتأكيد في هذا الجهد المستقبلي.

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

1. تم نقل هذه المقالة من [ الحالةإلى الأمام عنوان العنوان الأصلي 'تجاهل الحساب (EIP-2938): لماذا وما', جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [ راجيف جوبالاكريشنا]. إذا كانت هناك اعتراضات على هذا الإعادة طباعتها، يرجى الاتصال بالبوابة تعلمالفريق، وسيتولون بالأمر على الفور.

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

3. تتم الترجمات للمقال إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر غير ذلك، فإن نسخ أو توزيع أو نسخ المقالات المترجمة ممنوع.