मुख्य सामग्री पर जाएं
Change page

लेन-देन

लेन-देन खातों से क्रिप्टोग्राफ़िक रूप से हस्ताक्षर किए गए निर्देश हैं। एक खाता इथेरियम नेटवर्क की स्थिति को अपडेट करने के लिए एक लेन-देन शुरू करेगा। सबसे सरल लेन-देन एक खाते से दूसरे खाते में ETH ट्रांसफर करना है।

पूर्वापेक्षाएँ

इस पृष्ठ को बेहतर ढंग से समझने में आपकी मदद करने के लिए, हम अनुशंसा करते हैं कि आप पहले खाते और हमारा इथेरियम का परिचय पढ़ें।

लेन-देन क्या है?

एक इथेरियम लेन-देन बाहरी रूप से स्वामित्व वाले खाते द्वारा शुरू की गई कार्रवाई को संदर्भित करता है, दूसरे शब्दों में एक खाता जो किसी इंसान द्वारा प्रबंधित किया जाता है, न कि किसी अनुबंध द्वारा। उदाहरण के लिए, यदि बॉब ऐलिस को 1 ETH भेजता है, तो बॉब के खाते से डेबिट किया जाना चाहिए और ऐलिस के खाते में क्रेडिट किया जाना चाहिए। स्थिति बदलने वाली यह कार्रवाई एक लेन-देन के भीतर होती है।

Diagram showing a transaction cause state change आरेख इथेरियम EVM इलस्ट्रेटेड (opens in a new tab) से अनुकूलित

लेन-देन, जो EVM की स्थिति को बदलते हैं, उन्हें पूरे नेटवर्क में प्रसारित करने की आवश्यकता होती है। कोई भी नोड EVM पर निष्पादित होने वाले लेन-देन के लिए अनुरोध प्रसारित कर सकता है; ऐसा होने के बाद, एक सत्यापक लेन-देन को निष्पादित करेगा और परिणामी स्थिति परिवर्तन को बाकी नेटवर्क में प्रसारित करेगा।

लेन-देन के लिए शुल्क की आवश्यकता होती है और इसे एक मान्य ब्लॉक में शामिल किया जाना चाहिए। इस अवलोकन को सरल बनाने के लिए हम गैस शुल्क और सत्यापन को कहीं और कवर करेंगे।

सबमिट किए गए लेन-देन में निम्नलिखित जानकारी शामिल होती है:

  • from – प्रेषक का पता, जो लेन-देन पर हस्ताक्षर करेगा। यह बाहरी रूप से स्वामित्व वाला खाता होगा क्योंकि कॉन्ट्रैक्ट खाते लेन-देन नहीं भेज सकते हैं
  • to – प्राप्तकर्ता का पता (यदि बाहरी रूप से स्वामित्व वाला खाता है, तो लेन-देन मूल्य ट्रांसफर करेगा। यदि कॉन्ट्रैक्ट खाता है, तो लेन-देन अनुबंध कोड निष्पादित करेगा)
  • signature – प्रेषक का पहचानकर्ता। यह तब उत्पन्न होता है जब प्रेषक की निजी कुंजी लेन-देन पर हस्ताक्षर करती है और पुष्टि करती है कि प्रेषक ने इस लेन-देन को अधिकृत किया है
  • nonce - एक क्रमिक रूप से बढ़ने वाला काउंटर जो खाते से लेन-देन संख्या को इंगित करता है
  • value – प्रेषक से प्राप्तकर्ता को ट्रांसफर की जाने वाली ETH की मात्रा (Wei में मूल्यवर्गित, जहां 1ETH 1e+18wei के बराबर है)
  • input data – मनमाना डेटा शामिल करने के लिए वैकल्पिक फ़ील्ड
  • gasLimit – गैस इकाइयों की अधिकतम मात्रा जिसका उपभोग लेन-देन द्वारा किया जा सकता है। EVM प्रत्येक कम्प्यूटेशनल चरण के लिए आवश्यक गैस की इकाइयों को निर्दिष्ट करता है
  • maxPriorityFeePerGas - सत्यापक को टिप के रूप में शामिल की जाने वाली उपभोग की गई गैस का अधिकतम मूल्य
  • maxFeePerGas - लेन-देन के लिए भुगतान की जाने वाली गैस की प्रति इकाई अधिकतम शुल्क (baseFeePerGas और maxPriorityFeePerGas सहित)

