تقدم هذه المقالة بشكل أساسي التطوير والمحتوى ذي الصلة للحسابات المجردة (AA، الحسابات المجردة) في حل الطبقة الثانية لـ zkSync. وسيكون التركيز على ثلاثة أجزاء:
عقد الحساب: نوع الحساب ونقطة الدخول المهمة والنقاط الرئيسية ذات الصلة بعقد الحساب
المعاملة: طريقة التحقق وطريقة التنفيذ وعملية معاملة AA
رسوم المناولة: رسوم المعاملات، صراف الرواتب
جدول المحتويات
مقدمة
لمحة موجزة عن عقد zkSync AA
نموذج الرسوم وPaymaster في عصر zkSync
ملخص ومقارنة
خاتمة
خلفية
على دراية بمحفظة العقود الذكية وميزاتها المشتركة
احصل على نظرة عامة حول كيفية عمل معاملات الايثيريوم
فهم عام لوضع تشغيل EIP-4337
فهم عام لوضع تشغيل مجموعة ZK (الصلاحية).
نظرة سريعة على zkSync
هنا، لسهولة القراءة، ليس من الضروري فهم zkSync بعمق، ولكن قم بمراجعة المعلومات الأساسية لـ zkSync بإيجاز. هناك إصداران رئيسيان من zkSync، الإصدار 1.0 (zkSync Lite) والإصدار 2.0 (zkSync Era).
يدعم الإصدار 1.0 من zkSync EOA (الحساب الخارجي) فقط ولا يدعم العقود الذكية (يدعم فقط نقل وتبادل الرموز المميزة)، بينما ينتمي zkSync 2.0، أي zkSync Era، إلى AA الأصلي (حساب مجرد) (جميع أنواع الحسابات عبارة عن عقود، ولا يوجد EOA) ، وهو الفرق بين EOA وحساب العقد في Ethereum)، وهو متوافق مع EVM (Ethereum Virtual Machine)، ويدعم تطوير العقود الذكية باستخدام Rust وYul وVyper وSolidity وما إلى ذلك.
يشير zkSync المذكور أدناه إلى zkSync 2.0، أي zkSync Era، ما لم ينص على خلاف ذلك.
يوجد في zkSync Era عقود متعددة، والتي يمكن فهمها لأنها تنفذ بعض وظائف نظام التشغيل المهمة لـ zkSync في العقود الذكية. هذه العقود عبارة عن عقود مجمعة مسبقًا ولم يتم نشرها مطلقًا (يتم تشغيلها مباشرة في العقدة)، ولكن جميعها لها عنوان رسمي.
عند تنفيذ بروتوكول AA، سيقوم zkSync بإجراء عمليات وأحكام منطقية من خلال بعض العقود، على سبيل المثال، عند التحقق من nonce، يتم الحكم عليه بواسطة NonceHolder، بينما يتم الحكم على تنفيذ آلية الحساب المجرد وتحصيل الرسوم بواسطة أداة تحميل التشغيل، وفيما يلي سيتم تقديم لهم واحدا تلو الآخر.
** خلاصة تجريد الحساب **
يمكن تلخيص المفهوم الأساسي لتجريد الحساب في نقطتين رئيسيتين: تجريد التوقيع وتجريد الدفع.
الهدف من تجريد التوقيع هو تمكين عقود الحسابات المختلفة من استخدام أنظمة تحقق مختلفة. وهذا يعني أن المستخدمين لا يقتصرون على خوارزمية التوقيع الرقمي التي يمكنها فقط استخدام منحنى محدد، ولكن يمكنهم اختيار أي آلية تحقق يريدونها.
يهدف تجريد الدفع إلى تزويد المستخدمين بمجموعة متنوعة من خيارات دفع المعاملات. على سبيل المثال، يمكن إجراء الدفعات باستخدام رموز ERC-20 بدلاً من الرموز الأصلية، أو يمكن رعاية المعاملات من قبل طرف ثالث، أو حتى نماذج دفع أخرى أكثر تخصيصًا.
يمكن للحسابات في zkSync 2.0 بدء معاملات مثل EOA، ولكن يمكنها أيضًا استخدام قابليتها للبرمجة لتنفيذ منطق عشوائي، مثل حسابات العقود. وهذا ما نسميه تجريد الحساب، والذي يجمع بين مزايا نوعي الحسابات في الايثيريوم لجعل تجربة استخدام حسابات AA أكثر مرونة، وبالتالي تحقيق الهدفين المذكورين أعلاه: تجريد التوقيع وتجريد الدفع.
** آلية AA في عصر zkSync **
في zkSync Era، الدور الأكثر أهمية لـ zkSync AA هو أداة تحميل التشغيل، وهو عقد يستخدم بشكل أساسي لمعالجة المعاملات وتنفيذ آلية AA، المقابلة لعقد EntryPoint الخاص بـ EIP-4337. لا يمكن للمستخدم استدعاء أداة تحميل التشغيل (يمكن تشغيلها فقط بواسطة المشغل)، ولم يتم نشرها مطلقًا (يتم تشغيلها مباشرة على العقدة)، ولكن لها عنوان رسمي (يمكن استخدامه لتلقي المدفوعات).
يلعب المشغل دورًا مهمًا في ZK Rollup، فهو خادم مركزي خارج السلسلة، وعلى غرار Sequencer الذي ربما رأيته، فهو مسؤول عن تشغيل العقود مثل أداة تحميل التشغيل من الخارج.
تم تصميم بروتوكولات تجريد الحساب الأصلي (مثل StarkNet وzkSync) بشكل أساسي بالرجوع إلى EIP-4337. في تنفيذ zkSync، سيرسل المستخدم المعاملة إلى المشغل، وسيقوم المشغل بإرسال المعاملة إلى أداة تحميل التشغيل وبدء عملية سلسلة من المعالجة.
من وجهة نظر الكتلة:
عندما يتلقى محمل الإقلاع مدخلات من المشغل، سيحدد محمل الإقلاع أولاً بعض متغيرات البيئة الخاصة بالكتلة (مثل سعر الغاز، ورقم الكتلة، والطابع الزمني للكتلة، وما إلى ذلك). بعد ذلك، سيقوم أداة تحميل التشغيل بقراءة قائمة المعاملات بشكل تسلسلي، والاستعلام أولاً عما إذا كان عقد الحساب يتوافق مع المعاملة (أي استدعاء وظيفة التحقق من الصحة في آلية AA)، ثم وضعها في الكتلة.
بعد التحقق من كل معاملة، يتحقق المشغل مما إذا كانت الكتلة كبيرة بما يكفي لإرسالها إلى أداة التحقق (أو ما إذا كانت المهلة قد انتهت). إذا كانت كبيرة بما يكفي أو انتهت المهلة، يقوم المشغل بإغلاق الكتلة، ويتوقف عن إضافة معاملات جديدة إلى أداة تحميل التشغيل، ويكمل تنفيذ المعاملة.
من منظور المعاملات، عندما يقوم المشغل بتشغيل أداة تحميل التشغيل، سيقوم برنامج تحميل التشغيل بمعالجة كل معاملة بالتسلسل:
تأكد مما إذا كان الرقم المطابق لعنوان العقد الخاص بحساب المستخدم قانونيًا
اتصل بوظيفة التحقق من صحة عقد حساب المستخدم للتحقق
بعد اجتياز عملية التحقق، سيقوم عقد الحساب بتحويل رسوم الغاز إلى عنوان أداة تحميل التشغيل (أو من خلال Paymaster، الذي سيتم تقديمه لاحقًا)، وسيقوم محمل التشغيل بالتحقق مما إذا كان قد تلقى أموالاً كافية.
قم باستدعاء وظيفة ute في عقد حساب المستخدم لتنفيذ المعاملة.
تتوافق الخطوات الثلاث الأولى أعلاه مع حلقة التحقق (حلقة التحقق) الخاصة بـ EIP-4337، والخطوة الرابعة تتوافق مع حلقة التنفيذ (حلقة ution) الخاصة بـ EIP-4337.
إليك بشكل أساسي مقدمة عامة، وسيتم تفصيل تفاصيل وأدوار كل خطوة واحدة تلو الأخرى في الوصف التفصيلي التالي.
نظرة سريعة على عقد الحساب المجرد zkSync
** نونس **
يتم تسجيل رقم حساب zkSync في عقد نظام يسمى NonceHolder، والذي يتذكر ما إذا كان كل زوج (حساب_عنوان، nonce) يتم استخدامه عن طريق التعيين (تعيين) للحكم على ما إذا كان الرقم قانونيًا.
وفقًا لما سبق، فإن الخطوة الأولى بعد قيام المشغل بتشغيل أداة تحميل التشغيل هي التحقق من الرقم. لذلك، قبل بدء كل معاملة، سيتم استخدام NonceHolder لتأكيد ما إذا كانت مجموعة الأرقام المستخدمة حاليًا قانونية (حاليًا يتحقق فقط مما إذا كان قد تم استخدامها). إذا كان الرقم قانونيًا، فسوف يدخل مرحلة التحقق (مرحلة التحقق)، وفي ذلك الوقت سيتم وضع علامة على الرقم كمستخدم؛ وإذا لم يكن قانونيًا، فستفشل المعاملة (التحقق).
نقاط مهمة حول الرقم الحالي لـ zkSync:
على الرغم من أنه يمكن للمستخدمين حاليًا إرسال معاملات متعددة بأحرف مختلفة إلى الحساب للتنفيذ في نفس الوقت، نظرًا لأن zkSync لا يدعم المعالجة المتوازية، ستظل تتم معالجة المعاملات ذات أحرف مختلفة بشكل تسلسلي.
من الناحية النظرية، يمكن للمستخدمين استخدام أي عدد صحيح غير صفري 256 بت مثل nonce، لكن zkSync لا يزال يوصي باستخدام incrementNonceIfEquals كطريقة لإدارة nonce للتأكد من زيادته بالترتيب (تؤكد آلية AA الخاصة بـ zkSync حاليًا فقط nonce غير المستخدم، لكن الرقم الرسمي تشير الوثيقة إلى أن الزيادة المتسلسلة قد تكون مطلوبة في المستقبل).
عقد الحساب
يحتوي عقد الحساب في zkSync على نقاط الدخول الأربع الضرورية التالية (نقطة الدخول)، وهي:
التحقق من صحة المعاملة: يتم استدعاؤه أثناء مرحلة التحقق للتأكد مما إذا كانت العملية مصرح بها من قبل مالك الحساب، حيث يمكن للمستخدمين تخصيص منطق التحقق الخاص بهم (مثل خوارزميات التوقيع المختلفة والتوقيع المتعدد وما إلى ذلك).
payForTransaction: عندما يتم دفع رسوم المعاملة عن طريق هذا الحساب (بدلاً من استخدام paymaster)، سيستدعي المشغل هذه الوظيفة لدفع tx.gasprice * tx.gaslimit من ETH على الأقل إلى عنوان أداة تحميل التشغيل.
PreparForPaymaster: عندما يقوم Paymaster بدفع رسوم المعاملة، سيقوم المشغل باستدعاء هذه الوظيفة لإكمال أعمال التحضير قبل التفاعل مع Paymaster. المثال المقدم من zkSync هو رمز ERC-20 معتمد من Paymaster.
uteTransaction: بعد اجتياز مرحلة التحقق بنجاح وتحصيل رسوم المعاملة بنجاح، سيتم استخدام هذه الوظيفة لتنفيذ العملية التي يريد المستخدم تحقيقها (مثل التفاعل مع العقد والتحويلات وما إلى ذلك).
بخصوص Paymaster، سيتم شرح مبلغ رسوم المناولة (tx.gasprice * tx.gaslimit)، وما إلى ذلك في الفصول اللاحقة.
هناك أيضًا وظيفة تأمين غير أساسية uteTransactionFromOutside في حساب zkSync. يمكن سحب الأموال إلى L1 باستخدام "آلية الهروب" عندما لا يمكن تنفيذ العمليات (على سبيل المثال عندما يكون مولد التسلسل غير مستجيب أو يتبين أن zkSync يمثل خطرًا تنظيميًا). هذا الجزء لا علاقة له ببروتوكول AA، لذا لن يتم وصفه بالتفصيل هنا، ويمكن للمهتمين التحقق من المستندات الرسمية ومواصفات zkSync.
** النقاط الرئيسية والقيود المفروضة على وظائف التحقق **
في وظيفة validateTransaction، يمكن تنفيذ العديد من المنطق المخصصة، على سبيل المثال، إذا قام الحساب بتطبيق معيار EIP-1271، فيمكن تطبيق منطق التحقق في EIP-1271 مباشرة على validateTransaction، أو الرجوع إلى عقد الحساب متعدد التوقيع التنفيذ في المستند الرسمي zkSync .
في الوقت نفسه، لتجنب تهديدات حجب الخدمة في مرحلة التحقق من EIP-4337، هناك بعض القيود (لا يمكن أن تتضمن أكواد تشغيل خارجية وعمق محدود، وما إلى ذلك)، وهناك قيود مماثلة في zkSync، على سبيل المثال:
1. يمكن لمنطق العقد أن يلمس الفتحة الخاصة به فقط (إذا كان عنوان عقد الحساب هو A):
الفتحة الخاصة بالعنوان أ
الفتحة A في أي عنوان آخر
الفتحة keccak256(A||X) لأي عنوان آخر، والتي يمكنها استخدام العنوان مباشرة كمفتاح التعيين (مثل التعيين (العنوان=>القيمة)))، تعادل أيضًا السماح بالوصول إلى الفتحة keccak256( A||X)، لتحقيق التوسع. على سبيل المثال، أرصدة الرموز المميزة على ERC-20.
2. يجب ألا يستخدم منطق العقد متغيرات عامة، مثل block.number
** النقاط الرئيسية والقيود المفروضة على تنفيذ الوظائف **
ما يجب ملاحظته في وظيفة uteTransaction هو أنه إذا كنت تريد إجراء مكالمة نظام (Call)، فأنت بحاجة إلى التأكد من أنها تحتوي على علامة is. لأن عقود النظام هذه لها تأثير كبير على نظام الحساب. على سبيل المثال، الطريقة الوحيدة لزيادة nonce هي التفاعل مع NonceHolder. لنشر عقد، يجب عليك التفاعل مع ContractDeployer. باستخدام علامة is يمكن أن يضمن تفاعل مطوري الحسابات بوعي مع عقود النظام.
ومع ذلك، فمن المستحسن استخدام مكتبة ContractsCaller التي توفرها zkSync لتجنب التعامل مع علامة is بنفسك، واستخدام CallWithPropagedRevert لإكمال استدعاء النظام.
يتضمن نموذج التعليمات البرمجية أعلاه التفاعل مع DEPLOYER__CONTRACT. إن موقف عقد النظام الأكثر شيوعًا الذي يواجهه مطورو الحسابات هو أننا نريد استخدام حساب لنشر العقد، وفي هذا الوقت، يجب علينا التفاعل مع عقد نظام ContractDeployer. في هذه الحالة، يحتاج مطور الحساب إلى التواصل مع عقد ContractDeployer للتأكد من نشر العقد بنجاح وتنفيذ العمليات المطلوبة.
نموذج الرسوم وPaymaster في عصر zkSync
الرسوم وحدود الغاز
نموذج رسوم zkSync مشابه جدًا لـ Ethereum، ولا يزال رمز الرسوم هو ETH. ومع ذلك، مثل حلول الطبقة الثانية الأخرى (مثل Arbitrum وOptimism)، يحتاج zkSync أيضًا إلى مراعاة التكلفة الإضافية للنشر إلى L1 (رسوم الأمان) بالإضافة إلى الحساب الأساسي وتكاليف فتحة الكتابة. نظرًا لأن سعر الغاز الذي ينشر البيانات إلى L1 غير مستقر للغاية، يحدد مشغل zkSync المعلمات الديناميكية التالية عند فتح كل كتلة (يبدأ في تسجيل المعاملات):
gasPrice: سعر الغاز بـ gwei، أي tx.gasprice في كائن المعاملة المذكور أعلاه
gasPerPubdata: كمية الغاز المطلوبة لنشر بايت من البيانات على الايثيريوم
بالإضافة إلى ذلك، على عكس EIP-4337، لا يحتاج zkSync إلى تحديد ثلاثة حدود للغاز: التحقق من الغاز، وutionGas، وpreVerificationGas، ولكنه يتطلب فقط حد الغاز لتغطية جميع التكاليف المذكورة أعلاه، لذلك يحتاج المستخدمون إلى التأكد من أن حد الغاز كافٍ لتغطية مرحلة التحقق ومرحلة الاستخدام وتحميل البيانات جميع النفقات مثل رسوم الأمن إلى L1. يتم تضمين تكلفة الرسوم هذه في tx.gaslimit في كائن المعاملة المذكور أعلاه.
يدفع Paymaster بشكل أساسي ETH إلى أداة تحميل التشغيل بدلاً من عقد حساب المستخدم في مرحلة رسوم دفع معاملة المستخدم. يمكن للمستخدمين اختيار Paymaster وطرق الدفع المختلفة لدفع رسوم المناولة، مثل (على سبيل المثال لا الحصر):
دفع رموز ERC-20 إلى Paymaster قبل بدء المعاملة أو بعد تنفيذها
قم بتعبئة عقد Paymaster ببطاقة الائتمان
سيستمر Paymaster في دفع جزء أو كل الرسوم للمستخدمين مجانًا
الطريقة التي يتفاعل بها المستخدمون مع Paymaster تعتمد على بروتوكولات مختلفة، يمكن أن تكون مركزية أو لا مركزية، يمكن أن تكون قبل أو بعد المعاملة، يمكن أن تستخدم رموز ERC-20 أو العطاء القانوني، أو حتى مجانية.
يتكون عقد Paymaster الخاص بـ zkSync بشكل أساسي من وظيفتين، وهما validateAndPayForPaymasterTransaction (مطلوب) وpostTransaction (اختياري)، وكلاهما لا يمكن استدعاؤهما إلا بواسطة أداة تحميل التشغيل:
validateAndPayForPaymasterTransaction هي الوظيفة الوحيدة التي يجب تنفيذها في عقد Paymaster بأكمله. عندما يتلقى المشغل معاملة بمعلمة Paymaster، فهذا يعني أن رسوم المعالجة لا يتم دفعها بواسطة عقد حساب المستخدم، ولكن بواسطة Paymaster. في هذه المرحلة، سيقوم المشغل بالاتصال بـ validateAndPayForPaymasterTransaction لتحديد ما إذا كان Paymaster مستعدًا لدفع رسوم المعاملة. إذا وافق Paymaster، سترسل هذه الوظيفة على الأقل tx.gasprice * tx.gaslimit ETH إلى أداة تحميل التشغيل.
ما بعد المعاملة هي وظيفة اختيارية، تستخدم عادةً لاسترداد الأموال (إعادة الغاز غير المستخدم إلى المرسل). ومع ذلك، فإن zkSync الحالي لا يدعم هذه العملية حتى الآن.
سيقوم Paymaster في zkSync بتنفيذ postTransaction بعد تنفيذ postTransaction، وهو يختلف عن EIP-4337. لن يقوم EIP-4337 باستدعاء postOp عندما لا يقوم validatePaymasterUserOp بإرجاع السياق، والعكس صحيح.
بناءً على ما سبق، على سبيل المثال، يريد المستخدم الآن إرسال معاملة يتم دفع رسوم معالجتها من قبل Paymaster، تتم العملية كما يلي:
استخدم NonceHolder لتأكيد ما إذا كان nonce قانونيًا أم لا
اتصل بـ validateTransaction على عقد حساب المستخدم للتحقق من أن المعاملة مرخصة من قبل مالك الحساب
اتصل بـ PreparationForPaymaster بشأن عقد حساب المستخدم، والذي قد ينفذ، على سبيل المثال، الموافقة على عدد معين من رموز ERC-20 إلى Paymaster أو لا يفعل شيئًا
اتصل بـ validateAndPayForPaymasterTransaction على عقد Paymaster للتأكد من أن Paymaster على استعداد لدفع وتحصيل رسوم المناولة، وفي الوقت نفسه، سيفرض Paymaster على المستخدم مبلغًا معينًا من ERC-20 (تمت الموافقة عليه مسبقًا)
تأكد من أن أداة تحميل التشغيل تتلقى المبلغ الصحيح (على الأقل tx.gasprice * tx.gaslimit) من رسوم ETH
اتصل بـ uteTransaction على عقد حساب المستخدم لتنفيذ المعاملة التي يريدها المستخدم
إذا كان عقد مسؤول صرف الرواتب ينفذ ما بعد المعاملة وكان الغاز لا يزال كافيًا (لا يوجد خطأ خارج الغاز)، فقم بتنفيذ ما بعد المعاملة
في الخطوة الأخيرة، حتى إذا تعذر تنفيذ المعاملة اللاحقة بسبب خطأ نفاد الغاز، فإن معاملة AA هذه تعتبر ناجحة، ولكن يتم حذف إجراء استدعاء المعاملة اللاحقة.
إذا تعمقت في Paymaster الخاص بـ zkSync، فستجد أن قواعد التحقق الخاصة به تختلف قليلاً عن 4337 (يمكن لـ zkSync Paymaster أن يتدخل في أي فتحة عقد أخرى)، وهناك أيضًا أنواع مختلفة (مثل القائمة على الموافقة). لمقارنة التفاصيل، ويمكن للمهتمين الرجوع إلى المستندات الرسمية أو تنفيذي السابق.
** ملخص ومقارنة **
من خلال الشروحات السابقة تعرفنا على ما هي نقاط الدخول المهمة التي يتضمنها عقد الحساب، وكذلك وظائفها والقيود المتعلقة بها. وفي الوقت نفسه، تعرفنا أيضًا على وظائف عقد النظام. بعد ذلك، دعونا نلخص عملية معاملة التشغيل الآلي (AA) في zkSync من الإنشاء إلى الاكتمال، وسأقدم أيضًا مراجع أكثر تفصيلاً لأولئك الذين يرغبون في معرفة المزيد:
يستخدم المستخدم SDK أو المحفظة محليًا لإنشاء كائنات المعاملات (على سبيل المثال: من، إلى، البيانات، القيمة، وما إلى ذلك).
يقوم المستخدم بالتوقيع على المعاملة. التوقيع هنا ليس بالضرورة تنسيق EIP-712 التقليدي وتوقيع منحنى ECDSA. يدعم zkSync أيضًا EIP-2718 وEIP-1559. مفتاح اختيار طريقة التوقيع وطريقة التحقق هو التحقق من خلال وظيفة التحقق في عقد الحساب.
أرسل المعاملة الموقعة إلى المشغل من خلال RPC API. عند هذه النقطة، تدخل المعاملة في الحالة المعلقة. يقوم المشغل بتمرير المعاملة إلى أداة تحميل التشغيل (يستدعي وظيفةprocessL2Tx في عقد أداة تحميل التشغيل)، ويبدأ سلسلة من عمليات بروتوكول AA.
سوف يتحقق Bootloader مما إذا كان Nonce قانونيًا، ويستخدم NonceHolder للتحقق.
سيقوم Bootloader باستدعاء وظيفة validateTransaction في عقد حساب المستخدم للتأكد من أن المعاملة قد تمت الموافقة عليها من قبل مالك الحساب.
هناك طريقتان لـ Bootloader لتحصيل الرسوم، وتعتمد طريقة الشحن المحددة على معلمات المعاملة (سواء كانت معلمة paymaster مرفقة عند إنشاء كائن المعاملة):
ب. اتصل بوظائف PreparForPaymaster وvalidateAndPayForPaymasterTransaction لتحصيل رسوم المعاملة مع عقد Paymaster.
"اتصل بـ payForTransaction لمعرفة رسوم العقد مع الحساب" أو "اتصل بـ PreparForPaymaster وقم بالتحقق من صحة AndPayForPaymasterTransaction لمعرفة رسوم العقد مع Paymaster"
تحقق مما إذا كان برنامج تحميل التشغيل قد تلقى على الأقل رسوم المعاملات tx.gasprice * tx.gaslimit.
سوف يقوم Bootloader باستدعاء وظيفة uteTransaction في عقد حساب المستخدم لتنفيذ المعاملة.
(اختياري) في حالة استخدام Paymaster لدفع رسوم المعاملة، سيقوم برنامج تحميل التشغيل باستدعاء وظيفة postTransaction. إذا لم ينفذ Paymaster ما بعد المعاملة، أو تم استنفاد الغاز، فسيتم تخطي هذه الخطوة.
الخطوات 4.~7. المذكورة أعلاه هي مرحلة التحقق (المحددة في l2TxValidation الخاص بمحمل التشغيل)، ومرحلة تنفيذ الخطوة 8.~9 (المحددة في l2Txution الخاص بمحمل التشغيل).
مقارنة بين EIP-4337 وStarkNet وzkSync Era
في الأساس، عمليات آلية AA الثلاثة متشابهة، وكلها هي مرحلة التحقق ← آلية رسوم المناولة (المدفوعة عن طريق عقد الحساب أو صراف الرواتب) ← مرحلة التنفيذ. الاختلافات الرئيسية هي:
دور تنفيذ آلية AA هو: الفرق بين الفتح في عصر zkSync والآليتين الأخريين AA هو أن المشغل يحتاج إلى التعاون مع محمل الإقلاع (عقد النظام)، على سبيل المثال، سيفتح محمل الإقلاع كتلة جديدة ويحددها المعلمات ذات الصلة للكتلة، واستلام عملية التاجر التي يرسلها العضو ويتم التحقق منها. في 4337، يتم تنسيق هذا الجزء بواسطة Bundler وEntryPoint، بينما في StarkNet، هذا الجزء هو المسؤول بالكامل عن Sequencer.
هل تحتاج تكلفة الغاز إلى مراعاة رسوم أمان المستوى 1: يحتاج L2 AA إلى مراعاة تكلفة تحميل البيانات إلى المستوى 1، وليس فقط مجموعات ZK (الصلاحية) المجمعة الأصلية AA المذكورة في الدفع، ولكن يجب أيضًا تضمينها في المستوى 1 عندما تكون متفائلة تطبق المجموعات المجمعة رسوم الأمان 4337 (محسوبة في preVerificationGas، راجع المستندات ذات الصلة بـ Alchemy للحصول على التفاصيل).
ما إذا كان من الممكن إرسال المعاملات قبل نشر عقد الحساب: في عصر StarkNet وzkSync، لا يوجد EntryPoint مثل 4337 الذي يحتوي على حقل initCode للسماح للمستخدم بنشر عقد الحساب، لذلك لا يرسل المعاملات قبل أن تتمكن من تكوين الحساب.
مقارنة
بما أن StarkNet لم تدرك بعد آلية Paymaster، ولم تكمل zkSync بعد تصميم آلية استرداد الغاز، فإن بعض المقارنات الأكثر تفصيلاً غير مدرجة هنا.
بالإضافة إلى ذلك، لقد أكملنا مجمع ذاكرة P2P لمجمع 4337 الحالي، كما أن مُسلسل ومشغل zkRollups هما أيضًا الخوادم الرسمية الوحيدة، لذلك هناك مكونات مركزية معينة.
في عملية التطوير، نظرًا لأن zkSync لا يواجه مشكلة الاتصال بمختلف المجمعات (يحتاج فقط إلى التفاعل مع واجهة برمجة تطبيقات المشغل)، فمن السهل استخدام 4337، كما أن تجربة تطوير عقود الحساب (SDK) أفضل أيضًا؛ في في الوقت نفسه، يمكن لـ zkSync استخدام Solidity كلغة تطوير تعاقدية، لذلك ليست هناك حاجة لعبور عتبة القاهرة في تطوير StarkNet.
خاتمة
نظرًا لأن كلاً من StarkNet وzkSync ينتميان إلى فئة AA المحلية (AA الأصلية)، يمكنك أيضًا الرجوع إلى مقدمتي السابقة لـ StarkNet AA، بعنوان "مقدمة لتجريد حساب StarkNet" (مقدمة لتجريد حساب StarkNet). يمكنك أيضًا قراءة مقالات أخرى متعلقة بـ EIP-4337 لمزيد من المعلومات.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
مقدمة لتجريد الحساب الأصلي في zkSync
المؤلف: بقلم ChiHaoLu، imToken Labs
تقدم هذه المقالة بشكل أساسي التطوير والمحتوى ذي الصلة للحسابات المجردة (AA، الحسابات المجردة) في حل الطبقة الثانية لـ zkSync. وسيكون التركيز على ثلاثة أجزاء:
جدول المحتويات
خلفية
هنا، لسهولة القراءة، ليس من الضروري فهم zkSync بعمق، ولكن قم بمراجعة المعلومات الأساسية لـ zkSync بإيجاز. هناك إصداران رئيسيان من zkSync، الإصدار 1.0 (zkSync Lite) والإصدار 2.0 (zkSync Era).
يدعم الإصدار 1.0 من zkSync EOA (الحساب الخارجي) فقط ولا يدعم العقود الذكية (يدعم فقط نقل وتبادل الرموز المميزة)، بينما ينتمي zkSync 2.0، أي zkSync Era، إلى AA الأصلي (حساب مجرد) (جميع أنواع الحسابات عبارة عن عقود، ولا يوجد EOA) ، وهو الفرق بين EOA وحساب العقد في Ethereum)، وهو متوافق مع EVM (Ethereum Virtual Machine)، ويدعم تطوير العقود الذكية باستخدام Rust وYul وVyper وSolidity وما إلى ذلك.
يشير zkSync المذكور أدناه إلى zkSync 2.0، أي zkSync Era، ما لم ينص على خلاف ذلك.
يوجد في zkSync Era عقود متعددة، والتي يمكن فهمها لأنها تنفذ بعض وظائف نظام التشغيل المهمة لـ zkSync في العقود الذكية. هذه العقود عبارة عن عقود مجمعة مسبقًا ولم يتم نشرها مطلقًا (يتم تشغيلها مباشرة في العقدة)، ولكن جميعها لها عنوان رسمي.
عند تنفيذ بروتوكول AA، سيقوم zkSync بإجراء عمليات وأحكام منطقية من خلال بعض العقود، على سبيل المثال، عند التحقق من nonce، يتم الحكم عليه بواسطة NonceHolder، بينما يتم الحكم على تنفيذ آلية الحساب المجرد وتحصيل الرسوم بواسطة أداة تحميل التشغيل، وفيما يلي سيتم تقديم لهم واحدا تلو الآخر.
** خلاصة تجريد الحساب **
يمكن تلخيص المفهوم الأساسي لتجريد الحساب في نقطتين رئيسيتين: تجريد التوقيع وتجريد الدفع.
الهدف من تجريد التوقيع هو تمكين عقود الحسابات المختلفة من استخدام أنظمة تحقق مختلفة. وهذا يعني أن المستخدمين لا يقتصرون على خوارزمية التوقيع الرقمي التي يمكنها فقط استخدام منحنى محدد، ولكن يمكنهم اختيار أي آلية تحقق يريدونها.
يهدف تجريد الدفع إلى تزويد المستخدمين بمجموعة متنوعة من خيارات دفع المعاملات. على سبيل المثال، يمكن إجراء الدفعات باستخدام رموز ERC-20 بدلاً من الرموز الأصلية، أو يمكن رعاية المعاملات من قبل طرف ثالث، أو حتى نماذج دفع أخرى أكثر تخصيصًا.
يمكن للحسابات في zkSync 2.0 بدء معاملات مثل EOA، ولكن يمكنها أيضًا استخدام قابليتها للبرمجة لتنفيذ منطق عشوائي، مثل حسابات العقود. وهذا ما نسميه تجريد الحساب، والذي يجمع بين مزايا نوعي الحسابات في الايثيريوم لجعل تجربة استخدام حسابات AA أكثر مرونة، وبالتالي تحقيق الهدفين المذكورين أعلاه: تجريد التوقيع وتجريد الدفع.
** آلية AA في عصر zkSync **
في zkSync Era، الدور الأكثر أهمية لـ zkSync AA هو أداة تحميل التشغيل، وهو عقد يستخدم بشكل أساسي لمعالجة المعاملات وتنفيذ آلية AA، المقابلة لعقد EntryPoint الخاص بـ EIP-4337. لا يمكن للمستخدم استدعاء أداة تحميل التشغيل (يمكن تشغيلها فقط بواسطة المشغل)، ولم يتم نشرها مطلقًا (يتم تشغيلها مباشرة على العقدة)، ولكن لها عنوان رسمي (يمكن استخدامه لتلقي المدفوعات).
يلعب المشغل دورًا مهمًا في ZK Rollup، فهو خادم مركزي خارج السلسلة، وعلى غرار Sequencer الذي ربما رأيته، فهو مسؤول عن تشغيل العقود مثل أداة تحميل التشغيل من الخارج.
تم تصميم بروتوكولات تجريد الحساب الأصلي (مثل StarkNet وzkSync) بشكل أساسي بالرجوع إلى EIP-4337. في تنفيذ zkSync، سيرسل المستخدم المعاملة إلى المشغل، وسيقوم المشغل بإرسال المعاملة إلى أداة تحميل التشغيل وبدء عملية سلسلة من المعالجة.
من وجهة نظر الكتلة:
عندما يتلقى محمل الإقلاع مدخلات من المشغل، سيحدد محمل الإقلاع أولاً بعض متغيرات البيئة الخاصة بالكتلة (مثل سعر الغاز، ورقم الكتلة، والطابع الزمني للكتلة، وما إلى ذلك). بعد ذلك، سيقوم أداة تحميل التشغيل بقراءة قائمة المعاملات بشكل تسلسلي، والاستعلام أولاً عما إذا كان عقد الحساب يتوافق مع المعاملة (أي استدعاء وظيفة التحقق من الصحة في آلية AA)، ثم وضعها في الكتلة.
بعد التحقق من كل معاملة، يتحقق المشغل مما إذا كانت الكتلة كبيرة بما يكفي لإرسالها إلى أداة التحقق (أو ما إذا كانت المهلة قد انتهت). إذا كانت كبيرة بما يكفي أو انتهت المهلة، يقوم المشغل بإغلاق الكتلة، ويتوقف عن إضافة معاملات جديدة إلى أداة تحميل التشغيل، ويكمل تنفيذ المعاملة.
من منظور المعاملات، عندما يقوم المشغل بتشغيل أداة تحميل التشغيل، سيقوم برنامج تحميل التشغيل بمعالجة كل معاملة بالتسلسل:
تتوافق الخطوات الثلاث الأولى أعلاه مع حلقة التحقق (حلقة التحقق) الخاصة بـ EIP-4337، والخطوة الرابعة تتوافق مع حلقة التنفيذ (حلقة ution) الخاصة بـ EIP-4337.
إليك بشكل أساسي مقدمة عامة، وسيتم تفصيل تفاصيل وأدوار كل خطوة واحدة تلو الأخرى في الوصف التفصيلي التالي.
نظرة سريعة على عقد الحساب المجرد zkSync
** نونس **
يتم تسجيل رقم حساب zkSync في عقد نظام يسمى NonceHolder، والذي يتذكر ما إذا كان كل زوج (حساب_عنوان، nonce) يتم استخدامه عن طريق التعيين (تعيين) للحكم على ما إذا كان الرقم قانونيًا.
وفقًا لما سبق، فإن الخطوة الأولى بعد قيام المشغل بتشغيل أداة تحميل التشغيل هي التحقق من الرقم. لذلك، قبل بدء كل معاملة، سيتم استخدام NonceHolder لتأكيد ما إذا كانت مجموعة الأرقام المستخدمة حاليًا قانونية (حاليًا يتحقق فقط مما إذا كان قد تم استخدامها). إذا كان الرقم قانونيًا، فسوف يدخل مرحلة التحقق (مرحلة التحقق)، وفي ذلك الوقت سيتم وضع علامة على الرقم كمستخدم؛ وإذا لم يكن قانونيًا، فستفشل المعاملة (التحقق).
نقاط مهمة حول الرقم الحالي لـ zkSync:
على الرغم من أنه يمكن للمستخدمين حاليًا إرسال معاملات متعددة بأحرف مختلفة إلى الحساب للتنفيذ في نفس الوقت، نظرًا لأن zkSync لا يدعم المعالجة المتوازية، ستظل تتم معالجة المعاملات ذات أحرف مختلفة بشكل تسلسلي.
من الناحية النظرية، يمكن للمستخدمين استخدام أي عدد صحيح غير صفري 256 بت مثل nonce، لكن zkSync لا يزال يوصي باستخدام incrementNonceIfEquals كطريقة لإدارة nonce للتأكد من زيادته بالترتيب (تؤكد آلية AA الخاصة بـ zkSync حاليًا فقط nonce غير المستخدم، لكن الرقم الرسمي تشير الوثيقة إلى أن الزيادة المتسلسلة قد تكون مطلوبة في المستقبل).
عقد الحساب
يحتوي عقد الحساب في zkSync على نقاط الدخول الأربع الضرورية التالية (نقطة الدخول)، وهي:
بخصوص Paymaster، سيتم شرح مبلغ رسوم المناولة (tx.gasprice * tx.gaslimit)، وما إلى ذلك في الفصول اللاحقة.
هناك أيضًا وظيفة تأمين غير أساسية uteTransactionFromOutside في حساب zkSync. يمكن سحب الأموال إلى L1 باستخدام "آلية الهروب" عندما لا يمكن تنفيذ العمليات (على سبيل المثال عندما يكون مولد التسلسل غير مستجيب أو يتبين أن zkSync يمثل خطرًا تنظيميًا). هذا الجزء لا علاقة له ببروتوكول AA، لذا لن يتم وصفه بالتفصيل هنا، ويمكن للمهتمين التحقق من المستندات الرسمية ومواصفات zkSync.
** النقاط الرئيسية والقيود المفروضة على وظائف التحقق **
في وظيفة validateTransaction، يمكن تنفيذ العديد من المنطق المخصصة، على سبيل المثال، إذا قام الحساب بتطبيق معيار EIP-1271، فيمكن تطبيق منطق التحقق في EIP-1271 مباشرة على validateTransaction، أو الرجوع إلى عقد الحساب متعدد التوقيع التنفيذ في المستند الرسمي zkSync .
في الوقت نفسه، لتجنب تهديدات حجب الخدمة في مرحلة التحقق من EIP-4337، هناك بعض القيود (لا يمكن أن تتضمن أكواد تشغيل خارجية وعمق محدود، وما إلى ذلك)، وهناك قيود مماثلة في zkSync، على سبيل المثال:
1. يمكن لمنطق العقد أن يلمس الفتحة الخاصة به فقط (إذا كان عنوان عقد الحساب هو A):
الفتحة الخاصة بالعنوان أ
الفتحة A في أي عنوان آخر
الفتحة keccak256(A||X) لأي عنوان آخر، والتي يمكنها استخدام العنوان مباشرة كمفتاح التعيين (مثل التعيين (العنوان=>القيمة)))، تعادل أيضًا السماح بالوصول إلى الفتحة keccak256( A||X)، لتحقيق التوسع. على سبيل المثال، أرصدة الرموز المميزة على ERC-20.
2. يجب ألا يستخدم منطق العقد متغيرات عامة، مثل block.number
** النقاط الرئيسية والقيود المفروضة على تنفيذ الوظائف **
ما يجب ملاحظته في وظيفة uteTransaction هو أنه إذا كنت تريد إجراء مكالمة نظام (Call)، فأنت بحاجة إلى التأكد من أنها تحتوي على علامة is. لأن عقود النظام هذه لها تأثير كبير على نظام الحساب. على سبيل المثال، الطريقة الوحيدة لزيادة nonce هي التفاعل مع NonceHolder. لنشر عقد، يجب عليك التفاعل مع ContractDeployer. باستخدام علامة is يمكن أن يضمن تفاعل مطوري الحسابات بوعي مع عقود النظام.
ومع ذلك، فمن المستحسن استخدام مكتبة ContractsCaller التي توفرها zkSync لتجنب التعامل مع علامة is بنفسك، واستخدام CallWithPropagedRevert لإكمال استدعاء النظام.
يتضمن نموذج التعليمات البرمجية أعلاه التفاعل مع DEPLOYER__CONTRACT. إن موقف عقد النظام الأكثر شيوعًا الذي يواجهه مطورو الحسابات هو أننا نريد استخدام حساب لنشر العقد، وفي هذا الوقت، يجب علينا التفاعل مع عقد نظام ContractDeployer. في هذه الحالة، يحتاج مطور الحساب إلى التواصل مع عقد ContractDeployer للتأكد من نشر العقد بنجاح وتنفيذ العمليات المطلوبة.
نموذج الرسوم وPaymaster في عصر zkSync
الرسوم وحدود الغاز
نموذج رسوم zkSync مشابه جدًا لـ Ethereum، ولا يزال رمز الرسوم هو ETH. ومع ذلك، مثل حلول الطبقة الثانية الأخرى (مثل Arbitrum وOptimism)، يحتاج zkSync أيضًا إلى مراعاة التكلفة الإضافية للنشر إلى L1 (رسوم الأمان) بالإضافة إلى الحساب الأساسي وتكاليف فتحة الكتابة. نظرًا لأن سعر الغاز الذي ينشر البيانات إلى L1 غير مستقر للغاية، يحدد مشغل zkSync المعلمات الديناميكية التالية عند فتح كل كتلة (يبدأ في تسجيل المعاملات):
gasPrice: سعر الغاز بـ gwei، أي tx.gasprice في كائن المعاملة المذكور أعلاه
gasPerPubdata: كمية الغاز المطلوبة لنشر بايت من البيانات على الايثيريوم
بالإضافة إلى ذلك، على عكس EIP-4337، لا يحتاج zkSync إلى تحديد ثلاثة حدود للغاز: التحقق من الغاز، وutionGas، وpreVerificationGas، ولكنه يتطلب فقط حد الغاز لتغطية جميع التكاليف المذكورة أعلاه، لذلك يحتاج المستخدمون إلى التأكد من أن حد الغاز كافٍ لتغطية مرحلة التحقق ومرحلة الاستخدام وتحميل البيانات جميع النفقات مثل رسوم الأمن إلى L1. يتم تضمين تكلفة الرسوم هذه في tx.gaslimit في كائن المعاملة المذكور أعلاه.
اضرب الاثنين (tx.gasprice * tx.gaslimit) لتحصل على رسوم المعاملة المدفوعة لمحمل الإقلاع.
** صراف الرواتب **
يدفع Paymaster بشكل أساسي ETH إلى أداة تحميل التشغيل بدلاً من عقد حساب المستخدم في مرحلة رسوم دفع معاملة المستخدم. يمكن للمستخدمين اختيار Paymaster وطرق الدفع المختلفة لدفع رسوم المناولة، مثل (على سبيل المثال لا الحصر):
دفع رموز ERC-20 إلى Paymaster قبل بدء المعاملة أو بعد تنفيذها
قم بتعبئة عقد Paymaster ببطاقة الائتمان
سيستمر Paymaster في دفع جزء أو كل الرسوم للمستخدمين مجانًا
الطريقة التي يتفاعل بها المستخدمون مع Paymaster تعتمد على بروتوكولات مختلفة، يمكن أن تكون مركزية أو لا مركزية، يمكن أن تكون قبل أو بعد المعاملة، يمكن أن تستخدم رموز ERC-20 أو العطاء القانوني، أو حتى مجانية.
يتكون عقد Paymaster الخاص بـ zkSync بشكل أساسي من وظيفتين، وهما validateAndPayForPaymasterTransaction (مطلوب) وpostTransaction (اختياري)، وكلاهما لا يمكن استدعاؤهما إلا بواسطة أداة تحميل التشغيل:
validateAndPayForPaymasterTransaction هي الوظيفة الوحيدة التي يجب تنفيذها في عقد Paymaster بأكمله. عندما يتلقى المشغل معاملة بمعلمة Paymaster، فهذا يعني أن رسوم المعالجة لا يتم دفعها بواسطة عقد حساب المستخدم، ولكن بواسطة Paymaster. في هذه المرحلة، سيقوم المشغل بالاتصال بـ validateAndPayForPaymasterTransaction لتحديد ما إذا كان Paymaster مستعدًا لدفع رسوم المعاملة. إذا وافق Paymaster، سترسل هذه الوظيفة على الأقل tx.gasprice * tx.gaslimit ETH إلى أداة تحميل التشغيل.
ما بعد المعاملة هي وظيفة اختيارية، تستخدم عادةً لاسترداد الأموال (إعادة الغاز غير المستخدم إلى المرسل). ومع ذلك، فإن zkSync الحالي لا يدعم هذه العملية حتى الآن.
سيقوم Paymaster في zkSync بتنفيذ postTransaction بعد تنفيذ postTransaction، وهو يختلف عن EIP-4337. لن يقوم EIP-4337 باستدعاء postOp عندما لا يقوم validatePaymasterUserOp بإرجاع السياق، والعكس صحيح.
بناءً على ما سبق، على سبيل المثال، يريد المستخدم الآن إرسال معاملة يتم دفع رسوم معالجتها من قبل Paymaster، تتم العملية كما يلي:
في الخطوة الأخيرة، حتى إذا تعذر تنفيذ المعاملة اللاحقة بسبب خطأ نفاد الغاز، فإن معاملة AA هذه تعتبر ناجحة، ولكن يتم حذف إجراء استدعاء المعاملة اللاحقة.
إذا تعمقت في Paymaster الخاص بـ zkSync، فستجد أن قواعد التحقق الخاصة به تختلف قليلاً عن 4337 (يمكن لـ zkSync Paymaster أن يتدخل في أي فتحة عقد أخرى)، وهناك أيضًا أنواع مختلفة (مثل القائمة على الموافقة). لمقارنة التفاصيل، ويمكن للمهتمين الرجوع إلى المستندات الرسمية أو تنفيذي السابق.
** ملخص ومقارنة **
من خلال الشروحات السابقة تعرفنا على ما هي نقاط الدخول المهمة التي يتضمنها عقد الحساب، وكذلك وظائفها والقيود المتعلقة بها. وفي الوقت نفسه، تعرفنا أيضًا على وظائف عقد النظام. بعد ذلك، دعونا نلخص عملية معاملة التشغيل الآلي (AA) في zkSync من الإنشاء إلى الاكتمال، وسأقدم أيضًا مراجع أكثر تفصيلاً لأولئك الذين يرغبون في معرفة المزيد:
يستخدم المستخدم SDK أو المحفظة محليًا لإنشاء كائنات المعاملات (على سبيل المثال: من، إلى، البيانات، القيمة، وما إلى ذلك).
يقوم المستخدم بالتوقيع على المعاملة. التوقيع هنا ليس بالضرورة تنسيق EIP-712 التقليدي وتوقيع منحنى ECDSA. يدعم zkSync أيضًا EIP-2718 وEIP-1559. مفتاح اختيار طريقة التوقيع وطريقة التحقق هو التحقق من خلال وظيفة التحقق في عقد الحساب.
أرسل المعاملة الموقعة إلى المشغل من خلال RPC API. عند هذه النقطة، تدخل المعاملة في الحالة المعلقة. يقوم المشغل بتمرير المعاملة إلى أداة تحميل التشغيل (يستدعي وظيفةprocessL2Tx في عقد أداة تحميل التشغيل)، ويبدأ سلسلة من عمليات بروتوكول AA.
سوف يتحقق Bootloader مما إذا كان Nonce قانونيًا، ويستخدم NonceHolder للتحقق.
سيقوم Bootloader باستدعاء وظيفة validateTransaction في عقد حساب المستخدم للتأكد من أن المعاملة قد تمت الموافقة عليها من قبل مالك الحساب.
هناك طريقتان لـ Bootloader لتحصيل الرسوم، وتعتمد طريقة الشحن المحددة على معلمات المعاملة (سواء كانت معلمة paymaster مرفقة عند إنشاء كائن المعاملة):
أ. اتصل بوظيفة payForTransaction وعقد الحساب لتحصيل رسوم المعاملة؛
ب. اتصل بوظائف PreparForPaymaster وvalidateAndPayForPaymasterTransaction لتحصيل رسوم المعاملة مع عقد Paymaster.
"اتصل بـ payForTransaction لمعرفة رسوم العقد مع الحساب" أو "اتصل بـ PreparForPaymaster وقم بالتحقق من صحة AndPayForPaymasterTransaction لمعرفة رسوم العقد مع Paymaster"
تحقق مما إذا كان برنامج تحميل التشغيل قد تلقى على الأقل رسوم المعاملات tx.gasprice * tx.gaslimit.
سوف يقوم Bootloader باستدعاء وظيفة uteTransaction في عقد حساب المستخدم لتنفيذ المعاملة.
(اختياري) في حالة استخدام Paymaster لدفع رسوم المعاملة، سيقوم برنامج تحميل التشغيل باستدعاء وظيفة postTransaction. إذا لم ينفذ Paymaster ما بعد المعاملة، أو تم استنفاد الغاز، فسيتم تخطي هذه الخطوة.
الخطوات 4.~7. المذكورة أعلاه هي مرحلة التحقق (المحددة في l2TxValidation الخاص بمحمل التشغيل)، ومرحلة تنفيذ الخطوة 8.~9 (المحددة في l2Txution الخاص بمحمل التشغيل).
مقارنة بين EIP-4337 وStarkNet وzkSync Era
في الأساس، عمليات آلية AA الثلاثة متشابهة، وكلها هي مرحلة التحقق ← آلية رسوم المناولة (المدفوعة عن طريق عقد الحساب أو صراف الرواتب) ← مرحلة التنفيذ. الاختلافات الرئيسية هي:
مقارنة
بالإضافة إلى ذلك، لقد أكملنا مجمع ذاكرة P2P لمجمع 4337 الحالي، كما أن مُسلسل ومشغل zkRollups هما أيضًا الخوادم الرسمية الوحيدة، لذلك هناك مكونات مركزية معينة.
في عملية التطوير، نظرًا لأن zkSync لا يواجه مشكلة الاتصال بمختلف المجمعات (يحتاج فقط إلى التفاعل مع واجهة برمجة تطبيقات المشغل)، فمن السهل استخدام 4337، كما أن تجربة تطوير عقود الحساب (SDK) أفضل أيضًا؛ في في الوقت نفسه، يمكن لـ zkSync استخدام Solidity كلغة تطوير تعاقدية، لذلك ليست هناك حاجة لعبور عتبة القاهرة في تطوير StarkNet.
خاتمة
نظرًا لأن كلاً من StarkNet وzkSync ينتميان إلى فئة AA المحلية (AA الأصلية)، يمكنك أيضًا الرجوع إلى مقدمتي السابقة لـ StarkNet AA، بعنوان "مقدمة لتجريد حساب StarkNet" (مقدمة لتجريد حساب StarkNet). يمكنك أيضًا قراءة مقالات أخرى متعلقة بـ EIP-4337 لمزيد من المعلومات.