المعاملات
المعاملات هي تعليمات موقعة تشفيريًا من الحسابات. سيبدأ الحساب معاملة لتحديث حالة شبكة إيثيريوم. أبسط معاملة هي تحويل ETH من حساب إلى آخر.
المتطلبات الأساسية
لمساعدتك على فهم هذه الصفحة بشكل أفضل، نوصيك بقراءة الحسابات ومقدمة إلى إيثيريوم أولاً.
ما هي المعاملة؟
تشير معاملة إيثيريوم إلى إجراء يبدأه حساب مملوك خارجيًا، بعبارة أخرى حساب يديره إنسان، وليس عقدًا. على سبيل المثال، إذا أرسل بوب إلى أليس 1 ETH، فيجب خصم المبلغ من حساب بوب وإضافته إلى حساب أليس. يحدث هذا الإجراء الذي يغير الحالة داخل معاملة.
مخطط مقتبس من توضيح آلة إيثيريوم الافتراضية (EVM) (opens in a new tab)
المعاملات، التي تغير حالة آلة إيثيريوم الافتراضية (EVM)، يجب بثها إلى الشبكة بأكملها. يمكن لأي عقدة بث طلب لتنفيذ معاملة على EVM؛ بعد حدوث ذلك، سيقوم مُدَقِّق بتنفيذ المعاملة ونشر تغيير الحالة الناتج إلى بقية الشبكة.
تتطلب المعاملات رسومًا ويجب تضمينها في كتلة تم التحقق من صحتها. لجعل هذه النظرة العامة أبسط، سنغطي رسوم الغاز والتحقق من الصحة في مكان آخر.
تتضمن المعاملة المقدمة المعلومات التالية:
from– عنوان المرسل، الذي سيقوم بتوقيع المعاملة. سيكون هذا حسابًا مملوكًا خارجيًا لأن حسابات العقود لا يمكنها إرسال معاملاتto– عنوان المستلم (إذا كان حسابًا مملوكًا خارجيًا، فستقوم المعاملة بتحويل القيمة. إذا كان حساب عقد، فستقوم المعاملة بتنفيذ كود العقد)signature– مُعرّف المرسل. يتم إنشاء هذا عندما يقوم المفتاح الخاص للمرسل بتوقيع المعاملة ويؤكد أن المرسل قد صرح بهذه المعاملةnonce- عداد يتزايد تسلسليًا يشير إلى رقم المعاملة من الحساب (رقم فريد)value– مقدار ETH المراد تحويله من المرسل إلى المستلم (مقوم بوحدة Wei، حيث يساوي 1 ETH 1e+18 wei)input data– حقل اختياري لتضمين بيانات عشوائيةgasLimit– الحد الأقصى لعدد وحدات الغاز التي يمكن أن تستهلكها المعاملة. تحدد آلة إيثيريوم الافتراضية (EVM) وحدات الغاز المطلوبة لكل خطوة حسابيةmaxPriorityFeePerGas- الحد الأقصى لسعر الغاز المستهلك ليتم تضمينه كإكرامية للمُدَقِّقmaxFeePerGas- الحد الأقصى للرسوم لكل وحدة غاز التي يكون المستخدم على استعداد لدفعها مقابل المعاملة (شاملةbaseFeePerGasوmaxPriorityFeePerGas)
الغاز هو إشارة إلى الحساب المطلوب لمعالجة المعاملة بواسطة مُدَقِّق. يجب على المستخدمين دفع رسوم مقابل هذا الحساب. يحدد gasLimit و maxPriorityFeePerGas الحد الأقصى لرسوم المعاملة المدفوعة للمُدَقِّق. المزيد عن الغاز.
سيبدو كائن المعاملة هكذا تقريبًا:
{
from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
gasLimit: "21000",
maxFeePerGas: "300",
maxPriorityFeePerGas: "10",
nonce: "0",
value: "10000000000"
}
لكن كائن المعاملة يحتاج إلى توقيع باستخدام المفتاح الخاص للمرسل. يثبت هذا أن المعاملة لا يمكن أن تأتي إلا من المرسل ولم يتم إرسالها بشكل احتيالي.
سيتعامل عميل إيثيريوم مثل جو إيثريوم (geth) مع عملية التوقيع هذه.
مثال على استدعاء JSON-RPC:
{
"id": 2,
"jsonrpc": "2.0",
"method": "account_signTransaction",
"params": [
{
"from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
"gas": "0x55555",
"maxFeePerGas": "0x1234",
"maxPriorityFeePerGas": "0x1234",
"input": "0xabcd",
"nonce": "0x0",
"to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
"value": "0x1234"
}
]
}
مثال على الاستجابة:
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
"tx": {
"nonce": "0x0",
"maxFeePerGas": "0x1234",
"maxPriorityFeePerGas": "0x1234",
"gas": "0x55555",
"to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
"value": "0x1234",
"input": "0xabcd",
"v": "0x26",
"r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e",
"s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
"hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e"
}
}
}
rawهي المعاملة الموقعة بصيغة مشفرة بـ بادئة الطول العودية (RLP)txهي المعاملة الموقعة بصيغة JSON
باستخدام تجزئة التوقيع، يمكن إثبات المعاملة تشفيريًا أنها جاءت من المرسل وتم تقديمها إلى الشبكة.
حقل البيانات
تصل الغالبية العظمى من المعاملات إلى عقد من حساب مملوك خارجيًا. تُكتب معظم العقود بلغة Solidity وتفسر حقل بياناتها وفقًا لـ .
تحدد البايتات الأربعة الأولى الوظيفة التي يجب استدعاؤها، باستخدام تجزئة اسم الوظيفة ووسائطها. يمكنك أحيانًا تحديد الوظيفة من المُحدِّد باستخدام قاعدة البيانات هذه (opens in a new tab).
بقية بيانات الاستدعاء هي الوسائط، مشفرة كما هو محدد في مواصفات ABI (opens in a new tab).
على سبيل المثال، دعنا نلقي نظرة على هذه المعاملة (opens in a new tab). استخدم انقر لرؤية المزيد (Click to see More) لرؤية بيانات الاستدعاء.
مُحدِّد الوظيفة هو 0xa9059cbb. هناك العديد من الوظائف المعروفة بهذا التوقيع (opens in a new tab).
في هذه الحالة، تم رفع الكود المصدري للعقد (opens in a new tab) إلى Etherscan، لذلك نعلم أن الوظيفة هي transfer(address,uint256).
بقية البيانات هي:
0000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279
000000000000000000000000000000000000000000000000000000003b0559f4
وفقًا لمواصفات ABI، تظهر القيم الصحيحة (مثل العناوين، وهي أعداد صحيحة بحجم 20-byte) في ABI ككلمات بحجم 32-byte، مبطنة بأصفار في المقدمة.
لذلك نعلم أن عنوان to هو 4f6742badb049791cd9a37ea913f2bac38d01279 (opens in a new tab).
قيمة value هي 0x3b0559f4 = 990206452.
واصفات المعاملة
نظرًا لأن حقل البيانات يحتوي على بايتات سداسية عشرية مبهمة، فقد يكون من الصعب للغاية التحقق من الإجراء الذي ستنفذه المعاملة فعليًا. تتم معالجة ثغرة "التوقيع الأعمى" هذه بواسطة التوقيع الواضح (opens in a new tab) من خلال استخدام واصفات المعاملة (opens in a new tab) (المحددة بواسطة ERC-7730).
تستخدم مواصفات ERC-7730 واصفات المعاملة (غالبًا ما تكون مهيكلة كملفات JSON) لإثراء البيانات الموجودة في ABIs والرسائل المهيكلة، مثل بيانات الاستدعاء لمعاملات EVM، ورسائل EIP-712، وعمليات المستخدم في EIP-4337. يستخدم المطورون هذه الواصفات لتعيين متغيرات معاملة محددة مباشرة في قوالب التنسيق، مما يضمن بقاء البيانات الأساسية قابلة للقراءة آليًا للتطبيقات.
في الواجهة الأمامية، تستخدم المحافظ سياق التنسيق هذا لترجمة رمز البايت المبهم إلى معلومات واضحة يمكن للبشر قراءتها. من خلال حل القيم تلقائيًا مثل عناوين الرموز المميزة إلى رموز مؤشرات معروفة، أو المبالغ إلى أرقام عشرية، يتم تقديم ملخص بلغة بسيطة للمستخدمين يوضح القصد الدقيق للمعاملة (على سبيل المثال، 'مبادلة 1000 USDC مقابل ما لا يقل عن 0.25 WETH') قبل أن يقوموا بالتوقيع
أنواع المعاملات
يوجد على إيثيريوم بضعة أنواع مختلفة من المعاملات:
- المعاملات العادية: معاملة من حساب إلى آخر.
- معاملات نشر العقد: معاملة بدون عنوان 'إلى' (to)، حيث يتم استخدام حقل البيانات لكود العقد.
- تنفيذ عقد: معاملة تتفاعل مع عقد ذكي تم نشره. في هذه الحالة، عنوان 'إلى' (to) هو عنوان العقد الذكي.
حول الغاز
كما ذكرنا، تكلف المعاملات غاز لتنفيذها. تتطلب معاملات التحويل البسيطة 21,000 وحدة من الغاز.
لذلك لكي يرسل بوب إلى أليس 1 ETH بـ baseFeePerGas يبلغ 190 Gwei و maxPriorityFeePerGas يبلغ 10 Gwei، سيحتاج بوب إلى دفع الرسوم التالية:
(190 + 10) * 21000 = 4,200,000 gwei
--أو--
0.0042 ETH
سيتم خصم -1.0042 ETH من حساب بوب (1 ETH لأليس + 0.0042 ETH كرسوم الغاز)
سيتم إضافة +1.0 ETH إلى حساب أليس
سيتم حرق الرسم الأساسي -0.00399 ETH
يحتفظ المُدَقِّق بالإكرامية +0.000210 ETH
مخطط مقتبس من توضيح آلة إيثيريوم الافتراضية (EVM) (opens in a new tab)
يتم استرداد أي غاز لم يُستخدم في المعاملة إلى حساب المستخدم.
تفاعلات العقد الذكي
الغاز مطلوب لأي معاملة تتضمن عقدًا ذكيًا.
يمكن أن تحتوي العقود الذكية أيضًا على وظائف تُعرف بوظائف view (opens in a new tab) أو pure (opens in a new tab)، والتي لا تغير حالة العقد. على هذا النحو، فإن استدعاء هذه الوظائف من حساب مملوك خارجيًا (EOA) لن يتطلب أي غاز. استدعاء RPC الأساسي لهذا السيناريو هو eth_call.
على عكس الوصول إليها باستخدام eth_call، يتم أيضًا استدعاء وظائف view أو pure هذه بشكل شائع داخليًا (أي من العقد نفسه أو من عقد آخر) مما يكلف غازًا.
دورة حياة المعاملة
بمجرد تقديم المعاملة، يحدث ما يلي:
- يتم إنشاء تجزئة المعاملة تشفيريًا:
0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017 - يتم بعد ذلك بث المعاملة إلى الشبكة وإضافتها إلى مجمع المعاملات الذي يتكون من جميع معاملات الشبكة المعلقة الأخرى.
- يجب أن يختار مُدَقِّق معاملتك ويضمنها في كتلة من أجل التحقق من المعاملة واعتبارها "ناجحة".
- بمرور الوقت، ستتم ترقية الكتلة التي تحتوي على معاملتك إلى "مبررة" ثم "نهائية". تجعل هذه الترقيات من المؤكد بشكل أكبر أن معاملتك كانت ناجحة ولن يتم تغييرها أبدًا. بمجرد أن تصبح الكتلة "نهائية"، لا يمكن تغييرها إلا من خلال هجوم على مستوى الشبكة سيكلف مليارات الدولارات.
عرض مرئي
شاهد أوستن وهو يرشدك عبر المعاملات، والغاز، والتعدين.
غلاف المعاملة محدد النوع
كان لدى إيثيريوم في الأصل تنسيق واحد للمعاملات. احتوت كل معاملة على رقم فريد، وسعر الغاز، وحد الغاز، وعنوان المستلم (to)، والقيمة، والبيانات، و v، و r، و s. هذه الحقول مشفرة بـ RLP، لتبدو هكذا تقريبًا:
RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])
تطورت إيثيريوم لدعم أنواع متعددة من المعاملات للسماح بتنفيذ ميزات جديدة مثل قوائم الوصول و EIP-1559 (opens in a new tab) دون التأثير على تنسيقات المعاملات القديمة.
EIP-2718 (opens in a new tab) هو ما يسمح بهذا السلوك. يتم تفسير المعاملات على النحو التالي:
TransactionType || TransactionPayload
حيث يتم تعريف الحقول على النحو التالي:
TransactionType- رقم بين 0 و 0x7f، لإجمالي 128 نوعًا ممكنًا من المعاملات.TransactionPayload- مصفوفة بايتات عشوائية يحددها نوع المعاملة.
بناءً على قيمة TransactionType، يمكن تصنيف المعاملة إلى:
-
معاملات النوع 0 (القديمة): تنسيق المعاملة الأصلي المستخدم منذ إطلاق إيثيريوم. لا تتضمن ميزات من EIP-1559 (opens in a new tab) مثل حسابات رسوم الغاز الديناميكية أو قوائم الوصول للعقود الذكية. تفتقر المعاملات القديمة إلى بادئة محددة تشير إلى نوعها في شكلها المتسلسل، وتبدأ بالبايت
0xf8عند استخدام تشفير بادئة الطول العودية (RLP). قيمة نوع المعاملة (TransactionType) لهذه المعاملات هي0x0. -
معاملات النوع 1: تم تقديمها في EIP-2930 (opens in a new tab) كجزء من ترقية برلين لإيثيريوم، وتتضمن هذه المعاملات معلمة
accessList. تحدد هذه القائمة العناوين ومفاتيح التخزين التي تتوقع المعاملة الوصول إليها، مما يساعد على تقليل تكاليف الغاز المحتملة للمعاملات المعقدة التي تتضمن عقودًا ذكية. لا يتم تضمين تغييرات سوق رسوم EIP-1559 في معاملات النوع 1. تتضمن معاملات النوع 1 أيضًا معلمةyParity، والتي يمكن أن تكون إما0x0أو0x1، مما يشير إلى تكافؤ قيمة y لتوقيع secp256k1. يتم التعرف عليها من خلال البدء بالبايت0x01، وقيمة نوع المعاملة (TransactionType) الخاصة بها هي0x1. -
معاملات النوع 2، والتي يشار إليها عادةً باسم معاملات EIP-1559، هي معاملات تم تقديمها في EIP-1559 (opens in a new tab)، في ترقية لندن لإيثيريوم. لقد أصبحت نوع المعاملة القياسي على شبكة إيثيريوم. تقدم هذه المعاملات آلية جديدة لسوق الرسوم تعمل على تحسين القدرة على التنبؤ من خلال فصل رسوم المعاملة إلى الرسم الأساسي ورسم الأولوية. تبدأ بالبايت
0x02وتتضمن حقولاً مثلmaxPriorityFeePerGasوmaxFeePerGas. أصبحت معاملات النوع 2 الآن هي الافتراضية نظرًا لمرونتها وكفاءتها، وهي مفضلة بشكل خاص خلال فترات ازدحام الشبكة العالي لقدرتها على مساعدة المستخدمين في إدارة رسوم المعاملات بشكل أكثر قابلية للتنبؤ. قيمة نوع المعاملة (TransactionType) لهذه المعاملات هي0x2. -
معاملات النوع 3 (كتلة بيانات) تم تقديمها في EIP-4844 (opens in a new tab) كجزء من ترقية دينكون لإيثيريوم. تم تصميم هذه المعاملات للتعامل مع بيانات "كتلة بيانات" (الكائنات الثنائية الكبيرة) بشكل أكثر كفاءة، مما يفيد بشكل خاص تجميعات طبقة 2 (L2) من خلال توفير طريقة لنشر البيانات على شبكة إيثيريوم بتكلفة أقل. تتضمن معاملات كتلة بيانات حقولاً إضافية مثل
blobVersionedHashes، وmaxFeePerBlobGas، وblobGasPrice. تبدأ بالبايت0x03، وقيمة نوع المعاملة (TransactionType) الخاصة بها هي0x3. تمثل معاملات كتلة بيانات تحسنًا كبيرًا في توفر بيانات إيثيريوم وقدرات التوسع. -
معاملات النوع 4 تم تقديمها في EIP-7702 (opens in a new tab) كجزء من ترقية بيكترا لإيثيريوم. تم تصميم هذه المعاملات لتكون متوافقة مع الإصدارات المستقبلية مع تجريد الحساب. إنها تسمح للحسابات المملوكة خارجيًا (EOAs) بالتصرف مؤقتًا مثل حسابات العقود الذكية دون المساس بوظائفها الأصلية. تتضمن معلمة
authorization_list، والتي تحدد العقد الذكي الذي يفوض إليه الحساب المملوك خارجيًا سلطته. بعد المعاملة، سيحتوي حقل كود الحساب المملوك خارجيًا على عنوان العقد الذكي المفوض.
قراءة إضافية
هل تعرف موردًا مجتمعيًا ساعدك؟ قم بتعديل هذه الصفحة وأضفه!