गैस एक सत्यापक द्वारा लेन-देन को संसाधित करने के लिए आवश्यक गणना का संदर्भ है। उपयोगकर्ताओं को इस गणना के लिए शुल्क का भुगतान करना पड़ता है। gasLimit, और maxPriorityFeePerGas सत्यापक को भुगतान किए गए अधिकतम लेन-देन शुल्क का निर्धारण करते हैं। गैस पर अधिक जानकारी

लेन-देन ऑब्जेक्ट कुछ इस तरह दिखेगा:

लेकिन एक लेन-देन ऑब्जेक्ट को प्रेषक की निजी कुंजी का उपयोग करके हस्ताक्षर करने की आवश्यकता होती है। यह साबित करता है कि लेन-देन केवल प्रेषक से ही आ सकता था और इसे धोखाधड़ी से नहीं भेजा गया था।

Geth जैसा इथेरियम क्लाइंट इस हस्ताक्षर करने की प्रक्रिया को संभालेगा।

उदाहरण जेसन-आरपीसी कॉल:

उदाहरण प्रतिक्रिया:

हस्ताक्षर हैश के साथ, लेन-देन को क्रिप्टोग्राफ़िक रूप से साबित किया जा सकता है कि यह प्रेषक से आया है और नेटवर्क में सबमिट किया गया है।

डेटा फ़ील्ड

अधिकांश लेन-देन बाहरी रूप से स्वामित्व वाले खाते से एक अनुबंध तक पहुंचते हैं। अधिकांश अनुबंध 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-बाइट पूर्णांक हैं) ABI में 32-बाइट शब्दों के रूप में दिखाई देते हैं, जिनके सामने शून्य (zeros) पैड किए गए होते हैं। इसलिए हम जानते हैं कि to पता 4f6742badb049791cd9a37ea913f2bac38d01279 (opens in a new tab) है। value 0x3b0559f4 = 990206452 है।

लेन-देन डिस्क्रिप्टर

चूंकि डेटा फ़ील्ड में अपारदर्शी हेक्साडेसिमल बाइट्स होते हैं, इसलिए यह सत्यापित करना बेहद मुश्किल हो सकता है कि लेन-देन वास्तव में क्या कार्रवाई करेगा। इस "ब्लाइंड साइनिंग" भेद्यता को लेन-देन डिस्क्रिप्टर (opens in a new tab) (ERC-7730 द्वारा परिभाषित) के उपयोग के माध्यम से क्लियर साइनिंग (opens in a new tab) द्वारा संबोधित किया जाता है।

ERC-7730 विनिर्देश ABI और संरचित संदेशों, जैसे EVM लेन-देन कॉल डेटा, EIP-712 संदेशों और EIP-4337 उपयोगकर्ता संचालन (User Operations) में पाए जाने वाले डेटा को समृद्ध करने के लिए लेन-देन डिस्क्रिप्टर (अक्सर JSON फ़ाइलों के रूप में संरचित) का उपयोग करता है। डेवलपर्स इन डिस्क्रिप्टर का उपयोग विशिष्ट लेन-देन चर को सीधे फ़ॉर्मेटिंग टेम्प्लेट में मैप करने के लिए करते हैं, यह सुनिश्चित करते हुए कि अंतर्निहित डेटा एप्लिकेशन के लिए मशीन-पठनीय बना रहे।

फ्रंटएंड पर, वॉलेट इस फ़ॉर्मेटिंग संदर्भ का उपयोग अपारदर्शी बाइटकोड को स्पष्ट, मानव-पठनीय जानकारी में अनुवाद करने के लिए करते हैं। टोकन पते जैसे मानों को मान्यता प्राप्त टिकर में, या मात्रा को दशमलव में स्वचालित रूप से हल करके, उपयोगकर्ताओं को हस्ताक्षर करने से पहले लेन-देन के सटीक आशय का एक सरल-भाषा सारांश (उदा., 'कम से कम 0.25 WETH के लिए 1000 USDC स्वैप करें') प्रस्तुत किया जाता है।

लेन-देन के प्रकार

