व्यवहार

व्यवहार हे खात्यांकडून आलेल्या क्रिप्टोग्राफिकदृष्ट्या स्वाक्षरी केलेल्या सूचना आहेत. इथेरियम नेटवर्कची स्थिती अद्यतनित करण्यासाठी खाते व्यवहार सुरू करेल. एका खात्यातून दुसऱ्या खात्यात ETH चे हस्तांतरण करणे हा सर्वात सोपा व्यवहार आहे.

पूर्वतयारी

हे पृष्ठ अधिक चांगल्या प्रकारे समजून घेण्यासाठी, आम्ही शिफारस करतो की तुम्ही प्रथम खाती आणि आमची इथेरियमची ओळख वाचा.

व्यवहार म्हणजे काय?

इथेरियम व्यवहार म्हणजे बाह्य मालकीच्या खात्याद्वारे सुरू केलेली कृती, दुसऱ्या शब्दांत सांगायचे तर, कॉन्ट्रॅक्टद्वारे नव्हे तर मानवाद्वारे व्यवस्थापित केलेले खाते. उदाहरणार्थ, जर बॉबने ॲलिसला 1 ETH पाठवले, तर बॉबच्या खात्यातून ते वजा झाले पाहिजेत आणि ॲलिसच्या खात्यात जमा झाले पाहिजेत. ही स्थिती बदलणारी कृती एका व्यवहारामध्ये घडते.

इथेरियम EVM इलस्ट्रेटेड (नवीन टॅबमध्ये उघडते) वरून रूपांतरित केलेली आकृती

EVM ची स्थिती बदलणाऱ्या व्यवहारांना संपूर्ण नेटवर्कवर प्रसारित करणे आवश्यक आहे. कोणताही नोड EVM वर व्यवहार कार्यान्वित करण्यासाठी विनंती प्रसारित करू शकतो; हे घडल्यानंतर, एक प्रमाणक व्यवहार कार्यान्वित करेल आणि परिणामी स्थितीतील बदल उर्वरित नेटवर्कवर प्रसारित करेल.

व्यवहारांसाठी शुल्क आवश्यक असते आणि ते प्रमाणित ब्लॉकमध्ये समाविष्ट केले जाणे आवश्यक आहे. हा आढावा सोपा करण्यासाठी आम्ही गॅस शुल्क आणि प्रमाणीकरण इतरत्र कव्हर करू.

सबमिट केलेल्या व्यवहारामध्ये खालील माहिती समाविष्ट असते:

from – प्रेषकाचा पत्ता, जो व्यवहारावर स्वाक्षरी करेल. हे बाह्य मालकीचे खाते असेल कारण कॉन्ट्रॅक्ट खाती व्यवहार पाठवू शकत नाहीत
to – प्राप्तकर्ता पत्ता (जर बाह्य मालकीचे खाते असेल, तर व्यवहार मूल्य हस्तांतरित करेल. जर कॉन्ट्रॅक्ट खाते असेल, तर व्यवहार कॉन्ट्रॅक्ट कोड कार्यान्वित करेल)
signature – प्रेषकाचा ओळखकर्ता. जेव्हा प्रेषकाची खाजगी की व्यवहारावर स्वाक्षरी करते आणि प्रेषकाने या व्यवहारास अधिकृत केले आहे याची पुष्टी करते तेव्हा हे तयार केले जाते
nonce - एक क्रमाने वाढणारा काउंटर जो खात्यातून व्यवहाराचा क्रमांक दर्शवतो
value – प्रेषकाकडून प्राप्तकर्त्याकडे हस्तांतरित करायची ETH ची रक्कम (Wei मध्ये दर्शविलेली, जिथे 1ETH म्हणजे 1e+18wei)
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 सारखा इथेरियम क्लायंट ही स्वाक्षरी करण्याची प्रक्रिया हाताळेल.

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

