أجهزة التجميع (Bundlers) وعمليات المستخدم (UserOperations): كيف تعمل معاملات ERC-4337

عملية المستخدم (UserOperation) هي كائن النية الموقّع الذي يعرّفه ERC-4337: فهي تبيّن ما يريد حساب العقد الذكي إنجازه، وكيف ينبغي التحقق من ذلك الإجراء ودفع تكلفته. وخلافاً لمعاملة Ethereum العادية، ليست عملية المستخدم كائناً على مستوى البروتوكول يوقّعه حساب مملوك خارجياً: إذ يفحص عقد الحساب نفسه توقيعها، وهي ليست مضطرة لدفع غازها الأصلي بنفسها. أما جهاز التجميع (bundler) فهو الفاعل خارج السلسلة الذي يجمع عمليات المستخدم من ذاكرة انتظار بديلة مخصصة، ويحاكي كل واحدة منها، ويحزم الصالحة في معاملة Ethereum عادية واحدة، ويستدعي عقد EntryPoint القانوني — الذي يتحقق من كل عملية في الدُفعة قبل تنفيذ أي منها. ويقدّم جهاز التجميع الغاز الحقيقي سلفاً من حساب EOA الخاص به، ثم يُردّ إليه على السلسلة من الحساب المرسِل أو من جهاز الدفع (paymaster) التابع لذلك الحساب. ويمكن لعقد جهاز دفع اختياري أن يوافق على تغطية عملية ما أثناء خطوة التحقق تلك، وعند هذه النقطة تصبح الرسوم مرعيّة أو قابلة للدفع برمز ERC-20 بدلاً من رمز الغاز الأصلي للسلسلة.

مراجعة سريعة لـ ERC-4337

ERC-4337 هو معيار Ethereum لـ تجريد الحسابات — طريقة لمنح حسابات العقود الذكية القدرة من الدرجة الأولى نفسها على بدء الإجراءات ودفع تكاليفها التي طالما امتلكتها الحسابات المملوكة خارجياً (EOAs)، دون أي تغيير في البروتوكول الأساسي. فبدلاً من تعديل طبقة الإجماع، يُدخل ERC-4337 نظاماً موازياً من الكائنات عالية المستوى والبنية التحتية خارج السلسلة التي تُسوّى في نهاية المطاف عبر معاملات Ethereum عادية. وإن أردت النسخة من الأساس أولاً، فإن شرحنا حول ما هو تجريد الحسابات يغطي الدافع، وما هو ERC-4337 يرسم المعيار الكامل، والحسابات الذكية مقابل EOA يقارن نوعَي الحساب مباشرة. تركّز هذه المقالة على الآليات: الكائنات التي تتحرك عبر النظام والفاعلون الذين يعالجونها. لاحظ أن ERC-4337 معيار EVM — فهو ينطبق على Ethereum والسلاسل المتوافقة مع EVM، لا على السلاسل غير EVM مثل Solana أو TON.

ما هي عملية المستخدم (UserOperation) فعلاً

الكائن المركزي في ERC-4337 هو عملية المستخدم (UserOperation). تبدو ظاهرياً كمعاملة، لكن من الأفضل فهمها كبيان نية موقّع: "هذا ما يريد حسابي أن يُنجَز، وهذه هي وسائط التحقق منه ودفع تكلفته." وهي بنية (struct) تُمرَّر كبيانات استدعاء إلى عقد، لا كائناً أصلياً في البروتوكول — فالطبقة الأساسية لم تسمع بها قط.

وتحمل عملية المستخدم، في جوهرها، ما يلي:

• sender — حساب العقد الذكي الذي تعمل العملية نيابة عنه.
• nonce — حماية من إعادة الإرسال، يتتبعها EntryPoint كقيمة من جزأين (مفتاح مع تسلسل)، بحيث يمكن للحساب تشغيل عدة مسارات nonce مستقلة بدلاً من طابور واحد صارم.
• callData — ما ينبغي أن ينفّذه الحساب، وكثيراً ما يكون حزمة من عدة استدعاءات في عملية واحدة.
• بيانات نشر الحساب — اختيارية؛ تنشر عقد الحساب في أول عملية له على الإطلاق، وهكذا يمكن تمويل حساب ذكي على عنوان معروف مشتق حتمياً قبل وجوده على السلسلة.
• حدود الغاز — ميزانيتان منفصلتان للتحقق والتنفيذ، إضافة إلى قيمة preVerificationGas التي تعوّض جهاز التجميع عن بيانات الاستدعاء والأعباء التي لا يستطيع EntryPoint قياسها بنفسه.
• وسائط الرسوم — حد أقصى للرسم وحد أقصى لرسم الأولوية، على غرار EIP-1559.
• بيانات جهاز الدفع — اختيارية؛ أي عقد سيرعى العملية وأي سياق يحتاجه.
• التوقيع — تفحصه دالة التحقق الخاصة بالحساب نفسه، لا البروتوكول.

