diff --git a/.all-contributorsrc b/.all-contributorsrc index 60f6266306e..c3f1ba09625 100644 --- a/.all-contributorsrc +++ b/.all-contributorsrc @@ -12643,6 +12643,24 @@ "contributions": [ "doc" ] + }, + { + "login": "YakshitAgarwal", + "name": "Yakshit Agarwal", + "avatar_url": "https://avatars.githubusercontent.com/u/153830716?v=4", + "profile": "https://github.com/YakshitAgarwal", + "contributions": [ + "content" + ] + }, + { + "login": "mseidlx", + "name": "Matthias Seidl", + "avatar_url": "https://avatars.githubusercontent.com/u/32496674?v=4", + "profile": "https://growthepie.xyz", + "contributions": [ + "code" + ] } ], "contributorsPerLine": 7, diff --git a/.github/workflows/generate-review-report.yml b/.github/workflows/generate-review-report.yml index 8b09e4a0d8c..fb9b435f753 100644 --- a/.github/workflows/generate-review-report.yml +++ b/.github/workflows/generate-review-report.yml @@ -28,7 +28,7 @@ jobs: CROWDIN_PROJECT_ID: ${{ secrets.CROWDIN_PROJECT_ID }} - name: Upload output as artifact - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v4 with: name: output path: ./src/data/crowdin/bucketsAwaitingReviewReport.csv \ No newline at end of file diff --git a/README.md b/README.md index 5eb37a73b84..0b516f19628 100644 --- a/README.md +++ b/README.md @@ -1934,6 +1934,10 @@ Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/d ddannehh
ddannehh
🎨 Jonas Irgens Kylling
Jonas Irgens Kylling
🖋 Thomas Brillard
Thomas Brillard
📖 + Yakshit Agarwal
Yakshit Agarwal
🖋 + + + Matthias Seidl
Matthias Seidl
💻 diff --git a/next.config.js b/next.config.js index 886870c1b02..1aa0317271f 100644 --- a/next.config.js +++ b/next.config.js @@ -63,6 +63,12 @@ module.exports = (phase, { defaultConfig }) => { trailingSlash: true, images: { deviceSizes: [640, 750, 828, 1080, 1200, 1504, 1920], + remotePatterns: [ + { + protocol: "https", + hostname: "crowdin-static.downloads.crowdin.com", + }, + ], }, } diff --git a/package.json b/package.json index ed1c0edc5b7..11eaca20b13 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "ethereum-org-website", - "version": "9.3.0", + "version": "9.4.0", "license": "MIT", "private": true, "scripts": { @@ -66,7 +66,7 @@ "lodash.merge": "^4.6.2", "lodash.shuffle": "^4.2.0", "lodash.union": "^4.6.0", - "next": "^14.2.10", + "next": "^14.2.15", "next-i18next": "^14.0.3", "next-mdx-remote": "^3.0.8", "next-sitemap": "^4.2.3", diff --git a/public/_redirects b/public/_redirects index 376f679fb56..d6ca9de7a30 100644 --- a/public/_redirects +++ b/public/_redirects @@ -28,6 +28,8 @@ /nfts/ /en/nft/ 301! +/payments/ /en/payments/ 301! + /daos/ /en/dao/ 301! /layer2/ /en/layer-2/ 301! diff --git a/public/content/community/research/index.md b/public/content/community/research/index.md index 45a6e898324..3b238fb9658 100644 --- a/public/content/community/research/index.md +++ b/public/content/community/research/index.md @@ -111,7 +111,7 @@ There are now several Layer 2 protocols that scale Ethereum using different tech #### Recent research {#recent-research-2} - [Arbitrum's fair-ordering for sequencers](https://eprint.iacr.org/2021/1465) -- [ethresear.ch Layer 2](https://ethresear.ch/c/layer-2/32) +- [Ethresear.ch Layer 2](https://ethresear.ch/c/layer-2/32) - [Rollup-centric roadmap](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) - [L2Beat](https://l2beat.com/) @@ -189,7 +189,7 @@ Ethereum wallets can be browser extensions, desktop and mobile apps or smart con - [Introduction to wallets](/wallets/) - [Introduction to wallet security](/security/) -- [ethresear.ch Security](https://ethresear.ch/tag/security) +- [Ethresear.ch Security](https://ethresear.ch/tag/security) - [EIP-2938 Account Abstraction](https://eips.ethereum.org/EIPS/eip-2938) - [EIP-4337 Account Abstraction](https://eips.ethereum.org/EIPS/eip-4337) @@ -364,7 +364,7 @@ Oracles import off-chain data onto the blockchain in a permissionless and decent - [Introduction to Oracles](/developers/docs/oracles/) -#### Recent Research {#recent-research-18} +#### Recent research {#recent-research-18} - [Survey of blockchain oracles](https://arxiv.org/pdf/2004.07140.pdf) - [Chainlink white paper](https://chain.link/whitepaper) @@ -381,7 +381,7 @@ Hacks on Ethereum generally exploit vulnerabilities in individual applications r #### Recent research {#recent-research-19} -- [ethresear.ch Applications](https://ethresear.ch/c/applications/18) +- [Ethresear.ch Applications](https://ethresear.ch/c/applications/18) ### Technology stack {#technology-stack} diff --git a/public/content/contributing/index.md b/public/content/contributing/index.md index 2d680b80ce9..372f0b07fda 100644 --- a/public/content/contributing/index.md +++ b/public/content/contributing/index.md @@ -19,7 +19,7 @@ We are a welcoming community that will help you grow and educate in the Ethereum - [Work on an open issue](https://github.com/ethereum/ethereum-org-website/issues) – Work we've identified that needs doing **Design** -- [Help design the website](/contributing/design/) Designers of all levels can contribute to improve the website +- [Help design the website](/contributing/design/) – Designers of all levels can contribute to improve the website **Content** - [Create/edit content](/contributing/#how-to-update-content) – Suggest new pages or make tweaks to what's here already @@ -94,7 +94,7 @@ If your contribution gets merged into ethereum.org, you will have a chance to cl ### How to claim 1. Join our [Discord server](https://discord.gg/ethereum-org). -2. Paste a link to your contribution in the `#🥇 | proof-of-contribution` channel +2. Paste a link to your contribution in the `#🥇 | proof-of-contribution` channel. 3. Wait for a member of our team to send you a link to your OAT. 4. Claim your OAT! diff --git a/public/content/contributing/style-guide/content-standardization/index.md b/public/content/contributing/style-guide/content-standardization/index.md index 1d52685f12a..8fbf287c31a 100644 --- a/public/content/contributing/style-guide/content-standardization/index.md +++ b/public/content/contributing/style-guide/content-standardization/index.md @@ -252,7 +252,7 @@ This site uses **sentence casing** for header names as a convention. Only the fi ### Setting Up Your Wallet -### Getting Enough Ether +### Getting Enough ether ``` ### Article authors {#authors} diff --git a/public/content/dao/index.md b/public/content/dao/index.md index 6fc2f53630a..5287be1e8fa 100644 --- a/public/content/dao/index.md +++ b/public/content/dao/index.md @@ -1,5 +1,6 @@ --- -title: Decentralized autonomous organizations (DAOs) +title: What is a DAO? +metaTitle: What is a DAO? | Decentralized Autonomous Organization description: An overview of DAOs on Ethereum lang: en template: use-cases diff --git a/public/content/defi/index.md b/public/content/defi/index.md index 19d41c91073..eff4bcf38d5 100644 --- a/public/content/defi/index.md +++ b/public/content/defi/index.md @@ -1,5 +1,6 @@ --- title: Decentralized finance (DeFi) +metaTitle: What is DeFi? | Benefits and Use of Decentralised Finance description: An overview of DeFi on Ethereum lang: en template: use-cases @@ -168,7 +169,7 @@ If exchange B's supply dropped suddenly and the user wasn't able to buy enough t To be able to do the above example in the traditional finance world, you'd need an enormous amount of money. These money-making strategies are only accessible to those with existing wealth. Flash loans are an example of a future where having money is not necessarily a prerequisite for making money. - + More on flash loans @@ -324,7 +325,7 @@ You can think of DeFi in layers: 3. The protocols – [smart contracts](/glossary/#smart-contract) that provide the functionality, for example, a service that allows for decentralized lending of assets. 4. [The applications](/dapps/) – the products we use to manage and access the protocols. -Note: much of DeFi uses the [ERC-20 standard](/glossary/#erc-20). Applications in DeFi use a wrapper for ETH called Wrapped Ether (WETH). [Learn more about wrapped ether](/wrapped-eth). +Note: much of DeFi uses the [ERC-20 standard](/glossary/#erc-20). Applications in DeFi use a wrapper for ETH called Wrapped ether (WETH). [Learn more about wrapped ether](/wrapped-eth). ## Build DeFi {#build-defi} @@ -358,4 +359,4 @@ DeFi is an open-source movement. The DeFi protocols and applications are all ope - \ No newline at end of file + diff --git a/public/content/developers/docs/apis/json-rpc/index.md b/public/content/developers/docs/apis/json-rpc/index.md index 129f8acc633..c9842341a8c 100755 --- a/public/content/developers/docs/apis/json-rpc/index.md +++ b/public/content/developers/docs/apis/json-rpc/index.md @@ -992,7 +992,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params" ### eth_call {#eth_call} -Executes a new message call immediately without creating a transaction on the block chain. Often used for executing read-only smart contract functions, for example the `balanceOf` for an ERC-20 contract. +Executes a new message call immediately without creating a transaction on the blockchain. Often used for executing read-only smart contract functions, for example the `balanceOf` for an ERC-20 contract. **Parameters** diff --git a/public/content/developers/docs/evm/index.md b/public/content/developers/docs/evm/index.md index 92132062bc5..7f0010fbdb4 100644 --- a/public/content/developers/docs/evm/index.md +++ b/public/content/developers/docs/evm/index.md @@ -14,7 +14,7 @@ Some basic familiarity with common terminology in computer science such as [byte The analogy of a 'distributed ledger' is often used to describe blockchains like Bitcoin, which enable a decentralized currency using fundamental tools of cryptography. The ledger maintains a record of activity which must adhere to a set of rules that govern what someone can and cannot do to modify the ledger. For example, a Bitcoin address cannot spend more Bitcoin than it has previously received. These rules underpin all transactions on Bitcoin and many other blockchains. -While Ethereum has its own native cryptocurrency (Ether) that follows almost exactly the same intuitive rules, it also enables a much more powerful function: [smart contracts](/developers/docs/smart-contracts/). For this more complex feature, a more sophisticated analogy is required. Instead of a distributed ledger, Ethereum is a distributed [state machine](https://wikipedia.org/wiki/Finite-state_machine). Ethereum's state is a large data structure which holds not only all accounts and balances, but a _machine state_, which can change from block to block according to a pre-defined set of rules, and which can execute arbitrary machine code. The specific rules of changing state from block to block are defined by the EVM. +While Ethereum has its own native cryptocurrency (ether) that follows almost exactly the same intuitive rules, it also enables a much more powerful function: [smart contracts](/developers/docs/smart-contracts/). For this more complex feature, a more sophisticated analogy is required. Instead of a distributed ledger, Ethereum is a distributed [state machine](https://wikipedia.org/wiki/Finite-state_machine). Ethereum's state is a large data structure which holds not only all accounts and balances, but a _machine state_, which can change from block to block according to a pre-defined set of rules, and which can execute arbitrary machine code. The specific rules of changing state from block to block are defined by the EVM. ![A diagram showing the make up of the EVM](./evm.png) _Diagram adapted from [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ diff --git a/public/content/developers/docs/gas/index.md b/public/content/developers/docs/gas/index.md index 2b6cedb16c8..6fdff280090 100644 --- a/public/content/developers/docs/gas/index.md +++ b/public/content/developers/docs/gas/index.md @@ -1,5 +1,6 @@ --- title: Gas and fees +metaTitle: "Ethereum gas and fees: technical overview" description: lang: en --- diff --git a/public/content/developers/docs/intro-to-ether/index.md b/public/content/developers/docs/intro-to-ether/index.md index 6ecff1f4d17..b794ee17afe 100644 --- a/public/content/developers/docs/intro-to-ether/index.md +++ b/public/content/developers/docs/intro-to-ether/index.md @@ -71,7 +71,7 @@ Users can query the ether balance of any [account](/developers/docs/accounts/) b ## Further reading {#further-reading} -- [Defining Ether and Ethereum](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_ +- [Defining ether and Ethereum](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_ - [Ethereum Whitepaper](/whitepaper/): The original proposal for Ethereum. This document includes a description of ether and the motivations behind its creation. - [Gwei Calculator](https://www.alchemy.com/gwei-calculator): Use this gwei calculator to easily convert wei, gwei, and ether. Simply plug in any amount of wei, gwei, or ETH and automatically calculate the conversion. diff --git a/public/content/developers/docs/networking-layer/network-addresses/index.md b/public/content/developers/docs/networking-layer/network-addresses/index.md index 5a8b5c5c1b6..3c09ed6e85e 100644 --- a/public/content/developers/docs/networking-layer/network-addresses/index.md +++ b/public/content/developers/docs/networking-layer/network-addresses/index.md @@ -23,7 +23,7 @@ For an Ethereum node, the multiaddr contains the node-ID (a hash of their public ## Enode {#enode} -An enode is a way to identify an Ethereum node using a URL address format. The hexadecimal node-ID is encoded in the username portion of the URL separated from the host using an @ sign. The hostname can only be given as an IP address; DNS names are not allowed. The port in the hostname section is the TCP listening port. If the TCP and UDP (discovery) ports differ, the UDP port is specified as a query parameter "discport" +An enode is a way to identify an Ethereum node using a URL address format. The hexadecimal node-ID is encoded in the username portion of the URL separated from the host using an @ sign. The hostname can only be given as an IP address; DNS names are not allowed. The port in the hostname section is the TCP listening port. If the TCP and UDP (discovery) ports differ, the UDP port is specified as a query parameter "discport". In the following example, the node URL describes a node with IP address `10.3.58.6`, TCP port `30303` and UDP discovery port `30301`. @@ -35,6 +35,6 @@ Ethereum Node Records (ENRs) are a standardized format for network addresses on ## Further Reading {#further-reading} -[EIP-778: Ethereum Node Records (ENR)](https://eips.ethereum.org/EIPS/eip-778) -[Network addresses in Ethereum](https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/) -[LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/) +- [EIP-778: Ethereum Node Records (ENR)](https://eips.ethereum.org/EIPS/eip-778) +- [Network addresses in Ethereum](https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/) +- [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/) diff --git a/public/content/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/developers/docs/nodes-and-clients/client-diversity/index.md index 57231954f26..4e234ecca24 100644 --- a/public/content/developers/docs/nodes-and-clients/client-diversity/index.md +++ b/public/content/developers/docs/nodes-and-clients/client-diversity/index.md @@ -80,6 +80,8 @@ Addressing client diversity requires more than individual users to choose minori [Prysm](https://docs.prylabs.network/docs/getting-started) +[Grandine](https://docs.grandine.io/) + Technical users can help accelerate this process by writing more tutorials and documentation for minority clients and encouraging their node-operating peers to migrate away from the dominant clients. Guides for switching to a minority consensus client are available on [clientdiversity.org](https://clientdiversity.org/). ## Client diversity dashboards {#client-diversity-dashboards} diff --git a/public/content/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/developers/docs/nodes-and-clients/run-a-node/index.md index b2bef8282d0..5b9a9307751 100644 --- a/public/content/developers/docs/nodes-and-clients/run-a-node/index.md +++ b/public/content/developers/docs/nodes-and-clients/run-a-node/index.md @@ -312,7 +312,7 @@ reth node \ --authrpc.port 8551 ``` -See [Configuring Reth](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth) to learn more about data default data directories. [Reth's documentation](https://reth.rs/run/mainnet.html) contains additional options and configuration details. +See [Configuring Reth](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth) to learn more about default data directories. [Reth's documentation](https://reth.rs/run/mainnet.html) contains additional options and configuration details. #### Starting the consensus client {#starting-the-consensus-client} diff --git a/public/content/developers/docs/scaling/plasma/index.md b/public/content/developers/docs/scaling/plasma/index.md index cd9f52e6a6a..efac61b8b9e 100644 --- a/public/content/developers/docs/scaling/plasma/index.md +++ b/public/content/developers/docs/scaling/plasma/index.md @@ -108,7 +108,7 @@ Although exit games sound nice in theory, real-life mass exits will likely trigg | Pros | Cons | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Offers high throughput and low cost per transaction. | Does not support general computation (cannot run smart contracts. Only basic token transfers, swaps, and a few other transaction types are supported via predicate logic. | +| Offers high throughput and low cost per transaction. | Does not support general computation (cannot run smart contracts). Only basic token transfers, swaps, and a few other transaction types are supported via predicate logic. | | Good for transactions between arbitrary users (no overhead per user pair if both are established on the plasma chain) | Need to periodically watch the network (liveness requirement) or delegate this responsibility to someone else to ensure the security of your funds. | | Plasma chains can be adapted to specific use-cases that are unrelated to the main chain. Anyone, including businesses, can customize Plasma smart contracts to provide scalable infrastructure that works in different contexts. | Relies on one or more operators to store data and serve it upon request. | | Reduces load on Ethereum Mainnet by moving computation and storage off-chain. | Withdrawals are delayed by several days to allow for challenges. For fungible assets, this can be mitigated by liquidity providers, but there is an associated capital cost. | diff --git a/public/content/developers/docs/smart-contracts/security/index.md b/public/content/developers/docs/smart-contracts/security/index.md index e6451925967..fbba029f9d0 100644 --- a/public/content/developers/docs/smart-contracts/security/index.md +++ b/public/content/developers/docs/smart-contracts/security/index.md @@ -99,7 +99,7 @@ That said, you should avoid treating audits as a silver bullet. Smart contract a Setting up a bug bounty program is another approach for implementing external code reviews. A bug bounty is a financial reward given to individuals (usually whitehat hackers) that discover vulnerabilities in an application. -When used properly, bug bounties give members of the hacker community incentive to inspect your code for critical flaws. A real-life example is the “infinite money bug” that would have let an attacker create an unlimited amount of Ether on [Optimism](https://www.optimism.io/), a [Layer 2](/layer-2/) protocol running on Ethereum. Fortunately, a whitehat hacker [discovered the flaw](https://www.saurik.com/optimism.html) and notified the team, [earning a large payout in the process](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/). +When used properly, bug bounties give members of the hacker community incentive to inspect your code for critical flaws. A real-life example is the “infinite money bug” that would have let an attacker create an unlimited amount of ether on [Optimism](https://www.optimism.io/), a [Layer 2](/layer-2/) protocol running on Ethereum. Fortunately, a whitehat hacker [discovered the flaw](https://www.saurik.com/optimism.html) and notified the team, [earning a large payout in the process](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/). A useful strategy is to set the payout of a bug bounty program in proportion to the amount of funds at stake. Described as the “[scaling bug bounty](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)”, this approach provides financial incentives for individuals to responsibly disclose vulnerabilities instead of exploiting them. @@ -235,7 +235,7 @@ The EVM doesn’t permit concurrency, meaning two contracts involved in a messag Although mostly harmless, transferring control flow to untrusted contracts can cause problems, such as reentrancy. A reentrancy attack occurs when a malicious contract calls back into a vulnerable contract before the original function invocation is complete. This type of attack is best explained with an example. -Consider a simple smart contract (‘Victim’) that allows anyone to deposit and withdraw Ether: +Consider a simple smart contract (‘Victim’) that allows anyone to deposit and withdraw ether: ```solidity // This contract is vulnerable. Do not use in production diff --git a/public/content/developers/docs/smart-contracts/testing/index.md b/public/content/developers/docs/smart-contracts/testing/index.md index 30f27ac1a9e..7062738aade 100644 --- a/public/content/developers/docs/smart-contracts/testing/index.md +++ b/public/content/developers/docs/smart-contracts/testing/index.md @@ -130,7 +130,7 @@ Many unit testing frameworks allow you to create assertions—simple statements ##### 3. Measure code coverage -[Code coverage](https://en.m.wikipedia.org/wiki/Code_coverage) is a testing metric that tracks the number of branches, lines, and statements in your code executed during tests. Tests should have good code coverage, otherwise you may get "false negatives" which happen a contract passes all tests, but vulnerabilities still exist in the code. Recording high code coverage, however, gives the assurance all statements/functions in a smart contract were sufficiently tested for correctness. +[Code coverage](https://en.m.wikipedia.org/wiki/Code_coverage) is a testing metric that tracks the number of branches, lines, and statements in your code executed during tests. Tests should have good code coverage to minimize the risk of untested vulnerabilities. Without sufficient coverage, you might falsely assume your contract is secure because all tests pass, while vulnerabilities still exist in untested code paths. Recording high code coverage, however, gives the assurance all statements/functions in a smart contract were sufficiently tested for correctness. ##### 4. Use well-developed testing frameworks @@ -213,7 +213,7 @@ Running contracts on a local blockchain could be useful as a form of manual inte ### Testing contracts on testnets {#testing-contracts-on-testnets} -A test network or testnet works exactly like Ethereum Mainnet, except that it uses Ether (ETH) with no real-world value. Deploying your contract on a [testnet](/developers/docs/networks/#ethereum-testnets) means anyone can interact with it (e.g., via the dapp's frontend) without putting funds at risk. +A test network or testnet works exactly like Ethereum Mainnet, except that it uses ether (ETH) with no real-world value. Deploying your contract on a [testnet](/developers/docs/networks/#ethereum-testnets) means anyone can interact with it (e.g., via the dapp's frontend) without putting funds at risk. This form of manual testing is useful for evaluating the end-to-end flow of your application from a user’s point of view. Here, beta testers can also perform trial runs and report any issues with the contract’s business logic and overall functionality. diff --git a/public/content/developers/docs/standards/tokens/erc-223/index.md b/public/content/developers/docs/standards/tokens/erc-223/index.md index 76f3f5559c3..a5f61c63e8e 100644 --- a/public/content/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/developers/docs/standards/tokens/erc-223/index.md @@ -129,7 +129,7 @@ contract RecipientContract is IERC223Recipient { { // 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, + // 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); @@ -155,7 +155,7 @@ If an ERC-20 token is sent to the `RecipientContract`, the tokens will be transf ### What if we want to execute some function after the token deposit is completed? {#function-execution} -There are multiple ways of doing so. In this example we will follow the method which makes ERC-223 transfers identical to Ether transfers: +There are multiple ways of doing so. In this example we will follow the method which makes ERC-223 transfers identical to ether transfers: ```solidity contract RecipientContract is IERC223Recipient { @@ -178,7 +178,7 @@ contract RecipientContract is IERC223Recipient { } ``` -When the `RecipientContract` will receive a ERC-223 token the contract will execute a function encoded as `_data` parameter of the token transaction, identical to how Ether transactions encode function calls as transaction `data`. Read [the data field](https://ethereum.org/en/developers/docs/transactions/#the-data-field) for more information. +When the `RecipientContract` will receive a ERC-223 token the contract will execute a function encoded as `_data` parameter of the token transaction, identical to how ether transactions encode function calls as transaction `data`. Read [the data field](https://ethereum.org/en/developers/docs/transactions/#the-data-field) for more information. In the above example an ERC-223 token must be transferred to the address of the `RecipientContract` with the `transfer(address,uin256,bytes calldata _data)` function. If the data parameter will be `0xc2985578` (the signature of a `foo()` function) then the function foo() will be invoked after the token deposit is received and the event Foo() will be fired. diff --git a/public/content/developers/docs/standards/tokens/erc-4626/index.md b/public/content/developers/docs/standards/tokens/erc-4626/index.md index a7429c253a7..d14199ae755 100644 --- a/public/content/developers/docs/standards/tokens/erc-4626/index.md +++ b/public/content/developers/docs/standards/tokens/erc-4626/index.md @@ -16,6 +16,22 @@ ERC-4626 in yield-bearing vaults will lower the integration effort and unlock ac The ERC-4626 token is described fully in [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626). +**Asynchronous vault extension (ERC-7540)** + +ERC-4626 is optimized for atomic deposits and redemptions up to a limit. If the limit is reached, no new deposits or redemptions can be submitted. This limitation does not work well for any smart contract system with asynchronous actions or delays as a prerequisite for interfacing with the Vault (e.g. real-world asset protocols, undercollateralized lending protocols, cross-chain lending protocols, liquid staking tokens, or insurance safety modules). + +ERC-7540 expands the utility of ERC-4626 Vaults for asynchronous use cases. The existing Vault interface (`deposit`/`withdraw`/`mint`/`redeem`) is fully utilized to claim asynchronous Requests. + +The ERC-7540 extension is described fully in [ERC-7540](https://eips.ethereum.org/EIPS/eip-7540). + +**Multi-asset vault extension (ERC-7575)** + +One missing use case that is not supported by ERC-4626 is Vaults which have multiple assets or entry points such as liquidity provider (LP) Tokens. These are generally unwieldy or non-compliant due to the requirement of ERC-4626 to itself be an ERC-20. + +ERC-7575 adds support for Vaults with multiple assets by externalizing the ERC-20 token implementation from the ERC-4626 implementation. + +The ERC-7575 extension is described fully in [ERC-7575](https://eips.ethereum.org/EIPS/eip-7575). + ## Prerequisites {#prerequisites} To better understand this page, we recommend you first read about [token standards](/developers/docs/standards/tokens/) and [ERC-20](/developers/docs/standards/tokens/erc-20/). @@ -176,7 +192,7 @@ Returns the total amount of vault shares the `owner` currently has. #### Deposit Event -**MUST** be emitted when tokens are deposited into the vault via the [`mint`](#mint) and [`deposit`](#deposit) methods +**MUST** be emitted when tokens are deposited into the vault via the [`mint`](#mint) and [`deposit`](#deposit) methods. ```solidity event Deposit( diff --git a/public/content/developers/docs/transactions/index.md b/public/content/developers/docs/transactions/index.md index 5c427727816..687df036351 100644 --- a/public/content/developers/docs/transactions/index.md +++ b/public/content/developers/docs/transactions/index.md @@ -23,7 +23,7 @@ Transactions require a fee and must be included in a validated block. To make th A submitted transaction includes the following information: -- `from` – the address of the sender, that will be signing the transaction. This will be an externally-owned account as contract accounts cannot send transactions. +- `from` – the address of the sender, that will be signing the transaction. This will be an externally-owned account as contract accounts cannot send transactions - `to` – the receiving address (if an externally-owned account, the transaction will transfer value. If a contract account, the transaction will execute the contract code) - `signature` – the identifier of the sender. This is generated when the sender's private key signs the transaction and confirms the sender has authorized this transaction - `nonce` - a sequentially incrementing counter which indicates the transaction number from the account @@ -170,7 +170,7 @@ Any gas not used in a transaction is refunded to the user account. Gas is required for any transaction that involves a smart contract. -Smart contracts can also contain functions known as [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) or [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions) functions, which do not alter the state of the contract. As such, calling these functions from an EOA will not require any gas. The underlying RPC call for this scenario is [`eth_call`](/developers/docs/apis/json-rpc#eth_call) +Smart contracts can also contain functions known as [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) or [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions) functions, which do not alter the state of the contract. As such, calling these functions from an EOA will not require any gas. The underlying RPC call for this scenario is [`eth_call`](/developers/docs/apis/json-rpc#eth_call). Unlike when accessed using `eth_call`, these `view` or `pure` functions are also commonly called internally (i.e. from the contract itself or from another contract) which does cost gas. @@ -209,7 +209,7 @@ Where the fields are defined as: - `TransactionType` - a number between 0 and 0x7f, for a total of 128 possible transaction types. - `TransactionPayload` - an arbitrary byte array defined by the transaction type. -Based on the `TransactionType` value, a transaction can be classified as +Based on the `TransactionType` value, a transaction can be classified as: 1. **Type 0 (Legacy) Transactions:** The original transaction format used since Ethereum's launch. They do not include features from [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) such as dynamic gas fee calculations or access lists for smart contracts. Legacy transactions lack a specific prefix indicating their type in their serialized form, starting with the byte `0xf8` when using [Recursive Length Prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp) encoding. The TransactionType value for these transactions is `0x0`. diff --git a/public/content/guides/how-to-use-a-bridge/index.md b/public/content/guides/how-to-use-a-bridge/index.md index 172b9e9cfc4..eaecafab031 100644 --- a/public/content/guides/how-to-use-a-bridge/index.md +++ b/public/content/guides/how-to-use-a-bridge/index.md @@ -10,7 +10,7 @@ If there is a lot of traffic on Ethereum, it can become expensive. One solution **Prerequisite:** -- have a crypto wallet, you can follow this tutorial: [How to: "Register" an Ethereum account](/guides/how-to-create-an-ethereum-account/) +- have a crypto wallet, you can follow this tutorial: [How to create an Ethereum account](/guides/how-to-create-an-ethereum-account/) - add funds to your wallet ## 1. Determine which layer 2 network you want to use diff --git a/public/content/guides/how-to-use-a-wallet/index.md b/public/content/guides/how-to-use-a-wallet/index.md index 600f2562cc9..f94f3789738 100644 --- a/public/content/guides/how-to-use-a-wallet/index.md +++ b/public/content/guides/how-to-use-a-wallet/index.md @@ -1,5 +1,6 @@ --- title: How to use a wallet +metaTitle: How to use Ethereum Wallets | Step by Step description: A guide explaining how to send, receive tokens and connect to web3 projects. lang: en --- diff --git a/public/content/nft/index.md b/public/content/nft/index.md index e24cf4646db..a93ba806054 100644 --- a/public/content/nft/index.md +++ b/public/content/nft/index.md @@ -1,5 +1,6 @@ --- title: Non-fungible tokens (NFT) +metaTitle: What are NFTs? | Benefits and use description: An overview of NFTs on Ethereum lang: en template: use-cases diff --git a/public/content/payments/computer.png b/public/content/payments/computer.png new file mode 100644 index 00000000000..fb6db5b3ac6 Binary files /dev/null and b/public/content/payments/computer.png differ diff --git a/public/content/payments/eth_robot.png b/public/content/payments/eth_robot.png new file mode 100644 index 00000000000..01db53c69bf Binary files /dev/null and b/public/content/payments/eth_robot.png differ diff --git a/public/content/payments/index.md b/public/content/payments/index.md new file mode 100644 index 00000000000..765aa5bdb01 --- /dev/null +++ b/public/content/payments/index.md @@ -0,0 +1,152 @@ +--- +title: Ethereum Payments +description: An overview of payments on Ethereum +lang: en +template: use-cases +emoji: ":frame_with_picture:" +sidebarDepth: 2 +image: /images/impact_transparent.png +alt: An Eth logo being displayed along with giving hands. +summaryPoint1: A world where money moves as freely as information +summaryPoint2: Open and global, enabling borderless transactions for everyone +summaryPoint3: Payments received within a minute +--- + +Every day, millions of people face the same challenge: moving money across borders is slow, expensive, and often frustrating. A freelancer in Bali waits days for payment to clear from their New York client. This particularly affects people in regions with limited banking infrastructure, making it difficult to participate in the global economy. + +This isn't a far-off dream – it's happening today on Ethereum. While traditional financial institutions have built robust payment systems over decades, they often remain constrained by borders, working hours, and legacy infrastructure. Ethereum offers a new paradigm: a global, 24/7 financial platform that enables near-instant, programmable transactions for anyone with internet access. + +
+ +![Ethereum logo on the computer screen](./computer.png) + +
+ +## Remittances: cheaper international transfers {#remittances} + +For millions of people working abroad, sending money back home is a regular necessity. Traditional remittance services often come with high fees and slow processing times. Ethereum offers a compelling alternative. + + + + + + + +## Access to Global Currencies {#access-to-global-currencies} + +In many countries, inflation is a pressing concern, often accompanied by limited access to foreign currencies. People in these situations struggle to preserve their wealth as they are forced to hold rapidly depreciating savings. + +The Ethereum community has created **a robust alternative financial system** that is independent of any nation’s monetary policies or control. + +Ethereum users can use **stablecoins—tokens typically tied to strong currencies like the US Dollar**. By earning and saving in cryptocurrency, people can protect themselves from high inflation in their country, helping to preserve or even grow their purchasing power. This also enables easier payments for goods and services, both locally and globally. + + + More on stablecoins + + +## Buying Goods and Payment for Services {#buying-goods-and-payment-for-services} + +Many businesses are beginning to accept ether (ETH) and other cryptocurrencies as payment. For example: + +- **Newegg:** The popular electronics retailer accepts Ethereum for purchases in select countries. +- **Travala.com:** This travel booking platform allows users to pay for hotels and flights using Ethereum. +- **Shopify:** This popular E-commerce platform which serves as a platform for hosting businesses also accepts payments for goods and services using Ethereum. +- **Sotheby's:** This organisation trade fine and decorative art, jewellery, and collectibles and allows for payments using Ethereum and other cryptocurrencies. + +Countries like El Salvador and the Central African Republic have even adopted cryptocurrencies as legal tender, paving the way for wider acceptance of Ethereum payments in everyday transactions. + +In countries where their means of payment have been disconnected from the rest of the world, crypto-integrated payment solutions have been a huge relief. Payments of subscriptions for platforms like Netflix, Spotify, and educational courses have now been made easy through crypto payment platforms like Gnosis Pay and Paypal. + + +
Create your Ethereum account with a wallet app today.
+ + Get started + + + +## Salary Payments {#salary-payments} + +Many forward-thinking companies are now offering employees the option to receive their salaries, or a portion of them, in cryptocurrencies like ether (ETH): + +- **Gipsybee:** is an organisation that deals in electronics, robotics, game creation and other services. They give employees the option to get paid in Ethereum. +- **SC5:** This Finnish company was one of the first to offer salaries in Bitcoin, paving the way for similar arrangements with Ethereum. +- **Blockchain startups:** Many companies in the blockchain space naturally offer cryptocurrency salary options to their employees. +- **DAOs:** Due to the peculiarity and diversity of contributors to DAOs, most contributions and salaries are rewarded in cryptocurrency. + +This trend particularly appeals to remote workers and digital nomads who can benefit from borderless payments and potentially favorable exchange rates. + + + +## Global relief efforts {#global-relief-efforts} + +In February 2023, when devastating earthquakes struck Turkey and Syria, the global crypto community sprang into action. Various campaigns were launched to collect funds for relief efforts, showcasing the power of Ethereum in times of crisis. Despite crypto [not being a recognized form](https://www.reuters.com/technology/no-more-kebabs-bitcoins-turkeys-crypto-payment-ban-looms-2021-04-28/) of payment in Turkey, authorities made [exceptions](https://x.com/haluklevent/status/1622913175409623041) for some organizations to collect donations. Some examples are: + +- [Refik Anadol](https://x.com/refikanadol/status/1622623521104089090): is a renowned digital artist who initiated a fundraising campaign. +- DAO Power: [Anka Relief DAO](https://ankarelief.org/) and [Bankless DAO](https://x.com/banklessDAO) joined forces with [Giveth](https://x.com/Giveth/status/1623493672149843969) to raise funds. +- [Pak](https://cause.quest/), a prominent NFT artist, also contributed to the cause. +- Even Ethereum co-founder [Vitalik Buterin](https://cointelegraph.com/news/vitalik-buterin-donates-227k-to-help-earthquake-victims-in-turkey-syria) made personal donations to multiple campaigns. +The result of this? Over $6 million was raised in a matter of days, as tracked by a [Dune](https://dune.com/davy42/turkiye-earthquake-donations) Analytics dashboard. + +There were also similar response times for tragedies that happened in India and Ukraine. This rapid response highlights a crucial advantage of Ethereum payments, which is the ability to quickly mobilize global support without the hurdles of currency conversion, lengthy bank transfers, or exorbitant fees. +
+ +![Ethereum Robot Image](./eth_robot.png) + +
+ +## Ethereum vs fiat {#ethereum-vs-fiat} + +To truly appreciate the impact of Ethereum payments, it's worth comparing them to traditional fiat currencies: + +| | **Ethereum** | **Traditional banks** | +| ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | +| **Speed** | Seconds to minutes | Hours to days | +| **Global Reach** | Borderless, 24/7 | Subject to international banking restrictions and work hours | +| **Transparency** | Fully transparent | Varies by institution | +| **Programmability** | Smart contracts enabled | Limited to basic transactions | +| **Inflation Control** | Predictable issuance | Subject to central bank policies | +| **Accessibility** | Anyone with internet | Subject to national and international restrictions | + +At its core, Ethereum is a decentralized platform that allows for secure, fast, and transparent transactions. However, many components set it apart from traditional payment methods. Let's dive into the benefits that make Ethereum payments a game-changer: + +### Programmability {#programmability} + +One of Ethereum's unique features is its ability to support smart contracts. Smart contracts are self-executing agreements with the terms directly written into code. This opens up a world of possibilities for automated, condition-based payments that can greatly improve transactions like: + +- Escrow services +- Recurring payments +- Performance-based compensation + +### Speed {#speed} + +Do you remember the last time you waited days for an international bank transfer to clear? The long queue? And the multiple forms you had to fill? With Ethereum, those days are long gone. Transactions on the Ethereum network settle in minutes, regardless of where the sender and recipient are located. Due to Ethereum being permissionless, there is no regulatory bureaucracy when sending money. This speed is particularly crucial in time-sensitive situations, such as emergency relief efforts. + +### Lower Fees {#lower-fees} + +Traditional international money transfers fees sometimes eat up a significant portion of the amount sent, especially when dealing with transactions in the hundreds of dollars. Ethereum transactions, while not free, often come with lower fees. This means more of your money goes where you intend it to, rather than lining the pockets of intermediaries. + +### Transparency {#transparency} + +Every transaction on the Ethereum blockchain is recorded on a public ledger. This means anyone can verify the movement of funds, making it an excellent tool for: + +- Charitable organizations to demonstrate how donations are used +- Businesses to prove payments to suppliers or employees +- Individuals to keep track of their financial activities + +With Ethereum, everyone can see how money moves and how costs are implemented, unlike traditional organisations where most of these remain unknown. +
+ +![walking image](./walking.png) + +
+ +While fiat currencies have the advantage of widespread acceptance and stability, Ethereum offers unique benefits that make it an attractive option for certain types of transactions. + +From facilitating rapid disaster relief to empowering global workers, Ethereum payments are writing a new chapter in the long history of money. While challenges remain, the unique advantages offered by this technology make it an attractive option for a wide range of use cases. + + +
Time to get your own Ethereum account.
+ + Get started + + \ No newline at end of file diff --git a/public/content/payments/walking.png b/public/content/payments/walking.png new file mode 100644 index 00000000000..698f5c7a128 Binary files /dev/null and b/public/content/payments/walking.png differ diff --git a/public/content/roadmap/statelessness/index.md b/public/content/roadmap/statelessness/index.md index b09a4397e43..4f3d6b7767a 100644 --- a/public/content/roadmap/statelessness/index.md +++ b/public/content/roadmap/statelessness/index.md @@ -16,7 +16,7 @@ Cheaper hard drives can be used to store older data but those are too slow to ke There are several ways to reduce the amount of data each node has to store, each requiring Ethereum's core protocol to be updated to a different extent: -- **History expiry**: enable nodes to discard state data older than X blocks, but does not change how Ethereum client's handle state data +- **History expiry**: enable nodes to discard state data older than X blocks, but does not change how Ethereum client's handle state data. - **State expiry**: allow state data that is not used frequently to become inactive. Inactive data can be ignored by clients until it is resurrected. - **Weak statelessness**: only block producers need access to full state data, other nodes can verify blocks without a local state database. - **Strong statelessness**: no nodes need access to the full state data. diff --git a/public/content/smart-contracts/index.md b/public/content/smart-contracts/index.md index 64bf7d73a62..afda9c35ba6 100644 --- a/public/content/smart-contracts/index.md +++ b/public/content/smart-contracts/index.md @@ -1,5 +1,6 @@ --- title: Smart contracts +metaTitle: "Smart contracts: What are the and benefits" description: A non-technical introduction to smart contracts lang: en --- @@ -76,7 +77,6 @@ They can perform computations, create currency, store data, mint [NFTs](/glossar ## Further reading {#further-reading} - [How Smart Contracts Will Change the World](https://www.youtube.com/watch?v=pA6CGuXEKtQ) -- [Smart Contracts: The Blockchain Technology That Will Replace Lawyers](https://blockgeeks.com/guides/smart-contracts/) - [Smart contracts for developers](/developers/docs/smart-contracts/) - [Learn to write smart-contracts](/developers/learning-tools/) - [Mastering Ethereum - What is a Smart Contract?](https://github.com/ethereumbook/ethereumbook/blob/develop/07smart-contracts-solidity.asciidoc#what-is-a-smart-contract) diff --git a/public/content/translations/el/community/get-involved/index.md b/public/content/translations/el/community/get-involved/index.md index 08a877b0f09..852412f2f6f 100644 --- a/public/content/translations/el/community/get-involved/index.md +++ b/public/content/translations/el/community/get-involved/index.md @@ -15,15 +15,17 @@ lang: el - Μάθετε σχετικά και δοκιμάστε το Ethereum στο [ethereum.org/developers/](/developers/). - Παρακολουθήστε ένα [ETHGlobal](http://ethglobal.co/) hackathon κοντά σας! - Δείτε τα [έργα που σχετίζονται με τον τομέα που γνωρίζετε καλύτερα ή τη γλώσσα προγραμματισμού της επιλογής σας](/developers/docs/programming-languages/). -- Παρακολουθήστε ή συμμετάσχετε σε μια συνάντηση [Core Dev](https://www.youtube.com/@EthereumProtocol). +- Παρακολουθήστε ή συμμετάσχετε σε μια συνάντηση με θέμα [Επίπεδο Συναίνεσης και Εκτέλεσης](https://www.youtube.com/@EthereumProtocol/streams) - [Λίστα επιθυμιών του Προγράμματος Υποστήριξης Οικοσυστήματος](https://esp.ethereum.foundation/wishlist/) - περιοχές εργαλείων, τεκμηρίωσης και υποδομής όπου το Πρόγραμμα Υποστήριξης Οικοσυστημάτων Ethereum αναζητά ενεργά αιτήσεις χορήγησης. - [Web3Bridge](https://www.web3bridge.com/) - ένταξη στη φιλοδοξία της κοινότητας web3 και την πρωτοβουλία τους να εντοπίσουν, να εκπαιδεύσουν και να υποστηρίξουν εκατοντάδες προγραμματιστές και μέλη της κοινότητας σε όλη την Αφρική. +- Εγγραφείτε στο [Eth R&D Discord](https://discord.com/invite/VmG7Uxc) - Εγγραφείτε στο [Ethereum Cat Herders Discord](https://discord.com/invite/Nz6rtfJ8Cu) ## Ερευνητές & Ακαδημαϊκοί {#researchers-and-academics} Έχετε εμπειρία στα μαθηματικά, την κρυπτογραφία ή τα οικονομικά; Ίσως, ενδιαφέρεστε για κάποιες από τις εργασίες αιχμής που γίνονται στο οικοσύστημα του Ethereum: +- Εγγραφείτε στο [Eth R&D Discord](https://discord.com/invite/VmG7Uxc) - Συντάξτε ή ελέγξτε μια πρόταση βελτίωσης του Ethereum - Συντάξτε μία EIP 1. Υποβάλλετε την ιδέα σας στο [Ethereum Magicians](https://ethereum-magicians.org) diff --git a/public/content/translations/el/community/online/index.md b/public/content/translations/el/community/online/index.md index 9c6e5d55b15..b2929d47b67 100644 --- a/public/content/translations/el/community/online/index.md +++ b/public/content/translations/el/community/online/index.md @@ -8,6 +8,31 @@ lang: el Εκατοντάδες χιλιάδες λάτρεις του Ethereum συγκεντρώνονται σε αυτές τις διαδικτυακές τοποθεσίες για να μοιραστούν ειδήσεις, να μιλήσουν για τις πρόσφατες εξελίξεις, να συζητήσουν τεχνικά ζητήματα και να ονειρευτούν το μέλλον. +## Πολιτική καταχώρησης {#listing-policy} + +Για να διατηρήσει την ακεραιότητα και την αξία των κοινοτήτων που αναφέρονται, το ethereum.org ακολουθεί μια αυστηρή πολιτική για τον προσδιορισμό καταλληλότητας: + +### Κριτήρια επιλεξιμότητας {#eligibility-criteria} + +- **Συνάφεια**: Η κοινότητα πρέπει να σχετίζεται άμεσα με το Ethereum και το οικοσύστημά του. +- **Επίπεδο δραστηριότητας**: Η κοινότητα θα πρέπει να είναι ενεργή, με τακτικές αλληλεπιδράσεις, αναρτήσεις ή συζητήσεις. Οι αδρανείς ή ανενεργές κοινότητες μπορούν να αφαιρεθούν. +- **Συμμετοχικότητα**: Η κοινότητα πρέπει να καλλιεργήσει ένα φιλόξενο περιβάλλον που σέβεται τη διαφορετικότητα και ενθαρρύνει τη συμμετοχή από άτομα κάθε προέλευσης. +- **Μη εμπορική κατεύθυνση**: Οι καταχωρίσεις προορίζονται για χώρους με γνώμονα την κοινότητα και όχι για εμπορικές ή διαφημιστικές πλατφόρμες. + +### Οδηγός περιεχομένου {#content-guidelines} + +- **Κατάλληλο περιεχόμενο**: Οι κοινότητες πρέπει να έχουν τις δικές τους οδηγίες εποπτείας, αποφεύγοντας ανεπιθύμητα μηνύματα, ρητορική μίσους, παρενόχληση ή οποιοδήποτε περιεχόμενο που προωθεί παράνομες δραστηριότητες. +- **Γλώσσα**: Ενώ τα Αγγλικά είναι η κύρια γλώσσα, οι κοινότητες σε άλλες γλώσσες ενθαρρύνονται να υποβάλλουν αίτηση, εφόσον διατηρούν μια ατμόσφαιρα χωρίς αποκλεισμούς και σεβασμό. +- **Διαφάνεια**: Σαφείς πληροφορίες σχετικά με τον σκοπό, τους κανόνες και τους διαχειριστές της κοινότητας θα πρέπει να είναι διαθέσιμες στα μέλη. + +### Άλλες προϋποθέσεις {#other-recommendations} + +- **Προσβασιμότητα**: Τα φόρουμ κοινότητας θα πρέπει να είναι προσβάσιμα από όλους για ανάγνωση χωρίς την ανάγκη εγγραφής ή σύνδεσης. +- **Προσκλήσεις διακομιστή Discord**: Συνιστάται να προστίθενται μόνο αξιόπιστες προσκλήσεις διακομιστή Discord στο ethereum.org. Στην ιδανική περίπτωση, αυτές οι προσκλήσεις θα πρέπει να συνδέονται με μια σελίδα κοινότητας στον ιστότοπο (π.χ., [ethglobal.com/discord](https://ethglobal.com/discord)) ή να προέρχονται από μια επίσημη διεύθυνση URL (π.χ., [discord.gg/ethstaker](https://discord.gg/ethstaker) ή [discord.com/invite/ethstaker](https://discord.com/invite/ethstaker)). + +Εάν πιστεύετε ότι μια κοινότητα πρέπει να προστεθεί ή να αφαιρεθεί με βάση αυτές τις οδηγίες, [ανοίξτε ένα ζήτημα στο GitHub](https://github.com/ethereum/ethereum-org-website/issues). + + ## Φόρουμ {#forums} r/ethereum - όλα για το Ethereum, diff --git a/public/content/translations/el/community/research/index.md b/public/content/translations/el/community/research/index.md index f7266fda53a..3942a7a8c4a 100644 --- a/public/content/translations/el/community/research/index.md +++ b/public/content/translations/el/community/research/index.md @@ -6,21 +6,21 @@ lang: el # Ενεργοί τομείς έρευνας για το Ethereum {#active-areas-of-ethereum-research} -Ένα από τα κύρια πλεονεκτήματα του Ethereum είναι ότι μια ενεργή κοινότητα έρευνας και μηχανικής το βελτιώνει συνεχώς. Πολλοί ενθουσιώδεις, ειδικευμένοι άνθρωποι από όλο τον κόσμο θα ήθελαν να ασχοληθούν με εκκρεμή ζητήματα στο Ethereum, αλλά δεν είναι πάντα εύκολο να μάθετε ποια είναι αυτά τα ζητήματα. Αυτή η σελίδα περιγράφει τους βασικούς ενεργούς ερευνητικούς τομείς μέσα από έναν πρόχειρο οδηγό για την αιχμή του Ethereum. +Ένα από τα κύρια πλεονεκτήματα του Ethereum, είναι ότι μια ενεργή κοινότητα έρευνας και μηχανικής το βελτιώνει συνεχώς. Πολλοί ενθουσιώδεις, ειδικευμένοι άνθρωποι από όλο τον κόσμο θα ήθελαν να ασχοληθούν με εκκρεμή ζητήματα στο Ethereum, αλλά δεν είναι πάντα εύκολο να μάθετε ποια είναι αυτά τα ζητήματα. Αυτή η σελίδα περιγράφει τους βασικούς ενεργούς ερευνητικούς τομείς μέσα από έναν πρόχειρο οδηγό για την αιχμή του Ethereum. ## Πώς λειτουργεί η έρευνα στο Ethereum {#how-ethereum-research-works} -Η έρευνα για το Ethereum είναι ανοιχτή και διαφανής, ενσωματώνοντας τις αρχές της [Αποκεντρωμένης επιστήμης (DeSci)](https://hackernoon.com/desci-decentralized-science-as-our-chance-to-recover-the-real-science). Η κουλτούρα είναι να γίνουν τα ερευνητικά εργαλεία και τα αποτελέσματα όσο το δυνατόν πιο ανοιχτά και διαδραστικά, για παράδειγμα μέσω εκτελέσιμων σημειωματάριων. Η έρευνα για το Ethereum προχωρά γρήγορα, με νέα ευρήματα να δημοσιεύονται και να συζητούνται ανοιχτά σε φόρουμ όπως το [ethresear.ch](https://ethresear.ch/) αντί να φτάνουν στην κοινότητα μέσω των παραδοσιακών δημοσιεύσεων μετά από διαδικασίες αξιολόγησης από διάφορους χρήστες. +Η έρευνα στο Ethereum είναι ανοιχτή και διαφανής, ενσωματώνοντας τις αρχές της [Αποκεντρωμένης Επιστήμης (DeSci)](https://hackernoon.com/desci-decentralized-science-as-our-chance-to-recover-the-real-science). Η κουλτούρα είναι να γίνουν τα ερευνητικά εργαλεία και τα αποτελέσματα όσο το δυνατόν πιο ανοιχτά και διαδραστικά, για παράδειγμα μέσω εκτελέσιμων σημειωματάριων. Η έρευνα για το Ethereum προχωρά γρήγορα, με νέα ευρήματα να δημοσιεύονται και να συζητούνται ανοιχτά σε φόρουμ όπως το [ethresear.ch](https://ethresear.ch/) αντί να φτάνουν στην κοινότητα μέσω παραδοσιακών δημοσιεύσεων μετά από γύρους αξιολόγησης από χρήστες. ## Γενικοί ερευνητικοί πόροι {#general-research-resources} -Ανεξάρτητα από το συγκεκριμένο θέμα, υπάρχει πληθώρα πληροφοριών σχετικά με την έρευνα του Ethereum στη διεύθυνση [ethresear.ch](https://ethresear.ch) και στο [κανάλι Eth R&D του Discord](https://discord.gg/qGpsxSA). Αυτά είναι τα κύρια μέρη όπου οι ερευνητές του Ethereum συζητούν τις τελευταίες ιδέες και ευκαιρίες ανάπτυξης. +Ανεξάρτητα από το συγκεκριμένο θέμα, υπάρχει πληθώρα πληροφοριών σχετικά με την έρευνα του Ethereum στη διεύθυνση [ethresear.ch](https://ethresear.ch) και στο [κανάλι Eth Rd του Discord](https://discord.gg/qGpsxSA). Αυτά είναι τα κύρια μέρη όπου οι ερευνητές του Ethereum συζητούν τις τελευταίες ιδέες και ευκαιρίες ανάπτυξης. Αυτή η αναφορά δημοσιεύτηκε τον Μάιο του 2022 από το [DelphiDigital](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) και παρέχει μια καλή επισκόπηση του οδικού χάρτη του Ethereum. ## Πηγές χρηματοδότησης {#sources-of-funding} -Μπορείτε να εμπλακείτε με την έρευνα για το Ethereum και να πληρωθείτε για αυτό! Για παράδειγμα, το [Ίδρυμα Ethereum](/foundation/) διεξήγαγε πρόσφατα έναν γύρο χρηματοδότησης [Academic Grants](https://esp.ethereum.foundation/academic-grants). Μπορείτε να βρείτε πληροφορίες για ενεργές και επερχόμενες ευκαιρίες χρηματοδότησης στη [σελίδα επιχορηγήσεων του Ethereum](/community/grants/). +Μπορείτε να εμπλακείτε με την έρευνα για το Ethereum και να πληρωθείτε για αυτό! Για παράδειγμα, το [Ίδρυμα Ethereum](/foundation/) διεξήγαγε πρόσφατα έναν [γύρο χρηματοδότησης Academic Grants](https://esp.ethereum.foundation/academic-grants). Μπορείτε να βρείτε πληροφορίες για ενεργές και επερχόμενες ευκαιρίες χρηματοδότησης στη [σελίδα επιχορηγήσεων του Ethereum](/community/grants/). ## Έρευνα πρωτοκόλλου {#protocol-research} @@ -31,48 +31,48 @@ lang: el Η έρευνα συναίνεσης ασχολείται με τον [μηχανισμό της απόδειξης συμμετοχής του Ethereum](/developers/docs/consensus-mechanisms/pos/). Μερικά παραδείγματα συναινετικών ερευνητικών θεμάτων είναι: - ο εντοπισμός και η επιδιόρθωση των τρωτών σημείων. -- την ποσοτικοποίηση κρυπτοοικονομικής ασφάλειας. -- την αύξηση της ασφάλειας ή της απόδοσης των εφαρμογών της εφαρμογής πελάτη. -- και η ανάπτυξη εφαρμογών πελάτη χαμηλών επιδόσεων. +- Η ποσοτικοποίηση κρυπτοοικονομικής ασφάλειας. +- Η αύξηση της ασφάλειας ή της απόδοσης των εφαρμογών της εφαρμογής πελάτη. +- Η ανάπτυξη εφαρμογών πελάτη χαμηλών επιδόσεων. Εκτός από την προοδευτική έρευνα, ερευνώνται ορισμένοι θεμελιώδεις επανασχεδιασμοί του πρωτοκόλλου, όπως η οριστικοποίηση μιας θέσης, ώστε να επιτραπούν σημαντικές βελτιώσεις στο Ethereum. Επιπλέον, η αποτελεσματικότητα, η ασφάλεια και η παρακολούθηση της δικτύωσης από χρήστη σε χρήστη μεταξύ εφαρμογών πελατών συναίνεσης είναι επίσης σημαντικά ερευνητικά θέματα. -#### Επιπλέον πληροφορίες {#background-reading} +#### Απαιτούμενες γνώσεις {#background-reading} -- [Introduction to proof-of-stake](/developers/docs/consensus-mechanisms/pos/) -- [Casper-FFG paper](https://arxiv.org/abs/1710.09437) -- [Επεξηγητής Casper-FFG](https://arxiv.org/abs/1710.09437) -- [Χαρτί Gasper](https://arxiv.org/abs/2003.03052) +- [Είσοδος στην απόδειξη συμμετοχής](/developers/docs/consensus-mechanisms/pos/) +- [Έγγραφο Casper-FFG](https://arxiv.org/abs/1710.09437) +- [Εξήγηση Casper-FFG](https://arxiv.org/abs/1710.09437) +- [Έγγραφο Gasper](https://arxiv.org/abs/2003.03052) #### Πρόσφατη έρευνα {#recent-research} -- [Ethresear.ch Consensus](https://ethresear.ch/c/consensus/29) -- [Δίλημμα διαθεσιμότητας/οριστικοποίησης](https://arxiv.org/abs/2009.04987) -- [Single slot finality](https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259) -- [Διαχωρισμός προτείνοντος - κατασκευαστή](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) +- [Συναίνεση Ethresear.ch](https://ethresear.ch/c/consensus/29) +- [Δίλημμα διαθεσιμότητα ή οριστικοποίηση](https://arxiv.org/abs/2009.04987) +- [Οριστικοποίηση απλής θέσης](https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259) +- [Διαχωρισμός προτείνων - δημιουργού](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) ### Εκτέλεση {#execution} -Το επίπεδο εκτέλεσης ασχολείται με την εκτέλεση των συναλλαγών, τη λειτουργία της [εικονικής μηχανής του Ethereum (EVM)](/developers/docs/evm/) και τη δημιουργία ωφέλιμων φορτίων εκτέλεσης για να περάσουν στο επίπεδο συναίνεσης. Υπάρχουν πολλοί ενεργοί τομείς έρευνας, όπως: +Το επίπεδο εκτέλεσης ασχολείται με την εκτέλεση των συναλλαγών, τη λειτουργία της [εικονικής μηχανής του Ethereum (EVM)](/developers/docs/evm/) και τη δημιουργία ωφέλιμων συναλλαγών εκτέλεσης για να περάσουν στο επίπεδο συναίνεσης. Υπάρχουν πολλοί ενεργοί τομείς έρευνας, όπως: -- τη δημιουργία υποστήριξης για εφαρμογές πελάτη χαμηλών επιδόσεων. -- την έρευνα ορίων των κρατήσεων. -- την ενσωμάτωση νέων δομών δεδομένων (π.χ. Verkle Tries). +- Η δημιουργία υποστήριξης για εφαρμογές πελάτη χαμηλών επιδόσεων. +- Η έρευνα ορίων των κρατήσεων. +- Η ενσωμάτωση νέων δομών δεδομένων (π.χ. Verkle Tries). -#### Επιπλέον πληροφορίες {#background-reading-1} +#### Απαιτούμενες γνώσεις {#background-reading-1} -- [Εισαγωγή στο EVM.](/developers/docs/evm) -- [Εκτελεστικό επίπεδο Ethresear.ch.](https://ethresear.ch/c/execution-layer-research/37) +- [Εισαγωγή στην EVM](/developers/docs/evm) +- [Επίπεδο εκτέλεσης Ethresear.ch](https://ethresear.ch/c/execution-layer-research/37) #### Πρόσφατη έρευνα {#recent-research-1} -- [Βελτιστοποιήσεις βάσεως δεδομένων.](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/db_faq.md) -- [State expiry](https://notes.ethereum.org/@vbuterin/state_expiry_eip) -- [Διαδρομές για τη λήξη κατάστασης.](https://hackmd.io/@vbuterin/state_expiry_paths) -- [Πρόταση λήξης κατάστασης και Verkel.](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal) -- [Διαχείριση ιστορικού.](https://eips.ethereum.org/EIPS/eip-4444) -- [Verkle Trees.](https://vitalik.eth.limo/general/2021/06/18/verkle.html) -- [Δειγματοληψία διαθεσιμότητας δεδομένων](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding) +- [Βελτιστοποιήσεις βάσεων δεδομένων](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/db_faq.md) +- [Ολοκλήρωση κατάστασης](https://notes.ethereum.org/@vbuterin/state_expiry_eip) +- [Διαδρομή για ολοκλήρωση κατάστασης](https://hackmd.io/@vbuterin/state_expiry_paths) +- [Τα Verkle και πρόταση ολοκλήρωσης κατάστασης](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal) +- [Διαχείριση ιστορικού](https://eips.ethereum.org/EIPS/eip-4444) +- [Verkle Trees](https://vitalik.eth.limo/general/2021/06/18/verkle.html) +- [Δείγματα διαθεσιμότητας δεδομένων](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding) ## Ανάπτυξη εφαρμογής πελάτη {#client-development} @@ -80,22 +80,22 @@ lang: el Απαιτείται ένας κόμβος Ethereum για την εκτέλεση δύο τμημάτων του λογισμικού: -1. Ένα πελάτη συναίνεσης για να παρακολουθεί την αρχή της κρυπτοαλυσίδας, τα μπλοκ ενημέρωσης και να χειρίζεται τη λογική συναίνεσης. -2. Ένα πελάτη εκτέλεσης για την υποστήριξη της εικονικής μηχανής Ethereum και την εκτέλεση συναλλαγών και έξυπνων συμβολαίων. +1. Ένας πελάτης συναίνεσης για να παρακολουθεί την αρχή της κρυπτοαλυσίδας, τα μπλοκ ενημέρωσης και να χειρίζεται τη λογική συναίνεσης. +2. Ένας πελάτης εκτέλεσης για την υποστήριξη της εικονικής μηχανής Ethereum και την εκτέλεση συναλλαγών και έξυπνων συμβολαίων. Ανατρέξτε στη [σελίδα κόμβων και πελατών](/developers/docs/nodes-and-clients/) για περισσότερες λεπτομέρειες σχετικά με τους κόμβους και τις εφαρμογές πελάτη και για τη λίστα με όλες τις τρέχουσες υλοποιήσεις πελατών. Μπορείτε επίσης να βρείτε το ιστορικό όλων των αναβαθμίσεων του Ethereum στη [σελίδα ιστορικού](/history/). ### Εφαρμογές πελάτη εκτέλεσης {#execution-clients} - [Προδιαγραφές πελάτη εκτέλεσης](https://github.com/ethereum/execution-specs) -- [Προδιαγραφές ΑΡΙ εκτέλεσης](https://github.com/ethereum/execution-apis) +- [Προδιαγραφές API εκτέλεσης](https://github.com/ethereum/execution-apis) ### Εφαρμογές πελάτη συναίνεσης {#consensus-clients} - [Προδιαγραφές πελάτη συναίνεσης](https://github.com/ethereum/consensus-specs) -- [Προδιαγραφή κεντρικού API](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot) +- [Προδιαγραφές Beacon API](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot) -## Κλιμακωτή αναβάθμιση και απόδοση {#scaling-and-performance} +## Αναβάθμιση και επιδόσεις {#scaling-and-performance} Η κλιμακωτή αναβάθμιση του Ethereum είναι μια μεγάλη περιοχή εστίασης για τους ερευνητές του Ethereum. Οι τρέχουσες προσεγγίσεις περιλαμβάνουν τη μεταφόρτωση συναλλαγών σε πακέτα ενημέρωσης και την όσο το δυνατόν φθηνότερη χρέωση χρησιμοποιώντας σύνολα δεδομένων. Εισαγωγικές πληροφορίες σχετικά με την κλιμακωτή αναβάθμιση του Ethereum είναι διαθέσιμες στη [σελίδα κλιμακωτής αναβάθμισης](/developers/docs/scaling). @@ -103,28 +103,28 @@ lang: el Υπάρχουν πολλά πρωτόκολλα επιπέδου 2 που αναβαθμίζουν κλιμακωτά το Ethereum χρησιμοποιώντας διαφορετικές τεχνικές για την ομαδοποίηση των συναλλαγών και την ασφάλισή τους στο επίπεδο 1 του Ethereum. Αυτό είναι ένα πολύ ταχέως αναπτυσσόμενο ζήτημα με πολλές δυνατότητες έρευνας και ανάπτυξης. -#### Επιπλέον πληροφορίες {#background-reading-2} +#### Απαιτούμενες γνώσεις {#background-reading-2} - [Εισαγωγή στο επίπεδο 2](/layer-2/) - [Polynya: Πακέτα ενημέρωσης, DA και αρθρωτές αλυσίδες](https://polynya.medium.com/rollups-data-availability-layers-modular-blockchains-introductory-meta-post-5a1e7a60119d) #### Πρόσφατη έρευνα {#recent-research-2} -- [Arbitrum's fair-ordering for sequencers](https://eprint.iacr.org/2021/1465) -- [ethresear.ch Επίπεδο 2](https://ethresear.ch/c/layer-2/32) -- [Οδικός χάρτης των πακέτων ενημέρωσης](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) +- [Arbitrum's δίκαιη εντολή για ακολουθίες](https://eprint.iacr.org/2021/1465) +- [ethresear.ch επίπεδο 2](https://ethresear.ch/c/layer-2/32) +- [Οδικός χάρτης Rollup-centric](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) - [L2Beat](https://l2beat.com/) ### Γέφυρες {#bridges} Μια συγκεκριμένη περιοχή του επιπέδου 2 που απαιτεί περισσότερη έρευνα και ανάπτυξη, είναι οι ασφαλείς και αποτελεσματικές γέφυρες. Αυτό περιλαμβάνει γέφυρες μεταξύ διαφόρων επιπέδων 2 και γέφυρες μεταξύ του επιπέδου 1 και του επιπέδου 2. Αυτός είναι ένας ιδιαίτερα σημαντικός τομέας έρευνας επειδή οι γέφυρες στοχοποιούνται συνήθως από χάκερ. -#### Επιπλέον πληροφορίες {#background-reading-3} +#### Απαιτούμενες γνώσεις {#background-reading-3} - [Εισαγωγή στις γέφυρες κρυπτοαλυσίδων](/bridges/) - [Ο Vitalik για τις γέφυρες](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/) -- [Το άρθρο για τις γέφυρες κρυπτοαλυσίδας](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) -- [Κλειδωμένη αξία στις γέφυρες]() +- [Άρθρο για τις γέφυρες Blockchain](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) +- [Κλειδωμένη αξία στις γέφυρες](https://dune.com/eliasimos/Bridge-Away-\(from-Ethereum\)) #### Πρόσφατη έρευνα {#recent-research-3} @@ -132,13 +132,17 @@ lang: el ### Τμηματοποίηση {#sharding} -Το τμηματοποίηση της κρυπτοαλυσίδας του Ethereum αποτελεί εδώ και καιρό μέρος του οδικού χάρτη ανάπτυξης. Ωστόσο, νέες λύσεις κλιμακωτής αναβάθμισης όπως το «Danksharding» βρίσκονται επί του παρόντος στο επίκεντρο. +Η τμηματοποίηση της κρυπτοαλυσίδας του Ethereum αποτελεί εδώ και καιρό μέρος του οδικού χάρτη ανάπτυξης. Ωστόσο, νέες λύσεις κλιμακωτής αναβάθμισης όπως το «Danksharding» βρίσκονται επί του παρόντος στο επίκεντρο. -#### Επιπλέον πληροφορίες {#background-reading-4} +Ο πρόδρομος του πλήρους Danksharding γνωστό ως Proto-Danksharding κυκλοφόρησε με την αναβάθμιση του δικτύου Cancun-Deneb (Dencun). + +[Περισσότερα σχετικά με την αναβάθμιση Dencun](/roadmap/dencun/) + +#### Απαιτούμενες γνώσεις {#background-reading-4} - [Σημειώσεις Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) -- [Βίντεο Danksharding χωρίς τράπεζα](https://www.youtube.com/watch?v=N5p0TB77flM) -- [Ethereum Sharding Research Compendium](https://notes.ethereum.org/@serenity/H1PGqDhpm?type=view) +- [Βίντεο Bankless Danksharding](https://www.youtube.com/watch?v=N5p0TB77flM) +- [Η επιτομή έρευνας για το Sharding του Ethereum](https://notes.ethereum.org/@serenity/H1PGqDhpm?type=view) - [Danksharding (Polynya)](https://polynya.medium.com/danksharding-36dc0c8067fe) #### Πρόσφατη έρευνα {#recent-research-4} @@ -148,25 +152,25 @@ lang: el ### Εξοπλισμός {#hardware} -[Η εκτέλεση κόμβων](/developers/docs/nodes-and-clients/run-a-node/) σε σύγχρονο υλικό είναι θεμελιώδους σημασίας για τη διατήρηση του Ethereum αποκεντρωμένο. Επομένως, η ενεργός έρευνα για την ελαχιστοποίηση των απαιτήσεων υλικού για την εκτέλεση κόμβων είναι ένας σημαντικός τομέας έρευνας. +Η [εκτέλεση κόμβων](/developers/docs/nodes-and-clients/run-a-node/) σε σύγχρονο υλικό είναι θεμελιώδους σημασίας για τη διατήρηση του Ethereum αποκεντρωμένο. Επομένως, η ενεργός έρευνα για την ελαχιστοποίηση των απαιτήσεων υλικού για την εκτέλεση κόμβων είναι ένας σημαντικός τομέας έρευνας. -#### Επιπλέον πληροφορίες {#background-reading-5} +#### Απαιτούμενες γνώσεις {#background-reading-5} -- [Ethereum στο ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) +- [Το Ethereum στο ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) #### Πρόσφατη έρευνα {#recent-research-5} -- [ecdsa σε FPGAs](https://ethresear.ch/t/does-ecdsa-on-fpga-solve-the-scaling-problem/6738) +- [Το ecdsa στο FPGAs](https://ethresear.ch/t/does-ecdsa-on-fpga-solve-the-scaling-problem/6738) ## Ασφάλεια {#security} Η ασφάλεια είναι ένα ευρύ θέμα που μπορεί να περιλαμβάνει την πρόληψη ανεπιθύμητης αλληλογραφίας/απάτης, την ασφάλεια πορτοφολιού, την ασφάλεια υλικού, την κρυπτοοικονομική ασφάλεια, την αναζήτηση σφαλμάτων και τη δοκιμή εφαρμογών και λογισμικού πελατών και διαχείριση των κλειδιών. Η συμβολή στη γνώση σε αυτούς τους τομείς θα συμβάλει στην τόνωση της γενικής υιοθέτησης. -### Κρυπτογραφία & ZKP {#cryptography--zkp} +### Κρυπτογράφηση και ZKP {#cryptography--zkp} -Οι αποδείξεις μηδενικής γνώσης (ZKP) και η κρυπτογραφία είναι ζωτικής σημασίας για τη δημιουργία απορρήτου και ασφάλειας στο Ethereum και τις εφαρμογές του. Η μηδενική γνώση είναι ένας σχετικά νέος αλλά ταχύτατος χώρος με πολλές ανοιχτές ευκαιρίες έρευνας και ανάπτυξης. Ορισμένες δυνατότητες περιλαμβάνουν την ανάπτυξη πιο αποτελεσματικών υλοποιήσεων του [αλγόριθμου κατακερματισμού Keccak](https://hackmd.io/sK7v0lr8Txi1bgION1rRpw?view#Overview), την εύρεση καλύτερων πολυωνυμικών δεσμεύσεων που υπάρχουν σήμερα ή τη μείωση του κόστους του ecdsa των κυκλωμάτων επαλήθευσης και δημιουργίας δημόσιου κλειδιού και υπογραφής. +Οι αποδείξεις μηδενικής γνώσης (ZKP) και η κρυπτογραφία είναι ζωτικής σημασίας για τη δημιουργία απορρήτου και ασφάλειας στο Ethereum και τις εφαρμογές του. Η μηδενική γνώση είναι ένας σχετικά νέος αλλά ταχύτατος χώρος με πολλές ανοιχτές ευκαιρίες έρευνας και ανάπτυξης. Ορισμένες δυνατότητες περιλαμβάνουν την ανάπτυξη πιο αποτελεσματικών υλοποιήσεων του [αλγόριθμου κατακερματισμού Keccak[Keccak hashing algorithm](https://hackmd.io/sK7v0lr8Txi1bgION1rRpw?view#Overview), την εύρεση καλύτερων πολυωνυμικών δεσμεύσεων που υπάρχουν σήμερα ή τη μείωση του κόστους του ecdsa των κυκλωμάτων επαλήθευσης και δημιουργίας δημόσιου κλειδιού και υπογραφής. -#### Επιπλέον πληροφορίες {#background-reading-6} +#### Απαιτούμενες γνώσεις {#background-reading-6} - [Ιστολόγιο 0xparc](https://0xparc.org/blog) - [zkp.science](https://zkp.science/) @@ -181,22 +185,22 @@ lang: el Τα πορτοφόλια Ethereum μπορεί να είναι επεκτάσεις προγράμματος περιήγησης, εφαρμογές για υπολογιστές και κινητά ή έξυπνα συμβόλαια στο Ethereum. Υπάρχει ενεργή έρευνα για τα πορτοφόλια ανάκτησης κοινωνικής δικτύωσης που μειώνουν μέρος του κινδύνου που σχετίζεται με τη διαχείριση κλειδιών των μεμονωμένων χρηστών. Η έρευνα για εναλλακτικές μορφές υλοποίησης λογαριασμών συνδέεται με την ανάπτυξη πορτοφολιών, η οποία είναι ένας σημαντικός τομέας της εκκολαπτόμενης έρευνας. -#### Επιπλέον πληροφορίες {#background-reading-7} +#### Απαιτούμενες γνώσεις {#background-reading-7} - [Εισαγωγή στα πορτοφόλια](/wallets/) - [Εισαγωγή στην ασφάλεια πορτοφολιού](/security/) - [Ασφάλεια ethresear.ch](https://ethresear.ch/tag/security) -- [EIP-2938 Account Abstraction](https://eips.ethereum.org/EIPS/eip-2938) -- [EIP-4337 Account Abstraction](https://eips.ethereum.org/EIPS/eip-4337) +- [EIP-2938 Αφαιρετικότητα λογαριασμού](https://eips.ethereum.org/EIPS/eip-2938) +- [EIP-4337 Αφαιρετικότητα λογαριασμού](https://eips.ethereum.org/EIPS/eip-4337) #### Πρόσφατη έρευνα {#recent-research-7} -- [Πορτοφόλια έξυπνων συμβολαίων εστιασμένων στην επικύρωση](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603) +- [Πορτοφόλια έξυπνων συμβολαίων εστιασμένα στην επικύρωση](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603) - [Το μέλλον των λογαριασμών](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603) - [EIP-3074 AUTH και AUTHCALL Opcodes](https://eips.ethereum.org/EIPS/eip-3074) -- [Δημοσίευση κώδικα σε διεύθυνση ΕΟΑ](https://eips.ethereum.org/EIPS/eip-5003) +- [Δημοσίευση κώδικα σε διεύθυνση EOA](https://eips.ethereum.org/EIPS/eip-5003) -## Κοινότητα, εκπαίδευση και προβολή {#community-education-and-outreach} +## Κοινότητα, εκπαίδευση και έρευνα {#community-education-and-outreach} Η προσθήκη νέων χρηστών στο Ethereum απαιτεί νέους εκπαιδευτικούς πόρους και προσεγγίσεις ενημέρωσης. Αυτό μπορεί να περιλαμβάνει αναρτήσεις και άρθρα ιστολογίου, βιβλία, podcast, memes, εκδηλώσεις ενημέρωσης και οτιδήποτε άλλο δημιουργεί κοινότητες, καλωσορίζει νέους αρχάριους και εκπαιδεύει τους ανθρώπους σχετικά με το Ethereum. @@ -204,77 +208,77 @@ lang: el Για να ενσωματωθούν περισσότερα άτομα στο Ethereum, το οικοσύστημα πρέπει να βελτιώσει το UX/UI. Αυτό θα απαιτήσει από τους σχεδιαστές και τους ειδικούς προϊόντων να επανεξετάσουν τον σχεδιασμό των πορτοφολιών και των εφαρμογών. -#### Επιπλέον πληροφορίες {#background-reading-8} +#### Απαιτούμενες γνώσεις {#background-reading-8} - [Ethresear.ch UX/UI](https://ethresear.ch/c/ui-ux/24) #### Πρόσφατη έρευνα {#recent-research-8} -- [Discord σχεδίασης Web3](https://discord.gg/FsCFPMTSm9) -- [Οι αρχές σχεδιασμού Web3](https://www.web3designprinciples.com/) +- [Discord Σχεδίασης Web3](https://discord.gg/FsCFPMTSm9) +- [Αρχές Σχεδιασμού Web3](https://www.web3designprinciples.com/) - [Συζήτηση Ethereum Magicians UX](https://ethereum-magicians.org/t/og-council-ux-follow-up/9032/3) ### Οικονομικά {#economics} Η οικονομική έρευνα στο Ethereum ακολουθεί σε γενικές γραμμές δύο προσεγγίσεις: την επικύρωση της ασφάλειας των μηχανισμών που βασίζονται σε οικονομικά κίνητρα («μικροοικονομία») και την ανάλυση των ροών αξίας μεταξύ των πρωτοκόλλων, των εφαρμογών και των χρηστών («μακροοικονομία»). Υπάρχουν περίπλοκοι κρυπτοοικονομικοί παράγοντες που σχετίζονται με το εγγενές κρυπτονόμισμα του Ethereum (ether) και τα κρυπτονομίσματα που έχουν δημιουργηθεί πάνω σε αυτό (για παράδειγμα τα NFT και τα κρύπτο ERC20). -#### Επιπλέον πληροφορίες {#background-reading-9} +#### Απαιτούμενες γνώσεις {#background-reading-9} - [Robust Incentives Group](https://ethereum.github.io/rig/) -- [Ομάδα εργασίας ETHconomics στο Devconnect](https://www.youtube.com/playlist?list=PLTLjFJ0OQOj5PHRvA2snoOKt2udVsyXEm) +- [Ομάδα εργασίας οικονομικών ETH στο Devconnect](https://www.youtube.com/playlist?list=PLTLjFJ0OQOj5PHRvA2snoOKt2udVsyXEm) #### Πρόσφατη έρευνα {#recent-research-9} -- [Εμπειρική ανάλυση EIP1559](https://arxiv.org/abs/2201.05574) +- [Εμπειρική ανάλυση του EIP1559](https://arxiv.org/abs/2201.05574) - [Circulating supply equilibrium](https://ethresear.ch/t/circulating-supply-equilibrium-for-ethereum-and-minimum-viable-issuance-during-the-proof-of-stake-era/10954) -- [Quantifying MEV: Πόσο σκοτεινό είναι το δάσος;](https://arxiv.org/abs/2101.05511) +- [Ποσοτικοποίηση MEV: Πόσο σκοτεινό είναι το δάσος;](https://arxiv.org/abs/2101.05511) -### Blockspace και αγορές τελών {#blockspace-fee-markets} +### Blockspace και αγορές κρατήσεων {#blockspace-fee-markets} Οι αγορές blockspace διέπουν τη συμπερίληψη συναλλαγών τελικού χρήστη, είτε απευθείας στο Ethereum (Επίπεδο 1) είτε σε γεφυρωμένα δίκτυα, π.χ. πακέτα ενημέρωσης (Επίπεδο 2). Στο Ethereum, οι συναλλαγές υποβάλλονται στην αγορά χρεώσεων που αναπτύσσονται εντός του πρωτοκόλλου ως EIP-1559, προστατεύοντας την αλυσίδα από ανεπιθύμητα μηνύματα και συμφόρηση τιμολόγησης. Και στα δύο επίπεδα, οι συναλλαγές μπορεί να παράγουν εξωτερικές επιδράσεις, γνωστές ως Μέγιστη Εξαγώγιμη Αξία (MEV), οι οποίες παρακινούν τις νέες δομές της αγοράς να συμπεριλάβουν ή να διαχειριστούν αυτές τις εξωτερικές επιδράσεις. -#### Επιπλέον πληροφορίες {#background-reading-10} +#### Απαιτούμενες γνώσεις {#background-reading-10} -- [Σχεδιασμός Μηχανισμού Χρεώσεων Συναλλαγών για την κρυπτοαλυσίδα του Ethereum: Μια οικονομική ανάλυση του EIP-1559 (Tim Roughgarden, 2020)](https://timroughgarden.org/papers/eip1559.pdf) -- [Προσομοιώσεις EIP-1559 (Robust Incentives Group)](https://ethereum.github.io/abm1559) -- [Πακέτα ενημέρωσης οικονομικών από τις πρώτες αρχές](https://barnabe.substack.com/p/understanding-rollup-economics-from?utm_source=url) +- [Σχεδιασμός μηχανισμού κρατήσεων για το Ethereum Blockchain: An Economic Analysis of EIP-1559 (Tim Roughgarden, 2020)](https://timroughgarden.org/papers/eip1559.pdf) +- [Προσομοίωση του EIP-1559 (Robust Incentives Group)](https://ethereum.github.io/abm1559) +- [Οικονομικά πακέτων ενημέρωσης από την πρώτη Αρχή](https://barnabe.substack.com/p/understanding-rollup-economics-from?utm_source=url) - [Flash Boys 2.0: Αρχική εκτέλεση, αναδιάταξη συναλλαγών και αστάθεια συναίνεσης σε αποκεντρωμένα χρηματιστήρια](https://arxiv.org/abs/1904.05234) #### Πρόσφατη έρευνα {#recent-research-10} - [Πολυδιάστατη παρουσίαση βίντεο EIP-1559](https://youtu.be/QbR4MTgnCko) -- [MEV μεταξύ ονομάτων τομέα](http://arxiv.org/abs/2112.01472) -- [Ενέργειες MEV](https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788) +- [Cross domain MEV](http://arxiv.org/abs/2112.01472) +- [Λειτουργίες MEV](https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788) -### Κίνητρα της απόδειξης συμμετοχής {#proof-of-stake-incentives} +### Κίνητρα απόδειξης συμμετοχής {#proof-of-stake-incentives} Οι επικυρωτές χρησιμοποιούν το εγγενές κρυπτονόμισμα (ether) του Ethereum ως εγγύηση έναντι της ανέντιμης συμπεριφοράς. Αυτή η κρυπτοοικονομία καθορίζει την ασφάλεια του δικτύου. Οι εξελιγμένοι επικυρωτές μπορεί να είναι σε θέση να εκμεταλλευτούν τις εκδοχές του επιπέδου κινήτρων για να εξαπολύσουν ρητές επιθέσεις. -#### Επιπλέον πληροφορίες {#background-reading-11} +#### Απαιτούμενες γνώσεις {#background-reading-11} -- [Εξειδικευμένα οικονομικά του Ethereum και οικονομικό μοντέλο](https://github.com/CADLabs/ethereum-economic-model) +- [Masterclass οικονομικών Ethereum και οικονομικό μοντέλο](https://github.com/CADLabs/ethereum-economic-model) - [Προσομοιώσεις κινήτρων PoS (Robust Incentives Group)](https://ethereum.github.io/beaconrunner/) #### Πρόσφατη έρευνα {#recent-research-11} -- [Αυξάνοντας την αντίσταση στη λογοκρισία των συναλλαγών στο πλαίσιο του διαχωρισμού προτείνοντα/κατασκευαστή (PBS)](https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ) +- [Αυξάνοντας την αντίσταση στη λογοκρισία των συναλλαγών υπό διαχωρισμό προτείνοντα/κατασκευαστή (PBS)](https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ) - [Τρεις επιθέσεις στο PoS Ethereum](https://arxiv.org/abs/2110.10086) -### Κυμαινόμενο αποθηκευμένο κεφάλαιο και παράγωγα {#liquid-staking-and-derivatives} +### Αποθήκευση κεφαλαίου ρευστότητας και παράγωγα {#liquid-staking-and-derivatives} Το κυμαινόμενο αποθηκευμένο κεφάλαιο επιτρέπει στους χρήστες με λιγότερα από 32 ETH, να λαμβάνουν αποδόσεις από κεφάλαιό τους ανταλλάσσοντας το ether με ένα κρυπτονόμισμα που αντιπροσωπεύει το αποθηκευμένο ether και μπορεί να χρησιμοποιηθεί στο DeFi. Ωστόσο, τα κίνητρα και η δυναμική της αγοράς που σχετίζονται με το κυμαινόμενο αποθηκευμένο κεφάλαιο εξακολουθούν να βρίσκονται υπό έρευνα, καθώς και η επίδρασή του στην ασφάλεια του Ethereum (π.χ. κίνδυνοι συγκέντρωσης). -#### Επιπλέον πληροφορίες {#background-reading-12} +#### Απαιτούμενες γνώσεις {#background-reading-12} -- [Ethresear.ch κυμαινόμενο αποθηκευμένο κεφάλαιο](https://ethresear.ch/search?q=liquid%20staking) -- [Lido: Ο δρόμος για την αποθήκευση κεφαλαίο στο Ethereum χωρίς την ανάγκη παροχής εμπιστοσύνης](https://blog.lido.fi/the-road-to-trustless-ethereum-staking/) -- [Rocket Pool: Εισαγωγή στο πρωτόκολλο αποθήκευσης κεφαλαίου](https://medium.com/rocket-pool/rocket-pool-staking-protocol-part-1-8be4859e5fbd) +- [Αποθήκευση ρευστότητας Ethresear.ch](https://ethresear.ch/search?q=liquid%20staking) +- [Lido: Ο δρόμος στην αποθήκευση κεφαλαίου στο Ethereum χωρίς παροχή εμπιστοσύνης](https://blog.lido.fi/the-road-to-trustless-ethereum-staking/) +- [Δεξαμενή Rocket: Εισαγωγή στο πρωτόκολλο αποθήκευσης](https://medium.com/rocket-pool/rocket-pool-staking-protocol-part-1-8be4859e5fbd) #### Πρόσφατη έρευνα {#recent-research-12} -- [Χειρισμός αναλήψεων από το Lido](https://ethresear.ch/t/handling-withdrawals-in-lidos-eth-liquid-staking-protocol/8873) -- [Πιστοποιητικά ανάληψης](https://ethresear.ch/t/withdrawal-credential-rotation-from-bls-to-eth1/8722) -- [Οι κίνδυνοι των παραγώγων κυμαινόμενου αποθηκευμένου κεφαλαίου](https://notes.ethereum.org/@djrtwo/risks-of-lsd) +- [Διαχείριση αναλήψεων από το Lido](https://ethresear.ch/t/handling-withdrawals-in-lidos-eth-liquid-staking-protocol/8873) +- [Διαπιστευτήρια ανάληψης](https://ethresear.ch/t/withdrawal-credential-rotation-from-bls-to-eth1/8722) +- [Οι κίνδυνοι των παραγώγων ρευστοποίησης κεφαλαίου](https://notes.ethereum.org/@djrtwo/risks-of-lsd) ## Δοκιμή {#testing} @@ -282,23 +286,23 @@ lang: el Η επίσημη επαλήθευση είναι η σύνταξη κώδικα για την επαλήθευση ότι οι συναινετικές προδιαγραφές του Ethereum είναι σωστές και χωρίς σφάλματα. Υπάρχει μια εκτελέσιμη έκδοση της προδιαγραφής γραμμένη σε Python που απαιτεί συντήρηση και ανάπτυξη. Περαιτέρω έρευνα μπορεί να βοηθήσει στη βελτίωση της εφαρμογής Python της προδιαγραφής και την προσθήκη εργαλείων που μπορούν να επαληθεύσουν πιο σθεναρά την ορθότητα και τον εντοπισμό προβλημάτων. -#### Επιπλέον πληροφορίες {#background-reading-13} +#### Απαιτούμενες γνώσεις {#background-reading-13} - [Εισαγωγή στην επίσημη επαλήθευση](https://ptolemy.berkeley.edu/projects/embedded/research/vis/doc/VisUser/vis_user/node4.html) - [Επίσημη επαλήθευση (Intel)](https://www.cl.cam.ac.uk/~jrh13/papers/mark10.pdf) #### Πρόσφατη έρευνα {#recent-research-13} -- [Επίσημη επαλήθευση του συμβολαίου κατάθεσης](https://github.com/runtimeverification/deposit-contract-verification) -- [Επίσημη επαλήθευση της προδιαγραφής Κύριας Αλυσίδας](https://github.com/runtimeverification/deposit-contract-verification) +- [Επίσημη επαλήθευση του συμβολαίου αποθήκευσης κεφαλαίου](https://github.com/runtimeverification/deposit-contract-verification) +- [Επίσημη επαλήθευση των προδιαγραφών της Κύριας αλυσίδας](https://github.com/runtimeverification/deposit-contract-verification) ## Επιστήμη και ανάλυση δεδομένων {#data-science-and-analytics} Υπάρχει ανάγκη για περισσότερα εργαλεία ανάλυσης δεδομένων και πίνακες εργαλείων που παρέχουν λεπτομερείς πληροφορίες σχετικά με τη δραστηριότητα στο Ethereum και την υγεία του δικτύου. -### Επιπλέον πληροφορίες {#background-reading-14} +### Απαιτούμενες γνώσεις {#background-reading-14} -- [Dune Analytics](https://dune.com/browse/dashboards) +- [Ανάλυση Dune](https://dune.com/browse/dashboards) - [Πίνακας ελέγχου διαφορετικότητας πελατών](https://clientdiversity.org/) #### Πρόσφατη έρευνα {#recent-research-14} @@ -313,84 +317,83 @@ lang: el Η αποκεντρωμένη χρηματοδότηση (DeFi) είναι μια από τις κύριες κατηγορίες εφαρμογών που έχουν δημιουργηθεί πάνω από το Ethereum. Το DeFi στοχεύει να δημιουργήσει συνθέσιμα «legos χρημάτων» που επιτρέπουν στους χρήστες να αποθηκεύουν, να μεταφέρουν, να δανείζουν, να δανείζονται και να επενδύουν κρυπτονομίσματα χρησιμοποιώντας έξυπνα συμβόλαια. Το DeFi είναι ένας γρήγορος χώρος που ενημερώνεται συνεχώς. Απαιτείται συνεχώς έρευνα για ασφαλή, αποτελεσματικά και προσβάσιμα πρωτόκολλα. -#### Επιπλέον πληροφορίες {#background-reading-15} +#### Απαιτούμενες γνώσεις {#background-reading-15} - [DeFi](/defi/) - [Coinbase: Τι είναι το DeFi;](https://www.coinbase.com/learn/crypto-basics/what-is-defi) #### Πρόσφατη έρευνα {#recent-research-15} -- [Αποκεντρωμένη οικονομία, συγκεντρωτική ιδιοκτησία;](https://arxiv.org/pdf/2012.09306.pdf) -- [Optimism: Ο δρόμος προς τις συναλλαγές υπό του δολαρίου](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) +- [Αποκεντρωμένη χρηματοπιστωτική, κεντρική ιδιοκτησία;](https://arxiv.org/pdf/2012.09306.pdf) +- [Optimism: Ο δρόμος για συναλλαγές κάτω του δολαρίου](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) ### DAOs {#daos} Μια χρήσιμη περίπτωση χρήσης για το Ethereum είναι η ικανότητα οργάνωσης με αποκεντρωμένο τρόπο μέσω της χρήσης DAO. Υπάρχει πολλή ενεργή έρευνα για το πώς οι DAO στο Ethereum μπορούν να αναπτυχθούν και να χρησιμοποιηθούν για την εκτέλεση βελτιωμένων μορφών διακυβέρνησης, ως εργαλείο συντονισμού απεξαρτημένο από την ανάγκη εμπιστοσύνης, διευρύνοντας σημαντικά τις επιλογές των ανθρώπων πέρα από τις παραδοσιακές εταιρείες και οργανισμούς. -#### Επιπλέον πληροφορίες {#background-reading-16} +#### Απαιτούμενες γνώσεις {#background-reading-16} -- [Εισαγωγή στους DAO](/dao/) +- [Εισαγωγή στους DAO/](/dao/) - [Συλλογή Dao](https://daocollective.xyz/) #### Πρόσφατη έρευνα {#recent-research-16} -- [Χαρτογράφηση του οικοσυστήματος DAO](https://www.researchgate.net/publication/358694594_Mapping_out_the_DAO_Ecosystem_and_Assessing_DAO_Autonomy) +- [Καταγράφοντας το οικοσύστημα DAO](https://www.researchgate.net/publication/358694594_Mapping_out_the_DAO_Ecosystem_and_Assessing_DAO_Autonomy) -### Εργαλεία προγραμματιστών {#developer-tools} +### Εργαλεία ανάπτυξης {#developer-tools} Τα εργαλεία για προγραμματιστές Ethereum βελτιώνονται γρήγορα. Υπάρχει πολλή ενεργή έρευνα και ανάπτυξη να γίνει σε αυτόν τον γενικό τομέα. -#### Επιπλέον πληροφορίες {#background-reading-17} +#### Απαιτούμενες γνώσεις {#background-reading-17} - [Εργαλεία ανά γλώσσα προγραμματισμού](/developers/docs/programming-languages/) -- [Πλαίσια ανάπτυξης](/developers/docs/frameworks/) -- [Λίστα εργαλείων προγραμματιστών συναίνεσης](https://github.com/ConsenSys/ethereum-developer-tools-list) -- [Πρότυπα ψηφιακού στοιχείου](/developers/docs/standards/tokens/) -- [Biastek: Εργαλεία Ethereum](https://biastek.com/ethereum-tools/) +- [Developer Frameworks](/developers/docs/frameworks/) +- [Λίστα εργαλείων ανάπτυξης Συναίνεσης](https://github.com/ConsenSys/ethereum-developer-tools-list) +- [Πρότυπα κρυπτονομισμάτων](/developers/docs/standards/tokens/) - [CryptoDevHub: Εργαλεία EVM](https://cryptodevhub.io/wiki/ethereum-virtual-machine-tools) #### Πρόσφατη έρευνα {#recent-research-17} -- [Eth R&D Κανάλι Discord εργαλείων συναίνεσης](https://discordapp.com/channels/595666850260713488/746343380900118528) +- [Κανάλι Discord Eth R&D εργαλείων συναίνεσης](https://discordapp.com/channels/595666850260713488/746343380900118528) ### Oracles {#oracles} Η Oracles εισάγει δεδομένα εκτός αλυσίδας στο blockchain με τρόπο χωρίς την ανάγκη άδειας και αποκεντρωμένο. Η λήψη αυτών των δεδομένων εντός της αλυσίδας επιτρέπει στις dapp να αντιδρούν σε καταστάσεις του πραγματικού κόσμου, όπως τις διακυμάνσεις τιμών σε οικονομικά στοιχεία του πραγματικού κόσμου, συμβάντα σε εφαρμογές εκτός αλυσίδας ή ακόμα και αλλαγές στον καιρό. -#### Επιπλέον πληροφορίες {#background-reading-18} +#### Απαιτούμενες γνώσεις {#background-reading-18} - [Εισαγωγή στην Oracles](/developers/docs/oracles/) #### Πρόσφατη έρευνα {#recent-research-18} -- [Έρευνα blockchain oracles](https://arxiv.org/pdf/2004.07140.pdf) +- [Δημοσκόπηση για blockchain oracles](https://arxiv.org/pdf/2004.07140.pdf) - [Λευκή βίβλος Chainlink](https://chain.link/whitepaper) -### Ασφάλεια εφαρμογών {#app-security} +### Ασφάλεια εφαρμογής {#app-security} Οι παραβιάσεις στο Ethereum γενικά εκμεταλλεύονται ευπάθειες σε μεμονωμένες εφαρμογές και όχι στο ίδιο το πρωτόκολλο. Οι χάκερ και οι προγραμματιστές εφαρμογών έχουν εγκλωβιστεί σε μια κούρσα εξοπλισμών για να αναπτύξουν νέες επιθέσεις και άμυνες. Αυτό σημαίνει ότι απαιτείται πάντα σημαντική έρευνα και ανάπτυξη για να κρατηθούν οι εφαρμογές ασφαλείς από επιθέσεις. -#### Επιπλέον πληροφορίες {#background-reading-19} +#### Απαιτούμενες γνώσεις {#background-reading-19} -- [Αναφορά Wormhole exploit](https://blog.chainalysis.com/reports/wormhole-hack-february-2022/) -- [Κατάλογος παραβιάσεων με συμβόλαιο Ethereum](https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191) -- [Ειδήσεις Rekt](https://twitter.com/RektHQ?s=20&t=3otjYQdM9Bqk8k3n1a1Adg) +- [Αναφορά εκμετάλλευσης Wormhole](https://blog.chainalysis.com/reports/wormhole-hack-february-2022/) +- [Κατάλογος μεταθανάτιων παραβιάσεων με συμβόλαιο Ethereum](https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191) +- [Ειδήσεις Rekt](https://twitter.com/RektHQ?s=20\&t=3otjYQdM9Bqk8k3n1a1Adg) #### Πρόσφατη έρευνα {#recent-research-19} - [Εφαρμογές ethresear.ch](https://ethresear.ch/c/applications/18) -### Πυλώνας τεχνολογίας {#technology-stack} +### Κατηγορία τεχνολογία {#technology-stack} Η αποκέντρωση ολόκληρου του πυλώνα τεχνολογίας του Ethereum είναι ένας σημαντικός τομέας έρευνας. Επί του παρόντος, οι dapp στο Ethereum έχουν συνήθως ορισμένα σημεία κεντρικής διαχείρισης επειδή βασίζονται σε κεντρικά εργαλεία ή υποδομή. -#### Επιπλέον πληροφορίες {#background-reading-20} +#### Απαιτούμενες γνώσεις {#background-reading-20} -- [Ethereum stack](/developers/docs/ethereum-stack/) -- [Coinbase: Εισαγωγή στο Web3 Stack](https://blog.coinbase.com/a-simple-guide-to-the-web3-stack-785240e557f0) +- [Στοίβα Ethereum](/developers/docs/ethereum-stack/) +- [Coinbase: Εισαγωγή στη στοίβα Web3](https://blog.coinbase.com/a-simple-guide-to-the-web3-stack-785240e557f0) - [Εισαγωγή στα έξυπνα συμβόλαια](/developers/docs/smart-contracts/) - [Εισαγωγή στον αποκεντρωμένο αποθηκευτικό χώρο](/developers/docs/storage/) #### Πρόσφατη έρευνα {#recent-research-20} -- [Smart contract composability](/developers/docs/smart-contracts/composability/) +- [Συνθετικότητα έξυπνου συμβολαίου](/developers/docs/smart-contracts/composability/) diff --git a/public/content/translations/el/community/support/index.md b/public/content/translations/el/community/support/index.md index 05aa82b3083..84bafec9acd 100644 --- a/public/content/translations/el/community/support/index.md +++ b/public/content/translations/el/community/support/index.md @@ -10,7 +10,7 @@ lang: el Χρειάζεστε επίσημη υποστήριξη του Ethereum; Το πρώτο πράγμα που πρέπει να γνωρίζετε είναι ότι το Ethereum είναι αποκεντρωμένο. Αυτό σημαίνει ότι κανένας κεντρικός οργανισμός, οντότητα ή άτομο δεν κατέχει το Ethereum και γι' αυτό δεν υπάρχουν επίσημα κανάλια υποστήριξης. -Η κατανόηση της αποκεντρωμένης φύσης του Ethereum είναι ζωτικής σημασίας, γιατί οποιοσδήποτε παρουσιάζεται ως επίσημη υποστήριξη για το Ethereum πιθανότατα προσπαθεί να σας εξαπατήσει! Η καλύτερη προστασία από απατεώνες είναι να εκπαιδευτείτε καλύτερα και να λάβετε σοβαρά υπόψη την ασφάλεια. +Η κατανόηση της αποκεντρωμένης φύσης του Ethereum είναι ζωτικής σημασίας, **γιατί οποιοσδήποτε παρουσιάζεται ως επίσημη υποστήριξη για το Ethereum πιθανότατα προσπαθεί να σας εξαπατήσει!** Η καλύτερη προστασία ενάντια στους κακόβουλους είναι να ενημερωθείτε σωστά και να λαμβάνετε σοβαρά υπόψη τα θέματα ασφαλείας. Ασφάλεια του Ethereum και πρόληψη κατά της απάτης @@ -91,6 +91,7 @@ lang: el - [Nethermind](https://discord.gg/YJx3pm8z5C) - [Besu](https://discord.gg/p8djYngzKN) - [Erigon](https://github.com/ledgerwatch/erigon/issues) +- [Reth](https://github.com/paradigmxyz/reth/discussions) ### Προγράμματα συναίνεσης {#consensus-clients} @@ -99,5 +100,6 @@ lang: el - [Lighthouse](https://discord.gg/cyAszAh) - [Teku](https://discord.gg/7hPv2T6) - [Lodestar](https://discord.gg/aMxzVcr) +- [Grandine](https://discord.gg/H9XCdUSyZd) Μπορείτε επίσης να [μάθετε πώς να εκτελέσετε έναν κόμβο εδώ](/developers/docs/nodes-and-clients/run-a-node/). diff --git a/public/content/translations/el/defi/index.md b/public/content/translations/el/defi/index.md index b2ce7f1af30..75e48119b05 100644 --- a/public/content/translations/el/defi/index.md +++ b/public/content/translations/el/defi/index.md @@ -354,4 +354,4 @@ H DeFi είναι ένας γενικός όρος για οικονομικά ### Κοινότητες {#communities} - [DeFi Llama διακομιστής Discord](https://discord.defillama.com/) -- [DeFi Pulse διακομιστής Discord](https://discord.gg/Gx4TCTk) +- [DeFi Pulse διακομιστής Discord](https://discord.gg/Gx4TCTk) \ No newline at end of file diff --git a/public/content/translations/el/developers/docs/intro-to-ether/index.md b/public/content/translations/el/developers/docs/intro-to-ether/index.md index 84fccf49902..faf4df458eb 100644 --- a/public/content/translations/el/developers/docs/intro-to-ether/index.md +++ b/public/content/translations/el/developers/docs/intro-to-ether/index.md @@ -26,7 +26,7 @@ lang: el Ως εκ τούτου, ακόμη και αν ένα κακόβουλο dapp υπέβαλε συνεχόμενες συναλλαγές, η συναλλαγή θα τελειώσει και θα τερματιστεί όταν καταναλωθούν τα ether, επιτρέποντας στο δίκτυο να επιστρέψει στο κανονικό. -[Συχνά](https://www.reuters.com/article/us-crypto-currencies-lending-insight-idUSKBN25M0GP#:~:text=price%20of%20ethereum) [συγχέονται](https://www.cnn.com/2021/03/14/tech/nft-art-buying/index.html#:~:text=price%20of%20ethereum) το Ethereum και το ether, όταν αυτοί που αναφέρονται στην «τιμή του Ethereum», περιγράφουν την τιμή του ether. +[Συχνά συγχέονται](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845) το Ethereum και το ether, όταν αυτοί που αναφέρονται στην «τιμή του Ethereum», περιγράφουν την τιμή του ether. ## Κρυπτόρυξη ether {#minting-ether} diff --git a/public/content/translations/el/developers/docs/networks/index.md b/public/content/translations/el/developers/docs/networks/index.md index b1c0da1138d..69718a5cca4 100644 --- a/public/content/translations/el/developers/docs/networks/index.md +++ b/public/content/translations/el/developers/docs/networks/index.md @@ -91,7 +91,7 @@ _Σημείωση: [το δοκιμαστικό δίκτυο Goerli έχει κ - [Coinbase Wallet Faucet | Goerli](https://coinbase.com/faucets/ethereum-goerli-faucet) - [Goerli faucet στο Chainstack](https://faucet.chainstack.com/goerli-faucet) -Για να εκκινήσετε έναν επικυρωτή στο δοκιμαστικό δίκτυο Goerli, χρησιμοποιήστε την [πλατφόρμα «φτηνού επικυρωτή goerli»](https://goerli.launchpad.ethstaker.cc/en/) του ethstaker. +Για να εκκινήσετε έναν επικυρωτή στο δίκτυο δοκιμών Holesky, χρησιμοποιήστε την [πλατφόρμα «φτηνού επικυρωτή Holesky»](https://holesky.launchpad.ethstaker.cc/en/) του ethstaker. ### Δίκτυα δοκιμών Layer 2 {#layer-2-testnets} diff --git a/public/content/translations/fr/web3/index.md b/public/content/translations/fr/web3/index.md index 261dc4abd6f..9fba54ea1ae 100644 --- a/public/content/translations/fr/web3/index.md +++ b/public/content/translations/fr/web3/index.md @@ -64,7 +64,7 @@ Le Web3 permet la propriété directe via les [jetons non-fongibles (NFT)](/glos
En savoir plus sur les NFT
- Plus d'infos sur les NTF + Plus d'infos sur les NFT diff --git a/public/content/translations/hi/defi/index.md b/public/content/translations/hi/defi/index.md index cc13c24250f..df075a00546 100644 --- a/public/content/translations/hi/defi/index.md +++ b/public/content/translations/hi/defi/index.md @@ -355,3 +355,7 @@ DeFi एक ओपन-सोर्स गतिविधि है। DeFi प - [DeFi Llama Discord सर्वर](https://discord.defillama.com/) - [DeFi Pulse Discord सर्वर](https://discord.gg/Gx4TCTk) + + + + \ No newline at end of file diff --git a/public/content/translations/hi/developers/docs/nodes-and-clients/archive-nodes/index.md b/public/content/translations/hi/developers/docs/nodes-and-clients/archive-nodes/index.md new file mode 100644 index 00000000000..c7cff829817 --- /dev/null +++ b/public/content/translations/hi/developers/docs/nodes-and-clients/archive-nodes/index.md @@ -0,0 +1,80 @@ +--- +title: एथेरियम आर्काइव नोड +description: आर्काइव नोड्स का अवलोकन +lang: hi +sidebarDepth: 2 +--- + +एक आर्काइव नोड एक एथेरियम क्लाइंट का एक उदाहरण है जिसे सभी ऐतिहासिक स्थितियों का आर्काइव बनाने के लिए कॉन्फ़िगर किया गया है। यह कुछ उपयोग के मामलों के लिए एक उपयोगी उपकरण है लेकिन पूर्ण नोड की तुलना में चलाना अधिक मुश्किल हो सकता है। + +## आवश्यक शर्तें {#prerequisites} + +आपको [एथेरियम नोड](/developers/docs/nodes-and-clients/) की अवधारणा, इसकी [वास्तुकला](/developers/docs/nodes-and-clients/node-architecture/), [सिंक रणनीतियों](/developers/docs/nodes-and-clients/#sync-modes), उन्हें [चलाने](/developers/docs/nodes-and-clients/run-a-node/) और [उपयोग करने](/developers/docs/apis/json-rpc/) की प्रथाओं को समझना चाहिए। + +## एक आर्काइव नोड क्या है + +एक आर्काइव नोड के महत्व को समझने के लिए, आइए "स्थिति" की अवधारणा को स्पष्ट करें। एथेरियम को _लेनदेन-आधारित स्थिति मशीन_ के रूप में संदर्भित किया जा सकता है। इसमें लेनदेन को निष्पादित करने वाले खाते और एप्लिकेशन शामिल हैं जो अपनी स्थिति बदल रहे हैं। प्रत्येक खाते और अनुबंध के बारे में जानकारी के साथ वैश्विक डेटा को स्टेट नामक एक ट्राई डेटाबेस में संग्रहित किया जाता है। इसे निष्पादन परत (EL) क्लाइंट द्वारा नियंत्रित किया जाता है और इसमें शामिल हैं: + +- खाता शेष और नॉन्सेस +- अनुबंध कोड और भंडारण +- सहमति से संबंधित डेटा, जैसे स्टेकिंग डिपॉजिट अनुबंध + +नेटवर्क के साथ बातचीत करने, नए ब्लॉकों को सत्यापित करने और उत्पादन करने के लिए, एथेरियम क्लाइंट को सबसे हाल के परिवर्तनों (श्रृंखला की नोक) और इसलिए वर्तमान स्थिति के साथ रहना होगा। एक पूर्ण नोड के रूप में कॉन्फ़िगर किया गया एक निष्पादन परत क्लाइंट नेटवर्क की नवीनतम स्थिति को सत्यापित करता है और उसका अनुसरण करता है, लेकिन केवल पिछली कुछ स्थिति को कैश करता है, उदाहरण के लिए अंतिम 128 ब्लॉकों से जुड़ी स्थिति, इसलिए यह चेन रीऑर्ग को संभाल सकता है और हाल के डेटा तक तेजी से पहुंच प्रदान कर सकता है। हाल की स्थिति वह है जो सभी क्लाइंट को आने वाले लेनदेन को सत्यापित करने और नेटवर्क का उपयोग करने की आवश्यकता है। + +आप किसी दिए गए ब्लॉक और इतिहास रीप्ले के रूप में आर्काइव पर एक क्षणिक नेटवर्क स्नैपशॉट के रूप में स्थिति की कल्पना कर सकते हैं। + +ऐतिहासिक states को सुरक्षित रूप से छंटनी की जा सकती है क्योंकि वे नेटवर्क को संचालित करने के लिए आवश्यक नहीं हैं और क्लाइंट के लिए सभी आउट-ऑफ-डेट डेटा रखना बेकार होगा। कुछ हालिया ब्लॉक (जैसे हेड से पहले 128 ब्लॉक) से पहले मौजूद स्थितियों को प्रभावी ढंग से फेंक दिया जाता है। पूर्ण नोड्स केवल ऐतिहासिक ब्लॉकचेन डेटा (ब्लॉक और लेनदेन) और कभी-कभी ऐतिहासिक स्नैपशॉट रखते हैं जिनका उपयोग वे अनुरोध पर पुरानी स्थितियों को पुनः उत्पन्न करने के लिए कर सकते हैं। वे EVM में पिछले लेनदेन को फिर से निष्पादित करके ऐसा करते हैं, जिसकी कम्प्यूटेशनल रूप से तब मांग की जा सकती है जब वांछित स्थिति निकटतम स्नैपशॉट से दूर हो। + +हालांकि, इसका मतलब यह है कि एक पूर्ण नोड पर एक ऐतिहासिक स्थिति तक पहुंचने में बहुत अधिक गणना की खपत होती है। क्लाइंट को पिछले सभी लेनदेन निष्पादित करने और उत्पत्ति से एक ऐतिहासिक स्थिति की गणना करने की आवश्यकता हो सकती है। आर्काइव नोड्स न केवल सबसे हाल की स्थितियों बल्कि प्रत्येक ब्लॉक के बाद बनाई गई प्रत्येक ऐतिहासिक स्थिति को संग्रहित करके इसे हल करते हैं। यह मूल रूप से बड़ी डिस्क स्थान की आवश्यकता के साथ एक ट्रेड-ऑफ़ करता है। + +यह ध्यान रखना महत्वपूर्ण है कि नेटवर्क सभी ऐतिहासिक डेटा को रखने और प्रदान करने के लिए आर्काइव नोड्स पर निर्भर नहीं करता है। जैसा कि ऊपर उल्लेख किया गया है, सभी ऐतिहासिक अंतरिम स्थितियों को एक पूर्ण नोड पर प्राप्त किया जा सकता है। लेन-देन किसी भी पूर्ण नोड (वर्तमान में 400G से कम) द्वारा संग्रहित किए जाते हैं और पूरे आर्काइव को बनाने के लिए फिर से चलाए जा सकते हैं। + +### उपयोग के मामले + +एथेरियम का नियमित उपयोग जैसे लेनदेन भेजना, अनुबंधों को परिनियोजित करना, सहमति की पुष्टि करना आदि के लिए ऐतिहासिक स्थितियों तक पहुंच की आवश्यकता नहीं होती है। यूज़र को नेटवर्क के साथ मानक इंटरैक्शन के लिए आर्काइव नोड की आवश्यकता नहीं होती है। + +स्थिति आर्काइव का मुख्य लाभ ऐतिहासिक स्थितियों के बारे में प्रश्नों तक त्वरित पहुंच है। उदाहरण के लिए, आर्काइव नोड तुरंत परिणाम लौटाएगा जैसे: + +- _खाता 0x1337 का... ब्लॉक 15537393 में ETH बैलेंस क्या था?_ +- _ब्लॉक 1920000 पर अनुबंध 0x में टोकन 0x का बैलेंस क्या है?_ + +जैसा कि ऊपर बताया गया है, एक पूर्ण नोड को EVM निष्पादन द्वारा इस डेटा को उत्पन्न करने की आवश्यकता होगी जो CPU का उपयोग करता है और समय लेता है। आर्काइव नोड्स उन्हें डिस्क पर एक्सेस करते हैं और तुरंत प्रतिक्रियाएं देते हैं। यह बुनियादी ढांचे के कुछ हिस्सों के लिए एक उपयोगी विशेषता है, उदाहरण के लिए: + +- ब्लॉक खोजकर्ता जैसे सेवा प्रदाता +- शोधकर्ताओं +- सुरक्षा विश्लेषक +- Dapp डेवलपर +- ऑडिटिंग और अनुपालन + +विभिन्न मुफ्त [सेवाएं](/developers/docs/nodes-and-clients/nodes-as-a-service/) हैं जो ऐतिहासिक डेटा तक पहुंच की अनुमति भी देती हैं। चूंकि एक आर्काइव नोड चलाने की अधिक मांग है, यह पहुंच ज्यादातर सीमित है और केवल सामयिक पहुंच के लिए काम करती है। यदि आपकी परियोजना को ऐतिहासिक डेटा तक निरंतर पहुंच की आवश्यकता है, तो आपको स्वयं एक चलाने पर विचार करना चाहिए। + +## कार्यान्वयन और उपयोग + +इस संदर्भ में आर्काइव नोड का अर्थ है यूज़र द्वारा निष्पादन परत क्लाइंट द्वारा प्रदान किया गया डेटा क्योंकि वे स्थिति डेटाबेस को संभालते हैं और JSON-RPC समापन बिंदु प्रदान करते हैं। कॉन्फ़िगरेशन विकल्प, सिंक्रनाइज़ेशन समय और डेटाबेस आकार क्लाइंट के अनुसार भिन्न हो सकते हैं। विवरण के लिए, कृपया अपने क्लाइंट द्वारा प्रदान किए गए प्रलेखन देखें। + +अपना स्वयं का आर्काइव नोड शुरू करने से पहले, क्लाइंट और विशेष रूप से विभिन्न [हार्डवेयर आवश्यकताओं](/developers/docs/nodes-and-clients/run-a-node/#requirements) के बीच अंतर के बारे में जानें। अधिकांश क्लाइंट इस सुविधा के लिए अनुकूलित नहीं हैं और उनके आर्काइव के लिए 12TB से अधिक स्थान की आवश्यकता होती है। इसके विपरीत, Erigon जैसे कार्यान्वयन एक ही डेटा को 3TB से कम में संग्रहित कर सकते हैं जो उन्हें आर्काइव नोड चलाने का सबसे प्रभावी तरीका बनाता है। + +## अनुशंसित अभ्यास + +[नोड चलाने के लिए सामान्य सिफारिशों](/developers/docs/nodes-and-clients/run-a-node/) के अलावा, एक आर्काइव नोड हार्डवेयर और रखरखाव पर अधिक मांग कर सकता है। Erigons की [प्रमुख विशेषताओं](https://github.com/ledgerwatch/erigon#key-features) को ध्यान में रखते हुए सबसे व्यावहारिक दृष्टिकोण [Erigon](/developers/docs/nodes-and-clients/#erigon) क्लाइंट कार्यान्वयन का उपयोग कर रहा है। + +### हार्डवेयर + +क्लाइंट के प्रलेखन में किसी दिए गए मोड के लिए हार्डवेयर आवश्यकताओं को हमेशा सत्यापित करना सुनिश्चित करें। आर्काइव नोड्स के लिए सबसे बड़ी आवश्यकता डिस्क स्थान है। क्लाइंट के आधार पर, यह 3TB से 12TB तक भिन्न होता है। यहां तक कि अगर HDD को बड़ी मात्रा में डेटा के लिए बेहतर समाधान माना जा सकता है, तो इसे सिंक करने और श्रृंखला के प्रमुख को लगातार अपडेट करने के लिए SSD ड्राइव की आवश्यकता होगी। [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) ड्राइव काफी अच्छे हैं लेकिन यह एक विश्वसनीय गुणवत्ता होनी चाहिए, कम से कम [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences)। डिस्क को डेस्कटॉप कंप्यूटर या पर्याप्त स्लॉट वाले सर्वर में फिट किया जा सकता है। ऐसे समर्पित उपकरण उच्च अपटाइम नोड चलाने के लिए आदर्श हैं। इसे लैपटॉप पर चलाना पूरी तरह से संभव है लेकिन पोर्टेबिलिटी के लिए अतिरिक्त लागत आएगी। + +सभी डेटा को एक वॉल्यूम में फिट करने की आवश्यकता है, इसलिए डिस्क को जोड़ना होगा, उदाहरण के लिए [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) या [LVM](https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/ch-lvm.html) के साथ। यह [ZFS](https://en.wikipedia.org/wiki/ZFS) का उपयोग करने पर विचार करने के लायक भी हो सकता है क्योंकि यह "कॉपी-ऑन-राइट" का सपोर्ट करता है जो सुनिश्चित करता है कि डेटा बिना किसी निम्न स्तर की त्रुटियों के डिस्क पर सही ढंग से लिखा गया है। + +अचानक डेटाबेस खराब होने को रोकने में अधिक स्थिरता और सुरक्षा के लिए, विशेष रूप से एक पेशेवर सेटअप में, [ECC मेमोरी](https://en.wikipedia.org/wiki/ECC_memory) का उपयोग करने पर विचार करें यदि आपका सिस्टम इसका समर्थन करता है। RAM का आकार आमतौर पर एक पूर्ण नोड के समान होने की सलाह दी जाती है, लेकिन अधिक RAM सिंक्रनाइज़ेशन को गति देने में मदद कर सकता है। + +प्रारंभिक सिंक के दौरान, आर्काइव मोड में क्लाइंट उत्पत्ति के बाद से प्रत्येक लेनदेन निष्पादित करेंगे। निष्पादन की गति ज्यादातर CPU द्वारा सीमित होती है, इसलिए एक तेज CPU प्रारंभिक सिंक समय में मदद कर सकता है। एक औसत उपभोक्ता कंप्यूटर पर, प्रारंभिक सिंक में एक महीने तक का समय लग सकता है। + +## अग्रिम पठन {#further-reading} + +- [एथेरियम फुल नोड बनाम आर्काइव नोड](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) - _QuickNode, सितंबर 2022_ +- [अपनी खुद की एथेरियम आर्काइव नोड का निर्माण](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) - _थॉमस जे रश, अगस्त 2021_ +- [Erigon, Erigon का RPC और TrueBlocks (स्क्रैप और API) को सेवाओं के रूप में कैसे सेट करें](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– मैग्नस हैनसन, सितंबर 2022 को अपडेट किया गया_ + +## संबंधित विषय {#related-topics} + +- [ नोड्स और क्लाइंट](/developers/docs/nodes-and-clients/) +- [नोड चलाना](/developers/docs/nodes-and-clients/run-a-node/) diff --git a/public/content/translations/hi/developers/docs/nodes-and-clients/bootnodes/index.md b/public/content/translations/hi/developers/docs/nodes-and-clients/bootnodes/index.md new file mode 100644 index 00000000000..3460cbe6aae --- /dev/null +++ b/public/content/translations/hi/developers/docs/nodes-and-clients/bootnodes/index.md @@ -0,0 +1,31 @@ +--- +title: एथेरियम बूटनोड्स का परिचय +description: बूटनोड्स को समझने के लिए आवश्यक बुनियादी जानकारी +lang: hi +--- + +जब कोई नया नोड एथेरियम नेटवर्क में शामिल होता है, तो उसे नए साथियों की खोज करने के लिए पहले से ही नेटवर्क पर मौजूद नोड्स से कनेक्ट करने की आवश्यकता होती है। एथेरियम नेटवर्क में इन प्रवेश बिंदुओं को बूटनोड्स कहा जाता है। क्लाइंट के पास आमतौर पर बूटनोड्स की एक सूची होती है जो उनमें हार्डकोड की जाती है। ये बूटनोड आमतौर पर Ethereum फाउंडेशन की डेवऑप्स टीम या क्लाइंट टीमों द्वारा स्वयं चलाए जाते हैं। ध्यान दें कि बूटनोड स्टेटिक नोड्स के समान नहीं हैं। स्टेटिक नोड्स को बार-बार बुलाया जाता है, जबकि बूटनोड्स को केवल तभी बुलाया जाता है जब कनेक्ट करने के लिए पर्याप्त सहकर्मी नहीं होते हैं और नोड को कुछ नए कनेक्शन बूटस्ट्रैप करने की आवश्यकता होती है। + +## बूटनोड से कनेक्ट करें {#connect-to-a-bootnode} + +अधिकांश क्लाइंट के पास बूटनोड्स की एक सूची होती है, लेकिन आप अपना स्वयं का बूटनोड भी चलाना चाह सकते हैं, या क्लाइंट की हार्डकोडेड सूची का हिस्सा नहीं होने वाले का उपयोग कर सकते हैं। इस मामले में, आप अपने क्लाइंट को शुरू करते समय उन्हें निर्दिष्ट कर सकते हैं, जैसा कि निम्नानुसार है (उदाहरण Geth के लिए है, कृपया अपने ग्राहक का प्रलेखन देखें): + +``` +geth --bootnodes "enode://@:" +``` + +## बूटनोड चलाएँ {#run-a-bootnode} + +बूटनोड्स पूर्ण नोड्स हैं जो NAT ([नेटवर्क एड्रेस ट्रांसलेशन](https://www.geeksforgeeks.org/network-address-translation-nat/)) के पीछे नहीं होते हैं। प्रत्येक पूर्ण नोड बूटनोड के रूप में कार्य कर सकता है जब तक कि यह सार्वजनिक रूप से उपलब्ध हो। + +जब आप एक नोड शुरू करते हैं तो उसे आपके [ईनोड](/developers/docs/networking-layer/network-addresses/#enode) को लॉग करना चाहिए, जो एक सार्वजनिक पहचानकर्ता है जिसका उपयोग अन्य आपके नोड से कनेक्ट करने के लिए कर सकते हैं। + +ईनोड आमतौर पर प्रत्येक पुनरारंभ पर पुनः उत्पन्न होता है, इसलिए अपने बूटनोड के लिए लगातार ईनोड उत्पन्न करने के तरीके पर अपने क्लाइंट के प्रलेखन को देखना सुनिश्चित करें। + +एक अच्छा बूटनोड होने के लिए, साथियों की अधिकतम संख्या बढ़ाना एक अच्छा विचार है जो इससे जुड़ सकते हैं। कई साथियों के साथ बूटनोड चलाने से बैंडविड्थ की आवश्यकता में काफी वृद्धि होगी। + +## उपलब्ध बूटनोड {#available-bootnodes} + +गो-एथेरियम के भीतर बिल्टिन बूटनोड्स की एक सूची [यहां](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23) पाई जा सकती है। इन बूटनोड्स का रखरखाव Ethereum फाउंडेशन और गो-एथेरियम टीम द्वारा किया जाता है। + +स्वयंसेवकों द्वारा बनाए गए बूटनोड्स की अन्य सूचियां उपलब्ध हैं। कृपया हमेशा कम से कम एक आधिकारिक बूटनोड शामिल करना सुनिश्चित करें, अन्यथा आप पर ग्रहण का हमला किया जा सकता है। diff --git a/public/content/translations/hi/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/hi/developers/docs/nodes-and-clients/client-diversity/index.md new file mode 100644 index 00000000000..7d9d35c6b07 --- /dev/null +++ b/public/content/translations/hi/developers/docs/nodes-and-clients/client-diversity/index.md @@ -0,0 +1,109 @@ +--- +title: ग्राहक विविधता +description: एथेरियम क्लाइंट विविधता के महत्व का एक उच्च स्तरीय स्पष्टीकरण। +lang: hi +sidebarDepth: 2 +--- + +एथेरियम नोड का व्यवहार उसके द्वारा चलाए जाने वाले क्लाइंट सॉफ़्टवेयर द्वारा नियंत्रित किया जाता है। कई उत्पादन-स्तर के एथेरियम क्लाइंट हैं, प्रत्येक को अलग-अलग टीमों द्वारा विभिन्न भाषाओं में विकसित किया और बनाए रखा गया है। क्लाइंट को एक सामान्य विनिर्देश के लिए बनाया गया है जो यह सुनिश्चित करता है कि क्लाइंट एक-दूसरे के साथ निर्बाध रूप से संवाद करें और समान कार्यक्षमता रखें और एक समान उपयोगकर्ता अनुभव प्रदान करें। हालाँकि, फिलहाल नोड्स में क्लाइंट का वितरण इतना समान नहीं है कि इस नेटवर्क सुदृढ़ीकरण को इसकी पूरी क्षमता तक महसूस किया जा सके। आदर्श रूप से, यूज़र नेटवर्क में जितना संभव हो उतना क्लाइंट विविधता लाने के लिए विभिन्न क्लाइंट में लगभग समान रूप से विभाजित होते हैं। + +## आवश्यक शर्तें {#prerequisites} + +यदि आप पहले से ही नहीं समझते हैं कि नोड्स और क्लाइंट क्या हैं, तो [नोड्स और क्लाइंट](/developers/docs/nodes-and-clients/) देखें। [निष्पादन](/glossary/#execution-layer) और [आम सहमति](/glossary/#consensus-layer) परतों को शब्दावली में परिभाषित किया गया है। + +## एक से अधिक क्लाइंट क्यों हैं? {#why-multiple-clients} + +कई, स्वतंत्र रूप से विकसित और बनाए रखे गए क्लाइंट मौजूद हैं क्योंकि क्लाइंट की विविधता नेटवर्क को हमलों और बग के लिए अधिक लचीला बनाती है। एक से अधिक क्लाइंट होना एथेरियम की अद्वितीय ताकत है - अन्य ब्लॉकचेन एकल क्लाइंट की अचूकता पर भरोसा करते हैं। हालांकि, केवल कई क्लाइंट उपलब्ध होना पर्याप्त नहीं है, उन्हें समुदाय द्वारा अपनाया जाना चाहिए और कुल सक्रिय नोड्स अपेक्षाकृत समान रूप से वितरित किए जाने चाहिए। + +## क्लाइंट विविधता क्यों महत्वपूर्ण है? {#client-diversity-importance} + +स्वतंत्र रूप से विकसित और अनुरक्षित कई क्लाइंट का होना विकेन्द्रीकृत नेटवर्क के स्वास्थ्य के लिए महत्वपूर्ण है। आइए कारणों का पता लगाएं। + +### बग्स {#bugs} + +एक व्यक्तिगत क्लाइंट में एक बग, एथेरियम नोड्स की कमी का प्रतिनिधित्व करते समय नेटवर्क के लिए जोखिम से कम होता है। कई क्लाइंट में नोड्स के लगभग समान वितरण के कारण, अधिकांश क्लाइंट के साझा मुद्दे से पीड़ित होने की संभावना कम होती है, और परिणामस्वरूप, नेटवर्क अधिक मजबूत होता है। + +### हमलों के लिए लचीलापन {#resilience} + +क्लाइंट विविधता भी हमलों के लिए लचीलापन प्रदान करती है। उदाहरण के लिए, एक हमला जो किसी [विशेष क्लाइंट](https://twitter.com/vdWijden/status/1437712249926393858) को श्रृंखला की किसी विशेष शाखा पर धोखा देता है, के सफल होने की संभावना नहीं होती क्योंकि अन्य क्लाइंट का उसी तरह से शोषण होने की संभावना नहीं होती और कैनोनिकल श्रृंखला अदूषित रहती है। कम क्लाइंट विविधता प्रमुख क्लाइंट पर हैक से जुड़े जोखिम को बढ़ाती है। क्लाइंट विविधता पहले से ही नेटवर्क पर दुर्भावनापूर्ण हमलों के खिलाफ एक महत्वपूर्ण बचाव साबित हुई है, उदाहरण के लिए 2016 में शंघाई सेवा अस्वीकार हमला संभव था क्योंकि हमलावर प्रमुख क्लाइंट (Geth) को धोखा देकर प्रति ब्लॉक हजारों बार धीमी डिस्क i/o ऑपरेशन निष्पादित कर सकते थे। क्योंकि वैकल्पिक क्लाइंट भी ऑनलाइन थे जो कमजोरी को साझा नहीं करते थे, एथेरियम हमले का विरोध करने में सक्षम था और Geth में कमजोरी तय होने के दौरान संचालन जारी रखता था। + +### हिस्सेदारी का सबूत की अन्तिम स्थिति {#finality} + +33% से अधिक एथेरियम नोड्स के साथ सहमति क्लाइंट में एक बग सर्वसम्मति परत को अंतिम रूप देने से रोक सकता है, जिसका अर्थ है कि यूज़र भरोसा नहीं कर सकते हैं कि लेनदेन को किसी बिंदु पर वापस किया या बदला नहीं जाएगा। यह एथेरियम, विशेष रूप से DeFi के शीर्ष पर निर्मित कई ऐप्स के लिए बहुत समस्याग्रस्त होगा। + + इससे भी बदतर, दो-तिहाई बहुमत वाले क्लाइंट में एक महत्वपूर्ण बग श्रृंखला को गलत तरीके से विभाजित करने और अंतिम रूप देने का कारण बन सकता है, जिससे सत्यापनकर्ताओं का एक बड़ा सेट एक अमान्य श्रृंखला पर फंस सकता है। यदि वे सही श्रृंखला में फिर से शामिल होना चाहते हैं, तो इन सत्यापनकर्ताओं को स्लैशिंग या धीमी और महंगी स्वैच्छिक निकासी और पुनर्सक्रियन का सामना करना पड़ता है। दो-तिहाई बहुमत के साथ दोषी नोड्स की संख्या के साथ एक स्लैशिंग स्केल का परिमाण अधिकतम (32 ETH) घटा दिया गया। + +हालांकि ये असंभावित परिदृश्य हैं, एथेरियम इको-सिस्टम सक्रिय नोड्स में क्लाइंट के वितरण को समान करके जोखिम को कम कर सकता है। आदर्श रूप से, कोई भी कंसेंसस क्लाइंट कभी भी कुल नोड्स के 33% हिस्से तक नहीं पहुंच पाएगा। + +### साझा की गई जिम्मेदारी {#responsibility} + +बहुसंख्यक क्लाइंट होने की मानवीय लागत भी है। यह एक छोटी विकास टीम पर अतिरिक्त तनाव और जिम्मेदारी डालता है। क्लाइंट विविधता जितनी कम होगी, बहुसंख्यक क्लाइंट को बनाए रखने वाले डेवलपर के लिए जिम्मेदारी का बोझ उतना ही अधिक होगा। इस जिम्मेदारी को कई टीमों में फैलाना एथेरियम के नोड्स के नेटवर्क और इसके लोगों के नेटवर्क दोनों के स्वास्थ्य के लिए अच्छा है। + +## वर्तमान क्लाइंट विविधता {#current-client-diversity} + +![क्लाइंट विविधता दिखाने वाला पाइ चार्ट](./client-diversity.png) _रेखाचित्र डेटा [ethernodes.org](https://ethernodes.org) और [clientdiversity.org](https://clientdiversity.org/) से_ + +ऊपर दिए गए दो पाई चार्ट निष्पादन और सर्वसम्मति परतों (जनवरी 2022 में लेखन के समय) के लिए वर्तमान क्लाइंट विविधता के स्नैपशॉट दिखाते हैं। निष्पादन परत में [Geth](https://geth.ethereum.org/), का अत्यधिक प्रभुत्व है, जिसमें [खुला एथेरियम](https://openethereum.github.io/) एक दूर दूसरा, [Erigon](https://github.com/ledgerwatch/erigon) तीसरा और [Nethermind](https://nethermind.io/) चौथा है, अन्य ग्राहकों में नेटवर्क का 1% से कम शामिल है। सहमति परत पर सबसे अधिक इस्तेमाल किया जाने वाला क्लाइंट - [प्रिज़्म](https://prysmaticlabs.com/#projects)- Geth जितना प्रमुख नहीं है, लेकिन फिर भी नेटवर्क के 60% से अधिक का प्रतिनिधित्व करता है। [लाइटहाउस](https://lighthouse.sigmaprime.io/)और [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) क्रमशः ~ 20% और ~ 14% बनाते हैं, और अन्य क्लाइंट का उपयोग शायद ही कभी किया जाता है। + +निष्पादन परत डेटा 23 जनवरी 2022 को [Ethernodes](https://ethernodes.org) से प्राप्त किया गया था। सहमति क्लाइंट के लिए डेटा [माइकल स्प्राउल](https://github.com/sigp/blockprint) से प्राप्त किया गया था। सहमति ग्राहक डेटा प्राप्त करना अधिक कठिन है क्योंकि सहमति परत क्लाइंट के पास हमेशा स्पष्ट निशान नहीं होते हैं जिनका उपयोग उन्हें पहचानने के लिए किया जा सकता है। डेटा एक वर्गीकरण एल्गोरिथम का उपयोग करके उत्पन्न किया गया था जो कभी-कभी कुछ अल्पसंख्यक क्लाइंट को भ्रमित करता है (अधिक विवरण के लिए [यहां](https://twitter.com/sproulM_/status/1440512518242197516) देखें)। उपरोक्त रेखाचित्र में, इन अस्पष्ट वर्गीकरणों को या तो/या लेबल (जैसे Nimbus/Teku) के साथ व्यवहार किया जाता है। फिर भी, यह स्पष्ट है कि अधिकांश नेटवर्क प्रिज़्म चला रहे हैं। डेटा ब्लॉक के एक निश्चित सेट पर एक स्नैपशॉट है (इस मामले में 2164916 के 2048001 स्लॉट में बीकन ब्लॉक) और प्रिज़्म का प्रभुत्व कभी-कभी अधिक, 68% से अधिक रहा है। केवल स्नैपशॉट होने के बावजूद, रेखाचित्र में मान क्लाइंट विविधता की वर्तमान स्थिति का एक अच्छा सामान्य ज्ञान प्रदान करते हैं। + +सहमति परत के लिए अद्यतित क्लाइंट विविधता डेटा अब [clientdiversity.org](https://clientdiversity.org/) पर उपलब्ध है। + +## निष्पादन परत {#execution-layer} + +अब तक, क्लाइंट विविधता के आसपास की बातचीत मुख्य रूप से सहमति परत पर केंद्रित है। हालांकि, निष्पादन क्लाइंट [Geth](https://geth.ethereum.org) वर्तमान में सभी नोड्स का लगभग 85% है। यह प्रतिशत सहमति क्लाइंट के समान कारणों से समस्याग्रस्त है। उदाहरण के लिए, Geth में एक बग लेनदेन से निपटने या निष्पादन पेलोड के निर्माण को प्रभावित करता है, जिससे सहमति ग्राहक समस्याग्रस्त या बग किए गए लेनदेन को अंतिम रूप दे सकते हैं। इसलिए, एथेरियम निष्पादन ग्राहक के अधिक समान वितरण के साथ स्वस्थ होगा, आदर्श रूप से कोई भी क्लाइंट नेटवर्क के 33% से अधिक का प्रतिनिधित्व नहीं करता है। + +## अल्पसंख्यक क्लाइंट का उपयोग करें {#use-minority-client} + +क्लाइंट विविधता को संबोधित करने के लिए अल्पसंख्यक क्लाइंट को चुनने के लिए व्यक्तिगत उपयोगकर्ताओं से अधिक की आवश्यकता होती है - इसके लिए क्लाइंट को स्विच करने के लिए माईनिंग/सत्यापनकर्ता पूल और प्रमुख dapps और एक्सचेंजों जैसे संस्थानों की आवश्यकता होती है। हालांकि, सभी यूज़र वर्तमान असंतुलन को दूर करने और सभी उपलब्ध एथेरियम सॉफ़्टवेयर के उपयोग को सामान्य बनाने में अपनी भूमिका निभा सकते हैं। मर्ज के बाद, सभी नोड ऑपरेटरों को एक एक्‍जीक्यूशन क्लाइंट और एक कंसेंसस क्लाइंट रन करने की आवश्यकता होगी। नीचे सुझाए गए क्लाइंट के संयोजन चुनने से क्लाइंट विविधता बढ़ाने में मदद मिलेगी। + +### निष्पादन ग्राहक {#execution-clients} + +[बेसु](https://www.hyperledger.org/use/besu) + +[नेदरमाइंड](https://downloads.nethermind.io/) + +[एरिगोन](https://github.com/ledgerwatch/erigon) + +[गो-एथेरियम](https://geth.ethereum.org/) + +### सहमति ग्राहक {#consensus-clients} + +[निम्बस](https://nimbus.team/) + +[लाइटहाउस](https://github.com/sigp/lighthouse) + +[टेकु](https://consensys.net/knowledge-base/ethereum-2/teku/) + +[लोडस्टार](https://github.com/ChainSafe/lodestar) + +[प्रिज़्म](https://docs.prylabs.network/docs/getting-started) + +तकनीकी यूज़र अल्पसंख्यक क्लाइंट के लिए अधिक ट्यूटोरियल और प्रलेखन लिखकर और अपने नोड-ऑपरेटिंग साथियों को प्रमुख क्लाइंट से दूर माइग्रेट करने के लिए प्रोत्साहित करके इस प्रक्रिया को तेज करने में मदद कर सकते हैं। अल्पसंख्यक सहमति क्लाइंट पर स्विच करने के लिए गाइड [clientdiversity.org](https://clientdiversity.org/) पर उपलब्ध हैं। + +## क्लाइंट विविधता डैशबोर्ड {#client-diversity-dashboards} + +कई डैशबोर्ड निष्पादन और सहमति परत के लिए वास्तविक समय क्लाइंट विविधता आँकड़े देते हैं। + +**सहमति परत:** + +- [Rated.network](https://www.rated.network/) +- [clientdiversity.org](https://clientdiversity.org/) **निष्पादन परत:** + +- [supermajority.info](https://supermajority.info//) +- [Ethernodes](https://ethernodes.org/) + +## अग्रिम पठन {#further-reading} + +- [एथेरियम की सहमति परत पर क्लाइंट विविधता](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) +- [एथेरियम मर्ज: बहुमत वाले क्लाइंट को अपने जोखिम पर चलाएं!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _डंकराड फिएस्ट, 24 मार्च 2022_ +- [क्लाइंट विविधता का महत्व](https://our.status.im/the-importance-of-client-diversity/) +- [एथेरियम नोड सेवाओं की सूची](https://ethereumnodes.com/) +- [क्लाइंट विविधता समस्या के पांच क्यों](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08) +- [एथेरियम विविधता और इसका समाधान कैसे करें (YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU) +- [clientdiversity.org](https://clientdiversity.org/) + +## संबंधित विषय {#related-topics} + +- [एक एथेरियम नोड चलाएँ](/run-a-node/) +- [नोड्स और क्लाइंट](/developers/docs/nodes-and-clients/) diff --git a/public/content/translations/hi/developers/docs/nodes-and-clients/index.md b/public/content/translations/hi/developers/docs/nodes-and-clients/index.md new file mode 100644 index 00000000000..c4799dba16e --- /dev/null +++ b/public/content/translations/hi/developers/docs/nodes-and-clients/index.md @@ -0,0 +1,315 @@ +--- +title: नोड्स और क्लाइंट +description: एथेरियम नोड्स और क्लाइंट सॉफ़्टवेयर का अवलोकन, साथ ही नोड कैसे सेट करें और आपको यह क्यों करना चाहिए। +lang: hi +sidebarDepth: 2 +--- + +एथेरियम कंप्यूटर का एक वितरित नेटवर्क है (जिसे नोड्स के रूप में जाना जाता है) जो सॉफ़्टवेयर चला रहा है जो ब्लॉक और लेनदेन संबंधी डेटा को सत्यापित कर सकता है। सॉफ़्टवेयर को एथेरियम नोड में बदलने के लिए आपके कंप्यूटर पर चलाया जाना चाहिए। नोड बनाने के लिए आवश्यक सॉफ़्टवेयर के दो अलग-अलग टुकड़े ('क्लाइंट' के रूप में जाना जाता है) होते हैं। + +## आवश्यक शर्तें {#prerequisites} + +आपको पीयर-टू-पीयर नेटवर्क की अवधारणा और [मूल EVM](/developers/docs/evm/) गहराई से गोता लगाने और एथेरियम क्लाइंट का अपना उदाहरण चलाने से पहले समझना चाहिए। हमारे [एथेरियम का परिचय](/developers/docs/intro-to-ethereum/) पर एक नज़र डालें। + +अगर आप नोड्स के विषय में नए हैं, तो हम अनुशंसा करते हैं कि पहले हमारे यूज़र के अनुकूल परिचय देखें [एथेरियम नोड चलाना](/run-a-node)। + +## नोड्स और क्लाइंट क्या हैं? {#what-are-nodes-and-clients} + +एक "नोड" एथेरियम क्लाइंट सॉफ़्टवेयर का कोई उदाहरण है जो अन्य कंप्यूटरों से जुड़ा होता है जो एथेरियम सॉफ़्टवेयर भी चलाते हैं, एक नेटवर्क बनाते हैं। एक क्लाइंट एथेरियम का एक कार्यान्वयन है जो प्रोटोकॉल नियमों के खिलाफ डेटा की पुष्टि करता है और नेटवर्क को सुरक्षित रखता है। एक नोड को दो क्लाइंट चलाने होते हैं: एक सर्वसम्मति क्लाइंट और एक निष्पादन क्लाइंट। + +- निष्पादन क्लाइंट (जिसे निष्पादन इंजन, EL क्लाइंट या पूर्व में Eth1 क्लाइंट के रूप में भी जाना जाता है) नेटवर्क में प्रसारित नए लेनदेन को सुनता है, उन्हें EVM में निष्पादित करता है और एथेरियम संबंधी सभी मौजूदा डेटा की नई स्थिति और डेटाबेस रखता है। +- सहमति क्लाइंट (जिसे बीकन नोड, CL क्लाइंट या पूर्व में Eth2 क्लाइंट के रूप में भी जाना जाता है) हिस्सेदारी का सबूत कंसेंसस एल्गोरिथम को लागू करता है, जो नेटवर्क को एक्‍जीक्यूशन क्लाइंट से मान्य डेटा के आधार पर समझौता प्राप्त करने में सक्षम बनाता है। सॉफ़्टवेयर का एक तीसरा हिस्सा भी है, जिसे 'सत्यापनकर्ता' के रूप में जाना जाता है जिसे आम सहमति क्लाइंट में जोड़ा जा सकता है, जिससे नोड नेटवर्क को सुरक्षित करने में भाग ले सकता है। + +ये क्लाइंट एथेरियम सीरीज़ के प्रमुख पर नज़र रखने के लिए एक साथ काम करते हैं और यूज़र को एथेरियम नेटवर्क के साथ बातचीत करने की अनुमति देते हैं। एक साथ काम करने वाले सॉफ़्टवेयर के कई हिस्सों के साथ मॉड्यूलर डिज़ाइन को सभी [जटिलताओं का समाधान](https://vitalik.eth.limo/general/2022/02/28/complexity.html) कहा जाता है। इस दृष्टिकोण ने [मर्ज](/roadmap/merge) को निर्बाध रूप से निष्पादित करना आसान बना दिया, क्लाइंट सॉफ़्टवेयर को बनाए रखने और विकसित करने में आसान बनाता है और व्यक्तिगत ग्राहकों के पुनः उपयोग को सक्षम बनाता है, उदाहरण के लिए, [लेयर 2 पारिस्थितिकी तंत्र](/layer-2/)। + +![युग्मित निष्पादन और आम सहमति वाले क्लाइंट](./eth1eth2client.png) युग्मित निष्पादन और सर्वसम्मति वाले क्लाइंट का आसान बनाया गया आरेख। + +### ग्राहक विविधता {#client-diversity} + +दोनों [निष्पादन क्लाइंट](/developers/docs/nodes-and-clients/#execution-clients) और [सहमति क्लाइंट](/developers/docs/nodes-and-clients/#consensus-clients) विभिन्न टीमों द्वारा विकसित की गई विभिन्न प्रोग्रामिंग भाषाओं में मौजूद हैं। + +एकाधिक क्लाइंट कार्यान्वयन सिंगल कोडबेस पर अपनी निर्भरता को कम करके नेटवर्क को मजबूत बना सकते हैं। आदर्श लक्ष्य किसी भी क्लाइंट को नेटवर्क पर हावी किए बिना विविधता प्राप्त करना है, जिससे विफलता के संभावित एकल बिंदु को समाप्त किया जा सके। भाषाओं की विविधता एक व्यापक डेवलपर समुदाय को भी आमंत्रित करती है और उन्हें अपनी पसंदीदा भाषा में इंटीग्रेशन तय करने की अनुमति देती है। + +[क्लाइंट विविधता](/developers/docs/nodes-and-clients/client-diversity/) के बारे में अधिक जानें। + +इन कार्यान्वयनों में क्या समानता है, वे सभी एक ही विनिर्देश का पालन करते हैं। विनिर्देश तय करते हैं कि एथेरियम नेटवर्क और ब्लॉकचेन कैसे कार्य करता है। प्रत्येक तकनीकी विवरण को परिभाषित किया गया है और विनिर्देशों को इस प्रकार पाया जा सकता है: + +- मूल रूप से, [एथेरियम येलो पेपर](https://ethereum.github.io/yellowpaper/paper.pdf) +- [निष्पादन संबंधी विनिर्देश](https://github.com/ethereum/execution-specs/) +- [सहमति संबंधी विनिर्देश](https://github.com/ethereum/consensus-specs) +- विभिन्न [नेटवर्क उन्नयन](/history/) में लागू किए गए [EIP](https://eips.ethereum.org/) + +### नेटवर्क में ट्रैकिंग नोड्स {#network-overview} + +एकाधिक ट्रैकर्स एथेरियम नेटवर्क में नोड्स का रियल टाइम ओवरव्यू प्रदान करते हैं। ध्यान दें कि विकेंद्रीकृत नेटवर्क की प्रकृति के कारण, ये क्रॉलर केवल नेटवर्क का एक सीमित दृश्य प्रदान कर सकते हैं और विभिन्न परिणामों की रिपोर्ट कर सकते हैं। + +- Etherscan द्वारा [नोड्स का नक्शा](https://etherscan.io/nodetracker) +- Bitfly द्वारा [Ethernodes](https://ethernodes.org/) +- Chainsafe द्वारा [Nodewatch](https://www.nodewatch.io/), क्रॉलिंग सर्वसम्मति नोड्स +- MigaLabs द्वारा [Monitoreth](https://monitoreth.io/), - एक वितरित नेटवर्क मॉनिटरिंग टूल + +## नोड प्रकार {#node-types} + +अगर आप [अपना नोड चलाना चाहते](/developers/docs/nodes-and-clients/run-a-node/) हैं, तो आपको यह समझना चाहिए कि विभिन्न प्रकार के नोड हैं जो डेटा का अलग-अलग उपभोग करते हैं। वास्तव में, क्लाइंट तीन अलग-अलग प्रकार के नोड्स चला सकते हैं: लाइट, पूर्ण और आर्काइव। विभिन्न सिंक रणनीतियों के विकल्प भी हैं जो तेजी से सिंक्रनाइज़ेशन समय को सक्षम करते हैं। सिंक्रनाइज़ेशन से मतलब है कि यह एथेरियम की स्थिति पर हाल ही में अपडेट की गई जानकारी कितनी जल्दी प्राप्त कर सकता है। + +### फ़ुल नोड {#full-node} + +फ़ुल नोड्स ब्लॉकचेन का ब्लॉक-बाय-ब्लॉक सत्यापन करते हैं, जिसमें प्रत्येक ब्लॉक के लिए ब्लॉक बॉडी और स्टेट डेटा को डाउनलोड और सत्यापित करना शामिल है। फ़ुल नोड के विभिन्न वर्ग हैं - कुछ उत्पत्ति ब्लॉक से शुरू होते हैं और ब्लॉकचेन के पूरे इतिहास में हर एक ब्लॉक को सत्यापित करते हैं। अन्य लोग अपना सत्यापन हाल के ब्लॉक पर शुरू करते हैं जिसे वे वैध मानते हैं (उदाहरण के लिए Geth का 'स्नैप सिंक')। भले ही सत्यापन कहीं से भी शुरू हो, फ़ुल नोड्स केवल अपेक्षाकृत हाल के डेटा (आमतौर पर सबसे हाल के 128 ब्लॉक) की एक स्थानीय प्रतिलिपि रखते हैं, जिससे डिस्क स्थान को बचाने के लिए पुराने डेटा को हटाया जा सकता है। जरूरत पड़ने पर पुराने डेटा को पुनः उत्पन्न किया जा सकता है। + +- पूर्ण ब्लॉकचेन डेटा संग्रहीत करता है (हालांकि यह समय-समय पर छंटनी की जाती है, इसलिए एक फ़ुल नोड सभी स्टेट डेटा को उत्पत्ति में वापस संग्रहीत नहीं करता है) +- ब्लॉक सत्यापन में भाग लेता है, सभी ब्लॉकों और स्टेट की पुष्टि करता है। +- सभी स्टेट को या तो स्थानीय भंडारण से पुनर्प्राप्त किया जा सकता है या एक फ़ुल नोड द्वारा 'स्नैपशॉट' से पुनः उत्पन्न किया जा सकता है। +- नेटवर्क की सेवा करता है और अनुरोध पर डेटा प्रदान करता है। + +### आर्काइव नोड {#archive-node} + +आर्काइव नोड्स पूर्ण नोड्स हैं जो उत्पत्ति से प्रत्येक ब्लॉक को सत्यापित करते हैं और कभी भी डाउनलोड किए गए किसी भी डेटा को नहीं हटाते हैं। + +- फ़ुल नोड में रखी गई हर चीज को संग्रहीत करता है और ऐतिहासिक स्टेट का एक संग्रह बनाता है। अगर आप ब्लॉक #4,000,000 पर खाता शेष राशि की तरह कुछ क्वेरी करना चाहते हैं, या ट्रेसिंग का उपयोग करके माईनिंग किए बिना बस और मज़बूती से अपने खुद के लेनदेन सेट का परीक्षण करना चाहते हैं, तो इसकी ज़रूरत हो सकती है। +- यह डेटा टेराबाइट्स की इकाइयों को दिखाता है, जो औसत उपयोगकर्ताओं के लिए संग्रह नोड्स को कम आकर्षक बनाता है लेकिन ब्लॉक खोजकर्ताओं, वॉलेट विक्रेताओं और चेन एनालिटिक्स जैसी सेवाओं के लिए आसान हो सकता है। + +संग्रह के अलावा किसी भी मोड में क्लाइंट को सिंक करने से ब्लॉकचेन डेटा की छंटनी होगी। इसका मतलब है, सभी ऐतिहासिक स्टेट्स का कोई संग्रह नहीं है, लेकिन फ़ुल नोड मांग पर उन्हें बनाने में सक्षम है। + +[आर्काइव नोड्स](/developers/docs/nodes-and-clients/archive-nodes) के बारे में अधिक जानें। + +### लाइट नोड {#light-node} + +प्रत्येक ब्लॉक को डाउनलोड करने के बजाय, लाइट नोड्स केवल ब्लॉक हेडर डाउनलोड करते हैं। इन शीर्षलेखों में ब्लॉकों की सामग्री के बारे में सारांश के तौर पर जानकारी होती है। लाइट नोड की आवश्यकता वाली किसी भी अन्य जानकारी को एक फ़ुल नोड से अनुरोध किया जाता है। लाइट नोड तब स्वतंत्र रूप से ब्लॉक हेडर में स्टेट रूट्स के हिसाब से प्राप्त डेटा को सत्यापित कर सकता है। लाइट नोड्स यूज़र को पूर्ण नोड्स चलाने के लिए आवश्यक शक्तिशाली हार्डवेयर या उच्च बैंडविड्थ के बिना एथेरियम नेटवर्क में भाग लेने में सक्षम बनाते हैं। आखिरकार, मोबाइल फ़ोन या एम्बेडेड डिवाइस पर लाइट नोड्स चल सकते हैं। लाइट नोड्स आम सहमति में भाग नहीं लेते हैं (यानी वे खनिक/सत्यापनकर्ता नहीं हो सकते हैं), लेकिन वे एथेरियम ब्लॉकचेन को फ़ुल नोड के समान कार्यक्षमता और सुरक्षा गारंटी के साथ एक्सेस कर सकते हैं। + +लाइट क्लाइंट एथेरियम के लिए सक्रिय विकास का एक क्षेत्र हैं और हम जल्द ही सर्वसम्मति परत और निष्पादन परत के लिए नए लाइट क्लाइंट को देखने की उम्मीद करते हैं। [गपशप नेटवर्क](https://www.ethportal.net/) पर लाइट क्लाइंट डेटा प्रदान करने के संभावित तरीके भी हैं। यह फायदेमंद है, क्योंकि गपशप नेटवर्क अनुरोधों की सेवा के लिए पूर्ण नोड्स की आवश्यकता के बिना लाइट नोड्स के नेटवर्क का सपोर्ट कर सकता है। + +एथेरियम अभी तक लाइट नोड्स की एक बड़ी आबादी का सपोर्ट नहीं करता है, लेकिन लाइट नोड सपोर्ट एक ऐसा क्षेत्र है जो निकट भविष्य में तेजी से विकसित होने की उम्मीद है। विशेष रूप से, [Nimbus](https://nimbus.team/), [Helios](https://github.com/a16z/helios), और [LodeStar](https://lodestar.chainsafe.io/) जैसे क्लाइंट वर्तमान में लाइट नोड्स पर बहुत अधिक केंद्रित हैं। + +## मुझे एथेरियम नोड क्यों चलाना चाहिए? {#why-should-i-run-an-ethereum-node} + +नोड चलाने से आप नेटवर्क को अधिक मजबूत और विकेंद्रीकृत रखते हुए एथेरियम को सपोर्ट करते हुए सीधे, भरोसेमंद और निजी तौर पर एथेरियम का उपयोग कर सकते हैं। + +### आपके लिए लाभ {#benefits-to-you} + +अपना खुद का नोड चलाना आपको निजी, आत्मनिर्भर और भरोसेमंद तरीके से एथेरियम का उपयोग करने में सक्षम बनाता है। आपको नेटवर्क पर भरोसा करने की आवश्यकता नहीं है, क्योंकि आप अपने क्लाइंट के साथ डेटा को खुद सत्यापित कर सकते हैं। "भरोसा न करें, सत्यापित करें" एक लोकप्रिय ब्लॉकचेन मंत्र है। + +- आपका नोड सभी लेनदेन और ब्लॉकों को सर्वसम्मति वाले नियमों के हिसाब से खुद सत्यापित करता है। इसका मतलब है कि आपको नेटवर्क में किसी अन्य नोड्स पर भरोसा करने या उन पर पूरी तरह भरोसा करने की आवश्यकता नहीं है। +- आप अपने खुद के नोड के साथ एथेरियम वॉलेट का उपयोग कर सकते हैं। आप dapps का अधिक सुरक्षित और निजी रूप से उपयोग कर सकते हैं, क्योंकि आपको अपने पते और शेष राशि को बिचौलियों को लीक नहीं करना पड़ेगा। सभी चीज़ों की अपने ग्राहकों के साथ जाँच की जा सकती है। [MetaMask](https://metamask.io), [Frame](https://frame.sh/), और [कई अन्य वॉलेट](/wallets/find-wallet/) RPC-आयात की पेशकश करते हैं, जिससे वे आपके नोड का उपयोग कर सकते हैं। +- आप अन्य सेवाओं को चला सकते हैं और स्वयं-होस्ट कर सकते हैं जो एथेरियम के डेटा पर निर्भर करती हैं। उदाहरण के लिए, यह एक बीकन चेन सत्यापनकर्ता, लेयर 2, इन्फ़्रास्ट्रक्चर, ब्लॉक खोजकर्ता, पेमेंट प्रोसेसर आदि जैसे सॉफ़्टवेयर हो सकते हैं। +- आप अपना खुद का कस्टम [RPC समापन बिंदु](/developers/docs/apis/json-rpc/) दे सकते हैं। आप इन समापन बिंदुओं को सार्वजनिक रूप से समुदाय को बड़े केंद्रीकृत प्रदाताओं से बचने में मदद करने के लिए भी पेश कर सकते हैं। +- आप **इंटर-प्रोसेस कम्युनिकेशंस (IPC)** का उपयोग करके अपने नोड से कनेक्ट कर सकते हैं या अपने प्रोग्राम को प्लगइन के रूप में लोड करने के लिए नोड को फिर से लिख सकते हैं। यह कम विलंबता प्रदान करता है, जो बहुत मदद करता है, उदाहरण के लिए web3 पुस्तकालयों का उपयोग करके बहुत सारे डेटा को प्रोसेस करते समय या जब आपको अपने लेनदेन को जितनी जल्दी हो सके बदलने की आवश्यकता होती है (यानी फ़्रंटरनिंग)। +- आप नेटवर्क को सुरक्षित करने और पुरस्कार हासिल करने के लिए ETH को सीधे स्टेक कर सकते हैं। शुरू करने के लिए [सोलो स्टेकिंग](/staking/solo/) देखें। + +![आप अपने एप्लिकेशन और नोड्स के माध्यम से एथेरियम तक कैसे पहुंचते हैं](./nodes.png) + +### नेटवर्क के लाभ {#network-benefits} + +एथेरियम के स्वास्थ्य, सुरक्षा और परिचालन लचीलापन के लिए नोड्स का एक विविध सेट महत्वपूर्ण है। + +- फ़ुल नोड्स सहमति नियमों को लागू करते हैं, ताकि उन्हें उन ब्लॉकों को स्वीकार करने में धोखा न दिया जा सके जो उनका पालन नहीं करते। यह नेटवर्क में अतिरिक्त सुरक्षा प्रदान करता है, क्योंकि अगर सभी नोड्स लाइट नोड थे, जो पूर्ण सत्यापन नहीं करते हैं, तो सत्यापनकर्ता नेटवर्क पर हमला कर सकते हैं। +- एक हमले के मामले में जो [हिस्सेदारी के सबूत](/developers/docs/consensus-mechanisms/pos/#what-is-pos) के क्रिप्टो-आर्थिक बचाव पर काबू पाता है, ईमानदार सीरीज़ का पालन करने के लिए चुनने वाले फ़ुल नोड्स द्वारा एक सामाजिक सुधार किया जा सकता है। +- नेटवर्क में अधिक नोड्स के परिणामस्वरूप एक अधिक विविध और मजबूत नेटवर्क होता है, जो विकेंद्रीकरण का अंतिम लक्ष्य है, जो सेंसरशिप-प्रतिरोधी और विश्वसनीय सिस्टम को सक्षम बनाता है। +- फ़ुल नोड्स लाइट क्लाइंट के लिए ब्लॉकचेन डेटा तक पहुंच प्रदान करते हैं जो इस पर निर्भर करते हैं। लाइट नोड्स पूरे ब्लॉकचेन को स्टोर नहीं करते हैं, इसके बजाय वे [ब्लॉक हेडर में स्टेट रूट्स](/developers/docs/blocks/#block-anatomy) के माध्यम से डेटा सत्यापित करते हैं। अगर उन्हें इसकी आवश्यकता हो, तो वे पूर्ण नोड्स से अधिक जानकारी का अनुरोध कर सकते हैं। + +अगर आप एक पूर्ण नोड चलाते हैं, तो पूरे एथेरियम नेटवर्क को इससे लाभ होता है, भले ही आप एक सत्यापनकर्ता न चलाएं। + +## अपना खुद का नोड चला रहा है {#running-your-own-node} + +अपना खुद का एथेरियम क्लाइंट चलाने के इच्छुक हैं? + +शुरुआत के अनुकूल परिचय के लिए, अधिक जानने के लिए हमारे [रन ए नोड](/run-a-node) पेज पर जाएं। + +अगर आप एक तकनीकी यूज़र के रूप में अधिक हैं, तो [अपने स्वयं के नोड को स्पिन करने](/developers/docs/nodes-and-clients/run-a-node/) के तरीके के बारे में अधिक विवरण और विकल्पों को देखें। + +## वैकल्पिक {#alternatives} + +अपना खुद का नोड सेट करने से आपका समय और संसाधन खर्च हो सकते हैं, लेकिन आपको हमेशा अपना खुद का उदाहरण चलाने की आवश्यकता नहीं होती। इस मामले में, आप किसी तीसरे पक्ष के API प्रदाता का उपयोग कर सकते हैं। इन सेवाओं का उपयोग करने के अवलोकन के लिए, [सेवा के रूप में नोड्स](/developers/docs/nodes-and-clients/nodes-as-a-service/) देखें। + +अगर कोई आपके समुदाय में सार्वजनिक API के साथ एथेरियम नोड चलाता है, तो आप कस्टम RPC के माध्यम से अपने वॉलेट को सामुदायिक नोड पर इंगित कर सकते हैं और कुछ यादृच्छिक विश्वसनीय तीसरे पक्ष की तुलना में अधिक गोपनीयता प्राप्त कर सकते हैं। + +दूसरी ओर, अगर आप कोई क्लाइंट चलाते हैं, तो आप इसे अपने उन दोस्तों के साथ साझा कर सकते हैं जिन्हें इसकी आवश्यकता हो सकती है। + +## निष्पादन ग्राहक {#execution-clients} + +एथेरियम समुदाय कई ओपन-सोर्स निष्पादन क्लाइंट (पहले 'Eth1 क्लाइंट', या सिर्फ 'एथेरियम क्लाइंट' के रूप में जाना जाता था) को बनाए रखता है, जिसे विभिन्न प्रोग्रामिंग भाषाओं का उपयोग करके विभिन्न टीमों द्वारा विकसित किया गया है। यह नेटवर्क को मजबूत और अधिक [विविध](/developers/docs/nodes-and-clients/client-diversity/) बनाता है। आदर्श लक्ष्य विफलता के किसी भी बिंदु को कम करने के लिए किसी भी ग्राहक पर हावी हुए बिना विविधता प्राप्त करना है। + +यह टेबल विभिन्न क्लाइंट को सारांशित करती है। वे सभी [क्लाइंट परीक्षण](https://github.com/ethereum/tests) पास करते हैं और नेटवर्क अपग्रेड के साथ अपडेट रहने के लिए सक्रिय रूप से बनाए रखा जाता है। + +| क्लाइंट | भाषा | ऑपरेटिंग सिस्टम | नेटवर्क | सिंक करने की रणनीतियाँ | स्टेट की छंटाई | +| ------------------------------------------------------------------------ | ---------- | --------------------- | -------------------------- | ------------------------------------------------------------- | -------------- | +| [गेथ](https://geth.ethereum.org/) | Go | Linux, Windows, macOS | मेननेट, सेपोलिया, होलेस्की | [स्नैप](#snap-sync), [फुल](#full-sync) | आर्काइव, छंटाई | +| [नेदरमाइंड](https://www.nethermind.io/) | C#, .NET | Linux, Windows, macOS | मेननेट, सेपोलिया, होलेस्की | [स्नैप](#snap-sync) (बिना सेवा के), फ़ास्ट, [फुल](#full-sync) | आर्काइव, छंटाई | +| [बेसु](https://besu.hyperledger.org/en/stable/) | Java | Linux, Windows, macOS | मेननेट, सेपोलिया, होलेस्की | [स्नैप](#snap-sync), [फास्ट](#fast-sync), [फुल](#full-sync) | आर्काइव, छंटाई | +| [एरिगोन](https://github.com/ledgerwatch/erigon) | Go | Linux, Windows, macOS | मेननेट, सेपोलिया, होलेस्की | [फुल](#full-sync) | आर्काइव, छंटाई | +| [रेथ](https://reth.rs/) | Rust | Linux, Windows, macOS | मेननेट, सेपोलिया, होलेस्की | [फुल](#full-sync) | आर्काइव, छंटाई | +| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(बीटा)_ | TypeScript | Linux, Windows, macOS | सेपोलिया, होलेस्की | [फुल](#full-sync) | छंटाई की गई | + +सपोर्ट करने वाले नेटवर्क के बारे में अधिक जानकारी के लिए, [एथेरियम नेटवर्क](/developers/docs/networks/) पर पढ़ें। + +हर क्लाइंट के पास खास उपयोग के मामले और फायदे होते हैं, इसलिए आपको अपनी प्राथमिकताओं के आधार पर एक चुनना चाहिए। विविधता कार्यान्वयन को विभिन्न विशेषताओं और यूज़र दर्शकों पर केंद्रित करने की अनुमति देती है। आप सुविधाओं, सपोर्ट, प्रोग्रामिंग भाषा या लाइसेंस के आधार पर क्लाइंट चुनना चाह सकते हैं। + +### बेसु {#besu} + +Hyperledger Besu सार्वजनिक और अनुमति प्राप्त नेटवर्क के लिए एक एंटरप्राइज़-ग्रेड एथेरियम क्लाइंट है। यह ट्रेसिंग से लेकर GraphQL तक सभी एथेरियम मेननेट सुविधाओं को चलाता है, इसकी व्यापक निगरानी है और यह खुले सामुदायिक चैनलों और एंटरप्राइज़ के लिए वाणिज्यिक SLA दोनों के माध्यम से ConsenSys द्वारा सपोर्ट करता है। यह Java में लिखा गया है और Apache 2.0 लाइसेंस प्राप्त है। + +Besu का व्यापक [प्रलेखन](https://besu.hyperledger.org/en/stable/) आपको इसकी विशेषताओं और सेटअप के बारे में सभी विवरणों के माध्यम से मार्गदर्शन करेगा। + +### एरिगोन {#erigon} + +Erigon, जिसे पहले टर्बो-गेथ के नाम से जाना जाता था, गो एथेरियम के फ़ोर्क के रूप में गति और डिस्क-स्पेस दक्षता की ओर उन्मुख था। Erigon एथेरियम का पूरी तरह से फिर से वास्तुशिल्प कार्यान्वयन है, जो वर्तमान में गो में लिखा गया है लेकिन विकास के तहत अन्य भाषाओं में कार्यान्वयन के साथ है। Erigon का लक्ष्य एथेरियम का तेज़, अधिक मॉड्यूलर और अधिक अनुकूलित कार्यान्वयन प्रदान करना है। यह 3 दिनों से कम समय में लगभग 2TB डिस्क स्थान का उपयोग करके एक फ़ुल आर्काइव नोड सिंक कर सकता है। + +### गो एथेरियम {#geth} + +गो एथेरियम (संक्षेप में Geth) एथेरियम प्रोटोकॉल के मूल कार्यान्वयन में से एक है। वर्तमान में, यह यूज़र और डिवलपर्स के लिए सबसे बड़े यूज़र आधार और विभिन्न प्रकार के टूलींग के साथ सबसे व्यापक क्लाइंट है। यह गो में लिखा गया है, पूरी तरह से खुला स्रोत और GNU LGPL v3 के तहत लाइसेंस प्राप्त है। + +Geth के बारे में इसके [प्रलेखन](https://geth.ethereum.org/docs/) में अधिक जानें। + +### नेदरमाइंड {#nethermind} + +Nethermind एक एथेरियम कार्यान्वयन है जिसे C# .NET टेक स्टैक के साथ बनाया गया है, जिसे LGPL-3.0 के साथ लाइसेंस प्राप्त है, जो ARM सहित सभी प्रमुख प्लेटफ़ार्मों पर चल रहा है। यह इसके साथ शानदार परफ़ॉर्मेंस प्रदान करता है: + +- एक कस्टमाइज़ की गई वर्चुअल मशीन +- स्टेट एक्सेस +- नेटवर्किंग और समृद्ध विशेषताएं जैसे Prometheus/Grafana डैशबोर्ड, seq एंटरप्राइज़ लॉगिंग सपोर्ट, JSON-RPC ट्रेसिंग और एनालिटिक्स प्लगइन्स। + +Nethermind में प्रीमियम यूज़र के लिए [विस्तृत प्रलेखन](https://docs.nethermind.io), मजबूत डेवलपर सपोर्ट, एक ऑनलाइन समुदाय और 24/7 सपोर्ट भी उपलब्ध है। + +### रेथ {#reth} + +Reth (Rust एथेरियम के लिए छोटा) एक एथेरियम फ़ुल नोड कार्यान्वयन है जो यूज़र के अनुकूल, बहुत ज़्यादा मॉड्यूलर, तेज और कुशल होने पर केंद्रित है। Reth मूल रूप से Paradigm द्वारा बनाया और आगे बढ़ाया गया था, और Apache और MIT लाइसेंस के तहत लाइसेंस प्राप्त है। + +Reth उत्पादन के लिए तैयार है, और मिशन-महत्वपूर्ण वातावरण जैसे स्टेकिंग या हाई-अपटाइम सेवाओं में उपयोग के लिए सही है। उपयोग के मामलों में अच्छी परफ़ॉर्मेंस देता है जहां RPC, MEV, इंडेक्सिंग, सिमुलेशन और P2P गतिविधियों जैसे महान मार्जिन के साथ बेहतरीन परफ़ॉर्मेंस की आवश्यकता होती है। + +चेक आउट करके और जानें [Reth बुक](https://reth.rs/), या [Reth GitHub रेपो](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth)। + +### विकास प्रक्रिया में {#execution-in-development} + +ये क्लाइंट अब भी विकास के पहले चरणों में हैं और अभी तक उत्पादन उपयोग के लिए नहीं सुझाए गए हैं। + +#### EthereumJS {#ethereumjs} + +EthereumJS निष्पादन क्लाइंट (EthereumJS) TypeScript में लिखा गया है और कई पैकेजों से बना है, जिसमें ब्लॉक, ट्रांज़ैक्शन और मर्कल-पेट्रीसिया ट्राई वर्गों द्वारा दर्शाए गए कोर एथेरियम प्राइमेटिव और एथेरियम वर्चुअल मशीन (EVM), एक ब्लॉकचेन क्लास और DevP2P नेटवर्किंग स्टैक के कार्यान्वयन सहित कोर क्लाइंट घटक शामिल हैं। + +इसके [प्रलेखन](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master) को पढ़कर इसके बारे में अधिक जानें + +## सहमति ग्राहक {#consensus-clients} + +[सर्वसम्मति उन्नयन](/roadmap/beacon-chain/) का सपोर्ट करने के लिए कई सर्वसम्मति वाले ग्राहक (पहले 'Eth2' क्लाइंट के रूप में जाने जाते थे) हैं। वे सभी सर्वसम्मति-संबंधी तर्कों के लिए ज़िम्मेदार हैं जिनमें फ़ोर्क-चॉइस एल्गोरिथम, प्रोसेसिंग सत्यापन और प्रबंधन [हिस्सेदारी का सबूत](/developers/docs/consensus-mechanisms/pos) पुरस्कार और दंड शामिल हैं। + +| क्लाइंट | भाषा | ऑपरेटिंग सिस्टम | नेटवर्क | +| -------------------------------------------------------------- | ---------- | --------------------- | ------------------------------------------------------------------- | +| [लाइटहाउस](https://lighthouse.sigmaprime.io/) | Rust | Linux, Windows, macOS | बीकन चेन, गोएर्ली, पिरमोंट, सेपोलिया, रोपस्टेन और बहुत कुछ | +| [लोडस्टार](https://lodestar.chainsafe.io/) | TypeScript | Linux, Windows, macOS | बीकन चेन, गोएर्ली, सेपोलिया, रोपस्टेन और बहुत कुछ | +| [निंबस](https://nimbus.team/) | Nim | Linux, Windows, macOS | बीकन चेन, गोएर्ली, सेपोलिया, रोपस्टेन और बहुत कुछ | +| [प्रिज़्म](https://docs.prylabs.network/docs/getting-started/) | Go | Linux, Windows, macOS | बीकन चेन, ग्नोसिस, गोएर्ली, पिरमोंट, सेपोलिया, रोपस्टेन और बहुत कुछ | +| [टेकु](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux, Windows, macOS | बीकन चेन, ग्नोसिस, गोएर्ली, सेपोलिया, रोपस्टेन और बहुत कुछ | +| [ग्रांडाइन](https://docs.grandine.io/) (बीटा) | Rust | Linux, Windows, macOS | बीकन चेन, गोएर्ली, सेपोलिया और बहुत कुछ | + +### लाइटहाउस {#lighthouse} + +लाइटहाउस Apache-2.0 लाइसेंस के तहत Rust में लिखा गया एक सर्वसम्मति ग्राहक कार्यान्वयन है। यह सिग्मा प्राइम द्वारा बनाए रखा गया है और बीकन चेन उत्पत्ति के बाद से स्थिर और उत्पादन के लिए तैयार है। यह विभिन्न एंटरप्राइज़, स्टेकिंग पूल और व्यक्तियों द्वारा भरोसा किया जाता है। इसका उद्देश्य डेस्कटॉप PC से परिष्कृत स्वचालित डिप्लॉयमेंट तक, वातावरण की एक विस्तृत सीरीजत़ में सुरक्षित, प्रदर्शनकारी और इंटरऑपरेबल होना है। + +प्रलेखन [लाइटहाउस बुक](https://lighthouse-book.sigmaprime.io/) में पाया जा सकता है + +### लोडस्टार {#lodestar} + +Lodestar LGPL-3.0 लाइसेंस के तहत TypeScript में लिखा गया एक उत्पादन-तैयार सर्वसम्मति ग्राहक कार्यान्वयन है। यह ChainSafe सिस्टम्स द्वारा बनाए रखा जाता है और एकल-स्टेकर्स, डिवलपर्स और शोधकर्ताओं के लिए आम सहमति ग्राहकों में सबसे नया है। Lodestar में एक बीकन नोड और सत्यापनकर्ता क्लाइंट होता है जो एथेरियम प्रोटोकॉल के JavaScript कार्यान्वयन द्वारा संचालित होता है। Lodestar का उद्देश्य लाइट क्लाइंट के साथ एथेरियम उपयोगिता में सुधार करना, डिवलपर्स के एक बड़े समूह तक पहुंच का विस्तार करना और ईकोसिस्टम की विविधता में और योगदान करना है। + +अधिक जानकारी हमारे [Lodestar वेबसाइट](https://lodestar.chainsafe.io/) पर पाई जा सकती है + +### निंबस {#nimbus} + +Nimbus, Apache-2.0 लाइसेंस के तहत Nim में लिखा गया एक सर्वसम्मति ग्राहक कार्यान्वयन है। यह एकल-स्टेकर्स और स्टेकिंग पूल द्वारा उपयोग में उत्पादन के लिए तैयार एक क्लाइंट है। Nimbus को संसाधन दक्षता के लिए डिज़ाइन किया गया है, जिससे स्थिरता या इनाम प्रदर्शन से समझौता किए बिना, संसाधन-प्रतिबंधित उपकरणों और एंटरप्राइज़ संबंधी बुनियादी ढांचे पर समान आसानी से चलना आसान हो जाता है। एक लाइट संसाधन पदचिह्न का मतलब है कि नेटवर्क तनाव में होने पर क्लाइंट के पास सुरक्षा का अधिक मार्जिन होता है। + +[Nimbus डॉक्स](https://nimbus.guide/) में अधिक जानें + +### प्रिज़्म {#prysm} + +प्रिज़्म GPL-3.0 लाइसेंस के तहत गो में लिखा गया एक पूर्ण विशेषताओं वाला, ओपन सोर्स सर्वसम्मति वाला क्लाइंट है। इसमें एक वैकल्पिक वेबपैप UI है और यह स्टेक-एट-होम और संस्थागत उपयोगकर्ताओं दोनों के लिए यूज़र अनुभव, प्रलेखन और विन्यास को प्राथमिकता देता है। + +अधिक जानने के लिए [प्रिज़्म डॉक्स](https://docs.prylabs.network/docs/getting-started/) पर जाएं। + +### टेकु {#teku} + +Teku मूल बीकन चेन उत्पत्ति वाले क्लाइंट में से एक है। सामान्य लक्ष्यों (सुरक्षा, मजबूती, स्थिरता, प्रयोज्यता, प्रदर्शन) के साथ, Teku का उद्देश्य विशेष रूप से सभी विभिन्न सर्वसम्मति वाले ग्राहक संबंधी मानकों का पूरी तरह से पालन करना है। + +Teku बहुत लचीले परिनियोजन विकल्प प्रदान करता है। बीकन नोड और सत्यापनकर्ता क्लाइंट को एक ही प्रक्रिया के रूप में एक साथ चलाया जा सकता है, जो सिंगल स्टेकर्स के लिए बेहद सुविधाजनक है, या परिष्कृत स्टेकिंग संचालन के लिए नोड्स को अलग से चलाया जा सकता है। इसके अलावा, Teku प्रमुख सुरक्षा और स्लैशिंग सुरक्षा पर हस्ताक्षर करने के लिए [Web3Signer](https://github.com/ConsenSys/web3signer/) के साथ पूरी तरह से इंटरऑपरेबल है। + +Teku, Java में लिखा गया है और Apache 2.0 लाइसेंस प्राप्त है। इसे ConsenSys में प्रोटोकॉल टीम द्वारा विकसित किया गया है जो Besu और Web3Signer के लिए भी ज़िम्मेदार है। [Teku डॉक्स](https://docs.teku.consensys.net/en/latest/) में और जानें। + +### Grandine {#grandine} + +ग्रैंडाइन एक सर्वसम्मति वाले क्लाइंट से संबंधित कार्यान्वयन है, जिसे GPL-3.0 लाइसेंस के तहत Rust में लिखा गया है। इसका रखरखाव ग्रैंडाइन कोर टीम द्वारा किया जाता है और यह तेज़, बेहतर परफ़ॉर्मेंस वाला और हल्का है। यह रास्पबेरी पाई जैसे कम संसाधन वाले उपकरणों पर चलने वाले सिंगल स्टेकरों से लेकर हज़ारों सत्यापनकर्ताओं को चलाने वाले बड़े संस्थागत स्टेकर्स तक, विभिन्न प्रकार के स्टेकर्स के लिए उपयुक्त है। + +प्रलेखन [ग्रैंडाइन बुक](https://docs.grandine.io/) में पाया जा सकता है + +## सिंक्रनाइज़ेशन मोड {#sync-modes} + +नेटवर्क में वर्तमान डेटा का पालन करने और सत्यापित करने के लिए, एथेरियम क्लाइंट को नेटवर्क की नई स्टेट के साथ सिंक करने की आवश्यकता है। यह साथियों से डेटा डाउनलोड करके, क्रिप्टोग्राफ़िक रूप से उनकी इंटीग्रिटी की पुष्टि करके और स्थानीय ब्लॉकचेन डेटाबेस का निर्माण करके किया जाता है। + +सिंक्रनाइज़ेशन मोड विभिन्न ट्रेड-ऑफ़ के साथ इस प्रक्रिया के विभिन्न दृष्टिकोणों को दर्शाते हैं। क्लाइंट सिंक एल्गोरिदम के कार्यान्वयन में भी भिन्न होते हैं। कार्यान्वयन पर बारीकियों के लिए हमेशा अपने चुने हुए ग्राहक के आधिकारिक प्रलेखन देखें। + +### निष्पादन परत सिंक मोड {#execution-layer-sync-modes} + +निष्पादन परत को अलग-अलग उपयोग के मामलों के हिसाब से अलग-अलग मोड में चलाया जा सकता है, ब्लॉकचेन की वैश्विक स्थिति को फिर से निष्पादित करने से लेकर केवल एक विश्वसनीय चेकपॉइंट से सीरीज़ की नोक के साथ समन्वयित करने तक। + +#### फ़ुल सिंक {#full-sync} + +एक फ़ुल सिंक सभी ब्लॉकों (हेडर और ब्लॉक निकायों सहित) को डाउनलोड करता है और उत्पत्ति से हर ब्लॉक को निष्पादित करके ब्लॉकचेन की स्टेट को आगे बढ़ाते हुए फिर से जेनरेट करता है। + +- विश्वास को कम करता है और प्रत्येक लेनदेन को सत्यापित करके उच्चतम सुरक्षा प्रदान करता है। +- लेन-देन की बढ़ती संख्या के साथ, सभी लेनदेन को प्रोसेस करने में दिनों से लेकर हफ़्तों तक का समय लग सकता है। + +[आर्काइव नोड्स](#archive-node) हर ब्लॉक में हर लेनदेन द्वारा किए गए स्टेट संबंधी बदलावों का एक पूरा इतिहास बनाने (और बनाए रखने) के लिए एक फ़ुल सिंक करते हैं। + +#### फ़ास्ट सिंक {#fast-sync} + +एक फ़ुल सिंक की तरह, एक तेज़ सिंक सभी ब्लॉक (हेडर, लेनदेन और रसीदों सहित) को डाउनलोड करता है। हालांकि, ऐतिहासिक लेनदेन को फिर से प्रोसेस करने के बजाय, एक तेज़ सिंक रसीदों पर निर्भर करता है जब तक कि यह हाल के सिर तक नहीं पहुंच जाता, जब यह एक फ़ुल नोड प्रदान करने के लिए आयात और प्रसंस्करण ब्लॉक पर स्विच करता है। + +- फ़ास्ट सिंक रणनीति। +- बैंडविड्थ उपयोग के पक्ष में प्रसंस्करण मांग को कम करता है। + +#### स्नैप सिंक {#snap-sync} + +स्नैप सिंक सीरीज़ एक-एक करके हर ब्लॉक को भी सत्यापित करता है। हालांकि, उत्पत्ति ब्लॉक से शुरू होने के बजाय, एक स्नैप सिंक हाल ही में 'विश्वसनीय' चेकपॉइंट पर शुरू होता है जिसे सच्चे ब्लॉकचेन का हिस्सा माना जाता है। नोड एक निश्चित आयु से अधिक पुराने डेटा को हटाते समय आवधिक चौकियों को बचाता है। इन स्नैपशॉट का उपयोग स्टेट डेटा को हमेशा के लिए संग्रहीत करने के बजाय, इसे ज़रूरत के हिसाब से फिर से उत्पन्न करने के लिए किया जाता है। + +- सबसे तेज़ सिंक रणनीति, वर्तमान में एथेरियम मेननेट में डिफ़ॉल्ट। +- सुरक्षा का त्याग किए बिना बहुत सारे डिस्क उपयोग और नेटवर्क बैंडविड्थ बचाता है। + +[स्नैप सिंक पर अधिक जानकारी](https://github.com/ethereum/devp2p/blob/master/caps/snap.md)। + +#### लाइट सिंक {#light-sync} + +लाइट क्लाइंट मोड सभी ब्लॉक हेडर डाउनलोड करता है, डेटा ब्लॉक करता है, और कुछ बेतरतीब ढंग से सत्यापित करता है। केवल विश्वसनीय चेकपॉइंट से सीरीज़ की नोक को सिंक करता है। + +- डिवलपर्स और सर्वसम्मति तंत्र में विश्वास पर भरोसा करते हुए केवल नई स्टेट प्राप्त करता है। +- क्लाइंट कुछ ही मिनटों में वर्तमान नेटवर्क स्टेट के साथ उपयोग करने के लिए तैयार है। + +**NB** लाइट सिंक अभी तक हिस्सेदारी के सूबत वाले एथेरियम के साथ काम नहीं करता है - लाइट सिंक के नए संस्करणों को जल्द ही शिप करना चाहिए! + +[लाइट क्लाइंट्स के बारे में अधिक जानकारी](/developers/docs/nodes-and-clients/light-clients/) + +### आम सहमति परत सिंक मोड {#consensus-layer-sync-modes} + +#### आशावादी सिंक {#optimistic-sync} + +आशावादी सिंक एक पोस्ट-मर्ज सिंक्रनाइज़ेशन रणनीति है जिसे ऑप्ट-इन और पीछे की ओर संगत होने के लिए डिज़ाइन किया गया है, जिससे निष्पादन नोड्स तय तरीकों के माध्यम से सिंक हो सकते हैं। निष्पादन इंजन उन्हें पूरी तरह से सत्यापित किए बिना बीकन ब्लॉक को _आशावादी रूप_ से आयात कर सकता है, नया हेड ढूंढ सकता है, और फिर उपरोक्त तरीकों के साथ सीरीज़ को सिंक करना शुरू कर सकता है। फिर, निष्पादन ग्राहक का पता चलने के बाद, यह बीकन सीरीज़ में लेनदेन की वैधता के आम सहमति वाले ग्राहक को सूचित करेगा। + +[आशावादी सिंक पर अधिक जानकारी](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md) + +#### चेकपॉइंट सिंक {#checkpoint-sync} + +एक चेकपॉइंट सिंक, जिसे कमजोर सब्जेक्टिविटी सिंक के रूप में भी जाना जाता है, बीकन नोड को सिंक करने के लिए एक बेहतर उपयोगकर्ता अनुभव देता है। यह [कमजोर व्यक्तिपरकता](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) की मान्यताओं पर आधारित है जो उत्पत्ति के बजाय हाल ही में कमजोर व्यक्तिपरकता चेकपॉइंट से बीकन चेन को सिंक करने में सक्षम बनाता है। चेकपॉइंट सिंक, सिंक में लगने वाले शुरुआती समय को समान ट्रस्ट मान्यताओं के साथ काफी तेज बनाते हैं जैसे कि [जेनेसिस](/glossary/#genesis-block) से सिंक करना। + +व्यवहार में, इसका मतलब है कि आपका नोड हाल ही में अंतिम रूप दिए गए स्टेट को डाउनलोड करने के लिए एक दूरस्थ सेवा से जुड़ता है और उस बिंदु से डेटा की पुष्टि करना जारी रखता है। डेटा प्रदान करने वाला तीसरा-पक्ष विश्वसनीय है और इसे सावधानी से चुना जाना चाहिए। + +[चेकपॉइंट सिंक](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice) पर अधिक जानकारी + +## अग्रिम पठन {#further-reading} + +- [एथेरियम 101 - भाग 2 - नोड्स को समझना](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) - _विल बार्न्स, 13 फ़रवरी 2019_ +- [एथेरियम फुल नोड्स चलाना: बमुश्किल प्रेरित लोगों के लिए एक गाइड](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– जस्टिन लेरौक्स, 7 नवंबर 2019_ + +## संबंधित विषय {#related-topics} + +- [ब्लॉक](/developers/docs/blocks/) +- [नेटवर्क](/developers/docs/networks/) + +## संबंधित ट्यूटोरियल {#related-tutorials} + +- [MicroSD कार्ड को फ़्लैश करके अपने रास्पबेरी पाई 4 को एक सत्यापनकर्ता नोड में बदल दें - इंस्टॉलेशन गाइड](/developers/tutorials/run-node-raspberry-pi/) _– अपने रास्पबेरी पाई 4 को फ़्लैश करें, एक ईथरनेट केबल में प्लग करें, SSD डिस्क को कनेक्ट करें और रास्पबेरी पाई 4 को पूर्ण एथेरियम नोड में बदलने के लिए डिवाइस को पावर दें निष्पादन परत (मेननेट) और / या सर्वसम्मति परत (बीकन चेन / सत्यापनकर्ता) चल रहा है।_ diff --git a/public/content/translations/hi/developers/docs/nodes-and-clients/light-clients/index.md b/public/content/translations/hi/developers/docs/nodes-and-clients/light-clients/index.md new file mode 100644 index 00000000000..3443855ac37 --- /dev/null +++ b/public/content/translations/hi/developers/docs/nodes-and-clients/light-clients/index.md @@ -0,0 +1,61 @@ +--- +title: लाइट क्लाइंट +description: एथेरियम लाइट क्लाइंट का परिचय। +lang: hi +--- + +एक पूर्ण नोड चलाना एथेरियम के साथ बातचीत करने का सबसे भरोसेमंद, निजी, विकेन्द्रीकृत और सेंसरशिप प्रतिरोधी तरीका है। एक पूर्ण नोड के साथ आप ब्लॉकचेन की अपनी प्रति रखते हैं जिसे आप तुरंत क्वेरी कर सकते हैं और आपको एथेरियम के पीयर-टू-पीयर नेटवर्क तक सीधी पहुंच प्राप्त होती है। हालाँकि, पूर्ण नोड चलाने के लिए काफी मात्रा में मेमोरी, भंडारण और CPU की आवश्यकता होती है। इसका मतलब है कि हर किसी के लिए अपना नोड चलाना संभव नहीं है। एथेरियम रोडमैप पर इसके कई समाधान हैं, जिनमें स्थितिविहीनता भी शामिल है, लेकिन वे लागू होने से कई साल दूर हैं। निकट अवधि में उत्तर बड़े प्रदर्शन सुधारों के लिए एक पूर्ण नोड चलाने के कुछ लाभों का ट्रेड-ऑफ़ करना है जो नोड्स को बहुत कम हार्डवेयर आवश्यकताओं के साथ चलाने की अनुमति देते हैं। इस ट्रेड-ऑफ को बनाने वाले नोड्स को लाइट नोड्स के रूप में जाना जाता है। + +## एक लाइट क्लाइंट क्या है {#what-is-a-light-client} + +एक लाइट नोड एक नोड है जो लाइट क्लाइंट सॉफ़्टवेयर चला रहा है। ब्लॉकचेन डेटा की स्थानीय प्रतियां रखने और स्वतंत्र रूप से सभी परिवर्तनों को सत्यापित करने के बजाय, वे कुछ प्रदाता से आवश्यक डेटा का अनुरोध करते हैं। प्रदाता एक पूर्ण नोड के लिए या कुछ केंद्रीकृत RPC सर्वर के माध्यम से एक सीधा कनेक्शन हो सकता है। डेटा को तब लाइट नोड द्वारा सत्यापित किया जाता है, जिससे यह श्रृंखला के प्रमुख के साथ बने रह सकता है। लाइट नोड केवल ब्लॉक हेडर को संसाधित करता है, केवल कभी-कभी वास्तविक ब्लॉक सामग्री डाउनलोड करता है। नोड्स उनके हल्केपन में भिन्न हो सकते हैं, जो उनके द्वारा चलाए जाने वाले लाइट और पूर्ण क्लाइंट सॉफ़्टवेयर के संयोजन पर निर्भर करता है। उदाहरण के लिए, सबसे लाइट कॉन्फ़िगरेशन एक लाइट निष्पादन ग्राहक और एक हल्का सहमति ग्राहक चलाने के लिए होगा। यह भी संभावना है कि कई नोड्स पूर्ण निष्पादन ग्राहक के साथ लाइट सहमति ग्राहक को चलाने का विकल्प चुनेंगे, या इसके विपरीत। + +## लाइट क्लाइंट कैसे काम करते हैं? {#how-do-light-clients-work} + +जब एथेरियम ने हिस्सेदारी का सबूत आधारित आम सहमति तंत्र का उपयोग करना शुरू किया, तो विशेष रूप से लाइट क्लाइंट का समर्थन करने के लिए नया बुनियादी ढांचा पेश किया गया। जिस तरह से यह काम करता है वह **सिंक समिति** के रूप में कार्य करने के लिए हर 512 दिनों में 1.1 सत्यापनकर्ताओं के सबसेट का बेतरतीब ढंग से चयन करके होता है। सिंक समिति हाल के ब्लॉकों के हेडर पर हस्ताक्षर करती है। प्रत्येक ब्लॉक हेडर में सिंक समिति में सत्यापनकर्ताओं के एकत्रित हस्ताक्षर और एक "बिटफ़ील्ड" होता है जो दिखाता है कि किस सत्यापनकर्ता ने हस्ताक्षर किए है और किस ने नहीं। प्रत्येक हेडर में अगले ब्लॉक पर हस्ताक्षर करने में भाग लेने की उम्मीद वाले सत्यापनकर्ताओं की एक सूची भी शामिल होती है। इसका मतलब यह है कि एक लाइट क्लाइंट जल्दी से देख सकता है कि सिंक समिति ने उन्हें प्राप्त होने वाले डेटा पर हस्ताक्षर किए हैं, और वे यह भी जांच सकते हैं कि सिंक समिति वास्तविक है, जो उन्हें पिछले ब्लॉक में उम्मीद करने के लिए कहा गया था। इस तरह, लाइट क्लाइंट वास्तव में ब्लॉक को डाउनलोड किए बिना नवीनतम एथेरियम ब्लॉक के अपने ज्ञान को अपडेट कर सकता है, केवल हेडर जिसमें सारांश जानकारी होती है। + +निष्पादन परत पर लाइट निष्पादन ग्राहक के लिए कोई एकल विनिर्देश नहीं है। एक हल्का निष्पादन ग्राहक का दायरा एक पूर्ण निष्पादन ग्राहक के "लाइट मोड" से भिन्न हो सकता है जिसमें एक पूर्ण नोड की सभी EVM और नेटवर्किंग कार्यक्षमता होती है, लेकिन संबंधित डेटा डाउनलोड किए बिना केवल ब्लॉक हेडर की पुष्टि करता है, या यह एक अधिक छीन लिया गया क्लाइंट हो सकता है जो एथेरियम के साथ इंटरैक्ट करने के लिए RPC प्रदाता को अग्रेषित अनुरोधों पर बहुत अधिक निर्भर करता है। + +## लाइट क्लाइंट क्यों महत्वपूर्ण हैं? {#why-are-light-clients-important} + +लाइट क्लाइंट मायने रखते हैं क्योंकि वे यूज़र को आने वाले डेटा को सत्यापित करने की अनुमति देते हैं, बजाय इसके कि उनका डेटा प्रदाता सही और ईमानदार है, जबकि वे एक पूर्ण नोड के कम्प्यूटेशनल संसाधनों के केवल एक छोटे से हिस्से का उपयोग करते हैं। डेटा लाइट क्लाइंट को प्राप्त होने वाले ब्लॉक हेडर के खिलाफ चेक किया जा सकता है जिनके बारे में उन्हें पता है कि 512 एथेरियम सत्यापनकर्ताओं के यादृच्छिक सेट के कम से कम 2/3 द्वारा हस्ताक्षर किए गए हैं। यह बहुत मजबूत सबूत है कि डेटा सही है। + +लाइट क्लाइंट केवल कंप्यूटिंग पावर, मेमोरी और भंडारण की एक छोटी मात्रा का उपयोग करता है, इसलिए इसे मोबाइल फोन पर चलाया जा सकता है, ऐप में एम्बेडेड या ब्राउज़र के हिस्से के रूप में चलाया जा सकता है। लाइट क्लाइंट एथेरियम तक विश्वास-न्यूनतम पहुंच बनाने का एक तरीका है, जैसे कि किसी तृतीय-पक्ष प्रदाता पर भरोसा करना। + +आइए एक सरल उदाहरण लेते हैं। कल्पना कीजिए कि आप अपने खाते की शेष राशि की जांच करना चाहते हैं। ऐसा करने के लिए आपको एथेरियम नोड से अनुरोध करना होगा। वह नोड आपकी शेष राशि के लिए एथेरियम स्थिति की अपनी स्थानीय प्रति की जांच करेगा और इसे आपको वापस कर देगा। यदि आपके पास नोड तक सीधी पहुंच नहीं है, तो केंद्रीकृत ऑपरेटर हैं जो इस डेटा को एक सेवा के रूप में प्रदान करते हैं। आप उन्हें एक अनुरोध भेज सकते हैं, वे अपने नोड की जांच करते हैं, और परिणाम आपको वापस भेजते हैं। इसके साथ समस्या यह है कि आपको तब प्रदाता पर भरोसा करना होगा कि वह आपको सही जानकारी दे रहा है। आप वास्तव में कभी नहीं जान सकते कि जानकारी सही है यदि आप इसे अपने लिए सत्यापित नहीं कर सकते हैं। + +एक लाइट क्लाइंट इस समस्या को हल करता है। आप अभी भी कुछ बाहरी प्रदाता से डेटा का अनुरोध करते हैं, लेकिन जब आप डेटा वापस प्राप्त करते हैं तो यह एक प्रमाण के साथ आता है कि आपका लाइट नोड ब्लॉक हेडर में प्राप्त जानकारी के खिलाफ जांच कर सकता है। इसका मतलब है कि एथेरियम कुछ विश्वसनीय ऑपरेटर के बजाय आपके डेटा की शुद्धता की पुष्टि कर रहा है। + +## लाइट क्लाइंट किन नवाचारों को सक्षम करते हैं? {#what-innovations-do-light-clients-enable} + +हल्के क्लाइंट का प्राथमिक लाभ अधिक लोगों को नगण्य हार्डवेयर आवश्यकताओं और तृतीय पक्ष पर न्यूनतम निर्भरता के साथ स्वतंत्र रूप से एथेरियम तक पहुंचने में सक्षम बनाना है। यह यूज़र के लिए अच्छा है क्योंकि वे अपने स्वयं के डेटा को सत्यापित कर सकते हैं और यह नेटवर्क के लिए अच्छा है क्योंकि यह श्रृंखला को सत्यापित करने वाले नोड्स की संख्या और विविधता को बढ़ाता है। + +बहुत छोटे भंडारण, मेमोरी और प्रोसेसिंग शक्ति वाले उपकरणों पर एथेरियम नोड्स चलाने की क्षमता लाइट क्लाइंट द्वारा अनलॉक किए गए नवाचार के प्रमुख क्षेत्रों में से एक है। जबकि आज एथेरियम नोड्स को बहुत सारे कंप्यूटिंग संसाधनों की आवश्यकता होती है, लाइट क्लाइंट को ब्राउज़रों में एम्बेड किया जा सकता है, मोबाइल फोन पर चलाया जा सकता है और शायद स्मार्ट घड़ियों जैसे छोटे उपकरणों पर भी चलाया जा सकता है। इसका मतलब है कि एम्बेडेड क्लाइंट वाले एथेरियम वॉलेट मोबाइल फोन पर चल सकते हैं। इसका मतलब है कि मोबाइल वॉलेट बहुत अधिक विकेंद्रीकृत हो सकते हैं क्योंकि उन्हें अपने डेटा के लिए केंद्रीकृत डेटा प्रदाताओं पर भरोसा नहीं करना पड़ेगा। + +इसका एक विस्तार **इंटरनेट ऑफ थिंग्स (IoT)** उपकरणों को सक्षम कर रहा है। एक लाइट क्लाइंट का उपयोग कुछ टोकन बैलेंस या NFT के स्वामित्व को जल्दी से साबित करने के लिए किया जा सकता है, सिंक समितियों द्वारा प्रदान की गई सभी सुरक्षा गारंटी के साथ, IoT नेटवर्क पर कुछ कार्रवाई को ट्रिगर करना। एक [साइकिल किराए पर लेने की सेवा](https://youtu.be/ZHNrAXf3RDE?t=929) की कल्पना करें जो एक एम्बेडेड लाइट क्लाइंट के साथ एक ऐप का उपयोग करके जल्दी से सत्यापित करता है कि आप किराये की सेवा के NFT के मालिक हैं और यदि ऐसा है, तो आपके लिए सवारी करने के लिए एक साइकिल अनलॉक करता है! + +एथेरियम रोलअप को लाइट क्लाइंट से भी फायदा होगा। रोलअप के लिए बड़ी समस्याओं में से एक हैकिंग है जो उन ब्रिज को लक्षित करती है जो धन को एथेरियम मेननेट से रोलअप में स्थानांतरित करने की अनुमति देते हैं। एक कमजोरी यह है कि रोलअप ओरेकल्स का उपयोग यह पता लगाने के लिए करता है कि यूज़र ने ब्रिज में कोई जमा राशि जमा की है। यदि कोई ओरेकल खराब डेटा प्रदान करता है, तो वे रोलअप को यह सोचकर धोखा दे सकते हैं कि ब्रिज में जमा राशि है, और गलत तरीके से धनराशि जारी कर सकते हैं। रोलअप में एम्बेडेड एक लाइट क्लाइंट का उपयोग खराब ओरेकल्स से बचाने के लिए किया जा सकता है क्योंकि ब्रिज में जमा एक प्रमाण के साथ आ सकता है जिसे किसी भी टोकन को जारी करने से पहले रोलअप द्वारा सत्यापित किया जा सकता है। इसी अवधारणा को अन्य इंटरचेन ब्रिज पर भी लागू किया जा सकता है। + +लाइट क्लाइंट का उपयोग एथेरियम वॉलेट को अपग्रेड करने के लिए भी किया जा सकता है। RPC प्रदाता द्वारा प्रदान किए गए डेटा पर भरोसा करने के बजाय, आपका वॉलेट सीधे एम्बेडेड लाइट क्लाइंट का उपयोग करके आपके सामने प्रस्तुत किए जा रहे डेटा को सत्यापित कर सकता है। यह आपके वॉलेट में सुरक्षा जोड़ देगा। यदि आपका RPC प्रदाता बेईमान था और आपको गलत डेटा प्रदान करता है, तो एम्बेडेड लाइट क्लाइंट आपको बता सकता है! + +## लाइट क्लाइंट विकास की वर्तमान स्थिति क्या है? {#current-state-of-development} + +विकास में कई लाइट क्लाइंट होते हैं, जिनमें निष्पादन, आम सहमति और संयुक्त निष्पादन/सहमति लाइट क्लाइंट शामिल हैं। ये लाइट क्लाइंट कार्यान्वयन हैं जिन्हें हम इस पृष्ठ को लिखने के समय जानते हैं: + +- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): TypeScript में आम सहमति लाइट क्लाइंट +- [Helios](https://github.com/a16z/helios): Rust में संयुक्त निष्पादन और आम सहमति लाइट क्लाइंट +- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light): गो में निष्पादन ग्राहक (विकास में) के लिए लाइट मोड +- [Nimbus](https://nimbus.guide/el-light-client.html): Nim में आम सहमति लाइट क्लाइंट + +हमारी जानकारी के अनुसार इनमें से कोई भी अभी तक उत्पादन के लिए तैयार नहीं माना जाता है। + +उन तरीकों को बेहतर बनाने के लिए भी बहुत काम किया जा रहा है जो लाइट क्लाइंट एथेरियम डेटा तक पहुंच सकते हैं। सर्वर मॉडल का उपयोग करके पूर्ण नोड्स के लिए RPC अनुरोधों पर भरोसा करते हैं, लेकिन भविष्य में डेटा को एक समर्पित नेटवर्क जैसे [पोर्टल नेटवर्क](https://www.ethportal.net/) का उपयोग करके अधिक विकेन्द्रीकृत तरीके से अनुरोध किया जा सकता है जो पीयर-टू-पीयर गपशप प्रोटोकॉल का उपयोग करके लाइट क्लाइंट को डेटा प्रदान कर सकता है। + +अन्य [रोडमैप](/roadmap/) आइटम जैसे कि [वर्कल ट्री](/roadmap/verkle-trees/) और [स्थितिविहीनता](/roadmap/statelessness/) अंततः पूर्ण क्लाइंट के बराबर लाइट क्लाइंट की सुरक्षा गारंटी लाएंगे। + +## अग्रिम पठन {#further-reading} + +- [Geth लाइट क्लाइंट पर जोल्ट फेलफोधी](https://www.youtube.com/watch?v=EPZeFXau-RE) +- [लाइट क्लाइंट नेटवर्किंग पर एटन किसलिंग](https://www.youtube.com/watch?v=85MeiMA4dD8) +- [मर्ज के बाद लाइट क्लाइंट पर एटन किसलिंग](https://www.youtube.com/watch?v=ZHNrAXf3RDE) +- [पाइपर मरियम: कार्यात्मक लाइट क्लाइंट के लिए घुमावदार सड़क](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/) diff --git a/public/content/translations/hi/developers/docs/nodes-and-clients/node-architecture/index.md b/public/content/translations/hi/developers/docs/nodes-and-clients/node-architecture/index.md new file mode 100644 index 00000000000..4650a3ceba6 --- /dev/null +++ b/public/content/translations/hi/developers/docs/nodes-and-clients/node-architecture/index.md @@ -0,0 +1,57 @@ +--- +title: नोड वास्तुकला +description: एथेरियम नोड्स कैसे व्यवस्थित किए जाते हैं, इसका परिचय। +lang: hi +--- + +एक एथेरियम नोड दो क्लाइंट से बना होता है: एक [निष्पादन ग्राहक](/developers/docs/nodes-and-clients/#execution-clients) और एक [सहमति ग्राहक](/developers/docs/nodes-and-clients/#consensus-clients)। + +जब एथेरियम [काम का सबूत](/developers/docs/consensus-mechanisms/pow/) का उपयोग कर रहा था, तो एक निष्पादन ग्राहक एक पूर्ण एथेरियम नोड चलाने के लिए पर्याप्त था। हालांकि, [हिस्सेदारी का सबूत](/developers/docs/consensus-mechanisms/pow/) को लागू करने के बाद से निष्पादन ग्राहक को [“"सहमति ग्राहक"](/developers/docs/nodes-and-clients/#consensus-clients) नामक सॉफ़्टवेयर के एक अन्य हिस्से के साथ उपयोग करने की आवश्यकता होती है। + +नीचे दिया गया आरेख दो एथेरियम क्लाइंट के बीच संबंध दिखाता है। दो क्लाइंट अपने स्वयं के संबंधित पीयर-टू-पीयर (P2P) नेटवर्क से जुड़ते हैं। अलग-अलग P2P नेटवर्क की आवश्यकता होती है क्योंकि निष्पादन ग्राहक अपने P2P नेटवर्क पर गपशप लेनदेन करते हैं, जिससे उन्हें अपने स्थानीय लेनदेन पूल का प्रबंधन करने में सक्षम बनाया जाता है, जबकि सहमति ग्राहक अपने P2P नेटवर्क पर गपशप ब्लॉक करते हैं, जिससे आम सहमति और श्रृंखला विकास को सक्षम किया जाता है। + +![](node-architecture-text-background.png) + +इस दो-क्लाइंट संरचना के काम करने के लिए, सहमति ग्राहक को निष्पादन ग्राहक को लेनदेन के बंडलों को पारित करने में सक्षम होना चाहिए। स्थानीय स्तर पर लेनदेन निष्पादित करने से क्लाइंट यह सत्यापित करता है कि लेनदेन किसी भी एथेरियम नियमों का उल्लंघन नहीं करता है और एथेरियम की स्थिति का प्रस्तावित अपडेट सही है। इसी तरह, जब नोड को ब्लॉक निर्माता के रूप में चुना जाता है, तो सहमति ग्राहक को नए ब्लॉक में शामिल करने के लिए Geth से लेनदेन के बंडलों का अनुरोध करने और वैश्विक स्थिति को अपडेट करने के लिए उन्हें निष्पादित करने में सक्षम होना चाहिए। यह अंतर-क्लाइंट संचार [इंजन API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) का उपयोग करके एक स्थानीय RPC कनेक्शन द्वारा नियंत्रित किया जाता है। + +## निष्पादन ग्राहक क्या करता है? {#execution-client} + +निष्पादन ग्राहक लेनदेन से निपटने, लेनदेन गपशप, स्थिति प्रबंधन और (एथेरियम वर्चुअल मशीन [EVM](/developers/docs/evm/)) का समर्थन करने के लिए जिम्मेदार है। हालांकि, यह ब्लॉक बिल्डिंग, ब्लॉक गपशप या आम सहमति तर्क को संभालने के लिए जिम्मेदार **नहीं** है। ये सहमति ग्राहक के प्रेषण में हैं। + +निष्पादन ग्राहक निष्पादन पेलोड बनाता है - लेन-देन की सूची, अपडेट की गई स्थिति प्रयास और अन्य निष्पादन-संबंधी डेटा। सहमति ग्राहक में प्रत्येक ब्लॉक में निष्पादन पेलोड शामिल है। निष्पादन ग्राहक नए ब्लॉकों में लेनदेन को फिर से निष्पादित करने के लिए भी जिम्मेदार है ताकि यह सुनिश्चित हो सके कि वे वैध हैं। निष्पादन ग्राहक के एम्बेडेड कंप्यूटर पर लेनदेन निष्पादित किया जाता है, जिसे [एथेरियम वर्चुअल मशीन (EVM)](/developers/docs/evm) के रूप में जाना जाता है। + +निष्पादन ग्राहक [RPC विधियों](/developers/docs/apis/json-rpc) के माध्यम से एथेरियम को एक यूज़र इंटरफेस भी प्रदान करता है जो उपयोगकर्ताओं को एथेरियम ब्लॉकचेन को क्वेरी करने, लेनदेन जमा करने और स्मार्ट अनुबंधों को परिनियोजित करने में सक्षम बनाता है। RPC कॉल को [Web3js](https://docs.web3js.org/), [Web3py](https://web3py.readthedocs.io/en/v5/), जैसी लाइब्रेरी द्वारा या ब्राउज़र वॉलेट जैसे यूज़र-इंटरफ़ेस द्वारा नियंत्रित किया जाना आम बात है। + +संक्षेप में, निष्पादन ग्राहक है: + +- एथेरियम के लिए एक यूज़र प्रवेश द्वार +- एथेरियम वर्चुअल मशीन, एथेरियम की स्थिति और लेनदेन पूल का घर। + +## सहमति क्लाइंट क्या करता है? {#consensus-client} + +सहमति क्लाइंट उन सभी तर्कों से निपटता है जो एक नोड को एथेरियम नेटवर्क के साथ सिंक में रहने में सक्षम बनाता है। इसमें साथियों से ब्लॉक प्राप्त करना और यह सुनिश्चित करने के लिए एक फ़ोर्क विकल्प एल्गोरिथम चलाना शामिल है कि नोड हमेशा सत्यापन के सबसे बड़े संचय (सत्यापनकर्ता प्रभावी शेष राशि द्वारा भारित) के साथ श्रृंखला का अनुसरण करता है। निष्पादन क्लाइंट की तरह, सहमति क्लाइंट का अपना P2P नेटवर्क होता है जिसके माध्यम से वे ब्लॉक और सत्यापन साझा करते हैं। + +सहमति क्लाइंट ब्लॉक को सत्यापित करने या प्रस्तावित करने में भाग नहीं लेता है - यह एक सत्यापनकर्ता द्वारा किया जाता है, एक सहमति क्लाइंट के लिए एक वैकल्पिक ऐड-ऑन। एक सत्यापनकर्ता के बिना सहमति क्लाइंट केवल श्रृंखला के प्रमुख के साथ रहता है, जिससे नोड को सिंक रहने की अनुमति मिलती है। यह एक यूज़र को अपने निष्पादन क्लाइंट का उपयोग करके एथेरियम के साथ लेनदेन करने में सक्षम बनाता है, इस विश्वास के साथ कि वे सही श्रृंखला पर हैं। + +## सत्यापनकर्ता {#validators} + +नोड ऑपरेटर जमा अनुबंध में 32 ETH जमा करके अपने सहमति क्लाइंट के लिए एक सत्यापनकर्ता जोड़ सकते हैं। सत्यापनकर्ता क्लाइंट सहमति क्लाइंट के साथ बंडल में आता है और इसे किसी भी समय नोड में जोड़ा जा सकता है। सत्यापनकर्ता सत्यापन और ब्लॉक प्रस्तावों को संभालता है। वे एक नोड को पुरस्कार अर्जित करने या दंड या स्लैशिंग के माध्यम से ETH खोने में सक्षम बनाते हैं। सत्यापनकर्ता सॉफ़्टवेयर चलाने से एक नोड भी एक नया ब्लॉक प्रस्तावित करने के लिए चुने जाने योग्य हो जाता है। + +[स्टेकिंग के बारे में अधिक जानकारी](/staking/)। + +## नोड तुलना के घटक {#node-comparison} + +| निष्पादन क्लाइंट | सहमति क्लाइंट | सत्यापनकर्ता | +| ----------------------------------------------------------------- | ---------------------------------------------------------------------- | ----------------------------------------------- | +| अपने p2p नेटवर्क पर गपशप लेनदेन | अपने p2p नेटवर्क पर गपशप ब्लॉक और सत्यापन | ब्लॉक का प्रस्ताव करता है | +| लेनदेन निष्पादित/पुनः निष्पादित करता है | फ़ोर्क पसंद एल्गोरिथम चलाता है | पुरस्कार/दंड अर्जित करता है | +| आने वाली स्थिति परिवर्तनों की पुष्टि करता है | श्रृंखला के हेड का ट्रैक रखता है | सत्यापन करता है | +| स्थिति और प्राप्तियों का प्रबंधन करता है | बीकन स्थिति का प्रबंधन करता है (आम सहमति और निष्पादन जानकारी शामिल है) | दांव पर लगाने के लिए 32 ETH की आवश्यकता होती है | +| निष्पादन पेलोड बनाता है | RANDAO में संचित यादृच्छिकता का ट्रैक रखता है | काटा जा सकता है | +| एथेरियम के साथ इंटरैक्ट करने के लिए JSON-RPC API को उजागर करता है | औचित्य और अंतिम रूप देने का ट्रैक रखता है | | + +## अग्रिम पठन {#further-reading} + +- [स्टेक-का-प्रमाण](/developers/docs/consensus-mechanisms/pos) +- [ब्लॉक प्रस्ताव](/developers/docs/consensus-mechanisms/pos/block-proposal) +- [सत्यापनकर्ता पुरस्कार और दंड](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) diff --git a/public/content/translations/hi/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/translations/hi/developers/docs/nodes-and-clients/nodes-as-a-service/index.md new file mode 100644 index 00000000000..220b248bf22 --- /dev/null +++ b/public/content/translations/hi/developers/docs/nodes-and-clients/nodes-as-a-service/index.md @@ -0,0 +1,419 @@ +--- +title: सेवा के रूप में नोड्स +description: नोड सेवाओं, पक्ष-विपक्ष और लोकप्रिय प्रदाताओं में से एक एंट्री लेवल ओवरव्यू। +lang: hi +sidebarDepth: 2 +--- + +## परिचय {#Introduction} + +अपना खुद का [एथेरियम नोड](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) चलाना चुनौतीपूर्ण हो सकता है, खासकर जब शुरुआत करनी हो या तेजी से आगे बढ़ना हो। ऐसी [कई सेवाएँ](#popular-node-services) हैं जो आपके लिए अनुकूलित नोड इन्फ़्रास्ट्रक्चर चलाती हैं, ताकि आप इसके बजाय अपने एप्लिकेशन या उत्पाद को विकसित करने पर ध्यान केंद्रित कर सकें। हम बताएंगे कि नोड सेवाएं कैसे काम करती हैं, उनका उपयोग करने वाले पेशेवरों और विपक्षों के साथ-साथ अगर आप शुरू करने में रुचि रखते हैं, तो प्रदाताओं को सूचीबद्ध करें। + +## आवश्यक शर्तें {#prerequisites} + +अगर आपको पहले से ही समझ नहीं है कि नोड्स और क्लाइंट क्या हैं, तो [नोड्स और क्लाइंट](/developers/docs/nodes-and-clients/) देखें। + +## स्टेकर्स {#stakoooooooooooooors} + +सोलो स्टेकर्स को तीसरे पक्ष के प्रदाताओं पर भरोसा करने के बजाय अपना बुनियादी ढांचा चलाना चाहिए। इसका मतलब है कि एक आम सहमति क्लाइंट के साथ मिलकर एक निष्पादित करने वाला क्लाइंट चलाना। [मर्ज](/roadmap/merge) करने से पहले केवल एक आम सहमति ग्राहक चलाने और निष्पादन डेटा के लिए एक केंद्रीकृत प्रदाता का उपयोग करना संभव था; यह अब संभव नहीं है - एक सिंगल स्टेकर को दोनों क्लाइंट को चलाना चाहिए। हालाँकि, इस प्रक्रिया को आसान बनाने के लिए सेवाएँ उपलब्ध हैं। + +[नोड चलाने के बारे में और पढ़ें](/developers/docs/nodes-and-clients/run-a-node/)। + +इस पेज पर बताई गई सेवाएं गैर-स्टेकिंग नोड्स के लिए हैं। + +## नोड सेवाएं कैसे काम करती हैं? {#how-do-node-services-work} + +नोड सेवा प्रदाता आपके लिए पर्दे के पीछे वितरित नोड क्लाइंट चलाते हैं, इसलिए आपको ऐसा करने की आवश्यकता नहीं है। + +ये सेवाएं आमतौर पर एक API कुंजी प्रदान करती हैं जिसका उपयोग आप ब्लॉकचेन से लिखने और पढ़ने के लिए कर सकते हैं। वे अक्सर मेननेट के अलावा [एथेरियम टेस्टनेट](/developers/docs/networks/#ethereum-testnets) तक पहुंच शामिल करते हैं। + +कुछ सेवाएं आपको अपना स्वयं का खास नोड प्रदान करती हैं जो वे आपके लिए प्रबंधित करते हैं, जबकि अन्य नोड्स में गतिविधि वितरित करने के लिए लोड बैलेंसर्स का उपयोग करते हैं। + +लगभग सभी नोड सेवाओं के साथ एकीकृत करना बेहद आसान है, जिसमें आपके कोड में एक पंक्ति का बदलाव शामिल है, ताकि आप स्वयं होस्ट किए गए नोड को स्वैप कर सकें, या यहां तक कि सेवाओं के बीच स्विच भी कर सकें। + +अक्सर नोड सेवाएं अलग-अलग प्रकार के [नोड क्लाइंट](/developers/docs/nodes-and-clients/#execution-clients) और [प्रकार](/developers/docs/nodes-and-clients/#node-types) चलाएंगी जिससे आप एक API में क्लाइंट विशिष्ट तरीकों के अलावा पूर्ण और संग्रह नोड्स तक पहुंच सकते हैं। + +यह ध्यान रखना महत्वपूर्ण है कि नोड सेवाएं आपकी निजी कुंजी या जानकारी को संग्रहीत नहीं करती हैं और न ही करनी चाहिए। + +## नोड सेवा का उपयोग करने के क्या लाभ हैं? {#benefits-of-using-a-node-service} + +नोड सेवा का उपयोग करने का मुख्य लाभ खुद नोड्स को बनाए रखने और प्रबंधित करने में इंजीनियरिंग समय खर्च नहीं करना है। यह आपको बुनियादी ढांचे के रखरखाव के बारे में चिंता करने के बजाय अपने उत्पाद के निर्माण पर ध्यान केंद्रित करने की अनुमति देता है। + +अपने खुद के नोड्स चलाना भंडारण से बैंडविड्थ से मूल्यवान इंजीनियरिंग समय तक बहुत महंगा हो सकता है। स्केलिंग करते समय अधिक नोड्स को स्पिन करना, नोड्स को नए वर्जन में अपग्रेड करना और स्थिति की स्थिरता सुनिश्चित करना, आपके वांछित web3 उत्पाद पर संसाधनों के निर्माण और खर्च करने से विचलित कर सकता है। + +## नोड सेवा का उपयोग करने के विपक्ष क्या हैं? {#cons-of-using-a-node-service} + +नोड सेवा का उपयोग करके आप अपने उत्पाद के बुनियादी ढांचे के पहलू को केंद्रीकृत कर रहे हैं। इस कारण से, विकेंद्रीकरण को सबसे अधिक महत्व देने वाली परियोजनाएं किसी तीसरे पक्ष को आउटसोर्सिंग के बजाय खुद होस्ट करने वाले नोड्स पसंद कर सकती हैं। + +[अपना खुद का नोड चलाने के लाभों](/developers/docs/nodes-and-clients/#benefits-to-you) के बारे में और पढ़ें। + +## लोकप्रिय नोड सेवाएं {#popular-node-services} + +यहाँ कुछ सबसे लोकप्रिय एथेरियम नोड प्रदाताओं की सूची दी गई है, जो भी गायब हैं उन्हें जोड़ने के लिए स्वतंत्र महसूस करें! प्रत्येक नोड सेवा मुफ्त या सशुल्क स्तरों के अलावा विभिन्न लाभ और सुविधाएँ प्रदान करती है, आपको निर्णय लेने से पहले यह जांचना चाहिए कि आपकी आवश्यकताओं के लिए कौन सा सबसे उपयुक्त है। + +- [**एल्केमी**](https://alchemy.com/) + - [डॉक्स](https://docs.alchemyapi.io/) + - विशेषताएँ + - प्रति माह 300M कंप्यूट इकाइयों के साथ सबसे बड़ा फ़्री टियर (~30M getLatestBlock अनुरोध) + - Polygon, Starknet, Optimism, Arbitrum के लिए मल्टीचैन सपोर्ट + - सबसे बड़े एथेरियम dapps और DeFi लेनदेन की मात्रा का ~70% पॉवरिंग + - Alchemy अलर्ट के माध्यम से रीयल-टाइम वेबहुक अलर्ट + - शानदार-इन-क्लास सपोर्ट और विश्वसनीयता / स्थिरता + - Alchemy का NFT API + - रिक्वेस्ट एक्सप्लोरर, Mempool वॉचर और कम्पोज़र के साथ डैशबोर्ड + - इंटिग्रेटेड टेस्टनेट फोसेट तक पहुंच + - 18k यूज़र के साथ सक्रिय Discord बिल्डर समुदाय + +- [**वह सब नोड**](https://allthatnode.com/) + - [डॉक्स](https://docs.allthatnode.com/) + - विशेषताएँ + - फ़्री टियर के साथ प्रति दिन 50,000 अनुरोध + - 40 से अधिक प्रोटोकॉल के लिए सपोर्ट + - JSON-RPC (EVM, Tendermint), REST और Websocket API सपोर्ट करते हैं + - संग्रह की तारीख तक असीमित पहुंच + - 24/7 तकनीकी सहायता और अपटाइम पर 99.9% + - मल्टी चेन पर उपलब्ध फोसेट + - API कुंजियों की असीमित संख्या के साथ असीमित समापन बिंदु पहुंच + - ट्रेस/डीबग API सपोर्ट करता है + - स्वचालित अपडेट + +- [**Amazon प्रबंधित ब्लॉकचेन**](https://aws.amazon.com/managed-blockchain/) + - [डॉक्स](https://aws.amazon.com/managed-blockchain/resources/) + - विशेषताएँ + - पूरी तरह से प्रबंधित एथेरियम नोड्स + - छह क्षेत्रों में उपलब्ध है + - JSON-RPC HTTP और सुरक्षित WebSockets पर + - 3 चेन का सपोर्ट करता है + - SLA, AWS सपोर्ट 24/7 + - गो-एथेरियम और लाइटहाउस + +- [**Ankr**](https://www.ankr.com/) + - [डॉक्स](https://docs.ankr.com/) + - विशेषताएँ + - Ankr प्रोटोकॉल - 8+ सीरीज़ के लिए सार्वजनिक RPC API समापन बिंदुओं तक खुली पहुंच + - निकटतम उपलब्ध नोड के लिए तेज़ और विश्वसनीय प्रवेश द्वार के लिए लोड बैलेंसिंग और नोड हेल्थ मॉनिटरिंग + - प्रीमियम स्तरीय WSS समापन बिंदु और अनकैप्ड दर सीमा को सक्षम करना + - 40+ सीरीज़ के लिए एक-क्लिक पूर्ण नोड और सत्यापनकर्ता नोड परिनियोजन + - चलते-फ़िरते बढ़ाते रहें + - विश्लेषिकी संबंधी उपकरण + - डैशबोर्ड + - RPC, HTTPS और WSS समापन बिंदु + - प्रत्यक्ष सपोर्ट + +- [**ब्लास्ट**](https://blastapi.io/) + - [डॉक्स](https://docs.blastapi.io/) + - विशेषताएँ + - RPC और WSS सपोर्ट + - बहु-क्षेत्रीय नोड होस्टिंग + - विकेंद्रीकृत बुनियादी ढांचा + - सार्वजनिक API + - समर्पित निःशुल्क योजना + - मल्टीचैन सपोर्ट (17+ ब्लॉकचेन) + - आर्काइव नोड्स + - 24/7 Discord सपोर्ट + - 24/7 निगरानी और अलर्ट + - 99.9% का समग्र SLA + - क्रिप्टो में भुगतान करें + +- [**BlockDaemon**](https://blockdaemon.com/) + - [डॉक्स](https://ubiquity.docs.blockdaemon.com/) + - फ़ायदे + - डैशबोर्ड + - प्रति नोड आधार + - विश्लेषिकी + +- [**BlockPI**](https://blockpi.io/) + - [डॉक्स](https://docs.blockpi.io/) + - विशेषताएँ + - मजबूत &; वितरित नोड संरचना + - 40 HTTPS और WSS समापन बिंदु तक + - फ़्री साइनअप पैकेज और मासिक पैकेज + - ट्रेस करने का तरीका + आर्काइव डेटा सपोर्ट + - 90 दिनों तक के पैकेज की वैधता + - कस्टम योजना और भुगतान के रूप में आप भुगतान करते हैं + - क्रिप्टो में भुगतान करें + - प्रत्यक्ष सपोर्ट और तकनीकी सहायता + +- [**चेनबेस**](https://www.chainbase.com/) + - [डॉक्स](https://docs.chainbase.com) + - विशेषताएँ + - हर समय उपलब्ध, तेज और स्केलेबल RPC सेवा + - मल्टी-चेन सपोर्ट + - फ़्री टैरिफ़ + - यूज़र के अनुकूल डैशबोर्ड + - RPC से परे ब्लॉकचेन डेटा सेवाएं प्रदान करता है + +- [**चेनस्टैक**](https://chainstack.com/) + - [डॉक्स](https://docs.chainstack.com/) + - विशेषताएँ + - मुक्त साझा नोड्स + - साझा संग्रह नोड्स + - GraphQL सपोर्ट + - RPC और WSS समापन बिंदु + - समर्पित पूर्ण और संग्रह नोड्स + - समर्पित परिनियोजन के लिए तेज़ सिंक समय + - अपना क्लाउड लाएँ + - भुगतान-प्रति-घंटे मूल्य निर्धारण + - प्रत्यक्ष 24/7 सपोर्ट + +- [**डेटाहब**](https://datahub.figment.io) + - [डॉक्स](https://docs.figment.io/) + - विशेषताएँ + - 3,000,000 अनुरोध/माह के साथ फ़्री टियर विकल्प + - RPC और WSS समापन बिंदु + - समर्पित पूर्ण और संग्रह नोड्स + - ऑटो-स्केलिंग (वॉल्यूम छूट) + - फ़्री आर्काइवल डेटा + - सेवा विश्लेषिकी + - डैशबोर्ड + - प्रत्यक्ष 24/7 सपोर्ट + - क्रिप्टो में भुगतान करें (एंटरप्राइज़) + +- [**DRPC**](https://drpc.org/) + - [डॉक्स](https://docs.drpc.org/) + - विशेषताएँ + - विकेंद्रीकृत RPC नोड्स + - 15+ नोड प्रदाता + - नोड बैलेंसिंग + - फ़्री टियर पर प्रति माह असीमित गणना वाली इकाइयां + - डेटा वेरिफ़िकेशन + - कस्टम समापन बिंदु + - HTTP और WSS समापन बिंदु + - असीमित कुंजी (निःशुल्क और सशुल्क टियर) + - लचीले फ़ॉलबैक संबंधी विकल्प + - [सार्वजनिक समापन बिंदु](https://eth.drpc.org) + - फ़्री साझा संग्रह वाले नोड्स + +- [**GetBlock**](https://getblock.io/) + - [डॉक्स](https://getblock.io/docs/get-started/authentication-with-api-key/) + - विशेषताएँ + - 40+ ब्लॉकचेन नोड्स तक पहुंच + - 40K निःशुल्क दैनिक अनुरोध + - API कुंजियों की असीमित संख्या + - 1GB/sec पर उच्च कनेक्शन गति + - ट्रेस+आर्काइव + - उन्नत विश्लेषण + - स्वचालित अपडेट + - तकनीकी सहायता + +- [**InfStones**](https://infstones.com/) + - विशेषताएँ + - फ़्री टियर विकल्प + - चलते-फ़िरते बढ़ाते रहें + - विश्लेषिकी + - डैशबोर्ड + - अद्वितीय API समापन बिंदु + - समर्पित फुल नोड्स + - समर्पित परिनियोजन के लिए तेज़ सिंक समय + - प्रत्यक्ष 24/7 सपोर्ट + - 50+ ब्लॉकचेन नोड्स तक पहुंच + +- [**Infura**](https://infura.io/) + - [डॉक्स](https://infura.io/docs) + - विशेषताएँ + - फ़्री टियर विकल्प + - चलते-फ़िरते बढ़ाते रहें + - भुगतान किया गया आर्काइवल डेटा + - प्रत्यक्ष सपोर्ट + - डैशबोर्ड + +- [**Kaleido**](https://kaleido.io/) + - [डॉक्स](https://docs.kaleido.io/) + - विशेषताएँ + - फ़्री स्टार्टियर टियर + - वन-क्लिक एथेरियम नोड डिप्लॉयमेंट + - अनुकूलन योग्य क्लाइंट और एल्गोरिदम (Geth, Quorum और Besu || PoA, IBFT और बेड़ा) + - 500+ प्रशासनिक और सेवा API + - एथेरियम लेनदेन प्रस्तुत करने के लिए RESTful इंटरफ़ेस (Apache Kafka सपोर्ट करता है) + - घटना वितरण के लिए आउटबाउंड स्ट्रीम (Apache Kafka सपोर्ट करता है) + - "ऑफ-चेन" और सहायक सेवाओं का गहरा संग्रह (जैसे बाइलेट्रल एन्क्रिप्टेड मैसेजिंग ट्रांसपोर्ट) + - शासन और भूमिका-आधारित अभिगम नियंत्रण के साथ सीधा नेटवर्क ऑनबोर्डिंग + - व्यवस्थापकों और अंतिम यूज़र, दोनों के लिए शानदार उपयोगकर्ता प्रबंधन + - बहुत ज़्यादा बढ़ाया जा सकने वाला, लचीला, एंटरप्राइज़-ग्रेड बुनियादी ढांचा + - क्लाउड HSM निजी कुंजी प्रबंधन + - एथेरियम मेननेट टेदरिंग + - ISO 27k और SOC 2, टाइप 2 प्रमाणपत्र + - डायनामिक रनटाइम कॉन्फ़िगरेशन (जैसे क्लाउड इंटीग्रेशन जोड़ना, नोड प्रवेश को बदलना आदि।) + - मल्टी-क्लाउड, मल्टी-रीजन और हाइब्रिड डिप्लॉयमेंट ऑर्केस्ट्रेशन के लिए सपोर्ट + - सरल प्रति घंटा SaaS-आधारित मूल्य निर्धारण + - SLA और 24x7 सपोर्ट + +- [**Lava नेटवर्क**](https://www.lavanet.xyz/) + - [डॉक्स](https://docs.lavanet.xyz/) + - विशेषताएँ + - निःशुल्क टेस्टनेट का उपयोग + - उच्च अपटाइम के लिए डिसेंट्रलाइज़्ड रिडंडेंसी + - ओपन-सोर्स + - पूरी तरह से विकेंद्रीकृत SDK + - Ethers.js इंटीग्रेशन + - सहज परियोजना प्रबंधन इंटरफ़ेस + - सहमति-आधारित डेटा इंटीग्रेटी + - मल्टी-चेन सपोर्ट + +- [**Moralis**](https://moralis.io/) + - [डॉक्स](https://docs.moralis.io/) + - विशेषताएँ + - मुक्त साझा नोड्स + - फ़्री साझा संग्रह वाले नोड्स + - गोपनीयता केंद्रित (कोई लॉग नीति नहीं) + - क्रॉस चेन सपोर्ट + - चलते-फ़िरते बढ़ाते रहें + - डैशबोर्ड + - अद्वितीय एथेरियम SDK + - अद्वितीय API समापन बिंदु + - प्रत्यक्ष, तकनीकी सहायता + +- [**NodeReal MegaNode**](https://nodereal.io/) + - [डॉक्स](https://docs.nodereal.io/nodereal/meganode/introduction) + - विशेषताएँ + - विश्वसनीय, तेज और स्केलेबल RPC API सेवाएं + - web3 डेवलपर के लिए उन्नत API + - मल्टी-चेन सपोर्ट + - मुफ़्त में शुरू करें + +- [**NOWNodes**](https://nownodes.io/) + - [डॉक्स](https://documenter.getpostman.com/view/13630829/TVmFkLwy) + - विशेषताएँ + - 50+ ब्लॉकचेन नोड्स तक पहुंच + - फ़्री API कुंजी + - ब्लॉक खोजकर्ता + - API प्रतिक्रिया समय ⩽ 1 सेकंड + - 24/7 सपोर्ट टीम + - व्यक्तिगत खाता प्रबंधक + - साझा, आर्काइव, बैकअप और समर्पित नोड्स + +- [**पॉकेट नेटवर्क**](https://www.pokt.network/) + - [डॉक्स](https://docs.pokt.network/home/) + - विशेषताएँ + - विकेंद्रीकृत RPC प्रोटोकॉल और बाज़ार + - 1M अनुरोध प्रति दिन फ़्री टियर (प्रति समापन बिंदु, अधिकतम 2) + - [सार्वजनिक समापन बिंदु](https://docs.pokt.network/developers/public-endpoints) + - प्री-स्टेक+ प्रोग्राम (अगर आपको प्रति दिन 1M से अधिक अनुरोधों की आवश्यकता है) + - 15+ ब्लॉकचेन सपोर्ट करता है + - 6400+ नोड्स एप्लिकेशन की सेवा के लिए POKT कमा रहे हैं + - आर्काइवल नोड, ट्रेसिंग के साथ आर्काइवल नोड्स और टेस्टनेट नोड सपोर्ट + - एथेरियम मेननेट नोड क्लाइंट विविधता + - विफलता का कोई एक बिंदु नहीं + - शून्य डाउनटाइम + - लागत प्रभावी निकट-शून्य टोकनोमिक्स (नेटवर्क बैंडविड्थ के लिए POKT को एक बार स्टेक करें) + - कोई मासिक डूब लागत नहीं, अपने बुनियादी ढांचे को एक संपत्ति में बदल दें + - प्रोटोकॉल में निर्मित लोड-बैलेंसिंग + - जाते ही प्रति दिन अनुरोधों की संख्या और प्रति घंटे नोड्स को बिना किसी सीमा के बढ़ाएँ + - सबसे निजी, सेंसरशिप-प्रतिरोध संबंधी विकल्प + - हैंड्स-ऑन डेवलपर सपोर्ट + - [पॉकेट पोर्टल](https://bit.ly/ETHorg_POKTportal) डैशबोर्ड और एनालिटिक्स + +- [**QuickNode**](https://www.quicknode.com) + - [डॉक्स](https://www.quicknode.com/docs/) + - विशेषताएँ + - 24/7 तकनीकी सहायता और डेवलपर Discord समुदाय + - भू-संतुलित, मल्टी क्लाउड/मेटल, लो-लेटेंसी नेटवर्क + - मल्टीचैन सपोर्ट (Optimism, Arbitrum, Polygon + 11 अन्य) + - गति& और स्थिरता के लिए मध्य-परतें (कॉल रूटिंग, कैश, इंडेक्सिंग) + - वेबहुक के माध्यम से स्मार्ट-अनुबंध निगरानी + - सहज डैशबोर्ड, विश्लेषिकी सूट, RPC कम्पोज़र + - उन्नत सुरक्षा सुविधाएँ (JWT, मास्किंग, श्वेतसूची) + - NFT डेटा और एनालिटिक्स API + - [SOC2 प्रमाणित](https://www.quicknode.com/security) + - डेवलपर से एंटरप्राइज़ के लिए उपयुक्त + +- [**Rivet**](https://rivet.cloud/) + - [डॉक्स](https://rivet.readthedocs.io/en/latest/) + - विशेषताएँ + - फ़्री टियर विकल्प + - चलते-फ़िरते बढ़ाते रहें + +- [**SenseiNode**](https://senseinode.com) + - [डॉक्स](https://docs.senseinode.com/) + - विशेषताएँ + - समर्पित और साझा नोड्स + - डैशबोर्ड + - लैटिन अमेरिका में विभिन्न स्थानों पर कई होस्टिंग प्रदाताओं पर AWS को होस्ट करना + - प्रिज़्म और लाइटहाउस क्लाइंट + +- [**SettleMint**](https://console.settlemint.com/) + - [डॉक्स](https://docs.settlemint.com/) + - विशेषताएँ + - फ़्री ट्रायल + - चलते-फ़िरते बढ़ाते रहें + - GraphQL सपोर्ट + - RPC और WSS समापन बिंदु + - समर्पित फुल नोड्स + - अपना क्लाउड लाएँ + - विश्लेषिकी संबंधी उपकरण + - डैशबोर्ड + - भुगतान-प्रति-घंटे मूल्य निर्धारण + - प्रत्यक्ष सपोर्ट + +- [**Tenderly**](https://tenderly.co/web3-gateway) + - [डॉक्स](https://docs.tenderly.co/web3-gateway/web3-gateway) + - विशेषताएँ + - प्रति माह 25 मिलियन Tenderly यूनिट सहित फ़्री टियर + - पुराने डेटा तक निःशुल्क पहुंच + - 8x तक तेजी से रीड-हैवी वर्कलोड + - 100% लगातार रीड एक्सेस + - JSON-RPC समापन बिंदु + - UI-आधारित RPC अनुरोध बिल्डर और अनुरोध पूर्वावलोकन + - Tenderly के विकास, डिबगिंग और परीक्षण उपकरणों के साथ पूरी तरह इंटीग्रेटेड + - लेनदेन सिमुलेशन + - उपयोग विश्लेषण और फ़िल्टरिंग + - आसान पहुँच कुंजी प्रबंधन + - चैट, ईमेल और Discord के माध्यम से समर्पित इंजीनियरिंग सपोर्ट + +- [**Tokenview**](https://services.tokenview.io/) + - [डॉक्स](https://services.tokenview.io/docs?type=nodeService) + - विशेषताएँ + - 24/7 तकनीकी सहायता और डेवलपर Telegram समुदाय + - मल्टीचैन सपोर्ट (बिटकॉइन, एथेरियम, ट्रॉन, बीएनबी स्मार्ट चेन, एथेरियम क्लासिक) + - RPC और WSS समापन बिंदु दोनों उपयोग के लिए खुले हैं + - संग्रह डेटा API तक असीमित पहुंच + - अनुरोध एक्सप्लोरर और Mempool वॉचर के साथ डैशबोर्ड + - NFT डेटा API और वेबहुक अलर्ट + - क्रिप्टो में भुगतान करें + - अतिरिक्त व्यवहार संबंधी आवश्यकताओं के लिए बाहरी सपोर्ट + +- [**Watchdata**](https://watchdata.io/) + - [डॉक्स](https://docs.watchdata.io/) + - विशेषताएँ + - डेटा विश्वसनीयता + - बिना किसी डाउनटाइम के निर्बाध कनेक्शन + - प्रक्रिया स्वचालन + - फ़्री टैरिफ़ + - उच्च सीमाएं जो किसी भी यूज़र के अनुरूप हैं + - विभिन्न नोड्स के लिए सपोर्ट + - संसाधन स्केलिंग + - उच्च प्रसंस्करण गति + +- [**ZMOK**](https://zmok.io/) + - [डॉक्स](https://docs.zmok.io/) + - विशेषताएँ + - एक सेवा के रूप में फ्रंट-रनिंग + - खोज/फ़िल्टरिंग विधियों के साथ वैश्विक लेनदेन मेमपूल + - असीमित TX शुल्क और लेनदेन भेजने के लिए अनंत गैस + - नए ब्लॉक का सबसे तेज़ होना और ब्लॉकचेन पढ़ना + - API कॉल गारंटी के लिए सबसे अच्छी कीमत + +- [**Zeeve**](https://www.zeeve.io/) + - [डॉक्स](https://www.zeeve.io/docs/) + - विशेषताएँ + - एंटरप्राइज़-ग्रेड नो-कोड ऑटोमेशन प्लेटफ़ॉर्म ब्लॉकचेन नोड्स और नेटवर्क की तैनाती, निगरानी और प्रबंधन प्रदान करता है + - 30+ समर्थित प्रोटोकॉल और एकीकरण और अधिक जोड़ना + - वास्तविक दुनिया के उपयोग के मामलों के लिए विकेंद्रीकृत भंडारण, विकेंद्रीकृत पहचान और ब्लॉकचेन लेज़र डेटा API जैसी मूल्य वर्धित web3 अवसंरचना सेवाएं + - 24/7 सपोर्ट और सक्रिय निगरानी हर समय नोड्स के स्वास्थ्य को सुनिश्चित करती है। + - RPC एंडपॉइंट API तक प्रमाणित पहुंच, सहज डैशबोर्ड और एनालिटिक्स के साथ परेशानी मुक्त प्रबंधन प्रदान करते हैं। + - दोनों प्रबंधित क्लाउड प्रदान करता है और चुनने के लिए अपने खुद के क्लाउड विकल्प लाता है और AWS, Azure, Google Cloud, Digital Ocean और on-premise जैसे सभी प्रमुख क्लाउड प्रदाताओं का सपोर्ट करता है। + - हम हर बार आपके यूज़र के निकटतम नोड को हिट करने के लिए बुद्धिमान रूटिंग का उपयोग करते हैं + + +## अग्रिम पठन {#further-reading} + +- [एथेरियम नोड सेवाओं की सूची](https://ethereumnodes.com/) + +## संबंधित विषय {#related-topics} + +- [ नोड्स और क्लाइंट](/developers/docs/nodes-and-clients/) + +## संबंधित ट्यूटोरियल {#related-tutorials} + +- [Alchemy का उपयोग करके एथेरियम विकास के साथ शुरुआत करना](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/) +- [वेब3 और Alchemy का उपयोग करके लेनदेन भेजने के लिए गाइड](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) diff --git a/public/content/translations/hi/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/translations/hi/developers/docs/nodes-and-clients/run-a-node/index.md new file mode 100644 index 00000000000..efadb7cf1a2 --- /dev/null +++ b/public/content/translations/hi/developers/docs/nodes-and-clients/run-a-node/index.md @@ -0,0 +1,480 @@ +--- +title: अपना खुद का एथेरियम नोड सेटअप करें +description: एथेरियम क्लाइंट का अपना इंस्टेंस चलाने का सामान्य परिचय। +lang: hi +sidebarDepth: 2 +--- + +अपना एथेरियम नोड चलाना आपको विभिन्न लाभ प्रदान करता है, नई संभावनाएँ खोलता है, और इकोसिस्टम का सपोर्ट करता है। इस पेज पर आपको अपना नोड सेटअप करने और एथेरियम लेन-देन को मान्य करने में भाग लेने की प्रक्रिया के बारे में मार्गदर्शन मिलेगा। + +ध्यान दें कि [मर्ज](/roadmap/merge) के बाद, एथेरियम नोड रन करने के लिए दो क्लाइंट्स की आवश्यकता होती है; एक **एक्जीक्यूशन लेयर (EL)** क्लाइंट और एक **कंसेंसस लेयर (CL)** क्लाइंट। यह पेज दिखाएगा कि कैसे इन दोनों क्लाइंट्स को इंस्टॉल, कॉन्फ़िगर और कनेक्ट करें, ताकि आप एक एथेरियम नोड चला सकें। + +## आवश्यक शर्तें {#prerequisites} + +आपको यह समझना चाहिए कि एथेरियम नोड क्या है और आप एक क्लाइंट चलाने की आवश्यकता क्यों महसूस कर सकते हैं। यह [नोड्स और क्लाइंट्स](/developers/docs/nodes-and-clients/) में कवर किया गया है। + +अगर आप नोड चलाने के विषय में नए हैं या एक कम तकनीकी मार्ग ढूंढ रहे हैं, तो हम पहले हमारी यूज़र-अनुकूल परिचय [एथेरियम नोड चलाने](/run-a-node) पर देखने की सलाह देते हैं। + +## एक दृष्टिकोण चुनना {#choosing-approach} + +अपने नोड को सेटअप करने का पहला कदम आपके दृष्टिकोण का चयन करना है। आवश्यकताओं और विभिन्न संभावनाओं के आधार पर, आपको क्लाइंट इंप्लीमेंटेशन (दोनों एक्ज़ीक्यूशन और कंसेंसस क्लाइंट्स), वातावरण (हार्डवेयर, सिस्टम), और क्लाइंट सेटिंग्स के लिए पैरामीटर्स का चयन करना होगा। + +यह पेज आपको इन निर्णयों के माध्यम से मार्गदर्शन करेगा और आपकी एथेरियम इंस्टेंस को चलाने के लिए सबसे उपयुक्त तरीका खोजने में मदद करेगा। + +क्लाइंट इंप्लीमेंटेशन चुनने के लिए, उपलब्ध मेननेट-तैयार [एक्ज़ीक्यूशन क्लाइंट्स](/developers/docs/nodes-and-clients/#execution-clients), [कंसेंसस क्लाइंट्स](/developers/docs/nodes-and-clients/#consensus-clients) देखें और [क्लाइंट की विविधता](/developers/docs/nodes-and-clients/client-diversity) के बारे में जानें। + +ग्राहकों की [आवश्यकताओं](#requirements) को ध्यान में रखते हुए, सॉफ़्टवेयर को अपने [हार्डवेयर पर या क्लाउड में](#local-vs-cloud) चलाने का निर्णय लें। + +पर्यावरण तैयार करने के बाद, चुने हुए क्लाइंट्स को या तो [शुरुआत करने वाले के अनुकूल इंटरफ़ेस](#automatized-setup) के साथ इंस्टॉल करें या [टर्मिनल](#manual-setup) का उपयोग करके उन्नत विकल्पों के साथ मैन्युअल रूप से इंस्टॉल करें। + +जब नोड चल रहा हो और सिंक हो रहा हो, तो आप इसे [उपयोग](#using-the-node) करने के लिए तैयार हैं, लेकिन इसके [देखभाल](#operating-the-node) पर नज़र रखना सुनिश्चित करें। + +![क्लाइंट सेटअप](./diagram.png) + +### पर्यावरण और हार्डवेयर {#environment-and-hardware} + +#### स्थानीय या क्लाउड {#local-vs-cloud} + +एथेरियम क्लाइंट्स उपभोक्ता ग्रेड कंप्यूटर पर चल सकते हैं और इन्हें किसी विशेष हार्डवेयर, जैसे कि माईनिंग मशीन की आवश्यकता नहीं होती। इसलिए, आपकी ज़रूरतों के आधार पर नोड को डिप्लॉय करने के लिए आपके पास विभिन्न विकल्प हैं। साधारण तरीके से सोचें, तो नोड को एक स्थानीय भौतिक मशीन और एक क्लाउड सर्वर दोनों पर चलाने के बारे में विचार करें: + +- क्लाउड + - प्रोवाइडर्स उच्च सर्वर अपटाइम और स्थिर सार्वजनिक IP पते प्रदान करते हैं + - खास तौर पर काम करने वाले या वर्चुअल सर्वर प्राप्त करना अपने खुद के सर्वर बनाने की तुलना में अधिक सुविधाजनक हो सकता है + - इसका व्यापारिक समझौता तीसरे पक्ष - सर्वर प्रोवाइडर पर भरोसा करने का होता है + - फ़ुल नोड के लिए आवश्यक स्टोरेज आकार के कारण, किराए पर लिए गए सर्वर की कीमत अधिक हो सकती है +- अपना खुद का हार्डवेयर + - अधिक विश्वासहीन और स्वायत्त दृष्टिकोण + - एक बार का निवेश + - पहले से कॉन्फ़िगर की गई मशीनें खरीदने का विकल्प + - आपको मशीन और नेटवर्किंग को भौतिक रूप से तैयार, बनाए रखना और संभावित रूप से समस्या निवारण करना होगा + +दोनों विकल्पों के विभिन्न लाभ हैं, जो ऊपर संक्षेप में बताए गए हैं। अगर आप एक क्लाउड समाधान की तलाश में हैं, तो पारंपरिक क्लाउड कंप्यूटिंग प्रोवाइडर्स के अलावा, नोड्स को डिप्लॉय करने पर केंद्रित सेवाएँ भी उपलब्ध हैं। [सर्विस के तौर पर नोड्स](/developers/docs/nodes-and-clients/nodes-as-a-service/) पर अधिक विकल्पों के लिए देखें जो होस्टेड नोड्स प्रदान करते हैं। + +#### हार्डवेयर {#hardware} + +हालांकि, सेंसरशिप-रेजिस्टेंट और विकेन्द्रीकृत नेटवर्क को क्लाउड प्रोवाइडर्स पर निर्भर नहीं होना चाहिए। इसके बजाय, अपने नोड को अपने स्वयं के स्थानीय हार्डवेयर पर चलाना इकोसिस्टम के लिए स्वस्थ है। [अनुमान](https://www.ethernodes.org/networkType/Hosting) दर्शाते हैं कि नोड्स का एक बड़ा हिस्सा क्लाउड पर चलता है, जो एकल विफलता बिंदु बन सकता है। + +एथेरियम क्लाइंट्स आपके कंप्यूटर, लैपटॉप, सर्वर, या यहां तक कि एक सिंगल-बोर्ड कंप्यूटर पर चल सकते हैं। हालांकि पर्सनल कंप्यूटर पर क्लाइंट्स चलाना संभव है, एक विशेष मशीन का होना आपके नोड की परफ़ॉर्मेंस और सुरक्षा को काफी हद तक बढ़ा सकता है, जबकि आपके मुख्य कंप्यूटर पर प्रभाव को कम करता है। + +अपने खुद के हार्डवेयर का उपयोग करना बहुत आसान हो सकता है। यहां बहुत सारे सरल विकल्प और अधिक तकनीकी लोगों के लिए उन्नत सेटअप भी हैं। तो आइए, हम आपके मशीन पर एथेरियम क्लाइंट्स चलाने के लिए आवश्यकताओं और साधनों पर नज़र डालें। + +#### आवश्यकताएँ {#requirements} + +क्लाइंट के अनुसार हार्डवेयर की आवश्यकताएँ भिन्न होती हैं, लेकिन सामान्य तौर पर ये इतनी अधिक नहीं होतीं क्योंकि नोड को बस सिंक रहना होता है। इसे माईनिंग से भ्रमित न करें, जिसमें बहुत अधिक कंप्यूटिंग पावर की आवश्यकता होती है। हालांकि, सिंक टाइम और प्रदर्शन अधिक शक्तिशाली हार्डवेयर के साथ बेहतर होते हैं। + +किसी भी क्लाइंट को इंस्टॉल करने से पहले, कृपया सुनिश्चित करें कि आपके कंप्यूटर में इसे चलाने के लिए ज़रूरी संसाधन हों। न्यूनतम और सुझाई गई आवश्यकताओं को नीचे पाया जा सकता है। + +आपके हार्डवेयर की मुख्य रुकावट आमतौर पर डिस्क स्पेस होती है। एथेरियम ब्लॉकचेन को सिंक करना बहुत अधिक इनपुट/आउटपुट इंटेंसिव होता है और इसके लिए बहुत अधिक स्पेस की आवश्यकता होती है। सिंक्रनाइज़ेशन के बाद भी फ़्री स्पेस के साथ सैकडों GB वाला **सॉलिड-स्टेट ड्राइव (SSD)** होना सबसे अच्छा है। + +डेटाबेस का साइज़ और शुरुआती सिंक्रनाइज़ेशन की गति चुने गए क्लाइंट, इसकी कॉन्फ़िगरेशन और [सिंक रणनीति](/developers/docs/nodes-and-clients/#sync-modes) पर निर्भर करती है। + +सुनिश्चित करें कि आपका इंटरनेट कनेक्शन [बैंडविड्थ कैप](https://wikipedia.org/wiki/Data_cap) द्वारा सीमित न हो। शुरुआती सिंक और नेटवर्क पर प्रसारित डेटा आपके लिमिट को पार कर सकते हैं, इसलिए मीटर्ड कनेक्शन का उपयोग करने का सुझाव दिया जाता है। + +##### ऑपरेटिंग सिस्टम + +सभी क्लाइंट्स प्रमुख ऑपरेटिंग सिस्टम - Linux, MacOS, Windows का सपोर्ट करते हैं। इसका मतलब है कि आप नोड्स को नियमित डेस्कटॉप या सर्वर मशीनों पर उस ऑपरेटिंग सिस्टम (OS) के साथ चला सकते हैं जो आपके लिए सबसे उपयुक्त हो। संभावित समस्याओं और सुरक्षा कमजोरियों से बचने के लिए सुनिश्चित करें कि आपका OS अपडेटेड है। + +##### न्यूनतम आवश्यकताएँ + +- 2+ कोर वाला CPU +- 8 GB RAM +- 2TB SSD +- 10+ MBit/s बैंडविड्थ + +##### सुझाया गया स्पेसिफिकेशन + +- 4+ कोर वाला तेज़ CPU +- 16 GB+ RAM +- 2+TB वाले तेज़ SSD +- 25+ MBit/s बैंडविड्थ + +आपके द्वारा चुने गए सिंक मोड और क्लाइंट स्पेस की आवश्यकताओं को प्रभावित करेंगे, लेकिन हमने नीचे प्रत्येक क्लाइंट के लिए आवश्यक डिस्क स्पेस का अनुमान लगाया है। + +| क्लाइंट | डिस्क आकार (स्नैप सिंक) | डिस्क आकार (फ़ुल आर्काइव) | +| --------- | ----------------------- | ------------------------- | +| बेसु | 800GB+ | 12TB+ | +| एरिगोन | लागू नहीं | 2.5TB+ | +| गेथ | 500GB+ | 12TB+ | +| नेदरमाइंड | 500GB+ | 12TB+ | +| रेथ | लागू नहीं | 2.2TB+ | + +- नोट: Erigon और Reth स्नैप सिंक की पेशकश नहीं करते, लेकिन फ़ुल प्रूनिंग संभव है (Erigon के लिए ~2TB, Reth के लिए ~1.2TB)। + +सहमति क्लाइंट्स के लिए, स्पेस की आवश्यकता क्लाइंट की कार्यान्वयन और सक्षम सुविधाओं (जैसे, वैलिडेटर स्लैशर) पर भी निर्भर करती है, लेकिन सामान्य रूप से, बीकन डेटा के लिए अतिरिक्त 200GB की आवश्यकता होती है। वैलिडेटर्स की बड़ी संख्या के साथ, बैंडविड्थ लोड भी बढ़ जाता है। [सहमति ग्राहक की आवश्यकताओं पर विवरण](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc) आप इस विश्लेषण में पा सकते हैं। + +#### प्लग-एंड-प्ले समाधान {#plug-and-play} + +अपने खुद के हार्डवेयर के साथ नोड चलाने के लिए सबसे आसान विकल्प प्लग-एंड-प्ले बॉक्स का उपयोग करना है। विक्रेताओं से पहले से कॉन्फ़िगर की गई मशीनें सबसे सीधी अनुभव प्रदान करती हैं: ऑर्डर करें, कनेक्ट करें, चलाएं। सब कुछ पहले से कॉन्फ़िगर किया गया है और एक सहज गाइड और सॉफ़्टवेयर की निगरानी और नियंत्रण के लिए डैशबोर्ड के साथ स्वचालित रूप से चलता है। + +- [DappNode](https://dappnode.io/) +- [Avado](https://ava.do/) + +#### एकल-बोर्ड कंप्यूटर पर एथेरियम {#ethereum-on-a-single-board-computer} + +एथेरियम नोड चलाने का एक आसान और सस्ता तरीका सिंगल-बोर्ड कंप्यूटर का उपयोग करना है, यहां तक कि ARM आर्किटेक्चर वाले जैसे कि रास्पबेरी पाई। [एथेरियम ऑन ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) रास्पबेरी पाई और अन्य ARM बोर्ड के लिए कई एग्जीक्यूशन और कंसेंसस क्लाइंट्स की रन करने योग्य इमेज प्रदान करता है। + +छोटे, किफायती और प्रभावशाली उपकरण जैसे ये घरेलू नोड चलाने के लिए आदर्श होते हैं, लेकिन उनकी सीमित प्रदर्शन को ध्यान में रखना आवश्यक है। + +## नोड स्थापित करना {#spinning-up-node} + +वास्तविक क्लाइंट सेटअप को या तो स्वचालित लॉन्चर्स के साथ या मैन्युअल रूप से, सीधे क्लाइंट सॉफ़्टवेयर को सेटअप करके किया जा सकता है। + +कम अनुभवी यूज़र के लिए, सुझाव दिया जाता है कि आप एक लॉन्चर का उपयोग करें, जो एक सॉफ़्टवेयर हो और आपको स्थापना के माध्यम से मार्गदर्शित करता हो और क्लाइंट सेटअप प्रक्रिया को स्वचालित करता हो। हालांकि, अगर आपके पास टर्मिनल का उपयोग करने का कुछ अनुभव है, तो मैन्युअल सेटअप के चरणों का पालन करना सरल होगा। + +### मार्गदर्शित सेटअप {#automatized-setup} + +कई यूज़र-अनुकूल प्रोजेक्ट्स क्लाइंट सेटअप के अनुभव को बेहतर बनाने का लक्ष्य रखते हैं। ये लॉन्चर्स स्वचालित क्लाइंट स्थापना और कॉन्फ़िगरेशन प्रदान करते हैं, कुछ तो ग्राफ़िकल इंटरफ़ेस भी पेश करते हैं जो मार्गदर्शित सेटअप और क्लाइंट्स की निगरानी के लिए होता है। + +नीचे कुछ प्रोजेक्ट्स दिए गए हैं जो आपको कुछ ही क्लिक में क्लाइंट्स स्थापित करने और नियंत्रित करने में मदद कर सकते हैं: + +- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) - DappNode केवल विक्रेता की मशीन के साथ नहीं आता। सॉफ़्टवेयर, वास्तविक नोड लॉन्चर और कई विशेषताओं के साथ नियंत्रण केंद्र का उपयोग मनमाने हार्डवेयर पर किया जा सकता है। +- [eth-docker](https://eth-docker.net/) - आसान और सुरक्षित स्टेकिंग पर केंद्रित डॉकर का उपयोग करके स्वचालित सेटअप, बुनियादी टर्मिनल और डॉकर ज्ञान की आवश्यकता होती है, जो थोड़ा अधिक उन्नत यूज़र के लिए सुझाया गया है। +- [स्टीरियम](https://stereum.net/ethereum-node-setup/) - एक GUI सेटअप गाइड, नियंत्रण केंद्र और कई अन्य सुविधाओं के साथ SSH कनेक्शन के माध्यम से दूरस्थ सर्वर पर क्लाइंट स्थापित करने के लिए लॉन्चर। +- [NiceNode](https://www.nicenode.xyz/) - अपने कंप्यूटर पर एक नोड चलाने के लिए एक सीधे यूज़र अनुभव के साथ लॉन्चर। बस क्लाइंट चुनें और उन्हें कुछ क्लिक के साथ शुरू करें। अब भी विकास में है। +- [सेज](https://docs.sedge.nethermind.io/docs/intro)-नोड सेटअप उपकरण जो CLI विज़ार्ड का उपयोग करके स्वचालित रूप से एक डॉकर कॉन्फ़िगरेशन जेनरेट करता है। Nethermind द्वारा गो में लिखा गया। + +### मैन्युअल क्लाइंट सेटअप {#manual-setup} + +दूसरा विकल्प है क्लाइंट सॉफ़्टवेयर को मैन्युअल रूप से डाउनलोड, सत्यापित और कॉन्फ़िगर करना। हालांकि कुछ क्लाइंट्स ग्राफ़िकल इंटरफ़ेस प्रदान करते हैं, मैन्युअल सेटअप के लिए अब भी टर्मिनल के साथ बुनियादी कौशल की आवश्यकता होती है, लेकिन यह अलग-अलग तरह का होता है। + +जैसा कि पहले समझाया गया है, अपने खुद के एथेरियम नोड को सेटअप करने के लिए आपको कंसेंसस और एक्जीक्यूशन क्लाइंट्स के एक पेयर को रन करना होगा। कुछ क्लाइंट्स अन्य प्रकार का लाइट क्लाइंट भी शामिल कर सकते हैं और बिना किसी अन्य सॉफ़्टवेयर के सिंक हो सकते हैं। हालांकि, पूर्ण विश्वासहीन सत्यापन के लिए दोनों कार्यान्वयन की आवश्यकता होती है। + +#### क्लाइंट सॉफ़्टवेयर प्राप्त करना {#getting-the-client} + +पहले, आपको अपने पसंदीदा [एक्सीक्यूशन क्लाइंट](/developers/docs/nodes-and-clients/#execution-clients) और [कंसेंसस क्लाइंट](/developers/docs/nodes-and-clients/#consensus-clients) सॉफ़्टवेयर को प्राप्त करना होगा। + +आप बस एक ऐसा निष्पादन योग्य एप्लिकेशन या इंस्टॉलेशन पैकेज डाउनलोड कर सकते हैं जो आपके ऑपरेटिंग सिस्टम और आर्किटेक्चर के लिए उपयुक्त हो। डाउनलोड किए गए पैकेज के डिजिटल हस्ताक्षरों और चेकसम्स की हमेशा जांच करें। कुछ क्लाइंट्स रिपोज़िटरी या डॉकर इमेजेस भी प्रदान करते हैं जो इंस्टॉलेशन और अपडेट को सरल बनाते हैं। सभी क्लाइंट्स ओपन-सोर्स हैं, इसलिए आप इन्हें सोर्स से भी बना सकते हैं। यह एक अधिक उन्नत तरीका है, लेकिन कुछ मामलों में इसकी आवश्यकता हो सकती है । + +हर क्लाइंट को स्थापित करने के निर्देश क्लाइंट सूचियों में लिंक किए गए प्रलेखन में प्रदान किए गए हैं। + +यहां क्लाइंट्स के रिलीज़ पेज़ हैं जहाँ आप उनके पहले से तैयार बाइनरी या स्थापना के निर्देश प्राप्त कर सकते हैं: + +##### निष्पादन ग्राहक + +- [बेसु](https://github.com/hyperledger/besu/releases) +- [एरिगोन](https://github.com/ledgerwatch/erigon/releases) +- [गेथ](https://geth.ethereum.org/downloads/) +- [नेदरमाइंड](https://downloads.nethermind.io/) +- [रेथ](https://reth.rs/installation/installation.html) + +यह भी ध्यान देने योग्य है कि क्लाइंट विविधता एक [निष्पादन परत की एक समस्या](/developers/docs/nodes-and-clients/client-diversity/#execution-layer) है। सुझाया जाता है कि पाठक एक अल्पसंख्यक निष्पादन क्लाइंट चलाने पर विचार करें। + +##### सहमति ग्राहक + +- [लाइटहाउस](https://github.com/sigp/lighthouse/releases/latest) +- [Lodestar](https://chainsafe.github.io/lodestar/install/source/) (एक पहले से तैयार बाइनरी, केवल एक डॉकर इमेज प्रदान नहीं करता है या उसे स्रोत से बनाया जा सकता है) +- [निम्बस](https://github.com/status-im/nimbus-eth2/releases/latest) +- [प्रिज़्म](https://github.com/prysmaticlabs/prysm/releases/latest) +- [टेकु](https://github.com/ConsenSys/teku/releases) + +[क्लाइंट विविधता](/developers/docs/nodes-and-clients/client-diversity/) सहमति नोड्स के लिए बहुत महत्वपूर्ण है जो सत्यापनकर्ता चला रहे हैं। अगर ज़्यादातर सत्यापनकर्ता एक ही क्लाइंट इम्प्लीमेंटेशन चला रहे हैं, तो नेटवर्क की सुरक्षा खतरे में पड़ सकती है। इसलिए, अल्पसंख्यक क्लाइंट को चुनने पर विचार करने का सुझाव दिया जाता है। + +[नवीनतम नेटवर्क क्लाइंट उपयोग देखें](https://clientdiversity.org/) और [ग्राहक विविधता](/developers/docs/nodes-and-clients/client-diversity) के बारे में अधिक जानें। + +##### सॉफ़्टवेयर की पुष्टि करना + +इंटरनेट से सॉफ़्टवेयर डाउनलोड करते समय, इसकी अखंडता की पुष्टि करने का सुझाव दिया जाता है। यह कदम वैकल्पिक है, लेकिन एथेरियम क्लाइंट जैसे महत्वपूर्ण इंफ़्रास्ट्रक्चर के लिए, संभावित हमलों के तरीकों के बारे में जागरूक होना और उनसे बचना महत्वपूर्ण है। अगर आपने एक पहले से तैयार बाइनरी डाउनलोड किया है, तो आपको उस पर भरोसा करना होगा और इस जोखिम को स्वीकार करना होगा कि कोई हमलावर उस निष्पादन योग्य फ़ाइल को एक दुर्भावनापूर्ण फ़ाइल के साथ बदल सकता है। + +डेवलपर रिलीज़ किए गए बाइनरी को अपनी PGP कुंजियों से हस्ताक्षरित करते हैं, ताकि आप क्रिप्टोग्राफ़िक रूप से सत्यापित कर सकें कि आप वास्तव में उनके द्वारा बनाए गए सॉफ़्टवेयर को चला रहे हैं। आपको केवल डेवलपर द्वारा उपयोग की जाने वाली सार्वजनिक कुंजियाँ प्राप्त करने की आवश्यकता है, जो क्लाइंट रिलीज वाले पेजों या प्रलेखन में पाई जा सकती हैं। क्लाइंट रिलीज और उसके हस्ताक्षर को डाउनलोड करने के बाद, आप उन्हें आसानी से सत्यापित करने के लिए [GnuPG](https://gnupg.org/download/index.html) जैसे PGP कार्यान्वयन का उपयोग कर सकते हैं। [linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) पर `gpg` या [Windows/MacOS](https://freedom.press/training/verifying-open-source-software/) का उपयोग करके ओपन-सोर्स सॉफ़्टवेयर को सत्यापित करने पर एक ट्यूटोरियल देखें। + +सत्यापन का एक अन्य रूप यह सुनिश्चित करना है कि आपके द्वारा डाउनलोड किए गए सॉफ़्टवेयर का हैश, जो एक अद्वितीय क्रिप्टोग्राफिक फ़िंगरप्रिंट है, डेवलपर द्वारा प्रदान किए गए हैश से मेल खाता है। यह PGP का उपयोग करने से भी आसान है, और कुछ क्लाइंट केवल यह विकल्प प्रदान करते हैं। बस डाउनलोड किए गए सॉफ़्टवेयर पर हैश फ़ंक्शन चलाएं और इसकी तुलना रिलीज वाले पेज पर दिए गए हैश से करें। उदाहरण के लिए: + +```sh +sha256sum teku-22.6.1.tar.gz + +9b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde +``` + +#### क्लाइंट सेटअप {#client-setup} + +क्लाइंट सॉफ़्टवेयर को इंस्टॉल, डाउनलोड या संकलित करने के बाद, आप इसे चलाने के लिए तैयार हैं। इसका मतलब केवल यह है कि इसे उचित कॉन्फ़िगरेशन के साथ निष्पादित किया जाना चाहिए। क्लाइंट बेहतर कॉन्फ़िगरेशन विकल्प प्रदान करते हैं, जो विभिन्न सुविधाओं को सक्षम कर सकते हैं। + +आइए उन विकल्पों से शुरू करें जो क्लाइंट की परफ़ॉर्मेंस और डेटा उपयोग को महत्वपूर्ण रूप से प्रभावित कर सकते हैं। [सिंक मोड](/developers/docs/nodes-and-clients/#sync-modes) ब्लॉकचेन डेटा को डाउनलोड करने और मान्य करने के विभिन्न तरीकों को दर्शाते हैं। नोड शुरू करने से पहले, आपको तय करना चाहिए कि किस नेटवर्क और सिंक मोड का उपयोग करना है। सबसे महत्वपूर्ण बातें जिन पर विचार करना है वे हैं डिस्क स्पेस और सिंक टाइम जो क्लाइंट को चाहिए होगा। यह निर्धारित करने के लिए क्लाइंट के दस्तावेज़ों पर ध्यान दें कि कौन सा सिंक मोड डिफ़ॉल्ट है। अगर वह आपके लिए उपयुक्त नहीं है, तो सुरक्षा के स्तर, उपलब्ध डेटा और लागत के आधार पर किसी अन्य का चयन करें। सिंक्रनाइज़ेशन एल्गोरिथम के अलावा, आप विभिन्न प्रकार के पुराने डेटा की प्रूनिंग भी सेट कर सकते हैं। प्रूनिंग पुराने डेटा को हटाने की अनुमति देता है, जैसे कि स्टेट ट्राई नोड्स को हटाना जो हाल के ब्लॉक्स से पहुंच योग्य नहीं हैं। + +अन्य बुनियादी कॉन्फ़िगरेशन विकल्प हैं, जैसे नेटवर्क चुनना - मेननेट या टेस्टनेट, RPC या WebSockets के लिए HTTP एंडपॉइंट सक्षम करना आदि। आप क्लाइंट के प्रलेखन में सभी सुविधाओं और विकल्पों को पा सकते हैं। विभिन्न क्लाइंट कॉन्फ़िगरेशन को सीधे CLI या कॉन्फ़िग फ़ाइल में संबंधित फ़्लैग के साथ क्लाइंट को निष्पादित करके सेट किया जा सकता है। हर क्लाइंट थोड़ा अलग है; कृपया कॉन्फ़िग विकल्पों के विवरण के लिए हमेशा इसके आधिकारिक प्रलेखन या सहायता पेज को देखें। + +परीक्षण उद्देश्यों के लिए, आप टेस्टनेट नेटवर्क में से एक पर क्लाइंट चलाना पसंद कर सकते हैं। [समर्थित नेटवर्क का ओवरव्यू देखें](/developers/docs/nodes-and-clients/#execution-clients)। + +बुनियादी कॉन्फ़िगरेशन के साथ एक्सीक्यूशन क्लाइंट चलाने के उदाहरण अगले सेक्शन में पाए जा सकते हैं। + +#### एक्सीक्यूशन क्लाइंट शुरू करना {#starting-the-execution-client} + +एथेरियम क्लाइंट सॉफ़्टवेयर शुरू करने से पहले, एक अंतिम जांच करें कि आपका एनवायरमेंट तैयार है। उदाहरण के लिए, सुनिश्चित करें कि: + +- चुने गए नेटवर्क और सिंक मोड को ध्यान में रखते हुए पर्याप्त डिस्क स्पेस है। +- मेमोरी और CPU अन्य प्रोग्रामों द्वारा रोका नहीं गया है। +- ऑपरेटिंग सिस्टम नए वर्जन में अपडेट किया गया है। +- सिस्टम में सही समय और तारीख है। +- आपका राउटर और फ़ायरवॉल लिसनिंग पोर्ट्स पर कनेक्शन स्वीकार करते हैं। डिफ़ॉल्ट रूप से एथेरियम क्लाइंट्स एक लिसनर (TCP) पोर्ट और एक डिस्कवरी (UDP) पोर्ट का उपयोग करते हैं, दोनों डिफ़ॉल्ट रूप से 30303 पर होते हैं। + +यह सुनिश्चित करने के लिए कि सब कुछ सही ढंग से काम कर रहा है, पहले अपने क्लाइंट को एक टेस्टनेट पर चलाएं। + +आपको शुरुआत में किसी भी क्लाइंट सेटिंग्स की घोषणा करनी होगी जो डिफ़ॉल्ट नहीं हैं। आप अपने पसंदीदा कॉन्फ़िगरेशन की घोषणा करने के लिए फ़्लैग या कॉन्फ़िग फ़ाइल का उपयोग कर सकते हैं। हर क्लाइंट की सुविधाओं का सेट और कॉन्फ़िग सिंटैक्स अलग होता है। विशिष्टताओं के लिए अपने क्लाइंट के प्रलेखन की जांच करें। + +एक्सीक्यूशन और सहमति क्लाइंट [इंजन API](https://github.com/ethereum/execution-apis/tree/main/src/engine) में निर्दिष्ट एक प्रमाणित समाप्ति बिंदु के माध्यम से संवाद करते हैं। सहमति क्लाइंट से कनेक्ट करने के लिए, निष्पादन क्लाइंट को एक ज्ञात पथ पर एक [`jwtsecret`](https://jwt.io/) जेनरेट करना होगा। सुरक्षा और स्थिरता कारणों से, क्लाइंट को एक ही मशीन पर चलना चाहिए, और दोनों क्लाइंट को यह पथ जानना चाहिए, क्योंकि इसका उपयोग उनके बीच एक स्थानीय RPC कनेक्शन को प्रमाणित करने के लिए किया जाता है। निष्पादन क्लाइंट को प्रमाणित API के लिए एक लिसनिंग पोर्ट भी परिभाषित करना होगा। + +यह टोकन स्वचालित रूप से क्लाइंट सॉफ़्टवेयर द्वारा जेनरेट किया जाता है, लेकिन कुछ मामलों में, आपको इसे खुद करने की आवश्यकता हो सकती है। आप इसे [OpenSSL](https://www.openssl.org/) का उपयोग करके जेनरेट कर सकते हैं: + +```sh +openssl rand -hex 32 > jwtsecret +``` + +#### एक्सीक्यूशन क्लाइंट चलाना {#running-an-execution-client} + +यह सेक्शन आपको एक्सीक्यूशन क्लाइंट शुरू करने में मार्गदर्शन करेगा। यह केवल एक बुनियादी कॉन्फ़िगरेशन के उदाहरण के रूप में काम करता है, जो क्लाइंट को इन सेटिंग्स के साथ शुरू करेगा: + +- कनेक्ट करने के लिए नेटवर्क निर्दिष्ट करता है, हमारे उदाहरणों में मेननेट + - इसके बजाय आप अपने सेटअप के प्रारंभिक परीक्षण के लिए [टेस्टनेट में से एक](/developers/docs/networks/) चुन सकते हैं +- डेटा डायरेक्टरी परिभाषित करता है, जहां ब्लॉकचेन सहित सभी डेटा संग्रहित किया जाएगा + - सुनिश्चित करें कि आप पथ को वास्तविक पथ से बदलें, जैसे कि अपने बाहरी ड्राइव की ओर इशारा करते हुए +- क्लाइंट के साथ संवाद करने के लिए इंटरफेस सक्षम करता है + - कंसेंसस क्लाइंट के साथ संचार के लिए JSON-RPC और इंजन API सहित +- प्रमाणित API के लिए `jwtsecret` का पथ परिभाषित करता है + - सुनिश्चित करें कि आप उदाहरण पथ को एक वास्तविक पथ से बदलते हैं जिसे क्लाइंट द्वारा एक्सेस किया जा सकता है, जैसे `/tmp/jwtsecret` + +कृपया ध्यान रखें कि यह केवल एक बुनियादी उदाहरण है, अन्य सभी सेटिंग्स डिफ़ॉल्ट पर सेट की जाएंगी। डिफ़ॉल्ट मान, सेटिंग्स और सुविधाओं के बारे में जानने के लिए प्रत्येक क्लाइंट के प्रलेखन पर ध्यान दें। अधिक सुविधाओं के लिए, उदाहरण के लिए सत्यापनकर्ता चलाने, निगरानी आदि के लिए, कृपया विशिष्ट क्लाइंट के प्रलेखन को देखें। + +> ध्यान दें कि उदाहरणों में बैकस्लैश `\` केवल फ़ॉर्मेटिंग उद्देश्यों के लिए हैं; कॉन्फ़िग ध्वजों को एक ही पंक्ति में परिभाषित किया जा सकता है। + +##### Besu चलाना + +यह उदाहरण Besu को मेननेट पर शुरू करता है, ब्लॉकचेन डेटा को डिफ़ॉल्ट प्रारूप में `/data/ethereum` पर संग्रहित करता है, JSON-RPC और सहमति क्लाइंट को कनेक्ट करने के लिए इंजन RPC सक्षम करता है। इंजन API को `jwtsecret` टोकन के साथ प्रमाणित किया जाता है और केवल `localhost` से कॉल की अनुमति दी जाती है। + +```sh +besu --network=mainnet \ + --data-path=/data/ethereum \ + --rpc-http-enabled=true \ + --engine-rpc-enabled=true \ + --engine-host-allowlist="*" \ + --engine-jwt-enabled=true \ + --engine-jwt-secret=/path/to/jwtsecret +``` + +Besu में एक लॉन्चर विकल्प भी आता है जो कई प्रश्न पूछेगा और कॉन्फ़िग फ़ाइल बनाएगा। इंटरैक्टिव लॉन्चर को निम्न का उपयोग करके चलाएँ: + +```sh +besu --Xlauncher +``` + +[Besu का प्रलेखन](https://besu.hyperledger.org/en/latest/HowTo/Get-Started/Starting-node/) अतिरिक्त विकल्प और कॉन्फ़िगरेशन विवरण शामिल करता है। + +##### Erigon चलाना + +यह उदाहरण Erigon को मेननेट पर शुरू करता है, ब्लॉकचेन डेटा को `/data/ethereum` पर संग्रहित करता है, JSON-RPC सक्षम करता है, परिभाषित करता है कि कौन से नेमस्पेस की अनुमति है और सहमति क्लाइंट को कनेक्ट करने के लिए प्रमाणीकरण सक्षम करता है जो `jwtsecret` पथ द्वारा परिभाषित किया गया है। + +```sh +erigon --chain mainnet \ + --datadir /data/ethereum \ + --http --http.api=engine,eth,web3,net \ + --authrpc.jwtsecret=/path/to/jwtsecret +``` + +Erigon डिफ़ॉल्ट रूप से 8GB HDD के साथ पूर्ण सिंक प्रदर्शन करता है जिसके परिणामस्वरूप 2TB से अधिक आर्काइव डेटा होगा। सुनिश्चित करें कि `datadir` पर्याप्त खाली स्थान वाली डिस्क की ओर इशारा कर रहा है या `--prune` ध्वज पर ध्यान दें जो विभिन्न प्रकार के डेटा को ट्रिम कर सकता है। अधिक जानने के लिए Erigon के `--help` की जांच करें। + +##### Geth चलाना + +यह उदाहरण Geth को मेननेट पर शुरू करता है, ब्लॉकचेन डेटा को `/data/ethereum` पर संग्रहित करता है, JSON-RPC सक्षम करता है और परिभाषित करता है कि किन नेमस्पेस की अनुमति है। यह सहमति क्लाइंट को कनेक्ट करने के लिए प्रमाणीकरण भी सक्षम करता है जिसके लिए `jwtsecret` का पथ और यह विकल्प भी आवश्यक है जो परिभाषित करता है कि किन कनेक्शनों की अनुमति है, हमारे उदाहरण में केवल `localhost` से। + +```sh +geth --mainnet \ + --datadir "/data/ethereum" \ + --http --authrpc.addr localhost \ + --authrpc.vhosts="localhost" \ + --authrpc.port 8551 + --authrpc.jwtsecret=/path/to/jwtsecret +``` + +[सभी कॉन्फ़िगरेशन विकल्पों के लिए दस्तावेज़](https://geth.ethereum.org/docs/fundamentals/command-line-options) जांचें और [सहमति क्लाइंट के साथ Geth चलाने](https://geth.ethereum.org/docs/getting-started/consensus-clients) के बारे में अधिक जानें। + +##### Nethermind चलाना + +Nethermind विभिन्न [इंस्टॉलेशन विकल्प](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/getting-started) प्रदान करता है। पैकेज में विभिन्न बाइनरी आते हैं, जिसमें एक निर्देशित सेटअप के साथ एक लॉन्चर शामिल है, जो आपको कॉन्फ़िगरेशन को इंटरैक्टिव रूप से बनाने में मदद करेगा। वैकल्पिक रूप से, आप रनर पा सकते हैं जो स्वयं एक्जीक्यूटेबल है और आप इसे कॉन्फ़िग ध्वजों के साथ चला सकते हैं। JSON-RPC डिफ़ॉल्ट रूप से सक्षम है। + +```sh +Nethermind.Runner --config mainnet \ + --datadir /data/ethereum \ + --JsonRpc.JwtSecretFile=/path/to/jwtsecret +``` + +Nethermind दस्तावेज़, सहमति क्लाइंट के साथ Nethermind चलाने पर एक [पूर्ण मार्गदर्शिका](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/running-nethermind-post-merge) प्रदान करते हैं। + +एक निष्पादन क्लाइंट अपने मुख्य कार्यों, चुने गए एंडपॉइंट्स को आरंभ करेगा और पीयर्स की खोज शुरू करेगा। पीयर्स की सफलतापूर्वक खोज के बाद, क्लाइंट सिंक्रनाइज़ेशन शुरू करता है। निष्पादन क्लाइंट, सहमति क्लाइंट से कनेक्शन की प्रतीक्षा करेगा। वर्तमान ब्लॉकचेन डेटा तब उपलब्ध होगा जब क्लाइंट वर्तमान स्थिति के साथ सफलतापूर्वक सिंक हो जाएगा। + +##### Reth चलाना + +यह उदाहरण डिफ़ॉल्ट डेटा स्थान का उपयोग करते हुए Reth को मेननेट पर शुरू करता है। JSON-RPC और इंजन RPC प्रमाणीकरण को सहमति क्लाइंट से कनेक्ट करने के लिए सक्षम करता है जो `jwtsecret` पथ द्वारा परिभाषित किया गया है, केवल `localhost` से कॉल की अनुमति के साथ। + +```sh +reth नोड \ + --authrpc.jwtsecret /path/to/jwtsecret \ + --authrpc.addr 127.0.0.1 \ + --authrpc.port 8551 +``` + +डिफ़ॉल्ट डेटा डायरेक्टरी के बारे में अधिक जानने के लिए [Reth कॉन्फ़िगर करना](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth) देखें। [Reth का प्रलेखन](https://reth.rs/run/mainnet.html) अतिरिक्त विकल्प और कॉन्फ़िगरेशन विवरण शामिल करता है। + +#### सहमति क्लाइंट शुरू करना {#starting-the-consensus-client} + +सहमति क्लाइंट को निष्पादन क्लाइंट के साथ एक स्थानीय RPC कनेक्शन स्थापित करने के लिए सही पोर्ट कॉन्फ़िगरेशन के साथ शुरू किया जाना चाहिए। सहमति क्लाइंट को एक्सपोज्ड निष्पादन क्लाइंट पोर्ट के साथ कॉन्फ़िगरेशन तर्क के रूप में चलाया जाना चाहिए। + +सहमति क्लाइंट को निष्पादन क्लाइंट के `jwt-secret` का पथ भी चाहिए ताकि उनके बीच RPC कनेक्शन को प्रमाणित किया जा सके। ऊपर दिए गए एक्सीक्यूशन उदाहरणों के समान, प्रत्येक सहमति क्लाइंट में एक कॉन्फ़िगरेशन ध्वज होता है जो jwt टोकन फ़ाइल पथ को तर्क के रूप में लेता है। यह निष्पादन क्लाइंट को प्रदान किए गए `jwtsecret` पथ के अनुरूप होना चाहिए। + +यदि आप एक वेलिडेटर रन करने की योजना बना रहे हैं, तो शुल्क प्राप्तकर्ता के एथेरियम पते को निर्दिष्ट करने वाला एक कॉन्फ़िगरेशन ध्वज जोड़ना सुनिश्चित करें। यह वह जगह है जहां आपके सत्यापनकर्ता के लिए ईथर पुरस्कार जमा होते हैं। प्रत्येक सहमति क्लाइंट में एक विकल्प होता है, जैसे `--suggested-fee-recipient=0xabcd1`, जो एक एथेरियम पते को तर्क के रूप में लेता है। + +टेस्टनेट पर एक बीकन नोड शुरू करते समय, आप [चेकपॉइंट सिंक](https://notes.ethereum.org/@launchpad/checkpoint-sync) के लिए एक सार्वजनिक एंडपॉइंट का उपयोग करके महत्वपूर्ण सिंकिंग समय बचा सकते हैं। + +#### एक सहमति क्लाइंट चलाना {#running-a-consensus-client} + +##### लाइटहाउस चलाना + +लाइटहाउस रन करने से पहले, [लाइटहाउस बुक](https://lighthouse-book.sigmaprime.io/installation.html) में इसे इंस्टॉल और कॉन्फ़िगर करने के तरीके के बारे में अधिक जानें। + +```sh +lighthouse beacon_node \ + --network mainnet \ + --datadir /data/ethereum \ + --http \ + --execution-endpoint http://127.0.0.1:8551 \ + --execution-jwt /path/to/jwtsecret +``` + +##### Lodestar चलाना + +Lodestar सॉफ़्टवेयर को इंस्टॉल करने के लिए इसे संकलित करें या डॉकर इमेज डाउनलोड करें। [दस्तावेज़ों](https://chainsafe.github.io/lodestar/) में और अधिक जानें और [सेटअप गाइड](https://hackmd.io/@philknows/rk5cDvKmK) में विस्तृत जानकारी प्राप्त करें। + +```sh +lodestar beacon \ + --rootDir="/data/ethereum" \ + --network=mainnet \ + --eth1.enabled=true \ + --execution.urls="http://127.0.0.1:8551" \ + --jwt-secret="/path/to/jwtsecret" +``` + +##### Nimbus चलाना + +Nimbus आम सहमति और निष्पादन क्लाइंट दोनों के साथ आता है। इसे बहुत मामूली कंप्यूटिंग शक्ति के साथ भी विभिन्न उपकरणों पर चलाया जा सकता है। [निर्भरता और स्वयं Nimbus को स्थापित करने के बाद](https://nimbus.guide/quick-start.html), आप इसके सहमति क्लाइंट को चला सकते हैं: + +```sh +nimbus_beacon_node \ + --network=mainnet \ + --web3-url=http://127.0.0.1:8551 \ + --rest \ + --jwt-secret="/path/to/jwtsecret" +``` + +##### प्रिज़्म चलाना + +Prysm स्क्रिप्ट के साथ आता है जो आसान स्वचालित स्थापना की अनुमति देता है। विवरण [प्रिज़्म डॉक्स](https://docs.prylabs.network/docs/install/install-with-script) में पाए जा सकते हैं। + +```sh +./prysm.sh beacon-chain \ + --mainnet \ + --datadir /data/ethereum \ + --execution-endpoint=http://localhost:8551 \ + --jwt-secret=/path/to/jwtsecret +``` + +##### Teku चलाना + +```sh +teku --network mainnet \ + --data-path "/data/ethereum" \ + --ee-endpoint http://localhost:8551 \ + --ee-jwt-secret-file "/path/to/jwtsecret" +``` + +जब एक सहमति क्लाइंट जमा अनुबंध को पढ़ने और सत्यापनकर्ताओं की पहचान करने के लिए निष्पादन क्लाइंट से जुड़ता है, तो यह अन्य बीकन नोड पीयर्स से भी जुड़ता है और उत्पत्ति से सहमति स्लॉट्स को सिंक करना शुरू करता है। एक बार जब बीकन नोड वर्तमान युग तक पहुंच जाता है, तो बीकन API आपके सत्यापनकर्ताओं के लिए उपयोग योग्य हो जाती है। [बीकन नोड API](https://eth2docs.vercel.app/) के बारे में अधिक जानें। + +### सत्यापनकर्ता जोड़ना {#adding-validators} + +एक सहमति क्लाइंट सत्यापनकर्ताओं के जुड़ने के लिए एक बीकन नोड के रूप में काम करता है। प्रत्येक सहमति क्लाइंट का अपना सत्यापनकर्ता सॉफ्टवेयर होता है जिसका विस्तृत विवरण उसके संबंधित प्रलेखन में दिया गया है। + +अपना खुद का सत्यापनकर्ता चलाना [एकल स्टेकिंग](/staking/solo/) की अनुमति देता है, जो एथेरियम नेटवर्क का समर्थन करने का सबसे प्रभावशाली और विश्वसनीय तरीका है। हालांकि, इसके लिए 32 ETH की जमा राशि की आवश्यकता होती है। अपने खुद के नोड पर कम राशि के साथ एक सत्यापनकर्ता चलाने के लिए, [रॉकेट पूल](https://rocketpool.net/node-operators) जैसा विकेंद्रीकृत पूल जिसमें अनुमति रहित नोड ऑपरेटर हों, आपको रुचिकर लग सकता है। + +स्टेकिंग शुरू करने और सत्यापनकर्ता कुंजी बनाने का सबसे आसान तरीका [होलेस्की टेस्टनेट स्टेकिंग लॉन्चपैड](https://holesky.launchpad.ethereum.org/) का उपयोग करना है, जो आपको [होलेस्की पर नोड्स चलाकर](https://notes.ethereum.org/@launchpad/holesky) अपने सेटअप का परीक्षण करने की अनुमति देता है। जब आप मेननेट के लिए तैयार हों, तो आप [मेननेट स्टेकिंग](https://launchpad.ethereum.org/) लॉन्चपैड का उपयोग करके इन चरणों को दोहरा सकते हैं। + +स्टेकिंग विकल्पों के बारे में जानकारी के लिए [स्टेकिंग पृष्ठ](/staking) देखें। + +### नोड का उपयोग करना {#using-the-node} + +निष्पादन ग्राहक [RPC API एंडपॉइंट्स](/developers/docs/apis/json-rpc/) प्रदान करते हैं जिनका उपयोग आप विभिन्न तरीकों से एथेरियम नेटवर्क पर लेनदेन जमा करने, बातचीत करने या स्मार्ट अनुबंध तैनात करने के लिए कर सकते हैं: + +- उपयुक्त प्रोटोकॉल का उपयोग करके उन्हें मैन्युअल रूप से कॉल करना (जैसे `curl` का उपयोग करना) +- एक प्रदान किए गए कंसोल को संलग्न करना (जैसे `geth attach`) +- web3 लाइब्रेरीज़, जैसे [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview), [ईथर](https://github.com/ethers-io/ethers.js/) का उपयोग करके उन्हें एप्लिकेशन में लागू करना + +विभिन्न क्लाइंट के RPC एंडपॉइंट्स के अलग-अलग कार्यान्वयन होते हैं। लेकिन एक मानक JSON-RPC है जिसका उपयोग आप हर क्लाइंट के साथ कर सकते हैं। एक सिंहावलोकन के लिए [JSON-RPC दस्तावेज़ पढ़ें](/developers/docs/apis/json-rpc/)। एप्लिकेशन जिन्हें एथेरियम नेटवर्क से जानकारी की आवश्यकता होती है, वे इस RPC का उपयोग कर सकते हैं। उदाहरण के लिए, लोकप्रिय वॉलेट MetaMask [आपको अपने खुद के RPC एंडपॉइंट से कनेक्ट](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node) करने की अनुमति देता है जिसमें मजबूत निजता और सुरक्षा लाभ हैं। + +सभी सहमति क्लाइंट एक [बीकन API](https://ethereum.github.io/beacon-APIs) को प्रदर्शित करते हैं जिसका उपयोग सहमति क्लाइंट की स्थिति की जांच करने या [Curl](https://curl.se) जैसे उपकरणों का उपयोग करके अनुरोध भेजकर ब्लॉक और सहमति डेटा डाउनलोड करने के लिए किया जा सकता है। इस पर अधिक जानकारी प्रत्येक सहमति ग्राहक के प्रलेखन में पाई जा सकती है। + +#### RPC तक पहुंचना {#reaching-rpc} + +निष्पादन क्लाइंट JSON-RPC के लिए डिफ़ॉल्ट पोर्ट `8545` है लेकिन आप कॉन्फ़िगरेशन में स्थानीय एंडपॉइंट्स के पोर्ट को संशोधित कर सकते हैं। डिफ़ॉल्ट रूप से, RPC इंटरफ़ेस केवल आपके कंप्यूटर के लोकलहोस्ट पर पहुंच योग्य होता है। इसे दूरस्थ रूप से सुलभ बनाने के लिए, आप पते को `0.0.0.0` में बदलकर इसे सार्वजनिक रूप से प्रदर्शित करना चाह सकते हैं। यह इसे स्थानीय नेटवर्क और सार्वजनिक IP पते पर पहुंच योग्य बना देगा। अधिकांश मामलों में आपको अपने राउटर पर पोर्ट फॉरवर्डिंग भी सेट करने की आवश्यकता होगी। + +इंटरनेट पर पोर्ट को उजागर करने के दृष्टिकोण को सावधानी से अपनाएं क्योंकि यह इंटरनेट पर किसी को भी आपके नोड को नियंत्रित करने की अनुमति देगा। यदि आप अपने क्लाइंट का उपयोग वॉलेट के रूप में कर रहे हैं तो दुर्भावनापूर्ण कर्ता आपके सिस्टम को ठप्प करने या आपके धन को चुराने के लिए आपके नोड तक पहुंच सकते हैं। + +इसका एक समाधान संभावित रूप से हानिकारक RPC विधियों को संशोधन योग्य होने से रोकना है। उदाहरण के लिए, Geth के साथ, आप एक ध्वज के साथ संशोधन योग्य विधियों को घोषित कर सकते हैं: -`--http.api web3,eth,txpool`। + +RPC इंटरफ़ेस तक पहुंच को एज लेयर API या वेब सर्वर एप्लिकेशन के विकास के माध्यम से बढ़ाया जा सकता है, जैसे Nginx, और उन्हें आपके क्लाइंट के स्थानीय पते और पोर्ट से जोड़ा जा सकता है। एक मध्य परत का लाभ उठाना डेवलपर्स को RPC इंटरफ़ेस के लिए सुरक्षित `https` कनेक्शन के लिए एक प्रमाणपत्र सेट करने की क्षमता भी प्रदान कर सकता है। + +एक वेब सर्वर, एक प्रॉक्सी, या बाहरी दिखने वाले रेस्ट API को सेट करना आपके नोड के RPC एंडपॉइंट तक पहुंच प्रदान करने का एकमात्र तरीका नहीं है। सार्वजनिक रूप से पहुंच योग्य एंडपॉइंट सेट करने का एक अन्य निजता-संरक्षित तरीका नोड को अपनी खुद की [Tor](https://www.torproject.org/) अनियन सर्विस पर होस्ट करना है। यह आपको स्थिर सार्वजनिक IP पते या खुले पोर्ट के बिना अपने स्थानीय नेटवर्क के बाहर RPC तक पहुंचने की अनुमति देगा। हालांकि, इस कॉन्फ़िगरेशन का उपयोग करने से RPC एंडपॉइंट केवल Tor नेटवर्क के माध्यम से पहुंच योग्य हो सकता है जो सभी एप्लिकेशन द्वारा समर्थित नहीं है और इससे कनेक्शन की समस्याएं हो सकती हैं। + +ऐसा करने के लिए, आपको अपनी खुद की [अनियन सर्विस](https://community.torproject.org/onion-services/)बनानी होगी। अपनी खुद की होस्ट करने के लिए अनियन सर्विस सेटअप पर [प्रलेखन](https://community.torproject.org/onion-services/setup/) देखें। आप इसे RPC पोर्ट के लिए प्रॉक्सी के साथ एक वेब सर्वर की ओर निर्देशित कर सकते हैं या सीधे RPC की ओर निर्देशित कर सकते हैं। + +अंत में, और आंतरिक नेटवर्क तक पहुंच प्रदान करने के सबसे लोकप्रिय तरीकों में से एक VPN कनेक्शन के माध्यम से है। आपके उपयोग के मामले और आपके नोड तक पहुंच की आवश्यकता वाले यूज़र की मात्रा के आधार पर, एक सुरक्षित VPN कनेक्शन एक विकल्प हो सकता है। [OpenVPN](https://openvpn.net/) एक पूर्ण-विशेषताओं वाला SSL VPN है जो उद्योग मानक SSL/TLS प्रोटोकॉल का उपयोग करके OSI लेयर 2 या 3 सुरक्षित नेटवर्क विस्तार को लागू करता है, यह प्रमाणपत्रों, स्मार्ट कार्ड्स, और/या यूज़र नाम/पासवर्ड प्रमाण-पत्रों पर आधारित लचीले क्लाइंट प्रमाणीकरण विधियों का समर्थन करता है, और VPN वर्चुअल इंटरफेस पर लागू फायरवॉल नियमों का उपयोग करके यूज़र या समूह-विशिष्ट पहुँच नियंत्रण नीतियों की अनुमति देता है। + +### नोड का संचालन करना {#operating-the-node} + +आपको नियमित रूप से अपने नोड की निगरानी करनी चाहिए यह सुनिश्चित करने के लिए कि यह ठीक से चल रहा है। आपको कभी-कभी रखरखाव करने की आवश्यकता हो सकती है। + +#### एक नोड को ऑनलाइन रखना {#keeping-node-online} + +आपके नोड को हर समय ऑनलाइन होने की आवश्यकता नहीं है, लेकिन आपको इसे नेटवर्क के साथ सिंक रखने के लिए जितना संभव हो उतना ऑनलाइन रखना चाहिए। आप इसे पुनः आरंभ करने के लिए बंद कर सकते हैं, लेकिन ध्यान रखें कि: + +- यदि नवीनतम स्थिति अभी भी डिस्क पर लिखी जा रही हो तो बंद होने में कुछ मिनट लग सकते हैं। +- बलपूर्वक बंद करने से डेटाबेस क्षतिग्रस्त हो सकता है जिससे आपको पूरे नोड को फिर से सिंक करने की आवश्यकता हो सकती है। +- आपका क्लाइंट नेटवर्क के साथ सिंक से बाहर हो जाएगा और जब आप इसे पुनः आरंभ करेंगे तो इसे फिर से सिंक करने की आवश्यकता होगी। हालांकि नोड अंतिम शटडाउन से सिंक करना शुरू कर सकता है, प्रक्रिया में समय लग सकता है जो इस बात पर निर्भर करता है कि यह कितने समय से ऑफलाइन था। + +_यह सहमति परत सत्यापनकर्ता नोड्स पर लागू नहीं होता।_ अपने नोड को ऑफलाइन करने से इस पर निर्भर सभी सेवाएं प्रभावित होंगी। यदि आप _स्टेकिंग_ उद्देश्यों के लिए एक नोड चला रहे हैं तो आपको डाउनटाइम को यथासंभव कम करने का प्रयास करना चाहिए। + +#### क्लाइंट सेवाएं बनाना {#creating-client-services} + +अपने क्लाइंट को स्टार्टअप पर स्वचालित रूप से चलाने के लिए एक सेवा बनाने पर विचार करें। उदाहरण के लिए, Linux सर्वर पर, अच्छा अभ्यास होगा कि एक सेवा बनाई जाए, जैसे `systemd` के साथ, जो उचित कॉन्फ़िग के साथ क्लाइंट को निष्पादित करती है, सीमित विशेषाधिकारों वाले यूज़र के तहत, और स्वचालित रूप से पुनः आरंभ करती है। + +#### क्लाइंट को अपडेट करना {#updating-clients} + +आपको अपने क्लाइंट सॉफ़्टवेयर को नवीनतम सुरक्षा पैच, सुविधाओं और [EIP](/eips/) के साथ अप-टू-डेट रखने की आवश्यकता है। विशेष रूप से [हार्ड फ़ोर्क](/history/) से पहले, सुनिश्चित करें कि आप सही क्लाइंट संस्करणों को चला रहे हैं। + +> महत्वपूर्ण नेटवर्क अपडेट से पहले, EF अपने [ब्लॉग](https://blog.ethereum.org) पर एक पोस्ट प्रकाशित करता है। आप इन [घोषणाओं की सदस्यता ले सकते हैं](https://blog.ethereum.org/category/protocol#subscribe) ताकि जब आपके नोड को अपडेट की आवश्यकता हो तो आपको अपने मेल पर एक सूचना मिल सके। + +क्लाइंट को अपडेट करना बहुत आसान है। प्रत्येक क्लाइंट के अपने प्रलेखन में विशिष्ट निर्देश हैं, लेकिन प्रक्रिया आम तौर पर केवल नवीनतम संस्करण डाउनलोड करना और नए एक्जीक्यूटेबल के साथ क्लाइंट को पुनः आरंभ करना है। क्लाइंट को अपडेट लागू होने के साथ वहीं से शुरू करना चाहिए जहां से वह छोड़ा गया था। + +प्रत्येक क्लाइंट कार्यान्वयन में एक मानव-पठनीय संस्करण स्ट्रिंग होती है जिसका उपयोग पीयर-टू-पीयर प्रोटोकॉल में किया जाता है लेकिन कमांड लाइन से भी पहुंच योग्य होती है। यह संस्करण स्ट्रिंग यूज़र को यह जांचने की अनुमति देती है कि वे सही संस्करण चला रहे हैं और ब्लॉक खोजकर्ता और अन्य विश्लेषणात्मक उपकरणों को नेटवर्क पर विशिष्ट क्लाइंट के वितरण को मात्रात्मक करने में रुचि रखने वालों को अनुमति देती है। संस्करण स्ट्रिंग के बारे में अधिक जानकारी के लिए कृपया व्यक्तिगत क्लाइंट प्रलेखन देखें। + +#### अतिरिक्त सेवाएं चलाना {#running-additional-services} + +अपना खुद का नोड चलाने से आप उन सेवाओं का उपयोग कर सकते हैं जिन्हें एथेरियम क्लाइंट RPC तक सीधी पहुंच की आवश्यकता होती है। ये एथेरियम पर बनाई गई सेवाएं हैं जैसे [लेयर 2 समाधान](/developers/docs/scaling/#layer-2-scaling), वॉलेट के लिए बैकएंड, ब्लॉक खोजकर्ता, डेवलपर्स उपकरण और अन्य एथेरियम इंफ्रास्ट्रक्चर। + +#### नोड की निगरानी करना {#monitoring-the-node} + +अपने नोड की उचित निगरानी के लिए, मेट्रिक्स एकत्र करने पर विचार करें। क्लाइंट मेट्रिक्स एंडपॉइंट प्रदान करते हैं ताकि आप अपने नोड के बारे में व्यापक डेटा प्राप्त कर सकें। [InfluxDB](https://www.influxdata.com/get-influxdb/) या [Prometheus](https://prometheus.io/) जैसे उपकरण का उपयोग करें ताकि डेटाबेस बनाए जा सकें जिन्हें आप [Grafana](https://grafana.com/) जैसे सॉफ़्टवेयर में विज़ुअलाइज़ेशन और चार्ट में बदल सकते हैं। इस सॉफ्टवेयर का उपयोग करने के लिए कई सेटअप हैं और अलग-अलग Grafana डैशबोर्ड हैं जिनके माध्यम से आप अपने नोड और सम्पूर्ण नेटवर्क को विज़ुअलाइज़ कर सकते हैं। उदाहरण के लिए, [Geth की निगरानी पर ट्यूटोरियल](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/) देखें। + +अपनी निगरानी के हिस्से के रूप में, अपनी मशीन के प्रदर्शन पर नज़र रखना सुनिश्चित करें। आपके नोड के प्रारंभिक सिंक्रनाइज़ेशन के दौरान, क्लाइंट सॉफ़्टवेयर CPU और RAM पर बहुत भारी हो सकता है। Grafana के अलावा, आप ऐसा करने के लिए अपने OS द्वारा प्रदान किए जाने वाले उपकरण जैसे `htop` या `uptime` का उपयोग कर सकते हैं। + +## अग्रिम पठन {#further-reading} + +- [एथेरियम स्टेकिंग मार्गदर्शिकाएँ](https://github.com/SomerEsat/ethereum-staking-guides) - _सोमर एसैट, अक्सर अपडेट किया जाता है_ +- [मार्गदर्शिका | मेननेट पर एथेरियम स्टेकिंग के लिए एक सत्यापनकर्ता कैसे सेटअप करें](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet)- _CoinCashew, नियमित रूप से अपडेट किया गया_ +- [ETHStaker टेस्टनेट पर सत्यापनकर्ताओं को चलाने के लिए गाइड करता है](https://github.com/remyroy/ethstaker#guides) – _ETHStaker, नियमित रूप से अपडेट किया जाता है_ +- [नोड ऑपरेटरों के लिए मर्ज FAQ](https://notes.ethereum.org/@launchpad/node-faq-merge) - _जुलाई 2022_ +- [एथेरियम पूर्ण मान्य नोड होने के लिए हार्डवेयर आवश्यकताओं का विश्लेषण करना](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– अल्बर्ट पलाऊ, 24 सितंबर 2018_ +- [एथेरियम फुल नोड्स चलाना: बमुश्किल प्रेरित लोगों के लिए एक गाइड](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– जस्टिन लेरौक्स, 7 नवंबर 2019_ +- [एथेरियम मेननेट पर Hyperledger Besu नोड चलाना: लाभ, आवश्यकताएं और सेटअप](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– फेलिप फरागी, 7 मई 2020_ +- [मॉनिटरिंग स्टैक के साथ Nethermind एथेरियम क्लाइंट को परिनियोजित करना](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _– Nethermind.eth, 8 जुलाई 2020_ + +## संबंधित विषय {#related-topics} + +- [ नोड्स और क्लाइंट](/developers/docs/nodes-and-clients/) +- [ब्लॉक](/developers/docs/blocks/) +- [नेटवर्क](/developers/docs/networks/) diff --git a/public/content/translations/hi/developers/docs/smart-contracts/composability/index.md b/public/content/translations/hi/developers/docs/smart-contracts/composability/index.md new file mode 100644 index 00000000000..cdc77ea5776 --- /dev/null +++ b/public/content/translations/hi/developers/docs/smart-contracts/composability/index.md @@ -0,0 +1,76 @@ +--- +title: स्मार्ट अनुबंध कम्पोज़ेबिलिटी +description: +lang: hi +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} + +कम्पोज़ेबिलिटी नए सिस्टम या आउटपुट बनाने के लिए अलग-अलग घटकों का संयोजन कर रही है। सॉफ़टवेयर के विकास में, कम्पोज़ेबिलिटी का मतलब है कि डेवलपर्स नए एप्लिकेशन के निर्माण के लिए मौजूदा सॉफ़्टवेयर के घटकों का फिर से उपयोग कर सकते हैं। कम्पोज़ेबिलिटी को समझने का एक अच्छा तरीका लेगो ब्लॉक के रूप में कंपोज़ेबल तत्वों के बारे में सोचना है। प्रत्येक लेगो को दूसरे के साथ जोड़ा जा सकता है, जिससे आप विभिन्न लेगो को मिलाकर जटिल संरचनाएं बना सकते हैं। + +एथेरियम में, प्रत्येक स्मार्ट अनुबंध एक प्रकार का लेगो है - आप अपनी परियोजना के लिए बिल्डिंग ब्लॉक के रूप में अन्य परियोजनाओं से स्मार्ट अनुबंधों का उपयोग कर सकते हैं। इसका मतलब है कि आपको पहिया या इमारत को शुरुआत से फिर से बनाने में समय बिताने की ज़रूरत नहीं है। + +## कम्पोज़ेबिलिटी कैसे काम करती है? {#how-does-composability-work} + +एथेरियम स्मार्ट अनुबंध सार्वजनिक API की तरह हैं, इसलिए कोई भी अनुबंध के साथ बातचीत कर सकता है या अतिरिक्त कार्यक्षमता के लिए उन्हें डैप्स में इंटीग्रेट कर सकता है। स्मार्ट अनुबंध कम्पोज़ेबिलिटी आम तौर पर तीन सिद्धांतों से काम करती है: प्रतिरूपकता, स्वायत्तता और खोज क्षमता: + +**1. मॉड्यूलेरिटी**: यह एक विशिष्ट कार्य करने के लिए व्यक्तिगत घटकों की क्षमता है। एथेरियम में, प्रत्येक स्मार्ट अनुबंध का एक विशिष्ट उपयोग मामला होता है (जैसा कि Uniswap उदाहरण में दिखाया गया है)। + +**2. स्वायत्तता**: कंपोज़ेबल घटकों को स्वतंत्र रूप से संचालित करने में सक्षम होना चाहिए। एथेरियम में हर स्मार्ट अनुबंध अपने-आप लागू होता है और सिस्टम के अन्य भागों पर भरोसा किए बिना कार्य कर सकता है। + +**3. खोज योग्यता**: डेवलपर्स बाहरी अनुबंधों को कॉल नहीं कर सकते हैं या सॉफ़्टवेयर लाइब्रेरी को एप्लिकेशंस में एकीकृत नहीं कर सकते हैं यदि पुराने वाले सार्वजनिक रूप से उपलब्ध नहीं हैं। डिज़ाइन के अनुसार, स्मार्ट अनुबंध खुले स्रोत हैं; कोई भी स्मार्ट अनुबंध कह सकता है या कोडबेस फ़ोर्क कर सकता है। + +## रचना के लाभ {#benefits-of-composability} + +### छोटा विकास चक्र {#shorter-development-cycle} + +कम्पोज़ेबिलिटी उस काम को कम करती है जो डेवलपर्स को [डैप्स](/dapps/#what-are-dapps) बनाते समय करना पड़ता है। [जैसा कि नवल रविकांत कहते हैं:](https://twitter.com/naval/status/1444366754650656770) "ओपन सोर्स का मतलब है कि हर समस्या को एक बार हल किया जाना चाहिए।" + +अगर कोई स्मार्ट अनुबंध है जो एक समस्या को हल करता है, तो अन्य डेवलपर्स इसका पुन: उपयोग कर सकते हैं, इसलिए उन्हें उसी समस्या को हल करने की आवश्यकता नहीं है। इस तरह, डेवलपर्स मौजूदा सॉफ़्टवेयर लाइब्रेरी ले सकते हैं और नए डेप बनाने के लिए अतिरिक्त कार्यक्षमता जोड़ सकते हैं। + +### अधिक से अधिक इनोवेशन {#greater-innovation} + +कम्पोज़ेबिलिटी इनोवेशन और प्रयोग को प्रोत्साहित करती है, क्योंकि डेवलपर्स वांछित परिणाम पाने के लिए ओपन-सोर्स कोड का फिर से उपयोग, संशोधन, डुप्लिकेट या एकीकृत करने के लिए स्वतंत्र हैं। परिणामस्वरूप, विकास दल बुनियादी कार्यक्षमता पर कम समय बिताते हैं और नई सुविधाओं के साथ प्रयोग करने में अधिक समय आवंटित कर सकते हैं। + +### बेहतर उपयोगकर्ता अनुभव {#better-user-experience} + +एथेरियम इकोसिस्टम के घटकों के बीच इंटरऑपरेबिलिटी उपयोगकर्ता अनुभव को बेहतर बनाती है। उपयोगकर्ता अधिक कार्यक्षमता का उपयोग कर सकते हैं जब डैप्स एक खंडित पारिस्थितिकी तंत्र की तुलना में बाहरी स्मार्ट अनुबंधों को एकीकृत करते हैं जहां एप्लिकेशन कम्युनिकेट नहीं कर सकते। + +हम इंटरऑपरेबिलिटी के लाभों को स्पष्ट करने के लिए आर्बिट्रेज ट्रेडिंग से एक उदाहरण का उपयोग करेंगे: + +यदि कोई टोकन `exchange B` की तुलना में `exchange A` पर अधिक ट्रेडिंग कर रहा है, तो आप लाभ कमाने के लिए मूल्य अंतर का लाभ उठा सकते हैं। हालाँकि, आप केवल तभी ऐसा कर सकते हैं जब आपके पास लेन-देन को निधि देने के लिए पर्याप्त पूंजी हो (यानी, `exchange B` से टोकन खरीदना और इसे `exchange A` पर बेचना)। + +ऐसे परिदृश्य में जहां आपके पास व्यापार को कवर करने के लिए पर्याप्त धन नहीं है, एक फ़्लैश लोन आदर्श हो सकता है। [फ्लैश ऋण](/defi/#flash-loans) अत्यधिक तकनीकी हैं, लेकिन मूल विचार यह है कि आप एसेट उधार ले सकते हैं (संपार्श्विक के बिना) और _एक_ लेनदेन के भीतर वापस कर सकते हैं। + +हमारे प्रारंभिक उदाहरण पर वापस जा रहे हैं, एक आर्बिट्रेज व्यापारी एक बड़ा फ्लैश ऋण ले सकता है, `exchange B` से टोकन खरीद सकता है, उन्हें `exchange A` पर बेच सकता है, पूंजी + ब्याज का भुगतान कर सकता है, और उसी लेनदेन के भीतर लाभ रख सकता है। इस जटिल तर्क के लिए कई अनुबंधों में कॉल के संयोजन की आवश्यकता होती है, जो स्मार्ट अनुबंधों में इंटरऑपरेबिलिटी की कमी होने पर संभव नहीं होगा। + +## एथेरियम में कम्पोज़ेबिलिटी के उदाहरण {#composability-in-ethereum} + +### टोकन स्वैप {#token-swaps} + +अगर आप एक डैप बनाते हैं जिसके लिए ETH में लेनदेन का भुगतान करने की आवश्यकता होती है, तो आप टोकन स्वैप तर्क को इंटीग्रेट करके उपयोगकर्ताओं को अन्य ERC-20 टोकन में भुगतान करने की अनुमति दे सकते हैं। अनुबंध द्वारा कॉल किए गए फ़ंक्शन को लागू करने से पहले कोड स्वचालित रूप से उपयोगकर्ता के टोकन को ETH में बदल देगा। + +### गवर्नेंस {#governance} + +[डीएओ](/dao/) के लिए बिस्पोक गवर्नेंस सिस्‍टम का निर्माण महंगा और समय लेने वाला हो सकता है। इसके बजाय, आप एक ओपन-सोर्स गवर्नेंस टूलकिट जैसे [Aragon क्लाइंट](https://client.aragon.org/) का उपयोग कर अपने डीएओ को बूटस्ट्रैप करने के लिए जल्दी से एक गवर्नेंस फ्रेमवर्क बना सकते हैं। + +### पहचान प्रबंधन {#identity-management} + +कस्टम ऑथेंटिकेशन सिस्टम बनाने या केंद्रीकृत प्रदाताओं पर भरोसा करने के बजाय, आप उपयोगकर्ताओं के लिए प्रमाणीकरण प्रबंधित करने के लिए विकेन्द्रीकृत पहचान (DID) उपकरणों को इंटीग्रेट कर सकते हैं। एक उदाहरण है [SpruceID](https://www.spruceid.com/), एक ओपन-सोर्स टूलकिट जो "एथेरियम के साथ साइन इन करें" कार्यक्षमता प्रदान करता है जो उपयोगकर्ताओं को एथेरियम वॉलेट के साथ पहचान प्रमाणित करने देता है। + +## संबंधित ट्यूटोरियल {#related-tutorials} + +- [create-eth-app के साथ अपने डैप फ्रंटएंड डेवलपमेंट को किकस्टार्ट करें](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _– आधुनिक लोकप्रिय स्मार्ट अनुबंध वाले ऐप्स बनाने के लिए create-eth-app का उपयोग करने का अवलोकन।_ + +## अग्रिम पठन {#further-reading} + +_एक सामुदायिक संसाधन के बारे में जानें, जिसने आपकी मदद की? इस पृष्ठ को संपादित करें और इसे जोड़ें!_ + +- [कम्पोज़ेबिलिटी इनोवेशन है](https://future.a16z.com/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/hi/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/hi/developers/docs/smart-contracts/formal-verification/index.md new file mode 100644 index 00000000000..02ec5291ae0 --- /dev/null +++ b/public/content/translations/hi/developers/docs/smart-contracts/formal-verification/index.md @@ -0,0 +1,283 @@ +--- +title: स्मार्ट अनुबंधों का औपचारिक सत्यापन +description: एथेरियम स्मार्ट अनुबंधों के लिए औपचारिक सत्यापन का अवलोकन +lang: hi +--- + +[स्मार्ट अनुबंध](/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) एक कम्प्यूटेशनल प्रक्रिया का गणितीय विवरण है। कार्यक्रमों को गणितीय कार्यों (समीकरणों) में सारगर्भित किया जाता है, जिसमें मॉडल का वर्णन होता है कि इनपुट दिए जाने पर कार्यों के आउटपुट की गणना कैसे की जाती है। + +औपचारिक मॉडल अमूर्तता का एक स्तर प्रदान करते हैं जिस पर किसी कार्यक्रम के व्यवहार के विश्लेषण का मूल्यांकन किया जा सकता है। औपचारिक मॉडल का अस्तित्व _औपचारिक विनिर्देश_ के निर्माण की अनुमति देता है, जो प्रश्न में मॉडल के वांछित गुणों का वर्णन करता है। + +औपचारिक सत्यापन के लिए स्मार्ट अनुबंधों के मॉडलिंग के लिए अलग-अलग तकनीकों का उपयोग किया जाता है। उदाहरण के लिए, कुछ मॉडलों का उपयोग स्मार्ट अनुबंध के उच्च-स्तरीय व्यवहार के बारे में तर्क करने के लिए किया जाता है। ये मॉडलिंग तकनीकें स्मार्ट अनुबंधों के लिए एक ब्लैक-बॉक्स दृश्य लागू करती हैं, उन्हें सिस्टम के रूप में देखती हैं जो इनपुट स्वीकार करती हैं और उन इनपुट के आधार पर गणना निष्पादित करती हैं। + +उच्च-स्तरीय मॉडल स्मार्ट अनुबंध और बाहरी एजेंटों के बीच संबंधों पर ध्यान केंद्रित करते हैं, जैसे बाहरी स्वामित्व वाले खाते (EOA), अनुबंध खाते और ब्लॉकचेन एनवायरमेंट। ऐसे मॉडल उन गुणों को परिभाषित करने के लिए उपयोगी होते हैं जो निर्दिष्ट करते हैं कि कुछ उपयोगकर्ता इंटरैक्शन के जवाब में अनुबंध को कैसे व्यवहार करना चाहिए। + +इसके विपरीत, अन्य औपचारिक मॉडल एक स्मार्ट अनुबंध के निम्न-स्तरीय व्यवहार पर ध्यान केंद्रित करते हैं। जबकि उच्च-स्तरीय मॉडल अनुबंध की कार्यक्षमता के बारे में तर्क देने में मदद कर सकते हैं, वे कार्यान्वयन के अंदरूनी कामकाज के बारे में जानकारी हासिल करने में विफल हो सकते हैं। निम्न-स्तरीय मॉडल प्रोग्राम विश्लेषण के लिए एक व्हाइट-बॉक्स दृश्य लागू करते हैं और स्मार्ट अनुबंध ऐप्लिकेशन के निचले स्तर के रिप्रजेंटेशन पर भरोसा करते हैं, जैसे कि प्रोग्राम ट्रेस और [नियंत्रण प्रवाह ग्राफ़](https://en.wikipedia.org/wiki/Control-flow_graph), जिनसे अनुबंध के निष्पादन के लिए प्रासंगिक गुणों के बारे में तर्क किया जा सके। + +निम्न-स्तरीय मॉडल को आदर्श माना जाता है क्योंकि वे एथेरियम के निष्पादन वातावरण (यानी, [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_ (यानी, कार्यक्रम) की स्थिति पर विधेय हैं, औपचारिक रूप से क्रमशः _प्रीकंडीशंस_ और _पोस्टकंडीशन_ के रूप में वर्णित हैं। + +एक पूर्व शर्त एक विधेय है जो किसी फ़ंक्शन के सही निष्पादन के लिए आवश्यक शर्तों का वर्णन करता है; अनुबंध में कॉल करने वाले उपयोगकर्ताओं को इस आवश्यकता को पूरा करना होगा। एक पोस्टकंडीशन एक विधेय है जो उस स्थिति का वर्णन करता है जिससे एक फ़ंक्शन लागू होता है अगर सही ढंग से लागू किया जाता है; उपयोगकर्ता फ़ंक्शन में कॉल करने के बाद इस स्थिति के सत्य होने की उम्मीद कर सकते हैं। होरे लॉजिक में एक _इनवेरिएंट_ एक विधेय है जिसे किसी फ़ंक्शन के निष्पादन द्वारा संरक्षित किया जाता है (यानी, यह नहीं बदलता है)। + +होरे-शैली के विनिर्देश या तो _आंशिक शुद्धता_ या _कुल शुद्धता_ की गारंटी दे सकते हैं। अनुबंध संबंधी फ़ंक्शन को लागू करना "आंशिक रूप से सही है" अगर फ़ंक्शन लागू होने से पहले पूर्व शर्त सही है, और अगर यह प्रक्रिया समाप्त हो जाती है, तो पोस्टकंडीशन भी सत्य है। कुल शुद्धता का प्रमाण प्राप्त किया जाता है अगर फ़ंक्शन निष्पादित होने से पहले एक पूर्व शर्त सत्य है, तो निष्पादन को समाप्त करने की गारंटी दी जाती है और जब ऐसा होता है, तो पोस्टकंडीशन सत्य होती है। + +कुल शुद्धता का प्रमाण प्राप्त करना मुश्किल है क्योंकि कुछ निष्पादन समाप्त होने से पहले देरी कर सकते हैं, या कभी भी समाप्त नहीं हो सकते। उसने कहा, यह सवाल कि क्या निष्पादन समाप्त हो जाता है, यकीनन एक विवादास्पद बिंदु है, क्योंकि एथेरियम का गैस तंत्र अनंत प्रोग्राम लूप को रोकता है (लागू करने की प्रक्रिया या तो सफलतापूर्वक समाप्त हो जाता है या 'आउट-ऑफ-गैस' गड़बड़ी के कारण समाप्त होती है)। + +होरे लॉजिक का उपयोग करके बनाए गए स्मार्ट अनुबंध विनिर्देशों में अनुबंध में कार्यों और छोरों के निष्पादन के लिए परिभाषित पूर्व शर्तें, पोस्टकंडीशन और इनवेरिएंट होंगे। पूर्व शर्तों में अक्सर किसी फ़ंक्शन के लिए गलत इनपुट की संभावना शामिल होती है, जिसमें पोस्टकंडीशन ऐसे इनपुट के लिए अपेक्षित प्रतिक्रिया का वर्णन करते हैं (उदाहरण के लिए, एक विशिष्ट अपवाद फेंकना)। इस तरीके से अनुबंध कार्यान्वयन की शुद्धता सुनिश्चित करने के लिए होरे-शैली के गुण प्रभावी हैं। + +कई औपचारिक सत्यापन ढांचे कार्यों की सिमेंटिक शुद्धता साबित करने के लिए होरे-शैली विनिर्देशों का उपयोग करते हैं। Solidity में `require` और `assert` स्टेटमेंट का उपयोग करके सीधे अनुबंध कोड में होरे-स्टाइल गुणों (दावे के रूप में) को जोड़ना भी संभव है। + +`require` स्टेटमेंट एक प्रीकंडीशन या अपरिवर्तनीय व्यक्त करते हैं और अक्सर उपयोगकर्ता इनपुट को मान्य करने के लिए उपयोग किए जाते हैं, जबकि `assert` सुरक्षा के लिए आवश्यक पोस्टकंडीशन को कैप्चर करता है। उदाहरण के लिए, कार्यों के लिए उचित अभिगम नियंत्रण (सुरक्षा विशेषता का एक उदाहरण) कॉलिंग खाते की पहचान पर पूर्व शर्त जांच के रूप में `require` का उपयोग करके प्राप्त किया जा सकता है। इसी तरह, एक अनुबंध में स्टेट वेरिएबल के अनुमेय मानों पर एक अपरिवर्तनीय (उदाहरण के लिए, प्रचलन में टोकन की कुल संख्या) को फ़ंक्शन निष्पादन के बाद अनुबंध की स्थिति की पुष्टि करने के लिए `assert` का उपयोग करके उल्लंघन से बचाया जा सकता है। + +### ट्रेस-स्तर गुण {#trace-level-properties} + +ट्रेस-आधारित विनिर्देश उन कार्रवाइयों का वर्णन करते हैं जो विभिन्न राज्यों और इन कार्रवाइयों के बीच संबंधों के बीच एक अनुबंध को लागू करते हैं। जैसा कि पहले बताया गया है, निशान संचालन के अनुक्रम हैं जो एक विशेष तरीके से अनुबंध की स्थिति को बदलते हैं। + +यह दृष्टिकोण पूर्वनिर्धारित संक्रमण (अनुबंध के कार्यों द्वारा वर्णित) के एक सेट के साथ कुछ पूर्वनिर्धारित राज्यों (राज्य चर द्वारा वर्णित) के साथ स्टेट-ट्रांज़िशन सिस्टम के रूप में स्मार्ट अनुबंधों के मॉडल पर निर्भर करता है। इसके अलावा, एक [नियंत्रण प्रवाह ग्राफ](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) (CFG), जो एक कार्यक्रम के निष्पादन प्रवाह का एक चित्रमय प्रतिनिधित्व है, अक्सर एक अनुबंध के परिचालन शब्दार्थ का वर्णन करने के लिए उपयोग किया जाता है। यहां, प्रत्येक ट्रेस को नियंत्रण प्रवाह ग्राफ पर पथ के रूप में दर्शाया गया है। + +मुख्य रूप से, ट्रेस-स्तरीय विनिर्देशों का उपयोग स्मार्ट अनुबंधों में आंतरिक निष्पादन के पैटर्न के बारे में तर्क करने के लिए किया जाता है। ट्रेस-स्तरीय विनिर्देशों का निर्माण करके, हम एक स्मार्ट अनुबंध के लिए स्वीकार्य निष्पादन पथ (यानी, स्टेट ट्रांज़िशन) पर ज़ोर देते हैं। प्रतीकात्मक निष्पादन जैसी तकनीकों का उपयोग करके, हम औपचारिक रूप से सत्यापित कर सकते हैं कि निष्पादन कभी भी औपचारिक मॉडल में परिभाषित पथ का अनुसरण नहीं करता। + +आइए [डीएओ](/dao/) अनुबंध का एक उदाहरण उपयोग करें जिसमें ट्रेस-स्तरीय गुणों का वर्णन करने के लिए कुछ सार्वजनिक रूप से सुलभ कार्य हैं। यहां, हम मानते हैं कि डीएओ अनुबंध उपयोगकर्ताओं को निम्नलिखित काम करने की अनुमति देता है: + +- धनराशि जमा करें + +- धन जमा करने के बाद प्रस्ताव पर मतदान करें + +- अगर वे किसी प्रस्ताव पर मतदान नहीं करते हैं, तो धनवापसी का दावा करें + +उदाहरण ट्रेस-स्तरीय गुण _"उपयोगकर्ता जो धन जमा नहीं करते हैं, वे प्रस्ताव पर मतदान नहीं कर सकते हैं"_ या _"उपयोगकर्ता जो किसी प्रस्ताव पर मतदान नहीं करते हैं, उन्हें हमेशा धनवापसी का दावा करने में सक्षम होना चाहिए"_। दोनों गुण निष्पादन के पसंदीदा अनुक्रमों पर जोर देते हैं (धन जमा करने से _पहले_ मतदान नहीं हो सकता है और धनवापसी का दावा किसी प्रस्ताव पर मतदान के _बाद_ नहीं हो सकता है)। + +## स्मार्ट अनुबंधों के औपचारिक सत्यापन के लिए तकनीक {#formal-verification-techniques} + +### मॉडल जाँच {#model-checking} + +मॉडल जाँच एक औपचारिक सत्यापन तकनीक है जिसमें एक एल्गोरिथ्म अपने विनिर्देश के खिलाफ एक स्मार्ट अनुबंध के औपचारिक मॉडल की जांच करता है। मॉडल की जाँच में स्मार्ट अनुबंधों को अक्सर राज्य-संक्रमण प्रणाली के रूप में दर्शाया जाता है, जबकि अनुमेय अनुबंध राज्यों पर गुणों को अस्थायी तर्क का उपयोग करके परिभाषित किया जाता है। + +मॉडल जाँच के लिए एक प्रणाली (यानी, एक अनुबंध) का एक अमूर्त गणितीय प्रतिनिधित्व बनाने और [प्रस्तावात्मक तर्क](https://www.baeldung.com/cs/propositional-logic) में निहित सूत्रों का उपयोग करके इस प्रणाली के गुणों को व्यक्त करने की आवश्यकता होती है। यह मॉडल-चेकिंग एल्गोरिथ्म के कार्य को सरल करता है, अर्थात् यह साबित करने के लिए कि एक गणितीय मॉडल किसी दिए गए तार्किक सूत्र को संतुष्ट करता है। + +औपचारिक सत्यापन में मॉडल जाँच मुख्य रूप से अस्थायी गुणों का मूल्यांकन करने के लिए उपयोग की जाती है जो समय के साथ अनुबंध के काम करने के तरीके के बारे में बताते हैं। स्मार्ट अनुबंधों के लिए अस्थायी गुणों में _सुरक्षा_ और _जीवंतता_ शामिल हैं, जिन्हें हमने पहले समझाया था। + +उदाहरण के लिए, अभिगम नियंत्रण से संबंधित एक सुरक्षा विशेषता (उदाहरण के लिए, _केवल अनुबंध का स्वामी `selfdestruct` को कॉल कर सकता है_) को औपचारिक तर्क में लिखा जा सकता है। इसके बाद, मॉडल-चेकिंग एल्गोरिथ्म यह सत्यापित कर सकता है कि अनुबंध इस औपचारिक विनिर्देश को पूरा करता है या नहीं। + +मॉडल चेकिंग राज्य अंतरिक्ष अन्वेषण का उपयोग करता है, जिसमें एक स्मार्ट अनुबंध के सभी संभावित राज्यों का निर्माण करना और पहुंच योग्य राज्यों को खोजने की कोशिश करना शामिल है जिसकी वजह से संपत्ति का उल्लंघन होता है। हालांकि, इससे अनंत संख्या में राज्य ("राज्य विस्फोट समस्या" के रूप में जाना जाता है) हो सकता है, इसलिए मॉडल चेकर्स स्मार्ट अनुबंधों के कुशल विश्लेषण को संभव बनाने के लिए अमूर्त तकनीकों पर भरोसा करते हैं। + +### प्रमेय साबित करना {#theorem-proving} + +प्रमेय साबित करना स्मार्ट अनुबंधों सहित कार्यक्रमों की शुद्धता के बारे में गणितीय रूप से तर्क करने का एक तरीका है। इसमें एक अनुबंध की प्रणाली के मॉडल और इसके विनिर्देशों को गणितीय सूत्रों (तर्क के साथ कथन) में बदलना शामिल है। + +प्रमेय साबित करने का उद्देश्य इन कथनों के बीच तार्किक तुलना को सत्यापित करना है। तार्किक तुल्यता (जिसे "तार्किक द्वि-निहितार्थ" भी कहा जाता है) दो स्टेटमेंट के बीच एक प्रकार का संबंध है जैसे कि पहला स्टेटमेंट ट्रू है _if and only if_ दूसरा स्टेटमेंट ट्रू है। + +एक अनुबंध के मॉडल और इसकी संपत्ति के बारे में बयानों के बीच आवश्यक संबंध (तार्किक तुल्यता) को एक सिद्ध कथन (प्रमेय कहा जाता है) के रूप में तैयार किया जाता है। अनुमान की एक औपचारिक प्रणाली का उपयोग करके, स्वचालित प्रमेय प्रोवर प्रमेय की वैधता को सत्यापित कर सकता है। दूसरे शब्दों में, एक प्रमेय प्रोवर निर्णायक रूप से साबित कर सकता है कि एक स्मार्ट अनुबंध का मॉडल इसके विनिर्देशों से सटीक रूप से मेल खाता है। + +जबकि मॉडल की जाँच मॉडल परिमित स्टेट के साथ ट्रांज़िशन सिस्टम के रूप में अनुबंध करते हैं, प्रमेय साबित करना अनंत-राज्य प्रणालियों के विश्लेषण को संभाल सकता है। हालांकि, इसका मतलब है कि एक स्वचालित प्रमेय प्रोवर हमेशा यह नहीं जान सकता है कि तर्क संबंधी समस्या "निर्णायक" है या नहीं। + +इस वजह से, शुद्धता प्रमाण प्राप्त करने में प्रमेय प्रोवर का मार्गदर्शन करने के लिए अक्सर मानव सहायता की आवश्यकता होती है। प्रमेय साबित करने में मानव प्रयास का उपयोग मॉडल जाँच की तुलना में उपयोग करना अधिक महंगा बनाता है, जो पूरी तरह से स्वचालित है। + +### प्रतीकात्मक निष्पादन {#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/)। औपचारिक रूप से तैनाती से पहले एक अनुबंध की पुष्टि करना, हालांकि, गारंटी बढ़ा सकता है कि यह ब्लॉकचेन पर चलने के बाद उम्मीद के मुताबिक परफ़ॉर्मेंस देगा। + +विश्वसनीयता किसी भी स्मार्ट अनुबंध में एक बहुत ज़्यादा ज़रूरी गुणवत्ता है, खासकर क्योंकि एथेरियम वर्चुअल मशीन (EVM) में डिप्लॉय किया गया कोड आमतौर पर अपरिवर्तनीय होता है। लॉन्च के बाद के अपग्रेड आसानी से सुलभ नहीं होने के कारण, अनुबंधों की विश्वसनीयता की गारंटी देने की आवश्यकता औपचारिक सत्यापन को आवश्यक बनाती है। औपचारिक सत्यापन मुश्किल मुद्दों का पता लगाने में सक्षम है, जैसे इंटीजर अंडरफ़्लो और ओवरफ़्लो, पुन: प्रवेश, और खराब गैस अनुकूलन, जो पिछले लेखा परीक्षकों और परीक्षकों को फिसल सकते हैं। + +#### कार्यात्मक शुद्धता साबित करें {#prove-functional-correctness} + +कार्यक्रम परीक्षण यह साबित करने का सबसे आम तरीका है कि एक स्मार्ट अनुबंध कुछ आवश्यकताओं को पूरा करता है। इसमें डेटा के नमूने के साथ एक अनुबंध निष्पादित करना शामिल है जिसे इसके व्यवहार को प्रबंधित करने और विश्लेषण करने की उम्मीद है। अगर अनुबंध के हिसाब से नमूना वाले डेटा के लिए अपेक्षित परिणाम देता है, तो डेवलपर्स के पास इसकी शुद्धता का असल प्रमाण होता है। + +हालाँकि, यह प्रकिया उन इनपुट मानों के लिए सही निष्पादन सिद्ध नहीं कर सकता जो नमूने का भाग नहीं हैं। इसलिए, एक अनुबंध का परीक्षण बग का पता लगाने में मदद कर सकता है (यानी, यदि कुछ कोड पथ निष्पादन के दौरान वांछित परिणाम वापस करने में विफल रहते हैं), लेकिन **यह बग की अनुपस्थिति को निर्णायक रूप से साबित नहीं कर सकता है**। + +इसके विपरीत, औपचारिक सत्यापन औपचारिक रूप से साबित कर सकता है कि एक स्मार्ट अनुबंध किसी अनुबंध को चलाने के _बिना_ निष्पादन की अनंत श्रेणी के लिए आवश्यकताओं को पूरा करता है। इसके लिए एक औपचारिक विनिर्देश बनाने की आवश्यकता होती है जो अनुबंध के काम करने के सही तरीके का सटीक वर्णन करता है और अनुबंध की प्रणाली का एक औपचारिक (गणितीय) मॉडल विकसित करता है। फिर हम अनुबंध के मॉडल और इसके विनिर्देश के बीच स्थिरता की जांच के लिए प्रमाण की एक औपचारिक प्रक्रिया का पालन कर सकते हैं। + +औपचारिक सत्यापन के साथ, यह सत्यापित करने का प्रश्न कि क्या अनुबंध का व्यावसायिक तर्क आवश्यकताओं को पूरा करता है, एक गणितीय प्रस्ताव है जिसे साबित या अस्वीकृत किया जा सकता है। औपचारिक रूप से एक प्रस्ताव साबित करके, हम चरणों की एक सीमित संख्या के साथ परीक्षण संबंधी मामलों की एक अनंत संख्या को सत्यापित कर सकते हैं। इस तरीके से औपचारिक सत्यापन में यह साबित करने की बेहतर संभावनाएं हैं कि अनुबंध एक विनिर्देश के संबंध में कार्यात्मक रूप से सही है। + +#### आदर्श सत्यापन संबंधी लक्ष्य {#ideal-verification-targets} + +एक सत्यापन लक्ष्य औपचारिक रूप से सत्यापित किए जाने वाले सिस्टम के बारे में बताता है। औपचारिक सत्यापन का सबसे अच्छा उपयोग "एम्बेडेड सिस्टम" (सॉफ़्टवेयर के छोटे, सरल टुकड़े जो एक बड़ी प्रणाली का हिस्सा बनते हैं) में किया जाता है। वे विशेष डोमेन के लिए भी आदर्श हैं जिनके कुछ नियम हैं, क्योंकि इससे डोमेन-विशिष्ट गुणों को सत्यापित करने के लिए उपकरणों में बदलाव करना आसान हो जाता है। + +स्मार्ट अनुबंध-कम से कम, कुछ हद तक-दोनों आवश्यकताओं को पूरा करते हैं। उदाहरण के लिए, एथेरियम अनुबंधों का छोटा आकार उन्हें औपचारिक सत्यापन के लिए उत्तरदायी बनाता है। इसी तरह EVM सरल नियमों का पालन करती है, जो EVM में चल रहे प्रोग्राम के लिए सिमेंटिक गुणों को निर्दिष्ट और सत्यापित करना आसान बनाता है। + +### तेजी से विकास चक्र {#faster-development-cycle} + +औपचारिक सत्यापन तकनीक, जैसे मॉडल जांच और प्रतीकात्मक निष्पादन, आमतौर पर स्मार्ट अनुबंध कोड के नियमित विश्लेषण (परीक्षण या ऑडिटिंग के दौरान निष्पादित) की तुलना में अधिक कुशल होते हैं। ऐसा इसलिए है क्योंकि औपचारिक सत्यापन दावों का परीक्षण करने के लिए प्रतीकात्मक मूल्यों पर निर्भर करता है ("क्या होगा यदि कोई उपयोगकर्ता _n_ ईथर वापस लेने का प्रयास करता है?") परीक्षण के विपरीत जो ठोस मूल्यों का उपयोग करता है ("क्या होगा अगर कोई उपयोगकर्ता 5 ईथर वापस लेने की कोशिश करता है?")। + +प्रतीकात्मक इनपुट चर ठोस मूल्यों के कई वर्गों को कवर कर सकते हैं, इसलिए औपचारिक सत्यापन दृष्टिकोण कम समय सीमा में अधिक कोड कवरेज का वादा करते हैं। जब प्रभावी ढंग से उपयोग किया जाता है, तो औपचारिक सत्यापन डेवलपर्स के लिए विकास चक्र को तेज कर सकता है। + +औपचारिक सत्यापन महंगे डिज़ाइन से जुड़ी गड़बड़ियों को कम करके विकेन्द्रीकृत अनुप्रयोगों (डैप्स) के निर्माण की प्रक्रिया में भी सुधार करता है। कमजोरियों को ठीक करने के लिए अनुबंधों (जहां संभव हो) को अपग्रेड करने के लिए कोडबेस के व्यापक पुनर्लेखन और विकास पर अधिक प्रयास की आवश्यकता होती है। औपचारिक सत्यापन अनुबंध को लागू करने में कई गड़बड़ियों का पता लगा सकता है जिससे पिछले परीक्षक और लेखा परीक्षक छूट सकते हैं और अनुबंध को डिप्लॉय करने से पहले उन मुद्दों को ठीक करने के पर्याप्त अवसर मिलते हैं। + +## औपचारिक सत्यापन की कमियां {#drawbacks-of-formal-verification} + +### मैन्युअल श्रम की लागत {#cost-of-manual-labor} + +औपचारिक सत्यापन, विशेष रूप से अर्ध-स्वचालित सत्यापन जिसमें एक मानव शुद्धता प्रमाण प्राप्त करने के लिए प्रोवर का मार्गदर्शन करता है, इसके लिए काफी मैन्युअल श्रम की आवश्यकता होती है। इसके अलावा, औपचारिक विनिर्देश बनाना एक जटिल गतिविधि है जो उच्च स्तर के कौशल की मांग करती है। + +ये कारक (प्रयास और कौशल) औपचारिक सत्यापन को अनुबंधों में शुद्धता का आकलन करने के सामान्य तरीकों की तुलना में अधिक मांग और महंगा बनाते हैं, जैसे कि परीक्षण और ऑडिट। फिर भी, स्मार्ट अनुबंध कार्यान्वयन में गड़बड़ियों की लागत को देखते हुए, पूर्ण सत्यापन ऑडिट के लिए लागत का भुगतान करना व्यावहारिक है। + +### झूठी नकारात्मकता {#false-negatives} + +औपचारिक सत्यापन केवल यह जांच सकता है कि स्मार्ट अनुबंध का निष्पादन औपचारिक विनिर्देश से मेल खाता है या नहीं। जैसे, यह सुनिश्चित करना महत्वपूर्ण है कि विनिर्देश एक स्मार्ट अनुबंध के अपेक्षित व्यवहार के बारे में ठीक से बताता है। + +अगर विनिर्देशों को खराब तरीके से लिखा गया हो, तो संपत्तियों का उल्लंघन - जो कमजोर निष्पादन की ओर इशारा करता है - औपचारिक सत्यापन वाले ऑडिट द्वारा पता नहीं लगाया जा सकता। इस मामले में, एक डेवलपर गलती से मान सकता है कि अनुबंध बग-मुक्त है। + +### परफ़ॉर्मेंस से जुड़ी समस्याएँ {#performance-issues} + +औपचारिक सत्यापन परफ़ॉर्मेंस से जुड़ी कई समस्याओं में चलता है। उदाहरण के लिए, मॉडल जाँच और प्रतीकात्मक जाँच के दौरान खासकर राज्य और पथ विस्फोट की समस्याएँ सत्यापन प्रक्रियाओं को प्रभावित कर सकती हैं। इसके अलावा, औपचारिक सत्यापन उपकरण अक्सर अपनी अंतर्निहित परत में SMT सॉल्वर और अन्य बाधा सॉल्वर का उपयोग करते हैं और ये सॉल्वर कम्प्यूटेशनल रूप से गहन प्रक्रियाओं पर भरोसा करते हैं। + +साथ ही, प्रोग्राम सत्यापनकर्ताओं के लिए यह निर्धारित करना हमेशा संभव नहीं होता है कि कोई गुण (तार्किक सूत्र के रूप में वर्णित) संतुष्ट हो सकता है या नहीं ("[निर्णायकता समस्या](https://en.wikipedia.org/wiki/Decision_problem)") क्योंकि कोई प्रोग्राम कभी समाप्त नहीं हो सकता है। जैसे, अनुबंध के लिए कुछ गुणों को साबित करना असंभव हो सकता है, भले ही यह अच्छी तरह से निर्दिष्ट हो। + +## एथेरियम स्मार्ट अनुबंधों के लिए औपचारिक सत्यापन संबंधी उपकरण {#formal-verification-tools} + +### औपचारिक विनिर्देश बनाने के लिए विशिष्टता भाषाएं {#specification-languages} + +**Act**: _*Act स्टोरेज अपडेट, पूर्व पोस्ट शर्तों और अनुबंध वेरिएंट के विनिर्देश की अनुमति देता है। इसके टूल सूट में Coq, SMT सॉल्वर, या hevm के माध्यम से कई गुणों को साबित करने में सक्षम प्रूफ बैकएंड भी हैं।** + +- [GitHub](https://github.com/ethereum/act) +- [दस्तावेज़ीकरण](https://ethereum.github.io/act/) + +**Scribble** - _*Scribble विनिर्देश भाषा में कोड एनोटेशन को कंक्रीट असर्शन में बदल देता है जो विनिर्देश की जाँच करते हैं।** + +- [प्रलेखन](https://docs.scribble.codes/) + +**Dafny** - _*Dafny एक सत्यापन-तैयार प्रोग्रामिंग भाषा है जो कोड की शुद्धता के बारे में तर्क करने और साबित करने के लिए उच्च-स्तरीय एनोटेशन पर निर्भर करती है।** + +- [GitHub](https://github.com/dafny-lang/dafny) + +### शुद्धता की जांच के लिए कार्यक्रम सत्यापनकर्ता {#program-verifiers} + +**Certora Prover** - _Certora Prover स्मार्ट अनुबंधों में कोड शुद्धता की जाँच के लिए एक स्वचालित औपचारिक सत्यापन टूल है। विनिर्देश CVL (सर्टोसा वेरिफिकेशन लैंग्वेज) में लिखे गए हैं, जिसमें स्थिर विश्लेषण और बाधा-समाधान के संयोजन का उपयोग करके विशेषता के उल्लंघन का पता लगाया गया है।_ + +- [वेबसाइट](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 फ्रेमवर्क में लिखे गए एथेरियम वर्चुअल मशीन (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) + +**Coq** - _Coq एक इंटरैक्टिव थ्योरम प्रोवर है जो आपको थ्योरम्स का उपयोग करके प्रोग्राम को निर्धारित करने की सुविधा देता है और अंतःक्रियात्मक रूप से शुद्धता के मशीन-चेक किए गए प्रमाण उत्पन्न करता है।_ + +- [GitHub](https://github.com/coq/coq) +- [दस्तावेज़ीकरण](https://coq.github.io/doc/v8.13/refman/index.html) + +### स्मार्ट अनुबंधों में कमजोर पैटर्न का पता लगाने के लिए प्रतीकात्मक निष्पादन-आधारित उपकरण {#symbolic-execution-tools} + +**Manticore** - _*प्रतीकात्मक निष्पादन के आधार पर EVM बाइटकोड विश्लेषण टूल के विश्लेषण के लिए एक टूल*।* + +- [GitHub](https://github.com/trailofbits/manticore) +- [दस्तावेज़ीकरण](https://github.com/trailofbits/manticore/wiki) + +**hevm** - _*hevm एक प्रतीकात्मक निष्पादन इंजन है और EVM बाइटकोड के लिए इक्विलिवेलेंस चेकर है।** + +- [गिटहब](https://github.com/dapphub/dapptools/tree/master/src/hevm) + +**Mythril** - _एथेरियम स्मार्ट अनुबंधों में कमजोरियों का पता लगाने के लिए एक प्रतीकात्मक निष्पादन टूल_ + +- [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) +- [एथेरियम इकोसिस्टम में औपचारिक सत्यापन परियोजनाओं का अवलोकन](https://github.com/leonardoalt/ethereum_formal_verification_overview) +- [एथेरियम 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/hi/developers/docs/smart-contracts/testing/index.md b/public/content/translations/hi/developers/docs/smart-contracts/testing/index.md new file mode 100644 index 00000000000..532056161e9 --- /dev/null +++ b/public/content/translations/hi/developers/docs/smart-contracts/testing/index.md @@ -0,0 +1,308 @@ +--- +title: स्मार्ट अनुबंधों का परीक्षण +description: एथेरियम स्मार्ट अनुबंधों के परीक्षण के लिए तकनीकों और विचारों का अवलोकन। +lang: hi +--- + +एथेरियम जैसी सार्वजनिक ब्लॉकचेन अपरिवर्तनीय हैं, जिससे डिप्लॉय करने के बाद स्मार्ट अनुबंध कोड को बदलना मुश्किल हो जाता है। "वर्चुअल अपग्रेड" करने के लिए [कॉन्ट्रैक्ट अपग्रेड पैटर्न](/developers/docs/smart-contracts/upgrading/) मौजूद हैं, लेकिन इन्हें लागू करना मुश्किल है और इनके लिए सामाजिक सहमति आवश्यक होती है। इसके अलावा, एक अपग्रेड केवल एक त्रुटि को ठीक कर सकता है _जब_ इसे खोजा जाता है - यदि कोई हमलावर भेद्यता का पता पहले लगाता है, तो आपके स्मार्ट अनुबंध को शोषण का खतरा होता है। + +इन कारणों से, मेननेट पर [लागू](/developers/docs/smart-contracts/deploying/) किए जाने से पहले स्मार्ट अनुबंधों का परीक्षण करना [सुरक्षा](/developers/docs/smart-contracts/security/) के लिए एक न्यूनतम अर्हता है। अनुबंधों का परीक्षण करने और कोड शुद्धता का मूल्यांकन करने के लिए कई तकनीकें हैं; आप जो चुनते हैं वह आपकी आवश्यकताओं पर निर्भर करता है। फिर भी, अलग-अलग उपकरणों और दृष्टिकोणों से बना एक परीक्षण सूट, अनुबंध कोड से जुड़ी मामूली और प्रमुख सुरक्षा खामियों दोनों को पकड़ने के लिए आदर्श है। + +## आवश्यक शर्तें {#prerequisites} + +यह पेज बताता है कि एथेरियम नेटवर्क पर डिप्लॉय करने से पहले स्मार्ट अनुबंधों का परीक्षण कैसे करें। यह मानता है कि आप [स्मार्ट अनुबंध](/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/) पहुंचा सकती हैं और अक्सर हो सकती हैं हालांकि, कठोर परीक्षण आपको स्मार्ट अनुबंध के कोड में गड़बड़ियों और मुद्दों को जल्दी खोजने और मेननेट पर लॉन्च करने से पहले उन्हें ठीक करने में मदद कर सकता है। + +हालांकि बग का पता चलने पर अनुबंध को अपग्रेड करना संभव है, अपग्रेड जटिल हैं और अनुचित तरीके से संभालने पर [परिणाम त्रुटियां](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/) हो सकती हैं। एक अनुबंध को अपग्रेड करना अपरिवर्तनीयता के सिद्धांत को और नकारता है और उपयोगकर्ताओं के लिए विश्वास की अतिरिक्त मान्यताओं का बोझ बढ़ाता है। इसके विपरीत, आपके अनुबंध के परीक्षण के लिए एक व्यापक योजना स्मार्ट अनुबंध सुरक्षा जोखिमों को कम करती है और डिप्लॉय करने के बाद जटिल तर्क लागू करने की आवश्यकता को कम करती है। + +## स्मार्ट अनुबंधों का परीक्षण करने के तरीके {#methods-for-testing-smart-contracts} + +एथेरियम स्मार्ट अनुबंधों के परीक्षण के तरीके दो व्यापक श्रेणियों के अंतर्गत आते हैं: **स्वचालित परीक्षण** और **मैन्युअल परीक्षण**। स्वचालित परीक्षण और मैन्युअल परीक्षण अद्वितीय लाभ और ट्रेडऑफ़ प्रदान करते हैं, लेकिन आप अपने अनुबंधों के विश्लेषण के लिए एक मज़बूत योजना बनाने के लिए दोनों को जोड़ सकते हैं। + +### स्वचालित परीक्षण {#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) के इस (संक्षिप्त) उदाहरण का उपयोग करके समझाएंगे + +``` +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) एक परीक्षण मीट्रिक है जो परीक्षणों के दौरान निष्पादित आपके कोड में शाखाओं, रेखाओं और स्टेटमेंट की संख्या को ट्रैक करता है। टेस्ट में अच्छा कोड कवरेज होना चाहिए, अन्यथा आपको "झूठी नकारात्मक" मिल सकती है जो एक अनुबंध सभी परीक्षणों को पास करता है, लेकिन कोड में कमजोरियां अब भी मौजूद हैं। उच्च कोड कवरेज रिकॉर्डिंग, हालांकि, आश्वासन देता है कि एक स्मार्ट अनुबंध में सभी बयानों/कार्यों का शुद्धता के लिए पर्याप्त रूप से परीक्षण किया गया था। + +##### 4. अच्छी तरह से विकसित टेस्टिंग फ़्रेमवर्क का उपयोग करें + +आपके स्मार्ट अनुबंधों के लिए यूनिट परीक्षण चलाने में उपयोग किए जाने वाले उपकरणों की गुणवत्ता महत्वपूर्ण है। एक आदर्श टेस्टिंग फ़्रेमवर्क वह है जिसे नियमित रूप से बनाए रखा जाता है; उपयोगी सुविधाएं प्रदान करता है (जैसे, लॉगिंग और रिपोर्टिंग संबंधी क्षमताएं); और अन्य डेवलपर्स द्वारा बड़े पैमाने पर उपयोग और सत्यापित किया जाना चाहिए। + +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) जैसे टूल का उपयोग करना और अपने अनुबंध और लागू अनुबंधों के बीच इंटरैक्शन को सिम्युलेट करना। + +फ़ोर्कड ब्लॉकचेन मेननेट के समान व्यवहार करेगा और उसके पास संबंधित स्टेट्स और शेष राशि के साथ खाते होंगे। हालांकि, यह केवल सैंडबॉक्स किए गए लोकल डेवपलमेंट इनवायरमेंट के रूप में कार्य करता है, जिसका अर्थ है कि आपको लेनदेन के लिए वास्तविक ETH की आवश्यकता नहीं होगी, उदाहरण के लिए, न ही आपके परिवर्तन वास्तविक एथेरियम प्रोटोकॉल को प्रभावित करेंगे। + +### संपत्ति आधारित परीक्षण {#property-based-testing-for-smart-contracts} + +संपत्ति-आधारित परीक्षण यह जांचने की प्रक्रिया है कि एक स्मार्ट अनुबंध कुछ परिभाषित संपत्ति को संतुष्ट करता है। गुण एक अनुबंध के व्यवहार के बारे में तथ्यों पर जोर देते हैं जो विभिन्न परिदृश्यों में सच रहने की उम्मीद करते हैं - एक स्मार्ट अनुबंध संपत्ति का एक उदाहरण "अनुबंध में अंकगणितीय संचालन कभी भी अतिप्रवाह या अंडरफ़्लो नहीं हो सकता।" + +**स्टैटिक विश्लेषण** और **डायनेमिक विश्लेषण** विशेषता-आधारित परीक्षण निष्पादित करने के लिए दो सामान्य तकनीकें हैं और दोनों यह सत्यापित कर सकते हैं कि प्रोग्राम के लिए कोड (इस मामले में एक स्मार्ट अनुबंध) कुछ पूर्वनिर्धारित विशेषता पर खरा उतरता है। कुछ प्रॉपर्टी-आधारित परीक्षण उपकरण अपेक्षित अनुबंध गुणों के बारे में पहले से तय नियमों के साथ आते हैं और उन नियमों के विरुद्ध कोड की जांच करते हैं, जबकि अन्य आपको स्मार्ट अनुबंध के लिए कस्टम गुण बनाने की अनुमति देते हैं। + +#### स्थैतिक विश्लेषण {#static-analysis} + +एक स्थिर विश्लेषक एक स्मार्ट अनुबंध के स्रोत कोड को इनपुट के रूप में लेता है और यह घोषित करने वाले परिणामों को आउटपुट करता है कि कोई अनुबंध किसी संपत्ति को संतुष्ट करता है या नहीं। गतिशील विश्लेषण के विपरीत, स्थिर विश्लेषण में शुद्धता के लिए इसका विश्लेषण करने के लिए अनुबंध निष्पादित करना शामिल नहीं है। इसके बजाय स्थैतिक विश्लेषण उन सभी संभावित रास्तों के बारे में कारण बताता है जो एक स्मार्ट अनुबंध निष्पादन के दौरान ले सकता है (यानी, स्रोत कोड की संरचना की जांच करके यह निर्धारित करने के लिए कि रनटाइम पर अनुबंध संचालन के लिए इसका क्या अर्थ होगा)। + +[लिंटिंग](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important) और [स्‍टैटिक परीक्षण](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://halborn.com/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/building-secure-contracts/tree/master/program-analysis/slither#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} + +जबकि स्थानीय विकास वातावरण में किए गए स्वचालित परीक्षण उपयोगी डिबगिंग जानकारी प्रदान कर सकते हैं, आप जानना चाहेंगे कि आपका स्मार्ट अनुबंध उत्पादन वातावरण में कैसे व्यवहार करता है। हालांकि, मुख्य एथेरियम श्रृंखला में तैनाती करने से गैस शुल्क लगता है - यह उल्लेख नहीं करने के लिए कि आप या आपके उपयोगकर्ता वास्तविक धन खो सकते हैं, अगर आपके स्मार्ट अनुबंध में अभी भी बग हैं। + +स्थानीय ब्लॉकचेन पर अपने अनुबंध का परीक्षण करना (जिसे [डेवलपमेंट नेटवर्क](/developers/docs/development-networks/) के रूप में भी जाना जाता है), मेननेट पर परीक्षण के लिए एक अनुशंसित विकल्प है। एक स्थानीय ब्लॉकचेन आपके कंप्यूटर पर स्थानीय रूप से चलने वाले एथेरियम ब्लॉकचेन की एक कॉपी है जो एथेरियम की निष्पादन परत के व्यवहार का अनुकरण करता है। जैसे, आप महत्वपूर्ण ओवरहेड के बिना अनुबंध के साथ इंटरैक्ट करने के लिए लेनदेन प्रोग्राम कर सकते हैं। + +स्थानीय ब्लॉकचेन पर अनुबंध चलाना मैन्युअल एकीकरण परीक्षण के रूप में उपयोगी हो सकता है। [स्मार्ट अनुबंध अत्यधिक कंपोज़ेबल हैं](/developers/docs/smart-contracts/composability/), जिससे आप मौजूदा प्रोटोकॉल के साथ एकीकृत कर सकते हैं—लेकिन आपको अभी भी यह सुनिश्चित करने की आवश्यकता होगी कि इस तरह के जटिल ऑन-चेन इंटरैक्शन सही परिणाम उत्पन्न करें। + +[विकास नेटवर्क पर अधिक।](/developers/docs/development-networks/) + +### टेस्टनेट पर परीक्षण अनुबंध {#testing-contracts-on-testnets} + +एक परीक्षण नेटवर्क या टेस्टनेट बिल्कुल एथेरियम मेननेट की तरह काम करता है, सिवाय इसके कि यह बिना किसी वास्तविक दुनिया के मूल्य के ईथर (ETH) का उपयोग करता है। अपने अनुबंध को [टेस्टनेट](/developers/docs/networks/#ethereum-testnets) पर लागू करने का अर्थ है कि कोई भी इसके साथ इंटरैक्शन कर सकता है (उदाहरण के लिए, डैप के फ्रंटएंड के माध्यम से) फंड को जोखिम में डाले बिना। + +मैन्युअल परीक्षण का यह रूप उपयोगकर्ता के दृष्टिकोण से आपके एप्लिकेशन के एंड-टू-एंड प्रवाह का मूल्यांकन करने के लिए उपयोगी है। यहां, बीटा परीक्षक परीक्षण रन भी कर सकते हैं और अनुबंध के व्यावसायिक तर्क और समग्र कार्यक्षमता के साथ किसी भी समस्या की रिपोर्ट कर सकते हैं। + +स्थानीय ब्लॉकचेन पर परीक्षण के बाद टेस्टनेट पर तैनाती आदर्श है क्योंकि पूर्व एथेरियम वर्चुअल मशीन के व्यवहार के करीब है। इसलिए, कई एथेरियम-देशी परियोजनाओं के लिए वास्तविक दुनिया की स्थितियों के तहत स्मार्ट अनुबंध ऑपरेशन का मूल्यांकन करने के लिए टेस्टनेट पर डैप्स को डिप्लॉय करना आम बात है। + +[एथेरियम टेस्टनेट पर अधिक।](/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-कवरेज](https://github.com/sc-forks/solidity-coverage)** - _Solidity में लिखे गए स्मार्ट अनुबंध के लिए कोड कवरेज टूल।_ + +- **[वेफ़ल](https://ethereum-waffle.readthedocs.io/en/latest/)** - _उन्नत स्मार्ट अनुबंध डेवपलमेंट और परीक्षण के लिए फ्रेमवर्क (ethers.js के आधार पर)_। + +- **[Remix टेस्ट](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _Solidity स्मार्ट अनुबंध के परीक्षण के लिए टूल। Remix IDE "Solidity यूनिट टेस्टिंग" प्लगइन के तहत काम करता है जिसका उपयोग अनुबंध के लिए परीक्षण मामलों को लिखने और चलाने के लिए किया जाता है।_ + +- **[OpenZeppelin टेस्ट हेल्पर्स](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _एथेरियम स्मार्ट अनुबंध टेस्टिंग के लिए कन्सर्ट लाइब्रेरी। सुनिश्चित करें कि आपके अनुबंध अपेक्षित व्यवहार करते हैं!_ + +- **[Brownie यूनिट टेस्टिंग फ्रेमवर्क](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _Brownie Pytest का उपयोग करता है, जो एक फीचर-समृद्ध परीक्षण फ्रैमवर्क है जो आपको न्यूनतम कोड के साथ छोटे परीक्षण लिखने की सुविधा देता है, बड़ी परियोजनाओं के लिए अच्छी तरह से स्केल करता है और अत्यधिक विस्तार योग्य है।_ + +- **[Foundry टेस्ट](https://github.com/foundry-rs/foundry/tree/master/forge)** - _Foundry Forge प्रदान करता है, जो एक तेज़ और लचीला एथेरियम परीक्षण ढांचा है जो सरल इकाई परीक्षण, गैस अनुकूलन जांच और अनुबंध फ़ज़िंग निष्पादित करने में सक्षम है।_ + +- **[Hardhat टेस्ट](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _ethers.js, Mocha, और Chai के आधार पर स्मार्ट अनुबंधों के परीक्षण के लिए फ्रैमवर्क।_ + +- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _एथेरियम वर्चुअल मशीन को लक्षित करने वाले स्मार्ट अनुबंधों के लिए 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)** - _Rust-आधारित स्थिर विश्लेषक विशेष रूप से Web3 स्मार्ट अनुबंध सुरक्षा और विकास के लिए डिज़ाइन किया गया।_ + +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _भेद्यता और कोड गुणवत्ता डिटेक्टरों के साथ Python-आधारित स्थिर विश्लेषण फ्रैमवर्क, कोड से उपयोगी जानकारी निकालने के लिए प्रिंटर और कस्टम सबमॉड्यूल लिखने के लिए सपोर्ट।_ + +#### गतिशील विश्लेषण उपकरण {#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 फ़ज़िंग या MythX जैसे टूल के साथ अनुबंधों का स्वचालित रूप से परीक्षण करने की सुविधा देते हैं।_ + +## संबंधित ट्यूटोरियल {#related-tutorials} + +- [विभिन्न टेस्टिंग प्रोडक्ट्स का अवलोकन और तुलना](/developers/tutorials/guide-to-smart-contract-security-tools/) \_ +- [स्मार्ट अनुबंधों का परीक्षण करने के लिए Echidna का उपयोग कैसे करें](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) +- [स्मार्ट अनुबंध बग खोजने के लिए Manticore का उपयोग कैसे करें](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) +- [स्मार्ट अनुबंध बग खोजने के लिए Slither का उपयोग कैसे करें](/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} + +- [एथेरियम स्मार्ट अनुबंधों का परीक्षण करने के लिए एक गहन मार्गदर्शिका](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297) +- [एथेरियम स्मार्ट अनुबंधों का परीक्षण कैसे करें](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/hi/developers/docs/smart-contracts/upgrading/index.md b/public/content/translations/hi/developers/docs/smart-contracts/upgrading/index.md new file mode 100644 index 00000000000..71ab97a53a7 --- /dev/null +++ b/public/content/translations/hi/developers/docs/smart-contracts/upgrading/index.md @@ -0,0 +1,165 @@ +--- +title: स्मार्ट अनुबंधों को अपग्रेड करना +description: एथेरियम स्मार्ट अनुबंधों के लिए अपग्रेड पैटर्न का अवलोकन +lang: hi +--- + +एथेरियम पर स्मार्ट अनुबंध स्व-निष्पादन प्रोग्राम हैं जो एथेरियम वर्चुअल मशीन (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} + +| पेशेवरों | विपक्ष | +| --------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| एक स्मार्ट अनुबंध अपग्रेड परिनियोजन के बाद के चरण में खोजी गई कमजोरियों को ठीक करना आसान बना सकता है। | स्मार्ट अनुबंधों को अपग्रेड करना कोड अपरिवर्तनीयता के विचार को नकारता है, जिसमें विकेंद्रीकरण और सुरक्षा के लिए निहितार्थ हैं। | +| विकेन्द्रीकृत अनुप्रयोगों में नई सुविधाओं को जोड़ने के लिए डेवलपर्स तर्क को अपग्रेड करने की प्रोसेस का उपयोग कर सकते हैं। | उपयोगकर्ताओं को डेवलपर्स पर भरोसा करना चाहिए कि वे स्मार्ट अनुबंधों में मनमाने ढंग से बदलाव न करें। | +| स्मार्ट अनुबंध अपग्रेड करने से अंतिम उपयोगकर्ताओं के लिए सुरक्षा में सुधार किया जा सकता है, क्योंकि बग को जल्दी से ठीक किया जा सकता है। | प्रोग्रामिंग स्मार्ट अनुबंधों में कार्यक्षमता को अपग्रेड करता है जटिलता की एक और परत जोड़ता है और महत्वपूर्ण खामियों की संभावना को बढ़ाता है। | +| अनुबंध उन्नयन डेवलपर्स को अलग-अलग सुविधाओं के साथ प्रयोग करने और समय के साथ डैप्स को बेहतर बनाने के लिए अधिक जगह देता है। | स्मार्ट अनुबंधों को अपग्रेड करने का अवसर डेवलपर्स को विकास के चरण के दौरान उचित परिश्रम किए बिना परियोजनाओं को तेजी से लॉन्च करने के लिए प्रोत्साहित कर सकता है। | +| | स्मार्ट अनुबंधों में असुरक्षित अभिगम नियंत्रण या केंद्रीकरण दुर्भावनापूर्ण अभिनेताओं के लिए अनधिकृत रूप से अपग्रेड करना आसान बना सकता है। | + +## स्मार्ट अनुबंधों को अपग्रेड करने के लिए विचार {#considerations-for-upgrading-smart-contracts} + +1. अनधिकृत स्मार्ट अनुबंध के अपग्रेड को रोकने के लिए सुरक्षित अभिगम नियंत्रण/प्राधिकरण तंत्र का उपयोग करें, खासकर यदि प्रॉक्सी पैटर्न, रणनीति पैटर्न या डेटा पृथक्करण का उपयोग कर रहे हैं। एक उदाहरण अपग्रेड फ़ंक्शन तक पहुंच को प्रतिबंधित कर रहा है, जैसे कि केवल अनुबंध का स्वामी ही इसे कॉल कर सकता है। + +2. स्मार्ट अनुबंधों को अपग्रेड करना एक जटिल गतिविधि है और कमजोरियों की शुरुआत को रोकने के लिए उच्च स्तर के परिश्रम की आवश्यकता होती है। + +3. अपग्रेड को लागू करने की प्रक्रिया को विकेन्द्रीकृत करके विश्वास मान्यताओं को कम करें। संभावित रणनीतियों में अपग्रेड को नियंत्रित करने के लिए [मल्टी-सिग वॉलेट कॉन्ट्रैक्ट](/developers/docs/smart-contracts/#multisig) का उपयोग करना, या अपग्रेड को अनुमोदित करने के लिए मतदान करने के लिए [डीएओ के सदस्यों](/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 ट्यूटोरियल: fangjun.eth के अनुसार [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/) +- [Solidity स्मार्ट अनुबंध को अपग्रेड करने के कई तरीके](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - क्रिप्टो मार्केट पूल ब्लॉग +- [जानें: स्मार्ट अनुबंध को अपग्रेड करना](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - OpenZeppelin डॉक्स +- नवीन साहू के अनुसार, [Solidity कॉन्ट्रैक्ट्स की अपग्रेडेबिलिटी के लिए प्रॉक्सी पैटर्न: ट्रांसपेरेंट बनाम UUPS प्रॉक्सी](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) +- निक मडगे के अनुसार, [डायमंड अपग्रेड कैसे काम करता है](https://dev.to/mudgen/how-diamond-upgrades-work-417j) diff --git a/public/content/translations/hi/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/hi/developers/docs/smart-contracts/verifying/index.md new file mode 100644 index 00000000000..ed5b749c39a --- /dev/null +++ b/public/content/translations/hi/developers/docs/smart-contracts/verifying/index.md @@ -0,0 +1,107 @@ +--- +title: स्मार्ट अनुबंधों की पुष्टि करना +description: एथेरियम स्मार्ट अनुबंधों के लिए स्रोत कोड सत्यापन का अवलोकन +lang: hi +--- + +[स्मार्ट अनुबंध](/developers/docs/smart-contracts/) को "भरोसेमंद" होने के लिए डिज़ाइन किया गया है, जिसका अर्थ है कि उपयोगकर्ताओं को अनुबंध के साथ बातचीत करने से पहले तीसरे पक्ष (जैसे, डेवलपर्स और कंपनियों) पर भरोसा नहीं करना चाहिए। विश्वसनीयता के लिए एक आवश्यकता के रूप में, उपयोगकर्ताओं और अन्य डेवलपर्स को स्मार्ट अनुबंध के स्रोत कोड को सत्यापित करने में सक्षम होना चाहिए। स्रोत कोड सत्यापन उपयोगकर्ताओं और डेवलपर्स को आश्वस्त करता है कि प्रकाशित अनुबंध कोड वही कोड है जो एथेरियम ब्लॉकचेन पर अनुबंध पते पर चल रहा है। + +"स्रोत कोड सत्यापन" और "[औपचारिक सत्यापन](/developers/docs/smart-contracts/formal-verification/)" के बीच अंतर करना महत्वपूर्ण है। स्रोत कोड सत्यापन, जिसे नीचे विस्तार से समझाया जाएगा, यह सत्यापित करने के लिए संदर्भित करता है कि एक उच्च-स्तरीय भाषा (जैसे Solidity) में स्मार्ट अनुबंध का दिया गया स्रोत कोड अनुबंध पते पर निष्पादित होने वाले उसी बाइटकोड को संकलित करता है। हालांकि, औपचारिक सत्यापन एक स्मार्ट अनुबंध की शुद्धता की पुष्टि करने का वर्णन करता है, जिसका अर्थ है कि अनुबंध अपेक्षित व्यवहार करता है। हालांकि संदर्भ-निर्भर, अनुबंध सत्यापन आमतौर पर स्रोत कोड सत्यापन को संदर्भित करता है। + +## स्रोत कोड सत्यापन क्या है? {#what-is-source-code-verification} + +[एथेरियम वर्चुअल मशीन (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} + +अविश्वासहीनता यकीनन स्मार्ट अनुबंधों और [विकेन्द्रीकृत एप्लिकेशनों (डैप्स)](/developers/docs/dapps/) के लिए सबसे बड़ा आधार है। स्मार्ट अनुबंध "अपरिवर्तनीय" हैं और इन्हें बदला नहीं जा सकता है; एक अनुबंध केवल लागू करते समय कोड में निर्धारित व्यावसायिक तर्क को निष्पादित करेगा। इसका मतलब है कि डेवलपर्स और उद्यम एथेरियम पर लागू होने के बाद अनुबंध के कोड के साथ छेड़छाड़ नहीं कर सकते हैं। + +एक स्मार्ट अनुबंध भरोसेमंद होने के लिए, अनुबंध कोड स्वतंत्र सत्यापन के लिए उपलब्ध होना चाहिए। जबकि प्रत्येक स्मार्ट अनुबंध के लिए संकलित बाइटकोड ब्लॉकचेन पर सार्वजनिक रूप से उपलब्ध है, निम्न-स्तरीय भाषा को समझना मुश्किल है - डेवलपर्स और उपयोगकर्ताओं दोनों के लिए। + +प्रोजेक्ट्स अपने अनुबंधों के स्रोत कोड को प्रकाशित करके विश्वास मान्यताओं को कम करती हैं। लेकिन यह एक और समस्या की ओर जाता है: यह सत्यापित करना मुश्किल है कि प्रकाशित स्रोत कोड अनुबंध बाइटकोड से मेल खाता है। इस परिदृश्य में, अविश्वसनीयता का मान खो जाता है क्योंकि उपयोगकर्ताओं को किसी अनुबंध को ब्लॉकचेन पर लागू करने से पहले इसके व्यावसायिक तर्क (यानी, बाइटकोड बदलकर) को नहीं बदलने के लिए डेवलपर्स पर भरोसा करना पड़ता है। + +स्रोत कोड सत्यापन टूल गारंटी प्रदान करते हैं कि एक स्मार्ट अनुबंध की स्रोत कोड फाइलें असेंबली कोड से मेल खाती हैं। परिणाम एक भरोसेमंद पारिस्थितिकी तंत्र है, जहां उपयोगकर्ता तीसरे पक्ष पर आँख बंद करके भरोसा नहीं करते हैं और इसके बजाय अनुबंध में धन जमा करने से पहले कोड सत्यापित करते हैं। + +### उपयोगकर्ता सुरक्षा {#user-safety} + +स्मार्ट अनुबंधों के साथ, आमतौर पर स्टेक पर बहुत सारा पैसा लगाया जाता है। यह उच्च सुरक्षा गारंटी और इसका उपयोग करने से पहले एक स्मार्ट अनुबंध के तर्क के सत्यापन की मांग करता है। समस्या यह है कि बेईमान डेवलपर्स स्मार्ट अनुबंध में दुर्भावनापूर्ण कोड डालकर उपयोगकर्ताओं को धोखा दे सकते हैं। सत्यापन के बिना, दुर्भावनापूर्ण स्मार्ट अनुबंधों में [बैकडोर](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts), संदेहास्पद एक्सेस कंट्रोल सिस्टम, भेद्य कमजोरियां और अन्य चीजें हो सकती हैं जो उपयोगकर्ता सुरक्षा को खतरे में डालती हैं और जिनकी जांच चूक जाएगी। + +एक स्मार्ट अनुबंध के स्रोत कोड फ़ाइलों को प्रकाशित करना संभावित हमले वैक्टर के लिए अनुबंध का आकलन करने के लिए रुचि रखने वाले व्यक्तियों जैसे लेखा परीक्षकों के लिए आसान बनाता है। कई पार्टियों के स्वतंत्र रूप से एक स्मार्ट अनुबंध की पुष्टि करने के साथ, उपयोगकर्ताओं के पास इसकी सुरक्षा की मजबूत गारंटी है। + +## एथेरियम स्मार्ट अनुबंधों के स्रोत कोड को कैसे सत्यापित करें {#source-code-verification-for-ethereum-smart-contracts} + +[एथेरियम पर एक स्मार्ट अनुबंध](/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} + +अनुबंधों को सत्यापित करने की पारंपरिक प्रक्रिया जटिल हो सकती है। यही कारण है कि हमारे पास एथेरियम पर लागू स्मार्ट अनुबंधों के लिए स्रोत कोड की पुष्टि करने के लिए टूल हैं। ये टूल स्रोत कोड सत्यापन के बड़े हिस्से को स्वचालित करते हैं और उपयोगकर्ताओं के लाभों के लिए सत्यापित अनुबंधों को भी क्यूरेट करते हैं। + +### इथरस्कैन {#etherscan} + +हालांकि ज्यादातर [एथेरियम ब्लॉकचेन एक्सप्लोरर](/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)। + +### 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 पर इसके [सार्वजनिक भंडार](https://docs.sourcify.dev/docs/repository/) और [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs) में परोसा जाता है, जो एक विकेन्द्रीकृत, [सामग्री-संबोधित](https://web3.storage/docs/concepts/content-addressing/) स्‍टोरेज है। यह IPFS पर अनुबंध की मेटाडेटा फ़ाइल लाने की अनुमति देता है क्योंकि संलग्न मेटाडेटा हैश एक IPFS हैश है। + +इसके अतिरिक्त, कोई भी IPFS पर स्रोत कोड फ़ाइलों को पुनः प्राप्त कर सकता है, क्योंकि इन फ़ाइलों के IPFS हैश मेटाडेटा में भी पाए जाते हैं। एक अनुबंध को मेटाडेटा फ़ाइल और स्रोत फ़ाइलें उसके API या [UI](https://sourcify.dev/#/verifier) पर प्रदान करके या प्लगइन्स का उपयोग करके सत्यापित किया जा सकता है। Sourcify मॉनिटरिंग टूल नए ब्लॉकों पर अनुबंध निर्माण को भी सुनता है और अनुबंधों को सत्यापित करने का प्रयास करता है यदि उनके मेटाडेटा और स्रोत फ़ाइलें IPFS पर प्रकाशित होती हैं। + +[Sourcify पर अनुबंधों की पुष्टि करने पर अधिक](https://blog.soliditylang.org/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/monitoring/smart-contract-verification/verifying-a-smart-contract), [टेंडरली हार्डहाट प्लगइन](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin), या [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/hi/whitepaper/index.md b/public/content/translations/hi/whitepaper/index.md new file mode 100644 index 00000000000..cde17de302d --- /dev/null +++ b/public/content/translations/hi/whitepaper/index.md @@ -0,0 +1,517 @@ +--- +title: इथेरियम व्हाइटपैपर +description: एथेरियम का एक परिचयात्मक पत्र, जो इसके लॉन्च से पहले 2013 में प्रकाशित हुआ था। +lang: hi +sidebarDepth: 2 +hideEditButton: true +--- + +# इथेरियम व्हाइटपैपर {#ethereum-whitepaper} + +_यह परिचयात्मक पत्र मूल रूप से 2014 में [एथेरियम](/what-is-ethereum/) के संस्थापक विटालिक ब्यूटिरिन द्वारा 2015 में प्रोजेक्ट के लॉन्च से पहले प्रकाशित किया गया था। यह ध्यान देने योग्य है कि एथेरियम, कई समुदाय-संचालित, ओपन-सोर्स सॉफ़्टवेयर प्रोजेक्ट्स की तरह, अपनी प्रारंभिक स्थापना के बाद से विकसित हुआ है।_ + +_हालांकि यह कई साल पुराना है, हम इस पेपर को बनाए रखते हैं, क्योंकि यह एक उपयोगी संदर्भ और एथेरियम और इसकी दृष्टि के सटीक प्रतिनिधित्व के रूप में काम करना जारी रखता है। एथेरियम के नवीनतम विकास और प्रोटोकॉल में परिवर्तन कैसे किए जाते हैं, इसके बारे में जानने के लिए, हम [इस गाइड](/learn/) की अनुशंसा करते हैं।_ + +[[दिसंबर 2014 से] सफेद कागज के ऐतिहासिक या विहित संस्करण की मांग करने वाले शोधकर्ताओं और शिक्षाविदों को इस PDF का उपयोग करना चाहिए।](./whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf) + +## एक अगली पीढ़ी का स्मार्ट अनुबंध और विकेंद्रीकृत एप्लिकेशन प्लेटफ़ार्म {#a-next-generation-smart-contract-and-decentralized-application-platform} + +2009 में सतोशी नाकामोतो के Bitcoin के विकास को अक्सर मुद्रा और मुद्रा में एक कट्टरपंथी विकास के रूप में सराहा गया है, जो एक डिजिटल संपत्ति का पहला उदाहरण है जिसका एक साथ कोई समर्थन या "[आंतरिक मूल्य](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/)" नहीं है और कोई केंद्रीकृत जारीकर्ता या नियंत्रक नहीं है। हालांकि, एक और, यकीनन अधिक महत्वपूर्ण, Bitcoin प्रयोग का हिस्सा अंतर्निहित ब्लॉकचेन तकनीक है जो वितरित सहमति के एक उपकरण के रूप में है, और ध्यान तेजी से Bitcoin के इस अन्य पहलू पर स्थानांतरित होने लगा है। ब्लॉकचेन तकनीक के आम तौर पर उद्धृत वैकल्पिक अनुप्रयोगों में कस्टम मुद्राओं और वित्तीय उपकरणों ("[रंगीन सिक्के](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)") का प्रतिनिधित्व करने के लिए ऑन-ब्लॉकचेन डिजिटल संपत्ति का उपयोग करना शामिल है, एक अंतर्निहित भौतिक उपकरण का स्वामित्व ("[स्मार्ट संपत्ति ](https://en.bitcoin.it/wiki/Smart_Property)") अपूरणीय संपत्ति जैसे डोमेन नाम ("[Namecoin](http://namecoin.org)") के साथ-साथ अधिक जटिल अनुप्रयोगों में डिजिटल संपत्ति को सीधे मनमाने नियमों ("[स्मार्ट अनुबंध](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)") को लागू करने वाले कोड के एक हिस्से या यहां तक कि ब्लॉकचेन-आधारित "[विकेंद्रीकृत स्वायत्त संगठन](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/)" (डीएओ) द्वारा नियंत्रित किया जा रहा है। एथेरियम जो प्रदान करने का इरादा रखता है वह एक अंतर्निहित पूरी तरह से ट्यूरिंग वाली प्रोग्रामिंग भाषा के साथ एक ब्लॉकचेन है जिसका उपयोग "अनुबंध" बनाने और मनमाने ढंग से स्टेट ट्रांजिशन फ़ंक्शन को एन्कोड करने के लिए किया जा सकता है, जिससे यूज़र ऊपर वर्णित किसी भी सिस्टम को बना सकते हैं, साथ ही कई अन्य जिनकी हमने अभी तक कल्पना नहीं की है, ऐसा वे बस कोड की कुछ पंक्तियों में तर्क लिखकर कर सकते हैं। + +## Bitcoin और मौजूदा अवधारणाओं का परिचय {#introduction-to-bitcoin-and-existing-concepts} + +### इतिहास {#history} + +विकेंद्रीकृत डिजिटल मुद्रा की अवधारणा के साथ-साथ संपत्ति रजिस्ट्रियों जैसे वैकल्पिक एप्लिकेशन दशकों से हैं। 1980 और 1990 के दशक के अनाम ई-कैश प्रोटोकॉल, जो ज़्यादातर एक क्रिप्टोग्राफिक प्रीमिटिव पर निर्भर थे, जिन्हें चौमियन ब्लाइंडिंग के रूप में जाना जाता था, उन्होंने उच्च स्तर की गोपनीयता के साथ एक मुद्रा प्रदान की, लेकिन प्रोटोकॉल काफी हद तक एक केंद्रीकृत मध्यस्थ पर उनकी निर्भरता के कारण कर्षण प्राप्त करने में विफल रहे। 1998 में, Wei Dai का [बी-मनी](http://www.weidai.com/bmoney.txt) कम्प्यूटेशनल पहेलियों को हल करने के साथ-साथ विकेंद्रीकृत सर्वसम्मति के माध्यम से धन बनाने के विचार को पेश करने वाला पहला प्रस्ताव बन गया, लेकिन प्रस्ताव इस विवरण पर बहुत कम था कि विकेंद्रीकृत सर्वसम्मति को असल में कैसे लागू किया जा सकता है। 2005 में, हेल फ़िन्नी ने "[काम का सबूत प्रयोज्य प्रमाण](https://nakamotoinstitute.org/finney/rpow/)" की एक अवधारणा पेश की, एक ऐसा सिस्टम जो क्रिप्टोक्यूरेंसी के लिए एक अवधारणा बनाने के लिए एडम बैक की कम्प्यूटेशनल रूप से कठिन हैशकैश पहेलियों के साथ बी-मनी से विचारों का उपयोग करता है, लेकिन एक बार फिर बैकएंड के रूप में विश्वसनीय कंप्यूटिंग पर भरोसा करके आदर्श से कम हो गया। 2009 में, एक विकेंद्रीकृत मुद्रा को पहली बार सतोशी नाकामोतो द्वारा व्यवहार में लागू किया गया था, जिसमें सिक्कों के मालिक कौन हैं, इस पर नज़र रखने के लिए एक सर्वसम्मत एल्गोरिथ्म के साथ सार्वजनिक कुंजी क्रिप्टोग्राफ़ी के माध्यम से स्वामित्व के प्रबंधन के लिए स्थापित प्रीमिटिव को जोड़ा गया था, जिसे "काम का सबूत" के रूप में जाना जाता है। + +काम के सबूत के पीछे की प्रणाली इस क्षेत्र में एक बड़ी सफलता थी, क्योंकि इससे एक साथ दो समस्याएँ हल हुईं। सबसे पहले, इसने एक सरल और मध्यम रूप से प्रभावी सर्वसम्मति एल्गोरिथ्म प्रदान किया, जिससे नेटवर्क में नोड्स को Bitcoin खाता बही की स्थिति के लिए कैनॉनिकल अपडेट के एक सेट पर सामूहिक रूप से सहमत होने की अनुमति मिली। दूसरा, इसने सर्वसम्मति प्रक्रिया में स्वतंत्र प्रवेश की अनुमति देने के लिए एक तरीका उपलब्ध कराया, यह तय करने की राजनीतिक समस्या को हल किया कि कौन सर्वसम्मति को प्रभावित करता है, साथ ही साथ सिबिल हमलों को रोकता है। यह भागीदारी के लिए एक औपचारिक समस्या को प्रतिस्थापित करके ऐसा करता है, जैसे कि एक विशेष सूची में एक अद्वितीय इकाई के रूप में पंजीकृत होने की आवश्यकता, एक आर्थिक रुकावट के साथ-सर्वसम्मति मतदान प्रक्रिया में एक सिंगल नोड का वज़न सीधे कंप्यूटिंग क्षमता के समानुपाती होता है जो नोड लाता है। तब से, एक वैकल्पिक दृष्टिकोण प्रस्तावित किया गया है जिसे _हिस्सेदारी का सबूत_ कहा जाता है, एक नोड के वज़न की गणना इसके करेंसी होल्डिंग्स के समानुपाती होने के रूप में और कम्प्यूटेशनल संसाधनों के रूप में नहीं; दोनों दृष्टिकोणों के सापेक्ष गुणों की चर्चा इस पेपर के दायरे से परे है, लेकिन यह ध्यान दिया जाना चाहिए कि दोनों दृष्टिकोण का उपयोग क्रिप्टोकरेंसी के अहम हिस्से के रूप में किया जा सकता है। + +### एक राज्य संक्रमण सिस्टम के रूप में Bitcoin {#bitcoin-as-a-state-transition-system} + +![एथेरियम राज्य संक्रमण](./ethereum-state-transition.png) + +तकनीकी दृष्टिकोण से, Bitcoin जैसी क्रिप्टोकरेंसी के खाता बही को एक स्टेट ट्रांज़िशन सिस्टम के रूप में समझा जा सकता है, जहां एक "स्टेट" होता है जिसमें सभी मौजूदा Bitcoin के स्वामित्व वाली स्थिति और एक "स्टेट ट्रांज़िशन फ़ंक्शन" होता है जो एक राज्य और एक लेनदेन लेता है और एक नई स्थिति पेश करता है जो परिणाम है। एक मानक बैंकिंग सिस्टम में, उदाहरण के लिए, राज्य एक बैलेंस शीट है, लेनदेन $X को A से B तक स्थानांतरित करने का अनुरोध है, और स्टेट ट्रांज़िशन फ़ंक्शन A के खाते में मूल्य को $X कम कर देता है और B के खाते में मूल्य को $X से बढ़ जाता है। अगर A के खाते में पहले से ही $X से कम राशि है, तो राज्य संक्रमण फ़ंक्शन एक गड़बड़ी देता है। इसलिए, कोई औपचारिक रूप से परिभाषित कर सकता है: + +``` +लागू करें (एस, TX) -> एस 'या त्रुटि +``` + +ऊपर परिभाषित बैंकिंग सिस्टम में: + +```js +लागू करें ({ Alice: $50, Bob: $50 },"एलिस से बॉब को $20 भेजें") = { Alice: $30, Bob: $70 } +``` + +परंतु: + +```js +लागू करें "({ Alice: $50, Bob: $50 }","एलिस से बॉब को $70 भेजें") = त्रुटि +``` + +Bitcoin में "स्टेट" सभी सिक्कों (तकनीकी रूप से, "खर्च न किए गए लेनदेन आउटपुट" या UTXO) का संग्रह है, जिन्हें ढाला गया है और अभी तक खर्च नहीं किया गया है, प्रत्येक UTXO के पास एक मूल्यवर्ग और एक मालिक है (20-बाइट पते द्वारा परिभाषित किया गया है जो अनिवार्य रूप से एक क्रिप्टोग्राफिक सार्वजनिक कुंजी है [fn1] (#notes) )। एक लेन-देन में एक या अधिक इनपुट होते हैं, जिनमें हर इनपुट में मौजूदा UTXO का संदर्भ होता है और मालिक के पते से जुड़ी निजी कुंजी द्वारा जेनरेट किया गया एक क्रिप्टोग्राफ़िक हस्ताक्षर होता है, और एक या अधिक आउटपुट होते हैं, जिसमें हर आउटपुट में एक नया UTXO होता है जिसे स्टेट में जोड़ा जाना है। + +स्टेट संक्रमण फ़ंक्शन `APPLY(S,TX) -> S'` इसे मोटे तौर पर निम्नानुसार परिभाषित किया जा सकता हैं: + +
    +
  1. + TX में प्रत्येक इनपुट के लिए: +
      +
    • + अगर संदर्भित UTXO S में नहीं है, तो एक गड़बड़ी लौटाएं। +
      • +
    • + अगर दिए गए हस्ताक्षर UTXO के मालिक से मेल नहीं खाते हैं, तो एक गड़बड़ी वापस करें। +
      • +
    +
    2. +
  2. + अगर सभी इनपुट UTXO के मूल्यवर्गों का योग सभी आउटपुट UTXO के मूल्यवर्गों के योग से कम है, एक गड़बड़ी लौटाएं। +
    3. +
  3. + सभी इनपुट UTXO हटाए जाने और सभी आउटपुट UTXO जोड़े जाने के साथ S वापस करें। +
    4. +
+ +पहले चरण का पहला भाग लेन-देन प्रेषकों को उन सिक्कों को खर्च करने से रोकता है जो मौजूद नहीं हैं, पहले चरण का दूसरा भाग लेन-देन प्रेषकों को अन्य लोगों के सिक्के खर्च करने से रोकता है, और दूसरा चरण मूल्य के संरक्षण को लागू करता है। इसका उपयोग करने के लिए भुगतान, प्रोटोकॉल इस प्रकार है। मान लीजिए ऐलिस, बॉब को 11.7 BTC भेजना चाहता है। सबसे पहले, ऐलिस उपलब्ध UTXO के एक सेट की तलाश करेगी जिसे वह जिसके पास कम से कम 11.7 BTC है। वास्तविक रूप से, ऐलिस ठीक 11.7 BTC प्राप्त करने में सक्षम नहीं होगी; मान लीजिए कि वह सबसे कम 6+4+2=12 प्राप्त कर सकती है। फिर वह उन तीन इनपुट और दो आउटपुट के साथ एक लेनदेन बनाती है। पहला आउटपुट 11.7 BTC होगा जिसमें बॉब का पता होगा मालिक, और दूसरा आउटपुट शेष 0.3 BTC "बदलाव" होगा, जिसकी मालिक खुद ऐलिस होगी। + +### खुदाई {#mining} + +![एथेरियम ब्लॉक](./ethereum-blocks.png) + +अगर हमारे पास एक भरोसेमंद केंद्रीकृत सेवा तक पहुंच होती, तो यह सिस्टम लागू करने के लिए तुच्छ हो; इसे बिल्कुल वर्णित के रूप में कोडित किया जा सकता है, राज्य पर नज़र रखने के लिए एक केंद्रीकृत सर्वर की हार्ड ड्राइव का उपयोग करना। हालांकि, Bitcoin के साथ हम एक विकेन्द्रीकृत मुद्रा प्रणाली बनाने की कोशिश कर रहे हैं, इसलिए हमें स्टेट ट्रांज़िशन सिस्टम को सर्वसम्मति प्रणाली के साथ संयोजित करने की आवश्यकता होगी, ताकि यह सुनिश्चित किया जा सके कि सभी लोग लेनदेन के क्रम से सहमत हों। Bitcoin की विकेन्द्रीकृत सर्वसम्मति प्रक्रिया के लिए नेटवर्क में नोड्स को लगातार "ब्लॉक" नाम के लेनदेन के पैकेज बनाने की कोशिश करना आवश्यक होता है। नेटवर्क का उद्देश्य लगभग हर दस मिनट में एक ब्लॉक तैयार करना है, जिसमें से हर ब्लॉक में एक टाइमस्टैम्प, एक नॉन्स, पिछले ब्लॉक का संदर्भ (मतलब उसका हैश) और पिछले ब्लॉक के बाद से हुए सभी लेन-देन की सूची शामिल होगी। समय के साथ, यह एक स्थायी, निरंतर बढ़ने वाला "ब्लॉकचेन" बनाता है जो Bitcoin खाता बही की हाल ही की स्थिति को दिखाने के लिए लगातार अपडेट होता रहता है। + +इस प्रतिमान में दिय़ा गया, किसी ब्लॉक के मान्य होने की जांच करने का एल्गोरिथ्म इस प्रकार है: + +1. जाँचें कि ब्लॉक द्वारा संदर्भित पिछला ब्लॉक मौजूद है या नहीं और मान्य है या नहीं। +2. जाँचें कि ब्लॉक का टाइमस्टैम्प पिछले ब्लॉक[fn2](#notes) से बड़ा है और आने वाले समय में 2 घंटे से कम है +3. जाँचें कि ब्लॉक पर काम का सबूत मान्य है या नहीं। +4. मान लें कि `S[0]` पिछले ब्लॉक के आखिर में स्टेट है। +5. मान लें कि `TX` ब्लॉक की लेनदेन सूची है जिसमें `n` लेन-देन है। `0...n-1` में सभी `i` के लिए, `S[i+1] = APPLY(S[i],TX[i])` सेट करें अगर कोई भी एप्लिकेशन गड़बड़ी लौटाता है, तो बाहर निकलें और गलत लौटाएं। +6. सत्य लौटाएँ, और इस ब्लॉक के आखिर में स्थिति के रूप में `S[n]` रजिस्टर करें। + +अनिवार्य रूप से, ब्लॉक में हर लेनदेन को लेनदेन के निष्पादन से पहले की प्रामाणिक स्थिति से लेकर किसी नई स्थिति तक एक मान्य स्टेट ट्रांज़िशन प्रदान करना होगा। ध्यान दें कि स्टेट को किसी भी तरह से ब्लॉक में एनकोड नहीं किया गया है; यह पूरी तरह से एक अमूर्तता है जिसे सत्यापन नोड द्वारा याद रखा जाना चाहिए और इसे किसी भी ब्लॉक के लिए केवल उत्पत्ति स्थिति से शुरू करके और प्रत्येक ब्लॉक में प्रत्येक लेनदेन को क्रम के हिसाब से लागू करके (सुरक्षित रूप से) गणना की जा सकती है। इसके अतिरिक्त, ध्यान दें कि जिस क्रम में माइनर ब्लॉक में लेनदेन शामिल करता है वह मायने रखता है; अगर किसी ब्लॉक में दो लेनदेन A और B हैं, जिससे B, A द्वारा बनाए गए UTXO को खर्च करता है, तो ब्लॉक तभी मान्य होगा जब A, B से पहले आएगा और किसी मामले में नहीं। + +उपरोक्त सूची में एक वैधता शर्त मौजूद है जो अन्य सिस्टम में नहीं पाई जाती है, वह है "काम का सबूत" की आवश्यकता। सटीक शर्त यह है कि हर ब्लॉक का डबल-SHA256 हैश, जिसे 256-बिट संख्या माना जाता है, गतिशील रूप से एडजस्ट किए गए लक्ष्य से कम होना चाहिए, जो इस लेखन के समय लगभग 2187 है। इसका उद्देश्य ब्लॉक बनाने की प्रोसेस को कम्प्यूटेशनल रूप से "मुश्किल" बनाना है, जिससे सिबिल हमलावरों को पूरे ब्लॉकचेन को अपने पक्ष में बनाने से रोका जा सके। चूँकि SHA256 को पूरी तरह से अप्रत्याशित सियूडोरैंडम फ़ंक्शन के रूप में डिज़ाइन किया गया है, इसलिए मान्य ब्लॉक बनाने का एकमात्र तरीका केवल परीक्षण और गड़बड़ी है, बार-बार नॉन्स को बढ़ाना और देखना कि क्या नया हैश मेल खाता है। + +वर्तमान लक्ष्य ~2187 पर, मान्य ब्लॉक मिलने से पहले नेटवर्क को औसतन ~269 प्रयास करने होंगे; सामान्य तौर पर, नेटवर्क द्वारा हर 2016 ब्लॉक पर लक्ष्य का पुनर्निर्धारण किया जाता है, ताकि औसतन हर दस मिनट में नेटवर्क में किसी नोड द्वारा एक नया ब्लॉक तैयार किया जा सके। इस कम्प्यूटेशनल काम के लिए खनिकों को मुआवज़ा देने के लिए, हर ब्लॉक के खनिक को एक लेनदेन शामिल करने का अधिकार है, जिससे उन्हें कहीं से भी 25 BTC हासिल हो। इसके अलावा, अगर किसी लेनदेन में इनपुट का कुल मूल्य उसके आउटपुट की तुलना में अधिक है, तो यह अंतर भी "लेनदेन शुल्क" के रूप में खनिक को जाता है। संयोग से, यह इकलौता तरीका है जिसकी मदद से BTC जारी किया जाता है; उत्पत्ति अवस्था में कोई भी सिक्का नहीं था। + +खनन के उद्देश्य को बेहतर ढंग से समझने के लिए, आइए देखें कि दुर्भावनापूर्ण हमलावर की स्थिति में क्या होता है। चूंकि Bitcoin में शामिल क्रिप्टोग्राफ़ी सुरक्षित मानी जाती है, इसलिए हमलावर Bitcoin सिस्टम के उस हिस्से को सीधे निशाना बनाएगा जो क्रिप्टोग्राफ़ी द्वारा सुरक्षित नहीं है: लेनदेन का क्रम। हमलावर की रणनीति सरल है: + +1. किसी उत्पाद (अधिमान के हिसाब से तेज़ डिलीवरी वाला डिजिटल सामान) के बदले में किसी व्यापारी को 100 BTC भेजें +2. उत्पाद की डिलीवरी का इंतज़ार करें +3. खुद को वही 100 BTC भेजकर दूसरा लेनदेन करें +4. नेटवर्क को यह समझाने की कोशिश करें कि उसका लेन-देन खुद के लिए था एक जो पहले आया था। + +एक बार चरण (1) हो जाने के बाद, कुछ मिनटों के बाद कुछ खनिक एक ब्लॉक में लेनदेन को शामिल करेंगे, जैसे ब्लॉक संख्या 270000। लगभग एक घंटे के बाद, उस ब्लॉक के बाद चेन में पाँच और ब्लॉक जुड़ जाएँगे, जिनमें से हर ब्लॉक सीधे तौर पर लेन-देन की ओर इशारा करेगा और इस प्रकार इसकी "पुष्टि" करेगा। इस बिंदु पर, व्यापारी भुगतान को अंतिम रूप से स्वीकार कर लेगा और उत्पाद वितरित कर देगा; चूंकि हम यह मान रहे हैं कि यह एक डिजिटल चीज़ है, इसलिए वितरण तत्काल होगा। अब, हमलावर 100 BTC को खुद को भेजते हुए एक और लेनदेन बनाता है। अगर हमलावर इसे खुले में छोड़ देता है, तो लेनदेन प्रोसेस नहीं होगा; खनिक `APPLY(S,TX)` चलाने की कोशिश करेंगे और देखेंगे कि `TX` एक UTXO का उपभोग करता है जो अब स्टेट में नहीं है। इसलिए इसके बजाय, हमलावर ब्लॉकचेन का एक "फ़ोर्क" बनाता है, जो ब्लॉक 270000 के दूसरे वर्जन की माईनिंग करके शुरू होता है और मूल ब्लॉक 269999 को दर्शाता है, लेकिन पुराने के स्थान पर नया लेनदेन होता है। चूँकि ब्लॉक डेटा अलग है, इसलिए इसके लिए काम के सबूत को दोबारा करने की आवश्यकता होती है। इसके अलावा, हमलावर के ब्लॉक 270000 के नए वर्जन का हैश अलग है, इसलिए मूल ब्लॉक 270001 से 270005 इसकी ओर "इशारा" नहीं करते हैं; इस प्रकार, मूल चेन और हमलावर की नई चेन पूरी तरह से अलग हैं। नियम यह है कि किसी फ़ोर्क में सबसे लंबे ब्लॉकचेन को सत्य माना जाता है, और इसलिए मान्य माईनर 270005 चेन पर काम करेंगे, जबकि हमलावर अकेले 270000 चेन पर काम कर रहा होगा। हमलावर को अपनी ब्लॉकचेन को सबसे लंबा बनाने के लिए, उसे शेष नेटवर्क की तुलना में अधिक कम्प्यूटेशनल क्षमता की आवश्यकता होगी (इसलिए, "51% हमला")। + +### मर्कल ट्री {#merkle-trees} + +![Bitcoin में SPV](./spv-bitcoin.png) + +_बायां: किसी शाखा की वैधता का प्रमाण देने के लिए मर्कले ट्री में केवल कुछ ही नोड्स पेश करना काफ़ी है।_ + +_दायां: मर्कल ट्री के किसी भी हिस्से को बदलने की कोई भी कोशिश आखिर में चेन में कहीं न कहीं एक असंगति की ओर ले जाती है।_ + +Bitcoin की एक महत्वपूर्ण स्केलेबिलिटी विशेषता यह है कि ब्लॉक को कई लेवल के हिसाब से डेटा संरचना में स्टोर किया जाता है। किसी ब्लॉक का "हैश" असल में केवल ब्लॉक हेडर का हैश होता है, जो लगभग 200-बाइट का डेटा होता है, जिसमें टाइमस्टैम्प, नॉन्स, पिछले ब्लॉक का हैश और मर्कल ट्री नाम के डेटा स्ट्रक्चर का रूट हैश शामिल होता है, जो ब्लॉक में सभी लेनदेन को स्टोर करता है। मर्कल ट्री एक तरह का बाइनरी ट्री है, जो नोड्स के एक ग्रुप से बना होता है, जिसमें ट्री के निचले भाग में बड़ी संख्या में लीफ़ नोड्स होते हैं, जिनमें शामिल डेटा होता है, मध्यवर्ती नोड्स का एक ग्रुप होता है, जहां हर नोड अपने दो संतानों का हैश होता है, तथा आखिर में एक सिंगल रूट नोड होता है, जो अपने दो संतानों के हैश से बना होता है, और ट्री के "शीर्ष" को दर्शाता है। मर्कल ट्री का उद्देश्य एक ब्लॉक में डेटा को अलग-अलग हिस्सों में वितरित करने की अनुमति देना है: एक नोड एक स्रोत से केवल ब्लॉक के हेडर को डाउनलोड कर सकता है, दूसरे स्रोत से उनके लिए प्रासंगिक ट्री का छोटा हिस्सा, और फिर भी आश्वस्त हो सकता है कि सारा डेटा सही है। यह इसलिए काम करता है, क्योंकि हैश ऊपर की ओर फैलता है: अगर कोई दुर्भावनापूर्ण यूज़र मर्कल ट्री के निचले भाग में नकली लेनदेन को स्वैप करने की कोशिश करता है, तो यह बदलाव ऊपर के नोड में बदलाव का कारण बनेगा, और फिर उसके ऊपर के नोड में बदलाव करेगा, आखिर में वृक्ष के मूल में बदलाव करेगा और इस प्रकार ब्लॉक के हैश में भी बदलाव करेगा, जिसके कारण प्रोटोकॉल इसे पूरी तरह से अलग ब्लॉक के रूप में पंजीकृत करेगा (लगभग पक्के तौर पर अमान्य काम के सबूत के साथ)। + +मर्कल ट्री प्रोटोकॉल दीर्घकालिक स्थिरता के लिए निश्चित रूप से आवश्यक है। Bitcoin नेटवर्क में एक "फ़ुल नोड", जो हर ब्लॉक की संपूर्णता को स्टोर और प्रोसेस करता है, अप्रैल 2014 तक Bitcoin नेटवर्क में लगभग 15 GB डिस्क स्थान लेता है, और हर माह एक गीगाबाइट से अधिक बढ़ रहा है। वर्तमान में, यह कुछ डेस्कटॉप कम्प्यूटरों के लिए ही योग्य है, न कि फ़ोन के लिए, और बाद में भविष्य में केवल व्यवसाय और शौकिया लोग ही इसमें भाग ले पाएंगे। "आसान बनाया गया भुगतान सत्यापन" (SPV) के रूप में जाना जाने वाला एक प्रोटोकॉल नोड्स के एक अन्य वर्ग की मौजूदगी की अनुमति देता है, जिसे "लाइट नोड्स" कहा जाता है, जो ब्लॉक हेडर को डाउनलोड करते हैं, ब्लॉक हेडर पर काम के सबूत को सत्यापित करते हैं, और फिर केवल उन लेनदेन से जुड़ी "शाखाओं" को डाउनलोड करते हैं जो उनके लिए प्रासंगिक हैं। इससे लाइट नोड्स को सुरक्षा की मज़बूत गारंटी के साथ यह पता लगाने की अनुमति मिलती है कि किसी भी Bitcoin लेनदेन की स्थिति क्या है, और उनका मौजूदा शेष क्या है, जबकि वे पूरी ब्लॉकचेन का केवल एक बहुत छोटा हिस्सा ही डाउनलोड करते हैं। + +### वैकल्पिक ब्लॉकचेन एप्लिकेशन {#alternative-blockchain-applications} + +ब्लॉकचेन से संबंधित विचार को अन्य अवधारणाओं पर लागू करने के विचार का भी एक लंबा इतिहास है। 2005 में, निक स्जाबो ने "[मालिकाना हक के साथ सुरक्षित संपत्ति वाला शीर्षक](https://nakamotoinstitute.org/secure-property-titles/)" की अवधारणा पेश की, जो एक दस्तावेज़ था, जिसमें बताया गया था कि किस प्रकार "कॉपी किए गए डाटाबेस संबंधी टेक्नोलॉजी में नई प्रगति" ब्लॉकचेन-आधारित सिस्टम के माध्यम से यह रजिस्ट्री स्टोर करने की अनुमति देगी कि कौन किस भूमि का मालिक है, तथा इसमें होमस्टेडिंग, प्रतिकूल कब्जे और जॉर्जियाई भूमि कर जैसी अवधारणाओं के साथ एक बड़ी रूपरेखा तैयार की जाएगी। हालाँकि, दुर्भाग्य से उस समय कोई प्रभावी कॉपी किया गया या डाटाबेस सिस्टम उपलब्ध नहीं था, और इसलिए प्रोटोकॉल को व्यवहार में कभी लागू नहीं किया गया। हालाँकि, 2009 के बाद, जब Bitcoin की विकेन्द्रीकृत सर्वसम्मति विकसित हो गई, तो कई वैकल्पिक एप्लिकेशन तेजी से सामने आने लगे। + +- **Namecoin** - 2010 में निर्मित, [Namecoin](https://namecoin.org/) का वर्णन एक विकेन्द्रीकृत नाम पंजीकरण डेटाबेस के रूप में किया जा सकता है। Tor, Bitcoin और BitMessage जैसे विकेन्द्रीकृत प्रोटोकॉल में खातों की पहचान करने का कोई तरीका होना चाहिए, ताकि अन्य लोग उनके साथ इंटरैक्ट कर सकें, लेकिन सभी मौजूदा समाधानों में उपलब्ध एकमात्र पहचानकर्ता स्यूडोरैंडम हैश है जैसे `1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy`। आदर्श रूप से, कोई "जॉर्ज" जैसे नाम के साथ एक खाता रखने में सक्षम होना चाहेगा। हालांकि, समस्या यह है कि अगर एक व्यक्ति "जॉर्ज" नाम से अकाउंट बना सकता है, तो कोई अन्य व्यक्ति उसी प्रक्रिया का उपयोग करके अपने लिए भी "जॉर्ज" को पंजीकृत कर सकता है और उसकी नकल कर सकता है। इसका इकलौता समाधान फ़र्स्ट-टू-फ़ाइल प्रतिमान है, जहां पहला रजिस्टर सफल होता है और दूसरा विफल - यह समस्या Bitcoin सर्वसम्मति प्रोटोकॉल के लिए बिल्कुल उपयुक्त है। Namecoin इस तरह के विचार का उपयोग करते हुए नाम पंजीकरण सिस्टम का सबसे पुराना और सबसे सफल कार्यान्वयन है। +- **रंगीन सिक्के**[रंगीन सिक्कों](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) का उद्देश्य एक प्रोटोकॉल के रूप में काम करना है, जिससे लोगों को अपनी खुद की डिजिटल मुद्राएं बनाने की अनुमति मिल सके - या, Bitcoin ब्लॉकचेन पर एक इकाई वाली मुद्रा, डिजिटल टोकन के अहम मामले में। रंगीन सिक्कों के प्रोटोकॉल में, एक खास Bitcoin UTXO को सार्वजनिक रूप से रंग प्रदान करके एक नई मुद्रा "जारी" की जाती है, और प्रोटोकॉल पुनरावर्ती रूप से अन्य UTXO के रंग को उन इनपुट के रंग के समान परिभाषित करता है, जो उन्हें बनाने वाले लेनदेन ने खर्च किए हैं (मिश्रित-रंग इनपुट के मामले में कुछ खास नियम लागू होते हैं)। इससे उपयोगकर्ताओं को केवल एक खास रंग के UTXO वाले वॉलेट को बनाए रखने और उन्हें नियमित bitcoin की तरह भेजने की अनुमति मिलती है, जो उन्हें प्राप्त होने वाले किसी भी UTXO का रंग निर्धारित करने के लिए ब्लॉकचेन के माध्यम से बैकट्रैकिंग करता है। +- **Metacoins** - metacoin के पीछे विचार यह है कि एक प्रोटोकॉल हो जो Bitcoin के शीर्ष पर हो, जो मेटाकॉइन लेनदेन को स्टोर करने के लिए Bitcoin लेनदेन का उपयोग करता हो, लेकिन इसमें एक अलग स्टेट ट्रांज़िशन फ़ंक्शन हो, `APPLY'`। चूँकि मेटाकॉइन प्रोटोकॉल अमान्य मेटाकॉइन लेनदेन को Bitcoin ब्लॉकचेन में दिखने से नहीं रोक सकता है, इसलिए एक नियम जोड़ा गया है कि अगर `APPLY'(S,TX)` कोई गड़बड़ी लौटाता है, तो प्रोटोकॉल डिफ़ॉल्ट रूप से `APPLY'(S,TX) = S` हो जाता है। यह एक मनमाना क्रिप्टोकरेंसी प्रोटोकॉल बनाने के लिए एक आसान सिस्टम उपलब्ध कराता है, जिसमें शायद बेहतरीन विशेषताएं होंगी जिन्हें Bitcoin के अंदर लागू नहीं किया जा सकता है, लेकिन बहुत कम विकास की लागत के साथ क्योंकि खनन और नेटवर्किंग की समस्याओं को पहले से ही Bitcoin प्रोटोकॉल द्वारा नियंत्रित किया जाता है। Metacoin का उपयोग कुछ प्रकार के वित्तीय अनुबंधों, नाम पंजीकरण और विकेन्द्रीकृत विनिमयों को लागू करने के लिए किया गया है। + +इस प्रकार, सामान्य तौर पर, सर्वसम्मति प्रोटोकॉल को तौयार करने के लिए दो दृष्टिकोण हैं: एक स्वतंत्र नेटवर्क को तैयार करना, और Bitcoin के सबसे ऊपर एक प्रोटोकॉल तैयार करना। पहला दृष्टिकोण, Namecoin जैसे एप्लिकेशन के मामले में उचित तरीके से सफल होते हुए भी, लागू करने में समस्या होती है; हर व्यक्तिगत कार्यान्वयन के लिए एक स्वतंत्र ब्लॉकचेन को बूटस्ट्रैप करने की आवश्यकता होती है, साथ ही सभी आवश्यक स्टेट ट्रांज़िशन और नेटवर्किंग कोड का निर्माण और परीक्षण भी करना होता है। इसके अतिरिक्त, हम भविष्यवाणी करते हैं कि विकेन्द्रीकृत सर्वसम्मति प्रौद्योगिकी के लिए एप्लिकेशन का ग्रुप एक शक्ति कानून वितरण का पालन करेगा, जहां ज़्यादातर अनुप्रयोग अपने स्वयं के ब्लॉकचेन की गारंटी देने के लिए बहुत छोटे होंगे, और हम देखते हैं कि विकेन्द्रीकृत एप्लिकेशन के बड़े वर्ग मौजूद हैं, विशेष रूप से विकेन्द्रीकृत स्वायत्त संगठन, जिन्हें एक दूसरे के साथ बातचीत करने की आवश्यकता है। + +दूसरी ओर, Bitcoin-आधारित दृष्टिकोण में यह गड़बड़ी है कि इसमें Bitcoin की सरलीकृत भुगतान सत्यापन सुविधाएं नहीं हैं। SPV, Bitcoin के लिए काम करता है, क्योंकि यह वैधता के लिए प्रॉक्सी के रूप में ब्लॉकचेन की गहराई का उपयोग कर सकता है; किसी बिंदु पर, जब पिछले लेनदेन किए हुए काफी समय हो जाता है, तो यह कहना सुरक्षित है कि वे मान्य रूप से स्टेट का हिस्सा थे। दूसरी ओर, ब्लॉकचेन-आधारित मेटा-प्रोटोकॉल ब्लॉकचेन को उन लेनदेन को शामिल न करने के लिए बाध्य नहीं कर सकते जो उनके अपने प्रोटोकॉल के मामले में मान्य नहीं हैं। इसलिए, एक पूरी तरह सुरक्षित SPV मेटा-प्रोटोकॉल कार्यान्वयन को Bitcoin ब्लॉकचेन की शुरुआत तक पीछे की ओर स्कैन करने की आवश्यकता होगी, ताकि यह निर्धारित किया जा सके कि कुछ लेनदेन वैध हैं या नहीं। वर्तमान में, Bitcoin-आधारित मेटा-प्रोटोकॉल के सभी "हल्के" कार्यान्वयन डेटा प्रदान करने के लिए एक विश्वसनीय सर्वर पर निर्भर करते हैं, जो यकीनन एक अत्यधिक उप-इष्टतम परिणाम है, खासकर जब क्रिप्टोकरेंसी का एक प्राथमिक उद्देश्य विश्वास की आवश्यकता को समाप्त करना है। + +### स्क्रिप्टिंग {#scripting} + +किसी भी विस्तार के बिना भी, Bitcoin प्रोटोकॉल असल में "स्मार्ट कॉन्ट्रैक्ट्स" की अवधारणा के एक कमजोर वर्जन को सुविधाजनक बनाता है। Bitcoin में UTXO का मालिकाना हक न केवल सार्वजनिक कुंजी के द्वारा हो सकता है, बल्कि एक सरल स्टैक-आधारित प्रोग्रामिंग भाषा में व्यक्त एक अधिक जटिल स्क्रिप्ट द्वारा भी हो सकता है। इस प्रतिमान में, लेनदेन से जुड़े व्यय जो UTXO को स्क्रिप्ट को संतुष्ट करने वाला डेटा प्रदान करना चाहिए। असल में, यहां तक ​​कि बुनियादी सार्वजनिक कुंजी के मालिकाना हक वाले सिस्टम को भी एक स्क्रिप्ट के माध्यम से लागू किया जाता है: स्क्रिप्ट एक दीर्घवृत्तीय वक्र हस्ताक्षर को इनपुट के रूप में लेती है, उसे लेनदेन और UTXO के मालिकाना हक वाले पते के विरुद्ध सत्यापित करती है, और सत्यापन सफल होने पर 1 और अन्यथा 0 लौटाती है। अलग-अलग अतिरिक्त उपयोग मामलों के लिए अन्य, अधिक जटिल, स्क्रिप्ट मौजूद हैं। उदाहरण के लिए, कोई ऐसी स्क्रिप्ट बना सकता है जिसमें सत्यापन के लिए दिए गए तीन निजी कुंजियों में से दो के हस्ताक्षर की आवश्यकता होती है ("मल्टीसिग"), यह सेटअप कॉर्पोरेट खातों, सुरक्षित बचत खातों और कुछ व्यापारी एस्क्रो स्टेट के लिए उपयोगी है। स्क्रिप्ट का उपयोग कम्प्यूटेशनल समस्याओं के समाधान के लिए इनाम का भुगतान करने के लिए भी किया जा सकता है, और यहां तक ​​कि एक स्क्रिप्ट भी बनाई जा सकती है जो कुछ इस तरह कहती है "यह Bitcoin UTXO आपका है अगर आप एक SPV प्रमाण प्रदान कर सकते हैं कि आपने इस मूल्यवर्ग का एक डॉगकॉइन लेनदेन मुझे भेजा है", अनिवार्य रूप से विकेन्द्रीकृत क्रॉस-क्रिप्टोकरेंसी एक्सचेंज की अनुमति देता है। + +हालाँकि, Bitcoin में लागू की गई स्क्रिप्टिंग भाषा में कई महत्वपूर्ण सीमाएं हैं: + +- **ट्यूरिंग की पूर्णता का अभाव** - मतलब, हालांकि Bitcoin स्क्रिप्टिंग भाषा द्वारा समर्थित संगणना का एक बड़ा उपसमूह है, फिर भी यह लगभग सभी चीज़ों का समर्थन नहीं करता है। मुख्य श्रेणी जो गायब है वह है लूप्स। यह लेन-देन सत्यापन के दौरान अनंत लूप से बचने के लिए किया जाता है; सैद्धांतिक रूप से यह स्क्रिप्ट प्रोग्रामरों के लिए एक पार करने योग्य बाधा है, क्योंकि किसी भी लूप को केवल एक if स्टेटमेंट के साथ अंतर्निहित कोड को कई बार दोहराकर अनुकरण किया जा सकता है, लेकिन यह उन स्क्रिप्टों की ओर ले जाता है जो बहुत जगह-अपर्याप्त हैं। उदाहरण के लिए, एक वैकल्पिक अण्डाकार वक्र हस्ताक्षर एल्गोरिथ्म को लागू करने के लिए संभवतः 256 बार-बार गुणा दौर की आवश्यकता होगी, जो सभी व्यक्तिगत रूप से कोड में शामिल हैं। +- **वैल्यू-ब्लाइंडनेस** - वापस ली जा सकने वाली राशि पर ठीक-ठाक नियंत्रण प्रदान करने के लिए UTXO स्क्रिप्ट का कोई तरीका नहीं है। उदाहरण के लिए, एक ओरैकल कॉन्ट्रैक्ट का उपयोग का एक बेहतरीन मामला एक हेजिंग कॉन्ट्रैक्ट होगा, जहाँ A और B $1000 मूल्य के BTC जमा करते हैं और 30 दिनों के बाद स्क्रिप्ट $1000 मूल्य के BTC को A को भेजती है और शेष राशि को B को भेजती है। इसके लिए 1 BTC का USD में मूल्य निर्धारित करने के लिए एक ओरैकल की आवश्यकता होगी, लेकिन तब भी यह वर्तमान में उपलब्ध पूरी तरह से केंद्रीकृत समाधानों की तुलना में विश्वास और बुनियादी ढांचे की आवश्यकता के मामले में एक बहुत बड़ा सुधार है। हालांकि, क्योंकि UTXO सभी या कुछ भी नहीं होते हैं, इसे हासिल करने का एकमात्र तरीका बहुत ही अप्रभावी हैक के माध्यम से होता है जिसमें अलग-अलग मूल्यवर्ग के कई UTXO होते हैं (उदाहरण के लिए, 2 के हर k तक 30 तक का एक UTXO) और ओरेकल यह चुनता है कि किस UTXO को A को भेजना है और किसे B को। +- **स्टेट की कमी** - UTXO या तो खर्च किया जा सकता है या खर्च नहीं किया जा सकता है; बहु-चरण अनुबंध या स्क्रिप्ट के लिए कोई अवसर नहीं है जो किसी अन्य आंतरिक स्थिति को इससे परे रखता है। यह बहु-स्तरीय विकल्प अनुबंध, विकेंद्रीकृत विनिमय प्रस्ताव या दो-चरण क्रिप्टोग्राफ़िक प्रतिबद्धता प्रोटोकॉल (सुरक्षित गणना पुरस्कारों के लिए आवश्यक) बनाना मुश्किल बना देता है। इसका मतलब यह भी है कि UTXO का उपयोग केवल साधारण, एकमुश्त अनुबंध बनाने के लिए किया जा सकता है और अधिक जटिल "स्टेटफ़ुल" अनुबंध, जैसे विकेंद्रीकृत संगठन, नहीं बनाए जा सकते हैं, और मेटा-प्रोटोकॉल्स को लागू करना कठिन बना देता है। बाइनरी स्टेट और वैल्यू-ब्लाइंडनेस का संयोजन यह भी दर्शाता है कि एक और महत्वपूर्ण एप्लिकेशन, निकासी सीमाएं, असंभव हैं। +- **ब्लॉकचेन-ब्लाइंडनेस** - UTXO ब्लॉकचेन डेटा, जैसे नॉन्स, टाइमस्टैम्प और पिछले ब्लॉक हैश को समझ नहीं पाते हैं। इससे जुए तथा कई अन्य श्रेणियों में अनुप्रयोगों की संख्या गंभीर रूप से सीमित हो जाती है, क्योंकि इससे स्क्रिप्टिंग भाषा को सियुडोरैंडम के संभावित मूल्यवान स्रोत से वंचित कर दिया जाता है। + +इस प्रकार, हम शीर्ष पर उन्नत एप्लिकेशन के निर्माण के लिए तीन दृष्टिकोण देखते हैं क्रिप्टोक्यूरेंसी का: शीर्ष पर स्क्रिप्टिंग का उपयोग करके एक नया ब्लॉकचेन बनाना Bitcoin, और Bitcoin के शीर्ष पर एक मेटा-प्रोटोकॉल का निर्माण। एक नया निर्माण ब्लॉकचेन फीचर सेट के निर्माण में असीमित स्वतंत्रता की अनुमति देता है, लेकिन विकास के समय, बूटस्ट्रैपिंग प्रयास और सुरक्षा की कीमत पर। स्क्रिप्टिंग का उपयोग करना कार्यान्वयन और मानकीकरण के लिए आसान है, लेकिन इसकी क्षमताएं बहुत सीमित हैं, और मेटा-प्रोटोकॉल, आसान होते हुए भी, मापनीयता से जुड़ी सम्सयाओं से प्रभावित हैं। एथेरियम के साथ, हम एक वैकल्पिक ढांचा बनाने का इरादा रखते हैं जो विकास की आसानी के साथ-साथ और भी मजबूत लाइट क्लाइंट गुणों में और भी अधिक लाभ प्रदान करता है, जबकि एक ही समय में एप्लिकेशन को आर्थिक वातावरण और ब्लॉकचेन सुरक्षा साझा करने की अनुमति देता है। + +## इथेरियम {#ethereum} + +एथेरियम का उद्देश्य विकेन्द्रीकृत एप्लिकेशन के निर्माण के लिए एक वैकल्पिक प्रोटोकॉल बनाना है, जो विभिन्न प्रकार के समझौतों को उपलब्ध कराता है, जिनके बारे में हमारा मानना ​​है कि वे विकेन्द्रीकृत एप्लिकेशन के एक बड़े वर्ग के लिए बहुत उपयोगी होंगे, तथा उन स्थितियों पर विशेष जोर दिया जाएगा जहां तेजी से विकास का समय, छोटे और कम उपयोग किए जाने वाले एप्लिकेशन के लिए सुरक्षा, तथा विभिन्न एप्लिकेशन की बहुत कुशलतापूर्वक मिलकर काम करने की क्षमता महत्वपूर्ण है। एथेरियम ऐसा एक अमूर्त आधारभूत परत का निर्माण करके करता है: एक ब्लॉकचेन जिसमें ट्यूरिंग-पूर्ण प्रोग्रामिंग भाषा अंतर्निहित होती है, जो किसी को भी स्मार्ट अनुबंध और विकेन्द्रीकृत एप्लिकेशन लिखने की अनुमति देती है, जहां वे स्वामित्व, लेनदेन प्रारूप और स्टेट ट्रांज़िशन संबंधी कामों के लिए अपने स्वयं के मनमाने नियम बना सकते हैं। Namecoin का एक बुनियादी वर्जन दो पंक्तियों के कोड में लिखा जा सकता है, और अन्य प्रोटोकॉल जैसे मुद्राएं और प्रतिष्ठा वाले सिस्टम बीस पंक्तियों से कम मे बनाए जा सकते है। स्मार्ट अनुबंध, क्रिप्टोग्राफ़िक "बॉक्स" जिसमें मूल्य शामिल होता है तथा जो केवल कुछ निश्चित शर्तों के पूरा होने पर ही खुलता है, उसे भी प्लेटफॉर्म के शीर्ष पर बनाया जा सकता है, तथा इसमें Bitcoin स्क्रिप्टिंग की तुलना में कहीं अधिक शक्ति होती है, क्योंकि इसमें ट्यूरिंग-पूर्णता, मूल्य-जागरूकता, ब्लॉकचेन-जागरूकता और स्थिति की अतिरिक्त शक्तियां होती हैं। + +### एथेरियम खाता {#ethereum-accounts} + +एथेरियम में, स्थिति "खातों" नामक वस्तुओं से बनी होती है, प्रत्येक खाते का 20-बाइट पता होता है और स्थिति परिवर्तन सीधे खातों के बीच मूल्य और जानकारी के स्थानांतरण होते हैं। एक एथेरियम खाता चार क्षेत्रों में बाँटा गया होता है: + +- **नॉन्स**, एक काउंटर जो यह सुनिश्चित करता है कि प्रत्येक लेनदेन केवल एक बार ही संसाधित किया जा सके +- खाते का वर्तमान **एथर बैलेंस** +- खाते का **अनुबंध कोड**, यदि मौजूद हो +- खाते का **स्टोरेज** (डिफ़ॉल्ट रूप से खाली) + +"एथर" एथेरियम का मुख्य आंतरिक क्रिप्टो-ईंधन है, और इसका उपयोग लेनदेन शुल्क चुकाने के लिए किया जाता है। सामान्य रूप से, दो प्रकार के खाते होते हैं: **बाहरी रूप से स्वामित्व वाले खाते**, जो निजी कुंजी द्वारा नियंत्रित होते हैं, और **अनुबंध खाते**, जो अपने अनुबंध कोड द्वारा नियंत्रित होते हैं। बाहरी रूप से स्वामित्व वाले खाते में कोई कोड नहीं होता है, तथा कोई व्यक्ति लेनदेन बनाकर और उस पर हस्ताक्षर करके बाहरी स्वामित्व वाले खाते से संदेश भेज सकता है; अनुबंध खाते में, जब भी अनुबंध खाते को कोई संदेश प्राप्त होता है, तो उसका कोड चालू हो जाता है, जिससे वह आंतरिक स्टोरेज को पढ़ और लिख सकता है तथा अन्य संदेश भेज सकता है या बदले में अनुबंध बना सकता है। + +ध्यान दें कि एथेरियम में "अनुबंधों" को ऐसी चीज़ के रूप में नहीं देखा जाना चाहिए जिसे "पूरा" किया जाना चाहिए या "अनुपालन" किया जाना चाहिए; बल्कि, वे "स्वायत्त एजेंट" की तरह हैं जो एथेरियम निष्पादन वातावरण के अंदर रहते हैं, हमेशा एक संदेश या लेनदेन द्वारा "पोक" किए जाने पर कोड के एक विशिष्ट टुकड़े को निष्पादित करते हैं, और अपने खुद के ईथर बैलेंस और अपने खुद के कुंजी/मूल्य स्टोर पर सीधा नियंत्रण रखते हैं ताकि लगातार चर का ट्रैक रखा जा सके। + +### संदेश और लेन-देन {#messages-and-transactions} + +"लेन-देन" शब्द का उपयोग एथेरियम में हस्ताक्षरित डेटा पैकेज को संदर्भित करने के लिए किया जाता है जो बाहरी स्वामित्व वाले खाते से भेजे जाने वाले संदेश को संग्रहीत करता है। लेन-देन में शामिल है: + +- संदेश का प्राप्तकर्ता +- प्रेषक की पहचान करने वाला एक हस्ताक्षर +- प्रेषक से प्राप्तकर्ता को स्थानांतरित करने के लिए एथर की मात्रा +- एक वैकल्पिक डेटा फ़ील्ड +- `STARTGAS` मान, जो अधिकतम कम्प्यूटेशनल स्टेप की संख्या को दर्शाता है जिसे लेनदेन निष्पादन के लिए अनुमति दी जाती है +- `GASPRICE` मान, जो प्रेषक द्वारा हर कम्प्यूटेशनल स्टेप भुगतान किए जाने वाले शुल्क को दर्शाता है + +पहले तीन किसी भी क्रिप्टोकरेंसी में अपेक्षित मानक क्षेत्र हैं। डेटा फ़ील्ड में डिफ़ॉल्ट रूप से कोई काम नहीं होता है, लेकिन वर्चुअल मशीन में एक ऑपकोड होता है जिसका उपयोग करके एक अनुबंध डेटा तक पहुंच सकता है; एक उदाहरण के उपयोग के मामले के रूप में, अगर कोई अनुबंध एक ऑन-ब्लॉकचेन डोमेन पंजीकरण सेवा के रूप में काम कर रहा है, तो यह दो "फ़ील्ड" वाले डेटा के बारे में जानकारी देना चाह सकता है, पहला फ़ील्ड पंजीकरण के लिए एक डोमेन है और दूसरा फ़ील्ड इसे पंजीकृत करने के लिए IP एड्रेस है। अनुबंध संदेश डेटा से इन मूल्यों को पढ़ेगा और उन्हें उचित रूप से स्टोरेज में रखेगा। + +एथेरियम के सेवा-विरोधी मॉडल के लिए `STARTGAS` और `GASPRICE` फ़ील्ड महत्वपूर्ण हैं। कोड में आकस्मिक या शत्रुतापूर्ण लंबे समय तक रहने वाले लूप या अन्य कम्प्यूटेशनल अपव्यय को रोकने के लिए, हर लेनदेन को एक सीमा निर्धारित करने की आवश्यकता होती है कि वह कोड निष्पादन के कितने कम्प्यूटेशनल स्टेप का उपयोग कर सकता है। गणना की मौलिक इकाई "गैस" है; आमतौर पर, एक कम्प्यूटेशनल स्टेप की लागत 1 गैस होती है, लेकिन कुछ संचालनों में गैस की मात्रा अधिक होती है क्योंकि वे अधिक कम्प्यूटेशनल रूप से महंगे होते हैं, या डेटा की मात्रा को बढ़ाते हैं जिसे स्टेट के हिस्से के रूप में स्टोर किया जाना चाहिए। लेन-देन डेटा में प्रत्येक बाइट के लिए 5 गैस का शुल्क भी है। शुल्क वाले सिस्टम का उद्देश्य हमलावर को उनके द्वारा उपभोग किए जाने वाले प्रत्येक संसाधन के लिए आनुपातिक रूप से भुगतान करने के लिए बाध्य करना है, जिसमें संगणन, बैंडविड्थ और स्टोरेज शामिल हैं; इसलिए, कोई भी लेनदेन जिसके कारण नेटवर्क इन संसाधनों में से किसी की भी अधिक मात्रा का उपभोग करता है, उस पर गैस शुल्क लगभग बढ़ोतरी के समानुपातिक होना चाहिए। + +### संदेश {#messages} + +अनुबंधों में अन्य अनुबंधों को "संदेश" भेजने की क्षमता होती है। संदेश आभासी वस्तुएँ हैं जो कभी क्रमबद्ध नहीं होती हैं और केवल एथेरियम निष्पादन वातावरण में मौजूद होती हैं। एक संदेश में शामिल है: + +- संदेश भेजने वाला (अनिहित) +- संदेश का प्राप्तकर्ता +- संदेश के साथ स्थानांतरित करने के लिए ईथर की मात्रा +- एक वैकल्पिक डेटा फ़ील्ड +- `STARTGAS` मान + +मूल रूप से, संदेश एक लेन-देन की तरह होता है, सिवाय इसके कि यह किसी बाहरी कर्ता द्वारा नहीं बल्कि एक अनुबंध द्वारा तैयार किया जाता है। एक संदेश तब मिलता है, जब वर्तमान में कोड निष्पादित करने वाला अनुबंध, `CALL` ओपकोड को निष्पादित करता है, जो एक संदेश का उत्पादन और निष्पादन करता है। लेन-देन की तरह, एक संदेश प्राप्तकर्ता के खाते में अपना कोड चलाता है। इस प्रकार, अनुबंधों के अन्य अनुबंधों के साथ ठीक उसी तरह संबंध हो सकते हैं जैसे बाहरी कर्ता के होते हैं। + +ध्यान दें कि किसी लेन-देन या अनुबंध द्वारा आवंटित गैस भत्ता उस लेन-देन द्वारा खपत की गई कुल गैस और सभी उप-निष्पादनों पर लागू होता है। उदाहरण के लिए, अगर एक बाहरी कर्ता A, B को 1000 गैस के साथ एक लेनदेन भेजता है, और B C को संदेश भेजने से पहले 600 गैस का उपयोग करता है, और C का आंतरिक निष्पादन वापस लौटने से पहले 300 गैस का उपयोग करता है, तो B गैस समाप्त होने से पहले और 100 गैस खर्च कर सकता है। + +### एथेरियम स्टेट ट्रांजिशन फ़ंक्शन {#ethereum-state-transition-function} + +![ईथर स्टेट ट्रांजिशन](./ether-state-transition.png) + +एथेरियम स्टेट ट्रांजिशन फ़ंक्शन, `APPLY(S,TX) -> S'` को निम्नानुसार परिभाषित किया जा सकता हैं: + +1. जाँच करें कि क्या लेन-देन अच्छी तरह से तैयार है (मतलब मूल्यों की सही संख्या है) हस्ताक्षर मान्य है, और नोन्स प्रेषक के खाते में नोन्स से मेल खाता है। अगर नहीं, तो एक गड़बड़ी वापस करें। +2. लेन-देन शुल्क की गणना `STARTGAS * GASPRICE` के रूप में करें, और हस्ताक्षर से भेजने का पता तय करें। प्रेषक के खाते की शेष राशि से शुल्क घटाएं और प्रेषक की राशि बढ़ाएं। अगर खर्च करने के लिए पर्याप्त शेष राशि नहीं है, तो एक गड़बड़ी वापस करें। +3. `GAS = STARTGAS` आरंभ करें, और लेन-देन में बाइट्स के लिए भुगतान करने के लिए प्रति बाइट गैस की एक निश्चित मात्रा लें। +4. लेन-देन मूल्य को प्रेषक के खाते से प्राप्तकर्ता खाते में स्थानांतरित करें। अगर प्राप्तकर्ता खाता अभी तक मौजूद नहीं है, तो उसे बनाएँ। अगर प्राप्तकर्ता खाता एक अनुबंध है, तो अनुबंध का कोड या तो पूरा होने तक या जब तक निष्पादन गैस समाप्त नहीं हो जाता, तब तक चलाएं। +5. अगर मूल्य अंतरण विफल हो जाता है, क्योंकि प्रेषक के पास पर्याप्त पैसा नहीं था, या कोड निष्पादन गैस से बाहर हो गया, तो शुल्क के भुगतान को छोड़कर स्टेट से जुड़े सभी बदलावों को वापस करें, और शुल्क को माईनर के खाते में जोड़ें। +6. नहीं तो, शेष गैस के लिए शुल्क भेजने वाले को वापस कर दें और गैस की खपत के लिए भुगतान शुल्क माईनर को भेज दें। + +उदाहरण के लिए, मान लीजिए कि अनुबंध का कोड है: + +```py +if !self.storage[calldataload(0)]: + self.storage[calldataload(0)] = calldataload(32) +``` + +ध्यान दें कि असल में अनुबंध कोड निम्न-स्तरीय EVM कोड में लिखा जाता है; यह उदाहरण स्पष्टता के लिए हमारी उच्च-स्तरीय भाषाओं में से एक, सर्पेंट में लिखा गया है, और इसे EVM कोड में इकट्ठा किया जा सकता है। मान लीजिए कि अनुबंध का स्टोरेज खाली शुरू होता है, और 10 ईथर मूल्य, 2000 गैस, 0.001 ईथर गैस मूल्य, और 64 बाइट डेटा के साथ एक लेनदेन भेजा जाता है, जिसमें बाइट 0-31 संख्या `2` का प्रतिनिधित्व करते हैं और बाइट 32-63 स्ट्रिंग `CHARLIE` का प्रतिनिधित्व करते हैं। इस मामले में स्टेट ट्रांज़िशन फ़ंक्शन के लिए प्रक्रिया निम्नानुसार है: + +1. जाँच करें कि लेनदेन मान्य और सही तरीके से बनाया गया है। +2. जाँच करें कि लेनदेन भेजने वाले के पास कम से कम 2000 \* 0.001 = 2 ईथर है। अगर ऐसा है, तो भेजने वाले के खाते से 2 ईथर घटा दें। +3. गैस = 2000 शुरू करें; यह मानते हुए कि लेनदेन 170 बाइट लंबा है और बाइट-शुल्क 5 है, 850 घटाएं ताकि 1150 गैस बचा रहे। +4. भेजने वाले के खाते से 10 और ईथर घटाएं, और इसे अनुबंध के खाते में जोड़ें। +5. कोड चलाएं। इस मामले में, यह सरल है: यह जाँचता है कि क्या अनुबंध का संग्रहण इंडेक्स `2` पर उपयोग किया जाता है, देखता है कि ऐसा नहीं है, और इसलिए यह इंडेक्स `2` पर संग्रहण को मूल्य `CHARLIE` पर सेट करता है। मान लीजिए कि इसमें 187 गैस लगता है, तो शेष गैस की मात्रा 1150 - 187 = 963 है +6. भेजने वाले के खाते में 963 \* 0.001 = 0.963 ईथर वापस जोड़ें, और परिणामी स्थिति लौटाएं। + +अगर लेनदेन के प्राप्त करने वाले छोर पर कोई अनुबंध नहीं था, तो कुल लेनदेन शुल्क बस प्रदान किए गए `GASPRICE` को लेनदेन की बाइट में लंबाई से गुणा किया जाएगा, और लेनदेन के साथ भेजा गया डेटा अप्रासंगिक होगा। + +ध्यान दें कि संदेश वापसी के संदर्भ में लेनदेन के समान काम करते हैं: अगर कोई संदेश निष्पादन गैस से बाहर हो जाता है, तो उस संदेश का निष्पादन, और उस निष्पादन द्वारा ट्रिगर किए गए अन्य सभी निष्पादन वापस हो जाते हैं, लेकिन मूल निष्पादन को वापस होने की आवश्यकता नहीं होती। इसका मतलब है कि एक अनुबंध के लिए दूसरे अनुबंध को कॉल करना "सुरक्षित" है, क्योंकि अगर A, B को G गैस के साथ कॉल करता है तो A के निष्पादन को अधिकतम G गैस खोने की गारंटी है। अंत में, ध्यान दें कि एक ऑपकोड है, `CREATE`, जो एक अनुबंध बनाता है; इसकी निष्पादन तंत्र आम तौर पर `CALL` के समान होता है, अपवाद के साथ कि निष्पादन का आउटपुट नए तैयार किए गए अनुबंध के कोड को निर्धारित करता है। + +### कोड निष्पादन {#code-execution} + +एथेरियम अनुबंधों में कोड एक निम्न-स्तरीय, स्टैक-आधारित बाइटकोड भाषा में लिखा जाता है, जिसे "एथेरियम वर्चुअल मशीन कोड" या "EVM कोड" के रूप में जाना जाता है। कोड बाइट्स की एक सीरीज़ से बना होता है, जहां प्रत्येक बाइट एक ऑपरेशन का प्रतिनिधित्व करता है। सामान्य तौर पर, कोड निष्पादन एक हमेशा चलने वाला लूप है जो वर्तमान प्रोग्राम काउंटर पर ऑपरेशन को बार-बार करने से बना होता है (जो शून्य से शुरू होता है) और फिर प्रोग्राम काउंटर को एक से बढ़ाता है, जब तक कि कोड का अंत न हो जाए या कोई गड़बड़ी या `STOP` या `RETURN` निर्देश का पता न चल जाए। ऑपरेशंस के पास डेटा स्टोर करने के लिए तीन प्रकार के स्थान तक पहुंच होती है: + +- **स्टैक**, एक लास्ट-इन-फ़र्स्ट-आउट कंटेनर जिसमें मान पुश और पॉप किए जा सकते हैं +- **मेमोरी**, एक अनंत विस्तार योग्य बाइट ऐरे +- अनुबंध का लंबे समय के लिए **स्टोरेज**, एक की/मूल्य स्टोर। स्टैक और मेमोरी के विपरीत, जो कंप्यूटेशन समाप्त होने के बाद रीसेट हो जाते हैं, स्टोरेज लंबे समय तक बना रहता है। + +कोड आने वाले संदेश के मूल्य, भेजने वाले और डेटा के साथ-साथ ब्लॉक हेडर डेटा तक भी पहुंच सकता है, और कोड आउटपुट के रूप में डेटा की एक बाइट ऐरे भी लौटा सकता है। + +EVM कोड के औपचारिक निष्पादन मॉडल आश्चर्यजनक रूप से सरल है। जब एथेरियम वर्चुअल मशीन चल रही होती है, तो इसकी पूरी कम्प्यूटेशनल स्थिति को ट्यूपल `(block_state, transaction, message, code, memory, stack, pc, gas)` द्वारा परिभाषित किया जा सकता है, जहां `block_state` वैश्विक स्थिति है जिसमें सभी खाते शामिल हैं और इसमें शेष राशि और स्टोरेज शामिल हैं। निष्पादन के हर दौर की शुरुआत में, वर्तमान निर्देश `code` के `pc` वें बाइट को लेकर पाया जाता है (या 0 अगर `pc >= len(code)`), और प्रत्येक निर्देश की अपनी परिभाषा होती है कि यह ट्यूपल को कैसे प्रभावित करता है। उदाहरण के लिए, `ADD` स्टैक से दो आइटम पॉप करता है और उनका योग पुश करता है, `गैस` को 1 से कम करता है और `pc` को 1 से बढ़ाता है, और `SSTORE` स्टैक से शीर्ष दो आइटम पॉप करता है और दूसरे आइटम को अनुबंध के स्टोरेज में पहले आइटम द्वारा निर्दिष्ट इंडेक्स पर डालता है। हालांकि, जस्ट-इन-टाइम कंपाइलेशन की मदद से एथेरियम वर्चुअल मशीन निष्पादन को अनुकूलित करने के कई तरीके हैं, एथेरियम का एक बुनियादी कार्यान्वयन कोड की कुछ सौ पंक्तियों में किया जा सकता है। + +### ब्लॉकचेन और माइनिंग {#blockchain-and-mining} + +![एथेरियम ब्लॉक एप्लाई डायग्राम](./ethereum-apply-block-diagram.png) + +एथेरियम ब्लॉकचेन कई मायनों में Bitcoin ब्लॉकचेन के समान है, हालांकि इसमें कुछ अंतर हैं। ब्लॉकचेन आर्किटेक्चर के संबंध में एथेरियम और Bitcoin के बीच मुख्य अंतर यह है कि Bitcoin के विपरीत, एथेरियम ब्लॉक में लेनदेन सूची और सबसे हाल की स्थिति दोनों की एक कॉपी होती है। इसके अलावा, दो अन्य मूल्य, ब्लॉक संख्या और कठिनाई, भी ब्लॉक में संग्रहीत किए जाते हैं। एथेरियम में बुनियादी ब्लॉक सत्यापन एल्गोरिथ्म निम्नानुसार है: + +1. जांचें कि संदर्भित पिछला ब्लॉक मौजूद है और मान्य है। +2. जांचें कि ब्लॉक का टाइमस्टैम्प संदर्भित पिछले ब्लॉक से अधिक है और भविष्य में 15 मिनट से कम है +3. जांचें कि ब्लॉक संख्या, कठिनाई, लेनदेन रूट, अंकल रूट और गैस सीमा (अलग-अलग निम्न-स्तरीय एथेरियम-विशिष्ट अवधारणाएं) मान्य हैं। +4. जाँचें कि ब्लॉक पर काम का सबूत मान्य है या नहीं। +5. पिछले ब्लॉक के अंत में `S[0]` स्टेट होने दें। +6. मान लें कि `TX` ब्लॉक की लेनदेन सूची है, जिसमें `n` लेनदेन हैं। सभी `i` के लिए `0...n-1` में, `S[i+1] = APPLY(S[i],TX[i]) सेट करें`। अगर कोई भी एप्लिकेशन गड़बड़ी लौटाता है, या इस बिंदु तक ब्लॉक में खपत की गई कुल गैस `GASLIMIT` से अधिक हो जाती है, तो गड़बड़ी लौटाएं। +7. मान लें कि `S_FINAL` `S[n]` है, लेकिन माईनर को भुगतान किए गए ब्लॉक पुरस्कार को जोड़कर। +8. जांचें कि स्थिति `S_FINAL` का मर्कल ट्री रूट ब्लॉक हेडर में प्रदान किए गए अंतिम स्टेट रूट के बराबर है। अगर ऐसा है, तो ब्लॉक मान्य है; नहीं तो, यह मान्य नहीं है। + +पहली नज़र में दृष्टिकोण बहुत ज़्यादा अक्षम लग सकता है, क्योंकि इसे प्रत्येक ब्लॉक के साथ पूरी स्थिति को संग्रहीत करने की आवश्यकता होती है, लेकिन वास्तविकता में दक्षता Bitcoin के समान होनी चाहिए। कारण यह है कि स्थिति ट्री संरचना में संग्रहीत की जाती है, और प्रत्येक ब्लॉक के बाद ट्री का केवल एक छोटा हिस्सा बदलने की आवश्यकता होती है। इस प्रकार, सामान्य रूप से, दो बगल वाले ब्लॉकों के बीच पेड़ का विशाल बहुमत समान होना चाहिए, और इसलिए डेटा को एक बार संग्रहीत किया जा सकता है और संकेतों का उपयोग करके दो बार संदर्भित किया जा सकता है (अर्थात्, सबट्री के हैश)। इस काम को पूरा करने के लिए एक विशेष प्रकार के ट्री "पेट्रिसिया ट्री" का उपयोग किया जाता है, जिसमें मेरकल वृक्ष की अवधारणा में बदलाव किया गया है, जिससे नोड्स को कुशलता से जोड़ा और हटाया जा सके, न केवल बदला जा सके। इसके अतिरिक्त, क्योंकि स्टेट की सभी जानकारी अंतिम ब्लॉक का हिस्सा है, इसलिए पूरे ब्लॉकचेन इतिहास को संग्रहीत करने की कोई आवश्यकता नहीं है - एक रणनीति जो, अगर इसे Bitcoin पर लागू किया जा सकता है, तो अंतरिक्ष में 5-20x बचत प्रदान करने के लिए गणना की जा सकती है। + +एक आम तौर पर पूछा जाने वाला प्रश्न भौतिक हार्डवेयर के संदर्भ में अनुबंध कोड को "कहाँ" निष्पादित किया जाता है। इसका एक सरल जवाब हैः अनुबंध कोड को निष्पादित करने की प्रक्रिया स्टेट ट्रांज़िशन फ़ंक्शन की परिभाषा का हिस्सा है, जो ब्लॉक सत्यापन एल्गोरिथ्म का हिस्सा है, इसलिए अगर कोई लेनदेन ब्लॉक `B` में जोड़ा जाता है, तो उस लेनदेन द्वारा उत्पन्न कोड निष्पादन सभी नोड्स द्वारा निष्पादित किया जाएगा, अब और भविष्य में, जो ब्लॉक `B` को डाउनलोड और मान्य करता है। + +## एप्लिकेशन {#applications} + +आम तौर पर, एथेरियम के तीन प्रकार के एप्लिकेशन होते हैं। पहली श्रेणी वित्तीय एप्लिकेशन है, जिससे उपयोगकर्ताओं को अपने पैसे का उपयोग करके अनुबंधों का प्रबंधन करने और उनमें प्रवेश करने के लिए अधिक बेहतरीन तरीके प्रदान करती है। इसमें उप-मुद्राएं, वित्तीय डेरिवेटिव, हेजिंग अनुबंध, बचत वॉलेट, वसीयत और अंततः पूर्ण पैमाने के रोज़गार संबंधी अनुबंधों के कुछ वर्ग भी शामिल हैं। दूसरी श्रेणी अर्ध-वित्तीय अनुप्रयोगों की है, जहां पैसा शामिल है लेकिन जो किया जा रहा है उसका एक भारी गैर-मौद्रिक पक्ष भी है; एक सही उदाहरण कम्प्यूटेशनल समस्याओं के समाधान के लिए खुद लागू होने वाले इनाम हैं। आखिर में, ऐसे एप्लिकेशन हैं जैसे ऑनलाइन मतदान और विकेंद्रीकृत शासन जो बिल्कुल भी वित्तीय नहीं हैं। + +### टोकन सिस्टम {#token-systems} + +ऑन-ब्लॉकचेन टोकन सिस्टम के कई एप्लिकेशन हैं जो USD या सोने जैसी संपत्तियों का प्रतिनिधित्व करने वाली उप-मुद्राओं से लेकर कंपनी के स्टॉक, स्मार्ट संपत्ति को दर्शाने वाले व्यक्तिगत टोकन, सुरक्षित अप्रतिकृत कूपन, और यहां तक कि पारंपरिक मूल्य से बिना किसी संबंध के टोकन सिस्टम तक फैले हुए हैं, जिनका उपयोग प्रोत्साहन के लिए पॉइंट सिस्टम के रूप में किया जाता है। एथेरियम में टोकन सिस्टम को लागू करना आश्चर्यजनक रूप से आसान है। समझने वाली मुख्य बात यह है कि एक मुद्रा, या टोकन सिस्टम, मूल रूप से एक डेटाबेस है जिसमें एक ऑपरेशन है: A से X इकाइयाँ घटाएँ और B को X इकाइयाँ दें, इस शर्त के साथ कि (i) लेनदेन से पहले A के पास कम से कम X इकाइयाँ थीं और (2) लेनदेन A द्वारा स्वीकृत है। एक टोकन सिस्टम को लागू करने के लिए इस तर्क को एक अनुबंध में लागू करना ही काफ़ी है। + +सर्पेंट में एक टोकन सिस्टम को लागू करने का बुनियादी कोड इस प्रकार दिखता है: + +```py +def send(to, value): + if self.storage[msg.sender] >= value: + self.storage[msg.sender] = self.storage[msg.sender] - value + self.storage[to] = self.storage[to] + value +``` + +यह अनिवार्य रूप से इस दस्तावेज़ में ऊपर वर्णित "बैंकिंग सिस्टम" स्टेट ट्रांजीशन फंक्शन का एक शाब्दिक कार्यान्वयन है। कोड की कुछ अतिरिक्त पंक्तियाँ जोड़ने की आवश्यकता है, ताकि पहले स्थान पर मुद्रा इकाइयों के वितरण के प्रारंभिक चरण और कुछ अन्य सीमांत मामलों के लिए प्रावधान किया जा सके, और आदर्श रूप से एक फ़ंक्शन जोड़ा जाएगा जो अन्य अनुबंधों को किसी पते के शेष की जांच करने की अनुमति देगा। हालांकि, बस इतना ही है। सैद्धांतिक रूप से, उप-मुद्राओं के रूप में कार्य करने वाले एथेरियम-आधारित टोकन सिस्टम में संभावित रूप से एक अन्य महत्वपूर्ण विशेषता हो सकती है जो ऑन-चेन Bitcoin-आधारित मेटा-मुद्राओं में नहीं है: उस मुद्रा में सीधे लेनदेन शुल्क का भुगतान करने की क्षमता। इसे इस तरह से लागू किया जाएगा कि अनुबंध एक ईथर शेष बनाए रखेगा जिससे वह शुल्क का भुगतान करने के लिए उपयोग किए गए ईथर को प्रेषक को वापस कर देगा, और यह शुल्क में ली जाने वाली आंतरिक मुद्रा इकाइयों को एकत्र करके और उन्हें एक निरंतर चलने वाली नीलामी में फिर से बेचकर इस शेष को दोबारा भर देगा। इस प्रकार उपयोगकर्ताओं को अपने खातों को ईथर के साथ "सक्रिय" करने की आवश्यकता होगी, लेकिन एक बार ईथर वहां होने के बाद यह फिर से उपयोग योग्य होगा, क्योंकि अनुबंध हर बार इसे वापस कर देगा। + +### वित्तीय डेरिवेटिव और स्थिर-मूल्य मुद्राएं {#financial-derivatives-and-stable-value-currencies} + +वित्तीय डेरिवेटिव "स्मार्ट अनुबंध" के सबसे आम एप्लिकेशन हैं, और कोड में लागू करने के लिए सबसे सरल में से एक हैं। वित्तीय अनुबंधों को लागू करने में मुख्य चुनौती यह है कि उनमें से ज़्यादातर को एक बाहरी मूल्य टिकर के संदर्भ की आवश्यकता होती है; उदाहरण के लिए, एक बहुत वांछनीय एप्लिकेशन एक स्मार्ट अनुबंध है जो अमेरिकी डॉलर के संबंध में ईथर (या किसी अन्य क्रिप्टोकरेंसी) की अस्थिरता के खिलाफ बचाव करता है, लेकिन ऐसा करने के लिए अनुबंध को यह जानने की आवश्यकता होती है कि ETH/USD का मूल्य क्या है। ऐसा करने का सबसे सरल तरीका एक खास पार्टी (जैसे NASDAQ) द्वारा बनाए रखे गए एक "डेटा फीड" अनुबंध के माध्यम से है जिसे इस तरह से डिज़ाइन किया गया है कि उस पार्टी के पास आवश्यकतानुसार अनुबंध को अपडेट करने की क्षमता है, और एक इंटरफ़ेस प्रदान करता है जो अन्य अनुबंधों को उस अनुबंध को एक संदेश भेजने और एक प्रतिक्रिया प्राप्त करने की अनुमति देता है जो कीमत प्रदान करता है। + +उस महत्वपूर्ण घटक को देखते हुए, हेजिंग अनुबंध इस प्रकार दिखेगा: + +1. पार्टी A के 1000 ईथर इनपुट करने की प्रतीक्षा करें। +2. पार्टी B के 1000 ईथर इनपुट करने की प्रतीक्षा करें। +3. डेटा फीड अनुबंध से पूछताछ करके गणना किए गए 1000 ईथर के USD मूल्य को स्टोरेज में रिकॉर्ड करें, मान लें कि यह $x है। +4. 30 दिनों के बाद, A या B को अनुबंध को "फिर से चालू" करने की अनुमति दें ताकि A को $x मूल्य का ईथर (नई कीमत प्राप्त करने के लिए डेटा फ़ीड अनुबंध से फिर से पूछताछ करके गणना की गई) और शेष B को भेजा जा सके। + +ऐसे अनुबंध की क्रिप्टो-वाणिज्य में महत्वपूर्ण संभावना होगी। क्रिप्टोकरेंसी के बारे में बताई जाने वाली मुख्य समस्याओं में से एक यह तथ्य है कि यह अस्थिर है; हालांकि, कई उपयोगकर्ता और व्यापारी क्रिप्टोग्राफिक संपत्तियों के साथ व्यवहार करने की सुरक्षा और सुविधा चाहते हैं, वे एक ही दिन में अपने फ़ंड के मूल्य का 23% खोने की संभावना का सामना नहीं करना चाहते। अब तक, सबसे अधिक प्रस्तावित समाधान जारीकर्ता-समर्थित संपत्तियां रहा है; विचार यह है कि एक जारीकर्ता एक उप-मुद्रा बनाता है जिसमें उनके पास इकाइयों को जारी करने और रद्द करने का अधिकार होता है, और किसी भी व्यक्ति को मुद्रा की एक इकाई प्रदान करता है जो उन्हें (ऑफ़लाइन) एक निर्दिष्ट अंतर्निहित संपत्ति (जैसे सोना, USD) की एक इकाई प्रदान करता है। फिर जारीकर्ता किसी भी व्यक्ति को अंतर्निहित संपत्ति की एक इकाई प्रदान करने का वादा करता है जो क्रिप्टो-संपत्ति की एक इकाई वापस भेजता है। यह तरीका किसी भी गैर-क्रिप्टोग्राफिक संपत्ति को एक क्रिप्टोग्राफिक संपत्ति में "बेहतरीन" करने की अनुमति देता है, बशर्ते कि जारीकर्ता पर भरोसा किया जा सके। + +व्यवहार में, हालांकि, जारीकर्ता हमेशा विश्वसनीय नहीं होते हैं, और कुछ मामलों में बैंकिंग बुनियादी ढांचा बहुत कमजोर है, या ऐसी सेवाओं के मौजूद होने के लिए बहुत प्रतिकूल है। वित्तीय डेरिवेटिव एक विकल्प प्रदान करते हैं। यहां एक एकल जारीकर्ता के बजाय जो एक संपत्ति को सपोर्ट करने के लिए धन प्रदान करता है, सट्टेबाजों का एक विकेंद्रीकृत बाज़ार, जो यह शर्त लगाता है कि एक क्रिप्टोग्राफिक संदर्भ संपत्ति (जैसे ETH) की कीमत बढ़ेगी, वह भूमिका निभाता है। जारीकर्ताओं के विपरीत, सट्टेबाजों के पास सौदे के अपने हिस्से पर चूक करने का कोई विकल्प नहीं होता है, क्योंकि हेजिंग अनुबंध उनके फ़ंड को एस्क्रो में रखता है। ध्यान दें कि यह दृष्टिकोण पूरी तरह से विकेंद्रीकृत नहीं है, क्योंकि मूल्य टिकर प्रदान करने के लिए अब भी एक विश्वसनीय स्रोत की आवश्यकता होती है, हालांकि तर्क दिया जा सकता है कि यह अब भी बुनियादी ढांचे की आवश्यकताओं को कम करने के मामले में एक बड़ा सुधार है (जारीकर्ता होने के विपरीत, मूल्य फ़ीड जारी करने के लिए किसी लाइसेंस की आवश्यकता नहीं होती है और इसे शायद मुक्त भाषण के रूप में वर्गीकृत किया जा सकता है) और धोखाधड़ी की संभावना को कम करता है। + +### पहचान और प्रतिष्ठा प्रणालियाँ {#identity-and-reputation-systems} + +सबसे पुरानी वैकल्पिक क्रिप्टोकरेंसी, [Namecoin](http://namecoin.org/), ने एक नाम पंजीकरण प्रणाली प्रदान करने के लिए Bitcoin जैसी ब्लॉकचेन का उपयोग करने का प्रयास किया, जहां उपयोगकर्ता अपने नाम को अन्य डेटा के साथ एक सार्वजनिक डेटाबेस में पंजीकृत कर सकते हैं। प्रमुख उद्धृत उपयोग मामला एक [DNS](https://wikipedia.org/wiki/Domain_Name_System) प्रणाली के लिए है, जो डोमेन नामों जैसे "bitcoin.org" (या, Namecoin के मामले में, "bitcoin.bit") को एक IP पते से मैप करता है। अन्य उपयोग मामलों में ईमेल प्रमाणीकरण और संभावित रूप से अधिक उन्नत प्रतिष्ठा प्रणालियाँ शामिल हैं। यहाँ एथेरियम पर Namecoin जैसी नाम पंजीकरण प्रणाली प्रदान करने के लिए बुनियादी अनुबंध है: + +```py +def register(name, value): + if !self.storage[name]: + self.storage[name] = value +``` + +अनुबंध बहुत सरल है; यह एथेरियम नेटवर्क के अंदर एक डेटाबेस है जिसमें कुछ जोड़ा तो जा सकता है, लेकिन संशोधित किया या हटाया नहीं जा सकता। कोई भी किसी मूल्य वाला एक नाम पंजीकृत कर सकता है, और वह पंजीकरण तब हमेशा के लिए रहता है। एक अधिक परिष्कृत नाम पंजीकरण अनुबंध में एक "फंक्शन क्लॉज" भी होगा जो अन्य अनुबंधों को इसकी पूछताछ करने देता है, साथ ही नाम के "मालिक" (यानी पहले पंजीकरणकर्ता) के लिए डेटा बदलने या स्वामित्व हस्तांतरित करने का एक तंत्र भी होगा। कोई भी इसके ऊपर प्रतिष्ठा और विश्वास-का-वेब कार्यक्षमता जोड़ सकता है। + +### विकेंद्रीकृत फ़ाइल भंडारण {#decentralized-file-storage} + +पिछले कुछ वर्षों में, कई लोकप्रिय ऑनलाइन फ़ाइल भंडारण स्टार्टअप सामने आए हैं, जिनमें सबसे प्रमुख ड्रॉपबॉक्स है, जो यूज़र को अपनी हार्ड ड्राइव का बैकअप अपलोड करने और सेवा को बैकअप संग्रहित करने और यूज़र को मासिक शुल्क के बदले में इसे एक्सेस करने की अनुमति देता है। हालांकि, इस बिंदु पर फ़ाइल संग्रहण बाजार कभी-कभी अपेक्षाकृत अकुशल होता है; विभिन्न मौजूदा समाधानों पर एक सरसरी नज़र से पता चलता है कि, विशेष रूप से "अनकैनी वैली" 20-200 GB स्तर पर जहां न तो मुफ्त कोटा और न ही उद्यम-स्तरीय छूट लागू होती है, मुख्यधारा के फ़ाइल स्टोरेज लागत के लिए मासिक कीमतें ऐसी हैं कि आप एक महीने में पूरी हार्ड ड्राइव की लागत से अधिक का भुगतान कर रहे हैं। एथेरियम अनुबंध एक विकेंद्रीकृत फ़ाइल भंडारण पारिस्थितिकी तंत्र के विकास की अनुमति दे सकते हैं, जहां व्यक्तिगत यूज़र अपनी खुद की हार्ड ड्राइव को किराए पर देकर कम मात्रा में पैसे कमा सकते हैं और अप्रयुक्त स्थान का उपयोग फ़ाइल भंडारण की लागत को और कम करने के लिए किया जा सकता है। + +ऐसे उपकरण का मुख्य आधार टुकड़ा वह होगा जिसे हमने "विकेंद्रीकृत ड्रॉपबॉक्स अनुबंध" कहा है। यह अनुबंध इस प्रकार काम करता है। सबसे पहले, वांछित डेटा को ब्लॉकों में विभाजित किया जाता है, निजता के लिए प्रत्येक ब्लॉक को एन्क्रिप्ट किया जाता है और उसमें से एक मर्कल ट्री बनाया जाता है। फिर एक अनुबंध बनाया जाता है जिसमें नियम यह है कि, हर N ब्लॉक के बाद, अनुबंध मर्कल ट्री में एक रैंडम इंडेक्स चुनेगा (पिछले ब्लॉक हैश का उपयोग करके, जिसे अनुबंध कोड से एक्सेस किया जा सकता है, रैंडमनेस के स्रोत के रूप में), और ट्री में उस विशेष इंडेक्स पर ब्लॉक के स्वामित्व के सरलीकृत भुगतान सत्यापन जैसे प्रमाण के साथ लेनदेन की आपूर्ति करने वाली पहली इकाई को X ईथर देगा। जब कोई यूज़र अपनी फ़ाइल को फिर से डाउनलोड करना चाहता है, तो वे फ़ाइल को पुनः प्राप्त करने के लिए एक माइक्रोपेमेंट चैनल प्रोटोकॉल का उपयोग कर सकते हैं (उदाहरण के लिए, 32 किलोबाइट प्रति 1 स्ज़ाबो का भुगतान करें); सबसे शुल्क-कुशल दृष्टिकोण यह है कि भुगतानकर्ता अंत तक लेनदेन प्रकाशित न करे, इसके बजाय हर 32 किलोबाइट के बाद समान नोंस वाले थोड़े अधिक लाभदायक लेनदेन के साथ लेनदेन को बदल दे। + +प्रोटोकॉल की एक महत्वपूर्ण विशेषता यह है कि, हालांकि ऐसा लग सकता है कि कोई कई रैंडम नोड्स पर भरोसा कर रहा है कि वे फ़ाइल को भूलने का निर्णय नहीं लेंगे, कोई भी इस जोखिम को गुप्त साझाकरण के माध्यम से फ़ाइल को कई टुकड़ों में विभाजित करके और अनुबंधों पर नज़र रखकर इस जोखिम को लगभग शून्य तक कम किया जा सकता है कि प्रत्येक टुकड़ा अभी भी किसी नोड के कब्जे में है। यदि कोई अनुबंध अभी भी पैसे का भुगतान कर रहा है, तो यह एक क्रिप्टोग्राफिक प्रमाण प्रदान करता है कि कोई अभी भी फ़ाइल को संग्रहित कर रहा है। + +### विकेंद्रीकृत स्वायत्त संगठन {#decentralized-autonomous-organizations} + +एक "विकेंद्रीकृत स्वायत्त संगठन" की सामान्य अवधारणा एक आभासी इकाई की है जिसमें सदस्यों या शेयरधारकों का एक निश्चित समूह होता है, जो शायद 67% बहुमत के साथ, इकाई के फंड खर्च करने और उसके कोड को संशोधित करने का अधिकार रखता है। सदस्य सामूहिक रूप से यह तय करेंगे कि संगठन को अपने फंड का आवंटन कैसे करना चाहिए। एक डीएओ के फंड आवंटित करने के तरीके इनाम, वेतन से लेकर काम को पुरस्कृत करने के लिए आंतरिक मुद्रा जैसे अधिक अजीब तंत्रों तक हो सकते हैं। यह अनिवार्य रूप से एक पारंपरिक कंपनी या गैर-लाभकारी संस्था के कानूनी पहलुओं को दोहराता है लेकिन केवल प्रवर्तन के लिए क्रिप्टोग्राफिक ब्लॉकचेन तकनीक का उपयोग करता है। अब तक डीएओ के बारे में बहुत सी बातें लाभांश प्राप्त करने वाले शेयरधारकों और व्यापार योग्य शेयरों वाले "विकेंद्रीकृत स्वायत्त निगम" (DAC) के "पूंजीवादी" मॉडल के बारे में रही हैं; एक विकल्प, जिसे शायद "विकेंद्रीकृत स्वायत्त समुदाय" के रूप में वर्णित किया जा सकता है, में सभी सदस्यों की निर्णय लेने में समान भागीदारी होगी और किसी सदस्य को जोड़ने या हटाने के लिए 67% मौजूदा सदस्यों की सहमति की आवश्यकता होगी। यह आवश्यकता कि एक व्यक्ति की केवल एक सदस्यता हो सकती है, तब समूह द्वारा सामूहिक रूप से लागू की जानी होगी। + +एक DAO को कोड करने के लिए एक सामान्य रूपरेखा इस प्रकार है। सबसे सरल डिज़ाइन बस एक स्व-संशोधित कोड का टुकड़ा है जो बदल जाता है यदि दो-तिहाई सदस्य एक परिवर्तन पर सहमत होते हैं। हालांकि सैद्धांतिक रूप से कोड अपरिवर्तनीय होता है, कोई भी इससे आसानी से बच सकता है और कोड के टुकड़ों को अलग-अलग अनुबंधों में रखकर, और जिन अनुबंधों को कॉल करना है उनके पते को संशोधन योग्य स्टोरेज में संग्रहित करके वास्तविक परिवर्तनशीलता प्राप्त कर सकता है। ऐसे DAO अनुबंध के एक सरल कार्यान्वयन में, तीन प्रकार के लेनदेन होंगे, जो लेनदेन में प्रदान किए गए डेटा द्वारा अलग किए जाते हैं: + +- `[0,i,K,V]` भंडारण इंडेक्स `K` पर पते को मूल्य `V` में बदलने के लिए इंडेक्स `i` के साथ एक प्रस्ताव पंजीकृत करने के लिए +- `[1,i]` प्रस्ताव `i` के पक्ष में एक वोट पंजीकृत करने के लिए +- `[2,i]` यदि पर्याप्त वोट किए गए हैं तो प्रस्ताव `i` को अंतिम रूप देने के लिए + +अनुबंध में तब इनमें से प्रत्येक के लिए खंड होंगे। यह सभी खुले भंडारण परिवर्तनों का एक रिकॉर्ड बनाए रखेगा, साथ ही इसकी एक सूची भी रखेगा कि उनके लिए किसने वोट दिया। इसमें सभी सदस्यों की एक सूची भी होगी। जब कोई भी भंडारण परिवर्तन दो-तिहाई सदस्यों के वोट तक पहुंच जाता है, तो एक अंतिम लेनदेन परिवर्तन को निष्पादित कर सकता है। एक अधिक परिष्कृत ढांचे में लेनदेन भेजने, सदस्यों को जोड़ने और हटाने जैसी सुविधाओं के लिए बिल्ट-इन मतदान क्षमता भी होगी, और यहां तक कि [लिक्विड डेमोक्रेसी](https://wikipedia.org/wiki/Liquid_democracy)-शैली के वोट प्रतिनिधिमंडल के लिए भी प्रावधान हो सकता है (यानी कोई भी किसी को अपने लिए वोट करने के लिए असाइन कर सकता है, और असाइनमेंट संक्रामक है इसलिए यदि A, B को असाइन करता है और B, C को असाइन करता है तो C, A का वोट निर्धारित करता है)। यह डिज़ाइन डीएओ को एक विकेंद्रीकृत समुदाय के रूप में जैविक रूप से विकसित होने देगा, लोगों को अंततः यह फ़िल्टर करने का कार्य विशेषज्ञों को सौंपने देगा कि कौन सदस्य है, हालांकि "वर्तमान प्रणाली" के विपरीत विशेषज्ञ समय के साथ आसानी से अस्तित्व में आ और जा सकते हैं क्योंकि व्यक्तिगत समुदाय के सदस्य अपने संरेखण बदलते हैं। + +एक वैकल्पिक मॉडल विकेंद्रीकृत निगम के लिए है, जहां किसी भी खाते के पास शून्य या उससे अधिक शेयर हो सकते हैं, और निर्णय लेने के लिए दो तिहाई शेयरों की आवश्यकता होती है। एक पूर्ण ढांचे में परिसंपत्ति प्रबंधन कार्यक्षमता, शेयर खरीदने या बेचने का प्रस्ताव देने की क्षमता और प्रस्तावों को स्वीकार करने की क्षमता शामिल होगी (अनुबंध के अंदर एक आदेश-मिलान तंत्र के साथ, यदि संभव हो)। प्रतिनिधि का अस्तित्व भी लिक्विड डेमोक्रेसी-शैली में होगा, "बोर्ड ऑफ डायरेक्टर्स" की अवधारणा का सामान्यीकरण करते हुए। + +### आगे के अनुप्रयोग {#further-applications} + +**1. बचत वॉलेट**। मान लीजिए कि एलिस अपने फंड को सुरक्षित रखना चाहती है, लेकिन चिंतित है कि वह अपनी निजी चाबी खो देगी या कोई उसे हैक कर लेगा। वह ईथर को बॉब, एक बैंक के साथ एक अनुबंध में डालती है, जो इस प्रकार है: + +- एलिस अकेले प्रतिदिन अधिकतम 1% फंड निकाल सकती है। +- बॉब अकेले प्रतिदिन अधिकतम 1% फंड निकाल सकता है, लेकिन एलिस के पास अपनी चाबी से एक लेनदेन करने की क्षमता है जो इस क्षमता को बंद कर देती है। +- एलिस और बॉब मिलकर कुछ भी निकाल सकते हैं। + +सामान्यतः, एलिस के लिए प्रतिदिन 1% पर्याप्त है, और यदि एलिस अधिक निकालना चाहती है तो वह मदद के लिए बॉब से संपर्क कर सकती है। अगर एलिस की चाबी हैक हो जाती है, तो वह धनराशि को नए अनुबंध में स्थानांतरित करने के लिए बॉब के पास जाती है। यदि वह अपनी चाबी खो देती है, तो बॉब अंततः फंड निकाल लेगा। यदि बॉब दुर्भावनापूर्ण साबित होता है, तो वह उसकी निकासी की क्षमता को बंद कर सकती है। + +**2. क्रॉप इंश्योरेंस**। कोई भी किसी भी मूल्य सूचकांक के बजाय मौसम के डेटा फीड का उपयोग करके आसानी से एक वित्तीय डेरिवेटिव अनुबंध बना सकता है। यदि आयोवा में एक किसान एक डेरिवेटिव खरीदता है जो आयोवा में वर्षा के आधार पर विपरीत रूप से भुगतान करता है, तो यदि सूखा पड़ता है, तो किसान को स्वचालित रूप से पैसा मिलेगा और यदि पर्याप्त बारिश होती है तो किसान खुश होगा क्योंकि उनकी फसलें अच्छी होंगी। इसे सामान्य रूप से प्राकृतिक आपदा बीमा में विस्तारित किया जा सकता है। + +**3. एक विकेंद्रीकृत डेटा फीड**। वित्तीय अंतर अनुबंधों के लिए, ["SchellingCoin"](http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/) नामक एक प्रोटोकॉल के माध्यम से डेटा फीड को विकेंद्रीकृत करना वास्तव में संभव हो सकता है। SchellingCoin मूल रूप से इस प्रकार काम करता है: N पक्ष सभी सिस्टम में एक दिए गए डेटम का मूल्य डालते हैं (उदाहरण के लिए ETH/USD मूल्य), मूल्यों को क्रमबद्ध किया जाता है, और 25वें और 75वें प्रतिशतक के बीच सभी को पुरस्कार के रूप में एक टोकन मिलता है। हर किसी के पास वह उत्तर प्रदान करने का प्रोत्साहन होता है जो हर कोई प्रदान करेगा, और एकमात्र मूल्य जिस पर बड़ी संख्या में खिलाड़ी वास्तव में सहमत हो सकते हैं वह स्पष्ट डिफ़ॉल्ट है: सत्य। यह एक विकेंद्रीकृत प्रोटोकॉल बनाता है जो सैद्धांतिक रूप से किसी भी संख्या में मूल्य प्रदान कर सकता है, जिसमें ETH/USD मूल्य, बर्लिन में तापमान या यहां तक कि किसी विशेष कठिन गणना का परिणाम भी शामिल है। + +**4. स्मार्ट मल्टीसिग्नेचर एस्क्रो**। Bitcoin मल्टीसिग्नेचर लेनदेन अनुबंधों की अनुमति देता है जहां, उदाहरण के लिए, दी गई पांच चाबियों में से तीन फंड खर्च कर सकती हैं। एथेरियम अधिक परिष्कार की अनुमति देता है; उदाहरण के लिए, पांच में से चार सब कुछ खर्च कर सकते हैं, पांच में से तीन प्रतिदिन 10% तक खर्च कर सकते हैं, और पांच में से दो प्रतिदिन 0.5% तक खर्च कर सकते हैं। इसके अतिरिक्त, एथेरियम मल्टीसिग असिंक्रोनस है - दो पक्ष अलग-अलग समय पर ब्लॉकचेन पर अपने हस्ताक्षर पंजीकृत कर सकते हैं और अंतिम हस्ताक्षर स्वचालित रूप से लेनदेन भेज देगा। + +**5. क्लाउड कंप्यूटिंग**। EVM तकनीक का उपयोग एक सत्यापन योग्य कंप्यूटिंग वातावरण बनाने के लिए भी किया जा सकता है, जो उपयोगकर्ताओं को दूसरों से गणना करने के लिए कहने और फिर वैकल्पिक रूप से कुछ यादृच्छिक रूप से चुने गए चेकपॉइंट्स पर गणना सही ढंग से की गई थी, इसके प्रमाण मांगने की अनुमति देता है। इससे एक क्लाउड कंप्यूटिंग बाजार बनाया जा सकता है जहां कोई भी यूज़र अपने डेस्कटॉप, लैपटॉप या विशेष सर्वर के साथ भाग ले सकता है और स्पॉट-चेकिंग और सुरक्षा जमा का उपयोग करके यह सुनिश्चित किया जा सकता है कि सिस्टम भरोसेमंद है (अर्थात्, नोड्स लाभप्रद रूप से धोखा नहीं दे सकते)। हालांकि यह सिस्टम सभी कार्यों के लिए उपयुक्त नहीं हो सकता है। उदाहरण के लिए, जिन कार्यों में उच्च स्तर की अंतर-प्रक्रिया संचार की आवश्यकता होती है, उन्हें नोड्स के बड़े क्लाउड पर आसानी से नहीं किया जा सकता। हालांकि, दूसरे टास्क को समानांतर करना बहुत आसान है; SETI@home, folding@home और जेनेटिक एल्गोरिदम जैसे प्रोजेक्ट ऐसे किसी प्लेटफ़ॉर्म पर आसानी से लागू किए जा सकते हैं। + +**6. पीयर-टू-पीयर जुआ**। कई पीयर-टू-पीयर जुआ प्रोटोकॉल, जैसे फ्रैंक स्टजानो और रिचर्ड क्लेटन के [साइबरडाइस](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf), को एथेरियम ब्लॉकचेन पर लागू किया जा सकता है। सबसे सरल जुआ प्रोटोकॉल वास्तव में अगले ब्लॉक हैश पर एक अंतर का अनुबंध है और इससे आगे और उन्नत प्रोटोकॉल बनाए जा सकते हैं, इससे लगभग शून्य शुल्क वाली जुआ सेवाएं बनाई जा सकती हैं जिनमें धोखा देने की क्षमता नहीं होती। + +**7. भविष्यवाणी बाजार**। एक ओरेकल या SchellingCoin की मदद से, भविष्यवाणी बाजारों को भी आसानी से लागू किया जा सकता है और भविष्यवाणी बाजार और SchellingCoin मिलकर विकेंद्रीकृत संगठनों के लिए शासन प्रणाली के रूप में [फ्यूटार्की](http://hanson.gmu.edu/futarchy.html) का पहला मुख्यधारा का एप्लिकेशन साबित हो सकते हैं। + +**8. ऑन-चेन पर आधारित विकेंद्रीकृत बाजार**, जो पहचान और प्रतिष्ठा प्रणाली का उपयोग आधार के रूप में करते हैं। + +## विविध मुद्दे और चिंताएं {#miscellanea-and-concerns} + +### संशोधित GHOST कार्यान्वयन {#modified-ghost-implementation} + +"ग्रीडी हेवीएस्ट ऑब्जर्व्ड सबट्री" (GHOST) प्रोटोकॉल एक नवाचार है जिसे [दिसंबर 2013](https://eprint.iacr.org/2013/881.pdf) में योनातन सोम्पोलिन्स्की और अवीव ज़ोहर ने पेश किया था। GHOST के पीछे का विचार यह है कि तेज पुष्टि समय वाली ब्लॉकचेन वर्तमान में उच्च पुराने दर के कारण कम सुरक्षा से पीड़ित हैं, ऐसा इसलिए है क्योंकि ब्लॉक को नेटवर्क में फैलने में कुछ समय लगता है, अगर माईनर A एक ब्लॉक खोदता है और फिर माईनर B दूसरा ब्लॉक खोद लेता है, इससे पहले कि A का ब्लॉक B तक पहुंचे, तो B का ब्लॉक बेकार हो जाएगा और नेटवर्क सुरक्षा में योगदान नहीं देगा। इसके अलावा, एक केंद्रीकरण मुद्दा है: यदि माईनर A 30% हैशपावर वाला एक खनन पूल है और B में 10% हैशपावर है, तो A के लिए 70% समय पुराने ब्लॉक का उत्पादन करने का जोखिम होगा (क्योंकि अन्य 30% समय A ने अंतिम ब्लॉक का उत्पादन किया और इसलिए तुरंत खनन डेटा प्राप्त होगा) जबकि B के लिए 90% समय में पुराने ब्लॉक का उत्पादन करने का जोखिम होगा। इसलिए, अगर ब्लॉक अंतराल इतना छोटा है कि पुरानी दर उच्च हो, तो A अपने आकार के कारण काफी अधिक कुशल होगा। इन दोनों प्रभावों के मिलने से, जो ब्लॉकचेन जल्दी ब्लॉक बनाती हैं, उनमें एक माईनिंग पूल के पास नेटवर्क हैशपावर का बड़ा हिस्सा होने की संभावना अधिक होती है, जिससे वह माईनिंग प्रक्रिया पर वास्तविक नियंत्रण रख सकता है। + +सोम्पोलिन्स्की और ज़ोहर के अनुसार, GHOST नेटवर्क सुरक्षा के नुकसान की पहली समस्या को हल करता है, यह पुराने ब्लॉकों को भी शामिल करके यह गणना करता है कि कौन सी श्रृंखला "सबसे लंबी" है, यानी, न केवल एक ब्लॉक के पैरेंट और पूर्वज, बल्कि ब्लॉक के पूर्वज के पुराने वंशज (एथेरियम की भाषा में, "अंकल") भी इस गणना में जोड़े जाते हैं कि किस ब्लॉक के पीछे सबसे बड़ा कुल काम का सबूत है। केंद्रीकरण पूर्वाग्रह की दूसरी समस्या को हल करने के लिए, हम सोम्पोलिन्स्की और ज़ोहर द्वारा वर्णित प्रोटोकॉल से आगे बढ़ते हैं, और हम पुराने को भी ब्लॉक इनाम देते हैं: एक पुराना ब्लॉक अपने मूल इनाम का 87.5% प्राप्त करता है, और जो भतीजा पुराने ब्लॉक को शामिल करता है वह शेष 12.5% प्राप्त करता है। हालांकि, लेनदेन शुल्क अंकल को नहीं दिया जाता है। + +एथेरियम GHOST का एक सरलीकृत संस्करण लागू करता है जो केवल सात स्तर तक जाता है। विशेष रूप से, इसे इस प्रकार परिभाषित किया गया है: + +- एक ब्लॉक को एक पैरेंट निर्दिष्ट करना चाहिए, और यह 0 या अधिक अंकल निर्दिष्ट कर सकता है +- ब्लॉक B में शामिल एक अंकल के पास निम्नलिखित गुण होने चाहिए: + - यह B के kth पीढ़ी के पूर्वज का प्रत्यक्ष बच्चा होना चाहिए, जहां `2 <= k <= 7`। + - यह B का पूर्वज नहीं हो सकता + - अंकल एक वैध ब्लॉक हेडर होना चाहिए, लेकिन पहले से सत्यापित या वैध ब्लॉक होने की आवश्यकता नहीं है + - अंकल को पिछले ब्लॉकों में शामिल सभी अंकल और एक ही ब्लॉक में शामिल अन्य सभी अंकल (गैर-डबल-समावेशन) से अलग होना चाहिए +- ब्लॉक B में प्रत्येक अंकल U के लिए, B के माईनर को अपने कॉइनबेस इनाम में अतिरिक्त 3.125% मिलता है और U के माईनर को मानक कॉइनबेस इनाम का 93.75% मिलता है। + +GHOST का यह सीमित वर्जन, जिसमें केवल 7 पीढ़ियों तक अंकल शामिल किए जा सकते हैं, दो कारणों से उपयोग किया गया था। पहला, असीमित GHOST किसी दिए गए ब्लॉक के लिए वैध अंकल की गणना में बहुत सारी जटिलताएं शामिल करेगा। दूसरा, एथेरियम में उपयोग किए जाने वाले मुआवजे के साथ असीमित GHOST मुख्य श्रृंखला पर माइन करने के लिए एक माईनर के लिए प्रोत्साहन को हटा देता है न कि किसी सार्वजनिक हमलावर की श्रृंखला पर। + +### शुल्क {#fees} + +क्योंकि ब्लॉकचेन में प्रकाशित हर लेनदेन नेटवर्क पर डाउनलोड और सत्यापित करने की लागत लगाता है, दुरुपयोग को रोकने के लिए कुछ नियामक मैकेनिज्म की आवश्यकता होती है, जिसमें आमतौर पर लेनदेन शुल्क शामिल होता है। Bitcoin में उपयोग किया जाने वाला डिफ़ॉल्ट दृष्टिकोण पूरी तरह से स्वैच्छिक शुल्क रखना है, जो माईनर पर गेटकीपर के रूप में कार्य करने और डायनामिक न्यूनतम निर्धारित करने पर निर्भर करता है। इस दृष्टिकोण को Bitcoin समुदाय में बहुत पसंद किया गया है, विशेष रूप से क्योंकि यह "बाजार-आधारित" है, जो माईनर और लेनदेन भेजने वालों के बीच आपूर्ति और मांग को कीमत निर्धारित करने की अनुमति देता है। हालांकि, इस तर्क की समस्या यह है कि लेनदेन की प्रोसेसिंग एक बाजार नहीं है; यह आकर्षक लगता है कि लेनदेन की प्रोसेसिंग को एक सेवा के रूप में देखा जाए जो माईनर प्रेषक को प्रदान कर रहा है, वास्तविकता में एक माईनर द्वारा शामिल किए गए प्रत्येक लेनदेन को नेटवर्क में हर नोड द्वारा प्रोसेस किया जाना होगा, इसलिए, लेनदेन प्रोसेसिंग की अधिकांश लागत तृतीय पक्षों द्वारा वहन की जाती है, न कि उस माईनर द्वारा जो इसे शामिल करने या न करने का निर्णय ले रहा है। इसलिए, आम लोगों की त्रासदी की समस्याएं होने की बहुत संभावना है। + +हालांकि, जैसा कि पता चलता है, बाजार-आधारित तंत्र में यह खामी, जब एक विशेष अनुचित सरलीकरण मान्यता दी जाती है, तो जादुई रूप से खुद को रद्द कर देती है। तर्क इस प्रकार है। मान लीजिए कि: + +1. लेनदेन से `k` ऑपरेशन होते हैं, जो किसी भी माईनर को `kR` इनाम की पेशकश करते हैं जो इसे शामिल करता है जहां `R` भेजने वाले द्वारा निर्धारित किया जाता है और `k` और `R` पहले से ही माईनर को (लगभग) दिखाई देते हैं। +2. एक ऑपरेशन की किसी भी नोड के लिए प्रोसेसिंग लागत `C` है (यानी सभी नोड्स की समान दक्षता है) +3. `N` माईनिंग नोड्स हैं, प्रत्येक के पास बिल्कुल समान प्रोसेसिंग पावर है (यानी कुल का `1/N`) +4. कोई नॉन-माईनिंग फुल नोड मौजूद नहीं है। + +एक माईनर लेनदेन को तब प्रोसेस करने के लिए तैयार होगा अगर अपेक्षित इनाम लागत से अधिक है। इस प्रकार, अपेक्षित इनाम `kR/N` है क्योंकि माईनर के पास अगले ब्लॉक को प्रोसेस करने की संभावना `1/N` है, और माईनर के लिए प्रोसेसिंग लागत मात्र `kC` है। इसलिए, माईनर उन लेनदेन को शामिल करेंगे जहां `kR/N > kC`, या `R > NC` है। ध्यान दें कि `R` भेजने वाले द्वारा प्रदान किया गया प्रति-ऑपरेशन शुल्क है, और इसलिए यह लाभ की निचली सीमा है जो भेजने वाला लेनदेन से प्राप्त करता है, और `NC` एक ऑपरेशन को प्रोसेस करने के लिए पूरे नेटवर्क की कुल लागत है। इसलिए, माईनरों के पास केवल उन लेनदेन को शामिल करने का प्रोत्साहन है जिनके लिए कुल उपयोगितावादी लाभ लागत से अधिक है। + +हालांकि, वास्तविकता में उन मान्यताओं से कई महत्वपूर्ण विचलन हैं: + +1. माईनर लेनदेन को प्रोसेस करने के लिए अन्य सत्यापन नोड्स की तुलना में अधिक लागत चुकाता है, क्योंकि अतिरिक्त सत्यापन समय ब्लॉक प्रसार में देरी करता है और इस प्रकार ब्लॉक के पुराना होने की संभावना बढ़ जाती है। +2. नॉन-माईनिंग फुल नोड्स मौजूद हैं। +3. माईनिंग पावर वितरण व्यवहार में बहुत असमान हो सकता है। +4. सट्टेबाज, राजनीतिक दुश्मन और सनकी लोग जिनके उपयोगिता फंक्शन में नेटवर्क को नुकसान पहुंचाना शामिल है, मौजूद हैं और वे चतुराई से ऐसे अनुबंध स्थापित कर सकते हैं जहां उनकी लागत अन्य सत्यापन नोड्स द्वारा भुगतान की गई लागत से बहुत कम है। + +(1) माईनर को कम लेनदेन शामिल करने की प्रवृत्ति प्रदान करता है, और (2) `NC` को बढ़ाता है; इसलिए, ये दो प्रभाव कम से कम आंशिक रूप से एक दूसरे को रद्द कर देते हैं।[कैसे?](https://github.com/ethereum/wiki/issues/447#issuecomment-316972260) (3) और (4) प्रमुख मुद्दा है; उन्हें हल करने के लिए हम बस एक फ्लोटिंग कैप स्थापित करते हैं: किसी भी ब्लॉक में `BLK_LIMIT_FACTOR` गुना दीर्घकालिक एक्सपोनेंशियल मूविंग एवरेज से अधिक ऑपरेशन नहीं हो सकते। विशेष रूप से: + +```js +blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) + +floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR) +``` + +`BLK_LIMIT_FACTOR` और `EMA_FACTOR` स्थिरांक हैं जो फिलहाल 65536 और 1.5 पर सेट किए जाएंगे, लेकिन आगे के विश्लेषण के बाद बदले जाने की संभावना है। + +Bitcoin में बड़े ब्लॉक आकारों को हतोत्साहित करने वाला एक और कारक है: बड़े ब्लॉक को प्रसारित करने में अधिक समय लगेगा, और इस प्रकार पुराना बनने की संभावना अधिक होती है। एथेरियम में, उच्च गैस खपत वाले ब्लॉक भी प्रसारित होने में अधिक समय ले सकते हैं क्योंकि वे भौतिक रूप से बड़े होते हैं और लेनदेन स्थिति परिवर्तनों को मान्य करने के लिए प्रोसेस करने में अधिक समय लगता है। यह देरी का हतोत्साहन Bitcoin में एक महत्वपूर्ण विचार है, लेकिन GHOST प्रोटोकॉल के कारण एथेरियम में कम है; इसलिए, नियंत्रित ब्लॉक सीमाओं पर निर्भर रहना एक अधिक स्थिर आधार रेखा प्रदान करता है। + +### कम्प्यूटेशन और ट्यूरिंग-कम्प्लीटनेस {#computation-and-turing-completeness} + +एक महत्वपूर्ण नोट यह है कि एथेरियम वर्चुअल मशीन ट्यूरिंग-कम्प्लीट है; इसका मतलब है कि EVM कोड किसी भी गणना को एनकोड कर सकता है जो संभवतः की जा सकती है, जिसमें अनंत लूप भी शामिल हैं। EVM कोड दो तरीकों से लूपिंग की अनुमति देता है। पहला, एक `JUMP` निर्देश है जो प्रोग्राम को कोड में पिछले स्पॉट पर वापस जाने की अनुमति देता है और एक `JUMPI` निर्देश सशर्त जम्पिंग के लिए है, जो `while x > 27: x = x * 2` जैसे स्टेटमेंट्स की अनुमति देता है। दूसरा, अनुबंध अन्य अनुबंधों को कॉल कर सकते हैं, संभवतः रिकर्शन के माध्यम से लूपिंग की अनुमति देते हैं। यह स्वाभाविक रूप से एक समस्या की ओर ले जाता है: क्या दुर्भावनापूर्ण उपयोगकर्ता माईनरों और पूर्ण नोड्स को एक अनंत लूप में प्रवेश करने के लिए मजबूर करके अनिवार्य रूप से बंद कर सकते हैं? यह मुद्दा कंप्यूटर विज्ञान में ज्ञात हाल्टिंग समस्या के कारण उत्पन्न होता है: सामान्य मामले में यह बताने का कोई तरीका नहीं है कि क्या कोई दिया गया प्रोग्राम कभी रुकेगा या नहीं। + +जैसा कि स्टेट ट्रांजिशन सेक्शन में वर्णित है, हमारा समाधान एक लेनदेन को अनुमति प्राप्त अधिकतम कम्प्यूटेशनल चरणों की संख्या निर्धारित करने की आवश्यकता के द्वारा काम करता है, और यदि निष्पादन लंबे समय तक चलता है तो कम्प्यूटेशन वापस कर दिया जाता है लेकिन शुल्क का भुगतान अभी भी किया जाता है। संदेश उसी तरह काम करते हैं। हमारे समाधान के पीछे की प्रेरणा दिखाने के लिए, निम्नलिखित उदाहरणों पर विचार करें: + +- एक हमलावर एक अनुबंध बनाता है जो एक अनंत लूप चलाता है, और फिर उस लूप को सक्रिय करने वाला एक लेनदेन माईनर को भेजता है। माईनर लेनदेन को प्रोसेस करेगा, अनंत लूप चलाएगा और इसकी गैस समाप्त होने का इंतजार करेगा। हालांकि निष्पादन गैस से बाहर हो जाता है और बीच में रुक जाता है, लेनदेन अभी भी मान्य है और माईनर अभी भी हमलावर से प्रत्येक कम्प्यूटेशनल चरण के लिए शुल्क का दावा करता है। +- एक हमलावर एक बहुत लंबा अनंत लूप बनाता है जिसका उद्देश्य माईनर को इतने लंबे समय तक कम्प्यूटिंग करने के लिए मजबूर करना है कि जब तक कम्प्यूटेशन समाप्त होगा तब तक कुछ और ब्लॉक आ चुके होंगे और माईनर के लिए शुल्क का दावा करने के लिए लेनदेन को शामिल करना संभव नहीं होगा। हालांकि, हमलावर को `STARTGAS` के लिए एक मूल्य प्रस्तुत करने की आवश्यकता होगी जो निष्पादन द्वारा ली जा सकने वाली कम्प्यूटेशनल चरणों की संख्या को सीमित करता है, इसलिए माईनर पहले से ही जानेगा कि कम्प्यूटेशन अत्यधिक बड़ी संख्या में चरण लेगा। +- एक हमलावर `send(A,contract.storage[A]); contract.storage[A] = 0` जैसे किसी रूप के कोड वाले अनुबंध को देखता है, और बस पहले चरण को चलाने के लिए पर्याप्त गैस वाला एक लेनदेन भेजता है लेकिन दूसरे को नहीं (यानी निकासी करना लेकिन शेष राशि को कम नहीं होने देना)। अनुबंध लेखक को ऐसे हमलों से बचाव करने की चिंता करने की आवश्यकता नहीं है, क्योंकि यदि निष्पादन बीच में रुक जाता है तो परिवर्तन वापस कर दिए जाते हैं। +- एक वित्तीय अनुबंध जोखिम को कम करने के लिए नौ स्वामित्व डेटा फीड के मध्यमान को लेकर काम करता है। एक हमलावर एक डेटा फीड पर कब्जा कर लेता है, जो डीएओ के खंड में वर्णित वेरिएबल-एड्रेस-कॉल मैकेनिज्म के माध्यम से संशोधन योग्य होने के लिए डिजाइन किया गया है, और इसे एक अनंत लूप चलाने के लिए परिवर्तित करता है, इस प्रकार वित्तीय अनुबंध से धन का दावा करने के किसी भी प्रयास की गैस खत्म करने के लिए मजबूर करने का प्रयास करता है। हालांकि, वित्तीय अनुबंध इस समस्या को रोकने के लिए संदेश पर एक गैस सीमा सेट कर सकता है। + +ट्यूरिंग-कम्प्लीटनेस का विकल्प ट्यूरिंग-इनकम्प्लीटनेस है, जहां `JUMP` और `JUMPI` मौजूद नहीं हैं और किसी भी समय कॉल स्टैक में प्रत्येक अनुबंध की केवल एक प्रति की अनुमति है। इस प्रणाली के साथ, वर्णित शुल्क प्रणाली और हमारे समाधान की प्रभावशीलता के बारे में अनिश्चितताएं आवश्यक नहीं हो सकती हैं, क्योंकि एक अनुबंध को निष्पादित करने की लागत उसके आकार से ऊपर सीमित होगी। इसके अलावा, ट्यूरिंग-इनकम्प्लीटनेस इतनी बड़ी सीमा भी नहीं है; हमने आंतरिक रूप से अनुबंध के सभी उदाहरणों की कल्पना की है, अब तक केवल एक के लिए लूप की आवश्यकता थी और उस लूप को भी एक पंक्ति के कोड को 26 बार दोहराने से हटाया जा सकता था। ट्यूरिंग-कम्प्लीटनेस के गंभीर निहितार्थ और सीमित लाभ को देखते हुए, बस एक ट्यूरिंग-इनकम्प्लीट भाषा क्यों न रखें? वास्तविकता में, ट्यूरिंग-इनकम्प्लीटनेस समस्या के एक स्वच्छ समाधान से बहुत दूर है। यह समझने के लिए, निम्नलिखित अनुबंधों पर विचार करें: + +```sh +C0: call(C1); call(C1); +C1: call(C2); call(C2); +C2: call(C3); call(C3); +... +C49: call(C50); call(C50); +C50: (run one step of a program and record the change in storage) +``` + +अब, A को एक लेनदेन भेजें। इस प्रकार, 51 लेनदेनों में, हमारे पास एक अनुबंध है जो 250 कम्प्यूटेशनल चरण लेता है। माईनर प्रत्येक अनुबंध के साथ एक मूल्य बनाए रखकर समय से पहले ऐसे तर्क बमों का पता लगाने की कोशिश कर सकते हैं, जिसमें अधिकतम कम्प्यूटेशनल चरणों की संख्या निर्दिष्ट की जा सकती है, और अन्य अनुबंधों को पुनरावर्ती रूप से कॉल करने वाले अनुबंधों के लिए इसकी गणना की जा सके, लेकिन इसके लिए माईनरों को ऐसे अनुबंधों को प्रतिबंधित करना होगा जो अन्य अनुबंध बनाते हैं (क्योंकि उपरोक्त सभी 26 अनुबंधों का निर्माण और निष्पादन आसानी से एक ही अनुबंध में समेटा जा सकता है)। एक और समस्याग्रस्त बिंदु यह है कि किसी संदेश का पता फ़ील्ड एक वेरिएबल है, इसलिए सामान्य तौर पर यह बताना भी संभव नहीं हो सकता है कि किसी दिए गए अनुबंध को समय से पहले कौन से अन्य अनुबंध कॉल करेंगे। इसलिए, परिणाम आश्‍चर्यजनक है: ट्यूरिंग-पूर्णता को प्रबंधित करना आश्चर्यजनक रूप से आसान है, और ट्यूरिंग-पूर्णता की कमी को प्रबंधित करना भी आश्चर्यजनक रूप से उतना ही कठिन है, जब तक कि वही सटीक नियंत्रण मौजूद न हों - लेकिन उस मामले में प्रोटोकॉल को ट्यूरिंग-पूर्ण क्यों न होने दें? + +### मुद्रा और जारी करना {#currency-and-issuance} + +एथेरियम नेटवर्क में अपनी खुद की बिल्ट-इन मुद्रा, ईथर शामिल है, जो दोहरे उद्देश्य की पूर्ति करती है, विभिन्न प्रकार की डिजिटल संपत्तियों के बीच कुशल विनिमय की अनुमति देने के लिए एक प्राथमिक तरलता परत प्रदान करती है और अधिक महत्वपूर्ण रूप से लेनदेन शुल्क का भुगतान करने के लिए एक मैकेनिज्म प्रदान करती है। सुविधा के लिए और भविष्य के तर्क से बचने के लिए (Bitcoin में वर्तमान mBTC/uBTC/सातोशी बहस देखें), मूल्यवर्ग पहले से लेबल किए जाएंगे: + +- 1: wei +- 1012: स्जाबो +- 1015: फिन्नी +- 1018: ईथर + +इसे "डॉलर" और "सेंट" या "BTC" और "सातोशी" की अवधारणा का विस्तारित संस्करण माना जाना चाहिए। निकट भविष्य में, हम उम्मीद करते हैं कि सामान्य लेनदेन के लिए "ईथर", सूक्ष्म लेनदेन के लिए "फिन्नी" और शुल्क और प्रोटोकॉल कार्यान्वयन के आसपास तकनीकी चर्चाओं के लिए "स्जाबो" और "वेई" का उपयोग किया जाएगा; शेष मूल्यवर्ग बाद में उपयोगी हो सकते हैं और इस बिंदु पर क्लाइंट में शामिल नहीं किए जाने चाहिए। + +जारी करने का मॉडल निम्नानुसार होगा: + +- ईथर को एक मुद्रा बिक्री में 1000-2000 ईथर प्रति BTC की कीमत पर जारी किया जाएगा, एक मैकेनिज्म जिसका उद्देश्य एथेरियम संगठन को वित्त पोषित करना और विकास के लिए भुगतान करना है जो अन्य प्लेटफार्मों जैसे मास्टरकॉइन और NXT द्वारा सफलतापूर्वक उपयोग किया गया है। पहले के खरीदारों को बड़े छूट से लाभ होगा। बिक्री से प्राप्त BTC का उपयोग पूरी तरह से डेवलपर को वेतन और बाउंटी का भुगतान करने और एथेरियम और क्रिप्टोकरेंसी पारिस्थितिकी तंत्र में विभिन्न लाभकारी और गैर-लाभकारी प्रोजेक्ट में निवेश करने के लिए किया जाएगा। +- कुल बेची गई राशि का 0.099x (60102216 ETH) संगठन को आवंटित किया जाएगा ताकि शुरुआती योगदानकर्ताओं को मुआवजा दिया जा सके और जेनेसिस ब्लॉक से पहले ETH-मूल्यवर्ग वाले खर्चों का भुगतान किया जा सके। +- कुल बेची गई राशि का 0.099x एक दीर्घकालिक रिजर्व के रूप में बनाए रखा जाएगा। +- कुल बेची गई राशि का 0.26x उस बिंदु के बाद हमेशा के लिए प्रति वर्ष माइनरों को आवंटित किया जाएगा। + +| समूह | लॉन्च के समय | 1 साल बाद | 5 साल बाद | +| -------------------------------------- | ------------ | --------- | --------- | +| मुद्रा इकाइयाँ | 1.198X | 1.458X | 2.498X | +| खरीदार | 83.5% | 68.6% | 40.0% | +| बिक्री से पहले खर्च किया रिजर्व | 8.26% | 6.79% | 3.96% | +| बिक्री के बाद इस्तेमाल किया गया रिजर्व | 8.26% | 6.79% | 3.96% | +| माईनर | 0% | 17.8% | 52.0% | + +#### दीर्घकालिक आपूर्ति वृद्धि दर (प्रतिशत में) + +![एथेरियम इन्फ्लेशन](./ethereum-inflation.png) + +_रैखिक मुद्रा प्रसार के बावजूद, Bitcoin की तरह ही समय के साथ आपूर्ति वृद्धि दर शून्य की ओर प्रवृत्त होती है।_ + +उपरोक्त मॉडल में दो मुख्य विकल्प हैं (1) एंडोमेंट पूल का अस्तित्व और आकार, और (2) Bitcoin की तरह सीमित आपूर्ति के विपरीत एक स्थायी रूप से बढ़ती रैखिक आपूर्ति का होना। एंडोमेंट पूल का औचित्य इस प्रकार है। यदि एंडोमेंट पूल मौजूद नहीं होता, और रैखिक निर्गम को समान इन्फ्लेशन दर प्रदान करने के लिए 0.217x तक कम कर दिया जाता, तो ईथर की कुल मात्रा 16.5% कम होती और इसलिए प्रत्येक इकाई 19.8% अधिक मूल्यवान होती। अतः, संतुलन में 19.8% अधिक ईथर की सेल में खरीद होती, इसलिए प्रत्येक इकाई फिर से पहले की तरह ठीक उतनी ही मूल्यवान होती। संगठन के पास भी 1.198x अधिक BTC होता, जिसे दो हिस्सों में विभाजित माना जा सकता है: मूल BTC और अतिरिक्त 0.198x। इसलिए, यह स्थिति एंडोमेंट के _बिल्कुल समान_ है, लेकिन एक महत्वपूर्ण अंतर के साथ: संगठन केवल BTC रखता है, और इसलिए ईथर इकाई के मूल्य का समर्थन करने के लिए प्रोत्साहित नहीं किया जाता है। + +स्थायी रैखिक आपूर्ति वृद्धि मॉडल Bitcoin में कुछ लोगों द्वारा देखे जाने वाले अत्यधिक धन केंद्रीकरण के जोखिम को कम करता है और वर्तमान और भविष्य के युगों में रहने वाले व्यक्तियों को मुद्रा इकाइयाँ प्राप्त करने का उचित अवसर देता है, जबकि साथ ही ईथर प्राप्त करने और रखने के लिए एक मजबूत प्रोत्साहन बनाए रखता है क्योंकि "आपूर्ति वृद्धि दर" प्रतिशत के रूप में समय के साथ शून्य की ओर प्रवृत्त होती है। हम यह भी सिद्धांत देते हैं कि चूंकि कॉइन हमेशा लापरवाही, मृत्यु आदि के कारण समय के साथ खो जाते हैं, और कॉइन के नुकसान को प्रति वर्ष कुल आपूर्ति के प्रतिशत के रूप में मॉडल किया जा सकता है, इसलिए प्रचलन में कुल मुद्रा आपूर्ति वास्तव में अंततः वार्षिक निर्गम को नुकसान दर से विभाजित करने पर प्राप्त मूल्य पर स्थिर हो जाएगी (उदाहरण के लिए, 1% की नुकसान दर पर, जब आपूर्ति 26X तक पहुंच जाती है, तब 0.26X माइन किया जाएगा और 0.26X का नुकसान हर साल होगा, जो एक संतुलन बनाएगा)। + +ध्यान दें कि भविष्य में, एथेरियम सुरक्षा के लिए एक प्रूफ-ऑफ-स्टेक मॉडल पर स्विच करने की संभावना है, जो निर्गम आवश्यकता को प्रति वर्ष शून्य से 0.05X के बीच कहीं कम कर देगा। यदि एथेरियम संगठन फंडिंग खो देता है या किसी अन्य कारण से गायब हो जाता है, तो हम एक "सामाजिक अनुबंध" खुला छोड़ते हैं: किसी को भी भविष्य के उम्मीदवार संस्करण के एथेरियम बनाने का अधिकार है, जिसमें एकमात्र शर्त यह है कि ईथर की मात्रा अधिकतम `60102216 * (1.198 + 0.26 * n)` के बराबर होनी चाहिए, जहां `n` जेनेसिस ब्लॉक के बाद वर्षों की संख्या है। निर्माता विकास के लिए भुगतान करने के लिए PoS-संचालित आपूर्ति विस्तार और अधिकतम अनुमेय आपूर्ति विस्तार के बीच के अंतर के कुछ या सभी को क्राउड-सेल या अन्यथा असाइन करने के लिए स्वतंत्र हैं। सामाजिक अनुबंध का पालन न करने वाले उम्मीदवार अपग्रेड को न्यायोचित रूप से अनुपालन वाले संस्करणों में फोर्क किया जा सकता है। + +### माईनिंग केंद्रीकरण {#mining-centralization} + +Bitcoin माईनिंग एल्गोरिथम, माईनर द्वारा ब्लॉक हेडर के थोड़े संशोधित संस्करणों पर SHA256 की गणना बार-बार लाखों बार करने के द्वारा काम करता है, जब तक कि अंततः एक नोड एक ऐसा संस्करण नहीं निकाल लेता जिसका हैश लक्ष्य (वर्तमान में लगभग 2192) से कम होता है। हालांकि, यह माईनिंग एल्गोरिथम, केंद्रीकरण के दो रूपों के प्रति कमजोर है। पहला, माईनिंग पारिस्थितिकी तंत्र ASIC (एप्लिकेशन-स्पेसिफिक इंटीग्रेटेड सर्किट) द्वारा प्रभुत्व में आ गया है, जो Bitcoin माईनिंग के विशिष्ट कार्य के लिए डिज़ाइन किए गए कंप्यूटर चिप हैं, और इसलिए हजारों गुना अधिक कुशल हैं। इसका मतलब है कि Bitcoin माईनिंग अब एक अत्यधिक विकेंद्रीकृत और समतावादी गतिविधि नहीं रह गई है, प्रभावी ढंग से भाग लेने के लिए लाखों डॉलर की पूंजी की आवश्यकता होती है। दूसरा, अधिकांश Bitcoin माईनर वास्तव में स्थानीय स्तर पर ब्लॉक सत्यापन नहीं करते हैं; इसके बजाय, वे ब्लॉक हेडर प्रदान करने के लिए एक केंद्रीकृत माईनिंग पूल पर निर्भर करते हैं। यह समस्या शायद और भी बदतर है: इस लेख के समय तक, शीर्ष तीन माईनिंग पूल अप्रत्यक्ष रूप से Bitcoin नेटवर्क में लगभग 50% प्रोसेसिंग पावर को नियंत्रित करते हैं, हालांकि यह इस तथ्य से कम हो जाता है कि यदि कोई पूल या गठबंधन 51% हमले का प्रयास करता है तो माईनर अन्य माईनिंग पूलों में स्विच कर सकते हैं। + +एथेरियम में वर्तमान इरादा एक ऐसे माईनिंग एल्गोरिथम का उपयोग करने का है जहां माईनर को राज्य से रैंडम डेटा प्राप्त करना आवश्यक है, ब्लॉकचेन में पिछले N ब्लॉकों से कुछ रैंडम रूप से चयनित लेनदेन की गणना करना और परिणाम का हैश वापस करना होता है। इसके दो महत्वपूर्ण लाभ हैं। पहला, एथेरियम अनुबंधों में किसी भी प्रकार की गणना शामिल हो सकती है, इसलिए एक एथेरियम ASIC अनिवार्य रूप से सामान्य गणना के लिए एक ASIC होगा - यानी एक बेहतर CPU। दूसरा, माईनिंग के लिए पूरे ब्लॉकचेन तक पहुंच की आवश्यकता होती है, जो माईनर को पूरे ब्लॉकचेन को संग्रहित करने और कम से कम प्रत्येक लेनदेन को सत्यापित करने में सक्षम होने के लिए मजबूर करता है। यह केंद्रीकृत माईनिंग पूलों की आवश्यकता को समाप्त कर देता है; हालांकि माईनिंग पूल अभी भी पुरस्कार वितरण की रैंडमनेस को समान करने की वैध भूमिका निभा सकते हैं, यह कार्य बिना किसी केंद्रीय नियंत्रण के पीयर-टू-पीयर पूलों द्वारा समान रूप से किया जा सकता है। + +इस मॉडल की जांच नहीं की गई है और माईनिंग एल्गोरिथम के रूप में अनुबंध निष्पादन का उपयोग करते समय कुछ चतुर अनुकूलन से बचने में कठिनाइयाँ हो सकती हैं। हालांकि, इस एल्गोरिथम की विशेष रूप से दिलचस्प एक विशेषता यह है कि यह किसी को भी "प्रतिष्ठा को नुकसान पहुंचाने" की अनुमति देता है, जिसमें ब्लॉकचेन में बड़ी संख्या में अनुबंधों को शामिल किया जाता है जो विशेष रूप से कुछ ASIC को बाधित करने के लिए डिजाइन किए गए हैं। ASIC निर्माताओं के लिए एक-दूसरे पर हमला करने के लिए ऐसी चाल का उपयोग करने के लिए आर्थिक प्रोत्साहन मौजूद हैं। इसलिए, हम जिस समाधान का विकास कर रहे हैं, वह अंततः एक अनुकूलजन मानवीय आर्थिक समाधान है, पूरी तरह से तकनीकी नहीं। + +### स्केलेबिलिटी {#scalability} + +एथेरियम के बारे में एक सामान्य चिंता मापनीयता का मुद्दा है। Bitcoin की तरह, एथेरियम भी उस दोष से पीड़ित है कि प्रत्येक लेनदेन को नेटवर्क में प्रत्येक नोड द्वारा प्रोसेस किया जाना चाहिए। Bitcoin के साथ, वर्तमान ब्लॉकचेन का आकार लगभग 15 GB पर है, जो प्रति घंटे लगभग 1 MB बढ़ रहा है। यदि Bitcoin नेटवर्क, वीज़ा के 2000 लेनदेन प्रति सेकंड को प्रोसेस करता, तो यह प्रति तीन सेकंड में 1 MB (प्रति घंटे 1 GB, प्रति वर्ष 8 TB) से बढ़ता। एथेरियम को भी इसी तरह के विकास पैटर्न का सामना करना पड़ सकता है, जो इस तथ्य से बदतर हो जाता है कि Bitcoin की तरह एथेरियम ब्लॉकचेन के शीर्ष पर केवल एक मुद्रा के बजाय कई एप्लिकेशन होंगे, लेकिन इस तथ्य से भी स्थिति बेहतर हो जाएगी कि एथेरियम के पूर्ण नोड्स को संपूर्ण ब्लॉकचेन इतिहास के बजाय केवल राज्य को संग्रहित करने की आवश्यकता होगी। + +इतने बड़े ब्लॉकचेन आकार की समस्या केंद्रीकरण का जोखिम है। यदि ब्लॉकचेन का आकार बढ़कर, मान लीजिए, 100 TB हो जाता है, तो संभावित परिदृश्य यह होगा कि केवल बहुत कम संख्या में बड़े व्यवसाय पूर्ण नोड चलाएंगे, जबकि सभी नियमित उपयोगकर्ता हल्के SPV नोड का उपयोग करेंगे। ऐसी स्थिति में, संभावित चिंता उत्पन्न होती है कि पूर्ण नोड एक साथ मिलकर किसी लाभदायक तरीके से धोखा देने के लिए सहमत हो सकते हैं (जैसे, ब्लॉक पुरस्कार बदलना, खुद को BTC देना)। हल्के नोड इसका तुरंत पता नहीं लगा पाएंगे। बेशक, कम से कम एक ईमानदार पूर्ण नोड की संभावना होगी, और कुछ घंटों के बाद धोखाधड़ी की जानकारी रेडिट जैसे चैनलों के माध्यम से बाहर आ जाएगी, लेकिन उस समय तक बहुत देर हो चुकी होगी: यह साधारण उपयोगकर्ताओं पर निर्भर होगा कि वे दिए गए ब्लॉकों को ब्लैकलिस्ट करने का प्रयास करें, जो एक विशाल और संभवतः अव्यवहार्य समन्वय संबंधी समस्या होगी, जो एक सफल 51% हमले को अंजाम देने के समान स्तर पर होगी। Bitcoin के मामले में, यह वर्तमान में एक समस्या है, लेकिन [पीटर टॉड द्वारा सुझाया गया](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) एक ब्लॉकचेन संशोधन मौजूद है जो इस मुद्दे को कम करेगा। + +निकट भविष्य में, इस समस्या से निपटने के लिए एथेरियम दो अतिरिक्त रणनीतियों का उपयोग करेगा। पहला, ब्लॉकचेन-आधारित माईनिंग एल्गोरिथम के कारण, कम से कम प्रत्येक माईनर को एक पूर्ण नोड होने के लिए मजबूर किया जाएगा, जो पूर्ण नोड्स की संख्या पर एक निचली सीमा बनाएगा। दूसरा और अधिक महत्वपूर्ण, हालांकि, हम प्रत्येक लेनदेन को प्रोसेस करने के बाद ब्लॉकचेन में एक मध्यवर्ती स्थिति ट्री रूट शामिल करेंगे। यहां तक कि अगर ब्लॉक सत्यापन केंद्रीकृत है, जब तक एक ईमानदार सत्यापन नोड मौजूद है, केंद्रीकरण की समस्या को एक सत्यापन प्रोटोकॉल के माध्यम से दरकिनार किया जा सकता है। यदि कोई माईनर एक अमान्य ब्लॉक प्रकाशित करता है, तो वह ब्लॉक या तो बुरी तरह से प्रारूपित होना चाहिए, या स्थिति `S[n]` गलत होगी। चूंकि `S[0]` के सही होने की जानकारी है, इसलिए कोई पहली स्थिति `S[i]` होनी चाहिए जो गलत है जहां `S[i-1]` सही है। सत्यापन नोड इंडेक्स `i` प्रदान करेगा, साथ ही "अमान्यता का प्रमाण" जो `APPLY(S[i-1],TX[i]) -> S[i]` को प्रोसेस करने के लिए आवश्यक पैट्रिशिया ट्री नोड्स के सबसेट से मिलकर बना होगा। नोड्स गणना के उस भाग को चलाने के लिए उन नोड्स का उपयोग कर सकेंगे, और देख सकेंगे कि उत्पन्न `S[i]` प्रदान किए गए `S[i]` से मेल नहीं खाता। + +एक और, अधिक परिष्कृत हमला, दुर्भावनापूर्ण माईनरों द्वारा अपूर्ण ब्लॉक प्रकाशित करने से संबंधित होगा, ताकि यह निर्धारित करने के लिए पूरी जानकारी भी मौजूद न हो कि ब्लॉक मान्य हैं या नहीं। इसका समाधान एक चुनौती-प्रतिक्रिया प्रोटोकॉल है: सत्यापन नोड्स लक्षित लेनदेन सूचकांकों के रूप में "चुनौतियाँ" जारी करते हैं, और एक नोड प्राप्त करने पर एक हल्का नोड ब्लॉक को अविश्वसनीय मानता है जब तक कि कोई अन्य नोड, चाहे वह माईनर हो या कोई अन्य सत्यापनकर्ता, वैधता के प्रमाण के रूप में पैट्रिशिया नोड्स का एक सबसेट प्रदान नहीं करता। + +## निष्कर्ष {#conclusion} + +एथेरियम प्रोटोकॉल को मूल रूप से एक क्रिप्टोकरेंसी के उन्नत संस्करण के रूप में माना गया था, जो एक अत्यधिक सामान्यीकृत प्रोग्रामिंग भाषा के माध्यम से ब्लॉकचेन पर एस्क्रो, निकासी सीमा, वित्तीय अनुबंध, जुआ बाजार और इसी तरह की उन्नत सुविधाएं प्रदान करता है। एथेरियम प्रोटोकॉल किसी भी एप्लिकेशन का सीधे "समर्थन" नहीं करेगा, लेकिन एक ट्यूरिंग-कंप्लीट प्रोग्रामिंग भाषा का अस्तित्व का मतलब है कि सैद्धांतिक रूप से किसी भी लेनदेन प्रकार या एप्लिकेशन के लिए मनमाने अनुबंध बनाए जा सकते हैं। हालांकि, एथेरियम के बारे में जो अधिक दिलचस्प है, वह यह है कि एथेरियम प्रोटोकॉल केवल मुद्रा से कहीं आगे निकल जाता है। विकेंद्रीकृत फ़ाइल भंडारण, विकेंद्रीकृत गणना और विकेंद्रीकृत भविष्यवाणी बाजारों के आसपास के प्रोटोकॉल, दर्जनों अन्य ऐसी अवधारणाओं के बीच, कम्प्यूटेशनल उद्योग की दक्षता को काफी बढ़ाने की क्षमता रखते हैं, और पहली बार एक आर्थिक परत जोड़कर अन्य पीयर-टू-पीयर प्रोटोकॉल को बड़ा बढ़ावा देते हैं। अंत में, ऐसे एप्लिकेशन की एक पर्याप्त श्रृंखला भी है जिनका पैसे से कोई लेना-देना नहीं है। + +एथेरियम प्रोटोकॉल द्वारा लागू किए गए एक मनमाने राज्य संक्रमण फंक्शन की अवधारणा एक अद्वितीय क्षमता वाला प्लेटफॉर्म प्रदान करती है; डेटा भंडारण, जुआ या वित्त में अनुप्रयोगों की एक विशिष्ट श्रृंखला के लिए अभिप्रेत एक बंद-सिरे वाला, एकल-उद्देश्य प्रोटोकॉल होने के बजाय, एथेरियम डिजाइन से खुले-सिरे वाला है, और हमारा मानना है कि यह आने वाले वर्षों में बहुत बड़ी संख्या में वित्तीय और गैर-वित्तीय प्रोटोकॉल के लिए एक आधारभूत परत के रूप में सेवा करने के लिए बेहद उपयुक्त है। + +## नोट्स और आगे पढ़ने के लिए {#notes-and-further-reading} + +### नोट्स {#notes} + +1. एक परिष्कृत पाठक यह ध्यान दे सकता है कि वास्तव में एक Bitcoin पता दीर्घवृत्ताकार वक्र सार्वजनिक कुंजी का हैश है, न कि स्वयं सार्वजनिक कुंजी। हालांकि, वास्तव में पबकी हैश को स्वयं एक सार्वजनिक कुंजी के रूप में संदर्भित करना पूरी तरह से वैध क्रिप्टोग्राफिक शब्दावली है। ऐसा इसलिए है क्योंकि Bitcoin की क्रिप्टोग्राफी को एक कस्टम डिजिटल हस्ताक्षर एल्गोरिथम माना जा सकता है, जहां सार्वजनिक कुंजी ECC पबकी के हैश से बनी होती है, हस्ताक्षर ECC पबकी और ECC हस्ताक्षर के संयोजन से बना होता है, और सत्यापन एल्गोरिथम में सार्वजनिक कुंजी के रूप में प्रदान किए गए ECC पबकी हैश के खिलाफ हस्ताक्षर में ECC पबकी की जांच करना और फिर ECC पबकी के खिलाफ ECC हस्ताक्षर का सत्यापन करना शामिल है। +2. तकनीकी रूप से, पिछले 11 ब्लॉकों का मध्यमान। +3. आंतरिक रूप से, 2 और "CHARLIE" दोनों संख्याएँ हैं [fn3](#notes), जहाँ बाद वाला बड़े-एंडियन आधार 256 प्रतिनिधित्व में है। संख्याएँ कम से कम 0 और अधिकतम 2256-1 हो सकती हैं। + +### अग्रिम पठन {#further-reading} + +1. [आंतरिक मूल्य](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/) +2. [स्मार्ट प्रॉपर्टी](https://en.bitcoin.it/wiki/Smart_Property) +3. [स्मार्ट अनुबंध](https://en.bitcoin.it/wiki/Contracts) +4. [B-मनी](http://www.weidai.com/bmoney.txt) +5. [पुन: प्रयोज्य कार्य के प्रमाण](https://nakamotoinstitute.org/finney/rpow/) +6. [मालिक प्राधिकरण के साथ सुरक्षित संपत्ति शीर्षक](https://nakamotoinstitute.org/secure-property-titles/) +7. [Bitcoin वाइट पेपर](http://bitcoin.org/bitcoin.pdf) +8. [Namecoin](https://namecoin.org/) +9. [ज़ूको का त्रिकोण](https://wikipedia.org/wiki/Zooko's_triangle) +10. [रंगीन कॉइन वाइट पेपर](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) +11. [मास्टरकॉइन वाइट पेपर](https://github.com/mastercoin-MSC/spec) +12. [विकेंद्रीकृत स्वायत्त निगम, Bitcoin पत्रिका](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/) +13. [सरलीकृत भुगतान सत्यापन](https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification) +14. [मर्कल ट्री](https://wikipedia.org/wiki/Merkle_tree) +15. [पैट्रिशिया ट्री](https://wikipedia.org/wiki/Patricia_tree) +16. [GHOST](https://eprint.iacr.org/2013/881.pdf) +17. [StorJ और स्वायत्त एजेंट, जेफ गार्ज़िक](http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html) +18. [ट्यूरिंग फेस्टिवल में माइक हर्न, स्मार्ट प्रॉपर्टी पर](https://www.youtube.com/watch?v=MVyv4t0OKe4) +19. [एथेरियम RLP](https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP) +20. [एथेरियम मर्कल पैट्रिशिया ट्री](https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree) +21. [मर्कल सम ट्री पर पीटर टॉड](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) + +_वाइट पेपर के इतिहास के लिए, [इस विकि](https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md) को देखें।_ + +_एथेरियम, कई समुदाय-संचालित, ओपन-सोर्स सॉफ़्टवेयर प्रोजेक्ट की तरह, अपनी प्रारंभिक स्थापना के बाद से विकसित हुआ है। एथेरियम के नवीनतम विकास और प्रोटोकॉल में परिवर्तन कैसे किए जाते हैं, इसके बारे में जानने के लिए, हम [इस गाइड](/learn/) की अनुशंसा करते हैं।_ diff --git a/public/content/translations/it/developers/docs/mev/index.md b/public/content/translations/it/developers/docs/mev/index.md index 3102f838f6f..ea44884b3b8 100644 --- a/public/content/translations/it/developers/docs/mev/index.md +++ b/public/content/translations/it/developers/docs/mev/index.md @@ -76,7 +76,7 @@ Nel mondo dei NFT, il MEV è un fenomeno emergente e non necessariamente redditi Tuttavia, poiché le transazioni di NFT hanno luogo sulla stessa blockchain condivisa da tutte le transazioni di Ethereum, i ricercatori possono usare tecniche simili a quelle usate per le opportunità di MEV tradizionali anche nel mercato dei NFT. -Per esempio, se si verifica un calo a livello di un NFT popolare e un ricercatore vuole un certo NFT o una serie di NFT, può programmare una transazione in modo tale da essere il primo ad acquistare il NTF o l'intera serie di NTF in una sola transazione. Oppure, se un NFT viene [erroneamente elencato a un prezzo basso](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent), un ricercatore può scavalcare gli altri acquirenti e ottenerlo a buon mercato. +Per esempio, se si verifica un calo a livello di un NFT popolare e un ricercatore vuole un certo NFT o una serie di NFT, può programmare una transazione in modo tale da essere il primo ad acquistare il NFT o l'intera serie di NFT in una sola transazione. Oppure, se un NFT viene [erroneamente elencato a un prezzo basso](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent), un ricercatore può scavalcare gli altri acquirenti e ottenerlo a buon mercato. Un esempio eloquente di MEV nel mondo dei NFT si è verificato quando un ricercatore ha speso $7 milioni per [comprare](https://etherscan.io/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5) ogni singolo Cryptopunk al prezzo di base. Un ricercatore della blockchain [ha spiegato su Twitter](https://twitter.com/IvanBogatyy/status/1422232184493121538) come l'acquirente avesse lavorato con un fornitore di MEV per mantenere segreto l'acquisto. diff --git a/public/content/translations/pcm/nft/index.md b/public/content/translations/pcm/nft/index.md index 1a3211efde8..250845ad354 100644 --- a/public/content/translations/pcm/nft/index.md +++ b/public/content/translations/pcm/nft/index.md @@ -35,7 +35,7 @@ Si as intanet of NFTs dey compia to di intanet wey plenti of us dey yus today... | Dem store ownaship of NFT on di blockchain for anyone to **verify am for publik**. | Na institushons dey kontrol ** di access to ownaship rekod of digital items** - and yu go biliv wetin dem tok. | | NFTs na [ smart kontracts](/glossary/#smart-contract) wey dey on top Ethereum. Dis mean sey dem ** fit yus dem for oda smart contracts** and aplikashon wey dey ontop Ethereum! | Kompanis wey get digital items dey always ** nid dem own "walled garden" infrastrukshure**. | | Pipol wey dey kreate **kontent fit sell dem work anywia** and fit enta one global market.get access to di global market. | Kreators dey dipend on di infrastructure and distribushon wey di platfoms wey dem yus provide for dem. Dis dey onda tams of yus and **geografika restrikshons**. | -| Pipol wey dey kreate NFT** fit retain ownaship rites** ova them own work and program royaltis direct into di NTF kontract. | Platfoms, laik savis ** wey dey stream musik, dey retain di plenti profits from sales**. | +| Pipol wey dey kreate NFT** fit retain ownaship rites** ova them own work and program royaltis direct into di NFT kontract. | Platfoms, laik savis ** wey dey stream musik, dey retain di plenti profits from sales**. | ## Wetin dem dey yus NFT for? {#nft-use-cases} diff --git a/public/content/translations/ro/developers/tutorials/erc-721-vyper-annotated-code/index.md b/public/content/translations/ro/developers/tutorials/erc-721-vyper-annotated-code/index.md index 26fbec97a8a..ad0c545726b 100644 --- a/public/content/translations/ro/developers/tutorials/erc-721-vyper-annotated-code/index.md +++ b/public/content/translations/ro/developers/tutorials/erc-721-vyper-annotated-code/index.md @@ -152,7 +152,7 @@ Identitățile utilizatorului și ale contractului sunt reprezentate în Ethereu ownerToNFTokenCount: HashMap[address, uint256] ``` -Această variabilă conține numărul de jetoane pentru fiecare proprietar. Deoarece nu există nicio corespondență între proprietari și tokenuri, singura modalitate de a identifica tokenurile pe care le deține un anumit proprietar este să ne uităm în urmă în istoricul evenimentelor din blockchain ca să găsim evenimentele `Transfer` corespunzătoare. Această variabilă ne permite să știm când avem toate NTF-urile, fără să mai fie nevoie să ne mai întoarcem în timp pentru a căuta. +Această variabilă conține numărul de jetoane pentru fiecare proprietar. Deoarece nu există nicio corespondență între proprietari și tokenuri, singura modalitate de a identifica tokenurile pe care le deține un anumit proprietar este să ne uităm în urmă în istoricul evenimentelor din blockchain ca să găsim evenimentele `Transfer` corespunzătoare. Această variabilă ne permite să știm când avem toate NFT-urile, fără să mai fie nevoie să ne mai întoarcem în timp pentru a căuta. De reținut este că acest algoritm funcționează numai pentru interfețele cu utilizatorul și serverele externe. Codul care rulează pe blockchain-ul propriu-zis nu poate citi evenimentele din trecut. diff --git a/public/content/translations/ro/glossary/index.md b/public/content/translations/ro/glossary/index.md index 8c4ce7ad459..d42c16e278a 100644 --- a/public/content/translations/ro/glossary/index.md +++ b/public/content/translations/ro/glossary/index.md @@ -556,7 +556,7 @@ Se referă la rețeaua Ethereum, o rețea peer-to-peer care propagă tranzacții Rețelele -### token non-fungibil (NTF) {#nft} +### token non-fungibil (NFT) {#nft} De asemenea, cunoscut sub numele de „deed”, acesta este un token standard introdus de propunerea ERC-721. NFT-urile pot fi urmărite și tranzacționate, însă fiecare token este unic și distinct; acestea nu sunt interschimbabile precum ETH-ul și [tokenurile ERC-20](#token-standard). NFT-urile pot reprezenta proprietatea asupra activelor digitale sau fizice. diff --git a/public/content/translations/ro/nft/index.md b/public/content/translations/ro/nft/index.md index b0b0cf18104..cf2ad9c03bf 100644 --- a/public/content/translations/ro/nft/index.md +++ b/public/content/translations/ro/nft/index.md @@ -8,7 +8,7 @@ sidebarDepth: 2 image: /images/infrastructure_transparent.png alt: Sigla Eth-ului afișată printr-o hologramă. summaryPoint1: O manieră de reprezenta ceva unic ca un activ bazat pe Ethereum. -summaryPoint2: NTF-urile oferă putere mai multă creatorilor de conținut decât oricând. +summaryPoint2: NFT-urile oferă putere mai multă creatorilor de conținut decât oricând. summaryPoint3: Sunt acționate de contractele inteligente pe blockchain-ul Ethereum. --- @@ -136,11 +136,11 @@ Să luăm ca exemplu un bilet la un eveniment sportiv. Tot aşa cum organizatoru Unele NFT-uri vor plăti în mod automat redevențe creatorilor lor atunci când sunt vândute. Conceptul este încă în curs de dezvoltare, însă este unul dintre cele mai puternice. De exemplu, proprietarii originali ai [EulerBeats Originals](https://eulerbeats.com/) câștigă o redevență de 8% la fiecare vânzare a unui NFT. Iar o serie de platforme, cum ar fi [Foundation](https://foundation.app) și [Zora](https://zora.co/), oferă redevențe pentru artiștii lor. -Aceasta se petrece complet automat, deci creatorii nu au decât să stea liniștiți și să câştige redevențe în momentul în care opera lor este vândută de la o persoană la alta. În momentul de față, calculul redevențelor se face de manieră foarte manuală și nu are precizia necesară – mulți creatori nu sunt plătiți așa cum merită. Atunci când NTF-ul dvs. este programat pentru redevențe, nu veți pierde niciodată nimic. +Aceasta se petrece complet automat, deci creatorii nu au decât să stea liniștiți și să câştige redevențe în momentul în care opera lor este vândută de la o persoană la alta. În momentul de față, calculul redevențelor se face de manieră foarte manuală și nu are precizia necesară – mulți creatori nu sunt plătiți așa cum merită. Atunci când NFT-ul dvs. este programat pentru redevențe, nu veți pierde niciodată nimic. ## La ce se utilizează NFT-urile? {#nft-use-cases} -Uitaţi câteva informații suplimentare despre unele cazuri de utilizare și viziuni mai bine dezvoltate pentru utilizarea NTF-urilor pe Ethereum. +Uitaţi câteva informații suplimentare despre unele cazuri de utilizare și viziuni mai bine dezvoltate pentru utilizarea NFT-urilor pe Ethereum. - [Conținut digital](#nfts-for-creators) - [Articole de joc](#nft-gaming) @@ -158,7 +158,7 @@ Atunci când un artist publică o lucrare pe o rețea socială, aceasta câștig NFT-urile acționează o nouă economie, în care creatorii nu cedează proprietatea asupra conținutului lor platformelor care le publică acel conținut. Dreptul de proprietate este incorporat în conținutul însuși. -Odată ce conținutul este vândut, fondurile le revin în mod direct. Și chiar atunci când noul proprietar ar revinde NTF-urile, creatorul original poate primi în mod automat redevențe. Garanția acestui lucru este asigurată prin faptul că, la orice vânzare a sa, adresa creatorului este integrată în metadatele tokenului – iar metadatele nu pot fi modificate. +Odată ce conținutul este vândut, fondurile le revin în mod direct. Și chiar atunci când noul proprietar ar revinde NFT-urile, creatorul original poate primi în mod automat redevențe. Garanția acestui lucru este asigurată prin faptul că, la orice vânzare a sa, adresa creatorului este integrată în metadatele tokenului – iar metadatele nu pot fi modificate.
Explorați, cumpărați sau creați-vă propriile NFT-uri de artă/de colecție...
diff --git a/public/content/translations/sw/nft/index.md b/public/content/translations/sw/nft/index.md index d091a31c1e5..54a0514aa1e 100644 --- a/public/content/translations/sw/nft/index.md +++ b/public/content/translations/sw/nft/index.md @@ -14,7 +14,7 @@ summaryPoint3: Inaendeshwa na mikataba erevu kwenye mnyororo wa bloku wa Ethereu ## Nini ni NFTs? {#what-are-nfts} -Tokeni zisizoweza kubadilishwa(NFTs) ni tokeni ambazo **kila moja ni ya kipekee**. Kila NTF ina sifa tofauti (haziwezi kubadilishwa) na ni chache. Hii ni tofauti kutokana na tokeni kama [ETH](/glossary/#ether) au Ethereum nyinginezo ukizingatia tokeni kama USDC ambapo kila tokeni ni sawa na ina vipengele sawa('ya kujirudia'). Hutojali ni noti gani ya dola (au ETH) unayo kwenye pochi lako, kwa sababu zote zinafanana na zina thamani sawa. Hata hivyo, _unajali_ NFT unayomiliki, kwa sababu zote huwa na sifa zao za binafsi na unaweza kuzitofautisha kutoka kwa nyingine ('haziwezi kuigwa'). +Tokeni zisizoweza kubadilishwa(NFTs) ni tokeni ambazo **kila moja ni ya kipekee**. Kila NFT ina sifa tofauti (haziwezi kubadilishwa) na ni chache. Hii ni tofauti kutokana na tokeni kama [ETH](/glossary/#ether) au Ethereum nyinginezo ukizingatia tokeni kama USDC ambapo kila tokeni ni sawa na ina vipengele sawa('ya kujirudia'). Hutojali ni noti gani ya dola (au ETH) unayo kwenye pochi lako, kwa sababu zote zinafanana na zina thamani sawa. Hata hivyo, _unajali_ NFT unayomiliki, kwa sababu zote huwa na sifa zao za binafsi na unaweza kuzitofautisha kutoka kwa nyingine ('haziwezi kuigwa'). Upekee wa kila NFT ni kuwezesha ishara ya vitu kama sanaa, vitu vinavyokusanywa ama mali isiyohamishika, ambapo kila NFT huwakilisha ulimwengu halisi ama bidhaa ya kidijitali. Umiliki wa mali uko wazi kuhakikishwa na umma kwenye [kiambajengo](/glossary/#blockchain) cha Ethereum. diff --git a/public/content/translations/uk/nft/index.md b/public/content/translations/uk/nft/index.md index eec0dab7295..c47af570868 100644 --- a/public/content/translations/uk/nft/index.md +++ b/public/content/translations/uk/nft/index.md @@ -37,7 +37,7 @@ NFT – це **індивідуально унікальні** токени. К | Творці контенту **можуть продавати свої роботи будь-де** і мають доступ до глобального ринку. | Творці покладаються на інфраструктуру й аудиторію платформ, якими користуються. На них часто поширюються умови використання та **географічні обмеження**. | | Творці NFT **можуть зберігати права власності** на власну роботу та отримувати роялті безпосередньо в контракті NFT. | Платформи, як-от музичні **стрімінгові сервіси, зберігають більшу частину прибутку від продажів**. | -## Для чого використовується NTF? {#nft-use-cases} +## Для чого використовується NFT? {#nft-use-cases} NFT використовується для багатьох речей, зокрема: diff --git a/public/content/translations/uz/defi/index.md b/public/content/translations/uz/defi/index.md index f489f13d7c6..fb4aabc8d41 100644 --- a/public/content/translations/uz/defi/index.md +++ b/public/content/translations/uz/defi/index.md @@ -355,3 +355,7 @@ DeFi — bu ochiq kodli harakat. DeFi protokollari va ilovalarining barchasi siz - [DeFi Llama Discord server](https://discord.defillama.com/) - [DeFi Pulse Discord server](https://discord.gg/Gx4TCTk) + + + + \ No newline at end of file diff --git a/public/content/translations/vi/nft/index.md b/public/content/translations/vi/nft/index.md index 1d6f3c45a6b..c7f21e26ce4 100644 --- a/public/content/translations/vi/nft/index.md +++ b/public/content/translations/vi/nft/index.md @@ -75,7 +75,7 @@ Trang web này cũng có một tên miền thay thế được vận hành bởi ## NFT hoạt động như thế nào? {#how-nfts-work} -NTF, giống như mặt hàng kĩ thuật số trên chuỗi khối Ethereum, và được tạo ra thông qua một chương trình máy tính đặc biệt dựa trên Ethereum được gọi là "Hợp đồng thông minh" Những hợp đồng này tuân theo một quy tắc nhất định, như tiêu chuẩn [ERC-721](/glossary/#erc-721) hoặc [ERC-1155](/glossary/#erc-1155), những tiêu chuẩn này có thể xác định những gì hợp đồng có thể làm. +NFT, giống như mặt hàng kĩ thuật số trên chuỗi khối Ethereum, và được tạo ra thông qua một chương trình máy tính đặc biệt dựa trên Ethereum được gọi là "Hợp đồng thông minh" Những hợp đồng này tuân theo một quy tắc nhất định, như tiêu chuẩn [ERC-721](/glossary/#erc-721) hoặc [ERC-1155](/glossary/#erc-1155), những tiêu chuẩn này có thể xác định những gì hợp đồng có thể làm. Hợp đồng thông minh NFT có thể làm một số điều quan trọng: diff --git a/public/images/dapps/crackandstack.png b/public/images/dapps/crackandstack.png new file mode 100644 index 00000000000..ff824e923c8 Binary files /dev/null and b/public/images/dapps/crackandstack.png differ diff --git a/public/manifest.json b/public/manifest.json index b8b8154a040..eccc6708daf 100644 --- a/public/manifest.json +++ b/public/manifest.json @@ -38,5 +38,5 @@ ] } ], - "description": "Ethereum is a global, decentralized platform for money and new kinds of applications. On Ethereum, you can write code that controls money, and build applications accessible anywhere in the world.", -} \ No newline at end of file + "description": "Ethereum is a global, decentralized platform for money and new kinds of applications. On Ethereum, you can write code that controls money, and build applications accessible anywhere in the world." +} diff --git a/src/components/ActionCard.tsx b/src/components/ActionCard.tsx index b111bfe80bd..be0b38cd5de 100644 --- a/src/components/ActionCard.tsx +++ b/src/components/ActionCard.tsx @@ -1,33 +1,18 @@ import { StaticImageData } from "next/image" -import type { ReactNode } from "react" -import { - Box, - type BoxProps, - Flex, - Heading, - LinkBox, - type LinkBoxProps, - LinkOverlay, - useColorModeValue, -} from "@chakra-ui/react" +import type { BaseHTMLAttributes, ElementType, ReactNode } from "react" -import { Image } from "@/components/Image" -import { BaseLink } from "@/components/Link" -import Text from "@/components/OldText" +import { TwImage } from "@/components/Image" +import InlineLink from "@/components/ui/Link" +import { LinkBox, LinkOverlay } from "@/components/ui/link-box" -const linkBoxFocusStyles: BoxProps = { - borderRadius: "base", - boxShadow: "0px 8px 17px rgba(0, 0, 0, 0.15)", - bg: "tableBackgroundHover", - transition: "transform 0.1s", - transform: "scale(1.02)", -} - -const linkFocusStyles: BoxProps = { - textDecoration: "none", -} +import { cn } from "@/lib/utils/cn" -export type ActionCardProps = Omit & { +import { Flex } from "./ui/flex" +export type ActionCardProps = Omit< + BaseHTMLAttributes, + "title" +> & { + as?: ElementType children?: ReactNode href: string alt?: string @@ -53,64 +38,43 @@ const ActionCard = ({ isBottom = true, ...props }: ActionCardProps) => { - const descriptionColor = useColorModeValue("blackAlpha.700", "whiteAlpha.800") - return ( - {alt - - - - {title} +
+

+ + + {title} + - - - {description} - - {children && {children}} - +

+

{description}

+ {children &&
{children}
} +
) } diff --git a/src/components/BugBountyCards.tsx b/src/components/BugBountyCards.tsx index fb017ea3611..56786711e3e 100644 --- a/src/components/BugBountyCards.tsx +++ b/src/components/BugBountyCards.tsx @@ -14,7 +14,10 @@ const CardRow = ({ children }: ChildOnlyProp) => ( {children} ) -const SubmitBugBountyButton = ({ children, ...props }: ButtonLinkProps) => ( +const SubmitBugBountyButton = ({ + children, + ...props +}: Omit) => ( { return ( handleClick(item, idx)} asChild > @@ -89,7 +89,7 @@ const ButtonDropdown = ({ list, className }: ButtonDropdownProps) => { return ( handleClick(item, idx)} > {text} diff --git a/src/components/Buttons/ButtonTwoLines/index.tsx b/src/components/Buttons/ButtonTwoLines/index.tsx deleted file mode 100644 index 03210dbe166..00000000000 --- a/src/components/Buttons/ButtonTwoLines/index.tsx +++ /dev/null @@ -1,113 +0,0 @@ -import type { IconType } from "react-icons/lib" -import { Icon, Stack, Text } from "@chakra-ui/react" - -import Button, { type ButtonProps } from "../Button" -import ButtonLink, { type ButtonLinkProps } from "../ButtonLink" - -type CommonProps = { - icon: IconType | typeof Icon - iconAlignment?: "left" | "right" | "start" | "end" - /** - * Reduced choices of the button variant. - * - * This component only accepts the `solid` or `outline` variant - */ - variant?: "solid" | "outline" - /** - * Reduced choices of the button size - * - * This component only accepts the `md` or `sm` sizes - */ - size?: "md" | "sm" - mainText: string - helperText: string - /** - * Should the main text be below the helper text instead of ab? - */ - reverseTextOrder?: boolean -} - -type OmittedTypes = "variant" | "size" - -type ButtonTypeProps = CommonProps & - Omit & { - href?: never - } - -type ButtonLinkTypeProps = CommonProps & - Omit & { - toId?: never - } - -type ButtonTwoLinesProps = ButtonTypeProps | ButtonLinkTypeProps - -const hasHref = (props: ButtonTwoLinesProps): props is ButtonLinkTypeProps => { - return "href" in props -} - -const ButtonTwoLines = (props: ButtonTwoLinesProps) => { - const { - icon: Icon, - iconAlignment = "start", - mainText, - helperText, - reverseTextOrder = false, - size = "md", - ...rest - } = props - - const isIconLeft = ["left", "start"].includes(iconAlignment) - - const vertPadding: ButtonTwoLinesProps["py"] = size === "md" ? "4" : "2" - - const buttonStyles: ButtonProps = { - [isIconLeft ? "leftIcon" : "rightIcon"]: , - textAlign: isIconLeft ? "start" : "end", - justifyContent: isIconLeft ? "flex-start" : "flex-end", - } - - const Component = hasHref(props) ? ButtonLink : Button - - return ( - // TODO: fix type error - // @ts-expect-error incompatible prop type shapes - - - - {mainText} - - - {helperText} - - - - ) -} - -export default ButtonTwoLines diff --git a/src/components/Buttons/index.ts b/src/components/Buttons/index.ts index 73e0e2bcbb1..6f05838f36d 100644 --- a/src/components/Buttons/index.ts +++ b/src/components/Buttons/index.ts @@ -1,4 +1,3 @@ export { default as Button, type ButtonProps, checkIsSecondary } from "./Button" export { default as ButtonLink, type ButtonLinkProps } from "./ButtonLink" -export { default as ButtonTwoLines } from "./ButtonTwoLines" export { default as IconButton } from "./IconButton" diff --git a/src/components/FileContributors.tsx b/src/components/FileContributors.tsx index f98e4c6eefe..1e727925591 100644 --- a/src/components/FileContributors.tsx +++ b/src/components/FileContributors.tsx @@ -12,12 +12,15 @@ import type { ChildOnlyProp, FileContributor } from "@/lib/types" import { Button } from "@/components/Buttons" import InlineLink from "@/components/Link" -import Modal from "@/components/Modal" import Text from "@/components/OldText" import Translation from "@/components/Translation" import { trackCustomEvent } from "@/lib/utils/matomo" +import Modal from "./ui/dialog-modal" + +import { useBreakpointValue } from "@/hooks/useBreakpointValue" + const ContributorList = ({ children }: Required) => ( {children} @@ -61,12 +64,14 @@ const FileContributors = ({ date: Date.now().toString(), } as FileContributor) + const modalSize = useBreakpointValue({ base: "xl", md: "md" } as const) + return ( <> setModalOpen(false)} - size={{ base: "full", md: "xl" }} + open={isModalOpen} + onOpenChange={(open) => setModalOpen(open)} + size={modalSize} title={} > diff --git a/src/components/HorizontalCard.tsx b/src/components/HorizontalCard.tsx index 48cbae9ca24..d4ab4caa81b 100644 --- a/src/components/HorizontalCard.tsx +++ b/src/components/HorizontalCard.tsx @@ -1,35 +1,37 @@ import React, { ReactNode } from "react" -import { Box, Flex, FlexProps } from "@chakra-ui/react" import { cn } from "@/lib/utils/cn" import Emoji from "./Emoji" -import Text from "./OldText" -export type HorizontalCardProps = Omit & { +export interface HorizontalCardProps + extends Omit, "title"> { emoji: string + emojiClassName?: string title?: ReactNode description: ReactNode + children?: ReactNode } const HorizontalCard = ({ emoji, + emojiClassName, title, description, children, className, - ...rest -}: HorizontalCardProps) => ( - - - - {title} - - {description} - - <>{children} - - -) + ...props +}: HorizontalCardProps) => { + return ( +
+ +
+

{title}

+

{description}

+ {children} +
+
+ ) +} export default HorizontalCard diff --git a/src/components/Layer2NetworksTable/NetworksNoResults.tsx b/src/components/Layer2NetworksTable/NetworksNoResults.tsx index 799d8493659..a7468bd0c90 100644 --- a/src/components/Layer2NetworksTable/NetworksNoResults.tsx +++ b/src/components/Layer2NetworksTable/NetworksNoResults.tsx @@ -1,12 +1,8 @@ -import { useTranslation } from "next-i18next" - import { trackCustomEvent } from "@/lib/utils/matomo" import { Button } from "../ui/buttons/Button" const FindWalletsNoResults = ({ resetFilters }) => { - const { t } = useTranslation("page-wallets-find-wallet") - // Track empty state trackCustomEvent({ eventCategory: "Wallet_empty_state", @@ -26,14 +22,12 @@ const FindWalletsNoResults = ({ resetFilters }) => { return (
-

- {t("page-find-wallet-empty-results-title")} -

+

No results

There are no networks matching your criteria, try adding some filters

diff --git a/src/components/Layer2ProductCard.tsx b/src/components/Layer2ProductCard.tsx index a4c637fb900..844654a86ce 100644 --- a/src/components/Layer2ProductCard.tsx +++ b/src/components/Layer2ProductCard.tsx @@ -1,12 +1,11 @@ -// Libraries import { StaticImageData } from "next/image" import { useTranslation } from "next-i18next" -import { Box, Center, Flex, Heading } from "@chakra-ui/react" -import { ButtonLink } from "@/components/Buttons" -import { Image } from "@/components/Image" -import InlineLink from "@/components/Link" -import Text from "@/components/OldText" +import { Card, CardContent, CardFooter, CardHeader } from "@/components/ui/card" + +import { ButtonLink } from "./ui/buttons/Button" +import InlineLink from "./ui/Link" +import { TwImage } from "./Image" export type Layer2ProductCardProps = { children?: React.ReactNode @@ -38,72 +37,75 @@ const Layer2ProductCard = ({ const { t } = useTranslation("page-layer-2") return ( - -
+
- {alt} -
- - - - {name} - - {children && ( - - {children} - - )} - - {description} - - {note.length > 0 && ( - + + + +
+

{name}

+ {children &&
{children}
} +
+ + + +
+

{description}

+ + {note && ( +

{t("layer-2-note")} {note} - +

)} - - {bridge && ( - - {name} {t("layer-2-bridge")} - - )} - {ecosystemPortal && ( - - {name} {t("layer-2-ecosystem-portal")} - - )} - {tokenLists && ( - - {name} {t("layer-2-token-lists")} - +
+ +
+ {bridge && ( + + {name} {t("layer-2-bridge")} + + )} + + {ecosystemPortal && ( + + {name} {t("layer-2-ecosystem-portal")} + + )} + + {tokenLists && ( + + {name} {t("layer-2-token-lists")} + + )} +
+ + + + {url && ( + + {t("layer-2-explore")} {name} + )} - - - - {t("layer-2-explore")} {name} - - - + + ) } diff --git a/src/components/Modal/index.tsx b/src/components/Modal/index.tsx deleted file mode 100644 index 11d2e80c59b..00000000000 --- a/src/components/Modal/index.tsx +++ /dev/null @@ -1,51 +0,0 @@ -import React from "react" -import { - Button, - HStack, - Modal as ChakraModal, - ModalBody, - ModalCloseButton, - ModalContent, - ModalContentProps, - ModalFooter, - ModalHeader, - ModalOverlay, - type ModalProps as ChakraModalProps, -} from "@chakra-ui/react" - -export type ModalProps = ChakraModalProps & { - children?: React.ReactNode - title?: React.ReactNode - actionButtonLabel?: string - contentProps?: ModalContentProps -} - -const Modal = ({ - children, - title, - actionButtonLabel, - contentProps, - ...restProps -}: ModalProps) => { - return ( - - - - - - {title} - - - {children} - {actionButtonLabel && ( - - - - - )} - - - ) -} - -export default Modal diff --git a/src/components/Nav/Mobile/LvlAccordion.tsx b/src/components/Nav/Mobile/LvlAccordion.tsx index 8fed6c6ee83..e3596464ab5 100644 --- a/src/components/Nav/Mobile/LvlAccordion.tsx +++ b/src/components/Nav/Mobile/LvlAccordion.tsx @@ -96,7 +96,7 @@ const LvlAccordion = ({ className={cn( "text-md font-bold", isActivePage - ? "text-primary-low-contrast" + ? "text-primary-high-contrast" : "text-body" )} > diff --git a/src/components/Nav/useNav.ts b/src/components/Nav/useNav.ts index 45c438c2ab6..95ab3496483 100644 --- a/src/components/Nav/useNav.ts +++ b/src/components/Nav/useNav.ts @@ -186,6 +186,11 @@ export const useNav = () => { description: t("nav-defi-description"), href: "/defi/", }, + { + label: t("payments-page"), + description: t("nav-payments-description"), + href: "/payments/", + }, { label: t("dao-page"), description: t("nav-dao-description"), diff --git a/src/components/PageMetadata.tsx b/src/components/PageMetadata.tsx index e39257ad0e9..1adf4215545 100644 --- a/src/components/PageMetadata.tsx +++ b/src/components/PageMetadata.tsx @@ -42,7 +42,6 @@ const PageMetadata = ({ const desc = description || t("site-description") const siteTitle = t("site-title") - const fullTitle = `${title} | ${siteTitle}` // Remove any query params (?) or hash links (#) const path = asPath.replace(/[?#].*/, "") @@ -66,10 +65,10 @@ const PageMetadata = ({ { name: `twitter:card`, content: `summary_large_image` }, { name: `twitter:creator`, content: author || siteTitle }, { name: `twitter:site`, content: author || siteTitle }, - { name: `twitter:title`, content: fullTitle }, + { name: `twitter:title`, content: title }, { name: `twitter:description`, content: desc }, { name: `twitter:image`, content: ogImageUrl }, - { property: `og:title`, content: fullTitle }, + { property: `og:title`, content: title }, { property: `og:locale`, content: locale! }, { property: `og:description`, content: desc }, { property: `og:type`, content: `website` }, @@ -80,7 +79,7 @@ const PageMetadata = ({ return ( - {fullTitle} + {title} {metadata.map((data) => ( { - const shadow = useColorModeValue("tableBox.light", "tableBox.dark") - const CATEGORY_NAME = "category-name" return ( - - +

{category} - - +

+ {content.map(({ title, description, link, image, alt, id }, idx) => ( - - + +
{image && ( - {alt} )} - - - - {title} - - {description} - - +
+ +
+
{title}
+
{description}
+
{link && ( {actionLabel} to {title} website )} - + ))} - - + + ) } diff --git a/src/components/Quiz/QuizzesModal.tsx b/src/components/Quiz/QuizzesModal.tsx index 38298e49467..8b0580606ce 100644 --- a/src/components/Quiz/QuizzesModal.tsx +++ b/src/components/Quiz/QuizzesModal.tsx @@ -1,11 +1,13 @@ import { QuizStatus } from "@/lib/types" -import Modal from "../Modal" +import Modal, { type ModalProps } from "../ui/dialog-modal" import { Center } from "../ui/flex" +import { useBreakpointValue } from "@/hooks/useBreakpointValue" + type QuizzesModalProps = { isQuizModalOpen: boolean - onQuizModalClose: () => void + onQuizModalOpenChange: (open: boolean) => void children: React.ReactNode quizStatus: QuizStatus } @@ -14,7 +16,7 @@ const QuizzesModal = ({ children, quizStatus, isQuizModalOpen, - onQuizModalClose, + onQuizModalOpenChange, ...props }: QuizzesModalProps) => { // TODO: remove bang in utility class names when Modal is migrated @@ -25,11 +27,13 @@ const QuizzesModal = ({ return "!bg-error-light dark:!bg-error-dark" } + const size = useBreakpointValue({ base: "xl", md: "md" })! + return ( diff --git a/src/components/Quiz/stories/QuizModal.stories.tsx b/src/components/Quiz/stories/QuizModal.stories.tsx index b8f61dc6b3c..df64747c900 100644 --- a/src/components/Quiz/stories/QuizModal.stories.tsx +++ b/src/components/Quiz/stories/QuizModal.stories.tsx @@ -17,7 +17,7 @@ const meta = { args: { isQuizModalOpen: true, quizStatus: "neutral", - onQuizModalClose: fn(), + onQuizModalOpenChange: fn(), children: "", widgetProps: { quizKey: LAYER_2_QUIZ_KEY, diff --git a/src/components/Simulator/SimulatorModal.tsx b/src/components/Simulator/SimulatorModal.tsx index 1d2d7dea07f..c38ef765efd 100644 --- a/src/components/Simulator/SimulatorModal.tsx +++ b/src/components/Simulator/SimulatorModal.tsx @@ -1,35 +1,9 @@ import React from "react" -import { - type ModalContentProps, - type ModalProps, - UseDisclosureReturn, -} from "@chakra-ui/react" -import Modal from "../Modal" +import Modal, { type ModalProps } from "../ui/dialog-modal" -type SimulatorModalProps = ModalContentProps & - Pick & { - isOpen: UseDisclosureReturn["isOpen"] - onClose: UseDisclosureReturn["onClose"] - children?: React.ReactNode - } +type SimulatorModalProps = Omit -export const SimulatorModal = ({ - isOpen, - onClose, - children, - ...restProps -}: SimulatorModalProps) => { - return ( - - {children} - - ) +export const SimulatorModal = (props: SimulatorModalProps) => { + return } diff --git a/src/components/Simulator/index.tsx b/src/components/Simulator/index.tsx index 64acaea2863..d324c1d467d 100644 --- a/src/components/Simulator/index.tsx +++ b/src/components/Simulator/index.tsx @@ -4,6 +4,8 @@ import { Flex, type FlexProps, Grid } from "@chakra-ui/react" import { trackCustomEvent } from "@/lib/utils/matomo" +import type { ModalProps } from "../ui/dialog-modal" + import { PATH_ID_QUERY_PARAM, SIMULATOR_ID } from "./constants" import { Explanation } from "./Explanation" import type { @@ -41,14 +43,16 @@ export const Simulator = ({ children, data }: SimulatorProps) => { } // When simulator closed: log event, clear URL params and close modal - const onClose = (): void => { - trackCustomEvent({ - eventCategory: "simulator", - eventAction: `${pathId}_click`, - eventName: `close-from-step-${step + 1}`, - }) - // Clearing URL Params will reset pathId, and close modal - clearUrlParams() + const onClose: ModalProps["onOpenChange"] = (open) => { + if (!open) { + trackCustomEvent({ + eventCategory: "simulator", + eventAction: `${pathId}_click`, + eventName: `close-from-step-${step + 1}`, + }) + // Clearing URL Params will reset pathId, and close modal + clearUrlParams() + } } // Remove URL search param if invalid pathId @@ -181,7 +185,7 @@ export const Simulator = ({ children, data }: SimulatorProps) => { })} - +