diff --git a/public/content/translations/mr/developers/docs/smart-contracts/anatomy/index.md b/public/content/translations/mr/developers/docs/smart-contracts/anatomy/index.md new file mode 100644 index 00000000000..ec1395c5960 --- /dev/null +++ b/public/content/translations/mr/developers/docs/smart-contracts/anatomy/index.md @@ -0,0 +1,658 @@ +--- +title: "स्मार्ट करारांची रचना" +description: "स्मार्ट कराराच्या रचनेचा सखोल अभ्यास – फंक्शन्स, डेटा आणि व्हेरिएबल्स." +lang: mr +--- + +स्मार्ट करार हा एक प्रोग्राम आहे जो Ethereum वरील एका पत्त्यावर (address) चालतो. ते डेटा आणि फंक्शन्सचे बनलेले असतात जे व्यवहार (transaction) प्राप्त झाल्यावर कार्यान्वित होऊ शकतात. स्मार्ट करार कशाने बनलेला आहे याचा आढावा येथे आहे. + +## पूर्वतयारी {#prerequisites} + +आपण प्रथम [स्मार्ट करार](/developers/docs/smart-contracts/) बद्दल वाचले असल्याची खात्री करा. हा दस्तऐवज असे गृहीत धरतो की आपण आधीच JavaScript किंवा Python सारख्या प्रोग्रामिंग भाषांशी परिचित आहात. + +## डेटा {#data} + +कोणताही करार डेटा एका स्थानावर नियुक्त करणे आवश्यक आहे: एकतर `storage` किंवा `memory` मध्ये. स्मार्ट करारामध्ये स्टोरेजमध्ये बदल करणे महाग आहे, त्यामुळे तुमचा डेटा कोठे राहावा याचा विचार करणे आवश्यक आहे. + +### स्टोरेज {#storage} + +पर्सिस्टंट डेटाला स्टोरेज म्हणून संबोधले जाते आणि ते स्टेट व्हेरिएबल्सद्वारे दर्शविले जाते. ही मूल्ये कायमस्वरूपी ब्लॉकचेनवर संग्रहित केली जातात. तुम्ही प्रकार घोषित करणे आवश्यक आहे जेणेकरून करार संकलित (compile) झाल्यावर त्याला ब्लॉकचेनवर किती स्टोरेजची आवश्यकता आहे याचा मागोवा ठेवू शकेल. + +```solidity +// Solidity example +contract SimpleStorage { + uint storedData; // State variable + // ... +} +``` + +```python +# Vyper example +storedData: int128 +``` + +जर तुम्ही आधीच ऑब्जेक्ट-ओरिएंटेड भाषा प्रोग्राम केल्या असतील, तर तुम्ही बहुतांश प्रकारांशी परिचित असाल. तथापि, जर तुम्ही Ethereum विकासासाठी नवीन असाल तर `address` तुमच्यासाठी नवीन असावा. + +एक `address` प्रकार Ethereum पत्ता धारण करू शकतो जो 20 बाइट्स किंवा 160 बिट्सच्या समान असतो. हे अग्रगण्य 0x सह हेक्साडेसिमल नोटेशनमध्ये परत येते. + +इतर प्रकारांमध्ये हे समाविष्ट आहे: + +- बुलियन +- पूर्णांक +- फिक्स्ड पॉइंट नंबर्स +- निश्चित-आकाराचे बाइट अॅरे +- डायनॅमिक आकाराचे बाइट अॅरे +- रेशनल आणि पूर्णांक लिटरल्स +- स्ट्रिंग लिटरल्स +- हेक्साडेसिमल लिटरल्स +- एनम्स + +अधिक स्पष्टीकरणासाठी, डॉक्सवर एक नजर टाका: + +- [Vyper प्रकार पहा](https://docs.vyperlang.org/en/v0.1.0-beta.6/types.html#value-types) +- [Solidity प्रकार पहा](https://docs.soliditylang.org/en/latest/types.html#value-types) + +### मेमरी {#memory} + +जी मूल्ये केवळ करार फंक्शनच्या अंमलबजावणीच्या जीवनकाळासाठी संग्रहित केली जातात त्यांना मेमरी व्हेरिएबल्स म्हणतात. हे ब्लॉकचेनवर कायमस्वरूपी संग्रहित नसल्यामुळे, ते वापरण्यासाठी खूप स्वस्त आहेत. + +EVM डेटा (स्टोरेज, मेमरी आणि स्टॅक) कसे संग्रहित करते याबद्दल [Solidity डॉक्स](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#storage-memory-and-the-stack) मध्ये अधिक जाणून घ्या. + +### एनव्हायरनमेंट व्हेरिएबल्स {#environment-variables} + +आपण आपल्या करारावर परिभाषित केलेल्या व्हेरिएबल्सव्यतिरिक्त, काही विशेष ग्लोबल व्हेरिएबल्स आहेत. ते प्रामुख्याने ब्लॉकचेन किंवा सध्याच्या व्यवहाराबद्दल माहिती प्रदान करण्यासाठी वापरले जातात. + +उदाहरणे: + +| **प्रॉप** | **स्टेट व्हेरिएबल** | **वर्णन** | +| ----------------- | ------------------- | --------------------------------------------- | +| `block.timestamp` | uint256 | सध्याचा ब्लॉक इपॉक टाइमस्टॅम्प | +| `msg.sender` | पत्ता | संदेशाचा प्रेषक (चालू कॉल) | + +## फंक्शन्स {#functions} + +अत्यंत सोप्या भाषेत सांगायचे झाल्यास, फंक्शन्स येणाऱ्या व्यवहारांना प्रतिसाद म्हणून माहिती मिळवू शकतात किंवा सेट करू शकतात. + +फंक्शन कॉलचे दोन प्रकार आहेत: + +- `internal` – हे EVM कॉल तयार करत नाहीत + - अंतर्गत फंक्शन्स आणि स्टेट व्हेरिएबल्सना फक्त अंतर्गतच प्रवेश केला जाऊ शकतो (म्हणजे, चालू करारातून किंवा त्यातून मिळवलेल्या करारांमधून) +- `external` – हे EVM कॉल तयार करतात + - बाह्य फंक्शन्स करार इंटरफेसचा भाग आहेत, याचा अर्थ ते इतर करारांमधून आणि व्यवहारांद्वारे कॉल केले जाऊ शकतात. एक बाह्य फंक्शन `f` अंतर्गत कॉल केले जाऊ शकत नाही (म्हणजे, `f()` कार्य करत नाही, परंतु `this.f()` कार्य करते). + +ते `public` किंवा `private` देखील असू शकतात + +- `public` फंक्शन्स कराराच्या आतून अंतर्गत किंवा संदेशांद्वारे बाह्यरित्या कॉल केले जाऊ शकतात +- `private` फंक्शन्स फक्त त्या करारासाठी दिसतात ज्यात ते परिभाषित केले आहेत आणि व्युत्पन्न करारांमध्ये नाहीत + +फंक्शन्स आणि स्टेट व्हेरिएबल्स दोन्ही सार्वजनिक किंवा खाजगी केले जाऊ शकतात + +करारावरील स्टेट व्हेरिएबल अपडेट करण्यासाठी येथे एक फंक्शन आहे: + +```solidity +// Solidity example +function update_name(string value) public { + dapp_name = value; +} +``` + +- `string` प्रकारचा पॅरामीटर `value` फंक्शनमध्ये पास केला जातो: `update_name` +- हे `सार्वजनिक` म्हणून घोषित केले आहे, म्हणजे कोणीही त्यात प्रवेश करू शकतो +- हे `व्ह्यू` म्हणून घोषित केलेले नाही, त्यामुळे ते कराराची स्थिती सुधारित करू शकते + +### व्ह्यू फंक्शन्स {#view-functions} + +ही फंक्शन्स कराराच्या डेटाच्या स्थितीमध्ये बदल न करण्याचे वचन देतात. सामान्य उदाहरणे म्हणजे "गेटर" फंक्शन्स – उदाहरणार्थ, तुम्ही याचा वापर वापरकर्त्याची शिल्लक मिळवण्यासाठी करू शकता. + +```solidity +// Solidity example +function balanceOf(address _owner) public view returns (uint256 _balance) { + return ownerPizzaCount[_owner]; +} +``` + +```python +dappName: public(string) + +@view +@public +def readName() -> string: + return dappName +``` + +स्टेट सुधारित करणे म्हणजे काय: + +1. स्टेट व्हेरिएबल्समध्ये लिहिणे. +2. [इव्हेंट्स एमिट करणे](https://docs.soliditylang.org/en/v0.7.0/contracts.html#events). +3. [इतर करार तयार करणे](https://docs.soliditylang.org/en/v0.7.0/control-structures.html#creating-contracts). +4. `selfdestruct` वापरणे. +5. कॉलद्वारे इथर पाठवणे. +6. `व्ह्यू` किंवा `प्युअर` म्हणून चिन्हांकित नसलेले कोणतेही फंक्शन कॉल करणे. +7. लो-लेव्हल कॉल्स वापरणे. +8. विशिष्ट ऑपकोड असलेले इनलाइन असेंब्ली वापरणे. + +### कन्स्ट्रक्टर फंक्शन्स {#constructor-functions} + +`constructor` फंक्शन्स फक्त एकदाच कार्यान्वित होतात जेव्हा करार प्रथम तैनात केला जातो. अनेक वर्ग-आधारित प्रोग्रामिंग भाषांमधील `कन्स्ट्रक्टर` प्रमाणे, ही फंक्शन्स अनेकदा स्टेट व्हेरिएबल्सना त्यांच्या निर्दिष्ट मूल्यांमध्ये सुरू करतात. + +```solidity +// Solidity example +// Initializes the contract's data, setting the `owner` +// to the address of the contract creator. +constructor() public { + // All smart contracts rely on external transactions to trigger its functions. + // `msg` is a global variable that includes relevant data on the given transaction, + // such as the address of the sender and the ETH value included in the transaction. + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties + owner = msg.sender; +} +``` + +```python +# Vyper example + +@external +def __init__(_beneficiary: address, _bidding_time: uint256): + self.beneficiary = _beneficiary + self.auctionStart = block.timestamp + self.auctionEnd = self.auctionStart + _bidding_time +``` + +### अंगभूत फंक्शन्स {#built-in-functions} + +आपण आपल्या करारावर परिभाषित केलेल्या व्हेरिएबल्स आणि फंक्शन्स व्यतिरिक्त, काही विशेष अंगभूत फंक्शन्स आहेत. सर्वात स्पष्ट उदाहरण आहे: + +- `address.send()` – Solidity +- `send(address)` – Vyper + +हे करारांना इतर खात्यांवर ETH पाठविण्याची परवानगी देतात. + +## फंक्शन्स लिहिणे {#writing-functions} + +तुमच्या फंक्शनला आवश्यक आहे: + +- पॅरामीटर व्हेरिएबल आणि प्रकार (जर ते पॅरामीटर्स स्वीकारत असेल तर) +- अंतर्गत/बाह्य ची घोषणा +- प्युअर/व्ह्यू/पेएबल ची घोषणा +- रिटर्न्स प्रकार (जर ते मूल्य परत करत असेल तर) + +```solidity +pragma solidity >=0.4.0 <=0.6.0; + +contract ExampleDapp { + string dapp_name; // state variable + + // Called when the contract is deployed and initializes the value + constructor() public { + dapp_name = "My Example dapp"; + } + + // Get Function + function read_name() public view returns(string) { + return dapp_name; + } + + // Set Function + function update_name(string value) public { + dapp_name = value; + } +} +``` + +एक संपूर्ण करार काहीसा असा दिसू शकतो. येथे `कन्स्ट्रक्टर` फंक्शन `dapp_name` व्हेरिएबलसाठी प्रारंभिक मूल्य प्रदान करते. + +## इव्हेंट्स आणि लॉग {#events-and-logs} + +इव्हेंट्स तुमच्या स्मार्ट कराराला तुमच्या फ्रंटएंड किंवा इतर सदस्यत्व घेतलेल्या ॲप्लिकेशन्ससह संवाद साधण्यास सक्षम करतात. एकदा व्यवहार प्रमाणित झाल्यावर आणि ब्लॉकमध्ये जोडला गेल्यावर, स्मार्ट करार इव्हेंट एमिट करू शकतात आणि माहिती लॉग करू शकतात, ज्यावर फ्रंटएंड नंतर प्रक्रिया आणि उपयोग करू शकतो. + +## भाष्य केलेली उदाहरणे {#annotated-examples} + +ही Solidity मध्ये लिहिलेली काही उदाहरणे आहेत. तुम्हाला कोडसोबत खेळायचे असल्यास, तुम्ही [Remix](http://remix.ethereum.org) मध्ये त्यांच्याशी संवाद साधू शकता. + +### हॅलो वर्ल्ड {#hello-world} + +```solidity +// Specifies the version of Solidity, using semantic versioning. +// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +pragma solidity ^0.5.10; + +// Defines a contract named `HelloWorld`. +// A contract is a collection of functions and data (its state). +// Once deployed, a contract resides at a specific address on the Ethereum blockchain. +// Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +contract HelloWorld { + + // Declares a state variable `message` of type `string`. + // State variables are variables whose values are permanently stored in contract storage. + // The keyword `public` makes variables accessible from outside a contract + // and creates a function that other contracts or clients can call to access the value. + string public message; + + // Similar to many class-based object-oriented languages, a constructor is + // a special function that is only executed upon contract creation. + // Constructors are used to initialize the contract's data. + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + constructor(string memory initMessage) public { + // Accepts a string argument `initMessage` and sets the value + // into the contract's `message` storage variable). + message = initMessage; + } + + // A public function that accepts a string argument + // and updates the `message` storage variable. + function update(string memory newMessage) public { + message = newMessage; + } +} +``` + +### टोकन {#token} + +```solidity +pragma solidity ^0.5.10; + +contract Token { + // An `address` is comparable to an email address - it's used to identify an account on Ethereum. + // Addresses can represent a smart contract or an external (user) accounts. + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#address + address public owner; + + // A `mapping` is essentially a hash table data structure. + // This `mapping` assigns an unsigned integer (the token balance) to an address (the token holder). + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types + mapping (address => uint) public balances; + + // Events allow for logging of activity on the blockchain. + // Ethereum clients can listen for events in order to react to contract state changes. + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events + event Transfer(address from, address to, uint amount); + + // Initializes the contract's data, setting the `owner` + // to the address of the contract creator. + constructor() public { + // All smart contracts rely on external transactions to trigger its functions. + // `msg` is a global variable that includes relevant data on the given transaction, + // such as the address of the sender and the ETH value included in the transaction. + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties + owner = msg.sender; + } + + // Creates an amount of new tokens and sends them to an address. + function mint(address receiver, uint amount) public { + // `require` is a control structure used to enforce certain conditions. + // If a `require` statement evaluates to `false`, an exception is triggered, + // which reverts all changes made to the state during the current call. + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions + + // Only the contract owner can call this function + require(msg.sender == owner, "You are not the owner."); + + // Enforces a maximum amount of tokens + require(amount < 1e60, "Maximum issuance exceeded"); + + // Increases the balance of `receiver` by `amount` + balances[receiver] += amount; + } + + // Sends an amount of existing tokens from any caller to an address. + function transfer(address receiver, uint amount) public { + // The sender must have enough tokens to send + require(amount <= balances[msg.sender], "Insufficient balance."); + + // Adjusts token balances of the two addresses + balances[msg.sender] -= amount; + balances[receiver] += amount; + + // Emits the event defined earlier + emit Transfer(msg.sender, receiver, amount); + } +} +``` + +### युनिक डिजिटल मालमत्ता {#unique-digital-asset} + +```solidity +pragma solidity ^0.5.10; + +// Imports symbols from other files into the current contract. +// In this case, a series of helper contracts from OpenZeppelin. +// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files + +import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721.sol"; +import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol"; +import "../node_modules/@openzeppelin/contracts/introspection/ERC165.sol"; +import "../node_modules/@openzeppelin/contracts/math/SafeMath.sol"; + +// The `is` keyword is used to inherit functions and keywords from external contracts. +// In this case, `CryptoPizza` inherits from the `IERC721` and `ERC165` contracts. +// Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance +contract CryptoPizza is IERC721, ERC165 { + // Uses OpenZeppelin's SafeMath library to perform arithmetic operations safely. + // Learn more: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath + using SafeMath for uint256; + + // Constant state variables in Solidity are similar to other languages + // but you must assign from an expression which is constant at compile time. + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables + uint256 constant dnaDigits = 10; + uint256 constant dnaModulus = 10 ** dnaDigits; + bytes4 private constant _ERC721_RECEIVED = 0x150b7a02; + + // Struct types let you define your own type + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs + struct Pizza { + string name; + uint256 dna; + } + + // Creates an empty array of Pizza structs + Pizza[] public pizzas; + + // Mapping from pizza ID to its owner's address + mapping(uint256 => address) public pizzaToOwner; + + // Mapping from owner's address to number of owned token + mapping(address => uint256) public ownerPizzaCount; + + // Mapping from token ID to approved address + mapping(uint256 => address) pizzaApprovals; + + // You can nest mappings, this example maps owner to operator approvals + mapping(address => mapping(address => bool)) private operatorApprovals; + + // Internal function to create a random Pizza from string (name) and DNA + function _createPizza(string memory _name, uint256 _dna) + // The `internal` keyword means this function is only visible + // within this contract and contracts that derive this contract + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters + internal + // `isUnique` is a function modifier that checks if the pizza already exists + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers + isUnique(_name, _dna) + { + // Adds Pizza to array of Pizzas and get id + uint256 id = SafeMath.sub(pizzas.push(Pizza(_name, _dna)), 1); + + // Checks that Pizza owner is the same as current user + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions + + // note that address(0) is the zero address, + // indicating that pizza[id] is not yet allocated to a particular user. + + assert(pizzaToOwner[id] == address(0)); + + // Maps the Pizza to the owner + pizzaToOwner[id] = msg.sender; + ownerPizzaCount[msg.sender] = SafeMath.add( + ownerPizzaCount[msg.sender], + 1 + ); + } + + // Creates a random Pizza from string (name) + function createRandomPizza(string memory _name) public { + uint256 randDna = generateRandomDna(_name, msg.sender); + _createPizza(_name, randDna); + } + + // Generates random DNA from string (name) and address of the owner (creator) + function generateRandomDna(string memory _str, address _owner) + public + // Functions marked as `pure` promise not to read from or modify the state + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions + pure + returns (uint256) + { + // Generates random uint from string (name) + address (owner) + uint256 rand = uint256(keccak256(abi.encodePacked(_str))) + + uint256(_owner); + rand = rand % dnaModulus; + return rand; + } + + // Returns array of Pizzas found by owner + function getPizzasByOwner(address _owner) + public + // Functions marked as `view` promise not to modify state + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions + view + returns (uint256[] memory) + { + // Uses the `memory` storage location to store values only for the + // lifecycle of this function call. + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack + uint256[] memory result = new uint256[](ownerPizzaCount[_owner]); + uint256 counter = 0; + for (uint256 i = 0; i < pizzas.length; i++) { + if (pizzaToOwner[i] == _owner) { + result[counter] = i; + counter++; + } + } + return result; + } + + // Transfers Pizza and ownership to other address + function transferFrom(address _from, address _to, uint256 _pizzaId) public { + require(_from != address(0) && _to != address(0), "Invalid address."); + require(_exists(_pizzaId), "Pizza does not exist."); + require(_from != _to, "Cannot transfer to the same address."); + require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); + + ownerPizzaCount[_to] = SafeMath.add(ownerPizzaCount[_to], 1); + ownerPizzaCount[_from] = SafeMath.sub(ownerPizzaCount[_from], 1); + pizzaToOwner[_pizzaId] = _to; + + // Emits event defined in the imported IERC721 contract + emit Transfer(_from, _to, _pizzaId); + _clearApproval(_to, _pizzaId); + } + + /** + * Safely transfers the ownership of a given token ID to another address + * If the target address is a contract, it must implement `onERC721Received`, + * which is called upon a safe transfer, and return the magic value + * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; + * otherwise, the transfer is reverted. + */ + function safeTransferFrom(address from, address to, uint256 pizzaId) + public + { + // solium-disable-next-line arg-overflow + this.safeTransferFrom(from, to, pizzaId, ""); + } + + /** + * Safely transfers the ownership of a given token ID to another address + * If the target address is a contract, it must implement `onERC721Received`, + * which is called upon a safe transfer, and return the magic value + * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; + * otherwise, the transfer is reverted. + */ + function safeTransferFrom( + address from, + address to, + uint256 pizzaId, + bytes memory _data + ) public { + this.transferFrom(from, to, pizzaId); + require(_checkOnERC721Received(from, to, pizzaId, _data), "Must implement onERC721Received."); + } + + /** + * Internal function to invoke `onERC721Received` on a target address + * The call is not executed if the target address is not a contract + */ + function _checkOnERC721Received( + address from, + address to, + uint256 pizzaId, + bytes memory _data + ) internal returns (bool) { + if (!isContract(to)) { + return true; + } + + bytes4 retval = IERC721Receiver(to).onERC721Received( + msg.sender, + from, + pizzaId, + _data + ); + return (retval == _ERC721_RECEIVED); + } + + // Burns a Pizza - destroys Token completely + // The `external` function modifier means this function is + // part of the contract interface and other contracts can call it + function burn(uint256 _pizzaId) external { + require(msg.sender != address(0), "Invalid address."); + require(_exists(_pizzaId), "Pizza does not exist."); + require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); + + ownerPizzaCount[msg.sender] = SafeMath.sub( + ownerPizzaCount[msg.sender], + 1 + ); + pizzaToOwner[_pizzaId] = address(0); + } + + // Returns count of Pizzas by address + function balanceOf(address _owner) public view returns (uint256 _balance) { + return ownerPizzaCount[_owner]; + } + + // Returns owner of the Pizza found by id + function ownerOf(uint256 _pizzaId) public view returns (address _owner) { + address owner = pizzaToOwner[_pizzaId]; + require(owner != address(0), "Invalid Pizza ID."); + return owner; + } + + // Approves other address to transfer ownership of Pizza + function approve(address _to, uint256 _pizzaId) public { + require(msg.sender == pizzaToOwner[_pizzaId], "Must be the Pizza owner."); + pizzaApprovals[_pizzaId] = _to; + emit Approval(msg.sender, _to, _pizzaId); + } + + // Returns approved address for specific Pizza + function getApproved(uint256 _pizzaId) + public + view + returns (address operator) + { + require(_exists(_pizzaId), "Pizza does not exist."); + return pizzaApprovals[_pizzaId]; + } + + /** + * Private function to clear current approval of a given token ID + * Reverts if the given address is not indeed the owner of the token + */ + function _clearApproval(address owner, uint256 _pizzaId) private { + require(pizzaToOwner[_pizzaId] == owner, "Must be pizza owner."); + require(_exists(_pizzaId), "Pizza does not exist."); + if (pizzaApprovals[_pizzaId] != address(0)) { + pizzaApprovals[_pizzaId] = address(0); + } + } + + /* + * Sets or unsets the approval of a given operator + * An operator is allowed to transfer all tokens of the sender on their behalf + */ + function setApprovalForAll(address to, bool approved) public { + require(to != msg.sender, "Cannot approve own address"); + operatorApprovals[msg.sender][to] = approved; + emit ApprovalForAll(msg.sender, to, approved); + } + + // Tells whether an operator is approved by a given owner + function isApprovedForAll(address owner, address operator) + public + view + returns (bool) + { + return operatorApprovals[owner][operator]; + } + + // Takes ownership of Pizza - only for approved users + function takeOwnership(uint256 _pizzaId) public { + require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); + address owner = this.ownerOf(_pizzaId); + this.transferFrom(owner, msg.sender, _pizzaId); + } + + // Checks if Pizza exists + function _exists(uint256 pizzaId) internal view returns (bool) { + address owner = pizzaToOwner[pizzaId]; + return owner != address(0); + } + + // Checks if address is owner or is approved to transfer Pizza + function _isApprovedOrOwner(address spender, uint256 pizzaId) + internal + view + returns (bool) + { + address owner = pizzaToOwner[pizzaId]; + // Disable solium check because of + // https://github.com/duaraghav8/Solium/issues/175 + // solium-disable-next-line operator-whitespace + return (spender == owner || + this.getApproved(pizzaId) == spender || + this.isApprovedForAll(owner, spender)); + } + + // Check if Pizza is unique and doesn't exist yet + modifier isUnique(string memory _name, uint256 _dna) { + bool result = true; + for (uint256 i = 0; i < pizzas.length; i++) { + if ( + keccak256(abi.encodePacked(pizzas[i].name)) == + keccak256(abi.encodePacked(_name)) && + pizzas[i].dna == _dna + ) { + result = false; + } + } + require(result, "Pizza with such name already exists."); + _; + } + + // Returns whether the target address is a contract + function isContract(address account) internal view returns (bool) { + uint256 size; + // Currently there is no better way to check if there is a contract in an address + // than to check the size of the code at that address. + // See https://ethereum.stackexchange.com/a/14016/36603 + // for more details about how this works. + // TODO Check this again before the Serenity release, because all addresses will be + // contracts then. + // solium-disable-next-line security/no-inline-assembly + assembly { + size := extcodesize(account) + } + return size > 0; + } +} +``` + +## पुढील वाचन {#further-reading} + +स्मार्ट करारांच्या अधिक संपूर्ण विहंगावलोकनासाठी Solidity आणि Vyper चे दस्तऐवजीकरण पहा: + +- [Solidity](https://docs.soliditylang.org/) +- [Vyper](https://docs.vyperlang.org/en/stable/) + +## संबंधित विषय {#related-topics} + +- [स्मार्ट कॉन्ट्रॅक्ट्स](/developers/docs/smart-contracts/) +- [Ethereum व्हर्च्युअल मशीन](/developers/docs/evm/) + +## संबंधित ट्युटोरियल्स {#related-tutorials} + +- [करार आकार मर्यादेशी लढण्यासाठी करार कमी करणे](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– तुमच्या स्मार्ट कराराचा आकार कमी करण्यासाठी काही व्यावहारिक टिप्स._ +- [इव्हेंटसह स्मार्ट करारांमधून डेटा लॉग करणे](/developers/tutorials/logging-events-smart-contracts/) _– स्मार्ट करार इव्हेंटची ओळख आणि डेटा लॉग करण्यासाठी तुम्ही त्यांचा कसा वापर करू शकता._ +- [Solidity वरून इतर करारांशी संवाद साधा](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– विद्यमान करारातून स्मार्ट करार कसा तैनात करायचा आणि त्याच्याशी संवाद कसा साधायचा._ diff --git a/public/content/translations/mr/developers/docs/smart-contracts/compiling/index.md b/public/content/translations/mr/developers/docs/smart-contracts/compiling/index.md new file mode 100644 index 00000000000..3312764f6f4 --- /dev/null +++ b/public/content/translations/mr/developers/docs/smart-contracts/compiling/index.md @@ -0,0 +1,53 @@ +--- +title: "स्मार्ट कॉन्ट्रॅक्ट्स संकलित करणे" +description: "स्मार्ट कॉन्ट्रॅक्ट्स का संकलित करावे लागतात आणि संकलन नेमके काय करते, याचे स्पष्टीकरण." +lang: mr +incomplete: true +--- + +तुम्हाला तुमचा कॉन्ट्रॅक्ट संकलित करण्याची गरज आहे जेणेकरून तुमचे वेब ॲप आणि इथेरियम व्हर्च्युअल मशीन (EVM) ते समजू शकतील. + +## पूर्वतयारी {#prerequisites} + +संकलनाबद्दल वाचण्यापूर्वी, [स्मार्ट कॉन्ट्रॅक्ट्स](/developers/docs/smart-contracts/) आणि [इथेरियम व्हर्च्युअल मशीन](/developers/docs/evm/) यांबद्दलचा आमचा परिचय वाचणे तुम्हाला उपयुक्त वाटू शकते. + +## EVM {#the-evm} + +[EVM](/developers/docs/evm/) ला तुमचा कॉन्ट्रॅक्ट चालवता यावा यासाठी, तो **बाइटकोड** मध्ये असणे आवश्यक आहे. संकलन याचे रूपांतर यात करते: + +```solidity +pragma solidity 0.4.24;\n\ncontract Greeter {\n\n function greet() public view returns (string memory) {\n return \ +``` + +**यात** + +``` +PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH2 0x41 JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCFAE3217 EQ PUSH2 0x46 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH2 0x52 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH2 0x5B PUSH2 0xD6 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP4 DUP2 DUP2 MLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0x9B JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x80 JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0xC8 JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x60 PUSH1 0x40 DUP1 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 PUSH1 0x5 DUP2 MSTORE PUSH1 0x20 ADD PUSH32 0x48656C6C6F000000000000000000000000000000000000000000000000000000 DUP2 MSTORE POP SWAP1 POP SWAP1 JUMP STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 SLT 0xec 0xe 0xf5 0xf8 SLT 0xc7 0x2d STATICCALL ADDRESS SHR 0xdb COINBASE 0xb1 BALANCE 0xe8 0xf8 DUP14 0xda 0xad DUP13 LOG1 0x4c 0xb4 0x26 0xc2 DELEGATECALL PUSH7 0x8994D3E002900 +``` + +यांना **ऑपकोड्स** म्हणतात. EVM ऑपकोड्स ह्या निम्न-स्तरीय सूचना आहेत ज्या इथेरियम व्हर्च्युअल मशीन (EVM) कार्यान्वित करू शकते. प्रत्येक ऑपकोड एक विशिष्ट ऑपरेशन दर्शवतो, जसे की अंकगणितीय ऑपरेशन्स, तार्किक ऑपरेशन्स, डेटा मॅनिप्युलेशन, कंट्रोल फ्लो, इत्यादी. + +[ऑपकोड्सबद्दल अधिक](/developers/docs/evm/opcodes/) + +## वेब ॲप्लिकेशन्स {#web-applications} + +कंपाइलर **ॲप्लिकेशन बायनरी इंटरफेस (ABI)** सुद्धा तयार करतो. तुमच्या ॲप्लिकेशनला कॉन्ट्रॅक्ट समजण्यासाठी आणि त्याची फंक्शन्स कॉल करण्यासाठी तुम्हाला याची गरज असते. + +ABI ही एक JSON फाईल आहे जी तैनात केलेल्या कॉन्ट्रॅक्ट आणि त्याच्या स्मार्ट कॉन्ट्रॅक्ट फंक्शन्सचे वर्णन करते. हे वेब2 आणि वेब3 मधील अंतर कमी करण्यास मदत करते. + +तुम्ही तुमच्या वेब ॲप इंटरफेसमध्ये तुमच्या स्मार्ट कॉन्ट्रॅक्टवर कॉल करू शकावे, यासाठी एक [जावास्क्रिप्ट क्लायंट लायब्ररी](/developers/docs/apis/javascript/) **ABI** वाचते. + +खाली ERC-20 टोकन कॉन्ट्रॅक्टसाठी ABI दिलेला आहे. ERC-20 हे एक टोकन आहे ज्याचा तुम्ही इथेरियमवर व्यापार करू शकता. + +```json +[\n {\n \ +``` + +## पुढील वाचन {#further-reading} + +- [ABI तपशील](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _– सॉलिडिटी_ + +## संबंधित विषय {#related-topics} + +- [जावास्क्रिप्ट क्लायंट लायब्ररी](/developers/docs/apis/javascript/) +- [इथेरियम व्हर्च्युअल मशीन](/developers/docs/evm/) diff --git a/public/content/translations/mr/developers/docs/smart-contracts/composability/index.md b/public/content/translations/mr/developers/docs/smart-contracts/composability/index.md new file mode 100644 index 00000000000..d057b865ee9 --- /dev/null +++ b/public/content/translations/mr/developers/docs/smart-contracts/composability/index.md @@ -0,0 +1,76 @@ +--- +title: "स्मार्ट कॉन्ट्रॅक्ट संयोजनीयता" +description: "विद्यमान घटकांचा पुन्हा वापर करून, जटिल डॅप्स (dapps) तयार करण्यासाठी लेगो ब्लॉक्सप्रमाणे स्मार्ट कॉन्ट्रॅक्ट्स कसे एकत्र केले जाऊ शकतात, हे जाणून घ्या." +lang: mr +incomplete: true +--- + +## एक संक्षिप्त परिचय {#a-brief-introduction} + +स्मार्ट कॉन्ट्रॅक्ट इथेरिअमवर सार्वजनिक आहेत आणि त्यांना मुक्त API म्हणून मानले जाऊ शकते. डॅप डेव्हलपर बनण्यासाठी तुम्हाला तुमचा स्वतःचा स्मार्ट कॉन्ट्रॅक्ट लिहिण्याची गरज नाही, तुम्हाला फक्त त्यांच्याशी कसा संवाद साधायचा हे माहित असणे आवश्यक आहे. उदाहरणार्थ, तुम्ही तुमच्या ॲपमधील सर्व टोकन स्वॅप लॉजिक हाताळण्यासाठी [Uniswap](https://uniswap.exchange/swap) या विकेंद्रित एक्सचेंजचे विद्यमान स्मार्ट कॉन्ट्रॅक्ट्स वापरू शकता – तुम्हाला अगदी सुरुवातीपासून सुरुवात करण्याची गरज नाही. त्यांचे काही [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) आणि [v3](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts) कॉन्ट्रॅक्ट्स पहा. + +## संयोजनीयता म्हणजे काय? {#what-is-composability} + +संयोजनीयता म्हणजे नवीन प्रणाली किंवा आउटपुट तयार करण्यासाठी वेगळे घटक एकत्र करणे. सॉफ्टवेअर डेव्हलपमेंटमध्ये, संयोजनीयतेचा अर्थ असा आहे की डेव्हलपर्स नवीन ॲप्लिकेशन्स तयार करण्यासाठी विद्यमान सॉफ्टवेअर घटकांचा पुन्हा वापर करू शकतात. संयोजनीयता समजून घेण्याचा एक चांगला मार्ग म्हणजे संयोजनीय घटकांना लेगो ब्लॉक्स म्हणून पाहणे. प्रत्येक लेगो दुसऱ्यासोबत जोडला जाऊ शकतो, ज्यामुळे तुम्हाला वेगवेगळे लेगो एकत्र करून गुंतागुंतीच्या रचना तयार करता येतात. + +Ethereum मध्ये, प्रत्येक स्मार्ट कॉन्ट्रॅक्ट एक प्रकारचा लेगो आहे—तुम्ही तुमच्या प्रोजेक्टसाठी बिल्डिंग ब्लॉक्स म्हणून इतर प्रोजेक्ट्समधील स्मार्ट कॉन्ट्रॅक्ट्स वापरू शकता. याचा अर्थ असा की तुम्हाला आधीच झालेल्या गोष्टी पुन्हा करण्यात किंवा सुरवातीपासून काहीतरी तयार करण्यात वेळ घालवावा लागत नाही. + +## संयोजनीयता कशी कार्य करते? {#how-does-composability-work} + +Ethereum स्मार्ट कॉन्ट्रॅक्ट्स हे सार्वजनिक APIs सारखे आहेत, त्यामुळे कोणीही कॉन्ट्रॅक्टशी संवाद साधू शकतो किंवा अतिरिक्त कार्यक्षमतेसाठी त्यांना डॅप्समध्ये समाकलित करू शकतो. स्मार्ट कॉन्ट्रॅक्ट संयोजनीयता सामान्यतः तीन तत्त्वांवर कार्य करते: मॉड्युलॅरिटी, स्वायत्तता आणि शोधक्षमता: + +**१.** **मॉड्युलॅरिटी**: ही वैयक्तिक घटकांची विशिष्ट कार्य करण्याची क्षमता आहे. Ethereum मध्ये, प्रत्येक स्मार्ट कॉन्ट्रॅक्टचा एक विशिष्ट वापर असतो (जसे Uniswap च्या उदाहरणात दाखवले आहे). + +**२.** **स्वायत्तता**: संयोजनीय घटक स्वतंत्रपणे कार्य करण्यास सक्षम असले पाहिजेत. Ethereum मधील प्रत्येक स्मार्ट कॉन्ट्रॅक्ट स्वयं-अंमलबजावणी करणारा असतो आणि प्रणालीच्या इतर भागांवर अवलंबून न राहता कार्य करू शकतो. + +**३.** डेव्हलपर्स बाह्य कॉन्ट्रॅक्टना कॉल करू शकत नाहीत किंवा सॉफ्टवेअर लायब्ररींना ॲप्लिकेशन्समध्ये समाकलित करू शकत नाहीत, जर त्या सार्वजनिकरित्या उपलब्ध नसतील. रचनेनुसार, स्मार्ट कॉन्ट्रॅक्ट्स ओपन-सोर्स असतात; कोणीही स्मार्ट कॉन्ट्रॅक्टला कॉल करू शकतो किंवा कोडबेस फोर्क करू शकतो. + +## संयोजनीयतेचे फायदे {#benefits-of-composability} + +### लहान डेव्हलपमेंट सायकल {#shorter-development-cycle} + +संयोजनीयता [dapps](/apps/#what-are-dapps) तयार करताना डेव्हलपर्सना करावे लागणारे काम कमी करते. [नवल रविकांत यांच्या मते:](https://twitter.com/naval/status/1444366754650656770) "ओपन सोर्स म्हणजे प्रत्येक समस्येचे निराकरण फक्त एकदाच करायला लागते." + +जर एखादी समस्या सोडवणारा स्मार्ट कॉन्ट्रॅक्ट अस्तित्वात असेल, तर इतर डेव्हलपर्स त्याचा पुन्हा वापर करू शकतात, त्यामुळे त्यांना तीच समस्या सोडवावी लागत नाही. अशाप्रकारे, डेव्हलपर्स नवीन डॅप्स तयार करण्यासाठी विद्यमान सॉफ्टवेअर लायब्ररी घेऊन त्यात अतिरिक्त कार्यक्षमता जोडू शकतात. + +### अधिक नवनिर्मिती {#greater-innovation} + +संयोजनीयता नवनिर्मिती आणि प्रयोगांना प्रोत्साहन देते, कारण डेव्हलपर्स इच्छित परिणाम मिळवण्यासाठी ओपन-सोर्स कोडचा पुनर्वापर, बदल, डुप्लिकेट किंवा समाकलित करण्यास स्वतंत्र असतात. परिणामी, डेव्हलपमेंट टीम्स मूलभूत कार्यक्षमतेवर कमी वेळ घालवतात आणि नवीन वैशिष्ट्यांवर प्रयोग करण्यासाठी अधिक वेळ देऊ शकतात. + +### उत्तम वापरकर्ता अनुभव {#better-user-experience} + +Ethereum इकोसिस्टीममधील घटकांमधील आंतरकार्यक्षमता वापरकर्त्याचा अनुभव सुधारते. ज्या इकोसिस्टममध्ये ॲप्लिकेशन्स एकमेकांशी संवाद साधू शकत नाहीत, अशा विखुरलेल्या इकोसिस्टमच्या तुलनेत, जेव्हा डॅप्स बाह्य स्मार्ट कॉन्ट्रॅक्ट्स समाकलित करतात तेव्हा वापरकर्त्यांना अधिक कार्यक्षमता उपलब्ध होते. + +आंतरकार्यक्षमतेचे फायदे स्पष्ट करण्यासाठी आपण आर्बिट्राज ट्रेडिंगमधील एक उदाहरण घेऊया: + +जर एखादे टोकन `एक्सचेंज B` पेक्षा `एक्सचेंज A` वर जास्त किमतीत ट्रेड होत असेल, तर तुम्ही नफा मिळवण्यासाठी या किमतीतील फरकाचा फायदा घेऊ शकता. तथापि, तुम्ही हे तेव्हाच करू शकता जेव्हा तुमच्याकडे व्यवहार पूर्ण करण्यासाठी पुरेसे भांडवल असेल (म्हणजेच, `एक्सचेंज B` वरून टोकन विकत घेणे आणि ते `एक्सचेंज A` वर विकणे). + +तुमच्याकडे ट्रेड पूर्ण करण्यासाठी पुरेसा निधी नसलेल्या परिस्थितीत, फ्लॅश लोन एक आदर्श पर्याय असू शकतो. [फ्लॅश लोन्स](/defi/#flash-loans) हे अत्यंत तांत्रिक आहेत, परंतु मूळ कल्पना अशी आहे की तुम्ही मालमत्ता (तारणाशिवाय) उधार घेऊ शकता आणि त्याच _एका_ व्यवहारात परत करू शकता. + +आपल्या सुरुवातीच्या उदाहरणाकडे परत जाताना, एक आर्बिट्राज ट्रेडर मोठा फ्लॅश लोन घेऊ शकतो, `एक्सचेंज B` वरून टोकन्स विकत घेऊन ते `एक्सचेंज A` वर विकू शकतो, भांडवल + व्याज परतफेड करू शकतो आणि नफा ठेवू शकतो, हे सर्व एकाच व्यवहारात. या गुंतागुंतीच्या लॉजिकसाठी अनेक कॉन्ट्रॅक्ट्सना केलेल्या कॉल्सना एकत्र करणे आवश्यक आहे, जे स्मार्ट कॉन्ट्रॅक्ट्समध्ये आंतरकार्यक्षमता नसल्यास शक्य झाले नसते. + +## Ethereum मधील संयोजनीयतेची उदाहरणे {#composability-in-ethereum} + +### टोकन स्वॅप्स {#token-swaps} + +जर तुम्ही असा डॅप तयार केला ज्यामध्ये व्यवहारांसाठी ETH मध्ये पैसे देणे आवश्यक आहे, तर तुम्ही टोकन स्वॅप लॉजिक समाकलित करून वापरकर्त्यांना इतर ERC-20 टोकनमध्ये पैसे देण्याची परवानगी देऊ शकता. कॉन्ट्रॅक्टने कॉल केलेले फंक्शन कार्यान्वित करण्यापूर्वी कोड आपोआप वापरकर्त्याच्या टोकनला ETH मध्ये रूपांतरित करेल. + +### शासन {#governance} + +[DAO](/dao/) साठी सानुकूलित शासन प्रणाली तयार करणे खर्चिक आणि वेळखाऊ असू शकते. त्याऐवजी, तुम्ही तुमच्या DAO ला त्वरीत बूटस्ट्रॅप करण्यासाठी आणि एक शासन फ्रेमवर्क तयार करण्यासाठी [Aragon Client](https://client.aragon.org/) सारखे ओपन-सोर्स शासन टूलकिट वापरू शकता. + +### ओळख व्यवस्थापन {#identity-management} + +सानुकूल ऑथेंटिकेशन प्रणाली तयार करण्याऐवजी किंवा केंद्रीकृत प्रदात्यांवर अवलंबून राहण्याऐवजी, तुम्ही वापरकर्त्यांसाठी ऑथेंटिकेशन व्यवस्थापित करण्यासाठी विकेंद्रित ओळख (DID) साधने समाकलित करू शकता. याचे एक उदाहरण [SpruceID](https://www.spruceid.com/) आहे, जे एक ओपन-सोर्स टूलकिट आहे. हे "Sign in with Ethereum" कार्यक्षमता प्रदान करते, ज्यामुळे वापरकर्ते Ethereum वॉलेटद्वारे त्यांची ओळख प्रमाणित करू शकतात. + +## संबंधित ट्युटोरियल्स {#related-tutorials} + +- [create-eth-app सह तुमच्या डॅप फ्रंटएंड डेव्हलपमेंटला किकस्टार्ट करा](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _– लोकप्रिय स्मार्ट कॉन्ट्रॅक्ट्ससह ॲप्स तयार करण्यासाठी create-eth-app कसे वापरावे याचे विहंगावलोकन._ + +## पुढील वाचन {#further-reading} + +_तुम्हाला मदत केलेल्या सामुदायिक संसाधनाबद्दल माहिती आहे का?_ हे पृष्ठ संपादित करा आणि ते जोडा!_ + +- [संयोजनीयता ही नवनिर्मिती आहे](https://a16zcrypto.com/posts/article/how-composability-unlocks-crypto-and-everything-else/) +- [Web3 साठी संयोजनीयता का महत्त्वाची आहे](https://hackernoon.com/why-composability-matters-for-web3) +- [संयोजनीयता म्हणजे काय?](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.) diff --git a/public/content/translations/mr/developers/docs/smart-contracts/deploying/index.md b/public/content/translations/mr/developers/docs/smart-contracts/deploying/index.md new file mode 100644 index 00000000000..af775e700aa --- /dev/null +++ b/public/content/translations/mr/developers/docs/smart-contracts/deploying/index.md @@ -0,0 +1,81 @@ +--- +title: "स्मार्ट कॉन्ट्रॅक्ट्स डिप्लॉय करणे" +description: "Ethereum नेटवर्क्सवर स्मार्ट कॉन्ट्रॅक्ट्स कसे डिप्लॉय करायचे ते शिका, ज्यामध्ये पूर्वआवश्यकता, साधने आणि डिप्लॉयमेंटच्या पायऱ्या समाविष्ट आहेत." +lang: mr +--- + +Ethereum नेटवर्कच्या वापरकर्त्यांसाठी तुमचा स्मार्ट कॉन्ट्रॅक्ट उपलब्ध होण्यासाठी तुम्हाला तो डिप्लॉय करणे आवश्यक आहे. + +स्मार्ट कॉन्ट्रॅक्ट डिप्लॉय करण्यासाठी, तुम्ही कोणताही प्राप्तकर्ता निर्दिष्ट न करता स्मार्ट कॉन्ट्रॅक्टचा संकलित कोड असलेला Ethereum व्यवहार पाठवता. + +## पूर्वतयारी {#prerequisites} + +स्मार्ट कॉन्ट्रॅक्ट्स डिप्लॉय करण्यापूर्वी तुम्हाला [Ethereum नेटवर्क्स](/developers/docs/networks/), [व्यवहार](/developers/docs/transactions/) आणि [स्मार्ट कॉन्ट्रॅक्ट्सची रचना](/developers/docs/smart-contracts/anatomy/) समजून घेणे आवश्यक आहे. + +कॉन्ट्रॅक्ट डिप्लॉय करण्यासाठी इथर (ETH) देखील खर्च होतो कारण ते ब्लॉकचेनवर साठवले जातात, त्यामुळे तुम्हाला Ethereum वरील [गॅस आणि शुल्क](/developers/docs/gas/) बद्दल माहिती असणे आवश्यक आहे. + +शेवटी, तुम्हाला तुमचा कॉन्ट्रॅक्ट डिप्लॉय करण्यापूर्वी तो संकलित करणे आवश्यक आहे, म्हणून तुम्ही [स्मार्ट कॉन्ट्रॅक्ट्स संकलित करणे](/developers/docs/smart-contracts/compiling/) बद्दल वाचले असल्याची खात्री करा. + +## स्मार्ट कॉन्ट्रॅक्ट कसा डिप्लॉय करायचा {#how-to-deploy-a-smart-contract} + +### तुम्हाला काय लागेल {#what-youll-need} + +- तुमच्या कॉन्ट्रॅक्टचा बायकोड – हे [संकलन](/developers/docs/smart-contracts/compiling/) द्वारे तयार केले जाते +- गॅससाठी ETH – तुम्ही इतर व्यवहारांप्रमाणे तुमची गॅस मर्यादा सेट कराल, त्यामुळे लक्षात ठेवा की कॉन्ट्रॅक्ट डिप्लॉयमेंटसाठी साध्या ETH हस्तांतरणापेक्षा खूप जास्त गॅसची आवश्यकता असते +- एक डिप्लॉयमेंट स्क्रिप्ट किंवा प्लगइन +- [Ethereum नोड](/developers/docs/nodes-and-clients/) मध्ये प्रवेश, एकतर तुमचा स्वतःचा चालवून, सार्वजनिक नोडशी कनेक्ट करून, किंवा [नोड सेवा](/developers/docs/nodes-and-clients/nodes-as-a-service/) वापरून API की द्वारे + +### स्मार्ट कॉन्ट्रॅक्ट डिप्लॉय करण्याच्या पायऱ्या {#steps-to-deploy} + +यात समाविष्ट असलेल्या विशिष्ट पायऱ्या प्रश्नातील डेव्हलपमेंट फ्रेमवर्कवर अवलंबून असतील. उदाहरणार्थ, तुम्ही [तुमचे कॉन्ट्रॅक्ट्स डिप्लॉय करण्यावर Hardhat चे डॉक्युमेंटेशन](https://hardhat.org/docs/tutorial/deploying) किंवा [स्मार्ट कॉन्ट्रॅक्ट डिप्लॉय आणि सत्यापित करण्यावर Foundry चे डॉक्युमेंटेशन](https://book.getfoundry.sh/forge/deploying) पाहू शकता. एकदा डिप्लॉय झाल्यावर, तुमच्या कॉन्ट्रॅक्टला इतर [खात्यांप्रमाणेच](/developers/docs/accounts/) एक Ethereum पत्ता मिळेल आणि [सोर्स कोड व्हेरिफिकेशन टूल्स](/developers/docs/smart-contracts/verifying/#source-code-verification-tools) वापरून ते सत्यापित केले जाऊ शकते. + +## संबंधित साधने {#related-tools} + +**Remix - _Remix IDE Ethereum सारख्या ब्लॉकचेनसाठी स्मार्ट कॉन्ट्रॅक्ट्स विकसित, डिप्लॉय आणि व्यवस्थापित करण्याची परवानगी देतो_** + +- [Remix](https://remix.ethereum.org) + +**Tenderly - _Web3 डेव्हलपमेंट प्लॅटफॉर्म जो स्मार्ट कॉन्ट्रॅक्ट्स विकसित करणे, चाचणी करणे, निरीक्षण करणे आणि ऑपरेट करण्यासाठी डीबगिंग, निरीक्षणक्षमता आणि पायाभूत सुविधा बिल्डिंग ब्लॉक्स प्रदान करतो_** + +- [tenderly.co](https://tenderly.co/) +- [Docs](https://docs.tenderly.co/) +- [GitHub](https://github.com/Tenderly) +- [Discord](https://discord.gg/eCWjuvt) + +**Hardhat - _तुमचे Ethereum सॉफ्टवेअर संकलित करणे, डिप्लॉय करणे, चाचणी करणे आणि डीबग करण्यासाठी एक डेव्हलपमेंट वातावरण_** + +- [hardhat.org](https://hardhat.org/getting-started/) +- [तुमचे कॉन्ट्रॅक्ट्स डिप्लॉय करण्यावरील डॉक्स](https://hardhat.org/docs/tutorial/deploying) +- [GitHub](https://github.com/nomiclabs/hardhat) +- [Discord](https://discord.com/invite/TETZs2KK4k) + +**thirdweb - _एकाच कमांडचा वापर करून, कोणताही कॉन्ट्रॅक्ट कोणत्याही EVM सुसंगत चेनवर सहजपणे डिप्लॉय करा_** + +- [डॉक्युमेंटेशन](https://portal.thirdweb.com/deploy/) + +**Crossmint - _स्मार्ट कॉन्ट्रॅक्ट्स डिप्लॉय करण्यासाठी, क्रेडिट-कार्ड आणि क्रॉस-चेन पेमेंट सक्षम करण्यासाठी आणि NFTs तयार करण्यासाठी, वितरित करण्यासाठी, विकण्यासाठी, संग्रहित करण्यासाठी आणि संपादित करण्यासाठी APIs वापरण्याकरिता एंटरप्राइझ-ग्रेड वेब3 डेव्हलपमेंट प्लॅटफॉर्म._** + +- [crossmint.com](https://www.crossmint.com) +- [दस्तऐवजीकरण](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) +- [Blog](https://blog.crossmint.com) + +## संबंधित ट्युटोरियल्स {#related-tutorials} + +- [तुमचा पहिला स्मार्ट कॉन्ट्रॅक्ट डिप्लॉय करणे](/developers/tutorials/deploying-your-first-smart-contract/) _– Ethereum चाचणी नेटवर्कवर तुमचा पहिला स्मार्ट कॉन्ट्रॅक्ट डिप्लॉय करण्याची ओळख._ +- [हॅलो वर्ल्ड | स्मार्ट कॉन्ट्रॅक्ट ट्यूटोरियल](/developers/tutorials/hello-world-smart-contract/) _– Ethereum वर एक मूलभूत स्मार्ट कॉन्ट्रॅक्ट तयार करण्यासाठी आणि डिप्लॉय करण्यासाठी सोपे ट्यूटोरियल._ +- [Solidity वरून इतर करारांशी संवाद साधा](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– विद्यमान करारातून स्मार्ट करार कसा तैनात करायचा आणि त्याच्याशी संवाद कसा साधायचा._ +- [तुमच्या कॉन्ट्रॅक्टचा आकार कसा कमी करायचा](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _- तुमच्या कॉन्ट्रॅक्टचा आकार मर्यादेत ठेवण्यासाठी आणि गॅसवर बचत करण्यासाठी तो कसा कमी करावा_ + +## पुढील वाचन {#further-reading} + +- [https://docs.openzeppelin.com/learn/deploying-and-interacting](https://docs.openzeppelin.com/learn/deploying-and-interacting) - _OpenZeppelin_ +- [Hardhat सह तुमचे कॉन्ट्रॅक्ट्स डिप्लॉय करणे](https://hardhat.org/docs/tutorial/deploying) - _Nomic Labs_ + +_तुम्हाला मदत केलेल्या सामुदायिक संसाधनाबद्दल माहिती आहे का?_ हे पृष्ठ संपादित करा आणि ते जोडा!_ + +## संबंधित विषय {#related-topics} + +- [डेव्हलपमेंट फ्रेमवर्क्स](/developers/docs/frameworks/) +- [एक Ethereum नोड चालवा](/developers/docs/nodes-and-clients/run-a-node/) +- [Nodes-as-a-service](/developers/docs/nodes-and-clients/nodes-as-a-service) diff --git a/public/content/translations/mr/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/mr/developers/docs/smart-contracts/formal-verification/index.md new file mode 100644 index 00000000000..54d4fc7bab3 --- /dev/null +++ b/public/content/translations/mr/developers/docs/smart-contracts/formal-verification/index.md @@ -0,0 +1,284 @@ +--- +title: "स्मार्ट कॉन्ट्रॅक्ट्सची औपचारिक पडताळणी" +description: "Ethereum स्मार्ट कॉन्ट्रॅक्ट्ससाठी औपचारिक पडताळणीचा आढावा" +lang: mr +--- + +[स्मार्ट कॉन्ट्रॅक्ट्स](/developers/docs/smart-contracts/) विकेंद्रित, विश्वासहीन आणि मजबूत ॲप्लिकेशन्स तयार करणे शक्य करत आहेत जे नवीन उपयोग-प्रकरणे सादर करतात आणि वापरकर्त्यांसाठी मूल्य अनलॉक करतात. कारण स्मार्ट कॉन्ट्रॅक्ट्स मोठ्या प्रमाणात मूल्य हाताळतात, त्यामुळे डेव्हलपर्ससाठी सुरक्षा हा एक महत्त्वपूर्ण विचार आहे. + +औपचारिक पडताळणी हे [स्मार्ट कॉन्ट्रॅक्ट सुरक्षा](/developers/docs/smart-contracts/security/) सुधारण्यासाठी शिफारस केलेल्या तंत्रांपैकी एक आहे. औपचारिक पडताळणी, जी प्रोग्राम्सचे विनिर्देशन, डिझाइन आणि पडताळणी करण्यासाठी [औपचारिक पद्धती](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/) वापरते, महत्त्वपूर्ण हार्डवेअर आणि सॉफ्टवेअर प्रणालींची अचूकता सुनिश्चित करण्यासाठी अनेक वर्षांपासून वापरली जात आहे. + +स्मार्ट कॉन्ट्रॅक्ट्समध्ये लागू केल्यावर, औपचारिक पडताळणी हे सिद्ध करू शकते की कॉन्ट्रॅक्टचा व्यावसायिक तर्क पूर्वनिर्धारित विनिर्देशनाची पूर्तता करतो. कॉन्ट्रॅक्ट कोडच्या अचूकतेचे मूल्यांकन करण्याच्या इतर पद्धतींच्या तुलनेत, जसे की चाचणी, औपचारिक पडताळणी स्मार्ट कॉन्ट्रॅक्ट कार्यात्मकदृष्ट्या योग्य असल्याची अधिक मजबूत हमी देते. + +## औपचारिक पडताळणी म्हणजे काय? {#what-is-formal-verification} + +औपचारिक पडताळणी म्हणजे औपचारिक विनिर्देशनाच्या संदर्भात प्रणालीच्या अचूकतेचे मूल्यांकन करण्याची प्रक्रिया. सोप्या भाषेत सांगायचे तर, औपचारिक पडताळणी आपल्याला हे तपासण्याची परवानगी देते की प्रणालीचे वर्तन काही आवश्यकतांची पूर्तता करते की नाही (म्हणजेच, ते आपल्याला हवे ते करते). + +प्रणालीचे (या प्रकरणात स्मार्ट कॉन्ट्रॅक्ट) अपेक्षित वर्तन औपचारिक मॉडेलिंग वापरून वर्णन केले जाते, तर विनिर्देशन भाषा औपचारिक गुणधर्म तयार करण्यास सक्षम करतात. औपचारिक पडताळणी तंत्रे नंतर हे सत्यापित करू शकतात की कॉन्ट्रॅक्टची अंमलबजावणी त्याच्या विनिर्देशनाचे पालन करते आणि पूर्वीच्या अचूकतेचा गणितीय पुरावा मिळवू शकतात. जेव्हा एखादा कॉन्ट्रॅक्ट त्याच्या विनिर्देशनाची पूर्तता करतो, तेव्हा त्याचे वर्णन “कार्यात्मकदृष्ट्या योग्य”, “डिझाइननुसार योग्य” किंवा “बांधणीनुसार योग्य” असे केले जाते. + +### औपचारिक मॉडेल म्हणजे काय? {#what-is-a-formal-model} + +संगणक शास्त्रात, [औपचारिक मॉडेल](https://en.wikipedia.org/wiki/Model_of_computation) हे गणना प्रक्रियेचे गणितीय वर्णन आहे. प्रोग्राम्सना गणितीय कार्यांमध्ये (समीकरणांमध्ये) रूपांतरित केले जाते, ज्यामध्ये मॉडेल वर्णन करते की इनपुट दिल्यावर फंक्शन्सचे आउटपुट कसे मोजले जातात. + +औपचारिक मॉडेल्स अमूर्ततेची एक पातळी प्रदान करतात ज्यावर प्रोग्रामच्या वर्तनाचे विश्लेषण मूल्यांकन केले जाऊ शकते. औपचारिक मॉडेल्सचे अस्तित्व _औपचारिक विनिर्देशन_ तयार करण्याची परवानगी देते, जे प्रश्नातील मॉडेलचे इच्छित गुणधर्म वर्णन करते. + +औपचारिक पडताळणीसाठी स्मार्ट कॉन्ट्रॅक्ट्सचे मॉडेलिंग करण्यासाठी विविध तंत्रे वापरली जातात. उदाहरणार्थ, काही मॉडेल्स स्मार्ट कॉन्ट्रॅक्टच्या उच्च-स्तरीय वर्तनाबद्दल तर्क करण्यासाठी वापरले जातात. ही मॉडेलिंग तंत्रे स्मार्ट कॉन्ट्रॅक्ट्सवर ब्लॅक-बॉक्स दृष्टिकोन लागू करतात, त्यांना अशा प्रणाली म्हणून पाहतात ज्या इनपुट स्वीकारतात आणि त्या इनपुटवर आधारित गणना करतात. + +उच्च-स्तरीय मॉडेल्स स्मार्ट कॉन्ट्रॅक्ट्स आणि बाह्य एजंट्स, जसे की बाह्य मालकीची खाती (EOAs), कॉन्ट्रॅक्ट खाती आणि ब्लॉकचेन पर्यावरण यांच्यातील संबंधांवर लक्ष केंद्रित करतात. असे मॉडेल्स गुणधर्म परिभाषित करण्यासाठी उपयुक्त आहेत जे विशिष्ट वापरकर्ता परस्परसंवादांना प्रतिसाद म्हणून कॉन्ट्रॅक्टने कसे वागावे हे निर्दिष्ट करतात. + +याउलट, इतर औपचारिक मॉडेल्स स्मार्ट कॉन्ट्रॅक्टच्या निम्न-स्तरीय वर्तनावर लक्ष केंद्रित करतात. जरी उच्च-स्तरीय मॉडेल्स कॉन्ट्रॅक्टच्या कार्यक्षमतेबद्दल तर्क करण्यामध्ये मदत करू शकतात, तरी ते अंमलबजावणीच्या अंतर्गत कार्यांबद्दल तपशील कॅप्चर करण्यात अयशस्वी होऊ शकतात. निम्न-स्तरीय मॉडेल्स प्रोग्राम विश्लेषणासाठी व्हाइट-बॉक्स दृष्टिकोन लागू करतात आणि कॉन्ट्रॅक्टच्या अंमलबजावणीशी संबंधित गुणधर्मांबद्दल तर्क करण्यासाठी स्मार्ट कॉन्ट्रॅक्ट ॲप्लिकेशन्सच्या निम्न-स्तरीय प्रतिनिधित्वांवर, जसे की प्रोग्राम ट्रेसेस आणि [कंट्रोल फ्लो ग्राफ्स](https://en.wikipedia.org/wiki/Control-flow_graph) वर अवलंबून असतात. + +निम्न-स्तरीय मॉडेल्स आदर्श मानले जातात कारण ते Ethereum च्या अंमलबजावणी वातावरणात (म्हणजेच, [EVM](/developers/docs/evm/)) स्मार्ट कॉन्ट्रॅक्टच्या वास्तविक अंमलबजावणीचे प्रतिनिधित्व करतात. निम्न-स्तरीय मॉडेलिंग तंत्रे स्मार्ट कॉन्ट्रॅक्ट्समध्ये महत्त्वपूर्ण सुरक्षा गुणधर्म स्थापित करण्यासाठी आणि संभाव्य असुरक्षितता शोधण्यासाठी विशेषतः उपयुक्त आहेत. + +### औपचारिक विनिर्देशन म्हणजे काय? {#what-is-a-formal-specification} + +विनिर्देशन ही फक्त एक तांत्रिक आवश्यकता आहे जी एका विशिष्ट प्रणालीने पूर्ण केली पाहिजे. प्रोग्रामिंगमध्ये, विनिर्देशने प्रोग्रामच्या अंमलबजावणीबद्दलच्या सामान्य कल्पनांचे प्रतिनिधित्व करतात (म्हणजेच, प्रोग्रामने काय केले पाहिजे). + +स्मार्ट कॉन्ट्रॅक्ट्सच्या संदर्भात, औपचारिक विनिर्देशने _गुणधर्मांना_ सूचित करतात—कॉन्ट्रॅक्टने पूर्ण केल्या पाहिजेत अशा आवश्यकतांचे औपचारिक वर्णन. अशा गुणधर्मांना "अचल" म्हणून वर्णन केले जाते आणि ते कॉन्ट्रॅक्टच्या अंमलबजावणीबद्दल तार्किक प्रतिपादनांचे प्रतिनिधित्व करतात जे कोणत्याही अपवादांशिवाय प्रत्येक संभाव्य परिस्थितीत खरे राहिले पाहिजेत. + +अशाप्रकारे, आपण औपचारिक विनिर्देशनाला एका औपचारिक भाषेत लिहिलेल्या विधानांचा संग्रह मानू शकतो जे स्मार्ट कॉन्ट्रॅक्टच्या अभिप्रेत अंमलबजावणीचे वर्णन करतात. विनिर्देशने कॉन्ट्रॅक्टचे गुणधर्म समाविष्ट करतात आणि विविध परिस्थितीत कॉन्ट्रॅक्टने कसे वागावे हे परिभाषित करतात. औपचारिक पडताळणीचा उद्देश हे निर्धारित करणे आहे की स्मार्ट कॉन्ट्रॅक्टमध्ये हे गुणधर्म (अचल) आहेत की नाही आणि अंमलबजावणी दरम्यान या गुणधर्मांचे उल्लंघन होत नाही. + +स्मार्ट कॉन्ट्रॅक्ट्सच्या सुरक्षित अंमलबजावणी विकसित करण्यामध्ये औपचारिक विनिर्देशने महत्त्वपूर्ण आहेत. अचल लागू करण्यात अयशस्वी होणारे किंवा अंमलबजावणी दरम्यान ज्यांचे गुणधर्म उल्लंघन केले जातात असे कॉन्ट्रॅक्ट्स असुरक्षिततेस प्रवण असतात, जे कार्यक्षमतेला हानी पोहोचवू शकतात किंवा दुर्भावनापूर्ण शोषणास कारणीभूत ठरू शकतात. + +## स्मार्ट कॉन्ट्रॅक्ट्ससाठी औपचारिक विनिर्देशनांचे प्रकार {#formal-specifications-for-smart-contracts} + +औपचारिक विनिर्देशने प्रोग्राम अंमलबजावणीच्या अचूकतेबद्दल गणितीय तर्कास सक्षम करतात. औपचारिक मॉडेल्सप्रमाणेच, औपचारिक विनिर्देशने एकतर उच्च-स्तरीय गुणधर्म किंवा कॉन्ट्रॅक्ट अंमलबजावणीचे निम्न-स्तरीय वर्तन कॅप्चर करू शकतात. + +औपचारिक विनिर्देशने [प्रोग्राम लॉजिक](https://en.wikipedia.org/wiki/Logic_programming) च्या घटकांचा वापर करून साधित केली जातात, जे प्रोग्रामच्या गुणधर्मांबद्दल औपचारिक तर्कास परवानगी देतात. प्रोग्राम लॉजिकमध्ये औपचारिक नियम असतात जे प्रोग्रामचे अपेक्षित वर्तन (गणितीय भाषेत) व्यक्त करतात. औपचारिक विनिर्देशने तयार करण्यामध्ये विविध प्रोग्राम लॉजिक्स वापरले जातात, ज्यात [रीचेबिलिटी लॉजिक](https://en.wikipedia.org/wiki/Reachability_problem), [टेम्पोरल लॉजिक](https://en.wikipedia.org/wiki/Temporal_logic) आणि [होअर लॉजिक](https://en.wikipedia.org/wiki/Hoare_logic) यांचा समावेश आहे. + +स्मार्ट कॉन्ट्रॅक्ट्ससाठी औपचारिक विनिर्देशनांचे वर्गीकरण साधारणपणे **उच्च-स्तरीय** किंवा **निम्न-स्तरीय** विनिर्देशने म्हणून केले जाऊ शकते. विनिर्देशन कोणत्याही श्रेणीतील असो, त्याने विश्लेषणाधीन प्रणालीच्या गुणधर्माचे पुरेसे आणि निःसंदिग्धपणे वर्णन केले पाहिजे. + +### उच्च-स्तरीय विनिर्देशने {#high-level-specifications} + +नावाप्रमाणेच, उच्च-स्तरीय विनिर्देशन (ज्याला "मॉडेल-ओरिएंटेड विनिर्देशन" असेही म्हणतात) प्रोग्रामच्या उच्च-स्तरीय वर्तनाचे वर्णन करते. उच्च-स्तरीय विनिर्देशने स्मार्ट कॉन्ट्रॅक्टला [फायनाइट स्टेट मशीन](https://en.wikipedia.org/wiki/Finite-state_machine) (FSM) म्हणून मॉडेल करतात, जे ऑपरेशन्स करून स्टेट्समध्ये संक्रमण करू शकते, FSM मॉडेलसाठी औपचारिक गुणधर्म परिभाषित करण्यासाठी टेम्पोरल लॉजिक वापरले जाते. + +[टेम्पोरल लॉजिक्स](https://en.wikipedia.org/wiki/Temporal_logic) हे "वेळेच्या संदर्भात पात्र असलेल्या प्रस्तावांबद्दल तर्क करण्याचे नियम आहेत (उदा., "मला _नेहमीच_ भूक लागलेली असते" किंवा "मला _अखेरीस_ भूक लागेल")." औपचारिक पडताळणीवर लागू केल्यावर, टेम्पोरल लॉजिक्सचा वापर स्टेट मशीन म्हणून मॉडेल केलेल्या प्रणालींच्या योग्य वर्तनाबद्दल प्रतिपादन करण्यासाठी केला जातो. विशेषतः, एक टेम्पोरल लॉजिक स्मार्ट कॉन्ट्रॅक्टच्या भविष्यातील संभाव्य अवस्थांचे आणि ते अवस्थांमध्ये कसे संक्रमण करते याचे वर्णन करते. + +उच्च-स्तरीय विनिर्देशने साधारणपणे स्मार्ट कॉन्ट्रॅक्ट्ससाठी दोन महत्त्वपूर्ण टेम्पोरल गुणधर्म कॅप्चर करतात: **सुरक्षितता** आणि **सजीवता**. सुरक्षा गुणधर्म “काहीही वाईट कधीच घडत नाही” ही कल्पना दर्शवतात आणि सहसा अचलता व्यक्त करतात. सुरक्षा गुणधर्म सामान्य सॉफ्टवेअर आवश्यकता परिभाषित करू शकतो, जसे की [डेडलाक](https://www.techtarget.com/whatis/definition/deadlock) पासून स्वातंत्र्य, किंवा कॉन्ट्रॅक्ट्ससाठी डोमेन-विशिष्ट गुणधर्म व्यक्त करू शकतो (उदा. फंक्शन्ससाठी ॲक्सेस कंट्रोलवरील अचल, स्टेट व्हेरिएबल्सची स्वीकार्य मूल्ये, किंवा टोकन ट्रान्सफरसाठी अटी). + +उदाहरणार्थ, ERC-20 टोकन कॉन्ट्रॅक्ट्समध्ये `transfer()` किंवा `transferFrom()` वापरण्याच्या अटींचा समावेश असलेली ही सुरक्षा आवश्यकता घ्या: _“पाठवल्या जाणाऱ्या टोकनच्या विनंती केलेल्या रकमेपेक्षा पाठवणाऱ्याची शिल्लक कधीही कमी नसते.”_. कॉन्ट्रॅक्ट अचलाचे हे नैसर्गिक-भाषेतील वर्णन औपचारिक (गणितीय) विनिर्देशनामध्ये अनुवादित केले जाऊ शकते, ज्याची वैधता नंतर कठोरपणे तपासली जाऊ शकते. + +सजीवता गुणधर्म हे सांगतात की “अखेरीस काहीतरी चांगले घडते” आणि ते कॉन्ट्रॅक्टच्या विविध अवस्थांमधून प्रगती करण्याच्या क्षमतेशी संबंधित आहेत. सजीवता गुणधर्माचे एक उदाहरण "तरलता" आहे, जे विनंतीनुसार वापरकर्त्यांना त्याची शिल्लक हस्तांतरित करण्याच्या कॉन्ट्रॅक्टच्या क्षमतेला सूचित करते. या गुणधर्माचे उल्लंघन झाल्यास, वापरकर्ते कॉन्ट्रॅक्टमध्ये संग्रहित मालमत्ता काढू शकणार नाहीत, जसे [पॅरिटी वॉलेट घटनेमध्ये](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html) घडले होते. + +### निम्न-स्तरीय विनिर्देशने {#low-level-specifications} + +उच्च-स्तरीय विनिर्देशने कॉन्ट्रॅक्टच्या मर्यादित-अवस्था मॉडेलला प्रारंभिक बिंदू म्हणून घेतात आणि या मॉडेलचे इच्छित गुणधर्म परिभाषित करतात. याउलट, निम्न-स्तरीय विनिर्देशने (ज्यांना "गुणधर्म-केंद्रित विनिर्देशने" असेही म्हणतात) अनेकदा प्रोग्राम्सना (स्मार्ट कॉन्ट्रॅक्ट्सना) गणितीय कार्यांचा संग्रह असलेली प्रणाली म्हणून मॉडेल करतात आणि अशा प्रणालींच्या योग्य वर्तनाचे वर्णन करतात. + +सोप्या भाषेत, निम्न-स्तरीय विनिर्देशने _प्रोग्राम ट्रेसेसचे_ विश्लेषण करतात आणि या ट्रेसेसवर स्मार्ट कॉन्ट्रॅक्टचे गुणधर्म परिभाषित करण्याचा प्रयत्न करतात. ट्रेसेस म्हणजे फंक्शन एक्झिक्युशनच्या अनुक्रमांना जे स्मार्ट कॉन्ट्रॅक्टची अवस्था बदलतात; म्हणून, निम्न-स्तरीय विनिर्देशने कॉन्ट्रॅक्टच्या अंतर्गत अंमलबजावणीसाठी आवश्यकता निर्दिष्ट करण्यास मदत करतात. + +निम्न-स्तरीय औपचारिक विनिर्देशने होअर-शैलीतील गुणधर्म किंवा अंमलबजावणी मार्गांवरील अचल म्हणून दिले जाऊ शकतात. + +### होअर-शैलीतील गुणधर्म {#hoare-style-properties} + +[होअर लॉजिक](https://en.wikipedia.org/wiki/Hoare_logic) स्मार्ट कॉन्ट्रॅक्ट्ससह प्रोग्राम्सच्या अचूकतेबद्दल तर्क करण्यासाठी औपचारिक नियमांचा एक संच प्रदान करते. होअर-शैलीतील गुणधर्म होअर ट्रिपल `{P}c{Q}` द्वारे दर्शविला जातो, जिथे `c` एक प्रोग्राम आहे आणि `P` आणि `Q` हे `c` (म्हणजेच, प्रोग्राम) च्या स्थितीवरील प्रेडिकेट्स आहेत, ज्यांना अनुक्रमे _पूर्वअटी_ आणि _उत्तरअटी_ म्हणून औपचारिकपणे वर्णन केले जाते. + +पूर्वअट ही एक प्रेडिकेट आहे जी फंक्शनच्या योग्य अंमलबजावणीसाठी आवश्यक असलेल्या अटींचे वर्णन करते; कॉन्ट्रॅक्टमध्ये कॉल करणाऱ्या वापरकर्त्यांनी ही आवश्यकता पूर्ण केली पाहिजे. उत्तरअट ही एक प्रेडिकेट आहे जी फंक्शन योग्यरित्या कार्यान्वित झाल्यास स्थापित होणारी स्थिती दर्शवते; फंक्शन कॉल केल्यानंतर वापरकर्ते ही स्थिती खरी होण्याची अपेक्षा करू शकतात. होअर लॉजिकमधील एक _अचल_ (invariant) एक प्रेडिकेट आहे जे फंक्शनच्या अंमलबजावणीद्वारे संरक्षित केले जाते (म्हणजेच ते बदलत नाही). + +होअर-शैलीतील विनिर्देशने _आंशिक अचूकता_ किंवा _संपूर्ण अचूकता_ यांची हमी देऊ शकतात. कॉन्ट्रॅक्ट फंक्शनची अंमलबजावणी "आंशिकपणे योग्य" असते जर फंक्शन कार्यान्वित होण्यापूर्वी पूर्वअट खरी असेल आणि अंमलबजावणी समाप्त झाल्यास, उत्तरअट देखील खरी असते. जर फंक्शन कार्यान्वित होण्यापूर्वी पूर्वअट खरी असेल, अंमलबजावणी समाप्त होण्याची हमी असेल आणि ती समाप्त झाल्यावर उत्तरअट खरी असेल तर संपूर्ण अचूकतेचा पुरावा मिळतो. + +संपूर्ण अचूकतेचा पुरावा मिळवणे कठीण आहे कारण काही अंमलबजावणी समाप्त होण्यापूर्वी विलंब होऊ शकतात, किंवा कधीही समाप्त होत नाहीत. तरीही, अंमलबजावणी समाप्त होते की नाही हा प्रश्न विवादास्पद आहे कारण Ethereum ची गॅस यंत्रणा अनंत प्रोग्राम लूप्सना प्रतिबंधित करते (अंमलबजावणी एकतर यशस्वीरित्या समाप्त होते किंवा 'आउट-ऑफ-गॅस' त्रुटीमुळे संपते). + +होअर लॉजिक वापरून तयार केलेल्या स्मार्ट कॉन्ट्रॅक्ट विनिर्देशनांमध्ये कॉन्ट्रॅक्टमधील फंक्शन्स आणि लूप्सच्या अंमलबजावणीसाठी पूर्वअटी, उत्तरअटी आणि अचल परिभाषित केलेले असतील. पूर्वअटींमध्ये अनेकदा फंक्शनमध्ये चुकीच्या इनपुटची शक्यता समाविष्ट असते, तर उत्तरअटी अशा इनपुटला अपेक्षित प्रतिसाद दर्शवतात (उदा., विशिष्ट अपवाद फेकणे). या प्रकारे होअर-शैलीतील गुणधर्म कॉन्ट्रॅक्ट अंमलबजावणीची अचूकता सुनिश्चित करण्यासाठी प्रभावी आहेत. + +अनेक औपचारिक पडताळणी फ्रेमवर्क फंक्शन्सच्या अर्थपूर्ण अचूकतेचा पुरावा देण्यासाठी होअर-शैलीतील विनिर्देशनांचा वापर करतात. Solidity मध्ये `require` आणि `assert` विधानांचा वापर करून होअर-शैलीतील गुणधर्म (प्रतिपादने म्हणून) थेट कॉन्ट्रॅक्ट कोडमध्ये जोडणे देखील शक्य आहे. + +`require` विधाने पूर्वअट किंवा अचल व्यक्त करतात आणि अनेकदा वापरकर्त्याच्या इनपुटची वैधता तपासण्यासाठी वापरली जातात, तर `assert` सुरक्षिततेसाठी आवश्यक उत्तरअट कॅप्चर करते. उदाहरणार्थ, फंक्शन्ससाठी योग्य प्रवेश नियंत्रण (सुरक्षा गुणधर्माचे उदाहरण) कॉलिंग खात्याच्या ओळखीवर पूर्वअट तपासणी म्हणून `require` वापरून साध्य केले जाऊ शकते. त्याचप्रमाणे, कॉन्ट्रॅक्टमधील स्टेट व्हेरिएबल्सच्या परवानगी असलेल्या मूल्यांवरील अचलता (उदा., चलनात असलेल्या एकूण टोकनची संख्या) फंक्शन अंमलबजावणीनंतर कॉन्ट्रॅक्टची स्थिती निश्चित करण्यासाठी `assert` वापरून उल्लंघनापासून संरक्षित केली जाऊ शकते. + +### ट्रेस-स्तरीय गुणधर्म {#trace-level-properties} + +ट्रेस-आधारित विनिर्देशने अशा ऑपरेशन्सचे वर्णन करतात जे कॉन्ट्रॅक्टला वेगवेगळ्या अवस्थांमध्ये संक्रमण करतात आणि या ऑपरेशन्समधील संबंधांचे वर्णन करतात. आधी स्पष्ट केल्याप्रमाणे, ट्रेसेस म्हणजे ऑपरेशन्सचे अनुक्रम जे कॉन्ट्रॅक्टची स्थिती विशिष्ट प्रकारे बदलतात. + +हा दृष्टीकोन स्मार्ट कॉन्ट्रॅक्ट्सच्या स्टेट-ट्रान्झिशन सिस्टमच्या मॉडेलवर अवलंबून आहे ज्यात काही पूर्वनिर्धारित अवस्था (स्टेट व्हेरिएबल्सद्वारे वर्णन केलेल्या) आणि पूर्वनिर्धारित संक्रमणांचा (कॉन्ट्रॅक्ट फंक्शन्सद्वारे वर्णन केलेल्या) संच असतो. शिवाय, [कंट्रोल फ्लो ग्राफ](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) (CFG), जो प्रोग्रामच्या अंमलबजावणी प्रवाहाचे ग्राफिकल प्रतिनिधित्व आहे, अनेकदा कॉन्ट्रॅक्टच्या ऑपरेशनल सिमेंटिक्सचे वर्णन करण्यासाठी वापरला जातो. येथे, प्रत्येक ट्रेस कंट्रोल फ्लो ग्राफवरील एक मार्ग म्हणून दर्शविला जातो. + +प्राथमिकतः, ट्रेस-स्तरीय विनिर्देशने स्मार्ट कॉन्ट्रॅक्ट्समधील अंतर्गत अंमलबजावणीच्या पॅटर्नबद्दल तर्क करण्यासाठी वापरली जातात. ट्रेस-स्तरीय विनिर्देशने तयार करून, आम्ही स्मार्ट कॉन्ट्रॅक्टसाठी स्वीकार्य अंमलबजावणी मार्गांची (म्हणजेच, स्थिती संक्रमणांची) पुष्टी करतो. प्रतीकात्मक अंमलबजावणी सारख्या तंत्रांचा वापर करून, आम्ही औपचारिकपणे सत्यापित करू शकतो की अंमलबजावणी कधीही औपचारिक मॉडेलमध्ये परिभाषित नसलेल्या मार्गाचे अनुसरण करत नाही. + +चला ट्रेस-स्तरीय गुणधर्मांचे वर्णन करण्यासाठी काही सार्वजनिकरित्या प्रवेशयोग्य फंक्शन्स असलेल्या [DAO](/dao/) कॉन्ट्रॅक्टचे उदाहरण वापरूया. येथे, आम्ही असे गृहीत धरतो की DAO कॉन्ट्रॅक्ट वापरकर्त्यांना खालील ऑपरेशन्स करण्याची परवानगी देतो: + +- निधी जमा करा + +- निधी जमा केल्यानंतर प्रस्तावावर मतदान करा + +- जर त्यांनी प्रस्तावावर मतदान केले नसेल तर परताव्याचा दावा करा + +उदाहरणार्थ, ट्रेस-स्तरीय गुणधर्म असू शकतात _"जे वापरकर्ते निधी जमा करत नाहीत ते प्रस्तावावर मतदान करू शकत नाहीत"_ किंवा _"जे वापरकर्ते प्रस्तावावर मतदान करत नाहीत ते नेहमी परताव्याचा दावा करू शकले पाहिजेत"_. दोन्ही गुणधर्म अंमलबजावणीच्या पसंतीच्या अनुक्रमांची पुष्टी करतात (मतदान निधी जमा करण्या_पूर्वी_ होऊ शकत नाही आणि प्रस्तावावर मतदान केल्या_नंतर_ परताव्याचा दावा होऊ शकत नाही). + +## स्मार्ट कॉन्ट्रॅक्ट्सच्या औपचारिक पडताळणीची तंत्रे {#formal-verification-techniques} + +### मॉडेल तपासणी {#model-checking} + +मॉडेल तपासणी हे एक औपचारिक पडताळणी तंत्र आहे ज्यात एक अल्गोरिदम स्मार्ट कॉन्ट्रॅक्टच्या औपचारिक मॉडेलची त्याच्या विनिर्देशनानुसार तपासणी करते. मॉडेल तपासणीमध्ये स्मार्ट कॉन्ट्रॅक्ट्सना अनेकदा स्टेट-ट्रान्झिशन सिस्टम म्हणून दर्शविले जाते, तर परवानगी असलेल्या कॉन्ट्रॅक्ट अवस्थांवरील गुणधर्म टेम्पोरल लॉजिक वापरून परिभाषित केले जातात. + +मॉडेल तपासणीसाठी सिस्टमचे (म्हणजेच, कॉन्ट्रॅक्टचे) अमूर्त गणितीय प्रतिनिधित्व तयार करणे आणि [प्रपोझिशनल लॉजिक](https://www.baeldung.com/cs/propositional-logic) मध्ये रुजलेल्या सूत्रांचा वापर करून या सिस्टमचे गुणधर्म व्यक्त करणे आवश्यक आहे. हे मॉडेल-चेकिंग अल्गोरिदमचे कार्य सोपे करते, म्हणजेच गणितीय मॉडेल दिलेल्या तार्किक सूत्राची पूर्तता करते हे सिद्ध करणे. + +औपचारिक पडताळणीमध्ये मॉडेल तपासणीचा वापर प्रामुख्याने टेम्पोरल गुणधर्मांचे मूल्यांकन करण्यासाठी केला जातो जे वेळेनुसार कॉन्ट्रॅक्टच्या वर्तनाचे वर्णन करतात. स्मार्ट कॉन्ट्रॅक्ट्ससाठी टेम्पोरल गुणधर्मांमध्ये _सुरक्षितता_ आणि _सजीवता_ यांचा समावेश आहे, ज्यांचे आम्ही पूर्वी स्पष्टीकरण दिले आहे. + +उदाहरणार्थ, प्रवेश नियंत्रणाशी संबंधित सुरक्षा गुणधर्म (उदा., _केवळ कॉन्ट्रॅक्टचा मालक `selfdestruct` कॉल करू शकतो_) औपचारिक तर्कात लिहिला जाऊ शकतो. त्यानंतर, मॉडेल-चेकिंग अल्गोरिदम कॉन्ट्रॅक्ट या औपचारिक विनिर्देशनाचे समाधान करतो की नाही हे सत्यापित करू शकतो. + +मॉडेल तपासणी स्टेट स्पेस एक्सप्लोरेशन वापरते, ज्यात स्मार्ट कॉन्ट्रॅक्टच्या सर्व संभाव्य अवस्था तयार करणे आणि गुणधर्म उल्लंघनास कारणीभूत ठरणार्‍या पोहोचण्यायोग्य अवस्था शोधण्याचा प्रयत्न करणे समाविष्ट आहे. तथापि, यामुळे अनंत अवस्था निर्माण होऊ शकतात (ज्याला "स्टेट एक्सप्लोजन प्रॉब्लेम" म्हणतात), म्हणून मॉडेल चेकर्स स्मार्ट कॉन्ट्रॅक्ट्सचे कार्यक्षम विश्लेषण शक्य करण्यासाठी अमूर्तता तंत्रांवर अवलंबून असतात. + +### प्रमेय सिद्ध करणे {#theorem-proving} + +प्रमेय सिद्ध करणे ही स्मार्ट कॉन्ट्रॅक्ट्ससह प्रोग्राम्सच्या अचूकतेबद्दल गणितीयरित्या तर्क करण्याची एक पद्धत आहे. यात कॉन्ट्रॅक्टच्या सिस्टमच्या मॉडेलचे आणि त्याच्या विनिर्देशनांचे गणितीय सूत्रांमध्ये (तार्किक विधानांमध्ये) रूपांतर करणे समाविष्ट आहे. + +प्रमेय सिद्ध करण्याचे उद्दिष्ट या विधानांमधील तार्किक समानतेची पडताळणी करणे आहे. “लॉजिकल इक्विव्हॅलेन्स” (ज्याला “लॉजिकल बाय-इम्प्लिकेशन” असेही म्हणतात) हा दोन विधानांमधील एक प्रकारचा संबंध आहे ज्यामध्ये पहिले विधान खरे असते _जर आणि केवळ जर_ दुसरे विधान खरे असेल. + +कॉन्ट्रॅक्टच्या मॉडेल आणि त्याच्या गुणधर्मांबद्दलच्या विधानांमधील आवश्यक संबंध (लॉजिकल इक्विव्हॅलेन्स) एक सिद्ध करण्यायोग्य विधान (ज्याला प्रमेय म्हणतात) म्हणून तयार केला जातो. अनुमानाची औपचारिक प्रणाली वापरून, स्वयंचलित प्रमेय प्रोव्हर प्रमेयाच्या वैधतेची पडताळणी करू शकतो. दुसऱ्या शब्दांत, एक प्रमेय प्रोव्हर निर्णायकपणे सिद्ध करू शकतो की स्मार्ट कॉन्ट्रॅक्टचे मॉडेल त्याच्या विनिर्देशनांशी तंतोतंत जुळते. + +मॉडेल तपासणी कॉन्ट्रॅक्ट्सना मर्यादित अवस्थांसह संक्रमण प्रणाली म्हणून मॉडेल करते, तर प्रमेय सिद्ध करणे अनंत-अवस्था प्रणालींचे विश्लेषण हाताळू शकते. तथापि, याचा अर्थ असा की स्वयंचलित प्रमेय प्रोव्हरला नेहमीच माहित नसते की एखादी लॉजिक समस्या "निर्णयक्षम" आहे की नाही. + +परिणामी, अचूकतेचे पुरावे मिळवण्यासाठी प्रमेय प्रोव्हरला मार्गदर्शन करण्यासाठी अनेकदा मानवी मदतीची आवश्यकता असते. प्रमेय सिद्ध करण्यामध्ये मानवी प्रयत्नांच्या वापरामुळे ते मॉडेल तपासणीपेक्षा अधिक महाग होते, जे पूर्णपणे स्वयंचलित आहे. + +### प्रतीकात्मक अंमलबजावणी {#symbolic-execution} + +प्रतीकात्मक अंमलबजावणी ही _ठोस मूल्यां_ऐवजी (उदा., `x == 5`) _प्रतीकात्मक मूल्यां_चा (उदा., `x > 5`) वापर करून फंक्शन्स कार्यान्वित करून स्मार्ट कॉन्ट्रॅक्टचे विश्लेषण करण्याची एक पद्धत आहे. औपचारिक पडताळणी तंत्र म्हणून, प्रतीकात्मक अंमलबजावणीचा वापर कॉन्ट्रॅक्टच्या कोडमधील ट्रेस-स्तरीय गुणधर्मांबद्दल औपचारिकपणे तर्क करण्यासाठी केला जातो. + +प्रतीकात्मक अंमलबजावणी एका अंमलबजावणी ट्रेसला प्रतीकात्मक इनपुट मूल्यांवरील गणितीय सूत्र म्हणून दर्शवते, ज्याला _पाथ प्रेडिकेट_ असेही म्हणतात. [SMT सॉल्व्हर](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories) चा वापर पाथ प्रेडिकेट "सॅटिस्फायेबल" आहे की नाही हे तपासण्यासाठी केला जातो (म्हणजे, असे मूल्य अस्तित्वात आहे जे सूत्र पूर्ण करू शकते). जर एखादा असुरक्षित मार्ग सॅटिस्फायेबल असेल, तर SMT सॉल्व्हर एक ठोस मूल्य निर्माण करेल जे अंमलबजावणीला त्या मार्गाकडे वळवते. + +समजा एका स्मार्ट कॉन्ट्रॅक्टचे फंक्शन इनपुट म्हणून `uint` मूल्य (`x`) घेते आणि जेव्हा `x` हे `5` पेक्षा मोठे आणि `10` पेक्षा लहान असते तेव्हा रिव्हर्ट होते. सामान्य चाचणी प्रक्रियेचा वापर करून `x` साठी असे मूल्य शोधण्यासाठी जे त्रुटी ट्रिगर करते, डझनभर (किंवा अधिक) चाचणी प्रकरणे चालवावी लागतील आणि त्रुटी-ट्रिगरिंग इनपुट खरोखरच सापडेल याची खात्री नसेल. + +याउलट, एक प्रतीकात्मक अंमलबजावणी साधन फंक्शनला प्रतीकात्मक मूल्याने कार्यान्वित करेल: `X > 5 ∧ X < 10` (म्हणजेच, `x` हे 5 पेक्षा मोठे आहे आणि `x` हे 10 पेक्षा लहान आहे). संबंधित पाथ प्रेडिकेट `x = X > 5 ∧ X < 10` नंतर निराकरण करण्यासाठी SMT सॉल्व्हरला दिले जाईल. जर एखादे विशिष्ट मूल्य `x = X > 5 ∧ X < 10` हे सूत्र पूर्ण करत असेल, तर SMT सॉल्व्हर ते मोजेल—उदाहरणार्थ, सॉल्व्हर `x` साठी मूल्य म्हणून `7` तयार करू शकतो. + +कारण प्रतीकात्मक अंमलबजावणी प्रोग्रामच्या इनपुटवर अवलंबून असते, आणि सर्व पोहोचण्यायोग्य अवस्था शोधण्यासाठी इनपुटचा संच संभाव्यतः अनंत असतो, त्यामुळे हे अजूनही चाचणीचे एक रूप आहे. तथापि, उदाहरणामध्ये दाखवल्याप्रमाणे, गुणधर्म उल्लंघनांना चालना देणारे इनपुट शोधण्यासाठी प्रतीकात्मक अंमलबजावणी नियमित चाचणीपेक्षा अधिक कार्यक्षम आहे. + +शिवाय, प्रतीकात्मक अंमलबजावणी इतर गुणधर्म-आधारित तंत्रांपेक्षा (उदा., फझिंग) कमी चुकीचे सकारात्मक परिणाम देते जे फंक्शनला यादृच्छिकपणे इनपुट तयार करतात. जर प्रतीकात्मक अंमलबजावणी दरम्यान त्रुटीची स्थिती ट्रिगर झाली, तर त्रुटी ट्रिगर करणारे ठोस मूल्य तयार करणे आणि समस्येचे पुनरुत्पादन करणे शक्य आहे. + +प्रतीकात्मक अंमलबजावणी अचूकतेचा काही प्रमाणात गणितीय पुरावा देखील देऊ शकते. ओव्हरफ्लो संरक्षणासह कॉन्ट्रॅक्ट फंक्शनचे खालील उदाहरण विचारात घ्या: + +``` +function safe_add(uint x, uint y) returns(uint z){ + + z = x + y; + require(z>=x); + require(z>=y); + + return z; +} +``` + +पूर्णांक ओव्हरफ्लो होणाऱ्या अंमलबजावणी ट्रेसला `z = x + y AND (z >= x) AND (z >= y) AND (z < x OR z < y)` हे सूत्र पूर्ण करावे लागेल. असे सूत्र सोडवले जाण्याची शक्यता नाही, म्हणून ते `safe_add` फंक्शन कधीही ओव्हरफ्लो होत नाही याचा गणितीय पुरावा म्हणून काम करते. + +### स्मार्ट कॉन्ट्रॅक्ट्ससाठी औपचारिक पडताळणी का वापरावी? {#benefits-of-formal-verification} + +#### विश्वसनीयतेची गरज {#need-for-reliability} + +औपचारिक पडताळणीचा वापर सुरक्षितता-गंभीर प्रणालींच्या अचूकतेचे मूल्यांकन करण्यासाठी केला जातो ज्यांच्या अपयशामुळे मृत्यू, इजा किंवा आर्थिक नुकसान यांसारखे विनाशकारी परिणाम होऊ शकतात. स्मार्ट कॉन्ट्रॅक्ट्स हे उच्च-मूल्याचे ॲप्लिकेशन्स आहेत जे प्रचंड प्रमाणात मूल्य नियंत्रित करतात, आणि डिझाइनमधील साध्या चुकांमुळे [वापरकर्त्यांना भरून न येणारे नुकसान होऊ शकते](https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce/amp/). तथापि, उपयोजनापूर्वी कॉन्ट्रॅक्टची औपचारिक पडताळणी केल्याने, ब्लॉकचेनवर चालल्यावर ते अपेक्षेप्रमाणे कार्य करेल याची हमी वाढू शकते. + +कोणत्याही स्मार्ट कॉन्ट्रॅक्टमध्ये विश्वसनीयता हा अत्यंत इष्ट गुण आहे, विशेषतः कारण Ethereum व्हर्च्युअल मशीन (EVM) मध्ये तैनात केलेला कोड सामान्यतः अपरिवर्तनीय असतो. लॉन्च-नंतरचे अपग्रेड सहज उपलब्ध नसल्यामुळे, कॉन्ट्रॅक्ट्सच्या विश्वसनीयतेची हमी देण्याची गरज औपचारिक पडताळणी आवश्यक करते. औपचारिक पडताळणी इंटीजर अंडरफ्लो आणि ओव्हरफ्लो, री-एन्ट्रन्सी आणि खराब गॅस ऑप्टिमायझेशन यांसारख्या अवघड समस्या शोधू शकते, ज्या ऑडिटर्स आणि टेस्टर्सकडून सुटू शकतात. + +#### कार्यात्मक अचूकता सिद्ध करा {#prove-functional-correctness} + +स्मार्ट कॉन्ट्रॅक्ट काही आवश्यकता पूर्ण करतो हे सिद्ध करण्याची सर्वात सामान्य पद्धत प्रोग्राम चाचणी आहे. यामध्ये कॉन्ट्रॅक्टला अपेक्षित असलेल्या डेटाच्या नमुन्यासह कार्यान्वित करणे आणि त्याच्या वर्तनाचे विश्लेषण करणे समाविष्ट आहे. जर कॉन्ट्रॅक्ट नमुना डेटासाठी अपेक्षित परिणाम देत असेल, तर डेव्हलपर्सकडे त्याच्या अचूकतेचा वस्तुनिष्ठ पुरावा असतो. + +तथापि, हा दृष्टिकोन नमुन्याचा भाग नसलेल्या इनपुट मूल्यांसाठी योग्य अंमलबजावणी सिद्ध करू शकत नाही. म्हणून, कॉन्ट्रॅक्टची चाचणी बग शोधण्यात मदत करू शकते (म्हणजे, अंमलबजावणी दरम्यान काही कोड पाथ इच्छित परिणाम देत नसतील तर), पण **ते बगच्या अनुपस्थितीचा निर्णायक पुरावा देऊ शकत नाही**. + +याउलट, औपचारिक पडताळणी औपचारिकपणे सिद्ध करू शकते की स्मार्ट कॉन्ट्रॅक्ट कॉन्ट्रॅक्ट चालवल्या_शिवाय_ अनंत अंमलबजावणीसाठी आवश्यकता पूर्ण करतो. यासाठी एक औपचारिक विनिर्देशन तयार करणे आवश्यक आहे जे योग्य कॉन्ट्रॅक्ट वर्तनांचे अचूक वर्णन करते आणि कॉन्ट्रॅक्टच्या सिस्टमचे एक औपचारिक (गणितीय) मॉडेल विकसित करणे आवश्यक आहे. नंतर आम्ही कॉन्ट्रॅक्टच्या मॉडेल आणि त्याच्या विनिर्देशनामध्ये सुसंगतता तपासण्यासाठी औपचारिक पुरावा प्रक्रियेचे अनुसरण करू शकतो. + +औपचारिक पडताळणीसह, कॉन्ट्रॅक्टचा व्यावसायिक तर्क आवश्यकता पूर्ण करतो की नाही हे सत्यापित करण्याचा प्रश्न एक गणितीय प्रस्ताव आहे जो सिद्ध किंवा असिद्ध केला जाऊ शकतो. औपचारिकपणे प्रस्ताव सिद्ध करून, आम्ही मर्यादित संख्येच्या चरणांसह अनंत संख्येच्या चाचणी प्रकरणांची पडताळणी करू शकतो. या प्रकारे औपचारिक पडताळणीला विनिर्देशनाच्या संदर्भात कॉन्ट्रॅक्ट कार्यात्मकदृष्ट्या योग्य आहे हे सिद्ध करण्याची चांगली शक्यता असते. + +#### आदर्श पडताळणी लक्ष्ये {#ideal-verification-targets} + +पडताळणी लक्ष्य औपचारिकपणे सत्यापित करायच्या प्रणालीचे वर्णन करते. औपचारिक पडताळणीचा वापर "एम्बेडेड सिस्टम्स" मध्ये सर्वोत्तम होतो (मोठ्या प्रणालीचा भाग असलेले लहान, साधे सॉफ्टवेअरचे तुकडे). ते विशेष डोमेनसाठी देखील आदर्श आहेत ज्यात कमी नियम आहेत, कारण यामुळे डोमेन-विशिष्ट गुणधर्मांची पडताळणी करण्यासाठी साधने सुधारणे सोपे होते. + +स्मार्ट कॉन्ट्रॅक्ट्स—किमान, काही प्रमाणात—दोन्ही आवश्यकता पूर्ण करतात. उदाहरणार्थ, Ethereum कॉन्ट्रॅक्ट्सचा लहान आकार त्यांना औपचारिक पडताळणीसाठी अनुकूल बनवतो. त्याचप्रमाणे, EVM सोप्या नियमांचे पालन करते, ज्यामुळे EVM मध्ये चालणाऱ्या प्रोग्राम्ससाठी सिमेंटिक गुणधर्म निर्दिष्ट करणे आणि सत्यापित करणे सोपे होते. + +### जलद विकास चक्र {#faster-development-cycle} + +मॉडेल तपासणी आणि प्रतीकात्मक अंमलबजावणी यांसारखी औपचारिक पडताळणी तंत्रे साधारणपणे स्मार्ट कॉन्ट्रॅक्ट कोडच्या नियमित विश्लेषणापेक्षा (चाचणी किंवा ऑडिटिंग दरम्यान केल्या जाणाऱ्या) अधिक कार्यक्षम असतात. याचे कारण असे की औपचारिक पडताळणी प्रतिपादनांची चाचणी घेण्यासाठी प्रतीकात्मक मूल्यांवर अवलंबून असते ("जर वापरकर्त्याने _n_ ईथर काढण्याचा प्रयत्न केला तर काय होईल?"). चाचणीच्या विपरीत जी ठोस मूल्ये वापरते ("जर वापरकर्त्याने 5 ईथर काढण्याचा प्रयत्न केला तर काय होईल?"). + +प्रतीकात्मक इनपुट व्हेरिएबल्स ठोस मूल्यांच्या अनेक वर्गांना कव्हर करू शकतात, त्यामुळे औपचारिक पडताळणी दृष्टिकोन कमी वेळेत अधिक कोड कव्हरेजचे वचन देतात. प्रभावीपणे वापरल्यास, औपचारिक पडताळणी डेव्हलपर्ससाठी विकास चक्र गतिमान करू शकते. + +औपचारिक पडताळणी खर्चिक डिझाइन त्रुटी कमी करून विकेंद्रित ॲप्लिकेशन्स (dapps) तयार करण्याची प्रक्रिया सुधारते. असुरक्षितता दूर करण्यासाठी कॉन्ट्रॅक्ट्स अपग्रेड करण्यासाठी (जेथे शक्य असेल) कोडबेसचे विस्तृत पुनर्लेखन आणि विकासावर अधिक प्रयत्न आवश्यक आहेत. औपचारिक पडताळणी कॉन्ट्रॅक्ट अंमलबजावणीमधील अनेक त्रुटी शोधू शकते ज्या टेस्टर्स आणि ऑडिटर्सकडून सुटू शकतात आणि कॉन्ट्रॅक्ट तैनात करण्यापूर्वी त्या समस्या दूर करण्याची पुरेशी संधी देते. + +## औपचारिक पडताळणीचे तोटे {#drawbacks-of-formal-verification} + +### मॅन्युअल श्रमाचा खर्च {#cost-of-manual-labor} + +औपचारिक पडताळणी, विशेषतः अर्ध-स्वयंचलित पडताळणी ज्यात मानव प्रोव्हरला अचूकतेचे पुरावे मिळवण्यासाठी मार्गदर्शन करतो, त्यासाठी मोठ्या प्रमाणात मॅन्युअल श्रम आवश्यक आहेत. शिवाय, औपचारिक विनिर्देशन तयार करणे ही एक जटिल क्रिया आहे ज्यासाठी उच्च पातळीचे कौशल्य आवश्यक आहे. + +हे घटक (प्रयत्न आणि कौशल्य) औपचारिक पडताळणीला कॉन्ट्रॅक्ट्समधील अचूकतेचे मूल्यांकन करण्याच्या नेहमीच्या पद्धतींपेक्षा, जसे की चाचणी आणि ऑडिट, अधिक मागणीपूर्ण आणि महाग बनवतात. तरीही, स्मार्ट कॉन्ट्रॅक्ट अंमलबजावणीतील त्रुटींचा खर्च पाहता, पूर्ण पडताळणी ऑडिटसाठी खर्च करणे व्यावहारिक आहे. + +### खोटे नकारात्मक {#false-negatives} + +औपचारिक पडताळणी केवळ स्मार्ट कॉन्ट्रॅक्टची अंमलबजावणी औपचारिक विनिर्देशनाशी जुळते की नाही हे तपासू शकते. त्यामुळे, विनिर्देशन स्मार्ट कॉन्ट्रॅक्टच्या अपेक्षित वर्तनांचे योग्यरित्या वर्णन करते याची खात्री करणे महत्त्वाचे आहे. + +जर विनिर्देशने खराब लिहिलेली असतील, तर गुणधर्मांचे उल्लंघन—जे असुरक्षित अंमलबजावणीकडे निर्देश करतात—औपचारिक पडताळणी ऑडिटद्वारे शोधले जाऊ शकत नाहीत. या प्रकरणात, डेव्हलपर चुकीने समजू शकतो की कॉन्ट्रॅक्ट बग-मुक्त आहे. + +### कार्यप्रदर्शन समस्या {#performance-issues} + +औपचारिक पडताळणीमध्ये अनेक कार्यप्रदर्शन समस्या येतात. उदाहरणार्थ, मॉडेल तपासणी आणि प्रतीकात्मक तपासणी दरम्यान अनुक्रमे येणाऱ्या स्टेट आणि पाथ एक्सप्लोजन समस्या पडताळणी प्रक्रियांना प्रभावित करू शकतात. तसेच, औपचारिक पडताळणी साधने अनेकदा त्यांच्या अंतर्निहित स्तरावर SMT सॉल्व्हर्स आणि इतर कंस्ट्रेंट सॉल्व्हर्स वापरतात, आणि हे सॉल्व्हर्स संगणकीयदृष्ट्या गहन प्रक्रियांवर अवलंबून असतात. + +तसेच, प्रोग्राम व्हेरिफायर्सना नेहमीच हे ठरवणे शक्य नसते की एखादा गुणधर्म (लॉजिकल फॉर्म्युला म्हणून वर्णन केलेला) पूर्ण केला जाऊ शकतो की नाही (the "[decidability problem](https://en.wikipedia.org/wiki/Decision_problem)") कारण प्रोग्राम कधीही समाप्त होऊ शकत नाही. त्यामुळे, कॉन्ट्रॅक्ट व्यवस्थित निर्दिष्ट केलेला असला तरीही काही गुणधर्म सिद्ध करणे अशक्य असू शकते. + +## Ethereum स्मार्ट कॉन्ट्रॅक्ट्ससाठी औपचारिक पडताळणी साधने {#formal-verification-tools} + +### औपचारिक विनिर्देशने तयार करण्यासाठी विनिर्देशन भाषा {#specification-languages} + +**Act**: __Act स्टोरेज अद्यतने, पूर्व/उत्तर अटी आणि कॉन्ट्रॅक्ट अचलांचे विनिर्देशन करण्याची परवानगी देते. त्याच्या टूल सूटमध्ये पुरावा बॅकएंड्स देखील आहेत जे Coq, SMT सॉल्व्हर्स किंवा hevm द्वारे अनेक गुणधर्म सिद्ध करण्यास सक्षम आहेत.__ + +- [GitHub](https://github.com/ethereum/act) +- [दस्तऐवजीकरण](https://github.com/argotorg/act) + +**Scribble** - __Scribble, Scribble विनिर्देशन भाषेतील कोड भाष्यांना ठोस प्रतिपादनांमध्ये रूपांतरित करते जे विनिर्देशन तपासतात.__ + +- [दस्तऐवजीकरण](https://docs.scribble.codes/) + +**Dafny** - __Dafny ही पडताळणी-तयार प्रोग्रामिंग भाषा आहे जी कोडच्या अचूकतेबद्दल तर्क करण्यासाठी आणि सिद्ध करण्यासाठी उच्च-स्तरीय भाष्यांवर अवलंबून असते.__ + +- [GitHub](https://github.com/dafny-lang/dafny) + +### अचूकता तपासण्यासाठी प्रोग्राम व्हेरिफायर्स {#program-verifiers} + +**Certora Prover** - _Certora Prover हे स्मार्ट कॉन्ट्रॅक्ट्समधील कोडची अचूकता तपासण्यासाठी एक स्वयंचलित औपचारिक पडताळणी साधन आहे. विनिर्देशने CVL (Certora व्हेरिफिकेशन लँग्वेज) मध्ये लिहिली जातात, ज्यात स्टॅटिक विश्लेषण आणि कंस्ट्रेंट-सॉल्व्हिंगच्या संयोगाने गुणधर्म उल्लंघने शोधली जातात._ + +- [वेबसाइट](https://www.certora.com/) +- [दस्तऐवजीकरण](https://docs.certora.com/en/latest/index.html) + +**Solidity SMTChecker** - __Solidity चे SMTChecker हे SMT (सॅटिस्फायबिलिटी मॉड्युलो थिअरीज) आणि हॉर्न सॉल्विंगवर आधारित एक अंगभूत मॉडेल तपासक आहे. ते संकलनादरम्यान कॉन्ट्रॅक्टचा सोर्स कोड विनिर्देशनांशी जुळतो की नाही याची पुष्टी करते आणि सुरक्षितता गुणधर्मांच्या उल्लंघनांसाठी स्थिरपणे तपासते.__ + +- [GitHub](https://github.com/ethereum/solidity) + +**solc-verify** - __solc-verify ही Solidity कंपाइलरची विस्तारित आवृत्ती आहे जी भाष्यांचा आणि मॉड्यूलर प्रोग्राम पडताळणीचा वापर करून Solidity कोडवर स्वयंचलित औपचारिक पडताळणी करू शकते.__ + +- [GitHub](https://github.com/SRI-CSL/solidity) + +**KEVM** - __KEVM हे K फ्रेमवर्कमध्ये लिहिलेले Ethereum व्हर्च्युअल मशीन (EVM) चे औपचारिक सिमेंटिक्स आहे. KEVM कार्यान्वित करण्यायोग्य आहे आणि रीचेबिलिटी लॉजिक वापरून काही गुणधर्म-संबंधित प्रतिपादने सिद्ध करू शकते.__ + +- [GitHub](https://github.com/runtimeverification/evm-semantics) +- [दस्तऐवजीकरण](https://jellopaper.org/) + +### प्रमेय सिद्ध करण्यासाठी तार्किक फ्रेमवर्क {#theorem-provers} + +**Isabelle** - _Isabelle/HOL एक पुरावा सहाय्यक आहे जो गणितीय सूत्रांना औपचारिक भाषेत व्यक्त करण्याची परवानगी देतो आणि ती सूत्रे सिद्ध करण्यासाठी साधने प्रदान करतो. मुख्य ॲप्लिकेशन गणितीय पुराव्यांचे औपचारिकीकरण आणि विशेषतः औपचारिक पडताळणी आहे, ज्यात संगणक हार्डवेअर किंवा सॉफ्टवेअरची अचूकता सिद्ध करणे आणि संगणक भाषा आणि प्रोटोकॉलचे गुणधर्म सिद्ध करणे समाविष्ट आहे._ + +- [GitHub](https://github.com/isabelle-prover) +- [दस्तऐवजीकरण](https://isabelle.in.tum.de/documentation.html) + +**Rocq** - _Rocq एक इंटरॅक्टिव्ह प्रमेय प्रोव्हर आहे जो तुम्हाला प्रमेयांचा वापर करून प्रोग्राम्स परिभाषित करू देतो आणि अचूकतेचे मशीन-चेक्ड पुरावे इंटरॅक्टिव्हपणे तयार करू देतो._ + +- [GitHub](https://github.com/rocq-prover/rocq) +- [दस्तऐवजीकरण](https://rocq-prover.org/docs) + +### स्मार्ट कॉन्ट्रॅक्ट्समध्ये असुरक्षित नमुने शोधण्यासाठी प्रतीकात्मक अंमलबजावणी-आधारित साधने {#symbolic-execution-tools} + +**Manticore** - __प्रतीकात्मक अंमलबजावणीवर आधारित EVM बायकोड विश्लेषणासाठी एक साधन_._ + +- [GitHub](https://github.com/trailofbits/manticore) +- [दस्तऐवजीकरण](https://github.com/trailofbits/manticore/wiki) + +**hevm** - __hevm हे EVM बायकोडसाठी एक प्रतीकात्मक अंमलबजावणी इंजिन आणि समतुल्यता तपासक आहे.__ + +- [GitHub](https://github.com/dapphub/dapptools/tree/master/src/hevm) + +**Mythril** - _Ethereum स्मार्ट कॉन्ट्रॅक्ट्समधील असुरक्षितता शोधण्यासाठी एक प्रतीकात्मक अंमलबजावणी साधन_ + +- [GitHub](https://github.com/ConsenSys/mythril-classic) +- [दस्तऐवजीकरण](https://mythril-classic.readthedocs.io/en/develop/) + +## पुढील वाचन {#further-reading} + +- [स्मार्ट कॉन्ट्रॅक्ट्सची औपचारिक पडताळणी कशी कार्य करते](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/) +- [औपचारिक पडताळणी निर्दोष स्मार्ट कॉन्ट्रॅक्ट्स कसे सुनिश्चित करू शकते](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1) +- [Ethereum इकोसिस्टममधील औपचारिक पडताळणी प्रकल्पांचा आढावा](https://github.com/leonardoalt/ethereum_formal_verification_overview) +- [Ethereum 2.0 डिपॉझिट स्मार्ट कॉन्ट्रॅक्टची एंड-टू-एंड औपचारिक पडताळणी](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/) +- [जगातील सर्वात लोकप्रिय स्मार्ट कॉन्ट्रॅक्टची औपचारिक पडताळणी](https://www.zellic.io/blog/formal-verification-weth) +- [SMTChecker आणि औपचारिक पडताळणी](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html) diff --git a/public/content/translations/mr/developers/docs/smart-contracts/index.md b/public/content/translations/mr/developers/docs/smart-contracts/index.md new file mode 100644 index 00000000000..59c0698289e --- /dev/null +++ b/public/content/translations/mr/developers/docs/smart-contracts/index.md @@ -0,0 +1,112 @@ +--- +title: "स्मार्ट कॉन्ट्रॅक्टची ओळख" +description: "स्मार्ट कॉन्ट्रॅक्ट्सचे अवलोकन, त्यांच्या अद्वितीय वैशिष्ट्यांवर आणि मर्यादांवर लक्ष केंद्रित करणे." +lang: mr +--- + +## स्मार्ट कॉन्ट्रॅक्ट म्हणजे काय? {#what-is-a-smart-contract} + +"स्मार्ट कॉन्ट्रॅक्ट" हा फक्त इथेरिअम ब्लॉकचेनवर चालणारा एक प्रोग्राम आहे. हा कोड (त्याची फंक्शन्स) आणि डेटा (त्याची स्टेट) यांचा संग्रह आहे जो इथेरिअम ब्लॉकचेनवरील विशिष्ट ॲड्रेसवर असतो. + +स्मार्ट कॉन्ट्रॅक्ट्स हे [इथेरिअम अकाउंट](/developers/docs/accounts/) चा एक प्रकार आहेत. याचा अर्थ त्यांच्याकडे बॅलन्स असतो आणि ते व्यवहारांचे लक्ष्य असू शकतात. तथापि ते वापरकर्त्याद्वारे नियंत्रित केले जात नाहीत, त्याऐवजी ते नेटवर्कवर तैनात केले जातात आणि प्रोग्राम केल्यानुसार चालतात. वापरकर्ता खाती स्मार्ट कॉन्ट्रॅक्टवर परिभाषित फंक्शन कार्यान्वित करणाऱ्या व्यवहारांना सबमिट करून स्मार्ट कॉन्ट्रॅक्टशी संवाद साधू शकतात. स्मार्ट कॉन्ट्रॅक्ट्स नियमित कराराप्रमाणे नियम परिभाषित करू शकतात आणि कोडद्वारे त्यांची आपोआप अंमलबजावणी करू शकतात. स्मार्ट कॉन्ट्रॅक्ट्स डीफॉल्टनुसार हटवले जाऊ शकत नाहीत आणि त्यांच्यासोबतचे संवाद अपरिवर्तनीय आहेत. + +## पूर्वतयारी {#prerequisites} + +तुम्ही नुकतीच सुरुवात करत असाल किंवा कमी तांत्रिक परिचय शोधत असाल, तर आम्ही आमच्या [स्मार्ट कॉन्ट्रॅक्ट्सच्या परिचयाची](/smart-contracts/) शिफारस करतो. + +स्मार्ट कॉन्ट्रॅक्ट्सच्या जगात प्रवेश करण्यापूर्वी तुम्ही [खाती](/developers/docs/accounts/), [व्यवहार](/developers/docs/transactions/) आणि [इथेरिअम व्हर्च्युअल मशीन](/developers/docs/evm/) बद्दल वाचले असल्याची खात्री करा. + +## एक डिजिटल वेंडिंग मशीन {#a-digital-vending-machine} + +[निक स्झाबो](https://unenumerated.blogspot.com/) यांनी वर्णन केल्याप्रमाणे, स्मार्ट कॉन्ट्रॅक्टसाठी कदाचित सर्वोत्तम रूपक वेंडिंग मशीन आहे. योग्य इनपुटसह, विशिष्ट आउटपुटची हमी दिली जाते. + +वेंडिंग मशीनमधून स्नॅक मिळवण्यासाठी: + +``` +money + snack selection = snack dispensed +``` + +हे लॉजिक वेंडिंग मशीनमध्ये प्रोग्राम केलेले आहे. + +वेंडिंग मशीनप्रमाणेच स्मार्ट कॉन्ट्रॅक्टमध्ये लॉजिक प्रोग्राम केलेले असते. सॉलिडिटीमध्ये लिहिलेला स्मार्ट कॉन्ट्रॅक्ट असल्यास हे वेंडिंग मशीन कसे दिसेल याचे एक सोपे उदाहरण येथे आहे: + +```solidity +pragma solidity 0.8.7; + +contract VendingMachine { + + // Declare state variables of the contract + address public owner; + mapping (address => uint) public cupcakeBalances; + + // When 'VendingMachine' contract is deployed: + // 1. set the deploying address as the owner of the contract + // 2. set the deployed smart contract's cupcake balance to 100 + constructor() { + owner = msg.sender; + cupcakeBalances[address(this)] = 100; + } + + // Allow the owner to increase the smart contract's cupcake balance + function refill(uint amount) public { + require(msg.sender == owner, "Only the owner can refill."); + cupcakeBalances[address(this)] += amount; + } + + // Allow anyone to purchase cupcakes + function purchase(uint amount) public payable { + require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake"); + require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase"); + cupcakeBalances[address(this)] -= amount; + cupcakeBalances[msg.sender] += amount; + } +} +``` + +ज्याप्रमाणे वेंडिंग मशीनमुळे विक्रेता कर्मचाऱ्याची गरज नाहीशी होते, त्याचप्रमाणे स्मार्ट कॉन्ट्रॅक्ट अनेक उद्योगांमधील मध्यस्थांची जागा घेऊ शकतात. + +## परवानगीविरहित {#permissionless} + +कोणीही स्मार्ट कॉन्ट्रॅक्ट लिहू शकतो आणि ते नेटवर्कवर तैनात करू शकतो. तुम्हाला फक्त [स्मार्ट कॉन्ट्रॅक्ट भाषेत](/developers/docs/smart-contracts/languages/) कोड कसे करायचे हे शिकण्याची आणि तुमचा कॉन्ट्रॅक्ट तैनात करण्यासाठी पुरेसा ETH असणे आवश्यक आहे. स्मार्ट कॉन्ट्रॅक्ट तैनात करणे हे तांत्रिकदृष्ट्या एक व्यवहार आहे, त्यामुळे तुम्हाला साध्या ETH हस्तांतरणासाठी गॅस द्यावा लागतो त्याच प्रकारे [गॅस](/developers/docs/gas/) द्यावा लागेल. तथापि, कॉन्ट्रॅक्ट तैनात करण्यासाठी गॅस खर्च खूप जास्त असतो. + +इथेरिअममध्ये स्मार्ट कॉन्ट्रॅक्ट लिहिण्यासाठी डेव्हलपर-अनुकूल भाषा आहेत: + +- Solidity +- Vyper + +[भाषांबद्दल अधिक](/developers/docs/smart-contracts/languages/) + +तथापि, ते तैनात करण्यापूर्वी त्यांना संकलित करणे आवश्यक आहे जेणेकरून इथेरिअमचे व्हर्च्युअल मशीन कॉन्ट्रॅक्टचा अर्थ लावू शकेल आणि संचयित करू शकेल. [संकलनाबद्दल अधिक](/developers/docs/smart-contracts/compiling/) + +## कंपोझिबिलिटी {#composability} + +स्मार्ट कॉन्ट्रॅक्ट इथेरिअमवर सार्वजनिक आहेत आणि त्यांना मुक्त API म्हणून मानले जाऊ शकते. याचा अर्थ तुम्ही तुमच्या स्वतःच्या स्मार्ट कॉन्ट्रॅक्टमध्ये इतर स्मार्ट कॉन्ट्रॅक्ट्सना कॉल करू शकता जेणेकरून जे शक्य आहे ते मोठ्या प्रमाणात वाढवता येईल. कॉन्ट्रॅक्ट्स इतर कॉन्ट्रॅक्ट्स देखील तैनात करू शकतात. + +[स्मार्ट कॉन्ट्रॅक्ट कंपोझिबिलिटी](/developers/docs/smart-contracts/composability/) बद्दल अधिक जाणून घ्या. + +## मर्यादा {#limitations} + +स्मार्ट कॉन्ट्रॅक्ट्स एकटे "वास्तविक-जगातील" घटनांबद्दल माहिती मिळवू शकत नाहीत कारण ते ऑफचेन स्त्रोतांकडून डेटा मिळवू शकत नाहीत. याचा अर्थ ते वास्तविक जगातील घटनांना प्रतिसाद देऊ शकत नाहीत. हे डिझाइननुसार आहे. बाह्य माहितीवर अवलंबून राहण्याने सहमती धोक्यात येऊ शकते, जी सुरक्षा आणि विकेंद्रीकरणासाठी महत्त्वाची आहे. + +तथापि, ब्लॉकचेन ॲप्लिकेशन्ससाठी ऑफचेन डेटा वापरता येणे महत्त्वाचे आहे. यावरील उपाय म्हणजे [ऑरेकल्स](/developers/docs/oracles/) जे ऑफचेन डेटा घेतात आणि स्मार्ट कॉन्ट्रॅक्ट्ससाठी उपलब्ध करतात. + +स्मार्ट कॉन्ट्रॅक्ट्सची आणखी एक मर्यादा म्हणजे कमाल कॉन्ट्रॅक्ट आकार. एक स्मार्ट कॉन्ट्रॅक्ट जास्तीत जास्त 24KB असू शकतो अन्यथा त्याचा गॅस संपेल. [डायमंड पॅटर्न](https://eips.ethereum.org/EIPS/eip-2535) वापरून हे टाळता येऊ शकते. + +## मल्टीसिग कॉन्ट्रॅक्ट्स {#multisig} + +मल्टीसिग (मल्टिपल-सिग्नेचर) कॉन्ट्रॅक्ट्स हे स्मार्ट कॉन्ट्रॅक्ट अकाउंट्स आहेत ज्यांना व्यवहार कार्यान्वित करण्यासाठी अनेक वैध स्वाक्षऱ्यांची आवश्यकता असते. इथर किंवा इतर टोकन्सची मोठी रक्कम असलेल्या कॉन्ट्रॅक्ट्ससाठी अयशस्वीतेचे एकल बिंदू टाळण्यासाठी हे खूप उपयुक्त आहे. मल्टीसिग्ज कॉन्ट्रॅक्टच्या अंमलबजावणीची आणि की व्यवस्थापनाची जबाबदारी अनेक पक्षांमध्ये विभागतात आणि एका खाजगी कीच्या नुकसानीमुळे निधीचे अपरिवर्तनीय नुकसान होण्यास प्रतिबंध करतात. या कारणास्तव, मल्टीसिग कॉन्ट्रॅक्ट्स साध्या DAO गव्हर्नन्ससाठी वापरले जाऊ शकतात. मल्टीसिगला कार्यान्वित करण्यासाठी M संभाव्य स्वीकार्य स्वाक्षऱ्यांपैकी N स्वाक्षऱ्यांची आवश्यकता असते (जेथे N ≤ M, आणि M > 1). `N = 3, M = 5` आणि `N = 4, M = 7` सामान्यतः वापरले जातात. एका 4/7 मल्टीसिगला सात संभाव्य वैध स्वाक्षऱ्यांपैकी चार स्वाक्षऱ्यांची आवश्यकता असते. याचा अर्थ तीन स्वाक्षऱ्या गमावल्या तरीही निधी परत मिळवता येतो. या प्रकरणात, याचा अर्थ असा आहे की कॉन्ट्रॅक्ट कार्यान्वित होण्यासाठी बहुसंख्य की-धारकांनी सहमत होऊन स्वाक्षरी करणे आवश्यक आहे. + +## स्मार्ट कॉन्ट्रॅक्ट संसाधने {#smart-contract-resources} + +**OpenZeppelin Contracts -** **_सुरक्षित स्मार्ट कॉन्ट्रॅक्ट डेव्हलपमेंटसाठी लायब्ररी._** + +- [openzeppelin.com/contracts/](https://openzeppelin.com/contracts/) +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) +- [कम्युनिटी फोरम](https://forum.openzeppelin.com/c/general/16) + +## पुढील वाचन {#further-reading} + +- [Coinbase: स्मार्ट कॉन्ट्रॅक्ट म्हणजे काय?](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract) +- [Chainlink: स्मार्ट कॉन्ट्रॅक्ट म्हणजे काय?](https://chain.link/education/smart-contracts) +- [व्हिडिओ: सोप्या भाषेत स्पष्टीकरण - स्मार्ट कॉन्ट्रॅक्ट्स](https://youtu.be/ZE2HxTmxfrI) +- [Cyfrin Updraft: Web3 लर्निंग आणि ऑडिटिंग प्लॅटफॉर्म](https://updraft.cyfrin.io) diff --git a/public/content/translations/mr/developers/docs/smart-contracts/languages/index.md b/public/content/translations/mr/developers/docs/smart-contracts/languages/index.md new file mode 100644 index 00000000000..0c6961635c8 --- /dev/null +++ b/public/content/translations/mr/developers/docs/smart-contracts/languages/index.md @@ -0,0 +1,325 @@ +--- +title: "स्मार्ट कॉन्ट्रॅक्ट भाषा" +description: "दोन मुख्य स्मार्ट कॉन्ट्रॅक्ट भाषा - Solidity आणि Vyper यांचा आढावा आणि तुलना." +lang: mr +--- + +Ethereum बद्दल एक उत्तम गोष्ट ही आहे की स्मार्ट कॉन्ट्रॅक्ट्स तुलनेने विकसक-अनुकूल भाषा वापरून प्रोग्राम केले जाऊ शकतात. तुम्ही Python किंवा कोणत्याही [कर्ली-ब्रॅकेट भाषेमध्ये](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages) अनुभवी असाल, तर तुम्हाला परिचित सिंटॅक्स असलेली भाषा सापडू शकते. + +दोन सर्वात सक्रिय आणि देखरेख केलेल्या भाषा आहेत: + +- Solidity +- Vyper + +Remix IDE हे Solidity आणि Vyper या दोन्हीमधील कॉन्ट्रॅक्ट्स तयार करण्यासाठी आणि तपासण्यासाठी एक सर्वसमावेशक विकास वातावरण प्रदान करते. कोडिंग सुरू करण्यासाठी [ब्राउझर-मधील Remix IDE वापरून पाहा](https://remix.ethereum.org). + +अधिक अनुभवी विकसक [Ethereum Virtual Machine](/developers/docs/evm/) साठी एक मध्यस्थ भाषा Yul, किंवा Yul+ जे Yul चे विस्तारीकरण आहे, वापरू शकतात. + +तुम्ही उत्सुक असाल आणि मोठ्या प्रमाणात विकासाधीन असलेल्या नवीन भाषा तपासण्यात मदत करू इच्छित असाल, तर तुम्ही Fe सह प्रयोग करू शकता, जी एक उदयोन्मुख स्मार्ट कॉन्ट्रॅक्ट भाषा आहे आणि सध्या तिच्या सुरुवातीच्या टप्प्यात आहे. + +## पूर्वतयारी {#prerequisites} + +प्रोग्रामिंग भाषांचे, विशेषतः JavaScript किंवा Python चे पूर्वीचे ज्ञान, तुम्हाला स्मार्ट कॉन्ट्रॅक्ट भाषांमधील फरक समजून घेण्यास मदत करू शकते. आम्ही शिफारस करतो की भाषांच्या तुलनेत खोलवर जाण्यापूर्वी तुम्ही स्मार्ट कॉन्ट्रॅक्ट्स एक संकल्पना म्हणून समजून घ्या. [स्मार्ट कॉन्ट्रॅक्ट्सची ओळख](/developers/docs/smart-contracts/). + +## Solidity {#solidity} + +- स्मार्ट कॉन्ट्रॅक्ट्स लागू करण्यासाठी ऑब्जेक्ट-ओरिएंटेड, उच्च-स्तरीय भाषा. +- कर्ली-ब्रॅकेट भाषा जी C++ द्वारे सर्वाधिक प्रभावित झाली आहे. +- स्टॅटिकली टाइप केलेली (व्हेरिएबलचा प्रकार कंपाइल वेळेस ज्ञात असतो). +- समर्थन करते: + - इनहेरिटन्स (तुम्ही इतर कॉन्ट्रॅक्ट्स विस्तारित करू शकता). + - लायब्ररीज (तुम्ही पुन्हा वापरण्यायोग्य कोड तयार करू शकता जो तुम्ही वेगवेगळ्या कॉन्ट्रॅक्ट्समधून कॉल करू शकता – जसे की इतर ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषांमधील स्टॅटिक क्लासमधील स्टॅटिक फंक्शन्स). + - जटिल वापरकर्ता-परिभाषित प्रकार. + +### महत्वाच्या लिंक्स {#important-links} + +- [दस्तऐवजीकरण](https://docs.soliditylang.org/en/latest/) +- [Solidity लँग्वेज पोर्टल](https://soliditylang.org/) +- [उदाहरणांसह Solidity](https://docs.soliditylang.org/en/latest/solidity-by-example.html) +- [GitHub](https://github.com/ethereum/solidity/) +- [Solidity Gitter चॅटरूम](https://gitter.im/ethereum/solidity) जे [Solidity Matrix चॅटरूम](https://matrix.to/#/#ethereum_solidity:gitter.im) शी जोडलेले आहे +- [चीट शीट](https://reference.auditless.com/cheatsheet) +- [Solidity ब्लॉग](https://blog.soliditylang.org/) +- [Solidity ट्विटर](https://twitter.com/solidity_lang) + +### उदाहरण कॉन्ट्रॅक्ट {#example-contract} + +```solidity +// SPDX-License-Identifier: GPL-3.0 +pragma solidity >= 0.7.0; + +contract Coin { + // The keyword "public" makes variables + // accessible from other contracts + address public minter; + mapping (address => uint) public balances; + + // Events allow clients to react to specific + // contract changes you declare + event Sent(address from, address to, uint amount); + + // Constructor code is only run when the contract + // is created + constructor() { + minter = msg.sender; + } + + // Sends an amount of newly created coins to an address + // Can only be called by the contract creator + function mint(address receiver, uint amount) public { + require(msg.sender == minter); + require(amount < 1e60); + balances[receiver] += amount; + } + + // Sends an amount of existing coins + // from any caller to an address + function send(address receiver, uint amount) public { + require(amount <= balances[msg.sender], "Insufficient balance."); + balances[msg.sender] -= amount; + balances[receiver] += amount; + emit Sent(msg.sender, receiver, amount); + } +} +``` + +हे उदाहरण तुम्हाला Solidity कॉन्ट्रॅक्ट सिंटॅक्स कसा असतो याची कल्पना देईल. फंक्शन्स आणि व्हेरिएबल्सच्या अधिक तपशीलवार वर्णनासाठी, [डॉक्युमेंट्स पहा](https://docs.soliditylang.org/en/latest/contracts.html). + +## Vyper {#vyper} + +- पायथॉनिक प्रोग्रामिंग भाषा +- स्ट्रॉंग टायपिंग +- लहान आणि समजण्याजोगा कंपाइलर कोड +- कार्यक्षम बाईटकोड निर्मिती +- Solidity पेक्षा मुद्दामहून कमी वैशिष्ट्ये आहेत, ज्याचा उद्देश कॉन्ट्रॅक्ट्स अधिक सुरक्षित आणि ऑडिट करण्यास सोपे बनवणे आहे. Vyper समर्थन करत नाही: + - मॉडिफायर्स + - इनहेरिटन्स + - इनलाइन असेंब्ली + - फंक्शन ओव्हरलोडिंग + - ऑपरेटर ओव्हरलोडिंग + - रिकर्सिव्ह कॉलिंग + - अनंत-लांबीचे लूप्स + - बायनरी फिक्स्ड पॉइंट्स + +अधिक माहितीसाठी, [Vyper रॅशनल वाचा](https://vyper.readthedocs.io/en/latest/index.html). + +### महत्वाच्या लिंक्स {#important-links-1} + +- [दस्तऐवजीकरण](https://vyper.readthedocs.io) +- [उदाहरणांसह Vyper](https://vyper.readthedocs.io/en/latest/vyper-by-example.html) +- [उदाहरणांसह अधिक Vyper](https://vyper-by-example.org/) +- [GitHub](https://github.com/vyperlang/vyper) +- [Vyper कम्युनिटी डिस्कॉर्ड चॅट](https://discord.gg/SdvKC79cJk) +- [चीट शीट](https://reference.auditless.com/cheatsheet) +- [Vyper साठी स्मार्ट कॉन्ट्रॅक्ट डेव्हलपमेंट फ्रेमवर्क आणि टूल्स](/developers/docs/programming-languages/python/) +- [VyperPunk - Vyper स्मार्ट कॉन्ट्रॅक्ट्स सुरक्षित करणे आणि हॅक करणे शिका](https://github.com/SupremacyTeam/VyperPunk) +- [विकासासाठी Vyper हब](https://github.com/zcor/vyper-dev) +- [Vyper ग्रेटेस्ट हिट्स स्मार्ट कॉन्ट्रॅक्ट उदाहरणे](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts) +- [अप्रतिम Vyper क्युरेटेड संसाधने](https://github.com/spadebuilders/awesome-vyper) + +### उदाहरण {#example} + +```python +# Open Auction + +# Auction params +# Beneficiary receives money from the highest bidder +beneficiary: public(address) +auctionStart: public(uint256) +auctionEnd: public(uint256) + +# Current state of auction +highestBidder: public(address) +highestBid: public(uint256) + +# Set to true at the end, disallows any change +ended: public(bool) + +# Keep track of refunded bids so we can follow the withdraw pattern +pendingReturns: public(HashMap[address, uint256]) + +# Create a simple auction with `_bidding_time` +# seconds bidding time on behalf of the +# beneficiary address `_beneficiary`. +@external +def __init__(_beneficiary: address, _bidding_time: uint256): + self.beneficiary = _beneficiary + self.auctionStart = block.timestamp + self.auctionEnd = self.auctionStart + _bidding_time + +# Bid on the auction with the value sent +# together with this transaction. +# The value will only be refunded if the +# auction is not won. +@external +@payable +def bid(): + # Check if bidding period is over. + assert block.timestamp < self.auctionEnd + # Check if bid is high enough + assert msg.value > self.highestBid + # Track the refund for the previous high bidder + self.pendingReturns[self.highestBidder] += self.highestBid + # Track new high bid + self.highestBidder = msg.sender + self.highestBid = msg.value + +# Withdraw a previously refunded bid. The withdraw pattern is +# used here to avoid a security issue. If refunds were directly +# sent as part of bid(), a malicious bidding contract could block +# those refunds and thus block new higher bids from coming in. +@external +def withdraw(): + pending_amount: uint256 = self.pendingReturns[msg.sender] + self.pendingReturns[msg.sender] = 0 + send(msg.sender, pending_amount) + +# End the auction and send the highest bid +# to the beneficiary. +@external +def endAuction(): + # It is a good guideline to structure functions that interact + # with other contracts (i.e., they call functions or send ether) + # into three phases: + # 1. checking conditions + # 2. performing actions (potentially changing conditions) + # 3. interacting with other contracts + # If these phases are mixed up, the other contract could call + # back into the current contract and modify the state or cause + # effects (ether payout) to be performed multiple times. + # If functions called internally include interaction with external + # contracts, they also have to be considered interaction with + # external contracts. + + # 1. Conditions + # Check if auction endtime has been reached + assert block.timestamp >= self.auctionEnd + # Check if this function has already been called + assert not self.ended + + # 2. Effects + self.ended = True + + # 3. Interaction + send(self.beneficiary, self.highestBid) +``` + +हे उदाहरण तुम्हाला Vyper कॉन्ट्रॅक्ट सिंटॅक्स कसा असतो याची कल्पना देईल. फंक्शन्स आणि व्हेरिएबल्सच्या अधिक तपशीलवार वर्णनासाठी, [डॉक्युमेंट्स पहा](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction). + +## Yul आणि Yul+ {#yul} + +तुम्ही Ethereum साठी नवीन असाल आणि अद्याप स्मार्ट कॉन्ट्रॅक्ट भाषांसह कोडिंग केले नसेल, तर आम्ही Solidity किंवा Vyper सह प्रारंभ करण्याची शिफारस करतो. स्मार्ट कॉन्ट्रॅक्ट सुरक्षा सर्वोत्तम पद्धती आणि EVM सह काम करण्याच्या तपशीलांशी तुम्ही परिचित झाल्यावरच Yul किंवा Yul+ चा विचार करा. + +**Yul** + +- Ethereum साठी मध्यस्थ भाषा. +- [EVM](/developers/docs/evm) आणि [Ewasm](https://github.com/ewasm), एक Ethereum फ्लेवर्ड वेबअसेंब्ली, ला समर्थन देते आणि दोन्ही प्लॅटफॉर्म्सचा वापरण्यायोग्य समान विभाजक म्हणून डिझाइन केले आहे. +- उच्च-स्तरीय ऑप्टिमायझेशन टप्प्यांसाठी चांगले लक्ष्य जे EVM आणि Ewasm दोन्ही प्लॅटफॉर्मला समान फायदा देऊ शकतात. + +**Yul+** + +- Yul चे एक निम्न-स्तरीय, अत्यंत कार्यक्षम विस्तारीकरण. +- सुरुवातीला [optimistic rollup](/developers/docs/scaling/optimistic-rollups/) कॉन्ट्रॅक्टसाठी डिझाइन केलेले. +- Yul+ ला Yul साठी एक प्रायोगिक अपग्रेड प्रस्ताव म्हणून पाहिले जाऊ शकते, जे त्यात नवीन वैशिष्ट्ये जोडते. + +### महत्वाच्या लिंक्स {#important-links-2} + +- [Yul दस्तऐवजीकरण](https://docs.soliditylang.org/en/latest/yul.html) +- [Yul+ दस्तऐवजीकरण](https://github.com/fuellabs/yulp) +- [Yul+ परिचय पोस्ट](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f) + +### उदाहरण कॉन्ट्रॅक्ट {#example-contract-2} + +पुढील सोपे उदाहरण पॉवर फंक्शन लागू करते. `solc --strict-assembly --bin input.yul` वापरून ते संकलित केले जाऊ शकते. उदाहरण +input.yul फाईलमध्ये संग्रहित केले पाहिजे. + +``` +{ + function power(base, exponent) -> result + { + switch exponent + case 0 { result := 1 } + case 1 { result := base } + default + { + result := power(mul(base, base), div(exponent, 2)) + if mod(exponent, 2) { result := mul(base, result) } + } + } + let res := power(calldataload(0), calldataload(32)) + mstore(0, res) + return(0, 32) +} +``` + +जर तुम्ही स्मार्ट कॉन्ट्रॅक्टमध्ये आधीच चांगले अनुभवी असाल, तर Yul मधील संपूर्ण ERC20 अंमलबजावणी [येथे](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example) आढळू शकते. + +## Fe {#fe} + +- Ethereum व्हर्च्युअल मशीन (EVM) साठी स्टॅटिकली टाइप केलेली भाषा. +- Python आणि Rust पासून प्रेरित. +- अगदी Ethereum इकोसिस्टममध्ये नवीन असलेल्या विकसकांसाठीही शिकण्यास सोपे बनविण्याचे उद्दिष्ट आहे. +- Fe चा विकास अजूनही सुरुवातीच्या टप्प्यात आहे, या भाषेची अल्फा आवृत्ती जानेवारी २०२१ मध्ये प्रसिद्ध झाली. + +### महत्वाच्या लिंक्स {#important-links-3} + +- [GitHub](https://github.com/ethereum/fe) +- [Fe घोषणा](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/) +- [Fe 2021 रोडमॅप](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg) +- [Fe डिस्कॉर्ड चॅट](https://discord.com/invite/ywpkAXFjZH) +- [Fe ट्विटर](https://twitter.com/official_fe) + +### उदाहरण कॉन्ट्रॅक्ट {#example-contract-3} + +खालील एक Fe मध्ये अंमलात आणलेले एक साधे कॉन्ट्रॅक्ट आहे. + +``` +type BookMsg = bytes[100] + +contract GuestBook: + pub guest_book: map + + event Signed: + book_msg: BookMsg + + pub def sign(book_msg: BookMsg): + self.guest_book[msg.sender] = book_msg + + emit Signed(book_msg=book_msg) + + pub def get_msg(addr: address) -> BookMsg: + return self.guest_book[addr].to_mem() + +``` + +## कसे निवडावे {#how-to-choose} + +इतर कोणत्याही प्रोग्रामिंग भाषेप्रमाणे, हे बहुतेक योग्य कामासाठी योग्य साधन निवडण्याबद्दल तसेच वैयक्तिक पसंतींबद्दल आहे. + +तुम्ही अजून कोणतीही भाषा वापरून पाहिली नसेल, तर विचारात घेण्यासाठी येथे काही गोष्टी आहेत: + +### Solidity बद्दल काय छान आहे? {#solidity-advantages} + +- तुम्ही नवशिके असाल, तर तेथे अनेक ट्युटोरियल्स आणि शिकण्याची साधने उपलब्ध आहेत. त्याबद्दल अधिक माहिती [कोडिंगद्वारे शिका](/developers/learning-tools/) विभागात पहा. +- चांगली विकसक टूलींग उपलब्ध आहे. +- Solidity चा एक मोठा विकसक समुदाय आहे, याचा अर्थ तुम्हाला तुमच्या प्रश्नांची उत्तरे बहुधा पटकन मिळतील. + +### Vyper बद्दल काय छान आहे? {#vyper-advatages} + +- Python डेव्हलपर्ससाठी ज्यांना स्मार्ट कॉन्ट्रॅक्ट लिहायचे आहेत त्यांच्यासाठी सुरुवात करण्याचा उत्तम मार्ग. +- Vyper मध्ये कमी वैशिष्ट्ये आहेत ज्यामुळे ते कल्पनांच्या जलद प्रोटोटाइपिंगसाठी उत्तम आहे. +- Vyper चे उद्दिष्ट ऑडिट करण्यास सोपे आणि जास्तीत जास्त मानवी-वाचनीय असणे हे आहे. + +### Yul आणि Yul+ बद्दल काय छान आहे? {#yul-advantages} + +- सरळ आणि कार्यात्मक निम्न-स्तरीय भाषा. +- रॉ EVM च्या खूप जवळ जाण्याची परवानगी देते, जे तुमच्या कॉन्ट्रॅक्ट्सचा गॅस वापर ऑप्टिमाइझ करण्यात मदत करू शकते. + +## भाषांची तुलना {#language-comparisons} + +मूलभूत सिंटॅक्स, कॉन्ट्रॅक्ट लाइफसायकल, इंटरफेस, ऑपरेटर, डेटा स्ट्रक्चर्स, फंक्शन्स, कंट्रोल फ्लो, आणि बरेच काही यांच्या तुलनेसाठी Auditless द्वारे हे [चीटशीट](https://reference.auditless.com/cheatsheet/) पहा + +## पुढील वाचन {#further-reading} + +- [OpenZeppelin द्वारे Solidity कॉन्ट्रॅक्ट्स लायब्ररी](https://docs.openzeppelin.com/contracts/5.x/) +- [उदाहरणांसह Solidity](https://solidity-by-example.org) diff --git a/public/content/translations/mr/developers/docs/smart-contracts/libraries/index.md b/public/content/translations/mr/developers/docs/smart-contracts/libraries/index.md new file mode 100644 index 00000000000..6652b8e8d1e --- /dev/null +++ b/public/content/translations/mr/developers/docs/smart-contracts/libraries/index.md @@ -0,0 +1,117 @@ +--- +title: "स्मार्ट कॉन्ट्रॅक्ट लायब्रऱ्या" +description: "तुमच्या इथेरियम डेव्हलपमेंट प्रोजेक्ट्सना गती देण्यासाठी पुन्हा वापरता येण्याजोग्या स्मार्ट कॉन्ट्रॅक्ट लायब्रऱ्या आणि बिल्डिंग ब्लॉक्स शोधा." +lang: mr +--- + +तुम्हाला तुमच्या प्रोजेक्टमधील प्रत्येक स्मार्ट कॉन्ट्रॅक्ट अगदी सुरुवातीपासून लिहिण्याची गरज नाही. अनेक ओपन-सोर्स स्मार्ट कॉन्ट्रॅक्ट लायब्रऱ्या उपलब्ध आहेत, ज्या तुमच्या प्रोजेक्टसाठी पुन्हा वापरता येण्याजोगे बिल्डिंग ब्लॉक्स पुरवतात. यामुळे तुम्हाला पुन्हा नव्याने सुरुवात करावी लागणार नाही. + +## पूर्वतयारी {#prerequisites} + +स्मार्ट कॉन्ट्रॅक्ट लायब्रऱ्यांमध्ये थेट प्रवेश करण्यापूर्वी, स्मार्ट कॉन्ट्रॅक्टच्या रचनेची चांगली समज असणे महत्त्वाचे आहे. जर तुम्ही अद्याप तसे केले नसेल, तर [स्मार्ट कॉन्ट्रॅक्ट ॲनाटॉमी](/developers/docs/smart-contracts/anatomy/) वर जा. + +## लायब्ररीमध्ये काय असते {#whats-in-a-library} + +स्मार्ट कॉन्ट्रॅक्ट लायब्रऱ्यांमध्ये तुम्हाला सहसा दोन प्रकारचे बिल्डिंग ब्लॉक्स आढळतील: पुन्हा वापरता येणारे बिहेवियर्स जे तुम्ही तुमच्या कॉन्ट्रॅक्टमध्ये जोडू शकता आणि विविध मानकांची अंमलबजावणी. + +### बिहेवियर्स {#behaviors} + +स्मार्ट कॉन्ट्रॅक्ट लिहिताना, तुम्हाला वारंवार सारखेच पॅटर्न लिहावे लागण्याची शक्यता आहे, जसे की कॉन्ट्रॅक्टमध्ये संरक्षित ऑपरेशन्स करण्यासाठी _ॲडमिन_ ॲड्रेस नियुक्त करणे, किंवा अनपेक्षित समस्या उद्भवल्यास आपत्कालीन _पॉझ_ बटण जोडणे. + +स्मार्ट कॉन्ट्रॅक्ट लायब्रऱ्या सहसा सॉलिडिटीमध्ये [लायब्रऱ्या](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) म्हणून किंवा [इनहेरिटन्स](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance) द्वारे या बिहेवियर्सची पुन्हा वापरण्यायोग्य अंमलबजावणी प्रदान करतात. + +उदाहरणार्थ, [OpenZeppelin Contracts लायब्ररी](https://github.com/OpenZeppelin/openzeppelin-contracts) मधील [`Ownable` कॉन्ट्रॅक्टची](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) एक सरलीकृत आवृत्ती खालीलप्रमाणे आहे, जी एका ॲड्रेसला कॉन्ट्रॅक्टचा मालक म्हणून नियुक्त करते आणि केवळ त्या मालकापुरता एका मेथडचा ॲक्सेस मर्यादित करण्यासाठी मॉडिफायर प्रदान करते. + +```solidity +contract Ownable { + address public owner; + + constructor() internal { + owner = msg.sender; + } + + modifier onlyOwner() { + require(owner == msg.sender, "Ownable: caller is not the owner"); + _; + } +} +``` + +तुमच्या कॉन्ट्रॅक्टमध्ये असा बिल्डिंग ब्लॉक वापरण्यासाठी, तुम्हाला प्रथम तो इम्पोर्ट करावा लागेल, आणि नंतर तुमच्या स्वतःच्या कॉन्ट्रॅक्टमध्ये त्यातून एक्सटेंड करावे लागेल. हे तुम्हाला तुमची स्वतःची फंक्शन्स सुरक्षित करण्यासाठी बेस `Ownable` कॉन्ट्रॅक्टद्वारे प्रदान केलेला मॉडिफायर वापरण्याची परवानगी देईल. + +```solidity +import ".../Ownable.sol"; // Path to the imported library + +contract MyContract is Ownable { + // The following function can only be called by the owner + function secured() onlyOwner public { + msg.sender.transfer(1 ether); + } +} +``` + +आणखी एक लोकप्रिय उदाहरण म्हणजे [SafeMath](https://docs.openzeppelin.com/contracts/3.x/utilities#math) किंवा [DsMath](https://dappsys.readthedocs.io/en/latest/ds_math.html). या लायब्रऱ्या आहेत (बेस कॉन्ट्रॅक्ट्सच्या विरुद्ध) ज्या ओव्हरफ्लो तपासणीसह अंकगणितीय फंक्शन्स प्रदान करतात, जे भाषेद्वारे प्रदान केलेले नाहीत. तुमच्या कॉन्ट्रॅक्टला ओव्हरफ्लोपासून वाचवण्यासाठी नेटिव्ह अंकगणितीय ऑपरेशन्सऐवजी यापैकी कोणतीही एक लायब्ररी वापरणे ही एक चांगली सराव आहे, कारण ओव्हरफ्लोचे विनाशकारी परिणाम होऊ शकतात! + +### मानके {#standards} + +[कंपोझेबिलिटी आणि इंटरऑपरेबिलिटी](/developers/docs/smart-contracts/composability/) सुलभ करण्यासाठी, इथेरियम समुदायाने **ERCs** च्या स्वरूपात अनेक मानके परिभाषित केली आहेत. तुम्ही त्यांच्याबद्दल [मानके](/developers/docs/standards/) विभागात अधिक वाचू शकता. + +तुमच्या कॉन्ट्रॅक्टचा भाग म्हणून ERC समाविष्ट करताना, स्वतःची अंमलबजावणी करण्याचा प्रयत्न करण्याऐवजी मानक अंमलबजावणी शोधणे ही एक चांगली कल्पना आहे. अनेक स्मार्ट कॉन्ट्रॅक्ट लायब्रऱ्यांमध्ये सर्वात लोकप्रिय ERCs साठी अंमलबजावणी समाविष्ट असते. उदाहरणार्थ, सर्वव्यापी [ERC20 फंजिबल टोकन स्टँडर्ड](/developers/tutorials/understand-the-erc-20-token-smart-contract/) [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md), [DappSys](https://github.com/dapphub/ds-token/) आणि [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20) मध्ये आढळू शकते. याव्यतिरिक्त, काही ERCs स्वतः ERCचा भाग म्हणून प्रमाणित अंमलबजावणी प्रदान करतात. + +हे लक्षात घेण्यासारखे आहे की काही ERCs स्वतंत्र नसतात, तर त्या इतर ERCs मध्ये भर घालणाऱ्या असतात. उदाहरणार्थ, [ERC2612](https://eips.ethereum.org/EIPS/eip-2612) हे ERC20 ची उपयोगिता सुधारण्यासाठी त्यात एक विस्तार जोडते. + +## लायब्ररी कशी जोडावी {#how-to} + +तुमच्या प्रोजेक्टमध्ये लायब्ररी कशी समाविष्ट करावी याच्या विशिष्ट सूचनांसाठी तुम्ही समाविष्ट करत असलेल्या लायब्ररीच्या डॉक्युमेंटेशनचा नेहमी संदर्भ घ्या. अनेक सॉलिडिटी कॉन्ट्रॅक्ट लायब्रऱ्या `npm` वापरून पॅकेज केल्या जातात, त्यामुळे तुम्ही त्यांना फक्त `npm install` करू शकता. कॉन्ट्रॅक्ट [संकलित](/developers/docs/smart-contracts/compiling/) करण्यासाठीची बहुतेक साधने तुमच्या `node_modules` मध्ये स्मार्ट कॉन्ट्रॅक्ट लायब्रऱ्या शोधतील, त्यामुळे तुम्ही खालीलप्रमाणे करू शकता: + +```solidity +// This will load the @openzeppelin/contracts library from your node_modules +import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; + +contract MyNFT is ERC721 { + constructor() ERC721("MyNFT", "MNFT") public { } +} +``` + +तुम्ही कोणतीही पद्धत वापरत असलात तरी, लायब्ररी समाविष्ट करताना, नेहमी [भाषा](/developers/docs/smart-contracts/languages/) आवृत्तीवर लक्ष ठेवा. उदाहरणार्थ, जर तुम्ही तुमचे कॉन्ट्रॅक्ट्स सॉलिडिटी 0.5 मध्ये लिहित असाल, तर तुम्ही सॉलिडिटी 0.6 साठीची लायब्ररी वापरू शकत नाही. + +## कधी वापरावे {#when-to-use} + +तुमच्या प्रोजेक्टसाठी स्मार्ट कॉन्ट्रॅक्ट लायब्ररी वापरण्याचे अनेक फायदे आहेत. सर्वात महत्त्वाचे म्हणजे, ते तुम्हाला स्वतः कोड करण्याऐवजी तुमच्या सिस्टममध्ये समाविष्ट करता येणारे तयार बिल्डिंग ब्लॉक्स पुरवून तुमचा वेळ वाचवते. + +सुरक्षितता हा देखील एक मोठा फायदा आहे. ओपन-सोर्स स्मार्ट कॉन्ट्रॅक्ट लायब्रऱ्यांची देखील अनेकदा कसून तपासणी केली जाते. अनेक प्रोजेक्ट्स त्यांच्यावर अवलंबून असल्यामुळे, समुदायाकडून त्यांना सतत पुनरावलोकनाखाली ठेवण्यास जोरदार प्रोत्साहन मिळते. पुन्हा वापरता येण्याजोग्या कॉन्ट्रॅक्ट लायब्रऱ्यांपेक्षा ॲप्लिकेशन कोडमध्ये त्रुटी आढळणे अधिक सामान्य आहे. अतिरिक्त सुरक्षिततेसाठी काही लायब्रऱ्यांचे [बाह्य ऑडिट](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits) देखील केले जाते. + +तथापि, स्मार्ट कॉन्ट्रॅक्ट लायब्रऱ्या वापरण्यामध्ये तुमच्या प्रोजेक्टमध्ये असा कोड समाविष्ट करण्याचा धोका असतो ज्याच्याशी तुम्ही परिचित नाही. एखादे कॉन्ट्रॅक्ट इम्पोर्ट करून ते थेट तुमच्या प्रोजेक्टमध्ये समाविष्ट करणे मोहक वाटते, परंतु ते कॉन्ट्रॅक्ट काय करते याची चांगली समज नसल्यास, तुम्ही अनपेक्षित वर्तनामुळे नकळतपणे तुमच्या सिस्टममध्ये समस्या निर्माण करू शकता. तुम्ही जो कोड इम्पोर्ट करत आहात त्याचे डॉक्युमेंटेशन नेहमी वाचा आणि तुमच्या प्रोजेक्टचा भाग बनवण्यापूर्वी कोडचे स्वतः पुनरावलोकन करा! + +शेवटी, लायब्ररी समाविष्ट करायची की नाही हे ठरवताना, तिच्या एकूण वापराचा विचार करा. व्यापकपणे स्वीकारलेल्या लायब्ररीला मोठा समुदाय असण्याचा आणि समस्या शोधण्यासाठी अधिक लोक त्यावर लक्ष ठेवून असण्याचा फायदा मिळतो. स्मार्ट कॉन्ट्रॅक्ट्ससह तयार करताना सुरक्षितता हे तुमचे प्राथमिक लक्ष असले पाहिजे! + +## संबंधित साधने {#related-tools} + +**OpenZeppelin Contracts -** **_सुरक्षित स्मार्ट कॉन्ट्रॅक्ट डेव्हलपमेंटसाठी सर्वात लोकप्रिय लायब्ररी._** + +- [डॉक्युमेंटेशन](https://docs.openzeppelin.com/contracts/) +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) +- [कम्युनिटी फोरम](https://forum.openzeppelin.com/c/general/16) + +**DappSys -** **_स्मार्ट-कॉन्ट्रॅक्टसाठी सुरक्षित, सोपे, लवचिक बिल्डिंग-ब्लॉक्स._** + +- [डॉक्युमेंटेशन](https://dappsys.readthedocs.io/) +- [GitHub](https://github.com/dapphub/dappsys) + +**HQ20 -** **_कॉन्ट्रॅक्ट्स, लायब्रऱ्या आणि उदाहरणांसह एक सॉलिडिटी प्रोजेक्ट जो तुम्हाला वास्तविक जगासाठी पूर्ण-वैशिष्ट्यपूर्ण वितरित ॲप्लिकेशन्स तयार करण्यात मदत करतो._** + +- [GitHub](https://github.com/HQ20/contracts) + +**thirdweb Solidity SDK -** **_सानुकूल स्मार्ट कॉन्ट्रॅक्ट्स कार्यक्षमतेने तयार करण्यासाठी आवश्यक साधने पुरवते_** + +- [डॉक्युमेंटेशन](https://portal.thirdweb.com/contracts/build/overview) +- [GitHub](https://github.com/thirdweb-dev/contracts) + +## संबंधित ट्युटोरियल्स {#related-tutorials} + +- [इथेरियम डेव्हलपर्ससाठी सुरक्षा विचार](/developers/docs/smart-contracts/security/) _- स्मार्ट कॉन्ट्रॅक्ट्स तयार करताना सुरक्षा विचारांवर एक ट्यूटोरियल, ज्यामध्ये लायब्ररी वापराचा समावेश आहे._ +- [ERC-20 टोकन स्मार्ट कॉन्ट्रॅक्ट समजून घ्या](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _- ERC20 मानकावरील ट्यूटोरियल, जे अनेक लायब्रऱ्यांद्वारे प्रदान केले जाते._ + +## पुढील वाचन {#further-reading} + +_तुम्हाला मदत केलेल्या सामुदायिक संसाधनाबद्दल माहिती आहे का?_ हे पृष्ठ संपादित करा आणि ते जोडा!_ diff --git a/public/content/translations/mr/developers/docs/smart-contracts/naming/index.md b/public/content/translations/mr/developers/docs/smart-contracts/naming/index.md new file mode 100644 index 00000000000..989c2dceabc --- /dev/null +++ b/public/content/translations/mr/developers/docs/smart-contracts/naming/index.md @@ -0,0 +1,101 @@ +--- +title: "स्मार्ट कॉन्ट्रॅक्ट्सचे नावकरण" +description: "ENS सह Ethereum स्मार्ट कॉन्ट्रॅक्ट्सना नाव देण्यासाठी सर्वोत्तम पद्धती" +lang: mr +--- + +स्मार्ट कॉन्ट्रॅक्ट्स हे Ethereum च्या विकेंद्रीकृत पायाभूत सुविधांचा आधारस्तंभ आहेत, जे स्वायत्त ॲप्लिकेशन्स आणि प्रोटोकॉल्सना सक्षम करतात. परंतु कॉन्ट्रॅक्टची क्षमता विकसित होत असतानाही, वापरकर्ते आणि डेव्हलपर अजूनही या कॉन्ट्रॅक्ट्सना ओळखण्यासाठी आणि संदर्भ देण्यासाठी मूळ हेक्साडेसिमल पत्त्यांवर अवलंबून आहेत. + +[Ethereum Name Service (ENS)](https://ens.domains/) सह स्मार्ट कॉन्ट्रॅक्ट्सचे नावकरण केल्याने हेक्साडेसिमल कॉन्ट्रॅक्ट पत्ते काढून वापरकर्त्याचा अनुभव सुधारतो आणि पत्ता विषबाधा आणि स्पूफिंग हल्ल्यांसारख्या हल्ल्यांपासून धोका कमी होतो. ही मार्गदर्शिका स्पष्ट करते की स्मार्ट कॉन्ट्रॅक्ट्सना नाव देणे का महत्त्वाचे आहे, ते कसे लागू केले जाऊ शकते आणि प्रक्रिया सुलभ करण्यासाठी आणि डेव्हलपर्सना ही पद्धत अवलंबण्यास मदत करण्यासाठी [Enscribe](https://www.enscribe.xyz) सारखी साधने उपलब्ध आहेत. + +## स्मार्ट कॉन्ट्रॅक्ट्सना नाव का द्यावे? {#why-name-contracts} + +### मानव-वाचनीय अभिज्ञापक {#human-readable-identifiers} + +`0x8f8e...f9e3` सारख्या अपारदर्शक कॉन्ट्रॅक्ट पत्त्यांशी संवाद साधण्याऐवजी, डेव्हलपर आणि वापरकर्ते `v2.myapp.eth` सारखी मानव-वाचनीय नावे वापरू शकतात. हे स्मार्ट कॉन्ट्रॅक्ट परस्परसंवाद सोपे करते. + +हे [Ethereum Name Service](https://ens.domains/) द्वारे शक्य झाले आहे जे Ethereum पत्त्यांसाठी विकेंद्रीकृत नामकरण सेवा प्रदान करते. हे डोमेन नेम सर्व्हिस (DNS) प्रमाणेच आहे, जे इंटरनेट वापरकर्त्यांना `104.18.176.152` सारख्या IP पत्त्याऐवजी ethereum.org सारख्या नावाने नेटवर्क पत्त्यांवर प्रवेश करण्यास सक्षम करते. + +### सुधारित सुरक्षा आणि विश्वास {#improved-security-and-trust} + +नामित कॉन्ट्रॅक्ट्स चुकीच्या पत्त्यावर अपघाती व्यवहार कमी करण्यास मदत करतात. ते वापरकर्त्यांना विशिष्ट ॲप्स किंवा ब्रँड्सशी जोडलेले कॉन्ट्रॅक्ट्स ओळखण्यात देखील मदत करतात. हे प्रतिष्ठेच्या विश्वासाचा एक स्तर जोडते, विशेषतः जेव्हा `uniswap.eth` सारख्या सुप्रसिद्ध पॅरेंट डोमेनशी नावे जोडलेली असतात. + +Ethereum पत्त्याच्या ४२-वर्णांच्या लांबीमुळे, वापरकर्त्यांना पत्त्यांमधील लहान बदल ओळखणे खूप कठीण आहे, जिथे काही वर्ण बदलले आहेत. उदाहरणार्थ, `0x58068646C148E313CB414E85d2Fe89dDc3426870` सारखा पत्ता सामान्यतः वॉलेट्स सारख्या वापरकर्ता-मुखी ॲप्लिकेशन्सद्वारे `0x580...870` पर्यंत कापला जाईल. वापरकर्त्याच्या लक्षात दुर्भावनापूर्ण पत्ता येण्याची शक्यता कमी असते, जिथे काही वर्ण बदललेले असतात. + +या प्रकारची पद्धत ॲड्रेस स्पूफिंग आणि पॉयझनिंग हल्ल्यांमध्ये वापरली जाते, जिथे वापरकर्त्यांना असा विश्वास दिला जातो की ते योग्य पत्त्यावर संवाद साधत आहेत किंवा निधी पाठवत आहेत, पण प्रत्यक्षात तो पत्ता फक्त योग्य पत्त्यासारखा दिसतो, पण तोच नसतो. + +वॉलेट्स आणि कॉन्ट्रॅक्ट्ससाठी ENS नावे या प्रकारच्या हल्ल्यांपासून संरक्षण करतात. DNS स्पूफिंग हल्ल्यांप्रमाणेच, ENS स्पूफिंग हल्ले देखील केले जाऊ शकतात, तथापि, वापरकर्त्याला हेक्साडेसिमल पत्त्यातील लहान बदलापेक्षा ENS नावातील चुकीचे स्पेलिंग लक्षात येण्याची अधिक शक्यता असते. + +### वॉलेट्स आणि एक्सप्लोरर्ससाठी उत्तम UX {#better-ux} + +जेव्हा एखादा स्मार्ट कॉन्ट्रॅक्ट ENS नावासह कॉन्फिगर केला जातो, तेव्हा वॉलेट्स आणि ब्लॉकचेन एक्सप्लोरर्स सारख्या ॲप्ससाठी हेक्साडेसिमल पत्त्यांऐवजी स्मार्ट कॉन्ट्रॅक्ट्ससाठी ENS नावे प्रदर्शित करणे शक्य होते. हे वापरकर्त्यांसाठी एक महत्त्वपूर्ण वापरकर्ता अनुभव (UX) सुधारणा प्रदान करते. + +उदाहरणार्थ, Uniswap सारख्या ॲपशी संवाद साधताना, वापरकर्त्यांना सामान्यतः दिसेल की ते ज्या ॲपशी संवाद साधत आहेत ते `uniswap.org` वेबसाइटवर होस्ट केलेले आहे, परंतु जर Uniswap ने त्यांच्या स्मार्ट कॉन्ट्रॅक्ट्सना ENS सह नाव दिले नसेल तर त्यांना एक हेक्साडेसिमल कॉन्ट्रॅक्ट पत्ता सादर केला जाईल. जर कॉन्ट्रॅक्टला नाव दिले असेल, तर त्याऐवजी ते `v4.contracts.uniswap.eth` पाहू शकतील जे अधिक उपयुक्त आहे. + +## डिप्लॉयमेंटवेळी नाव देणे विरुद्ध डिप्लॉयमेंटनंतर {#when-to-name} + +दोन टप्प्यांवर स्मार्ट कॉन्ट्रॅक्ट्सना नाव दिले जाऊ शकते: + +- **डिप्लॉयमेंटवेळी**: कॉन्ट्रॅक्ट डिप्लॉय होत असताना त्याला ENS नाव देणे. +- **डिप्लॉयमेंटनंतर**: विद्यमान कॉन्ट्रॅक्ट पत्त्याला नवीन ENS नावासह मॅप करणे. + +दोन्ही पद्धती ENS डोमेनच्या मालक किंवा व्यवस्थापक प्रवेशावर अवलंबून आहेत, जेणेकरून ते ENS रेकॉर्ड्स तयार आणि सेट करू शकतील. + +## कॉन्ट्रॅक्ट्ससाठी ENS नामकरण कसे कार्य करते {#how-ens-naming-works} + +ENS नावे ऑनचेन संग्रहित केली जातात आणि ENS रिझॉल्व्हर्सद्वारे Ethereum पत्त्यांवर रिझॉल्व्ह केली जातात. एका स्मार्ट कॉन्ट्रॅक्टला नाव देण्यासाठी: + +1. पॅरेंट ENS डोमेनची नोंदणी करा किंवा नियंत्रित करा (उदा. `myapp.eth`) +2. एक सबडोमेन तयार करा (उदा. `v1.myapp.eth`) +3. सबडोमेनचा `address` रेकॉर्ड कॉन्ट्रॅक्ट पत्त्यावर सेट करा +4. कॉन्ट्रॅक्टच्या रिव्हर्स रेकॉर्डला ENS वर सेट करा जेणेकरून नाव त्याच्या पत्त्याद्वारे शोधता येईल + +ENS नावे श्रेणीबद्ध आहेत आणि अमर्यादित उप-नावांना समर्थन देतात. हे रेकॉर्ड्स सेट करण्यासाठी सामान्यतः ENS नोंदणी आणि सार्वजनिक रिझॉल्व्हर कॉन्ट्रॅक्ट्सशी संवाद साधावा लागतो. + +## कॉन्ट्रॅक्ट्सना नाव देण्यासाठी साधने {#tools} + +स्मार्ट कॉन्ट्रॅक्ट्सना नाव देण्याचे दोन दृष्टिकोन आहेत. एकतर काही मॅन्युअल पायऱ्यांसह [ENS App](https://app.ens.domains) वापरणे किंवा [Enscribe](https://www.enscribe.xyz) वापरणे. हे खालीलप्रमाणे आहेत. + +### मॅन्युअल ENS सेटअप {#manual-ens-setup} + +[ENS App](https://app.ens.domains/) वापरून, डेव्हलपर मॅन्युअली उप-नावे तयार करू शकतात आणि फॉरवर्ड ॲड्रेस रेकॉर्ड्स सेट करू शकतात. तथापि, ते ENS ॲपद्वारे नावासाठी रिव्हर्स रेकॉर्ड सेट करून स्मार्ट कॉन्ट्रॅक्टसाठी प्राथमिक नाव सेट करू शकत नाहीत. मॅन्युअल पावले उचलली पाहिजेत जी [ENS docs](https://docs.ens.domains/web/naming-contracts/) मध्ये समाविष्ट आहेत. + +### Enscribe {#enscribe} + +[Enscribe](https://www.enscribe.xyz) ENS सह स्मार्ट कॉन्ट्रॅक्ट नामकरण सुलभ करते आणि स्मार्ट कॉन्ट्रॅक्ट्सवरील वापरकर्त्याचा विश्वास वाढवते. ते प्रदान करते: + +- **ॲटॉमिक डिप्लॉयमेंट आणि नामकरण**: नवीन कॉन्ट्रॅक्ट डिप्लॉय करताना ENS नाव नियुक्त करणे +- **डिप्लॉयमेंटनंतर नामकरण**: आधीच डिप्लॉय केलेल्या कॉन्ट्रॅक्ट्सना नावे जोडणे +- **मल्टी-चेन समर्थन**: Ethereum आणि L2 नेटवर्क्सवर कार्य करते जिथे ENS समर्थित आहे +- **कॉन्ट्रॅक्ट व्हेरिफिकेशन डेटा**: वापरकर्त्यांसाठी विश्वास वाढवण्यासाठी एकाधिक स्त्रोतांकडून काढलेला कॉन्ट्रॅक्ट व्हेरिफिकेशन डेटा समाविष्ट आहे + +Enscribe वापरकर्त्यांद्वारे प्रदान केलेली ENS नावे किंवा वापरकर्त्याकडे ENS नाव नसल्यास स्वतःचे डोमेन समर्थित करते. + +स्मार्ट कॉन्ट्रॅक्ट्सना नाव देणे आणि पाहणे सुरू करण्यासाठी आपण [Enscribe App](https://app.enscribe.xyz) ॲक्सेस करू शकता. + +## सर्वोत्तम पद्धती {#best-practices} + +- **स्पष्ट, आवृत्तीकृत नावे वापरा** जसे की `v1.myapp.eth` जेणेकरून कॉन्ट्रॅक्ट अपग्रेड्स पारदर्शक होतील +- **रिव्हर्स रेकॉर्ड्स सेट करा** जेणेकरून वॉलेट्स आणि ब्लॉकचेन एक्सप्लोरर्स सारख्या ॲप्समध्ये दृश्यमानतेसाठी कॉन्ट्रॅक्ट्स ENS नावांना जोडले जातील. +- **मालकीमधील अपघाती बदल टाळायचे असल्यास कालबाह्यतेवर बारकाईने लक्ष ठेवा** +- **कॉन्ट्रॅक्ट स्त्रोत सत्यापित करा** जेणेकरून वापरकर्ते विश्वास ठेवू शकतील की नामित कॉन्ट्रॅक्ट अपेक्षेप्रमाणे वागतो + +## धोके {#risks} + +स्मार्ट कॉन्ट्रॅक्ट्सना नाव देणे Ethereum च्या वापरकर्त्यांसाठी महत्त्वपूर्ण फायदे प्रदान करते, तथापि, ENS डोमेनच्या मालकांनी त्यांच्या व्यवस्थापनाबाबत सतर्क असले पाहिजे. उल्लेखनीय धोक्यांमध्ये हे समाविष्ट आहे: + +- **कालबाह्यता**: DNS नावांप्रमाणे, ENS नावांची नोंदणी मर्यादित कालावधीची असते. म्हणूनच हे महत्त्वाचे आहे की मालकांनी त्यांच्या डोमेनच्या कालबाह्यतेच्या तारखांवर लक्ष ठेवावे आणि कालबाह्य होण्यापूर्वीच त्यांचे नूतनीकरण करावे. ENS ॲप आणि Enscribe दोन्ही डोमेन मालकांसाठी कालबाह्यता जवळ आल्यावर व्हिज्युअल इंडिकेटर प्रदान करतात. +- **मालकीमध्ये बदल**: ENS रेकॉर्ड Ethereum वर NFTs म्हणून दर्शविले जातात, जिथे विशिष्ट `.eth` डोमेनच्या मालकाकडे संबंधित NFT त्यांच्या ताब्यात असते. म्हणूनच जर वेगळ्या खात्याने या NFT ची मालकी घेतली, तर नवीन मालक त्यांच्या इच्छेनुसार कोणतेही ENS रेकॉर्ड सुधारू शकतो. + +अशा धोक्यांपासून बचाव करण्यासाठी, `.eth` द्वितीय-स्तरीय डोमेन्स (2LD) साठी मालक खाते मल्टी-सिग वॉलेटद्वारे सुरक्षित केले पाहिजे, आणि कॉन्ट्रॅक्ट नामकरण व्यवस्थापित करण्यासाठी सबडोमेन्स तयार केले पाहिजेत. त्यामुळे सबडोमेन स्तरावर मालकीमध्ये कोणतेही अपघाती किंवा दुर्भावनापूर्ण बदल झाल्यास, ते 2LD मालकाद्वारे ओव्हरराइड केले जाऊ शकतात. + +## कॉन्ट्रॅक्ट नामकरणाचे भविष्य {#future} + +कॉन्ट्रॅक्ट नामकरण हे dApp विकासासाठी एक सर्वोत्तम सराव बनत आहे, जसे वेबवर डोमेन नावांनी IP पत्त्यांची जागा घेतली. वॉलेट्स, एक्सप्लोरर्स आणि डॅशबोर्ड्स सारख्या अधिक पायाभूत सुविधा कॉन्ट्रॅक्ट्ससाठी ENS रिझोल्यूशन समाकलित करत असल्याने, नामित कॉन्ट्रॅक्ट्स सुरक्षितता सुधारतील आणि संपूर्ण इकोसिस्टममध्ये चुका कमी करतील. + +स्मार्ट कॉन्ट्रॅक्ट्स ओळखण्यास आणि समजण्यास सोपे करून, नामकरण Ethereum वरील वापरकर्ते आणि ॲप्समधील अंतर कमी करण्यास मदत करते, ज्यामुळे वापरकर्त्यांसाठी सुरक्षा आणि UX दोन्ही सुधारतात. + +## पुढील वाचन {#further-reading} + +- [ENS सह स्मार्ट कॉन्ट्रॅक्ट्सचे नामकरण](https://docs.ens.domains/web/naming-contracts/) +- [Enscribe सह स्मार्ट कॉन्ट्रॅक्ट्सचे नामकरण](https://www.enscribe.xyz/docs). diff --git a/public/content/translations/mr/developers/docs/smart-contracts/security/index.md b/public/content/translations/mr/developers/docs/smart-contracts/security/index.md new file mode 100644 index 00000000000..f6d665e45a7 --- /dev/null +++ b/public/content/translations/mr/developers/docs/smart-contracts/security/index.md @@ -0,0 +1,576 @@ +--- +title: "स्मार्ट कॉन्ट्रॅक्ट सुरक्षा" +description: "सुरक्षित Ethereum स्मार्ट कॉन्ट्रॅक्ट्स तयार करण्यासाठीच्या मार्गदर्शक तत्त्वांचे अवलोकन" +lang: mr +--- + +स्मार्ट कॉन्ट्रॅक्ट्स अत्यंत लवचिक आहेत आणि ब्लॉकचेनवर तैनात केलेल्या कोडवर आधारित अपरिवर्तनीय तर्क चालवताना मोठ्या प्रमाणात मूल्य आणि डेटा नियंत्रित करण्यास सक्षम आहेत. यामुळे विश्वासहीन आणि विकेंद्रित ॲप्लिकेशन्सची एक उत्साही इकोसिस्टम तयार झाली आहे जी जुन्या सिस्टीमपेक्षा अनेक फायदे प्रदान करते. ते स्मार्ट कॉन्ट्रॅक्ट्समधील असुरक्षिततेचा फायदा घेऊन नफा मिळवू पाहणाऱ्या हल्लेखोरांसाठी संधी देखील दर्शवतात. + +Ethereum सारखे सार्वजनिक ब्लॉकचेन्स, स्मार्ट कॉन्ट्रॅक्ट्स सुरक्षित करण्याच्या समस्येला आणखी गुंतागुंतीचे करतात. तैनात केलेला कॉन्ट्रॅक्ट कोड _सहसा_ सुरक्षा त्रुटी दूर करण्यासाठी बदलला जाऊ शकत नाही, तर स्मार्ट कॉन्ट्रॅक्ट्समधून चोरलेली मालमत्ता अपरिवर्तनीयतेमुळे ट्रॅक करणे अत्यंत कठीण आणि बहुतेक वेळा परत मिळवता न येण्याजोगी असते. + +आकडेवारी वेगवेगळी असली तरी, स्मार्ट कॉन्ट्रॅक्ट्समधील सुरक्षा दोषांमुळे चोरलेल्या किंवा गमावलेल्या मूल्याची एकूण रक्कम $1 बिलियन पेक्षा जास्त असल्याचा अंदाज आहे. यामध्ये [DAO हॅक](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/) (3.6M ETH चोरले गेले, आजच्या किमतीनुसार $1B पेक्षा जास्त किंमत), [Parity मल्टी-सिग वॉलेट हॅक](https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach) ($30M हॅकर्समुळे गमावले), आणि [Parity फ्रोझन वॉलेट समस्या](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether) (ETH मध्ये $300M पेक्षा जास्त कायमचे लॉक झाले) यांसारख्या हाय-प्रोफाइल घटनांचा समावेश आहे. + +वर नमूद केलेल्या समस्यांमुळे डेव्हलपर्सना सुरक्षित, मजबूत आणि लवचिक स्मार्ट कॉन्ट्रॅक्ट्स तयार करण्यासाठी प्रयत्न करणे अनिवार्य होते. स्मार्ट कॉन्ट्रॅक्ट सुरक्षा हा एक गंभीर विषय आहे, आणि प्रत्येक डेव्हलपरने तो शिकणे चांगले आहे. हे मार्गदर्शक Ethereum डेव्हलपर्ससाठी सुरक्षा विचारांचा आढावा घेईल आणि स्मार्ट कॉन्ट्रॅक्ट सुरक्षा सुधारण्यासाठी संसाधने शोधेल. + +## पूर्वतयारी {#prerequisites} + +सुरक्षेचा सामना करण्यापूर्वी तुम्ही [स्मार्ट कॉन्ट्रॅक्ट डेव्हलपमेंटच्या मूलभूत गोष्टींशी](/developers/docs/smart-contracts/) परिचित आहात याची खात्री करा. + +## सुरक्षित Ethereum स्मार्ट कॉन्ट्रॅक्ट्स तयार करण्यासाठी मार्गदर्शक तत्त्वे {#smart-contract-security-guidelines} + +### १. योग्य प्रवेश नियंत्रणे डिझाइन करा {#design-proper-access-controls} + +स्मार्ट कॉन्ट्रॅक्ट्समध्ये, `public` किंवा `external` म्हणून चिन्हांकित केलेली फंक्शन्स कोणत्याही बाह्य मालकीच्या खात्यांद्वारे (EOAs) किंवा कॉन्ट्रॅक्ट खात्यांद्वारे कॉल केली जाऊ शकतात. जर तुम्हाला इतरांना तुमच्या कॉन्ट्रॅक्टशी संवाद साधायचा असेल तर फंक्शन्ससाठी सार्वजनिक दृश्यमानता निर्दिष्ट करणे आवश्यक आहे. तथापि, `private` म्हणून चिन्हांकित केलेली फंक्शन्स केवळ स्मार्ट कॉन्ट्रॅक्टमधील फंक्शन्सद्वारेच कॉल केली जाऊ शकतात, बाह्य खात्यांद्वारे नाही. प्रत्येक नेटवर्क सहभागीला कॉन्ट्रॅक्ट फंक्शन्समध्ये प्रवेश दिल्याने समस्या उद्भवू शकतात, विशेषतः जर याचा अर्थ कोणीही संवेदनशील ऑपरेशन्स करू शकतो (उदा. नवीन टोकन मिंट करणे). + +स्मार्ट कॉन्ट्रॅक्ट फंक्शन्सचा अनधिकृत वापर रोखण्यासाठी, सुरक्षित प्रवेश नियंत्रणे लागू करणे आवश्यक आहे. प्रवेश नियंत्रण यंत्रणा स्मार्ट कॉन्ट्रॅक्टमधील विशिष्ट फंक्शन्स वापरण्याची क्षमता मंजूर घटकांपुरती मर्यादित ठेवते, जसे की कॉन्ट्रॅक्ट व्यवस्थापित करण्यासाठी जबाबदार खाती. **Ownable पॅटर्न** आणि **भूमिका-आधारित नियंत्रण** हे स्मार्ट कॉन्ट्रॅक्ट्समध्ये प्रवेश नियंत्रण लागू करण्यासाठी उपयुक्त असलेले दोन पॅटर्न आहेत: + +#### Ownable पॅटर्न {#ownable-pattern} + +Ownable पॅटर्नमध्ये, कॉन्ट्रॅक्ट-निर्मिती प्रक्रियेदरम्यान एक ॲड्रेस कॉन्ट्रॅक्टचा “मालक” म्हणून सेट केला जातो. संरक्षित फंक्शन्सना `OnlyOwner` मॉडिफायर दिला जातो, जो फंक्शन कार्यान्वित करण्यापूर्वी कॉन्ट्रॅक्ट कॉलिंग ॲड्रेसची ओळख प्रमाणित करतो याची खात्री करतो. कॉन्ट्रॅक्ट मालकाव्यतिरिक्त इतर ॲड्रेसवरून संरक्षित फंक्शन्सना केलेले कॉल्स नेहमी परत येतात, ज्यामुळे अवांछित प्रवेश रोखला जातो. + +#### भूमिका-आधारित प्रवेश नियंत्रण {#role-based-access-control} + +स्मार्ट कॉन्ट्रॅक्टमध्ये एकाच ॲड्रेसला `Owner` म्हणून नोंदणी केल्याने केंद्रीकरणाचा धोका निर्माण होतो आणि तो एकच अपयशाचा बिंदू दर्शवतो. जर मालकाच्या खात्याच्या कीजशी तडजोड झाली, तर हल्लेखोर मालकीच्या कॉन्ट्रॅक्टवर हल्ला करू शकतात. म्हणूनच एकाधिक प्रशासकीय खात्यांसह भूमिका-आधारित प्रवेश नियंत्रण पॅटर्न वापरणे हा एक चांगला पर्याय असू शकतो. + +भूमिका-आधारित प्रवेश नियंत्रणामध्ये, संवेदनशील फंक्शन्समध्ये प्रवेश विश्वसनीय सहभागींच्या एका सेटमध्ये वितरित केला जातो. उदाहरणार्थ, एक खाते टोकन मिंट करण्यासाठी जबाबदार असू शकते, तर दुसरे खाते अपग्रेड करते किंवा कॉन्ट्रॅक्ट थांबवते. या प्रकारे प्रवेश नियंत्रणाचे विकेंद्रीकरण केल्याने अपयशाचे एकल बिंदू दूर होतात आणि वापरकर्त्यांसाठी विश्वासाची गृहितके कमी होतात. + +##### मल्टी-सिग्नेचर वॉलेट्स वापरणे + +सुरक्षित प्रवेश नियंत्रण लागू करण्याचा दुसरा दृष्टिकोन म्हणजे कॉन्ट्रॅक्ट व्यवस्थापित करण्यासाठी [मल्टी-सिग्नेचर खाते](/developers/docs/smart-contracts/#multisig) वापरणे. नियमित EOA च्या विपरीत, मल्टी-सिग्नेचर खाती एकाधिक घटकांच्या मालकीची असतात आणि व्यवहार कार्यान्वित करण्यासाठी किमान संख्येच्या खात्यांकडून स्वाक्षरी आवश्यक असते — समजा 5 पैकी 3. + +प्रवेश नियंत्रणासाठी मल्टीसिग वापरल्याने सुरक्षेचा एक अतिरिक्त स्तर येतो कारण लक्ष्य कॉन्ट्रॅक्टवरील क्रियांना अनेक पक्षांच्या संमतीची आवश्यकता असते. जर Ownable पॅटर्न वापरणे आवश्यक असेल तर हे विशेषतः उपयुक्त आहे, कारण यामुळे हल्लेखोर किंवा दुष्ट व्यक्तीसाठी दुर्भावनापूर्ण हेतूंसाठी संवेदनशील कॉन्ट्रॅक्ट फंक्शन्समध्ये फेरफार करणे अधिक कठीण होते. + +### २. कॉन्ट्रॅक्ट ऑपरेशन्सचे संरक्षण करण्यासाठी require(), assert(), आणि revert() विधाने वापरा {#use-require-assert-revert} + +नमूद केल्याप्रमाणे, एकदा तुमचा स्मार्ट कॉन्ट्रॅक्ट ब्लॉकचेनवर तैनात झाल्यावर कोणीही त्यातील सार्वजनिक फंक्शन्स कॉल करू शकतो. बाह्य खाती कॉन्ट्रॅक्टशी कसा संवाद साधतील हे तुम्ही आगाऊ जाणून घेऊ शकत नसल्यामुळे, तैनात करण्यापूर्वी समस्याग्रस्त ऑपरेशन्सविरूद्ध अंतर्गत सुरक्षा उपाययोजना लागू करणे आदर्श आहे. विशिष्ट आवश्यकता पूर्ण करण्यात अंमलबजावणी अयशस्वी झाल्यास अपवाद सुरू करण्यासाठी आणि स्थिती बदल परत करण्यासाठी `require()`, `assert()`, आणि `revert()` विधाने वापरून तुम्ही स्मार्ट कॉन्ट्रॅक्ट्समध्ये योग्य वर्तनाची अंमलबजावणी करू शकता. + +**`require()`**: `require` हे फंक्शन्सच्या सुरूवातीला परिभाषित केले जातात आणि कॉल केलेले फंक्शन कार्यान्वित होण्यापूर्वी पूर्वनिर्धारित अटी पूर्ण झाल्या आहेत याची खात्री करतात. एखादे `require` विधान वापरकर्ता इनपुट प्रमाणित करण्यासाठी, स्थिती व्हेरिएबल्स तपासण्यासाठी किंवा फंक्शनसह पुढे जाण्यापूर्वी कॉलिंग खात्याची ओळख प्रमाणित करण्यासाठी वापरले जाऊ शकते. + +**`assert()`**: `assert()` चा वापर अंतर्गत त्रुटी शोधण्यासाठी आणि तुमच्या कोडमधील “अपरिवर्तनीय” उल्लंघने तपासण्यासाठी केला जातो. एक अपरिवर्तनीय म्हणजे कॉन्ट्रॅक्टच्या स्थितीबद्दल एक तार्किक विधान जे सर्व फंक्शन अंमलबजावणीसाठी खरे असले पाहिजे. एका टोकन कॉन्ट्रॅक्टची कमाल एकूण पुरवठा किंवा शिल्लक हे एक अपरिवर्तनीय उदाहरण आहे. `assert()` वापरल्याने हे सुनिश्चित होते की तुमचा कॉन्ट्रॅक्ट कधीही असुरक्षित स्थितीत पोहोचणार नाही, आणि जर पोहोचला, तर स्थिती व्हेरिएबल्समधील सर्व बदल परत घेतले जातात. + +**`revert()`**: `revert()` चा वापर if-else स्टेटमेंटमध्ये केला जाऊ शकतो जो आवश्यक अट पूर्ण न झाल्यास अपवाद सुरू करतो. खालील नमुना कॉन्ट्रॅक्ट फंक्शन्सच्या अंमलबजावणीचे संरक्षण करण्यासाठी `revert()` वापरतो: + +``` +pragma solidity ^0.8.4; + +contract VendingMachine { + address owner; + error Unauthorized(); + function buy(uint amount) public payable { + if (amount > msg.value / 2 ether) + revert("Not enough Ether provided."); + // Perform the purchase. + } + function withdraw() public { + if (msg.sender != owner) + revert Unauthorized(); + + payable(msg.sender).transfer(address(this).balance); + } +} +``` + +### ३. स्मार्ट कॉन्ट्रॅक्ट्सची चाचणी घ्या आणि कोडची अचूकता सत्यापित करा {#test-smart-contracts-and-verify-code-correctness} + +[Ethereum Virtual Machine](/developers/docs/evm/) मध्ये चालणाऱ्या कोडची अपरिवर्तनीयता म्हणजे स्मार्ट कॉन्ट्रॅक्ट्सना डेव्हलपमेंटच्या टप्प्यात उच्च पातळीच्या गुणवत्ता मूल्यांकनाची आवश्यकता असते. तुमच्या कॉन्ट्रॅक्टची विस्तृतपणे चाचणी करणे आणि कोणत्याही अनपेक्षित परिणामांसाठी त्याचे निरीक्षण केल्याने मोठ्या प्रमाणात सुरक्षा सुधारेल आणि दीर्घकाळात तुमच्या वापरकर्त्यांचे संरक्षण होईल. + +नेहमीची पद्धत म्हणजे वापरकर्त्यांकडून कॉन्ट्रॅक्टला अपेक्षित असलेला मॉक डेटा वापरून लहान युनिट चाचण्या लिहिणे. [युनिट टेस्टिंग](/developers/docs/smart-contracts/testing/#unit-testing) हे विशिष्ट फंक्शन्सची कार्यक्षमता तपासण्यासाठी आणि स्मार्ट कॉन्ट्रॅक्ट अपेक्षेप्रमाणे काम करत असल्याची खात्री करण्यासाठी चांगले आहे. + +दुर्दैवाने, एकटे वापरल्यास स्मार्ट कॉन्ट्रॅक्ट सुरक्षा सुधारण्यासाठी युनिट टेस्टिंग कमीतकमी प्रभावी आहे. एक युनिट चाचणी हे सिद्ध करू शकते की एखादे फंक्शन मॉक डेटासाठी योग्यरित्या कार्यान्वित होते, परंतु युनिट चाचण्या केवळ लिहिलेल्या चाचण्यांइतक्याच प्रभावी असतात. यामुळे तुमच्या स्मार्ट कॉन्ट्रॅक्टची सुरक्षितता धोक्यात आणू शकणारे सुटलेले एज केसेस आणि असुरक्षितता शोधणे कठीण होते. + +एक चांगला दृष्टीकोन म्हणजे [स्थिर आणि गतिशील विश्लेषण](/developers/docs/smart-contracts/testing/#static-dynamic-analysis) वापरून केलेल्या मालमत्ता-आधारित चाचणीसह युनिट चाचणी एकत्र करणे. स्थिर विश्लेषण पोहोचण्यायोग्य प्रोग्राम स्थिती आणि अंमलबजावणी मार्गांचे विश्लेषण करण्यासाठी [कंट्रोल फ्लो ग्राफ्स](https://en.wikipedia.org/wiki/Control-flow_graph) आणि [ॲबस्ट्रॅक्ट सिंटॅक्स ट्रीज](https://deepsource.io/glossary/ast/) सारख्या निम्न-स्तरीय प्रतिनिधित्वांवर अवलंबून असते. दरम्यान, [स्मार्ट कॉन्ट्रॅक्ट फझिंग](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry) सारखी गतिशील विश्लेषण तंत्रे, सुरक्षा गुणधर्मांचे उल्लंघन करणाऱ्या ऑपरेशन्स शोधण्यासाठी यादृच्छिक इनपुट मूल्यांसह कॉन्ट्रॅक्ट कोड कार्यान्वित करतात. + +[औपचारिक पडताळणी](/developers/docs/smart-contracts/formal-verification) हे स्मार्ट कॉन्ट्रॅक्ट्समधील सुरक्षा गुणधर्म सत्यापित करण्याचे आणखी एक तंत्र आहे. नियमित चाचणीच्या विपरीत, औपचारिक पडताळणी स्मार्ट कॉन्ट्रॅक्टमधील त्रुटींची अनुपस्थिती निश्चितपणे सिद्ध करू शकते. हे एक औपचारिक स्पेसिफिकेशन तयार करून साध्य केले जाते जे इच्छित सुरक्षा गुणधर्मांना कॅप्चर करते आणि कॉन्ट्रॅक्ट्सचे औपचारिक मॉडेल या स्पेसिफिकेशनचे पालन करते हे सिद्ध करते. + +### ४. तुमच्या कोडचे स्वतंत्र पुनरावलोकन करण्यास सांगा {#get-independent-code-reviews} + +तुमच्या कॉन्ट्रॅक्टची चाचणी घेतल्यानंतर, इतरांना कोणत्याही सुरक्षा समस्यांसाठी स्त्रोत कोड तपासण्यास सांगणे चांगले. चाचणीमुळे स्मार्ट कॉन्ट्रॅक्टमधील प्रत्येक त्रुटी उघड होणार नाही, परंतु स्वतंत्र पुनरावलोकन मिळाल्याने असुरक्षितता शोधण्याची शक्यता वाढते. + +#### ऑडिट्स {#audits} + +स्मार्ट कॉन्ट्रॅक्ट ऑडिट करणे हा स्वतंत्र कोड पुनरावलोकन करण्याचा एक मार्ग आहे. ऑडिटर हे स्मार्ट कॉन्ट्रॅक्ट्स सुरक्षित आहेत आणि गुणवत्ता दोष आणि डिझाइन त्रुटींपासून मुक्त आहेत याची खात्री करण्यात महत्त्वाची भूमिका बजावतात. + +तरीही, तुम्ही ऑडिटला रामबाण उपाय म्हणून मानणे टाळावे. स्मार्ट कॉन्ट्रॅक्ट ऑडिट्स प्रत्येक बग पकडणार नाहीत आणि बहुतेकदा पुनरावलोकनांची अतिरिक्त फेरी प्रदान करण्यासाठी डिझाइन केलेले असतात, जे प्रारंभिक डेव्हलपमेंट आणि चाचणी दरम्यान डेव्हलपर्सकडून सुटलेल्या समस्या शोधण्यात मदत करू शकतात. तुम्ही ऑडिटर्ससोबत काम करण्यासाठी सर्वोत्तम पद्धतींचे पालन केले पाहिजे, जसे की कोडचे योग्यरित्या दस्तऐवजीकरण करणे आणि इनलाइन टिप्पण्या जोडणे, जेणेकरून स्मार्ट कॉन्ट्रॅक्ट ऑडिटचा जास्तीत जास्त फायदा घेता येईल. + +- [स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंग टिप्स आणि ट्रिक्स](https://twitter.com/tinchoabbate/status/1400170232904400897) - _@tinchoabbate_ +- [तुमच्या ऑडिटचा पुरेपूर फायदा घ्या](https://inference.ag/blog/2023-08-14-tips/) - _Inference_ + +#### बग बाउंटीज {#bug-bounties} + +बग बाउंटी प्रोग्राम सेट करणे हा बाह्य कोड पुनरावलोकन लागू करण्याचा आणखी एक दृष्टीकोन आहे. बग बाउंटी हे ॲप्लिकेशनमधील असुरक्षितता शोधणाऱ्या व्यक्तींना (सहसा व्हाईटहॅट हॅकर्सना) दिलेले आर्थिक बक्षीस आहे. + +योग्यरित्या वापरल्यास, बग बाउंटीज हॅकर समुदायाच्या सदस्यांना तुमच्या कोडमधील गंभीर त्रुटी तपासण्यासाठी प्रोत्साहन देतात. एक वास्तविक-जीवनातील उदाहरण म्हणजे “अनंत पैशाचा बग” ज्याने एका हल्लेखोराला Ethereum वर चालणाऱ्या [लेयर 2](/layer-2/) प्रोटोकॉल [Optimism](https://www.optimism.io/) वर अमर्याद प्रमाणात इथर तयार करण्याची परवानगी दिली असती. सुदैवाने, एका व्हाईटहॅट हॅकरने [ही त्रुटी शोधली](https://www.saurik.com/optimism.html) आणि टीमला सूचित केले, [या प्रक्रियेत मोठे बक्षीस मिळवले](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/). + +एक उपयुक्त धोरण म्हणजे बग बाउंटी प्रोग्रामचे पेआउट धोक्यात असलेल्या निधीच्या प्रमाणात सेट करणे. “[स्केलिंग बग बाउंटी](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)” म्हणून वर्णन केलेला हा दृष्टिकोन, व्यक्तींना असुरक्षिततेचा फायदा घेण्याऐवजी जबाबदारीने उघड करण्यासाठी आर्थिक प्रोत्साहन देतो. + +### ५. स्मार्ट कॉन्ट्रॅक्ट डेव्हलपमेंट दरम्यान सर्वोत्तम पद्धतींचे पालन करा {#follow-smart-contract-development-best-practices} + +ऑडिट्स आणि बग बाउंटीजचे अस्तित्व उच्च-गुणवत्तेचा कोड लिहिण्याच्या तुमच्या जबाबदारीतून तुम्हाला सूट देत नाही. चांगली स्मार्ट कॉन्ट्रॅक्ट सुरक्षा योग्य डिझाइन आणि डेव्हलपमेंट प्रक्रियांचे पालन करण्यापासून सुरू होते: + +- सर्व कोड git सारख्या आवृत्ती नियंत्रण प्रणालीमध्ये संग्रहित करा + +- सर्व कोड बदल पुल रिक्वेस्ट्सद्वारे करा + +- पुल रिक्वेस्ट्समध्ये किमान एक स्वतंत्र समीक्षक असल्याची खात्री करा—जर तुम्ही एखाद्या प्रोजेक्टवर एकटे काम करत असाल, तर इतर डेव्हलपर्स शोधण्याचा आणि कोड पुनरावलोकनांची देवाणघेवाण करण्याचा विचार करा + +- स्मार्ट कॉन्ट्रॅक्ट्सची चाचणी, संकलन आणि उपयोजन करण्यासाठी [विकास पर्यावरण](/developers/docs/frameworks/) वापरा + +- तुमचा कोड [Cyfrin Aderyn](https://github.com/Cyfrin/aderyn), Mythril आणि Slither सारख्या मूलभूत कोड विश्लेषण साधनांमधून चालवा. आदर्शपणे, तुम्ही प्रत्येक पुल रिक्वेस्ट विलीन होण्यापूर्वी हे केले पाहिजे आणि आउटपुटमधील फरकांची तुलना केली पाहिजे + +- तुमचा कोड त्रुटींशिवाय संकलित होतो आणि सॉलिडिटी कंपाइलर कोणतीही चेतावणी देत नाही याची खात्री करा + +- तुमच्या कोडचे योग्यरित्या दस्तऐवजीकरण करा ([NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html) वापरून) आणि कॉन्ट्रॅक्ट आर्किटेक्चरबद्दलचे तपशील समजण्यास सोप्या भाषेत वर्णन करा. यामुळे इतरांना तुमच्या कोडचे ऑडिट आणि पुनरावलोकन करणे सोपे होईल. + +### 6. मजबूत आपत्कालीन पुनर्प्राप्ती योजना लागू करा {#implement-disaster-recovery-plans} + +सुरक्षित प्रवेश नियंत्रणे डिझाइन करणे, फंक्शन मॉडिफायर्स लागू करणे आणि इतर सूचनांमुळे स्मार्ट कॉन्ट्रॅक्ट सुरक्षा सुधारू शकते, परंतु ते दुर्भावनापूर्ण शोषणांची शक्यता नाकारू शकत नाहीत. सुरक्षित स्मार्ट कॉन्ट्रॅक्ट्स तयार करण्यासाठी “अपयशासाठी तयार राहणे” आणि हल्ल्यांना प्रभावीपणे प्रतिसाद देण्यासाठी एक बॅकअप योजना असणे आवश्यक आहे. एका योग्य आपत्कालीन पुनर्प्राप्ती योजनेत खालीलपैकी काही किंवा सर्व घटक समाविष्ट असतील: + +#### कॉन्ट्रॅक्ट अपग्रेड {#contract-upgrades} + +Ethereum स्मार्ट कॉन्ट्रॅक्ट्स डीफॉल्टनुसार अपरिवर्तनीय असले तरी, अपग्रेड पॅटर्न वापरून काही प्रमाणात बदलक्षमता प्राप्त करणे शक्य आहे. ज्या प्रकरणांमध्ये गंभीर त्रुटीमुळे तुमचा जुना कॉन्ट्रॅक्ट निरुपयोगी होतो आणि नवीन तर्क तैनात करणे हा सर्वात व्यवहार्य पर्याय असतो, अशा प्रकरणांमध्ये कॉन्ट्रॅक्ट अपग्रेड करणे आवश्यक आहे. + +कॉन्ट्रॅक्ट अपग्रेड यंत्रणा वेगवेगळ्या प्रकारे काम करतात, परंतु “प्रॉक्सी पॅटर्न” हा स्मार्ट कॉन्ट्रॅक्ट्स अपग्रेड करण्यासाठी अधिक लोकप्रिय दृष्टिकोनांपैकी एक आहे. [प्रॉक्सी पॅटर्न्स](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern) ॲप्लिकेशनची स्थिती आणि तर्क _दोन_ कॉन्ट्रॅक्ट्समध्ये विभाजित करतात. पहिला कॉन्ट्रॅक्ट (ज्याला 'प्रॉक्सी कॉन्ट्रॅक्ट' म्हणतात) स्थिती व्हेरिएबल्स (उदा. वापरकर्ता शिल्लक) संग्रहित करतो, तर दुसरा कॉन्ट्रॅक्ट (ज्याला 'लॉजिक कॉन्ट्रॅक्ट' म्हणतात) कॉन्ट्रॅक्ट फंक्शन्स कार्यान्वित करण्यासाठी कोड धारण करतो. + +खाती प्रॉक्सी कॉन्ट्रॅक्टशी संवाद साधतात, जो सर्व फंक्शन कॉल्स लॉजिक कॉन्ट्रॅक्टकडे [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries) या निम्न-स्तरीय कॉलचा वापर करून पाठवतो. नियमित मेसेज कॉलच्या विपरीत, `delegatecall()` हे सुनिश्चित करते की लॉजिक कॉन्ट्रॅक्टच्या ॲड्रेसवर चालणारा कोड कॉलिंग कॉन्ट्रॅक्टच्या संदर्भात कार्यान्वित होतो. याचा अर्थ लॉजिक कॉन्ट्रॅक्ट नेहमी प्रॉक्सीच्या स्टोरेजमध्ये लिहील (त्याच्या स्वतःच्या स्टोरेजऐवजी) आणि `msg.sender` आणि `msg.value` ची मूळ मूल्ये जतन केली जातील. + +लॉजिक कॉन्ट्रॅक्टकडे कॉल सोपवण्यासाठी त्याचा ॲड्रेस प्रॉक्सी कॉन्ट्रॅक्टच्या स्टोरेजमध्ये संग्रहित करणे आवश्यक आहे. म्हणून, कॉन्ट्रॅक्टचा तर्क अपग्रेड करणे म्हणजे फक्त दुसरा लॉजिक कॉन्ट्रॅक्ट तैनात करणे आणि नवीन ॲड्रेस प्रॉक्सी कॉन्ट्रॅक्टमध्ये संग्रहित करणे. प्रॉक्सी कॉन्ट्रॅक्टला केलेले त्यानंतरचे कॉल आपोआप नवीन लॉजिक कॉन्ट्रॅक्टकडे पाठवले जात असल्याने, तुम्ही कोडमध्ये कोणताही बदल न करता कॉन्ट्रॅक्ट “अपग्रेड” केला असेल. + +[कॉन्ट्रॅक्ट अपग्रेड करण्याबद्दल अधिक](/developers/docs/smart-contracts/upgrading/). + +#### आपत्कालीन थांबे {#emergency-stops} + +नमूद केल्याप्रमाणे, विस्तृत ऑडिटिंग आणि चाचणी स्मार्ट कॉन्ट्रॅक्टमधील सर्व बग शोधू शकत नाही. उपयोजनानंतर तुमच्या कोडमध्ये एखादी असुरक्षितता आढळल्यास, ती दूर करणे अशक्य आहे कारण तुम्ही कॉन्ट्रॅक्ट ॲड्रेसवर चालणारा कोड बदलू शकत नाही. तसेच, अपग्रेड यंत्रणा (उदा. प्रॉक्सी पॅटर्न्स) लागू करण्यासाठी वेळ लागू शकतो (त्यांना अनेकदा वेगवेगळ्या पक्षांकडून मंजुरीची आवश्यकता असते), ज्यामुळे हल्लेखोरांना अधिक नुकसान करण्यासाठी अधिक वेळ मिळतो. + +अंतिम पर्याय म्हणजे “आपत्कालीन थांबा” फंक्शन लागू करणे जे कॉन्ट्रॅक्टमधील असुरक्षित फंक्शन्सना केलेले कॉल ब्लॉक करते. आपत्कालीन थांब्यांमध्ये सामान्यतः खालील घटक असतात: + +1. एक ग्लोबल बुलियन व्हेरिएबल जे स्मार्ट कॉन्ट्रॅक्ट थांबलेल्या स्थितीत आहे की नाही हे दर्शवते. हे व्हेरिएबल कॉन्ट्रॅक्ट सेट करताना `false` वर सेट केले जाते, परंतु कॉन्ट्रॅक्ट थांबवल्यावर `true` वर परत जाईल. + +2. त्यांच्या अंमलबजावणीमध्ये बुलियन व्हेरिएबलचा संदर्भ देणारी फंक्शन्स. स्मार्ट कॉन्ट्रॅक्ट थांबवलेला नसताना अशी फंक्शन्स उपलब्ध असतात आणि आपत्कालीन थांबा वैशिष्ट्य सुरू झाल्यावर ती अनुपलब्ध होतात. + +3. एक घटक ज्याला आपत्कालीन थांबा फंक्शनमध्ये प्रवेश आहे, जो बुलियन व्हेरिएबलला `true` वर सेट करतो. दुर्भावनापूर्ण कृती टाळण्यासाठी, या फंक्शनला केलेले कॉल विश्वसनीय ॲड्रेसपर्यंत (उदा. कॉन्ट्रॅक्ट मालक) मर्यादित ठेवले जाऊ शकतात. + +एकदा कॉन्ट्रॅक्टने आपत्कालीन थांबा सक्रिय केल्यावर, काही फंक्शन्स कॉल करण्यायोग्य नसतील. हे ग्लोबल व्हेरिएबलचा संदर्भ देणाऱ्या मॉडिफायरमध्ये निवडक फंक्शन्स गुंडाळून साध्य केले जाते. खाली [एक उदाहरण](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol) आहे जे कॉन्ट्रॅक्ट्समध्ये या पॅटर्नची अंमलबजावणी दर्शवते: + +```solidity +// This code has not been professionally audited and makes no promises about safety or correctness. Use at your own risk. + +contract EmergencyStop { + + bool isStopped = false; + + modifier stoppedInEmergency { + require(!isStopped); + _; + } + + modifier onlyWhenStopped { + require(isStopped); + _; + } + + modifier onlyAuthorized { + // Check for authorization of msg.sender here + _; + } + + function stopContract() public onlyAuthorized { + isStopped = true; + } + + function resumeContract() public onlyAuthorized { + isStopped = false; + } + + function deposit() public payable stoppedInEmergency { + // Deposit logic happening here + } + + function emergencyWithdraw() public onlyWhenStopped { + // Emergency withdraw happening here + } +} +``` + +हे उदाहरण आपत्कालीन थांब्यांची मूलभूत वैशिष्ट्ये दर्शवते: + +- `isStopped` हे एक बुलियन आहे जे सुरुवातीला `false` आणि कॉन्ट्रॅक्ट आपत्कालीन मोडमध्ये प्रवेश केल्यावर `true` ठरते. + +- फंक्शन मॉडिफायर्स `onlyWhenStopped` आणि `stoppedInEmergency` `isStopped` व्हेरिएबल तपासतात. `stoppedInEmergency` चा वापर अशा फंक्शन्स नियंत्रित करण्यासाठी केला जातो जे कॉन्ट्रॅक्ट असुरक्षित असताना अनुपलब्ध असले पाहिजेत (उदा. `deposit()`). या फंक्शन्सना केलेले कॉल फक्त परत येतील. + +`onlyWhenStopped` चा वापर आपत्कालीन परिस्थितीत कॉल करण्यायोग्य असलेल्या फंक्शन्ससाठी केला जातो (उदा. `emergencyWithdraw()`). अशी फंक्शन्स परिस्थिती सोडविण्यात मदत करू शकतात, म्हणूनच त्यांना “प्रतिबंधित फंक्शन्स” सूचीमधून वगळण्यात आले आहे. + +आपत्कालीन थांबा कार्यक्षमता वापरल्याने तुमच्या स्मार्ट कॉन्ट्रॅक्टमधील गंभीर असुरक्षितता हाताळण्यासाठी एक प्रभावी तात्पुरता उपाय मिळतो. तथापि, यामुळे वापरकर्त्यांना डेव्हलपर्सवर विश्वास ठेवण्याची गरज वाढते की ते स्व-सेवा कारणांसाठी ते सक्रिय करणार नाहीत. यासाठी, आपत्कालीन थांब्याचे नियंत्रण विकेंद्रित करणे, एकतर ऑनचेन मतदान यंत्रणा, टाइमलॉक किंवा मल्टीसिग वॉलेटच्या मंजुरीच्या अधीन ठेवून, हे संभाव्य उपाय आहेत. + +#### इव्हेंट मॉनिटरिंग {#event-monitoring} + +[इव्हेंट्स](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events) तुम्हाला स्मार्ट कॉन्ट्रॅक्ट फंक्शन्सना केलेले कॉल ट्रॅक करण्याची आणि स्थिती व्हेरिएबल्समधील बदल मॉनिटर करण्याची परवानगी देतात. जेव्हा एखादा पक्ष सुरक्षिततेसाठी महत्त्वपूर्ण कृती करतो (उदा. निधी काढणे) तेव्हा तुमचा स्मार्ट कॉन्ट्रॅक्ट एक इव्हेंट उत्सर्जित करण्यासाठी प्रोग्राम करणे आदर्श आहे. + +इव्हेंट्स लॉग करणे आणि त्यांचे ऑफचेन मॉनिटरिंग केल्याने कॉन्ट्रॅक्ट ऑपरेशन्सबद्दल अंतर्दृष्टी मिळते आणि दुर्भावनापूर्ण कृती लवकर शोधण्यात मदत होते. याचा अर्थ तुमची टीम हॅकला जलद प्रतिसाद देऊ शकते आणि वापरकर्त्यांवरील परिणाम कमी करण्यासाठी कृती करू शकते, जसे की फंक्शन्स थांबवणे किंवा अपग्रेड करणे. + +तुम्ही एक ऑफ-द-शेल्फ मॉनिटरिंग टूल देखील निवडू शकता जे कोणी तुमच्या कॉन्ट्रॅक्टशी संवाद साधल्यावर आपोआप अलर्ट फॉरवर्ड करते. ही साधने तुम्हाला वेगवेगळ्या ट्रिगर्सवर आधारित कस्टम अलर्ट तयार करण्याची परवानगी देतील, जसे की व्यवहाराचे प्रमाण, फंक्शन कॉलची वारंवारता किंवा विशिष्ट फंक्शन्स. उदाहरणार्थ, तुम्ही एक अलर्ट प्रोग्राम करू शकता जो एकाच व्यवहारात काढलेली रक्कम विशिष्ट मर्यादेपेक्षा जास्त झाल्यास येतो. + +### 7. सुरक्षित शासन प्रणाली डिझाइन करा {#design-secure-governance-systems} + +तुम्ही तुमच्या ॲप्लिकेशनचे विकेंद्रीकरण करू शकता, ज्यामध्ये मुख्य स्मार्ट कॉन्ट्रॅक्ट्सचे नियंत्रण समुदाय सदस्यांना सोपवले जाते. या प्रकरणात, स्मार्ट कॉन्ट्रॅक्ट सिस्टममध्ये एक गव्हर्नन्स मॉड्यूल समाविष्ट असेल - एक यंत्रणा जी समुदाय सदस्यांना ऑनचेन गव्हर्नन्स सिस्टमद्वारे प्रशासकीय कृतींना मंजूर करण्याची परवानगी देते. उदाहरणार्थ, प्रॉक्सी कॉन्ट्रॅक्टला नवीन अंमलबजावणीमध्ये अपग्रेड करण्याच्या प्रस्तावावर टोकन-धारकांकडून मतदान केले जाऊ शकते. + +विकेंद्रित शासन फायदेशीर असू शकते, विशेषतः कारण ते डेव्हलपर्स आणि अंतिम-वापरकर्त्यांच्या हितांना संरेखित करते. तरीही, स्मार्ट कॉन्ट्रॅक्ट शासन यंत्रणा चुकीच्या पद्धतीने लागू केल्यास नवीन धोके निर्माण करू शकतात. एक संभाव्य परिस्थिती अशी आहे की जर एखाद्या हल्लेखोराने [फ्लॅश लोन](/defi/#flash-loans) घेऊन प्रचंड मतदान शक्ती (टोकनच्या संख्येत मोजलेली) मिळवली आणि एक दुर्भावनापूर्ण प्रस्ताव मंजूर करून घेतला. + +ऑनचेन शासनाशी संबंधित समस्या टाळण्याचा एक मार्ग म्हणजे [टाइमलॉक वापरणे](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/). टाइमलॉक स्मार्ट कॉन्ट्रॅक्टला विशिष्ट कालावधी उलटल्याशिवाय काही क्रिया करण्यापासून प्रतिबंधित करते. इतर धोरणांमध्ये प्रत्येक टोकनला ते किती काळ लॉक केले गेले आहे यावर आधारित “मतदान वजन” देणे, किंवा सध्याच्या ब्लॉकऐवजी ऐतिहासिक कालावधीतील (उदाहरणार्थ, 2-3 ब्लॉक्स पूर्वीच्या) ॲड्रेसची मतदान शक्ती मोजणे यांचा समावेश आहे. दोन्ही पद्धती ऑनचेन मतांवर प्रभाव टाकण्यासाठी लवकर मतदान शक्ती जमा करण्याची शक्यता कमी करतात. + +सामायिक केलेल्या लिंक्समध्ये [सुरक्षित शासन प्रणाली डिझाइन करणे](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/), [DAOs मधील विविध मतदान यंत्रणा](https://hackernoon.com/governance-is-the-holy-grail-for-daos), आणि [DeFi चा लाभ घेणारे सामान्य DAO हल्ला वेक्टर](https://dacian.me/dao-governance-defi-attacks) यावर अधिक. + +### 8. कोडमधील गुंतागुंत कमीतकमी ठेवा {#reduce-code-complexity} + +पारंपारिक सॉफ्टवेअर डेव्हलपर्स KISS (“keep it simple, stupid”) तत्त्वाशी परिचित आहेत, जे सॉफ्टवेअर डिझाइनमध्ये अनावश्यक गुंतागुंत आणण्याविरुद्ध सल्ला देते. हे “गुंतागुंतीच्या प्रणाली गुंतागुंतीच्या मार्गांनी अयशस्वी होतात” आणि महागड्या चुकांना अधिक बळी पडतात या दीर्घकालीन विचाराचे अनुसरण करते. + +स्मार्ट कॉन्ट्रॅक्ट्स लिहिताना गोष्टी सोप्या ठेवणे विशेष महत्त्वाचे आहे, कारण स्मार्ट कॉन्ट्रॅक्ट्स संभाव्यतः मोठ्या प्रमाणात मूल्य नियंत्रित करतात. स्मार्ट कॉन्ट्रॅक्ट्स लिहिताना साधेपणा साधण्यासाठी एक टीप म्हणजे शक्य असेल तेथे [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/) सारख्या विद्यमान लायब्ररींचा पुन्हा वापर करणे. कारण या लायब्ररींचे डेव्हलपर्सकडून विस्तृतपणे ऑडिट आणि चाचणी केली गेली आहे, त्यामुळे त्यांचा वापर केल्याने सुरवातीपासून नवीन कार्यक्षमता लिहून बग येण्याची शक्यता कमी होते. + +आणखी एक सामान्य सल्ला म्हणजे लहान फंक्शन्स लिहिणे आणि एकाधिक कॉन्ट्रॅक्ट्समध्ये व्यावसायिक तर्क विभाजित करून कॉन्ट्रॅक्ट्स मॉड्यूलर ठेवणे. सोपा कोड लिहिल्याने केवळ स्मार्ट कॉन्ट्रॅक्टमधील हल्ल्याची पृष्ठभाग कमी होत नाही, तर संपूर्ण प्रणालीच्या अचूकतेबद्दल तर्क करणे आणि संभाव्य डिझाइन त्रुटी लवकर शोधणे देखील सोपे होते. + +### 9. सामान्य स्मार्ट कॉन्ट्रॅक्ट असुरक्षिततेपासून बचाव करा {#mitigate-common-smart-contract-vulnerabilities} + +#### रीएन्ट्रन्सी {#reentrancy} + +EVM समवर्तीतेस परवानगी देत नाही, याचा अर्थ मेसेज कॉलमध्ये सामील असलेले दोन कॉन्ट्रॅक्ट्स एकाच वेळी चालू शकत नाहीत. एक बाह्य कॉल कॉलिंग कॉन्ट्रॅक्टची अंमलबजावणी आणि मेमरी थांबवतो जोपर्यंत कॉल परत येत नाही, त्यानंतर अंमलबजावणी सामान्यपणे पुढे जाते. या प्रक्रियेचे औपचारिकपणे वर्णन [कंट्रोल फ्लो](https://www.computerhope.com/jargon/c/contflow.htm) दुसऱ्या कॉन्ट्रॅक्टकडे हस्तांतरित करणे असे केले जाऊ शकते. + +जरी बहुतेक वेळा निरुपद्रवी असले तरी, अविश्वासू कॉन्ट्रॅक्ट्सकडे कंट्रोल फ्लो हस्तांतरित केल्याने समस्या निर्माण होऊ शकतात, जसे की रीएन्ट्रन्सी. जेव्हा मूळ फंक्शनची विनंती पूर्ण होण्यापूर्वी एखादा दुर्भावनापूर्ण कॉन्ट्रॅक्ट असुरक्षित कॉन्ट्रॅक्टमध्ये परत कॉल करतो तेव्हा रीएन्ट्रन्सी हल्ला होतो. या प्रकारचा हल्ला एका उदाहरणासह उत्तम प्रकारे स्पष्ट केला आहे. + +एक साधा स्मार्ट कॉन्ट्रॅक्ट (‘Victim’) विचारात घ्या जो कोणालाही इथर जमा आणि काढण्याची परवानगी देतो: + +```solidity +// This contract is vulnerable. Do not use in production + +contract Victim { + mapping (address => uint256) public balances; + + function deposit() external payable { + balances[msg.sender] += msg.value; + } + + function withdraw() external { + uint256 amount = balances[msg.sender]; + (bool success, ) = msg.sender.call.value(amount)(""); + require(success); + balances[msg.sender] = 0; + } +} +``` + +हा कॉन्ट्रॅक्ट वापरकर्त्यांना कॉन्ट्रॅक्टमध्ये पूर्वी जमा केलेला ETH काढण्याची परवानगी देण्यासाठी `withdraw()` फंक्शन उघड करतो. पैसे काढण्याची प्रक्रिया करताना, कॉन्ट्रॅक्ट खालील ऑपरेशन्स करतो: + +1. वापरकर्त्याची ETH शिल्लक तपासते +2. कॉलिंग ॲड्रेसवर निधी पाठवते +3. त्यांची शिल्लक 0 वर रीसेट करते, ज्यामुळे वापरकर्त्याकडून अतिरिक्त पैसे काढणे प्रतिबंधित होते + +`Victim` कॉन्ट्रॅक्टमधील `withdraw()` फंक्शन “चेक्स-इंटरॅक्शन्स-इफेक्ट्स” पॅटर्नचे अनुसरण करते. ते अंमलबजावणीसाठी आवश्यक असलेल्या अटी पूर्ण झाल्या आहेत का हे _तपासते_ (उदा., वापरकर्त्याकडे सकारात्मक ETH शिल्लक आहे) आणि व्यवहाराचे _परिणाम_ लागू करण्यापूर्वी कॉलरच्या ॲड्रेसवर ETH पाठवून _संवाद_ साधते (उदा., वापरकर्त्याची शिल्लक कमी करणे). + +जर `withdraw()` बाह्य मालकीच्या खात्यातून (EOA) कॉल केले असेल, तर फंक्शन अपेक्षेप्रमाणे कार्यान्वित होते: `msg.sender.call.value()` कॉलरला ETH पाठवते. तथापि, जर `msg.sender` एक स्मार्ट कॉन्ट्रॅक्ट खाते असेल आणि ते `withdraw()` कॉल करत असेल, तर `msg.sender.call.value()` वापरून निधी पाठवल्याने त्या ॲड्रेसवर संग्रहित केलेला कोड देखील चालेल. + +कल्पना करा की हा कोड कॉन्ट्रॅक्ट ॲड्रेसवर तैनात केला आहे: + +```solidity + contract Attacker { + function beginAttack() external payable { + Victim(victim_address).deposit.value(1 ether)(); + Victim(victim_address).withdraw(); + } + + function() external payable { + if (gasleft() > 40000) { + Victim(victim_address).withdraw(); + } + } +} +``` + +हा कॉन्ट्रॅक्ट तीन गोष्टी करण्यासाठी डिझाइन केलेला आहे: + +1. दुसऱ्या खात्यातून (बहुधा हल्लेखोराच्या EOA) ठेव स्वीकारा +2. Victim कॉन्ट्रॅक्टमध्ये 1 ETH जमा करा +3. स्मार्ट कॉन्ट्रॅक्टमध्ये संग्रहित 1 ETH काढा + +येथे काहीही चुकीचे नाही, फक्त `Attacker` कडे आणखी एक फंक्शन आहे जे `Victim` मधील `withdraw()` ला पुन्हा कॉल करते जर येणाऱ्या `msg.sender.call.value` मधून उरलेला गॅस 40,000 पेक्षा जास्त असेल. हे `Attacker` ला `Victim` मध्ये पुन्हा प्रवेश करण्याची आणि `withdraw` ची पहिली विनंती पूर्ण होण्यापूर्वी अधिक निधी काढण्याची क्षमता देते. हे चक्र असे दिसते: + +```solidity +- Attacker's EOA calls `Attacker.beginAttack()` with 1 ETH +- `Attacker.beginAttack()` deposits 1 ETH into `Victim` +- `Attacker` calls `withdraw() in `Victim` +- `Victim` checks `Attacker`’s balance (1 ETH) +- `Victim` sends 1 ETH to `Attacker` (which triggers the default function) +- `Attacker` calls `Victim.withdraw()` again (note that `Victim` hasn’t reduced `Attacker`’s balance from the first withdrawal) +- `Victim` checks `Attacker`’s balance (which is still 1 ETH because it hasn’t applied the effects of the first call) +- `Victim` sends 1 ETH to `Attacker` (which triggers the default function and allows `Attacker` to reenter the `withdraw` function) +- The process repeats until `Attacker` runs out of gas, at which point `msg.sender.call.value` returns without triggering additional withdrawals +- `Victim` finally applies the results of the first transaction (and subsequent ones) to its state, so `Attacker`’s balance is set to 0 +``` + +सारांश असा आहे की कॉलरची शिल्लक फंक्शनची अंमलबजावणी पूर्ण होईपर्यंत 0 वर सेट केली जात नसल्यामुळे, त्यानंतरच्या विनंत्या यशस्वी होतील आणि कॉलरला त्यांची शिल्लक अनेक वेळा काढण्याची परवानगी मिळेल. [2016 च्या DAO हॅक](https://www.coindesk.com/learn/understanding-the-dao-attack) मध्ये घडल्याप्रमाणे, या प्रकारचा हल्ला स्मार्ट कॉन्ट्रॅक्टमधील निधी काढून घेण्यासाठी वापरला जाऊ शकतो. आजही स्मार्ट कॉन्ट्रॅक्ट्ससाठी रीएन्ट्रन्सी हल्ले ही एक गंभीर समस्या आहे, जसे की [रीएन्ट्रन्सी शोषणांची सार्वजनिक सूची](https://github.com/pcaversaccio/reentrancy-attacks) दर्शवते. + +##### रीएन्ट्रन्सी हल्ले कसे टाळावे + +रीएन्ट्रन्सी हाताळण्याचा एक दृष्टीकोन म्हणजे [चेक्स-इफेक्ट्स-इंटरॅक्शन्स पॅटर्न](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern) चे अनुसरण करणे. हा पॅटर्न फंक्शन्सची अंमलबजावणी अशा प्रकारे क्रमबद्ध करतो की अंमलबजावणीसह पुढे जाण्यापूर्वी आवश्यक तपासणी करणारा कोड प्रथम येतो, त्यानंतर कॉन्ट्रॅक्ट स्थितीमध्ये फेरफार करणारा कोड आणि शेवटी इतर कॉन्ट्रॅक्ट्स किंवा EOAs शी संवाद साधणारा कोड येतो. + +चेक्स-इफेक्ट-इंटरॅक्शन पॅटर्न `Victim` कॉन्ट्रॅक्टच्या सुधारित आवृत्तीमध्ये वापरला जातो जो खाली दर्शविला आहे: + +```solidity +contract NoLongerAVictim { + function withdraw() external { + uint256 amount = balances[msg.sender]; + balances[msg.sender] = 0; + (bool success, ) = msg.sender.call.value(amount)(""); + require(success); + } +} +``` + +हा कॉन्ट्रॅक्ट वापरकर्त्याच्या शिलकीची _तपासणी_ करतो, `withdraw()` फंक्शनचे _परिणाम_ लागू करतो (वापरकर्त्याची शिल्लक 0 वर रीसेट करून), आणि नंतर _संवाद_ साधतो (वापरकर्त्याच्या ॲड्रेसवर ETH पाठवून). हे सुनिश्चित करते की बाह्य कॉल करण्यापूर्वी कॉन्ट्रॅक्ट आपले स्टोरेज अपडेट करते, ज्यामुळे पहिल्या हल्ल्याला सक्षम करणारी री-एन्ट्रन्सी अट दूर होते. `Attacker` कॉन्ट्रॅक्ट अजूनही `NoLongerAVictim` मध्ये परत कॉल करू शकतो, परंतु `balances[msg.sender]` 0 वर सेट केल्यामुळे, अतिरिक्त काढण्यामुळे त्रुटी येईल. + +आणखी एक पर्याय म्हणजे म्युच्युअल एक्सक्लूजन लॉक (सामान्यतः "म्यूटेक्स" म्हणून वर्णन केलेले) वापरणे जे फंक्शनची विनंती पूर्ण होईपर्यंत कॉन्ट्रॅक्टच्या स्थितीचा काही भाग लॉक करते. हे एक बुलियन व्हेरिएबल वापरून लागू केले जाते जे फंक्शन कार्यान्वित होण्यापूर्वी `true` वर सेट केले जाते आणि विनंती पूर्ण झाल्यावर `false` वर परत येते. खालील उदाहरणात पाहिल्याप्रमाणे, म्यूटेक्स वापरल्याने मूळ विनंती अजूनही प्रक्रिया करत असताना फंक्शनला पुनरावृत्ती होणाऱ्या कॉलपासून संरक्षण मिळते, ज्यामुळे रीएन्ट्रन्सी प्रभावीपणे थांबते. + +```solidity +pragma solidity ^0.7.0; + +contract MutexPattern { + bool locked = false; + mapping(address => uint256) public balances; + + modifier noReentrancy() { + require(!locked, "Blocked from reentrancy."); + locked = true; + _; + locked = false; + } + // This function is protected by a mutex, so reentrant calls from within `msg.sender.call` cannot call `withdraw` again. + // The `return` statement evaluates to `true` but still evaluates the `locked = false` statement in the modifier + function withdraw(uint _amount) public payable noReentrancy returns(bool) { + require(balances[msg.sender] >= _amount, "No balance to withdraw."); + + balances[msg.sender] -= _amount; + (bool success, ) = msg.sender.call{value: _amount}(""); + require(success); + + return true; + } +} +``` + +तुम्ही [पुल पेमेंट्स](https://docs.openzeppelin.com/contracts/5.x/api/security#PullPayment) प्रणाली देखील वापरू शकता ज्यासाठी वापरकर्त्यांना स्मार्ट कॉन्ट्रॅक्ट्समधून निधी काढणे आवश्यक आहे, "पुश पेमेंट्स" प्रणालीऐवजी जी खात्यांमध्ये निधी पाठवते. यामुळे अज्ञात ॲड्रेसवरील कोड अनावधानाने सुरू होण्याची शक्यता दूर होते (आणि काही डिनायल-ऑफ-सर्व्हिस हल्ले देखील टाळू शकते). + +#### पूर्णांक अंडरफ्लो आणि ओव्हरफ्लो {#integer-underflows-and-overflows} + +जेव्हा अंकगणितीय क्रियेचे परिणाम स्वीकार्य मूल्यांच्या मर्यादेबाहेर जातात, तेव्हा पूर्णांक ओव्हरफ्लो होतो, ज्यामुळे ते सर्वात कमी दर्शविण्यायोग्य मूल्यावर "रोल ओव्हर" होते. उदाहरणार्थ, एक `uint8` फक्त 2^8-1=255 पर्यंतची मूल्ये संग्रहित करू शकतो. ज्या अंकगणितीय क्रियांचे परिणाम `255` पेक्षा जास्त होतात त्या ओव्हरफ्लो होतील आणि `uint` ला `0` वर रीसेट करतील, जसे गाडीचा ओडोमीटर कमाल मायलेज (999999) गाठल्यावर 0 वर रीसेट होतो. + +पूर्णांक अंडरफ्लो समान कारणांमुळे होतात: अंकगणितीय क्रियेचे परिणाम स्वीकार्य मर्यादेखाली येतात. समजा तुम्ही `uint8` मध्ये `0` कमी करण्याचा प्रयत्न केला, तर परिणाम फक्त कमाल दर्शविण्यायोग्य मूल्यावर (`255`) रोल ओव्हर होईल. + +पूर्णांक ओव्हरफ्लो आणि अंडरफ्लो दोन्ही कॉन्ट्रॅक्टच्या स्थिती व्हेरिएबल्समध्ये अनपेक्षित बदल घडवू शकतात आणि अनियोजित अंमलबजावणीस कारणीभूत ठरू शकतात. खाली एक उदाहरण दिले आहे जे दर्शवते की हल्लेखोर अवैध ऑपरेशन करण्यासाठी स्मार्ट कॉन्ट्रॅक्टमध्ये अंकगणितीय ओव्हरफ्लोचा कसा फायदा घेऊ शकतो: + +``` +pragma solidity ^0.7.6; + +// This contract is designed to act as a time vault. +// User can deposit into this contract but cannot withdraw for at least a week. +// User can also extend the wait time beyond the 1 week waiting period. + +/* +1. Deploy TimeLock +2. Deploy Attack with address of TimeLock +3. Call Attack.attack sending 1 ether. You will immediately be able to + withdraw your ether. + +What happened? +Attack caused the TimeLock.lockTime to overflow and was able to withdraw +before the 1 week waiting period. +*/ + +contract TimeLock { + mapping(address => uint) public balances; + mapping(address => uint) public lockTime; + + function deposit() external payable { + balances[msg.sender] += msg.value; + lockTime[msg.sender] = block.timestamp + 1 weeks; + } + + function increaseLockTime(uint _secondsToIncrease) public { + lockTime[msg.sender] += _secondsToIncrease; + } + + function withdraw() public { + require(balances[msg.sender] > 0, "Insufficient funds"); + require(block.timestamp > lockTime[msg.sender], "Lock time not expired"); + + uint amount = balances[msg.sender]; + balances[msg.sender] = 0; + + (bool sent, ) = msg.sender.call{value: amount}(""); + require(sent, "Failed to send Ether"); + } +} + +contract Attack { + TimeLock timeLock; + + constructor(TimeLock _timeLock) { + timeLock = TimeLock(_timeLock); + } + + fallback() external payable {} + + function attack() public payable { + timeLock.deposit{value: msg.value}(); + /* + if t = current lock time then we need to find x such that + x + t = 2**256 = 0 + so x = -t + 2**256 = type(uint).max + 1 + so x = type(uint).max + 1 - t + */ + timeLock.increaseLockTime( + type(uint).max + 1 - timeLock.lockTime(address(this)) + ); + timeLock.withdraw(); + } +} +``` + +##### पूर्णांक अंडरफ्लो आणि ओव्हरफ्लो कसे टाळावे + +आवृत्ती 0.8.0 पासून, सॉलिडिटी कंपाइलर पूर्णांक अंडरफ्लो आणि ओव्हरफ्लोस कारणीभूत ठरणारा कोड नाकारतो. तथापि, कमी कंपाइलर आवृत्तीसह संकलित केलेल्या कॉन्ट्रॅक्ट्सनी एकतर अंकगणितीय ऑपरेशन्स असलेल्या फंक्शन्सवर तपासणी करावी किंवा अंडरफ्लो/ओव्हरफ्लोसाठी तपासणारी लायब्ररी (उदा. [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)) वापरावी. + +#### ओरॅकल मॅनिपुलेशन {#oracle-manipulation} + +[ओरॅकल्स](/developers/docs/oracles/) ऑफचेन माहिती मिळवतात आणि स्मार्ट कॉन्ट्रॅक्ट्सना वापरण्यासाठी ऑनचेन पाठवतात. ओरॅकल्ससह, तुम्ही स्मार्ट कॉन्ट्रॅक्ट्स डिझाइन करू शकता जे ऑफचेन सिस्टम्स, जसे की भांडवली बाजार, यांच्याशी आंतरकार्य करतात, ज्यामुळे त्यांच्या ॲप्लिकेशनचा विस्तार होतो. + +परंतु जर ओरॅकल भ्रष्ट असेल आणि चुकीची माहिती ऑनचेन पाठवत असेल, तर स्मार्ट कॉन्ट्रॅक्ट्स चुकीच्या इनपुटवर आधारित कार्यान्वित होतील, ज्यामुळे समस्या निर्माण होऊ शकतात. हे “ओरॅकल समस्येचा” आधार आहे, जे ब्लॉकचेन ओरॅकलकडून आलेली माहिती अचूक, अद्ययावत आणि वेळेवर असल्याची खात्री करण्याच्या कार्याशी संबंधित आहे. + +एका मालमत्तेची स्पॉट किंमत मिळविण्यासाठी ऑनचेन ओरॅकल, जसे की विकेंद्रित एक्सचेंज, वापरणे ही एक संबंधित सुरक्षा चिंता आहे. [विकेंद्रित वित्त (DeFi)](/defi/) उद्योगातील कर्ज देणारे प्लॅटफॉर्म वापरकर्त्याच्या तारण मालमत्तेचे मूल्य निश्चित करण्यासाठी हे अनेकदा करतात, जेणेकरून ते किती कर्ज घेऊ शकतात हे ठरवता येईल. + +DEX किमती अनेकदा अचूक असतात, मुख्यत्वे बाजारात समता पुनर्संचयित करणाऱ्या आर्बिट्रेजर्समुळे. तथापि, त्या फेरफारीसाठी खुल्या आहेत, विशेषतः जर ऑनचेन ओरॅकल ऐतिहासिक ट्रेडिंग पॅटर्नवर आधारित मालमत्ता किमतींची गणना करत असेल (जे सहसा घडते). + +उदाहरणार्थ, एक हल्लेखोर तुमच्या कर्ज देणाऱ्या कॉन्ट्रॅक्टशी संवाद साधण्यापूर्वी फ्लॅश लोन घेऊन मालमत्तेची स्पॉट किंमत कृत्रिमरित्या वाढवू शकतो. मालमत्तेच्या किमतीसाठी DEX ची चौकशी केल्यास सामान्यपेक्षा जास्त मूल्य परत येईल (हल्लेखोराच्या मोठ्या “खरेदी ऑर्डर” मुळे मालमत्तेची मागणी विस्कळीत झाल्यामुळे), ज्यामुळे त्यांना गरजेपेक्षा जास्त कर्ज घेता येईल. अशा "फ्लॅश लोन हल्ल्यांचा" वापर DeFi ॲप्लिकेशन्समध्ये किंमत ओरॅकल्सवरील अवलंबित्व शोषण्यासाठी केला गेला आहे, ज्यामुळे प्रोटोकॉलना लाखो डॉलर्सचा निधी गमावावा लागला आहे. + +##### ओरॅकल मॅनिपुलेशन कसे टाळावे + +[ओरॅकल मॅनिपुलेशन टाळण्यासाठी](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples) किमान आवश्यकता म्हणजे विकेंद्रित ओरॅकल नेटवर्क वापरणे जे अपयशाचे एकल बिंदू टाळण्यासाठी अनेक स्त्रोतांकडून माहिती मिळवते. बहुतेक प्रकरणांमध्ये, विकेंद्रित ओरॅकल्समध्ये ओरॅकल नोड्सना योग्य माहिती कळवण्यासाठी प्रोत्साहित करण्यासाठी अंगभूत क्रिप्टोकॉनॉमिक प्रोत्साहन असते, ज्यामुळे ते केंद्रीकृत ओरॅकल्सपेक्षा अधिक सुरक्षित बनतात. + +जर तुम्ही मालमत्ता किमतींसाठी ऑनचेन ओरॅकलची चौकशी करण्याची योजना आखत असाल, तर टाइम-वेटेड सरासरी किंमत (TWAP) यंत्रणा लागू करणारी एक वापरण्याचा विचार करा. एक [TWAP ओरॅकल](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) दोन वेगवेगळ्या वेळी (जे तुम्ही सुधारू शकता) मालमत्तेच्या किमतीची चौकशी करते आणि मिळालेल्या सरासरीवर आधारित स्पॉट किंमत मोजते. लांब कालावधी निवडल्याने तुमचे प्रोटोकॉल किंमत फेरफारीपासून संरक्षित होते कारण अलीकडेच कार्यान्वित झालेल्या मोठ्या ऑर्डर्स मालमत्ता किमतींवर परिणाम करू शकत नाहीत. + +## डेव्हलपर्ससाठी स्मार्ट कॉन्ट्रॅक्ट सुरक्षा संसाधने {#smart-contract-security-resources-for-developers} + +### स्मार्ट कॉन्ट्रॅक्ट्सचे विश्लेषण करण्यासाठी आणि कोडची अचूकता सत्यापित करण्यासाठी साधने {#code-analysis-tools} + +- **[चाचणी साधने आणि लायब्ररी](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** - _स्मार्ट कॉन्ट्रॅक्ट्सवर युनिट चाचण्या, स्थिर विश्लेषण आणि गतिशील विश्लेषण करण्यासाठी उद्योग-मानक साधने आणि लायब्ररींचा संग्रह._ + +- **[औपचारिक पडताळणी साधने](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** - _स्मार्ट कॉन्ट्रॅक्ट्समध्ये कार्यात्मक अचूकता सत्यापित करण्यासाठी आणि अपरिवर्तनीयता तपासण्यासाठी साधने._ + +- **[स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंग सेवा](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** - _Ethereum विकास प्रकल्पांसाठी स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंग सेवा प्रदान करणाऱ्या संस्थांची सूची._ + +- **[बग बाउंटी प्लॅटफॉर्म](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** - _बग बाउंटीज समन्वयित करण्यासाठी आणि स्मार्ट कॉन्ट्रॅक्ट्समधील गंभीर असुरक्षिततेच्या जबाबदार प्रकटीकरणासाठी बक्षीस देण्यासाठी प्लॅटफॉर्म._ + +- **[फोर्क चेकर](https://forkchecker.hashex.org/)** - _फोर्क केलेल्या कॉन्ट्रॅक्टबद्दल सर्व उपलब्ध माहिती तपासण्यासाठी एक विनामूल्य ऑनलाइन साधन._ + +- **[ABI एनकोडर](https://abi.hashex.org/)** - _तुमची सॉलिडिटी कॉन्ट्रॅक्ट फंक्शन्स आणि कन्स्ट्रक्टर युक्तिवाद एनकोड करण्यासाठी एक विनामूल्य ऑनलाइन सेवा._ + +- **[Aderyn](https://github.com/Cyfrin/aderyn)** - _सॉलिडिटी स्टॅटिक ॲनालायझर, ॲबस्ट्रॅक्ट सिंटॅक्स ट्रीज (AST) मधून जात संशयित असुरक्षितता शोधतो आणि सोप्या-वाचण्यायोग्य मार्कडाउन स्वरूपात समस्या प्रिंट करतो._ + +### स्मार्ट कॉन्ट्रॅक्ट्सचे निरीक्षण करण्यासाठी साधने {#smart-contract-monitoring-tools} + +- **[Tenderly रिअल-टाइम अलर्टिंग](https://tenderly.co/monitoring)** - _तुमच्या स्मार्ट कॉन्ट्रॅक्ट्स किंवा वॉलेट्सवर असामान्य किंवा अनपेक्षित घटना घडल्यास रिअल-टाइम सूचना मिळवण्यासाठी एक साधन._ + +### स्मार्ट कॉन्ट्रॅक्ट्सच्या सुरक्षित प्रशासनासाठी साधने {#smart-contract-administration-tools} + +- **[Safe](https://safe.global/)** - _Ethereum वर चालणारा स्मार्ट कॉन्ट्रॅक्ट वॉलेट ज्यासाठी व्यवहार होण्यापूर्वी किमान संख्येच्या लोकांची मंजुरी आवश्यक असते (M-of-N)._ + +- **[OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)** - _कॉन्ट्रॅक्ट मालकी, अपग्रेड, प्रवेश नियंत्रणे, शासन, थांबवण्याची क्षमता आणि बरेच काही यासह प्रशासकीय वैशिष्ट्ये लागू करण्यासाठी कॉन्ट्रॅक्ट लायब्ररीज._ + +### स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंग सेवा {#smart-contract-auditing-services} + +- **[ConsenSys Diligence](https://diligence.consensys.io/)** - _स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंग सेवा जी ब्लॉकचेन इकोसिस्टममधील प्रकल्पांना त्यांचे प्रोटोकॉल लॉन्चसाठी तयार आहेत आणि वापरकर्त्यांचे संरक्षण करण्यासाठी तयार आहेत याची खात्री करण्यास मदत करते._ + +- **[CertiK](https://www.certik.com/)** - _ब्लॉकचेन सुरक्षा फर्म जी स्मार्ट कॉन्ट्रॅक्ट्स आणि ब्लॉकचेन नेटवर्क्सवर अत्याधुनिक औपचारिक पडताळणी तंत्रज्ञानाचा वापर करण्यात अग्रणी आहे._ + +- **[Trail of Bits](https://www.trailofbits.com/)** - _सायबर सुरक्षा कंपनी जी धोका कमी करण्यासाठी आणि कोड मजबूत करण्यासाठी हल्लेखोर मानसिकतेसह सुरक्षा संशोधन एकत्र करते._ + +- **[PeckShield](https://peckshield.com/)** - _ब्लॉकचेन सुरक्षा कंपनी जी संपूर्ण ब्लॉकचेन इकोसिस्टमच्या सुरक्षा, गोपनीयता आणि उपयोगितेसाठी उत्पादने आणि सेवा देते._ + +- **[QuantStamp](https://quantstamp.com/)** - _सुरक्षा आणि जोखीम मूल्यांकन सेवांद्वारे ब्लॉकचेन तंत्रज्ञानाचा मुख्य प्रवाहात अवलंब सुलभ करणारी ऑडिटिंग सेवा._ + +- **[OpenZeppelin](https://www.openzeppelin.com/security-audits)** - _वितरित प्रणालींसाठी सुरक्षा ऑडिट प्रदान करणारी स्मार्ट कॉन्ट्रॅक्ट सुरक्षा कंपनी._ + +- **[Runtime Verification](https://runtimeverification.com/)** - _स्मार्ट कॉन्ट्रॅक्ट्सच्या औपचारिक मॉडेलिंग आणि पडताळणीमध्ये विशेषज्ञ असलेली सुरक्षा कंपनी._ + +- **[Hacken](https://hacken.io)** - _वेब3 सायबर सुरक्षा ऑडिटर जो ब्लॉकचेन सुरक्षेसाठी 360-डिग्री दृष्टिकोन आणतो._ + +- **[Nethermind](https://www.nethermind.io/smart-contract-audits)** - _Solidity आणि Cairo ऑडिटिंग सेवा, Ethereum आणि Starknet वर स्मार्ट कॉन्ट्रॅक्ट्सची अखंडता आणि वापरकर्त्यांच्या सुरक्षिततेची खात्री करते._ + +- **[HashEx](https://hashex.org/)** - _HashEx ब्लॉकचेन आणि स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंगवर लक्ष केंद्रित करते ज्यामुळे क्रिप्टोकरन्सीची सुरक्षा सुनिश्चित होते, स्मार्ट कॉन्ट्रॅक्ट डेव्हलपमेंट, पेनिट्रेशन टेस्टिंग, ब्लॉकचेन कन्सल्टिंग यासारख्या सेवा प्रदान करते._ + +- **[Code4rena](https://code4rena.com/)** - _एक स्पर्धात्मक ऑडिट प्लॅटफॉर्म जो स्मार्ट कॉन्ट्रॅक्ट सुरक्षा तज्ञांना असुरक्षितता शोधण्यासाठी आणि वेब3 अधिक सुरक्षित बनविण्यात मदत करण्यासाठी प्रोत्साहन देतो._ + +- **[CodeHawks](https://codehawks.com/)** - _सुरक्षा संशोधकांसाठी स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंग स्पर्धा आयोजित करणारा स्पर्धात्मक ऑडिट प्लॅटफॉर्म._ + +- **[Cyfrin](https://cyfrin.io)** - _वेब3 सुरक्षा पॉवरहाऊस, उत्पादने आणि स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंग सेवांद्वारे क्रिप्टो सुरक्षा विकसित करते._ + +- **[ImmuneBytes](https://immunebytes.com/smart-contract-audit/)** - _वेब3 सुरक्षा फर्म जी अनुभवी ऑडिटर्स आणि सर्वोत्तम साधनांच्या टीमद्वारे ब्लॉकचेन प्रणालींसाठी सुरक्षा ऑडिट प्रदान करते._ + +- **[Oxorio](https://oxor.io/)** - _क्रिप्टो फर्म्स आणि DeFi प्रकल्पांसाठी EVM, Solidity, ZK, क्रॉस-चेन टेक मध्ये कौशल्यासह स्मार्ट कॉन्ट्रॅक्ट ऑडिट आणि ब्लॉकचेन सुरक्षा सेवा._ + +- **[Inference](https://inference.ag/)** - _सुरक्षा ऑडिटिंग कंपनी, EVM-आधारित ब्लॉकचेनसाठी स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंगमध्ये विशेषज्ञ. त्यांच्या तज्ञ ऑडिटर्समुळे ते संभाव्य समस्या ओळखतात आणि उपयोजनापूर्वी त्या दुरुस्त करण्यासाठी कृतीशील उपाय सुचवतात._ + +### बग बाउंटी प्लॅटफॉर्म {#bug-bounty-platforms} + +- **[Immunefi](https://immunefi.com/)** - _स्मार्ट कॉन्ट्रॅक्ट्स आणि DeFi प्रकल्पांसाठी बग बाउंटी प्लॅटफॉर्म, जिथे सुरक्षा संशोधक कोडचे पुनरावलोकन करतात, असुरक्षितता उघड करतात, पैसे मिळवतात आणि क्रिप्टो अधिक सुरक्षित करतात._ + +- **[HackerOne](https://www.hackerone.com/)** - _असुरक्षितता समन्वय आणि बग बाउंटी प्लॅटफॉर्म जो व्यवसायांना पेनिट्रेशन टेस्टर्स आणि सायबर सुरक्षा संशोधकांशी जोडतो._ + +- **[HackenProof](https://hackenproof.com/)** - _क्रिप्टो प्रकल्पांसाठी (DeFi, स्मार्ट कॉन्ट्रॅक्ट्स, वॉलेट्स, CEX आणि बरेच काही) तज्ञ बग बाउंटी प्लॅटफॉर्म, जिथे सुरक्षा व्यावसायिक ट्रायज सेवा प्रदान करतात आणि संशोधकांना संबंधित, सत्यापित बग अहवालांसाठी पैसे मिळतात._ + +- **[Sherlock](https://www.sherlock.xyz/)** - _वेब3 मध्ये स्मार्ट कॉन्ट्रॅक्ट सुरक्षेसाठी अंडररायटर, ऑडिटर्ससाठी पेआउट स्मार्ट कॉन्ट्रॅक्ट्सद्वारे व्यवस्थापित केले जातात ज्यामुळे संबंधित बग्स योग्यरित्या दिले जातात हे सुनिश्चित होते._ + +- **[CodeHawks](https://www.codehawks.com/)** - _स्पर्धात्मक बग बाउंटी प्लॅटफॉर्म जिथे ऑडिटर्स सुरक्षा स्पर्धा आणि आव्हानांमध्ये भाग घेतात, आणि (लवकरच) त्यांच्या स्वतःच्या खाजगी ऑडिटमध्ये._ + +### ज्ञात स्मार्ट कॉन्ट्रॅक्ट असुरक्षितता आणि शोषणांची प्रकाशने {#common-smart-contract-vulnerabilities-and-exploits} + +- **[ConsenSys: ज्ञात स्मार्ट कॉन्ट्रॅक्ट हल्ले](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/)** - _सर्वात महत्त्वपूर्ण कॉन्ट्रॅक्ट असुरक्षिततेचे नवशिक्यांसाठी अनुकूल स्पष्टीकरण, बहुतेक प्रकरणांसाठी नमुना कोडसह._ + +- **[SWC रजिस्ट्री](https://swcregistry.io/)** - _कॉमन वीकनेस एन्यूमरेशन (CWE) आयटमची क्युरेट केलेली सूची जी Ethereum स्मार्ट कॉन्ट्रॅक्ट्सना लागू होते._ + +- **[Rekt](https://rekt.news/)** - _उच्च-प्रोफाइल क्रिप्टो हॅक आणि शोषणांचे नियमितपणे अद्यतनित केलेले प्रकाशन, तपशीलवार पोस्ट-मॉर्टम अहवालांसह._ + +### स्मार्ट कॉन्ट्रॅक्ट सुरक्षा शिकण्यासाठी आव्हाने {#challenges-for-learning-smart-contract-security} + +- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** - _ब्लॉकचेन सुरक्षा वॉरगेम्स, आव्हाने आणि [कॅप्चर द फ्लॅग](https://www.webopedia.com/definitions/ctf-event/amp/) स्पर्धा आणि सोल्यूशन राइटअप्सची क्युरेट केलेली सूची._ + +- **[Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/)** - _DeFi स्मार्ट कॉन्ट्रॅक्ट्सची आक्षेपार्ह सुरक्षा शिकण्यासाठी आणि बग-हंटिंग आणि सुरक्षा ऑडिटिंगमध्ये कौशल्ये तयार करण्यासाठी वॉरगेम._ + +- **[Ethernaut](https://ethernaut.openzeppelin.com/)** - _वेब3/सॉलिडिटी-आधारित वॉरगेम जिथे प्रत्येक स्तर एक स्मार्ट कॉन्ट्रॅक्ट आहे ज्याला 'हॅक' करणे आवश्यक आहे._ + +- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** - _एका काल्पनिक साहसात सेट केलेले स्मार्ट कॉन्ट्रॅक्ट हॅकिंग आव्हान. आव्हान यशस्वीरित्या पूर्ण केल्यावर खाजगी बग बाउंटी प्रोग्राममध्ये प्रवेश देखील मिळतो._ + +### स्मार्ट कॉन्ट्रॅक्ट्स सुरक्षित करण्यासाठी सर्वोत्तम पद्धती {#smart-contract-security-best-practices} + +- **[ConsenSys: Ethereum स्मार्ट कॉन्ट्रॅक्ट सुरक्षा सर्वोत्तम पद्धती](https://consensys.github.io/smart-contract-best-practices/)** - _Ethereum स्मार्ट कॉन्ट्रॅक्ट्स सुरक्षित करण्यासाठी मार्गदर्शक तत्त्वांची विस्तृत सूची._ + +- **[Nascent: साधे सुरक्षा टूलकिट](https://github.com/nascentxyz/simple-security-toolkit)** - _स्मार्ट कॉन्ट्रॅक्ट डेव्हलपमेंटसाठी व्यावहारिक सुरक्षा-केंद्रित मार्गदर्शक आणि चेकलिस्टचा संग्रह._ + +- **[Solidity पॅटर्न्स](https://fravoll.github.io/solidity-patterns/)** - _स्मार्ट कॉन्ट्रॅक्ट प्रोग्रामिंग भाषा Solidity साठी सुरक्षित पॅटर्न आणि सर्वोत्तम पद्धतींचे उपयुक्त संकलन._ + +- **[Solidity डॉक्स: सुरक्षा विचार](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** - _Solidity सह सुरक्षित स्मार्ट कॉन्ट्रॅक्ट्स लिहिण्यासाठी मार्गदर्शक तत्त्वे._ + +- **[स्मार्ट कॉन्ट्रॅक्ट सुरक्षा पडताळणी मानक](https://github.com/securing/SCSVS)** - _डेव्हलपर्स, आर्किटेक्ट्स, सुरक्षा समीक्षक आणि विक्रेत्यांसाठी स्मार्ट कॉन्ट्रॅक्ट्सची सुरक्षा प्रमाणित करण्यासाठी तयार केलेली चौदा-भागांची चेकलिस्ट._ + +- **[स्मार्ट कॉन्ट्रॅक्ट सुरक्षा आणि ऑडिटिंग शिका](https://updraft.cyfrin.io/courses/security)** - _अंतिम स्मार्ट कॉन्ट्रॅक्ट सुरक्षा आणि ऑडिटिंग कोर्स, जो स्मार्ट कॉन्ट्रॅक्ट डेव्हलपर्ससाठी तयार केला आहे जे त्यांच्या सुरक्षा सर्वोत्तम पद्धती सुधारू इच्छितात आणि सुरक्षा संशोधक बनू इच्छितात._ + +### स्मार्ट कॉन्ट्रॅक्ट सुरक्षेवरील ट्युटोरियल्स {#tutorials-on-smart-contract-security} + +- [सुरक्षित स्मार्ट कॉन्ट्रॅक्ट कसे लिहावे](/developers/tutorials/secure-development-workflow/) + +- [स्मार्ट कॉन्ट्रॅक्ट बग शोधण्यासाठी स्लिथरचा वापर कसा करावा](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) + +- [स्मार्ट कॉन्ट्रॅक्ट बग शोधण्यासाठी मँटिकोरचा वापर कसा करावा](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) + +- [स्मार्ट कॉन्ट्रॅक्ट सुरक्षा मार्गदर्शक तत्त्वे](/developers/tutorials/smart-contract-security-guidelines/) + +- [तुमच्या टोकन कॉन्ट्रॅक्टला अनियंत्रित टोकन्ससह सुरक्षितपणे कसे समाकलित करावे](/developers/tutorials/token-integration-checklist/) + +- [सायफ्रिन अपड्राफ्ट - स्मार्ट कॉन्ट्रॅक्ट्स सुरक्षा आणि ऑडिटिंग पूर्ण कोर्स](https://updraft.cyfrin.io/courses/security) diff --git a/public/content/translations/mr/developers/docs/smart-contracts/testing/index.md b/public/content/translations/mr/developers/docs/smart-contracts/testing/index.md new file mode 100644 index 00000000000..22ca6cf1e05 --- /dev/null +++ b/public/content/translations/mr/developers/docs/smart-contracts/testing/index.md @@ -0,0 +1,310 @@ +--- +title: "स्मार्ट करारांची चाचणी" +description: "Ethereum स्मार्ट करारांच्या चाचणीसाठी तंत्र आणि विचारांचे विहंगावलोकन." +lang: mr +--- + +Ethereum सारखे सार्वजनिक ब्लॉकचेन अपरिवर्तनीय आहेत, ज्यामुळे स्मार्ट कराराचा कोड उपयोजनानंतर बदलणे कठीण होते. "व्हर्च्युअल अपग्रेड" करण्यासाठी [करार अपग्रेड पॅटर्न्स](/developers/docs/smart-contracts/upgrading/) अस्तित्वात आहेत, परंतु हे लागू करणे कठीण आहे आणि त्यासाठी सामाजिक सहमती आवश्यक आहे. शिवाय, एखादी त्रुटी शोधल्यानंतरच अपग्रेडद्वारे ती दुरुस्त केली जाऊ शकते—जर एखाद्या आक्रमणकर्त्याला प्रथम असुरक्षितता आढळली, तर तुमचा स्मार्ट करार धोक्यात येऊ शकतो. + +या कारणांमुळे, Mainnet वर [उपयोजन](/developers/docs/smart-contracts/deploying/) करण्यापूर्वी स्मार्ट करारांची चाचणी करणे हे [सुरक्षिततेसाठी](/developers/docs/smart-contracts/security/) किमान आवश्यकता आहे. करारांची चाचणी घेण्यासाठी आणि कोडच्या अचूकतेचे मूल्यांकन करण्यासाठी अनेक तंत्रे आहेत; तुम्ही काय निवडता हे तुमच्या गरजांवर अवलंबून आहे. तरीही, विविध साधने आणि दृष्टिकोनांनी बनलेला एक चाचणी संच करार कोडमधील किरकोळ आणि मोठ्या दोन्ही सुरक्षा त्रुटी शोधण्यासाठी आदर्श आहे. + +## पूर्वतयारी {#prerequisites} + +हे पृष्ठ Ethereum नेटवर्कवर उपयोजन करण्यापूर्वी स्मार्ट करारांची चाचणी कशी करावी हे स्पष्ट करते. तुम्ही [स्मार्ट करारांशी](/developers/docs/smart-contracts/) परिचित आहात असे गृहीत धरले आहे. + +## स्मार्ट करार चाचणी म्हणजे काय? {#what-is-smart-contract-testing} + +स्मार्ट करार चाचणी ही स्मार्ट कराराचा कोड अपेक्षेप्रमाणे काम करतो की नाही हे सत्यापित करण्याची प्रक्रिया आहे. एखादा विशिष्ट स्मार्ट करार विश्वासार्हता, उपयोगिता आणि सुरक्षिततेच्या गरजा पूर्ण करतो की नाही हे तपासण्यासाठी चाचणी उपयुक्त आहे. + +दृष्टिकोन वेगवेगळे असले तरी, बहुतेक चाचणी पद्धतींना स्मार्ट कराराला हाताळण्यासाठी अपेक्षित असलेल्या डेटाच्या लहान नमुन्यासह कार्यान्वित करणे आवश्यक आहे. जर करार नमुना डेटासाठी योग्य परिणाम देत असेल, तर तो योग्यरित्या कार्य करत आहे असे गृहीत धरले जाते. बहुतेक चाचणी साधने कराराची अंमलबजावणी अपेक्षित परिणामांशी जुळते की नाही हे तपासण्यासाठी [चाचणी प्रकरणे](https://en.m.wikipedia.org/wiki/Test_case) लिहिण्यासाठी आणि कार्यान्वित करण्यासाठी संसाधने प्रदान करतात. + +### स्मार्ट करारांची चाचणी करणे महत्त्वाचे का आहे? {#importance-of-testing-smart-contracts} + +स्मार्ट करार अनेकदा उच्च-मूल्याच्या आर्थिक मालमत्ता व्यवस्थापित करत असल्याने, किरकोळ प्रोग्रामिंग त्रुटी वापरकर्त्यांसाठी [मोठ्या नुकसानीस](https://rekt.news/leaderboard/) कारणीभूत ठरू शकतात. तथापि, कठोर चाचणीमुळे तुम्हाला स्मार्ट कराराच्या कोडमधील दोष आणि समस्या लवकर शोधण्यात आणि Mainnet वर लॉन्च करण्यापूर्वी त्या दुरुस्त करण्यात मदत होऊ शकते. + +बग आढळल्यास करार अपग्रेड करणे शक्य असले तरी, अपग्रेड गुंतागुंतीचे असतात आणि अयोग्यरित्या हाताळल्यास [त्रुटी येऊ शकतात](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/). कराराचे अपग्रेडेशन अपरिवर्तनीयतेच्या तत्त्वाला नाकारते आणि वापरकर्त्यांवर अतिरिक्त विश्वासाची गृहितके लादते. याउलट, तुमच्या कराराच्या चाचणीसाठी एक व्यापक योजना स्मार्ट करार सुरक्षा धोके कमी करते आणि उपयोजनानंतर जटिल लॉजिक अपग्रेड करण्याची गरज कमी करते. + +## स्मार्ट करारांची चाचणी करण्याच्या पद्धती {#methods-for-testing-smart-contracts} + +Ethereum स्मार्ट करारांच्या चाचणीच्या पद्धती दोन विस्तृत श्रेणींमध्ये येतात: **स्वयंचलित चाचणी** आणि **मॅन्युअल चाचणी**. स्वयंचलित चाचणी आणि मॅन्युअल चाचणी अद्वितीय फायदे आणि तोटे देतात, परंतु तुम्ही तुमच्या करारांचे विश्लेषण करण्यासाठी एक मजबूत योजना तयार करण्यासाठी दोन्ही एकत्र करू शकता. + +### स्वयंचलित चाचणी {#automated-testing} + +स्वयंचलित चाचणी अशा साधनांचा वापर करते जी अंमलबजावणीमधील त्रुटींसाठी स्मार्ट कराराचा कोड आपोआप तपासतात. स्वयंचलित चाचणीचा फायदा करार कार्यक्षमतेच्या मूल्यांकनासाठी [स्क्रिप्ट्स](https://www.techtarget.com/whatis/definition/script?amp=1) वापरण्यापासून मिळतो. स्क्रिप्टेड चाचण्या कमीत कमी मानवी हस्तक्षेपासह वारंवार चालवण्यासाठी शेड्यूल केल्या जाऊ शकतात, ज्यामुळे स्वयंचलित चाचणी मॅन्युअल चाचणी पद्धतींपेक्षा अधिक कार्यक्षम बनते. + +जेव्हा चाचण्या पुनरावृत्ती होणाऱ्या आणि वेळखाऊ असतात; मॅन्युअली करणे कठीण असते; मानवी त्रुटीस बळी पडण्याची शक्यता असते; किंवा गंभीर करार कार्यांचे मूल्यांकन करणे समाविष्ट असते तेव्हा स्वयंचलित चाचणी विशेषतः उपयुक्त आहे. परंतु स्वयंचलित चाचणी साधनांमध्ये काही तोटे असू शकतात—ते काही बग्स चुकवू शकतात आणि अनेक [चुकीचे सकारात्मक](https://www.contrastsecurity.com/glossary/false-positive) परिणाम देऊ शकतात. म्हणून, स्मार्ट करारांसाठी स्वयंचलित चाचणीला मॅन्युअल चाचणीसोबत जोडणे आदर्श आहे. + +### मॅन्युअल चाचणी {#manual-testing} + +मॅन्युअल चाचणी मानवी-सहाय्यित असते आणि त्यात स्मार्ट कराराच्या अचूकतेचे विश्लेषण करताना तुमच्या चाचणी संचातील प्रत्येक चाचणी प्रकरण एकामागून एक कार्यान्वित करणे समाविष्ट असते. हे स्वयंचलित चाचणीच्या विपरीत आहे जिथे तुम्ही एकाच वेळी करारावर अनेक वेगळ्या चाचण्या चालवू शकता आणि सर्व अयशस्वी आणि यशस्वी चाचण्या दर्शवणारा अहवाल मिळवू शकता. + +मॅन्युअल चाचणी एकाच व्यक्तीद्वारे केली जाऊ शकते जी विविध चाचणी परिस्थितींचा समावेश असलेल्या लिखित चाचणी योजनेचे पालन करते. तुम्ही मॅन्युअल चाचणीचा भाग म्हणून एका विशिष्ट कालावधीत अनेक व्यक्ती किंवा गटांना स्मार्ट कराराशी संवाद साधायला लावू शकता. चाचणी करणारे कराराच्या वास्तविक वर्तनाची अपेक्षित वर्तनाशी तुलना करतील, कोणत्याही फरकाला बग म्हणून चिन्हांकित करतील. + +प्रभावी मॅन्युअल चाचणीसाठी भरीव संसाधने (कौशल्य, वेळ, पैसा आणि प्रयत्न) आवश्यक असतात, आणि मानवी त्रुटीमुळे—चाचण्या कार्यान्वित करताना काही त्रुटी चुकण्याची शक्यता असते. परंतु मॅन्युअल चाचणी देखील फायदेशीर असू शकते—उदाहरणार्थ, एक मानवी चाचणीकर्ता (उदा., एक ऑडिटर) स्वयंचलित चाचणी साधनाने चुकवलेल्या एज केसेस शोधण्यासाठी अंतर्ज्ञान वापरू शकतो. + +## स्मार्ट करारांसाठी स्वयंचलित चाचणी {#automated-testing-for-smart-contracts} + +### युनिट चाचणी {#unit-testing-for-smart-contracts} + +युनिट चाचणी करार कार्यांचे स्वतंत्रपणे मूल्यांकन करते आणि प्रत्येक घटक योग्यरित्या कार्य करतो की नाही हे तपासते. चांगल्या युनिट चाचण्या सोप्या, चालवण्यास जलद असाव्यात आणि चाचण्या अयशस्वी झाल्यास काय चुकले याची स्पष्ट कल्पना द्यावी. + +कार्य अपेक्षित मूल्ये परत करतात की नाही आणि कार्य अंमलबजावणीनंतर करार स्टोरेज योग्यरित्या अपडेट केले आहे की नाही हे तपासण्यासाठी युनिट चाचण्या उपयुक्त आहेत. शिवाय, कराराच्या कोडबेसमध्ये बदल केल्यानंतर युनिट चाचण्या चालवल्याने नवीन लॉजिक जोडल्याने त्रुटी येत नाहीत याची खात्री होते. प्रभावी युनिट चाचण्या चालवण्यासाठी खाली काही मार्गदर्शक तत्त्वे आहेत: + +#### स्मार्ट करारांच्या युनिट चाचणीसाठी मार्गदर्शक तत्त्वे {#unit-testing-guidelines} + +##### १. तुमच्या करारांचे व्यावसायिक लॉजिक आणि कार्यप्रवाह समजून घ्या + +युनिट चाचण्या लिहिण्यापूर्वी, स्मार्ट करार कोणती कार्यक्षमता देतो आणि वापरकर्ते त्या कार्यांमध्ये कसे प्रवेश करतील आणि त्यांचा वापर कसा करतील हे जाणून घेणे उपयुक्त ठरते. हे विशेषतः [हॅपी पाथ चाचण्या](https://en.m.wikipedia.org/wiki/Happy_path) चालवण्यासाठी उपयुक्त आहे जे करारातील कार्ये वैध वापरकर्ता इनपुटसाठी योग्य आउटपुट परत करतात की नाही हे ठरवतात. आम्ही ही संकल्पना [लिलाव कराराच्या](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction) या (संक्षिप्त) उदाहरणाचा वापर करून स्पष्ट करू + +```solidity +constructor( + uint biddingTime, + address payable beneficiaryAddress + ) { + beneficiary = beneficiaryAddress; + auctionEndTime = block.timestamp + biddingTime; + } + +function bid() external payable { + + if (block.timestamp > auctionEndTime) + revert AuctionAlreadyEnded(); + + if (msg.value <= highestBid) + revert BidNotHighEnough(highestBid); + + if (highestBid != 0) { + pendingReturns[highestBidder] += highestBid; + } + highestBidder = msg.sender; + highestBid = msg.value; + emit HighestBidIncreased(msg.sender, msg.value); + } + + function withdraw() external returns (bool) { + uint amount = pendingReturns[msg.sender]; + if (amount > 0) { + pendingReturns[msg.sender] = 0; + + if (!payable(msg.sender).send(amount)) { + pendingReturns[msg.sender] = amount; + return false; + } + } + return true; + } + +function auctionEnd() external { + if (block.timestamp < auctionEndTime) + revert AuctionNotYetEnded(); + if (ended) + revert AuctionEndAlreadyCalled(); + + ended = true; + emit AuctionEnded(highestBidder, highestBid); + + beneficiary.transfer(highestBid); + } +} +``` + +हा एक साधा लिलाव करार आहे जो बोलीच्या कालावधीत बोली स्वीकारण्यासाठी डिझाइन केलेला आहे. जर `highestBid` वाढली, तर मागील सर्वोच्च बोली लावणाऱ्याला त्याचे पैसे परत मिळतात; एकदा बोलीचा कालावधी संपला की, `beneficiary` त्याचे पैसे मिळवण्यासाठी कराराला कॉल करतो. + +अशा करारासाठी युनिट चाचण्या कराराशी संवाद साधताना वापरकर्ता कॉल करू शकणाऱ्या विविध कार्यांना कव्हर करतील. एक उदाहरण म्हणजे एक युनिट चाचणी जी तपासते की लिलाव चालू असताना वापरकर्ता बोली लावू शकतो की नाही (म्हणजे, `bid()` ला केलेले कॉल यशस्वी होतात) किंवा एक जी तपासते की वापरकर्ता सध्याच्या `highestBid` पेक्षा जास्त बोली लावू शकतो की नाही. + +कराराचा कार्यान्वयन कार्यप्रवाह समजून घेतल्याने अंमलबजावणी आवश्यकता पूर्ण करते की नाही हे तपासणाऱ्या युनिट चाचण्या लिहिण्यास देखील मदत होते. उदाहरणार्थ, लिलाव करार निर्दिष्ट करतो की लिलाव संपल्यावर वापरकर्ते बोली लावू शकत नाहीत (म्हणजे, जेव्हा `auctionEndTime` हे `block.timestamp` पेक्षा कमी असते). म्हणून, एक डेव्हलपर एक युनिट चाचणी चालवू शकतो जी लिलाव संपल्यावर `bid()` फंक्शनला केलेले कॉल यशस्वी होतात की अयशस्वी होतात हे तपासते (म्हणजे, जेव्हा `auctionEndTime` > `block.timestamp` असते). + +##### २. करार अंमलबजावणीशी संबंधित सर्व गृहितकांचे मूल्यांकन करा + +कराराच्या अंमलबजावणीबद्दलच्या कोणत्याही गृहितकांचे दस्तऐवजीकरण करणे आणि त्या गृहितकांची वैधता सत्यापित करण्यासाठी युनिट चाचण्या लिहिणे महत्त्वाचे आहे. अनपेक्षित अंमलबजावणीपासून संरक्षण देण्याव्यतिरिक्त, चाचणी दावे तुम्हाला अशा ऑपरेशन्सबद्दल विचार करण्यास भाग पाडतात जे स्मार्ट कराराचे सुरक्षा मॉडेल तोडू शकतात. एक उपयुक्त टीप म्हणजे "हॅपी युझर टेस्ट"च्या पलीकडे जाऊन चुकीच्या इनपुटसाठी फंक्शन अयशस्वी होते की नाही हे तपासणाऱ्या नकारात्मक चाचण्या लिहिणे. + +अनेक युनिट टेस्टिंग फ्रेमवर्क तुम्हाला दावे तयार करण्याची परवानगी देतात—साधी विधाने जी सांगतात की करार काय करू शकतो आणि काय करू शकत नाही—आणि अंमलबजावणी अंतर्गत ते दावे टिकतात की नाही हे पाहण्यासाठी चाचण्या चालवतात. पूर्वी वर्णन केलेल्या लिलाव करारावर काम करणारा एक डेव्हलपर नकारात्मक चाचण्या चालवण्यापूर्वी त्याच्या वर्तनाबद्दल खालील दावे करू शकतो: + +- लिलाव संपल्यावर किंवा सुरू झाला नसताना वापरकर्ते बोली लावू शकत नाहीत. + +- स्वीकार्य मर्यादेपेक्षा कमी बोली असल्यास लिलाव करार परत येतो. + +- बोली जिंकण्यात अयशस्वी झालेल्या वापरकर्त्यांना त्यांचे फंड परत मिळतात + +**टीप**: गृहितकांची चाचणी करण्याचा आणखी एक मार्ग म्हणजे करारात [फंक्शन मॉडिफायर्स](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers) ट्रिगर करणाऱ्या चाचण्या लिहिणे, विशेषतः `require`, `assert`, आणि `if…else` विधाने. + +##### ३. कोड कव्हरेज मोजा + +[कोड कव्हरेज](https://en.m.wikipedia.org/wiki/Code_coverage) हे एक चाचणी मेट्रिक आहे जे चाचण्यांदरम्यान तुमच्या कोडमध्ये कार्यान्वित केलेल्या शाखा, ओळी आणि विधानांची संख्या ट्रॅक करते. न तपासलेल्या असुरक्षिततेचा धोका कमी करण्यासाठी चाचण्यांमध्ये चांगले कोड कव्हरेज असावे. पुरेशा कव्हरेजशिवाय, तुम्ही चुकीच्या पद्धतीने गृहीत धरू शकता की तुमचा करार सुरक्षित आहे कारण सर्व चाचण्या पास होतात, तर न तपासलेल्या कोड मार्गांमध्ये अजूनही असुरक्षितता अस्तित्वात असते. तथापि, उच्च कोड कव्हरेज नोंदवल्याने स्मार्ट करारातील सर्व विधाने/कार्य अचूकतेसाठी पुरेशा प्रमाणात तपासली गेली असल्याची खात्री मिळते. + +##### ४. सुविकसित चाचणी फ्रेमवर्क वापरा + +तुमच्या स्मार्ट करारांसाठी युनिट चाचण्या चालवण्यासाठी वापरल्या जाणार्‍या साधनांची गुणवत्ता महत्त्वपूर्ण आहे. एक आदर्श चाचणी फ्रेमवर्क म्हणजे जे नियमितपणे सांभाळले जाते; उपयुक्त वैशिष्ट्ये (उदा., लॉगिंग आणि रिपोर्टिंग क्षमता) प्रदान करते; आणि इतर डेव्हलपर्सनी मोठ्या प्रमाणावर वापरलेले आणि तपासलेले असावे. + +Solidity स्मार्ट करारांसाठी युनिट टेस्टिंग फ्रेमवर्क वेगवेगळ्या भाषांमध्ये (मुख्यतः JavaScript, Python आणि Rust) येतात. वेगवेगळ्या चाचणी फ्रेमवर्कसह युनिट चाचण्या चालवणे कसे सुरू करावे याबद्दलच्या माहितीसाठी खालील काही मार्गदर्शक तत्त्वे पहा: + +- **[Brownie सह युनिट चाचण्या चालवणे](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** +- **[Foundry सह युनिट चाचण्या चालवणे](https://book.getfoundry.sh/forge/writing-tests)** +- **[Waffle सह युनिट चाचण्या चालवणे](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)** +- **[Remix सह युनिट चाचण्या चालवणे](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)** +- **[Ape सह युनिट चाचण्या चालवणे](https://docs.apeworx.io/ape/stable/userguides/testing.html)** +- **[Hardhat सह युनिट चाचण्या चालवणे](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** +- **[Wake सह युनिट चाचण्या चालवणे](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** + +### एकत्रीकरण चाचणी {#integration-testing-for-smart-contracts} + +युनिट चाचणी करार कार्यांना वेगळे करून डीबग करते, तर एकत्रीकरण चाचण्या स्मार्ट कराराच्या घटकांचे संपूर्णपणे मूल्यांकन करतात. एकत्रीकरण चाचणी क्रॉस-करार कॉल्स किंवा एकाच स्मार्ट करारातील वेगवेगळ्या कार्यांमधील परस्परसंवादातून उद्भवणाऱ्या समस्या शोधू शकते. उदाहरणार्थ, एकत्रीकरण चाचण्या [इनहेरिटन्स](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) आणि अवलंबित्व इंजेक्शन यांसारख्या गोष्टी योग्यरित्या कार्य करतात की नाही हे तपासण्यात मदत करू शकतात. + +जर तुमचा करार मॉड्युलर आर्किटेक्चरचा अवलंब करत असेल किंवा अंमलबजावणी दरम्यान इतर ऑनचेन करारांशी संवाद साधत असेल तर एकत्रीकरण चाचणी उपयुक्त आहे. एकत्रीकरण चाचण्या चालवण्याचा एक मार्ग म्हणजे एका विशिष्ट उंचीवर [ब्लॉकचेनला फोर्क करणे](/glossary/#fork) ([Forge](https://book.getfoundry.sh/forge/fork-testing) किंवा [Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks) सारख्या साधनांचा वापर करून) आणि तुमच्या करार आणि उपयोजित करारांमधील परस्परसंवादांचे अनुकरण करणे. + +फोर्क केलेला ब्लॉकचेन Mainnet प्रमाणेच वागेल आणि त्यात संबंधित स्थिती आणि शिल्लक असलेली खाती असतील. परंतु ते केवळ सँडबॉक्स्ड स्थानिक विकास वातावरण म्हणून कार्य करते, याचा अर्थ तुम्हाला व्यवहारांसाठी वास्तविक ETH ची गरज भासणार नाही, उदाहरणार्थ, किंवा तुमचे बदल वास्तविक Ethereum प्रोटोकॉलवर परिणाम करणार नाहीत. + +### गुणधर्म-आधारित चाचणी {#property-based-testing-for-smart-contracts} + +गुणधर्म-आधारित चाचणी ही स्मार्ट करार काही परिभाषित गुणधर्म पूर्ण करतो की नाही हे तपासण्याची प्रक्रिया आहे. गुणधर्म कराराच्या वर्तनाबद्दल तथ्ये सांगतात जे वेगवेगळ्या परिस्थितीत खरे राहण्याची अपेक्षा असते—स्मार्ट कराराच्या गुणधर्माचे एक उदाहरण असू शकते "करारातील अंकगणितीय ऑपरेशन्स कधीही ओव्हरफ्लो किंवा अंडरफ्लो होत नाहीत." + +**स्थिर विश्लेषण** आणि **डायनॅमिक विश्लेषण** हे गुणधर्म-आधारित चाचणी कार्यान्वित करण्यासाठी दोन सामान्य तंत्रे आहेत आणि दोन्ही सत्यापित करू शकतात की प्रोग्रामचा कोड (या प्रकरणात स्मार्ट करार) काही पूर्वनिर्धारित गुणधर्म पूर्ण करतो. काही गुणधर्म-आधारित चाचणी साधने अपेक्षित करार गुणधर्मांबद्दल पूर्वनिर्धारित नियमांसह येतात आणि त्या नियमांनुसार कोड तपासतात, तर इतर तुम्हाला स्मार्ट करारासाठी सानुकूल गुणधर्म तयार करण्याची परवानगी देतात. + +#### स्थिर विश्लेषण {#static-analysis} + +एक स्थिर विश्लेषक स्मार्ट कराराचा स्त्रोत कोड इनपुट म्हणून घेतो आणि करार गुणधर्म पूर्ण करतो की नाही हे घोषित करणारे परिणाम आउटपुट करतो. डायनॅमिक विश्लेषणाच्या विपरीत, स्थिर विश्लेषणात अचूकतेसाठी त्याचे विश्लेषण करण्यासाठी करार कार्यान्वित करणे समाविष्ट नाही. स्थिर विश्लेषण त्याऐवजी अंमलबजावणी दरम्यान स्मार्ट करार घेऊ शकणाऱ्या सर्व संभाव्य मार्गांबद्दल तर्क करतो (म्हणजे, स्त्रोत कोडच्या संरचनेचे परीक्षण करून हे ठरवण्यासाठी की रनटाइममध्ये कराराच्या ऑपरेशनसाठी त्याचा काय अर्थ होईल). + +[लिंटिंग](https://www.perforce.com/blog/qac/what-is-linting) आणि [स्टॅटिक टेस्टिंग](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) हे करारांवर स्थिर विश्लेषण चालवण्यासाठी सामान्य पद्धती आहेत. दोन्हींना कंपाइलरद्वारे आउटपुट केलेल्या [ॲबस्ट्रॅक्ट सिंटॅक्स ट्रीज](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) आणि [कंट्रोल फ्लो ग्राफ्स](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/) सारख्या कराराच्या अंमलबजावणीच्या निम्न-स्तरीय प्रतिनिधित्वांचे विश्लेषण करणे आवश्यक आहे. + +बहुतेक प्रकरणांमध्ये, स्थिर विश्लेषण असुरक्षित रचनांचा वापर, वाक्यरचना त्रुटी किंवा कराराच्या कोडमधील कोडिंग मानकांचे उल्लंघन यासारख्या सुरक्षा समस्या शोधण्यासाठी उपयुक्त आहे. तथापि, स्थिर विश्लेषक सामान्यतः खोल असुरक्षितता शोधण्यात अकार्यक्षम म्हणून ओळखले जातात आणि जास्त प्रमाणात चुकीचे सकारात्मक परिणाम देऊ शकतात. + +#### डायनॅमिक विश्लेषण {#dynamic-analysis} + +डायनॅमिक विश्लेषण स्मार्ट कराराच्या फंक्शन्सना प्रतिकात्मक इनपुट (उदा., [प्रतिकात्मक अंमलबजावणीमध्ये](https://en.m.wikipedia.org/wiki/Symbolic_execution)) किंवा ठोस इनपुट (उदा., [फझिंगमध्ये](https://owasp.org/www-community/Fuzzing)) तयार करते हे पाहण्यासाठी की कोणताही अंमलबजावणी ट्रेस विशिष्ट गुणधर्मांचे उल्लंघन करतो का. गुणधर्म-आधारित चाचणीचा हा प्रकार युनिट चाचण्यांपेक्षा वेगळा आहे कारण चाचणी प्रकरणे एकाधिक परिस्थिती कव्हर करतात आणि एक प्रोग्राम चाचणी प्रकरणे तयार करण्याचे काम हाताळतो. + +[फझिंग](https://www.halborn.com/blog/post/what-is-fuzz-testing-fuzzing) हे स्मार्ट करारांमधील अनियंत्रित गुणधर्म सत्यापित करण्यासाठी डायनॅमिक विश्लेषण तंत्राचे एक उदाहरण आहे. एक फझर लक्ष्य करारातील फंक्शन्सना परिभाषित इनपुट मूल्याच्या यादृच्छिक किंवा विकृत भिन्नतांसह आमंत्रित करतो. जर स्मार्ट करार त्रुटीच्या स्थितीत प्रवेश करतो (उदा., जिथे एक दावा अयशस्वी होतो), तर समस्या ध्वजांकित केली जाते आणि असुरक्षित मार्गाकडे अंमलबजावणी चालवणारे इनपुट अहवालात तयार केले जातात. + +स्मार्ट कराराच्या इनपुट प्रमाणीकरण यंत्रणेचे मूल्यांकन करण्यासाठी फझिंग उपयुक्त आहे कारण अनपेक्षित इनपुटच्या अयोग्य हाताळणीमुळे अनपेक्षित अंमलबजावणी होऊ शकते आणि धोकादायक परिणाम होऊ शकतात. गुणधर्म-आधारित चाचणीचा हा प्रकार अनेक कारणांसाठी आदर्श असू शकतो: + +1. **अनेक परिस्थिती कव्हर करण्यासाठी चाचणी प्रकरणे लिहिणे कठीण आहे.** गुणधर्म चाचणीसाठी फक्त तुम्हाला वर्तन आणि वर्तनाची चाचणी घेण्यासाठी डेटाची श्रेणी परिभाषित करणे आवश्यक आहे—प्रोग्राम परिभाषित गुणधर्मावर आधारित स्वयंचलितपणे चाचणी प्रकरणे तयार करतो. + +2. **तुमचा चाचणी संच प्रोग्राममधील सर्व संभाव्य मार्ग पुरेशा प्रमाणात कव्हर करू शकत नाही.** 100% कव्हरेजसह देखील, एज केसेस चुकण्याची शक्यता असते. + +3. **युनिट चाचण्या सिद्ध करतात की करार नमुना डेटासाठी योग्यरित्या कार्यान्वित होतो, परंतु नमुन्याबाहेरील इनपुटसाठी करार योग्यरित्या कार्यान्वित होतो की नाही हे अज्ञात राहते.** गुणधर्म चाचण्या दावा अयशस्वी होण्यास कारणीभूत ठरणारे अंमलबजावणी ट्रेस शोधण्यासाठी दिलेल्या इनपुट मूल्याच्या एकाधिक भिन्नतांसह लक्ष्य करार कार्यान्वित करतात. म्हणून, एक गुणधर्म चाचणी अधिक हमी देते की करार इनपुट डेटाच्या विस्तृत वर्गासाठी योग्यरित्या कार्यान्वित होतो. + +### स्मार्ट करारांसाठी गुणधर्म-आधारित चाचणी चालवण्यासाठी मार्गदर्शक तत्त्वे {#running-property-based-tests} + +गुणधर्म-आधारित चाचणी चालवणे सामान्यतः स्मार्ट करारात सत्यापित करू इच्छित असलेल्या गुणधर्माची (उदा., [पूर्णांक ओव्हरफ्लोचा](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow) अभाव) किंवा गुणधर्मांच्या संग्रहाची व्याख्या करून सुरू होते. गुणधर्म चाचण्या लिहिताना तुम्हाला मूल्यांची एक श्रेणी देखील परिभाषित करण्याची आवश्यकता असू शकते ज्यामध्ये प्रोग्राम व्यवहार इनपुटसाठी डेटा तयार करू शकतो. + +एकदा योग्यरित्या कॉन्फिगर केल्यावर, गुणधर्म चाचणी साधन तुमच्या स्मार्ट कराराच्या फंक्शन्सना यादृच्छिकपणे तयार केलेल्या इनपुटसह कार्यान्वित करेल. जर कोणतेही दावा उल्लंघन असेल, तर तुम्हाला मूल्यांकनाखालील गुणधर्माचे उल्लंघन करणाऱ्या ठोस इनपुट डेटासह एक अहवाल मिळायला हवा. वेगवेगळ्या साधनांसह गुणधर्म-आधारित चाचणी चालवणे सुरू करण्यासाठी खालील काही मार्गदर्शक तत्त्वे पहा: + +- **[Slither सह स्मार्ट करारांचे स्थिर विश्लेषण](https://github.com/crytic/slither)** +- **[Wake सह स्मार्ट करारांचे स्थिर विश्लेषण](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** +- **[Brownie सह गुणधर्म-आधारित चाचणी](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)** +- **[Foundry सह करारांचे फझिंग](https://book.getfoundry.sh/forge/fuzz-testing)** +- **[Echidna सह करारांचे फझिंग](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)** +- **[Wake सह करारांचे फझिंग](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)** +- **[Manticore सह स्मार्ट करारांची प्रतिकात्मक अंमलबजावणी](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)** +- **[Mythril सह स्मार्ट करारांची प्रतिकात्मक अंमलबजावणी](https://mythril-classic.readthedocs.io/en/master/tutorial.html)** + +## स्मार्ट करारांसाठी मॅन्युअल चाचणी {#manual-testing-for-smart-contracts} + +स्मार्ट करारांची मॅन्युअल चाचणी अनेकदा स्वयंचलित चाचण्या चालवल्यानंतर विकास चक्रात नंतर येते. चाचणीचा हा प्रकार स्मार्ट कराराचे एक पूर्णपणे एकात्मिक उत्पादन म्हणून मूल्यांकन करतो हे पाहण्यासाठी की ते तांत्रिक आवश्यकतांमध्ये निर्दिष्ट केल्याप्रमाणे कार्य करते की नाही. + +### स्थानिक ब्लॉकचेनवर करारांची चाचणी करणे {#testing-on-local-blockchain} + +स्थानिक विकास वातावरणात केलेली स्वयंचलित चाचणी उपयुक्त डीबगिंग माहिती प्रदान करू शकते, तरीही तुमचा स्मार्ट करार उत्पादन वातावरणात कसा वागतो हे तुम्हाला जाणून घ्यायचे असेल. तथापि, मुख्य Ethereum चेनवर उपयोजन केल्यास गॅस शुल्क लागते—तुमच्या स्मार्ट करारात अजूनही बग असल्यास तुम्ही किंवा तुमचे वापरकर्ते वास्तविक पैसे गमावू शकतात हे सांगायला नको. + +तुमच्या कराराची स्थानिक ब्लॉकचेनवर ([विकास नेटवर्क](/developers/docs/development-networks/) म्हणूनही ओळखले जाते) चाचणी करणे हे Mainnet वर चाचणी करण्यासाठी एक शिफारस केलेला पर्याय आहे. स्थानिक ब्लॉकचेन हे तुमच्या संगणकावर स्थानिक पातळीवर चालणाऱ्या Ethereum ब्लॉकचेनची एक प्रत आहे जी Ethereum च्या अंमलबजावणी स्तराच्या वर्तनाचे अनुकरण करते. त्यामुळे, तुम्ही महत्त्वपूर्ण ओव्हरहेड न होता कराराशी संवाद साधण्यासाठी व्यवहार प्रोग्राम करू शकता. + +स्थानिक ब्लॉकचेनवर करार चालवणे मॅन्युअल एकत्रीकरण चाचणीचा एक प्रकार म्हणून उपयुक्त ठरू शकते. [स्मार्ट करार अत्यंत संयोजनक्षम असतात](/developers/docs/smart-contracts/composability/), जे तुम्हाला विद्यमान प्रोटोकॉलसह समाकलित करण्याची परवानगी देतात—परंतु तुम्हाला अजूनही हे सुनिश्चित करणे आवश्यक आहे की अशा जटिल ऑनचेन परस्परसंवादातून योग्य परिणाम मिळतात. + +[विकास नेटवर्कबद्दल अधिक.](/developers/docs/development-networks/) + +### टेस्टनेटवर करारांची चाचणी करणे {#testing-contracts-on-testnets} + +एक चाचणी नेटवर्क किंवा टेस्टनेट Ethereum Mainnet प्रमाणेच कार्य करते, फक्त ते वास्तविक-जगाचे मूल्य नसलेले इथर (ETH) वापरते. तुमचा करार [टेस्टनेटवर](/developers/docs/networks/#ethereum-testnets) उपयोजित करणे म्हणजे कोणीही निधी धोक्यात न घालवता त्याच्याशी संवाद साधू शकतो (उदा., dApp च्या फ्रंटएंडद्वारे). + +मॅन्युअल चाचणीचा हा प्रकार वापरकर्त्याच्या दृष्टिकोनातून तुमच्या ॲप्लिकेशनच्या एंड-टू-एंड प्रवाहाचे मूल्यांकन करण्यासाठी उपयुक्त आहे. येथे, बीटा टेस्टर देखील चाचणी चालवू शकतात आणि कराराच्या व्यावसायिक लॉजिक आणि एकूण कार्यक्षमतेमधील कोणत्याही समस्यांबद्दल अहवाल देऊ शकतात. + +स्थानिक ब्लॉकचेनवर चाचणी केल्यानंतर टेस्टनेटवर उपयोजन करणे आदर्श आहे कारण पहिले Ethereum व्हर्च्युअल मशीनच्या वर्तनाच्या जवळ आहे. म्हणून, अनेक Ethereum-नेटिव्ह प्रकल्पांसाठी वास्तविक-जगातील परिस्थितीनुसार स्मार्ट कराराच्या ऑपरेशनचे मूल्यांकन करण्यासाठी टेस्टनेटवर dApps उपयोजित करणे सामान्य आहे. + +[Ethereum टेस्टनेटबद्दल अधिक.](/developers/docs/development-networks/#public-beacon-testchains) + +## चाचणी विरुद्ध औपचारिक पडताळणी {#testing-vs-formal-verification} + +चाचणी काही डेटा इनपुटसाठी करार अपेक्षित परिणाम परत करतो याची पुष्टी करण्यास मदत करत असली तरी, चाचण्यांदरम्यान न वापरलेल्या इनपुटसाठी तेच निर्णायकपणे सिद्ध करू शकत नाही. म्हणून, स्मार्ट कराराची चाचणी "कार्यात्मक अचूकतेची" हमी देऊ शकत नाही (म्हणजे, ते दाखवू शकत नाही की प्रोग्राम इनपुट मूल्यांच्या _सर्व_ संचांसाठी आवश्यकतेनुसार वागतो). + +औपचारिक पडताळणी ही प्रोग्रामचे औपचारिक मॉडेल औपचारिक तपशीलांशी जुळते की नाही हे तपासून सॉफ्टवेअरच्या अचूकतेचे मूल्यांकन करण्याचा एक दृष्टिकोन आहे. एक औपचारिक मॉडेल हे प्रोग्रामचे एक अमूर्त गणितीय प्रतिनिधित्व आहे, तर एक औपचारिक तपशील प्रोग्रामचे गुणधर्म (म्हणजे, प्रोग्रामच्या अंमलबजावणीबद्दल तार्किक दावे) परिभाषित करते. + +कारण गुणधर्म गणितीय संज्ञांमध्ये लिहिलेले आहेत, त्यामुळे तर्काच्या तार्किक नियमांचा वापर करून प्रणालीचे औपचारिक (गणितीय) मॉडेल तपशील पूर्ण करते हे सत्यापित करणे शक्य होते. म्हणून, औपचारिक पडताळणी साधने प्रणालीच्या अचूकतेचा 'गणितीय पुरावा' तयार करतात असे म्हटले जाते. + +चाचणीच्या विपरीत, औपचारिक पडताळणीचा वापर स्मार्ट कराराची अंमलबजावणी _सर्व_ अंमलबजावणीसाठी औपचारिक तपशील पूर्ण करते हे सत्यापित करण्यासाठी केला जाऊ शकतो (म्हणजे, त्यात कोणतेही बग नाहीत) नमुना डेटासह कार्यान्वित करण्याची आवश्यकता न ठेवता. हे केवळ डझनभर युनिट चाचण्या चालवण्यासाठी लागणारा वेळ कमी करत नाही, तर छुपी असुरक्षितता पकडण्यात देखील अधिक प्रभावी आहे. त्यानुसार, औपचारिक पडताळणी तंत्र त्यांच्या अंमलबजावणीच्या अडचणी आणि उपयुक्ततेनुसार एका स्पेक्ट्रमवर अवलंबून असतात. + +[स्मार्ट करारांसाठी औपचारिक पडताळणीबद्दल अधिक.](/developers/docs/smart-contracts/formal-verification) + +## चाचणी विरुद्ध ऑडिट आणि बग बाउंटीज {#testing-vs-audits-bug-bounties} + +नमूद केल्याप्रमाणे, कठोर चाचणी क्वचितच करारात बग्सच्या अनुपस्थितीची हमी देऊ शकते; औपचारिक पडताळणी दृष्टिकोन अचूकतेची अधिक मजबूत हमी देऊ शकतात परंतु सध्या वापरण्यास कठीण आहेत आणि त्यावर मोठा खर्च येतो. + +तरीही, तुम्ही स्वतंत्र कोड पुनरावलोकन मिळवून करार असुरक्षितता पकडण्याची शक्यता आणखी वाढवू शकता. [स्मार्ट करार ऑडिट](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) आणि [बग बाउंटीज](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) हे तुमच्या करारांचे विश्लेषण करण्यासाठी इतरांना मिळवण्याचे दोन मार्ग आहेत. + +स्मार्ट करारांमध्ये सुरक्षा त्रुटी आणि खराब विकास पद्धतींची प्रकरणे शोधण्यात अनुभवी ऑडिटर्सद्वारे ऑडिट केले जाते. एका ऑडिटमध्ये सामान्यतः चाचणी (आणि शक्यतो औपचारिक पडताळणी) तसेच संपूर्ण कोडबेसचे मॅन्युअल पुनरावलोकन समाविष्ट असते. + +याउलट, बग बाउंटी प्रोग्राममध्ये सामान्यतः एखाद्या व्यक्तीला (सामान्यतः [व्हाइटहॅट हॅकर्स](https://en.wikipedia.org/wiki/White_hat_\(computer_security\)) म्हणून वर्णन केलेले) आर्थिक बक्षीस देणे समाविष्ट असते जो स्मार्ट करारात असुरक्षितता शोधतो आणि डेव्हलपर्सना ती उघड करतो. बग बाउंटी ऑडिटसारखेच आहेत कारण त्यात स्मार्ट करारांमधील दोष शोधण्यात मदत करण्यासाठी इतरांना विचारणे समाविष्ट आहे. + +मुख्य फरक असा आहे की बग बाउंटी प्रोग्राम व्यापक डेव्हलपर/हॅकर समुदायासाठी खुले आहेत आणि अद्वितीय कौशल्ये आणि अनुभव असलेल्या नैतिक हॅकर्स आणि स्वतंत्र सुरक्षा व्यावसायिकांच्या विस्तृत वर्गाला आकर्षित करतात. स्मार्ट करार ऑडिटपेक्षा हा एक फायदा असू शकतो जे मुख्यत्वे मर्यादित किंवा संकुचित कौशल्य असलेल्या संघांवर अवलंबून असतात. + +## चाचणी साधने आणि लायब्ररी {#testing-tools-and-libraries} + +### युनिट चाचणी साधने {#unit-testing-tools} + +- **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** - _Solidity मध्ये लिहिलेल्या स्मार्ट करारांसाठी कोड कव्हरेज साधन._ + +- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** - _प्रगत स्मार्ट करार विकास आणि चाचणीसाठी फ्रेमवर्क (ethers.js वर आधारित)_. + +- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _Solidity स्मार्ट करारांची चाचणी करण्यासाठी साधन. Remix IDE "Solidity Unit Testing" प्लगइनच्या खाली कार्य करते जे करारासाठी चाचणी प्रकरणे लिहिण्यासाठी आणि चालवण्यासाठी वापरले जाते._ + +- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _Ethereum स्मार्ट करार चाचणीसाठी Assertion लायब्ररी. तुमचे करार अपेक्षेप्रमाणे वागतात याची खात्री करा!_ + +- **[Brownie युनिट टेस्टिंग फ्रेमवर्क](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _Brownie Pytest चा वापर करते, एक वैशिष्ट्य-समृद्ध चाचणी फ्रेमवर्क जे तुम्हाला कमीतकमी कोडसह लहान चाचण्या लिहू देते, मोठ्या प्रकल्पांसाठी चांगले स्केल करते आणि अत्यंत विस्तारणीय आहे._ + +- **[Foundry Tests](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** - _Foundry Forge देते, एक जलद आणि लवचिक Ethereum चाचणी फ्रेमवर्क जे साध्या युनिट चाचण्या, गॅस ऑप्टिमायझेशन तपासणी आणि करार फझिंग कार्यान्वित करण्यास सक्षम आहे._ + +- **[Hardhat Tests](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _ethers.js, Mocha, आणि Chai वर आधारित स्मार्ट करारांच्या चाचणीसाठी फ्रेमवर्क._ + +- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _Ethereum व्हर्च्युअल मशीनला लक्ष्य करणाऱ्या स्मार्ट करारांसाठी Python-आधारित विकास आणि चाचणी फ्रेमवर्क._ + +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _युनिट टेस्टिंग आणि फझिंगसाठी Python-आधारित फ्रेमवर्क ज्यामध्ये मजबूत डीबगिंग क्षमता आणि क्रॉस-चेन टेस्टिंग सपोर्ट आहे, सर्वोत्तम वापरकर्ता अनुभव आणि कार्यक्षमतेसाठी pytest आणि Anvil चा वापर करते._ + +### गुणधर्म-आधारित चाचणी साधने {#property-based-testing-tools} + +#### स्थिर विश्लेषण साधने {#static-analysis-tools} + +- **[Slither](https://github.com/crytic/slither)** - _असुरक्षितता शोधण्यासाठी, कोड आकलन वाढवण्यासाठी आणि स्मार्ट करारांसाठी सानुकूल विश्लेषण लिहिण्यासाठी Python-आधारित Solidity स्थिर विश्लेषण फ्रेमवर्क._ + +- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _Solidity स्मार्ट करार प्रोग्रामिंग भाषेसाठी शैली आणि सुरक्षा सर्वोत्तम पद्धती लागू करण्यासाठी लिंटर._ + +- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** - _Web3 स्मार्ट करार सुरक्षा आणि विकासासाठी विशेषतः डिझाइन केलेले Rust-आधारित स्थिर विश्लेषक._ + +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _असुरक्षितता आणि कोड गुणवत्ता डिटेक्टरसह Python-आधारित स्थिर विश्लेषण फ्रेमवर्क, कोडमधून उपयुक्त माहिती काढण्यासाठी प्रिंटर आणि सानुकूल सबमॉड्यूल लिहिण्यासाठी समर्थन._ + +- **[Slippy](https://github.com/fvictorio/slippy)** - _Solidity साठी एक साधा आणि शक्तिशाली लिंटर._ + +#### डायनॅमिक विश्लेषण साधने {#dynamic-analysis-tools} + +- **[Echidna](https://github.com/crytic/echidna/)** - _गुणधर्म-आधारित चाचणीद्वारे स्मार्ट करारांमधील असुरक्षितता शोधण्यासाठी जलद करार फझर._ + +- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _स्मार्ट करार कोडमधील गुणधर्म उल्लंघन शोधण्यासाठी उपयुक्त स्वयंचलित फझिंग साधन._ + +- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** - _EVM बाइटकोडचे विश्लेषण करण्यासाठी डायनॅमिक प्रतिकात्मक अंमलबजावणी फ्रेमवर्क._ + +- **[Mythril](https://github.com/ConsenSys/mythril-classic)** - _टेंट विश्लेषण, कॉन्कोलिक विश्लेषण आणि नियंत्रण प्रवाह तपासणी वापरून करार असुरक्षितता शोधण्यासाठी EVM बाइटकोड मूल्यांकन साधन._ + +- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _Scribble ही एक स्पेसिफिकेशन भाषा आणि रनटाइम पडताळणी साधन आहे जे तुम्हाला स्मार्ट करारांना गुणधर्मांसह भाष्य करण्याची परवानगी देते जे तुम्हाला Diligence Fuzzing किंवा MythX सारख्या साधनांसह करारांची स्वयंचलितपणे चाचणी करण्याची परवानगी देते._ + +## संबंधित ट्युटोरियल्स {#related-tutorials} + +- [विविध चाचणी उत्पादनांचे विहंगावलोकन आणि तुलना](/developers/tutorials/guide-to-smart-contract-security-tools/) \_ +- [स्मार्ट करारांची चाचणी करण्यासाठी Echidna कसे वापरावे](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) +- [स्मार्ट कॉन्ट्रॅक्ट बग शोधण्यासाठी मँटिकोरचा वापर कसा करावा](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) +- [स्मार्ट कॉन्ट्रॅक्ट बग शोधण्यासाठी स्लिथरचा वापर कसा करावा](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) +- [चाचणीसाठी Solidity करारांना कसे मॉक करावे](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/) +- [Foundry वापरून Solidity मध्ये युनिट चाचण्या कशा चालवाव्यात](https://www.rareskills.io/post/foundry-testing-solidity) + +## पुढील वाचन {#further-reading} + +- [Ethereum स्मार्ट करारांच्या चाचणीसाठी सखोल मार्गदर्शक](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297) +- [Ethereum स्मार्ट करारांची चाचणी कशी करावी](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d) +- [डेव्हलपर्ससाठी MolochDAO चे युनिट टेस्टिंग मार्गदर्शक](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide) +- [रॉकस्टारप्रमाणे स्मार्ट करारांची चाचणी कशी करावी](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001) diff --git a/public/content/translations/mr/developers/docs/smart-contracts/upgrading/index.md b/public/content/translations/mr/developers/docs/smart-contracts/upgrading/index.md new file mode 100644 index 00000000000..792851274ae --- /dev/null +++ b/public/content/translations/mr/developers/docs/smart-contracts/upgrading/index.md @@ -0,0 +1,165 @@ +--- +title: "स्मार्ट कॉन्ट्रॅक्ट अपग्रेड करणे" +description: "इथेरियम स्मार्ट कॉन्ट्रॅक्टसाठी अपग्रेड पॅटर्नचा आढावा" +lang: mr +--- + +इथेरियमवरील स्मार्ट कॉन्ट्रॅक्ट हे स्व-कार्यकारी प्रोग्राम आहेत जे इथेरियम व्हर्च्युअल मशीन (EVM) मध्ये चालतात. हे प्रोग्राम डिझाइननुसार अपरिवर्तनीय आहेत, जे एकदा कॉन्ट्रॅक्ट तैनात झाल्यावर व्यवसायाच्या तर्कामध्ये कोणतेही बदल करण्यास प्रतिबंध करते. + +स्मार्ट कॉन्ट्रॅक्ट्सच्या विश्वासहीनता, विकेंद्रीकरण आणि सुरक्षिततेसाठी अपरिवर्तनीयता आवश्यक असली तरी, काही विशिष्ट प्रकरणांमध्ये तो एक तोटा असू शकतो. उदाहरणार्थ, अपरिवर्तनीय कोडमुळे डेव्हलपर्सना असुरक्षित कॉन्ट्रॅक्ट्स दुरुस्त करणे अशक्य होऊ शकते. + +तथापि, स्मार्ट कॉन्ट्रॅक्ट सुधारण्यावरील वाढलेल्या संशोधनामुळे अनेक अपग्रेड पॅटर्नची ओळख झाली आहे. हे अपग्रेड पॅटर्न डेव्हलपर्सना वेगवेगळ्या कॉन्ट्रॅक्टमध्ये व्यवसायाचे तर्क ठेवून स्मार्ट कॉन्ट्रॅक्ट अपग्रेड करण्यास सक्षम करतात (अपरिवर्तनीयता जपताना). + +## पूर्वतयारी {#prerequisites} + +तुम्हाला [स्मार्ट कॉन्ट्रॅक्ट](/developers/docs/smart-contracts/), [स्मार्ट कॉन्ट्रॅक्ट रचना](/developers/docs/smart-contracts/anatomy/), आणि [इथेरियम व्हर्च्युअल मशीन (EVM)](/developers/docs/evm/) यांची चांगली समज असायला हवी. हे मार्गदर्शक असेही गृहीत धरते की वाचकांना स्मार्ट कॉन्ट्रॅक्ट प्रोग्रामिंगची माहिती आहे. + +## स्मार्ट कॉन्ट्रॅक्ट अपग्रेड म्हणजे काय? {#what-is-a-smart-contract-upgrade} + +स्मार्ट कॉन्ट्रॅक्ट अपग्रेडमध्ये कॉन्ट्रॅक्टची स्थिती जतन करताना स्मार्ट कॉन्ट्रॅक्टच्या व्यवसायाच्या तर्कामध्ये बदल करणे समाविष्ट असते. हे स्पष्ट करणे महत्त्वाचे आहे की, विशेषतः स्मार्ट कॉन्ट्रॅक्टच्या संदर्भात, अपग्रेडिबिलिटी आणि म्युटेबिलिटी या एकच नाहीत. + +तुम्ही इथेरियम नेटवर्कवरील पत्त्यावर तैनात केलेला प्रोग्राम अजूनही बदलू शकत नाही. परंतु वापरकर्ते स्मार्ट कॉन्ट्रॅक्टशी संवाद साधताना कार्यान्वित होणारा कोड तुम्ही बदलू शकता. + +हे खालील पद्धतींद्वारे केले जाऊ शकते: + +1. स्मार्ट कॉन्ट्रॅक्टच्या अनेक आवृत्त्या तयार करणे आणि जुन्या कॉन्ट्रॅक्टमधून नवीन कॉन्ट्रॅक्ट इंस्टन्सवर स्थिती (म्हणजे डेटा) स्थलांतरित करणे. + +2. व्यवसाय तर्क आणि स्थिती साठवण्यासाठी स्वतंत्र कॉन्ट्रॅक्ट तयार करणे. + +3. अपरिवर्तनीय प्रॉक्सी कॉन्ट्रॅक्टमधून बदलण्यायोग्य तर्क कॉन्ट्रॅक्टकडे फंक्शन कॉल सोपवण्यासाठी प्रॉक्सी पॅटर्न वापरणे. + +4. विशिष्ट फंक्शन्स कार्यान्वित करण्यासाठी लवचिक सॅटेलाइट कॉन्ट्रॅक्ट्सशी इंटरफेस करणारा आणि त्यावर अवलंबून असणारा एक अपरिवर्तनीय मुख्य कॉन्ट्रॅक्ट तयार करणे. + +5. प्रॉक्सी कॉन्ट्रॅक्टमधून लॉजिक कॉन्ट्रॅक्ट्सकडे फंक्शन कॉल सोपवण्यासाठी डायमंड पॅटर्न वापरणे. + +### अपग्रेड यंत्रणा #1: कॉन्ट्रॅक्ट स्थलांतर {#contract-migration} + +कॉन्ट्रॅक्ट स्थलांतर हे आवृत्तीकरणावर आधारित आहे—म्हणजेच, एकाच सॉफ्टवेअरच्या अद्वितीय स्थिती तयार करणे आणि व्यवस्थापित करण्याची कल्पना. कॉन्ट्रॅक्ट स्थलांतरामध्ये अस्तित्वात असलेल्या स्मार्ट कॉन्ट्रॅक्टचा नवीन इन्स्टन्स तैनात करणे आणि नवीन कॉन्ट्रॅक्टमध्ये स्टोरेज आणि शिल्लक हस्तांतरित करणे यांचा समावेश असतो. + +नव्याने तैनात केलेल्या कॉन्ट्रॅक्टमध्ये रिकामा स्टोरेज असेल, ज्यामुळे तुम्हाला जुन्या कॉन्ट्रॅक्टमधून डेटा परत मिळवता येईल आणि तो नवीन अंमलबजावणीमध्ये लिहिता येईल. त्यानंतर, तुम्हाला जुन्या कॉन्ट्रॅक्टशी संवाद साधलेल्या सर्व कॉन्ट्रॅक्टना नवीन पत्ता दर्शवण्यासाठी अपडेट करावे लागेल. + +कॉन्ट्रॅक्ट स्थलांतरातील शेवटची पायरी म्हणजे वापरकर्त्यांना नवीन कॉन्ट्रॅक्ट वापरण्यासाठी प्रवृत्त करणे. नवीन कॉन्ट्रॅक्ट आवृत्ती वापरकर्त्याची शिल्लक आणि पत्ते कायम ठेवेल, ज्यामुळे अपरिवर्तनीयता जपली जाते. जर तो टोकन-आधारित कॉन्ट्रॅक्ट असेल, तर तुम्हाला जुना कॉन्ट्रॅक्ट रद्द करून नवीन कॉन्ट्रॅक्ट वापरण्यासाठी एक्सचेंजेसशी संपर्क साधावा लागेल. + +वापरकर्त्यांच्या संवादात व्यत्यय न आणता स्मार्ट कॉन्ट्रॅक्ट अपग्रेड करण्यासाठी कॉन्ट्रॅक्ट स्थलांतर ही एक तुलनेने सोपी आणि सुरक्षित उपाययोजना आहे. तथापि, वापरकर्ता स्टोरेज आणि शिल्लक नवीन कॉन्ट्रॅक्टमध्ये मॅन्युअली स्थलांतरित करणे वेळखाऊ आहे आणि त्यात जास्त गॅस खर्च येऊ शकतो. + +[कॉन्ट्रॅक्ट स्थलांतरावर अधिक.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) + +### अपग्रेड यंत्रणा #2: डेटा विभाजन {#data-separation} + +स्मार्ट कॉन्ट्रॅक्ट अपग्रेड करण्याची दुसरी पद्धत म्हणजे व्यवसाय तर्क आणि डेटा स्टोरेज स्वतंत्र कॉन्ट्रॅक्टमध्ये वेगळे करणे. याचा अर्थ वापरकर्ते लॉजिक कॉन्ट्रॅक्टशी संवाद साधतात, तर डेटा स्टोरेज कॉन्ट्रॅक्टमध्ये संग्रहित केला जातो. + +लॉजिक कॉन्ट्रॅक्टमध्ये तो कोड असतो जो वापरकर्ते ऍप्लिकेशनशी संवाद साधताना कार्यान्वित होतो. त्यात स्टोरेज कॉन्ट्रॅक्टचा पत्ता देखील असतो आणि डेटा मिळवण्यासाठी आणि सेट करण्यासाठी त्याच्याशी संवाद साधतो. + +दरम्यान, स्टोरेज कॉन्ट्रॅक्टमध्ये स्मार्ट कॉन्ट्रॅक्टशी संबंधित स्थिती असते, जसे की वापरकर्त्याची शिल्लक आणि पत्ते. लक्षात घ्या की स्टोरेज कॉन्ट्रॅक्ट लॉजिक कॉन्ट्रॅक्टच्या मालकीचा असतो आणि तैनात करताना नंतरच्या पत्त्यासह कॉन्फिगर केलेला असतो. हे अनधिकृत कॉन्ट्रॅक्टना स्टोरेज कॉन्ट्रॅक्टला कॉल करण्यापासून किंवा त्याचा डेटा अपडेट करण्यापासून प्रतिबंधित करते. + +डीफॉल्टनुसार, स्टोरेज कॉन्ट्रॅक्ट अपरिवर्तनीय असतो—परंतु तुम्ही ज्या लॉजिक कॉन्ट्रॅक्टकडे ते निर्देश करते त्याला नवीन अंमलबजावणीसह बदलू शकता. यामुळे EVM मध्ये चालणारा कोड बदलेल, आणि स्टोरेज व शिल्लक अबाधित राहील. + +ही अपग्रेड पद्धत वापरण्यासाठी स्टोरेज कॉन्ट्रॅक्टमधील लॉजिक कॉन्ट्रॅक्टचा पत्ता अपडेट करणे आवश्यक आहे. तुम्ही नवीन लॉजिक कॉन्ट्रॅक्टला स्टोरेज कॉन्ट्रॅक्टच्या पत्त्यासह कॉन्फिगर करणे आवश्यक आहे, ज्याची कारणे पूर्वी स्पष्ट केली आहेत. + +कॉन्ट्रॅक्ट स्थलांतराच्या तुलनेत डेटा विभाजन पॅटर्न अंमलात आणणे अधिक सोपे आहे. तथापि, तुम्हाला अनेक कॉन्ट्रॅक्ट्स व्यवस्थापित करावे लागतील आणि स्मार्ट कॉन्ट्रॅक्ट्सना दुर्भावनापूर्ण अपग्रेड्सपासून वाचवण्यासाठी गुंतागुंतीच्या अधिकृतता योजना लागू कराव्या लागतील. + +### अपग्रेड यंत्रणा #3: प्रॉक्सी पॅटर्न {#proxy-patterns} + +प्रॉक्सी पॅटर्न देखील व्यवसाय तर्क आणि डेटा स्वतंत्र कॉन्ट्रॅक्टमध्ये ठेवण्यासाठी डेटा विभाजनाचा वापर करतो. तथापि, प्रॉक्सी पॅटर्नमध्ये, स्टोरेज कॉन्ट्रॅक्ट (ज्याला प्रॉक्सी म्हणतात) कोड अंमलबजावणी दरम्यान लॉजिक कॉन्ट्रॅक्टला कॉल करतो. ही डेटा विभाजन पद्धतीच्या उलट आहे, जिथे लॉजिक कॉन्ट्रॅक्ट स्टोरेज कॉन्ट्रॅक्टला कॉल करतो. + +प्रॉक्सी पॅटर्नमध्ये हे घडते: + +1. वापरकर्ते प्रॉक्सी कॉन्ट्रॅक्टशी संवाद साधतात, जो डेटा संग्रहित करतो, परंतु व्यवसायाचा तर्क ठेवत नाही. + +2. प्रॉक्सी कॉन्ट्रॅक्ट लॉजिक कॉन्ट्रॅक्टचा पत्ता संग्रहित करतो आणि `delegatecall` फंक्शन वापरून सर्व फंक्शन कॉल लॉजिक कॉन्ट्रॅक्टकडे (ज्यात व्यवसायाचा तर्क असतो) सोपवतो. + +3. कॉल लॉजिक कॉन्ट्रॅक्टकडे फॉरवर्ड केल्यानंतर, लॉजिक कॉन्ट्रॅक्टमधून परत आलेला डेटा पुनर्प्राप्त केला जातो आणि वापरकर्त्याला परत केला जातो. + +प्रॉक्सी पॅटर्न वापरण्यासाठी **delegatecall** फंक्शनची समज असणे आवश्यक आहे. मूलतः, `delegatecall` एक ऑपकोड आहे जो एका कॉन्ट्रॅक्टला दुसऱ्या कॉन्ट्रॅक्टला कॉल करण्याची परवानगी देतो, तर प्रत्यक्ष कोडची अंमलबजावणी कॉलिंग कॉन्ट्रॅक्टच्या संदर्भात होते. प्रॉक्सी पॅटर्नमध्ये `delegatecall` वापरण्याचा एक परिणाम म्हणजे प्रॉक्सी कॉन्ट्रॅक्ट त्याच्या स्टोरेजमध्ये वाचतो आणि लिहितो आणि लॉजिक कॉन्ट्रॅक्टमध्ये साठवलेला तर्क कार्यान्वित करतो, जसे की तो अंतर्गत फंक्शनला कॉल करत आहे. + +[Solidity माहिती](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries) वरून: + +> _मेसेज कॉलचा एक विशेष प्रकार आहे, ज्याला **delegatecall** म्हणतात, जो मेसेज कॉलसारखाच आहे, याशिवाय की लक्ष्य पत्त्यावरील कोड कॉलिंग कॉन्ट्रॅक्टच्या संदर्भात (म्हणजे, पत्त्यावर) कार्यान्वित होतो आणि `msg.sender` व `msg.value` त्यांची मूल्ये बदलत नाहीत._ _याचा अर्थ असा की एक कॉन्ट्रॅक्ट रनटाइमवेळी वेगळ्या पत्त्यावरून कोड डायनॅमिकली लोड करू शकतो. स्टोरेज, वर्तमान पत्ता आणि शिल्लक अजूनही कॉलिंग कॉन्ट्रॅक्टचा संदर्भ घेतात, फक्त कोड कॉल केलेल्या पत्त्यावरून घेतला जातो._ + +प्रॉक्सी कॉन्ट्रॅक्टला `delegatecall` कसे चालवायचे हे माहित असते, जेव्हा एखादा वापरकर्ता फंक्शनला कॉल करतो, कारण त्यात `fallback` फंक्शन तयार केलेले असते. Solidity प्रोग्रामिंगमध्ये, [फॉलबॅक फंक्शन](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) तेव्हा कार्यान्वित होते जेव्हा फंक्शन कॉल कॉन्ट्रॅक्टमध्ये निर्दिष्ट केलेल्या फंक्शन्सशी जुळत नाही. + +प्रॉक्सी पॅटर्न कार्यरत करण्यासाठी एक कस्टम फॉलबॅक फंक्शन लिहिणे आवश्यक आहे, जे हे निर्दिष्ट करते की प्रॉक्सी कॉन्ट्रॅक्टने समर्थन न करणाऱ्या फंक्शन कॉल्सना कसे हाताळावे. या प्रकरणात, प्रॉक्सीचे फॉलबॅक फंक्शन delegatecall सुरू करण्यासाठी आणि वापरकर्त्याची विनंती सध्याच्या लॉजिक कॉन्ट्रॅक्ट अंमलबजावणीकडे पुन्हा मार्गस्थ करण्यासाठी प्रोग्राम केलेले असते. + +प्रॉक्सी कॉन्ट्रॅक्ट डीफॉल्टनुसार अपरिवर्तनीय असतो, परंतु अपडेटेड व्यवसाय तर्कासह नवीन लॉजिक कॉन्ट्रॅक्ट तयार केले जाऊ शकतात. त्यानंतर अपग्रेड करणे म्हणजे प्रॉक्सी कॉन्ट्रॅक्टमध्ये संदर्भित लॉजिक कॉन्ट्रॅक्टचा पत्ता बदलणे. + +प्रॉक्सी कॉन्ट्रॅक्टला नवीन लॉजिक कॉन्ट्रॅक्टकडे निर्देशित करून, वापरकर्ते प्रॉक्सी कॉन्ट्रॅक्ट फंक्शनला कॉल करतात तेव्हा कार्यान्वित होणारा कोड बदलतो. यामुळे आम्हाला वापरकर्त्यांना नवीन कॉन्ट्रॅक्टशी संवाद साधण्यास न सांगता कॉन्ट्रॅक्टचा तर्क अपग्रेड करता येतो. + +प्रॉक्सी पॅटर्न स्मार्ट कॉन्ट्रॅक्ट अपग्रेड करण्याची एक लोकप्रिय पद्धत आहे कारण ते कॉन्ट्रॅक्ट स्थलांतराशी संबंधित अडचणी दूर करतात. तथापि, प्रॉक्सी पॅटर्न वापरण्यास अधिक गुंतागुंतीचे आहेत आणि जर ते अयोग्यरित्या वापरले गेले तर, [फंक्शन सिलेक्टर क्लॅश](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357) सारखे गंभीर दोष निर्माण करू शकतात. + +[प्रॉक्सी पॅटर्नवर अधिक](https://blog.openzeppelin.com/proxy-patterns/). + +### अपग्रेड यंत्रणा #4: स्ट्रॅटेजी पॅटर्न {#strategy-pattern} + +हे तंत्र [स्ट्रॅटेजी पॅटर्न](https://en.wikipedia.org/wiki/Strategy_pattern) पासून प्रभावित आहे, जे विशिष्ट वैशिष्ट्ये लागू करण्यासाठी इतर प्रोग्राम्सशी इंटरफेस करणारे सॉफ्टवेअर प्रोग्राम तयार करण्यास प्रोत्साहित करते. इथेरियम डेव्हलपमेंटमध्ये स्ट्रॅटेजी पॅटर्न लागू करणे म्हणजे इतर कॉन्ट्रॅक्ट्समधून फंक्शन्स कॉल करणारा स्मार्ट कॉन्ट्रॅक्ट तयार करणे. + +या प्रकरणात मुख्य कॉन्ट्रॅक्टमध्ये मुख्य व्यवसाय तर्क असतो, परंतु तो विशिष्ट फंक्शन्स कार्यान्वित करण्यासाठी इतर स्मार्ट कॉन्ट्रॅक्ट्स ("सॅटेलाइट कॉन्ट्रॅक्ट्स") शी इंटरफेस करतो. हा मुख्य कॉन्ट्रॅक्ट प्रत्येक सॅटेलाइट कॉन्ट्रॅक्टचा पत्ता देखील संग्रहित करतो आणि सॅटेलाइट कॉन्ट्रॅक्टच्या वेगवेगळ्या अंमलबजावणींमध्ये स्विच करू शकतो. + +तुम्ही एक नवीन सॅटेलाइट कॉन्ट्रॅक्ट तयार करू शकता आणि मुख्य कॉन्ट्रॅक्टला नवीन पत्त्यासह कॉन्फिगर करू शकता. यामुळे तुम्हाला स्मार्ट कॉन्ट्रॅक्टसाठी _स्ट्रॅटेजी_ (म्हणजे, नवीन तर्क लागू करणे) बदलता येते. + +आधी चर्चा केलेल्या प्रॉक्सी पॅटर्नसारखे असले तरी, स्ट्रॅटेजी पॅटर्न वेगळा आहे कारण मुख्य कॉन्ट्रॅक्ट, ज्याच्याशी वापरकर्ते संवाद साधतात, त्यात व्यवसायाचा तर्क असतो. हा पॅटर्न वापरल्याने तुम्हाला मुख्य पायाभूत सुविधांवर परिणाम न करता स्मार्ट कॉन्ट्रॅक्टमध्ये मर्यादित बदल करण्याची संधी मिळते. + +मुख्य तोटा असा आहे की हा पॅटर्न मुख्यतः किरकोळ अपग्रेड्ससाठी उपयुक्त आहे. तसेच, जर मुख्य कॉन्ट्रॅक्टमध्ये तडजोड झाली (उदा. हॅकद्वारे), तर तुम्ही ही अपग्रेड पद्धत वापरू शकत नाही. + +### अपग्रेड यंत्रणा #5: डायमंड पॅटर्न {#diamond-pattern} + +डायमंड पॅटर्नला प्रॉक्सी पॅटर्नमधील सुधारणा मानले जाऊ शकते. डायमंड पॅटर्न प्रॉक्सी पॅटर्नपेक्षा वेगळे आहेत कारण डायमंड प्रॉक्सी कॉन्ट्रॅक्ट एकापेक्षा जास्त लॉजिक कॉन्ट्रॅक्टकडे फंक्शन कॉल सोपवू शकतो. + +डायमंड पॅटर्नमधील लॉजिक कॉन्ट्रॅक्ट्स _फेसिट्स_ म्हणून ओळखले जातात. डायमंड पॅटर्न कार्यरत करण्यासाठी, तुम्हाला प्रॉक्सी कॉन्ट्रॅक्टमध्ये एक मॅपिंग तयार करावे लागेल जे [फंक्शन सिलेक्टर्स](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) वेगवेगळ्या फेसिट पत्त्यांवर मॅप करेल. + +जेव्हा वापरकर्ता फंक्शन कॉल करतो, तेव्हा प्रॉक्सी कॉन्ट्रॅक्ट ते फंक्शन कार्यान्वित करण्यासाठी जबाबदार फेसिट शोधण्यासाठी मॅपिंग तपासतो. मग ते `delegatecall` (फॉलबॅक फंक्शन वापरून) चालवते आणि कॉल योग्य लॉजिक कॉन्ट्रॅक्टकडे पुनर्निर्देशित करते. + +डायमंड अपग्रेड पॅटर्नमध्ये पारंपरिक प्रॉक्सी अपग्रेड पॅटर्नपेक्षा काही फायदे आहेत: + +1. हे तुम्हाला संपूर्ण कोड न बदलता कॉन्ट्रॅक्टचा एक छोटासा भाग अपग्रेड करण्याची परवानगी देते. अपग्रेडसाठी प्रॉक्सी पॅटर्न वापरताना, किरकोळ अपग्रेडसाठी सुद्धा, संपूर्णपणे नवीन लॉजिक कॉन्ट्रॅक्ट तयार करणे आवश्यक आहे. + +2. सर्व स्मार्ट कॉन्ट्रॅक्ट्सना (प्रॉक्सी पॅटर्नमध्ये वापरलेल्या लॉजिक कॉन्ट्रॅक्ट्ससह) 24KB आकाराची मर्यादा असते, जी एक मर्यादा असू शकते - विशेषतः अधिक फंक्शन्स आवश्यक असलेल्या गुंतागुंतीच्या कॉन्ट्रॅक्ट्ससाठी. डायमंड पॅटर्न अनेक लॉजिक कॉन्ट्रॅक्ट्समध्ये फंक्शन्स विभाजित करून ही समस्या सोडवणे सोपे करते. + +3. प्रॉक्सी पॅटर्न ऍक्सेस नियंत्रणासाठी कॅच-ऑल दृष्टीकोन स्वीकारतात. अपग्रेड फंक्शन्समध्ये ऍक्सेस असलेली संस्था _संपूर्ण_ कॉन्ट्रॅक्ट बदलू शकते. परंतु डायमंड पॅटर्न एक मॉड्यूलर परवानगी दृष्टीकोन सक्षम करतो, जिथे तुम्ही संस्थांना स्मार्ट कॉन्ट्रॅक्टमधील विशिष्ट फंक्शन्स अपग्रेड करण्यापुरते मर्यादित करू शकता. + +[डायमंड पॅटर्नवर अधिक](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w). + +## स्मार्ट कॉन्ट्रॅक्ट अपग्रेड करण्याचे फायदे आणि तोटे {#pros-and-cons-of-upgrading-smart-contracts} + +| फायदे | बाधक | +| ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| स्मार्ट कॉन्ट्रॅक्ट अपग्रेडमुळे तैनातीनंतरच्या टप्प्यात शोधलेल्या असुरक्षितता दुरुस्त करणे सोपे होते. | स्मार्ट कॉन्ट्रॅक्ट अपग्रेड करणे हे कोड अपरिवर्तनीयतेच्या कल्पनेला नाकारते, ज्याचे विकेंद्रीकरण आणि सुरक्षिततेवर परिणाम होतात. | +| डेव्हलपर्स विकेंद्रित ऍप्लिकेशन्समध्ये नवीन वैशिष्ट्ये जोडण्यासाठी लॉजिक अपग्रेड्स वापरू शकतात. | वापरकर्त्यांनी डेव्हलपर्सवर विश्वास ठेवला पाहिजे की ते स्मार्ट कॉन्ट्रॅक्टमध्ये अनियंत्रितपणे बदल करणार नाहीत. | +| स्मार्ट कॉन्ट्रॅक्ट अपग्रेड्स अंतिम वापरकर्त्यांसाठी सुरक्षितता सुधारू शकतात कारण बग्स लवकर दुरुस्त केले जाऊ शकतात. | स्मार्ट कॉन्ट्रॅक्टमध्ये अपग्रेड कार्यक्षमता प्रोग्रामिंग केल्याने गुंतागुंतीचा आणखी एक स्तर वाढतो आणि गंभीर दोषांची शक्यता वाढते. | +| कॉन्ट्रॅक्ट अपग्रेड डेव्हलपर्सना वेगवेगळ्या वैशिष्ट्यांसह प्रयोग करण्यासाठी आणि कालांतराने dapps सुधारण्यासाठी अधिक संधी देतात. | स्मार्ट कॉन्ट्रॅक्ट अपग्रेड करण्याची संधी डेव्हलपर्सना विकासाच्या टप्प्यात योग्य काळजी न घेता प्रकल्प लवकर सुरू करण्यास प्रोत्साहित करू शकते. | +| | स्मार्ट कॉन्ट्रॅक्टमधील असुरक्षित ऍक्सेस नियंत्रण किंवा केंद्रीकरणामुळे दुर्भावनापूर्ण व्यक्तींना अनधिकृत अपग्रेड करणे सोपे होऊ शकते. | + +## स्मार्ट कॉन्ट्रॅक्ट अपग्रेड करण्यासाठी विचार करण्याच्या गोष्टी {#considerations-for-upgrading-smart-contracts} + +1. अनधिकृत स्मार्ट कॉन्ट्रॅक्ट अपग्रेड्सना प्रतिबंध करण्यासाठी सुरक्षित ऍक्सेस नियंत्रण/अधिकृतता यंत्रणा वापरा, विशेषतः प्रॉक्सी पॅटर्न, स्ट्रॅटेजी पॅटर्न किंवा डेटा विभाजन वापरत असल्यास. एक उदाहरण म्हणजे अपग्रेड फंक्शनमध्ये प्रवेश मर्यादित करणे, जेणेकरून केवळ कॉन्ट्रॅक्टचा मालकच ते कॉल करू शकेल. + +2. स्मार्ट कॉन्ट्रॅक्ट अपग्रेड करणे ही एक गुंतागुंतीची क्रिया आहे आणि असुरक्षितता टाळण्यासाठी उच्च पातळीवरील काळजी घेणे आवश्यक आहे. + +3. अपग्रेड लागू करण्याची प्रक्रिया विकेंद्रित करून विश्वासाची गृहितके कमी करा. संभाव्य धोरणांमध्ये अपग्रेड नियंत्रित करण्यासाठी [मल्टी-सिग वॉलेट कॉन्ट्रॅक्ट](/developers/docs/smart-contracts/#multisig) वापरणे, किंवा अपग्रेड मंजूर करण्यासाठी [DAO चे सदस्य](/dao/) यांना मतदान करणे आवश्यक करणे यांचा समावेश आहे. + +4. कॉन्ट्रॅक्ट अपग्रेड करण्यामध्ये समाविष्ट असलेल्या खर्चाबद्दल जागरूक रहा. उदाहरणार्थ, कॉन्ट्रॅक्ट स्थलांतरादरम्यान जुन्या कॉन्ट्रॅक्टमधून नवीन कॉन्ट्रॅक्टमध्ये स्थिती (उदा. वापरकर्त्याची शिल्लक) कॉपी करण्यासाठी एकापेक्षा जास्त व्यवहारांची आवश्यकता असू शकते, म्हणजे अधिक गॅस शुल्क. + +5. वापरकर्त्यांचे संरक्षण करण्यासाठी **टाइमलॉक** लागू करण्याचा विचार करा. टाइमलॉक म्हणजे सिस्टममधील बदलांवर लागू होणारा विलंब. अपग्रेड नियंत्रित करण्यासाठी टाइमलॉक मल्टी-सिग गव्हर्नन्स प्रणालीसह एकत्र केले जाऊ शकतात: जर प्रस्तावित कृती आवश्यक मान्यता मर्यादेपर्यंत पोहोचली, तर ती पूर्वनिर्धारित विलंब कालावधी संपेपर्यंत कार्यान्वित होत नाही. + +जर वापरकर्ते प्रस्तावित बदलाशी (उदा. लॉजिक अपग्रेड किंवा नवीन शुल्क योजना) असहमत असतील तर टाइमलॉक त्यांना सिस्टममधून बाहेर पडण्यासाठी थोडा वेळ देतात. टाइमलॉकशिवाय, वापरकर्त्यांना डेव्हलपर्सवर विश्वास ठेवावा लागतो की ते पूर्वसूचना न देता स्मार्ट कॉन्ट्रॅक्टमध्ये अनियंत्रित बदल करणार नाहीत. येथे तोटा असा आहे की टाइमलॉक असुरक्षितता त्वरीत पॅच करण्याची क्षमता प्रतिबंधित करतात. + +## संसाधने {#resources} + +**OpenZeppelin अपग्रेड्स प्लगइन - _अपग्रेड करण्यायोग्य स्मार्ट कॉन्ट्रॅक्ट्स तैनात आणि सुरक्षित करण्यासाठी साधनांचा संच._** + +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-upgrades) +- [माहिती](https://docs.openzeppelin.com/upgrades) + +## ट्यूटोरियल्स {#tutorials} + +- [तुमचे स्मार्ट कॉन्ट्रॅक्ट्स अपग्रेड करणे | YouTube ट्युटोरियल](https://www.youtube.com/watch?v=bdXJmWajZRY) पॅट्रिक कॉलिन्स द्वारे +- [इथेरियम स्मार्ट कॉन्ट्रॅक्ट मायग्रेशन ट्युटोरियल](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) ऑस्टिन ग्रिफिथ द्वारे +- [स्मार्ट कॉन्ट्रॅक्ट अपग्रेड करण्यासाठी UUPS प्रॉक्सी पॅटर्न वापरणे](https://blog.logrocket.com/author/praneshas/) प्रणेश ए. एस. द्वारे +- [Web3 ट्युटोरियल: OpenZeppelin वापरून अपग्रेड करण्यायोग्य स्मार्ट कॉन्ट्रॅक्ट (प्रॉक्सी) लिहा](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) फॅंगजुन.ईथ द्वारे + +## पुढील वाचन {#further-reading} + +- [स्मार्ट कॉन्ट्रॅक्ट अपग्रेडची स्थिती](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) सँटियागो पॅलाडिनो द्वारे +- [सॉलिडिटी स्मार्ट कॉन्ट्रॅक्ट अपग्रेड करण्याचे अनेक मार्ग](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - क्रिप्टो मार्केट पूल ब्लॉग +- [शिका: स्मार्ट कॉन्ट्रॅक्ट अपग्रेड करणे](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - OpenZeppelin Docs +- [सॉलिडिटी कॉन्ट्रॅक्ट्सच्या अपग्रेडिबिलिटीसाठी प्रॉक्सी पॅटर्न: पारदर्शक विरुद्ध UUPS प्रॉक्सी](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) नवीन साहू द्वारे +- [डायमंड अपग्रेड्स कसे काम करतात](https://dev.to/mudgen/how-diamond-upgrades-work-417j) निक मज द्वारे diff --git a/public/content/translations/mr/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/mr/developers/docs/smart-contracts/verifying/index.md new file mode 100644 index 00000000000..994a21eaa69 --- /dev/null +++ b/public/content/translations/mr/developers/docs/smart-contracts/verifying/index.md @@ -0,0 +1,113 @@ +--- +title: "हुशार करारांची पडताळणी" +description: "Ethereum हुशार करारांसाठी सोर्स कोड पडताळणीचे एक अवलोकन" +lang: mr +--- + +[हुशार करार](/developers/docs/smart-contracts/) “विश्वासहीन” (trustless) असण्यासाठी डिझाइन केलेले आहेत, याचा अर्थ वापरकर्त्यांनी कराराशी संवाद साधण्यापूर्वी तृतीय पक्षांवर (उदा. डेव्हलपर्स आणि कंपन्या) विश्वास ठेवण्याची गरज नाही. विश्वासहीनतेसाठी एक आवश्यक अट म्हणून, वापरकर्ते आणि इतर डेव्हलपर्सना हुशार कराराच्या सोर्स कोडची पडताळणी करता आली पाहिजे. सोर्स कोड पडताळणी वापरकर्त्यांना आणि डेव्हलपर्सना आश्वासन देते की प्रकाशित केलेला करार कोड Ethereum ब्लॉकचेनवरील करार पत्त्यावर चालणाऱ्या कोडसारखाच आहे. + +"सोर्स कोड पडताळणी" आणि "[औपचारिक पडताळणी](/developers/docs/smart-contracts/formal-verification/)" यातील फरक ओळखणे महत्त्वाचे आहे. सोर्स कोड पडताळणी, ज्याचे खाली तपशीलवार स्पष्टीकरण दिले जाईल, म्हणजे उच्च-स्तरीय भाषेत (उदा. Solidity) हुशार कराराचा दिलेला सोर्स कोड करार पत्त्यावर कार्यान्वित होण्यासाठी त्याच बाईटकोडमध्ये संकलित होतो की नाही हे तपासणे. तथापि, औपचारिक पडताळणी हुशार कराराच्या अचूकतेची पडताळणी करण्याचे वर्णन करते, याचा अर्थ करार अपेक्षेप्रमाणे वागतो. संदर्भ-अवलंबित असले तरी, करार पडताळणी सामान्यतः सोर्स कोड पडताळणीला संदर्भित करते. + +## सोर्स कोड पडताळणी म्हणजे काय? {#what-is-source-code-verification} + +[Ethereum व्हर्च्युअल मशीन (EVM)](/developers/docs/evm/) मध्ये हुशार करार तैनात करण्यापूर्वी, डेव्हलपर्स कराराचा सोर्स कोड—[Solidity मध्ये लिहिलेल्या](/developers/docs/smart-contracts/languages/) सूचना किंवा दुसरी उच्च-स्तरीय प्रोग्रामिंग भाषा—बाईटकोडमध्ये [संकलित](/developers/docs/smart-contracts/compiling/) करतात. EVM उच्च-स्तरीय सूचनांचा अर्थ लावू शकत नसल्यामुळे, EVM मध्ये कराराचे तर्कशास्त्र कार्यान्वित करण्यासाठी सोर्स कोडला बाईटकोडमध्ये (म्हणजे, निम्न-स्तरीय, मशीन सूचना) संकलित करणे आवश्यक आहे. + +सोर्स कोड पडताळणी म्हणजे कोणताही फरक शोधण्यासाठी हुशार कराराचा सोर्स कोड आणि करार तयार करताना वापरलेल्या संकलित बाईटकोडची तुलना करणे. हुशार करारांची पडताळणी करणे महत्त्वाचे आहे कारण जाहिरात केलेला करार कोड ब्लॉकचेनवर चालणाऱ्या कोडपेक्षा वेगळा असू शकतो. + +हुशार कराराची पडताळणी मशीन कोड वाचल्याशिवाय, करार ज्या उच्च-स्तरीय भाषेत लिहिलेला आहे त्याद्वारे तो काय करतो याचा तपास करण्यास सक्षम करते. संकलित आणि तैनात केलेल्या मूळ सोर्स कोडसह फंक्शन्स, व्हॅल्यूज आणि सामान्यतः व्हेरिएबलची नावे आणि टिप्पण्या समान राहतात. यामुळे कोड वाचणे खूप सोपे होते. सोर्स पडताळणी कोड दस्तऐवजीकरणासाठी देखील तरतूद करते, जेणेकरून अंतिम वापरकर्त्यांना कळेल की हुशार करार काय करण्यासाठी डिझाइन केला आहे. + +### पूर्ण पडताळणी म्हणजे काय? {#full-verification} + +सोर्स कोडचे काही भाग असे आहेत जे संकलित बाईटकोडवर परिणाम करत नाहीत जसे की टिप्पण्या किंवा व्हेरिएबलची नावे. याचा अर्थ असा की भिन्न व्हेरिएबल नावे आणि भिन्न टिप्पण्या असलेले दोन सोर्स कोड एकाच कराराची पडताळणी करण्यास सक्षम असतील. त्यामुळे, एक दुर्भावनापूर्ण अभिनेता फसव्या टिप्पण्या जोडू शकतो किंवा सोर्स कोडमध्ये दिशाभूल करणारी व्हेरिएबल नावे देऊ शकतो आणि मूळ सोर्स कोडपेक्षा वेगळ्या सोर्स कोडसह कराराची पडताळणी करून घेऊ शकतो. + +सोर्स कोडच्या अचूकतेसाठी _क्रिप्टोग्राफिक हमी_ म्हणून आणि संकलन माहितीचा _फिंगरप्रिंट_ म्हणून काम करण्यासाठी बाईटकोडमध्ये अतिरिक्त डेटा जोडून हे टाळणे शक्य आहे. आवश्यक माहिती [Solidity च्या करार मेटाडेटामध्ये](https://docs.soliditylang.org/en/v0.8.15/metadata.html) आढळते आणि या फाइलचा हॅश कराराच्या बाईटकोडमध्ये जोडला जातो. तुम्ही ते [मेटाडेटा प्लेग्राउंड](https://playground.sourcify.dev) मध्ये कार्यरत पाहू शकता + +मेटाडेटा फाइलमध्ये स्त्रोत फाइल्स आणि त्यांचे हॅशसह कराराच्या संकलनाविषयी माहिती असते. म्हणजेच, जर कोणतीही संकलन सेटिंग्ज किंवा स्त्रोत फाइल्सपैकी एकामधील एक बाइट जरी बदलला, तरी मेटाडेटा फाइल बदलते. परिणामी मेटाडेटा फाइलचा हॅश, जो बाईटकोडमध्ये जोडला जातो, तो देखील बदलतो. याचा अर्थ असा की जर एखाद्या कराराचा बाईटकोड + जोडलेला मेटाडेटा हॅश दिलेला सोर्स कोड आणि संकलन सेटिंग्जशी जुळत असेल, तर आपण खात्री बाळगू शकतो की हा तोच सोर्स कोड आहे जो मूळ संकलनामध्ये वापरला गेला होता, एकही बाइट वेगळा नाही. + +मेटाडेटा हॅशचा फायदा घेणार्‍या या प्रकारच्या पडताळणीला **"[पूर्ण पडताळणी](https://docs.sourcify.dev/docs/full-vs-partial-match/)"** (तसेच "परिपूर्ण पडताळणी") म्हणून संबोधले जाते. जर मेटाडेटा हॅश जुळत नसतील किंवा पडताळणीमध्ये विचारात घेतले जात नसतील तर तो एक "आंशिक जुळणी" असेल, जो सध्या करार पडताळण्याचा अधिक सामान्य मार्ग आहे. पूर्ण पडताळणीशिवाय [दुर्भावनापूर्ण कोड घालणे](https://samczsun.com/hiding-in-plain-sight/) शक्य आहे जो सत्यापित सोर्स कोडमध्ये दिसणार नाही. बहुतेक डेव्हलपर्सना पूर्ण पडताळणीबद्दल माहिती नसते आणि ते त्यांच्या संकलनाची मेटाडेटा फाइल ठेवत नाहीत, त्यामुळे आतापर्यंत करार पडताळण्यासाठी आंशिक पडताळणी ही वास्तविक पद्धत आहे. + +## सोर्स कोड पडताळणी का महत्त्वाची आहे? {#importance-of-source-code-verification} + +### विश्वासहीनता {#trustlessness} + +विश्वासहीनता हा हुशार करार आणि [विकेंद्रित ॲप्लिकेशन्स (dapps)](/developers/docs/dapps/) साठी सर्वात मोठा आधार आहे. हुशार करार “अपरिवर्तनीय” आहेत आणि त्यात बदल करता येत नाही; एखादा करार फक्त उपयोजनाच्या वेळी कोडमध्ये परिभाषित केलेला व्यवसाय तर्क कार्यान्वित करेल. याचा अर्थ डेव्हलपर्स आणि उद्योग Ethereum वर तैनात केल्यानंतर कराराच्या कोडमध्ये फेरफार करू शकत नाहीत. + +हुशार करार विश्वासहीन होण्यासाठी, कराराचा कोड स्वतंत्र पडताळणीसाठी उपलब्ध असावा. प्रत्येक हुशार करारासाठी संकलित बाईटकोड ब्लॉकचेनवर सार्वजनिकरित्या उपलब्ध असला तरी, निम्न-स्तरीय भाषा समजण्यास अवघड आहे - डेव्हलपर्स आणि वापरकर्ते दोघांसाठीही. + +प्रकल्प त्यांच्या करारांचा सोर्स कोड प्रकाशित करून विश्वासाची गृहितके कमी करतात. परंतु यामुळे दुसरी समस्या उद्भवते: प्रकाशित केलेला सोर्स कोड कराराच्या बाईटकोडशी जुळतो की नाही हे तपासणे कठीण आहे. या परिस्थितीत, विश्वासहीनतेचे मूल्य गमावले जाते कारण वापरकर्त्यांना ब्लॉकचेनवर तैनात करण्यापूर्वी कराराचे व्यवसाय तर्क (म्हणजे, बाईटकोड बदलून) न बदलण्यासाठी डेव्हलपर्सवर विश्वास ठेवावा लागतो. + +सोर्स कोड पडताळणी साधने हमी देतात की हुशार कराराच्या सोर्स कोड फाइल्स असेंब्ली कोडशी जुळतात. परिणाम एक विश्वासहीन परिसंस्था आहे, जिथे वापरकर्ते तृतीय पक्षांवर आंधळेपणाने विश्वास ठेवत नाहीत आणि त्याऐवजी करारामध्ये निधी जमा करण्यापूर्वी कोडची पडताळणी करतात. + +### वापरकर्ता सुरक्षा {#user-safety} + +हुशार करारांसह, सहसा बरेच पैसे पणाला लागलेले असतात. यासाठी उच्च सुरक्षा हमी आणि हुशार कराराच्या तर्काची पडताळणी वापरण्यापूर्वी करणे आवश्यक आहे. समस्या ही आहे की अनैतिक डेव्हलपर्स हुशार करारामध्ये दुर्भावनापूर्ण कोड घालून वापरकर्त्यांची फसवणूक करू शकतात. पडताळणीशिवाय, दुर्भावनापूर्ण हुशार करारांमध्ये [बॅकडोअर्स](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts), वादग्रस्त ऍक्सेस कंट्रोल यंत्रणा, शोषण करण्यायोग्य भेद्यता आणि वापरकर्त्याच्या सुरक्षिततेला धोका निर्माण करणाऱ्या इतर गोष्टी असू शकतात ज्या लक्षात येणार नाहीत. + +हुशार कराराच्या सोर्स कोड फाइल्स प्रकाशित केल्याने लेखापरीक्षकांसारख्या स्वारस्य असलेल्यांना संभाव्य हल्ला करणाऱ्या वेक्टर्ससाठी कराराचे मूल्यांकन करणे सोपे होते. अनेक पक्ष स्वतंत्रपणे हुशार कराराची पडताळणी करत असल्याने, वापरकर्त्यांना त्याच्या सुरक्षिततेची अधिक मजबूत हमी मिळते. + +## Ethereum हुशार करारांसाठी सोर्स कोडची पडताळणी कशी करावी {#source-code-verification-for-ethereum-smart-contracts} + +[Ethereum वर हुशार करार तैनात करण्यासाठी](/developers/docs/smart-contracts/deploying/) डेटा पेलोड (संकलित बाईटकोड) सह एका विशेष पत्त्यावर व्यवहार पाठवणे आवश्यक आहे. डेटा पेलोड सोर्स कोड संकलित करून तयार केला जातो, तसेच व्यवहारातील डेटा पेलोडमध्ये जोडलेल्या करार उदाहरणाच्या [कन्स्ट्रक्टर युक्तिवादांसह](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor). संकलन हे निश्चित आहे, याचा अर्थ जर समान सोर्स फाइल्स, आणि संकलन सेटिंग्ज (उदा. कंपाइलर आवृत्ती, ऑप्टिमायझर) वापरल्या गेल्या तर ते नेहमी समान आउटपुट (म्हणजे, करार बाईटकोड) तयार करते. + +![हुशार कराराच्या सोर्स कोड पडताळणीचे रेखाचित्र](./source-code-verification.png) + +हुशार कराराची पडताळणी करण्यामध्ये मुळात खालील पायऱ्या समाविष्ट आहेत: + +1. सोर्स फाइल्स आणि संकलन सेटिंग्ज कंपाइलरमध्ये इनपुट करा. + +2. कंपाइलर कराराचा बाईटकोड आउटपुट करतो + +3. दिलेल्या पत्त्यावर तैनात केलेल्या कराराचा बाईटकोड मिळवा + +4. तैनात केलेल्या बाईटकोडची पुन्हा संकलित केलेल्या बाईटकोडशी तुलना करा. जर कोड जुळले, तर दिलेला सोर्स कोड आणि संकलन सेटिंग्जसह कराराची पडताळणी होते. + +5. याव्यतिरिक्त, बाईटकोडच्या शेवटी असलेले मेटाडेटा हॅश जुळल्यास, ती पूर्ण जुळणी असेल. + +लक्षात घ्या की हे पडताळणीचे एक सोपे वर्णन आहे आणि यात अनेक अपवाद आहेत जे यासह कार्य करणार नाहीत जसे की [अपरिवर्तनीय व्हेरिएबल्स](https://docs.sourcify.dev/docs/immutables/) असणे. + +## सोर्स कोड पडताळणी साधने {#source-code-verification-tools} + +करार पडताळणीची पारंपरिक प्रक्रिया गुंतागुंतीची असू शकते. म्हणूनच आमच्याकडे Ethereum वर तैनात केलेल्या हुशार करारांसाठी सोर्स कोड पडताळण्यासाठी साधने आहेत. ही साधने सोर्स कोड पडताळणीचे मोठे भाग स्वयंचलित करतात आणि वापरकर्त्यांच्या फायद्यासाठी सत्यापित करारांची निवड करतात. + +### Etherscan {#etherscan} + +जरी मुख्यतः [Ethereum ब्लॉकचेन एक्सप्लोरर](/developers/docs/data-and-analytics/block-explorers/) म्हणून ओळखले जात असले तरी, Etherscan हुशार कराराचे डेव्हलपर्स आणि वापरकर्त्यांसाठी [सोर्स कोड पडताळणी सेवा](https://etherscan.io/verifyContract) देखील प्रदान करते. + +Etherscan तुम्हाला मूळ डेटा पेलोड (सोर्स कोड, लायब्ररी ॲड्रेस, कंपाइलर सेटिंग्ज, करार ॲड्रेस, इ.) मधून करार बाईटकोड पुन्हा संकलित करण्याची परवानगी देतो. जर पुन्हा संकलित केलेला बाईटकोड ऑनचेन कराराच्या बाईटकोडशी (आणि कन्स्ट्रक्टर पॅरामीटर्स) संबंधित असेल, तर [करार सत्यापित केला जातो](https://info.etherscan.com/types-of-contract-verification/). + +एकदा सत्यापित झाल्यावर, तुमच्या कराराच्या सोर्स कोडला "सत्यापित" लेबल मिळते आणि इतरांना ऑडिट करण्यासाठी Etherscan वर प्रकाशित केले जाते. हे [सत्यापित करार](https://etherscan.io/contractsVerified/) विभागात देखील जोडले जाते - सत्यापित सोर्स कोडसह हुशार करारांचे एक भांडार. + +Etherscan करार पडताळण्यासाठी सर्वाधिक वापरले जाणारे साधन आहे. तथापि, Etherscan च्या करार पडताळणीमध्ये एक कमतरता आहे: ते ऑनचेन बाईटकोड आणि पुन्हा संकलित केलेल्या बाईटकोडच्या **मेटाडेटा हॅश**ची तुलना करण्यात अयशस्वी ठरते. त्यामुळे Etherscan मधील जुळण्या या आंशिक जुळण्या आहेत. + +[Etherscan वर करार पडताळणीबद्दल अधिक](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327). + +### Blockscout {#blockscout} + +[Blockscout](https://blockscout.com/) एक ओपन-सोर्स ब्लॉकचेन एक्सप्लोरर आहे जो हुशार करार डेव्हलपर्स आणि वापरकर्त्यांसाठी [करार पडताळणी सेवा](https://eth.blockscout.com/contract-verification) देखील प्रदान करतो. एक ओपन-सोर्स पर्याय म्हणून, Blockscout पडताळणी कशी केली जाते यामध्ये पारदर्शकता प्रदान करते आणि पडताळणी प्रक्रियेत सुधारणा करण्यासाठी समुदाय योगदान सक्षम करते. + +इतर पडताळणी सेवांप्रमाणेच, Blockscout तुम्हाला बाईटकोड पुन्हा संकलित करून आणि तैनात केलेल्या कराराशी त्याची तुलना करून तुमच्या कराराच्या सोर्स कोडची पडताळणी करण्याची परवानगी देतो. एकदा सत्यापित झाल्यावर, तुमच्या कराराला पडताळणी स्थिती प्राप्त होते आणि सोर्स कोड ऑडिटिंग आणि परस्परसंवादासाठी सार्वजनिकरित्या उपलब्ध होतो. सत्यापित करार सोप्या ब्राउझिंग आणि शोधासाठी Blockscout च्या [सत्यापित करार भांडारात](https://eth.blockscout.com/verified-contracts) देखील सूचीबद्ध आहेत. + +### Sourcify {#sourcify} + +[Sourcify](https://sourcify.dev/#/verifier) हे करार पडताळण्यासाठी आणखी एक साधन आहे जे ओपन-सोर्स आणि विकेंद्रित आहे. हा ब्लॉक एक्सप्लोरर नाही आणि तो फक्त [विविध EVM आधारित नेटवर्क्स](https://docs.sourcify.dev/docs/chains) वर करारांची पडताळणी करतो. हे इतर साधनांसाठी त्यावर तयार करण्यासाठी सार्वजनिक पायाभूत सुविधा म्हणून काम करते आणि मेटाडेटा फाइलमध्ये आढळलेल्या [ABI](/developers/docs/smart-contracts/compiling/#web-applications) आणि [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) टिप्पण्या वापरून अधिक मानवी-अनुकूल करार संवाद सक्षम करण्याचे उद्दिष्ट ठेवते. + +Etherscan च्या विपरीत, Sourcify मेटाडेटा हॅशसह पूर्ण जुळण्यांना समर्थन देते. सत्यापित करार HTTP आणि [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs) वर त्याच्या [सार्वजनिक भांडारात](https://docs.sourcify.dev/docs/repository/) दिले जातात, जे एक विकेंद्रित, [कंटेंट-ॲड्रेस्ड](https://docs.storacha.network/concepts/content-addressing/) स्टोरेज आहे. हे IPFS वरून कराराची मेटाडेटा फाइल मिळविण्यास अनुमती देते कारण जोडलेला मेटाडेटा हॅश एक IPFS हॅश आहे. + +याव्यतिरिक्त, IPFS वरून सोर्स कोड फाइल्स देखील मिळवू शकतात, कारण या फाइल्सचे IPFS हॅश देखील मेटाडेटामध्ये आढळतात. त्याच्या API किंवा [UI](https://sourcify.dev/#/verifier) द्वारे मेटाडेटा फाइल आणि सोर्स फाइल्स प्रदान करून किंवा प्लगइन्स वापरून कराराची पडताळणी केली जाऊ शकते. Sourcify मॉनिटरिंग टूल नवीन ब्लॉक्सवर कराराच्या निर्मितीचे देखील ऐकते आणि जर त्यांचे मेटाडेटा आणि सोर्स फाइल्स IPFS वर प्रकाशित केल्या असतील तर करारांची पडताळणी करण्याचा प्रयत्न करते. + +[Sourcify वर करार पडताळणीबद्दल अधिक](https://soliditylang.org/blog/2020/06/25/sourcify-faq/). + +### Tenderly {#tenderly} + +[Tenderly प्लॅटफॉर्म](https://tenderly.co/) Web3 डेव्हलपर्सना हुशार करार तयार करण्यास, चाचणी करण्यास, निरीक्षण करण्यास आणि ऑपरेट करण्यास सक्षम करते. डीबगिंग साधनांना निरीक्षणक्षमता आणि पायाभूत सुविधांच्या बिल्डिंग ब्लॉक्ससह एकत्र करून, Tenderly डेव्हलपर्सना हुशार कराराचा विकास वेगवान करण्यास मदत करते. Tenderly ची वैशिष्ट्ये पूर्णपणे सक्षम करण्यासाठी, डेव्हलपर्सना अनेक पद्धती वापरून [सोर्स कोड पडताळणी करणे](https://docs.tenderly.co/monitoring/contract-verification) आवश्यक आहे. + +करार खाजगीरित्या किंवा सार्वजनिकरित्या सत्यापित करणे शक्य आहे. खाजगीरित्या सत्यापित केल्यास, हुशार करार फक्त तुम्हाला (आणि तुमच्या प्रकल्पातील इतर सदस्यांना) दिसेल. करार सार्वजनिकरित्या सत्यापित केल्याने तो Tenderly प्लॅटफॉर्म वापरणाऱ्या प्रत्येकाला दिसतो. + +तुम्ही [डॅशबोर्ड](https://docs.tenderly.co/contract-verification), [Tenderly Hardhat प्लगइन](https://docs.tenderly.co/contract-verification/hardhat), किंवा [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli) वापरून तुमच्या करारांची पडताळणी करू शकता. + +डॅशबोर्डद्वारे करार पडताळताना, तुम्हाला Solidity कंपाइलरद्वारे तयार केलेली सोर्स फाइल किंवा मेटाडेटा फाइल, ॲड्रेस/नेटवर्क, आणि कंपाइलर सेटिंग्ज आयात करणे आवश्यक आहे. + +Tenderly Hardhat प्लगइन वापरल्याने कमी प्रयत्नात पडताळणी प्रक्रियेवर अधिक नियंत्रण मिळते, ज्यामुळे तुम्हाला स्वयंचलित (नो-कोड) आणि मॅन्युअल (कोड-आधारित) पडताळणी यापैकी निवड करता येते. + +## पुढील वाचन {#further-reading} + +- [करार सोर्स कोडची पडताळणी करणे](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/) diff --git a/public/content/translations/mr/developers/docs/standards/index.md b/public/content/translations/mr/developers/docs/standards/index.md new file mode 100644 index 00000000000..23dceeaf403 --- /dev/null +++ b/public/content/translations/mr/developers/docs/standards/index.md @@ -0,0 +1,59 @@ +--- +title: "इथेरियम विकास मानके" +description: "EIPs, ERC-20 आणि ERC-721 सारखी टोकन मानके आणि विकास रूढींसह इथेरियम मानकांबद्दल जाणून घ्या." +lang: mr +incomplete: true +--- + +## मानकांचे विहंगावलोकन {#standards-overview} + +इथेरियम समुदायाने अनेक मानके स्वीकारली आहेत जी ([इथेरियम क्लायंट](/developers/docs/nodes-and-clients/) आणि वॉलेट्स सारखे) प्रकल्प अंमलबजावणींमध्ये आंतरकार्यक्षम ठेवण्यास मदत करतात आणि स्मार्ट कॉन्ट्रॅक्ट्स आणि डॅप्स कंपोझेबल राहतील याची खात्री करतात. + +सामान्यतः मानके [इथेरियम सुधारणा प्रस्ताव](/eips/) (EIPs) म्हणून सादर केली जातात, ज्यावर समुदाय सदस्य [मानक प्रक्रियेद्वारे](https://eips.ethereum.org/EIPS/eip-1) चर्चा करतात. + +- [EIPs चा परिचय](/eips/) +- [EIPs ची सूची](https://eips.ethereum.org/) +- [EIP गिटहब रेपो](https://github.com/ethereum/EIPs) +- [EIP चर्चा मंडळ](https://ethereum-magicians.org/c/eips) +- [इथेरियम गव्हर्नन्सचा परिचय](/governance/) +- [इथेरियम गव्हर्नन्सचे विहंगावलोकन](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _31 मार्च, 2019 - बोरिस मॅन_ +- [इथेरियम प्रोटोकॉल विकास गव्हर्नन्स आणि नेटवर्क अपग्रेड समन्वय](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _23 मार्च, 2020 - हडसन जेमिसन_ +- [सर्व इथेरियम कोअर डेव्ह बैठकांची प्लेलिस्ट](https://www.youtube.com/@EthereumProtocol) _(YouTube प्लेलिस्ट)_ + +## मानकांचे प्रकार {#types-of-standards} + +EIPs चे 3 प्रकार आहेत: + +- स्टँडर्ड्स ट्रॅक: बहुतेक किंवा सर्व इथेरियम अंमलबजावणींवर परिणाम करणाऱ्या कोणत्याही बदलाचे वर्णन करते +- [मेटा ट्रॅक](https://eips.ethereum.org/meta): इथेरियमच्या सभोवतालच्या प्रक्रियेचे वर्णन करते किंवा प्रक्रियेत बदल प्रस्तावित करते +- [माहितीपूर्ण ट्रॅक](https://eips.ethereum.org/informational): इथेरियम डिझाइन समस्येचे वर्णन करते किंवा इथेरियम समुदायाला सामान्य मार्गदर्शक तत्त्वे किंवा माहिती प्रदान करते + +शिवाय, स्टँडर्ड ट्रॅक 4 श्रेणींमध्ये विभागलेला आहे: + +- [कोअर](https://eips.ethereum.org/core): सहमती फोर्क आवश्यक असलेल्या सुधारणा +- [नेटवर्किंग](https://eips.ethereum.org/networking): devp2p आणि लाईट इथेरियम सबप्रोटोकॉलमधील सुधारणा, तसेच व्हिस्पर आणि स्वार्मच्या नेटवर्क प्रोटोकॉल तपशीलांसाठी प्रस्तावित सुधारणा. +- [इंटरफेस](https://eips.ethereum.org/interface): क्लायंट API/RPC तपशील आणि मानकांमधील सुधारणा, आणि मेथडची नावे आणि कॉन्ट्रॅक्ट ABI सारखी विशिष्ट भाषा-स्तरीय मानके. +- [ERC](https://eips.ethereum.org/erc): अनुप्रयोग-स्तरीय मानके आणि रूढी + +या विविध प्रकार आणि श्रेणींबद्दल अधिक तपशीलवार माहिती [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types) मध्ये आढळू शकते + +### टोकन मानके {#token-standards} + +- [ERC-20](/developers/docs/standards/tokens/erc-20/) - फंजिबल (परस्पर बदलण्यायोग्य) टोकनसाठी एक मानक इंटरफेस, जसे की व्होटिंग टोकन, स्टेकिंग टोकन किंवा व्हर्च्युअल चलने. + - [ERC-223](/developers/docs/standards/tokens/erc-223/) - एक फंजिबल टोकन मानक जे टोकनला इथरसारखेच वागण्यास प्रवृत्त करते आणि प्राप्तकर्त्याच्या बाजूने टोकन हस्तांतरण हाताळण्यास समर्थन देते. + - [ERC-1363](/developers/docs/standards/tokens/erc-1363/) - ERC-20 टोकन्ससाठी एक विस्तार इंटरफेस जो एकाच व्यवहारात प्राप्तकर्ता करारांवर कॉलबॅक कार्यान्वित करण्यास समर्थन देतो. +- [ERC-721](/developers/docs/standards/tokens/erc-721/) - नॉन-फंजिबल टोकनसाठी एक मानक इंटरफेस, जसे की कलाकृती किंवा गाण्यासाठी एक डीड. + - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - सलग टोकन आयडेंटिफायर्स वापरून एक किंवा अनेक नॉन-फंजिबल टोकन तयार/हस्तांतरित करताना उत्सर्जित होणारा एक प्रमाणित इव्हेंट. + - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - EIP-721 ग्राहक भूमिकेसाठी इंटरफेस विस्तार. + - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - ERC-721 टोकनमध्ये प्रतिबंधित परवानग्यांसह वेळ-मर्यादित भूमिका जोडा. +- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **(शिफारस केलेले नाही)** ERC-20 पेक्षा सुधारित एक टोकन मानक. +- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - एक टोकन मानक ज्यात फंजिबल आणि नॉन-फंजिबल दोन्ही मालमत्ता असू शकतात. +- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - यील्ड-बेअरिंग वॉल्ट्सचे तांत्रिक पॅरामीटर्स ऑप्टिमाइझ करण्यासाठी आणि एकत्रित करण्यासाठी डिझाइन केलेले एक टोकनाइज्ड वॉल्ट मानक. + +[टोकन मानकां](/developers/docs/standards/tokens/)बद्दल अधिक जाणून घ्या. + +## पुढील वाचन {#further-reading} + +- [इथेरियम सुधारणा प्रस्ताव (EIPs)](/eips/) + +_तुम्हाला मदत केलेल्या सामुदायिक संसाधनाबद्दल माहिती आहे का?_ हे पृष्ठ संपादित करा आणि ते जोडा!_ diff --git a/public/content/translations/mr/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/mr/developers/docs/standards/tokens/erc-1155/index.md new file mode 100644 index 00000000000..845f9e01626 --- /dev/null +++ b/public/content/translations/mr/developers/docs/standards/tokens/erc-1155/index.md @@ -0,0 +1,146 @@ +--- +title: "ERC-1155 मल्टी-टोकन स्टँडर्ड" +description: "ERC-1155 बद्दल जाणून घ्या, हे एक मल्टी-टोकन स्टँडर्ड आहे जे एकाच कॉन्ट्रॅक्टमध्ये फंजिबल आणि नॉन-फंजिबल टोकन एकत्र करते." +lang: mr +--- + +## प्रस्तावना {#introduction} + +अनेक टोकन प्रकारांचे व्यवस्थापन करणाऱ्या कॉन्ट्रॅक्टसाठी एक स्टँडर्ड इंटरफेस. एकाच तैनात केलेल्या कॉन्ट्रॅक्टमध्ये फंजिबल टोकन, नॉन-फंजिबल टोकन किंवा इतर कॉन्फिगरेशन्सचे (उदा., सेमी-फंजिबल टोकन) कोणतेही संयोजन समाविष्ट असू शकते. + +**मल्टी-टोकन स्टँडर्ड याचा अर्थ काय आहे?** + +ही कल्पना सोपी आहे आणि एक स्मार्ट कॉन्ट्रॅक्ट इंटरफेस तयार करण्याचा प्रयत्न करते जो कोणत्याही संख्येच्या फंजिबल आणि नॉन-फंजिबल टोकन प्रकारांचे प्रतिनिधित्व आणि नियंत्रण करू शकतो. या प्रकारे, ERC-1155 टोकन [ERC-20](/developers/docs/standards/tokens/erc-20/) आणि [ERC-721](/developers/docs/standards/tokens/erc-721/) टोकन सारखीच कार्ये करू शकते, आणि एकाच वेळी दोन्हीही करू शकते. हे ERC-20 आणि ERC-721 दोन्ही स्टँडर्डची कार्यक्षमता सुधारते, त्याला अधिक कार्यक्षम बनवते आणि स्पष्ट अंमलबजावणीतील चुका दुरुस्त करते. + +ERC-1155 टोकनचे पूर्ण वर्णन [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155) मध्ये केले आहे. + +## पूर्वतयारी {#prerequisites} + +हे पेज अधिक चांगल्या प्रकारे समजून घेण्यासाठी, आम्ही शिफारस करतो की तुम्ही प्रथम [टोकन स्टँडर्ड](/developers/docs/standards/tokens/), [ERC-20](/developers/docs/standards/tokens/erc-20/), आणि [ERC-721](/developers/docs/standards/tokens/erc-721/) बद्दल वाचा. + +## ERC-1155 फंक्शन्स आणि वैशिष्ट्ये: {#body} + +- [बॅच ट्रान्सफर](#batch_transfers): एकाच कॉलमध्ये एकाधिक मालमत्ता हस्तांतरित करा. +- [बॅच बॅलन्स](#batch_balance): एकाच कॉलमध्ये एकाधिक मालमत्तांची शिल्लक मिळवा. +- [बॅच अप्रूव्हल](#batch_approval): सर्व टोकन एका अॅड्रेससाठी मंजूर करा. +- [हुक्स](#receive_hook): टोकन प्राप्त करण्यासाठी हुक. +- [NFT सपोर्ट](#nft_support): पुरवठा फक्त 1 असल्यास, त्याला NFT म्हणून माना. +- [सुरक्षित हस्तांतरण नियम](#safe_transfer_rule): सुरक्षित हस्तांतरणासाठी नियमांचा संच. + +### बॅच ट्रान्सफर {#batch-transfers} + +बॅच हस्तांतरण नियमित ERC-20 हस्तांतरणासारखेच कार्य करते. चला नियमित ERC-20 `transferFrom` फंक्शन पाहूया: + +```solidity +// ERC-20 +function transferFrom(address from, address to, uint256 value) external returns (bool); + +// ERC-1155 +function safeBatchTransferFrom( + address _from, + address _to, + uint256[] calldata _ids, + uint256[] calldata _values, + bytes calldata _data +) external; +``` + +ERC-1155 मध्ये फक्त फरक हा आहे की आपण व्हॅल्यूज एका अॅरे म्हणून पास करतो आणि आपण आयडींचा अॅरे देखील पास करतो. उदाहरणार्थ, `ids=[3, 6, 13]` आणि `values=[100, 200, 5]` दिल्यास, परिणामी हस्तांतरणे अशी असतील + +1. `_from` पासून `_to` कडे आयडी 3 असलेले 100 टोकन हस्तांतरित करा. +2. `_from` पासून `_to` कडे आयडी 6 असलेले 200 टोकन हस्तांतरित करा. +3. `_from` पासून `_to` कडे आयडी 13 असलेले 5 टोकन हस्तांतरित करा. + +ERC-1155 मध्ये आपल्याकडे फक्त `transferFrom` आहे, `transfer` नाही. याचा नियमित `transfer` सारखा वापर करण्यासाठी, फक्त 'from' अॅड्रेस फंक्शन कॉल करणाऱ्या अॅड्रेसवर सेट करा. + +### बॅच बॅलन्स {#batch-balance} + +संबंधित ERC-20 `balanceOf` कॉलला देखील बॅच सपोर्टसह त्याचे पार्टनर फंक्शन आहे. एक आठवण म्हणून, ही ERC-20 आवृत्ती आहे: + +```solidity +// ERC-20 +function balanceOf(address owner) external view returns (uint256); + +// ERC-1155 +function balanceOfBatch( + address[] calldata _owners, + uint256[] calldata _ids +) external view returns (uint256[] memory); +``` + +बॅलन्स कॉलसाठी आणखी सोपे, आपण एकाच कॉलमध्ये एकाधिक बॅलन्स मिळवू शकतो. आपण ओनर्सचा अॅरे पास करतो, आणि त्यानंतर टोकन आयडींचा अॅरे पास करतो. + +उदाहरणार्थ `_ids=[3, 6, 13]` आणि `_owners=[0xbeef..., 0x1337..., 0x1111...]` दिल्यास, रिटर्न व्हॅल्यू अशी असेल + +```solidity +[ + balanceOf(0xbeef...), + balanceOf(0x1337...), + balanceOf(0x1111...) +] +``` + +### बॅच अप्रूव्हल {#batch-approval} + +```solidity +// ERC-1155 +function setApprovalForAll( + address _operator, + bool _approved +) external; + +function isApprovedForAll( + address _owner, + address _operator +) external view returns (bool); +``` + +मंजुरी ERC-20 पेक्षा थोड्या वेगळ्या आहेत. विशिष्ट रकमेला मंजुरी देण्याऐवजी, तुम्ही `setApprovalForAll` द्वारे ऑपरेटरला मंजूर किंवा नामंजूर म्हणून सेट करता. + +सध्याची स्थिती `isApprovedForAll` द्वारे वाचता येते. तुम्ही पाहू शकता की, हे एक 'ऑल-ऑर-नथिंग' ऑपरेशन आहे. तुम्ही किती टोकन मंजूर करायचे किंवा कोणता टोकन वर्ग मंजूर करायचा हे परिभाषित करू शकत नाही. + +हे सोपेपणा लक्षात घेऊन हेतुपुरस्सर डिझाइन केले आहे. तुम्ही फक्त एका अॅड्रेससाठी सर्वकाही मंजूर करू शकता. + +### रिसीव्ह हुक {#receive-hook} + +```solidity +function onERC1155BatchReceived( + address _operator, + address _from, + uint256[] calldata _ids, + uint256[] calldata _values, + bytes calldata _data +) external returns(bytes4); +``` + +[EIP-165](https://eips.ethereum.org/EIPS/eip-165) सपोर्टमुळे, ERC-1155 केवळ स्मार्ट कॉन्ट्रॅक्ट्ससाठी रिसीव्ह हुक्सना सपोर्ट करते. हुक फंक्शनने एक मॅजिक पूर्वनिर्धारित bytes4 व्हॅल्यू परत करणे आवश्यक आहे, जे खालीलप्रमाणे दिले आहे: + +```solidity +bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) +``` + +जेव्हा प्राप्त करणारा कॉन्ट्रॅक्ट ही व्हॅल्यू परत करतो, तेव्हा असे मानले जाते की कॉन्ट्रॅक्ट हस्तांतरण स्वीकारतो आणि ERC-1155 टोकन कसे हाताळायचे हे त्याला माहीत आहे. उत्तम, आता कॉन्ट्रॅक्टमध्ये टोकन अडकणार नाहीत! + +### NFT सपोर्ट {#nft-support} + +जेव्हा पुरवठा फक्त एक असतो, तेव्हा टोकन मूलतः एक नॉन-फंजिबल टोकन (NFT) असते. आणि जसे ERC-721 साठी स्टँडर्ड आहे, तुम्ही मेटाडेटा URL परिभाषित करू शकता. URL क्लायंटद्वारे वाचता आणि सुधारित करता येतो, [येथे](https://eips.ethereum.org/EIPS/eip-1155#metadata) पहा. + +### सुरक्षित हस्तांतरण नियम {#safe-transfer-rule} + +आपण मागील स्पष्टीकरणांमध्ये आधीच काही सुरक्षित हस्तांतरण नियमांवर चर्चा केली आहे. पण चला सर्वात महत्त्वाच्या नियमांवर नजर टाकूया: + +1. कॉलरला `_from` अॅड्रेससाठी टोकन खर्च करण्याची परवानगी असणे आवश्यक आहे किंवा कॉलर स्वतः `_from` असणे आवश्यक आहे. +2. हस्तांतरण कॉल रिव्हर्ट होणे आवश्यक आहे जर + 1. `_to` अॅड्रेस 0 आहे. + 2. `_ids` ची लांबी `_values` च्या लांबी समान नाही. + 3. `_ids` मधील टोकनसाठी धारकाची कोणतीही शिल्लक प्राप्तकर्त्याला पाठवलेल्या `_values` मधील संबंधित रकमेपेक्षा कमी असेल. + 4. इतर कोणतीही त्रुटी उद्भवल्यास. + +_टीप_: हुकसह सर्व बॅच फंक्शन्स बॅचशिवाय आवृत्त्या म्हणून देखील अस्तित्वात आहेत. हे गॅस कार्यक्षमतेसाठी केले जाते, कारण फक्त एक मालमत्ता हस्तांतरित करणे हाच बहुधा सर्वाधिक वापरला जाणारा मार्ग असेल. स्पष्टीकरणांमध्ये सोपेपणासाठी आम्ही त्यांना वगळले आहे, यात सुरक्षित हस्तांतरण नियमांचाही समावेश आहे. नावे सारखीच आहेत, फक्त 'Batch' काढून टाका. + +## पुढील वाचन {#further-reading} + +- [EIP-1155: मल्टी टोकन स्टँडर्ड](https://eips.ethereum.org/EIPS/eip-1155) +- [ERC-1155: Openzeppelin डॉक्स](https://docs.openzeppelin.com/contracts/5.x/erc1155) +- [ERC-1155: GitHub रेपो](https://github.com/enjin/erc-1155) +- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart) diff --git a/public/content/translations/mr/developers/docs/standards/tokens/erc-1363/index.md b/public/content/translations/mr/developers/docs/standards/tokens/erc-1363/index.md new file mode 100644 index 00000000000..a1ba5986506 --- /dev/null +++ b/public/content/translations/mr/developers/docs/standards/tokens/erc-1363/index.md @@ -0,0 +1,213 @@ +--- +title: "ERC-1363 पेयबल टोकन मानक" +description: "ERC-1363 हा ERC-20 टोकनसाठी एक एक्सटेंशन इंटरफेस आहे जो हस्तांतरणानंतर प्राप्तकर्त्याच्या करारावर किंवा मंजुरीनंतर खर्च करणाऱ्याच्या करारावर, सर्व काही एकाच व्यवहारामध्ये, कस्टम लॉजिक कार्यान्वित करण्यास समर्थन देतो." +lang: mr +--- + +## प्रस्तावना {#introduction} + +### ERC-1363 म्हणजे काय? {#what-is-erc1363} + +ERC-1363 हा ERC-20 टोकनसाठी एक एक्सटेंशन इंटरफेस आहे जो हस्तांतरणानंतर प्राप्तकर्त्याच्या करारावर किंवा मंजुरीनंतर खर्च करणाऱ्याच्या करारावर, सर्व काही एकाच व्यवहारामध्ये, कस्टम लॉजिक कार्यान्वित करण्यास समर्थन देतो. + +### ERC-20 मधील फरक {#erc20-differences} + +`transfer`, `transferFrom` आणि `approve` यासारख्या मानक ERC-20 ऑपरेशन्स स्वतंत्र व्यवहाराशिवाय प्राप्तकर्ता किंवा खर्च करणाऱ्या करारावर कोड अंमलबजावणीस परवानगी देत नाहीत. +यामुळे UI विकासात गुंतागुंत निर्माण होते आणि अवलंब करण्यामध्ये अडथळा येतो कारण वापरकर्त्यांना पहिला व्यवहार कार्यान्वित होण्याची वाट पाहावी लागते आणि मग दुसरा व्यवहार सबमिट करावा लागतो. +त्यांना दोनदा GAS देखील भरावा लागतो. + +ERC-1363 फंजिबल टोकनला अधिक सहजपणे क्रिया करण्यास आणि कोणत्याही ऑफ-चेन लिसनरचा वापर न करता काम करण्यास सक्षम बनवते. +हे हस्तांतरण किंवा मंजुरीनंतर, एकाच व्यवहारामध्ये, रिसीव्हर किंवा स्पेंडर करारावर कॉलबॅक करण्याची परवानगी देते. + +## पूर्वतयारी {#prerequisites} + +हे पान अधिक चांगल्या प्रकारे समजून घेण्यासाठी, आम्ही शिफारस करतो की तुम्ही प्रथम याबद्दल वाचा: + +- [टोकन मानके](/developers/docs/standards/tokens/) +- [ERC-20](/developers/docs/standards/tokens/erc-20/) + +## मुख्य भाग {#body} + +ERC-1363, `transfer`, `transferFrom` किंवा `approve` नंतर ERC-20 टोकनला स्मार्ट करारांशी संवाद साधण्यासाठी एक मानक API सादर करते. + +हे मानक टोकन हस्तांतरित करण्यासाठी मूलभूत कार्यक्षमता प्रदान करते, तसेच टोकनला मंजूर करण्याची परवानगी देते जेणेकरून ते दुसऱ्या ऑन-चेन तृतीय पक्षाद्वारे खर्च केले जाऊ शकतात, आणि नंतर रिसीव्हर किंवा स्पेंडर करारावर कॉलबॅक करते. + +ERC-20 कॉलबॅक स्वीकारू शकणार्‍या स्मार्ट करारांचे अनेक प्रस्तावित उपयोग आहेत. + +उदाहरणे असू शकतात: + +- **क्राउडसेल्स**: पाठवलेले टोकन त्वरित रिवॉर्ड वाटप सुरू करतात. +- **सेवा**: पेमेंट एकाच टप्प्यात सेवा प्रवेश सक्रिय करते. +- **इन्व्हॉइसेस**: टोकन आपोआप इन्व्हॉइसेस सेटल करतात. +- **सबस्क्रिप्शन्स**: वार्षिक दराला मंजुरी दिल्याने पहिल्या महिन्याच्या पेमेंटमध्येच सबस्क्रिप्शन सक्रिय होते. + +या कारणांमुळे याला मूळतः **"पेयबल टोकन"** असे नाव देण्यात आले होते. + +कॉलबॅक वर्तणूक त्याची उपयुक्तता आणखी वाढवते, ज्यामुळे यांसारखे अखंड संवाद सक्षम होतात: + +- **स्टेकिंग**: हस्तांतरित केलेले टोकन स्टेकिंग करारामध्ये स्वयंचलित लॉकिंग सुरू करतात. +- **मतदान**: प्राप्त झालेले टोकन प्रशासन प्रणालीमध्ये मते नोंदवतात. +- **स्वॅपिंग**: टोकन मान्यता एकाच टप्प्यात स्वॅप लॉजिक सक्रिय करतात. + +ERC-1363 टोकन सर्व प्रकरणांमध्ये विशिष्ट उपयुक्ततांसाठी वापरले जाऊ शकतात, ज्यात हस्तांतरण किंवा मंजुरी मिळाल्यानंतर कॉलबॅक कार्यान्वित करणे आवश्यक असते. +प्राप्तकर्त्याच्या टोकन हाताळण्याच्या क्षमतेची पडताळणी करून स्मार्ट करारांमध्ये टोकनचे नुकसान किंवा टोकन लॉकिंग टाळण्यासाठी ERC-1363 उपयुक्त आहे. + +इतर ERC-20 एक्सटेंशन प्रस्तावांच्या विपरीत, ERC-1363 हे ERC-20 `transfer` आणि `transferFrom` पद्धतींना ओव्हरराइड करत नाही आणि ERC-20 सह बॅकवर्ड सुसंगतता राखून अंमलबजावणीसाठी इंटरफेस आयडी परिभाषित करते. + +[EIP-1363](https://eips.ethereum.org/EIPS/eip-1363) वरून: + +### मेथड्स {#methods} + +ERC-1363 मानक लागू करणाऱ्या स्मार्ट करारांनी `ERC1363` इंटरफेसमधील सर्व फंक्शन्स, तसेच `ERC20` आणि `ERC165` इंटरफेस **अवश्य** लागू केले पाहिजेत. + +```solidity +pragma solidity ^0.8.0; + +/** + * @title ERC1363 + * @dev An extension interface for ERC-20 tokens that supports executing code on a recipient contract + * after `transfer` or `transferFrom`, or code on a spender contract after `approve`, in a single transaction. + */ +interface ERC1363 is ERC20, ERC165 { + /* + * NOTE: the ERC-165 identifier for this interface is 0xb0202a11. + * 0xb0202a11 === + * bytes4(keccak256('transferAndCall(address,uint256)')) ^ + * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^ + * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^ + * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^ + * bytes4(keccak256('approveAndCall(address,uint256)')) ^ + * bytes4(keccak256('approveAndCall(address,uint256,bytes)')) + */ + + /** + * @dev Moves a `value` amount of tokens from the caller's account to `to` + * and then calls `ERC1363Receiver::onTransferReceived` on `to`. + * @param to The address to which tokens are being transferred. + * @param value The amount of tokens to be transferred. + * @return A boolean value indicating the operation succeeded unless throwing. + */ + function transferAndCall(address to, uint256 value) external returns (bool); + + /** + * @dev Moves a `value` amount of tokens from the caller's account to `to` + * and then calls `ERC1363Receiver::onTransferReceived` on `to`. + * @param to The address to which tokens are being transferred. + * @param value The amount of tokens to be transferred. + * @param data Additional data with no specified format, sent in call to `to`. + * @return A boolean value indicating the operation succeeded unless throwing. + */ + function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool); + + /** + * @dev Moves a `value` amount of tokens from `from` to `to` using the allowance mechanism + * and then calls `ERC1363Receiver::onTransferReceived` on `to`. + * @param from The address from which to send tokens. + * @param to The address to which tokens are being transferred. + * @param value The amount of tokens to be transferred. + * @return A boolean value indicating the operation succeeded unless throwing. + */ + function transferFromAndCall(address from, address to, uint256 value) external returns (bool); + + /** + * @dev Moves a `value` amount of tokens from `from` to `to` using the allowance mechanism + * and then calls `ERC1363Receiver::onTransferReceived` on `to`. + * @param from The address from which to send tokens. + * @param to The address to which tokens are being transferred. + * @param value The amount of tokens to be transferred. + * @param data Additional data with no specified format, sent in call to `to`. + * @return A boolean value indicating the operation succeeded unless throwing. + */ + function transferFromAndCall(address from, address to, uint256 value, bytes calldata data) external returns (bool); + + /** + * @dev Sets a `value` amount of tokens as the allowance of `spender` over the caller's tokens + * and then calls `ERC1363Spender::onApprovalReceived` on `spender`. + * @param spender The address which will spend the funds. + * @param value The amount of tokens to be spent. + * @return A boolean value indicating the operation succeeded unless throwing. + */ + function approveAndCall(address spender, uint256 value) external returns (bool); + + /** + * @dev Sets a `value` amount of tokens as the allowance of `spender` over the caller's tokens + * and then calls `ERC1363Spender::onApprovalReceived` on `spender`. + * @param spender The address which will spend the funds. + * @param value The amount of tokens to be spent. + * @param data Additional data with no specified format, sent in call to `spender`. + * @return A boolean value indicating the operation succeeded unless throwing. + */ + function approveAndCall(address spender, uint256 value, bytes calldata data) external returns (bool); +} + +interface ERC20 { + event Transfer(address indexed from, address indexed to, uint256 value); + event Approval(address indexed owner, address indexed spender, uint256 value); + function transfer(address to, uint256 value) external returns (bool); + function transferFrom(address from, address to, uint256 value) external returns (bool); + function approve(address spender, uint256 value) external returns (bool); + function totalSupply() external view returns (uint256); + function balanceOf(address account) external view returns (uint256); + function allowance(address owner, address spender) external view returns (uint256); +} + +interface ERC165 { + function supportsInterface(bytes4 interfaceId) external view returns (bool); +} +``` + +`transferAndCall` किंवा `transferFromAndCall` द्वारे ERC-1363 टोकन स्वीकारू इच्छिणाऱ्या स्मार्ट कराराने `ERC1363Receiver` इंटरफेस **अवश्य** लागू केला पाहिजे: + +```solidity +/** + * @title ERC1363Receiver + * @dev Interface for any contract that wants to support `transferAndCall` or `transferFromAndCall` from ERC-1363 token contracts. + */ +interface ERC1363Receiver { + /** + * @dev Whenever ERC-1363 tokens are transferred to this contract via `ERC1363::transferAndCall` or `ERC1363::transferFromAndCall` + * by `operator` from `from`, this function is called. + * + * NOTE: To accept the transfer, this must return + * `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` + * (i.e. 0x88a7ca5c, or its own function selector). + * + * @param operator The address which called `transferAndCall` or `transferFromAndCall` function. + * @param from The address which are tokens transferred from. + * @param value The amount of tokens transferred. + * @param data Additional data with no specified format. + * @return `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` if transfer is allowed unless throwing. + */ + function onTransferReceived(address operator, address from, uint256 value, bytes calldata data) external returns (bytes4); +} +``` + +`approveAndCall` द्वारे ERC-1363 टोकन स्वीकारू इच्छिणाऱ्या स्मार्ट कराराने `ERC1363Spender` इंटरफेस **अवश्य** लागू केला पाहिजे: + +```solidity +/** + * @title ERC1363Spender + * @dev Interface for any contract that wants to support `approveAndCall` from ERC-1363 token contracts. + */ +interface ERC1363Spender { + /** + * @dev Whenever an ERC-1363 tokens `owner` approves this contract via `ERC1363::approveAndCall` + * to spend their tokens, this function is called. + * + * NOTE: To accept the approval, this must return + * `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` + * (i.e. 0x7b04a2d0, or its own function selector). + * + * @param owner The address which called `approveAndCall` function and previously owned the tokens. + * @param value The amount of tokens to be spent. + * @param data Additional data with no specified format. + * @return `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` if approval is allowed unless throwing. + */ + function onApprovalReceived(address owner, uint256 value, bytes calldata data) external returns (bytes4); +} +``` + +## पुढील वाचन {#further-reading} + +- [ERC-1363: पेयबल टोकन मानक](https://eips.ethereum.org/EIPS/eip-1363) +- [ERC-1363: GitHub रेपो](https://github.com/vittominacori/erc1363-payable-token) diff --git a/public/content/translations/mr/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/mr/developers/docs/standards/tokens/erc-20/index.md new file mode 100644 index 00000000000..71289503fe6 --- /dev/null +++ b/public/content/translations/mr/developers/docs/standards/tokens/erc-20/index.md @@ -0,0 +1,186 @@ +--- +title: "ERC-20 टोकन मानक" +description: "ERC-20 बद्दल जाणून घ्या, Ethereum वरील फंजिबल टोकन्ससाठीचे मानक जे इंटरऑपरेबल टोकन ऍप्लिकेशन्सना सक्षम करते." +lang: mr +--- + +## प्रस्तावना {#introduction} + +**टोकन म्हणजे काय?** + +Ethereum मध्ये टोकन्स अक्षरशः काहीही दर्शवू शकतात: + +- ऑनलाइन प्लॅटफॉर्ममधील प्रतिष्ठेचे गुण +- गेममधील कॅरॅक्टरची कौशल्ये +- कंपनीमधील शेअरसारखी आर्थिक मालमत्ता +- USD सारखे फियाट चलन +- एक औंस सोने +- आणि बरेच काही... + +Ethereum चे इतके शक्तिशाली वैशिष्ट्य एका मजबूत मानकाद्वारे हाताळले जाणे आवश्यक आहे, बरोबर? अगदी इथेच ERC-20 आपली भूमिका बजावते! हे मानक डेव्हलपर्सना असे टोकन ऍप्लिकेशन्स बनविण्याची परवानगी देते जे इतर उत्पादने आणि सेवांसह इंटरऑपरेबल आहेत. ERC-20 मानकाचा वापर [ether](/glossary/#ether) ला अतिरिक्त कार्यक्षमता प्रदान करण्यासाठी देखील केला जातो. + +**ERC-20 म्हणजे काय?** + +ERC-20 फंजिबल टोकन्ससाठी एक मानक सादर करते, दुसऱ्या शब्दांत, त्यांच्याकडे एक वैशिष्ट्य आहे जे प्रत्येक टोकनला दुसऱ्या टोकनसारखेच (प्रकार आणि मूल्यात) बनवते. उदाहरणार्थ, ERC-20 टोकन ETH प्रमाणेच कार्य करते, याचा अर्थ असा की 1 टोकन इतर सर्व टोकन्सच्या समान आहे आणि नेहमीच असेल. + +## पूर्वतयारी {#prerequisites} + +- [खाती](/developers/docs/accounts) +- [स्मार्ट कॉन्ट्रॅक्ट्स](/developers/docs/smart-contracts/) +- [टोकन मानके](/developers/docs/standards/tokens/) + +## मुख्य भाग {#body} + +ERC-20 (Ethereum Request for Comments 20), नोव्हेंबर 2015 मध्ये फॅबियन व्होगेलस्टेलर यांनी प्रस्तावित केले, हे एक टोकन मानक आहे जे स्मार्ट कॉन्ट्रॅक्ट्समधील टोकन्ससाठी API लागू करते. + +ERC-20 द्वारे प्रदान केलेल्या उदाहरण कार्यक्षमता: + +- एका खात्यातून दुसऱ्या खात्यात टोकन हस्तांतरित करणे +- खात्यातील सध्याची टोकन शिल्लक मिळवणे +- नेटवर्कवर उपलब्ध असलेल्या टोकनचा एकूण पुरवठा मिळवणे +- एखाद्या खात्यातील टोकनची रक्कम तृतीय-पक्ष खात्याद्वारे खर्च केली जाऊ शकते की नाही हे मंजूर करणे + +जर एखादे स्मार्ट कॉन्ट्रॅक्ट खालील पद्धती आणि इव्हेंट्स लागू करत असेल, तर त्याला ERC-20 टोकन कॉन्ट्रॅक्ट म्हटले जाऊ शकते आणि एकदा तैनात केल्यावर ते Ethereum वर तयार केलेल्या टोकन्सचा मागोवा ठेवण्यासाठी जबाबदार असेल. + +[EIP-20](https://eips.ethereum.org/EIPS/eip-20) वरून: + +### मेथड्स {#methods} + +```solidity +function name() public view returns (string) +function symbol() public view returns (string) +function decimals() public view returns (uint8) +function totalSupply() public view returns (uint256) +function balanceOf(address _owner) public view returns (uint256 balance) +function transfer(address _to, uint256 _value) public returns (bool success) +function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) +function approve(address _spender, uint256 _value) public returns (bool success) +function allowance(address _owner, address _spender) public view returns (uint256 remaining) +``` + +### इव्हेंट्स {#events} + +```solidity +event Transfer(address indexed _from, address indexed _to, uint256 _value) +event Approval(address indexed _owner, address indexed _spender, uint256 _value) +``` + +### उदाहरणे {#web3py-example} + +चला पाहूया की Ethereum वरील कोणत्याही ERC-20 टोकन कॉन्ट्रॅक्टची तपासणी करणे आपल्यासाठी सोपे करण्यासाठी एक मानक किती महत्त्वाचे आहे. +कोणत्याही ERC-20 टोकनसाठी इंटरफेस तयार करण्यासाठी आपल्याला फक्त कॉन्ट्रॅक्ट ऍप्लिकेशन बायनरी इंटरफेस (ABI) ची आवश्यकता आहे. तुम्ही खाली पाहू शकता की आम्ही एक सरलीकृत ABI वापरणार आहोत, जेणेकरून हे एक कमी घर्षणाचे उदाहरण बनेल. + +#### Web3.py उदाहरण {#web3py-example} + +प्रथम, आपण [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) Python लायब्ररी स्थापित केली असल्याची खात्री करा: + +``` +pip install web3 +``` + +```python +from web3 import Web3 + + +w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) + +dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI +weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH) + +acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2 + +# This is a simplified Contract Application Binary Interface (ABI) of an ERC-20 Token Contract. +# It will expose only the methods: balanceOf(address), decimals(), symbol() and totalSupply() +simplified_abi = [ + { + 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}], + 'name': 'balanceOf', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'decimals', + 'outputs': [{'internalType': 'uint8', 'name': '', 'type': 'uint8'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'symbol', + 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'totalSupply', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + } +] + +dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi) +symbol = dai_contract.functions.symbol().call() +decimals = dai_contract.functions.decimals().call() +totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals +addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals + +# DAI +print("===== %s =====" % symbol) +print("Total Supply:", totalSupply) +print("Addr Balance:", addr_balance) + +weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi) +symbol = weth_contract.functions.symbol().call() +decimals = weth_contract.functions.decimals().call() +totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals +addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals + +# WETH +print("===== %s =====" % symbol) +print("Total Supply:", totalSupply) +print("Addr Balance:", addr_balance) +``` + +## ज्ञात समस्या {#erc20-issues} + +### ERC-20 टोकन स्वीकृतीची समस्या {#reception-issue} + +**06/20/2024 पर्यंत, या समस्येमुळे किमान $83,656,418 किमतीचे ERC-20 टोकन गमावले गेले आहेत. लक्षात घ्या की शुद्ध ERC-20 अंमलबजावणी या समस्येस बळी पडू शकते, जोपर्यंत तुम्ही खाली सूचीबद्ध केल्यानुसार मानकाच्या वर अतिरिक्त निर्बंधांचा संच लागू करत नाही.** + +जेव्हा ERC-20 टोकन्स अशा स्मार्ट कॉन्ट्रॅक्टला पाठवले जातात जे ERC-20 टोकन्स हाताळण्यासाठी डिझाइन केलेले नाहीत, तेव्हा ते टोकन्स कायमचे गमावले जाऊ शकतात. हे घडते कारण प्राप्त करणाऱ्या कॉन्ट्रॅक्टमध्ये येणाऱ्या टोकन्सना ओळखण्याची किंवा प्रतिसाद देण्याची कार्यक्षमता नसते आणि ERC-20 मानकामध्ये प्राप्त करणाऱ्या कॉन्ट्रॅक्टला येणाऱ्या टोकन्सबद्दल सूचित करण्याची कोणतीही यंत्रणा नसते. ही समस्या मुख्यत्वे खालील मार्गांनी स्वरूप घेते: + +1. टोकन हस्तांतरण यंत्रणा + +- ERC-20 टोकन transfer किंवा transferFrom फंक्शन्स वापरून हस्तांतरित केले जातात + - जेव्हा एखादा वापरकर्ता या फंक्शन्सचा वापर करून कॉन्ट्रॅक्ट पत्त्यावर टोकन पाठवतो, तेव्हा प्राप्त करणारा कॉन्ट्रॅक्ट ते हाताळण्यासाठी डिझाइन केलेला आहे की नाही याची पर्वा न करता टोकन हस्तांतरित केले जातात + +2. सूचनेचा अभाव + - प्राप्त करणाऱ्या कॉन्ट्रॅक्टला टोकन पाठवले गेल्याची सूचना किंवा कॉलबॅक मिळत नाही + - जर प्राप्त करणाऱ्या कॉन्ट्रॅक्टमध्ये टोकन हाताळण्यासाठी यंत्रणेचा अभाव असेल (उदा. फॉलबॅक फंक्शन किंवा टोकन स्वीकृती व्यवस्थापित करण्यासाठी एक समर्पित फंक्शन), तर टोकन प्रभावीपणे कॉन्ट्रॅक्टच्या पत्त्यावर अडकून पडतात +3. अंगभूत हाताळणी नाही + - ERC-20 मानकामध्ये प्राप्त करणाऱ्या कॉन्ट्रॅक्ट्ससाठी लागू करण्यासाठी कोणतेही अनिवार्य फंक्शन समाविष्ट नाही, ज्यामुळे अनेक कॉन्ट्रॅक्ट्स येणाऱ्या टोकन्सचे योग्यरित्या व्यवस्थापन करण्यास असमर्थ ठरतात + +**संभाव्य उपाय** + +जरी ERC-20 सह ही समस्या पूर्णपणे टाळणे शक्य नसले तरी, अशा पद्धती आहेत ज्यामुळे अंतिम वापरकर्त्यासाठी टोकन गमावण्याची शक्यता लक्षणीयरीत्या कमी होऊ शकते: + +- सर्वात सामान्य समस्या म्हणजे जेव्हा वापरकर्ता टोकन कॉन्ट्रॅक्टच्या पत्त्यावरच टोकन पाठवतो (उदा. USDT टोकन कॉन्ट्रॅक्टच्या पत्त्यावर जमा केलेले USDT). अशा हस्तांतरणाच्या प्रयत्नांना परत फिरवण्यासाठी `transfer(..)` फंक्शन प्रतिबंधित करण्याची शिफारस केली जाते. `transfer(..)` फंक्शनच्या अंमलबजावणीमध्ये `require(_to != address(this));` तपासणी जोडण्याचा विचार करा. +- `transfer(..)` फंक्शन सर्वसाधारणपणे कॉन्ट्रॅक्ट्समध्ये टोकन जमा करण्यासाठी डिझाइन केलेले नाही. `approve(..) आणि transferFrom(..)` पॅटर्नचा वापर त्याऐवजी ERC-20 टोकन कॉन्ट्रॅक्ट्समध्ये जमा करण्यासाठी केला जातो. ट्रान्सफर फंक्शनला कोणत्याही कॉन्ट्रॅक्टमध्ये टोकन जमा करण्यास मनाई करण्यासाठी प्रतिबंधित करणे शक्य आहे, तथापि ते `trasnfer(..)` फंक्शनसह कॉन्ट्रॅक्टमध्ये टोकन जमा केले जाऊ शकतात असे गृहीत धरणाऱ्या कॉन्ट्रॅक्ट्ससह (उदा. Uniswap लिक्विडिटी पूल्स) सुसंगतता खंडित करू शकते. +- तुमच्या कॉन्ट्रॅक्टला कधीही कोणतेही टोकन मिळणे अपेक्षित नसले तरी, ERC-20 टोकन तुमच्या कॉन्ट्रॅक्टमध्ये येऊ शकतात असे नेहमी गृहीत धरा. प्राप्तकर्त्याच्या बाजूने अपघाती ठेवी रोखण्याचा किंवा नाकारण्याचा कोणताही मार्ग नाही. असे फंक्शन लागू करण्याची शिफारस केली जाते जे अपघाताने जमा केलेले ERC-20 टोकन काढण्यास अनुमती देईल. +- वैकल्पिक टोकन मानके वापरण्याचा विचार करा. + +या समस्येतून काही पर्यायी मानके समोर आली आहेत जसे की [ERC-223](/developers/docs/standards/tokens/erc-223) किंवा [ERC-1363](/developers/docs/standards/tokens/erc-1363). + +## पुढील वाचन {#further-reading} + +- [EIP-20: ERC-20 टोकन मानक](https://eips.ethereum.org/EIPS/eip-20) +- [OpenZeppelin - टोकन्स](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20) +- [OpenZeppelin - ERC-20 अंमलबजावणी](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) +- [Alchemy - Solidity ERC20 टोकन्ससाठी मार्गदर्शक](https://www.alchemy.com/overviews/erc20-solidity) + +## इतर फंजिबल टोकन मानके {#fungible-token-standards} + +- [ERC-223](/developers/docs/standards/tokens/erc-223) +- [ERC-1363](/developers/docs/standards/tokens/erc-1363) +- [ERC-777](/developers/docs/standards/tokens/erc-777) +- [ERC-4626 - टोकनाइज्ड वॉल्ट्स](/developers/docs/standards/tokens/erc-4626) diff --git a/public/content/translations/mr/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/mr/developers/docs/standards/tokens/erc-223/index.md new file mode 100644 index 00000000000..af0afee3cc3 --- /dev/null +++ b/public/content/translations/mr/developers/docs/standards/tokens/erc-223/index.md @@ -0,0 +1,198 @@ +--- +title: "ERC-223 टोकन मानक" +description: "ERC-223 फंजिबल टोकन मानकाचा आढावा, ते कसे कार्य करते, आणि ERC-20 शी तुलना." +lang: mr +--- + +## प्रस्तावना {#introduction} + +### ERC-223 म्हणजे काय? {#what-is-erc223} + +ERC-223 हे ERC-20 मानकासारखेच फंजिबल टोकन्ससाठी एक मानक आहे. मुख्य फरक हा आहे की ERC-223 केवळ टोकन API परिभाषित करत नाही, तर प्रेषकाकडून प्राप्तकर्त्याकडे टोकन हस्तांतरित करण्याची तर्कप्रणाली देखील परिभाषित करते. हे एक संवाद मॉडेल सादर करते जे प्राप्तकर्त्याच्या बाजूने टोकन हस्तांतरण हाताळण्याची परवानगी देते. + +### ERC-20 मधील फरक {#erc20-differences} + +ERC-223 हे ERC-20 च्या काही मर्यादा दूर करते आणि टोकन कॉन्ट्रॅक्ट व टोकन प्राप्त करू शकणाऱ्या कॉन्ट्रॅक्टमध्ये संवादाची एक नवीन पद्धत सादर करते. ERC-223 मध्ये काही गोष्टी शक्य आहेत, पण ERC-20 मध्ये नाहीत: + +- प्राप्तकर्त्याच्या बाजूने टोकन हस्तांतरण हाताळणी: प्राप्तकर्ते हे ओळखू शकतात की ERC-223 टोकन जमा केले जात आहे. +- अयोग्यरित्या पाठवलेले टोकन नाकारणे: जर वापरकर्त्याने ERC-223 टोकन अशा कॉन्ट्रॅक्टला पाठवले जे टोकन स्वीकारण्यासाठी बनवलेले नाही, तर ते कॉन्ट्रॅक्ट व्यवहार नाकारू शकते, ज्यामुळे टोकनचे नुकसान टळते. +- हस्तांतरणामध्ये मेटाडेटा: ERC-223 टोकन्समध्ये मेटाडेटा समाविष्ट असू शकतो, ज्यामुळे टोकन व्यवहारांशी कोणतीही माहिती जोडता येते. + +## पूर्वतयारी {#prerequisites} + +- [खाती](/developers/docs/accounts) +- [स्मार्ट कॉन्ट्रॅक्ट्स](/developers/docs/smart-contracts/) +- [टोकन मानके](/developers/docs/standards/tokens/) +- [ERC-20](/developers/docs/standards/tokens/erc-20/) + +## मुख्य भाग {#body} + +ERC-223 हे एक टोकन मानक आहे जे स्मार्ट कॉन्ट्रॅक्ट्समधील टोकन्ससाठी एक API लागू करते. हे ERC-223 टोकन स्वीकारणाऱ्या कॉन्ट्रॅक्ट्ससाठी एक API देखील घोषित करते. जे कॉन्ट्रॅक्ट ERC-223 रिसीव्हर API ला समर्थन देत नाहीत ते ERC-223 टोकन स्वीकारू शकत नाहीत, ज्यामुळे वापरकर्त्याच्या चुका टाळता येतात. + +जर एखादे स्मार्ट कॉन्ट्रॅक्ट खालील पद्धती आणि इव्हेंट्स लागू करत असेल तर त्याला ERC-223 सुसंगत टोकन कॉन्ट्रॅक्ट म्हटले जाऊ शकते. एकदा तैनात झाल्यावर, +ते इथेरियमवर तयार केलेल्या टोकन्सचा मागोवा ठेवण्यास जबाबदार असेल. + +कॉन्ट्रॅक्टमध्ये केवळ ही फंक्शन्स असणे बंधनकारक नाही आणि एक डेव्हलपर विविध टोकन मानकांमधून या कॉन्ट्रॅक्टमध्ये इतर कोणतीही वैशिष्ट्ये जोडू शकतो. उदाहरणार्थ, `approve` आणि `transferFrom` फंक्शन्स ERC-223 मानकाचा भाग नाहीत, परंतु आवश्यक असल्यास ही फंक्शन्स लागू केली जाऊ शकतात. + +[EIP-223](https://eips.ethereum.org/EIPS/eip-223) मधून: + +### मेथड्स {#methods} + +ERC-223 टोकनने खालील पद्धती लागू केल्या पाहिजेत: + +```solidity +function name() public view returns (string) +function symbol() public view returns (string) +function decimals() public view returns (uint8) +function totalSupply() public view returns (uint256) +function balanceOf(address _owner) public view returns (uint256 balance) +function transfer(address _to, uint256 _value) public returns (bool success) +function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success) +``` + +ERC-223 टोकन स्वीकारणाऱ्या कॉन्ट्रॅक्टने खालील पद्धत लागू करणे आवश्यक आहे: + +```solidity +function tokenReceived(address _from, uint _value, bytes calldata _data) +``` + +जर ERC-223 टोकन्स `tokenReceived(..)` फंक्शन लागू न करणाऱ्या कॉन्ट्रॅक्टला पाठवले गेले, तर हस्तांतरण अयशस्वी झाले पाहिजे आणि टोकन्स प्रेषकाच्या बॅलन्समधून हलवले जाऊ नयेत. + +### इव्हेंट्स {#events} + +```solidity +event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes calldata _data) +``` + +### उदाहरणे {#examples} + +ERC-223 टोकनचा API हा ERC-20 सारखाच आहे, त्यामुळे UI डेव्हलपमेंटच्या दृष्टिकोनातून कोणताही फरक नाही. येथे एकमेव अपवाद हा आहे की ERC-223 टोकनमध्ये `approve` + `transferFrom` फंक्शन्स असू शकत नाहीत कारण या मानकासाठी ते ऐच्छिक आहेत. + +#### Solidity उदाहरणे {#solidity-example} + +खालील उदाहरण स्पष्ट करते की एक मूलभूत ERC-223 टोकन कॉन्ट्रॅक्ट कसे कार्य करते: + +```solidity +pragma solidity ^0.8.19; +abstract contract IERC223Recipient { + function tokenReceived(address _from, uint _value, bytes memory _data) public virtual; +} +contract VeryBasicERC223Token { + event Transfer(address indexed from, address indexed to, uint value, bytes data); + string private _name; + string private _symbol; + uint8 private _decimals; + uint256 private _totalSupply; + mapping(address => uint256) private balances; + function name() public view returns (string memory) { return _name; } + function symbol() public view returns (string memory) {return _symbol; } + function decimals() public view returns (uint8) { return _decimals; } + function totalSupply() public view returns (uint256) { return _totalSupply; } + function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; } + function isContract(address account) internal view returns (bool) { + uint256 size; + assembly { size := extcodesize(account) } + return size > 0; + } + function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success){ + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data); + } + emit Transfer(msg.sender, _to, _value, _data); + return true; + } + function transfer(address _to, uint _value) public returns (bool success){ + bytes memory _empty = hex"00000000"; + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty); + } + emit Transfer(msg.sender, _to, _value, _empty); + return true; + } +} +``` + +आता आपल्याला `tokenA` च्या ठेवी स्वीकारण्यासाठी दुसरा कॉन्ट्रॅक्ट हवा आहे, हे गृहीत धरून की tokenA हे ERC-223 टोकन आहे. कॉन्ट्रॅक्टने फक्त tokenA स्वीकारले पाहिजे आणि इतर कोणतेही टोकन नाकारले पाहिजेत. जेव्हा कॉन्ट्रॅक्टला tokenA प्राप्त होईल, तेव्हा त्याने `Deposit()` इव्हेंट उत्सर्जित केला पाहिजे आणि अंतर्गत `deposits` व्हेरिएबलचे मूल्य वाढवले पाहिजे. + +येथे कोड आहे: + +```solidity +contract RecipientContract is IERC223Recipient { + event Deposit(address whoSentTheTokens); + uint256 deposits = 0; + address tokenA; // The only token that we want to accept. + function tokenReceived(address _from, uint _value, bytes memory _data) public override + { + // It is important to understand that within this function + // msg.sender is the address of a token that is being received, + // msg.value is always 0 as the token contract does not own or send ether in most cases, + // _from is the sender of the token transfer, + // _value is the amount of tokens that was deposited. + require(msg.sender == tokenA); + deposits += _value; + emit Deposit(_from); + } +} +``` + +## वारंवार विचारले जाणारे प्रश्न {#faq} + +### जर आपण काही tokenB कॉन्ट्रॅक्टला पाठवले तर काय होईल? {#sending-tokens} + +व्यवहार अयशस्वी होईल आणि टोकनचे हस्तांतरण होणार नाही. टोकन प्रेषकाच्या पत्त्यावर परत केले जातील. + +### आपण या कॉन्ट्रॅक्टमध्ये ठेव कशी करू शकतो? {#contract-deposits} + +ERC-223 टोकनचे `transfer(address,uint256)` किंवा `transfer(address,uint256,bytes)` फंक्शन कॉल करा, `RecipientContract` चा पत्ता निर्दिष्ट करून. + +### जर आपण या कॉन्ट्रॅक्टला ERC-20 टोकन हस्तांतरित केले तर काय होईल? {#erc-20-transfers} + +जर `RecipientContract` ला ERC-20 टोकन पाठवले, तर टोकन हस्तांतरित होतील, परंतु हस्तांतरण ओळखले जाणार नाही (कोणताही `Deposit()` इव्हेंट फायर होणार नाही, आणि ठेवींचे मूल्य बदलणार नाही). अनावश्यक ERC-20 ठेवी फिल्टर किंवा प्रतिबंधित केल्या जाऊ शकत नाहीत. + +### टोकन ठेव पूर्ण झाल्यानंतर आपल्याला एखादे फंक्शन कार्यान्वित करायचे असेल तर काय? {#function-execution} + +असे करण्याचे अनेक मार्ग आहेत. या उदाहरणात आपण ती पद्धत वापरू जी ERC-223 हस्तांतरणांना ईथर हस्तांतरणांसारखेच बनवते: + +```solidity +contract RecipientContract is IERC223Recipient { + event Foo(); + event Bar(uint256 someNumber); + address tokenA; // The only token that we want to accept. + function tokenReceived(address _from, uint _value, bytes memory _data) public override + { + require(msg.sender == tokenA); + address(this).call(_data); // Handle incoming transaction and perform a subsequent function call. + } + function foo() public + { + emit Foo(); + } + function bar(uint256 _someNumber) public + { + emit Bar(_someNumber); + } +} +``` + +जेव्हा `RecipientContract` ला ERC-223 टोकन प्राप्त होईल, तेव्हा कॉन्ट्रॅक्ट टोकन व्यवहाराच्या `_data` पॅरामीटर म्हणून एन्कोड केलेले एक फंक्शन कार्यान्वित करेल, अगदी त्याचप्रमाणे जसे ईथर व्यवहार फंक्शन कॉल्सना व्यवहार `data` म्हणून एन्कोड करतात. अधिक माहितीसाठी [डेटा फील्ड](/developers/docs/transactions/#the-data-field) वाचा. + +वरील उदाहरणामध्ये, `transfer(address,uin256,bytes calldata _data)` फंक्शन वापरून `RecipientContract` च्या पत्त्यावर ERC-223 टोकन हस्तांतरित केले जाणे आवश्यक आहे. जर डेटा पॅरामीटर `0xc2985578` (`foo()` फंक्शनची स्वाक्षरी) असेल, तर टोकन ठेव प्राप्त झाल्यानंतर foo() फंक्शन कॉल केले जाईल आणि Foo() इव्हेंट फायर होईल. + +टोकन हस्तांतरणाच्या `data` मध्ये पॅरामीटर्स देखील एन्कोड केले जाऊ शकतात, उदाहरणार्थ आपण `_someNumber` साठी 12345 मूल्याने bar() फंक्शन कॉल करू शकतो. या प्रकरणात `data` हा `0x0423a13200000000000000000000000000000000000000000000000000000000000004d2` असावा, जिथे `0x0423a132` ही `bar(uint256)` फंक्शनची स्वाक्षरी आहे आणि `00000000000000000000000000000000000000000000000000000000000004d2` हे uint256 म्हणून 12345 आहे. + +## मर्यादा {#limitations} + +जरी ERC-223 हे ERC-20 मानकात आढळलेल्या अनेक समस्यांचे निराकरण करते, तरी त्याच्या स्वतःच्या काही मर्यादा आहेत: + +- स्वीकृती आणि सुसंगतता: ERC-223 अद्याप व्यापकपणे स्वीकारले गेले नाही, जे विद्यमान टूल्स आणि प्लॅटफॉर्मसह त्याची सुसंगतता मर्यादित करू शकते. +- मागील आवृत्तीशी सुसंगतता: ERC-223 हे ERC-20 सोबत बॅकवर्ड सुसंगत नाही, याचा अर्थ असा की विद्यमान ERC-20 कॉन्ट्रॅक्ट्स आणि टूल्स बदलांशिवाय ERC-223 टोकन्ससोबत काम करणार नाहीत. +- गॅस खर्च: ERC-223 हस्तांतरणातील अतिरिक्त तपासण्या आणि कार्यक्षमतेमुळे ERC-20 व्यवहारांच्या तुलनेत गॅसचा खर्च जास्त येऊ शकतो. + +## पुढील वाचन {#further-reading} + +- [EIP-223: ERC-223 टोकन मानक](https://eips.ethereum.org/EIPS/eip-223) +- [सुरुवातीचा ERC-223 प्रस्ताव](https://github.com/ethereum/eips/issues/223) diff --git a/public/content/translations/mr/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/mr/developers/docs/standards/tokens/erc-4626/index.md new file mode 100644 index 00000000000..666e96b113e --- /dev/null +++ b/public/content/translations/mr/developers/docs/standards/tokens/erc-4626/index.md @@ -0,0 +1,227 @@ +--- +title: "ERC-4626 टोकनाइज्ड वॉल्ट स्टँडर्ड" +description: "उत्पन्न देणाऱ्या वॉल्ट्ससाठी एक मानक." +lang: mr +--- + +## प्रस्तावना {#introduction} + +ERC-4626 हे उत्पन्न देणाऱ्या वॉल्ट्सचे तांत्रिक पॅरामीटर्स ऑप्टिमाइझ आणि एकीकृत करण्यासाठी एक मानक आहे. हे टोकनाइज्ड उत्पन्न-देणाऱ्या वॉल्ट्ससाठी एक मानक API प्रदान करते जे एकाच मूळ ERC-20 टोकनच्या शेअर्सचे प्रतिनिधित्व करतात. ERC-4626 ERC-20 वापरणाऱ्या टोकनाइज्ड वॉल्ट्ससाठी एक पर्यायी विस्तार देखील दर्शवते, जे टोकन जमा करण्यासाठी, काढण्यासाठी आणि शिल्लक वाचण्यासाठी मूलभूत कार्यक्षमता प्रदान करते. + +**उत्पन्न देणाऱ्या वॉल्ट्समध्ये ERC-4626 ची भूमिका** + +लेंडिंग मार्केट्स, एग्रीगेटर्स, आणि स्वाभाविकपणे व्याज-देणारे टोकन वापरकर्त्यांना त्यांच्या क्रिप्टो टोकनवर सर्वोत्तम उत्पन्न शोधण्यात वेगवेगळ्या स्ट्रॅटेजीस कार्यान्वित करून मदत करतात. या स्ट्रॅटेजीस थोड्या फरकाने केल्या जातात, ज्यामुळे चुका होण्याची शक्यता असते किंवा डेव्हलपमेंट संसाधने वाया जातात. + +उत्पन्न-देणाऱ्या वॉल्ट्समधील ERC-4626 अधिक सुसंगत आणि मजबूत अंमलबजावणी पॅटर्न तयार करून डेव्हलपर्सकडून कमी विशेष प्रयत्नांसह एकत्रीकरण प्रयत्न कमी करेल आणि विविध ॲप्लिकेशन्समध्ये उत्पन्नाचा ॲक्सेस अनलॉक करेल. + +ERC-4626 टोकनचे संपूर्ण वर्णन [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626) मध्ये केले आहे. + +**असिंक्रोनस वॉल्ट विस्तार (ERC-7540)** + +ERC-4626 एका मर्यादेपर्यंत ॲटॉमिक डिपॉझिट आणि रिडेम्प्शनसाठी ऑप्टिमाइझ केलेले आहे. जर मर्यादा गाठली गेली, तर कोणतेही नवीन डिपॉझिट किंवा रिडेम्प्शन सबमिट केले जाऊ शकत नाहीत. ही मर्यादा कोणत्याही स्मार्ट कॉन्ट्रॅक्ट सिस्टीमसाठी योग्यरित्या काम करत नाही, ज्यात वॉल्टसोबत इंटरफेस करण्यासाठी पूर्वअट म्हणून असिंक्रोनस क्रिया किंवा विलंब असतो (उदा., वास्तविक-जगातील मालमत्ता प्रोटोकॉल, अंडरकोलॅटरलाइज्ड लेंडिंग प्रोटोकॉल, क्रॉस-चेन लेंडिंग प्रोटोकॉल, लिक्विड स्टेकिंग टोकन, किंवा विमा सुरक्षा मॉड्यूल). + +ERC-7540 असिंक्रोनस वापराच्या प्रकरणांसाठी ERC-4626 वॉल्ट्सची उपयोगिता वाढवते. विद्यमान वॉल्ट इंटरफेस (`deposit`/`withdraw`/`mint`/`redeem`) असिंक्रोनस रिक्वेस्ट्सवर दावा करण्यासाठी पूर्णपणे वापरला जातो. + +ERC-7540 विस्ताराचे संपूर्ण वर्णन [ERC-7540](https://eips.ethereum.org/EIPS/eip-7540) मध्ये केले आहे. + +**बहु-मालमत्ता वॉल्ट विस्तार (ERC-7575)** + +एक गहाळ वापर प्रकरण जे ERC-4626 द्वारे समर्थित नाही ते असे वॉल्ट्स आहेत ज्यात लिक्विडिटी प्रोव्हायडर (LP) टोकनसारख्या अनेक मालमत्ता किंवा एंट्री पॉइंट्स आहेत. ERC-4626 स्वतः एक ERC-20 असण्याच्या आवश्यकतेमुळे हे साधारणपणे अवजड किंवा गैर-अनुपालक असतात. + +ERC-7575, ERC-4626 अंमलबजावणीतून ERC-20 टोकन अंमलबजावणीला बाह्य करून अनेक मालमत्ता असलेल्या वॉल्ट्ससाठी समर्थन जोडते. + +ERC-7575 विस्ताराचे संपूर्ण वर्णन [ERC-7575](https://eips.ethereum.org/EIPS/eip-7575) मध्ये केले आहे. + +## पूर्वतयारी {#prerequisites} + +हे पृष्ठ अधिक चांगल्या प्रकारे समजून घेण्यासाठी, आम्ही शिफारस करतो की तुम्ही आधी [टोकन मानक](/developers/docs/standards/tokens/) आणि [ERC-20](/developers/docs/standards/tokens/erc-20/) बद्दल वाचा. + +## ERC-4626 कार्ये आणि वैशिष्ट्ये: {#body} + +### मेथड्स {#methods} + +#### ॲसेट {#asset} + +```solidity +function asset() public view returns (address assetTokenAddress) +``` + +हे फंक्शन वॉल्टसाठी अकाउंटिंग, डिपॉझिटिंग, विथड्रॉइंगसाठी वापरल्या जाणाऱ्या मूळ टोकनचा ॲड्रेस परत करते. + +#### एकूण ॲसेट्स {#totalassets} + +```solidity +function totalAssets() public view returns (uint256) +``` + +हे फंक्शन वॉल्टमध्ये ठेवलेल्या मूळ ॲसेट्सची एकूण रक्कम परत करते. + +#### शेअर्समध्ये रूपांतरित करा {#convertoshares} + +```solidity +function convertToShares(uint256 assets) public view returns (uint256 shares) +``` + +हे फंक्शन `shares` ची रक्कम परत करते जी प्रदान केलेल्या `assets` च्या रकमेसाठी वॉल्टद्वारे एक्सचेंज केली जाईल. + +#### ॲसेट्समध्ये रूपांतरित करा {#convertoassets} + +```solidity +function convertToAssets(uint256 shares) public view returns (uint256 assets) +``` + +हे फंक्शन `assets` ची रक्कम परत करते जी प्रदान केलेल्या `shares` च्या रकमेसाठी वॉल्टद्वारे एक्सचेंज केली जाईल. + +#### कमाल डिपॉझिट {#maxdeposit} + +```solidity +function maxDeposit(address receiver) public view returns (uint256 maxAssets) +``` + +हे फंक्शन मूळ ॲसेट्सची कमाल रक्कम परत करते जी एकाच [`deposit`](#deposit) कॉलमध्ये जमा केली जाऊ शकते, ज्यात `receiver` साठी शेअर्स मिंट केले जातात. + +#### डिपॉझिटचे पूर्वावलोकन {#previewdeposit} + +```solidity +function previewDeposit(uint256 assets) public view returns (uint256 shares) +``` + +हे फंक्शन वापरकर्त्यांना सध्याच्या ब्लॉकवर त्यांच्या डिपॉझिटच्या परिणामांचे सिम्युलेशन करण्याची परवानगी देते. + +#### डिपॉझिट {#deposit} + +```solidity +function deposit(uint256 assets, address receiver) public returns (uint256 shares) +``` + +हे फंक्शन मूळ टोकनचे `assets` वॉल्टमध्ये जमा करते आणि `receiver` ला `shares` ची मालकी देते. + +#### कमाल मिंट {#maxmint} + +```solidity +function maxMint(address receiver) public view returns (uint256 maxShares) +``` + +हे फंक्शन शेअर्सची कमाल रक्कम परत करते जी एकाच [`mint`](#mint) कॉलमध्ये मिंट केली जाऊ शकते, ज्यात `receiver` साठी शेअर्स मिंट केले जातात. + +#### मिंटचे पूर्वावलोकन {#previewmint} + +```solidity +function previewMint(uint256 shares) public view returns (uint256 assets) +``` + +हे फंक्शन वापरकर्त्यांना सध्याच्या ब्लॉकवर त्यांच्या मिंटच्या परिणामांचे सिम्युलेशन करण्याची परवानगी देते. + +#### मिंट {#mint} + +```solidity +function mint(uint256 shares, address receiver) public returns (uint256 assets) +``` + +हे फंक्शन मूळ टोकनचे `assets` जमा करून `receiver` ला तंतोतंत `shares` वॉल्ट शेअर्स मिंट करते. + +#### कमाल विथड्रॉ {#maxwithdraw} + +```solidity +function maxWithdraw(address owner) public view returns (uint256 maxAssets) +``` + +हे फंक्शन मूळ ॲसेट्सची कमाल रक्कम परत करते जी `owner` च्या बॅलन्समधून एकाच [`withdraw`](#withdraw) कॉलने काढली जाऊ शकते. + +#### विथड्रॉचे पूर्वावलोकन {#previewwithdraw} + +```solidity +function previewWithdraw(uint256 assets) public view returns (uint256 shares) +``` + +हे फंक्शन वापरकर्त्यांना सध्याच्या ब्लॉकवर त्यांच्या विथड्रॉवलच्या परिणामांचे सिम्युलेशन करण्याची परवानगी देते. + +#### विथड्रॉ {#withdraw} + +```solidity +function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares) +``` + +हे फंक्शन `owner` कडून `shares` बर्न करते आणि वॉल्टमधून तंतोतंत `assets` टोकन `receiver` ला पाठवते. + +#### कमाल रिडीम {#maxredeem} + +```solidity +function maxRedeem(address owner) public view returns (uint256 maxShares) +``` + +हे फंक्शन शेअर्सची कमाल रक्कम परत करते जी `owner` च्या बॅलन्समधून [`redeem`](#redeem) कॉलद्वारे रिडीम केली जाऊ शकते. + +#### रिडीमचे पूर्वावलोकन {#previewredeem} + +```solidity +function previewRedeem(uint256 shares) public view returns (uint256 assets) +``` + +हे फंक्शन वापरकर्त्यांना सध्याच्या ब्लॉकवर त्यांच्या रिडेम्पशनच्या परिणामांचे सिम्युलेशन करण्याची परवानगी देते. + +#### रिडीम {#redeem} + +```solidity +function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets) +``` + +हे फंक्शन `owner` कडून विशिष्ट संख्येचे `shares` रिडीम करते आणि वॉल्टमधून `receiver` ला मूळ टोकनचे `assets` पाठवते. + +#### एकूण पुरवठा {#totalsupply} + +```solidity +function totalSupply() public view returns (uint256) +``` + +वापरात असलेल्या, न रिडीम केलेल्या वॉल्ट शेअर्सची एकूण संख्या परत करते. + +#### शिल्लक {#balanceof} + +```solidity +function balanceOf(address owner) public view returns (uint256) +``` + +`owner` कडे सध्या असलेल्या वॉल्ट शेअर्सची एकूण रक्कम परत करते. + +### इंटरफेसचा नकाशा {#mapOfTheInterface} + +![ERC-4626 इंटरफेसचा नकाशा](./map-of-erc-4626.png) + +### इव्हेंट्स {#events} + +#### डिपॉझिट इव्हेंट + +[`mint`](#mint) आणि [`deposit`](#deposit) मेथड्सद्वारे जेव्हा टोकन वॉल्टमध्ये जमा केले जातात तेव्हा **अवश्य** उत्सर्जित केले पाहिजे. + +```solidity +event Deposit( + address indexed sender, + address indexed owner, + uint256 assets, + uint256 shares +) +``` + +जिथे `sender` हा वापरकर्ता आहे ज्याने `shares` साठी `assets` एक्सचेंज केले, आणि ते `shares` `owner` ला हस्तांतरित केले. + +#### विथड्रॉ इव्हेंट + +[`redeem`](#redeem) किंवा [`withdraw`](#withdraw) मेथड्समध्ये जेव्हा ठेवीदाराद्वारे वॉल्टमधून शेअर्स काढले जातात तेव्हा **अवश्य** उत्सर्जित केले पाहिजे. + +```solidity +event Withdraw( + address indexed sender, + address indexed receiver, + address indexed owner, + uint256 assets, + uint256 shares +) +``` + +जिथे `sender` हा वापरकर्ता आहे ज्याने विथड्रॉवल सुरू केले आणि `owner` च्या मालकीचे `shares` `assets` साठी एक्सचेंज केले. `receiver` हा वापरकर्ता आहे ज्याला काढलेले `assets` मिळाले. + +## पुढील वाचन {#further-reading} + +- [EIP-4626: टोकनाइज्ड वॉल्ट स्टँडर्ड](https://eips.ethereum.org/EIPS/eip-4626) +- [ERC-4626: GitHub रेपो](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol) diff --git a/public/content/translations/mr/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/mr/developers/docs/standards/tokens/erc-721/index.md new file mode 100644 index 00000000000..6af9ba71fed --- /dev/null +++ b/public/content/translations/mr/developers/docs/standards/tokens/erc-721/index.md @@ -0,0 +1,261 @@ +--- +title: "ERC-721 नॉन-फंजिबल टोकन मानक" +description: "ERC-721 बद्दल जाणून घ्या, जे Ethereum वरील युनिक डिजिटल मालमत्तेचे प्रतिनिधित्व करणाऱ्या नॉन-फंजिबल टोकन (NFTs) साठी एक मानक आहे." +lang: mr +--- + +## प्रस्तावना {#introduction} + +**नॉन-फंजिबल टोकन म्हणजे काय?** + +नॉन-फंजिबल टोकन (NFT) हे काहीतरी किंवा कोणालातरी अद्वितीय पद्धतीने ओळखण्यासाठी वापरले जाते. हे टोकन संग्रहणीय वस्तू, ॲक्सेस की, लॉटरीची तिकिटे, कॉन्सर्ट आणि क्रीडा सामन्यांसाठी क्रमांकित जागा इत्यादी देणाऱ्या प्लॅटफॉर्मवर वापरण्यासाठी योग्य आहे. या विशेष प्रकारच्या टोकनमध्ये अद्भूत शक्यता आहेत, त्यामुळे ते एका योग्य मानकास पात्र आहे, आणि ERC-721 +हेच निराकरण करण्यासाठी आले आहे! + +**ERC-721 म्हणजे काय?** + +ERC-721 हे NFT साठी एक मानक सादर करते, दुसऱ्या शब्दांत, या प्रकारचे टोकन अद्वितीय असते आणि त्याचे मूल्य त्याच स्मार्ट कॉन्ट्रॅक्टमधील दुसऱ्या टोकनपेक्षा वेगळे असू शकते, +kदाचित त्याचे वय, दुर्मिळता किंवा अगदी त्याच्या व्हिज्युअलसारख्या इतर गोष्टींमुळे. +थांबा, व्हिज्युअल? + +होय! सर्व NFTs मध्ये `tokenId` नावाचे `uint256` व्हेरिएबल असते, म्हणून कोणत्याही ERC-721 कॉन्ट्रॅक्टसाठी, `contract address, uint256 tokenId` ही जोडी +जागतिक स्तरावर अद्वितीय असणे आवश्यक आहे. असे असले तरी, एका dApp मध्ये एक "कन्व्हर्टर" असू शकतो जो +`tokenId` इनपुट म्हणून वापरतो आणि झोम्बी, शस्त्रे, कौशल्ये किंवा आश्चर्यकारक किटीजसारख्या छान गोष्टीची इमेज आउटपुट करतो! + +## पूर्वतयारी {#prerequisites} + +- [खाती](/developers/docs/accounts/) +- [स्मार्ट कॉन्ट्रॅक्ट्स](/developers/docs/smart-contracts/) +- [टोकन मानके](/developers/docs/standards/tokens/) + +## मुख्य भाग {#body} + +जानेवारी 2018 मध्ये विल्यम एंट्रिंकन, डायटर शिर्ले, जेकब इव्हान्स, +नास्तासिया सॅक्स यांनी प्रस्तावित केलेले ERC-721 (Ethereum रिक्वेस्ट फॉर कमेंट्स 721), हे एक नॉन-फंजिबल टोकन मानक आहे जे स्मार्ट कॉन्ट्रॅक्ट्समधील टोकन्ससाठी API लागू करते. + +हे एका खात्यातून दुसऱ्या खात्यात टोकन हस्तांतरित करणे, खात्यातील सध्याची टोकन शिल्लक मिळवणे, +एका विशिष्ट टोकनचा मालक मिळवणे आणि नेटवर्कवर उपलब्ध असलेल्या टोकनचा एकूण पुरवठा मिळवणे यासारख्या कार्यक्षमता प्रदान करते. +या व्यतिरिक्त, यात इतर काही कार्यक्षमता आहेत, जसे की एखाद्या खात्यातून टोकनची रक्कम तृतीय-पक्ष खात्याद्वारे +हलवली जाऊ शकते याला मान्यता देणे. + +जर एखादा स्मार्ट कॉन्ट्रॅक्ट खालील पद्धती आणि इव्हेंट्स लागू करत असेल तर त्याला ERC-721 नॉन-फंजिबल टोकन कॉन्ट्रॅक्ट म्हटले जाऊ शकते +आणि, एकदा तैनात केल्यावर, ते Ethereum वर तयार केलेल्या टोकनचा मागोवा ठेवण्यासाठी जबाबदार असेल. + +[EIP-721](https://eips.ethereum.org/EIPS/eip-721) मधून: + +### मेथड्स {#methods} + +```solidity + function balanceOf(address _owner) external view returns (uint256); + function ownerOf(uint256 _tokenId) external view returns (address); + function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable; + function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable; + function transferFrom(address _from, address _to, uint256 _tokenId) external payable; + function approve(address _approved, uint256 _tokenId) external payable; + function setApprovalForAll(address _operator, bool _approved) external; + function getApproved(uint256 _tokenId) external view returns (address); + function isApprovedForAll(address _owner, address _operator) external view returns (bool); +``` + +### इव्हेंट्स {#events} + +```solidity + event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId); + event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId); + event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); +``` + +### उदाहरणे {#web3py-example} + +Ethereum वरील कोणत्याही ERC-721 टोकन कॉन्ट्रॅक्टची तपासणी करणे आपल्यासाठी सोपे करण्यासाठी एक मानक किती महत्त्वाचे आहे ते पाहूया. +कोणत्याही ERC-721 टोकनसाठी इंटरफेस तयार करण्यासाठी आपल्याला फक्त कॉन्ट्रॅक्ट ॲप्लिकेशन बायनरी इंटरफेस (ABI) ची आवश्यकता आहे. तुम्ही खाली पाहू शकता की आम्ही एक सरलीकृत ABI वापरणार आहोत, जेणेकरून हे एक कमी घर्षणाचे उदाहरण बनेल. + +#### Web3.py उदाहरण {#web3py-example} + +प्रथम, आपण [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) Python लायब्ररी स्थापित केली असल्याची खात्री करा: + +``` +pip install web3 +``` + +```python +from web3 import Web3 +from web3._utils.events import get_event_data + + +w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) + +ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # CryptoKitties Contract + +acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # CryptoKitties Sales Auction + +# This is a simplified Contract Application Binary Interface (ABI) of an ERC-721 NFT Contract. +# It will expose only the methods: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply() +simplified_abi = [ + { + 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}], + 'name': 'balanceOf', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'name', + 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [{'internalType': 'uint256', 'name': 'tokenId', 'type': 'uint256'}], + 'name': 'ownerOf', + 'outputs': [{'internalType': 'address', 'name': '', 'type': 'address'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'symbol', + 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'totalSupply', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, +] + +ck_extra_abi = [ + { + 'inputs': [], + 'name': 'pregnantKitties', + 'outputs': [{'name': '', 'type': 'uint256'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [{'name': '_kittyId', 'type': 'uint256'}], + 'name': 'isPregnant', + 'outputs': [{'name': '', 'type': 'bool'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + } +] + +ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi) +name = ck_contract.functions.name().call() +symbol = ck_contract.functions.symbol().call() +kitties_auctions = ck_contract.functions.balanceOf(acc_address).call() +print(f"{name} [{symbol}] NFTs in Auctions: {kitties_auctions}") + +pregnant_kitties = ck_contract.functions.pregnantKitties().call() +print(f"{name} [{symbol}] NFTs Pregnants: {pregnant_kitties}") + +# Using the Transfer Event ABI to get info about transferred Kitties. +tx_event_abi = { + 'anonymous': False, + 'inputs': [ + {'indexed': False, 'name': 'from', 'type': 'address'}, + {'indexed': False, 'name': 'to', 'type': 'address'}, + {'indexed': False, 'name': 'tokenId', 'type': 'uint256'}], + 'name': 'Transfer', + 'type': 'event' +} + +# We need the event's signature to filter the logs +event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex() + +logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), + "topics": [event_signature] +}) + +# Notes: +# - Increase the number of blocks up from 120 if no Transfer event is returned. +# - If you didn't find any Transfer event you can also try to get a tokenId at: +# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events +# Click to expand the event's logs and copy its "tokenId" argument +recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs] + +if recent_tx: + kitty_id = recent_tx[0]['tokenId'] # Paste the "tokenId" here from the link above + is_pregnant = ck_contract.functions.isPregnant(kitty_id).call() + print(f"{name} [{symbol}] NFTs {kitty_id} is pregnant: {is_pregnant}") +``` + +CryptoKitties कॉन्ट्रॅक्टमध्ये मानक इव्हेंट्स व्यतिरिक्त काही मनोरंजक इव्हेंट्स आहेत. + +चला त्यापैकी `Pregnant` आणि `Birth` हे दोन तपासूया. + +```python +# Using the Pregnant and Birth Events ABI to get info about new Kitties. +ck_extra_events_abi = [ + { + 'anonymous': False, + 'inputs': [ + {'indexed': False, 'name': 'owner', 'type': 'address'}, + {'indexed': False, 'name': 'matronId', 'type': 'uint256'}, + {'indexed': False, 'name': 'sireId', 'type': 'uint256'}, + {'indexed': False, 'name': 'cooldownEndBlock', 'type': 'uint256'}], + 'name': 'Pregnant', + 'type': 'event' + }, + { + 'anonymous': False, + 'inputs': [ + {'indexed': False, 'name': 'owner', 'type': 'address'}, + {'indexed': False, 'name': 'kittyId', 'type': 'uint256'}, + {'indexed': False, 'name': 'matronId', 'type': 'uint256'}, + {'indexed': False, 'name': 'sireId', 'type': 'uint256'}, + {'indexed': False, 'name': 'genes', 'type': 'uint256'}], + 'name': 'Birth', + 'type': 'event' + }] + +# We need the event's signature to filter the logs +ck_event_signatures = [ + w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(), + w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(), +] + +# Here is a Pregnant Event: +# - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog +pregnant_logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), + "topics": [ck_event_signatures[0]] +}) + +recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs] + +# Here is a Birth Event: +# - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a +birth_logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), + "topics": [ck_event_signatures[1]] +}) + +recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs] +``` + +## लोकप्रिय NFTs {#popular-nfts} + +- [Etherscan NFT Tracker](https://etherscan.io/nft-top-contracts) हस्तांतरण व्हॉल्यूमनुसार Ethereum वरील शीर्ष NFT ची यादी करते. +- [CryptoKitties](https://www.cryptokitties.co/) हा प्रजननक्षम, संग्रहणीय आणि अत्यंत मोहक प्राण्यांभोवती केंद्रित असलेला एक खेळ आहे, + ज्यांना आपण CryptoKitties म्हणतो. +- [Sorare](https://sorare.com/) हा एक जागतिक फँटसी फुटबॉल खेळ आहे जिथे तुम्ही मर्यादित आवृत्तीचे संग्रहणीय वस्तू गोळा करू शकता, + तुमच्या संघांचे व्यवस्थापन करू शकता आणि बक्षिसे मिळवण्यासाठी स्पर्धा करू शकता. +- [The Ethereum Name Service (ENS)](https://ens.domains/) सोप्या, मानवी-वाचनीय नावांचा वापर करून ब्लॉकचेनवर आणि ब्लॉकचेनबाहेर + संसाधनांना संबोधित करण्याचा एक सुरक्षित आणि विकेंद्रित मार्ग प्रदान करते. +- [POAP](https://poap.xyz) जे लोक कार्यक्रमांना उपस्थित राहतात किंवा विशिष्ट क्रिया पूर्ण करतात त्यांना मोफत NFTs वितरीत करते. POAPs तयार करणे आणि वितरित करणे विनामूल्य आहे. +- [Unstoppable Domains](https://unstoppabledomains.com/) ही सॅन फ्रान्सिस्को-स्थित कंपनी आहे जी ब्लॉकचेनवर + डोमेन तयार करत आहे. ब्लॉकचेन डोमेन मानवी-वाचनीय नावांनी क्रिप्टोकरन्सी पत्त्यांची जागा घेतात आणि सेन्सॉरशिप-प्रतिरोधक वेबसाइट्स + सक्षम करण्यासाठी वापरल्या जाऊ शकतात. +- [Gods Unchained Cards](https://godsunchained.com/) हा Ethereum ब्लॉकचेनवरील एक TCG आहे जो इन-गेम मालमत्तेला खरी मालकी + देण्यासाठी NFT's चा वापर करतो. +- [Bored Ape Yacht Club](https://boredapeyachtclub.com) हा 10,000 युनिक NFTs चा संग्रह आहे, जो, एक सिद्ध-दुर्मिळ कलाकृती असण्यासोबतच, क्लबसाठी सदस्यत्व टोकन म्हणून काम करतो, आणि सदस्यांना फायदे आणि लाभ प्रदान करतो जे सामुदायिक प्रयत्नांच्या परिणामी कालांतराने वाढतात. + +## पुढील वाचन {#further-reading} + +- [EIP-721: ERC-721 नॉन-फंजिबल टोकन मानक](https://eips.ethereum.org/EIPS/eip-721) +- [OpenZeppelin - ERC-721 डॉक्स](https://docs.openzeppelin.com/contracts/3.x/erc721) +- [OpenZeppelin - ERC-721 अंमलबजावणी](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol) +- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart) diff --git a/public/content/translations/mr/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/mr/developers/docs/standards/tokens/erc-777/index.md new file mode 100644 index 00000000000..24c1d102703 --- /dev/null +++ b/public/content/translations/mr/developers/docs/standards/tokens/erc-777/index.md @@ -0,0 +1,45 @@ +--- +title: "ERC-777 टोकन मानक" +description: "ERC-777 बद्दल जाणून घ्या, हुक्ससह एक सुधारित फंजिबल टोकन मानक, जरी सुरक्षेसाठी ERC-20 ची शिफारस केली जाते." +lang: mr +--- + +## चेतावणी {#warning} + +**[वेगवेगळ्या प्रकारच्या हल्ल्यांना बळी पडण्याची शक्यता](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2620) असल्यामुळे ERC-777 योग्यरित्या लागू करणे कठीण आहे.** **त्याऐवजी [ERC-20](/developers/docs/standards/tokens/erc-20/) वापरण्याची शिफारस केली जाते.** हे पृष्ठ ऐतिहासिक संग्रहण म्हणून ठेवले आहे. + +## परिचय? {#introduction} + +ERC-777 हे एक फंजिबल टोकन मानक आहे जे विद्यमान [ERC-20](/developers/docs/standards/tokens/erc-20/) मानकात सुधारणा करते. + +## पूर्वतयारी {#prerequisites} + +हे पृष्ठ अधिक चांगल्या प्रकारे समजून घेण्यासाठी, आम्ही शिफारस करतो की तुम्ही प्रथम [ERC-20](/developers/docs/standards/tokens/erc-20/) बद्दल वाचा. + +## ERC-777, ERC-20 च्या तुलनेत काय सुधारणा प्रस्तावित करते? {#-erc-777-vs-erc-20} + +ERC-777, ERC-20 च्या तुलनेत खालील सुधारणा प्रदान करते. + +### हुक्स {#hooks} + +हुक्स हे स्मार्ट कॉन्ट्रॅक्टच्या कोडमध्ये वर्णन केलेले एक फंक्शन आहे. जेव्हा कॉन्ट्रॅक्टद्वारे टोकन्स पाठवले जातात किंवा प्राप्त केले जातात तेव्हा हुक्स कॉल केले जातात. हे स्मार्ट कॉन्ट्रॅक्टला येणाऱ्या किंवा जाणाऱ्या टोकन्सवर प्रतिक्रिया देण्यास अनुमती देते. + +[ERC-1820](https://eips.ethereum.org/EIPS/eip-1820) मानकाचा वापर करून हुक्सची नोंदणी केली जाते आणि ते शोधले जातात. + +#### हुक्स उत्तम का आहेत? {#why-are-hooks-great} + +1. हुक्स, [ERC-20](https://eips.ethereum.org/EIPS/eip-20) च्या विपरीत, एकाच व्यवहारात कॉन्ट्रॅक्टला टोकन्स पाठवण्याची आणि कॉन्ट्रॅक्टला सूचित करण्याची परवानगी देतात, ज्यासाठी हे साध्य करण्यासाठी दुहेरी कॉल (`approve`/`transferFrom`) आवश्यक असतो. +2. ज्या कॉन्ट्रॅक्ट्सनी हुक्सची नोंदणी केलेली नाही ते ERC-777 शी विसंगत आहेत. जेव्हा प्राप्त करणाऱ्या कॉन्ट्रॅक्टने हुकची नोंदणी केलेली नसते, तेव्हा पाठवणारा कॉन्ट्रॅक्ट व्यवहार रद्द करतो. हे नॉन-ERC-777 स्मार्ट कॉन्ट्रॅक्ट्समध्ये अपघाती हस्तांतरण प्रतिबंधित करते. +3. हुक्स व्यवहार नाकारू शकतात. + +### दशांश {#decimals} + +हे मानक ERC-20 मध्ये `decimals` मुळे निर्माण होणारा गोंधळ देखील सोडवते. ही स्पष्टता डेव्हलपरचा अनुभव सुधारते. + +### ERC-20 सह बॅकवर्ड कंपॅटिबिलिटी {#backwards-compatibility-with-erc-20} + +ERC-777 कॉन्ट्रॅक्ट्ससोबत ERC-20 कॉन्ट्रॅक्ट्सप्रमाणेच संवाद साधला जाऊ शकतो. + +## अधिक वाचन {#further-reading} + +[EIP-777: टोकन मानक](https://eips.ethereum.org/EIPS/eip-777) diff --git a/public/content/translations/mr/developers/docs/standards/tokens/index.md b/public/content/translations/mr/developers/docs/standards/tokens/index.md new file mode 100644 index 00000000000..764c701edd3 --- /dev/null +++ b/public/content/translations/mr/developers/docs/standards/tokens/index.md @@ -0,0 +1,41 @@ +--- +title: "टोकन मानके" +description: "फंजिबल आणि नॉन-फंजिबल टोकनसाठी ERC-20, ERC-721, आणि ERC-1155 सह Ethereum टोकन मानकांचे अन्वेषण करा." +lang: mr +incomplete: true +--- + +## प्रस्तावना {#introduction} + +अनेक Ethereum विकास मानके टोकन इंटरफेसवर लक्ष केंद्रित करतात. ही मानके स्मार्ट कॉन्ट्रॅक्ट्स कंपोजेबल राहतील याची खात्री करण्यास मदत करतात, त्यामुळे जेव्हा एखादा नवीन प्रोजेक्ट टोकन जारी करतो, तेव्हा ते विद्यमान विकेंद्रित एक्सचेंज आणि ॲप्लिकेशन्सशी सुसंगत राहते. + +टोकन मानके संपूर्ण Ethereum इकोसिस्टममध्ये टोकन कसे वागतात आणि संवाद साधतात हे परिभाषित करतात. ते डेव्हलपर्ससाठी पुन्हा नव्याने सुरुवात न करता बिल्ड करणे सोपे करतात, याची खात्री करून की टोकन वॉलेट्स, एक्सचेंजेस आणि DeFi प्लॅटफॉर्मसह अखंडपणे काम करतात. गेमिंग, गव्हर्नन्स किंवा इतर वापराच्या बाबतीत असो, ही मानके सुसंगतता प्रदान करतात आणि Ethereum ला अधिक आंतरकनेक्टेड बनवतात. + +## पूर्वतयारी {#prerequisites} + +- [Ethereum विकास मानके](/developers/docs/standards/) +- [स्मार्ट कॉन्ट्रॅक्ट्स](/developers/docs/smart-contracts/) + +## टोकन मानके {#token-standards} + +Ethereum वरील काही सर्वात लोकप्रिय टोकन मानके येथे आहेत: + +- [ERC-20](/developers/docs/standards/tokens/erc-20/) - फंजिबल (परस्पर बदलण्यायोग्य) टोकनसाठी एक मानक इंटरफेस, जसे की व्होटिंग टोकन, स्टेकिंग टोकन किंवा व्हर्च्युअल चलने. + +### NFT मानके {#nft-standards} + +- [ERC-721](/developers/docs/standards/tokens/erc-721/) - नॉन-फंजिबल टोकनसाठी एक मानक इंटरफेस, जसे की कलाकृती किंवा गाण्यासाठी एक डीड. +- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - ERC-1155 अधिक कार्यक्षम ट्रेड आणि व्यवहारांचे बंडलिंग करण्यास परवानगी देतो – त्यामुळे खर्चात बचत होते. हे टोकन मानक युटिलिटी टोकन (जसे की $BNB किंवा $BAT) आणि CryptoPunks सारखे नॉन-फंजिबल टोकन दोन्ही तयार करण्यास परवानगी देते. + +[ERC](https://eips.ethereum.org/erc) प्रस्तावांची संपूर्ण यादी. + +## पुढील वाचन {#further-reading} + +_तुम्हाला मदत केलेल्या सामुदायिक संसाधनाबद्दल माहिती आहे का?_ हे पृष्ठ संपादित करा आणि ते जोडा!_ + +## संबंधित ट्युटोरियल्स {#related-tutorials} + +- [टोकन एकत्रीकरण चेकलिस्ट](/developers/tutorials/token-integration-checklist/) _– टोकनशी संवाद साधताना विचारात घेण्याच्या गोष्टींची एक चेकलिस्ट._ +- [ERC20 टोकन स्मार्ट कॉन्ट्रॅक्ट समजून घ्या](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– Ethereum टेस्ट नेटवर्कवर तुमचा पहिला स्मार्ट कॉन्ट्रॅक्ट तैनात करण्याची ओळख._ +- [Solidity स्मार्ट कॉन्ट्रॅक्टमधून ERC20 टोकन्सचे हस्तांतरण आणि मान्यता](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– Solidity भाषेचा वापर करून टोकनशी संवाद साधण्यासाठी स्मार्ट कॉन्ट्रॅक्ट कसा वापरायचा._ +- [ERC721 मार्केटची अंमलबजावणी करणे [एक कसे-करावे मार्गदर्शक]](/developers/tutorials/how-to-implement-an-erc721-market/) _– विकेंद्रित क्लासिफाइड बोर्डवर टोकनाइज्ड वस्तू विक्रीसाठी कशा ठेवायच्या._ diff --git a/public/content/translations/mr/developers/docs/storage/index.md b/public/content/translations/mr/developers/docs/storage/index.md new file mode 100644 index 00000000000..8a8234656fe --- /dev/null +++ b/public/content/translations/mr/developers/docs/storage/index.md @@ -0,0 +1,216 @@ +--- +title: "विकेंद्रित स्टोरेज" +description: "विकेंद्रित स्टोरेज काय आहे आणि ते dapp मध्ये समाकलित करण्यासाठी उपलब्ध असलेल्या साधनांचा आढावा." +lang: mr +--- + +एखाद्या कंपनी किंवा संस्थेद्वारे चालवल्या जाणाऱ्या केंद्रीकृत सर्व्हरच्या विपरीत, विकेंद्रित स्टोरेज सिस्टममध्ये वापरकर्ता-ऑपरेटरच्या पीअर-टू-पीअर नेटवर्कचा समावेश असतो जे एकूण डेटाचा काही भाग धारण करतात, ज्यामुळे एक लवचिक फाइल स्टोरेज शेअरिंग सिस्टम तयार होते. हे ब्लॉकचेन-आधारित ॲप्लिकेशन किंवा कोणत्याही पीअर-टू-पीअर-आधारित नेटवर्कमध्ये असू शकतात. + +Ethereum स्वतः एक विकेंद्रित स्टोरेज सिस्टम म्हणून वापरले जाऊ शकते, आणि जेव्हा सर्व स्मार्ट कॉन्ट्रॅक्ट्समध्ये कोड स्टोरेजचा विचार येतो तेव्हा ते वापरले जाते. तथापि, जेव्हा मोठ्या प्रमाणात डेटा येतो, तेव्हा Ethereum त्यासाठी डिझाइन केलेले नव्हते. चेन सातत्याने वाढत आहे, परंतु हे लिहिण्याच्या वेळी, Ethereum चेन सुमारे 500GB - 1TB आहे ([क्लायंटवर अवलंबून](https://etherscan.io/chartsync/chaindefault)), आणि नेटवर्कवरील प्रत्येक नोडला सर्व डेटा संग्रहित करण्यास सक्षम असणे आवश्यक आहे. जर चेन मोठ्या प्रमाणात डेटापर्यंत (समजा 5TBs) विस्तारली, तर सर्व नोड्ससाठी चालू राहणे व्यवहार्य होणार नाही. तसेच, [gas](/developers/docs/gas) शुल्कामुळे मेननेटवर इतका डेटा तैनात करण्याचा खर्च खूप जास्त असेल. + +या मर्यादांमुळे, मोठ्या प्रमाणात डेटा विकेंद्रित पद्धतीने संग्रहित करण्यासाठी आम्हाला वेगळ्या चेन किंवा पद्धतीची आवश्यकता आहे. + +विकेंद्रित स्टोरेज (dStorage) पर्यायांचा विचार करताना, वापरकर्त्याने काही गोष्टी लक्षात ठेवल्या पाहिजेत. + +- टिकाऊपणाची यंत्रणा / प्रोत्साहन रचना +- डेटा टिकवून ठेवण्याची अंमलबजावणी +- विकेंद्रितता +- एकमत + +## टिकाऊपणाची यंत्रणा / प्रोत्साहन रचना {#persistence-mechanism} + +### ब्लॉकचेन-आधारित {#blockchain-based} + +डेटाचा एखादा तुकडा कायमचा टिकून राहावा यासाठी, आम्हाला एका टिकाऊपणाच्या यंत्रणेचा वापर करणे आवश्यक आहे. उदाहरणार्थ, Ethereum वर, टिकाऊपणाची यंत्रणा अशी आहे की नोड चालवताना संपूर्ण चेनचा हिशोब ठेवणे आवश्यक आहे. डेटाचे नवीन तुकडे चेनच्या शेवटी जोडले जातात आणि ती वाढतच राहते - ज्यामुळे प्रत्येक नोडला सर्व एम्बेड केलेला डेटा प्रतिकृत करणे आवश्यक असते. + +याला **ब्लॉकचेन-आधारित** टिकाऊपणा म्हणून ओळखले जाते. + +ब्लॉकचेन-आधारित टिकाऊपणाची समस्या अशी आहे की चेन सर्व डेटा व्यवहार्यपणे सांभाळण्यासाठी आणि संग्रहित करण्यासाठी खूप मोठी होऊ शकते (उदा., [अनेक स्त्रोत](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) अंदाजानुसार इंटरनेटला 40 झेटाबाईट्स पेक्षा जास्त स्टोरेज क्षमतेची आवश्यकता असेल). + +ब्लॉकचेनमध्ये काही प्रकारची प्रोत्साहन रचना देखील असणे आवश्यक आहे. ब्लॉकचेन-आधारित टिकाऊपणासाठी, व्हॅलिडेटरला पेमेंट केले जाते. जेव्हा डेटा चेनमध्ये जोडला जातो, तेव्हा व्हॅलिडेटर्सना तो डेटा जोडण्यासाठी पैसे दिले जातात. + +ब्लॉकचेन-आधारित टिकाऊपणा असलेले प्लॅटफॉर्म: + +- Ethereum +- [Arweave](https://www.arweave.org/) + +### कॉन्ट्रॅक्ट-आधारित {#contract-based} + +**कॉन्ट्रॅक्ट-आधारित** टिकाऊपणाचा अंतर्ज्ञान असा आहे की डेटा प्रत्येक नोडद्वारे प्रतिकृत केला जाऊ शकत नाही आणि कायमचा संग्रहित केला जाऊ शकत नाही, आणि त्याऐवजी तो कॉन्ट्रॅक्ट करारांद्वारे सांभाळला पाहिजे. हे एकाधिक नोड्ससह केलेले करार आहेत ज्यांनी विशिष्ट कालावधीसाठी डेटाचा एक तुकडा ठेवण्याचे वचन दिले आहे. डेटा टिकवून ठेवण्यासाठी ते संपल्यावर त्यांना परतावा किंवा त्यांचे नूतनीकरण करणे आवश्यक आहे. + +बहुतेक प्रकरणांमध्ये, सर्व डेटा ऑनचेन संग्रहित करण्याऐवजी, डेटा चेनवर कुठे आहे याचा हॅश संग्रहित केला जातो. यामुळे, सर्व डेटा ठेवण्यासाठी संपूर्ण चेनला स्केल करण्याची आवश्यकता नाही. + +कॉन्ट्रॅक्ट-आधारित टिकाऊपणा असलेले प्लॅटफॉर्म: + +- [Filecoin](https://docs.filecoin.io/basics/what-is-filecoin) +- [Skynet](https://sia.tech/) +- [Storj](https://storj.io/) +- [Züs](https://zus.network/) +- [Crust Network](https://crust.network) +- [Swarm](https://www.ethswarm.org/) +- [4EVERLAND](https://www.4everland.org/) + +### अतिरिक्त विचार {#additional-consideration} + +IPFS ही फाईल्स, वेबसाइट्स, ॲप्लिकेशन्स आणि डेटा संग्रहित करण्यासाठी आणि ॲक्सेस करण्यासाठी एक वितरित प्रणाली आहे. यात कोणतीही अंगभूत प्रोत्साहन योजना नाही, परंतु त्याऐवजी दीर्घकालीन टिकाऊपणासाठी वरील कोणत्याही कॉन्ट्रॅक्ट-आधारित प्रोत्साहन उपायांसह याचा वापर केला जाऊ शकतो. IPFS वर डेटा टिकवून ठेवण्याचा दुसरा मार्ग म्हणजे पिनिंग सेवेसह काम करणे, जी तुमच्यासाठी तुमचा डेटा "पिन" करेल. तुम्ही तुमचा स्वतःचा IPFS नोड चालवून तुमचा आणि/किंवा इतरांचा डेटा विनामूल्य टिकवून ठेवण्यासाठी नेटवर्कमध्ये योगदान देऊ शकता! + +- [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/) +- [Pinata](https://www.pinata.cloud/) _(IPFS पिनिंग सेवा)_ +- [web3.storage](https://web3.storage/) _(IPFS/Filecoin पिनिंग सेवा)_ +- [Infura](https://infura.io/product/ipfs) _(IPFS पिनिंग सेवा)_ +- [IPFS Scan](https://ipfs-scan.io) _(IPFS पिनिंग एक्सप्लोरर)_ +- [4EVERLAND](https://www.4everland.org/)_（IPFS पिनिंग सेवा）_ +- [Filebase](https://filebase.com) _(IPFS पिनिंग सेवा)_ +- [Spheron Network](https://spheron.network/) _(IPFS/Filecoin पिनिंग सेवा)_ + +SWARM हे स्टोरेज प्रोत्साहन प्रणाली आणि स्टोरेज भाडे किंमत ओरॅकल असलेले विकेंद्रित डेटा स्टोरेज आणि वितरण तंत्रज्ञान आहे. + +## डेटा टिकवून ठेवणे {#data-retention} + +डेटा टिकवून ठेवण्यासाठी, सिस्टममध्ये डेटा टिकवून ठेवला गेला आहे याची खात्री करण्यासाठी काही प्रकारची यंत्रणा असणे आवश्यक आहे. + +### चॅलेंज यंत्रणा {#challenge-mechanism} + +डेटा टिकवून ठेवला गेला आहे याची खात्री करण्याचा एक सर्वात लोकप्रिय मार्ग म्हणजे, त्यांच्याकडे अजूनही डेटा आहे याची खात्री करण्यासाठी नोड्सना जारी केलेल्या काही प्रकारच्या क्रिप्टोग्राफिक चॅलेंजचा वापर करणे. एक सोपे उदाहरण म्हणजे Arweave चा प्रूफ-ऑफ-एक्सेस पाहणे. त्यांच्याकडे सर्वात अलीकडील ब्लॉक आणि भूतकाळातील यादृच्छिक ब्लॉक दोन्हीवर डेटा आहे की नाही हे पाहण्यासाठी ते नोड्सना आव्हान देतात. जर नोड उत्तर देऊ शकला नाही, तर त्याला दंड ठोठावला जातो. + +चॅलेंज यंत्रणेसह dStorage चे प्रकार: + +- Züs +- Skynet +- Arweave +- Filecoin +- Crust Network +- 4EVERLAND + +### विकेंद्रितता {#decentrality} + +प्लॅटफॉर्मच्या विकेंद्रीकरणाची पातळी मोजण्यासाठी कोणतीही उत्तम साधने नाहीत, परंतु सर्वसाधारणपणे, तुम्हाला अशी साधने वापरायची असतील ज्यात KYC चे कोणतेही स्वरूप नाही, जेणेकरून ते केंद्रीकृत नाहीत याचा पुरावा देता येईल. + +KYC शिवाय विकेंद्रित साधने: + +- Skynet +- Arweave +- Filecoin +- IPFS +- Ethereum +- Crust Network +- 4EVERLAND + +### Consensus {#consensus} + +यापैकी बहुतेक साधनांची [एकमत यंत्रणेची](/developers/docs/consensus-mechanisms/) स्वतःची आवृत्ती आहे, परंतु सामान्यतः ते [**प्रूफ-ऑफ-वर्क (PoW)**](/developers/docs/consensus-mechanisms/pow/) किंवा [**प्रूफ-ऑफ-स्टेक (PoS)**](/developers/docs/consensus-mechanisms/pos/) यावर आधारित आहेत. + +प्रूफ-ऑफ-वर्क आधारित: + +- Skynet +- Arweave + +प्रूफ-ऑफ-स्टेक आधारित: + +- Ethereum +- Filecoin +- Züs +- Crust Network + +## संबंधित साधने {#related-tools} + +**IPFS - _इंटरप्लॅनेटरी फाइल सिस्टम ही Ethereum साठी एक विकेंद्रित स्टोरेज आणि फाइल संदर्भ प्रणाली आहे._** + +- [Ipfs.io](https://ipfs.io/) +- [दस्तऐवजीकरण](https://docs.ipfs.io/) +- [GitHub](https://github.com/ipfs/ipfs) + +**Storj DCS - _डेव्हलपर्ससाठी सुरक्षित, खाजगी आणि S3-सुसंगत विकेंद्रित क्लाउड ऑब्जेक्ट स्टोरेज._** + +- [Storj.io](https://storj.io/) +- [दस्तऐवजीकरण](https://docs.storj.io/) +- [GitHub](https://github.com/storj/storj) + +**Sia - _खरेदीदार आणि विक्रेत्यांना थेट व्यवहार करण्याची परवानगी देऊन, एक ट्रस्टलेस क्लाउड स्टोरेज मार्केटप्लेस तयार करण्यासाठी क्रिप्टोग्राफीचा उपयोग करते._** + +- [Skynet.net](https://sia.tech/) +- [दस्तऐवजीकरण](https://docs.sia.tech/) +- [GitHub](https://github.com/SiaFoundation/) + +**Filecoin - _Filecoin IPFS च्या मागे असलेल्या त्याच टीमने तयार केले आहे. हा IPFS आदर्शांवर एक प्रोत्साहन स्तर आहे._** + +- [Filecoin.io](https://filecoin.io/) +- [दस्तऐवजीकरण](https://docs.filecoin.io/) +- [GitHub](https://github.com/filecoin-project/) + +**Arweave - _Arweave हे डेटा संग्रहित करण्यासाठी एक dStorage प्लॅटफॉर्म आहे._** + +- [Arweave.org](https://www.arweave.org/) +- [दस्तऐवजीकरण](https://docs.arweave.org/info/) +- [Arweave](https://github.com/ArweaveTeam/arweave/) + +**Züs - _Züs हे शार्डिंग आणि ब्लॉबर्ससह एक प्रूफ-ऑफ-स्टेक dStorage प्लॅटफॉर्म आहे._** + +- [zus.network](https://zus.network/) +- [दस्तऐवजीकरण](https://docs.zus.network/zus-docs/) +- [GitHub](https://github.com/0chain/) + +**Crust Network - _Crust हे IPFS वर एक dStorage प्लॅटफॉर्म आहे._** + +- [Crust.network](https://crust.network) +- [दस्तऐवजीकरण](https://wiki.crust.network) +- [GitHub](https://github.com/crustio) + +**Swarm - _Ethereum web3 स्टॅकसाठी एक वितरित स्टोरेज प्लॅटफॉर्म आणि सामग्री वितरण सेवा._** + +- [EthSwarm.org](https://www.ethswarm.org/) +- [दस्तऐवजीकरण](https://docs.ethswarm.org/) +- [GitHub](https://github.com/ethersphere/) + +**OrbitDB - _IPFS वर एक विकेंद्रित पीअर-टू-पीअर डेटाबेस._** + +- [OrbitDB.org](https://orbitdb.org/) +- [दस्तऐवजीकरण](https://github.com/orbitdb/field-manual/) +- [GitHub](https://github.com/orbitdb/orbit-db/) + +**Aleph.im - _विकेंद्रित क्लाउड प्रकल्प (डेटाबेस, फाइल स्टोरेज, कॉम्प्युटिंग आणि DID). ऑफचेन आणि ऑनचेन पीअर-टू-पीअर तंत्रज्ञानाचे एक अद्वितीय मिश्रण. IPFS आणि मल्टी-चेन सुसंगतता._** + +- [Aleph.im](https://aleph.cloud/) +- [दस्तऐवजीकरण](https://docs.aleph.cloud/) +- [GitHub](https://github.com/aleph-im/) + +**Ceramic - _डेटा-समृद्ध आणि आकर्षक ॲप्लिकेशन्ससाठी वापरकर्ता-नियंत्रित IPFS डेटाबेस स्टोरेज._** + +- [Ceramic.network](https://ceramic.network/) +- [दस्तऐवजीकरण](https://developers.ceramic.network/) +- [GitHub](https://github.com/ceramicnetwork/js-ceramic/) + +**Filebase - _S3-सुसंगत विकेंद्रित स्टोरेज आणि जिओ-रिडंडंट IPFS पिनिंग सेवा. Filebase द्वारे IPFS वर अपलोड केलेल्या सर्व फायली जगभरात 3x प्रतिकृतीसह Filebase पायाभूत सुविधेवर स्वयंचलितपणे पिन केल्या जातात._** + +- [Filebase.com](https://filebase.com/) +- [दस्तऐवजीकरण](https://docs.filebase.com/) +- [GitHub](https://github.com/filebase) + +**4EVERLAND - _एक वेब 3.0 क्लाउड कॉम्प्युटिंग प्लॅटफॉर्म जो स्टोरेज, कॉम्प्युट आणि नेटवर्किंग कोर क्षमतांना एकत्रित करतो, S3 सुसंगत आहे आणि IPFS आणि Arweave सारख्या विकेंद्रित स्टोरेज नेटवर्कवर सिंक्रोनस डेटा स्टोरेज प्रदान करतो._** + +- [4everland.org](https://www.4everland.org/) +- [दस्तऐवजीकरण](https://docs.4everland.org/) +- [GitHub](https://github.com/4everland) + +**Kaleido - _एक ब्लॉकचेन-ॲज-अ-सर्व्हिस प्लॅटफॉर्म ज्यात क्लिक-बटण IPFS नोड्स आहेत_** + +- [Kaleido](https://kaleido.io/) +- [दस्तऐवजीकरण](https://docs.kaleido.io/kaleido-services/ipfs/) +- [GitHub](https://github.com/kaleido-io) + +**Spheron Network - _Spheron हे एक प्लॅटफॉर्म-ॲज-अ-सर्व्हिस (PaaS) आहे जे सर्वोत्तम कामगिरीसह विकेंद्रित पायाभूत सुविधांवर त्यांचे ॲप्लिकेशन्स लॉन्च करू इच्छिणाऱ्या dApps साठी डिझाइन केलेले आहे. हे कॉम्प्युट, विकेंद्रित स्टोरेज, CDN आणि वेब होस्टिंग आउट ऑफ द बॉक्स प्रदान करते._** + +- [spheron.network](https://spheron.network/) +- [दस्तऐवजीकरण](https://docs.spheron.network/) +- [GitHub](https://github.com/spheronFdn) + +## पुढील वाचन {#further-reading} + +- [विकेंद्रित स्टोरेज म्हणजे काय?](https://coinmarketcap.com/academy/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_ +- [विकेंद्रित स्टोरेजबद्दलच्या पाच सामान्य मिथकांना दूर करणे](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_ + +_तुम्हाला मदत केलेल्या सामुदायिक संसाधनाबद्दल माहिती आहे का?_ हे पृष्ठ संपादित करा आणि ते जोडा!_ + +## संबंधित विषय {#related-topics} + +- [डेव्हलपमेंट फ्रेमवर्क्स](/developers/docs/frameworks/)