وقد تغيّر الترميز الدقيق بين إصدارات EntryPoint — فالإصدار v0.7 يفصل بيانات النشر وبيانات جهاز الدفع إلى حقول صريحة ويحزم عدة قيم غاز معاً، بينما استخدم v0.6 سلسلتَي بايتات واحدتين هما initCode وpaymasterAndData — لكن المحتوى المفاهيمي واحد. وإن كنت تعمل على التكامل، فتحقق من إصدار EntryPoint الذي يستهدفه جهاز التجميع لديك.

الفرق الجوهري عن المعاملة العادية هو مَن وماذا يوقّعها. فمعاملة Ethereum التقليدية يجب أن يوقّعها المفتاح الخاص لحساب EOA باستخدام مخطط ECDSA ثابت، ويدفع الحساب نفسه الغاز. أما عملية المستخدم فيتحقق منها منطق حساب العقد الذكي الخاص بالمرسِل — الذي يمكن أن ينفّذ أي مخطط توقيع أو قاعدة متعددة المفاتيح أو مفتاح جلسة أو سياسة تخويل يحددها الحساب — وليست مضطرة لدفع تكلفتها بالغاز الأصلي إطلاقاً. وتلك المرونة هي بيت القصيد: فالحساب، لا البروتوكول، هو من يقرر شكل الإجراء الصالح.

ذاكرة الانتظار البديلة التي تقيم فيها

لا تدخل عمليات المستخدم ذاكرة انتظار معاملات Ethereum العادية، لأنها ليست معاملات بعد. بل تُبَثّ إلى ذاكرة انتظار بديلة منفصلة (تُسمى غالباً alt-mempool) — شبكة نظير-إلى-نظير مخصصة لكائنات ERC-4337. وعملياً، تقدّم المحفظة أو التطبيق اللامركزي عملية بإجراء استدعاء eth_sendUserOperation على نقطة نهاية RPC لأحد أجهزة التجميع؛ وقد ينشر ذلك الجهاز العملية في ذاكرة الانتظار البديلة المشتركة، أو يبقيها في تجمّع خاص به. وفي الحالتين، تستمع البنية التحتية التي تستهلك هذه الكائنات هنا، لا على ذاكرة انتظار الطبقة الأساسية. ويُبقي هذا الفصل حركة تجريد الحسابات بعيدة عن المسار الحرج للإجماع حتى لحظة تغليفها في معاملة حقيقية.

دور جهاز التجميع (bundler)

جهاز التجميع (bundler) هو الفاعل خارج السلسلة الذي يحوّل النوايا إلى واقع على السلسلة. ولمهمته أربعة أجزاء. أولاً، يجمع عمليات المستخدم من ذاكرة الانتظار البديلة. ثانياً، يحاكي كل واحدة ويتحقق منها — بتشغيل منطق التحقق الخاص بالحساب في سياق محاكى لتأكيد صحة التوقيع وصحة nonce وقدرة الحساب أو جهاز الدفع التابع له على تغطية التكلفة. ثالثاً، يحزم عملية مستخدم صالحة واحدة أو أكثر في معاملة Ethereum عادية واحدة. رابعاً، يرسل تلك المعاملة إلى الشبكة من حساب EOA الخاص به، دافعاً غاز الطبقة الأساسية سلفاً ومتوقعاً أن يُردّ إليه على السلسلة.

