هذا هو الجزء 1 من سلسلة أكتبها لفحص التأثير الذي من المرجح أن يكون لـ EIP-7702 على أجزاء مختلفة من عالم العملات المشفرة، بما في ذلك:
في الجزء 1 ، أرغب في دراسة كيفية تبني 7702 وكيفية تطوره. هل سيتم تبنيه بسرعة فائقة أم سنرى دورة تبني طويلة جدًا؟ من سيتبناه أولاً؟ هذا هو موضوع هذه المقالة.
أولاً، ملخص سريع. EIP-7702 هو واحد من EIPs المقرر أن يدخل حيز التنفيذ في الترقية التالية لإيثيريوم (بيكترا) المقررة في الربع الأول من عام 2025.
مع EIP-7702، يمكن لـ EOA أن يقوم بـ "ترقية" نفسه إلى حساب ذكي، مع البقاء ك EOA والاحتفاظ بنفس العنوان في نفس الوقت.
بمجرد أن يتمتع المستخدم بالترقية، يمكنه بعد ذلك الاستفادة من معظم فوائد AA مثل رعاية الغاز، دفع المعاملات بدفعة واحدة، مفاتيح الوصول، إلخ.
EIP-7702 هو مقترح لتجريد الحساب، لكنه يختلف عن ERC-4337 بطرق حرجة:
في الواقع، النقطتان الأوليان - أن EIP-7702 يمكن أن يرقي حسابات العقد الذاتية وأن تظل حسابات العقد الذاتية حسابات العقد الذاتية حتى بعد الترقية - هما الأسباب الأكبر لماذا من المحتمل أن يعزز EIP-7702 اعتماد AA بشكل أكبر بكثير مما يمكن أن يفعله ERC-4337 وحده. هذا يعود لأن:
ومع ذلك، سيكون من الخطأ القول بأن EIP-7702 سيقتل ERC-4337. كما سنناقش في مقال مستقبلي، سيحتاج EIP-7702 إلى الاستفادة من ERC-4337 من أجل تحقيق كامل إمكاناته، لذا فإن EIP-7702 هو في الواقع أخبار جيدة بشكل لا يصدق لشركات ERC-4337 اليوم مثل@zerodev_app""> @zerodev_app.
الآن إلى النقطة الرئيسية لهذه المقالة: ما هي سرعة اعتماد 7702، وكيف سيتم تبنيه في الممارسة، أي كيف ستتبنى أجزاء مختلفة من كومة Web3 (على سبيل المثال، المحافظ، التطبيقات اللامركزية، البنية التحتية) 7702؟
بالنسبة للسؤال الأول - مدة الوقت - هناك بعض السيناريوهات الممكنة:
ترتيبي الشخصي لاحتمالات هذه السيناريوهات هو 2 > 3 >> 4 > 1 (مع 2/3 هي السيناريوهات المحتملة و 4/1 هي السيناريوهات الأقل احتمالا). بمعنى آخر ، من المحتمل أن يحقق 7702 اعتمادا هائلا في غضون بضع سنوات ، ولكن من غير المرجح أن يتم اعتماده بين عشية وضحاها أو يتم تجاهله تماما.
لمعرفة السبب، دعنا نفحص كيف سيتبين احتمال تبني 7702 في التطبيق العملي.
لنبدأ بفحص المحافظ، الذين يكونون في المرحلة الأعلى في دورة اعتماد 7702، لأنه من دون دعم المحافظ لـ 7702، لا يمكن لتطبيقات اللامركزية الاستفادة من ميزات 7702.
أولاً، دعنا نفرق بين المحافظ المستقلة مثل Gate.io و@MetaMask""> @MetaMask @CoinbaseWallet ، وخدمات المحفظة مثل Gate@privy_io""> @privy_io @dynamic_xyz @turnkeyhq @magic_labs. ستواجه المحافظ المستقلة وخدمات المحافظ حوافز مختلفة في اعتماد 7702. في هذا القسم نتحدث فقط عن المحافظ المستقلة.
محافظ مستقلة لديها بعض الخيارات عندما يتعلق الأمر بتبني 7702:
توقعي هو أن الذيل الطويل لشركات المحفظة سيذهب مع الخيار 3 (الانتظار والترقب) ، لسبب بسيط هو أن اعتماد 7702 يتطلب الكثير من العمل ، لذا قد لا يكون لدى معظم شركات المحفظة الوقت والموارد اللازمة لتنفيذه بسرعة. ومع ذلك ، فإن أهم المحافظ ، مثل MetaMask و Coinbase ، ستذهب مع الخيار 2 ، أي تنفيذ دعم 7702 بسرعة ولكن مطالبة المستخدمين بالاشتراك فيه. ستكون هناك أيضا محافظ مستقلة جديدة تتوافق مع الخيار 1 (تمكين 7702 افتراضيا) ، ولكن نظرا لأن المحافظ هي مساحة تنافسية ويصعب على اللاعبين الجدد الدخول إليها ، فمن الناحية الواقعية ، سيستخدم معظم المستخدمين المحافظ الحالية التي تتوافق مع الخيار 2 أو 3.
لماذا أعتقد أن المحافظ الأعلى ستنفذ دعم 7702 بسرعة؟ لأن:
الآن، لماذا أعتقد أن هذه المحافظ لن تمكِّن 7702 بشكل افتراضي، ولكنها ستتطلب من المستخدمين الاشتراك؟
بكلمة واحدة، الأمان.
موضوع الأمان مع 7702 هو موضوع دقيق للغاية ويستحق مشاركة خاصة به، لكن سأقوم بسرد الأساسيات هنا بسرعة.
باختصار، من غير الصحيح القول إما 1) أن 7702 يحسن أمان المحفظة، أو 2) أنه يؤذي أمان المحفظة. هذا لأن الأمان شيء متعدد الجوانب، ويحسن 7702 الأمان في بعض الجوانب بينما يؤذي الأمان في جوانب أخرى.
يحسن 7702 الأمان للأسباب التالية:
7702 لا يحسن الأمان وربما يؤذي الأمان في بعض الطرق لأن:
لذلك، من الممكن حقًا أن يكون حساب 7702 أكثر أمانًا أو أقل أمانًا من حساب EOA، وأيضًا ما إذا كانت فوائد تجربة المستخدم تستحق تضحيات الأمان.
نظرًا لأن أهم خاصية للمحفظة هي الأمان، فإن أعلى المحافظ الحالية لن تخاطر بأمان المستخدم عن طريق تمكين 7702 افتراضيًا. بدلاً من ذلك، سينقلون القرار إلى المستخدمين ويتركون لهم القرار فيما إذا كانوا يرغبون في استخدام 7702 أم لا.
نظرًا لأن المحافظ العلوية ستقدم 7702 كميزة اختيارية ، فإن السؤال الطبيعي يصبح: هل سيختار المستخدمون الاشتراك؟
الجواب في الواقع بسيط جدًا: سيقوم المستخدمون بتمكين 7702 إذا كانوا حقًا يرغبون في استخدام dapp / ميزة تتطلب 7702 ، وإلا فلن يفعلوا ذلك. لذلك ، يؤدي هذا إلى الجزء الثاني من التحليل - كيف ستتبنى dapps 7702؟
بالنسبة لتطبيقات الويب اللامركزية، يحتوي 7702 (وAA بشكل عام) على أربعة اقتراحات قيم رئيسية:
تعمل هذه المزايا القيمة معًا على تحقيق فوائد تجربة مستخدم ملموسة ستميز تطبيقًا للتطبيقات الموزعة من منافسيه، لذلك لدى التطبيقات الموزعة حافز قوي للاستفادة من AA. السبب في عدم رؤية اعتماد التطبيقات الموزعة لـ AA حتى الآن يرجع إلى أن التطبيقات الموزعة يجب أن تختار نموذج حساب جديد بالكامل (حسابات ذكية) الذي لا يعمل مع 99٪ من المستخدمين (مستخدمي EOA)، ولكن مع 7702، يمكن للتطبيق الموزع تقديم هذه المزايا من تجربة المستخدم دون صرف مستخدمي EOA، لذلك يصبح حساب الفائدة / التكلفة للتطبيقات الموزعة للاعتماد على AA أكثر ملاءمة بكثير.
ولكن هنا نرى مشكلة الدجاجة والبيض - لا ترغب التطبيقات اللامركزية في إنفاق الوقت والموارد في دعم 7702 إذا كان عدد قليل جدًا من المستخدمين سيستخدمون محافظ 7702، ولكن المستخدمين أيضًا لن يمكنهم تمكين 7702 ما لم تكن هناك تطبيقات تدعم 7702. كيف نكسر هذه المشكلة؟
هذا يقودنا إلى فحص جزء آخر من مكدس Web3 - خدمات المحفظة المدمجة.
تماما مثل المحافظ المستقلة ، لن يقوم موفرو المحافظ المضمنة بتمكين 7702 افتراضيا ، بل يقدمون ذلك كخيار لعملائهم (مطوري dapp). ومع ذلك ، على عكس المحافظ المستقلة حيث يكون خيار تمكين 7702 على المستخدم (لأنه سيكون غير آمن بشكل رهيب إذا تمكن dapp من تمكين 7702 ل MetaMask الخاص بك) ، فإن خيار تمكين 7702 للمحافظ المضمنة سيقع على عاتق مطور dapp ، حيث أن المحافظ المضمنة هي بحكم التعريف محافظ جديدة ينشئها المطورون لمستخدميهم.
لذا، إذا كان مطور تطبيق داب يرغب في استغلال ميزات AA، فلن يحتاج إلى الانتظار حتى يختار مستخدموه 7702 - يمكنهم فقط استخدام المحافظ المضمنة الممكّنة بواسطة 7702.
الآن، قد تقول أن المطورين كانوا قادرين على الاستفادة من ERC-4337 من خلال المحافظ المضمنة أيضًا، ولكن ذلك لم يؤدي إلى اعتمادٍ ضخم للـ AA. الفارق الرئيسي مع 7702، ومع ذلك، هو أن المطورين ليس عليهم استبعاد مستخدمي EOA عندما يبنون بمحافظ المضمنة التي تدعم 7702. بدلاً من ذلك، يمكن للتطبيقات دعم كل من المحافظ المضمنة ومستخدمي EOA. يمكن لمستخدمي EOA الذين يرغبون في تجربة ميزات AA مع التطبيق تشغيل 7702 لمحافظهم EOA.
لذلك، ستلعب المحافظ المضمنة دورًا رئيسيًا في تعزيز اعتماد 7702، من خلال السماح للمطورين بتقديم ميزات AA دون الانتظار حتى يقوم المستخدمون بتمكين 7702 لمحافظهم المستقلة.
لقد فحصنا الآن كيف ستعتمد أربع مجموعات مختلفة - المحافظ والمستخدمون والتطبيقات المشفرة والمحافظ المضمنة - 7702 على الأرجح. دعنا نضع الآن كل شيء معًا.
نأمل أن يؤدي هذا الدورة الحميدة من المحافظ => التطبيقات الموزعة => المستخدمون => المحافظ إلى دفع المجال بأكمله لاعتماد 7702/AA، مما سيجلب تحسينًا بنسبة 10 أضعاف في تجربة المستخدم Web3 كما نعرفها اليوم، ويضع المسرحية لـ AA الأصلية، متى ما حدث ذلك.
في المقالة القادمة، سننغمس عميقًا في الجانب التقني وندرس كيف ستقوم المحافظ وتطبيقات الويب اللامركزية بتنفيذ دعم لـ 7702 بالضبط.
هذا هو الجزء 1 من سلسلة أكتبها لفحص التأثير الذي من المرجح أن يكون لـ EIP-7702 على أجزاء مختلفة من عالم العملات المشفرة، بما في ذلك:
في الجزء 1 ، أرغب في دراسة كيفية تبني 7702 وكيفية تطوره. هل سيتم تبنيه بسرعة فائقة أم سنرى دورة تبني طويلة جدًا؟ من سيتبناه أولاً؟ هذا هو موضوع هذه المقالة.
أولاً، ملخص سريع. EIP-7702 هو واحد من EIPs المقرر أن يدخل حيز التنفيذ في الترقية التالية لإيثيريوم (بيكترا) المقررة في الربع الأول من عام 2025.
مع EIP-7702، يمكن لـ EOA أن يقوم بـ "ترقية" نفسه إلى حساب ذكي، مع البقاء ك EOA والاحتفاظ بنفس العنوان في نفس الوقت.
بمجرد أن يتمتع المستخدم بالترقية، يمكنه بعد ذلك الاستفادة من معظم فوائد AA مثل رعاية الغاز، دفع المعاملات بدفعة واحدة، مفاتيح الوصول، إلخ.
EIP-7702 هو مقترح لتجريد الحساب، لكنه يختلف عن ERC-4337 بطرق حرجة:
في الواقع، النقطتان الأوليان - أن EIP-7702 يمكن أن يرقي حسابات العقد الذاتية وأن تظل حسابات العقد الذاتية حسابات العقد الذاتية حتى بعد الترقية - هما الأسباب الأكبر لماذا من المحتمل أن يعزز EIP-7702 اعتماد AA بشكل أكبر بكثير مما يمكن أن يفعله ERC-4337 وحده. هذا يعود لأن:
ومع ذلك، سيكون من الخطأ القول بأن EIP-7702 سيقتل ERC-4337. كما سنناقش في مقال مستقبلي، سيحتاج EIP-7702 إلى الاستفادة من ERC-4337 من أجل تحقيق كامل إمكاناته، لذا فإن EIP-7702 هو في الواقع أخبار جيدة بشكل لا يصدق لشركات ERC-4337 اليوم مثل@zerodev_app""> @zerodev_app.
الآن إلى النقطة الرئيسية لهذه المقالة: ما هي سرعة اعتماد 7702، وكيف سيتم تبنيه في الممارسة، أي كيف ستتبنى أجزاء مختلفة من كومة Web3 (على سبيل المثال، المحافظ، التطبيقات اللامركزية، البنية التحتية) 7702؟
بالنسبة للسؤال الأول - مدة الوقت - هناك بعض السيناريوهات الممكنة:
ترتيبي الشخصي لاحتمالات هذه السيناريوهات هو 2 > 3 >> 4 > 1 (مع 2/3 هي السيناريوهات المحتملة و 4/1 هي السيناريوهات الأقل احتمالا). بمعنى آخر ، من المحتمل أن يحقق 7702 اعتمادا هائلا في غضون بضع سنوات ، ولكن من غير المرجح أن يتم اعتماده بين عشية وضحاها أو يتم تجاهله تماما.
لمعرفة السبب، دعنا نفحص كيف سيتبين احتمال تبني 7702 في التطبيق العملي.
لنبدأ بفحص المحافظ، الذين يكونون في المرحلة الأعلى في دورة اعتماد 7702، لأنه من دون دعم المحافظ لـ 7702، لا يمكن لتطبيقات اللامركزية الاستفادة من ميزات 7702.
أولاً، دعنا نفرق بين المحافظ المستقلة مثل Gate.io و@MetaMask""> @MetaMask @CoinbaseWallet ، وخدمات المحفظة مثل Gate@privy_io""> @privy_io @dynamic_xyz @turnkeyhq @magic_labs. ستواجه المحافظ المستقلة وخدمات المحافظ حوافز مختلفة في اعتماد 7702. في هذا القسم نتحدث فقط عن المحافظ المستقلة.
محافظ مستقلة لديها بعض الخيارات عندما يتعلق الأمر بتبني 7702:
توقعي هو أن الذيل الطويل لشركات المحفظة سيذهب مع الخيار 3 (الانتظار والترقب) ، لسبب بسيط هو أن اعتماد 7702 يتطلب الكثير من العمل ، لذا قد لا يكون لدى معظم شركات المحفظة الوقت والموارد اللازمة لتنفيذه بسرعة. ومع ذلك ، فإن أهم المحافظ ، مثل MetaMask و Coinbase ، ستذهب مع الخيار 2 ، أي تنفيذ دعم 7702 بسرعة ولكن مطالبة المستخدمين بالاشتراك فيه. ستكون هناك أيضا محافظ مستقلة جديدة تتوافق مع الخيار 1 (تمكين 7702 افتراضيا) ، ولكن نظرا لأن المحافظ هي مساحة تنافسية ويصعب على اللاعبين الجدد الدخول إليها ، فمن الناحية الواقعية ، سيستخدم معظم المستخدمين المحافظ الحالية التي تتوافق مع الخيار 2 أو 3.
لماذا أعتقد أن المحافظ الأعلى ستنفذ دعم 7702 بسرعة؟ لأن:
الآن، لماذا أعتقد أن هذه المحافظ لن تمكِّن 7702 بشكل افتراضي، ولكنها ستتطلب من المستخدمين الاشتراك؟
بكلمة واحدة، الأمان.
موضوع الأمان مع 7702 هو موضوع دقيق للغاية ويستحق مشاركة خاصة به، لكن سأقوم بسرد الأساسيات هنا بسرعة.
باختصار، من غير الصحيح القول إما 1) أن 7702 يحسن أمان المحفظة، أو 2) أنه يؤذي أمان المحفظة. هذا لأن الأمان شيء متعدد الجوانب، ويحسن 7702 الأمان في بعض الجوانب بينما يؤذي الأمان في جوانب أخرى.
يحسن 7702 الأمان للأسباب التالية:
7702 لا يحسن الأمان وربما يؤذي الأمان في بعض الطرق لأن:
لذلك، من الممكن حقًا أن يكون حساب 7702 أكثر أمانًا أو أقل أمانًا من حساب EOA، وأيضًا ما إذا كانت فوائد تجربة المستخدم تستحق تضحيات الأمان.
نظرًا لأن أهم خاصية للمحفظة هي الأمان، فإن أعلى المحافظ الحالية لن تخاطر بأمان المستخدم عن طريق تمكين 7702 افتراضيًا. بدلاً من ذلك، سينقلون القرار إلى المستخدمين ويتركون لهم القرار فيما إذا كانوا يرغبون في استخدام 7702 أم لا.
نظرًا لأن المحافظ العلوية ستقدم 7702 كميزة اختيارية ، فإن السؤال الطبيعي يصبح: هل سيختار المستخدمون الاشتراك؟
الجواب في الواقع بسيط جدًا: سيقوم المستخدمون بتمكين 7702 إذا كانوا حقًا يرغبون في استخدام dapp / ميزة تتطلب 7702 ، وإلا فلن يفعلوا ذلك. لذلك ، يؤدي هذا إلى الجزء الثاني من التحليل - كيف ستتبنى dapps 7702؟
بالنسبة لتطبيقات الويب اللامركزية، يحتوي 7702 (وAA بشكل عام) على أربعة اقتراحات قيم رئيسية:
تعمل هذه المزايا القيمة معًا على تحقيق فوائد تجربة مستخدم ملموسة ستميز تطبيقًا للتطبيقات الموزعة من منافسيه، لذلك لدى التطبيقات الموزعة حافز قوي للاستفادة من AA. السبب في عدم رؤية اعتماد التطبيقات الموزعة لـ AA حتى الآن يرجع إلى أن التطبيقات الموزعة يجب أن تختار نموذج حساب جديد بالكامل (حسابات ذكية) الذي لا يعمل مع 99٪ من المستخدمين (مستخدمي EOA)، ولكن مع 7702، يمكن للتطبيق الموزع تقديم هذه المزايا من تجربة المستخدم دون صرف مستخدمي EOA، لذلك يصبح حساب الفائدة / التكلفة للتطبيقات الموزعة للاعتماد على AA أكثر ملاءمة بكثير.
ولكن هنا نرى مشكلة الدجاجة والبيض - لا ترغب التطبيقات اللامركزية في إنفاق الوقت والموارد في دعم 7702 إذا كان عدد قليل جدًا من المستخدمين سيستخدمون محافظ 7702، ولكن المستخدمين أيضًا لن يمكنهم تمكين 7702 ما لم تكن هناك تطبيقات تدعم 7702. كيف نكسر هذه المشكلة؟
هذا يقودنا إلى فحص جزء آخر من مكدس Web3 - خدمات المحفظة المدمجة.
تماما مثل المحافظ المستقلة ، لن يقوم موفرو المحافظ المضمنة بتمكين 7702 افتراضيا ، بل يقدمون ذلك كخيار لعملائهم (مطوري dapp). ومع ذلك ، على عكس المحافظ المستقلة حيث يكون خيار تمكين 7702 على المستخدم (لأنه سيكون غير آمن بشكل رهيب إذا تمكن dapp من تمكين 7702 ل MetaMask الخاص بك) ، فإن خيار تمكين 7702 للمحافظ المضمنة سيقع على عاتق مطور dapp ، حيث أن المحافظ المضمنة هي بحكم التعريف محافظ جديدة ينشئها المطورون لمستخدميهم.
لذا، إذا كان مطور تطبيق داب يرغب في استغلال ميزات AA، فلن يحتاج إلى الانتظار حتى يختار مستخدموه 7702 - يمكنهم فقط استخدام المحافظ المضمنة الممكّنة بواسطة 7702.
الآن، قد تقول أن المطورين كانوا قادرين على الاستفادة من ERC-4337 من خلال المحافظ المضمنة أيضًا، ولكن ذلك لم يؤدي إلى اعتمادٍ ضخم للـ AA. الفارق الرئيسي مع 7702، ومع ذلك، هو أن المطورين ليس عليهم استبعاد مستخدمي EOA عندما يبنون بمحافظ المضمنة التي تدعم 7702. بدلاً من ذلك، يمكن للتطبيقات دعم كل من المحافظ المضمنة ومستخدمي EOA. يمكن لمستخدمي EOA الذين يرغبون في تجربة ميزات AA مع التطبيق تشغيل 7702 لمحافظهم EOA.
لذلك، ستلعب المحافظ المضمنة دورًا رئيسيًا في تعزيز اعتماد 7702، من خلال السماح للمطورين بتقديم ميزات AA دون الانتظار حتى يقوم المستخدمون بتمكين 7702 لمحافظهم المستقلة.
لقد فحصنا الآن كيف ستعتمد أربع مجموعات مختلفة - المحافظ والمستخدمون والتطبيقات المشفرة والمحافظ المضمنة - 7702 على الأرجح. دعنا نضع الآن كل شيء معًا.
نأمل أن يؤدي هذا الدورة الحميدة من المحافظ => التطبيقات الموزعة => المستخدمون => المحافظ إلى دفع المجال بأكمله لاعتماد 7702/AA، مما سيجلب تحسينًا بنسبة 10 أضعاف في تجربة المستخدم Web3 كما نعرفها اليوم، ويضع المسرحية لـ AA الأصلية، متى ما حدث ذلك.
في المقالة القادمة، سننغمس عميقًا في الجانب التقني وندرس كيف ستقوم المحافظ وتطبيقات الويب اللامركزية بتنفيذ دعم لـ 7702 بالضبط.