{
  "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 मध्ये लिहिलेले असतात आणि त्यांच्या डेटा फील्डचा अर्थ नुसार लावतात.

पहिले चार बाइट्स फंक्शनचे नाव आणि आर्ग्युमेंट्सच्या हॅशचा वापर करून कोणते फंक्शन कॉल करायचे हे निर्दिष्ट करतात. तुम्ही कधीकधी या डेटाबेसचा (नवीन टॅबमध्ये उघडते) वापर करून सिलेक्टरवरून फंक्शन ओळखू शकता.

उर्वरित कॉल डेटा हे आर्ग्युमेंट्स आहेत, जे ABI स्पेसिफिकेशन्समध्ये निर्दिष्ट केल्याप्रमाणे एन्कोड केलेले (नवीन टॅबमध्ये उघडते) आहेत.

उदाहरणार्थ, हा व्यवहार (नवीन टॅबमध्ये उघडते) पाहूया. कॉल डेटा पाहण्यासाठी Click to see More वापरा.

फंक्शन सिलेक्टर 0xa9059cbb आहे. या स्वाक्षरीसह अनेक ज्ञात फंक्शन्स (नवीन टॅबमध्ये उघडते) आहेत. या प्रकरणात कॉन्ट्रॅक्ट सोर्स कोड (नवीन टॅबमध्ये उघडते) Etherscan वर अपलोड केला गेला आहे, त्यामुळे आम्हाला माहित आहे की फंक्शन transfer(address,uint256) आहे.

उर्वरित डेटा असा आहे:

0000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279
000000000000000000000000000000000000000000000000000000003b0559f4

ABI स्पेसिफिकेशन्स नुसार, पूर्णांक मूल्ये (जसे की पत्ते, जे 20-बाइट पूर्णांक आहेत) ABI मध्ये 32-बाइट शब्द म्हणून दिसतात, ज्यांच्या समोर शून्ये जोडलेली असतात. त्यामुळे आम्हाला माहित आहे की to पत्ता 4f6742badb049791cd9a37ea913f2bac38d01279 (नवीन टॅबमध्ये उघडते) आहे. value हे 0x3b0559f4 = 990206452 आहे.

व्यवहार डिस्क्रिप्टर्स

डेटा फील्डमध्ये अपारदर्शक हेक्साडेसिमल बाइट्स असल्यामुळे, व्यवहार प्रत्यक्षात कोणती कृती करेल हे सत्यापित करणे अत्यंत कठीण असू शकते. ही "ब्लाइंड सायनिंग" असुरक्षा क्लिअर सायनिंग (नवीन टॅबमध्ये उघडते) द्वारे व्यवहार डिस्क्रिप्टर्स (नवीन टॅबमध्ये उघडते) (ERC-7730 द्वारे परिभाषित) च्या वापराद्वारे हाताळली जाते.

ERC-7730 स्पेसिफिकेशन ABI आणि संरचित संदेशांमध्ये आढळणारा डेटा समृद्ध करण्यासाठी व्यवहार डिस्क्रिप्टर्स (बहुतेकदा JSON फाइल्स म्हणून संरचित) वापरते, जसे की EVM व्यवहार कॉल डेटा, EIP-712 संदेश आणि EIP-4337 युजर ऑपरेशन्स. डेव्हलपर्स या डिस्क्रिप्टर्सचा वापर विशिष्ट व्यवहार व्हेरिएबल्स थेट फॉरमॅटिंग टेम्पलेट्समध्ये मॅप करण्यासाठी करतात, ज्यामुळे अंतर्निहित डेटा ॲप्लिकेशन्ससाठी मशीन-वाचनीय राहील याची खात्री होते.

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

व्यवहारांचे प्रकार

इथेरियमवर काही वेगवेगळ्या प्रकारचे व्यवहार आहेत:

नियमित व्यवहार: एका खात्यातून दुसऱ्या खात्यात होणारा व्यवहार.
कॉन्ट्रॅक्ट प्रस्थापना व्यवहार: 'to' पत्ता नसलेला व्यवहार, जिथे डेटा फील्ड कॉन्ट्रॅक्ट कोडसाठी वापरले जाते.
कॉन्ट्रॅक्टची अंमलबजावणी: प्रस्थापित स्मार्ट कॉन्ट्रॅक्टशी संवाद साधणारा व्यवहार. या प्रकरणात, 'to' पत्ता हा स्मार्ट कॉन्ट्रॅक्टचा पत्ता असतो.

गॅस बद्दल

नमूद केल्याप्रमाणे, व्यवहार कार्यान्वित करण्यासाठी गॅस खर्च होतो. साध्या हस्तांतरण व्यवहारांसाठी 21000 युनिट्स गॅस आवश्यक असतो.

त्यामुळे बॉबला ॲलिसला 190 gwei च्या baseFeePerGas आणि 10 gwei च्या maxPriorityFeePerGas वर 1 ETH पाठवण्यासाठी, बॉबला खालील शुल्क भरावे लागेल:

(190 + 10) * 21000 = 4,200,000 gwei
--or--
0.0042 ETH

बॉबच्या खात्यातून -1.0042 ETH वजा केले जातील (ॲलिससाठी 1 ETH + गॅस शुल्कामध्ये 0.0042 ETH)

ॲलिसच्या खात्यात +1.0 ETH जमा केले जातील

पायाभूत शुल्क बर्न केले जाईल -0.00399 ETH

प्रमाणक टिप ठेवतो +0.000210 ETH

इथेरियम EVM इलस्ट्रेटेड (नवीन टॅबमध्ये उघडते) वरून रूपांतरित केलेली आकृती

व्यवहारामध्ये न वापरलेला कोणताही गॅस वापरकर्ता खात्यात परत केला जातो.

स्मार्ट कॉन्ट्रॅक्ट संवाद

स्मार्ट कॉन्ट्रॅक्टचा समावेश असलेल्या कोणत्याही व्यवहारासाठी गॅस आवश्यक असतो.

स्मार्ट कॉन्ट्रॅक्ट्समध्ये view (नवीन टॅबमध्ये उघडते) किंवा pure (नवीन टॅबमध्ये उघडते) फंक्शन्स म्हणून ओळखली जाणारी फंक्शन्स देखील असू शकतात, जी कॉन्ट्रॅक्टची स्थिती बदलत नाहीत. त्यामुळे, EOA मधून या फंक्शन्सना कॉल करण्यासाठी कोणत्याही गॅसची आवश्यकता नसते. या परिस्थितीसाठी अंतर्निहित RPC कॉल eth_call आहे.

eth_call वापरून ॲक्सेस केल्यावर विपरीत, ही view किंवा pure फंक्शन्स सामान्यतः अंतर्गतपणे (म्हणजेच, स्वतः कॉन्ट्रॅक्टमधून किंवा दुसऱ्या कॉन्ट्रॅक्टमधून) कॉल केली जातात ज्यासाठी गॅस खर्च होतो.

व्यवहार जीवनचक्र

एकदा व्यवहार सबमिट झाल्यानंतर खालील गोष्टी घडतात:

व्यवहार हॅश क्रिप्टोग्राफिकदृष्ट्या तयार केला जातो: 0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017
त्यानंतर व्यवहार नेटवर्कवर प्रसारित केला जातो आणि इतर सर्व प्रलंबित नेटवर्क व्यवहारांचा समावेश असलेल्या व्यवहार पूलमध्ये जोडला जातो.
व्यवहार सत्यापित करण्यासाठी आणि तो "यशस्वी" मानण्यासाठी प्रमाणकाने तुमचा व्यवहार निवडला पाहिजे आणि तो ब्लॉकमध्ये समाविष्ट केला पाहिजे.
जसजसा वेळ जाईल तसतसा तुमचा व्यवहार असलेला ब्लॉक "प्रमाणित" आणि नंतर "अंतिम झालेले" मध्ये अपग्रेड केला जाईल. हे अपग्रेड्स तुमचा व्यवहार यशस्वी झाला आणि तो कधीही बदलला जाणार नाही याची अधिक खात्री देतात. एकदा ब्लॉक "अंतिम झालेले" झाल्यावर तो केवळ नेटवर्क स्तरावरील हल्ल्याद्वारेच बदलला जाऊ शकतो ज्यासाठी अब्जावधी डॉलर्स खर्च येतील.

एक दृश्य डेमो

ऑस्टिन तुम्हाला व्यवहार, गॅस आणि खनन याबद्दल माहिती देत असताना पहा.

Transactions — ETH.BUILD

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

ट्रान्सक्रिप्टसह पहा

टाइप्ड ट्रान्झॅक्शन एन्व्हलप

इथेरियममध्ये मूळतः व्यवहारांसाठी एकच स्वरूप होते. प्रत्येक व्यवहारामध्ये नॉन्स, गॅसची किंमत, गॅस मर्यादा, प्राप्तकर्ता पत्ता, मूल्य, डेटा, v, r आणि s समाविष्ट होते. हे फील्ड्स RLP-एन्कोड केलेले आहेत, जे काहीसे असे दिसतात:

RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])