والمحاكاة وحدها ليست حماية كافية، لأن الحالة قد تتغير بين المحاكاة والإدراج. لذلك يقيّد ERC-4337 أيضاً ما يُسمح لشيفرة التحقق بفعله: فخلال مرحلة التحقق، لا يجوز لحساب أو جهاز دفع أن يقرأ الطوابع الزمنية للكتل أو غيرها من قيم البيئة التي تتيح له التصرف على السلسلة بخلاف ما فعله في المحاكاة، ووصوله إلى التخزين محصور إلى حد بعيد في الخانات المرتبطة بحسابه هو. ويُتوقَّع من العقود التي تعمل نيابة عن مستخدمين كثر — لا سيما المصانع (factories) وأجهزة الدفع — أن ترهن حصة، حتى لا يستطيع عقد واحد سيئ السلوك أن يُبطل بثمن زهيد حصة كبيرة من ذاكرة الانتظار دفعة واحدة. وهذه القواعد موجودة لسبب واحد: جعل محاكاة جهاز التجميع تنبؤاً موثوقاً بما سيحدث على السلسلة.

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

عقد EntryPoint

يتلاقى كل شيء عند عقد ذكي واحد قانوني يُسمى EntryPoint. وهو عقد مفرد (singleton) يُنشر لكل إصدار على العنوان نفسه عبر سلاسل EVM، ويحتفظ بالودائع التي تُدفع منها تكاليف العمليات. فمعاملة جهاز التجميع هي استدعاء لـ EntryPoint مع مصفوفة من عمليات المستخدم، ثم يشغّل EntryPoint حلقة صارمة من مرحلتين.

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

هذا الفصل مهم: فيُفصل التحقق عن التنفيذ بحيث تُرسّخ ضمانات الدفع للدُفعة قبل تشغيل أي عمل يغيّر الحالة، وبحيث يستطيع EntryPoint احتساب الغاز بدقة عبر عمليات كثيرة دفعة واحدة. كما يعني ذلك أن فشل عملية واحدة أثناء التنفيذ لا يمكن أن يُفسد بقية عمليات الدُفعة.

أين يقع جهاز الدفع (paymaster)

جهاز الدفع (paymaster) عقد اختياري يوافق على الدفع مقابل عملية مستخدم نيابة عن الحساب. حين تتضمن عملية مستخدم بيانات جهاز دفع، يسأل EntryPoint ذلك الجهاز، أثناء مرحلة التحقق، عمّا إذا كان سيرعى العملية وبأي شروط؛ فيعيد جهاز الدفع قراره مع كتلة سياق. وبعد التنفيذ، يعاود EntryPoint استدعاء جهاز الدفع في خطوة لاحقة للعملية مع مقدار الغاز المستهلك فعلياً، وهنا يسوّي جهاز الدفع الذي يحصّل بالرموز المبلغ الدقيق. ويمكن لجهاز الدفع أن يقبل دون شروط (رعاية حقيقية بدون غاز، حيث يستوعب التطبيق التكلفة)، أو أن يقبل مقابل قيمة — والأكثر فائدة أن يحصّل من المستخدم بـ رمز ERC-20 بدلاً من الغاز الأصلي. وللاطلاع الأعمق على هذا المكوّن، انظر ما هو جهاز الدفع. جهاز الدفع هو المشبك في التدفق الذي يفصل "ما يدفع به المستخدم" عن "ما تُدفع به الشبكة".

كيف يُتعامل مع الغاز وحالات الفشل

الغاز في ERC-4337 مطبّق على طبقات. فجهاز التجميع يدفع ETH حقيقياً للمعاملة الخارجية؛ ويقيس EntryPoint غاز تحقق كل عملية مستخدم وتنفيذها مقابل الحدود التي أعلنتها؛ ومن يقع عليه الالتزام — الحساب أو جهاز الدفع الخاص به — يجب أن يكون قد أودع لدى EntryPoint ما يكفي لتغطية الفاتورة، التي تُسوّى في نهاية الدُفعة. وثمة نتيجة تستحق المعرفة: تكلّف عملية ERC-4337 غازاً أكثر قليلاً من المعاملة البسيطة المكافئة، لأنك تدفع مقابل التحقق على مستوى العقد ومسك دفاتر EntryPoint فوق الإجراء نفسه.

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

دورة الحياة، بالترتيب

