From 4dd7f6f89c4b47e278626f2b0934ab5cdb0c1502 Mon Sep 17 00:00:00 2001
From: Joshua <62268199+minimalsm@users.noreply.github.com>
Date: Sat, 14 Feb 2026 00:13:42 +0000
Subject: [PATCH] i18n(mr): translation import part 09 of 13 (23 files)

---
 .../developers/tutorials/short-abi/index.md   |  585 +++++
 .../index.md                                  |   91 +
 .../tutorials/stealth-addr/index.md           |  436 ++++
 .../index.md                                  |  314 +++
 .../token-integration-checklist/index.md      |   86 +
 .../index.md                                  |  314 +++
 .../index.md                                  |  177 ++
 .../uniswap-v2-annotated-code/index.md        | 1898 +++++++++++++++++
 .../tutorials/using-websockets/index.md       |  245 +++
 .../index.md                                  |  300 +++
 .../index.md                                  |  204 ++
 .../index.md                                  |  199 ++
 .../tutorials/yellow-paper-evm/index.md       |  278 +++
 public/content/translations/mr/eips/index.md  |   78 +
 .../mr/energy-consumption/index.md            |   86 +
 .../translations/mr/eth/supply/index.md       |   80 +
 .../translations/mr/ethereum-forks/index.md   |  663 ++++++
 .../translations/mr/foundation/index.md       |   33 +
 .../content/translations/mr/gaming/index.md   |   70 +
 .../content/translations/mr/glossary/index.md |  505 +++++
 .../translations/mr/governance/index.md       |  184 ++
 .../index.md                                  |   75 +
 .../mr/guides/how-to-id-scam-tokens/index.md  |   94 +
 23 files changed, 6995 insertions(+)
 create mode 100644 public/content/translations/mr/developers/tutorials/short-abi/index.md
 create mode 100644 public/content/translations/mr/developers/tutorials/smart-contract-security-guidelines/index.md
 create mode 100644 public/content/translations/mr/developers/tutorials/stealth-addr/index.md
 create mode 100644 public/content/translations/mr/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
 create mode 100644 public/content/translations/mr/developers/tutorials/token-integration-checklist/index.md
 create mode 100644 public/content/translations/mr/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md
 create mode 100644 public/content/translations/mr/developers/tutorials/understand-the-erc-20-token-smart-contract/index.md
 create mode 100644 public/content/translations/mr/developers/tutorials/uniswap-v2-annotated-code/index.md
 create mode 100644 public/content/translations/mr/developers/tutorials/using-websockets/index.md
 create mode 100644 public/content/translations/mr/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
 create mode 100644 public/content/translations/mr/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
 create mode 100644 public/content/translations/mr/developers/tutorials/waffle-test-simple-smart-contract/index.md
 create mode 100644 public/content/translations/mr/developers/tutorials/yellow-paper-evm/index.md
 create mode 100644 public/content/translations/mr/eips/index.md
 create mode 100644 public/content/translations/mr/energy-consumption/index.md
 create mode 100644 public/content/translations/mr/eth/supply/index.md
 create mode 100644 public/content/translations/mr/ethereum-forks/index.md
 create mode 100644 public/content/translations/mr/foundation/index.md
 create mode 100644 public/content/translations/mr/gaming/index.md
 create mode 100644 public/content/translations/mr/glossary/index.md
 create mode 100644 public/content/translations/mr/governance/index.md
 create mode 100644 public/content/translations/mr/guides/how-to-create-an-ethereum-account/index.md
 create mode 100644 public/content/translations/mr/guides/how-to-id-scam-tokens/index.md

diff --git a/public/content/translations/mr/developers/tutorials/short-abi/index.md b/public/content/translations/mr/developers/tutorials/short-abi/index.md
new file mode 100644
index 00000000000..5c32c7c8482
--- /dev/null
+++ b/public/content/translations/mr/developers/tutorials/short-abi/index.md
@@ -0,0 +1,585 @@
+---
+title: "कॉलडेटा ऑप्टिमायझेशनसाठी लहान ABI"
+description: "ऑप्टिमिस्टिक रोलअपसाठी स्मार्ट कॉन्ट्रॅक्ट्स ऑप्टिमाइझ करणे"
+author: Ori Pomerantz
+lang: mr
+tags: [ "स्तर 2" ]
+skill: intermediate
+published: 2022-04-01
+---
+
+## प्रस्तावना {#introduction}
+
+या लेखात, आपण [optimistic rollups](/developers/docs/scaling/optimistic-rollups) बद्दल शिकाल, त्यावरील व्यवहारांची किंमत, आणि ती वेगळी किंमत संरचना Ethereum मेननेटपेक्षा आपल्याला वेगवेगळ्या गोष्टींसाठी ऑप्टिमाइझ करण्याची आवश्यकता कशी निर्माण करते.
+हे ऑप्टिमायझेशन कसे लागू करायचे हे देखील आपण शिकाल.
+
+### संपूर्ण प्रकटीकरण {#full-disclosure}
+
+मी एक पूर्णवेळ [Optimism](https://www.optimism.io/) कर्मचारी आहे, त्यामुळे या लेखातील उदाहरणे Optimism वर चालतील.
+तथापि, येथे स्पष्ट केलेले तंत्र इतर रोलअपसाठी देखील तितकेच चांगले कार्य करेल.
+
+### परिभाषा {#terminology}
+
+रोलअपवर चर्चा करताना, 'स्तर 1' (L1) ही संज्ञा मेननेटसाठी वापरली जाते, जे उत्पादन Ethereum नेटवर्क आहे.
+'स्तर 2' (L2) ही संज्ञा रोलअप किंवा इतर कोणत्याही प्रणालीसाठी वापरली जाते जी सुरक्षिततेसाठी L1 वर अवलंबून असते परंतु तिची बहुतेक प्रक्रिया ऑफचेन करते.
+
+## आपण L2 व्यवहारांची किंमत आणखी कशी कमी करू शकतो? {#how-can-we-further-reduce-the-cost-of-L2-transactions}
+
+[ऑप्टिमिस्टिक रोलअप्सना](/developers/docs/scaling/optimistic-rollups) प्रत्येक ऐतिहासिक व्यवहाराचा रेकॉर्ड जतन करावा लागतो जेणेकरून कोणीही त्यातून जाऊन सध्याची स्थिती योग्य आहे हे सत्यापित करू शकेल.
+Ethereum मेननेटमध्ये डेटा मिळवण्याचा सर्वात स्वस्त मार्ग म्हणजे तो कॅलडेटा म्हणून लिहिणे.
+हे समाधान [Optimism](https://help.optimism.io/hc/en-us/articles/4413163242779-What-is-a-rollup-) आणि [Arbitrum](https://developer.offchainlabs.com/docs/rollup_basics#intro-to-rollups) या दोघांनी निवडले होते.
+
+### L2 व्यवहारांची किंमत {#cost-of-l2-transactions}
+
+L2 व्यवहारांच्या किंमतीत दोन घटक असतात:
+
+1. L2 प्रक्रिया, जी सहसा अत्यंत स्वस्त असते
+2. L1 स्टोरेज, जे मेननेट गॅस खर्चाशी जोडलेले आहे
+
+मी हे लिहित असताना, Optimism वर L2 गॅसची किंमत 0.001 [Gwei](/developers/docs/gas/#pre-london) आहे.
+दुसरीकडे, L1 गॅसची किंमत अंदाजे 40 gwei आहे.
+[आपण सध्याच्या किमती येथे पाहू शकता](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m).
+
+कॅलडेटाच्या एका बाइटला एकतर 4 गॅस (जर तो शून्य असेल तर) किंवा 16 गॅस (जर ते इतर कोणतेही मूल्य असेल तर) लागतात.
+EVM वरील सर्वात महागड्या क्रियांपैकी एक म्हणजे स्टोरेजमध्ये लिहिणे.
+L2 वर स्टोरेजमध्ये 32-बाइट शब्द लिहिण्याची कमाल किंमत 22100 गॅस आहे. सध्या, हे 22.1 gwei आहे.
+म्हणून जर आपण कॅलडेटाचा एक शून्य बाइट वाचवू शकलो, तर आपण स्टोरेजमध्ये सुमारे 200 बाइट्स लिहू शकू आणि तरीही फायद्यात राहू.
+
+### ABI {#the-abi}
+
+बहुतेक व्यवहार बाह्य-मालकीच्या खात्यातून करारावर प्रवेश करतात.
+बहुतेक कॉन्ट्रॅक्ट्स Solidity मध्ये लिहिलेले आहेत आणि [ऍप्लिकेशन बायनरी इंटरफेस (ABI)](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding) नुसार त्यांचे डेटा फील्ड इंटरप्रिट करतात.
+
+तथापि, ABI हे L1 साठी डिझाइन केले होते, जिथे कॅलडेटाच्या एका बाइटची किंमत अंदाजे चार अंकगणितीय क्रियांइतकी असते, L2 साठी नाही, जिथे कॅलडेटाच्या एका बाइटची किंमत हजारहून अधिक अंकगणितीय क्रियांइतकी असते.
+कॅलडेटा खालीलप्रमाणे विभागलेला आहे:
+
+| विभाग           | लांबी | बाइट्स | वाया गेलेले बाइट्स | वाया गेलेला गॅस | आवश्यक बाइट्स | आवश्यक गॅस |
+| --------------- | ----: | -----: | -----------------: | --------------: | ------------: | ---------: |
+| फंक्शन सिलेक्टर |     4 |    0-3 |                  3 |              48 |             1 |         16 |
+| शून्य           |    12 |   4-15 |                 12 |              48 |             0 |          0 |
+| गंतव्य पत्ता    |    20 |  16-35 |                  0 |               0 |            20 |        320 |
+| रक्कम           |    32 |  36-67 |                 17 |              64 |            15 |        240 |
+| एकूण            |    68 |        |                    |             160 |               |        576 |
+
+स्पष्टीकरण:
+
+- **फंक्शन सिलेक्टर**: कॉन्ट्रॅक्टमध्ये 256 पेक्षा कमी फंक्शन्स आहेत, त्यामुळे आपण त्यांना एका बाइटने वेगळे करू शकतो.
+  हे बाइट्स सहसा गैर-शून्य असतात आणि त्यामुळे [सोळा गॅस खर्च येतो](https://eips.ethereum.org/EIPS/eip-2028).
+- **शून्य**: हे बाइट्स नेहमी शून्य असतात कारण वीस-बाइट पत्त्याला ठेवण्यासाठी बत्तीस-बाइट शब्दाची आवश्यकता नसते.
+  शून्य धारण करणार्‍या बाइट्सना चार गॅस खर्च येतो ([पिवळे पेपर पहा](https://ethereum.github.io/yellowpaper/paper.pdf), परिशिष्ट G,
+  पृ. 27, `G`<sub>`txdatazero`</sub> चे मूल्य).
+- **रक्कम**: जर आपण असे गृहीत धरले की या कॉन्ट्रॅक्टमध्ये `decimals` अठरा आहे (सामान्य मूल्य) आणि आपण हस्तांतरित करत असलेल्या टोकन्सची कमाल रक्कम 10<sup>18</sup> असेल, तर आपल्याला 10<sup>36</sup> ची कमाल रक्कम मिळते.
+  256<sup>15</sup> > 10<sup>36</sup>, म्हणून पंधरा बाइट्स पुरेसे आहेत.
+
+L1 वर 160 गॅसचा अपव्यय सहसा नगण्य असतो. एका व्यवहाराला किमान [21,000 गॅस](https://yakkomajuri.medium.com/blockchain-definition-of-the-week-ethereum-gas-2f976af774ed) खर्च येतो, त्यामुळे अतिरिक्त 0.8% ने काही फरक पडत नाही.
+तथापि, L2 वर, गोष्टी वेगळ्या आहेत. व्यवहाराचा जवळजवळ संपूर्ण खर्च तो L1 वर लिहिण्याचा असतो.
+व्यवहार कॅलडेटा व्यतिरिक्त, 109 बाइट्सचे व्यवहार हेडर (गंतव्य पत्ता, स्वाक्षरी, इ.) आहे.
+म्हणून एकूण खर्च `109*16+576+160=2480` आहे, आणि आपण त्यापैकी सुमारे 6.5% वाया घालवत आहोत.
+
+## जेव्हा आपण गंतव्यस्थानावर नियंत्रण ठेवत नाही तेव्हा खर्च कमी करणे {#reducing-costs-when-you-dont-control-the-destination}
+
+आपले गंतव्य कॉन्ट्रॅक्टवर नियंत्रण नाही असे गृहीत धरून, आपण तरीही [यासारखा](https://github.com/qbzzt/ethereum.org-20220330-shortABI) उपाय वापरू शकता.
+चला संबंधित फाइल्स पाहूया.
+
+### Token.sol {#token-sol}
+
+[हे गंतव्य कॉन्ट्रॅक्ट आहे](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/Token.sol).
+हे एक मानक ERC-20 कॉन्ट्रॅक्ट आहे, ज्यात एक अतिरिक्त वैशिष्ट्य आहे.
+हे `faucet` फंक्शन कोणत्याही वापरकर्त्याला वापरण्यासाठी काही टोकन मिळवू देते.
+हे एका उत्पादन ERC-20 कॉन्ट्रॅक्टला निरुपयोगी बनवेल, परंतु जेव्हा एखादे ERC-20 केवळ चाचणी सुलभ करण्यासाठी अस्तित्वात असते तेव्हा ते जीवन सोपे करते.
+
+```solidity
+    /**
+     * @dev कॉलरला खेळण्यासाठी 1000 टोकन देते
+     */
+    function faucet() external {
+        _mint(msg.sender, 1000);
+    }   // फंक्शन फॉसेट
+```
+
+### CalldataInterpreter.sol {#calldatainterpreter-sol}
+
+[हे ते कॉन्ट्रॅक्ट आहे ज्याला व्यवहारांनी लहान कॅलडेटासह कॉल करणे अपेक्षित आहे](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/CalldataInterpreter.sol).
+चला ओळीनुसार पाहूया.
+
+```solidity
+//SPDX-License-Identifier: Unlicense
+pragma solidity ^0.8.0;
+
+
+import { OrisUselessToken } from "./Token.sol";
+```
+
+त्याला कसे कॉल करायचे हे जाणून घेण्यासाठी आम्हाला टोकन फंक्शनची आवश्यकता आहे.
+
+```solidity
+contract CalldataInterpreter {
+
+    OrisUselessToken public immutable token;
+```
+
+ज्या टोकनसाठी आम्ही प्रॉक्सी आहोत त्याचा पत्ता.
+
+```solidity
+
+    /**
+     * @dev टोकनचा पत्ता निर्दिष्ट करा
+     * @param tokenAddr_ ERC-20 कॉन्ट्रॅक्टचा पत्ता
+     */
+    constructor(
+        address tokenAddr_
+    )  {
+        token = OrisUselessToken(tokenAddr_);
+    }   // कन्स्ट्रक्टर
+```
+
+आम्हाला निर्दिष्ट करण्याची आवश्यकता असलेला टोकन पत्ता हा एकमेव पॅरामीटर आहे.
+
+```solidity
+    function calldataVal(uint startByte, uint length)
+        private pure returns (uint) {
+```
+
+कॅलडेटा मधून मूल्य वाचा.
+
+```solidity
+        uint _retVal;
+
+        require(length < 0x21,
+            "calldataVal लांबीची मर्यादा 32 बाइट्स आहे");
+
+        require(length + startByte <= msg.data.length,
+            "calldataVal calldatasize च्या पलीकडे वाचण्याचा प्रयत्न करत आहे");
+```
+
+आपण मेमरीमध्ये एकच 32-बाइट (256-बिट) शब्द लोड करणार आहोत आणि जे बाइट्स आपल्याला हव्या असलेल्या फील्डचा भाग नाहीत ते काढून टाकणार आहोत.
+हे अल्गोरिदम 32 बाइटपेक्षा जास्त लांबीच्या मूल्यांसाठी कार्य करत नाही, आणि अर्थातच आपण कॅलडेटाच्या शेवटाच्या पुढे वाचू शकत नाही.
+L1 वर गॅस वाचवण्यासाठी या चाचण्या वगळणे आवश्यक असू शकते, परंतु L2 वर गॅस अत्यंत स्वस्त आहे, ज्यामुळे आपण विचार करू शकणाऱ्या कोणत्याही सॅनिटी तपासण्या शक्य होतात.
+
+```solidity
+        assembly {
+            _retVal := calldataload(startByte)
+        }
+```
+
+आपण `fallback()` (खाली पहा) च्या कॉलमधून डेटा कॉपी करू शकलो असतो, परंतु EVM ची असेंब्ली भाषा [Yul](https://docs.soliditylang.org/en/v0.8.12/yul.html) वापरणे सोपे आहे.
+
+येथे आपण स्टॅकमध्ये `startByte` ते `startByte+31` बाइट्स वाचण्यासाठी [CALLDATALOAD ऑपकोड](https://www.evm.codes/#35) वापरतो.
+सर्वसाधारणपणे, Yul मधील ऑपकोडचे सिंटॅक्स `<opcode name>(<first stack value, if any>,<second stack value, if any>...)` असे आहे.
+
+```solidity
+
+        _retVal = _retVal >> (256-length*8);
+```
+
+केवळ सर्वात लक्षणीय `length` बाइट्स फील्डचा भाग आहेत, म्हणून आपण इतर मूल्ये काढून टाकण्यासाठी [राइट-शिफ्ट](https://en.wikipedia.org/wiki/Logical_shift) करतो.
+याचा अतिरिक्त फायदा असा आहे की ते मूल्य फील्डच्या उजवीकडे हलवते, त्यामुळे ते मूल्य स्वतःच आहे, 256<sup>something</sup> पट मूल्य नाही.
+
+```solidity
+
+        return _retVal;
+    }
+
+
+    fallback() external {
+```
+
+जेव्हा Solidity कॉन्ट्रॅक्टला केलेला कॉल कोणत्याही फंक्शन सिग्नेचरशी जुळत नाही, तेव्हा ते (एक आहे असे गृहीत धरून) [`fallback()` फंक्शन](https://docs.soliditylang.org/en/v0.8.12/contracts.html#fallback-function) कॉल करते.
+`CalldataInterpreter` च्या बाबतीत, _कोणताही_ कॉल येथे येतो कारण इतर कोणतेही `external` किंवा `public` फंक्शन्स नाहीत.
+
+```solidity
+        uint _func;
+
+        _func = calldataVal(0, 1);
+```
+
+कॅलडेटाचा पहिला बाइट वाचा, जो आपल्याला फंक्शन सांगतो.
+येथे एखादे फंक्शन उपलब्ध नसण्याची दोन कारणे आहेत:
+
+1. `pure` किंवा `view` असणारी फंक्शन्स स्थिती बदलत नाहीत आणि त्यांना गॅस लागत नाही (जेव्हा ऑफचेन कॉल केले जाते).
+   त्यांचा गॅस खर्च कमी करण्याचा प्रयत्न करण्यात काही अर्थ नाही.
+2. [`msg.sender`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#block-and-transaction-properties) वर अवलंबून असलेली फंक्शन्स.
+   `msg.sender` चे मूल्य `CalldataInterpreter` चा पत्ता असेल, कॉलरचा नाही.
+
+दुर्दैवाने, [ERC-20 स्पेसिफिकेशन्स पाहिल्यास](https://eips.ethereum.org/EIPS/eip-20), फक्त एकच फंक्शन उरते, `transfer`.
+यामुळे आपल्याकडे फक्त दोन फंक्शन्स उरतात: `transfer` (कारण आपण `transferFrom` कॉल करू शकतो) आणि `faucet` (कारण आपण ज्याने आपल्याला कॉल केला आहे त्याला टोकन परत हस्तांतरित करू शकतो).
+
+```solidity
+
+        // कॅलडेटामधील माहिती वापरून टोकनच्या स्थिती बदलणाऱ्या पद्धतींना कॉल करा
+        // 
+
+        // फॉसेट
+        if (_func == 1) {
+```
+
+`faucet()` ला कॉल, ज्यामध्ये पॅरामीटर्स नाहीत.
+
+```solidity
+            token.faucet();
+            token.transfer(msg.sender,
+                token.balanceOf(address(this)));
+        }
+```
+
+आपण `token.faucet()` कॉल केल्यावर आपल्याला टोकन्स मिळतात. तथापि, प्रॉक्सी कॉन्ट्रॅक्ट म्हणून, आम्हाला टोकनची **गरज** नाही.
+आपल्याला कॉल करणार्‍या EOA (बाह्य मालकीच्या खात्याला) किंवा कॉन्ट्रॅक्टला गरज आहे.
+म्हणून आम्ही आमचे सर्व टोकन ज्याने आम्हाला कॉल केला आहे त्याला हस्तांतरित करतो.
+
+```solidity
+        // हस्तांतरण (आपल्याकडे त्यासाठी भत्ता आहे असे गृहीत धरा)
+        if (_func == 2) {
+```
+
+टोकन हस्तांतरित करण्यासाठी दोन पॅरामीटर्स आवश्यक आहेत: गंतव्य पत्ता आणि रक्कम.
+
+```solidity
+            token.transferFrom(
+                msg.sender,
+```
+
+आम्ही फक्त कॉल करणाऱ्यांना त्यांच्या मालकीचे टोकन हस्तांतरित करण्याची परवानगी देतो
+
+```solidity
+                address(uint160(calldataVal(1, 20))),
+```
+
+गंतव्य पत्ता बाइट #1 पासून सुरू होतो (बाइट #0 हे फंक्शन आहे).
+एक पत्ता म्हणून, तो 20-बाइट लांब आहे.
+
+```solidity
+                calldataVal(21, 2)
+```
+
+या विशिष्ट कॉन्ट्रॅक्टसाठी आपण असे गृहीत धरतो की कोणीही हस्तांतरित करू इच्छित असलेल्या टोकनची कमाल संख्या दोन बाइटमध्ये (65536 पेक्षा कमी) बसते.
+
+```solidity
+            );
+        }
+```
+
+एकंदरीत, हस्तांतरणासाठी 35 बाइट्सचा कॅलडेटा लागतो:
+
+| विभाग           | लांबी | बाइट्स |
+| --------------- | ----: | -----: |
+| फंक्शन सिलेक्टर |     1 |      0 |
+| गंतव्य पत्ता    |    32 |   1-32 |
+| रक्कम           |     2 |  33-34 |
+
+```solidity
+    }   // फॉलबॅक
+
+}       // कॉन्ट्रॅक्ट CalldataInterpreter
+```
+
+### test.js {#test-js}
+
+[हे JavaScript युनिट टेस्ट](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/test/test.js) आपल्याला हे तंत्र कसे वापरावे (आणि ते योग्यरित्या कार्य करते की नाही हे कसे सत्यापित करावे) हे दाखवते.
+मी असे गृहीत धरणार आहे की तुम्हाला [chai](https://www.chaijs.com/) आणि [ethers](https://docs.ethers.io/v5/) समजतात आणि केवळ कॉन्ट्रॅक्टवर विशेषतः लागू होणारे भाग स्पष्ट करणार आहे.
+
+```js
+const { expect } = require("chai");
+
+describe("CalldataInterpreter", function () {
+  it("Should let us use tokens", async function () {
+    const Token = await ethers.getContractFactory("OrisUselessToken")
+    const token = await Token.deploy()
+    await token.deployed()
+    console.log("Token addr:", token.address)
+
+    const Cdi = await ethers.getContractFactory("CalldataInterpreter")
+    const cdi = await Cdi.deploy(token.address)
+    await cdi.deployed()
+    console.log("CalldataInterpreter addr:", cdi.address)
+
+    const signer = await ethers.getSigner()
+```
+
+आपण दोन्ही कॉन्ट्रॅक्ट्स तैनात करून सुरुवात करतो.
+
+```javascript
+    // खेळण्यासाठी टोकन मिळवा
+    const faucetTx = {
+```
+
+आम्ही व्यवहार तयार करण्यासाठी सामान्यतः वापरत असलेली उच्च-स्तरीय फंक्शन्स (जसे की `token.faucet()`) वापरू शकत नाही, कारण आम्ही ABI चे पालन करत नाही.
+त्याऐवजी, आपल्याला स्वतः व्यवहार तयार करून तो पाठवावा लागेल.
+
+```javascript
+      to: cdi.address,
+      data: "0x01"
+```
+
+व्यवहारासाठी आपल्याला दोन पॅरामीटर्स द्यावे लागतील:
+
+1. `to`, गंतव्य पत्ता.
+   हा कॅलडेटा इंटरप्रिटर कॉन्ट्रॅक्ट आहे.
+2. `data`, पाठवण्यासाठी कॅलडेटा.
+   फॉसेट कॉलच्या बाबतीत, डेटा एकच बाइट आहे, `0x01`.
+
+```javascript
+
+    }
+    await (await signer.sendTransaction(faucetTx)).wait()
+```
+
+आम्ही [साईनरच्या `sendTransaction` पद्धतीला](https://docs.ethers.io/v5/api/signer/#Signer-sendTransaction) कॉल करतो कारण आम्ही आधीच गंतव्य (`faucetTx.to`) निर्दिष्ट केले आहे आणि आम्हाला व्यवहार स्वाक्षरी केलेला हवा आहे.
+
+```javascript
+// फॉसेट टोकन योग्यरित्या पुरवतो का ते तपासा
+expect(await token.balanceOf(signer.address)).to.equal(1000)
+```
+
+येथे आपण शिल्लक तपासतो.
+`view` फंक्शन्सवर गॅस वाचवण्याची गरज नाही, म्हणून आपण त्यांना सामान्यपणे चालवतो.
+
+```javascript
+// CDI ला भत्ता द्या (मंजुरी प्रॉक्सी केली जाऊ शकत नाही)
+const approveTX = await token.approve(cdi.address, 10000)
+await approveTX.wait()
+expect(await token.allowance(signer.address, cdi.address)).to.equal(10000)
+```
+
+हस्तांतरण करण्यासाठी कॅलडेटा इंटरप्रिटरला भत्ता द्या.
+
+```javascript
+// टोकन हस्तांतरित करा
+const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d"
+const transferTx = {
+  to: cdi.address,
+  data: "0x02" + destAddr.slice(2, 42) + "0100",
+}
+```
+
+एक हस्तांतरण व्यवहार तयार करा. पहिला बाइट "0x02" आहे, त्यानंतर गंतव्य पत्ता आणि शेवटी रक्कम (0x0100, जे दशांश मध्ये 256 आहे).
+
+```javascript
+    await (await signer.sendTransaction(transferTx)).wait()
+
+    // तपासा की आपल्याकडे 256 टोकन कमी आहेत
+    expect (await token.balanceOf(signer.address)).to.equal(1000-256)
+
+    // आणि ते आपल्या गंतव्यस्थानाला मिळाले आहेत
+    expect (await token.balanceOf(destAddr)).to.equal(256)
+  })    // ते
+})      // वर्णन करा
+```
+
+## जेव्हा तुम्ही गंतव्य कॉन्ट्रॅक्टवर नियंत्रण ठेवता तेव्हा खर्च कमी करणे {#reducing-the-cost-when-you-do-control-the-destination-contract}
+
+जर तुमचे गंतव्य कॉन्ट्रॅक्टवर नियंत्रण असेल तर तुम्ही अशी फंक्शन्स तयार करू शकता जी `msg.sender` तपासण्यांना बायपास करतात कारण ते कॅलडेटा इंटरप्रिटरवर विश्वास ठेवतात.
+[हे कसे कार्य करते याचे उदाहरण तुम्ही येथे पाहू शकता, `control-contract` शाखेत](https://github.com/qbzzt/ethereum.org-20220330-shortABI/tree/control-contract).
+
+जर कॉन्ट्रॅक्ट केवळ बाह्य व्यवहारांना प्रतिसाद देत असेल, तर आपण फक्त एका कॉन्ट्रॅक्टने काम चालवू शकलो असतो.
+तथापि, ते [कंपोझिबिलिटी](/developers/docs/smart-contracts/composability/) खंडित करेल.
+सामान्य ERC-20 कॉल्सला प्रतिसाद देणारा एक कॉन्ट्रॅक्ट आणि लहान कॉल डेटासह व्यवहारांना प्रतिसाद देणारा दुसरा कॉन्ट्रॅक्ट असणे खूप चांगले आहे.
+
+### Token.sol {#token-sol-2}
+
+या उदाहरणात आपण `Token.sol` मध्ये बदल करू शकतो.
+हे आपल्याला अनेक फंक्शन्स ठेवण्याची परवानगी देते जे फक्त प्रॉक्सी कॉल करू शकते.
+हे नवीन भाग आहेत:
+
+```solidity
+    // CalldataInterpreter पत्ता निर्दिष्ट करण्याची परवानगी असलेला एकमेव पत्ता
+    address owner;
+
+    // CalldataInterpreter पत्ता
+    address proxy = address(0);
+```
+
+ERC-20 कॉन्ट्रॅक्टला अधिकृत प्रॉक्सीची ओळख माहित असणे आवश्यक आहे.
+तथापि, आपण हे व्हेरिएबल कन्स्ट्रक्टरमध्ये सेट करू शकत नाही, कारण आपल्याला अद्याप मूल्य माहित नाही.
+हा कॉन्ट्रॅक्ट प्रथम इन्स्टंटिएट केला जातो कारण प्रॉक्सीला त्याच्या कन्स्ट्रक्टरमध्ये टोकनच्या पत्त्याची अपेक्षा असते.
+
+```solidity
+    /**
+     * @dev ERC20 कन्स्ट्रक्टरला कॉल करते.
+     */
+    constructor(
+    ) ERC20("Oris useless token-2", "OUT-2") {
+        owner = msg.sender;
+    }
+```
+
+निर्मात्याचा पत्ता (ज्याला `owner` म्हणतात) येथे संग्रहित केला जातो कारण प्रॉक्सी सेट करण्याची परवानगी असलेला तो एकमेव पत्ता आहे.
+
+```solidity
+    /**
+     * @dev प्रॉक्सीसाठी (CalldataInterpreter) पत्ता सेट करा.
+     * मालकाद्वारे फक्त एकदाच कॉल केले जाऊ शकते
+     */
+    function setProxy(address _proxy) external {
+        require(msg.sender == owner, "फक्त मालकाद्वारे कॉल केले जाऊ शकते");
+        require(proxy == address(0), "प्रॉक्सी आधीच सेट आहे");
+
+        proxy = _proxy;
+    }    // फंक्शन setProxy
+```
+
+प्रॉक्सीला विशेषाधिकारित प्रवेश आहे, कारण ते सुरक्षा तपासण्या बायपास करू शकते.
+आपण प्रॉक्सीवर विश्वास ठेवू शकतो याची खात्री करण्यासाठी, आम्ही फक्त `owner` ला हे फंक्शन कॉल करू देतो, आणि फक्त एकदाच.
+एकदा `proxy` चे वास्तविक मूल्य (शून्य नाही) आले की, ते मूल्य बदलू शकत नाही, त्यामुळे मालकाने बदमाश होण्याचा निर्णय घेतला तरी, किंवा त्यासाठीचा मेमोनिक उघड झाला तरी, आपण तरीही सुरक्षित आहोत.
+
+```solidity
+    /**
+     * @dev काही फंक्शन्स फक्त प्रॉक्सीद्वारे कॉल केली जाऊ शकतात.
+     */
+    modifier onlyProxy {
+```
+
+हे एक [`modifier` फंक्शन](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) आहे, ते इतर फंक्शन्सच्या कार्यपद्धतीत बदल करते.
+
+```solidity
+      require(msg.sender == proxy);
+```
+
+प्रथम, सत्यापित करा की आपल्याला प्रॉक्सीने आणि इतर कोणीही कॉल केलेला नाही.
+नसल्यास, `revert` करा.
+
+```solidity
+      _;
+    }
+```
+
+तसे असल्यास, आपण सुधारित करत असलेले फंक्शन चालवा.
+
+```solidity
+   /* फंक्शन्स जे प्रॉक्सीला खात्यांसाठी प्रत्यक्षात प्रॉक्सी करण्याची परवानगी देतात */
+
+    function transferProxy(address from, address to, uint256 amount)
+        public virtual onlyProxy() returns (bool)
+    {
+        _transfer(from, to, amount);
+        return true;
+    }
+
+    function approveProxy(address from, address spender, uint256 amount)
+        public virtual onlyProxy() returns (bool)
+    {
+        _approve(from, spender, amount);
+        return true;
+    }
+
+    function transferFromProxy(
+        address spender,
+        address from,
+        address to,
+        uint256 amount
+    ) public virtual onlyProxy() returns (bool)
+    {
+        _spendAllowance(from, spender, amount);
+        _transfer(from, to, amount);
+        return true;
+    }
+```
+
+या तीन क्रिया आहेत ज्यांना सामान्यतः टोकन हस्तांतरित करणाऱ्या किंवा भत्ता मंजूर करणाऱ्या घटकाकडून थेट संदेश येण्याची आवश्यकता असते.
+येथे आमच्याकडे या ऑपरेशन्सची प्रॉक्सी आवृत्ती आहे जी:
+
+1. `onlyProxy()` द्वारे सुधारित केले आहे जेणेकरून इतर कोणालाही त्यांना नियंत्रित करण्याची परवानगी नाही.
+2. जो पत्ता सामान्यतः `msg.sender` असतो तो अतिरिक्त पॅरामीटर म्हणून मिळवतो.
+
+### CalldataInterpreter.sol {#calldatainterpreter-sol-2}
+
+कॅलडेटा इंटरप्रिटर वरील इंटरप्रिटरसारखाच आहे, फक्त प्रॉक्सी केलेल्या फंक्शन्सना `msg.sender` पॅरामीटर मिळतो आणि `transfer` साठी भत्त्याची गरज नसते.
+
+```solidity
+        // हस्तांतरण (भत्त्याची गरज नाही)
+        if (_func == 2) {
+            token.transferProxy(
+                msg.sender,
+                address(uint160(calldataVal(1, 20))),
+                calldataVal(21, 2)
+            );
+        }
+
+        // मंजूर करा
+        if (_func == 3) {
+            token.approveProxy(
+                msg.sender,
+                address(uint160(calldataVal(1, 20))),
+                calldataVal(21, 2)
+            );
+        }
+
+        // transferFrom
+        if (_func == 4) {
+            token.transferFromProxy(
+                msg.sender,
+                address(uint160(calldataVal( 1, 20))),
+                address(uint160(calldataVal(21, 20))),
+                calldataVal(41, 2)
+            );
+        }
+```
+
+### Test.js {#test-js-2}
+
+मागील टेस्टिंग कोड आणि या कोडमध्ये काही बदल आहेत.
+
+```js
+const Cdi = await ethers.getContractFactory("CalldataInterpreter")
+const cdi = await Cdi.deploy(token.address)
+await cdi.deployed()
+await token.setProxy(cdi.address)
+```
+
+आम्हाला ERC-20 कॉन्ट्रॅक्टला कोणत्या प्रॉक्सीवर विश्वास ठेवावा हे सांगावे लागेल
+
+```js
+console.log("CalldataInterpreter addr:", cdi.address)
+
+// भत्ते तपासण्यासाठी दोन स्वाक्षरीकर्त्यांची आवश्यकता आहे
+const signers = await ethers.getSigners()
+const signer = signers[0]
+const poorSigner = signers[1]
+```
+
+`approve()` आणि `transferFrom()` तपासण्यासाठी आम्हाला दुसऱ्या स्वाक्षरीकर्त्याची आवश्यकता आहे.
+आम्ही त्याला `poorSigner` म्हणतो कारण त्याला आमचे कोणतेही टोकन मिळत नाहीत (अर्थात, त्याच्याकडे ETH असणे आवश्यक आहे).
+
+```js
+// टोकन हस्तांतरित करा
+const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d"
+const transferTx = {
+  to: cdi.address,
+  data: "0x02" + destAddr.slice(2, 42) + "0100",
+}
+await (await signer.sendTransaction(transferTx)).wait()
+```
+
+कारण ERC-20 कॉन्ट्रॅक्ट प्रॉक्सी (`cdi`) वर विश्वास ठेवतो, आम्हाला हस्तांतरण रिले करण्यासाठी भत्त्याची गरज नाही.
+
+```js
+// मंजूरी आणि transferFrom
+const approveTx = {
+  to: cdi.address,
+  data: "0x03" + poorSigner.address.slice(2, 42) + "00FF",
+}
+await (await signer.sendTransaction(approveTx)).wait()
+
+const destAddr2 = "0xE1165C689C0c3e9642cA7606F5287e708d846206"
+
+const transferFromTx = {
+  to: cdi.address,
+  data: "0x04" + signer.address.slice(2, 42) + destAddr2.slice(2, 42) + "00FF",
+}
+await (await poorSigner.sendTransaction(transferFromTx)).wait()
+
+// approve / transferFrom कॉम्बो योग्यरित्या केले होते की नाही हे तपासा
+expect(await token.balanceOf(destAddr2)).to.equal(255)
+```
+
+दोन नवीन फंक्शन्सची चाचणी घ्या.
+लक्षात घ्या की `transferFromTx` ला दोन पत्ता पॅरामीटर्स आवश्यक आहेत: भत्त्याचा दाता आणि स्वीकारकर्ता.
+
+## निष्कर्ष {#conclusion}
+
+दोन्ही [Optimism](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) आणि [Arbitrum](https://developer.offchainlabs.com/docs/special_features) L1 वर लिहिलेल्या कॅलडेटाचा आकार आणि त्यामुळे व्यवहारांची किंमत कमी करण्याचे मार्ग शोधत आहेत.
+तथापि, सामान्य उपायांचा शोध घेणारे पायाभूत सुविधा प्रदाते म्हणून, आमच्या क्षमता मर्यादित आहेत.
+dapp डेव्हलपर म्हणून, आपल्याकडे अनुप्रयोगा-विशिष्ट ज्ञान आहे, जे आपल्याला सामान्य समाधानापेक्षा आपले कॅलडेटा अधिक चांगल्या प्रकारे ऑप्टिमाइझ करू देते.
+आशा आहे की, हा लेख आपल्याला आपल्या गरजांसाठी आदर्श समाधान शोधण्यात मदत करेल.
+
+[माझ्या कामाबद्दल अधिक माहितीसाठी येथे पहा](https://cryptodocguy.pro/).
+
diff --git a/public/content/translations/mr/developers/tutorials/smart-contract-security-guidelines/index.md b/public/content/translations/mr/developers/tutorials/smart-contract-security-guidelines/index.md
new file mode 100644
index 00000000000..4a0a076996e
--- /dev/null
+++ b/public/content/translations/mr/developers/tutorials/smart-contract-security-guidelines/index.md
@@ -0,0 +1,91 @@
+---
+title: "स्मार्ट कॉन्ट्रॅक्ट सुरक्षा मार्गदर्शक तत्त्वे"
+description: "तुमचे डॅप तयार करताना विचारात घेण्यासाठी सुरक्षा मार्गदर्शक तत्त्वांची तपासणी सूची"
+author: "Trailofbits"
+tags: [ "सॉलिडिटी", "स्मार्ट कॉन्ट्रॅक्ट", "सुरक्षा" ]
+skill: intermediate
+lang: mr
+published: 2020-09-06
+source: Building secure contracts
+sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md
+---
+
+अधिक सुरक्षित स्मार्ट कॉन्ट्रॅक्ट तयार करण्यासाठी या उच्च-स्तरीय शिफारशींचे अनुसरण करा.
+
+## डिझाइन मार्गदर्शक तत्त्वे {#design-guidelines}
+
+कोडची कोणतीही ओळ लिहिण्यापूर्वी कॉन्ट्रॅक्टच्या डिझाइनवर वेळेपूर्वी चर्चा केली पाहिजे.
+
+### दस्तऐवजीकरण आणि विशिष्टता {#documentation-and-specifications}
+
+दस्तऐवजीकरण वेगवेगळ्या स्तरांवर लिहिले जाऊ शकते आणि कॉन्ट्रॅक्ट्सची अंमलबजावणी करताना ते अपडेट केले पाहिजे:
+
+- **सिस्टमचे सोपे इंग्रजी वर्णन**, जे कॉन्ट्रॅक्ट्स काय करतात आणि कोडबेसवरील कोणतीही गृहितके यांचे वर्णन करते.
+- **स्कीमा आणि आर्किटेक्चरल डायग्राम**, ज्यात कॉन्ट्रॅक्टमधील परस्परसंवाद आणि सिस्टमचे स्टेट मशीन समाविष्ट आहे. [स्लिदर प्रिंटर्स](https://github.com/crytic/slither/wiki/Printer-documentation) हे स्कीमा तयार करण्यासाठी मदत करू शकतात.
+- **संपूर्ण कोड दस्तऐवजीकरण**, सॉलिडिटीसाठी [Natspec फॉरमॅट](https://docs.soliditylang.org/en/develop/natspec-format.html) वापरला जाऊ शकतो.
+
+### ऑनचेन विरुद्ध ऑफचेन गणना {#onchain-vs-offchain-computation}
+
+- **तुम्ही शक्य तितका कोड ऑफचेन ठेवा.** ऑनचेन लेयर लहान ठेवा. ऑफचेन कोडसह डेटावर अशा प्रकारे पूर्व-प्रक्रिया करा की ऑनचेन पडताळणी सोपी होईल. तुम्हाला क्रमबद्ध यादीची आवश्यकता आहे का? यादी ऑफचेन लावा, मग फक्त तिचा क्रम ऑनचेन तपासा.
+
+### अपग्रेडेबिलिटी {#upgradeability}
+
+आम्ही [आमच्या ब्लॉगपोस्टमध्ये](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/) वेगवेगळ्या अपग्रेडेबिलिटी सोल्यूशन्सवर चर्चा केली आहे. कोणताही कोड लिहिण्यापूर्वी अपग्रेडेबिलिटीला सपोर्ट करायचा की नाही, याची हेतुपुरस्सर निवड करा. तुम्ही तुमचा कोड कसा संरचित करता यावर हा निर्णय प्रभाव टाकेल. सर्वसाधारणपणे, आम्ही शिफारस करतो:
+
+- **अपग्रेडेबिलिटीपेक्षा [कॉन्ट्रॅक्ट मायग्रेशनला](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) प्राधान्य द्या.** मायग्रेशन सिस्टम्समध्ये अपग्रेड करण्यायोग्य सिस्टमसारखेच अनेक फायदे आहेत, पण त्यांचे तोटे नाहीत.
+- **डेलिगेट कॉल प्रॉक्सी पॅटर्नपेक्षा डेटा सेपरेशन पॅटर्न वापरा.** जर तुमच्या प्रोजेक्टमध्ये स्पष्ट ॲब्स्ट्रॅक्शन सेपरेशन असेल, तर डेटा सेपरेशन वापरून अपग्रेडेबिलिटीसाठी फक्त काही समायोजन आवश्यक असतील. डेलिगेट कॉल प्रॉक्सीसाठी EVM तज्ञतेची आवश्यकता असते आणि ते खूप त्रुटी-प्रवण आहे.
+- **डिप्लॉयमेंट करण्यापूर्वी मायग्रेशन/अपग्रेड प्रक्रिया डॉक्युमेंट करा.** जर तुम्हाला कोणत्याही मार्गदर्शक तत्त्वांशिवाय तणावाखाली प्रतिक्रिया द्यावी लागली, तर तुम्ही चुका कराल. अनुसरण्याची प्रक्रिया वेळेपूर्वीच लिहा. त्यात समाविष्ट असावे:
+  - नवीन कॉन्ट्रॅक्ट्स सुरू करणारे कॉल्स
+  - कीज कुठे साठवल्या आहेत आणि त्या कशा ऍक्सेस करायच्या
+  - डिप्लॉयमेंट कशी तपासावी! डिप्लॉयमेंट-नंतरची स्क्रिप्ट विकसित करा आणि तपासा.
+
+## अंमलबजावणीची मार्गदर्शक तत्त्वे {#implementation-guidelines}
+
+**साधेपणासाठी प्रयत्न करा.** नेहमी सर्वात सोपा उपाय वापरा जो तुमच्या उद्देशाला अनुकूल असेल. तुमच्या टीममधील कोणत्याही सदस्याला तुमचा उपाय समजू शकला पाहिजे.
+
+### फंक्शन कंपोझिशन {#function-composition}
+
+तुमच्या कोडबेसचे आर्किटेक्चर असे असावे की ज्यामुळे तुमचा कोड तपासणे सोपे होईल. असे आर्किटेक्चरल पर्याय टाळा जे त्याच्या अचूकतेबद्दल तर्क करण्याची क्षमता कमी करतात.
+
+- **तुमच्या सिस्टमच्या लॉजिकचे विभाजन करा**, एकतर अनेक कॉन्ट्रॅक्ट्सद्वारे किंवा समान फंक्शन्स एकत्र गटबद्ध करून (उदाहरणार्थ, ऑथेंटिकेशन, अंकगणित, ...).
+- **स्पष्ट उद्देशाने लहान फंक्शन्स लिहा.** यामुळे पुनरावलोकन सोपे होईल आणि वैयक्तिक घटकांची चाचणी घेता येईल.
+
+### इनहेरिटन्स {#inheritance}
+
+- **इनहेरिटन्स व्यवस्थापनीय ठेवा.** लॉजिकचे विभाजन करण्यासाठी इनहेरिटन्सचा वापर केला पाहिजे, तथापि, तुमच्या प्रोजेक्टने इनहेरिटन्स ट्रीची खोली आणि रुंदी कमी करण्याचे ध्येय ठेवले पाहिजे.
+- **कॉन्ट्रॅक्ट्सची हायरार्की तपासण्यासाठी स्लिदरचा [इनहेरिटन्स प्रिंटर](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) वापरा.** इनहेरिटन्स प्रिंटर तुम्हाला हायरार्कीचा आकार तपासण्यात मदत करेल.
+
+### इव्हेंट्स {#events}
+
+- **सर्व महत्त्वाच्या ऑपरेशन्स लॉग करा.** इव्हेंट्स डेव्हलपमेंट दरम्यान कॉन्ट्रॅक्ट डीबग करण्यास आणि डिप्लॉयमेंटनंतर त्यावर लक्ष ठेवण्यास मदत करतील.
+
+### ज्ञात धोके टाळा {#avoid-known-pitfalls}
+
+- **सर्वात सामान्य सुरक्षा समस्यांबद्दल जागरूक रहा.** सामान्य समस्यांबद्दल जाणून घेण्यासाठी अनेक ऑनलाइन संसाधने आहेत, जसे की [Ethernaut CTF](https://ethernaut.openzeppelin.com/), [कॅप्चर द इथर](https://capturetheether.com/), किंवा [नॉट सो स्मार्ट कॉन्ट्रॅक्ट्स](https://github.com/crytic/not-so-smart-contracts/).
+- **[Solidity दस्तऐवजीकरणामधील](https://docs.soliditylang.org/en/latest/) चेतावणी विभागांबद्दल जागरूक रहा.** चेतावणी विभाग तुम्हाला भाषेच्या अस्पष्ट वर्तनाबद्दल माहिती देतील.
+
+### डिपेंडन्सीज {#dependencies}
+
+- **चांगल्या प्रकारे तपासलेल्या लायब्ररी वापरा.** चांगल्या प्रकारे तपासलेल्या लायब्ररीमधून कोड इम्पोर्ट केल्याने तुम्ही सदोष कोड लिहिण्याची शक्यता कमी होईल. जर तुम्हाला ERC20 कॉन्ट्रॅक्ट लिहायचा असेल, तर [OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20) वापरा.
+- **डिपेंडन्सी मॅनेजर वापरा; कोड कॉपी-पेस्ट करणे टाळा.** जर तुम्ही बाह्य स्त्रोतावर अवलंबून असाल, तर तुम्ही ते मूळ स्त्रोतासह अद्ययावत ठेवले पाहिजे.
+
+### चाचणी आणि पडताळणी {#testing-and-verification}
+
+- **संपूर्ण युनिट-टेस्ट्स लिहा.** उच्च-गुणवत्तेचे सॉफ्टवेअर तयार करण्यासाठी एक विस्तृत टेस्ट सूट महत्त्वपूर्ण आहे.
+- **[स्लिदर](https://github.com/crytic/slither), [एकिडना](https://github.com/crytic/echidna) आणि [मॅन्टिकोर](https://github.com/trailofbits/manticore) कस्टम चेक्स आणि प्रॉपर्टीज लिहा.** स्वयंचलित टूल्स तुमचा कॉन्ट्रॅक्ट सुरक्षित असल्याची खात्री करण्यास मदत करतील. कार्यक्षम चेक्स आणि प्रॉपर्टीज कसे लिहायचे हे जाणून घेण्यासाठी या मार्गदर्शकाचा उर्वरित भाग तपासा.
+- **[crytic.io](https://crytic.io/) वापरा.** क्रिटिक GitHub सह समाकलित होते, खाजगी स्लिदर डिटेक्टरना ऍक्सेस प्रदान करते, आणि एकिडनामधून कस्टम प्रॉपर्टी चेक्स चालवते.
+
+### Solidity {#solidity}
+
+- **0.4 आणि 0.6 पेक्षा सॉलिडिटी 0.5 ला प्राधान्य द्या.** आमच्या मते, सॉलिडिटी 0.5 अधिक सुरक्षित आहे आणि 0.4 पेक्षा त्यात अधिक चांगल्या बिल्ट-इन पद्धती आहेत. सॉलिडिटी 0.6 उत्पादनासाठी खूपच अस्थिर सिद्ध झाले आहे आणि त्याला परिपक्व होण्यासाठी वेळ लागेल.
+- **कंपाइल करण्यासाठी स्थिर रिलीझ वापरा; चेतावणी तपासण्यासाठी नवीनतम रिलीझ वापरा.** नवीनतम कंपाइलर आवृत्तीसह तुमच्या कोडमध्ये कोणतीही नोंदवलेली समस्या नाही याची खात्री करा. तथापि, सॉलिडिटीचे रिलीझ चक्र वेगवान आहे आणि त्यात कंपाइलर बग्सचा इतिहास आहे, म्हणून आम्ही डिप्लॉयमेंटसाठी नवीनतम आवृत्तीची शिफारस करत नाही (स्लिदरची [solc आवृत्ती शिफारस](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33) पहा).
+- **इनलाइन असेंब्ली वापरू नका.** असेंब्लीसाठी EVM तज्ञतेची आवश्यकता असते. जर तुम्ही यलो पेपरवर _प्रभुत्व_ मिळवले नसेल तर EVM कोड लिहू नका.
+
+## डिप्लॉयमेंट मार्गदर्शक तत्त्वे {#deployment-guidelines}
+
+एकदा कॉन्ट्रॅक्ट विकसित आणि डिप्लॉय झाल्यानंतर:
+
+- **तुमच्या कॉन्ट्रॅक्ट्सवर लक्ष ठेवा.** लॉग्स पहा आणि कॉन्ट्रॅक्ट किंवा वॉलेटशी तडजोड झाल्यास प्रतिक्रिया देण्यासाठी तयार रहा.
+- **तुमची संपर्क माहिती [ब्लॉकचेन-सुरक्षा-संपर्क](https://github.com/crytic/blockchain-security-contacts) मध्ये जोडा.** जर एखादी सुरक्षा त्रुटी आढळल्यास ही यादी तृतीय-पक्षांना तुमच्याशी संपर्क साधण्यास मदत करते.
+- **विशेषाधिकार असलेल्या वापरकर्त्यांचे वॉलेट्स सुरक्षित करा.** जर तुम्ही हार्डवेअर वॉलेट्समध्ये कीज साठवत असाल तर आमच्या [सर्वोत्तम पद्धतींचे](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/) अनुसरण करा.
+- **घटनेला प्रतिसाद देण्यासाठी एक योजना तयार ठेवा.** तुमचे स्मार्ट कॉन्ट्रॅक्ट्स धोक्यात येऊ शकतात याचा विचार करा. जरी तुमचे कॉन्ट्रॅक्ट्स बग-मुक्त असले तरी, एक हल्लेखोर कॉन्ट्रॅक्ट मालकाच्या कीजचा ताबा घेऊ शकतो.
diff --git a/public/content/translations/mr/developers/tutorials/stealth-addr/index.md b/public/content/translations/mr/developers/tutorials/stealth-addr/index.md
new file mode 100644
index 00000000000..1c3b5e5ff16
--- /dev/null
+++ b/public/content/translations/mr/developers/tutorials/stealth-addr/index.md
@@ -0,0 +1,436 @@
+---
+title: "गुप्त पत्त्यांचा वापर"
+description: "गुप्त पत्ते वापरकर्त्यांना अज्ञातपणे मालमत्ता हस्तांतरित करण्याची परवानगी देतात. हा लेख वाचल्यानंतर, तुम्ही हे करू शकाल: गुप्त पत्ते काय आहेत आणि ते कसे कार्य करतात हे स्पष्ट करू शकाल, अनामिकता जपणाऱ्या पद्धतीने गुप्त पत्त्यांचा वापर कसा करायचा हे समजू शकाल, आणि गुप्त पत्त्यांचा वापर करणारे वेब-आधारित ॲप्लिकेशन लिहू शकाल."
+author: Ori Pomerantz
+tags: [ "गुप्त पत्ता", "गोपनीयता", "कूटलेखन", "rust", "wasm" ]
+skill: intermediate
+published: 2025-11-30
+lang: mr
+sidebarDepth: 3
+---
+
+तुम्ही बिल आहात. ज्या कारणांमध्ये आपण जाणार नाही, त्या कारणास्तव, तुम्हाला "Alice for Queen of the World" मोहिमेसाठी देणगी द्यायची आहे आणि तुम्ही देणगी दिली आहे हे ॲलिसला कळावे असे तुम्हाला वाटते, जेणेकरून ती जिंकल्यास तुम्हाला बक्षीस देईल. दुर्दैवाने, तिचा विजय निश्चित नाही. एक प्रतिस्पर्धी मोहीम आहे, "Carol for Empress of the Solar System". जर कॅरोल जिंकली आणि तिला कळले की तुम्ही ॲलिसला देणगी दिली आहे, तर तुम्ही अडचणीत याल. म्हणून तुम्ही तुमच्या खात्यातून ॲलिसच्या खात्यात फक्त 200 ETH हस्तांतरित करू शकत नाही.
+
+[ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) मध्ये याचे समाधान आहे. हे ERC अज्ञात हस्तांतरणासाठी [गुप्त पत्त्यांचा](https://nerolation.github.io/stealth-utils) वापर कसा करायचा हे स्पष्ट करते.
+
+**चेतावणी**: गुप्त पत्त्यांमागील कूटलेखन, आमच्या माहितीनुसार, सुरक्षित आहे. तथापि, संभाव्य साइड-चॅनल हल्ले होऊ शकतात. [खाली](#go-wrong), हा धोका कमी करण्यासाठी तुम्ही काय करू शकता ते तुम्हाला दिसेल.
+
+## गुप्त पत्ते कसे कार्य करतात {#how}
+
+हा लेख गुप्त पत्ते दोन प्रकारे स्पष्ट करण्याचा प्रयत्न करेल. पहिले म्हणजे [त्यांचा वापर कसा करायचा](#how-use). लेखाचा उर्वरित भाग समजून घेण्यासाठी हा भाग पुरेसा आहे. त्यानंतर, [त्यामागील गणिताचे स्पष्टीकरण](#how-math) आहे. जर तुम्हाला कूटलेखनात रस असेल, तर हा भाग देखील वाचा.
+
+### साधी आवृत्ती (गुप्त पत्त्यांचा वापर कसा करायचा) {#how-use}
+
+ॲलिस दोन खाजगी की तयार करते आणि संबंधित सार्वजनिक की प्रकाशित करते (ज्या एकाच दुप्पट-लांबीच्या मेटा-पत्त्यामध्ये एकत्र केल्या जाऊ शकतात). बिल देखील एक खाजगी की तयार करतो आणि संबंधित सार्वजनिक की प्रकाशित करतो.
+
+एका पक्षाची सार्वजनिक की आणि दुसऱ्याची खाजगी की वापरून, तुम्ही एक सामायिक गुप्त (shared secret) मिळवू शकता जे केवळ ॲलिस आणि बिल यांनाच माहीत आहे (ते केवळ सार्वजनिक कीमधून मिळवता येत नाही). हे सामायिक गुप्त वापरून, बिलला गुप्त पत्ता मिळतो आणि तो त्यावर मालमत्ता पाठवू शकतो.
+
+ॲलिसला सामायिक गुप्तानंतर पत्ता मिळतो, परंतु तिने प्रकाशित केलेल्या सार्वजनिक कींच्या खाजगी की तिला माहीत असल्यामुळे, तिला त्या पत्त्यावरून पैसे काढण्यासाठी खाजगी की देखील मिळू शकते.
+
+### गणित (गुप्त पत्ते असे का कार्य करतात) {#how-math}
+
+मानक गुप्त पत्ते [एलिप्टिक-कर्व्ह क्रिप्टोग्राफी (ECC)](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/#elliptic-curves-building-blocks-of-a-better-trapdoor) वापरतात ज्यामुळे कमी की बिट्ससह चांगली कामगिरी मिळते, आणि त्याच वेळी सुरक्षेची पातळी कायम राहते. परंतु बहुतेक वेळा आपण त्याकडे दुर्लक्ष करू शकतो आणि आपण नियमित अंकगणित वापरत आहोत असे भासवू शकतो.
+
+एक संख्या आहे जी प्रत्येकाला माहीत आहे, _G_. तुम्ही _G_ ने गुणू शकता. परंतु ECC च्या स्वरूपामुळे, _G_ ने भागणे व्यावहारिकदृष्ट्या अशक्य आहे. Ethereum मध्ये सार्वजनिक की कूटलेखन सामान्यतः ज्या प्रकारे कार्य करते ते म्हणजे, तुम्ही व्यवहार स्वाक्षरी करण्यासाठी एक खाजगी की, _P<sub>priv</sub>_ वापरू शकता, जे नंतर सार्वजनिक की, _P<sub>pub</sub> = GP<sub>priv</sub>_ द्वारे सत्यापित केले जातात.
+
+ॲलिस दोन खाजगी की तयार करते, _K<sub>priv</sub>_ आणि _V<sub>priv</sub>_. _K<sub>priv</sub>_ चा वापर गुप्त पत्त्यामधून पैसे खर्च करण्यासाठी केला जाईल, आणि _V<sub>priv</sub>_ चा वापर ॲलिसच्या मालकीचे पत्ते पाहण्यासाठी केला जाईल. त्यानंतर ॲलिस सार्वजनिक की प्रकाशित करते: _K<sub>pub</sub> = GK<sub>priv</sub>_ आणि _V<sub>pub</sub> = GV<sub>priv</sub>_
+
+बिल तिसरी खाजगी की, _R<sub>priv</sub>_ तयार करतो, आणि _R<sub>pub</sub> = GR<sub>priv</sub>_ एका केंद्रीय नोंदणीमध्ये प्रकाशित करतो (बिलने ते ॲलिसला देखील पाठवले असते, परंतु आम्ही असे गृहीत धरतो की कॅरोल ऐकत आहे).
+
+बिल _R<sub>priv</sub>V<sub>pub</sub> = GR<sub>priv</sub>V<sub>priv</sub>_ ची गणना करतो, जे ॲलिसला देखील माहीत असेल अशी त्याला अपेक्षा आहे (खाली स्पष्ट केले आहे). या मूल्याला _S_, म्हणजेच सामायिक गुप्त (shared secret) म्हणतात. यामुळे बिलला एक सार्वजनिक की मिळते, _P<sub>pub</sub> = K<sub>pub</sub>+G\*hash(S)_. या सार्वजनिक कीमधून, तो एक पत्ता मोजू शकतो आणि त्याला हवी असलेली कोणतीही संसाधने त्यावर पाठवू शकतो. भविष्यात, जर ॲलिस जिंकली, तर बिल तिला _R<sub>priv</sub>_ सांगून संसाधने त्याच्याकडून आली आहेत हे सिद्ध करू शकतो.
+
+ॲलिस _R<sub>pub</sub>V<sub>priv</sub> = GR<sub>priv</sub>V<sub>priv</sub>_ ची गणना करते. यामुळे तिला तेच सामायिक गुप्त, _S_ मिळते. तिला खाजगी की, _K<sub>priv</sub>_ माहीत असल्यामुळे, ती _P<sub>priv</sub> = K<sub>priv</sub>+hash(S)_ ची गणना करू शकते. ही की तिला _P<sub>pub</sub> = GP<sub>priv</sub> = GK<sub>priv</sub>+G\*hash(S) = K<sub>pub</sub>+G\*hash(S)_ मधून मिळणाऱ्या पत्त्यातील मालमत्तांमध्ये प्रवेश करू देते.
+
+आमच्याकडे एक वेगळी व्ह्यूइंग की (viewing key) आहे, जी ॲलिसला डेव्हच्या वर्ल्ड डॉमिनेशन कॅम्पेन सर्व्हिसेसला उपकंत्राट देण्यास अनुमती देते. ॲलिस डेव्हला सार्वजनिक पत्ते कळवण्यास आणि अधिक पैसे उपलब्ध झाल्यावर तिला माहिती देण्यास तयार आहे, परंतु तिने तिच्या मोहिमेचे पैसे खर्च करावेत असे तिला वाटत नाही.
+
+पाहणे आणि खर्च करणे यासाठी स्वतंत्र की वापरल्या जातात, त्यामुळे ॲलिस डेव्हला _V<sub>priv</sub>_ देऊ शकते. त्यानंतर डेव्ह _S = R<sub>pub</sub>V<sub>priv</sub> = GR<sub>priv</sub>V<sub>priv</sub>_ ची गणना करू शकतो आणि त्याद्वारे सार्वजनिक की (_P<sub>pub</sub> = K<sub>pub</sub>+G\*hash(S)_) मिळवू शकतो. परंतु _K<sub>priv</sub>_ शिवाय डेव्ह खाजगी की मिळवू शकत नाही.
+
+सारांश, ही मूल्ये विविध सहभागींना ज्ञात आहेत.
+
+| ॲलिस                                                                      | प्रकाशित          | बिल                                                                       | डेव्ह                                                                       |                                               |
+| ------------------------------------------------------------------------- | ----------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------- |
+| G                                                                         | G                 | G                                                                         | G                                                                           |                                               |
+| _K<sub>priv</sub>_                                                        | -                 | -                                                                         | -                                                                           |                                               |
+| _V<sub>priv</sub>_                                                        | -                 | -                                                                         | _V<sub>priv</sub>_                                                          |                                               |
+| _K<sub>pub</sub> = GK<sub>priv</sub>_                                     | _K<sub>pub</sub>_ | _K<sub>pub</sub>_                                                         | _K<sub>pub</sub>_                                                           |                                               |
+| _V<sub>pub</sub> = GV<sub>priv</sub>_                                     | _V<sub>pub</sub>_ | _V<sub>pub</sub>_                                                         | _V<sub>pub</sub>_                                                           |                                               |
+| -                                                                         | -                 | _R<sub>priv</sub>_                                                        | -                                                                           |                                               |
+| _R<sub>pub</sub>_                                                         | _R<sub>pub</sub>_ | _R<sub>pub</sub> = GR<sub>priv</sub>_                                     | _R<sub>pub</sub>_                                                           |                                               |
+| _S = R<sub>pub</sub>V<sub>priv</sub> = GR<sub>priv</sub>V<sub>priv</sub>_ | -                 | _S = R<sub>priv</sub>V<sub>pub</sub> = GR<sub>priv</sub>V<sub>priv</sub>_ | _S = _R<sub>pub</sub>V<sub>priv</sub>_ = GR<sub>priv</sub>V<sub>priv</sub>_ |                                               |
+| _P<sub>pub</sub> = K<sub>pub</sub>+G\*hash(S)_         | -                 | _P<sub>pub</sub> = K<sub>pub</sub>+G\*hash(S)_         | _P<sub>pub</sub> = K<sub>pub</sub>+G\*hash(S)_           |                                               |
+| _पत्ता=f(P<sub>pub</sub>)_                             | -                 | _पत्ता=f(P<sub>pub</sub>)_                             | _पत्ता=f(P<sub>pub</sub>)_                               | _पत्ता=f(P<sub>pub</sub>)_ |
+| _P<sub>priv</sub> = K<sub>priv</sub>+hash(S)_          | -                 | -                                                                         | -                                                                           |                                               |
+
+## जेव्हा गुप्त पत्ते चुकीचे ठरतात {#go-wrong}
+
+_ब्लॉकचेनवर कोणतीही रहस्ये नसतात_. जरी गुप्त पत्ते तुम्हाला गोपनीयता देऊ शकतात, तरीही ती गोपनीयता ट्रॅफिक विश्लेषणासाठी असुरक्षित असते. एक सोपे उदाहरण घ्यायचे झाल्यास, कल्पना करा की बिल एका पत्त्याला निधी देतो आणि लगेच _R<sub>pub</sub>_ मूल्य प्रकाशित करण्यासाठी एक व्यवहार पाठवतो. ॲलिसच्या _V<sub>priv</sub>_ शिवाय, हा एक गुप्त पत्ता आहे याची खात्री आपण करू शकत नाही, परंतु तसा अंदाज लावता येतो. त्यानंतर, आम्हाला आणखी एक व्यवहार दिसतो जो त्या पत्त्यावरून सर्व ETH ॲलिसच्या मोहीम निधी पत्त्यावर हस्तांतरित करतो. आम्ही ते सिद्ध करू शकत नाही, परंतु बहुधा बिलने नुकतीच ॲलिसच्या मोहिमेला देणगी दिली आहे. कॅरोलला नक्कीच असे वाटेल.
+
+बिलसाठी _R<sub>pub</sub>_ चे प्रकाशन आणि गुप्त पत्त्यासाठी निधी देणे हे वेगळे करणे सोपे आहे (हे वेगवेगळ्या वेळी, वेगवेगळ्या पत्त्यांवरून करा). तथापि, ते पुरेसे नाही. कॅरोल जो पॅटर्न शोधते तो असा आहे की बिल एका पत्त्याला निधी देतो, आणि नंतर ॲलिसचा मोहीम निधी त्यातून पैसे काढतो.
+
+एक उपाय म्हणजे ॲलिसच्या मोहिमेने थेट पैसे काढू नये, तर ते तिसऱ्या पक्षाला पैसे देण्यासाठी वापरावे. जर ॲलिसची मोहीम डेव्हच्या वर्ल्ड डॉमिनेशन कॅम्पेन सर्व्हिसेसला 10 ETH पाठवते, तर कॅरोलला फक्त एवढेच कळते की बिलने डेव्हच्या एका ग्राहकाला देणगी दिली आहे. जर डेव्हकडे पुरेसे ग्राहक असतील, तर कॅरोलला हे कळू शकणार नाही की बिलने तिच्याशी स्पर्धा करणाऱ्या ॲलिसला देणगी दिली की ॲडम, अल्बर्ट किंवा ॲबिगेल यांना, ज्यांची कॅरोलला पर्वा नाही. ॲलिस पेमेंटसोबत एक हॅश केलेले मूल्य समाविष्ट करू शकते, आणि नंतर डेव्हला प्रीइमेज देऊ शकते, हे सिद्ध करण्यासाठी की ती तिची देणगी होती. वैकल्पिकरित्या, वर नमूद केल्याप्रमाणे, जर ॲलिसने डेव्हला तिची _V<sub>priv</sub>_ दिली, तर त्याला आधीच कळते की पेमेंट कोणाकडून आले आहे.
+
+या उपायातील मुख्य समस्या अशी आहे की, जेव्हा ती गुप्तता बिलच्या फायद्याची असते तेव्हा ॲलिसने गुप्ततेची काळजी घेणे आवश्यक असते. ॲलिसला तिची प्रतिष्ठा टिकवून ठेवायची असेल, जेणेकरून बिलचा मित्र बॉब देखील तिला देणगी देईल. परंतु हे देखील शक्य आहे की तिला बिलला उघड करण्यास हरकत नसेल, कारण मग कॅरोल जिंकल्यास काय होईल याची त्याला भीती वाटेल. बिल कदाचित ॲलिसला आणखी जास्त पाठिंबा देऊ शकेल.
+
+### अनेक गुप्त स्तरांचा वापर करणे {#multi-layer}
+
+बिलची गोपनीयता जपण्यासाठी ॲलिसवर अवलंबून राहण्याऐवजी, बिल ते स्वतः करू शकतो. तो बॉब आणि बेला या काल्पनिक लोकांसाठी अनेक मेटा-पत्ते तयार करू शकतो. बिल नंतर बॉबला ETH पाठवतो, आणि "बॉब" (जो खरं तर बिल आहे) ते बेलाला पाठवतो. "बेला" (जो बिलच आहे) ते ॲलिसला पाठवते.
+
+कॅरोल तरीही ट्रॅफिक विश्लेषण करू शकते आणि बिल-ते-बॉब-ते-बेला-ते-ॲलिस पाइपलाइन पाहू शकते. तथापि, जर "बॉब" आणि "बेला" देखील इतर कारणांसाठी ETH वापरत असतील, तर असे दिसणार नाही की बिलने ॲलिसला काही हस्तांतरित केले आहे, जरी ॲलिसने गुप्त पत्त्यावरून तिच्या ज्ञात मोहीम पत्त्यावर त्वरित पैसे काढले तरीही.
+
+## एक गुप्त-पत्ता ॲप्लिकेशन लिहिणे {#write-app}
+
+हा लेख [GitHub वर उपलब्ध](https://github.com/qbzzt/251022-stealth-addresses.git) असलेल्या गुप्त-पत्ता ॲप्लिकेशनबद्दल स्पष्ट करतो.
+
+### साधने {#tools}
+
+एक [टाइपस्क्रिप्ट गुप्त पत्ता लायब्ररी](https://github.com/ScopeLift/stealth-address-sdk) आहे जी आपण वापरू शकतो. तथापि, कूटलेखन ऑपरेशन्स CPU-केंद्रित असू शकतात. मी त्यांना [Rust](https://rust-lang.org/) सारख्या संकलित भाषेत कार्यान्वित करण्यास प्राधान्य देतो, आणि ब्राउझरमध्ये कोड चालवण्यासाठी [WASM](https://webassembly.org/) वापरतो.
+
+आम्ही [Vite](https://vite.dev/) आणि [React](https://react.dev/) वापरणार आहोत. ही उद्योग-मानक साधने आहेत; जर तुम्हाला त्यांच्याशी परिचय नसेल, तर तुम्ही [हे ट्यूटोरियल](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/) वापरू शकता. Vite वापरण्यासाठी, आम्हाला Node ची आवश्यकता आहे.
+
+### गुप्त पत्ते प्रत्यक्षात पहा {#in-action}
+
+1. आवश्यक साधने स्थापित करा: [Rust](https://rust-lang.org/tools/install/) आणि [Node](https://nodejs.org/en/download).
+
+2. GitHub रिपॉझिटरी क्लोन करा.
+
+   ```sh
+   git clone https://github.com/qbzzt/251022-stealth-addresses.git
+   cd 251022-stealth-addresses
+   ```
+
+3. पूर्वापेक्षित गोष्टी स्थापित करा आणि Rust कोड संकलित करा.
+
+   ```sh
+   cd src/rust-wasm
+   rustup target add wasm32-unknown-unknown   
+   cargo install wasm-pack   
+   wasm-pack build --target web
+   ```
+
+4. वेब सर्व्हर सुरू करा.
+
+   ```sh
+   cd ../..
+   npm install
+   npm run dev
+   ```
+
+5. [ॲप्लिकेशन](http://localhost:5173/) वर ब्राउझ करा. या ॲप्लिकेशन पृष्ठावर दोन फ्रेम आहेत: एक ॲलिसच्या वापरकर्ता इंटरफेससाठी आणि दुसरी बिलच्या. दोन फ्रेम संवाद साधत नाहीत; त्या फक्त सोयीसाठी एकाच पृष्ठावर आहेत.
+
+6. ॲलिस म्हणून, **एक गुप्त मेटा-पत्ता तयार करा** वर क्लिक करा. हे नवीन गुप्त पत्ता आणि संबंधित खाजगी की प्रदर्शित करेल. गुप्त मेटा-पत्ता क्लिपबोर्डवर कॉपी करा.
+
+7. बिल म्हणून, नवीन गुप्त मेटा-पत्ता पेस्ट करा आणि **एक पत्ता तयार करा** वर क्लिक करा. हे तुम्हाला ॲलिससाठी निधी देण्यासाठी पत्ता देते.
+
+8. पत्ता आणि बिलची सार्वजनिक की कॉपी करा आणि त्यांना ॲलिसच्या वापरकर्ता इंटरफेसच्या "बिलद्वारे तयार केलेल्या पत्त्यासाठी खाजगी की" क्षेत्रात पेस्ट करा. एकदा ती क्षेत्रे भरली की, तुम्हाला त्या पत्त्यावरील मालमत्तांमध्ये प्रवेश करण्यासाठी खाजगी की दिसेल.
+
+9. खाजगी की पत्त्याशी जुळते याची खात्री करण्यासाठी तुम्ही [एक ऑनलाइन कॅल्क्युलेटर](https://iancoleman.net/ethereum-private-key-to-address/) वापरू शकता.
+
+### प्रोग्राम कसा कार्य करतो {#how-the-program-works}
+
+#### WASM घटक {#wasm}
+
+WASM मध्ये संकलित होणारा स्त्रोत कोड [Rust](https://rust-lang.org/) मध्ये लिहिलेला आहे. तुम्ही ते [`src/rust_wasm/src/lib.rs`](https://github.com/qbzzt/251022-stealth-addresses/blob/main/src/rust-wasm/src/lib.rs) मध्ये पाहू शकता. हा कोड प्रामुख्याने JavaScript कोड आणि [`eth-stealth-addresses` लायब्ररी](https://github.com/kassandraoftroy/eth-stealth-addresses) यांच्यातील इंटरफेस आहे.
+
+**`Cargo.toml`**
+
+Rust मधील [`Cargo.toml`](https://doc.rust-lang.org/cargo/reference/manifest.html) हे JavaScript मधील [`package.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-json) प्रमाणेच आहे. यात पॅकेज माहिती, अवलंबित्व घोषणा इत्यादींचा समावेश आहे.
+
+```toml
+[package]
+name = "rust-wasm"
+version = "0.1.0"
+edition = "2024"
+
+[dependencies]
+eth-stealth-addresses = "0.1.0"
+hex = "0.4.3"
+wasm-bindgen = "0.2.104"
+getrandom = { version = "0.2", features = ["js"] }
+```
+
+[`getrandom`](https://docs.rs/getrandom/latest/getrandom/) पॅकेजला यादृच्छिक मूल्ये तयार करण्याची आवश्यकता आहे. हे केवळ अल्गोरिदमिक माध्यमांनी केले जाऊ शकत नाही; त्याला एंट्रॉपीचा स्त्रोत म्हणून भौतिक प्रक्रियेत प्रवेश आवश्यक आहे. ही व्याख्या निर्दिष्ट करते की आम्ही ज्या ब्राउझरमध्ये चालवत आहोत त्याला विचारून आम्ही ती एंट्रॉपी मिळवू.
+
+```toml
+console_error_panic_hook = "0.1.7"
+```
+
+[ही लायब्ररी](https://docs.rs/console_error_panic_hook/latest/console_error_panic_hook/) आम्हाला अधिक अर्थपूर्ण त्रुटी संदेश देते जेव्हा WASM कोड पॅनिक होतो आणि पुढे चालू शकत नाही.
+
+```toml
+[lib]
+crate-type = ["cdylib", "rlib"]
+```
+
+WASM कोड तयार करण्यासाठी आवश्यक असलेला आउटपुट प्रकार.
+
+**`lib.rs`**
+
+हा खरा Rust कोड आहे.
+
+```rust
+use wasm_bindgen::prelude::*;
+```
+
+Rust मधून WASM पॅकेज तयार करण्याच्या व्याख्या. ते [येथे](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/index.html) दस्तऐवजीकरण केलेले आहेत.
+
+```rust
+use eth_stealth_addresses::{
+    generate_stealth_meta_address,
+    generate_stealth_address,
+    compute_stealth_key
+};
+```
+
+आम्हाला [`eth-stealth-addresses` लायब्ररी](https://github.com/kassandraoftroy/eth-stealth-addresses) मधून आवश्यक असलेली फंक्शन्स.
+
+```rust
+use hex::{decode,encode};
+```
+
+Rust सामान्यतः मूल्यांसाठी बाइट [अॅरे](https://doc.rust-lang.org/std/primitive.array.html) (`[u8; <size>]`) वापरते. परंतु JavaScript मध्ये, आम्ही सामान्यतः हेक्साडेसिमल स्ट्रिंग वापरतो. [`hex` लायब्ररी](https://docs.rs/hex/latest/hex/) आमच्यासाठी एका प्रतिनिधित्वातून दुसऱ्यामध्ये भाषांतर करते.
+
+```rust
+#[wasm_bindgen]
+```
+
+JavaScript मधून हे फंक्शन कॉल करण्यासाठी WASM बाइंडिंग तयार करा.
+
+```rust
+pub fn wasm_generate_stealth_meta_address() -> String {
+```
+
+अनेक फील्ड असलेले ऑब्जेक्ट परत करण्याचा सर्वात सोपा मार्ग म्हणजे JSON स्ट्रिंग परत करणे.
+
+```rust
+    let (address, spend_private_key, view_private_key) = 
+        generate_stealth_meta_address();
+```
+
+[`generate_stealth_meta_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_meta_address.html) तीन फील्ड परत करते:
+
+- मेटा-पत्ता (_K<sub>pub</sub>_ आणि _V<sub>pub</sub>_)
+- पाहण्याची खाजगी की (_V<sub>priv</sub>_)
+- खर्च करण्याची खाजगी की (_K<sub>priv</sub>_)
+
+[टपल](https://doc.rust-lang.org/std/primitive.tuple.html) सिंटॅक्स आम्हाला ती मूल्ये पुन्हा वेगळी करू देतो.
+
+```rust
+    format!("{{\"address\":\"{}\",\"view_private_key\":\"{}\",\"spend_private_key\":\"{}\"}}",
+        encode(address),
+        encode(view_private_key),
+        encode(spend_private_key)
+    )
+}
+```
+
+JSON-एनकोडेड स्ट्रिंग तयार करण्यासाठी [`format!`](https://doc.rust-lang.org/std/fmt/index.html) मॅक्रो वापरा. अॅरेला हेक्स स्ट्रिंगमध्ये बदलण्यासाठी [`hex::encode`](https://docs.rs/hex/latest/hex/fn.encode.html) वापरा.
+
+```rust
+fn str_to_array<const N: usize>(s: &str) -> Option<[u8; N]> {
+```
+
+हे फंक्शन हेक्स स्ट्रिंगला (JavaScript द्वारे प्रदान केलेले) बाइट अॅरेमध्ये बदलते. आम्ही JavaScript कोडद्वारे प्रदान केलेली मूल्ये पार्स करण्यासाठी याचा वापर करतो. Rust अॅरे आणि व्हेक्टर कसे हाताळते त्यामुळे हे फंक्शन क्लिष्ट आहे.
+
+`<const N: usize>` अभिव्यक्तीला [जेनेरिक](https://doc.rust-lang.org/book/ch10-01-syntax.html) म्हणतात. `N` हे एक पॅरामीटर आहे जे परत केलेल्या अॅरेच्या लांबीवर नियंत्रण ठेवते. फंक्शनला प्रत्यक्षात `str_to_array::<n>` असे म्हणतात, जिथे `n` ही अॅरेची लांबी आहे.
+
+परत केलेले मूल्य `Option<[u8; N]>` आहे, याचा अर्थ परत केलेला अॅरे [पर्यायी](https://doc.rust-lang.org/std/option/) आहे. Rust मध्ये अयशस्वी होऊ शकणाऱ्या फंक्शन्ससाठी हा एक सामान्य नमुना आहे.
+
+उदाहरणार्थ, जर आपण `str_to_array::10("bad060a7")` कॉल केले, तर फंक्शनने दहा-मूल्यांची अॅरे परत करणे अपेक्षित आहे, परंतु इनपुट फक्त चार बाइट्सचे आहे. फंक्शन अयशस्वी होणे आवश्यक आहे, आणि ते `None` परत करून तसे करते. `str_to_array::4("bad060a7")` साठी परत केलेले मूल्य `Some<[0xba, 0xd0, 0x60, 0xa7]>` असेल.
+
+```rust
+    // decode returns Result<Vec<u8>, _>
+    let vec = decode(s).ok()?;
+```
+
+[`hex::decode`](https://docs.rs/hex/latest/hex/fn.decode.html) फंक्शन `Result<Vec<u8>, FromHexError>` परत करते. [`Result`](https://doc.rust-lang.org/std/result/) प्रकारात एकतर यशस्वी परिणाम (`Ok(value)`) किंवा एक त्रुटी (`Err(error)`) असू शकते.
+
+`.ok()` पद्धत `Result` ला `Option` मध्ये रूपांतरित करते, ज्याचे मूल्य यशस्वी झाल्यास `Ok()` मूल्य किंवा अयशस्वी झाल्यास `None` असते. शेवटी, [प्रश्नचिन्ह ऑपरेटर](https://doc.rust-lang.org/std/option/#the-question-mark-operator-) `Option` रिक्त असल्यास वर्तमान फंक्शन रद्द करतो आणि `None` परत करतो. अन्यथा, ते मूल्य अनरॅप करते आणि ते परत करते (या प्रकरणात, `vec` ला मूल्य नियुक्त करण्यासाठी).
+
+त्रुटी हाताळण्याची ही एक विचित्र गुंतागुंतीची पद्धत वाटते, परंतु `Result` आणि `Option` हे सुनिश्चित करतात की सर्व त्रुटी, एका ना कोणत्या मार्गाने हाताळल्या जातात.
+
+```rust
+    if vec.len() != N { return None; }
+```
+
+जर बाइट्सची संख्या चुकीची असेल, तर ते अपयश आहे, आणि आम्ही `None` परत करतो.
+
+```rust
+    // try_into consumes vec and attempts to make [u8; N]
+    let array: [u8; N] = vec.try_into().ok()?;
+```
+
+Rust मध्ये दोन अॅरे प्रकार आहेत. [अॅरे](https://doc.rust-lang.org/std/primitive.array.html) चा आकार निश्चित असतो. [व्हेक्टर](https://doc.rust-lang.org/std/vec/index.html) वाढू आणि लहान होऊ शकतात. `hex::decode` एक व्हेक्टर परत करतो, परंतु `eth_stealth_addresses` लायब्ररीला अॅरे प्राप्त करायचे आहेत. [`.try_into()`](https://doc.rust-lang.org/std/convert/trait.TryInto.html#required-methods) एका मूल्याला दुसऱ्या प्रकारात रूपांतरित करते, उदाहरणार्थ, व्हेक्टरला अॅरेमध्ये.
+
+```rust
+    Some(array)
+}
+```
+
+Rust तुम्हाला फंक्शनच्या शेवटी मूल्य परत करताना [`return`](https://doc.rust-lang.org/std/keyword.return.html) कीवर्ड वापरण्याची आवश्यकता नाही.
+
+```rust
+#[wasm_bindgen]
+pub fn wasm_generate_stealth_address(stealth_address: &str) -> Option<String> {
+```
+
+हे फंक्शन एक सार्वजनिक मेटा-पत्ता प्राप्त करते, ज्यात _V<sub>pub</sub>_ आणि _K<sub>pub</sub>_ दोन्ही समाविष्ट आहेत. ते गुप्त पत्ता, प्रकाशित करण्यासाठी सार्वजनिक की (_R<sub>pub</sub>_), आणि एक-बाइट स्कॅन मूल्य परत करते जे ॲलिसच्या मालकीचे कोणते प्रकाशित पत्ते असू शकतात हे ओळखण्यास गती देते.
+
+स्कॅन मूल्य सामायिक गुप्त (_S = GR<sub>priv</sub>V<sub>priv</sub>_) चा भाग आहे. हे मूल्य ॲलिससाठी उपलब्ध आहे, आणि ते तपासणे _f(K<sub>pub</sub>+G\*hash(S))_ प्रकाशित पत्त्याच्या बरोबर आहे की नाही हे तपासण्यापेक्षा खूप वेगवान आहे.
+
+```rust
+    let (address, r_pub, scan) = 
+        generate_stealth_address(&str_to_array::<66>(stealth_address)?);
+```
+
+आम्ही लायब्ररीचे [`generate_stealth_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_address.html) वापरतो.
+
+```rust
+    format!("{{\"address\":\"{}\",\"rPub\":\"{}\",\"scan\":\"{}\"}}",
+        encode(address),
+        encode(r_pub),
+        encode(&[scan])
+    ).into()
+}
+```
+
+JSON-एनकोडेड आउटपुट स्ट्रिंग तयार करा.
+
+```rust
+#[wasm_bindgen]
+pub fn wasm_compute_stealth_key(
+    address: &str, 
+    bill_pub_key: &str, 
+    view_private_key: &str,
+    spend_private_key: &str    
+) -> Option<String> {
+    .
+    .
+    .
+}
+```
+
+हे फंक्शन पत्त्यावरून (_R<sub>priv</sub>_) पैसे काढण्यासाठी खाजगी की मोजण्यासाठी लायब्ररीच्या [`compute_stealth_key`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.compute_stealth_key.html) चा वापर करते. या गणनेसाठी ही मूल्ये आवश्यक आहेत:
+
+- पत्ता (_पत्ता=f(P<sub>pub</sub>)_)
+- बिलद्वारे तयार केलेली सार्वजनिक की (_R<sub>pub</sub>_)
+- पाहण्याची खाजगी की (_V<sub>priv</sub>_)
+- खर्च करण्याची खाजगी की (_K<sub>priv</sub>_)
+
+```rust
+#[wasm_bindgen(start)]
+```
+
+[`#[wasm_bindgen(start)]`](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/on-rust-exports/start.html) निर्दिष्ट करते की WASM कोड सुरू झाल्यावर फंक्शन कार्यान्वित केले जाते.
+
+```rust
+pub fn main() {
+    console_error_panic_hook::set_once();
+}
+```
+
+हा कोड निर्दिष्ट करतो की पॅनिक आउटपुट JavaScript कन्सोलवर पाठवले जावे. ते प्रत्यक्षात पाहण्यासाठी, ॲप्लिकेशन वापरा आणि बिलला एक अवैध मेटा-पत्ता द्या (फक्त एक हेक्साडेसिमल अंक बदला). तुम्हाला JavaScript कन्सोलमध्ये ही त्रुटी दिसेल:
+
+```
+rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/subtle-2.6.1/src/lib.rs:701:9:
+assertion `left == right` failed
+  left: 0
+ right: 1
+```
+
+त्यानंतर स्टॅक ट्रेस येईल. नंतर बिलला वैध मेटा-पत्ता द्या, आणि ॲलिसला एकतर अवैध पत्ता किंवा अवैध सार्वजनिक की द्या. तुम्हाला ही त्रुटी दिसेल:
+
+```
+rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/eth-stealth-addresses-0.1.0/src/lib.rs:78:9:
+keys do not generate stealth address
+```
+
+पुन्हा, त्यानंतर स्टॅक ट्रेस येईल.
+
+#### वापरकर्ता इंटरफेस {#ui}
+
+वापरकर्ता इंटरफेस [React](https://react.dev/) वापरून लिहिलेला आहे आणि [Vite](https://vite.dev/) द्वारे सर्व्ह केला जातो. तुम्ही [या ट्यूटोरियल](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/) चा वापर करून त्यांच्याबद्दल शिकू शकता. येथे [WAGMI](https://wagmi.sh/) ची गरज नाही कारण आम्ही थेट ब्लॉकचेन किंवा वॉलेटशी संवाद साधत नाही.
+
+वापरकर्ता इंटरफेसचा एकमेव अस्पष्ट भाग म्हणजे WASM कनेक्टिव्हिटी. हे कसे कार्य करते ते येथे आहे.
+
+**`vite.config.js`**
+
+या फाइलमध्ये [Vite कॉन्फिगरेशन](https://vite.dev/config/) आहे.
+
+```js
+import { defineConfig } from 'vite'
+import react from '@vitejs/plugin-react'
+import wasm from "vite-plugin-wasm";
+
+// https://vite.dev/config/
+export default defineConfig({
+  plugins: [react(), wasm()],
+})
+```
+
+आम्हाला दोन Vite प्लगइनची आवश्यकता आहे: [react](https://www.npmjs.com/package/@vitejs/plugin-react) आणि [wasm](https://github.com/Menci/vite-plugin-wasm#readme).
+
+**`App.jsx`**
+
+ही फाइल ॲप्लिकेशनचा मुख्य घटक आहे. हे एक कंटेनर आहे ज्यात दोन घटक आहेत: `Alice` आणि `Bill`, त्या वापरकर्त्यांसाठी वापरकर्ता इंटरफेस. WASM साठी संबंधित भाग म्हणजे इनिशियलायझेशन कोड.
+
+```jsx
+import init from './rust-wasm/pkg/rust_wasm.js'
+```
+
+जेव्हा आपण [`wasm-pack`](https://rustwasm.github.io/docs/wasm-pack/) वापरतो, तेव्हा ते दोन फाइल्स तयार करते ज्या आपण येथे वापरतो: प्रत्यक्ष कोड असलेली एक wasm फाइल (येथे, `src/rust-wasm/pkg/rust_wasm_bg.wasm`) आणि ते वापरण्यासाठी व्याख्या असलेली एक JavaScript फाइल (येथे, `src/rust_wasm/pkg/rust_wasm.js`). त्या JavaScript फाइलचा डीफॉल्ट एक्सपोर्ट हा कोड आहे जो WASM सुरू करण्यासाठी चालवणे आवश्यक आहे.
+
+```jsx
+function App() {
+    .
+    .
+    .
+  useEffect(() => {
+    const loadWasm = async () => {
+      try {
+        await init();
+        setWasmReady(true)
+      } catch (err) {
+        console.error('Error loading wasm:', err)
+        alert("Wasm error: " + err)
+      }
+    }
+
+    loadWasm()
+    }, []
+  )
+```
+
+[`useEffect` हुक](https://react.dev/reference/react/useEffect) तुम्हाला एक फंक्शन निर्दिष्ट करू देतो जे स्टेट व्हेरिएबल्स बदलल्यावर कार्यान्वित होते. येथे, स्टेट व्हेरिएबल्सची सूची रिकामी (`[]`) आहे, त्यामुळे हे फंक्शन पृष्ठ लोड झाल्यावर फक्त एकदाच कार्यान्वित होते.
+
+इफेक्ट फंक्शन त्वरित परत आले पाहिजे. असिंक्रोनस कोड वापरण्यासाठी, जसे की WASM `init` (ज्याला `.wasm` फाइल लोड करावी लागते आणि त्यामुळे वेळ लागतो) आम्ही एक अंतर्गत [`async`](https://en.wikipedia.org/wiki/Async/await) फंक्शन परिभाषित करतो आणि ते `await` शिवाय चालवतो.
+
+**`Bill.jsx`**
+
+हा बिलसाठी वापरकर्ता इंटरफेस आहे. त्यात एकच क्रिया आहे, ॲलिसने प्रदान केलेल्या गुप्त मेटा-पत्त्यावर आधारित पत्ता तयार करणे.
+
+```jsx
+import { wasm_generate_stealth_address } from './rust-wasm/pkg/rust_wasm.js'
+```
+
+डीफॉल्ट एक्सपोर्ट व्यतिरिक्त, `wasm-pack` द्वारे तयार केलेला JavaScript कोड WASM कोडमधील प्रत्येक फंक्शनसाठी एक फंक्शन एक्सपोर्ट करतो.
+
+```jsx
+            <button onClick={() => {
+              setPublicAddress(JSON.parse(wasm_generate_stealth_address(stealthMetaAddress)))
+            }}>
+```
+
+WASM फंक्शन्स कॉल करण्यासाठी, आम्ही फक्त `wasm-pack` द्वारे तयार केलेल्या JavaScript फाइलद्वारे एक्सपोर्ट केलेले फंक्शन कॉल करतो.
+
+**`Alice.jsx`**
+
+`Alice.jsx` मधील कोड समान आहे, फक्त ॲलिसच्या दोन क्रिया आहेत:
+
+- एक मेटा-पत्ता तयार करा
+- बिलने प्रकाशित केलेल्या पत्त्यासाठी खाजगी की मिळवा
+
+## निष्कर्ष {#conclusion}
+
+गुप्त पत्ते हे रामबाण उपाय नाहीत; ते [योग्यरित्या वापरले](#go-wrong) पाहिजेत. परंतु योग्यरित्या वापरल्यास, ते सार्वजनिक ब्लॉकचेनवर गोपनीयता सक्षम करू शकतात.
+
+[माझ्या कामाबद्दल अधिक माहितीसाठी येथे पहा](https://cryptodocguy.pro/).
\ No newline at end of file
diff --git a/public/content/translations/mr/developers/tutorials/the-graph-fixing-web3-data-querying/index.md b/public/content/translations/mr/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
new file mode 100644
index 00000000000..8bbb8535dbb
--- /dev/null
+++ b/public/content/translations/mr/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
@@ -0,0 +1,314 @@
+---
+title: "द ग्राफ: Web3 डेटा क्वेरींग दुरुस्त करणे"
+description: "ब्लॉकचेन एका डेटाबेससारखे आहे पण SQL शिवाय. सर्व डेटा तिथे आहे, पण त्यावर प्रवेश करण्याचा कोणताही मार्ग नाही. मी तुम्हाला दाखवतो की द ग्राफ आणि GraphQL वापरून हे कसे दुरुस्त करायचे."
+author: Markus Waas
+lang: mr
+tags:
+  [
+    "सॉलिडिटी",
+    "स्मार्ट कॉन्ट्रॅक्ट",
+    "querying",
+    "द ग्राफ",
+    "react"
+  ]
+skill: intermediate
+published: 2020-09-06
+source: soliditydeveloper.com
+sourceUrl: https://soliditydeveloper.com/thegraph
+---
+
+यावेळी आपण द ग्राफवर अधिक बारकाईने नजर टाकूया जे गेल्या वर्षात dapps विकसित करण्यासाठी स्टँडर्ड स्टॅकचा एक भाग बनले आहे. चला आधी पाहूया की आपण पारंपारिक पद्धतीने गोष्टी कशा करतो...
+
+## द ग्राफ शिवाय... {#without-the-graph}
+
+तर, उदाहरणासाठी आपण एक सोपे उदाहरण घेऊया. आपल्या सर्वांना गेम्स आवडतात, म्हणून एका साध्या गेमची कल्पना करा जिथे वापरकर्ते बेट लावतात:
+
+```solidity
+pragma solidity 0.7.1;
+
+contract Game {
+    uint256 totalGamesPlayerWon = 0;
+    uint256 totalGamesPlayerLost = 0;
+    event BetPlaced(address player, uint256 value, bool hasWon);
+
+    function placeBet() external payable {
+        bool hasWon = evaluateBetForPlayer(msg.sender);
+
+        if (hasWon) {
+            (bool success, ) = msg.sender.call{ value: msg.value * 2 }('');
+            require(success, "हस्तांतरण अयशस्वी झाले");
+            totalGamesPlayerWon++;
+        } else {
+            totalGamesPlayerLost++;
+        }
+
+        emit BetPlaced(msg.sender, msg.value, hasWon);
+    }
+}
+```
+
+आता समजा आपल्या dapp मध्ये, आपल्याला एकूण बेट्स, एकूण हरलेले/जिंकलेले गेम्स दाखवायचे आहेत आणि जेव्हा कोणी पुन्हा खेळेल तेव्हा ते अपडेट करायचे आहे. यासाठी दृष्टिकोन असा असेल:
+
+1. `totalGamesPlayerWon` फेच करा.
+2. `totalGamesPlayerLost` फेच करा.
+3. `BetPlaced` इव्हेंट्सला सबस्क्राइब करा.
+
+आपण उजवीकडे दाखवल्याप्रमाणे [Web3 मधील इव्हेंट](https://docs.web3js.org/api/web3/class/Contract#events) ऐकू शकतो, परंतु यासाठी बरीच प्रकरणे हाताळण्याची आवश्यकता आहे.
+
+```solidity
+GameContract.events.BetPlaced({
+    fromBlock: 0
+}, function(error, event) { console.log(event); })
+.on('data', function(event) {
+    // इव्हेंट फायर झाला
+})
+.on('changed', function(event) {
+    // इव्हेंट पुन्हा काढला गेला
+})
+.on('error', function(error, receipt) {
+    // tx नाकारले
+});
+```
+
+आता हे आपल्या साध्या उदाहरणासाठी काही प्रमाणात ठीक आहे. पण समजा आपल्याला आता फक्त सध्याच्या खेळाडूसाठी हरलेल्या/जिंकलेल्या बेट्सची रक्कम दाखवायची आहे. ठीक आहे, आपले नशीब खराब आहे, तुम्ही एक नवीन कॉन्ट्रॅक्ट तैनात करणे चांगले आहे जे ती मूल्ये संग्रहित करते आणि त्यांना फेच करते. आणि आता एका अधिक गुंतागुंतीच्या स्मार्ट कॉन्ट्रॅक्ट आणि dapp ची कल्पना करा, गोष्टी पटकन गोंधळात टाकू शकतात.
+
+![कोणीही फक्त क्वेरी करू शकत नाही](./one-does-not-simply-query.jpg)
+
+तुम्ही पाहू शकता की हे इष्टतम कसे नाही:
+
+- आधीच तैनात केलेल्या कॉन्ट्रॅक्ट्ससाठी काम करत नाही.
+- ती मूल्ये संग्रहित करण्यासाठी अतिरिक्त गॅस खर्च.
+- एका Ethereum नोडसाठी डेटा फेच करण्यासाठी दुसऱ्या कॉलची आवश्यकता आहे.
+
+![हे पुरेसे चांगले नाही](./not-good-enough.jpg)
+
+आता एका चांगल्या समाधानाकडे पाहूया.
+
+## मी तुम्हाला GraphQL ची ओळख करून देतो {#let-me-introduce-to-you-graphql}
+
+प्रथम GraphQL बद्दल बोलूया, जे मूळतः फेसबुकद्वारे डिझाइन आणि अंमलात आणले गेले होते. तुम्ही पारंपारिक REST API मॉडेलशी परिचित असाल. आता त्याऐवजी कल्पना करा की तुम्ही तुम्हाला हव्या असलेल्या डेटासाठी एक क्वेरी लिहू शकता:
+
+![GraphQL API विरुद्ध REST API](./graphql.jpg)
+
+![](./graphql-query.gif)
+
+दोन प्रतिमा बऱ्यापैकी GraphQL चे सार दर्शवतात. उजवीकडील क्वेरीसह आपण आपल्याला नक्की कोणता डेटा हवा आहे हे परिभाषित करू शकतो, त्यामुळे तिथे आपल्याला एकाच विनंतीत सर्वकाही मिळते आणि आपल्याला जे हवे आहे त्यापेक्षा जास्त काही नाही. एक GraphQL सर्व्हर आवश्यक असलेला सर्व डेटा फेच करणे हाताळतो, त्यामुळे फ्रंटएंड ग्राहक बाजूसाठी वापरणे अविश्वसनीयपणे सोपे आहे. तुम्हाला स्वारस्य असल्यास, सर्व्हर क्वेरी नक्की कशी हाताळतो याचे [हे एक छान स्पष्टीकरण आहे](https://www.apollographql.com/blog/graphql-explained).
+
+आता त्या ज्ञानासह, चला अखेरीस ब्लॉकचेन क्षेत्रात आणि द ग्राफमध्ये उडी घेऊया.
+
+## द ग्राफ काय आहे? {#what-is-the-graph}
+
+ब्लॉकचेन एक विकेंद्रित डेटाबेस आहे, पण सामान्यतः जे घडते त्याच्या विपरीत, आपल्याकडे या डेटाबेससाठी क्वेरी भाषा नाही. डेटा पुनर्प्राप्त करण्याचे उपाय वेदनादायक किंवा पूर्णपणे अशक्य आहेत. द ग्राफ हा ब्लॉकचेन डेटाची अनुक्रमणिका आणि क्वेरी करण्यासाठी एक विकेंद्रित प्रोटोकॉल आहे. आणि तुम्ही अंदाज लावला असेलच, ते क्वेरी भाषा म्हणून GraphQL वापरत आहे.
+
+![द ग्राफ](./thegraph.png)
+
+काहीतरी समजण्यासाठी उदाहरणे नेहमीच सर्वोत्तम असतात, म्हणून चला आपल्या GameContract उदाहरणासाठी द ग्राफ वापरूया.
+
+## सबग्राफ कसा तयार करावा {#how-to-create-a-subgraph}
+
+डेटाची अनुक्रमणिका कशी करावी याच्या व्याख्येला सबग्राफ म्हणतात. यासाठी तीन घटक आवश्यक आहेत:
+
+1. मॅनिफेस्ट (`subgraph.yaml`)
+2. स्कीमा (`schema.graphql`)
+3. मॅपिंग (`mapping.ts`)
+
+### मॅनिफेस्ट (`subgraph.yaml`) {#manifest}
+
+मॅनिफेस्ट ही आपली कॉन्फिगरेशन फाईल आहे आणि ती परिभाषित करते:
+
+- कोणत्या स्मार्ट कॉन्ट्रॅक्ट्सची अनुक्रमणिका करायची (पत्ता, नेटवर्क, ABI...)
+- कोणते इव्हेंट्स ऐकायचे
+- ऐकण्यासाठी इतर गोष्टी जसे की फंक्शन कॉल्स किंवा ब्लॉक्स
+- कॉल केली जात असलेली मॅपिंग फंक्शन्स (खाली `mapping.ts` पहा)
+
+तुम्ही येथे अनेक कॉन्ट्रॅक्ट्स आणि हँडलर्स परिभाषित करू शकता. एक सामान्य सेटअप Hardhat प्रोजेक्टच्या आत एक सबग्राफ फोल्डर असेल, त्याच्या स्वतःच्या रेपॉजिटरीसह. मग तुम्ही सहजपणे ABI चा संदर्भ घेऊ शकता.
+
+सोयीसाठी तुम्ही मस्टॅशसारखे टेम्पलेट टूल देखील वापरू शकता. मग तुम्ही एक `subgraph.template.yaml` तयार करता आणि नवीनतम डिप्लॉयमेंट्सवर आधारित पत्ते घालता. अधिक प्रगत उदाहरण सेटअपसाठी, उदाहरणार्थ [Aave सबग्राफ रेपो](https://github.com/aave/aave-protocol/tree/master/thegraph) पहा.
+
+आणि संपूर्ण डॉक्युमेंटेशन [येथे](https://thegraph.com/docs/en/developing/creating-a-subgraph/#the-subgraph-manifest) पाहिले जाऊ शकते.
+
+```yaml
+specVersion: 0.0.1
+description: Ethereum वर बेट्स लावणे
+repository: - GitHub लिंक -
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum/contract
+    name: GameContract
+    network: mainnet
+    source:
+      address: '0x2E6454...cf77eC'
+      abi: GameContract
+      startBlock: 6175244
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.1
+      language: wasm/assemblyscript
+      entities:
+        - GameContract
+      abis:
+        - name: GameContract
+          file: ../build/contracts/GameContract.json
+      eventHandlers:
+        - event: PlacedBet(address,uint256,bool)
+          handler: handleNewBet
+      file: ./src/mapping.ts
+```
+
+### स्कीमा (`schema.graphql`) {#schema}
+
+स्कीमा ही GraphQL डेटाची व्याख्या आहे. हे तुम्हाला कोणत्या एंटिटी अस्तित्वात आहेत आणि त्यांचे प्रकार परिभाषित करण्याची परवानगी देईल. द ग्राफ मधील समर्थित प्रकार आहेत
+
+- बाइट्स
+- ID
+- स्ट्रिंग
+- बूलियन
+- इंट
+- बिगइंट
+- बिगडेसिमल
+
+तुम्ही संबंध परिभाषित करण्यासाठी एंटिटीचा प्रकार म्हणून देखील वापरू शकता. आपल्या उदाहरणात आपण खेळाडूपासून बेट्सपर्यंत 1-ते-अनेक संबंध परिभाषित करतो. ! याचा अर्थ मूल्य रिक्त असू शकत नाही. संपूर्ण डॉक्युमेंटेशन [येथे](https://thegraph.com/docs/en/developing/creating-a-subgraph/#the-subgraph-manifest) पाहिले जाऊ शकते.
+
+```graphql
+type Bet @entity {
+  id: ID!
+  player: Player!
+  playerHasWon: Boolean!
+  time: Int!
+}
+
+type Player @entity {
+  id: ID!
+  totalPlayedCount: Int
+  hasWonCount: Int
+  hasLostCount: Int
+  bets: [Bet]!
+}
+```
+
+### मॅपिंग (`mapping.ts`) {#mapping}
+
+द ग्राफमधील मॅपिंग फाईल येणाऱ्या इव्हेंट्सला एंटिटीमध्ये रूपांतरित करणारी आपली फंक्शन्स परिभाषित करते. हे AssemblyScript मध्ये लिहिलेले आहे, जे Typescript चा उपसंच आहे. याचा अर्थ मॅपिंगच्या अधिक कार्यक्षम आणि पोर्टेबल अंमलबजावणीसाठी ते WASM (WebAssembly) मध्ये संकलित केले जाऊ शकते.
+
+तुम्हाला `subgraph.yaml` फाईलमध्ये नावाच्या प्रत्येक फंक्शनला परिभाषित करणे आवश्यक आहे, त्यामुळे आपल्या बाबतीत आपल्याला फक्त एकाची आवश्यकता आहे: `handleNewBet`. आपण प्रथम प्रेषकाच्या पत्त्यावरून आयडी म्हणून Player एंटिटी लोड करण्याचा प्रयत्न करतो. जर ते अस्तित्वात नसेल, तर आपण एक नवीन एंटिटी तयार करतो आणि ती प्रारंभिक मूल्यांनी भरतो.
+
+मग आपण एक नवीन Bet एंटिटी तयार करतो. यासाठी आयडी `event.transaction.hash.toHex() + "-" + event.logIndex.toString()` असेल, जे नेहमी एक अद्वितीय मूल्य सुनिश्चित करते. फक्त हॅश वापरणे पुरेसे नाही कारण कोणीतरी स्मार्ट कॉन्ट्रॅक्टद्वारे एकाच व्यवहारात placeBet फंक्शनला अनेक वेळा कॉल करू शकते.
+
+शेवटी आपण सर्व डेटासह Player एंटिटी अपडेट करू शकतो. अॅरेमध्ये थेट पुश केले जाऊ शकत नाही, परंतु येथे दाखवल्याप्रमाणे अपडेट करणे आवश्यक आहे. आपण बेटचा संदर्भ देण्यासाठी आयडी वापरतो. आणि एंटिटी संग्रहित करण्यासाठी शेवटी `.save()` आवश्यक आहे.
+
+संपूर्ण डॉक्युमेंटेशन येथे पाहिले जाऊ शकते: https://thegraph.com/docs/en/developing/creating-a-subgraph/#writing-mappings. तुम्ही मॅपिंग फाईलमध्ये लॉगिंग आउटपुट देखील जोडू शकता, [येथे](https://thegraph.com/docs/en/subgraphs/developing/creating/graph-ts/api/#api-reference) पहा.
+
+```typescript
+import { Bet, Player } from "../generated/schema"
+import { PlacedBet } from "../generated/GameContract/GameContract"
+
+export function handleNewBet(event: PlacedBet): void {
+  let player = Player.load(event.transaction.from.toHex())
+
+  if (player == null) {
+    // अद्याप अस्तित्वात नसल्यास तयार करा
+    player = new Player(event.transaction.from.toHex())
+    player.bets = new Array<string>(0)
+    player.totalPlayedCount = 0
+    player.hasWonCount = 0
+    player.hasLostCount = 0
+  }
+
+  let bet = new Bet(
+    event.transaction.hash.toHex() + "-" + event.logIndex.toString()
+  )
+  bet.player = player.id
+  bet.playerHasWon = event.params.hasWon
+  bet.time = event.block.timestamp
+  bet.save()
+
+  player.totalPlayedCount++
+  if (event.params.hasWon) {
+    player.hasWonCount++
+  } else {
+    player.hasLostCount++
+  }
+
+  // अॅरे अशाप्रकारे अपडेट करा
+  let bets = player.bets
+  bets.push(bet.id)
+  player.bets = bets
+
+  player.save()
+}
+```
+
+## फ्रंटएंडमध्ये वापरणे {#using-it-in-the-frontend}
+
+Apollo Boost सारखे काहीतरी वापरून, तुम्ही तुमच्या React dapp (किंवा Apollo-Vue) मध्ये द ग्राफ सहजपणे समाकलित करू शकता. विशेषतः React हुक्स आणि Apollo वापरताना, तुमच्या कंपोनेंटमध्ये एकच GraphQL क्वेरी लिहिण्याइतके डेटा फेच करणे सोपे आहे. एक सामान्य सेटअप यासारखा दिसू शकतो:
+
+```javascript
+// सर्व सबग्राफ पहा: https://thegraph.com/explorer/
+const client = new ApolloClient({
+  uri: "{{ subgraphUrl }}",
+})
+
+ReactDOM.render(
+  <ApolloProvider client={client}>
+    <App />
+  </ApolloProvider>,
+  document.getElementById("root")
+)
+```
+
+आणि आता आपण उदाहरणार्थ अशी क्वेरी लिहू शकतो. हे आपल्याला फेच करून देईल
+
+- सध्याचा वापरकर्ता किती वेळा जिंकला आहे
+- सध्याचा वापरकर्ता किती वेळा हरला आहे
+- त्यांच्या सर्व मागील बेट्सच्या टाइमस्टॅम्पची यादी
+
+GraphQL सर्व्हरला केलेल्या एकाच विनंतीत सर्वकाही.
+
+```javascript
+const myGraphQlQuery = gql`
+    players(where: { id: $currentUser }) {
+      totalPlayedCount
+      hasWonCount
+      hasLostCount
+      bets {
+        time
+      }
+    }
+`
+
+const { loading, error, data } = useQuery(myGraphQlQuery)
+
+React.useEffect(() => {
+  if (!loading && !error && data) {
+    console.log({ data })
+  }
+}, [loading, error, data])
+```
+
+![जादू](./magic.jpg)
+
+पण आपण कोड्यातील एक शेवटचा तुकडा विसरत आहोत आणि तो म्हणजे सर्व्हर. तुम्ही ते स्वतः चालवू शकता किंवा होस्टेड सेवा वापरू शकता.
+
+## द ग्राफ सर्व्हर {#the-graph-server}
+
+### ग्राफ एक्सप्लोरर: होस्टेड सेवा {#graph-explorer-the-hosted-service}
+
+सर्वात सोपा मार्ग म्हणजे होस्टेड सेवा वापरणे. सबग्राफ तैनात करण्यासाठी [येथील](https://thegraph.com/docs/en/deploying/deploying-a-subgraph-to-hosted/) सूचनांचे अनुसरण करा. अनेक प्रकल्पांसाठी तुम्ही प्रत्यक्षात [एक्सप्लोरर](https://thegraph.com/explorer/) मध्ये विद्यमान सबग्राफ शोधू शकता.
+
+![द ग्राफ-एक्सप्लोरर](./thegraph-explorer.png)
+
+### तुमचा स्वतःचा नोड चालवणे {#running-your-own-node}
+
+वैकल्पिकरित्या, तुम्ही तुमचा स्वतःचा नोड चालवू शकता. डॉक्युमेंटेशन [येथे](https://github.com/graphprotocol/graph-node#quick-start). हे करण्याचे एक कारण होस्टेड सेवेद्वारे समर्थित नसलेले नेटवर्क वापरणे असू शकते. सध्या समर्थित नेटवर्क्स [येथे](https://thegraph.com/docs/en/developing/supported-networks/) आढळू शकतात.
+
+## विकेंद्रित भविष्य {#the-decentralized-future}
+
+GraphQL नवीन येणाऱ्या इव्हेंट्ससाठी स्ट्रीम्सला देखील समर्थन देते. हे ग्राफवर [सबस्ट्रीम्स](https://thegraph.com/docs/en/substreams/) द्वारे समर्थित आहेत, जे सध्या ओपन बीटामध्ये आहेत.
+
+[2021](https://thegraph.com/blog/mainnet-migration/) मध्ये द ग्राफने विकेंद्रित अनुक्रमणिका नेटवर्कमध्ये संक्रमणाची सुरुवात केली. तुम्ही या विकेंद्रित अनुक्रमणिका नेटवर्कच्या आर्किटेक्चरबद्दल अधिक [येथे](https://thegraph.com/docs/en/network/explorer/) वाचू शकता.
+
+दोन प्रमुख पैलू आहेत:
+
+1. वापरकर्ते क्वेरीसाठी इंडेक्सर्सना पैसे देतात.
+2. इंडेक्सर्स ग्राफ टोकन्स (GRT) स्टेक करतात.
diff --git a/public/content/translations/mr/developers/tutorials/token-integration-checklist/index.md b/public/content/translations/mr/developers/tutorials/token-integration-checklist/index.md
new file mode 100644
index 00000000000..9955b7a9383
--- /dev/null
+++ b/public/content/translations/mr/developers/tutorials/token-integration-checklist/index.md
@@ -0,0 +1,86 @@
+---
+title: "टोकन एकत्रीकरण तपासणीसूची"
+description: "टोकन्ससोबत संवाद साधताना विचारात घेण्यासारख्या गोष्टींची एक तपासणीसूची"
+author: "Trailofbits"
+lang: mr
+tags:
+  [
+    "सॉलिडिटी",
+    "स्मार्ट कॉन्ट्रॅक्ट",
+    "सुरक्षा",
+    "tokens"
+  ]
+skill: intermediate
+published: 2020-08-13
+source: Building secure contracts
+sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/token_integration.md
+---
+
+अनियंत्रित टोकन्ससोबत संवाद साधताना ही तपासणीसूची पाळा. प्रत्येक बाबीशी संबंधित धोके तुम्ही समजून घेतले आहेत याची खात्री करा आणि या नियमांमधील कोणत्याही अपवादांचे समर्थन करा.
+
+सोयीसाठी, सर्व Slither [युटिलिटीज](https://github.com/crytic/slither#tools) थेट टोकन ॲड्रेसवर चालवल्या जाऊ शकतात, जसे की:
+
+[Slither वापरण्याचे ट्युटोरियल](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
+
+```bash
+slither-check-erc 0xdac17f958d2ee523a2206206994597c13d831ec7 TetherToken
+```
+
+ही तपासणीसूची फॉलो करण्यासाठी, तुम्हाला टोकनसाठी Slither कडून हा आउटपुट हवा असेल:
+
+```bash
+- slither-check-erc [target] [contractName] [optional: --erc ERC_NUMBER]
+- slither [target] --print human-summary
+- slither [target] --print contract-summary
+- slither-prop . --contract ContractName # कॉन्फिगरेशन आवश्यक आहे, आणि Echidna व Manticore चा वापर
+```
+
+## सामान्य विचार {#general-considerations}
+
+- **कॉन्ट्रॅक्टचे सुरक्षा पुनरावलोकन झाले आहे.** ज्या कॉन्ट्रॅक्ट्सचे सुरक्षा पुनरावलोकन झालेले नाही त्यांच्याशी संवाद साधणे टाळा. मूल्यांकनाची लांबी (उर्फ "प्रयत्नांची पातळी"), सुरक्षा फर्मची प्रतिष्ठा, आणि निष्कर्षांची संख्या व तीव्रता तपासा.
+- **तुम्ही डेव्हलपर्सशी संपर्क साधला आहे.** तुम्हाला त्यांच्या टीमला एखाद्या घटनेबद्दल सतर्क करण्याची आवश्यकता असू शकते. [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts) वर योग्य संपर्क शोधा.
+- **त्यांच्याकडे गंभीर घोषणांसाठी एक सुरक्षा मेलिंग लिस्ट आहे.** त्यांच्या टीमने वापरकर्त्यांना (तुमच्यासारख्या!) सल्ला द्यावा. जेव्हा गंभीर समस्या आढळतात किंवा जेव्हा अपग्रेड्स होतात.
+
+## ERC अनुरूपता {#erc-conformity}
+
+Slither मध्ये एक युटिलिटी, [slither-check-erc](https://github.com/crytic/slither/wiki/ERC-Conformance) समाविष्ट आहे, जी अनेक संबंधित ERC मानकांशी टोकनच्या अनुरूपतेचे पुनरावलोकन करते. हे तपासण्यासाठी slither-check-erc वापरा:
+
+- **Transfer आणि transferFrom एक बुलियन परत करतात.** अनेक टोकन्स या फंक्शन्सवर बुलियन परत करत नाहीत. परिणामी, कॉन्ट्रॅक्टमधील त्यांचे कॉल्स अयशस्वी होऊ शकतात.
+- **जर वापरले असेल तर name, decimals, आणि symbol फंक्शन्स उपस्थित आहेत.** ही फंक्शन्स ERC20 मानकांमध्ये ऐच्छिक आहेत आणि उपस्थित नसू शकतात.
+- **Decimals एक uint8 परत करते.** अनेक टोकन्स चुकीने uint256 परत करतात. असे असल्यास, परत केलेले मूल्य 255 च्या खाली आहे याची खात्री करा.
+- **टोकन ज्ञात [ERC20 रेस कंडीशन](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729) कमी करते.** ERC20 मानकांमध्ये एक ज्ञात ERC20 रेस कंडीशन आहे जी हल्लेखोरांना टोकन चोरण्यापासून रोखण्यासाठी कमी करणे आवश्यक आहे.
+- **टोकन एक ERC777 टोकन नाही आणि transfer व transferFrom मध्ये कोणतेही बाह्य फंक्शन कॉल नाही.** ट्रान्सफर फंक्शन्समधील बाह्य कॉल्समुळे रीएन्ट्रन्सी होऊ शकते.
+
+Slither मध्ये एक युटिलिटी, [slither-prop](https://github.com/crytic/slither/wiki/Property-generation) समाविष्ट आहे, जी युनिट टेस्ट्स आणि सुरक्षा गुणधर्म निर्माण करते जे अनेक सामान्य ERC त्रुटी शोधू शकतात. हे तपासण्यासाठी slither-prop वापरा:
+
+- **कॉन्ट्रॅक्ट slither-prop मधील सर्व युनिट टेस्ट्स आणि सुरक्षा गुणधर्मांमध्ये पास होतो.** निर्माण केलेल्या युनिट टेस्ट्स चालवा, नंतर [Echidna](https://github.com/crytic/echidna) आणि [Manticore](https://manticore.readthedocs.io/en/latest/verifier.html) सह गुणधर्म तपासा.
+
+शेवटी, काही विशिष्ट वैशिष्ट्ये आहेत जी आपोआप ओळखणे कठीण आहे. या परिस्थितींसाठी स्वतः तपासा:
+
+- **Transfer आणि transferFrom ने फी घेऊ नये.** डिफ्लेशनरी टोकन्समुळे अनपेक्षित वर्तन होऊ शकते.
+- **टोकनमधून मिळणारे संभाव्य व्याज विचारात घेतले जाते.** काही टोकन्स टोकन धारकांना व्याज वितरित करतात. जर ते विचारात घेतले नाही तर हे व्याज कॉन्ट्रॅक्टमध्ये अडकू शकते.
+
+## कॉन्ट्रॅक्ट रचना {#contract-composition}
+
+- **कॉन्ट्रॅक्ट अनावश्यक गुंतागुंत टाळतो.** टोकन एक साधा कॉन्ट्रॅक्ट असावा; गुंतागुंतीच्या कोड असलेल्या टोकनसाठी उच्च दर्जाचे पुनरावलोकन आवश्यक आहे. गुंतागुंतीचा कोड ओळखण्यासाठी Slither चा [human-summary printer](https://github.com/crytic/slither/wiki/Printer-documentation#human-summary) वापरा.
+- **कॉन्ट्रॅक्ट SafeMath वापरतो.** जे कॉन्ट्रॅक्ट्स SafeMath वापरत नाहीत त्यांना उच्च दर्जाच्या पुनरावलोकनाची आवश्यकता असते. SafeMath वापरासाठी कॉन्ट्रॅक्टची स्वतः तपासणी करा.
+- **कॉन्ट्रॅक्टमध्ये टोकनशी संबंधित नसलेले फक्त काही फंक्शन्स आहेत.** टोकनशी संबंधित नसलेले फंक्शन्स कॉन्ट्रॅक्टमध्ये समस्या असण्याची शक्यता वाढवतात. कॉन्ट्रॅक्टमध्ये वापरलेल्या कोडचे विस्तृतपणे पुनरावलोकन करण्यासाठी Slither चा [contract-summary printer](https://github.com/crytic/slither/wiki/Printer-documentation#contract-summary) वापरा.
+- **टोकनला फक्त एकच ॲड्रेस आहे.** बॅलन्स अपडेट्ससाठी अनेक एंट्री पॉइंट्स असलेले टोकन्स ॲड्रेसवर आधारित अंतर्गत बुककीपिंग तोडू शकतात (उदा., `balances[token_address][msg.sender]` वास्तविक बॅलन्स दर्शवू शकत नाही).
+
+## मालकाचे विशेषाधिकार {#owner-privileges}
+
+- **टोकन अपग्रेड करण्यायोग्य नाही.** अपग्रेड करण्यायोग्य कॉन्ट्रॅक्ट्स कालांतराने त्यांचे नियम बदलू शकतात. कॉन्ट्रॅक्ट अपग्रेड करण्यायोग्य आहे की नाही हे ठरवण्यासाठी Slither चा [human-summary printer](https://github.com/crytic/slither/wiki/Printer-documentation#contract-summary) वापरा.
+- **मालकाकडे मर्यादित मिंटिंग क्षमता आहे.** दुर्भावनापूर्ण किंवा तडजोड केलेले मालक मिंटिंग क्षमतेचा गैरवापर करू शकतात. मिंटिंग क्षमतेचे पुनरावलोकन करण्यासाठी Slither चा [human-summary printer](https://github.com/crytic/slither/wiki/Printer-documentation#contract-summary) वापरा, आणि कोडचे स्वतः पुनरावलोकन करण्याचा विचार करा.
+- **टोकन पॉज करण्यायोग्य नाही.** दुर्भावनापूर्ण किंवा तडजोड केलेले मालक पॉज करण्यायोग्य टोकन्सवर अवलंबून असलेले कॉन्ट्रॅक्ट्स अडकवू शकतात. पॉज करण्यायोग्य कोड स्वतः ओळखा.
+- **मालक कॉन्ट्रॅक्टला ब्लॅकलिस्ट करू शकत नाही.** दुर्भावनापूर्ण किंवा तडजोड केलेले मालक ब्लॅकलिस्ट असलेल्या टोकन्सवर अवलंबून असलेले कॉन्ट्रॅक्ट्स अडकवू शकतात. ब्लॅकलिस्टिंग वैशिष्ट्ये स्वतः ओळखा.
+- **टोकनमागील टीम ज्ञात आहे आणि गैरवापरासाठी जबाबदार धरले जाऊ शकते.** अज्ञात डेव्हलपमेंट टीम असलेले कॉन्ट्रॅक्ट्स, किंवा जे कायदेशीर आश्रयस्थानांमध्ये राहतात त्यांना उच्च दर्जाच्या पुनरावलोकनाची आवश्यकता असेल.
+
+## टोकनची टंचाई {#token-scarcity}
+
+टोकन टंचाईच्या समस्यांचे पुनरावलोकन करण्यासाठी स्वतः पुनरावलोकन करणे आवश्यक आहे. या परिस्थिती तपासा:
+
+- **कोणत्याही एका वापरकर्त्याकडे बहुतेक पुरवठा नाही.** जर काही वापरकर्त्यांकडे बहुतेक टोकन्स असतील, तर ते टोकनच्या पुनर्वितरणावर आधारित ऑपरेशन्सवर प्रभाव टाकू शकतात.
+- **एकूण पुरवठा पुरेसा आहे.** कमी एकूण पुरवठा असलेल्या टोकन्समध्ये सहज फेरफार केली जाऊ शकते.
+- **टोकन्स काही एक्सचेंजेसपेक्षा जास्त ठिकाणी आहेत.** जर सर्व टोकन्स एकाच एक्सचेंजमध्ये असतील, तर त्या एक्सचेंजमधील तडजोड टोकनवर अवलंबून असलेल्या कॉन्ट्रॅक्टशी तडजोड करू शकते.
+- **वापरकर्ते मोठ्या निधी किंवा फ्लॅश लोन्सशी संबंधित धोके समजतात.** टोकन बॅलन्सवर अवलंबून असलेल्या कॉन्ट्रॅक्ट्सनी मोठ्या निधी असलेल्या हल्लेखोरांचा किंवा फ्लॅश लोन्सद्वारे होणाऱ्या हल्ल्यांचा काळजीपूर्वक विचार केला पाहिजे.
+- **टोकन फ्लॅश मिंटिंगला परवानगी देत नाही.** फ्लॅश मिंटिंगमुळे बॅलन्स आणि एकूण पुरवठ्यात लक्षणीय चढ-उतार होऊ शकतात, ज्यामुळे टोकनच्या ऑपरेशनमध्ये कठोर आणि व्यापक ओव्हरफ्लो तपासणी आवश्यक होते.
diff --git a/public/content/translations/mr/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md b/public/content/translations/mr/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md
new file mode 100644
index 00000000000..e3a993289e4
--- /dev/null
+++ b/public/content/translations/mr/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md
@@ -0,0 +1,314 @@
+---
+title: "Solidity स्मार्ट कॉन्ट्रॅक्टमधून ERC-20 टोकनचे हस्तांतरण आणि मंजूरी"
+description: "Solidity वापरून एक DEX स्मार्ट कॉन्ट्रॅक्ट तयार करा जो ERC-20 टोकन हस्तांतरण आणि मंजुरी हाताळतो."
+author: "jdourlens"
+tags: [ "स्मार्ट कॉन्ट्रॅक्ट", "tokens", "सॉलिडिटी", "erc-20" ]
+skill: intermediate
+lang: mr
+published: 2020-04-07
+source: EthereumDev
+sourceUrl: https://ethereumdev.io/transfers-and-approval-or-erc20-tokens-from-a-solidity-smart-contract/
+address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+---
+
+मागील ट्युटोरियलमध्ये आपण Ethereum ब्लॉकचेनवरील [Solidity मधील ERC-20 टोकनची रचना](/developers/tutorials/understand-the-erc-20-token-smart-contract/) अभ्यासली. या लेखात आपण पाहू की Solidity भाषा वापरून टोकनसोबत संवाद साधण्यासाठी आपण स्मार्ट कॉन्ट्रॅक्टचा कसा वापर करू शकतो.
+
+या स्मार्ट कॉन्ट्रॅक्टसाठी, आम्ही एक प्रत्यक्ष डमी विकेंद्रित एक्सचेंज तयार करू जिथे वापरकर्ता आमच्या नवीन तैनात केलेल्या [ERC-20 टोकनच्या](/developers/docs/standards/tokens/erc-20/) बदल्यात ईथरचा व्यापार करू शकतो.
+
+या ट्युटोरियलसाठी आम्ही मागील ट्युटोरियलमध्ये लिहिलेला कोड आधार म्हणून वापरणार आहोत. आमचा DEX त्याच्या कन्स्ट्रक्टरमध्ये कॉन्ट्रॅक्टचा इन्स्टन्स तयार करेल आणि खालील कार्ये पार पाडेल:
+
+- टोकनची ईथरमध्ये देवाणघेवाण करणे
+- ईथरची टोकनमध्ये देवाणघेवाण करणे
+
+आपण आपला सोपा ERC20 कोडबेस जोडून आपला विकेंद्रित एक्सचेंज कोड सुरू करू:
+
+```solidity
+pragma solidity ^0.8.0;
+
+interface IERC20 {
+
+    function totalSupply() external view returns (uint256);
+    function balanceOf(address account) external view returns (uint256);
+    function allowance(address owner, address spender) external view returns (uint256);
+
+    function transfer(address recipient, uint256 amount) external returns (bool);
+    function approve(address spender, uint256 amount) external returns (bool);
+    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
+
+
+    event Transfer(address indexed from, address indexed to, uint256 value);
+    event Approval(address indexed owner, address indexed spender, uint256 value);
+}
+
+
+contract ERC20Basic is IERC20 {
+
+    string public constant name = "ERC20Basic";
+    string public constant symbol = "ERC";
+    uint8 public constant decimals = 18;
+
+
+    mapping(address => uint256) balances;
+
+    mapping(address => mapping (address => uint256)) allowed;
+
+    uint256 totalSupply_ = 10 ether;
+
+
+   constructor() {
+	balances[msg.sender] = totalSupply_;
+    }
+
+    function totalSupply() public override view returns (uint256) {
+	return totalSupply_;
+    }
+
+    function balanceOf(address tokenOwner) public override view returns (uint256) {
+        return balances[tokenOwner];
+    }
+
+    function transfer(address receiver, uint256 numTokens) public override returns (bool) {
+        require(numTokens <= balances[msg.sender]);
+        balances[msg.sender] = balances[msg.sender]-numTokens;
+        balances[receiver] = balances[receiver]+numTokens;
+        emit Transfer(msg.sender, receiver, numTokens);
+        return true;
+    }
+
+    function approve(address delegate, uint256 numTokens) public override returns (bool) {
+        allowed[msg.sender][delegate] = numTokens;
+        emit Approval(msg.sender, delegate, numTokens);
+        return true;
+    }
+
+    function allowance(address owner, address delegate) public override view returns (uint) {
+        return allowed[owner][delegate];
+    }
+
+    function transferFrom(address owner, address buyer, uint256 numTokens) public override returns (bool) {
+        require(numTokens <= balances[owner]);
+        require(numTokens <= allowed[owner][msg.sender]);
+
+        balances[owner] = balances[owner]-numTokens;
+        allowed[owner][msg.sender] = allowed[owner][msg.sender]-numTokens;
+        balances[buyer] = balances[buyer]+numTokens;
+        emit Transfer(owner, buyer, numTokens);
+        return true;
+    }
+}
+
+
+```
+
+आमचा नवीन DEX स्मार्ट कॉन्ट्रॅक्ट ERC-20 तैनात करेल आणि पुरवलेल्या सर्व गोष्टी मिळवेल:
+
+```solidity
+contract DEX {
+
+    IERC20 public token;
+
+    event Bought(uint256 amount);
+    event Sold(uint256 amount);
+
+    constructor() {
+        token = new ERC20Basic();
+    }
+
+    function buy() payable public {
+        // TODO
+    }
+
+    function sell(uint256 amount) public {
+        // TODO
+    }
+
+}
+```
+
+तर आता आपल्याकडे आपला DEX आहे आणि त्यात सर्व टोकन राखीव निधी उपलब्ध आहे. कॉन्ट्रॅक्टमध्ये दोन फंक्शन्स आहेत:
+
+- `buy`: वापरकर्ता ईथर पाठवून बदल्यात टोकन्स मिळवू शकतो
+- `sell`: वापरकर्ता ईथर परत मिळवण्यासाठी टोकन्स पाठवण्याचा निर्णय घेऊ शकतो
+
+## `buy` फंक्शन {#the-buy-function}
+
+चला `buy` फंक्शन कोड करूया. आपल्याला आधी मेसेजमध्ये किती ईथर आहे हे तपासावे लागेल आणि कॉन्ट्रॅक्ट्सकडे पुरेसे टोकन आहेत आणि मेसेजमध्ये काही ईथर आहे याची पडताळणी करावी लागेल. जर कॉन्ट्रॅक्टकडे पुरेसे टोकन असतील, तर ते वापरकर्त्याला टोकनची संख्या पाठवेल आणि `Bought` इव्हेंट उत्सर्जित करेल.
+
+लक्षात घ्या की त्रुटीच्या बाबतीत आपण `require` फंक्शन कॉल केल्यास, पाठवलेले ईथर थेट परत केले जाईल आणि वापरकर्त्याला परत दिले जाईल.
+
+गोष्टी सोप्या ठेवण्यासाठी, आम्ही फक्त 1 Wei साठी 1 टोकन एक्सचेंज करतो.
+
+```solidity
+function buy() payable public {
+    uint256 amountTobuy = msg.value;
+    uint256 dexBalance = token.balanceOf(address(this));
+    require(amountTobuy > 0, "तुम्हाला काही ईथर पाठवणे आवश्यक आहे");
+    require(amountTobuy <= dexBalance, "रिझर्व्हमध्ये पुरेसे टोकन्स नाहीत");
+    token.transfer(msg.sender, amountTobuy);
+    emit Bought(amountTobuy);
+}
+```
+
+`buy` यशस्वी झाल्यास, आपल्याला ट्रांझॅक्शनमध्ये दोन इव्हेंट दिसले पाहिजेत: टोकन `Transfer` आणि `Bought` इव्हेंट.
+
+![ट्रांझॅक्शनमधील दोन इव्हेंट: Transfer आणि Bought](./transfer-and-bought-events.png)
+
+## `sell` फंक्शन {#the-sell-function}
+
+विक्रीसाठी जबाबदार फंक्शनला आधी `approve` फंक्शन कॉल करून वापरकर्त्याकडून रकमेला मंजुरी देण्याची आवश्यकता असेल. हस्तांतरणाला मंजुरी देण्यासाठी DEX द्वारे तयार केलेल्या ERC20Basic टोकनला वापरकर्त्याद्वारे कॉल करणे आवश्यक आहे. हे साध्य करण्यासाठी प्रथम DEX कॉन्ट्रॅक्टचे `token()` फंक्शन कॉल करून तो ऍड्रेस मिळवावा लागेल जिथे DEX ने `token` नावाचा ERC20Basic कॉन्ट्रॅक्ट तैनात केला आहे. त्यानंतर आम्ही आमच्या सेशनमध्ये त्या कॉन्ट्रॅक्टचा एक इन्स्टन्स तयार करतो आणि त्याचे `approve` फंक्शन कॉल करतो. त्यानंतर आपण DEX चे `sell` फंक्शन कॉल करू शकतो आणि आपले टोकन परत ईथरसाठी स्वॅप करू शकतो. उदाहरणार्थ, इंटरऍक्टिव्ह ब्राउनी सेशनमध्ये हे असे दिसते:
+
+```python
+#### इंटरऍक्टिव्ह ब्राउनी कन्सोलमधील पायथन...
+
+# DEX तैनात करा
+dex = DEX.deploy({'from':account1})
+
+# टोकनसाठी ईथर स्वॅप करण्याकरिता `buy` फंक्शन कॉल करा
+# 1e18 म्हणजे 1 ईथर wei मध्ये दर्शवलेले
+dex.buy({'from': account2, 1e18})
+
+# ERC20 टोकनसाठी डिप्लॉयमेंट ऍड्रेस मिळवा
+# जे DEX कॉन्ट्रॅक्ट तयार करताना तैनात केले होते
+# dex.token() टोकनसाठी तैनात केलेला ऍड्रेस परत करतो
+token = ERC20Basic.at(dex.token())
+
+# टोकनचे `approve` फंक्शन कॉल करा
+# dex ऍड्रेसला स्पेंडर म्हणून मंजूर करा
+# आणि ते तुमचे किती टोकन खर्च करू शकते
+token.approve(dex.address, 3e18, {'from':account2})
+
+```
+
+मग जेव्हा `sell` फंक्शन कॉल केले जाते, तेव्हा आम्ही कॉलरच्या ऍड्रेसवरून कॉन्ट्रॅक्ट ऍड्रेसवर हस्तांतरण यशस्वी झाले आहे की नाही हे तपासू आणि नंतर ईथर कॉलरच्या ऍड्रेसवर परत पाठवू.
+
+```solidity
+function sell(uint256 amount) public {
+    require(amount > 0, "तुम्हाला किमान काही टोकन्स विकणे आवश्यक आहे");
+    uint256 allowance = token.allowance(msg.sender, address(this));
+    require(allowance >= amount, "टोकन भत्ता तपासा");
+    token.transferFrom(msg.sender, address(this), amount);
+    payable(msg.sender).transfer(amount);
+    emit Sold(amount);
+}
+```
+
+जर सर्व काही व्यवस्थित चालले, तर तुम्हाला ट्रांझॅक्शनमध्ये 2 इव्हेंट (`Transfer` आणि `Sold`) दिसले पाहिजेत आणि तुमचा टोकन बॅलन्स आणि ईथर बॅलन्स अपडेट झालेला दिसेल.
+
+![ट्रांझॅक्शनमधील दोन इव्हेंट: Transfer आणि Sold](./transfer-and-sold-events.png)
+
+<Divider />
+
+या ट्युटोरियलमधून आपण ERC-20 टोकनचा बॅलन्स आणि भत्ता कसा तपासावा आणि इंटरफेस वापरून ERC20 स्मार्ट कॉन्ट्रॅक्टचे `Transfer` आणि `TransferFrom` कसे कॉल करावे हे पाहिले.
+
+एकदा तुम्ही व्यवहार केल्यावर, तुमच्याकडे तुमच्या करारासाठी केलेल्या [व्यवहारांची प्रतीक्षा करण्यासाठी आणि तपशील मिळवण्यासाठी](https://ethereumdev.io/waiting-for-a-transaction-to-be-mined-on-ethereum-with-js/) एक जावास्क्रिप्ट ट्युटोरियल आहे आणि जोपर्यंत तुमच्याकडे ABI असेल तोपर्यंत [टोकन हस्तांतरणाद्वारे किंवा इतर कोणत्याही इव्हेंट्सद्वारे तयार केलेले इव्हेंट्स डीकोड करण्यासाठी एक ट्युटोरियल](https://ethereumdev.io/how-to-decode-event-logs-in-javascript-using-abi-decoder/) आहे.
+
+ट्युटोरियलसाठी संपूर्ण कोड येथे आहे:
+
+```solidity
+pragma solidity ^0.8.0;
+
+interface IERC20 {
+
+    function totalSupply() external view returns (uint256);
+    function balanceOf(address account) external view returns (uint256);
+    function allowance(address owner, address spender) external view returns (uint256);
+
+    function transfer(address recipient, uint256 amount) external returns (bool);
+    function approve(address spender, uint256 amount) external returns (bool);
+    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
+
+
+    event Transfer(address indexed from, address indexed to, uint256 value);
+    event Approval(address indexed owner, address indexed spender, uint256 value);
+}
+
+
+contract ERC20Basic is IERC20 {
+
+    string public constant name = "ERC20Basic";
+    string public constant symbol = "ERC";
+    uint8 public constant decimals = 18;
+
+
+    mapping(address => uint256) balances;
+
+    mapping(address => mapping (address => uint256)) allowed;
+
+    uint256 totalSupply_ = 10 ether;
+
+
+   constructor() {
+	balances[msg.sender] = totalSupply_;
+    }
+
+    function totalSupply() public override view returns (uint256) {
+	return totalSupply_;
+    }
+
+    function balanceOf(address tokenOwner) public override view returns (uint256) {
+        return balances[tokenOwner];
+    }
+
+    function transfer(address receiver, uint256 numTokens) public override returns (bool) {
+        require(numTokens <= balances[msg.sender]);
+        balances[msg.sender] = balances[msg.sender]-numTokens;
+        balances[receiver] = balances[receiver]+numTokens;
+        emit Transfer(msg.sender, receiver, numTokens);
+        return true;
+    }
+
+    function approve(address delegate, uint256 numTokens) public override returns (bool) {
+        allowed[msg.sender][delegate] = numTokens;
+        emit Approval(msg.sender, delegate, numTokens);
+        return true;
+    }
+
+    function allowance(address owner, address delegate) public override view returns (uint) {
+        return allowed[owner][delegate];
+    }
+
+    function transferFrom(address owner, address buyer, uint256 numTokens) public override returns (bool) {
+        require(numTokens <= balances[owner]);
+        require(numTokens <= allowed[owner][msg.sender]);
+
+        balances[owner] = balances[owner]-numTokens;
+        allowed[owner][msg.sender] = allowed[owner][msg.sender]-numTokens;
+        balances[buyer] = balances[buyer]+numTokens;
+        emit Transfer(owner, buyer, numTokens);
+        return true;
+    }
+}
+
+
+contract DEX {
+
+    event Bought(uint256 amount);
+    event Sold(uint256 amount);
+
+
+    IERC20 public token;
+
+    constructor() {
+        token = new ERC20Basic();
+    }
+
+    function buy() payable public {
+        uint256 amountTobuy = msg.value;
+        uint256 dexBalance = token.balanceOf(address(this));
+        require(amountTobuy > 0, "तुम्हाला काही ईथर पाठवणे आवश्यक आहे");
+        require(amountTobuy <= dexBalance, "रिझर्व्हमध्ये पुरेसे टोकन्स नाहीत");
+        token.transfer(msg.sender, amountTobuy);
+        emit Bought(amountTobuy);
+    }
+
+    function sell(uint256 amount) public {
+        require(amount > 0, "तुम्हाला किमान काही टोकन्स विकणे आवश्यक आहे");
+        uint256 allowance = token.allowance(msg.sender, address(this));
+        require(allowance >= amount, "टोकन भत्ता तपासा");
+        token.transferFrom(msg.sender, address(this), amount);
+        payable(msg.sender).transfer(amount);
+        emit Sold(amount);
+    }
+
+}
+```
diff --git a/public/content/translations/mr/developers/tutorials/understand-the-erc-20-token-smart-contract/index.md b/public/content/translations/mr/developers/tutorials/understand-the-erc-20-token-smart-contract/index.md
new file mode 100644
index 00000000000..aef47ef34ae
--- /dev/null
+++ b/public/content/translations/mr/developers/tutorials/understand-the-erc-20-token-smart-contract/index.md
@@ -0,0 +1,177 @@
+---
+title: "ERC-20 टोकन स्मार्ट कॉन्ट्रॅक्ट समजून घ्या"
+description: "संपूर्ण सॉलिडिटी स्मार्ट कॉन्ट्रॅक्ट उदाहरण आणि स्पष्टीकरणासह ERC-20 टोकन स्टँडर्ड कसे अंमलात आणायचे ते शिका."
+author: "jdourlens"
+tags: [ "स्मार्ट कॉन्ट्रॅक्ट", "tokens", "सॉलिडिटी", "erc-20" ]
+skill: beginner
+lang: mr
+published: 2020-04-05
+source: EthereumDev
+sourceUrl: https://ethereumdev.io/understand-the-erc20-token-smart-contract/
+address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+---
+
+Ethereum वरील सर्वात महत्त्वाच्या [स्मार्ट कॉन्ट्रॅक्ट स्टँडर्ड्सपैकी](/developers/docs/standards/) एक [ERC-20](/developers/docs/standards/tokens/erc-20/) म्हणून ओळखले जाते, जे फंजिबल टोकन अंमलबजावणीसाठी Ethereum ब्लॉकचेनवरील सर्व स्मार्ट कॉन्ट्रॅक्ट्ससाठी वापरले जाणारे तांत्रिक मानक म्हणून उदयास आले आहे.
+
+ERC-20 नियमांची एक सामान्य सूची परिभाषित करते ज्याचे सर्व फंजिबल Ethereum टोकन्सनी पालन केले पाहिजे. परिणामी, हे टोकन स्टँडर्ड सर्व प्रकारच्या डेव्हलपर्सना मोठ्या Ethereum प्रणालीमध्ये नवीन टोकन कसे कार्य करतील याचा अचूक अंदाज लावण्यास सक्षम करते. हे डेव्हलपर्सची कामे सोपी करते, कारण ते आपले काम पुढे चालू ठेवू शकतात, हे जाणून की प्रत्येक नवीन प्रोजेक्टला प्रत्येक वेळी नवीन टोकन रिलीज झाल्यावर पुन्हा करण्याची आवश्यकता भासणार नाही, जोपर्यंत टोकन नियमांचे पालन करते.
+
+येथे, एका इंटरफेसच्या स्वरूपात सादर केलेले, ERC-20 ने अंमलात आणायलाच हवे असे फंक्शन्स आहेत. जर तुम्हाला इंटरफेस म्हणजे काय याबद्दल खात्री नसेल तर: [Solidity मध्ये OOP प्रोग्रामिंग](https://ethereumdev.io/inheritance-in-solidity-contracts-are-classes/) वरील आमचा लेख तपासा.
+
+```solidity
+pragma solidity ^0.6.0;
+
+interface IERC20 {
+
+    function totalSupply() external view returns (uint256);
+    function balanceOf(address account) external view returns (uint256);
+    function allowance(address owner, address spender) external view returns (uint256);
+
+    function transfer(address recipient, uint256 amount) external returns (bool);
+    function approve(address spender, uint256 amount) external returns (bool);
+    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
+
+
+    event Transfer(address indexed from, address indexed to, uint256 value);
+    event Approval(address indexed owner, address indexed spender, uint256 value);
+}
+```
+
+प्रत्येक फंक्शन कशासाठी आहे याचे ओळीनुसार स्पष्टीकरण येथे दिले आहे. यानंतर आम्ही ERC-20 टोकनची एक सोपी अंमलबजावणी सादर करू.
+
+## गेटर्स {#getters}
+
+```solidity
+function totalSupply() external view returns (uint256);
+```
+
+अस्तित्वात असलेल्या टोकन्सची संख्या परत करते. हे फंक्शन एक गेटर आहे आणि कॉन्ट्रॅक्टची स्थिती बदलत नाही. लक्षात ठेवा की सॉलिडिटीमध्ये फ्लोट्स नाहीत. म्हणून, बहुतेक टोकन्स 18 डेसिमल्सचा अवलंब करतात आणि 1 टोकनसाठी 1000000000000000000 असा एकूण पुरवठा आणि इतर परिणाम परत करतील. प्रत्येक टोकनमध्ये 18 डेसिमल्स नसतात आणि टोकन्स हाताळताना ही एक गोष्ट आहे ज्याकडे तुम्हाला खरोखर लक्ष देणे आवश्यक आहे.
+
+```solidity
+function balanceOf(address account) external view returns (uint256);
+```
+
+एखाद्या ॲड्रेसच्या (`account`) मालकीच्या टोकन्सची संख्या परत करते. हे फंक्शन एक गेटर आहे आणि कॉन्ट्रॅक्टची स्थिती बदलत नाही.
+
+```solidity
+function allowance(address owner, address spender) external view returns (uint256);
+```
+
+ERC-20 स्टँडर्ड एका ॲड्रेसला दुसऱ्या ॲड्रेसला त्यातून टोकन मिळवण्यास सक्षम होण्यासाठी भत्ता देण्याची परवानगी देते. हे गेटर `spender` ला `owner` च्या वतीने खर्च करण्याची परवानगी असलेल्या टोकनची उर्वरित संख्या परत करते. हे फंक्शन एक गेटर आहे आणि कॉन्ट्रॅक्टची स्थिती बदलत नाही आणि डीफॉल्टनुसार 0 परत केले पाहिजे.
+
+## फंक्शन्स {#functions}
+
+```solidity
+function transfer(address recipient, uint256 amount) external returns (bool);
+```
+
+हे फंक्शन कॉलर ॲड्रेस (`msg.sender`) वरून प्राप्तकर्त्याच्या ॲड्रेसवर टोकन्सची `amount` हलवते. हे फंक्शन नंतर परिभाषित केलेला `Transfer` इव्हेंट उत्सर्जित करते. जर हस्तांतरण शक्य असेल तर ते true परत करते.
+
+```solidity
+function approve(address spender, uint256 amount) external returns (bool);
+```
+
+फंक्शन कॉलर (`msg.sender`) च्या बॅलन्समधून `spender` ला हस्तांतरित करण्याची परवानगी असलेल्या `allowance` ची रक्कम सेट करा. हे फंक्शन Approval इव्हेंट उत्सर्जित करते. फंक्शन भत्ता यशस्वीरित्या सेट झाला होता की नाही हे परत करते.
+
+```solidity
+function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
+```
+
+अलाउन्स मेकॅनिझम वापरून `sender` कडून `recipient` कडे टोकनची `amount` हलवते. त्यानंतर कॉलरच्या भत्त्यामधून रक्कम कापली जाते. हे फंक्शन `Transfer` इव्हेंट उत्सर्जित करते.
+
+## इव्हेंट्स {#events}
+
+```solidity
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+हा इव्हेंट तेव्हा उत्सर्जित होतो जेव्हा टोकनची रक्कम (व्हॅल्यू) `from` ॲड्रेसवरून `to` ॲड्रेसवर पाठविली जाते.
+
+नवीन टोकन मिंट करण्याच्या बाबतीत, हस्तांतरण सामान्यतः 0x00..0000 ॲड्रेस `from` होते तर टोकन बर्न करण्याच्या बाबतीत हस्तांतरण 0x00..0000 `to` होते.
+
+```solidity
+event Approval(address indexed owner, address indexed spender, uint256 value);
+```
+
+हा इव्हेंट तेव्हा उत्सर्जित होतो जेव्हा `owner` द्वारे `spender` ला वापरण्यासाठी टोकन्सची रक्कम (`value`) मंजूर केली जाते.
+
+## ERC-20 टोकन्सची मूलभूत अंमलबजावणी {#a-basic-implementation-of-erc-20-tokens}
+
+तुमच्या ERC-20 टोकनचा आधार घेण्यासाठी येथे सर्वात सोपा कोड आहे:
+
+```solidity
+pragma solidity ^0.8.0;
+
+interface IERC20 {
+
+    function totalSupply() external view returns (uint256);
+    function balanceOf(address account) external view returns (uint256);
+    function allowance(address owner, address spender) external view returns (uint256);
+
+    function transfer(address recipient, uint256 amount) external returns (bool);
+    function approve(address spender, uint256 amount) external returns (bool);
+    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
+
+
+    event Transfer(address indexed from, address indexed to, uint256 value);
+    event Approval(address indexed owner, address indexed spender, uint256 value);
+}
+
+
+contract ERC20Basic is IERC20 {
+
+    string public constant name = "ERC20Basic";
+    string public constant symbol = "ERC";
+    uint8 public constant decimals = 18;
+
+
+    mapping(address => uint256) balances;
+
+    mapping(address => mapping (address => uint256)) allowed;
+
+    uint256 totalSupply_ = 10 ether;
+
+
+   constructor() {
+	balances[msg.sender] = totalSupply_;
+    }
+
+    function totalSupply() public override view returns (uint256) {
+	return totalSupply_;
+    }
+
+    function balanceOf(address tokenOwner) public override view returns (uint256) {
+        return balances[tokenOwner];
+    }
+
+    function transfer(address receiver, uint256 numTokens) public override returns (bool) {
+        require(numTokens <= balances[msg.sender]);
+        balances[msg.sender] = balances[msg.sender]-numTokens;
+        balances[receiver] = balances[receiver]+numTokens;
+        emit Transfer(msg.sender, receiver, numTokens);
+        return true;
+    }
+
+    function approve(address delegate, uint256 numTokens) public override returns (bool) {
+        allowed[msg.sender][delegate] = numTokens;
+        emit Approval(msg.sender, delegate, numTokens);
+        return true;
+    }
+
+    function allowance(address owner, address delegate) public override view returns (uint) {
+        return allowed[owner][delegate];
+    }
+
+    function transferFrom(address owner, address buyer, uint256 numTokens) public override returns (bool) {
+        require(numTokens <= balances[owner]);
+        require(numTokens <= allowed[owner][msg.sender]);
+
+        balances[owner] = balances[owner]-numTokens;
+        allowed[owner][msg.sender] = allowed[owner][msg.sender]-numTokens;
+        balances[buyer] = balances[buyer]+numTokens;
+        emit Transfer(owner, buyer, numTokens);
+        return true;
+    }
+}
+```
+
+ERC-20 टोकन स्टँडर्डची आणखी एक उत्कृष्ट अंमलबजावणी म्हणजे [OpenZeppelin ERC-20 अंमलबजावणी](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20).
diff --git a/public/content/translations/mr/developers/tutorials/uniswap-v2-annotated-code/index.md b/public/content/translations/mr/developers/tutorials/uniswap-v2-annotated-code/index.md
new file mode 100644
index 00000000000..51bc913db16
--- /dev/null
+++ b/public/content/translations/mr/developers/tutorials/uniswap-v2-annotated-code/index.md
@@ -0,0 +1,1898 @@
+---
+title: "Uniswap-v2 कराराचे अवलोकन"
+description: "Uniswap-v2 करार कसा काम करतो? ते त्या प्रकारे का लिहिले आहे?"
+author: Ori Pomerantz
+tags: [ "सॉलिडिटी" ]
+skill: intermediate
+published: 2021-05-01
+lang: mr
+---
+
+## प्रस्तावना {#introduction}
+
+[Uniswap v2](https://app.uniswap.org/whitepaper.pdf) कोणत्याही दोन ERC-20 टोकन्समध्ये विनिमय बाजार तयार करू शकते. या लेखात आपण या प्रोटोकॉलची अंमलबजावणी करणाऱ्या करारांसाठी स्रोत कोड पाहू आणि ते या प्रकारे का लिहिले आहेत हे पाहू.
+
+### Uniswap काय करते? {#what-does-uniswap-do}
+
+मूलतः, वापरकर्त्यांचे दोन प्रकार आहेत: लिक्विडिटी प्रोव्हायडर आणि व्यापारी.
+
+_लिक्विडिटी प्रोव्हायडर_ पूलला दोन टोकन्स प्रदान करतात ज्यांचा विनिमय केला जाऊ शकतो (आपण त्यांना **टोकन0** आणि **टोकन1** म्हणू). त्या बदल्यात, त्यांना तिसरे टोकन मिळते जे पूलच्या आंशिक मालकीचे प्रतिनिधित्व करते, ज्याला _लिक्विडिटी टोकन_ म्हणतात.
+
+_व्यापारी_ पूलमध्ये एका प्रकारचे टोकन पाठवतात आणि दुसरे टोकन (उदाहरणार्थ, **टोकन0** पाठवून **टोकन1** प्राप्त करणे) लिक्विडिटी प्रोव्हायडरद्वारे प्रदान केलेल्या पूलमधून प्राप्त करतात. पूलमध्ये असलेल्या **टोकन0** आणि **टोकन1** च्या सापेक्ष संख्येनुसार विनिमय दर निर्धारित केला जातो. याव्यतिरिक्त, पूल लिक्विडिटी पूलसाठी बक्षीस म्हणून लहान टक्केवारी घेते.
+
+जेव्हा लिक्विडिटी प्रोव्हायडरना त्यांची मालमत्ता परत हवी असते, तेव्हा ते पूल टोकन्स बर्न करू शकतात आणि बक्षिसांमधील त्यांच्या वाट्यासह त्यांचे टोकन्स परत मिळवू शकतात.
+
+[अधिक वर्णनासाठी येथे क्लिक करा](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/swaps/).
+
+### v2 का? v3 का नाही? {#why-v2}
+
+[Uniswap v3](https://app.uniswap.org/whitepaper-v3.pdf) हे एक अपग्रेड आहे जे v2 पेक्षा खूपच गुंतागुंतीचे आहे. आधी v2 शिकणे आणि नंतर v3 कडे जाणे सोपे आहे.
+
+### मुख्य करार विरुद्ध परिघ करार {#contract-types}
+
+Uniswap v2 दोन घटकांमध्ये विभागलेले आहे, एक मुख्य आणि एक परिघ. हे विभाजन मुख्य करारांना, जे मालमत्ता ठेवतात आणि त्यामुळे _सुरक्षित_ असणे आवश्यक आहे, सोपे आणि ऑडिट करण्यास सोपे बनवते. व्यापाऱ्यांसाठी आवश्यक असलेली सर्व अतिरिक्त कार्यक्षमता नंतर परिघ करारांद्वारे प्रदान केली जाऊ शकते.
+
+## डेटा आणि नियंत्रण प्रवाह {#flows}
+
+जेव्हा तुम्ही Uniswap च्या तीन मुख्य क्रिया करता तेव्हा हा डेटा आणि नियंत्रणाचा प्रवाह आहे:
+
+1. वेगवेगळ्या टोकन्समध्ये स्वॅप करा
+2. मार्केटमध्ये लिक्विडिटी जोडा आणि पेअर एक्सचेंज ERC-20 लिक्विडिटी टोकन्ससह बक्षीस मिळवा
+3. ERC-20 लिक्विडिटी टोकन्स बर्न करा आणि पेअर एक्सचेंज व्यापाऱ्यांना विनिमय करण्याची परवानगी देणारे ERC-20 टोकन्स परत मिळवा
+
+### स्वॅप {#swap-flow}
+
+हा सर्वात सामान्य प्रवाह आहे, जो व्यापाऱ्यांद्वारे वापरला जातो:
+
+#### कॉलर {#caller}
+
+1. स्वॅप करायच्या रकमेसाठी परिघ खात्याला अनुमती द्या.
+2. परिघ कराराच्या अनेक स्वॅप फंक्शन्सपैकी एक कॉल करा (कोणते फंक्शन वापरायचे हे ETH सामील आहे की नाही, व्यापारी जमा करायच्या टोकन्सची रक्कम किंवा परत मिळवायच्या टोकन्सची रक्कम निर्दिष्ट करतो का, इत्यादीवर अवलंबून असते).
+   प्रत्येक स्वॅप फंक्शन एक `path` स्वीकारतो, जो एक एक्सचेंजेसचा अॅरे आहे ज्यातून जायचे आहे.
+
+#### परिघ करारामध्ये (UniswapV2Router02.sol) {#in-the-periphery-contract-uniswapv2router02-sol}
+
+3. मार्गावरील प्रत्येक एक्सचेंजवर व्यापार करण्याची आवश्यकता असलेल्या रकमेची ओळख करा.
+4. मार्गावर पुनरावृत्ती करते. मार्गावरील प्रत्येक एक्सचेंजसाठी ते इनपुट टोकन पाठवते आणि नंतर एक्सचेंजच्या `swap` फंक्शनला कॉल करते.
+   बहुतेक प्रकरणांमध्ये टोकन्ससाठी गंतव्य पत्ता मार्गावरील पुढील पेअर एक्सचेंज असतो. अंतिम एक्सचेंजमध्ये तो व्यापाऱ्याने प्रदान केलेला पत्ता असतो.
+
+#### मुख्य करारामध्ये (UniswapV2Pair.sol) {#in-the-core-contract-uniswapv2pairsol-2}
+
+5. मुख्य कराराची फसवणूक होत नाही आणि स्वॅपनंतर पुरेशी लिक्विडिटी राखू शकते याची पडताळणी करा.
+6. ज्ञात रिझर्व्ह्स व्यतिरिक्त आमच्याकडे किती अतिरिक्त टोकन्स आहेत ते पहा. ती रक्कम म्हणजे आम्हाला विनिमय करण्यासाठी मिळालेल्या इनपुट टोकन्सची संख्या.
+7. आउटपुट टोकन्स गंतव्यस्थानावर पाठवा.
+8. रिझर्व्ह रक्कम अपडेट करण्यासाठी `_update` ला कॉल करा
+
+#### परिघ करारामध्ये परत (UniswapV2Router02.sol) {#back-in-the-periphery-contract-uniswapv2router02-sol}
+
+9. आवश्यक स्वच्छता करा (उदाहरणार्थ, व्यापाऱ्याला पाठवण्यासाठी ETH परत मिळवण्यासाठी WETH टोकन्स बर्न करा)
+
+### लिक्विडिटी जोडा {#add-liquidity-flow}
+
+#### कॉलर {#caller-2}
+
+1. लिक्विडिटी पूलमध्ये जोडल्या जाणाऱ्या रकमेसाठी परिघ खात्याला अनुमती द्या.
+2. परिघ कराराच्या `addLiquidity` फंक्शन्सपैकी एक कॉल करा.
+
+#### परिघ करारामध्ये (UniswapV2Router02.sol) {#in-the-periphery-contract-uniswapv2router02sol-2}
+
+3. आवश्यक असल्यास नवीन पेअर एक्सचेंज तयार करा
+4. जर अस्तित्वात असलेला पेअर एक्सचेंज असेल, तर जोडण्यासाठी टोकन्सची रक्कम मोजा. हे दोन्ही टोकन्ससाठी समान मूल्य मानले जाते, म्हणून नवीन टोकन्स आणि अस्तित्वातील टोकन्सचे प्रमाण समान असते.
+5. रक्कम स्वीकारार्ह आहे की नाही ते तपासा (कॉलर किमान रक्कम निर्दिष्ट करू शकतात ज्याच्या खाली ते लिक्विडिटी जोडू इच्छित नाहीत)
+6. मुख्य कराराला कॉल करा.
+
+#### मुख्य करारामध्ये (UniswapV2Pair.sol) {#in-the-core-contract-uniswapv2pairsol-2}
+
+7. लिक्विडिटी टोकन्स मिंट करा आणि ते कॉलरला पाठवा
+8. रिझर्व्ह रक्कम अपडेट करण्यासाठी `_update` ला कॉल करा
+
+### लिक्विडिटी काढा {#remove-liquidity-flow}
+
+#### कॉलर {#caller-3}
+
+1. अंतर्निहित टोकन्सच्या बदल्यात बर्न करण्यासाठी लिक्विडिटी टोकन्सची अनुमती परिघ खात्याला द्या.
+2. परिघ कराराच्या `removeLiquidity` फंक्शन्सपैकी एक कॉल करा.
+
+#### परिघ करारामध्ये (UniswapV2Router02.sol) {#in-the-periphery-contract-uniswapv2router02sol-3}
+
+3. लिक्विडिटी टोकन्स पेअर एक्सचेंजला पाठवा
+
+#### मुख्य करारामध्ये (UniswapV2Pair.sol) {#in-the-core-contract-uniswapv2pairsol-3}
+
+4. बर्न केलेल्या टोकन्सच्या प्रमाणात गंतव्य पत्त्यावर अंतर्निहित टोकन्स पाठवा. उदाहरणार्थ, जर पूलमध्ये 1000 A टोकन्स, 500 B टोकन्स, आणि 90 लिक्विडिटी टोकन्स असतील, आणि आम्हाला बर्न करण्यासाठी 9 टोकन्स मिळाले, तर आम्ही 10% लिक्विडिटी टोकन्स बर्न करत आहोत, म्हणून आम्ही वापरकर्त्याला 100 A टोकन्स आणि 50 B टोकन्स परत पाठवतो.
+5. लिक्विडिटी टोकन्स बर्न करा
+6. रिझर्व्ह रक्कम अपडेट करण्यासाठी `_update` ला कॉल करा
+
+## मुख्य करार {#core-contracts}
+
+हे सुरक्षित करार आहेत जे लिक्विडिटी ठेवतात.
+
+### UniswapV2Pair.sol {#UniswapV2Pair}
+
+[हा करार](https://github.com/Uniswap/uniswap-v2-core/blob/master/contracts/UniswapV2Pair.sol) प्रत्यक्ष पूलची अंमलबजावणी करतो जो टोकन्सचा विनिमय करतो. ही मुख्य Uniswap कार्यक्षमता आहे.
+
+```solidity
+pragma solidity =0.5.16;
+
+import './interfaces/IUniswapV2Pair.sol';
+import './UniswapV2ERC20.sol';
+import './libraries/Math.sol';
+import './libraries/UQ112x112.sol';
+import './interfaces/IERC20.sol';
+import './interfaces/IUniswapV2Factory.sol';
+import './interfaces/IUniswapV2Callee.sol';
+```
+
+हे सर्व इंटरफेस आहेत ज्यांबद्दल कराराला माहित असणे आवश्यक आहे, एकतर कारण करार त्यांची अंमलबजावणी करतो (`IUniswapV2Pair` आणि `UniswapV2ERC20`) किंवा कारण तो त्यांची अंमलबजावणी करणाऱ्या करारांना कॉल करतो.
+
+```solidity
+contract UniswapV2Pair is IUniswapV2Pair, UniswapV2ERC20 {
+```
+
+हा करार `UniswapV2ERC20` पासून वारसा घेतो, जो लिक्विडिटी टोकन्ससाठी ERC-20 फंक्शन्स प्रदान करतो.
+
+```solidity
+    using SafeMath  for uint;
+```
+
+[SafeMath लायब्ररी](https://docs.openzeppelin.com/contracts/2.x/api/math) ओव्हरफ्लो आणि अंडरफ्लो टाळण्यासाठी वापरली जाते. हे महत्त्वाचे आहे कारण अन्यथा आपण अशा परिस्थितीत येऊ शकतो जिथे मूल्य `-1` असले पाहिजे, परंतु त्याऐवजी `2^256-1` असेल.
+
+```solidity
+    using UQ112x112 for uint224;
+```
+
+पूल करारामध्ये अनेक गणितांसाठी अपूर्णांकांची आवश्यकता असते. तथापि, EVM द्वारे अपूर्णांक समर्थित नाहीत.
+Uniswap ने शोधलेला उपाय म्हणजे 224 बिट मूल्यांचा वापर करणे, ज्यामध्ये पूर्णांक भागासाठी 112 बिट्स आणि अपूर्णांकासाठी 112 बिट्स असतात. म्हणून `1.0` हे `2^112` म्हणून दर्शविले जाते, `1.5` हे `2^112 + 2^111` म्हणून दर्शविले जाते, इत्यादी.
+
+या लायब्ररीबद्दल अधिक तपशील [दस्तऐवजात नंतर](#FixedPoint) उपलब्ध आहेत.
+
+#### व्हेरिअबल्स {#pair-vars}
+
+```solidity
+    uint public constant MINIMUM_LIQUIDITY = 10**3;
+```
+
+शून्याने भागाकार टाळण्यासाठी, लिक्विडिटी टोकन्सची किमान संख्या नेहमी अस्तित्वात असते (परंतु ती शून्य खात्याच्या मालकीची असते). ती संख्या **MINIMUM_LIQUIDITY** आहे, एक हजार.
+
+```solidity
+    bytes4 private constant SELECTOR = bytes4(keccak256(bytes('transfer(address,uint256)')));
+```
+
+हा ERC-20 ट्रान्सफर फंक्शनसाठी ABI सिलेक्टर आहे. हे दोन टोकन खात्यांमध्ये ERC-20 टोकन्स हस्तांतरित करण्यासाठी वापरले जाते.
+
+```solidity
+    address public factory;
+```
+
+हा फॅक्टरी करार आहे ज्याने हा पूल तयार केला. प्रत्येक पूल दोन ERC-20 टोकन्समध्ये एक एक्सचेंज आहे, फॅक्टरी एक केंद्रीय बिंदू आहे जो या सर्व पूलांना जोडतो.
+
+```solidity
+    address public token0;
+    address public token1;
+```
+
+हे त्या दोन प्रकारच्या ERC-20 टोकन्सच्या करारांचे पत्ते आहेत ज्यांचा या पूलमार्फत विनिमय केला जाऊ शकतो.
+
+```solidity
+    uint112 private reserve0;           // uses single storage slot, accessible via getReserves
+    uint112 private reserve1;           // uses single storage slot, accessible via getReserves
+```
+
+प्रत्येक टोकन प्रकारासाठी पूलमध्ये असलेला राखीव साठा. आपण असे गृहीत धरतो की दोन्ही समान मूल्याचे प्रतिनिधित्व करतात, आणि म्हणून प्रत्येक token0 चे मूल्य reserve1/reserve0 token1 इतके आहे.
+
+```solidity
+    uint32  private blockTimestampLast; // uses single storage slot, accessible via getReserves
+```
+
+शेवटच्या ब्लॉकसाठी टाइमस्टॅम्प ज्यामध्ये विनिमय झाला होता, जो वेळेनुसार विनिमय दरांचा मागोवा घेण्यासाठी वापरला जातो.
+
+Ethereum करारांचा सर्वात मोठा गॅस खर्च म्हणजे स्टोरेज, जो कराराच्या एका कॉलपासून दुसऱ्या कॉलपर्यंत कायम राहतो. प्रत्येक स्टोरेज सेल 256 बिट्स लांब असतो. म्हणून तीन व्हेरिएबल्स, `reserve0`, `reserve1`, आणि `blockTimestampLast`, अशा प्रकारे वाटप केले जातात की एकाच स्टोरेज मूल्यामध्ये हे तिन्ही समाविष्ट होऊ शकतात (112+112+32=256).
+
+```solidity
+    uint public price0CumulativeLast;
+    uint public price1CumulativeLast;
+```
+
+हे व्हेरिएबल्स प्रत्येक टोकनसाठी (प्रत्येकी दुसऱ्याच्या संदर्भात) एकत्रित खर्च ठेवतात. ते एका विशिष्ट कालावधीसाठी सरासरी विनिमय दर मोजण्यासाठी वापरले जाऊ शकतात.
+
+```solidity
+    uint public kLast; // reserve0 * reserve1, as of immediately after the most recent liquidity event
+```
+
+पेअर एक्सचेंज token0 आणि token1 मधील विनिमय दराचा निर्णय घेण्याचा मार्ग म्हणजे व्यापारादरम्यान दोन राखीव साठ्यांचा गुणाकार स्थिर ठेवणे. `kLast` हे हे मूल्य आहे. जेव्हा एखादा लिक्विडिटी प्रोव्हायडर टोकन्स जमा करतो किंवा काढतो तेव्हा ते बदलते आणि 0.3% बाजार शुल्कामुळे ते किंचित वाढते.
+
+येथे एक सोपे उदाहरण आहे. लक्षात घ्या की साधेपणासाठी सारणीमध्ये दशांश बिंदूनंतर फक्त तीन अंक आहेत आणि आम्ही 0.3% व्यापार शुल्क दुर्लक्षित करतो त्यामुळे संख्या अचूक नाहीत.
+
+| इव्हेंट                                                                |                  reserve0 |                  reserve1 | reserve0 \* reserve1 | सरासरी विनिमय दर (टोकन1 / टोकन0) |
+| ---------------------------------------------------------------------- | ------------------------: | ------------------------: | -------------------: | --------------------------------------------------- |
+| प्राथमिक सेटअप                                                         | 1,000.000 | 1,000.000 |            1,000,000 |                                                     |
+| व्यापारी A ने 50 token0 साठी 47.619 token1 स्वॅप केले  | 1,050.000 |   952.381 |            1,000,000 | 0.952                               |
+| व्यापारी B ने 10 token0 साठी 8.984 token1 स्वॅप केले   | 1,060.000 |   943.396 |            1,000,000 | 0.898                               |
+| व्यापारी C ने 40 token0 साठी 34.305 token1 स्वॅप केले  | 1,100.000 |   909.090 |            1,000,000 | 0.858                               |
+| व्यापारी D ने 100 token1 साठी 109.01 token0 स्वॅप केले |   990.990 | 1,009.090 |            1,000,000 | 0.917                               |
+| व्यापारी E ने 10 token0 साठी 10.079 token1 स्वॅप केले  | 1,000.990 |   999.010 |            1,000,000 | 1.008                               |
+
+व्यापारी जसजसे अधिक token0 प्रदान करतात, तसतसे token1 चे सापेक्ष मूल्य वाढते आणि उलट, पुरवठा आणि मागणीवर आधारित.
+
+#### लॉक {#pair-lock}
+
+```solidity
+    uint private unlocked = 1;
+```
+
+सुरक्षा भेद्यतांचा एक वर्ग आहे जो [पुनर्प्रवेश गैरवापरा](https://medium.com/coinmonks/ethernaut-lvl-10-re-entrancy-walkthrough-how-to-abuse-execution-ordering-and-reproduce-the-dao-7ec88b912c14) वर आधारित आहे. Uniswap ला अनियंत्रित ERC-20 टोकन हस्तांतरित करणे आवश्यक आहे, याचा अर्थ ERC-20 करारांना कॉल करणे जे त्यांना कॉल करणाऱ्या Uniswap बाजाराचा गैरवापर करण्याचा प्रयत्न करू शकतात.
+कराराचा भाग म्हणून `unlocked` व्हेरिएबल असल्यामुळे, आपण फंक्शन्स चालू असताना (एकाच व्यवहारात) त्यांना कॉल करण्यापासून रोखू शकतो.
+
+```solidity
+    modifier lock() {
+```
+
+हे फंक्शन एक [मॉडिफायर](https://docs.soliditylang.org/en/v0.8.3/contracts.html#function-modifiers) आहे, एक फंक्शन जे सामान्य फंक्शनभोवती गुंडाळते आणि त्याचे वर्तन काही प्रकारे बदलते.
+
+```solidity
+        require(unlocked == 1, 'UniswapV2: LOCKED');
+        unlocked = 0;
+```
+
+जर `unlocked` एकच्या बरोबर असेल, तर ते शून्यावर सेट करा. जर ते आधीच शून्य असेल तर कॉल रिव्हर्ट करा, ते अयशस्वी करा.
+
+```solidity
+        _;
+```
+
+एका मॉडिफायरमध्ये `_;` हे मूळ फंक्शन कॉल आहे (सर्व पॅरामीटर्ससह). येथे याचा अर्थ असा आहे की फंक्शन कॉल तेव्हाच होतो जेव्हा `unlocked` चे मूल्य एक होते, आणि ते चालू असताना `unlocked` चे मूल्य शून्य असते.
+
+```solidity
+        unlocked = 1;
+    }
+```
+
+मुख्य फंक्शन परत आल्यानंतर, लॉक सोडा.
+
+#### विविध फंक्शन्स {#pair-misc}
+
+```solidity
+    function getReserves() public view returns (uint112 _reserve0, uint112 _reserve1, uint32 _blockTimestampLast) {
+        _reserve0 = reserve0;
+        _reserve1 = reserve1;
+        _blockTimestampLast = blockTimestampLast;
+    }
+```
+
+हे फंक्शन कॉल करणाऱ्यांना एक्सचेंजच्या सध्याच्या स्थितीबद्दल माहिती देते. लक्षात घ्या की सॉलिडिटी फंक्शन्स [एकाधिक मूल्ये परत करू शकतात](https://docs.soliditylang.org/en/v0.8.3/contracts.html#returning-multiple-values).
+
+```solidity
+    function _safeTransfer(address token, address to, uint value) private {
+        (bool success, bytes memory data) = token.call(abi.encodeWithSelector(SELECTOR, to, value));
+```
+
+हे इंटर्नल फंक्शन एक्सचेंजमधून ERC20 टोकन्सची ठराविक रक्कम दुसऱ्या कोणालातरी हस्तांतरित करते. `SELECTOR` हे निर्दिष्ट करते की आपण ज्या फंक्शनला कॉल करत आहोत ते `transfer(address,uint)` आहे (वरील व्याख्या पहा).
+
+टोकन फंक्शनसाठी इंटरफेस इम्पोर्ट करणे टाळण्यासाठी, आम्ही [ABI फंक्शन्स](https://docs.soliditylang.org/en/v0.8.3/units-and-global-variables.html#abi-encoding-and-decoding-functions) पैकी एक वापरून "मॅन्युअली" कॉल तयार करतो.
+
+```solidity
+        require(success && (data.length == 0 || abi.decode(data, (bool))), 'UniswapV2: TRANSFER_FAILED');
+    }
+```
+
+ERC-20 ट्रान्सफर कॉल अयशस्वी झाल्याची तक्रार करण्याचे दोन मार्ग आहेत:
+
+1. रिव्हर्ट. जर बाह्य कॉन्ट्रॅक्टचा कॉल रिव्हर्ट झाल्यास, तर बुलियन रिटर्न व्हॅल्यू `false` असते
+2. सामान्यपणे समाप्त होते परंतु अपयशाची तक्रार करते. त्या बाबतीत रिटर्न व्हॅल्यू बफरची लांबी शून्य नसते, आणि जेव्हा बुलियन व्हॅल्यू म्हणून डीकोड केले जाते, तेव्हा ते `false` असते
+
+यापैकी कोणतीही अट घडल्यास, रिव्हर्ट करा.
+
+#### इव्हेंट्स {#pair-events}
+
+```solidity
+    event Mint(address indexed sender, uint amount0, uint amount1);
+    event Burn(address indexed sender, uint amount0, uint amount1, address indexed to);
+```
+
+हे दोन इव्हेंट्स तेव्हा उत्सर्जित होतात जेव्हा लिक्विडिटी प्रोव्हायडर एकतर लिक्विडिटी जमा करतो (`Mint`) किंवा काढतो (`Burn`). दोन्ही बाबतीत, जमा केलेल्या किंवा काढलेल्या token0 आणि token1 ची रक्कम इव्हेंटचा भाग आहे, तसेच आम्हाला कॉल करणाऱ्या खात्याची ओळख (`sender`) देखील आहे. विथड्रॉवलच्या बाबतीत, इव्हेंटमध्ये टोकन प्राप्त करणारे लक्ष्य (`to`) देखील समाविष्ट असते, जे प्रेषकासारखे (`sender`) नसू शकते.
+
+```solidity
+    event Swap(
+        address indexed sender,
+        uint amount0In,
+        uint amount1In,
+        uint amount0Out,
+        uint amount1Out,
+        address indexed to
+    );
+```
+
+जेव्हा एखादा व्यापारी एका टोकनसाठी दुसऱ्या टोकनची देवाणघेवाण करतो तेव्हा हा इव्हेंट उत्सर्जित होतो. पुन्हा, प्रेषक आणि गंतव्यस्थान समान नसू शकतात.
+प्रत्येक टोकन एकतर एक्सचेंजला पाठवला जाऊ शकतो, किंवा तिथून प्राप्त केला जाऊ शकतो.
+
+```solidity
+    event Sync(uint112 reserve0, uint112 reserve1);
+```
+
+शेवटी, `Sync` प्रत्येक वेळी टोकन्स जोडले किंवा काढले जातात, कारणाकडे दुर्लक्ष करून, नवीनतम राखीव माहिती (आणि म्हणून विनिमय दर) प्रदान करण्यासाठी उत्सर्जित होतो.
+
+#### सेटअप फंक्शन्स {#pair-setup}
+
+नवीन पेअर एक्सचेंज सेट अप केल्यावर हे फंक्शन्स एकदा कॉल केले जाणे अपेक्षित आहे.
+
+```solidity
+    constructor() public {
+        factory = msg.sender;
+    }
+```
+
+कन्स्ट्रक्टर हे सुनिश्चित करतो की आम्ही पेअर तयार करणाऱ्या फॅक्टरीच्या ॲड्रेसचा मागोवा ठेवू. ही माहिती `initialize` साठी आणि फॅक्टरी फीसाठी (असल्यास) आवश्यक आहे.
+
+```solidity
+    // डिप्लॉयमेंटच्या वेळी फॅक्टरीद्वारे एकदा कॉल केले जाते
+    function initialize(address _token0, address _token1) external {
+        require(msg.sender == factory, 'UniswapV2: FORBIDDEN'); // पुरेसे तपासणी
+        token0 = _token0;
+        token1 = _token1;
+    }
+```
+
+हे फंक्शन फॅक्टरीला (आणि फक्त फॅक्टरीला) दोन ERC-20 टोकन्स निर्दिष्ट करण्याची परवानगी देते ज्यांची हे पेअर देवाणघेवाण करेल.
+
+#### इंटर्नल अपडेट फंक्शन्स {#pair-update-internal}
+
+##### \_update
+
+```solidity
+    // रिझर्व्हस् अपडेट करा आणि, प्रति ब्लॉक पहिल्या कॉलवर, किंमत संचयक (price accumulators) अपडेट करा
+    function _update(uint balance0, uint balance1, uint112 _reserve0, uint112 _reserve1) private {
+```
+
+प्रत्येक वेळी टोकन्स जमा केले किंवा काढले जातात तेव्हा हे फंक्शन कॉल केले जाते.
+
+```solidity
+        require(balance0 <= uint112(-1) && balance1 <= uint112(-1), 'UniswapV2: OVERFLOW');
+```
+
+जर balance0 किंवा balance1 (uint256) हे uint112(-1) (=2^112-1) पेक्षा जास्त असेल (म्हणजे uint112 मध्ये रूपांतरित केल्यावर ते ओव्हरफ्लो होते आणि 0 वर परत येते) तर ओव्हरफ्लो टाळण्यासाठी \_update पुढे चालू ठेवण्यास नकार द्या. एका सामान्य टोकनसह ज्याला 10^18 युनिट्समध्ये उपविभाजित केले जाऊ शकते, याचा अर्थ प्रत्येक एक्सचेंज प्रत्येक टोकनच्या सुमारे 5.1\*10^15 पर्यंत मर्यादित आहे. आतापर्यंत ही समस्या आलेली नाही.
+
+```solidity
+        uint32 blockTimestamp = uint32(block.timestamp % 2**32);
+        uint32 timeElapsed = blockTimestamp - blockTimestampLast; // ओव्हरफ्लो अपेक्षित आहे
+        if (timeElapsed > 0 && _reserve0 != 0 && _reserve1 != 0) {
+```
+
+जर गेलेला वेळ शून्य नसेल, तर याचा अर्थ आम्ही या ब्लॉकवरील पहिले एक्सचेंज व्यवहार आहोत. त्या बाबतीत, आम्हाला कॉस्ट अ‍ॅक्युम्युलेटर (cost accumulators) अपडेट करणे आवश्यक आहे.
+
+```solidity
+            // * कधीही ओव्हरफ्लो होत नाही, आणि + ओव्हरफ्लो अपेक्षित आहे
+            price0CumulativeLast += uint(UQ112x112.encode(_reserve1).uqdiv(_reserve0)) * timeElapsed;
+            price1CumulativeLast += uint(UQ112x112.encode(_reserve0).uqdiv(_reserve1)) * timeElapsed;
+        }
+```
+
+प्रत्येक कॉस्ट अ‍ॅक्युम्युलेटरला नवीनतम कॉस्ट (दुसऱ्या टोकनचा रिझर्व्ह/या टोकनचा रिझर्व्ह) गुणिले सेकंदात गेलेला वेळ यानुसार अपडेट केले जाते. सरासरी किंमत मिळवण्यासाठी, तुम्ही वेळेच्या दोन बिंदूंमधील एकत्रित किंमत वाचता आणि त्यांच्यातील वेळेच्या फरकाने भागता. उदाहरणार्थ, घटनांचा हा क्रम गृहीत धरा:
+
+| इव्हेंट                                                                     |                  reserve0 |                  reserve1 | टाइमस्टॅम्प | सीमान्त विनिमय दर (reserve1 / reserve0) |                                                       price0CumulativeLast |
+| --------------------------------------------------------------------------- | ------------------------: | ------------------------: | ----------- | ---------------------------------------------------------: | -------------------------------------------------------------------------: |
+| प्राथमिक सेटअप                                                              | 1,000.000 | 1,000.000 | 5,000       |                                      1.000 |                                                                          0 |
+| व्यापारी A 50 token0 जमा करतो आणि 47.619 token1 परत मिळवतो  | 1,050.000 |   952.381 | 5,020       |                                      0.907 |                                                                         20 |
+| व्यापारी B 10 token0 जमा करतो आणि 8.984 token1 परत मिळवतो   | 1,060.000 |   943.396 | 5,030       |                                      0.890 |                       20+10\*0.907 = 29.07 |
+| व्यापारी C 40 token0 जमा करतो आणि 34.305 token1 परत मिळवतो  | 1,100.000 |   909.090 | 5,100       |                                      0.826 |    29.07+70\*0.890 = 91.37 |
+| व्यापारी D 100 token1 जमा करतो आणि 109.01 token0 परत मिळवतो |   990.990 | 1,009.090 | 5,110       |                                      1.018 |    91.37+10\*0.826 = 99.63 |
+| व्यापारी E 10 token0 जमा करतो आणि 10.079 token1 परत मिळवतो  | 1,000.990 |   999.010 | 5,150       |                                      0.998 | 99.63+40\*1.1018 = 143.702 |
+
+समजा आपल्याला 5,030 आणि 5,150 टाइमस्टॅम्प दरम्यान **Token0** ची सरासरी किंमत काढायची आहे. `price0Cumulative` च्या मूल्यातील फरक 143.702-29.07=114.632 आहे. ही दोन मिनिटांची (120 सेकंद) सरासरी आहे. म्हणून सरासरी किंमत 114.632/120 = 0.955 आहे.
+
+या किंमतीच्या गणनेमुळेच आपल्याला जुन्या रिझर्व्ह आकारांची माहिती असणे आवश्यक आहे.
+
+```solidity
+एका मॉडिफायरमध्ये `_;` मूळ फंक्शन कॉल (सर्व पॅरामीटर्ससह) असतो.
+```
+
+येथे याचा अर्थ असा आहे की फंक्शन कॉल तेव्हाच होतो जेव्हा `unlocked` कॉल केल्यावर एक होते आणि ते चालू असताना `unlocked` चे मूल्य शून्य असते.
+
+##### ```
+
+    unlocked = 1;
+}
+```
+
+```solidity
+मुख्य फंक्शन परत आल्यानंतर, लॉक सोडा.
+```
+
+विविध फंक्शन्स {#pair-misc}     function getReserves() public view returns (uint112 _reserve0, uint112 _reserve1, uint32 _blockTimestampLast) {
+_reserve0 = reserve0;
+_reserve1 = reserve1;
+_blockTimestampLast = blockTimestampLast;
+}
+
+हे फंक्शन कॉलरला एक्सचेंजच्या सध्याच्या स्थितीबद्दल माहिती देते.
+
+```solidity
+लक्षात घ्या की Solidity फंक्शन्स [एकापेक्षा जास्त मूल्ये परत करू शकतात](https://docs.soliditylang.org/en/v0.8.3/contracts.html#returning-multiple-values).
+```
+
+```
+function _safeTransfer(address token, address to, uint value) private {
+    (bool success, bytes memory data) = token.call(abi.encodeWithSelector(SELECTOR, to, value)); हे अंतर्गत फंक्शन एक्सचेंजमधून ERC20 टोकनची रक्कम दुसऱ्या कोणालातरी हस्तांतरित करते.
+```
+
+```solidity
+`SELECTOR` निर्दिष्ट करते की आपण ज्या फंक्शनला कॉल करत आहोत ते `transfer(address,uint)` आहे (वर व्याख्या पहा).
+```
+
+टोकन फंक्शनसाठी इंटरफेस आयात करणे टाळण्यासाठी, आम्ही [ABI फंक्शन्स](https://docs.soliditylang.org/en/v0.8.3/units-and-global-variables.html#abi-encoding-and-decoding-functions) पैकी एक वापरून "मॅन्युअली" कॉल तयार करतो.
+require(success && (data.length == 0 || abi.decode(data, (bool))), 'UniswapV2: TRANSFER_FAILED');
+}
+
+```solidity
+ERC-20 ट्रान्सफर कॉल अयशस्वी झाल्याची तक्रार करण्याचे दोन मार्ग आहेत:
+```
+
+रिव्हर्ट. जर बाह्य कराराचा कॉल रिव्हर्ट झाला, तर बूलियन रिटर्न व्हॅल्यू `false` असते
+
+```solidity
+सामान्यपणे समाप्त होते परंतु अपयशाची तक्रार करते.
+```
+
+त्या बाबतीत रिटर्न व्हॅल्यू बफरची लांबी शून्य नसते आणि बूलियन व्हॅल्यू म्हणून डीकोड केल्यावर ते `false` असते यापैकी कोणतीही एक अट घडल्यास, रिव्हर्ट करा.
+
+```solidity
+इव्हेंट्स {#pair-events}
+```
+
+```
+event Mint(address indexed sender, uint amount0, uint amount1);
+event Burn(address indexed sender, uint amount0, uint amount1, address indexed to); जेव्हा लिक्विडिटी प्रोव्हायडर एकतर लिक्विडिटी जमा करतो (`Mint`) किंवा काढतो (`Burn`) तेव्हा हे दोन इव्हेंट उत्सर्जित होतात.
+```
+
+```solidity
+दोन्ही बाबतीत, जमा किंवा काढलेल्या token0 आणि token1 ची रक्कम इव्हेंटचा भाग असते, तसेच आम्हाला कॉल करणाऱ्या खात्याची ओळख (`sender`).
+```
+
+पैसे काढण्याच्या बाबतीत, इव्हेंटमध्ये टोकन प्राप्त करणाऱ्या लक्ष्याचा (`to`) देखील समावेश असतो, जो प्रेषकसारखाच असेल असे नाही.
+
+```solidity
+    event Swap(
+        address indexed sender,
+        uint amount0In,
+        uint amount1In,
+        uint amount0Out,
+        uint amount1Out,
+        address indexed to
+    );
+```
+
+जेव्हा व्यापारी एका टोकनसाठी दुसरा टोकन स्वॅप करतो तेव्हा हा इव्हेंट उत्सर्जित होतो. पुन्हा, प्रेषक आणि गंतव्यस्थान समान असू शकत नाहीत.
+प्रत्येक टोकन एकतर एक्सचेंजला पाठवला जाऊ शकतो, किंवा त्यातून प्राप्त केला जाऊ शकतो.
+
+#### ```
+
+event Sync(uint112 reserve0, uint112 reserve1);
+```
+
+शेवटी, `Sync` प्रत्येक वेळी टोकन जोडले किंवा काढले जातात, कारणास्तव काहीही असो, नवीनतम राखीव माहिती (आणि म्हणून विनिमय दर) प्रदान करण्यासाठी उत्सर्जित होते. सेटअप फंक्शन्स {#pair-setup}
+
+##### नवीन पेअर एक्सचेंज सेट केल्यावर ही फंक्शन्स एकदा कॉल केली जावीत.
+
+```solidity
+    constructor() public {
+        factory = msg.sender;
+    }
+```
+
+कन्स्ट्रक्टर हे सुनिश्चित करतो की आम्ही पेअर तयार करणाऱ्या फॅक्टरीच्या पत्त्याचा मागोवा ठेवू. ही माहिती `initialize` आणि फॅक्टरी शुल्कासाठी (जर असेल तर) आवश्यक आहे     // called once by the factory at time of deployment
+function initialize(address _token0, address _token1) external {
+require(msg.sender == factory, 'UniswapV2: FORBIDDEN'); // sufficient check
+token0 = _token0;
+token1 = _token1;
+}
+
+```solidity
+हे फंक्शन फॅक्टरीला (आणि फक्त फॅक्टरीला) दोन ERC-20 टोकन निर्दिष्ट करण्याची परवानगी देते ज्यांचा हा पेअर एक्सचेंज करेल.
+```
+
+अंतर्गत अपडेट फंक्शन्स {#pair-update-internal} \_update
+
+```solidity
+    // update reserves and, on the first call per block, price accumulators
+    function _update(uint balance0, uint balance1, uint112 _reserve0, uint112 _reserve1) private {
+```
+
+जेव्हाही टोकन्स जमा किंवा काढले जातात तेव्हा हे फंक्शन कॉल केले जाते.
+
+```solidity
+        require(balance0 <= uint112(-1) && balance1 <= uint112(-1), 'UniswapV2: OVERFLOW');
+```
+
+जर balance0 किंवा balance1 (uint256) uint112(-1) (=2^112-1) पेक्षा जास्त असेल (म्हणजे ते ओव्हरफ्लो होते आणि uint112 मध्ये रूपांतरित झाल्यावर 0 वर परत येते), तर ओव्हरफ्लो टाळण्यासाठी \_update पुढे चालू ठेवण्यास नकार द्या. सामान्य टोकनसह जे 10^18 युनिट्समध्ये विभागले जाऊ शकते, याचा अर्थ प्रत्येक एक्सचेंज सुमारे 5.1\*10^15 प्रत्येक टोकनपर्यंत मर्यादित आहे.
+
+```solidity
+आतापर्यंत ती समस्या नाही.
+```
+
+```
+    uint32 blockTimestamp = uint32(block.timestamp % 2**32);
+    uint32 timeElapsed = blockTimestamp - blockTimestampLast; // overflow is desired
+    if (timeElapsed > 0 && _reserve0 != 0 && _reserve1 != 0) { जर गेलेला वेळ शून्य नसेल, तर याचा अर्थ आम्ही या ब्लॉकवरील पहिला एक्सचेंज व्यवहार आहोत. त्या बाबतीत, आम्हाला खर्च संचयक अद्यतनित करणे आवश्यक आहे.             // * never overflows, and + overflow is desired
+        price0CumulativeLast += uint(UQ112x112.encode(_reserve1).uqdiv(_reserve0)) * timeElapsed;
+        price1CumulativeLast += uint(UQ112x112.encode(_reserve0).uqdiv(_reserve1)) * timeElapsed;
+    }
+```
+
+प्रत्येक खर्च संचयक नवीनतम खर्चासह (दुसऱ्या टोकनचा राखीव साठा/या टोकनचा राखीव साठा) सेकंदात गेलेल्या वेळेने गुणून अद्यतनित केला जातो.
+
+सरासरी किंमत मिळविण्यासाठी, आपण दोन वेळेच्या बिंदूंवर एकत्रित किंमत वाचता आणि त्यांच्यातील वेळेच्या फरकाने भागता.
+उदाहरणार्थ, घटनांचा हा क्रम गृहीत धरा: एक व्यापारी या वस्तुस्थितीचा वापर करू शकतो की पेअर एक्सचेंजला वाटते की **Token0** अधिक मौल्यवान आहे, त्यातून मूल्य काढण्यासाठी.
+
+| इव्हेंट                                                         | reserve0 | reserve1 | reserve0 \* reserve1 | price0CumulativeLast |
+| --------------------------------------------------------------- | -------: | -------: | -------------------: | -------------------: |
+| प्राथमिक सेटअप                                                  |        8 |       32 |                5,000 |                   40 |
+| व्यापारी 8 **Token0** टोकन्स जमा करतो, 16 **Token1** परत मिळवतो |       16 |       16 |                5,000 |                   32 |
+
+0.907
+
+```solidity
+        } else {
+            liquidity = Math.min(amount0.mul(_totalSupply) / _reserve0, amount1.mul(_totalSupply) / _reserve1);
+```
+
+व्यापारी B ने 10 token0 जमा केले आणि 8.984 token1 परत मिळवले जर ते तसे करत नाहीत, तर आम्ही त्यांना शिक्षा म्हणून त्यांनी प्रदान केलेल्या कमी मूल्याच्या आधारावर लिक्विडिटी टोकन देतो.
+
+ती सुरुवातीची ठेव असो किंवा नंतरची, आम्ही प्रदान केलेल्या लिक्विडिटी टोकन्सची संख्या `reserve0*reserve1` मधील बदलाच्या वर्गमूळाएवढी असते आणि लिक्विडिटी टोकनचे मूल्य बदलत नाही (जोपर्यंत आम्हाला दोन्ही प्रकारांचे समान मूल्य नसलेली ठेव मिळत नाही, ज्या प्रकरणात "दंड" वितरित केला जातो). 5,030
+
+| इव्हेंट                                                                                                                                                                   |                                                                                                                                                  reserve0 |                                                                                                                                                  reserve1 |                                                                              reserve0 \* reserve1 |                                                                                                                          पूल मूल्य (reserve0 + reserve1) | 5,100 | 0.826 |                                                                                                                                                                                                                                                                                                                                                        29.07+70\*0.890 = 91.37 |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------: | ------------------------------------------------------------------------------------------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | ----: | --------------------: | -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
+| प्राथमिक सेटअप                                                                                                                                                            |                                                                                                                                     8.000 |                                                                                                                                     8.000 |                                                                                                64 |                                                                                                                                                       1.018 |     8 |                     8 |                                                                                                                                                                                                                                                                                                                                                                                                          2.000 |
+| प्रत्येक प्रकारातील चार जमा करा                                                                                                                                           |                                                                                                                                                     5,150 |                                                                                                                                                     5,150 |                        99.63+40\*1.1018 = 143.702 |                                                                    समजा आपल्याला 5,030 आणि 5,150 टाइमस्टॅम्प दरम्यान **टोकन0** ची सरासरी किंमत मोजायची आहे. |     4 |                    12 |                                                                                                                                                                                                                                                                                                                                                                                                          2.000 |
+| या किंमतीच्या गणनेमुळेच आपल्याला जुन्या राखीव आकारांची माहिती असणे आवश्यक आहे.                                                                            | ```
+    reserve0 = uint112(balance0);
+    reserve1 = uint112(balance1);
+    blockTimestampLast = blockTimestamp;
+    emit Sync(reserve0, reserve1);
+}
+``` | ```
+    reserve0 = uint112(balance0);
+    reserve1 = uint112(balance1);
+    blockTimestampLast = blockTimestamp;
+    emit Sync(reserve0, reserve1);
+}
+``` |                                                                   \_mintFee | ```
+// if fee is on, mint liquidity equivalent to 1/6th of the growth in sqrt(k)
+function _mintFee(uint112 _reserve0, uint112 _reserve1) private returns (bool feeOn) {
+``` |     2 |                    14 |                                                                                                                                                                                                                                                                                                                                                                                                          2.000 |
+| गणना कमी करण्यासाठी (आणि त्यामुळे गॅस खर्च), हे शुल्क प्रत्येक व्यवहाराऐवजी केवळ लिक्विडिटी जोडताना किंवा पूलमधून काढतानाच मोजले जाते. |                                                          ```
+    address feeTo = IUniswapV2Factory(factory).feeTo();
+    feeOn = feeTo != address(0);
+``` | ```
+    reserve0 = uint112(balance0);
+    reserve1 = uint112(balance1);
+    blockTimestampLast = blockTimestamp;
+    emit Sync(reserve0, reserve1);
+}
+``` | जर ते शून्य असेल तर कोणतेही प्रोटोकॉल शुल्क नाही आणि ते शुल्क मोजण्याची गरज नाही. |                                                                                                                             ```
+    uint _kLast = kLast; // gas savings
+``` |     0 |                    14 |                                                                                                                                                                                                                                                                                                                                                                            ```
+    if (feeOn) {
+        if (_kLast != 0) {
+``` |
+| लिक्विडिटी प्रोव्हायडरला त्यांच्या लिक्विडिटी टोकनच्या मूल्यांकनातून त्यांचा वाटा मिळतो.                                                                  |                                 परंतु प्रोटोकॉल शुल्कासाठी नवीन लिक्विडिटी टोकन्स मिंट करणे आणि `feeTo` पत्त्यावर प्रदान करणे आवश्यक आहे. |                                 परंतु प्रोटोकॉल शुल्कासाठी नवीन लिक्विडिटी टोकन्स मिंट करणे आणि `feeTo` पत्त्यावर प्रदान करणे आवश्यक आहे. | जर ते शून्य असेल तर कोणतेही प्रोटोकॉल शुल्क नाही आणि ते शुल्क मोजण्याची गरज नाही. |                                                                                                        आपण वर्गमूळ फंक्शन [या लेखात नंतर](#Math) पाहू शकता. |     0 |                    14 | आम्हाला माहित आहे की `kLast` ची गणना केल्यापासून आणि वर्तमानापर्यंत कोणतीही लिक्विडिटी जोडली किंवा काढली गेली नाही (कारण आम्ही प्रत्येक वेळी लिक्विडिटी जोडली किंवा काढली जाते तेव्हा ही गणना करतो, ती प्रत्यक्षात बदलण्यापूर्वी), त्यामुळे `reserve0 * reserve1` मधील कोणताही बदल व्यवहार शुल्कातून आला पाहिजे (त्यांच्याशिवाय आम्ही `reserve0 * reserve1` स्थिर ठेवू). |
+
+```solidity
+                    if (liquidity > 0) _mint(feeTo, liquidity);
+                }
+            }
+```
+
+अतिरिक्त लिक्विडिटी टोकन तयार करण्यासाठी आणि त्यांना `feeTo` ला नियुक्त करण्यासाठी `UniswapV2ERC20._mint` फंक्शन वापरा.
+
+```solidity
+        } else if (_kLast != 0) {
+            kLast = 0;
+        }
+    }
+```
+
+जर कोणतेही शुल्क नसेल तर `kLast` शून्यावर सेट करा (जर ते आधीच नसेल तर).
+
+##### जेव्हा हा करार लिहिला गेला होता तेव्हा एक [गॅस परतावा वैशिष्ट्य](https://eips.ethereum.org/EIPS/eip-3298) होते जे करारांना Ethereum राज्याचा एकूण आकार कमी करण्यासाठी प्रोत्साहन देत होते, ज्यासाठी त्यांना आवश्यक नसलेले स्टोरेज शून्यावर आणावे लागत होते.
+
+```solidity
+हा कोड शक्य असेल तेव्हा तो परतावा मिळवतो.
+```
+
+बाह्यरित्या प्रवेश करण्यायोग्य फंक्शन्स {#pair-external}
+लक्षात घ्या की कोणताही व्यवहार किंवा करार ही फंक्शन्स _कॉल_ करू शकतो, तरीही ते परिघ करारातून कॉल करण्यासाठी डिझाइन केलेले आहेत.
+
+```solidity
+जर तुम्ही त्यांना थेट कॉल केले तर तुम्ही पेअर एक्सचेंजला फसवू शकणार नाही, परंतु चुकीमुळे तुमचे मूल्य कमी होऊ शकते.
+```
+
+मिंट     // this low-level function should be called from a contract which performs important safety checks
+function mint(address to) external lock returns (uint liquidity) {
+
+```solidity
+जेव्हा लिक्विडिटी प्रोव्हायडर पूलमध्ये लिक्विडिटी जोडतो तेव्हा हे फंक्शन कॉल केले जाते.
+```
+
+ते बक्षीस म्हणून अतिरिक्त लिक्विडिटी टोकन मिंट करते. हे [परिघ करार](#UniswapV2Router02) मधून कॉल केले पाहिजे जे त्याच व्यवहारात लिक्विडिटी जोडल्यानंतर त्याला कॉल करते (जेणेकरून इतर कोणीही कायदेशीर मालकापूर्वी नवीन लिक्विडिटीचा दावा करणारा व्यवहार सबमिट करू शकणार नाही).
+
+```solidity
+        (uint112 _reserve0, uint112 _reserve1,) = getReserves(); // gas savings
+```
+
+अनेक मूल्ये परत करणाऱ्या Solidity फंक्शनचे परिणाम वाचण्याचा हा मार्ग आहे.
+
+##### आम्ही शेवटची परत केलेली मूल्ये, ब्लॉक टाइमस्टॅम्प, टाकून देतो कारण आम्हाला त्याची गरज नाही.
+
+```solidity
+        uint balance0 = IERC20(token0).balanceOf(address(this));
+        uint balance1 = IERC20(token1).balanceOf(address(this));
+        uint amount0 = balance0.sub(_reserve0);
+        uint amount1 = balance1.sub(_reserve1);
+```
+
+सध्याची शिल्लक मिळवा आणि प्रत्येक टोकन प्रकारात किती जोडले गेले ते पहा.
+
+```solidity
+        bool feeOn = _mintFee(_reserve0, _reserve1);
+```
+
+गोळा करायचे प्रोटोकॉल शुल्क, जर असेल तर, मोजा आणि त्यानुसार लिक्विडिटी टोकन मिंट करा.
+कारण `_mintFee` चे पॅरामीटर्स जुने राखीव मूल्ये आहेत, शुल्क केवळ शुल्कामुळे होणाऱ्या पूल बदलांवर आधारित अचूकपणे मोजले जाते.         uint _totalSupply = totalSupply; // gas savings, must be defined here since totalSupply can update in _mintFee
+if (_totalSupply == 0) {
+liquidity = Math.sqrt(amount0.mul(amount1)).sub(MINIMUM_LIQUIDITY);
+_mint(address(0), MINIMUM_LIQUIDITY); // permanently lock the first MINIMUM_LIQUIDITY tokens
+
+```solidity
+जर ही पहिली ठेव असेल, तर `MINIMUM_LIQUIDITY` टोकन तयार करा आणि त्यांना लॉक करण्यासाठी शून्य पत्त्यावर पाठवा.
+```
+
+ते कधीही रिडीम केले जाऊ शकत नाहीत, याचा अर्थ पूल कधीही पूर्णपणे रिकामा होणार नाही (हे आपल्याला काही ठिकाणी शून्याने भागाकार करण्यापासून वाचवते). `MINIMUM_LIQUIDITY` चे मूल्य एक हजार आहे, जे बहुतेक ERC-20 हे 10^-18 व्या टोकनच्या युनिट्समध्ये विभागलेले आहेत हे लक्षात घेता, जसे ETH वेईमध्ये विभागलेले आहे, ते एकाच टोकनच्या मूल्याच्या 10^-15 आहे.
+
+```solidity
+जास्त खर्च नाही.
+```
+
+पहिल्या ठेवीच्या वेळी आम्हाला दोन टोकनचे सापेक्ष मूल्य माहित नसते, म्हणून आम्ही फक्त रक्कम गुणतो आणि वर्गमूळ घेतो, असे गृहीत धरून की ठेव आम्हाला दोन्ही टोकनमध्ये समान मूल्य प्रदान करते.
+
+```solidity
+आपण यावर विश्वास ठेवू शकतो कारण समान मूल्य प्रदान करणे ठेवकर्त्याच्या हिताचे आहे, जेणेकरून आर्बिट्रेजमुळे मूल्य गमावू नये.
+```
+
+समजा दोन टोकनचे मूल्य समान आहे, परंतु आमच्या ठेवकर्त्याने **टोकन0** पेक्षा चार पट जास्त **टोकन1** जमा केले. एक व्यापारी या वस्तुस्थितीचा वापर करू शकतो की पेअर एक्सचेंजला वाटते की **टोकन0** अधिक मौल्यवान आहे, त्यातून मूल्य काढण्यासाठी. यामुळे कॉन्ट्रॅक्टला फसवणूक होत नाही हे तपासणे सोपे होते, ही तपासणी कोअर कॉन्ट्रॅक्टमध्येच _व्हावी_ लागते (कारण आम्हाला आमच्या पेरिफेरी कॉन्ट्रॅक्टव्यतिरिक्त इतर घटकांद्वारे कॉल केले जाऊ शकते).
+
+```solidity
+        uint amount0In = balance0 > _reserve0 - amount0Out ? balance0 - (_reserve0 - amount0Out) : 0;
+        uint amount1In = balance1 > _reserve1 - amount1Out ? balance1 - (_reserve1 - amount1Out) : 0;
+        require(amount0In > 0 || amount1In > 0, 'UniswapV2: INSUFFICIENT_INPUT_AMOUNT');
+        { // reserve{0,1}Adjusted साठी स्कोप, स्टॅक खूप खोल त्रुटी टाळतो
+            uint balance0Adjusted = balance0.mul(1000).sub(amount0In.mul(3));
+            uint balance1Adjusted = balance1.mul(1000).sub(amount1In.mul(3));
+            require(balance0Adjusted.mul(balance1Adjusted) >= uint(_reserve0).mul(_reserve1).mul(1000**2), 'UniswapV2: K');
+```
+
+स्वॅपमधून आपले नुकसान होणार नाही याची खात्री करण्यासाठी ही एक सॅनिटी चेक आहे. अशी कोणतीही परिस्थिती नाही ज्यात स्वॅपमुळे `reserve0*reserve1` कमी व्हावे. पूलचे मूल्य (reserve0 + reserve1)
+
+```solidity
+        }
+
+        _update(balance0, balance1, _reserve0, _reserve1);
+        emit Swap(msg.sender, amount0In, amount1In, amount0Out, amount1Out, to);
+    }
+```
+
+`reserve0` आणि `reserve1` अपडेट करा, आणि आवश्यक असल्यास प्राइस अ‍ॅक्युम्युलेटर (price accumulators) आणि टाइमस्टॅम्प अपडेट करा आणि एक इव्हेंट उत्सर्जित करा.
+
+##### सिंक किंवा स्किम
+
+256
+कॉन्ट्रॅक्टच्या संमतीशिवाय टोकन काढण्याचा कोणताही मार्ग नाही, परंतु डिपॉझिट ही एक वेगळी बाब आहे. व्यापारी 8 **टोकन0** टोकन्स जमा करतो, 16 **टोकन1** परत मिळवतो
+
+त्या बाबतीत दोन उपाय आहेत:
+
+- `sync`, रिझर्व्हस्ना सध्याच्या बॅलन्सवर अपडेट करा
+- `skim`, अतिरिक्त रक्कम काढा. लक्षात घ्या की कोणत्याही खात्याला `skim` कॉल करण्याची परवानगी आहे कारण आम्हाला माहित नाही की टोकन कोणी जमा केले. जसे आपण पाहू शकता, व्यापाऱ्याने अतिरिक्त 8 टोकन कमावले, जे पूलच्या मूल्यात घट झाल्यामुळे येतात, ज्यामुळे त्याच्या मालकीच्या ठेवकर्त्याला दुखापत होते.
+
+```solidity
+        } else {
+            liquidity = Math.min(amount0.mul(_totalSupply) / _reserve0, amount1.mul(_totalSupply) / _reserve1);
+```
+
+### प्रत्येक त्यानंतरच्या ठेवीसह आम्हाला दोन मालमत्तांमधील विनिमय दर आधीच माहित आहे, आणि आम्ही अपेक्षा करतो की लिक्विडिटी प्रदाता दोन्हीमध्ये समान मूल्य प्रदान करतील.
+
+जर ते तसे करत नाहीत, तर आम्ही त्यांना शिक्षा म्हणून त्यांनी प्रदान केलेल्या कमी मूल्यावर आधारित लिक्विडिटी टोकन देतो.
+
+```solidity
+ती प्रारंभिक ठेव असो किंवा त्यानंतरची, आम्ही प्रदान करत असलेल्या लिक्विडिटी टोकनची संख्या `reserve0*reserve1` मधील बदलाच्या वर्गमूळाच्या बरोबरीची असते आणि लिक्विडिटी टोकनचे मूल्य बदलत नाही (जोपर्यंत आम्हाला अशी ठेव मिळत नाही ज्यात दोन्ही प्रकारांची समान मूल्ये नसतात, अशावेळी "दंड" वितरीत केला जातो).
+```
+
+येथे समान मूल्याच्या दोन टोकनसह दुसरे उदाहरण आहे, ज्यात तीन चांगल्या ठेवी आणि एक वाईट ठेव आहे (फक्त एका टोकन प्रकाराची ठेव, त्यामुळे ते कोणतेही लिक्विडिटी टोकन तयार करत नाही).
+`feeTo` ॲड्रेस प्रोटोकॉल फीसाठी लिक्विडिटी टोकन जमा करतो, आणि `feeToSetter` हा `feeTo` ला वेगळ्या ॲड्रेसवर बदलण्याची परवानगी असलेला ॲड्रेस आहे.
+
+```solidity
+    mapping(address => mapping(address => address)) public getPair;
+    address[] public allPairs;
+```
+
+हे व्हेरिएबल्स पेअर्सचा, म्हणजेच दोन टोकन प्रकारांमधील एक्सचेंजचा मागोवा ठेवतात.
+
+पहिले, `getPair`, हे एक मॅपिंग आहे जे दोन ERC-20 टोकन्सच्या आधारे पेअर एक्सचेंज कॉन्ट्रॅक्ट ओळखते ज्यांची ते देवाणघेवाण करते. पूल मूल्य (reserve0 + reserve1) या ठेवीसाठी तयार केलेले लिक्विडिटी टोकन
+
+एकूण लिक्विडिटी टोकन्स प्रत्येक लिक्विडिटी टोकनचे मूल्य
+
+टीप: मॅपिंगच्या सर्व कीज (keys) वर पुनरावृत्ती (iterate) न करू शकण्याचे कारण म्हणजे कॉन्ट्रॅक्ट डेटा स्टोरेज _महाग_ आहे, म्हणून आपण जितके कमी वापरू तितके चांगले आणि जितके कमी वेळा बदलू तितके चांगले. 8.000 बहुतेक ऍप्लिकेशन्समध्ये तुम्हाला त्याची गरज नसते.
+
+```solidity
+    event PairCreated(address indexed token0, address indexed token1, address pair, uint);
+```
+
+16.000 यात टोकन्सचे ॲड्रेस, पेअर एक्सचेंजचा ॲड्रेस आणि फॅक्टरीद्वारे व्यवस्थापित केलेल्या एकूण एक्सचेंजची संख्या समाविष्ट आहे.
+
+```solidity
+    constructor(address _feeToSetter) public {
+        feeToSetter = _feeToSetter;
+    }
+```
+
+2.000 प्रत्येक प्रकारचे चार जमा करा
+
+```solidity
+12.000
+```
+
+हे फंक्शन एक्सचेंज पेअर्सची संख्या परत करते.
+
+```solidity
+144
+```
+
+24.000 लक्षात घ्या की कोणीही हे फंक्शन कॉल करू शकतो. नवीन पेअर एक्सचेंज तयार करण्यासाठी तुम्हाला Uniswap कडून परवानगीची आवश्यकता नाही.
+
+```solidity
+        require(tokenA != tokenB, 'UniswapV2: IDENTICAL_ADDRESSES');
+        (address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
+```
+
+प्रत्येक प्रकारचे दोन जमा करा
+14.000
+
+```solidity
+        require(token0 != address(0), 'UniswapV2: ZERO_ADDRESS');
+        require(getPair[token0][token1] == address(0), 'UniswapV2: PAIR_EXISTS'); // एकच तपासणी पुरेशी आहे
+```
+
+196 28.000 जर आधीपासूनच एक्सचेंज अस्तित्वात असेल, तर त्याच पेअरसाठी दुसरे तयार करण्याची गरज नाही.
+
+```solidity
+        bytes memory bytecode = type(UniswapV2Pair).creationCode;
+```
+
+नवीन कॉन्ट्रॅक्ट तयार करण्यासाठी आम्हाला तो तयार करणारा कोड आवश्यक आहे (कन्स्ट्रक्टर फंक्शन आणि प्रत्यक्ष कॉन्ट्रॅक्टचा EVM बायकोड मेमरीमध्ये लिहिणारा कोड दोन्ही). असमान मूल्य ठेव
+18.000 ही आता समस्या नाही, कारण [Solidity आता CREATE2 ला सपोर्ट करते](https://docs.soliditylang.org/en/v0.8.3/control-structures.html#salted-contract-creations-create2).
+
+```solidity
+252
+```
+
+32.000
+
+```solidity
+        IUniswapV2Pair(pair).initialize(token0, token1);
+```
+
+नवीन एक्सचेंजला ते कोणते दोन टोकन एक्सचेंज करते हे सांगण्यासाठी `initialize` फंक्शनला कॉल करा.
+
+```solidity
+~2.286
+```
+
+आर्बिट्रेजनंतर
+
+```solidity
+~15.874
+```
+
+हे दोन फंक्शन्स `feeSetter` ला फी प्राप्तकर्त्यावर (असल्यास) नियंत्रण ठेवण्याची आणि `feeSetter` ला नवीन ॲड्रेसवर बदलण्याची परवानगी देतात.
+
+### UniswapV2ERC20.sol {#UniswapV2ERC20}
+
+~31.748 हे [OpenZeppelin ERC-20 कॉन्ट्रॅक्ट](/developers/tutorials/erc20-annotated-code) सारखेच आहे, म्हणून मी फक्त वेगळा असलेला भाग, `permit` फंक्शनॅलिटी समजावून सांगेन.
+
+Ethereum वरील व्यवहारांसाठी इथर (ETH) खर्च होतो, जो खऱ्या पैशाच्या समतुल्य आहे. ~2.267         }
+require(liquidity > 0, 'UniswapV2: INSUFFICIENT_LIQUIDITY_MINTED');
+_mint(to, liquidity);
+अतिरिक्त लिक्विडिटी टोकन तयार करण्यासाठी आणि त्यांना योग्य खात्यात देण्यासाठी `UniswapV2ERC20._mint` फंक्शन वापरा.
+_update(balance0, balance1, _reserve0, _reserve1);
+if (feeOn) kLast = uint(reserve0).mul(reserve1); // reserve0 and reserve1 are up-to-date
+emit Mint(msg.sender, amount0, amount1);
+}
+
+```solidity
+स्टेट व्हेरिएबल्स (`reserve0`, `reserve1`, आणि आवश्यक असल्यास `kLast`) अद्यतनित करा आणि योग्य इव्हेंट उत्सर्जित करा.
+```
+
+बर्न     // this low-level function should be called from a contract which performs important safety checks
+function burn(address to) external lock returns (uint amount0, uint amount1) {
+
+```solidity
+जेव्हा लिक्विडिटी काढली जाते आणि योग्य लिक्विडिटी टोकन बर्न करणे आवश्यक असते तेव्हा हे फंक्शन कॉल केले जाते.
+```
+
+हे [परिघ खात्या](#UniswapV2Router02) मधून देखील कॉल केले पाहिजे.         (uint112 _reserve0, uint112 _reserve1,) = getReserves(); // gas savings
+address _token0 = token0;                                // gas savings
+address _token1 = token1;                                // gas savings
+uint balance0 = IERC20(_token0).balanceOf(address(this));
+uint balance1 = IERC20(_token1).balanceOf(address(this));
+uint liquidity = balanceOf[address(this)]; परिघ कराराने कॉल करण्यापूर्वी बर्न करण्यासाठी लिक्विडिटी या करारात हस्तांतरित केली. त्यामुळे आम्हाला माहित आहे की किती लिक्विडिटी बर्न करायची आहे आणि आम्ही खात्री करू शकतो की ती बर्न होईल.
+
+```solidity
+        bool feeOn = _mintFee(_reserve0, _reserve1);
+        uint _totalSupply = totalSupply; // gas savings, must be defined here since totalSupply can update in _mintFee
+        amount0 = liquidity.mul(balance0) / _totalSupply; // using balances ensures pro-rata distribution
+        amount1 = liquidity.mul(balance1) / _totalSupply; // using balances ensures pro-rata distribution
+        require(amount0 > 0 && amount1 > 0, 'UniswapV2: INSUFFICIENT_LIQUIDITY_BURNED');
+```
+
+लिक्विडिटी प्रोव्हायडरला दोन्ही टोकनचे समान मूल्य मिळते. यामुळे आपण विनिमय दर बदलत नाही.         _burn(address(this), liquidity);
+_safeTransfer(_token0, to, amount0);
+_safeTransfer(_token1, to, amount1);
+balance0 = IERC20(_token0).balanceOf(address(this));
+balance1 = IERC20(_token1).balanceOf(address(this));```
+    _update(balance0, balance1, _reserve0, _reserve1);
+    if (feeOn) kLast = uint(reserve0).mul(reserve1); // reserve0 and reserve1 are up-to-date
+    emit Burn(msg.sender, amount0, amount1, to);
+}
+```
+
+```solidity
+`burn` फंक्शनचा उर्वरित भाग वरील `mint` फंक्शनचा आरसा प्रतिमा आहे.
+```
+
+स्वॅप
+
+```solidity
+    // this low-level function should be called from a contract which performs important safety checks
+    function swap(uint amount0Out, uint amount1Out, address to, bytes calldata data) external lock {
+```
+
+हे फंक्शन [परिघ करार](#UniswapV2Router02) मधून कॉल केले जाणे अपेक्षित आहे.         require(amount0Out > 0 || amount1Out > 0, 'UniswapV2: INSUFFICIENT_OUTPUT_AMOUNT');
+(uint112 _reserve0, uint112 _reserve1,) = getReserves(); // gas savings
+require(amount0Out < _reserve0 && amount1Out < _reserve1, 'UniswapV2: INSUFFICIENT_LIQUIDITY');```
+    uint balance0;
+    uint balance1;
+    { // scope for _token{0,1}, avoids stack too deep errors
+```
+
+```solidity
+स्थानिक व्हेरिएबल्स एकतर मेमरीमध्ये किंवा, जर ते जास्त नसतील तर, थेट स्टॅकवर संग्रहित केले जाऊ शकतात.
+```
+
+जर आपण संख्या मर्यादित करू शकलो तर आपण स्टॅक वापरू ज्यामुळे कमी गॅस वापरला जाईल.
+
+```solidity
+अधिक माहितीसाठी [पिवळे कागदपत्र, अधिकृत Ethereum तपशील](https://ethereum.github.io/yellowpaper/paper.pdf), पृष्ठ २६, समीकरण २९८ पहा.
+```
+
+```
+        address _token0 = token0;
+        address _token1 = token1;
+        require(to != _token0 && to != _token1, 'UniswapV2: INVALID_TO');
+        if (amount0Out > 0) _safeTransfer(_token0, to, amount0Out); // optimistically transfer tokens
+        if (amount1Out > 0) _safeTransfer(_token1, to, amount1Out); // optimistically transfer tokens हे हस्तांतरण आशावादी आहे, कारण सर्व अटी पूर्ण झाल्या आहेत याची खात्री करण्यापूर्वी आम्ही हस्तांतरण करतो.
+```
+
+Ethereum मध्ये हे ठीक आहे कारण जर कॉलमध्ये नंतर अटी पूर्ण झाल्या नाहीत तर आम्ही त्यातून आणि त्याने तयार केलेल्या कोणत्याही बदलांमधून रिव्हर्ट करतो.
+
+```solidity
+            if (data.length > 0) IUniswapV2Callee(to).uniswapV2Call(msg.sender, amount0Out, amount1Out, data);
+```
+
+मागणी केल्यास प्राप्तकर्त्याला स्वॅपबद्दल माहिती द्या.
+
+```solidity
+            balance0 = IERC20(_token0).balanceOf(address(this));
+            balance1 = IERC20(_token1).balanceOf(address(this));
+        }
+```
+
+सध्याची शिल्लक मिळवा.
+
+## परिघ करार आम्हाला स्वॅपसाठी कॉल करण्यापूर्वी टोकन्स पाठवतो.
+
+यामुळे कराराला त्याची फसवणूक होत नाही हे तपासणे सोपे होते, ही तपासणी _मुख्य करारामध्ये_ होणे आवश्यक आहे (कारण आम्हाला आमच्या परिघ कराराव्यतिरिक्त इतर घटकांकडून कॉल केला जाऊ शकतो).         uint amount0In = balance0 > _reserve0 - amount0Out ? balance0 - (_reserve0 - amount0Out) : 0;
+uint amount1In = balance1 > _reserve1 - amount1Out ? balance1 - (_reserve1 - amount1Out) : 0;
+require(amount0In > 0 || amount1In > 0, 'UniswapV2: INSUFFICIENT_INPUT_AMOUNT');
+{ // scope for reserve{0,1}Adjusted, avoids stack too deep errors
+uint balance0Adjusted = balance0.mul(1000).sub(amount0In.mul(3));
+uint balance1Adjusted = balance1.mul(1000).sub(amount1In.mul(3));
+require(balance0Adjusted.mul(balance1Adjusted) >= uint(_reserve0).mul(_reserve1).mul(1000\*\*2), 'UniswapV2: K'); स्वॅपमधून आम्हाला नुकसान होत नाही याची खात्री करण्यासाठी ही एक sanity check आहे. कोणत्याही परिस्थितीत स्वॅपने `reserve0*reserve1` कमी करू नये. येथेच आम्ही खात्री करतो की स्वॅपवर 0.3% शुल्क पाठवले जात आहे; K चे मूल्य तपासण्यापूर्वी, आम्ही दोन्ही शिल्लक 1000 ने गुणतो आणि रकमेला 3 ने गुणून वजा करतो, याचा अर्थ 0.3% (3/1000 = 0.003 = 0.3%) शिल्लक मधून वजा केले जात आहे, त्याच्या K मूल्याची सध्याच्या राखीव K मूल्याशी तुलना करण्यापूर्वी.
+
+### ```
+
+    }
+
+    _update(balance0, balance1, _reserve0, _reserve1);
+    emit Swap(msg.sender, amount0In, amount1In, amount0Out, amount1Out, to);
+}
+```
+
+`reserve0` आणि `reserve1` अद्यतनित करा, आणि आवश्यक असल्यास किंमत संचयक आणि टाइमस्टॅम्प आणि एक इव्हेंट उत्सर्जित करा. सिंक किंवा स्किम
+
+### पेअर एक्सचेंजला वाटणाऱ्या राखीव साठ्याशी वास्तविक शिल्लक सिंकच्या बाहेर जाणे शक्य आहे.
+
+कराराच्या संमतीशिवाय टोकन काढण्याचा कोणताही मार्ग नाही, परंतु ठेवी वेगळी बाब आहे.
+एक खाते `mint` किंवा `swap` कॉल न करता एक्सचेंजला टोकन हस्तांतरित करू शकते.
+
+```solidity
+त्या बाबतीत दोन उपाय आहेत:
+```
+
+`sync`, राखीव साठा सध्याच्या शिल्लकनुसार अद्यतनित करा `skim`, अतिरिक्त रक्कम काढा. लक्षात घ्या की कोणत्याही खात्याला `skim` कॉल करण्याची परवानगी आहे कारण आम्हाला माहित नाही की टोकन कोणी जमा केले. ही माहिती एका इव्हेंटमध्ये उत्सर्जित केली जाते, परंतु इव्हेंट ब्लॉकचेनमधून प्रवेश करण्यायोग्य नाहीत.     // force balances to match reserves
+function skim(address to) external lock {
+address _token0 = token0; // gas savings
+address _token1 = token1; // gas savings
+_safeTransfer(_token0, to, IERC20(_token0).balanceOf(address(this)).sub(reserve0));
+_safeTransfer(_token1, to, IERC20(_token1).balanceOf(address(this)).sub(reserve1));
+}```
+// force reserves to match balances
+function sync() external lock {
+    _update(IERC20(token0).balanceOf(address(this)), IERC20(token1).balanceOf(address(this)), reserve0, reserve1);
+}
+```} UniswapV2Factory.sol {#UniswapV2Factory} [हा करार](https://github.com/Uniswap/uniswap-v2-core/blob/master/contracts/UniswapV2Factory.sol) पेअर एक्सचेंजेस तयार करतो.
+
+```solidity
+pragma solidity =0.5.16;
+
+import './interfaces/IUniswapV2Factory.sol';
+import './UniswapV2Pair.sol';
+
+contract UniswapV2Factory is IUniswapV2Factory {
+    address public feeTo;
+    address public feeToSetter;
+```
+
+प्रोटोकॉल शुल्क लागू करण्यासाठी हे स्टेट व्हेरिएबल्स आवश्यक आहेत ([व्हाइटपेपर](https://app.uniswap.org/whitepaper.pdf), पृष्ठ 5 पहा). `feeTo` पत्ता प्रोटोकॉल शुल्कासाठी लिक्विडिटी टोकन जमा करतो, आणि `feeToSetter` हा `feeTo` वेगळ्या पत्त्यावर बदलण्यास परवानगी असलेला पत्ता आहे.     mapping(address => mapping(address => address)) public getPair;
+address[] public allPairs;
+
+```solidity
+हे व्हेरिएबल्स पेअर्सचा, दोन टोकन प्रकारांमधील एक्सचेंजेसचा मागोवा ठेवतात.
+```
+
+पहिले, `getPair`, एक मॅपिंग आहे जे दोन ERC-20 टोकनच्या आधारावर पेअर एक्सचेंज करार ओळखते.
+
+```solidity
+ERC-20 टोकन्स त्यांच्या अंमलबजावणी करणाऱ्या करारांच्या पत्त्यांवरून ओळखले जातात, त्यामुळे की आणि मूल्य सर्व पत्ते आहेत.
+```
+
+`tokenA` वरून `tokenB` मध्ये रूपांतरित करणाऱ्या पेअर एक्सचेंजचा पत्ता मिळवण्यासाठी, तुम्ही `getPair[<tokenA address>][<tokenB address>]` (किंवा उलट) वापरता.
+
+```solidity
+दुसरे व्हेरिएबल, `allPairs`, एक अॅरे आहे ज्यात या फॅक्टरीद्वारे तयार केलेल्या पेअर एक्सचेंजेसचे सर्व पत्ते समाविष्ट आहेत.
+```
+
+Ethereum मध्ये तुम्ही मॅपिंगच्या सामग्रीवर पुनरावृत्ती करू शकत नाही, किंवा सर्व कीची सूची मिळवू शकत नाही, म्हणून हे व्हेरिएबलच या फॅक्टरीद्वारे व्यवस्थापित केलेल्या एक्सचेंजेसची माहिती मिळवण्याचा एकमेव मार्ग आहे. टीप: तुम्ही मॅपिंगच्या सर्व कीवर पुनरावृत्ती करू शकत नाही याचे कारण असे की करार डेटा स्टोरेज _महाग_ आहे, त्यामुळे आपण जितके कमी वापरू तितके चांगले, आणि आपण ते जितके कमी बदलू तितके चांगले.
+
+#### तुम्ही [पुनरावृत्तीला समर्थन देणारे मॅपिंग](https://github.com/ethereum/dapp-bin/blob/master/library/iterable_mapping.sol) तयार करू शकता, परंतु त्यांना कीच्या सूचीसाठी अतिरिक्त स्टोरेजची आवश्यकता असते.
+
+बहुतेक ॲप्लिकेशन्समध्ये तुम्हाला त्याची गरज नसते.
+
+```solidity
+    event PairCreated(address indexed token0, address indexed token1, address pair, uint);
+```
+
+जेव्हा नवीन पेअर एक्सचेंज तयार केले जाते तेव्हा हा इव्हेंट उत्सर्जित होतो.
+
+```solidity
+यात टोकनचे पत्ते, पेअर एक्सचेंजचा पत्ता आणि फॅक्टरीद्वारे व्यवस्थापित केलेल्या एकूण एक्सचेंजेसची संख्या समाविष्ट आहे.
+```
+
+```
+constructor(address _feeToSetter) public {
+    feeToSetter = _feeToSetter;
+}
+```
+
+```solidity
+कन्स्ट्रक्टर फक्त `feeToSetter` निर्दिष्ट करतो.
+```
+
+फॅक्टरीज शुल्काशिवाय सुरू होतात, आणि फक्त `feeSetter` ते बदलू शकतो.     function allPairsLength() external view returns (uint) {
+return allPairs.length;
+}
+
+```solidity
+हे फंक्शन एक्सचेंज पेअर्सची संख्या परत करते.
+```
+
+```
+function createPair(address tokenA, address tokenB) external returns (address pair) { फॅक्टरीचे मुख्य कार्य म्हणजे दोन ERC-20 टोकनमध्ये पेअर एक्सचेंज तयार करणे. लक्षात घ्या की कोणीही हे फंक्शन कॉल करू शकते.
+```
+
+नवीन पेअर एक्सचेंज तयार करण्यासाठी तुम्हाला Uniswap कडून परवानगीची गरज नाही.         require(tokenA != tokenB, 'UniswapV2: IDENTICAL_ADDRESSES');
+(address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
+
+आम्हाला नवीन एक्सचेंजचा पत्ता निश्चित हवा आहे, जेणेकरून तो ऑफचेन आगाऊ मोजला जाऊ शकेल (हे [लेयर 2 व्यवहारांसाठी](/developers/docs/scaling/) उपयुक्त ठरू शकते).
+
+| पॅरामीटर                                                                                                                                                                                  |                                                                                                                                                                                                                                                                                      मूल्य |
+| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
+| मोठे लिक्विडिटी पूल लहान पूलांपेक्षा चांगले असतात, कारण त्यांच्या किंमती अधिक स्थिर असतात.                                                                                |                                                                                                                                                                                                        आम्हाला प्रति टोकन जोडीसाठी एकापेक्षा जास्त लिक्विडिटी पूल नको आहे. |
+| जर आधीच एक एक्सचेंज असेल, तर त्याच जोडीसाठी दुसरा तयार करण्याची गरज नाही.                                                                                                 |                                                                                                                                                                                                        आम्हाला प्रति टोकन जोडीसाठी एकापेक्षा जास्त लिक्विडिटी पूल नको आहे. |
+| नवीन करार तयार करण्यासाठी आम्हाला तो तयार करणारा कोड आवश्यक आहे (कन्स्ट्रक्टर फंक्शन आणि वास्तविक कराराचा EVM बायटकोड मेमरीमध्ये लिहिणारा कोड दोन्ही). | सामान्यतः Solidity मध्ये आपण फक्त `addr = new <name of contract>(<constructor parameters>)` वापरतो आणि कंपायलर आमच्यासाठी सर्व काही हाताळतो, परंतु एक निश्चित करार पत्ता मिळवण्यासाठी आम्हाला [CREATE2 ऑपकोड](https://eips.ethereum.org/EIPS/eip-1014) वापरण्याची गरज आहे. |
+| जेव्हा हा कोड लिहिला गेला होता तेव्हा तो ऑपकोड अजूनही Solidity द्वारे समर्थित नव्हता, म्हणून कोड मॅन्युअली मिळवणे आवश्यक होते.                                            |                                                                                                         ही आता समस्या नाही, कारण [Solidity आता CREATE2 ला समर्थन देते](https://docs.soliditylang.org/en/v0.8.3/control-structures.html#salted-contract-creations-create2). |
+
+```
+    bytes32 salt = keccak256(abi.encodePacked(token0, token1));
+    assembly {
+        pair := create2(0, add(bytecode, 32), mload(bytecode), salt)
+    } जेव्हा एखादा ऑपकोड Solidity द्वारे अजून समर्थित नसतो तेव्हा आपण त्याला [इनलाइन असेंब्ली](https://docs.soliditylang.org/en/v0.8.3/assembly.html) वापरून कॉल करू शकतो.
+```
+
+```
+    IUniswapV2Pair(pair).initialize(token0, token1); नवीन एक्सचेंजला कोणते दोन टोकन एक्सचेंज करायचे आहेत हे सांगण्यासाठी `initialize` फंक्शनला कॉल करा.
+```
+
+```solidity
+        getPair[token0][token1] = pair;
+        getPair[token1][token0] = pair; // populate mapping in the reverse direction
+        allPairs.push(pair);
+        emit PairCreated(token0, token1, pair, allPairs.length);
+    }
+```
+
+नवीन जोडीची माहिती स्टेट व्हेरिएबल्समध्ये सेव्ह करा आणि नवीन जोडी एक्सचेंजची माहिती जगाला देण्यासाठी एक इव्हेंट उत्सर्जित करा.
+
+```solidity
+    function setFeeTo(address _feeTo) external {
+        require(msg.sender == feeToSetter, 'UniswapV2: FORBIDDEN');
+        feeTo = _feeTo;
+    }
+
+    function setFeeToSetter(address _feeToSetter) external {
+        require(msg.sender == feeToSetter, 'UniswapV2: FORBIDDEN');
+        feeToSetter = _feeToSetter;
+    }
+}
+```
+
+ही दोन फंक्शन्स `feeSetter` ला शुल्क प्राप्तकर्ता (जर असेल तर) नियंत्रित करण्यास आणि `feeSetter` ला नवीन पत्त्यावर बदलण्यास परवानगी देतात.
+
+```solidity
+UniswapV2ERC20.sol {#UniswapV2ERC20}
+```
+
+[हा करार](https://github.com/Uniswap/uniswap-v2-core/blob/master/contracts/UniswapV2ERC20.sol) ERC-20 लिक्विडिटी टोकन लागू करतो.
+
+```solidity
+हे [OpenZeppelin ERC-20 करार](/developers/tutorials/erc20-annotated-code) सारखेच आहे, म्हणून मी फक्त वेगळा भाग, `permit` कार्यक्षमता स्पष्ट करेन.
+```
+
+Ethereum वरील व्यवहारांसाठी इथर (ETH) लागते, जे खऱ्या पैशाच्या समतुल्य आहे. तुमच्याकडे ERC-20 टोकन्स असतील पण ETH नसेल, तर तुम्ही व्यवहार पाठवू शकत नाही, त्यामुळे तुम्ही त्यांच्यासोबत काहीही करू शकत नाही.
+
+```solidity
+ही समस्या टाळण्यासाठी एक उपाय म्हणजे [मेटा-ट्रान्झॅक्शन्स](https://docs.uniswap.org/contracts/v2/guides/smart-contract-integration/supporting-meta-transactions).
+```
+
+टोकनचा मालक एका व्यवहारावर स्वाक्षरी करतो ज्यामुळे दुसऱ्या कोणालातरी ऑफचेन टोकन काढण्याची परवानगी मिळते आणि ते इंटरनेटद्वारे प्राप्तकर्त्याला पाठवतो. प्राप्तकर्ता, ज्याच्याकडे ETH आहे, तो मालकाच्या वतीने परवानगी सादर करतो.
+
+```solidity
+    bytes32 public DOMAIN_SEPARATOR;
+    // keccak256("Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)");
+    bytes32 public constant PERMIT_TYPEHASH = 0x6e71edae12b1b97f4d1f60370fef10105fa2faae0126114a169c64845d6126c9;
+```
+
+हा हॅश [व्यवहार प्रकारासाठी ओळखकर्ता](https://eips.ethereum.org/EIPS/eip-712#rationale-for-typehash) आहे.
+
+```solidity
+आम्ही येथे फक्त या पॅरामीटर्ससह `Permit` ला समर्थन देतो.
+```
+
+```
+mapping(address => uint) public nonces; प्राप्तकर्त्यासाठी डिजिटल स्वाक्षरी बनावट करणे शक्य नाही. तथापि, समान व्यवहार दोनदा पाठवणे क्षुल्लक आहे (हा [रिप्ले हल्ला](https://wikipedia.org/wiki/Replay_attack) चा एक प्रकार आहे).
+```
+
+हे टाळण्यासाठी, आम्ही [नॉन्स](https://wikipedia.org/wiki/Cryptographic_nonce) वापरतो. जर नवीन `Permit` चा नॉन्स शेवटच्या वापरलेल्या नॉन्सपेक्षा एक जास्त नसेल, तर आम्ही ते अवैध मानतो.     constructor() public {
+uint chainId;
+assembly {
+chainId := chainid
+} हा [चेन आयडेंटिफायर](https://chainid.network/) मिळवण्यासाठी कोड आहे. हे [Yul](https://docs.soliditylang.org/en/v0.8.4/yul.html) नावाच्या EVM असेंब्ली बोलीचा वापर करते. लक्षात घ्या की Yul च्या सध्याच्या आवृत्तीमध्ये तुम्हाला `chainid()` वापरावे लागेल, `chainid` नाही.
+
+```
+    DOMAIN_SEPARATOR = keccak256(
+        abi.encode(
+            keccak256('EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)'),
+            keccak256(bytes(name)),
+            keccak256(bytes('1')),
+            chainId,
+            address(this)
+        )
+    );
+```
+
+EIP-712 साठी [डोमेन विभाजक](https://eips.ethereum.org/EIPS/eip-712#rationale-for-domainseparator) मोजा.     function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external {
+
+```solidity
+हे फंक्शन परवानगी लागू करते.
+```
+
+ते पॅरामीटर्स म्हणून संबंधित फील्ड्स आणि [स्वाक्षरीसाठी](https://yos.io/2018/11/16/ethereum-signatures/) तीन स्केलर मूल्ये (v, r, आणि s) प्राप्त करते.         require(deadline >= block.timestamp, 'UniswapV2: EXPIRED');
+
+.         bytes32 digest = keccak256(
+abi.encodePacked(
+'\x19\x01',
+DOMAIN_SEPARATOR,
+keccak256(abi.encode(PERMIT_TYPEHASH, owner, spender, value, nonces[owner]++, deadline))
+)
+); `abi.encodePacked(...)` हा संदेश आहे जो आम्हाला मिळण्याची अपेक्षा आहे.
+
+```solidity
+आम्हाला माहित आहे की नॉन्स काय असावे, म्हणून आम्हाला ते पॅरामीटर म्हणून मिळवण्याची गरज नाही.
+```
+
+Ethereum स्वाक्षरी अल्गोरिदमला स्वाक्षरी करण्यासाठी 256 बिट्सची अपेक्षा असते, म्हणून आम्ही `keccak256` हॅश फंक्शन वापरतो.         address recoveredAddress = ecrecover(digest, v, r, s);
+
+```solidity
+डायजेस्ट आणि स्वाक्षरीवरून आपण [ecrecover](https://coders-errand.com/ecrecover-signature-verification-ethereum/) वापरून स्वाक्षरी करणारा पत्ता मिळवू शकतो.
+```
+
+```
+    require(recoveredAddress != address(0) && recoveredAddress == owner, 'UniswapV2: INVALID_SIGNATURE');
+    _approve(owner, spender, value);
+}
+```
+
+```solidity
+जर सर्व काही ठीक असेल, तर याला [ERC-20 approve](https://eips.ethereum.org/EIPS/eip-20#approve) म्हणून समजा.
+```
+
+परिघ करार {#periphery-contracts} परिघ करार Uniswap साठी API (ॲप्लिकेशन प्रोग्राम इंटरफेस) आहेत.
+
+```solidity
+ते बाह्य कॉल्ससाठी उपलब्ध आहेत, एकतर इतर करारांमधून किंवा विकेंद्रीकृत ॲप्लिकेशन्समधून.
+```
+
+तुम्ही मुख्य करारांना थेट कॉल करू शकता, परंतु ते अधिक गुंतागुंतीचे आहे आणि तुम्ही चूक केल्यास मूल्य गमावू शकता. मुख्य करारांमध्ये फक्त ते फसवले जात नाहीत याची खात्री करण्यासाठी चाचण्या असतात, इतर कोणासाठीही sanity checks नाहीत. ते परिघामध्ये आहेत जेणेकरून आवश्यकतेनुसार ते अद्यतनित केले जाऊ शकतात.
+
+```solidity
+UniswapV2Router01.sol {#UniswapV2Router01}
+```
+
+[या करारामध्ये](https://github.com/Uniswap/uniswap-v2-periphery/blob/master/contracts/UniswapV2Router01.sol) समस्या आहेत, आणि [तो आता वापरला जाऊ नये](https://docs.uniswap.org/contracts/v2/reference/smart-contracts/router-01). सुदैवाने, परिघ करार स्टेटलेस आहेत आणि कोणतीही मालमत्ता ठेवत नाहीत, त्यामुळे त्याला नाकारणे आणि लोकांना त्याऐवजी बदल, `UniswapV2Router02`, वापरण्यास सुचवणे सोपे आहे. UniswapV2Router02.sol {#UniswapV2Router02}
+
+```solidity
+बहुतेक प्रकरणांमध्ये तुम्ही [या कराराद्वारे](https://github.com/Uniswap/uniswap-v2-periphery/blob/master/contracts/UniswapV2Router02.sol) Uniswap वापराल.
+```
+
+तुम्ही ते कसे वापरायचे ते [येथे](https://docs.uniswap.org/contracts/v2/reference/smart-contracts/router-02) पाहू शकता.
+
+#### pragma solidity =0.6.6;import '@uniswap/v2-core/contracts/interfaces/IUniswapV2Factory.sol';&#xA;import '@uniswap/lib/contracts/libraries/TransferHelper.sol';import './interfaces/IUniswapV2Router02.sol';&#xA;import './libraries/UniswapV2Library.sol';&#xA;import './libraries/SafeMath.sol';&#xA;import './interfaces/IERC20.sol';&#xA;import './interfaces/IWETH.sol';
+
+यापैकी बहुतेक आपण यापूर्वी पाहिले आहेत, किंवा ते बरेच स्पष्ट आहेत.
+
+```solidity
+एक अपवाद `IWETH.sol` आहे.
+```
+
+Uniswap v2 कोणत्याही ERC-20 टोकनच्या जोडीसाठी एक्सचेंजला परवानगी देतो, परंतु इथर (ETH) स्वतः ERC-20 टोकन नाही. ते मानकापूर्वीचे आहे आणि अद्वितीय यंत्रणेद्वारे हस्तांतरित केले जाते.
+
+```solidity
+ERC-20 टोकनवर लागू होणाऱ्या करारांमध्ये ETH चा वापर सक्षम करण्यासाठी लोकांनी [रॅप्ड इथर (WETH)](https://weth.tkn.eth.limo/) करार आणला.
+```
+
+तुम्ही या कराराला ETH पाठवता, आणि ते तुम्हाला WETH ची समतुल्य रक्कम मिंट करते.
+
+```solidity
+किंवा तुम्ही WETH बर्न करू शकता, आणि ETH परत मिळवू शकता.
+```
+
+contract UniswapV2Router02 is IUniswapV2Router02 {
+using SafeMath for uint;```
+address public immutable override factory;
+address public immutable override WETH; राउटरला माहित असणे आवश्यक आहे की कोणती फॅक्टरी वापरायची, आणि WETH आवश्यक असलेल्या व्यवहारांसाठी कोणता WETH करार वापरायचा.
+```
+
+```solidity
+ही मूल्ये [अपरिवर्तनीय](https://docs.soliditylang.org/en/v0.8.3/contracts.html#constant-and-immutable-state-variables) आहेत, म्हणजे ती फक्त कन्स्ट्रक्टरमध्ये सेट केली जाऊ शकतात.
+```
+
+यामुळे वापरकर्त्यांना विश्वास मिळतो की कोणीही त्यांना कमी प्रामाणिक करारांकडे निर्देशित करण्यासाठी बदलू शकणार नाही.
+
+```solidity
+    modifier ensure(uint deadline) {
+        require(deadline >= block.timestamp, 'UniswapV2Router: EXPIRED');
+        _;
+    }
+```
+
+हा मॉडिफायर खात्री करतो की वेळेनुसार मर्यादित व्यवहार ("वेळेच्या आत Y करा जर तुम्ही करू शकत असाल तर") त्यांच्या वेळेच्या मर्यादेनंतर होत नाहीत.
+
+```solidity
+    constructor(address _factory, address _WETH) public {
+        factory = _factory;
+        WETH = _WETH;
+    }
+```
+
+कन्स्ट्रक्टर फक्त अपरिवर्तनीय स्टेट व्हेरिएबल्स सेट करतो.
+
+```solidity
+    receive() external payable {
+        assert(msg.sender == WETH); // only accept ETH via fallback from the WETH contract
+    }
+```
+
+जेव्हा आम्ही WETH करारातून टोकन परत ETH मध्ये रिडीम करतो तेव्हा हे फंक्शन कॉल केले जाते.
+
+```solidity
+फक्त आम्ही वापरत असलेला WETH करारच ते करण्यास अधिकृत आहे.
+```
+
+लिक्विडिटी जोडा {#add-liquidity} ही फंक्शन्स पेअर एक्सचेंजमध्ये टोकन जोडतात, ज्यामुळे लिक्विडिटी पूल वाढतो.
+
+```solidity
+
+    // **** ADD LIQUIDITY ****
+    function _addLiquidity(
+```
+
+अंतिम कार्य स्टोरेज फी आणि मेटा-ट्रान्झॅक्शन्स एकत्र करते.
+
+#### ट्रेड {#trade}
+
+```solidity
+    // **** स्वॅप ****
+    // प्रारंभिक रक्कम आधीच पहिल्या जोडीला पाठवली गेली असणे आवश्यक आहे
+    function _swap(uint[] memory amounts, address[] memory path, address _to) internal virtual {
+```
+
+हे कार्य अंतर्गत प्रक्रिया करते जे ट्रेडर्ससाठी उपलब्ध असलेल्या कार्यांसाठी आवश्यक आहे.
+
+```solidity
+        for (uint i; i < path.length - 1; i++) {
+```
+
+मी हे लिहित असताना [388,160 ERC-20 टोकन्स](https://eth.blockscout.com/tokens) आहेत. प्रत्येक टोकन जोडीसाठी एक पेअर एक्सचेंज असते, तर ते 150 अब्ज पेक्षा जास्त पेअर एक्सचेंज झाले असते. संपूर्ण चेनमध्ये, सध्या, [त्या संख्येच्या केवळ 0.1% खाती आहेत](https://eth.blockscout.com/stats/accountsGrowth). त्याऐवजी, स्वॅप फंक्शन्स पाथच्या संकल्पनेला समर्थन देतात. एक ट्रेडर A ला B साठी, B ला C साठी, आणि C ला D साठी एक्सचेंज करू शकतो, त्यामुळे थेट A-D पेअर एक्सचेंजची गरज नाही.
+
+या बाजारांमधील किमती सिंक्रोनाइझ (समक्रमित) केल्या जातात, कारण जेव्हा त्या सिंकमध्ये नसतात तेव्हा आर्बिट्रेजसाठी संधी निर्माण होते. उदाहरणार्थ, A, B आणि C या तीन टोकन्सची कल्पना करा. प्रत्येक जोडीसाठी एक, असे तीन पेअर एक्सचेंज आहेत.
+
+1. सुरुवातीची परिस्थिती
+2. एक ट्रेडर 24.695 A टोकन्स विकतो आणि 25.305 B टोकन्स मिळवतो.
+3. ट्रेडर 24.695 B टोकन्स 25.305 C टोकन्ससाठी विकतो, आणि अंदाजे 0.61 B टोकन्स नफा म्हणून ठेवतो.
+4. मग ट्रेडर 24.695 C टोकन्स 25.305 A टोकन्ससाठी विकतो, आणि अंदाजे 0.61 C टोकन्स नफा म्हणून ठेवतो. ट्रेडरकडे 0.61 अतिरिक्त A टोकन्स देखील आहेत (ट्रेडरला शेवटी मिळालेले 25.305, वजा 24.695 ची मूळ गुंतवणूक).
+
+| टप्पा | A-B एक्सचेंज                                                                                | B-C एक्सचेंज                                                                                | A-C एक्सचेंज                                                                                |
+| ----- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
+| 1     | A:1000 B:1050 A/B=1.05                      | B:1000 C:1050 B/C=1.05                      | A:1050 C:1000 C/A=1.05                      |
+| 2     | A:1024.695 B:1024.695 A/B=1 | B:1000 C:1050 B/C=1.05                      | A:1050 C:1000 C/A=1.05                      |
+| 3     | A:1024.695 B:1024.695 A/B=1 | B:1024.695 C:1024.695 B/C=1 | A:1050 C:1000 C/A=1.05                      |
+| 4     | A:1024.695 B:1024.695 A/B=1 | B:1024.695 C:1024.695 B/C=1 | A:1024.695 C:1024.695 C/A=1 |
+
+```solidity
+            (address input, address output) = (path[i], path[i + 1]);
+            (address token0,) = UniswapV2Library.sortTokens(input, output);
+            uint amountOut = amounts[i + 1];
+```
+
+आपण सध्या हाताळत असलेली जोडी मिळवा, ती क्रमवारी लावा (जोडीसोबत वापरण्यासाठी) आणि अपेक्षित आउटपुट रक्कम मिळवा.
+
+```solidity
+            (uint amount0Out, uint amount1Out) = input == token0 ? (uint(0), amountOut) : (amountOut, uint(0));
+```
+
+अपेक्षित आउटपुट रक्कम मिळवा, पेअर एक्सचेंजला अपेक्षित असलेल्या पद्धतीने क्रमवारी लावा.
+
+```solidity
+            address to = i < path.length - 2 ? UniswapV2Library.pairFor(factory, output, path[i + 2]) : _to;
+```
+
+हे शेवटचे एक्सचेंज आहे का? तसे असल्यास, ट्रेडसाठी मिळालेले टोकन्स गंतव्यस्थानावर पाठवा. तसे नसल्यास, ते पुढील पेअर एक्सचेंजवर पाठवा.
+
+```solidity
+
+            IUniswapV2Pair(UniswapV2Library.pairFor(factory, input, output)).swap(
+                amount0Out, amount1Out, to, new bytes(0)
+            );
+        }
+    }
+```
+
+टोकन्स स्वॅप करण्यासाठी प्रत्यक्षात पेअर एक्सचेंजला कॉल करा. आम्हाला एक्सचेंजबद्दल कळवण्यासाठी कॉलबॅकची आवश्यकता नाही, म्हणून आम्ही त्या फील्डमध्ये कोणतेही बाइट्स पाठवत नाही.
+
+```solidity
+    function swapExactTokensForTokens(
+```
+
+हे कार्य ट्रेडर्सद्वारे थेट एका टोकनला दुसऱ्या टोकनसाठी स्वॅप करण्याकरिता वापरले जाते.
+
+```solidity
+        uint amountIn,
+        uint amountOutMin,
+        address[] calldata path,
+```
+
+या पॅरामीटरमध्ये ERC-20 कॉन्ट्रॅक्ट्सचे ॲड्रेस आहेत. वर स्पष्ट केल्याप्रमाणे, ही एक ॲरे आहे कारण तुमच्याकडे असलेल्या मालमत्तेपासून तुम्हाला हव्या असलेल्या मालमत्तेपर्यंत पोहोचण्यासाठी तुम्हाला अनेक पेअर एक्सचेंजेसमधून जावे लागू शकते.
+
+सॉलिडिटीमधील फंक्शन पॅरामीटर `memory` किंवा `calldata` मध्ये संग्रहित केले जाऊ शकते. जर कार्य कॉन्ट्रॅक्टसाठी एक प्रवेश बिंदू असेल, वापरकर्त्याकडून थेट (ट्रान्झॅक्शन वापरून) किंवा वेगळ्या कॉन्ट्रॅक्टवरून कॉल केले असेल, तर पॅरामीटरचे मूल्य थेट कॉल डेटामधून घेतले जाऊ शकते. जर कार्य अंतर्गतपणे कॉल केले असेल, जसे वरील `_swap`, तर पॅरामीटर्स `memory` मध्ये संग्रहित करणे आवश्यक आहे. कॉल केलेल्या कॉन्ट्रॅक्टच्या दृष्टिकोनातून `calldata` फक्त वाचनीय आहे.
+
+`uint` किंवा `address` सारख्या स्केलर प्रकारांसह कंपाइलर आमच्यासाठी स्टोरेजची निवड हाताळतो, परंतु ॲरेंसाठी, जे लांब आणि अधिक महाग आहेत, आम्ही वापरल्या जाणाऱ्या स्टोरेजचा प्रकार निर्दिष्ट करतो.
+
+```solidity
+        address to,
+        uint deadline
+    ) external virtual override ensure(deadline) returns (uint[] memory amounts) {
+```
+
+परत येणारी मूल्ये नेहमी मेमरीमध्ये परत केली जातात.
+
+```solidity
+        amounts = UniswapV2Library.getAmountsOut(factory, amountIn, path);
+        require(amounts[amounts.length - 1] >= amountOutMin, 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT');
+```
+
+प्रत्येक स्वॅपमध्ये खरेदी करायच्या रकमेची गणना करा. जर परिणाम ट्रेडरने स्वीकारण्यास तयार असलेल्या किमान रकमेपेक्षा कमी असेल, तर ट्रान्झॅक्शनमधून परत या.
+
+```solidity
+        TransferHelper.safeTransferFrom(
+            path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]
+        );
+        _swap(amounts, path, to);
+    }
+```
+
+शेवटी, प्रारंभिक ERC-20 टोकन पहिल्या पेअर एक्सचेंजच्या खात्यावर हस्तांतरित करा आणि `_swap` कॉल करा. हे सर्व एकाच ट्रान्झॅक्शनमध्ये घडत आहे, त्यामुळे पेअर एक्सचेंजला माहित आहे की कोणतेही अनपेक्षित टोकन या हस्तांतरणाचा भाग आहेत.
+
+```solidity
+    function swapTokensForExactTokens(
+        uint amountOut,
+        uint amountInMax,
+        address[] calldata path,
+        address to,
+        uint deadline
+    ) external virtual override ensure(deadline) returns (uint[] memory amounts) {
+        amounts = UniswapV2Library.getAmountsIn(factory, amountOut, path);
+        require(amounts[0] <= amountInMax, 'UniswapV2Router: EXCESSIVE_INPUT_AMOUNT');
+        TransferHelper.safeTransferFrom(
+            path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]
+        );
+        _swap(amounts, path, to);
+    }
+```
+
+मागील कार्य, `swapTokensForTokens`, एका ट्रेडरला तो देण्यास तयार असलेल्या इनपुट टोकन्सची नेमकी संख्या आणि त्या बदल्यात तो स्वीकारण्यास तयार असलेल्या आउटपुट टोकन्सची किमान संख्या निर्दिष्ट करण्याची परवानगी देते. हे कार्य उलट स्वॅप करते, हे एका ट्रेडरला त्याला हव्या असलेल्या आउटपुट टोकन्सची संख्या आणि त्यासाठी तो देण्यास तयार असलेल्या इनपुट टोकन्सची कमाल संख्या निर्दिष्ट करू देते.
+
+दोन्ही प्रकरणांमध्ये, ट्रेडरला प्रथम या पेरिफेरी कॉन्ट्रॅक्टला एक भत्ता द्यावा लागतो जेणेकरून ते त्यांना हस्तांतरित करू शकेल.
+
+```solidity
+    function swapExactETHForTokens(uint amountOutMin, address[] calldata path, address to, uint deadline)
+        external
+        virtual
+        override
+        payable
+        ensure(deadline)
+        returns (uint[] memory amounts)
+    {
+        require(path[0] == WETH, 'UniswapV2Router: INVALID_PATH');
+        amounts = UniswapV2Library.getAmountsOut(factory, msg.value, path);
+        require(amounts[amounts.length - 1] >= amountOutMin, 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT');
+        IWETH(WETH).deposit{value: amounts[0]}();
+        assert(IWETH(WETH).transfer(UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]));
+        _swap(amounts, path, to);
+    }
+
+
+    function swapTokensForExactETH(uint amountOut, uint amountInMax, address[] calldata path, address to, uint deadline)
+        external
+        virtual
+        override
+        ensure(deadline)
+        returns (uint[] memory amounts)
+    {
+        require(path[path.length - 1] == WETH, 'UniswapV2Router: INVALID_PATH');
+        amounts = UniswapV2Library.getAmountsIn(factory, amountOut, path);
+        require(amounts[0] <= amountInMax, 'UniswapV2Router: EXCESSIVE_INPUT_AMOUNT');
+        TransferHelper.safeTransferFrom(
+            path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]
+        );
+        _swap(amounts, path, address(this));
+        IWETH(WETH).withdraw(amounts[amounts.length - 1]);
+        TransferHelper.safeTransferETH(to, amounts[amounts.length - 1]);
+    }
+
+
+
+    function swapExactTokensForETH(uint amountIn, uint amountOutMin, address[] calldata path, address to, uint deadline)
+        external
+        virtual
+        override
+        ensure(deadline)
+        returns (uint[] memory amounts)
+    {
+        require(path[path.length - 1] == WETH, 'UniswapV2Router: INVALID_PATH');
+        amounts = UniswapV2Library.getAmountsOut(factory, amountIn, path);
+        require(amounts[amounts.length - 1] >= amountOutMin, 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT');
+        TransferHelper.safeTransferFrom(
+            path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]
+        );
+        _swap(amounts, path, address(this));
+        IWETH(WETH).withdraw(amounts[amounts.length - 1]);
+        TransferHelper.safeTransferETH(to, amounts[amounts.length - 1]);
+    }
+
+
+    function swapETHForExactTokens(uint amountOut, address[] calldata path, address to, uint deadline)
+        external
+        virtual
+        override
+        payable
+        ensure(deadline)
+        returns (uint[] memory amounts)
+    {
+        require(path[0] == WETH, 'UniswapV2Router: INVALID_PATH');
+        amounts = UniswapV2Library.getAmountsIn(factory, amountOut, path);
+        require(amounts[0] <= msg.value, 'UniswapV2Router: EXCESSIVE_INPUT_AMOUNT');
+        IWETH(WETH).deposit{value: amounts[0]}();
+        assert(IWETH(WETH).transfer(UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]));
+        _swap(amounts, path, to);
+        // डस्ट eth परत करा, जर असेल तर
+        if (msg.value > amounts[0]) TransferHelper.safeTransferETH(msg.sender, msg.value - amounts[0]);
+    }
+```
+
+हे चार प्रकार ETH आणि टोकन्समध्ये ट्रेड करण्याशी संबंधित आहेत. फरक फक्त एवढाच आहे की आम्ही एकतर ट्रेडरकडून ETH घेतो आणि WETH तयार करण्यासाठी त्याचा वापर करतो, किंवा आम्ही पाथमधील शेवटच्या एक्सचेंजमधून WETH घेतो आणि ते बर्न करतो, आणि ट्रेडरला परिणामी ETH परत पाठवतो.
+
+```solidity
+    // **** स्वॅप (फी-ऑन-ट्रान्सफर टोकन्सना समर्थन देणारे) ****
+    // प्रारंभिक रक्कम आधीच पहिल्या जोडीला पाठवली गेली असणे आवश्यक आहे
+    function _swapSupportingFeeOnTransferTokens(address[] memory path, address _to) internal virtual {
+```
+
+हे ट्रान्सफर किंवा स्टोरेज फी असलेल्या टोकन्सना स्वॅप करण्यासाठीचे अंतर्गत कार्य आहे ([ही समस्या](https://github.com/Uniswap/uniswap-interface/issues/835) सोडवण्यासाठी).
+
+```solidity
+        for (uint i; i < path.length - 1; i++) {
+            (address input, address output) = (path[i], path[i + 1]);
+            (address token0,) = UniswapV2Library.sortTokens(input, output);
+            IUniswapV2Pair pair = IUniswapV2Pair(UniswapV2Library.pairFor(factory, input, output));
+            uint amountInput;
+            uint amountOutput;
+            { // स्टॅक खूप खोल त्रुटी टाळण्यासाठी स्कोप
+            (uint reserve0, uint reserve1,) = pair.getReserves();
+            (uint reserveInput, uint reserveOutput) = input == token0 ? (reserve0, reserve1) : (reserve1, reserve0);
+            amountInput = IERC20(input).balanceOf(address(pair)).sub(reserveInput);
+            amountOutput = UniswapV2Library.getAmountOut(amountInput, reserveInput, reserveOutput);
+```
+
+ट्रान्सफर फीमुळे प्रत्येक ट्रान्सफरमधून आम्हाला किती मिळेल हे सांगण्यासाठी आम्ही `getAmountsOut` फंक्शनवर अवलंबून राहू शकत नाही (ज्याप्रमाणे आम्ही मूळ `_swap` कॉल करण्यापूर्वी करतो). त्याऐवजी आम्हाला आधी हस्तांतरण करावे लागेल आणि मग आम्हाला किती टोकन्स परत मिळाले हे पाहावे लागेल.
+
+टीप: सैद्धांतिकदृष्ट्या आपण `_swap` ऐवजी फक्त हे फंक्शन वापरू शकतो, परंतु काही विशिष्ट प्रकरणांमध्ये (उदाहरणार्थ, जर आवश्यक किमान रक्कम पूर्ण करण्यासाठी शेवटी पुरेसे नसल्यामुळे हस्तांतरण परत केले गेले) त्यासाठी जास्त गॅस खर्च येईल. ट्रान्सफर फी टोकन्स खूप दुर्मिळ आहेत, त्यामुळे जरी आपल्याला त्यांना सामावून घेण्याची आवश्यकता असली तरी, सर्व स्वॅप्सना त्यांच्यापैकी किमान एकातून जावे लागेल असे गृहीत धरण्याची गरज नाही.
+
+```solidity
+            }
+            (uint amount0Out, uint amount1Out) = input == token0 ? (uint(0), amountOutput) : (amountOutput, uint(0));
+            address to = i < path.length - 2 ? UniswapV2Library.pairFor(factory, output, path[i + 2]) : _to;
+            pair.swap(amount0Out, amount1Out, to, new bytes(0));
+        }
+    }
+
+
+    function swapExactTokensForTokensSupportingFeeOnTransferTokens(
+        uint amountIn,
+        uint amountOutMin,
+        address[] calldata path,
+        address to,
+        uint deadline
+    ) external virtual override ensure(deadline) {
+        TransferHelper.safeTransferFrom(
+            path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amountIn
+        );
+        uint balanceBefore = IERC20(path[path.length - 1]).balanceOf(to);
+        _swapSupportingFeeOnTransferTokens(path, to);
+        require(
+            IERC20(path[path.length - 1]).balanceOf(to).sub(balanceBefore) >= amountOutMin,
+            'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT'
+        );
+    }
+
+
+    function swapExactETHForTokensSupportingFeeOnTransferTokens(
+        uint amountOutMin,
+        address[] calldata path,
+        address to,
+        uint deadline
+    )
+        external
+        virtual
+        override
+        payable
+        ensure(deadline)
+    {
+        require(path[0] == WETH, 'UniswapV2Router: INVALID_PATH');
+        uint amountIn = msg.value;
+        IWETH(WETH).deposit{value: amountIn}();
+        assert(IWETH(WETH).transfer(UniswapV2Library.pairFor(factory, path[0], path[1]), amountIn));
+        uint balanceBefore = IERC20(path[path.length - 1]).balanceOf(to);
+        _swapSupportingFeeOnTransferTokens(path, to);
+        require(
+            IERC20(path[path.length - 1]).balanceOf(to).sub(balanceBefore) >= amountOutMin,
+            'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT'
+        );
+    }
+
+
+    function swapExactTokensForETHSupportingFeeOnTransferTokens(
+        uint amountIn,
+        uint amountOutMin,
+        address[] calldata path,
+        address to,
+        uint deadline
+    )
+        external
+        virtual
+        override
+        ensure(deadline)
+    {
+        require(path[path.length - 1] == WETH, 'UniswapV2Router: INVALID_PATH');
+        TransferHelper.safeTransferFrom(
+            path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amountIn
+        );
+        _swapSupportingFeeOnTransferTokens(path, address(this));
+        uint amountOut = IERC20(WETH).balanceOf(address(this));
+        require(amountOut >= amountOutMin, 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT');
+        IWETH(WETH).withdraw(amountOut);
+        TransferHelper.safeTransferETH(to, amountOut);
+    }
+```
+
+हे सामान्य टोकन्ससाठी वापरले जाणारे तेच प्रकार आहेत, परंतु ते त्याऐवजी `_swapSupportingFeeOnTransferTokens` कॉल करतात.
+
+```solidity
+    // **** लायब्ररी फंक्शन्स ****
+    function quote(uint amountA, uint reserveA, uint reserveB) public pure virtual override returns (uint amountB) {
+        return UniswapV2Library.quote(amountA, reserveA, reserveB);
+    }
+
+    function getAmountOut(uint amountIn, uint reserveIn, uint reserveOut)
+        public
+        pure
+        virtual
+        override
+        returns (uint amountOut)
+    {
+        return UniswapV2Library.getAmountOut(amountIn, reserveIn, reserveOut);
+    }
+
+    function getAmountIn(uint amountOut, uint reserveIn, uint reserveOut)
+        public
+        pure
+        virtual
+        override
+        returns (uint amountIn)
+    {
+        return UniswapV2Library.getAmountIn(amountOut, reserveIn, reserveOut);
+    }
+
+    function getAmountsOut(uint amountIn, address[] memory path)
+        public
+        view
+        virtual
+        override
+        returns (uint[] memory amounts)
+    {
+        return UniswapV2Library.getAmountsOut(factory, amountIn, path);
+    }
+
+    function getAmountsIn(uint amountOut, address[] memory path)
+        public
+        view
+        virtual
+        override
+        returns (uint[] memory amounts)
+    {
+        return UniswapV2Library.getAmountsIn(factory, amountOut, path);
+    }
+}
+```
+
+ही फंक्शन्स फक्त प्रॉक्सी आहेत जी [UniswapV2Library फंक्शन्स](#uniswapV2library) ला कॉल करतात.
+
+### UniswapV2Migrator.sol {#UniswapV2Migrator}
+
+हा कॉन्ट्रॅक्ट जुन्या v1 मधून v2 मध्ये एक्सचेंज स्थलांतरित करण्यासाठी वापरला गेला होता. आता ते स्थलांतरित झाले असल्याने, ते आता संबंधित नाही.
+
+## लायब्ररी {#libraries}
+
+[SafeMath लायब्ररी](https://docs.openzeppelin.com/contracts/2.x/api/math) चांगल्या प्रकारे दस्तऐवजीकृत आहे, म्हणून येथे त्याचे दस्तऐवजीकरण करण्याची गरज नाही.
+
+### गणित {#Math}
+
+या लायब्ररीमध्ये काही गणिती फंक्शन्स आहेत ज्यांची सामान्यतः Solidity कोडमध्ये आवश्यकता नसते, म्हणून ते भाषेचा भाग नाहीत.
+
+```solidity
+pragma solidity =0.5.16;
+
+// विविध गणिती क्रिया करण्यासाठी एक लायब्ररी
+
+library Math {
+    function min(uint x, uint y) internal pure returns (uint z) {
+        z = x < y ? x : y;
+    }
+
+    // बॅबिलोनियन पद्धत (https://wikipedia.org/wiki/Methods_of_computing_square_roots#Babylonian_method)
+    function sqrt(uint y) internal pure returns (uint z) {
+        if (y > 3) {
+            z = y;
+            uint x = y / 2 + 1;
+```
+
+वर्गमूळापेक्षा जास्त असलेल्या अंदाजाने x सह प्रारंभ करा (हेच कारण आहे की आम्हाला 1-3 ला विशेष प्रकरणे म्हणून हाताळण्याची आवश्यकता आहे).
+
+```solidity
+            while (x < z) {
+                z = x;
+                x = (y / x + x) / 2;
+```
+
+एक जवळचा अंदाज मिळवा, मागील अंदाज आणि ज्या संख्येचे वर्गमूळ आपण शोधण्याचा प्रयत्न करत आहोत ती संख्या, मागील अंदाजाने भागून मिळणारी सरासरी. नवीन अंदाज विद्यमान अंदाजापेक्षा कमी होईपर्यंत पुनरावृत्ती करा. अधिक माहितीसाठी, [येथे पहा](https://wikipedia.org/wiki/Methods_of_computing_square_roots#Babylonian_method).
+
+```solidity
+            }
+        } else if (y != 0) {
+            z = 1;
+```
+
+आपल्याला शून्याच्या वर्गमूळाची कधीही गरज भासू नये. एक, दोन आणि तीन यांचे वर्गमूळ अंदाजे एक आहे (आपण पूर्णांक वापरतो, म्हणून आपण अपूर्णांकाकडे दुर्लक्ष करतो).
+
+```solidity
+        }
+    }
+}
+```
+
+### फिक्स्ड पॉईंट फ्रॅक्शन्स (UQ112x112) {#FixedPoint}
+
+ही लायब्ररी अपूर्णांक हाताळते, जे सामान्यतः Ethereum अंकगणिताचा भाग नाहीत. हे _x_ या संख्येला _x\*2^112_ म्हणून एन्कोड करून करते. हे आपल्याला मूळ बेरीज आणि वजाबाकी ऑपकोड्समध्ये बदल न करता वापरण्याची परवानगी देते.
+
+```solidity
+pragma solidity =0.5.16;
+
+// बायनरी फिक्स्ड पॉईंट संख्या हाताळण्यासाठी एक लायब्ररी (https://wikipedia.org/wiki/Q_(number_format))
+
+// श्रेणी: [0, 2**112 - 1]
+// रिझोल्यूशन: 1 / 2**112
+
+library UQ112x112 {
+    uint224 constant Q112 = 2**112;
+```
+
+`Q112` हे एक साठी एन्कोडिंग आहे.
+
+```solidity
+    // uint112 ला UQ112x112 म्हणून एन्कोड करा
+    function encode(uint112 y) internal pure returns (uint224 z) {
+        z = uint224(y) * Q112; // कधीही ओव्हरफ्लो होत नाही
+    }
+```
+
+कारण y हे `uint112` आहे, ते जास्तीत जास्त 2^112-1 असू शकते. ती संख्या अजूनही `UQ112x112` म्हणून एन्कोड केली जाऊ शकते.
+
+```solidity
+    // UQ112x112 ला uint112 ने भागा, UQ112x112 परत करा
+    function uqdiv(uint224 x, uint112 y) internal pure returns (uint224 z) {
+        z = x / uint224(y);
+    }
+}
+```
+
+जर आपण दोन `UQ112x112` मूल्यांना भागले, तर परिणाम 2^112 ने गुणला जात नाही. म्हणून त्याऐवजी आपण भाजकासाठी एक पूर्णांक घेतो. गुणाकार करण्यासाठी आम्हाला अशीच युक्ती वापरावी लागली असती, परंतु आम्हाला `UQ112x112` मूल्यांचा गुणाकार करण्याची आवश्यकता नाही.
+
+### UniswapV2Library {#uniswapV2library}
+
+ही लायब्ररी केवळ पेरिफेरी कॉन्ट्रॅक्ट्सद्वारे वापरली जाते.
+
+```solidity
+pragma solidity >=0.5.0;
+
+import '@uniswap/v2-core/contracts/interfaces/IUniswapV2Pair.sol';
+
+import "./SafeMath.sol";
+
+library UniswapV2Library {
+    using SafeMath for uint;
+
+    // क्रमवारी लावलेले टोकन पत्ते परत करते, या क्रमाने क्रमवारी लावलेल्या जोड्यांमधून परत येणारी मूल्ये हाताळण्यासाठी वापरले जाते
+    function sortTokens(address tokenA, address tokenB) internal pure returns (address token0, address token1) {
+        require(tokenA != tokenB, 'UniswapV2Library: IDENTICAL_ADDRESSES');
+        (token0, token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
+        require(token0 != address(0), 'UniswapV2Library: ZERO_ADDRESS');
+    }
+```
+
+दोन टोकन्सना ॲड्रेसनुसार क्रमवारी लावा, म्हणजे आपल्याला त्यांच्यासाठी पेअर एक्सचेंजचा ॲड्रेस मिळू शकेल. हे आवश्यक आहे कारण अन्यथा आमच्याकडे दोन शक्यता असतील, एक A,B पॅरामीटर्ससाठी आणि दुसरी B,A पॅरामीटर्ससाठी, ज्यामुळे एकाऐवजी दोन एक्सचेंज होतील.
+
+```solidity
+    // कोणत्याही बाह्य कॉल न करता जोडीसाठी CREATE2 ॲड्रेसची गणना करते
+    function pairFor(address factory, address tokenA, address tokenB) internal pure returns (address pair) {
+        (address token0, address token1) = sortTokens(tokenA, tokenB);
+        pair = address(uint(keccak256(abi.encodePacked(
+                hex'ff',
+                factory,
+                keccak256(abi.encodePacked(token0, token1)),
+                hex'96e8ac4277198ff8b6f785478aa9a39f403cb768dd02cbee326c3e7da348845f' // init कोड हॅश
+            ))));
+    }
+```
+
+हे फंक्शन दोन टोकन्ससाठी पेअर एक्सचेंजच्या ॲड्रेसची गणना करते. हा कॉन्ट्रॅक्ट [CREATE2 ऑपकोड](https://eips.ethereum.org/EIPS/eip-1014) वापरून तयार केला आहे, त्यामुळे जर आम्हाला ते वापरत असलेले पॅरामीटर्स माहित असतील तर आम्ही त्याच अल्गोरिदमचा वापर करून ॲड्रेसची गणना करू शकतो. हे फॅक्टरीला विचारण्यापेक्षा खूपच स्वस्त आहे, आणि
+
+```solidity
+    // एका जोडीसाठी राखीव निधी मिळवते आणि क्रमवारी लावते
+    function getReserves(address factory, address tokenA, address tokenB) internal view returns (uint reserveA, uint reserveB) {
+        (address token0,) = sortTokens(tokenA, tokenB);
+        (uint reserve0, uint reserve1,) = IUniswapV2Pair(pairFor(factory, tokenA, tokenB)).getReserves();
+        (reserveA, reserveB) = tokenA == token0 ? (reserve0, reserve1) : (reserve1, reserve0);
+    }
+```
+
+हे फंक्शन पेअर एक्सचेंजकडे असलेल्या दोन टोकन्सचा राखीव निधी परत करते. लक्षात घ्या की ते टोकन्स कोणत्याही क्रमाने प्राप्त करू शकते, आणि अंतर्गत वापरासाठी त्यांची क्रमवारी लावते.
+
+```solidity
+    // मालमत्तेची काही रक्कम आणि जोडीचा राखीव निधी दिल्यास, दुसऱ्या मालमत्तेची समतुल्य रक्कम परत करते
+    function quote(uint amountA, uint reserveA, uint reserveB) internal pure returns (uint amountB) {
+        require(amountA > 0, 'UniswapV2Library: INSUFFICIENT_AMOUNT');
+        require(reserveA > 0 && reserveB > 0, 'UniswapV2Library: INSUFFICIENT_LIQUIDITY');
+        amountB = amountA.mul(reserveB) / reserveA;
+    }
+```
+
+हे फंक्शन तुम्हाला टोकन A च्या बदल्यात मिळणाऱ्या टोकन B ची रक्कम देते, जर त्यात कोणतेही शुल्क सामील नसेल. ही गणना विचारात घेते की हस्तांतरणामुळे विनिमय दर बदलतो.
+
+```solidity
+    // मालमत्तेची इनपुट रक्कम आणि जोडीचा राखीव निधी दिल्यास, दुसऱ्या मालमत्तेची कमाल आउटपुट रक्कम परत करते
+    function getAmountOut(uint amountIn, uint reserveIn, uint reserveOut) internal pure returns (uint amountOut) {
+```
+
+वरील `quote` फंक्शन उत्तम काम करते, जर पेअर एक्सचेंज वापरण्यासाठी कोणतेही शुल्क नसेल. तथापि, जर 0.3% एक्सचेंज शुल्क असेल तर तुम्हाला मिळणारी रक्कम कमी असते. हे फंक्शन एक्सचेंज फी नंतरच्या रकमेची गणना करते.
+
+```solidity
+
+        require(amountIn > 0, 'UniswapV2Library: INSUFFICIENT_INPUT_AMOUNT');
+        require(reserveIn > 0 && reserveOut > 0, 'UniswapV2Library: INSUFFICIENT_LIQUIDITY');
+        uint amountInWithFee = amountIn.mul(997);
+        uint numerator = amountInWithFee.mul(reserveOut);
+        uint denominator = reserveIn.mul(1000).add(amountInWithFee);
+        amountOut = numerator / denominator;
+    }
+```
+
+Solidity मूळतः अपूर्णांक हाताळत नाही, म्हणून आपण फक्त रकमेला 0.997 ने गुणू शकत नाही. त्याऐवजी, आम्ही अंशाला 997 ने आणि भाजकाला 1000 ने गुणतो, ज्यामुळे तोच परिणाम साधला जातो.
+
+```solidity
+    // मालमत्तेची आउटपुट रक्कम आणि जोडीचा राखीव निधी दिल्यास, दुसऱ्या मालमत्तेची आवश्यक इनपुट रक्कम परत करते
+    function getAmountIn(uint amountOut, uint reserveIn, uint reserveOut) internal pure returns (uint amountIn) {
+        require(amountOut > 0, 'UniswapV2Library: INSUFFICIENT_OUTPUT_AMOUNT');
+        require(reserveIn > 0 && reserveOut > 0, 'UniswapV2Library: INSUFFICIENT_LIQUIDITY');
+        uint numerator = reserveIn.mul(amountOut).mul(1000);
+        uint denominator = reserveOut.sub(amountOut).mul(997);
+        amountIn = (numerator / denominator).add(1);
+    }
+```
+
+हे फंक्शन अंदाजे तेच काम करते, परंतु ते आउटपुट रक्कम मिळवते आणि इनपुट प्रदान करते.
+
+```solidity
+
+    // कोणत्याही संख्येच्या जोड्यांवर साखळी getAmountOut गणना करते
+    function getAmountsOut(address factory, uint amountIn, address[] memory path) internal view returns (uint[] memory amounts) {
+        require(path.length >= 2, 'UniswapV2Library: INVALID_PATH');
+        amounts = new uint[](path.length);
+        amounts[0] = amountIn;
+        for (uint i; i < path.length - 1; i++) {
+            (uint reserveIn, uint reserveOut) = getReserves(factory, path[i], path[i + 1]);
+            amounts[i + 1] = getAmountOut(amounts[i], reserveIn, reserveOut);
+        }
+    }
+
+    // कोणत्याही संख्येच्या जोड्यांवर साखळी getAmountIn गणना करते
+    function getAmountsIn(address factory, uint amountOut, address[] memory path) internal view returns (uint[] memory amounts) {
+        require(path.length >= 2, 'UniswapV2Library: INVALID_PATH');
+        amounts = new uint[](path.length);
+        amounts[amounts.length - 1] = amountOut;
+        for (uint i = path.length - 1; i > 0; i--) {
+            (uint reserveIn, uint reserveOut) = getReserves(factory, path[i - 1], path[i]);
+            amounts[i - 1] = getAmountIn(amounts[i], reserveIn, reserveOut);
+        }
+    }
+}
+```
+
+ही दोन फंक्शन्स मूल्ये ओळखण्याचे काम करतात, जेव्हा अनेक पेअर एक्सचेंजेसमधून जाणे आवश्यक असते.
+
+### ट्रान्सफर हेल्पर {#transfer-helper}
+
+[ही लायब्ररी](https://github.com/Uniswap/uniswap-lib/blob/master/contracts/libraries/TransferHelper.sol) ERC-20 आणि Ethereum ट्रान्सफरभोवती यशस्वी तपासणी जोडते, जेणेकरून रिव्हर्ट आणि `false` मूल्य परत येण्यास एकाच प्रकारे हाताळता येईल.
+
+```solidity
+// SPDX-License-Identifier: GPL-3.0-or-later
+
+pragma solidity >=0.6.0;
+
+// ERC20 टोकन्सशी संवाद साधण्यासाठी आणि ETH पाठवण्यासाठी मदतनीस पद्धती जे सातत्याने खरे/खोटे परत करत नाहीत
+library TransferHelper {
+    function safeApprove(
+        address token,
+        address to,
+        uint256 value
+    ) internal {
+        // bytes4(keccak256(bytes('approve(address,uint256)')));
+        (bool success, bytes memory data) = token.call(abi.encodeWithSelector(0x095ea7b3, to, value));
+
+```
+
+आपण वेगळ्या कॉन्ट्रॅक्टला दोनपैकी एका प्रकारे कॉल करू शकतो:
+
+- फंक्शन कॉल तयार करण्यासाठी इंटरफेस व्याख्या वापरा
+- कॉल तयार करण्यासाठी [ऍप्लिकेशन बायनरी इंटरफेस (ABI)](https://docs.soliditylang.org/en/v0.8.3/abi-spec.html) "मॅन्युअली" वापरा. कोडच्या लेखकाने हेच करण्याचे ठरवले.
+
+```solidity
+        require(
+            success && (data.length == 0 || abi.decode(data, (bool))),
+            'TransferHelper::safeApprove: approve failed'
+        );
+    }
+```
+
+ERC-20 मानकापूर्वी तयार केलेल्या टोकनसह बॅकवर्ड सुसंगततेसाठी, ERC-20 कॉल एकतर रिव्हर्ट होऊन अयशस्वी होऊ शकतो (या प्रकरणात `success` `false` असते) किंवा यशस्वी होऊन `false` मूल्य परत करून (या प्रकरणात आउटपुट डेटा असतो, आणि जर तुम्ही ते बुलियन म्हणून डीकोड केले तर तुम्हाला `false` मिळते).
+
+```solidity
+
+
+    function safeTransfer(
+        address token,
+        address to,
+        uint256 value
+    ) internal {
+        // bytes4(keccak256(bytes('transfer(address,uint256)')));
+        (bool success, bytes memory data) = token.call(abi.encodeWithSelector(0xa9059cbb, to, value));
+        require(
+            success && (data.length == 0 || abi.decode(data, (bool))),
+            'TransferHelper::safeTransfer: transfer failed'
+        );
+    }
+```
+
+हे फंक्शन [ERC-20 ची ट्रान्सफर कार्यक्षमता](https://eips.ethereum.org/EIPS/eip-20#transfer) लागू करते, जे एका खात्याला दुसऱ्या खात्याने प्रदान केलेला भत्ता खर्च करण्याची परवानगी देते.
+
+```solidity
+
+    function safeTransferFrom(
+        address token,
+        address from,
+        address to,
+        uint256 value
+    ) internal {
+        // bytes4(keccak256(bytes('transferFrom(address,address,uint256)')));
+        (bool success, bytes memory data) = token.call(abi.encodeWithSelector(0x23b872dd, from, to, value));
+        require(
+            success && (data.length == 0 || abi.decode(data, (bool))),
+            'TransferHelper::transferFrom: transferFrom failed'
+        );
+    }
+```
+
+हे फंक्शन [ERC-20 ची transferFrom कार्यक्षमता](https://eips.ethereum.org/EIPS/eip-20#transferfrom) लागू करते, जे एका खात्याला दुसऱ्या खात्याने प्रदान केलेला भत्ता खर्च करण्याची परवानगी देते.
+
+```solidity
+
+    function safeTransferETH(address to, uint256 value) internal {
+        (bool success, ) = to.call{value: value}(new bytes(0));
+        require(success, 'TransferHelper::safeTransferETH: ETH transfer failed');
+    }
+}
+```
+
+हे फंक्शन एका खात्यात ईथर हस्तांतरित करते. वेगळ्या कॉन्ट्रॅक्टला केलेला कोणताही कॉल ईथर पाठवण्याचा प्रयत्न करू शकतो. कारण आम्हाला प्रत्यक्षात कोणतेही फंक्शन कॉल करण्याची गरज नाही, आम्ही कॉलसोबत कोणताही डेटा पाठवत नाही.
+
+## निष्कर्ष {#conclusion}
+
+हा सुमारे 50 पानांचा एक लांब लेख आहे. तुम्ही इथपर्यंत पोहोचलात तर, अभिनंदन! आशा आहे की आतापर्यंत तुम्हाला वास्तविक जीवनातील ॲप्लिकेशन लिहिण्यातील विचार (लहान नमुना कार्यक्रमांच्या विपरीत) समजले असतील आणि तुमच्या स्वतःच्या वापराच्या प्रकरणांसाठी कॉन्ट्रॅक्ट लिहिण्यास अधिक सक्षम आहात.
+
+आता जा आणि काहीतरी उपयुक्त लिहा आणि आम्हाला चकित करा.
+
+[माझ्या कामाबद्दल अधिक माहितीसाठी येथे पहा](https://cryptodocguy.pro/).
diff --git a/public/content/translations/mr/developers/tutorials/using-websockets/index.md b/public/content/translations/mr/developers/tutorials/using-websockets/index.md
new file mode 100644
index 00000000000..04ae738b218
--- /dev/null
+++ b/public/content/translations/mr/developers/tutorials/using-websockets/index.md
@@ -0,0 +1,245 @@
+---
+title: "WebSockets वापरणे"
+description: "JSON-RPC विनंत्या करण्यासाठी आणि इव्हेंटसाठी सदस्यत्व घेण्यासाठी WebSockets आणि Alchemy वापरण्याकरिता मार्गदर्शक."
+author: "Elan Halpern"
+lang: mr
+tags: [ "alchemy", "websockets", "querying", "javascript" ]
+skill: beginner
+source: Alchemy docs
+sourceUrl: https://www.alchemy.com/docs/reference/best-practices-for-using-websockets-in-web3
+published: 2020-12-01
+---
+
+Ethereum ब्लॉकचेनला विनंत्या करण्यासाठी WebSockets आणि Alchemy वापरण्याकरिता हे एक एन्ट्री लेव्हल मार्गदर्शक आहे.
+
+## WebSockets विरुद्ध HTTP {#websockets-vs-http}
+
+HTTP च्या विपरीत, WebSockets सह, तुम्हाला विशिष्ट माहिती हवी असताना सतत विनंत्या करण्याची आवश्यकता नाही. WebSockets तुमच्यासाठी नेटवर्क कनेक्शन राखतात (जर योग्यरित्या केले असेल) आणि बदलांसाठी ऐकतात.
+
+कोणत्याही नेटवर्क कनेक्शनप्रमाणे, तुम्ही असे गृहीत धरू नये की WebSocket कोणत्याही व्यत्ययाशिवाय कायमचे उघडे राहील, परंतु ड्रॉप झालेले कनेक्शन आणि हाताने पुन्हा कनेक्शन करणे योग्यरित्या हाताळणे आव्हानात्मक असू शकते. WebSockets चा आणखी एक तोटा म्हणजे तुम्हाला प्रतिसादात HTTP स्टेटस कोड मिळत नाहीत, तर फक्त त्रुटी संदेश मिळतो.
+
+[Alchemy Web3](https://docs.alchemy.com/reference/api-overview) कोणत्याही कॉन्फिगरेशनशिवाय WebSocket अयशस्वी झाल्यास आणि पुन्हा प्रयत्न करण्यासाठी आपोआप हाताळणी जोडते.
+
+## हे करून पहा {#try-it-out}
+
+WebSockets ची चाचणी करण्याचा सर्वात सोपा मार्ग म्हणजे WebSocket विनंत्या करण्यासाठी [wscat](https://github.com/websockets/wscat) सारखे कमांड लाइन साधन इंस्टॉल करणे. wscat वापरून, तुम्ही खालीलप्रमाणे विनंत्या पाठवू शकता:
+
+_टीप: तुमचे Alchemy खाते असल्यास तुम्ही `demo` ला तुमच्या स्वतःच्या API की ने बदलू शकता. [येथे विनामूल्य Alchemy खात्यासाठी साइन अप करा!](https://auth.alchemy.com/signup)_
+
+```
+wscat -c wss://eth-mainnet.ws.alchemyapi.io/ws/demo
+
+>  {"jsonrpc":  "2.0", "id": 0, "method":  "eth_gasPrice"}
+
+<  {"jsonrpc":  "2.0", "result":  "0xb2d05e00", "id": 0}
+
+```
+
+## WebSockets कसे वापरावे {#how-to-use-websockets}
+
+सुरुवात करण्यासाठी, तुमच्या ॲपसाठी WebSocket URL वापरून एक WebSocket उघडा. तुम्ही तुमच्या ॲपचा WebSocket URL [तुमच्या डॅशबोर्ड](https://dashboard.alchemy.com/) मध्ये ॲपचे पेज उघडून आणि "View Key" वर क्लिक करून शोधू शकता. लक्षात घ्या की तुमच्या ॲपचा WebSockets साठीचा URL हा HTTP विनंत्यांसाठी असलेल्या URL पेक्षा वेगळा आहे, परंतु दोन्ही "View Key" वर क्लिक करून शोधता येतात.
+
+![तुमच्या Alchemy डॅशबोर्डमध्ये तुमचा WebSocket URL कुठे शोधायचा](./use-websockets.gif)
+
+[Alchemy API रेफरन्स](https://www.alchemy.com/docs/reference/api-overview) मध्ये सूचीबद्ध केलेले कोणतेही API WebSocket द्वारे वापरले जाऊ शकतात. असे करण्यासाठी, HTTP POST विनंतीच्या बॉडी म्हणून पाठवला जाणारा तोच पेलोड वापरा, परंतु त्याऐवजी तो पेलोड WebSocket द्वारे पाठवा.
+
+## Web3 सह {#with-web3}
+
+Web3 सारखी क्लायंट लायब्ररी वापरताना WebSockets वर संक्रमण करणे सोपे आहे. तुमचा Web3 क्लायंट इन्स्टँशिएट करताना फक्त HTTP URL ऐवजी WebSocket URL पास करा. उदाहरणार्थ:
+
+```js
+const web3 = new Web3("wss://eth-mainnet.ws.alchemyapi.io/ws/your-api-key")
+
+web3.eth.getBlockNumber().then(console.log) // -> 7946893
+```
+
+## सबस्क्रिप्शन API {#subscription-api}
+
+WebSocket द्वारे कनेक्ट केल्यावर, तुम्ही दोन अतिरिक्त पद्धती वापरू शकता: `eth_subscribe` आणि `eth_unsubscribe`. या पद्धती तुम्हाला विशिष्ट इव्हेंटसाठी ऐकण्याची आणि त्वरित सूचित होण्याची परवानगी देतील.
+
+### `eth_subscribe` {#eth-subscribe}
+
+निर्दिष्ट इव्हेंटसाठी नवीन सबस्क्रिप्शन तयार करते. [`eth_subscribe` बद्दल अधिक जाणून घ्या](https://docs.alchemy.com/reference/eth-subscribe).
+
+#### मापदंड {#parameters}
+
+1. सबस्क्रिप्शन प्रकार
+2. पर्यायी पॅरामीटर्स
+
+पहिला युक्तिवाद (argument) कोणत्या प्रकारच्या इव्हेंटसाठी ऐकायचे ते निर्दिष्ट करतो. दुसऱ्या युक्तिवादामध्ये (argument) अतिरिक्त पर्याय आहेत जे पहिल्या युक्तिवादावर अवलंबून असतात. विविध वर्णन प्रकार, त्यांचे पर्याय, आणि त्यांचे इव्हेंट पेलोड खाली वर्णन केले आहेत.
+
+#### रिटर्न्स {#returns}
+
+सबस्क्रिप्शन आयडी: हा आयडी कोणत्याही प्राप्त झालेल्या इव्हेंटशी जोडला जाईल, आणि `eth_unsubscribe` वापरून सबस्क्रिप्शन रद्द करण्यासाठी देखील वापरला जाऊ शकतो.
+
+#### सबस्क्रिप्शन इव्हेंट्स {#subscription-events}
+
+सबस्क्रिप्शन सक्रिय असताना, तुम्हाला इव्हेंट प्राप्त होतील जे खालील फील्डसह ऑब्जेक्ट्स आहेत:
+
+- `jsonrpc`: नेहमी "2.0"
+- `method`: नेहमी "eth_subscription"
+- `params`: खालील फील्डसह एक ऑब्जेक्ट:
+  - `subscription`: हे सबस्क्रिप्शन तयार करणाऱ्या `eth_subscribe` कॉलद्वारे परत केलेला सबस्क्रिप्शन आयडी.
+  - `result`: एक ऑब्जेक्ट ज्याची सामग्री सबस्क्रिप्शनच्या प्रकारानुसार बदलते.
+
+#### सबस्क्रिप्शन प्रकार {#subscription-types}
+
+1. `alchemy_newFullPendingTransactions`
+
+प्रलंबित स्थितीत (pending state) जोडलेल्या सर्व व्यवहारांची माहिती परत करते. हा सबस्क्रिप्शन प्रकार प्रलंबित व्यवहारांसाठी सबस्क्राइब करतो, जो `web3.eth.subscribe("pendingTransactions")` या मानक Web3 कॉल सारखाच आहे, परंतु तो फक्त व्यवहार हॅशऐवजी _संपूर्ण व्यवहार माहिती_ उत्सर्जित करतो यात वेगळा आहे.
+
+उदाहरण:
+
+```json
+>  {"jsonrpc":  "2.0",  "id":  1,  "method":  "eth_subscribe",  "params":  ["alchemy_newFullPendingTransactions"]}
+
+<  {"id":1,"result":"0x9a52eeddc2b289f985c0e23a7d8427c8","jsonrpc":"2.0"}
+<  {
+      "jsonrpc":"2.0",
+      "method":"eth_subscription",
+      "params":{
+          "result":{
+          "blockHash":null,
+          "blockNumber":null,
+          "from":"0xa36452fc31f6f482ad823cd1cf5515177d57667f",
+          "gas":"0x1adb0",
+          "gasPrice":"0x7735c4d40",
+          "hash":"0x50bff0736c713458c92dd1848d12f3354149be1363123dae35e94e0f2a9d56bf",
+"input":"0xa9059cbb0000000000000000000000000d0707963952f2fba59dd06f2b425ace40b492fe0000000000000000000000000000000000000000000015b1111266cfca100000",
+          "nonce":"0x0",
+          "to":"0xea38eaa3c86c8f9b751533ba2e562deb9acded40",
+          "transactionIndex":null,
+          "value":"0x0",
+          "v":"0x26",
+          "r":"0x195c2c1ed126088e12d290aa93541677d3e3b1d10f137e11f86b1b9227f01e3b",
+          "s":"0x60fc4edbf1527832a2a36dbc1e63ed6193a6eee654472fbebbf88ef1750b5344"},
+          "subscription":"0x9a52eeddc2b289f985c0e23a7d8427c8"
+      }
+  }
+
+```
+
+2. `newHeads`
+
+चेन पुनर्रचनेदरम्यान नवीन हेडर चेनमध्ये जोडल्यास कधीही एक इव्हेंट उत्सर्जित करतो.
+
+जेव्हा चेन पुनर्रचना होते, तेव्हा हे सबस्क्रिप्शन नवीन चेनसाठी सर्व नवीन हेडर्स असलेला इव्हेंट उत्सर्जित करेल. विशेषतः, याचा अर्थ असा की तुम्ही एकाच उंचीसह अनेक हेडर्स उत्सर्जित झालेले पाहू शकता, आणि जेव्हा असे होते तेव्हा पुनर्रचनेनंतर नंतरचा हेडर योग्य मानला पाहिजे.
+
+उदाहरण:
+
+```json
+>  {"jsonrpc":  "2.0",  "id":  1,  "method":  "eth_subscribe",  "params":  ["newHeads"]}
+
+<  {"jsonrpc":"2.0","id":2,"result":"0x9ce59a13059e417087c02d3236a0b1cc"}
+<  {
+  "jsonrpc":  "2.0",
+  "method":  "eth_subscription",
+  "params":  {
+      "result":  {
+          "extraData":  "0xd983010305844765746887676f312e342e328777696e646f7773",
+          "gasLimit":  "0x47e7c4",
+          "gasUsed":  "0x38658",
+          "logsBloom":
+"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
+          "nonce":  "0x084149998194cc5f",
+          "number":  "0x1348c9",
+          "parentHash":  "0x7736fab79e05dc611604d22470dadad26f56fe494421b5b333de816ce1f25701",
+          "receiptRoot":  "0x2fab35823ad00c7bb388595cb46652fe7886e00660a01e867824d3dceb1c8d36",
+          "sha3Uncles":  "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
+          "stateRoot":  "0xb3346685172db67de536d8765c43c31009d0eb3bd9c501c9be3229203f15f378",
+          "timestamp":  "0x56ffeff8",
+          "transactionsRoot":  "0x0167ffa60e3ebc0b080cdb95f7c0087dd6c0e61413140e39d94d3468d7c9689f"
+      },
+  "subscription":  "0x9ce59a13059e417087c02d3236a0b1cc"
+  }
+}
+
+```
+
+3. `logs`
+
+निर्दिष्ट फिल्टर निकषांशी जुळणाऱ्या नव्याने जोडलेल्या ब्लॉक्सचा भाग असलेले लॉग उत्सर्जित करते.
+
+जेव्हा चेन पुनर्रचना होते, तेव्हा जुन्या चेनवरील ब्लॉक्सचा भाग असलेले लॉग `removed` प्रॉपर्टी `true` वर सेट करून पुन्हा उत्सर्जित केले जातील. पुढे, नवीन चेनवरील ब्लॉक्सचा भाग असलेले लॉग उत्सर्जित केले जातात, याचा अर्थ पुनर्रचनेच्या बाबतीत एकाच व्यवहारासाठी अनेक वेळा लॉग पाहणे शक्य आहे.
+
+पॅरामीटर्स
+
+1. खालील फील्ड असलेला एक ऑब्जेक्ट:
+   - `address` (पर्यायी): एकतर ॲड्रेस दर्शवणारी स्ट्रिंग किंवा अशा स्ट्रिंगची ॲरे.
+     - यापैकी फक्त एका ॲड्रेसवरून तयार केलेले लॉगच उत्सर्जित केले जातील.
+   - `topics`: टॉपिक स्पेसिफायर्सची एक ॲरे.
+     - प्रत्येक टॉपिक स्पेसिफायर एकतर `null`, एक टॉपिक दर्शवणारी स्ट्रिंग, किंवा स्ट्रिंगची ॲरे असते.
+     - ॲरेमधील प्रत्येक स्थान जे `null` नाही ते उत्सर्जित लॉगला केवळ त्या स्थानावर दिलेल्या विषयांपैकी एक असलेल्यांपर्यंतच मर्यादित करते.
+
+टॉपिक स्पेसिफिकेशन्सची काही उदाहरणे:
+
+- `[]`: कोणतेही विषय (topics) अनुमत आहेत.
+- `[A]`: पहिल्या स्थानावर A (आणि त्यानंतर काहीही).
+- `[null, B]`: पहिल्या स्थानावर काहीही आणि दुसऱ्या स्थानावर B (आणि त्यानंतर काहीही).
+- `[A, B]`: पहिल्या स्थानावर A आणि दुसऱ्या स्थानावर B (आणि त्यानंतर काहीही).
+- `[[A, B], [A, B]]`: पहिल्या स्थानावर (A किंवा B) आणि दुसऱ्या स्थानावर (A किंवा B) (आणि त्यानंतर काहीही).
+
+उदाहरण:
+
+```json
+>  {"jsonrpc":  "2.0",  "id":  1,  "method":  "eth_subscribe",  "params":  ["logs",  {"address":  "0x8320fe7702b96808f7bbc0d4a888ed1468216cfd",  "topics":  ["0xd78a0cb8bb633d06981248b816e7bd33c2a35a6089241d099fa519e361cab902"]}]}
+
+<  {"jsonrpc":"2.0","id":2,"result":"0x4a8a4c0517381924f9838102c5a4dcb7"}
+<  {
+  "jsonrpc":  "2.0",
+  "method":  "eth_subscription",
+  "params":  {
+      "subscription":  "0x4a8a4c0517381924f9838102c5a4dcb7",
+      "result":  {
+          "address":  "0x8320fe7702b96808f7bbc0d4a888ed1468216cfd",
+          "blockHash":  "0x61cdb2a09ab99abf791d474f20c2ea89bf8de2923a2d42bb49944c8c993cbf04",
+          "blockNumber":  "0x29e87",
+          "data": "0x00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000003",
+          "logIndex":"0x0",
+          "topics":["0xd78a0cb8bb633d06981248b816e7bd33c2a35a6089241d099fa519e361cab902"],
+          "transactionHash":  "0xe044554a0a55067caafd07f8020ab9f2af60bdfe337e395ecd84b4877a3d1ab4",
+          "transactionIndex":  "0x0"
+      }
+  }
+}
+
+```
+
+### `eth_unsubscribe` {#eth-unsubscribe}
+
+विद्यमान सबस्क्रिप्शन रद्द करते जेणेकरून पुढील कोणतेही इव्हेंट पाठवले जाणार नाहीत.
+
+पॅरामीटर्स
+
+1. सबस्क्रिप्शन आयडी, `eth_subscribe` कॉलवरून पूर्वी परत केल्याप्रमाणे.
+
+रिटर्न्स
+
+सबस्क्रिप्शन यशस्वीरित्या रद्द केले असल्यास `true`, किंवा दिलेल्या आयडीसह कोणतेही सबस्क्रिप्शन अस्तित्वात नसल्यास `false`.
+
+उदाहरण:
+
+**विनंती**
+
+```
+curl https://eth-mainnet.alchemyapi.io/v2/your-api-key
+-X POST
+-H "Content-Type: application/json"
+-d '{"id": 1, "method": "eth_unsubscribe", "params": ["0x9cef478923ff08bf67fde6c64013158d"]}'
+
+
+```
+
+**परिणाम**
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 1,
+  "result": true
+}
+```
+
+---
+
+[Alchemy](https://auth.alchemy.com) सह विनामूल्य साइन अप करा, आमची [माहिती](https://www.alchemy.com/docs/) पहा, आणि ताज्या बातम्यांसाठी, आम्हाला [Twitter](https://x.com/AlchemyPlatform) वर फॉलो करा.
diff --git a/public/content/translations/mr/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md b/public/content/translations/mr/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
new file mode 100644
index 00000000000..b64d523f92b
--- /dev/null
+++ b/public/content/translations/mr/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
@@ -0,0 +1,300 @@
+---
+title: "Waffle: डायनॅमिक मॉकिंग आणि कॉन्ट्रॅक्ट कॉल्सची चाचणी"
+description: "डायनॅमिक मॉकिंग आणि कॉन्ट्रॅक्ट कॉल्सच्या चाचणीसाठी प्रगत Waffle ट्यूटोरियल"
+author: "Daniel Izdebski"
+tags:
+  [
+    "waffle",
+    "स्मार्ट कॉन्ट्रॅक्ट",
+    "सॉलिडिटी",
+    "चाचणी",
+    "मॉक करणे"
+  ]
+skill: intermediate
+lang: mr
+published: 2020-11-14
+---
+
+## हे ट्यूटोरियल कशाबद्दल आहे? {#what-is-this-tutorial-about}
+
+या ट्यूटोरियलमध्ये तुम्ही हे कसे करायचे ते शिकाल:
+
+- डायनॅमिक मॉकिंगचा वापर करणे
+- स्मार्ट कॉन्ट्रॅक्ट्समधील संवादांची चाचणी घेणे
+
+गृहीतके:
+
+- तुम्हाला `Solidity` मध्ये साधा स्मार्ट कॉन्ट्रॅक्ट कसा लिहायचा हे आधीच माहीत आहे
+- तुम्हाला `JavaScript` आणि `TypeScript` ची माहिती आहे
+- तुम्ही इतर `Waffle` ट्यूटोरियल्स केले आहेत किंवा त्याबद्दल तुम्हाला थोडेफार माहीत आहे
+
+## डायनॅमिक मॉकिंग {#dynamic-mocking}
+
+डायनॅमिक मॉकिंग उपयुक्त का आहे? बरं, ते आपल्याला इंटिग्रेशन टेस्ट्सऐवजी युनिट टेस्ट्स लिहिण्याची परवानगी देते. याचा अर्थ काय? याचा अर्थ असा आहे की आपल्याला स्मार्ट कॉन्ट्रॅक्टच्या अवलंबनांबद्दल (dependencies) काळजी करण्याची गरज नाही, त्यामुळे आपण त्या सर्वांची पूर्णपणे वेगळे ठेवून चाचणी घेऊ शकतो. तुम्ही हे नक्की कसे करू शकता, हे मी तुम्हाला दाखवतो.
+
+### **१.** प्रोजेक्ट\*\* {#1-project}
+
+सुरू करण्यापूर्वी, आपल्याला एक साधा node.js प्रोजेक्ट तयार करणे आवश्यक आहे:
+
+```bash
+mkdir dynamic-mocking
+cd dynamic-mocking
+mkdir contracts src
+
+yarn init
+# or if you're using npm
+npm init
+```
+
+चला typescript आणि test dependencies - mocha आणि chai जोडून सुरुवात करूया:
+
+```bash
+yarn add --dev @types/chai @types/mocha chai mocha ts-node typescript
+# or if you're using npm
+npm install @types/chai @types/mocha chai mocha ts-node typescript --save-dev
+```
+
+आता `Waffle` आणि `ethers` जोडूया:
+
+```bash
+yarn add --dev ethereum-waffle ethers
+# or if you're using npm
+npm install ethereum-waffle ethers --save-dev
+```
+
+तुमच्या प्रोजेक्टची रचना आता अशी दिसली पाहिजे:
+
+```
+.
+├── contracts
+├── package.json
+└── test
+```
+
+### **२.** स्मार्ट कॉन्ट्रॅक्ट\*\* {#2-smart-contract}
+
+डायनॅमिक मॉकिंग सुरू करण्यासाठी, आपल्याला अवलंबित्व (dependencies) असलेल्या स्मार्ट कॉन्ट्रॅक्टची आवश्यकता आहे. काळजी करू नका, मी सर्व तयारी केली आहे!
+
+येथे `Solidity` मध्ये लिहिलेला एक साधा स्मार्ट कॉन्ट्रॅक्ट आहे, ज्याचा एकमेव उद्देश आपण श्रीमंत आहोत की नाही हे तपासणे आहे. आपल्याकडे पुरेसे टोकन्स आहेत की नाही हे तपासण्यासाठी ते ERC20 टोकन वापरते. ते `./contracts/AmIRichAlready.sol` मध्ये ठेवा.
+
+```solidity
+pragma solidity ^0.6.2;
+
+interface IERC20 {
+    function balanceOf(address account) external view returns (uint256);
+}
+
+contract AmIRichAlready {
+    IERC20 private tokenContract;
+    uint public richness = 1000000 * 10 ** 18;
+
+    constructor (IERC20 _tokenContract) public {
+        tokenContract = _tokenContract;
+    }
+
+    function check() public view returns (bool) {
+        uint balance = tokenContract.balanceOf(msg.sender);
+        return balance > richness;
+    }
+}
+```
+
+आपल्याला डायनॅमिक मॉकिंग वापरायचे असल्यामुळे, आपल्याला संपूर्ण ERC20 ची गरज नाही, म्हणूनच आपण फक्त एका फंक्शनसह IERC20 इंटरफेस वापरत आहोत.
+
+हा कॉन्ट्रॅक्ट तयार करण्याची वेळ झाली आहे! त्यासाठी आपण `Waffle` वापरणार आहोत. प्रथम, आपण एक साधी `waffle.json` कॉन्फिग फाइल तयार करणार आहोत जी कंपाईलेशन पर्याय निर्दिष्ट करते.
+
+```json
+{
+  "compilerType": "solcjs",
+  "compilerVersion": "0.6.2",
+  "sourceDirectory": "./contracts",
+  "outputDirectory": "./build"
+}
+```
+
+आता आपण Waffle सह कॉन्ट्रॅक्ट तयार करण्यासाठी सज्ज आहोत:
+
+```bash
+npx waffle
+```
+
+सोपे आहे, नाही का? `build/` फोल्डरमध्ये कॉन्ट्रॅक्ट आणि इंटरफेसशी संबंधित दोन फाइल्स दिसू लागल्या. चाचणीसाठी आपण त्यांचा वापर नंतर करणार आहोत.
+
+### **३.** चाचणी\*\* {#3-testing}
+
+प्रत्यक्ष चाचणीसाठी `AmIRichAlready.test.ts` नावाची फाइल तयार करूया. सर्वप्रथम, आपल्याला इम्पोर्ट्स हाताळावे लागतील. आपल्याला नंतर त्यांची आवश्यकता असेल:
+
+```typescript
+import { expect, use } from "chai"
+import { Contract, utils, Wallet } from "ethers"
+import {
+  deployContract,
+  deployMockContract,
+  MockProvider,
+  solidity,
+} from "ethereum-waffle"
+```
+
+JS अवलंबित्व वगळता, आपल्याला आपला तयार केलेला कॉन्ट्रॅक्ट आणि इंटरफेस इम्पोर्ट करणे आवश्यक आहे:
+
+```typescript
+import IERC20 from "../build/IERC20.json"
+import AmIRichAlready from "../build/AmIRichAlready.json"
+```
+
+चाचणीसाठी Waffle `chai` वापरते. तथापि, आपण ते वापरण्यापूर्वी, आपल्याला Waffle चे मॅचर्स थेट chai मध्ये इंजेक्ट करावे लागतील:
+
+```typescript
+use(solidity)
+```
+
+आपल्याला `beforeEach()` फंक्शन लागू करण्याची आवश्यकता आहे, जे प्रत्येक चाचणीपूर्वी कॉन्ट्रॅक्टची स्थिती (state) रीसेट करेल. चला आधी विचार करूया की आपल्याला तिथे कशाची गरज आहे. कॉन्ट्रॅक्ट डिप्लॉय करण्यासाठी आपल्याला दोन गोष्टींची आवश्यकता आहे: एक वॉलेट आणि एक डिप्लॉय केलेला ERC20 कॉन्ट्रॅक्ट, जो `AmIRichAlready` कॉन्ट्रॅक्टसाठी एक आर्गुमेंट म्हणून पास करता येईल.
+
+प्रथम, आपण एक वॉलेट तयार करतो:
+
+```typescript
+const [wallet] = new MockProvider().getWallets()
+```
+
+मग आपल्याला ERC20 कॉन्ट्रॅक्ट डिप्लॉय करण्याची आवश्यकता आहे. येथे एक अवघड गोष्ट आहे - आपल्याकडे फक्त एक इंटरफेस आहे. इथेच Waffle आपल्या मदतीला येतो. Waffle मध्ये एक जादुई `deployMockContract()` फंक्शन आहे जे केवळ इंटरफेसच्या _abi_ चा वापर करून कॉन्ट्रॅक्ट तयार करते:
+
+```typescript
+const mockERC20 = await deployMockContract(wallet, IERC20.abi)
+```
+
+आता वॉलेट आणि डिप्लॉय केलेला ERC20 या दोन्हींसह, आपण `AmIRichAlready` कॉन्ट्रॅक्ट डिप्लॉय करू शकतो:
+
+```typescript
+const contract = await deployContract(wallet, AmIRichAlready, [
+  mockERC20.address,
+])
+```
+
+या सर्वांसह, आपले `beforeEach()` फंक्शन पूर्ण झाले आहे. आतापर्यंत तुमची `AmIRichAlready.test.ts` फाइल अशी दिसली पाहिजे:
+
+```typescript
+import { expect, use } from "chai"
+import { Contract, utils, Wallet } from "ethers"
+import {
+  deployContract,
+  deployMockContract,
+  MockProvider,
+  solidity,
+} from "ethereum-waffle"
+
+import IERC20 from "../build/IERC20.json"
+import AmIRichAlready from "../build/AmIRichAlready.json"
+
+use(solidity)
+
+describe("Am I Rich Already", () => {
+  let mockERC20: Contract
+  let contract: Contract
+  let wallet: Wallet
+
+  beforeEach(async () => {
+    ;[wallet] = new MockProvider().getWallets()
+    mockERC20 = await deployMockContract(wallet, IERC20.abi)
+    contract = await deployContract(wallet, AmIRichAlready, [mockERC20.address])
+  })
+})
+```
+
+`AmIRichAlready` कॉन्ट्रॅक्टसाठी पहिली चाचणी लिहूया. तुम्हाला काय वाटते, आपली चाचणी कशाबद्दल असावी? होय, तुमचे बरोबर आहे! आपण आधीच श्रीमंत आहोत की नाही हे तपासले पाहिजे :)
+
+पण एक मिनिट थांबा. आपल्या मॉक्ड कॉन्ट्रॅक्टला कोणती मूल्ये परत करायची आहेत हे कसे कळेल? आपण `balanceOf()` फंक्शनसाठी कोणतीही लॉजिक लागू केलेली नाही. येथे पुन्हा Waffle मदत करू शकते. आपल्या मॉक्ड कॉन्ट्रॅक्टमध्ये आता काही नवीन आकर्षक गोष्टी आहेत:
+
+```typescript
+await mockERC20.mock.<nameOfMethod>.returns(<value>)
+await mockERC20.mock.<nameOfMethod>.withArgs(<arguments>).returns(<value>)
+```
+
+या माहितीसह आपण अखेरीस आपली पहिली चाचणी लिहू शकतो:
+
+```typescript
+it("जर वॉलेटमध्ये 1000000 पेक्षा कमी टोकन असतील तर false परत करते", async () => {
+  await mockERC20.mock.balanceOf.returns(utils.parseEther("999999"))
+  expect(await contract.check()).to.be.equal(false)
+})
+```
+
+चला ही चाचणी भागांमध्ये विभागूया:
+
+1. आपण आपला मॉक्ड ERC20 कॉन्ट्रॅक्ट नेहमी 999999 टोकनची शिल्लक (बॅलन्स) परत करण्यासाठी सेट करतो.
+2. `contract.check()` पद्धत `false` परत करते की नाही ते तपासा.
+
+हे सुरू करण्यासाठी आपण तयार आहोत:
+
+![एक चाचणी यशस्वी](./test-one.png)
+
+तर चाचणी काम करत आहे, पण... अजूनही सुधारणेला वाव आहे. `balanceOf()` फंक्शन नेहमी 999999 परत करेल. आपण एका विशिष्ट वॉलेटसाठी फंक्शनने काय परत करावे हे नमूद करून त्यात सुधारणा करू शकतो - अगदी खऱ्या कॉन्ट्रॅक्टप्रमाणे:
+
+```typescript
+it("जर वॉलेटमध्ये 1000001 पेक्षा कमी टोकन असतील तर false परत करते", async () => {
+  await mockERC20.mock.balanceOf
+    .withArgs(wallet.address)
+    .returns(utils.parseEther("999999"))
+  expect(await contract.check()).to.be.equal(false)
+})
+```
+
+आतापर्यंत, आपण फक्त अशा स्थितीची चाचणी केली आहे जिथे आपण पुरेसे श्रीमंत नाही. चला याच्या उलट चाचणी घेऊया:
+
+```typescript
+it("जर वॉलेटमध्ये किमान 1000001 टोकन असतील तर true परत करते", async () => {
+  await mockERC20.mock.balanceOf
+    .withArgs(wallet.address)
+    .returns(utils.parseEther("1000001"))
+  expect(await contract.check()).to.be.equal(true)
+})
+```
+
+तुम्ही चाचण्या चालवता...
+
+![दोन चाचण्या यशस्वी](test-two.png)
+
+...आणि हे बघा! आपला कॉन्ट्रॅक्ट अपेक्षेप्रमाणे काम करत आहे असे दिसते :)
+
+## कॉन्ट्रॅक्ट कॉल्सची चाचणी {#testing-contract-calls}
+
+आपण आतापर्यंत काय केले आहे याचा सारांश घेऊया. आपण आपल्या `AmIRichAlready` कॉन्ट्रॅक्टच्या कार्यक्षमतेची चाचणी घेतली आहे आणि ते योग्यरित्या काम करत असल्याचे दिसते. म्हणजे आपले काम झाले, बरोबर? अगदी नाही! Waffle आपल्याला आपल्या कॉन्ट्रॅक्टची आणखी चाचणी घेण्याची परवानगी देते. पण नक्की कसे? बरं, Waffle च्या भांडारात `calledOnContract()` आणि `calledOnContractWith()` मॅचर्स आहेत. आपल्या कॉन्ट्रॅक्टने ERC20 मॉक्ड कॉन्ट्रॅक्टला कॉल केला आहे की नाही हे तपासण्याची ते आपल्याला परवानगी देतील. या मॅचर्सपैकी एकासह येथे एक मूलभूत चाचणी दिली आहे:
+
+```typescript
+it("कॉन्ट्रॅक्टने ERC20 टोकनवर balanceOf कॉल केला आहे की नाही हे तपासते", async () => {
+  await mockERC20.mock.balanceOf.returns(utils.parseEther("999999"))
+  await contract.check()
+  expect("balanceOf").to.be.calledOnContract(mockERC20)
+})
+```
+
+मी तुम्हाला सांगितलेल्या दुसऱ्या मॅचरने आपण आणखी पुढे जाऊन ही चाचणी सुधारू शकतो:
+
+```typescript
+it("कॉन्ट्रॅक्टने ERC20 टोकनवर विशिष्ट वॉलेटसह balanceOf कॉल केला आहे की नाही हे तपासते", async () => {
+  await mockERC20.mock.balanceOf
+    .withArgs(wallet.address)
+    .returns(utils.parseEther("999999"))
+  await contract.check()
+  expect("balanceOf").to.be.calledOnContractWith(mockERC20, [wallet.address])
+})
+```
+
+चला चाचण्या बरोबर आहेत की नाही ते तपासूया:
+
+![तीन चाचण्या यशस्वी](test-three.png)
+
+छान, सर्व चाचण्या यशस्वी झाल्या आहेत.
+
+Waffle सह कॉन्ट्रॅक्ट कॉल्सची चाचणी घेणे खूप सोपे आहे. आणि सर्वात चांगली गोष्ट ही आहे. हे मॅचर्स सामान्य आणि मॉक्ड दोन्ही कॉन्ट्रॅक्ट्ससोबत काम करतात! याचे कारण असे आहे की Waffle इतर तंत्रज्ञानासाठी लोकप्रिय चाचणी लायब्ररींप्रमाणे कोड इंजेक्ट करण्याऐवजी EVM कॉल्सची नोंद ठेवते आणि फिल्टर करते.
+
+## अंतिम टप्पा {#the-finish-line}
+
+अभिनंदन! आता तुम्हाला कॉन्ट्रॅक्ट कॉल्सची चाचणी घेण्यासाठी आणि कॉन्ट्रॅक्ट्सना डायनॅमिकपणे मॉक करण्यासाठी Waffle कसे वापरावे हे माहित झाले आहे. शोधण्यासाठी आणखी बरीच मनोरंजक वैशिष्ट्ये आहेत. मी Waffle च्या डॉक्युमेंटेशनमध्ये अधिक माहिती घेण्याची शिफारस करतो.
+
+Waffle चे डॉक्युमेंटेशन [येथे](https://ethereum-waffle.readthedocs.io/) उपलब्ध आहे.
+
+या ट्यूटोरियलसाठी सोर्स कोड [येथे](https://github.com/EthWorks/Waffle/tree/master/examples/dynamic-mocking-and-testing-calls) मिळू शकेल.
+
+तुम्हाला यातही स्वारस्य असू शकेल अशी ट्यूटोरियल्स:
+
+- [Waffle सह स्मार्ट कॉन्ट्रॅक्टची चाचणी](/developers/tutorials/waffle-test-simple-smart-contract/)
diff --git a/public/content/translations/mr/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md b/public/content/translations/mr/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
new file mode 100644
index 00000000000..0beb100e491
--- /dev/null
+++ b/public/content/translations/mr/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
@@ -0,0 +1,204 @@
+---
+title: "hardhat आणि ethers वापरून Waffle hello world शिकवणी"
+description: "hardhat आणि ethers.js वापरून तुमचा पहिला Waffle प्रकल्प बनवा"
+author: "MiZiet"
+tags:
+  [
+    "waffle",
+    "स्मार्ट कॉन्ट्रॅक्ट",
+    "सॉलिडिटी",
+    "चाचणी",
+    "hardhat",
+    "ethers.js"
+  ]
+skill: beginner
+lang: mr
+published: 2020-10-16
+---
+
+या [Waffle](https://ethereum-waffle.readthedocs.io) शिकवणीमध्ये, आपण [hardhat](https://hardhat.org/) आणि [ethers.js](https://docs.ethers.io/v5/) वापरून एक साधा "Hello world" स्मार्ट कॉन्ट्रॅक्ट प्रकल्प कसा सेट करायचा हे शिकू. मग आपण आपल्या स्मार्ट कॉन्ट्रॅक्टमध्ये एक नवीन कार्यक्षमता कशी जोडावी आणि Waffle सह त्याची चाचणी कशी करावी हे शिकू.
+
+चला एक नवीन प्रकल्प तयार करून सुरुवात करूया:
+
+```bash
+yarn init
+```
+
+किंवा
+
+```bash
+npm init
+```
+
+आणि आवश्यक पॅकेजेस स्थापित करत आहोत:
+
+```bash
+yarn add -D hardhat @nomiclabs/hardhat-ethers ethers @nomiclabs/hardhat-waffle ethereum-waffle chai
+```
+
+किंवा
+
+```bash
+npm install -D hardhat @nomiclabs/hardhat-ethers ethers @nomiclabs/hardhat-waffle ethereum-waffle chai
+```
+
+पुढील पायरी `npx hardhat` चालवून एक नमुना hardhat प्रकल्प तयार करणे ही आहे.
+
+```bash
+888    888                      888 888               888
+888    888                      888 888               888
+888    888                      888 888               888
+8888888888  8888b.  888d888 .d88888 88888b.   8888b.  888888
+888    888     "88b 888P"  d88" 888 888 "88b     "88b 888
+888    888 .d888888 888    888  888 888  888 .d888888 888
+888    888 888  888 888    Y88b 888 888  888 888  888 Y88b.
+888    888 "Y888888 888     "Y88888 888  888 "Y888888  "Y888
+
+👷 Hardhat v2.0.3 मध्ये आपले स्वागत आहे 👷‍
+
+? तुम्हाला काय करायचे आहे? …
+❯ एक नमुना प्रकल्प तयार करा
+एक रिकामा hardhat.config.js तयार करा
+बाहेर पडा
+```
+
+`Create a sample project` निवडा
+
+आपल्या प्रकल्पाची रचना अशी दिसावी:
+
+```
+MyWaffleProject
+├── contracts
+│   └── Greeter.sol
+├── node_modules
+├── scripts
+│   └── sample-script.js
+├── test
+│   └── sample-test.js
+├── .gitattributes
+├── .gitignore
+├── hardhat.config.js
+└── package.json
+```
+
+### आता यापैकी काही फाइल्सबद्दल बोलूया: {#now-lets-talk}
+
+- Greeter.sol - solidity मध्ये लिहिलेला आमचा स्मार्ट कॉन्ट्रॅक्ट;
+
+```solidity
+contract Greeter {
+string greeting;
+
+constructor(string memory _greeting) public {
+console.log("अभिवादनासह ग्रीटर उपयोजित करत आहे:", _greeting);
+greeting = _greeting;
+}
+
+function greet() public view returns (string memory) {
+return greeting;
+}
+
+function setGreeting(string memory _greeting) public {
+console.log("अभिवादन '%s' वरून '%s' मध्ये बदलत आहे", greeting, _greeting);
+greeting = _greeting;
+}
+}
+```
+
+आपला स्मार्ट कॉन्ट्रॅक्ट तीन भागांमध्ये विभागला जाऊ शकतो:
+
+1. कन्स्ट्रक्टर - जिथे आपण `greeting` नावाचा एक स्ट्रिंग प्रकारचा व्हेरिएबल घोषित करतो,
+2. फंक्शन ग्रीट - एक फंक्शन जे कॉल केल्यावर `greeting` परत करेल,
+3. फंक्शन सेटग्रीटिंग - एक फंक्शन जे आपल्याला `greeting` चे मूल्य बदलण्याची परवानगी देते.
+
+- sample-test.js - आमची चाचणी फाइल
+
+```js
+describe("Greeter", function () {
+  it("एकदा बदलल्यावर नवीन अभिवादन परत केले पाहिजे", async function () {
+    const Greeter = await ethers.getContractFactory("Greeter")
+    const greeter = await Greeter.deploy("Hello, world!")
+
+    await greeter.deployed()
+    expect(await greeter.greet()).to.equal("Hello, world!")
+
+    await greeter.setGreeting("Hola, mundo!")
+    expect(await greeter.greet()).to.equal("Hola, mundo!")
+  })
+})
+```
+
+### पुढील पायरी म्हणजे आपला कॉन्ट्रॅक्ट संकलित करणे आणि चाचण्या चालवणे: {#compiling-and-testing}
+
+Waffle चाचण्या Mocha (एक चाचणी फ्रेमवर्क) आणि Chai (एक अभिकथन लायब्ररी) वापरतात. तुम्हाला फक्त `npx hardhat test` चालवायचे आहे आणि खालील संदेश येण्याची वाट पाहायची आहे.
+
+```bash
+✓ एकदा बदलल्यावर नवीन अभिवादन परत केले पाहिजे
+```
+
+### आतापर्यंत सर्व काही छान दिसत आहे, चला आपल्या प्रकल्पात थोडी अधिक गुंतागुंत वाढवूया <Emoji text=":slightly_smiling_face:" size={1}/> {#adding-complexity}
+
+अशा परिस्थितीची कल्पना करा जिथे कोणीतरी अभिवादन म्हणून एक रिकामा स्ट्रिंग जोडतो. ते एक आपुलकीचे अभिवादन होणार नाही, बरोबर?  
+असे होणार नाही याची खात्री करूया:
+
+जेव्हा कोणी रिकामा स्ट्रिंग पास करतो तेव्हा आम्हाला solidity चा `revert` वापरायचा आहे. चांगली गोष्ट ही आहे की आपण Waffle च्या चाय मॅचर `to.be.revertedWith()` सह या कार्यक्षमतेची सहज चाचणी घेऊ शकतो.
+
+```js
+it("रिकामा स्ट्रिंग पास केल्यावर उलटले पाहिजे", async () => {
+  const Greeter = await ethers.getContractFactory("Greeter")
+  const greeter = await Greeter.deploy("Hello, world!")
+
+  await greeter.deployed()
+  await expect(greeter.setGreeting("")).to.be.revertedWith(
+    "अभिवादन रिकामे नसावे"
+  )
+})
+```
+
+असे दिसते की आमची नवीन चाचणी यशस्वी झाली नाही:
+
+```bash
+अभिवादनासह ग्रीटर उपयोजित करत आहे: Hello, world!
+अभिवादन 'Hello, world!' वरून 'Hola, mundo!' मध्ये बदलत आहे
+    ✓ एकदा बदलल्यावर नवीन अभिवादन परत केले पाहिजे (1514ms)
+अभिवादनासह ग्रीटर उपयोजित करत आहे: Hello, world!
+अभिवादन 'Hello, world!' वरून '' मध्ये बदलत आहे
+    1) रिकामा स्ट्रिंग पास केल्यावर उलटले पाहिजे
+
+
+  1 यशस्वी (2s)
+  1 अयशस्वी
+```
+
+चला ही कार्यक्षमता आपल्या स्मार्ट कॉन्ट्रॅक्टमध्ये लागू करूया:
+
+```solidity
+require(bytes(_greeting).length > 0, "अभिवादन रिकामे नसावे");
+```
+
+आता, आमचे setGreeting फंक्शन असे दिसते:
+
+```solidity
+function setGreeting(string memory _greeting) public {
+require(bytes(_greeting).length > 0, "अभिवादन रिकामे नसावे");
+console.log("अभिवादन '%s' वरून '%s' मध्ये बदलत आहे", greeting, _greeting);
+greeting = _greeting;
+}
+```
+
+चला पुन्हा चाचण्या चालवूया:
+
+```bash
+✓ एकदा बदलल्यावर नवीन अभिवादन परत केले पाहिजे (1467ms)
+✓ रिकामा स्ट्रिंग पास केल्यावर उलटले पाहिजे (276ms)
+
+2 यशस्वी (2s)
+```
+
+अभिनंदन! तुम्ही ते केले :)
+
+### निष्कर्ष {#conclusion}
+
+आम्ही Waffle, Hardhat आणि ethers.js सह एक सोपा प्रकल्प बनवला. आपण प्रकल्प कसा सेट करायचा, चाचणी कशी जोडायची आणि नवीन कार्यक्षमता कशी लागू करायची हे शिकलो.
+
+तुमच्या स्मार्ट कॉन्ट्रॅक्टची चाचणी घेण्यासाठी अधिक उत्तम चाय मॅचर्ससाठी, [Waffle चे अधिकृत डॉक्स](https://ethereum-waffle.readthedocs.io/en/latest/matchers.html) तपासा.
diff --git a/public/content/translations/mr/developers/tutorials/waffle-test-simple-smart-contract/index.md b/public/content/translations/mr/developers/tutorials/waffle-test-simple-smart-contract/index.md
new file mode 100644
index 00000000000..e7c875c558f
--- /dev/null
+++ b/public/content/translations/mr/developers/tutorials/waffle-test-simple-smart-contract/index.md
@@ -0,0 +1,199 @@
+---
+title: "Waffle लायब्ररीसह साध्या स्मार्ट कॉन्ट्रॅक्टची चाचणी करणे"
+description: "नवशिक्यांसाठी ट्युटोरियल"
+author: Ewa Kowalska
+tags: [ "स्मार्ट कॉन्ट्रॅक्ट", "सॉलिडिटी", "Waffle", "चाचणी" ]
+skill: beginner
+lang: mr
+published: 2021-02-26
+---
+
+## या ट्युटोरियलमध्ये तुम्ही शिकाल की कसे {#in-this-tutorial-youll-learn-how-to}
+
+- वॉलेट बॅलन्समधील बदलांची चाचणी करा
+- निर्दिष्ट युक्तिवादांसह इव्हेंट्सच्या उत्सर्जनाची चाचणी करा
+- एक व्यवहार परत फिरवला गेला आहे हे निश्चित करा
+
+## गृहितके {#assumptions}
+
+- तुम्ही एक नवीन JavaScript किंवा TypeScript प्रकल्प तयार करू शकता
+- तुमच्याकडे JavaScript मधील चाचण्यांचा काही मूलभूत अनुभव आहे
+- तुम्ही yarn किंवा npm सारखे काही पॅकेज व्यवस्थापक वापरले आहेत
+- तुमच्याकडे स्मार्ट कॉन्ट्रॅक्ट्स आणि Solidity चे अतिशय मूलभूत ज्ञान आहे
+
+## सुरुवात करणे {#getting-started}
+
+या ट्युटोरियलमध्ये yarn वापरून टेस्ट सेटअप आणि रन कसे करायचे हे दाखवले आहे, पण जर तुम्ही npm ला प्राधान्य देत असाल तर काही हरकत नाही - मी अधिकृत Waffle [डॉक्युमेंटेशन](https://ethereum-waffle.readthedocs.io/en/latest/index.html) चे योग्य संदर्भ देईन.
+
+## डिपेन्डन्सीज इन्स्टॉल करा {#install-dependencies}
+
+तुमच्या प्रोजेक्टच्या डेव्हलपमेंट डिपेन्डन्सीजमध्ये ethereum-waffle आणि typescript डिपेन्डन्सीज [जोडा](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#installation).
+
+```bash
+yarn add --dev ethereum-waffle ts-node typescript @types/jest
+```
+
+## उदाहरण स्मार्ट कॉन्ट्रॅक्ट {#example-smart-contract}
+
+ट्युटोरियल दरम्यान आपण एका साध्या स्मार्ट कॉन्ट्रॅक्टच्या उदाहरणावर काम करू - EtherSplitter. हे कोणालाही काही wei पाठवण्याची आणि ते दोन पूर्वनिर्धारित रिसीव्हर्समध्ये समान रीतीने विभाजित करण्याव्यतिरिक्त फार काही करत नाही.
+स्प्लिट फंक्शनला wei ची संख्या सम असणे आवश्यक आहे, अन्यथा ते परत फिरवले जाईल. दोन्ही रिसीव्हर्ससाठी, ते एक wei ट्रान्सफर करते आणि त्यानंतर Transfer इव्हेंटचे उत्सर्जन होते.
+
+EtherSplitter कोडचा स्निपेट `src/EtherSplitter.sol` मध्ये ठेवा.
+
+```solidity
+pragma solidity ^0.6.0;
+
+contract EtherSplitter {
+    address payable receiver1;
+    address payable receiver2;
+
+    event Transfer(address from, address to, uint256 amount);
+
+    constructor(address payable _address1, address payable _address2) public {
+        receiver1 = _address1;
+        receiver2 = _address2;
+    }
+
+    function split() public payable {
+        require(msg.value % 2 == 0, 'विषम wei रक्कम परवानगी नाही');
+        receiver1.transfer(msg.value / 2);
+        emit Transfer(msg.sender, receiver1, msg.value / 2);
+        receiver2.transfer(msg.value / 2);
+        emit Transfer(msg.sender, receiver2, msg.value / 2);
+    }
+}
+```
+
+## कॉन्ट्रॅक्ट कंपाईल करा {#compile-the-contract}
+
+कॉन्ट्रॅक्ट [कंपाईल](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#compiling-the-contract) करण्यासाठी package.json फाईलमध्ये खालील एंट्री जोडा:
+
+```json
+"scripts": {
+    "build": "waffle"
+  }
+```
+
+पुढे, प्रोजेक्टच्या रूट डिरेक्टरीमध्ये Waffle कॉन्फिगरेशन फाईल - `waffle.json` - तयार करा आणि नंतर तिथे खालील कॉन्फिगरेशन पेस्ट करा:
+
+```json
+{
+  "compilerType": "solcjs",
+  "compilerVersion": "0.6.2",
+  "sourceDirectory": "./src",
+  "outputDirectory": "./build"
+}
+```
+
+`yarn build` चालवा. परिणामी, JSON फॉरमॅटमध्ये EtherSplitter च्या कंपाईल केलेल्या कॉन्ट्रॅक्टसह `build` डिरेक्टरी दिसेल.
+
+## टेस्ट सेटअप {#test-setup}
+
+Waffle सह चाचणी करण्यासाठी Chai मॅचर्स आणि Mocha वापरणे आवश्यक आहे, म्हणून तुम्हाला ते तुमच्या प्रोजेक्टमध्ये [जोडावे](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests) लागतील. तुमची package.json फाईल अपडेट करा आणि स्क्रिप्ट्स विभागात `test` एंट्री जोडा:
+
+```json
+"scripts": {
+    "build": "waffle",
+    "test": "export NODE_ENV=test && mocha -r ts-node/register 'test/**/*.test.ts'"
+  }
+```
+
+जर तुम्हाला तुमच्या चाचण्या [कार्यान्वित](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#running-tests) करायच्या असतील, तर फक्त `yarn test` चालवा.
+
+## चाचणी {#testing}
+
+आता `test` डिरेक्टरी तयार करा आणि `test\EtherSplitter.test.ts` ही नवीन फाईल तयार करा.
+खालील स्निपेट कॉपी करा आणि ते आपल्या टेस्ट फाईलमध्ये पेस्ट करा.
+
+```ts
+import { expect, use } from "chai"
+import { Contract } from "ethers"
+import { deployContract, MockProvider, solidity } from "ethereum-waffle"
+import EtherSplitter from "../build/EtherSplitter.json"
+
+use(solidity)
+
+describe("इथर स्प्लिटर", () => {
+  const [sender, receiver1, receiver2] = new MockProvider().getWallets()
+  let splitter: Contract
+
+  beforeEach(async () => {
+    splitter = await deployContract(sender, EtherSplitter, [
+      receiver1.address,
+      receiver2.address,
+    ])
+  })
+
+  // चाचण्या इथे जोडा
+})
+```
+
+आपण सुरू करण्यापूर्वी काही शब्द.
+`MockProvider` ब्लॉकचेनची एक मॉक आवृत्ती प्रदान करतो. ते मॉक वॉलेट्स देखील प्रदान करते जे EtherSplitter कॉन्ट्रॅक्टच्या चाचणीसाठी आपल्याला उपयोगी पडतील. प्रोव्हायडरवर `getWallets()` पद्धत कॉल करून आपण दहा पर्यंत वॉलेट्स मिळवू शकतो. उदाहरणामध्ये, आपण तीन वॉलेट्स मिळवतो - सेंडरसाठी आणि दोन रिसीव्हर्ससाठी.
+
+पुढे, आपण 'splitter' नावाचा एक व्हेरिएबल घोषित करतो - हा आपला मॉक EtherSplitter कॉन्ट्रॅक्ट आहे. `deployContract` पद्धतीद्वारे प्रत्येक एकाच चाचणीच्या अंमलबजावणीपूर्वी ते तयार केले जाते. ही पद्धत पहिला पॅरामीटर म्हणून पास केलेल्या वॉलेटमधून (आपल्या बाबतीत सेंडरचे वॉलेट) कॉन्ट्रॅक्टच्या डिप्लॉयमेंटचे सिम्युलेशन करते. दुसरा पॅरामीटर चाचणी केलेल्या कॉन्ट्रॅक्टचा ABI आणि बायटेकोड आहे - आपण तिथे `build` डिरेक्टरीमधून कंपाईल केलेल्या EtherSplitter कॉन्ट्रॅक्टची json फाईल पास करतो. तिसरा पॅरामीटर कॉन्ट्रॅक्टच्या कन्स्ट्रक्टर युक्तिवादांसह एक अ‍ॅरे आहे, जे आपल्या बाबतीत, रिसीव्हर्सचे दोन अ‍ॅड्रेस आहेत.
+
+## changeBalances {#changebalances}
+
+प्रथम, आपण तपासू की स्प्लिट पद्धत खरोखर रिसीव्हर्सच्या वॉलेट्समधील बॅलन्स बदलते का. जर आपण सेंडरच्या खात्यातून 50 wei विभाजित केले, तर आपण अपेक्षा करू की दोन्ही रिसीव्हर्सचा बॅलन्स 25 wei ने वाढेल. आपण Waffle चा `changeBalances` मॅचर वापरू:
+
+```ts
+it("खात्यांचे बॅलन्स बदलते", async () => {
+  await expect(() => splitter.split({ value: 50 })).to.changeBalances(
+    [receiver1, receiver2],
+    [25, 25]
+  )
+})
+```
+
+मॅचरचा पहिला पॅरामीटर म्हणून, आपण रिसीव्हर्सच्या वॉलेट्सचा एक अ‍ॅरे पास करतो, आणि दुसरा म्हणून - संबंधित खात्यांवरील अपेक्षित वाढीचा एक अ‍ॅरे.
+जर आपल्याला एका विशिष्ट वॉलेटचा बॅलन्स तपासायचा असेल, तर आपण `changeBalance` मॅचर देखील वापरू शकतो, ज्याला खालील उदाहरणाप्रमाणे अ‍ॅरे पास करण्याची आवश्यकता नाही:
+
+```ts
+it("खात्याचा बॅलन्स बदलते", async () => {
+  await expect(() => splitter.split({ value: 50 })).to.changeBalance(
+    receiver1,
+    25
+  )
+})
+```
+
+लक्षात घ्या की `changeBalance` आणि `changeBalances` या दोन्ही बाबतीत आपण स्प्लिट फंक्शन कॉलबॅक म्हणून पास करतो कारण मॅचरला कॉलच्या आधी आणि नंतरच्या बॅलन्सच्या स्थितीमध्ये प्रवेश करणे आवश्यक आहे.
+
+पुढे, आपण चाचणी करू की प्रत्येक wei च्या ट्रान्सफरनंतर Transfer इव्हेंट उत्सर्जित झाला होता का. आपण Waffle च्या दुसर्‍या मॅचरकडे वळूया:
+
+## Emit {#emit}
+
+```ts
+it("पहिल्या रिसीव्हरला हस्तांतरण झाल्यावर इव्हेंट उत्सर्जित करते", async () => {
+  await expect(splitter.split({ value: 50 }))
+    .to.emit(splitter, "Transfer")
+    .withArgs(sender.address, receiver1.address, 25)
+})
+
+it("दुसऱ्या रिसीव्हरला हस्तांतरण झाल्यावर इव्हेंट उत्सर्जित करते", async () => {
+  await expect(splitter.split({ value: 50 }))
+    .to.emit(splitter, "Transfer")
+    .withArgs(sender.address, receiver2.address, 25)
+})
+```
+
+`emit` मॅचर आपल्याला एखादी पद्धत कॉल केल्यावर कॉन्ट्रॅक्टने इव्हेंट उत्सर्जित केला आहे का हे तपासण्याची परवानगी देतो. `emit` मॅचरचे पॅरामीटर्स म्हणून, आपण तो मॉक कॉन्ट्रॅक्ट प्रदान करतो ज्यातून इव्हेंट उत्सर्जित होईल अशी आपण अपेक्षा करतो, त्यासोबत त्या इव्हेंटचे नावही देतो. आपल्या बाबतीत, मॉक कॉन्ट्रॅक्ट `splitter` आहे आणि इव्हेंटचे नाव - `Transfer` आहे. ज्या युक्तिवादांसह इव्हेंट उत्सर्जित झाला होता त्यांच्या अचूक मूल्यांचीही आपण पडताळणी करू शकतो - आपल्या इव्हेंट डिक्लेरेशनला जितके अपेक्षित आहेत तितके युक्तिवाद आपण `withArgs` मॅचरला पास करतो. EtherSplitter कॉन्ट्रॅक्टच्या बाबतीत, आपण हस्तांतरित wei रकमेसह सेंडर आणि रिसीव्हरचे अ‍ॅड्रेस पास करतो.
+
+## revertedWith {#revertedwith}
+
+शेवटचे उदाहरण म्हणून, आपण तपासू की विषम संख्येच्या wei च्या बाबतीत व्यवहार परत फिरवला गेला होता का. आपण `revertedWith` मॅचर वापरू:
+
+```ts
+it("wei रक्कम विषम असताना परत फिरवते", async () => {
+  await expect(splitter.split({ value: 51 })).to.be.revertedWith(
+    "विषम wei रक्कम परवानगी नाही"
+  )
+})
+```
+
+चाचणी, जर पास झाली, तर आपल्याला खात्री देईल की व्यवहार खरोखरच परत फिरवला गेला होता. तथापि, `require` स्टेटमेंटमध्ये आपण पास केलेल्या संदेशांमध्ये आणि `revertedWith` मध्ये आपण अपेक्षित असलेल्या संदेशात एक अचूक जुळणी देखील असणे आवश्यक आहे. जर आपण EtherSplitter कॉन्ट्रॅक्टच्या कोडवर परत गेलो, तर wei रकमेसाठीच्या `require` स्टेटमेंटमध्ये, आपण संदेश देतो: 'विषम wei रक्कम परवानगी नाही'. हे आपल्या चाचणीमध्ये अपेक्षित असलेल्या संदेशाशी जुळते. जर ते समान नसते, तर चाचणी अयशस्वी झाली असती.
+
+## अभिनंदन! {#congratulations}
+
+तुम्ही Waffle सह स्मार्ट कॉन्ट्रॅक्ट्सची चाचणी करण्याच्या दिशेने तुमचे पहिले मोठे पाऊल उचलले आहे!
diff --git a/public/content/translations/mr/developers/tutorials/yellow-paper-evm/index.md b/public/content/translations/mr/developers/tutorials/yellow-paper-evm/index.md
new file mode 100644
index 00000000000..c1744cca3b8
--- /dev/null
+++ b/public/content/translations/mr/developers/tutorials/yellow-paper-evm/index.md
@@ -0,0 +1,278 @@
+---
+title: "यलो पेपरचे EVM स्पेसिफिकेशन्स समजून घेणे"
+description: "यलो पेपरचा, Ethereum च्या औपचारिक स्पेसिफिकेशन्सचा तो भाग समजून घेणे, जो Ethereum व्हर्च्युअल मशीन (EVM) चे स्पष्टीकरण देतो."
+author: "qbzzt"
+tags: [ "evm" ]
+skill: intermediate
+lang: mr
+published: 2022-05-15
+---
+
+[यलो पेपर](https://ethereum.github.io/yellowpaper/paper.pdf) हे Ethereum साठीचे औपचारिक स्पेसिफिकेशन आहे. [EIP प्रक्रियेद्वारे](/eips/) सुधारित केलेले ठिकाण वगळता, त्यात सर्व काही कसे कार्य करते याचे अचूक वर्णन आहे. हे एक गणितीय पेपर म्हणून लिहिले आहे, ज्यामध्ये अशी परिभाषा आहे जी प्रोग्रामरना परिचित वाटणार नाही. या पेपरमध्ये तुम्ही ते कसे वाचावे हे शिकाल, आणि त्याचबरोबर इतर संबंधित गणितीय पेपर्स कसे वाचावेत हे देखील शिकाल.
+
+## कोणता यलो पेपर? {#which-yellow-paper}
+
+Ethereum मधील इतर बहुतेक गोष्टींप्रमाणेच, यलो पेपर देखील कालांतराने विकसित होतो. एका विशिष्ट आवृत्तीचा संदर्भ देता यावा यासाठी, मी [लिहिण्याच्या वेळी असलेली सध्याची आवृत्ती](yellow-paper-berlin.pdf) अपलोड केली आहे. मी वापरत असलेले विभाग, पृष्ठ आणि समीकरण क्रमांक त्याच आवृत्तीचा संदर्भ देतील. हे डॉक्युमेंट वाचताना दुसऱ्या विंडोमध्ये उघडे ठेवणे ही एक चांगली कल्पना आहे.
+
+### EVM का? {#why-the-evm}
+
+मूळ यलो पेपर Ethereum च्या विकासाच्या अगदी सुरुवातीला लिहिला गेला होता. हे मूळ प्रूफ-ऑफ-वर्क-आधारित सहमती यंत्रणेचे वर्णन करते जी मूळतः नेटवर्क सुरक्षित करण्यासाठी वापरली गेली होती. तथापि, Ethereum ने प्रूफ-ऑफ-वर्क बंद केले आणि सप्टेंबर 2022 मध्ये प्रूफ-ऑफ-स्टेक-आधारित सहमती वापरण्यास सुरुवात केली. हे ट्यूटोरियल यलो पेपरच्या त्या भागांवर लक्ष केंद्रित करेल जे Ethereum व्हर्च्युअल मशीनची व्याख्या करतात. प्रूफ-ऑफ-स्टेकमध्ये संक्रमण झाल्यामुळे EVM मध्ये कोणताही बदल झाला नाही (DIFFICULTY ऑपकोडच्या रिटर्न व्हॅल्यू वगळता).
+
+## 9 एक्झिक्युशन मॉडेल {#9-execution-model}
+
+या विभागात (पृ. 12-14) EVM च्या व्याख्येचा बहुतेक भाग समाविष्ट आहे.
+
+_सिस्टम स्टेट_ या शब्दात सिस्टीम चालवण्यासाठी तुम्हाला ज्या सर्व गोष्टींची माहिती असणे आवश्यक आहे त्या सर्वांचा समावेश होतो. एका सामान्य संगणकात, याचा अर्थ मेमरी, रजिस्टर्समधील मजकूर, इत्यादी.
+
+[ट्युरिंग मशीन](https://en.wikipedia.org/wiki/Turing_machine) हे एक संगणकीय मॉडेल आहे. मूलतः, ही संगणकाची एक सोपी आवृत्ती आहे, जी एक सामान्य संगणक करू शकणाऱ्या गणना चालवण्याची समान क्षमता असल्याचे सिद्ध झाले आहे (एक संगणक जे काही मोजू शकतो ते ट्युरिंग मशीन मोजू शकते आणि याउलट). हे मॉडेल काय गणनीय आहे आणि काय नाही याबद्दलचे विविध प्रमेय सिद्ध करणे सोपे करते.
+
+[ट्युरिंग-कम्प्लीट](https://en.wikipedia.org/wiki/Turing_completeness) या शब्दाचा अर्थ एक संगणक आहे जो ट्युरिंग मशीनसारखीच गणना करू शकतो. ट्युरिंग मशीन्स अनंत लूपमध्ये अडकू शकतात, आणि EVM अडकू शकत नाही कारण त्यात गॅस संपेल, त्यामुळे ते फक्त क्वासी-ट्युरिंग-कम्प्लीट आहे.
+
+## 9.1 मूलभूत गोष्टी {#91-basics}
+
+हा विभाग EVM च्या मूलभूत गोष्टी सांगतो आणि इतर संगणकीय मॉडेल्सशी त्याची तुलना कशी केली जाते.
+
+[स्टॅक मशीन](https://en.wikipedia.org/wiki/Stack_machine) हे एक संगणक आहे जे मध्यवर्ती डेटा रजिस्टर्समध्ये नाही, तर [**स्टॅक**](https://en.wikipedia.org/wiki/Stack_\(abstract_data_type\)) मध्ये संग्रहित करते. व्हर्च्युअल मशीनसाठी हे प्राधान्यकृत आर्किटेक्चर आहे कारण ते लागू करणे सोपे आहे, याचा अर्थ असा की बग्स आणि सुरक्षा भेद्यता खूप कमी असण्याची शक्यता असते. स्टॅकमधील मेमरी 256-बिट वर्ड्समध्ये विभागलेली आहे. हे निवडले गेले कारण ते Ethereum च्या मुख्य क्रिप्टोग्राफिक ऑपरेशन्ससाठी सोयीस्कर आहे, जसे की Keccak-256 हॅशिंग आणि एलिप्टिक कर्व्ह कॅल्क्युलेशन्स. स्टॅकचा कमाल आकार 1024 आयटम्स (1024 x 256 बिट्स) आहे. जेव्हा ऑपकोड्स कार्यान्वित केले जातात तेव्हा ते सहसा त्यांचे पॅरामीटर्स स्टॅकमधून मिळवतात. स्टॅकमधील घटकांची पुनर्रचना करण्यासाठी विशेषतः ऑपकोड्स आहेत जसे की `POP` (स्टॅकच्या वरून आयटम काढून टाकते), `DUP_N` (स्टॅकमधील N'व्या आयटमची डुप्लिकेट करते), इत्यादी.
+
+EVM मध्ये **मेमरी** नावाची एक अस्थिर जागा देखील आहे जी एक्झिक्युशन दरम्यान डेटा संग्रहित करण्यासाठी वापरली जाते. ही मेमरी 32-बाइट वर्ड्समध्ये आयोजित केली जाते. सर्व मेमरी लोकेशन्स शून्यावर इनिशिअलाइज केली जातात. जर तुम्ही मेमरीमध्ये एक वर्ड जोडण्यासाठी हा [Yul](https://docs.soliditylang.org/en/latest/yul.html) कोड कार्यान्वित केला, तर तो वर्डमधील रिकामी जागा शून्यांनी पॅड करून 32 बाइट्स मेमरी भरेल, म्हणजे, तो एक वर्ड तयार करतो - लोकेशन्स 0-29 मध्ये शून्य, 30 वर 0x60, आणि 31 वर 0xA7.
+
+```yul
+mstore(0, 0x60A7)
+```
+
+`mstore` हे EVM द्वारे मेमरीशी संवाद साधण्यासाठी प्रदान केलेल्या तीन ऑपकोड्सपैकी एक आहे - ते मेमरीमध्ये एक वर्ड लोड करते. इतर दोन `mstore8` आहेत जे मेमरीमध्ये एकच बाइट लोड करते, आणि `mload` जे मेमरीतून स्टॅकवर एक वर्ड हलवते.
+
+EVM मध्ये एक वेगळे नॉन-व्होलाटाईल **स्टोरेज** मॉडेल देखील आहे जे सिस्टम स्टेटचा एक भाग म्हणून राखले जाते - ही मेमरी वर्ड अॅरेमध्ये आयोजित केली जाते (स्टॅकमधील वर्ड-अॅड्रेसेबल बाइट अॅरेच्या विपरीत). हे स्टोरेज असे आहे जिथे कॉन्ट्रॅक्ट्स पर्सिस्टंट डेटा ठेवतात - एक कॉन्ट्रॅक्ट फक्त त्याच्या स्वतःच्या स्टोरेजशी संवाद साधू शकतो. स्टोरेज की-व्हॅल्यू मॅपिंगमध्ये आयोजित केले जाते.
+
+यलो पेपरच्या या विभागात याचा उल्लेख नसला तरी, चौथ्या प्रकारची मेमरी आहे हे जाणून घेणे देखील उपयुक्त आहे. **कॉलडेटा** ही बाइट-अॅड्रेसेबल रीड-ओन्ली मेमरी आहे जी व्यवहाराच्या `data` पॅरामीटरसह पास केलेले मूल्य संग्रहित करण्यासाठी वापरली जाते. EVM मध्ये `calldata` व्यवस्थापित करण्यासाठी विशिष्ट ऑपकोड्स आहेत. `calldatasize` डेटाचा आकार परत करते. `calldataload` डेटा स्टॅकमध्ये लोड करते. `calldatacopy` डेटा मेमरीमध्ये कॉपी करते.
+
+मानक [वॉन न्यूमन आर्किटेक्चर](https://en.wikipedia.org/wiki/Von_Neumann_architecture) कोड आणि डेटा एकाच मेमरीमध्ये संग्रहित करते. EVM सुरक्षिततेच्या कारणास्तव या मानकाचे पालन करत नाही - अस्थिर मेमरी शेअर केल्याने प्रोग्राम कोड बदलणे शक्य होते. त्याऐवजी, कोड स्टोरेजमध्ये सेव्ह केला जातो.
+
+अशी फक्त दोन प्रकरणे आहेत ज्यात कोड मेमरीमधून कार्यान्वित केला जातो:
+
+- जेव्हा एखादा कॉन्ट्रॅक्ट दुसरा कॉन्ट्रॅक्ट तयार करतो ([`CREATE`](https://www.evm.codes/#f0) किंवा [`CREATE2`](https://www.evm.codes/#f5) वापरून), कॉन्ट्रॅक्ट कंस्ट्रक्टरसाठीचा कोड मेमरीमधून येतो.
+- _कोणत्याही_ कॉन्ट्रॅक्टच्या निर्मितीदरम्यान, कंस्ट्रक्टर कोड चालतो आणि नंतर प्रत्यक्ष कॉन्ट्रॅक्टच्या कोडसह परत येतो, तो देखील मेमरीमधून.
+
+अपवादात्मक एक्झिक्युशन या शब्दाचा अर्थ असा आहे की असा अपवाद ज्यामुळे सध्याच्या कॉन्ट्रॅक्टचे एक्झिक्युशन थांबते.
+
+## 9.2 शुल्काचे अवलोकन {#92-fees-overview}
+
+हा विभाग गॅस शुल्क कसे मोजले जाते हे स्पष्ट करतो. तीन खर्च आहेत:
+
+### ऑपकोड खर्च {#opcode-cost}
+
+विशिष्ट ऑपकोडचा अंतर्भूत खर्च. हे मूल्य मिळविण्यासाठी, परिशिष्ट H (पृ. 28, समीकरण (327) अंतर्गत) मध्ये ऑपकोडचा खर्च गट शोधा आणि समीकरण (324) मध्ये खर्च गट शोधा. हे तुम्हाला एक खर्च फंक्शन देते, जे बहुतेक प्रकरणांमध्ये परिशिष्ट G (पृ. 27) मधील पॅरामीटर्स वापरते.
+
+उदाहरणार्थ, ऑपकोड [`CALLDATACOPY`](https://www.evm.codes/#37) हा _W<sub>copy</sub>_ गटाचा सदस्य आहे. त्या गटासाठी ऑपकोड खर्च _G<sub>verylow</sub>+G<sub>copy</sub>×⌈μ<sub>s</sub>[2]÷32⌉_ आहे. परिशिष्ट G पाहता, आपल्याला दिसते की दोन्ही स्थिरांक 3 आहेत, जे आपल्याला _3+3×⌈μ<sub>s</sub>[2]÷32⌉_ देते.
+
+आपल्याला अजूनही _⌈μ<sub>s</sub>[2]÷32⌉_ या अभिव्यक्तीचा अर्थ लावणे आवश्यक आहे. सर्वात बाहेरील भाग, _⌈ \<मूल्य\> ⌉_ हे सीलिंग फंक्शन आहे, एक फंक्शन जे दिलेले मूल्य परत करते जो सर्वात लहान पूर्णांक आहे जो अजूनही मूल्यापेक्षा लहान नाही. उदाहरणार्थ, _⌈2.5⌉ = ⌈3⌉ = 3_. आतील भाग _μ<sub>s</sub>[2]÷32_ आहे. पृष्ठ 3 वरील विभाग 3 (संकेत) पाहता, _μ_ ही मशीन स्टेट आहे. मशीन स्टेटची व्याख्या पृष्ठ 13 वरील विभाग 9.4.1 मध्ये केली आहे. त्या विभागानुसार, मशीन स्टेट पॅरामीटर्सपैकी एक स्टॅकसाठी _s_ आहे. हे सर्व एकत्र ठेवल्यास, असे दिसते की _μ<sub>s</sub>[2]_ हे स्टॅकमधील स्थान #2 आहे. [ऑपकोड](https://www.evm.codes/#37) पाहता, स्टॅकमधील स्थान #2 म्हणजे डेटाचा आकार बाइट्समध्ये. W<sub>copy</sub> गटातील इतर ऑपकोड्स, [`CODECOPY`](https://www.evm.codes/#39) आणि [`RETURNDATACOPY`](https://www.evm.codes/#3e) पाहता, त्यांच्याकडे त्याच ठिकाणी डेटाचा आकार देखील असतो. त्यामुळे _⌈μ<sub>s</sub>[2]÷32⌉_ म्हणजे कॉपी केल्या जात असलेल्या डेटाला संग्रहित करण्यासाठी आवश्यक असलेल्या 32 बाइट शब्दांची संख्या. सर्वकाही एकत्र ठेवल्यास, [`CALLDATACOPY`](https://www.evm.codes/#37) चा अंतर्भूत खर्च 3 गॅस अधिक कॉपी केल्या जाणाऱ्या डेटाच्या प्रति वर्ड 3 आहे.
+
+### चालू खर्च {#running-cost}
+
+आपण कॉल करत असलेल्या कोडला चालवण्याचा खर्च.
+
+- [`CREATE`](https://www.evm.codes/#f0) आणि [`CREATE2`](https://www.evm.codes/#f5) च्या बाबतीत, नवीन कॉन्ट्रॅक्टसाठीचा कंस्ट्रक्टर.
+- [`CALL`](https://www.evm.codes/#f1), [`CALLCODE`](https://www.evm.codes/#f2), [`STATICCALL`](https://www.evm.codes/#fa), किंवा [`DELEGATECALL`](https://www.evm.codes/#f4) च्या बाबतीत, आपण ज्या कॉन्ट्रॅक्टला कॉल करतो तो.
+
+### मेमरी विस्तार खर्च {#expanding-memory-cost}
+
+मेमरी विस्तारण्याचा खर्च (आवश्यक असल्यास).
+
+समीकरण 324 मध्ये, हे मूल्य _C<sub>mem</sub>(μ<sub>i</sub>')-C<sub>mem</sub>(μ<sub>i</sub>)_ असे लिहिले आहे. विभाग 9.4.1 पुन्हा पाहता, आपल्याला दिसते की _μ<sub>i</sub>_ हे मेमरीमधील शब्दांची संख्या आहे. त्यामुळे _μ<sub>i</sub>_ हे ऑपकोडच्या आधी मेमरीमधील शब्दांची संख्या आहे आणि _μ<sub>i</sub>'_ हे ऑपकोडनंतर मेमरीमधील शब्दांची संख्या आहे.
+
+_C<sub>mem</sub>_ हे फंक्शन समीकरण 326 मध्ये परिभाषित केले आहे: _C<sub>mem</sub>(a) = G<sub>memory</sub> × a + ⌊a<sup>2</sup> ÷ 512⌋_. ⌊x⌋ हे फ्लोअर फंक्शन आहे, एक फंक्शन जे दिलेले मूल्य परत करते जो सर्वात मोठा पूर्णांक आहे जो अजूनही मूल्यापेक्षा मोठा नाही. उदाहरणार्थ, ⌊2.5⌋ = ⌊2⌋ = 2._ जेव्हा _a < √512_, _a<sup>2</sup> < 512_, आणि फ्लोअर फंक्शनचा परिणाम शून्य असतो. त्यामुळे पहिल्या 22 शब्दांसाठी (704 बाइट्स), खर्च आवश्यक असलेल्या मेमरी शब्दांच्या संख्येसह रेषीयपणे वाढतो. त्या बिंदूच्या पलीकडे _⌊a<sup>2</sup> ÷ 512⌋_ धन असतो. जेव्हा आवश्यक असलेली मेमरी पुरेशी जास्त असते तेव्हा गॅस खर्च मेमरीच्या प्रमाणाच्या वर्गाच्या प्रमाणात असतो.
+
+**टीप** की हे घटक फक्त _अंतर्भूत_ गॅस खर्चावर परिणाम करतात - ते फी मार्केट किंवा व्हॅलिडेटर्सना मिळणाऱ्या टिप्सचा विचार करत नाहीत जे अंतिम वापरकर्त्याला किती पैसे द्यावे लागतील हे ठरवतात - हा फक्त EVM वर विशिष्ट ऑपरेशन चालवण्याचा कच्चा खर्च आहे.
+
+[गॅसविषयी अधिक वाचा](/developers/docs/gas/).
+
+## 9.3 एक्झिक्युशन पर्यावरण {#93-execution-env}
+
+एक्झिक्युशन पर्यावरण हे एक टपल, _I_ आहे, ज्यात अशी माहिती समाविष्ट आहे जी ब्लॉकचेन स्टेट किंवा EVM चा भाग नाही.
+
+| पॅरामीटर        | डेटामध्ये प्रवेश करण्यासाठी ऑपकोड                                                                              | डेटामध्ये प्रवेश करण्यासाठी सॉलिडिटी कोड                     |
+| --------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ |
+| _I<sub>a</sub>_ | [`ADDRESS`](https://www.evm.codes/#30)                                                                         | `address(this)`                                              |
+| _I<sub>o</sub>_ | [`ORIGIN`](https://www.evm.codes/#32)                                                                          | `tx.origin`                                                  |
+| _I<sub>p</sub>_ | [`GASPRICE`](https://www.evm.codes/#3a)                                                                        | `tx.gasprice`                                                |
+| _I<sub>d</sub>_ | [`CALLDATALOAD`](https://www.evm.codes/#35), इत्यादी.                                          | `msg.data`                                                   |
+| _I<sub>s</sub>_ | [`CALLER`](https://www.evm.codes/#33)                                                                          | `msg.sender`                                                 |
+| _I<sub>v</sub>_ | [`CALLVALUE`](https://www.evm.codes/#34)                                                                       | `msg.value`                                                  |
+| _I<sub>b</sub>_ | [`CODECOPY`](https://www.evm.codes/#39)                                                                        | `address(this).code`                                         |
+| _I<sub>H</sub>_ | ब्लॉक हेडर फील्ड्स, जसे की [`NUMBER`](https://www.evm.codes/#43) आणि [`DIFFICULTY`](https://www.evm.codes/#44) | `block.number`, `block.difficulty`, इत्यादी. |
+| _I<sub>e</sub>_ | कॉन्ट्रॅक्ट्समधील कॉल्ससाठी कॉल स्टॅकची खोली (कॉन्ट्रॅक्ट निर्मितीसह)                       |                                                              |
+| _I<sub>w</sub>_ | EVM ला स्टेट बदलण्याची परवानगी आहे का, की ते स्टॅटिकली चालत आहे                                                |                                                              |
+
+विभाग 9 चा उर्वरित भाग समजून घेण्यासाठी काही इतर पॅरामीटर्स आवश्यक आहेत:
+
+| पॅरामीटर | या विभागात परिभाषित                                             | अर्थ                                                                                                                                                                                                                                                            |
+| -------- | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| _σ_      | 2 (पृ. 2, समीकरण 1)          | ब्लॉकचेनची स्टेट                                                                                                                                                                                                                                                |
+| _g_      | 9.3 (पृ. 13) | शिल्लक गॅस                                                                                                                                                                                                                                                      |
+| _A_      | 6.1 (पृ. 8)  | एकत्रित सबस्टेट (व्यवहार संपल्यावर नियोजित बदल)                                                                                                                                                                                              |
+| _o_      | 9.3 (पृ. 13) | आउटपुट - अंतर्गत व्यवहाराच्या बाबतीत परत आलेला परिणाम (जेव्हा एक कॉन्ट्रॅक्ट दुसऱ्याला कॉल करतो) आणि व्ह्यू फंक्शन्सना केलेले कॉल (जेव्हा तुम्ही फक्त माहिती विचारत असता, त्यामुळे व्यवहारासाठी थांबण्याची आवश्यकता नसते) |
+
+## 9.4 एक्झिक्युशनचे अवलोकन {#94-execution-overview}
+
+आता आपल्याकडे सर्व प्राथमिक गोष्टी आहेत, आपण शेवटी EVM कसे कार्य करते यावर काम करण्यास सुरुवात करू शकतो.
+
+समीकरणे 137-142 आपल्याला EVM चालवण्यासाठीच्या प्रारंभिक अटी देतात:
+
+| चिन्ह            | प्रारंभिक मूल्य                                                                  | अर्थ                                                                                                                                                                                                                                                                                                                 |
+| ---------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| _μ<sub>g</sub>_  | _g_                                                                              | शिल्लक गॅस                                                                                                                                                                                                                                                                                                           |
+| _μ<sub>pc</sub>_ | _0_                                                                              | प्रोग्राम काउंटर, कार्यान्वित करण्याच्या पुढील निर्देशाचा अॅड्रेस                                                                                                                                                                                                                                                    |
+| _μ<sub>m</sub>_  | _(0, 0, ...)_ | मेमरी, सर्व शून्यांवर इनिशिअलाइज केलेली                                                                                                                                                                                                                                                                              |
+| _μ<sub>i</sub>_  | _0_                                                                              | वापरलेले सर्वोच्च मेमरी लोकेशन                                                                                                                                                                                                                                                                                       |
+| _μ<sub>s</sub>_  | _()_                                                          | स्टॅक, सुरुवातीला रिकामा                                                                                                                                                                                                                                                                                             |
+| _μ<sub>o</sub>_  | _∅_                                                                              | आउटपुट, जोपर्यंत आपण रिटर्न डेटासह ([`RETURN`](https://www.evm.codes/#f3) किंवा [`REVERT`](https://www.evm.codes/#fd)) किंवा त्याशिवाय ([`STOP`](https://www.evm.codes/#00) किंवा [`SELFDESTRUCT`](https://www.evm.codes/#ff)) थांबत नाही तोपर्यंत रिकामा सेट. |
+
+समीकरण 143 आपल्याला सांगते की एक्झिक्युशन दरम्यान प्रत्येक वेळी चार संभाव्य अटी आहेत, आणि त्यांचे काय करायचे:
+
+1. `Z(σ,μ,A,I)`. Z हे एक फंक्शन दर्शवते जे एखादे ऑपरेशन अवैध स्टेट संक्रमण तयार करते की नाही हे तपासते ([अपवादात्मक थांबणे](#942-exceptional-halting) पहा). जर त्याचे मूल्य True आले, तर नवीन स्टेट जुन्या स्टेटसारखीच असते (गॅस जळतो वगळता) कारण बदल लागू केलेले नाहीत.
+2. जर कार्यान्वित होणारा ऑपकोड [`REVERT`](https://www.evm.codes/#fd) असेल, तर नवीन स्टेट जुन्या स्टेटसारखीच असते, काही गॅस वाया जातो.
+3. जर ऑपरेशन्सचा क्रम पूर्ण झाला असेल, जसे की [`RETURN`](https://www.evm.codes/#f3) द्वारे सूचित केले जाते, तर स्टेट नवीन स्टेटमध्ये अपडेट केली जाते.
+4. जर आपण 1-3 या अंतिम अटींपैकी एकात नसू, तर चालवणे सुरू ठेवा.
+
+## 9.4.1 मशीन स्टेट {#941-machine-state}
+
+हा विभाग मशीन स्टेट अधिक तपशीलवार स्पष्ट करतो. हे निर्दिष्ट करते की _w_ हा सध्याचा ऑपकोड आहे. जर _μ<sub>pc</sub>_ हे _||I<sub>b</sub>||_ पेक्षा कमी असेल, जे कोडची लांबी आहे, तर तो बाइट (_I<sub>b</sub>[μ<sub>pc</sub>]_) ऑपकोड आहे. अन्यथा, ऑपकोड [`STOP`](https://www.evm.codes/#00) म्हणून परिभाषित केला आहे.
+
+हे एक [स्टॅक मशीन](https://en.wikipedia.org/wiki/Stack_machine) असल्याने, आपल्याला प्रत्येक ऑपकोडद्वारे बाहेर काढलेल्या (_δ_) आणि आत टाकलेल्या (_α_) आयटमच्या संख्येचा मागोवा ठेवणे आवश्यक आहे.
+
+## 9.4.2 अपवादात्मक थांबणे {#942-exceptional-halt}
+
+हा विभाग _Z_ फंक्शन परिभाषित करतो, जो निर्दिष्ट करतो की आपल्याकडे असामान्य समाप्ती केव्हा होते. हे एक [बूलियन](https://en.wikipedia.org/wiki/Boolean_data_type) फंक्शन आहे, म्हणून ते [लॉजिकल ऑर साठी _∨_](https://en.wikipedia.org/wiki/Logical_disjunction) आणि [लॉजिकल अँड साठी _∧_](https://en.wikipedia.org/wiki/Logical_conjunction) वापरते.
+
+यापैकी कोणतीही अट सत्य असल्यास आम्हाला एक अपवादात्मक थांबा मिळतो:
+
+- **_μ<sub>g</sub> < C(σ,μ,A,I)_**
+  जसे आपण विभाग 9.2 मध्ये पाहिले, _C_ हे फंक्शन आहे जे गॅसचा खर्च निर्दिष्ट करते. पुढील ऑपकोडसाठी पुरेसा गॅस शिल्लक नाही.
+
+- **_δ<sub>w</sub>=∅_**
+  जर एखाद्या ऑपकोडसाठी बाहेर काढलेल्या आयटमची संख्या अपरिभाषित असेल, तर ऑपकोड स्वतःच अपरिभाषित असतो.
+
+- **_|| μ<sub>s</sub> || < δ<sub>w</sub>_**
+  स्टॅक अंडरफ्लो, सध्याच्या ऑपकोडसाठी स्टॅकमध्ये पुरेसे आयटम नाहीत.
+
+- **_w = JUMP ∧ μ<sub>s</sub>[0]∉D(I<sub>b</sub>)_**
+  ऑपकोड [`JUMP`](https://www.evm.codes/#56) आहे आणि अॅड्रेस [`JUMPDEST`](https://www.evm.codes/#5b) नाही. जेव्हा गंतव्यस्थान [`JUMPDEST`](https://www.evm.codes/#5b) असेल तेव्हाच जंप _केवळ_ वैध असतात.
+
+- **_w = JUMPI ∧ μ<sub>s</sub>[1]≠0 ∧ μ<sub>s</sub>[0] ∉ D(I<sub>b</sub>)_**
+  ऑपकोड [`JUMPI`](https://www.evm.codes/#57) आहे, अट सत्य आहे (शून्य नाही) त्यामुळे जंप व्हायला हवा, आणि अॅड्रेस [`JUMPDEST`](https://www.evm.codes/#5b) नाही. जेव्हा गंतव्यस्थान [`JUMPDEST`](https://www.evm.codes/#5b) असेल तेव्हाच जंप _केवळ_ वैध असतात.
+
+- **_w = RETURNDATACOPY ∧ μ<sub>s</sub>[1]+μ<sub>s</sub>[2]>|| μ<sub>o</sub> ||_**
+  ऑपकोड [`RETURNDATACOPY`](https://www.evm.codes/#3e) आहे. या ऑपकोडमध्ये स्टॅक घटक _μ<sub>s</sub>[1]_ रिटर्न डेटा बफरमध्ये वाचण्यासाठीचा ऑफसेट आहे, आणि स्टॅक घटक _μ<sub>s</sub>[2]_ डेटाची लांबी आहे. जेव्हा तुम्ही रिटर्न डेटा बफरच्या शेवटी पलीकडे वाचण्याचा प्रयत्न करता तेव्हा ही अट उद्भवते. लक्षात घ्या की कॉलडेटासाठी किंवा कोडसाठीच अशीच अट नाही. जेव्हा तुम्ही त्या बफर्सच्या शेवटी पलीकडे वाचण्याचा प्रयत्न करता तेव्हा तुम्हाला फक्त शून्य मिळतात.
+
+- **_|| μ<sub>s</sub> || - δ<sub>w</sub> + α<sub>w</sub> > 1024_**
+
+  स्टॅक ओव्हरफ्लो. जर ऑपकोड चालवल्याने 1024 पेक्षा जास्त आयटमचा स्टॅक तयार होणार असेल, तर रद्द करा.
+
+- **_¬I<sub>w</sub> ∧ W(w,μ)_**
+  आपण स्टॅटिकली चालवत आहोत का ([¬ म्हणजे नकार](https://en.wikipedia.org/wiki/Negation) आणि _I<sub>w</sub>_ सत्य आहे जेव्हा आपल्याला ब्लॉकचेन स्टेट बदलण्याची परवानगी असते)? जर असे असेल, आणि आपण स्टेट बदलणारे ऑपरेशन करण्याचा प्रयत्न करत असू, तर ते होऊ शकत नाही.
+
+  _W(w,μ)_ हे फंक्शन नंतर समीकरण 150 मध्ये परिभाषित केले आहे. यापैकी एक अट सत्य असल्यास _W(w,μ)_ सत्य आहे:
+
+  - **_w ∈ \{CREATE, CREATE2, SSTORE, SELFDESTRUCT}_**
+    हे ऑपकोड्स स्टेट बदलतात, एकतर नवीन कॉन्ट्रॅक्ट तयार करून, मूल्य संग्रहित करून किंवा सध्याचा कॉन्ट्रॅक्ट नष्ट करून.
+
+  - **_LOG0≤w ∧ w≤LOG4_**
+    जर आपल्याला स्टॅटिकली कॉल केले असेल तर आपण लॉग नोंदी जारी करू शकत नाही.
+    लॉग ऑपकोड्स सर्व [`LOG0` (A0)](https://www.evm.codes/#a0) आणि [`LOG4` (A4)](https://www.evm.codes/#a4) दरम्यानच्या श्रेणीत आहेत.
+    लॉग ऑपकोडनंतरची संख्या लॉग एंट्रीमध्ये किती विषय आहेत हे निर्दिष्ट करते.
+
+  - **_w=CALL ∧ μ<sub>s</sub>[2]≠0_**
+    तुम्ही स्टॅटिक असताना दुसऱ्या कॉन्ट्रॅक्टला कॉल करू शकता, पण जर तुम्ही तसे केले तर तुम्ही त्याला ETH हस्तांतरित करू शकत नाही.
+
+- **_w = SSTORE ∧ μ<sub>g</sub> ≤ G<sub>callstipend</sub>_**
+  तुमच्याकडे G<sub>callstipend</sub> (परिशिष्ट G मध्ये 2300 म्हणून परिभाषित) पेक्षा जास्त गॅस असल्याशिवाय तुम्ही [`SSTORE`](https://www.evm.codes/#55) चालवू शकत नाही.
+
+## 9.4.3 जंप डेस्टिनेशन वैधता {#943-jump-dest-valid}
+
+येथे आपण [`JUMPDEST`](https://www.evm.codes/#5b) ऑपकोड्स काय आहेत हे औपचारिकपणे परिभाषित करतो. आपण फक्त 0x5B बाइट मूल्य शोधू शकत नाही, कारण ते PUSH च्या आत असू शकते (आणि म्हणून डेटा आणि ऑपकोड नाही).
+
+समीकरण (153) मध्ये आपण एक फंक्शन, _N(i,w)_ परिभाषित करतो. पहिला पॅरामीटर, _i_, ऑपकोडचे स्थान आहे. दुसरा, _w_, ऑपकोड स्वतःच आहे. जर _w∈[PUSH1, PUSH32]_ असेल तर याचा अर्थ ऑपकोड PUSH आहे (चौरस कंस अंत्यबिंदू समाविष्ट असलेली श्रेणी परिभाषित करतात). त्या बाबतीत पुढील ऑपकोड _i+2+(w−PUSH1)_ येथे आहे. [`PUSH1`](https://www.evm.codes/#60) साठी आपल्याला दोन बाइट्सने पुढे जाणे आवश्यक आहे (PUSH स्वतः आणि एक बाइट मूल्य), [`PUSH2`](https://www.evm.codes/#61) साठी आपल्याला तीन बाइट्सने पुढे जाणे आवश्यक आहे कारण ते दोन बाइट मूल्य आहे, इत्यादी. इतर सर्व EVM ऑपकोड्स फक्त एक बाइट लांब आहेत, म्हणून इतर सर्व प्रकरणांमध्ये _N(i,w)=i+1_.
+
+हे फंक्शन समीकरण (152) मध्ये _D<sub>J</sub>(c,i)_ परिभाषित करण्यासाठी वापरले जाते, जे कोड _c_ मध्ये, ऑपकोड स्थान _i_ पासून सुरू होणाऱ्या सर्व वैध जंप गंतव्यस्थानांचा [संच](https://en.wikipedia.org/wiki/Set_\(mathematics\)) आहे. हे फंक्शन पुनरावृत्तीने परिभाषित केले आहे. जर _i≥||c||_ असेल, तर याचा अर्थ असा की आपण कोडच्या शेवटी किंवा नंतर आहोत. आम्हाला आणखी जंप गंतव्यस्थान सापडणार नाहीत, म्हणून फक्त रिकामा संच परत करा.
+
+इतर सर्व प्रकरणांमध्ये आपण पुढील ऑपकोडवर जाऊन आणि त्यापासून सुरू होणारा संच मिळवून उर्वरित कोड पाहतो. _c[i]_ हा सध्याचा ऑपकोड आहे, म्हणून _N(i,c[i])_ हे पुढील ऑपकोडचे स्थान आहे. _D<sub>J</sub>(c,N(i,c[i]))_ म्हणून पुढील ऑपकोडपासून सुरू होणाऱ्या वैध जंप गंतव्यस्थानांचा संच आहे. जर सध्याचा ऑपकोड `JUMPDEST` नसेल, तर फक्त तो संच परत करा. जर ते `JUMPDEST` असेल, तर ते परिणाम संचामध्ये समाविष्ट करा आणि ते परत करा.
+
+## 9.4.4 सामान्य थांबणे {#944-normal-halt}
+
+थांबणारे फंक्शन _H_, तीन प्रकारचे मूल्य परत करू शकते.
+
+- जर आपण हॉल्ट ऑपकोडमध्ये नसू, तर _∅_, रिकामा संच परत करा. परंपरेनुसार, हे मूल्य बूलियन फाल्स म्हणून अर्थ लावले जाते.
+- जर आपल्याकडे हॉल्ट ऑपकोड असेल जो आउटपुट तयार करत नाही ([`STOP`](https://www.evm.codes/#00) किंवा [`SELFDESTRUCT`](https://www.evm.codes/#ff)), तर परत मूल्य म्हणून शून्य बाइट्सचा क्रम परत करा. लक्षात घ्या की हे रिकाम्या संचापेक्षा खूप वेगळे आहे. या मूल्याचा अर्थ असा आहे की EVM खरोखर थांबले आहे, फक्त वाचण्यासाठी कोणताही रिटर्न डेटा नाही.
+- जर आपल्याकडे हॉल्ट ऑपकोड असेल जो आउटपुट तयार करतो ([`RETURN`](https://www.evm.codes/#f3) किंवा [`REVERT`](https://www.evm.codes/#fd)), तर त्या ऑपकोडद्वारे निर्दिष्ट केलेला बाइट्सचा क्रम परत करा. हा क्रम मेमरीमधून घेतला जातो, स्टॅकच्या शीर्षस्थानी असलेले मूल्य (_μ<sub>s</sub>[0]_) पहिला बाइट आहे, आणि त्यानंतरचे मूल्य (_μ<sub>s</sub>[1]_) लांबी आहे.
+
+## H.2 सूचना संच {#h2-instruction-set}
+
+EVM च्या अंतिम उपविभाग 9.5 वर जाण्यापूर्वी, आपण सूचना स्वतः पाहूया. ते परिशिष्ट H.2 मध्ये परिभाषित केले आहेत जे पृ. 29 पासून सुरू होते. त्या विशिष्ट ऑपकोडसह बदलणारे म्हणून निर्दिष्ट नसलेली कोणतीही गोष्ट तशीच राहण्याची अपेक्षा आहे. बदलणारे व्हेरिएबल्स \<काहीतरी\>′ सह निर्दिष्ट केले जातात.
+
+उदाहरणार्थ, आपण [`ADD`](https://www.evm.codes/#01) ऑपकोड पाहूया.
+
+| मूल्य | स्मरणीय | δ | α | वर्णन                                                                                                                                                                                                                 |
+| ----: | ------- | - | - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0x01 | ADD     | 2 | 1 | बेरीज ऑपरेशन.                                                                                                                                                                                         |
+|       |         |   |   | _μ′<sub>s</sub>[0] ≡ μ<sub>s</sub>[0] + μ<sub>s</sub>[1]_ |
+
+_δ_ ही आपण स्टॅकमधून काढलेल्या मूल्यांची संख्या आहे. या प्रकरणात दोन, कारण आपण शीर्षस्थानी असलेल्या दोन मूल्यांची बेरीज करत आहोत.
+
+_α_ ही आपण परत ढकललेल्या मूल्यांची संख्या आहे. या प्रकरणात एक, बेरीज.
+
+त्यामुळे नवीन स्टॅक टॉप (_μ′<sub>s</sub>[0]_) जुन्या स्टॅक टॉप (_μ<sub>s</sub>[0]_) आणि त्याखालील जुन्या मूल्याची (_μ<sub>s</sub>[1]_) बेरीज आहे.
+
+सर्व ऑपकोड्सची "डोळे मिटून घेणारी यादी" पाहण्याऐवजी, हा लेख फक्त त्या ऑपकोड्सचे स्पष्टीकरण देतो जे काहीतरी नवीन सादर करतात.
+
+| मूल्य | स्मरणीय   | δ | α | वर्णन                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| ----: | --------- | - | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0x20 | KECCAK256 | 2 | 1 | Keccak-256 हॅशची गणना करा.                                                                                                                                                                                                                                                                                                                                                                                                                           |
+|       |           |   |   | _μ′<sub>s</sub>[0] ≡ KEC(μ<sub>m</sub>[μ<sub>s</sub>[0] . . . (μ<sub>s</sub>[0] + μ<sub>s</sub>[1] − 1)])_ |
+|       |           |   |   | _μ′<sub>i</sub> ≡ M(μ<sub>i</sub>,μ<sub>s</sub>[0],μ<sub>s</sub>[1])_                                                                                                                                                                                                                                                                     |
+
+हा पहिला ऑपकोड आहे जो मेमरीमध्ये प्रवेश करतो (या प्रकरणात, फक्त वाचन). तथापि, ते मेमरीच्या सध्याच्या मर्यादांच्या पलीकडे विस्तारू शकते, म्हणून आपल्याला _μ<sub>i</sub>_ अपडेट करणे आवश्यक आहे. आपण हे पृष्ठ 29 वरील समीकरण 328 मध्ये परिभाषित केलेल्या _M_ फंक्शनचा वापर करून करतो.
+
+| मूल्य | स्मरणीय | δ | α | वर्णन                                               |
+| ----: | ------- | - | - | --------------------------------------------------- |
+|  0x31 | BALANCE | 1 | 1 | दिलेल्या खात्याची शिल्लक मिळवा.     |
+|       |         |   |   | ... |
+
+ज्या पत्त्याची शिल्लक आपल्याला शोधायची आहे तो _μ<sub>s</sub>[0] mod 2<sup>160</sup>_ आहे. स्टॅकच्या शीर्षस्थानी अॅड्रेस आहे, परंतु अॅड्रेस फक्त 160 बिट्सचे असल्यामुळे, आपण [मॉड्युलो](https://en.wikipedia.org/wiki/Modulo_operation) 2<sup>160</sup> मूल्याची गणना करतो.
+
+जर _σ[μ<sub>s</sub>[0] mod 2<sup>160</sup>] ≠ ∅_ असेल, तर याचा अर्थ या अॅड्रेसबद्दल माहिती आहे. त्या बाबतीत, _σ[μ<sub>s</sub>[0] mod 2<sup>160</sup>]<sub>b</sub>_ ही त्या अॅड्रेसची शिल्लक आहे. जर _σ[μ<sub>s</sub>[0] mod 2<sup>160</sup>] = ∅_ असेल, तर याचा अर्थ हा अॅड्रेस इनिशिअलाइज केलेला नाही आणि शिल्लक शून्य आहे. तुम्ही पृष्ठ 4 वरील विभाग 4.1 मध्ये खाते माहिती फील्डची यादी पाहू शकता.
+
+दुसरे समीकरण, _A'<sub>a</sub> ≡ A<sub>a</sub> ∪ \{μ<sub>s</sub>[0] mod 2<sup>160</sup>}_, हे वॉर्म स्टोरेज (स्टोरेज ज्यावर नुकताच प्रवेश केला गेला आहे आणि कॅश होण्याची शक्यता आहे) आणि कोल्ड स्टोरेज (स्टोरेज ज्यावर प्रवेश केला गेला नाही आणि पुनर्प्राप्त करण्यासाठी अधिक महाग असलेल्या हळू स्टोरेजमध्ये असण्याची शक्यता आहे) मधील प्रवेश खर्चातील फरकाशी संबंधित आहे. _A<sub>a</sub>_ ही व्यवहाराद्वारे पूर्वी प्रवेश केलेल्या पत्त्यांची सूची आहे, ज्यामुळे प्रवेश करणे स्वस्त असले पाहिजे, जसे की पृष्ठ 8 वरील विभाग 6.1 मध्ये परिभाषित केले आहे. तुम्ही या विषयावर [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929) मध्ये अधिक वाचू शकता.
+
+| मूल्य | स्मरणीय | δ  | α  | वर्णन                                                                                                                                           |
+| ----: | ------- | -- | -- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0x8F | DUP16   | 16 | 17 | 16 व्या स्टॅक आयटमची डुप्लिकेट करा.                                                                                             |
+|       |         |    |    | _μ′<sub>s</sub>[0] ≡ μ<sub>s</sub>[15]_ |
+
+लक्षात घ्या की कोणताही स्टॅक आयटम वापरण्यासाठी, आपल्याला तो पॉप करणे आवश्यक आहे, याचा अर्थ आपल्याला त्याच्यावरील सर्व स्टॅक आयटम देखील पॉप करणे आवश्यक आहे. [`DUP<n>`](https://www.evm.codes/#8f) आणि [`SWAP<n>`](https://www.evm.codes/#9f) च्या बाबतीत, याचा अर्थ सोळा मूल्यांपर्यंत पॉप करणे आणि नंतर पुश करणे आहे.
+
+## 9.5 एक्झिक्युशन सायकल {#95-exec-cycle}
+
+आता आपल्याकडे सर्व भाग आहेत, आपण शेवटी EVM चे एक्झिक्युशन सायकल कसे दस्तऐवजीकरण केले आहे हे समजू शकतो.
+
+समीकरण (155) म्हणते की दिलेली स्टेट:
+
+- _σ_ (जागतिक ब्लॉकचेन स्टेट)
+- _μ_ (EVM स्टेट)
+- _A_ (सबस्टेट, व्यवहार संपल्यावर होणारे बदल)
+- _I_ (एक्झिक्युशन पर्यावरण)
+
+नवीन स्टेट _(σ', μ', A', I')_ आहे.
+
+समीकरणे (156)-(158) स्टॅक आणि ऑपकोडमुळे त्यात होणारा बदल (_μ<sub>s</sub>_) परिभाषित करतात. समीकरण (159) गॅसमधील बदल (_μ<sub>g</sub>_) आहे. समीकरण (160) प्रोग्राम काउंटरमधील बदल (_μ<sub>pc</sub>_) आहे. शेवटी, समीकरणे (161)-(164) निर्दिष्ट करतात की इतर पॅरामीटर्स तसेच राहतात, जोपर्यंत ऑपकोडद्वारे स्पष्टपणे बदलले जात नाही.
+
+याद्वारे EVM पूर्णपणे परिभाषित आहे.
+
+## निष्कर्ष {#conclusion}
+
+गणितीय नोटेशन अचूक आहे आणि त्याने यलो पेपरला Ethereum च्या प्रत्येक तपशीलाचे तपशीलवार वर्णन करण्याची परवानगी दिली आहे. तथापि, त्याचे काही तोटे आहेत:
+
+- हे फक्त मानवांनाच समजू शकते, याचा अर्थ असा की [अनुपालन चाचण्या](https://github.com/ethereum/tests) हाताने लिहाव्या लागतील.
+- प्रोग्रामर संगणक कोड समजतात.
+  ते गणितीय नोटेशन समजू शकतात किंवा नाही.
+
+कदाचित या कारणांमुळे, नवीन [कन्सेंसस लेयर स्पेक्स](https://github.com/ethereum/consensus-specs/blob/dev/tests/core/pyspec/README.md) पायथनमध्ये लिहिलेले आहेत. [पायथनमधील एक्झिक्युशन लेयर स्पेक्स](https://ethereum.github.io/execution-specs) आहेत, परंतु ते पूर्ण नाहीत. जोपर्यंत संपूर्ण यलो पेपर पायथन किंवा तत्सम भाषेत भाषांतरित होत नाही, तोपर्यंत यलो पेपर सेवेत राहील, आणि ते वाचण्यास सक्षम असणे उपयुक्त आहे.
diff --git a/public/content/translations/mr/eips/index.md b/public/content/translations/mr/eips/index.md
new file mode 100644
index 00000000000..3695cb478c0
--- /dev/null
+++ b/public/content/translations/mr/eips/index.md
@@ -0,0 +1,78 @@
+---
+title: "इथरियम सुधारणा प्रस्ताव (EIPs)"
+description: "EIPs समजून घेण्यासाठी तुम्हाला आवश्यक असलेली मूलभूत माहिती"
+lang: mr
+---
+
+# इथरियम सुधारणा प्रस्तावांची (EIPs) ओळख {#introduction-to-ethereum-improvement-proposals}
+
+## EIPs म्हणजे काय? {#what-are-eips}
+
+[इथरियम सुधारणा प्रस्ताव (EIPs)](https://eips.ethereum.org/) हे इथेरियमसाठी संभाव्य नवीन वैशिष्ट्ये किंवा प्रक्रिया निर्दिष्ट करणारे मानक आहेत. EIPs मध्ये प्रस्तावित बदलांसाठी तांत्रिक तपशील असतात आणि ते समुदायासाठी “सत्याचा स्रोत” म्हणून काम करतात. Ethereum साठी नेटवर्क अपग्रेड्स आणि ॲप्लिकेशन मानकांवर EIP प्रक्रियेद्वारे चर्चा केली जाते आणि ते विकसित केले जातात.
+
+इथरियम समुदायातील कोणीही EIP तयार करू शकतो. EIPs लिहिण्यासाठीची मार्गदर्शक तत्त्वे [EIP-1](https://eips.ethereum.org/EIPS/eip-1) मध्ये समाविष्ट आहेत. EIP ने प्रामुख्याने थोड्या प्रेरणेसह एक संक्षिप्त तांत्रिक तपशील प्रदान केला पाहिजे. EIP लेखक समुदायामध्ये एकमत साधण्यासाठी आणि पर्यायी मतांचे दस्तऐवजीकरण करण्यासाठी जबाबदार असतो. एक सुव्यवस्थित EIP सादर करण्यासाठी उच्च तांत्रिक अडथळा लक्षात घेता, ऐतिहासिकदृष्ट्या, बहुतेक EIP लेखक सामान्यतः ॲप्लिकेशन किंवा प्रोटोकॉल डेव्हलपर्स असतात.
+
+## EIPs का महत्त्वाचे आहेत? {#why-do-eips-matter}
+
+इथेरियमवर बदल कसे होतात आणि ते कसे दस्तऐवजीकरण केले जातात यात EIPs मध्यवर्ती भूमिका बजावतात. लोकांसाठी बदल प्रस्तावित करण्याचा, त्यावर चर्चा करण्याचा आणि ते स्वीकारण्याचा हा एक मार्ग आहे. [EIPs चे विविध प्रकार](https://eips.ethereum.org/EIPS/eip-1#eip-types) आहेत, ज्यात निम्न-स्तरीय प्रोटोकॉल बदलांसाठी कोअर EIPs समाविष्ट आहेत जे एकमत वर परिणाम करतात आणि ज्यांना [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) सारख्या नेटवर्क अपग्रेडची आवश्यकता असते, आणि [EIP-20](https://eips.ethereum.org/EIPS/eip-20) व [EIP-721](https://eips.ethereum.org/EIPS/eip-721) सारख्या ॲप्लिकेशन मानकांसाठी ERCs समाविष्ट आहेत.
+
+प्रत्येक नेटवर्क अपग्रेडमध्ये EIPs चा एक संच असतो जो नेटवर्कवरील प्रत्येक [इथेरियम क्लायंट](/learn/#clients-and-nodes) द्वारे लागू करणे आवश्यक असते. याचा अर्थ असा की Ethereum Mainnet वरील इतर क्लायंट्ससोबत एकमत मध्ये राहण्यासाठी, क्लायंट डेव्हलपर्सना हे सुनिश्चित करणे आवश्यक आहे की त्यांनी सर्व आवश्यक EIPs लागू केले आहेत.
+
+बदलांसाठी तांत्रिक तपशील प्रदान करण्यासोबतच, EIPs हे एकक आहे ज्याच्याभोवती Ethereum मध्ये शासन होते: कोणीही एक प्रस्ताव देण्यास स्वतंत्र आहे आणि नंतर समुदायातील विविध भागधारक ते मानक म्हणून स्वीकारले जावे की नेटवर्क अपग्रेडमध्ये समाविष्ट केले जावे हे ठरवण्यासाठी चर्चा करतील. कारण नॉन-कोअर EIPs सर्व ॲप्लिकेशन्सद्वारे स्वीकारले जाणे आवश्यक नाही (उदाहरणार्थ, EIP-20 लागू न करणारे फंजिबल टोकन तयार करणे शक्य आहे), परंतु कोअर EIPs मोठ्या प्रमाणावर स्वीकारले जाणे आवश्यक आहे (कारण सर्व नोड्सना एकाच नेटवर्कचा भाग राहण्यासाठी अपग्रेड करणे आवश्यक आहे), त्यामुळे कोअर EIPs ला नॉन-कोअर EIPs पेक्षा समुदायामध्ये व्यापक एकमत आवश्यक आहे.
+
+## EIPs चा इतिहास {#history-of-eips}
+
+[इथेरियम सुधारणा प्रस्ताव (EIPs) GitHub रेपॉजिटरी](https://github.com/ethereum/EIPs) ऑक्टोबर 2015 मध्ये तयार करण्यात आली होती. EIP प्रक्रिया [Bitcoin Improvement Proposals (BIPs)](https://github.com/bitcoin/bips) प्रक्रियेवर आधारित आहे, जी स्वतः [Python Enhancement Proposals (PEPs)](https://www.python.org/dev/peps/) प्रक्रियेवर आधारित आहे.
+
+EIP संपादकांना तांत्रिक सुदृढता, फॉर्मेटिंग समस्या आणि स्पेलिंग, व्याकरण आणि कोड शैली सुधारण्यासाठी EIPs चे पुनरावलोकन करण्याचे काम सोपवले आहे. मार्टिन बेक्झे, विटालिक बुटेरिन, गॅव्हिन वूड, आणि इतर काही जण 2015 ते 2016 च्या अखेरीस मूळ EIP संपादक होते.
+
+सध्याचे EIP संपादक आहेत
+
+- Alex Beregszaszi (@axic)
+- Gavin John (@Pandapip1)
+- Greg Colvin (@gcolvin)
+- Matt Garnett (@lightclient)
+- Sam Wilson (@SamWilsn)
+
+मानद EIP संपादक आहेत
+
+- Casey Detrio (@cdetrio)
+- Hudson Jameson (@Souptacular)
+- Martin Becze (@wanderer)
+- Micah Zoltu (@MicahZoltu)
+- Nick Johnson (@arachnid)
+- Nick Savers (@nicksavers)
+- Vitalik Buterin (@vbuterin)
+
+तुम्हाला EIP संपादक व्हायचे असल्यास, कृपया [EIP-5069](https://eips.ethereum.org/EIPS/eip-5069) तपासा.
+
+EIP संपादक ठरवतात की एखादा प्रस्ताव EIP बनण्यासाठी कधी तयार आहे, आणि EIP लेखकांना त्यांचे प्रस्ताव पुढे नेण्यात मदत करतात. [Ethereum Cat Herders](https://www.ethereumcatherders.com/) EIP संपादक आणि समुदाय यांच्यात बैठका आयोजित करण्यास मदत करतात (पहा [EIPIP](https://github.com/ethereum-cat-herders/EIPIP)).
+
+चार्टसह संपूर्ण मानकीकरण प्रक्रिया [EIP-1](https://eips.ethereum.org/EIPS/eip-1) मध्ये वर्णन केलेली आहे.
+
+## अधिक जाणून घ्या {#learn-more}
+
+तुम्हाला EIPs बद्दल अधिक वाचण्यात स्वारस्य असल्यास, [EIPs वेबसाइट](https://eips.ethereum.org/) आणि [EIP-1](https://eips.ethereum.org/EIPS/eip-1) तपासा. येथे काही उपयुक्त लिंक्स आहेत:
+
+- [प्रत्येक इथेरियम सुधारणा प्रस्तावाची यादी](https://eips.ethereum.org/all)
+- [सर्व EIP प्रकारांचे वर्णन](https://eips.ethereum.org/EIPS/eip-1#eip-types)
+- [सर्व EIP स्थितींचे वर्णन](https://eips.ethereum.org/EIPS/eip-1#eip-process)
+
+### समुदाय शिक्षण प्रकल्प {#community-projects}
+
+- [PEEPanEIP](https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F) — _PEEPanEIP ही एक शैक्षणिक व्हिडिओ मालिका आहे जी इथेरियम सुधारणा प्रस्ताव (EIPs) आणि आगामी अपग्रेडच्या मुख्य वैशिष्ट्यांवर चर्चा करते._
+- [EIPs.wtf](https://www.eips.wtf/) — _EIPs.wtf इथेरियम सुधारणा प्रस्तावांसाठी (EIPs) अतिरिक्त माहिती प्रदान करते, ज्यात त्यांची स्थिती, अंमलबजावणी तपशील, संबंधित पुल रिक्वेस्ट्स आणि समुदायाचा अभिप्राय समाविष्ट आहे._
+- [EIP.Fun](https://eipfun.substack.com/) — _EIP.Fun इथेरियम सुधारणा प्रस्तावां (EIPs) वरील ताज्या बातम्या, EIP बैठकींवरील अपडेट्स आणि बरेच काही प्रदान करते._
+- [EIPs Insight](https://eipsinsight.com/) — _EIPs Insight हे विविध स्त्रोतांकडून गोळा केलेल्या माहितीनुसार इथेरियम सुधारणा प्रस्ताव (EIPs) प्रक्रिया आणि आकडेवारीच्या स्थितीचे प्रतिनिधित्व आहे._
+
+## सहभाग घ्या {#participate}
+
+कोणीही EIP तयार करू शकतो. प्रस्ताव सादर करण्यापूर्वी, व्यक्तीने [EIP-1](https://eips.ethereum.org/EIPS/eip-1) वाचले पाहिजे, ज्यात EIP प्रक्रिया आणि EIP कसे लिहावे हे सांगितले आहे, आणि [Ethereum Magicians](https://ethereum-magicians.org/) वर अभिप्राय मागितला पाहिजे, जिथे मसुदा सादर करण्यापूर्वी प्रस्तावांवर प्रथम समुदायासोबत चर्चा केली जाते.
+
+## संदर्भ {#references}
+
+<cite class="citation">
+
+पृष्ठ सामग्री हडसन जेमसन यांच्या [Ethereum Protocol Development Governance and Network Upgrade Coordination](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) मधून अंशतः प्रदान केलेली आहे.
+
+</cite>
diff --git a/public/content/translations/mr/energy-consumption/index.md b/public/content/translations/mr/energy-consumption/index.md
new file mode 100644
index 00000000000..2fdc698e59b
--- /dev/null
+++ b/public/content/translations/mr/energy-consumption/index.md
@@ -0,0 +1,86 @@
+---
+title: "इथरियम ऊर्जेचा वापर"
+description: "इथरियमचा ऊर्जा वापर समजून घेण्यासाठी तुम्हाला आवश्यक असलेली मूलभूत माहिती."
+lang: mr
+---
+
+# Ethereum चा ऊर्जा खर्च {#proof-of-stake-energy}
+
+इथरियम एक हिरवा ब्लॉकचेन आहे. Ethereum ची [प्रूफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos) सहमती यंत्रणा [नेटवर्क सुरक्षित करण्यासाठी ऊर्जेऐवजी](/developers/docs/consensus-mechanisms/pow) ETH वापरते. संपूर्ण जागतिक नेटवर्कवर Ethereum चा ऊर्जेचा वापर अंदाजे [~0.0026 TWh/yr](https://carbon-ratings.com/eth-report-2022) आहे.
+
+Ethereum साठी ऊर्जेच्या वापराचा अंदाज [CCRI (Crypto Carbon Ratings Institute)](https://carbon-ratings.com) च्या अभ्यासातून आला आहे. त्यांनी Ethereum नेटवर्कच्या विजेच्या वापराचे आणि कार्बन फूटप्रिंटचे बॉटम-अप अंदाज तयार केले ([अहवाल पहा](https://carbon-ratings.com/eth-report-2022)). त्यांनी विविध हार्डवेअर आणि क्लायंट सॉफ्टवेअर कॉन्फिगरेशनसह वेगवेगळ्या नोड्सचा वीज वापर मोजला. नेटवर्कच्या वार्षिक वीज वापरासाठी अंदाजित **2,601 MWh** (0.0026 TWh) हे प्रादेशिक-विशिष्ट कार्बन तीव्रता घटक लागू केल्यावर **870 टन CO2e** च्या वार्षिक कार्बन उत्सर्जनाशी संबंधित आहे. जेव्हा नोड्स नेटवर्कमध्ये प्रवेश करतात आणि बाहेर पडतात तेव्हा हे मूल्य बदलते - आपण [Cambridge Blockchain network Sustainability Index](https://ccaf.io/cbnsi/ethereum) द्वारे 7-दिवसांच्या सरासरी अंदाजाचा वापर करून याचा मागोवा ठेवू शकता (लक्षात घ्या की ते त्यांच्या अंदाजांसाठी थोडी वेगळी पद्धत वापरतात - तपशील त्यांच्या साइटवर उपलब्ध आहेत).
+
+इथरियमच्या उर्जेच्या वापराचे संदर्भ देण्यासाठी, आम्ही काही इतर उत्पादने आणि उद्योगांसाठी वार्षिक अंदाजांची तुलना करू शकतो. हे आम्हाला Ethereum साठी अंदाज जास्त आहे की कमी हे चांगल्या प्रकारे समजून घेण्यास मदत करते.
+
+<EnergyConsumptionChart />
+
+वरील चार्ट इतर अनेक उत्पादने आणि उद्योगांच्या तुलनेत इथरियमसाठी TWh/yr मध्ये अंदाजे ऊर्जा वापर प्रदर्शित करतो. प्रदान केलेले अंदाज सार्वजनिकरीत्या उपलब्ध माहितीवरून घेतलेले आहेत, जुलै 2023 मध्ये ऍक्सेस केले गेले आहेत, खालील तक्त्यामध्ये उपलब्ध स्त्रोतांच्या लिंकसह.
+
+|                      | वार्षिक ऊर्जा वापर (TWh) | PoS Ethereum शी तुलना |                                                                                       स्रोत                                                                                      |
+| :------------------- | :-----------------------------------------: | :-------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
+| जागतिक डेटा केंद्रे  |                     १९०                     |        73,000x        |                                    [स्रोत](https://www.iea.org/commentaries/data-centres-and-energy-from-global-headlines-to-local-headaches)                                    |
+| बिटकॉइन              |                     149                     |        53,000x        |                                                                 [स्रोत](https://ccaf.io/cbnsi/cbeci/comparisons)                                                                 |
+| गोल्ड माइनिंग        |                     131                     |        50,000x        |                                                                 [स्रोत](https://ccaf.io/cbnsi/cbeci/comparisons)                                                                 |
+| यूएसए मध्ये गेमिंग\* |                      34                     |        13,000x        |                 [स्रोत](https://www.researchgate.net/publication/336909520_Toward_Greener_Gaming_Estimating_National_Energy_Use_and_Energy_Efficiency_Potential)                 |
+| PoW इथरियम           |                      21                     |         8,100x        |                                                                     [स्रोत](https://ccaf.io/cbnsi/ethereum/1)                                                                    |
+| Google               |                      19                     |         7,300x        |                                           [स्रोत](https://www.gstatic.com/gumdrop/sustainability/google-2022-environmental-report.pdf)                                           |
+| Netflix              |            ०.४५७            |          176x         | [स्रोत](https://assets.ctfassets.net/4cd45et68cgf/7B2bKCqkXDfHLadrjrNWD8/e44583e5b288bdf61e8bf3d7f8562884/2021_US_EN_Netflix_EnvironmentalSocialGovernanceReport-2021_Final.pdf) |
+| PayPal               |             0.26            |          100x         |                                  [स्रोत](https://s202.q4cdn.com/805890769/files/doc_downloads/global-impact/CDP_Climate_Change_PayPal-\(1\).pdf)                                 |
+| एअर बीएनबी           |             0.02            |           8x          |                              [स्रोत](https://s26.q4cdn.com/656283129/files/doc_downloads/governance_doc_updated/Airbnb-ESG-Factsheet-\(Final\).pdf)                              |
+| **PoS इथरियम**       |          **०.००२६**         |         **1x**        |                                                                [स्रोत](https://carbon-ratings.com/eth-report-2022)                                                               |
+
+\*पीसी, लॅपटॉप आणि गेमिंग कन्सोल सारख्या अंतिम वापरकर्त्याच्या डिव्हाइसेसचा समावेश आहे.
+
+ऊर्जेच्या वापरासाठी अचूक अंदाज मिळवणे क्लिष्ट आहे, विशेषत: जे मोजले जात आहे ते एक जटिल पुरवठा साखळी किंवा उपयोजन तपशील आहे जे त्याच्या कार्यक्षमतेवर परिणाम करतात. उदाहरणार्थ, Netflix आणि Google साठी ऊर्जेच्या वापराचे अंदाज यावर अवलंबून बदलतात की त्यात केवळ त्यांच्या सिस्टीमची देखरेख करण्यासाठी आणि वापरकर्त्यांना सामग्री वितरीत करण्यासाठी वापरलेल्या ऊर्जेचा समावेश आहे (_थेट खर्च_) की त्यात सामग्री तयार करणे, कॉर्पोरेट कार्यालये चालवणे, जाहिरात करणे इत्यादीसाठी आवश्यक खर्चाचा समावेश आहे (_अप्रत्यक्ष खर्च_). अप्रत्यक्ष खर्चामध्ये टीव्ही, संगणक आणि मोबाईल यांसारख्या अंतिम वापरकर्त्याच्या उपकरणांवर सामग्री वापरण्यासाठी आवश्यक ऊर्जा देखील समाविष्ट असू शकते.
+
+वरील अंदाज परिपूर्ण तुलना नाहीत. अप्रत्यक्ष खर्चाची रक्कम स्त्रोतानुसार बदलते आणि क्वचितच अंतिम-वापरकर्ता उपकरणांमधून ऊर्जा समाविष्ट करते. प्रत्येक अंतर्निहित स्त्रोतामध्ये काय मोजले जात आहे याबद्दल अधिक तपशील समाविष्ट आहेत.
+
+वरील सारणी आणि तक्त्यामध्ये बिटकॉइन आणि कामाचा पुरावा इथरियमशी तुलना देखील समाविष्ट आहे. हे लक्षात घेणे महत्त्वाचे आहे की कार्य-प्रूफ नेटवर्क्सचा ऊर्जा वापर स्थिर नाही आणि दिवसेंदिवस बदलतो. स्त्रोतांदरम्यान अंदाज देखील मोठ्या प्रमाणात बदलू शकतात. हा विषय केवळ वापरलेल्या ऊर्जेच्या प्रमाणावरच नव्हे, तर त्या ऊर्जेचे स्रोत आणि संबंधित नैतिकतेवरही सूक्ष्म [चर्चेला](https://www.coindesk.com/business/2020/05/19/the-last-word-on-bitcoins-energy-consumption/) सुरुवात करतो. ऊर्जेचा वापर पर्यावरणीय पायाच्या ठशांशी अचूकपणे मॅप करणे आवश्यक नाही कारण भिन्न प्रकल्प वेगवेगळ्या ऊर्जा स्त्रोतांचा वापर करू शकतात, ज्यामध्ये नूतनीकरणक्षमतेच्या कमी किंवा जास्त प्रमाणात समावेश आहे. उदाहरणार्थ, [Cambridge Bitcoin Electricity Consumption Index](https://ccaf.io/cbnsi/cbeci/comparisons) सूचित करतो की Bitcoin नेटवर्कची मागणी सैद्धांतिकदृष्ट्या गॅस फ्लेअरिंग किंवा विजेद्वारे समर्थित असू शकते जी अन्यथा ट्रान्समिशन आणि डिस्ट्रिब्युशनमध्ये वाया गेली असती. इथरियमचा टिकाऊपणाचा मार्ग म्हणजे नेटवर्कचा ऊर्जा-भुकेलेला भाग हिरव्या पर्यायाने बदलणे.
+
+आपण [Cambridge Blockchain Network Sustainability Index साइट](https://ccaf.io/cbnsi/ethereum) वर अनेक उद्योगांसाठी ऊर्जा वापर आणि कार्बन उत्सर्जन अंदाज ब्राउझ करू शकता.
+
+## प्रति-व्यवहार अंदाज {#per-transaction-estimates}
+
+अनेक लेख ब्लॉकचेनसाठी "प्रति-व्यवहार" ऊर्जा खर्चाचा अंदाज लावतात. हे दिशाभूल करणारे असू शकते कारण ब्लॉक प्रस्तावित करण्यासाठी आणि त्याचे प्रमाणीकरण करण्यासाठी लागणारी ऊर्जा त्यातील व्यवहारांच्या संख्येपेक्षा स्वतंत्र असते. ऊर्जा खर्चाच्या प्रति-व्यवहार युनिटचा अर्थ असा होतो की कमी व्यवहारांमुळे ऊर्जा खर्च कमी होईल आणि उलट, जे तसे नाही. तसेच, ब्लॉकचेनचे व्यवहार थ्रूपुट कसे परिभाषित केले जाते याबद्दल प्रति-व्यवहार अंदाज अतिशय संवेदनशील असतात आणि मूल्य मोठे किंवा लहान वाटण्यासाठी या व्याख्येमध्ये बदल केला जाऊ शकतो.
+
+उदाहरणार्थ, Ethereum वर, व्यवहार थ्रुपुट केवळ बेस लेयरचाच नाही - तर तो त्याच्या सर्व "[लेयर 2](/layer-2/)" रोलअपच्या व्यवहार थ्रुपुटची बेरीज देखील आहे. लेयर 2 सामान्यत: गणनेमध्ये समाविष्ट केले जात नाहीत, परंतु सिक्वेन्सर (लहान) द्वारे वापरल्या जाणाऱ्या अतिरिक्त उर्जेचा आणि त्यांनी प्रक्रिया केलेल्या (मोठ्या) व्यवहारांची संख्या लक्षात घेतल्यास प्रति-व्यवहार अंदाज मोठ्या प्रमाणात कमी होईल. हे एक कारण आहे की प्लॅटफॉर्मवर प्रति-व्यवहार ऊर्जा वापराची तुलना दिशाभूल करणारी असू शकते.
+
+## Ethereum चे कार्बन कर्ज {#carbon-debt}
+
+इथरियमचा उर्जा खर्च खूप कमी आहे, परंतु हे नेहमीच होत नाही. इथरियमने मूळतः प्रूफ-ऑफ-वर्कचा वापर केला ज्याचा सध्याच्या प्रूफ-ऑफ-स्टेक यंत्रणेपेक्षा पर्यावरणीय खर्च जास्त होता.
+
+अगदी सुरुवातीपासूनच, इथरियमने प्रूफ-ऑफ-स्टेक आधारित एकमत यंत्रणा कार्यान्वित करण्याची योजना आखली, परंतु सुरक्षितता आणि विकेंद्रीकरणाचा त्याग न करता असे केल्याने अनेक वर्षे केंद्रित संशोधन आणि विकास झाला. त्यामुळे, नेटवर्क सुरू करण्यासाठी कामाचा पुरावा यंत्रणा वापरण्यात आली. कामाच्या पुराव्यासाठी खाण कामगारांनी त्यांचे संगणकीय हार्डवेअर मूल्य मोजण्यासाठी, प्रक्रियेत ऊर्जा खर्च करणे आवश्यक आहे.
+
+![द मर्जच्या आधी आणि नंतरच्या Ethereum च्या ऊर्जेच्या वापराची तुलना; डावीकडे आयफेल टॉवर (330 मीटर उंच) द मर्ज पूर्वीच्या उच्च ऊर्जा वापराचे प्रतीक आहे आणि उजवीकडे 4 सेमी उंच छोटी लेगो आकृती द मर्ज नंतरच्या ऊर्जा वापरामध्ये झालेल्या नाट्यमय घटीचे प्रतिनिधित्व करते](energy_consumption_pre_post_merge.png)
+
+CCRI चा अंदाज आहे की द मर्जने Ethereum चा वार्षिक वीज वापर **99.988%** पेक्षा जास्त कमी केला आहे. त्याचप्रमाणे, Ethereum चा कार्बन फूटप्रिंट अंदाजे **99.992%** ने कमी झाला (11,016,000 वरून 870 टन CO2e पर्यंत). या दृष्टीकोनातून सांगायचे तर, उत्सर्जनातील घट म्हणजे आयफेल टॉवरच्या उंचीवरून लहान प्लास्टिकच्या खेळण्यांच्या आकृतीपर्यंत जाण्यासारखे आहे, जसे की वरील आकृतीमध्ये स्पष्ट केले आहे. परिणामी, नेटवर्क सुरक्षित करण्याचा पर्यावरणीय खर्च खूपच कमी झाला आहे. त्याच वेळी, नेटवर्कची सुरक्षा सुधारली असल्याचे मानले जाते.
+
+## एक ग्रीन ॲप्लिकेशन लेयर {#green-applications}
+
+Ethereum चा ऊर्जेचा वापर खूप कमी असला तरी, Ethereum वर एक भरीव, वाढणारा आणि अत्यंत सक्रिय [**रिजनरेटिव्ह फायनान्स (ReFi)**](/refi/) समुदाय तयार होत आहे. ReFi ऍप्लिकेशन्स आर्थिक ऍप्लिकेशन्स तयार करण्यासाठी DeFi घटकांचा वापर करतात ज्यात सकारात्मक बाह्य गोष्टींचा पर्यावरणाला फायदा होतो. ReFi हे एका व्यापक ["solarpunk"](https://en.wikipedia.org/wiki/Solarpunk) चळवळीचा भाग आहे जे Ethereum शी जवळून संरेखित आहे आणि तांत्रिक प्रगती व पर्यावरण संवर्धन यांची सांगड घालण्याचे उद्दिष्ट ठेवते. इथरियमचे विकेंद्रित, परवानगीहीन आणि संमिश्र स्वरूप हे ReFi आणि सोलरपंक समुदायांसाठी आदर्श आधार स्तर बनवते.
+
+[Gitcoin](https://gitcoin.co) सारखे Web3 नेटिव्ह सार्वजनिक वस्तू निधीकरण प्लॅटफॉर्म Ethereum च्या ॲप्लिकेशन लेयरवर पर्यावरण-जागरूक निर्मितीला उत्तेजन देण्यासाठी क्लायमेट राउंड चालवतात. या उपक्रमांच्या (आणि इतर, उदा., [DeSci](/desci/)) विकासाद्वारे, Ethereum एक पर्यावरणीय आणि सामाजिक दृष्ट्या निव्वळ-सकारात्मक तंत्रज्ञान बनत आहे.
+
+<Alert variant="update">
+<AlertEmoji text=":evergreen_tree:" />
+<AlertContent>
+<AlertDescription>
+  जर तुम्हाला वाटत असेल की हे पृष्ठ अधिक अचूक केले जाऊ शकते, तर कृपया समस्या किंवा PR करा. या पृष्ठावरील आकडेवारी सार्वजनिकरित्या उपलब्ध डेटावर आधारित अंदाजे आहेत - ते अधिकृत विधान किंवा ethereum.org टीम किंवा Ethereum फाउंडेशनचे वचन दर्शवत नाहीत.
+</AlertDescription>
+</AlertContent>
+</Alert>
+
+## पुढील वाचन {#further-reading}
+
+- [Cambridge Blockchain Network Sustainability Index](https://ccaf.io/cbnsi/ethereum)
+- [प्रूफ-ऑफ-वर्क ब्लॉकचेनवरील व्हाईट हाऊसचा अहवाल](https://web.archive.org/web/20221109005700/https://www.whitehouse.gov/wp-content/uploads/2022/09/09-2022-Crypto-Assets-and-Climate-Report.pdf)
+- [Ethereum उत्सर्जन: एक बॉटम-अप अंदाज](https://kylemcdonald.github.io/ethereum-emissions/) - _Kyle McDonald_
+- [Ethereum ऊर्जा वापर निर्देशांक](https://digiconomist.net/ethereum-energy-consumption/) - _Digiconomist_
+- [ETHMerge.com](https://ethmerge.com/) - _[@InsideTheSim](https://twitter.com/InsideTheSim)_
+- [द मर्ज - Ethereum नेटवर्कच्या वीज वापरावरील आणि कार्बन फूटप्रिंटवरील परिणाम](https://carbon-ratings.com/eth-report-2022) - _CCRI_
+- [Ethereum चा ऊर्जा वापर](https://mirror.xyz/jmcook.eth/ODpCLtO4Kq7SCVFbU4He8o8kXs418ZZDTj0lpYlZkR8)
+
+## संबंधित विषय {#related-topics}
+
+- [द बीकन चेन](/roadmap/beacon-chain)
+- [द मर्ज](/roadmap/merge/)
diff --git a/public/content/translations/mr/eth/supply/index.md b/public/content/translations/mr/eth/supply/index.md
new file mode 100644
index 00000000000..76c44e93462
--- /dev/null
+++ b/public/content/translations/mr/eth/supply/index.md
@@ -0,0 +1,80 @@
+---
+title: "ETH पुरवठा आणि निर्मिती समजून घेणे"
+description: "ETH पुरवठा आणि निर्मितीसाठी एक नवशिक्यांसाठी सोपे मार्गदर्शक, ज्यामध्ये EIPs, PoS, आणि EIP-1559 सारख्या मुख्य संकल्पनांचा समावेश आहे."
+lang: mr
+---
+
+# ETH पुरवठा आणि निर्मिती {#eth-supply-and-issuance}
+
+## पूर्वतयारी {#prerequisites}
+
+हा लेख कोणत्याही पूर्वज्ञानाशिवाय नवशिक्यांसाठी लिहिला आहे. तथापि, हा विषय पूर्णपणे समजून घेण्यासाठी, [Ethereum सुधारणा प्रस्ताव (EIPs)](/eips/#introduction-to-ethereum-improvement-proposals), [प्रूफ-ऑफ-वर्क (PoW)](/developers/docs/consensus-mechanisms/pow/), [प्रूफ-ऑफ-स्टेक (PoS)](/developers/docs/consensus-mechanisms/pos/), आणि [लंडन अपग्रेड](/ethereum-forks/#london) यांसारख्या संकल्पनांची मूलभूत माहिती असणे उपयुक्त आहे.
+
+## आज किती ETH टोकन आहेत? {#current-eth-supply}
+
+ETH चा एकूण पुरवठा डायनॅमिक आहे आणि दोन मुख्य घटकांमुळे तो सतत बदलत असतो:
+
+1. **प्रूफ-ऑफ-स्टेक (PoS) निर्मिती**: नेटवर्क सुरक्षित करणाऱ्या व्हॅलिडेटर्सना बक्षीस म्हणून नवीन ETH तयार केले जातात
+2. **EIP-1559 बर्निंग**: व्यवहाराच्या शुल्काचा एक भाग कायमस्वरूपी चलनातून काढून टाकला जातो
+
+तुम्ही सध्याचा पुरवठा आणि हे बदल [अल्ट्रासाउंड मनी](https://ultrasound.money) सारख्या प्लॅटफॉर्मवर रिअल-टाइममध्ये ट्रॅक करू शकता.
+
+Ethereum चा पुरवठा आणि निर्मिती हे नेटवर्कचे आरोग्य आणि भविष्य समजून घेण्यासाठी आवश्यक मेट्रिक्स आहेत. पण ETH निर्मितीचा नेमका अर्थ काय? चला ते सविस्तरपणे पाहूया.
+
+## ETH पुरवठा आणि निर्मिती का महत्त्वाची आहे {#why-eth-supply-matters}
+
+पारंपरिक वित्तात, केंद्रीय बँका पैशाच्या पुरवठ्यावर नियंत्रण ठेवतात, आणि अनेकदा अर्थव्यवस्थांना चालना देण्यासाठी अधिक चलन छापतात. दुसरीकडे, Ethereum त्याच्या कोडद्वारे शासित पारदर्शक आणि अंदाजित प्रणालीवर चालते. किती ETH अस्तित्वात आहेत आणि नवीन ETH किती वेगाने जारी केले जातात हे जाणून घेतल्याने मदत होते:
+
+- **विश्वास निर्माण करणे**: Ethereum समुदाय थेट ब्लॉकचेनवरून पुरवठा आणि निर्मिती डेटाची पडताळणी करू शकतो.
+- **मूल्य समजून घेणे**: निर्मिती आणि ETH बर्न दरांमधील संबंध ETH च्या चलनवाढ किंवा चलनघटीवर परिणाम करतो, ज्यामुळे कालांतराने त्याच्या मूल्यावर प्रभाव पडतो.
+- **नेटवर्क आरोग्याचा मागोवा घेणे**: निर्मिती आणि बर्न दरांमधील बदल नेटवर्कची क्रियाशीलता आणि सुरक्षितता दर्शवतात.
+
+## ETH निर्मिती म्हणजे काय? {#eth-issuance}
+
+ETH निर्मिती म्हणजे Ethereum नेटवर्क सुरक्षित करणाऱ्या व्हॅलिडेटर्सना बक्षीस म्हणून नवीन ETH तयार करण्याची प्रक्रिया. हे एकूण पुरवठ्यापेक्षा वेगळे आहे, जो चलनात असलेल्या ETH ची एकूण रक्कम आहे.
+
+### सोप्या भाषेत सांगायचे तर:
+
+- **निर्मिती** नेटवर्कमध्ये नवीन ETH जोडते.
+- **बर्निंग** (EIP-1559 द्वारे सादर केलेले) व्यवहाराच्या शुल्काचा एक भाग नष्ट करून नेटवर्कमधून ETH काढून टाकते.
+
+या दोन शक्ती ठरवतात की Ethereum चा पुरवठा कालांतराने वाढतो (चलनवाढीचा) की कमी होतो (चलनघटीचा).
+
+## आजचा ETH पुरवठा आणि निर्मिती {#eth-supply-today}
+
+Ethereum च्या प्रूफ-ऑफ-स्टेक (PoS) प्रणालीने त्याच्या पूर्वीच्या प्रूफ-ऑफ-वर्क (PoW) मॉडेलच्या तुलनेत ETH निर्मितीमध्ये मोठ्या प्रमाणात घट केली आहे. व्हॅलिडेटर्स—जे नेटवर्क सुरक्षित करण्यासाठी ETH लॉक करतात—बक्षीस म्हणून ETH कमावतात. तुम्ही सध्याचा निर्मिती दर [अल्ट्रासाउंड मनी](https://ultrasound.money) वर पाहू शकता.
+
+तथापि, ही संख्या डायनॅमिक आहे. EIP-1559 मुळे, जेव्हा नेटवर्क क्रियाशीलता जास्त असते, तेव्हा ETH बर्न दर निर्मितीपेक्षा जास्त होऊ शकतात, ज्यामुळे चलनघटीचा परिणाम होतो. उदाहरणार्थ, NFT लाँच किंवा DeFi क्रियाशीलतेसारख्या उच्च मागणीच्या काळात, जारी केल्यापेक्षा जास्त ETH बर्न केले जाऊ शकतात.
+
+### ETH पुरवठा आणि निर्मितीचा मागोवा घेण्यासाठी साधने:
+
+- [अल्ट्रासाउंड मनी](https://ultrasound.money) - ETH पुरवठा, निर्मिती आणि बर्न दरांचे रिअल-टाइम ट्रॅकिंग
+- [इथरस्कॅन](https://etherscan.io) - पुरवठा मेट्रिक्ससह ब्लॉक एक्सप्लोरर
+
+## भविष्यातील ETH पुरवठा आणि निर्मितीवर परिणाम करणारे घटक {#future-eth-supply}
+
+Ethereum चा भविष्यातील पुरवठा निश्चित नाही—तो अनेक व्हेरिएबल्सवर अवलंबून आहे:
+
+1. **स्टेकिंगमधील सहभाग**:
+   - नेटवर्कमध्ये अधिक व्हॅलिडेटर्स सामील होणे म्हणजे अधिक ETH बक्षिसे वितरित केली जातात.
+   - कमी व्हॅलिडेटर्स सहभागी झाल्यास निर्मिती कमी होऊ शकते.
+   - [स्टेकिंग](/staking/) बद्दल अधिक जाणून घ्या.
+
+2. **नेटवर्क क्रियाशीलता**:
+   - उच्च व्यवहारांचे प्रमाण अधिक ETH बर्न होण्यास कारणीभूत ठरते, जे संभाव्यतः निर्मितीची भरपाई करते किंवा त्याहून अधिक होते.
+   - [गॅस शुल्क](/developers/docs/gas/) आणि ते बर्निंगवर कसा परिणाम करतात याबद्दल वाचा.
+
+3. **प्रोटोकॉल अपग्रेड**:
+   - Ethereum च्या कोडमधील भविष्यातील बदल स्टेकिंग बक्षिसे किंवा बर्निंग यंत्रणा समायोजित करू शकतात, ज्यामुळे पुरवठ्याच्या डायनॅमिक्सला आणखी आकार मिळेल.
+   - [Ethereum रोडमॅप](/roadmap/) सह अपडेटेड रहा.
+
+## रिकॅप: ETH पुरवठा, निर्मिती आणि पुढे काय {#recap}
+
+ETH पुरवठा आणि निर्मितीबद्दल तुम्हाला काय माहित असणे आवश्यक आहे याचा एक छोटा सारांश येथे आहे:
+
+- **ETH पुरवठा**: डायनॅमिक आणि सतत बदलणारा, [अल्ट्रासाउंड मनी](https://ultrasound.money) सारख्या साधनांद्वारे रिअल-टाइममध्ये ट्रॅक करण्यायोग्य
+- **PoS अंतर्गत निर्मिती**: PoW च्या तुलनेत लक्षणीयरीत्या कमी, बक्षिसे व्हॅलिडेटर्सना मिळतात. [अल्ट्रासाउंड मनी](https://ultrasound.money) वर सध्याचे दर पहा
+- **EIP-1559 ची भूमिका**: उच्च क्रियाशीलतेच्या काळात ETH बर्निंग नेटवर्कला चलनघटीचे बनवू शकते
+- **भविष्यातील ट्रेंड**: स्टेकिंगमधील सहभाग, नेटवर्कची मागणी आणि प्रोटोकॉल अपडेट्स हे सर्व ETH पुरवठ्याला आकार देतील
+
+ETH निर्मिती समजून घेणे Ethereum चे मूल्य आणि चलनघटीची, विकेंद्रित मालमत्ता म्हणून त्याची क्षमता स्पष्ट करण्यास मदत करते. द मर्जने ETH पुरवठ्यावर कसा परिणाम केला याबद्दल अधिक तपशीलवार माहितीसाठी, आमचे [तपशीलवार विश्लेषण](/roadmap/merge/issuance/) पहा. ETH च्या भविष्याबद्दल उत्सुक आहात? [अल्ट्रासाउंड मनी](https://ultrasound.money) सारख्या साधनांसह अधिक खोलवर जा किंवा आमचे [स्टेकिंग मार्गदर्शक](/staking/) एक्सप्लोर करा.
\ No newline at end of file
diff --git a/public/content/translations/mr/ethereum-forks/index.md b/public/content/translations/mr/ethereum-forks/index.md
new file mode 100644
index 00000000000..dcad49f8a90
--- /dev/null
+++ b/public/content/translations/mr/ethereum-forks/index.md
@@ -0,0 +1,663 @@
+---
+title: "सर्व Ethereum फोर्क्सची टाइमलाइन (2014 ते आतापर्यंत)"
+description: "प्रमुख टप्पे, रिलीझ आणि फोर्क्ससह Ethereum ब्लॉकचेनचा इतिहास."
+lang: mr
+sidebarDepth: 1
+---
+
+# सर्व Ethereum फोर्क्सची टाइमलाइन (2014 ते आतापर्यंत) {#the-history-of-ethereum}
+
+Ethereum ब्लॉकचेनचे सर्व प्रमुख टप्पे, फोर्क्स आणि अपडेट्सची टाइमलाइन.
+
+<ExpandableCard title="फोर्क्स म्हणजे काय?" contentPreview="Ethereum प्रोटोकॉलच्या नियमांमध्ये बदल, ज्यात नियोजित तांत्रिक अपग्रेडचा समावेश असतो.">
+
+जेव्हा नेटवर्कमध्ये मोठे तांत्रिक अपग्रेड किंवा बदल करणे आवश्यक असते तेव्हा फोर्क्स होतात - ते सामान्यतः [Ethereum सुधारणा प्रस्ताव (EIPs)](/eips/) मधून येतात आणि प्रोटोकॉलचे "नियम" बदलतात.
+
+पारंपारिक, केंद्रीय-नियंत्रित सॉफ्टवेअरमध्ये अपग्रेडची आवश्यकता असते, तेव्हा कंपनी अंतिम-वापरकर्त्यासाठी फक्त एक नवीन आवृत्ती प्रकाशित करते. ब्लॉकचेन्स वेगळ्या पद्धतीने काम करतात कारण तेथे कोणतीही केंद्रीय मालकी नाही. [Ethereum क्लायंट्सनी](/developers/docs/nodes-and-clients/) नवीन फोर्क नियम लागू करण्यासाठी त्यांचे सॉफ्टवेअर अपडेट करणे आवश्यक आहे. याशिवाय ब्लॉक निर्माते (प्रूफ-ऑफ-वर्क जगात मायनर्स, प्रूफ-ऑफ-स्टेक जगात व्हॅलिडेटर्स) आणि नोड्सनी नवीन नियमांनुसार ब्लॉक्स तयार केले पाहिजेत आणि प्रमाणित केले पाहिजेत. [कन्सेंसस यंत्रणांबद्दल अधिक](/developers/docs/consensus-mechanisms/)
+
+हे नियम बदल नेटवर्कमध्ये तात्पुरते विभाजन निर्माण करू शकतात. नवीन ब्लॉक्स नवीन नियमांनुसार किंवा जुन्या नियमांनुसार तयार केले जाऊ शकतात. फोर्क्सवर सहसा आधीच सहमती दर्शविली जाते जेणेकरून क्लायंट एकमताने बदल स्वीकारतील आणि अपग्रेडसह फोर्क मुख्य चेन बनेल. तथापि, क्वचित प्रसंगी, फोर्क्सवरील मतभेद नेटवर्कमध्ये कायमचे विभाजन घडवून आणू शकतात – विशेषतः <a href="#dao-fork">DAO फोर्क</a> सह Ethereum क्लासिकची निर्मिती.
+</ExpandableCard>
+
+<ExpandableCard title="काही अपग्रेड्सना अनेक नावे का असतात?" contentPreview="अपग्रेडच्या नावांची एक विशिष्ट पद्धत असते.">
+
+Ethereum च्या मुळाशी असलेले सॉफ्टवेअर दोन भागांनी बनलेले आहे, जे [एक्सिक्यूशन लेअर](/glossary/#execution-layer) आणि [कन्सेंसस लेअर](/glossary/#consensus-layer) म्हणून ओळखले जातात.
+
+**एक्सिक्यूशन अपग्रेडचे नावकरण**
+
+2021 पासून, **एक्सिक्यूशन लेअर** मधील अपग्रेड्सना कालक्रमानुसार [मागील Devcon स्थानांच्या](https://devcon.org/en/past-events/) शहरांच्या नावांवरून नाव दिले जाते:
+
+| अपग्रेडचे नाव | Devcon वर्ष | Devcon क्रमांक | अपग्रेडची तारीख |
+| ------------- | ----------- | -------------- | --------------- |
+| बर्लिन        | 2014        | 0              | 15 एप्रिल, 2021 |
+| लंडन          | 2015        | I              | 5 ऑगस्ट, 2021   |
+| शांघाय        | 2016        | II             | 12 एप्रिल, 2023 |
+| कँकून         | 2017        | III            | 13 मार्च, 2024  |
+| **प्राग**     | 2018        | IV             | TBD - पुढील     |
+| _ओसाका_       | 2019        | V              | TBD             |
+| _बोगोटा_      | 2022        | VI             | TBD             |
+| _बँगकॉक_      | 2024        | VII            | TBD             |
+
+**कन्सेंसस अपग्रेड नामकरण**
+
+[बीकन चेन](/glossary/#beacon-chain) लाँच झाल्यापासून, **कन्सेंसस लेअर** मधील अपग्रेड्सना वर्णानुक्रमे पुढे जाणाऱ्या अक्षरांनी सुरू होणाऱ्या खगोलीय ताऱ्यांवरून नावे दिली जातात:
+
+| अपग्रेडचे नाव                                                 | अपग्रेडची तारीख  |
+| ------------------------------------------------------------- | ---------------- |
+| बीकन चेन जेनेसिस                                              | 1 डिसेंबर, 2020  |
+| [Altair](https://en.wikipedia.org/wiki/Altair)                | 27 ऑक्टोबर, 2021 |
+| [Bellatrix](https://en.wikipedia.org/wiki/Bellatrix)          | 6 सप्टेंबर, 2022 |
+| [Capella](https://en.wikipedia.org/wiki/Capella)              | 12 एप्रिल, 2023  |
+| [Deneb](https://en.wikipedia.org/wiki/Deneb)                  | 13 मार्च, 2024   |
+| [**Electra**](https://en.wikipedia.org/wiki/Electra_\(star\)) | TBD - पुढील      |
+| [_Fulu_](https://en.wikipedia.org/wiki/Fulu_\(star\))         | TBD              |
+
+**एकत्रित नामकरण**
+
+एक्सिक्यूशन आणि कन्सेंसस अपग्रेड्स सुरुवातीला वेगवेगळ्या वेळी लागू केले गेले होते, परंतु 2022 मध्ये [द मर्ज](/roadmap/merge/) नंतर ते एकाच वेळी तैनात केले गेले आहेत. त्यामुळे, या अपग्रेड्सचा संदर्भ एकाच जोडलेल्या शब्दाचा वापर करून सोपा करण्यासाठी बोलचालीतील शब्द उदयास आले आहेत. याची सुरुवात _Shanghai-Capella_ अपग्रेडने झाली, ज्याला सामान्यतः "**Shapella**" म्हटले जाते आणि _Cancun-Deneb_ (**Dencun**) आणि _Prague-Electra_ (**Pectra**) अपग्रेडसह ते पुढे चालू आहे.
+
+| एक्सिक्यूशन अपग्रेड | कन्सेंसस अपग्रेड | लहान नाव   |
+| ------------------- | ---------------- | ---------- |
+| शांघाय              | Capella          | "Shapella" |
+| कँकून               | Deneb            | "Dencun"   |
+| प्राग               | Electra          | "Pectra"   |
+| ओसाका               | Fulu             | "Fusaka"   |
+</ExpandableCard>
+
+काही विशेष महत्त्वाच्या मागील अपग्रेड्सबद्दल थेट माहितीवर जा: [द बीकन चेन](/roadmap/beacon-chain/); [द मर्ज](/roadmap/merge/); आणि [EIP-1559](#london)
+
+भविष्यातील प्रोटोकॉल अपग्रेड शोधत आहात? [Ethereum रोडमॅपवर आगामी अपग्रेड्सबद्दल जाणून घ्या](/roadmap/).
+
+<Divider />
+
+## 2025 {#2025}
+
+### फुलू-ओसाका ("फुसाका") {#fusaka}
+
+<NetworkUpgradeSummary name="fusaka" />
+
+[फुसाकाबद्दल अधिक](/roadmap/fusaka/)
+
+### प्राग-इलेक्ट्रा ("पेक्ट्रा") {#pectra}
+
+<NetworkUpgradeSummary name="pectra" />
+
+प्राग-इलेक्ट्रा ("पेक्ट्रा") अपग्रेडमध्ये Ethereum प्रोटोकॉलमध्ये अनेक सुधारणांचा समावेश होता, ज्याचा उद्देश सर्व वापरकर्ते, लेअर 2 नेटवर्क्स, स्टेकर्स आणि नोड ऑपरेटर्ससाठी अनुभव वाढवणे हा होता.
+
+स्टेकिंगला कंपाऊंडिंग व्हॅलिडेटर खात्यांसह एक अपग्रेड मिळाला, आणि एक्सिक्यूशन विथड्रॉवल ॲड्रेस वापरून स्टेक केलेल्या फंडांवर सुधारित नियंत्रण मिळाले. EIP-7251 ने एका व्हॅलिडेटरसाठी कमाल प्रभावी शिल्लक 2048 पर्यंत वाढवली, ज्यामुळे स्टेकर्ससाठी भांडवली कार्यक्षमता सुधारली. EIP-7002 ने एका एक्सिक्यूशन खात्याला व्हॅलिडेटर क्रिया सुरक्षितपणे ट्रिगर करण्यास सक्षम केले, ज्यात बाहेर पडणे, किंवा निधीचा काही भाग काढून घेणे समाविष्ट आहे, ज्यामुळे ETH स्टेकर्सचा अनुभव सुधारला, आणि नोड ऑपरेटर्ससाठी जबाबदारी मजबूत करण्यास मदत झाली.
+
+अपग्रेडच्या इतर भागांमध्ये सामान्य वापरकर्त्यांसाठी अनुभव सुधारण्यावर लक्ष केंद्रित केले गेले. EIP-7702 ने सामान्य नॉन-स्मार्ट-कॉन्ट्रॅक्ट खाते ([EOA](/glossary/#eoa)) ला स्मार्ट कॉन्ट्रॅक्टसारखा कोड एक्सिक्यूट करण्याची क्षमता आणली. याने पारंपारिक Ethereum खात्यांसाठी अमर्याद नवीन कार्यक्षमता अनलॉक केली, जसे की व्यवहार बॅचिंग, गॅस प्रायोजकत्व, पर्यायी प्रमाणीकरण, प्रोग्राम करण्यायोग्य खर्च नियंत्रणे, खाते पुनर्प्राप्ती यंत्रणा आणि बरेच काही.
+
+<ExpandableCard title="पेक्ट्रा EIPs" contentPreview="या अपग्रेडमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+चांगला वापरकर्ता अनुभव:
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-7702">EIP-7702</a> - <em>EOA खाते कोड सेट करा</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-7691">EIP-7691</a> - <em>ब्लॉब थ्रुपुट वाढ</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-7623">EIP-7623</a> - <em>कॉलडेटा खर्च वाढवा</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-7840">EIP-7840</a> - <em>EL कॉन्फिगरेशन फाइल्समध्ये ब्लॉब शेड्यूल जोडा</em></li>
+</ul>
+
+उत्तम स्टेकिंग अनुभव:
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-7251">EIP-7251</a> - <em><code>MAX_EFFECTIVE_BALANCE</code> वाढवा</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-7002">EIP-7002</a> - <em>एक्सिक्यूशन लेअर ट्रिगर करण्यायोग्य एक्सिट्स</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-7685">EIP-7685</a> - <em>सामान्य उद्देश एक्सिक्यूशन लेअर विनंत्या</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-6110">EIP-6110</a> - <em>चेनवर व्हॅलिडेटर ठेवी पुरवा</em></li>
+</ul>
+
+प्रोटोकॉल कार्यक्षमता आणि सुरक्षा सुधारणा:
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-2537">EIP-2537</a> - <em>BLS12-381 कर्व ऑपरेशन्ससाठी प्रीकंपाइल</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-2935">EIP-2935</a> - <em>स्टेटमध्ये ऐतिहासिक ब्लॉक हॅशेस सेव्ह करा</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-7549">EIP-7549</a> - <em>समिती इंडेक्स ॲटेस्टेशनच्या बाहेर हलवा</em></li>
+</ul>
+</ExpandableCard>
+
+- [Pectra.wtf](https://pectra.wtf)
+- [पेक्ट्रा स्टेकिंगचा अनुभव कसा वाढवेल](https://www.kiln.fi/post/next-ethereum-upgrade-how-pectra-will-enhance-the-staking-experience)
+- [इलेक्ट्रा अपग्रेड स्पेसिफिकेशन्स वाचा](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/)
+- [प्राग-इलेक्ट्रा ("पेक्ट्रा") FAQ](/roadmap/pectra/)
+
+<Divider />
+
+## 2024 {#2024}
+
+### कँकून-डेनेब ("डेनकून") {#dencun}
+
+<NetworkUpgradeSummary name="dencun" />
+
+#### कँकून सारांश {#cancun-summary}
+
+कँकून अपग्रेडमध्ये डेनेब कन्सेंसस अपग्रेड्ससह स्केलेबिलिटी सुधारण्याच्या उद्देशाने Ethereum च्या _एक्सिक्यूशन_ मध्ये सुधारणांचा संच आहे.
+
+विशेष म्हणजे यामध्ये EIP-4844 समाविष्ट आहे, जे **प्रोटो-डँकशार्डिंग** म्हणून ओळखले जाते, ज्यामुळे लेअर 2 रोलअपसाठी डेटा स्टोरेजचा खर्च लक्षणीयरीत्या कमी होतो. हे डेटा "ब्लॉब्स" च्या परिचयाने साधले जाते जे रोलअप्सना थोड्या कालावधीसाठी मेननेटवर डेटा पोस्ट करण्यास सक्षम करते. यामुळे लेअर 2 रोलअप्सच्या वापरकर्त्यांसाठी व्यवहाराचे शुल्क लक्षणीयरीत्या कमी होते.
+
+<ExpandableCard title="कॅनकुन EIPs" contentPreview="या अपग्रेडमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-1153">EIP-1153</a> - <em>तात्पुरते स्टोरेज ऑपकोड्स</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-4788">EIP-4788</a> - <em>EVM मधील बीकन ब्लॉक रूट</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-4844">EIP-4844</a> - <em>शार्ड ब्लॉब व्यवहार (प्रोटो-डँकशार्डिंग)</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-5656">EIP-5656</a> - <em><code>MCOPY</code> - मेमरी कॉपी करण्याची सूचना</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-6780">EIP-6780</a> - <em><code>SELFDESTRUCT</code> फक्त त्याच व्यवहारात</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-7516">EIP-7516</a> - <em><code>BLOBBASEFEE</code> ऑपकोड</em></li>
+</ul>
+</ExpandableCard>
+
+- [लेअर 2 रोलअप्स](/layer-2/)
+- [प्रोटो-डँकशार्डिंग](/roadmap/scaling/#proto-danksharding)
+- [डँकशार्डिंग](/roadmap/danksharding/)
+- [कँकून अपग्रेड स्पेसिफिकेशन वाचा](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md)
+
+#### डेनेब सारांश {#deneb-summary}
+
+डेनेब अपग्रेडमध्ये Ethereum च्या _कन्सेंसस_ मध्ये स्केलेबिलिटी सुधारण्याच्या उद्देशाने सुधारणांचा संच आहे. हे अपग्रेड प्रोटो-डँकशार्डिंग (EIP-4844) सक्षम करण्यासाठी कँकून एक्सिक्यूशन अपग्रेड्ससोबत येते, तसेच बीकन चेनमध्ये इतर सुधारणांसह येते.
+
+आधीपासून तयार केलेले स्वाक्षरी केलेले "स्वैच्छिक एक्सिट संदेश" यापुढे कालबाह्य होत नाहीत, त्यामुळे तृतीय-पक्ष नोड ऑपरेटरकडे आपले फंड स्टेक करणाऱ्या वापरकर्त्यांना अधिक नियंत्रण मिळते. या स्वाक्षरी केलेल्या एक्सिट संदेशासह, स्टेकर्स नोड ऑपरेशन डेलीगेट करू शकतात आणि कोणाकडूनही परवानगी न मागता कधीही सुरक्षितपणे बाहेर पडण्याची आणि त्यांचे फंड काढून घेण्याची क्षमता राखू शकतात.
+
+EIP-7514 व्हॅलिडेटर्स नेटवर्कमध्ये सामील होण्याच्या "चर्न" दराला प्रति इपॉक आठ (8) पर्यंत मर्यादित करून ETH च्या इश्युअन्सला कडक करते. ETH इश्युअन्स एकूण स्टेक केलेल्या ETH च्या प्रमाणात असल्याने, सामील होणाऱ्या व्हॅलिडेटर्सची संख्या मर्यादित केल्याने नवीन जारी केलेल्या ETH च्या _वाढीचा दर_ मर्यादित होतो, तसेच नोड ऑपरेटर्ससाठी हार्डवेअर आवश्यकता कमी होतात, ज्यामुळे विकेंद्रीकरणाला मदत होते.
+
+<ExpandableCard title="डेनेब EIPs" contentPreview="या अपग्रेडमध्ये समाविष्ट अधिकृत सुधारणा">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-4788">EIP-4788</a> - <em>EVM मधील बीकन ब्लॉक रूट</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-4844">EIP-4844</a> - <em>शार्ड ब्लॉब व्यवहार</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-7044">EIP-7044</a> - <em>कायमस्वरूपी वैध स्वाक्षरी केलेले स्वैच्छिक एक्सिट्स</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-7045">EIP-7045</a> - <em>कमाल ॲटेस्टेशन इन्क्लूजन स्लॉट वाढवा</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-7514">EIP-7514</a> - <em>कमाल इपॉक चर्न मर्यादा जोडा</em></li>
+</ul>
+</ExpandableCard>
+
+- [डेनेब अपग्रेड स्पेसिफिकेशन्स वाचा](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/)
+- [कँकून-डेनेब ("डेनकून") FAQ](/roadmap/dencun/)
+
+<Divider />
+
+## 2023 {#2023}
+
+### शांघाय-कॅपेलॅ ("शेपेलॅ") {#shapella}
+
+<NetworkUpgradeSummary name="shapella" />
+
+#### शांघाय सारांश {#shanghai-summary}
+
+शांघाय अपग्रेडने एक्सिक्यूशन लेअरवर स्टेकिंग विथड्रॉवल आणले. कॅपेलॅ अपग्रेडसोबत, यामुळे ब्लॉक्सना विथड्रॉवल ऑपरेशन्स स्वीकारण्याची परवानगी मिळाली, ज्यामुळे स्टेकर्सना त्यांचे ETH बीकन चेनवरून एक्सिक्यूशन लेअरवर काढता येतात.
+
+<ExpandableCard title="शांघाय EIPs" contentPreview="या अपग्रेडमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-3651">EIP-3651</a> – <em><code>COINBASE</code> ॲड्रेस वॉर्म सुरू करते</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-3855">EIP-3855</a> – <em>नवीन <code>PUSH0</code> सूचना</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-3860">EIP-3860</a> – <em>initcode मर्यादित करा आणि मोजा</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-4895">EIP-4895</a> – <em>बीकन चेन पुश विथड्रॉवल्स ऑपरेशन्स म्हणून</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-6049">EIP-6049</a> - <em><code>SELFDESTRUCT</code> डेप्रिकेट करा</em></li>
+</ul>
+</ExpandableCard>
+
+- [शांघाय अपग्रेड स्पेसिफिकेशन वाचा](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md)
+
+#### कॅपेलॅ सारांश {#capella-summary}
+
+कॅपेलॅ अपग्रेड हा कन्सेंसस लेअर (बीकन चेन) चा तिसरा मोठा अपग्रेड होता आणि त्याने स्टेकिंग विथड्रॉवल सक्षम केले. कॅपेलॅ एक्सिक्यूशन लेअर अपग्रेड, शांघायसोबत समकालिकपणे झाले आणि त्याने स्टेकिंग विथड्रॉवल कार्यक्षमता सक्षम केली.
+
+या कन्सेंसस लेअर अपग्रेडमुळे ज्या स्टेकर्सनी त्यांच्या सुरुवातीच्या ठेवीसह विथड्रॉवल क्रेडेन्शियल दिले नव्हते त्यांना ते देण्याची क्षमता मिळाली, ज्यामुळे विथड्रॉवल सक्षम झाले.
+
+अपग्रेडने स्वयंचलित खाते स्वीपिंग कार्यक्षमता देखील प्रदान केली, जी कोणत्याही उपलब्ध रिवॉर्ड पेमेंट्स किंवा पूर्ण विथड्रॉवलसाठी व्हॅलिडेटर खात्यांवर सतत प्रक्रिया करते.
+
+- [स्टेकिंग विथड्रॉवल्सबद्दल अधिक](/staking/withdrawals/).
+- [कॅपेलॅ अपग्रेड स्पेसिफिकेशन्स वाचा](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/)
+
+<Divider />
+
+## 2022 {#2022}
+
+### पॅरिस (द मर्ज) {#paris}
+
+<NetworkUpgradeSummary name="paris" />
+
+#### सारांश {#paris-summary}
+
+पॅरिस अपग्रेड 58750000000000000000000 च्या [टर्मिनल टोटल डिफिकल्टी](/glossary/#terminal-total-difficulty) पार केल्यावर प्रूफ-ऑफ-वर्क ब्लॉकचेनद्वारे ट्रिगर झाले. हे 15 सप्टेंबर 2022 रोजी ब्लॉक 15537393 वर झाले, ज्यामुळे पुढील ब्लॉकवर पॅरिस अपग्रेड ट्रिगर झाला. पॅरिस हे [द मर्ज](/roadmap/merge/) संक्रमण होते - त्याचे प्रमुख वैशिष्ट्य म्हणजे [प्रूफ-ऑफ-वर्क](/developers/docs/consensus-mechanisms/pow) मायनिंग अल्गोरिदम आणि संबंधित कन्सेंसस लॉजिक बंद करणे आणि त्याऐवजी [प्रूफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos) चालू करणे होते. पॅरिस स्वतः [एक्सिक्यूशन क्लायंट्स](/developers/docs/nodes-and-clients/#execution-clients) (कन्सेंसस लेअरवरील बेलॅट्रिक्सच्या समतुल्य) साठी एक अपग्रेड होता ज्यामुळे त्यांना त्यांच्या कनेक्ट केलेल्या [कन्सेंसस क्लायंट्स](/developers/docs/nodes-and-clients/#consensus-clients) कडून सूचना घेता आली. यासाठी अंतर्गत API पद्धतींचा एक नवीन संच आवश्यक होता, जो एकत्रितपणे [इंजिन API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) म्हणून ओळखला जातो, जो सक्रिय करणे आवश्यक होते. [होमस्टेड](#homestead) नंतर Ethereum च्या इतिहासातील हा कदाचित सर्वात महत्त्वपूर्ण अपग्रेड होता!
+
+- [पॅरिस अपग्रेड स्पेसिफिकेशन वाचा](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md)
+
+<ExpandableCard title="पॅरिस EIPs" contentPreview="या अपग्रेडमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-3675">EIP-3675</a> – <em>कन्सेंसस प्रूफ-ऑफ-स्टेकवर अपग्रेड करा</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-4399">EIP-4399</a> – <em>DIFFICULTY ऑपकोडला PREVRANDAO ने बदला</em></li>
+</ul>
+</ExpandableCard>
+
+---
+
+### बेलॅट्रिक्स {#bellatrix}
+
+<NetworkUpgradeSummary name="bellatrix" />
+
+#### बेलॅट्रिक्स सारांश {#bellatrix-summary}
+
+बेलॅट्रिक्स अपग्रेड हा [बीकन चेन](/roadmap/beacon-chain) साठी दुसरा नियोजित अपग्रेड होता, जो चेनला [द मर्ज](/roadmap/merge/) साठी तयार करत होता. हे निष्क्रियता आणि स्लॅशेबल गुन्ह्यांसाठी व्हॅलिडेटर दंडांना त्यांच्या पूर्ण मूल्यांपर्यंत आणते. बेलॅट्रिक्समध्ये द मर्जसाठी चेन तयार करण्यासाठी आणि शेवटच्या प्रूफ-ऑफ-वर्क ब्लॉकपासून पहिल्या प्रूफ-ऑफ-स्टेक ब्लॉकपर्यंतच्या संक्रमणासाठी फोर्क निवड नियमांमध्ये एक अपडेट देखील समाविष्ट आहे. यात कन्सेंसस क्लायंट्सना 58750000000000000000000 च्या [टर्मिनल टोटल डिफिकल्टी](/glossary/#terminal-total-difficulty) बद्दल जागरूक करणे समाविष्ट आहे.
+
+- [बेलॅट्रिक्स अपग्रेड स्पेसिफिकेशन वाचा](https://github.com/ethereum/consensus-specs/tree/dev/specs/bellatrix)
+
+---
+
+### ग्रे ग्लेशियर {#gray-glacier}
+
+<NetworkUpgradeSummary name="grayGlacier" />
+
+#### ग्रे ग्लेशियर सारांश {#gray-glacier-summary}
+
+ग्रे ग्लेशियर नेटवर्क अपग्रेडने [डिफिकल्टी बॉम्ब](/glossary/#difficulty-bomb) तीन महिन्यांनी पुढे ढकलला. या अपग्रेडमध्ये सादर केलेला हा एकमेव बदल आहे आणि तो [ॲरो ग्लेशियर](#arrow-glacier) आणि [म्युर ग्लेशियर](#muir-glacier) अपग्रेड्ससारखाच आहे. असेच बदल [बायझँटियम](#byzantium), [कॉन्स्टँटिनोपल](#constantinople) आणि [लंडन](#london) नेटवर्क अपग्रेड्सवर केले गेले आहेत.
+
+- [EF ब्लॉग - ग्रे ग्लेशियर अपग्रेड घोषणा](https://blog.ethereum.org/2022/06/16/gray-glacier-announcement/)
+
+<ExpandableCard title="ग्रे ग्लेशियर EIPs" contentPreview="या अपग्रेडमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-5133">EIP-5133</a> – <em>डिफिकल्टी बॉम्ब सप्टेंबर 2022 पर्यंत पुढे ढकलते</em></li>
+</ul>
+</ExpandableCard>
+
+<Divider />
+
+## 2021 {#2021}
+
+### ॲरो ग्लेशियर {#arrow-glacier}
+
+<NetworkUpgradeSummary name="arrowGlacier" />
+
+#### ॲरो ग्लेशियर सारांश {#arrow-glacier-summary}
+
+ॲरो ग्लेशियर नेटवर्क अपग्रेडने [डिफिकल्टी बॉम्ब](/glossary/#difficulty-bomb) अनेक महिन्यांनी पुढे ढकलला. या अपग्रेडमध्ये सादर केलेला हा एकमेव बदल आहे आणि तो [म्युर ग्लेशियर](#muir-glacier) अपग्रेड्ससारखाच आहे. असेच बदल [बायझँटियम](#byzantium), [कॉन्स्टँटिनोपल](#constantinople) आणि [लंडन](#london) नेटवर्क अपग्रेड्सवर केले गेले आहेत.
+
+- [EF ब्लॉग - ॲरो ग्लेशियर अपग्रेड घोषणा](https://blog.ethereum.org/2021/11/10/arrow-glacier-announcement/)
+- [Ethereum कॅट हर्डर्स - Ethereum ॲरो ग्लेशियर अपग्रेड](https://medium.com/ethereum-cat-herders/ethereum-arrow-glacier-upgrade-e8d20fa4c002)
+
+<ExpandableCard title="ॲरो ग्लेशियर EIPs" contentPreview="या अपग्रेडमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-4345">EIP-4345</a> – <em>डिफिकल्टी बॉम्ब जून 2022 पर्यंत पुढे ढकलते</em></li>
+</ul>
+</ExpandableCard>
+
+---
+
+### अल्टेअर {#altair}
+
+<NetworkUpgradeSummary name="altair" />
+
+#### अल्टेअर सारांश {#altair-summary}
+
+अल्टेअर अपग्रेड हा [बीकन चेन](/roadmap/beacon-chain) साठी पहिला नियोजित अपग्रेड होता. त्याने "सिंक कमिटी" साठी समर्थन जोडले—लाइट क्लायंट्स सक्षम करणे, आणि द मर्जच्या दिशेने विकास प्रगती करत असताना व्हॅलिडेटर निष्क्रियता आणि स्लॅशिंग दंड वाढवले.
+
+- [अल्टेअर अपग्रेड स्पेसिफिकेशन वाचा](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair)
+
+#### <Emoji text=":tada:" size={1} className="me-2" />मजेदार तथ्य! {#altair-fun-fact}
+
+अल्टेअर हा पहिला मोठा नेटवर्क अपग्रेड होता ज्याची रोलआउट वेळ निश्चित होती. यापूर्वीचे प्रत्येक अपग्रेड प्रूफ-ऑफ-वर्क चेनवरील घोषित ब्लॉक क्रमांकावर आधारित होते, जिथे ब्लॉक वेळ बदलते. बीकन चेनला प्रूफ-ऑफ-वर्कसाठी सोडवण्याची आवश्यकता नाही, आणि त्याऐवजी वेळे-आधारित इपॉक प्रणालीवर काम करते ज्यात 32 बारा-सेकंदांचे "स्लॉट्स" असतात ज्यात व्हॅलिडेटर्स ब्लॉक्स प्रस्तावित करू शकतात. म्हणूनच आम्हाला नक्की माहित होते की आपण इपॉक 74,240 वर पोहोचू आणि अल्टेअर लाईव्ह होईल!
+
+- [ब्लॉक वेळ](/developers/docs/blocks/#block-time)
+
+---
+
+### लंडन {#london}
+
+<NetworkUpgradeSummary name="london" />
+
+#### लंडन सारांश {#london-summary}
+
+लंडन अपग्रेडने [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) सादर केले, ज्याने व्यवहार शुल्क बाजारात सुधारणा केली, तसेच गॅस रिफंड कसे हाताळले जातात आणि [आईस एज](/glossary/#ice-age) शेड्यूलमध्ये बदल केले.
+
+#### लंडन अपग्रेड / EIP-1559 काय होते? {#eip-1559}
+
+लंडन अपग्रेडपूर्वी, Ethereum मध्ये निश्चित-आकाराचे ब्लॉक्स होते. उच्च नेटवर्क मागणीच्या काळात, हे ब्लॉक्स पूर्ण क्षमतेने चालत होते. परिणामी, वापरकर्त्यांना अनेकदा ब्लॉकमध्ये समाविष्ट होण्यासाठी मागणी कमी होण्याची प्रतीक्षा करावी लागत असे, ज्यामुळे वापरकर्त्याचा अनुभव खराब होत असे. लंडन अपग्रेडने Ethereum मध्ये बदलत्या-आकाराचे ब्लॉक्स सादर केले.
+
+ऑगस्ट २०२१ च्या [लंडन अपग्रेड](/ethereum-forks/#london) सह Ethereum नेटवर्कवरील व्यवहार शुल्काची गणना करण्याची पद्धत बदलली. लंडन अपग्रेडपूर्वी, शुल्काची गणना `base` आणि `priority` शुल्क वेगळे न करता, खालीलप्रमाणे केली जात असे:
+
+समजा ॲलिसला बॉबला 1 ETH द्यावे लागले. व्यवहारात, गॅस मर्यादा २१,००० युनिट्स आहे, आणि गॅसची किंमत २०० gwei आहे.
+
+एकूण शुल्क असेल: `गॅस युनिट्स (मर्यादा) * प्रति युनिट गॅसची किंमत` म्हणजे `21,000 * 200 = 4,200,000 gwei` किंवा 0.0042 ETH
+
+लंडन अपग्रेडमध्ये [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) च्या अंमलबजावणीने व्यवहार शुल्क यंत्रणा अधिक गुंतागुंतीची केली, परंतु गॅस शुल्क अधिक अंदाजित केले, ज्यामुळे अधिक कार्यक्षम व्यवहार शुल्क बाजार निर्माण झाला. वापरकर्ते `maxFeePerGas` सह व्यवहार सादर करू शकतात, जे ते व्यवहारासाठी किती पैसे देण्यास इच्छुक आहेत याच्याशी संबंधित आहे, हे जाणून की ते गॅसच्या बाजारभावापेक्षा (`baseFeePerGas`) जास्त पैसे देणार नाहीत, आणि त्यांना अतिरिक्त रक्कम, त्यांच्या टीपमधून वजा करून, परत मिळेल.
+
+हा व्हिडिओ EIP-1559 आणि त्यामुळे होणारे फायदे स्पष्ट करतो: [EIP-1559 स्पष्टीकरण](https://www.youtube.com/watch?v=MGemhK9t44Q)
+
+- [तुम्ही एक डॅप डेव्हलपर आहात का? तुमच्या लायब्ररी आणि टूलिंग अपग्रेड करण्याचे सुनिश्चित करा.](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/london-ecosystem-readiness.md)
+- [Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2021/07/15/london-mainnet-announcement/)
+- [Ethereum कॅट हर्डरचे स्पष्टीकरण वाचा](https://medium.com/ethereum-cat-herders/london-upgrade-overview-8eccb0041b41)
+
+<ExpandableCard title="लंडन EIPs" contentPreview="या अपग्रेडमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-1559">EIP-1559</a> – <em>व्यवहार शुल्क बाजार सुधारतो</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-3198">EIP-3198</a> – <em>एका ब्लॉकमधून <code>BASEFEE</code> परत करतो</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-3529">EIP-3529</a> - <em>EVM ऑपरेशन्ससाठी गॅस रिफंड कमी करतो</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-3541">EIP-3541</a> - <em><code>0xEF</code> ने सुरू होणारे करार तैनात करण्यास प्रतिबंध करते</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-3554">EIP-3554</a> – <em>आईस एज डिसेंबर 2021 पर्यंत पुढे ढकलते</em></li>
+</ul>
+</ExpandableCard>
+
+---
+
+### बर्लिन {#berlin}
+
+<NetworkUpgradeSummary name="berlin" />
+
+#### बर्लिन सारांश {#berlin-summary}
+
+बर्लिन अपग्रेडने काही EVM क्रियांसाठी गॅस खर्च ऑप्टिमाइझ केला आणि अनेक व्यवहार प्रकारांसाठी समर्थन वाढवले.
+
+- [Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2021/03/08/ethereum-berlin-upgrade-announcement/)
+- [Ethereum कॅट हर्डरचे स्पष्टीकरण वाचा](https://medium.com/ethereum-cat-herders/the-berlin-upgrade-overview-2f7ad710eb80)
+
+<ExpandableCard title="बर्लिन EIPs" contentPreview="या अपग्रेडमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-2565">EIP-2565</a> – <em>ModExp गॅस खर्च कमी करतो</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-2718">EIP-2718</a> – <em>अनेक व्यवहार प्रकारांसाठी सोपे समर्थन सक्षम करते</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-2929">EIP-2929</a> – <em>स्टेट ॲक्सेस ऑपकोड्ससाठी गॅस खर्च वाढतो</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-2930">EIP-2930</a> – <em>पर्यायी ॲक्सेस याद्या जोडतो</em></li>
+</ul>
+</ExpandableCard>
+
+<Divider />
+
+## 2020 {#2020}
+
+### बीकन चेन जेनेसिस {#beacon-chain-genesis}
+
+<NetworkUpgradeSummary name="beaconChainGenesis" />
+
+#### बीकन चेन जेनेसिस सारांश {#beacon-chain-genesis-summary}
+
+[बीकन चेन](/roadmap/beacon-chain/) ला सुरक्षितपणे पाठवण्यासाठी 32 स्टेक केलेल्या ETH च्या 16384 ठेवींची आवश्यकता होती. हे २७ नोव्हेंबर रोजी घडले, आणि बीकन चेनने १ डिसेंबर २०२० रोजी ब्लॉक्स तयार करण्यास सुरुवात केली.
+
+[Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2020/11/27/eth2-quick-update-no-21/)
+
+<DocLink href="/roadmap/beacon-chain/">
+  बीकन चेन
+</DocLink>
+
+---
+
+### स्टेकिंग डिपॉझिट करार तैनात केला गेला {#staking-deposit-contract}
+
+<NetworkUpgradeSummary name="stakingDepositContractDeployed" />
+
+#### डिपॉझिट करार सारांश {#deposit-contract-summary}
+
+स्टेकिंग डिपॉझिट कराराने Ethereum इकोसिस्टममध्ये [स्टेकिंग](/glossary/#staking) सादर केले. जरी हा एक [मेननेट](/glossary/#mainnet) करार असला तरी, त्याचा [बीकन चेन](/roadmap/beacon-chain/) लाँच करण्याच्या टाइमलाइनवर थेट परिणाम झाला, जो एक महत्त्वाचा [Ethereum अपग्रेड](/roadmap/) आहे.
+
+[Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2020/11/04/eth2-quick-update-no-19/)
+
+<DocLink href="/staking/">
+  स्टेकिंग
+</DocLink>
+
+---
+
+### म्युर ग्लेशियर {#muir-glacier}
+
+<NetworkUpgradeSummary name="muirGlacier" />
+
+#### म्युर ग्लेशियर सारांश {#muir-glacier-summary}
+
+म्युर ग्लेशियर फोर्कने [डिफिकल्टी बॉम्ब](/glossary/#difficulty-bomb) ला विलंब लावला. [प्रूफ-ऑफ-वर्क](/developers/docs/consensus-mechanisms/pow/) कन्सेंसस यंत्रणेच्या ब्लॉक डिफिकल्टीमधील वाढीमुळे व्यवहार पाठवण्यासाठी आणि डॅप्स वापरण्यासाठी लागणारा प्रतीक्षा वेळ वाढवून Ethereum च्या वापरण्यायोग्यतेत घट होण्याची भीती होती.
+
+- [Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2019/12/23/ethereum-muir-glacier-upgrade-announcement/)
+- [Ethereum कॅट हर्डरचे स्पष्टीकरण वाचा](https://medium.com/ethereum-cat-herders/ethereum-muir-glacier-upgrade-89b8cea5a210)
+
+<ExpandableCard title="म्युर ग्लेशियर EIPs" contentPreview="या फोर्कमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-2384">EIP-2384</a> – <em>डिफिकल्टी बॉम्बला आणखी ४,०००,००० ब्लॉक्स किंवा ~६११ दिवसांसाठी विलंब लावते.</em></li>
+</ul>
+</ExpandableCard>
+
+<Divider />
+
+## 2019 {#2019}
+
+### इस्तंबूल {#istanbul}
+
+<NetworkUpgradeSummary name="istanbul" />
+
+#### इस्तंबूल सारांश {#istanbul-summary}
+
+इस्तंबूल फोर्क:
+
+- [EVM](/developers/docs/ethereum-stack/#ethereum-virtual-machine) मधील काही क्रियांसाठी [गॅस](/glossary/#gas) खर्च ऑप्टिमाइझ केला.
+- डिनायल-ऑफ-सर्व्हिस हल्ल्याची लवचिकता सुधारली.
+- SNARKs आणि STARKs वर आधारित [लेअर 2 स्केलिंग](/developers/docs/scaling/#layer-2-scaling) सोल्यूशन्स अधिक कार्यक्षम केले.
+- Ethereum आणि Zcash ला इंटरऑपरेट करण्याची परवानगी दिली.
+- करारांना अधिक सर्जनशील फंक्शन्स सादर करण्याची परवानगी दिली.
+
+[Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2019/11/20/ethereum-istanbul-upgrade-announcement/)
+
+<ExpandableCard title="इस्तंबूल EIPs" contentPreview="या फोर्कमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-152">EIP-152</a> – <em>Zcash सारख्या गोपनीयता-संरक्षक चलनासह Ethereum ला काम करण्याची परवानगी देते.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-1108">EIP-1108</a> – <em>[गॅस](/glossary/#gas) खर्च सुधारण्यासाठी स्वस्त क्रिप्टोग्राफी.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-1344">EIP-1344</a> – <em><code>CHAINID</code> [ऑपकोड](/developers/docs/ethereum-stack/#ethereum-virtual-machine) जोडून Ethereum ला रिप्ले हल्ल्यांपासून वाचवते.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-1884">EIP-1884</a> – <em>वापराच्या आधारावर ऑपकोड गॅस किंमती ऑप्टिमाइझ करणे.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-2028">EIP-2028</a> – <em>ब्लॉक्समध्ये अधिक डेटा सामावून घेण्यासाठी CallData चा खर्च कमी करते – [लेअर 2 स्केलिंग](/developers/docs/scaling/#layer-2-scaling) साठी चांगले आहे.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-2200">EIP-2200</a> – <em>इतर ऑपकोड गॅस किंमतीतील बदल.</em></li>
+</ul>
+</ExpandableCard>
+
+---
+
+### कॉन्स्टँटिनोपल {#constantinople}
+
+<NetworkUpgradeSummary name="constantinople" />
+
+#### कॉन्स्टँटिनोपल सारांश {#constantinople-summary}
+
+कॉन्स्टँटिनोपल फोर्क:
+
+- ब्लॉक [मायनिंग](/developers/docs/consensus-mechanisms/pow/mining/) रिवॉर्ड ३ वरून २ ETH पर्यंत कमी केले.
+- [प्रूफ-ऑफ-स्टेक लागू होण्यापूर्वी](#beacon-chain-genesis) ब्लॉकचेन फ्रीज होणार नाही याची खात्री केली.
+- [EVM](/developers/docs/ethereum-stack/#ethereum-virtual-machine) मधील काही क्रियांसाठी [गॅस](/glossary/#gas) खर्च ऑप्टिमाइझ केला.
+- अद्याप तयार न केलेल्या पत्त्यांशी संवाद साधण्याची क्षमता जोडली.
+
+[Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/)
+
+<ExpandableCard title="कॉन्स्टँटिनोपल EIPs" contentPreview="या फोर्कमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-145">EIP-145</a> – <em>काही ऑनचेन क्रियांचा खर्च ऑप्टिमाइझ करते.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-1014">EIP-1014</a> – <em>अद्याप तयार न झालेल्या पत्त्यांशी संवाद साधण्याची परवानगी देते.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-1052">EIP-1052</a> – <em>दुसऱ्या कराराच्या कोडचा हॅश पुनर्प्राप्त करण्यासाठी <code>EXTCODEHASH</code> सूचना सादर करते.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-1234">EIP-1234</a> – <em>प्रूफ-ऑफ-स्टेक होण्यापूर्वी ब्लॉकचेन फ्रीज होणार नाही याची खात्री करते आणि ब्लॉक रिवॉर्ड ३ वरून २ ETH पर्यंत कमी करते.</em></li>
+</ul>
+</ExpandableCard>
+
+<Divider />
+
+## 2017 {#2017}
+
+### बायझँटियम {#byzantium}
+
+<NetworkUpgradeSummary name="byzantium" />
+
+#### बायझँटियम सारांश {#byzantium-summary}
+
+बायझँटियम फोर्क:
+
+- ब्लॉक [मायनिंग](/developers/docs/consensus-mechanisms/pow/mining/) रिवॉर्ड ५ वरून ३ ETH पर्यंत कमी केले.
+- [डिफिकल्टी बॉम्ब](/glossary/#difficulty-bomb) एका वर्षाने पुढे ढकलला.
+- इतर करारांना नॉन-स्टेट-चेंजिंग कॉल्स करण्याची क्षमता जोडली.
+- [लेअर 2 स्केलिंग](/developers/docs/scaling/#layer-2-scaling) साठी विशिष्ट क्रिप्टोग्राफी पद्धती जोडल्या.
+
+[Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/)
+
+<ExpandableCard title="बायझँटियम EIPs" contentPreview="या फोर्कमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-140">EIP-140</a> – <em><code>REVERT</code> ऑपकोड जोडतो.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-658">EIP-658</a> – <em>यश किंवा अपयश दर्शविण्यासाठी व्यवहार पावतींमध्ये स्टेटस फील्ड जोडले गेले.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-196">EIP-196</a> – <em>[ZK-Snarks](/developers/docs/scaling/zk-rollups/) ला परवानगी देण्यासाठी इलिप्टिक कर्व आणि स्केलर गुणाकार जोडते.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-197">EIP-197</a> – <em>[ZK-Snarks](/developers/docs/scaling/zk-rollups/) ला परवानगी देण्यासाठी इलिप्टिक कर्व आणि स्केलर गुणाकार जोडते.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-198">EIP-198</a> – <em>RSA स्वाक्षरी पडताळणी सक्षम करते.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-211">EIP-211</a> – <em>व्हेरिएबल लांबीच्या रिटर्न मूल्यांसाठी समर्थन जोडते.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-214">EIP-214</a> – <em><code>STATICCALL</code> ऑपकोड जोडते, ज्यामुळे इतर करारांना नॉन-स्टेट-चेंजिंग कॉल्स करता येतात.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-100">EIP-100</a> – <em>डिफिकल्टी ॲडजस्टमेंट फॉर्म्युला बदलतो.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-649">EIP-649</a> – <em>[डिफिकल्टी बॉम्ब](/glossary/#difficulty-bomb) ला १ वर्षाने पुढे ढकलते आणि ब्लॉक रिवॉर्ड ५ वरून ३ ETH पर्यंत कमी करते.</em></li>
+</ul>
+</ExpandableCard>
+
+<Divider />
+
+## 2016 {#2016}
+
+### स्प्युरियस ड्रॅगन {#spurious-dragon}
+
+<NetworkUpgradeSummary name="spuriousDragon" />
+
+#### स्प्युरियस ड्रॅगन सारांश {#spurious-dragon-summary}
+
+स्प्युरियस ड्रॅगन फोर्क हा नेटवर्कवरील डिनायल ऑफ सर्व्हिस (DoS) हल्ल्यांना (सप्टेंबर/ऑक्टोबर २०१६) दुसरा प्रतिसाद होता, ज्यात समाविष्ट आहे:
+
+- नेटवर्कवरील भविष्यातील हल्ले रोखण्यासाठी ऑपकोड किंमती समायोजित करणे.
+- ब्लॉकचेन स्टेटचे “डिब्लोट” सक्षम करणे.
+- रिप्ले हल्ल्यापासून संरक्षण जोडणे.
+
+[Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/)
+
+<ExpandableCard title="स्प्युरियस ड्रॅगन EIPs" contentPreview="या फोर्कमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-155">EIP-155</a> – <em>एका Ethereum चेनवरील व्यवहारांना पर्यायी चेनवर पुन्हा प्रसारित होण्यापासून प्रतिबंधित करते, उदाहरणार्थ, टेस्टनेट व्यवहाराला मुख्य Ethereum चेनवर पुन्हा प्ले केले जाणे.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-160">EIP-160</a> – <em><code>EXP</code> ऑपकोडच्या किंमती समायोजित करते – संगणकीयदृष्ट्या महागड्या करार क्रियांमुळे नेटवर्कला धीमे करणे अधिक कठीण बनवते.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-161">EIP-161</a> – <em>DOS हल्ल्यांद्वारे जोडलेली रिकामी खाती काढून टाकण्याची परवानगी देते.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-170">EIP-170</a> – <em>ब्लॉकचेनवरील कराराच्या कमाल कोड आकाराला बदलते – २४५७६ बाइट्सपर्यंत.</em></li>
+</ul>
+</ExpandableCard>
+
+---
+
+### टँजेरिन व्हिसल {#tangerine-whistle}
+
+<NetworkUpgradeSummary name="tangerineWhistle" />
+
+#### टँजेरिन व्हिसल सारांश {#tangerine-whistle-summary}
+
+टँजेरिन व्हिसल फोर्क हा नेटवर्कवरील डिनायल ऑफ सर्व्हिस (DoS) हल्ल्यांना (सप्टेंबर/ऑक्टोबर २०१६) पहिला प्रतिसाद होता, ज्यात समाविष्ट आहे:
+
+- कमी किमतीच्या ऑपरेशन कोड्सशी संबंधित तातडीच्या नेटवर्क आरोग्य समस्यांचे निराकरण करणे.
+
+[Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2016/10/18/faq-upcoming-ethereum-hard-fork/)
+
+<ExpandableCard title="टँजेरिन व्हिसल EIPs" contentPreview="या फोर्कमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-150">EIP-150</a> – <em>स्पॅम हल्ल्यांमध्ये वापरल्या जाऊ शकणाऱ्या ऑपकोड्सचे गॅस खर्च वाढवते.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-158">EIP-158</a> – <em>Ethereum प्रोटोकॉलच्या पूर्वीच्या आवृत्त्यांमधील त्रुटींमुळे खूप कमी खर्चात स्टेटमध्ये टाकलेल्या मोठ्या संख्येने रिकाम्या खात्यांना काढून टाकून स्टेटचा आकार कमी करते.</em></li>
+</ul>
+</ExpandableCard>
+
+---
+
+### DAO फोर्क {#dao-fork}
+
+<NetworkUpgradeSummary name="daoFork" />
+
+#### DAO फोर्क सारांश {#dao-fork-summary}
+
+DAO फोर्क हा [2016 च्या DAO हल्ल्याला](https://www.coindesk.com/learn/understanding-the-dao-attack/) प्रतिसाद म्हणून होता, जिथे एका असुरक्षित [DAO](/glossary/#dao) करारातून एका हॅकमध्ये 3.6 दशलक्ष पेक्षा जास्त ETH काढून टाकले गेले. फोर्कने सदोष करारातून निधी एका [नवीन करारात](https://eth.blockscout.com/address/0xbf4ed7b27f1d666546e30d74d50d173d20bca754) हलवला ज्यामध्ये फक्त एकच कार्य होते: काढणे. ज्यांनी निधी गमावला होता ते त्यांच्या वॉलेटमधील प्रत्येक १०० DAO टोकन्ससाठी १ ETH काढू शकत होते.
+
+कृतीच्या या मार्गावर इथरियम समुदायाने मतदान केले. कोणताही ETH धारक [एका मतदान प्लॅटफॉर्मवर](https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/) व्यवहाराद्वारे मतदान करू शकत होता. काटा काढण्याचा निर्णय 85% पेक्षा जास्त मतांपर्यंत पोहोचला.
+
+काही मायनर्सनी फोर्क करण्यास नकार दिला कारण DAO घटना प्रोटोकॉलमधील दोष नव्हता. त्यांनी पुढे जाऊन [Ethereum Classic](https://ethereumclassic.org/) तयार केले.
+
+[Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2016/07/20/hard-fork-completed/)
+
+---
+
+### होमस्टेड {#homestead}
+
+<NetworkUpgradeSummary name="homestead" />
+
+#### होमस्टेड सारांश {#homestead-summary}
+
+होमस्टेड फोर्क जो भविष्याकडे पाहत होता. यात अनेक प्रोटोकॉल बदल आणि एक नेटवर्किंग बदल समाविष्ट होता ज्यामुळे Ethereum ला पुढील नेटवर्क अपग्रेड करण्याची क्षमता मिळाली.
+
+[Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2016/02/29/homestead-release/)
+
+<ExpandableCard title="होमस्टेड EIPs" contentPreview="या फोर्कमध्ये समाविष्ट अधिकृत सुधारणा.">
+
+<ul>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-2">EIP-2</a> – <em>करार निर्मिती प्रक्रियेत संपादन करते.</em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-7">EIP-7</a> – <em>नवीन ऑपकोड जोडते: <code>DELEGATECALL</code></em></li>
+  <li><a href="https://eips.ethereum.org/EIPS/eip-8">EIP-8</a> – <em>devp2p फॉरवर्ड कंपॅटिबिलिटी आवश्यकता सादर करते</em></li>
+</ul>
+</ExpandableCard>
+
+<Divider />
+
+## 2015 {#2015}
+
+### फ्रंटियर थॉईंग {#frontier-thawing}
+
+<NetworkUpgradeSummary name="frontierThawing" />
+
+#### फ्रंटियर थॉईंग सारांश {#frontier-thawing-summary}
+
+फ्रंटियर थॉईंग फोर्कने प्रति [ब्लॉक](/glossary/#block) ५,००० [गॅस](/glossary/#gas) मर्यादा उचलली आणि डिफॉल्ट गॅसची किंमत ५१ [gwei](/glossary/#gwei) वर सेट केली. यामुळे व्यवहारांना परवानगी मिळाली – व्यवहारांना २१,००० गॅसची आवश्यकता असते. [प्रूफ-ऑफ-स्टेक](/glossary/#pos) वर भविष्यातील हार्ड-फोर्क सुनिश्चित करण्यासाठी [डिफिकल्टी बॉम्ब](/glossary/#difficulty-bomb) सादर करण्यात आला.
+
+- [Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2015/08/04/the-thawing-frontier/)
+- [Ethereum प्रोटोकॉल अपडेट १ वाचा](https://blog.ethereum.org/2015/08/04/ethereum-protocol-update-1/)
+
+---
+
+### फ्रंटियर {#frontier}
+
+<NetworkUpgradeSummary name="frontier" />
+
+#### फ्रंटियर सारांश {#frontier-summary}
+
+फ्रंटियर हा Ethereum प्रकल्पाची एक थेट, पण मूलभूत अंमलबजावणी होती. हे यशस्वी ऑलिम्पिक चाचणी टप्प्यानंतर आले. हे तांत्रिक वापरकर्त्यांसाठी, विशेषतः डेव्हलपर्ससाठी होते. [ब्लॉक्स](/glossary/#block) ची [गॅस](/glossary/#gas) मर्यादा ५,००० होती. या ‘थॉईंग’ कालावधीमुळे मायनर्सना त्यांचे ऑपरेशन्स सुरू करण्याची आणि सुरुवातीच्या वापरकर्त्यांना ‘घाई’ न करता त्यांचे क्लायंट स्थापित करण्याची परवानगी मिळाली.
+
+[Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2015/07/22/frontier-is-coming-what-to-expect-and-how-to-prepare/)
+
+<Divider />
+
+## 2014 {#2014}
+
+### ईथर विक्री {#ether-sale}
+
+<NetworkUpgradeSummary name="etherSale" />
+
+ईथर अधिकृतपणे ४२ दिवसांसाठी विक्रीवर गेले. तुम्ही ते BTC ने खरेदी करू शकत होता.
+
+[Ethereum फाउंडेशनची घोषणा वाचा](https://blog.ethereum.org/2014/07/22/launching-the-ether-sale/)
+
+---
+
+### येलोपेपर प्रसिद्ध झाले {#yellowpaper}
+
+<NetworkUpgradeSummary name="yellowpaperRelease" />
+
+डॉ. गॅविन वुड यांनी लिहिलेले यलो पेपर, Ethereum प्रोटोकॉलची तांत्रिक व्याख्या आहे.
+
+[यलो पेपर पहा](https://github.com/ethereum/yellowpaper)
+
+<Divider />
+
+## 2013 {#2013}
+
+### व्हाइटपेपर प्रसिद्ध झाले {#whitepaper}
+
+<NetworkUpgradeSummary name="whitepaperRelease" />
+
+२०१३ मध्ये Ethereum चे संस्थापक विटालिक बुटेरिन यांनी प्रकाशित केलेला परिचयात्मक पेपर, २०१५ मध्ये प्रकल्पाच्या लाँचपूर्वी.
+
+<DocLink href="/whitepaper/">
+  व्हाइटपेपर
+</DocLink>
diff --git a/public/content/translations/mr/foundation/index.md b/public/content/translations/mr/foundation/index.md
new file mode 100644
index 00000000000..086cf9aa602
--- /dev/null
+++ b/public/content/translations/mr/foundation/index.md
@@ -0,0 +1,33 @@
+---
+title: "Ethereum फाउंडेशन"
+description: "Ethereum फाउंडेशन (EF) बद्दल जाणून घ्या, ही Ethereum आणि संबंधित तंत्रज्ञानाचे समर्थन करण्यासाठी समर्पित एक नान-प्राॅफिट संस्था आहे."
+hideEditButton: true
+lang: mr
+---
+
+# Ethereum फाउंडेशन {#ethereum-foundation}
+
+<Logo/>
+
+[Ethereum फाउंडेशन](http://ethereum.foundation/) (EF) ही एक नान-प्राॅफिट संस्था आहे जी Ethereum इकोसिस्टमला समर्थन देते. ती प्रोटोकॉल विकासासाठी निधी देते, इकोसिस्टम वाढवते आणि Ethereum साठी समर्थन करते.
+
+EF ही एक कंपनी नाही, किंवा एक पारंपरिक नान-प्राॅफिट सुद्धा नाही. ती Ethereum चे नियंत्रण किंवा नेतृत्व करत नाही, तसेच ती Ethereum-संबंधित तंत्रज्ञानाच्या महत्त्वपूर्ण विकासासाठी निधी देणारी एकमेव संस्था नाही. EF हा एका खूप मोठ्या [इकोसिस्टमचा](/community/) एक भाग आहे.
+
+## EF काय करते {#what-the-ef-does}
+
+- **प्रोटोकॉल विकास** – Ethereum च्या मूळ प्रोटोकॉलवर काम करणार्‍या टीम्सना समर्थन देणे, ज्यामध्ये क्लायंट विकास, संशोधन, अपग्रेड्स आणि [बग बाउंटी प्रोग्रामचा](/bug-bounty/) समावेश आहे.
+- **इकोसिस्टम निधी** – [इकोसिस्टम सपोर्ट प्रोग्राम](https://esp.ethereum.foundation/) द्वारे Ethereum वर तयार होत असलेल्या प्रकल्पांना अनुदान आणि समर्थन प्रदान करणे
+- **संशोधन** – क्रिप्टोग्राफी, सर्वसम्मती, स्केलिंग, गोपनीयता आणि सुरक्षा या क्षेत्रातील संशोधनासाठी निधी देणे
+
+## कार्यक्रम आणि उपक्रम {#programs-and-initiatives}
+
+- **[इकोसिस्टम सपोर्ट प्रोग्राम](https://esp.ethereum.foundation/)** – Ethereum वर तयार होत असलेल्या ओपन-सोर्स प्रकल्पांसाठी अनुदान आणि समर्थन
+- **[अकॅडमिक ग्रँट्स](https://esp.ethereum.foundation/academic-grants)** – Ethereum-संबंधित शैक्षणिक संशोधनास समर्थन देणे
+- **[Devcon](https://devcon.org/)** – Ethereum डेव्हलपर्स, संशोधक आणि बिल्डर्ससाठी वार्षिक परिषद
+- **[बग बाउंटी प्रोग्राम](/bug-bounty/)** – Ethereum प्रोटोकॉलमधील त्रुटी शोधण्यासाठी बक्षिसे
+
+## अधिक जाणून घ्या {#learn-more}
+
+- [ethereum.foundation](https://ethereum.foundation/) – अधिकृत EF वेबसाइट
+- [EF ब्लॉग](https://blog.ethereum.org/) – बातम्या आणि घोषणा
+- [इकोसिस्टम सपोर्ट प्रोग्राम](https://esp.ethereum.foundation/) – अनुदान आणि समर्थन
diff --git a/public/content/translations/mr/gaming/index.md b/public/content/translations/mr/gaming/index.md
new file mode 100644
index 00000000000..1cf551786dc
--- /dev/null
+++ b/public/content/translations/mr/gaming/index.md
@@ -0,0 +1,70 @@
+---
+title: "ऑनचेन गेमिंग"
+lang: mr
+template: use-cases
+image: /images/robot-help-bar.png
+sidebarDepth: 2
+summaryPoint1: "गेमचे नियम आणि स्थिती स्टुडिओच्या सर्व्हरद्वारे नव्हे, तर ब्लॉकचेनद्वारे लागू केले जाऊ शकतात"
+summaryPoint2: "कोणीही मॉड्स, बॉट्स किंवा पूर्णपणे नवीन गेम तयार करू शकतो जे समान ऑनचेन डेटामध्ये प्लग इन करतात"
+summaryPoint3: "Redstone सारखे हेतु-निर्मित L2s आणि MUD सारखे फ्रेमवर्क, रिअल-टाइम गेमप्लेला समर्थन देण्यासाठी खर्च कमी करतात"
+buttons:
+  - content: अधिक जाणून घ्या
+    toId: how-gaming-on-ethereum-works
+  - content: अ‍ॅप्स एक्सप्लोर करा
+    toId: popular-games-built-on-ethereum
+    isSecondary: false
+---
+
+## Ethereum वर गेमिंग कसे कार्य करते {#how-gaming-on-ethereum-works}
+
+Ethereum वरील गेमिंग विविध प्रकारांमध्ये येते, विशिष्ट वैशिष्ट्यांसाठी ब्लॉकचेन समाकलित करणाऱ्या गेमपासून ते ज्यांचे संपूर्ण गेम जग ऑनचेन असते अशा गेमपर्यंत. अनेक गेम इन-गेम मालमत्ता NFTs (नॉन-फंजिबल टोकन) म्हणून व्यवस्थापित करण्यासाठी Ethereum चा वापर करतात. यामुळे खेळाडूंना खऱ्या अर्थाने अद्वितीय डिजिटल वस्तूंची मालकी मिळवता येते, ज्यांची एकाच गेम डेव्हलपरच्या इकोसिस्टमच्या मर्यादेबाहेर उघडपणे देवाणघेवाण, विक्री किंवा भेट दिली जाऊ शकते. जरी या मालमत्ता खेळाडू एजन्सीचे नवीन प्रकार ऑफर करतात, तरीही मुख्य गेम लॉजिक अनेकदा केंद्रीकृत सर्व्हरवरच राहते.
+
+पूर्णपणे ऑनचेन गेम असे गेम आहेत जिथे मूलभूत मेकॅनिक्स आणि अनेकदा संपूर्ण गेम जग थेट Ethereum ब्लॉकचेन (किंवा त्याच्या लेयर 2s) वरील स्मार्ट करारांद्वारे नियंत्रित केले जाते. यामुळे अतुलनीय पारदर्शकता सुनिश्चित होते. कोणतेही केंद्रीय सर्व्हर नाहीत, कोणतेही मध्यस्थ नाहीत—फक्त पारदर्शक, खेळाडू-चालित अनुभव आणि अर्थव्यवस्था.
+
+- खेळाडू त्यांच्या मालमत्तेची मालकी NFTs म्हणून ठेवतात.
+- वस्तूंची मुक्तपणे देवाणघेवाण, भेट किंवा विक्री केली जाऊ शकते.
+- ब्लॉकचेन मालमत्ता कायमस्वरूपी उपलब्ध राहील याची खात्री देते.
+
+## गेमिंगची सद्यस्थिती {#the-current-state-of-gaming}
+
+- **वारंवार गेम बंद होणे:** केवळ 2023 मध्ये, [60+ गेम बंद झाले](https://tech4gamers.com/game-studios-shut-down-2023/), आणि 11 गेम स्टुडिओ पूर्णपणे बंद झाले, ज्यामुळे खेळाडूंच्या इन-गेम गुंतवणुकीसाठी काहीही शिल्लक राहिले नाही. ऑनचेन गेम, त्यांचे लॉजिक आणि मालमत्ता विकेंद्रित नेटवर्कवर असल्यामुळे, जोपर्यंत ब्लॉकचेन अस्तित्वात आहे तोपर्यंत टिकू शकतात, ज्यामुळे उच्च प्रमाणात कायमस्वरूपीपणा मिळतो.
+- **लॉक केलेल्या मालमत्तेबद्दल निराशा:** [51% गेमर्स निराश आहेत](https://www.starknet.io/blog/blockchain-gaming/) कारण ते खरेदी केलेल्या इन-गेम वस्तू भेट देऊ शकत नाहीत किंवा पुन्हा विकू शकत नाहीत, आणि 23% इन-गेम खरेदीतून पैसे वसूल करणे किती कठीण आहे याबद्दल नाराज आहेत. खेळाडू इन-गेम वस्तू मिळवण्यासाठी बराच वेळ आणि पैसा गुंतवतात, पण नंतर त्यांना कळते की ते खऱ्या अर्थाने त्यांचे मालक नाहीत. Ethereum चे NFT मानक सत्यापित डिजिटल मालकी प्रदान करते, ज्यामुळे खेळाडू त्यांच्या मालमत्तेवर नियंत्रण ठेवू शकतात.
+- **परतावा नसलेला उच्च खर्च:** [गेमर्स त्यांच्या आयुष्यात आभासी वस्तूंवर सरासरी \$6,425 खर्च करतात](https://www.starknet.io/blog/blockchain-gaming/), दरमहा \$8.74 किंवा दरवर्षी \$104 खर्च करतात. ऑनचेन मालकी त्या खर्चाला बुडीत खर्चातून एका डिजिटल मालमत्तेतील गुंतवणुकीत रूपांतरित करते जी विकली जाऊ शकते, देवाणघेवाण केली जाऊ शकते किंवा भेट दिली जाऊ शकते, जसे की भौतिक संग्रहणीय वस्तू.
+
+## Ethereum वर तयार केलेले लोकप्रिय गेम {#popular-games-built-on-ethereum}
+
+डेव्हलपर गेम अधिक आकर्षक बनवण्यासाठी आणि कौशल्य-आधारित गेमप्लेला अधिक सखोल करण्यासाठी साध्या बक्षीस मेकॅनिक्सच्या पलीकडे जाण्यासाठी नवीन मार्ग शोधत आहेत.
+
+<OnchainGamingProductList list="game" />
+
+## खेळून-कमवा (P2E) {#play-to-earn-p2e}
+
+खेळून-कमवा (P2E) गेमसह, आपण वास्तविक-जगातील मूल्याच्या इन-गेम मालमत्ता मिळवू शकता. अशाश्वत बक्षिसांवर अवलंबून असलेल्या पूर्वीच्या P2E मॉडेल्सच्या विपरीत, नवीन गेम दीर्घकालीन मूल्यावर लक्ष केंद्रित करतात. उदाहरणार्थ, [वुल्फ गेम](https://gam3s.gg/wolf-game/) धोरणात्मक गेमप्लेला वास्तविक डिजिटल मालमत्ता मालकीसह जोडतो. खेळाडू आभासी मेंढ्या आणि लांडगे व्यवस्थापित करतात, इन-गेम चलन WOOL मिळवतात, ज्याची देवाणघेवाण किंवा विक्री केली जाऊ शकते.
+
+<OnchainGamingProductList list="p2e" />
+
+## इंटरऑपरेबिलिटी आणि क्रॉस-चेन प्ले {#interoperability-and-cross-chain-play}
+
+गेमिंगसाठी Ethereum च्या सर्वात शक्तिशाली वैशिष्ट्यांपैकी एक म्हणजे इंटरऑपरेबिलिटी आणि कंपोझेबिलिटीसाठी त्याचे मूळ समर्थन. पारंपारिक गेम "भिंतींच्या बागेत" चालतात, जे इन-गेम मालमत्ता आणि प्रगती एकाच शीर्षकात लॉक करतात. Ethereum वर तयार केलेली इन-गेम मालमत्ता, आणि अगदी मुख्य गेम लॉजिक, सुरक्षिततेचा त्याग न करता विविध ऍप्लिकेशन्स आणि चेन्सवर संवाद साधू शकतात. जरी ही अजूनही एक विकसनशील इकोसिस्टम असली तरी, काही Ethereum-आधारित गेम नेटवर्क्स आधीच इंटरऑपरेबल आहेत आणि इन-गेम आयटम (NFTs) एकाधिक गेममध्ये वापरण्याची परवानगी देतात.
+
+उदाहरणार्थ, Illuvium मध्ये, [खेळाडू Illuvials नावाचे प्राणी गोळा करू शकतात](https://gam3s.gg/news/illuvium-three-web3-games/), जे NFTs आहेत. हे Illuvials Illuvium विश्वातील विविध गेममध्ये वापरले जाऊ शकतात. Illuvium Overworld मध्ये पकडलेले एक Illuvial Illuvium Arena मध्ये लढाईसाठी देखील वापरले जाऊ शकते.
+
+आणखी एक उदाहरण म्हणजे गॅलेक्सी फाईट क्लब. या गेममध्ये, [खेळाडू लढाईत सहभागी होण्यासाठी विविध NFT संग्रह वापरू शकतात](https://gam3s.gg/galaxy-fight-club/), याचा अर्थ विविध प्रकल्पांमधील NFTs गेममध्ये वापरले जाऊ शकतात.
+
+## स्केलेबिलिटी आणि गॅस फी सुधारणा {#scalability-and-gas-fee-improvements}
+
+ऑनचेन गेमिंगवर एक जुनी टीका होती की ब्लॉकचेन गेमर्सना त्यांच्या अपेक्षेनुसार अनुभव देण्यासाठी खूप जटिल आणि मंद आहेत. परंतु जसजसे Ethereum परिपक्व झाले आहे, तसतसे ऑनचेन गेमिंगचा खर्च लक्षणीयरीत्या कमी करण्यासाठी आणि कार्यक्षमता वाढवण्यासाठी उपाय उदयास आले आहेत, ज्यामुळे परस्परसंवादी आणि वेगवान अनुभव व्यवहार्य बनले आहेत.
+
+या प्रगती प्रामुख्याने खालील गोष्टींद्वारे साध्य केल्या जातात:
+
+- **गॅस-लेस व्यवहार:** काही प्लॅटफॉर्म आणि प्रोटोकॉल, ज्यात Immutable X चा फायदा घेणाऱ्यांचा समावेश आहे, वापरकर्त्यासाठी शुल्काशिवाय ट्रेडिंग किंवा NFTs मिंटिंग सारखे व्यवहार करण्याची क्षमता देतात, ज्यामुळे खेळाडूचा अनुभव अधिक सुव्यवस्थित होतो.
+- **स्केलिंग सोल्यूशन्स:** Ethereum L2s जसे की Arbitrum, zkSync आणि Starknet त्यांच्या उच्च थ्रूपुट आणि कमी खर्चामुळे ऑनचेन गेमसाठी इकोसिस्टम सक्रियपणे वाढवत आहेत.
+- **[MUD इकोसिस्टम](https://mud.dev/):** MUD ऑनचेन गेम डेव्हलपमेंटसाठी Ethereum-आधारित ऍप्लिकेशन डेव्हलपमेंट टूलकिट ऑप्टिमाइझ करते, जटिल गेम लॉजिकसाठी अधिक कार्यक्षम राज्य व्यवस्थापन प्रदान करते.
+
+## Ethereum गेमिंगसह प्रारंभ करा {#get-started-with-ethereum-gaming}
+
+Ethereum गेमिंगमध्ये प्रवेश करणे आपल्या विचारापेक्षा सोपे आहे. फक्त काही पायऱ्यांसह, आपण खेळण्यास प्रारंभ करू शकता आणि आपल्या प्रगतीचा आनंद घेऊ शकता:
+
+1. **क्रिप्टो वॉलेट सेट करा:** आपल्याला आपली डिजिटल मालमत्ता व्यवस्थापित करण्यासाठी आणि विकेंद्रित ऍप्लिकेशन्सशी संवाद साधण्यासाठी वॉलेटची आवश्यकता असेल. [एक वॉलेट निवडा](/wallets/find-wallet/)
+2. **तुमच्या वॉलेटमध्ये निधी जमा करा:** तुम्ही वापरण्याची योजना असलेल्या लेयर 2 नेटवर्कशी संबंधित काही Ether (ETH) किंवा टोकन्स मिळवा.
+3. **गेम एक्सप्लोर करा:** [Orden](https://orden.gg/), [ChainPlay](https://chainplay.gg/chain/ethereum/), [Gam3s.GG](https://gam3s.gg/), [DappRadar](https://dappradar.com/rankings/protocol/ethereum/category/games), [OpenSea](https://opensea.io/), आणि [PlayToEarn.net](https://playtoearn.com/blockchaingames) सारख्या प्लॅटफॉर्मवर गेम शोधा.
diff --git a/public/content/translations/mr/glossary/index.md b/public/content/translations/mr/glossary/index.md
new file mode 100644
index 00000000000..cb3783a01b1
--- /dev/null
+++ b/public/content/translations/mr/glossary/index.md
@@ -0,0 +1,505 @@
+---
+title: "Ethereum शब्दकोष"
+description: "Ethereum शी संबंधित तांत्रिक आणि गैर-तांत्रिक संज्ञांची एक अपूर्ण शब्दसूची"
+lang: mr
+---
+
+# शब्दसूची {#ethereum-glossary}
+
+## \# {#section-numbers}
+
+<GlossaryDefinition term="51%-attack" />
+
+<Divider />
+
+## A {#section-a}
+
+<GlossaryDefinition term="account" />
+
+<GlossaryDefinition term="address" />
+
+<GlossaryDefinition term="abi" />
+
+<GlossaryDefinition term="anti-sybil" />
+
+<GlossaryDefinition term="api" />
+
+<GlossaryDefinition term="apr" />
+
+<GlossaryDefinition term="asic" />
+
+<GlossaryDefinition term="assert" />
+
+<GlossaryDefinition term="attestation" />
+
+<Divider />
+
+## B {#section-b}
+
+<GlossaryDefinition term="base-fee" />
+
+<GlossaryDefinition term="beacon-chain" />
+
+<GlossaryDefinition term="big-endian" />
+
+<GlossaryDefinition term="block" />
+
+<GlossaryDefinition term="block-explorer" />
+
+<GlossaryDefinition term="block-header" />
+
+<GlossaryDefinition term="block-propagation" />
+
+<GlossaryDefinition term="block-proposer" />
+
+<GlossaryDefinition term="block-reward" />
+
+<GlossaryDefinition term="block-status" />
+
+<GlossaryDefinition term="block-time" />
+
+<GlossaryDefinition term="block-validation" />
+
+<GlossaryDefinition term="blockchain" />
+
+<GlossaryDefinition term="bootnode" />
+
+<GlossaryDefinition term="bridge" />
+
+<GlossaryDefinition term="bytecode" />
+
+<GlossaryDefinition term="byzantium-fork" />
+
+<Divider />
+
+## C {#section-c}
+
+<GlossaryDefinition term="casper-ffg" />
+
+<GlossaryDefinition term="checkpoint" />
+
+<GlossaryDefinition term="compiling" />
+
+<GlossaryDefinition term="committee" />
+
+<GlossaryDefinition term="computational-infeasibility" />
+
+<GlossaryDefinition term="consensus" />
+
+<GlossaryDefinition term="consensus-client" />
+
+<GlossaryDefinition term="consensus-layer" />
+
+<GlossaryDefinition term="consensus-rules" />
+
+<GlossaryDefinition term="constantinople-fork" />
+
+<GlossaryDefinition term="contract-account" />
+
+<GlossaryDefinition term="contract-creation-transaction" />
+
+<GlossaryDefinition term="cryptography" />
+
+<GlossaryDefinition term="cryptoeconomics" />
+
+<Divider />
+
+## D {#section-d}
+
+<GlossaryDefinition term="doge-d" />
+
+<GlossaryDefinition term="dag" />
+
+<GlossaryDefinition term="dapp" />
+
+<GlossaryDefinition term="data-availability" />
+
+<GlossaryDefinition term="decentralization" />
+
+<GlossaryDefinition term="dao" />
+
+<GlossaryDefinition term="desci" />
+
+<GlossaryDefinition term="dex" />
+
+<GlossaryDefinition term="deposit-contract" />
+
+<GlossaryDefinition term="defi" />
+
+<GlossaryDefinition term="difficulty" />
+
+<GlossaryDefinition term="difficulty-bomb" />
+
+<GlossaryDefinition term="digital-signatures" />
+
+<GlossaryDefinition term="discovery" />
+
+<GlossaryDefinition term="distributed-hash-table" />
+
+<GlossaryDefinition term="double-spend" />
+
+<Divider />
+
+## E {#section-e}
+
+<GlossaryDefinition term="ecdsa" />
+
+<GlossaryDefinition term="encryption" />
+
+<GlossaryDefinition term="entropy" />
+
+<GlossaryDefinition term="epoch" />
+
+<GlossaryDefinition term="equivocation" />
+
+<GlossaryDefinition term="eth1" />
+
+<GlossaryDefinition term="eth2" />
+
+<GlossaryDefinition term="eip" />
+
+<GlossaryDefinition term="ens" />
+
+<GlossaryDefinition term="execution-client" />
+
+<GlossaryDefinition term="execution-layer" />
+
+<GlossaryDefinition term="eoa" />
+
+<GlossaryDefinition term="erc" />
+
+<GlossaryDefinition term="erc-20" />
+
+<GlossaryDefinition term="erc-721" />
+
+<GlossaryDefinition term="erc-1155" />
+
+<GlossaryDefinition term="ethash" />
+
+<GlossaryDefinition term="ether" />
+
+<GlossaryDefinition term="events" />
+
+<GlossaryDefinition term="evm" />
+
+<GlossaryDefinition term="evm-assembly-language" />
+
+<Divider />
+
+## F {#section-f}
+
+<GlossaryDefinition term="fallback-function" />
+
+<GlossaryDefinition term="faucet" />
+
+<GlossaryDefinition term="finality" />
+
+<GlossaryDefinition term="finney" />
+
+<GlossaryDefinition term="fork" />
+
+<GlossaryDefinition term="fork-choice-algorithm" />
+
+<GlossaryDefinition term="fraud-proof" />
+
+<GlossaryDefinition term="frontier" />
+
+<Divider />
+
+## G {#section-g}
+
+<GlossaryDefinition term="gas" />
+
+<GlossaryDefinition term="gas-limit" />
+
+<GlossaryDefinition term="gas-price" />
+
+<GlossaryDefinition term="genesis-block" />
+
+<GlossaryDefinition term="geth" />
+
+<GlossaryDefinition term="gwei" />
+
+<Divider />
+
+## H {#section-h}
+
+<GlossaryDefinition term="hard-fork" />
+
+<GlossaryDefinition term="hash" />
+
+<GlossaryDefinition term="hash-rate" />
+
+<GlossaryDefinition term="holographic-consensus" />
+
+<GlossaryDefinition term="homestead" />
+
+<Divider />
+
+## I {#section-i}
+
+<GlossaryDefinition term="index" />
+
+<GlossaryDefinition term="ide" />
+
+<GlossaryDefinition term="immutable-deployed-code-problem" />
+
+<GlossaryDefinition term="internal-transaction" />
+
+<GlossaryDefinition term="issuance" />
+
+<Divider />
+
+## K {#section-k}
+
+<GlossaryDefinition term="kdf" />
+
+<GlossaryDefinition term="key" />
+
+<GlossaryDefinition term="keystore" />
+
+<GlossaryDefinition term="keccak-256" />
+
+<Divider />
+
+## L {#section-l}
+
+<GlossaryDefinition term="layer-1" />
+
+<GlossaryDefinition term="layer-2" />
+
+<GlossaryDefinition term="library" />
+
+<GlossaryDefinition term="light-client" />
+
+<GlossaryDefinition term="liquidity" />
+
+<GlossaryDefinition term="liquidity-tokens" />
+
+<GlossaryDefinition term="lmd-ghost" />
+
+<Divider />
+
+## M {#section-m}
+
+<GlossaryDefinition term="mainnet" />
+
+<GlossaryDefinition term="max-fee-per-gas" />
+
+<GlossaryDefinition term="merkle-patricia-tree" />
+
+<GlossaryDefinition term="merkle-root" />
+
+<GlossaryDefinition term="message" />
+
+<GlossaryDefinition term="message-call" />
+
+<GlossaryDefinition term="mev" />
+
+<GlossaryDefinition term="mining" />
+
+<GlossaryDefinition term="miner" />
+
+<GlossaryDefinition term="mint" />
+
+<GlossaryDefinition term="multisig" />
+
+<Divider />
+
+## N {#section-n}
+
+<GlossaryDefinition term="network" />
+
+<GlossaryDefinition term="network-hashrate" />
+
+<GlossaryDefinition term="nft" />
+
+<GlossaryDefinition term="node" />
+
+<GlossaryDefinition term="nonce" />
+
+<Divider />
+
+## O {#section-o}
+
+<GlossaryDefinition term="offchain" />
+
+<GlossaryDefinition term="ommer" />
+
+<GlossaryDefinition term="onchain" />
+
+<GlossaryDefinition term="optimistic-rollup" />
+
+<GlossaryDefinition term="oracle" />
+
+<Divider />
+
+## P {#section-p}
+
+<GlossaryDefinition term="peer" />
+
+<GlossaryDefinition term="peer-to-peer-network" />
+
+<GlossaryDefinition term="permissionless" />
+
+<GlossaryDefinition term="plasma" />
+
+<GlossaryDefinition term="private-key" />
+
+<GlossaryDefinition term="private-chain" />
+
+<GlossaryDefinition term="poap" />
+
+<GlossaryDefinition term="pos" />
+
+<GlossaryDefinition term="pow" />
+
+<GlossaryDefinition term="proto-danksharding" />
+
+<GlossaryDefinition term="public-goods" />
+
+<GlossaryDefinition term="public-key" />
+
+<Divider />
+
+## R {#section-r}
+
+<GlossaryDefinition term="receipt" />
+
+<GlossaryDefinition term="re-entrancy-attack" />
+
+<GlossaryDefinition term="reward" />
+
+<GlossaryDefinition term="rlp" />
+
+<GlossaryDefinition term="rollups" />
+
+<GlossaryDefinition term="rpc" />
+
+<Divider />
+
+## S {#section-s}
+
+<GlossaryDefinition term="sha" />
+
+<GlossaryDefinition term="recovery-phrase" />
+
+<GlossaryDefinition term="sequencer" />
+
+<GlossaryDefinition term="serialization" />
+
+<GlossaryDefinition term="shard" />
+
+<GlossaryDefinition term="sidechain" />
+
+<GlossaryDefinition term="signing" />
+
+<GlossaryDefinition term="singleton" />
+
+<GlossaryDefinition term="slasher" />
+
+<GlossaryDefinition term="slot" />
+
+<GlossaryDefinition term="smart-contract" />
+
+<GlossaryDefinition term="snark" />
+
+<GlossaryDefinition term="soft-fork" />
+
+<GlossaryDefinition term="solidity" />
+
+<GlossaryDefinition term="solidity-inline-assembly" />
+
+<GlossaryDefinition term="stablecoin" />
+
+<GlossaryDefinition term="staking" />
+
+<GlossaryDefinition term="staking-pool" />
+
+<GlossaryDefinition term="stark" />
+
+<GlossaryDefinition term="state" />
+
+<GlossaryDefinition term="state-channels" />
+
+<GlossaryDefinition term="supermajority" />
+
+<GlossaryDefinition term="sybil-attack" />
+
+<GlossaryDefinition term="syncing" />
+
+<GlossaryDefinition term="sync-committee" />
+
+<GlossaryDefinition term="szabo" />
+
+<Divider />
+
+## T {#section-t}
+
+<GlossaryDefinition term="terminal-total-difficulty" />
+
+<GlossaryDefinition term="testnet" />
+
+<GlossaryDefinition term="token" />
+
+<GlossaryDefinition term="token-factory" />
+
+<GlossaryDefinition term="transaction" />
+
+<GlossaryDefinition term="transaction-fee" />
+
+<GlossaryDefinition term="trust-assumptions" />
+
+<GlossaryDefinition term="trustlessness" />
+
+<GlossaryDefinition term="turing-complete" />
+
+<Divider />
+
+## V {#section-v}
+
+<GlossaryDefinition term="validator" />
+
+<GlossaryDefinition term="validator-lifecycle" />
+
+<GlossaryDefinition term="validity-proof" />
+
+<GlossaryDefinition term="validium" />
+
+<GlossaryDefinition term="vyper" />
+
+<Divider />
+
+## W {#section-w}
+
+<GlossaryDefinition term="wallet" />
+
+<GlossaryDefinition term="web3" />
+
+<GlossaryDefinition term="wei" />
+
+<GlossaryDefinition term="wrapped-token" />
+
+<Divider />
+
+## Z {#section-z}
+
+<GlossaryDefinition term="zero-address" />
+
+<GlossaryDefinition term="zk-proof" />
+
+<GlossaryDefinition term="zk-rollup" />
+
+<Divider />
+
+## स्रोत {#sources}
+
+_[Andreas M. Antonopoulos, Gavin Wood](https://aantonop.com/books/mastering-ethereum) यांच्या [Mastering Ethereum](https://github.com/ethereumbook/ethereumbook) मधून CC-BY-SA अंतर्गत अंशतः प्रदान केलेले_
+
+<Divider />
+
+## या पृष्ठावर योगदान द्या {#contribute-to-this-page}
+
+आमच्याकडून काही सुटले आहे का? काही चुकीचे आहे का? GitHub वर या शब्दसूचीमध्ये योगदान देऊन आम्हाला सुधारण्यात मदत करा!
+
+[योगदान कसे द्यावे याबद्दल अधिक जाणून घ्या](/contributing/adding-glossary-terms)
diff --git a/public/content/translations/mr/governance/index.md b/public/content/translations/mr/governance/index.md
new file mode 100644
index 00000000000..9cf4190c0b8
--- /dev/null
+++ b/public/content/translations/mr/governance/index.md
@@ -0,0 +1,184 @@
+---
+title: "इथरियम गव्हर्नन्स"
+description: "इथरियमबद्दल निर्णय कसे घेतले जातात याचा परिचय."
+lang: mr
+---
+
+# Ethereum गव्हर्नन्सचा परिचय {#introduction}
+
+_जर कोणीही इथरियमचे मालक नसेल, तर इथरियममधील भूतकाळातील आणि भविष्यातील बदलांबद्दलचे निर्णय कसे घेतले जातात? Ethereum गव्हर्नन्स ही अशी प्रक्रिया आहे जी असे निर्णय घेण्यास परवानगी देते._
+
+<Divider />
+
+## शासन म्हणजे काय? गव्हर्नन्स म्हणजे काय? {#what-is-governance}
+
+शासन ही अशी व्यवस्था आहे जी निर्णय घेण्यास परवानगी देते. ठराविक संस्थात्मक संरचनेत, कार्यकारी संघ किंवा संचालक मंडळाला निर्णय घेण्याबाबत अंतिम म्हणणे असू शकते. किंवा कदाचित भागधारक बदल लागू करण्याच्या प्रस्तावांवर मत देतात. राजकीय व्यवस्थेमध्ये, निवडून आलेले अधिकारी त्यांच्या घटकांच्या इच्छांचे प्रतिनिधित्व करण्याचा प्रयत्न करणारे कायदे तयार करू शकतात.
+
+## विकेंद्रित गव्हर्नन्स {#decentralized-governance}
+
+इथरियम प्रोटोकॉलची मालकी किंवा नियंत्रण कोणीही करत नाही, परंतु नेटवर्कचे दीर्घायुष्य आणि समृद्धी सुनिश्चित करण्यासाठी बदलांची अंमलबजावणी करण्याबाबत निर्णय घेणे आवश्यक आहे. मालकीच्या या अभावामुळे पारंपारिक संस्थात्मक प्रशासन एक विसंगत उपाय बनते.
+
+## Ethereum गव्हर्नन्स {#ethereum-governance}
+
+इथरियम गव्हर्नन्स ही प्रक्रिया आहे ज्याद्वारे प्रोटोकॉल बदल केले जातात. लोक आणि ऍप्लिकेशन प्रोटोकॉल कसे वापरतात याच्याशी ही प्रक्रिया संबंधित नाही हे निदर्शनास आणणे महत्त्वाचे आहे - इथरियम अनुज्ञेय आहे. जगातील कोठूनही कोणीही onchain क्रियाकलापांमध्ये सहभागी होऊ शकते. कोण अर्ज तयार करू शकतो किंवा करू शकत नाही किंवा व्यवहार पाठवू शकतो यासाठी कोणतेही नियम सेट केलेले नाहीत. तथापि, मुख्य प्रोटोकॉलमध्ये बदल प्रस्तावित करण्याची प्रक्रिया आहे, ज्याच्या वर विकेंद्रित अनुप्रयोग चालतात. बरेच लोक इथरियमच्या स्थिरतेवर अवलंबून असल्याने, इथरियममधील कोणतेही बदल सुरक्षित आणि समुदायाद्वारे व्यापकपणे समर्थित आहेत याची खात्री करण्यासाठी सामाजिक आणि तांत्रिक प्रक्रियांसह मुख्य बदलांसाठी खूप उच्च समन्वय थ्रेशोल्ड आहे.
+
+### Onchain वि. offchain गव्हर्नन्स {#onchain-vs-offchain}
+
+Blockchain तंत्रज्ञान नवीन गव्हर्नन्स क्षमतांना अनुमती देते, ज्याला onchain गव्हर्नन्स म्हणून ओळखले जाते. Onchain गव्हर्नन्स म्हणजे जेव्हा प्रस्तावित प्रोटोकॉल बदलांचा निर्णय भागधारकांच्या मताने घेतला जातो, सामान्यतः गव्हर्नन्स टोकन धारकांद्वारे, आणि मतदान blockchain वर होते. onchain गव्हर्नन्सच्या काही प्रकारांमध्ये, प्रस्तावित प्रोटोकॉल बदल आधीच कोडमध्ये लिहिलेले असतात आणि जर भागधारकांनी व्यवहार स्वाक्षरी करून बदलांना मंजुरी दिली तर ते आपोआप लागू केले जातात.
+
+याउलट, offchain गव्हर्नन्समध्ये कोणताही प्रोटोकॉल बदलण्याचा निर्णय सामाजिक चर्चेच्या अनौपचारिक प्रक्रियेद्वारे घेतला जातो, जो मंजूर झाल्यास कोडमध्ये लागू केला जाईल.
+
+**Ethereum गव्हर्नन्स offchain घडते,** आणि या प्रक्रियेत विविध प्रकारचे भागधारक सामील असतात.
+
+_जरी प्रोटोकॉल स्तरावर Ethereum गव्हर्नन्स offchain असले तरी, Ethereum वर तयार केलेले अनेक उपयोग-प्रकार, जसे की DAOs, onchain गव्हर्नन्स वापरतात._
+
+<ButtonLink href="/dao/">
+  DAOs वर अधिक
+</ButtonLink>
+
+<Divider />
+
+## यात कोणाचा सहभाग आहे? {#who-is-involved}
+
+[Ethereum समुदाय](/community/) मध्ये विविध भागधारक आहेत, आणि प्रत्येकजण गव्हर्नन्स प्रक्रियेत भूमिका बजावतो. प्रोटोकॉलपासून सर्वात दूर असलेल्या भागधारकांपासून सुरुवात करून आणि झूम इन करणे, आमच्याकडे आहे:
+
+- **Ether धारक**: या लोकांकडे ETH ची कितीही रक्कम असू शकते. [ETH वर अधिक](/what-is-ether/).
+- **ॲप्लिकेशन वापरकर्ते**: हे लोक Ethereum blockchain वरील ॲप्लिकेशन्सशी संवाद साधतात.
+- **ॲप्लिकेशन/टूलिंग डेव्हलपर्स**: हे लोक Ethereum blockchain वर चालणारे ॲप्लिकेशन्स (उदा., DeFi, NFTs, इ.) लिहितात. किंवा Ethereum शी संवाद साधण्यासाठी टूलिंग (उदा., wallets, टेस्ट सूट्स, इ.) तयार करतात. [dapps वर अधिक](/apps/).
+- **नोड ऑपरेटर्स**: हे लोक ब्लॉक्स आणि व्यवहारांचा प्रसार करणारे नोड्स चालवतात, आणि त्यांना आढळणारा कोणताही अवैध व्यवहार किंवा ब्लॉक नाकारतात. [नोड्सवर अधिक](/developers/docs/nodes-and-clients/).
+- **EIP लेखक**: हे लोक Ethereum Improvement Proposals (EIPs) च्या स्वरूपात Ethereum प्रोटोकॉलमध्ये बदल सुचवतात. [EIPs वर अधिक](/eips/).
+- **व्हॅलिडेटर्स**: हे लोक नोड्स चालवतात जे Ethereum blockchain मध्ये नवीन ब्लॉक्स जोडू शकतात.
+- **प्रोटोकॉल डेव्हलपर्स** (a.k.a. "कोअर डेव्हलपर्स" ): हे लोक विविध Ethereum अंमलबजावणीची देखरेख करतात (उदा., एक्झिक्यूशन लेअरवर go-ethereum, Nethermind, Besu, Erigon, Reth किंवा कन्सेन्सस लेअरवर Prysm, Lighthouse, Nimbus, Teku, Lodestar, Grandine). [Ethereum क्लायंट्सवर अधिक](/developers/docs/nodes-and-clients/).
+
+_टीप: कोणतीही एक व्यक्ती यापैकी अनेक गटांचा भाग असू शकते (उदा. एक प्रोटोकॉल डेव्हलपर एखाद्या EIP चे नेतृत्व करू शकतो, बीकन चेन व्हॅलिडेटर चालवू शकतो आणि DeFi ॲप्लिकेशन्स वापरू शकतो)._ तरीही, वैचारिक स्पष्टतेसाठी त्यांच्यात फरक करणे सर्वात सोपे आहे._
+
+<Divider />
+
+## EIP म्हणजे काय? {#what-is-an-eip}
+
+Ethereum गव्हर्नन्समध्ये वापरली जाणारी एक महत्त्वाची प्रक्रिया म्हणजे **Ethereum Improvement Proposals (EIPs)** चा प्रस्ताव. EIPs हे Ethereum साठी संभाव्य नवीन वैशिष्ट्ये किंवा प्रक्रिया निर्दिष्ट करणारे मानक आहेत. इथरियम समुदायातील कोणीही EIP तयार करू शकतो. तुम्हाला EIP लिहिण्यात किंवा पीअर-रिव्ह्यू आणि/किंवा गव्हर्नन्समध्ये सहभागी होण्यात स्वारस्य असल्यास, पहा:
+
+<ButtonLink href="/eips/">
+  EIPs वर अधिक
+</ButtonLink>
+
+<Divider />
+
+## औपचारिक प्रक्रिया {#formal-process}
+
+इथरियम प्रोटोकॉलमध्ये बदल सादर करण्याची औपचारिक प्रक्रिया खालीलप्रमाणे आहे:
+
+1. **कोअर EIP प्रस्तावित करा**: [EIP-1](https://eips.ethereum.org/EIPS/eip-1#core-eips) मध्ये वर्णन केल्याप्रमाणे, Ethereum मध्ये औपचारिकपणे बदल प्रस्तावित करण्याची पहिली पायरी म्हणजे त्याचा तपशील कोअर EIP मध्ये देणे. हे EIP साठी अधिकृत तपशील म्हणून कार्य करेल जे स्वीकारल्यास प्रोटोकॉल डेव्हलपर लागू करतील.
+
+2. **तुमचा EIP प्रोटोकॉल डेव्हलपर्सना सादर करा**: एकदा तुमच्याकडे एक कोअर EIP असेल ज्यासाठी तुम्ही समुदायाकडून इनपुट गोळा केले आहे, की तुम्ही ते प्रोटोकॉल डेव्हलपर्सना सादर केले पाहिजे. तुम्ही [AllCoreDevs call](https://github.com/ethereum/execution-specs/tree/master/network-upgrades#getting-the-considered-for-inclusion-cfi-status) वर चर्चेसाठी प्रस्ताव देऊन असे करू शकता. [Ethereum Magician's forum](https://ethereum-magicians.org/) वर किंवा [Ethereum R&D Discord](https://discord.gg/mncqtgVSVw) मध्ये काही चर्चा आधीच असिंक्रोनसपणे झाल्या असण्याची शक्यता आहे.
+
+> या टप्प्याचे संभाव्य परिणाम आहेत:
+
+> - भविष्यातील नेटवर्क अपग्रेडसाठी EIP चा विचार केला जाईल
+> - तांत्रिक बदलांची विनंती केली जाईल
+> - जर ते प्राधान्य नसेल किंवा विकासाच्या प्रयत्नांच्या तुलनेत सुधारणा मोठ्या प्रमाणात नसेल तर ते नाकारले जाऊ शकते
+
+3. **अंतिम प्रस्तावाच्या दिशेने पुनरावृत्ती करा:** सर्व संबंधित भागधारकांकडून अभिप्राय मिळाल्यानंतर, तुम्हाला तुमच्या सुरुवातीच्या प्रस्तावात त्याची सुरक्षा सुधारण्यासाठी किंवा विविध वापरकर्त्यांच्या गरजा अधिक चांगल्या प्रकारे पूर्ण करण्यासाठी बदल करण्याची आवश्यकता असेल. एकदा तुमच्या EIP ने तुम्हाला आवश्यक वाटत असलेले सर्व बदल समाविष्ट केले की, तुम्हाला ते पुन्हा प्रोटोकॉल डेव्हलपर्सकडे सादर करावे लागतील. त्यानंतर तुम्ही या प्रक्रियेच्या पुढच्या टप्प्यावर जाल, किंवा नवीन चिंता निर्माण होतील, तुमच्या प्रस्तावावर पुनरावृत्तीची आणखी एक फेरी आवश्यक आहे.
+
+4. **नेटवर्क अपग्रेडमध्ये समाविष्ट EIP**: EIP मंजूर, चाचणी आणि लागू केले आहे असे गृहीत धरून, ते नेटवर्क अपग्रेडचा भाग म्हणून शेड्यूल केले जाते. नेटवर्क अपग्रेड्सच्या उच्च समन्वय खर्चामुळे (प्रत्येकाला एकाच वेळी अपग्रेड करणे आवश्यक आहे), EIP सामान्यत: अपग्रेडमध्ये एकत्रित केले जातात.
+
+5. **नेटवर्क अपग्रेड सक्रिय**: नेटवर्क अपग्रेड सक्रिय झाल्यानंतर, EIP हे Ethereum नेटवर्कवर लाइव्ह होईल. _टीप: नेटवर्क अपग्रेड सामान्यत: इथरियम मेननेटवर सक्रिय होण्यापूर्वी टेस्टनेटवर सक्रिय केले जातात._
+
+हा प्रवाह, अगदी सरलीकृत असताना, इथरियमवर सक्रिय होण्यासाठी प्रोटोकॉल बदलाच्या महत्त्वपूर्ण टप्प्यांचे विहंगावलोकन देतो. आता, या प्रक्रियेदरम्यान खेळत असलेल्या अनौपचारिक घटकांकडे पाहू.
+
+## अनौपचारिक प्रक्रिया {#informal-process}
+
+### पूर्वीचे काम समजून घेणे {#prior-work}
+
+ईआयपी चॅम्पियन्सनी ईआयपी तयार करण्यापूर्वी पूर्वीचे काम आणि प्रस्तावांसह स्वत: ला परिचित केले पाहिजे जे इथरियम मेननेटवर तैनात करण्यासाठी गंभीरपणे विचारात घेतले जाऊ शकते. अशा प्रकारे, ईआयपी काहीतरी नवीन आणेल जे आधी नाकारले गेले नाही. यावर संशोधन करण्यासाठी तीन मुख्य ठिकाणे म्हणजे [EIP रेपॉजिटरी](https://github.com/ethereum/EIPs), [Ethereum Magicians](https://ethereum-magicians.org/) आणि [ethresear.ch](https://ethresear.ch/).
+
+### कार्य गट {#working-groups}
+
+EIP चा प्रारंभिक मसुदा संपादन किंवा बदलांशिवाय Ethereum Mainnet वर लागू होण्याची शक्यता नाही. साधारणपणे, EIP चॅम्पियन्स प्रोटोकॉल डेव्हलपर्सच्या उपसंचासह त्यांचे प्रस्ताव निर्दिष्ट, अंमलबजावणी, चाचणी, पुनरावृत्ती आणि अंतिम रूप देण्यासाठी कार्य करतील. ऐतिहासिकदृष्ट्या, या कार्य गटांना अनेक महिन्यांची (आणि कधीकधी वर्षांची!) गरज आहे कामासाठी. त्याचप्रमाणे, अशा बदलांसाठी EIP चॅम्पियन्समध्ये संबंधित ऍप्लिकेशन/टूलिंग डेव्हलपर्सचा अंत-वापरकर्ता अभिप्राय गोळा करण्यासाठी आणि कोणत्याही तैनाती जोखीम कमी करण्याच्या प्रयत्नात लवकर समावेश असावा.
+
+### सामुदायिक एकमत {#community-consensus}
+
+काही EIPs कमीत कमी सूक्ष्मतेसह सरळ तांत्रिक सुधारणा आहेत, तर काही अधिक क्लिष्ट आहेत आणि ट्रेडऑफसह येतात जे वेगवेगळ्या भागधारकांना वेगवेगळ्या प्रकारे प्रभावित करतात. याचा अर्थ काही EIPs समाजामध्ये इतरांपेक्षा अधिक वादग्रस्त असतात.
+
+वादग्रस्त प्रस्ताव कसे हाताळायचे याबद्दल कोणतेही स्पष्ट प्लेबुक नाही. हे इथरियमच्या विकेंद्रित डिझाइनचा परिणाम आहे ज्यामध्ये कोणताही एक भागधारक गट क्रूर फोर्सद्वारे दुसऱ्यावर जबरदस्ती करू शकत नाही: प्रोटोकॉल डेव्हलपर कोड बदल लागू न करणे निवडू शकतात; नोड ऑपरेटर नवीनतम इथरियम क्लायंट न चालवणे निवडू शकतात; अनुप्रयोग संघ आणि वापरकर्ते साखळीवर व्यवहार न करणे निवडू शकतात. प्रोटोकॉल डेव्हलपर्सकडे लोकांना नेटवर्क अपग्रेड्सचा अवलंब करण्यास भाग पाडण्याचा कोणताही मार्ग नसल्यामुळे, ते सामान्यतः EIPs लागू करणे टाळतील जेथे विवादास्पदता व्यापक समुदायाच्या फायद्यांपेक्षा जास्त असेल.
+
+EIP चॅम्पियन्सनी सर्व संबंधित भागधारकांकडून अभिप्राय मागणे अपेक्षित आहे. जर तुम्हाला वादग्रस्त EIP चे चॅम्पियन वाटत असेल, तर तुम्ही तुमच्या EIP भोवती एकमत निर्माण करण्याचा प्रयत्न करून आक्षेपांचे निराकरण करावे. Ethereum समुदायाचा आकार आणि विविधता लक्षात घेता, असे कोणतेही एकच मेट्रिक (उदा. कॉइन व्होट) नाही, जे सामुदायिक एकमत मोजण्यासाठी वापरले जाऊ शकते, आणि EIP चॅम्पियन्सनी त्यांच्या प्रस्तावाच्या परिस्थितीशी जुळवून घेणे अपेक्षित आहे.
+
+इथरियम नेटवर्कच्या सुरक्षिततेच्या पलीकडे, प्रोटोकॉल डेव्हलपर्सद्वारे ऐतिहासिकदृष्ट्या ऍप्लिकेशन/टूलिंग डेव्हलपर आणि ऍप्लिकेशन वापरकर्ते काय मूल्य देतात यावर महत्त्वपूर्ण वजन ठेवले आहे, कारण त्यांचा इथरियम वापरणे आणि विकसित करणे हे इतर भागधारकांसाठी इकोसिस्टम आकर्षक बनवते. याव्यतिरिक्त, EIPs सर्व क्लायंट अंमलबजावणीवर लागू करणे आवश्यक आहे, जे वेगळ्या संघांद्वारे व्यवस्थापित केले जातात. या प्रक्रियेचा एक भाग म्हणजे सामान्यतः प्रोटोकॉल डेव्हलपर्सच्या अनेक संघांना खात्री पटवणे की विशिष्ट बदल मौल्यवान आहे आणि तो अंतिम वापरकर्त्यांना मदत करतो किंवा सुरक्षिततेच्या समस्येचे निराकरण करतो.
+
+<Divider />
+
+## मतभेद हाताळणे {#disagreements}
+
+भिन्न प्रेरणा आणि विश्वास असलेले अनेक भागधारक असण्याचा अर्थ असा आहे की मतभेद असामान्य नाहीत.
+
+सामान्यत:, समस्येचे मूळ समजून घेण्यासाठी आणि कोणासही विचार करण्याची परवानगी देण्यासाठी सार्वजनिक मंचांमध्ये दीर्घकालीन चर्चेद्वारे मतभेद हाताळले जातात. सामान्यतः, एक गट कबूल करतो किंवा आनंदी माध्यम साध्य केले जाते. जर एखाद्या गटाला पुरेशी तीव्रता जाणवत असेल, तर एखाद्या विशिष्ट बदलाची सक्ती केल्याने साखळीचे विभाजन होऊ शकते. साखळी विभाजन म्हणजे जेव्हा काही भागधारक प्रोटोकॉल बदलाची अंमलबजावणी करण्यास विरोध करतात परिणामी प्रोटोकॉलच्या भिन्न, विसंगत आवृत्त्या तयार होतात, ज्यामधून दोन भिन्न ब्लॉकचेन उदयास येतात.
+
+### DAO फोर्क {#dao-fork}
+
+फोर्क्स म्हणजे जेव्हा नेटवर्कमध्ये मोठे तांत्रिक अपग्रेड किंवा बदल करणे आणि प्रोटोकॉलचे "नियम" बदलणे आवश्यक असते. [Ethereum क्लायंट्सनी](/developers/docs/nodes-and-clients/) नवीन फोर्क नियम लागू करण्यासाठी त्यांचे सॉफ्टवेअर अपडेट करणे आवश्यक आहे.
+
+DAO फोर्क हा [2016 च्या DAO हल्ल्याला](https://www.coindesk.com/learn/understanding-the-dao-attack) दिलेला प्रतिसाद होता, जिथे एका हॅकमध्ये असुरक्षित [DAO](/glossary/#dao) कॉन्ट्रॅक्टमधून 3.6 दशलक्ष पेक्षा जास्त ETH काढण्यात आले होते. फॉर्कने सदोष करारातून निधी एका नवीन करारामध्ये हलविला ज्याने हॅकमध्ये निधी गमावलेल्या कोणालाही ते पुनर्प्राप्त करण्याची परवानगी दिली.
+
+कृतीच्या या मार्गावर इथरियम समुदायाने मतदान केले. कोणताही ETH धारक [एका मतदान प्लॅटफॉर्मवर](https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/) व्यवहाराद्वारे मतदान करू शकत होता. काटा काढण्याचा निर्णय 85% पेक्षा जास्त मतांपर्यंत पोहोचला.
+
+हे लक्षात घेणे महत्त्वाचे आहे की प्रोटोकॉलने हॅक परत करण्याचा काटा लावला असताना, काटा काढण्याचा निर्णय घेताना मताचे वजन काही कारणांमुळे वादातीत आहे:
+
+- मतदानाची टक्केवारी कमालीची कमी होती
+- मतदान होत आहे हे बहुतेकांना माहीत नव्हते
+- मत केवळ ETH धारकांचे प्रतिनिधित्व करते, सिस्टममधील इतर कोणत्याही सहभागींना नाही
+
+समुदायाच्या एका उपसंचाने काटा काढण्यास नकार दिला, मुख्यत्वे कारण त्यांना वाटले की DAO घटना प्रोटोकॉलमधील दोष नाही. त्यांनी पुढे जाऊन [Ethereum Classic](https://ethereumclassic.org/) तयार केले.
+
+आज, इथरियम समुदायाने प्रणालीची विश्वासार्ह तटस्थता राखण्यासाठी कॉन्ट्रॅक्ट बग किंवा गमावलेल्या निधीच्या प्रकरणांमध्ये हस्तक्षेप न करण्याचे धोरण स्वीकारले आहे.
+
+DAO हॅक वर अधिक पहा:
+
+<YouTube id="rNeLuBOVe8A" />
+
+<Divider />
+
+### फोर्किंगची उपयुक्तता {#forking-utility}
+
+Ethereum/Ethereum क्लासिक काटा हे निरोगी काट्याचे उत्कृष्ट उदाहरण आहे. आमच्याकडे दोन गट होते जे काही मूलभूत मूल्यांवर एकमेकांशी जोरदारपणे असहमत होते जेणेकरून त्यांच्या विशिष्ट कृतीचा पाठपुरावा करण्यात गुंतलेली जोखीम योग्य आहे.
+
+महत्त्वपूर्ण राजकीय, तात्विक किंवा आर्थिक फरकांना तोंड देण्याची क्षमता इथरियम प्रशासनाच्या यशात मोठी भूमिका बजावते. पर्यायी काटा काढण्याच्या क्षमतेशिवाय लढाई चालू होती, ज्यांनी शेवटी इथरियम क्लासिक तयार केला त्यांच्यासाठी अनिच्छेने सहभाग घेणे आणि इथरियमचे यश कसे दिसते याची वाढती भिन्न दृष्टी.
+
+<Divider />
+
+## बीकन चेन गव्हर्नन्स {#beacon-chain}
+
+इथरियम गव्हर्नन्स प्रक्रिया मोकळेपणा आणि सर्वसमावेशकतेसाठी गती आणि कार्यक्षमता कमी करते. बीकन साखळीच्या विकासाला गती देण्यासाठी, ते प्रूफ-ऑफ-वर्क इथरियम नेटवर्कपासून स्वतंत्रपणे लॉन्च केले गेले आणि स्वतःच्या शासन पद्धतींचे पालन केले.
+
+स्पेसिफिकेशन आणि डेव्हलपमेंट अंमलबजावणी नेहमीच पूर्णपणे मुक्त स्त्रोत असताना, वर वर्णन केलेल्या अद्यतनांचा प्रस्ताव देण्यासाठी वापरल्या जाणाऱ्या औपचारिक प्रक्रियांचा वापर केला गेला नाही. यामुळे संशोधक आणि अंमलबजावणी करणाऱ्यांनी बदल निर्दिष्ट केले आणि त्यावर लवकर सहमती दिली.
+
+15 सप्टेंबर 2022 रोजी जेव्हा बीकन चेन Ethereum एक्झिक्यूशन लेअरमध्ये विलीन झाली, तेव्हा [पॅरिस नेटवर्क अपग्रेडचा](/ethereum-forks/#paris) भाग म्हणून द मर्ज पूर्ण झाले. [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675) हा प्रस्ताव 'लास्ट कॉल' वरून 'फायनल' मध्ये बदलण्यात आला, ज्यामुळे प्रूफ-ऑफ-स्टेकमध्ये संक्रमण पूर्ण झाले.
+
+<ButtonLink href="/roadmap/merge/">
+  द मर्जवर अधिक
+</ButtonLink>
+
+<Divider />
+
+## मी कसे सहभागी होऊ शकतो? सहभागी व्हा {#get-involved}
+
+- [EIP प्रस्तावित करा](/eips/#participate)
+- [सध्याच्या प्रस्तावांवर चर्चा करा](https://ethereum-magicians.org/)
+- [R&D चर्चेत सहभागी व्हा](https://ethresear.ch/)
+- [Ethereum R&D डिस्कॉर्डमध्ये सामील व्हा](https://discord.gg/mncqtgVSVw)
+- [नोड चालवा](/developers/docs/nodes-and-clients/run-a-node/)
+- [क्लायंट डेव्हलपमेंटमध्ये योगदान द्या](/developers/docs/nodes-and-clients/#execution-clients)
+- [कोअर डेव्हलपर अप्रेंटिसशिप प्रोग्राम](https://blog.ethereum.org/2021/09/06/core-dev-apprenticeship-second-cohort/)
+
+## पुढील वाचन {#further-reading}
+
+इथरियममधील प्रशासन कठोरपणे परिभाषित केलेले नाही. विविध समुदायातील सहभागींचे याविषयी विविध दृष्टिकोन आहेत. त्यापैकी काही येथे आहेत:
+
+- [ब्लॉकचेन गव्हर्नन्सवरील नोट्स](https://vitalik.eth.limo/general/2017/12/17/voting.html) - _विटालिक बुटेरिन_
+- [Ethereum गव्हर्नन्स कसे कार्य करते?](https://cryptotesters.com/blog/ethereum-governance) – _Cryptotesters_
+- [Ethereum गव्हर्नन्स कसे कार्य करते](https://medium.com/coinmonks/how-ethereum-governance-works-71856426b63a) – _Micah Zoltu_
+- [Ethereum कोअर डेव्हलपर म्हणजे काय?](https://hudsonjameson.com/2020-06-22-what-is-an-ethereum-core-developer/) - _Hudson Jameson_
+- [गव्हर्नन्स, भाग 2: प्लुटोक्रेसी अजूनही वाईट आहे](https://vitalik.eth.limo/general/2018/03/28/plutocracy.html) - _विटालिक बुटेरिन_
+- [कॉइन व्होटिंग गव्हर्नन्सच्या पलीकडे जाणे](https://vitalik.eth.limo/general/2021/08/16/voting3.html) - _विटालिक बुटेरिन_
+- [ब्लॉकचेन गव्हर्नन्स समजून घेणे](https://web.archive.org/web/20250124192731/https://research.2077.xyz/understanding-blockchain-governance) - _2077 Research_
+- [The Ethereum Government](https://www.galaxy.com/insights/research/ethereum-governance/) - _Christine Kim_
diff --git a/public/content/translations/mr/guides/how-to-create-an-ethereum-account/index.md b/public/content/translations/mr/guides/how-to-create-an-ethereum-account/index.md
new file mode 100644
index 00000000000..2128a390187
--- /dev/null
+++ b/public/content/translations/mr/guides/how-to-create-an-ethereum-account/index.md
@@ -0,0 +1,75 @@
+---
+title: "अथेरम खाते \"तयार\" कसे करावे"
+description: "वॉलेट वापरून Ethereum खाते तयार कसे करावे याचे मार्गदर्शन."
+lang: mr
+---
+
+# अथेरम खाते कसे तयार करावे
+
+**कोणीही विनामूल्य Ethereum खाते तयार करू शकतो. तुम्हाला फक्त क्रिप्टो वॉलेट ॲप इंस्टॉल करावे लागेल.** वॉलेट्स तुमचे Ethereum खाते तयार करतात आणि जतन करतात. ते व्यवहार पाठवू शकतात, शिल्लक तपासू शकतात आणि तुम्हाला Ethereum वर तयार केलेल्या इतर ॲप्सशी कनेक्ट करू शकतात.
+
+वॉलेटसह तुम्ही कोणत्याही टोकन एक्सचेंज, गेम्स, [NFT](/glossary/#nft) मार्केटप्लेसेसवर त्वरित लॉग इन करू शकता. कोणत्याही वयक्तिक नोंदणीची गरज नाही, Ethereum वर तयार केलेल्या सर्व ॲप्ससाठी एक खाते सामायिक केले आहे.
+
+## पायरी 1: वॉलेट निवडा
+
+वॉलेट हे एक ॲप आहे जे तुम्हाला तुमचे Ethereum खाते व्यवस्थापित करण्यास मदत करते. निवडण्यासाठी डझनभर वेगवेगळे वॉलेट्स आहेत: मोबाइल, डेस्कटॉप किंवा ब्राउझर एक्सटेन्शन.
+
+<ButtonLink href="/wallets/find-wallet/">
+  वॉलेट्सची यादी
+</ButtonLink>
+
+तुम्ही नवीन असाल, तर तुम्ही "find a wallet" पेजवर “New to crypto” फिल्टर निवडू शकता, जेणेकरून तुम्हाला नवशिक्यांसाठी योग्य आणि सर्व आवश्यक वैशिष्ट्ये असलेले वॉलेट्स ओळखता येतील.
+
+![‘find a wallet’ पेजवरील फिल्टर निवड](./wallet-box.png)
+
+तुमच्या गरजा पूर्ण करण्यासाठी इतर प्रोफाइल फिल्टर्स देखील आहेत. ही सामान्यतः वापरल्या जाणाऱ्या वॉलेट्सची उदाहरणे आहेत - तुम्ही कोणत्याही सॉफ्टवेअरवर विश्वास ठेवण्यापूर्वी स्वतःचे संशोधन केले पाहिजे.
+
+## पायरी 2: तुमचे वॉलेट ॲप डाउनलोड आणि इंस्टॉल करा
+
+तुम्ही एकदा विशिष्ट वॉलेट ठरवल्यानंतर, त्यांच्या अधिकृत वेबसाइट किंवा ॲप स्टोअरला भेट देऊन ते डाउनलोड आणि इंस्टॉल करा. ते सर्व विनामूल्य असले पाहिजेत.
+
+## पायरी 3: ॲप उघडा आणि तुमचे Ethereum खाते तयार करा
+
+जेव्हा तुम्ही पहिल्यांदा तुमचे नवीन वॉलेट उघडता, तेव्हा तुम्हाला नवीन खाते तयार करणे किंवा विद्यमान खाते इम्पोर्ट करणे यापैकी एक निवडण्यास सांगितले जाऊ शकते. नवीन खाते तयार करण्यावर क्लिक करा. **ही ती पायरी आहे ज्या दरम्यान वॉलेट सॉफ्टवेअर तुमचे Ethereum खाते जनरेट करते.**
+
+## पायरी 4: तुमचा रिकव्हरी फ्रेज साठवा
+
+काही ॲप्स तुम्हाला एक गुप्त "रिकव्हरी फ्रेज" (ज्याला "सीड फ्रेज" किंवा "निमोनिक" असेही म्हणतात) सेव्ह करण्यास सांगतील. हा फ्रेज सुरक्षित ठेवणे अत्यंत महत्त्वाचे आहे! याचा उपयोग तुमचे Ethereum खाते जनरेट करण्यासाठी होतो आणि व्यवहार सबमिट करण्यासाठी देखील याचा वापर केला जाऊ शकतो.
+
+**ज्या व्यक्तीला हा फ्रेज माहीत आहे, ती सर्व निधीवर नियंत्रण मिळवू शकते.** हे कोणाशीही शेअर करू नका. या फ्रेजमध्ये 12 ते 24 यादृच्छिकपणे जनरेट केलेले शब्द असावेत (शब्दांचा क्रम महत्त्वाचा आहे).
+
+<div>
+<Alert variant="update">
+<AlertEmoji text=":eyes:"/>
+<AlertContent className="flex-row justify-between items-center">
+  <div><b>वॉलेट इंस्टॉल केले आहे का?</b><br/>ते कसे वापरायचे ते शिका.</div>
+  <ButtonLink href="/guides/how-to-use-a-wallet">
+    वॉलेट कसे वापरावे
+  </ButtonLink>
+</AlertContent>
+</Alert>
+</div>
+
+इतर मार्गदर्शकांमध्ये स्वारस्य आहे का? आमचे पहा: [पायरी-पायरीने मार्गदर्शक](/guides/)
+
+## वारंवार विचारले जाणारे प्रश्न
+
+### माझे वॉलेट आणि माझे Ethereum खाते एकच आहे का?
+
+नाही. वॉलेट हे एक व्यवस्थापन साधन आहे जे तुम्हाला खाती व्यवस्थापित करण्यास मदत करते. एकच वॉलेट अनेक खात्यांमध्ये प्रवेश करू शकते, आणि एकाच खात्यात अनेक वॉलेट्सद्वारे प्रवेश केला जाऊ शकतो. रिकव्हरी फ्रेजचा उपयोग खाती तयार करण्यासाठी केला जातो आणि तो मालमत्ता व्यवस्थापित करण्यासाठी वॉलेट ॲपला परवानगी देतो.
+
+### मी Ethereum ॲड्रेसवर बिटकॉइन, किंवा Bitcoin ॲड्रेसवर ईथर पाठवू शकतो का?
+
+नाही, तुम्ही असे करू शकत नाही. बिटकॉइन आणि ईथर दोन वेगळ्या नेटवर्क्सवर (म्हणजे, वेगवेगळ्या ब्लॉकचेन्सवर) अस्तित्वात आहेत, प्रत्येकाचे स्वतःचे बुककीपिंग आणि ॲड्रेस स्वरूप आहेत. दोन भिन्न नेटवर्क जोडण्याचे विविध प्रयत्न झाले आहेत, ज्यापैकी सर्वात सक्रिय सध्या [Wrapped Bitcoin किंवा WBTC](https://www.bitcoin.com/get-started/what-is-wbtc/) आहे. हे एक समर्थन नाही, कारण WBTC हे एक कस्टोडियल सोल्यूशन आहे (म्हणजे लोकांचा एकच गट काही महत्त्वपूर्ण कार्ये नियंत्रित करतो) आणि ते येथे फक्त माहितीच्या उद्देशाने प्रदान केले आहे.
+
+### जर माझ्याकडे ETH पत्ता असेल, तर माझ्याकडे इतर ब्लॉकचेनवरही तोच पत्ता असतो का?
+
+तुम्ही तोच [ॲड्रेस](/glossary/#address) Ethereum सारखे मूळ सॉफ्टवेअर वापरणाऱ्या सर्व ब्लॉकचेन्सवर (ज्यांना 'EVM-सुसंगत' म्हणून ओळखले जाते) वापरू शकता. ही [सूची](https://chainlist.org/) तुम्हाला दाखवेल की तुम्ही कोणत्या ब्लॉकचेनवर समान पत्ता वापरू शकता. Bitcoin सारखे काही ब्लॉकचेन, नेटवर्क नियमांचा पूर्णपणे वेगळा संच लागू करतात आणि तुम्हाला वेगळ्या स्वरूपासह वेगळ्या पत्त्याची आवश्यकता असेल. जर तुमच्याकडे स्मार्ट कॉन्ट्रॅक्ट वॉलेट असेल, तर कोणत्या ब्लॉकचेन समर्थित आहेत याबद्दल अधिक माहितीसाठी तुम्ही त्याच्या उत्पादनाची वेबसाइट तपासावी, कारण सहसा त्यांची व्याप्ती मर्यादित परंतु अधिक सुरक्षित असते.
+
+### एक्स्चेंजवर माझे फंड ठेवण्यापेक्षा माझे स्वतःचे वॉलेट असणे अधिक सुरक्षित आहे का?
+
+तुमचे स्वतःचे वॉलेट असणे म्हणजे तुम्ही तुमच्या मालमत्तेच्या सुरक्षिततेची जबाबदारी घेता. दुर्दैवाने, अयशस्वी एक्सचेंजची अनेक उदाहरणे आहेत ज्यांनी त्यांच्या ग्राहकांचे पैसे गमावले. वॉलेट (रिकव्हरी फ्रेजसह) बाळगल्याने तुमची मालमत्ता ठेवण्यासाठी एखाद्या संस्थेवर विश्वास ठेवण्याशी संबंधित धोका दूर होतो. तथापि, तुम्हाला ते स्वतःच सुरक्षित ठेवावे लागेल आणि फिशिंग घोटाळे, चुकून व्यवहार मंजूर करणे किंवा रिकव्हरी फ्रेज उघड करणे, बनावट वेबसाइट्सशी संवाद साधणे आणि इतर स्व-ताब्यातील धोके टाळावे लागतील. धोके आणि फायदे वेगवेगळे आहेत.
+
+### जर मी माझा फोन/हार्डवेअर वॉलेट गमावले, तर गमावलेला निधी परत मिळवण्यासाठी मला पुन्हा तेच वॉलेट ॲप वापरण्याची गरज आहे का?
+
+नाही, तुम्ही वेगळे वॉलेट वापरू शकता. जोपर्यंत तुमच्याकडे सीड फ्रेज आहे, तोपर्यंत तुम्ही तो बहुतेक वॉलेट्समध्ये टाकू शकता आणि ते तुमचे खाते पुनर्संचयित करतील. तुम्हाला असे करण्याची कधी गरज पडल्यास सावधगिरी बाळगा: तुमचे वॉलेट रिकव्हर करताना तुम्ही इंटरनेटशी कनेक्ट केलेले नाही याची खात्री करणे उत्तम आहे, जेणेकरून तुमचा सीड फ्रेज चुकून लीक होणार नाही. रिकव्हरी फ्रेजशिवाय गमावलेला निधी परत मिळवणे अनेकदा अशक्य असते.
diff --git a/public/content/translations/mr/guides/how-to-id-scam-tokens/index.md b/public/content/translations/mr/guides/how-to-id-scam-tokens/index.md
new file mode 100644
index 00000000000..f4d4770d567
--- /dev/null
+++ b/public/content/translations/mr/guides/how-to-id-scam-tokens/index.md
@@ -0,0 +1,94 @@
+---
+title: "स्कॅम टोकन्स कसे ओळखावे"
+description: "स्कॅम टोकन्स समजून घेणे, ते स्वतःला वैध कसे भासवतात आणि त्यांना कसे टाळावे."
+lang: mr
+---
+
+# स्कॅम टोकन्स कसे ओळखावे {#identify-scam-tokens}
+
+Ethereum च्या सर्वात सामान्य उपयोगांपैकी एक म्हणजे एखाद्या गटाने एक ट्रेडेबल टोकन तयार करणे, एका अर्थाने त्यांचे स्वतःचे चलन. हे टोकन्स सामान्यतः एका मानकाचे पालन करतात, [ERC-20](/developers/docs/standards/tokens/erc-20/). तथापि, जिथे कुठे मूल्य आणणारी वैध उपयोग-प्रकरणे आहेत, तिथे असे गुन्हेगार देखील आहेत जे ते मूल्य स्वतःसाठी चोरण्याचा प्रयत्न करतात.
+
+ते तुमची फसवणूक करू शकतील असे दोन मार्ग आहेत:
+
+- **तुम्हाला स्कॅम टोकन विकणे**, जे तुम्हाला खरेदी करायच्या असलेल्या वैध टोकनसारखे दिसू शकते, परंतु ते स्कॅमर्सद्वारे जारी केलेले असते आणि त्याचे काहीही मूल्य नसते.
+- **खराब व्यवहारांवर सही करण्यासाठी तुम्हाला फसवणे**, सहसा तुम्हाला त्यांच्या स्वतःच्या युझर इंटरफेसवर निर्देशित करून. ते तुम्हाला तुमच्या ERC-20 टोकन्सवर त्यांच्या कॉन्ट्रॅक्ट्सना भत्ता देण्यासाठी प्रवृत्त करू शकतात, संवेदनशील माहिती उघड करणे ज्यामुळे त्यांना तुमच्या मालमत्तेत प्रवेश मिळतो, इत्यादी. हे युझर इंटरफेस प्रामाणिक साइट्सचे जवळजवळ अचूक क्लोन असू शकतात, परंतु त्यात छुप्या युक्त्या असतात.
+
+स्कॅम टोकन्स काय आहेत आणि ते कसे ओळखावे हे स्पष्ट करण्यासाठी, आपण त्यापैकी एका उदाहरणाकडे पाहणार आहोत: [`wARB`](https://eth.blockscout.com/token/0xB047c8032b99841713b8E3872F06cF32beb27b82). हे टोकन वैध [`ARB`](https://eth.blockscout.com/address/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1) टोकनसारखे दिसण्याचा प्रयत्न करते.
+
+<ExpandableCard
+title="ARB काय आहे?"
+contentPreview=''>
+
+Arbitrum ही एक संस्था आहे जी [optimistic rollups](/developers/docs/scaling/optimistic-rollups/) विकसित आणि व्यवस्थापित करते. सुरुवातीला, Arbitrum ही एक नफा-कमावणारी कंपनी म्हणून संघटित झाली होती, परंतु नंतर तिने विकेंद्रीकरणासाठी पावले उचलली. त्या प्रक्रियेचा एक भाग म्हणून, त्यांनी एक ट्रेडेबल [governance token](/dao/#token-based-membership) जारी केला.
+</ExpandableCard>
+
+<ExpandableCard
+title="स्कॅम टोकनला wARB का म्हटले जाते?"
+contentPreview=''>
+
+Ethereum मध्ये एक प्रथा आहे की जेव्हा एखादी मालमत्ता ERC-20 अनुरूप नसते तेव्हा आम्ही तिची एक "रॅप्ड" आवृत्ती तयार करतो जिचे नाव "w" ने सुरू होते. म्हणून, उदाहरणार्थ, आमच्याकडे bitcoin साठी wBTC आणि <a href="https://cointelegraph.com/news/what-is-wrapped-ethereum-weth-and-how-does-it-work">ether साठी wETH</a> आहे.
+
+Ethereum वर आधीपासूनच असलेल्या ERC-20 टोकनची रॅप्ड आवृत्ती तयार करण्यात काही अर्थ नाही, परंतु स्कॅमर मूळ वास्तवाऐवजी वैधतेच्या दिसण्यावर अवलंबून असतात.
+</ExpandableCard>
+
+## स्कॅम टोकन्स कसे काम करतात? {#how-do-scam-tokens-work}
+
+Ethereum चा संपूर्ण उद्देश विकेंद्रीकरण आहे. याचा अर्थ असा की अशी कोणतीही केंद्रीय संस्था नाही जी तुमची मालमत्ता जप्त करू शकेल किंवा तुम्हाला स्मार्ट कॉन्ट्रॅक्ट तैनात करण्यापासून रोखू शकेल. परंतु याचा अर्थ असाही होतो की स्कॅमर त्यांच्या इच्छेनुसार कोणताही स्मार्ट कॉन्ट्रॅक्ट तैनात करू शकतात.
+
+<ExpandableCard
+title="स्मार्ट कॉन्ट्रॅक्ट्स काय आहेत?"
+contentPreview=''>
+
+[स्मार्ट कॉन्ट्रॅक्ट्स](/developers/docs/smart-contracts/) हे असे प्रोग्राम्स आहेत जे Ethereum ब्लॉकचेनवर चालतात. उदाहरणार्थ, प्रत्येक ERC-20 टोकन एक स्मार्ट कॉन्ट्रॅक्ट म्हणून लागू केले जाते.
+</ExpandableCard>
+
+विशेषतः, Arbitrum ने एक कॉन्ट्रॅक्ट तैनात केला आहे जो `ARB` हे चिन्ह वापरतो. परंतु ते इतर लोकांनाही तेच चिन्ह किंवा तत्सम चिन्ह वापरणारे कॉन्ट्रॅक्ट तैनात करण्यापासून थांबवत नाही. जो कोणी कॉन्ट्रॅक्ट लिहितो त्याला कॉन्ट्रॅक्ट काय करेल हे ठरवण्याचा हक्क मिळतो.
+
+## वैध दिसणे {#appearing-legitimate}
+
+स्कॅम टोकन निर्माते वैध दिसण्यासाठी अनेक युक्त्या वापरतात.
+
+- **वैध नाव आणि चिन्ह**. आधी उल्लेख केल्याप्रमाणे, ERC-20 कॉन्ट्रॅक्ट्सचे नाव आणि चिन्ह इतर ERC-20 कॉन्ट्रॅक्ट्ससारखेच असू शकते. तुम्ही सुरक्षेसाठी त्या फील्ड्सवर अवलंबून राहू शकत नाही.
+
+- **वैध मालक**. स्कॅम टोकन्स अनेकदा अशा ॲड्रेसेसवर लक्षणीय शिल्लक (significant balances) एअरड्रॉप करतात, जे खऱ्या टोकनचे वैध धारक असण्याची अपेक्षा असते.
+
+  उदाहरणार्थ, `wARB` कडे पुन्हा पाहूया. [सुमारे १६% टोकन्स](https://eth.blockscout.com/token/0xb047c8032b99841713b8E3872F06cF32beb27b82?tab=holders) अशा एका ॲड्रेसद्वारे ठेवलेले आहेत ज्याचा सार्वजनिक टॅग [Arbitrum Foundation: Deployer](https://eth.blockscout.com/address/0x1C8db745ABe3C8162119b9Ef2c13864Cd1FDD72F) आहे. हा _खोटा_ ॲड्रेस नाही, हा खरोखरच तो ॲड्रेस आहे ज्याने [Ethereum mainnet वर खरा ARB कॉन्ट्रॅक्ट तैनात केला](https://eth.blockscout.com/tx/0x242b50ab4fe9896cb0439cfe6e2321d23feede7eeceb31aa2dbb46fc06ed2670).
+
+  कारण एका ॲड्रेसची ERC-20 शिल्लक ही ERC-20 कॉन्ट्रॅक्टच्या स्टोरेजचा भाग असते, त्यामुळे कॉन्ट्रॅक्ट डेव्हलपरच्या इच्छेनुसार ती काहीही निर्दिष्ट केली जाऊ शकते. एखाद्या कॉन्ट्रॅक्टसाठी हस्तांतरण प्रतिबंधित करणे देखील शक्य आहे जेणेकरून वैध वापरकर्ते त्या स्कॅम टोकन्समधून सुटका मिळवू शकणार नाहीत.
+
+- **वैध हस्तांतरण**. _वैध मालक इतरांना स्कॅम टोकन हस्तांतरित करण्यासाठी पैसे देणार नाहीत, त्यामुळे जर हस्तांतरण होत असेल तर ते वैध असले पाहिजे, बरोबर?_ **चूक**. `Transfer` इव्हेंट्स ERC-20 कॉन्ट्रॅक्टद्वारे तयार केले जातात. एक स्कॅमर सहजपणे कॉन्ट्रॅक्ट अशा प्रकारे लिहू शकतो की तो त्या क्रिया निर्माण करेल.
+
+## स्कॅमी वेबसाइट्स {#websites}
+
+स्कॅमर्स खूप खात्रीशीर वेबसाइट्स देखील तयार करू शकतात, कधीकधी तर सारख्याच UI सह अस्सल साइट्सचे अचूक क्लोन देखील, परंतु त्यात सूक्ष्म युक्त्या असतात. उदाहरणार्थ बाह्य लिंक्स ज्या वैध वाटतात पण प्रत्यक्षात वापरकर्त्याला बाह्य स्कॅम साईटवर पाठवतात, किंवा चुकीच्या सूचना ज्या वापरकर्त्याला त्यांच्या कीज उघड करण्यास किंवा हल्लेखोराच्या ॲड्रेसवर निधी पाठवण्यासाठी मार्गदर्शन करतात.
+
+हे टाळण्यासाठी सर्वोत्तम सराव म्हणजे तुम्ही भेट देत असलेल्या साइट्ससाठी URL काळजीपूर्वक तपासणे आणि तुमच्या बुकमार्कमध्ये ज्ञात अस्सल साइट्ससाठी ॲड्रेस सेव्ह करणे. त्यानंतर, तुम्ही चुकून स्पेलिंगच्या चुका न करता किंवा बाह्य लिंक्सवर अवलंबून न राहता तुमच्या बुकमार्क्सद्वारे खऱ्या साइटवर प्रवेश करू शकता.
+
+## तुम्ही स्वतःचे संरक्षण कसे करू शकता? {#protect-yourself}
+
+1. **कॉन्ट्रॅक्ट ॲड्रेस तपासा**. वैध टोकन्स वैध संस्थांकडून येतात आणि तुम्ही संस्थेच्या वेबसाइटवर कॉन्ट्रॅक्ट ॲड्रेस पाहू शकता. उदाहरणार्थ, [`ARB` साठी तुम्ही वैध ॲड्रेस येथे पाहू शकता](https://docs.arbitrum.foundation/deployment-addresses#token).
+
+2. **खऱ्या टोकन्समध्ये तरलता असते**. दुसरा पर्याय म्हणजे [Uniswap](https://uniswap.org/) वरील लिक्विडिटी पूलचा आकार पाहणे, जो सर्वात सामान्य टोकन स्वॅपिंग प्रोटोकॉलपैकी एक आहे. हा प्रोटोकॉल लिक्विडिटी पूल्स वापरून काम करतो, ज्यात गुंतवणूकदार ट्रेडिंग शुल्कातून परताव्याच्या आशेने त्यांचे टोकन्स जमा करतात.
+
+स्कॅम टोकन्समध्ये सहसा खूप लहान लिक्विडिटी पूल्स असतात, जर असतील तर, कारण स्कॅमर्सना खरी मालमत्ता धोक्यात घालायची नसते. उदाहरणार्थ, `ARB`/`ETH` Uniswap पूलमध्ये सुमारे एक दशलक्ष डॉलर्स आहेत ([अद्ययावत मूल्यासाठी येथे पहा](https://app.uniswap.org/explore#/pools/0x755e5a186f0469583bd2e80d1216e02ab88ec6ca)) आणि थोड्या प्रमाणात खरेदी किंवा विक्री केल्याने किंमत बदलणार नाही:
+
+![एक वैध टोकन खरेदी करणे](./uniswap-real.png)
+
+परंतु जेव्हा तुम्ही स्कॅम टोकन `wARB` खरेदी करण्याचा प्रयत्न करता, तेव्हा अगदी लहान खरेदीमुळेही किंमत ९०% पेक्षा जास्त बदलेल:
+
+![एक स्कॅम टोकन खरेदी करणे](./uniswap-scam.png)
+
+हा आणखी एक पुरावा आहे जो आपल्याला दर्शवितो की `wARB` हे वैध टोकन असण्याची शक्यता नाही.
+
+3. **Etherscan मध्ये पहा**. बरेच स्कॅम टोकन्स समुदायाद्वारे आधीच ओळखले गेले आहेत आणि त्यांची तक्रार केली गेली आहे. असे टोकन्स [Etherscan मध्ये चिन्हांकित केले जातात](https://info.etherscan.com/etherscan-token-reputation/). जरी Etherscan सत्याचा अधिकृत स्त्रोत नसला तरी (विकेंद्रित नेटवर्क्सचे स्वरूप असे आहे की वैधतेसाठी कोणताही अधिकृत स्त्रोत असू शकत नाही), Etherscan द्वारे स्कॅम म्हणून ओळखले जाणारे टोकन्स स्कॅम असण्याची शक्यता आहे.
+
+   ![Etherscan मधील स्कॅम टोकन](./etherscan-scam.png)
+
+## निष्कर्ष {#conclusion}
+
+जोपर्यंत जगात मूल्य आहे, तोपर्यंत असे स्कॅमर्स असणारच आहेत जे ते स्वतःसाठी चोरण्याचा प्रयत्न करतील आणि विकेंद्रीकृत जगात तुमच्या स्वतःशिवाय तुमचे संरक्षण करण्यासाठी कोणीही नाही. आशा आहे की, तुम्हाला हे मुद्दे आठवतील जे वैध टोकन्सना स्कॅमपासून वेगळे करण्यास मदत करतील:
+
+- स्कॅम टोकन्स वैध टोकन्सचे सोंग घेतात, ते समान नाव, चिन्ह इत्यादी वापरू शकतात.
+- स्कॅम टोकन्स समान कॉन्ट्रॅक्ट ॲड्रेस वापरू _शकत नाहीत_.
+- वैध टोकनच्या ॲड्रेससाठी सर्वोत्तम स्त्रोत म्हणजे ती संस्था ज्याचा तो टोकन आहे.
+- ते शक्य नसल्यास, तुम्ही [Uniswap](https://app.uniswap.org/#/swap) आणि [Blockscout](https://eth.blockscout.com/) सारखे लोकप्रिय, विश्वसनीय ॲप्लिकेशन्स वापरू शकता.