लेगसी व्यवहार स्वरूपांवर परिणाम न करता ॲक्सेस लिस्ट्स आणि EIP-1559 (नवीन टॅबमध्ये उघडते) सारख्या नवीन वैशिष्ट्यांची अंमलबजावणी करण्यासाठी एकाधिक प्रकारच्या व्यवहारांना समर्थन देण्यासाठी इथेरियम विकसित झाले आहे.

EIP-2718 (नवीन टॅबमध्ये उघडते) हे या वर्तनास अनुमती देते. व्यवहारांचा अर्थ असा लावला जातो:

TransactionType || TransactionPayload

जिथे फील्ड्स खालीलप्रमाणे परिभाषित केले आहेत:

TransactionType - 0 आणि 0x7f मधील एक संख्या, एकूण 128 संभाव्य व्यवहार प्रकारांसाठी.
TransactionPayload - व्यवहार प्रकाराद्वारे परिभाषित केलेला एक अनियंत्रित बाइट ॲरे.

TransactionType मूल्यावर आधारित, व्यवहाराचे खालीलप्रमाणे वर्गीकरण केले जाऊ शकते:

प्रकार 0 (लेगसी) व्यवहार: इथेरियमच्या लाँचपासून वापरले जाणारे मूळ व्यवहार स्वरूप. त्यामध्ये EIP-1559 (नवीन टॅबमध्ये उघडते) मधील वैशिष्ट्ये समाविष्ट नाहीत जसे की डायनॅमिक गॅस शुल्क गणना किंवा स्मार्ट कॉन्ट्रॅक्ट्ससाठी ॲक्सेस लिस्ट्स. लेगसी व्यवहारांमध्ये त्यांच्या सीरियलाइज्ड स्वरूपात त्यांचा प्रकार दर्शविणारा विशिष्ट उपसर्ग नसतो, रिकर्सिव्ह लेंथ प्रिफिक्स (RLP) एन्कोडिंग वापरताना 0xf8 बाइटने सुरुवात होते. या व्यवहारांसाठी TransactionType मूल्य 0x0 आहे.
प्रकार 1 व्यवहार: इथेरियमच्या बर्लिन अपग्रेड चा भाग म्हणून EIP-2930 (नवीन टॅबमध्ये उघडते) मध्ये सादर केलेल्या, या व्यवहारांमध्ये accessList पॅरामीटर समाविष्ट आहे. ही सूची व्यवहार ज्या पत्ते आणि स्टोरेज कीजमध्ये प्रवेश करण्याची अपेक्षा करतो ते निर्दिष्ट करते, ज्यामुळे स्मार्ट कॉन्ट्रॅक्ट्सचा समावेश असलेल्या जटिल व्यवहारांसाठी गॅस खर्च संभाव्यतः कमी होण्यास मदत होते. EIP-1559 शुल्क बाजारातील बदल प्रकार 1 व्यवहारांमध्ये समाविष्ट नाहीत. प्रकार 1 व्यवहारांमध्ये yParity पॅरामीटर देखील समाविष्ट असतो, जो 0x0 किंवा 0x1 असू शकतो, जो secp256k1 स्वाक्षरीच्या y-मूल्याची समानता दर्शवतो. ते 0x01 बाइटने सुरू होऊन ओळखले जातात आणि त्यांचे TransactionType मूल्य 0x1 आहे.
प्रकार 2 व्यवहार, ज्यांना सामान्यतः EIP-1559 व्यवहार म्हणून संबोधले जाते, ते इथेरियमच्या लंडन अपग्रेड मध्ये EIP-1559 (नवीन टॅबमध्ये उघडते) मध्ये सादर केलेले व्यवहार आहेत. ते इथेरियम नेटवर्कवरील मानक व्यवहार प्रकार बनले आहेत. हे व्यवहार एक नवीन शुल्क बाजार यंत्रणा सादर करतात जी व्यवहार शुल्काची पायाभूत शुल्क आणि प्राधान्य शुल्कामध्ये विभागणी करून अंदाजक्षमता सुधारते. ते 0x02 बाइटने सुरू होतात आणि त्यामध्ये maxPriorityFeePerGas आणि maxFeePerGas सारख्या फील्ड्सचा समावेश असतो. प्रकार 2 व्यवहार आता त्यांच्या लवचिकता आणि कार्यक्षमतेमुळे डीफॉल्ट आहेत, विशेषतः उच्च नेटवर्क गर्दीच्या काळात वापरकर्त्यांना व्यवहार शुल्क अधिक अंदाजे व्यवस्थापित करण्यात मदत करण्याच्या त्यांच्या क्षमतेसाठी पसंती दिली जाते. या व्यवहारांसाठी TransactionType मूल्य 0x2 आहे.
प्रकार 3 (ब्लॉब) व्यवहार इथेरियमच्या डेंकुन अपग्रेड चा भाग म्हणून EIP-4844 (नवीन टॅबमध्ये उघडते) मध्ये सादर केले गेले. हे व्यवहार "ब्लॉब" डेटा (बायनरी लार्ज ऑब्जेक्ट्स) अधिक कार्यक्षमतेने हाताळण्यासाठी डिझाइन केलेले आहेत, विशेषतः इथेरियम नेटवर्कवर कमी खर्चात डेटा पोस्ट करण्याचा मार्ग प्रदान करून स्तर 2 (l2) रोलअप्सना फायदा होतो. ब्लॉब व्यवहारांमध्ये blobVersionedHashes, maxFeePerBlobGas, आणि blobGasPrice सारख्या अतिरिक्त फील्ड्सचा समावेश असतो. ते 0x03 बाइटने सुरू होतात आणि त्यांचे TransactionType मूल्य 0x3 आहे. ब्लॉब व्यवहार इथेरियमच्या डेटा उपलब्धता आणि स्केलिंग क्षमतांमध्ये लक्षणीय सुधारणा दर्शवतात.
प्रकार 4 व्यवहार इथेरियमच्या पेक्ट्रा अपग्रेड चा भाग म्हणून EIP-7702 (नवीन टॅबमध्ये उघडते) मध्ये सादर केले गेले. हे व्यवहार खाते अमूर्तीकरणाशी फॉरवर्ड-कम्पॅटिबल होण्यासाठी डिझाइन केलेले आहेत. ते EOA ला त्यांच्या मूळ कार्यक्षमतेशी तडजोड न करता तात्पुरते स्मार्ट कॉन्ट्रॅक्ट खात्यांसारखे वागण्याची परवानगी देतात. त्यामध्ये authorization_list पॅरामीटर समाविष्ट आहे, जो EOA आपला अधिकार ज्या स्मार्ट कॉन्ट्रॅक्टला सोपवतो तो निर्दिष्ट करतो. व्यवहारानंतर, EOA च्या कोड फील्डमध्ये सोपवलेल्या स्मार्ट कॉन्ट्रॅक्टचा पत्ता असेल.

पुढील वाचन

EIP-2718: टाइप्ड ट्रान्झॅक्शन एन्व्हलप (नवीन टॅबमध्ये उघडते)

तुम्हाला मदत केलेल्या एखाद्या समुदाय संसाधनाबद्दल माहिती आहे का? हे पृष्ठ संपादित करा आणि ते जोडा!