المعاملات

المعاملات هي تعليمات من الحسابات موقعة بشكل مشفّر. أبسط معاملة هي نقل ETH من حساب إلى آخر.

المتطلبات الأساسية

لمساعدتك في فهم هذه الصفحة بشكل أفضل، نوصيك أولاً بقراءة الحسابات ومقدمة إلى إيثريوم.

ما هي المعاملة؟

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

رسم بياني مقتبس من إيثريوم EVM illustrated (opens in a new tab)

يجب بث المعاملات التي تؤدي إلى تغيير حالة EVM إلى الشبكة بأكملها. يمكن لأي عقدة بث طلب لتنفيذ معاملة على EVM؛ بعد حدوث ذلك، سيقوم المحقق بتنفيذ المعاملة ونشر تغيير الحالة الناتج إلى بقية الشبكة.

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

تتضمن المعاملة المقدمة المعلومات التالية:

from – عنوان المرسل، الذي سيوقع المعاملة. This will be an externally-owned account as contract accounts cannot send transactions
to – عنوان المستلم (إذا كان حسابًا مملوكًا خارجيًا، فستقوم المعاملة بتحويل القيمة. إذا كان حساب عقد، سيتم تنفيذ المعاملة بواسطة رمز العقد)
signature – معرّف المرسل. يتم إنشاء ذلك عندما يوقع المفتاح الخاص للمرسل على المعاملة ويؤكد أن المرسل قد سمح بهذه المعاملة
nonce - عداد يزداد بشكل تسلسلي ويشير إلى رقم المعاملة من الحساب
value – كمية الإيثريوم (ETH) المراد تحويلها من المرسل إلى المستلم (مُقوَّمة بعملة WEI، حيث 1ETH يساوي 1e+18wei)
input data – حقل اختياري لتضمين بيانات عشوائية
gasLimit – الحد الأقصى لوحدات الغاز التي يمكن أن تستهلكها المعاملة. تحدد آلة الإيثريوم الافتراضية (EVM) وحدات الغاز المطلوبة لكل خطوة حسابية
maxPriorityFeePerGas - الحد الأقصى لسعر الغاز المستهلك ليتم تضمينه كإكرامية للمدقق
maxFeePerGas - الحد الأقصى للرسوم لكل وحدة غاز المدفوعة مقابل المعاملة (بما في ذلك baseFeePerGas وmaxPriorityFeePerGas)

الغاز هو إشارة إلى الحساب المطلوب لمعالجة المعاملة بواسطة المحقق. يتعين على المستخدمين دفع رسوم مقابل هذا الحساب. يحدد gasLimit و maxPriorityFeePerGas الحد الأقصى لرسوم المعاملة المدفوعة للمدقق. المزيد عن الغاز.

سيبدو كائن المعاملة قليلاً مثل هذا:

1{
2  from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
3  to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
4  gasLimit: "21000",
5  maxFeePerGas: "300",
6  maxPriorityFeePerGas: "10",
7  nonce: "0",
8  value: "10000000000"
9}
إظهار الكل

ولكن يجب توقيع كائن المعاملة باستخدام المفتاح الخاص للمرسل. وهذا يثبت أن المعاملة لا يمكن أن تأتي إلا من المرسل ولم يتم إرسالها بطريقة احتيالية.

سيتولى عميل إيثريوم مثل غيث عملية التوقيع هذه.

مثال على استدعاء JSON-RPC:

1{
2  "id": 2,
3  "jsonrpc": "2.0",
4  "method": "account_signTransaction",
5  "params": [
6    {
7      "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
8      "gas": "0x55555",
9      "maxFeePerGas": "0x1234",
10      "maxPriorityFeePerGas": "0x1234",
11      "input": "0xabcd",
12      "nonce": "0x0",
13      "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
14      "value": "0x1234"
15    }
16  ]
17}
إظهار الكل

مثال على الاستجابة:

1{
2  "jsonrpc": "2.0",
3  "id": 2,
4  "result": {
5    "raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
6    "tx": {
7      "nonce": "0x0",
8      "maxFeePerGas": "0x1234",
9      "maxPriorityFeePerGas": "0x1234",
10      "gas": "0x55555",
11      "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
12      "value": "0x1234",
13      "input": "0xabcd",
14      "v": "0x26",
15      "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e",
16      "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
17      "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e"
18    }
19  }
20}
إظهار الكل

raw هي المعاملة الموقعة بصيغة بادئة الطول المتكرر (RLP) المشفرة
tx هي المعاملة الموقعة بصيغة JSON

باستخدام تجزئة التوقيع، يمكن إثبات المعاملة تشفيريًا على أنها جاءت من المرسل وتم إرسالها إلى الشبكة.

حقل البيانات

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

تحدد البايتات الأربعة الأولى الوظيفة التي سيتم استدعاؤها، باستخدام تجزئة اسم الوظيفة والحجج. يمكنك أحيانًا تحديد الوظيفة من المحدد باستخدام قاعدة البيانات هذه (opens in a new tab).

بقية بيانات الاستدعاء هي الوسائط، المشفرة كما هو محدد في مواصفات واجهة التطبيق الثنائية (ABI) (opens in a new tab).

على سبيل المثال، دعنا نلقي نظرة على هذه المعاملة (opens in a new tab). استخدم انقر لرؤية المزيد لرؤية بيانات الاستدعاء.