इथेरियम पर कुछ अलग प्रकार के लेन-देन होते हैं:

  • नियमित लेन-देन: एक खाते से दूसरे खाते में लेन-देन।
  • अनुबंध तैनाती लेन-देन: 'to' पते के बिना एक लेन-देन, जहां डेटा फ़ील्ड का उपयोग अनुबंध कोड के लिए किया जाता है।
  • अनुबंध का निष्पादन: एक लेन-देन जो तैनात स्मार्ट अनुबंध के साथ इंटरैक्ट करता है। इस मामले में, 'to' पता स्मार्ट अनुबंध का पता है।

गैस पर

जैसा कि उल्लेख किया गया है, लेन-देन को निष्पादित करने में गैस खर्च होती है। सरल ट्रांसफर लेन-देन के लिए गैस की 21000 इकाइयों की आवश्यकता होती है।

इसलिए बॉब को 190 gwei के baseFeePerGas और 10 gwei के maxPriorityFeePerGas पर ऐलिस को 1 ETH भेजने के लिए, बॉब को निम्नलिखित शुल्क का भुगतान करना होगा:

(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

Diagram showing how unused gas is refunded आरेख इथेरियम 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 फ़ंक्शंस को आमतौर पर आंतरिक रूप से (यानी, अनुबंध से ही या किसी अन्य अनुबंध से) भी कॉल किया जाता है, जिसमें गैस खर्च होती है।

लेन-देन जीवनचक्र

एक बार लेन-देन सबमिट हो जाने के बाद निम्नलिखित होता है:

  1. एक लेनदेन हैश क्रिप्टोग्राफ़िक रूप से उत्पन्न होता है: 0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017
  2. लेन-देन को फिर नेटवर्क पर प्रसारित किया जाता है और अन्य सभी लंबित नेटवर्क लेन-देन वाले लेन-देन पूल में जोड़ा जाता है।
  3. लेन-देन को सत्यापित करने और इसे "सफल" मानने के लिए एक सत्यापक को आपके लेन-देन को चुनना होगा और इसे एक ब्लॉक में शामिल करना होगा।
  4. जैसे-जैसे समय बीतता है, आपके लेन-देन वाले ब्लॉक को "औचित्य-सिद्ध" और फिर "अंतिम रूप दिया गया" में अपग्रेड किया जाएगा। ये अपग्रेड इसे और अधिक निश्चित बनाते हैं कि आपका लेन-देन सफल रहा और इसे कभी नहीं बदला जाएगा। एक बार जब किसी ब्लॉक को "अंतिम रूप दिया गया" कर दिया जाता है, तो इसे केवल नेटवर्क स्तर के हमले से ही बदला जा सकता है जिसमें कई अरबों डॉलर खर्च होंगे।

एक दृश्य डेमो

ऑस्टिन को लेन-देन, गैस और खनन के बारे में बताते हुए देखें।

Transactions — ETH.BUILD

A demonstration of how Ethereum transactions work using the ETH.BUILD educational tool.

ट्रांसक्रिप्ट के साथ देखें 

टाइप्ड ट्रांजेक्शन एनवलप

इथेरियम में मूल रूप से लेन-देन के लिए एक प्रारूप था। प्रत्येक लेन-देन में एक नॉन्स, गैस मूल्य, गैस सीमा, प्राप्तकर्ता का पता (to address), मूल्य, डेटा, 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 मान के आधार पर, लेन-देन को इस प्रकार वर्गीकृत किया जा सकता है:

  1. टाइप 0 (लीगेसी) लेन-देन: इथेरियम के लॉन्च के बाद से उपयोग किया जाने वाला मूल लेन-देन प्रारूप। इनमें EIP-1559 (opens in a new tab) की विशेषताएं शामिल नहीं हैं जैसे कि गतिशील गैस शुल्क गणना या स्मार्ट अनुबंधों के लिए एक्सेस सूचियां। लीगेसी लेन-देन में उनके क्रमबद्ध रूप में उनके प्रकार को इंगित करने वाले एक विशिष्ट उपसर्ग का अभाव होता है, जो रिकर्सिव लेंथ प्रीफिक्स (RLP) एन्कोडिंग का उपयोग करते समय बाइट 0xf8 से शुरू होता है। इन लेन-देन के लिए TransactionType मान 0x0 है।

  2. टाइप 1 लेन-देन: इथेरियम के बर्लिन अपग्रेड के हिस्से के रूप में EIP-2930 (opens in a new tab) में पेश किए गए, इन लेन-देन में एक accessList पैरामीटर शामिल है। यह सूची उन पतों और स्टोरेज कुंजियों को निर्दिष्ट करती है जिन तक लेन-देन पहुंचने की अपेक्षा करता है, जिससे स्मार्ट अनुबंधों से जुड़े जटिल लेन-देन के लिए संभावित रूप से गैस लागत को कम करने में मदद मिलती है। EIP-1559 शुल्क बाज़ार परिवर्तन टाइप 1 लेन-देन में शामिल नहीं हैं। टाइप 1 लेन-देन में एक yParity पैरामीटर भी शामिल होता है, जो या तो 0x0 या 0x1 हो सकता है, जो secp256k1 हस्ताक्षर के y-मान की समता (parity) को दर्शाता है। उन्हें बाइट 0x01 से शुरू करके पहचाना जाता है, और उनका TransactionType मान 0x1 है।

  3. टाइप 2 लेन-देन, जिन्हें आमतौर पर EIP-1559 लेन-देन कहा जाता है, इथेरियम के लंदन अपग्रेड में EIP-1559 (opens in a new tab) में पेश किए गए लेन-देन हैं। वे इथेरियम नेटवर्क पर मानक लेन-देन प्रकार बन गए हैं। ये लेन-देन एक नया शुल्क बाज़ार तंत्र पेश करते हैं जो लेन-देन शुल्क को आधार शुल्क और प्राथमिकता शुल्क में अलग करके पूर्वानुमान में सुधार करता है। वे बाइट 0x02 से शुरू होते हैं और इनमें maxPriorityFeePerGas और maxFeePerGas जैसे फ़ील्ड शामिल होते हैं। टाइप 2 लेन-देन अब उनके लचीलेपन और दक्षता के कारण डिफ़ॉल्ट हैं, विशेष रूप से उच्च नेटवर्क भीड़भाड़ की अवधि के दौरान उपयोगकर्ताओं को लेन-देन शुल्क को अधिक अनुमानित रूप से प्रबंधित करने में मदद करने की उनकी क्षमता के लिए पसंद किए जाते हैं। इन लेन-देन के लिए TransactionType मान 0x2 है।

  4. टाइप 3 (ब्लॉब) लेन-देन इथेरियम के डेंकन अपग्रेड के हिस्से के रूप में EIP-4844 (opens in a new tab) में पेश किए गए थे। इन लेन-देन को "ब्लॉब" डेटा (बाइनरी लार्ज ऑब्जेक्ट्स) को अधिक कुशलता से संभालने के लिए डिज़ाइन किया गया है, विशेष रूप से कम लागत पर इथेरियम नेटवर्क पर डेटा पोस्ट करने का एक तरीका प्रदान करके लेयर 2 (l2) रोलअप्स को लाभान्वित करते हैं। ब्लॉब लेन-देन में blobVersionedHashes, maxFeePerBlobGas, और blobGasPrice जैसे अतिरिक्त फ़ील्ड शामिल हैं। वे बाइट 0x03 से शुरू होते हैं, और उनका TransactionType मान 0x3 है। ब्लॉब लेन-देन इथेरियम की डेटा उपलब्धता और स्केलिंग क्षमताओं में एक महत्वपूर्ण सुधार का प्रतिनिधित्व करते हैं।

  5. टाइप 4 लेन-देन इथेरियम के पेक्ट्रा अपग्रेड के हिस्से के रूप में EIP-7702 (opens in a new tab) में पेश किए गए थे। इन लेन-देन को खाता अमूर्तन के साथ आगे-संगत (forward-compatible) होने के लिए डिज़ाइन किया गया है। वे EOA को उनकी मूल कार्यक्षमता से समझौता किए बिना अस्थायी रूप से स्मार्ट अनुबंध खातों की तरह व्यवहार करने की अनुमति देते हैं। उनमें एक authorization_list पैरामीटर शामिल है, जो उस स्मार्ट अनुबंध को निर्दिष्ट करता है जिसे EOA अपना अधिकार सौंपता है। लेन-देन के बाद, EOA के कोड फ़ील्ड में प्रत्यायोजित स्मार्ट अनुबंध का पता होगा।

आगे की पढ़ाई

क्या आप किसी ऐसे सामुदायिक संसाधन के बारे में जानते हैं जिसने आपकी मदद की? इस पृष्ठ को संपादित करें और इसे जोड़ें!