1. تبني محفظتك عملية مستخدم: الحساب المرسِل، وnonce، وبيانات الاستدعاء، وحدود الغاز، ووسائط الرسوم، وبيانات جهاز دفع اختيارية.
2. يوافق جهاز الدفع، إن استُخدم، على شروط الرعاية قبل بثّ العملية.
3. يوقّعها منطق التوقيع الخاص بحسابك — وليس بالضرورة أن يكون مفتاح ECDSA واحداً.
4. تُرسل المحفظة العملية إلى نقطة نهاية RPC لجهاز تجميع، فتدخل ذاكرة الانتظار البديلة.
5. يحاكيها جهاز التجميع ويتحقق منها وفق قواعد المعيار الخاصة بالأوامر البرمجية المقيّدة والتخزين.
6. يحزمها جهاز التجميع مع عمليات أخرى في معاملة Ethereum واحدة تستدعي handleOps على EntryPoint، ويدفع غاز الطبقة الأساسية.
7. يتحقق EntryPoint من كل عملية، وينفّذ بيانات استدعاء كل منها، ويسوّي التكاليف مقابل الودائع، ويعيد الفائض، ويردّ لجهاز التجميع تكاليفه.

ماذا يجني مستخدم المحفظة من هذا

الآلية متشعبة، لكن الغاية منها بسيطة ونافعة: تجميع عدة إجراءات في تأكيد واحد (الموافقة والمبادلة معاً، مثلاً)، ورسوم مرعيّة أو مدفوعة برمز، ومخططات توقيع غير المفتاح الواحد من نوع secp256k1، وسياسات إنفاق ومفاتيح جلسة، واسترداد اجتماعي أو قائم على الجهاز. ويجدر بالذكر أن EIP-7702 يتيح لحساب EOA عادي أن ينفّذ مؤقتاً بشيفرة حساب ذكي، وهو ما يضيّق الفجوة في بعض هذه الميزات دون أن يستبدل بنية ERC-4337 التحتية الموصوفة أعلاه.

كيف تستخدم WATS هذا

على سلاسل EVM، تعتمد WATS على قطعة واحدة بالضبط من هذا التدفق: خانة جهاز الدفع (paymaster). حين تجري تحويلاً أو مبادلة أو رهناً في محفظة WATS الساخنة، تسمّي عملية المستخدم التي تبنيها محفظتك جهاز دفع، وذلك الجهاز هو ما يتيح احتساب الرسم بـ ATS بدلاً من رمز الغاز الأصلي للسلسلة — فلست بحاجة أبداً للاحتفاظ برصيد ضئيل من ETH أو BNB أو POL على كل شبكة لمجرد أن تتمكن من التحرك. ولا يُطلب منك تشغيل جهاز تجميع، ولا اختيار إصدار EntryPoint، ولا امتلاك مفتاح RPC لجهاز تجميع؛ فتلك بنية تحتية، ومهمة المحفظة هي بناء عملية مستخدم صالحة وإرسالها.

وهناك توضيحان يُبقيان الأمر أميناً. أولاً، الدفع بـ ATS ليس خصماً — فالشبكة لا تزال تتقاضى رسمها المعتاد ويسوّيه جهاز الدفع، فما يتغير هو الرمز الذي يغادر رصيدك، لا التكلفة الأساسية. ثانياً، ERC-4337 خاص بـ EVM فحسب، لذا يؤدي على Solana وTON ترتيبُ دافع رسوم معادل دورَ جهاز الدفع بدلاً من تدفق EntryPoint الموصوف هنا. وATS رمز OFT من LayerZero، وهذا ما يتيح لرصيد ATS واحد أن يغطي الرسوم عبر Ethereum وArbitrum وOptimism وBase وPolygon وBNB Chain وSolana وTON، ويُحرَق ATS المُحصَّل، فينزل المعروض من 100,000,000 إلى حدٍّ أدنى قدره 30,000,000. وتبقى WATS غير حافظة تماماً طوال ذلك: أنت تحمل مفاتيحك، وWATS لا تحمل أي مفتاح إطلاقاً.

وإن أردت أن ترى هذا التدفق كنظام يعمل لا كمواصفة مكتوبة، فالخطوة الملموسة هي تجربة تحويل في محفظة WATS الساخنة على سلسلة لا تملك فيها شيئاً من رمز الغاز الأصلي: تؤدي عملية المستخدم وجهاز التجميع وEntryPoint عملها بعيداً عن النظر، ويخرج الرسم من رصيدك بـ ATS. وتغطي مقالة كيف يعمل نموذج رسوم ATS الآليات من طرف إلى طرف.