محدد الوظيفة هو 0xa9059cbb. هناك العديد من الوظائف المعروفة بهذا التوقيع (opens in a new tab). في هذه الحالة، تم تحميل النص البرمجي المصدري للعقد (opens in a new tab) إلى إيثرسكان، لذلك نحن نعلم أن الوظيفة هي transfer(address,uint256).

أما بقية البيانات فهي:

10000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279
2000000000000000000000000000000000000000000000000000000003b0559f4

وفقًا لمواصفات ABI، تظهر القيم الصحيحة (مثل العناوين، والتي هي أعداد صحيحة مكونة من 20 بايتًا) في ABI ككلمات مكونة من 32 بايتًا، مبطنة بأصفار في المقدمة. لذا، فنحن نعلم أن عنوان to هو 4f6742badb049791cd9a37ea913f2bac38d01279 (opens in a new tab). قيمة value هي 0x3b0559f4 = 990206452.

أنواع المعاملات

يوجد على إيثريوم أنواع مختلفة من المعاملات:

المعاملات العادية: معاملة من حساب إلى آخر.
معاملات نشر العقد: معاملة بدون عنوان "إلى"، حيث يتم استخدام حقل البيانات لكود العقد.
تنفيذ العقد: معاملة تتفاعل مع عقد ذكي تم نشره. في هذه الحالة، عنوان "إلى" هو عنوان العقد الذكي.

عن الغاز

كما ذكرنا، تستهلك المعاملات الغاز لتنفيذها. تتطلب معاملات النقل البسيطة 21000 وحدة غاز.

لذلك، لكي يرسل Bob إلى Alice عملة ETH واحدة بسعر baseFeePerGas يبلغ 190 gwei وmaxPriorityFeePerGas يبلغ 10 gwei، سيحتاج Bob إلى دفع الرسوم التالية:

1(١٩٠ + ١٠) * ٢١٠٠٠ = ٤,٢٠٠,٠٠٠ وي --أو-- ٠.٠٠٤٢ إيثريوم

سيتم خصم -1.0042 ETH من حساب Bob (1 ETH لـ Alice + 0.0042 ETH رسوم الغاز)

سيضاف إلى حساب Alice مبلغ +1.0 ETH

سيتم حرق الرسوم الأساسية -0.00399 ETH

يحتفظ المدقق بالإكرامية +0.000210 ETH

رسم بياني مقتبس من إيثريوم EVM illustrated (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
يتم بعد ذلك بث المعاملة إلى الشبكة وإضافتها إلى مجموعة المعاملات المكونة من جميع معاملات الشبكة المعلقة الأخرى.
يجب على المحقق أن يختار معاملتك ويدرجها في كتلة حتى يتمكن من التحقق من المعاملة واعتبارها "ناجحة".
مع مرور الوقت، سيتم ترقية الكتلة التي تحتوي على معاملتك إلى "مبررة" ثم "نهائية". هذه الترقيات تجعل من المؤكد أن معاملتك كانت ناجحة ولن يتم تغييرها أبدًا. بمجرد "إنهاء" الكتلة، لا يمكن تغييرها إلا عن طريق هجوم على مستوى الشبكة سيكلف مليارات الدولارات.

عرض مرئي

شاهد أوستن وهو يشرح لك المعاملات والغاز والتعدين.

غلاف المعاملات المكتوبة

كان لدى الإيثريوم في الأصل تنسيق واحد للمعاملات. تحتوي كل معاملة على رقم عشوائي، وسعر الغاز، وحد الغاز، والعنوان، والقيمة، والبيانات، و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 (Blob) تم تقديمها في EIP-4844 (opens in a new tab) كجزء من تطوير دينكون لـ إيثريوم. تم تصميم هذه المعاملات للتعامل مع بيانات "blob" (الكائنات الثنائية الكبيرة) بكفاءة أكبر، مما يفيد بشكل خاص عمليات التجميع في الطبقة 2 من خلال توفير طريقة لنشر البيانات على شبكة إيثريوم بتكلفة أقل. تتضمن معاملات Blob حقولًا إضافية مثل blobVersionedHashes و maxFeePerBlobGas و blobGasPrice. تبدأ بالبايت 0x03، وقيمة TransactionType الخاصة بها هي 0x3. تمثل معاملات Blob تحسنًا كبيرًا في توفر بيانات إيثريوم وقدرات التوسع.
معاملات النوع 4 تم تقديمها في EIP-7702 (opens in a new tab) كجزء من تطوير بيكترا لـ إيثريوم. صُممت هذه المعاملات لتكون متوافقة مع تجريد الحسابات مستقبلاً. إنها تسمح لحسابات EOA بالتصرف مؤقتًا مثل حسابات العقود الذكية دون المساس بوظائفها الأصلية. تتضمن معلمة authorization_list، التي تحدد العقد الذكي الذي يفوض حساب EOA سلطته إليه. بعد المعاملة، سيحتوي حقل النص البرمجي الخاص بـ EOA على عنوان العقد الذكي المفوض.

قراءة إضافية

EIP-2718: غلاف المعاملات المكتوبة (opens in a new tab)

هل تعرف أحد الموارد المجتمعية التي ساعدتك؟ عدّل هذه الصفحة وأضفه!