# Table of Contents - [Ethereum Virtual Machine (EVM) | ethereum.org](#ethereum-virtual-machine-evm-ethereum-org) - [Opcodes for the EVM | ethereum.org](#opcodes-for-the-evm-ethereum-org) - [Blocks | ethereum.org](#blocks-ethereum-org) - [Miundo ya data na usimbaji | ethereum.org](#miundo-ya-data-na-usimbaji-ethereum-org) - [Lugha za programu | ethereum.org](#lugha-za-programu-ethereum-org) - [Utangulizi wa Nodi za Uanzishaji za Ethereum | ethereum.org](#utangulizi-wa-nodi-za-uanzishaji-za-ethereum-ethereum-org) - [Viwango vya Tokeni | ethereum.org](#viwango-vya-tokeni-ethereum-org) - [프로그래밍 언어 | ethereum.org](#-ethereum-org) - [Ethereum kwa Wasanidi wa Elixir | ethereum.org](#ethereum-kwa-wasanidi-wa-elixir-ethereum-org) - [Ethereum kwa wasanidi wa JavaScript | ethereum.org](#ethereum-kwa-wasanidi-wa-javascript-ethereum-org) - [인출 자격 증명 | ethereum.org](#-ethereum-org) - [이더리움 부트노드 소개 | ethereum.org](#-ethereum-org) - [Mitandao ya Maendeleo | ethereum.org](#mitandao-ya-maendeleo-ethereum-org) - [Nodi ya Kumbukumbu ya Ethereum | ethereum.org](#nodi-ya-kumbukumbu-ya-ethereum-ethereum-org) - [Viwango vya Uendelezaji vya Ethereum | ethereum.org](#viwango-vya-uendelezaji-vya-ethereum-ethereum-org) - [Potal Netwoki | ethereum.org](#potal-netwoki-ethereum-org) - [データ構造とエンコーディング | ethereum.org](#-ethereum-org) - [イーサリアムのブートノード入門 | ethereum.org](#-ethereum-org) - [Usanjari rahisi | ethereum.org](#usanjari-rahisi-ethereum-org) - [개발 네트워크 | ethereum.org](#-ethereum-org) - [Gasper | ethereum.org](#gasper-ethereum-org) - [이더리움 스택 소개 | ethereum.org](#-ethereum-org) - [Usanifu na UX katika Web3 | ethereum.org](#usanifu-na-ux-katika-web3-ethereum-org) - [Maktaba za mkataba mahiri | ethereum.org](#maktaba-za-mkataba-mahiri-ethereum-org) - [弱い主観性 | ethereum.org](#-ethereum-org) - [Kanuni 7 za muundo wa kiolesura cha Web3 | ethereum.org](#kanuni-7-za-muundo-wa-kiolesura-cha-web3-ethereum-org) - [Mikakati ya Kuhifadhi Data kwenye Mnyororo wa Vitalu | ethereum.org](#mikakati-ya-kuhifadhi-data-kwenye-mnyororo-wa-vitalu-ethereum-org) - [Utangulizi wa mikataba mahiri | ethereum.org](#utangulizi-wa-mikataba-mahiri-ethereum-org) - [Mifumo ya Uundaji wa Dapp | ethereum.org](#mifumo-ya-uundaji-wa-dapp-ethereum-org) - [Delphi開発者のためのイーサリアム | ethereum.org](#delphi-ethereum-org) - [데이터 가용성 | ethereum.org](#-ethereum-org) - [합의 메커니즘 | ethereum.org](#-ethereum-org) - [Dart開発者のためのイーサリアム | ethereum.org](#dart-ethereum-org) - [Elixir開発者のためのイーサリアム | ethereum.org](#elixir-ethereum-org) - [지분 증명(PoS) 대 작업증명(PoW) | ethereum.org](#-pos-pow-ethereum-org) - [이더리움 아카이브 노드 | ethereum.org](#-ethereum-org) - [JavaScript 개발자를 위한 이더리움 | ethereum.org](#javascript-ethereum-org) - [토큰 표준 | ethereum.org](#-ethereum-org) - [Kuboresha mikataba mahiri | ethereum.org](#kuboresha-mikataba-mahiri-ethereum-org) - [イーサリアムのアーカイブ・ノード | ethereum.org](#-ethereum-org) - [ライト・クライアント | ethereum.org](#-ethereum-org) - [스마트 컨트랙트 조합성 | ethereum.org](#-ethereum-org) - [포털 네트워크 | ethereum.org](#-ethereum-org) - [イーサリアム開発標準 | ethereum.org](#-ethereum-org) - [Go 개발자를 위한 이더리움 | ethereum.org](#go-ethereum-org) - [Uthibitisho | ethereum.org](#uthibitisho-ethereum-org) - [Rust 개발자를 위한 이더리움 | ethereum.org](#rust-ethereum-org) - [Upatikanaji wa data | ethereum.org](#upatikanaji-wa-data-ethereum-org) - [Mashine Pepe ya Ethereum (EVM) | ethereum.org](#mashine-pepe-ya-ethereum-evm-ethereum-org) - [ノードのアーキテクチャ | ethereum.org](#-ethereum-org) - [スマート・コントラクトの命名 | ethereum.org](#-ethereum-org) - [Java開発者向けのイーサリアム | ethereum.org](#java-ethereum-org) - [Uongezaji wa Uwezo | ethereum.org](#uongezaji-wa-uwezo-ethereum-org) - [Ufafanuzi wa hifadhi ya siri ya Web3 | ethereum.org](#ufafanuzi-wa-hifadhi-ya-siri-ya-web3-ethereum-org) - [Kiwango cha Tokeni Inayolipwa cha ERC-1363 | ethereum.org](#kiwango-cha-tokeni-inayolipwa-cha-erc-1363-ethereum-org) - [Hifadhi Iliyogatuliwa | ethereum.org](#hifadhi-iliyogatuliwa-ethereum-org) - [Web3 인터페이스 디자인을 위한 7가지 휴리스틱 | ethereum.org](#web3-7-ethereum-org) - [스마트 컨트랙트 소개 | ethereum.org](#-ethereum-org) - [Usanjari wa kiambishi awali cha urefu wa kujirudia (RLP) | ethereum.org](#usanjari-wa-kiambishi-awali-cha-urefu-wa-kujirudia-rlp-ethereum-org) - [シンプル・シリアライズ (Simple serialize) | ethereum.org](#-simple-serialize-ethereum-org) - [ERC-777 토큰 표준 | ethereum.org](#erc-777-ethereum-org) - [Web3 비밀 저장소 정의 | ethereum.org](#web3-ethereum-org) - [イーサの技術入門 | ethereum.org](#-ethereum-org) - [ERC-1155 다중 토큰 표준 | ethereum.org](#erc-1155-ethereum-org) - [Gesi na ada za Ethereum: muhtasari wa kiufundi | ethereum.org](#gesi-na-ada-za-ethereum-muhtasari-wa-kiufundi-ethereum-org) - [Uthibitishaji kwenye Ethereum | ethereum.org](#uthibitishaji-kwenye-ethereum-ethereum-org) - [Mitandao | ethereum.org](#mitandao-ethereum-org) - [マイニング | ethereum.org](#-ethereum-org) - [データと分析 | ethereum.org](#-ethereum-org) - [Web3におけるデザインとUX | ethereum.org](#web3-ux-ethereum-org) - [이더리움 가상 머신(EVM) | ethereum.org](#-evm-ethereum-org) - [Go開発者のためのイーサリアム | ethereum.org](#go-ethereum-org) - [Rust開発者のためのイーサリアム | ethereum.org](#rust-ethereum-org) - [.NET開発者のためのイーサリアム | ethereum.org](#-net-ethereum-org) - [इथेरियम बूटनोड का परिचय | ethereum.org](#-ethereum-org) - [스마트 컨트랙트와 상호작용하기 | ethereum.org](#-ethereum-org) - [スマート・コントラクトの紹介 | ethereum.org](#-ethereum-org) - [브릿지 | ethereum.org](#-ethereum-org) - [Python 개발자를 위한 이더리움 | ethereum.org](#python-ethereum-org) - [ポータル・ネットワーク | ethereum.org](#-ethereum-org) - [ERC-7540 非同期トークン化ヴォールト標準 | ethereum.org](#erc-7540-ethereum-org) - [データ可用性 | ethereum.org](#-ethereum-org) - [클라이언트 다양성 | ethereum.org](#-ethereum-org) - [Uthibitisho wa Dau (PoS) | ethereum.org](#uthibitisho-wa-dau-pos-ethereum-org) - [작업증명 (PoW) | ethereum.org](#-pow-ethereum-org) - [스마트 컨트랙트 검증 | ethereum.org](#-ethereum-org) - [Mbinu bora za muundo wa soko la ubadilishanaji lililogatuliwa (DEX) | ethereum.org](#mbinu-bora-za-muundo-wa-soko-la-ubadilishanaji-lililogatuliwa-dex-ethereum-org) - [イーサリアム仮想マシン (EVM) | ethereum.org](#-evm-ethereum-org) - [スマート・コントラクトとのやり取り | ethereum.org](#-ethereum-org) - [재귀 길이 접두사(RLP) 직렬화 | ethereum.org](#-rlp-ethereum-org) - [지분 증명 (PoS) | ethereum.org](#-pos-ethereum-org) - [이더리움에서의 인증 | ethereum.org](#-ethereum-org) - [스마트 컨트랙트 업그레이드 | ethereum.org](#-ethereum-org) - [ブロック・エクスプローラー | ethereum.org](#-ethereum-org) - [分散型ストレージ | ethereum.org](#-ethereum-org) - [スマート・コントラクトの検証 | ethereum.org](#-ethereum-org) - [Python開発者のためのイーサリアム | ethereum.org](#python-ethereum-org) - [자주 묻는 질문 | ethereum.org](#-ethereum-org) - [ERC-1363 Payable Token標準 | ethereum.org](#erc-1363-payable-token-ethereum-org) - [Chaneli za Hali | ethereum.org](#chaneli-za-hali-ethereum-org) - [Kiwango cha Tokeni cha ERC-20 | ethereum.org](#kiwango-cha-tokeni-cha-erc-20-ethereum-org) - [スマート・コントラクトのアップグレード | ethereum.org](#-ethereum-org) - [탈중앙화 거래소(DEX) 디자인 모범 사례 | ethereum.org](#-dex-ethereum-org) - [네트워크 | ethereum.org](#-ethereum-org) - [इथेरियम आर्काइव नोड | ethereum.org](#-ethereum-org) - [Dart डेव्हलपर्ससाठी इथेरियम | ethereum.org](#dart-ethereum-org) - [지분 증명 보상 및 페널티 | ethereum.org](#-ethereum-org) - [Ruby 개발자를 위한 이더리움 | ethereum.org](#ruby-ethereum-org) - [Token Standards | ethereum.org](#token-standards-ethereum-org) - [Dart 개발자를 위한 이더리움 | ethereum.org](#dart-ethereum-org) - [.NET 개발자를 위한 이더리움 | ethereum.org](#-net-ethereum-org) - [Sidechains | ethereum.org](#sidechains-ethereum-org) - [Ethereum for Rust developers | ethereum.org](#ethereum-for-rust-developers-ethereum-org) - [ERC-1155 Multi-Token Standard | ethereum.org](#erc-1155-multi-token-standard-ethereum-org) - [디앱(dapp) 개발 프레임워크 | ethereum.org](#-dapp-ethereum-org) - [Scaling | ethereum.org](#scaling-ethereum-org) - [데이터 및 분석 | ethereum.org](#-ethereum-org) - [Ethereum Development Standards | ethereum.org](#ethereum-development-standards-ethereum-org) - [Plasma chains | ethereum.org](#plasma-chains-ethereum-org) - [Maximal extractable value (MEV) | ethereum.org](#maximal-extractable-value-mev-ethereum-org) - [State Channels | ethereum.org](#state-channels-ethereum-org) - [Zero-knowledge rollups | ethereum.org](#zero-knowledge-rollups-ethereum-org) - [ERC-721 Non-Fungible Token Standard | ethereum.org](#erc-721-non-fungible-token-standard-ethereum-org) - [ERC-20 Token Standard | ethereum.org](#erc-20-token-standard-ethereum-org) - [スマート・コントラクトのデプロイ | ethereum.org](#-ethereum-org) - [채굴 | ethereum.org](#-ethereum-org) - [이더리움 기술 소개 | ethereum.org](#-ethereum-org) --- # Ethereum Virtual Machine (EVM) | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/evm/#main-content) Change page Ethereum Virtual Machine (EVM) ============================== Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/evm/index.md) On this page The Ethereum Virtual Machine (EVM) is a decentralized virtual environment that executes code consistently and securely across all [Ethereum](https://ethereum.org/) nodes. Nodes run the EVM to execute smart contracts, using "[gas](https://ethereum.org/developers/docs/gas/) " to measure the computational effort required for [operations](https://ethereum.org/developers/docs/evm/opcodes/) , ensuring efficient resource allocation and network security. [](https://ethereum.org/developers/docs/evm/#prerequisites) Prerequisites ------------------------------------------------------------------------- Some basic familiarity with common terminology in computer science such as [bytes (opens in a new tab)](https://wikipedia.org/wiki/Byte) , [memory (opens in a new tab)](https://wikipedia.org/wiki/Computer_memory) , and a [stack (opens in a new tab)](https://wikipedia.org/wiki/Stack_(abstract_data_type)) are necessary to understand the EVM. It would also be helpful to be comfortable with cryptography/blockchain concepts like [hash functions (opens in a new tab)](https://wikipedia.org/wiki/Cryptographic_hash_function) and the [Merkle tree (opens in a new tab)](https://wikipedia.org/wiki/Merkle_tree) . [](https://ethereum.org/developers/docs/evm/#from-ledger-to-state-machine) From ledger to state machine ------------------------------------------------------------------------------------------------------- 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](https://ethereum.org/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 (opens in a new tab)](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](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fevm%2Fevm.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/evm/evm.png) _Diagram adapted from [Ethereum EVM illustrated (opens in a new tab)](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) _ [](https://ethereum.org/developers/docs/evm/#the-ethereum-state-transition-function) The Ethereum state transition function --------------------------------------------------------------------------------------------------------------------------- The EVM behaves as a mathematical function would: Given an input, it produces a deterministic output. It therefore is quite helpful to more formally describe Ethereum as having a **state transition function**: Y(S, T)= S' Copy Given an old valid state `(S)` and a new set of valid transactions `(T)`, the Ethereum state transition function `Y(S, T)` produces a new valid output state `S'` ### [](https://ethereum.org/developers/docs/evm/#state) State In the context of Ethereum, the state is an enormous data structure called a [modified Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) , which keeps all [accounts](https://ethereum.org/developers/docs/accounts/) linked by hashes and reducible to a single root hash stored on the blockchain. ### [](https://ethereum.org/developers/docs/evm/#transactions) Transactions Transactions are cryptographically signed instructions from accounts. There are two types of transactions: those which result in message calls and those which result in contract creation. Contract creation results in the creation of a new contract account containing compiled [smart contract](https://ethereum.org/developers/docs/smart-contracts/anatomy/) bytecode. Whenever another account makes a message call to that contract, it executes its bytecode. [](https://ethereum.org/developers/docs/evm/#evm-instructions) EVM instructions ------------------------------------------------------------------------------- The EVM executes as a [stack machine (opens in a new tab)](https://wikipedia.org/wiki/Stack_machine) with a depth of 1024 items. Each item is a 256-bit word, which was chosen for the ease of use with 256-bit cryptography (such as Keccak-256 hashes or secp256k1 signatures). During execution, the EVM maintains a transient _memory_ (as a word-addressed byte array), which does not persist between transactions. ### [](https://ethereum.org/developers/docs/evm/#transient-storage) Transient storage Transient storage is a per-transaction key–value store accessed through the `TSTORE` and `TLOAD` opcodes. It persists across all internal calls during the same transaction but is cleared at the end of the transaction. Unlike memory, transient storage is modeled as part of the EVM state rather than the execution frame, yet it is not committed to the global state. Transient storage enables gas-efficient temporary state sharing across internal calls during a transaction. ### [](https://ethereum.org/developers/docs/evm/#storage) Storage Contracts contain a Merkle Patricia _storage_ trie (as a word-addressable word array), associated with the account in question and part of the global state. This persistent storage differs from transient storage, which is available only for the duration of a single transaction and does not form part of the account's persistent storage trie. ### [](https://ethereum.org/developers/docs/evm/#opcodes) Opcodes Compiled smart contract bytecode executes as a number of EVM [opcodes](https://ethereum.org/developers/docs/evm/opcodes/) , which perform standard stack operations like `XOR`, `AND`, `ADD`, `SUB`, etc. The EVM also implements a number of blockchain-specific stack operations, such as `ADDRESS`, `BALANCE`, `BLOCKHASH`, etc. The opcode set also includes `TSTORE` and `TLOAD`, which provide access to transient storage. [![A diagram showing where gas is needed for EVM operations](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fgas%2Fgas.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/gas/gas.png) _Diagrams adapted from [Ethereum EVM illustrated (opens in a new tab)](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) _ [](https://ethereum.org/developers/docs/evm/#evm-implementations) EVM implementations ------------------------------------------------------------------------------------- All implementations of the EVM must adhere to the specification described in the Ethereum Yellowpaper. Over Ethereum's ten year history, the EVM has undergone several revisions, and there are several implementations of the EVM in various programming languages. [Ethereum execution clients](https://ethereum.org/developers/docs/nodes-and-clients/#execution-clients) include an EVM implementation. Additionally, there are multiple standalone implementations, including: * [Py-EVM (opens in a new tab)](https://github.com/ethereum/py-evm) - _Python_ * [evmone (opens in a new tab)](https://github.com/ethereum/evmone) - _C++_ * [ethereumjs-vm (opens in a new tab)](https://github.com/ethereumjs/ethereumjs-vm) - _JavaScript_ * [revm (opens in a new tab)](https://github.com/bluealloy/revm) - _Rust_ [](https://ethereum.org/developers/docs/evm/#further-reading) Further Reading ----------------------------------------------------------------------------- * [Ethereum Yellowpaper (opens in a new tab)](https://ethereum.github.io/yellowpaper/paper.pdf) * [Jellopaper aka KEVM: Semantics of EVM in K (opens in a new tab)](https://jellopaper.org/) * [The Beigepaper (opens in a new tab)](https://github.com/chronaeon/beigepaper) * [Ethereum Virtual Machine Opcodes (opens in a new tab)](https://www.ethervm.io/) * [Ethereum Virtual Machine Opcodes Interactive Reference (opens in a new tab)](https://www.evm.codes/) * [A short introduction in Solidity's documentation (opens in a new tab)](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) * [Mastering Ethereum - The Ethereum Virtual Machine (opens in a new tab)](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc) [](https://ethereum.org/developers/docs/evm/#related-topics) Related Topics --------------------------------------------------------------------------- * [Gas](https://ethereum.org/developers/docs/gas/) [](https://ethereum.org/developers/docs/evm/#tutorials) Tutorials: Ethereum Virtual Machine (EVM) / Opcodes on Ethereum ----------------------------------------------------------------------------------------------------------------------- * [Understanding the Yellow Paper's EVM Specifications](https://ethereum.org/developers/tutorials/yellow-paper-evm/) _– A guided walkthrough of the formal EVM spec from the Ethereum Yellow Paper._ * [Reverse Engineering a Contract](https://ethereum.org/developers/tutorials/reverse-engineering-a-contract/) _– How to reverse-engineer a compiled smart contract using EVM opcodes._ Test your Ethereum knowledge ---------------------------- Ethereum Virtual Machine (EVM) Question number 1:The EVM is one machine, running in one place, that Ethereum nodes send their transactions to for execution. A True B False Check answer Is this page helpful? --- # Opcodes for the EVM | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/evm/opcodes/#main-content) Change page Opcodes for the EVM =================== Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/evm/opcodes/index.md) On this page [](https://ethereum.org/developers/docs/evm/opcodes/#overview) Overview ----------------------------------------------------------------------- This is an updated version of the EVM reference page at [wolflo/evm-opcodes (opens in a new tab)](https://github.com/wolflo/evm-opcodes) . Also drawn from the [Yellow Paper (opens in a new tab)](https://ethereum.github.io/yellowpaper/paper.pdf) , the [Jello Paper (opens in a new tab)](https://jellopaper.org/evm/) , and the [geth (opens in a new tab)](https://github.com/ethereum/go-ethereum) implementation. This is intended to be an accessible reference, but it is not particularly rigorous. If you want to be certain of correctness and aware of every edge case, using the Jello Paper or a client implementation is advisable. Looking for an interactive reference? Check out [evm.codes (opens in a new tab)](https://www.evm.codes/) . For operations with dynamic gas costs, see [gas.md (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md) . 💡 Quick tip: To view entire lines, use `[shift] + scroll` to scroll horizontally on desktop. | Stack | Name | Gas | Initial Stack | Resulting Stack | Mem / Storage | Notes | | --- | --- | --- | --- | --- | --- | --- | | 00 | STOP | 0 | | | | halt execution | | 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 addition modulo 2\*\*256 | | 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 multiplication modulo 2\*\*256 | | 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 subtraction modulo 2\*\*256 | | 04 | DIV | 5 | `a, b` | `a // b` | | uint256 division | | 05 | SDIV | 5 | `a, b` | `a // b` | | int256 division | | 06 | MOD | 5 | `a, b` | `a % b` | | uint256 modulus | | 07 | SMOD | 5 | `a, b` | `a % b` | | int256 modulus | | 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 addition modulo N | | 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 multiplication modulo N | | 0A | EXP | [A1 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 exponentiation modulo 2\*\*256 | | 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [sign extend (opens in a new tab)](https://wikipedia.org/wiki/Sign_extension)
`x` from `(b+1)` bytes to 32 bytes | | 0C-0F | _invalid_ | | | | | | | 10 | LT | 3 | `a, b` | `a < b` | | uint256 less-than | | 11 | GT | 3 | `a, b` | `a > b` | | uint256 greater-than | | 12 | SLT | 3 | `a, b` | `a < b` | | int256 less-than | | 13 | SGT | 3 | `a, b` | `a > b` | | int256 greater-than | | 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 equality | | 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero | | 16 | AND | 3 | `a, b` | `a && b` | | bitwise AND | | 17 | OR | 3 | `a, b` | `a \| b` | | bitwise OR | | 18 | XOR | 3 | `a, b` | `a ^ b` | | bitwise XOR | | 19 | NOT | 3 | `a` | `~a` | | bitwise NOT | | 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`th byte of (u)int256 `x`, from the left | | 1B | SHL | 3 | `shift, val` | `val << shift` | | shift left | | 1C | SHR | 3 | `shift, val` | `val >> shift` | | logical shift right | | 1D | SAR | 3 | `shift, val` | `val >> shift` | | arithmetic shift right | | 1E-1F | _invalid_ | | | | | | | 20 | KECCAK256 | [A2 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | | 21-2F | _invalid_ | | | | | | | 30 | ADDRESS | 2 | `.` | `address(this)` | | address of executing contract | | 31 | BALANCE | [A5 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | balance, in wei | | 32 | ORIGIN | 2 | `.` | `tx.origin` | | address that originated the tx | | 33 | CALLER | 2 | `.` | `msg.sender` | | address of msg sender | | 34 | CALLVALUE | 2 | `.` | `msg.value` | | msg value, in wei | | 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | read word from msg data at index `idx` | | 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | length of msg data, in bytes | | 37 | CALLDATACOPY | [A3 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem\[dstOst:dstOst+len-1\] := msg.data\[ost:ost+len-1\] | copy msg data | | 38 | CODESIZE | 2 | `.` | `len(this.code)` | | length of executing contract's code, in bytes | | 39 | CODECOPY | [A3 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem\[dstOst:dstOst+len-1\] := this.code\[ost:ost+len-1\] | | 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | gas price of tx, in wei per unit gas [\*\* (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | | 3B | EXTCODESIZE | [A5 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | size of code at addr, in bytes | | 3C | EXTCODECOPY | [A4 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem\[dstOst:dstOst+len-1\] := addr.code\[ost:ost+len-1\] | copy code from `addr` | | 3D | RETURNDATASIZE | 2 | `.` | `size` | | size of returned data from last external call, in bytes | | 3E | RETURNDATACOPY | [A3 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem\[dstOst:dstOst+len-1\] := returndata\[ost:ost+len-1\] | copy returned data from last external call | | 3F | EXTCODEHASH | [A5 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hash = addr.exists ? keccak256(addr.code) : 0 | | 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | | 41 | COINBASE | 2 | `.` | `block.coinbase` | | address of proposer of current block | | 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | timestamp of current block | | 43 | NUMBER | 2 | `.` | `block.number` | | number of current block | | 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | randomness beacon | | 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | gas limit of current block | | 46 | CHAINID | 2 | `.` | `chain_id` | | push current [chain id (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-155)
onto stack | | 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | balance of executing contract, in wei | | 48 | BASEFEE | 2 | `.` | `block.basefee` | | base fee of current block | | 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-4844) | | 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | blob base fee of current block ([EIP-7516 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-7516)
) | | 4B-4F | _invalid_ | | | | | | | 50 | POP | 2 | `_anon` | `.` | | remove item from top of stack and discard it | | 51 | MLOAD | 3[\* (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` | | 52 | MSTORE | 3[\* (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem\[ost:ost+32\] := val | write a word to memory | | 53 | MSTORE8 | 3[\* (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem\[ost\] := val && 0xFF | write a single byte to memory | | 54 | SLOAD | [A6 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | read word from storage | | 55 | SSTORE | [A7 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage\[key\] := val | write word to storage | | 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` mark that `pc` is only assigned if `dst` is a valid jumpdest | | 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ? dst : $pc + 1` | | 58 | PC | 2 | `.` | `$pc` | | program counter | | 59 | MSIZE | 2 | `.` | `len(mem)` | | size of memory in current execution context, in bytes | | 5A | GAS | 2 | `.` | `gasRemaining` | | | | 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data | | 5C | TLOAD | 100 | `key` | `tstorage[key]` | | read word from transient storage ([EIP-1153 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-1153)
) | | 5D | TSTORE | 100 | `key, val` | `.` | tstorage\[key\] := val | write word to transient storage ([EIP-1153 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-1153)
) | | 5E | MCOPY | 3+3\*words+[A0 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem\[dstOst\] := mem\[ost:ost+len\] | copy memory from one area to another ([EIP-5656 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-5656)
) | | 5F | PUSH0 | 2 | `.` | `uint8` | | push the constant value 0 onto stack | | 60 | PUSH1 | 3 | `.` | `uint8` | | push 1-byte value onto stack | | 61 | PUSH2 | 3 | `.` | `uint16` | | push 2-byte value onto stack | | 62 | PUSH3 | 3 | `.` | `uint24` | | push 3-byte value onto stack | | 63 | PUSH4 | 3 | `.` | `uint32` | | push 4-byte value onto stack | | 64 | PUSH5 | 3 | `.` | `uint40` | | push 5-byte value onto stack | | 65 | PUSH6 | 3 | `.` | `uint48` | | push 6-byte value onto stack | | 66 | PUSH7 | 3 | `.` | `uint56` | | push 7-byte value onto stack | | 67 | PUSH8 | 3 | `.` | `uint64` | | push 8-byte value onto stack | | 68 | PUSH9 | 3 | `.` | `uint72` | | push 9-byte value onto stack | | 69 | PUSH10 | 3 | `.` | `uint80` | | push 10-byte value onto stack | | 6A | PUSH11 | 3 | `.` | `uint88` | | push 11-byte value onto stack | | 6B | PUSH12 | 3 | `.` | `uint96` | | push 12-byte value onto stack | | 6C | PUSH13 | 3 | `.` | `uint104` | | push 13-byte value onto stack | | 6D | PUSH14 | 3 | `.` | `uint112` | | push 14-byte value onto stack | | 6E | PUSH15 | 3 | `.` | `uint120` | | push 15-byte value onto stack | | 6F | PUSH16 | 3 | `.` | `uint128` | | push 16-byte value onto stack | | 70 | PUSH17 | 3 | `.` | `uint136` | | push 17-byte value onto stack | | 71 | PUSH18 | 3 | `.` | `uint144` | | push 18-byte value onto stack | | 72 | PUSH19 | 3 | `.` | `uint152` | | push 19-byte value onto stack | | 73 | PUSH20 | 3 | `.` | `uint160` | | push 20-byte value onto stack | | 74 | PUSH21 | 3 | `.` | `uint168` | | push 21-byte value onto stack | | 75 | PUSH22 | 3 | `.` | `uint176` | | push 22-byte value onto stack | | 76 | PUSH23 | 3 | `.` | `uint184` | | push 23-byte value onto stack | | 77 | PUSH24 | 3 | `.` | `uint192` | | push 24-byte value onto stack | | 78 | PUSH25 | 3 | `.` | `uint200` | | push 25-byte value onto stack | | 79 | PUSH26 | 3 | `.` | `uint208` | | push 26-byte value onto stack | | 7A | PUSH27 | 3 | `.` | `uint216` | | push 27-byte value onto stack | | 7B | PUSH28 | 3 | `.` | `uint224` | | push 28-byte value onto stack | | 7C | PUSH29 | 3 | `.` | `uint232` | | push 29-byte value onto stack | | 7D | PUSH30 | 3 | `.` | `uint240` | | push 30-byte value onto stack | | 7E | PUSH31 | 3 | `.` | `uint248` | | push 31-byte value onto stack | | 7F | PUSH32 | 3 | `.` | `uint256` | | push 32-byte value onto stack | | 80 | DUP1 | 3 | `a` | `a, a` | | clone 1st value on stack | | 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clone 2nd value on stack | | 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clone 3rd value on stack | | 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clone 4th value on stack | | 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clone 5th value on stack | | 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clone 6th value on stack | | 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clone 7th value on stack | | 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clone 8th value on stack | | 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clone 9th value on stack | | 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clone 10th value on stack | | 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clone 11th value on stack | | 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clone 12th value on stack | | 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clone 13th value on stack | | 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clone 14th value on stack | | 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clone 15th value on stack | | 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clone 16th value on stack | | 90 | SWAP1 | 3 | `a, b` | `b, a` | | | | 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | | 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | | 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | | 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | | 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | | 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | | 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | | 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | | 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | | 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | | 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | | 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | | 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | | 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | | 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | | A0 | LOG0 | [A8 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory\[ost:ost+len-1\]) | | A1 | LOG1 | [A8 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory\[ost:ost+len-1\], topic0) | | A2 | LOG2 | [A8 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory\[ost:ost+len-1\], topic0, topic1) | | A3 | LOG3 | [A8 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory\[ost:ost+len-1\], topic0, topic1, topic2) | | A4 | LOG4 | [A8 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory\[ost:ost+len-1\], topic0, topic1, topic2, topic3) | | A5-EF | _invalid_ | | | | | | | F0 | CREATE | [A9 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp(\[address(this), this.nonce\])) | | F1 | CALL | [AA (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem\[retOst:retOst+retLen-1\] := returndata | | | F2 | CALLCODE | [AA (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem\[retOst:retOst+retLen-1\] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value | | F3 | RETURN | 0[\* (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | return mem\[ost:ost+len-1\] | | F4 | DELEGATECALL | [AA (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem\[retOst:retOst+retLen-1\] := returndata | | | F5 | CREATE2 | [A9 (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem\[ost:ost+len-1\]))\[12:\] | | F6-F9 | _invalid_ | | | | | | | FA | STATICCALL | [AA (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem\[retOst:retOst+retLen-1\] := returndata | | | FB-FC | _invalid_ | | | | | | | FD | REVERT | 0[\* (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem\[ost:ost+len-1\]) | | FE | INVALID | [AF (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-141) | | | FF | SELFDESTRUCT | [AB (opens in a new tab)](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | sends all ETH to `addr`; if executed in the same transaction as a contract was created it destroys the contract | Is this page helpful? --- # Blocks | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/blocks/#main-content) Change page Blocks ====== Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/blocks/index.md) On this page Blocks are batches of transactions with a hash of the previous block in the chain. This links blocks together (in a chain) because hashes are cryptographically derived from the block data. This prevents fraud, because one change in any block in history would invalidate all the following blocks as all subsequent hashes would change and everyone running the blockchain would notice. [](https://ethereum.org/developers/docs/blocks/#prerequisites) Prerequisites ---------------------------------------------------------------------------- Blocks are a very beginner-friendly topic. But to help you better understand this page, we recommend you first read [Accounts](https://ethereum.org/developers/docs/accounts/) , [Transactions](https://ethereum.org/developers/docs/transactions/) , and our [introduction to Ethereum](https://ethereum.org/developers/docs/intro-to-ethereum/) . [](https://ethereum.org/developers/docs/blocks/#why-blocks) Why blocks? ----------------------------------------------------------------------- To ensure that all participants on the [Ethereum](https://ethereum.org/) network maintain a synchronized state and agree on the precise history of transactions, we batch transactions into blocks. This means dozens (or hundreds) of transactions are committed, agreed on, and synchronized all at once. [![A diagram showing transaction in a block causing state changes](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fblocks%2Ftx-block.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/blocks/tx-block.png) _Diagram adapted from [Ethereum EVM illustrated (opens in a new tab)](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) _ By spacing out commits, we give all network participants enough time to come to consensus: even though transaction requests occur dozens of times per second, blocks are only created and committed on Ethereum once every twelve seconds. [](https://ethereum.org/developers/docs/blocks/#how-blocks-work) How blocks work -------------------------------------------------------------------------------- To preserve the transaction history, blocks are strictly ordered (every new block created contains a reference to its parent block), and transactions within blocks are strictly ordered as well. Except in rare cases, at any given time, all participants on the network are in agreement on the exact number and history of blocks, and are working to batch the current live transaction requests into the next block. Once a block is put together by a randomly selected validator on the network, it is propagated to the rest of the network; all nodes add this block to the end of their blockchain, and a new validator is selected to create the next block. The exact block-assembly process and commitment/consensus process is currently specified by Ethereum’s “proof-of-stake” protocol. [](https://ethereum.org/developers/docs/blocks/#proof-of-stake-protocol) Proof-of-stake protocol ------------------------------------------------------------------------------------------------ Proof-of-stake means the following: * Validating nodes have to stake 32 ETH into a deposit contract as collateral against bad behavior. This helps protect the network because provably dishonest activity leads to some or all of that stake being destroyed. * In every slot (spaced twelve seconds apart) a validator is randomly selected to be the block proposer. They bundle transactions together, execute them and determine a new 'state'. They wrap this information into a block and pass it around to other validators. * Other validators who hear about the new block re-execute the transactions to ensure they agree with the proposed change to the global state. Assuming the block is valid, they add it to their own database. * If a validator hears about two conflicting blocks for the same slot they use their fork-choice algorithm to pick the one supported by the most staked ETH. [More on proof-of-stake](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) [](https://ethereum.org/developers/docs/blocks/#block-anatomy) What's in a block? --------------------------------------------------------------------------------- There is a lot of information contained within a block. At the highest level a block contains the following fields: | Field | Description | | --- | --- | | `slot` | the slot the block belongs to | | `proposer_index` | the ID of the validator proposing the block | | `parent_root` | the hash of the preceding block | | `state_root` | the root hash of the state object | | `body` | an object containing several fields, as defined below | The block `body` contains several fields of its own: | Field | Description | | --- | --- | | `randao_reveal` | a value used to select the next block proposer | | `eth1_data` | information about the deposit contract | | `graffiti` | arbitrary data used to tag blocks | | `proposer_slashings` | list of validators to be slashed | | `attester_slashings` | list of attesters to be slashed | | `attestations` | list of attestations made against previous slots | | `deposits` | list of new deposits to the deposit contract | | `voluntary_exits` | list of validators exiting the network | | `sync_aggregate` | subset of validators used to serve light clients | | `execution_payload` | transactions passed from the execution client | The `attestations` field contains a list of all the attestations in the block. Attestations have their own data type that contains several pieces of data. Each attestation contains: | Field | Description | | --- | --- | | `aggregation_bits` | a list of which validators participated in this attestation | | `data` | a container with multiple subfields | | `signature` | aggregate signature of a set of validators against `data` part | The `data` field in the `attestation` contains the following: | Field | Description | | --- | --- | | `slot` | the slot the attestation relates to | | `index` | indices for attesting validators | | `beacon_block_root` | the root hash of the Beacon block seen as the head of the chain | | `source` | the last justified checkpoint | | `target` | the latest epoch boundary block | Executing the transactions in the `execution_payload` updates the global state. All clients re-execute the transactions in the `execution_payload` to ensure the new state matches that in the new block `state_root` field. This is how clients can tell that a new block is valid and safe to add to their blockchain. The `execution payload` itself is an object with several fields. There is also an `execution_payload_header` that contains important summary information about the execution data. These data structures are organized as follows: The `execution_payload_header` contains the following fields: | Field | Description | | --- | --- | | `parent_hash` | hash of the parent block | | `fee_recipient` | account address for paying transaction fees to | | `state_root` | root hash for the global state after applying changes in this block | | `receipts_root` | hash of the transaction receipts trie | | `logs_bloom` | data structure containing event logs | | `prev_randao` | value used in random validator selection | | `block_number` | the number of the current block | | `gas_limit` | maximum gas allowed in this block | | `gas_used` | the actual amount of gas used in this block | | `timestamp` | the block time | | `extra_data` | arbitrary additional data as raw bytes | | `base_fee_per_gas` | the base fee value | | `block_hash` | Hash of execution block | | `transactions_root` | root hash of the transactions in the payload | | `withdrawal_root` | root hash of the withdrawals in the payload | The `execution_payload` itself contains the following (notice this is identical to the header except that instead of the root hash of the transactions it includes the actual list of transactions and withdrawal information) : | Field | Description | | --- | --- | | `parent_hash` | hash of the parent block | | `fee_recipient` | account address for paying transaction fees to | | `state_root` | root hash for the global state after applying changes in this block | | `receipts_root` | hash of the transaction receipts trie | | `logs_bloom` | data structure containing event logs | | `prev_randao` | value used in random validator selection | | `block_number` | the number of the current block | | `gas_limit` | maximum gas allowed in this block | | `gas_used` | the actual amount of gas used in this block | | `timestamp` | the block time | | `extra_data` | arbitrary additional data as raw bytes | | `base_fee_per_gas` | the base fee value | | `block_hash` | Hash of execution block | | `transactions` | list of transactions to be executed | | `withdrawals` | list of withdrawal objects | The `withdrawals` list contains `withdrawal` objects structured in the following way: | Field | Description | | --- | --- | | `address` | account address that has withdrawn | | `amount` | withdrawal amount | | `index` | withdrawal index value | | `validatorIndex` | validator index value | [](https://ethereum.org/developers/docs/blocks/#block-time) Block time ---------------------------------------------------------------------- Block time refers to the time separating blocks. In Ethereum, time is divided up into twelve second units called 'slots'. In each slot a single validator is selected to propose a block. Assuming all validators are online and fully functional there will be a block in every slot, meaning the block time is 12s. However, occasionally validators might be offline when called to propose a block, meaning slots can sometimes go empty. This implementation differs from proof-of-work based systems where block times are probabilistic and tuned by the protocol's target mining difficulty. Ethereum's [average block time (opens in a new tab)](https://etherscan.io/chart/blocktime) is a perfect example of this whereby the transition from proof-of-work to proof-of-stake can be clearly inferred based on the consistency of the new 12s block time. [](https://ethereum.org/developers/docs/blocks/#block-size) Block size ---------------------------------------------------------------------- A final important note is that blocks themselves are bounded in size. Each block has a target size of 30 million gas but the size of blocks will increase or decrease in accordance with network demands, up until the block limit of 60 million gas (2x target block size). The block gas limit can be adjusted upwards or downwards by a factor of 1/1024 from the previous block's gas limit. As a result, validators can change the block gas limit through consensus. The total amount of gas expended by all transactions in the block must be less than the block gas limit. This is important because it ensures that blocks can’t be arbitrarily large. If blocks could be arbitrarily large, then less performant full nodes would gradually stop being able to keep up with the network due to space and speed requirements. The larger the block, the greater the computing power required to process them in time for the next slot. This is a centralizing force, which is resisted by capping block sizes. [](https://ethereum.org/developers/docs/blocks/#further-reading) Further reading -------------------------------------------------------------------------------- _Know of a community resource that helped you? Edit this page and add it!_ [](https://ethereum.org/developers/docs/blocks/#related-topics) Related topics ------------------------------------------------------------------------------ * [Transactions](https://ethereum.org/developers/docs/transactions/) * [Gas](https://ethereum.org/developers/docs/gas/) * [Proof-of-stake](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) Test your Ethereum knowledge ---------------------------- Blocks Question number 1:Why does Ethereum limit how much gas a single block can use? A To cap how much ETH can move in one block B To give each validator an equal quota, so no proposer can include more transactions than another C Because block size is fixed in the protocol and cannot be changed D Because blocks could otherwise grow so large that less powerful nodes fall behind Check answer Is this page helpful? --- # Miundo ya data na usimbaji | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/#main-content) Change page Miundo ya data na usimbaji ========================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-structures-and-encoding/index.md) Kwenye ukurasa huu Ethereum huunda, kuhifadhi na kuhamisha viwango vikubwa vya data. Data hii lazima iumbizwe kwa njia sanifu na zinazotumia kumbukumbu vizuri ili kuruhusu mtu yeyote [kuendesha nodi](https://ethereum.org/sw/run-a-node/) kwenye maunzi ya kawaida ya kiwango cha mtumiaji. Ili kufanikisha hili, miundo kadhaa maalum ya data inatumika kwenye staki ya Ethereum. [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/#prerequisites) Masharti ------------------------------------------------------------------------------------------------ Unapaswa kuelewa misingi ya Ethereum na [programu ya mteja](https://ethereum.org/sw/developers/docs/nodes-and-clients/) . Uelewa wa tabaka la mtandao na [waraka mweupe wa Ethereum](https://ethereum.org/sw/whitepaper/) unapendekezwa. [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/#data-structures) Miundo ya data -------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/#patricia-merkle-tries) Trie za Patricia merkle Trie za Patricia Merkle ni miundo inayosimba jozi za ufunguo-thamani kwenye trie thabiti na iliyothibitishwa kwa njia ya kificho. Hizi hutumika sana katika tabaka la utekelezaji la Ethereum. [Zaidi kuhusu Trie za Patricia Merkle](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) ### [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/#recursive-length-prefix) Recursive Length Prefix Recursive Length Prefix (RLP) ni mbinu ya usanjari inayotumika sana katika tabaka la utekelezaji la Ethereum. [Zaidi kuhusu RLP](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/rlp/) ### [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/#simple-serialize) Simple Serialize Simple Serialize (SSZ) ni umbizo kuu la usanjari kwenye tabaka la mwafaka la Ethereum kwa sababu ya utangamano wake na merklelization. [Zaidi kuhusu SSZ](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/ssz/) --- # Lugha za programu | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/programming-languages/#main-content) Change page Lugha za programu ================= Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/index.md) Kwenye ukurasa huu Dhana potofu ya kawaida ni kwamba waendelezaji lazima waandike [mikataba mahiri](https://ethereum.org/sw/developers/docs/smart-contracts/) ili kujenga kwenye Ethereum. Hili si kweli. Moja ya uzuri wa mtandao wa Ethereum na jamii ni kwamba unaweza [kushiriki](https://ethereum.org/sw/community/) kwa kutumia karibu lugha yoyote ya programu. Ethereum na jamii yake inakumbatia programu huria. Unaweza kupata miradi ya jamii - utekelezaji wa wateja, API, mifumo ya uendelezaji, zana za majaribio - katika lugha mbalimbali. [](https://ethereum.org/sw/developers/docs/programming-languages/#data) Chagua lugha yako ----------------------------------------------------------------------------------------- Chagua lugha yako ya programu unayoipendelea ili kupata miradi, rasilimali, na jamii za mtandaoni: * [Ethereum kwa waendelezaji wa Dart](https://ethereum.org/sw/developers/docs/programming-languages/dart/) * [Ethereum kwa waendelezaji wa Delphi](https://ethereum.org/sw/developers/docs/programming-languages/delphi/) * [Ethereum kwa waendelezaji wa .NET](https://ethereum.org/sw/developers/docs/programming-languages/dot-net/) * [Ethereum kwa waendelezaji wa Elixir](https://ethereum.org/sw/developers/docs/programming-languages/elixir/) * [Ethereum kwa waendelezaji wa Go](https://ethereum.org/sw/developers/docs/programming-languages/golang/) * [Ethereum kwa waendelezaji wa Java](https://ethereum.org/sw/developers/docs/programming-languages/java/) * [Ethereum kwa waendelezaji wa JavaScript](https://ethereum.org/sw/developers/docs/programming-languages/javascript/) * [Ethereum kwa waendelezaji wa Python](https://ethereum.org/sw/developers/docs/programming-languages/python/) * [Ethereum kwa waendelezaji wa Ruby](https://ethereum.org/sw/developers/docs/programming-languages/ruby/) * [Ethereum kwa waendelezaji wa Rust](https://ethereum.org/sw/developers/docs/programming-languages/rust/) ### [](https://ethereum.org/sw/developers/docs/programming-languages/#other-lang) Vipi ikiwa lugha yangu haitumiki Ikiwa unataka kuunganisha kwenye rasilimali au kuelekeza kwenye jamii ya mtandaoni kwa lugha ya ziada ya programu unaweza kuomba ukurasa mpya kwa [kufungua suala (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/issues/new/choose) . Ikiwa unataka tu kuandika msimbo ili kuingiliana na mnyororo wa vitalu kwa kutumia lugha ambayo haitumiki kwa sasa unaweza kutumia [kiolesura cha JSON-RPC](https://ethereum.org/sw/developers/docs/apis/json-rpc/) ili kuunganisha kwenye mtandao wa Ethereum. Lugha yoyote ya programu inayoweza kutumia TCP/IP inaweza kutumia kiolesura hiki. --- # Utangulizi wa Nodi za Uanzishaji za Ethereum | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/nodes-and-clients/bootnodes/#main-content) Change page Utangulizi wa Nodi za Uanzishaji za Ethereum ============================================ Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/nodes-and-clients/bootnodes/index.md) Kwenye ukurasa huu Wakati nodi mpya inapojiunga na mtandao wa Ethereum inahitaji kuunganishwa na nodi ambazo tayari ziko kwenye mtandao ili kisha kugundua wenza (peers) wapya. Sehemu hizi za kuingilia kwenye mtandao wa Ethereum zinaitwa nodi za uanzishaji. Wateja (Clients) kwa kawaida huwa na orodha ya nodi za uanzishaji zilizowekwa moja kwa moja kwenye kodi zao (hardcoded). Nodi hizi za uanzishaji kwa kawaida huendeshwa na timu ya devops ya Taasisi ya Ethereum au timu za wateja wenyewe. Kumbuka kwamba nodi za uanzishaji si sawa na nodi tuli (static nodes). Nodi tuli huitwa mara kwa mara, wakati nodi za uanzishaji huitwa tu ikiwa hakuna wenza wa kutosha wa kuunganishwa nao na nodi inahitaji kuanzisha miunganisho mipya. [](https://ethereum.org/sw/developers/docs/nodes-and-clients/bootnodes/#connect-to-a-bootnode) Unganisha kwenye nodi ya uanzishaji ---------------------------------------------------------------------------------------------------------------------------------- Wateja wengi wana orodha ya nodi za uanzishaji zilizojengewa ndani, lakini unaweza pia kutaka kuendesha nodi yako ya uanzishaji, au kutumia ambayo si sehemu ya orodha iliyowekwa kwenye kodi ya mteja. Katika hali hii, unaweza kuzibainisha wakati wa kuanzisha mteja wako, kama ifuatavyo (mfano ni wa Geth, tafadhali angalia nyaraka za mteja wako): geth --bootnodes "enode://@:" Nakili [](https://ethereum.org/sw/developers/docs/nodes-and-clients/bootnodes/#run-a-bootnode) Endesha nodi ya uanzishaji ------------------------------------------------------------------------------------------------------------------ Nodi za uanzishaji ni nodi kamili ambazo haziko nyuma ya NAT ([Tafsiri ya Anwani ya Mtandao (inafunguka katika kichupo kipya)](https://www.geeksforgeeks.org/network-address-translation-nat/) ). Kila nodi kamili inaweza kufanya kazi kama nodi ya uanzishaji mradi tu inapatikana kwa umma. Unapoanzisha nodi inapaswa kuweka logi ya [enode](https://ethereum.org/sw/developers/docs/networking-layer/network-addresses/#enode) yako, ambayo ni kitambulisho cha umma ambacho wengine wanaweza kutumia kuunganisha kwenye nodi yako. Enode kwa kawaida hutengenezwa upya kila inapoanzishwa tena, kwa hivyo hakikisha unaangalia nyaraka za mteja wako kuhusu jinsi ya kutengeneza enode ya kudumu kwa ajili ya nodi yako ya uanzishaji. Ili kuwa nodi nzuri ya uanzishaji ni wazo zuri kuongeza idadi ya juu zaidi ya wenza wanaoweza kuunganishwa nayo. Kuendesha nodi ya uanzishaji yenye wenza wengi kutaongeza hitaji la kipimo data (bandwidth) kwa kiasi kikubwa. [](https://ethereum.org/sw/developers/docs/nodes-and-clients/bootnodes/#available-bootnodes) Nodi za uanzishaji zinazopatikana ------------------------------------------------------------------------------------------------------------------------------ Orodha ya nodi za uanzishaji zilizojengewa ndani katika go-ethereum inaweza kupatikana [hapa (inafunguka katika kichupo kipya)](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23) . Nodi hizi za uanzishaji zinasimamiwa na Taasisi ya Ethereum na timu ya go-ethereum. Kuna orodha nyingine za nodi za uanzishaji zinazosimamiwa na watu wa kujitolea zinazopatikana. Tafadhali hakikisha kila wakati unajumuisha angalau nodi moja rasmi ya uanzishaji, vinginevyo unaweza kufanyiwa shambulio la eclipse (eclipse attack). --- # Viwango vya Tokeni | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/standards/tokens/#main-content) Change page Viwango vya Tokeni ================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/tokens/index.md) Kwenye ukurasa huu [](https://ethereum.org/sw/developers/docs/standards/tokens/#introduction) Utangulizi ------------------------------------------------------------------------------------- Viwango vingi vya maendeleo vya [Ethereum](https://ethereum.org/sw/) vinalenga miingiliano ya tokeni. Viwango hivi husaidia kuhakikisha mikataba mahiri inabaki inayoweza kuunganishwa, hivyo wakati mradi mpya unatoa tokeni, inabaki inayoendana na mabadilishano na programu zilizogatuliwa zilizopo. Viwango vya tokeni vinafafanua jinsi tokeni zinavyofanya kazi na kuingiliana katika mfumo wa ikolojia wa Ethereum. Vinarahisisha kwa watengenezaji kujenga bila kurudia kazi iliyokwisha fanywa, kuhakikisha kwamba tokeni zinafanya kazi bila matatizo na pochi, mabadilishano, na majukwaa ya fedha zilizogatuliwa (DeFi). Iwe katika michezo, utawala, au matumizi mengine, viwango hivi vinatoa uthabiti na kufanya Ethereum iwe iliyounganishwa zaidi. [](https://ethereum.org/sw/developers/docs/standards/tokens/#prerequisites) Mahitaji ya awali --------------------------------------------------------------------------------------------- * [Viwango vya maendeleo vya Ethereum](https://ethereum.org/sw/developers/docs/standards/) * [Mikataba mahiri](https://ethereum.org/sw/developers/docs/smart-contracts/) [](https://ethereum.org/sw/developers/docs/standards/tokens/#token-standards) Viwango vya tokeni ------------------------------------------------------------------------------------------------ Hapa kuna baadhi ya viwango maarufu vya tokeni kwenye Ethereum: * [ERC-20](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/) - Kiolesura cha kawaida cha tokeni zinazoweza kubadilishwa (fungible), kama vile tokeni za kura, tokeni za uwekaji dhamana au sarafu za mtandaoni. ### [](https://ethereum.org/sw/developers/docs/standards/tokens/#nft-standards) Viwango vya NFT * [ERC-721](https://ethereum.org/sw/developers/docs/standards/tokens/erc-721/) - Kiolesura cha kawaida cha tokeni zisizoweza kubadilishwa (non-fungible), kama vile hati ya kazi ya sanaa au wimbo. * [ERC-1155](https://ethereum.org/sw/developers/docs/standards/tokens/erc-1155/) - ERC-1155 inaruhusu biashara zenye ufanisi zaidi na kuunganisha miamala pamoja – hivyo kuokoa gharama. Kiwango hiki cha tokeni kinaruhusu kuunda tokeni za matumizi (kama vile $BNB au $BAT) na Tokeni Zisizoweza Kubadilishwa kama CryptoPunks. Orodha kamili ya mapendekezo ya [ERC (inafunguka katika kichupo kipya)](https://eips.ethereum.org/erc) . Usomaji zaidi ------------- _Je, unajua rasilimali ya jamii iliyokusaidia? Hariri ukurasa huu na uiongeze!_ * [Orodha ya Ukaguzi ya Ujumuishaji wa Tokeni (inafunguka katika kichupo kipya)](https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/token_integration.md) - _Trail of Bits_ * [Nyaraka za OpenZeppelin: Tokeni (inafunguka katika kichupo kipya)](https://docs.openzeppelin.com/contracts/5.x/tokens) - _OpenZeppelin_ * [Hatari za Ujumuishaji wa Tokeni (PDF) (inafunguka katika kichupo kipya)](https://github.com/OpenZeppelin/workshops/blob/master/11-dangers-token-integration/slides.pdf) - _OpenZeppelin_ [](https://ethereum.org/sw/developers/docs/standards/tokens/#related-tutorials) Mafunzo yanayohusiana ----------------------------------------------------------------------------------------------------- * [Orodha ya ukaguzi ya ujumuishaji wa tokeni](https://ethereum.org/sw/developers/tutorials/token-integration-checklist/) _– Orodha ya ukaguzi ya mambo ya kuzingatia wakati wa kuingiliana na tokeni._ * [Kuelewa mkataba mahiri wa tokeni ya ERC20](https://ethereum.org/sw/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– Utangulizi wa kusambaza mkataba wako mahiri wa kwanza kwenye mtandao wa majaribio wa Ethereum._ * [Uhamishaji na idhini ya tokeni za ERC20 kutoka kwenye mkataba mahiri wa Solidity](https://ethereum.org/sw/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– Jinsi ya kutumia mkataba mahiri kuingiliana na tokeni kwa kutumia lugha ya Solidity._ * [Kutekeleza soko la ERC721 \[mwongozo wa jinsi ya kufanya\]](https://ethereum.org/sw/developers/tutorials/how-to-implement-an-erc721-market/) _– Jinsi ya kuweka bidhaa zilizofanywa kuwa tokeni kwa ajili ya kuuzwa kwenye ubao wa matangazo uliogatuliwa._ --- # 프로그래밍 언어 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/programming-languages/#main-content) Change page 프로그래밍 언어 ======== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/index.md) 이 페이지의 내용 개발자가 이더리움 기반으로 개발하려면 반드시 [스마트 컨트랙트](https://ethereum.org/ko/developers/docs/smart-contracts/) 를 작성해야 한다는 것은 흔한 오해입니다. 이는 사실이 아닙니다. 이더리움 네트워크와 커뮤니티의 장점 중 하나는 거의 모든 프로그래밍 언어로 [참여](https://ethereum.org/ko/community/) 할 수 있다는 것입니다. 이더리움과 그 커뮤니티는 오픈 소스를 지향합니다. 클라이언트 구현체, API, 개발 프레임워크, 테스트 도구 등 다양한 언어로 작성된 커뮤니티 프로젝트를 찾을 수 있습니다. [](https://ethereum.org/ko/developers/docs/programming-languages/#data) 언어 선택 ----------------------------------------------------------------------------- 선호하는 프로그래밍 언어를 선택하여 프로젝트, 리소스 및 가상 커뮤니티를 찾아보세요. * [Dart 개발자를 위한 이더리움](https://ethereum.org/ko/developers/docs/programming-languages/dart/) * [Delphi 개발자를 위한 이더리움](https://ethereum.org/ko/developers/docs/programming-languages/delphi/) * [.NET 개발자를 위한 이더리움](https://ethereum.org/ko/developers/docs/programming-languages/dot-net/) * [Elixir 개발자를 위한 이더리움](https://ethereum.org/ko/developers/docs/programming-languages/elixir/) * [Go 개발자를 위한 이더리움](https://ethereum.org/ko/developers/docs/programming-languages/golang/) * [Java 개발자를 위한 이더리움](https://ethereum.org/ko/developers/docs/programming-languages/java/) * [JavaScript 개발자를 위한 이더리움](https://ethereum.org/ko/developers/docs/programming-languages/javascript/) * [Python 개발자를 위한 이더리움](https://ethereum.org/ko/developers/docs/programming-languages/python/) * [Ruby 개발자를 위한 이더리움](https://ethereum.org/ko/developers/docs/programming-languages/ruby/) * [Rust 개발자를 위한 이더리움](https://ethereum.org/ko/developers/docs/programming-languages/rust/) ### [](https://ethereum.org/ko/developers/docs/programming-languages/#other-lang) 내 언어가 지원되지 않는다면 추가 프로그래밍 언어에 대한 리소스를 연결하거나 가상 커뮤니티를 소개하고 싶다면 [이슈를 열어 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/issues/new/choose) 새 페이지를 요청할 수 있습니다. 현재 지원되지 않는 언어를 사용하여 블록체인과 상호 작용하는 코드를 작성하고 싶다면 [JSON-RPC 인터페이스](https://ethereum.org/ko/developers/docs/apis/json-rpc/) 를 사용하여 이더리움 네트워크에 연결할 수 있습니다. TCP/IP를 사용할 수 있는 모든 프로그래밍 언어는 이 인터페이스를 사용할 수 있습니다. --- # Ethereum kwa Wasanidi wa Elixir | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/programming-languages/elixir/#main-content) Change page Ethereum kwa Wasanidi wa Elixir =============================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/elixir/index.md) Kwenye ukurasa huu Jifunze jinsi ya kusanidi kwa ajili ya Ethereum ukitumia miradi na zana zinazotegemea Elixir. Tumia Ethereum kuunda programu tumizi zilizogatuliwa (au "dapps") zinazotumia manufaa ya sarafu-fiche na teknolojia ya mnyororo wa vitalu. Dapps hizi zinaweza kuwa bila hitaji la uaminifu, ikimaanisha kwamba zikishasambazwa kwenye Ethereum, zitaendelea kufanya kazi kama zilivyopangwa. Zinaweza kudhibiti rasilimali za kidijitali ili kuunda aina mpya za programu tumizi za kifedha. Zinaweza kuwa zilizogatuliwa, ikimaanisha kwamba hakuna shirika au mtu mmoja anayezidhibiti na ni karibu haiwezekani kuzidhibiti. [](https://ethereum.org/sw/developers/docs/programming-languages/elixir/#getting-started-with-smart-contracts-and-solidity) Kuanza na mikataba mahiri na lugha ya Solidity -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- **Chukua hatua zako za kwanza za kuunganisha Elixir na Ethereum** Je, unahitaji mwongozo wa kimsingi zaidi kwanza? Angalia [ethereum.org/learn](https://ethereum.org/sw/learn/) au [ethereum.org/developers](https://ethereum.org/sw/developers/) . * [Mnyororo wa Vitalu Umefafanuliwa (inafunguka katika kichupo kipya)](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [Kuelewa Mikataba Mahiri (inafunguka katika kichupo kipya)](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [Andika Mkataba wako Mahiri wa Kwanza (inafunguka katika kichupo kipya)](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Jifunze Jinsi ya Kukusanya na Kusambaza Solidity (inafunguka katika kichupo kipya)](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) [](https://ethereum.org/sw/developers/docs/programming-languages/elixir/#beginner-articles) Makala za wanaoanza --------------------------------------------------------------------------------------------------------------- * [Hatimaye kuelewa akaunti za Ethereum (inafunguka katika kichupo kipya)](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) * [Ethers — Maktaba ya daraja la kwanza ya Web3 ya Ethereum kwa ajili ya Elixir (inafunguka katika kichupo kipya)](https://medium.com/@alisinabh/announcing-ethers-a-first-class-ethereum-web3-library-for-elixir-1d64e9409122) [](https://ethereum.org/sw/developers/docs/programming-languages/elixir/#intermediate-articles) Makala za kiwango cha kati -------------------------------------------------------------------------------------------------------------------------- * [Jinsi ya kutia saini miamala ghafi ya mkataba wa Ethereum ukitumia Elixir (inafunguka katika kichupo kipya)](https://kohlerjp.medium.com/how-to-sign-raw-ethereum-contract-transactions-with-elixir-f8822bcc813b) * [Mikataba Mahiri ya Ethereum na Elixir (inafunguka katika kichupo kipya)](https://medium.com/agile-alpha/ethereum-smart-contracts-and-elixir-c7c4b239ddb4) [](https://ethereum.org/sw/developers/docs/programming-languages/elixir/#elixir-projects-and-tools) Miradi na zana za Elixir ---------------------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/sw/developers/docs/programming-languages/elixir/#active) Inayotumika * [block\_keys (inafunguka katika kichupo kipya)](https://github.com/ExWeb3/block_keys) - _Utekelezaji wa BIP32 & BIP44 katika Elixir (Utawala wa Akaunti Nyingi kwa Pochi za Kiuhakika)_ * [ethereumex (inafunguka katika kichupo kipya)](https://github.com/mana-ethereum/ethereumex) - _Mteja wa JSON-RPC wa Elixir kwa ajili ya mnyororo wa vitalu wa Ethereum_ * [ethers (inafunguka katika kichupo kipya)](https://github.com/ExWeb3/elixir_ethers) - _Maktaba ya kina ya Web3 ya kuingiliana na mikataba mahiri kwenye Ethereum kwa kutumia Elixir_ * [ethers\_kms (inafunguka katika kichupo kipya)](https://github.com/ExWeb3/elixir_ethers_kms) - _Maktaba ya kutia saini ya KMS kwa ajili ya Ethers (tia saini miamala ukitumia AWS KMS)_ * [ex\_abi (inafunguka katika kichupo kipya)](https://github.com/poanetwork/ex_abi) - _Utekelezaji wa kichanganuzi/kisimbuzi/kisimbaji cha ABI cha Ethereum katika Elixir_ * [ex\_keccak (inafunguka katika kichupo kipya)](https://github.com/ExWeb3/ex_keccak) - _Maktaba ya Elixir ya kukokotoa heshi za Keccak SHA3-256 kwa kutumia kreti ya Rust ya tiny-keccak iliyojengwa na NIF_ * [ex\_rlp (inafunguka katika kichupo kipya)](https://github.com/mana-ethereum/ex_rlp) - _Utekelezaji wa Elixir wa usimbaji wa RLP (Recursive Length Prefix) wa Ethereum_ ### [](https://ethereum.org/sw/developers/docs/programming-languages/elixir/#archived--no-longer-maintained) Iliyohifadhiwa / Haidhibitiwi tena * [eth (inafunguka katika kichupo kipya)](https://hex.pm/packages/eth) - _Huduma za Ethereum kwa ajili ya Elixir_ * [exw3 (inafunguka katika kichupo kipya)](https://github.com/hswick/exw3) - _Mteja wa RPC wa Ethereum wa kiwango cha juu kwa ajili ya Elixir_ * [mana (inafunguka katika kichupo kipya)](https://github.com/mana-ethereum/mana) - _Utekelezaji wa nodi kamili ya Ethereum ulioandikwa katika Elixir_ Je, unatafuta rasilimali zaidi? Angalia [ukurasa wetu wa nyumbani wa Wasanidi](https://ethereum.org/sw/developers/) . [](https://ethereum.org/sw/developers/docs/programming-languages/elixir/#elixir-community-contributors) Wachangiaji wa jumuiya ya Elixir ---------------------------------------------------------------------------------------------------------------------------------------- [Chaneli ya #ethereum ya Slack ya Elixir (inafunguka katika kichupo kipya)](https://elixir-lang.slack.com/archives/C5RPZ3RJL) ni mwenyeji wa jumuiya inayokua kwa kasi na ni rasilimali maalum kwa ajili ya majadiliano kuhusu mradi wowote kati ya iliyo hapo juu na mada zinazohusiana. --- # Ethereum kwa wasanidi wa JavaScript | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/programming-languages/javascript/#main-content) Change page Ethereum kwa wasanidi wa JavaScript =================================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/javascript/index.md) Kwenye ukurasa huu JavaScript ni miongoni mwa lugha maarufu zaidi katika mfumo wa ikolojia wa Ethereum. Kwa kweli, kuna [timu (inafunguka katika kichupo kipya)](https://github.com/ethereumjs) iliyojitolea kuleta kiasi kikubwa cha Ethereum kwenye JavaScript iwezekanavyo. Kuna fursa za kuandika JavaScript (au kitu kinachokaribiana nayo) katika [viwango vyote vya steki](https://ethereum.org/sw/developers/docs/ethereum-stack/) . [](https://ethereum.org/sw/developers/docs/programming-languages/javascript/#interact-with-ethereum) Kuingiliana na Ethereum ---------------------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/sw/developers/docs/programming-languages/javascript/#javascript-api-libraries) Maktaba za API za JavaScript Ikiwa ungependa kuandika JavaScript ili kuuliza mnyororo wa vitalu, kutuma miamala na zaidi, njia rahisi zaidi ya kufanya hivi ni kutumia [maktaba ya API ya JavaScript](https://ethereum.org/sw/developers/docs/apis/javascript/) . API hizi huruhusu wasanidi kuingiliana kwa urahisi na [nodi katika mtandao wa Ethereum](https://ethereum.org/sw/developers/docs/nodes-and-clients/) . Unaweza kutumia maktaba hizi kuingiliana na mikataba mahiri kwenye Ethereum kwa hivyo inawezekana kuunda programu tumizi iliyogatuliwa (dapp) ambapo unatumia tu JavaScript kuingiliana na mikataba iliyopo tayari. **Angalia** * [Web3.js (inafunguka katika kichupo kipya)](https://web3js.readthedocs.io/) * [Ethers.js (inafunguka katika kichupo kipya)](https://ethers.org/) – _inajumuisha utekelezaji wa mkoba wa Ethereum na huduma katika JavaScript na TypeScript._ * [viem (inafunguka katika kichupo kipya)](https://viem.sh/) – _Kiolesura cha TypeScript cha Ethereum ambacho hutoa misingi ya kiwango cha chini isiyo na hali ya kuingiliana na Ethereum._ * [Drift (inafunguka katika kichupo kipya)](https://ryangoree.github.io/drift/) – _maktaba kuu ya TypeScript yenye uwekaji akiba uliojengewa ndani, ndoano, na majaribio ya kuiga kwa usanidi rahisi wa Ethereum kwenye maktaba za Web3._ ### [](https://ethereum.org/sw/developers/docs/programming-languages/javascript/#smart-contracts) Mikataba mahiri Ikiwa wewe ni msanidi wa JavaScript na unataka kuandika mkataba mahiri wako mwenyewe, unaweza kutaka kufahamiana na [Solidity (inafunguka katika kichupo kipya)](https://solidity.readthedocs.io/) . Hii ndiyo lugha maarufu zaidi ya mkataba mahiri na inafanana kimuundo na JavaScript, jambo ambalo linaweza kuifanya iwe rahisi kujifunza. Zaidi kuhusu [mikataba mahiri](https://ethereum.org/sw/developers/docs/smart-contracts/) . [](https://ethereum.org/sw/developers/docs/programming-languages/javascript/#understand-the-protocol) Kuelewa itifaki --------------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/sw/developers/docs/programming-languages/javascript/#the-ethereum-virtual-machine) Mashine pepe ya Ethereum Kuna utekelezaji wa JavaScript wa [mashine pepe ya Ethereum](https://ethereum.org/sw/developers/docs/evm/) . Inasaidia sheria za hivi punde za mchepuo. Sheria za mchepuo hurejelea mabadiliko yaliyofanywa kwenye EVM kutokana na masasisho yaliyopangwa. Imegawanywa katika vifurushi mbalimbali vya JavaScript ambavyo unaweza kuviangalia ili kuelewa vyema: * Akaunti * Vitalu * Mnyororo wa vitalu wenyewe * Miamala * Na zaidi... Hii itakusaidia kuelewa mambo kama "muundo wa data wa akaunti ni upi?". Ikiwa unapendelea kusoma msimbo, JavaScript hii inaweza kuwa mbadala mzuri wa kusoma kupitia hati zetu. **Angalia EVM** [`@ethereumjs/evm` (inafunguka katika kichupo kipya)](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm) ### [](https://ethereum.org/sw/developers/docs/programming-languages/javascript/#nodes-and-clients) Nodi na wateja Mteja wa EthereumJS yuko katika usanidi unaoendelea ambao unakuruhusu kuchunguza jinsi wateja wa Ethereum wanavyofanya kazi katika lugha unayoielewa; JavaScript! **Angalia mteja** [`@ethereumjs/client` (inafunguka katika kichupo kipya)](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client) [](https://ethereum.org/sw/developers/docs/programming-languages/javascript/#other-projects) Miradi mingine ----------------------------------------------------------------------------------------------------------- Pia kuna mambo mengine mengi yanayoendelea katika ulimwengu wa JavaScript ya Ethereum, ikiwa ni pamoja na: * maktaba za huduma za mkoba. * zana za kuzalisha, kuingiza, na kuhamisha funguo za Ethereum. * utekelezaji wa `merkle-patricia-tree` – muundo wa data ulioainishwa katika waraka wa manjano wa Ethereum. Chunguza chochote kinachokuvutia zaidi kwenye [hifadhi ya EthereumJS (inafunguka katika kichupo kipya)](https://github.com/ethereumjs) [](https://ethereum.org/sw/developers/docs/programming-languages/javascript/#further-reading) Kusoma zaidi ---------------------------------------------------------------------------------------------------------- _Unajua rasilimali ya jamii iliyokusaidia? Hariri ukurasa huu na uiongeze!_ --- # 인출 자격 증명 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/#main-content) Change page 인출 자격 증명 ======== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md) 이 페이지의 내용 모든 검증자는 스테이킹된 ETH와 보상을 어떻게, 어디로 인출할지 결정하는 **인출 자격 증명**을 가지고 있습니다. 자격 증명 유형은 첫 번째 바이트인 `0x00`, `0x01` 또는 `0x02`로 표시됩니다. 스테이크를 관리하는 검증자에게 이러한 유형을 이해하는 것은 중요합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/#0x00-credentials) 0x00: 샤펠라 이전 자격 증명 -------------------------------------------------------------------------------------------------------------------------------- `0x00` 유형은 샤펠라 업그레이드(2023년 4월) 이전의 원래 인출 자격 증명 형식입니다. 이 자격 증명 유형을 가진 검증자는 실행 계층 인출 주소가 설정되어 있지 않으므로, 자금이 합의 레이어에 잠겨 있습니다. 여전히 `0x00` 자격 증명을 가지고 있다면, 인출을 받기 전에 `0x01` 또는 `0x02`로 업그레이드해야 합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/#0x01-credentials) 0x01: 레거시 인출 자격 증명 -------------------------------------------------------------------------------------------------------------------------------- `0x01` 유형은 샤펠라 업그레이드와 함께 도입되었으며, 실행 계층 인출 주소를 설정하려는 검증자의 표준이 되었습니다. `0x01` 자격 증명의 특징은 다음과 같습니다: * 32 ETH를 초과하는 잔고는 인출 주소로 **자동으로 스윕(sweep)**됩니다. * 전체 종료는 표준 종료 대기열을 거칩니다. * 32 ETH를 초과하는 보상은 복리로 적용될 수 없으며, 주기적으로 스윕되어 빠져나갑니다. **일부 검증자가 여전히 0x01을 사용하는 이유:** 더 간단하고 익숙하기 때문입니다. 많은 검증자가 샤펠라 이후에 예치하여 이미 이 유형을 가지고 있으며, 초과 잔고의 자동 인출을 원하는 사람들에게는 잘 작동합니다. **권장하지 않는 이유:** `0x01`을 사용하면 32 ETH를 초과하는 보상을 복리로 적용할 수 있는 기능을 잃게 됩니다. 초과분은 모두 자동으로 스윕되므로 검증자의 수익 잠재력이 제한되고 인출된 자금을 별도로 관리해야 합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/#0x02-credentials) 0x02: 복리 인출 자격 증명 ------------------------------------------------------------------------------------------------------------------------------- `0x02` 유형은 펙트라 업그레이드와 함께 도입되었으며, 오늘날 검증자에게 **권장되는 선택**입니다. `0x02` 자격 증명을 가진 검증자는 때때로 "복리 검증자(compounding validators)"라고 불립니다. `0x02` 자격 증명의 특징은 다음과 같습니다: * 32 ETH를 초과하는 보상은 최대 유효 잔고인 2048 ETH까지 1 ETH 단위로 **복리 적용**됩니다. * 부분 인출은 수동으로 요청해야 합니다(자동 스윕은 2048 ETH 임계값을 초과할 때만 발생합니다). * 검증자는 여러 개의 32 ETH 검증자를 더 높은 잔고를 가진 단일 검증자로 통합할 수 있습니다. * 전체 종료는 여전히 표준 종료 대기열을 통해 지원됩니다. 부분 인출과 통합은 모두 [런치패드 검증자 작업(Launchpad Validator Actions) (새 탭에서 열림)](https://launchpad.ethereum.org/en/validator-actions) 을 통해 수행할 수 있습니다. **검증자가 0x02를 선호해야 하는 이유:** 복리를 통해 더 나은 자본 효율성을 제공하고, 인출 시기에 대한 더 많은 제어권을 가지며, 검증자 통합을 지원합니다. 시간이 지남에 따라 보상을 축적하는 솔로 스테이커의 경우, 이는 수동 개입 없이도 유효 잔고와 보상이 32 ETH를 넘어 성장할 수 있음을 의미합니다. **중요:** `0x01`에서 `0x02`로 변환한 후에는 되돌리기를 할 수 없습니다. 유형 2 자격 증명으로의 변환 및 MaxEB 기능에 대한 자세한 가이드는 [MaxEB 설명 페이지](https://ethereum.org/ko/roadmap/pectra/maxeb/) 를 참조하세요. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/#what-should-i-pick) 무엇을 선택해야 할까요? ----------------------------------------------------------------------------------------------------------------------------- * **새로운 검증자:** `0x02`를 선택하세요. 더 나은 복리와 유연성을 갖춘 최신 표준입니다. * **기존 0x01 검증자:** 32 ETH를 초과하는 보상에 복리를 적용하고 싶거나 검증자를 통합할 계획이라면 `0x02`로 변환하는 것을 고려해 보세요. * **기존 0x00 검증자:** 즉시 업그레이드하세요. 자격 증명을 업데이트하지 않으면 인출할 수 없습니다. 먼저 `0x01`로 변환한 다음, `0x02`로 변환할 수 있습니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/#withdrawal-credential-tools) 인출 자격 증명 관리 도구 --------------------------------------------------------------------------------------------------------------------------------------- 여러 도구에서 자격 증명 유형을 선택하거나 변환하는 기능을 지원합니다: * **[이더리움 스테이킹 런치패드(Ethereum Staking Launchpad) (새 탭에서 열림)](https://launchpad.ethereum.org/en/validator-actions) ** - 자격 증명 변환 및 통합을 포함한 예치 및 검증자 관리를 위한 공식 도구입니다. * **[펙트라 스테이킹 매니저(Pectra Staking Manager) (새 탭에서 열림)](https://pectrastaking.com/) ** - 변환 및 통합을 위한 지갑 연결을 지원하는 웹 UI입니다. * **[펙트라 검증자 운영 CLI 도구(Pectra Validator Ops CLI Tool) (새 탭에서 열림)](https://github.com/Luganodes/Pectra-Batch-Contract) ** - 일괄 변환을 위한 명령줄 도구입니다. * **[Ethereal (새 탭에서 열림)](https://github.com/wealdtech/ethereal) ** - 검증자 관리를 포함한 이더리움 작업을 위한 CLI 도구입니다. 통합 도구의 전체 목록과 자세한 변환 지침은 [MaxEB 통합 도구](https://ethereum.org/ko/roadmap/pectra/maxeb/#consolidation-tooling) 를 참조하세요. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/#further-reading) 더 읽어보기 ------------------------------------------------------------------------------------------------------------------- * [지분 증명(PoS) 이더리움의 키](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/keys/) - 검증자 키와 인출 자격 증명과의 관계에 대해 알아보세요. * [MaxEB](https://ethereum.org/ko/roadmap/pectra/maxeb/) - 펙트라 업그레이드 및 최대 유효 잔고 기능에 대한 자세한 가이드입니다. --- # 이더리움 부트노드 소개 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/nodes-and-clients/bootnodes/#main-content) Change page 이더리움 부트노드 소개 ============ .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/nodes-and-clients/bootnodes/index.md) 이 페이지의 내용 새로운 노드가 이더리움 네트워크에 참여할 때, 새로운 피어를 발견하기 위해 이미 네트워크에 있는 노드에 연결해야 합니다. 이더리움 네트워크로 들어가는 이러한 진입점을 부트노드라고 합니다. 클라이언트에는 일반적으로 부트노드 목록이 하드코딩되어 있습니다. 이러한 부트노드는 일반적으로 이더리움 재단의 데브옵스(devops) 팀이나 클라이언트 팀 자체에서 운영합니다. 부트노드는 정적 노드(static node)와 같지 않다는 점에 유의하세요. 정적 노드는 반복해서 호출되는 반면, 부트노드는 연결할 피어가 충분하지 않고 노드가 새로운 연결을 부트스트랩해야 할 때만 호출됩니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/bootnodes/#connect-to-a-bootnode) 부트노드에 연결하기 --------------------------------------------------------------------------------------------------------- 대부분의 클라이언트에는 부트노드 목록이 내장되어 있지만, 자체 부트노드를 실행하거나 클라이언트의 하드코딩된 목록에 없는 부트노드를 사용하고 싶을 수도 있습니다. 이 경우 다음과 같이 클라이언트를 시작할 때 이를 지정할 수 있습니다(예시는 Geth용이며, 해당 클라이언트의 문서를 확인하세요). geth --bootnodes "enode://@:" 복사 [](https://ethereum.org/ko/developers/docs/nodes-and-clients/bootnodes/#run-a-bootnode) 부트노드 실행하기 ------------------------------------------------------------------------------------------------- 부트노드는 NAT([네트워크 주소 변환(Network Address Translation) (새 탭에서 열림)](https://www.geeksforgeeks.org/network-address-translation-nat/) ) 뒤에 있지 않은 풀 노드입니다. 모든 풀 노드는 공개적으로 접근할 수 있는 한 부트노드 역할을 할 수 있습니다. 노드를 시작할 때 [enode](https://ethereum.org/ko/developers/docs/networking-layer/network-addresses/#enode) 를 로그에 기록해야 합니다. 이는 다른 사람들이 여러분의 노드에 연결하는 데 사용할 수 있는 공개 식별자입니다. enode는 일반적으로 다시 시작할 때마다 재생성되므로, 부트노드에 대한 영구적인 enode를 생성하는 방법은 클라이언트 문서를 확인하시기 바랍니다. 좋은 부트노드가 되려면 연결할 수 있는 최대 피어 수를 늘리는 것이 좋습니다. 많은 피어와 함께 부트노드를 실행하면 대역폭 요구 사항이 크게 증가합니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/bootnodes/#available-bootnodes) 사용 가능한 부트노드 -------------------------------------------------------------------------------------------------------- go-ethereum 내에 내장된 부트노드 목록은 [여기 (새 탭에서 열림)](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23) 에서 찾을 수 있습니다. 이러한 부트노드는 이더리움 재단과 go-ethereum 팀에서 유지 관리합니다. 자원봉사자가 유지 관리하는 다른 부트노드 목록도 사용할 수 있습니다. 항상 하나 이상의 공식 부트노드를 포함해야 합니다. 그렇지 않으면 이클립스 공격(eclipse attack)을 받을 수 있습니다. --- # Mitandao ya Maendeleo | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/development-networks/#main-content) Change page Mitandao ya Maendeleo ===================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/development-networks/index.md) Kwenye ukurasa huu Unapojenga programu ya [Ethereum](https://ethereum.org/sw/) yenye mikataba mahiri, utataka kuiendesha kwenye mtandao wa ndani ili kuona jinsi inavyofanya kazi kabla ya kuisambaza. Sawa na jinsi unavyoweza kuendesha seva ya ndani kwenye kompyuta yako kwa maendeleo ya wavuti, unaweza kutumia mtandao wa maendeleo kuunda mfano wa mnyororo wa vitalu wa ndani ili kujaribu programu tumizi iliyogatuliwa (dapp) yako. Mitandao hii ya maendeleo ya Ethereum hutoa vipengele vinavyoruhusu urudiaji wa haraka zaidi kuliko mtandao wa majaribio wa umma (kwa mfano huhitaji kushughulika na kupata ETH kutoka kwenye bomba la mtandao wa majaribio). [](https://ethereum.org/sw/developers/docs/development-networks/#prerequisites) Mahitaji ya awali ------------------------------------------------------------------------------------------------- Unapaswa kuelewa [misingi ya steki ya Ethereum](https://ethereum.org/sw/developers/docs/ethereum-stack/) na [mitandao ya Ethereum](https://ethereum.org/sw/developers/docs/networks/) kabla ya kuzama kwenye mitandao ya maendeleo. [](https://ethereum.org/sw/developers/docs/development-networks/#what-is-a-development-network) Mtandao wa maendeleo ni nini? ----------------------------------------------------------------------------------------------------------------------------- Mitandao ya maendeleo kimsingi ni wateja wa Ethereum (utekelezaji wa Ethereum) iliyoundwa mahususi kwa maendeleo ya ndani. **Kwa nini usiendeshaji tu nodi ya kawaida ya Ethereum ndani?** _Unaweza_ [kuendesha nodi](https://ethereum.org/sw/developers/docs/nodes-and-clients/#running-your-own-node) lakini kwa kuwa mitandao ya maendeleo imejengwa kwa madhumuni ya maendeleo, mara nyingi huja na vipengele vinavyofaa kama vile: * Kupanda data kwa uhakika kwenye mnyororo wa vitalu wako wa ndani (k.m., akaunti zenye salio la ETH) * Kuzalisha vitalu papo hapo kwa kila muamala inaopokea, kwa mpangilio na bila kuchelewa * Utendaji ulioboreshwa wa utatuzi na uwekaji kumbukumbu [](https://ethereum.org/sw/developers/docs/development-networks/#available-projects) Zana zinazopatikana -------------------------------------------------------------------------------------------------------- **Kumbuka**: [Mifumo mingi ya maendeleo](https://ethereum.org/sw/developers/docs/frameworks/) inajumuisha mtandao wa maendeleo uliojengewa ndani. Tunapendekeza kuanza na mfumo ili [kuweka mazingira yako ya maendeleo ya ndani](https://ethereum.org/sw/developers/local-environment/) . ### [](https://ethereum.org/sw/developers/docs/development-networks/#hardhat-network) Mtandao wa Hardhat Mtandao wa ndani wa Ethereum ulioundwa kwa ajili ya maendeleo. Inakuruhusu kusambaza mikataba yako, kuendesha majaribio yako na kutatua msimbo wako. Mtandao wa Hardhat unakuja umejengewa ndani na Hardhat, mazingira ya maendeleo ya Ethereum kwa wataalamu. * [Tovuti (inafunguka katika kichupo kipya)](https://hardhat.org/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/NomicFoundation/hardhat) ### [](https://ethereum.org/sw/developers/docs/development-networks/#local-beacon-chains) Minyororo ya Beacon ya Ndani Baadhi ya wateja wa mwafaka wana zana zilizojengewa ndani za kuanzisha minyororo ya beacon ya ndani kwa madhumuni ya majaribio. Maagizo ya Lighthouse, Nimbus na Lodestar yanapatikana: * [Mtandao wa majaribio wa ndani kwa kutumia Lodestar (inafunguka katika kichupo kipya)](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/) * [Mtandao wa majaribio wa ndani kwa kutumia Lighthouse (inafunguka katika kichupo kipya)](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets) ### [](https://ethereum.org/sw/developers/docs/development-networks/#public-beacon-testchains) Minyororo ya Majaribio ya Umma ya Ethereum Pia kuna utekelezaji miwili ya majaribio ya umma ya Ethereum inayodumishwa: Sepolia na Hoodi. Mtandao wa majaribio unaopendekezwa wenye usaidizi wa muda mrefu ni Hoodi, ambao mtu yeyote yuko huru kuthibitisha. Sepolia inatumia seti ya mthibitishaji yenye ruhusa, ikimaanisha hakuna ufikiaji wa jumla kwa wathibitishaji wapya kwenye mtandao huu wa majaribio. * [Jukwaa la Uzinduzi la Uwekaji Dhamana la Hoodi (inafunguka katika kichupo kipya)](https://hoodi.launchpad.ethereum.org/) ### [](https://ethereum.org/sw/developers/docs/development-networks/#kurtosis) Kifurushi cha Ethereum cha Kurtosis Kurtosis ni mfumo wa ujenzi wa mazingira ya majaribio ya kontena nyingi ambao huwawezesha wasanidi programu kuanzisha ndani mifano inayoweza kuzalishwa tena ya mitandao ya mnyororo wa vitalu. Kifurushi cha Kurtosis cha Ethereum kinaweza kutumika kuanzisha haraka mtandao wa majaribio wa Ethereum unaoweza kuwekewa vigezo, unaoweza kupanuka sana, na wa faragha kupitia Docker au Kubernetes. Kifurushi hiki kinaauni wateja wote wakuu wa Tabaka la Utekelezaji (EL) na Tabaka la Mwafaka (CL). Kurtosis inashughulikia kwa ustadi uchoraji wote wa bandari za ndani na miunganisho ya huduma kwa mtandao wakilishi utakaotumika katika uthibitishaji na mtiririko wa kazi wa majaribio unaohusiana na miundombinu ya msingi ya Ethereum. * [Kifurushi cha mtandao wa Ethereum (inafunguka katika kichupo kipya)](https://github.com/kurtosis-tech/ethereum-package) * [Tovuti (inafunguka katika kichupo kipya)](https://www.kurtosis.com/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/kurtosis-tech/kurtosis) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.kurtosis.com/) [](https://ethereum.org/sw/developers/docs/development-networks/#further-reading) Usomaji zaidi ----------------------------------------------------------------------------------------------- _Unajua rasilimali ya jamii iliyokusaidia? Hariri ukurasa huu na uiongeze!_ [](https://ethereum.org/sw/developers/docs/development-networks/#related-topics) Mada zinazohusiana --------------------------------------------------------------------------------------------------- * [Mifumo ya maendeleo](https://ethereum.org/sw/developers/docs/frameworks/) * [Weka mazingira ya maendeleo ya ndani](https://ethereum.org/sw/developers/local-environment/) [](https://ethereum.org/sw/developers/docs/development-networks/#tutorials) Mafunzo: Mitandao ya maendeleo na mazingira ya majaribio kwenye Ethereum ---------------------------------------------------------------------------------------------------------------------------------------------------- * [Tengeneza na ujaribu programu tumizi zilizogatuliwa (dapps) ukitumia mtandao wa majaribio wa ndani wa Ethereum wa wateja wengi](https://ethereum.org/sw/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/) _– Jinsi ya kuanzisha mtandao wa majaribio wa ndani wa Ethereum wa wateja wengi ukitumia Kurtosis kwa maendeleo na majaribio ya dapp._ --- # Nodi ya Kumbukumbu ya Ethereum | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/nodes-and-clients/archive-nodes/#main-content) Change page Nodi ya Kumbukumbu ya Ethereum ============================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/nodes-and-clients/archive-nodes/index.md) Kwenye ukurasa huu Nodi ya kumbukumbu ni mfano wa mteja wa [Ethereum](https://ethereum.org/sw/) aliyesanidiwa kujenga kumbukumbu ya hali zote za kihistoria. Ni zana muhimu kwa matumizi fulani lakini inaweza kuwa ngumu zaidi kuiendesha kuliko nodi kamili. [](https://ethereum.org/sw/developers/docs/nodes-and-clients/archive-nodes/#prerequisites) Mahitaji ya awali ------------------------------------------------------------------------------------------------------------ Unapaswa kuelewa dhana ya [nodi ya Ethereum](https://ethereum.org/sw/developers/docs/nodes-and-clients/) , [usanifu wake](https://ethereum.org/sw/developers/docs/nodes-and-clients/node-architecture/) , [mikakati ya usawazishaji](https://ethereum.org/sw/developers/docs/nodes-and-clients/#sync-modes) , mbinu za [kuziendesha](https://ethereum.org/sw/developers/docs/nodes-and-clients/run-a-node/) na [kuzitumia](https://ethereum.org/sw/developers/docs/apis/json-rpc/) . [](https://ethereum.org/sw/developers/docs/nodes-and-clients/archive-nodes/#what-is-an-archive-node) Nodi ya kumbukumbu ni nini ------------------------------------------------------------------------------------------------------------------------------- Ili kuelewa umuhimu wa nodi ya kumbukumbu, hebu tufafanue dhana ya "hali." Ethereum inaweza kurejelewa kama _mashine ya hali inayotegemea miamala_. Inajumuisha akaunti na programu zinazotekeleza miamala ambayo inabadilisha hali zao. Data ya kimataifa yenye taarifa kuhusu kila akaunti na mkataba inahifadhiwa katika hifadhidata ya trie inayoitwa hali. Hili linashughulikiwa na mteja wa tabaka la utekelezaji (EL) na inajumuisha: * Salio la akaunti na nonces * Msimbo wa mkataba na hifadhi * Data inayohusiana na mwafaka, k.m., Mkataba wa Amana ya Uwekaji Dhamana Ili kuingiliana na mtandao, kuthibitisha na kuzalisha vitalu vipya, wateja wa Ethereum wanapaswa kuendana na mabadiliko ya hivi karibuni (ncha ya mnyororo) na hivyo hali ya sasa. Mteja wa tabaka la utekelezaji aliyesanidiwa kama nodi kamili huthibitisha na kufuata hali ya hivi karibuni ya mtandao lakini huhifadhi tu hali chache zilizopita, k.m., hali inayohusishwa na vitalu 128 vya mwisho, ili aweze kushughulikia upangaji upya wa mnyororo na kutoa ufikiaji wa haraka wa data ya hivi karibuni. Hali ya hivi karibuni ndiyo wateja wote wanahitaji ili kuthibitisha miamala inayoingia na kutumia mtandao. Unaweza kufikiria hali kama picha ya muda ya mtandao kwenye kitalu fulani na kumbukumbu kama marudio ya historia. Hali za kihistoria zinaweza kupunguzwa kwa usalama kwa sababu si lazima kwa mtandao kufanya kazi na itakuwa ni marudio yasiyo na maana kwa mteja kuweka data zote zilizopitwa na wakati. Hali zilizokuwepo kabla ya kitalu fulani cha hivi karibuni (k.m., vitalu 128 kabla ya kichwa) hutupwa mbali. Nodi kamili huweka tu data ya kihistoria ya mnyororo wa vitalu (vitalu na miamala) na picha za kihistoria za mara kwa mara wanazoweza kutumia kuzalisha upya hali za zamani wanapoomba. Wanafanya hivi kwa kutekeleza upya miamala iliyopita katika EVM, ambayo inaweza kuhitaji nguvu kubwa ya kompyuta wakati hali inayohitajika iko mbali na picha ya karibu zaidi. Hata hivyo, hii inamaanisha kuwa kufikia hali ya kihistoria kwenye nodi kamili hutumia nguvu nyingi za kompyuta. Mteja anaweza kuhitaji kutekeleza miamala yote iliyopita na kukokotoa hali moja ya kihistoria kutoka mwanzo (genesis). Nodi za kumbukumbu hutatua hili kwa kuhifadhi si tu hali za hivi karibuni bali kila hali ya kihistoria iliyoundwa baada ya kila kitalu. Kimsingi inafanya maelewano na hitaji kubwa la nafasi ya diski. Ni muhimu kutambua kwamba mtandao hautegemei nodi za kumbukumbu kuweka na kutoa data zote za kihistoria. Kama ilivyotajwa hapo juu, hali zote za mpito za kihistoria zinaweza kupatikana kwenye nodi kamili. Miamala inahifadhiwa na nodi yoyote kamili (kwa sasa chini ya 400G) na inaweza kurudiwa ili kujenga kumbukumbu nzima. ### [](https://ethereum.org/sw/developers/docs/nodes-and-clients/archive-nodes/#use-cases) Matumizi Matumizi ya kawaida ya Ethereum kama vile kutuma miamala, kusambaza mikataba, kuthibitisha mwafaka, n.k. hayahitaji ufikiaji wa hali za kihistoria. Watumiaji hawahitaji kamwe nodi ya kumbukumbu kwa mwingiliano wa kawaida na mtandao. Faida kuu ya kumbukumbu ya hali ni ufikiaji wa haraka wa maswali kuhusu hali za kihistoria. Kwa mfano, nodi ya kumbukumbu itarudisha matokeo mara moja kama vile: * _Salio la ETH la akaunti 0x1337... lilikuwa kiasi gani kwenye kitalu 15537393?_ * _Salio la tokeni 0x katika mkataba 0x ni kiasi gani kwenye kitalu 1920000?_ Kama ilivyoelezwa hapo juu, nodi kamili ingehitaji kuzalisha data hii kwa utekelezaji wa EVM ambao hutumia CPU na kuchukua muda. Nodi za kumbukumbu huzifikia kwenye diski na kutoa majibu mara moja. Hiki ni kipengele muhimu kwa sehemu fulani za miundombinu, kwa mfano: * Watoa huduma kama wachunguzi wa vitalu (block explorers) * Watafiti * Wachambuzi wa usalama * Wasanidi wa programu tumizi iliyogatuliwa (dapp) * Ukaguzi na uzingatiaji Kuna [huduma](https://ethereum.org/sw/developers/docs/nodes-and-clients/nodes-as-a-service/) mbalimbali za bure ambazo pia zinaruhusu ufikiaji wa data ya kihistoria. Kwa kuwa inahitaji nguvu zaidi kuendesha nodi ya kumbukumbu, ufikiaji huu mara nyingi una kikomo na hufanya kazi tu kwa ufikiaji wa mara kwa mara. Ikiwa mradi wako unahitaji ufikiaji wa mara kwa mara wa data ya kihistoria, unapaswa kufikiria kujiendeshea yako mwenyewe. [](https://ethereum.org/sw/developers/docs/nodes-and-clients/archive-nodes/#implementations-and-usage) Utekelezaji na matumizi ------------------------------------------------------------------------------------------------------------------------------ Nodi ya kumbukumbu katika muktadha huu inamaanisha data inayotolewa na wateja wa tabaka la utekelezaji wanaokabiliana na mtumiaji wanaposhughulikia hifadhidata ya hali na kutoa vituo vya mwisho vya JSON-RPC. Chaguzi za usanidi, muda wa usawazishaji na ukubwa wa hifadhidata zinaweza kutofautiana kulingana na mteja. Kwa maelezo, tafadhali rejelea nyaraka zilizotolewa na mteja wako. Kabla ya kuanzisha nodi yako ya kumbukumbu, jifunze kuhusu tofauti kati ya wateja na hasa [mahitaji mbalimbali ya maunzi](https://ethereum.org/sw/developers/docs/nodes-and-clients/run-a-node/#requirements) . Wateja wengi hawajaboreshwa kwa kipengele hiki na kumbukumbu zao zinahitaji zaidi ya 12TB ya nafasi. Kinyume chake, utekelezaji kama Erigon unaweza kuhifadhi data sawa katika chini ya 3TB ambayo inawafanya kuwa njia bora zaidi ya kuendesha nodi ya kumbukumbu. [](https://ethereum.org/sw/developers/docs/nodes-and-clients/archive-nodes/#recommended-practices) Mapendekezo ya vitendo ------------------------------------------------------------------------------------------------------------------------- Mbali na [mapendekezo ya jumla ya kuendesha nodi](https://ethereum.org/sw/developers/docs/nodes-and-clients/run-a-node/) , nodi ya kumbukumbu inaweza kuhitaji zaidi kwenye maunzi na matengenezo. Kwa kuzingatia [vipengele muhimu (inafunguka katika kichupo kipya)](https://github.com/ledgerwatch/erigon#key-features) vya Erigon, mbinu ya vitendo zaidi ni kutumia utekelezaji wa mteja wa [Erigon](https://ethereum.org/sw/developers/docs/nodes-and-clients/#erigon) . ### [](https://ethereum.org/sw/developers/docs/nodes-and-clients/archive-nodes/#hardware) Maunzi Hakikisha kila wakati unathibitisha mahitaji ya maunzi kwa hali fulani katika nyaraka za mteja. Hitaji kubwa zaidi kwa nodi za kumbukumbu ni nafasi ya diski. Kulingana na mteja, inatofautiana kutoka 3TB hadi 12TB. Hata kama HDD inaweza kuchukuliwa kuwa suluhisho bora kwa kiasi kikubwa cha data, kuisawazisha na kusasisha mara kwa mara kichwa cha mnyororo itahitaji diski za SSD. Diski za [SATA (inafunguka katika kichupo kipya)](https://www.cleverfiles.com/help/sata-hard-drive.html) ni nzuri vya kutosha lakini zinapaswa kuwa za ubora wa kuaminika, angalau [TLC (inafunguka katika kichupo kipya)](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences) . Diski zinaweza kuwekwa kwenye kompyuta ya mezani au seva yenye nafasi za kutosha. Vifaa kama hivyo vilivyojitolea ni bora kwa kuendesha nodi yenye muda mwingi wa kufanya kazi. Inawezekana kabisa kuiendesha kwenye kompyuta mpakato lakini uwezo wa kubebeka utakuja kwa gharama ya ziada. Data yote inahitaji kutoshea katika kiasi kimoja, kwa hivyo diski zinapaswa kuunganishwa, k.m., na [RAID0 (inafunguka katika kichupo kipya)](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) au LVM. Inaweza pia kuwa na thamani ya kufikiria kutumia [ZFS (inafunguka katika kichupo kipya)](https://en.wikipedia.org/wiki/ZFS) kwani inasaidia "Copy-on-write" ambayo inahakikisha data imeandikwa kwa usahihi kwenye diski bila makosa yoyote ya kiwango cha chini. Kwa uthabiti na usalama zaidi katika kuzuia uharibifu wa hifadhidata kwa bahati mbaya, hasa katika usanidi wa kitaalamu, fikiria kutumia [kumbukumbu ya ECC (inafunguka katika kichupo kipya)](https://en.wikipedia.org/wiki/ECC_memory) ikiwa mfumo wako unaiunga mkono. Ukubwa wa RAM kwa ujumla unashauriwa kuwa sawa na wa nodi kamili lakini RAM zaidi inaweza kusaidia kuharakisha usawazishaji. Wakati wa usawazishaji wa awali, wateja katika hali ya kumbukumbu watatekeleza kila muamala tangu mwanzo (genesis). Kasi ya utekelezaji mara nyingi inazuiwa na CPU, kwa hivyo CPU yenye kasi inaweza kusaidia kwa muda wa usawazishaji wa awali. Kwenye kompyuta ya wastani ya mtumiaji, usawazishaji wa awali unaweza kuchukua hadi mwezi mmoja. [](https://ethereum.org/sw/developers/docs/nodes-and-clients/archive-nodes/#further-reading) Usomaji zaidi ---------------------------------------------------------------------------------------------------------- * [Nodi Kamili ya Ethereum dhidi ya Nodi ya Kumbukumbu (inafunguka katika kichupo kipya)](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) - _QuickNode, Septemba 2022_ * [Kujenga Nodi Yako Mwenyewe ya Kumbukumbu ya Ethereum (inafunguka katika kichupo kipya)](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) - _Thomas Jay Rush, Agosti 2021_ * [Jinsi ya kusanidi Erigon, RPC ya Erigon na TrueBlocks (scrape na API) kama huduma (inafunguka katika kichupo kipya)](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– Magnus Hansson, ilisasishwa Septemba 2022_ [](https://ethereum.org/sw/developers/docs/nodes-and-clients/archive-nodes/#related-topics) Mada zinazohusiana -------------------------------------------------------------------------------------------------------------- * [Nodi na wateja](https://ethereum.org/sw/developers/docs/nodes-and-clients/) * [Kuendesha nodi](https://ethereum.org/sw/developers/docs/nodes-and-clients/run-a-node/) --- # Viwango vya Uendelezaji vya Ethereum | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/standards/#main-content) Change page Viwango vya Uendelezaji vya Ethereum ==================================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/index.md) Kwenye ukurasa huu [](https://ethereum.org/sw/developers/docs/standards/#standards-overview) Muhtasari wa viwango ---------------------------------------------------------------------------------------------- Jumuiya ya Ethereum imepitisha viwango vingi vinavyosaidia kuweka miradi (kama vile [wateja wa Ethereum](https://ethereum.org/sw/developers/docs/nodes-and-clients/) na pochi) inayoingiliana katika utekelezaji wote, na kuhakikisha mikataba mahiri na programu tumizi zilizogatuliwa (dapps) zinasalia kuwa zinazoweza kuunganishwa. Kwa kawaida viwango huletwa kama [Mapendekezo ya Kuboresha Ethereum](https://ethereum.org/sw/eips/) (EIPs), ambayo hujadiliwa na wanajumuiya kupitia [mchakato wa kawaida (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-1) . * [Utangulizi wa EIPs](https://ethereum.org/sw/eips/) * [Orodha ya EIPs (inafunguka katika kichupo kipya)](https://eips.ethereum.org/) * [Hifadhi ya GitHub ya EIP (inafunguka katika kichupo kipya)](https://github.com/ethereum/EIPs) * [Ubao wa majadiliano wa EIP (inafunguka katika kichupo kipya)](https://ethereum-magicians.org/c/eips) * [Utangulizi wa Utawala wa Ethereum](https://ethereum.org/sw/governance/) * [Muhtasari wa Utawala wa Ethereum (inafunguka katika kichupo kipya)](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _Machi 31, 2019 - Boris Mann_ * [Utawala wa Uendelezaji wa Itifaki ya Ethereum na Uratibu wa Uboreshaji wa Mtandao (inafunguka katika kichupo kipya)](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _Machi 23, 2020 - Hudson Jameson_ * [Orodha ya kucheza ya Mikutano yote ya Wasanidi Wakuu wa Ethereum (inafunguka katika kichupo kipya)](https://www.youtube.com/@EthereumProtocol) _(Orodha ya kucheza ya YouTube)_ [](https://ethereum.org/sw/developers/docs/standards/#types-of-standards) Aina za viwango ----------------------------------------------------------------------------------------- Kuna aina 3 za EIPs: * Njia ya Viwango: inaelezea mabadiliko yoyote yanayoathiri utekelezaji mwingi au wote wa Ethereum * [Njia ya Meta (inafunguka katika kichupo kipya)](https://eips.ethereum.org/meta) : inaelezea mchakato unaozunguka Ethereum au inapendekeza mabadiliko kwenye mchakato * [Njia ya Taarifa (inafunguka katika kichupo kipya)](https://eips.ethereum.org/informational) : inaelezea suala la muundo wa Ethereum au inatoa miongozo ya jumla au taarifa kwa jumuiya ya Ethereum Zaidi ya hayo, Njia ya Viwango imegawanywa katika makundi 4: * [Msingi (inafunguka katika kichupo kipya)](https://eips.ethereum.org/core) : maboresho yanayohitaji mchepuo wa mwafaka * [Mtandao (inafunguka katika kichupo kipya)](https://eips.ethereum.org/networking) : maboresho kuhusu devp2p na Itifaki Ndogo ya Ethereum Nyepesi, pamoja na maboresho yaliyopendekezwa kwa vipimo vya itifaki ya mtandao vya whisper na Kundi. * [Kiolesura (inafunguka katika kichupo kipya)](https://eips.ethereum.org/interface) : maboresho kuhusu vipimo na viwango vya API/RPC vya mteja, na viwango fulani vya kiwango cha lugha kama vile majina ya mbinu na ABIs za mkataba. * [ERC (inafunguka katika kichupo kipya)](https://eips.ethereum.org/erc) : viwango na taratibu za kiwango cha programu Taarifa za kina zaidi kuhusu aina na makundi haya tofauti zinaweza kupatikana katika [EIP-1 (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-1#eip-types) ### [](https://ethereum.org/sw/developers/docs/standards/#token-standards) Viwango vya tokeni * [ERC-20](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/) - Kiolesura cha kawaida cha tokeni zinazoweza kubadilishana, kama vile tokeni za kura, tokeni za uwekaji dhamana au sarafu za mtandaoni. * [ERC-223](https://ethereum.org/sw/developers/docs/standards/tokens/erc-223/) - Kiwango cha tokeni zinazoweza kubadilishana kinachofanya tokeni zifanye kazi sawa na Etha na inasaidia ushughulikiaji wa uhamishaji wa tokeni upande wa wapokeaji. * [ERC-1363](https://ethereum.org/sw/developers/docs/standards/tokens/erc-1363/) - Kiolesura cha kiendelezi cha tokeni za ERC-20 kinachosaidia kutekeleza wito wa kurudi kwenye mikataba ya mpokeaji katika muamala mmoja. * [ERC-721](https://ethereum.org/sw/developers/docs/standards/tokens/erc-721/) - Kiolesura cha kawaida cha tokeni zisizoweza kubadilishana, kama vile hati ya mchoro au wimbo. * [ERC-2309 (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-2309) - Tukio la kawaida linalotolewa wakati wa kuunda/kuhamisha tokeni moja, au nyingi zisizoweza kubadilishana kwa kutumia vitambulisho vya tokeni vinavyofuatana. * [ERC-4400 (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-4400) - Kiendelezi cha kiolesura cha jukumu la mtumiaji la EIP-721. * [ERC-4907 (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-4907) - Ongeza jukumu lenye ukomo wa muda na ruhusa zilizozuiliwa kwenye tokeni za ERC-721. * [ERC-777](https://ethereum.org/sw/developers/docs/standards/tokens/erc-777/) - **(HAIPENDEKEZWI)** Kiwango cha tokeni kinachoboresha ERC-20. * [ERC-1155](https://ethereum.org/sw/developers/docs/standards/tokens/erc-1155/) - Kiwango cha tokeni kinachoweza kuwa na rasilimali zinazoweza kubadilishana na zisizoweza kubadilishana. * [ERC-4626](https://ethereum.org/sw/developers/docs/standards/tokens/erc-4626/) - Kiwango cha hifadhi iliyowekwa tokeni iliyoundwa ili kuboresha na kuunganisha vigezo vya kiufundi vya hifadhi zinazozalisha faida. Jifunze zaidi kuhusu [viwango vya tokeni](https://ethereum.org/sw/developers/docs/standards/tokens/) . [](https://ethereum.org/sw/developers/docs/standards/#further-reading) Usomaji zaidi ------------------------------------------------------------------------------------ * [Mapendekezo ya Kuboresha Ethereum (EIPs)](https://ethereum.org/sw/eips/) _Unajua rasilimali ya jumuiya iliyokusaidia? Hariri ukurasa huu na uiongeze!_ --- # Potal Netwoki | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/networking-layer/portal-network/#main-content) Change page Potal Netwoki ============= Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/networking-layer/portal-network/index.md) Kwenye ukurasa huu [Ethereum](https://ethereum.org/sw/) ni mtandao unaoundwa na kompyuta zinazoendesha programu ya mteja wa Ethereum. Kila moja ya kompyuta hizi inaitwa 'nodi'. Programu ya mteja inaruhusu nodi kutuma na kupokea data kwenye mtandao wa Ethereum, na inathibitisha data dhidi ya sheria za itifaki ya Ethereum. Nodi huweka data nyingi za kihistoria katika hifadhi zao za diski na kuongeza juu yake zinapopokea pakiti mpya za taarifa, zinazojulikana kama vitalu, kutoka kwa nodi nyingine kwenye mtandao. Hili ni muhimu kwa kuangalia kila wakati kwamba nodi ina taarifa inayoendana na mtandao mzima. Hii inamaanisha kuendesha nodi kunaweza kuhitaji nafasi kubwa ya diski. Baadhi ya shughuli za nodi zinaweza kuhitaji RAM nyingi pia. Ili kutatua tatizo hili la hifadhi ya diski, nodi 'nyepesi' zimeundwa ambazo huomba taarifa kutoka kwa nodi kamili badala ya kuhifadhi zote zenyewe. Hata hivyo, hii inamaanisha nodi nyepesi haithibitishi taarifa kwa kujitegemea na badala yake inaiamini nodi nyingine. Pia inamaanisha kuwa nodi kamili zinahitajika kufanya kazi ya ziada ili kuhudumia hizo nodi nyepesi. Potal Netwoki ni muundo mpya wa mtandao kwa ajili ya Ethereum ambao unalenga kutatua tatizo la upatikanaji wa data kwa nodi "nyepesi" bila kulazimika kuamini au kuweka mzigo wa ziada kwenye nodi kamili, kwa kushiriki data muhimu katika vipande vidogo kwenye mtandao mzima. Zaidi kuhusu [nodi na wateja](https://ethereum.org/sw/developers/docs/nodes-and-clients/) [](https://ethereum.org/sw/developers/docs/networking-layer/portal-network/#why-do-we-need-portal-network) Kwa nini tunahitaji Potal Netwoki -------------------------------------------------------------------------------------------------------------------------------------------- Nodi za Ethereum huhifadhi nakala zao kamili au za sehemu za mnyororo wa vitalu wa Ethereum. Nakala hii ya ndani inatumika kuthibitisha miamala na kuhakikisha nodi inafuata mnyororo sahihi. Data hii iliyohifadhiwa ndani inaruhusu nodi kuthibitisha kwa kujitegemea kwamba data inayoingia ni halali na sahihi bila kuhitaji kuamini chombo kingine chochote. Nakala hii ya ndani ya mnyororo wa vitalu na data inayohusiana ya hali na stakabadhi inachukua nafasi kubwa kwenye diski kuu ya nodi. Kwa mfano, diski kuu ya 2TB inapendekezwa kwa kuendesha nodi kwa kutumia [Geth (inafunguka katika kichupo kipya)](https://geth.ethereum.org/) iliyounganishwa na mteja wa mwafaka. Kwa kutumia usawazishaji wa haraka (snap sync), ambao huhifadhi tu data ya mnyororo kutoka kwa seti ya hivi karibuni ya vitalu, Geth kwa kawaida huchukua takriban 650GB ya nafasi ya diski lakini inakua kwa takriban 14GB/kwa wiki (unaweza kupunguza nodi kurudi kwenye 650GB mara kwa mara). Hii inamaanisha kuendesha nodi kunaweza kuwa ghali, kwa sababu kiasi kikubwa cha nafasi ya diski kinapaswa kutengwa kwa ajili ya Ethereum. Kuna suluhisho kadhaa kwa tatizo hili kwenye ramani ya njia ya Ethereum, ikiwa ni pamoja na [ukomo wa historia](https://ethereum.org/sw/roadmap/statelessness/#history-expiry) , [ukomo wa hali](https://ethereum.org/sw/roadmap/statelessness/#state-expiry) na [ubilahali](https://ethereum.org/sw/roadmap/statelessness/) . Hata hivyo, hizi huenda zikachukua miaka kadhaa kabla ya kutekelezwa. Pia kuna [nodi nyepesi](https://ethereum.org/sw/developers/docs/nodes-and-clients/light-clients/) ambazo hazihifadhi nakala zao za data ya mnyororo, zinaomba data zinazohitaji kutoka kwa nodi kamili. Hata hivyo, hii inamaanisha nodi nyepesi zinapaswa kuamini nodi kamili kutoa data ya kweli na pia inaleta mkazo kwa nodi kamili ambazo zinapaswa kutoa data ambayo nodi nyepesi zinahitaji. Potal Netwoki inalenga kutoa njia mbadala kwa nodi nyepesi kupata data zao ambayo haihitaji kuamini au kuongeza kwa kiasi kikubwa kazi inayopaswa kufanywa na nodi kamili. Njia ambayo hii itafanywa ni kuanzisha njia mpya kwa nodi za Ethereum kushiriki data kwenye mtandao mzima. [](https://ethereum.org/sw/developers/docs/networking-layer/portal-network/#how-does-portal-network-work) Potal Netwoki inafanyaje kazi? ---------------------------------------------------------------------------------------------------------------------------------------- Nodi za Ethereum zina itifaki kali zinazofafanua jinsi zinavyowasiliana zenyewe kwa zenyewe. Wateja wa utekelezaji huwasiliana kwa kutumia seti ya itifaki ndogo zinazojulikana kama [devp2p](https://ethereum.org/sw/developers/docs/networking-layer/#devp2p) , wakati wateja wa mwafaka hutumia mkusanyiko tofauti wa itifaki ndogo unaoitwa [libp2p](https://ethereum.org/sw/developers/docs/networking-layer/#libp2p) . Hizi hufafanua aina za data zinazoweza kupitishwa kati ya nodi. [![devP2P and libP2P](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fnetworking-layer%2Fportal-network%2Fportal-network-devp2p-libp2p.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/networking-layer/portal-network/portal-network-devp2p-libp2p.png) Nodi pia zinaweza kutoa data maalum kupitia [JSON-RPC API](https://ethereum.org/sw/developers/docs/apis/json-rpc/) , ambayo ndiyo njia programu na pochi hubadilishana taarifa na nodi za Ethereum. Hata hivyo, hakuna kati ya hizi iliyo itifaki bora kwa kutoa data kwa wateja wepesi. Wateja wepesi kwa sasa hawawezi kuomba vipande maalum vya data ya mnyororo kupitia devp2p au libp2p kwa sababu itifaki hizo zimeundwa tu kuwezesha usawazishaji wa mnyororo na usambazaji wa taarifa (gossiping) wa vitalu na miamala. Wateja wepesi hawataki kupakua taarifa hii kwa sababu hiyo ingewazuia kuwa "wepesi". JSON-RPC API pia si chaguo bora kwa maombi ya data ya mteja mwepesi, kwa sababu inategemea muunganisho kwa nodi kamili maalum au mtoa huduma wa RPC aliyewekwa kati ambaye anaweza kutoa data. Hii inamaanisha mteja mwepesi anapaswa kuamini nodi/mtoa huduma huyo maalum kuwa mkweli, na pia nodi kamili inaweza kulazimika kushughulikia maombi mengi kutoka kwa wateja wepesi wengi, na kuongeza mahitaji yao ya kipimo data. Lengo la Potal Netwoki ni kufikiria upya muundo mzima, kujenga hasa kwa ajili ya wepesi, nje ya vikwazo vya muundo wa wateja wa Ethereum waliopo. Wazo kuu la Potal Netwoki ni kuchukua sehemu bora zaidi za mkusanyiko wa sasa wa mtandao kwa kuwezesha taarifa zinazohitajika na wateja wepesi, kama vile data ya kihistoria na utambulisho wa kichwa cha sasa cha mnyororo kutolewa kupitia mtandao mwepesi uliogatuliwa wa rika-kwa-rika wa mtindo wa devp2p kwa kutumia [DHT (inafunguka katika kichupo kipya)](https://en.wikipedia.org/wiki/Distributed_hash_table) (sawa na Bittorrent). Wazo ni kuongeza sehemu ndogo za jumla ya data ya kihistoria ya Ethereum na baadhi ya majukumu maalum ya nodi kwa kila nodi. Kisha, maombi yanahudumiwa kwa kutafuta nodi zinazohifadhi data maalum iliyoombwa na kuirejesha kutoka kwao. Hii inageuza mtindo wa kawaida wa nodi nyepesi kupata nodi moja na kuiomba kuchuja na kutoa kiasi kikubwa cha data; badala yake, zinachuja haraka mtandao mkubwa wa nodi ambazo kila moja inashughulikia kiasi kidogo cha data. Lengo ni kuruhusu mtandao uliogatuliwa wa wateja wepesi wa Potal: * kufuatilia kichwa cha mnyororo * kufanya usawazishaji wa data ya mnyororo ya hivi karibuni na ya kihistoria * kurejesha data ya hali * kutangaza miamala * kutekeleza miamala kwa kutumia [EVM](https://ethereum.org/sw/developers/docs/evm/) Faida za muundo huu wa mtandao ni: * kupunguza utegemezi kwa watoa huduma waliowekwa kati * Kupunguza matumizi ya kipimo data cha Intaneti * Usawazishaji uliopunguzwa au sifuri * Inapatikana kwa vifaa vyenye rasilimali chache (<1 GB RAM, <100 MB nafasi ya diski, 1 CPU) Jedwali hapa chini linaonyesha kazi za wateja waliopo ambazo zinaweza kutolewa na Potal Netwoki, kuwezesha watumiaji kufikia kazi hizi kwenye vifaa vyenye rasilimali chache sana. ### [](https://ethereum.org/sw/developers/docs/networking-layer/portal-network/#the-portal-networks) Potal Netwoki | Kiteja chepesi cha Beacon | Mtandao wa hali | Usambazaji wa miamala | Mtandao wa historia | Faharisi ya Miamala ya Kikanonika | | --- | --- | --- | --- | --- | | Kiteja chepesi cha mnyororo wa Beacon | Hifadhi ya akaunti na mkataba | Mempool nyepesi | Vihusishi (Headers) | TxHash > Heshi, Faharisi | | Data ya itifaki | | | Miili ya vitalu | | | | | | Stakabadhi | | [](https://ethereum.org/sw/developers/docs/networking-layer/portal-network/#client-diversity-as-default) Anuwai ya wateja kwa chaguo-msingi ------------------------------------------------------------------------------------------------------------------------------------------- Wasanidi wa Potal Netwoki pia walifanya uamuzi wa kimuundo wa kujenga wateja wanne tofauti wa Potal Netwoki kuanzia siku ya kwanza. Wateja wa Potal Netwoki ni: * [Trin (inafunguka katika kichupo kipya)](https://github.com/ethereum/trin) : imeandikwa kwa Rust * [Fluffy (inafunguka katika kichupo kipya)](https://fluffy.guide/) : imeandikwa kwa Nim * [Ultralight (inafunguka katika kichupo kipya)](https://github.com/ethereumjs/ultralight) : imeandikwa kwa TypeScript * [Shisui (inafunguka katika kichupo kipya)](https://github.com/zen-eth/shisui) : imeandikwa kwa Go Kuwa na utekelezaji wa wateja wengi wanaojitegemea huongeza uthabiti na ugatuzi wa mtandao wa Ethereum. Ikiwa mteja mmoja atapata matatizo au udhaifu, wateja wengine wanaweza kuendelea kufanya kazi vizuri, na kuzuia hatari ya kushindwa kwa mfumo mzima (single point of failure). Zaidi ya hayo, utekelezaji wa anuwai ya wateja hukuza ubunifu na ushindani, na kuchochea maboresho na kupunguza hatari ya utamaduni mmoja (monoculture) ndani ya mfumo ikolojia. [](https://ethereum.org/sw/developers/docs/networking-layer/portal-network/#further-reading) Usomaji zaidi ---------------------------------------------------------------------------------------------------------- * [Potal Netwoki (Piper Merriam katika Devcon Bogota) (inafunguka katika kichupo kipya)](https://www.youtube.com/watch?v=0stc9jnQLXA) . * [Discord ya Potal Netwoki (inafunguka katika kichupo kipya)](https://discord.gg/CFFnmE7Hbs) * [Tovuti ya Potal Netwoki (inafunguka katika kichupo kipya)](https://www.ethportal.net/) --- # データ構造とエンコーディング | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/#main-content) Change page データ構造とエンコーディング ============== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-structures-and-encoding/index.md) このページの内容 イーサリアムは大量のデータを作成、保存、転送します。誰もが比較的控えめな消費者向けハードウェアで[ノードを実行](https://ethereum.org/ja/run-a-node/) できるように、このデータは標準化され、メモリ効率の良い方法でフォーマットされる必要があります。これを実現するために、イーサリアムのスタックではいくつかの特定のデータ構造が使用されています。 [](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/#prerequisites) 前提条件 -------------------------------------------------------------------------------------------- イーサリアムの基礎と[クライアントソフトウェア](https://ethereum.org/ja/developers/docs/nodes-and-clients/) について理解している必要があります。ネットワーキングレイヤーと[イーサリアムのホワイトペーパー](https://ethereum.org/ja/whitepaper/) に精通していることが推奨されます。 [](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/#data-structures) データ構造 ----------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/#patricia-merkle-tries) パトリシア・マークル・ツリー パトリシア・マークル・ツリー (Patricia Merkle Tries) は、鍵と値のペアを決定論的かつ暗号学的に認証されたツリーにエンコードする構造です。これらは、イーサリアムの実行レイヤー全体で広く使用されています。 [パトリシア・マークル・ツリーの詳細](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) ### [](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/#recursive-length-prefix) 再帰的長さプレフィックス (RLP) 再帰的長さプレフィックス (RLP) は、イーサリアムの実行レイヤー全体で広く使用されているシリアライゼーション手法です。 [RLPの詳細](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/rlp/) ### [](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/#simple-serialize) シンプル・シリアライズ (SSZ) シンプル・シリアライズ (SSZ) は、マークル化との互換性があるため、イーサリアムのコンセンサス・レイヤーにおける主要なシリアライゼーション形式です。 [SSZの詳細](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/ssz/) --- # イーサリアムのブートノード入門 | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/nodes-and-clients/bootnodes/#main-content) Change page イーサリアムのブートノード入門 =============== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/nodes-and-clients/bootnodes/index.md) このページの内容 新しいノードがイーサリアムのネットワークに参加する際、新しいピアを発見するために、すでにネットワーク上に存在するノードに接続する必要があります。イーサリアムのネットワークへのこれらのエントリポイントは、ブートノードと呼ばれます。通常、クライアントにはブートノードのリストがハードコードされています。これらのブートノードは通常、イーサリアム財団のDevOpsチームやクライアントチーム自身によって運営されています。ブートノードは静的ノードとは異なることに注意してください。静的ノードは何度も繰り返し呼び出されますが、ブートノードは接続するピアが不足しており、ノードが新しい接続をブートストラップする必要がある場合にのみ呼び出されます。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/bootnodes/#connect-to-a-bootnode) ブートノードへの接続 --------------------------------------------------------------------------------------------------------- ほとんどのクライアントにはブートノードのリストが組み込まれていますが、独自のブートノードを実行したり、クライアントのハードコードされたリストに含まれていないブートノードを使用したりすることもできます。この場合、クライアントの起動時に次のように指定できます（例はGethのものです。クライアントのドキュメントを確認してください）。 geth --bootnodes "enode://@:" コピー [](https://ethereum.org/ja/developers/docs/nodes-and-clients/bootnodes/#run-a-bootnode) ブートノードの実行 ------------------------------------------------------------------------------------------------- ブートノードは、NAT（[ネットワークアドレス変換 （新しいタブで開きます）](https://www.geeksforgeeks.org/network-address-translation-nat/) ）の背後にないフル・ノードです。パブリックに利用可能である限り、すべてのフル・ノードはブートノードとして機能できます。 ノードを起動すると、[enode](https://ethereum.org/ja/developers/docs/networking-layer/network-addresses/#enode) がログに記録されるはずです。これは、他の人があなたのノードに接続するために使用できるパブリック識別子です。 enodeは通常、再起動のたびに再生成されるため、ブートノード用の永続的なenodeを生成する方法については、クライアントのドキュメントを必ず確認してください。 優れたブートノードにするためには、接続できるピアの最大数を増やすことをお勧めします。多くのピアを持つブートノードを実行すると、必要な帯域幅が大幅に増加します。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/bootnodes/#available-bootnodes) 利用可能なブートノード -------------------------------------------------------------------------------------------------------- go-ethereumに組み込まれているブートノードのリストは、[こちら （新しいタブで開きます）](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23) で確認できます。これらのブートノードは、イーサリアム財団とgo-ethereumチームによって維持されています。 ボランティアによって維持されている他のブートノードのリストも利用可能です。エクリプス攻撃を受ける可能性があるため、常に少なくとも1つの公式ブートノードを含めるようにしてください。 --- # Usanjari rahisi | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/ssz/#main-content) Change page Usanjari rahisi =============== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-structures-and-encoding/ssz/index.md) Kwenye ukurasa huu **Usanjari rahisi (SSZ)** ni mbinu ya usanjari inayotumika kwenye Mnyororo wa Beacon. Inachukua nafasi ya usanjari wa RLP unaotumika kwenye tabaka la utekelezaji kila mahali kwenye tabaka la mwafaka isipokuwa kwenye itifaki ya ugunduzi wa mwenza. Ili kujifunza zaidi kuhusu usanjari wa RLP, tazama [Kiambishi awali cha urefu wa kujirudia (RLP)](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/rlp/) . SSZ imeundwa kuwa thabiti na pia kufanya umerkle kwa ufanisi. SSZ inaweza kufikiriwa kuwa na vijenzi viwili: mpango wa usanjari na mpango wa kugeuza kuwa mti wa Merkle ambao umeundwa kufanya kazi kwa ufanisi na muundo wa data uliosanjariwa. [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/ssz/#how-does-ssz-work) SSZ inafanyaje kazi? -------------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/ssz/#serialization) Usanjari SSZ ni mpango wa usanjari ambao haujielezi wenyewe - badala yake unategemea skema ambayo lazima ijulikane mapema. Lengo la usanjari wa SSZ ni kuwakilisha vipengee vya utata wowote kama mifuatano ya baiti. Huu ni mchakato rahisi sana kwa "aina za msingi". Kipengele hubadilishwa tu kuwa baiti za heksadesimali. Aina za msingi ni pamoja na: * nambari kamili zisizo na ishara (unsigned integers) * Buleani (Booleans) Kwa aina changamano za "mchanganyiko", usanjari ni mgumu zaidi kwa sababu aina ya mchanganyiko ina vipengele vingi ambavyo vinaweza kuwa na aina tofauti au ukubwa tofauti, au vyote viwili. Ambapo vipengee hivi vyote vina urefu usiobadilika (yaani, ukubwa wa vipengele utakuwa wa kudumu kila wakati bila kujali thamani zake halisi) usanjari ni ubadilishaji tu wa kila kipengele katika aina ya mchanganyiko kilichopangwa katika mifuatano ya baiti ya little-endian. Mifuatano hii ya baiti huunganishwa pamoja. Kipengee kilichosanjariwa kina uwakilishi wa orodha ya baiti ya vipengele vya urefu usiobadilika katika mpangilio sawa na jinsi vinavyoonekana katika kipengee kilichotolewa kwenye usanjari. Kwa aina zenye urefu unaobadilika, data halisi hubadilishwa na thamani ya "kifidia" (offset) katika nafasi ya kipengele hicho katika kipengee kilichosanjariwa. Data halisi huongezwa kwenye lundo mwishoni mwa kipengee kilichosanjariwa. Thamani ya kifidia ni faharisi ya kuanza kwa data halisi kwenye lundo, ikifanya kazi kama kielekezi kwa baiti husika. Mfano hapa chini unaonyesha jinsi ufidiaji unavyofanya kazi kwa kontena lenye vipengele vya urefu usiobadilika na unaobadilika: struct Dummy { number1: u64, number2: u64, vector: Vec, number3: u64 } dummy = Dummy{ number1: 37, number2: 55, vector: vec![1,2,3,4], number3: 22, } serialized = ssz.serialize(dummy) Nakili Onyesha yote (19) `serialized` ingekuwa na muundo ufuatao (imejazwa tu hadi biti 4 hapa, imejazwa hadi biti 32 kiuhalisia, na kuweka uwakilishi wa `int` kwa uwazi): [37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4] ------------ ----------- ----------- ----------- ---------- | | | | | nambari1 nambari2 kifidia cha nambari 3 thamani ya vekta vekta Nakili imegawanywa kwenye mistari kwa uwazi: [\ 37, 0, 0, 0, # usimbaji wa little-endian wa `number1`.\ 55, 0, 0, 0, # usimbaji wa little-endian wa `number2`.\ 16, 0, 0, 0, # "Kifidia" kinachoonyesha mahali thamani ya `vector` inapoanzia (little-endian 16).\ 22, 0, 0, 0, # usimbaji wa little-endian wa `number3`.\ 1, 2, 3, 4, # Thamani halisi katika `vector`.\ ] Nakili Huu bado ni urahisishaji - nambari kamili na sufuri katika michoro hapo juu kwa kweli zingehifadhiwa kama orodha za baiti, kama hivi: [\ 10100101000000000000000000000000 # usimbaji wa little-endian wa `number1`\ 10110111000000000000000000000000 # usimbaji wa little-endian wa `number2`.\ 10010000000000000000000000000000 # "Kifidia" kinachoonyesha mahali thamani ya `vector` inapoanzia (little-endian 16).\ 10010110000000000000000000000000 # usimbaji wa little-endian wa `number3`.\ 10000001100000101000001110000100 # Thamani halisi ya uga wa `bytes`.\ ] Nakili Kwa hivyo thamani halisi za aina zenye urefu unaobadilika huhifadhiwa kwenye lundo mwishoni mwa kipengee kilichosanjariwa huku vifidia vyake vikihifadhiwa katika nafasi zake sahihi katika orodha iliyopangwa ya nyanja. Pia kuna baadhi ya matukio maalum ambayo yanahitaji matibabu maalum, kama vile aina ya `BitList` ambayo inahitaji kikomo cha urefu kuongezwa wakati wa usanjari na kuondolewa wakati wa kutoa kwenye usanjari. Maelezo kamili yanapatikana katika [vipimo vya SSZ (inafunguka katika kichupo kipya)](https://github.com/ethereum/consensus-specs/blob/master/ssz/simple-serialize.md) . ### [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/ssz/#deserialization) Kutoa kwenye usanjari Kutoa kipengee hiki kwenye usanjari kunahitaji **skema**. Skema inafafanua mpangilio kamili wa data iliyosanjariwa ili kila kipengele maalum kiweze kutolewa kwenye usanjari kutoka kwenye blobu ya baiti hadi kwenye kipengee chenye maana huku vipengele vikiwa na aina, thamani, ukubwa na nafasi sahihi. Ni skema inayomwambia mtoaji kwenye usanjari ni thamani zipi ni thamani halisi na zipi ni vifidia. Majina yote ya nyanja hupotea wakati kipengee kinaposanjariwa, lakini hurejeshwa wakati wa kutoa kwenye usanjari kulingana na skema. [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/ssz/#merkleization) Kugeuza kuwa mti wa Merkle (Merkleization) -------------------------------------------------------------------------------------------------------------------------------------- Kipengee hiki kilichosanjariwa cha SSZ kinaweza kugeuzwa kuwa mti wa Merkle - yaani kubadilishwa kuwa uwakilishi wa mti wa Merkle wa data hiyo hiyo. Kwanza, idadi ya vipande vya baiti 32 katika kipengee kilichosanjariwa hubainishwa. Haya ni "majani" ya mti. Jumla ya idadi ya majani lazima iwe kipeo cha 2 ili kuheshiji pamoja majani hatimaye kuzalishe mzizi mmoja wa mti wa heshi. Ikiwa hii si hivyo kiasili, majani ya ziada yenye baiti 32 za sufuri huongezwa. Kwa mchoro: mzizi wa mti wa heshi / \ / \ / \ / \ heshi ya majani heshi ya majani 1 na 2 3 na 4 / \ / \ / \ / \ / \ / \ jani1 jani2 jani3 jani4 Nakili Onyesha yote (11) Pia kuna matukio ambapo majani ya mti hayasambaaji kwa usawa kiasili kwa njia yanayofanya katika mfano hapo juu. Kwa mfano, jani la 4 linaweza kuwa kontena lenye vipengele vingi vinavyohitaji "kina" cha ziada kuongezwa kwenye mti wa Merkle, na kuunda mti usio sawa. Badala ya kurejelea vipengele hivi vya mti kama jani X, nodi X n.k., tunaweza kuvipa faharisi za jumla, kuanzia na mzizi = 1 na kuhesabu kutoka kushoto kwenda kulia kando ya kila kiwango. Hii ndiyo faharisi ya jumla iliyoelezwa hapo juu. Kila kipengele katika orodha iliyosanjariwa kina faharisi ya jumla sawa na `2**depth + idx` ambapo idx ni nafasi yake yenye faharisi ya sufuri katika kipengee kilichosanjariwa na kina ni idadi ya viwango katika mti wa Merkle, ambayo inaweza kubainishwa kama logariti ya msingi wa mbili ya idadi ya vipengele (majani). [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/ssz/#generalized-indices) Faharisi za jumla ------------------------------------------------------------------------------------------------------------------- Faharisi ya jumla ni nambari kamili inayowakilisha nodi katika mti wa Merkle wa mfumo wa jozi ambapo kila nodi ina faharisi ya jumla `2 ** depth + index in row`. 1 --kina = 0 2**0 + 0 = 1 2 3 --kina = 1 2**1 + 0 = 2, 2**1+1 = 3 4 5 6 7 --kina = 2 2**2 + 0 = 4, 2**2 + 1 = 5... Nakili Uwakilishi huu hutoa faharisi ya nodi kwa kila kipande cha data katika mti wa Merkle. [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/ssz/#multiproofs) Uthibitisho mwingi (Multiproofs) -------------------------------------------------------------------------------------------------------------------------- Kutoa orodha ya faharisi za jumla zinazowakilisha kipengele maalum huturuhusu kukithibitisha dhidi ya mzizi wa mti wa heshi. Mzizi huu ndio toleo letu linalokubalika la uhalisia. Data yoyote tunayopewa inaweza kuthibitishwa dhidi ya uhalisia huo kwa kuiingiza mahali sahihi katika mti wa Merkle (inayobainishwa na faharisi yake ya jumla) na kuchunguza kwamba mzizi unabaki kuwa wa kudumu. Kuna vipengele vya utendaji katika vipimo [hapa (inafunguka katika kichupo kipya)](https://github.com/ethereum/consensus-specs/blob/master/ssz/merkle-proofs.md#merkle-multiproofs) vinavyoonyesha jinsi ya kukokotoa seti ya chini zaidi ya nodi zinazohitajika ili kuthibitisha yaliyomo katika seti fulani ya faharisi za jumla. Kwa mfano, ili kuthibitisha data katika faharisi ya 9 katika mti ulio hapa chini, tunahitaji heshi ya data katika faharisi za 8, 9, 5, 3, 1. Heshi ya (8,9) inapaswa kuwa sawa na heshi (4), ambayo huheshiji na 5 ili kuzalisha 2, ambayo huheshiji na 3 ili kuzalisha mzizi wa mti 1. Ikiwa data isiyo sahihi ilitolewa kwa 9, mzizi ungebadilika - tungegundua hili na kushindwa kuthibitisha tawi. * = data inayohitajika ili kuzalisha uthibitisho 1* 2 3* 4 5* 6 7 8* 9* 10 11 12 13 14 15 Nakili [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/ssz/#further-reading) Usomaji zaidi ----------------------------------------------------------------------------------------------------------- * [Kuboresha Ethereum: SSZ (inafunguka katika kichupo kipya)](https://eth2book.info/altair/part2/building_blocks/ssz) * [Kuboresha Ethereum: Kugeuza kuwa mti wa Merkle (inafunguka katika kichupo kipya)](https://eth2book.info/altair/part2/building_blocks/merkleization) * [Utekelezaji wa SSZ (inafunguka katika kichupo kipya)](https://github.com/ethereum/consensus-specs/issues/2138) * [Kikokotoo cha SSZ (inafunguka katika kichupo kipya)](https://simpleserialize.com/) --- # 개발 네트워크 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/development-networks/#main-content) Change page 개발 네트워크 ======= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/development-networks/index.md) 이 페이지의 내용 스마트 컨트랙트를 사용하여 [이더리움](https://ethereum.org/ko/) 애플리케이션을 구축할 때, 이를 배포하기 전에 로컬 네트워크에서 실행하여 어떻게 작동하는지 확인하고 싶을 것입니다. 웹 개발을 위해 컴퓨터에서 로컬 서버를 실행하는 것과 유사하게, 개발 네트워크를 사용하여 로컬 블록체인 인스턴스를 생성하고 탈중앙화 애플리케이션 (dapp)을 테스트할 수 있습니다. 이러한 이더리움 개발 네트워크는 퍼블릭 테스트넷보다 훨씬 빠른 반복 작업을 가능하게 하는 기능을 제공합니다(예를 들어 테스트넷 포싯에서 ETH를 얻는 번거로운 과정을 거칠 필요가 없습니다). [](https://ethereum.org/ko/developers/docs/development-networks/#prerequisites) 전제 조건 ------------------------------------------------------------------------------------- 개발 네트워크에 대해 자세히 알아보기 전에 [이더리움 스택의 기초](https://ethereum.org/ko/developers/docs/ethereum-stack/) 와 [이더리움 네트워크](https://ethereum.org/ko/developers/docs/networks/) 를 이해해야 합니다. [](https://ethereum.org/ko/developers/docs/development-networks/#what-is-a-development-network) 개발 네트워크란 무엇인가요? --------------------------------------------------------------------------------------------------------------- 개발 네트워크는 본질적으로 로컬 개발을 위해 특별히 설계된 이더리움 클라이언트(이더리움 구현체)입니다. **왜 로컬에서 표준 이더리움 노드를 실행하지 않나요?** [노드를 실행](https://ethereum.org/ko/developers/docs/nodes-and-clients/#running-your-own-node) 할 _수도_ 있지만, 개발 네트워크는 개발을 목적으로 구축되었기 때문에 다음과 같은 편리한 기능이 포함되어 있는 경우가 많습니다. * 로컬 블록체인에 데이터를 결정론적으로 시딩(예: ETH 잔액이 있는 계정) * 트랜잭션을 수신할 때마다 지연 없이 순서대로 즉시 블록 생성 * 향상된 디버깅 및 로깅 기능 [](https://ethereum.org/ko/developers/docs/development-networks/#available-projects) 사용 가능한 도구 ---------------------------------------------------------------------------------------------- **참고**: 대부분의 [개발 프레임워크](https://ethereum.org/ko/developers/docs/frameworks/) 에는 개발 네트워크가 내장되어 있습니다. 프레임워크로 시작하여 [로컬 개발 환경을 설정](https://ethereum.org/ko/developers/local-environment/) 하는 것을 권장합니다. ### [](https://ethereum.org/ko/developers/docs/development-networks/#hardhat-network) Hardhat 네트워크 개발을 위해 설계된 로컬 이더리움 네트워크입니다. 컨트랙트를 배포하고, 테스트를 실행하며, 코드를 디버깅할 수 있습니다. Hardhat 네트워크는 전문가를 위한 이더리움 개발 환경인 Hardhat에 내장되어 있습니다. * [웹사이트 (새 탭에서 열림)](https://hardhat.org/) * [GitHub (새 탭에서 열림)](https://github.com/NomicFoundation/hardhat) ### [](https://ethereum.org/ko/developers/docs/development-networks/#local-beacon-chains) 로컬 비콘 체인 일부 합의 클라이언트에는 테스트 목적으로 로컬 비콘 체인을 가동하기 위한 도구가 내장되어 있습니다. 라이트하우스, 님버스 및 로드스타에 대한 지침이 제공됩니다. * [로드스타를 사용한 로컬 테스트넷 (새 탭에서 열림)](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/) * [라이트하우스를 사용한 로컬 테스트넷 (새 탭에서 열림)](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets) ### [](https://ethereum.org/ko/developers/docs/development-networks/#public-beacon-testchains) 퍼블릭 이더리움 테스트 체인 유지 관리되는 퍼블릭 이더리움 테스트 구현체로는 Sepolia와 Hoodi 두 가지가 있습니다. 장기 지원이 제공되는 권장 테스트넷은 누구나 자유롭게 검증할 수 있는 Hoodi입니다. Sepolia는 허가형 검증자 세트를 사용하므로, 이 테스트넷에서는 새로운 검증자의 일반적인 접근이 불가능합니다. * [Hoodi 스테이킹 런치패드 (새 탭에서 열림)](https://hoodi.launchpad.ethereum.org/) ### [](https://ethereum.org/ko/developers/docs/development-networks/#kurtosis) Kurtosis 이더리움 패키지 Kurtosis는 개발자가 로컬에서 블록체인 네트워크의 재현 가능한 인스턴스를 가동할 수 있게 해주는 다중 컨테이너 테스트 환경용 빌드 시스템입니다. 이더리움 Kurtosis 패키지를 사용하면 Docker 또는 Kubernetes에서 매개변수화가 가능하고 확장성이 뛰어난 프라이빗 이더리움 테스트넷을 빠르게 인스턴스화할 수 있습니다. 이 패키지는 모든 주요 실행 계층(EL) 및 합의 레이어(CL) 클라이언트를 지원합니다. Kurtosis는 이더리움 핵심 인프라와 관련된 검증 및 테스트 워크플로에 사용될 대표 네트워크의 모든 로컬 포트 매핑과 서비스 연결을 원활하게 처리합니다. * [이더리움 네트워크 패키지 (새 탭에서 열림)](https://github.com/kurtosis-tech/ethereum-package) * [웹사이트 (새 탭에서 열림)](https://www.kurtosis.com/) * [GitHub (새 탭에서 열림)](https://github.com/kurtosis-tech/kurtosis) * [문서 (새 탭에서 열림)](https://docs.kurtosis.com/) [](https://ethereum.org/ko/developers/docs/development-networks/#further-reading) 더 읽어보기 ---------------------------------------------------------------------------------------- _도움이 된 커뮤니티 리소스를 알고 계신가요? 이 페이지를 편집하여 추가해 주세요!_ [](https://ethereum.org/ko/developers/docs/development-networks/#related-topics) 관련 주제 -------------------------------------------------------------------------------------- * [개발 프레임워크](https://ethereum.org/ko/developers/docs/frameworks/) * [로컬 개발 환경 설정](https://ethereum.org/ko/developers/local-environment/) [](https://ethereum.org/ko/developers/docs/development-networks/#tutorials) 튜토리얼: 이더리움의 개발 네트워크 및 테스트 환경 -------------------------------------------------------------------------------------------------------- * [다중 클라이언트 로컬 이더리움 테스트넷으로 탈중앙화 애플리케이션 (dapp) 개발 및 테스트하기](https://ethereum.org/ko/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/) _– 탈중앙화 애플리케이션 (dapp) 개발 및 테스트를 위해 Kurtosis로 로컬 다중 클라이언트 이더리움 테스트넷을 가동하는 방법._ --- # Gasper | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/gasper/#main-content) Change page Gasper ====== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/consensus-mechanisms/pos/gasper/index.md) 이 페이지의 내용 Gasper는 캐스퍼 FFG(Casper the Friendly Finality Gadget)와 엘엠디 고스트(LMD-GHOST) 포크 선택 알고리즘의 조합입니다. 이 두 구성 요소는 함께 지분 증명(PoS) 이더리움을 보호하는 합의 메커니즘을 형성합니다. Casper는 특정 블록을 "완결된" 상태로 업그레이드하여 네트워크에 새로 진입하는 참여자가 표준 체인을 동기화하고 있다고 확신할 수 있게 해주는 메커니즘입니다. 포크 선택 알고리즘은 누적된 투표를 사용하여 블록체인에 포크가 발생했을 때 노드가 올바른 포크를 쉽게 선택할 수 있도록 보장합니다. **참고**: 캐스퍼 FFG의 원래 정의는 Gasper에 포함되기 위해 약간 업데이트되었습니다. 이 페이지에서는 업데이트된 버전을 다룹니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/gasper/#prerequisites) 전제 조건 ------------------------------------------------------------------------------------------------ 이 자료를 이해하려면 [지분 증명(PoS)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/) 에 대한 소개 페이지를 읽어야 합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/gasper/#role-of-gasper) Gasper의 역할 ------------------------------------------------------------------------------------------------------ Gasper는 노드가 블록을 제안하거나 검증할 때 게으르거나 부정직하게 행동할 경우 파기될 수 있는 보안 보증금으로 이더를 제공하는 지분 증명 블록체인 위에서 작동합니다. Gasper는 검증자가 보상과 처벌을 받는 방식, 수락하거나 거부할 블록을 결정하는 방식, 그리고 블록체인의 어떤 포크를 기반으로 구축할지 정의하는 메커니즘입니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/gasper/#what-is-finality) 완결성이란 무엇인가요? ---------------------------------------------------------------------------------------------------------- 완결성은 치명적인 합의 실패가 발생하고 공격자가 전체 스테이킹된 이더의 최소 3분의 1을 파기하지 않는 한 되돌릴 수 없음을 의미하는 특정 블록의 속성입니다. 완결된 블록은 블록체인이 확신하는 정보라고 생각할 수 있습니다. 블록이 완결되려면 2단계 업그레이드 절차를 거쳐야 합니다. 1. 전체 스테이킹된 이더의 3분의 2가 해당 블록을 표준 체인에 포함하는 데 찬성하는 투표를 해야 합니다. 이 조건은 블록을 "정당화된" 상태로 업그레이드합니다. 정당화된 블록은 되돌려질 가능성이 낮지만, 특정 조건에서는 되돌려질 수 있습니다. 2. 정당화된 블록 위에 다른 블록이 정당화되면, 해당 블록은 "완결된" 상태로 업그레이드됩니다. 블록을 완결하는 것은 해당 블록을 표준 체인에 포함하겠다는 커밋먼트입니다. 공격자가 수백만 이더(수십억 달러)를 파기하지 않는 한 이를 되돌릴 수 없습니다. 이러한 블록 업그레이드는 모든 슬롯에서 발생하지 않습니다. 대신 에포크 경계 블록만 정당화되고 완결될 수 있습니다. 이러한 블록을 "체크포인트"라고 합니다. 업그레이드는 체크포인트 쌍을 고려합니다. 덜 최근의 체크포인트를 완결된 상태로, 더 최근의 블록을 정당화된 상태로 업그레이드하려면 두 연속된 체크포인트 사이에 "절대다수 링크"가 존재해야 합니다(즉, 전체 스테이킹된 이더의 3분의 2가 체크포인트 B가 체크포인트 A의 올바른 후손이라고 투표해야 함). 완결성에는 블록이 표준이라는 3분의 2의 동의가 필요하므로, 공격자는 다음 조건 없이 대안적인 완결된 체인을 생성할 수 없습니다. 1. 전체 스테이킹된 이더의 3분의 2를 소유하거나 조작합니다. 2. 전체 스테이킹된 이더의 최소 3분의 1을 파기합니다. 첫 번째 조건은 체인을 완결하는 데 스테이킹된 이더의 3분의 2가 필요하기 때문에 발생합니다. 두 번째 조건은 전체 스테이크의 3분의 2가 두 포크 모두에 찬성 투표를 했다면, 3분의 1은 양쪽 모두에 투표했어야 하기 때문에 발생합니다. 이중 투표는 최대한의 처벌을 받는 슬래싱 조건이며, 전체 스테이크의 3분의 1이 파기됩니다. 2022년 5월 기준으로, 이를 위해서는 공격자가 약 100억 달러 가치의 이더를 소각해야 합니다. Gasper에서 블록을 정당화하고 완결하는 알고리즘은 [캐스퍼 FFG(Casper the Friendly Finality Gadget) (새 탭에서 열림)](https://arxiv.org/pdf/1710.09437.pdf) 의 약간 수정된 형태입니다. ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/gasper/#incentives-and-slashing) 인센티브 및 슬래싱 검증자는 정직하게 블록을 제안하고 검증하면 보상을 받습니다. 이더가 보상으로 지급되며 이들의 스테이크에 추가됩니다. 반면, 부재중이거나 호출되었을 때 행동하지 않는 검증자는 이러한 보상을 놓치고 때로는 기존 스테이크의 일부를 잃기도 합니다. 하지만 오프라인 상태에 대한 페널티는 작으며, 대부분의 경우 보상을 놓치는 기회비용에 해당합니다. 그러나 동일한 슬롯에 대해 여러 블록을 제안하거나, 동일한 슬롯에 대해 여러 블록을 증명하거나, 이전 체크포인트 투표와 모순되는 행동 등은 실수로 하기 매우 어려우며 악의적인 인텐트를 나타냅니다. 이러한 행동은 더 가혹하게 처벌받는 "슬래싱 가능한" 행동입니다. 슬래싱은 검증자 스테이크의 일부를 파기하고 검증자 네트워크에서 해당 검증자를 제거하는 결과를 낳습니다. 이 과정은 36일이 걸립니다. 1일 차에는 최대 1 ETH의 초기 페널티가 부과됩니다. 그런 다음 슬래싱된 검증자의 이더는 종료 기간에 걸쳐 서서히 빠져나가지만, 18일 차에는 "상관관계 페널티(correlation penalty)"를 받게 되며, 이는 비슷한 시기에 더 많은 검증자가 슬래싱될수록 커집니다. 최대 페널티는 전체 스테이크입니다. 이러한 보상과 처벌은 정직한 검증자에게 인센티브를 제공하고 네트워크에 대한 공격을 억제하도록 설계되었습니다. ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/gasper/#inactivity-leak) 비활동 누수 Gasper는 보안뿐만 아니라 "그럴듯한 활성도(plausible liveness)"도 제공합니다. 이는 전체 스테이킹된 이더의 3분의 2가 정직하게 투표하고 프로토콜을 따르는 한, 다른 활동(공격, 지연 문제 또는 슬래싱 등)과 관계없이 체인이 완결될 수 있는 조건입니다. 다른 말로 하면, 체인이 완결되는 것을 막으려면 전체 스테이킹된 이더의 3분의 1이 어떻게든 손상되어야 합니다. Gasper에는 활성도 실패에 대한 추가적인 방어선인 "비활동 누수"가 있습니다. 이 메커니즘은 체인이 4 에포크 이상 완결되지 못할 때 활성화됩니다. 다수 체인을 적극적으로 증명하지 않는 검증자는 다수가 전체 스테이크의 3분의 2를 회복할 때까지 스테이크가 점진적으로 빠져나가게 되며, 이를 통해 활성도 실패가 일시적인 현상에 그치도록 보장합니다. ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) 포크 선택 캐스퍼 FFG의 원래 정의에는 `follow the chain containing the justified checkpoint that has the greatest height` 규칙을 부과하는 포크 선택 알고리즘이 포함되어 있었으며, 여기서 높이는 제네시스 블록으로부터의 가장 큰 거리로 정의됩니다. Gasper에서는 원래의 포크 선택 규칙이 더 이상 사용되지 않으며, 엘엠디 고스트(LMD-GHOST)라는 더 정교한 알고리즘이 사용됩니다. 정상적인 조건에서는 포크 선택 규칙이 불필요하다는 점을 인식하는 것이 중요합니다. 모든 슬롯에는 단일 블록 제안자가 있으며 정직한 검증자가 이를 증명합니다. 대규모 네트워크 비동기성이 발생하거나 부정직한 블록 제안자가 모순된 행동을 한 경우에만 포크 선택 알고리즘이 필요합니다. 그러나 이러한 경우가 발생할 때 포크 선택 알고리즘은 올바른 체인을 보호하는 중요한 방어 수단입니다. LMD-GHOST는 "최근 메시지 기반 탐욕적 가장 무거운 관찰된 하위 트리(latest message-driven greedy heaviest observed sub-tree)"의 약자입니다. 이는 누적된 증명 가중치가 가장 큰 포크를 표준 포크로 선택하고(탐욕적 가장 무거운 하위 트리), 검증자로부터 여러 메시지가 수신된 경우 가장 최근의 메시지만 고려하는(최근 메시지 기반) 알고리즘을 정의하는 전문 용어가 많은 표현입니다. 가장 무거운 블록을 표준 체인에 추가하기 전에 모든 검증자는 이 규칙을 사용하여 각 블록을 평가합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/gasper/#further-reading) 추가 자료 -------------------------------------------------------------------------------------------------- * [Gasper: GHOST와 Casper의 결합 (새 탭에서 열림)](https://arxiv.org/pdf/2003.03052.pdf) * [캐스퍼 FFG(Casper the Friendly Finality Gadget) (새 탭에서 열림)](https://arxiv.org/pdf/1710.09437.pdf) --- # 이더리움 스택 소개 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/ethereum-stack/#main-content) Change page 이더리움 스택 소개 ========== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/ethereum-stack/index.md) 이 페이지의 내용 다른 소프트웨어 스택과 마찬가지로, 완전한 "이더리움 스택"은 목표에 따라 프로젝트마다 다릅니다. 하지만 소프트웨어 애플리케이션이 이더리움 블록체인과 상호 작용하는 방식에 대한 멘탈 모델을 제공하는 이더리움의 핵심 구성 요소가 있습니다. 스택의 계층을 이해하면 이더리움이 소프트웨어 프로젝트에 통합될 수 있는 다양한 방법을 이해하는 데 도움이 됩니다. [](https://ethereum.org/ko/developers/docs/ethereum-stack/#ethereum-virtual-machine) 레벨 1: 이더리움 가상 머신 ----------------------------------------------------------------------------------------------------- [이더리움 가상 머신(EVM)](https://ethereum.org/ko/developers/docs/evm/) 은 이더리움의 스마트 컨트랙트를 위한 런타임 환경입니다. 이더리움 블록체인의 모든 스마트 컨트랙트와 상태 변경은 [트랜잭션](https://ethereum.org/ko/developers/docs/transactions/) 에 의해 실행됩니다. EVM은 이더리움 네트워크의 모든 트랜잭션 처리를 담당합니다. 다른 가상 머신과 마찬가지로 EVM은 실행 중인 코드와 실행 중인 머신(이더리움 노드) 사이에 추상화 계층을 만듭니다. 현재 EVM은 전 세계에 분산된 수천 개의 노드에서 실행되고 있습니다. 내부적으로 EVM은 특정 작업을 실행하기 위해 일련의 연산 코드 명령을 사용합니다. 이러한 (140개의 고유한) 연산 코드를 통해 EVM은 [튜링 완전(Turing-complete) (새 탭에서 열림)](https://en.wikipedia.org/wiki/Turing_completeness) 해지며, 이는 충분한 리소스가 주어지면 EVM이 거의 모든 것을 계산할 수 있음을 의미합니다. 탈중앙화 애플리케이션(dapp) 개발자로서 EVM에 대해 알아야 할 것은 EVM이 존재하며 다운타임 없이 이더리움의 모든 애플리케이션을 안정적으로 구동한다는 사실뿐입니다. [](https://ethereum.org/ko/developers/docs/ethereum-stack/#smart-contracts) 레벨 2: 스마트 컨트랙트 ------------------------------------------------------------------------------------------ [스마트 컨트랙트](https://ethereum.org/ko/developers/docs/smart-contracts/) 는 이더리움 블록체인에서 실행되는 실행 가능한 프로그램입니다. 스마트 컨트랙트는 EVM 바이트코드(연산 코드라고 하는 저수준 기계어 명령)로 컴파일되는 특정 [프로그래밍 언어](https://ethereum.org/ko/developers/docs/smart-contracts/languages/) 를 사용하여 작성됩니다. 스마트 컨트랙트는 오픈 소스 라이브러리 역할을 할 뿐만 아니라, 본질적으로 항상 실행되고 중단될 수 없는 개방형 API 서비스입니다. 스마트 컨트랙트는 사용자와 애플리케이션([탈중앙화 애플리케이션(dapp)](https://ethereum.org/ko/developers/docs/dapps/) )이 권한 없이 상호 작용할 수 있는 퍼블릭 함수를 제공합니다. 모든 애플리케이션은 배포된 스마트 컨트랙트와 통합하여 [데이터 피드](https://ethereum.org/ko/developers/docs/oracles/) 를 추가하거나 토큰 스왑을 지원하는 등의 기능을 구성할 수 있습니다. 또한 누구나 애플리케이션의 요구 사항을 충족하는 사용자 지정 기능을 추가하기 위해 이더리움에 새로운 스마트 컨트랙트를 배포할 수 있습니다. 탈중앙화 애플리케이션(dapp) 개발자로서 이더리움 블록체인에 사용자 지정 기능을 추가하려는 경우에만 스마트 컨트랙트를 작성하면 됩니다. 예를 들어 스테이블코인 결제를 지원하거나 토큰의 탈중앙화된 교환을 활성화하려는 경우, 기존 스마트 컨트랙트와 통합하는 것만으로도 프로젝트 요구 사항의 대부분 또는 전부를 달성할 수 있습니다. [](https://ethereum.org/ko/developers/docs/ethereum-stack/#ethereum-nodes) 레벨 3: 이더리움 노드 ---------------------------------------------------------------------------------------- 애플리케이션이 이더리움 블록체인과 상호 작용하려면 [이더리움 노드](https://ethereum.org/ko/developers/docs/nodes-and-clients/) 에 연결해야 합니다. 노드에 연결하면 블록체인 데이터를 읽거나 네트워크에 트랜잭션을 보낼 수 있습니다. 이더리움 노드는 소프트웨어, 즉 이더리움 클라이언트를 실행하는 컴퓨터입니다. 클라이언트는 각 블록의 모든 트랜잭션을 검증하여 네트워크를 안전하게 유지하고 데이터를 정확하게 유지하는 이더리움의 구현체입니다. **이더리움 노드가 곧 이더리움 블록체인입니다**. 이들은 집단적으로 이더리움 블록체인의 상태를 저장하고 블록체인 상태를 변경하기 위한 트랜잭션에 대해 합의에 도달합니다. 애플리케이션을 이더리움 노드에 연결하면([JSON-RPC API](https://ethereum.org/ko/developers/docs/apis/json-rpc/) 를 통해), 애플리케이션은 블록체인에서 데이터(예: 사용자 계정 잔액)를 읽을 수 있을 뿐만 아니라 네트워크에 새로운 트랜잭션(예: 사용자 계정 간 ETH 전송 또는 스마트 컨트랙트 함수 실행)을 브로드캐스트할 수 있습니다. [](https://ethereum.org/ko/developers/docs/ethereum-stack/#ethereum-client-apis) 레벨 4: 이더리움 클라이언트 API ----------------------------------------------------------------------------------------------------- (이더리움의 오픈 소스 커뮤니티에서 구축하고 유지 관리하는) 많은 편의성 라이브러리를 통해 애플리케이션이 이더리움 블록체인에 연결하고 통신할 수 있습니다. 사용자 대면 애플리케이션이 웹 앱인 경우, 프론트엔드에서 직접 [JavaScript API](https://ethereum.org/ko/developers/docs/apis/javascript/) 를 `npm install`할 수 있습니다. 또는 [Python](https://ethereum.org/ko/developers/docs/programming-languages/python/) 이나 [Java](https://ethereum.org/ko/developers/docs/programming-languages/java/) API를 사용하여 서버 측에서 이 기능을 구현하도록 선택할 수도 있습니다. 이러한 API가 스택의 필수 요소는 아니지만, 이더리움 노드와 직접 상호 작용하는 복잡성의 상당 부분을 추상화합니다. 또한 유틸리티 함수(예: ETH를 Gwei로 변환)를 제공하므로 개발자는 이더리움 클라이언트의 복잡성을 다루는 데 드는 시간을 줄이고 애플리케이션에 특화된 기능에 더 많은 시간을 집중할 수 있습니다. [](https://ethereum.org/ko/developers/docs/ethereum-stack/#end-user-applications) 레벨 5: 최종 사용자 애플리케이션 ----------------------------------------------------------------------------------------------------- 스택의 최상위 레벨에는 사용자 대면 애플리케이션이 있습니다. 이는 오늘날 정기적으로 사용하고 구축하는 표준 애플리케이션으로, 주로 웹 및 모바일 앱입니다. 이러한 사용자 인터페이스를 개발하는 방식은 본질적으로 변하지 않습니다. 종종 사용자는 자신이 사용하는 애플리케이션이 블록체인을 사용하여 구축되었다는 사실을 알 필요가 없습니다. [](https://ethereum.org/ko/developers/docs/ethereum-stack/#ready-to-choose-your-stack) 스택을 선택할 준비가 되셨나요? -------------------------------------------------------------------------------------------------------- 이더리움 애플리케이션을 위한 [로컬 개발 환경 설정](https://ethereum.org/ko/developers/local-environment/) 가이드를 확인해 보세요. [](https://ethereum.org/ko/developers/docs/ethereum-stack/#further-reading) 더 읽어보기 ---------------------------------------------------------------------------------- * [웹 3.0 애플리케이션의 아키텍처 (새 탭에서 열림)](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ _도움이 된 커뮤니티 리소스를 알고 계신가요? 이 페이지를 편집하여 추가해 주세요!_ --- # Usanifu na UX katika Web3 | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/design-and-ux/#main-content) Change page Usanifu na UX katika Web3 ========================= Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/design-and-ux/index.md) Kwenye ukurasa huu Je, wewe ni mgeni katika kusanifu na Ethereum? Hapa ni mahali sahihi kwako. Jumuiya ya Ethereum imeandika rasilimali za kukutambulisha kwenye misingi ya usanifu na utafiti wa Web3. Utajifunza kuhusu dhana za msingi ambazo zinaweza kutofautiana na usanifu wa programu zingine unazozifahamu. Je, unahitaji uelewa wa kimsingi zaidi wa Web3 kwanza? Angalia [**Kitovu cha kujifunza**](https://ethereum.org/sw/learn/) . [](https://ethereum.org/sw/developers/docs/design-and-ux/#start-with-user-research) Anza na utafiti wa mtumiaji --------------------------------------------------------------------------------------------------------------- Usanifu mzuri huenda zaidi ya kuunda miingiliano ya mtumiaji inayovutia. Inahusisha kupata uelewa wa kina wa mahitaji, malengo, na mambo yanayomsukuma mtumiaji. Kwa hivyo, tunapendekeza sana kwamba wasanifu wote wachukue mchakato wa usanifu, kama vile [**mchakato wa almasi mbili (double diamond process)** (inafunguka katika kichupo kipya)](https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model)) , ili kuhakikisha kwamba kazi yao ni ya makusudi na inakusudiwa. Ikiwa unataka kuona ni changamoto zipi za UX zinazosumbua zaidi kwa sasa, angalia hii **[ramani ya masuala ya sasa ya UX (inafunguka katika kichupo kipya)](https://ethux.design/) **. * [Web3 inahitaji Watafiti na Wasanifu zaidi wa UX (inafunguka katika kichupo kipya)](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - Muhtasari wa ukomavu wa sasa wa usanifu * [Mwongozo rahisi wa Utafiti wa UX katika Web3 (inafunguka katika kichupo kipya)](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - Mwongozo rahisi wa jinsi ya kufanya utafiti * [Jinsi ya Kukaribia Maamuzi ya UX katika Web3 (inafunguka katika kichupo kipya)](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - Muhtasari mfupi wa utafiti wa kiasi na ubora na tofauti kati ya hizo mbili (video, dakika 6) * [Kuwa mtafiti wa ux katika Web3 (inafunguka katika kichupo kipya)](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - Mtazamo wa kibinafsi kuhusu jinsi ilivyo kuwa mtafiti wa UX katika Web3 [](https://ethereum.org/sw/developers/docs/design-and-ux/#research-in-web3) Tafiti katika Web3 ---------------------------------------------------------------------------------------------- Hii ni orodha iliyoratibiwa ya utafiti wa mtumiaji uliofanywa katika Web3 ambayo inaweza kusaidia katika maamuzi ya usanifu na bidhaa au kufanya kazi kama msukumo wa kufanya utafiti wako mwenyewe. | Eneo la kuzingatia | Jina | | --- | --- | | Uingizaji wa kripto | [The Reown Pulse 2024: Hisia na Matumizi ya Mtumiaji wa Kripto (inafunguka katika kichupo kipya)](https://reown.com/blog/unveiling-walletconnects-consumer-crypto-report) | | Uingizaji wa kripto | [CRADL: UX katika Sarafu-fiche (inafunguka katika kichupo kipya)](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) | | Uingizaji wa kripto | [CRADL: Uingizaji kwenye Sarafu-fiche (inafunguka katika kichupo kipya)](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) | | Uingizaji wa kripto | [Ripoti ya UX ya Bitcoin (inafunguka katika kichupo kipya)](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) | | Uingizaji wa kripto | [ConsenSys: Hali ya mtazamo wa Web3 duniani kote 2023 (inafunguka katika kichupo kipya)](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) | | Uingizaji wa kripto | [NEAR: Kuharakisha safari kuelekea kupitishwa (inafunguka katika kichupo kipya)](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) | | Uwekaji dhamana | [OpenUX: UX ya Mwendeshaji wa Nodi ya Rocket Pool (inafunguka katika kichupo kipya)](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) | | Uwekaji dhamana | [Uwekaji dhamana: Mielekeo mikuu, mambo ya kujifunza, na utabiri - Eth Staker (inafunguka katika kichupo kipya)](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) | | Uwekaji dhamana | [Uwekaji dhamana wa Programu Nyingi (inafunguka katika kichupo kipya)](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20(MAS)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) | | DAO | [Sasisho la Utafiti la DAO la 2022: Wajenzi wa DAO Wanahitaji Nini? (inafunguka katika kichupo kipya)](https://blog.aragon.org/2022-dao-research-update/) | | DeFi | [Madimbwi ya ulinzi (inafunguka katika kichupo kipya)](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) | | DeFi | [ConsenSys: Ripoti ya Utafiti wa Mtumiaji wa DeFi 2022 (inafunguka katika kichupo kipya)](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) | | Metaverse | [Metaverse: Ripoti ya Utafiti wa Mtumiaji (inafunguka katika kichupo kipya)](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) | | Metaverse | [Kwenda Safari: Kutafiti Watumiaji katika Metaverse (inafunguka katika kichupo kipya)](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube)
(video, dakika 27) | [](https://ethereum.org/sw/developers/docs/design-and-ux/#design-for-web3) Usanifu kwa ajili ya Web3 ---------------------------------------------------------------------------------------------------- * [Kitabu cha Mbinu za Usanifu wa Web3 (inafunguka katika kichupo kipya)](https://learnweb3.design/) - Mkusanyiko wa kina wa mifumo na maelezo kuhusu kanuni za UX za Web3, ruwaza za fedha zilizogatuliwa (DeFi), usanifu wa utawala, UX ya mkoba, na fikra za kiwango cha itifaki kwa wasanifu na waanzilishi * [Kitabu cha Mwongozo cha Usanifu wa UX wa Web3 (inafunguka katika kichupo kipya)](https://web3ux.design/) - Mwongozo wa vitendo wa kusanifu programu za Web3 * [Kanuni za Usanifu wa Web3 (inafunguka katika kichupo kipya)](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - Mfumo wa sheria za UX kwa programu tumizi zilizogatuliwa (dapps) zinazotegemea mnyororo wa vitalu * [Kanuni za Usanifu wa Mnyororo wa Vitalu (inafunguka katika kichupo kipya)](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - Masomo yaliyojifunzwa na timu ya usanifu wa mnyororo wa vitalu katika IBM * [Neueux.com (inafunguka katika kichupo kipya)](https://neueux.com/apps) - Maktaba ya UI ya mtiririko wa mtumiaji yenye chaguzi mbalimbali za kuchuja * [Mgogoro wa Utumiaji wa Web3: Kile UNACHOHITAJI Kujua! (inafunguka katika kichupo kipya)](https://www.youtube.com/watch?v=oBSXT_6YDzg) - Majadiliano ya jopo kuhusu mitego ya ujenzi wa miradi inayolenga wasanidi programu (video, dakika 34) [](https://ethereum.org/sw/developers/docs/design-and-ux/#getting-started) Kuanza --------------------------------------------------------------------------------- * [Heuristics kwa Web3](https://ethereum.org/sw/developers/docs/design-and-ux/heuristics-for-web3/) - Heuristics 7 za usanifu wa kiolesura cha Web3 * [Mbinu Bora za Usanifu wa DEX](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/) - Mwongozo wa kusanifu Mabadilishano Yaliyogatuliwa [](https://ethereum.org/sw/developers/docs/design-and-ux/#design-case-studies) Uchunguzi Kifani wa Usanifu wa Web3 ------------------------------------------------------------------------------------------------------------------ * [Deep Work Studio (inafunguka katika kichupo kipya)](https://www.deepwork.studio/case-studies) * [Kuuza NFT kwenye OpenSea (inafunguka katika kichupo kipya)](https://builtformars.com/case-studies/opensea) * [Uchambuzi wa UX wa mkoba jinsi mikoba inavyohitaji kubadilika (inafunguka katika kichupo kipya)](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (video, dakika 20) [](https://ethereum.org/sw/developers/docs/design-and-ux/#bounties) Zawadi za Usanifu ------------------------------------------------------------------------------------- * [Dework (inafunguka katika kichupo kipya)](https://app.dework.xyz/bounties) * [Hackathons za Buildbox (inafunguka katika kichupo kipya)](https://app.buidlbox.io/) * [Hackathons za ETHGlobal (inafunguka katika kichupo kipya)](https://ethglobal.com/) [](https://ethereum.org/sw/developers/docs/design-and-ux/#design-daos-and-communities) DAO za Usanifu na jumuiya ---------------------------------------------------------------------------------------------------------------- Jihusishe katika mashirika ya kitaalamu yanayoendeshwa na jumuiya au jiunge na vikundi vya usanifu ili kujadili mada na mielekeo inayohusiana na usanifu na utafiti na wanachama wengine. * [Vectordao.com (inafunguka katika kichupo kipya)](https://vectordao.com/) * [Deepwork.studio (inafunguka katika kichupo kipya)](https://www.deepwork.studio/) * [We3.co (inafunguka katika kichupo kipya)](https://we3.co/) * [Openux.xyz (inafunguka katika kichupo kipya)](https://openux.xyz/) [](https://ethereum.org/sw/developers/docs/design-and-ux/#design-systems-and-resources) Mifumo ya Usanifu na rasilimali zingine za usanifu ------------------------------------------------------------------------------------------------------------------------------------------ * [Usanifu wa Optimism (inafunguka katika kichupo kipya)](https://www.figma.com/@optimism) (Figma) * [Mfumo wa Usanifu wa Ethereum.org (inafunguka katika kichupo kipya)](https://www.figma.com/@ethdotorg) (Figma) * [Finity, mfumo wa usanifu na Polygon (inafunguka katika kichupo kipya)](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma) * [Mfumo wa Usanifu wa Kleros (inafunguka katika kichupo kipya)](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma) * [Mfumo wa Usanifu wa Safe (inafunguka katika kichupo kipya)](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma) * [Mfumo wa Usanifu wa ENS (inafunguka katika kichupo kipya)](https://thorin.ens.domains/) * [Mfumo wa Usanifu wa Mirror (inafunguka katika kichupo kipya)](https://degen-xyz.vercel.app/) **Makala na miradi iliyoorodheshwa kwenye ukurasa huu sio idhini rasmi**, na hutolewa kwa madhumuni ya habari pekee. Tunaongeza viungo kwenye ukurasa huu kulingana na vigezo katika [sera yetu ya uorodheshaji](https://ethereum.org/sw/contributing/design/adding-design-resources/) . Ikiwa ungependa tuongeze mradi/makala, hariri ukurasa huu kwenye [GitHub (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md) . --- # Maktaba za mkataba mahiri | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/smart-contracts/libraries/#main-content) Change page Maktaba za mkataba mahiri ========================= Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/libraries/index.md) Kwenye ukurasa huu Huhitaji kuandika kila mkataba mahiri katika mradi wako kuanzia mwanzo. Kuna maktaba nyingi za mkataba mahiri za programu huria zinazopatikana ambazo hutoa vijenzi vinavyoweza kutumika tena kwa mradi wako ambavyo vinaweza kukuokoa na usumbufu wa kurudia kazi iliyokwisha fanywa. [](https://ethereum.org/sw/developers/docs/smart-contracts/libraries/#prerequisites) Masharti --------------------------------------------------------------------------------------------- Kabla ya kuingia kwenye maktaba za mkataba mahiri, ni wazo zuri kuwa na uelewa mzuri wa muundo wa mkataba mahiri. Nenda kwenye [anatomi ya mkataba mahiri](https://ethereum.org/sw/developers/docs/smart-contracts/anatomy/) ikiwa bado hujafanya hivyo. [](https://ethereum.org/sw/developers/docs/smart-contracts/libraries/#whats-in-a-library) Nini kimo ndani ya maktaba -------------------------------------------------------------------------------------------------------------------- Kwa kawaida unaweza kupata aina mbili za vijenzi katika maktaba za mkataba mahiri: tabia zinazoweza kutumika tena unazoweza kuongeza kwenye mikataba yako, na utekelezaji wa viwango mbalimbali. ### [](https://ethereum.org/sw/developers/docs/smart-contracts/libraries/#behaviors) Tabia Unapoandika mikataba mahiri, kuna uwezekano mkubwa utajikuta ukiandika ruwaza zinazofanana mara kwa mara, kama vile kukabidhi anwani ya _msimamizi_ ili kutekeleza shughuli zilizolindwa katika mkataba, au kuongeza kitufe cha _kusitisha_ cha dharura endapo kutatokea suala lisilotarajiwa. Maktaba za mkataba mahiri kwa kawaida hutoa utekelezaji unaoweza kutumika tena wa tabia hizi kama [maktaba (inafunguka katika kichupo kipya)](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) au kupitia [urithi (inafunguka katika kichupo kipya)](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance) katika Solidity. Kama mfano, ifuatayo ni toleo lililorahisishwa la [mkataba wa `Ownable` (inafunguka katika kichupo kipya)](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) kutoka kwenye [maktaba ya Mikataba ya OpenZeppelin (inafunguka katika kichupo kipya)](https://github.com/OpenZeppelin/openzeppelin-contracts) , ambayo huteua anwani kama mmiliki wa mkataba, na kutoa kirekebishaji cha kuzuia ufikiaji wa mbinu kwa mmiliki huyo pekee. contract Ownable { address public owner; constructor() internal { owner = msg.sender; } modifier onlyOwner() { require(owner == msg.sender, "Ownable: caller is not the owner"); _; } } NakiliSolidity Onyesha yote (12) Ili kutumia kijenzi kama hiki katika mkataba wako, utahitaji kwanza kukiingiza, na kisha kukipanua katika mikataba yako mwenyewe. Hii itakuruhusu kutumia kirekebishaji kilichotolewa na mkataba wa msingi wa `Ownable` ili kulinda vipengele vyako mwenyewe. import ".../Ownable.sol"; // Njia ya maktaba iliyoingizwa contract MyContract is Ownable { // Kazi ifuatayo inaweza kuitwa tu na mmiliki function secured() onlyOwner public { msg.sender.transfer(1 ether); } } NakiliSolidity Mfano mwingine maarufu ni [SafeMath (inafunguka katika kichupo kipya)](https://docs.openzeppelin.com/contracts/3.x/utilities#math) au [DsMath (inafunguka katika kichupo kipya)](https://dappsys.readthedocs.io/en/latest/ds_math.html) . Hizi ni maktaba (tofauti na mikataba ya msingi) ambazo hutoa vipengele vya hesabu na ukaguzi wa mzidio, ambazo hazitolewi na lugha. Ni utendaji mzuri kutumia mojawapo ya maktaba hizi badala ya shughuli za asili za hesabu ili kulinda mkataba wako dhidi ya mizidio, ambayo inaweza kuwa na matokeo mabaya sana! ### [](https://ethereum.org/sw/developers/docs/smart-contracts/libraries/#standards) Viwango Ili kuwezesha [utangamano na mwingiliano](https://ethereum.org/sw/developers/docs/smart-contracts/composability/) , jumuiya ya Ethereum imefafanua viwango kadhaa katika mfumo wa **ERCs**. Unaweza kusoma zaidi kuzihusu katika sehemu ya [viwango](https://ethereum.org/sw/developers/docs/standards/) . Unapojumuisha ERC kama sehemu ya mikataba yako, ni wazo zuri kutafuta utekelezaji wa kiwango badala ya kujaribu kuunda chako mwenyewe. Maktaba nyingi za mkataba mahiri zinajumuisha utekelezaji wa ERCs maarufu zaidi. Kwa mfano, [kiwango cha tokheni mbadala cha ERC-20](https://ethereum.org/sw/developers/tutorials/understand-the-erc-20-token-smart-contract/) kilichoenea kila mahali kinaweza kupatikana katika [HQ20 (inafunguka katika kichupo kipya)](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md) , [DappSys (inafunguka katika kichupo kipya)](https://github.com/dapphub/ds-token/) na [OpenZeppelin (inafunguka katika kichupo kipya)](https://docs.openzeppelin.com/contracts/3.x/erc20) . Zaidi ya hayo, baadhi ya ERCs pia hutoa utekelezaji wa kikanoniki kama sehemu ya ERC yenyewe. Inafaa kutaja kwamba baadhi ya ERCs hazijitegemei, bali ni nyongeza kwa ERCs nyingine. Kwa mfano, [ERC-2612 (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-2612) inaongeza kiendelezi kwenye ERC-20 kwa ajili ya kuboresha utumizi wake. [](https://ethereum.org/sw/developers/docs/smart-contracts/libraries/#how-to) Jinsi ya kuongeza maktaba ------------------------------------------------------------------------------------------------------- Daima rejelea nyaraka za maktaba unayojumuisha kwa maagizo maalum ya jinsi ya kuijumuisha katika mradi wako. Maktaba kadhaa za mkataba wa Solidity zimefungashwa kwa kutumia `npm`, kwa hivyo unaweza tu kuzi-`npm install`. Zana nyingi za [ukusanyaji](https://ethereum.org/sw/developers/docs/smart-contracts/compiling/) wa mikataba zitaangalia kwenye `node_modules` yako kwa ajili ya maktaba za mkataba mahiri, kwa hivyo unaweza kufanya yafuatayo: // Hii itapakia maktaba ya @openzeppelin/contracts kutoka kwenye node_modules yako import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; contract MyNFT is ERC721 { constructor() ERC721("MyNFT", "MNFT") public { } } NakiliSolidity Bila kujali mbinu unayotumia, unapojumuisha maktaba, daima zingatia toleo la [lugha](https://ethereum.org/sw/developers/docs/smart-contracts/languages/) . Kwa mfano, huwezi kutumia maktaba ya Solidity 0.6 ikiwa unaandika mikataba yako katika Solidity 0.5. [](https://ethereum.org/sw/developers/docs/smart-contracts/libraries/#when-to-use) Wakati wa kutumia ---------------------------------------------------------------------------------------------------- Kutumia maktaba ya mkataba mahiri kwa mradi wako kuna faida kadhaa. Kwanza kabisa, inakuokoa muda kwa kukupa vijenzi vilivyo tayari kutumika unavyoweza kujumuisha katika mfumo wako, badala ya kulazimika kuziandika mwenyewe. Usalama pia ni faida kubwa. Maktaba za mkataba mahiri za programu huria pia mara nyingi huchunguzwa kwa kina. Kwa kuwa miradi mingi inazitegemea, kuna motisha kubwa kwa jumuiya kuziweka chini ya ukaguzi wa mara kwa mara. Ni kawaida zaidi kupata makosa katika msimbo wa programu kuliko katika maktaba za mkataba zinazoweza kutumika tena. Baadhi ya maktaba pia hupitia [ukaguzi wa nje (inafunguka katika kichupo kipya)](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits) kwa usalama wa ziada. Hata hivyo, kutumia maktaba za mkataba mahiri hubeba hatari ya kujumuisha msimbo usioufahamu kwenye mradi wako. Inashawishi kuingiza mkataba na kuujumuisha moja kwa moja kwenye mradi wako, lakini bila uelewa mzuri wa kile mkataba huo unafanya, unaweza kuwa unaingiza suala kwenye mfumo wako bila kukusudia kutokana na tabia isiyotarajiwa. Daima hakikisha unasoma nyaraka za msimbo unaoingiza, na kisha ukague msimbo wenyewe kabla ya kuufanya kuwa sehemu ya mradi wako! Mwisho, unapoamua kama utajumuisha maktaba, zingatia matumizi yake kwa ujumla. Ile iliyopitishwa na wengi ina faida za kuwa na jumuiya kubwa na macho mengi yanayoiangalia kwa ajili ya masuala. Usalama unapaswa kuwa lengo lako kuu unapounda kwa mikataba mahiri! [](https://ethereum.org/sw/developers/docs/smart-contracts/libraries/#related-tools) Zana zinazohusiana ------------------------------------------------------------------------------------------------------- **Mikataba ya OpenZeppelin -** **_Maktaba maarufu zaidi kwa uundaji salama wa mkataba mahiri._** * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.openzeppelin.com/contracts/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/OpenZeppelin/openzeppelin-contracts) * [Jukwaa la Jumuiya (inafunguka katika kichupo kipya)](https://forum.openzeppelin.com/c/general/16) **DappSys -** **_Vijenzi salama, rahisi, na vinavyobadilika kwa mikataba mahiri._** * [Nyaraka (inafunguka katika kichupo kipya)](https://dappsys.readthedocs.io/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/dapphub/dappsys) **HQ20 -** **_Mradi wa Solidity wenye mikataba, maktaba na mifano ya kukusaidia kuunda programu zilizosambazwa zenye vipengele kamili kwa ulimwengu wa kweli._** * [GitHub (inafunguka katika kichupo kipya)](https://github.com/HQ20/contracts) **thirdweb Solidity SDK -** **_Hutoa zana zinazohitajika ili kuunda mikataba mahiri maalum kwa ufanisi_** * [Nyaraka (inafunguka katika kichupo kipya)](https://portal.thirdweb.com/contracts/build/overview) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/thirdweb-dev/contracts) [](https://ethereum.org/sw/developers/docs/smart-contracts/libraries/#related-tutorials) Mafunzo yanayohusiana -------------------------------------------------------------------------------------------------------------- * [Mazingatio ya usalama kwa waundaji wa Ethereum](https://ethereum.org/sw/developers/docs/smart-contracts/security/) _– Mafunzo kuhusu mazingatio ya usalama wakati wa kuunda mikataba mahiri, ikijumuisha matumizi ya maktaba._ * [Elewa mkataba mahiri wa tokeni ya ERC-20](https://ethereum.org/sw/developers/tutorials/understand-the-erc-20-token-smart-contract/) _\-Mafunzo kuhusu kiwango cha ERC-20, kinachotolewa na maktaba nyingi._ [](https://ethereum.org/sw/developers/docs/smart-contracts/libraries/#further-reading) Usomaji zaidi ---------------------------------------------------------------------------------------------------- _Unajua rasilimali ya jumuiya iliyokusaidia? Hariri ukurasa huu na uiongeze!_ --- # 弱い主観性 | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/weak-subjectivity/#main-content) Change page 弱い主観性 ===== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md) このページの内容 ブロックチェーンにおける主観性とは、現在の状態について合意するために社会的な情報に依存することを指します。ネットワーク上の他のピアから収集した情報に基づいて選択される、複数の有効なフォークが存在する場合があります。その逆は客観性であり、コード化されたルールを適用することで、すべてのノードが必然的に合意する唯一の有効なチェーンが存在するチェーンを指します。また、弱い主観性として知られる第3の状態もあります。これは、初期の情報のシードが社会的に取得された後、客観的に進行できるチェーンを指します。 [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/weak-subjectivity/#prerequisites) 前提条件 ---------------------------------------------------------------------------------------------------------- このページを理解するには、まず[プルーフ・オブ・ステーク (PoS)](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/) の基礎を理解する必要があります。 [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/weak-subjectivity/#problems-ws-solves) 弱い主観性はどのような問題を解決するのか？ -------------------------------------------------------------------------------------------------------------------------------- 複数のフォークから正しいチェーンを選択することは過去の投票を数えることによって行われるため、主観性はプルーフ・オブ・ステーク (PoS) ブロックチェーンに固有のものです。これにより、ブロックチェーンはいくつかの攻撃ベクトルの危険にさらされます。これには、チェーンの非常に初期に参加したノードが代替のフォークを維持し、後になって自分たちに有利になるようにそれを公開する長距離攻撃が含まれます。あるいは、バリデータの33%がステークを引き出しつつも、証明とブロックの生成を続ける場合、正規のチェーンと競合する代替のフォークを生成する可能性があります。新しいノードや長期間オフラインだったノードは、これらの攻撃を行っているバリデータが資金を引き出したことに気づかない可能性があるため、攻撃者は彼らを騙して誤ったチェーンに従わせることができます。[イーサリアム](https://ethereum.org/ja/) は、メカニズムの主観的な側面、つまりトラスト前提を最小限に抑える制約を課すことで、これらの攻撃ベクトルを解決できます。 [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/weak-subjectivity/#ws-checkpoints) 弱い主観性のチェックポイント --------------------------------------------------------------------------------------------------------------------- 弱い主観性は、「弱い主観性のチェックポイント」を使用することで、プルーフ・オブ・ステーク (PoS) イーサリアムに実装されています。これらは、ネットワーク上のすべてのノードが正規のチェーンに属することに合意した状態ルートです。これらは、ブロックチェーンのジェネシス位置にないことを除けば、ジェネシスブロックと同じ「普遍的な真実」の目的を果たします。フォーク選択アルゴリズムは、そのチェックポイントで定義されたブロックチェーンの状態が正しいことを信頼し、その時点以降のチェーンを独立して客観的に検証します。弱い主観性のチェックポイントより前にあるブロックは変更できないため、チェックポイントは「リバートの制限」として機能します。これは、メカニズム設計の一部として長距離フォークを無効と定義するだけで、長距離攻撃を弱体化させます。弱い主観性のチェックポイントがバリデータの引き出し期間よりも短い間隔で分離されていることを保証することで、チェーンをフォークするバリデータは、ステークを引き出す前に少なくとも一定のしきい値の量だけスラッシングされることが保証されます。また、ステークを引き出したバリデータによって、新規参入者が誤ったフォークに騙されることも防ぎます。 [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/weak-subjectivity/#difference-between-ws-and-finalized-blocks) 弱い主観性のチェックポイントとファイナライズ済みブロックの違い ------------------------------------------------------------------------------------------------------------------------------------------------------------------ ファイナライズ済みブロックと弱い主観性のチェックポイントは、イーサリアムのノードによって異なる扱いを受けます。ノードが競合する2つのファイナライズ済みブロックを認識した場合、ノードは2つの間で板挟みになります。どちらが正規のフォークであるかを自動的に識別する方法はありません。これはコンセンサスの失敗の兆候です。対照的に、ノードは弱い主観性のチェックポイントと競合するブロックを単に拒否します。ノードの観点からは、弱い主観性のチェックポイントは、ピアからの新しい知識によって損なわれることのない絶対的な真実を表しています。 [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/weak-subjectivity/#how-weak-is-weak) どの程度「弱い」のか？ -------------------------------------------------------------------------------------------------------------------- イーサリアムのプルーフ・オブ・ステーク (PoS) の主観的な側面は、同期の起点となる信頼できるソースからの最近の状態 (弱い主観性のチェックポイント) が必要であるという点です。ブロック・エクスプローラーや複数のノードなど、いくつかの独立した公開ソースと照合できるため、不正な弱い主観性のチェックポイントを取得するリスクは非常に低いです。ただし、ソフトウェア開発者が誠実なソフトウェアを作成したと信頼するなど、ソフトウェアアプリケーションを実行するには常に一定の信頼が必要です。 弱い主観性のチェックポイントは、クライアントソフトウェアの一部として提供されることさえあります。間違いなく、攻撃者はソフトウェア内のチェックポイントを改ざんでき、同様にソフトウェア自体も簡単に改ざんできます。この問題を回避する現実的な暗号経済学的な手段はありませんが、イーサリアムでは、それぞれが異なる言語で同等のソフトウェアを構築し、誠実なチェーンを維持することに既得権益を持つ複数の独立したクライアントチームが存在することで、信頼できない開発者の影響は最小限に抑えられています。ブロック・エクスプローラーも、弱い主観性のチェックポイントを提供したり、他の場所から取得したチェックポイントを追加のソースと相互参照する方法を提供したりする場合があります。 最後に、チェックポイントは他のノードにリクエストすることもできます。おそらく、フル・ノードを実行している別のイーサリアムユーザーがチェックポイントを提供し、バリデータはそれをブロック・エクスプローラーのデータと照合して検証できます。全体として、弱い主観性のチェックポイントの提供者を信頼することは、クライアント開発者を信頼することと同じくらい問題になり得ると考えられます。全体として必要な信頼の度合いは低いです。これらの考慮事項は、バリデータの過半数が共謀してブロックチェーンの代替フォークを生成するという、極めて起こりにくい事態においてのみ重要になることに注意することが重要です。それ以外の状況では、選択できるイーサリアムのチェーンは1つしかありません。 [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/weak-subjectivity/#further-reading) 参考文献 ------------------------------------------------------------------------------------------------------------ * [Eth2における弱い主観性 （新しいタブで開きます）](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) * [ヴィタリック: 私はいかにして弱い主観性を愛するようになったか （新しいタブで開きます）](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity) * [弱い主観性 (テクのドキュメント) （新しいタブで開きます）](https://docs.teku.consensys.io/concepts/weak-subjectivity) * [フェーズ0 弱い主観性ガイド （新しいタブで開きます）](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/weak-subjectivity.md) * [イーサリアム2.0における弱い主観性の分析 （新しいタブで開きます）](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) --- # Kanuni 7 za muundo wa kiolesura cha Web3 | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/design-and-ux/heuristics-for-web3/#main-content) Change page Kanuni 7 za muundo wa kiolesura cha Web3 ======================================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/design-and-ux/heuristics-for-web3/index.md) Kwenye ukurasa huu Kanuni za utumiaji ni "kanuni za msingi" pana ambazo unaweza kutumia kupima utumiaji wa tovuti yako. Kanuni 7 hapa zimeundwa mahususi kwa ajili ya Web3 na zinapaswa kutumiwa pamoja na [kanuni 10 za jumla za muundo wa mwingiliano (inafunguka katika kichupo kipya)](https://www.nngroup.com/articles/ten-usability-heuristics/) za Jakob Nielsen. [](https://ethereum.org/sw/developers/docs/design-and-ux/heuristics-for-web3/#seven-usability-heuristics-for-web3) Kanuni saba za utumiaji kwa Web3 --------------------------------------------------------------------------------------------------------------------------------------------------- 1. Mrejesho hufuata kitendo 2. Usalama na uaminifu 3. Taarifa muhimu zaidi ni dhahiri 4. Istilahi zinazoeleweka 5. Vitendo ni vifupi iwezekanavyo 6. Miunganisho ya mtandao inaonekana na inabadilika 7. Udhibiti kutoka kwenye programu, si kwenye mkoba [](https://ethereum.org/sw/developers/docs/design-and-ux/heuristics-for-web3/#definitions-and-examples) Ufafanuzi na mifano --------------------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/sw/developers/docs/design-and-ux/heuristics-for-web3/#feedback-follows-action) 1\. Mrejesho hufuata kitendo **Inapaswa kuwa dhahiri wakati jambo limetokea, au linatokea.** Watumiaji huamua hatua zao zinazofuata kulingana na matokeo ya hatua zao za awali. Kwa hivyo ni muhimu kwamba waendelee kufahamishwa kuhusu hali ya mfumo. Hili ni muhimu hasa katika Web3 kwani miamala wakati mwingine inaweza kuchukua muda mfupi kuthibitishwa kwenye mnyororo wa vitalu. Ikiwa hakuna mrejesho unaowajulisha kusubiri, watumiaji hawana uhakika kama kuna chochote kimetokea. **Vidokezo:** * Mjulishe mtumiaji kupitia ujumbe, arifa, na tahadhari nyingine. * Wasilisha muda wa kusubiri kwa uwazi. * Ikiwa kitendo kitachukua muda mrefu zaidi ya sekunde chache, mhakikishie mtumiaji kwa kipima muda au uhuishaji ili kumfanya ahisi kama kuna kitu kinatokea. * Ikiwa kuna hatua nyingi kwenye mchakato, onyesha kila hatua. **Mfano:** Kuonyesha kila hatua inayohusika katika muamala huwasaidia watumiaji kujua wako wapi katika mchakato. Aikoni zinazofaa humjulisha mtumiaji hali ya vitendo vyao. [![Informing the user about each step when swapping tokens](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage1.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image1.png) ### [](https://ethereum.org/sw/developers/docs/design-and-ux/heuristics-for-web3/#security-and-trust-are-backed-in) 2\. Usalama na uaminifu vimejumuishwa Usalama unapaswa kupewa kipaumbele, na hili linapaswa kusisitizwa kwa mtumiaji. Watu wanajali sana data zao. Usalama mara nyingi ni jambo la msingi kwa watumiaji, kwa hivyo unapaswa kuzingatiwa katika viwango vyote vya muundo. Unapaswa daima kutafuta kupata uaminifu wa watumiaji wako, lakini njia unayofanya hivi inaweza kumaanisha mambo tofauti kwenye programu tofauti. Haipaswi kuwa jambo la kufikiria baadaye, bali inapaswa kuundwa kwa uangalifu kote. Jenga uaminifu katika matumizi yote ya mtumiaji, ikijumuisha njia za kijamii na nyaraka, pamoja na kiolesura cha mwisho cha mtumiaji (UI). Mambo kama vile kiwango cha ugatuzi, hali ya saini nyingi ya hazina, na kama timu inajulikana hadharani (doxxed), yote huathiri uaminifu wa watumiaji **Vidokezo:** * Orodhesha ukaguzi wako kwa fahari * Pata ukaguzi mwingi * Tangaza vipengele vyovyote vya usalama ulivyounda * Angazia hatari zinazowezekana, ikijumuisha miunganisho ya msingi * Wasilisha ugumu wa mikakati * Fikiria masuala yasiyo ya UI ambayo yanaweza kuathiri mtazamo wa watumiaji wako kuhusu usalama **Mfano:** Jumuisha ukaguzi wako kwenye sehemu ya chini ya ukurasa, kwa ukubwa unaoonekana wazi. [![Audits referenced in the website footer](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage2.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image2.png) ### [](https://ethereum.org/sw/developers/docs/design-and-ux/heuristics-for-web3/#the-most-important-info-is-obvious) 3\. Taarifa muhimu zaidi ni dhahiri Kwa mifumo changamano, onyesha tu data muhimu zaidi. Tambua kile ambacho ni muhimu zaidi, na upe kipaumbele onyesho lake. Taarifa nyingi sana hulemea na watumiaji kwa kawaida hutegemea kipande kimoja cha taarifa wanapofanya maamuzi. Katika fedha zilizogatuliwa (DeFi), hii labda itakuwa APR kwenye programu za mapato na LTV kwenye programu za ukopeshaji. **Vidokezo:** * Utafiti wa mtumiaji utafichua kipimo muhimu zaidi * Fanya taarifa kuu iwe kubwa, na maelezo mengine yawe madogo na yasiyoingilia * Watu hawasomi, wanapitia haraka; hakikisha muundo wako unaweza kupitiwa haraka **Mfano:** Tokeni kubwa zenye rangi kamili ni rahisi kupata unapopitia haraka. APR ni kubwa na imeangaziwa kwa rangi ya msisitizo. [![The token and APR are easy to find](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage3.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image3.png) ### [](https://ethereum.org/sw/developers/docs/design-and-ux/heuristics-for-web3/#clear-terminology) 4\. Istilahi zilizo wazi Istilahi zinapaswa kueleweka na kufaa. Lugha ya kitaalamu inaweza kuwa kikwazo kikubwa, kwa sababu inahitaji ujenzi wa muundo mpya kabisa wa kiakili. Watumiaji wanashindwa kuhusisha muundo na maneno, virai na dhana wanazozijua tayari. Kila kitu kinaonekana kutatanisha na kigeni, na kuna mchakato mgumu wa kujifunza kabla hata hawajajaribu kuitumia. Watumiaji wanaweza kukaribia fedha zilizogatuliwa (DeFi) wakitaka kuweka akiba ya pesa, na kile wanachokipata ni: Uchimbaji, ukulima, uwekaji dhamana, utoaji, hongo, vaults, makabati, veTokens, umilikishaji wa kimuda, epochs, algoriti zilizogatuliwa, ukwasi unaomilikiwa na itifaki… Jaribu kutumia maneno rahisi yatakayoeleweka na kundi kubwa zaidi la watu. Usibuni maneno mapya kabisa kwa ajili ya mradi wako tu. **Vidokezo:** * Tumia istilahi rahisi na thabiti * Tumia lugha iliyopo kadiri iwezekanavyo * Usibuni maneno yako mwenyewe * Fuata taratibu zinavyoonekana * Waelimishe watumiaji kadiri iwezekanavyo **Mfano:** "Zawadi zako" ni neno linaloeleweka kwa mapana, lisiloegemea upande wowote; si neno jipya lililoundwa kwa ajili ya mradi huu. Zawadi hizo zimetajwa kwa USD ili kuendana na miundo ya kiakili ya ulimwengu halisi, hata kama zawadi zenyewe ziko katika tokeni nyingine. [![Token rewards, displayed in U.S. dollars](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage4.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image4.png) ### [](https://ethereum.org/sw/developers/docs/design-and-ux/heuristics-for-web3/#actions-are-as-short-as-possible) 5\. Vitendo ni vifupi iwezekanavyo Harakisha mwingiliano wa mtumiaji kwa kupanga vitendo vidogo. Hili linaweza kufanywa katika kiwango cha mkataba mahiri, pamoja na UI. Mtumiaji hapaswi kulazimika kuhama kutoka sehemu moja ya mfumo hadi nyingine – au kuacha mfumo kabisa – ili kukamilisha kitendo cha kawaida. **Vidokezo:** * Unganisha "Idhinisha" na vitendo vingine inapowezekana * Kusanya hatua za kusaini karibu iwezekanavyo **Mfano:** Kuunganisha "ongeza ukwasi" na "weka dhamana" ni mfano rahisi wa kichapuzi kinachomwokoa mtumiaji muda na gesi. [![Modal showing a switch to combine the deposit and stake actions](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage5.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image5.png) ### [](https://ethereum.org/sw/developers/docs/design-and-ux/heuristics-for-web3/#network-connections-are-visible-and-flexible) 6\. Miunganisho ya mtandao inaonekana na inabadilika Mjulishe mtumiaji kuhusu mtandao gani ameunganishwa nao, na utoe njia za mkato zilizo wazi za kubadilisha mtandao. Hili ni muhimu hasa kwenye programu za minyororo mingi. Kazi kuu za programu zinapaswa kuendelea kuonekana zikiwa zimetenganishwa au kuunganishwa kwenye mtandao usiotumika. **Vidokezo:** * Onyesha sehemu kubwa ya programu iwezekanavyo ukiwa umetenganishwa * Onyesha ni mtandao gani mtumiaji ameunganishwa nao kwa sasa * Usimfanye mtumiaji aende kwenye mkoba ili kubadilisha mtandao * Ikiwa programu inahitaji mtumiaji kubadilisha mtandao, himiza kitendo kutoka kwenye wito mkuu wa kuchukua hatua * Ikiwa programu ina masoko au vaults kwa mitandao mingi, eleza wazi ni seti gani mtumiaji anaiangalia kwa sasa **Mfano:** Mwonyeshe mtumiaji ni mtandao gani ameunganishwa nao, na umruhusu kuubadilisha, kwenye upau wa programu. [![Dropdown button showing the connected network](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage6.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image6.png) ### [](https://ethereum.org/sw/developers/docs/design-and-ux/heuristics-for-web3/#control-from-the-app-not-the-wallet) 7\. Udhibiti kutoka kwenye programu, si kwenye mkoba UI inapaswa kumwambia mtumiaji kila kitu anachohitaji kujua na kumpa udhibiti wa kila kitu anachohitaji kufanya. Katika Web3, kuna vitendo unavyochukua kwenye UI, na vitendo unavyochukua kwenye mkoba. Kwa ujumla, unaanzisha kitendo kwenye UI, na kisha kukithibitisha kwenye mkoba. Watumiaji wanaweza kujisikia vibaya ikiwa nyuzi hizi mbili hazijaunganishwa kwa uangalifu. **Vidokezo:** * Wasilisha hali ya mfumo kupitia mrejesho kwenye UI * Weka rekodi ya historia yao * Toa viungo vya wavinjari wa vitalu kwa miamala ya zamani * Toa njia za mkato za kubadilisha mitandao. **Mfano:** Kontena fiche humwonyesha mtumiaji ni tokeni gani husika alizonazo kwenye mkoba wake, na CTA kuu hutoa njia ya mkato ya kubadilisha mtandao. [![Main CTA is prompting the user to switch network](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage7.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image7.png) --- # Mikakati ya Kuhifadhi Data kwenye Mnyororo wa Vitalu | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/data-availability/blockchain-data-storage-strategies/#main-content) Change page Mikakati ya Kuhifadhi Data kwenye Mnyororo wa Vitalu ==================================================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-availability/blockchain-data-storage-strategies/index.md) Kwenye ukurasa huu Kuna njia nyingi za kuhifadhi taarifa moja kwa moja kwenye mnyororo wa vitalu, au kwa namna ambayo inalindwa na mnyororo wa vitalu: * Blobs za EIP-4844 * Data za mwito (Calldata) * Nje ya mnyororo na mifumo ya tabaka la 1 (l1) * "Msimbo" wa mkataba * Matukio * Hifadhi ya EVM Uchaguzi wa njia gani ya kutumia unategemea vigezo kadhaa: * Chanzo cha taarifa. Taarifa katika data za mwito haziwezi kutoka moja kwa moja kwenye mnyororo wa vitalu wenyewe. * Hatima ya taarifa. Data za mwito zinapatikana tu katika muamala unaozijumuisha. Matukio hayapatikani mnyororoni kabisa. * Ni usumbufu kiasi gani unakubalika? Kompyuta zinazoendesha nodi kamili zinaweza kufanya uchakataji zaidi kuliko kiteja chepesi katika programu inayoendeshwa kwenye kivinjari. * Je, ni lazima kuwezesha ufikiaji rahisi wa taarifa kutoka kwa kila nodi? * Mahitaji ya usalama. [](https://ethereum.org/sw/developers/docs/data-availability/blockchain-data-storage-strategies/#security-requirements) Mahitaji ya usalama ------------------------------------------------------------------------------------------------------------------------------------------- Kwa ujumla, usalama wa taarifa unajumuisha sifa tatu: * _Usiri_, vyombo visivyoidhinishwa haviruhusiwi kusoma taarifa. Hili ni muhimu katika matukio mengi, lakini si hapa. _Hakuna siri kwenye mnyororo wa vitalu_. Minyororo ya vitalu inafanya kazi kwa sababu mtu yeyote anaweza kuhakiki mabadiliko ya hali, kwa hivyo haiwezekani kuitumia kuhifadhi siri moja kwa moja. Kuna njia za kuhifadhi taarifa za siri kwenye mnyororo wa vitalu, lakini zote zinategemea kijenzi fulani cha nje ya mnyororo kuhifadhi angalau ufunguo. * _Uadilifu_, taarifa ni sahihi, haiwezi kubadilishwa na vyombo visivyoidhinishwa, au kwa njia zisizoidhinishwa (kwa mfano, kuhamisha [tokeni za ERC-20 (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-20#events) bila tukio la `Transfer`). Kwenye mnyororo wa vitalu, kila nodi huhakiki kila mabadiliko ya hali, ambayo inahakikisha uadilifu. * _Upatikanaji_, taarifa inapatikana kwa chombo chochote kilichoidhinishwa. Kwenye mnyororo wa vitalu, hii kwa kawaida hufikiwa kwa kuwa na taarifa inayopatikana kwenye kila [nodi kamili (inafunguka katika kichupo kipya)](https://ethereum.org/developers/docs/nodes-and-clients/#full-node) . Suluhu tofauti hapa zote zina uadilifu bora, kwa sababu heshi huchapishwa kwenye tabaka la 1 (l1). Hata hivyo, zina hakikisho tofauti za upatikanaji. [](https://ethereum.org/sw/developers/docs/data-availability/blockchain-data-storage-strategies/#prerequisites) Matakwa ya awali -------------------------------------------------------------------------------------------------------------------------------- Unapaswa kuwa na uelewa mzuri wa [misingi ya mnyororo wa vitalu](https://ethereum.org/sw/developers/docs/intro-to-ethereum/) . Ukurasa huu pia unachukulia kuwa msomaji anafahamu [vitalu](https://ethereum.org/sw/developers/docs/blocks/) , [miamala](https://ethereum.org/sw/developers/docs/transactions/) , na mada nyingine husika. [](https://ethereum.org/sw/developers/docs/data-availability/blockchain-data-storage-strategies/#eip-4844-blobs) Blobs za EIP-4844 ---------------------------------------------------------------------------------------------------------------------------------- Kuanzia na [hardfork ya Dencun (inafunguka katika kichupo kipya)](https://github.com/ethereum/consensus-specs/blob/master/specs/deneb/beacon-chain.md) mnyororo wa vitalu wa Ethereum unajumuisha [EIP-4844 (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-4844) , ambayo inaongeza kwenye Ethereum blobs za data zenye muda mfupi wa kuishi (awali takriban [siku 18 (inafunguka katika kichupo kipya)](https://github.com/ethereum/consensus-specs/blob/master/specs/deneb/p2p-interface.md#configuration) ). Blobs hizi zinapangiwa bei tofauti na [gesi ya utekelezaji](https://ethereum.org/sw/developers/docs/gas/) , ingawa zinatumia mfumo sawa. Ni njia ya bei nafuu ya kuchapisha data za muda. Matumizi makuu ya blobs za EIP-4844 ni kwa ajili ya mikusanyiko kuchapisha miamala yao. [Mikusanyiko ya optimistic](https://ethereum.org/sw/developers/docs/scaling/optimistic-rollups/) inahitaji kuchapisha miamala kwenye minyororo yao ya vitalu. Miamala hiyo inapaswa kupatikana kwa mtu yeyote wakati wa [kipindi cha changamoto (inafunguka katika kichupo kipya)](https://docs.optimism.io/connect/resources/glossary#challenge-period) ili kuwezesha [wathibitishaji (inafunguka katika kichupo kipya)](https://docs.optimism.io/connect/resources/glossary#validator) kurekebisha kosa ikiwa [mpangaji (inafunguka katika kichupo kipya)](https://docs.optimism.io/connect/resources/glossary#sequencer) wa rollup atachapisha mzizi wa hali usio sahihi. Hata hivyo, mara tu kipindi cha changamoto kinapopita na mzizi wa hali unakuwa umekamilishwa, dhumuni lililosalia la kujua miamala hii ni kunakili hali ya sasa ya mnyororo. Hali hii pia inapatikana kutoka kwa nodi za mnyororo, huku ikihitaji uchakataji mdogo sana. Kwa hivyo taarifa za muamala bado zinapaswa kuhifadhiwa katika sehemu chache, kama vile [vivinjari vya kitalu](https://ethereum.org/sw/developers/docs/data-and-analytics/block-explorers/) , lakini hakuna haja ya kulipia kiwango cha upinzani wa udhibiti ambacho Ethereum inatoa. [Mikusanyiko ya sifuri-maarifa](https://ethereum.org/sw/developers/docs/scaling/zk-rollups/#data-availability) pia huchapisha data zao za muamala ili kuwezesha nodi nyingine kunakili hali iliyopo na kuhakiki uthibitisho wa uhalali, lakini tena hilo ni hitaji la muda mfupi. Wakati wa kuandika, kuchapisha kwenye EIP-4844 kunagharimu Wei moja (10\-18 ETH) kwa kila baiti, ambayo ni ndogo sana ikilinganishwa na [gesi 21,000 za utekelezaji ambazo muamala wowote, ikiwa ni pamoja na ule unaochapisha blobs, unagharimu (inafunguka katika kichupo kipya)](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index) . Unaweza kuona bei ya sasa ya EIP-4844 kwenye [blobscan.com (inafunguka katika kichupo kipya)](https://blobscan.com/blocks) . Hizi hapa ni anwani za kuona blobs zilizochapishwa na baadhi ya mikusanyiko maarufu. | Rollup | Anwani ya sanduku la barua | | --- | --- | | [Optimism (inafunguka katika kichupo kipya)](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010` (inafunguka katika kichupo kipya)](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) | | [Arbitrum (inafunguka katika kichupo kipya)](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6` (inafunguka katika kichupo kipya)](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | | [Base (inafunguka katika kichupo kipya)](https://base.org/) | [`0xFF00000000000000000000000000000000008453` (inafunguka katika kichupo kipya)](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) | [](https://ethereum.org/sw/developers/docs/data-availability/blockchain-data-storage-strategies/#calldata) Data za mwito ------------------------------------------------------------------------------------------------------------------------ Data za mwito inarejelea baiti zinazotumwa kama sehemu ya muamala. Inahifadhiwa kama sehemu ya rekodi ya kudumu ya mnyororo wa vitalu katika kitalu kinachojumuisha muamala huo. Hii ndiyo njia ya bei nafuu zaidi ya kuweka data kwa kudumu kwenye mnyororo wa vitalu. Gharama kwa kila baiti ni gesi 4 za utekelezaji (ikiwa baiti ni sifuri) au gesi 16 (thamani nyingine yoyote). Ikiwa data imeshinikizwa, ambayo ni desturi ya kawaida, basi kila thamani ya baiti ina uwezekano sawa, kwa hivyo gharama ya wastani ni takriban gesi 15.95 kwa kila baiti. Wakati wa kuandika, bei ni Gwei 12/gesi na 2300 $/ETH, ambayo inamaanisha gharama ni takriban senti 45 kwa kila kilobaiti. Kwa sababu hii ilikuwa njia ya bei nafuu zaidi kabla ya EIP-4844, hii ndiyo njia ambayo mikusanyiko ilitumia kuhifadhi taarifa za muamala, ambazo zinahitaji kupatikana kwa ajili ya [changamoto za makosa (inafunguka katika kichupo kipya)](https://docs.optimism.io/stack/protocol/overview#fault-proofs) , lakini hazihitaji kupatikana moja kwa moja mnyororoni. Hizi hapa ni anwani za kuona miamala iliyochapishwa na baadhi ya mikusanyiko maarufu. | Rollup | Anwani ya sanduku la barua | | --- | --- | | [Optimism (inafunguka katika kichupo kipya)](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010` (inafunguka katika kichupo kipya)](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) | | [Arbitrum (inafunguka katika kichupo kipya)](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6` (inafunguka katika kichupo kipya)](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | | [Base (inafunguka katika kichupo kipya)](https://base.org/) | [`0xFF00000000000000000000000000000000008453` (inafunguka katika kichupo kipya)](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) | [](https://ethereum.org/sw/developers/docs/data-availability/blockchain-data-storage-strategies/#offchain-with-l1-mechs) Nje ya mnyororo na mifumo ya tabaka la 1 (l1) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- Kulingana na mabadilishano yako ya usalama, inaweza kukubalika kuweka taarifa mahali pengine na kutumia mfumo unaohakikisha data inapatikana inapohitajika. Kuna mahitaji mawili ili hili lifanye kazi: 1. Chapisha [heshi (inafunguka katika kichupo kipya)](https://en.wikipedia.org/wiki/Cryptographic_hash_function) ya data kwenye mnyororo wa vitalu, inayoitwa _ufungamanisho wa ingizo_. Hili linaweza kuwa neno moja la baiti 32, kwa hivyo si ghali. Mradi ufungamanisho wa ingizo unapatikana, uadilifu unahakikishwa kwa sababu haiwezekani kupata data nyingine yoyote ambayo ingeleta heshi ya thamani sawa. Kwa hivyo ikiwa data isiyo sahihi itatolewa, inaweza kugunduliwa. 2. Kuwa na mfumo unaohakikisha upatikanaji. Kwa mfano, katika [Redstone (inafunguka katika kichupo kipya)](https://redstone.xyz/docs/what-is-redstone) nodi yoyote inaweza kuwasilisha changamoto ya upatikanaji. Ikiwa mpangaji hatajibu mnyororoni kufikia tarehe ya mwisho, ufungamanisho wa ingizo hutupwa, kwa hivyo taarifa inachukuliwa kuwa haijawahi kuchapishwa. Hili linakubalika kwa rollup ya optimistic kwa sababu tayari tunategemea kuwa na angalau mhakiki mmoja mwaminifu kwa ajili ya mzizi wa hali. Mhakiki mwaminifu kama huyo pia atahakikisha ana data ya kuchakata vitalu, na kutoa changamoto ya upatikanaji ikiwa taarifa haipatikani nje ya mnyororo. Aina hii ya rollup ya optimistic inaitwa [Plasma](https://ethereum.org/sw/developers/docs/scaling/plasma/) . [](https://ethereum.org/sw/developers/docs/data-availability/blockchain-data-storage-strategies/#contract-code) Msimbo wa mkataba --------------------------------------------------------------------------------------------------------------------------------- Taarifa ambayo inahitaji tu kuandikwa mara moja, haifutwi kamwe, na inahitaji kupatikana mnyororoni inaweza kuhifadhiwa kama msimbo wa mkataba. Hii inamaanisha kuwa tunaunda "mkataba mahiri" na data kisha tunatumia [`EXTCODECOPY` (inafunguka katika kichupo kipya)](https://www.evm.codes/#3c?fork=shanghai) kusoma taarifa. Faida ni kwamba kunakili msimbo ni nafuu kiasi. Mbali na gharama ya upanuzi wa kumbukumbu, `EXTCODECOPY` inagharimu gesi 2600 kwa ufikiaji wa kwanza wa mkataba (unapokuwa "baridi") na gesi 100 kwa nakala zinazofuata kutoka kwa mkataba huo huo pamoja na gesi 3 kwa kila neno la baiti 32. Ikilinganishwa na data za mwito, ambayo inagharimu 15.95 kwa kila baiti, hii ni nafuu kuanzia takriban baiti 200. Kulingana na [fomula ya gharama za upanuzi wa kumbukumbu (inafunguka katika kichupo kipya)](https://www.evm.codes/about#memoryexpansion) , mradi tu huhitaji zaidi ya 4MB ya kumbukumbu, gharama ya upanuzi wa kumbukumbu ni ndogo kuliko gharama ya kuongeza data za mwito. Bila shaka, hii ni gharama tu ya _kusoma_ data. Kuunda mkataba kunagharimu takriban gesi 32,000 + gesi 200/baiti. Njia hii ni ya kiuchumi tu wakati taarifa sawa inahitaji kusomwa mara nyingi katika miamala tofauti. Msimbo wa mkataba unaweza kuwa hauna maana, mradi tu hauanzi na `0xEF`. Mikataba inayoanza na `0xEF` inatafsiriwa kama [umbizo la kipengee cha ethereum (inafunguka katika kichupo kipya)](https://notes.ethereum.org/@ipsilon/evm-object-format-overview) , ambalo lina mahitaji magumu zaidi. [](https://ethereum.org/sw/developers/docs/data-availability/blockchain-data-storage-strategies/#events) Matukio ---------------------------------------------------------------------------------------------------------------- [Matukio (inafunguka katika kichupo kipya)](https://docs.alchemy.com/docs/solidity-events) hutolewa na mikataba mahiri, na kusomwa na programu za nje ya mnyororo. Faida yake ni kwamba msimbo wa nje ya mnyororo unaweza kusikiliza matukio. Gharama ni [gesi (inafunguka katika kichupo kipya)](https://www.evm.codes/#a0?fork=cancun) , 375 pamoja na gesi 8 kwa kila baiti ya data. Kwa Gwei 12/gesi na 2300 $/ETH, hii inatafsiriwa kuwa senti moja pamoja na senti 22 kwa kila kilobaiti. [](https://ethereum.org/sw/developers/docs/data-availability/blockchain-data-storage-strategies/#storage) Hifadhi ----------------------------------------------------------------------------------------------------------------- Mikataba mahiri ina ufikiaji wa [hifadhi ya kudumu (inafunguka katika kichupo kipya)](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory) . Hata hivyo, ni ghali sana. Kuandika neno la baiti 32 kwenye sloti ya hifadhi iliyokuwa tupu hapo awali kunaweza [kugharimu gesi 22,100 (inafunguka katika kichupo kipya)](https://www.evm.codes/#55?fork=cancun) . Kwa Gwei 12/gesi na 2300 $/ETH, hii ni takriban senti 61 kwa kila operesheni ya kuandika, au $19.5 kwa kila kilobaiti. Hii ndiyo aina ghali zaidi ya hifadhi katika Ethereum. [](https://ethereum.org/sw/developers/docs/data-availability/blockchain-data-storage-strategies/#summary) Muhtasari ------------------------------------------------------------------------------------------------------------------- Jedwali hili linatoa muhtasari wa chaguzi tofauti, faida na hasara zake. | Aina ya hifadhi | Chanzo cha data | Hakikisho la upatikanaji | Upatikanaji mnyororoni | Vizuizi vya ziada | | --- | --- | --- | --- | --- | | Blobs za EIP-4844 | Nje ya mnyororo | Hakikisho la Ethereum kwa [~siku 18 (inafunguka katika kichupo kipya)](https://github.com/ethereum/consensus-specs/blob/master/specs/deneb/p2p-interface.md#configuration) | Heshi pekee ndiyo inapatikana | | | Data za mwito | Nje ya mnyororo | Hakikisho la Ethereum milele (sehemu ya mnyororo wa vitalu) | Inapatikana tu ikiwa imeandikwa kwenye mkataba, na kwenye muamala huo | | | Nje ya mnyororo na mifumo ya tabaka la 1 (l1) | Nje ya mnyororo | Hakikisho la "mhakiki mmoja mwaminifu" wakati wa kipindi cha changamoto | Heshi pekee | Imehakikishwa na mfumo wa changamoto, tu wakati wa kipindi cha changamoto | | Msimbo wa mkataba | Mnyororoni au nje ya mnyororo | Hakikisho la Ethereum milele (sehemu ya mnyororo wa vitalu) | Ndiyo | Imeandikwa kwenye anwani "nasibu", haiwezi kuanza na `0xEF` | | Matukio | Mnyororoni | Hakikisho la Ethereum milele (sehemu ya mnyororo wa vitalu) | Hapana | | | Hifadhi | Mnyororoni | Hakikisho la Ethereum milele (sehemu ya mnyororo wa vitalu na hali ya sasa hadi ifutwe na kuandikwa upya) | Ndiyo | | --- # Utangulizi wa mikataba mahiri | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/smart-contracts/#main-content) Change page Utangulizi wa mikataba mahiri ============================= Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/index.md) Kwenye ukurasa huu [](https://ethereum.org/sw/developers/docs/smart-contracts/#what-is-a-smart-contract) Mkataba mahiri ni nini? ------------------------------------------------------------------------------------------------------------- "Mkataba mahiri" ni programu tu inayoendeshwa kwenye mnyororo wa vitalu wa [Ethereum](https://ethereum.org/sw/) . Ni mkusanyiko wa msimbo (kazi zake) na data (hali yake) unaokaa kwenye anwani maalum kwenye mnyororo wa vitalu wa Ethereum. Mikataba mahiri ni aina ya [akaunti ya Ethereum](https://ethereum.org/sw/developers/docs/accounts/) . Hii inamaanisha ina salio na inaweza kuwa lengwa la miamala. Hata hivyo haidhibitiwi na mtumiaji, badala yake inasambazwa kwenye mtandao na kuendeshwa kama ilivyopangwa. Akaunti za watumiaji zinaweza kuingiliana na mkataba mahiri kwa kuwasilisha miamala inayotekeleza kazi iliyofafanuliwa kwenye mkataba mahiri. Mikataba mahiri inaweza kufafanua sheria, kama mkataba wa kawaida, na kuzitekeleza kiotomatiki kupitia msimbo. Mikataba mahiri haiwezi kufutwa kwa chaguo-msingi, na mwingiliano nayo hauwezi kutenduliwa. [](https://ethereum.org/sw/developers/docs/smart-contracts/#prerequisites) Mahitaji ya awali -------------------------------------------------------------------------------------------- Ikiwa ndio kwanza unaanza au unatafuta utangulizi usio wa kiufundi sana, tunapendekeza [utangulizi wetu wa mikataba mahiri](https://ethereum.org/sw/smart-contracts/) . Hakikisha umesoma kuhusu [akaunti](https://ethereum.org/sw/developers/docs/accounts/) , [miamala](https://ethereum.org/sw/developers/docs/transactions/) na [mashine pepe ya Ethereum](https://ethereum.org/sw/developers/docs/evm/) kabla ya kurukia ulimwengu wa mikataba mahiri. [](https://ethereum.org/sw/developers/docs/smart-contracts/#a-digital-vending-machine) Mashine ya kidijitali ya kuuza bidhaa ---------------------------------------------------------------------------------------------------------------------------- Labda sitiari bora zaidi ya mkataba mahiri ni mashine ya kuuza bidhaa, kama ilivyoelezwa na [Nick Szabo (inafunguka katika kichupo kipya)](https://unenumerated.blogspot.com/) . Kwa pembejeo sahihi, pato fulani linahakikishwa. Ili kupata kitafunwa kutoka kwenye mashine ya kuuza bidhaa: pesa + uchaguzi wa kitafunwa = kitafunwa kutolewa Nakili Mantiki hii imepangwa kwenye mashine ya kuuza bidhaa. Mkataba mahiri, kama mashine ya kuuza bidhaa, una mantiki iliyopangwa ndani yake. Huu hapa ni mfano rahisi wa jinsi mashine hii ya kuuza bidhaa ingeonekana kama ingekuwa mkataba mahiri ulioandikwa kwa Solidity: pragma solidity 0.8.7; contract VendingMachine { // Tangaza vigezo vya hali vya mkataba address public owner; mapping (address => uint) public cupcakeBalances; // Wakati mkataba wa 'VendingMachine' unasambazwa: // 1. weka anwani inayosambaza kama mmiliki wa mkataba // 2. weka salio la cupcake la mkataba mahiri uliosambazwa kuwa 100 constructor() { owner = msg.sender; cupcakeBalances[address(this)] = 100; } // Ruhusu mmiliki kuongeza salio la cupcake la mkataba mahiri function refill(uint amount) public { require(msg.sender == owner, "Only the owner can refill."); cupcakeBalances[address(this)] += amount; } // Ruhusu mtu yeyote kununua cupcakes function purchase(uint amount) public payable { require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake"); require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase"); cupcakeBalances[address(this)] -= amount; cupcakeBalances[msg.sender] += amount; } } NakiliSolidity Onyesha yote (30) Kama vile mashine ya kuuza bidhaa inavyoondoa hitaji la mfanyakazi wa muuzaji, mikataba mahiri inaweza kuchukua nafasi ya waamuzi katika tasnia nyingi. [](https://ethereum.org/sw/developers/docs/smart-contracts/#permissionless) Bila ruhusa --------------------------------------------------------------------------------------- Mtu yeyote anaweza kuandika mkataba mahiri na kuusambaza kwenye mtandao. Unahitaji tu kujifunza jinsi ya kuweka msimbo katika [lugha ya mkataba mahiri](https://ethereum.org/sw/developers/docs/smart-contracts/languages/) , na kuwa na ETH ya kutosha kusambaza mkataba wako. Kusambaza mkataba mahiri kiufundi ni muamala, kwa hivyo unahitaji kulipa [gesi](https://ethereum.org/sw/developers/docs/gas/) kwa njia sawa na unavyohitaji kulipa gesi kwa hamisho rahisi la ETH. Hata hivyo, gharama za gesi kwa usambazaji wa mkataba ni kubwa zaidi. Ethereum ina lugha zinazofaa kwa wasanidi programu kwa ajili ya kuandika mikataba mahiri: * Solidity * Vyper [Zaidi kuhusu lugha](https://ethereum.org/sw/developers/docs/smart-contracts/languages/) Hata hivyo, lazima zikusanywe kabla ya kusambazwa ili mashine pepe ya Ethereum iweze kufasiri na kuhifadhi mkataba. [Zaidi kuhusu ukusanyaji](https://ethereum.org/sw/developers/docs/smart-contracts/compiling/) [](https://ethereum.org/sw/developers/docs/smart-contracts/#composability) Utangamano ------------------------------------------------------------------------------------- Mikataba mahiri ni ya umma kwenye Ethereum na inaweza kufikiriwa kama API zilizo wazi. Hii inamaanisha unaweza kuita mikataba mahiri mingine katika mkataba wako mahiri ili kupanua sana kile kinachowezekana. Mikataba inaweza hata kusambaza mikataba mingine. Jifunze zaidi kuhusu [utangamano wa mkataba mahiri](https://ethereum.org/sw/developers/docs/smart-contracts/composability/) . [](https://ethereum.org/sw/developers/docs/smart-contracts/#limitations) Mapungufu ---------------------------------------------------------------------------------- Mikataba mahiri pekee haiwezi kupata taarifa kuhusu matukio ya "ulimwengu halisi" kwa sababu haiwezi kupata data kutoka vyanzo vya nje ya mnyororo. Hii inamaanisha haiwezi kujibu matukio katika ulimwengu halisi. Hii ni kwa muundo. Kutegemea taarifa za nje kunaweza kuhatarisha mwafaka, ambao ni muhimu kwa usalama na ugatuzi. Hata hivyo, ni muhimu kwa programu za mnyororo wa vitalu kuweza kutumia data ya nje ya mnyororo. Suluhisho ni [oracles](https://ethereum.org/sw/developers/docs/oracles/) ambazo ni zana zinazochukua data ya nje ya mnyororo na kuifanya ipatikane kwa mikataba mahiri. Kizuizi kingine cha mikataba mahiri ni ukubwa wa juu wa mkataba. Mkataba mahiri unaweza kuwa na ukubwa wa juu wa 24KB au utaishiwa na gesi. Hili linaweza kuepukwa kwa kutumia [Muundo wa Almasi (The Diamond Pattern) (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-2535) . [](https://ethereum.org/sw/developers/docs/smart-contracts/#multisig) Mikataba ya saini-nyingi ---------------------------------------------------------------------------------------------- Mikataba ya saini-nyingi (sahihi nyingi) ni akaunti za mkataba mahiri zinazohitaji sahihi nyingi halali ili kutekeleza muamala. Hii ni muhimu sana kwa kuepuka sehemu moja ya kutofaulu kwa mikataba inayoshikilia kiasi kikubwa cha Etha au tokeni nyingine. Saini-nyingi pia hugawanya jukumu la utekelezaji wa mkataba na usimamizi wa ufunguo kati ya pande nyingi na kuzuia upotevu wa ufunguo wa siri mmoja unaosababisha upotevu wa fedha usioweza kutenduliwa. Kwa sababu hizi, mikataba ya saini-nyingi inaweza kutumika kwa utawala rahisi wa DAO. Saini-nyingi zinahitaji sahihi N kati ya sahihi M zinazokubalika (ambapo N ≤ M, na M > 1) ili kutekeleza. `N = 3, M = 5` na `N = 4, M = 7` hutumiwa sana. Saini-nyingi ya 4/7 inahitaji sahihi nne kati ya saba zinazowezekana. Hii inamaanisha fedha bado zinaweza kurejeshwa hata kama sahihi tatu zimepotea. Katika kesi hii, inamaanisha pia kwamba idadi kubwa ya wamiliki wa ufunguo lazima wakubaliane na kusaini ili mkataba utekelezwe. [](https://ethereum.org/sw/developers/docs/smart-contracts/#smart-contract-resources) Rasilimali za mkataba mahiri ------------------------------------------------------------------------------------------------------------------ **Mikataba ya OpenZeppelin -** **_Maktaba kwa ajili ya uundaji salama wa mkataba mahiri._** * [openzeppelin.com/contracts/ (inafunguka katika kichupo kipya)](https://openzeppelin.com/contracts/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/OpenZeppelin/openzeppelin-contracts) * [Jukwaa la Jamii (inafunguka katika kichupo kipya)](https://forum.openzeppelin.com/c/general/16) [](https://ethereum.org/sw/developers/docs/smart-contracts/#further-reading) Usomaji zaidi ------------------------------------------------------------------------------------------ * [Coinbase: Mkataba mahiri ni nini? (inafunguka katika kichupo kipya)](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract) * [Chainlink: Mkataba mahiri ni nini? (inafunguka katika kichupo kipya)](https://chain.link/education/smart-contracts) * [Video: Imefafanuliwa kwa Urahisi - Mikataba Mahiri (inafunguka katika kichupo kipya)](https://youtu.be/ZE2HxTmxfrI) * [Cyfrin Updraft: Jukwaa la kujifunza na kukagua Web3 (inafunguka katika kichupo kipya)](https://updraft.cyfrin.io/) [](https://ethereum.org/sw/developers/docs/smart-contracts/#tutorials) Mafunzo: Sahihi za mkataba mahiri (EIP-1271) kwenye Ethereum ----------------------------------------------------------------------------------------------------------------------------------- * [EIP-1271: Kusaini na Kuthibitisha Sahihi za Mkataba Mahiri](https://ethereum.org/sw/developers/tutorials/eip-1271-smart-contract-signatures/) _– Jinsi EIP-1271 inavyowezesha mikataba mahiri kuthibitisha sahihi, pamoja na mwongozo wa utekelezaji wa Safe._ --- # Mifumo ya Uundaji wa Dapp | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/frameworks/#main-content) Change page Mifumo ya Uundaji wa Dapp ========================= Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/frameworks/index.md) Kwenye ukurasa huu [](https://ethereum.org/sw/developers/docs/frameworks/#introduction-to-frameworks) Utangulizi wa mifumo ------------------------------------------------------------------------------------------------------- Kujenga programu tumizi iliyogatuliwa (dapp) kamili kunahitaji vipande tofauti vya teknolojia. Mifumo ya programu inajumuisha vipengele vingi vinavyohitajika au hutoa mifumo rahisi ya programu-jalizi ili kuchagua zana unazotaka. Mifumo inakuja na utendaji mwingi wa moja kwa moja, kama vile: * Vipengele vya kuanzisha mfano wa mnyororo wa vitalu wa ndani. * Huduma za kukusanya na kujaribu mikataba mahiri yako. * Viongezi vya uundaji wa mteja ili kujenga programu yako inayoangalia mtumiaji ndani ya mradi/hifadhi sawa. * Usanidi wa kuunganisha kwenye mitandao ya Ethereum na kusambaza mikataba, iwe kwa mfano unaoendeshwa ndani, au mojawapo ya mitandao ya umma ya Ethereum. * Usambazaji wa programu iliyogatuliwa - miunganisho na chaguzi za uhifadhi kama IPFS. [](https://ethereum.org/sw/developers/docs/frameworks/#prerequisites) Mahitaji ya awali --------------------------------------------------------------------------------------- Kabla ya kuzama kwenye mifumo, tunapendekeza usome kwanza utangulizi wetu wa [dapps](https://ethereum.org/sw/developers/docs/dapps/) na [mrundikano wa Ethereum](https://ethereum.org/sw/developers/docs/ethereum-stack/) . Mifumo inayopatikana -------------------- **Foundry** - **_Foundry ni seti ya zana ya haraka sana, inayobebeka na ya kimoduli kwa uundaji wa programu za Ethereum_** * [Sakinisha Foundry (inafunguka katika kichupo kipya)](https://book.getfoundry.sh/) * [Kitabu cha Foundry (inafunguka katika kichupo kipya)](https://book.getfoundry.sh/) * [Soga ya jamii ya Foundry kwenye Telegram (inafunguka katika kichupo kipya)](https://t.me/foundry_support) * [Awesome Foundry (inafunguka katika kichupo kipya)](https://github.com/crisgarner/awesome-foundry) **Hardhat -** **_Mazingira ya uundaji wa Ethereum kwa wataalamu._** * [hardhat.org (inafunguka katika kichupo kipya)](https://hardhat.org/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/nomiclabs/hardhat) **Ape -** **_Zana ya uundaji wa mkataba mahiri kwa Wana-Python, Wanasayansi wa Data, na Wataalamu wa Usalama._** * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.apeworx.io/ape/stable/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/ApeWorX/ape) **Web3j -** **_Jukwaa la kuunda programu za mnyororo wa vitalu kwenye JVM._** * [Ukurasa wa nyumbani (inafunguka katika kichupo kipya)](https://www.web3labs.com/web3j-sdk) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.web3j.io/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/web3j/web3j) **ethers-kt -** **_Maktaba ya Async, yenye utendaji wa juu ya Kotlin/Java/Android kwa minyororo ya vitalu inayotegemea EVM._** * [GitHub (inafunguka katika kichupo kipya)](https://github.com/Kr1ptal/ethers-kt) * [Mifano (inafunguka katika kichupo kipya)](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) * [Discord (inafunguka katika kichupo kipya)](https://discord.gg/rx35NzQGSb) **Create Eth App -** **_Unda programu zinazoendeshwa na Ethereum kwa amri moja. Inakuja na ofa pana ya mifumo ya UI na violezo vya fedha zilizogatuliwa (DeFi) vya kuchagua._** * [GitHub (inafunguka katika kichupo kipya)](https://github.com/paulrberg/create-eth-app) * [Violezo (inafunguka katika kichupo kipya)](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates) **Scaffold-ETH 2 -** **_Next.js, Wagmi, Viem na RainbowKit na chaguo lako la Hardhat au Foundry: upakiaji upya wa haraka wa mkataba, ndoano maalum za React, mkoba wa burner na bomba la ndani, na moduli za ugani kwa uundaji wa programu tumizi iliyogatuliwa (dapp) wa mrundikano kamili._** * [Tovuti (inafunguka katika kichupo kipya)](https://scaffoldeth.io/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/scaffold-eth/scaffold-eth-2) **Tenderly -** **_Jukwaa la uundaji la Web3 linalowezesha waundaji wa mnyororo wa vitalu kujenga, kujaribu, kutatua, kufuatilia, na kuendesha mikataba mahiri na kuboresha UX ya dapp._** * [Tovuti (inafunguka katika kichupo kipya)](https://tenderly.co/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.tenderly.co/) **The Graph -** **_The Graph kwa kuuliza data ya mnyororo wa vitalu kwa ufanisi._** * [Tovuti (inafunguka katika kichupo kipya)](https://thegraph.com/) * [Mafunzo](https://ethereum.org/sw/developers/tutorials/the-graph-fixing-web3-data-querying/) **Alchemy -** **_Jukwaa la Uundaji la Ethereum._** * [alchemy.com (inafunguka katika kichupo kipya)](https://www.alchemy.com/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/alchemyplatform) * [Discord (inafunguka katika kichupo kipya)](https://discord.com/invite/alchemyplatform) **NodeReal -** **_Jukwaa la Uundaji la Ethereum._** * [Nodereal.io (inafunguka katika kichupo kipya)](https://nodereal.io/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/node-real) * [Discord (inafunguka katika kichupo kipya)](https://discord.gg/V5k5gsuE) **thirdweb SDK -** **_Jenga programu za Web3 zinazoweza kuingiliana na mikataba mahiri yako kwa kutumia SDK zetu zenye nguvu na CLI._** * [Nyaraka (inafunguka katika kichupo kipya)](https://portal.thirdweb.com/sdk/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/thirdweb-dev/) **Chainstack -** **_Jukwaa la Uundaji la Web3 (Ethereum na vinginevyo)._** * [chainstack.com (inafunguka katika kichupo kipya)](https://www.chainstack.com/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/chainstack) * [Discord (inafunguka katika kichupo kipya)](https://discord.gg/BSb5zfp9AT) **Crossmint -** **_Jukwaa la uundaji la Web3 la kiwango cha biashara, ambalo linakuruhusu kujenga programu za NFT kwenye minyororo yote mikuu Minyororo ya EVM (na mingine)._** * [Tovuti (inafunguka katika kichupo kipya)](https://www.crossmint.com/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.crossmint.com/) * [Discord (inafunguka katika kichupo kipya)](https://discord.com/invite/crossmint) **Brownie -** **_Mazingira ya uundaji yanayotegemea Python na mfumo wa majaribio._** * [Nyaraka (inafunguka katika kichupo kipya)](https://eth-brownie.readthedocs.io/en/latest/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/eth-brownie/brownie) * **Brownie kwa sasa haitunzwi** **OpenZeppelin SDK -** **_Seti Kuu ya Zana ya Mkataba Mahiri: Mkusanyiko wa zana za kukusaidia kuunda, kukusanya, kuboresha, kusambaza na kuingiliana na mikataba mahiri._** * [OpenZeppelin Defender SDK (inafunguka katika kichupo kipya)](https://docs.openzeppelin.com/defender/sdk) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/OpenZeppelin/openzeppelin-sdk) * [Jukwaa la Jamii (inafunguka katika kichupo kipya)](https://forum.openzeppelin.com/c/support/17) * **Uundaji wa OpenZeppelin SDK umekwisha** **Catapulta -** **_Zana ya usambazaji wa mikataba mahiri ya minyororo mingi, otomatisha uthibitishaji katika vigunduzi vya kitalu, fuatilia mikataba mahiri iliyosambazwa na ushiriki ripoti za usambazaji, chomeka-na-cheza kwa miradi ya Foundry na Hardhat._** * [GitHub (inafunguka katika kichupo kipya)](https://github.com/catapulta-sh) **GoldRush (inayoendeshwa na Covalent) -** **_GoldRush inatoa seti kamili zaidi ya API ya data ya mnyororo wa vitalu kwa waundaji, wachambuzi, na biashara. Iwe unajenga dashibodi ya DeFi, mkoba, boti ya biashara, ajenti wa akili bandia au jukwaa la kufuata, API za data hutoa ufikiaji wa haraka, sahihi, na rafiki kwa waundaji kwa data muhimu ya mnyororoni unayohitaji_** * [Tovuti (inafunguka katika kichupo kipya)](https://goldrush.dev/) * [Nyaraka (inafunguka katika kichupo kipya)](https://goldrush.dev/docs/chains/ethereum) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/covalenthq) * [Discord (inafunguka katika kichupo kipya)](https://www.covalenthq.com/discord/) **Wake -** **_Mfumo wa Python wa yote kwa moja kwa majaribio ya mikataba, fuzzing, usambazaji, uchunguzi wa udhaifu na urambazaji wa msimbo._** * [Ukurasa wa nyumbani (inafunguka katika kichupo kipya)](https://getwake.io/) * [Nyaraka (inafunguka katika kichupo kipya)](https://ackeeblockchain.com/wake/docs/latest/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/Ackee-Blockchain/wake) * [Kiendelezi cha VS Code (inafunguka katika kichupo kipya)](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity) **Veramo -** **_Mfumo wa chanzo wazi, wa kimoduli na usio na upendeleo ambao hurahisisha waundaji wa programu tumizi iliyogatuliwa kujenga vitambulisho vilivyogatuliwa na vitambulisho vinavyoweza kuthibitishwa kwenye programu zao._** * [Ukurasa wa nyumbani (inafunguka katika kichupo kipya)](https://veramo.io/) * [Nyaraka (inafunguka katika kichupo kipya)](https://veramo.io/docs/basics/introduction) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/uport-project/veramo) * [Discord (inafunguka katika kichupo kipya)](https://discord.com/invite/FRRBdjemHV) * [Kifurushi cha NPM (inafunguka katika kichupo kipya)](https://www.npmjs.com/package/@veramo/core) **Moccasin -** **_Mfumo wa haraka, wa Pythonic wa uundaji na majaribio ya mkataba mahiri kwa Vyper, uliojengwa kwenye Titanoboa._** * [Nyaraka (inafunguka katika kichupo kipya)](https://cyfrin.github.io/moccasin/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/Cyfrin/moccasin) [](https://ethereum.org/sw/developers/docs/frameworks/#further-reading) Usomaji zaidi ------------------------------------------------------------------------------------- _Unajua rasilimali ya jamii iliyokusaidia? Hariri ukurasa huu na uiongeze!_ [](https://ethereum.org/sw/developers/docs/frameworks/#related-topics) Mada zinazohusiana ----------------------------------------------------------------------------------------- * [Sanidi mazingira ya uundaji wa ndani](https://ethereum.org/sw/developers/local-environment/) [](https://ethereum.org/sw/developers/docs/frameworks/#tutorials) Mafunzo: Mifumo ya uundaji kwenye Ethereum ------------------------------------------------------------------------------------------------------------ * [Mkataba Mahiri wa Hello World kwa Wanaoanza – Fullstack](https://ethereum.org/sw/developers/tutorials/hello-world-smart-contract-fullstack/) _– Jenga na usambaze mkataba mahiri wa hello world kwa kutumia Hardhat, kisha uunganishe kwenye sehemu ya mbele (frontend)._ --- # Delphi開発者のためのイーサリアム | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/programming-languages/delphi/#main-content) Change page Delphi開発者のためのイーサリアム =================== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/delphi/index.md) このページの内容 Delphiプログラミング言語を使用してイーサリアム向けに開発する方法を学ぶ イーサリアムを使用して、暗号資産とブロックチェーン技術の利点を活用する分散型アプリケーション (dapp) を作成します。これらのdappは信頼性が高く、一度イーサリアムにデプロイされると、常にプログラムされた通りに実行されます。デジタル資産を制御して、新しい種類の金融アプリケーションを作成できます。これらは分散型であり、単一の組織や個人が制御することはなく、検閲することはほぼ不可能です。 Delphiプログラミング言語を使用して、イーサリアム上に分散型アプリケーションを構築し、スマート・コントラクトと対話しましょう！ [](https://ethereum.org/ja/developers/docs/programming-languages/delphi/#getting-started-with-smart-contracts-and-the-solidity-language) スマート・コントラクトとSolidity言語の入門 ------------------------------------------------------------------------------------------------------------------------------------------------------------------ **Delphiとイーサリアムを統合するための第一歩を踏み出す** まずはより基本的な入門書が必要ですか？ [ethereum.org/learn](https://ethereum.org/ja/learn/) または [ethereum.org/developers](https://ethereum.org/ja/developers/) を確認してください。 * [ブロックチェーンの解説 （新しいタブで開きます）](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [スマート・コントラクトの理解 （新しいタブで開きます）](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [初めてのスマート・コントラクトを書く （新しいタブで開きます）](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Solidityのコンパイルとデプロイ方法を学ぶ （新しいタブで開きます）](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) [](https://ethereum.org/ja/developers/docs/programming-languages/delphi/#beginner-references-and-links) 初心者向けのリファレンスとリンク ------------------------------------------------------------------------------------------------------------------------ **Delphereumライブラリの紹介** * [Delphereumとは？ （新しいタブで開きます）](https://github.com/svanas/delphereum/blob/master/README.md) * [Delphiをローカル（インメモリ）のブロックチェーンに接続する （新しいタブで開きます）](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0) * [Delphiをイーサリアム・メインネットに接続する （新しいタブで開きます）](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83) * [Delphiをスマート・コントラクトに接続する （新しいタブで開きます）](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1) **セットアップをスキップして、すぐにサンプルを見たいですか？** * [3分でわかるスマート・コントラクトとDelphi - パート1 （新しいタブで開きます）](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d) * [3分でわかるスマート・コントラクトとDelphi - パート2 （新しいタブで開きます）](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b) [](https://ethereum.org/ja/developers/docs/programming-languages/delphi/#intermediate-articles) 中級者向けの記事 -------------------------------------------------------------------------------------------------------- * [Delphiでイーサリアム署名付きメッセージの署名を生成する （新しいタブで開きます）](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b) * [Delphiでイーサを送金する （新しいタブで開きます）](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4) * [DelphiでERC-20トークンを送金する （新しいタブで開きます）](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d) [](https://ethereum.org/ja/developers/docs/programming-languages/delphi/#advanced-use-patterns) 高度な使用パターン --------------------------------------------------------------------------------------------------------- * [DelphiとEthereum Name Service (ENS) （新しいタブで開きます）](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7) * [QuikNode、イーサリアム、Delphi （新しいタブで開きます）](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23) * [Delphiとイーサリアムのダークフォレスト （新しいタブで開きます）](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93) * [Delphiであるトークンを別のトークンにスワップする （新しいタブで開きます）](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7) さらにリソースをお探しですか？ [ethereum.org/developers](https://ethereum.org/ja/developers/) を確認してください。 --- # 데이터 가용성 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/data-availability/#main-content) Change page 데이터 가용성 ======= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-availability/index.md) 이 페이지의 내용 "신뢰하지 말고 검증하라(Don't trust, verify)"는 이더리움에서 흔히 쓰이는 격언입니다. 이 개념은 노드가 피어로부터 받은 블록 내의 모든 트랜잭션을 실행하여, 제안된 변경 사항이 노드가 독립적으로 계산한 것과 정확히 일치하는지 확인함으로써 수신한 정보가 올바른지 독립적으로 검증할 수 있다는 것입니다. 이는 노드가 블록 전송자가 정직하다고 신뢰할 필요가 없음을 의미합니다. 데이터가 누락된 경우에는 이것이 불가능합니다. **데이터 가용성**은 블록을 검증하는 데 필요한 데이터가 모든 네트워크 참여자에게 실제로 제공되고 있다는 사용자의 확신을 의미합니다. [이더리움](https://ethereum.org/ko/) 레이어 1 (l1)의 풀 노드에게 이는 비교적 간단합니다. 풀 노드는 각 블록의 모든 데이터 사본을 다운로드하며, 다운로드가 가능하려면 데이터가 _반드시_ 가용해야 합니다. 데이터가 누락된 블록은 블록체인에 추가되지 않고 폐기됩니다. 이것이 "온체인 데이터 가용성"이며, 모놀리식 블록체인의 특징입니다. 풀 노드는 모든 트랜잭션을 직접 다운로드하고 실행하기 때문에 유효하지 않은 트랜잭션을 수락하도록 속일 수 없습니다. 하지만 모듈형 블록체인, 레이어 2 (l2) 롤업 및 경량 클라이언트의 경우 데이터 가용성 환경이 더 복잡하여 보다 정교한 검증 절차가 필요합니다. [](https://ethereum.org/ko/developers/docs/data-availability/#prerequisites) 전제 조건 ---------------------------------------------------------------------------------- [블록체인 기초](https://ethereum.org/ko/developers/docs/intro-to-ethereum/) , 특히 [합의 메커니즘](https://ethereum.org/ko/developers/docs/consensus-mechanisms/) 에 대해 잘 이해하고 있어야 합니다. 또한 이 페이지는 독자가 [블록](https://ethereum.org/ko/developers/docs/blocks/) , [트랜잭션](https://ethereum.org/ko/developers/docs/transactions/) , [노드](https://ethereum.org/ko/developers/docs/nodes-and-clients/) , [확장성 솔루션](https://ethereum.org/ko/developers/docs/scaling/) 및 기타 관련 주제에 익숙하다고 가정합니다. [](https://ethereum.org/ko/developers/docs/data-availability/#the-data-availability-problem) 데이터 가용성 문제 ------------------------------------------------------------------------------------------------------- 데이터 가용성 문제는 블록체인에 추가되는 일부 트랜잭션 데이터의 요약된 형태가 실제로 유효한 트랜잭션 세트를 나타낸다는 것을 전체 네트워크에 증명해야 하지만, 모든 노드가 모든 데이터를 다운로드하지 않고도 이를 수행해야 한다는 필요성에서 비롯됩니다. 블록을 독립적으로 검증하려면 전체 트랜잭션 데이터가 필요하지만, 모든 노드에 전체 트랜잭션 데이터를 다운로드하도록 요구하는 것은 확장에 장애물이 됩니다. 데이터 가용성 문제에 대한 해결책은 데이터를 직접 다운로드하고 저장하지 않는 네트워크 참여자에게도 검증을 위한 전체 트랜잭션 데이터가 제공되었다는 충분한 보장을 제공하는 것을 목표로 합니다. [경량 노드](https://ethereum.org/ko/developers/docs/nodes-and-clients/light-clients/) 와 [레이어 2 (l2) 롤업](https://ethereum.org/ko/developers/docs/scaling/) 은 강력한 데이터 가용성 보장이 필요하지만 트랜잭션 데이터를 직접 다운로드하고 처리할 수 없는 네트워크 참여자의 중요한 예입니다. 트랜잭션 데이터 다운로드를 피하는 것이 경량 노드를 가볍게 만들고 롤업이 효과적인 확장성 솔루션이 될 수 있게 하는 요소입니다. 데이터 가용성은 블록을 검증하기 위해 상태 데이터를 다운로드하고 저장할 필요가 없는 미래의 ["무상태(stateless)"](https://ethereum.org/ko/roadmap/statelessness/) 이더리움 클라이언트에게도 중요한 문제입니다. 무상태 클라이언트는 여전히 데이터가 _어딘가에_ 가용하며 올바르게 처리되었음을 확신할 수 있어야 합니다. [](https://ethereum.org/ko/developers/docs/data-availability/#data-availability-solutions) 데이터 가용성 솔루션 ------------------------------------------------------------------------------------------------------ ### [](https://ethereum.org/ko/developers/docs/data-availability/#data-availability-sampling) 데이터 가용성 샘플링(DAS) 데이터 가용성 샘플링(DAS)은 개별 노드에 너무 많은 부담을 주지 않으면서 네트워크가 데이터가 가용한지 확인하는 방법입니다. 각 노드(스테이킹하지 않는 노드 포함)는 전체 데이터 중 무작위로 선택된 작은 하위 집합을 다운로드합니다. 샘플을 성공적으로 다운로드하면 모든 데이터가 가용하다는 것을 높은 신뢰도로 확인할 수 있습니다. 이는 주어진 데이터 세트를 중복 정보로 확장하는 데이터 이레이저 코딩에 의존합니다(이 작업은 데이터에 _다항식_이라는 함수를 맞추고 추가 지점에서 해당 다항식을 평가하는 방식으로 수행됩니다). 이를 통해 필요할 때 중복 데이터에서 원본 데이터를 복구할 수 있습니다. 이러한 데이터 생성의 결과로, 원본 데이터 중 _일부_라도 가용하지 않으면 확장된 데이터의 _절반_이 누락됩니다! 각 노드가 다운로드하는 데이터 샘플의 양을 조정하여, 실제로 가용한 데이터가 절반 미만일 _경우_ 각 클라이언트가 샘플링한 데이터 조각 중 적어도 하나가 누락될 가능성을 _매우_ 높일 수 있습니다. DAS는 [완전한 댕크샤딩](https://ethereum.org/ko/roadmap/danksharding/#what-is-danksharding) 이 구현된 후 롤업 운영자가 트랜잭션 데이터를 가용하게 만들도록 보장하는 데 사용될 것입니다. 이더리움 노드는 위에서 설명한 중복 체계를 사용하여 블롭에 제공된 트랜잭션 데이터를 무작위로 샘플링하여 모든 데이터가 존재하는지 확인합니다. 동일한 기술을 사용하여 블록 생성자가 경량 클라이언트를 보호하기 위해 모든 데이터를 가용하게 만들고 있는지 확인할 수도 있습니다. 마찬가지로 [제안자-빌더 분리 (PBS)](https://ethereum.org/ko/roadmap/pbs/) 하에서는 블록 빌더만 전체 블록을 처리하면 되며, 다른 검증자는 데이터 가용성 샘플링을 사용하여 검증하게 됩니다. ### [](https://ethereum.org/ko/developers/docs/data-availability/#data-availability-committees) 데이터 가용성 위원회 데이터 가용성 위원회(DAC)는 데이터 가용성을 제공하거나 증명하는 신뢰할 수 있는 당사자입니다. DAC는 DAS 대신 사용하거나 [DAS와 결합하여 (새 탭에서 열림)](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) 사용할 수 있습니다. 위원회가 제공하는 보안 보장은 특정 설정에 따라 다릅니다. 예를 들어, 이더리움은 무작위로 샘플링된 검증자 하위 집합을 사용하여 경량 노드를 위한 데이터 가용성을 증명합니다. DAC는 일부 밸리디움(validium)에서도 사용됩니다. DAC는 데이터 사본을 오프라인에 저장하는 신뢰할 수 있는 노드 집합입니다. 분쟁이 발생할 경우 DAC는 데이터를 가용하게 만들어야 합니다. DAC 구성원은 또한 해당 데이터가 실제로 가용하다는 것을 증명하기 위해 온체인 증명을 게시합니다. 일부 밸리디움은 DAC를 지분 증명 (PoS) 검증자 시스템으로 대체합니다. 여기서는 누구나 검증자가 되어 오프체인에 데이터를 저장할 수 있습니다. 하지만 이들은 스마트 컨트랙트에 예치되는 "보증금(bond)"을 제공해야 합니다. 검증자가 데이터를 은닉하는 등의 악의적인 행동을 할 경우 보증금은 슬래싱될 수 있습니다. 지분 증명 (PoS) 데이터 가용성 위원회는 정직한 행동을 직접적으로 장려하기 때문에 일반 DAC보다 훨씬 더 안전합니다. [](https://ethereum.org/ko/developers/docs/data-availability/#data-availability-and-light-nodes) 데이터 가용성과 경량 노드 --------------------------------------------------------------------------------------------------------------- [경량 노드](https://ethereum.org/ko/developers/docs/nodes-and-clients/light-clients/) 는 블록 데이터를 다운로드하지 않고 수신한 블록 헤더의 정확성을 검증해야 합니다. 이러한 가벼움의 대가는 풀 노드처럼 로컬에서 트랜잭션을 재실행하여 블록 헤더를 독립적으로 검증할 수 없다는 것입니다. 이더리움 경량 노드는 _동기화 위원회_에 할당된 512명의 무작위 검증자 세트를 신뢰합니다. 동기화 위원회는 암호화 서명을 사용하여 헤더의 데이터가 올바르다는 것을 경량 클라이언트에게 알리는 DAC 역할을 합니다. 동기화 위원회는 매일 갱신됩니다. 각 블록 헤더는 경량 노드에게 _다음_ 블록에 서명할 검증자가 누구인지 알려주므로, 실제 동기화 위원회인 척하는 악의적인 그룹을 신뢰하도록 속일 수 없습니다. 하지만 공격자가 어떻게든 악의적인 블록 헤더를 경량 클라이언트에게 전달하고 정직한 동기화 위원회가 서명했다고 확신시키는 데 성공한다면 어떻게 될까요? 이 경우 공격자는 유효하지 않은 트랜잭션을 포함할 수 있으며, 경량 클라이언트는 블록 헤더에 요약된 모든 상태 변경을 독립적으로 확인하지 않기 때문에 이를 맹목적으로 수락하게 됩니다. 이를 방지하기 위해 경량 클라이언트는 사기 증명을 사용할 수 있습니다. 이러한 사기 증명이 작동하는 방식은 다음과 같습니다. 네트워크에 유효하지 않은 상태 전환이 전파되는 것을 본 풀 노드는 제안된 상태 전환이 주어진 트랜잭션 세트에서 발생할 수 없음을 보여주는 작은 데이터를 신속하게 생성하여 피어에게 브로드캐스트할 수 있습니다. 경량 노드는 이러한 사기 증명을 수신하여 잘못된 블록 헤더를 폐기하는 데 사용함으로써 풀 노드와 동일한 정직한 체인에 머물 수 있습니다. 이는 풀 노드가 전체 트랜잭션 데이터에 접근할 수 있다는 점에 의존합니다. 잘못된 블록 헤더를 브로드캐스트하면서 트랜잭션 데이터도 가용하게 만들지 않는 공격자는 풀 노드가 사기 증명을 생성하는 것을 막을 수 있습니다. 풀 노드는 잘못된 블록에 대한 경고를 보낼 수는 있지만, 증명을 생성할 데이터가 제공되지 않았기 때문에 증명으로 경고를 뒷받침할 수는 없습니다! 이 데이터 가용성 문제에 대한 해결책이 바로 DAS입니다. 경량 노드는 전체 상태 데이터의 매우 작은 무작위 청크를 다운로드하고 샘플을 사용하여 전체 데이터 세트가 가용한지 검증합니다. N개의 무작위 청크를 다운로드한 후 전체 데이터가 가용하다고 잘못 가정할 실제 가능성은 계산할 수 있습니다([100개 청크의 경우 확률은 10^-30 (새 탭에서 열림)](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) 으로, 믿을 수 없을 정도로 낮습니다). 이 시나리오에서도 단 몇 바이트만 은닉하는 공격은 무작위 데이터 요청을 하는 클라이언트가 눈치채지 못할 수 있습니다. 이레이저 코딩은 제안된 상태 변경을 확인하는 데 사용할 수 있는 누락된 작은 데이터 조각을 재구성하여 이 문제를 해결합니다. 그런 다음 재구성된 데이터를 사용하여 사기 증명을 구성할 수 있으므로 경량 노드가 잘못된 헤더를 수락하는 것을 방지할 수 있습니다. **참고:** DAS 및 사기 증명은 지분 증명 (PoS) 이더리움 경량 클라이언트를 위해 아직 구현되지 않았지만 로드맵에 있으며, 영지식 스나크 기반 증명의 형태를 취할 가능성이 높습니다. 오늘날의 경량 클라이언트는 DAC의 한 형태에 의존합니다. 즉, 동기화 위원회의 신원을 검증한 다음 수신한 서명된 블록 헤더를 신뢰합니다. [](https://ethereum.org/ko/developers/docs/data-availability/#data-availability-and-layer-2-rollups) 데이터 가용성과 레이어 2 (l2) 롤업 --------------------------------------------------------------------------------------------------------------------------- 과 같은 [레이어 2 (l2) 확장성 솔루션](https://ethereum.org/ko/layer-2/) 은 트랜잭션을 오프체인에서 처리하여 트랜잭션 비용을 줄이고 이더리움의 처리량을 늘립니다. 롤업 트랜잭션은 압축되어 이더리움에 배치(batch)로 게시됩니다. 배치는 이더리움의 단일 트랜잭션 내에 수천 개의 개별 오프체인 트랜잭션을 나타냅니다. 이는 기본 레이어의 혼잡을 줄이고 사용자의 수수료를 낮춥니다. 하지만 이더리움에 게시된 '요약' 트랜잭션을 신뢰할 수 있는 것은 제안된 상태 변경이 독립적으로 검증될 수 있고 모든 개별 오프체인 트랜잭션을 적용한 결과임이 확인될 때뿐입니다. 롤업 운영자가 이 검증을 위해 트랜잭션 데이터를 가용하게 만들지 않으면 이더리움에 잘못된 데이터를 보낼 수 있습니다. [옵티미스틱 롤업](https://ethereum.org/ko/developers/docs/scaling/optimistic-rollups/) 은 압축된 트랜잭션 데이터를 이더리움에 게시하고 독립적인 검증자가 데이터를 확인할 수 있도록 일정 시간(일반적으로 7일)을 기다립니다. 누군가 문제를 발견하면 사기 증명을 생성하여 롤업에 이의를 제기할 수 있습니다. 이로 인해 체인이 롤백되고 유효하지 않은 블록이 생략됩니다. 이는 데이터가 가용할 때만 가능합니다. 현재 옵티미스틱 롤업이 레이어 1 (l1)에 트랜잭션 데이터를 게시하는 방법에는 두 가지가 있습니다. 일부 롤업은 온체인에 영구적으로 존재하는 `CALLDATA`로 데이터를 영구적으로 가용하게 만듭니다. EIP-4844의 구현으로 일부 롤업은 트랜잭션 데이터를 더 저렴한 블롭 스토리지에 대신 게시합니다. 이는 영구적인 스토리지가 아닙니다. 독립적인 검증자는 데이터가 이더리움 레이어 1 (l1)에서 삭제되기 전인 약 18일 이내에 블롭을 쿼리하고 이의를 제기해야 합니다. 데이터 가용성은 그 짧은 고정된 기간 동안만 이더리움 프로토콜에 의해 보장됩니다. 그 이후에는 이더리움 생태계 내 다른 주체들의 책임이 됩니다. 모든 노드는 DAS를 사용하여, 즉 블롭 데이터의 작고 무작위적인 샘플을 다운로드하여 데이터 가용성을 검증할 수 있습니다. [영지식(ZK) 롤업](https://ethereum.org/ko/developers/docs/scaling/zk-rollups/) 은 이 상태 전환의 정확성을 보장하므로 트랜잭션 데이터를 게시할 필요가 없습니다. 하지만 상태 데이터에 접근하지 않고는 ZK 롤업의 기능(또는 상호 작용)을 보장할 수 없기 때문에 데이터 가용성은 여전히 문제입니다. 예를 들어, 운영자가 롤업의 상태에 대한 세부 정보를 은닉하면 사용자는 자신의 잔액을 알 수 없습니다. 또한 새로 추가된 블록에 포함된 정보를 사용하여 상태 업데이트를 수행할 수 없습니다. [](https://ethereum.org/ko/developers/docs/data-availability/#data-availability-vs-data-retrievability) 데이터 가용성 대 데이터 검색 가능성 ---------------------------------------------------------------------------------------------------------------------------- 데이터 가용성은 데이터 검색 가능성(retrievability)과 다릅니다. 데이터 가용성은 풀 노드가 특정 블록과 관련된 전체 트랜잭션 세트에 접근하고 검증할 수 있었다는 보장입니다. 이것이 데이터에 영원히 접근할 수 있다는 것을 의미하지는 않습니다. 데이터 검색 가능성은 노드가 블록체인에서 _과거 정보_를 검색할 수 있는 능력입니다. 이 과거 데이터는 새로운 블록을 검증하는 데 필요하지 않으며, 제네시스 블록부터 풀 노드를 동기화하거나 특정 과거 요청을 처리하는 데만 필요합니다. 핵심 이더리움 프로토콜은 주로 데이터 검색 가능성이 아닌 데이터 가용성에 중점을 둡니다. 데이터 검색 가능성은 제3자가 운영하는 소수의 아카이브 노드에 의해 제공되거나, [포털 네트워크 (새 탭에서 열림)](https://www.ethportal.net/) 와 같은 탈중앙화된 파일 스토리지를 사용하여 네트워크 전체에 분산될 수 있습니다. [](https://ethereum.org/ko/developers/docs/data-availability/#further-reading) 더 읽어보기 ------------------------------------------------------------------------------------- * [데이터 가용성이란 무엇인가요? (새 탭에서 열림)](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) * [데이터 가용성이란 무엇인가요? (새 탭에서 열림)](https://coinmarketcap.com/academy/article/what-is-data-availability) * [데이터 가용성 검사 입문 (새 탭에서 열림)](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) * [샤딩 + DAS 제안에 대한 설명 (새 탭에서 열림)](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) * [데이터 가용성 및 이레이저 코딩에 대한 참고 사항 (새 탭에서 열림)](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) * [데이터 가용성 위원회 (새 탭에서 열림)](https://medium.com/starkware/data-availability-e5564c416424) * [지분 증명 (PoS) 데이터 가용성 위원회 (새 탭에서 열림)](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) * [데이터 검색 가능성 문제에 대한 해결책 (새 탭에서 열림)](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) * [데이터 가용성, 또는 롤업이 걱정을 멈추고 이더리움을 사랑하게 된 방법 (새 탭에서 열림)](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) * [EIP-7623: 콜 데이터 비용 증가 (새 탭에서 열림)](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) --- # 합의 메커니즘 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#main-content) Change page 합의 메커니즘 ======= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/consensus-mechanisms/index.md) 이 페이지의 내용 '합의 메커니즘'이라는 용어는 종종 일상적으로 '지분 증명(PoS)', '작업증명(PoW)' 또는 '권위 증명(PoA)' 프로토콜을 지칭하는 데 사용됩니다. 하지만 이들은 으로부터 보호하는 합의 메커니즘의 구성 요소일 뿐입니다. 합의 메커니즘은 분산된 노드 세트가 블록체인의 상태에 동의할 수 있도록 하는 아이디어, 프로토콜 및 인센티브의 완전한 스택입니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#prerequisites) 전제 조건 ------------------------------------------------------------------------------------- 이 페이지를 더 잘 이해하려면 먼저 [이더리움 소개](https://ethereum.org/ko/developers/docs/intro-to-ethereum/) 를 읽어보시기 바랍니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#what-is-consensus) 합의란 무엇인가요? ---------------------------------------------------------------------------------------------- 합의란 일반적인 동의에 도달했음을 의미합니다. 영화관에 가는 사람들의 그룹을 생각해 보세요. 제안된 영화 선택에 이견이 없다면 합의가 이루어진 것입니다. 이견이 있는 경우, 그룹은 어떤 영화를 볼지 결정할 수 있는 수단이 있어야 합니다. 극단적인 경우 그룹은 결국 분열될 것입니다. [이더리움](https://ethereum.org/ko/) 블록체인과 관련하여 이 프로세스는 공식화되어 있으며, 합의에 도달한다는 것은 네트워크 노드의 최소 66%가 네트워크의 전역 상태에 동의한다는 것을 의미합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#what-is-a-consensus-mechanism) 합의 메커니즘이란 무엇인가요? ---------------------------------------------------------------------------------------------------------------- 합의 메커니즘이라는 용어는 노드 네트워크가 블록체인의 상태에 동의할 수 있도록 하는 프로토콜, 인센티브 및 아이디어의 전체 스택을 의미합니다. 이더리움은 스테이킹 참여자가 예치한 자본에 적용되는 일련의 보상과 벌칙에서 암호화폐 경제적 보안을 도출하는 지분 증명 기반 합의 메커니즘을 사용합니다. 이러한 인센티브 구조는 개별 스테이킹 참여자가 정직한 검증자를 운영하도록 장려하고, 그렇지 않은 사람을 처벌하며, 네트워크를 공격하는 데 엄청나게 높은 비용을 발생시킵니다. 또한 정직한 검증자가 블록을 제안하거나 검증하고, 트랜잭션을 처리하며, 체인의 헤드(head)에 대한 자신의 관점에 투표하도록 선택되는 방식을 관리하는 프로토콜이 있습니다. 체인의 헤드 근처의 동일한 위치에 여러 블록이 존재하는 드문 상황에서는, 스테이킹된 이더 잔액으로 가중치를 부여하여 블록에 투표한 검증자의 수로 측정된 '가장 무거운(heaviest)' 체인을 구성하는 블록을 선택하는 포크 선택 메커니즘(fork-choice mechanism)이 있습니다. 네트워크 공격에 대한 최후의 방어선으로서 잠재적인 대역 외(out-of-band) 사회적 조정이 제공하는 추가적인 보안과 같이, 코드에 명시적으로 정의되어 있지는 않지만 합의에 중요한 몇 가지 개념이 있습니다. 이러한 구성 요소들이 모여 합의 메커니즘을 형성합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#types-of-consensus-mechanisms) 합의 메커니즘의 유형 ----------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#proof-of-work) 작업증명 기반 비트코인과 마찬가지로 이더리움도 한때 **작업증명(PoW)** 기반 합의 프로토콜을 사용했습니다. #### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#pow-block-creation) 블록 생성 채굴자들은 처리된 트랜잭션으로 채워진 새로운 블록을 생성하기 위해 경쟁합니다. 승자는 나머지 네트워크와 새 블록을 공유하고 새로 발행된 약간의 ETH를 얻습니다. 이 경쟁은 수학 퍼즐을 가장 빨리 푸는 컴퓨터가 승리합니다. 이는 현재 블록과 이전 블록 사이에 암호화 링크를 생성합니다. 이 퍼즐을 푸는 것이 "작업증명"에서의 작업(work)입니다. 그런 다음 정규 체인(canonical chain)은 채굴하는 데 가장 많은 작업이 수행된 블록 세트를 선택하는 포크 선택 규칙에 의해 결정됩니다. #### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#pow-security) 보안 체인을 속이려면 네트워크 컴퓨팅 파워의 51%가 필요하다는 사실에 의해 네트워크가 안전하게 유지됩니다. 이를 위해서는 장비와 에너지에 막대한 투자가 필요하며, 얻는 것보다 더 많은 비용을 지출하게 될 가능성이 높습니다. [작업증명](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/) 에 대해 자세히 알아보기 ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#proof-of-stake) 지분 증명 기반 이더리움은 이제 **지분 증명(PoS)** 기반 합의 프로토콜을 사용합니다. #### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#pos-block-creation) 블록 생성 검증자가 블록을 생성합니다. 각 슬롯에서 한 명의 검증자가 무작위로 선택되어 블록 제안자가 됩니다. 이들의 합의 클라이언트는 페어링된 실행 클라이언트에게 트랜잭션 번들을 '실행 페이로드'로 요청합니다. 이들은 이를 합의 데이터로 감싸 블록을 형성하고, 이더리움 네트워크의 다른 노드로 전송합니다. 이러한 블록 생성은 ETH로 보상받습니다. 단일 슬롯에 대해 여러 개의 가능한 블록이 존재하거나 노드가 서로 다른 시간에 블록에 대해 듣는 드문 경우, 포크 선택 알고리즘은 증명(attestation)의 가중치가 가장 큰 체인을 형성하는 블록을 선택합니다(여기서 가중치는 증명하는 검증자의 수에 ETH 잔액을 곱한 값입니다). #### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#pos-security) 보안 지분 증명 시스템은 체인을 장악하려는 공격자가 엄청난 양의 ETH를 파괴해야 하므로 암호화폐 경제적으로 안전합니다. 보상 시스템은 개별 스테이킹 참여자가 정직하게 행동하도록 장려하고, 벌칙은 스테이킹 참여자가 악의적으로 행동하는 것을 억제합니다. [지분 증명](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/) 에 대해 자세히 알아보기 ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#types-of-consensus-video) 시각적 가이드 이더리움에서 사용되는 다양한 유형의 합의 메커니즘에 대해 자세히 시청하세요. ### Understanding blockchain consensus mechanisms An explainer covering the core consensus mechanisms used in blockchains, and how they enable decentralized networks to agree on the state of transactions without a central authority. [대본과 함께 시청하기](https://ethereum.org/ko/videos/understanding-consensus-mechanisms/)   ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#sybil-chain) 시빌 저항성 및 체인 선택 작업증명과 지분 증명만으로는 합의 프로토콜이 아니지만, 단순성을 위해 종종 그렇게 불립니다. 이들은 실제로는 시빌 저항성 메커니즘이자 블록 작성자 선택기입니다. 즉, 최신 블록의 작성자가 누구인지 결정하는 방법입니다. 또 다른 중요한 구성 요소는 동일한 위치에 여러 블록이 존재하는 시나리오에서 노드가 체인의 헤드에서 단일한 올바른 블록을 선택할 수 있도록 하는 체인 선택(일명 포크 선택) 알고리즘입니다. **시빌 저항성(Sybil resistance)**은 프로토콜이 시빌 공격에 어떻게 대처하는지를 측정합니다. 이러한 유형의 공격에 대한 저항성은 탈중앙화된 블록체인에 필수적이며, 채굴자와 검증자가 투입한 자원을 기반으로 동등하게 보상받을 수 있도록 합니다. 작업증명과 지분 증명은 사용자가 많은 에너지를 소비하거나 많은 담보를 제공하도록 함으로써 이를 방어합니다. 이러한 보호 장치는 시빌 공격에 대한 경제적 억지력입니다. **체인 선택 규칙(chain selection rule)**은 어느 체인이 "올바른" 체인인지 결정하는 데 사용됩니다. 비트코인은 "가장 긴 체인(longest chain)" 규칙을 사용하는데, 이는 가장 긴 블록체인이 나머지 노드들이 유효하다고 수용하고 작업할 체인이 된다는 것을 의미합니다. 작업증명 체인의 경우, 가장 긴 체인은 체인의 총 누적 작업증명 난이도에 의해 결정됩니다. 이더리움도 예전에는 가장 긴 체인 규칙을 사용했습니다. 하지만 이제 이더리움은 지분 증명으로 실행되므로 체인의 '가중치'를 측정하는 업데이트된 포크 선택 알고리즘을 채택했습니다. 가중치는 검증자의 스테이킹된 이더 잔액으로 가중치가 부여된 검증자 투표의 누적 합계입니다. 이더리움은 [캐스퍼 FFG 지분 증명 (새 탭에서 열림)](https://arxiv.org/abs/1710.09437) 과 [GHOST 포크 선택 규칙 (새 탭에서 열림)](https://arxiv.org/abs/2003.03052) 을 결합한 [Gasper](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/gasper/) 라는 합의 메커니즘을 사용합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#further-reading) 더 읽을거리 ---------------------------------------------------------------------------------------- * [블록체인 합의 알고리즘이란 무엇인가요? (새 탭에서 열림)](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm) * [나카모토 합의란 무엇인가요? 완전 초보자 가이드 (새 탭에서 열림)](https://blockonomi.com/nakamoto-consensus/) * [Casper는 어떻게 작동하나요? (새 탭에서 열림)](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d) * [작업증명 블록체인의 보안 및 성능에 관하여 (새 탭에서 열림)](https://eprint.iacr.org/2016/555.pdf) * [비잔틴 장애(Byzantine fault) (새 탭에서 열림)](https://en.wikipedia.org/wiki/Byzantine_fault) _도움이 된 커뮤니티 리소스를 알고 계신가요? 이 페이지를 편집하여 추가해 주세요!_ [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/#related-topics) 관련 주제 -------------------------------------------------------------------------------------- * [작업증명](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/) * [채굴](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/) * [지분 증명](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/) * [권위 증명(PoA)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/poa/) --- # Dart開発者のためのイーサリアム | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/programming-languages/dart/#main-content) Change page Dart開発者のためのイーサリアム ================= .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/dart/index.md) このページの内容 [](https://ethereum.org/ja/developers/docs/programming-languages/dart/#getting-started-with-smart-contracts-and-solidity) スマート・コントラクトとSolidity言語の入門 --------------------------------------------------------------------------------------------------------------------------------------------------- [](https://ethereum.org/ja/developers/docs/programming-languages/dart/#tutorials) チュートリアル ----------------------------------------------------------------------------------------- * [Flutterとブロックチェーン – Hello World Dapp （新しいタブで開きます）](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) では、始めるためのすべての手順を説明しています。 1. [Solidity （新しいタブで開きます）](https://soliditylang.org/) でスマート・コントラクトを書く 2. Dartでユーザーインターフェースを書く * [Flutterを使ったモバイル分散型アプリケーション (dapp) の構築 （新しいタブで開きます）](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) ははるかに短く、すでに基礎を知っている場合に適しているかもしれません。 * 動画で学ぶ方が好きな場合は、約1時間の[初めてのブロックチェーンFlutterアプリの構築 （新しいタブで開きます）](https://www.youtube.com/watch?v=3Eeh3pJ6PeA) を視聴できます。 * 手っ取り早く学びたい場合は、約20分の[イーサリアム上でFlutterとDartを使ったブロックチェーン分散型アプリケーションの構築 （新しいタブで開きます）](https://www.youtube.com/watch?v=jaMFEOCq_1s) がおすすめです。 * [WalletConnectのWeb3Modalを使用したFlutterアプリケーションへのメタマスクの統合 （新しいタブで開きます）](https://www.youtube.com/watch?v=v_M2buHCpc4) - この短い動画では、WalletConnectの[Web3Modal （新しいタブで開きます）](https://pub.dev/packages/web3modal_flutter) ライブラリを使用して、Flutterアプリケーションにメタマスクを統合する手順を説明しています。 * [SolidityとFlutterを使ったモバイルブロックチェーン開発者ブートキャンプコース （新しいタブで開きます）](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - フルスタックのモバイルブロックチェーン開発者向けコースのプレイリスト [](https://ethereum.org/ja/developers/docs/programming-languages/dart/#working-with-ethereum-clients) イーサリアムクライアントの操作 --------------------------------------------------------------------------------------------------------------------- イーサリアムを使用すると、暗号資産とブロックチェーン技術の利点を活用した分散型アプリケーション (dapp) を作成できます。 現在、Dartでイーサリアムの[JSON-RPC API](https://ethereum.org/ja/developers/docs/apis/json-rpc/) を使用するためにメンテナンスされているライブラリが少なくとも2つあります。 1. [pwa.irのWeb3dart （新しいタブで開きます）](https://pub.dev/packages/web3dart) 2. [darticulate.comのEthereum 5.0.0 （新しいタブで開きます）](https://pub.dev/packages/ethereum) また、特定のイーサリアムアドレスを操作したり、さまざまな暗号資産の価格を取得したりできる追加のライブラリもあります。 [完全なリストはこちらで確認できます （新しいタブで開きます）](https://pub.dev/dart/packages?q=ethereum) 。 --- # Elixir開発者のためのイーサリアム | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/programming-languages/elixir/#main-content) Change page Elixir開発者のためのイーサリアム =================== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/elixir/index.md) このページの内容 Elixirベースのプロジェクトやツールを使用して、イーサリアム向けに開発する方法を学びます。 イーサリアムを使用して、暗号資産とブロックチェーン技術の利点を活用した分散型アプリケーション (dapp) を作成します。これらのdappはトラストレスにすることができます。つまり、一度イーサリアムにデプロイされると、常にプログラムされた通りに実行されます。デジタル資産を制御して、新しい種類の金融アプリケーションを作成できます。また、分散型であるため、単一の組織や個人が制御することはなく、検閲することはほぼ不可能です。 [](https://ethereum.org/ja/developers/docs/programming-languages/elixir/#getting-started-with-smart-contracts-and-solidity) スマート・コントラクトとSolidity言語の基礎 ----------------------------------------------------------------------------------------------------------------------------------------------------- **Elixirとイーサリアムを統合するための第一歩を踏み出しましょう** まずはより基本的な入門書が必要ですか？ [ethereum.org/learn](https://ethereum.org/ja/learn/) または [ethereum.org/developers](https://ethereum.org/ja/developers/) を確認してください。 * [ブロックチェーンの解説 （新しいタブで開きます）](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [スマート・コントラクトの理解 （新しいタブで開きます）](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [初めてのスマート・コントラクトを作成する （新しいタブで開きます）](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Solidityのコンパイルとデプロイ方法を学ぶ （新しいタブで開きます）](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) [](https://ethereum.org/ja/developers/docs/programming-languages/elixir/#beginner-articles) 初心者向け記事 --------------------------------------------------------------------------------------------------- * [イーサリアムのアカウントを完全に理解する （新しいタブで開きます）](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) * [Ethers — Elixir向けのファーストクラスのイーサリアムWeb3ライブラリ （新しいタブで開きます）](https://medium.com/@alisinabh/announcing-ethers-a-first-class-ethereum-web3-library-for-elixir-1d64e9409122) [](https://ethereum.org/ja/developers/docs/programming-languages/elixir/#intermediate-articles) 中級者向け記事 ------------------------------------------------------------------------------------------------------- * [Elixirで生のイーサリアムコントラクトトランザクションに署名する方法 （新しいタブで開きます）](https://kohlerjp.medium.com/how-to-sign-raw-ethereum-contract-transactions-with-elixir-f8822bcc813b) * [イーサリアムのスマート・コントラクトとElixir （新しいタブで開きます）](https://medium.com/agile-alpha/ethereum-smart-contracts-and-elixir-c7c4b239ddb4) [](https://ethereum.org/ja/developers/docs/programming-languages/elixir/#elixir-projects-and-tools) Elixirのプロジェクトとツール --------------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ja/developers/docs/programming-languages/elixir/#active) アクティブ * [block\_keys （新しいタブで開きます）](https://github.com/ExWeb3/block_keys) - _ElixirでのBIP32およびBIP44の実装 (決定論的ウォレットのためのマルチアカウント階層)_ * [ethereumex （新しいタブで開きます）](https://github.com/mana-ethereum/ethereumex) - _イーサリアムブロックチェーン用のElixir JSON-RPCクライアント_ * [ethers （新しいタブで開きます）](https://github.com/ExWeb3/elixir_ethers) - _Elixirを使用してイーサリアム上のスマート・コントラクトと対話するための包括的なWeb3ライブラリ_ * [ethers\_kms （新しいタブで開きます）](https://github.com/ExWeb3/elixir_ethers_kms) - _Ethers用のKMS署名ライブラリ (AWS KMSでトランザクションに署名)_ * [ex\_abi （新しいタブで開きます）](https://github.com/poanetwork/ex_abi) - _ElixirでのイーサリアムABIパーサー/デコーダー/エンコーダーの実装_ * [ex\_keccak （新しいタブで開きます）](https://github.com/ExWeb3/ex_keccak) - _NIFでビルドされたtiny-keccak Rustクレートを使用してKeccak SHA3-256ハッシュを計算するためのElixirライブラリ_ * [ex\_rlp （新しいタブで開きます）](https://github.com/mana-ethereum/ex_rlp) - _イーサリアムのRLP (Recursive Length Prefix) エンコーディングのElixir実装_ ### [](https://ethereum.org/ja/developers/docs/programming-languages/elixir/#archived--no-longer-maintained) アーカイブ済み / メンテナンス終了 * [eth （新しいタブで開きます）](https://hex.pm/packages/eth) - _Elixir用のイーサリアムユーティリティ_ * [exw3 （新しいタブで開きます）](https://github.com/hswick/exw3) - _Elixir用の高レベルイーサリアムRPCクライアント_ * [mana （新しいタブで開きます）](https://github.com/mana-ethereum/mana) - _Elixirで書かれたイーサリアムのフル・ノード実装_ さらにリソースをお探しですか？ [開発者向けホーム](https://ethereum.org/ja/developers/) をご覧ください。 [](https://ethereum.org/ja/developers/docs/programming-languages/elixir/#elixir-community-contributors) Elixirコミュニティの貢献者 ------------------------------------------------------------------------------------------------------------------------ [ElixirのSlack #ethereum チャンネル （新しいタブで開きます）](https://elixir-lang.slack.com/archives/C5RPZ3RJL) は、急速に成長しているコミュニティのホストであり、上記のプロジェクトや関連トピックに関する議論のための専用リソースです。 --- # 지분 증명(PoS) 대 작업증명(PoW) | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/pos-vs-pow/#main-content) Change page 지분 증명(PoS) 대 작업증명(PoW) ====================== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md) 이 페이지의 내용 [이더리움](https://ethereum.org/ko/) 이 출시되었을 때, 지분 증명(PoS)이 이더리움을 안전하게 보호할 수 있을 만큼 신뢰를 얻기 위해서는 여전히 많은 연구와 개발이 필요했습니다. 작업증명(PoW)은 비트코인에 의해 이미 검증된 더 단순한 메커니즘이었기 때문에, 핵심 개발자들은 이를 즉시 구현하여 이더리움을 출시할 수 있었습니다. 지분 증명을 구현할 수 있는 수준으로 개발하는 데는 8년이 더 걸렸습니다. 이 페이지는 이더리움이 작업증명에서 지분 증명으로 전환한 이유와 그에 따른 장단점을 설명합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/pos-vs-pow/#security) 보안 -------------------------------------------------------------------------------------------- 이더리움 연구자들은 지분 증명이 작업증명보다 더 안전하다고 생각합니다. 하지만 실제 이더리움 메인넷에 구현된 지 얼마 되지 않았으며, 작업증명에 비해 시간이 지나면서 검증된 정도는 덜합니다. 다음 섹션에서는 작업증명과 비교하여 지분 증명 보안 모델의 장단점을 논의합니다. ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/pos-vs-pow/#cost-to-attack) 공격 비용 지분 증명에서 검증자는 스마트 컨트랙트에 최소 32 ETH를 예치("스테이킹")해야 합니다. 이더리움은 잘못된 행동을 하는 검증자를 처벌하기 위해 스테이킹된 이더를 소각할 수 있습니다. 합의에 도달하려면 전체 스테이킹된 이더의 최소 66%가 특정 블록 세트에 찬성 투표를 해야 합니다. 66% 이상의 스테이크가 투표한 블록은 "완결된" 상태가 되며, 이는 해당 블록을 제거하거나 재구성할 수 없음을 의미합니다. 네트워크를 공격한다는 것은 체인이 완결되는 것을 막거나, 공격자에게 유리한 방식으로 정규 체인 내 블록의 특정 구성을 보장하는 것을 의미할 수 있습니다. 이를 위해 공격자는 대량의 이더를 축적하여 직접 투표하거나, 정직한 검증자가 특정 방식으로 투표하도록 속여 정직한 합의 경로를 우회해야 합니다. 정직한 검증자를 속이는 정교하고 확률이 낮은 공격을 제외하면, 이더리움을 공격하는 비용은 공격자가 합의를 자신에게 유리하게 이끌기 위해 축적해야 하는 스테이크의 비용과 같습니다. 가장 낮은 공격 비용은 전체 스테이크의 33%를 초과하는 것입니다. 전체 스테이크의 33% 이상을 보유한 공격자는 단순히 오프라인 상태가 되는 것만으로도 완결성 지연을 유발할 수 있습니다. 이는 네트워크에 비교적 사소한 문제인데, 온라인 상태의 다수가 스테이크의 66%를 차지하여 체인을 다시 완결할 수 있을 때까지 오프라인 검증자의 스테이크를 누수시키는 "비활동 누수"라는 메커니즘이 있기 때문입니다. 또한 공격자가 블록 생성자로 지정되었을 때 하나 대신 두 개의 블록을 생성하고 모든 검증자를 동원해 이중 투표를 함으로써, 전체 스테이크의 33%를 조금 넘는 비율로 이중 완결성을 유발하는 것도 이론적으로 가능합니다. 각 포크는 남은 정직한 검증자의 50%가 각 블록을 먼저 보기만 하면 되므로, 메시지 타이밍을 정확히 맞춘다면 두 포크 모두 완결시킬 수도 있습니다. 이는 성공 가능성이 낮지만, 공격자가 이중 완결성을 유발할 수 있다면 이더리움 커뮤니티는 하나의 포크를 따르기로 결정해야 하며, 이 경우 다른 포크에 있는 공격자의 검증자는 반드시 슬래싱을 당하게 됩니다. 전체 스테이크의 33%를 초과하면, 공격자는 이더리움 네트워크에 경미한(완결성 지연) 또는 더 심각한(이중 완결성) 영향을 미칠 기회를 얻게 됩니다. 네트워크에 14,000,000 ETH 이상이 스테이킹되어 있고 대표 가격이 $1000/ETH라고 가정할 때, 이러한 공격을 시도하는 데 드는 최소 비용은 `1000 x 14,000,000 x 0.33 = $4,620,000,000`입니다. 공격자는 슬래싱을 통해 이 자금을 잃고 네트워크에서 퇴출당하게 됩니다. 다시 공격하려면 33% 이상의 스테이크를 (다시) 축적하고 (다시) 소각해야 합니다. 네트워크를 공격하려는 각 시도에는 46억 달러 이상이 소요됩니다($1000/ETH 및 1400만 ETH 스테이킹 기준). 공격자는 슬래싱을 당할 때 네트워크에서 퇴출되며, 다시 참여하려면 활성화 대기열에 합류해야 합니다. 이는 반복 공격의 속도가 공격자가 전체 스테이크의 33% 이상을 축적할 수 있는 속도뿐만 아니라 모든 검증자를 네트워크에 온보딩하는 데 걸리는 시간에도 제한을 받는다는 것을 의미합니다. 공격자가 공격할 때마다 그들은 훨씬 더 가난해지고, 그에 따른 공급 충격 덕분에 나머지 커뮤니티는 더 부유해집니다. 51% 공격이나 전체 스테이크의 66%를 이용한 완결성 되돌리기와 같은 다른 공격은 훨씬 더 많은 ETH를 필요로 하며 공격자에게 훨씬 더 많은 비용을 초래합니다. 이를 작업증명과 비교해 보십시오. 작업증명 이더리움에서 공격을 시작하는 비용은 전체 네트워크 해시레이트의 50% 이상을 지속적으로 소유하는 비용이었습니다. 이는 작업증명 솔루션을 지속적으로 계산하기 위해 다른 채굴자들을 압도할 수 있는 충분한 컴퓨팅 파워의 하드웨어 및 운영 비용에 해당했습니다. 이더리움은 주로 ASIC이 아닌 GPU를 사용하여 채굴되었기 때문에 비용이 낮게 유지되었습니다(이더리움이 작업증명을 유지했다면 ASIC 채굴이 더 대중화되었을 수도 있습니다). 적대자는 작업증명 이더리움 네트워크를 공격하기 위해 많은 하드웨어를 구매하고 이를 실행할 전기 요금을 지불해야 하지만, 총 비용은 공격을 시작하기에 충분한 ETH를 축적하는 데 필요한 비용보다 적을 것입니다. 51% 공격은 지분 증명보다 작업증명에서 약 [20배 덜 (새 탭에서 열림)](https://youtu.be/1m12zgJ42dI?t=1562) 비쌉니다. 공격이 감지되고 체인이 하드 포크되어 변경 사항이 제거되더라도, 공격자는 동일한 하드웨어를 반복적으로 사용하여 새로운 포크를 공격할 수 있습니다. ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/pos-vs-pow/#complexity) 복잡성 지분 증명은 작업증명보다 훨씬 더 복잡합니다. 더 단순한 프로토콜에는 우연히 버그나 의도치 않은 영향을 도입하기가 더 어렵기 때문에 이는 작업증명에 유리한 점이 될 수 있습니다. 하지만 수년간의 연구 개발, 시뮬레이션 및 테스트넷 구현을 통해 이러한 복잡성을 길들였습니다. 지분 증명 프로토콜은 5개의 개별 팀(실행 및 합의 계층 각각)에 의해 5가지 프로그래밍 언어로 독립적으로 구현되어 클라이언트 버그에 대한 복원력을 제공합니다. 지분 증명 합의 로직을 안전하게 개발하고 테스트하기 위해, 이더리움 메인넷에 지분 증명이 구현되기 2년 전에 비콘 체인이 출시되었습니다. 비콘 체인은 실제 이더리움 트랜잭션을 건드리지 않고 지분 증명 합의 로직을 구현하는 라이브 블록체인이었기 때문에 지분 증명 테스트를 위한 샌드박스 역할을 했습니다. 사실상 자체적으로 합의에 도달하는 것뿐이었습니다. 이것이 충분한 시간 동안 안정적이고 버그 없이 유지된 후, 비콘 체인은 이더리움 메인넷과 "병합(merged)"되었습니다. 이 모든 과정은 의도치 않은 결과나 클라이언트 버그의 위험이 매우 낮아질 정도로 지분 증명의 복잡성을 길들이는 데 기여했습니다. ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/pos-vs-pow/#attack-surface) 공격 표면 지분 증명은 작업증명보다 복잡하며, 이는 처리해야 할 잠재적인 공격 벡터가 더 많다는 것을 의미합니다. 클라이언트를 연결하는 하나의 피어 투 피어 네트워크 대신, 각각 별도의 프로토콜을 구현하는 두 개의 네트워크가 있습니다. 각 슬롯에서 블록을 제안할 특정 검증자 한 명을 미리 선택하는 것은 대량의 네트워크 트래픽이 해당 특정 검증자를 오프라인으로 만드는 서비스 거부(DoS) 공격의 가능성을 만듭니다. 또한 공격자가 블록이나 증명의 릴리스 타이밍을 신중하게 조절하여 정직한 네트워크의 특정 비율이 이를 수신하게 함으로써 특정 방식으로 투표하도록 영향을 미치는 방법도 있습니다. 마지막으로, 공격자는 단순히 스테이킹할 충분한 ETH를 축적하여 합의 메커니즘을 지배할 수 있습니다. 이러한 각각의 [공격 벡터에는 관련된 방어 수단이 있지만](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/attack-and-defense/) , 작업증명 하에서는 방어해야 할 대상 자체가 존재하지 않습니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/pos-vs-pow/#decentralization) 탈중앙화 ------------------------------------------------------------------------------------------------------ 채굴 하드웨어 군비 경쟁은 개인과 소규모 조직을 시장에서 밀어내는 경향이 있기 때문에 지분 증명은 작업증명보다 더 탈중앙화되어 있습니다. 기술적으로는 누구나 적당한 하드웨어로 채굴을 시작할 수 있지만, 기관 채굴 운영에 비해 보상을 받을 가능성은 희박합니다. 지분 증명에서는 스테이킹 비용과 해당 스테이크에 대한 수익률이 모든 사람에게 동일합니다. 현재 검증자를 실행하는 데는 32 ETH가 필요합니다. 반면에 유동성 스테이킹 파생상품의 발명은 소수의 대형 제공업체가 대량의 스테이킹된 ETH를 관리하기 때문에 중앙화에 대한 우려를 낳았습니다. 이는 문제가 있으며 가능한 한 빨리 수정되어야 하지만, 겉보기보다 더 미묘한 문제이기도 합니다. 중앙화된 스테이킹 제공업체가 반드시 검증자에 대한 중앙화된 통제권을 갖는 것은 아닙니다. 종종 이는 모든 참가자가 각자 32 ETH를 요구하지 않고도 많은 독립적인 노드 운영자가 스테이킹할 수 있는 중앙 ETH 풀을 만드는 방법일 뿐입니다. 이더리움을 위한 최선의 선택은 검증자가 가정용 컴퓨터에서 로컬로 실행되어 탈중앙화를 극대화하는 것입니다. 이것이 이더리움이 노드/검증자를 실행하기 위한 하드웨어 요구 사항을 증가시키는 변경에 저항하는 이유입니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/pos-vs-pow/#sustainability) 지속 가능성 ------------------------------------------------------------------------------------------------------ 지분 증명은 탄소 배출이 적은 방식으로 블록체인을 보호합니다. 작업증명 하에서 채굴자들은 블록을 채굴할 권리를 얻기 위해 경쟁합니다. 채굴자들은 계산을 더 빨리 수행할 수 있을 때 더 성공적이며, 이는 하드웨어 투자와 에너지 소비를 장려합니다. 이는 지분 증명으로 전환하기 전의 이더리움에서 관찰되었습니다. 지분 증명으로 전환하기 직전에 이더리움은 연간 약 78 TWh를 소비하고 있었는데, 이는 소규모 국가와 맞먹는 양이었습니다. 하지만 지분 증명으로 전환하면서 이 에너지 소비를 약 99.98% 줄였습니다. 지분 증명은 이더리움을 에너지 효율적이고 탄소 배출이 적은 플랫폼으로 만들었습니다. [이더리움의 에너지 소비에 대해 더 알아보기](https://ethereum.org/ko/energy-consumption/) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/pos-vs-pow/#issuance) 발행 -------------------------------------------------------------------------------------------- 지분 증명 이더리움은 검증자가 높은 전기 요금을 지불할 필요가 없기 때문에 작업증명 이더리움보다 훨씬 적은 코인을 발행하여 보안 비용을 지불할 수 있습니다. 결과적으로 ETH는 인플레이션을 줄이거나 대량의 ETH가 소각될 때 디플레이션 상태가 될 수도 있습니다. 낮은 인플레이션 수준은 이더리움의 보안이 작업증명 하에서보다 더 저렴하다는 것을 의미합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/pos-vs-pow/#visual-learner) 시각적인 학습을 선호하시나요? ---------------------------------------------------------------------------------------------------------------- ### The PoW vs. PoS debate Lyn Alden and Justin Drake debate whether proof of work or proof of stake is best suited for creating a global crypto money system, covering economic security, 51% attack recovery, fairness, and the commodity vs. [대본과 함께 시청하기](https://ethereum.org/ko/videos/pow-vs-pos/)   [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/pos-vs-pow/#further-reading) 더 읽을거리 ------------------------------------------------------------------------------------------------------- * [비탈릭의 지분 증명 설계 철학 (새 탭에서 열림)](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) * [비탈릭의 지분 증명 FAQ (새 탭에서 열림)](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) * [PoS 대 PoW에 대한 "Simply Explained" 비디오 (새 탭에서 열림)](https://www.youtube.com/watch?v=M3EFi_POhps) --- # 이더리움 아카이브 노드 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/nodes-and-clients/archive-nodes/#main-content) Change page 이더리움 아카이브 노드 ============ .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/nodes-and-clients/archive-nodes/index.md) 이 페이지의 내용 아카이브 노드는 모든 과거 상태의 아카이브를 구축하도록 구성된 [이더리움](https://ethereum.org/ko/) 클라이언트의 인스턴스입니다. 특정 사용 사례에 유용한 도구이지만 풀 노드보다 실행하기가 더 까다로울 수 있습니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/archive-nodes/#prerequisites) 전제 조건 ------------------------------------------------------------------------------------------------ [이더리움 노드](https://ethereum.org/ko/developers/docs/nodes-and-clients/) 의 개념, [아키텍처](https://ethereum.org/ko/developers/docs/nodes-and-clients/node-architecture/) , [동기화 전략](https://ethereum.org/ko/developers/docs/nodes-and-clients/#sync-modes) , 그리고 노드를 [실행](https://ethereum.org/ko/developers/docs/nodes-and-clients/run-a-node/) 하고 [사용하는](https://ethereum.org/ko/developers/docs/apis/json-rpc/) 방법에 대해 이해하고 있어야 합니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/archive-nodes/#what-is-an-archive-node) 아카이브 노드란 무엇인가 ------------------------------------------------------------------------------------------------------------------ 아카이브 노드의 중요성을 파악하기 위해 "상태"의 개념을 명확히 해보겠습니다. 이더리움은 _트랜잭션 기반 상태 머신(transaction-based state machine)_이라고 할 수 있습니다. 이더리움은 트랜잭션을 실행하여 상태를 변경하는 계정과 애플리케이션으로 구성됩니다. 각 계정과 컨트랙트에 대한 정보가 포함된 전역 데이터는 상태라는 트라이(trie) 데이터베이스에 저장됩니다. 이는 실행 계층(EL) 클라이언트에서 처리하며 다음을 포함합니다: * 계정 잔액 및 논스(nonce) * 컨트랙트 코드 및 스토리지 * 합의 관련 데이터 (예: 스테이킹 예치금 컨트랙트) 네트워크와 상호작용하고 새로운 블록을 검증 및 생성하기 위해, 이더리움 클라이언트는 가장 최근의 변경 사항(체인의 끝)과 현재 상태를 계속 파악해야 합니다. 풀 노드로 구성된 실행 계층 클라이언트는 네트워크의 최신 상태를 검증하고 따르지만, 체인 재구성을 처리하고 최근 데이터에 빠르게 접근할 수 있도록 최근 몇 개의 상태(예: 마지막 128개 블록과 관련된 상태)만 캐시합니다. 최근 상태는 모든 클라이언트가 들어오는 트랜잭션을 검증하고 네트워크를 사용하는 데 필요한 것입니다. 상태를 특정 블록에서의 순간적인 네트워크 스냅샷으로, 아카이브를 과거 기록의 재생으로 생각할 수 있습니다. 과거 상태는 네트워크 작동에 필요하지 않으며 클라이언트가 모든 오래된 데이터를 보관하는 것은 불필요하게 중복되므로 안전하게 프루닝(pruning)할 수 있습니다. 최근 블록(예: 헤드에서 128개 블록 이전) 이전에 존재했던 상태는 사실상 버려집니다. 풀 노드는 과거 블록체인 데이터(블록 및 트랜잭션)와 요청 시 이전 상태를 재생성하는 데 사용할 수 있는 간헐적인 과거 스냅샷만 보관합니다. 풀 노드는 EVM에서 과거 트랜잭션을 재실행하여 이 작업을 수행하는데, 원하는 상태가 가장 가까운 스냅샷에서 멀리 떨어져 있을 경우 연산 요구량이 많아질 수 있습니다. 그러나 이는 풀 노드에서 과거 상태에 접근할 때 많은 연산이 소모된다는 것을 의미합니다. 클라이언트는 제네시스(genesis)부터 모든 과거 트랜잭션을 실행하고 하나의 과거 상태를 계산해야 할 수도 있습니다. 아카이브 노드는 가장 최근의 상태뿐만 아니라 각 블록 이후에 생성된 모든 과거 상태를 저장하여 이 문제를 해결합니다. 기본적으로 더 큰 디스크 공간을 요구하는 대신 성능을 얻는 트레이드오프(trade-off)를 합니다. 네트워크가 모든 과거 데이터를 보관하고 제공하기 위해 아카이브 노드에 의존하지 않는다는 점에 유의해야 합니다. 위에서 언급했듯이 모든 과거 중간 상태는 풀 노드에서 파생될 수 있습니다. 트랜잭션은 모든 풀 노드(현재 400GB 미만)에 저장되며 전체 아카이브를 구축하기 위해 재생될 수 있습니다. ### [](https://ethereum.org/ko/developers/docs/nodes-and-clients/archive-nodes/#use-cases) 사용 사례 트랜잭션 전송, 컨트랙트 배포, 합의 검증 등과 같은 이더리움의 일반적인 사용에는 과거 상태에 대한 접근이 필요하지 않습니다. 사용자는 네트워크와의 표준적인 상호작용을 위해 아카이브 노드가 전혀 필요하지 않습니다. 상태 아카이브의 주요 이점은 과거 상태에 대한 쿼리에 빠르게 접근할 수 있다는 것입니다. 예를 들어, 아카이브 노드는 다음과 같은 결과를 즉시 반환합니다: * _블록 15537393에서 계정 0x1337...의 ETH 잔액은 얼마였는가?_ * _블록 1920000에서 컨트랙트 0x에 있는 토큰 0x의 잔액은 얼마인가?_ 위에서 설명한 바와 같이, 풀 노드는 CPU를 사용하고 시간이 걸리는 EVM 실행을 통해 이 데이터를 생성해야 합니다. 아카이브 노드는 디스크에서 이 데이터에 접근하여 즉시 응답을 제공합니다. 이는 인프라의 특정 부분에서 유용한 기능입니다. 예를 들면 다음과 같습니다: * 블록 탐색기와 같은 서비스 제공자 * 연구원 * 보안 분석가 * 탈중앙화 애플리케이션 (dapp) 개발자 * 감사 및 규정 준수 과거 데이터에 접근할 수 있는 다양한 무료 [서비스](https://ethereum.org/ko/developers/docs/nodes-and-clients/nodes-as-a-service/) 도 있습니다. 아카이브 노드를 실행하는 것은 요구 사항이 더 많기 때문에 이러한 접근은 대부분 제한적이며 간헐적인 접근에만 작동합니다. 프로젝트에서 과거 데이터에 지속적으로 접근해야 하는 경우 직접 아카이브 노드를 실행하는 것을 고려해야 합니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/archive-nodes/#implementations-and-usage) 구현 및 사용 -------------------------------------------------------------------------------------------------------------- 이 문맥에서 아카이브 노드는 상태 데이터베이스를 처리하고 JSON-RPC 엔드포인트를 제공하는 사용자 대면 실행 계층 클라이언트가 제공하는 데이터를 의미합니다. 구성 옵션, 동기화 시간 및 데이터베이스 크기는 클라이언트에 따라 다를 수 있습니다. 자세한 내용은 클라이언트에서 제공하는 문서를 참조하세요. 자체 아카이브 노드를 시작하기 전에 클라이언트 간의 차이점, 특히 다양한 [하드웨어 요구 사항](https://ethereum.org/ko/developers/docs/nodes-and-clients/run-a-node/#requirements) 에 대해 알아보세요. 대부분의 클라이언트는 이 기능에 최적화되어 있지 않으며 아카이브에 12TB 이상의 공간이 필요합니다. 반면, 에리곤(Erigon)과 같은 구현은 동일한 데이터를 3TB 미만으로 저장할 수 있어 아카이브 노드를 실행하는 가장 효과적인 방법입니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/archive-nodes/#recommended-practices) 권장 사례 -------------------------------------------------------------------------------------------------------- [노드 실행에 대한 일반적인 권장 사항](https://ethereum.org/ko/developers/docs/nodes-and-clients/run-a-node/) 외에도 아카이브 노드는 하드웨어 및 유지 관리에 더 많은 요구 사항이 있을 수 있습니다. 에리곤의 [주요 기능 (새 탭에서 열림)](https://github.com/ledgerwatch/erigon#key-features) 을 고려할 때 가장 실용적인 접근 방식은 [에리곤](https://ethereum.org/ko/developers/docs/nodes-and-clients/#erigon) 클라이언트 구현을 사용하는 것입니다. ### [](https://ethereum.org/ko/developers/docs/nodes-and-clients/archive-nodes/#hardware) 하드웨어 항상 클라이언트 문서에서 특정 모드에 대한 하드웨어 요구 사항을 확인하세요. 아카이브 노드의 가장 큰 요구 사항은 디스크 공간입니다. 클라이언트에 따라 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) 이상의 신뢰할 수 있는 품질이어야 합니다. 디스크는 데스크톱 컴퓨터나 슬롯이 충분한 서버에 장착할 수 있습니다. 이러한 전용 장치는 높은 가동 시간(uptime)을 유지하는 노드를 실행하는 데 이상적입니다. 노트북에서도 실행할 수 있지만 휴대성으로 인해 추가 비용이 발생합니다. 모든 데이터는 하나의 볼륨에 들어가야 하므로 디스크를 [RAID0 (새 탭에서 열림)](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) 또는 LVM 등으로 결합해야 합니다. 또한 하위 수준의 오류 없이 데이터가 디스크에 올바르게 기록되도록 보장하는 "기록 중 복사(Copy-on-write)"를 지원하는 [ZFS (새 탭에서 열림)](https://en.wikipedia.org/wiki/ZFS) 사용을 고려해 볼 가치가 있습니다. 특히 전문적인 설정에서 우발적인 데이터베이스 손상을 방지하여 안정성과 보안을 높이려면 시스템이 지원하는 경우 [ECC 메모리 (새 탭에서 열림)](https://en.wikipedia.org/wiki/ECC_memory) 사용을 고려하세요. RAM 크기는 일반적으로 풀 노드와 동일하게 권장되지만 RAM이 많을수록 동기화 속도를 높이는 데 도움이 될 수 있습니다. 초기 동기화 중에 아카이브 모드의 클라이언트는 제네시스 이후의 모든 트랜잭션을 실행합니다. 실행 속도는 대부분 CPU에 의해 제한되므로 더 빠른 CPU는 초기 동기화 시간에 도움이 될 수 있습니다. 일반적인 소비자용 컴퓨터의 경우 초기 동기화에 최대 한 달이 걸릴 수 있습니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/archive-nodes/#further-reading) 추가 읽을거리 ---------------------------------------------------------------------------------------------------- * [이더리움 풀 노드 대 아카이브 노드(Ethereum Full Node vs Archive Node) (새 탭에서 열림)](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) - _QuickNode, 2022년 9월_ * [나만의 이더리움 아카이브 노드 구축하기(Building Your Own Ethereum Archive Node) (새 탭에서 열림)](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) - _Thomas Jay Rush, 2021년 8월_ * [에리곤, 에리곤의 RPC 및 TrueBlocks(스크랩 및 API)를 서비스로 설정하는 방법(How to set up Erigon, Erigon’s RPC and TrueBlocks (scrape and API) as services) (새 탭에서 열림)](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– Magnus Hansson, 2022년 9월 업데이트_ [](https://ethereum.org/ko/developers/docs/nodes-and-clients/archive-nodes/#related-topics) 관련 주제 ------------------------------------------------------------------------------------------------- * [노드 및 클라이언트](https://ethereum.org/ko/developers/docs/nodes-and-clients/) * [노드 실행하기](https://ethereum.org/ko/developers/docs/nodes-and-clients/run-a-node/) --- # JavaScript 개발자를 위한 이더리움 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/programming-languages/javascript/#main-content) Change page JavaScript 개발자를 위한 이더리움 ======================= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/javascript/index.md) 이 페이지의 내용 JavaScript는 이더리움 생태계에서 가장 인기 있는 언어 중 하나입니다. 실제로 가능한 한 많은 이더리움 기능을 JavaScript로 가져오기 위해 전념하는 [팀 (새 탭에서 열림)](https://github.com/ethereumjs) 이 있습니다. [스택의 모든 수준](https://ethereum.org/ko/developers/docs/ethereum-stack/) 에서 JavaScript(또는 이와 유사한 언어)를 작성할 기회가 있습니다. [](https://ethereum.org/ko/developers/docs/programming-languages/javascript/#interact-with-ethereum) 이더리움과 상호 작용 ---------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ko/developers/docs/programming-languages/javascript/#javascript-api-libraries) JavaScript API 라이브러리 블록체인을 쿼리하고, 트랜잭션을 전송하는 등의 작업을 위해 JavaScript를 작성하려는 경우, 가장 편리한 방법은 [JavaScript API 라이브러리](https://ethereum.org/ko/developers/docs/apis/javascript/) 를 사용하는 것입니다. 이러한 API를 통해 개발자는 [이더리움 네트워크의 노드](https://ethereum.org/ko/developers/docs/nodes-and-clients/) 와 쉽게 상호 작용할 수 있습니다. 이러한 라이브러리를 사용하여 이더리움의 스마트 컨트랙트와 상호 작용할 수 있으므로, JavaScript만 사용하여 기존 컨트랙트와 상호 작용하는 탈중앙화 애플리케이션 (dapp)을 구축할 수 있습니다. **확인해 보기** * [Web3.js (새 탭에서 열림)](https://web3js.readthedocs.io/) * [Ethers.js (새 탭에서 열림)](https://ethers.org/) – _JavaScript 및 TypeScript로 작성된 이더리움 지갑 구현 및 유틸리티를 포함합니다._ * [viem (새 탭에서 열림)](https://viem.sh/) – _이더리움과 상호 작용하기 위한 저수준의 무상태(stateless) 기본 요소를 제공하는 이더리움용 TypeScript 인터페이스입니다._ * [Drift (새 탭에서 열림)](https://ryangoree.github.io/drift/) – _Web3 라이브러 전반에서 손쉬운 이더리움 개발을 위해 내장 캐싱, 훅(hook) 및 테스트 모의(mock) 객체를 제공하는 TypeScript 메타 라이브러리입니다._ ### [](https://ethereum.org/ko/developers/docs/programming-languages/javascript/#smart-contracts) 스마트 컨트랙트 JavaScript 개발자로서 자신만의 스마트 컨트랙트를 작성하고 싶다면 [Solidity (새 탭에서 열림)](https://solidity.readthedocs.io/) 에 익숙해지는 것이 좋습니다. 이는 가장 인기 있는 스마트 컨트랙트 언어이며 구문이 JavaScript와 유사하여 더 쉽게 배울 수 있습니다. [스마트 컨트랙트](https://ethereum.org/ko/developers/docs/smart-contracts/) 에 대해 자세히 알아보기. [](https://ethereum.org/ko/developers/docs/programming-languages/javascript/#understand-the-protocol) 프로토콜 이해하기 --------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ko/developers/docs/programming-languages/javascript/#the-ethereum-virtual-machine) 이더리움 가상 머신 [이더리움 가상 머신](https://ethereum.org/ko/developers/docs/evm/) 의 JavaScript 구현체가 있습니다. 이는 최신 포크 규칙을 지원합니다. 포크 규칙은 계획된 업그레이드의 결과로 EVM에 적용된 변경 사항을 의미합니다. 이는 더 잘 이해할 수 있도록 여러 JavaScript 패키지로 나뉘어 있습니다. * 계정 * 블록 * 블록체인 자체 * 트랜잭션 * 기타 등등... 이를 통해 "계정의 데이터 구조는 무엇인가?"와 같은 내용을 이해하는 데 도움이 될 것입니다. 코드를 읽는 것을 선호한다면, 이 JavaScript 코드는 문서를 읽는 것의 훌륭한 대안이 될 수 있습니다. **EVM 확인해 보기** [`@ethereumjs/evm` (새 탭에서 열림)](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm) ### [](https://ethereum.org/ko/developers/docs/programming-languages/javascript/#nodes-and-clients) 노드 및 클라이언트 여러분이 이해할 수 있는 언어인 JavaScript로 이더리움 클라이언트가 어떻게 작동하는지 파헤쳐 볼 수 있는 EthereumJS 클라이언트가 활발히 개발 중입니다! **클라이언트 확인해 보기** [`@ethereumjs/client` (새 탭에서 열림)](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client) [](https://ethereum.org/ko/developers/docs/programming-languages/javascript/#other-projects) 기타 프로젝트 ---------------------------------------------------------------------------------------------------- 이더리움 JavaScript 영역에서는 다음과 같은 다양한 프로젝트도 진행되고 있습니다. * 지갑 유틸리티 라이브러리. * 이더리움 키를 생성, 가져오기 및 내보내는 도구. * 이더리움 황서에 요약된 데이터 구조인 `merkle-patricia-tree`의 구현체. [EthereumJS 저장소 (새 탭에서 열림)](https://github.com/ethereumjs) 에서 가장 관심 있는 내용을 파헤쳐 보세요. [](https://ethereum.org/ko/developers/docs/programming-languages/javascript/#further-reading) 더 읽어보기 ---------------------------------------------------------------------------------------------------- _도움이 된 커뮤니티 리소스를 알고 계신가요? 이 페이지를 편집하여 추가해 주세요!_ --- # 토큰 표준 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/standards/tokens/#main-content) Change page 토큰 표준 ===== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/tokens/index.md) 이 페이지의 내용 [](https://ethereum.org/ko/developers/docs/standards/tokens/#introduction) 소개 ----------------------------------------------------------------------------- 많은 [이더리움](https://ethereum.org/ko/) 개발 표준은 토큰 인터페이스에 중점을 둡니다. 이러한 표준은 스마트 컨트랙트가 조합 가능한 상태를 유지하도록 도와주어, 새로운 프로젝트가 토큰을 발행할 때 기존의 탈중앙화된 거래소 및 애플리케이션과 호환성을 유지할 수 있게 합니다. 토큰 표준은 이더리움 생태계 전반에서 토큰이 어떻게 작동하고 상호작용하는지 정의합니다. 개발자가 불필요한 중복 작업 없이 더 쉽게 개발할 수 있도록 하며, 토큰이 지갑, 거래소, DeFi 플랫폼과 원활하게 작동하도록 보장합니다. 게임, 거버넌스 또는 기타 사용 사례에 관계없이 이러한 표준은 일관성을 제공하고 이더리움을 더욱 상호 연결되게 만듭니다. [](https://ethereum.org/ko/developers/docs/standards/tokens/#prerequisites) 전제 조건 --------------------------------------------------------------------------------- * [이더리움 개발 표준](https://ethereum.org/ko/developers/docs/standards/) * [스마트 컨트랙트](https://ethereum.org/ko/developers/docs/smart-contracts/) [](https://ethereum.org/ko/developers/docs/standards/tokens/#token-standards) 토큰 표준 ----------------------------------------------------------------------------------- 다음은 이더리움에서 가장 인기 있는 토큰 표준 중 일부입니다: * [ERC-20](https://ethereum.org/ko/developers/docs/standards/tokens/erc-20/) - 투표 토큰, 스테이킹 토큰 또는 가상 통화와 같은 대체 가능(상호 교환 가능) 토큰을 위한 표준 인터페이스입니다. ### [](https://ethereum.org/ko/developers/docs/standards/tokens/#nft-standards) NFT 표준 * [ERC-721](https://ethereum.org/ko/developers/docs/standards/tokens/erc-721/) - 예술 작품이나 노래의 소유권 증명서와 같은 대체 불가능 토큰을 위한 표준 인터페이스입니다. * [ERC-1155](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/) - ERC-1155는 더 효율적인 거래와 트랜잭션 묶음을 가능하게 하여 비용을 절감합니다. 이 토큰 표준을 사용하면 유틸리티 토큰($BNB 또는 $BAT 등)과 CryptoPunks와 같은 대체 불가능 토큰을 모두 생성할 수 있습니다. [ERC (새 탭에서 열림)](https://eips.ethereum.org/erc) 제안의 전체 목록입니다. 더 읽어보기 ------ _도움이 된 커뮤니티 리소스를 알고 계신가요? 이 페이지를 편집하여 추가해 주세요!_ * [토큰 통합 체크리스트 (새 탭에서 열림)](https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/token_integration.md) - _Trail of Bits_ * [오픈제플린 문서: 토큰 (새 탭에서 열림)](https://docs.openzeppelin.com/contracts/5.x/tokens) - _오픈제플린_ * [토큰 통합의 위험성 (PDF) (새 탭에서 열림)](https://github.com/OpenZeppelin/workshops/blob/master/11-dangers-token-integration/slides.pdf) - _오픈제플린_ [](https://ethereum.org/ko/developers/docs/standards/tokens/#related-tutorials) 관련 튜토리얼 --------------------------------------------------------------------------------------- * [토큰 통합 체크리스트](https://ethereum.org/ko/developers/tutorials/token-integration-checklist/) _– 토큰과 상호작용할 때 고려해야 할 사항들의 체크리스트입니다._ * [ERC20 토큰 스마트 컨트랙트 이해하기](https://ethereum.org/ko/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– 이더리움 테스트 네트워크에 첫 스마트 컨트랙트를 배포하는 방법에 대한 소개입니다._ * [Solidity 스마트 컨트랙트에서 ERC20 토큰 전송 및 승인](https://ethereum.org/ko/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– Solidity 언어를 사용하여 스마트 컨트랙트로 토큰과 상호작용하는 방법입니다._ * [ERC721 마켓 구현하기 \[방법 안내\]](https://ethereum.org/ko/developers/tutorials/how-to-implement-an-erc721-market/) _– 탈중앙화된 광고 게시판에 토큰화된 아이템을 판매용으로 올리는 방법입니다._ --- # Kuboresha mikataba mahiri | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/smart-contracts/upgrading/#main-content) Change page Kuboresha mikataba mahiri ========================= Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/upgrading/index.md) Kwenye ukurasa huu Mikataba mahiri kwenye Ethereum ni programu zinazojitekeleza zenyewe zinazoendeshwa katika Mashine Pepe ya Ethereum (EVM). Programu hizi ni zisizobadilika kwa muundo, jambo ambalo huzuia masasisho yoyote kwenye mantiki ya biashara mara tu mkataba unaposambazwa. Ingawa kutobadilika ni muhimu kwa hali ya kutohitaji kuamini, ugatuzi, na usalama wa mikataba mahiri, inaweza kuwa kikwazo katika baadhi ya matukio. Kwa mfano, msimbo usiobadilika unaweza kufanya iwezekane kwa wasanidi programu kurekebisha mikataba iliyo hatarini. Hata hivyo, utafiti ulioongezeka katika kuboresha mikataba mahiri umesababisha kuanzishwa kwa mifumo kadhaa ya uboreshaji. Mifumo hii ya uboreshaji inawawezesha wasanidi programu kuboresha mikataba mahiri (huku wakihifadhi kutobadilika) kwa kuweka mantiki ya biashara katika mikataba tofauti. [](https://ethereum.org/sw/developers/docs/smart-contracts/upgrading/#prerequisites) Mahitaji ya awali ------------------------------------------------------------------------------------------------------ Unapaswa kuwa na uelewa mzuri wa [mikataba mahiri](https://ethereum.org/sw/developers/docs/smart-contracts/) , [muundo wa mkataba mahiri](https://ethereum.org/sw/developers/docs/smart-contracts/anatomy/) , na [Mashine Pepe ya Ethereum (EVM)](https://ethereum.org/sw/developers/docs/evm/) . Mwongozo huu pia unachukulia kuwa wasomaji wana uelewa wa kuandaa mikataba mahiri. [](https://ethereum.org/sw/developers/docs/smart-contracts/upgrading/#what-is-a-smart-contract-upgrade) Uboreshaji wa mkataba mahiri ni nini? --------------------------------------------------------------------------------------------------------------------------------------------- Uboreshaji wa mkataba mahiri unahusisha kubadilisha mantiki ya biashara ya mkataba mahiri huku ukihifadhi hali ya mkataba. Ni muhimu kufafanua kwamba uwezo wa kuboreshwa na uwezo wa kubadilika si sawa, hasa katika muktadha wa mikataba mahiri. Bado huwezi kubadilisha programu iliyosambazwa kwenye anwani katika mtandao wa Ethereum. Lakini unaweza kubadilisha msimbo unaotekelezwa wakati watumiaji wanaingiliana na mkataba mahiri. Hili linaweza kufanywa kupitia mbinu zifuatazo: 1. Kuunda matoleo mengi ya mkataba mahiri na kuhamisha hali (yaani, data) kutoka kwa mkataba wa zamani hadi mfano mpya wa mkataba. 2. Kuunda mikataba tofauti ili kuhifadhi mantiki ya biashara na hali. 3. Kutumia mifumo ya uwakilishi kukaimisha miito ya fanksheni kutoka kwa mkataba wa uwakilishi usiobadilika hadi mkataba wa mantiki unaoweza kurekebishwa. 4. Kuunda mkataba mkuu usiobadilika ambao unaingiliana na kutegemea mikataba ya satelaiti inayobadilika ili kutekeleza fanksheni maalum. 5. Kutumia mfumo wa almasi kukaimisha miito ya fanksheni kutoka kwa mkataba wa uwakilishi hadi mikataba ya mantiki. ### [](https://ethereum.org/sw/developers/docs/smart-contracts/upgrading/#contract-migration) Utaratibu wa uboreshaji #1: Uhamishaji wa mkataba Uhamishaji wa mkataba unategemea utoaji wa matoleo—wazo la kuunda na kudhibiti hali za kipekee za programu sawa. Uhamishaji wa mkataba unahusisha kusambaza mfano mpya wa mkataba mahiri uliopo na kuhamisha hifadhi na salio kwenye mkataba mpya. Mkataba uliosambazwa hivi karibuni utakuwa na hifadhi tupu, kukuwezesha kurejesha data kutoka kwa mkataba wa zamani na kuiandika kwenye utekelezaji mpya. Baadaye, utahitaji kusasisha mikataba yote iliyoingiliana na mkataba wa zamani ili kuonyesha anwani mpya. Hatua ya mwisho katika uhamishaji wa mkataba ni kuwashawishi watumiaji kubadili na kutumia mkataba mpya. Toleo jipya la mkataba litahifadhi salio na anwani za watumiaji, jambo ambalo huhifadhi kutobadilika. Ikiwa ni mkataba unaotegemea tokeni, utahitaji pia kuwasiliana na mabadilishano ili kutupa mkataba wa zamani na kutumia mkataba mpya. Uhamishaji wa mkataba ni hatua ya moja kwa moja na salama ya kuboresha mikataba mahiri bila kuvunja mwingiliano wa watumiaji. Hata hivyo, kuhamisha hifadhi na salio la mtumiaji kwa mikono kwenye mkataba mpya kunachukua muda mwingi na kunaweza kuingiza gharama kubwa za gesi. [Zaidi kuhusu uhamishaji wa mkataba. (inafunguka katika kichupo kipya)](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) ### [](https://ethereum.org/sw/developers/docs/smart-contracts/upgrading/#data-separation) Utaratibu wa uboreshaji #2: Utenganishaji wa data Mbinu nyingine ya kuboresha mikataba mahiri ni kutenganisha mantiki ya biashara na hifadhi ya data katika mikataba tofauti. Hii inamaanisha watumiaji wanaingiliana na mkataba wa mantiki, huku data ikihifadhiwa katika mkataba wa hifadhi. Mkataba wa mantiki una msimbo unaotekelezwa wakati watumiaji wanaingiliana na programu. Pia unashikilia anwani ya mkataba wa hifadhi na kuingiliana nao ili kupata na kuweka data. Wakati huo huo, mkataba wa hifadhi unashikilia hali inayohusishwa na mkataba mahiri, kama vile salio na anwani za watumiaji. Kumbuka kwamba mkataba wa hifadhi unamilikiwa na mkataba wa mantiki na umesanidiwa na anwani ya mwisho wakati wa usambazaji. Hii inazuia mikataba isiyoidhinishwa kuita mkataba wa hifadhi au kusasisha data yake. Kwa chaguo-msingi, mkataba wa hifadhi haubadiliki—lakini unaweza kubadilisha mkataba wa mantiki unaoelekeza kwa utekelezaji mpya. Hii itabadilisha msimbo unaoendeshwa katika EVM, huku ukiweka hifadhi na salio sawa. Kutumia mbinu hii ya uboreshaji kunahitaji kusasisha anwani ya mkataba wa mantiki katika mkataba wa hifadhi. Lazima pia usanidi mkataba mpya wa mantiki na anwani ya mkataba wa hifadhi kwa sababu zilizoelezwa hapo awali. Mfumo wa utenganishaji wa data bila shaka ni rahisi kutekeleza ikilinganishwa na uhamishaji wa mkataba. Hata hivyo, itabidi udhibiti mikataba mingi na kutekeleza mipango tata ya uidhinishaji ili kulinda mikataba mahiri dhidi ya uboreshaji mbaya. ### [](https://ethereum.org/sw/developers/docs/smart-contracts/upgrading/#proxy-patterns) Utaratibu wa uboreshaji #3: Mifumo ya uwakilishi Mfumo wa uwakilishi pia unatumia utenganishaji wa data ili kuweka mantiki ya biashara na data katika mikataba tofauti. Hata hivyo, katika mfumo wa uwakilishi, mkataba wa hifadhi (unaoitwa uwakilishi) unaita mkataba wa mantiki wakati wa utekelezaji wa msimbo. Hii ni kinyume cha mbinu ya utenganishaji wa data, ambapo mkataba wa mantiki unaita mkataba wa hifadhi. Hivi ndivyo kinachotokea katika mfumo wa uwakilishi: 1. Watumiaji wanaingiliana na mkataba wa uwakilishi, ambao unahifadhi data, lakini haushikilii mantiki ya biashara. 2. Mkataba wa uwakilishi unahifadhi anwani ya mkataba wa mantiki na kukaimisha miito yote ya fanksheni kwa mkataba wa mantiki (ambao unashikilia mantiki ya biashara) kwa kutumia fanksheni ya `delegatecall`. 3. Baada ya mwito kusambazwa kwa mkataba wa mantiki, data iliyorejeshwa kutoka kwa mkataba wa mantiki inarejeshwa na kurudishwa kwa mtumiaji. Kutumia mifumo ya uwakilishi kunahitaji uelewa wa fanksheni ya **delegatecall**. Kimsingi, `delegatecall` ni msimbo wa operesheni unaoruhusu mkataba kuita mkataba mwingine, huku utekelezaji halisi wa msimbo ukitokea katika muktadha wa mkataba unaoita. Maana ya kutumia `delegatecall` katika mifumo ya uwakilishi ni kwamba mkataba wa uwakilishi unasoma na kuandika kwenye hifadhi yake na kutekeleza mantiki iliyohifadhiwa kwenye mkataba wa mantiki kana kwamba unaita fanksheni ya ndani. Kutoka kwenye [nyaraka za Solidity (inafunguka katika kichupo kipya)](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries) : > _Kuna aina maalum ya mwito wa ujumbe, inayoitwa **delegatecall** ambayo inafanana na mwito wa ujumbe isipokuwa ukweli kwamba msimbo kwenye anwani lengwa unatekelezwa katika muktadha (yaani, kwenye anwani) wa mkataba unaoita na `msg.sender` na `msg.value` hazibadilishi thamani zake._ _Hii inamaanisha kuwa mkataba unaweza kupakia msimbo kwa nguvu kutoka kwa anwani tofauti wakati wa utekelezaji. Hifadhi, anwani ya sasa na salio bado zinarejelea mkataba unaoita, msimbo pekee ndio unachukuliwa kutoka kwa anwani inayoitwa._ Mkataba wa uwakilishi unajua kuita `delegatecall` wakati wowote mtumiaji anapoita fanksheni kwa sababu una fanksheni ya `fallback` iliyojengwa ndani yake. Katika upangaji programu wa Solidity [fanksheni mbadala (inafunguka katika kichupo kipya)](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) inatekelezwa wakati mwito wa fanksheni haulingani na fanksheni zilizobainishwa katika mkataba. Kufanya mfumo wa uwakilishi ufanye kazi kunahitaji kuandika fanksheni mbadala maalum inayobainisha jinsi mkataba wa uwakilishi unapaswa kushughulikia miito ya fanksheni ambayo hauiauni. Katika hali hii fanksheni mbadala ya uwakilishi imepangwa kuanzisha delegatecall na kuelekeza upya ombi la mtumiaji kwenye utekelezaji wa sasa wa mkataba wa mantiki. Mkataba wa uwakilishi haubadiliki kwa chaguo-msingi, lakini mikataba mipya ya mantiki yenye mantiki ya biashara iliyosasishwa inaweza kuundwa. Kufanya uboreshaji basi ni suala la kubadilisha anwani ya mkataba wa mantiki unaorejelewa katika mkataba wa uwakilishi. Kwa kuelekeza mkataba wa uwakilishi kwenye mkataba mpya wa mantiki, msimbo unaotekelezwa wakati watumiaji wanaita fanksheni ya mkataba wa uwakilishi unabadilika. Hii inaturuhusu kuboresha mantiki ya mkataba bila kuwauliza watumiaji kuingiliana na mkataba mpya. Mifumo ya uwakilishi ni mbinu maarufu ya kuboresha mikataba mahiri kwa sababu inaondoa matatizo yanayohusiana na uhamishaji wa mkataba. Hata hivyo, mifumo ya uwakilishi ni ngumu zaidi kutumia na inaweza kuanzisha dosari muhimu, kama vile [migongano ya kiteuzi cha fanksheni (inafunguka katika kichupo kipya)](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357) , ikiwa inatumiwa isivyofaa. [Zaidi kuhusu mifumo ya uwakilishi (inafunguka katika kichupo kipya)](https://blog.openzeppelin.com/proxy-patterns/) . ### [](https://ethereum.org/sw/developers/docs/smart-contracts/upgrading/#strategy-pattern) Utaratibu wa uboreshaji #4: Mfumo wa mkakati Mbinu hii inasukumwa na [mfumo wa mkakati (inafunguka katika kichupo kipya)](https://en.wikipedia.org/wiki/Strategy_pattern) , ambao unahimiza kuunda programu za kompyuta zinazoingiliana na programu nyingine ili kutekeleza vipengele maalum. Kutumia mfumo wa mkakati kwenye uundaji wa Ethereum kungemaanisha kujenga mkataba mahiri unaoita fanksheni kutoka kwa mikataba mingine. Mkataba mkuu katika hali hii una mantiki ya msingi ya biashara, lakini unaingiliana na mikataba mingine mahiri ("mikataba ya satelaiti") ili kutekeleza fanksheni fulani. Mkataba huu mkuu pia unahifadhi anwani kwa kila mkataba wa satelaiti na unaweza kubadili kati ya utekelezaji tofauti wa mkataba wa satelaiti. Unaweza kujenga mkataba mpya wa satelaiti na kusanidi mkataba mkuu na anwani mpya. Hii inakuruhusu kubadilisha _mikakati_ (yaani, kutekeleza mantiki mpya) kwa mkataba mahiri. Ingawa inafanana na mfumo wa uwakilishi uliojadiliwa hapo awali, mfumo wa mkakati ni tofauti kwa sababu mkataba mkuu, ambao watumiaji wanaingiliana nao, unashikilia mantiki ya biashara. Kutumia mfumo huu kunakupa fursa ya kuanzisha mabadiliko machache kwenye mkataba mahiri bila kuathiri miundombinu ya msingi. Kikwazo kikuu ni kwamba mfumo huu ni muhimu zaidi kwa kutoa uboreshaji mdogo. Pia, ikiwa mkataba mkuu umeathiriwa (k.m., kupitia udukuzi), huwezi kutumia mbinu hii ya uboreshaji. ### [](https://ethereum.org/sw/developers/docs/smart-contracts/upgrading/#diamond-pattern) Utaratibu wa uboreshaji #5: Mfumo wa almasi Mfumo wa almasi unaweza kuchukuliwa kama uboreshaji wa mfumo wa uwakilishi. Mifumo ya almasi inatofautiana na mifumo ya uwakilishi kwa sababu mkataba wa uwakilishi wa almasi unaweza kukaimisha miito ya fanksheni kwa zaidi ya mkataba mmoja wa mantiki. Mikataba ya mantiki katika mfumo wa almasi inajulikana kama _facets_. Ili kufanya mfumo wa almasi ufanye kazi, unahitaji kuunda ramani katika mkataba wa uwakilishi inayounganisha [viteuzi vya fanksheni (inafunguka katika kichupo kipya)](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) kwenye anwani tofauti za facet. Mtumiaji anapofanya mwito wa fanksheni, mkataba wa uwakilishi unakagua ramani ili kupata facet inayohusika na kutekeleza fanksheni hiyo. Kisha inaita `delegatecall` (kwa kutumia fanksheni mbadala) na kuelekeza upya mwito kwenye mkataba unaofaa wa mantiki. Mfumo wa uboreshaji wa almasi una baadhi ya faida juu ya mifumo ya jadi ya uboreshaji wa uwakilishi: 1. Inakuruhusu kuboresha sehemu ndogo ya mkataba bila kubadilisha msimbo wote. Kutumia mfumo wa uwakilishi kwa uboreshaji kunahitaji kuunda mkataba mpya kabisa wa mantiki, hata kwa uboreshaji mdogo. 2. Mikataba yote mahiri (ikiwa ni pamoja na mikataba ya mantiki inayotumika katika mifumo ya uwakilishi) ina kikomo cha ukubwa cha 24KB, ambacho kinaweza kuwa kizuizi—hasa kwa mikataba tata inayohitaji fanksheni zaidi. Mfumo wa almasi hurahisisha kutatua tatizo hili kwa kugawanya fanksheni kwenye mikataba mingi ya mantiki. 3. Mifumo ya uwakilishi inachukua mbinu ya kujumuisha yote kwa vidhibiti vya ufikiaji. Huluki iliyo na ufikiaji wa kuboresha fanksheni inaweza kubadilisha mkataba _mzima_. Lakini mfumo wa almasi unawezesha mbinu ya ruhusa ya msimu, ambapo unaweza kuzuia huluki kuboresha fanksheni fulani ndani ya mkataba mahiri. [Zaidi kuhusu mfumo wa almasi (inafunguka katika kichupo kipya)](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w) . [](https://ethereum.org/sw/developers/docs/smart-contracts/upgrading/#pros-and-cons-of-upgrading-smart-contracts) Faida na hasara za kuboresha mikataba mahiri -------------------------------------------------------------------------------------------------------------------------------------------------------------- | Faida | Hasara | | --- | --- | | Uboreshaji wa mkataba mahiri unaweza kurahisisha kurekebisha udhaifu uliogunduliwa katika awamu ya baada ya usambazaji. | Kuboresha mikataba mahiri kunapingana na wazo la kutobadilika kwa msimbo, jambo ambalo lina athari kwa ugatuzi na usalama. | | Wasanidi programu wanaweza kutumia uboreshaji wa mantiki ili kuongeza vipengele vipya kwenye programu tumizi zilizogatuliwa. | Watumiaji lazima waamini wasanidi programu kutorekebisha mikataba mahiri kiholela. | | Uboreshaji wa mkataba mahiri unaweza kuboresha usalama kwa watumiaji wa mwisho kwa kuwa hitilafu zinaweza kurekebishwa haraka. | Kupanga utendakazi wa uboreshaji katika mikataba mahiri kunaongeza safu nyingine ya utata na kuongeza uwezekano wa dosari muhimu. | | Uboreshaji wa mkataba huwapa wasanidi programu nafasi zaidi ya kufanya majaribio na vipengele tofauti na kuboresha dapp kadiri muda unavyopita. | Fursa ya kuboresha mikataba mahiri inaweza kuwahimiza wasanidi programu kuzindua miradi haraka bila kufanya uchunguzi wa kina wakati wa awamu ya uundaji. | | | Udhibiti usio salama wa ufikiaji au uwekaji kati katika mikataba mahiri unaweza kurahisisha kwa watendaji wabaya kufanya uboreshaji usioidhinishwa. | [](https://ethereum.org/sw/developers/docs/smart-contracts/upgrading/#considerations-for-upgrading-smart-contracts) Mambo ya kuzingatia kwa kuboresha mikataba mahiri --------------------------------------------------------------------------------------------------------------------------------------------------------------------- 1. Tumia udhibiti salama wa ufikiaji/mbinu za uidhinishaji ili kuzuia uboreshaji usioidhinishwa wa mkataba mahiri, hasa ikiwa unatumia mifumo ya uwakilishi, mifumo ya mkakati, au utenganishaji wa data. Mfano ni kuzuia ufikiaji wa fanksheni ya uboreshaji, kiasi kwamba mmiliki wa mkataba pekee ndiye anayeweza kuiita. 2. Kuboresha mikataba mahiri ni shughuli ngumu na inahitaji kiwango cha juu cha uangalifu ili kuzuia kuanzishwa kwa udhaifu. 3. Punguza dhana za uaminifu kwa kugatua mchakato wa kutekeleza uboreshaji. Mikakati inayowezekana inajumuisha kutumia [mkataba wa mkoba wa saini nyingi](https://ethereum.org/sw/developers/docs/smart-contracts/#multisig) ili kudhibiti uboreshaji, au kuhitaji [wanachama wa DAO](https://ethereum.org/sw/dao/) kupiga kura kuidhinisha uboreshaji. 4. Fahamu gharama zinazohusika katika kuboresha mikataba. Kwa mfano, kunakili hali (k.m., salio la mtumiaji) kutoka kwa mkataba wa zamani hadi mkataba mpya wakati wa uhamishaji wa mkataba kunaweza kuhitaji zaidi ya muamala mmoja, ikimaanisha ada zaidi za gesi. 5. Fikiria kutekeleza **timelocks** ili kulinda watumiaji. Timelock inarejelea ucheleweshaji unaotekelezwa kwenye mabadiliko ya mfumo. Timelocks zinaweza kuunganishwa na mfumo wa utawala wa saini nyingi ili kudhibiti uboreshaji: ikiwa hatua iliyopendekezwa inafikia kiwango kinachohitajika cha idhini, haitekelezi hadi kipindi cha ucheleweshaji kilichobainishwa awali kipite. Timelocks huwapa watumiaji muda wa kujitoa kwenye mfumo ikiwa hawakubaliani na mabadiliko yaliyopendekezwa (k.m., uboreshaji wa mantiki au mipango mipya ya ada). Bila timelocks, watumiaji wanahitaji kuamini wasanidi programu kutotekeleza mabadiliko ya kiholela katika mkataba mahiri bila taarifa ya awali. Kikwazo hapa ni kwamba timelocks huzuia uwezo wa kurekebisha udhaifu haraka. [](https://ethereum.org/sw/developers/docs/smart-contracts/upgrading/#resources) Rasilimali ------------------------------------------------------------------------------------------- **Programu-jalizi za Uboreshaji za OpenZeppelin - _Kikundi cha zana za kusambaza na kulinda mikataba mahiri inayoweza kuboreshwa._** * [GitHub (inafunguka katika kichupo kipya)](https://github.com/OpenZeppelin/openzeppelin-upgrades) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.openzeppelin.com/upgrades) [](https://ethereum.org/sw/developers/docs/smart-contracts/upgrading/#tutorials) Mafunzo ---------------------------------------------------------------------------------------- * [Kuboresha Mikataba yako Mahiri | Mafunzo ya YouTube (inafunguka katika kichupo kipya)](https://www.youtube.com/watch?v=bdXJmWajZRY) na Patrick Collins * [Mafunzo ya Uhamishaji wa Mkataba Mahiri wa Ethereum (inafunguka katika kichupo kipya)](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) na Austin Griffith * [Kutumia mfumo wa uwakilishi wa UUPS kuboresha mikataba mahiri (inafunguka katika kichupo kipya)](https://blog.logrocket.com/author/praneshas/) na Pranesh A.S * [Mafunzo ya Web3: Andika mkataba mahiri unaoweza kuboreshwa (uwakilishi) kwa kutumia OpenZeppelin (inafunguka katika kichupo kipya)](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) na fangjun.eth [](https://ethereum.org/sw/developers/docs/smart-contracts/upgrading/#further-reading) Usomaji zaidi ---------------------------------------------------------------------------------------------------- * [Hali ya Uboreshaji wa Mkataba Mahiri (inafunguka katika kichupo kipya)](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) na Santiago Palladino * [Njia nyingi za kuboresha mkataba mahiri wa Solidity (inafunguka katika kichupo kipya)](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - Blogu ya Crypto Market Pool * [Jifunze: Kuboresha Mikataba Mahiri (inafunguka katika kichupo kipya)](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - Nyaraka za OpenZeppelin * [Mifumo ya Uwakilishi Kwa Uwezo wa Kuboreshwa wa Mikataba ya Solidity: Uwakilishi wa Uwazi dhidi ya UUPS (inafunguka katika kichupo kipya)](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) na Naveen Sahu * [Jinsi Uboreshaji wa Almasi Unavyofanya Kazi (inafunguka katika kichupo kipya)](https://dev.to/mudgen/how-diamond-upgrades-work-417j) na Nick Mudge --- # イーサリアムのアーカイブ・ノード | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/nodes-and-clients/archive-nodes/#main-content) Change page イーサリアムのアーカイブ・ノード ================ .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/nodes-and-clients/archive-nodes/index.md) このページの内容 アーカイブ・ノードは、すべての履歴状態のアーカイブを構築するように設定された[イーサリアム](https://ethereum.org/ja/) クライアントのインスタンスです。特定のユースケースにおいて有用なツールですが、フル・ノードよりも運用が難しい場合があります。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/archive-nodes/#prerequisites) 前提条件 ----------------------------------------------------------------------------------------------- [イーサリアムのノード](https://ethereum.org/ja/developers/docs/nodes-and-clients/) の概念、[そのアーキテクチャ](https://ethereum.org/ja/developers/docs/nodes-and-clients/node-architecture/) 、[同期戦略](https://ethereum.org/ja/developers/docs/nodes-and-clients/#sync-modes) 、およびノードの[運用](https://ethereum.org/ja/developers/docs/nodes-and-clients/run-a-node/) と[使用](https://ethereum.org/ja/developers/docs/apis/json-rpc/) に関する実践について理解しておく必要があります。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/archive-nodes/#what-is-an-archive-node) アーカイブ・ノードとは ---------------------------------------------------------------------------------------------------------------- アーカイブ・ノードの重要性を理解するために、「状態」の概念を明確にしましょう。イーサリアムは「トランザクションベースの状態遷移マシン」と呼ぶことができます。イーサリアムは、トランザクションを実行して自身の状態を変更するアカウントとアプリケーションで構成されています。各アカウントとコントラクトに関する情報を持つグローバルデータは、状態と呼ばれるトライデータベースに保存されます。これは実行レイヤー (EL) クライアントによって処理され、以下が含まれます。 * アカウントの残高とナンス * コントラクトのコードとストレージ * コンセンサス関連のデータ（例：ステーキング・デポジット・コントラクト） ネットワークとやり取りし、新しいブロックを検証および生成するために、イーサリアムクライアントは最新の変更（チェーンの先端）と現在の状態を常に把握しておく必要があります。フル・ノードとして設定された実行レイヤークライアントは、ネットワークの最新の状態を検証して追跡しますが、チェーンの再編成（reorg）を処理し、最近のデータへの高速なアクセスを提供するために、過去のいくつかの状態（例：過去128ブロックに関連する状態）のみをキャッシュします。最近の状態は、すべてのクライアントが受信したトランザクションを検証し、ネットワークを使用するために必要とするものです。 状態は特定のブロックにおけるネットワークの瞬間的なスナップショットであり、アーカイブは履歴のリプレイであると想像できます。 履歴状態はネットワークの運用に必要ではなく、クライアントがすべての古いデータを保持することは無駄に冗長であるため、安全にプルーニング（削除）できます。最近のブロック（例：先頭から128ブロック前）より前に存在した状態は、事実上破棄されます。フル・ノードは、履歴のブロックチェーンデータ（ブロックとトランザクション）と、要求に応じて古い状態を再生成するために使用できる時折の履歴スナップショットのみを保持します。これは、EVMで過去のトランザクションを再実行することによって行われますが、目的の状態が最も近いスナップショットから遠く離れている場合、計算負荷が高くなる可能性があります。 しかし、これはフル・ノードで履歴状態にアクセスすると大量の計算を消費することを意味します。クライアントは、すべての過去のトランザクションを実行し、ジェネシスから1つの履歴状態を計算する必要があるかもしれません。アーカイブ・ノードは、最新の状態だけでなく、各ブロックの後に作成されたすべての履歴状態を保存することでこれを解決します。基本的には、より大きなディスク容量を必要とするというトレードオフになります。 ネットワークは、すべての履歴データを保持および提供するためにアーカイブ・ノードに依存しているわけではないことに注意することが重要です。前述のように、すべての履歴の中間状態はフル・ノードで導出できます。トランザクションは任意のフル・ノードに保存されており（現在は400GB未満）、リプレイしてアーカイブ全体を構築することができます。 ### [](https://ethereum.org/ja/developers/docs/nodes-and-clients/archive-nodes/#use-cases) ユースケース トランザクションの送信、コントラクトのデプロイ、コンセンサスの検証など、イーサリアムの通常の利用では、履歴状態へのアクセスは必要ありません。ユーザーがネットワークとの標準的なやり取りを行うためにアーカイブ・ノードを必要とすることは決してありません。 状態アーカイブの主な利点は、履歴状態に関するクエリへの迅速なアクセスです。たとえば、アーカイブ・ノードは次のような結果を即座に返します。 * _ブロック15537393におけるアカウント 0x1337... のETH残高はいくらだったか？_ * _ブロック1920000におけるコントラクト 0x 内のトークン 0x の残高はいくらか？_ 上で説明したように、フル・ノードはCPUを使用し時間がかかるEVMの実行によってこのデータを生成する必要があります。アーカイブ・ノードはディスク上のデータにアクセスし、即座に応答を返します。これは、インフラストラクチャの特定の部分にとって有用な機能です。例えば： * ブロックエクスプローラーなどのサービスプロバイダー * 研究者 * セキュリティアナリスト * 分散型アプリケーション (dapp) の開発者 * 監査とコンプライアンス 履歴データへのアクセスを可能にする様々な無料の[サービス](https://ethereum.org/ja/developers/docs/nodes-and-clients/nodes-as-a-service/) もあります。アーカイブ・ノードの運用はより要求が厳しいため、このアクセスはほとんど制限されており、時折のアクセスにのみ機能します。プロジェクトで履歴データへの継続的なアクセスが必要な場合は、自分でアーカイブ・ノードを運用することを検討すべきです。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/archive-nodes/#implementations-and-usage) 実装と使用方法 -------------------------------------------------------------------------------------------------------------- この文脈におけるアーカイブ・ノードとは、状態データベースを処理し、JSON-RPCエンドポイントを提供する、ユーザー向け実行レイヤークライアントによって提供されるデータを意味します。設定オプション、同期時間、データベースのサイズはクライアントによって異なる場合があります。詳細については、使用するクライアントのドキュメントを参照してください。 独自のアーカイブ・ノードを起動する前に、クライアント間の違い、特に様々な[ハードウェア要件](https://ethereum.org/ja/developers/docs/nodes-and-clients/run-a-node/#requirements) について学んでください。ほとんどのクライアントはこの機能に最適化されておらず、そのアーカイブには12TB以上の容量が必要です。対照的に、エリゴンのような実装は同じデータを3TB未満で保存できるため、アーカイブ・ノードを運用する最も効果的な方法となります。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/archive-nodes/#recommended-practices) 推奨される実践 ---------------------------------------------------------------------------------------------------------- [ノードの運用に関する一般的な推奨事項](https://ethereum.org/ja/developers/docs/nodes-and-clients/run-a-node/) とは別に、アーカイブ・ノードはハードウェアとメンテナンスの面でより要求が厳しい場合があります。エリゴンの[主要な機能 （新しいタブで開きます）](https://github.com/ledgerwatch/erigon#key-features) を考慮すると、最も実用的なアプローチは[エリゴン](https://ethereum.org/ja/developers/docs/nodes-and-clients/#erigon) クライアントの実装を使用することです。 ### [](https://ethereum.org/ja/developers/docs/nodes-and-clients/archive-nodes/#hardware) ハードウェア 常にクライアントのドキュメントで、特定のモードのハードウェア要件を確認するようにしてください。 アーカイブ・ノードの最大の要件はディスク容量です。クライアントによって異なりますが、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) のような信頼できる品質のものであるべきです。ディスクは、デスクトップコンピュータや十分なスロットを持つサーバーに取り付けることができます。このような専用デバイスは、高い稼働率でノードを運用するのに理想的です。ノートパソコンで運用することも完全に可能ですが、携帯性には追加のコストがかかります。 すべてのデータは1つのボリュームに収まる必要があるため、例えば[RAID0 （新しいタブで開きます）](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) やLVMなどでディスクを結合する必要があります。また、低レベルのエラーなしにデータがディスクに正しく書き込まれることを保証する「コピーオンライト（Copy-on-write）」をサポートしているため、[ZFS （新しいタブで開きます）](https://en.wikipedia.org/wiki/ZFS) の使用を検討する価値もあるかもしれません。 偶発的なデータベースの破損を防ぐための安定性とセキュリティをさらに高めるために、特にプロフェッショナルなセットアップでは、システムがサポートしている場合は[ECCメモリ （新しいタブで開きます）](https://en.wikipedia.org/wiki/ECC_memory) の使用を検討してください。RAMのサイズは一般的にフル・ノードと同じであることが推奨されますが、RAMが多いほど同期を高速化するのに役立ちます。 初期同期中、アーカイブモードのクライアントはジェネシス以降のすべてのトランザクションを実行します。実行速度は主にCPUによって制限されるため、より高速なCPUは初期同期時間の短縮に役立ちます。平均的な消費者向けコンピュータでは、初期同期に最大1か月かかる場合があります。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/archive-nodes/#further-reading) 参考文献 ------------------------------------------------------------------------------------------------- * [Ethereum Full Node vs Archive Node （新しいタブで開きます）](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) - _QuickNode、2022年9月_ * [Building Your Own Ethereum Archive Node （新しいタブで開きます）](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) - _Thomas Jay Rush、2021年8月_ * [How to set up Erigon, Erigon’s RPC and TrueBlocks (scrape and API) as services （新しいタブで開きます）](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– Magnus Hansson、2022年9月更新_ [](https://ethereum.org/ja/developers/docs/nodes-and-clients/archive-nodes/#related-topics) 関連トピック -------------------------------------------------------------------------------------------------- * [ノードとクライアント](https://ethereum.org/ja/developers/docs/nodes-and-clients/) * [ノードの運用](https://ethereum.org/ja/developers/docs/nodes-and-clients/run-a-node/) --- # ライト・クライアント | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/nodes-and-clients/light-clients/#main-content) Change page ライト・クライアント ========== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/nodes-and-clients/light-clients/index.md) このページの内容 フル・ノードを実行することは、[イーサリアム](https://ethereum.org/ja/) とやり取りするための、最もトラストレスでプライベート、かつ分散型で検閲耐性のある方法です。フル・ノードを使用すると、即座にクエリを実行できるブロックチェーンの独自のコピーを保持し、イーサリアムのピア・ツー・ピア・ネットワークに直接アクセスできます。しかし、フル・ノードを実行するには、大量のメモリ、ストレージ、およびCPUが必要です。つまり、誰もが独自のノードを実行できるわけではありません。イーサリアムのロードマップには、ステートレス性など、これに対するいくつかの解決策がありますが、実装されるまでには数年かかります。短期的な答えは、フル・ノードを実行する利点の一部を妥協する代わりに、非常に低いハードウェア要件でノードを実行できるようにする大幅なパフォーマンス向上を得ることです。この妥協を行うノードは、ライト・ノードと呼ばれます。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/light-clients/#what-is-a-light-client) ライト・クライアントとは ---------------------------------------------------------------------------------------------------------------- ライト・ノードとは、ライト・クライアント・ソフトウェアを実行しているノードのことです。ブロックチェーン・データのローカルコピーを保持し、すべての変更を独立して検証する代わりに、必要なデータをプロバイダーに要求します。プロバイダーは、フル・ノードへの直接接続である場合もあれば、中央集権型のRPCサーバーを経由する場合もあります。その後、データはライト・ノードによって検証され、チェーンの先頭に追従できるようになります。ライト・ノードはブロック・ヘッダーのみを処理し、実際のブロックの内容をダウンロードするのは時々だけです。ノードの軽量さは、実行するライト・クライアントとフル・クライアント・ソフトウェアの組み合わせによって異なります。たとえば、最も軽量な構成は、ライト実行クライアントとライト・コンセンサス・クライアントを実行することです。また、多くのノードが、フル実行クライアントとライト・コンセンサス・クライアントを組み合わせて実行したり、その逆を選択したりする可能性もあります。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/light-clients/#how-do-light-clients-work) ライト・クライアントはどのように機能するのか？ ------------------------------------------------------------------------------------------------------------------------------ イーサリアムがプルーフ・オブ・ステーク (PoS) ベースのコンセンサス・メカニズムを使用し始めたとき、ライト・クライアントをサポートするために特化した新しいインフラストラクチャが導入されました。その仕組みは、1.1日ごとに512人のバリデータのサブセットをランダムに選択し、**シンク・コミッティ**として機能させるというものです。シンク・コミッティは、最近のブロックのヘッダーに署名します。各ブロック・ヘッダーには、シンク・コミッティ内のバリデータの集約署名と、どのバリデータが署名し、どのバリデータが署名しなかったかを示す「ビットフィールド」が含まれています。各ヘッダーには、次のブロックの署名に参加することが期待されるバリデータのリストも含まれています。これにより、ライト・クライアントは、受信したデータにシンク・コミッティが署名したことをすばやく確認できます。また、受信したシンク・コミッティと、前のブロックで期待されていたシンク・コミッティを比較することで、それが本物であるかどうかも確認できます。このようにして、ライト・クライアントは、ブロック自体を実際にダウンロードすることなく、要約情報を含むヘッダーのみを使用して、最新のイーサリアム・ブロックに関する知識を更新し続けることができます。 実行レイヤーには、ライト実行クライアントの単一の仕様はありません。ライト実行クライアントの範囲は、フル・ノードのすべてのEVMおよびネットワーク機能を備えつつ、関連データをダウンロードせずにブロック・ヘッダーのみを検証するフル実行クライアントの「ライト・モード」から、イーサリアムとやり取りするためにRPCプロバイダーへのリクエスト転送に大きく依存する、より機能が削ぎ落とされたクライアントまでさまざまです。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/light-clients/#why-are-light-clients-important) なぜライト・クライアントが重要なのか？ -------------------------------------------------------------------------------------------------------------------------------- ライト・クライアントが重要なのは、フル・ノードのほんのわずかな計算リソースを使用するだけで、データ・プロバイダーが正確で誠実であると盲目的に信頼するのではなく、ユーザーが受信データを検証できるからです。ライト・クライアントが受信したデータは、512人のランダムなイーサリアム・バリデータのセットのうち少なくとも3分の2によって署名されたことがわかっているブロック・ヘッダーと照合できます。これは、データが正しいことを示す非常に強力な証拠です。 ライト・クライアントは、ごくわずかな計算能力、メモリ、ストレージしか使用しないため、携帯電話で実行したり、アプリに組み込んだり、ブラウザの一部として実行したりできます。ライト・クライアントは、イーサリアムへのトラスト最小化されたアクセスを、サードパーティのプロバイダーを信頼するのと同じくらいスムーズにする方法です。 簡単な例を挙げてみましょう。アカウントの残高を確認したいとします。これを行うには、イーサリアム・ノードにリクエストを送信する必要があります。そのノードは、イーサリアムの状態のローカルコピーであなたの残高を確認し、それを返します。ノードに直接アクセスできない場合は、このデータをサービスとして提供する中央集権型のオペレーターが存在します。彼らにリクエストを送信すると、彼らは自身のノードを確認し、結果を返してくれます。これの問題点は、プロバイダーが正しい情報を提供していると信頼しなければならないことです。自分で検証できなければ、その情報が本当に正しいかどうかを知ることはできません。 ライト・クライアントは、この問題に対処します。依然として外部プロバイダーにデータを要求しますが、データを受信すると、ライト・ノードがブロック・ヘッダーで受信した情報と照合できる証明が付属しています。つまり、信頼できるオペレーターの代わりに、イーサリアムがデータの正確性を検証していることになります。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/light-clients/#what-innovations-do-light-clients-enable) ライト・クライアントはどのようなイノベーションを可能にするのか？ ------------------------------------------------------------------------------------------------------------------------------------------------------ ライト・クライアントの主な利点は、無視できるほどのハードウェア要件とサードパーティへの最小限の依存で、より多くの人々が独立してイーサリアムにアクセスできるようにすることです。これは、ユーザーが自身のデータを検証できるためユーザーにとって有益であり、チェーンを検証するノードの数と多様性が増加するためネットワークにとっても有益です。 非常に少ないストレージ、メモリ、処理能力のデバイスでイーサリアム・ノードを実行できる機能は、ライト・クライアントによって解き放たれたイノベーションの主要な分野の1つです。現在のイーサリアム・ノードは多くの計算リソースを必要としますが、ライト・クライアントはブラウザに組み込んだり、携帯電話で実行したり、おそらくスマートウォッチなどのさらに小さなデバイスでも実行できるようになります。つまり、クライアントが組み込まれたイーサリアム・ウォレットを携帯電話で実行できるようになります。これにより、モバイル・ウォレットはデータについて中央集権型のデータ・プロバイダーを信頼する必要がなくなるため、はるかに分散型になる可能性があります。 これの延長線上にあるのが、**モノのインターネット (IoT)** デバイスの有効化です。ライト・クライアントを使用すると、シンク・コミッティによって提供されるすべてのセキュリティ保証を伴って、トークン残高やNFTの所有権をすばやく証明し、IoTネットワーク上で何らかのアクションをトリガーできます。組み込みのライト・クライアントを備えたアプリを使用して、レンタルサービスのNFTを所有していることをすばやく検証し、所有している場合は自転車のロックを解除して乗れるようにする[自転車レンタルサービス （新しいタブで開きます）](https://youtu.be/ZHNrAXf3RDE?t=929) を想像してみてください！ イーサリアムのロールアップも、ライト・クライアントの恩恵を受けるでしょう。ロールアップの大きな問題の1つは、イーサリアム・メインネットからロールアップへの資金の送金を可能にするブリッジを標的としたハッキングでした。脆弱性の1つは、ユーザーがブリッジに預け入れを行ったことを検出するためにロールアップが使用するオラクルです。オラクルが不正なデータを提供した場合、ブリッジへの預け入れがあったとロールアップを騙し、誤って資金を解放させる可能性があります。ロールアップに組み込まれたライト・クライアントは、トークンを解放する前にロールアップによって検証できる証明をブリッジへの預け入れに付随させることができるため、破損したオラクルから保護するために使用できます。同じ概念は、他のインターチェーン・ブリッジにも適用できます。 ライト・クライアントは、イーサリアム・ウォレットのアップグレードにも使用できます。RPCプロバイダーから提供されたデータを信頼する代わりに、ウォレットは組み込みのライト・クライアントを使用して、提示されたデータを直接検証できます。これにより、ウォレットのセキュリティが向上します。RPCプロバイダーが不誠実で不正確なデータを提供した場合、組み込みのライト・クライアントがそれを教えてくれます！ [](https://ethereum.org/ja/developers/docs/nodes-and-clients/light-clients/#current-state-of-development) ライト・クライアント開発の現状は？ --------------------------------------------------------------------------------------------------------------------------- 実行、コンセンサス、および実行/コンセンサスを組み合わせたライト・クライアントなど、いくつかのライト・クライアントが開発中です。このページを執筆している時点で私たちが把握しているライト・クライアントの実装は以下の通りです。 * [ロードスター （新しいタブで開きます）](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) : Goで書かれた実行クライアントのライト・モード（開発中） * [ニンバス （新しいタブで開きます）](https://nimbus.guide/el-light-client.html) : Nimで書かれたコンセンサス・ライト・クライアント 私たちの知る限り、これらの中でまだ本番環境の準備が整っていると見なされているものはありません。 ライト・クライアントがイーサリアムのデータにアクセスする方法を改善するための多くの作業も行われています。現在、ライト・クライアントはクライアント/サーバー・モデルを使用してフル・ノードへのRPCリクエストに依存していますが、将来的には、ピア・ツー・ピアのゴシップ・プロトコルを使用してライト・クライアントにデータを提供できる[ポータル・ネットワーク （新しいタブで開きます）](https://www.ethportal.net/) などの専用ネットワークを使用して、より分散化された方法でデータを要求できるようになる可能性があります。 [ヴァークル・ツリー](https://ethereum.org/ja/roadmap/verkle-trees/) や[ステートレス性](https://ethereum.org/ja/roadmap/statelessness/) などの他の[ロードマップ](https://ethereum.org/ja/roadmap/) の項目は、最終的にライト・クライアントのセキュリティ保証をフル・クライアントと同等にするでしょう。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/light-clients/#further-reading) 参考文献 ------------------------------------------------------------------------------------------------- * [Zsolt FelfodhiによるGethライト・クライアントに関する記事 （新しいタブで開きます）](https://www.youtube.com/watch?v=EPZeFXau-RE) * [Etan Kisslingによるライト・クライアントのネットワーキングに関する記事 （新しいタブで開きます）](https://www.youtube.com/watch?v=85MeiMA4dD8) * [Etan Kisslingによるマージ後のライト・クライアントに関する記事 （新しいタブで開きます）](https://www.youtube.com/watch?v=ZHNrAXf3RDE) * [Piper Merriam: 機能的なライト・クライアントへの曲がりくねった道 （新しいタブで開きます）](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/) --- # 스마트 컨트랙트 조합성 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#main-content) Change page 스마트 컨트랙트 조합성 ============ .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/composability/index.md) 이 페이지의 내용 [](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#a-brief-introduction) 간단한 소개 ------------------------------------------------------------------------------------------------------ 스마트 컨트랙트는 이더리움에 공개되어 있으며 오픈 API로 생각할 수 있습니다. 탈중앙화 애플리케이션 (dapp) 개발자가 되기 위해 자체 스마트 컨트랙트를 작성할 필요는 없으며, 상호작용하는 방법만 알면 됩니다. 예를 들어, 탈중앙화 거래소인 [유니스왑 (새 탭에서 열림)](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) 컨트랙트 중 일부를 확인해 보세요. [](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#what-is-composability) 조합성이란 무엇인가요? ------------------------------------------------------------------------------------------------------------- 조합성은 서로 다른 컴포넌트를 결합하여 새로운 시스템이나 결과물을 만드는 것입니다. 소프트웨어 개발에서 조합성이란 개발자가 기존 소프트웨어 컴포넌트를 재사용하여 새로운 애플리케이션을 구축할 수 있음을 의미합니다. 조합성을 이해하는 좋은 방법은 조합 가능한 요소를 레고 블록으로 생각하는 것입니다. 각 레고는 다른 레고와 결합할 수 있으므로, 다양한 레고를 결합하여 복잡한 구조를 만들 수 있습니다. 이더리움에서 모든 스마트 컨트랙트는 일종의 레고와 같습니다. 다른 프로젝트의 스마트 컨트랙트를 프로젝트의 구성 요소로 사용할 수 있습니다. 즉, 이미 있는 것을 다시 만들거나 처음부터 구축하는 데 시간을 낭비할 필요가 없습니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#how-does-composability-work) 조합성은 어떻게 작동하나요? ---------------------------------------------------------------------------------------------------------------------- 이더리움 스마트 컨트랙트는 퍼블릭 API와 같으므로 누구나 컨트랙트와 상호작용하거나 추가 기능을 위해 dapp에 통합할 수 있습니다. 스마트 컨트랙트 조합성은 일반적으로 모듈성(modularity), 자율성(autonomy), 발견 가능성(discoverability)이라는 세 가지 원칙에 따라 작동합니다. **1\. 모듈성**: 개별 컴포넌트가 특정 작업을 수행할 수 있는 능력입니다. 이더리움의 모든 스마트 컨트랙트에는 특정 사용 사례가 있습니다(유니스왑 예시 참조). **2\. 자율성**: 조합 가능한 컴포넌트는 독립적으로 작동할 수 있어야 합니다. 이더리움의 각 스마트 컨트랙트는 자체 실행되며 시스템의 다른 부분에 의존하지 않고 기능할 수 있습니다. **3\. 발견 가능성**: 외부 컨트랙트나 소프트웨어 라이브러리가 공개적으로 사용 가능하지 않다면 개발자는 이를 호출하거나 애플리케이션에 통합할 수 없습니다. 설계상 스마트 컨트랙트는 오픈 소스이므로 누구나 스마트 컨트랙트를 호출하거나 코드베이스를 포크할 수 있습니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#benefits-of-composability) 조합성의 이점 ------------------------------------------------------------------------------------------------------------ ### [](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#shorter-development-cycle) 개발 주기 단축 조합성은 개발자가 [dapp](https://ethereum.org/ko/apps/#what-are-dapps) 을 만들 때 해야 할 작업을 줄여줍니다. [나발 라비칸트(Naval Ravikant)가 말했듯이 (새 탭에서 열림)](https://twitter.com/naval/status/1444366754650656770) , "오픈 소스란 모든 문제를 한 번만 해결하면 된다는 것을 의미합니다." 한 문제를 해결하는 스마트 컨트랙트가 있다면 다른 개발자가 이를 재사용할 수 있으므로 같은 문제를 다시 해결할 필요가 없습니다. 이런 방식으로 개발자는 기존 소프트웨어 라이브러리를 가져와 추가 기능을 더해 새로운 dapp을 만들 수 있습니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#greater-innovation) 더 큰 혁신 조합성은 개발자가 원하는 결과를 만들기 위해 오픈 소스 코드를 자유롭게 재사용, 수정, 복제 또는 통합할 수 있기 때문에 혁신과 실험을 장려합니다. 결과적으로 개발 팀은 기본 기능에 소요되는 시간을 줄이고 새로운 기능을 실험하는 데 더 많은 시간을 할애할 수 있습니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#better-user-experience) 더 나은 사용자 경험 이더리움 생태계 컴포넌트 간의 상호운용성은 사용자 경험을 향상시킵니다. 애플리케이션이 서로 통신할 수 없는 파편화된 생태계보다 dapp이 외부 스마트 컨트랙트를 통합할 때 사용자는 더 많은 기능에 접근할 수 있습니다. 차익 거래의 예를 들어 상호운용성의 이점을 설명해 보겠습니다. 토큰이 `exchange B`보다 `exchange A`에서 더 높은 가격에 거래되고 있다면, 가격 차이를 이용해 수익을 낼 수 있습니다. 하지만 이는 트랜잭션에 자금을 조달할 충분한 자본이 있는 경우(즉, `exchange B`에서 토큰을 구매하고 `exchange A`에서 판매하는 경우)에만 가능합니다. 거래를 감당할 충분한 자금이 없는 상황에서는 플래시 론이 이상적일 수 있습니다. [플래시 론](https://ethereum.org/ko/defi/#flash-loans) 은 고도의 기술이 필요하지만, 기본 개념은 (담보 없이) 자산을 빌리고 _단일_ 트랜잭션 내에서 동일한 자산을 반환할 수 있다는 것입니다. 처음 예시로 돌아가서, 차익 거래자는 대규모 플래시 론을 받아 `exchange B`에서 토큰을 구매하고 `exchange A`에서 판매한 다음, 원금과 이자를 갚고 수익을 챙기는 모든 과정을 동일한 트랜잭션 내에서 수행할 수 있습니다. 이 복잡한 로직은 여러 컨트랙트에 대한 호출을 결합해야 하며, 스마트 컨트랙트에 상호운용성이 없다면 불가능할 것입니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#composability-in-ethereum) 이더리움의 조합성 예시 ----------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#token-swaps) 토큰 스왑 트랜잭션 비용을 ETH로 지불해야 하는 dapp을 만드는 경우, 토큰 스왑 로직을 통합하여 사용자가 다른 ERC-20 토큰으로 지불하도록 허용할 수 있습니다. 코드는 컨트랙트가 호출된 함수를 실행하기 전에 사용자의 토큰을 자동으로 ETH로 변환합니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#governance) 거버넌스 [DAO](https://ethereum.org/ko/dao/) 를 위한 맞춤형 거버넌스 시스템을 구축하는 것은 비용과 시간이 많이 들 수 있습니다. 대신 [Aragon Client (새 탭에서 열림)](https://client.aragon.org/) 와 같은 오픈 소스 거버넌스 툴킷을 사용하여 DAO를 부트스트랩하고 거버넌스 프레임워크를 빠르게 만들 수 있습니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#identity-management) 신원 관리 맞춤형 인증 시스템을 구축하거나 중앙화된 제공업체에 의존하는 대신, 탈중앙화 신원증명 (DID) 도구를 통합하여 사용자의 인증을 관리할 수 있습니다. 사용자가 이더리움 지갑으로 신원을 인증할 수 있는 "이더리움으로 로그인(Sign in with Ethereum)" 기능을 제공하는 오픈 소스 툴킷인 [SpruceID (새 탭에서 열림)](https://www.spruceid.com/) 가 그 예입니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#related-tutorials) 관련 튜토리얼 ---------------------------------------------------------------------------------------------------- * [create-eth-app으로 dapp 프론트엔드 개발 시작하기](https://ethereum.org/ko/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _– create-eth-app을 사용하여 별도 설정 없이 인기 있는 스마트 컨트랙트가 포함된 앱을 만드는 방법에 대한 개요입니다._ [](https://ethereum.org/ko/developers/docs/smart-contracts/composability/#further-reading) 더 읽을거리 ------------------------------------------------------------------------------------------------- _도움이 된 커뮤니티 리소스를 알고 계신가요? 이 페이지를 편집하여 추가해 주세요!_ * [조합성은 혁신이다(Composability is Innovation) (새 탭에서 열림)](https://a16zcrypto.com/posts/article/how-composability-unlocks-crypto-and-everything-else/) * [Web3에서 조합성이 중요한 이유(Why Composability Matters For Web3) (새 탭에서 열림)](https://hackernoon.com/why-composability-matters-for-web3) * [조합성이란 무엇인가?(What is Composability?) (새 탭에서 열림)](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.) --- # 포털 네트워크 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/networking-layer/portal-network/#main-content) Change page 포털 네트워크 ======= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/networking-layer/portal-network/index.md) 이 페이지의 내용 [이더리움](https://ethereum.org/ko/) 은 이더리움 클라이언트 소프트웨어를 실행하는 컴퓨터들로 구성된 네트워크입니다. 이러한 각각의 컴퓨터를 '노드'라고 부릅니다. 클라이언트 소프트웨어를 통해 노드는 이더리움 네트워크에서 데이터를 주고받을 수 있으며, 이더리움 프로토콜 규칙에 따라 데이터를 검증합니다. 노드는 디스크 저장소에 많은 과거 데이터를 보관하며, 네트워크의 다른 노드로부터 블록이라고 알려진 새로운 정보 패킷을 수신할 때마다 이를 추가합니다. 이는 노드가 네트워크의 나머지 부분과 일치하는 정보를 가지고 있는지 항상 확인하기 위해 필요합니다. 이는 노드를 실행하는 데 많은 디스크 공간이 필요할 수 있음을 의미합니다. 일부 노드 작업은 많은 RAM을 요구하기도 합니다. 이러한 디스크 저장소 문제를 해결하기 위해, 모든 정보를 직접 저장하는 대신 풀 노드에 정보를 요청하는 '라이트' 노드가 개발되었습니다. 하지만 이는 라이트 노드가 정보를 독립적으로 검증하지 않고 다른 노드를 신뢰한다는 것을 의미합니다. 또한 풀 노드가 이러한 라이트 노드에 데이터를 제공하기 위해 추가적인 작업을 수행해야 함을 의미하기도 합니다. 포털 네트워크는 네트워크 전체에 필요한 데이터를 작은 조각으로 공유함으로써, 풀 노드를 신뢰하거나 추가적인 부담을 주지 않고 "라이트" 노드의 데이터 가용성 문제를 해결하는 것을 목표로 하는 이더리움의 새로운 네트워킹 설계입니다. [노드와 클라이언트](https://ethereum.org/ko/developers/docs/nodes-and-clients/) 에 대해 더 알아보기 [](https://ethereum.org/ko/developers/docs/networking-layer/portal-network/#why-do-we-need-portal-network) 포털 네트워크가 필요한 이유 -------------------------------------------------------------------------------------------------------------------------- 이더리움 노드는 이더리움 블록체인의 전체 또는 부분 사본을 자체적으로 저장합니다. 이 로컬 사본은 트랜잭션을 검증하고 노드가 올바른 체인을 따르고 있는지 확인하는 데 사용됩니다. 이렇게 로컬에 저장된 데이터를 통해 노드는 다른 주체를 신뢰할 필요 없이 수신되는 데이터가 유효하고 올바른지 독립적으로 검증할 수 있습니다. 이러한 블록체인의 로컬 사본과 관련 상태 및 영수증 데이터는 노드의 하드 디스크에서 많은 공간을 차지합니다. 예를 들어, 합의 클라이언트와 쌍을 이루는 [Geth (새 탭에서 열림)](https://geth.ethereum.org/) 를 사용하여 노드를 실행하려면 2TB 하드 디스크가 권장됩니다. 비교적 최근 블록 세트의 체인 데이터만 저장하는 스냅 동기화를 사용할 경우, Geth는 일반적으로 약 650GB의 디스크 공간을 차지하지만 매주 약 14GB씩 증가합니다(주기적으로 노드를 프루닝하여 다시 650GB로 줄일 수 있습니다). 이는 이더리움을 위해 많은 디스크 공간을 할당해야 하므로 노드 실행 비용이 많이 들 수 있음을 의미합니다. 이더리움 로드맵에는 이 문제에 대한 몇 가지 해결책이 있으며, 여기에는 [기록 만료](https://ethereum.org/ko/roadmap/statelessness/#history-expiry) , [상태 만료](https://ethereum.org/ko/roadmap/statelessness/#state-expiry) 및 [무상태성](https://ethereum.org/ko/roadmap/statelessness/) 이 포함됩니다. 하지만 이들이 구현되기까지는 수년이 걸릴 가능성이 높습니다. 또한 체인 데이터의 자체 사본을 저장하지 않고 필요한 데이터를 풀 노드에 요청하는 [라이트 노드](https://ethereum.org/ko/developers/docs/nodes-and-clients/light-clients/) 도 있습니다. 그러나 이는 라이트 노드가 정직한 데이터를 제공할 것이라고 풀 노드를 신뢰해야 함을 의미하며, 라이트 노드가 필요로 하는 데이터를 제공해야 하는 풀 노드에게도 부담을 줍니다. 포털 네트워크는 풀 노드를 신뢰하거나 풀 노드가 해야 할 작업을 크게 늘리지 않고도 라이트 노드가 데이터를 얻을 수 있는 대안적인 방법을 제공하는 것을 목표로 합니다. 이를 달성하는 방법은 이더리움 노드가 네트워크 전체에서 데이터를 공유하는 새로운 방식을 도입하는 것입니다. [](https://ethereum.org/ko/developers/docs/networking-layer/portal-network/#how-does-portal-network-work) 포털 네트워크는 어떻게 작동하나요? ----------------------------------------------------------------------------------------------------------------------------- 이더리움 노드에는 서로 통신하는 방법을 정의하는 엄격한 프로토콜이 있습니다. 실행 클라이언트는 [devp2p](https://ethereum.org/ko/developers/docs/networking-layer/#devp2p) 로 알려진 하위 프로토콜 세트를 사용하여 통신하는 반면, 합의 클라이언트는 [libp2p](https://ethereum.org/ko/developers/docs/networking-layer/#libp2p) 라는 다른 하위 프로토콜 스택을 사용합니다. 이들은 노드 간에 전달될 수 있는 데이터의 유형을 정의합니다. [![devP2P and libP2P](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fnetworking-layer%2Fportal-network%2Fportal-network-devp2p-libp2p.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/networking-layer/portal-network/portal-network-devp2p-libp2p.png) 노드는 또한 [JSON-RPC API](https://ethereum.org/ko/developers/docs/apis/json-rpc/) 를 통해 특정 데이터를 제공할 수 있으며, 이는 앱과 지갑이 이더리움 노드와 정보를 스왑하는 방식입니다. 하지만 이들 중 어느 것도 경량 클라이언트에 데이터를 제공하기에 이상적인 프로토콜은 아닙니다. 경량 클라이언트는 현재 devp2p나 libp2p를 통해 특정 체인 데이터를 요청할 수 없습니다. 해당 프로토콜들은 체인 동기화와 블록 및 트랜잭션의 가십(gossip) 전파만을 가능하게 하도록 설계되었기 때문입니다. 경량 클라이언트는 이러한 정보를 다운로드하는 것을 원하지 않는데, 그렇게 하면 더 이상 "경량"이 아니게 되기 때문입니다. JSON-RPC API 역시 경량 클라이언트의 데이터 요청에 이상적인 선택은 아닙니다. 데이터를 제공할 수 있는 특정 풀 노드나 중앙화된 RPC 제공자에 대한 연결에 의존하기 때문입니다. 이는 경량 클라이언트가 해당 특정 노드/제공자가 정직하다고 신뢰해야 함을 의미하며, 또한 풀 노드가 많은 경량 클라이언트로부터의 수많은 요청을 처리해야 하므로 대역폭 요구 사항이 증가할 수 있습니다. 포털 네트워크의 핵심은 기존 이더리움 클라이언트의 설계 제약에서 벗어나, 경량성을 위해 특별히 전체 설계를 재고하는 것입니다. 포털 네트워크의 핵심 아이디어는 현재 네트워킹 스택의 장점을 취하는 것입니다. 즉, 과거 데이터나 현재 체인 헤드의 식별자와 같이 경량 클라이언트에 필요한 정보를 [DHT (새 탭에서 열림)](https://en.wikipedia.org/wiki/Distributed_hash_table) (비트토렌트와 유사)를 사용하는 경량화된 devp2p 스타일의 피어 투 피어 탈중앙화된 네트워크를 통해 제공할 수 있게 합니다. 이 아이디어는 전체 이더리움 과거 데이터의 작은 부분과 일부 특정 노드 책임을 각 노드에 추가하는 것입니다. 그런 다음, 요청된 특정 데이터를 저장하고 있는 노드를 찾아 그들로부터 데이터를 검색하여 요청을 처리합니다. 이는 라이트 노드가 단일 노드를 찾아 대량의 데이터를 필터링하고 제공하도록 요청하는 일반적인 모델을 뒤집습니다. 대신, 각각 적은 양의 데이터를 처리하는 대규모 노드 네트워크를 빠르게 필터링합니다. 목표는 경량 포털 클라이언트로 구성된 탈중앙화된 네트워크가 다음을 수행할 수 있도록 하는 것입니다. * 체인의 헤드 추적 * 최근 및 과거 체인 데이터 동기화 * 상태 데이터 검색 * 트랜잭션 브로드캐스트 * [EVM](https://ethereum.org/ko/developers/docs/evm/) 을 사용한 트랜잭션 실행 이러한 네트워크 설계의 이점은 다음과 같습니다. * 중앙화된 제공자에 대한 의존도 감소 * 인터넷 대역폭 사용량 감소 * 동기화 최소화 또는 불필요 * 리소스가 제한된 기기(<1GB RAM, <100MB 디스크 공간, 1 CPU)에서도 접근 가능 아래 표는 포털 네트워크를 통해 제공될 수 있는 기존 클라이언트의 기능을 보여주며, 사용자가 매우 낮은 사양의 기기에서도 이러한 기능에 접근할 수 있게 해줍니다. ### [](https://ethereum.org/ko/developers/docs/networking-layer/portal-network/#the-portal-networks) 포털 네트워크 | 비콘 경량 클라이언트 | 상태 네트워크 | 트랜잭션 가십 | 기록 네트워크 | 표준 트랜잭션 인덱스 | | --- | --- | --- | --- | --- | | 비콘 체인 라이트 | 계정 및 컨트랙트 저장소 | 경량 멤풀 | 헤더 | TxHash > 해시, 인덱스 | | 프로토콜 데이터 | | | 블록 바디 | | | | | | 영수증 | | [](https://ethereum.org/ko/developers/docs/networking-layer/portal-network/#client-diversity-as-default) 기본적으로 제공되는 클라이언트 다양성 ----------------------------------------------------------------------------------------------------------------------------- 포털 네트워크 개발자들은 또한 첫날부터 4개의 독립적인 포털 네트워크 클라이언트를 구축하는 설계상의 선택을 했습니다. 포털 네트워크 클라이언트는 다음과 같습니다. * [Trin (새 탭에서 열림)](https://github.com/ethereum/trin) : Rust로 작성됨 * [Fluffy (새 탭에서 열림)](https://fluffy.guide/) : Nim으로 작성됨 * [Ultralight (새 탭에서 열림)](https://github.com/ethereumjs/ultralight) : TypeScript로 작성됨 * [Shisui (새 탭에서 열림)](https://github.com/zen-eth/shisui) : Go로 작성됨 여러 개의 독립적인 클라이언트 구현체를 보유하는 것은 이더리움 네트워크의 회복탄력성과 탈중앙화를 향상시킵니다. 한 클라이언트에 문제나 취약점이 발생하더라도 다른 클라이언트가 계속해서 원활하게 작동할 수 있어 단일 장애점(single point of failure)을 방지합니다. 또한, 다양한 클라이언트 구현체는 혁신과 경쟁을 촉진하여 생태계 내에서 개선을 주도하고 단일 문화(monoculture)의 위험을 줄입니다. [](https://ethereum.org/ko/developers/docs/networking-layer/portal-network/#further-reading) 더 읽어보기 --------------------------------------------------------------------------------------------------- * [포털 네트워크 (데브콘 보고타의 Piper Merriam) (새 탭에서 열림)](https://www.youtube.com/watch?v=0stc9jnQLXA) . * [포털 네트워크 디스코드 (새 탭에서 열림)](https://discord.gg/CFFnmE7Hbs) * [포털 네트워크 웹사이트 (새 탭에서 열림)](https://www.ethportal.net/) --- # イーサリアム開発標準 | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/standards/#main-content) Change page イーサリアム開発標準 ========== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/index.md) このページの内容 [](https://ethereum.org/ja/developers/docs/standards/#standards-overview) 標準の概要 ------------------------------------------------------------------------------- イーサリアムコミュニティは、プロジェクト（[イーサリアムクライアント](https://ethereum.org/ja/developers/docs/nodes-and-clients/) やウォレットなど）が実装間で相互運用可能であることを維持し、スマートコントラクトや分散型アプリケーション (dapp) がコンポーザブルであり続けることを保証する多くの標準を採用しています。 通常、標準は[イーサリアム改善提案](https://ethereum.org/ja/eips/) (EIP) として導入され、コミュニティメンバーによって[標準プロセス （新しいタブで開きます）](https://eips.ethereum.org/EIPS/eip-1) を通じて議論されます。 * [EIPの紹介](https://ethereum.org/ja/eips/) * [EIPのリスト （新しいタブで開きます）](https://eips.ethereum.org/) * [EIPのGitHubリポジトリ （新しいタブで開きます）](https://github.com/ethereum/EIPs) * [EIPディスカッションボード （新しいタブで開きます）](https://ethereum-magicians.org/c/eips) * [イーサリアムガバナンスの紹介](https://ethereum.org/ja/governance/) * [イーサリアムガバナンスの概要 （新しいタブで開きます）](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _2019年3月31日 - Boris Mann_ * [イーサリアムプロトコル開発のガバナンスとネットワークアップグレードの調整 （新しいタブで開きます）](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _2020年3月23日 - Hudson Jameson_ * [すべてのイーサリアムコア開発者会議のプレイリスト （新しいタブで開きます）](https://www.youtube.com/@EthereumProtocol) _(ユーチューブプレイリスト)_ [](https://ethereum.org/ja/developers/docs/standards/#types-of-standards) 標準の種類 ------------------------------------------------------------------------------- EIPには3つの種類があります。 * Standards Track: ほとんど、またはすべてのイーサリアム実装に影響を与える変更について説明します。 * [Meta Track （新しいタブで開きます）](https://eips.ethereum.org/meta) : イーサリアムを取り巻くプロセスについて説明するか、プロセスへの変更を提案します。 * [Informational Track （新しいタブで開きます）](https://eips.ethereum.org/informational) : イーサリアムの設計上の問題について説明するか、イーサリアムコミュニティに一般的なガイドラインや情報を提供します。 さらに、Standard Trackは4つのカテゴリに細分化されます。 * [Core （新しいタブで開きます）](https://eips.ethereum.org/core) : コンセンサスフォークを必要とする改善。 * [Networking （新しいタブで開きます）](https://eips.ethereum.org/networking) : devp2pやLight Ethereum Subprotocolに関する改善、およびwhisperやスウォームのネットワークプロトコル仕様に対する改善提案。 * [Interface （新しいタブで開きます）](https://eips.ethereum.org/interface) : クライアントのAPI/RPC仕様や標準、およびメソッド名やコントラクトABIなどの特定の言語レベルの標準に関する改善。 * [ERC （新しいタブで開きます）](https://eips.ethereum.org/erc) : アプリケーションレベルの標準と慣習。 これらの異なる種類やカテゴリに関する詳細情報は、[EIP-1 （新しいタブで開きます）](https://eips.ethereum.org/EIPS/eip-1#eip-types) に記載されています。 ### [](https://ethereum.org/ja/developers/docs/standards/#token-standards) トークン標準 * [ERC-20](https://ethereum.org/ja/developers/docs/standards/tokens/erc-20/) - 投票トークン、ステーキングトークン、仮想通貨などの代替可能（交換可能）なトークンのための標準インターフェース。 * [ERC-223](https://ethereum.org/ja/developers/docs/standards/tokens/erc-223/) - トークンをイーサと同じように動作させ、受信者側でのトークン転送の処理をサポートする代替可能トークン標準。 * [ERC-1363](https://ethereum.org/ja/developers/docs/standards/tokens/erc-1363/) - 単一のトランザクションで受信者コントラクトでのコールバック実行をサポートする、ERC-20トークンの拡張インターフェース。 * [ERC-721](https://ethereum.org/ja/developers/docs/standards/tokens/erc-721/) - アートワークや楽曲の権利書のような、非代替性トークンのための標準インターフェース。 * [ERC-2309 （新しいタブで開きます）](https://eips.ethereum.org/EIPS/eip-2309) - 連続したトークン識別子を使用して1つまたは複数の非代替性トークンを作成/転送する際に発行される標準化されたイベント。 * [ERC-4400 （新しいタブで開きます）](https://eips.ethereum.org/EIPS/eip-4400) - EIP-721のコンシューマーロールのためのインターフェース拡張。 * [ERC-4907 （新しいタブで開きます）](https://eips.ethereum.org/EIPS/eip-4907) - ERC-721トークンに制限された権限を持つ期間限定のロールを追加します。 * [ERC-777](https://ethereum.org/ja/developers/docs/standards/tokens/erc-777/) - **(非推奨)** ERC-20を改良したトークン標準。 * [ERC-1155](https://ethereum.org/ja/developers/docs/standards/tokens/erc-1155/) - 代替可能資産と非代替性資産の両方を含めることができるトークン標準。 * [ERC-4626](https://ethereum.org/ja/developers/docs/standards/tokens/erc-4626/) - 利回り付きヴォールトの技術的パラメータを最適化および統一するために設計された、トークン化されたヴォールト標準。 [トークン標準](https://ethereum.org/ja/developers/docs/standards/tokens/) についてさらに学ぶ。 [](https://ethereum.org/ja/developers/docs/standards/#further-reading) 参考文献 --------------------------------------------------------------------------- * [イーサリアム改善提案 (EIP)](https://ethereum.org/ja/eips/) _役に立ったコミュニティリソースをご存知ですか？このページを編集して追加してください！_ --- # Go 개발자를 위한 이더리움 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/programming-languages/golang/#main-content) Change page Go 개발자를 위한 이더리움 =============== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/golang/index.md) 이 페이지의 내용 Go 기반 프로젝트 및 도구를 사용하여 이더리움용으로 개발하는 방법을 배워보세요. 이더리움을 사용하여 탈중앙화 애플리케이션 (dapp)을 만들어보세요. 이러한 dapp은 신뢰할 수 있으며, 이는 이더리움에 배포된 후에는 항상 프로그래밍된 대로 실행됨을 의미합니다. 또한 탈중앙화되어 있어 피어 투 피어 네트워크에서 실행되며 단일 장애점(single point of failure)이 없습니다. 단일 주체나 개인이 이를 제어할 수 없으며 검열이 거의 불가능합니다. 디지털 자산을 제어하여 새로운 종류의 애플리케이션을 만들 수 있습니다. [](https://ethereum.org/ko/developers/docs/programming-languages/golang/#getting-started-with-smart-contracts-and-solidity) 스마트 컨트랙트 및 Solidity 언어 시작하기 ------------------------------------------------------------------------------------------------------------------------------------------------------- **Go와 이더리움을 통합하기 위한 첫걸음을 내디뎌 보세요** 더 기본적인 입문서가 먼저 필요하신가요? [ethereum.org/learn](https://ethereum.org/ko/learn/) 또는 [ethereum.org/developers](https://ethereum.org/ko/developers/) 를 확인해 보세요. * [블록체인 설명 (새 탭에서 열림)](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [스마트 컨트랙트의 이해 (새 탭에서 열림)](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [첫 번째 스마트 컨트랙트 작성하기 (새 탭에서 열림)](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Solidity 컴파일 및 배포 방법 알아보기 (새 탭에서 열림)](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) * [컨트랙트 튜토리얼 (새 탭에서 열림)](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial) [](https://ethereum.org/ko/developers/docs/programming-languages/golang/#beginner-articles-and-books) 초급자용 문서 및 도서 ------------------------------------------------------------------------------------------------------------------ * [Geth 시작하기 (새 탭에서 열림)](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458) * [Golang을 사용하여 이더리움에 연결하기 (새 탭에서 열림)](https://www.youtube.com/watch?v=-7uChuO_VzM) * [Golang을 사용하여 이더리움 스마트 컨트랙트 배포하기 (새 탭에서 열림)](https://www.youtube.com/watch?v=pytGqQmDslE) * [Go에서 이더리움 스마트 컨트랙트를 테스트하고 배포하기 위한 단계별 가이드 (새 탭에서 열림)](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78) * [전자책: Go를 활용한 이더리움 개발 (새 탭에서 열림)](https://goethereumbook.org/) - _Go로 이더리움 애플리케이션 개발하기_ [](https://ethereum.org/ko/developers/docs/programming-languages/golang/#intermediate-articles-and-docs) 중급자용 문서 및 자료 --------------------------------------------------------------------------------------------------------------------- * [고 이더리움 (geth) 공식 문서 (새 탭에서 열림)](https://geth.ethereum.org/docs) - _공식 이더리움 Golang 구현체에 대한 문서_ * [에리곤 프로그래머 가이드 (새 탭에서 열림)](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _상태 트리, 다중 증명(multi-proofs) 및 트랜잭션 처리를 포함한 그림 가이드_ * [에리곤과 무상태(Stateless) 이더리움 (새 탭에서 열림)](https://youtu.be/3-Mn7OckSus?t=394) - _2020 이더리움 커뮤니티 컨퍼런스 (EthCC 3)_ * [에리곤: 이더리움 클라이언트 최적화 (새 탭에서 열림)](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _2018 데브콘 4 (Devcon 4)_ * [고 이더리움 (geth) GoDoc (새 탭에서 열림)](https://godoc.org/github.com/ethereum/go-ethereum) * [Geth를 사용하여 Go로 탈중앙화 애플리케이션 (dapp) 만들기 (새 탭에서 열림)](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/) * [Golang 및 Geth를 사용하여 이더리움 프라이빗 네트워크 작업하기 (새 탭에서 열림)](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php) * [Go를 사용하여 이더리움에서 Solidity 컨트랙트 단위 테스트하기 (새 탭에서 열림)](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281) * [Geth를 라이브러리로 사용하기 위한 빠른 참조 가이드 (새 탭에서 열림)](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e) [](https://ethereum.org/ko/developers/docs/programming-languages/golang/#advanced-use-patterns) 고급 사용 패턴 -------------------------------------------------------------------------------------------------------- * [GETH 시뮬레이션 백엔드 (새 탭에서 열림)](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top) * [이더리움 및 Quorum을 사용한 서비스형 블록체인(BaaS) 앱 (새 탭에서 열림)](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html) * [이더리움 블록체인 애플리케이션의 분산 스토리지 IPFS 및 스웜 (새 탭에서 열림)](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html) * [모바일 클라이언트: 라이브러리 및 Inproc 이더리움 노드 (새 탭에서 열림)](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes) * [네이티브 dapp: 이더리움 컨트랙트에 대한 Go 바인딩 (새 탭에서 열림)](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts) [](https://ethereum.org/ko/developers/docs/programming-languages/golang/#go-projects-and-tools) Go 프로젝트 및 도구 ------------------------------------------------------------------------------------------------------------ * [Geth / 고 이더리움 (geth) (새 탭에서 열림)](https://github.com/ethereum/go-ethereum) - _이더리움 프로토콜의 공식 Go 구현체_ * [고 이더리움 (geth) 코드 분석 (새 탭에서 열림)](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _고 이더리움 (geth) 소스 코드 리뷰 및 분석_ * [에리곤 (새 탭에서 열림)](https://github.com/ledgerwatch/erigon) - _아카이브 노드에 중점을 둔 고 이더리움 (geth)의 더 빠른 파생 버전_ * [골렘 (Golem) (새 탭에서 열림)](https://github.com/golemfactory/golem) - _컴퓨팅 파워를 위한 글로벌 시장을 구축하는 골렘_ * [Quorum (새 탭에서 열림)](https://github.com/jpmorganchase/quorum) - _데이터 프라이버시를 지원하는 이더리움의 허가형 구현체_ * [프리즘 (새 탭에서 열림)](https://github.com/prysmaticlabs/prysm) - _이더리움 '세레니티(Serenity)' 2.0 Go 구현체_ * [Eth Tweet (새 탭에서 열림)](https://github.com/yep/eth-tweet) - _탈중앙화된 트위터: 이더리움 블록체인에서 실행되는 마이크로블로깅 서비스_ * [플라즈마 MVP Golang (새 탭에서 열림)](https://github.com/kyokan/plasma) — _최소 기능 플라즈마(Minimum Viable Plasma) 사양의 Golang 구현 및 확장_ * [오픈 이더리움 채굴 풀 (새 탭에서 열림)](https://github.com/sammy007/open-ethereum-pool) - _오픈 소스 이더리움 채굴 풀_ * [이더리움 HD 지갑 (새 탭에서 열림)](https://github.com/miguelmota/go-ethereum-hdwallet) - _Go로 작성된 이더리움 HD 지갑 파생(derivations)_ * [멀티 Geth (새 탭에서 열림)](https://github.com/multi-geth/multi-geth) - _다양한 종류의 이더리움 네트워크 지원_ * [Geth 경량 클라이언트 (새 탭에서 열림)](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _경량 이더리움 하위 프로토콜(Light Ethereum Subprotocol)의 Geth 구현체_ * [이더리움 Golang SDK (새 탭에서 열림)](https://github.com/everFinance/goether) - _Golang으로 작성된 간단한 이더리움 지갑 구현 및 유틸리티_ * [Covalent Golang SDK (새 탭에서 열림)](https://github.com/covalenthq/covalent-api-sdk-go) - _200개 이상의 블록체인을 위한 Go SDK를 통한 효율적인 블록체인 데이터 액세스_ 더 많은 자료를 찾고 계신가요? [ethereum.org/developers](https://ethereum.org/ko/developers/) 를 확인해 보세요. [](https://ethereum.org/ko/developers/docs/programming-languages/golang/#go-community-contributors) Go 커뮤니티 기여자 --------------------------------------------------------------------------------------------------------------- * [Geth 디스코드 (새 탭에서 열림)](https://discordapp.com/invite/nthXNEv) * [Geth Gist (새 탭에서 열림)](https://gitter.im/ethereum/go-ethereum) * [Gophers 슬랙(Slack) (새 탭에서 열림)](https://invite.slack.golangbridge.org/) - [#ethereum 채널 (새 탭에서 열림)](https://gophers.slack.com/messages/C9HP1S9V2) * [스택익스체인지(StackExchange) - 이더리움 (새 탭에서 열림)](https://ethereum.stackexchange.com/) * [멀티 Geth Gitter (새 탭에서 열림)](https://gitter.im/ethoxy/multi-geth) * [이더리움 Gitter (새 탭에서 열림)](https://gitter.im/ethereum/home) * [Geth 경량 클라이언트 Gitter (새 탭에서 열림)](https://gitter.im/ethereum/light-client) [](https://ethereum.org/ko/developers/docs/programming-languages/golang/#other-aggregated-lists) 기타 종합 목록 --------------------------------------------------------------------------------------------------------- * [Awesome Ethereum (새 탭에서 열림)](https://github.com/btomashvili/awesome-ethereum) * [컨센시스: 이더리움 개발자 도구의 결정판 목록 (새 탭에서 열림)](https://web.archive.org/web/2023/https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [GitHub 소스 (새 탭에서 열림)](https://github.com/ConsenSys/ethereum-developer-tools-list) --- # Uthibitisho | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/attestations/#main-content) Change page Uthibitisho =========== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/consensus-mechanisms/pos/attestations/index.md) Kwenye ukurasa huu Mthibitishaji anatarajiwa kuunda, kutia sahihi na kutangaza uthibitisho wakati wa kila kipindi. Ukurasa huu unaelezea jinsi uthibitisho huu unavyoonekana na jinsi unavyochakatwa na kuwasilishwa kati ya wateja wa mwafaka. [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/attestations/#what-is-an-attestation) Uthibitisho ni nini? ------------------------------------------------------------------------------------------------------------------------------ Kila (dakika 6.4) mthibitishaji hupendekeza uthibitisho kwenye mtandao. Uthibitisho ni kwa ajili ya sloti maalum katika kipindi. Kusudi la uthibitisho ni kupiga kura kuunga mkono mtazamo wa mthibitishaji wa mnyororo, haswa kitalu cha hivi karibuni kilichohalalishwa na kitalu cha kwanza katika kipindi cha sasa (kinachojulikana kama vituo vya ukaguzi vya `source` na `target`). Taarifa hii hujumuishwa kwa wathibitishaji wote wanaoshiriki, na kuwezesha mtandao kufikia mwafaka kuhusu hali ya mnyororo wa vitalu. Uthibitisho una vipengele vifuatavyo: * `aggregation_bits`: orodha ya biti ya wathibitishaji ambapo nafasi inalingana na faharisi ya mthibitishaji katika kamati yao; thamani (0/1) inaonyesha ikiwa mthibitishaji alitia sahihi `data` (yaani, ikiwa wanafanya kazi na wanakubaliana na mpendekezaji wa bloku) * `data`: maelezo yanayohusiana na uthibitisho, kama ilivyofafanuliwa hapa chini * `signature`: sahihi ya BLS inayojumuisha sahihi za wathibitishaji binafsi Kazi ya kwanza kwa mthibitishaji anayethibitisha ni kuunda `data`. `data` ina taarifa zifuatazo: * `slot`: Nambari ya sloti ambayo uthibitisho unarejelea * `index`: Nambari inayotambulisha kamati ambayo mthibitishaji ni mwanachama katika sloti fulani * `beacon_block_root`: Heshi ya mzizi ya kitalu ambacho mthibitishaji anakiona kwenye kichwa cha mnyororo (matokeo ya kutumia algoriti ya uchaguzi wa mchepuo) * `source`: Sehemu ya kura ya ukamilifu inayoonyesha kile wathibitishaji wanachokiona kama kitalu cha hivi karibuni kilichohalalishwa * `target`: Sehemu ya kura ya ukamilifu inayoonyesha kile wathibitishaji wanachokiona kama kitalu cha kwanza katika kipindi cha sasa Mara tu `data` inapoundwa, mthibitishaji anaweza kubadilisha biti katika `aggregation_bits` inayolingana na faharisi yao wenyewe ya mthibitishaji kutoka 0 hadi 1 ili kuonyesha kuwa walishiriki. Hatimaye, mthibitishaji hutia sahihi uthibitisho na kuutangaza kwenye mtandao. ### [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/attestations/#aggregated-attestation) Uthibitisho uliojumuishwa Kuna mzigo mkubwa unaohusishwa na kupitisha data hii kwenye mtandao kwa kila mthibitishaji. Kwa hivyo, uthibitisho kutoka kwa wathibitishaji binafsi hujumuishwa ndani ya mitandao midogo kabla ya kutangazwa kwa upana zaidi. Hii inajumuisha kujumuisha sahihi pamoja ili uthibitisho unaotangazwa ujumuishe mwafaka wa `data` na sahihi moja inayoundwa kwa kuchanganya sahihi za wathibitishaji wote wanaokubaliana na `data` hiyo. Hii inaweza kuangaliwa kwa kutumia `aggregation_bits` kwa sababu hii inatoa faharisi ya kila mthibitishaji katika kamati yao (ambayo kitambulisho chake kimetolewa katika `data`) ambayo inaweza kutumika kuulizia sahihi za mtu binafsi. Katika kila kipindi wathibitishaji 16 katika kila mtandao mdogo huchaguliwa kuwa `aggregators`. Wajumuishaji hukusanya uthibitisho wote wanaousikia kupitia mtandao wa uvumi ambao una `data` sawa na wao. Mtumaji wa kila uthibitisho unaolingana hurekodiwa katika `aggregation_bits`. Kisha wajumuishaji hutangaza mjumuisho wa uthibitisho kwenye mtandao mpana zaidi. Wakati mthibitishaji anachaguliwa kuwa mpendekezaji wa bloku, hufunga uthibitisho uliojumuishwa kutoka kwenye mitandao midogo hadi kwenye sloti ya hivi karibuni katika kitalu kipya. ### [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/attestations/#attestation-inclusion-lifecycle) Mzunguko wa maisha wa ujumuishaji wa uthibitisho 1. Uundaji 2. Uenezaji 3. Ukusanyaji 4. Uenezaji 5. Ujumuishaji Mzunguko wa maisha wa uthibitisho umeainishwa katika mchoro hapa chini: [![attestation lifecycle](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fconsensus-mechanisms%2Fpos%2Fattestations%2Fattestation_schematic.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/consensus-mechanisms/pos/attestations/attestation_schematic.png) [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/attestations/#rewards) Tuzo ----------------------------------------------------------------------------------------------- Wathibitishaji hupewa tuzo kwa kuwasilisha uthibitisho. Tuzo ya uthibitisho inategemea bendera za ushiriki (chanzo, lengo na kichwa), tuzo ya msingi na kiwango cha ushiriki. Kila moja ya bendera za ushiriki inaweza kuwa kweli au si kweli, kulingana na uthibitisho uliowasilishwa na ucheleweshaji wake wa ujumuishaji. Hali bora zaidi hutokea wakati bendera zote tatu ni za kweli, ambapo mthibitishaji atapata (kwa kila bendera sahihi): `reward += base reward * flag weight * flag attesting rate / 64` Kiwango cha uthibitishaji wa bendera hupimwa kwa kutumia jumla ya salio tendaji la wathibitishaji wote wanaothibitisha kwa bendera iliyotolewa ikilinganishwa na jumla ya salio tendaji linalofanya kazi. ### [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/attestations/#base-reward) Tuzo ya msingi Tuzo ya msingi hukokotolewa kulingana na idadi ya wathibitishaji wanaothibitisha na salio lao tendaji la Etha lililowekwa dhamana: `base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)` #### [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/attestations/#inclusion-delay) Ucheleweshaji wa ujumuishaji Wakati wathibitishaji walipopiga kura kwenye kichwa cha mnyororo (`block n`), `block n+1` kilikuwa bado hakijapendekezwa. Kwa hivyo uthibitisho kwa kawaida hujumuishwa **kitalu kimoja baadaye** kwa hivyo uthibitisho wote uliopiga kura kwenye `block n` kuwa kichwa cha mnyororo ulijumuishwa katika `block n+1` na, **ucheleweshaji wa ujumuishaji** ni 1. Ikiwa ucheleweshaji wa ujumuishaji utaongezeka maradufu hadi sloti mbili, tuzo ya uthibitisho hupungua nusu, kwa sababu ili kukokotoa tuzo ya uthibitisho tuzo ya msingi huzidishwa na kinyume cha ucheleweshaji wa ujumuishaji. ### [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/attestations/#attestation-scenarios) Matukio ya uthibitisho #### [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/attestations/#missing-voting-validator) Mthibitishaji Anayepiga Kura Aliyekosekana Wathibitishaji wana kiwango cha juu cha kipindi 1 cha kuwasilisha uthibitisho wao. Ikiwa uthibitisho ulikosekana katika kipindi cha 0, wanaweza kuuwasilisha kwa ucheleweshaji wa ujumuishaji katika kipindi cha 1. #### [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/attestations/#missing-aggregator) Mkusanyaji Aliyekosekana Kuna Wakusanyaji 16 kwa kila kipindi kwa jumla. Kwa kuongezea, wathibitishaji wa nasibu hujiandikisha kwenye **mitandao midogo miwili kwa vipindi 256** na hutumika kama mbadala endapo wakusanyaji watakosekana. #### [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/attestations/#missing-block-proposer) Mpendekezaji wa bloku aliyekosekana Kumbuka kwamba katika baadhi ya matukio mkusanyaji mwenye bahati anaweza pia kuwa mpendekezaji wa bloku. Ikiwa uthibitisho haukujumuishwa kwa sababu mpendekezaji wa bloku amekosekana, mpendekezaji wa bloku anayefuata atachukua uthibitisho uliokusanywa na kuujumuisha kwenye kitalu kinachofuata. Hata hivyo, **ucheleweshaji wa ujumuishaji** utaongezeka kwa moja. [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/attestations/#further-reading) Usomaji zaidi ---------------------------------------------------------------------------------------------------------------- * [Uthibitisho katika maelezo ya mwafaka yaliyofafanuliwa ya Vitalik (inafunguka katika kichupo kipya)](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) * [Uthibitisho katika eth2book.info (inafunguka katika kichupo kipya)](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) _Unajua rasilimali ya jamii iliyokusaidia? Hariri ukurasa huu na uiongeze!_ --- # Rust 개발자를 위한 이더리움 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/programming-languages/rust/#main-content) Change page Rust 개발자를 위한 이더리움 ================= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/rust/index.md) 이 페이지의 내용 Rust 기반 프로젝트 및 도구를 사용하여 이더리움용으로 개발하는 방법을 알아보세요. 이더리움을 사용하여 암호화폐와 블록체인 기술의 이점을 활용하는 탈중앙화 애플리케이션 (dapp)을 만들어보세요. 이러한 dapp은 신뢰할 수 있으며, 이는 이더리움에 배포된 후에는 항상 프로그래밍된 대로 실행됨을 의미합니다. 디지털 자산을 제어하여 새로운 종류의 금융 애플리케이션을 만들 수 있습니다. 또한 탈중앙화되어 있어 단일 주체나 개인이 제어할 수 없으며 검열이 거의 불가능합니다. [](https://ethereum.org/ko/developers/docs/programming-languages/rust/#getting-started-with-smart-contracts-and-solidity) 스마트 컨트랙트 및 Solidity 언어 시작하기 ----------------------------------------------------------------------------------------------------------------------------------------------------- **Rust를 이더리움과 통합하기 위한 첫걸음을 내디뎌보세요** 더 기본적인 입문서가 먼저 필요하신가요? [ethereum.org/learn](https://ethereum.org/ko/learn/) 또는 [ethereum.org/developers](https://ethereum.org/ko/developers/) 를 확인해 보세요. * [블록체인 설명 (새 탭에서 열림)](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [스마트 컨트랙트 이해하기 (새 탭에서 열림)](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [첫 번째 스마트 컨트랙트 작성하기 (새 탭에서 열림)](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Solidity 컴파일 및 배포 방법 알아보기 (새 탭에서 열림)](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) [](https://ethereum.org/ko/developers/docs/programming-languages/rust/#beginner-articles) 초급자용 문서 ------------------------------------------------------------------------------------------------- * [Rust 이더리움 클라이언트 (새 탭에서 열림)](https://openethereum.github.io/) \* **OpenEthereum은 [더 이상 사용되지 않으며 (새 탭에서 열림)](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) 유지 관리되지 않습니다.** 주의해서 사용하고 가급적 다른 클라이언트 구현으로 전환하세요. * [Rust를 사용하여 이더리움으로 트랜잭션 전송하기 (새 탭에서 열림)](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/) * [Kovan을 위해 Rust Wasm으로 컨트랙트를 작성하는 방법에 대한 단계별 튜토리얼 (새 탭에서 열림)](https://github.com/paritytech/pwasm-tutorial) [](https://ethereum.org/ko/developers/docs/programming-languages/rust/#intermediate-articles) 중급자용 문서 ----------------------------------------------------------------------------------------------------- [](https://ethereum.org/ko/developers/docs/programming-languages/rust/#advanced-use-patterns) 고급 사용 패턴 ------------------------------------------------------------------------------------------------------ * [이더리움과 유사한 네트워크와 상호 작용하기 위한 pwasm\_ethereum externs 라이브러리 (새 탭에서 열림)](https://github.com/openethereum/pwasm-ethereum) * [JavaScript 및 Rust를 사용하여 탈중앙화 채팅 앱 구축하기 (새 탭에서 열림)](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52) * [Vue.js 및 Rust를 사용하여 탈중앙화 할 일(Todo) 앱 구축하기 (새 탭에서 열림)](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb) * [Rust로 블록체인 구축하기 (새 탭에서 열림)](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/) [](https://ethereum.org/ko/developers/docs/programming-languages/rust/#rust-projects-and-tools) Rust 프로젝트 및 도구 -------------------------------------------------------------------------------------------------------------- * [pwasm-ethereum (새 탭에서 열림)](https://github.com/paritytech/pwasm-ethereum) - _이더리움과 유사한 네트워크와 상호 작용하기 위한 externs 모음_ * [라이트하우스 (새 탭에서 열림)](https://github.com/sigp/lighthouse) - _빠른 이더리움 합의 레이어 클라이언트_ * [이더리움 WebAssembly (새 탭에서 열림)](https://ewasm.readthedocs.io/en/mkdocs/) - _결정론적 WebAssembly 하위 집합을 사용한 이더리움 스마트 컨트랙트 실행 계층의 재설계 제안_ * [oasis\_std (새 탭에서 열림)](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _OASIS API 참조_ * [Solaris (새 탭에서 열림)](https://github.com/paritytech/sol-rs) - _네이티브 Parity 클라이언트 EVM을 사용하는 Solidity 스마트 컨트랙트 단위 테스트 하네스._ * [SputnikVM (새 탭에서 열림)](https://github.com/rust-blockchain/evm) - _Rust 이더리움 가상 머신 구현_ * [Wavelet (새 탭에서 열림)](https://github.com/perlin-network/smart-contract-rs) - _Rust로 작성된 Wavelet 스마트 컨트랙트_ * [Foundry (새 탭에서 열림)](https://github.com/foundry-rs/foundry) - _이더리움 애플리케이션 개발을 위한 툴킷_ * [Alloy (새 탭에서 열림)](https://alloy.rs/) - _이더리움 및 기타 EVM 기반 체인과 상호 작용하기 위한 고성능의 잘 테스트되고 문서화된 라이브러리._ * [Ethers\_rs (새 탭에서 열림)](https://github.com/gakonst/ethers-rs) - _이더리움 라이브러리 및 지갑 구현_ * [SewUp (새 탭에서 열림)](https://github.com/second-state/SewUp) - _일반적인 백엔드에서 개발하는 것처럼 Rust로 이더리움 WebAssembly 컨트랙트를 구축할 수 있도록 돕는 라이브러리_ * [Substreams (새 탭에서 열림)](https://github.com/streamingfast/substreams) - _병렬화된 블록체인 데이터 인덱싱 기술_ * [레스 (새 탭에서 열림)](https://github.com/paradigmxyz/reth) 레스(Rust Ethereum의 약자)는 새로운 이더리움 풀 노드 구현입니다. * [Awesome Ethereum Rust (새 탭에서 열림)](https://github.com/Vid201/awesome-ethereum-rust) - _Rust로 작성된 이더리움 생태계 프로젝트의 엄선된 모음_ * [Stylus (새 탭에서 열림)](https://github.com/OffchainLabs/stylus) - _Arbitrum에서 스마트 컨트랙트를 구축하기 위한 Rust SDK_ 더 많은 리소스를 찾고 계신가요? [ethereum.org/developers.](https://ethereum.org/ko/developers/) 를 확인해 보세요. [](https://ethereum.org/ko/developers/docs/programming-languages/rust/#rust-community-contributors) Rust 커뮤니티 기여자 ----------------------------------------------------------------------------------------------------------------- * [이더리움 WebAssembly (새 탭에서 열림)](https://gitter.im/ewasm/Lobby) * [Oasis Gitter (새 탭에서 열림)](https://gitter.im/Oasis-official/Lobby) * [Parity Gitter (새 탭에서 열림)](https://gitter.im/paritytech/parity) * [Enigma (새 탭에서 열림)](https://discord.gg/SJK32GY) --- # Upatikanaji wa data | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/data-availability/#main-content) Change page Upatikanaji wa data =================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-availability/index.md) Kwenye ukurasa huu "Usiamini, thibitisha" ni msemo wa kawaida katika Ethereum. Wazo ni kwamba nodi yako inaweza kuthibitisha kwa kujitegemea kuwa taarifa inayopokea ni sahihi kwa kutekeleza miamala yote katika vitalu inavyopokea kutoka kwa wenzao ili kuhakikisha kuwa mabadiliko yaliyopendekezwa yanalingana kikamilifu na yale yaliyokokotolewa kwa kujitegemea na nodi. Hii inamaanisha nodi hazilazimiki kuamini kwamba watumaji wa kitalu ni waaminifu. Hili haliwezekani ikiwa data inakosekana. **Upatikanaji wa data** unarejelea ujasiri ambao mtumiaji anaweza kuwa nao kwamba data inayohitajika kuthibitisha kitalu inapatikana kweli kwa washiriki wote wa mtandao. Kwa nodi kamili kwenye tabaka la 1 (l1) la [Ethereum](https://ethereum.org/sw/) hii ni rahisi kiasi; nodi kamili hupakua nakala ya data yote katika kila kitalu - data _lazima_ ipatikane ili upakuaji uwezekane. Kitalu chenye data inayokosekana kitatupiliwa mbali badala ya kuongezwa kwenye mnyororo wa vitalu. Huu ni "upatikanaji wa data mnyororoni" na ni kipengele cha minyororo ya vitalu ya monolitiki. Nodi kamili haziwezi kudanganywa kukubali miamala batili kwa sababu zinapakua na kutekeleza kila muamala zenyewe. Hata hivyo, kwa minyororo ya vitalu ya kawaida, mikusanyiko ya tabaka la 2 (l2) na viteja vyepesi, mazingira ya upatikanaji wa data ni magumu zaidi, yakihitaji taratibu za uthibitishaji za kisasa zaidi. [](https://ethereum.org/sw/developers/docs/data-availability/#prerequisites) Mahitaji ya awali ---------------------------------------------------------------------------------------------- Unapaswa kuwa na uelewa mzuri wa [misingi ya mnyororo wa vitalu](https://ethereum.org/sw/developers/docs/intro-to-ethereum/) , hasa [mbinu za mwafaka](https://ethereum.org/sw/developers/docs/consensus-mechanisms/) . Ukurasa huu pia unachukulia kuwa msomaji anafahamu [vitalu](https://ethereum.org/sw/developers/docs/blocks/) , [miamala](https://ethereum.org/sw/developers/docs/transactions/) , [nodi](https://ethereum.org/sw/developers/docs/nodes-and-clients/) , [suluhisho za kuongeza uwezo](https://ethereum.org/sw/developers/docs/scaling/) , na mada nyingine husika. [](https://ethereum.org/sw/developers/docs/data-availability/#the-data-availability-problem) Tatizo la upatikanaji wa data -------------------------------------------------------------------------------------------------------------------------- Tatizo la upatikanaji wa data ni hitaji la kuthibitisha kwa mtandao mzima kwamba muhtasari wa baadhi ya data za muamala zinazoongezwa kwenye mnyororo wa vitalu unawakilisha kweli seti ya miamala halali, lakini kufanya hivyo bila kuhitaji nodi zote kupakua data yote. Data kamili ya muamala ni muhimu kwa kuthibitisha vitalu kwa kujitegemea, lakini kuhitaji nodi zote kupakua data yote ya muamala ni kikwazo cha kuongeza uwezo. Suluhisho za tatizo la upatikanaji wa data zinalenga kutoa hakikisho la kutosha kwamba data kamili ya muamala ilipatikana kwa uthibitishaji kwa washiriki wa mtandao ambao hawapakui na kuhifadhi data wenyewe. [Nodi nyepesi](https://ethereum.org/sw/developers/docs/nodes-and-clients/light-clients/) na [mikusanyiko ya tabaka la 2 (l2)](https://ethereum.org/sw/developers/docs/scaling/) ni mifano muhimu ya washiriki wa mtandao wanaohitaji hakikisho dhabiti la upatikanaji wa data lakini hawawezi kupakua na kuchakata data ya muamala wenyewe. Kuepuka kupakua data ya muamala ndiko kunakofanya nodi nyepesi kuwa nyepesi na kuwezesha mikusanyiko kuwa suluhisho bora za kuongeza uwezo. Upatikanaji wa data pia ni suala muhimu kwa wateja wa Ethereum wa baadaye ["wasio na hali"](https://ethereum.org/sw/roadmap/statelessness/) ambao hawahitaji kupakua na kuhifadhi data ya hali ili kuthibitisha vitalu. Wateja wasio na hali bado wanahitaji kuwa na uhakika kwamba data inapatikana _mahali fulani_ na kwamba imechakatwa kwa usahihi. [](https://ethereum.org/sw/developers/docs/data-availability/#data-availability-solutions) Suluhisho za upatikanaji wa data --------------------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/sw/developers/docs/data-availability/#data-availability-sampling) Sampuli ya upatikanaji wa data (DAS) Sampuli ya Upatikanaji wa Data (DAS) ni njia ya mtandao kuangalia kuwa data inapatikana bila kuweka mzigo mkubwa kwenye nodi yoyote binafsi. Kila nodi (ikiwa ni pamoja na nodi zisizoweka dhamana) hupakua sehemu ndogo, iliyochaguliwa kwa nasibu ya data yote. Kupakua sampuli kwa ufanisi kunathibitisha kwa ujasiri mkubwa kwamba data yote inapatikana. Hii inategemea usimbaji wa ufutaji wa data, ambao hupanua seti fulani ya data na taarifa za ziada (njia hii inafanywa ni kutosheleza utendakazi unaojulikana kama _polinomiali_ juu ya data na kutathmini polinomiali hiyo katika pointi za ziada). Hii inaruhusu data asili kurejeshwa kutoka kwa data ya ziada inapohitajika. Matokeo ya uundaji huu wa data ni kwamba ikiwa _yoyote_ ya data asili haipatikani, _nusu_ ya data iliyopanuliwa itakosekana! Kiasi cha sampuli za data zinazopakuliwa na kila nodi kinaweza kurekebishwa ili iwe na uwezekano _mkubwa sana_ kwamba angalau moja ya vipande vya data vilivyochukuliwa sampuli na kila mteja vitakosekana _ikiwa_ chini ya nusu ya data inapatikana kweli. DAS itatumika kuhakikisha waendeshaji wa rollup wanafanya data yao ya muamala ipatikane baada ya [danksharding Kamili](https://ethereum.org/sw/roadmap/danksharding/#what-is-danksharding) kutekelezwa. Nodi za Ethereum zitachukua sampuli kwa nasibu za data ya muamala iliyotolewa katika mablobu kwa kutumia mpango wa ziada ulioelezwa hapo juu ili kuhakikisha kuwa data yote ipo. Mbinu hiyo hiyo inaweza pia kutumika kuhakikisha wazalishaji wa kitalu wanafanya data yao yote ipatikane ili kulinda viteja vyepesi. Vile vile, chini ya [utengano wa mpendekezaji na mjengaji (PBS)](https://ethereum.org/sw/roadmap/pbs/) , mjenga kizuizi pekee ndiye atahitajika kuchakata kitalu kizima - wathibitishaji wengine wangethibitisha kwa kutumia sampuli ya upatikanaji wa data. ### [](https://ethereum.org/sw/developers/docs/data-availability/#data-availability-committees) Kamati za upatikanaji wa data Kamati za Upatikanaji wa Data (DACs) ni pande zinazoaminika zinazotoa, au kuthibitisha, upatikanaji wa data. DACs zinaweza kutumika badala ya, [au kwa pamoja na (inafunguka katika kichupo kipya)](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) DAS. Dhamana za usalama zinazokuja na kamati zinategemea usanidi maalum. Ethereum hutumia vikundi vidogo vya wathibitishaji vilivyochukuliwa sampuli kwa nasibu kuthibitisha upatikanaji wa data kwa nodi nyepesi, kwa mfano. DACs pia hutumiwa na baadhi ya validiums. DAC ni seti inayoaminika ya nodi inayohifadhi nakala za data nje ya mtandao. DAC inahitajika kufanya data ipatikane katika tukio la mzozo. Wanachama wa DAC pia huchapisha uthibitisho mnyororoni ili kuthibitisha kwamba data iliyotajwa inapatikana kweli. Baadhi ya validiums hubadilisha DACs na mfumo wa mthibitishaji wa Uthibitisho wa Dau (PoS). Hapa, mtu yeyote anaweza kuwa mthibitishaji na kuhifadhi data nje ya mnyororo. Hata hivyo, lazima watoe "dhamana", ambayo inawekwa katika mkataba mahiri. Katika tukio la tabia mbaya, kama vile mthibitishaji kuzuia data, dhamana inaweza kufanyiwa ukataji. Kamati za upatikanaji wa data za Uthibitisho wa Dau ni salama zaidi kuliko DACs za kawaida kwa sababu zinahamasisha moja kwa moja tabia ya uaminifu. [](https://ethereum.org/sw/developers/docs/data-availability/#data-availability-and-light-nodes) Upatikanaji wa data na nodi nyepesi ------------------------------------------------------------------------------------------------------------------------------------ [Nodi nyepesi](https://ethereum.org/sw/developers/docs/nodes-and-clients/light-clients/) zinahitaji kuthibitisha usahihi wa vichwa vya kizuizi zinazopokea bila kupakua data ya kitalu. Gharama ya wepesi huu ni kutoweza kuthibitisha kwa kujitegemea vichwa vya kizuizi kwa kutekeleza upya miamala ndani kwa ndani kwa njia ambayo nodi kamili hufanya. Nodi nyepesi za Ethereum zinaamini seti za nasibu za wathibitishaji 512 ambao wamepewa _kamati ya usawazishaji_. Kamati ya usawazishaji hufanya kazi kama DAC inayoashiria kwa viteja vyepesi kwamba data katika kichwa ni sahihi kwa kutumia sahihi ya kificho. Kila siku, kamati ya usawazishaji hujisasisha. Kila kichwa cha kizuizi huarifu nodi nyepesi kuhusu wathibitishaji gani wa kutarajia kutia sahihi kitalu _kijacho_, kwa hivyo haziwezi kudanganywa kuamini kikundi kibaya kinachojifanya kuwa kamati halisi ya usawazishaji. Hata hivyo, nini kinatokea ikiwa mshambuliaji kwa namna fulani _atafanikiwa_ kupitisha kichwa cha kizuizi kibaya kwa viteja vyepesi na kuwashawishi kwamba kilitiwa sahihi na kamati ya usawazishaji ya uaminifu? Katika hali hiyo, mshambuliaji anaweza kujumuisha miamala batili na kiteja chepesi kitazikubali kwa upofu, kwani hazikagui kwa kujitegemea mabadiliko yote ya hali yaliyofupishwa katika kichwa cha kizuizi. Ili kujilinda dhidi ya hili, kiteja chepesi kinaweza kutumia ushahidi wa udanganyifu. Njia ambayo ushahidi huu wa udanganyifu hufanya kazi ni kwamba nodi kamili, ikiona mabadiliko batili ya hali yakisambazwa kwenye mtandao, inaweza haraka kuzalisha kipande kidogo cha data kinachoonyesha kwamba mabadiliko ya hali yaliyopendekezwa hayawezi kutokea kutoka kwa seti fulani ya miamala na kutangaza data hiyo kwa wenzao. Nodi nyepesi zinaweza kuchukua ushahidi huo wa udanganyifu na kuutumia kutupa vichwa vibaya vya kizuizi, kuhakikisha zinabaki kwenye mnyororo huo huo wa uaminifu kama nodi kamili. Hii inategemea nodi kamili kuwa na ufikiaji wa data kamili ya muamala. Mshambuliaji anayetangaza kichwa kibaya cha kizuizi na pia kushindwa kufanya data ya muamala ipatikane ataweza kuzuia nodi kamili kuzalisha ushahidi wa udanganyifu. Nodi kamili zinaweza kuashiria onyo kuhusu kitalu kibaya, lakini hazingeweza kuunga mkono onyo lao kwa ushahidi, kwa sababu data haikupatikana ili kuzalisha ushahidi kutoka kwayo! Suluhisho la tatizo hili la upatikanaji wa data ni DAS. Nodi nyepesi hupakua vipande vidogo sana vya nasibu vya data kamili ya hali na kutumia sampuli kuthibitisha kuwa seti kamili ya data inapatikana. Uwezekano halisi wa kudhani kimakosa upatikanaji kamili wa data baada ya kupakua vipande N vya nasibu unaweza kukokotolewa ([kwa vipande 100 nafasi ni 10^-30 (inafunguka katika kichupo kipya)](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) , yaani, haiwezekani sana). Hata katika hali hii, mashambulizi yanayozuia baiti chache tu yanaweza kupita bila kutambuliwa na wateja wanaofanya maombi ya data ya nasibu. Usimbaji wa ufutaji hurekebisha hili kwa kujenga upya vipande vidogo vya data vinavyokosekana ambavyo vinaweza kutumika kuangalia mabadiliko ya hali yaliyopendekezwa. Ushahidi wa udanganyifu unaweza kisha kujengwa kwa kutumia data iliyojengwa upya, kuzuia nodi nyepesi kukubali vichwa vibaya. **Kumbuka:** DAS na ushahidi wa udanganyifu bado hazijatekelezwa kwa viteja vyepesi vya Ethereum vya Uthibitisho wa Dau, lakini viko kwenye ramani ya njia, uwezekano mkubwa vikichukua fomu ya ushahidi unaotegemea ZK-SNARK. Viteja vyepesi vya leo vinategemea aina ya DAC: vinathibitisha utambulisho wa kamati ya usawazishaji na kisha kuamini vichwa vya kizuizi vilivyotiwa sahihi vinavyopokea. [](https://ethereum.org/sw/developers/docs/data-availability/#data-availability-and-layer-2-rollups) Upatikanaji wa data na mikusanyiko ya tabaka la 2 (l2) ----------------------------------------------------------------------------------------------------------------------------------------------------------- [Suluhisho za kuongeza uwezo za tabaka la 2 (l2)](https://ethereum.org/sw/layer-2/) , kama vile , hupunguza gharama za muamala na kuongeza uwezo wa upitishaji wa Ethereum kwa kuchakata miamala nje ya mnyororo. Miamala ya rollup inabanwa na kuchapishwa kwenye Ethereum kwa makundi. Makundi yanawakilisha maelfu ya miamala ya mtu binafsi ya nje ya mnyororo katika muamala mmoja kwenye Ethereum. Hii inapunguza msongamano kwenye tabaka la msingi na kupunguza ada kwa watumiaji. Hata hivyo, inawezekana tu kuamini miamala ya 'muhtasari' iliyochapishwa kwenye Ethereum ikiwa mabadiliko ya hali yaliyopendekezwa yanaweza kuthibitishwa kwa kujitegemea na kuthibitishwa kuwa matokeo ya kutumia miamala yote ya mtu binafsi ya nje ya mnyororo. Ikiwa waendeshaji wa rollup hawafanyi data ya muamala ipatikane kwa uthibitishaji huu, basi wanaweza kutuma data isiyo sahihi kwa Ethereum. [Mikusanyiko yenye matumaini](https://ethereum.org/sw/developers/docs/scaling/optimistic-rollups/) huchapisha data ya muamala iliyobanwa kwa Ethereum na kusubiri kwa muda fulani (kawaida siku 7) kuruhusu wathibitishaji huru kuangalia data. Ikiwa mtu yeyote atatambua tatizo, anaweza kuzalisha ushahidi wa udanganyifu na kuutumia kupinga rollup. Hii itasababisha mnyororo kurudi nyuma na kuacha kitalu batili. Hili linawezekana tu ikiwa data inapatikana. Kwa sasa, kuna njia mbili ambazo mikusanyiko yenye matumaini huchapisha data ya muamala kwa L1. Baadhi ya mikusanyiko hufanya data ipatikane kudumu kama `CALLDATA` ambayo huishi kudumu mnyororoni. Pamoja na utekelezaji wa EIP-4844, baadhi ya mikusanyiko huchapisha data yao ya muamala kwenye hifadhi ya blobu ya bei nafuu badala yake. Hii sio hifadhi ya kudumu. Wathibitishaji huru wanapaswa kuuliza mablobu na kuibua changamoto zao ndani ya siku ~18 kabla ya data kufutwa kutoka kwa tabaka la 1 (l1) la Ethereum. Upatikanaji wa data unahakikishwa tu na itifaki ya Ethereum kwa dirisha hilo fupi lililowekwa. Baada ya hapo, inakuwa jukumu la vyombo vingine katika mfumo wa ikolojia wa Ethereum. Nodi yoyote inaweza kuthibitisha upatikanaji wa data kwa kutumia DAS, yaani, kwa kupakua sampuli ndogo, za nasibu za data ya blobu. [Mikusanyiko ya sifuri-maarifa (ZK)](https://ethereum.org/sw/developers/docs/scaling/zk-rollups/) haihitaji kuchapisha data ya muamala kwa kuwa unahakikisha usahihi wa mabadiliko ya hali. Hata hivyo, upatikanaji wa data bado ni suala kwa sababu hatuwezi kuhakikisha utendakazi wa ZK-rollup (au kuingiliana nayo) bila ufikiaji wa data yake ya hali. Kwa mfano, watumiaji hawawezi kujua salio lao ikiwa mwendeshaji anazuia maelezo kuhusu hali ya rollup. Pia, hawawezi kufanya sasisho za hali kwa kutumia taarifa zilizomo katika kitalu kipya kilichoongezwa. [](https://ethereum.org/sw/developers/docs/data-availability/#data-availability-vs-data-retrievability) Upatikanaji wa data dhidi ya urejeshaji wa data ------------------------------------------------------------------------------------------------------------------------------------------------------- Upatikanaji wa data ni tofauti na urejeshaji wa data. Upatikanaji wa data ni hakikisho kwamba nodi kamili zimeweza kufikia na kuthibitisha seti kamili ya miamala inayohusishwa na kitalu maalum. Haimaanishi lazima kwamba data inapatikana milele. Urejeshaji wa data ni uwezo wa nodi kurejesha _taarifa za kihistoria_ kutoka kwa mnyororo wa vitalu. Data hii ya kihistoria haihitajiki kwa kuthibitisha vitalu vipya, inahitajika tu kwa usawazishaji wa nodi kamili kutoka kwa kitalu cha asili au kuhudumia maombi maalum ya kihistoria. Itifaki ya msingi ya Ethereum inahusika kimsingi na upatikanaji wa data, sio urejeshaji wa data. Urejeshaji wa data unaweza kutolewa na idadi ndogo ya nodi za kumbukumbu zinazoendeshwa na wahusika wengine, au inaweza kusambazwa kwenye mtandao kwa kutumia hifadhi ya faili iliyogatuliwa kama vile [Potal Netwoki (inafunguka katika kichupo kipya)](https://www.ethportal.net/) . [](https://ethereum.org/sw/developers/docs/data-availability/#further-reading) Usomaji zaidi -------------------------------------------------------------------------------------------- * [Upatikanaji wa Data ni nini? (inafunguka katika kichupo kipya)](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) * [Upatikanaji wa Data ni Nini? (inafunguka katika kichupo kipya)](https://coinmarketcap.com/academy/article/what-is-data-availability) * [Mwongozo wa ukaguzi wa upatikanaji wa data (inafunguka katika kichupo kipya)](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) * [Maelezo ya pendekezo la sharding + DAS (inafunguka katika kichupo kipya)](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) * [Dokezo kuhusu upatikanaji wa data na usimbaji wa ufutaji (inafunguka katika kichupo kipya)](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) * [Kamati za upatikanaji wa data. (inafunguka katika kichupo kipya)](https://medium.com/starkware/data-availability-e5564c416424) * [Kamati za upatikanaji wa data za Uthibitisho wa Dau. (inafunguka katika kichupo kipya)](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) * [Suluhisho za tatizo la urejeshaji wa data (inafunguka katika kichupo kipya)](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) * [Upatikanaji wa Data Au: Jinsi Mikusanyiko Ilivyojifunza Kuacha Kuwa na Wasiwasi na Kuipenda Ethereum (inafunguka katika kichupo kipya)](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) * [EIP-7623: Kuongeza Gharama ya Data za Mwito (inafunguka katika kichupo kipya)](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) --- # Mashine Pepe ya Ethereum (EVM) | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/evm/#main-content) Change page Mashine Pepe ya Ethereum (EVM) ============================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/evm/index.md) Kwenye ukurasa huu Mashine Pepe ya Ethereum (EVM) ni mazingira pepe yaliyogatuliwa ambayo hutekeleza msimbo kwa uthabiti na usalama kwenye nodi zote za [Ethereum](https://ethereum.org/sw/) . Nodi huendesha EVM ili kutekeleza mikataba mahiri, zikitumia "[gesi](https://ethereum.org/sw/developers/docs/gas/) " kupima juhudi za kikokotoo zinazohitajika kwa [operesheni](https://ethereum.org/sw/developers/docs/evm/opcodes/) , kuhakikisha ugawaji mzuri wa rasilimali na usalama wa mtandao. [](https://ethereum.org/sw/developers/docs/evm/#prerequisites) Mahitaji ya Awali -------------------------------------------------------------------------------- Uelewa wa kimsingi wa istilahi za kawaida katika sayansi ya kompyuta kama vile [baiti (inafunguka katika kichupo kipya)](https://wikipedia.org/wiki/Byte) , [kumbukumbu (inafunguka katika kichupo kipya)](https://wikipedia.org/wiki/Computer_memory) , na [staki (inafunguka katika kichupo kipya)](https://wikipedia.org/wiki/Stack_(abstract_data_type)) ni muhimu ili kuelewa EVM. Pia itakuwa na manufaa kuwa na uelewa mzuri wa dhana za kriptografia/mnyororo wa vitalu kama vile [fomula za heshi (inafunguka katika kichupo kipya)](https://wikipedia.org/wiki/Cryptographic_hash_function) na [mti wa Merkle (inafunguka katika kichupo kipya)](https://wikipedia.org/wiki/Merkle_tree) . [](https://ethereum.org/sw/developers/docs/evm/#from-ledger-to-state-machine) Kutoka leja hadi mashine ya hali -------------------------------------------------------------------------------------------------------------- Mfano wa 'leja iliyosambazwa' mara nyingi hutumika kuelezea minyororo ya vitalu kama Bitcoin, ambayo huwezesha sarafu-fiche iliyogatuliwa kwa kutumia zana za kimsingi za kriptografia. Leja hutunza rekodi ya shughuli ambayo lazima ifuate seti ya sheria zinazosimamia kile ambacho mtu anaweza na hawezi kufanya ili kurekebisha leja. Kwa mfano, anwani ya Bitcoin haiwezi kutumia Bitcoin nyingi zaidi ya ilivyopokea hapo awali. Sheria hizi ndizo msingi wa miamala yote kwenye Bitcoin na minyororo mingine mingi ya vitalu. Ingawa Ethereum ina sarafu-fiche yake asili (Etha) ambayo inafuata karibu sheria zilezile zinazoeleweka, pia inawezesha utendaji wenye nguvu zaidi: [mikataba mahiri](https://ethereum.org/sw/developers/docs/smart-contracts/) . Kwa kipengele hiki changamano zaidi, mfano wa hali ya juu zaidi unahitajika. Badala ya leja iliyosambazwa, Ethereum ni [mashine ya hali (inafunguka katika kichupo kipya)](https://wikipedia.org/wiki/Finite-state_machine) iliyosambazwa. Hali ya Ethereum ni muundo mkubwa wa data ambao haushikilii tu akaunti na salio zote, bali _hali ya mashine_, ambayo inaweza kubadilika kutoka kitalu hadi kitalu kulingana na seti ya sheria zilizobainishwa mapema, na ambayo inaweza kutekeleza msimbo wowote wa mashine. Sheria mahususi za kubadilisha hali kutoka kitalu hadi kitalu hufafanuliwa na EVM. [![A diagram showing the make up of the EVM](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fevm%2Fevm.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/evm/evm.png) _Mchoro umechukuliwa kutoka [Ethereum EVM illustrated (inafunguka katika kichupo kipya)](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) _ [](https://ethereum.org/sw/developers/docs/evm/#the-ethereum-state-transition-function) Fomula ya mpito wa hali ya Ethereum --------------------------------------------------------------------------------------------------------------------------- EVM hufanya kazi kama fomula ya hisabati inavyofanya: Ikipewa ingizo, hutoa tokeo thabiti. Kwa hivyo inasaidia sana kuelezea Ethereum rasmi zaidi kama yenye **fomula ya mpito wa hali**: Y(S, T)= S' Nakili Ikipewa hali halali ya zamani `(S)` na seti mpya ya miamala halali `(T)`, fomula ya mpito wa hali ya Ethereum `Y(S, T)` hutoa hali mpya halali ya tokeo `S'` ### [](https://ethereum.org/sw/developers/docs/evm/#state) Hali Katika muktadha wa Ethereum, hali ni muundo mkubwa wa data unaoitwa [Trie ya Merkle Patricia iliyorekebishwa](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) , ambayo huweka [akaunti](https://ethereum.org/sw/developers/docs/accounts/) zote zikiwa zimeunganishwa na heshi na zinazoweza kupunguzwa hadi kwenye heshi moja ya mzizi iliyohifadhiwa kwenye mnyororo wa vitalu. ### [](https://ethereum.org/sw/developers/docs/evm/#transactions) Miamala Miamala ni maagizo yaliyotiwa saini kwa njia ya kriptografia kutoka kwenye akaunti. Kuna aina mbili za miamala: ile inayosababisha miito ya ujumbe na ile inayosababisha uundaji wa mkataba. Uundaji wa mkataba husababisha kuundwa kwa akaunti mpya ya mkataba iliyo na msimbo wa baiti wa [mkataba mahiri](https://ethereum.org/sw/developers/docs/smart-contracts/anatomy/) uliokusanywa. Kila wakati akaunti nyingine inapofanya mwito wa ujumbe kwenye mkataba huo, hutekeleza msimbo wake wa baiti. [](https://ethereum.org/sw/developers/docs/evm/#evm-instructions) Maagizo ya EVM -------------------------------------------------------------------------------- EVM hutekelezwa kama [mashine ya staki (inafunguka katika kichupo kipya)](https://wikipedia.org/wiki/Stack_machine) yenye kina cha vipengee 1024. Kila kipengee ni neno la biti 256, ambalo lilichaguliwa kwa urahisi wa matumizi na kriptografia ya biti 256 (kama vile heshi za Keccak-256 au saini za secp256k1). Wakati wa utekelezaji, EVM hudumisha _kumbukumbu_ ya muda (kama safu ya baiti inayoelekezwa kwa neno), ambayo haidumu kati ya miamala. ### [](https://ethereum.org/sw/developers/docs/evm/#transient-storage) Hifadhi ya muda Hifadhi ya muda ni hifadhi ya ufunguo-thamani kwa kila muamala inayofikiwa kupitia misimbo ya operesheni ya `TSTORE` na `TLOAD`. Inadumu katika miito yote ya ndani wakati wa muamala huo huo lakini inafutwa mwishoni mwa muamala. Tofauti na kumbukumbu, hifadhi ya muda inaundwa kama sehemu ya hali ya EVM badala ya fremu ya utekelezaji, lakini haijatolewa kwa hali ya kimataifa. Hifadhi ya muda huwezesha ushiriki wa hali ya muda unaotumia gesi vizuri katika miito ya ndani wakati wa muamala. ### [](https://ethereum.org/sw/developers/docs/evm/#storage) Hifadhi Mikataba ina trie ya _hifadhi_ ya Merkle Patricia (kama safu ya maneno inayoelekezwa kwa neno), inayohusishwa na akaunti husika na sehemu ya hali ya kimataifa. Hifadhi hii ya kudumu inatofautiana na hifadhi ya muda, ambayo inapatikana tu kwa muda wa muamala mmoja na haifanyi sehemu ya trie ya hifadhi ya kudumu ya akaunti. ### [](https://ethereum.org/sw/developers/docs/evm/#opcodes) Misimbo ya operesheni Msimbo wa baiti wa mkataba mahiri uliokusanywa hutekelezwa kama idadi ya [misimbo ya operesheni](https://ethereum.org/sw/developers/docs/evm/opcodes/) ya EVM, ambayo hufanya operesheni za kawaida za staki kama vile `XOR`, `AND`, `ADD`, `SUB`, n.k. EVM pia hutekeleza idadi ya operesheni za staki mahususi kwa mnyororo wa vitalu, kama vile `ADDRESS`, `BALANCE`, `BLOCKHASH`, n.k. Seti ya msimbo wa operesheni pia inajumuisha `TSTORE` na `TLOAD`, ambayo hutoa ufikiaji wa hifadhi ya muda. [![A diagram showing where gas is needed for EVM operations](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fgas%2Fgas.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/gas/gas.png) _Michoro imechukuliwa kutoka [Ethereum EVM illustrated (inafunguka katika kichupo kipya)](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) _ [](https://ethereum.org/sw/developers/docs/evm/#evm-implementations) Utekelezaji wa EVM --------------------------------------------------------------------------------------- Utekelezaji wote wa EVM lazima ufuate vipimo vilivyoelezwa katika Waraka wa Manjano wa Ethereum. Katika historia ya miaka kumi ya Ethereum, EVM imepitia marekebisho kadhaa, na kuna utekelezaji kadhaa wa EVM katika lugha mbalimbali za programu. [Viteja vya utekelezaji wa Ethereum](https://ethereum.org/sw/developers/docs/nodes-and-clients/#execution-clients) vinajumuisha utekelezaji wa EVM. Zaidi ya hayo, kuna utekelezaji mwingi wa kujitegemea, ikiwa ni pamoja na: * [Py-EVM (inafunguka katika kichupo kipya)](https://github.com/ethereum/py-evm) - _Python_ * [evmone (inafunguka katika kichupo kipya)](https://github.com/ethereum/evmone) - _C++_ * [ethereumjs-vm (inafunguka katika kichupo kipya)](https://github.com/ethereumjs/ethereumjs-vm) - _JavaScript_ * [revm (inafunguka katika kichupo kipya)](https://github.com/bluealloy/revm) - _Rust_ [](https://ethereum.org/sw/developers/docs/evm/#further-reading) Usomaji Zaidi ------------------------------------------------------------------------------ * [Waraka wa Manjano wa Ethereum (inafunguka katika kichupo kipya)](https://ethereum.github.io/yellowpaper/paper.pdf) * [Jellopaper au KEVM: Semantiki za EVM katika K (inafunguka katika kichupo kipya)](https://jellopaper.org/) * [Waraka wa Beige (inafunguka katika kichupo kipya)](https://github.com/chronaeon/beigepaper) * [Misimbo ya Operesheni ya Mashine Pepe ya Ethereum (inafunguka katika kichupo kipya)](https://www.ethervm.io/) * [Rejeleo Shirikishi la Misimbo ya Operesheni ya Mashine Pepe ya Ethereum (inafunguka katika kichupo kipya)](https://www.evm.codes/) * [Utangulizi mfupi katika nyaraka za Solidity (inafunguka katika kichupo kipya)](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) * [Kujua Ethereum - Mashine Pepe ya Ethereum (inafunguka katika kichupo kipya)](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc) [](https://ethereum.org/sw/developers/docs/evm/#related-topics) Mada Zinazohusiana ---------------------------------------------------------------------------------- * [Gesi](https://ethereum.org/sw/developers/docs/gas/) [](https://ethereum.org/sw/developers/docs/evm/#tutorials) Mafunzo: Mashine Pepe ya Ethereum (EVM) / Misimbo ya Operesheni kwenye Ethereum ------------------------------------------------------------------------------------------------------------------------------------------ * [Kuelewa Vipimo vya EVM vya Waraka wa Manjano](https://ethereum.org/sw/developers/tutorials/yellow-paper-evm/) _– Mwongozo wa hatua kwa hatua wa vipimo rasmi vya EVM kutoka kwenye Waraka wa Manjano wa Ethereum._ * [Uhandisi wa Kinyume wa Mkataba](https://ethereum.org/sw/developers/tutorials/reverse-engineering-a-contract/) _– Jinsi ya kufanya uhandisi wa kinyume wa mkataba mahiri uliokusanywa kwa kutumia misimbo ya operesheni ya EVM._ Pima ujuzi wako wa Ethereum --------------------------- --- # ノードのアーキテクチャ | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/nodes-and-clients/node-architecture/#main-content) Change page ノードのアーキテクチャ =========== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/nodes-and-clients/node-architecture/index.md) このページの内容 イーサリアムのノードは、[実行クライアント](https://ethereum.org/ja/developers/docs/nodes-and-clients/#execution-clients) と[コンセンサス・クライアント](https://ethereum.org/ja/developers/docs/nodes-and-clients/#consensus-clients) の2つのクライアントで構成されています。ノードが新しいブロックを提案するには、[バリデータクライアント](https://ethereum.org/ja/developers/docs/nodes-and-clients/node-architecture/#validators) も実行する必要があります。 イーサリアムが[プルーフ・オブ・ワーク (PoW)](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/) を使用していたときは、完全なイーサリアムノードを実行するには実行クライアントだけで十分でした。しかし、[プルーフ・オブ・ステーク (PoS)](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/) を実装してからは、実行クライアントは[コンセンサス・クライアント](https://ethereum.org/ja/developers/docs/nodes-and-clients/#consensus-clients) と呼ばれる別のソフトウェアと一緒に使用する必要があります。 以下の図は、2つのイーサリアムクライアントの関係を示しています。2つのクライアントは、それぞれ独自のピア・ツー・ピア (P2P) ネットワークに接続します。実行クライアントはP2Pネットワーク上でトランザクションをゴシップしてローカルのトランザクション・プールを管理し、コンセンサス・クライアントはP2Pネットワーク上でブロックをゴシップしてコンセンサスとチェーンの成長を可能にするため、別々のP2Pネットワークが必要になります。 [![Diagram of Ethereum node architecture showing execution and consensus layers](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fnodes-and-clients%2Fnode-architecture%2Fnode-architecture-text-background.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/nodes-and-clients/node-architecture/node-architecture-text-background.png) _実行クライアントには、エリゴン、ネザーマインド、Besuなど、いくつかの選択肢があります_。 この2クライアント構造が機能するためには、コンセンサス・クライアントがトランザクションのバンドルを実行クライアントに渡す必要があります。実行クライアントはトランザクションをローカルで実行し、トランザクションがイーサリアムのルールに違反していないこと、および提案されたイーサリアムの状態の更新が正しいことを検証します。ノードがブロック生成者として選択されると、そのコンセンサス・クライアントのインスタンスは、新しいブロックに含めるトランザクションのバンドルを実行クライアントに要求し、それらを実行してグローバルな状態を更新します。コンセンサス・クライアントは、[Engine API （新しいタブで開きます）](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) を使用したローカルRPC接続を介して実行クライアントを駆動します。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/node-architecture/#execution-client) 実行クライアントの役割とは？ ---------------------------------------------------------------------------------------------------------------- 実行クライアントは、トランザクションの検証、処理、ゴシップ、および状態の管理とEthereum Virtual Machine ([EVM](https://ethereum.org/ja/developers/docs/evm/) ) のサポートを担当します。ブロックの構築、ブロックのゴシップ、またはコンセンサスロジックの処理は担当**しません**。これらはコンセンサス・クライアントの役割です。 実行クライアントは、トランザクションのリスト、更新されたステート・トライ、およびその他の実行関連データである実行ペイロードを作成します。コンセンサス・クライアントは、すべてのブロックに実行ペイロードを含めます。実行クライアントは、新しいブロック内のトランザクションを再実行して、それらが有効であることを確認する責任もあります。トランザクションの実行は、[Ethereum Virtual Machine (EVM)](https://ethereum.org/ja/developers/docs/evm/) として知られる、実行クライアントに組み込まれたコンピューター上で行われます。 実行クライアントはまた、ユーザーがイーサリアムのブロックチェーンを照会し、トランザクションを送信し、スマートコントラクトをデプロイできるようにする[RPCメソッド](https://ethereum.org/ja/developers/docs/apis/json-rpc/) を通じて、イーサリアムへのユーザーインターフェースを提供します。RPC呼び出しは、[Web3js （新しいタブで開きます）](https://docs.web3js.org/) や[Web3py （新しいタブで開きます）](https://web3py.readthedocs.io/en/v5/) などのライブラリ、またはブラウザウォレットなどのユーザーインターフェースによって処理されるのが一般的です。 要約すると、実行クライアントは以下の通りです。 * イーサリアムへのユーザーゲートウェイ * Ethereum Virtual Machine、イーサリアムの状態、およびトランザクション・プールのホーム [](https://ethereum.org/ja/developers/docs/nodes-and-clients/node-architecture/#consensus-client) コンセンサス・クライアントの役割とは？ --------------------------------------------------------------------------------------------------------------------- コンセンサス・クライアントは、ノードがイーサリアムネットワークと同期し続けることを可能にするすべてのロジックを処理します。これには、ピアからブロックを受信し、フォーク選択アルゴリズムを実行して、ノードが常に（バリデータの有効残高で重み付けされた）アテステーションの蓄積が最も多いチェーンに従うようにすることが含まれます。実行クライアントと同様に、コンセンサス・クライアントは独自のP2Pネットワークを持ち、それを通じてブロックとアテステーションを共有します。 コンセンサス・クライアントは、ブロックのアテステーションや提案には参加しません。これは、コンセンサス・クライアントのオプションのアドオンであるバリデータによって行われます。バリデータを持たないコンセンサス・クライアントは、チェーンの先頭に追従するだけであり、ノードが同期された状態を維持できるようにします。これにより、ユーザーは正しいチェーン上にいると確信して、実行クライアントを使用してイーサリアムとトランザクションを行うことができます。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/node-architecture/#validators) バリデータ ------------------------------------------------------------------------------------------------- ステーキングを行い、バリデータソフトウェアを実行することで、ノードは新しいブロックを提案するために選択される資格を得ます。ノードオペレーターは、デポジット・コントラクトに32 ETHをステークすることで、コンセンサス・クライアントにバリデータを追加できます。バリデータクライアントはコンセンサス・クライアントにバンドルされており、いつでもノードに追加できます。バリデータはアテステーションとブロックの提案を処理します。また、ノードが報酬を蓄積したり、ペナルティやスラッシングによってETHを失ったりすることも可能にします。 [ステーキングの詳細](https://ethereum.org/ja/staking/) 。 [](https://ethereum.org/ja/developers/docs/nodes-and-clients/node-architecture/#node-comparison) ノードのコンポーネントの比較 --------------------------------------------------------------------------------------------------------------- | 実行クライアント | コンセンサス・クライアント | バリデータ | | --- | --- | --- | | P2Pネットワーク上でトランザクションをゴシップする | P2Pネットワーク上でブロックとアテステーションをゴシップする | ブロックを提案する | | トランザクションを実行/再実行する | フォーク選択アルゴリズムを実行する | 報酬/ペナルティを蓄積する | | 受信した状態の変更を検証する | チェーンの先頭を追跡する | アテステーションを行う | | 状態とレシートのトライを管理する | ビーコンの状態（コンセンサスと実行の情報を含む）を管理する | 32 ETHのステーキングが必要 | | 実行ペイロードを作成する | RANDAO（バリデータの選択やその他のコンセンサス操作に検証可能なランダム性を提供するアルゴリズム）に蓄積されたランダム性を追跡する | スラッシングされる可能性がある | | イーサリアムと対話するためのJSON-RPC APIを公開する | 正当化 (justification) とファイナライゼーションを追跡する | | [](https://ethereum.org/ja/developers/docs/nodes-and-clients/node-architecture/#further-reading) 参考文献 ----------------------------------------------------------------------------------------------------- * [プルーフ・オブ・ステーク (PoS)](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/) * [ブロックの提案](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/block-proposal/) * [バリデータの報酬とペナルティ](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) --- # スマート・コントラクトの命名 | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#main-content) Change page スマート・コントラクトの命名 ============== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/naming/index.md) このページの内容 スマート・コントラクトはイーサリアムの分散型インフラストラクチャの基盤であり、自律的なアプリケーションやプロトコルを可能にします。しかし、コントラクトの機能が進化しても、ユーザーや開発者は依然として、これらのコントラクトを識別して参照するために生の16進数のアドレスに依存しています。 [Ethereum Name Service (ENS) （新しいタブで開きます）](https://ens.domains/) を使用してスマート・コントラクトに名前を付けることで、16進数のコントラクトアドレスを排除してユーザーエクスペリエンスを向上させ、アドレスポイズニングやスプーフィング攻撃などのリスクを軽減します。このガイドでは、スマート・コントラクトの命名が重要である理由、その実装方法、そしてプロセスを簡素化して開発者がこのプラクティスを採用するのに役立つ[Enscribe （新しいタブで開きます）](https://www.enscribe.xyz/) などの利用可能なツールについて説明します。 [](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#why-name-contracts) なぜスマート・コントラクトに名前を付けるのか？ -------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#human-readable-identifiers) 人間が読める識別子 `0x8f8e...f9e3`のような不透明なコントラクトアドレスとやり取りする代わりに、開発者やユーザーは`v2.myapp.eth`のような人間が読める名前を使用できます。これにより、スマート・コントラクトとのやり取りが簡素化されます。 これは、イーサリアムアドレスに分散型ネーミングサービスを提供する[Ethereum Name Service （新しいタブで開きます）](https://ens.domains/) によって可能になります。これは、ドメインネームシステム (DNS) が、インターネットユーザーに対して`104.18.176.152`のようなIPアドレス経由ではなく、ethereum.orgのような名前を使用してネットワークアドレスにアクセスできるようにする仕組みと似ています。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#improved-security-and-trust) セキュリティと信頼性の向上 名前付きのコントラクトは、間違ったアドレスへの偶発的なトランザクションを減らすのに役立ちます。また、ユーザーが特定のアプリやブランドに結びついたコントラクトを識別するのにも役立ちます。これにより、特に`uniswap.eth`のようなよく知られた親ドメインに名前が付けられている場合、評判による信頼の層が追加されます。 イーサリアムのアドレスは42文字の長さがあるため、数文字が変更されたようなアドレスの小さな変化をユーザーが識別するのは非常に困難です。たとえば、`0x58068646C148E313CB414E85d2Fe89dDc3426870`のようなアドレスは、通常、ウォレットなどのユーザー向けアプリケーションによって`0x580...870`に切り詰められます。ユーザーは、数文字が変更された悪意のあるアドレスに気付く可能性は低いです。 この種の手法は、アドレススプーフィングやポイズニング攻撃で採用されており、ユーザーは正しいアドレスとやり取りしている、または資金を送っていると信じ込まされますが、実際にはそのアドレスは正しいアドレスに似ているだけで、同じものではありません。 ウォレットやコントラクトのENS名は、これらの種類の攻撃から保護します。DNSスプーフィング攻撃と同様に、ENSスプーフィング攻撃も潜む可能性がありますが、ユーザーは16進数のアドレスの小さな変更よりも、ENS名のスペルミスに気付く可能性が高くなります。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#better-ux) ウォレットとエクスプローラーのUX向上 スマート・コントラクトにENS名が設定されている場合、ウォレットやブロックチェーンエクスプローラーなどのアプリは、16進数のアドレスの代わりにスマート・コントラクトのENS名を表示できます。これにより、ユーザーのユーザーエクスペリエンス (UX) が大幅に向上します。 たとえば、ユニスワップなどのアプリとやり取りする場合、ユーザーは通常、やり取りしているアプリが`uniswap.org`というウェブサイトでホストされていることを確認しますが、ユニスワップがスマート・コントラクトにENSで名前を付けていない場合、16進数のコントラクトアドレスが提示されます。コントラクトに名前が付けられている場合、代わりに`v4.contracts.uniswap.eth`と表示され、はるかに便利です。 [](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#when-to-name) デプロイ時の命名とデプロイ後の命名 -------------------------------------------------------------------------------------------------- スマート・コントラクトに名前を付けるタイミングは2つあります。 * **デプロイ時**: デプロイされる際にコントラクトにENS名を割り当てる。 * **デプロイ後**: 既存のコントラクトアドレスを新しいENS名にマッピングする。 どちらのアプローチも、ENSレコードを作成および設定できるように、ENSドメインの所有者または管理者アクセス権を持っていることに依存しています。 [](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#how-ens-naming-works) コントラクトのENS命名の仕組み --------------------------------------------------------------------------------------------------------- ENS名はオンチェーンに保存され、ENSリゾルバを介してイーサリアムアドレスに解決されます。スマート・コントラクトに名前を付けるには： 1. 親ENSドメイン（例：`myapp.eth`）を登録または管理する 2. サブドメイン（例：`v1.myapp.eth`）を作成する 3. サブドメインの`address`レコードをコントラクトアドレスに設定する 4. アドレスから名前を見つけられるように、コントラクトのリバースレコードをENSに設定する ENS名は階層的であり、無制限のサブネームをサポートしています。これらのレコードの設定には、通常、ENSレジストリおよびパブリックリゾルバのコントラクトとのやり取りが含まれます。 [](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#tools) コントラクト命名のためのツール ----------------------------------------------------------------------------------------- スマート・コントラクトに名前を付けるには2つのアプローチがあります。手動の手順を伴う[ENS App （新しいタブで開きます）](https://app.ens.domains/) を使用するか、[Enscribe （新しいタブで開きます）](https://www.enscribe.xyz/) を使用するかのいずれかです。これらの概要を以下に示します。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#manual-ens-setup) 手動でのENS設定 [ENS App （新しいタブで開きます）](https://app.ens.domains/) を使用すると、開発者は手動でサブネームを作成し、フォワードアドレスレコードを設定できます。ただし、ENSアプリを介して名前のリバースレコードを設定することで、スマート・コントラクトのプライマリ名を設定することはできません。[ENSドキュメント （新しいタブで開きます）](https://docs.ens.domains/web/naming-contracts/) で説明されている手動の手順を実行する必要があります。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#enscribe) Enscribe [Enscribe （新しいタブで開きます）](https://www.enscribe.xyz/) は、ENSを使用したスマート・コントラクトの命名を簡素化し、スマート・コントラクトに対するユーザーの信頼を高めます。以下の機能を提供します： * **アトミックなデプロイと命名**: 新しいコントラクトをデプロイする際にENS名を割り当てる * **デプロイ後の命名**: すでにデプロイされたコントラクトに名前を付ける * **マルチチェーンサポート**: ENSがサポートされているイーサリアムおよびレイヤー2 (L2) ネットワーク全体で機能する * **コントラクト検証データ**: ユーザーの信頼を高めるために、複数のソースから取得したコントラクト検証データを含める Enscribeは、ユーザーが提供するENS名、またはユーザーがENS名を持っていない場合は独自のドメインをサポートします。 [Enscribe App （新しいタブで開きます）](https://app.enscribe.xyz/) にアクセスして、スマート・コントラクトの命名と表示を開始できます。 [](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#best-practices) ベストプラクティス -------------------------------------------------------------------------------------------- * コントラクトのアップグレードを透明にするために、`v1.myapp.eth`のような**明確でバージョン管理された名前を使用する** * ウォレットやブロックチェーンエクスプローラーなどのアプリでの可視性を高めるために、コントラクトをENS名にリンクする**リバースレコードを設定する** * 所有権の偶発的な変更を防ぎたい場合は、**有効期限を注意深く監視する** * ユーザーが名前付きのコントラクトが期待通りに動作すると信頼できるように、**コントラクトのソースを検証する** [](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#risks) リスク ----------------------------------------------------------------------------- スマート・コントラクトに名前を付けることは、イーサリアムのユーザーに大きなメリットをもたらしますが、ENSドメインの所有者はその管理に関して警戒を怠ってはなりません。主なリスクは以下の通りです： * **有効期限**: DNS名と同様に、ENS名の登録期間は有限です。したがって、所有者がドメインの有効期限を監視し、有効期限が切れる前に余裕を持って更新することが不可欠です。ENS AppとEnscribeの両方が、有効期限が近づいたときにドメイン所有者に視覚的なインジケーターを提供します。 * **所有権の変更**: ENSレコードはイーサリアム上のNFTとして表され、特定の`.eth`ドメインの所有者は関連するNFTを所有しています。したがって、別のアカウントがこのNFTの所有権を取得した場合、新しい所有者は任意のENSレコードを自由に変更できます。 このようなリスクを軽減するために、`.eth`の第2レベルドメイン (2LD) の所有者アカウントは、マルチシグウォレットを介して保護し、コントラクトの命名を管理するためのサブドメインを作成する必要があります。そうすることで、サブドメインレベルで偶発的または悪意のある所有権の変更が発生した場合でも、2LDの所有者がそれらを上書きできます。 [](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#future) コントラクト命名の未来 -------------------------------------------------------------------------------------- ウェブ上でドメイン名がIPアドレスに取って代わったのと同様に、コントラクトの命名は分散型アプリケーション (dapp) 開発のベストプラクティスになりつつあります。ウォレット、エクスプローラー、ダッシュボードなどのより多くのインフラストラクチャがコントラクトのENS解決を統合するにつれて、名前付きのコントラクトはエコシステム全体の安全性を向上させ、エラーを減らすでしょう。 スマート・コントラクトを認識しやすく、理解しやすくすることで、命名はイーサリアム上のユーザーとアプリの間のギャップを埋めるのに役立ち、ユーザーの安全性とUXの両方を向上させます。 [](https://ethereum.org/ja/developers/docs/smart-contracts/naming/#further-reading) 参考文献 ---------------------------------------------------------------------------------------- * [ENSを使用したスマート・コントラクトの命名 （新しいタブで開きます）](https://docs.ens.domains/web/naming-contracts/) * [Enscribeを使用したスマート・コントラクトの命名 （新しいタブで開きます）](https://www.enscribe.xyz/docs) --- # Java開発者向けのイーサリアム | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/programming-languages/java/#main-content) Change page Java開発者向けのイーサリアム ================ .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/java/index.md) このページの内容 Javaベースのプロジェクトやツールを使用してイーサリアム向けに開発する方法を学びます イーサリアムを使用して、暗号資産とブロックチェーン技術の利点を活用した分散型アプリケーション (dapp) を作成します。これらのdappは信頼性が高く、一度イーサリアムにデプロイされると、常にプログラムされた通りに実行されます。デジタル資産を制御して、新しい種類の金融アプリケーションを作成できます。また、分散型であるため、単一の組織や個人が制御することはなく、検閲することはほぼ不可能です。 [](https://ethereum.org/ja/developers/docs/programming-languages/java/#getting-started-with-smart-contracts-and-solidity) スマート・コントラクトとSolidity言語の基礎 --------------------------------------------------------------------------------------------------------------------------------------------------- **Javaとイーサリアムを統合するための第一歩を踏み出しましょう** まずはより基本的な入門書が必要ですか？ [ethereum.org/learn](https://ethereum.org/ja/learn/) または [ethereum.org/developers](https://ethereum.org/ja/developers/) を確認してください。 * [ブロックチェーンの解説 （新しいタブで開きます）](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [スマート・コントラクトの理解 （新しいタブで開きます）](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [初めてのスマート・コントラクトを作成する （新しいタブで開きます）](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Solidityのコンパイルとデプロイ方法を学ぶ （新しいタブで開きます）](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) [](https://ethereum.org/ja/developers/docs/programming-languages/java/#working-with-ethereum-clients) イーサリアムクライアントの操作 --------------------------------------------------------------------------------------------------------------------- 2つの主要なJavaイーサリアムクライアントである[Web3j （新しいタブで開きます）](https://github.com/web3j/web3j) とHyperledger ベスの使用方法を学びます * [Java、Eclipse、Web3jを使用してイーサリアムクライアントに接続する （新しいタブで開きます）](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j) * [JavaとWeb3jでイーサリアムアカウントを管理する （新しいタブで開きます）](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j) * [スマート・コントラクトからJavaラッパーを生成する （新しいタブで開きます）](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract) * [イーサリアムのスマート・コントラクトと対話する （新しいタブで開きます）](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java) * [イーサリアムのスマート・コントラクトのイベントをリッスンする （新しいタブで開きます）](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java) * [LinuxでJavaイーサリアムクライアントのベス (Pantheon) を使用する （新しいタブで開きます）](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux) * [Java統合テストでHyperledger ベス (Pantheon) ノードを実行する （新しいタブで開きます）](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests) * [Web3jチートシート （新しいタブで開きます）](https://kauri.io/web3j-cheat-sheet-(java-ethereum)/5dfa1ea941ac3d0001ce1d90/c) EVMベースのブロックチェーンと対話するための非同期で高性能なKotlinライブラリである[ethers-kt （新しいタブで開きます）](https://github.com/Kr1ptal/ethers-kt) の使用方法を学びます。JVMおよびAndroidプラットフォームを対象としています。 * [ERC-20トークンの送金 （新しいタブで開きます）](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt) * [イベントリスニングを伴うUniswapV2のスワップ （新しいタブで開きます）](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt) * [ETH / ERC-20残高トラッカー （新しいタブで開きます）](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt) [](https://ethereum.org/ja/developers/docs/programming-languages/java/#intermediate-articles) 中級者向けの記事 ------------------------------------------------------------------------------------------------------ * [IPFSを使用したJavaアプリケーションでのストレージ管理 （新しいタブで開きます）](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs) * [Web3jを使用したJavaでのERC-20トークン管理 （新しいタブで開きます）](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j) * [Web3jトランザクションマネージャー （新しいタブで開きます）](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers) [](https://ethereum.org/ja/developers/docs/programming-languages/java/#advanced-use-patterns) 高度な使用パターン ------------------------------------------------------------------------------------------------------- * [Eventeumを使用したJavaスマート・コントラクトのデータキャッシュの構築 （新しいタブで開きます）](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache) [](https://ethereum.org/ja/developers/docs/programming-languages/java/#java-projects-and-tools) Javaのプロジェクトとツール --------------------------------------------------------------------------------------------------------------- * [Web3j (イーサリアムクライアントと対話するためのライブラリ) （新しいタブで開きます）](https://github.com/web3j/web3j) * [ethers-kt (EVMベースのブロックチェーン向けの非同期で高性能なKotlin/Java/Androidライブラリ) （新しいタブで開きます）](https://github.com/Kr1ptal/ethers-kt) * [Eventeum (イベントリスナー) （新しいタブで開きます）](https://github.com/ConsenSys/eventeum) * [Mahuta (IPFS開発ツール) （新しいタブで開きます）](https://github.com/ConsenSys/mahuta) さらにリソースをお探しですか？ [ethereum.org/developers](https://ethereum.org/ja/developers/) を確認してください。 [](https://ethereum.org/ja/developers/docs/programming-languages/java/#java-community-contributors) Javaコミュニティの貢献者 ------------------------------------------------------------------------------------------------------------------ * [IO Builders （新しいタブで開きます）](https://io.builders/) * [Kauri （新しいタブで開きます）](https://kauri.io/) --- # Uongezaji wa Uwezo | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/scaling/#main-content) Change page Uongezaji wa Uwezo ================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/scaling/index.md) Kwenye ukurasa huu [](https://ethereum.org/sw/developers/docs/scaling/#scaling-overview) Muhtasari wa uongezaji wa uwezo ----------------------------------------------------------------------------------------------------- Kadiri idadi ya watu wanaotumia [Ethereum](https://ethereum.org/sw/) inavyoongezeka, mnyororo wa vitalu umefikia vikwazo fulani vya uwezo. Hii imepandisha gharama ya kutumia mtandao, na kujenga hitaji la "suluhisho za uongezaji wa uwezo." Kuna suluhisho nyingi zinazofanyiwa utafiti, kujaribiwa na kutekelezwa ambazo zinachukua mbinu tofauti kufikia malengo yanayofanana. Lengo kuu la uwezo wa kuongezeka ni kuongeza kasi ya muamala (ukamilifu wa haraka zaidi) na uwezo wa upitishaji wa muamala (idadi kubwa ya miamala kwa sekunde) bila kuathiri ugatuzi au usalama. Kwenye mnyororo wa vitalu wa tabaka la 1 (l1) la Ethereum, mahitaji makubwa husababisha miamala ya polepole na [bei za gesi](https://ethereum.org/sw/developers/docs/gas/) zisizowezekana. Kuongeza uwezo wa mtandao kwa upande wa kasi na uwezo wa upitishaji ni msingi kwa upitishaji wa maana na wa umati wa Ethereum. Ingawa kasi na uwezo wa upitishaji ni muhimu, ni muhimu kwamba suluhisho za uongezaji wa uwezo zinazowezesha malengo haya zibaki zimegatuliwa na salama. Kuweka kizuizi cha kuingia chini kwa waendeshaji wa nodi ni muhimu katika kuzuia maendeleo kuelekea nguvu ya kompyuta iliyowekwa kati na isiyo salama. Kimawazo kwanza tunaainisha uongezaji wa uwezo kama uongezaji wa uwezo mnyororoni au uongezaji wa uwezo nje ya mnyororo. [](https://ethereum.org/sw/developers/docs/scaling/#prerequisites) Mahitaji ya awali ------------------------------------------------------------------------------------ Unapaswa kuwa na uelewa mzuri wa mada zote za msingi. Kutekeleza suluhisho za uongezaji wa uwezo ni kwa hali ya juu kwani teknolojia haijajaribiwa sana, na inaendelea kufanyiwa utafiti na kuendelezwa. [](https://ethereum.org/sw/developers/docs/scaling/#onchain-scaling) Uongezaji wa uwezo mnyororoni -------------------------------------------------------------------------------------------------- Uongezaji wa uwezo mnyororoni unahitaji mabadiliko kwenye itifaki ya Ethereum ( wa tabaka la 1). Kwa muda mrefu, kugawanya mnyororo wa vitalu (sharding) kulitarajiwa kuongeza uwezo wa Ethereum. Hii ilikuwa inahusisha kugawanya mnyororo wa vitalu katika vipande tofauti (shadi) ili kuthibitishwa na vikundi vidogo vya wathibitishaji. Hata hivyo, uongezaji wa uwezo kwa mikusanyiko ya tabaka la 2 (l2) umechukua nafasi kama mbinu kuu ya uongezaji wa uwezo. Hili linaungwa mkono na kuongezwa kwa aina mpya ya data ya bei nafuu iliyoambatishwa kwenye vitalu vya Ethereum ambayo imeundwa maalum kufanya mikusanyiko iwe nafuu kwa watumiaji. ### [](https://ethereum.org/sw/developers/docs/scaling/#sharding) Sharding Sharding ni mchakato wa kugawanya hifadhidata. Vikundi vidogo vya wathibitishaji vingehusika na shadi binafsi badala ya kufuatilia Ethereum yote. Sharding ilikuwa kwenye [ramani ya njia](https://ethereum.org/sw/roadmap/) ya Ethereum kwa muda mrefu, na iliwahi kukusudiwa kutolewa kabla ya Unganisho kwenda kwenye Uthibitisho wa Dau (PoS). Hata hivyo, maendeleo ya haraka ya [mikusanyiko ya tabaka la 2](https://ethereum.org/sw/developers/docs/scaling/#layer-2-scaling) na uvumbuzi wa [danksharding](https://ethereum.org/sw/roadmap/danksharding/) (kuongeza blobs za data za rollup kwenye vitalu vya Ethereum ambazo zinaweza kuthibitishwa kwa ufanisi sana na wathibitishaji) kumesababisha jamii ya Ethereum kupendelea uongezaji wa uwezo unaozingatia rollup badala ya uongezaji wa uwezo kwa sharding. Hii pia itasaidia kuweka mantiki ya mwafaka ya Ethereum kuwa rahisi zaidi. [](https://ethereum.org/sw/developers/docs/scaling/#offchain-scaling) Uongezaji wa uwezo nje ya mnyororo -------------------------------------------------------------------------------------------------------- Suluhisho za nje ya mnyororo zinatekelezwa kando na Mtandao Mkuu wa tabaka la 1 - hazihitaji mabadiliko yoyote kwenye itifaki iliyopo ya Ethereum. Baadhi ya suluhisho, zinazojulikana kama suluhisho za "tabaka la 2", hupata usalama wao moja kwa moja kutoka kwa mwafaka wa Ethereum wa tabaka la 1, kama vile [mikusanyiko yenye matumaini (optimistic rollups)](https://ethereum.org/sw/developers/docs/scaling/optimistic-rollups/) , [mikusanyiko ya sifuri-maarifa](https://ethereum.org/sw/developers/docs/scaling/zk-rollups/) au [chaneli za hali](https://ethereum.org/sw/developers/docs/scaling/state-channels/) . Suluhisho zingine zinahusisha uundaji wa minyororo mipya katika aina mbalimbali ambayo hupata usalama wao kando na Mtandao Mkuu, kama vile [minyororo ya kando](https://ethereum.org/sw/developers/docs/scaling/#sidechains) , [Validium](https://ethereum.org/sw/developers/docs/scaling/#validium) , au [minyororo ya Plasma](https://ethereum.org/sw/developers/docs/scaling/#plasma) . Suluhisho hizi huwasiliana na Mtandao Mkuu lakini hupata usalama wao kwa njia tofauti ili kufikia malengo mbalimbali. ### [](https://ethereum.org/sw/developers/docs/scaling/#layer-2-scaling) Uongezaji wa uwezo wa tabaka la 2 Kategoria hii ya suluhisho za nje ya mnyororo hupata usalama wake kutoka kwa Mtandao Mkuu wa Ethereum. Tabaka la 2 ni neno la pamoja kwa suluhisho zilizoundwa kusaidia kuongeza uwezo wa programu yako kwa kushughulikia miamala nje ya Mtandao Mkuu wa Ethereum (tabaka la 1) huku ikitumia faida ya muundo thabiti wa usalama uliogatuliwa wa Mtandao Mkuu. Kasi ya muamala huathirika wakati mtandao una shughuli nyingi, na kufanya uzoefu wa mtumiaji kuwa mbaya kwa aina fulani za programu tumizi zilizogatuliwa (dapp). Na kadiri mtandao unavyozidi kuwa na shughuli nyingi, bei za gesi huongezeka kwani watumaji wa miamala wanalenga kushindana kwa bei. Hii inaweza kufanya matumizi ya Ethereum kuwa ghali sana. Suluhisho nyingi za tabaka la 2 zinajikita kwenye seva au kikundi cha seva, ambazo kila moja inaweza kuitwa nodi, mthibitishaji, mwendeshaji, mpangaji, mzalishaji wa kitalu, au neno linalofanana. Kulingana na utekelezaji, nodi hizi za tabaka la 2 zinaweza kuendeshwa na watu binafsi, biashara au taasisi zinazozitumia, au na mwendeshaji wa tatu, au na kundi kubwa la watu binafsi (sawa na Mtandao Mkuu). Kwa ujumla, miamala huwasilishwa kwa nodi hizi za tabaka la 2 badala ya kuwasilishwa moja kwa moja kwenye tabaka la 1 (Mtandao Mkuu). Kwa baadhi ya suluhisho, mfumo wa tabaka la 2 kisha huzikusanya katika makundi kabla ya kuziweka kwenye tabaka la 1, baada ya hapo zinalindwa na tabaka la 1 na haziwezi kubadilishwa. Maelezo ya jinsi hii inafanywa yanatofautiana sana kati ya teknolojia na utekelezaji tofauti wa tabaka la 2. Mfumo maalum wa tabaka la 2 unaweza kuwa wazi na kushirikiwa na programu nyingi, au unaweza kusambazwa na mradi mmoja na kujitolea kusaidia programu yao pekee. #### [](https://ethereum.org/sw/developers/docs/scaling/#why-is-layer-2-needed) Kwa nini tabaka la 2 linahitajika? * Kuongezeka kwa miamala kwa sekunde kunaboresha sana uzoefu wa mtumiaji, na kupunguza msongamano wa mtandao kwenye Mtandao Mkuu wa Ethereum. * Miamala inakusanywa kuwa muamala mmoja kwenye Mtandao Mkuu wa Ethereum, kupunguza ada za gesi kwa watumiaji na kufanya Ethereum iwe jumuishi zaidi na kufikiwa na watu kila mahali. * Masasisho yoyote ya uwezo wa kuongezeka hayapaswi kuwa kwa gharama ya ugatuzi au usalama – tabaka la 2 linajengwa juu ya Ethereum. * Kuna mitandao ya tabaka la 2 maalum kwa programu ambayo huleta seti yao wenyewe ya ufanisi wakati wa kufanya kazi na rasilimali kwa kiwango kikubwa. [Zaidi kuhusu tabaka la 2](https://ethereum.org/sw/layer-2/) . #### [](https://ethereum.org/sw/developers/docs/scaling/#rollups) Mikusanyiko Mikusanyiko hufanya utekelezaji wa muamala nje ya tabaka la 1 na kisha data inatumwa kwenye tabaka la 1 ambapo mwafaka unafikiwa. Kwa kuwa data ya muamala inajumuishwa kwenye vitalu vya tabaka la 1, hii inaruhusu mikusanyiko kulindwa na usalama wa asili wa Ethereum. Kuna aina mbili za mikusanyiko yenye miundo tofauti ya usalama: * **Mikusanyiko yenye matumaini (Optimistic rollups)**: huchukulia miamala kuwa halali kwa chaguo-msingi na huendesha tu ukokotoaji, kupitia , endapo kutatokea changamoto. [Zaidi kuhusu mikusanyiko yenye matumaini](https://ethereum.org/sw/developers/docs/scaling/optimistic-rollups/) . * **Mikusanyiko ya sifuri-maarifa**: huendesha ukokotoaji nje ya mnyororo na kuwasilisha kwenye mnyororo. [Zaidi kuhusu mikusanyiko ya sifuri-maarifa](https://ethereum.org/sw/developers/docs/scaling/zk-rollups/) . #### [](https://ethereum.org/sw/developers/docs/scaling/#channels) Chaneli za hali Chaneli za hali hutumia mikataba ya saini-nyingi kuwezesha washiriki kufanya miamala haraka na kwa uhuru nje ya mnyororo, kisha kutatua ukamilifu na Mtandao Mkuu. Hii inapunguza msongamano wa mtandao, ada, na ucheleweshaji. Aina mbili za chaneli kwa sasa ni chaneli za hali na chaneli za malipo. Jifunze zaidi kuhusu [chaneli za hali](https://ethereum.org/sw/developers/docs/scaling/state-channels/) . ### [](https://ethereum.org/sw/developers/docs/scaling/#sidechains) Minyororo ya kando Mnyororo wa kando ni mnyororo wa vitalu unaojitegemea unaoendana na EVM ambao unafanya kazi sambamba na Mtandao Mkuu. Hizi zinaendana na Ethereum kupitia madaraja ya njia mbili na zinafanya kazi chini ya sheria zao zilizochaguliwa za mwafaka na vigezo vya kitalu. Jifunze zaidi kuhusu [Minyororo ya kando](https://ethereum.org/sw/developers/docs/scaling/sidechains/) . ### [](https://ethereum.org/sw/developers/docs/scaling/#plasma) Plasma Mnyororo wa Plasma ni mnyororo wa vitalu tofauti ambao umewekwa kwenye mnyororo mkuu wa Ethereum na hutumia ushahidi wa udanganyifu (kama [mikusanyiko yenye matumaini](https://ethereum.org/sw/developers/docs/scaling/optimistic-rollups/) ) kusuluhisha mizozo. Jifunze zaidi kuhusu [Plasma](https://ethereum.org/sw/developers/docs/scaling/plasma/) . ### [](https://ethereum.org/sw/developers/docs/scaling/#validium) Validium Mnyororo wa Validium hutumia uthibitisho wa uhalali kama mikusanyiko ya sifuri-maarifa lakini data haihifadhiwi kwenye mnyororo mkuu wa Ethereum wa tabaka la 1. Hii inaweza kusababisha miamala 10k kwa sekunde kwa kila mnyororo wa Validium na minyororo mingi inaweza kuendeshwa sambamba. Jifunze zaidi kuhusu [Validium](https://ethereum.org/sw/developers/docs/scaling/validium/) . [](https://ethereum.org/sw/developers/docs/scaling/#why-do-we-need-these) Kwa nini suluhisho nyingi za uongezaji wa uwezo zinahitajika? --------------------------------------------------------------------------------------------------------------------------------------- * Suluhisho nyingi zinaweza kusaidia kupunguza msongamano wa jumla kwenye sehemu yoyote ya mtandao na pia kuzuia sehemu moja ya kutofaulu. * Kwa pamoja ni zaidi ya jumla ya sehemu zake. Suluhisho tofauti zinaweza kuwepo na kufanya kazi kwa upatano, kuruhusu athari kubwa kwenye kasi ya muamala ya baadaye na uwezo wa upitishaji. * Sio suluhisho zote zinahitaji kutumia algoriti ya mwafaka ya Ethereum moja kwa moja, na njia mbadala zinaweza kutoa faida ambazo vinginevyo zingekuwa ngumu kupata. [](https://ethereum.org/sw/developers/docs/scaling/#visual-learner) Je, unapendelea kujifunza kwa kuona? -------------------------------------------------------------------------------------------------------- ### Ethereum layer 2 scaling explained An overview of layer 2 scaling solutions for Ethereum, including rollups, Plasma, state channels, and sidechains. [Tazama na nakala](https://ethereum.org/sw/videos/layer-2-scaling-explained/)   _Kumbuka maelezo kwenye video yanatumia neno "Tabaka la 2" kurejelea suluhisho zote za uongezaji wa uwezo nje ya mnyororo, wakati sisi tunatofautisha "Tabaka la 2" kama suluhisho la nje ya mnyororo ambalo hupata usalama wake kupitia mwafaka wa Mtandao Mkuu wa tabaka la 1._ ### Rollups: the ultimate Ethereum scaling strategy? A deep dive into rollups as Ethereum's primary scaling strategy. [Tazama na nakala](https://ethereum.org/sw/videos/rollups-scaling-strategy/)   [](https://ethereum.org/sw/developers/docs/scaling/#further-reading) Usomaji zaidi ---------------------------------------------------------------------------------- * [Ramani ya njia ya Ethereum inayozingatia rollup (inafunguka katika kichupo kipya)](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _Vitalik Buterin_ * [Uchanganuzi wa kisasa kuhusu suluhisho za uongezaji wa uwezo wa Tabaka la 2 kwa Ethereum (inafunguka katika kichupo kipya)](https://www.l2beat.com/) * [Kutathmini Suluhisho za Uongezaji wa Uwezo wa tabaka la 2 la Ethereum: Mfumo wa Ulinganisho (inafunguka katika kichupo kipya)](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) * [Mwongozo Usiokamilika wa Mikusanyiko (inafunguka katika kichupo kipya)](https://vitalik.eth.limo/general/2021/01/05/rollup.html) * [Mikusanyiko ya ZK Inayoendeshwa na Ethereum: Washindi wa Dunia (inafunguka katika kichupo kipya)](https://hackmd.io/@canti/rkUT0BD8K) * [Mikusanyiko Yenye Matumaini dhidi ya Mikusanyiko ya ZK (inafunguka katika kichupo kipya)](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/) * [Kwa nini mikusanyiko + shadi za data ndio suluhisho pekee endelevu kwa uwezo wa juu wa kuongezeka (inafunguka katika kichupo kipya)](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48) * [Ni aina gani ya Tabaka la 3 inaleta maana? (inafunguka katika kichupo kipya)](https://vitalik.eth.limo/general/2022/09/17/layer_3.html) * [Upatikanaji wa Data Au: Jinsi Mikusanyiko Ilivyojifunza Kuacha Kuwa na Wasiwasi na Kuipenda Ethereum (inafunguka katika kichupo kipya)](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) * [Mwongozo wa Vitendo wa Mikusanyiko ya Ethereum (inafunguka katika kichupo kipya)](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) _Je, unajua rasilimali ya jamii iliyokusaidia? Hariri ukurasa huu na uiongeze!_ [](https://ethereum.org/sw/developers/docs/scaling/#tutorials) Mafunzo: Jenga Tabaka la 2 lenye uwezo wa kuongezeka kwenye Ethereum ----------------------------------------------------------------------------------------------------------------------------------- * [Yote unayoweza kuhifadhi kwenye kache](https://ethereum.org/sw/developers/tutorials/all-you-can-cache/) _– Jinsi ya kujenga na kutumia mkataba wa kuhifadhi kwenye kache ili kupunguza gharama za data za mwito kwenye mikusanyiko._ * [ABI Fupi kwa Uboreshaji wa Data za Mwito](https://ethereum.org/sw/developers/tutorials/short-abi/) _– Jinsi ya kutumia ABI fupi zaidi kupunguza gharama za data za mwito kwa miamala ya tabaka la 2._ --- # Ufafanuzi wa hifadhi ya siri ya Web3 | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/web3-secret-storage/#main-content) Change page Ufafanuzi wa hifadhi ya siri ya Web3 ==================================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md) Kwenye ukurasa huu Ili kufanya programu yako ifanye kazi kwenye Ethereum, unaweza kutumia kipengee cha web3 kinachotolewa na maktaba ya web3.js. Kiufundi, inawasiliana na nodi ya ndani kupitia miito ya RPC. [web3 (inafunguka katika kichupo kipya)](https://github.com/ethereum/web3.js/) inafanya kazi na nodi yoyote ya Ethereum inayoweka wazi safu ya RPC. `web3` ina kipengee cha `eth` - web3.eth. var fs = require("fs") var recognizer = require("ethereum-keyfile-recognizer") fs.readFile("keyfile.json", (err, data) => { var json = JSON.parse(data) var result = recognizer(json) }) /** matokeo * [ 'web3', 3 ] faili la ufunguo la Web3 (v3) * [ 'ethersale', undefined ] faili la ufunguo la Ethersale * null faili la ufunguo batili */ NakiliJS Onyesha yote (13) Hii inaandika **toleo la 3** la Ufafanuzi wa Hifadhi ya Siri ya Web3. [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/web3-secret-storage/#definition) Ufafanuzi ------------------------------------------------------------------------------------------------------------------ Usimbaji na usimbuaji halisi wa faili unabaki bila kubadilika sana kutoka toleo la 1, isipokuwa kwamba algoriti ya kripto haijafungwa tena kwenye AES-128-CBC (AES-128-CTR sasa ni hitaji la chini kabisa). Maana/algoriti nyingi zinafanana na toleo la 1, isipokuwa `mac`, ambayo inatolewa kama SHA3 (keccak-256) ya miunganisho ya baiti 16 za pili kutoka kushoto za ufunguo uliotolewa pamoja na `ciphertext` kamili. Faili za ufunguo wa siri zinahifadhiwa moja kwa moja katika `~/.web3/keystore` (kwa mifumo kama ya Unix) na `~/AppData/Web3/keystore` (kwa Windows). Zinaweza kuitwa chochote, lakini utaratibu mzuri ni `.json`, ambapo `` ni UUID ya biti 128 iliyotolewa kwa ufunguo wa siri (wakala wa kuhifadhi faragha kwa anwani ya ufunguo wa siri). Faili zote kama hizo zina nenosiri linalohusiana. Ili kupata ufunguo wa siri wa faili fulani ya `.json`, kwanza pata ufunguo wa usimbaji fiche wa faili; hii inafanywa kwa kuchukua nenosiri la faili na kulipitisha kwenye kitendakazi cha kutoa ufunguo kama ilivyoelezwa na ufunguo wa `kdf`. Vigezo tuli na badilifu vinavyotegemea KDF kwa kitendakazi cha KDF vinaelezwa katika ufunguo wa `kdfparams`. PBKDF2 lazima iungwe mkono na utekelezaji wote unaokidhi viwango vya chini, unaoonyeshwa kupitia: * `kdf`: `pbkdf2` Kwa PBKDF2, kdfparams zinajumuisha: * `prf`: Lazima iwe `hmac-sha256` (inaweza kupanuliwa katika siku zijazo); * `c`: idadi ya marudio; * `salt`: salt iliyopitishwa kwa PBKDF; * `dklen`: urefu wa ufunguo uliotolewa. Lazima iwe >= 32. Mara tu ufunguo wa faili unapopatikana, unapaswa kuthibitishwa kupitia utoaji wa MAC. MAC inapaswa kuhesabiwa kama heshi ya SHA3 (keccak-256) ya safu ya baiti iliyoundwa kama miunganisho ya baiti 16 za pili kutoka kushoto za ufunguo uliotolewa na yaliyomo kwenye ufunguo wa `ciphertext`, yaani,: KECCAK(DK[16..31] ++ ) NakiliJS (ambapo `++` ni opereta ya muunganisho) Thamani hii inapaswa kulinganishwa na yaliyomo kwenye ufunguo wa `mac`; ikiwa ni tofauti, nenosiri mbadala linapaswa kuombwa (au operesheni ighairiwe). Baada ya ufunguo wa faili kuthibitishwa, maandishi ya siri (ufunguo wa `ciphertext` kwenye faili) yanaweza kusimbuliwa kwa kutumia algoriti ya usimbaji fiche linganifu iliyobainishwa na ufunguo wa `cipher` na kuwekewa vigezo kupitia ufunguo wa `cipherparams`. Ikiwa ukubwa wa ufunguo uliotolewa na ukubwa wa ufunguo wa algoriti haulingani, baiti za kulia kabisa zilizojazwa sifuri za ufunguo uliotolewa zinapaswa kutumika kama ufunguo wa algoriti. Utekelezaji wote unaokidhi viwango vya chini lazima uunge mkono algoriti ya AES-128-CTR, inayoonyeshwa kupitia: * `cipher: aes-128-ctr` Sifa hii ya siri inachukua vigezo vifuatavyo, vilivyotolewa kama funguo kwa ufunguo wa cipherparams: * `iv`: vekta ya uanzishaji ya biti 128 kwa sifa ya siri. Ufunguo wa sifa ya siri ni baiti 16 za kushoto kabisa za ufunguo uliotolewa, yaani, `DK[0..15]` Uundaji/usimbaji fiche wa ufunguo wa siri unapaswa kuwa kinyume cha maagizo haya. Hakikisha `uuid`, `salt` na `iv` ni za nasibu kweli. Mbali na uga wa `version`, ambao unapaswa kufanya kazi kama kitambulisho "kigumu" cha toleo, utekelezaji unaweza pia kutumia `minorversion` kufuatilia mabadiliko madogo, yasiyovunja muundo. [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/web3-secret-storage/#test-vectors) Vekta za Majaribio ----------------------------------------------------------------------------------------------------------------------------- Maelezo: * `Address`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b` * `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67` * `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6` * `Password`: `testpassword` * `Secret`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d` ### [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/web3-secret-storage/#pbkdf2-sha-256) PBKDF2-SHA-256 Vekta ya majaribio kwa kutumia `AES-128-CTR` na `PBKDF2-SHA-256`: Yaliyomo kwenye faili la `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`: { "crypto": { "cipher": "aes-128-ctr", "cipherparams": { "iv": "6087dab2f9fdbbfaddc31a909735c1e6" }, "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46", "kdf": "pbkdf2", "kdfparams": { "c": 262144, "dklen": 32, "prf": "hmac-sha256", "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd" }, "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2" }, "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", "version": 3 } NakiliJSON Onyesha yote (19) **Hatua za kati**: `Derived key`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` `MAC Body`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` `MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` `Cipher key`: `f06d69cdc7da0faffb1008270bca38f5` ### [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/web3-secret-storage/#scrypt) Scrypt Vekta ya majaribio kwa kutumia AES-128-CTR na Scrypt: { "crypto": { "cipher": "aes-128-ctr", "cipherparams": { "iv": "740770fce12ce862af21264dab25f1da" }, "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2", "kdf": "scrypt", "kdfparams": { "dklen": 32, "n": 262144, "p": 1, "r": 8, "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034" }, "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c" }, "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", "version": 3 } NakiliJSON Onyesha yote (20) **Hatua za kati**: `Derived key`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` `MAC Body`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` `MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` `Cipher key`: `7446f59ecc301d2d79bc3302650d8a5c` [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/web3-secret-storage/#alterations-from-v2) Mabadiliko kutoka Toleo la 1 ---------------------------------------------------------------------------------------------------------------------------------------------- Toleo hili linarekebisha kutofautiana kadhaa na toleo la 1 lililochapishwa [hapa (inafunguka katika kichupo kipya)](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst) . Kwa ufupi haya ni: * Uwekaji wa herufi kubwa hauna msingi na haulingani (scrypt herufi ndogo, Kdf herufi mchanganyiko, MAC herufi kubwa). * Anwani si ya lazima na inahatarisha faragha. * `Salt` kimsingi ni kigezo cha kitendakazi cha kutoa ufunguo na inastahili kuhusishwa nacho, si na kripto kwa ujumla. * _SaltLen_ si ya lazima (itoe tu kutoka kwa Salt). * Kitendakazi cha kutoa ufunguo kimetolewa, lakini algoriti ya kripto imebainishwa kwa uthabiti. * `Version` kimsingi ni nambari lakini ni mfuatano (utolewaji wa matoleo uliopangwa ungewezekana kwa mfuatano, lakini unaweza kuchukuliwa kuwa nje ya upeo kwa muundo wa faili ya usanidi unaobadilika mara chache). * `KDF` na `cipher` kinadharia ni dhana ndugu lakini zimepangwa tofauti. * `MAC` inahesabiwa kupitia kipande cha data kisichojali nafasi tupu(!) Mabadiliko yamefanywa kwenye muundo ili kutoa faili ifuatayo, inayolingana kiutendaji na mfano uliotolewa kwenye ukurasa uliounganishwa hapo awali: { "crypto": { "cipher": "aes-128-cbc", "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b", "cipherparams": { "iv": "16d67ba0ce5a339ff2f07951253e6ba8" }, "kdf": "scrypt", "kdfparams": { "dklen": 32, "n": 262144, "p": 1, "r": 8, "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91" }, "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd", "version": 1 }, "id": "0498f19a-59db-4d54-ac95-33901b4f1870", "version": 2 } NakiliJSON Onyesha yote (21) [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/web3-secret-storage/#alterations-from-v2-2) Mabadiliko kutoka Toleo la 2 ------------------------------------------------------------------------------------------------------------------------------------------------ Toleo la 2 lilikuwa utekelezaji wa mapema wa C++ wenye hitilafu kadhaa. Mambo yote muhimu yanabaki bila kubadilika kutoka kwake. --- # Kiwango cha Tokeni Inayolipwa cha ERC-1363 | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/standards/tokens/erc-1363/#main-content) Change page Kiwango cha Tokeni Inayolipwa cha ERC-1363 ========================================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/tokens/erc-1363/index.md) Kwenye ukurasa huu [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-1363/#introduction) Utangulizi ---------------------------------------------------------------------------------------------- ### [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-1363/#what-is-erc1363) ERC-1363 ni nini? ERC-1363 ni kiolesura cha upanuzi cha tokeni za ERC-20 kinachounga mkono kutekeleza mantiki maalum kwenye mkataba wa mpokeaji baada ya uhamisho, au kwenye mkataba wa mtumiaji baada ya idhini, yote ndani ya muamala mmoja. ### [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-1363/#erc20-differences) Tofauti na ERC-20 Operesheni za kawaida za ERC-20 kama `transfer`, `transferFrom` na `approve`, haziruhusu utekelezaji wa msimbo kwenye mkataba wa mpokeaji au mtumiaji bila muamala tofauti. Hii inaleta ugumu katika uundaji wa kiolesura cha mtumiaji (UI) na msuguano katika upokeaji kwa sababu watumiaji lazima wasubiri muamala wa kwanza utekelezwe na kisha wawasilishe wa pili. Pia lazima walipe gesi mara mbili. ERC-1363 inafanya tokeni zinazoweza kubadilishana kuwa na uwezo wa kufanya vitendo kwa urahisi zaidi na kufanya kazi bila matumizi ya msikilizaji yeyote wa nje ya mnyororo. Inaruhusu kufanya wito wa kurudi (callback) kwenye mkataba wa mpokeaji au mtumiaji, baada ya hamisho au idhini, katika muamala mmoja. [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-1363/#prerequisites) Mahitaji ya awali ------------------------------------------------------------------------------------------------------ Ili kuelewa vyema ukurasa huu, tunapendekeza usome kwanza kuhusu: * [Viwango vya tokeni](https://ethereum.org/sw/developers/docs/standards/tokens/) * [ERC-20](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/) [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-1363/#body) Mwili --------------------------------------------------------------------------------- ERC-1363 inaleta API ya kiwango kwa tokeni za ERC-20 ili kuingiliana na mikataba mahiri baada ya `transfer`, `transferFrom` au `approve`. Kiwango hiki kinatoa utendaji wa kimsingi wa kuhamisha tokeni, pamoja na kuruhusu tokeni kuidhinishwa ili ziweze kutumiwa na mtu mwingine wa tatu mnyororoni, na kisha kufanya wito wa kurudi kwenye mkataba wa mpokeaji au mtumiaji. Kuna matumizi mengi yaliyopendekezwa ya mikataba mahiri yanayoweza kukubali wito wa kurudi wa ERC-20. Mifano inaweza kuwa: * **Mauzo ya umati (Crowdsales)**: tokeni zilizotumwa huchochea ugawaji wa tuzo wa papo hapo. * **Huduma**: malipo huwezesha ufikiaji wa huduma katika hatua moja. * **Ankara**: tokeni hulipa ankara kiotomatiki. * **Usajili**: kuidhinisha kiwango cha mwaka huwezesha usajili ndani ya malipo ya mwezi wa kwanza. Kwa sababu hizi hapo awali ilipewa jina la **"Tokeni Inayolipwa"**. Tabia ya wito wa kurudi inapanua zaidi matumizi yake, kuwezesha mwingiliano usio na mshono kama vile: * **Uwekaji dhamana**: tokeni zilizohamishwa huchochea ufungaji wa kiotomatiki katika mkataba wa uwekaji dhamana. * **Kura**: tokeni zilizopokelewa husajili kura katika mfumo wa utawala. * **Badilishano**: idhini za tokeni huwezesha mantiki ya badilishano katika hatua moja. Tokeni za ERC-1363 zinaweza kutumika kwa matumizi maalum katika visa vyote vinavyohitaji wito wa kurudi kutekelezwa baada ya hamisho au idhini kupokelewa. ERC-1363 pia ni muhimu kwa kuepuka upotezaji wa tokeni au kufungwa kwa tokeni katika mikataba mahiri kwa kuthibitisha uwezo wa mpokeaji kushughulikia tokeni. Tofauti na mapendekezo mengine ya upanuzi wa ERC-20, ERC-1363 haibatilishi mbinu za ERC-20 za `transfer` na `transferFrom` na inafafanua vitambulisho vya violesura (interfaces IDs) vitakavyotekelezwa huku ikidumisha utangamano wa nyuma na ERC-20. Kutoka [EIP-1363 (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-1363) : ### [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-1363/#methods) Mbinu Mikataba mahiri inayotekeleza kiwango cha ERC-1363 **LAZIMA** itekeleze kazi zote katika kiolesura cha `ERC1363`, pamoja na violesura vya `ERC20` na `ERC165`. pragma solidity ^0.8.0; /** * @title ERC1363 * @dev Kiolesura cha ugani cha tokeni za ERC-20 kinachounga mkono kutekeleza msimbo kwenye mkataba wa mpokeaji * baada ya `transfer` au `transferFrom`, au msimbo kwenye mkataba wa mtumiaji baada ya `approve`, katika muamala mmoja. */ interface ERC1363 is ERC20, ERC165 { /* * KUMBUKA: kitambulisho cha ERC-165 cha kiolesura hiki ni 0xb0202a11. * 0xb0202a11 === * bytes4(keccak256('transferAndCall(address,uint256)')) ^ * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^ * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^ * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^ * bytes4(keccak256('approveAndCall(address,uint256)')) ^ * bytes4(keccak256('approveAndCall(address,uint256,bytes)')) */ /** * @dev Inahamisha kiasi cha `value` cha tokeni kutoka kwenye akaunti ya mpigaji kwenda `to` * na kisha kuita `ERC1363Receiver::onTransferReceived` kwenye `to`. * @param to Anwani ambayo tokeni zinahamishiwa. * @param value Kiasi cha tokeni zinazopaswa kuhamishwa. * @return Thamani ya boolean inayoonyesha operesheni imefaulu isipokuwa kama inatupa kosa (throwing). */ function transferAndCall(address to, uint256 value) external returns (bool); /** * @dev Inahamisha kiasi cha `value` cha tokeni kutoka kwenye akaunti ya mpigaji kwenda `to` * na kisha kuita `ERC1363Receiver::onTransferReceived` kwenye `to`. * @param to Anwani ambayo tokeni zinahamishiwa. * @param value Kiasi cha tokeni zinazopaswa kuhamishwa. * @param data Data ya ziada isiyo na umbizo maalum, iliyotumwa katika wito kwenda `to`. * @return Thamani ya boolean inayoonyesha operesheni imefaulu isipokuwa kama inatupa kosa (throwing). */ function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool); /** * @dev Inahamisha kiasi cha `value` cha tokeni kutoka `from` kwenda `to` kwa kutumia utaratibu wa posho (allowance) * na kisha kuita `ERC1363Receiver::onTransferReceived` kwenye `to`. * @param from Anwani ambayo tokeni zitatumwa kutoka. * @param to Anwani ambayo tokeni zinahamishiwa. * @param value Kiasi cha tokeni zinazopaswa kuhamishwa. * @return Thamani ya boolean inayoonyesha operesheni imefaulu isipokuwa kama inatupa kosa (throwing). */ function transferFromAndCall(address from, address to, uint256 value) external returns (bool); /** * @dev Inahamisha kiasi cha `value` cha tokeni kutoka `from` kwenda `to` kwa kutumia utaratibu wa posho (allowance) * na kisha kuita `ERC1363Receiver::onTransferReceived` kwenye `to`. * @param from Anwani ambayo tokeni zitatumwa kutoka. * @param to Anwani ambayo tokeni zinahamishiwa. * @param value Kiasi cha tokeni zinazopaswa kuhamishwa. * @param data Data ya ziada isiyo na umbizo maalum, iliyotumwa katika wito kwenda `to`. * @return Thamani ya boolean inayoonyesha operesheni imefaulu isipokuwa kama inatupa kosa (throwing). */ function transferFromAndCall(address from, address to, uint256 value, bytes calldata data) external returns (bool); /** * @dev Inaweka kiasi cha `value` cha tokeni kama posho ya `spender` juu ya tokeni za mpigaji * na kisha kuita `ERC1363Spender::onApprovalReceived` kwenye `spender`. * @param spender Anwani itakayotumia fedha. * @param value Kiasi cha tokeni zinazopaswa kutumika. * @return Thamani ya boolean inayoonyesha operesheni imefaulu isipokuwa kama inatupa kosa (throwing). */ function approveAndCall(address spender, uint256 value) external returns (bool); /** * @dev Inaweka kiasi cha `value` cha tokeni kama posho ya `spender` juu ya tokeni za mpigaji * na kisha kuita `ERC1363Spender::onApprovalReceived` kwenye `spender`. * @param spender Anwani itakayotumia fedha. * @param value Kiasi cha tokeni zinazopaswa kutumika. * @param data Data ya ziada isiyo na umbizo maalum, iliyotumwa katika wito kwenda `spender`. * @return Thamani ya boolean inayoonyesha operesheni imefaulu isipokuwa kama inatupa kosa (throwing). */ function approveAndCall(address spender, uint256 value, bytes calldata data) external returns (bool); } interface ERC20 { event Transfer(address indexed from, address indexed to, uint256 value); event Approval(address indexed owner, address indexed spender, uint256 value); function transfer(address to, uint256 value) external returns (bool); function transferFrom(address from, address to, uint256 value) external returns (bool); function approve(address spender, uint256 value) external returns (bool); function totalSupply() external view returns (uint256); function balanceOf(address account) external view returns (uint256); function allowance(address owner, address spender) external view returns (uint256); } interface ERC165 { function supportsInterface(bytes4 interfaceId) external view returns (bool); } NakiliSolidity Onyesha yote (93) Mkataba mahiri unaotaka kukubali tokeni za ERC-1363 kupitia `transferAndCall` au `transferFromAndCall` **LAZIMA** utekeleze kiolesura cha `ERC1363Receiver`: /** * @title ERC1363Receiver * @dev Kiolesura cha mkataba wowote unaotaka kuunga mkono `transferAndCall` au `transferFromAndCall` kutoka kwenye mikataba ya tokeni za ERC-1363. */ interface ERC1363Receiver { /** * @dev Kila wakati tokeni za ERC-1363 zinapohamishiwa kwenye mkataba huu kupitia `ERC1363::transferAndCall` au `ERC1363::transferFromAndCall` * na `operator` kutoka `from`, chaguo hili la kukokotoa (function) linaitwa. * * KUMBUKA: Ili kukubali hamisho, hii lazima irudishe * `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` * (yaani 0x88a7ca5c, au kiteuzi chake cha chaguo la kukokotoa). * * @param operator Anwani iliyoita chaguo la kukokotoa la `transferAndCall` au `transferFromAndCall`. * @param from Anwani ambayo tokeni zinahamishwa kutoka. * @param value Kiasi cha tokeni zilizohamishwa. * @param data Data ya ziada isiyo na umbizo maalum. * @return `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` ikiwa hamisho linaruhusiwa isipokuwa kama inatupa kosa (throwing). */ function onTransferReceived(address operator, address from, uint256 value, bytes calldata data) external returns (bytes4); } NakiliSolidity Onyesha yote (21) Mkataba mahiri unaotaka kukubali tokeni za ERC-1363 kupitia `approveAndCall` **LAZIMA** utekeleze kiolesura cha `ERC1363Spender`: /** * @title ERC1363Spender * @dev Kiolesura cha mkataba wowote unaotaka kuunga mkono `approveAndCall` kutoka kwenye mikataba ya tokeni za ERC-1363. */ interface ERC1363Spender { /** * @dev Kila wakati `owner` wa tokeni za ERC-1363 anapoidhinisha mkataba huu kupitia `ERC1363::approveAndCall` * kutumia tokeni zao, chaguo hili la kukokotoa (function) linaitwa. * * KUMBUKA: Ili kukubali idhini, hii lazima irudishe * `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` * (yaani 0x7b04a2d0, au kiteuzi chake cha chaguo la kukokotoa). * * @param owner Anwani iliyoita chaguo la kukokotoa la `approveAndCall` na iliyomiliki tokeni hapo awali. * @param value Kiasi cha tokeni zinazopaswa kutumika. * @param data Data ya ziada isiyo na umbizo maalum. * @return `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` ikiwa idhini inaruhusiwa isipokuwa kama inatupa kosa (throwing). */ function onApprovalReceived(address owner, uint256 value, bytes calldata data) external returns (bytes4); } NakiliSolidity Onyesha yote (20) [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-1363/#further-reading) Usomaji zaidi ---------------------------------------------------------------------------------------------------- * [ERC-1363: Kiwango cha Tokeni Inayolipwa (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-1363) * [ERC-1363: Hifadhi ya GitHub (inafunguka katika kichupo kipya)](https://github.com/vittominacori/erc1363-payable-token) --- # Hifadhi Iliyogatuliwa | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/storage/#main-content) Change page Hifadhi Iliyogatuliwa ===================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/storage/index.md) Kwenye ukurasa huu Tofauti na seva kuu inayoendeshwa na kampuni au shirika moja, mifumo ya hifadhi iliyogatuliwa inajumuisha mtandao wa rika-kwa-rika wa waendeshaji-watumiaji ambao wanashikilia sehemu ya data yote, na kuunda mfumo thabiti wa kushiriki hifadhi ya faili. Hizi zinaweza kuwa katika programu inayotegemea mnyororo wa vitalu au mtandao wowote unaotegemea rika-kwa-rika. Ethereum yenyewe inaweza kutumika kama mfumo wa hifadhi iliyogatuliwa, na inatumika inapokuja kwenye hifadhi ya msimbo katika mikataba yote mahiri. Hata hivyo, inapokuja kwenye kiasi kikubwa cha data, hilo sio ambalo Ethereum iliundwa kwa ajili yake. Mnyororo unakua kwa kasi, lakini wakati wa kuandika, mnyororo wa Ethereum ni karibu 500GB - 1TB ([kulingana na mteja (inafunguka katika kichupo kipya)](https://etherscan.io/chartsync/chaindefault) ), na kila nodi kwenye mtandao inahitaji kuwa na uwezo wa kuhifadhi data yote. Ikiwa mnyororo ungepanuka hadi kiasi kikubwa cha data (tuseme 5TBs) isingewezekana kwa nodi zote kuendelea kufanya kazi. Pia, gharama ya kupeleka data nyingi hivi kwenye Mtandao Mkuu itakuwa ghali sana kutokana na ada za [gesi](https://ethereum.org/sw/developers/docs/gas/) . Kutokana na vikwazo hivi, tunahitaji mnyororo tofauti au mbinu ya kuhifadhi kiasi kikubwa cha data kwa njia iliyogatuliwa. Unapoangalia chaguzi za hifadhi iliyogatuliwa (dStorage), kuna mambo machache ambayo mtumiaji lazima akumbuke. * Utaratibu wa kudumu / muundo wa motisha * Utekelezaji wa uhifadhi wa data * Ugatuzi * Mwafaka [](https://ethereum.org/sw/developers/docs/storage/#persistence-mechanism) Utaratibu wa kudumu / muundo wa motisha ------------------------------------------------------------------------------------------------------------------ ### [](https://ethereum.org/sw/developers/docs/storage/#blockchain-based) Inayotegemea mnyororo wa vitalu Ili kipande cha data kidumu milele, tunahitaji kutumia utaratibu wa kudumu. Kwa mfano, kwenye Ethereum, utaratibu wa kudumu ni kwamba mnyororo mzima unahitaji kuzingatiwa wakati wa kuendesha nodi. Vipande vipya vya data vinaongezwa mwishoni mwa mnyororo, na unaendelea kukua - ikihitaji kila nodi kunakili data yote iliyopachikwa. Hii inajulikana kama udumu **unaotegemea mnyororo wa vitalu**. Suala la udumu unaotegemea mnyororo wa vitalu ni kwamba mnyororo unaweza kuwa mkubwa sana kuutunza na kuhifadhi data yote kwa uwezekano (k.m., [vyanzo vingi (inafunguka katika kichupo kipya)](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) vinakadiria Mtandao unahitaji zaidi ya Zetabytes 40 za uwezo wa kuhifadhi). Mnyororo wa vitalu lazima pia uwe na aina fulani ya muundo wa motisha. Kwa udumu unaotegemea mnyororo wa vitalu, kuna malipo yanayofanywa kwa mthibitishaji. Wakati data inaongezwa kwenye mnyororo, wathibitishaji wanalipwa ili kuongeza data hiyo. Majukwaa yenye udumu unaotegemea mnyororo wa vitalu: * Ethereum * [Arweave (inafunguka katika kichupo kipya)](https://www.arweave.org/) ### [](https://ethereum.org/sw/developers/docs/storage/#contract-based) Inayotegemea mkataba Udumu **unaotegemea mkataba** una dhana kwamba data haiwezi kunakiliwa na kila nodi na kuhifadhiwa milele, na badala yake lazima itunzwe kwa makubaliano ya mkataba. Haya ni makubaliano yaliyofanywa na nodi nyingi ambazo zimeahidi kushikilia kipande cha data kwa muda fulani. Lazima zirejeshewe fedha au zifanywe upya kila zinapoisha ili kuweka data idumu. Katika hali nyingi, badala ya kuhifadhi data yote mnyororoni, heshi ya mahali data ilipo kwenye mnyororo inahifadhiwa. Kwa njia hii, mnyororo mzima hauhitaji kupanuka ili kuweka data yote. Majukwaa yenye udumu unaotegemea mkataba: * [Filecoin (inafunguka katika kichupo kipya)](https://docs.filecoin.io/basics/what-is-filecoin) * [Skynet (inafunguka katika kichupo kipya)](https://sia.tech/) * [Storj (inafunguka katika kichupo kipya)](https://storj.io/) * [Züs (inafunguka katika kichupo kipya)](https://zus.network/) * [Crust Network (inafunguka katika kichupo kipya)](https://crust.network/) * [Kundi (inafunguka katika kichupo kipya)](https://www.ethswarm.org/) * [4EVERLAND (inafunguka katika kichupo kipya)](https://www.4everland.org/) ### [](https://ethereum.org/sw/developers/docs/storage/#additional-consideration) Mambo ya ziada ya kuzingatia IPFS ni mfumo uliosambazwa wa kuhifadhi na kufikia faili, tovuti, programu, na data. Haina mpango wa motisha uliojengewa ndani, lakini badala yake inaweza kutumika na suluhisho lolote la motisha linalotegemea mkataba hapo juu kwa udumu wa muda mrefu. Njia nyingine ya kudumisha data kwenye IPFS ni kufanya kazi na huduma ya kubandika (pinning), ambayo "itabandika" data yako kwa ajili yako. Unaweza hata kuendesha nodi yako mwenyewe ya IPFS na kuchangia kwenye mtandao ili kudumisha data yako na/au ya wengine bila malipo! * [IPFS (inafunguka katika kichupo kipya)](https://docs.ipfs.io/concepts/what-is-ipfs/) * [Pinata (inafunguka katika kichupo kipya)](https://www.pinata.cloud/) _(Huduma ya kubandika ya IPFS)_ * [web3.storage (inafunguka katika kichupo kipya)](https://web3.storage/) _(Huduma ya kubandika ya IPFS/Filecoin)_ * [Infura (inafunguka katika kichupo kipya)](https://infura.io/product/ipfs) _(Huduma ya kubandika ya IPFS)_ * [IPFS Scan (inafunguka katika kichupo kipya)](https://ipfs-scan.io/) _(Kichunguzi cha kubandika cha IPFS)_ * [4EVERLAND (inafunguka katika kichupo kipya)](https://www.4everland.org/) _（Huduma ya kubandika ya IPFS）_ * [Filebase (inafunguka katika kichupo kipya)](https://filebase.com/) _(Huduma ya Kubandika ya IPFS)_ * [Spheron Network (inafunguka katika kichupo kipya)](https://spheron.network/) _(Huduma ya kubandika ya IPFS/Filecoin)_ Kundi (SWARM) ni teknolojia ya hifadhi na usambazaji wa data iliyogatuliwa yenye mfumo wa motisha wa hifadhi na orakeli ya bei ya kodi ya hifadhi. [](https://ethereum.org/sw/developers/docs/storage/#data-retention) Uhifadhi wa data ------------------------------------------------------------------------------------ Ili kuhifadhi data, mifumo lazima iwe na aina fulani ya utaratibu wa kuhakikisha data inahifadhiwa. ### [](https://ethereum.org/sw/developers/docs/storage/#challenge-mechanism) Utaratibu wa changamoto Mojawapo ya njia maarufu za kuhakikisha data inahifadhiwa, ni kutumia aina fulani ya changamoto ya kriptografia ambayo inatolewa kwa nodi ili kuhakikisha bado zina data. Njia rahisi ni kuangalia uthibitisho wa ufikiaji wa Arweave. Wanatoa changamoto kwa nodi ili kuona kama zina data kwenye kitalu cha hivi karibuni na kitalu cha nasibu cha zamani. Ikiwa nodi haiwezi kupata jibu, inaadhibiwa. Aina za hifadhi iliyogatuliwa (dStorage) zenye utaratibu wa changamoto: * Züs * Skynet * Arweave * Filecoin * Crust Network * 4EVERLAND ### [](https://ethereum.org/sw/developers/docs/storage/#decentrality) Ugatuzi Hakuna zana nzuri za kupima kiwango cha ugatuzi cha majukwaa, lakini kwa ujumla, utataka kutumia zana ambazo hazina aina fulani ya KYC ili kutoa ushahidi kwamba hazijajikita kati. Zana zilizogatuliwa bila KYC: * Skynet * Arweave * Filecoin * IPFS * Ethereum * Crust Network * 4EVERLAND ### [](https://ethereum.org/sw/developers/docs/storage/#consensus) Mwafaka Nyingi ya zana hizi zina toleo lao la [utaratibu wa makubaliano](https://ethereum.org/sw/developers/docs/consensus-mechanisms/) lakini kwa ujumla zinategemea ama [**Uthibitisho wa Kazi (PoW)**](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pow/) au [**Uthibitisho wa Dau (PoS)**](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/) . Zinazotegemea Uthibitisho wa Kazi: * Skynet * Arweave Zinazotegemea Uthibitisho wa Dau: * Ethereum * Filecoin * Züs * Crust Network [](https://ethereum.org/sw/developers/docs/storage/#related-tools) Zana zinazohusiana ------------------------------------------------------------------------------------- **IPFS - _InterPlanetary File System ni mfumo wa hifadhi iliyogatuliwa na mfumo wa kurejelea faili kwa ajili ya Ethereum._** * [Ipfs.io (inafunguka katika kichupo kipya)](https://ipfs.io/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.ipfs.io/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/ipfs/ipfs) **Storj DCS - _Hifadhi ya kipengee cha wingu iliyogatuliwa iliyo salama, ya faragha, na inayoendana na S3 kwa ajili ya wasanidi programu._** * [Storj.io (inafunguka katika kichupo kipya)](https://storj.io/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.storj.io/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/storj/storj) **Sia - _Inatumia kriptografia kuunda soko la hifadhi ya wingu bila hitaji la uaminifu, ikiruhusu wanunuzi na wauzaji kufanya miamala moja kwa moja._** * [Skynet.net (inafunguka katika kichupo kipya)](https://sia.tech/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.sia.tech/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/SiaFoundation/) **Filecoin - _Filecoin iliundwa na timu ile ile iliyo nyuma ya IPFS. Ni safu ya motisha juu ya maadili ya IPFS._** * [Filecoin.io (inafunguka katika kichupo kipya)](https://filecoin.io/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.filecoin.io/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/filecoin-project/) **Arweave - _Arweave ni jukwaa la hifadhi iliyogatuliwa (dStorage) kwa ajili ya kuhifadhi data._** * [Arweave.org (inafunguka katika kichupo kipya)](https://www.arweave.org/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.arweave.org/info/) * [Arweave (inafunguka katika kichupo kipya)](https://github.com/ArweaveTeam/arweave/) **Züs - _Züs ni jukwaa la hifadhi iliyogatuliwa (dStorage) la Uthibitisho wa Dau lenye shadi na blobbers._** * [zus.network (inafunguka katika kichupo kipya)](https://zus.network/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.zus.network/zus-docs/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/0chain/) **Crust Network - _Crust ni jukwaa la hifadhi iliyogatuliwa (dStorage) juu ya IPFS._** * [Crust.network (inafunguka katika kichupo kipya)](https://crust.network/) * [Nyaraka (inafunguka katika kichupo kipya)](https://wiki.crust.network/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/crustio) **Kundi - _Jukwaa la hifadhi iliyosambazwa na huduma ya usambazaji wa maudhui kwa ajili ya mrundikano wa Web3 wa Ethereum._** * [EthSwarm.org (inafunguka katika kichupo kipya)](https://www.ethswarm.org/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.ethswarm.org/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/ethersphere/) **OrbitDB - _Hifadhidata iliyogatuliwa ya rika-kwa-rika juu ya IPFS._** * [OrbitDB.org (inafunguka katika kichupo kipya)](https://orbitdb.org/) * [Nyaraka (inafunguka katika kichupo kipya)](https://github.com/orbitdb/field-manual/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/orbitdb/orbit-db/) **Aleph.im - _Mradi wa wingu uliogatuliwa (hifadhidata, hifadhi ya faili, kompyuta na utambulisho uliogatuliwa (DID)). Mchanganyiko wa kipekee wa teknolojia ya rika-kwa-rika nje ya mnyororo na mnyororoni. Utangamano wa IPFS na minyororo mingi._** * [Aleph.im (inafunguka katika kichupo kipya)](https://aleph.cloud/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.aleph.cloud/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/aleph-im/) **Ceramic - _Hifadhi ya hifadhidata ya IPFS inayodhibitiwa na mtumiaji kwa ajili ya programu zenye data nyingi na zinazoshirikisha._** * [Ceramic.network (inafunguka katika kichupo kipya)](https://ceramic.network/) * [Nyaraka (inafunguka katika kichupo kipya)](https://developers.ceramic.network/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/ceramicnetwork/js-ceramic/) **Filebase - _Hifadhi iliyogatuliwa inayoendana na S3 na huduma ya kubandika ya IPFS yenye urudufishaji wa kijiografia. Faili zote zinazopakiwa kwenye IPFS kupitia Filebase zinabandikwa kiotomatiki kwenye miundombinu ya Filebase zikiwa na urudufishaji mara 3 kote ulimwenguni._** * [Filebase.com (inafunguka katika kichupo kipya)](https://filebase.com/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.filebase.com/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/filebase) **4EVERLAND - _Jukwaa la kompyuta ya wingu la Wavuti 3.0 ambalo linaunganisha uwezo wa msingi wa hifadhi, kompyuta na mtandao, linaendana na S3 na hutoa hifadhi ya data inayosawazishwa kwenye mitandao ya hifadhi iliyogatuliwa kama vile IPFS na Arweave._** * [4everland.org (inafunguka katika kichupo kipya)](https://www.4everland.org/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.4everland.org/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/4everland) **Kaleido - _Jukwaa la mnyororo wa vitalu kama huduma lenye Nodi za IPFS za kubofya kitufe_** * [Kaleido (inafunguka katika kichupo kipya)](https://kaleido.io/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.kaleido.io/kaleido-services/ipfs/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/kaleido-io) **Spheron Network - _Spheron ni jukwaa kama huduma (PaaS) lililoundwa kwa ajili ya programu tumizi zilizogatuliwa (dapps) zinazotafuta kuzindua programu zao kwenye miundombinu iliyogatuliwa kwa utendaji bora. Inatoa kompyuta, hifadhi iliyogatuliwa, CDN na upangishaji wa wavuti kwa chaguo-msingi._** * [spheron.network (inafunguka katika kichupo kipya)](https://spheron.network/) * [Nyaraka (inafunguka katika kichupo kipya)](https://docs.spheron.network/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/spheronFdn) **dweb3 - _Kisuluhishi cha kurasa za wavuti zilizogatuliwa, sawa na eth.limo, kinachounga mkono aina zote na hakizuiliwi kwa ENS na IPFS._** * [dweb3.wtf (inafunguka katika kichupo kipya)](https://dweb3.wtf/) **web3compass - _Injini ya utafutaji kwa ajili ya tovuti zilizogatuliwa zinazoungwa mkono na IPFS + ENS._** * [web3compass.net (inafunguka katika kichupo kipya)](https://www.web3compass.net/) * [Nyaraka (inafunguka katika kichupo kipya)](https://www.web3compass.net/statistics) [](https://ethereum.org/sw/developers/docs/storage/#further-reading) Usomaji zaidi ---------------------------------------------------------------------------------- * [Hifadhi Iliyogatuliwa ni Nini? (inafunguka katika kichupo kipya)](https://coinmarketcap.com/academy/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_ * [Kuvunja Hadithi Tano za Kawaida kuhusu Hifadhi Iliyogatuliwa (inafunguka katika kichupo kipya)](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_ _Unajua rasilimali ya jamii iliyokusaidia? Hariri ukurasa huu na uiongeze!_ [](https://ethereum.org/sw/developers/docs/storage/#related-topics) Mada zinazohusiana -------------------------------------------------------------------------------------- * [Mifumo ya usanidi](https://ethereum.org/sw/developers/docs/frameworks/) --- # Web3 인터페이스 디자인을 위한 7가지 휴리스틱 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/design-and-ux/heuristics-for-web3/#main-content) Change page Web3 인터페이스 디자인을 위한 7가지 휴리스틱 =========================== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/design-and-ux/heuristics-for-web3/index.md) 이 페이지의 내용 사용성 휴리스틱은 사이트의 사용성을 측정하는 데 사용할 수 있는 광범위한 "경험 법칙"입니다. 여기에 소개된 7가지 휴리스틱은 Web3에 특별히 맞춰져 있으며, 제이콥 닐슨(Jakob Nielsen)의 [인터랙션 디자인을 위한 10가지 일반 원칙 (새 탭에서 열림)](https://www.nngroup.com/articles/ten-usability-heuristics/) 과 함께 사용해야 합니다. [](https://ethereum.org/ko/developers/docs/design-and-ux/heuristics-for-web3/#seven-usability-heuristics-for-web3) Web3를 위한 7가지 사용성 휴리스틱 ---------------------------------------------------------------------------------------------------------------------------------------- 1. 행동에 따른 피드백 2. 보안과 신뢰 3. 가장 중요한 정보의 명확성 4. 이해하기 쉬운 용어 5. 가능한 한 짧은 작업 단계 6. 가시적이고 유연한 네트워크 연결 7. 지갑이 아닌 앱에서의 제어 [](https://ethereum.org/ko/developers/docs/design-and-ux/heuristics-for-web3/#definitions-and-examples) 정의 및 예시 --------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ko/developers/docs/design-and-ux/heuristics-for-web3/#feedback-follows-action) 1\. 행동에 따른 피드백 **어떤 일이 일어났거나 일어나고 있을 때 이를 명확히 알 수 있어야 합니다.** 사용자는 이전 단계의 결과를 바탕으로 다음 단계를 결정합니다. 따라서 시스템 상태에 대해 지속적으로 정보를 제공받는 것이 필수적입니다. 트랜잭션이 블록체인에 기록되기까지 약간의 시간이 걸릴 수 있는 Web3에서는 이것이 특히 중요합니다. 기다리라는 피드백이 없으면 사용자는 어떤 일이 일어났는지 확신할 수 없습니다. **팁:** * 메시지, 알림 및 기타 경고를 통해 사용자에게 정보를 제공하세요. * 대기 시간을 명확하게 전달하세요. * 작업이 몇 초 이상 걸릴 경우, 타이머나 애니메이션을 통해 무언가 진행되고 있음을 알려 사용자를 안심시키세요. * 프로세스에 여러 단계가 있는 경우 각 단계를 보여주세요. **예시:** 트랜잭션에 포함된 각 단계를 보여주면 사용자가 프로세스의 어느 단계에 있는지 아는 데 도움이 됩니다. 적절한 아이콘은 사용자에게 작업 상태를 알려줍니다. [![Informing the user about each step when swapping tokens](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage1.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image1.png) ### [](https://ethereum.org/ko/developers/docs/design-and-ux/heuristics-for-web3/#security-and-trust-are-backed-in) 2\. 내장된 보안과 신뢰 보안은 우선시되어야 하며, 사용자에게 이를 강조해야 합니다. 사람들은 자신의 데이터를 매우 중요하게 생각합니다. 안전은 종종 사용자의 주요 관심사이므로 디자인의 모든 수준에서 고려되어야 합니다. 항상 사용자의 신뢰를 얻기 위해 노력해야 하지만, 이를 수행하는 방법은 앱마다 다를 수 있습니다. 이는 나중에 덧붙이는 것이 아니라 전체적으로 의식적으로 설계되어야 합니다. 최종 UI뿐만 아니라 소셜 채널 및 문서를 포함한 사용자 경험 전반에 걸쳐 신뢰를 구축하세요. 탈중앙화 수준, 트레저리 다중 서명(multi-sig) 상태, 팀의 신원 공개 여부 등은 모두 사용자의 신뢰에 영향을 미칩니다. **팁:** * 감사를 받은 내역을 자랑스럽게 나열하세요. * 여러 번의 감사를 받으세요. * 설계한 안전 기능을 적극적으로 알리세요. * 기본 연동을 포함하여 발생할 수 있는 위험을 강조하세요. * 전략의 복잡성을 전달하세요. * 사용자의 안전 인식에 영향을 미칠 수 있는 UI 외적인 문제도 고려하세요. **예시:** 푸터에 눈에 띄는 크기로 감사 내역을 포함하세요. [![Audits referenced in the website footer](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage2.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image2.png) ### [](https://ethereum.org/ko/developers/docs/design-and-ux/heuristics-for-web3/#the-most-important-info-is-obvious) 3\. 가장 중요한 정보의 명확성 복잡한 시스템의 경우 가장 관련성 높은 데이터만 표시하세요. 무엇이 가장 중요한지 결정하고 표시 우선순위를 정하세요. 너무 많은 정보는 부담을 주며, 사용자는 일반적으로 결정을 내릴 때 한 가지 정보에 의존합니다. 탈중앙화 금융(DeFi)의 경우, 이는 아마도 수익 창출 앱의 APR과 대출 앱의 LTV일 것입니다. **팁:** * 사용자 조사를 통해 가장 중요한 지표를 파악할 수 있습니다. * 핵심 정보는 크게 만들고, 기타 세부 정보는 작고 눈에 띄지 않게 만드세요. * 사람들은 읽지 않고 훑어봅니다. 디자인이 훑어보기 쉽게 되어 있는지 확인하세요. **예시:** 풀 컬러로 된 큰 토큰은 훑어볼 때 찾기 쉽습니다. APR은 크고 강조 색상으로 눈에 띄게 표시됩니다. [![The token and APR are easy to find](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage3.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image3.png) ### [](https://ethereum.org/ko/developers/docs/design-and-ux/heuristics-for-web3/#clear-terminology) 4\. 명확한 용어 용어는 이해하기 쉽고 적절해야 합니다. 기술 전문 용어는 완전히 새로운 멘탈 모델을 구축해야 하므로 큰 장애물이 될 수 있습니다. 사용자는 디자인을 이미 알고 있는 단어, 구문 및 개념과 연관시킬 수 없습니다. 모든 것이 혼란스럽고 낯설게 느껴지며, 사용을 시도하기 전부터 가파른 학습 곡선에 직면하게 됩니다. 사용자가 돈을 모으고 싶어서 DeFi에 접근했을 때 발견하는 것은 채굴, 파밍, 스테이킹, 발행량(emissions), 브라이브(bribes), 볼트(vaults), 락커(lockers), veTokens, 베스팅, 에포크(epochs), 탈중앙화된 알고리즘, 프로토콜 소유 유동성 등입니다... 가장 많은 사람들이 이해할 수 있는 간단한 용어를 사용하도록 노력하세요. 프로젝트만을 위해 완전히 새로운 용어를 만들지 마세요. **팁:** * 간단하고 일관된 용어를 사용하세요. * 가능한 한 기존 언어를 사용하세요. * 자신만의 용어를 만들어내지 마세요. * 나타나는 관례를 따르세요. * 가능한 한 사용자를 교육하세요. **예시:** "내 보상(Your rewards)"은 이 프로젝트를 위해 만들어진 새로운 단어가 아니라 널리 이해되는 중립적인 용어입니다. 보상 자체가 다른 토큰으로 제공되더라도 현실 세계의 멘탈 모델과 일치하도록 보상은 USD로 표시됩니다. [![Token rewards, displayed in U.S. dollars](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage4.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image4.png) ### [](https://ethereum.org/ko/developers/docs/design-and-ux/heuristics-for-web3/#actions-are-as-short-as-possible) 5\. 가능한 한 짧은 작업 단계 하위 작업을 그룹화하여 사용자의 상호 작용 속도를 높이세요. 이는 UI뿐만 아니라 스마트 컨트랙트 수준에서도 수행될 수 있습니다. 사용자가 일반적인 작업을 완료하기 위해 시스템의 한 부분에서 다른 부분으로 이동하거나 시스템을 완전히 벗어나서는 안 됩니다. **팁:** * 가능한 경우 "승인"을 다른 작업과 결합하세요. * 서명하기 단계를 가능한 한 가깝게 묶으세요. **예시:** "유동성 추가"와 "스테이킹"을 결합하는 것은 사용자의 시간과 가스를 모두 절약하는 액셀러레이터의 간단한 예입니다. [![Modal showing a switch to combine the deposit and stake actions](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage5.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image5.png) ### [](https://ethereum.org/ko/developers/docs/design-and-ux/heuristics-for-web3/#network-connections-are-visible-and-flexible) 6\. 가시적이고 유연한 네트워크 연결 사용자에게 어떤 네트워크에 연결되어 있는지 알리고, 네트워크를 변경할 수 있는 명확한 단축키를 제공하세요. 이는 멀티체인 앱에서 특히 중요합니다. 연결이 끊어지거나 지원되지 않는 네트워크에 연결된 상태에서도 앱의 주요 기능은 계속 표시되어야 합니다. **팁:** * 연결이 끊어진 상태에서도 가능한 한 앱의 많은 부분을 보여주세요. * 사용자가 현재 어떤 네트워크에 연결되어 있는지 보여주세요. * 사용자가 네트워크를 변경하기 위해 지갑으로 이동하게 만들지 마세요. * 앱에서 사용자가 네트워크를 전환해야 하는 경우, 기본 콜투액션(CTA)에서 해당 작업을 유도하세요. * 앱에 여러 네트워크를 위한 시장이나 볼트가 포함되어 있는 경우, 사용자가 현재 어떤 세트를 보고 있는지 명확하게 명시하세요. **예시:** 앱바(appbar)에서 사용자가 어떤 네트워크에 연결되어 있는지 보여주고, 이를 변경할 수 있도록 하세요. [![Dropdown button showing the connected network](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage6.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image6.png) ### [](https://ethereum.org/ko/developers/docs/design-and-ux/heuristics-for-web3/#control-from-the-app-not-the-wallet) 7\. 지갑이 아닌 앱에서의 제어 UI는 사용자가 알아야 할 모든 것을 알려주고, 해야 할 모든 것을 제어할 수 있도록 해야 합니다. Web3에서는 UI에서 수행하는 작업과 지갑에서 수행하는 작업이 있습니다. 일반적으로 UI에서 작업을 시작한 다음 지갑에서 확인합니다. 이 두 가지 흐름이 신중하게 통합되지 않으면 사용자는 불편함을 느낄 수 있습니다. **팁:** * UI의 피드백을 통해 시스템 상태를 전달하세요. * 사용자의 기록을 보관하세요. * 이전 트랜잭션에 대한 블록 탐색기 링크를 제공하세요. * 네트워크를 변경할 수 있는 단축키를 제공하세요. **예시:** 미묘한 컨테이너는 사용자가 지갑에 어떤 관련 토큰을 가지고 있는지 보여주며, 기본 CTA는 네트워크를 변경할 수 있는 단축키를 제공합니다. [![Main CTA is prompting the user to switch network](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fheuristics-for-web3%2FImage7.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/heuristics-for-web3/Image7.png) --- # 스마트 컨트랙트 소개 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/smart-contracts/#main-content) Change page 스마트 컨트랙트 소개 =========== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/index.md) 이 페이지의 내용 [](https://ethereum.org/ko/developers/docs/smart-contracts/#what-is-a-smart-contract) 스마트 컨트랙트란 무엇인가요? ------------------------------------------------------------------------------------------------------ "스마트 컨트랙트"는 단순히 [이더리움](https://ethereum.org/ko/) 블록체인에서 실행되는 프로그램입니다. 이는 이더리움 블록체인의 특정 주소에 존재하는 코드(함수)와 데이터(상태)의 모음입니다. 스마트 컨트랙트는 [이더리움 계정](https://ethereum.org/ko/developers/docs/accounts/) 의 한 종류입니다. 즉, 잔액을 보유하며 트랜잭션의 대상이 될 수 있습니다. 하지만 사용자가 제어하는 것이 아니라 네트워크에 배포되어 프로그래밍된 대로 실행됩니다. 사용자 계정은 스마트 컨트랙트에 정의된 함수를 실행하는 트랜잭션을 제출하여 스마트 컨트랙트와 상호작용할 수 있습니다. 스마트 컨트랙트는 일반적인 계약처럼 규칙을 정의하고 코드를 통해 이를 자동으로 강제할 수 있습니다. 기본적으로 스마트 컨트랙트는 삭제할 수 없으며, 스마트 컨트랙트와의 상호작용은 되돌릴 수 없습니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/#prerequisites) 전제 조건 -------------------------------------------------------------------------------- 이제 막 시작했거나 덜 기술적인 소개를 찾고 있다면, [스마트 컨트랙트 소개](https://ethereum.org/ko/smart-contracts/) 를 추천합니다. 스마트 컨트랙트의 세계로 뛰어들기 전에 [계정](https://ethereum.org/ko/developers/docs/accounts/) , [트랜잭션](https://ethereum.org/ko/developers/docs/transactions/) 및 [이더리움 가상 머신](https://ethereum.org/ko/developers/docs/evm/) 에 대해 읽어보시기 바랍니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/#a-digital-vending-machine) 디지털 자판기 ---------------------------------------------------------------------------------------------- [닉 사보(Nick Szabo) (새 탭에서 열림)](https://unenumerated.blogspot.com/) 가 설명한 것처럼, 스마트 컨트랙트를 가장 잘 비유할 수 있는 것은 자판기일 것입니다. 올바른 입력이 주어지면 특정 출력이 보장됩니다. 자판기에서 간식을 뽑으려면 다음과 같이 합니다. 돈 + 간식 선택 = 간식 나옴 복사 이러한 로직이 자판기에 프로그래밍되어 있습니다. 스마트 컨트랙트도 자판기처럼 로직이 프로그래밍되어 있습니다. 이 자판기가 Solidity로 작성된 스마트 컨트랙트라면 어떤 모습일지 보여주는 간단한 예시는 다음과 같습니다. pragma solidity 0.8.7; contract VendingMachine { // 컨트랙트의 상태 변수를 선언합니다 address public owner; mapping (address => uint) public cupcakeBalances; // 'VendingMachine' 컨트랙트가 배포될 때: // 1. 배포 주소를 컨트랙트의 소유자로 설정합니다 // 2. 배포된 스마트 컨트랙트의 컵케이크 잔액을 100으로 설정합니다 constructor() { owner = msg.sender; cupcakeBalances[address(this)] = 100; } // 소유자가 스마트 컨트랙트의 컵케이크 잔액을 증가시킬 수 있도록 허용합니다 function refill(uint amount) public { require(msg.sender == owner, "Only the owner can refill."); cupcakeBalances[address(this)] += amount; } // 누구나 컵케이크를 구매할 수 있도록 허용합니다 function purchase(uint amount) public payable { require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake"); require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase"); cupcakeBalances[address(this)] -= amount; cupcakeBalances[msg.sender] += amount; } } 복사Solidity 모두 보기 (30) 자판기가 판매 직원의 필요성을 없애주는 것처럼, 스마트 컨트랙트는 많은 산업에서 중개자를 대체할 수 있습니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/#permissionless) 무허가성 -------------------------------------------------------------------------------- 누구나 스마트 컨트랙트를 작성하여 네트워크에 배포할 수 있습니다. [스마트 컨트랙트 언어](https://ethereum.org/ko/developers/docs/smart-contracts/languages/) 로 코딩하는 방법을 배우고, 컨트랙트를 배포할 수 있는 충분한 ETH만 있으면 됩니다. 스마트 컨트랙트를 배포하는 것은 기술적으로 트랜잭션이므로, 단순한 ETH 전송에 가스를 지불하는 것과 같은 방식으로 [가스](https://ethereum.org/ko/developers/docs/gas/) 를 지불해야 합니다. 하지만 컨트랙트 배포에 드는 가스 비용은 훨씬 더 높습니다. 이더리움에는 스마트 컨트랙트를 작성하기 위한 개발자 친화적인 언어들이 있습니다. * Solidity * Vyper [언어에 대해 더 알아보기](https://ethereum.org/ko/developers/docs/smart-contracts/languages/) 하지만 이더리움 가상 머신이 컨트랙트를 해석하고 저장할 수 있도록 배포 전에 반드시 컴파일되어야 합니다. [컴파일에 대해 더 알아보기](https://ethereum.org/ko/developers/docs/smart-contracts/compiling/) [](https://ethereum.org/ko/developers/docs/smart-contracts/#composability) 조합성 ------------------------------------------------------------------------------ 스마트 컨트랙트는 이더리움 상에 공개되어 있으며 오픈 API로 생각할 수 있습니다. 즉, 자신의 스마트 컨트랙트에서 다른 스마트 컨트랙트를 호출하여 가능한 기능을 크게 확장할 수 있습니다. 심지어 컨트랙트가 다른 컨트랙트를 배포할 수도 있습니다. [스마트 컨트랙트 조합성](https://ethereum.org/ko/developers/docs/smart-contracts/composability/) 에 대해 자세히 알아보세요. [](https://ethereum.org/ko/developers/docs/smart-contracts/#limitations) 한계 --------------------------------------------------------------------------- 스마트 컨트랙트 단독으로는 오프체인 소스에서 데이터를 가져올 수 없기 때문에 "현실 세계"의 이벤트에 대한 정보를 얻을 수 없습니다. 즉, 현실 세계의 이벤트에 반응할 수 없습니다. 이는 의도적으로 설계된 것입니다. 외부 정보에 의존하면 보안과 탈중앙화에 중요한 합의를 위태롭게 할 수 있기 때문입니다. 하지만 블록체인 애플리케이션이 오프체인 데이터를 사용할 수 있는 것은 중요합니다. 이에 대한 해결책은 오프체인 데이터를 수집하여 스마트 컨트랙트에서 사용할 수 있게 해주는 도구인 [오라클](https://ethereum.org/ko/developers/docs/oracles/) 입니다. 스마트 컨트랙트의 또 다른 한계는 최대 컨트랙트 크기입니다. 스마트 컨트랙트의 최대 크기는 24KB이며, 이를 초과하면 가스가 고갈됩니다. 이는 [다이아몬드 패턴(The Diamond Pattern) (새 탭에서 열림)](https://eips.ethereum.org/EIPS/eip-2535) 을 사용하여 우회할 수 있습니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/#multisig) 다중서명 컨트랙트 ------------------------------------------------------------------------------- 다중서명(Multisig) 컨트랙트는 트랜잭션을 실행하기 위해 여러 개의 유효한 서명이 필요한 스마트 컨트랙트 계정입니다. 이는 상당한 양의 이더나 다른 토큰을 보유한 컨트랙트의 단일 장애점(single point of failure)을 피하는 데 매우 유용합니다. 또한 다중서명은 컨트랙트 실행 및 키 관리 책임을 여러 당사자에게 분산시키고, 단일 개인 키의 분실이 돌이킬 수 없는 자금 손실로 이어지는 것을 방지합니다. 이러한 이유로 다중서명 컨트랙트는 간단한 DAO 거버넌스에 사용될 수 있습니다. 다중서명은 실행을 위해 허용 가능한 M개의 서명 중 N개의 서명(N ≤ M, M > 1)을 요구합니다. `N = 3, M = 5` 및 `N = 4, M = 7`이 일반적으로 사용됩니다. 4/7 다중서명은 7개의 가능한 유효 서명 중 4개가 필요합니다. 즉, 3개의 서명을 분실하더라도 자금을 회수할 수 있습니다. 이 경우, 컨트랙트가 실행되려면 키 보유자의 과반수가 동의하고 서명해야 함을 의미하기도 합니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/#smart-contract-resources) 스마트 컨트랙트 리소스 -------------------------------------------------------------------------------------------------- **오픈제플린 컨트랙트 -** **_안전한 스마트 컨트랙트 개발을 위한 라이브러리입니다._** * [openzeppelin.com/contracts/ (새 탭에서 열림)](https://openzeppelin.com/contracts/) * [GitHub (새 탭에서 열림)](https://github.com/OpenZeppelin/openzeppelin-contracts) * [커뮤니티 포럼 (새 탭에서 열림)](https://forum.openzeppelin.com/c/general/16) [](https://ethereum.org/ko/developers/docs/smart-contracts/#further-reading) 더 읽어보기 ----------------------------------------------------------------------------------- * [코인베이스: 스마트 컨트랙트란 무엇인가요? (새 탭에서 열림)](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract) * [체인링크: 스마트 컨트랙트란 무엇인가요? (새 탭에서 열림)](https://chain.link/education/smart-contracts) * [동영상: 쉽게 설명하는 스마트 컨트랙트 (새 탭에서 열림)](https://youtu.be/ZE2HxTmxfrI) * [Cyfrin Updraft: Web3 학습 및 감사 플랫폼 (새 탭에서 열림)](https://updraft.cyfrin.io/) [](https://ethereum.org/ko/developers/docs/smart-contracts/#tutorials) 튜토리얼: 이더리움의 스마트 컨트랙트 서명(EIP-1271) -------------------------------------------------------------------------------------------------------- * [EIP-1271: 스마트 컨트랙트 서명하기 및 검증](https://ethereum.org/ko/developers/tutorials/eip-1271-smart-contract-signatures/) _– EIP-1271이 스마트 컨트랙트에서 서명을 검증할 수 있게 하는 방법과 Safe 구현에 대한 설명입니다._ --- # Usanjari wa kiambishi awali cha urefu wa kujirudia (RLP) | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/rlp/#main-content) Change page Usanjari wa kiambishi awali cha urefu wa kujirudia (RLP) ======================================================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-structures-and-encoding/rlp/index.md) Kwenye ukurasa huu Usanjari wa Kiambishi Awali cha Urefu wa Kujirudia (RLP) unatumika sana katika wateja wa utekelezaji wa Ethereum. RLP husawazisha hamisho la data kati ya nodi katika umbizo linalotumia nafasi vizuri. Madhumuni ya RLP ni kusimba safu zilizowekwa kiholela za data ya mfumo wa namba mbili (binary), na RLP ndiyo njia kuu ya usimbaji inayotumika kusanjari vipengee katika tabaka la utekelezaji la Ethereum. Madhumuni makuu ya RLP ni kusimba muundo; isipokuwa kwa nambari kamili chanya, RLP hukabidhi usimbaji wa aina mahususi za data (k.m., mifuatano, nambari zinazoelea) kwa itifaki za daraja la juu. Nambari kamili chanya lazima ziwakilishwe katika mfumo wa namba mbili wa kianzia-kikubwa bila sufuri zinazoongoza (hivyo kufanya thamani ya nambari kamili ya sufuri kuwa sawa na safu tupu ya baiti). Nambari kamili chanya zilizotolewa kwenye usanjari zenye sufuri zinazoongoza lazima zichukuliwe kuwa batili na itifaki yoyote ya daraja la juu inayotumia RLP. Maelezo zaidi katika [waraka wa manjano wa Ethereum (Kiambatisho B) (inafunguka katika kichupo kipya)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19) . Ili kutumia RLP kusimba kamusi, fomu mbili za kikanoniki zilizopendekezwa ni: * tumia `[[k1,v1],[k2,v2]...]` na funguo katika mpangilio wa kileksikografia * tumia usimbaji wa kiwango cha juu wa Patricia Tree kama [Ethereum](https://ethereum.org/sw/) inavyofanya [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/rlp/#definition) Ufafanuzi -------------------------------------------------------------------------------------------------- Chaguo la kukokotoa la usimbaji la RLP huchukua kipengee. Kipengee kinafafanuliwa kama ifuatavyo: * mfuatano (yaani, safu ya baiti) ni kipengee * orodha ya vipengee ni kipengee * nambari kamili chanya ni kipengee Kwa mfano, yote yafuatayo ni vipengee: * mfuatano mtupu; * mfuatano ulio na neno "cat"; * orodha iliyo na idadi yoyote ya mifuatano; * na miundo changamano zaidi ya data kama `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`. * nambari `100` Kumbuka kwamba katika muktadha wa ukurasa huu uliosalia, 'mfuatano' unamaanisha "idadi fulani ya baiti za data ya mfumo wa namba mbili"; hakuna usimbaji maalum unaotumika, na hakuna ujuzi kuhusu maudhui ya mifuatano unaodokezwa (isipokuwa kama inavyotakiwa na sheria dhidi ya nambari kamili chanya zisizo za kiwango cha chini). Usimbaji wa RLP unafafanuliwa kama ifuatavyo: * Kwa nambari kamili chanya, inabadilishwa kuwa safu fupi zaidi ya baiti ambayo tafsiri yake ya kianzia-kikubwa ni nambari kamili, na kisha kusimbwa kama mfuatano kulingana na sheria zilizo hapa chini. * Kwa baiti moja ambayo thamani yake iko katika masafa ya `[0x00, 0x7f]` (desimali `[0, 127]`), baiti hiyo ni usimbaji wake wenyewe wa RLP. * Vinginevyo, ikiwa mfuatano una urefu wa baiti 0-55, usimbaji wa RLP unajumuisha baiti moja yenye thamani ya **0x80** (des. 128) pamoja na urefu wa mfuatano unaofuatwa na mfuatano huo. Masafa ya baiti ya kwanza kwa hivyo ni `[0x80, 0xb7]` (des. `[128, 183]`). * Ikiwa mfuatano una urefu wa zaidi ya baiti 55, usimbaji wa RLP unajumuisha baiti moja yenye thamani ya **0xb7** (des. 183) pamoja na urefu katika baiti wa urefu wa mfuatano katika mfumo wa namba mbili, ikifuatiwa na urefu wa mfuatano, ikifuatiwa na mfuatano huo. Kwa mfano, mfuatano wenye urefu wa baiti 1024 ungesimbwa kama `\xb9\x04\x00` (des. `185, 4, 0`) ikifuatiwa na mfuatano huo. Hapa, `0xb9` (183 + 2 = 185) kama baiti ya kwanza, ikifuatiwa na baiti 2 `0x0400` (des. 1024) zinazoonyesha urefu wa mfuatano halisi. Masafa ya baiti ya kwanza kwa hivyo ni `[0xb8, 0xbf]` (des. `[184, 191]`). * Ikiwa mfuatano una urefu wa baiti 2^64, au zaidi, huenda usisimbwe. * Ikiwa jumla ya mzigo wa data wa orodha (yaani, urefu wa pamoja wa vipengee vyake vyote vinavyosimbwa na RLP) una urefu wa baiti 0-55, usimbaji wa RLP unajumuisha baiti moja yenye thamani ya **0xc0** pamoja na urefu wa mzigo wa data ikifuatiwa na muunganisho wa usimbaji wa RLP wa vipengee hivyo. Masafa ya baiti ya kwanza kwa hivyo ni `[0xc0, 0xf7]` (des. `[192, 247]`). * Ikiwa jumla ya mzigo wa data wa orodha una urefu wa zaidi ya baiti 55, usimbaji wa RLP unajumuisha baiti moja yenye thamani ya **0xf7** pamoja na urefu katika baiti wa urefu wa mzigo wa data katika mfumo wa namba mbili, ikifuatiwa na urefu wa mzigo wa data, ikifuatiwa na muunganisho wa usimbaji wa RLP wa vipengee hivyo. Masafa ya baiti ya kwanza kwa hivyo ni `[0xf8, 0xff]` (des. `[248, 255]`). Kwa ufupi: | Masafa | Baiti 1 | Baiti 2 | ... | Baiti 9 | Baiti 10 | Maana | | --- | --- | --- | --- | --- | --- | --- | | `0x00-0x7f` | `0ppppppp` | | | | | mfuatano wa baiti moja | | `0x80-0xb7` | `10nnnnnn` | `pppppppp` | `...` | | | mfuatano mfupi (baiti 0-55) | | `0xb8-0xbf` | `10111NNN` | `nnnnnnnn` | `...` | `nnnnnnnn`/`pppppppp` | `pppppppp` | mfuatano mrefu, baiti N+1 za urefu, kisha mzigo wa data | | `0xc0-0xf7` | `11nnnnnn` | `pppppppp` | `...` | | | orodha fupi (baiti 0-55) | | `0xf8-0xff` | `11111NNN` | `nnnnnnnn` | `...` | `nnnnnnnn`/`pppppppp` | `pppppppp` | orodha ndefu, baiti N+1 za urefu, kisha mzigo wa data | * `p` = mzigo wa data * `n` = urefu (idadi ya baiti za mzigo wa data) * `N` = urekebishaji wa urefu-wa-urefu (baiti N+1 za `n` zinafuata) Katika msimbo, hii ni: def rlp_encode(input): if isinstance(input,str): if len(input) == 1 and ord(input) < 0x80: return input return encode_length(len(input), 0x80) + input elif isinstance(input, list): output = '' for item in input: output += rlp_encode(item) return encode_length(len(output), 0xc0) + output def encode_length(L, offset): if L < 56: return chr(L + offset) elif L < 256**8: BL = to_binary(L) return chr(len(BL) + offset + 55) + BL raise Exception("input too long") def to_binary(x): if x == 0: return '' return to_binary(int(x / 256)) + chr(x % 256) NakiliPython Onyesha yote (23) [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/rlp/#examples) Mifano --------------------------------------------------------------------------------------------- * mfuatano "dog" = \[ 0x83, 'd', 'o', 'g' \] * orodha \[ "cat", "dog" \] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` * mfuatano mtupu ('null') = `[ 0x80 ]` * orodha tupu = `[ 0xc0 ]` * nambari kamili 0 = `[ 0x80 ]` * baiti '\\x00' = `[ 0x00 ]` * baiti '\\x0f' = `[ 0x0f ]` * baiti '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]` * [uwakilishi wa kinadharia wa seti (inafunguka katika kichupo kipya)](https://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) wa tatu, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` * mfuatano "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/rlp/#rlp-decoding) Usimbuaji wa RLP ----------------------------------------------------------------------------------------------------------- Kulingana na sheria na mchakato wa usimbaji wa RLP, ingizo la usimbuaji wa RLP linachukuliwa kama safu ya data ya mfumo wa namba mbili. Mchakato wa usimbuaji wa RLP ni kama ifuatavyo: 1. kulingana na baiti ya kwanza (yaani, kiambishi awali) cha data inayoingizwa na kusimbua aina ya data, urefu wa data halisi na urekebishaji; 2. kulingana na aina na urekebishaji wa data, simbua data ipasavyo, ukiheshimu sheria ya usimbaji wa kiwango cha chini kwa nambari kamili chanya; 3. endelea kusimbua ingizo lililosalia; Miongoni mwao, sheria za kusimbua aina za data na urekebishaji ni kama ifuatavyo: 1. data ni mfuatano ikiwa masafa ya baiti ya kwanza (yaani, kiambishi awali) ni \[0x00, 0x7f\], na mfuatano ni baiti ya kwanza yenyewe haswa; 2. data ni mfuatano ikiwa masafa ya baiti ya kwanza ni \[0x80, 0xb7\], na mfuatano ambao urefu wake ni sawa na baiti ya kwanza ukiondoa 0x80 unafuata baiti ya kwanza; 3. data ni mfuatano ikiwa masafa ya baiti ya kwanza ni \[0xb8, 0xbf\], na urefu wa mfuatano ambao urefu wake katika baiti ni sawa na baiti ya kwanza ukiondoa 0xb7 unafuata baiti ya kwanza, na mfuatano unafuata urefu wa mfuatano; 4. data ni orodha ikiwa masafa ya baiti ya kwanza ni \[0xc0, 0xf7\], na muunganisho wa usimbaji wa RLP wa vipengee vyote vya orodha ambayo jumla ya mzigo wa data ni sawa na baiti ya kwanza ukiondoa 0xc0 unafuata baiti ya kwanza; 5. data ni orodha ikiwa masafa ya baiti ya kwanza ni \[0xf8, 0xff\], na jumla ya mzigo wa data wa orodha ambayo urefu wake ni sawa na baiti ya kwanza ukiondoa 0xf7 unafuata baiti ya kwanza, na muunganisho wa usimbaji wa RLP wa vipengee vyote vya orodha unafuata jumla ya mzigo wa data wa orodha; Katika msimbo, hii ni: def rlp_decode(input): if len(input) == 0: return output = '' (offset, dataLen, type) = decode_length(input) if type is str: output = instantiate_str(substr(input, offset, dataLen)) elif type is list: output = instantiate_list(substr(input, offset, dataLen)) output += rlp_decode(substr(input, offset + dataLen)) return output def decode_length(input): length = len(input) if length == 0: raise Exception("input is null") prefix = ord(input[0]) if prefix <= 0x7f: return (0, 1, str) elif prefix <= 0xb7 and length > prefix - 0x80: strLen = prefix - 0x80 return (1, strLen, str) elif prefix <= 0xbf and length > prefix - 0xb7 and length > prefix - 0xb7 + to_integer(substr(input, 1, prefix - 0xb7)): lenOfStrLen = prefix - 0xb7 strLen = to_integer(substr(input, 1, lenOfStrLen)) return (1 + lenOfStrLen, strLen, str) elif prefix <= 0xf7 and length > prefix - 0xc0: listLen = prefix - 0xc0; return (1, listLen, list) elif prefix <= 0xff and length > prefix - 0xf7 and length > prefix - 0xf7 + to_integer(substr(input, 1, prefix - 0xf7)): lenOfListLen = prefix - 0xf7 listLen = to_integer(substr(input, 1, lenOfListLen)) return (1 + lenOfListLen, listLen, list) raise Exception("input does not conform to RLP encoding form") def to_integer(b): length = len(b) if length == 0: raise Exception("input is null") elif length == 1: return ord(b[0]) return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256 NakiliPython Onyesha yote (42) [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/rlp/#further-reading) Usomaji zaidi ----------------------------------------------------------------------------------------------------------- * [RLP katika Ethereum (inafunguka katika kichupo kipya)](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) * [Ethereum kiufundi: RLP (inafunguka katika kichupo kipya)](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) * [Coglio, A. (2020). Kiambishi Awali cha Urefu wa Kujirudia cha Ethereum katika ACL2. arXiv preprint arXiv:2009.13769. (inafunguka katika kichupo kipya)](https://arxiv.org/abs/2009.13769) [](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/rlp/#related-topics) Mada zinazohusiana --------------------------------------------------------------------------------------------------------------- * [Patricia merkle trie](https://ethereum.org/sw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) --- # シンプル・シリアライズ (Simple serialize) | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/ssz/#main-content) Change page シンプル・シリアライズ (Simple serialize) ============================== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-structures-and-encoding/ssz/index.md) このページの内容 **シンプル・シリアライズ (SSZ)** は、ビーコン・チェーンで使用されるシリアライゼーション手法です。ピア・ディスカバリー・プロトコルを除き、コンセンサス・レイヤー全体で、実行レイヤーで使用されるRLPシリアライゼーションに代わるものです。RLPシリアライゼーションの詳細については、[再帰的長さプレフィックス (RLP)](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/rlp/) を参照してください。SSZは、決定論的であり、効率的にマークル化 (Merkleize) できるように設計されています。SSZは、シリアライゼーション・スキームと、シリアライズされたデータ構造で効率的に機能するように設計されたマークル化スキームの2つのコンポーネントで構成されていると考えることができます。 [](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/ssz/#how-does-ssz-work) SSZの仕組み ------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/ssz/#serialization) シリアライゼーション SSZは自己記述型ではないシリアライゼーション・スキームであり、事前に把握しておく必要があるスキーマに依存しています。SSZシリアライゼーションの目的は、任意の複雑さを持つオブジェクトをバイト列として表現することです。これは「基本型 (basic types)」にとっては非常にシンプルなプロセスです。要素は単に16進数のバイトに変換されます。基本型には以下が含まれます。 * 符号なし整数 * ブール値 複雑な「複合 (composite)」型の場合、複合型には異なる型や異なるサイズ、あるいはその両方を持つ複数の要素が含まれるため、シリアライゼーションはより複雑になります。これらのオブジェクトがすべて固定長である場合 (つまり、実際の値に関係なく要素のサイズが常に一定である場合)、シリアライゼーションは単に複合型内の各要素をリトルエンディアンのバイト列に順序付けて変換するだけです。これらのバイト列は結合されます。シリアライズされたオブジェクトは、デシリアライズされたオブジェクトに現れるのと同じ順序で、固定長要素のバイトリスト表現を持ちます。 可変長の型の場合、シリアライズされたオブジェクト内のその要素の位置にある実際のデータは、「オフセット (offset)」値に置き換えられます。実際のデータは、シリアライズされたオブジェクトの最後にあるヒープに追加されます。オフセット値は、ヒープ内の実際のデータの開始位置を示すインデックスであり、関連するバイトへのポインタとして機能します。 以下の例は、固定長要素と可変長要素の両方を持つコンテナでオフセットがどのように機能するかを示しています。 struct Dummy { number1: u64, number2: u64, vector: Vec, number3: u64 } dummy = Dummy{ number1: 37, number2: 55, vector: vec![1,2,3,4], number3: 22, } serialized = ssz.serialize(dummy) コピー すべて表示 (19) `serialized` は次のような構造になります (ここではわかりやすくするために4ビットにパディングしていますが、実際には32ビットにパディングされ、`int` 表現を維持しています)。 [37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4] ------------ ----------- ----------- ----------- ---------- | | | | | number1 number2 vectorの number 3 vectorの オフセット 値 コピー わかりやすくするために行に分割すると、次のようになります。 [\ 37, 0, 0, 0, # `number1` のリトルエンディアン・エンコーディング。\ 55, 0, 0, 0, # `number2` のリトルエンディアン・エンコーディング。\ 16, 0, 0, 0, # `vector` の値が始まる場所を示す「オフセット」 (リトルエンディアンの16)。\ 22, 0, 0, 0, # `number3` のリトルエンディアン・エンコーディング。\ 1, 2, 3, 4, # `vector` の実際の値。\ ] コピー これもまだ簡略化されたものです。上記の図式にある整数とゼロは、実際には次のようなバイトリストとして保存されます。 [\ 10100101000000000000000000000000 # `number1` のリトルエンディアン・エンコーディング\ 10110111000000000000000000000000 # `number2` のリトルエンディアン・エンコーディング。\ 10010000000000000000000000000000 # `vector` の値が始まる場所を示す「オフセット」 (リトルエンディアンの16)。\ 10010110000000000000000000000000 # `number3` のリトルエンディアン・エンコーディング。\ 10000001100000101000001110000100 # `bytes` フィールドの実際の値。\ ] コピー したがって、可変長の型の実際の値は、シリアライズされたオブジェクトの最後にあるヒープに保存され、そのオフセットは順序付けられたフィールドリストの正しい位置に保存されます。 また、シリアライゼーション時に長さの上限を追加し、デシリアライゼーション時に削除する必要がある `BitList` 型など、特別な処理を必要とする特殊なケースもいくつかあります。詳細については、[SSZ仕様 （新しいタブで開きます）](https://github.com/ethereum/consensus-specs/blob/master/ssz/simple-serialize.md) を参照してください。 ### [](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/ssz/#deserialization) デシリアライゼーション このオブジェクトをデシリアライズするには、**スキーマ**が必要です。スキーマはシリアライズされたデータの正確なレイアウトを定義しており、各特定の要素をバイト列から、正しい型、値、サイズ、位置を持つ意味のあるオブジェクトへとデシリアライズできるようにします。デシリアライザに対して、どの値が実際の値で、どの値がオフセットであるかを指示するのはスキーマです。オブジェクトがシリアライズされるとすべてのフィールド名は消滅しますが、デシリアライゼーション時にスキーマに従って再インスタンス化されます。 [](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/ssz/#merkleization) マークル化 ------------------------------------------------------------------------------------------------- このSSZでシリアライズされたオブジェクトは、その後マークル化 (merkleized) することができます。つまり、同じデータのマークル・ツリー表現に変換されます。まず、シリアライズされたオブジェクト内の32バイトのチャンクの数が決定されます。これらがツリーの「葉 (leaves)」になります。葉を一緒にハッシュ化して最終的に単一のハッシュ・ツリー・ルート (hash-tree-root) を生成できるように、葉の総数は2の累乗でなければなりません。自然にそうならない場合は、32バイトのゼロを含む追加の葉が追加されます。図で表すと次のようになります。 ハッシュ・ツリー・ルート / \ / \ / \ / \ 葉1と2の 葉3と4の ハッシュ ハッシュ / \ / \ / \ / \ / \ / \ 葉1 葉2 葉3 葉4 コピー すべて表示 (11) 上記の例のように、ツリーの葉が自然に均等に分布しない場合もあります。たとえば、葉4が複数の要素を持つコンテナであり、マークル・ツリーに追加の「深さ (depth)」を追加する必要があり、不均等なツリーが作成される可能性があります。 これらのツリー要素を葉X、ノードXなどと呼ぶ代わりに、ルート = 1から始まり、各レベルに沿って左から右に数える一般化インデックス (generalized indices) を与えることができます。これが上記で説明した一般化インデックスです。シリアライズされたリスト内の各要素は、`2**depth + idx` に等しい一般化インデックスを持ちます。ここで、idxはシリアライズされたオブジェクト内のゼロから始まるインデックス位置であり、深さ (depth) はマークル・ツリーのレベル数です。これは、要素 (葉) の数の2を底とする対数として決定できます。 [](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/ssz/#generalized-indices) 一般化インデックス ----------------------------------------------------------------------------------------------------------- 一般化インデックスは、バイナリ・マークル・ツリー内のノードを表す整数であり、各ノードは `2 ** depth + index in row` という一般化インデックスを持ちます。 1 --depth = 0 2**0 + 0 = 1 2 3 --depth = 1 2**1 + 0 = 2, 2**1+1 = 3 4 5 6 7 --depth = 2 2**2 + 0 = 4, 2**2 + 1 = 5... コピー この表現により、マークル・ツリー内の各データに対するノード・インデックスが得られます。 [](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/ssz/#multiproofs) マルチプルーフ ------------------------------------------------------------------------------------------------- 特定の要素を表す一般化インデックスのリストを提供することで、ハッシュ・ツリー・ルートに対してそれを検証できます。このルートは、私たちが受け入れている現実のバージョンです。提供されたデータは、マークル・ツリーの正しい場所 (一般化インデックスによって決定される) に挿入し、ルートが一定であることを確認することで、その現実に対して検証できます。特定の一般化インデックスのセットの内容を検証するために必要なノードの最小セットを計算する方法を示す関数が、仕様の[こちら （新しいタブで開きます）](https://github.com/ethereum/consensus-specs/blob/master/ssz/merkle-proofs.md#merkle-multiproofs) にあります。 たとえば、以下のツリーのインデックス9のデータを検証するには、インデックス8、9、5、3、1のデータのハッシュが必要です。 (8,9) のハッシュはハッシュ (4) と等しくなるはずです。ハッシュ (4) は5とハッシュ化されて2を生成し、2は3とハッシュ化されてツリー・ルート1を生成します。9に誤ったデータが提供された場合、ルートが変更されます。これを検出し、ブランチの検証に失敗します。 * = 証明の生成に必要なデータ 1* 2 3* 4 5* 6 7 8* 9* 10 11 12 13 14 15 コピー [](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/ssz/#further-reading) 参考文献 -------------------------------------------------------------------------------------------------- * [Upgrading Ethereum: SSZ （新しいタブで開きます）](https://eth2book.info/altair/part2/building_blocks/ssz) * [Upgrading Ethereum: Merkleization （新しいタブで開きます）](https://eth2book.info/altair/part2/building_blocks/merkleization) * [SSZの実装 （新しいタブで開きます）](https://github.com/ethereum/consensus-specs/issues/2138) * [SSZ計算機 （新しいタブで開きます）](https://simpleserialize.com/) --- # ERC-777 토큰 표준 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/standards/tokens/erc-777/#main-content) Change page ERC-777 토큰 표준 ============= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/tokens/erc-777/index.md) 이 페이지의 내용 [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-777/#warning) 경고 -------------------------------------------------------------------------------- **ERC-777은 [다양한 형태의 공격에 취약 (새 탭에서 열림)](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2620) 하기 때문에 제대로 구현하기 어렵습니다. 대신 [ERC-20](https://ethereum.org/ko/developers/docs/standards/tokens/erc-20/) 을 사용하는 것을 권장합니다.** 이 페이지는 역사적 기록 보관용으로 남겨두었습니다. [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-777/#introduction) 소개? -------------------------------------------------------------------------------------- ERC-777은 기존 [ERC-20](https://ethereum.org/ko/developers/docs/standards/tokens/erc-20/) 표준을 개선한 대체 가능 토큰 표준입니다. [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-777/#prerequisites) 전제 조건 ----------------------------------------------------------------------------------------- 이 페이지를 더 잘 이해하려면 먼저 [ERC-20](https://ethereum.org/ko/developers/docs/standards/tokens/erc-20/) 에 대해 읽어보는 것을 권장합니다. [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-777/#-erc-777-vs-erc-20) ERC-777은 ERC-20에 비해 어떤 개선 사항을 제안하나요? ----------------------------------------------------------------------------------------------------------------------------- ERC-777은 ERC-20에 비해 다음과 같은 개선 사항을 제공합니다. ### [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-777/#hooks) 훅 훅(Hook)은 스마트 컨트랙트 코드에 기술된 함수입니다. 훅은 컨트랙트를 통해 토큰을 보내거나 받을 때 호출됩니다. 이를 통해 스마트 컨트랙트는 들어오거나 나가는 토큰에 반응할 수 있습니다. 이러한 훅은 [ERC-1820 (새 탭에서 열림)](https://eips.ethereum.org/EIPS/eip-1820) 표준을 사용하여 등록되고 발견됩니다. #### [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-777/#why-are-hooks-great) 훅이 좋은 이유는 무엇인가요? 1. 훅을 사용하면 단일 트랜잭션으로 컨트랙트에 토큰을 전송하고 컨트랙트에 알릴 수 있습니다. 이는 이를 달성하기 위해 이중 호출(`approve`/`transferFrom`)이 필요한 [ERC-20 (새 탭에서 열림)](https://eips.ethereum.org/EIPS/eip-20) 과는 다릅니다. 2. 훅을 등록하지 않은 컨트랙트는 ERC-777과 호환되지 않습니다. 수신 컨트랙트가 훅을 등록하지 않은 경우 송신 컨트랙트는 트랜잭션을 중단합니다. 이는 ERC-777을 지원하지 않는 스마트 컨트랙트로의 우발적인 전송을 방지합니다. 3. 훅은 트랜잭션을 거부할 수 있습니다. ### [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-777/#decimals) 소수점 이 표준은 또한 ERC-20에서 발생했던 `decimals`와 관련된 혼란을 해결합니다. 이러한 명확성은 개발자 경험을 향상시킵니다. ### [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-777/#backwards-compatibility-with-erc-20) ERC-20과의 하위 호환성 ERC-777 컨트랙트는 마치 ERC-20 컨트랙트인 것처럼 상호 작용할 수 있습니다. [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-777/#further-reading) 더 읽어보기 -------------------------------------------------------------------------------------------- [EIP-777: 토큰 표준 (새 탭에서 열림)](https://eips.ethereum.org/EIPS/eip-777) --- # Web3 비밀 저장소 정의 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/web3-secret-storage/#main-content) Change page Web3 비밀 저장소 정의 ============== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md) 이 페이지의 내용 이더리움에서 앱이 작동하도록 하려면 Web3.js 라이브러리에서 제공하는 web3 객체를 사용할 수 있습니다. 내부적으로는 RPC 호출을 통해 로컬 노드와 통신합니다. [web3 (새 탭에서 열림)](https://github.com/ethereum/web3.js/) 는 RPC 계층을 노출하는 모든 이더리움 노드와 작동합니다. `web3`에는 `eth` 객체인 web3.eth가 포함되어 있습니다. var fs = require("fs") var recognizer = require("ethereum-keyfile-recognizer") fs.readFile("keyfile.json", (err, data) => { var json = JSON.parse(data) var result = recognizer(json) }) /** 결과 * [ 'web3', 3 ] Web3 (v3) 키 파일 * [ 'ethersale', undefined ] Ethersale 키 파일 * null 유효하지 않은 키 파일 */ 복사JS 모두 보기 (13) 이 문서는 Web3 비밀 저장소 정의의 **버전 3**을 설명합니다. [](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/web3-secret-storage/#definition) 정의 ----------------------------------------------------------------------------------------------------------- 파일의 실제 인코딩 및 디코딩은 암호화 알고리즘이 더 이상 AES-128-CBC로 고정되지 않는다는 점(이제 AES-128-CTR이 최소 요구 사항임)을 제외하면 버전 1과 크게 다르지 않습니다. 파생된 키의 왼쪽에서 두 번째 16바이트와 전체 `ciphertext`를 연결한 값의 SHA3(케착-256)로 주어지는 `mac`를 제외하고, 대부분의 의미/알고리즘은 버전 1과 유사합니다. 비밀 키 파일은 `~/.web3/keystore`(유닉스 계열 시스템의 경우) 및 `~/AppData/Web3/keystore`(Windows의 경우)에 직접 저장됩니다. 파일 이름은 자유롭게 지정할 수 있지만, `.json` 형식을 사용하는 것이 좋은 관례입니다. 여기서 ``는 비밀 키에 부여된 128비트 UUID(비밀 키 주소에 대한 프라이버시 보존 프록시)입니다. 이러한 모든 파일에는 연결된 비밀번호가 있습니다. 주어진 `.json` 파일의 비밀 키를 파생하려면 먼저 파일의 암호화 키를 파생해야 합니다. 이는 파일의 비밀번호를 가져와 `kdf` 키에 설명된 키 파생 함수(KDF)를 통과시킴으로써 수행됩니다. KDF 함수에 대한 KDF 종속 정적 및 동적 매개변수는 `kdfparams` 키에 설명되어 있습니다. PBKDF2는 최소 규정을 준수하는 모든 구현에서 지원되어야 하며, 다음과 같이 표시됩니다. * `kdf`: `pbkdf2` PBKDF2의 경우 kdfparams에는 다음이 포함됩니다. * `prf`: `hmac-sha256`이어야 합니다(향후 확장될 수 있음). * `c`: 반복 횟수. * `salt`: PBKDF에 전달되는 솔트(salt). * `dklen`: 파생된 키의 길이. 32 이상이어야 합니다. 파일의 키가 파생되면 MAC 파생을 통해 이를 검증해야 합니다. MAC은 파생된 키의 왼쪽에서 두 번째 16바이트와 `ciphertext` 키의 내용을 연결하여 형성된 바이트 배열의 SHA3(케착-256) 해시로 계산되어야 합니다. 즉, 다음과 같습니다. KECCAK(DK[16..31] ++ ) 복사JS (여기서 `++`는 연결 연산자입니다) 이 값은 `mac` 키의 내용과 비교되어야 합니다. 값이 다를 경우 대체 비밀번호를 요청하거나(또는 작업을 취소해야) 합니다. 파일의 키가 검증된 후, 암호문(파일의 `ciphertext` 키)은 `cipher` 키에 지정되고 `cipherparams` 키를 통해 매개변수화된 대칭 암호화 알고리즘을 사용하여 복호화될 수 있습니다. 파생된 키 크기와 알고리즘의 키 크기가 일치하지 않는 경우, 0으로 채워진 파생 키의 가장 오른쪽 바이트를 알고리즘의 키로 사용해야 합니다. 최소 규정을 준수하는 모든 구현은 AES-128-CTR 알고리즘을 지원해야 하며, 다음과 같이 표시됩니다. * `cipher: aes-128-ctr` 이 암호는 cipherparams 키에 대한 키로 주어지는 다음 매개변수를 사용합니다. * `iv`: 암호화를 위한 128비트 초기화 벡터(IV). 암호화 키는 파생된 키의 가장 왼쪽 16바이트입니다. 즉, `DK[0..15]`입니다. 비밀 키의 생성/암호화는 기본적으로 이 지침의 역순이어야 합니다. `uuid`, `salt` 및 `iv`가 실제로 무작위인지 확인하세요. 버전의 '하드' 식별자 역할을 해야 하는 `version` 필드 외에도, 구현에서는 `minorversion`를 사용하여 형식에 대한 작고 호환성을 깨지 않는 변경 사항을 추적할 수 있습니다. [](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/web3-secret-storage/#test-vectors) 테스트 벡터 ----------------------------------------------------------------------------------------------------------------- 세부 정보: * `Address`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b` * `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67` * `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6` * `Password`: `testpassword` * `Secret`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d` ### [](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/web3-secret-storage/#pbkdf2-sha-256) PBKDF2-SHA-256 `AES-128-CTR` 및 `PBKDF2-SHA-256`를 사용한 테스트 벡터: `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`의 파일 내용: { "crypto": { "cipher": "aes-128-ctr", "cipherparams": { "iv": "6087dab2f9fdbbfaddc31a909735c1e6" }, "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46", "kdf": "pbkdf2", "kdfparams": { "c": 262144, "dklen": 32, "prf": "hmac-sha256", "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd" }, "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2" }, "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", "version": 3 } 복사JSON 모두 보기 (19) **중간값(Intermediates)**: `Derived key`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` `MAC Body`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` `MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` `Cipher key`: `f06d69cdc7da0faffb1008270bca38f5` ### [](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/web3-secret-storage/#scrypt) Scrypt AES-128-CTR 및 Scrypt를 사용한 테스트 벡터: { "crypto": { "cipher": "aes-128-ctr", "cipherparams": { "iv": "740770fce12ce862af21264dab25f1da" }, "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2", "kdf": "scrypt", "kdfparams": { "dklen": 32, "n": 262144, "p": 1, "r": 8, "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034" }, "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c" }, "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", "version": 3 } 복사JSON 모두 보기 (20) **중간값(Intermediates)**: `Derived key`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` `MAC Body`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` `MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` `Cipher key`: `7446f59ecc301d2d79bc3302650d8a5c` [](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/web3-secret-storage/#alterations-from-v2) 버전 1에서의 변경 사항 ------------------------------------------------------------------------------------------------------------------------------- 이 버전은 [여기 (새 탭에서 열림)](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst) 에 게시된 버전 1의 몇 가지 불일치를 수정합니다. 간단히 요약하면 다음과 같습니다. * 대소문자 사용이 부적절하고 일관성이 없습니다(scrypt는 소문자, Kdf는 혼합 대소문자, MAC은 대문자). * 주소는 불필요하며 프라이버시를 침해합니다. * `Salt`는 본질적으로 키 파생 함수의 매개변수이므로 일반적인 암호화가 아닌 해당 함수와 연관되어야 합니다. * _SaltLen_은 불필요합니다(Salt에서 파생하면 됨). * 키 파생 함수가 주어졌음에도 암호화 알고리즘이 하드 코딩되어 지정되었습니다. * `Version`는 본질적으로 숫자형이지만 문자열로 되어 있습니다(문자열을 사용하면 구조화된 버전 관리가 가능하지만, 거의 변경되지 않는 구성 파일 형식에서는 범위를 벗어난 것으로 간주될 수 있습니다). * `KDF`와 `cipher`는 개념적으로 형제 관계이지만 다르게 구성되어 있습니다. * `MAC`는 공백을 무시하는 데이터 조각을 통해 계산됩니다(!) 이전에 링크된 페이지에 제공된 예제와 기능적으로 동일한 다음 파일을 제공하기 위해 형식이 변경되었습니다. { "crypto": { "cipher": "aes-128-cbc", "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b", "cipherparams": { "iv": "16d67ba0ce5a339ff2f07951253e6ba8" }, "kdf": "scrypt", "kdfparams": { "dklen": 32, "n": 262144, "p": 1, "r": 8, "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91" }, "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd", "version": 1 }, "id": "0498f19a-59db-4d54-ac95-33901b4f1870", "version": 2 } 복사JSON 모두 보기 (21) [](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/web3-secret-storage/#alterations-from-v2-2) 버전 2에서의 변경 사항 --------------------------------------------------------------------------------------------------------------------------------- 버전 2는 여러 버그가 있는 초기 C++ 구현이었습니다. 모든 필수 요소는 변경되지 않고 그대로 유지됩니다. --- # イーサの技術入門 | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/intro-to-ether/#main-content) Change page イーサの技術入門 ======== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/intro-to-ether/index.md) このページの内容 [](https://ethereum.org/ja/developers/docs/intro-to-ether/#prerequisites) 前提条件 ------------------------------------------------------------------------------ このページをよりよく理解するために、まずは[イーサリアムの概要](https://ethereum.org/ja/developers/docs/intro-to-ethereum/) を読むことをお勧めします。 [](https://ethereum.org/ja/developers/docs/intro-to-ether/#what-is-a-cryptocurrency) 暗号資産とは？ -------------------------------------------------------------------------------------------- 暗号資産とは、ブロックチェーンベースの台帳によって保護された交換媒体です。 交換媒体とは、商品やサービスの支払いとして広く受け入れられているもののことであり、台帳とはトランザクションを記録するデータストアのことです。ブロックチェーン技術により、ユーザーは台帳を維持するための信頼できる第三者に依存することなく、台帳上でトランザクションを行うことができます。 最初の暗号資産は、サトシ・ナカモトによって作成されたビットコインでした。2009年のビットコインのリリース以来、多くの異なるブロックチェーン上で何千もの暗号資産が作成されてきました。 [](https://ethereum.org/ja/developers/docs/intro-to-ether/#what-is-ether) イーサとは？ -------------------------------------------------------------------------------- **イーサ (ETH)** は、イーサリアム・ネットワーク上の多くの用途で使用される暗号資産です。基本的には、トランザクション手数料の支払いとして受け入れられる唯一の形式であり、[マージ](https://ethereum.org/ja/roadmap/merge/) 以降、メインネットでブロックを検証および提案するためにはイーサが必要になります。また、イーサは[分散型金融 (DeFi)](https://ethereum.org/ja/defi/) のレンディング市場における主要な担保の形式として、NFTマーケットプレイスでの計算単位として、サービス提供や現実世界の商品販売で得られる支払いとしてなど、様々な用途で使用されています。 イーサリアムを使用すると、開発者は[**分散型アプリケーション (dapp)**](https://ethereum.org/ja/developers/docs/dapps/) を作成でき、これらはすべてコンピューティング能力のプールを共有します。この共有プールは有限であるため、イーサリアムは誰がそれを使用できるかを決定するメカニズムを必要とします。そうしないと、dappが誤って、または悪意を持ってすべてのネットワークリソースを消費し、他のユーザーのアクセスをブロックしてしまう可能性があります。 暗号資産であるイーサは、イーサリアムのコンピューティング能力の価格設定メカニズムをサポートしています。ユーザーがトランザクションを行いたい場合、そのトランザクションをブロックチェーン上で認識させるためにイーサを支払う必要があります。これらの使用コストは[ガス代](https://ethereum.org/ja/developers/docs/gas/) として知られており、ガス代はトランザクションを実行するために必要なコンピューティング能力の量と、その時点でのネットワーク全体のコンピューティング能力に対する需要によって異なります。 したがって、悪意のあるdappが無限ループを送信したとしても、トランザクションは最終的にイーサを使い果たして終了し、ネットワークは正常な状態に戻ることができます。 イーサリアムとイーサを[混同することはよくあります （新しいタブで開きます）](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845) 。人々が「イーサリアムの価格」に言及するとき、それはイーサの価格を説明しています。 [](https://ethereum.org/ja/developers/docs/intro-to-ether/#minting-ether) イーサのミンティング ------------------------------------------------------------------------------------ ミンティングとは、イーサリアムの台帳上に新しいイーサが作成されるプロセスのことです。基盤となるイーサリアムのプロトコルが新しいイーサを作成するため、ユーザーがイーサを作成することはできません。 イーサは、提案された各ブロックに対する報酬として、またコンセンサス到達に関連する他のバリデータ活動に対して各エポックのチェックポイントでミントされます。発行される総額は、バリデータの数と、彼らがステークしたイーサの量によって異なります。この総発行量は、すべてのバリデータが誠実でオンラインであるという理想的なケースではバリデータ間で均等に分割されますが、現実にはバリデータのパフォーマンスに基づいて変動します。総発行量の約1/8はブロック・プロポーザーに支払われ、残りは他のバリデータに分配されます。ブロック・プロポーザーはトランザクション手数料やMEV関連の収入からのチップも受け取りますが、これらはリサイクルされたイーサから来るものであり、新規発行ではありません。 [](https://ethereum.org/ja/developers/docs/intro-to-ether/#burning-ether) イーサのバーン --------------------------------------------------------------------------------- ブロック報酬を通じてイーサを作成するだけでなく、「バーン」と呼ばれるプロセスを通じてイーサを破棄することもできます。イーサがバーンされると、永久に流通から排除されます。 イーサのバーンは、イーサリアム上のすべてのトランザクションで発生します。ユーザーがトランザクションの支払いを行うと、トランザクションの需要に応じてネットワークによって設定された基本料金が破棄されます。これは、可変ブロックサイズと最大ガス代と相まって、イーサリアムでのトランザクション手数料の見積もりを簡素化します。ネットワークの需要が高い場合、[ブロック （新しいタブで開きます）](https://eth.blockscout.com/block/22580057) はミントするよりも多くのイーサをバーンする可能性があり、事実上イーサの発行を相殺します。 基本料金をバーンすることで、ブロック生成者がトランザクションを操作する能力が妨げられます。たとえば、ブロック生成者が基本料金を受け取った場合、自身のトランザクションを無料で含め、他のすべてのユーザーの基本料金を引き上げることができます。あるいは、一部のユーザーにオフチェーンで基本料金を返金し、より不透明で複雑なトランザクション手数料市場につながる可能性もあります。 [](https://ethereum.org/ja/developers/docs/intro-to-ether/#denominations) イーサの単位 -------------------------------------------------------------------------------- イーサリアム上の多くのトランザクションの価値は小さいため、イーサにはより小さな計算単位として参照できるいくつかの単位があります。これらの単位のうち、WeiとGweiは特に重要です。 Weiはイーサの最小単位であり、その結果、[イーサリアム・イエローペーパー （新しいタブで開きます）](https://ethereum.github.io/yellowpaper/paper.pdf) などの多くの技術的な実装では、すべての計算の基準をWeiとしています。 Gweiはgiga-weiの略で、イーサリアムのガスコストを表すためによく使用されます。 | 単位 | イーサでの値 | 一般的な用途 | | --- | --- | --- | | Wei | 10\-18 | 技術的な実装 | | Gwei | 10\-9 | 人間が読みやすいガス代 | [](https://ethereum.org/ja/developers/docs/intro-to-ether/#transferring-ether) イーサの送金 ------------------------------------------------------------------------------------- イーサリアム上の各トランザクションには`value`フィールドが含まれており、送信者のアドレスから受信者のアドレスへ送るイーサの量をWei単位で指定します。 受信者のアドレスが[スマート・コントラクト](https://ethereum.org/ja/developers/docs/smart-contracts/) である場合、この送金されたイーサは、スマート・コントラクトがコードを実行する際のガス代の支払いに使用されることがあります。 [トランザクションの詳細](https://ethereum.org/ja/developers/docs/transactions/) [](https://ethereum.org/ja/developers/docs/intro-to-ether/#querying-ether) イーサの照会 --------------------------------------------------------------------------------- ユーザーは、アカウントの`balance`フィールドを調べることで、任意の[アカウント](https://ethereum.org/ja/developers/docs/accounts/) のイーサ残高を照会できます。このフィールドには、Wei単位でイーサの保有量が表示されます。 [Etherscan （新しいタブで開きます）](https://etherscan.io/) と[Blockscout （新しいタブで開きます）](https://eth.blockscout.com/) は、ウェブベースのアプリケーションを通じてアドレスの残高を調べるための人気のあるツールです。たとえば、[このBlockscoutのページ （新しいタブで開きます）](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) では、イーサリアム財団の残高が表示されています。アカウントの残高は、ウォレットを使用したり、ノードに直接リクエストを行ったりして照会することもできます。 [](https://ethereum.org/ja/developers/docs/intro-to-ether/#further-reading) 参考文献 -------------------------------------------------------------------------------- * [イーサとイーサリアムの定義 （新しいタブで開きます）](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_ * [イーサリアム・ホワイトペーパー](https://ethereum.org/ja/whitepaper/) : イーサリアムの最初の提案。このドキュメントには、イーサの説明とその作成の動機が含まれています。 * [Gwei計算機 （新しいタブで開きます）](https://www.alchemy.com/gwei-calculator) : このGwei計算機を使用すると、Wei、Gwei、イーサを簡単に変換できます。Wei、Gwei、またはETHの任意の金額を入力するだけで、自動的に変換が計算されます。 _役に立ったコミュニティのリソースをご存知ですか？このページを編集して追加してください！_ --- # ERC-1155 다중 토큰 표준 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#main-content) Change page ERC-1155 다중 토큰 표준 ================= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/tokens/erc-1155/index.md) 이 페이지의 내용 [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#introduction) 소개 -------------------------------------------------------------------------------------- 여러 토큰 유형을 관리하는 컨트랙트를 위한 표준 인터페이스입니다. 배포된 단일 컨트랙트에는 대체 가능 토큰, 대체 불가능 토큰 또는 기타 구성(예: 반대체 가능 토큰)의 모든 조합이 포함될 수 있습니다. **다중 토큰 표준이란 무엇을 의미하나요?** 이 아이디어는 단순하며, 원하는 수만큼의 대체 가능 토큰 및 대체 불가능 토큰 유형을 나타내고 제어할 수 있는 스마트 컨트랙트 인터페이스를 만드는 것을 목표로 합니다. 이러한 방식으로 ERC-1155 토큰은 [ERC-20](https://ethereum.org/ko/developers/docs/standards/tokens/erc-20/) 및 [ERC-721](https://ethereum.org/ko/developers/docs/standards/tokens/erc-721/) 토큰과 동일한 기능을 수행할 수 있으며, 심지어 두 가지 기능을 동시에 수행할 수도 있습니다. 이는 ERC-20 및 ERC-721 표준의 기능을 모두 개선하여 더 효율적으로 만들고 명백한 구현 오류를 수정합니다. ERC-1155 토큰은 [EIP-1155 (새 탭에서 열림)](https://eips.ethereum.org/EIPS/eip-1155) 에 자세히 설명되어 있습니다. [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#prerequisites) 전제 조건 ------------------------------------------------------------------------------------------ 이 페이지를 더 잘 이해하려면 먼저 [토큰 표준](https://ethereum.org/ko/developers/docs/standards/tokens/) , [ERC-20](https://ethereum.org/ko/developers/docs/standards/tokens/erc-20/) 및 [ERC-721](https://ethereum.org/ko/developers/docs/standards/tokens/erc-721/) 에 대해 읽어보는 것을 권장합니다. [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#body) ERC-1155 기능 및 특징: --------------------------------------------------------------------------------------------- * [일괄 전송(Batch Transfer)](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#batch-transfers) : 단일 호출로 여러 자산을 전송합니다. * [일괄 잔액(Batch Balance)](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#batch-balance) : 단일 호출로 여러 자산의 잔액을 가져옵니다. * [일괄 승인(Batch Approval)](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#batch-approval) : 주소에 대한 모든 토큰을 승인합니다. * [훅(Hooks)](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#receive-hook) : 토큰 수신 훅입니다. * [NFT 지원](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#nft-support) : 공급량이 1인 경우 NFT로 취급합니다. * [안전한 전송 규칙(Safe Transfer Rules)](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#safe-transfer-rule) : 안전한 전송을 위한 규칙 세트입니다. ### [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#batch-transfers) 일괄 전송 일괄 전송은 일반적인 ERC-20 전송과 매우 유사하게 작동합니다. 일반적인 ERC-20 `transferFrom` 함수를 살펴보겠습니다. // ERC-20 function transferFrom(address from, address to, uint256 value) external returns (bool); // ERC-1155 function safeBatchTransferFrom( address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data ) external; 복사Solidity 모두 보기 (11) ERC-1155의 유일한 차이점은 값을 배열로 전달하고 ID 배열도 함께 전달한다는 것입니다. 예를 들어 `ids=[3, 6, 13]` 및 `values=[100, 200, 5]`이 주어지면 결과 전송은 다음과 같습니다. 1. `_from`에서 `_to`(으)로 ID가 3인 토큰 100개를 전송합니다. 2. `_from`에서 `_to`(으)로 ID가 6인 토큰 200개를 전송합니다. 3. `_from`에서 `_to`(으)로 ID가 13인 토큰 5개를 전송합니다. ERC-1155에는 `transferFrom`만 있고 `transfer`는 없습니다. 일반적인 `transfer`처럼 사용하려면 발신자(from) 주소를 함수를 호출하는 주소로 설정하기만 하면 됩니다. ### [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#batch-balance) 일괄 잔액 마찬가지로 해당 ERC-20 `balanceOf` 호출에도 일괄 처리를 지원하는 파트너 함수가 있습니다. 참고로 다음은 ERC-20 버전입니다. // ERC-20 function balanceOf(address owner) external view returns (uint256); // ERC-1155 function balanceOfBatch( address[] calldata _owners, uint256[] calldata _ids ) external view returns (uint256[] memory); 복사Solidity 잔액 호출의 경우 훨씬 더 간단하게 단일 호출로 여러 잔액을 검색할 수 있습니다. 소유자 배열을 전달한 다음 토큰 ID 배열을 전달합니다. 예를 들어 `_ids=[3, 6, 13]` 및 `_owners=[0xbeef..., 0x1337..., 0x1111...]`가 주어지면 반환 값은 다음과 같습니다. [\ balanceOf(0xbeef...),\ balanceOf(0x1337...),\ balanceOf(0x1111...)\ ] 복사Solidity ### [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#batch-approval) 일괄 승인 // ERC-1155 function setApprovalForAll( address _operator, bool _approved ) external; function isApprovedForAll( address _owner, address _operator ) external view returns (bool); 복사Solidity 모두 보기 (10) 승인은 ERC-20과 약간 다릅니다. 특정 금액을 승인하는 대신 `setApprovalForAll`를 통해 운영자(operator)를 승인됨 또는 승인되지 않음으로 설정합니다. 현재 상태는 `isApprovedForAll`를 통해 읽을 수 있습니다. 보시다시피 이는 전부 아니면 전무(all-or-nothing) 방식의 작업입니다. 승인할 토큰 수나 토큰 클래스를 정의할 수 없습니다. 이는 의도적으로 단순성을 염두에 두고 설계되었습니다. 하나의 주소에 대해 모든 것만 승인할 수 있습니다. ### [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#receive-hook) 수신 훅 function onERC1155BatchReceived( address _operator, address _from, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data ) external returns(bytes4); 복사Solidity [EIP-165 (새 탭에서 열림)](https://eips.ethereum.org/EIPS/eip-165) 지원을 고려할 때, ERC-1155는 스마트 컨트랙트에 대해서만 수신 훅을 지원합니다. 훅 함수는 다음과 같이 미리 정의된 매직 bytes4 값을 반환해야 합니다. bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) 복사Solidity 수신 컨트랙트가 이 값을 반환하면 해당 컨트랙트가 전송을 수락하고 ERC-1155 토큰을 처리하는 방법을 알고 있는 것으로 간주됩니다. 훌륭합니다. 더 이상 컨트랙트에 토큰이 갇히는 일이 없습니다! ### [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#nft-support) NFT 지원 공급량이 단 하나일 때, 해당 토큰은 본질적으로 대체 불가능 토큰(NFT)입니다. 그리고 ERC-721의 표준과 마찬가지로 메타데이터 URL을 정의할 수 있습니다. 클라이언트는 이 URL을 읽고 수정할 수 있습니다. [여기 (새 탭에서 열림)](https://eips.ethereum.org/EIPS/eip-1155#metadata) 를 참조하세요. ### [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#safe-transfer-rule) 안전한 전송 규칙 이전 설명에서 이미 몇 가지 안전한 전송 규칙을 다루었습니다. 하지만 가장 중요한 규칙을 살펴보겠습니다. 1. 호출자는 `_from` 주소에 대해 토큰을 사용하도록 승인되어야 하거나 호출자가 `_from`와 같아야 합니다. 2. 다음과 같은 경우 전송 호출은 되돌리기 되어야 합니다. 1. `_to` 주소가 0인 경우. 2. `_ids`의 길이가 `_values`의 길이와 같지 않은 경우. 3. `_ids`에 있는 토큰에 대한 보유자의 잔액 중 하나라도 수신자에게 전송되는 `_values`의 해당 금액보다 적은 경우. 4. 기타 다른 오류가 발생하는 경우. _참고_: 훅을 포함한 모든 일괄 처리 함수는 일괄 처리가 없는 버전으로도 존재합니다. 단일 자산을 전송하는 것이 여전히 가장 일반적으로 사용되는 방법일 가능성이 높다는 점을 고려하여 가스 효율성을 위해 이렇게 만들어졌습니다. 안전한 전송 규칙을 포함하여 설명을 단순화하기 위해 여기서는 생략했습니다. 이름은 동일하며 'Batch'만 제거하면 됩니다. [](https://ethereum.org/ko/developers/docs/standards/tokens/erc-1155/#further-reading) 더 읽어보기 --------------------------------------------------------------------------------------------- * [EIP-1155: 다중 토큰 표준 (새 탭에서 열림)](https://eips.ethereum.org/EIPS/eip-1155) * [ERC-1155: 오픈제플린 문서 (새 탭에서 열림)](https://docs.openzeppelin.com/contracts/5.x/erc1155) * [ERC-1155: GitHub 리포지토리 (새 탭에서 열림)](https://github.com/enjin/erc-1155) * [Alchemy NFT API (새 탭에서 열림)](https://www.alchemy.com/docs/reference/nft-api-quickstart) --- # Gesi na ada za Ethereum: muhtasari wa kiufundi | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/gas/#main-content) Change page Gesi na ada =========== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/gas/index.md) Kwenye ukurasa huu Gesi ni muhimu kwa mtandao wa [Ethereum](https://ethereum.org/sw/) . Ni mafuta yanayouwezesha kufanya kazi, kwa njia sawa na ambayo gari linahitaji petroli ili kwenda. [](https://ethereum.org/sw/developers/docs/gas/#prerequisites) Mahitaji ya awali -------------------------------------------------------------------------------- Ili kuelewa vyema ukurasa huu, tunapendekeza usome kwanza kuhusu [miamala](https://ethereum.org/sw/developers/docs/transactions/) na [EVM](https://ethereum.org/sw/developers/docs/evm/) . [](https://ethereum.org/sw/developers/docs/gas/#what-is-gas) Gesi ni nini? -------------------------------------------------------------------------- Gesi inarejelea kipimo kinachopima kiasi cha juhudi za kikokotozi kinachohitajika kutekeleza shughuli mahususi kwenye mtandao wa Ethereum. Kwa kuwa kila muamala wa Ethereum unahitaji rasilimali za kikokotozi ili kutekelezwa, rasilimali hizo lazima zilipiwe ili kuhakikisha Ethereum haishambuliwi na taka na haiwezi kukwama katika mizunguko isiyo na kikomo ya kikokotozi. Malipo ya ukokotoaji hufanywa kwa njia ya ada ya gesi. Ada ya gesi ni **kiasi cha gesi kinachotumika kufanya operesheni fulani, kikizidishwa na gharama kwa kila uniti ya gesi**. Ada hulipwa bila kujali kama muamala umefaulu au umeshindwa. [![A diagram showing where gas is needed in EVM operations](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fgas%2Fgas.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/gas/gas.png) _Mchoro umechukuliwa kutoka [Ethereum EVM illustrated (inafunguka katika kichupo kipya)](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) _ Ada za gesi lazima zilipwe kwa sarafu ya asili ya Ethereum, Etha (ETH). Bei za gesi kwa kawaida hunukuliwa kwa Gwei, ambayo ni kigawanyo cha ETH. Kila Gwei ni sawa na sehemu moja ya bilioni ya ETH (0.000000001 ETH au 10\-9 ETH). Kwa mfano, badala ya kusema kwamba gesi yako inagharimu Etha 0.000000001, unaweza kusema gesi yako inagharimu Gwei 1. Neno 'Gwei' ni ufupisho wa 'giga-wei', ikimaanisha 'Wei bilioni'. Gwei moja ni sawa na Wei bilioni moja. Wei yenyewe (iliyopewa jina la [Wei Dai (inafunguka katika kichupo kipya)](https://wikipedia.org/wiki/Wei_Dai) , muundaji wa [b-money (inafunguka katika kichupo kipya)](https://www.investopedia.com/terms/b/bmoney.asp) ) ni uniti ndogo zaidi ya ETH. [](https://ethereum.org/sw/developers/docs/gas/#how-are-gas-fees-calculated) Ada za gesi zinakokotolewa vipi? ------------------------------------------------------------------------------------------------------------- Unaweza kuweka kiasi cha gesi ambacho uko tayari kulipa unapowasilisha muamala. Kwa kutoa kiasi fulani cha gesi, unashindania muamala wako ujumuishwe kwenye kitalu kinachofuata. Ukitoa kiasi kidogo sana, wathibitishaji wana uwezekano mdogo wa kuchagua muamala wako ili ujumuishwe, ikimaanisha muamala wako unaweza kutekelezwa kwa kuchelewa au usitekelezwe kabisa. Ukitoa kiasi kikubwa sana, unaweza kupoteza ETH. Kwa hivyo, unawezaje kujua kiasi cha kulipa? Jumla ya gesi unayolipa imegawanywa katika vipengele viwili: `base fee` na `priority fee` (ada ya kipaumbele). `base fee` huwekwa na itifaki—lazima ulipe angalau kiasi hiki ili muamala wako uchukuliwe kuwa halali. `priority fee` ni ada ya kipaumbele unayoongeza kwenye ada ya msingi ili kufanya muamala wako uvutie kwa wathibitishaji ili wauchague kwa ajili ya kujumuishwa kwenye kitalu kinachofuata. Muamala unaolipa tu `base fee` ni halali kiufundi lakini hauna uwezekano wa kujumuishwa kwa sababu hautoi motisha kwa wathibitishaji kuuchagua badala ya muamala mwingine wowote. Ada 'sahihi' ya `priority` inabainishwa na matumizi ya mtandao wakati unapotuma muamala wako—kama kuna mahitaji mengi basi unaweza kulazimika kuweka ada yako ya `priority` kuwa juu zaidi, lakini wakati kuna mahitaji machache unaweza kulipa kidogo. Kwa mfano, tuseme Jordan anapaswa kumlipa Taylor ETH 1. Hamisho la ETH linahitaji uniti 21,000 za gesi, na ada ya msingi ni Gwei 10. Jordan anajumuisha ada ya kipaumbele ya Gwei 2. Jumla ya ada sasa itakuwa sawa na: `units of gas used * (base fee + priority fee)` ambapo `base fee` ni thamani iliyowekwa na itifaki na `priority fee` ni thamani iliyowekwa na mtumiaji kama ada ya kipaumbele kwa mthibitishaji. k.m., `21,000 * (10 + 2) = 252,000 gwei` (0.000252 ETH). Wakati Jordan anatuma pesa, ETH 1.000252 itakatwa kutoka kwenye akaunti ya Jordan. Taylor atawekewa ETH 1.0000. Mthibitishaji anapokea ada ya kipaumbele ya ETH 0.000042. `base fee` ya ETH 0.00021 inachomwa. ### [](https://ethereum.org/sw/developers/docs/gas/#base-fee) Ada ya msingi Kila kitalu kina ada ya msingi ambayo hufanya kazi kama bei ya akiba. Ili kustahiki kujumuishwa kwenye kitalu, bei inayotolewa kwa kila gesi lazima angalau ilingane na ada ya msingi. Ada ya msingi inakokotolewa bila kutegemea kitalu cha sasa na badala yake inabainishwa na vitalu vilivyotangulia, na kufanya ada za muamala kutabirika zaidi kwa watumiaji. Kitalu kinapoundwa **ada hii ya msingi "inachomwa"**, na kuiondoa kwenye mzunguko. Ada ya msingi inakokotolewa kwa fomula inayolinganisha ukubwa wa kitalu kilichotangulia (kiasi cha gesi kilichotumika kwa miamala yote) na ukubwa unaolengwa (nusu ya kikomo cha gesi). Ada ya msingi itaongezeka au kupungua kwa kiwango cha juu cha 12.5% kwa kila kitalu ikiwa ukubwa wa kitalu unaolengwa uko juu au chini ya lengo, mtawalia. Ukuaji huu wa kielelezo hufanya isiwezekane kiuchumi kwa ukubwa wa kitalu kubaki juu kwa muda usiojulikana. | Nambari ya Kitalu | Gesi Iliyojumuishwa | Ongezeko la Ada | Ada ya Msingi ya Sasa | | --- | --- | --- | --- | | 1 | 18M | 0% | 100 gwei | | 2 | 36M | 0% | 100 gwei | | 3 | 36M | 12.5% | 112.5 gwei | | 4 | 36M | 12.5% | 126.6 gwei | | 5 | 36M | 12.5% | 142.4 gwei | | 6 | 36M | 12.5% | 160.2 gwei | | 7 | 36M | 12.5% | 180.2 gwei | | 8 | 36M | 12.5% | 202.7 gwei | Katika jedwali hapo juu, mfano unaonyeshwa kwa kutumia milioni 36 kama kikomo cha gesi. Kufuatia mfano huu, ili kuunda muamala kwenye kitalu nambari 9, mkoba utamjulisha mtumiaji kwa uhakika kwamba **ada ya juu zaidi ya msingi** itakayoongezwa kwenye kitalu kinachofuata ni `current base fee * 112.5%` au `202.7 gwei * 112.5% = 228.1 gwei`. Pia ni muhimu kutambua kuwa hakuna uwezekano wa kuona ongezeko la muda mrefu la vitalu vilivyojaa kwa sababu ya kasi ambayo ada ya msingi huongezeka kabla ya kitalu kujaa. | Nambari ya Kitalu | Gesi Iliyojumuishwa | Ongezeko la Ada | Ada ya Msingi ya Sasa | | --- | --- | --- | --- | | 30 | 36M | 12.5% | 2705.6 gwei | | ... | ... | 12.5% | ... | | 50 | 36M | 12.5% | 28531.3 gwei | | ... | ... | 12.5% | ... | | 100 | 36M | 12.5% | 10302608.6 gwei | ### [](https://ethereum.org/sw/developers/docs/gas/#priority-fee) Ada ya kipaumbele Ada ya kipaumbele inawapa motisha wathibitishaji kuongeza idadi ya miamala kwenye kitalu, ikizuiliwa tu na kikomo cha gesi cha kitalu. Bila ada za kipaumbele, mthibitishaji mwenye mantiki angeweza kujumuisha miamala michache—au hata sifuri—bila adhabu yoyote ya moja kwa moja ya tabaka la utekelezaji au tabaka la mwafaka, kwa kuwa zawadi za uwekaji dhamana hazitegemei idadi ya miamala iliyo kwenye kitalu. Zaidi ya hayo, ada za kipaumbele huwaruhusu watumiaji kushinda wengine kwa kipaumbele ndani ya kitalu kile kile, kuashiria udharura kwa ufanisi. ### [](https://ethereum.org/sw/developers/docs/gas/#maxfee) Ada ya juu zaidi Ili kutekeleza muamala kwenye mtandao, watumiaji wanaweza kubainisha kikomo cha juu zaidi ambacho wako tayari kulipa ili muamala wao utekelezwe. Kigezo hiki cha hiari kinajulikana kama `maxFeePerGas`. Ili muamala utekelezwe, ada ya juu zaidi lazima izidi jumla ya ada ya msingi na ada ya kipaumbele. Mtumaji wa muamala anarejeshewa tofauti kati ya ada ya juu zaidi na jumla ya ada ya msingi na ada ya kipaumbele. ### [](https://ethereum.org/sw/developers/docs/gas/#block-size) Ukubwa wa kitalu Kila kitalu kina ukubwa unaolengwa wa nusu ya kikomo cha gesi cha sasa, lakini ukubwa wa vitalu utaongezeka au kupungua kulingana na mahitaji ya mtandao, hadi kikomo cha kitalu kifikiwe (mara 2 ya ukubwa wa kitalu unaolengwa). Itifaki hufikia wastani wa ukubwa wa kitalu ulio sawa kwenye lengo kupitia mchakato wa _tâtonnement_. Hii inamaanisha ikiwa ukubwa wa kitalu ni mkubwa kuliko ukubwa wa kitalu unaolengwa, itifaki itaongeza ada ya msingi kwa kitalu kinachofuata. Vile vile, itifaki itapunguza ada ya msingi ikiwa ukubwa wa kitalu ni mdogo kuliko ukubwa wa kitalu unaolengwa. Kiasi ambacho ada ya msingi inarekebishwa kinalingana na jinsi ukubwa wa kitalu cha sasa ulivyo mbali na lengo. Huu ni ukokotoaji wa mstari kutoka -12.5% kwa kitalu tupu, 0% kwenye ukubwa unaolengwa, hadi +12.5% kwa kitalu kinachofikia kikomo cha gesi. Kikomo cha gesi kinaweza kubadilika kadiri muda unavyopita kulingana na uashiriaji wa mthibitishaji, pamoja na kupitia uboreshaji wa mtandao. Unaweza [kutazama mabadiliko katika kikomo cha gesi kadiri muda unavyopita hapa (inafunguka katika kichupo kipya)](https://eth.blockscout.com/stats/averageGasLimit?interval=threeMonths) . [Zaidi kuhusu vitalu](https://ethereum.org/sw/developers/docs/blocks/) ### [](https://ethereum.org/sw/developers/docs/gas/#calculating-fees-in-practice) Kukokotoa ada za gesi katika vitendo Unaweza kueleza waziwazi kiasi ambacho uko tayari kulipa ili muamala wako utekelezwe. Hata hivyo, watoa huduma wengi wa mikoba wataweka kiotomatiki ada ya muamala inayopendekezwa (ada ya msingi + ada ya kipaumbele inayopendekezwa) ili kupunguza kiasi cha utata kinachowekwa kwa watumiaji wao. [](https://ethereum.org/sw/developers/docs/gas/#why-do-gas-fees-exist) Kwa nini ada za gesi zipo? ------------------------------------------------------------------------------------------------- Kwa ufupi, ada za gesi husaidia kuweka mtandao wa Ethereum salama. Kwa kuhitaji ada kwa kila ukokotoaji unaotekelezwa kwenye mtandao, tunazuia watendaji wabaya kutuma taka kwenye mtandao. Ili kuepuka mizunguko isiyo na kikomo ya bahati mbaya au ya uhasama au upotevu mwingine wa kikokotozi katika msimbo, kila muamala unahitajika kuweka kikomo cha hatua ngapi za kikokotozi za utekelezaji wa msimbo unaweza kutumia. Uniti ya msingi ya ukokotoaji ni "gesi". Ingawa muamala unajumuisha kikomo, gesi yoyote ambayo haijatumika katika muamala inarejeshwa kwa mtumiaji (k.m., `max fee - (base fee + tip)` inarejeshwa). [![Diagram showing how unused gas is refunded](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Ftransactions%2Fgas-tx.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/transactions/gas-tx.png) _Mchoro umechukuliwa kutoka [Ethereum EVM illustrated (inafunguka katika kichupo kipya)](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) _ [](https://ethereum.org/sw/developers/docs/gas/#what-is-gas-limit) Kikomo cha gesi ni nini? ------------------------------------------------------------------------------------------- Kikomo cha gesi kinarejelea kiasi cha juu zaidi cha gesi ambacho uko tayari kutumia kwenye muamala. Miamala ngumu zaidi inayohusisha [mikataba mahiri](https://ethereum.org/sw/developers/docs/smart-contracts/) inahitaji kazi zaidi ya kikokotozi, kwa hivyo inahitaji kikomo cha juu zaidi cha gesi kuliko malipo rahisi. Hamisho la kawaida la ETH linahitaji kikomo cha gesi cha uniti 21,000 za gesi. Kwa mfano, ukiweka kikomo cha gesi cha 50,000 kwa hamisho rahisi la ETH, EVM itatumia 21,000, na utarudishiwa 29,000 zilizosalia. Hata hivyo, ukibainisha gesi kidogo sana, kwa mfano, kikomo cha gesi cha 20,000 kwa hamisho rahisi la ETH, muamala utashindwa wakati wa awamu ya uthibitishaji. Utakataliwa kabla ya kujumuishwa kwenye kitalu, na hakuna gesi itakayotumika. Kwa upande mwingine, ikiwa muamala utaishiwa na gesi wakati wa utekelezaji (k.m., mkataba mahiri unatumia gesi yote katikati), EVM itatengua mabadiliko yoyote, lakini gesi yote iliyotolewa bado itatumika kwa kazi iliyofanywa. [](https://ethereum.org/sw/developers/docs/gas/#why-can-gas-fees-get-so-high) Kwa nini ada za gesi zinaweza kuwa juu sana? -------------------------------------------------------------------------------------------------------------------------- Ada za juu za gesi zinatokana na umaarufu wa Ethereum. Ikiwa kuna mahitaji mengi sana, watumiaji lazima watoe kiasi cha juu zaidi cha ada ya kipaumbele ili kujaribu kushinda miamala ya watumiaji wengine. Ada ya kipaumbele ya juu zaidi inaweza kufanya iwezekane zaidi kwamba muamala wako utaingia kwenye kitalu kinachofuata. Pia, programu ngumu zaidi za mkataba mahiri zinaweza kuwa zinafanya operesheni nyingi ili kusaidia utendaji wao, na kuzifanya zitumie gesi nyingi. [](https://ethereum.org/sw/developers/docs/gas/#initiatives-to-reduce-gas-costs) Mipango ya kupunguza gharama za gesi --------------------------------------------------------------------------------------------------------------------- [Uboreshaji wa uwezo wa kuongezeka](https://ethereum.org/sw/roadmap/) wa Ethereum unapaswa hatimaye kushughulikia baadhi ya masuala ya ada ya gesi, ambayo, kwa upande wake, itawezesha jukwaa kuchakata maelfu ya miamala kwa sekunde na kuongezeka ulimwenguni kote. Uongezaji wa tabaka la 2 (l2) ni mpango wa msingi wa kuboresha sana gharama za gesi, uzoefu wa mtumiaji na uwezo wa kuongezeka. [Zaidi kuhusu uongezaji wa tabaka la 2 (l2)](https://ethereum.org/sw/developers/docs/scaling/#layer-2-scaling) [](https://ethereum.org/sw/developers/docs/gas/#monitoring-gas-fees) Kufuatilia ada za gesi ------------------------------------------------------------------------------------------- Ikiwa unataka kufuatilia bei za gesi, ili uweze kutuma ETH yako kwa bei nafuu, unaweza kutumia zana nyingi tofauti kama vile: * [Etherscan (inafunguka katika kichupo kipya)](https://etherscan.io/gastracker) _Kikadiriaji cha bei ya gesi ya muamala_ * [Blockscout (inafunguka katika kichupo kipya)](https://eth.blockscout.com/gas-tracker) _Kikadiriaji cha bei ya gesi ya muamala cha chanzo wazi_ * [ETH Gas Tracker (inafunguka katika kichupo kipya)](https://www.ethgastracker.com/) _Fuatilia na ufuatilie bei za gesi za Ethereum, na L2 ili kupunguza ada za muamala na kuokoa pesa_ * [Blocknative ETH Gas Estimator (inafunguka katika kichupo kipya)](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _Kiendelezi cha Chrome cha kukadiria gesi kinachoauni miamala ya urithi ya Aina ya 0 na miamala ya Aina ya 2 ya EIP-1559._ * [Cryptoneur Gas Fees Calculator (inafunguka katika kichupo kipya)](https://cryptoneur.xyz/en/gas-fees-calculator) _Kokotoa ada za gesi katika sarafu yako ya ndani kwa aina tofauti za miamala kwenye Mtandao Mkuu, Arbitrum, na Polygon._ [](https://ethereum.org/sw/developers/docs/gas/#related-tools) Zana zinazohusiana --------------------------------------------------------------------------------- * [Blocknative's Gas Platform (inafunguka katika kichupo kipya)](https://www.blocknative.com/gas) _API ya ukadiriaji wa gesi inayoendeshwa na jukwaa la data la mempool la kimataifa la Blocknative_ * [Gas Network (inafunguka katika kichupo kipya)](https://gas.network/) Oracles za Gesi za Mnyororoni. Usaidizi kwa misururu 35+. [](https://ethereum.org/sw/developers/docs/gas/#further-reading) Usomaji zaidi ------------------------------------------------------------------------------ * [Gesi ya Ethereum Imefafanuliwa (inafunguka katika kichupo kipya)](https://defiprime.com/gas) * [Kupunguza matumizi ya gesi ya Mikataba yako Mahiri (inafunguka katika kichupo kipya)](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a) * [Mikakati ya Matumizi Bora ya Gesi kwa Wasanidi Programu (inafunguka katika kichupo kipya)](https://www.alchemy.com/overviews/solidity-gas-optimization) * [Nyaraka za EIP-1559 (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-1559) . * [Rasilimali za EIP-1559 za Tim Beiko (inafunguka katika kichupo kipya)](https://hackmd.io/@timbeiko/1559-resources) * [EIP-1559: Kutenganisha Taratibu na Meme (inafunguka katika kichupo kipya)](https://web.archive.org/web/20241126205908/https://research.2077.xyz/eip-1559-separating-mechanisms-from-memes) --- # Uthibitishaji kwenye Ethereum | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#main-content) Change page Uthibitishaji kwenye Ethereum ============================= Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/ethereum-stack/authentication/index.md) Kwenye ukurasa huu Ikiwa unatoka kwenye uundaji wa wavuti wa kitamaduni, umezoea kuingia kwa kutumia jina la mtumiaji/nywila, mtiririko wa OAuth, na vidakuzi vya kipindi. Uthibitishaji kwenye Ethereum hufanya kazi tofauti—na kwa njia nyingi, kwa urahisi zaidi. Kwenye Ethereum, mtumiaji huthibitisha utambulisho wake kwa **kusaini ujumbe kwa kutumia mkoba wake**. Hakuna nywila ya kuhifadhi. Hakuna hifadhidata ya vitambulisho inayoweza kuvuja. Kriptografia tu. [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#how-is-it-different) Inatofautiana vipi na Web2? -------------------------------------------------------------------------------------------------------------------------- | Web2 | Ethereum | | --- | --- | | Jina la mtumiaji + nywila | Anwani ya mkoba + sahihi | | Seva huhifadhi vitambulisho | Mtumiaji anashikilia ufunguo wa siri | | Vipindi vinasimamiwa na vidakuzi / JWT | Vipindi huanza na sahihi ya mkoba nje ya mnyororo | | "Ingia kwa kutumia Google" | "Ingia kwa kutumia Ethereum" | | Mtiririko wa kuweka upya nywila | Urejeshaji wa kirai cha mbegu | Mabadiliko ya kimsingi: katika Web2, seva kuu inakuthibitisha. Kwenye Ethereum, **unajithibitisha mwenyewe** kwa kuthibitisha kuwa unadhibiti anwani maalum—na mtu yeyote anaweza kuithibitisha kwa kujitegemea. [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#prerequisites) Mahitaji ya awali ---------------------------------------------------------------------------------------------------------- Hakikisha unaelewa: * [Akaunti za Ethereum na jinsi zinavyofanya kazi](https://ethereum.org/sw/developers/docs/accounts/) * [Mkoba ni nini na jinsi ya kuuunganisha](https://ethereum.org/sw/wallets/) * [Misingi ya kriptografia ya ufunguo wa umma na ufunguo wa siri](https://ethereum.org/sw/developers/docs/accounts/#externally-owned-accounts-and-key-pairs) [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#how-wallet-auth-works) Jinsi uthibitishaji unaotegemea mkoba unavyofanya kazi ------------------------------------------------------------------------------------------------------------------------------------------------------- Mtiririko wa msingi ni rahisi: 1. **Programu tumizi iliyogatuliwa (dapp) yako inamwomba mtumiaji kuunganisha mkoba wake** (kupitia MetaMask, Rainbow, WalletConnect, n.k.) 2. **Mkoba unashiriki anwani ya Ethereum ya mtumiaji** - hiki ndicho kitambulisho chake cha umma 3. **Dapp yako inazalisha ujumbe wa kipekee** (nonsi au changamoto) 4. **Mtumiaji anasaini ujumbe** kwa kutumia ufunguo wa siri wake (hufanyika ndani ya mkoba) 5. **Mazingira yako ya nyuma (backend) yanathibitisha sahihi** dhidi ya anwani iliyodaiwa 6. **Ikiwa ni halali, mtumiaji anathibitishwa** Hakuna nywila iliyowahi kuchapwa, kuhifadhiwa, au kusambazwa. [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#sign-in-with-ethereum) Kuingia kwa kutumia Ethereum (EIP-4361) ---------------------------------------------------------------------------------------------------------------------------------------- [EIP-4361 (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-4361) inafafanua muundo wa ujumbe wa kawaida wa kuingia kwenye Ethereum, unaojulikana sana kama **SIWE** (Sign-In with Ethereum). Inachukua nafasi ya kusaini ujumbe kwa dharura na kiwango kilichopangwa na salama. Ujumbe wa SIWE unaonekana hivi: example.com wants you to sign in with your Ethereum account: 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B I accept the Terms of Service: https://example.com/tos URI: https://example.com/login Version: 1 Chain ID: 1 Nonce: 32891757 Issued At: 2024-06-12T14:30:00Z NakiliYAML Onyesha yote (10) Vipengele muhimu vya SIWE: * **Kufunga kikoa** - ujumbe unajumuisha kikoa, kuzuia hadaa (phishing) * **Kitambulisho cha Mnyororo (Chain ID)** - inabainisha ni mtandao upi sahihi ni halali kwake * **Nonsi** - inazuia mashambulizi ya kurudia (replay attacks) * **Muda wa kuisha** - muhuri wa muda wa hiari unaopunguza dirisha la uhalali * **Rasilimali** - URI za hiari kwa ufikiaji wenye upeo ### [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#siwe-libraries) Maktaba za SIWE * **[siwe (inafunguka katika kichupo kipya)](https://github.com/spruceid/siwe) ** - Utekelezaji rasmi wa TypeScript na Spruce * **[siwe-rs (inafunguka katika kichupo kipya)](https://github.com/spruceid/siwe-rs) ** - Utekelezaji wa Rust * **[siwe-go (inafunguka katika kichupo kipya)](https://github.com/spruceid/siwe-go) ** - Utekelezaji wa Go ### [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#example-siwe-client) Mfano: kuingia upande wa mteja kwa kutumia siwe import { SiweMessage } from 'siwe' import { BrowserProvider } from 'ethers' async function signIn() { const provider = new BrowserProvider(window.ethereum) const signer = await provider.getSigner() const address = await signer.getAddress() // 1. Pata nonsi kutoka kwenye mfumo wako wa nyuma const { nonce } = await fetch('/api/auth/nonce').then(r => r.json()) // 2. Unda na usaini ujumbe wa SIWE const message = new SiweMessage({ domain: window.location.host, address, statement: 'Sign in to My Dapp', uri: window.location.origin, version: '1', chainId: 1, nonce, }) const signature = await signer.signMessage(message.prepareMessage()) // 3. Tuma kwenye mfumo wa nyuma kwa uthibitishaji await fetch('/api/auth/verify', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ message, signature }), }) } NakiliTS Onyesha yote (31) ### [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#example-siwe-server) Mfano: uthibitishaji upande wa seva (Node.js) import { SiweMessage, generateNonce } from 'siwe' // Toa nonsi na uihifadhi kwenye kipindi ili /verify iweze kuikagua baadaye app.get('/api/auth/nonce', (req, res) => { req.session.nonce = generateNonce() res.json({ nonce: req.session.nonce }) }) app.post('/api/auth/verify', async (req, res) => { try { const { message, signature } = req.body const siweMessage = new SiweMessage(message) const { success, data } = await siweMessage.verify({ signature, nonce: req.session.nonce, }) if (success) { // data.address ni anwani ya Ethereum iliyothibitishwa // Unda kipindi au JWT kwa mtumiaji req.session.address = data.address res.json({ ok: true, address: data.address }) } } catch { res.status(401).json({ error: 'Invalid signature' }) } }) NakiliTS Onyesha yote (28) [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#wallet-connection-libraries) Maktaba za kuunganisha mkoba ----------------------------------------------------------------------------------------------------------------------------------- Kabla ya kuthibitisha, unahitaji mtumiaji aunganishe mkoba wake. Maktaba hizi hurahisisha: * **[RainbowKit (inafunguka katika kichupo kipya)](https://www.rainbowkit.com/) ** - Kijenzi cha React kilicho tayari kutumika chenye kiolesura kizuri cha mtumiaji (UI) * **[ConnectKit (inafunguka katika kichupo kipya)](https://docs.family.co/connectkit) ** - Modali ya kuunganisha mkoba ya kuweka moja kwa moja * **[AppKit (WalletConnect) (inafunguka katika kichupo kipya)](https://reown.com/appkit) ** - Muunganisho wa mkoba wa minyororo mingi wenye SIWE iliyojengewa ndani * **[Wagmi (inafunguka katika kichupo kipya)](https://wagmi.sh/) ** - Maktaba ya React Hooks yenye `useAccount`, `useConnect` [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#verifying-manually) Kuthibitisha sahihi kwa mikono ---------------------------------------------------------------------------------------------------------------------------- Ikiwa unapendelea kutotumia SIWE, unaweza kuthibitisha sahihi moja kwa moja: import { verifyMessage } from 'ethers' // Ujumbe ambao mtumiaji alisaini const message = `Sign in to My Dapp. Nonce: ${storedNonce}` // Rejesha anwani ya msaini kutoka kwenye sahihi const recoveredAddress = verifyMessage(message, signature) // Linganisha na anwani inayodaiwa if (recoveredAddress.toLowerCase() === claimedAddress.toLowerCase()) { // Uthibitishaji umefanikiwa } NakiliTS Onyesha yote (12) ### [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#security-notes) Vidokezo muhimu vya usalama * **Daima tumia nonsi** - inazuia mashambulizi ya kurudia ambapo sahihi ya zamani inatumiwa tena * **Jumuisha kikoa** - inazuia sahihi kuwa halali kwenye tovuti tofauti * **Angalia muda wa kuisha** - sahihi zinapaswa kuwa na dirisha dogo la uhalali * **Tumia SIWE (EIP-4361) inapowezekana** - inashughulikia yote hapo juu kwa ajili yako * **Kamwe usifichue funguo za siri** - kusaini hufanyika ndani ya mkoba; programu yako inaona tu matokeo [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#session-management) Usimamizi wa kipindi ------------------------------------------------------------------------------------------------------------------ Baada ya kuthibitishwa, bado unahitaji vipindi—kama tu Web2. Mitindo ya kawaida: * **Tokeni za JWT** - toa JWT baada ya kuthibitisha sahihi, tumia kwa maombi ya API * **Vipindi vya upande wa seva** - hifadhi anwani iliyothibitishwa kwenye kidakuzi cha kipindi * **SIWE yenye rasilimali** - fafanua tokeni za ufikiaji zenye upeo zilizounganishwa na URI maalum Tofauti kuu kutoka kwa Web2: anwani ya Ethereum ya mtumiaji ni utambulisho wake wa kudumu. Wanaweza kuitumia kwenye dapp yoyote bila kuunda akaunti mpya. [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#decentralized-identity) Utambulisho uliogatuliwa -------------------------------------------------------------------------------------------------------------------------- Uthibitishaji wa Ethereum ni sehemu ya harakati pana kuelekea **utambulisho wa kujitawala**. Viwango na miradi katika nafasi hii ni pamoja na: * **[Ethereum Name Service (ENS) (inafunguka katika kichupo kipya)](https://ens.domains/) ** - Majina yanayosomeka na binadamu (k.m., `vitalik.eth`) yanayotatua kwa anwani * **[Ethereum Attestation Service (EAS) (inafunguka katika kichupo kipya)](https://attest.org/) ** - Uthibitisho mnyororoni kuhusu utambulisho na vitambulisho * **[W3C Decentralized Identifiers (DIDs) (inafunguka katika kichupo kipya)](https://www.w3.org/TR/did-core/) ** - Kiwango cha kimataifa cha utambulisho uliogatuliwa (DID) unaoweza kuthibitishwa * **[Ceramic Network (inafunguka katika kichupo kipya)](https://ceramic.network/) ** - Mitiririko ya data iliyogatuliwa iliyofungwa na DID [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#further-reading) Usomaji zaidi -------------------------------------------------------------------------------------------------------- * [EIP-4361: Kuingia kwa kutumia Ethereum (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-4361) * [Nyaraka za SIWE (inafunguka katika kichupo kipya)](https://docs.login.xyz/) * [Kuingia kwa kutumia Ethereum kwenye Auth0 (inafunguka katika kichupo kipya)](https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/) * [Nyaraka za uthibitishaji za Reown AppKit (inafunguka katika kichupo kipya)](https://docs.reown.com/appkit/authentication) * [Nyaraka za ENS (inafunguka katika kichupo kipya)](https://docs.ens.domains/) [](https://ethereum.org/sw/developers/docs/ethereum-stack/authentication/#related-topics) Mada zinazohusiana ------------------------------------------------------------------------------------------------------------ * [Akaunti za Ethereum](https://ethereum.org/sw/developers/docs/accounts/) * [Maktaba za API za JavaScript](https://ethereum.org/sw/developers/docs/apis/javascript/) * [Maktaba za API za mazingira ya nyuma (backend)](https://ethereum.org/sw/developers/docs/apis/backend/) * [Mikoba](https://ethereum.org/sw/wallets/) --- # Mitandao | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/networks/#main-content) Change page Mitandao ======== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/networks/index.md) Kwenye ukurasa huu Mitandao ya [Ethereum](https://ethereum.org/sw/) ni vikundi vya kompyuta zilizounganishwa ambazo huwasiliana kwa kutumia itifaki ya Ethereum. Kuna Mtandao Mkuu wa Ethereum mmoja tu, lakini mitandao inayojitegemea inayofuata sheria sawa za itifaki inaweza kuundwa kwa madhumuni ya majaribio na maendeleo. Kuna "mitandao" mingi inayojitegemea inayofuata itifaki bila kuingiliana yenyewe kwa yenyewe. Unaweza hata kuanzisha mmoja kwenye kompyuta yako mwenyewe kwa ajili ya kujaribu mikataba mahiri yako na programu za Web3. Akaunti yako ya Ethereum itafanya kazi kwenye mitandao tofauti, lakini salio la akaunti yako na historia ya miamala haitahamishwa kutoka kwenye mtandao mkuu wa Ethereum. Kwa madhumuni ya majaribio, ni muhimu kujua ni mitandao ipi inapatikana na jinsi ya kupata ETH ya mtandao wa majaribio ya kufanyia majaribio. Kwa ujumla, kwa kuzingatia usalama, haipendekezwi kutumia tena akaunti za Mtandao Mkuu kwenye mitandao ya majaribio au kinyume chake. [](https://ethereum.org/sw/developers/docs/networks/#prerequisites) Mahitaji ya awali ------------------------------------------------------------------------------------- Unapaswa kuelewa [misingi ya Ethereum](https://ethereum.org/sw/developers/docs/intro-to-ethereum/) kabla ya kusoma kuhusu mitandao tofauti, kwani mitandao ya majaribio itakupa toleo la bei nafuu na salama la Ethereum la kufanyia majaribio. [](https://ethereum.org/sw/developers/docs/networks/#public-networks) Mitandao ya umma -------------------------------------------------------------------------------------- Mitandao ya umma inapatikana kwa mtu yeyote duniani aliye na muunganisho wa intaneti. Mtu yeyote anaweza kusoma au kuunda miamala kwenye mnyororo wa vitalu wa umma na kuthibitisha miamala inayotekelezwa. Mwafaka kati ya wenza huamua juu ya ujumuishaji wa miamala na hali ya mtandao. ### [](https://ethereum.org/sw/developers/docs/networks/#ethereum-mainnet) Mtandao Mkuu wa Ethereum Mtandao Mkuu ni mnyororo wa vitalu mkuu wa uzalishaji wa umma wa Ethereum, ambapo miamala yenye thamani halisi hufanyika kwenye leja iliyosambazwa. Watu na mabadilishano wanapojadili bei za ETH, wanazungumzia ETH ya Mtandao Mkuu. ### [](https://ethereum.org/sw/developers/docs/networks/#ethereum-testnets) Mitandao ya Majaribio ya Ethereum Mbali na Mtandao Mkuu, kuna mitandao ya majaribio ya umma. Hii ni mitandao inayotumiwa na wasanidi wa itifaki au wasanidi wa mikataba mahiri kujaribu uboreshaji wa itifaki pamoja na mikataba mahiri inayowezekana katika mazingira yanayofanana na ya uzalishaji kabla ya usambazaji kwenye Mtandao Mkuu. Fikiria hii kama mlinganisho wa seva za uzalishaji dhidi ya seva za maandalizi. Unapaswa kujaribu msimbo wowote wa mkataba unaoandika kwenye mtandao wa majaribio kabla ya kuusambaza kwenye Mtandao Mkuu. Miongoni mwa programu tumizi zilizogatuliwa (dapp) zinazounganishwa na mikataba mahiri iliyopo, miradi mingi ina nakala zilizosambazwa kwenye mitandao ya majaribio. Mitandao mingi ya majaribio ilianza kwa kutumia utaratibu wa makubaliano wa uthibitisho wa mamlaka (PoA) yenye ruhusa. Hii inamaanisha idadi ndogo ya nodi huchaguliwa kuthibitisha miamala na kuunda vitalu vipya – wakiweka utambulisho wao kama dhamana katika mchakato huo. Vinginevyo, baadhi ya mitandao ya majaribio ina utaratibu wa makubaliano wa Uthibitisho wa Dau (PoS) ulio wazi ambapo kila mtu anaweza kujaribu kuendesha mthibitishaji, kama tu Mtandao Mkuu wa Ethereum. ETH kwenye mitandao ya majaribio inapaswa kuwa haina thamani halisi; hata hivyo, kumekuwa na masoko yaliyoundwa kwa aina fulani za ETH ya mtandao wa majaribio ambazo zimekuwa adimu au ngumu kupata. Kwa kuwa unahitaji ETH ili kuingiliana kikweli na Ethereum (hata kwenye mitandao ya majaribio), watu wengi hupata ETH ya mtandao wa majaribio bila malipo kutoka kwenye mabomba. Mabomba mengi ni programu za wavuti ambapo unaweza kuweka anwani ambayo unaomba ETH itumwe. #### [](https://ethereum.org/sw/developers/docs/networks/#which-testnet-should-i-use) Nitumie Mtandao upi wa Majaribio? Mitandao miwili ya majaribio ya umma ambayo wasanidi wa wateja wanaitunza kwa sasa ni Sepolia na Hoodi. Sepolia ni mtandao kwa ajili ya wasanidi wa mikataba na programu kujaribu programu zao. Mtandao wa Hoodi unaruhusu wasanidi wa itifaki kujaribu uboreshaji wa mtandao, na unaruhusu waweka dhamana kujaribu kuendesha wathibitishaji. #### [](https://ethereum.org/sw/developers/docs/networks/#sepolia) Sepolia **Sepolia ni mtandao wa majaribio chaguomsingi unaopendekezwa kwa maendeleo ya programu**. Mtandao wa Sepolia unatumia seti ya wathibitishaji yenye ruhusa inayodhibitiwa na timu za wateja na majaribio. ##### Rasilimali * [Tovuti (inafunguka katika kichupo kipya)](https://sepolia.dev/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/eth-clients/sepolia) * [Otterscan (inafunguka katika kichupo kipya)](https://sepolia.otterscan.io/) * [Etherscan (inafunguka katika kichupo kipya)](https://sepolia.etherscan.io/) * [Blockscout (inafunguka katika kichupo kipya)](https://eth-sepolia.blockscout.com/) ##### Mabomba * [Bomba la Alchemy Sepolia (inafunguka katika kichupo kipya)](https://www.alchemy.com/faucets/ethereum-sepolia) * [Bomba la Chain Platform Sepolia (inafunguka katika kichupo kipya)](https://faucet.chainplatform.co/faucets/ethereum-sepolia/) * [Bomba la Chainstack Sepolia (inafunguka katika kichupo kipya)](https://faucet.chainstack.com/sepolia-testnet-faucet) * [Bomba la Mfumo wa Ikolojia wa Ethereum (inafunguka katika kichupo kipya)](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) * [Bomba la ethfaucet.com Sepolia (inafunguka katika kichupo kipya)](https://ethfaucet.com/networks/ethereum) * [Bomba la Google Cloud Web3 Sepolia (inafunguka katika kichupo kipya)](https://cloud.google.com/application/web3/faucet/ethereum/sepolia) * [Grabteeth (inafunguka katika kichupo kipya)](https://grabteeth.xyz/) * [Bomba la Infura Sepolia (inafunguka katika kichupo kipya)](https://www.infura.io/faucet) * [Bomba la PoW (inafunguka katika kichupo kipya)](https://sepolia-faucet.pk910.de/) * [Bomba la QuickNode Sepolia (inafunguka katika kichupo kipya)](https://faucet.quicknode.com/ethereum/sepolia) #### [](https://ethereum.org/sw/developers/docs/networks/#hoodi) Hoodi Hoodi ni mtandao wa majaribio kwa ajili ya kujaribu uthibitishaji na uwekaji dhamana. Mtandao wa Hoodi uko wazi kwa watumiaji wanaotaka kuendesha mthibitishaji wa mtandao wa majaribio. Waweka dhamana wanaotaka kujaribu uboreshaji wa itifaki kabla haujasambazwa kwenye Mtandao Mkuu wanapaswa kwa hivyo kutumia Hoodi. * Seti wazi ya wathibitishaji, waweka dhamana wanaweza kujaribu uboreshaji wa mtandao * Hali kubwa, muhimu kwa kujaribu mwingiliano changamano wa mikataba mahiri * Inachukua muda mrefu zaidi kufanya usawazishaji na inahitaji hifadhi zaidi ili kuendesha nodi ##### Rasilimali * [Tovuti (inafunguka katika kichupo kipya)](https://hoodi.ethpandaops.io/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/eth-clients/hoodi) * [Kichunguzi (inafunguka katika kichupo kipya)](https://explorer.hoodi.ethpandaops.io/) * [Usawazishaji wa Kituo cha Ukaguzi (inafunguka katika kichupo kipya)](https://checkpoint-sync.hoodi.ethpandaops.io/) * [Otterscan (inafunguka katika kichupo kipya)](https://hoodi.otterscan.io/) * [Etherscan (inafunguka katika kichupo kipya)](https://hoodi.etherscan.io/) ##### Mabomba * [Bomba la Chain Platform Hoodi (inafunguka katika kichupo kipya)](https://faucet.chainplatform.co/faucets/ethereum-hoodi/) * [Bomba la Hoodi (inafunguka katika kichupo kipya)](https://hoodi.ethpandaops.io/) * [Bomba la PoW (inafunguka katika kichupo kipya)](https://hoodi-faucet.pk910.de/) #### [](https://ethereum.org/sw/developers/docs/networks/#ephemery) Ephemery Ephemery ni aina ya kipekee ya mtandao wa majaribio ambayo huwekwa upya kikamilifu kila mwezi. Hali ya utekelezaji na mwafaka hurudi kwenye mwanzo kila baada ya siku 28, ambayo inamaanisha chochote kinachotokea kwenye mtandao wa majaribio ni cha muda mfupi. Hii inafanya iwe bora kwa majaribio ya muda mfupi, uanzishaji wa haraka wa nodi na aina ya programu za 'hello world' ambazo hazihitaji kudumu. * Hali mpya kila wakati, majaribio ya muda mfupi ya wathibitishaji na programu * Inajumuisha tu seti ya msingi ya mikataba * Seti wazi ya wathibitishaji na rahisi kupata kiasi kikubwa cha fedha * Mahitaji madogo zaidi ya nodi na usawazishaji wa haraka zaidi, <5GB kwa wastani ##### Rasilimali * [Tovuti (inafunguka katika kichupo kipya)](https://ephemery.dev/) * [GitHub (inafunguka katika kichupo kipya)](https://github.com/ephemery-testnet/ephemery-resources) * [Soga ya jamii (inafunguka katika kichupo kipya)](https://matrix.to/#/#staker-testnet:matrix.org) * [Blockscout (inafunguka katika kichupo kipya)](https://explorer.ephemery.dev/) * [Otterscan (inafunguka katika kichupo kipya)](https://otter.bordel.wtf/) * [Kichunguzi cha Beacon (inafunguka katika kichupo kipya)](https://beaconlight.ephemery.dev/) * [Usawazishaji wa Kituo cha Ukaguzi (inafunguka katika kichupo kipya)](https://checkpoint-sync.ephemery.ethpandaops.io/) * [Launchpad (inafunguka katika kichupo kipya)](https://launchpad.ephemery.dev/) #### [](https://ethereum.org/sw/developers/docs/networks/#faucets) Mabomba * [Bomba la Bordel (inafunguka katika kichupo kipya)](https://faucet.bordel.wtf/) * [Bomba la Pk910 PoW (inafunguka katika kichupo kipya)](https://ephemery-faucet.pk910.de/) #### [](https://ethereum.org/sw/developers/docs/networks/#holesky) Holesky (imeachwa kutumika) Mtandao wa majaribio wa Holesky umeachwa kutumika kuanzia Septemba 2025. Waendeshaji wa uwekaji dhamana na watoa huduma za miundombinu wanapaswa kutumia Hoodi kwa majaribio ya wathibitishaji badala yake. * [Tangazo la Kufungwa kwa Mtandao wa Majaribio wa Holesky (inafunguka katika kichupo kipya)](https://blog.ethereum.org/2025/09/01/holesky-shutdown-announcement) - _Blogu ya EF, 1-Septemba-2025_ * [Taarifa Mpya za Mtandao wa Majaribio wa Holesky na Hoodi (inafunguka katika kichupo kipya)](https://blog.ethereum.org/2025/03/18/hoodi-holesky) - _Blogu ya EF, 18-Machi-2025_ ### [](https://ethereum.org/sw/developers/docs/networks/#layer-2-testnets) Mitandao ya majaribio ya Tabaka la 2 [Tabaka la 2 (l2)](https://ethereum.org/sw/layer-2/) ni neno la pamoja kuelezea seti maalum ya suluhisho za kuongeza uwezo wa Ethereum. Tabaka la 2 ni mnyororo wa vitalu tofauti unaopanua Ethereum na kurithi dhamana za usalama za Ethereum. Mitandao ya majaribio ya tabaka la 2 kwa kawaida huunganishwa kwa karibu na mitandao ya majaribio ya umma ya Ethereum. #### [](https://ethereum.org/sw/developers/docs/networks/#arbitrum-sepolia) Arbitrum Sepolia Mtandao wa majaribio kwa ajili ya [Arbitrum (inafunguka katika kichupo kipya)](https://arbitrum.io/) . ##### Rasilimali * [Etherscan (inafunguka katika kichupo kipya)](https://sepolia.arbiscan.io/) * [Blockscout (inafunguka katika kichupo kipya)](https://sepolia-explorer.arbitrum.io/) ##### Mabomba * [Bomba la Alchemy Arbitrum Sepolia (inafunguka katika kichupo kipya)](https://www.alchemy.com/faucets/arbitrum-sepolia) * [Bomba la Chainlink Arbitrum Sepolia (inafunguka katika kichupo kipya)](https://faucets.chain.link/arbitrum-sepolia) * [Bomba la ethfaucet.com Arbitrum Sepolia (inafunguka katika kichupo kipya)](https://ethfaucet.com/networks/arbitrum) * [Bomba la QuickNode Arbitrum Sepolia (inafunguka katika kichupo kipya)](https://faucet.quicknode.com/arbitrum/sepolia) #### [](https://ethereum.org/sw/developers/docs/networks/#optimistic-sepolia) Optimistic Sepolia Mtandao wa majaribio kwa ajili ya [Optimism (inafunguka katika kichupo kipya)](https://www.optimism.io/) . ##### Rasilimali * [Etherscan (inafunguka katika kichupo kipya)](https://sepolia-optimistic.etherscan.io/) * [Blockscout (inafunguka katika kichupo kipya)](https://optimism-sepolia.blockscout.com/) ##### Mabomba * [Bomba la Alchemy (inafunguka katika kichupo kipya)](https://www.alchemy.com/faucets/optimism-sepolia) * [Bomba la Chainlink (inafunguka katika kichupo kipya)](https://faucets.chain.link/optimism-sepolia) * [Bomba la ethfaucet.com Optimism Sepolia (inafunguka katika kichupo kipya)](https://ethfaucet.com/networks/optimism) * [Bomba la Mtandao wa Majaribio (inafunguka katika kichupo kipya)](https://docs.optimism.io/builders/tools/build/faucets) #### [](https://ethereum.org/sw/developers/docs/networks/#starknet-sepolia) Starknet Sepolia Mtandao wa majaribio kwa ajili ya [Starknet (inafunguka katika kichupo kipya)](https://www.starknet.io/) . ##### Rasilimali * [Voyager Sepolia Scan (inafunguka katika kichupo kipya)](https://sepolia.voyager.online/) ##### Mabomba * [Bomba la Alchemy (inafunguka katika kichupo kipya)](https://www.alchemy.com/faucets/starknet-sepolia) * [Bomba la Blast Starknet Sepolia (inafunguka katika kichupo kipya)](https://blastapi.io/faucets/starknet-sepolia-eth) * [Bomba la Starknet (inafunguka katika kichupo kipya)](https://starknet-faucet.vercel.app/) [](https://ethereum.org/sw/developers/docs/networks/#private-networks) Mitandao ya kibinafsi -------------------------------------------------------------------------------------------- Mtandao wa Ethereum ni mtandao wa kibinafsi ikiwa nodi zake hazijaunganishwa kwenye mtandao wa umma (yaani, Mtandao Mkuu au mtandao wa majaribio). Katika muktadha huu, kibinafsi inamaanisha tu imehifadhiwa au imetengwa, badala ya kulindwa au kuwa salama. ### [](https://ethereum.org/sw/developers/docs/networks/#development-networks) Mitandao ya maendeleo Ili kuunda programu ya Ethereum, utataka kuiendesha kwenye mtandao wa kibinafsi ili kuona jinsi inavyofanya kazi kabla ya kuisambaza. Sawa na jinsi unavyounda seva ya ndani kwenye kompyuta yako kwa ajili ya maendeleo ya wavuti, unaweza kuunda mfano wa mnyororo wa vitalu wa ndani ili kujaribu programu tumizi iliyogatuliwa (dapp) yako. Hii inaruhusu urudiaji wa haraka zaidi kuliko mtandao wa majaribio wa umma. Kuna miradi na zana zilizojitolea kusaidia na hili. Jifunze zaidi kuhusu [mitandao ya maendeleo](https://ethereum.org/sw/developers/docs/development-networks/) . ### [](https://ethereum.org/sw/developers/docs/networks/#consortium-networks) Mitandao ya muungano Mchakato wa mwafaka unadhibitiwa na seti iliyofafanuliwa mapema ya nodi zinazoaminika. Kwa mfano, mtandao wa kibinafsi wa taasisi za kitaaluma zinazojulikana ambazo kila moja inasimamia nodi moja, na vitalu vinathibitishwa na kiwango cha watia saini ndani ya mtandao. Ikiwa mtandao wa umma wa Ethereum ni kama intaneti ya umma, mtandao wa muungano ni kama intraneti ya kibinafsi. [](https://ethereum.org/sw/developers/docs/networks/#why-naming) Kwa nini mitandao ya majaribio ya Ethereum inapewa majina ya vituo vya metro? ---------------------------------------------------------------------------------------------------------------------------------------------- Mitandao mingi ya majaribio ya Ethereum inapewa majina ya vituo vya metro au treni vya ulimwengu halisi. Mila hii ya kutoa majina ilianza mapema na inaonyesha miji ya kimataifa ambapo wachangiaji wameishi au kufanya kazi. Ni ya kiishara, ya kukumbukwa, na ya vitendo. Kama tu mitandao ya majaribio inavyotengwa na Mtandao Mkuu wa Ethereum, njia za metro huendeshwa kando na trafiki ya juu ya ardhi. ### [](https://ethereum.org/sw/developers/docs/networks/#common-and-legacy-testnets) Mitandao ya majaribio inayotumika sana na ya zamani * **Sepolia** - Kitongoji kilichounganishwa na metro huko Athens, Ugiriki. Kwa sasa inatumika kwa majaribio ya mikataba mahiri na programu tumizi iliyogatuliwa (dapp). * **Hoodi** - Imepewa jina la kituo cha metro cha Hoodi huko Bengaluru, India. Inatumika kwa majaribio ya wathibitishaji na uboreshaji wa itifaki. * **Goerli** _(imeachwa kutumika)_ - Imepewa jina la Görlitzer Bahnhof huko Berlin, Ujerumani. * **Rinkeby** _(imeachwa kutumika)_ - Imepewa jina la kitongoji cha Stockholm chenye kituo cha metro. * **Ropsten** _(imeachwa kutumika)_ - Inarejelea eneo na kituo cha zamani cha feri/metro huko Stockholm. * **Kovan** _(imeachwa kutumika)_ - Imepewa jina la kituo cha MRT cha Singapore. * **Morden** _(imeachwa kutumika)_ - Imepewa jina la kituo cha London Underground. Mtandao wa majaribio wa kwanza wa umma wa Ethereum. ### [](https://ethereum.org/sw/developers/docs/networks/#other-testnets) Mitandao mingine maalum ya majaribio Baadhi ya mitandao ya majaribio iliundwa kwa ajili ya majaribio ya muda mfupi au maalum kwa uboreshaji na si lazima iwe na mandhari ya metro: * **Holesky** _(imeachwa kutumika)_ - Imepewa jina la kituo cha Holešovice huko Prague. Inatumika kwa majaribio ya wathibitishaji; imeachwa kutumika mnamo 2025. * **Kiln**, **Zhejiang**, **Shandong**, **Prater**, **Pyrmont**, **Olympic** _(zote zimeachwa kutumika)_ na **Ephemery** - Zimejengwa kwa madhumuni ya uigaji wa uboreshaji kama vile Unganisho, Shanghai, au majaribio ya wathibitishaji. Baadhi ya majina ni ya kikanda au ya kimandhari badala ya kutegemea metro. Kutumia majina ya vituo vya metro husaidia wasanidi kutambua na kukumbuka haraka mitandao ya majaribio bila kuhitaji kutegemea vitambulisho vya nambari vya mnyororo. Pia inaonyesha utamaduni wa Ethereum: wa vitendo, wa kimataifa, na unaozingatia binadamu. [](https://ethereum.org/sw/developers/docs/networks/#related-tools) Zana zinazohusiana -------------------------------------------------------------------------------------- * [Chainlist (inafunguka katika kichupo kipya)](https://chainlist.org/) _orodha ya mitandao ya EVM ya kuunganisha pochi na watoa huduma kwenye Kitambulisho cha Mnyororo na Kitambulisho cha Mtandao kinachofaa_ * [Minyororo inayotegemea EVM (inafunguka katika kichupo kipya)](https://github.com/ethereum-lists/chains) _Hifadhi ya GitHub ya data fafanuzi ya mnyororo inayoendesha Chainlist_ [](https://ethereum.org/sw/developers/docs/networks/#further-reading) Usomaji zaidi ----------------------------------------------------------------------------------- * [Pendekezo: Mzunguko wa Maisha wa Mtandao wa Majaribio wa Ethereum Unaotabirika (inafunguka katika kichupo kipya)](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) * [Mageuzi ya Mitandao ya Majaribio ya Ethereum (inafunguka katika kichupo kipya)](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/) --- # マイニング | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/mining/#main-content) Change page マイニング ===== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/consensus-mechanisms/pow/mining/index.md) このページの内容 プルーフ・オブ・ワーク (PoW) はもはやイーサリアムのコンセンサス・メカニズムの基盤ではなくなり、マイニングは終了しました。代わりに、[イーサリアム](https://ethereum.org/ja/) はETHをステークするバリデーターによって保護されています。今日からETHのステーキングを始めることができます。[マージ](https://ethereum.org/roadmap/merge/) 、[プルーフ・オブ・ステーク (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) 、および[ステーキング](https://ethereum.org/staking/) について詳しくお読みください。このページは歴史的な関心のためにのみ提供されています。 [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/mining/#prerequisites) 前提知識 ----------------------------------------------------------------------------------------------- このページをよりよく理解するために、まずは[トランザクション](https://ethereum.org/ja/developers/docs/transactions/) 、[ブロック](https://ethereum.org/ja/developers/docs/blocks/) 、および[プルーフ・オブ・ワーク (PoW)](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/) について読むことをお勧めします。 [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/mining/#what-is-ethereum-mining) イーサリアムのマイニングとは？ -------------------------------------------------------------------------------------------------------------------- マイニングとは、現在では非推奨となったイーサリアムのプルーフ・オブ・ワーク (PoW) アーキテクチャにおいて、イーサリアムのブロックチェーンに追加されるトランザクションのブロックを作成するプロセスのことです。 マイニングという言葉は、暗号資産を金に例える文脈から生まれました。金や貴金属が希少であるように、デジタルトークンも希少であり、プルーフ・オブ・ワーク・システムにおいて総量を増やす唯一の方法がマイニングです。プルーフ・オブ・ワーク版のイーサリアムでは、唯一の発行方法がマイニングでした。しかし、金や貴金属とは異なり、イーサリアムのマイニングは、ブロックチェーン上でブロックを作成、検証、公開、伝播させることでネットワークを保護する方法でもありました。 イーサのマイニング = ネットワークの保護 マイニングは、あらゆるプルーフ・オブ・ワーク・ブロックチェーンの生命線です。イーサリアムのマイナー（ソフトウェアを実行するコンピュータ）は、プルーフ・オブ・ステーク (PoS) への移行前、時間と計算能力を使ってトランザクションを処理し、ブロックを生成していました。 [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/mining/#why-do-miners-exist) なぜマイナーが存在するのか？ --------------------------------------------------------------------------------------------------------------- イーサリアムのような分散型システムでは、全員がトランザクションの順序に合意することを保証する必要があります。マイナーは、計算が困難なパズルを解いてブロックを生成することでこれを支援し、攻撃からネットワークを保護していました。 [プルーフ・オブ・ワーク (PoW) の詳細](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/) 以前は、誰でも自分のコンピュータを使ってイーサリアム・ネットワークでマイニングを行うことができました。しかし、誰もが利益を上げてイーサ (ETH) をマイニングできたわけではありません。ほとんどの場合、マイナーは専用のコンピュータハードウェアを購入し、安価なエネルギー源にアクセスする必要がありました。一般的なコンピュータでは、マイニングに関連するコストをカバーするのに十分なブロック報酬を得ることは困難でした。 ### [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/mining/#cost-of-mining) マイニングのコスト * マイニングリグの構築と維持に必要なハードウェアの潜在的コスト * マイニングリグを稼働させるための電気代 * プールでマイニングを行う場合、通常、プールが生成した各ブロックに対して一定の割合（%）の手数料が請求された * マイニングリグをサポートする設備の潜在的コスト（換気、エネルギー監視、電気配線など） マイニングの収益性についてさらに詳しく調べるには、[Etherscan （新しいタブで開きます）](https://etherscan.io/ether-mining-calculator) が提供しているようなマイニング計算機を使用してください。 [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/mining/#how-ethereum-transactions-were-mined) イーサリアムのトランザクションはどのようにマイニングされたか ------------------------------------------------------------------------------------------------------------------------------------------------ 以下は、イーサリアムのプルーフ・オブ・ワーク (PoW) においてトランザクションがどのようにマイニングされたかの概要です。イーサリアムのプルーフ・オブ・ステーク (PoS) におけるこのプロセスの同様の説明は、[こちら](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) にあります。 1. ユーザーは、ある[アカウント](https://ethereum.org/ja/developers/docs/accounts/) の秘密鍵を使用して[トランザクション](https://ethereum.org/ja/developers/docs/transactions/) リクエストを作成し、署名します。 2. ユーザーは、ある[ノード](https://ethereum.org/ja/developers/docs/nodes-and-clients/) からイーサリアム・ネットワーク全体にトランザクションリクエストをブロードキャストします。 3. 新しいトランザクションリクエストを受信すると、イーサリアム・ネットワーク内の各ノードは、そのリクエストをローカルのメンプールに追加します。メンプールとは、受信したものの、まだブロックとしてブロックチェーンにコミットされていないすべてのトランザクションリクエストのリストです。 4. ある時点で、マイニングノードは数十から数百のトランザクションリクエストを集約し、ブロックのガス・リミット内に収めつつ、獲得する[トランザクション手数料](https://ethereum.org/ja/developers/docs/gas/) を最大化するように、候補となる[ブロック](https://ethereum.org/ja/developers/docs/blocks/) を作成します。その後、マイニングノードは以下の処理を行います。 1. 各トランザクションリクエストの有効性を検証し（例：署名を作成していないアカウントからイーサを送金しようとしていないか、リクエストの形式が不正でないかなど）、リクエストのコードを実行して、ローカルのEVMコピーの状態を変更します。マイナーは、そのような各トランザクションリクエストのトランザクション手数料を自身のアカウントに付与します。 2. ブロック内のすべてのトランザクションリクエストが検証され、ローカルのEVMコピー上で実行されると、候補となるブロックのプルーフ・オブ・ワークによる「正当性の証明書」を生成するプロセスを開始します。 5. 最終的に、あるマイナーが特定のトランザクションリクエストを含むブロックの証明書の生成を完了します。その後、マイナーは完成したブロックをブロードキャストします。これには、証明書と、主張する新しいEVM状態のチェックサムが含まれます。 6. 他のノードは新しいブロックを受信します。ノードは証明書を検証し、ブロック上のすべてのトランザクション（ユーザーが最初にブロードキャストしたトランザクションを含む）を自身で実行し、すべてのトランザクション実行後の新しいEVM状態のチェックサムが、マイナーのブロックが主張する状態のチェックサムと一致することを検証します。これらが確認されて初めて、ノードはこのブロックを自身のブロックチェーンの末尾に追加し、新しいEVM状態を正規の状態として受け入れます。 7. 各ノードは、新しいブロックに含まれるすべてのトランザクションを、未処理のトランザクションリクエストのローカルメンプールから削除します。 8. ネットワークに参加する新しいノードは、対象のトランザクションを含むブロックを含め、すべてのブロックを順番にダウンロードします。ローカルのEVMコピー（初期状態のEVMとして開始）を初期化し、ローカルのEVMコピー上で各ブロックのすべてのトランザクションを実行するプロセスを経て、途中の各ブロックで状態のチェックサムを検証します。 すべてのトランザクションは一度だけマイニング（新しいブロックに含まれ、初めて伝播される）されますが、正規のEVM状態を進めるプロセスにおいて、すべての参加者によって実行および検証されます。これは、ブロックチェーンの中心的なマントラの1つである「**信じるな、検証せよ (Don’t trust, verify)**」を強調しています。 [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/mining/#ommer-blocks) オマー（アンクル）・ブロック -------------------------------------------------------------------------------------------------------- プルーフ・オブ・ワーク (PoW) におけるブロックのマイニングは確率的であったため、ネットワークの遅延により、2つの有効なブロックが同時に公開されることがありました。この場合、プロトコルは最も長い（したがって最も「有効な」）チェーンを決定すると同時に、提案されたものの含まれなかった有効なブロックに対して部分的に報酬を与えることで、マイナーに対する公平性を確保する必要がありました。これにより、遅延が大きくなりがちな小規模なマイナーでもの報酬を通じて利益を得ることができたため、ネットワークのさらなる分散化が促進されました。 「オマー (ommer)」という用語は、親ブロックの兄弟ブロックを指すジェンダーニュートラルな用語として推奨されていますが、「アンクル (uncle)」と呼ばれることもあります。\*\*イーサリアムがプルーフ・オブ・ステーク (PoS) に移行して以来、各スロットで選出されるプロポーザーは1人だけになったため、オマー（アンクル）・ブロックはマイニングされなくなりました。\*\*マイニングされたオマー（アンクル）・ブロックの[履歴チャート （新しいタブで開きます）](https://ycharts.com/indicators/ethereum_uncle_rate) を見ることで、この変化を確認できます。 [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/mining/#a-visual-demo) 視覚的なデモ ------------------------------------------------------------------------------------------------- オースティンがマイニングとプルーフ・オブ・ワーク (PoW) ブロックチェーンについて解説する動画をご覧ください。 ### Blockchain — ETH.BUILD A demonstration of how blockchain mining works, including how blocks are chained together, how proof of work secures blockchains, and what happens when someone tries to tamper with data. [トランスクリプト付きで視聴](https://ethereum.org/ja/videos/blockchain-eth-build/)   [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/mining/#mining-algorithm) マイニングアルゴリズム --------------------------------------------------------------------------------------------------------- イーサリアム・メインネットで使用されたマイニングアルゴリズムは、[「イーサッシュ」](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/) の1つだけです。イーサッシュは、[「Dagger-Hashimoto」](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/) として知られる初期の研究開発アルゴリズムの後継でした。 [マイニングアルゴリズムの詳細](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/) 。 [](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/mining/#related-topics) 関連トピック -------------------------------------------------------------------------------------------------- * [ガス](https://ethereum.org/ja/developers/docs/gas/) * [EVM](https://ethereum.org/ja/developers/docs/evm/) * [プルーフ・オブ・ワーク (PoW)](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/) --- # データと分析 | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/data-and-analytics/#main-content) Change page データと分析 ====== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-and-analytics/index.md) このページの内容 [](https://ethereum.org/ja/developers/docs/data-and-analytics/#introduction) はじめに --------------------------------------------------------------------------------- ネットワークの利用が拡大し続けるにつれて、オンチェーンデータにはますます多くの価値ある情報が存在するようになります。データ量が急速に増加する中で、この情報を計算・集約してレポートを作成したり、分散型アプリケーション (dapp) を駆動させたりすることは、時間と処理の負担が大きい作業になる可能性があります。 既存のデータプロバイダーを活用することで、開発を迅速化し、より正確な結果を生み出し、継続的なメンテナンスの労力を削減できます。これにより、チームはプロジェクトが提供しようとしているコア機能に集中できるようになります。 [](https://ethereum.org/ja/developers/docs/data-and-analytics/#prerequisites) 前提条件 ---------------------------------------------------------------------------------- データ分析のコンテキストでの使用をよりよく理解するために、[ブロックエクスプローラー](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/) の基本概念を理解しておく必要があります。さらに、システム設計にもたらす利点を理解するために、の概念にも慣れておいてください。 アーキテクチャの基礎としては、[API （新しいタブで開きます）](https://www.wikipedia.org/wiki/API) と[REST （新しいタブで開きます）](https://www.wikipedia.org/wiki/Representational_state_transfer) が何であるかを、理論上だけでも理解しておく必要があります。 [](https://ethereum.org/ja/developers/docs/data-and-analytics/#block-explorers) ブロックエクスプローラー -------------------------------------------------------------------------------------------- 多くの[ブロックエクスプローラー](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/) は、開発者がブロック、トランザクション、バリデータ、アカウント、およびその他のオンチェーンアクティビティに関するリアルタイムデータを可視化できる[RESTful （新しいタブで開きます）](https://www.wikipedia.org/wiki/Representational_state_transfer) な[API （新しいタブで開きます）](https://www.wikipedia.org/wiki/API) ゲートウェイを提供しています。 開発者はこのデータを処理および変換して、ユーザーに独自の洞察を提供し、とのインタラクションを提供できます。たとえば、[Etherscan （新しいタブで開きます）](https://etherscan.io/) や[Blockscout （新しいタブで開きます）](https://eth.blockscout.com/) は、12秒の各スロットの実行データとコンセンサスデータを提供します。 [](https://ethereum.org/ja/developers/docs/data-and-analytics/#the-graph) The Graph ----------------------------------------------------------------------------------- [The Graph （新しいタブで開きます）](https://thegraph.com/) は、サブグラフと呼ばれるオープンなAPIを通じてブロックチェーンデータを簡単にクエリできるインデックス作成プロトコルです。 The Graphを使用すると、開発者は以下の利点を得ることができます。 * 分散型インデックス作成: 複数のインデクサーを通じてブロックチェーンデータのインデックスを作成できるため、単一障害点が排除されます。 * GraphQLクエリ: インデックス化されたデータをクエリするための強力なGraphQLインターフェースを提供し、データの取得を非常に簡単にします。 * カスタマイズ: ブロックチェーンデータを変換および保存するための独自のロジックを定義し、The Graphネットワーク上で他の開発者が公開したサブグラフを再利用できます。 この[クイックスタート （新しいタブで開きます）](https://thegraph.com/docs/en/quick-start/) ガイドに従って、5分以内にサブグラフを作成、デプロイ、およびクエリしてください。 [](https://ethereum.org/ja/developers/docs/data-and-analytics/#client-diversity) クライアント・ダイバーシティ ----------------------------------------------------------------------------------------------- [クライアント・ダイバーシティ](https://ethereum.org/ja/developers/docs/nodes-and-clients/client-diversity/) は、バグやエクスプロイトに対する回復力を提供するため、イーサリアムネットワーク全体の健全性にとって重要です。現在、[clientdiversity.org （新しいタブで開きます）](https://clientdiversity.org/) 、[rated.network （新しいタブで開きます）](https://www.rated.network/) 、[supermajority.info （新しいタブで開きます）](https://supermajority.info//) 、[Ethernodes （新しいタブで開きます）](https://ethernodes.org/) など、いくつかのクライアント・ダイバーシティのダッシュボードが存在します。 [](https://ethereum.org/ja/developers/docs/data-and-analytics/#dune-analytics) Dune Analytics --------------------------------------------------------------------------------------------- [Dune Analytics （新しいタブで開きます）](https://dune.com/) は、ブロックチェーンデータをリレーショナルデータベース (DuneSQL) のテーブルに事前処理し、ユーザーがSQLを使用してブロックチェーンデータをクエリし、クエリ結果に基づいてダッシュボードを構築できるようにします。オンチェーンデータは、`blocks`、`transactions`、(イベント) `logs`、(コール) `traces`の4つの生テーブルに整理されています。人気のあるコントラクトやプロトコルはデコードされており、それぞれに独自のイベントテーブルとコールテーブルのセットがあります。これらのイベントテーブルとコールテーブルはさらに処理され、DEX、レンディング、ステーブルコインなどのプロトコルの種類ごとに抽象化テーブルに整理されます。 [](https://ethereum.org/ja/developers/docs/data-and-analytics/#sqd) SQD ----------------------------------------------------------------------- [SQD （新しいタブで開きます）](https://sqd.dev/) は、大量のデータへの効率的でパーミッションレスなアクセスを提供するように最適化された、分散型のハイパースケーラブルなデータプラットフォームです。現在、イベントログ、トランザクションレシート、トレース、トランザクションごとの状態の差分など、過去のオンチェーンデータを提供しています。SQDは、カスタムのデータ抽出および処理パイプラインを作成するための強力なツールキットを提供し、毎秒最大15万ブロックのインデックス作成速度を実現します。 始めるには、[ドキュメント （新しいタブで開きます）](https://docs.sqd.dev/) にアクセスするか、SQDで構築できるものの[EVMの例 （新しいタブで開きます）](https://github.com/subsquid-labs/squid-evm-examples) を参照してください。 [](https://ethereum.org/ja/developers/docs/data-and-analytics/#subquery-network) SubQueryネットワーク ----------------------------------------------------------------------------------------------- [SubQuery （新しいタブで開きます）](https://subquery.network/) は、Web3プロジェクト向けに高速で信頼性が高く、分散型でカスタマイズされたAPIを開発者に提供する主要なデータインデクサーです。SubQueryは、165以上のエコシステム (イーサリアムを含む) の開発者に豊富なインデックス化されたデータを提供し、ユーザーにとって直感的で没入感のある体験を構築できるようにします。SubQueryネットワークは、回復力のある分散型インフラストラクチャネットワークで、止まらないアプリを強化します。SubQueryのブロックチェーン開発者ツールキットを使用して、データ処理アクティビティ用のカスタムバックエンドの構築に時間を費やすことなく、未来のWeb3アプリケーションを構築しましょう。 始めるには、[イーサリアムのクイックスタートガイド （新しいタブで開きます）](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) にアクセスしてください。[SubQueryのマネージドサービス （新しいタブで開きます）](https://managedservice.subquery.network/) や[SubQueryの分散型ネットワーク （新しいタブで開きます）](https://app.subquery.network/dashboard) で本番環境に移行する前に、テスト用のローカルDocker環境で数分でイーサリアムブロックチェーンデータのインデックス作成を開始できます。 [](https://ethereum.org/ja/developers/docs/data-and-analytics/#codex) Codex --------------------------------------------------------------------------- [Codex （新しいタブで開きます）](https://www.codex.io/) は、80以上のネットワークにわたる7,000万以上のトークンの充実したデータを提供するリアルタイムのブロックチェーンデータAPIです。開発者は、カスタムのインデックス作成インフラストラクチャを維持することなく、構造化されたトークン価格、ウォレット残高、トランザクション履歴、および集計された分析 (取引量、流動性、ユニークウォレット数) にアクセスできます。Codexは、WebSocketおよびWebhook統合による1秒未満のデータ配信をサポートしています。 始めるには、[ドキュメント （新しいタブで開きます）](https://docs.codex.io/) にアクセスするか、[エクスプローラー （新しいタブで開きます）](https://docs.codex.io/explore) を試すか、[ダッシュボード （新しいタブで開きます）](https://dashboard.codex.io/signup) でサインアップしてください。 Mobula ------ [Mobula （新しいタブで開きます）](https://mobula.io/) は、90以上のブロックチェーンにわたるリアルタイムおよび過去の市場データ、トークンのメタデータ、ウォレットのポートフォリオ、およびオンチェーン分析を提供する、高性能な暗号資産データAPIです。開発者は、独自のインフラストラクチャを実行することなく、トークン価格、時価総額、取引量、流動性データ、およびマルチチェーンのウォレット残高のためのRESTおよびGraphQLエンドポイントにアクセスできます。Mobulaは、本番環境のアプリケーション向けに無料（月間10万リクエスト）と有料の両方のプランを提供しています。 始めるには、[ドキュメント （新しいタブで開きます）](https://docs.mobula.io/) にアクセスするか、[APIリファレンス （新しいタブで開きます）](https://docs.mobula.io/reference/) を調べるか、[ダッシュボード （新しいタブで開きます）](https://mobula.io/) でサインアップしてください。 [](https://ethereum.org/ja/developers/docs/data-and-analytics/#evm-query-language) EVM Query Language ----------------------------------------------------------------------------------------------------- EVM Query Language (EQL) は、EVM (イーサリアム仮想マシン) チェーンをクエリするために設計されたSQLライクな言語です。EQLの最終的な目標は、EVMチェーンのファーストクラスシチズン (ブロック、アカウント、トランザクション) に対する複雑なリレーショナルクエリをサポートすると同時に、開発者や研究者に日常的に使用できる人間工学に基づいた構文を提供することです。EQLを使用すると、開発者は使い慣れたSQLライクな構文を使用してブロックチェーンデータを取得でき、複雑なボイラープレートコードの必要性を排除できます。EQLは、標準的なブロックチェーンデータのリクエスト (例: イーサリアム上のアカウントのナンスと残高の取得、現在のブロックサイズとタイムスタンプの取得など) をサポートしており、より複雑なリクエストや機能セットのサポートを継続的に追加しています。 Envio ----- [Envio （新しいタブで開きます）](https://envio.dev/) は、オンチェーンイベントをクエリ可能なGraphQL APIに変換するインデックス作成フレームワークです。イーサリアムおよびすべてのEVM互換チェーンをサポートしています。開発者はTypeScript、JavaScript、またはReScriptでイベントハンドラーを記述し、リオーグのサポート、マルチチェーンのインデックス作成、およびEnvio Cloudでのマネージドホスティングまたはセルフホスティングを備えた、リアルタイムおよび過去のデータを提供します。 始めるには、[HyperIndexのクイックスタート （新しいタブで開きます）](https://docs.envio.dev/docs/HyperIndex/quickstart) に従って、インデクサーを作成、デプロイ、およびクエリしてください。 [](https://ethereum.org/ja/developers/docs/data-and-analytics/#further-reading) 参考文献 ------------------------------------------------------------------------------------ * [暗号資産データの探索 I: データフローアーキテクチャ （新しいタブで開きます）](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) * [The Graphネットワークの概要 （新しいタブで開きます）](https://thegraph.com/docs/en/about/) * [Graphクエリプレイグラウンド （新しいタブで開きます）](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) * [EtherScanのAPIコード例 （新しいタブで開きます）](https://etherscan.io/apis#contracts) * [BlockscoutのAPIドキュメント （新しいタブで開きます）](https://docs.blockscout.com/devs/apis) * [Beaconcha.in ビーコン・チェーンエクスプローラー （新しいタブで開きます）](https://beaconcha.in/) * [Duneの基礎 （新しいタブで開きます）](https://docs.dune.com/#dune-basics) * [SubQuery イーサリアムクイックスタートガイド （新しいタブで開きます）](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) * [SQDネットワークの概要 （新しいタブで開きます）](https://docs.sqd.dev/) * [EVM Query Language （新しいタブで開きます）](https://web.archive.org/web/20250719151453/https://www.eql.sh/blog/alpha-release-notes) [](https://ethereum.org/ja/developers/docs/data-and-analytics/#tutorials) チュートリアル: データと分析 / イーサリアム上のSQL ------------------------------------------------------------------------------------------------------- * [SQLでイーサリアムの基礎トピックを学ぶ](https://ethereum.org/ja/developers/tutorials/learn-foundational-ethereum-topics-with-sql/) _– SQLを使用してオンチェーンのイーサリアムデータをクエリし、トランザクション、ブロック、ガスの基礎を理解します。_ --- # Web3におけるデザインとUX | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/design-and-ux/#main-content) Change page Web3におけるデザインとUX =============== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/design-and-ux/index.md) このページの内容 イーサリアムでのデザインは初めてですか？ここはあなたにぴったりの場所です。イーサリアムコミュニティは、Web3のデザインとリサーチの基礎を紹介するリソースを作成しました。あなたが慣れ親しんでいる他のアプリのデザインとは異なるかもしれないコアコンセプトについて学びます。 まずWeb3のより基本的な理解が必要ですか？[**学習ハブ**](https://ethereum.org/ja/learn/) をチェックしてください。 [](https://ethereum.org/ja/developers/docs/design-and-ux/#start-with-user-research) ユーザーリサーチから始める ------------------------------------------------------------------------------------------------- 効果的なデザインは、視覚的に魅力的なユーザーインターフェースを作成するだけにとどまりません。ユーザーのニーズ、目的、および推進要因を深く理解することが含まれます。したがって、すべてのデザイナーが[**ダブルダイヤモンドプロセス** （新しいタブで開きます）](https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model)) などのデザインプロセスを採用し、意図的かつ計画的に作業を進めることを強くお勧めします。 現在最も差し迫ったUXの課題（ペインポイント）を確認したい場合は、こちらの\*\*[現在のUX課題マップ （新しいタブで開きます）](https://ethux.design/) \*\*をご覧ください。 * [Web3にはより多くのUXリサーチャーとデザイナーが必要 （新しいタブで開きます）](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - 現在のデザイン成熟度の概要 * [Web3におけるUXリサーチのシンプルなガイド （新しいタブで開きます）](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - リサーチの進め方に関するシンプルなガイド * [Web3におけるUXの意思決定へのアプローチ方法 （新しいタブで開きます）](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - 定量調査と定性調査の概要、および両者の違い（動画、6分） * [Web3のUXリサーチャーになること （新しいタブで開きます）](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - Web3のUXリサーチャーとはどのようなものかについての個人的な見解 [](https://ethereum.org/ja/developers/docs/design-and-ux/#research-in-web3) Web3におけるリサーチ研究 ------------------------------------------------------------------------------------------ これは、デザインやプロダクトの意思決定に役立つ、あるいは独自の研究を行うためのインスピレーションとなる、Web3で行われたユーザーリサーチの厳選されたリストです。 | 注力分野 | 名前 | | --- | --- | | 暗号資産のオンボーディング | [The Reown Pulse 2024: 暗号資産の消費者心理と利用状況 （新しいタブで開きます）](https://reown.com/blog/unveiling-walletconnects-consumer-crypto-report) | | 暗号資産のオンボーディング | [CRADL: 暗号資産におけるUX （新しいタブで開きます）](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) | | 暗号資産のオンボーディング | [CRADL: 暗号資産へのオンボーディング （新しいタブで開きます）](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) | | 暗号資産のオンボーディング | [ビットコインUXレポート （新しいタブで開きます）](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) | | 暗号資産のオンボーディング | [コンセンシス: 2023年 世界におけるWeb3認識の現状 （新しいタブで開きます）](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) | | 暗号資産のオンボーディング | [NEAR: 普及に向けた道のりの加速 （新しいタブで開きます）](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) | | ステーキング | [OpenUX: Rocket PoolノードオペレーターのUX （新しいタブで開きます）](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) | | ステーキング | [ステーキング: 主要なトレンド、要点、および予測 - Eth Staker （新しいタブで開きます）](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) | | ステーキング | [マルチアプリステーキング （新しいタブで開きます）](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20(MAS)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) | | DAO | [2022年 DAOリサーチアップデート: DAOビルダーが求めているものとは？ （新しいタブで開きます）](https://blog.aragon.org/2022-dao-research-update/) | | DeFi | [カバレッジプール （新しいタブで開きます）](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) | | DeFi | [コンセンシス: 分散型金融 (DeFi) ユーザーリサーチレポート 2022 （新しいタブで開きます）](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) | | メタバース | [メタバース: ユーザーリサーチレポート （新しいタブで開きます）](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) | | メタバース | [サファリへ行く: メタバースにおけるユーザーリサーチ （新しいタブで開きます）](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube)
（動画、27分） | [](https://ethereum.org/ja/developers/docs/design-and-ux/#design-for-web3) Web3のためのデザイン --------------------------------------------------------------------------------------- * [Web3デザインプレイブック （新しいタブで開きます）](https://learnweb3.design/) - デザイナーや創業者向けの、Web3のUX原則、DeFiパターン、ガバナンスデザイン、ウォレットUX、プロトコルレベルの思考に関するフレームワークとメモの包括的なコレクション * [Web3 UXデザインハンドブック （新しいタブで開きます）](https://web3ux.design/) - Web3アプリをデザインするための実践的なガイド * [Web3デザイン原則 （新しいタブで開きます）](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - ブロックチェーンベースの分散型アプリケーション (dapp) 向けのUXルールのフレームワーク * [ブロックチェーンデザイン原則 （新しいタブで開きます）](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - IBMのブロックチェーンデザインチームが学んだ教訓 * [Neueux.com （新しいタブで開きます）](https://neueux.com/apps) - 多様なフィルタリングオプションを備えたユーザーフローのUIライブラリ * [Web3のユーザビリティの危機: 知っておくべきこと！ （新しいタブで開きます）](https://www.youtube.com/watch?v=oBSXT_6YDzg) - 開発者中心のプロジェクト構築の落とし穴に関するパネルディスカッション（動画、34分） [](https://ethereum.org/ja/developers/docs/design-and-ux/#getting-started) はじめに ------------------------------------------------------------------------------- * [Web3のヒューリスティクス](https://ethereum.org/ja/developers/docs/design-and-ux/heuristics-for-web3/) - Web3インターフェースデザインのための7つのヒューリスティクス * [DEXデザインのベストプラクティス](https://ethereum.org/ja/developers/docs/design-and-ux/dex-design-best-practice/) - 分散型取引所 (DEX) をデザインするためのガイド [](https://ethereum.org/ja/developers/docs/design-and-ux/#design-case-studies) Web3デザインのケーススタディ ----------------------------------------------------------------------------------------------- * [Deep Work Studio （新しいタブで開きます）](https://www.deepwork.studio/case-studies) * [オープンシーでのNFT販売 （新しいタブで開きます）](https://builtformars.com/case-studies/opensea) * [ウォレットUXの分解: ウォレットはどのように変わるべきか （新しいタブで開きます）](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) （動画、20分） [](https://ethereum.org/ja/developers/docs/design-and-ux/#bounties) デザインバウンティ ----------------------------------------------------------------------------- * [Dework （新しいタブで開きます）](https://app.dework.xyz/bounties) * [Buildboxハッカソン （新しいタブで開きます）](https://app.buidlbox.io/) * [ETHGlobalハッカソン （新しいタブで開きます）](https://ethglobal.com/) [](https://ethereum.org/ja/developers/docs/design-and-ux/#design-daos-and-communities) デザインDAOとコミュニティ ----------------------------------------------------------------------------------------------------- プロフェッショナルなコミュニティ主導の組織に参加したり、デザイングループに加わったりして、デザインやリサーチに関連するトピックやトレンドについて他のメンバーと議論しましょう。 * [Vectordao.com （新しいタブで開きます）](https://vectordao.com/) * [Deepwork.studio （新しいタブで開きます）](https://www.deepwork.studio/) * [We3.co （新しいタブで開きます）](https://we3.co/) * [Openux.xyz （新しいタブで開きます）](https://openux.xyz/) [](https://ethereum.org/ja/developers/docs/design-and-ux/#design-systems-and-resources) デザインシステムとその他のデザインリソース ------------------------------------------------------------------------------------------------------------- * [オプティミズムデザイン （新しいタブで開きます）](https://www.figma.com/@optimism) (Figma) * [Ethereum.org デザインシステム （新しいタブで開きます）](https://www.figma.com/@ethdotorg) (Figma) * [Finity、ポリゴンによるデザインシステム （新しいタブで開きます）](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma) * [Kleros デザインシステム （新しいタブで開きます）](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma) * [Safe デザインシステム （新しいタブで開きます）](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma) * [ENS デザインシステム （新しいタブで開きます）](https://thorin.ens.domains/) * [Mirror デザインシステム （新しいタブで開きます）](https://degen-xyz.vercel.app/) **このページに掲載されている記事やプロジェクトは公式に推奨されているものではなく**、情報提供のみを目的としています。 当サイトの[掲載ポリシー](https://ethereum.org/ja/contributing/design/adding-design-resources/) の基準に基づいて、このページにリンクを追加しています。プロジェクトや記事の追加をご希望の場合は、[GitHub （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md) でこのページを編集してください。 --- # 이더리움 가상 머신(EVM) | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/evm/#main-content) Change page 이더리움 가상 머신(EVM) =============== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/evm/index.md) 이 페이지의 내용 이더리움 가상 머신(EVM)은 모든 [이더리움](https://ethereum.org/ko/) 노드에서 일관되고 안전하게 코드를 실행하는 탈중앙화된 가상 환경입니다. 노드는 EVM을 실행하여 스마트 컨트랙트를 실행하며, [작업](https://ethereum.org/ko/developers/docs/evm/opcodes/) 에 필요한 컴퓨팅 노력을 측정하기 위해 "[가스](https://ethereum.org/ko/developers/docs/gas/) "를 사용하여 효율적인 리소스 할당과 네트워크 보안을 보장합니다. [](https://ethereum.org/ko/developers/docs/evm/#prerequisites) 전제 조건 -------------------------------------------------------------------- EVM을 이해하려면 [바이트 (새 탭에서 열림)](https://wikipedia.org/wiki/Byte) , [메모리 (새 탭에서 열림)](https://wikipedia.org/wiki/Computer_memory) , [스택 (새 탭에서 열림)](https://wikipedia.org/wiki/Stack_(abstract_data_type)) 과 같은 컴퓨터 과학의 일반적인 용어에 대한 기본적인 지식이 필요합니다. 또한 [해시 함수 (새 탭에서 열림)](https://wikipedia.org/wiki/Cryptographic_hash_function) 및 [머클 트리 (새 탭에서 열림)](https://wikipedia.org/wiki/Merkle_tree) 와 같은 암호학/블록체인 개념에 익숙하면 도움이 됩니다. [](https://ethereum.org/ko/developers/docs/evm/#from-ledger-to-state-machine) 원장에서 상태 머신으로 ------------------------------------------------------------------------------------------ '분산 원장'이라는 비유는 암호학의 기본 도구를 사용하여 탈중앙화된 통화를 가능하게 하는 비트코인과 같은 블록체인을 설명하는 데 자주 사용됩니다. 원장은 누군가가 원장을 수정하기 위해 할 수 있는 일과 할 수 없는 일을 규정하는 일련의 규칙을 준수해야 하는 활동 기록을 유지합니다. 예를 들어, 비트코인 주소는 이전에 받은 것보다 더 많은 비트코인을 사용할 수 없습니다. 이러한 규칙은 비트코인 및 기타 여러 블록체인의 모든 트랜잭션을 뒷받침합니다. 이더리움에는 거의 동일한 직관적인 규칙을 따르는 자체 기본 암호화폐(이더)가 있지만, 훨씬 더 강력한 기능인 [스마트 컨트랙트](https://ethereum.org/ko/developers/docs/smart-contracts/) 도 가능하게 합니다. 이 더 복잡한 기능을 설명하려면 더 정교한 비유가 필요합니다. 분산 원장 대신, 이더리움은 분산 [상태 머신 (새 탭에서 열림)](https://wikipedia.org/wiki/Finite-state_machine) 입니다. 이더리움의 상태는 모든 계정과 잔액뿐만 아니라, 미리 정의된 규칙 세트에 따라 블록마다 변경될 수 있고 임의의 기계 코드를 실행할 수 있는 _머신 상태(machine state)_를 보유하는 대규모 데이터 구조입니다. 블록마다 상태를 변경하는 구체적인 규칙은 EVM에 의해 정의됩니다. [![A diagram showing the make up of the EVM](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fevm%2Fevm.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/evm/evm.png) _다이어그램 출처: [Ethereum EVM illustrated (새 탭에서 열림)](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) _ [](https://ethereum.org/ko/developers/docs/evm/#the-ethereum-state-transition-function) 이더리움 상태 전환 함수 ----------------------------------------------------------------------------------------------------- EVM은 수학 함수처럼 작동합니다. 입력이 주어지면 결정론적 출력을 생성합니다. 따라서 이더리움이 **상태 전환 함수**를 가지고 있다고 더 공식적으로 설명하는 것이 매우 도움이 됩니다. Y(S, T)= S' 복사 유효한 이전 상태 `(S)`와 유효한 트랜잭션의 새로운 세트 `(T)`가 주어지면, 이더리움 상태 전환 함수 `Y(S, T)`는 새로운 유효한 출력 상태 `S'`를 생성합니다. ### [](https://ethereum.org/ko/developers/docs/evm/#state) 상태 이더리움의 맥락에서 상태는 [수정된 머클 패트리샤 트라이](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) 라는 거대한 데이터 구조로, 모든 [계정](https://ethereum.org/ko/developers/docs/accounts/) 을 해시로 연결하고 블록체인에 저장된 단일 루트 해시로 축소할 수 있도록 유지합니다. ### [](https://ethereum.org/ko/developers/docs/evm/#transactions) 트랜잭션 트랜잭션은 계정에서 암호학적으로 서명된 명령입니다. 트랜잭션에는 메시지 호출을 초래하는 트랜잭션과 컨트랙트 생성을 초래하는 트랜잭션의 두 가지 유형이 있습니다. 컨트랙트 생성은 컴파일된 [스마트 컨트랙트](https://ethereum.org/ko/developers/docs/smart-contracts/anatomy/) 바이트코드를 포함하는 새로운 컨트랙트 계정의 생성으로 이어집니다. 다른 계정이 해당 컨트랙트에 메시지 호출을 할 때마다, 그 바이트코드가 실행됩니다. [](https://ethereum.org/ko/developers/docs/evm/#evm-instructions) EVM 명령어 ------------------------------------------------------------------------- EVM은 1024개 항목의 깊이를 가진 [스택 머신 (새 탭에서 열림)](https://wikipedia.org/wiki/Stack_machine) 으로 실행됩니다. 각 항목은 256비트 단어(word)이며, 이는 256비트 암호학(예: 케착-256 해시 또는 secp256k1 서명)과 쉽게 사용할 수 있도록 선택되었습니다. 실행 중에 EVM은 트랜잭션 간에 유지되지 않는 일시적인 _메모리_(단어 주소 지정 바이트 배열 형태)를 유지합니다. ### [](https://ethereum.org/ko/developers/docs/evm/#transient-storage) 임시 스토리지 임시 스토리지는 `TSTORE` 및 `TLOAD` 연산 코드를 통해 접근하는 트랜잭션별 키-값 저장소입니다. 동일한 트랜잭션 동안 모든 내부 호출에 걸쳐 유지되지만 트랜잭션이 끝나면 지워집니다. 메모리와 달리 임시 스토리지는 실행 프레임이 아닌 EVM 상태의 일부로 모델링되지만, 전역 상태에 커밋되지는 않습니다. 임시 스토리지는 트랜잭션 중 내부 호출 간에 가스 효율적인 임시 상태 공유를 가능하게 합니다. ### [](https://ethereum.org/ko/developers/docs/evm/#storage) 스토리지 컨트랙트에는 해당 계정과 연결되고 전역 상태의 일부인 머클 패트리샤 _스토리지_ 트라이(단어 주소 지정 단어 배열 형태)가 포함되어 있습니다. 이 영구 스토리지는 단일 트랜잭션 기간 동안만 사용할 수 있고 계정의 영구 스토리지 트라이의 일부를 구성하지 않는 임시 스토리지와 다릅니다. ### [](https://ethereum.org/ko/developers/docs/evm/#opcodes) 연산 코드 컴파일된 스마트 컨트랙트 바이트코드는 `XOR`, `AND`, `ADD`, `SUB` 등과 같은 표준 스택 작업을 수행하는 여러 EVM [연산 코드](https://ethereum.org/ko/developers/docs/evm/opcodes/) 로 실행됩니다. EVM은 또한 `ADDRESS`, `BALANCE`, `BLOCKHASH` 등과 같은 여러 블록체인 전용 스택 작업도 구현합니다. 연산 코드 세트에는 임시 스토리지에 대한 접근을 제공하는 `TSTORE` 및 `TLOAD`도 포함되어 있습니다. [![A diagram showing where gas is needed for EVM operations](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fgas%2Fgas.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/gas/gas.png) _다이어그램 출처: [Ethereum EVM illustrated (새 탭에서 열림)](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) _ [](https://ethereum.org/ko/developers/docs/evm/#evm-implementations) EVM 구현 --------------------------------------------------------------------------- EVM의 모든 구현은 이더리움 황서에 설명된 사양을 준수해야 합니다. 이더리움의 10년 역사 동안 EVM은 여러 차례 개정되었으며, 다양한 프로그래밍 언어로 된 여러 EVM 구현이 존재합니다. [이더리움 실행 클라이언트](https://ethereum.org/ko/developers/docs/nodes-and-clients/#execution-clients) 에는 EVM 구현이 포함되어 있습니다. 또한 다음과 같은 여러 독립형 구현도 있습니다. * [Py-EVM (새 탭에서 열림)](https://github.com/ethereum/py-evm) - _Python_ * [evmone (새 탭에서 열림)](https://github.com/ethereum/evmone) - _C++_ * [ethereumjs-vm (새 탭에서 열림)](https://github.com/ethereumjs/ethereumjs-vm) - _JavaScript_ * [revm (새 탭에서 열림)](https://github.com/bluealloy/revm) - _Rust_ [](https://ethereum.org/ko/developers/docs/evm/#further-reading) 더 읽을거리 ----------------------------------------------------------------------- * [이더리움 황서 (새 탭에서 열림)](https://ethereum.github.io/yellowpaper/paper.pdf) * [젤로페이퍼(Jellopaper) 일명 KEVM: K에서의 EVM 의미론 (새 탭에서 열림)](https://jellopaper.org/) * [베이지페이퍼(The Beigepaper) (새 탭에서 열림)](https://github.com/chronaeon/beigepaper) * [이더리움 가상 머신 연산 코드 (새 탭에서 열림)](https://www.ethervm.io/) * [이더리움 가상 머신 연산 코드 대화형 레퍼런스 (새 탭에서 열림)](https://www.evm.codes/) * [Solidity 문서의 짧은 소개 (새 탭에서 열림)](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) * [마스터링 이더리움 - 이더리움 가상 머신 (새 탭에서 열림)](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc) [](https://ethereum.org/ko/developers/docs/evm/#related-topics) 관련 주제 --------------------------------------------------------------------- * [가스](https://ethereum.org/ko/developers/docs/gas/) [](https://ethereum.org/ko/developers/docs/evm/#tutorials) 튜토리얼: 이더리움 가상 머신(EVM) / 이더리움 연산 코드 --------------------------------------------------------------------------------------------- * [황서의 EVM 사양 이해하기](https://ethereum.org/ko/developers/tutorials/yellow-paper-evm/) _– 이더리움 황서의 공식 EVM 사양에 대한 가이드._ * [컨트랙트 리버스 엔지니어링](https://ethereum.org/ko/developers/tutorials/reverse-engineering-a-contract/) _– EVM 연산 코드를 사용하여 컴파일된 스마트 컨트랙트를 리버스 엔지니어링하는 방법._ 이더리움 지식 테스트하기 ------------- --- # Go開発者のためのイーサリアム | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/programming-languages/golang/#main-content) Change page Go開発者のためのイーサリアム =============== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/golang/index.md) このページの内容 Goベースのプロジェクトとツールを使用してイーサリアム向けに開発する方法を学ぶ イーサリアムを使用して、分散型アプリケーション (dapp) を作成します。これらのdappは信頼性が高く、一度イーサリアムにデプロイされると、常にプログラムされた通りに実行されます。これらは分散型であり、ピア・ツー・ピアのネットワーク上で実行されるため、単一障害点がありません。単一の組織や個人がこれらを制御することはなく、検閲することはほぼ不可能です。これらはデジタル資産を制御して、新しい種類のアプリケーションを作成することができます。 [](https://ethereum.org/ja/developers/docs/programming-languages/golang/#getting-started-with-smart-contracts-and-solidity) スマート・コントラクトとSolidity言語の基礎 ----------------------------------------------------------------------------------------------------------------------------------------------------- **Goとイーサリアムを統合するための第一歩を踏み出す** まずはより基本的な入門書が必要ですか？ [ethereum.org/learn](https://ethereum.org/ja/learn/) または [ethereum.org/developers](https://ethereum.org/ja/developers/) を確認してください。 * [ブロックチェーンの解説 （新しいタブで開きます）](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [スマート・コントラクトの理解 （新しいタブで開きます）](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [初めてのスマート・コントラクトを作成する （新しいタブで開きます）](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Solidityのコンパイルとデプロイ方法を学ぶ （新しいタブで開きます）](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) * [コントラクトのチュートリアル （新しいタブで開きます）](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial) [](https://ethereum.org/ja/developers/docs/programming-languages/golang/#beginner-articles-and-books) 初心者向けの記事と書籍 ----------------------------------------------------------------------------------------------------------------- * [Gethの基礎 （新しいタブで開きます）](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458) * [Golangを使用してイーサリアムに接続する （新しいタブで開きます）](https://www.youtube.com/watch?v=-7uChuO_VzM) * [Golangを使用してイーサリアムのスマート・コントラクトをデプロイする （新しいタブで開きます）](https://www.youtube.com/watch?v=pytGqQmDslE) * [Goでイーサリアムのスマート・コントラクトをテストおよびデプロイするためのステップバイステップガイド （新しいタブで開きます）](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78) * [電子書籍: Goによるイーサリアム開発 （新しいタブで開きます）](https://goethereumbook.org/) - _Goでイーサリアムアプリケーションを開発する_ [](https://ethereum.org/ja/developers/docs/programming-languages/golang/#intermediate-articles-and-docs) 中級者向けの記事とドキュメント ------------------------------------------------------------------------------------------------------------------------ * [Go Ethereumドキュメント （新しいタブで開きます）](https://geth.ethereum.org/docs) - _公式のイーサリアムGolang実装のドキュメント_ * [エリゴン・プログラマーズガイド （新しいタブで開きます）](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _状態ツリー、マルチプルーフ、トランザクション処理を含む図解ガイド_ * [エリゴンとステートレス・イーサリアム （新しいタブで開きます）](https://youtu.be/3-Mn7OckSus?t=394) - _2020年イーサリアムコミュニティカンファレンス (EthCC 3)_ * [エリゴン: イーサリアムクライアントの最適化 （新しいタブで開きます）](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _2018年 Devcon 4_ * [Go Ethereum GoDoc （新しいタブで開きます）](https://godoc.org/github.com/ethereum/go-ethereum) * [Gethを使用してGoでdappを作成する （新しいタブで開きます）](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/) * [GolangとGethを使用してイーサリアムのプライベートネットワークを操作する （新しいタブで開きます）](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php) * [Goを使用してイーサリアム上のSolidityコントラクトをユニットテストする （新しいタブで開きます）](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281) * [Gethをライブラリとして使用するためのクイックリファレンス （新しいタブで開きます）](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e) [](https://ethereum.org/ja/developers/docs/programming-languages/golang/#advanced-use-patterns) 高度な使用パターン --------------------------------------------------------------------------------------------------------- * [GETHシミュレートバックエンド （新しいタブで開きます）](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top) * [イーサリアムとQuorumを使用したBlockchain-as-a-Serviceアプリ （新しいタブで開きます）](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html) * [イーサリアムのブロックチェーンアプリケーションにおける分散ストレージIPFSとスウォーム （新しいタブで開きます）](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html) * [モバイルクライアント: ライブラリとインプロセス・イーサリアムノード （新しいタブで開きます）](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes) * [ネイティブdapp: イーサリアムコントラクトへのGoバインディング （新しいタブで開きます）](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts) [](https://ethereum.org/ja/developers/docs/programming-languages/golang/#go-projects-and-tools) Goのプロジェクトとツール ------------------------------------------------------------------------------------------------------------- * [Geth / Go Ethereum （新しいタブで開きます）](https://github.com/ethereum/go-ethereum) - _イーサリアムプロトコルの公式Go実装_ * [Go Ethereumコード分析 （新しいタブで開きます）](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Go Ethereumソースコードのレビューと分析_ * [エリゴン （新しいタブで開きます）](https://github.com/ledgerwatch/erigon) - _アーカイブノードに焦点を当てた、Go Ethereumのより高速な派生版_ * [Golem （新しいタブで開きます）](https://github.com/golemfactory/golem) - _Golemはコンピューティングパワーのグローバル市場を構築しています_ * [Quorum （新しいタブで開きます）](https://github.com/jpmorganchase/quorum) - _データプライバシーをサポートするイーサリアムのパーミッションド実装_ * [プリズム （新しいタブで開きます）](https://github.com/prysmaticlabs/prysm) - _イーサリアム「Serenity」2.0のGo実装_ * [Eth Tweet （新しいタブで開きます）](https://github.com/yep/eth-tweet) - _分散型ツイッター: イーサリアムのブロックチェーン上で実行されるマイクロブログサービス_ * [Plasma MVP Golang （新しいタブで開きます）](https://github.com/kyokan/plasma) — _Minimum Viable Plasma仕様のGolang実装および拡張_ * [Open Ethereum Mining Pool （新しいタブで開きます）](https://github.com/sammy007/open-ethereum-pool) - _オープンソースのイーサリアムのマイニングプール_ * [Ethereum HD Wallet （新しいタブで開きます）](https://github.com/miguelmota/go-ethereum-hdwallet) - _GoでのイーサリアムHDウォレットの派生_ * [Multi Geth （新しいタブで開きます）](https://github.com/multi-geth/multi-geth) - _多くの種類のイーサリアムネットワークのサポート_ * [Gethライト・クライアント （新しいタブで開きます）](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _Light Ethereum SubprotocolのGeth実装_ * [Ethereum Golang SDK （新しいタブで開きます）](https://github.com/everFinance/goether) - _Golangでのシンプルなイーサリアムウォレット実装とユーティリティ_ * [Covalent Golang SDK （新しいタブで開きます）](https://github.com/covalenthq/covalent-api-sdk-go) - _200以上のブロックチェーンに対するGo SDKを介した効率的なブロックチェーンデータアクセス_ さらにリソースをお探しですか？ [ethereum.org/developers](https://ethereum.org/ja/developers/) を確認してください。 [](https://ethereum.org/ja/developers/docs/programming-languages/golang/#go-community-contributors) Goコミュニティの貢献者 ---------------------------------------------------------------------------------------------------------------- * [Gethディスコード （新しいタブで開きます）](https://discordapp.com/invite/nthXNEv) * [Geth Gist （新しいタブで開きます）](https://gitter.im/ethereum/go-ethereum) * [Gophers Slack （新しいタブで開きます）](https://invite.slack.golangbridge.org/) - [#ethereum チャンネル （新しいタブで開きます）](https://gophers.slack.com/messages/C9HP1S9V2) * [StackExchange - イーサリアム （新しいタブで開きます）](https://ethereum.stackexchange.com/) * [Multi Geth Gitter （新しいタブで開きます）](https://gitter.im/ethoxy/multi-geth) * [イーサリアム Gitter （新しいタブで開きます）](https://gitter.im/ethereum/home) * [Gethライト・クライアント Gitter （新しいタブで開きます）](https://gitter.im/ethereum/light-client) [](https://ethereum.org/ja/developers/docs/programming-languages/golang/#other-aggregated-lists) その他のまとめリスト ----------------------------------------------------------------------------------------------------------- * [Awesome Ethereum （新しいタブで開きます）](https://github.com/btomashvili/awesome-ethereum) * [コンセンシス: イーサリアム開発者ツールの決定版リスト （新しいタブで開きます）](https://web.archive.org/web/2023/https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [GitHubソース （新しいタブで開きます）](https://github.com/ConsenSys/ethereum-developer-tools-list) --- # Rust開発者のためのイーサリアム | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/programming-languages/rust/#main-content) Change page Rust開発者のためのイーサリアム ================= .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/rust/index.md) このページの内容 Rustベースのプロジェクトやツールを使用してイーサリアム向けに開発する方法を学びます イーサリアムを使用して、暗号資産とブロックチェーン技術の利点を活用した分散型アプリケーション (dapp) を作成します。これらのdappは信頼性が高く、一度イーサリアムにデプロイされると、常にプログラムされた通りに実行されます。デジタル資産を制御して、新しい種類の金融アプリケーションを作成できます。また、分散型であるため、単一の組織や個人が制御することはなく、検閲することはほぼ不可能です。 [](https://ethereum.org/ja/developers/docs/programming-languages/rust/#getting-started-with-smart-contracts-and-solidity) スマート・コントラクトとSolidity言語の基礎 --------------------------------------------------------------------------------------------------------------------------------------------------- **Rustをイーサリアムに統合するための第一歩を踏み出しましょう** まずは基本的な入門書が必要ですか？ [ethereum.org/learn](https://ethereum.org/ja/learn/) または [ethereum.org/developers](https://ethereum.org/ja/developers/) を確認してください。 * [ブロックチェーンの解説 （新しいタブで開きます）](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [スマート・コントラクトの理解 （新しいタブで開きます）](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [初めてのスマート・コントラクトを作成する （新しいタブで開きます）](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Solidityのコンパイルとデプロイ方法を学ぶ （新しいタブで開きます）](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) [](https://ethereum.org/ja/developers/docs/programming-languages/rust/#beginner-articles) 初心者向けの記事 -------------------------------------------------------------------------------------------------- * [Rustイーサリアムクライアント （新しいタブで開きます）](https://openethereum.github.io/) \* **OpenEthereumは[非推奨となり （新しいタブで開きます）](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) 、現在はメンテナンスされていないことに注意してください。** 使用には注意し、できれば別のクライアント実装に切り替えてください。 * [Rustを使用してイーサリアムにトランザクションを送信する （新しいタブで開きます）](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/) * [Kovan向けにRust Wasmでコントラクトを作成する方法のステップバイステップチュートリアル （新しいタブで開きます）](https://github.com/paritytech/pwasm-tutorial) [](https://ethereum.org/ja/developers/docs/programming-languages/rust/#intermediate-articles) 中級者向けの記事 ------------------------------------------------------------------------------------------------------ [](https://ethereum.org/ja/developers/docs/programming-languages/rust/#advanced-use-patterns) 高度な使用パターン ------------------------------------------------------------------------------------------------------- * [イーサリアムのようなネットワークと対話するためのpwasm\_ethereum externsライブラリ （新しいタブで開きます）](https://github.com/openethereum/pwasm-ethereum) * [JavaScriptとRustを使用して分散型チャットを構築する （新しいタブで開きます）](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52) * [Vue.jsとRustを使用して分散型Todoアプリを構築する （新しいタブで開きます）](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb) * [Rustでブロックチェーンを構築する （新しいタブで開きます）](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/) [](https://ethereum.org/ja/developers/docs/programming-languages/rust/#rust-projects-and-tools) Rustのプロジェクトとツール --------------------------------------------------------------------------------------------------------------- * [pwasm-ethereum （新しいタブで開きます）](https://github.com/paritytech/pwasm-ethereum) - _イーサリアムのようなネットワークと対話するためのexternsのコレクション_ * [ライトハウス （新しいタブで開きます）](https://github.com/sigp/lighthouse) - _高速なイーサリアムのコンセンサス・レイヤークライアント_ * [Ethereum WebAssembly （新しいタブで開きます）](https://ewasm.readthedocs.io/en/mkdocs/) - _WebAssemblyの決定論的サブセットを使用した、イーサリアムのスマート・コントラクト実行レイヤーの再設計の提案_ * [oasis\_std （新しいタブで開きます）](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _OASIS APIリファレンス_ * [Solaris （新しいタブで開きます）](https://github.com/paritytech/sol-rs) - _ネイティブのParityクライアントEVMを使用したSolidityスマート・コントラクトの単体テストハーネス。_ * [SputnikVM （新しいタブで開きます）](https://github.com/rust-blockchain/evm) - _Rustによるイーサリアム仮想マシンの実装_ * [Wavelet （新しいタブで開きます）](https://github.com/perlin-network/smart-contract-rs) - _RustによるWaveletスマート・コントラクト_ * [Foundry （新しいタブで開きます）](https://github.com/foundry-rs/foundry) - _イーサリアムアプリケーション開発のためのツールキット_ * [Alloy （新しいタブで開きます）](https://alloy.rs/) - _イーサリアムやその他のEVMベースのチェーンと対話するための、高性能で十分にテストされ文書化されたライブラリ。_ * [Ethers\_rs （新しいタブで開きます）](https://github.com/gakonst/ethers-rs) - _イーサリアムライブラリとウォレットの実装_ * [SewUp （新しいタブで開きます）](https://github.com/second-state/SewUp) - _一般的なバックエンド開発のように、RustでイーサリアムのWebAssemblyコントラクトを構築するのに役立つライブラリ_ * [Substreams （新しいタブで開きます）](https://github.com/streamingfast/substreams) - _並列化されたブロックチェーンデータインデックス技術_ * [レス （新しいタブで開きます）](https://github.com/paradigmxyz/reth) レス (Rust Ethereumの略) は、新しいイーサリアムのフルノード実装です * [Awesome Ethereum Rust （新しいタブで開きます）](https://github.com/Vid201/awesome-ethereum-rust) - _Rustで書かれたイーサリアムエコシステムのプロジェクトの厳選されたコレクション_ * [Stylus （新しいタブで開きます）](https://github.com/OffchainLabs/stylus) - _Arbitrum上でスマート・コントラクトを構築するためのRust SDK_ さらにリソースをお探しですか？ [ethereum.org/developers.](https://ethereum.org/ja/developers/) [](https://ethereum.org/ja/developers/docs/programming-languages/rust/#rust-community-contributors) Rustコミュニティの貢献者 ------------------------------------------------------------------------------------------------------------------ * [Ethereum WebAssembly （新しいタブで開きます）](https://gitter.im/ewasm/Lobby) * [Oasis Gitter （新しいタブで開きます）](https://gitter.im/Oasis-official/Lobby) * [Parity Gitter （新しいタブで開きます）](https://gitter.im/paritytech/parity) * [Enigma （新しいタブで開きます）](https://discord.gg/SJK32GY) --- # .NET開発者のためのイーサリアム | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/programming-languages/dot-net/#main-content) Change page .NET開発者のためのイーサリアム ================= .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/dot-net/index.md) このページの内容 .NETベースのプロジェクトやツールを使用してイーサリアム向けに開発する方法を学ぶ イーサリアムを使用して、暗号資産とブロックチェーン技術の利点を活用する分散型アプリケーション (dapp) を作成します。これらのdappは信頼性が高く、一度イーサリアムにデプロイされると、常にプログラムされた通りに実行されます。デジタル資産を制御して、新しい種類の金融アプリケーションを作成できます。また、分散型であるため、単一の組織や個人が制御することはなく、検閲することはほぼ不可能です。 マイクロソフトのテクノロジースタックのツールとプログラミング言語を使用して、イーサリアム上に分散型アプリケーションを構築し、スマート・コントラクトと対話します。VSCodeやVisual Studioなどのツール上で、.NET Framework / .NET Core / .NET Standard全体にわたり、C#、Visual Basic .NET、F#をサポートしています。Microsoft Azure Blockchainを使用して、数分でAzure上にイーサリアムのブロックチェーンをデプロイできます。.NETへの愛をイーサリアムにもたらしましょう！ [](https://ethereum.org/ja/developers/docs/programming-languages/dot-net/#getting-started-with-smart-contracts-and-the-solidity-language) スマート・コントラクトとSolidity言語の基礎 ------------------------------------------------------------------------------------------------------------------------------------------------------------------- **.NETとイーサリアムを統合するための第一歩を踏み出す** まずはより基本的な入門書が必要ですか？[ethereum.org/learn](https://ethereum.org/ja/learn/) または[ethereum.org/developers](https://ethereum.org/ja/developers/) を確認してください。 * [ブロックチェーンの解説 （新しいタブで開きます）](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [スマート・コントラクトの理解 （新しいタブで開きます）](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [初めてのスマート・コントラクトを作成する （新しいタブで開きます）](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Solidityのコンパイルとデプロイ方法を学ぶ （新しいタブで開きます）](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) [](https://ethereum.org/ja/developers/docs/programming-languages/dot-net/#beginner-references-and-links) 初心者向けのリファレンスとリンク ------------------------------------------------------------------------------------------------------------------------- **NethereumライブラリとVS Code Solidityの紹介** * [Nethereum、はじめに （新しいタブで開きます）](https://docs.nethereum.com/docs/getting-started/welcome/) * [VS Code Solidityのインストール （新しいタブで開きます）](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) * [.NET開発者向けのイーサリアムのスマート・コントラクトの作成と呼び出しのワークフロー （新しいタブで開きます）](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2) * [Nethereumを使用したスマート・コントラクトの統合 （新しいタブで開きます）](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm) * [Nethereumを使用した.NETとイーサリアムのブロックチェーンのスマート・コントラクトのインターフェース （新しいタブで開きます）](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933) 、[中文版 （新しいタブで開きます）](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1) もあります * [Nethereum - ブロックチェーン向けのオープンソース.NET統合ライブラリ （新しいタブで開きます）](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/) * [Nethereumを使用してイーサリアムのトランザクションをSQLデータベースに書き込む （新しいタブで開きます）](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36) * [C#とVisualStudioを使用してイーサリアムのスマート・コントラクトを簡単にデプロイする方法 （新しいタブで開きます）](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c) **セットアップをスキップして、すぐにサンプルを見たいですか？** * [Nethereum Playground （新しいタブで開きます）](https://playground.nethereum.com/) - ブラウザを通じてイーサリアムと対話し、Nethereumの使用方法を学びます。 * [アカウント残高の照会 （新しいタブで開きます）](https://docs.nethereum.com/docs/core-foundation/guide-query-balance) * [ERC-20スマート・コントラクト残高の照会 （新しいタブで開きます）](https://docs.nethereum.com/docs/smart-contracts/erc20) * [アカウントへのイーサの送金 （新しいタブで開きます）](https://docs.nethereum.com/docs/core-foundation/guide-send-eth) * ... その他多数！ [](https://ethereum.org/ja/developers/docs/programming-languages/dot-net/#intermediate-articles) 中級者向けの記事 --------------------------------------------------------------------------------------------------------- * [Nethereumのはじめにと最初のプロジェクト （新しいタブで開きます）](https://docs.nethereum.com/docs/getting-started/first-project) * [独自の開発用テストチェーンのデプロイ （新しいタブで開きます）](https://github.com/Nethereum/Testchains) * [NethereumとVS Codeを使用したコード生成 （新しいタブで開きます）](https://docs.nethereum.com/docs/smart-contracts/code-generation/) * [Unityとイーサリアム: その理由と方法 （新しいタブで開きます）](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how) * [イーサリアムの分散型アプリケーション (dapp) 向けASP.NET Core Web APIの作成 （新しいタブで開きます）](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/) * [構造化されたオンチェーンアプリケーション向けのNethereum MUDフレームワーク （新しいタブで開きます）](https://docs.nethereum.com/docs/mud-framework/overview/) * [Nethereumのブロックチェーン処理 （新しいタブで開きます）](https://docs.nethereum.com/docs/data-and-indexing/guide-blockchain-processing) * [Nethereumのリアルタイムストリーミング （新しいタブで開きます）](https://docs.nethereum.com/docs/core-foundation/guide-realtime-streaming/) * [KaleidoとNethereum （新しいタブで開きます）](https://kaleido.io/kaleido-and-nethereum/) * [QuorumとNethereum （新しいタブで開きます）](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md) [](https://ethereum.org/ja/developers/docs/programming-languages/dot-net/#advanced-use-patterns) 高度な使用パターン ---------------------------------------------------------------------------------------------------------- * [Azure Key VaultとNethereum （新しいタブで開きます）](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum) * [Nethereum.DappHybrid （新しいタブで開きます）](https://github.com/Nethereum/Nethereum.DappHybrid) * [Ujo Nethereumバックエンドのリファレンスアーキテクチャ （新しいタブで開きます）](https://github.com/Nethereum/ujo-backend) [](https://ethereum.org/ja/developers/docs/programming-languages/dot-net/#dot-net-projects-tools-and-other-fun-stuff) .NETプロジェクト、ツール、その他の楽しいコンテンツ ------------------------------------------------------------------------------------------------------------------------------------------------- * [Nethereum Playground （新しいタブで開きます）](https://playground.nethereum.com/) - _ブラウザでNethereumのコードスニペットをコンパイル、作成、実行します_ * [Nethereum Codegen Blazor （新しいタブで開きます）](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _BlazorのUIを備えたNethereumのコード生成_ * [Nethereum Blazor （新しいタブで開きます）](https://github.com/Nethereum/NethereumBlazor) - _.NET Wasm SPAの軽量ブロックチェーンエクスプローラーおよびシンプルなウォレット_ * [Wonka Business Rules Engine （新しいタブで開きます）](https://github.com/Nethereum/Wonka) - _本質的にメタデータ駆動型であるビジネスルールエンジン (.NETプラットフォームとイーサリアムプラットフォームの両方向け)_ * [ネザーマインド （新しいタブで開きます）](https://github.com/NethermindEth/nethermind) - _Linux、Windows、MacOS向けの.NET Coreイーサリアムクライアント_ * [eth-utils （新しいタブで開きます）](https://github.com/ethereum/eth-utils/) - _イーサリアム関連のコードベースを操作するためのユーティリティ関数_ * [TestChains （新しいタブで開きます）](https://github.com/Nethereum/TestChains) - _高速な応答のための事前構成された.NET開発チェーン (プルーフ・オブ・オーソリティ (PoA))_ さらにリソースをお探しですか？[ethereum.org/developers](https://ethereum.org/ja/developers/) を確認してください。 [](https://ethereum.org/ja/developers/docs/programming-languages/dot-net/#dot-net-community-contributors) .NETコミュニティのコントリビューター ------------------------------------------------------------------------------------------------------------------------------ Nethereumでは、主に[Gitter （新しいタブで開きます）](https://gitter.im/Nethereum/Nethereum) で活動しており、誰でも質問や回答、サポートを受けたり、単にくつろいだりすることができます。[NethereumのGitHubリポジトリ （新しいタブで開きます）](https://github.com/Nethereum) でPRを作成したり、Issueを開いたり、多数のサイドプロジェクトやサンプルプロジェクトを閲覧したりしてください。[ディスコード （新しいタブで開きます）](https://discord.gg/jQPrR58FxX) でも私たちを見つけることができます！ ネザーマインドを初めて使用し、開始にあたってサポートが必要な場合は、私たちの[ディスコード （新しいタブで開きます）](https://discord.gg/PaCMRFdvWT) に参加してください。開発者が質問にお答えします。[ネザーマインドのGitHubリポジトリ （新しいタブで開きます）](https://github.com/NethermindEth/nethermind) でPRを作成したり、Issueを提起したりすることをためらわないでください。 [](https://ethereum.org/ja/developers/docs/programming-languages/dot-net/#other-aggregated-lists) その他の集約リスト ----------------------------------------------------------------------------------------------------------- [Nethereum公式サイト （新しいタブで開きます）](https://nethereum.com/) [ネザーマインド公式サイト （新しいタブで開きます）](https://nethermind.io/) --- # इथेरियम बूटनोड का परिचय | ethereum.org [मुख्य सामग्री पर जाएं](https://ethereum.org/hi/developers/docs/nodes-and-clients/bootnodes/#main-content) Change page इथेरियम बूटनोड का परिचय ======================= .md कॉपी करें.md कॉपी करें [पेज संपादित करें (नए टैब में खुलता है)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/nodes-and-clients/bootnodes/index.md) इस पेज पर जब कोई नया नोड इथेरियम नेटवर्क से जुड़ता है, तो उसे नए पीयर्स (peers) खोजने के लिए उन नोड्स से जुड़ना होता है जो पहले से ही नेटवर्क पर मौजूद हैं। इथेरियम नेटवर्क में इन प्रवेश बिंदुओं को बूटनोड कहा जाता है। क्लाइंट्स में आमतौर पर बूटनोड्स की एक सूची हार्डकोड की गई होती है। ये बूटनोड आमतौर पर एथेरियम फाउंडेशन की डेवऑप्स (devops) टीम या स्वयं क्लाइंट टीमों द्वारा चलाए जाते हैं। ध्यान दें कि बूटनोड और स्टैटिक नोड समान नहीं होते हैं। स्टैटिक नोड्स को बार-बार कॉल किया जाता है, जबकि बूटनोड्स को केवल तभी कॉल किया जाता है जब कनेक्ट करने के लिए पर्याप्त पीयर्स न हों और किसी नोड को कुछ नए कनेक्शन बूटस्ट्रैप करने की आवश्यकता हो। [](https://ethereum.org/hi/developers/docs/nodes-and-clients/bootnodes/#connect-to-a-bootnode) बूटनोड से कनेक्ट करें -------------------------------------------------------------------------------------------------------------------- अधिकांश क्लाइंट्स में बूटनोड्स की एक अंतर्निहित (builtin) सूची होती है, लेकिन आप अपना खुद का बूटनोड भी चलाना चाह सकते हैं, या किसी ऐसे बूटनोड का उपयोग करना चाह सकते हैं जो क्लाइंट की हार्डकोडेड सूची का हिस्सा नहीं है। इस मामले में, आप अपने क्लाइंट को शुरू करते समय उन्हें इस प्रकार निर्दिष्ट कर सकते हैं (उदाहरण Geth के लिए है, कृपया अपने क्लाइंट का दस्तावेज़ देखें): geth --bootnodes "enode://@:" कॉपी करें [](https://ethereum.org/hi/developers/docs/nodes-and-clients/bootnodes/#run-a-bootnode) बूटनोड चलाएं ---------------------------------------------------------------------------------------------------- बूटनोड ऐसे पूर्ण नोड होते हैं जो NAT ([नेटवर्क एड्रेस ट्रांसलेशन (नए टैब में खुलता है)](https://www.geeksforgeeks.org/network-address-translation-nat/) ) के पीछे नहीं होते हैं। हर पूर्ण नोड एक बूटनोड के रूप में कार्य कर सकता है जब तक कि वह सार्वजनिक रूप से उपलब्ध हो। जब आप कोई नोड शुरू करते हैं तो उसे आपके [enode](https://ethereum.org/hi/developers/docs/networking-layer/network-addresses/#enode) को लॉग करना चाहिए, जो एक सार्वजनिक पहचानकर्ता (identifier) है जिसका उपयोग अन्य लोग आपके नोड से जुड़ने के लिए कर सकते हैं। enode आमतौर पर हर रीस्टार्ट पर फिर से जनरेट होता है, इसलिए अपने बूटनोड के लिए एक स्थायी (persistent) enode जनरेट करने के तरीके के बारे में अपने क्लाइंट के दस्तावेज़ को देखना सुनिश्चित करें। एक अच्छा बूटनोड बनने के लिए, इससे जुड़ने वाले पीयर्स की अधिकतम संख्या बढ़ाना एक अच्छा विचार है। कई पीयर्स के साथ बूटनोड चलाने से बैंडविड्थ की आवश्यकता काफी बढ़ जाएगी। [](https://ethereum.org/hi/developers/docs/nodes-and-clients/bootnodes/#available-bootnodes) उपलब्ध बूटनोड ---------------------------------------------------------------------------------------------------------- go-ethereum के भीतर अंतर्निहित बूटनोड्स की एक सूची [यहां (नए टैब में खुलता है)](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23) पाई जा सकती है। इन बूटनोड्स का रखरखाव एथेरियम फाउंडेशन और go-ethereum टीम द्वारा किया जाता है। स्वयंसेवकों द्वारा बनाए रखी गई बूटनोड्स की अन्य सूचियां भी उपलब्ध हैं। कृपया हमेशा कम से कम एक आधिकारिक बूटनोड शामिल करना सुनिश्चित करें, अन्यथा आप पर एक्लिप्स अटैक (eclipse attack) हो सकता है। --- # 스마트 컨트랙트와 상호작용하기 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#main-content) Change page 스마트 컨트랙트와 상호작용하기 ================ .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/interacting/index.md) 이 페이지의 내용 항상 직접 스마트 컨트랙트를 작성하고 배포해야 하는 것은 아닙니다. 개발자로서 대부분의 경우 다른 사람들이 이더리움 네트워크에 이미 배포한 스마트 컨트랙트와 상호작용하게 될 것입니다. 이 페이지에서는 스마트 컨트랙트와 상호작용하는 두 가지 기본 방법인 데이터 **읽기**와 데이터 **쓰기**, 그리고 이 두 가지를 수행하는 데 필요한 도구에 대해 다룹니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#prerequisites) 전제 조건 -------------------------------------------------------------------------------------------- 다음 내용을 이해하고 있어야 합니다. * [스마트 컨트랙트 작동 방식](https://ethereum.org/ko/developers/docs/smart-contracts/) * [이더리움 계정과 트랜잭션에 서명하는 방법](https://ethereum.org/ko/developers/docs/accounts/) * [트랜잭션이란 무엇인가](https://ethereum.org/ko/developers/docs/transactions/) [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#two-ways) 스마트 컨트랙트와 상호작용하는 두 가지 방법 ---------------------------------------------------------------------------------------------------------- 스마트 컨트랙트와의 상호작용은 두 가지 범주로 나뉩니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#reading-from-a-contract) 컨트랙트에서 읽기 읽기는 트랜잭션을 생성하지 않고 블록체인의 어떤 상태도 변경하지 않는 **무료** 작업입니다. 컨트랙트에서 읽을 때는 단순히 이미 존재하는 데이터를 조회하는 것입니다. 예를 들면 다음과 같습니다. * ERC-20 토큰 잔액 확인 * 탈중앙화 거래소에서 현재 가격 읽기 * NFT 소유자 가져오기 읽기는 상태를 수정하지 않으므로 [가스](https://ethereum.org/ko/developers/docs/gas/) 비용이 들지 않으며, ETH가 없어도 누구나 수행할 수 있습니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#writing-to-a-contract) 컨트랙트에 쓰기 쓰기는 트랜잭션이 필요하고 가스 비용이 드는 **상태 변경** 작업입니다. 컨트랙트에 쓸 때는 블록체인 상태를 수정하는 함수를 트리거하는 것입니다. 예를 들면 다음과 같습니다. * 토큰 전송 * 탈중앙화 거래소에서 토큰 스왑 * NFT 발행 쓰기에는 항상 다음이 필요합니다. 1. 가스 비용을 지불할 충분한 ETH가 있는 [외부 소유 계정(EOA)](https://ethereum.org/ko/developers/docs/accounts/#types-of-account) 2. 계정의 개인 키로 서명된 트랜잭션 3. 채굴되어 블록에 포함될 트랜잭션 [계정 추상화](https://ethereum.org/ko/roadmap/account-abstraction/) 를 사용하면 스마트 컨트랙트 계정도 쓰기를 시작할 수 있으며, 페이마스터가 사용자를 대신하여 가스를 지불할 수 있으므로 ETH를 보유한 EOA가 반드시 필요한 것은 아닙니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#understanding-contract-abis) 컨트랙트 ABI 이해하기 ------------------------------------------------------------------------------------------------------------------ 스마트 컨트랙트와 상호작용하려면 애플리케이션이 컨트랙트가 _무엇을_ 할 수 있는지 알아야 합니다. 이때 \*\*애플리케이션 바이너리 인터페이스(ABI)\*\*가 필요합니다. ABI는 다음을 설명하는 JSON 문서입니다. * 컨트랙트가 노출하는 모든 함수(이름, 입력, 출력) * 컨트랙트가 발생시킬 수 있는 모든 이벤트 * 컨트랙트와 통신할 때 데이터를 인코딩하고 디코딩하는 방법 ABI를 컨트랙트의 사용 설명서라고 생각하세요. ABI가 없으면 애플리케이션은 어떤 함수가 존재하는지, 어떤 매개변수를 예상하는지 알 수 없습니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#where-to-find-abis) 컨트랙트 ABI를 찾을 수 있는 곳 * **Etherscan의 검증된 컨트랙트** - [Etherscan (새 탭에서 열림)](https://etherscan.io/) 은 검증된 소스 코드에 대한 ABI를 자동으로 노출합니다. * **개발자로부터** - 많은 프로젝트가 문서나 npm 패키지에 ABI를 게시합니다. * **소스에서 생성** - Solidity 소스 코드가 있는 경우, 이를 [컴파일하여](https://ethereum.org/ko/developers/docs/smart-contracts/compiling/) ABI를 생성할 수 있습니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#tools-and-libraries) 컨트랙트와 상호작용하기 위한 도구 및 라이브러리 ----------------------------------------------------------------------------------------------------------------------- 개발자는 일반적으로 웹 앱, 백엔드 또는 스크립트에서 컨트랙트와 상호작용하기 위해 JavaScript/TypeScript 라이브러리를 사용합니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#client-libraries) 클라이언트 라이브러리(JavaScript/TypeScript) * **[Viem (새 탭에서 열림)](https://viem.sh/) ** - 최고 수준의 타입 안정성을 갖춘 이더리움용 최신 경량 TypeScript 인터페이스 * **[ethers.js (새 탭에서 열림)](https://docs.ethers.org/) ** - 이더리움 블록체인과 상호작용하기 위해 실전에서 검증된 라이브러리 * **[Web3.js (새 탭에서 열림)](https://web3js.org/) ** - 오리지널 이더리움 JavaScript API ### [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#backend-libraries) 백엔드 라이브러리 * **[ethers.js (새 탭에서 열림)](https://docs.ethers.org/) ** - 서버 측 스크립트 및 봇을 위해 Node.js에서도 작동합니다. * **[Web3.py (새 탭에서 열림)](https://web3py.readthedocs.io/) ** - 이더리움 상호작용을 위한 Python 라이브러리 * **[go-ethereum (새 탭에서 열림)](https://geth.ethereum.org/docs/interact-with-geth) ** - Geth 팀의 공식 Go 라이브러리 ### [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#example-viem) 예시: Viem으로 토큰 잔액 읽기 import { createPublicClient, http, formatUnits } from 'viem' import { mainnet } from 'viem/chains' // USDC 컨트랙트 주소 및 ABI (balanceOf용 일부) const USDC = '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48' const abi = [{\ name: 'balanceOf',\ type: 'function',\ stateMutability: 'view',\ inputs: [{ name: 'account', type: 'address' }],\ outputs: [{ name: '', type: 'uint256' }],\ }] as const const client = createPublicClient({ chain: mainnet, transport: http() }) const balance = await client.readContract({ address: USDC, abi, functionName: 'balanceOf', args: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045'], // vitalik.eth }) console.log(formatUnits(balance, 6)) // USDC는 소수점 6자리를 가집니다 복사TS 모두 보기 (23) ### [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#example-ethers) 예시: ethers.js로 트랜잭션 보내기 const { ethers } = require('ethers') const provider = new ethers.JsonRpcProvider(process.env.RPC_URL) const wallet = new ethers.Wallet(process.env.PRIVATE_KEY, provider) // ERC-20 transfer ABI const abi = ['function transfer(address to, uint256 amount) returns (bool)'] const contract = new ethers.Contract(tokenAddress, abi, wallet) const tx = await contract.transfer(recipient, ethers.parseUnits('10', 18)) await tx.wait() // 트랜잭션이 채굴되기를 기다립니다 console.log(`Transferred! TX: ${tx.hash}`) 복사JS 모두 보기 (12) [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#events-and-logs) 이벤트 및 로그 ------------------------------------------------------------------------------------------------- 스마트 컨트랙트는 무언가 발생했음을 알리기 위해 **이벤트**를 발생시킬 수 있습니다. 애플리케이션은 이러한 이벤트를 수신하여 실시간으로 반응할 수 있습니다. import { createPublicClient, http, parseAbiItem } from 'viem' import { mainnet } from 'viem/chains' const client = createPublicClient({ chain: mainnet, transport: http() }) // USDC Transfer 이벤트를 감시합니다 const unwatch = client.watchEvent({ event: parseAbiItem('event Transfer(address indexed from, address indexed to, uint256 value)'), onLogs: (logs) => console.log(logs), }) 복사TS 모두 보기 (10) [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#simulating) 트랜잭션 시뮬레이션 ---------------------------------------------------------------------------------------------- 트랜잭션을 보내기 전에 가스를 소비하지 않고도 트랜잭션이 성공할지 확인하고 반환 값을 보기 위해 **시뮬레이션**할 수 있습니다. 이는 오류를 조기에 발견하고 결과를 미리 보는 데 유용합니다. 대부분의 클라이언트 라이브러리는 `eth_call`를 통해 이를 지원합니다. // Viem 사용 const result = await client.simulateContract({ address: contractAddress, abi, functionName: 'swap', args: [amountIn], account: userAddress, }) 복사TS [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#wallets-and-signing) 지갑 및 서명하기 ------------------------------------------------------------------------------------------------------ 탈중앙화 애플리케이션(dapp)에서는 사용자의 지갑(메타마스크, Rainbow 또는 WalletConnect 등)이 서명하기를 처리합니다. 개인 키를 직접 관리하지 않습니다. [지갑 라이브러리 및 연결 도구](https://ethereum.org/ko/developers/docs/apis/javascript/) 는 이를 추상화하므로 애플리케이션 로직을 구축하는 데 집중할 수 있습니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#related-tutorials) 관련 튜토리얼 -------------------------------------------------------------------------------------------------- * [JavaScript에서 스마트 컨트랙트 호출하기](https://ethereum.org/ko/developers/tutorials/calling-a-smart-contract-from-javascript/) * [Web3.js 및 Alchemy를 사용하여 트랜잭션 보내기](https://ethereum.org/ko/developers/tutorials/sending-transactions-using-web3-and-alchemy/) * [지갑에서 NFT를 보는 방법](https://ethereum.org/ko/developers/tutorials/how-to-view-nft-in-metamask/) [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#further-reading) 더 읽을거리 ----------------------------------------------------------------------------------------------- * [Viem 문서: 컨트랙트 읽기 및 쓰기 (새 탭에서 열림)](https://viem.sh/docs/contract/readContract) * [ethers.js 문서: 컨트랙트 (새 탭에서 열림)](https://docs.ethers.org/v6/api/contract/) * [Solidity ABI 사양 (새 탭에서 열림)](https://docs.soliditylang.org/en/latest/abi-spec.html) * [ABI란 무엇인가? - Alchemy (새 탭에서 열림)](https://www.alchemy.com/overviews/what-is-an-abi) [](https://ethereum.org/ko/developers/docs/smart-contracts/interacting/#related-topics) 관련 주제 --------------------------------------------------------------------------------------------- * [스마트 컨트랙트 컴파일링](https://ethereum.org/ko/developers/docs/smart-contracts/compiling/) * [스마트 컨트랙트 배포하기](https://ethereum.org/ko/developers/docs/smart-contracts/deploying/) * [JavaScript API](https://ethereum.org/ko/developers/docs/apis/javascript/) * [백엔드 API](https://ethereum.org/ko/developers/docs/apis/backend/) --- # スマート・コントラクトの紹介 | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/smart-contracts/#main-content) Change page スマート・コントラクトの紹介 ============== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/index.md) このページの内容 [](https://ethereum.org/ja/developers/docs/smart-contracts/#what-is-a-smart-contract) スマート・コントラクトとは? ---------------------------------------------------------------------------------------------------- 「スマート・コントラクト」とは、単に[イーサリアム](https://ethereum.org/ja/) ・ブロックチェーン上で実行されるプログラムのことです。イーサリアム・ブロックチェーン上の特定のアドレスに存在する、コード(関数)とデータ(状態)の集合体です。 スマート・コントラクトは、[イーサリアム・アカウント](https://ethereum.org/ja/developers/docs/accounts/) の一種です。つまり、残高を持ち、トランザクションの宛先になることができます。しかし、ユーザーによって制御されるのではなく、ネットワークにデプロイされ、プログラムされた通りに実行されます。ユーザー・アカウントは、スマート・コントラクトで定義された関数を実行するトランザクションを送信することで、スマート・コントラクトと対話できます。スマート・コントラクトは、通常の契約(コントラクト)のようにルールを定義し、コードを通じて自動的に強制することができます。スマート・コントラクトはデフォルトでは削除できず、それらとの対話は不可逆的です。 [](https://ethereum.org/ja/developers/docs/smart-contracts/#prerequisites) 前提条件 ------------------------------------------------------------------------------- これから始める方や、技術的でない紹介をお探しの場合は、[スマート・コントラクトの紹介](https://ethereum.org/ja/smart-contracts/) をお勧めします。 スマート・コントラクトの世界に飛び込む前に、[アカウント](https://ethereum.org/ja/developers/docs/accounts/) 、[トランザクション](https://ethereum.org/ja/developers/docs/transactions/) 、および[イーサリアム仮想マシン](https://ethereum.org/ja/developers/docs/evm/) について読んでおいてください。 [](https://ethereum.org/ja/developers/docs/smart-contracts/#a-digital-vending-machine) デジタル自動販売機 ------------------------------------------------------------------------------------------------ [ニック・サボ （新しいタブで開きます）](https://unenumerated.blogspot.com/) が説明しているように、スマート・コントラクトの最も適切な比喩はおそらく自動販売機でしょう。正しい入力があれば、特定の出力が保証されます。 自動販売機からスナックを取り出すには: お金 + スナックの選択 = スナックの提供 コピー このロジックは自動販売機にプログラムされています。 スマート・コントラクトには、自動販売機のようにロジックがプログラムされています。この自動販売機がSolidityで書かれたスマート・コントラクトだった場合、どのようになるかの簡単な例を以下に示します。 pragma solidity 0.8.7; contract VendingMachine { // コントラクトの状態変数を宣言する address public owner; mapping (address => uint) public cupcakeBalances; // 'VendingMachine' コントラクトがデプロイされたとき: // 1. デプロイしたアドレスをコントラクトのオーナーとして設定する // 2. デプロイされたスマート・コントラクトのカップケーキの残高を100に設定する constructor() { owner = msg.sender; cupcakeBalances[address(this)] = 100; } // オーナーがスマート・コントラクトのカップケーキの残高を増やせるようにする function refill(uint amount) public { require(msg.sender == owner, "Only the owner can refill."); cupcakeBalances[address(this)] += amount; } // 誰でもカップケーキを購入できるようにする function purchase(uint amount) public payable { require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake"); require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase"); cupcakeBalances[address(this)] -= amount; cupcakeBalances[msg.sender] += amount; } } コピーSolidity すべて表示 (30) 自動販売機が販売員を不要にするように、スマート・コントラクトは多くの業界で仲介者を置き換えることができます。 [](https://ethereum.org/ja/developers/docs/smart-contracts/#permissionless) パーミッションレス ------------------------------------------------------------------------------------- 誰でもスマート・コントラクトを書いてネットワークにデプロイできます。[スマート・コントラクト言語](https://ethereum.org/ja/developers/docs/smart-contracts/languages/) でのコーディング方法を学び、コントラクトをデプロイするのに十分なETHを持っているだけで済みます。スマート・コントラクトのデプロイは技術的にはトランザクションであるため、単純なETHの送金でガスを支払う必要があるのと同じように、[ガス](https://ethereum.org/ja/developers/docs/gas/) を支払う必要があります。ただし、コントラクトのデプロイにかかるガス・コストははるかに高くなります。 イーサリアムには、スマート・コントラクトを書くための開発者フレンドリーな言語があります。 * Solidity * Vyper [言語の詳細](https://ethereum.org/ja/developers/docs/smart-contracts/languages/) ただし、イーサリアムの仮想マシンがコントラクトを解釈して保存できるように、デプロイする前にコンパイルする必要があります。[コンパイルの詳細](https://ethereum.org/ja/developers/docs/smart-contracts/compiling/) [](https://ethereum.org/ja/developers/docs/smart-contracts/#composability) コンポーザビリティ ------------------------------------------------------------------------------------ スマート・コントラクトはイーサリアム上で公開されており、オープンなAPIと考えることができます。つまり、自分のスマート・コントラクト内で他のスマート・コントラクトを呼び出すことで、可能なことを大幅に拡張できます。コントラクトが他のコントラクトをデプロイすることさえ可能です。 [スマート・コントラクトのコンポーザビリティ](https://ethereum.org/ja/developers/docs/smart-contracts/composability/) についてさらに学ぶ。 [](https://ethereum.org/ja/developers/docs/smart-contracts/#limitations) 制限事項 ----------------------------------------------------------------------------- スマート・コントラクト単独では、オフチェーンのソースからデータを取得できないため、「現実世界」のイベントに関する情報を取得することはできません。つまり、現実世界のイベントに対応することはできません。これは意図的な設計です。外部情報に依存すると、セキュリティと分散化にとって重要なコンセンサスを危険にさらす可能性があります。 しかし、ブロックチェーン・アプリケーションがオフチェーンのデータを使用できることは重要です。その解決策が[オラクル](https://ethereum.org/ja/developers/docs/oracles/) であり、これはオフチェーンのデータを取り込み、スマート・コントラクトで利用できるようにするツールです。 スマート・コントラクトのもう一つの制限は、コントラクトの最大サイズです。スマート・コントラクトの最大サイズは24KBであり、それを超えるとガス不足になります。これは[ダイヤモンド・パターン （新しいタブで開きます）](https://eips.ethereum.org/EIPS/eip-2535) を使用することで回避できます。 [](https://ethereum.org/ja/developers/docs/smart-contracts/#multisig) マルチシグ・コントラクト ---------------------------------------------------------------------------------- マルチシグ(複数署名)・コントラクトは、トランザクションを実行するために複数の有効な署名を必要とするスマート・コントラクト・アカウントです。これは、大量のイーサやその他のトークンを保持するコントラクトの単一障害点を回避するのに非常に役立ちます。また、マルチシグはコントラクトの実行と鍵管理の責任を複数の当事者間で分割し、単一の秘密鍵の紛失が不可逆的な資金の損失につながるのを防ぎます。これらの理由から、マルチシグ・コントラクトはシンプルなDAOガバナンスに使用できます。マルチシグを実行するには、M個の許容可能な署名のうちN個の署名(N ≤ M、かつM > 1)が必要です。`N = 3, M = 5`や`N = 4, M = 7`が一般的に使用されます。4/7のマルチシグでは、7つの有効な署名のうち4つが必要です。つまり、3つの署名が失われても資金は回収可能です。この場合、コントラクトを実行するには、鍵保持者の過半数が同意して署名する必要があることも意味します。 [](https://ethereum.org/ja/developers/docs/smart-contracts/#smart-contract-resources) スマート・コントラクトのリソース ------------------------------------------------------------------------------------------------------ **オープンツェッペリン・コントラクト -** **_安全なスマート・コントラクト開発のためのライブラリ。_** * [openzeppelin.com/contracts/ （新しいタブで開きます）](https://openzeppelin.com/contracts/) * [GitHub （新しいタブで開きます）](https://github.com/OpenZeppelin/openzeppelin-contracts) * [コミュニティ・フォーラム （新しいタブで開きます）](https://forum.openzeppelin.com/c/general/16) [](https://ethereum.org/ja/developers/docs/smart-contracts/#further-reading) 参考文献 --------------------------------------------------------------------------------- * [コインベース: スマート・コントラクトとは? （新しいタブで開きます）](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract) * [チェーンリンク: スマート・コントラクトとは? （新しいタブで開きます）](https://chain.link/education/smart-contracts) * [動画: わかりやすい解説 - スマート・コントラクト （新しいタブで開きます）](https://youtu.be/ZE2HxTmxfrI) * [Cyfrin Updraft: Web3学習および監査プラットフォーム （新しいタブで開きます）](https://updraft.cyfrin.io/) [](https://ethereum.org/ja/developers/docs/smart-contracts/#tutorials) チュートリアル: イーサリアム上のスマート・コントラクト署名 (EIP-1271) ---------------------------------------------------------------------------------------------------------------- * [EIP-1271: スマート・コントラクト署名の署名と検証](https://ethereum.org/ja/developers/tutorials/eip-1271-smart-contract-signatures/) _– EIP-1271がスマート・コントラクトによる署名検証をどのように可能にするかについて、Safeの実装のウォークスルーを交えて解説します。_ --- # 브릿지 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/bridges/#main-content) Change page 브릿지 === .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/bridges/index.md) 이 페이지의 내용 레이어 1 (l1) 블록체인과 레이어 2 (l2) [확장성](https://ethereum.org/ko/developers/docs/scaling/) 솔루션이 확산되고 크로스체인으로 전환하는 탈중앙화 애플리케이션 (dapp)의 수가 지속적으로 증가함에 따라, 체인 간 통신 및 자산 이동의 필요성은 네트워크 인프라의 필수적인 부분이 되었습니다. 이를 가능하게 돕는 다양한 유형의 브릿지가 존재합니다. [](https://ethereum.org/ko/developers/docs/bridges/#need-for-bridges) 브릿지의 필요성 ------------------------------------------------------------------------------ 브릿지는 블록체인 네트워크를 연결하기 위해 존재합니다. 브릿지는 블록체인 간의 연결성과 상호운용성을 가능하게 합니다. 블록체인은 고립된 환경에 존재하므로, 블록체인이 다른 블록체인과 자연스럽게 거래하고 통신할 수 있는 방법이 없습니다. 결과적으로 한 생태계 내에서 상당한 활동과 혁신이 일어날 수 있지만, 다른 생태계와의 연결성 및 상호운용성 부족으로 인해 한계에 부딪히게 됩니다. 브릿지는 고립된 블록체인 환경이 서로 연결될 수 있는 방법을 제공합니다. 브릿지는 토큰, 메시지, 임의의 데이터, 심지어 [스마트 컨트랙트](https://ethereum.org/ko/developers/docs/smart-contracts/) 호출까지 한 체인에서 다른 체인으로 전송될 수 있는 블록체인 간의 전송 경로를 구축합니다. [](https://ethereum.org/ko/developers/docs/bridges/#benefits-of-bridges) 브릿지의 이점 -------------------------------------------------------------------------------- 간단히 말해, 브릿지는 블록체인 네트워크가 데이터를 교환하고 자산을 이동할 수 있게 함으로써 수많은 사용 사례를 열어줍니다. 블록체인은 고유한 강점, 약점, 그리고 애플리케이션 구축 방식(속도, 처리량, 비용 등)을 가지고 있습니다. 브릿지는 블록체인이 서로의 혁신을 활용할 수 있게 함으로써 전체 암호화폐 생태계의 발전을 돕습니다. 개발자에게 브릿지는 다음을 가능하게 합니다: * 체인 간 모든 데이터, 정보 및 자산의 전송. * 브릿지가 프로토콜이 제공할 수 있는 설계 공간을 확장함에 따라 프로토콜의 새로운 기능과 사용 사례를 열어줍니다. 예를 들어, 원래 [이더리움](https://ethereum.org/ko/) 메인넷에 배포된 이자 농사 프로토콜은 모든 EVM 호환 체인에 걸쳐 유동성 풀을 제공할 수 있습니다. * 다양한 블록체인의 강점을 활용할 수 있는 기회. 예를 들어, 개발자는 롤업과 사이드체인에 탈중앙화 애플리케이션 (dapp)을 배포하여 다양한 레이어 2 (l2) 솔루션이 제공하는 더 낮은 수수료의 이점을 누릴 수 있으며, 사용자는 이들 사이를 브릿지로 연결할 수 있습니다. * 새로운 제품을 구축하기 위한 다양한 블록체인 생태계 개발자 간의 협업. * 다양한 생태계의 사용자와 커뮤니티를 자신의 탈중앙화 애플리케이션 (dapp)으로 유치. [](https://ethereum.org/ko/developers/docs/bridges/#how-do-bridges-work) 브릿지는 어떻게 작동하나요? ---------------------------------------------------------------------------------------- [브릿지 설계의 유형 (새 탭에서 열림)](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/) 은 다양하지만, 자산의 크로스체인 전송을 촉진하는 세 가지 주요 방법이 있습니다: * **잠금 및 발행(Lock and mint) –** 출발지 체인에서 자산을 잠그고 목적지 체인에서 자산을 발행합니다. * **소각 및 발행(Burn and mint) –** 출발지 체인에서 자산을 소각하고 목적지 체인에서 자산을 발행합니다. * **아토믹 스왑(Atomic swaps) –** 출발지 체인의 자산을 다른 당사자와 목적지 체인의 자산으로 스왑합니다. [](https://ethereum.org/ko/developers/docs/bridges/#bridge-types) 브릿지 유형 ------------------------------------------------------------------------ 브릿지는 일반적으로 다음 범주 중 하나로 분류할 수 있습니다: * **네이티브 브릿지(Native bridges) –** 이러한 브릿지는 일반적으로 특정 블록체인에서 유동성을 부트스트랩하기 위해 구축되어 사용자가 생태계로 자금을 더 쉽게 이동할 수 있도록 합니다. 예를 들어, [아비트럼 브릿지(Arbitrum Bridge) (새 탭에서 열림)](https://bridge.arbitrum.io/) 는 사용자가 이더리움 메인넷에서 아비트럼으로 편리하게 브릿징할 수 있도록 구축되었습니다. 다른 유사한 브릿지로는 폴리곤 지분 증명 (PoS) 브릿지, [옵티미즘 게이트웨이(Optimism Gateway) (새 탭에서 열림)](https://app.optimism.io/bridge) 등이 있습니다. * **검증자 또는 오라클 기반 브릿지(Validator or oracle based bridges) –** 이러한 브릿지는 크로스체인 전송을 검증하기 위해 외부 검증자 세트나 오라클에 의존합니다. 예: Multichain 및 Across. * **일반화된 메시지 전달 브릿지(Generalized message passing bridges) –** 이러한 브릿지는 체인 간에 메시지 및 임의의 데이터와 함께 자산을 전송할 수 있습니다. 예: Axelar, LayerZero 및 Nomad. * **유동성 네트워크(Liquidity networks) –** 이러한 브릿지는 주로 아토믹 스왑을 통해 한 체인에서 다른 체인으로 자산을 전송하는 데 중점을 둡니다. 일반적으로 크로스체인 메시지 전달은 지원하지 않습니다. 예: Connext 및 Hop. [](https://ethereum.org/ko/developers/docs/bridges/#trade-offs) 고려해야 할 트레이드오프 ----------------------------------------------------------------------------- 브릿지에 완벽한 솔루션은 없습니다. 오히려 목적을 달성하기 위해 이루어지는 트레이드오프만 있을 뿐입니다. 개발자와 사용자는 다음 요소를 기반으로 브릿지를 평가할 수 있습니다: * **보안 –** 누가 시스템을 검증하나요? 외부 검증자에 의해 보호되는 브릿지는 일반적으로 블록체인의 검증자에 의해 로컬 또는 네이티브로 보호되는 브릿지보다 덜 안전합니다. * **편의성 –** 트랜잭션을 완료하는 데 얼마나 걸리며, 사용자가 서명해야 하는 트랜잭션은 몇 개인가요? 개발자의 경우 브릿지를 통합하는 데 얼마나 걸리며, 그 과정은 얼마나 복잡한가요? * **연결성 –** 브릿지가 연결할 수 있는 다양한 목적지 체인(예: 롤업, 사이드체인, 기타 레이어 1 (l1) 블록체인 등)은 무엇이며, 새로운 블록체인을 통합하는 것은 얼마나 어려운가요? * **더 복잡한 데이터를 전달하는 능력 –** 브릿지가 체인 간에 메시지와 더 복잡한 임의의 데이터를 전송할 수 있나요, 아니면 크로스체인 자산 전송만 지원하나요? * **비용 효율성 –** 브릿지를 통해 체인 간에 자산을 전송하는 데 비용이 얼마나 드나요? 일반적으로 브릿지는 가스 비용과 특정 경로의 유동성에 따라 고정 또는 변동 수수료를 부과합니다. 또한 보안을 보장하는 데 필요한 자본을 기반으로 브릿지의 비용 효율성을 평가하는 것도 중요합니다. 크게 보면 브릿지는 신뢰 기반(trusted)과 무신뢰(trustless)로 분류할 수 있습니다. * **신뢰 기반(Trusted) –** 신뢰 기반 브릿지는 외부에서 검증됩니다. 체인 간에 데이터를 전송하기 위해 외부 검증자 세트(다중 서명 연합, 다자간 컴퓨팅 시스템, 오라클 네트워크)를 사용합니다. 결과적으로 뛰어난 연결성을 제공하고 체인 간에 완전히 일반화된 메시지 전달을 가능하게 할 수 있습니다. 또한 속도와 비용 효율성 측면에서도 우수한 성능을 보이는 경향이 있습니다. 하지만 사용자가 브릿지의 보안에 의존해야 하므로 보안 측면에서 대가가 따릅니다. * **무신뢰(Trustless) –** 이러한 브릿지는 메시지와 토큰을 전송하기 위해 연결 중인 블록체인과 해당 검증자에 의존합니다. (블록체인 외에) 새로운 신뢰 가정을 추가하지 않기 때문에 '무신뢰'라고 합니다. 결과적으로 무신뢰 브릿지는 신뢰 기반 브릿지보다 더 안전한 것으로 간주됩니다. 다른 요소를 기반으로 무신뢰 브릿지를 평가하려면, 이를 일반화된 메시지 전달 브릿지와 유동성 네트워크로 나누어야 합니다. * **일반화된 메시지 전달 브릿지 –** 이러한 브릿지는 보안과 체인 간에 더 복잡한 데이터를 전송하는 능력에서 뛰어납니다. 일반적으로 비용 효율성도 좋습니다. 그러나 이러한 강점은 일반적으로 경량 클라이언트 브릿지(예: IBC)의 경우 연결성 저하, 사기 증명을 사용하는 옵티미스틱 브릿지(예: Nomad)의 경우 속도 저하라는 대가를 치릅니다. * **유동성 네트워크 –** 이러한 브릿지는 자산 전송에 아토믹 스왑을 사용하며 로컬에서 검증되는 시스템입니다(즉, 트랜잭션을 검증하기 위해 기본 블록체인의 검증자를 사용함). 결과적으로 보안과 속도 면에서 뛰어납니다. 또한 비교적 비용 효율적이며 좋은 연결성을 제공하는 것으로 간주됩니다. 그러나 주요 트레이드오프는 크로스체인 메시지 전달을 지원하지 않기 때문에 더 복잡한 데이터를 전달할 수 없다는 점입니다. [](https://ethereum.org/ko/developers/docs/bridges/#risk-with-bridges) 브릿지의 위험성 ------------------------------------------------------------------------------- 브릿지는 [탈중앙화 금융 (DeFi)에서 발생한 가장 큰 해킹 사건 (새 탭에서 열림)](https://rekt.news/leaderboard/) 상위 3건을 차지하며, 여전히 개발 초기 단계에 있습니다. 브릿지를 사용할 때는 다음과 같은 위험이 따릅니다: * **스마트 컨트랙트 위험 –** 많은 브릿지가 감사를 성공적으로 통과했지만, 스마트 컨트랙트에 단 하나의 결함만 있어도 자산이 해킹에 노출될 수 있습니다(예: [솔라나의 웜홀 브릿지(Solana’s Wormhole Bridge) (새 탭에서 열림)](https://rekt.news/wormhole-rekt/) ). * **시스템적 금융 위험** – 많은 브릿지가 래핑된 자산을 사용하여 새로운 체인에서 원본 자산의 표준 버전을 발행합니다. 래핑된 버전의 토큰이 악용된 사례에서 보았듯이, 이는 생태계를 시스템적 위험에 노출시킵니다. * **거래 상대방 위험 –** 일부 브릿지는 검증자들이 사용자 자금을 훔치기 위해 담합하지 않을 것이라는 가정에 사용자가 의존해야 하는 신뢰 기반 설계를 활용합니다. 사용자가 이러한 제3자를 신뢰해야 할 필요성은 러그풀, 검열 및 기타 악의적인 활동과 같은 위험에 노출시킵니다. * **미해결 문제 –** 브릿지가 개발 초기 단계에 있다는 점을 고려할 때, 네트워크 혼잡 시기나 네트워크 수준의 공격 또는 상태 롤백과 같은 예기치 않은 이벤트 발생 시 브릿지가 다양한 시장 조건에서 어떻게 작동할지와 관련된 많은 미해결 질문이 있습니다. 이러한 불확실성은 특정 위험을 초래하며, 그 정도는 아직 알려지지 않았습니다. [](https://ethereum.org/ko/developers/docs/bridges/#how-can-dapps-use-bridges) 탈중앙화 애플리케이션 (dapp)은 브릿지를 어떻게 사용할 수 있나요? ---------------------------------------------------------------------------------------------------------------------- 다음은 개발자가 브릿지 및 탈중앙화 애플리케이션 (dapp)의 크로스체인 전환에 대해 고려할 수 있는 몇 가지 실용적인 애플리케이션입니다: ### [](https://ethereum.org/ko/developers/docs/bridges/#integrating-bridges) 브릿지 통합 개발자가 브릿지 지원을 추가하는 방법에는 여러 가지가 있습니다: 1. **자체 브릿지 구축 –** 안전하고 신뢰할 수 있는 브릿지를 구축하는 것은 쉽지 않으며, 특히 신뢰 최소화 경로를 택할 경우 더욱 그렇습니다. 게다가 확장성 및 상호운용성 연구와 관련된 수년간의 경험과 기술적 전문 지식이 필요합니다. 또한 브릿지를 유지 관리하고 실현 가능하도록 충분한 유동성을 유치할 실무 팀이 필요합니다. 2. **사용자에게 여러 브릿지 옵션 표시 –** 많은 [탈중앙화 애플리케이션 (dapp)](https://ethereum.org/ko/developers/docs/dapps/) 은 사용자가 상호 작용하기 위해 네이티브 토큰을 보유하도록 요구합니다. 사용자가 토큰에 접근할 수 있도록 웹사이트에서 다양한 브릿지 옵션을 제공합니다. 그러나 이 방법은 사용자를 탈중앙화 애플리케이션 (dapp) 인터페이스에서 벗어나게 하고 여전히 다른 탈중앙화 애플리케이션 (dapp) 및 브릿지와 상호 작용하도록 요구하기 때문에 문제에 대한 임시방편일 뿐입니다. 이는 실수를 할 가능성이 커지는 번거로운 온보딩 경험입니다. 3. **브릿지 통합 –** 이 솔루션은 탈중앙화 애플리케이션 (dapp)이 사용자를 외부 브릿지 및 DEX 인터페이스로 보낼 필요가 없습니다. 이를 통해 탈중앙화 애플리케이션 (dapp)은 사용자 온보딩 경험을 개선할 수 있습니다. 그러나 이 접근 방식에는 다음과 같은 한계가 있습니다: * 브릿지의 평가 및 유지 관리가 어렵고 시간이 많이 걸립니다. * 하나의 브릿지를 선택하면 단일 장애점과 의존성이 발생합니다. * 탈중앙화 애플리케이션 (dapp)은 브릿지의 기능에 의해 제한됩니다. * 브릿지만으로는 충분하지 않을 수 있습니다. 탈중앙화 애플리케이션 (dapp)은 크로스체인 스왑과 같은 더 많은 기능을 제공하기 위해 DEX가 필요할 수 있습니다. 4. **여러 브릿지 통합 –** 이 솔루션은 단일 브릿지 통합과 관련된 많은 문제를 해결합니다. 그러나 여러 브릿지를 통합하는 것은 리소스를 많이 소비하고 암호화폐 분야에서 가장 희소한 자원인 개발자에게 기술 및 커뮤니케이션 오버헤드를 발생시키기 때문에 한계도 있습니다. 5. **브릿지 애그리게이터 통합 –** 탈중앙화 애플리케이션 (dapp)을 위한 또 다른 옵션은 여러 브릿지에 접근할 수 있게 해주는 브릿지 애그리게이션 솔루션을 통합하는 것입니다. 브릿지 애그리게이터는 모든 브릿지의 강점을 상속받으므로 단일 브릿지의 기능에 제한되지 않습니다. 특히, 브릿지 애그리게이터는 일반적으로 브릿지 통합을 유지 관리하므로 탈중앙화 애플리케이션 (dapp)이 브릿지 통합의 기술적 및 운영적 측면을 파악해야 하는 번거로움을 덜어줍니다. 그렇긴 하지만, 브릿지 애그리게이터에도 한계가 있습니다. 예를 들어, 더 많은 브릿지 옵션을 제공할 수 있지만, 일반적으로 애그리게이터 플랫폼에서 제공되는 것 외에도 시장에는 훨씬 더 많은 브릿지가 있습니다. 또한 브릿지와 마찬가지로 브릿지 애그리게이터도 스마트 컨트랙트 및 기술 위험에 노출됩니다(스마트 컨트랙트가 많을수록 위험도 커짐). 탈중앙화 애플리케이션 (dapp)이 브릿지나 애그리게이터를 통합하는 경로를 선택하는 경우, 통합의 깊이에 따라 다양한 옵션이 있습니다. 예를 들어, 사용자 온보딩 경험을 개선하기 위한 프론트엔드 통합일 뿐이라면 탈중앙화 애플리케이션 (dapp)은 위젯을 통합할 것입니다. 그러나 통합의 목적이 스테이킹, 이자 농사 등과 같은 더 깊은 크로스체인 전략을 탐색하는 것이라면 탈중앙화 애플리케이션 (dapp)은 SDK 또는 API를 통합합니다. ### [](https://ethereum.org/ko/developers/docs/bridges/#deploying-a-dapp-on-multiple-chains) 여러 체인에 탈중앙화 애플리케이션 (dapp) 배포 여러 체인에 탈중앙화 애플리케이션 (dapp)을 배포하기 위해 개발자는 [Alchemy (새 탭에서 열림)](https://www.alchemy.com/) , [Hardhat (새 탭에서 열림)](https://hardhat.org/) , [Moralis (새 탭에서 열림)](https://moralis.io/) 등과 같은 개발 플랫폼을 사용할 수 있습니다. 일반적으로 이러한 플랫폼에는 탈중앙화 애플리케이션 (dapp)이 크로스체인으로 전환할 수 있게 해주는 조합 가능한 플러그인이 함께 제공됩니다. 예를 들어, 개발자는 [hardhat-deploy 플러그인 (새 탭에서 열림)](https://github.com/wighawag/hardhat-deploy) 이 제공하는 결정론적 배포 프록시를 사용할 수 있습니다. #### [](https://ethereum.org/ko/developers/docs/bridges/#examples) 예시: * [크로스체인 탈중앙화 애플리케이션 (dapp) 구축 방법 (새 탭에서 열림)](https://moralis.io/how-to-build-cross-chain-dapps/) * [크로스체인 NFT 마켓플레이스 구축 (새 탭에서 열림)](https://youtu.be/WZWCzsB1xUE) * [Moralis: 크로스체인 NFT 탈중앙화 애플리케이션 (dapp) 구축 (새 탭에서 열림)](https://www.youtube.com/watch?v=ehv70kE1QYo) ### [](https://ethereum.org/ko/developers/docs/bridges/#monitoring-contract-activity-across-chains) 체인 간 컨트랙트 활동 모니터링 체인 간 컨트랙트 활동을 모니터링하기 위해 개발자는 서브그래프와 Tenderly 같은 개발자 플랫폼을 사용하여 스마트 컨트랙트를 실시간으로 관찰할 수 있습니다. 이러한 플랫폼에는 [컨트랙트에서 발생한 이벤트 (새 탭에서 열림)](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events) 확인 등 크로스체인 활동에 대한 더 강력한 데이터 모니터링 기능을 제공하는 도구도 있습니다. #### [](https://ethereum.org/ko/developers/docs/bridges/#tools) 도구 * [The Graph (새 탭에서 열림)](https://thegraph.com/en/) * [Tenderly (새 탭에서 열림)](https://tenderly.co/) [](https://ethereum.org/ko/developers/docs/bridges/#further-reading) 더 읽어보기 --------------------------------------------------------------------------- * [블록체인 브릿지](https://ethereum.org/ko/bridges/) – ethereum.org * [L2BEAT 브릿지 위험 프레임워크 (새 탭에서 열림)](https://l2beat.com/bridges/summary) * [블록체인 브릿지: 암호화폐 네트워크의 네트워크 구축(Blockchain Bridges: Building Networks of Cryptonetworks) (새 탭에서 열림)](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) - 2021년 9월 8일 – Dmitriy Berenzon * [상호운용성 트릴레마(The Interoperability Trilemma) (새 탭에서 열림)](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) - 2021년 10월 1일 – Arjun Bhuptani * [클러스터: 신뢰 기반 및 신뢰 최소화 브릿지가 멀티체인 환경을 형성하는 방법(Clusters: How Trusted & Trust-Minimized Bridges Shape the Multi-Chain Landscape) (새 탭에서 열림)](https://blog.celestia.org/clusters/) - 2021년 10월 4일 – Mustafa Al-Bassam * [LI.FI: 브릿지에서 신뢰는 스펙트럼이다(LI.FI: With Bridges, Trust is a Spectrum) (새 탭에서 열림)](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) - 2022년 4월 28일 – Arjun Chand * [롤업 상호운용성 솔루션의 현황(The State Of Rollup Interoperability Solutions) (새 탭에서 열림)](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - 2024년 6월 20일 – Alex Hook * [안전한 크로스체인 상호운용성을 위한 공유 보안 활용: 라그랑주 상태 위원회 및 그 너머(Harnessing Shared Security For Secure Cross-Chain Interoperability: Lagrange State Committees And Beyond) (새 탭에서 열림)](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - 2024년 6월 12일 – Emmanuel Awosika 또한, 브릿지에 대한 더 깊은 이해를 돕는 [James Prestwich (새 탭에서 열림)](https://twitter.com/_prestwich) 의 통찰력 있는 프레젠테이션 몇 가지를 소개합니다: * [장벽이 아닌 브릿지 구축하기(Building Bridges, Not Walled Gardens) (새 탭에서 열림)](https://youtu.be/ZQJWMiX4hT0) * [브릿지 분석(Breaking Down Bridges) (새 탭에서 열림)](https://youtu.be/b0mC-ZqN8Oo) * [왜 브릿지가 불타고 있는가(Why are the Bridges Burning) (새 탭에서 열림)](https://youtu.be/c7cm2kd20j8) --- # Python 개발자를 위한 이더리움 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/programming-languages/python/#main-content) Change page Python 개발자를 위한 이더리움 =================== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/python/index.md) 이 페이지의 내용 Python 기반 프로젝트 및 도구를 사용하여 이더리움용으로 개발하는 방법을 알아보세요. 이더리움을 사용하여 암호화폐와 블록체인 기술의 이점을 활용하는 탈중앙화 애플리케이션(또는 "dapp")을 만들어 보세요. 이러한 dapp은 신뢰할 수 있으며, 이는 이더리움에 배포된 후에는 항상 프로그래밍된 대로 실행됨을 의미합니다. 디지털 자산을 제어하여 새로운 종류의 금융 애플리케이션을 만들 수 있습니다. 또한 탈중앙화되어 있어 단일 주체나 개인이 통제하지 않으며 검열이 거의 불가능합니다. [](https://ethereum.org/ko/developers/docs/programming-languages/python/#getting-started-with-smart-contracts-and-solidity) 스마트 컨트랙트 및 Solidity 언어 시작하기 ------------------------------------------------------------------------------------------------------------------------------------------------------- **Python과 이더리움을 통합하기 위한 첫걸음을 내디뎌 보세요** 더 기본적인 입문서가 먼저 필요하신가요? [ethereum.org/learn](https://ethereum.org/ko/learn/) 또는 [ethereum.org/developers](https://ethereum.org/ko/developers/) 를 확인해 보세요. * [블록체인 설명 (새 탭에서 열림)](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [스마트 컨트랙트의 이해 (새 탭에서 열림)](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [첫 번째 스마트 컨트랙트 작성하기 (새 탭에서 열림)](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Solidity 컴파일링 및 배포 방법 알아보기 (새 탭에서 열림)](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) * [2023년 블록체인 내 Python 상태 보고서 (새 탭에서 열림)](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023) [](https://ethereum.org/ko/developers/docs/programming-languages/python/#beginner-articles) 초급자용 아티클 ---------------------------------------------------------------------------------------------------- * [Web3.py 개요 (새 탭에서 열림)](https://web3py.readthedocs.io/en/latest/overview.html) * [이더리움 Python 생태계 둘러보기 (새 탭에서 열림)](https://snakecharmers.ethereum.org/python-ecosystem/) * [(Python) 개발자를 위한 이더리움 가이드 (새 탭에서 열림)](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/) * [수상 가치가 있는: 이더리움 Python 해커톤 가이드 (새 탭에서 열림)](https://snakecharmers.ethereum.org/prize-worthy/) * [Vyper를 활용한 스마트 컨트랙트 소개 (새 탭에서 열림)](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/) * [Python Flask를 사용하여 이더리움 컨트랙트를 개발하는 방법은? (새 탭에서 열림)](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e) * [Web3.py 소개 · Python 개발자를 위한 이더리움 (새 탭에서 열림)](https://www.dappuniversity.com/articles/web3-py-intro) * [Python과 Web3.py를 사용하여 스마트 컨트랙트 함수를 호출하는 방법 (새 탭에서 열림)](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py) [](https://ethereum.org/ko/developers/docs/programming-languages/python/#intermediate-articles) 중급자용 아티클 -------------------------------------------------------------------------------------------------------- * [Web3.py의 친구들: Ape 소개 (새 탭에서 열림)](https://snakecharmers.ethereum.org/intro-to-ape/) * [Python 프로그래머를 위한 dapp 개발 (새 탭에서 열림)](https://www.youtube.com/watch?v=tE-8bG35VNw) * [Python 이더리움 인터페이스 만들기: 파트 1 (새 탭에서 열림)](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d) * [Python으로 작성하는 이더리움 스마트 컨트랙트: (나름) 포괄적인 가이드 (새 탭에서 열림)](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988) [](https://ethereum.org/ko/developers/docs/programming-languages/python/#advanced-use-patterns) 고급 사용 패턴 -------------------------------------------------------------------------------------------------------- * [Web3.py 패턴: 실시간 이벤트 구독 (새 탭에서 열림)](https://snakecharmers.ethereum.org/subscriptions/) * [Web3.py 패턴: WebSocketProvider (새 탭에서 열림)](https://snakecharmers.ethereum.org/websocketprovider/) * [Python을 사용한 이더리움 스마트 컨트랙트 컴파일링, 배포 및 호출 (새 탭에서 열림)](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/) * [슬리더를 사용한 Solidity 스마트 컨트랙트 분석 (새 탭에서 열림)](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither) * [블록체인 핀테크 튜토리얼: Python을 활용한 대출 및 차입 (새 탭에서 열림)](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/) [](https://ethereum.org/ko/developers/docs/programming-languages/python/#archived-articles) 보관된 아티클 --------------------------------------------------------------------------------------------------- * [Python과 Brownie로 나만의 ERC-20 토큰 배포하기 (새 탭에서 열림)](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58) * [Brownie와 Python을 사용하여 스마트 컨트랙트 배포하기 (새 탭에서 열림)](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp) * [Brownie를 사용하여 오픈씨에서 NFT 만들기 (새 탭에서 열림)](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/) [](https://ethereum.org/ko/developers/docs/programming-languages/python/#python-projects-and-tools) Python 프로젝트 및 도구 -------------------------------------------------------------------------------------------------------------------- * [Web3.py (새 탭에서 열림)](https://github.com/ethereum/web3.py) - _이더리움과 상호작용하기 위한 Python 라이브러리_ * [Vyper (새 탭에서 열림)](https://github.com/ethereum/vyper/) - _EVM을 위한 Pythonic 스마트 컨트랙트 언어_ * [Titanoboa (새 탭에서 열림)](https://github.com/vyperlang/titanoboa/) - _Vyper의 네이티브 테스트 도구; 메인넷 포킹, 디버깅 및 깔끔한 트레이스백을 지원하는 인터프리터_ * [Moccasin (새 탭에서 열림)](https://github.com/Cyfrin/moccasin) - _Titanoboa를 기반으로 구축된 Vyper 및 Python용 스마트 컨트랙트 개발 및 테스트 프레임워크_ * [Ape (새 탭에서 열림)](https://github.com/ApeWorX/ape) - _Python 개발자, 데이터 과학자 및 보안 전문가를 위한 스마트 컨트랙트 개발 도구_ * [py-evm (새 탭에서 열림)](https://github.com/ethereum/py-evm) - _이더리움 가상 머신(EVM) 구현체_ * [eth-tester (새 탭에서 열림)](https://github.com/ethereum/eth-tester) - _이더리움 기반 애플리케이션 테스트를 위한 도구_ * [eth-utils (새 탭에서 열림)](https://github.com/ethereum/eth-utils/) - _이더리움 관련 코드베이스 작업을 위한 유틸리티 함수_ * [py-solc-x (새 탭에서 열림)](https://pypi.org/project/py-solc-x/) - _0.5.x 버전을 지원하는 solc Solidity 컴파일러용 Python 래퍼_ * [pymaker (새 탭에서 열림)](https://github.com/makerdao/pymaker) - _Maker 컨트랙트를 위한 Python API_ * [siwe (새 탭에서 열림)](https://github.com/signinwithethereum/siwe-py) - _Python용 이더리움으로 로그인(SIWE)_ * [Web3 DeFi for Ethereum integrations (새 탭에서 열림)](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _ERC-20, 유니스왑 및 기타 인기 있는 프로젝트를 위한 통합 기능이 준비된 Python 패키지_ * [Wake (새 탭에서 열림)](https://getwake.io/) - _컨트랙트 테스트, 퍼징, 배포, 취약점 스캐닝 및 코드 탐색을 위한 올인원 Python 프레임워크 (언어 서버 - [Tools for Solidity (새 탭에서 열림)](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity) )_ * [DeFiPy (새 탭에서 열림)](https://github.com/defipy-devs/defipy) - _유니스왑 V2/V3, Balancer 및 Curve 전반의 탈중앙화 금융(DeFi) 분석 및 자동화된 마켓 메이커(AMM) 시뮬레이션을 위한 Python SDK_ ### [](https://ethereum.org/ko/developers/docs/programming-languages/python/#archived--no-longer-maintained) 보관됨 / 더 이상 유지보수되지 않음: * [Trinity (새 탭에서 열림)](https://github.com/ethereum/trinity) - _이더리움 Python 클라이언트_ * [Mamba (새 탭에서 열림)](https://github.com/arjunaskykok/mamba) - _Vyper 언어로 작성된 스마트 컨트랙트를 작성, 컴파일링 및 배포하기 위한 프레임워크_ * [Brownie (새 탭에서 열림)](https://github.com/eth-brownie/brownie) - _이더리움 스마트 컨트랙트 배포, 테스트 및 상호작용을 위한 Python 프레임워크_ * [pydevp2p (새 탭에서 열림)](https://github.com/ethereum/pydevp2p) - _이더리움 P2P 스택 구현체_ * [py-wasm (새 탭에서 열림)](https://github.com/ethereum/py-wasm) - _웹 어셈블리 인터프리터의 Python 구현체_ 더 많은 리소스를 찾고 계신가요? [ethereum.org/developers](https://ethereum.org/ko/developers/) 를 확인해 보세요. [](https://ethereum.org/ko/developers/docs/programming-languages/python/#projects-using-python-tooling) Python 도구를 사용하는 프로젝트 ---------------------------------------------------------------------------------------------------------------------------- 다음 이더리움 기반 프로젝트들은 이 페이지에서 언급된 도구를 사용합니다. 관련 오픈소스 리포지토리는 예제 코드와 모범 사례를 위한 좋은 참고 자료가 됩니다. * [Yearn Finance (새 탭에서 열림)](https://yearn.finance/) 및 [Yearn 볼트 컨트랙트 리포지토리 (새 탭에서 열림)](https://github.com/yearn/yearn-vaults) * [Curve (새 탭에서 열림)](https://www.curve.finance/) 및 [Curve 스마트 컨트랙트 리포지토리 (새 탭에서 열림)](https://github.com/curvefi/curve-contract) * [BadgerDAO (새 탭에서 열림)](https://badger.com/) 및 [Brownie 툴체인을 사용하는 스마트 컨트랙트 (새 탭에서 열림)](https://github.com/Badger-Finance/badger-system) * [Sushi (새 탭에서 열림)](https://sushi.com/) 는 [베스팅 컨트랙트를 관리하고 배포하는 데 Python을 사용합니다 (새 탭에서 열림)](https://github.com/sushiswap/sushi-vesting-protocols) * Alpha Homora로 유명한 [Alpha Finance (새 탭에서 열림)](https://alphaventuredao.io/) 는 [스마트 컨트랙트를 테스트하고 배포하는 데 Brownie를 사용합니다 (새 탭에서 열림)](https://github.com/AlphaFinanceLab/alpha-staking-contract) [](https://ethereum.org/ko/developers/docs/programming-languages/python/#python-community-contributors) Python 커뮤니티 토론 ---------------------------------------------------------------------------------------------------------------------- * Web3.py 및 기타 Python 프레임워크 토론을 위한 [이더리움 Python 커뮤니티 디스코드 (새 탭에서 열림)](https://discord.gg/9zk7snTfWe) * Vyper 스마트 컨트랙트 프로그래밍 토론을 위한 [Vyper 디스코드 (새 탭에서 열림)](https://discord.gg/SdvKC79cJk) [](https://ethereum.org/ko/developers/docs/programming-languages/python/#other-aggregated-lists) 기타 종합 목록 --------------------------------------------------------------------------------------------------------- Vyper 위키에는 [Vyper를 위한 훌륭한 리소스 목록 (새 탭에서 열림)](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources) 이 있습니다. --- # ポータル・ネットワーク | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/networking-layer/portal-network/#main-content) Change page ポータル・ネットワーク =========== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/networking-layer/portal-network/index.md) このページの内容 [イーサリアム](https://ethereum.org/ja/) は、イーサリアムのクライアントソフトウェアを実行するコンピュータで構成されるネットワークです。これらのコンピュータはそれぞれ「ノード」と呼ばれます。クライアントソフトウェアにより、ノードはイーサリアム・ネットワーク上でデータを送受信し、イーサリアムのプロトコルルールに照らしてデータを検証することができます。ノードはディスクストレージに大量の履歴データを保持しており、ネットワーク上の他のノードからブロックと呼ばれる新しい情報のパケットを受け取ると、それを追加します。これは、ノードがネットワークの他の部分と一貫した情報を持っていることを常に確認するために必要です。つまり、ノードを実行するには大量のディスク容量が必要になる場合があります。一部のノード操作では、大量のRAMも必要になる場合があります。 このディスクストレージの問題を回避するために、すべての情報を自分で保存するのではなく、フル・ノードに情報を要求する「ライト」ノードが開発されました。しかし、これはライト・ノードが情報を独立して検証しておらず、代わりに別のノードを信頼していることを意味します。また、フル・ノードはこれらのライト・ノードにサービスを提供するために追加の作業を引き受ける必要があることも意味します。 ポータル・ネットワークは、必要なデータを小さなチャンクに分割してネットワーク全体で共有することにより、フル・ノードを信頼したり余分な負担をかけたりすることなく、「ライト」ノードのデータ可用性の問題を解決することを目的とした、イーサリアムの新しいネットワーキング設計です。 [ノードとクライアント](https://ethereum.org/ja/developers/docs/nodes-and-clients/) の詳細 [](https://ethereum.org/ja/developers/docs/networking-layer/portal-network/#why-do-we-need-portal-network) なぜポータル・ネットワークが必要なのか ------------------------------------------------------------------------------------------------------------------------------ イーサリアムのノードは、イーサリアムのブロックチェーンの完全または部分的なコピーを独自に保存します。このローカルコピーは、トランザクションを検証し、ノードが正しいチェーンに従っていることを確認するために使用されます。このローカルに保存されたデータにより、ノードは他のエンティティを信頼することなく、受信したデータが有効で正しいことを独立して検証できます。 ブロックチェーンのこのローカルコピーと、関連する状態およびレシートデータは、ノードのハードディスク上の多くのスペースを占有します。たとえば、コンセンサス・クライアントとペアになった[Geth （新しいタブで開きます）](https://geth.ethereum.org/) を使用してノードを実行するには、2TBのハードディスクが推奨されます。比較的最近のブロックセットからのチェーンデータのみを保存するスナップ同期を使用すると、Gethは通常約650GBのディスク容量を占有しますが、週に約14GBのペースで増加します（定期的にノードをプルーニングして650GBまで減らすことができます）。 つまり、大量のディスク容量をイーサリアム専用にする必要があるため、ノードの実行にはコストがかかる可能性があります。イーサリアムのロードマップには、[履歴の失効](https://ethereum.org/ja/roadmap/statelessness/#history-expiry) 、[ステート失効](https://ethereum.org/ja/roadmap/statelessness/#state-expiry) 、[ステートレス性](https://ethereum.org/ja/roadmap/statelessness/) など、この問題に対するいくつかの解決策があります。ただし、これらが実装されるまでには数年かかる可能性があります。また、チェーンデータの独自のコピーを保存せず、必要なデータをフル・ノードに要求する[ライト・ノード](https://ethereum.org/ja/developers/docs/nodes-and-clients/light-clients/) もあります。しかし、これはライト・ノードが正直なデータを提供するためにフル・ノードを信頼しなければならないことを意味し、またライト・ノードが必要とするデータを提供しなければならないフル・ノードにストレスを与えます。 ポータル・ネットワークは、フル・ノードを信頼したり、フル・ノードが行わなければならない作業を大幅に増やしたりすることなく、ライト・ノードがデータを取得するための代替方法を提供することを目的としています。これを行う方法は、イーサリアムのノードがネットワーク全体でデータを共有するための新しい方法を導入することです。 [](https://ethereum.org/ja/developers/docs/networking-layer/portal-network/#how-does-portal-network-work) ポータル・ネットワークはどのように機能するのか？ ---------------------------------------------------------------------------------------------------------------------------------- イーサリアムのノードには、互いに通信する方法を定義する厳格なプロトコルがあります。実行クライアントは[devp2p](https://ethereum.org/ja/developers/docs/networking-layer/#devp2p) として知られるサブプロトコルのセットを使用して通信しますが、コンセンサス・クライアントは[libp2p](https://ethereum.org/ja/developers/docs/networking-layer/#libp2p) と呼ばれる異なるサブプロトコルのスタックを使用します。これらは、ノード間で渡すことができるデータの種類を定義します。 [![devP2P and libP2P](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fnetworking-layer%2Fportal-network%2Fportal-network-devp2p-libp2p.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/networking-layer/portal-network/portal-network-devp2p-libp2p.png) ノードは[JSON-RPC API](https://ethereum.org/ja/developers/docs/apis/json-rpc/) を介して特定のデータを提供することもできます。これは、アプリやウォレットがイーサリアムのノードと情報をスワップする方法です。ただし、これらはいずれもライト・クライアントにデータを提供するための理想的なプロトコルではありません。 ライト・クライアントは現在、devp2pやlibp2pを介して特定のチェーンデータを要求することはできません。これらのプロトコルは、チェーンの同期と、ブロックおよびトランザクションのゴシップを可能にするようにのみ設計されているためです。ライト・クライアントはこの情報をダウンロードしたくありません。なぜなら、そうすると「ライト」ではなくなってしまうからです。 JSON-RPC APIも、ライト・クライアントのデータ要求にとって理想的な選択肢ではありません。なぜなら、データを提供できる特定のフル・ノードまたは中央集権型のRPCプロバイダーへの接続に依存しているからです。これは、ライト・クライアントがその特定のノード/プロバイダーが正直であると信頼しなければならないことを意味し、またフル・ノードは多くのライト・クライアントからの多数の要求を処理しなければならない可能性があり、帯域幅の要件が増加します。 ポータル・ネットワークのポイントは、既存のイーサリアムクライアントの設計上の制約にとらわれず、特に軽量化のために構築された設計全体を再考することです。 ポータル・ネットワークの核となるアイデアは、[DHT （新しいタブで開きます）](https://en.wikipedia.org/wiki/Distributed_hash_table) （BitTorrentに似ています）を使用した軽量のdevp2pスタイルのピア・ツー・ピア分散型ネットワークを通じて、履歴データやチェーンの現在のヘッドのIDなど、ライト・クライアントが必要とする情報を提供できるようにすることで、現在のネットワーキングスタックの優れた部分を取り入れることです。 そのアイデアは、イーサリアムの全履歴データの小さな部分と、いくつかの特定のノードの責任を各ノードに追加することです。そして、要求された特定のデータを保存しているノードを探し出し、そこからデータを取得することで、要求が処理されます。 これは、ライト・ノードが単一のノードを見つけ、大量のデータをフィルタリングして提供するように要求するという通常のモデルを反転させます。代わりに、それぞれが少量のデータを処理するノードの大規模なネットワークをすばやくフィルタリングします。 目標は、軽量のポータルクライアントの分散型ネットワークが以下を行えるようにすることです。 * チェーンのヘッドを追跡する * 最近および過去のチェーンデータを同期する * 状態データを取得する * トランザクションをブロードキャストする * [EVM](https://ethereum.org/ja/developers/docs/evm/) を使用してトランザクションを実行する このネットワーク設計の利点は次のとおりです。 * 中央集権型プロバイダーへの依存を減らす * インターネットの帯域幅の使用量を減らす * 同期を最小限に抑えるか、ゼロにする * リソースに制約のあるデバイス（1GB未満のRAM、100MB未満のディスク容量、1CPU）からアクセス可能 以下の表は、ポータル・ネットワークによって提供できる既存のクライアントの機能を示しており、ユーザーは非常にリソースの少ないデバイスでこれらの機能にアクセスできるようになります。 ### [](https://ethereum.org/ja/developers/docs/networking-layer/portal-network/#the-portal-networks) ポータル・ネットワーク | ビーコン・ライト・クライアント | 状態ネットワーク | トランザクション・ゴシップ | 履歴ネットワーク | 正規トランザクション・インデックス | | --- | --- | --- | --- | --- | | ビーコンチェーン・ライト | アカウントとコントラクトのストレージ | 軽量メンプール | ヘッダー | TxHash > ハッシュ、インデックス | | プロトコルデータ | | | ブロックボディ | | | | | | レシート | | [](https://ethereum.org/ja/developers/docs/networking-layer/portal-network/#client-diversity-as-default) デフォルトでのクライアント・ダイバーシティ ------------------------------------------------------------------------------------------------------------------------------ ポータル・ネットワークの開発者はまた、初日から4つの別々のポータル・ネットワーククライアントを構築するという設計上の選択を行いました。 ポータル・ネットワーククライアントは次のとおりです。 * [Trin （新しいタブで開きます）](https://github.com/ethereum/trin) : Rustで記述 * [Fluffy （新しいタブで開きます）](https://fluffy.guide/) : Nimで記述 * [Ultralight （新しいタブで開きます）](https://github.com/ethereumjs/ultralight) : TypeScriptで記述 * [Shisui （新しいタブで開きます）](https://github.com/zen-eth/shisui) : Goで記述 複数の独立したクライアント実装を持つことで、イーサリアム・ネットワークの回復力と分散化が強化されます。 1つのクライアントで問題や脆弱性が発生した場合でも、他のクライアントはスムーズに動作し続けることができ、単一障害点を防ぐことができます。さらに、多様なクライアント実装はイノベーションと競争を促進し、エコシステム内の改善を推進し、モノカルチャーのリスクを軽減します。 [](https://ethereum.org/ja/developers/docs/networking-layer/portal-network/#further-reading) 参考文献 ------------------------------------------------------------------------------------------------- * [ポータル・ネットワーク（Devcon BogotaでのPiper Merriam） （新しいタブで開きます）](https://www.youtube.com/watch?v=0stc9jnQLXA) 。 * [ポータル・ネットワークのディスコード （新しいタブで開きます）](https://discord.gg/CFFnmE7Hbs) * [ポータル・ネットワークのウェブサイト （新しいタブで開きます）](https://www.ethportal.net/) --- # ERC-7540 非同期トークン化ヴォールト標準 | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#main-content) Change page ERC-7540 非同期トークン化ヴォールト標準 ======================== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/tokens/erc-7540/index.md) このページの内容 [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#introduction) はじめに ---------------------------------------------------------------------------------------- ERC-7540は、非同期の預入れ (deposit) および償還 (redemption) フローのサポートを追加することで、[ERC-4626 トークン化ヴォールト標準](https://ethereum.org/ja/developers/docs/standards/tokens/erc-4626/) を拡張します。この標準では、リクエスト後に請求 (claim) するパターンが導入されています。ユーザーはまずリクエストを送信して資産やシェアをロックし、ヴォールトがそれを処理した後に結果を請求します。 これは、ヴォールトが1つのトランザクションで即座にセトルメントできない場合に必要となります。例えば以下の通りです。 * トークン化された米国債、プライベートクレジット、その他T+1やT+2のセトルメントサイクルを持つ資産などのリアル・ワールド・アセット (RWA) プロトコル * 信用評価がオフチェーンで行われる無担保レンディング * ブリッジングによって遅延が生じるクロスチェーンのヴォールトストラテジー * アンボンディング期間があるリキッド・ステーキング・トークン (LST) ヴォールトは、預入れのみ、償還のみ、またはその両方で非同期にすることを選択できます。この柔軟性により、ヴォールト開発者は、基盤となるストラテジーが要求する部分にのみ非同期フローを追加し、もう一方を同期的なままに保つことができます。 [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#prerequisites) 前提知識 ----------------------------------------------------------------------------------------- このページをより深く理解するために、まずは[トークン標準](https://ethereum.org/ja/developers/docs/standards/tokens/) 、[ERC-20](https://ethereum.org/ja/developers/docs/standards/tokens/erc-20/) 、および[ERC-4626](https://ethereum.org/ja/developers/docs/standards/tokens/erc-4626/) について読むことをお勧めします。 [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#comparison) ERC-4626とERC-7540の比較 ------------------------------------------------------------------------------------------------------ ERC-4626では、預入れはアトミックにセトルメントされます。つまり、投資家は1つのトランザクションで資産を送金し、シェアを受け取ります。 [![ERC-4626 synchronous deposit flow](https://ethereum.org/content/developers/docs/standards/tokens/erc-7540/erc-4626-sync-flow.svg)](https://ethereum.org/content/developers/docs/standards/tokens/erc-7540/erc-4626-sync-flow.svg) ERC-7540はこれを2つのステップに分割します。投資家はまず`requestDeposit()`を呼び出して資産をロックし、ヴォールト管理者がリクエストを処理するのを待ちます。処理が完了すると、投資家は`deposit()`を呼び出してシェアを請求します。交換レートはリクエスト時ではなく、処理完了時に決定されます。 [![ERC-7540 asynchronous deposit flow](https://ethereum.org/content/developers/docs/standards/tokens/erc-7540/erc-7540-async-flow.svg)](https://ethereum.org/content/developers/docs/standards/tokens/erc-7540/erc-7540-async-flow.svg) 償還フローも同様に機能します。`requestRedeem()`でシェアをロックし、処理が完了すると投資家は`redeem()`を呼び出して資産を請求します。 [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#body) ERC-7540の関数と機能 ------------------------------------------------------------------------------------------ ERC-7540はERC-4626のインターフェースを完全に継承していますが、`deposit` / `mint` / `withdraw` / `redeem`を請求関数として再利用します。新しい`requestDeposit`および`requestRedeem`関数は、最初のリクエストステップを処理します。 各リクエストは3つの状態を遷移します。保留中 (pending: 送信済みで処理待ち)、請求可能 (claimable: 処理完了および価格決定済み)、および請求済み (claimed: 投資家がシェアまたは資産を回収済み) です。 [![Request lifecycle: Pending, Claimable, Claimed](https://ethereum.org/content/developers/docs/standards/tokens/erc-7540/request-lifecycle.svg)](https://ethereum.org/content/developers/docs/standards/tokens/erc-7540/request-lifecycle.svg) ### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#deposit-request-flow) 預入れリクエストフロー #### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#requestdeposit) requestDeposit function requestDeposit(uint256 assets, address controller, address owner) external returns (uint256 requestId) コピーSolidity `owner`からヴォールトへ`assets`を送金し、預入れリクエストを送信します。`controller`アドレスがリクエストの制御権を受け取ります。リクエストバッチを識別する`requestId`を返します。 #### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#pendingdepositrequest) pendingDepositRequest function pendingDepositRequest(uint256 requestId, address controller) external view returns (uint256 assets) コピーSolidity 指定された`controller`および`requestId`に対する、保留中 (まだ請求可能ではない) の預入れリクエストにおける`assets`の量を返します。 #### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#claimabledepositrequest) claimableDepositRequest function claimableDepositRequest(uint256 requestId, address controller) external view returns (uint256 assets) コピーSolidity 指定された`controller`および`requestId`に対する、請求可能 (処理完了済みだがまだ請求されていない) な預入れリクエストにおける`assets`の量を返します。 #### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#claiming-deposits) 預入れの請求 預入れリクエストが請求可能になると、ユーザーは標準のERC-4626の[`deposit`](https://ethereum.org/ja/developers/docs/standards/tokens/erc-4626/#deposit) または[`mint`](https://ethereum.org/ja/developers/docs/standards/tokens/erc-4626/#mint) 関数を呼び出してシェアを請求します。ERC-7540では、これらの関数はもはや資産を送金しません (それはリクエスト時にすでに完了しています)。受信者に対してシェアをミントするだけです。 ### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#redemption-request-flow) 償還リクエストフロー #### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#requestredeem) requestRedeem function requestRedeem(uint256 shares, address controller, address owner) external returns (uint256 requestId) コピーSolidity `owner`から`shares`をロックし、償還リクエストを送信します。`controller`アドレスがリクエストの制御権を受け取ります。 #### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#pendingredeemrequest) pendingRedeemRequest function pendingRedeemRequest(uint256 requestId, address controller) external view returns (uint256 shares) コピーSolidity 指定された`controller`および`requestId`に対する、保留中の償還リクエストにおける`shares`の量を返します。 #### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#claimableredeemrequest) claimableRedeemRequest function claimableRedeemRequest(uint256 requestId, address controller) external view returns (uint256 shares) コピーSolidity 指定された`controller`および`requestId`に対する、請求可能な償還リクエストにおける`shares`の量を返します。 #### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#claiming-redemptions) 償還の請求 償還リクエストが請求可能になると、ユーザーは標準のERC-4626の[`redeem`](https://ethereum.org/ja/developers/docs/standards/tokens/erc-4626/#redeem) または[`withdraw`](https://ethereum.org/ja/developers/docs/standards/tokens/erc-4626/#withdraw) 関数を呼び出して資産を請求します。 ### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#operator-management) オペレーター管理 ERC-7540には、サードパーティがユーザーに代わってリクエストを管理できるようにするオペレーターパターン ([ERC-6909 （新しいタブで開きます）](https://eips.ethereum.org/EIPS/eip-6909) 由来) が含まれています。 #### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#setoperator) setOperator function setOperator(address operator, bool approved) external returns (bool) コピーSolidity 預入れ/償還リクエストおよび請求に関して、`msg.sender`の代理として行動する`operator`を承認または取り消します。 #### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#isoperator) isOperator function isOperator(address controller, address operator) external view returns (bool) コピーSolidity `operator`が`controller`の代理として行動することを承認されているかどうかを返します。 ### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#request-ids) リクエストID リクエストIDは、異なるリクエストバッチを区別します。同じ`requestId`を共有するすべてのリクエストは代替可能 (fungible) であり、一緒に状態を遷移し、同じ交換レートを受け取ります。 ヴォールトがすべてのリクエストに対して`requestId = 0`を返す場合、`controller`アドレスのみがリクエストの状態を区別します。同じコントローラーからの複数のリクエストは集約されます。 ### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#events) イベント #### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#depositrequest-event) DepositRequestイベント 預入れリクエストが[`requestDeposit`](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#requestdeposit) 経由で送信されたときに発行されなければなりません (MUST)。 event DepositRequest( address indexed controller, address indexed owner, uint256 indexed requestId, address sender, uint256 assets ) コピーSolidity #### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#redeemrequest-event) RedeemRequestイベント 償還リクエストが[`requestRedeem`](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#requestredeem) 経由で送信されたときに発行されなければなりません (MUST)。 event RedeemRequest( address indexed controller, address indexed owner, uint256 indexed requestId, address sender, uint256 shares ) コピーSolidity #### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#operatorset-event) OperatorSetイベント オペレーターが[`setOperator`](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#setoperator) 経由で承認または取り消されたときに発行されなければなりません (MUST)。 event OperatorSet( address indexed controller, address indexed operator, bool approved ) コピーSolidity ### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#preview-functions) プレビュー関数 プレビュー関数は、非同期のフローに対してのみリバートしなければなりません。なぜなら、リクエストが処理されるまで交換レートが不明だからです。非同期預入れヴォールトでは、`previewDeposit`および`previewMint`はリバートしなければならず (MUST)、一方で`previewRedeem`および`previewWithdraw`はERC-4626と同様に機能し続けます (非同期償還ヴォールトの場合はその逆になります)。これはERC-4626との重要な動作上の違いです。 [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-7540/#further-reading) 参考文献 ------------------------------------------------------------------------------------------- * [EIP-7540: 非同期ERC-4626トークン化ヴォールト （新しいタブで開きます）](https://eips.ethereum.org/EIPS/eip-7540) * [EIP-4626: トークン化ヴォールト標準 （新しいタブで開きます）](https://eips.ethereum.org/EIPS/eip-4626) * [オープンツェッペリンのERC-7540実装 （新しいタブで開きます）](https://github.com/OpenZeppelin/openzeppelin-community-contracts/blob/master/contracts/token/ERC20/extensions/ERC7540.sol) --- # データ可用性 | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/data-availability/#main-content) Change page データ可用性 ====== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-availability/index.md) このページの内容 「信じるな、検証せよ (Don't trust, verify)」は、イーサリアムにおける一般的な格言です。この考え方は、ノードがピアから受け取ったブロック内のすべてのトランザクションを実行し、提案された変更がノード自身が独立して計算したものと正確に一致することを確認することで、受け取った情報が正しいことを独立して検証できるというものです。これは、ノードがブロックの送信者が誠実であると信頼する必要がないことを意味します。データが欠落している場合、これは不可能です。 **データ可用性**とは、ブロックを検証するために必要なデータが、すべてのネットワーク参加者にとって実際に利用可能であるとユーザーが確信できる度合いを指します。[イーサリアム](https://ethereum.org/ja/) のレイヤー1 (L1) 上のフル・ノードにとって、これは比較的単純です。フル・ノードは各ブロック内のすべてのデータのコピーをダウンロードします。ダウンロードが可能であるためには、データが利用可能で_なければなりません_。データが欠落しているブロックは、ブロックチェーンに追加されるのではなく破棄されます。これが「オンチェーンのデータ可用性」であり、モノリシックなブロックチェーンの特徴です。フル・ノードはすべてのトランザクションを自分でダウンロードして実行するため、騙されて無効なトランザクションを受け入れることはありません。しかし、モジュラー型のブロックチェーン、レイヤー2 (L2) のロールアップ、およびライト・クライアントの場合、データ可用性の状況はより複雑であり、より高度な検証手順が必要になります。 [](https://ethereum.org/ja/developers/docs/data-availability/#prerequisites) 前提知識 --------------------------------------------------------------------------------- [ブロックチェーンの基礎](https://ethereum.org/ja/developers/docs/intro-to-ethereum/) 、特に[コンセンサス・メカニズム](https://ethereum.org/ja/developers/docs/consensus-mechanisms/) について十分に理解している必要があります。また、このページでは、読者が[ブロック](https://ethereum.org/ja/developers/docs/blocks/) 、[トランザクション](https://ethereum.org/ja/developers/docs/transactions/) 、[ノード](https://ethereum.org/ja/developers/docs/nodes-and-clients/) 、[スケーリング・ソリューション](https://ethereum.org/ja/developers/docs/scaling/) 、およびその他の関連トピックに精通していることを前提としています。 [](https://ethereum.org/ja/developers/docs/data-availability/#the-data-availability-problem) データ可用性の問題 ------------------------------------------------------------------------------------------------------ データ可用性の問題とは、ブロックチェーンに追加されるトランザクション・データの要約形式が、実際に有効なトランザクションのセットを表していることをネットワーク全体に証明する必要がある一方で、すべてのノードにすべてのデータをダウンロードさせることなくそれを行う必要があるという問題です。ブロックを独立して検証するには完全なトランザクション・データが必要ですが、すべてのノードにすべてのトランザクション・データをダウンロードさせることはスケーリングの障壁となります。データ可用性の問題に対する解決策は、データを自分でダウンロードして保存しないネットワーク参加者に対して、完全なトランザクション・データが検証のために利用可能にされたという十分な保証を提供することを目指しています。 [ライト・ノード](https://ethereum.org/ja/developers/docs/nodes-and-clients/light-clients/) と[レイヤー2 (L2) のロールアップ](https://ethereum.org/ja/developers/docs/scaling/) は、強力なデータ可用性の保証を必要とするものの、トランザクション・データを自分でダウンロードして処理することができないネットワーク参加者の重要な例です。トランザクション・データのダウンロードを避けることが、ライト・ノードを軽量にし、ロールアップを効果的なスケーリング・ソリューションにしている理由です。 データ可用性は、ブロックを検証するために状態データをダウンロードして保存する必要がない、将来の[「ステートレス」](https://ethereum.org/ja/roadmap/statelessness/) なイーサリアム・クライアントにとっても重要な懸念事項です。ステートレス・クライアントは依然として、データが_どこか_で利用可能であり、正しく処理されたことを確信する必要があります。 [](https://ethereum.org/ja/developers/docs/data-availability/#data-availability-solutions) データ可用性の解決策 ----------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ja/developers/docs/data-availability/#data-availability-sampling) データ可用性サンプリング (DAS) データ可用性サンプリング (DAS) は、個々のノードに過度な負担をかけることなく、ネットワークがデータが利用可能であることを確認する方法です。各ノード (ステーキングを行っていないノードを含む) は、全体のデータからランダムに選択された小さなサブセットをダウンロードします。サンプルのダウンロードに成功すると、すべてのデータが利用可能であることが高い確度で確認されます。これは、冗長な情報で特定のデータセットを拡張するデータ・イレイジャー・コーディングに依存しています (この方法は、データに_多項式_と呼ばれる関数を当てはめ、追加のポイントでその多項式を評価することによって行われます)。これにより、必要に応じて冗長データから元のデータを復元できます。このデータ作成の結果として、元のデータの_いずれか_が利用できない場合、拡張されたデータの_半分_が欠落することになります。各ノードがダウンロードするデータ・サンプルの量は、実際に利用可能なデータが半分未満である_場合_、各クライアントがサンプリングしたデータ・フラグメントの少なくとも1つが欠落する可能性が_極めて_高くなるように調整できます。 DASは、[完全なダンクシャーディング](https://ethereum.org/ja/roadmap/danksharding/#what-is-danksharding) が実装された後、ロールアップ・オペレーターがトランザクション・データを利用可能にすることを保証するために使用されます。イーサリアムのノードは、上記で説明した冗長性スキームを使用して、ブロブで提供されるトランザクション・データをランダムにサンプリングし、すべてのデータが存在することを確認します。同じ技術は、ブロック生成者がライト・クライアントを保護するためにすべてのデータを利用可能にしていることを保証するためにも採用できます。同様に、[プロポーザー・ビルダー分離 (PBS)](https://ethereum.org/ja/roadmap/pbs/) の下では、ブロック・ビルダーのみがブロック全体を処理する必要があり、他のバリデータはデータ可用性サンプリングを使用して検証します。 ### [](https://ethereum.org/ja/developers/docs/data-availability/#data-availability-committees) データ可用性コミッティ データ可用性コミッティ (DAC) は、データ可用性を提供または証明する信頼された当事者です。DACは、DASの代わりに、[またはDASと組み合わせて （新しいタブで開きます）](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) 使用できます。コミッティに伴うセキュリティ保証は、具体的な設定によって異なります。例えば、イーサリアムはランダムにサンプリングされたバリデータのサブセットを使用して、ライト・ノードのデータ可用性を証明します。 DACは一部のValidiumでも使用されています。DACは、データのコピーをオフラインで保存する信頼されたノードのセットです。DACは、紛争が発生した場合にデータを利用可能にすることが求められます。また、DACのメンバーは、当該データが実際に利用可能であることを証明するために、オンチェーンで証明を公開します。一部のValidiumは、DACをプルーフ・オブ・ステーク (PoS) のバリデータ・システムに置き換えています。ここでは、誰でもバリデータになり、データをオフチェーンで保存できます。ただし、スマート・コントラクトに預け入れられる「保証金 (bond)」を提供する必要があります。バリデータがデータを隠蔽するなどの悪意のある行動をとった場合、保証金はスラッシングされる可能性があります。プルーフ・オブ・ステークのデータ可用性コミッティは、誠実な行動に直接インセンティブを与えるため、通常のDACよりもはるかに安全です。 [](https://ethereum.org/ja/developers/docs/data-availability/#data-availability-and-light-nodes) データ可用性とライト・ノード --------------------------------------------------------------------------------------------------------------- [ライト・ノード](https://ethereum.org/ja/developers/docs/nodes-and-clients/light-clients/) は、ブロック・データをダウンロードすることなく、受け取ったブロック・ヘッダーの正確性を検証する必要があります。この軽量さの代償として、フル・ノードのようにローカルでトランザクションを再実行してブロック・ヘッダーを独立して検証することはできません。 イーサリアムのライト・ノードは、_シンク・コミッティ_に割り当てられた512のバリデータのランダムなセットを信頼します。シンク・コミッティはDACとして機能し、暗号化された署名を使用して、ヘッダー内のデータが正しいことをライト・クライアントに伝えます。シンク・コミッティは毎日更新されます。各ブロック・ヘッダーは、_次_のブロックに署名することが期待されるバリデータをライト・ノードに通知するため、本物のシンク・コミッティを装った悪意のあるグループを信頼するように騙されることはありません。 しかし、攻撃者がどうにかして悪意のあるブロック・ヘッダーをライト・クライアントに渡し、それが誠実なシンク・コミッティによって署名されたと信じ込ませることに成功した場合はどうなるでしょうか。その場合、攻撃者は無効なトランザクションを含めることができ、ライト・クライアントはブロック・ヘッダーに要約されたすべての状態変更を独立してチェックしないため、それらを盲目的に受け入れてしまいます。これを防ぐために、ライト・クライアントは不正証明を使用できます。 これらの不正証明の仕組みは、ネットワーク上でゴシップされている無効な状態遷移を見たフル・ノードが、提案された状態遷移が特定のトランザクションのセットから生じるはずがないことを示す小さなデータを迅速に生成し、そのデータをピアにブロードキャストするというものです。ライト・ノードはそれらの不正証明を受け取り、それらを使用して不正なブロック・ヘッダーを破棄し、フル・ノードと同じ誠実なチェーンに留まることができます。 これは、フル・ノードが完全なトランザクション・データにアクセスできることに依存しています。不正なブロック・ヘッダーをブロードキャストし、さらにトランザクション・データを利用可能にしない攻撃者は、フル・ノードが不正証明を生成するのを防ぐことができます。フル・ノードは不正なブロックに関する警告を発することはできるかもしれませんが、証明を生成するためのデータが利用可能にされていないため、証明で警告を裏付けることはできません。 このデータ可用性の問題に対する解決策がDASです。ライト・ノードは、完全な状態データの非常に小さなランダムなチャンクをダウンロードし、そのサンプルを使用して完全なデータセットが利用可能であることを検証します。N個のランダムなチャンクをダウンロードした後に、完全なデータ可用性があると誤って想定する実際の可能性は計算できます ([100個のチャンクの場合、その確率は10^-30です （新しいタブで開きます）](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) 。つまり、信じられないほど低確率です)。 このシナリオにおいてさえ、わずか数バイトを隠蔽する攻撃は、ランダムなデータ・リクエストを行うクライアントに気づかれない可能性があります。イレイジャー・コーディングは、提案された状態変更をチェックするために使用できる小さな欠落データを再構築することで、これを解決します。その後、再構築されたデータを使用して不正証明を構築し、ライト・ノードが不正なヘッダーを受け入れるのを防ぐことができます。 **注:** DASと不正証明は、プルーフ・オブ・ステークのイーサリアムのライト・クライアントにはまだ実装されていませんが、ロードマップに載っており、おそらくZK-SNARKベースの証明の形をとるでしょう。現在のライト・クライアントはDACの一形態に依存しています。つまり、シンク・コミッティの身元を検証し、受け取った署名付きブロック・ヘッダーを信頼します。 [](https://ethereum.org/ja/developers/docs/data-availability/#data-availability-and-layer-2-rollups) データ可用性とレイヤー2 (L2) のロールアップ ------------------------------------------------------------------------------------------------------------------------------ などの[レイヤー2 (L2) のスケーリング・ソリューション](https://ethereum.org/ja/layer-2/) は、トランザクションをオフチェーンで処理することにより、トランザクション・コストを削減し、イーサリアムのスループットを向上させます。ロールアップのトランザクションは圧縮され、バッチとしてイーサリアムに投稿されます。バッチは、イーサリアム上の単一のトランザクションで数千の個別のオフチェーン・トランザクションを表します。これにより、ベース・レイヤーの混雑が緩和され、ユーザーの料金が削減されます。 しかし、イーサリアムに投稿された「要約」トランザクションを信頼できるのは、提案された状態変更が独立して検証可能であり、すべての個別のオフチェーン・トランザクションを適用した結果であることが確認できる場合のみです。ロールアップ・オペレーターがこの検証のためにトランザクション・データを利用可能にしない場合、誤ったデータをイーサリアムに送信する可能性があります。 [オプティミスティック・ロールアップ](https://ethereum.org/ja/developers/docs/scaling/optimistic-rollups/) は、圧縮されたトランザクション・データをイーサリアムに投稿し、独立した検証者がデータをチェックできるように一定期間 (通常は7日間) 待機します。誰かが問題を特定した場合、不正証明を生成してロールアップに異議を申し立てることができます。これにより、チェーンはロールバックされ、無効なブロックが省略されます。これは、データが利用可能な場合にのみ可能です。現在、オプティミスティック・ロールアップがトランザクション・データをレイヤー1 (L1) に投稿する方法は2つあります。一部のロールアップは、オンチェーンに永続的に存在する`CALLDATA`としてデータを永続的に利用可能にします。EIP-4844の実装により、一部のロールアップは代わりにトランザクション・データをより安価なブロブ・ストレージに投稿します。これは永続的なストレージではありません。独立した検証者は、データがイーサリアムのレイヤー1から削除される前の約18日以内に、ブロブをクエリして異議を申し立てる必要があります。データ可用性は、その短い固定期間のみイーサリアム・プロトコルによって保証されます。その後は、イーサリアム・エコシステム内の他のエンティティの責任となります。どのノードも、DASを使用して、つまりブロブ・データの小さなランダムなサンプルをダウンロードすることによって、データ可用性を検証できます。 [ゼロ知識 (ZK) ロールアップ](https://ethereum.org/ja/developers/docs/scaling/zk-rollups/) は、が状態遷移の正確性を保証するため、トランザクション・データを投稿する必要はありません。しかし、状態データにアクセスできなければZKロールアップの機能 (またはそれとの対話) を保証できないため、データ可用性は依然として問題です。例えば、オペレーターがロールアップの状態に関する詳細を隠蔽した場合、ユーザーは自分の残高を知ることができません。また、新しく追加されたブロックに含まれる情報を使用して状態の更新を実行することもできません。 [](https://ethereum.org/ja/developers/docs/data-availability/#data-availability-vs-data-retrievability) データ可用性とデータ検索可能性 ----------------------------------------------------------------------------------------------------------------------- データ可用性はデータ検索可能性とは異なります。データ可用性とは、フル・ノードが特定のブロックに関連付けられたトランザクションの完全なセットにアクセスし、検証できたという保証です。これは必ずしも、データが永久にアクセス可能であることを意味するわけではありません。 データ検索可能性とは、ノードがブロックチェーンから_履歴情報_を取得する能力のことです。この履歴データは新しいブロックの検証には必要なく、ジェネシス・ブロックからフル・ノードを同期したり、特定の履歴リクエストを処理したりするためにのみ必要です。 コアとなるイーサリアム・プロトコルは、主にデータ可用性に関心があり、データ検索可能性には関心がありません。データ検索可能性は、サードパーティによって運営される少数のアーカイブ・ノードによって提供されるか、[ポータル・ネットワーク （新しいタブで開きます）](https://www.ethportal.net/) などの分散型ファイル・ストレージを使用してネットワーク全体に分散させることができます。 [](https://ethereum.org/ja/developers/docs/data-availability/#further-reading) 参考文献 ----------------------------------------------------------------------------------- * [データ可用性とは何か？ (WTF is Data Availability?) （新しいタブで開きます）](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) * [データ可用性とは何か？ (What Is Data Availability?) （新しいタブで開きます）](https://coinmarketcap.com/academy/article/what-is-data-availability) * [データ可用性チェックの入門 (A primer on data availability checks) （新しいタブで開きます）](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) * [シャーディング + DAS提案の解説 (An explanation of the sharding + DAS proposal) （新しいタブで開きます）](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) * [データ可用性とイレイジャー・コーディングに関するメモ (A note on data availability and erasure coding) （新しいタブで開きます）](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) * [データ可用性コミッティ (Data availability committees.) （新しいタブで開きます）](https://medium.com/starkware/data-availability-e5564c416424) * [プルーフ・オブ・ステークのデータ可用性コミッティ (Proof-of-stake data availability committees.) （新しいタブで開きます）](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) * [データ検索可能性問題の解決策 (Solutions to the data retrievability problem) （新しいタブで開きます）](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) * [データ可用性、あるいはロールアップはいかにして心配するのをやめてイーサリアムを愛するようになったか (Data Availability Or: How Rollups Learned To Stop Worrying And Love Ethereum) （新しいタブで開きます）](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) * [EIP-7623: コールデータのコスト増加 (EIP-7623: Increasing Calldata Cost) （新しいタブで開きます）](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) --- # 클라이언트 다양성 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#main-content) Change page 클라이언트 다양성 ========= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/nodes-and-clients/client-diversity/index.md) 이 페이지의 내용 [이더리움](https://ethereum.org/ko/) 노드의 동작은 실행 중인 클라이언트 소프트웨어에 의해 제어됩니다. 여러 프로덕션 수준의 이더리움 클라이언트가 있으며, 각각 서로 다른 팀에서 다양한 언어로 개발 및 유지 관리합니다. 클라이언트는 서로 원활하게 통신하고 동일한 기능을 가지며 동등한 사용자 경험을 제공하도록 공통 사양에 따라 구축됩니다. 하지만 현재 노드 간 클라이언트 분포는 이러한 네트워크 강화의 잠재력을 최대한 실현할 만큼 균등하지 않습니다. 이상적으로는 사용자가 다양한 클라이언트에 거의 균등하게 나뉘어 네트워크에 최대한의 클라이언트 다양성을 가져오는 것입니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#prerequisites) 전제 조건 --------------------------------------------------------------------------------------------------- 노드와 클라이언트가 무엇인지 아직 이해하지 못했다면 [노드와 클라이언트](https://ethereum.org/ko/developers/docs/nodes-and-clients/) 를 확인해 보세요. 과 는 용어집에 정의되어 있습니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#why-multiple-clients) 왜 여러 클라이언트가 있나요? --------------------------------------------------------------------------------------------------------------------- 클라이언트 다양성이 네트워크를 공격과 버그에 더 탄력적으로 만들기 때문에 독립적으로 개발되고 유지 관리되는 여러 클라이언트가 존재합니다. 다중 클라이언트는 이더리움만의 고유한 강점입니다. 다른 블록체인은 단일 클라이언트의 무결성에 의존합니다. 하지만 단순히 여러 클라이언트를 사용할 수 있는 것만으로는 충분하지 않으며, 커뮤니티에서 이를 채택하고 전체 활성 노드가 비교적 균등하게 분산되어야 합니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#client-diversity-importance) 클라이언트 다양성이 왜 중요한가요? ------------------------------------------------------------------------------------------------------------------------------- 독립적으로 개발되고 유지 관리되는 여러 클라이언트를 보유하는 것은 탈중앙화된 네트워크의 건전성을 위해 필수적입니다. 그 이유를 살펴보겠습니다. ### [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#bugs) 버그 개별 클라이언트의 버그는 이더리움 노드의 소수를 차지할 때 네트워크에 미치는 위험이 적습니다. 여러 클라이언트에 노드가 거의 균등하게 분산되어 있으면 대부분의 클라이언트가 공통된 문제를 겪을 가능성이 작아지며, 결과적으로 네트워크는 더 강력해집니다. ### [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#resilience) 공격에 대한 복원력 클라이언트 다양성은 공격에 대한 복원력도 제공합니다. 예를 들어, [특정 클라이언트를 속여 (새 탭에서 열림)](https://twitter.com/vdWijden/status/1437712249926393858) 체인의 특정 브랜치로 유도하는 공격은 다른 클라이언트가 동일한 방식으로 악용될 가능성이 낮고 표준 체인이 손상되지 않은 상태로 유지되기 때문에 성공할 가능성이 낮습니다. 클라이언트 다양성이 낮으면 지배적인 클라이언트에 대한 해킹과 관련된 위험이 커집니다. 클라이언트 다양성은 이미 네트워크에 대한 악의적인 공격을 방어하는 중요한 수단임이 입증되었습니다. 예를 들어, 2016년 상하이 서비스 거부 공격은 공격자가 지배적인 클라이언트인 고 이더리움 (geth)을 속여 블록당 수만 번의 느린 디스크 I/O 작업을 실행하도록 만들 수 있었기 때문에 가능했습니다. 해당 취약점을 공유하지 않는 대체 클라이언트도 온라인 상태였기 때문에, 이더리움은 공격에 저항하고 고 이더리움 (geth)의 취약점이 수정되는 동안 계속 작동할 수 있었습니다. ### [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#finality) 지분 증명 (PoS) 완결성 이더리움 노드의 33% 이상을 차지하는 합의 클라이언트에 버그가 발생하면 합의 레이어가 완결성을 달성하지 못할 수 있으며, 이는 사용자가 어느 시점에서 트랜잭션이 되돌려지거나 변경되지 않을 것이라고 신뢰할 수 없음을 의미합니다. 이는 이더리움 위에 구축된 많은 앱, 특히 탈중앙화 금융 (DeFi)에 매우 큰 문제가 될 것입니다. 더 나쁜 것은, 3분의 2 이상의 절대다수를 차지하는 클라이언트에 치명적인 버그가 발생하면 체인이 [잘못 분할되고 완결성을 달성](https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/) 하여 대규모 검증자 세트가 유효하지 않은 체인에 갇히게 될 수 있다는 점입니다. 올바른 체인에 다시 합류하려면 이러한 검증자는 슬래싱을 당하거나 느리고 비용이 많이 드는 자발적 인출 및 재활성화를 거쳐야 합니다. 슬래싱의 규모는 책임이 있는 노드의 수에 비례하며, 3분의 2 이상의 절대다수가 최대치(32 ETH)로 슬래싱됩니다. 이러한 시나리오가 발생할 가능성은 낮지만, 이더리움 생태계는 활성 노드 전체에 클라이언트 분포를 균등하게 함으로써 그 위험을 완화할 수 있습니다. 이상적으로는 어떤 합의 클라이언트도 전체 노드의 33% 점유율에 도달하지 않아야 합니다. ### [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#responsibility) 책임 분담 다수 클라이언트를 보유하는 데에는 인적 비용도 따릅니다. 소규모 개발 팀에 과도한 부담과 책임을 지웁니다. 클라이언트 다양성이 낮을수록 다수 클라이언트를 유지 관리하는 개발자의 책임 부담이 커집니다. 여러 팀에 이 책임을 분산시키는 것은 이더리움의 노드 네트워크와 인적 네트워크 모두의 건전성에 좋습니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#current-client-diversity) 현재 클라이언트 다양성 --------------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#execution-clients-breakdown) 실행 클라이언트 * Geth41.0% * Nethermind38.0% * Besu16.0% * Erigon3.0% * Reth2.0% ### [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#consensus-clients-breakdown) 합의 클라이언트 * Lighthouse42.7% * Prysm30.9% * Teku13.9% * Nimbus8.7% * Lodestar2.7% * Grandine1.0% * 기타0.1% 이 다이어그램은 최신 정보가 아닐 수 있습니다. 최신 정보는 [ethernodes.org (새 탭에서 열림)](https://ethernodes.org/) 및 [clientdiversity.org (새 탭에서 열림)](https://clientdiversity.org/) 에서 확인하세요. 위의 두 원형 차트는 실행 계층과 합의 레이어의 현재 클라이언트 다양성 스냅샷을 보여줍니다(2025년 10월 작성 기준). 클라이언트 다양성은 수년에 걸쳐 개선되었으며, 실행 계층에서는 [고 이더리움 (geth) (새 탭에서 열림)](https://geth.ethereum.org/) 의 지배력이 감소했습니다. [네더마인드 (새 탭에서 열림)](https://www.nethermind.io/nethermind-client) 가 근소한 차이로 2위, [베수 (새 탭에서 열림)](https://besu.hyperledger.org/) 가 3위, [에리곤 (새 탭에서 열림)](https://github.com/ledgerwatch/erigon) 이 4위를 차지했으며, 기타 클라이언트는 네트워크의 3% 미만을 구성합니다. 합의 레이어에서 가장 많이 사용되는 클라이언트인 [라이트하우스 (새 탭에서 열림)](https://lighthouse.sigmaprime.io/) 는 두 번째로 많이 사용되는 클라이언트와 꽤 근접해 있습니다. [프리즘 (새 탭에서 열림)](https://prysmaticlabs.com/#projects) 과 [테쿠 (새 탭에서 열림)](https://consensys.net/knowledge-base/ethereum-2/teku/) 는 각각 약 31%와 약 14%를 차지하며, 다른 클라이언트는 거의 사용되지 않습니다. 실행 계층 데이터는 2025년 10월 26일에 [supermajority.info (새 탭에서 열림)](https://supermajority.info/) 에서 가져왔습니다. 합의 클라이언트 데이터는 [Michael Sproul (새 탭에서 열림)](https://github.com/sigp/blockprint) 에서 가져왔습니다. 합의 레이어 클라이언트는 항상 식별하는 데 사용할 수 있는 명확한 흔적을 남기지 않기 때문에 합의 클라이언트 데이터를 얻는 것은 더 어렵습니다. 이 데이터는 때때로 일부 소수 클라이언트를 혼동하는 분류 알고리즘을 사용하여 생성되었습니다(자세한 내용은 [여기 (새 탭에서 열림)](https://twitter.com/sproulM_/status/1440512518242197516) 참조). 위 다이어그램에서 이러한 모호한 분류는 양자택일 레이블(예: 님버스/테쿠)로 처리됩니다. 그럼에도 불구하고 네트워크의 대다수가 프리즘을 실행하고 있다는 것은 분명합니다. 스냅샷에 불과하지만 다이어그램의 값은 현재 클라이언트 다양성 상태에 대한 좋은 전반적인 감각을 제공합니다. 합의 레이어에 대한 최신 클라이언트 다양성 데이터는 이제 [clientdiversity.org (새 탭에서 열림)](https://clientdiversity.org/) 에서 확인할 수 있습니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#execution-layer) 실행 계층 ----------------------------------------------------------------------------------------------------- 지금까지 클라이언트 다양성에 대한 논의는 주로 합의 레이어에 집중되었습니다. 하지만 실행 클라이언트인 [고 이더리움 (geth) (새 탭에서 열림)](https://geth.ethereum.org/) 가 현재 전체 노드의 약 85%를 차지하고 있습니다. 이 비율은 합의 클라이언트와 동일한 이유로 문제가 됩니다. 예를 들어, 트랜잭션 처리나 실행 페이로드 구성에 영향을 미치는 고 이더리움 (geth)의 버그는 합의 클라이언트가 문제가 있거나 버그가 있는 트랜잭션에 완결성을 부여하는 결과를 초래할 수 있습니다. 따라서 이더리움은 실행 클라이언트가 더 균등하게 분산될 때 더 건전해질 것이며, 이상적으로는 어떤 클라이언트도 네트워크의 33% 이상을 차지하지 않아야 합니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#use-minority-client) 소수 클라이언트 사용 --------------------------------------------------------------------------------------------------------------- 클라이언트 다양성 문제를 해결하려면 개별 사용자가 소수 클라이언트를 선택하는 것 이상이 필요합니다. 검증자 풀과 주요 탈중앙화 애플리케이션 (dapp) 및 거래소와 같은 기관도 클라이언트를 전환해야 합니다. 하지만 모든 사용자는 현재의 불균형을 바로잡고 사용 가능한 모든 이더리움 소프트웨어의 사용을 정상화하는 데 각자의 역할을 다할 수 있습니다. 머지 이후 모든 노드 운영자는 실행 클라이언트와 합의 클라이언트를 실행해야 합니다. 아래 제안된 클라이언트 조합을 선택하면 클라이언트 다양성을 높이는 데 도움이 됩니다. ### [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#execution-clients) 실행 클라이언트 * [베수 (새 탭에서 열림)](https://www.hyperledger.org/use/besu) * [네더마인드 (새 탭에서 열림)](https://downloads.nethermind.io/) * [에리곤 (새 탭에서 열림)](https://github.com/ledgerwatch/erigon) * [고 이더리움 (geth) (새 탭에서 열림)](https://geth.ethereum.org/) * [레스 (새 탭에서 열림)](https://reth.rs/) ### [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#consensus-clients) 합의 클라이언트 * [님버스 (새 탭에서 열림)](https://nimbus.team/) * [라이트하우스 (새 탭에서 열림)](https://github.com/sigp/lighthouse) * [테쿠 (새 탭에서 열림)](https://consensys.io/teku) * [로드스타 (새 탭에서 열림)](https://github.com/ChainSafe/lodestar) * [프리즘 (새 탭에서 열림)](https://prysm.offchainlabs.com/docs/) * [Grandine (새 탭에서 열림)](https://docs.grandine.io/) 기술 사용자는 소수 클라이언트를 위한 더 많은 튜토리얼과 문서를 작성하고 노드를 운영하는 동료들이 지배적인 클라이언트에서 마이그레이션하도록 장려함으로써 이 과정을 가속화하는 데 도움을 줄 수 있습니다. 소수 합의 클라이언트로 전환하기 위한 가이드는 [clientdiversity.org (새 탭에서 열림)](https://clientdiversity.org/) 에서 확인할 수 있습니다. [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#client-diversity-dashboards) 클라이언트 다양성 대시보드 -------------------------------------------------------------------------------------------------------------------------- 여러 대시보드에서 실행 계층 및 합의 레이어에 대한 실시간 클라이언트 다양성 통계를 제공합니다. **합의 레이어:** * [Rated.network (새 탭에서 열림)](https://www.rated.network/) * [clientdiversity.org (새 탭에서 열림)](https://clientdiversity.org/) **실행 계층:** * [supermajority.info (새 탭에서 열림)](https://supermajority.info//) * [Ethernodes (새 탭에서 열림)](https://ethernodes.org/) [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#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) – _Dankrad Fiest, 2022년 3월 24일_ * [클라이언트 다양성의 중요성 (새 탭에서 열림)](https://our.status.im/the-importance-of-client-diversity/) * [이더리움 노드 서비스 목록 (새 탭에서 열림)](https://ethereumnodes.com/) * [클라이언트 다양성 문제의 "5가지 이유(Five Whys)" (새 탭에서 열림)](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08) * [이더리움 다양성과 해결 방법 (유튜브) (새 탭에서 열림)](https://www.youtube.com/watch?v=1hZgCaiqwfU) * [clientdiversity.org (새 탭에서 열림)](https://clientdiversity.org/) [](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/#related-topics) 관련 주제 ---------------------------------------------------------------------------------------------------- * [이더리움 노드 실행하기](https://ethereum.org/ko/run-a-node/) * [노드와 클라이언트](https://ethereum.org/ko/developers/docs/nodes-and-clients/) --- # Uthibitisho wa Dau (PoS) | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#main-content) Change page Uthibitisho wa Dau (PoS) ======================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/consensus-mechanisms/pos/index.md) Kwenye ukurasa huu Uthibitisho wa Dau (PoS) ndio msingi wa [utaratibu wa makubaliano](https://ethereum.org/sw/developers/docs/consensus-mechanisms/) wa Ethereum. Ethereum iliwasha utaratibu wake wa uthibitisho wa dau mnamo 2022 kwa sababu ni salama zaidi, unatumia nishati kidogo, na ni bora kwa kutekeleza suluhisho mpya za kuongeza viwango ikilinganishwa na usanifu wa awali wa [Uthibitisho wa Kazi (PoW)](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pow/) . [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#prerequisites) Mahitaji ya awali ----------------------------------------------------------------------------------------------------- Ili kuelewa vyema ukurasa huu, tunapendekeza usome kwanza kuhusu [taratibu za makubaliano](https://ethereum.org/sw/developers/docs/consensus-mechanisms/) . [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#what-is-pos) Uthibitisho wa Dau (PoS) ni nini? ------------------------------------------------------------------------------------------------------------------- Uthibitisho wa dau ni njia ya kuthibitisha kwamba mathibitishaji wameweka kitu cha thamani kwenye mtandao ambacho kinaweza kuharibiwa ikiwa watatenda kwa udanganyifu. Katika uthibitisho wa dau wa [Ethereum](https://ethereum.org/sw/) , mathibitishaji huweka dhamana ya mtaji waziwazi kwa njia ya ETH kwenye mkataba mahiri kwenye Ethereum. Mthibitishaji kisha anawajibika kuangalia kwamba vitalu vipya vinavyosambazwa kwenye mtandao ni halali na mara kwa mara kuunda na kusambaza vitalu vipya wenyewe. Wakijaribu kulaghai mtandao (kwa mfano kwa kupendekeza vitalu vingi wakati wanapaswa kutuma kimoja au kutuma uthibitisho unaokinzana), baadhi au ETH yao yote iliyowekwa dhamana inaweza kuharibiwa. [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#validators) Mathibitishaji ----------------------------------------------------------------------------------------------- Ili kushiriki kama mthibitishaji, mtumiaji lazima aweke amana ya 32 ETH kwenye mkataba wa amana na kuendesha programu tatu tofauti: kiteja cha utekelezaji, mteja wa mwafaka, na kiteja cha mthibitishaji. Baada ya kuweka ETH yao, mtumiaji hujiunga na foleni ya uanzishaji ambayo inazuia kiwango cha mathibitishaji wapya kujiunga na mtandao. Baada ya kuanzishwa, mathibitishaji hupokea vitalu vipya kutoka kwa wenzao kwenye mtandao wa Ethereum. Miamala iliyowasilishwa kwenye kitalu inatekelezwa tena ili kuangalia kwamba mabadiliko yaliyopendekezwa kwenye hali ya Ethereum ni halali, na sahihi ya kitalu inakaguliwa. Mthibitishaji kisha hutuma kura (inayoitwa uthibitisho) kuunga mkono kitalu hicho kwenye mtandao. Wakati chini ya uthibitisho wa kazi, muda wa vitalu huamuliwa na ugumu wa uchimbaji, katika uthibitisho wa dau, kasi imepangwa. Muda katika Ethereum ya uthibitisho wa dau umegawanywa katika sloti (sekunde 12) na vipindi (sloti 32). Mthibitishaji mmoja huchaguliwa kwa nasibu kuwa mpendekezaji wa bloku katika kila sloti. Mthibitishaji huyu anawajibika kuunda kitalu kipya na kukituma kwa nodi zingine kwenye mtandao. Pia katika kila sloti, kamati ya mathibitishaji huchaguliwa kwa nasibu, ambao kura zao hutumiwa kuamua uhalali wa kitalu kinachopendekezwa. Kugawanya kundi la mathibitishaji katika kamati ni muhimu kwa kuweka mzigo wa mtandao katika kiwango kinachoweza kudhibitiwa. Kamati hugawanya kundi la mathibitishaji ili kila mthibitishaji anayefanya kazi atoe uthibitisho katika kila kipindi, lakini si katika kila sloti. [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) Jinsi Muamala Unavyotekelezwa katika PoS ya Ethereum ------------------------------------------------------------------------------------------------------------------------------------------------------------- Yafuatayo yanatoa maelezo ya mwanzo hadi mwisho ya jinsi muamala unavyotekelezwa katika uthibitisho wa dau wa Ethereum. 1. Mtumiaji huunda na kutia sahihi [muamala](https://ethereum.org/sw/developers/docs/transactions/) kwa ufunguo wa siri wao. Hili kwa kawaida hushughulikiwa na mkoba au maktaba kama vile [Ethers.js (inafunguka katika kichupo kipya)](https://docs.ethers.org/v6/) , [web3js (inafunguka katika kichupo kipya)](https://docs.web3js.org/) , [web3py (inafunguka katika kichupo kipya)](https://web3py.readthedocs.io/en/v5/) n.k. lakini kiufundi mtumiaji anafanya ombi kwa nodi akitumia [JSON-RPC API](https://ethereum.org/sw/developers/docs/apis/json-rpc/) ya Ethereum. Mtumiaji hufafanua kiasi cha gesi ambacho yuko tayari kulipa kama ada ya kipaumbele kwa mthibitishaji ili kuwahimiza kujumuisha muamala kwenye kitalu. [Ada za kipaumbele](https://ethereum.org/sw/developers/docs/gas/#priority-fee) hulipwa kwa mthibitishaji huku [ada ya msingi](https://ethereum.org/sw/developers/docs/gas/#base-fee) ikichomwa. 2. Muamala unawasilishwa kwa [kiteja cha utekelezaji](https://ethereum.org/sw/developers/docs/nodes-and-clients/#execution-client) cha Ethereum ambacho huthibitisha uhalali wake. Hii inamaanisha kuhakikisha kuwa mtumaji ana ETH ya kutosha kutimiza muamala na ametia sahihi kwa ufunguo sahihi. 3. Ikiwa muamala ni halali, kiteja cha utekelezaji huongeza kwenye mempool yake ya ndani (orodha ya miamala inayosubiri) na pia kuisambaza kwa nodi zingine kupitia mtandao wa uvumi wa tabaka la utekelezaji. Nodi zingine zinaposikia kuhusu muamala huo, zinauongeza kwenye mempool yao ya ndani pia. Watumiaji wa hali ya juu wanaweza kujizuia kusambaza muamala wao na badala yake kuupeleka kwa wajenzi maalum wa vitalu kama vile [Flashbots Auction (inafunguka katika kichupo kipya)](https://docs.flashbots.net/flashbots-auction/overview) . Hii inawaruhusu kupanga miamala katika vitalu vijavyo kwa faida kubwa zaidi ([MEV](https://ethereum.org/sw/developers/docs/mev/#mev-extraction) ). 4. Moja ya nodi za mthibitishaji kwenye mtandao ni mpendekezaji wa bloku kwa sloti ya sasa, akiwa amechaguliwa hapo awali kwa nasibu akitumia RANDAO. Nodi hii inawajibika kujenga na kusambaza kitalu kijacho kitakachoongezwa kwenye mnyororo wa vitalu wa Ethereum na kusasisha hali ya kimataifa. Nodi inaundwa na sehemu tatu: kiteja cha utekelezaji, mteja wa mwafaka na kiteja cha mthibitishaji. Kiteja cha utekelezaji hukusanya miamala kutoka kwenye mempool ya ndani kuwa "mzigo wa utekelezaji" na kuitekeleza ndani ili kuzalisha mabadiliko ya hali. Taarifa hii hupitishwa kwa mteja wa mwafaka ambapo mzigo wa utekelezaji hufungwa kama sehemu ya "kitalu cha kinara" ambacho pia kina taarifa kuhusu zawadi, adhabu, ukataji, uthibitisho n.k. zinazowezesha mtandao kukubaliana juu ya mfuatano wa vitalu kwenye kichwa cha mnyororo. Mawasiliano kati ya wateja wa utekelezaji na mwafaka yameelezwa kwa kina zaidi katika [Kuunganisha Wateja wa Mwafaka na Utekelezaji](https://ethereum.org/sw/developers/docs/networking-layer/#connecting-clients) . 5. Nodi zingine hupokea kitalu cha kinara kipya kwenye mtandao wa uvumi wa tabaka la mwafaka. Wanapitisha kwa kiteja chao cha utekelezaji ambapo miamala inatekelezwa tena ndani ili kuhakikisha mabadiliko ya hali yaliyopendekezwa ni halali. Kiteja cha mthibitishaji kisha kinathibitisha kwamba kitalu ni halali na ni kitalu kinachofuata kimantiki katika mtazamo wao wa mnyororo (ikimaanisha kinajengwa kwenye mnyororo wenye uzito mkubwa zaidi wa uthibitisho kama ilivyofafanuliwa katika [sheria za uchaguzi wa mchepuo](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#fork-choice) ). Kitalu kinaongezwa kwenye hifadhidata ya ndani katika kila nodi inayokithibitisha. 6. Muamala unaweza kuchukuliwa kuwa "uliokamilishwa" ikiwa umekuwa sehemu ya mnyororo wenye "kiungo cha wingi mkuu" kati ya vituo viwili vya ukaguzi. Vituo vya ukaguzi hutokea mwanzoni mwa kila kipindi na vipo ili kuzingatia ukweli kwamba ni kikundi kidogo tu cha mathibitishaji wanaofanya kazi hutoa uthibitisho katika kila sloti, lakini mathibitishaji wote wanaofanya kazi hutoa uthibitisho katika kila kipindi. Kwa hivyo, ni kati ya vipindi tu ambapo 'kiungo cha wingi mkuu' kinaweza kuonyeshwa (hapa ndipo 66% ya jumla ya ETH iliyowekwa dhamana kwenye mtandao inakubaliana juu ya vituo viwili vya ukaguzi). Maelezo zaidi kuhusu ukamilifu yanaweza kupatikana hapa chini. [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#finality) Ukamilifu ---------------------------------------------------------------------------------------- Muamala una "ukamilifu" katika mitandao iliyosambazwa unapokuwa sehemu ya kitalu ambacho hakiwezi kubadilika bila kiasi kikubwa cha ETH kuchomwa. Kwenye Ethereum ya uthibitisho wa dau, hili linasimamiwa kwa kutumia vitalu vya "kituo cha ukaguzi". Kitalu cha kwanza katika kila kipindi ni kituo cha ukaguzi. Mathibitishaji hupiga kura kwa jozi za vituo vya ukaguzi wanavyoona kuwa halali. Ikiwa jozi ya vituo vya ukaguzi inavutia kura zinazowakilisha angalau theluthi mbili ya jumla ya ETH iliyowekwa dhamana, vituo vya ukaguzi vinaboreshwa. Kile cha hivi karibuni zaidi kati ya hivyo viwili (lengo) kinakuwa "iliyohalalishwa". Kile cha awali kati ya hivyo viwili tayari kimehalalishwa kwa sababu kilikuwa "lengo" katika kipindi kilichopita. Sasa kinaboreshwa kuwa "kiliokamilishwa". Mchakato huu wa kuboresha vituo vya ukaguzi unashughulikiwa na **[Casper the Friendly Finality Gadget (Casper FFG) (inafunguka katika kichupo kipya)](https://arxiv.org/pdf/1710.09437) **. Casper FFG ni zana ya ukamilifu wa kitalu kwa ajili ya mwafaka. Pindi kitalu kinapokamilishwa, hakiwezi kutenguliwa au kubadilishwa bila ukataji wa wengi wa waweka dhamana, na kuifanya isiwezekane kiuchumi. Ili kutengua kitalu kiliokamilishwa, mshambuliaji angejitolea kupoteza angalau theluthi moja ya jumla ya usambazaji wa ETH iliyowekwa dhamana. Sababu hasa ya hili imeelezwa katika [chapisho hili la blogu la Taasisi ya Ethereum (inafunguka katika kichupo kipya)](https://blog.ethereum.org/2016/05/09/on-settlement-finality) . Kwa kuwa ukamilifu unahitaji wingi wa theluthi mbili, mshambuliaji angeweza kuzuia mtandao kufikia ukamilifu kwa kupiga kura na theluthi moja ya jumla ya dhamana. Kuna utaratibu wa kujilinda dhidi ya hili: [uvujaji wa kutotenda (inafunguka katika kichupo kipya)](https://eth2book.info/bellatrix/part2/incentives/inactivity) . Hii huanzishwa wakati wowote mnyororo unaposhindwa kukamilika kwa zaidi ya vipindi vinne. Uvujaji wa kutotenda unavujisha ETH iliyowekwa dhamana kutoka kwa mathibitishaji wanaopiga kura dhidi ya wengi, na kuruhusu wengi kupata tena wingi wa theluthi mbili na kukamilisha mnyororo. [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#crypto-economic-security) Usalama wa kiuchumi wa kripto ---------------------------------------------------------------------------------------------------------------------------- Kuendesha mthibitishaji ni ufungumanisho. Mthibitishaji anatarajiwa kudumisha maunzi na muunganisho wa kutosha ili kushiriki katika uthibitishaji wa kitalu na pendekezo. Kwa malipo, mthibitishaji analipwa kwa ETH (salio lao lililowekwa dhamana linaongezeka). Kwa upande mwingine, kushiriki kama mthibitishaji pia hufungua njia mpya kwa watumiaji kushambulia mtandao kwa faida ya kibinafsi au hujuma. Ili kuzuia hili, mathibitishaji hukosa zawadi za ETH ikiwa watashindwa kushiriki wanapoitwa, na dhamana yao iliyopo inaweza kuharibiwa ikiwa watatenda kwa udanganyifu. Tabia mbili za msingi zinaweza kuchukuliwa kuwa za udanganyifu: kupendekeza vitalu vingi katika sloti moja (kudanganya) na kuwasilisha uthibitisho unaokinzana. Kiasi cha ETH kinachokatwa kinategemea ni mathibitishaji wangapi pia wanakatwa kwa wakati mmoja. Hii inajulikana kama ["adhabu ya uwiano" (inafunguka katika kichupo kipya)](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty) , na inaweza kuwa ndogo (~1% ya dhamana kwa mthibitishaji mmoja aliyekatwa peke yake) au inaweza kusababisha 100% ya dhamana ya mthibitishaji kuharibiwa (tukio la ukataji wa watu wengi). Inawekwa katikati ya kipindi cha kujitoa kwa lazima ambacho huanza na adhabu ya haraka (hadi 1 ETH) Siku ya 1, adhabu ya uwiano Siku ya 18, na hatimaye, kutolewa kwenye mtandao Siku ya 36. Wanapokea adhabu ndogo za uthibitisho kila siku kwa sababu wapo kwenye mtandao lakini hawawasilishi kura. Haya yote yanamaanisha shambulio lililoratibiwa lingekuwa la gharama kubwa sana kwa mshambuliaji. [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#fork-choice) Uchaguzi wa mchepuo ----------------------------------------------------------------------------------------------------- Wakati mtandao unafanya kazi kikamilifu na kwa uaminifu, kuna kitalu kipya kimoja tu kwenye kichwa cha mnyororo, na mathibitishaji wote wanakithibitisha. Hata hivyo, inawezekana kwa mathibitishaji kuwa na mitazamo tofauti ya kichwa cha mnyororo kutokana na ucheleweshaji wa mtandao au kwa sababu mpendekezaji wa bloku amedanganya. Kwa hivyo, wateja wa mwafaka wanahitaji algoriti ili kuamua ni ipi ya kupendelea. Algoriti inayotumika katika uthibitisho wa dau wa Ethereum inaitwa [LMD-GHOST (inafunguka katika kichupo kipya)](https://arxiv.org/pdf/2003.03052.pdf) , na inafanya kazi kwa kutambua mchepuo ambao una uzito mkubwa zaidi wa uthibitisho katika historia yake. [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#pos-and-security) Uthibitisho wa dau na usalama -------------------------------------------------------------------------------------------------------------------- Tishio la [shambulio la asilimia 51 (inafunguka katika kichupo kipya)](https://www.investopedia.com/terms/1/51-attack.asp) bado lipo kwenye uthibitisho wa dau kama lilivyo kwenye uthibitisho wa kazi, lakini ni hatari zaidi kwa washambuliaji. Mshambuliaji angehitaji 51% ya ETH iliyowekwa dhamana. Wangeweza kisha kutumia uthibitisho wao wenyewe kuhakikisha mchepuo wanaoupendelea ndio uliokuwa na uthibitisho mwingi uliokusanywa. 'Uzito' wa uthibitisho uliokusanywa ndio wateja wa mwafaka hutumia kuamua mnyororo sahihi, kwa hivyo mshambuliaji huyu angeweza kufanya mchepuo wao kuwa ule unaokubalika. Hata hivyo, nguvu ya uthibitisho wa dau juu ya uthibitisho wa kazi ni kwamba jamii ina unyumbufu katika kuanzisha shambulio la kupinga. Kwa mfano, mathibitishaji waaminifu wangeweza kuamua kuendelea kujenga kwenye mnyororo wa wachache na kupuuza mchepuo wa mshambuliaji huku wakiwahimiza programu, mabadilishano, na mabwawa kufanya vivyo hivyo. Wangeweza pia kuamua kumuondoa mshambuliaji kwa nguvu kwenye mtandao na kuharibu ETH yao iliyowekwa dhamana. Hizi ni ngome imara za kiuchumi dhidi ya shambulio la asilimia 51. Zaidi ya mashambulio ya asilimia 51, watendaji wabaya wanaweza pia kujaribu aina zingine za shughuli mbaya, kama vile: * mashambulio ya masafa marefu (ingawa zana ya ukamilifu inabatilisha vekta hii ya shambulio) * 'reorgs' za masafa mafupi (ingawa uimarishaji wa mpendekezaji na tarehe za mwisho za uthibitisho hupunguza hili) * mashambulio ya kudunda na kusawazisha (pia hupunguzwa na uimarishaji wa mpendekezaji, na mashambulio haya hata hivyo yameonyeshwa tu chini ya hali bora za mtandao) * mashambulio ya maporomoko (yanabatilishwa na sheria ya algoriti za uchaguzi wa mchepuo ya kuzingatia tu ujumbe wa hivi punde) Kwa ujumla, uthibitisho wa dau, kama unavyotekelezwa kwenye Ethereum, umeonyeshwa kuwa salama zaidi kiuchumi kuliko uthibitisho wa kazi. [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#pros-and-cons) Faida na hasara --------------------------------------------------------------------------------------------------- | Faida | Hasara | | --- | --- | | Uweka dhamana hurahisisha watu binafsi kushiriki katika kulinda mtandao, na kukuza ugatuzi. Nodi ya mthibitishaji inaweza kuendeshwa kwenye kompyuta mpakato ya kawaida. Mabwawa ya uwekaji dhamana huruhusu watumiaji kuweka dhamana bila kuwa na 32 ETH. | Uthibitisho wa dau ni mchanga na haujajaribiwa sana vitani ikilinganishwa na uthibitisho wa kazi | | Uwekaji dhamana umepewa ugatuzi zaidi. Uchumi wa kiwango hautumiki kwa njia sawa na unavyofanya kwa uchimbaji wa PoW. | Uthibitisho wa dau ni mgumu zaidi kutekeleza kuliko uthibitisho wa kazi | | Uthibitisho wa dau hutoa usalama mkubwa zaidi wa kiuchumi wa kripto kuliko uthibitisho wa kazi | Watumiaji wanahitaji kuendesha programu tatu ili kushiriki katika uthibitisho wa dau wa Ethereum. | | Utoaji mdogo wa ETH mpya unahitajika ili kuwahamasisha washiriki wa mtandao | | ### [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#comparison-to-proof-of-work) Ulinganisho na uthibitisho wa kazi Ethereum awali ilitumia uthibitisho wa kazi lakini ilibadilika na kuwa uthibitisho wa dau mnamo Septemba 2022. PoS inatoa faida kadhaa juu ya PoW, kama vile: * ufanisi bora wa nishati – hakuna haja ya kutumia nishati nyingi kwenye hesabu za uthibitisho wa kazi * vizuizi vya chini vya kuingia, mahitaji yaliyopunguzwa ya maunzi – hakuna haja ya maunzi ya hali ya juu ili kupata nafasi ya kuunda vitalu vipya * hatari iliyopunguzwa ya uwekaji kati – uthibitisho wa dau unapaswa kusababisha nodi nyingi zaidi kulinda mtandao * kwa sababu ya hitaji dogo la nishati utoaji mdogo wa ETH unahitajika ili kuhamasisha ushiriki * adhabu za kiuchumi kwa tabia mbaya hufanya mashambulio ya mtindo wa asilimia 51 kuwa ya gharama kubwa zaidi kwa mshambuliaji ikilinganishwa na uthibitisho wa kazi * jamii inaweza kukimbilia urejeshaji wa kijamii wa mnyororo wa uaminifu ikiwa shambulio la asilimia 51 lingeshinda ngome za kiuchumi za kripto. [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#further-reading) Kusoma zaidi -------------------------------------------------------------------------------------------------- * [Maswali Yanayoulizwa Mara kwa Mara kuhusu Uthibitisho wa Dau (inafunguka katika kichupo kipya)](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_ * [Uthibitisho wa Dau ni Nini (inafunguka katika kichupo kipya)](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ * [Uthibitisho wa Dau ni Nini na Kwa Nini ni Muhimu (inafunguka katika kichupo kipya)](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_ * [Kwa Nini Uthibitisho wa Dau (Nov 2020) (inafunguka katika kichupo kipya)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_ * [Uthibitisho wa Dau: Jinsi Nilivyojifunza Kupenda Udhanifu Dhaifu (inafunguka katika kichupo kipya)](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity) _Vitalik Buterin_ * [Shambulio na ulinzi wa Ethereum ya uthibitisho wa dau (inafunguka katika kichupo kipya)](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) * [Falsafa ya Usanifu wa Uthibitisho wa Dau (inafunguka katika kichupo kipya)](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_ * [Video: Vitalik Buterin anaelezea uthibitisho wa dau kwa Lex Fridman (inafunguka katika kichupo kipya)](https://www.youtube.com/watch?v=3yrqBG-7EVE) [](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pos/#related-topics) Mada zinazohusiana ------------------------------------------------------------------------------------------------------- * [Uthibitisho wa kazi](https://ethereum.org/sw/developers/docs/consensus-mechanisms/pow/) * [Uthibitisho wa mamlaka (PoA)](https://ethereum.org/sw/developers/docs/consensus-mechanisms/poa/) --- # 작업증명 (PoW) | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#main-content) Change page 작업증명 (PoW) ========== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/consensus-mechanisms/pow/index.md) 이 페이지의 내용 [이더리움](https://ethereum.org/ko/) 네트워크는 **[작업증명 (PoW)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/) **이 포함된 합의 메커니즘을 사용하는 것으로 시작되었습니다. 이를 통해 이더리움 네트워크의 노드들은 이더리움 블록체인에 기록된 모든 정보의 상태에 대해 합의할 수 있었고, 특정 종류의 경제적 공격을 방지할 수 있었습니다. 하지만 이더리움은 2022년에 작업증명 (PoW)을 종료하고 대신 [지분 증명 (PoS)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/) 을 사용하기 시작했습니다. 작업증명 (PoW)은 이제 더 이상 사용되지 않습니다. 이더리움은 더 이상 합의 메커니즘의 일부로 작업증명 (PoW)을 사용하지 않습니다. 대신 지분 증명 (PoS)을 사용합니다. [지분 증명 (PoS)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/) 및 [스테이킹](https://ethereum.org/ko/staking/) 에 대해 자세히 알아보세요. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#prerequisites) 전제 조건 ----------------------------------------------------------------------------------------- 이 페이지를 더 잘 이해하려면 먼저 [트랜잭션](https://ethereum.org/ko/developers/docs/transactions/) , [블록](https://ethereum.org/ko/developers/docs/blocks/) 및 [합의 메커니즘](https://ethereum.org/ko/developers/docs/consensus-mechanisms/) 에 대해 읽어보는 것을 권장합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#what-is-pow) 작업증명 (PoW)이란 무엇인가요? ----------------------------------------------------------------------------------------------------- 작업증명 (PoW)을 활용하는 나카모토 합의(Nakamoto consensus)는 과거 탈중앙화된 이더리움 네트워크가 계정 잔액이나 트랜잭션 순서와 같은 사항에 대해 합의(즉, 모든 노드가 동의함)에 도달할 수 있게 해준 메커니즘입니다. 이는 사용자가 코인을 "이중 지불"하는 것을 방지하고 이더리움 체인을 공격하거나 조작하는 것을 엄청나게 어렵게 만들었습니다. 이러한 보안 속성은 이제 [Gasper](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/gasper/) 라는 합의 메커니즘을 사용하는 지분 증명 (PoS)에서 제공됩니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#pow-and-mining) 작업증명 (PoW)과 채굴 --------------------------------------------------------------------------------------------------- 작업증명 (PoW)은 작업증명 (PoW) 블록체인에서 채굴자가 수행하는 작업에 대한 난이도와 규칙을 설정하는 기본 알고리즘입니다. 채굴은 "작업" 그 자체입니다. 이는 체인에 유효한 블록을 추가하는 행위입니다. 체인의 길이는 네트워크가 블록체인의 올바른 포크를 따르도록 돕기 때문에 중요합니다. 더 많은 "작업"이 수행될수록 체인이 길어지고 블록 번호가 높아지며, 네트워크는 현재 상태에 대해 더 확신할 수 있습니다. [채굴에 대해 더 알아보기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#how-it-works) 이더리움의 작업증명 (PoW)은 어떻게 작동했나요? --------------------------------------------------------------------------------------------------------------- 이더리움 트랜잭션은 블록으로 처리됩니다. 이제는 더 이상 사용되지 않는 작업증명 (PoW) 이더리움에서 각 블록에는 다음이 포함되었습니다. * 블록 난이도 – 예: 3,324,092,183,262,715 * mixHash – 예: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` * 논스 – 예: `0xd3ee432b4fb3d26b` 이 블록 데이터는 작업증명 (PoW)과 직접적인 관련이 있었습니다. ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#the-work) 작업증명 (PoW)에서의 작업 작업증명 (PoW) 프로토콜인 이더해시는 채굴자가 블록의 논스를 찾기 위해 치열한 시행착오 경쟁을 거치도록 요구했습니다. 유효한 논스가 있는 블록만 체인에 추가될 수 있었습니다. 블록을 생성하기 위해 경쟁할 때, 채굴자는 (채굴자가 하는 것처럼) 전체 체인을 다운로드하고 실행해야만 얻을 수 있는 데이터 세트를 수학적 함수에 반복적으로 입력했습니다. 이 데이터 세트는 블록 난이도에 의해 결정되는 목표값보다 낮은 mixHash를 생성하는 데 사용되었습니다. 이를 수행하는 가장 좋은 방법은 시행착오를 거치는 것입니다. 난이도는 해시의 목표값을 결정했습니다. 목표값이 낮을수록 유효한 해시의 집합이 작아집니다. 일단 생성되면 다른 채굴자와 클라이언트가 이를 검증하는 것은 매우 쉬웠습니다. 단 하나의 트랜잭션이라도 변경되면 해시가 완전히 달라져 사기임을 알릴 수 있었습니다. 해싱은 사기를 쉽게 발견할 수 있게 해줍니다. 하지만 프로세스로서의 작업증명 (PoW)은 체인 공격을 억제하는 큰 역할도 했습니다. ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#security) 작업증명 (PoW)과 보안 채굴자들은 메인 이더리움 체인에서 이 작업을 수행하도록 인센티브를 받았습니다. 일부 채굴자들이 자신만의 체인을 시작할 유인은 거의 없었습니다. 이는 시스템을 훼손하기 때문입니다. 블록체인은 단일 상태를 진실의 원천으로 삼는 것에 의존합니다. 작업증명 (PoW)의 목적은 체인을 연장하는 것이었습니다. 가장 긴 체인은 이를 생성하는 데 가장 많은 연산 작업이 수행되었기 때문에 유효한 체인으로 가장 신뢰할 수 있었습니다. 이더리움의 PoW 시스템 내에서는 트랜잭션을 지우거나 가짜 트랜잭션을 생성하거나 두 번째 체인을 유지하는 새로운 블록을 생성하는 것이 거의 불가능했습니다. 악의적인 채굴자가 항상 다른 모든 사람보다 블록 논스를 더 빨리 해결해야 했기 때문입니다. 악의적이면서도 유효한 블록을 지속적으로 생성하려면, 악의적인 채굴자가 다른 모든 사람을 이기기 위해 네트워크 채굴 능력의 51% 이상을 확보해야 했습니다. 그 정도의 "작업"에는 값비싼 컴퓨팅 파워가 많이 필요하며, 소비된 에너지가 공격으로 얻은 이득보다 더 컸을 수도 있습니다. ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#economics) 작업증명 (PoW) 경제학 작업증명 (PoW)은 또한 시스템에 새로운 통화를 발행하고 채굴자가 작업을 수행하도록 인센티브를 제공하는 역할도 담당했습니다. [콘스탄티노플 업그레이드](https://ethereum.org/ko/ethereum-forks/#constantinople) 이후, 블록을 성공적으로 생성한 채굴자는 새로 발행된 2 ETH와 트랜잭션 수수료의 일부를 보상으로 받았습니다. 엉클(Ommer) 블록도 1.75 ETH를 보상받았습니다. 엉클 블록은 한 채굴자가 다른 채굴자가 정규(canonical) 블록을 생성하는 것과 거의 동시에 생성한 유효한 블록으로, 궁극적으로 어느 체인이 먼저 구축되었는지에 따라 결정되었습니다. 엉클 블록은 주로 네트워크 지연으로 인해 발생했습니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#finality) 완결성 ---------------------------------------------------------------------------------- 트랜잭션이 변경될 수 없는 블록의 일부가 될 때 이더리움에서 "완결성"을 갖습니다. 채굴자들은 탈중앙화된 방식으로 작업했기 때문에 두 개의 유효한 블록이 동시에 채굴될 수 있었습니다. 이로 인해 일시적인 포크가 생성됩니다. 결국 후속 블록이 채굴되어 추가되면서 이 체인 중 하나가 더 길어지고 승인된 체인이 되었습니다. 상황을 더 복잡하게 만드는 것은, 임시 포크에서 거부된 트랜잭션이 승인된 체인에 포함되지 않았을 수도 있다는 점입니다. 이는 트랜잭션이 되돌려질 수 있음을 의미합니다. 따라서 완결성이란 트랜잭션을 되돌릴 수 없다고 간주하기 전에 기다려야 하는 시간을 의미합니다. 이전의 작업증명 (PoW) 이더리움에서는 특정 블록 `N` 위에 더 많은 블록이 채굴될수록 `N`의 트랜잭션이 성공적이었고 되돌려지지 않을 것이라는 확신이 높아졌습니다. 이제 지분 증명 (PoS)에서는 완결성이 블록의 확률적 속성이 아닌 명시적 속성이 되었습니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#energy) 작업증명 (PoW) 에너지 사용량 ----------------------------------------------------------------------------------------------- 작업증명 (PoW)에 대한 주요 비판은 네트워크를 안전하게 유지하는 데 필요한 에너지 출력량입니다. 보안과 탈중앙화를 유지하기 위해 작업증명 (PoW) 기반의 이더리움은 막대한 양의 에너지를 소비했습니다. 지분 증명 (PoS)으로 전환하기 직전, 이더리움 채굴자들은 집단적으로 연간 약 70 TWh를 소비하고 있었습니다(2022년 7월 18일 [digiconomist (새 탭에서 열림)](https://digiconomist.net/) 에 따르면 체코 공화국과 비슷한 수준). [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#pros-and-cons) 장단점 --------------------------------------------------------------------------------------- | 장점 | 단점 | | --- | --- | | 작업증명 (PoW)은 중립적입니다. 시작하는 데 ETH가 필요하지 않으며 블록 보상을 통해 0 ETH에서 양수 잔액으로 늘릴 수 있습니다. [지분 증명 (PoS)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/)
의 경우 시작하려면 ETH가 필요합니다. | 작업증명 (PoW)은 에너지를 너무 많이 소비하여 환경에 악영향을 미칩니다. | | 작업증명 (PoW)은 수년 동안 비트코인과 이더리움을 안전하고 탈중앙화된 상태로 유지해 온 검증된 합의 메커니즘입니다. | 채굴을 하려면 특수 장비가 필요하므로 시작하는 데 큰 투자가 필요합니다. | | 지분 증명 (PoS)에 비해 구현하기가 비교적 쉽습니다. | 필요한 연산량이 증가함에 따라 마이닝 풀이 채굴 게임을 지배할 가능성이 있으며, 이는 중앙화 및 보안 위험으로 이어질 수 있습니다. | [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#compared-to-pos) 지분 증명 (PoS)과의 비교 ------------------------------------------------------------------------------------------------------ 큰 틀에서 볼 때, 지분 증명 (PoS)은 작업증명 (PoW)과 동일한 최종 목표를 가지고 있습니다. 즉, 탈중앙화된 네트워크가 안전하게 합의에 도달하도록 돕는 것입니다. 하지만 프로세스와 참여자 측면에서 몇 가지 차이점이 있습니다: * 지분 증명 (PoS)은 컴퓨팅 파워의 중요성을 스테이킹된 ETH로 대체합니다. * 지분 증명 (PoS)은 채굴자를 검증자로 대체합니다. 검증자는 새로운 블록을 생성하는 기능을 활성화하기 위해 자신의 ETH를 스테이킹합니다. * 검증자는 블록을 생성하기 위해 경쟁하지 않으며, 대신 알고리즘에 의해 무작위로 선택됩니다. * 완결성이 더 명확해집니다. 특정 체크포인트에서 검증자의 2/3가 블록 상태에 동의하면 최종적인 것으로 간주됩니다. 검증자는 이에 대해 자신의 전체 스테이크를 걸어야 하므로, 나중에 담합을 시도하면 전체 스테이크를 잃게 됩니다. [지분 증명 (PoS)에 대해 더 알아보기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#visual-learner) 시각적인 학습을 선호하시나요? ----------------------------------------------------------------------------------------------------- ### What is proof of work? A beginner-friendly explanation of the proof of work (PoW) consensus mechanism, including how miners solve cryptographic puzzles to validate transactions and secure the blockchain network. [대본과 함께 시청하기](https://ethereum.org/ko/videos/proof-of-work-explained/)   [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#further-reading) 더 읽어보기 -------------------------------------------------------------------------------------------- * [다수결 공격(Majority attack) (새 탭에서 열림)](https://en.bitcoin.it/wiki/Majority_attack) * [정산 완결성에 대하여 (새 탭에서 열림)](https://blog.ethereum.org/2016/05/09/on-settlement-finality) ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#videos) 비디오 * [작업증명 프로토콜에 대한 기술적 설명 (새 탭에서 열림)](https://youtu.be/9V1bipPkCTU) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/#related-topics) 관련 주제 ------------------------------------------------------------------------------------------ * [채굴](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/) * [지분 증명 (PoS)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/) * [권위 증명(PoA)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/poa/) --- # 스마트 컨트랙트 검증 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/smart-contracts/verifying/#main-content) Change page 스마트 컨트랙트 검증 =========== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/verifying/index.md) 이 페이지의 내용 [스마트 컨트랙트](https://ethereum.org/ko/developers/docs/smart-contracts/) 는 "무신뢰"를 바탕으로 설계되었습니다. 즉, 사용자가 컨트랙트와 상호작용하기 전에 제3자(예: 개발자 및 기업)를 신뢰할 필요가 없어야 합니다. 무신뢰성을 위한 필수 조건으로, 사용자와 다른 개발자는 스마트 컨트랙트의 소스 코드를 검증할 수 있어야 합니다. 소스 코드 검증은 게시된 컨트랙트 코드가 이더리움 블록체인의 컨트랙트 주소에서 실행되는 코드와 동일하다는 것을 사용자와 개발자에게 보장합니다. "소스 코드 검증"과 "[정형 검증](https://ethereum.org/ko/developers/docs/smart-contracts/formal-verification/) "을 구분하는 것이 중요합니다. 아래에서 자세히 설명할 소스 코드 검증은 고급 언어(예: Solidity)로 작성된 스마트 컨트랙트의 주어진 소스 코드가 컨트랙트 주소에서 실행될 동일한 바이트코드로 컴파일링되는지 확인하는 것을 의미합니다. 반면, 정형 검증은 스마트 컨트랙트의 정확성을 검증하는 것, 즉 컨트랙트가 예상대로 작동하는지 확인하는 것을 설명합니다. 문맥에 따라 다르지만, 컨트랙트 검증은 일반적으로 소스 코드 검증을 의미합니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/verifying/#what-is-source-code-verification) 소스 코드 검증이란 무엇인가요? ------------------------------------------------------------------------------------------------------------------------- [이더리움 가상 머신(EVM)](https://ethereum.org/ko/developers/docs/evm/) 에 스마트 컨트랙트를 배포하기 전에, 개발자는 컨트랙트의 소스 코드(즉, [Solidity](https://ethereum.org/ko/developers/docs/smart-contracts/languages/) 나 다른 고급 프로그래밍 언어로 작성된 명령어)를 바이트코드로 [컴파일링](https://ethereum.org/ko/developers/docs/smart-contracts/compiling/) 합니다. EVM은 고급 명령어를 해석할 수 없으므로, EVM에서 컨트랙트 로직을 실행하려면 소스 코드를 바이트코드(즉, 저수준 기계어 명령어)로 컴파일링해야 합니다. 소스 코드 검증은 스마트 컨트랙트의 소스 코드와 컨트랙트 생성 시 사용된 컴파일된 바이트코드를 비교하여 차이점을 찾아내는 과정입니다. 광고된 컨트랙트 코드가 블록체인에서 실제로 실행되는 코드와 다를 수 있기 때문에 스마트 컨트랙트를 검증하는 것은 중요합니다. 스마트 컨트랙트 검증을 통해 기계어를 읽을 필요 없이 컨트랙트가 작성된 고급 언어를 통해 컨트랙트가 수행하는 작업을 조사할 수 있습니다. 함수, 값, 그리고 일반적으로 변수 이름과 주석은 컴파일링되어 배포된 원본 소스 코드와 동일하게 유지됩니다. 이로 인해 코드를 읽기가 훨씬 쉬워집니다. 또한 소스 검증은 코드 문서화를 제공하여 최종 사용자가 스마트 컨트랙트가 어떤 작업을 수행하도록 설계되었는지 알 수 있게 해줍니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/verifying/#full-verification) 전체 검증이란 무엇인가요? 소스 코드에는 주석이나 변수 이름과 같이 컴파일된 바이트코드에 영향을 주지 않는 부분이 있습니다. 이는 변수 이름과 주석이 다른 두 소스 코드가 모두 동일한 컨트랙트를 검증할 수 있음을 의미합니다. 이를 악용하여 악의적인 행위자가 소스 코드 내에 기만적인 주석을 추가하거나 오해의 소지가 있는 변수 이름을 지정하여 원본 소스 코드와 다른 소스 코드로 컨트랙트를 검증받을 수 있습니다. 소스 코드의 정확성에 대한 _암호학적 보장_ 및 컴파일링 정보의 _지문_ 역할을 하도록 바이트코드에 추가 데이터를 덧붙임으로써 이를 방지할 수 있습니다. 필요한 정보는 [Solidity의 컨트랙트 메타데이터 (새 탭에서 열림)](https://docs.soliditylang.org/en/v0.8.15/metadata.html) 에서 찾을 수 있으며, 이 파일의 해시가 컨트랙트의 바이트코드에 추가됩니다. [메타데이터 플레이그라운드 (새 탭에서 열림)](https://playground.sourcify.dev/) 에서 실제 작동 방식을 확인할 수 있습니다. 메타데이터 파일에는 소스 파일과 그 해시를 포함하여 컨트랙트의 컴파일링에 대한 정보가 포함되어 있습니다. 즉, 컴파일링 설정이나 소스 파일 중 하나의 단 1바이트라도 변경되면 메타데이터 파일이 변경됩니다. 결과적으로 바이트코드에 추가된 메타데이터 파일의 해시도 변경됩니다. 이는 컨트랙트의 바이트코드와 추가된 메타데이터 해시가 주어진 소스 코드 및 컴파일링 설정과 일치한다면, 단 1바이트도 다르지 않은 원본 컴파일링에 사용된 것과 정확히 동일한 소스 코드임을 확신할 수 있다는 것을 의미합니다. 메타데이터 해시를 활용하는 이러한 유형의 검증을 **"[전체 검증 (새 탭에서 열림)](https://docs.sourcify.dev/docs/full-vs-partial-match/) "**(또는 "완벽한 검증")이라고 합니다. 메타데이터 해시가 일치하지 않거나 검증에서 고려되지 않는 경우 "부분 일치"가 되며, 이는 현재 컨트랙트를 검증하는 더 일반적인 방법입니다. 전체 검증 없이는 검증된 소스 코드에 반영되지 않는 [악성 코드를 삽입 (새 탭에서 열림)](https://samczsun.com/hiding-in-plain-sight/) 하는 것이 가능합니다. 대부분의 개발자는 전체 검증을 알지 못하고 컴파일링의 메타데이터 파일을 보관하지 않기 때문에, 지금까지는 부분 검증이 컨트랙트를 검증하는 사실상의 표준 방법이었습니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/verifying/#importance-of-source-code-verification) 소스 코드 검증이 중요한 이유는 무엇인가요? -------------------------------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ko/developers/docs/smart-contracts/verifying/#trustlessness) 무신뢰성 무신뢰성은 스마트 컨트랙트와 [탈중앙화 애플리케이션 (dapp)](https://ethereum.org/ko/developers/docs/dapps/) 의 가장 큰 전제라고 할 수 있습니다. 스마트 컨트랙트는 "불변"이며 변경할 수 없습니다. 컨트랙트는 배포 시점에 코드에 정의된 비즈니스 로직만 실행합니다. 이는 개발자와 기업이 이더리움에 배포한 후에는 컨트랙트의 코드를 조작할 수 없음을 의미합니다. 스마트 컨트랙트가 무신뢰성을 가지려면, 독립적인 검증을 위해 컨트랙트 코드를 사용할 수 있어야 합니다. 모든 스마트 컨트랙트의 컴파일된 바이트코드는 블록체인에 공개되어 있지만, 저수준 언어는 개발자와 사용자 모두가 이해하기 어렵습니다. 프로젝트는 컨트랙트의 소스 코드를 게시하여 신뢰 가정을 줄입니다. 하지만 이는 또 다른 문제로 이어집니다. 게시된 소스 코드가 컨트랙트 바이트코드와 일치하는지 검증하기 어렵다는 것입니다. 이 시나리오에서는 사용자가 블록체인에 배포하기 전에 개발자가 컨트랙트의 비즈니스 로직을 변경하지 않을 것(즉, 바이트코드를 변경하여)이라고 신뢰해야 하므로 무신뢰성의 가치가 상실됩니다. 소스 코드 검증 도구는 스마트 컨트랙트의 소스 코드 파일이 어셈블리 코드와 일치한다는 보장을 제공합니다. 그 결과 사용자가 제3자를 맹목적으로 신뢰하지 않고 컨트랙트에 자금을 예치하기 전에 코드를 검증하는 무신뢰 생태계가 조성됩니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/verifying/#user-safety) 사용자 안전 스마트 컨트랙트에는 일반적으로 많은 자금이 걸려 있습니다. 이로 인해 더 높은 보안 보장과 사용 전 스마트 컨트랙트 로직의 검증이 요구됩니다. 문제는 부도덕한 개발자가 스마트 컨트랙트에 악성 코드를 삽입하여 사용자를 속일 수 있다는 것입니다. 검증이 없다면 악의적인 스마트 컨트랙트는 [백도어 (새 탭에서 열림)](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts) , 논란의 여지가 있는 접근 제어 메커니즘, 악용 가능한 취약점 및 사용자 안전을 위협하는 기타 요소들을 감지되지 않은 채로 포함할 수 있습니다. 스마트 컨트랙트의 소스 코드 파일을 게시하면 감사자와 같은 이해관계자가 잠재적인 공격 벡터에 대해 컨트랙트를 평가하기가 더 쉬워집니다. 여러 당사자가 독립적으로 스마트 컨트랙트를 검증함으로써 사용자는 보안에 대해 더 강력한 보장을 받게 됩니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/verifying/#source-code-verification-for-ethereum-smart-contracts) 이더리움 스마트 컨트랙트의 소스 코드를 검증하는 방법 ---------------------------------------------------------------------------------------------------------------------------------------------------------- [이더리움에 스마트 컨트랙트를 배포](https://ethereum.org/ko/developers/docs/smart-contracts/deploying/) 하려면 데이터 페이로드(컴파일된 바이트코드)가 포함된 트랜잭션을 특수 주소로 전송해야 합니다. 데이터 페이로드는 소스 코드를 컴파일링하여 생성되며, 여기에 트랜잭션의 데이터 페이로드에 추가된 컨트랙트 인스턴스의 [생성자 인수 (새 탭에서 열림)](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) 가 더해집니다. 컴파일링은 결정론적입니다. 즉, 동일한 소스 파일과 컴파일링 설정(예: 컴파일러 버전, 최적화 도구)을 사용하면 항상 동일한 출력(즉, 컨트랙트 바이트코드)을 생성합니다. [![A diagram showing showing smart contract source code verification](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fsmart-contracts%2Fverifying%2Fsource-code-verification.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/smart-contracts/verifying/source-code-verification.png) 스마트 컨트랙트 검증에는 기본적으로 다음 단계가 포함됩니다. 1. 소스 파일과 컴파일링 설정을 컴파일러에 입력합니다. 2. 컴파일러가 컨트랙트의 바이트코드를 출력합니다. 3. 주어진 주소에 배포된 컨트랙트의 바이트코드를 가져옵니다. 4. 배포된 바이트코드와 다시 컴파일된 바이트코드를 비교합니다. 코드가 일치하면 주어진 소스 코드 및 컴파일링 설정으로 컨트랙트가 검증됩니다. 5. 추가로, 바이트코드 끝에 있는 메타데이터 해시가 일치하면 전체 일치가 됩니다. 이것은 검증에 대한 단순화된 설명이며, [불변 변수 (새 탭에서 열림)](https://docs.sourcify.dev/docs/immutables/) 를 갖는 것과 같이 이 방식이 작동하지 않는 많은 예외가 있다는 점에 유의하세요. [](https://ethereum.org/ko/developers/docs/smart-contracts/verifying/#source-code-verification-tools) 소스 코드 검증 도구 ----------------------------------------------------------------------------------------------------------------- 컨트랙트를 검증하는 전통적인 과정은 복잡할 수 있습니다. 이것이 바로 이더리움에 배포된 스마트 컨트랙트의 소스 코드를 검증하기 위한 도구가 있는 이유입니다. 이러한 도구는 소스 코드 검증의 많은 부분을 자동화하고 사용자의 편의를 위해 검증된 컨트랙트를 선별합니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/verifying/#etherscan) Etherscan 주로 [이더리움 블록 탐색기](https://ethereum.org/ko/developers/docs/data-and-analytics/block-explorers/) 로 알려져 있지만, Etherscan은 스마트 컨트랙트 개발자와 사용자를 위한 [소스 코드 검증 서비스 (새 탭에서 열림)](https://etherscan.io/verifyContract) 도 제공합니다. Etherscan을 사용하면 원본 데이터 페이로드(소스 코드, 라이브러리 주소, 컴파일러 설정, 컨트랙트 주소 등)에서 컨트랙트 바이트코드를 다시 컴파일링할 수 있습니다. 다시 컴파일된 바이트코드가 온체인 컨트랙트의 바이트코드(및 생성자 매개변수)와 연관되어 있다면 [컨트랙트가 검증됩니다 (새 탭에서 열림)](https://info.etherscan.com/types-of-contract-verification/) . 검증이 완료되면 컨트랙트의 소스 코드는 "Verified(검증됨)" 라벨을 받고 다른 사람들이 감사할 수 있도록 Etherscan에 게시됩니다. 또한 검증된 소스 코드가 있는 스마트 컨트랙트 저장소인 [검증된 컨트랙트(Verified Contracts) (새 탭에서 열림)](https://etherscan.io/contractsVerified/) 섹션에 추가됩니다. Etherscan은 컨트랙 검증에 가장 많이 사용되는 도구입니다. 하지만 Etherscan의 컨트랙트 검증에는 한 가지 단점이 있습니다. 온체인 바이트코드와 다시 컴파일된 바이트코드의 **메타데이터 해시**를 비교하지 못한다는 것입니다. 따라서 Etherscan에서의 일치는 부분 일치입니다. [Etherscan에서 컨트랙트 검증에 대해 자세히 알아보기 (새 탭에서 열림)](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327) . ### [](https://ethereum.org/ko/developers/docs/smart-contracts/verifying/#blockscout) Blockscout [Blockscout (새 탭에서 열림)](https://blockscout.com/) 은 스마트 컨트랙트 개발자와 사용자를 위한 [컨트랙트 검증 서비스 (새 탭에서 열림)](https://eth.blockscout.com/contract-verification) 도 제공하는 오픈 소스 블록 탐색기입니다. 오픈 소스 대안으로서 Blockscout은 검증 수행 방식에 대한 투명성을 제공하고 검증 프로세스를 개선하기 위한 커뮤니티의 기여를 가능하게 합니다. 다른 검증 서비스와 마찬가지로 Blockscout을 사용하면 바이트코드를 다시 컴파일링하고 배포된 컨트랙트와 비교하여 컨트랙트의 소스 코드를 검증할 수 있습니다. 검증이 완료되면 컨트랙트는 검증 상태를 받게 되며 소스 코드는 감사 및 상호작용을 위해 공개적으로 사용할 수 있게 됩니다. 검증된 컨트랙트는 쉽게 탐색하고 디스커버리할 수 있도록 Blockscout의 [검증된 컨트랙트 저장소 (새 탭에서 열림)](https://eth.blockscout.com/verified-contracts) 에도 나열됩니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/verifying/#sourcify) Sourcify [Sourcify (새 탭에서 열림)](https://sourcify.dev/#/verifier) 는 오픈 소스이며 탈중앙화된 또 다른 컨트랙트 검증 도구입니다. 이것은 블록 탐색기가 아니며 [다양한 EVM 기반 네트워크 (새 탭에서 열림)](https://docs.sourcify.dev/docs/chains) 에서만 컨트랙트를 검증합니다. 다른 도구들이 그 위에 구축될 수 있는 공공 인프라 역할을 하며, 메타데이터 파일에 있는 [ABI](https://ethereum.org/ko/developers/docs/smart-contracts/compiling/#web-applications) 및 [NatSpec (새 탭에서 열림)](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) 주석을 사용하여 보다 인간 친화적인 컨트랙트 상호작용을 가능하게 하는 것을 목표로 합니다. Etherscan과 달리 Sourcify는 메타데이터 해시와의 전체 일치를 지원합니다. 검증된 컨트랙트는 HTTP 및 탈중앙화된 [콘텐츠 주소 지정 (새 탭에서 열림)](https://docs.storacha.network/concepts/content-addressing/) 스토리지인 [IPFS (새 탭에서 열림)](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs) 의 [공개 저장소 (새 탭에서 열림)](https://docs.sourcify.dev/docs/repository/) 에서 제공됩니다. 추가된 메타데이터 해시가 IPFS 해시이므로 이를 통해 IPFS를 통해 컨트랙트의 메타데이터 파일을 가져올 수 있습니다. 또한 이러한 파일의 IPFS 해시도 메타데이터에 있으므로 IPFS를 통해 소스 코드 파일을 검색할 수도 있습니다. API나 [UI (새 탭에서 열림)](https://sourcify.dev/#/verifier) 를 통해 메타데이터 파일과 소스 파일을 제공하거나 플러그인을 사용하여 컨트랙트를 검증할 수 있습니다. Sourcify 모니터링 도구는 또한 새로운 블록의 컨트랙트 생성을 수신하고 메타데이터와 소스 파일이 IPFS에 게시된 경우 컨트랙트를 검증하려고 시도합니다. [Sourcify에서 컨트랙트 검증에 대해 자세히 알아보기 (새 탭에서 열림)](https://soliditylang.org/blog/2020/06/25/sourcify-faq/) . ### [](https://ethereum.org/ko/developers/docs/smart-contracts/verifying/#tenderly) Tenderly [Tenderly 플랫폼 (새 탭에서 열림)](https://tenderly.co/) 을 통해 Web3 개발자는 스마트 컨트랙트를 구축, 테스트, 모니터링 및 운영할 수 있습니다. 디버깅 도구를 관찰 가능성 및 인프라 구성 요소와 결합하여 Tenderly는 개발자가 스마트 컨트랙트 개발을 가속화하도록 돕습니다. Tenderly 기능을 완전히 활성화하려면 개발자는 여러 가지 방법을 사용하여 [소스 코드 검증을 수행 (새 탭에서 열림)](https://docs.tenderly.co/monitoring/contract-verification) 해야 합니다. 컨트랙트를 비공개 또는 공개적으로 검증할 수 있습니다. 비공개로 검증된 경우 스마트 컨트랙트는 본인(및 프로젝트의 다른 멤버)에게만 표시됩니다. 컨트랙트를 공개적으로 검증하면 Tenderly 플랫폼을 사용하는 모든 사람에게 표시됩니다. [대시보드 (새 탭에서 열림)](https://docs.tenderly.co/contract-verification) , [Tenderly Hardhat 플러그인 (새 탭에서 열림)](https://docs.tenderly.co/contract-verification/hardhat) 또는 [CLI (새 탭에서 열림)](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli) 를 사용하여 컨트랙트를 검증할 수 있습니다. 대시보드를 통해 컨트랙트를 검증할 때는 소스 파일이나 Solidity 컴파일러에서 생성된 메타데이터 파일, 주소/네트워크 및 컴파일러 설정을 가져와야 합니다. Tenderly Hardhat 플러그인을 사용하면 적은 노력으로 검증 프로세스를 더 세밀하게 제어할 수 있으며, 자동(노코드) 검증과 수동(코드 기반) 검증 중에서 선택할 수 있습니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/verifying/#further-reading) 더 읽어보기 --------------------------------------------------------------------------------------------- * [컨트랙트 소스 코드 검증 (새 탭에서 열림)](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/) --- # Mbinu bora za muundo wa soko la ubadilishanaji lililogatuliwa (DEX) | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#main-content) Change page Mbinu bora za muundo wa soko la ubadilishanaji lililogatuliwa (DEX) =================================================================== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/design-and-ux/dex-design-best-practice/index.md) Kwenye ukurasa huu Tangu kuzinduliwa kwa Uniswap mnamo 2018, kumekuwa na mamia ya masoko ya ubadilishanaji yaliyogatuliwa yaliyozinduliwa kwenye makumi ya misururu tofauti. Mengi ya haya yalianzisha vipengele vipya au kuongeza mtindo wao wenyewe, lakini kiolesura kimebaki kuwa sawa kwa ujumla. Sababu moja ya hii ni [Sheria ya Jakob (inafunguka katika kichupo kipya)](https://lawsofux.com/jakobs-law/) : > Watumiaji hutumia muda wao mwingi kwenye tovuti nyingine. Hii inamaanisha kuwa watumiaji wanapendelea tovuti yako ifanye kazi kwa njia sawa na tovuti nyingine zote wanazozijua tayari. Shukrani kwa wavumbuzi wa mapema kama Uniswap, Pancakeswap, na Sushiswap, watumiaji wa fedha zilizogatuliwa (DeFi) wana wazo la pamoja la jinsi soko la ubadilishanaji lililogatuliwa (DEX) linavyoonekana. Kwa sababu hii, kitu kama "mbinu bora" sasa kinaibuka. Tunaona maamuzi mengi zaidi ya muundo yakisanifiwa kwenye tovuti mbalimbali. Unaweza kuona mabadiliko ya DEX kama mfano mkubwa wa kufanya majaribio katika matumizi halisi. Mambo yaliyofanya kazi yalibaki, mambo ambayo hayakufanya kazi, yalitupwa nje. Bado kuna nafasi ya kuweka mtindo binafsi, lakini kuna viwango fulani ambavyo DEX inapaswa kufuata. Makala haya ni muhtasari wa: * nini cha kujumuisha * jinsi ya kuifanya iwe rahisi kutumia iwezekanavyo * njia kuu za kubinafsisha muundo Mifano yote ya michoro ya awali (wireframes) ilitengenezwa mahususi kwa ajili ya makala haya, ingawa yote inategemea miradi halisi. Kifurushi cha Figma pia kimejumuishwa chini - jisikie huru kukitumia na kuharakisha michoro yako ya awali! [](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#basic-anatomy-of-a-dex) Muundo wa kimsingi wa DEX ------------------------------------------------------------------------------------------------------------------------------------ Kiolesura cha mtumiaji (UI) kwa ujumla kina vipengele vitatu: 1. Fomu kuu 2. Kitufe 3. Paneli ya maelezo [![Generic DEX UI, showing the three main elements](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F1.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/1.png) [](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#variations) Tofauti ------------------------------------------------------------------------------------------------------ Hii itakuwa mada ya kawaida katika makala haya, lakini kuna njia mbalimbali tofauti ambazo vipengele hivi vinaweza kupangwa. "Paneli ya maelezo" inaweza kuwa: * Juu ya kitufe * Chini ya kitufe * Imefichwa katika paneli kunjufu (accordion) * Na/au kwenye kidirisha cha "kuhakiki" Zingatia: Kidirisha cha "kuhakiki" ni cha hiari, lakini ikiwa unaonyesha maelezo machache sana kwenye UI kuu, inakuwa muhimu. [](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#structure-of-the-main-form) Muundo wa fomu kuu --------------------------------------------------------------------------------------------------------------------------------- Hili ni sanduku ambapo unachagua ni tokeni gani unataka kufanyia badilishano. Kipengele hiki kinajumuisha sehemu ya kuingiza data na kitufe kidogo katika mstari mmoja. DEX kwa kawaida huonyesha maelezo ya ziada katika mstari mmoja juu na mstari mmoja chini, ingawa hii inaweza kusanidiwa tofauti. [![Input row, with a details row above and below](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F2.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/2.png) [](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#variations2) Tofauti ------------------------------------------------------------------------------------------------------- Tofauti mbili za UI zinaonyeshwa hapa; moja isiyo na mipaka yoyote, na kuunda muundo ulio wazi sana, na moja ambapo mstari wa kuingiza data una mpaka, na kuunda mwelekeo kwenye kipengele hicho. [![Two UI variations of the main form](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F3.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/3.png) Muundo huu wa kimsingi unaruhusu **vipande vinne muhimu vya maelezo** kuonyeshwa katika muundo: kimoja katika kila kona. Ikiwa kuna mstari mmoja tu wa juu/chini, basi kuna nafasi mbili tu. Wakati wa mabadiliko ya DeFi, mambo mengi tofauti yamejumuishwa hapa. [](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#key-info-to-include) Maelezo muhimu ya kujumuisha ------------------------------------------------------------------------------------------------------------------------------------ * Salio katika mkoba * Kitufe cha kiwango cha juu (Max) * Thamani sawa katika sarafu ya serikali (fiat) * Athari ya bei kwenye kiasi "kilichopokelewa" Katika siku za mwanzo za DeFi, thamani sawa ya sarafu ya serikali mara nyingi ilikosekana. Ikiwa unaunda aina yoyote ya mradi wa Web3, ni muhimu kwamba thamani sawa ya sarafu ya serikali ionyeshwe. Watumiaji bado wanafikiria kwa kutumia sarafu za ndani, kwa hivyo ili kuendana na mifumo ya kiakili ya ulimwengu halisi, hii inapaswa kujumuishwa. Kwenye sehemu ya pili (ile ambayo unachagua tokeni unayobadilisha kwenda) unaweza pia kujumuisha athari ya bei karibu na kiasi cha sarafu ya serikali, kwa kukokotoa tofauti kati ya kiasi kilichoingizwa na kiasi kinachokadiriwa kutoka. Hili ni jambo muhimu sana la kujumuisha. Vitufe vya asilimia (k.m., 25%, 50%, 75%) vinaweza kuwa kipengele muhimu, lakini vinachukua nafasi zaidi, vinaongeza wito zaidi wa kuchukua hatua, na kuongeza mzigo zaidi wa kiakili. Sawa na vitelezi vya asilimia. Baadhi ya maamuzi haya ya UI yatategemea chapa yako na aina ya mtumiaji wako. Maelezo ya ziada yanaweza kuonyeshwa chini ya fomu kuu. Kwa kuwa aina hii ya maelezo ni zaidi kwa watumiaji wataalamu, inaleta maana: * kuiweka kwa uchache iwezekanavyo, au; * kuificha katika paneli kunjufu (accordion) [![Details shown in the corners of that main form](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F4.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/4.png) [](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#extra-info-to-include) Maelezo ya ziada ya kujumuisha ---------------------------------------------------------------------------------------------------------------------------------------- * Bei ya tokeni * Tofauti ya utekelezaji * Kiasi cha chini kilichopokelewa * Kiasi kinachotarajiwa * Athari ya bei * Makadirio ya gharama ya gesi * Ada nyingine * Uelekezaji wa oda Inawezekana, baadhi ya maelezo haya yanaweza kuwa ya hiari. Uelekezaji wa oda unavutia, lakini haileti tofauti kubwa kwa watumiaji wengi. Baadhi ya maelezo mengine yanarudia tu kitu kile kile kwa njia tofauti. Kwa mfano "kiasi cha chini kilichopokelewa" na "tofauti ya utekelezaji" ni pande mbili za sarafu moja. Ikiwa umeweka tofauti ya utekelezaji kwa 1%, basi kiasi cha chini unachoweza kutarajia kupokea = kiasi kinachotarajiwa-1%. Baadhi ya UI zitaonyesha kiasi kinachotarajiwa, kiasi cha chini, na tofauti ya utekelezaji... Ambayo ni muhimu lakini inawezekana ni maelezo yaliyozidi. Watumiaji wengi wataacha tofauti ya utekelezaji ya msingi hata hivyo. "Athari ya bei" mara nyingi huonyeshwa kwenye mabano karibu na thamani sawa ya sarafu ya serikali katika sehemu ya "kwenda". Hili ni jambo zuri la UX la kuongeza, lakini ikiwa linaonyeshwa hapa, je, kweli linahitaji kuonyeshwa tena hapa chini? Na kisha tena kwenye skrini ya kuhakiki? Watumiaji wengi (hasa wale wanaofanya badilishano la kiasi kidogo) hawatajali kuhusu maelezo haya; wataingiza tu nambari na kubofya badilishano. [![Some details show the same thing](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F5.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/5.png) Ni maelezo gani hasa yanayoonyeshwa yatategemea hadhira yako na hisia gani unataka programu iwe nayo. Ikiwa utajumuisha uvumilivu wa tofauti ya utekelezaji katika paneli ya maelezo, unapaswa pia kuifanya iweze kuhaririwa moja kwa moja kutoka hapa. Huu ni mfano mzuri wa "kiharakishi"; mbinu nzuri ya UX inayoweza kuharakisha mtiririko wa watumiaji wenye uzoefu, bila kuathiri matumizi ya jumla ya programu. [![Slippage can be controlled from the details panel](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F6.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/6.png) Ni wazo zuri kufikiria kwa makini sio tu kuhusu kipande kimoja maalum cha taarifa kwenye skrini moja, bali kuhusu mtiririko mzima: Kuingiza nambari katika Fomu Kuu → Kukagua Maelezo → Kubofya kwenye Skrini ya Kuhakiki (ikiwa una skrini ya kuhakiki). Je, paneli ya maelezo inapaswa kuonekana wakati wote, au mtumiaji anahitaji kuibofya ili kuipanua? Je, unapaswa kuunda msuguano kwa kuongeza skrini ya kuhakiki? Hii inamlazimu mtumiaji kupunguza mwendo na kufikiria biashara yake, jambo ambalo linaweza kuwa muhimu. Lakini je, wanataka kuona maelezo yale yale tena? Ni nini muhimu zaidi kwao wakati huu? [](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#design-options) Chaguzi za muundo -------------------------------------------------------------------------------------------------------------------- Kama ilivyotajwa, mengi ya haya yanategemea mtindo wako binafsi Mtumiaji wako ni nani? Chapa yako ni nini? Je, unataka kiolesura cha "kitaalamu" kinachoonyesha kila maelezo, au unataka kuwa na muundo rahisi? Hata kama unalenga watumiaji wataalamu wanaotaka maelezo yote iwezekanavyo, bado unapaswa kukumbuka maneno ya busara ya Alan Cooper: > Haijalishi kiolesura chako ni kizuri kiasi gani, haijalishi kinavutia kiasi gani, ingekuwa bora ikiwa kingekuwa na mambo machache. ### [](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#structure) Muundo * tokeni upande wa kushoto, au tokeni upande wa kulia * mistari 2 au 3 * maelezo juu au chini ya kitufe * maelezo yaliyopanuliwa, yaliyopunguzwa, au ambayo hayaonyeshwi ### [](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#component-style) Mtindo wa kipengele * tupu * yenye muhtasari * iliyojazwa Kutoka kwa mtazamo halisi wa UX, mtindo wa UI haujalishi sana kama unavyofikiria. Mitindo ya kuona huja na kuondoka katika mizunguko, na mapendeleo mengi ni ya kibinafsi. Njia rahisi zaidi ya kupata hisia ya hili - na kufikiria kuhusu usanidi mbalimbali tofauti - ni kuangalia baadhi ya mifano na kisha kufanya majaribio wewe mwenyewe. Kifurushi cha Figma kilichojumuishwa kina vipengele vitupu, vyenye muhtasari na vilivyojazwa. Angalia mifano hapa chini ili kuona njia tofauti unazoweza kuweka yote pamoja: [![3 rows in a filled style](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F7.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/7.png) [![3 rows in a outlined style](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F8.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/8.png) [![2 rows in an empty style](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F9.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/9.png) [![3 rows in an outlined style, with a details panel](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F10.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/10.png) [![3 rows with the input row in an outlined style](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F11.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/11.png) [![2 rows in a filled style](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F12.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/12.png) [](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#but-which-side-should-the-token-go-on) Lakini tokeni inapaswa kwenda upande gani? -------------------------------------------------------------------------------------------------------------------------------------------------------------------- Jambo la msingi ni kwamba labda haileti tofauti kubwa kwa matumizi. Kuna mambo machache ya kuzingatia, hata hivyo, ambayo yanaweza kukushawishi kwa njia moja au nyingine. Imekuwa ya kuvutia kiasi kuona mtindo ukibadilika na wakati. Uniswap mwanzoni ilikuwa na tokeni upande wa kushoto, lakini tangu wakati huo imeihamishia upande wa kulia. Sushiswap pia ilifanya mabadiliko haya wakati wa uboreshaji wa muundo. Itifaki nyingi, lakini sio zote, zimefuata mkondo huo. Kawaida ya kifedha kwa asili huweka alama ya sarafu kabla ya nambari, k.m., $50, €50, £50, lakini sisi _husema_ dola 50, Euro 50, pauni 50. Kwa mtumiaji wa kawaida - hasa mtu anayesoma kutoka kushoto kwenda kulia, juu hadi chini - tokeni upande wa kulia labda inahisi asili zaidi. [![A UI with tokens on the left](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F13.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/13.png) Kuweka tokeni upande wa kushoto na nambari zote upande wa kulia kunaonekana kwa ulinganifu wa kupendeza, ambayo ni faida, lakini kuna hasara nyingine kwa mpangilio huu. Sheria ya ukaribu inasema kwamba vitu vilivyo karibu pamoja huchukuliwa kuwa vinahusiana. Kwa hivyo, tunataka kuweka vitu vinavyohusiana karibu na kila kimoja. Salio la tokeni linahusiana moja kwa moja na tokeni yenyewe, na litabadilika wakati wowote tokeni mpya inapochaguliwa. Kwa hivyo inaleta maana kidogo zaidi kwa salio la tokeni kuwa karibu na kitufe cha kuchagua tokeni. Inaweza kuhamishwa chini ya tokeni, lakini hiyo inavunja ulinganifu wa mpangilio. Hatimaye, kuna faida na hasara kwa chaguzi zote mbili, lakini inavutia jinsi mwelekeo unavyoonekana kuwa kuelekea tokeni upande wa kulia. [](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#button-behavior) Tabia ya kitufe ------------------------------------------------------------------------------------------------------------------- Usiwe na kitufe tofauti cha Idhinisha. Pia usiwe na mbofyo tofauti wa Idhinisha. Mtumiaji anataka kufanya Badilishano, kwa hivyo sema tu "badilishano" kwenye kitufe na uanzishe uidhinishaji kama hatua ya kwanza. Kidirisha kinaweza kuonyesha maendeleo kwa kutumia kiashiria cha hatua, au arifa rahisi ya "muamala 1 kati ya 2 - inaidhinisha". [![A UI with separate buttons for approve and swap](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F14.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/14.png) [![A UI with one button that says approve](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F15.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/15.png) ### [](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#button-as-contextual-help) Kitufe kama msaada wa kimuktadha Kitufe kinaweza kufanya kazi mbili kama arifa! Kwa kweli huu ni muundo usio wa kawaida nje ya Web3, lakini umekuwa kiwango ndani yake. Huu ni uvumbuzi mzuri kwani unaokoa nafasi, na kuweka umakini ukilenga. Ikiwa kitendo kikuu - BADILISHANO - hakipatikani kutokana na hitilafu, sababu ya kwa nini inaweza kuelezewa na kitufe, k.m.: * badilisha mtandao * unganisha mkoba * hitilafu mbalimbali Kitufe pia kinaweza **kuhusishwa na kitendo** kinachohitaji kufanywa. Kwa mfano, ikiwa mtumiaji hawezi kufanya badilishano kwa sababu yuko kwenye mtandao usio sahihi, kitufe kinapaswa kusema "badilisha kwenda Ethereum", na wakati mtumiaji anabofya kwenye kitufe, inapaswa kubadilisha mtandao kwenda Ethereum. Hii inaharakisha mtiririko wa mtumiaji kwa kiasi kikubwa. [![Key actions being initiated from the main CTA](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F16.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/16.png) [![Error message shown within the main CTA](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F17.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/17.png) [](https://ethereum.org/sw/developers/docs/design-and-ux/dex-design-best-practice/#build-your-own-with-this-figma-file) Jenga yako mwenyewe na faili hili la figma ------------------------------------------------------------------------------------------------------------------------------------------------------------------ Shukrani kwa kazi ngumu ya itifaki nyingi, muundo wa DEX umeboreshwa sana. Tunajua ni maelezo gani mtumiaji anahitaji, jinsi tunavyopaswa kuyaonyesha, na jinsi ya kufanya mtiririko uwe laini iwezekanavyo. Tunatumai makala haya yanatoa muhtasari thabiti wa kanuni za UX. Ikiwa unataka kufanya majaribio, tafadhali jisikie huru kutumia kifurushi cha michoro ya awali cha Figma. Kimewekwa rahisi iwezekanavyo, lakini kina unyumbufu wa kutosha kujenga muundo wa kimsingi kwa njia mbalimbali. [Kifurushi cha michoro ya awali cha Figma (inafunguka katika kichupo kipya)](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit) Fedha zilizogatuliwa (DeFi) zitaendelea kubadilika, na daima kuna nafasi ya kuboresha. Kila la heri! --- # イーサリアム仮想マシン (EVM) | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/evm/#main-content) Change page イーサリアム仮想マシン (EVM) ================= .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/evm/index.md) このページの内容 イーサリアム仮想マシン (EVM) は、すべての[イーサリアム](https://ethereum.org/ja/) ノード間で一貫して安全にコードを実行する分散型仮想環境です。ノードはEVMを実行してスマート・コントラクトを実行し、[オペレーション](https://ethereum.org/ja/developers/docs/evm/opcodes/) に必要な計算量を測定するために「[ガス](https://ethereum.org/ja/developers/docs/gas/) 」を使用することで、効率的なリソース割り当てとネットワークのセキュリティを確保します。 [](https://ethereum.org/ja/developers/docs/evm/#prerequisites) 前提条件 ------------------------------------------------------------------- EVMを理解するには、[バイト （新しいタブで開きます）](https://wikipedia.org/wiki/Byte) 、[メモリ （新しいタブで開きます）](https://wikipedia.org/wiki/Computer_memory) 、[スタック （新しいタブで開きます）](https://wikipedia.org/wiki/Stack_(abstract_data_type)) などのコンピューターサイエンスの一般的な用語に関する基本的な知識が必要です。また、[ハッシュ関数 （新しいタブで開きます）](https://wikipedia.org/wiki/Cryptographic_hash_function) や[マークル・ツリー （新しいタブで開きます）](https://wikipedia.org/wiki/Merkle_tree) などの暗号技術やブロックチェーンの概念に慣れておくと役立ちます。 [](https://ethereum.org/ja/developers/docs/evm/#from-ledger-to-state-machine) 台帳から状態マシンへ ---------------------------------------------------------------------------------------- 「分散型台帳」という例えは、暗号技術の基本的なツールを使用して分散型通貨を可能にするビットコインのようなブロックチェーンを説明するためによく使用されます。台帳は、台帳を変更するために誰が何をでき、何ができないかを管理する一連のルールに従わなければならない活動の記録を維持します。たとえば、ビットコインのアドレスは、以前に受け取った以上のビットコインを支払うことはできません。これらのルールは、ビットコインや他の多くのブロックチェーン上のすべてのトランザクションの基盤となっています。 イーサリアムには、ほぼ同じ直感的なルールに従う独自のネイティブ暗号資産 (イーサ) がありますが、はるかに強力な機能である[スマート・コントラクト](https://ethereum.org/ja/developers/docs/smart-contracts/) も可能にします。このより複雑な機能には、より洗練された例えが必要です。分散型台帳の代わりに、イーサリアムは分散型の[状態マシン （新しいタブで開きます）](https://wikipedia.org/wiki/Finite-state_machine) です。イーサリアムの状態は、すべてのアカウントと残高だけでなく、事前に定義された一連のルールに従ってブロックごとに変化し、任意の機械語コードを実行できる「マシン状態 (machine state)」を保持する大規模なデータ構造です。ブロックごとに状態を変更する具体的なルールは、EVMによって定義されています。 [![A diagram showing the make up of the EVM](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fevm%2Fevm.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/evm/evm.png) _図は[Ethereum EVM illustrated （新しいタブで開きます）](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) から引用・改変_ [](https://ethereum.org/ja/developers/docs/evm/#the-ethereum-state-transition-function) イーサリアムの状態遷移関数 ----------------------------------------------------------------------------------------------------- EVMは数学関数のように動作します。つまり、入力が与えられると、決定論的な出力を生成します。したがって、イーサリアムが**状態遷移関数**を持っているとより形式的に説明することは非常に役立ちます。 Y(S, T)= S' コピー 有効な古い状態 `(S)` と有効なトランザクションの新しいセット `(T)` が与えられると、イーサリアムの状態遷移関数 `Y(S, T)` は新しい有効な出力状態 `S'` を生成します。 ### [](https://ethereum.org/ja/developers/docs/evm/#state) 状態 イーサリアムのコンテキストでは、状態は[変更されたマークル・パトリシア・トライ](https://ethereum.org/ja/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) と呼ばれる巨大なデータ構造であり、すべての[アカウント](https://ethereum.org/ja/developers/docs/accounts/) をハッシュでリンクし、ブロックチェーンに保存されている単一のルートハッシュに還元できるように保持します。 ### [](https://ethereum.org/ja/developers/docs/evm/#transactions) トランザクション トランザクションは、アカウントからの暗号技術によって署名された命令です。トランザクションには、メッセージ・コールをもたらすものと、コントラクトの作成をもたらすものの2種類があります。 コントラクトの作成により、コンパイルされた[スマート・コントラクト](https://ethereum.org/ja/developers/docs/smart-contracts/anatomy/) のバイトコードを含む新しいコントラクト・アカウントが作成されます。別のアカウントがそのコントラクトにメッセージ・コールを行うたびに、そのバイトコードが実行されます。 [](https://ethereum.org/ja/developers/docs/evm/#evm-instructions) EVMの命令 ------------------------------------------------------------------------ EVMは、深さ1024アイテムの[スタックマシン （新しいタブで開きます）](https://wikipedia.org/wiki/Stack_machine) として実行されます。各アイテムは256ビットのワードであり、256ビットの暗号技術 (ケチャック・256ハッシュやsecp256k1署名など) での使いやすさを考慮して選択されました。 実行中、EVMは一時的な「メモリ」(ワード単位でアドレス指定されるバイト配列として) を維持しますが、これはトランザクション間で永続化されません。 ### [](https://ethereum.org/ja/developers/docs/evm/#transient-storage) 一時ストレージ 一時ストレージは、`TSTORE` および `TLOAD` オペコードを通じてアクセスされる、トランザクションごとのキーバリューストアです。同じトランザクション中のすべての内部呼び出しにわたって保持されますが、トランザクションの終了時にクリアされます。メモリとは異なり、一時ストレージは実行フレームではなくEVMの状態の一部としてモデル化されていますが、グローバルな状態にはコミットされません。一時ストレージにより、トランザクション中の内部呼び出し間で、ガス効率の良い一時的な状態の共有が可能になります。 ### [](https://ethereum.org/ja/developers/docs/evm/#storage) ストレージ コントラクトには、対象のアカウントに関連付けられ、グローバルな状態の一部であるマークル・パトリシア・「ストレージ」・トライ (ワード単位でアドレス指定可能なワード配列として) が含まれています。この永続的なストレージは、単一のトランザクションの期間中のみ利用可能であり、アカウントの永続的なストレージ・トライの一部を形成しない一時ストレージとは異なります。 ### [](https://ethereum.org/ja/developers/docs/evm/#opcodes) オペコード コンパイルされたスマート・コントラクトのバイトコードは、`XOR`、`AND`、`ADD`、`SUB` などの標準的なスタック操作を実行する多数のEVM[オペコード](https://ethereum.org/ja/developers/docs/evm/opcodes/) として実行されます。EVMはまた、`ADDRESS`、`BALANCE`、`BLOCKHASH` などのブロックチェーン固有のスタック操作も多数実装しています。オペコードセットには、一時ストレージへのアクセスを提供する `TSTORE` と `TLOAD` も含まれています。 [![A diagram showing where gas is needed for EVM operations](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fgas%2Fgas.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/gas/gas.png) _図は[Ethereum EVM illustrated （新しいタブで開きます）](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) から引用・改変_ [](https://ethereum.org/ja/developers/docs/evm/#evm-implementations) EVMの実装 --------------------------------------------------------------------------- EVMのすべての実装は、イーサリアムのイエロー・ペーパーに記載されている仕様に準拠する必要があります。 イーサリアムの10年の歴史の中で、EVMは何度かの改訂を経ており、さまざまなプログラミング言語によるEVMの実装がいくつか存在します。 [イーサリアムの実行クライアント](https://ethereum.org/ja/developers/docs/nodes-and-clients/#execution-clients) には、EVMの実装が含まれています。さらに、以下のような複数のスタンドアロン実装があります。 * [Py-EVM （新しいタブで開きます）](https://github.com/ethereum/py-evm) - _Python_ * [evmone （新しいタブで開きます）](https://github.com/ethereum/evmone) - _C++_ * [ethereumjs-vm （新しいタブで開きます）](https://github.com/ethereumjs/ethereumjs-vm) - _JavaScript_ * [revm （新しいタブで開きます）](https://github.com/bluealloy/revm) - _Rust_ [](https://ethereum.org/ja/developers/docs/evm/#further-reading) 参考文献 --------------------------------------------------------------------- * [イーサリアムのイエロー・ペーパー （新しいタブで開きます）](https://ethereum.github.io/yellowpaper/paper.pdf) * [Jellopaper (別名 KEVM): KにおけるEVMのセマンティクス （新しいタブで開きます）](https://jellopaper.org/) * [The Beigepaper （新しいタブで開きます）](https://github.com/chronaeon/beigepaper) * [イーサリアム仮想マシンのオペコード （新しいタブで開きます）](https://www.ethervm.io/) * [イーサリアム仮想マシンのオペコード・インタラクティブ・リファレンス （新しいタブで開きます）](https://www.evm.codes/) * [Solidityドキュメントの簡単な紹介 （新しいタブで開きます）](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) * [マスタリング・イーサリアム - イーサリアム仮想マシン （新しいタブで開きます）](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc) [](https://ethereum.org/ja/developers/docs/evm/#related-topics) 関連トピック ---------------------------------------------------------------------- * [ガス](https://ethereum.org/ja/developers/docs/gas/) [](https://ethereum.org/ja/developers/docs/evm/#tutorials) チュートリアル: イーサリアム仮想マシン (EVM) / イーサリアムのオペコード ---------------------------------------------------------------------------------------------------- * [イエロー・ペーパーのEVM仕様を理解する](https://ethereum.org/ja/developers/tutorials/yellow-paper-evm/) _– イーサリアムのイエロー・ペーパーに記載されている正式なEVM仕様のガイド付きウォークスルー。_ * [コントラクトのリバースエンジニアリング](https://ethereum.org/ja/developers/tutorials/reverse-engineering-a-contract/) _– EVMオペコードを使用してコンパイルされたスマート・コントラクトをリバースエンジニアリングする方法。_ イーサリアムの知識をテストする --------------- --- # スマート・コントラクトとのやり取り | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#main-content) Change page スマート・コントラクトとのやり取り ================= .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/interacting/index.md) このページの内容 常に独自のスマート・コントラクトを記述してデプロイする必要はありません。開発者としては、他の人がすでにイーサリアムネットワークにデプロイしたスマート・コントラクトとやり取りしたい場合がほとんどです。 このページでは、スマート・コントラクトとやり取りするための2つの基本的な方法（データの**読み取り**と**書き込み**）と、その両方を行うために必要なツールについて説明します。 [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#prerequisites) 前提条件 ------------------------------------------------------------------------------------------- 以下について理解している必要があります。 * [スマート・コントラクトの仕組み](https://ethereum.org/ja/developers/docs/smart-contracts/) * [イーサリアムのアカウントとトランザクションの署名方法](https://ethereum.org/ja/developers/docs/accounts/) * [トランザクションとは何か](https://ethereum.org/ja/developers/docs/transactions/) [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#two-ways) スマート・コントラクトとやり取りする2つの方法 --------------------------------------------------------------------------------------------------------- スマート・コントラクトとのやり取りは、2つのカテゴリに分類されます。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#reading-from-a-contract) コントラクトからの読み取り 読み取りは**無料**の操作であり、トランザクションを作成せず、ブロックチェーン上の状態を変更することもありません。 コントラクトから読み取る場合、単にすでに存在するデータをクエリしているだけです。例： * ERC-20トークンの残高の確認 * 分散型取引所からの現在の価格の読み取り * NFTの所有者の取得 読み取りは状態を変更しないため、[ガス](https://ethereum.org/ja/developers/docs/gas/) を消費せず、ETHを必要とせずに誰でも実行できます。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#writing-to-a-contract) コントラクトへの書き込み 書き込みは**状態を変更する**操作であり、トランザクションを必要とし、ガスを消費します。 コントラクトに書き込む場合、ブロックチェーンの状態を変更する関数をトリガーします。例： * トークンの送金 * 分散型取引所でのトークンのスワップ * NFTのミンティング 書き込みには常に以下が必要です。 1. ガス代として十分なETHを持つ[外部所有アカウント（EOA）](https://ethereum.org/ja/developers/docs/accounts/#types-of-account) 2. アカウントの秘密鍵によって署名されたトランザクション 3. トランザクションがマイニングされ、ブロックに含まれること [アカウント抽象化](https://ethereum.org/ja/roadmap/account-abstraction/) を使用すると、スマート・コントラクトアカウントも書き込みを開始でき、ペイマスターがユーザーの代わりにガス代を負担できるため、ETHを保持するEOAは厳密には必要ありません。 [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#understanding-contract-abis) コントラクトABIの理解 ----------------------------------------------------------------------------------------------------------------- スマート・コントラクトとやり取りするには、アプリケーションがコントラクトに_何が_できるかを知る必要があります。ここで\*\*アプリケーション・バイナリ・インターフェース（ABI）\*\*の出番となります。 ABIは、以下を記述するJSONドキュメントです。 * コントラクトが公開するすべての関数（名前、入力、出力） * コントラクトが発行できるすべてのイベント * コントラクトと通信する際のデータのエンコードおよびデコード方法 ABIはコントラクトの取扱説明書と考えてください。これがないと、アプリケーションはどの関数が存在するのか、どのようなパラメータを期待しているのかを知ることができません。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#where-to-find-abis) コントラクトのABIを見つける場所 * **Etherscan上の検証済みコントラクト** - [Etherscan （新しいタブで開きます）](https://etherscan.io/) は、検証済みのソースコードのABIを自動的に公開します。 * **開発者から** - 多くのプロジェクトは、ドキュメントやnpmパッケージでABIを公開しています。 * **ソースからの生成** - Solidityのソースコードがある場合は、それを[コンパイル](https://ethereum.org/ja/developers/docs/smart-contracts/compiling/) してABIを生成できます。 [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#tools-and-libraries) コントラクトとやり取りするためのツールとライブラリ ---------------------------------------------------------------------------------------------------------------------- 開発者は通常、Webアプリ、バックエンド、またはスクリプトからコントラクトとやり取りするために、JavaScript/TypeScriptライブラリを使用します。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#client-libraries) クライアントライブラリ（JavaScript/TypeScript） * **[Viem （新しいタブで開きます）](https://viem.sh/) ** - ファーストクラスの型安全性を備えた、イーサリアム向けのモダンで軽量なTypeScriptインターフェース * **[ethers.js （新しいタブで開きます）](https://docs.ethers.org/) ** - イーサリアムブロックチェーンとやり取りするための実戦テスト済みのライブラリ * **[Web3.js （新しいタブで開きます）](https://web3js.org/) ** - オリジナルのイーサリアムJavaScript API ### [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#backend-libraries) バックエンドライブラリ * **[ethers.js （新しいタブで開きます）](https://docs.ethers.org/) ** - サーバーサイドスクリプトやボット向けにNode.jsでも動作します。 * **[Web3.py （新しいタブで開きます）](https://web3py.readthedocs.io/) ** - イーサリアムとやり取りするためのPythonライブラリ * **[go-ethereum （新しいタブで開きます）](https://geth.ethereum.org/docs/interact-with-geth) ** - Gethチームによる公式のGoライブラリ ### [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#example-viem) 例：Viemを使用したトークン残高の読み取り import { createPublicClient, http, formatUnits } from 'viem' import { mainnet } from 'viem/chains' // USDCのコントラクトアドレスとABI（balanceOf用の一部） const USDC = '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48' const abi = [{\ name: 'balanceOf',\ type: 'function',\ stateMutability: 'view',\ inputs: [{ name: 'account', type: 'address' }],\ outputs: [{ name: '', type: 'uint256' }],\ }] as const const client = createPublicClient({ chain: mainnet, transport: http() }) const balance = await client.readContract({ address: USDC, abi, functionName: 'balanceOf', args: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045'], // vitalik.eth }) console.log(formatUnits(balance, 6)) // USDCの小数点以下は6桁 コピーTS すべて表示 (23) ### [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#example-ethers) 例：ethers.jsを使用したトランザクションの送信 const { ethers } = require('ethers') const provider = new ethers.JsonRpcProvider(process.env.RPC_URL) const wallet = new ethers.Wallet(process.env.PRIVATE_KEY, provider) // ERC-20のtransferのABI const abi = ['function transfer(address to, uint256 amount) returns (bool)'] const contract = new ethers.Contract(tokenAddress, abi, wallet) const tx = await contract.transfer(recipient, ethers.parseUnits('10', 18)) await tx.wait() // トランザクションがマイニングされるのを待つ console.log(`Transferred! TX: ${tx.hash}`) コピーJS すべて表示 (12) [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#events-and-logs) イベントとログ ------------------------------------------------------------------------------------------------ スマート・コントラクトは、何かが起こったことを知らせるために**イベント**を発行できます。アプリケーションはこれらのイベントをリッスンして、リアルタイムで反応することができます。 import { createPublicClient, http, parseAbiItem } from 'viem' import { mainnet } from 'viem/chains' const client = createPublicClient({ chain: mainnet, transport: http() }) // USDCのTransferイベントを監視する const unwatch = client.watchEvent({ event: parseAbiItem('event Transfer(address indexed from, address indexed to, uint256 value)'), onLogs: (logs) => console.log(logs), }) コピーTS すべて表示 (10) [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#simulating) トランザクションのシミュレーション ----------------------------------------------------------------------------------------------------- トランザクションを送信する前に、それを**シミュレーション**して、ガスを消費することなく成功するかどうかを確認し、その戻り値を見ることができます。これは、エラーを早期に発見したり、結果をプレビューしたりするのに役立ちます。 ほとんどのクライアントライブラリは、`eth_call`を通じてこれをサポートしています。 // Viemを使用する場合 const result = await client.simulateContract({ address: contractAddress, abi, functionName: 'swap', args: [amountIn], account: userAddress, }) コピーTS [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#wallets-and-signing) ウォレットと署名 ----------------------------------------------------------------------------------------------------- 分散型アプリケーション (dapp) では、ユーザーのウォレット（メタマスク、Rainbow、WalletConnectなど）が署名を処理します。秘密鍵を直接管理することはありません。 [ウォレットライブラリと接続ツール](https://ethereum.org/ja/developers/docs/apis/javascript/) はこれを抽象化するため、アプリケーションロジックの構築に集中できます。 [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#related-tutorials) 関連チュートリアル ---------------------------------------------------------------------------------------------------- * [JavaScriptからスマート・コントラクトを呼び出す](https://ethereum.org/ja/developers/tutorials/calling-a-smart-contract-from-javascript/) * [Web3.jsとAlchemyを使用したトランザクションの送信](https://ethereum.org/ja/developers/tutorials/sending-transactions-using-web3-and-alchemy/) * [ウォレットでNFTを表示する方法](https://ethereum.org/ja/developers/tutorials/how-to-view-nft-in-metamask/) [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#further-reading) 参考文献 --------------------------------------------------------------------------------------------- * [Viemドキュメント：コントラクトへの読み取りと書き込み （新しいタブで開きます）](https://viem.sh/docs/contract/readContract) * [ethers.jsドキュメント：コントラクト （新しいタブで開きます）](https://docs.ethers.org/v6/api/contract/) * [Solidity ABI仕様 （新しいタブで開きます）](https://docs.soliditylang.org/en/latest/abi-spec.html) * [ABIとは何か？ - Alchemy （新しいタブで開きます）](https://www.alchemy.com/overviews/what-is-an-abi) [](https://ethereum.org/ja/developers/docs/smart-contracts/interacting/#related-topics) 関連トピック ---------------------------------------------------------------------------------------------- * [スマート・コントラクトのコンパイル](https://ethereum.org/ja/developers/docs/smart-contracts/compiling/) * [スマート・コントラクトのデプロイ](https://ethereum.org/ja/developers/docs/smart-contracts/deploying/) * [JavaScript API](https://ethereum.org/ja/developers/docs/apis/javascript/) * [バックエンドAPI](https://ethereum.org/ja/developers/docs/apis/backend/) --- # 재귀 길이 접두사(RLP) 직렬화 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/rlp/#main-content) Change page 재귀 길이 접두사(RLP) 직렬화 ================== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-structures-and-encoding/rlp/index.md) 이 페이지의 내용 재귀 길이 접두사(RLP) 직렬화는 이더리움의 실행 클라이언트에서 광범위하게 사용됩니다. RLP는 공간 효율적인 형식으로 노드 간 데이터 전송을 표준화합니다. RLP의 목적은 임의로 중첩된 이진 데이터 배열을 인코딩하는 것이며, 이더리움의 실행 계층에서 객체를 직렬화하는 데 사용되는 주요 인코딩 방법입니다. RLP의 주된 목적은 구조를 인코딩하는 것입니다. 양의 정수를 제외하고, RLP는 특정 데이터 유형(예: 문자열, 부동 소수점)의 인코딩을 상위 프로토콜에 위임합니다. 양의 정수는 선행 0이 없는 빅 엔디언 이진 형식으로 표현되어야 합니다(따라서 정수 값 0은 빈 바이트 배열과 동일해집니다). 선행 0이 있는 역직렬화된 양의 정수는 RLP를 사용하는 모든 상위 프로토콜에서 유효하지 않은 것으로 처리되어야 합니다. 자세한 정보는 [이더리움 황서(부록 B) (새 탭에서 열림)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19) 에서 확인할 수 있습니다. 딕셔너리를 인코딩하기 위해 RLP를 사용할 때 권장되는 두 가지 표준 형식은 다음과 같습니다. * 사전순으로 정렬된 키와 함께 `[[k1,v1],[k2,v2]...]` 사용 * [이더리움](https://ethereum.org/ko/) 과 같이 상위 수준의 패트리샤 트리(Patricia Tree) 인코딩 사용 [](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/rlp/#definition) 정의 ------------------------------------------------------------------------------------------- RLP 인코딩 함수는 항목(item)을 입력으로 받습니다. 항목은 다음과 같이 정의됩니다. * 문자열(즉, 바이트 배열)은 항목입니다. * 항목들의 목록은 항목입니다. * 양의 정수는 항목입니다. 예를 들어, 다음은 모두 항목입니다. * 빈 문자열 * "cat"이라는 단어가 포함된 문자열 * 임의의 개수의 문자열을 포함하는 목록 * `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`와 같은 더 복잡한 데이터 구조 * 숫자 `100` 이 페이지의 나머지 부분에서 '문자열'은 "특정 바이트 수의 이진 데이터"를 의미합니다. 특별한 인코딩은 사용되지 않으며, 문자열의 내용에 대한 어떠한 지식도 암시하지 않습니다(최소화되지 않은 양의 정수를 금지하는 규칙에서 요구하는 경우는 제외). RLP 인코딩은 다음과 같이 정의됩니다. * 양의 정수의 경우, 빅 엔디언으로 해석했을 때 해당 정수가 되는 가장 짧은 바이트 배열로 변환된 다음, 아래 규칙에 따라 문자열로 인코딩됩니다. * 값이 `[0x00, 0x7f]`(10진수 `[0, 127]`) 범위에 있는 단일 바이트의 경우, 해당 바이트 자체가 RLP 인코딩이 됩니다. * 그렇지 않고 문자열의 길이가 0~55바이트인 경우, RLP 인코딩은 값 **0x80**(10진수 128)에 문자열의 길이를 더한 단일 바이트와 그 뒤에 이어지는 문자열로 구성됩니다. 따라서 첫 번째 바이트의 범위는 `[0x80, 0xb7]`(10진수 `[128, 183]`)입니다. * 문자열의 길이가 55바이트를 초과하는 경우, RLP 인코딩은 값 **0xb7**(10진수 183)에 이진 형식으로 표현된 문자열 길이의 바이트 길이를 더한 단일 바이트, 문자열의 길이, 그리고 문자열 순으로 구성됩니다. 예를 들어, 1024바이트 길이의 문자열은 `\xb9\x04\x00`(10진수 `185, 4, 0`) 뒤에 문자열이 이어지는 형태로 인코딩됩니다. 여기서 첫 번째 바이트는 `0xb9`(183 + 2 = 185)이며, 그 뒤에 실제 문자열의 길이를 나타내는 2바이트 `0x0400`(10진수 1024)가 옵니다. 따라서 첫 번째 바이트의 범위는 `[0xb8, 0xbf]`(10진수 `[184, 191]`)입니다. * 문자열의 길이가 2^64바이트 이상인 경우 인코딩할 수 없습니다. * 목록의 전체 페이로드(즉, RLP 인코딩되는 모든 항목의 결합된 길이)가 0~55바이트인 경우, RLP 인코딩은 값 **0xc0**에 페이로드의 길이를 더한 단일 바이트와 그 뒤에 이어지는 항목들의 RLP 인코딩 연결로 구성됩니다. 따라서 첫 번째 바이트의 범위는 `[0xc0, 0xf7]`(10진수 `[192, 247]`)입니다. * 목록의 전체 페이로드가 55바이트를 초과하는 경우, RLP 인코딩은 값 **0xf7**에 이진 형식으로 표현된 페이로드 길이의 바이트 길이를 더한 단일 바이트, 페이로드의 길이, 그리고 항목들의 RLP 인코딩 연결 순으로 구성됩니다. 따라서 첫 번째 바이트의 범위는 `[0xf8, 0xff]`(10진수 `[248, 255]`)입니다. 간략히 요약하면 다음과 같습니다. | 범위 | 바이트 1 | 바이트 2 | ... | 바이트 9 | 바이트 10 | 의미 | | --- | --- | --- | --- | --- | --- | --- | | `0x00-0x7f` | `0ppppppp` | | | | | 단일 바이트 문자열 | | `0x80-0xb7` | `10nnnnnn` | `pppppppp` | `...` | | | 짧은 문자열(0~55바이트) | | `0xb8-0xbf` | `10111NNN` | `nnnnnnnn` | `...` | `nnnnnnnn`/`pppppppp` | `pppppppp` | 긴 문자열, 길이를 위한 N+1바이트 후 페이로드 | | `0xc0-0xf7` | `11nnnnnn` | `pppppppp` | `...` | | | 짧은 목록(0~55바이트) | | `0xf8-0xff` | `11111NNN` | `nnnnnnnn` | `...` | `nnnnnnnn`/`pppppppp` | `pppppppp` | 긴 목록, 길이를 위한 N+1바이트 후 페이로드 | * `p` = 페이로드 * `n` = 길이(페이로드 바이트 수) * `N` = 길이의 길이 오프셋(N+1개의 `n` 바이트가 이어짐) 코드로 표현하면 다음과 같습니다. def rlp_encode(input): if isinstance(input,str): if len(input) == 1 and ord(input) < 0x80: return input return encode_length(len(input), 0x80) + input elif isinstance(input, list): output = '' for item in input: output += rlp_encode(item) return encode_length(len(output), 0xc0) + output def encode_length(L, offset): if L < 56: return chr(L + offset) elif L < 256**8: BL = to_binary(L) return chr(len(BL) + offset + 55) + BL raise Exception("input too long") def to_binary(x): if x == 0: return '' return to_binary(int(x / 256)) + chr(x % 256) 복사Python 모두 보기 (23) [](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/rlp/#examples) 예시 ----------------------------------------------------------------------------------------- * 문자열 "dog" = \[ 0x83, 'd', 'o', 'g' \] * 목록 \[ "cat", "dog" \] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` * 빈 문자열('null') = `[ 0x80 ]` * 빈 목록 = `[ 0xc0 ]` * 정수 0 = `[ 0x80 ]` * 바이트 '\\x00' = `[ 0x00 ]` * 바이트 '\\x0f' = `[ 0x0f ]` * 바이트 '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]` * 3의 [집합론적 표현 (새 탭에서 열림)](https://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) , `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` * 문자열 "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` [](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/rlp/#rlp-decoding) RLP 디코딩 -------------------------------------------------------------------------------------------------- RLP 인코딩의 규칙과 과정에 따라, RLP 디코딩의 입력은 이진 데이터 배열로 간주됩니다. RLP 디코딩 과정은 다음과 같습니다. 1. 입력 데이터의 첫 번째 바이트(즉, 접두사)에 따라 데이터 유형, 실제 데이터의 길이 및 오프셋을 디코딩합니다. 2. 데이터의 유형과 오프셋에 따라 데이터를 상응하게 디코딩하며, 양의 정수에 대한 최소 인코딩 규칙을 준수합니다. 3. 입력의 나머지 부분을 계속해서 디코딩합니다. 이 중 데이터 유형 및 오프셋을 디코딩하는 규칙은 다음과 같습니다. 1. 첫 번째 바이트(즉, 접두사)의 범위가 \[0x00, 0x7f\]인 경우 데이터는 문자열이며, 문자열은 첫 번째 바이트 그 자체입니다. 2. 첫 번째 바이트의 범위가 \[0x80, 0xb7\]인 경우 데이터는 문자열이며, 첫 번째 바이트에서 0x80을 뺀 값과 길이가 같은 문자열이 첫 번째 바이트 뒤에 옵니다. 3. 첫 번째 바이트의 범위가 \[0xb8, 0xbf\]인 경우 데이터는 문자열이며, 첫 번째 바이트에서 0xb7을 뺀 값과 바이트 길이가 같은 문자열의 길이가 첫 번째 바이트 뒤에 오고, 그 뒤에 문자열이 옵니다. 4. 첫 번째 바이트의 범위가 \[0xc0, 0xf7\]인 경우 데이터는 목록이며, 첫 번째 바이트에서 0xc0을 뺀 값과 전체 페이로드가 같은 목록의 모든 항목에 대한 RLP 인코딩 연결이 첫 번째 바이트 뒤에 옵니다. 5. 첫 번째 바이트의 범위가 \[0xf8, 0xff\]인 경우 데이터는 목록이며, 첫 번째 바이트에서 0xf7을 뺀 값과 길이가 같은 목록의 전체 페이로드가 첫 번째 바이트 뒤에 오고, 그 뒤에 목록의 모든 항목에 대한 RLP 인코딩 연결이 옵니다. 코드로 표현하면 다음과 같습니다. def rlp_decode(input): if len(input) == 0: return output = '' (offset, dataLen, type) = decode_length(input) if type is str: output = instantiate_str(substr(input, offset, dataLen)) elif type is list: output = instantiate_list(substr(input, offset, dataLen)) output += rlp_decode(substr(input, offset + dataLen)) return output def decode_length(input): length = len(input) if length == 0: raise Exception("input is null") prefix = ord(input[0]) if prefix <= 0x7f: return (0, 1, str) elif prefix <= 0xb7 and length > prefix - 0x80: strLen = prefix - 0x80 return (1, strLen, str) elif prefix <= 0xbf and length > prefix - 0xb7 and length > prefix - 0xb7 + to_integer(substr(input, 1, prefix - 0xb7)): lenOfStrLen = prefix - 0xb7 strLen = to_integer(substr(input, 1, lenOfStrLen)) return (1 + lenOfStrLen, strLen, str) elif prefix <= 0xf7 and length > prefix - 0xc0: listLen = prefix - 0xc0; return (1, listLen, list) elif prefix <= 0xff and length > prefix - 0xf7 and length > prefix - 0xf7 + to_integer(substr(input, 1, prefix - 0xf7)): lenOfListLen = prefix - 0xf7 listLen = to_integer(substr(input, 1, lenOfListLen)) return (1 + lenOfListLen, listLen, list) raise Exception("input does not conform to RLP encoding form") def to_integer(b): length = len(b) if length == 0: raise Exception("input is null") elif length == 1: return ord(b[0]) return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256 복사Python 모두 보기 (42) [](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/rlp/#further-reading) 더 읽을거리 ---------------------------------------------------------------------------------------------------- * [이더리움의 RLP (새 탭에서 열림)](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) * [이더리움의 내부 동작 원리: RLP (새 탭에서 열림)](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) * [Coglio, A. (2020). ACL2에서의 이더리움 재귀 길이 접두사(Ethereum's Recursive Length Prefix in ACL2). arXiv preprint arXiv:2009.13769. (새 탭에서 열림)](https://arxiv.org/abs/2009.13769) [](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/rlp/#related-topics) 관련 주제 -------------------------------------------------------------------------------------------------- * [패트리샤 머클 트라이(Patricia merkle trie)](https://ethereum.org/ko/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) --- # 지분 증명 (PoS) | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#main-content) Change page 지분 증명 (PoS) =========== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/consensus-mechanisms/pos/index.md) 이 페이지의 내용 지분 증명 (PoS)은 이더리움의 [합의 메커니즘](https://ethereum.org/ko/developers/docs/consensus-mechanisms/) 의 기반이 됩니다. 이더리움은 이전의 [작업증명 (PoW)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/) 아키텍처에 비해 더 안전하고, 에너지 집약적이지 않으며, 새로운 확장성 솔루션을 구현하는 데 더 적합하기 때문에 2022년에 지분 증명 메커니즘으로 전환했습니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#prerequisites) 전제 조건 ----------------------------------------------------------------------------------------- 이 페이지를 더 잘 이해하려면 먼저 [합의 메커니즘](https://ethereum.org/ko/developers/docs/consensus-mechanisms/) 에 대해 읽어보는 것을 권장합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#what-is-pos) 지분 증명 (PoS)이란 무엇인가요? ------------------------------------------------------------------------------------------------------ 지분 증명은 검증자가 부정직하게 행동할 경우 파괴될 수 있는 가치 있는 것을 네트워크에 제공했음을 증명하는 방법입니다. [이더리움의](https://ethereum.org/ko/) 지분 증명에서 검증자는 이더리움의 스마트 컨트랙트에 ETH 형태로 자본을 명시적으로 스테이킹합니다. 그런 다음 검증자는 네트워크를 통해 전파되는 새로운 블록이 유효한지 확인하고, 때로는 스스로 새로운 블록을 생성하고 전파할 책임이 있습니다. 만약 이들이 네트워크를 속이려 한다면(예를 들어, 하나의 블록을 보내야 할 때 여러 블록을 제안하거나 상충되는 증명을 보내는 경우), 스테이킹한 ETH의 일부 또는 전부가 파괴될 수 있습니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#validators) 검증자 ------------------------------------------------------------------------------------ 검증자로 참여하려면 사용자는 예치 컨트랙트에 32 ETH를 예치하고 실행 클라이언트, 합의 클라이언트, 검증자 클라이언트라는 세 가지 개별 소프트웨어를 실행해야 합니다. ETH를 예치하면 사용자는 네트워크에 참여하는 새로운 검증자의 속도를 제한하는 활성화 대기열에 합류하게 됩니다. 활성화되면 검증자는 이더리움 네트워크의 피어로부터 새로운 블록을 받습니다. 블록에 전달된 트랜잭션은 이더리움의 상태에 대해 제안된 변경 사항이 유효한지 확인하기 위해 재실행되며, 블록 서명이 확인됩니다. 그런 다음 검증자는 네트워크 전체에 해당 블록을 지지하는 투표(증명이라고 함)를 보냅니다. 작업증명 (PoW)에서는 블록의 타이밍이 채굴 난이도에 의해 결정되는 반면, 지분 증명에서는 속도가 고정되어 있습니다. 지분 증명 이더리움의 시간은 슬롯(12초)과 에포크(32슬롯)로 나뉩니다. 매 슬롯마다 한 명의 검증자가 무작위로 블록 제안자로 선택됩니다. 이 검증자는 새로운 블록을 생성하고 네트워크의 다른 노드로 전송할 책임이 있습니다. 또한 매 슬롯마다 검증자 위원회가 무작위로 선택되며, 이들의 투표는 제안되는 블록의 유효성을 결정하는 데 사용됩니다. 검증자 세트를 위원회로 나누는 것은 네트워크 부하를 관리 가능한 수준으로 유지하는 데 중요합니다. 위원회는 모든 활성 검증자가 매 에포크마다 증명하지만 매 슬롯마다 증명하지는 않도록 검증자 세트를 나눕니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) 이더리움 PoS에서 트랜잭션이 실행되는 방법 --------------------------------------------------------------------------------------------------------------------------------- 다음은 이더리움 지분 증명에서 트랜잭션이 어떻게 실행되는지에 대한 엔드투엔드 설명입니다. 1. 사용자는 개인 키로 [트랜잭션](https://ethereum.org/ko/developers/docs/transactions/) 을 생성하고 서명합니다. 이는 일반적으로 지갑이나 [Ethers.js (새 탭에서 열림)](https://docs.ethers.org/v6/) , [web3js (새 탭에서 열림)](https://docs.web3js.org/) , [web3py (새 탭에서 열림)](https://web3py.readthedocs.io/en/v5/) 등과 같은 라이브러리에 의해 처리되지만, 내부적으로 사용자는 이더리움 [JSON-RPC API](https://ethereum.org/ko/developers/docs/apis/json-rpc/) 를 사용하여 노드에 요청을 보내는 것입니다. 사용자는 검증자가 트랜잭션을 블록에 포함하도록 장려하기 위해 팁으로 지불할 가스의 양을 정의합니다. [팁](https://ethereum.org/ko/developers/docs/gas/#priority-fee) 은 검증자에게 지급되는 반면 [기본 수수료](https://ethereum.org/ko/developers/docs/gas/#base-fee) 는 소각됩니다. 2. 트랜잭션은 이더리움 [실행 클라이언트](https://ethereum.org/ko/developers/docs/nodes-and-clients/#execution-client) 에 제출되어 유효성을 검증받습니다. 이는 발신자가 트랜잭션을 이행하기에 충분한 ETH를 가지고 있고 올바른 키로 서명했는지 확인하는 것을 의미합니다. 3. 트랜잭션이 유효한 경우, 실행 클라이언트는 이를 로컬 멤풀(대기 중인 트랜잭션 목록)에 추가하고 실행 계층 가십 네트워크를 통해 다른 노드에도 브로드캐스트합니다. 다른 노드들이 트랜잭션에 대해 듣게 되면 그들의 로컬 멤풀에도 이를 추가합니다. 고급 사용자는 트랜잭션을 브로드캐스트하는 것을 자제하고 대신 [Flashbots Auction (새 탭에서 열림)](https://docs.flashbots.net/flashbots-auction/overview) 과 같은 전문 블록 빌더에게 전달할 수 있습니다. 이를 통해 최대 수익([MEV](https://ethereum.org/ko/developers/docs/mev/#mev-extraction) )을 위해 다가오는 블록의 트랜잭션을 구성할 수 있습니다. 4. 네트워크의 검증자 노드 중 하나는 이전에 RANDAO를 사용하여 의사 난수로 선택된 현재 슬롯의 블록 제안자입니다. 이 노드는 이더리움 블록체인에 추가될 다음 블록을 구축 및 브로드캐스트하고 글로벌 상태를 업데이트할 책임이 있습니다. 노드는 실행 클라이언트, 합의 클라이언트, 검증자 클라이언트의 세 부분으로 구성됩니다. 실행 클라이언트는 로컬 멤풀의 트랜잭션을 "실행 페이로드"로 묶고 로컬에서 실행하여 상태 변경을 생성합니다. 이 정보는 합의 클라이언트로 전달되며, 여기서 실행 페이로드는 네트워크가 체인의 헤드에 있는 블록 시퀀스에 동의할 수 있도록 하는 보상, 페널티, 슬래싱, 증명 등에 대한 정보도 포함하는 "비콘 블록"의 일부로 래핑됩니다. 실행 클라이언트와 합의 클라이언트 간의 통신은 [합의 클라이언트와 실행 클라이언트 연결](https://ethereum.org/ko/developers/docs/networking-layer/#connecting-clients) 에 더 자세히 설명되어 있습니다. 5. 다른 노드들은 합의 레이어 가십 네트워크에서 새로운 비콘 블록을 받습니다. 이들은 이를 실행 클라이언트로 전달하여 제안된 상태 변경이 유효한지 확인하기 위해 트랜잭션을 로컬에서 재실행합니다. 그런 다음 검증자 클라이언트는 블록이 유효하며 체인에 대한 그들의 관점에서 논리적인 다음 블록임을 증명합니다(이는 [포크 선택 규칙](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#fork-choice) 에 정의된 대로 가장 큰 증명 가중치를 가진 체인을 기반으로 구축됨을 의미합니다). 블록은 이를 증명하는 각 노드의 로컬 데이터베이스에 추가됩니다. 6. 트랜잭션은 두 체크포인트 사이에 "절대다수 링크"가 있는 체인의 일부가 된 경우 "완결된" 것으로 간주될 수 있습니다. 체크포인트는 각 에포크의 시작 부분에서 발생하며, 각 슬롯에서는 활성 검증자의 하위 집합만 증명하지만 각 에포크에 걸쳐서는 모든 활성 검증자가 증명한다는 사실을 설명하기 위해 존재합니다. 따라서 에포크 사이에서만 '절대다수 링크'가 입증될 수 있습니다(이는 네트워크에 스테이킹된 총 ETH의 66%가 두 체크포인트에 동의하는 경우입니다). 완결성에 대한 자세한 내용은 아래에서 확인할 수 있습니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#finality) 완결성 ---------------------------------------------------------------------------------- 분산 네트워크에서 트랜잭션은 대량의 ETH가 소각되지 않고는 변경될 수 없는 블록의 일부일 때 "완결성"을 갖습니다. 지분 증명 이더리움에서는 "체크포인트" 블록을 사용하여 이를 관리합니다. 각 에포크의 첫 번째 블록이 체크포인트입니다. 검증자는 유효하다고 간주하는 체크포인트 쌍에 투표합니다. 체크포인트 쌍이 스테이킹된 총 ETH의 최소 3분의 2를 나타내는 투표를 끌어모으면 체크포인트가 업그레이드됩니다. 둘 중 더 최근의 것(대상)은 "정당화된" 상태가 됩니다. 둘 중 이전의 것은 이전 에포크에서 "대상"이었기 때문에 이미 정당화된 상태입니다. 이제 이것은 "완결된" 상태로 업그레이드됩니다. 체크포인트를 업그레이드하는 이 과정은 **[캐스퍼 FFG(Casper the Friendly Finality Gadget) (새 탭에서 열림)](https://arxiv.org/pdf/1710.09437) **에 의해 처리됩니다. 캐스퍼 FFG는 합의를 위한 블록 완결성 도구입니다. 블록이 완결되면 스테이커의 과반수 슬래싱 없이는 되돌리거나 변경할 수 없으므로 경제적으로 불가능해집니다. 완결된 블록을 되돌리려면 공격자는 스테이킹된 총 ETH 공급량의 최소 3분의 1을 잃을 각오를 해야 합니다. 이에 대한 정확한 이유는 이 [이더리움 재단 블로그 게시물 (새 탭에서 열림)](https://blog.ethereum.org/2016/05/09/on-settlement-finality) 에 설명되어 있습니다. 완결성에는 3분의 2 이상의 다수가 필요하므로 공격자는 총 스테이크의 3분의 1로 투표하여 네트워크가 완결성에 도달하는 것을 막을 수 있습니다. 이를 방어하기 위한 메커니즘이 있는데, 바로 [비활동 누수 (새 탭에서 열림)](https://eth2book.info/bellatrix/part2/incentives/inactivity) 입니다. 이는 체인이 4개 이상의 에포크 동안 완결되지 못할 때마다 활성화됩니다. 비활동 누수는 다수에 반대하여 투표하는 검증자로부터 스테이킹된 ETH를 서서히 빼앗아 다수가 3분의 2 이상의 다수를 되찾고 체인을 완결할 수 있도록 합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#crypto-economic-security) 암호경제학적 보안 -------------------------------------------------------------------------------------------------------- 검증자를 운영하는 것은 하나의 커밋먼트입니다. 검증자는 블록 검증 및 제안에 참여하기 위해 충분한 하드웨어와 연결성을 유지해야 합니다. 그 대가로 검증자는 ETH로 보상을 받습니다(스테이킹된 잔액이 증가함). 반면에 검증자로 참여하는 것은 사용자가 개인적인 이득이나 사보타주를 위해 네트워크를 공격할 수 있는 새로운 길을 열어주기도 합니다. 이를 방지하기 위해 검증자는 호출될 때 참여하지 않으면 ETH 보상을 놓치게 되며, 부정직하게 행동할 경우 기존 스테이크가 파괴될 수 있습니다. 단일 슬롯에서 여러 블록을 제안하는 것(모호성)과 모순되는 증명을 제출하는 것, 이 두 가지 주요 행동이 부정직한 것으로 간주될 수 있습니다. 슬래싱되는 ETH의 양은 거의 같은 시기에 얼마나 많은 검증자가 함께 슬래싱되는지에 따라 달라집니다. 이는 ["상관관계 페널티" (새 탭에서 열림)](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty) 로 알려져 있으며, 경미할 수도 있고(단일 검증자가 단독으로 슬래싱되는 경우 스테이크의 약 1%), 검증자의 스테이크가 100% 파괴되는 결과(대규모 슬래싱 이벤트)를 초래할 수도 있습니다. 이는 1일 차에 즉각적인 페널티(최대 1 ETH), 18일 차에 상관관계 페널티, 마지막으로 36일 차에 네트워크에서 퇴출되는 것으로 시작되는 강제 종료 기간의 중간에 부과됩니다. 이들은 네트워크에 존재하지만 투표를 제출하지 않기 때문에 매일 경미한 증명 페널티를 받습니다. 이 모든 것은 조직적인 공격이 공격자에게 매우 큰 비용을 초래할 것임을 의미합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#fork-choice) 포크 선택 --------------------------------------------------------------------------------------- 네트워크가 최적의 상태로 정직하게 수행될 때, 체인의 헤드에는 항상 하나의 새로운 블록만 존재하며 모든 검증자가 이를 증명합니다. 그러나 네트워크 지연이나 블록 제안자의 모호성으로 인해 검증자들이 체인의 헤드에 대해 서로 다른 관점을 가질 수 있습니다. 따라서 합의 클라이언트는 어느 것을 선호할지 결정하는 알고리즘이 필요합니다. 지분 증명 이더리움에서 사용되는 알고리즘은 [엘엠디 고스트(LMD-GHOST) (새 탭에서 열림)](https://arxiv.org/pdf/2003.03052.pdf) 라고 불리며, 역사상 가장 큰 증명 가중치를 가진 포크를 식별하는 방식으로 작동합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#pos-and-security) 지분 증명과 보안 ------------------------------------------------------------------------------------------------ [51% 공격 (새 탭에서 열림)](https://www.investopedia.com/terms/1/51-attack.asp) 의 위협은 작업증명 (PoW)과 마찬가지로 지분 증명에도 여전히 존재하지만, 공격자에게는 훨씬 더 위험합니다. 공격자는 스테이킹된 ETH의 51%가 필요합니다. 그런 다음 자신의 증명을 사용하여 선호하는 포크가 가장 많은 증명이 누적된 포크가 되도록 할 수 있습니다. 누적된 증명의 '가중치'는 합의 클라이언트가 올바른 체인을 결정하는 데 사용하는 것이므로, 이 공격자는 자신의 포크를 정식 포크로 만들 수 있습니다. 그러나 작업증명 (PoW)에 비해 지분 증명이 갖는 강점은 커뮤니티가 반격을 가하는 데 유연성을 갖는다는 것입니다. 예를 들어, 정직한 검증자들은 소수 체인에 계속 구축하고 공격자의 포크를 무시하기로 결정하는 동시에 앱, 거래소 및 풀도 동일하게 행동하도록 장려할 수 있습니다. 또한 공격자를 네트워크에서 강제로 제거하고 그들이 스테이킹한 ETH를 파괴하기로 결정할 수도 있습니다. 이는 51% 공격에 대한 강력한 경제적 방어 수단입니다. 51% 공격 외에도 악의적인 행위자는 다음과 같은 다른 유형의 악의적인 활동을 시도할 수 있습니다. * 장거리 공격 (완결성 가젯이 이 공격 벡터를 무력화하지만) * 단거리 '재구성(reorgs)' (제안자 부스팅 및 증명 마감일이 이를 완화하지만) * 바운싱 및 밸런싱 공격 (이 역시 제안자 부스팅에 의해 완화되며, 어쨌든 이러한 공격은 이상적인 네트워크 조건에서만 입증되었음) * 아발란체 공격 (최신 메시지만 고려하는 포크 선택 알고리즘 규칙에 의해 무력화됨) 전반적으로 이더리움에 구현된 지분 증명은 작업증명 (PoW)보다 경제적으로 더 안전한 것으로 입증되었습니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#pros-and-cons) 장단점 --------------------------------------------------------------------------------------- | 장점 | 단점 | | --- | --- | | 스테이킹은 개인이 네트워크 보안에 참여하기 쉽게 만들어 탈중앙화를 촉진합니다. 검증자 노드는 일반 노트북에서도 실행할 수 있습니다. 스테이킹 풀을 통해 사용자는 32 ETH가 없어도 스테이킹할 수 있습니다. | 지분 증명은 작업증명 (PoW)에 비해 역사가 짧고 실전 테스트를 덜 거쳤습니다. | | 스테이킹은 더 탈중앙화되어 있습니다. 규모의 경제가 PoW 채굴과 같은 방식으로 적용되지 않습니다. | 지분 증명은 작업증명 (PoW)보다 구현하기가 더 복잡합니다. | | 지분 증명은 작업증명 (PoW)보다 더 큰 암호경제학적 보안을 제공합니다. | 사용자는 이더리움의 지분 증명에 참여하기 위해 세 가지 소프트웨어를 실행해야 합니다. | | 네트워크 참여자에게 인센티브를 제공하기 위해 새로운 ETH 발행이 덜 필요합니다. | | ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#comparison-to-proof-of-work) 작업증명 (PoW)과의 비교 이더리움은 원래 작업증명 (PoW)을 사용했지만 2022년 9월에 지분 증명으로 전환했습니다. PoS는 PoW에 비해 다음과 같은 몇 가지 장점을 제공합니다. * 더 나은 에너지 효율성 – 작업증명 (PoW) 연산에 많은 에너지를 사용할 필요가 없습니다. * 진입 장벽이 낮아지고 하드웨어 요구 사항이 감소함 – 새로운 블록을 생성할 기회를 얻기 위해 최고급 하드웨어가 필요하지 않습니다. * 중앙화 위험 감소 – 지분 증명은 더 많은 노드가 네트워크를 보호하도록 이끌어야 합니다. * 에너지 요구량이 낮기 때문에 참여를 장려하기 위해 더 적은 ETH 발행이 필요합니다. * 잘못된 행동에 대한 경제적 페널티는 작업증명 (PoW)에 비해 공격자에게 51% 스타일 공격의 비용을 더 많이 들게 합니다. * 51% 공격이 암호경제학적 방어를 극복하더라도 커뮤니티는 정직한 체인의 소셜 복구에 의존할 수 있습니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#further-reading) 더 읽어보기 -------------------------------------------------------------------------------------------- * [지분 증명 FAQ (새 탭에서 열림)](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _비탈릭 부테린(Vitalik Buterin)_ * [지분 증명이란 무엇인가 (새 탭에서 열림)](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ * [지분 증명이란 무엇이며 왜 중요한가 (새 탭에서 열림)](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _비탈릭 부테린(Vitalik Buterin)_ * [왜 지분 증명인가 (2020년 11월) (새 탭에서 열림)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _비탈릭 부테린(Vitalik Buterin)_ * [지분 증명: 약한 주관성을 사랑하는 법을 배운 방법 (새 탭에서 열림)](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity) _비탈릭 부테린(Vitalik Buterin)_ * [지분 증명 이더리움 공격과 방어 (새 탭에서 열림)](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) * [지분 증명 설계 철학 (새 탭에서 열림)](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _비탈릭 부테린(Vitalik Buterin)_ * [비디오: 비탈릭 부테린이 렉스 프리드먼(Lex Fridman)에게 지분 증명을 설명하다 (새 탭에서 열림)](https://www.youtube.com/watch?v=3yrqBG-7EVE) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#related-topics) 관련 주제 ------------------------------------------------------------------------------------------ * [작업증명 (PoW)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/) * [권위 증명(PoA)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/poa/) --- # 이더리움에서의 인증 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#main-content) Change page 이더리움에서의 인증 ========== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/ethereum-stack/authentication/index.md) 이 페이지의 내용 전통적인 웹 개발에 익숙하다면 사용자 이름/비밀번호 로그인, OAuth 흐름, 세션 쿠키에 익숙할 것입니다. 이더리움에서의 인증은 다르게 작동하며, 여러 면에서 훨씬 더 간단합니다. 이더리움에서 사용자는 **지갑으로 메시지에 서명하기**를 통해 자신의 신원을 증명합니다. 저장할 비밀번호도 없고, 유출될 자격 증명 데이터베이스도 없습니다. 오직 암호학만이 존재합니다. [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#how-is-it-different) 웹2와 어떻게 다른가요? ------------------------------------------------------------------------------------------------------------ | 웹2 | 이더리움 | | --- | --- | | 사용자 이름 + 비밀번호 | 지갑 주소 + 서명 | | 서버가 자격 증명 저장 | 사용자가 개인 키 보유 | | 쿠키 / JWT로 세션 관리 | 오프체인 지갑 서명으로 세션 시작 | | "Google로 로그인" | "이더리움으로 로그인" | | 비밀번호 재설정 흐름 | 시드 구문 복구 | 근본적인 변화: 웹2에서는 중앙화된 서버가 사용자를 인증합니다. 이더리움에서는 특정 주소를 제어한다는 것을 증명함으로써 **스스로를 인증**하며, 누구나 이를 독립적으로 검증할 수 있습니다. [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#prerequisites) 전제 조건 ---------------------------------------------------------------------------------------------- 다음 내용을 이해하고 있는지 확인하세요. * [이더리움 계정 및 작동 방식](https://ethereum.org/ko/developers/docs/accounts/) * [지갑이란 무엇이며 어떻게 연결하는지](https://ethereum.org/ko/wallets/) * [공개 키-개인 키 암호학 기초](https://ethereum.org/ko/developers/docs/accounts/#externally-owned-accounts-and-key-pairs) [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#how-wallet-auth-works) 지갑 기반 인증 작동 방식 --------------------------------------------------------------------------------------------------------------- 핵심 흐름은 간단합니다. 1. **탈중앙화 애플리케이션 (dapp)이 사용자에게 지갑 연결을 요청합니다** (메타마스크, Rainbow, WalletConnect 등을 통해) 2. **지갑이 사용자의 이더리움 주소를 공유합니다** - 이것이 사용자의 공개 식별자입니다 3. **dapp이 고유한 메시지를 생성합니다** (논스 또는 챌린지) 4. **사용자가 개인 키로 메시지에 서명합니다** (지갑 내부에서 발생) 5. **백엔드가 주장된 주소에 대해 서명을 검증합니다** 6. **유효한 경우 사용자가 인증됩니다** 비밀번호는 입력되거나, 저장되거나, 전송되지 않았습니다. [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#sign-in-with-ethereum) 이더리움으로 로그인 (EIP-4361) ---------------------------------------------------------------------------------------------------------------------- [EIP-4361 (새 탭에서 열림)](https://eips.ethereum.org/EIPS/eip-4361) 은 일반적으로 **SIWE**(Sign-In with Ethereum)라고 불리는 이더리움 로그인을 위한 표준 메시지 형식을 정의합니다. 이는 임시방편적인 메시지 서명하기를 구조화되고 안전한 표준으로 대체합니다. SIWE 메시지는 다음과 같습니다. example.com wants you to sign in with your Ethereum account: 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B I accept the Terms of Service: https://example.com/tos URI: https://example.com/login Version: 1 Chain ID: 1 Nonce: 32891757 Issued At: 2024-06-12T14:30:00Z 복사YAML 모두 보기 (10) SIWE의 주요 특징: * **도메인 바인딩** - 메시지에 도메인이 포함되어 피싱을 방지합니다 * **체인 ID** - 서명이 유효한 네트워크를 지정합니다 * **논스** - 재전송 공격을 방지합니다 * **만료** - 유효 기간을 제한하는 선택적 타임스탬프입니다 * **리소스** - 범위가 지정된 액세스를 위한 선택적 URI입니다 ### [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#siwe-libraries) SIWE 라이브러리 * **[siwe (새 탭에서 열림)](https://github.com/spruceid/siwe) ** - Spruce의 공식 TypeScript 구현체 * **[siwe-rs (새 탭에서 열림)](https://github.com/spruceid/siwe-rs) ** - Rust 구현체 * **[siwe-go (새 탭에서 열림)](https://github.com/spruceid/siwe-go) ** - Go 구현체 ### [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#example-siwe-client) 예시: siwe를 사용한 클라이언트 측 로그인 import { SiweMessage } from 'siwe' import { BrowserProvider } from 'ethers' async function signIn() { const provider = new BrowserProvider(window.ethereum) const signer = await provider.getSigner() const address = await signer.getAddress() // 1. 백엔드에서 논스 가져오기 const { nonce } = await fetch('/api/auth/nonce').then(r => r.json()) // 2. SIWE 메시지 생성 및 서명 const message = new SiweMessage({ domain: window.location.host, address, statement: 'Sign in to My Dapp', uri: window.location.origin, version: '1', chainId: 1, nonce, }) const signature = await signer.signMessage(message.prepareMessage()) // 3. 검증을 위해 백엔드로 전송 await fetch('/api/auth/verify', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ message, signature }), }) } 복사TS 모두 보기 (31) ### [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#example-siwe-server) 예시: 서버 측 검증 (Node.js) import { SiweMessage, generateNonce } from 'siwe' // 논스를 발급하고 나중에 /verify에서 확인할 수 있도록 세션에 저장합니다 app.get('/api/auth/nonce', (req, res) => { req.session.nonce = generateNonce() res.json({ nonce: req.session.nonce }) }) app.post('/api/auth/verify', async (req, res) => { try { const { message, signature } = req.body const siweMessage = new SiweMessage(message) const { success, data } = await siweMessage.verify({ signature, nonce: req.session.nonce, }) if (success) { // data.address는 검증된 이더리움 주소입니다 // 사용자를 위한 세션 또는 JWT를 생성합니다 req.session.address = data.address res.json({ ok: true, address: data.address }) } } catch { res.status(401).json({ error: 'Invalid signature' }) } }) 복사TS 모두 보기 (28) [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#wallet-connection-libraries) 지갑 연결 라이브러리 ------------------------------------------------------------------------------------------------------------------ 인증하기 전에 사용자가 지갑을 연결해야 합니다. 다음 라이브러리들을 사용하면 쉽게 구현할 수 있습니다. * **[RainbowKit (새 탭에서 열림)](https://www.rainbowkit.com/) ** - 아름다운 UI를 갖춘 바로 사용 가능한 React 컴포넌트 * **[ConnectKit (새 탭에서 열림)](https://docs.family.co/connectkit) ** - 드롭인(Drop-in) 지갑 연결 모달 * **[AppKit (WalletConnect) (새 탭에서 열림)](https://reown.com/appkit) ** - SIWE가 내장된 멀티체인 지갑 연결 * **[Wagmi (새 탭에서 열림)](https://wagmi.sh/) ** - `useAccount`, `useConnect`를 제공하는 React 훅(Hooks) 라이브러리 [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#verifying-manually) 수동으로 서명 검증하기 ---------------------------------------------------------------------------------------------------------- SIWE를 사용하지 않으려면 서명을 직접 검증할 수 있습니다. import { verifyMessage } from 'ethers' // 사용자가 서명한 메시지 const message = `Sign in to My Dapp. Nonce: ${storedNonce}` // 서명에서 서명자의 주소를 복구합니다 const recoveredAddress = verifyMessage(message, signature) // 주장하는 주소와 비교합니다 if (recoveredAddress.toLowerCase() === claimedAddress.toLowerCase()) { // 인증 성공 } 복사TS 모두 보기 (12) ### [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#security-notes) 중요 보안 참고 사항 * **항상 논스를 사용하세요** - 오래된 서명이 재사용되는 재전송 공격을 방지합니다 * **도메인을 포함하세요** - 서명이 다른 사이트에서 유효하게 사용되는 것을 방지합니다 * **만료를 확인하세요** - 서명은 제한된 유효 기간을 가져야 합니다 * **가능한 경우 SIWE(EIP-4361)를 사용하세요** - 위의 모든 사항을 대신 처리해 줍니다 * **개인 키를 절대 노출하지 마세요** - 서명은 지갑 내부에서 이루어지며, 앱은 결과만 확인합니다 [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#session-management) 세션 관리 --------------------------------------------------------------------------------------------------- 인증이 완료된 후에도 웹2와 마찬가지로 세션이 필요합니다. 일반적인 패턴은 다음과 같습니다. * **JWT 토큰** - 서명을 검증한 후 JWT를 발급하여 API 요청에 사용합니다 * **서버 측 세션** - 검증된 주소를 세션 쿠키에 저장합니다 * **리소스를 포함한 SIWE** - 특정 URI에 연결된 범위가 지정된 액세스 토큰을 정의합니다 웹2와의 주요 차이점: 사용자의 이더리움 주소가 영구적인 신원이라는 점입니다. 사용자는 새 계정을 만들지 않고도 모든 dapp에서 이를 사용할 수 있습니다. [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#decentralized-identity) 탈중앙화 신원증명 (DID) ----------------------------------------------------------------------------------------------------------------- 이더리움 인증은 \*\*자기 주권 신원(self-sovereign identity)\*\*을 향한 더 광범위한 움직임의 일부입니다. 이 분야의 표준 및 프로젝트는 다음과 같습니다. * **[이더리움 네임 서비스 (ENS) (새 탭에서 열림)](https://ens.domains/) ** - 주소로 확인되는 사람이 읽을 수 있는 이름 (예: `vitalik.eth`) * **[이더리움 증명 서비스 (EAS) (새 탭에서 열림)](https://attest.org/) ** - 신원 및 자격 증명에 대한 온체인 증명 * **[W3C 탈중앙화 식별자 (DID) (새 탭에서 열림)](https://www.w3.org/TR/did-core/) ** - 검증 가능한 탈중앙화 신원증명 (DID)을 위한 글로벌 표준 * **[Ceramic 네트워크 (새 탭에서 열림)](https://ceramic.network/) ** - DID에 연결된 탈중앙화된 데이터 스트림 [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#further-reading) 더 읽어보기 ------------------------------------------------------------------------------------------------- * [EIP-4361: 이더리움으로 로그인 (새 탭에서 열림)](https://eips.ethereum.org/EIPS/eip-4361) * [SIWE 문서 (새 탭에서 열림)](https://docs.login.xyz/) * [Auth0에서의 이더리움으로 로그인 (새 탭에서 열림)](https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/) * [Reown AppKit 인증 문서 (새 탭에서 열림)](https://docs.reown.com/appkit/authentication) * [ENS 문서 (새 탭에서 열림)](https://docs.ens.domains/) [](https://ethereum.org/ko/developers/docs/ethereum-stack/authentication/#related-topics) 관련 주제 ----------------------------------------------------------------------------------------------- * [이더리움 계정](https://ethereum.org/ko/developers/docs/accounts/) * [JavaScript API 라이브러리](https://ethereum.org/ko/developers/docs/apis/javascript/) * [백엔드 API 라이브러리](https://ethereum.org/ko/developers/docs/apis/backend/) * [지갑](https://ethereum.org/ko/wallets/) --- # 스마트 컨트랙트 업그레이드 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/smart-contracts/upgrading/#main-content) Change page 스마트 컨트랙트 업그레이드 ============== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/upgrading/index.md) 이 페이지의 내용 이더리움의 스마트 컨트랙트는 이더리움 가상 머신(EVM)에서 실행되는 자동 실행 프로그램입니다. 이 프로그램들은 설계상 불변이므로, 컨트랙트가 배포된 후에는 비즈니스 로직을 업데이트할 수 없습니다. 불변성은 스마트 컨트랙트의 무신뢰성, 탈중앙화 및 보안에 필수적이지만, 특정 경우에는 단점이 될 수 있습니다. 예를 들어, 불변 코드는 개발자가 취약한 컨트랙트를 수정하는 것을 불가능하게 만들 수 있습니다. 그러나 스마트 컨트랙트 개선에 대한 연구가 증가함에 따라 여러 업그레이드 패턴이 도입되었습니다. 이러한 업그레이드 패턴을 통해 개발자는 비즈니스 로직을 다른 컨트랙트에 배치하여 (불변성을 유지하면서) 스마트 컨트랙트를 업그레이드할 수 있습니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/upgrading/#prerequisites) 전제 조건 ------------------------------------------------------------------------------------------ [스마트 컨트랙트](https://ethereum.org/ko/developers/docs/smart-contracts/) , [스마트 컨트랙트 구조](https://ethereum.org/ko/developers/docs/smart-contracts/anatomy/) 및 [이더리움 가상 머신(EVM)](https://ethereum.org/ko/developers/docs/evm/) 에 대해 잘 이해하고 있어야 합니다. 또한 이 가이드는 독자가 스마트 컨트랙트 프로그래밍에 대한 지식이 있다고 가정합니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/upgrading/#what-is-a-smart-contract-upgrade) 스마트 컨트랙트 업그레이드란 무엇인가요? ------------------------------------------------------------------------------------------------------------------------------ 스마트 컨트랙트 업그레이드는 컨트랙트의 상태를 유지하면서 스마트 컨트랙트의 비즈니스 로직을 변경하는 것을 포함합니다. 특히 스마트 컨트랙트의 맥락에서 업그레이드 가능성과 가변성이 동일하지 않다는 점을 명확히 하는 것이 중요합니다. 이더리움 네트워크의 주소에 배포된 프로그램은 여전히 변경할 수 없습니다. 하지만 사용자가 스마트 컨트랙트와 상호 작용할 때 실행되는 코드는 변경할 수 있습니다. 이는 다음 방법을 통해 수행할 수 있습니다. 1. 스마트 컨트랙트의 여러 버전을 생성하고 이전 컨트랙트에서 컨트랙트의 새 인스턴스로 상태(즉, 데이터)를 마이그레이션합니다. 2. 비즈니스 로직과 상태를 저장하기 위해 별도의 컨트랙트를 생성합니다. 3. 프록시 패턴을 사용하여 불변 프록시 컨트랙트에서 수정 가능한 로직 컨트랙트로 함수 호출을 위임합니다. 4. 특정 함수를 실행하기 위해 유연한 위성 컨트랙트와 인터페이스하고 이에 의존하는 불변 메인 컨트랙트를 생성합니다. 5. 다이아몬드 패턴을 사용하여 프록시 컨트랙트에서 로직 컨트랙트로 함수 호출을 위임합니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/upgrading/#contract-migration) 업그레이드 메커니즘 #1: 컨트랙트 마이그레이션 컨트랙트 마이그레이션은 동일한 소프트웨어의 고유한 상태를 생성하고 관리한다는 개념인 버전 관리를 기반으로 합니다. 컨트랙트 마이그레이션은 기존 스마트 컨트랙트의 새 인스턴스를 배포하고 스토리지와 잔액을 새 컨트랙트로 전송하는 것을 포함합니다. 새로 배포된 컨트랙트는 빈 스토리지를 가지므로 이전 컨트랙트에서 데이터를 복구하여 새 구현에 쓸 수 있습니다. 그 후에는 이전 컨트랙트와 상호 작용했던 모든 컨트랙트를 업데이트하여 새 주소를 반영해야 합니다. 컨트랙트 마이그레이션의 마지막 단계는 사용자가 새 컨트랙트를 사용하도록 설득하는 것입니다. 새 컨트랙트 버전은 사용자 잔액과 주소를 유지하여 불변성을 보존합니다. 토큰 기반 컨트랙트인 경우 거래소에 연락하여 이전 컨트랙트를 폐기하고 새 컨트랙트를 사용하도록 해야 합니다. 컨트랙트 마이그레이션은 사용자 상호 작용을 중단하지 않고 스마트 컨트랙트를 업그레이드하기 위한 비교적 간단하고 안전한 조치입니다. 그러나 사용자 스토리지와 잔액을 새 컨트랙트로 수동으로 마이그레이션하는 것은 시간이 많이 걸리고 높은 가스 비용이 발생할 수 있습니다. [컨트랙트 마이그레이션에 대해 자세히 알아보기 (새 탭에서 열림)](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) ### [](https://ethereum.org/ko/developers/docs/smart-contracts/upgrading/#data-separation) 업그레이드 메커니즘 #2: 데이터 분리 스마트 컨트랙트를 업그레이드하는 또 다른 방법은 비즈니스 로직과 데이터 스토리지를 별도의 컨트랙트로 분리하는 것입니다. 이는 사용자가 로직 컨트랙트와 상호 작용하는 동안 데이터는 스토리지 컨트랙트에 저장됨을 의미합니다. 로직 컨트랙트에는 사용자가 애플리케이션과 상호 작용할 때 실행되는 코드가 포함되어 있습니다. 또한 스토리지 컨트랙트의 주소를 보유하고 이와 상호 작용하여 데이터를 가져오고 설정합니다. 한편, 스토리지 컨트랙트는 사용자 잔액 및 주소와 같은 스마트 컨트랙트와 관련된 상태를 보유합니다. 스토리지 컨트랙트는 로직 컨트랙트가 소유하며 배포 시 후자의 주소로 구성된다는 점에 유의하세요. 이렇게 하면 승인되지 않은 컨트랙트가 스토리지 컨트랙트를 호출하거나 데이터를 업데이트하는 것을 방지할 수 있습니다. 기본적으로 스토리지 컨트랙트는 불변이지만, 가리키는 로직 컨트랙트를 새 구현으로 교체할 수 있습니다. 이렇게 하면 스토리지와 잔액을 그대로 유지하면서 EVM에서 실행되는 코드가 변경됩니다. 이 업그레이드 방법을 사용하려면 스토리지 컨트랙트에서 로직 컨트랙트의 주소를 업데이트해야 합니다. 앞서 설명한 이유로 새 로직 컨트랙트를 스토리지 컨트랙트의 주소로 구성해야 합니다. 데이터 분리 패턴은 컨트랙트 마이그레이션에 비해 구현하기가 더 쉽다고 할 수 있습니다. 그러나 악의적인 업그레이드로부터 스마트 컨트랙트를 보호하려면 여러 컨트랙트를 관리하고 복잡한 권한 부여 체계를 구현해야 합니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/upgrading/#proxy-patterns) 업그레이드 메커니즘 #3: 프록시 패턴 프록시 패턴은 또한 데이터 분리를 사용하여 비즈니스 로직과 데이터를 별도의 컨트랙트에 유지합니다. 그러나 프록시 패턴에서는 스토리지 컨트랙트(프록시라고 함)가 코드 실행 중에 로직 컨트랙트를 호출합니다. 이는 로직 컨트랙트가 스토리지 컨트랙트를 호출하는 데이터 분리 방법의 반대입니다. 프록시 패턴에서 일어나는 일은 다음과 같습니다. 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`가 값을 변경하지 않는다는 점을 제외하면 메시지 호출과 동일합니다._ _이는 컨트랙트가 런타임에 다른 주소에서 코드를 동적으로 로드할 수 있음을 의미합니다. 스토리지, 현재 주소 및 잔액은 여전히 호출하는 컨트랙트를 참조하며 코드만 호출된 주소에서 가져옵니다._ 프록시 컨트랙트에는 `fallback` 함수가 내장되어 있기 때문에 사용자가 함수를 호출할 때마다 `delegatecall`를 호출해야 한다는 것을 알고 있습니다. Solidity 프로그래밍에서 [폴백 함수 (새 탭에서 열림)](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) 는 함수 호출이 컨트랙트에 지정된 함수와 일치하지 않을 때 실행됩니다. 프록시 패턴이 작동하도록 하려면 프록시 컨트랙트가 지원하지 않는 함수 호출을 처리하는 방법을 지정하는 사용자 지정 폴백 함수를 작성해야 합니다. 이 경우 프록시의 폴백 함수는 delegatecall을 시작하고 사용자의 요청을 현재 로직 컨트랙트 구현으로 다시 라우팅하도록 프로그래밍됩니다. 프록시 컨트랙트는 기본적으로 불변이지만 업데이트된 비즈니스 로직이 있는 새 로직 컨트랙트를 생성할 수 있습니다. 그런 다음 업그레이드를 수행하는 것은 프록시 컨트랙트에서 참조되는 로직 컨트랙트의 주소를 변경하는 문제입니다. 프록시 컨트랙트가 새 로직 컨트랙트를 가리키도록 하면 사용자가 프록시 컨트랙트 함수를 호출할 때 실행되는 코드가 변경됩니다. 이를 통해 사용자에게 새 컨트랙트와 상호 작용하도록 요청하지 않고도 컨트랙트의 로직을 업그레이드할 수 있습니다. 프록시 패턴은 컨트랙트 마이그레이션과 관련된 어려움을 제거하기 때문에 스마트 컨트랙트를 업그레이드하는 데 널리 사용되는 방법입니다. 그러나 프록시 패턴은 사용하기가 더 복잡하며 부적절하게 사용할 경우 [함수 선택자 충돌(function selector clashes) (새 탭에서 열림)](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357) 과 같은 치명적인 결함을 유발할 수 있습니다. [프록시 패턴에 대해 자세히 알아보기 (새 탭에서 열림)](https://blog.openzeppelin.com/proxy-patterns/) . ### [](https://ethereum.org/ko/developers/docs/smart-contracts/upgrading/#strategy-pattern) 업그레이드 메커니즘 #4: 전략 패턴 이 기술은 특정 기능을 구현하기 위해 다른 프로그램과 인터페이스하는 소프트웨어 프로그램을 생성하도록 권장하는 [전략 패턴 (새 탭에서 열림)](https://en.wikipedia.org/wiki/Strategy_pattern) 의 영향을 받았습니다. 이더리움 개발에 전략 패턴을 적용한다는 것은 다른 컨트랙트의 함수를 호출하는 스마트 컨트랙트를 구축하는 것을 의미합니다. 이 경우 메인 컨트랙트에는 핵심 비즈니스 로직이 포함되어 있지만 특정 함수를 실행하기 위해 다른 스마트 컨트랙트("위성 컨트랙트")와 인터페이스합니다. 이 메인 컨트랙트는 또한 각 위성 컨트랙트의 주소를 저장하고 위성 컨트랙트의 다른 구현 간에 전환할 수 있습니다. 새 위성 컨트랙트를 구축하고 새 주소로 메인 컨트랙트를 구성할 수 있습니다. 이를 통해 스마트 컨트랙트의 _전략_(즉, 새 로직 구현)을 변경할 수 있습니다. 앞서 논의한 프록시 패턴과 유사하지만, 사용자가 상호 작용하는 메인 컨트랙트가 비즈니스 로직을 보유한다는 점에서 전략 패턴은 다릅니다. 이 패턴을 사용하면 핵심 인프라에 영향을 주지 않고 스마트 컨트랙트에 제한적인 변경 사항을 도입할 수 있는 기회를 얻을 수 있습니다. 주요 단점은 이 패턴이 주로 사소한 업그레이드를 출시하는 데 유용하다는 것입니다. 또한 메인 컨트랙트가 손상된 경우(예: 해킹을 통해) 이 업그레이드 방법을 사용할 수 없습니다. ### [](https://ethereum.org/ko/developers/docs/smart-contracts/upgrading/#diamond-pattern) 업그레이드 메커니즘 #5: 다이아몬드 패턴 다이아몬드 패턴은 프록시 패턴의 개선으로 간주될 수 있습니다. 다이아몬드 프록시 컨트랙트는 둘 이상의 로직 컨트랙트에 함수 호출을 위임할 수 있기 때문에 다이아몬드 패턴은 프록시 패턴과 다릅니다. 다이아몬드 패턴의 로직 컨트랙트는 _패싯(facets)_이라고 합니다. 다이아몬드 패턴이 작동하도록 하려면 프록시 컨트랙트에서 [함수 선택자 (새 탭에서 열림)](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) 를 다른 패싯 주소에 매핑하는 매핑을 생성해야 합니다. 사용자가 함수 호출을 수행하면 프록시 컨트랙트는 매핑을 확인하여 해당 함수 실행을 담당하는 패싯을 찾습니다. 그런 다음 (폴백 함수를 사용하여) `delegatecall`를 호출하고 호출을 적절한 로직 컨트랙트로 리디렉션합니다. 다이아몬드 업그레이드 패턴은 기존 프록시 업그레이드 패턴에 비해 몇 가지 장점이 있습니다. 1. 모든 코드를 변경하지 않고도 컨트랙트의 작은 부분을 업그레이드할 수 있습니다. 업그레이드에 프록시 패턴을 사용하려면 사소한 업그레이드라도 완전히 새로운 로직 컨트랙트를 생성해야 합니다. 2. 모든 스마트 컨트랙트(프록시 패턴에 사용되는 로직 컨트랙트 포함)에는 24KB 크기 제한이 있으며, 이는 특히 더 많은 함수가 필요한 복잡한 컨트랙트의 경우 제한이 될 수 있습니다. 다이아몬드 패턴은 여러 로직 컨트랙트에 함수를 분할하여 이 문제를 쉽게 해결할 수 있도록 합니다. 3. 프록시 패턴은 접근 제어에 포괄적인(catch-all) 접근 방식을 채택합니다. 업그레이드 함수에 접근할 수 있는 엔티티는 컨트랙트 _전체_를 변경할 수 있습니다. 그러나 다이아몬드 패턴은 모듈식 권한 접근 방식을 가능하게 하여 엔티티가 스마트 컨트랙트 내의 특정 함수만 업그레이드하도록 제한할 수 있습니다. [다이아몬드 패턴에 대해 자세히 알아보기 (새 탭에서 열림)](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w) . [](https://ethereum.org/ko/developers/docs/smart-contracts/upgrading/#pros-and-cons-of-upgrading-smart-contracts) 스마트 컨트랙트 업그레이드의 장단점 ------------------------------------------------------------------------------------------------------------------------------------- | 장점 | 단점 | | --- | --- | | 스마트 컨트랙트 업그레이드를 통해 배포 후 단계에서 발견된 취약점을 더 쉽게 수정할 수 있습니다. | 스마트 컨트랙트를 업그레이드하면 코드 불변성이라는 개념이 무효화되며, 이는 탈중앙화 및 보안에 영향을 미칩니다. | | 개발자는 로직 업그레이드를 사용하여 탈중앙화 애플리케이션(dapp)에 새로운 기능을 추가할 수 있습니다. | 사용자는 개발자가 스마트 컨트랙트를 임의로 수정하지 않을 것이라고 신뢰해야 합니다. | | 버그를 신속하게 수정할 수 있으므로 스마트 컨트랙트 업그레이드는 최종 사용자의 안전을 향상시킬 수 있습니다. | 스마트 컨트랙트에 업그레이드 기능을 프로그래밍하면 복잡성이 한층 더해지고 치명적인 결함의 가능성이 높아집니다. | | 컨트랙트 업그레이드는 개발자에게 다양한 기능을 실험하고 시간이 지남에 따라 디앱을 개선할 수 있는 더 많은 여지를 제공합니다. | 스마트 컨트랙트를 업그레이드할 수 있는 기회는 개발자가 개발 단계에서 실사를 수행하지 않고 프로젝트를 더 빨리 시작하도록 부추길 수 있습니다. | | | 스마트 컨트랙트의 안전하지 않은 접근 제어 또는 중앙화는 악의적인 행위자가 승인되지 않은 업그레이드를 더 쉽게 수행하도록 만들 수 있습니다. | [](https://ethereum.org/ko/developers/docs/smart-contracts/upgrading/#considerations-for-upgrading-smart-contracts) 스마트 컨트랙트 업그레이드 시 고려 사항 ------------------------------------------------------------------------------------------------------------------------------------------ 1. 특히 프록시 패턴, 전략 패턴 또는 데이터 분리를 사용하는 경우 승인되지 않은 스마트 컨트랙트 업그레이드를 방지하기 위해 안전한 접근 제어/권한 부여 메커니즘을 사용하세요. 컨트랙트의 소유자만 호출할 수 있도록 업그레이드 함수에 대한 접근을 제한하는 것이 그 예입니다. 2. 스마트 컨트랙트 업그레이드는 복잡한 활동이며 취약점 도입을 방지하기 위해 높은 수준의 주의가 필요합니다. 3. 업그레이드 구현 프로세스를 탈중앙화하여 신뢰 가정을 줄이세요. 가능한 전략으로는 업그레이드를 제어하기 위해 [다중 서명 지갑 컨트랙트](https://ethereum.org/ko/developers/docs/smart-contracts/#multisig) 를 사용하거나 [DAO 구성원](https://ethereum.org/ko/dao/) 이 업그레이드 승인에 투표하도록 요구하는 것이 있습니다. 4. 컨트랙트 업그레이드와 관련된 비용에 유의하세요. 예를 들어, 컨트랙트 마이그레이션 중에 이전 컨트랙트에서 새 컨트랙트로 상태(예: 사용자 잔액)를 복사하려면 둘 이상의 트랜잭션이 필요할 수 있으며, 이는 더 많은 가스 수수료를 의미합니다. 5. 사용자를 보호하기 위해 **타임락(timelocks)** 구현을 고려하세요. 타임락은 시스템 변경에 적용되는 지연을 의미합니다. 타임락은 다중 서명 거버넌스 시스템과 결합하여 업그레이드를 제어할 수 있습니다. 제안된 작업이 필요한 승인 임계값에 도달하더라도 미리 정의된 지연 기간이 경과할 때까지 실행되지 않습니다. 타임락은 제안된 변경 사항(예: 로직 업그레이드 또는 새로운 수수료 체계)에 동의하지 않는 경우 사용자가 시스템을 종료할 수 있는 시간을 제공합니다. 타임락이 없으면 사용자는 개발자가 사전 통지 없이 스마트 컨트랙트에 임의의 변경 사항을 구현하지 않을 것이라고 신뢰해야 합니다. 여기서 단점은 타임락이 취약점을 신속하게 패치하는 능력을 제한한다는 것입니다. [](https://ethereum.org/ko/developers/docs/smart-contracts/upgrading/#resources) 리소스 ------------------------------------------------------------------------------------ **오픈제플린 업그레이드 플러그인(OpenZeppelin Upgrades Plugins) - _업그레이드 가능한 스마트 컨트랙트를 배포하고 보호하기 위한 도구 모음입니다._** * [GitHub (새 탭에서 열림)](https://github.com/OpenZeppelin/openzeppelin-upgrades) * [문서 (새 탭에서 열림)](https://docs.openzeppelin.com/upgrades) [](https://ethereum.org/ko/developers/docs/smart-contracts/upgrading/#tutorials) 튜토리얼 ------------------------------------------------------------------------------------- * Patrick Collins의 [스마트 컨트랙트 업그레이드 | 유튜브 튜토리얼 (새 탭에서 열림)](https://www.youtube.com/watch?v=bdXJmWajZRY) * Austin Griffith의 [이더리움 스마트 컨트랙트 마이그레이션 튜토리얼 (새 탭에서 열림)](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) * Pranesh A.S의 [UUPS 프록시 패턴을 사용하여 스마트 컨트랙트 업그레이드하기 (새 탭에서 열림)](https://blog.logrocket.com/author/praneshas/) * fangjun.eth의 [Web3 튜토리얼: 오픈제플린을 사용하여 업그레이드 가능한 스마트 컨트랙트(프록시) 작성하기 (새 탭에서 열림)](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) [](https://ethereum.org/ko/developers/docs/smart-contracts/upgrading/#further-reading) 더 읽어보기 --------------------------------------------------------------------------------------------- * Santiago Palladino의 [스마트 컨트랙트 업그레이드의 상태 (새 탭에서 열림)](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) * Crypto Market Pool 블로그의 [Solidity 스마트 컨트랙트를 업그레이드하는 여러 가지 방법 (새 탭에서 열림)](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) * 오픈제플린 문서의 [학습: 스마트 컨트랙트 업그레이드 (새 탭에서 열림)](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) * Naveen Sahu의 [Solidity 컨트랙트의 업그레이드 가능성을 위한 프록시 패턴: Transparent vs UUPS 프록시 (새 탭에서 열림)](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) * Nick Mudge의 [다이아몬드 업그레이드 작동 방식 (새 탭에서 열림)](https://dev.to/mudgen/how-diamond-upgrades-work-417j) --- # ブロック・エクスプローラー | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#main-content) Change page ブロック・エクスプローラー ============= .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-and-analytics/block-explorers/index.md) このページの内容 ブロック・エクスプローラーは、イーサリアムのデータへのポータルです。これらを使用して、ブロック、トランザクション、バリデータ、アカウント、およびその他のオンチェーン・アクティビティに関するリアルタイムのデータを確認できます。 [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#prerequisites) 前提条件 -------------------------------------------------------------------------------------------------- ブロック・エクスプローラーが提供するデータを理解できるように、イーサリアムの基本概念を理解しておく必要があります。[イーサリアムの紹介](https://ethereum.org/ja/developers/docs/intro-to-ethereum/) から始めてください。 [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#open-source-tools) オープンソースツール ------------------------------------------------------------------------------------------------------------ * [3xpl （新しいタブで開きます）](https://3xpl.com/ethereum) - データセットのダウンロードが可能な、広告なしのイーサリアム・エクスプローラー (オープンコア: コアモジュールはオープンソース) * [Beaconcha.in （新しいタブで開きます）](https://beaconcha.in/) * [Blockscout （新しいタブで開きます）](https://eth.blockscout.com/) * [lazy-etherscan （新しいタブで開きます）](https://github.com/woxjro/lazy-etherscan) * [Otterscan （新しいタブで開きます）](https://otterscan.io/) [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#services) サービス --------------------------------------------------------------------------------------------- * [Blockchair （新しいタブで開きます）](https://blockchair.com/ethereum) - プライベートなイーサリアム・エクスプローラー。(メンプール) データの並べ替えやフィルタリングにも対応。スペイン語、フランス語、イタリア語、オランダ語、ポルトガル語、ロシア語、中国語、ペルシア語で利用可能 * [Chainlens （新しいタブで開きます）](https://www.chainlens.com/) * [DexGuru Block Explorer （新しいタブで開きます）](https://ethereum.dex.guru/) * [Etherchain （新しいタブで開きます）](https://www.etherchain.org/) * [Etherscan （新しいタブで開きます）](https://etherscan.io/) - 中国語、韓国語、ロシア語、日本語でも利用可能 * [Ethplorer （新しいタブで開きます）](https://ethplorer.io/) - トークンに焦点を当てたブロック・エクスプローラー。中国語、スペイン語、フランス語、トルコ語、ロシア語、韓国語、ベトナム語でも利用可能 * [Ethseer （新しいタブで開きます）](https://ethseer.io/) * [EthVM （新しいタブで開きます）](https://www.ethvm.com/) * [OKLink （新しいタブで開きます）](https://www.oklink.com/eth) [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#data) データ ---------------------------------------------------------------------------------------- イーサリアムは設計上透明性が高いため、すべてが検証可能です。ブロック・エクスプローラーは、この情報を取得するためのインターフェースを提供します。また、データが必要な場合は、メインのイーサリアム・ネットワークとテストネットの両方で利用できます。データは実行データとコンセンサス・データに分けられます。実行データは、特定のブロックで実行されたトランザクションを指します。コンセンサス・データは、ブロック自体とそれを提案したバリデータを指します。 ブロック・エクスプローラーから取得できるデータの種類の概要は以下の通りです。 ### [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#execution-data) 実行データ 新しいブロックは12秒ごとにイーサリアムに追加されるため (ブロック・プロポーザーが順番を逃さない限り)、ほぼ絶え間ないデータのストリームがブロック・エクスプローラーに追加されます。ブロックには、役立つ可能性のある重要なデータが多数含まれています。 **標準データ** * ブロック高 - 現在のブロック作成時のブロック番号とブロックチェーンの長さ (ブロック単位) * タイムスタンプ - ブロックが提案された時刻 * トランザクション - ブロックに含まれるトランザクションの数 * 手数料受取人 - トランザクションからガス代のチップを受け取ったアドレス * ブロック・リワード - ブロックを提案したバリデータに与えられるETHの量 * サイズ - ブロック内のデータのサイズ (バイト単位) * 使用されたガス - ブロック内のトランザクションによって使用されたガスの合計単位 * ガス・リミット - ブロック内のトランザクションによって設定されたガス・リミットの合計 * ガスあたりの基本料金 - トランザクションがブロックに含まれるために必要な最小の乗数 * 焼却された手数料 - ブロック内で焼却されたETHの量 * 追加データ - ビルダーがブロックに含めた追加データ **高度なデータ** * ハッシュ - ブロック・ヘッダーを表す暗号化ハッシュ (ブロックの一意の識別子) * 親ハッシュ - 現在のブロックの前のブロックのハッシュ * StateRoot - システムの全体の状態を保存するマークル・トライのルートハッシュ ### [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#gas) ガス ブロック・エクスプローラーは、トランザクションやブロックでのガス使用量に関するデータを提供するだけでなく、ネットワークの現在のガス価格に関する情報を提供するものもあります。これにより、ネットワークの使用状況を理解し、安全なトランザクションを送信し、ガスに過剰な支出をしないようにすることができます。この情報を製品のインターフェースに取り込むのに役立つAPIを探してみてください。ガス固有のデータには以下が含まれます。 * 安全だが遅いトランザクションに必要な推定ガス単位 (+ 推定価格と所要時間) * 平均的なトランザクションに必要な推定ガス単位 (+ 推定価格と所要時間) * 高速なトランザクションに必要な推定ガス単位 (+ 推定価格と所要時間) * ガス価格に基づく平均確認時間 * ガスを消費しているコントラクト - 言い換えれば、ネットワーク上で多く使用されている人気のある製品 * ガスを消費しているアカウント - 言い換えれば、頻繁なネットワークユーザー ### [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#transactions) トランザクション ブロック・エクスプローラーは、人々がトランザクションの進行状況を追跡するための一般的な場所になっています。それは、取得できる詳細レベルがさらなる確実性を提供するからです。トランザクション・データには以下が含まれます。 **標準データ** * トランザクション・ハッシュ - トランザクションが送信されたときに生成されるハッシュ * ステータス - トランザクションが保留中、失敗、または成功したかどうかの指標 * ブロック - トランザクションが含まれたブロック * タイムスタンプ - トランザクションがバリデータによって提案されたブロックに含まれた時刻 * From - トランザクションを送信したアカウントのアドレス * To - トランザクションが相互作用する受信者またはスマート・コントラクトのアドレス * 転送されたトークン - トランザクションの一部として転送されたトークンのリスト * 値 - 転送されるETHの合計値 * トランザクション手数料 - トランザクションを処理するためにバリデータに支払われる金額 (ガス価格\*使用されたガスで計算) **高度なデータ** * ガス・リミット - このトランザクションが消費できるガス単位の最大数 * 使用されたガス - トランザクションが実際に消費したガス単位の量 * ガス価格 - ガス単位ごとに設定された価格 * ナンス - `from` アドレスのトランザクション番号 (これは0から始まるため、`100` のナンスは実際にはこのアカウントによって送信された101番目のトランザクションになることに注意してください) * 入力データ - トランザクションに必要な追加情報 ### [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#accounts) アカウント アカウントに関してアクセスできるデータはたくさんあります。そのため、資産や価値が簡単に追跡されないように、複数のアカウントを使用することが推奨されることがよくあります。また、トランザクションやアカウントのアクティビティをよりプライベートにするために開発されているソリューションもいくつかあります。しかし、アカウントで利用できるデータは以下の通りです。 **ユーザー・アカウント** * アカウント・アドレス - 資金を送るために使用できる公開アドレス * ETH残高 - そのアカウントに関連付けられたETHの量 * 合計ETH値 - ETHの価値 * トークン - アカウントに関連付けられたトークンとその価値 * トランザクション履歴 - このアカウントが送信者または受信者であったすべてのトランザクションのリスト **スマート・コントラクト** スマート・コントラクト・アカウントには、ユーザー・アカウントが持つすべてのデータがありますが、一部のブロック・エクスプローラーではコード情報も表示されます。例は以下の通りです。 * コントラクト作成者 - コントラクトをメインネットにデプロイしたアドレス * 作成トランザクション - メインネットへのデプロイを含んだトランザクション * ソースコード - スマート・コントラクトのSolidityまたはVyperコード * コントラクトABI - コントラクトのアプリケーション・バイナリ・インターフェース — コントラクトが行う呼び出しと受信したデータ * コントラクト作成コード - スマート・コントラクトのコンパイル済みバイトコード — SolidityやVyperなどで書かれたスマート・コントラクトをコンパイルしたときに作成されます * コントラクト・イベント - スマート・コントラクトで呼び出されたメソッドの履歴 — 基本的に、コントラクトがどのように、どのくらいの頻度で使用されているかを確認する方法 ### [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#tokens) トークン トークンはコントラクトの一種であるため、スマート・コントラクトと同様のデータを持ちます。しかし、価値があり取引できるため、追加のデータポイントがあります。 * タイプ - ERC-20、ERC-721、または別のトークン標準のいずれであるか * 価格 - ERC-20の場合、現在の市場価値を持ちます * 時価総額 - ERC-20の場合、時価総額を持ちます (価格\*総供給量で計算) * 総供給量 - 流通しているトークンの数 * 保有者 - トークンを保有しているアドレスの数 * 転送 - トークンがアカウント間で転送された回数 * トランザクション履歴 - トークンを含むすべてのトランザクションの履歴 * コントラクト・アドレス - メインネットにデプロイされたトークンのアドレス * 小数点 - ERC-20トークンは分割可能であり、小数点以下の桁数を持ちます ### [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#network) ネットワーク 一部のブロックデータは、イーサリアムの健全性をより全体的に懸念しています。 * 総トランザクション - イーサリアムが作成されてからのトランザクション数 * 1秒あたりのトランザクション - 1秒以内に処理可能なトランザクション数 * ETH価格 - 1 ETHの現在の評価額 * 総ETH供給量 - 流通しているETHの数 — 新しいETHは、ブロック・リワードの形で各ブロックの作成とともに作成されることを覚えておいてください * 時価総額 - 価格\*供給量の計算 [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#consensus-layer-data) コンセンサス・レイヤーのデータ -------------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#epoch) エポック セキュリティ上の理由から、各エポックの終わり (6.4分ごと) に、ランダム化されたバリデータのコミッティが作成されます。エポック・データには以下が含まれます。 * エポック番号 * ファイナライズ済みステータス - エポックがファイナライズ済みかどうか (はい/いいえ) * 時刻 - エポックが終了した時刻 * アテステーション - エポック内のアテステーションの数 (スロット内のブロックに対する投票) * デポジット - エポックに含まれるETHデポジットの数 (バリデータになるにはETHをステークする必要があります) * スラッシング - ブロックのプロポーザーまたはアテスターに与えられたペナルティの数 * 投票参加 - ブロックをアテステーションするために使用されたステークされたETHの量 * バリデータ - エポックでアクティブなバリデータの数 * 平均バリデータ残高 - アクティブなバリデータの平均残高 * スロット - エポックに含まれるスロットの数 (スロットには1つの有効なブロックが含まれます) ### [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#slot) スロット スロットはブロック作成の機会であり、各スロットで利用可能なデータには以下が含まれます。 * エポック - スロットが有効なエポック * スロット番号 * ステータス - スロットのステータス (提案済み/見逃し) * 時刻 - スロットのタイムスタンプ * プロポーザー - スロットのブロックを提案したバリデータ * ブロック・ルート - ビーコン・ブロックのハッシュ・ツリー・ルート * 親ルート - 前のブロックのハッシュ * 状態ルート - ビーコン状態のハッシュ・ツリー・ルート * 署名 * RANDAOリビール * グラフィティ - ブロック・プロポーザーは、ブロック提案に32バイト長のメッセージを含めることができます * 実行データ * ブロック・ハッシュ * デポジット数 * デポジット・ルート * アテステーション - このスロットのブロックに対するアテステーションの数 * デポジット - このスロット中のデポジットの数 * 自発的な退出 - スロット中に退出したバリデータの数 * スラッシング - ブロックのプロポーザーまたはアテスターに与えられたペナルティの数 * 投票 - このスロットのブロックに投票したバリデータ ### [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#blocks-1) ブロック プルーフ・オブ・ステーク (PoS) は時間をスロットとエポックに分割します。つまり、新しいデータがあるということです！ * プロポーザー - 新しいブロックを提案するためにアルゴリズムによって選ばれたバリデータ * エポック - ブロックが提案されたエポック * スロット - ブロックが提案されたスロット * アテステーション - スロットに含まれるアテステーションの数 — アテステーションは、ブロックがビーコン・チェーンに進む準備ができていることを示す投票のようなものです ### [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#validators) バリデータ バリデータは、ブロックを提案し、スロット内でそれらをアテステーションする責任があります。 * バリデータ番号 - バリデータを表す一意の番号 * 現在の残高 - 報酬を含むバリデータの残高 * エフェクティブ・バランス - ステーキングに使用されるバリデータの残高 * 収入 - バリデータが受け取った報酬またはペナルティ * ステータス - バリデータが現在オンラインでアクティブかどうか * アテステーションの有効性 - バリデータのアテステーションがチェーンに含まれるまでの平均時間 * 有効化の資格 - バリデータが検証可能になった日付 (およびエポック) * アクティブ開始 - バリデータがアクティブになった日付 (およびエポック) * 提案されたブロック - バリデータが提案したブロック * アテステーション - バリデータが提供したアテステーション * デポジット - バリデータが行ったステーキング・デポジットの送信元アドレス、トランザクション・ハッシュ、ブロック番号、タイムスタンプ、金額、およびステータス ### [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#attestations) アテステーション アテステーションは、ブロックをチェーンに含めるための「はい」の投票です。そのデータは、アテステーションの記録とアテステーションを行ったバリデータに関連しています。 * スロット - アテステーションが行われたスロット * コミッティ・インデックス - 指定されたスロットでのコミッティのインデックス * 集約ビット - アテステーションに参加しているすべてのバリデータの集約されたアテステーションを表します * バリデータ - アテステーションを提供したバリデータ * ビーコン・ブロック・ルート - バリデータがアテステーションしているブロックを指します * ソース - 最新のジャスティファイド・エポックを指します * ターゲット - 最新のエポック境界を指します * 署名 ### [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#network-1) ネットワーク コンセンサス・レイヤーのトップレベルのデータには以下が含まれます。 * 現在のエポック * 現在のスロット * アクティブなバリデータ - アクティブなバリデータの数 * 保留中のバリデータ - アクティブになるのを待っているバリデータの数 * ステークされたETH - ネットワークにステークされたETHの量 * 平均残高 - バリデータの平均ETH残高 [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#further-reading) 参考文献 ---------------------------------------------------------------------------------------------------- _役に立ったコミュニティ・リソースをご存知ですか？このページを編集して追加してください！_ [](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/#related-topics) 関連トピック ----------------------------------------------------------------------------------------------------- * [トランザクション](https://ethereum.org/ja/developers/docs/transactions/) * [アカウント](https://ethereum.org/ja/developers/docs/accounts/) * [ネットワーク](https://ethereum.org/ja/developers/docs/networks/) --- # 分散型ストレージ | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/storage/#main-content) Change page 分散型ストレージ ======== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/storage/index.md) このページの内容 単一の企業や組織によって運営される中央集権型のサーバーとは異なり、分散型ストレージシステムは、データ全体の一部を保持するユーザーオペレーターのピア・ツー・ピアネットワークで構成されており、回復力のあるファイルストレージ共有システムを構築します。これらは、ブロックチェーンベースのアプリケーション、または任意のピア・ツー・ピアベースのネットワークに存在することができます。 イーサリアム自体も分散型ストレージシステムとして使用でき、すべてのスマート・コントラクトにおけるコードストレージに関しては実際にそのように機能しています。しかし、大量のデータとなると、それはイーサリアムが設計された目的ではありません。チェーンは着実に成長していますが、執筆時点では、イーサリアムのチェーンは約500GB〜1TB（[クライアントによって異なります （新しいタブで開きます）](https://etherscan.io/chartsync/chaindefault) ）であり、ネットワーク上のすべてのノードがすべてのデータを保存できる必要があります。もしチェーンが大量のデータ（例えば5TB）に拡大した場合、すべてのノードが稼働し続けることは現実的ではありません。また、これほど大量のデータをメインネットにデプロイするコストは、[ガス](https://ethereum.org/ja/developers/docs/gas/) 代のために法外に高くなります。 これらの制約のため、大量のデータを分散型の方法で保存するには、別のチェーンまたは方法論が必要です。 分散型ストレージ（dStorage）のオプションを検討する際、ユーザーが留意すべき点がいくつかあります。 * 永続化メカニズム / インセンティブ構造 * データ保持の強制 * 分散性 * コンセンサス [](https://ethereum.org/ja/developers/docs/storage/#persistence-mechanism) 永続化メカニズム / インセンティブ構造 ----------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ja/developers/docs/storage/#blockchain-based) ブロックチェーンベース データの一部を永久に保持するためには、永続化メカニズムを使用する必要があります。例えば、イーサリアムにおける永続化メカニズムは、ノードを実行する際にチェーン全体を考慮する必要があるというものです。新しいデータはチェーンの末尾に追加され、チェーンは成長し続けます。そのため、すべてのノードが埋め込まれたすべてのデータを複製する必要があります。 これは**ブロックチェーンベース**の永続化として知られています。 ブロックチェーンベースの永続化の問題点は、チェーンが大きくなりすぎて、すべてのデータを現実的に維持・保存できなくなる可能性があることです（例えば、[多くの情報源 （新しいタブで開きます）](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) が、インターネットには40ゼタバイト以上のストレージ容量が必要だと推定しています）。 ブロックチェーンには、何らかのインセンティブ構造も必要です。ブロックチェーンベースの永続化では、バリデータに対して支払いが行われます。データがチェーンに追加されると、バリデータはそのデータを追加するための報酬を受け取ります。 ブロックチェーンベースの永続化を持つプラットフォーム： * イーサリアム * [Arweave （新しいタブで開きます）](https://www.arweave.org/) ### [](https://ethereum.org/ja/developers/docs/storage/#contract-based) コントラクトベース **コントラクトベース**の永続化は、すべてのノードがデータを複製して永久に保存することはできないため、代わりにコントラクトの合意によって維持されなければならないという直感に基づいています。これらは、一定期間データを保持することを約束した複数のノードと結ばれる合意です。データを永続化し続けるためには、期間が切れるたびに資金を補充するか、更新する必要があります。 ほとんどの場合、すべてのデータをオンチェーンに保存するのではなく、チェーン上のどこにデータがあるかを示すハッシュが保存されます。これにより、すべてのデータを保持するためにチェーン全体をスケールさせる必要がなくなります。 コントラクトベースの永続化を持つプラットフォーム： * [ファイルコイン （新しいタブで開きます）](https://docs.filecoin.io/basics/what-is-filecoin) * [Skynet （新しいタブで開きます）](https://sia.tech/) * [Storj （新しいタブで開きます）](https://storj.io/) * [Züs （新しいタブで開きます）](https://zus.network/) * [Crust Network （新しいタブで開きます）](https://crust.network/) * [スウォーム （新しいタブで開きます）](https://www.ethswarm.org/) * [4EVERLAND （新しいタブで開きます）](https://www.4everland.org/) ### [](https://ethereum.org/ja/developers/docs/storage/#additional-consideration) その他の考慮事項 IPFSは、ファイル、ウェブサイト、アプリケーション、およびデータへの保存とアクセスを行うための分散型システムです。組み込みのインセンティブスキームはありませんが、長期的な永続化のために、上記のコントラクトベースのインセンティブソリューションのいずれかと組み合わせて使用することができます。IPFS上でデータを永続化するもう1つの方法は、データを「ピン留め」してくれるピニングサービスを利用することです。独自のIPFSノードを実行し、ネットワークに貢献して、自分や他人のデータを無料で永続化することも可能です！ * [IPFS （新しいタブで開きます）](https://docs.ipfs.io/concepts/what-is-ipfs/) * [Pinata （新しいタブで開きます）](https://www.pinata.cloud/) _(IPFSピニングサービス)_ * [web3.storage （新しいタブで開きます）](https://web3.storage/) _(IPFS/ファイルコインピニングサービス)_ * [Infura （新しいタブで開きます）](https://infura.io/product/ipfs) _(IPFSピニングサービス)_ * [IPFS Scan （新しいタブで開きます）](https://ipfs-scan.io/) _(IPFSピニングエクスプローラー)_ * [4EVERLAND （新しいタブで開きます）](https://www.4everland.org/) _（IPFSピニングサービス）_ * [Filebase （新しいタブで開きます）](https://filebase.com/) _(IPFSピニングサービス)_ * [Spheron Network （新しいタブで開きます）](https://spheron.network/) _(IPFS/ファイルコインピニングサービス)_ スウォームは、ストレージインセンティブシステムとストレージのレンタル価格オラクルを備えた、分散型データストレージおよび配信技術です。 [](https://ethereum.org/ja/developers/docs/storage/#data-retention) データ保持 ------------------------------------------------------------------------- データを保持するためには、システムはデータが確実に保持されるようにするための何らかのメカニズムを備えている必要があります。 ### [](https://ethereum.org/ja/developers/docs/storage/#challenge-mechanism) チャレンジメカニズム データが保持されていることを確認する最も一般的な方法の1つは、ノードがまだデータを持っているかを確認するために発行される、何らかの暗号技術によるチャレンジを使用することです。簡単な例として、ArweaveのProof-of-Access（アクセス証明）が挙げられます。彼らはノードに対してチャレンジを発行し、最新のブロックと過去のランダムなブロックの両方でデータを持っているかを確認します。ノードが答えを出せない場合、ペナルティが科せられます。 チャレンジメカニズムを持つdStorageの種類： * Züs * Skynet * Arweave * ファイルコイン * Crust Network * 4EVERLAND ### [](https://ethereum.org/ja/developers/docs/storage/#decentrality) 分散性 プラットフォームの分散化のレベルを測定する優れたツールはありませんが、一般的には、中央集権的でないことの証拠として、何らかのKYCを必要としないツールを使用することが望ましいでしょう。 KYCのない分散型ツール： * Skynet * Arweave * ファイルコイン * IPFS * イーサリアム * Crust Network * 4EVERLAND ### [](https://ethereum.org/ja/developers/docs/storage/#consensus) コンセンサス これらのツールのほとんどは独自の[コンセンサス・メカニズム](https://ethereum.org/ja/developers/docs/consensus-mechanisms/) を持っていますが、一般的には[**プルーフ・オブ・ワーク (PoW)**](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pow/) または[**プルーフ・オブ・ステーク (PoS)**](https://ethereum.org/ja/developers/docs/consensus-mechanisms/pos/) のいずれかに基づいています。 プルーフ・オブ・ワークベース： * Skynet * Arweave プルーフ・オブ・ステークベース： * イーサリアム * ファイルコイン * Züs * Crust Network [](https://ethereum.org/ja/developers/docs/storage/#related-tools) 関連ツール ------------------------------------------------------------------------ **IPFS - _InterPlanetary File Systemは、イーサリアムのための分散型ストレージおよびファイル参照システムです。_** * [Ipfs.io （新しいタブで開きます）](https://ipfs.io/) * [ドキュメント （新しいタブで開きます）](https://docs.ipfs.io/) * [GitHub （新しいタブで開きます）](https://github.com/ipfs/ipfs) **Storj DCS - _開発者向けの、安全でプライベートなS3互換の分散型クラウドオブジェクトストレージです。_** * [Storj.io （新しいタブで開きます）](https://storj.io/) * [ドキュメント （新しいタブで開きます）](https://docs.storj.io/) * [GitHub （新しいタブで開きます）](https://github.com/storj/storj) **Sia - _暗号技術を活用してトラストレスなクラウドストレージ市場を構築し、買い手と売り手が直接取引できるようにします。_** * [Skynet.net （新しいタブで開きます）](https://sia.tech/) * [ドキュメント （新しいタブで開きます）](https://docs.sia.tech/) * [GitHub （新しいタブで開きます）](https://github.com/SiaFoundation/) **ファイルコイン - _ファイルコインは、IPFSを開発したのと同じチームによって作成されました。IPFSの理念の上に構築されたインセンティブレイヤーです。_** * [Filecoin.io （新しいタブで開きます）](https://filecoin.io/) * [ドキュメント （新しいタブで開きます）](https://docs.filecoin.io/) * [GitHub （新しいタブで開きます）](https://github.com/filecoin-project/) **Arweave - _Arweaveは、データを保存するためのdStorageプラットフォームです。_** * [Arweave.org （新しいタブで開きます）](https://www.arweave.org/) * [ドキュメント （新しいタブで開きます）](https://docs.arweave.org/info/) * [Arweave （新しいタブで開きます）](https://github.com/ArweaveTeam/arweave/) **Züs - _Züsは、シャーディングとブロバーを備えたプルーフ・オブ・ステークのdStorageプラットフォームです。_** * [zus.network （新しいタブで開きます）](https://zus.network/) * [ドキュメント （新しいタブで開きます）](https://docs.zus.network/zus-docs/) * [GitHub （新しいタブで開きます）](https://github.com/0chain/) **Crust Network - _Crustは、IPFS上に構築されたdStorageプラットフォームです。_** * [Crust.network （新しいタブで開きます）](https://crust.network/) * [ドキュメント （新しいタブで開きます）](https://wiki.crust.network/) * [GitHub （新しいタブで開きます）](https://github.com/crustio) **スウォーム - _イーサリアムのWeb3スタックのための分散型ストレージプラットフォームおよびコンテンツ配信サービスです。_** * [EthSwarm.org （新しいタブで開きます）](https://www.ethswarm.org/) * [ドキュメント （新しいタブで開きます）](https://docs.ethswarm.org/) * [GitHub （新しいタブで開きます）](https://github.com/ethersphere/) **OrbitDB - _IPFS上に構築された分散型ピア・ツー・ピアデータベースです。_** * [OrbitDB.org （新しいタブで開きます）](https://orbitdb.org/) * [ドキュメント （新しいタブで開きます）](https://github.com/orbitdb/field-manual/) * [GitHub （新しいタブで開きます）](https://github.com/orbitdb/orbit-db/) **Aleph.im - _分散型クラウドプロジェクト（データベース、ファイルストレージ、コンピューティング、および分散型アイデンティティ (DID)）。オフチェーンとオンチェーンのピア・ツー・ピア技術のユニークな融合。IPFSおよびマルチチェーンとの互換性があります。_** * [Aleph.im （新しいタブで開きます）](https://aleph.cloud/) * [ドキュメント （新しいタブで開きます）](https://docs.aleph.cloud/) * [GitHub （新しいタブで開きます）](https://github.com/aleph-im/) **Ceramic - _データが豊富で魅力的なアプリケーションのための、ユーザー制御のIPFSデータベースストレージです。_** * [Ceramic.network （新しいタブで開きます）](https://ceramic.network/) * [ドキュメント （新しいタブで開きます）](https://developers.ceramic.network/) * [GitHub （新しいタブで開きます）](https://github.com/ceramicnetwork/js-ceramic/) **Filebase - _S3互換の分散型ストレージおよび地理的冗長性を持つIPFSピニングサービスです。Filebaseを通じてIPFSにアップロードされたすべてのファイルは、世界中で3倍のレプリケーションが行われ、Filebaseインフラストラクチャに自動的にピン留めされます。_** * [Filebase.com （新しいタブで開きます）](https://filebase.com/) * [ドキュメント （新しいタブで開きます）](https://docs.filebase.com/) * [GitHub （新しいタブで開きます）](https://github.com/filebase) **4EVERLAND - _ストレージ、コンピューティング、ネットワーキングのコア機能を統合したウェブ・3.0クラウドコンピューティングプラットフォームです。S3互換であり、IPFSやArweaveなどの分散型ストレージネットワーク上で同期データストレージを提供します。_** * [4everland.org （新しいタブで開きます）](https://www.4everland.org/) * [ドキュメント （新しいタブで開きます）](https://docs.4everland.org/) * [GitHub （新しいタブで開きます）](https://github.com/4everland) **Kaleido - _ボタンをクリックするだけでIPFSノードを利用できるBlockchain-as-a-Serviceプラットフォームです。_** * [Kaleido （新しいタブで開きます）](https://kaleido.io/) * [ドキュメント （新しいタブで開きます）](https://docs.kaleido.io/kaleido-services/ipfs/) * [GitHub （新しいタブで開きます）](https://github.com/kaleido-io) **Spheron Network - _Spheronは、最高のパフォーマンスで分散型インフラストラクチャ上にアプリケーションを立ち上げたい分散型アプリケーション (dapp) 向けに設計されたPlatform-as-a-Service (PaaS) です。コンピューティング、分散型ストレージ、CDN、およびウェブホスティングをデフォルトで提供します。_** * [spheron.network （新しいタブで開きます）](https://spheron.network/) * [ドキュメント （新しいタブで開きます）](https://docs.spheron.network/) * [GitHub （新しいタブで開きます）](https://github.com/spheronFdn) **dweb3 - _eth.limoに似た分散型ウェブページのリゾルバであり、ENSやIPFSに限定されず、すべてのタイプをサポートします。_** * [dweb3.wtf （新しいタブで開きます）](https://dweb3.wtf/) **web3compass - _IPFSとENSに裏付けられた分散型ウェブサイトのための検索エンジンです。_** * [web3compass.net （新しいタブで開きます）](https://www.web3compass.net/) * [ドキュメント （新しいタブで開きます）](https://www.web3compass.net/statistics) [](https://ethereum.org/ja/developers/docs/storage/#further-reading) 参考文献 ------------------------------------------------------------------------- * [分散型ストレージとは何か？ （新しいタブで開きます）](https://coinmarketcap.com/academy/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_ * [分散型ストレージに関する5つのよくある神話を打ち破る （新しいタブで開きます）](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_ _役に立ったコミュニティリソースをご存知ですか？このページを編集して追加してください！_ [](https://ethereum.org/ja/developers/docs/storage/#related-topics) 関連トピック -------------------------------------------------------------------------- * [開発フレームワーク](https://ethereum.org/ja/developers/docs/frameworks/) --- # スマート・コントラクトの検証 | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#main-content) Change page スマート・コントラクトの検証 ============== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/verifying/index.md) このページの内容 [スマート・コントラクト](https://ethereum.org/ja/developers/docs/smart-contracts/) は「トラストレス」であるように設計されています。つまり、ユーザーはコントラクトを操作する前に、サードパーティ（開発者や企業など）を信頼する必要がありません。トラストレス性の要件として、ユーザーや他の開発者はスマート・コントラクトのソースコードを検証できる必要があります。ソース・コード検証により、公開されたコントラクトのコードが、イーサリアムのブロックチェーン上のコントラクトのアドレスで実行されているコードと同じであることが、ユーザーや開発者に保証されます。 「ソース・コード検証」と「[形式的検証](https://ethereum.org/ja/developers/docs/smart-contracts/formal-verification/) 」を区別することが重要です。後で詳しく説明するソース・コード検証とは、高水準言語（Solidityなど）で記述されたスマート・コントラクトのソースコードが、コントラクトのアドレスで実行されるのと同じバイトコードにコンパイルされることを検証することです。一方、形式的検証は、スマート・コントラクトの正確性、つまりコントラクトが期待通りに動作することを検証することを指します。文脈にもよりますが、コントラクトの検証は通常、ソース・コード検証を意味します。 [](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#what-is-source-code-verification) ソース・コード検証とは何ですか？ ------------------------------------------------------------------------------------------------------------------------ スマート・コントラクトを[イーサリアム仮想マシン (EVM)](https://ethereum.org/ja/developers/docs/evm/) にデプロイする前に、開発者はコントラクトのソースコード（[Solidity](https://ethereum.org/ja/developers/docs/smart-contracts/languages/) などの高水準プログラミング言語で書かれた命令）をバイトコードに[コンパイル](https://ethereum.org/ja/developers/docs/smart-contracts/compiling/) します。EVMは高水準の命令を解釈できないため、EVMでコントラクトのロジックを実行するには、ソースコードをバイトコード（つまり、低水準の機械語命令）にコンパイルする必要があります。 ソース・コード検証とは、スマート・コントラクトのソースコードと、コントラクト作成時に使用されたコンパイル済みのバイトコードを比較し、違いがないかを検出することです。宣伝されているコントラクトのコードが、ブロックチェーン上で実際に実行されているものと異なる可能性があるため、スマート・コントラクトの検証は重要です。 スマート・コントラクトの検証により、機械語を読むことなく、記述された高水準言語を通じてコントラクトが何を行うかを調査できるようになります。関数、値、そして通常は変数名やコメントも、コンパイルおよびデプロイされた元のソースコードと同じままです。これにより、コードを読むのがはるかに簡単になります。また、ソース検証はコードのドキュメント化にも役立つため、エンドユーザーはスマート・コントラクトが何を行うように設計されているかを知ることができます。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#full-verification) 完全な検証とは何ですか？ ソースコードの中には、コメントや変数名など、コンパイルされたバイトコードに影響を与えない部分があります。つまり、変数名やコメントが異なる2つのソースコードでも、同じコントラクトを検証できるということです。そのため、悪意のあるアクターがソースコード内に欺瞞的なコメントを追加したり、誤解を招く変数名を付けたりして、元のソースコードとは異なるソースコードでコントラクトを検証させることが可能です。 ソースコードの正確性の\_暗号論的保証\_として、またコンパイル情報の\_フィンガープリント\_として機能する追加データをバイトコードに付加することで、これを回避できます。必要な情報は[Solidityのコントラクトのメタデータ （新しいタブで開きます）](https://docs.soliditylang.org/en/v0.8.15/metadata.html) にあり、このファイルのハッシュがコントラクトのバイトコードに付加されます。実際の動作は[メタデータ・プレイグラウンド （新しいタブで開きます）](https://playground.sourcify.dev/) で確認できます。 メタデータ・ファイルには、ソースファイルやそのハッシュなど、コントラクトのコンパイルに関する情報が含まれています。つまり、コンパイル設定やソースファイルの1バイトでも変更されると、メタデータ・ファイルも変更されます。その結果、バイトコードに付加されるメタデータ・ファイルのハッシュも変更されます。したがって、コントラクトのバイトコードと付加されたメタデータのハッシュが、提供されたソースコードおよびコンパイル設定と一致する場合、元のコンパイルで使用されたソースコードと1バイトも違わず完全に同じであることが確信できます。 メタデータのハッシュを活用するこのタイプの検証は、**「[完全な検証 （新しいタブで開きます）](https://docs.sourcify.dev/docs/full-vs-partial-match/) 」**（または「完璧な検証」）と呼ばれます。メタデータのハッシュが一致しない場合、または検証で考慮されない場合は「部分的な一致」となり、現在はこちらがコントラクトを検証する一般的な方法です。完全な検証を行わないと、検証済みのソースコードに反映されない[悪意のあるコードを挿入する （新しいタブで開きます）](https://samczsun.com/hiding-in-plain-sight/) ことが可能です。ほとんどの開発者は完全な検証について認識しておらず、コンパイル時のメタデータ・ファイルを保持していないため、これまで部分的な検証がコントラクトを検証する事実上の標準的な方法となっていました。 [](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#importance-of-source-code-verification) なぜソース・コード検証が重要なのですか？ ---------------------------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#trustlessness) トラストレス性 トラストレス性は、間違いなくスマート・コントラクトと[分散型アプリケーション (dapp)](https://ethereum.org/ja/developers/docs/dapps/) の最大の前提です。スマート・コントラクトは「イミュータブル」であり、変更することはできません。コントラクトは、デプロイ時にコードで定義されたビジネスロジックのみを実行します。つまり、開発者や企業は、イーサリアムにデプロイした後にコントラクトのコードを改ざんすることはできません。 スマート・コントラクトがトラストレスであるためには、コントラクトのコードが独立した検証のために利用可能である必要があります。すべてのスマート・コントラクトのコンパイル済みバイトコードはブロックチェーン上で公開されていますが、低水準言語は開発者にとってもユーザーにとっても理解するのが困難です。 プロジェクトは、コントラクトのソースコードを公開することでトラスト前提を減らします。しかし、これは別の問題を引き起こします。公開されたソースコードがコントラクトのバイトコードと一致することを検証するのは困難です。このシナリオでは、ユーザーはブロックチェーンにデプロイする前に開発者がコントラクトのビジネスロジックを変更しない（つまり、バイトコードを変更しない）ことを信頼しなければならないため、トラストレス性の価値が失われます。 ソース・コード検証ツールは、スマート・コントラクトのソースコード・ファイルがアセンブリコードと一致することを保証します。その結果、ユーザーがサードパーティを盲目的に信頼するのではなく、コントラクトに資金を入金する前にコードを検証するトラストレスなエコシステムが実現します。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#user-safety) ユーザーの安全性 スマート・コントラクトでは、通常、多額の資金がステークされます。そのため、使用する前に、より高いセキュリティ保証とスマート・コントラクトのロジックの検証が求められます。問題は、悪徳な開発者がスマート・コントラクトに悪意のあるコードを挿入してユーザーを欺く可能性があることです。検証を行わないと、悪意のあるスマート・コントラクトに[バックドア （新しいタブで開きます）](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts) 、物議を醸すアクセス制御メカニズム、悪用可能な脆弱性など、ユーザーの安全を脅かすものが検出されずに残る可能性があります。 スマート・コントラクトのソースコード・ファイルを公開することで、監査人などの関心を持つ人々が、潜在的な攻撃ベクトルについてコントラクトを評価しやすくなります。複数の当事者が独立してスマート・コントラクトを検証することで、ユーザーはそのセキュリティについてより強力な保証を得ることができます。 [](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#source-code-verification-for-ethereum-smart-contracts) イーサリアムのスマート・コントラクトのソース・コード検証方法 ----------------------------------------------------------------------------------------------------------------------------------------------------------- [イーサリアムにスマート・コントラクトをデプロイする](https://ethereum.org/ja/developers/docs/smart-contracts/deploying/) には、データ・ペイロード（コンパイル済みバイトコード）を含むトランザクションを特別なアドレスに送信する必要があります。データ・ペイロードは、ソースコードをコンパイルし、トランザクション内のデータ・ペイロードにコントラクト・インスタンスの[コンストラクタ引数 （新しいタブで開きます）](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) を付加することで生成されます。コンパイルは決定論的です。つまり、同じソースファイルとコンパイル設定（コンパイラのバージョン、オプティマイザなど）を使用すれば、常に同じ出力（つまり、コントラクトのバイトコード）が生成されます。 [![A diagram showing showing smart contract source code verification](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fsmart-contracts%2Fverifying%2Fsource-code-verification.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/smart-contracts/verifying/source-code-verification.png) スマート・コントラクトの検証には、基本的に以下の手順が含まれます。 1. ソースファイルとコンパイル設定をコンパイラに入力します。 2. コンパイラがコントラクトのバイトコードを出力します。 3. 指定されたアドレスにデプロイされたコントラクトのバイトコードを取得します。 4. デプロイされたバイトコードと再コンパイルされたバイトコードを比較します。コードが一致する場合、コントラクトは提供されたソースコードとコンパイル設定で検証されます。 5. さらに、バイトコードの末尾にあるメタデータのハッシュが一致する場合、完全な一致となります。 これは検証の単純化された説明であり、[イミュータブルな変数 （新しいタブで開きます）](https://docs.sourcify.dev/docs/immutables/) を持つ場合など、これでは機能しない多くの例外があることに注意してください。 [](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#source-code-verification-tools) ソース・コード検証ツール ------------------------------------------------------------------------------------------------------------------ コントラクトを検証する従来の手順は複雑になる可能性があります。そのため、イーサリアムにデプロイされたスマート・コントラクトのソース・コード検証ツールが存在します。これらのツールは、ソース・コード検証の大部分を自動化し、ユーザーの利益のために検証済みのコントラクトをキュレーションします。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#etherscan) Etherscan Etherscanは主に[イーサリアムのブロック・エクスプローラー](https://ethereum.org/ja/developers/docs/data-and-analytics/block-explorers/) として知られていますが、スマート・コントラクトの開発者やユーザー向けに[ソース・コード検証サービス （新しいタブで開きます）](https://etherscan.io/verifyContract) も提供しています。 Etherscanを使用すると、元のデータ・ペイロード（ソースコード、ライブラリのアドレス、コンパイラ設定、コントラクトのアドレスなど）からコントラクトのバイトコードを再コンパイルできます。再コンパイルされたバイトコードがオンチェーンのコントラクトのバイトコード（およびコンストラクタ・パラメータ）と関連付けられている場合、[コントラクトは検証されます （新しいタブで開きます）](https://info.etherscan.com/types-of-contract-verification/) 。 検証されると、コントラクトのソースコードには「Verified（検証済み）」ラベルが付与され、他の人が監査できるようにEtherscanで公開されます。また、検証済みのソースコードを持つスマート・コントラクトのリポジトリである[Verified Contracts （新しいタブで開きます）](https://etherscan.io/contractsVerified/) セクションにも追加されます。 Etherscanは、コントラクトの検証に最も使用されているツールです。しかし、Etherscanのコントラクト検証には欠点があります。オンチェーンのバイトコードと再コンパイルされたバイトコードの**メタデータのハッシュ**を比較できないのです。したがって、Etherscanでの一致は部分的な一致となります。 [Etherscanでのコントラクト検証の詳細 （新しいタブで開きます）](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327) ### [](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#blockscout) Blockscout [Blockscout （新しいタブで開きます）](https://blockscout.com/) はオープンソースのブロック・エクスプローラーであり、スマート・コントラクトの開発者やユーザー向けに[コントラクト検証サービス （新しいタブで開きます）](https://eth.blockscout.com/contract-verification) も提供しています。オープンソースの代替手段として、Blockscoutは検証の実行方法に透明性を提供し、検証プロセスを改善するためのコミュニティの貢献を可能にします。 他の検証サービスと同様に、Blockscoutではバイトコードを再コンパイルし、デプロイされたコントラクトと比較することで、コントラクトのソースコードを検証できます。検証されると、コントラクトは検証ステータスを受け取り、ソースコードは監査や操作のために一般公開されます。検証済みのコントラクトは、簡単に閲覧やディスカバリーができるように、Blockscoutの[検証済みコントラクト・リポジトリ （新しいタブで開きます）](https://eth.blockscout.com/verified-contracts) にもリストされます。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#sourcify) Sourcify [Sourcify （新しいタブで開きます）](https://sourcify.dev/#/verifier) は、オープンソースで分散型のコントラクト検証ツールです。ブロック・エクスプローラーではなく、[さまざまなEVMベースのネットワーク （新しいタブで開きます）](https://docs.sourcify.dev/docs/chains) 上のコントラクトのみを検証します。他のツールがその上に構築するためのパブリック・インフラストラクチャとして機能し、メタデータ・ファイルにある[ABI](https://ethereum.org/ja/developers/docs/smart-contracts/compiling/#web-applications) や[NatSpec （新しいタブで開きます）](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) コメントを使用して、より人間に優しいコントラクトの操作を可能にすることを目指しています。 Etherscanとは異なり、Sourcifyはメタデータのハッシュによる完全な一致をサポートしています。検証済みのコントラクトは、HTTPおよび分散型の[コンテンツ・アドレス （新しいタブで開きます）](https://docs.storacha.network/concepts/content-addressing/) ・ストレージである[IPFS （新しいタブで開きます）](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs) 上の[パブリック・リポジトリ （新しいタブで開きます）](https://docs.sourcify.dev/docs/repository/) で提供されます。付加されたメタデータのハッシュはIPFSハッシュであるため、IPFS経由でコントラクトのメタデータ・ファイルを取得できます。 さらに、これらのファイルのIPFSハッシュもメタデータに含まれているため、IPFS経由でソースコード・ファイルを取得することもできます。APIや[UI （新しいタブで開きます）](https://sourcify.dev/#/verifier) 経由でメタデータ・ファイルとソースファイルを提供するか、プラグインを使用することで、コントラクトを検証できます。また、Sourcifyの監視ツールは新しいブロックでのコントラクト作成をリッスンし、メタデータとソースファイルがIPFSで公開されている場合はコントラクトの検証を試みます。 [Sourcifyでのコントラクト検証の詳細 （新しいタブで開きます）](https://soliditylang.org/blog/2020/06/25/sourcify-faq/) ### [](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#tenderly) Tenderly [Tenderlyプラットフォーム （新しいタブで開きます）](https://tenderly.co/) を使用すると、Web3開発者はスマート・コントラクトの構築、テスト、監視、運用を行うことができます。デバッグツールと可観測性、およびインフラストラクチャの構成要素を組み合わせることで、Tenderlyは開発者がスマート・コントラクトの開発を加速するのを支援します。Tenderlyの機能を完全に有効にするには、開発者はいくつかの方法を使用して[ソース・コード検証を実行する （新しいタブで開きます）](https://docs.tenderly.co/monitoring/contract-verification) 必要があります。 コントラクトはプライベートまたはパブリックに検証することが可能です。プライベートに検証された場合、スマート・コントラクトはあなた（およびプロジェクトの他のメンバー）にのみ表示されます。コントラクトをパブリックに検証すると、Tenderlyプラットフォームを使用するすべてのユーザーに表示されるようになります。 [ダッシュボード （新しいタブで開きます）](https://docs.tenderly.co/contract-verification) 、[Tenderly Hardhatプラグイン （新しいタブで開きます）](https://docs.tenderly.co/contract-verification/hardhat) 、または[CLI （新しいタブで開きます）](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli) を使用してコントラクトを検証できます。 ダッシュボードからコントラクトを検証する場合、ソースファイルまたはSolidityコンパイラによって生成されたメタデータ・ファイル、アドレス/ネットワーク、およびコンパイラ設定をインポートする必要があります。 Tenderly Hardhatプラグインを使用すると、より少ない労力で検証プロセスをより詳細に制御でき、自動（ノーコード）検証と手動（コードベース）検証のいずれかを選択できます。 [](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#further-reading) 参考文献 ------------------------------------------------------------------------------------------- * [コントラクトのソースコードの検証 （新しいタブで開きます）](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/) --- # Python開発者のためのイーサリアム | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/programming-languages/python/#main-content) Change page Python開発者のためのイーサリアム =================== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/python/index.md) このページの内容 Pythonベースのプロジェクトやツールを使用してイーサリアム向けに開発する方法を学びます イーサリアムを使用して、暗号資産とブロックチェーン技術の利点を活用した分散型アプリケーション (dapp) を作成します。これらのdappは信頼性が高く、一度イーサリアムにデプロイされると、常にプログラムされた通りに実行されます。デジタル資産を制御して、新しい種類の金融アプリケーションを作成できます。また、分散型であるため、単一の組織や個人が制御することはなく、検閲することはほぼ不可能です。 [](https://ethereum.org/ja/developers/docs/programming-languages/python/#getting-started-with-smart-contracts-and-solidity) スマート・コントラクトとSolidity言語の基礎 ----------------------------------------------------------------------------------------------------------------------------------------------------- **Pythonとイーサリアムを統合するための第一歩を踏み出しましょう** まずはより基本的な入門書が必要ですか？ [ethereum.org/learn](https://ethereum.org/ja/learn/) または [ethereum.org/developers](https://ethereum.org/ja/developers/) を確認してください。 * [ブロックチェーンの解説 （新しいタブで開きます）](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [スマート・コントラクトの理解 （新しいタブで開きます）](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [初めてのスマート・コントラクトを作成する （新しいタブで開きます）](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Solidityのコンパイルとデプロイ方法を学ぶ （新しいタブで開きます）](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) * [2023年版ブロックチェーンにおけるPythonの現状レポート （新しいタブで開きます）](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023) [](https://ethereum.org/ja/developers/docs/programming-languages/python/#beginner-articles) 初心者向け記事 --------------------------------------------------------------------------------------------------- * [Web3.pyの概要 （新しいタブで開きます）](https://web3py.readthedocs.io/en/latest/overview.html) * [イーサリアムのPythonエコシステムツアー （新しいタブで開きます）](https://snakecharmers.ethereum.org/python-ecosystem/) * [(Python) 開発者のためのイーサリアムガイド （新しいタブで開きます）](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/) * [賞を狙える: イーサリアムPythonハッカソンガイド （新しいタブで開きます）](https://snakecharmers.ethereum.org/prize-worthy/) * [Vyperを使ったスマート・コントラクト入門 （新しいタブで開きます）](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/) * [Python Flaskを使用してイーサリアムのコントラクトを開発するには？ （新しいタブで開きます）](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e) * [Web3.py入門 · Python開発者のためのイーサリアム （新しいタブで開きます）](https://www.dappuniversity.com/articles/web3-py-intro) * [PythonとWeb3.pyを使用してスマート・コントラクトの関数を呼び出す方法 （新しいタブで開きます）](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py) [](https://ethereum.org/ja/developers/docs/programming-languages/python/#intermediate-articles) 中級者向け記事 ------------------------------------------------------------------------------------------------------- * [Web3.pyの仲間たち: Ape入門 （新しいタブで開きます）](https://snakecharmers.ethereum.org/intro-to-ape/) * [Pythonプログラマーのためのdapp開発 （新しいタブで開きます）](https://www.youtube.com/watch?v=tE-8bG35VNw) * [Pythonイーサリアムインターフェースの作成: パート1 （新しいタブで開きます）](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d) * [Pythonでのイーサリアムスマート・コントラクト: (ほぼ)完全ガイド （新しいタブで開きます）](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988) [](https://ethereum.org/ja/developers/docs/programming-languages/python/#advanced-use-patterns) 高度な使用パターン --------------------------------------------------------------------------------------------------------- * [Web3.pyのパターン: リアルタイムイベントのサブスクリプション （新しいタブで開きます）](https://snakecharmers.ethereum.org/subscriptions/) * [Web3.pyのパターン: WebSocketProvider （新しいタブで開きます）](https://snakecharmers.ethereum.org/websocketprovider/) * [Pythonを使用したイーサリアムスマート・コントラクトのコンパイル、デプロイ、呼び出し （新しいタブで開きます）](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/) * [スリザーを使用したSolidityスマート・コントラクトの分析 （新しいタブで開きます）](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither) * [ブロックチェーンフィンテックチュートリアル: Pythonを使ったレンディングと借り入れ （新しいタブで開きます）](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/) [](https://ethereum.org/ja/developers/docs/programming-languages/python/#archived-articles) アーカイブされた記事 ------------------------------------------------------------------------------------------------------ * [PythonとBrownieを使用して独自のERC-20トークンをデプロイする （新しいタブで開きます）](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58) * [BrownieとPythonを使用したスマート・コントラクトのデプロイ （新しいタブで開きます）](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp) * [Brownieを使用してオープンシーでNFTを作成する （新しいタブで開きます）](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/) [](https://ethereum.org/ja/developers/docs/programming-languages/python/#python-projects-and-tools) Pythonのプロジェクトとツール --------------------------------------------------------------------------------------------------------------------- * [Web3.py （新しいタブで開きます）](https://github.com/ethereum/web3.py) - _イーサリアムと対話するためのPythonライブラリ_ * [Vyper （新しいタブで開きます）](https://github.com/ethereum/vyper/) - _EVM向けのPython風スマート・コントラクト言語_ * [Titanoboa （新しいタブで開きます）](https://github.com/vyperlang/titanoboa/) - _Vyperのネイティブテストツール。メインネットのフォーク、デバッグ、見やすいトレースバックを備えたインタープリタ_ * [Moccasin （新しいタブで開きます）](https://github.com/Cyfrin/moccasin) - _Titanoboa上に構築された、VyperとPythonのためのスマート・コントラクト開発およびテストフレームワーク_ * [Ape （新しいタブで開きます）](https://github.com/ApeWorX/ape) - _Pythonista、データサイエンティスト、セキュリティ専門家のためのスマート・コントラクト開発ツール_ * [py-evm （新しいタブで開きます）](https://github.com/ethereum/py-evm) - _イーサリアム仮想マシン (EVM) の実装_ * [eth-tester （新しいタブで開きます）](https://github.com/ethereum/eth-tester) - _イーサリアムベースのアプリケーションをテストするためのツール_ * [eth-utils （新しいタブで開きます）](https://github.com/ethereum/eth-utils/) - _イーサリアム関連のコードベースを扱うためのユーティリティ関数_ * [py-solc-x （新しいタブで開きます）](https://pypi.org/project/py-solc-x/) - _0.5.xをサポートするsolc SolidityコンパイラのPythonラッパー_ * [pymaker （新しいタブで開きます）](https://github.com/makerdao/pymaker) - _Makerコントラクト用のPython API_ * [siwe （新しいタブで開きます）](https://github.com/signinwithethereum/siwe-py) - _Python向けのSign in with Ethereum (SIWE)_ * [Web3 DeFi for Ethereum integrations （新しいタブで開きます）](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _ERC-20、ユニスワップ、その他の人気プロジェクトとのすぐに使える統合を備えたPythonパッケージ_ * [Wake （新しいタブで開きます）](https://getwake.io/) - _コントラクトのテスト、ファジング、デプロイ、脆弱性スキャン、コードナビゲーションのためのオールインワンPythonフレームワーク (言語サーバー - [Tools for Solidity （新しいタブで開きます）](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity) )_ * [DeFiPy （新しいタブで開きます）](https://github.com/defipy-devs/defipy) - _ユニスワップV2/V3、Balancer、Curveにわたる分散型金融 (DeFi) 分析と自動マーケットメーカー (AMM) シミュレーションのためのPython SDK_ ### [](https://ethereum.org/ja/developers/docs/programming-languages/python/#archived--no-longer-maintained) アーカイブ済み / メンテナンス終了: * [Trinity （新しいタブで開きます）](https://github.com/ethereum/trinity) - _イーサリアムのPythonクライアント_ * [Mamba （新しいタブで開きます）](https://github.com/arjunaskykok/mamba) - _Vyper言語で書かれたスマート・コントラクトを記述、コンパイル、デプロイするためのフレームワーク_ * [Brownie （新しいタブで開きます）](https://github.com/eth-brownie/brownie) - _イーサリアムスマート・コントラクトのデプロイ、テスト、対話のためのPythonフレームワーク_ * [pydevp2p （新しいタブで開きます）](https://github.com/ethereum/pydevp2p) - _イーサリアムP2Pスタックの実装_ * [py-wasm （新しいタブで開きます）](https://github.com/ethereum/py-wasm) - _WebAssemblyインタープリタのPython実装_ さらにリソースをお探しですか？ [ethereum.org/developers](https://ethereum.org/ja/developers/) を確認してください。 [](https://ethereum.org/ja/developers/docs/programming-languages/python/#projects-using-python-tooling) Pythonツールを使用しているプロジェクト ------------------------------------------------------------------------------------------------------------------------------ 以下のイーサリアムベースのプロジェクトは、このページで言及されているツールを使用しています。関連するオープンソースリポジトリは、サンプルコードやベストプラクティスの良い参考になります。 * [Yearn Finance （新しいタブで開きます）](https://yearn.finance/) と [Yearnヴォールトコントラクトのリポジトリ （新しいタブで開きます）](https://github.com/yearn/yearn-vaults) * [Curve （新しいタブで開きます）](https://www.curve.finance/) と [Curveスマート・コントラクトのリポジトリ （新しいタブで開きます）](https://github.com/curvefi/curve-contract) * [BadgerDAO （新しいタブで開きます）](https://badger.com/) と [Brownieツールチェーンを使用したスマート・コントラクト （新しいタブで開きます）](https://github.com/Badger-Finance/badger-system) * [Sushi （新しいタブで開きます）](https://sushi.com/) は [ベスティングコントラクトの管理とデプロイにPythonを使用しています （新しいタブで開きます）](https://github.com/sushiswap/sushi-vesting-protocols) * Alpha Homoraで有名な [Alpha Finance （新しいタブで開きます）](https://alphaventuredao.io/) は、[スマート・コントラクトのテストとデプロイにBrownieを使用しています （新しいタブで開きます）](https://github.com/AlphaFinanceLab/alpha-staking-contract) [](https://ethereum.org/ja/developers/docs/programming-languages/python/#python-community-contributors) Pythonコミュニティのディスカッション ----------------------------------------------------------------------------------------------------------------------------- * Web3.pyやその他のPythonフレームワークに関するディスカッションのための [イーサリアムPythonコミュニティのディスコード （新しいタブで開きます）](https://discord.gg/9zk7snTfWe) * Vyperスマート・コントラクトプログラミングに関するディスカッションのための [Vyperのディスコード （新しいタブで開きます）](https://discord.gg/SdvKC79cJk) [](https://ethereum.org/ja/developers/docs/programming-languages/python/#other-aggregated-lists) その他のまとめリスト ----------------------------------------------------------------------------------------------------------- VyperのWikiには、[Vyperに関する素晴らしいリソースのリスト （新しいタブで開きます）](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources) があります。 --- # 자주 묻는 질문 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#main-content) Change page 자주 묻는 질문 ======== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/consensus-mechanisms/pos/faqs/index.md) 이 페이지의 내용 [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#what-is-proof-of-stake) 지분 증명 (PoS)이란 무엇인가요? ---------------------------------------------------------------------------------------------------------------------- 지분 증명 (PoS)은 부정직하게 행동하는 공격자가 가치 있는 자산을 잃도록 보장함으로써 블록체인에 보안을 제공할 수 있는 알고리즘의 한 종류입니다. 지분 증명 시스템은 검증자 세트가 증명 가능한 부정직한 행동에 가담할 경우 파괴될 수 있는 특정 자산을 제공하도록 요구합니다. 이더리움은 블록체인을 보호하기 위해 지분 증명 메커니즘을 사용합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#comparison-to-proof-of-work) 지분 증명 (PoS)과 작업증명 (PoW)은 어떻게 다른가요? ----------------------------------------------------------------------------------------------------------------------------------------- 작업증명 (PoW)과 지분 증명 (PoS) 모두 악의적인 행위자가 네트워크에 스팸을 보내거나 사기를 치는 것을 경제적으로 억제하는 메커니즘입니다. 두 경우 모두 합의에 적극적으로 참여하는 노드는 잘못된 행동을 할 경우 잃게 될 특정 자산을 "네트워크에" 투입합니다. 작업증명에서 이 자산은 에너지입니다. 채굴자라고 알려진 노드는 다른 어떤 노드보다 빠르게 값을 계산하는 것을 목표로 하는 알고리즘을 실행합니다. 가장 빠른 노드는 체인에 블록을 제안할 권리를 갖습니다. 체인의 기록을 변경하거나 블록 제안을 장악하려면, 채굴자는 항상 경쟁에서 이길 수 있을 만큼 막대한 컴퓨팅 파워를 가져야 합니다. 이는 엄청나게 비싸고 실행하기 어려워 공격으로부터 체인을 보호합니다. 작업증명을 사용하여 "채굴"하는 데 필요한 에너지는 채굴자가 비용을 지불하는 현실 세계의 자산입니다. 지분 증명은 검증자라고 알려진 노드가 스마트 컨트랙트에 암호화폐 자산을 명시적으로 제출하도록 요구합니다. 검증자가 잘못된 행동을 하면, 에너지 소비를 통해 간접적으로 하는 대신 체인에 직접 자산을 "스테이킹"하고 있기 때문에 이 암호화폐는 파괴될 수 있습니다. 작업증명은 채굴 과정에서 전기가 소모되기 때문에 훨씬 더 많은 에너지를 필요로 합니다. 반면 지분 증명은 아주 적은 양의 에너지만 필요로 합니다. 이더리움 검증자는 Raspberry Pi와 같은 저전력 기기에서도 실행될 수 있습니다. 이더리움의 지분 증명 메커니즘은 공격 비용이 더 크고 공격자에게 미치는 결과가 더 가혹하기 때문에 작업증명보다 더 안전한 것으로 간주됩니다. 작업증명 대 지분 증명은 논쟁의 여지가 있는 주제입니다. [비탈릭 부테린의 블로그 (새 탭에서 열림)](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) 와 Justin Drake 및 Lyn Alden 간의 토론은 이러한 주장들을 잘 요약해 줍니다. ### The PoW vs. PoS debate Lyn Alden and Justin Drake debate whether proof of work or proof of stake is best suited for creating a global crypto money system, covering economic security, 51% attack recovery, fairness, and the commodity vs. [대본과 함께 시청하기](https://ethereum.org/ko/videos/pow-vs-pos/)   [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#is-pos-energy-efficient) 지분 증명은 에너지 효율적인가요? --------------------------------------------------------------------------------------------------------------------- 네. 지분 증명 네트워크의 노드는 아주 적은 양의 에너지를 사용합니다. 제3자 연구에 따르면 전체 지분 증명 이더리움 네트워크는 연간 약 0.0026 TWh를 소비하며, 이는 미국 내 게임 산업 소비량의 약 13,000분의 1 수준입니다. [이더리움의 에너지 소비에 대해 자세히 알아보기](https://ethereum.org/ko/energy-consumption/) . [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#is-pos-secure) 지분 증명은 안전한가요? ------------------------------------------------------------------------------------------------------ 이더리움의 지분 증명은 매우 안전합니다. 이 메커니즘은 라이브로 전환되기 전 8년 이상 엄격하게 연구, 개발 및 테스트되었습니다. 보안 보장은 작업증명 블록체인과 다릅니다. 지분 증명에서 악의적인 검증자는 적극적으로 처벌("슬래싱")받고 검증자 세트에서 퇴출될 수 있으며, 이로 인해 상당한 양의 ETH 비용이 발생합니다. 작업증명 하에서는 공격자가 충분한 해시 파워를 가지고 있는 한 공격을 계속 반복할 수 있습니다. 또한 작업증명 하에서보다 지분 증명 이더리움에서 동등한 공격을 수행하는 데 더 많은 비용이 듭니다. 체인의 활성도(liveness)에 영향을 미치려면 네트워크에 스테이킹된 전체 이더의 최소 33%가 필요합니다(성공 가능성이 극히 낮은 매우 정교한 공격의 경우는 제외). 미래 블록의 내용을 제어하려면 전체 스테이킹된 ETH의 최소 51%가 필요하며, 기록을 다시 쓰려면 전체 스테이크의 66% 이상이 필요합니다. 이더리움 프로토콜은 33% 또는 51% 공격 시나리오에서는 이러한 자산을 파괴하고, 66% 공격 시나리오에서는 소셜 합의를 통해 파괴합니다. * [공격자로부터 이더리움 지분 증명 방어하기에 대해 자세히 알아보기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/attack-and-defense/) * [지분 증명 설계에 대해 자세히 알아보기 (새 탭에서 열림)](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#does-pos-make-ethereum-cheaper) 지분 증명으로 인해 이더리움이 더 저렴해지나요? ------------------------------------------------------------------------------------------------------------------------------------ 아니요. 트랜잭션을 보내는 비용(가스비)은 네트워크 수요가 많아질수록 증가하는 동적 수수료 시장에 의해 결정됩니다. 합의 메커니즘은 이에 직접적인 영향을 미치지 않습니다. [가스에 대해 자세히 알아보기](https://ethereum.org/ko/developers/docs/gas/) . [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#what-are-nodes-clients-and-validators) 노드, 클라이언트, 검증자란 무엇인가요? --------------------------------------------------------------------------------------------------------------------------------------- 노드는 이더리움 네트워크에 연결된 컴퓨터입니다. 클라이언트는 컴퓨터를 노드로 바꾸기 위해 실행하는 소프트웨어입니다. 클라이언트에는 실행 클라이언트와 합의 클라이언트의 두 가지 유형이 있습니다. 노드를 생성하려면 두 가지 모두 필요합니다. 검증자는 노드가 지분 증명 합의에 참여할 수 있도록 하는 합의 클라이언트의 선택적 애드온입니다. 이는 선택되었을 때 블록을 생성 및 제안하고, 네트워크에서 수신한 블록을 증명(attest)하는 것을 의미합니다. 검증자를 실행하려면 노드 운영자는 예치 컨트랙트에 32 ETH를 예치해야 합니다. * [노드 및 클라이언트에 대해 자세히 알아보기](https://ethereum.org/ko/developers/docs/nodes-and-clients/) * [스테이킹에 대해 자세히 알아보기](https://ethereum.org/ko/staking/) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#is-pos-new) 지분 증명은 새로운 아이디어인가요? --------------------------------------------------------------------------------------------------------- 아니요. 2011년에 BitcoinTalk의 한 사용자가 비트코인 업그레이드로서 [지분 증명의 기본 아이디어를 제안 (새 탭에서 열림)](https://bitcointalk.org/index.php?topic=27787.0) 했습니다. 이더리움 메인넷에 구현할 준비가 되기까지 11년이 걸렸습니다. 일부 다른 체인들은 이더리움보다 먼저 지분 증명을 구현했지만, 이더리움의 특정 메커니즘(Gasper로 알려짐)은 아니었습니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#why-is-ethereum-pos-special) 이더리움의 지분 증명은 무엇이 특별한가요? ------------------------------------------------------------------------------------------------------------------------------ 이더리움의 지분 증명 메커니즘은 그 설계가 독특합니다. 설계되고 구현된 최초의 지분 증명 메커니즘은 아니지만 가장 강력합니다. 이 지분 증명 메커니즘은 "Casper"로 알려져 있습니다. Casper는 블록을 제안할 검증자를 선택하는 방법, 증명이 이루어지는 방법과 시기, 증명을 계산하는 방법, 검증자에게 주어지는 보상과 페널티, 슬래싱 조건, 비활동 누수와 같은 안전장치 메커니즘, 그리고 "완결성"에 대한 조건을 정의합니다. 완결성은 블록이 정규 체인의 영구적인 부분으로 간주되기 위해 네트워크에 스테이킹된 전체 ETH의 최소 66%가 투표해야 한다는 조건입니다. 연구원들은 이더리움을 위해 특별히 Casper를 개발했으며, 이더리움은 이를 구현한 최초이자 유일한 블록체인입니다. Casper 외에도 이더리움의 지분 증명은 엘엠디 고스트(LMD GHOST)라는 포크 선택 알고리즘을 사용합니다. 이는 동일한 슬롯에 두 개의 블록이 존재하는 상황이 발생할 경우 필요합니다. 이로 인해 블록체인의 두 가지 포크가 생성됩니다. 엘엠디 고스트는 증명의 "가중치"가 가장 큰 것을 선택합니다. 가중치는 검증자의 유효 잔고에 의해 가중치가 부여된 증명의 수입니다. 엘엠디 고스트는 이더리움 고유의 알고리즘입니다. Casper와 엘엠디 고스트의 조합을 Gasper라고 합니다. [Gasper에 대해 자세히 알아보기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/gasper/) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#what-is-slashing) 슬래싱이란 무엇인가요? -------------------------------------------------------------------------------------------------------- 슬래싱은 검증자의 스테이크 일부를 파괴하고 네트워크에서 검증자를 퇴출시키는 것을 일컫는 용어입니다. 슬래싱으로 손실되는 ETH의 양은 슬래싱되는 검증자의 수에 비례합니다. 즉, 공모하는 검증자는 개인보다 더 가혹한 처벌을 받습니다. [슬래싱에 대해 자세히 알아보기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/#slashing) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#why-32-eth) 검증자에게 32 ETH가 필요한 이유는 무엇인가요? ------------------------------------------------------------------------------------------------------------------ 검증자는 잘못된 행동을 할 경우 잃을 것이 있도록 ETH를 스테이킹해야 합니다. 특히 32 ETH를 스테이킹해야 하는 이유는 적당한 사양의 하드웨어에서도 노드를 실행할 수 있도록 하기 위해서입니다. 검증자당 최소 ETH가 더 낮다면 검증자의 수와 각 슬롯에서 처리해야 하는 메시지의 수가 증가하여 노드를 실행하는 데 더 강력한 하드웨어가 필요하게 됩니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#how-are-validators-selected) 검증자는 어떻게 선택되나요? ---------------------------------------------------------------------------------------------------------------------- 블록 제안자의 해시와 매 블록마다 업데이트되는 시드를 혼합하는 RANDAO라는 알고리즘을 사용하여 각 슬롯에서 블록을 제안할 단일 검증자가 의사 난수(pseudo-randomly) 방식으로 선택됩니다. 이 값은 전체 검증자 세트에서 특정 검증자를 선택하는 데 사용됩니다. 검증자 선택은 2 에포크 전에 미리 확정됩니다. [검증자 선택에 대해 자세히 알아보기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/block-proposal/) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#what-is-stake-grinding) 스테이크 그라인딩이란 무엇인가요? -------------------------------------------------------------------------------------------------------------------- 스테이크 그라인딩은 공격자가 검증자 선택 알고리즘을 자신의 검증자에게 유리하도록 편향시키려는 지분 증명 네트워크에 대한 공격 유형입니다. RANDAO에 대한 스테이크 그라인딩 공격에는 전체 스테이킹된 ETH의 약 절반이 필요합니다. [스테이크 그라인딩에 대해 자세히 알아보기 (새 탭에서 열림)](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#what-is-social-slashing) 소셜 슬래싱이란 무엇인가요? ------------------------------------------------------------------------------------------------------------------ 소셜 슬래싱은 공격에 대응하여 커뮤니티가 블록체인의 포크를 조정할 수 있는 능력입니다. 이를 통해 커뮤니티는 공격자가 부정직한 체인을 완결하는 상황에서 복구할 수 있습니다. 소셜 슬래싱은 검열 공격에 대응하는 데에도 사용될 수 있습니다. * [소셜 슬래싱에 대해 자세히 알아보기 (새 탭에서 열림)](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) * [소셜 슬래싱에 대한 비탈릭 부테린의 글 (새 탭에서 열림)](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#will-i-get-slashed) 제가 슬래싱을 당할 수도 있나요? ---------------------------------------------------------------------------------------------------------------- 검증자로서 고의로 악의적인 행동에 가담하지 않는 한 슬래싱을 당하기는 매우 어렵습니다. 슬래싱은 검증자가 동일한 슬롯에 대해 여러 블록을 제안하거나 자신의 증명과 모순되는 매우 특정한 시나리오에서만 구현되며, 이러한 상황이 우연히 발생할 가능성은 매우 낮습니다. [슬래싱 조건에 대해 자세히 알아보기 (새 탭에서 열림)](https://eth2book.info/altair/part2/incentives/slashing) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#what-is-nothing-at-stake-problem) 낫싱 앳 스테이크 문제란 무엇인가요? -------------------------------------------------------------------------------------------------------------------------------- 낫싱 앳 스테이크 문제는 보상만 있고 페널티가 없는 일부 지분 증명 메커니즘의 개념적 문제입니다. 스테이킹된 것이 없다면, 실용적인 검증자는 보상을 늘리기 위해 블록체인의 어떤 포크나 심지어 여러 포크에 증명하는 것을 똑같이 기꺼이 할 것입니다. 이더리움은 완결성 조건과 슬래싱을 사용하여 하나의 정규 체인을 보장함으로써 이 문제를 우회합니다. [낫싱 앳 스테이크 문제에 대해 자세히 알아보기 (새 탭에서 열림)](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#what-is-a-fork-choice-algorithm) 포크 선택 알고리즘이란 무엇인가요? ------------------------------------------------------------------------------------------------------------------------------ 포크 선택 알고리즘은 어느 체인이 정규 체인인지 결정하는 규칙을 구현합니다. 최적의 조건에서는 슬롯당 하나의 블록 제안자와 선택할 수 있는 하나의 블록만 있기 때문에 포크 선택 규칙이 필요하지 않습니다. 하지만 때로는 동일한 슬롯에 대한 여러 블록이나 늦게 도착하는 정보로 인해 체인의 헤드 근처에 있는 블록이 구성되는 방식에 대한 여러 옵션이 생길 수 있습니다. 이러한 경우 모든 클라이언트는 올바른 블록 시퀀스를 선택하도록 일부 규칙을 동일하게 구현해야 합니다. 포크 선택 알고리즘은 이러한 규칙을 인코딩합니다. 이더리움의 포크 선택 알고리즘은 엘엠디 고스트라고 합니다. 이 알고리즘은 증명의 가중치가 가장 큰 포크, 즉 가장 많은 스테이킹된 ETH가 투표한 포크를 선택합니다. [엘엠디 고스트에 대해 자세히 알아보기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#what-is-finality) 지분 증명에서 완결성이란 무엇인가요? ---------------------------------------------------------------------------------------------------------------- 지분 증명에서 완결성은 주어진 블록이 정규 체인의 영구적인 부분이며, 공격자가 전체 스테이킹된 이더의 33%를 소각하는 합의 실패가 발생하지 않는 한 되돌릴 수 없다는 보장입니다. 이는 작업증명 블록체인과 관련된 "확률적 완결성"과 대조되는 "암호경제적" 완결성입니다. 확률적 완결성에서는 블록에 대한 명시적인 완결된/완결되지 않은 상태가 없습니다. 블록이 오래될수록 체인에서 제거될 가능성이 점점 줄어들 뿐이며, 사용자는 블록이 "안전하다"고 충분히 확신할 때를 스스로 결정합니다. 암호경제적 완결성에서는 체크포인트 블록 쌍이 스테이킹된 이더의 66%에 의해 투표되어야 합니다. 이 조건이 충족되면 해당 체크포인트 사이의 블록은 명시적으로 "완결된" 상태가 됩니다. [완결성에 대해 자세히 알아보기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#finality) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#what-is-weak-subjectivity) "약한 주관성"이란 무엇인가요? ---------------------------------------------------------------------------------------------------------------------- 약한 주관성은 소셜 정보를 사용하여 블록체인의 현재 상태를 확인하는 지분 증명 네트워크의 특징입니다. 새로운 노드나 오랫동안 오프라인 상태였다가 네트워크에 다시 참여하는 노드에게 최근 상태를 제공하여 올바른 체인에 있는지 즉시 확인할 수 있도록 합니다. 이러한 상태를 "약한 주관성 체크포인트"라고 하며, 대역 외(out-of-band)의 다른 노드 운영자, 블록 탐색기 또는 여러 퍼블릭 엔드포인트에서 얻을 수 있습니다. [약한 주관성에 대해 자세히 알아보기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#is-pos-censorship-resistant) 지분 증명은 검열 저항적인가요? ------------------------------------------------------------------------------------------------------------------------ 검열 저항성은 현재 증명하기 어렵습니다. 하지만 작업증명과 달리 지분 증명은 검열하는 검증자를 처벌하기 위해 슬래싱을 조정할 수 있는 옵션을 제공합니다. 블록 빌더를 블록 제안자와 분리하고 빌더가 각 블록에 포함해야 하는 트랜잭션 목록을 구현하는 프로토콜 변경 사항이 예정되어 있습니다. 이 제안은 제안자-빌더 분리 (PBS)로 알려져 있으며 검증자가 트랜잭션을 검열하는 것을 방지하는 데 도움이 됩니다. [제안자-빌더 분리 (PBS)에 대해 자세히 알아보기 (새 탭에서 열림)](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#pos-51-attack) 이더리움의 지분 증명 시스템은 51% 공격을 받을 수 있나요? --------------------------------------------------------------------------------------------------------------------------- 네. 지분 증명은 작업증명과 마찬가지로 51% 공격에 취약합니다. 공격자는 네트워크 해시 파워의 51% 대신 전체 스테이킹된 ETH의 51%를 필요로 합니다. 전체 스테이크의 51%를 축적한 공격자는 포크 선택 알고리즘을 제어할 수 있게 됩니다. 이를 통해 공격자는 특정 트랜잭션을 검열하고, 단거리 재구성(reorgs)을 수행하며, 자신에게 유리하게 블록을 재정렬하여 MEV를 추출할 수 있습니다. [지분 증명 공격에 대해 자세히 알아보기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/attack-and-defense/) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#what-is-social-coordination) 소셜 조정이란 무엇이며 왜 필요한가요? ---------------------------------------------------------------------------------------------------------------------------- 소셜 조정은 부정직한 블록을 완결한 공격으로부터 정직한 체인을 복구할 수 있게 해주는 이더리움의 마지막 방어선입니다. 이 경우 이더리움 커뮤니티는 "대역 외(out-of-band)"에서 조정하여 정직한 소수 포크를 사용하기로 합의하고, 그 과정에서 공격자의 검증자를 슬래싱해야 합니다. 이를 위해서는 앱과 거래소도 정직한 포크를 인식해야 합니다. [소셜 조정에 대해 자세히 알아보기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/attack-and-defense/#people-the-last-line-of-defense) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#do-rich-get-richer) 지분 증명에서는 부자가 더 부자가 되나요? --------------------------------------------------------------------------------------------------------------------- 스테이킹할 ETH가 많을수록 더 많은 검증자를 실행할 수 있고 더 많은 보상을 축적할 수 있습니다. 보상은 스테이킹된 ETH의 양에 비례하여 선형적으로 증가하며, 모든 사람이 동일한 비율의 수익을 얻습니다. 작업증명은 지분 증명보다 부자를 더 부유하게 만듭니다. 대규모로 하드웨어를 구매하는 부유한 채굴자가 규모의 경제로 이익을 얻기 때문이며, 이는 부와 보상 간의 관계가 비선형적임을 의미합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#is-pos-decentralized) 지분 증명은 작업증명보다 더 중앙화되어 있나요? -------------------------------------------------------------------------------------------------------------------------- 아니요, 작업증명은 채굴 비용이 증가하여 개인을 시장에서 밀어내고, 그다음에는 소규모 회사를 밀어내는 식으로 진행되기 때문에 중앙화되는 경향이 있습니다. 지분 증명의 현재 문제는 유동성 스테이킹 파생상품(LSD)의 영향력입니다. 이는 누구나 실제 ETH를 언스테이킹하지 않고도 2차 시장에서 스왑할 수 있는, 특정 제공자가 스테이킹한 ETH를 나타내는 토큰입니다. LSD를 사용하면 사용자가 32 ETH 미만으로 스테이킹할 수 있지만, 소수의 대규모 조직이 스테이크의 대부분을 통제하게 되는 중앙화 위험도 발생합니다. 이것이 [솔로 스테이킹](https://ethereum.org/ko/staking/solo/) 이 이더리움을 위한 최선의 선택인 이유입니다. [LSD의 스테이크 중앙화에 대해 자세히 알아보기 (새 탭에서 열림)](https://notes.ethereum.org/@djrtwo/risks-of-lsd) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#why-can-i-only-stake-eth) 왜 ETH만 스테이킹할 수 있나요? ----------------------------------------------------------------------------------------------------------------------- ETH는 이더리움의 기본 통화입니다. 투표 가중치를 위한 유효 잔고 회계 처리와 보안 모두를 위해 모든 스테이크가 표시되는 단일 통화를 갖는 것이 필수적입니다. ETH 자체는 스마트 컨트랙트라기보다는 이더리움의 기본 구성 요소입니다. 다른 통화를 통합하면 복잡성이 크게 증가하고 스테이킹의 보안이 저하됩니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#is-ethereum-the-only-pos-blockchain) 이더리움이 유일한 지분 증명 블록체인인가요? --------------------------------------------------------------------------------------------------------------------------------------- 아니요, 여러 지분 증명 블록체인이 있습니다. 이더리움과 동일한 것은 없으며, 이더리움의 지분 증명 메커니즘은 독특합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#what-is-the-merge) 머지(The Merge)란 무엇인가요? ------------------------------------------------------------------------------------------------------------------ 머지는 이더리움이 작업증명 기반 합의 메커니즘을 끄고 지분 증명 기반 합의 메커니즘을 켠 순간이었습니다. 머지는 2022년 9월 15일에 발생했습니다. [머지에 대해 자세히 알아보기](https://ethereum.org/ko/roadmap/merge/) [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/faqs/#what-are-liveness-and-safety) 활성도(Liveness)와 안전성(Safety)이란 무엇인가요? ------------------------------------------------------------------------------------------------------------------------------------------- 활성도와 안전성은 블록체인의 두 가지 기본적인 보안 고려 사항입니다. 활성도는 완결되는 체인의 가용성입니다. 체인이 완결을 멈추거나 사용자가 쉽게 접근할 수 없다면 이는 활성도 실패입니다. 접근 비용이 극도로 높은 것 또한 활성도 실패로 간주될 수 있습니다. 안전성은 체인을 공격하는 것, 즉 충돌하는 체크포인트를 완결하는 것이 얼마나 어려운지를 나타냅니다. [Casper 백서에서 자세히 알아보기 (새 탭에서 열림)](https://arxiv.org/pdf/1710.09437.pdf) --- # ERC-1363 Payable Token標準 | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/standards/tokens/erc-1363/#main-content) Change page ERC-1363 Payable Token標準 ======================== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/tokens/erc-1363/index.md) このページの内容 [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-1363/#introduction) はじめに ---------------------------------------------------------------------------------------- ### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-1363/#what-is-erc1363) ERC-1363とは? ERC-1363は、送金後の受信先コントラクト、または承認後のspenderコントラクトでカスタムロジックを実行することを、すべて単一のトランザクション内でサポートするERC-20トークンの拡張インターフェースです。 ### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-1363/#erc20-differences) ERC-20との違い `transfer`、`transferFrom`、`approve`のような標準的なERC-20の操作では、別のトランザクションを使用せずに受信先やspenderコントラクトでコードを実行することはできません。 ユーザーは最初のトランザクションが実行されるのを待ってから2つ目のトランザクションを送信しなければならないため、これはユーザーインターフェース (UI) 開発における複雑さや、普及における摩擦をもたらします。 また、ガスを2回支払う必要もあります。 ERC-1363により、代替可能トークン (Fungible Token) はより簡単にアクションを実行できるようになり、オフチェーンのリスナーを使用せずに機能するようになります。 これにより、送金や承認の後に、受信先またはspenderコントラクトへのコールバックを単一のトランザクションで行うことができます。 [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-1363/#prerequisites) 前提条件 ----------------------------------------------------------------------------------------- このページをより深く理解するために、まずは以下の記事を読むことをお勧めします。 * [トークン標準](https://ethereum.org/ja/developers/docs/standards/tokens/) * [ERC-20](https://ethereum.org/ja/developers/docs/standards/tokens/erc-20/) [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-1363/#body) 本文 ------------------------------------------------------------------------------ ERC-1363は、`transfer`、`transferFrom`、または`approve`の後にERC-20トークンがスマート・コントラクトと対話するための標準APIを導入します。 この標準は、トークンを送金する基本的な機能を提供するだけでなく、オンチェーンの第三者が消費できるようにトークンを承認し、その後、受信先またはspenderコントラクトでコールバックを行う機能を提供します。 ERC-20のコールバックを受け入れることができるスマート・コントラクトの用途は数多く提案されています。 例としては以下の通りです。 * **クラウドセール**: トークンの送信により、即座に報酬の割り当てがトリガーされます。 * **サービス**: 支払いがワンステップでサービスへのアクセスを有効にします。 * **請求書**: トークンが自動的に請求書を決済します。 * **サブスクリプション**: 年間料金を承認することで、最初の月の支払いと同時にサブスクリプションが有効になります。 これらの理由から、当初は\*\*「Payable Token」\*\*と名付けられました。 コールバックの動作はその有用性をさらに広げ、以下のようなシームレスな対話を可能にします。 * **ステーキング**: 送金されたトークンが、ステーキングコントラクトでの自動ロックをトリガーします。 * **投票**: 受け取ったトークンが、ガバナンスシステムに投票を登録します。 * **スワップ**: トークンの承認が、ワンステップでスワップロジックを有効にします。 ERC-1363トークンは、送金や承認の受け取り後にコールバックを実行する必要があるすべてのケースにおいて、特定のユーティリティとして使用できます。 また、ERC-1363は、受信者がトークンを処理する能力があるかを確認することで、スマート・コントラクト内でのトークンの喪失やロックを回避するのにも役立ちます。 他のERC-20拡張提案とは異なり、ERC-1363はERC-20の`transfer`および`transferFrom`メソッドをオーバーライドせず、ERC-20との下位互換性を維持しながら実装すべきインターフェースIDを定義しています。 [EIP-1363 （新しいタブで開きます）](https://eips.ethereum.org/EIPS/eip-1363) より: ### [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-1363/#methods) メソッド ERC-1363標準を実装するスマート・コントラクトは、`ERC1363`インターフェースのすべての関数、および`ERC20`と`ERC165`インターフェースを実装**しなければなりません (MUST)**。 pragma solidity ^0.8.0; /** * @title ERC1363 * @dev 単一のトランザクションで、`transfer` または `transferFrom` の後に受信者コントラクトでコードを実行したり、`approve` の後にspenderコントラクトでコードを実行したりすることをサポートする、ERC-20 トークンの拡張インターフェース。 */ interface ERC1363 is ERC20, ERC165 { /* * NOTE: このインターフェースのERC-165識別子は 0xb0202a11 です。 * 0xb0202a11 === * bytes4(keccak256('transferAndCall(address,uint256)')) ^ * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^ * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^ * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^ * bytes4(keccak256('approveAndCall(address,uint256)')) ^ * bytes4(keccak256('approveAndCall(address,uint256,bytes)')) */ /** * @dev 呼び出し元のアカウントから `to` へ `value` 量のトークンを送金し、 * その後 `to` で `ERC1363Receiver::onTransferReceived` を呼び出します。 * @param to トークンが送金されるアドレス。 * @param value 送金されるトークンの量。 * @return 例外がスローされない限り、操作が成功したことを示すブール値。 */ function transferAndCall(address to, uint256 value) external returns (bool); /** * @dev 呼び出し元のアカウントから `to` へ `value` 量のトークンを送金し、 * その後 `to` で `ERC1363Receiver::onTransferReceived` を呼び出します。 * @param to トークンが送金されるアドレス。 * @param value 送金されるトークンの量。 * @param data `to` への呼び出しで送信される、指定されたフォーマットのない追加データ。 * @return 例外がスローされない限り、操作が成功したことを示すブール値。 */ function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool); /** * @dev アローワンスメカニズムを使用して `from` から `to` へ `value` 量のトークンを送金し、 * その後 `to` で `ERC1363Receiver::onTransferReceived` を呼び出します。 * @param from トークンを送信する元のアドレス。 * @param to トークンが送金されるアドレス。 * @param value 送金されるトークンの量。 * @return 例外がスローされない限り、操作が成功したことを示すブール値。 */ function transferFromAndCall(address from, address to, uint256 value) external returns (bool); /** * @dev アローワンスメカニズムを使用して `from` から `to` へ `value` 量のトークンを送金し、 * その後 `to` で `ERC1363Receiver::onTransferReceived` を呼び出します。 * @param from トークンを送信する元のアドレス。 * @param to トークンが送金されるアドレス。 * @param value 送金されるトークンの量。 * @param data `to` への呼び出しで送信される、指定されたフォーマットのない追加データ。 * @return 例外がスローされない限り、操作が成功したことを示すブール値。 */ function transferFromAndCall(address from, address to, uint256 value, bytes calldata data) external returns (bool); /** * @dev 呼び出し元のトークンに対する `spender` のアローワンスとして `value` 量のトークンを設定し、 * その後 `spender` で `ERC1363Spender::onApprovalReceived` を呼び出します。 * @param spender 資金を消費するアドレス。 * @param value 消費されるトークンの量。 * @return 例外がスローされない限り、操作が成功したことを示すブール値。 */ function approveAndCall(address spender, uint256 value) external returns (bool); /** * @dev 呼び出し元のトークンに対する `spender` のアローワンスとして `value` 量のトークンを設定し、 * その後 `spender` で `ERC1363Spender::onApprovalReceived` を呼び出します。 * @param spender 資金を消費するアドレス。 * @param value 消費されるトークンの量。 * @param data `spender` への呼び出しで送信される、指定されたフォーマットのない追加データ。 * @return 例外がスローされない限り、操作が成功したことを示すブール値。 */ function approveAndCall(address spender, uint256 value, bytes calldata data) external returns (bool); } interface ERC20 { event Transfer(address indexed from, address indexed to, uint256 value); event Approval(address indexed owner, address indexed spender, uint256 value); function transfer(address to, uint256 value) external returns (bool); function transferFrom(address from, address to, uint256 value) external returns (bool); function approve(address spender, uint256 value) external returns (bool); function totalSupply() external view returns (uint256); function balanceOf(address account) external view returns (uint256); function allowance(address owner, address spender) external view returns (uint256); } interface ERC165 { function supportsInterface(bytes4 interfaceId) external view returns (bool); } コピーSolidity すべて表示 (92) `transferAndCall`または`transferFromAndCall`を介してERC-1363トークンを受け入れたいスマート・コントラクトは、`ERC1363Receiver`インターフェースを実装**しなければなりません (MUST)**。 /** * @title ERC1363Receiver * @dev ERC-1363 トークンコントラクトからの `transferAndCall` または `transferFromAndCall` をサポートしたい任意のコントラクトのためのインターフェース。 */ interface ERC1363Receiver { /** * @dev ERC-1363 トークンが `operator` によって `from` から `ERC1363::transferAndCall` または `ERC1363::transferFromAndCall` を介してこのコントラクトに送金されるたびに、この関数が呼び出されます。 * * NOTE: 送金を受け入れるには、これは * `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` * （すなわち 0x88a7ca5c、またはそれ自身の関数セレクタ）を返さなければなりません。 * * @param operator `transferAndCall` または `transferFromAndCall` 関数を呼び出したアドレス。 * @param from トークンが送金される元のアドレス。 * @param value 送金されたトークンの量。 * @param data 指定されたフォーマットのない追加データ。 * @return 例外がスローされず送金が許可される場合は `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))`。 */ function onTransferReceived(address operator, address from, uint256 value, bytes calldata data) external returns (bytes4); } コピーSolidity すべて表示 (20) `approveAndCall`を介してERC-1363トークンを受け入れたいスマート・コントラクトは、`ERC1363Spender`インターフェースを実装**しなければなりません (MUST)**。 /** * @title ERC1363Spender * @dev ERC-1363 トークンコントラクトからの `approveAndCall` をサポートしたい任意のコントラクトのためのインターフェース。 */ interface ERC1363Spender { /** * @dev ERC-1363 トークンの `owner` が `ERC1363::approveAndCall` を介してこのコントラクトにトークンの消費を承認するたびに、この関数が呼び出されます。 * * NOTE: 承認を受け入れるには、これは * `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` * （すなわち 0x7b04a2d0、またはそれ自身の関数セレクタ）を返さなければなりません。 * * @param owner `approveAndCall` 関数を呼び出し、以前にトークンを所有していたアドレス。 * @param value 消費されるトークンの量。 * @param data 指定されたフォーマットのない追加データ。 * @return 例外がスローされず承認が許可される場合は `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))`。 */ function onApprovalReceived(address owner, uint256 value, bytes calldata data) external returns (bytes4); } コピーSolidity すべて表示 (19) [](https://ethereum.org/ja/developers/docs/standards/tokens/erc-1363/#further-reading) 参考文献 ------------------------------------------------------------------------------------------- * [ERC-1363: Payable Token標準 （新しいタブで開きます）](https://eips.ethereum.org/EIPS/eip-1363) * [ERC-1363: GitHubリポジトリ （新しいタブで開きます）](https://github.com/vittominacori/erc1363-payable-token) --- # Chaneli za Hali | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/scaling/state-channels/#main-content) Change page Chaneli za Hali =============== Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/scaling/state-channels/index.md) Kwenye ukurasa huu Chaneli za hali huruhusu washiriki kufanya miamala kwa usalama nje ya mnyororo huku wakiweka mwingiliano na Mtandao Mkuu wa [Ethereum](https://ethereum.org/sw/) kwa kiwango cha chini. Wenza wa chaneli wanaweza kufanya idadi yoyote ya miamala nje ya mnyororo huku wakiwasilisha miamala miwili tu mnyororoni kufungua na kufunga chaneli. Hii inaruhusu uwezo wa upitishaji wa miamala wa juu sana na kusababisha gharama nafuu kwa watumiaji. [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#prerequisites) Mahitaji ya awali --------------------------------------------------------------------------------------------------- Unapaswa kuwa umesoma na kuelewa kurasa zetu kuhusu [kuongeza viwango vya Ethereum](https://ethereum.org/sw/developers/docs/scaling/) na [tabaka la 2 (l2)](https://ethereum.org/sw/layer-2/) . [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#what-are-channels) Chaneli ni nini? ------------------------------------------------------------------------------------------------------ Minyororo ya vitalu ya umma, kama vile Ethereum, inakabiliwa na changamoto za kuongeza viwango kutokana na usanifu wao uliosambazwa: miamala mnyororoni lazima itekelezwe na nodi zote. Nodi zinapaswa kuwa na uwezo wa kushughulikia kiasi cha miamala katika kitalu kwa kutumia maunzi ya kawaida, kuweka kikomo kwenye uwezo wa upitishaji wa miamala ili kuweka mtandao uliogatuliwa. Chaneli za mnyororo wa vitalu hutatua tatizo hili kwa kuruhusu watumiaji kuingiliana nje ya mnyororo huku bado wakitegemea usalama wa mnyororo mkuu kwa ukamilishaji wa mwisho. Chaneli ni itifaki rahisi za rika-kwa-rika zinazoruhusu pande mbili kufanya miamala mingi kati yao na kisha kuchapisha tu matokeo ya mwisho kwenye mnyororo wa vitalu. Chaneli hutumia kriptografia kuonyesha kwamba data ya muhtasari wanayozalisha ni kweli matokeo ya seti halali ya miamala ya kati. Mkataba mahiri wa ["saini-nyingi"](https://ethereum.org/sw/developers/docs/smart-contracts/#multisig) huhakikisha miamala inasainiwa na pande sahihi. Kwa chaneli, mabadiliko ya hali hutekelezwa na kuthibitishwa na pande zinazohusika, kupunguza ukokotoaji kwenye tabaka la utekelezaji la Ethereum. Hii hupunguza msongamano kwenye Ethereum na pia huongeza kasi ya uchakataji wa miamala kwa watumiaji. Kila chaneli inasimamiwa na [mkataba mahiri wa saini-nyingi](https://ethereum.org/sw/developers/docs/smart-contracts/#multisig) unaoendeshwa kwenye Ethereum. Ili kufungua chaneli, washiriki husambaza mkataba wa chaneli mnyororoni na kuweka fedha ndani yake. Pande zote mbili kwa pamoja husaini sasisho la hali ili kuanzisha hali ya chaneli, baada ya hapo wanaweza kufanya miamala haraka na kwa uhuru nje ya mnyororo. Ili kufunga chaneli, washiriki huwasilisha hali ya mwisho iliyokubaliwa ya chaneli mnyororoni. Baadaye, mkataba mahiri husambaza fedha zilizofungwa kulingana na salio la kila mshiriki katika hali ya mwisho ya chaneli. Chaneli za rika-kwa-rika ni muhimu sana kwa hali ambapo baadhi ya washiriki waliotambuliwa awali wanataka kufanya miamala kwa masafa ya juu bila kupata gharama za ziada zinazoonekana. Chaneli za mnyororo wa vitalu ziko chini ya makundi mawili: **chaneli za malipo** na **chaneli za hali**. [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#payment-channels) Chaneli za malipo ------------------------------------------------------------------------------------------------------ Chaneli ya malipo inaelezewa vyema kama "leja ya njia mbili" inayodumishwa kwa pamoja na watumiaji wawili. Salio la awali la leja ni jumla ya amana zilizofungwa kwenye mkataba mnyororoni wakati wa awamu ya kufungua chaneli. Uhamishaji wa chaneli ya malipo unaweza kufanywa papo hapo na bila ushiriki wa mnyororo wa vitalu wenyewe, isipokuwa kwa uundaji wa awali wa mara moja mnyororoni na kufungwa kwa mwisho kwa chaneli. Masasisho ya salio la leja (yaani, hali ya chaneli ya malipo) yanahitaji idhini ya pande zote katika chaneli. Sasisho la chaneli, lililosainiwa na washiriki wote wa chaneli, linachukuliwa kuwa liliokamilishwa, sawa na muamala kwenye Ethereum. Chaneli za malipo zilikuwa miongoni mwa suluhisho za awali za kuongeza viwango zilizoundwa kupunguza shughuli za gharama kubwa mnyororoni za mwingiliano rahisi wa watumiaji (k.m., uhamishaji wa ETH, ubadilishanaji wa atomiki, malipo madogo). Washiriki wa chaneli wanaweza kufanya kiasi kisicho na kikomo cha miamala ya papo hapo, isiyo na ada kati yao mradi tu jumla halisi ya uhamishaji wao haizidi tokeni zilizowekwa. [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#state-channels) Chaneli za hali -------------------------------------------------------------------------------------------------- Mbali na kusaidia malipo nje ya mnyororo, chaneli za malipo hazijathibitika kuwa na manufaa kwa kushughulikia mantiki ya jumla ya mpito wa hali. Chaneli za hali ziliundwa kutatua tatizo hili na kufanya chaneli kuwa na manufaa kwa kuongeza viwango vya ukokotoaji wa madhumuni ya jumla. Chaneli za hali bado zina mambo mengi yanayofanana na chaneli za malipo. Kwa mfano, watumiaji huingiliana kwa kubadilishana ujumbe uliosainiwa kwa kriptografia (miamala), ambao washiriki wengine wa chaneli lazima pia wasaini. Ikiwa sasisho la hali lililopendekezwa halijasainiwa na washiriki wote, linachukuliwa kuwa batili. Hata hivyo, pamoja na kushikilia salio la mtumiaji, chaneli pia hufuatilia hali ya sasa ya hifadhi ya mkataba (yaani, thamani za vigezo vya mkataba). Hii inafanya iwezekane kutekeleza mkataba mahiri nje ya mnyororo kati ya watumiaji wawili. Katika hali hii, masasisho ya hali ya ndani ya mkataba mahiri yanahitaji tu idhini ya wenza waliounda chaneli. Ingawa hii inatatua tatizo la kuongeza viwango lililoelezwa hapo awali, ina athari kwa usalama. Kwenye Ethereum, uhalali wa mabadiliko ya hali unatekelezwa na itifaki ya mwafaka ya mtandao. Hii inafanya iwezekane kupendekeza sasisho batili kwa hali ya mkataba mahiri au kubadilisha utekelezaji wa mkataba mahiri. Chaneli za hali hazina dhamana sawa za usalama. Kwa kiasi fulani, chaneli ya hali ni toleo dogo la Mtandao Mkuu. Kwa kuwa na seti ndogo ya washiriki wanaotekeleza sheria, uwezekano wa tabia mbaya (k.m., kupendekeza masasisho batili ya hali) huongezeka. Chaneli za hali hupata usalama wao kutoka kwa mfumo wa usuluhishi wa migogoro unaotegemea . [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#how-state-channels-work) Jinsi chaneli za hali zinavyofanya kazi ----------------------------------------------------------------------------------------------------------------------------------- Kimsingi, shughuli katika chaneli ya hali ni kipindi cha mwingiliano kinachohusisha watumiaji na mfumo wa mnyororo wa vitalu. Watumiaji mara nyingi huwasiliana wao kwa wao nje ya mnyororo na huingiliana tu na mnyororo wa vitalu wa msingi kufungua chaneli, kufunga chaneli, au kusuluhisha migogoro inayoweza kutokea kati ya washiriki. Sehemu ifuatayo inaelezea mtiririko wa msingi wa kazi wa chaneli ya hali: ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#opening-the-channel) Kufungua chaneli Kufungua chaneli kunahitaji washiriki kuweka fedha kwenye mkataba mahiri kwenye Mtandao Mkuu. Amana pia hufanya kazi kama kichupo pepe, hivyo wahusika wanaoshiriki wanaweza kufanya miamala kwa uhuru bila kuhitaji kukamilisha malipo mara moja. Ni pale tu chaneli inapokamilishwa mnyororoni ndipo pande zote hukamilishana na kutoa kile kilichosalia kwenye kichupo chao. Amana hii pia hutumika kama dhamana ya kuhakikisha tabia ya uaminifu kutoka kwa kila mshiriki. Ikiwa waweka amana watapatikana na hatia ya vitendo viovu wakati wa awamu ya utatuzi wa migogoro, mkataba hupunguza amana yao. Wenza wa chaneli lazima wasaini hali ya awali, ambayo wote wanakubaliana. Hii hutumika kama mwanzo wa chaneli ya hali, baada ya hapo watumiaji wanaweza kuanza kufanya miamala. ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#using-the-channel) Kutumia chaneli Baada ya kuanzisha hali ya chaneli, wenza huingiliana kwa kusaini miamala na kutumiana kwa idhini. Washiriki huanzisha masasisho ya hali kwa miamala hii na kusaini masasisho ya hali kutoka kwa wengine. Kila muamala unajumuisha yafuatayo: * **Nonsi**, ambayo hufanya kazi kama kitambulisho cha kipekee cha miamala na kuzuia mashambulizi ya kurudia. Pia hutambua mpangilio ambao masasisho ya hali yalitokea (ambayo ni muhimu kwa utatuzi wa migogoro) * Hali ya zamani ya chaneli * Hali mpya ya chaneli * Muamala unaosababisha mpito wa hali (k.m., Alice anamtumia Bob 5 ETH) Masasisho ya hali katika chaneli hayatangazwi mnyororoni kama ilivyo kawaida wakati watumiaji wanaingiliana kwenye Mtandao Mkuu, ambayo inaendana na lengo la chaneli za hali la kupunguza alama mnyororoni. Mradi tu washiriki wanakubaliana juu ya masasisho ya hali, yanakuwa ya mwisho kama muamala wa Ethereum. Washiriki wanahitaji tu kutegemea mwafaka wa Mtandao Mkuu ikiwa mgogoro utatokea. ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#closing-the-channel) Kufunga chaneli Kufunga chaneli ya hali kunahitaji kuwasilisha hali ya mwisho, iliyokubaliwa ya chaneli kwenye mkataba mahiri mnyororoni. Maelezo yaliyorejelewa katika sasisho la hali yanajumuisha idadi ya hatua za kila mshiriki na orodha ya miamala iliyoidhinishwa. Baada ya kuthibitisha kuwa sasisho la hali ni halali (yaani, limesainiwa na pande zote) mkataba mahiri hukamilisha chaneli na kusambaza fedha zilizofungwa kulingana na matokeo ya chaneli. Malipo yaliyofanywa nje ya mnyororo yanatumika kwa hali ya Ethereum na kila mshiriki hupokea sehemu yake iliyosalia ya fedha zilizofungwa. Hali iliyoelezwa hapo juu inawakilisha kile kinachotokea katika hali nzuri. Wakati mwingine, watumiaji wanaweza kushindwa kufikia makubaliano na kukamilisha chaneli (hali mbaya). Yoyote kati ya yafuatayo yanaweza kuwa kweli kuhusu hali hiyo: * Washiriki huenda nje ya mtandao na kushindwa kupendekeza mabadiliko ya hali * Washiriki wanakataa kusaini kwa pamoja masasisho halali ya hali * Washiriki wanajaribu kukamilisha chaneli kwa kupendekeza sasisho la hali ya zamani kwenye mkataba mnyororoni * Washiriki wanapendekeza mabadiliko batili ya hali ili wengine wasaini Kila wakati mwafaka unapovunjika kati ya wahusika wanaoshiriki katika chaneli, chaguo la mwisho ni kutegemea mwafaka wa Mtandao Mkuu kutekeleza hali ya mwisho, halali ya chaneli. Katika kesi hii, kufunga chaneli ya hali kunahitaji kusuluhisha migogoro mnyororoni. ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#settling-disputes) Kusuluhisha migogoro Kwa kawaida, pande katika chaneli hukubaliana kufunga chaneli mapema na kusaini kwa pamoja mpito wa mwisho wa hali, ambao wanauwasilisha kwenye mkataba mahiri. Mara tu sasisho linapoidhinishwa mnyororoni, utekelezaji wa mkataba mahiri nje ya mnyororo huisha na washiriki hujitoa kwenye chaneli na pesa zao. Hata hivyo, upande mmoja unaweza kuwasilisha ombi mnyororoni la kumaliza utekelezaji wa mkataba mahiri na kukamilisha chaneli—bila kusubiri idhini ya mwenza wao. Ikiwa yoyote kati ya hali za kuvunja mwafaka zilizoelezwa hapo awali zitatokea, upande wowote unaweza kuanzisha mkataba mnyororoni kufunga chaneli na kusambaza fedha. Hii hutoa **hali ya kutohitaji kuamini**, kuhakikisha kwamba pande waaminifu wanaweza kujitoa na amana zao wakati wowote, bila kujali vitendo vya upande mwingine. Ili kuchakata kujitoa kwenye chaneli, mtumiaji lazima awasilishe sasisho la mwisho halali la hali ya programu kwenye mkataba mnyororoni. Ikiwa hii itathibitishwa (yaani, ina saini ya pande zote), basi fedha zinasambazwa tena kwa faida yao. Hata hivyo, kuna ucheleweshaji katika kutekeleza maombi ya kujitoa ya mtumiaji mmoja. Ikiwa ombi la kuhitimisha chaneli liliidhinishwa kwa kauli moja, basi muamala wa kujitoa mnyororoni unatekelezwa mara moja. Ucheleweshaji hutokea katika kujitoa kwa mtumiaji mmoja kutokana na uwezekano wa vitendo vya udanganyifu. Kwa mfano, mshiriki wa chaneli anaweza kujaribu kukamilisha chaneli kwenye Ethereum kwa kuwasilisha sasisho la hali ya zamani mnyororoni. Kama hatua ya kupinga, chaneli za hali huruhusu watumiaji waaminifu kupinga masasisho batili ya hali kwa kuwasilisha hali ya hivi punde, halali ya chaneli mnyororoni. Chaneli za hali zimeundwa kwa njia ambayo masasisho mapya ya hali yaliyokubaliwa yanashinda masasisho ya hali ya zamani. Mara tu mwenza anapoanzisha mfumo wa utatuzi wa migogoro mnyororoni, upande mwingine unahitajika kujibu ndani ya kikomo cha muda (kinachoitwa dirisha la changamoto). Hii inaruhusu watumiaji kupinga muamala wa kujitoa, hasa ikiwa upande mwingine unatumia sasisho lililopitwa na wakati. Vyovyote itakavyokuwa, watumiaji wa chaneli daima wana dhamana dhabiti za ukamilifu: ikiwa mpito wa hali walio nao ulisainiwa na wanachama wote na ndio sasisho la hivi punde, basi una ukamilifu sawa na muamala wa kawaida mnyororoni. Bado wanapaswa kupinga upande mwingine mnyororoni, lakini matokeo pekee yanayowezekana ni kukamilisha hali ya mwisho halali, ambayo wanashikilia. ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#how-do-state-channels-interact-with-ethereum) Je, chaneli za hali zinaingilianaje na Ethereum? Ingawa zipo kama itifaki za nje ya mnyororo, chaneli za hali zina sehemu mnyororoni: mkataba mahiri uliosambazwa kwenye Ethereum wakati wa kufungua chaneli. Mkataba huu unadhibiti mali zilizowekwa kwenye chaneli, huthibitisha masasisho ya hali, na kusuluhisha migogoro kati ya washiriki. Chaneli za hali hazichapishi data ya muamala au ahadi za hali kwenye Mtandao Mkuu, tofauti na suluhisho za kuongeza viwango za [tabaka la 2 (l2)](https://ethereum.org/sw/layer-2/) . Hata hivyo, zimeunganishwa zaidi na Mtandao Mkuu kuliko, tuseme, [minyororo ya kando](https://ethereum.org/sw/developers/docs/scaling/sidechains/) , na kuzifanya kuwa salama kiasi. Chaneli za hali zinategemea itifaki kuu ya Ethereum kwa yafuatayo: #### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#liveness) 1\. Upatikanaji Mkataba mnyororoni uliosambazwa wakati wa kufungua chaneli unawajibika kwa utendaji wa chaneli. Ikiwa mkataba unaendeshwa kwenye Ethereum, basi chaneli inapatikana kila wakati kwa matumizi. Kinyume chake, mnyororo wa kando unaweza kushindwa kila wakati, hata kama Mtandao Mkuu unafanya kazi, na kuweka fedha za watumiaji hatarini. #### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#security) 2\. Usalama Kwa kiasi fulani, chaneli za hali zinategemea Ethereum kutoa usalama na kulinda watumiaji dhidi ya wenza waovu. Kama ilivyojadiliwa katika sehemu za baadaye, chaneli hutumia utaratibu wa ushahidi wa udanganyifu unaoruhusu watumiaji kupinga majaribio ya kukamilisha chaneli kwa sasisho batili au lililopitwa na wakati. Katika kesi hii, upande mwaminifu hutoa hali ya hivi punde halali ya chaneli kama ushahidi wa udanganyifu kwenye mkataba mnyororoni kwa uthibitisho. Ushahidi wa udanganyifu huwezesha pande zisizoaminiana kufanya miamala nje ya mnyororo bila kuhatarisha fedha zao katika mchakato huo. #### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#finality) 3\. Ukamilifu Masasisho ya hali yaliyosainiwa kwa pamoja na watumiaji wa chaneli yanachukuliwa kuwa mazuri kama miamala mnyororoni. Bado, shughuli zote ndani ya chaneli hufikia ukamilifu wa kweli tu wakati chaneli inafungwa kwenye Ethereum. Katika hali ya matumaini, pande zote mbili zinaweza kushirikiana na kusaini sasisho la mwisho la hali na kuwasilisha mnyororoni kufunga chaneli, baada ya hapo fedha zinasambazwa kulingana na hali ya mwisho ya chaneli. Katika hali ya kukata tamaa, ambapo mtu anajaribu kudanganya kwa kuchapisha sasisho lisilo sahihi la hali mnyororoni, muamala wao haukamilishwi hadi dirisha la changamoto lipite. [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#virtual-state-channels) Chaneli pepe za hali --------------------------------------------------------------------------------------------------------------- Utekelezaji wa kimsingi wa chaneli ya hali ungekuwa kusambaza mkataba mpya wakati watumiaji wawili wanataka kutekeleza programu nje ya mnyororo. Hii sio tu haiwezekani, lakini pia inakanusha ufanisi wa gharama wa chaneli za hali (gharama za miamala mnyororoni zinaweza kuongezeka haraka). Ili kutatua tatizo hili, "chaneli pepe" ziliundwa. Tofauti na chaneli za kawaida zinazohitaji miamala mnyororoni kufungua na kusitisha, chaneli pepe inaweza kufunguliwa, kutekelezwa, na kukamilishwa bila kuingiliana na mnyororo mkuu. Inawezekana hata kusuluhisha migogoro nje ya mnyororo kwa kutumia njia hii. Mfumo huu unategemea uwepo wa kile kinachoitwa "chaneli za leja", ambazo zimefadhiliwa mnyororoni. Chaneli pepe kati ya pande mbili zinaweza kujengwa juu ya chaneli ya leja iliyopo, huku mmiliki (wamiliki) wa chaneli ya leja akitumika kama mpatanishi. Watumiaji katika kila chaneli pepe huingiliana kupitia mfano mpya wa mkataba, huku chaneli ya leja ikiwa na uwezo wa kusaidia mifano mingi ya mkataba. Hali ya chaneli ya leja pia ina zaidi ya hali moja ya hifadhi ya mkataba, ikiruhusu utekelezaji sambamba wa programu nje ya mnyororo kati ya watumiaji tofauti. Kama tu chaneli za kawaida, watumiaji hubadilishana masasisho ya hali ili kuendeleza mashine ya hali. Isipokuwa mgogoro utokee, mpatanishi anahitaji tu kuwasiliana naye wakati wa kufungua au kusitisha chaneli. ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#virtual-payment-channels) Chaneli pepe za malipo Chaneli pepe za malipo hufanya kazi kwa wazo sawa na chaneli pepe za hali: washiriki waliounganishwa kwenye mtandao mmoja wanaweza kupitisha ujumbe bila kuhitaji kufungua chaneli mpya mnyororoni. Katika chaneli pepe za malipo, uhamishaji wa thamani hupitishwa kupitia mpatanishi mmoja au zaidi, na dhamana kwamba mpokeaji aliyekusudiwa pekee ndiye anayeweza kupokea fedha zilizohamishwa. [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#applications-of-state-channels) Matumizi ya chaneli za hali ------------------------------------------------------------------------------------------------------------------------------ ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#payments) Malipo Chaneli za awali za mnyororo wa vitalu zilikuwa itifaki rahisi zilizoruhusu washiriki wawili kufanya uhamishaji wa haraka, wa ada ya chini nje ya mnyororo bila kulazimika kulipa ada kubwa za miamala kwenye Mtandao Mkuu. Leo, chaneli za malipo bado ni muhimu kwa programu zilizoundwa kwa ajili ya ubadilishanaji na amana za Etha na tokeni. Malipo yanayotegemea chaneli yana faida zifuatazo: 1. **Uwezo wa upitishaji**: Kiasi cha miamala nje ya mnyororo kwa kila chaneli hakijaunganishwa na uwezo wa upitishaji wa Ethereum, ambao unaathiriwa na mambo mbalimbali, hasa ukubwa wa kitalu na muda wa kitalu. Kwa kutekeleza miamala nje ya mnyororo, chaneli za mnyororo wa vitalu zinaweza kufikia uwezo wa upitishaji wa juu zaidi. 2. **Faragha**: Kwa sababu chaneli zipo nje ya mnyororo, maelezo ya mwingiliano kati ya washiriki hayarekodiwi kwenye mnyororo wa vitalu wa umma wa Ethereum. Watumiaji wa chaneli wanahitaji tu kuingiliana mnyororoni wakati wa kufadhili na kufunga chaneli au kusuluhisha migogoro. Hivyo, chaneli ni muhimu kwa watu binafsi wanaotaka miamala ya faragha zaidi. 3. **Ucheleweshaji**: Miamala nje ya mnyororo inayofanywa kati ya washiriki wa chaneli inaweza kukamilishwa papo hapo, ikiwa pande zote mbili zitashirikiana, na kupunguza ucheleweshaji. Kinyume chake, kutuma muamala kwenye Mtandao Mkuu kunahitaji kusubiri nodi kuchakata muamala, kuzalisha kitalu kipya na muamala, na kufikia mwafaka. Watumiaji wanaweza pia kuhitaji kusubiri uthibitisho zaidi wa kitalu kabla ya kuchukulia muamala kuwa uliokamilishwa. 4. **Gharama**: Chaneli za hali ni muhimu sana katika hali ambapo seti ya washiriki watabadilishana masasisho mengi ya hali kwa muda mrefu. Gharama pekee zinazopatikana ni kufungua na kufunga mkataba mahiri wa chaneli ya hali; kila mabadiliko ya hali kati ya kufungua na kufunga chaneli yatakuwa nafuu kuliko ya mwisho kwani gharama ya ukamilishaji inasambazwa ipasavyo. Kutekeleza chaneli za hali kwenye suluhisho za tabaka la 2 (l2), kama vile [mikusanyiko](https://ethereum.org/sw/developers/docs/scaling/#rollups) , kunaweza kuzifanya zivutie zaidi kwa malipo. Ingawa chaneli hutoa malipo ya bei nafuu, gharama za kuanzisha mkataba mnyororoni kwenye Mtandao Mkuu wakati wa awamu ya kufungua zinaweza kuwa ghali—hasa wakati ada za gesi zinapopanda. Mikusanyiko inayotegemea Ethereum hutoa [ada za chini za miamala (inafunguka katika kichupo kipya)](https://l2fees.info/) na inaweza kupunguza gharama za ziada kwa washiriki wa chaneli kwa kupunguza ada za usanidi. ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#microtransactions) Miamala midogo Miamala midogo ni malipo ya thamani ya chini (k.m., chini ya sehemu ya dola) ambayo biashara haziwezi kuchakata bila kupata hasara. Mashirika haya lazima yalipe watoa huduma za malipo, jambo ambalo hawawezi kufanya ikiwa faida kwenye malipo ya wateja ni ndogo sana kupata faida. Chaneli za malipo hutatua tatizo hili kwa kupunguza gharama za ziada zinazohusiana na miamala midogo. Kwa mfano, Mtoa Huduma za Mtandao (ISP) anaweza kufungua chaneli ya malipo na mteja, na kuwaruhusu kutiririsha malipo madogo kila wakati wanapotumia huduma. Zaidi ya gharama ya kufungua na kufunga chaneli, washiriki hawapati gharama zaidi kwenye miamala midogo (hakuna ada za gesi). Hii ni hali ya kushinda na kushinda kwani wateja wana unyumbufu zaidi katika kiasi wanacholipa kwa huduma na biashara hazipotezi miamala midogo yenye faida. ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#decentralized-applications) Programu tumizi zilizogatuliwa Kama chaneli za malipo, chaneli za hali zinaweza kufanya malipo ya masharti kulingana na hali za mwisho za mashine ya hali. Chaneli za hali pia zinaweza kusaidia mantiki ya mpito wa hali kiholela, na kuzifanya kuwa muhimu kwa kutekeleza programu za jumla nje ya mnyororo. Chaneli za hali mara nyingi hupunguzwa kwa programu rahisi za zamu, kwani hii inafanya iwe rahisi kusimamia fedha zilizowekwa kwenye mkataba mnyororoni. Pia, kwa idadi ndogo ya pande zinazosasisha hali ya programu nje ya mnyororo kwa vipindi, kuadhibu tabia isiyo ya uaminifu ni rahisi kiasi. Ufanisi wa programu ya chaneli ya hali pia unategemea muundo wake. Kwa mfano, msanidi programu anaweza kusambaza mkataba wa chaneli ya programu mnyororoni mara moja na kuruhusu wachezaji wengine kutumia tena programu bila kulazimika kwenda mnyororoni. Katika kesi hii, chaneli ya awali ya programu hutumika kama chaneli ya leja inayosaidia chaneli pepe nyingi, kila moja ikiendesha mfano mpya wa mkataba mahiri wa programu nje ya mnyororo. Kesi inayowezekana ya matumizi ya programu za chaneli ya hali ni michezo rahisi ya wachezaji wawili, ambapo fedha zinasambazwa kulingana na matokeo ya mchezo. Faida hapa ni kwamba wachezaji hawapaswi kuaminiana (hali ya kutohitaji kuamini) na mkataba mnyororoni, sio wachezaji, unadhibiti ugawaji wa fedha na usuluhishi wa migogoro (ugatuzi). Kesi nyingine zinazowezekana za matumizi ya programu za chaneli ya hali ni pamoja na umiliki wa jina la ENS, leja za NFT, na mengine mengi. ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#atomic-transfers) Uhamishaji wa atomiki Chaneli za awali za malipo zilizuiliwa kwa uhamishaji kati ya pande mbili, na kupunguza matumizi yao. Hata hivyo, kuanzishwa kwa chaneli pepe kuliruhusu watu binafsi kupitisha uhamishaji kupitia wapatanishi (yaani, chaneli nyingi za rika-kwa-rika) bila kulazimika kufungua chaneli mpya mnyororoni. Kwa kawaida huelezewa kama "uhamishaji wa kuruka mara nyingi", malipo yaliyopitishwa ni ya atomiki (yaani, ama sehemu zote za muamala zinafanikiwa au inashindwa kabisa). Uhamishaji wa atomiki hutumia [Mikataba ya Kufunga Muda Iliyosimbwa (HTLCs) (inafunguka katika kichupo kipya)](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts) kuhakikisha malipo yanatolewa tu ikiwa masharti fulani yametimizwa, na hivyo kupunguza hatari ya upande mwingine. [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#drawbacks-of-state-channels) Hasara za kutumia chaneli za hali --------------------------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#liveness-assumptions) Mawazo ya upatikanaji Ili kuhakikisha ufanisi, chaneli za hali huweka mipaka ya muda juu ya uwezo wa washiriki wa chaneli kujibu migogoro. Sheria hii inachukulia kwamba wenza watakuwa mtandaoni kila wakati kufuatilia shughuli za chaneli na kupinga changamoto inapobidi. Kwa kweli, watumiaji wanaweza kwenda nje ya mtandao kwa sababu zilizo nje ya uwezo wao (k.m., muunganisho mbaya wa mtandao, hitilafu ya kimitambo, n.k.). Ikiwa mtumiaji mwaminifu ataenda nje ya mtandao, mwenza mwovu anaweza kutumia hali hiyo kwa kuwasilisha hali za kati za zamani kwenye mkataba wa msuluhishi na kuiba fedha zilizowekwa. Baadhi ya chaneli hutumia "minara ya ulinzi"—mashirika yanayowajibika kutazama matukio ya migogoro mnyororoni kwa niaba ya wengine na kuchukua hatua zinazohitajika, kama vile kuarifu pande zinazohusika. Hata hivyo, hii inaweza kuongeza gharama za kutumia chaneli ya hali. ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#data-unavailability) Kutopatikana kwa data Kama ilivyoelezwa hapo awali, kupinga mgogoro batili kunahitaji kuwasilisha hali ya hivi punde, halali ya chaneli ya hali. Hii ni sheria nyingine inayotegemea dhana—kwamba watumiaji wana ufikiaji wa hali ya hivi punde ya chaneli. Ingawa kutarajia watumiaji wa chaneli kuhifadhi nakala za hali ya programu nje ya mnyororo ni jambo la busara, data hii inaweza kupotea kutokana na hitilafu au hitilafu ya kimitambo. Ikiwa mtumiaji hana nakala rudufu ya data, anaweza tu kutumaini kwamba upande mwingine haukamilishi ombi batili la kujitoa kwa kutumia mabadiliko ya hali ya zamani waliyo nayo. Watumiaji wa Ethereum hawapaswi kushughulika na tatizo hili kwani mtandao unatekeleza sheria juu ya upatikanaji wa data. Data ya muamala inahifadhiwa na kuenezwa na nodi zote na inapatikana kwa watumiaji kupakua ikiwa na wakati inahitajika. ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#liquidity-issues) Masuala ya ukwasi Ili kuanzisha chaneli ya mnyororo wa vitalu, washiriki wanahitaji kufunga fedha katika mkataba mahiri mnyororoni kwa mzunguko wa maisha wa chaneli. Hii inapunguza ukwasi wa watumiaji wa chaneli na pia inazuia chaneli kwa wale wanaoweza kumudu kuweka fedha zimefungwa kwenye Mtandao Mkuu. Hata hivyo, chaneli za leja—zinazoendeshwa na mtoa huduma wa nje ya mnyororo (OSP)—zinaweza kupunguza masuala ya ukwasi kwa watumiaji. Wenza wawili waliounganishwa kwenye chaneli ya leja wanaweza kuunda chaneli pepe, ambayo wanaweza kufungua na kukamilisha kabisa nje ya mnyororo, wakati wowote wanaotaka. Watoa huduma wa nje ya mnyororo wanaweza pia kufungua chaneli na wenza wengi, na kuzifanya kuwa muhimu kwa kupitisha malipo. Bila shaka, watumiaji lazima walipe ada kwa OSP kwa huduma zao, jambo ambalo linaweza kuwa lisilofaa kwa baadhi. ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#griefing-attacks) Mashambulizi ya kusumbua Mashambulizi ya kusumbua ni kipengele cha kawaida cha mifumo inayotegemea ushahidi wa udanganyifu. Shambulio la kusumbua halimnufaishi mshambuliaji moja kwa moja lakini husababisha usumbufu (yaani, madhara) kwa mwathiriwa, hivyo jina lake. Uthibitishaji wa udanganyifu unakabiliwa na mashambulizi ya kusumbua kwa sababu upande mwaminifu lazima ujibu kila mgogoro, hata ule batili, au kuhatarisha kupoteza fedha zao. Mshiriki mwovu anaweza kuamua kuchapisha mara kwa mara mabadiliko ya hali yaliyopitwa na wakati mnyororoni, na kulazimisha upande mwaminifu kujibu kwa hali halali. Gharama ya miamala hiyo mnyororoni inaweza kuongezeka haraka, na kusababisha pande waaminifu kupoteza katika mchakato huo. ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#predefined-participant-sets) Seti za washiriki zilizotambuliwa awali Kwa muundo, idadi ya washiriki wanaounda chaneli ya hali inabaki thabiti katika maisha yake yote. Hii ni kwa sababu kusasisha seti ya washiriki kungetatiza utendaji wa chaneli, hasa wakati wa kufadhili chaneli, au kusuluhisha migogoro. Kuongeza au kuondoa washiriki pia kungehitaji shughuli za ziada mnyororoni, ambayo huongeza gharama za ziada kwa watumiaji. Ingawa hii inafanya chaneli za hali kuwa rahisi kuelewa, inapunguza manufaa ya miundo ya chaneli kwa wasanidi programu. Hii inaelezea kwa kiasi fulani kwa nini chaneli za hali zimeachwa kwa ajili ya suluhisho nyingine za kuongeza viwango, kama vile mikusanyiko. ### [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#parallel-transaction-processing) Uchakataji sambamba wa miamala Washiriki katika chaneli ya hali hutuma masasisho ya hali kwa zamu, ndiyo maana hufanya kazi vizuri zaidi kwa "programu za zamu" (k.m., mchezo wa chess wa wachezaji wawili). Hii huondoa hitaji la kushughulikia masasisho ya hali ya wakati mmoja na kupunguza kazi ambayo mkataba mnyororoni lazima ufanye ili kuadhibu wachapishaji wa masasisho yaliyopitwa na wakati. Hata hivyo, athari ya muundo huu ni kwamba miamala inategemeana, na kuongeza ucheleweshaji na kupunguza uzoefu wa jumla wa mtumiaji. Baadhi ya chaneli za hali hutatua tatizo hili kwa kutumia muundo wa "full-duplex" unaotenganisha hali ya nje ya mnyororo katika hali mbili za "simplex" za mwelekeo mmoja, kuruhusu masasisho ya hali ya wakati mmoja. Miundo kama hiyo inaboresha uwezo wa upitishaji nje ya mnyororo na kupunguza ucheleweshaji wa miamala. [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#use-state-channels) Tumia chaneli za hali ------------------------------------------------------------------------------------------------------------ Miradi mingi hutoa utekelezaji wa chaneli za hali ambazo unaweza kuunganisha kwenye programu tumizi zilizogatuliwa (dapp) zako: * [Connext (inafunguka katika kichupo kipya)](https://connext.network/) * [Perun (inafunguka katika kichupo kipya)](https://perun.network/) * [Raiden (inafunguka katika kichupo kipya)](https://raiden.network/) * [Statechannels.org (inafunguka katika kichupo kipya)](https://statechannels.org/) [](https://ethereum.org/sw/developers/docs/scaling/state-channels/#further-reading) Usomaji zaidi ------------------------------------------------------------------------------------------------- **Chaneli za hali** * [Kuelewa Suluhisho za Kuongeza Viwango za Tabaka la 2 la Ethereum: Chaneli za Hali, Plasma, na Truebit (inafunguka katika kichupo kipya)](https://medium.com/l4-media/making-sense-of-ethereums-layer-2-scaling-solutions-state-channels-plasma-and-truebit-22cb40dcc2f4) _– Josh Stark, Feb 12 2018_ * [Chaneli za Hali - maelezo (inafunguka katika kichupo kipya)](https://www.jeffcoleman.ca/state-channels/) _Nov 6, 2015 - Jeff Coleman_ * [Misingi ya Chaneli za Hali (inafunguka katika kichupo kipya)](https://unlock-protocol.github.io/ethhub/ethereum-roadmap/layer-2-scaling/state-channels/) _District0x_ * [Chaneli za Hali za Mnyororo wa Vitalu: Hali ya Sanaa (inafunguka katika kichupo kipya)](https://ieeexplore.ieee.org/document/9627997) _Je, unajua rasilimali ya jamii iliyokusaidia? Hariri ukurasa huu na uiongeze!_ --- # Kiwango cha Tokeni cha ERC-20 | ethereum.org [Ruka hadi maudhui makuu](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/#main-content) Change page Kiwango cha Tokeni cha ERC-20 ============================= Nakili .mdNakili .md [Hariri ukurasa (inafunguka katika kichupo kipya)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/tokens/erc-20/index.md) Kwenye ukurasa huu [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/#introduction) Utangulizi -------------------------------------------------------------------------------------------- **Tokeni ni nini?** Tokeni zinaweza kuwakilisha karibu chochote katika [Ethereum](https://ethereum.org/sw/) : * pointi za sifa katika jukwaa la mtandaoni * ujuzi wa mhusika katika mchezo * mali za kifedha kama hisa katika kampuni * sarafu ya fiat kama USD * aunsi ya dhahabu * na zaidi... Kipengele chenye nguvu kama hiki cha Ethereum lazima kishughulikiwe na kiwango thabiti, sivyo? Hapo ndipo hasa ERC-20 inapotekeleza jukumu lake! Kiwango hiki kinaruhusu wasanidi programu kujenga programu za tokeni zinazoingiliana na bidhaa na huduma zingine. Kiwango cha ERC-20 pia kinatumika kutoa utendaji wa ziada kwa . **ERC-20 ni nini?** ERC-20 inaleta kiwango cha Tokheni Mbadala, kwa maneno mengine, zina sifa inayofanya kila Tokeni iwe sawa kabisa (kwa aina na thamani) na Tokeni nyingine. Kwa mfano, Tokeni ya ERC-20 inafanya kazi kama ETH, ikimaanisha kwamba Tokeni 1 ni na itakuwa sawa na Tokeni nyingine zote. [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/#prerequisites) Mahitaji ya Awali ---------------------------------------------------------------------------------------------------- * [Akaunti](https://ethereum.org/sw/developers/docs/accounts/) * [Mikataba Mahiri](https://ethereum.org/sw/developers/docs/smart-contracts/) * [Viwango vya tokeni](https://ethereum.org/sw/developers/docs/standards/tokens/) [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/#body) Kiini ------------------------------------------------------------------------------- ERC-20 (Ethereum Request for Comments 20), iliyopendekezwa na Fabian Vogelsteller mnamo Novemba 2015, ni Kiwango cha Tokeni kinachotekeleza API kwa ajili ya tokeni ndani ya Mikataba Mahiri. Mifano ya utendaji ambayo ERC-20 inatoa: * kuhamisha tokeni kutoka akaunti moja hadi nyingine * kupata salio la sasa la tokeni la akaunti * kupata jumla ya usambazaji wa tokeni inayopatikana kwenye mtandao * idhinisha ikiwa kiasi cha tokeni kutoka kwenye akaunti kinaweza kutumiwa na akaunti ya mtu wa tatu Ikiwa Mkataba Mahiri unatekeleza mbinu na matukio yafuatayo unaweza kuitwa Mkataba wa Tokeni wa ERC-20 na, ukishasambazwa, utawajibika kufuatilia tokeni zilizoundwa kwenye Ethereum. Kutoka [EIP-20 (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-20) : ### [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/#methods) Mbinu function name() public view returns (string) function symbol() public view returns (string) function decimals() public view returns (uint8) function totalSupply() public view returns (uint256) function balanceOf(address _owner) public view returns (uint256 balance) function transfer(address _to, uint256 _value) public returns (bool success) function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) function approve(address _spender, uint256 _value) public returns (bool success) function allowance(address _owner, address _spender) public view returns (uint256 remaining) NakiliSolidity Onyesha yote (9) ### [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/#events) Matukio event Transfer(address indexed _from, address indexed _to, uint256 _value) event Approval(address indexed _owner, address indexed _spender, uint256 _value) NakiliSolidity ### [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/#web3py-example) Mifano Hebu tuone jinsi Kiwango kilivyo muhimu sana kurahisisha mambo kwetu kukagua Mkataba wowote wa Tokeni wa ERC-20 kwenye Ethereum. Tunahitaji tu Contract Application Binary Interface (ABI) ili kuunda kiolesura cha Tokeni yoyote ya ERC-20. Kama unavyoona hapa chini tutatumia ABI iliyorahisishwa, ili kuifanya iwe mfano rahisi kueleweka. #### [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/#web3py-example-2) Mfano wa Web3.py Kwanza, hakikisha umesakinisha maktaba ya Python ya [Web3.py (inafunguka katika kichupo kipya)](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) : pip install web3 Nakili from web3 import Web3 w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Etha iliyofungwa (WETH) acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2 # Hii ni Application Binary Interface (ABI) ya Mkataba iliyorahisishwa ya Mkataba wa Tokeni ya ERC-20. # Itaweka wazi tu mbinu hizi: balanceOf(anwani), decimals(), symbol() na totalSupply() simplified_abi = [\ {\ 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}],\ 'name': 'balanceOf',\ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],\ 'stateMutability': 'view', 'type': 'function', 'constant': True\ },\ {\ 'inputs': [],\ 'name': 'decimals',\ 'outputs': [{'internalType': 'uint8', 'name': '', 'type': 'uint8'}],\ 'stateMutability': 'view', 'type': 'function', 'constant': True\ },\ {\ 'inputs': [],\ 'name': 'symbol',\ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],\ 'stateMutability': 'view', 'type': 'function', 'constant': True\ },\ {\ 'inputs': [],\ 'name': 'totalSupply',\ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],\ 'stateMutability': 'view', 'type': 'function', 'constant': True\ }\ ] dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi) symbol = dai_contract.functions.symbol().call() decimals = dai_contract.functions.decimals().call() totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals # DAI print("===== %s =====" % symbol) print("Total Supply:", totalSupply) print("Addr Balance:", addr_balance) weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi) symbol = weth_contract.functions.symbol().call() decimals = weth_contract.functions.decimals().call() totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals # WETH print("===== %s =====" % symbol) print("Total Supply:", totalSupply) print("Addr Balance:", addr_balance) NakiliPython Onyesha yote (60) [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/#erc20-issues) Masuala yanayojulikana -------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/#reception-issue) Suala la upokeaji wa tokeni za ERC-20 **Kufikia tarehe 06/20/2024 angalau tokeni za ERC-20 zenye thamani ya $83,656,418 zilipotea kutokana na suala hili. Kumbuka kwamba utekelezaji halisi wa ERC-20 unakabiliwa na tatizo hili isipokuwa utekeleze seti ya vizuizi vya ziada juu ya kiwango kama ilivyoorodheshwa hapa chini.** Wakati tokeni za ERC-20 zinatumwa kwenye mkataba mahiri ambao haujaundwa kushughulikia tokeni za ERC-20, tokeni hizo zinaweza kupotea kabisa. Hili hutokea kwa sababu mkataba unaopokea hauna utendaji wa kutambua au kujibu tokeni zinazoingia, na hakuna utaratibu katika kiwango cha ERC-20 wa kuarifu mkataba unaopokea kuhusu tokeni zinazoingia. Njia kuu ambazo suala hili hujitokeza ni kupitia: 1. Utaratibu wa hamisho la tokeni * Tokeni za ERC-20 zinahamishwa kwa kutumia fanksheni za transfer au transferFrom * Wakati mtumiaji anatuma tokeni kwenye anwani ya mkataba akitumia fanksheni hizi, tokeni zinahamishwa bila kujali kama mkataba unaopokea umeundwa kuzishughulikia 2. Ukosefu wa arifa * Mkataba unaopokea haupokei arifa au wito wa kurudi (callback) kwamba tokeni zimetumwa kwake * Ikiwa mkataba unaopokea unakosa utaratibu wa kushughulikia tokeni (k.m., fanksheni mbadala au fanksheni maalum ya kusimamia upokeaji wa tokeni), tokeni zinakwama kabisa katika anwani ya mkataba 3. Hakuna ushughulikiaji uliojengewa ndani * Kiwango cha ERC-20 hakijumuishi fanksheni ya lazima kwa mikataba inayopokea kutekeleza, na kusababisha hali ambapo mikataba mingi inashindwa kusimamia vizuri tokeni zinazoingia **Masuluhisho Yanayowezekana** Ingawa haiwezekani kuzuia suala hili kabisa na ERC-20 kuna mbinu ambazo zingeruhusu kupunguza kwa kiasi kikubwa uwezekano wa upotezaji wa tokeni kwa mtumiaji wa mwisho: * Tatizo la kawaida zaidi ni wakati mtumiaji anatuma tokeni kwenye anwani ya mkataba wa tokeni yenyewe (k.m., USDT iliyowekwa kwenye anwani ya mkataba wa tokeni wa USDT). Inapendekezwa kuzuia fanksheni ya `transfer(..)` ili kutengua majaribio kama haya ya hamisho. Fikiria kuongeza ukaguzi wa `require(_to != address(this));` ndani ya utekelezaji wa fanksheni ya `transfer(..)`. * Fanksheni ya `transfer(..)` kwa ujumla haijaundwa kwa ajili ya kuweka tokeni kwenye mikataba. Badala yake, muundo wa `approve(..) & transferFrom(..)` unatumika kuweka tokeni za ERC-20 kwenye mikataba. Inawezekana kuzuia fanksheni ya hamisho ili kutoruhusu kuweka tokeni kwenye mikataba yoyote kwayo, hata hivyo inaweza kuvunja uoanifu na mikataba inayochukulia kuwa tokeni zinaweza kuwekwa kwenye mikataba kwa kutumia fanksheni ya `transfer(..)` (k.m., mabwawa ya ukwasi ya Uniswap). * Kila wakati chukulia kwamba tokeni za ERC-20 zinaweza kuishia kwenye mkataba wako hata kama mkataba wako haupaswi kupokea yoyote. Hakuna njia ya kuzuia au kukataa amana za bahati mbaya upande wa mpokeaji. Inapendekezwa kutekeleza fanksheni ambayo ingeruhusu kutoa tokeni za ERC-20 zilizowekwa kwa bahati mbaya. * Fikiria kutumia viwango mbadala vya tokeni. Baadhi ya viwango mbadala vimetokana na suala hili kama vile [ERC-223](https://ethereum.org/sw/developers/docs/standards/tokens/erc-223/) au [ERC-1363](https://ethereum.org/sw/developers/docs/standards/tokens/erc-1363/) . [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/#further-reading) Usomaji zaidi -------------------------------------------------------------------------------------------------- * [EIP-20: Kiwango cha Tokeni cha ERC-20 (inafunguka katika kichupo kipya)](https://eips.ethereum.org/EIPS/eip-20) * [OpenZeppelin - Tokeni (inafunguka katika kichupo kipya)](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20) * [OpenZeppelin - Utekelezaji wa ERC-20 (inafunguka katika kichupo kipya)](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) * [Alchemy - Mwongozo wa Tokeni za ERC20 za Solidity (inafunguka katika kichupo kipya)](https://www.alchemy.com/overviews/erc20-solidity) Viwango vingine vya tokheni mbadala ----------------------------------- * [ERC-223](https://ethereum.org/sw/developers/docs/standards/tokens/erc-223/) * [ERC-1363](https://ethereum.org/sw/developers/docs/standards/tokens/erc-1363/) * [ERC-777](https://ethereum.org/sw/developers/docs/standards/tokens/erc-777/) * [ERC-4626 - Hifadhi zilizowekwa tokeni](https://ethereum.org/sw/developers/docs/standards/tokens/erc-4626/) * [ERC-7540 - Hifadhi asinkronasi zilizowekwa tokeni](https://ethereum.org/sw/developers/docs/standards/tokens/erc-7540/) [](https://ethereum.org/sw/developers/docs/standards/tokens/erc-20/#tutorials) Mafunzo: Jenga na ERC-20 kwenye Ethereum ----------------------------------------------------------------------------------------------------------------------- * [Mwongozo wa Mkataba wa ERC-20](https://ethereum.org/sw/developers/tutorials/erc20-annotated-code/) _– Mwongozo uliofafanuliwa mstari kwa mstari wa utekelezaji wa mkataba wa ERC-20 wa OpenZeppelin._ * [ERC-20 yenye Njia za Usalama](https://ethereum.org/sw/developers/tutorials/erc20-with-safety-rails/) _– Jinsi ya kuongeza ulinzi kwenye tokeni za ERC-20 ili kusaidia watumiaji kuepuka makosa ya kawaida._ * [Kutuma Tokeni Kwa Kutumia Ethers.js](https://ethereum.org/sw/developers/tutorials/send-token-ethersjs/) _– Mwongozo rafiki kwa wanaoanza wa kuhamisha tokeni za ERC-20 kwa kutumia Ethers.js._ * [Baadhi ya mbinu zinazotumiwa na tokeni za utapeli na jinsi ya kuzigundua](https://ethereum.org/sw/developers/tutorials/scam-token-tricks/) _– Uchunguzi wa kina kuhusu mifumo ya tokeni za utapeli za ERC-20 na jinsi ya kuzitambua._ --- # スマート・コントラクトのアップグレード | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/smart-contracts/upgrading/#main-content) Change page スマート・コントラクトのアップグレード =================== .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/upgrading/index.md) このページの内容 イーサリアム上のスマート・コントラクトは、Ethereum Virtual Machine (EVM) で実行される自己実行型プログラムです。これらのプログラムは設計上イミュータブルであり、コントラクトがデプロイされた後はビジネスロジックの更新ができません。 不変性はスマート・コントラクトのトラストレス性、分散化、およびセキュリティに不可欠ですが、特定のケースでは欠点となる場合があります。たとえば、イミュータブルなコードは、開発者が脆弱なコントラクトを修正することを不可能にする可能性があります。 しかし、スマート・コントラクトの改善に関する研究が進んだことで、いくつかのアップグレードパターンが導入されました。これらのアップグレードパターンにより、開発者はビジネスロジックを別のコントラクトに配置することで、(不変性を維持しながら) スマート・コントラクトをアップグレードできるようになります。 [](https://ethereum.org/ja/developers/docs/smart-contracts/upgrading/#prerequisites) 前提条件 ----------------------------------------------------------------------------------------- [スマート・コントラクト](https://ethereum.org/ja/developers/docs/smart-contracts/) 、[スマート・コントラクトの構造](https://ethereum.org/ja/developers/docs/smart-contracts/anatomy/) 、および[Ethereum Virtual Machine (EVM)](https://ethereum.org/ja/developers/docs/evm/) について十分に理解している必要があります。また、このガイドは読者がスマート・コントラクトのプログラミングを理解していることを前提としています。 [](https://ethereum.org/ja/developers/docs/smart-contracts/upgrading/#what-is-a-smart-contract-upgrade) スマート・コントラクトのアップグレードとは？ ------------------------------------------------------------------------------------------------------------------------------ スマート・コントラクトのアップグレードには、コントラクトの状態を維持しながらスマート・コントラクトのビジネスロジックを変更することが含まれます。特にスマート・コントラクトのコンテキストにおいて、アップグレード可能性と可変性は同じではないことを明確にすることが重要です。 イーサリアムネットワーク上のアドレスにデプロイされたプログラムを変更することは依然としてできません。しかし、ユーザーがスマート・コントラクトとやり取りする際に実行されるコードを変更することは可能です。 これは以下の方法で行うことができます。 1. スマート・コントラクトの複数のバージョンを作成し、古いコントラクトから新しいコントラクトのインスタンスへ状態 (つまりデータ) を移行する。 2. ビジネスロジックと状態を保存するために別々のコントラクトを作成する。 3. プロキシパターンを使用して、イミュータブルなプロキシ・コントラクトから変更可能なロジックコントラクトへ関数呼び出しをデリゲートする。 4. 特定の関数を実行するために、柔軟なサテライトコントラクトとインターフェースを持ち、それに依存するイミュータブルなメインコントラクトを作成する。 5. ダイヤモンドパターンを使用して、プロキシ・コントラクトからロジックコントラクトへ関数呼び出しをデリゲートする。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/upgrading/#contract-migration) アップグレードメカニズム #1: コントラクトの移行 コントラクトの移行は、同じソフトウェアの固有の状態を作成および管理するというバージョン管理の考え方に基づいています。コントラクトの移行には、既存のスマート・コントラクトの新しいインスタンスをデプロイし、ストレージと残高を新しいコントラクトに転送することが含まれます。 新しくデプロイされたコントラクトのストレージは空であるため、古いコントラクトからデータを復元して新しい実装に書き込むことができます。その後、古いコントラクトとやり取りしていたすべてのコントラクトを更新して、新しいアドレスを反映させる必要があります。 コントラクト移行の最後のステップは、ユーザーに新しいコントラクトの使用へ切り替えるよう促すことです。新しいコントラクトのバージョンはユーザーの残高とアドレスを保持するため、不変性が維持されます。トークンベースのコントラクトの場合、取引所に連絡して古いコントラクトを破棄し、新しいコントラクトを使用するように依頼する必要もあります。 コントラクトの移行は、ユーザーのやり取りを中断することなくスマート・コントラクトをアップグレードするための、比較的簡単で安全な手段です。ただし、ユーザーのストレージと残高を新しいコントラクトに手動で移行するには時間がかかり、高いガス代が発生する可能性があります。 [コントラクトの移行に関する詳細 （新しいタブで開きます）](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) ### [](https://ethereum.org/ja/developers/docs/smart-contracts/upgrading/#data-separation) アップグレードメカニズム #2: データの分離 スマート・コントラクトをアップグレードする別の方法は、ビジネスロジックとデータストレージを別々のコントラクトに分離することです。これは、ユーザーがロジックコントラクトとやり取りする一方で、データはストレージコントラクトに保存されることを意味します。 ロジックコントラクトには、ユーザーがアプリケーションとやり取りする際に実行されるコードが含まれています。また、ストレージコントラクトのアドレスを保持し、それとやり取りしてデータを取得および設定します。 一方、ストレージコントラクトは、ユーザーの残高やアドレスなど、スマート・コントラクトに関連する状態を保持します。ストレージコントラクトはロジックコントラクトによって所有され、デプロイ時に後者のアドレスで設定されることに注意してください。これにより、許可されていないコントラクトがストレージコントラクトを呼び出したり、そのデータを更新したりするのを防ぎます。 デフォルトでは、ストレージコントラクトはイミュータブルですが、それが指し示すロジックコントラクトを新しい実装に置き換えることができます。これにより、ストレージと残高をそのまま維持しながら、EVMで実行されるコードを変更できます。 このアップグレード方法を使用するには、ストレージコントラクト内のロジックコントラクトのアドレスを更新する必要があります。また、前述の理由から、新しいロジックコントラクトにストレージコントラクトのアドレスを設定する必要があります。 データの分離パターンは、コントラクトの移行に比べて実装が容易であると言えます。ただし、複数のコントラクトを管理し、悪意のあるアップグレードからスマート・コントラクトを保護するための複雑な承認スキームを実装する必要があります。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/upgrading/#proxy-patterns) アップグレードメカニズム #3: プロキシパターン プロキシパターンでもデータの分離を使用し、ビジネスロジックとデータを別々のコントラクトに保持します。ただし、プロキシパターンでは、コードの実行中にストレージコントラクト (プロキシと呼ばれます) がロジックコントラクトを呼び出します。これは、ロジックコントラクトがストレージコントラクトを呼び出すデータ分離メソッドの逆です。 プロキシパターンでは次のようなことが起こります。 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` の値が変更されないという点を除いて、メッセージ・コールと同じです。_ _これは、コントラクトが実行時に別のアドレスから動的にコードをロードできることを意味します。ストレージ、現在のアドレス、および残高は引き続き呼び出し元のコントラクトを参照し、コードのみが呼び出されたアドレスから取得されます。_ プロキシ・コントラクトには `fallback` 関数が組み込まれているため、ユーザーが関数を呼び出すたびに `delegatecall` を呼び出すことを認識しています。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/) ### [](https://ethereum.org/ja/developers/docs/smart-contracts/upgrading/#strategy-pattern) アップグレードメカニズム #4: ストラテジーパターン この手法は、特定の機能を実装するために他のプログラムとインターフェースを持つソフトウェアプログラムの作成を推奨する[ストラテジーパターン （新しいタブで開きます）](https://en.wikipedia.org/wiki/Strategy_pattern) の影響を受けています。ストラテジーパターンをイーサリアム開発に適用するということは、他のコントラクトの関数を呼び出すスマート・コントラクトを構築することを意味します。 この場合のメインコントラクトにはコアビジネスロジックが含まれていますが、特定の関数を実行するために他のスマート・コントラクト (「サテライトコントラクト」) とインターフェースを持ちます。このメインコントラクトは各サテライトコントラクトのアドレスも保存し、サテライトコントラクトの異なる実装間で切り替えることができます。 新しいサテライトコントラクトを構築し、メインコントラクトに新しいアドレスを設定することができます。これにより、スマート・コントラクトの\_ストラテジー\_を変更する (つまり、新しいロジックを実装する) ことができます。 前述のプロキシパターンと似ていますが、ユーザーがやり取りするメインコントラクトがビジネスロジックを保持している点でストラテジーパターンは異なります。このパターンを使用すると、コアインフラストラクチャに影響を与えることなく、スマート・コントラクトに限定的な変更を導入する機会が得られます。 主な欠点は、このパターンが主にマイナーなアップグレードの展開に役立つということです。また、メインコントラクトが (ハッキングなどにより) 侵害された場合、このアップグレード方法は使用できません。 ### [](https://ethereum.org/ja/developers/docs/smart-contracts/upgrading/#diamond-pattern) アップグレードメカニズム #5: ダイヤモンドパターン ダイヤモンドパターンは、プロキシパターンの改良版と考えることができます。ダイヤモンドプロキシ・コントラクトは複数のロジックコントラクトに関数呼び出しをデリゲートできるため、ダイヤモンドパターンはプロキシパターンとは異なります。 ダイヤモンドパターンのロジックコントラクトは\_ファセット\_と呼ばれます。ダイヤモンドパターンを機能させるには、プロキシ・コントラクト内に[関数セレクタ （新しいタブで開きます）](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) [](https://ethereum.org/ja/developers/docs/smart-contracts/upgrading/#pros-and-cons-of-upgrading-smart-contracts) スマート・コントラクトのアップグレードのメリットとデメリット ------------------------------------------------------------------------------------------------------------------------------------------------ | メリット | デメリット | | --- | --- | | スマート・コントラクトのアップグレードにより、デプロイ後のフェーズで発見された脆弱性の修正が容易になります。 | スマート・コントラクトのアップグレードはコードの不変性という考え方を否定するものであり、分散化とセキュリティに影響を与えます。 | | 開発者はロジックのアップグレードを使用して、分散型アプリケーション (dapp) に新機能を追加できます。 | ユーザーは、開発者がスマート・コントラクトを恣意的に変更しないことを信頼する必要があります。 | | バグを迅速に修正できるため、スマート・コントラクトのアップグレードはエンドユーザーの安全性を向上させることができます。 | スマート・コントラクトにアップグレード機能をプログラミングすると、複雑さの層が追加され、重大な欠陥の可能性が高まります。 | | コントラクトのアップグレードにより、開発者はさまざまな機能を試したり、時間をかけてdappを改善したりする余地が広がります。 | スマート・コントラクトをアップグレードできる機会があることで、開発者が開発フェーズで十分なデューデリジェンスを行わずにプロジェクトを早く立ち上げることを助長する可能性があります。 | | | スマート・コントラクトにおける安全でないアクセス制御や中央集権化は、悪意のあるアクターが不正なアップグレードを実行しやすくする可能性があります。 | [](https://ethereum.org/ja/developers/docs/smart-contracts/upgrading/#considerations-for-upgrading-smart-contracts) スマート・コントラクトのアップグレードに関する考慮事項 ----------------------------------------------------------------------------------------------------------------------------------------------- 1. 特にプロキシパターン、ストラテジーパターン、またはデータの分離を使用する場合は、安全なアクセス制御/承認メカニズムを使用して、不正なスマート・コントラクトのアップグレードを防ぎます。例として、コントラクトの所有者のみが呼び出せるようにアップグレード関数へのアクセスを制限することが挙げられます。 2. スマート・コントラクトのアップグレードは複雑な作業であり、脆弱性の導入を防ぐために高いレベルの注意が必要です。 3. アップグレードを実装するプロセスを分散化することで、トラスト前提を減らします。考えられるストラテジーには、アップグレードを制御するために[マルチシグウォレットコントラクト](https://ethereum.org/ja/developers/docs/smart-contracts/#multisig) を使用することや、アップグレードの承認について[DAOのメンバー](https://ethereum.org/ja/dao/) に投票を要求することなどがあります。 4. コントラクトのアップグレードに伴うコストに注意してください。たとえば、コントラクトの移行中に古いコントラクトから新しいコントラクトに状態 (ユーザーの残高など) をコピーするには、複数のトランザクションが必要になる場合があり、これはより多くのガス代を意味します。 5. ユーザーを保護するために **タイムロック** の実装を検討してください。タイムロックとは、システムへの変更に強制される遅延を指します。タイムロックは、アップグレードを制御するためにマルチシグガバナンスシステムと組み合わせることができます。提案されたアクションが必要な承認しきい値に達した場合でも、事前に定義された遅延期間が経過するまで実行されません。 タイムロックは、提案された変更 (ロジックのアップグレードや新しい手数料スキームなど) に同意しない場合、ユーザーがシステムからエグジットするための時間を与えます。タイムロックがない場合、ユーザーは開発者が事前の通知なしにスマート・コントラクトに恣意的な変更を実装しないことを信頼する必要があります。ここでの欠点は、タイムロックが脆弱性に迅速にパッチを当てる能力を制限することです。 [](https://ethereum.org/ja/developers/docs/smart-contracts/upgrading/#resources) リソース ------------------------------------------------------------------------------------- **オープンツェッペリン Upgrades Plugins - _アップグレード可能なスマート・コントラクトをデプロイし、保護するためのツールスイート。_** * [GitHub （新しいタブで開きます）](https://github.com/OpenZeppelin/openzeppelin-upgrades) * [ドキュメント （新しいタブで開きます）](https://docs.openzeppelin.com/upgrades) [](https://ethereum.org/ja/developers/docs/smart-contracts/upgrading/#tutorials) チュートリアル ---------------------------------------------------------------------------------------- * [スマート・コントラクトのアップグレード | ユーチューブチュートリアル （新しいタブで開きます）](https://www.youtube.com/watch?v=bdXJmWajZRY) (Patrick Collins著) * [イーサリアムスマート・コントラクト移行チュートリアル （新しいタブで開きます）](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) (Austin Griffith著) * [UUPSプロキシパターンを使用したスマート・コントラクトのアップグレード （新しいタブで開きます）](https://blog.logrocket.com/author/praneshas/) (Pranesh A.S著) * [Web3チュートリアル: オープンツェッペリンを使用してアップグレード可能なスマート・コントラクト (プロキシ) を記述する （新しいタブで開きます）](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) (fangjun.eth著) [](https://ethereum.org/ja/developers/docs/smart-contracts/upgrading/#further-reading) 参考文献 ------------------------------------------------------------------------------------------- * [スマート・コントラクトのアップグレードの現状 （新しいタブで開きます）](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) (Santiago Palladino著) * [Solidityスマート・コントラクトをアップグレードする複数の方法 （新しいタブで開きます）](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - Crypto Market Poolブログ * [学習: スマート・コントラクトのアップグレード （新しいタブで開きます）](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - オープンツェッペリンドキュメント * [Solidityコントラクトのアップグレード可能性のためのプロキシパターン: Transparent vs UUPSプロキシ （新しいタブで開きます）](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) (Naveen Sahu著) * [ダイヤモンドアップグレードの仕組み （新しいタブで開きます）](https://dev.to/mudgen/how-diamond-upgrades-work-417j) (Nick Mudge著) --- # 탈중앙화 거래소(DEX) 디자인 모범 사례 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#main-content) Change page 탈중앙화 거래소(DEX) 디자인 모범 사례 ======================= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/design-and-ux/dex-design-best-practice/index.md) 이 페이지의 내용 2018년 유니스왑(Uniswap)이 출시된 이후, 수십 개의 다양한 체인에서 수백 개의 탈중앙화 거래소가 출시되었습니다. 이들 중 다수는 새로운 요소를 도입하거나 자신만의 특징을 추가했지만, 인터페이스는 대체로 동일하게 유지되었습니다. 그 이유 중 하나는 [제이콥의 법칙(Jakob’s Law) (새 탭에서 열림)](https://lawsofux.com/jakobs-law/) 때문입니다. > 사용자는 대부분의 시간을 다른 사이트에서 보냅니다. 즉, 사용자는 여러분의 사이트가 이미 알고 있는 다른 모든 사이트와 동일한 방식으로 작동하기를 선호합니다. 유니스왑, 팬케이크스왑(Pancakeswap), Sushiswap과 같은 초기 혁신가들 덕분에 탈중앙화 금융(DeFi) 사용자들은 DEX가 어떤 모습인지에 대한 공통된 인식을 갖게 되었습니다. 이러한 이유로 이제 '모범 사례'와 같은 것들이 등장하고 있습니다. 여러 사이트에서 디자인 결정이 점점 더 표준화되는 것을 볼 수 있습니다. DEX의 진화는 실시간 테스트의 거대한 사례로 볼 수 있습니다. 효과가 있는 것은 남고, 그렇지 않은 것은 버려졌습니다. 여전히 개성을 살릴 여지는 있지만, DEX가 준수해야 할 특정 표준이 존재합니다. 이 글은 다음 내용을 요약한 것입니다. * 포함해야 할 내용 * 사용성을 최대한 높이는 방법 * 디자인을 커스터마이징하는 주요 방법 모든 예시 와이어프레임은 실제 프로젝트를 기반으로 하지만, 이 글을 위해 특별히 제작되었습니다. 하단에 Figma 키트도 포함되어 있으니, 자유롭게 사용하여 여러분의 와이어프레임 작업 속도를 높여보세요! [](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#basic-anatomy-of-a-dex) DEX의 기본 구조 --------------------------------------------------------------------------------------------------------------------- UI는 일반적으로 세 가지 요소를 포함합니다. 1. 메인 폼 2. 버튼 3. 세부 정보 패널 [![Generic DEX UI, showing the three main elements](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F1.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/1.png) [](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#variations) 변형 ------------------------------------------------------------------------------------------------- 이 글에서 자주 다루게 될 주제이지만, 이러한 요소들을 구성하는 방법은 다양합니다. '세부 정보 패널'은 다음과 같이 배치될 수 있습니다. * 버튼 위 * 버튼 아래 * 아코디언 패널에 숨김 * 그리고/또는 '미리보기' 모달에 표시 참고: '미리보기' 모달은 선택 사항이지만, 메인 UI에 표시되는 세부 정보가 매우 적은 경우에는 필수적입니다. [](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#structure-of-the-main-form) 메인 폼의 구조 ----------------------------------------------------------------------------------------------------------------------- 이곳은 스왑할 토큰을 실제로 선택하는 상자입니다. 이 컴포넌트는 입력 필드와 작은 버튼이 한 줄로 구성되어 있습니다. DEX는 일반적으로 위아래로 한 줄씩 추가 세부 정보를 표시하지만, 이는 다르게 구성될 수도 있습니다. [![Input row, with a details row above and below](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F2.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/2.png) [](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#variations2) 변형 -------------------------------------------------------------------------------------------------- 여기에는 두 가지 UI 변형이 나와 있습니다. 하나는 테두리가 없어 매우 개방적인 디자인을 연출하고, 다른 하나는 입력 행에 테두리가 있어 해당 요소에 시선을 집중시킵니다. [![Two UI variations of the main form](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F3.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/3.png) 이 기본 구조를 통해 디자인의 각 모서리에 하나씩, **네 가지 핵심 정보**를 표시할 수 있습니다. 상단/하단 행이 하나만 있는 경우에는 두 자리만 남게 됩니다. 탈중앙화 금융(DeFi)이 발전하는 동안 이곳에 다양한 정보들이 포함되어 왔습니다. [](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#key-info-to-include) 포함해야 할 핵심 정보 -------------------------------------------------------------------------------------------------------------------- * 지갑 잔액 * 최대(Max) 버튼 * 법정화폐 환산 가치 * '수령' 금액에 대한 가격 영향 초기 탈중앙화 금융(DeFi)에서는 법정화폐 환산 가치가 누락되는 경우가 많았습니다. 어떤 종류의 Web3 프로젝트를 구축하든 법정화폐 환산 가치를 표시하는 것은 필수적입니다. 사용자는 여전히 현지 통화 기준으로 생각하므로, 현실 세계의 멘탈 모델과 일치시키기 위해 이를 포함해야 합니다. 두 번째 필드(스왑하여 받을 토큰을 선택하는 곳)에서는 입력 금액과 예상 출력 금액의 차이를 계산하여 법정화폐 금액 옆에 가격 영향을 포함할 수도 있습니다. 이는 포함해 두면 꽤 유용한 세부 정보입니다. 비율 버튼(예: 25%, 50%, 75%)은 유용한 기능일 수 있지만, 더 많은 공간을 차지하고 클릭 유도 문구(CTA)를 늘리며 인지적 부담을 가중시킵니다. 비율 슬라이더도 마찬가지입니다. 이러한 UI 결정 중 일부는 브랜드와 사용자 유형에 따라 달라집니다. 메인 폼 아래에 추가 세부 정보를 표시할 수 있습니다. 이러한 유형의 정보는 주로 전문가 사용자를 위한 것이므로 다음과 같이 처리하는 것이 합리적입니다. * 최대한 간소화하거나, * 아코디언 패널에 숨김 [![Details shown in the corners of that main form](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F4.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/4.png) [](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#extra-info-to-include) 포함할 추가 정보 ------------------------------------------------------------------------------------------------------------------- * 토큰 가격 * 슬리피지 * 최소 수령액 * 예상 수령액 * 가격 영향 * 예상 가스 비용 * 기타 수수료 * 주문 라우팅 이러한 세부 정보 중 일부는 선택 사항일 수 있습니다. 주문 라우팅은 흥미롭지만, 대부분의 사용자에게는 큰 차이를 만들지 않습니다. 다른 세부 정보 중 일부는 단순히 같은 내용을 다른 방식으로 다시 설명하는 것에 불과합니다. 예를 들어 '최소 수령액'과 '슬리피지'는 동전의 양면과 같습니다. 슬리피지를 1%로 설정한 경우, 예상할 수 있는 최소 수령액은 예상 수령액에서 1%를 뺀 값입니다. 일부 UI는 예상 금액, 최소 금액, 슬리피지를 모두 표시하기도 합니다. 이는 유용하지만 과할 수도 있습니다. 어차피 대부분의 사용자는 기본 슬리피지를 그대로 둘 것입니다. '가격 영향'은 종종 '받는(to)' 필드의 법정화폐 환산 가치 옆에 괄호로 표시됩니다. 이는 추가하기 좋은 훌륭한 UX 디테일이지만, 여기에 표시된다면 아래에 다시 표시할 필요가 있을까요? 그리고 미리보기 화면에서 또다시 표시해야 할까요? 많은 사용자(특히 소액을 스왑하는 사용자)는 이러한 세부 정보에 신경 쓰지 않을 것입니다. 그들은 단순히 숫자를 입력하고 스왑을 누를 것입니다. [![Some details show the same thing](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F5.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/5.png) 정확히 어떤 세부 정보를 표시할지는 대상 사용자와 앱에서 주고자 하는 느낌에 따라 달라집니다. 세부 정보 패널에 슬리피지 허용 오차를 포함하는 경우, 여기에서 직접 편집할 수 있도록 해야 합니다. 이는 앱의 전반적인 사용성에 영향을 주지 않으면서 숙련된 사용자의 작업 흐름을 가속화할 수 있는 깔끔한 UX 기법인 '액셀러레이터(accelerator)'의 좋은 예입니다. [![Slippage can be controlled from the details panel](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F6.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/6.png) 한 화면의 특정 정보 하나뿐만 아니라 전체적인 흐름에 대해 신중하게 생각하는 것이 좋습니다. 메인 폼에 숫자 입력 → 세부 정보 확인 → 미리보기 화면 클릭(미리보기 화면이 있는 경우). 세부 정보 패널이 항상 표시되어야 할까요, 아니면 사용자가 클릭해서 펼쳐야 할까요? 미리보기 화면을 추가하여 마찰을 일으켜야 할까요? 이는 사용자가 속도를 늦추고 거래를 고려하도록 유도하므로 유용할 수 있습니다. 하지만 사용자가 동일한 정보를 모두 다시 보고 싶어 할까요? 이 시점에서 그들에게 가장 유용한 것은 무엇일까요? [](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#design-options) 디자인 옵션 --------------------------------------------------------------------------------------------------------- 앞서 언급했듯이, 이 중 많은 부분은 개인적인 스타일에 달려 있습니다. 사용자는 누구인가요? 브랜드는 무엇인가요? 모든 세부 정보를 보여주는 '전문가용' 인터페이스를 원하시나요, 아니면 미니멀리즘을 추구하시나요? 가능한 모든 정보를 원하는 전문가 사용자를 대상으로 하더라도, 앨런 쿠퍼(Alan Cooper)의 명언을 기억해야 합니다. > 인터페이스가 아무리 아름답고 멋지더라도, 그 양이 적을수록 더 좋습니다. ### [](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#structure) 구조 * 토큰을 왼쪽에 배치할지, 오른쪽에 배치할지 * 2줄 또는 3줄 * 버튼 위 또는 아래에 세부 정보 배치 * 세부 정보를 펼치거나, 최소화하거나, 표시하지 않음 ### [](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#component-style) 컴포넌트 스타일 * 비어 있음(empty) * 윤곽선 있음(outlined) * 채워짐(filled) 순수한 UX 관점에서 볼 때, UI 스타일은 생각보다 중요하지 않습니다. 시각적 트렌드는 주기를 두고 돌고 돌며, 많은 선호도는 주관적입니다. 이에 대한 감을 잡고 다양한 구성을 생각해 보는 가장 쉬운 방법은 몇 가지 예시를 살펴본 다음 직접 실험해 보는 것입니다. 포함된 Figma 키트에는 비어 있는(empty), 윤곽선이 있는(outlined), 채워진(filled) 컴포넌트가 포함되어 있습니다. 아래 예시를 통해 이 모든 것을 조합하는 다양한 방법을 살펴보세요. [![3 rows in a filled style](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F7.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/7.png) [![3 rows in a outlined style](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F8.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/8.png) [![2 rows in an empty style](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F9.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/9.png) [![3 rows in an outlined style, with a details panel](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F10.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/10.png) [![3 rows with the input row in an outlined style](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F11.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/11.png) [![2 rows in a filled style](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F12.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/12.png) [](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#but-which-side-should-the-token-go-on) 그렇다면 토큰은 어느 쪽에 배치해야 할까요? -------------------------------------------------------------------------------------------------------------------------------------------------- 결론부터 말하자면, 사용성에 큰 차이를 만들지는 않을 것입니다. 하지만 어느 한쪽으로 마음이 기울게 할 만한 몇 가지 고려 사항이 있습니다. 시간이 지남에 따라 유행이 변하는 것을 보는 것은 꽤 흥미롭습니다. 유니스왑은 처음에 토큰을 왼쪽에 배치했지만, 이후 오른쪽으로 옮겼습니다. Sushiswap 역시 디자인 업그레이드 과정에서 이러한 변경을 적용했습니다. 전부는 아니지만 대부분의 프로토콜이 그 뒤를 따랐습니다. 금융 관례상 전통적으로 통화 기호를 숫자 앞에 배치하지만(예: $50, €50, £50), 우리는 50달러, 50유로, 50파운드라고 _말합니다_. 일반 사용자, 특히 왼쪽에서 오른쪽으로, 위에서 아래로 읽는 사람에게는 토큰이 오른쪽에 있는 것이 아마 더 자연스럽게 느껴질 것입니다. [![A UI with tokens on the left](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F13.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/13.png) 토큰을 왼쪽에 두고 모든 숫자를 오른쪽에 두면 대칭적으로 보기 좋다는 장점이 있지만, 이 레이아웃에는 또 다른 단점이 있습니다. 근접성의 법칙에 따르면 서로 가까이 있는 항목은 연관된 것으로 인식됩니다. 따라서 관련 항목을 서로 옆에 배치하는 것이 좋습니다. 토큰 잔액은 토큰 자체와 직접적인 관련이 있으며, 새로운 토큰이 선택될 때마다 변경됩니다. 그러므로 토큰 잔액이 토큰 선택 버튼 옆에 있는 것이 조금 더 이치에 맞습니다. 토큰 아래로 옮길 수도 있지만, 그렇게 하면 레이아웃의 대칭이 깨집니다. 결국 두 옵션 모두 장단점이 있지만, 트렌드가 토큰을 오른쪽에 배치하는 방향으로 흘러가고 있다는 점은 흥미롭습니다. [](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#button-behavior) 버튼 동작 --------------------------------------------------------------------------------------------------------- 승인을 위한 별도의 버튼을 만들지 마세요. 또한 승인을 위해 별도로 클릭하게 하지 마세요. 사용자는 스왑을 원하므로 버튼에 '스왑'이라고만 표시하고 첫 번째 단계로 승인을 시작하세요. 모달을 통해 단계별 진행 상황을 보여주거나, '트랜잭션 1/2 - 승인 중'이라는 간단한 알림을 표시할 수 있습니다. [![A UI with separate buttons for approve and swap](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F14.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/14.png) [![A UI with one button that says approve](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F15.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/15.png) ### [](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#button-as-contextual-help) 상황별 도움말로서의 버튼 버튼은 알림 역할까지 이중으로 수행할 수 있습니다! 이는 사실 Web3 외부에서는 꽤 드문 디자인 패턴이지만, Web3 내에서는 표준이 되었습니다. 공간을 절약하고 주의를 집중시킬 수 있다는 점에서 좋은 혁신입니다. 오류로 인해 주요 작업인 스왑(SWAP)을 사용할 수 없는 경우, 버튼을 통해 그 이유를 설명할 수 있습니다. 예: * 네트워크 전환 * 지갑 연결 * 다양한 오류 버튼은 수행해야 할 **작업에 매핑**될 수도 있습니다. 예를 들어, 사용자가 잘못된 네트워크에 있어 스왑할 수 없는 경우 버튼에 '이더리움으로 전환'이라고 표시하고, 사용자가 버튼을 클릭하면 네트워크가 이더리움으로 전환되어야 합니다. 이는 사용자 흐름의 속도를 크게 높여줍니다. [![Key actions being initiated from the main CTA](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F16.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/16.png) [![Error message shown within the main CTA](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fdesign-and-ux%2Fdex-design-best-practice%2F17.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/design-and-ux/dex-design-best-practice/17.png) [](https://ethereum.org/ko/developers/docs/design-and-ux/dex-design-best-practice/#build-your-own-with-this-figma-file) 이 Figma 파일로 직접 구축해 보세요 ---------------------------------------------------------------------------------------------------------------------------------------------- 여러 프로토콜의 노력 덕분에 DEX 디자인은 크게 개선되었습니다. 우리는 사용자가 어떤 정보를 필요로 하는지, 어떻게 보여주어야 하는지, 그리고 흐름을 어떻게 최대한 매끄럽게 만들 수 있는지 알고 있습니다. 이 글이 UX 원칙에 대한 탄탄한 개요를 제공하기를 바랍니다. 실험해 보고 싶다면 Figma 와이어프레임 키트를 자유롭게 사용해 보세요. 최대한 단순하게 유지되었지만, 다양한 방식으로 기본 구조를 구축할 수 있는 충분한 유연성을 갖추고 있습니다. [Figma 와이어프레임 키트 (새 탭에서 열림)](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit) 탈중앙화 금융(DeFi)은 계속해서 진화할 것이며, 항상 개선의 여지가 있습니다. 행운을 빕니다! --- # 네트워크 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/networks/#main-content) Change page 네트워크 ==== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/networks/index.md) 이 페이지의 내용 [이더리움](https://ethereum.org/ko/) 네트워크는 이더리움 프로토콜을 사용하여 통신하는 연결된 컴퓨터들의 그룹입니다. 이더리움 메인넷은 단 하나뿐이지만, 테스트 및 개발 목적으로 동일한 프로토콜 규칙을 따르는 독립적인 네트워크를 만들 수 있습니다. 서로 상호작용하지 않으면서 프로토콜을 따르는 독립적인 "네트워크"가 많이 있습니다. 스마트 컨트랙트와 Web3 앱을 테스트하기 위해 자신의 컴퓨터에서 로컬로 네트워크를 시작할 수도 있습니다. 이더리움 계정은 여러 다른 네트워크에서 작동하지만, 계정 잔액과 트랜잭션 내역은 기본 이더리움 네트워크에서 이월되지 않습니다. 테스트 목적으로는 어떤 네트워크를 사용할 수 있는지, 그리고 테스트해 볼 수 있는 테스트넷 ETH를 어떻게 얻는지 아는 것이 유용합니다. 일반적으로 보안상의 이유로 메인넷 계정을 테스트넷에서 재사용하거나 그 반대로 사용하는 것은 권장하지 않습니다. [](https://ethereum.org/ko/developers/docs/networks/#prerequisites) 전제 조건 ------------------------------------------------------------------------- 테스트 네트워크는 저렴하고 안전하게 이더리움을 다뤄볼 수 있는 환경을 제공하므로, 다양한 네트워크에 대해 읽기 전에 [이더리움의 기초](https://ethereum.org/ko/developers/docs/intro-to-ethereum/) 를 이해해야 합니다. [](https://ethereum.org/ko/developers/docs/networks/#public-networks) 퍼블릭 네트워크 ------------------------------------------------------------------------------ 퍼블릭 네트워크는 인터넷이 연결된 전 세계 누구나 접근할 수 있습니다. 누구나 퍼블릭 블록체인에서 트랜잭션을 읽거나 생성할 수 있으며, 실행되는 트랜잭션을 검증할 수 있습니다. 피어 간의 합의를 통해 트랜잭션 포함 여부와 네트워크의 상태가 결정됩니다. ### [](https://ethereum.org/ko/developers/docs/networks/#ethereum-mainnet) 이더리움 메인넷 메인넷은 분산 원장에서 실제 가치를 지닌 트랜잭션이 발생하는 주요 퍼블릭 이더리움 프로덕션 블록체인입니다. 사람들과 거래소에서 ETH 가격을 논할 때, 이는 메인넷 ETH를 의미합니다. ### [](https://ethereum.org/ko/developers/docs/networks/#ethereum-testnets) 이더리움 테스트넷 메인넷 외에도 퍼블릭 테스트넷이 있습니다. 이러한 네트워크는 프로토콜 개발자나 스마트 컨트랙트 개발자가 메인넷에 배포하기 전에 프로덕션과 유사한 환경에서 프로토콜 업그레이드와 잠재적인 스마트 컨트랙트를 모두 테스트하는 데 사용됩니다. 이를 프로덕션 서버와 스테이징 서버의 관계와 유사하다고 생각하면 됩니다. 작성한 모든 컨트랙트 코드는 메인넷에 배포하기 전에 테스트넷에서 테스트해야 합니다. 기존 스마트 컨트랙트와 통합되는 탈중앙화 애플리케이션(dapp) 중 대부분의 프로젝트는 테스트넷에 배포된 복사본을 가지고 있습니다. 대부분의 테스트넷은 허가형 권위 증명(PoA) 합의 메커니즘을 사용하여 시작되었습니다. 이는 소수의 노드가 트랜잭션을 검증하고 새로운 블록을 생성하도록 선택되며, 이 과정에서 자신의 신원을 스테이킹한다는 것을 의미합니다. 대안으로, 일부 테스트넷은 이더리움 메인넷처럼 누구나 검증자 실행을 테스트할 수 있는 개방형 지분 증명 (PoS) 합의 메커니즘을 특징으로 합니다. 테스트넷의 ETH는 실제 가치가 없는 것으로 간주되지만, 희소해지거나 구하기 어려워진 특정 유형의 테스트넷 ETH를 위한 시장이 형성되기도 했습니다. 이더리움과 실제로 상호작용하려면 (테스트넷에서도) ETH가 필요하므로, 대부분의 사람들은 퍼싯에서 무료로 테스트넷 ETH를 얻습니다. 대부분의 퍼싯은 ETH를 받을 주소를 입력하여 요청할 수 있는 웹앱입니다. #### [](https://ethereum.org/ko/developers/docs/networks/#which-testnet-should-i-use) 어떤 테스트넷을 사용해야 하나요? 현재 클라이언트 개발자들이 유지 관리하고 있는 두 개의 퍼블릭 테스트넷은 Sepolia와 Hoodi입니다. Sepolia는 컨트랙트 및 애플리케이션 개발자가 애플리케이션을 테스트하기 위한 네트워크입니다. Hoodi 네트워크를 통해 프로토콜 개발자는 네트워크 업그레이드를 테스트할 수 있으며, 스테이커는 검증자 실행을 테스트할 수 있습니다. #### [](https://ethereum.org/ko/developers/docs/networks/#sepolia) Sepolia **Sepolia는 애플리케이션 개발을 위해 권장되는 기본 테스트넷입니다**. Sepolia 네트워크는 클라이언트 및 테스트 팀이 제어하는 허가형 검증자 세트를 사용합니다. ##### 리소스 * [웹사이트 (새 탭에서 열림)](https://sepolia.dev/) * [GitHub (새 탭에서 열림)](https://github.com/eth-clients/sepolia) * [Otterscan (새 탭에서 열림)](https://sepolia.otterscan.io/) * [Etherscan (새 탭에서 열림)](https://sepolia.etherscan.io/) * [Blockscout (새 탭에서 열림)](https://eth-sepolia.blockscout.com/) ##### 퍼싯 * [Alchemy Sepolia 퍼싯 (새 탭에서 열림)](https://www.alchemy.com/faucets/ethereum-sepolia) * [Chain Platform Sepolia 퍼싯 (새 탭에서 열림)](https://faucet.chainplatform.co/faucets/ethereum-sepolia/) * [Chainstack Sepolia 퍼싯 (새 탭에서 열림)](https://faucet.chainstack.com/sepolia-testnet-faucet) * [이더리움 생태계 퍼싯 (새 탭에서 열림)](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) * [ethfaucet.com Sepolia 퍼싯 (새 탭에서 열림)](https://ethfaucet.com/networks/ethereum) * [Google Cloud Web3 Sepolia 퍼싯 (새 탭에서 열림)](https://cloud.google.com/application/web3/faucet/ethereum/sepolia) * [Grabteeth (새 탭에서 열림)](https://grabteeth.xyz/) * [Infura Sepolia 퍼싯 (새 탭에서 열림)](https://www.infura.io/faucet) * [PoW 퍼싯 (새 탭에서 열림)](https://sepolia-faucet.pk910.de/) * [QuickNode Sepolia 퍼싯 (새 탭에서 열림)](https://faucet.quicknode.com/ethereum/sepolia) #### [](https://ethereum.org/ko/developers/docs/networks/#hoodi) Hoodi Hoodi는 검증 및 스테이킹을 테스트하기 위한 테스트넷입니다. Hoodi 네트워크는 테스트넷 검증자를 실행하고자 하는 사용자에게 열려 있습니다. 따라서 메인넷에 배포되기 전에 프로토콜 업그레이드를 테스트하려는 스테이커는 Hoodi를 사용해야 합니다. * 개방형 검증자 세트, 스테이커가 네트워크 업그레이드를 테스트할 수 있음 * 대규모 상태, 복잡한 스마트 컨트랙트 상호작용을 테스트하는 데 유용함 * 동기화에 더 오랜 시간이 걸리며 노드를 실행하는 데 더 많은 스토리지가 필요함 ##### 리소스 * [웹사이트 (새 탭에서 열림)](https://hoodi.ethpandaops.io/) * [GitHub (새 탭에서 열림)](https://github.com/eth-clients/hoodi) * [익스플로러 (새 탭에서 열림)](https://explorer.hoodi.ethpandaops.io/) * [체크포인트 동기화 (새 탭에서 열림)](https://checkpoint-sync.hoodi.ethpandaops.io/) * [Otterscan (새 탭에서 열림)](https://hoodi.otterscan.io/) * [Etherscan (새 탭에서 열림)](https://hoodi.etherscan.io/) ##### 퍼싯 * [Chain Platform Hoodi 퍼싯 (새 탭에서 열림)](https://faucet.chainplatform.co/faucets/ethereum-hoodi/) * [Hoodi 퍼싯 (새 탭에서 열림)](https://hoodi.ethpandaops.io/) * [PoW 퍼싯 (새 탭에서 열림)](https://hoodi-faucet.pk910.de/) #### [](https://ethereum.org/ko/developers/docs/networks/#ephemery) Ephemery Ephemery는 매달 완전히 초기화되는 독특한 종류의 테스트넷입니다. 실행 및 합의 상태가 28일마다 제네시스로 되돌아가므로, 테스트넷에서 일어나는 모든 일은 일시적입니다. 따라서 단기 테스트, 빠른 노드 부트스트랩, 영구성이 필요 없는 'hello world' 종류의 애플리케이션에 이상적입니다. * 항상 새로운 상태, 검증자 및 앱의 단기 테스트 * 기본 컨트랙트 세트만 포함 * 개방형 검증자 세트 및 대량의 자금에 쉽게 접근 가능 * 최소한의 노드 요구 사항 및 가장 빠른 동기화, 평균 5GB 미만 ##### 리소스 * [웹사이트 (새 탭에서 열림)](https://ephemery.dev/) * [GitHub (새 탭에서 열림)](https://github.com/ephemery-testnet/ephemery-resources) * [커뮤니티 채팅 (새 탭에서 열림)](https://matrix.to/#/#staker-testnet:matrix.org) * [Blockscout (새 탭에서 열림)](https://explorer.ephemery.dev/) * [Otterscan (새 탭에서 열림)](https://otter.bordel.wtf/) * [비콘 익스플로러 (새 탭에서 열림)](https://beaconlight.ephemery.dev/) * [체크포인트 동기화 (새 탭에서 열림)](https://checkpoint-sync.ephemery.ethpandaops.io/) * [런치패드 (새 탭에서 열림)](https://launchpad.ephemery.dev/) #### [](https://ethereum.org/ko/developers/docs/networks/#faucets) 퍼싯 * [Bordel 퍼싯 (새 탭에서 열림)](https://faucet.bordel.wtf/) * [Pk910 PoW 퍼싯 (새 탭에서 열림)](https://ephemery-faucet.pk910.de/) #### [](https://ethereum.org/ko/developers/docs/networks/#holesky) 홀스카이 (사용 중단됨) 홀스카이 테스트넷은 2025년 9월부로 사용이 중단되었습니다. 스테이킹 운영자와 인프라 제공자는 검증자 테스트를 위해 대신 Hoodi를 사용해야 합니다. * [홀스카이 테스트넷 종료 공지 (새 탭에서 열림)](https://blog.ethereum.org/2025/09/01/holesky-shutdown-announcement) - _EF 블로그, 2025년 9월 1일_ * [홀스카이 및 Hoodi 테스트넷 업데이트 (새 탭에서 열림)](https://blog.ethereum.org/2025/03/18/hoodi-holesky) - _EF 블로그, 2025년 3월 18일_ ### [](https://ethereum.org/ko/developers/docs/networks/#layer-2-testnets) 레이어 2 테스트넷 [레이어 2 (l2)](https://ethereum.org/ko/layer-2/) 는 특정 이더리움 확장 솔루션 세트를 설명하는 총칭입니다. 레이어 2는 이더리움을 확장하고 이더리움의 보안 보장을 상속받는 별도의 블록체인입니다. 레이어 2 테스트넷은 일반적으로 퍼블릭 이더리움 테스트넷과 밀접하게 결합되어 있습니다. #### [](https://ethereum.org/ko/developers/docs/networks/#arbitrum-sepolia) 아비트럼 Sepolia [아비트럼 (새 탭에서 열림)](https://arbitrum.io/) 을 위한 테스트넷입니다. ##### 리소스 * [Etherscan (새 탭에서 열림)](https://sepolia.arbiscan.io/) * [Blockscout (새 탭에서 열림)](https://sepolia-explorer.arbitrum.io/) ##### 퍼싯 * [Alchemy 아비트럼 Sepolia 퍼싯 (새 탭에서 열림)](https://www.alchemy.com/faucets/arbitrum-sepolia) * [체인링크 아비트럼 Sepolia 퍼싯 (새 탭에서 열림)](https://faucets.chain.link/arbitrum-sepolia) * [ethfaucet.com 아비트럼 Sepolia 퍼싯 (새 탭에서 열림)](https://ethfaucet.com/networks/arbitrum) * [QuickNode 아비트럼 Sepolia 퍼싯 (새 탭에서 열림)](https://faucet.quicknode.com/arbitrum/sepolia) #### [](https://ethereum.org/ko/developers/docs/networks/#optimistic-sepolia) 옵티미스틱 Sepolia [옵티미즘 (새 탭에서 열림)](https://www.optimism.io/) 을 위한 테스트넷입니다. ##### 리소스 * [Etherscan (새 탭에서 열림)](https://sepolia-optimistic.etherscan.io/) * [Blockscout (새 탭에서 열림)](https://optimism-sepolia.blockscout.com/) ##### 퍼싯 * [Alchemy 퍼싯 (새 탭에서 열림)](https://www.alchemy.com/faucets/optimism-sepolia) * [체인링크 퍼싯 (새 탭에서 열림)](https://faucets.chain.link/optimism-sepolia) * [ethfaucet.com 옵티미즘 Sepolia 퍼싯 (새 탭에서 열림)](https://ethfaucet.com/networks/optimism) * [테스트넷 퍼싯 (새 탭에서 열림)](https://docs.optimism.io/builders/tools/build/faucets) #### [](https://ethereum.org/ko/developers/docs/networks/#starknet-sepolia) 스타크넷 Sepolia [스타크넷 (새 탭에서 열림)](https://www.starknet.io/) 을 위한 테스트넷입니다. ##### 리소스 * [Voyager Sepolia Scan (새 탭에서 열림)](https://sepolia.voyager.online/) ##### 퍼싯 * [Alchemy 퍼싯 (새 탭에서 열림)](https://www.alchemy.com/faucets/starknet-sepolia) * [Blast 스타크넷 Sepolia 퍼싯 (새 탭에서 열림)](https://blastapi.io/faucets/starknet-sepolia-eth) * [스타크넷 퍼싯 (새 탭에서 열림)](https://starknet-faucet.vercel.app/) [](https://ethereum.org/ko/developers/docs/networks/#private-networks) 프라이빗 네트워크 -------------------------------------------------------------------------------- 이더리움 네트워크의 노드가 퍼블릭 네트워크(예: 메인넷 또는 테스트넷)에 연결되어 있지 않다면 이는 프라이빗 네트워크입니다. 이 문맥에서 프라이빗은 보호되거나 안전하다는 의미보다는 예약되거나 격리되어 있다는 의미에 가깝습니다. ### [](https://ethereum.org/ko/developers/docs/networks/#development-networks) 개발 네트워크 이더리움 애플리케이션을 개발할 때, 배포하기 전에 프라이빗 네트워크에서 실행하여 어떻게 작동하는지 확인하는 것이 좋습니다. 웹 개발을 위해 컴퓨터에 로컬 서버를 만드는 것과 유사하게, 로컬 블록체인 인스턴스를 생성하여 탈중앙화 애플리케이션(dapp)을 테스트할 수 있습니다. 이를 통해 퍼블릭 테스트넷보다 훨씬 빠른 반복 작업이 가능합니다. 이를 지원하는 전용 프로젝트와 도구들이 있습니다. [개발 네트워크](https://ethereum.org/ko/developers/docs/development-networks/) 에 대해 자세히 알아보세요. ### [](https://ethereum.org/ko/developers/docs/networks/#consortium-networks) 컨소시엄 네트워크 합의 프로세스는 신뢰할 수 있는 사전 정의된 노드 세트에 의해 제어됩니다. 예를 들어, 알려진 학술 기관들이 각각 단일 노드를 관리하는 프라이빗 네트워크가 있으며, 블록은 네트워크 내 서명자의 임계값에 의해 검증됩니다. 퍼블릭 이더리움 네트워크가 퍼블릭 인터넷과 같다면, 컨소시엄 네트워크는 프라이빗 인트라넷과 같습니다. [](https://ethereum.org/ko/developers/docs/networks/#why-naming) 이더리움 테스트넷의 이름은 왜 지하철역 이름에서 따왔나요? ------------------------------------------------------------------------------------------------- 많은 이더리움 테스트넷은 실제 지하철역이나 기차역의 이름을 따서 명명되었습니다. 이러한 명명 전통은 일찍부터 시작되었으며 기여자들이 거주하거나 일했던 글로벌 도시들을 반영합니다. 이는 상징적이고 기억하기 쉬우며 실용적입니다. 테스트넷이 이더리움 메인넷과 격리되어 있는 것처럼, 지하철 노선도 지상 교통과 분리되어 운행됩니다. ### [](https://ethereum.org/ko/developers/docs/networks/#common-and-legacy-testnets) 일반적으로 사용되는 테스트넷 및 레거시 테스트넷 * **Sepolia** - 그리스 아테네의 지하철과 연결된 지역입니다. 현재 스마트 컨트랙트 및 탈중앙화 애플리케이션(dapp) 테스트에 사용됩니다. * **Hoodi** - 인도 벵갈루루의 Hoodi 지하철역 이름을 따서 명명되었습니다. 검증자 및 프로토콜 업그레이드 테스트에 사용됩니다. * **괴를리** _(사용 중단됨)_ - 독일 베를린의 Görlitzer Bahnhof 이름을 따서 명명되었습니다. * **Rinkeby** _(사용 중단됨)_ - 지하철역이 있는 스톡홀름 교외 지역의 이름을 따서 명명되었습니다. * **롭스텐** _(사용 중단됨)_ - 스톡홀름의 한 지역이자 과거 페리/지하철 터미널을 가리킵니다. * **Kovan** _(사용 중단됨)_ - 싱가포르 MRT 역 이름을 따서 명명되었습니다. * **Morden** _(사용 중단됨)_ - 런던 지하철역 이름을 따서 명명되었습니다. 이더리움의 첫 번째 퍼블릭 테스트넷입니다. ### [](https://ethereum.org/ko/developers/docs/networks/#other-testnets) 기타 특수 테스트넷 일부 테스트넷은 단기 또는 특정 업그레이드 테스트를 위해 생성되었으며 반드시 지하철을 테마로 하지는 않습니다. * **홀스카이** _(사용 중단됨)_ - 프라하의 Holešovice 역 이름을 따서 명명되었습니다. 검증자 테스트에 사용되었으며 2025년에 사용이 중단되었습니다. * **Kiln**, **Zhejiang**, **Shandong**, **Prater**, **Pyrmont**, **Olympic** _(모두 사용 중단됨)_ 및 **Ephemery** - 머지, 상하이와 같은 업그레이드 시뮬레이션이나 검증자 실험을 위해 특수 목적으로 구축되었습니다. 일부 이름은 지하철 기반이 아니라 지역적이거나 테마 기반입니다. 지하철역 이름을 사용하면 개발자가 숫자 체인 ID에 의존할 필요 없이 테스트넷을 빠르게 식별하고 기억하는 데 도움이 됩니다. 이는 또한 실용적이고 글로벌하며 인간 중심적인 이더리움의 문화를 반영합니다. [](https://ethereum.org/ko/developers/docs/networks/#related-tools) 관련 도구 ------------------------------------------------------------------------- * [Chainlist (새 탭에서 열림)](https://chainlist.org/) _지갑과 제공자를 적절한 체인 ID 및 네트워크 ID에 연결하기 위한 EVM 네트워크 목록_ * [EVM 기반 체인 (새 탭에서 열림)](https://github.com/ethereum-lists/chains) _Chainlist를 구동하는 체인 메타데이터의 GitHub 리포지토리_ [](https://ethereum.org/ko/developers/docs/networks/#further-reading) 더 읽을거리 ---------------------------------------------------------------------------- * [제안: 예측 가능한 이더리움 테스트넷 수명 주기 (새 탭에서 열림)](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) * [이더리움 테스트넷의 진화 (새 탭에서 열림)](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/) --- # इथेरियम आर्काइव नोड | ethereum.org [मुख्य सामग्री पर जाएं](https://ethereum.org/hi/developers/docs/nodes-and-clients/archive-nodes/#main-content) Change page इथेरियम आर्काइव नोड =================== .md कॉपी करें.md कॉपी करें [पेज संपादित करें (नए टैब में खुलता है)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/nodes-and-clients/archive-nodes/index.md) इस पेज पर एक आर्काइव नोड एक [इथेरियम](https://ethereum.org/hi/) क्लाइंट का एक उदाहरण है जिसे सभी ऐतिहासिक स्थितियों का आर्काइव बनाने के लिए कॉन्फ़िगर किया गया है। यह कुछ उपयोग के मामलों के लिए एक उपयोगी टूल है, लेकिन इसे पूर्ण नोड की तुलना में चलाना अधिक कठिन हो सकता है। [](https://ethereum.org/hi/developers/docs/nodes-and-clients/archive-nodes/#prerequisites) पूर्वापेक्षाएँ --------------------------------------------------------------------------------------------------------- आपको एक [इथेरियम नोड](https://ethereum.org/hi/developers/docs/nodes-and-clients/) की अवधारणा, [इसकी वास्तुकला](https://ethereum.org/hi/developers/docs/nodes-and-clients/node-architecture/) , [सिंकिंग रणनीतियों](https://ethereum.org/hi/developers/docs/nodes-and-clients/#sync-modes) , और उन्हें [चलाने](https://ethereum.org/hi/developers/docs/nodes-and-clients/run-a-node/) तथा [उपयोग करने](https://ethereum.org/hi/developers/docs/apis/json-rpc/) की प्रथाओं को समझना चाहिए। [](https://ethereum.org/hi/developers/docs/nodes-and-clients/archive-nodes/#what-is-an-archive-node) आर्काइव नोड क्या है ------------------------------------------------------------------------------------------------------------------------ आर्काइव नोड के महत्व को समझने के लिए, आइए "स्थिति" की अवधारणा को स्पष्ट करें। इथेरियम को एक _लेन-देन-आधारित स्थिति मशीन_ कहा जा सकता है। इसमें खाते और एप्लिकेशन शामिल होते हैं जो लेन-देन निष्पादित करते हैं जो उनकी स्थिति को बदल रहे हैं। प्रत्येक खाते और अनुबंध के बारे में जानकारी वाला वैश्विक डेटा स्थिति नामक एक ट्राई (trie) डेटाबेस में संग्रहीत किया जाता है। इसे निष्पादन परत (EL) क्लाइंट द्वारा नियंत्रित किया जाता है और इसमें शामिल हैं: * खाते के बैलेंस और नॉनस (nonces) * अनुबंध कोड और स्टोरेज * सर्वसम्मति से संबंधित डेटा, उदा., स्टेकिंग जमा अनुबंध नेटवर्क के साथ इंटरैक्ट करने, नए ब्लॉक को सत्यापित करने और बनाने के लिए, इथेरियम क्लाइंट्स को सबसे हालिया बदलावों (चेन की टिप) और इसलिए वर्तमान स्थिति के साथ अपडेट रहना पड़ता है। पूर्ण नोड के रूप में कॉन्फ़िगर किया गया एक निष्पादन परत क्लाइंट नेटवर्क की नवीनतम स्थिति को सत्यापित करता है और उसका पालन करता है, लेकिन केवल पिछली कुछ स्थितियों को कैश करता है, उदा., पिछले 128 ब्लॉक से जुड़ी स्थिति, ताकि यह चेन रीऑर्ग (reorgs) को संभाल सके और हाल के डेटा तक तेज़ पहुँच प्रदान कर सके। हाल की स्थिति वह है जिसकी सभी क्लाइंट्स को आने वाले लेन-देन को सत्यापित करने और नेटवर्क का उपयोग करने के लिए आवश्यकता होती है। आप स्थिति की कल्पना किसी दिए गए ब्लॉक पर एक क्षणिक नेटवर्क Snapshot के रूप में और आर्काइव की कल्पना एक इतिहास रीप्ले के रूप में कर सकते हैं। ऐतिहासिक स्थितियों को सुरक्षित रूप से प्रून (prune) किया जा सकता है क्योंकि वे नेटवर्क के संचालन के लिए आवश्यक नहीं हैं और क्लाइंट के लिए सभी पुराने डेटा को रखना व्यर्थ रूप से अनावश्यक होगा। कुछ हालिया ब्लॉक (उदा., हेड से 128 ब्लॉक पहले) से पहले मौजूद स्थितियों को प्रभावी ढंग से हटा दिया जाता है। पूर्ण नोड केवल ऐतिहासिक ब्लॉकचेन डेटा (ब्लॉक और लेन-देन) और कभी-कभार ऐतिहासिक Snapshot रखते हैं जिनका उपयोग वे अनुरोध पर पुरानी स्थितियों को फिर से उत्पन्न करने के लिए कर सकते हैं। वे EVM में पिछले लेन-देन को फिर से निष्पादित करके ऐसा करते हैं, जो कम्प्यूटेशनल रूप से मांग वाला हो सकता है जब वांछित स्थिति निकटतम Snapshot से बहुत दूर हो। हालाँकि, इसका मतलब है कि पूर्ण नोड पर ऐतिहासिक स्थिति तक पहुँचने में बहुत अधिक कंप्यूटेशन की खपत होती है। क्लाइंट को सभी पिछले लेन-देन को निष्पादित करने और जेनेसिस से एक ऐतिहासिक स्थिति की गणना करने की आवश्यकता हो सकती है। आर्काइव नोड्स न केवल सबसे हाल की स्थितियों को बल्कि प्रत्येक ब्लॉक के बाद बनाई गई हर ऐतिहासिक स्थिति को संग्रहीत करके इसे हल करते हैं। यह मूल रूप से बड़ी डिस्क स्पेस आवश्यकता के साथ एक ट्रेड-ऑफ़ करता है। यह ध्यान रखना महत्वपूर्ण है कि नेटवर्क सभी ऐतिहासिक डेटा को रखने और प्रदान करने के लिए आर्काइव नोड्स पर निर्भर नहीं करता है। जैसा कि ऊपर उल्लेख किया गया है, सभी ऐतिहासिक अंतरिम स्थितियों को पूर्ण नोड पर प्राप्त किया जा सकता है। लेन-देन किसी भी पूर्ण नोड (वर्तमान में 400G से कम) द्वारा संग्रहीत किए जाते हैं और पूरे आर्काइव को बनाने के लिए उन्हें फिर से चलाया जा सकता है। ### [](https://ethereum.org/hi/developers/docs/nodes-and-clients/archive-nodes/#use-cases) उपयोग के मामले इथेरियम के नियमित उपयोग जैसे लेन-देन भेजना, अनुबंध तैनात करना, सर्वसम्मति सत्यापित करना आदि के लिए ऐतिहासिक स्थितियों तक पहुँच की आवश्यकता नहीं होती है। उपयोगकर्ताओं को नेटवर्क के साथ मानक इंटरैक्शन के लिए कभी भी आर्काइव नोड की आवश्यकता नहीं होती है। स्थिति आर्काइव का मुख्य लाभ ऐतिहासिक स्थितियों के बारे में प्रश्नों तक त्वरित पहुँच है। उदाहरण के लिए, आर्काइव नोड तुरंत इस तरह के परिणाम लौटाएगा: * _ब्लॉक 15537393 पर खाते 0x1337... का ETH बैलेंस क्या था?_ * _ब्लॉक 1920000 पर अनुबंध 0x में टोकन 0x का बैलेंस क्या है?_ जैसा कि ऊपर बताया गया है, एक पूर्ण नोड को EVM निष्पादन द्वारा यह डेटा उत्पन्न करने की आवश्यकता होगी जो CPU का उपयोग करता है और इसमें समय लगता है। आर्काइव नोड्स डिस्क पर उन तक पहुँचते हैं और तुरंत प्रतिक्रिया देते हैं। यह बुनियादी ढाँचे के कुछ हिस्सों के लिए एक उपयोगी विशेषता है, उदाहरण के लिए: * ब्लॉक एक्सप्लोरर जैसे सेवा प्रदाता * शोधकर्ता * सुरक्षा विश्लेषक * विकेंद्रीकृत एप्लिकेशन (dapp) डेवलपर्स * ऑडिटिंग और अनुपालन विभिन्न मुफ्त [सेवाएँ](https://ethereum.org/hi/developers/docs/nodes-and-clients/nodes-as-a-service/) हैं जो ऐतिहासिक डेटा तक पहुँच की भी अनुमति देती हैं। चूँकि आर्काइव नोड चलाना अधिक मांग वाला है, यह पहुँच ज्यादातर सीमित है और केवल कभी-कभार पहुँच के लिए काम करती है। यदि आपके प्रोजेक्ट को ऐतिहासिक डेटा तक निरंतर पहुँच की आवश्यकता है, तो आपको स्वयं एक चलाने पर विचार करना चाहिए। [](https://ethereum.org/hi/developers/docs/nodes-and-clients/archive-nodes/#implementations-and-usage) कार्यान्वयन और उपयोग --------------------------------------------------------------------------------------------------------------------------- इस संदर्भ में आर्काइव नोड का अर्थ है उपयोगकर्ता का सामना करने वाले निष्पादन परत क्लाइंट्स द्वारा परोसा गया डेटा क्योंकि वे स्थिति डेटाबेस को संभालते हैं और जेसन-आरपीसी एंडपॉइंट प्रदान करते हैं। कॉन्फ़िगरेशन विकल्प, सिंकिंग समय और डेटाबेस का आकार क्लाइंट के अनुसार भिन्न हो सकता है। विवरण के लिए, कृपया अपने क्लाइंट द्वारा प्रदान किए गए दस्तावेज़ देखें। अपना खुद का आर्काइव नोड शुरू करने से पहले, क्लाइंट्स के बीच के अंतर और विशेष रूप से विभिन्न [हार्डवेयर आवश्यकताओं](https://ethereum.org/hi/developers/docs/nodes-and-clients/run-a-node/#requirements) के बारे में जानें। अधिकांश क्लाइंट इस सुविधा के लिए अनुकूलित नहीं हैं और उनके आर्काइव के लिए 12TB से अधिक स्थान की आवश्यकता होती है। इसके विपरीत, एरिगोन जैसे कार्यान्वयन उसी डेटा को 3TB से कम में संग्रहीत कर सकते हैं जो उन्हें आर्काइव नोड चलाने का सबसे प्रभावी तरीका बनाता है। [](https://ethereum.org/hi/developers/docs/nodes-and-clients/archive-nodes/#recommended-practices) अनुशंसित प्रथाएँ ------------------------------------------------------------------------------------------------------------------- [नोड चलाने के लिए सामान्य अनुशंसाओं](https://ethereum.org/hi/developers/docs/nodes-and-clients/run-a-node/) के अलावा, एक आर्काइव नोड हार्डवेयर और रखरखाव पर अधिक मांग वाला हो सकता है। एरिगोन की [प्रमुख विशेषताओं (नए टैब में खुलता है)](https://github.com/ledgerwatch/erigon#key-features) को ध्यान में रखते हुए, सबसे व्यावहारिक दृष्टिकोण [एरिगोन](https://ethereum.org/hi/developers/docs/nodes-and-clients/#erigon) क्लाइंट कार्यान्वयन का उपयोग करना है। ### [](https://ethereum.org/hi/developers/docs/nodes-and-clients/archive-nodes/#hardware) हार्डवेयर हमेशा क्लाइंट के दस्तावेज़ में किसी दिए गए मोड के लिए हार्डवेयर आवश्यकताओं को सत्यापित करना सुनिश्चित करें। आर्काइव नोड्स के लिए सबसे बड़ी आवश्यकता डिस्क स्पेस है। क्लाइंट के आधार पर, यह 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 के साथ। [ZFS (नए टैब में खुलता है)](https://en.wikipedia.org/wiki/ZFS) का उपयोग करने पर विचार करना भी उचित हो सकता है क्योंकि यह "कॉपी-ऑन-राइट" (Copy-on-write) का समर्थन करता है जो यह सुनिश्चित करता है कि डेटा बिना किसी निम्न स्तर की त्रुटियों के डिस्क पर सही ढंग से लिखा गया है। आकस्मिक डेटाबेस भ्रष्टाचार को रोकने में अधिक स्थिरता और सुरक्षा के लिए, विशेष रूप से एक पेशेवर सेटअप में, यदि आपका सिस्टम इसका समर्थन करता है तो [ECC मेमोरी (नए टैब में खुलता है)](https://en.wikipedia.org/wiki/ECC_memory) का उपयोग करने पर विचार करें। RAM का आकार आम तौर पर पूर्ण नोड के समान होने की सलाह दी जाती है लेकिन अधिक RAM सिंकिंग को गति देने में मदद कर सकती है। प्रारंभिक सिंकिंग के दौरान, आर्काइव मोड में क्लाइंट जेनेसिस से हर लेन-देन को निष्पादित करेंगे। निष्पादन की गति ज्यादातर CPU द्वारा सीमित होती है, इसलिए एक तेज़ CPU प्रारंभिक सिंकिंग समय में मदद कर सकता है। एक औसत उपभोक्ता कंप्यूटर पर, प्रारंभिक सिंकिंग में एक महीने तक का समय लग सकता है। [](https://ethereum.org/hi/developers/docs/nodes-and-clients/archive-nodes/#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) - _Thomas Jay Rush, अगस्त 2021_ * [एरिगोन, एरिगोन के RPC और TrueBlocks (स्क्रैप और API) को सेवाओं के रूप में कैसे सेट करें (नए टैब में खुलता है)](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– Magnus Hansson, अपडेटेड सितंबर 2022_ [](https://ethereum.org/hi/developers/docs/nodes-and-clients/archive-nodes/#related-topics) संबंधित विषय -------------------------------------------------------------------------------------------------------- * [नोड्स और क्लाइंट्स](https://ethereum.org/hi/developers/docs/nodes-and-clients/) * [नोड चलाना](https://ethereum.org/hi/developers/docs/nodes-and-clients/run-a-node/) --- # Dart डेव्हलपर्ससाठी इथेरियम | ethereum.org [मुख्य सामग्रीवर जा](https://ethereum.org/mr/developers/docs/programming-languages/dart/#main-content) Change page Dart डेव्हलपर्ससाठी इथेरियम =========================== .md कॉपी करा.md कॉपी करा [पृष्ठ संपादित करा (नवीन टॅबमध्ये उघडते)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/dart/index.md) या पृष्ठावर [](https://ethereum.org/mr/developers/docs/programming-languages/dart/#getting-started-with-smart-contracts-and-solidity) स्मार्ट कॉन्ट्रॅक्ट्स आणि Solidity भाषेशी सुरुवात करणे -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [](https://ethereum.org/mr/developers/docs/programming-languages/dart/#tutorials) ट्युटोरियल्स ---------------------------------------------------------------------------------------------- * [Flutter आणि ब्लॉकचेन – Hello World Dapp (नवीन टॅबमध्ये उघडते)](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) तुम्हाला सुरुवात करण्यासाठी सर्व पायऱ्यांमधून घेऊन जाते: 1. [Solidity (नवीन टॅबमध्ये उघडते)](https://soliditylang.org/) मध्ये स्मार्ट कॉन्ट्रॅक्ट लिहिणे 2. Dart मध्ये युझर इंटरफेस लिहिणे * [Flutter सह मोबाईल dapp तयार करणे (नवीन टॅबमध्ये उघडते)](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) हे खूपच लहान आहे, जर तुम्हाला आधीच मूलभूत गोष्टी माहित असतील तर हे अधिक चांगले असू शकते * जर तुम्हाला व्हिडिओ पाहून शिकायला आवडत असेल, तर तुम्ही [तुमचे पहिले ब्लॉकचेन Flutter ॲप तयार करा (नवीन टॅबमध्ये उघडते)](https://www.youtube.com/watch?v=3Eeh3pJ6PeA) पाहू शकता, जे सुमारे एक तासाचे आहे * जर तुम्हाला घाई असेल, तर तुम्ही [इथेरियमवर Flutter आणि Dart सह ब्लॉकचेन विकेंद्रित ॲप्लिकेशन (dapp) तयार करणे (नवीन टॅबमध्ये उघडते)](https://www.youtube.com/watch?v=jaMFEOCq_1s) पसंत करू शकता, जे फक्त वीस मिनिटांचे आहे * [WalletConnect च्या Web3Modal सह Flutter ॲप्लिकेशनमध्ये मेटामास्क इंटिग्रेट करणे (नवीन टॅबमध्ये उघडते)](https://www.youtube.com/watch?v=v_M2buHCpc4) - हा छोटा व्हिडिओ तुम्हाला WalletConnect च्या [Web3Modal (नवीन टॅबमध्ये उघडते)](https://pub.dev/packages/web3modal_flutter) लायब्ररीसह तुमच्या Flutter ॲप्लिकेशन्समध्ये मेटामास्क इंटिग्रेट करण्याच्या पायऱ्यांमधून घेऊन जातो * [Solidity आणि Flutter सह मोबाईल ब्लॉकचेन डेव्हलपर बूटकॅम्प कोर्स (नवीन टॅबमध्ये उघडते)](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - फुल स्टॅक मोबाईल ब्लॉकचेन डेव्हलपर कोर्सची प्लेलिस्ट [](https://ethereum.org/mr/developers/docs/programming-languages/dart/#working-with-ethereum-clients) इथेरियम क्लायंट्ससोबत काम करणे ------------------------------------------------------------------------------------------------------------------------------------ तुम्ही इथेरियमचा वापर करून विकेंद्रित ॲप्लिकेशन्स (किंवा "dapps") तयार करू शकता जे क्रिप्टोकरन्सी आणि ब्लॉकचेन तंत्रज्ञानाच्या फायद्यांचा उपयोग करतात. इथेरियमसाठी [जेसॉन-आरपीसी API](https://ethereum.org/mr/developers/docs/apis/json-rpc/) वापरण्यासाठी Dart साठी सध्या किमान दोन मेंटेन केलेल्या लायब्ररी आहेत. 1. [pwa.ir कडून Web3dart (नवीन टॅबमध्ये उघडते)](https://pub.dev/packages/web3dart) 2. [darticulate.com कडून इथेरियम 5.0.0 (नवीन टॅबमध्ये उघडते)](https://pub.dev/packages/ethereum) अशा अतिरिक्त लायब्ररी देखील आहेत ज्या तुम्हाला विशिष्ट इथेरियम ॲड्रेस हाताळण्याची परवानगी देतात, किंवा ज्या तुम्हाला विविध क्रिप्टोकरन्सीच्या किमती मिळवू देतात. [तुम्ही संपूर्ण यादी येथे पाहू शकता (नवीन टॅबमध्ये उघडते)](https://pub.dev/dart/packages?q=ethereum) . --- # 지분 증명 보상 및 페널티 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/#main-content) Change page 지분 증명 보상 및 페널티 ============== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md) 이 페이지의 내용 [이더리움](https://ethereum.org/ko/) 은 기본 암호화폐인 이더(ETH)를 사용하여 보호됩니다. 블록을 검증하고 체인의 헤드를 식별하는 데 참여하고자 하는 노드 운영자는 이더리움의 [예치 컨트랙트](https://ethereum.org/ko/staking/deposit-contract/) 에 이더를 예치합니다. 그런 다음 피어 투 피어 네트워크를 통해 수신된 새 블록의 유효성을 확인하고 포크 선택 알고리즘을 적용하여 체인의 헤드를 식별하는 검증자 소프트웨어를 실행하는 대가로 이더를 지급받습니다. 검증자에게는 두 가지 주요 역할이 있습니다. 1) 새 블록을 확인하고 유효한 경우 이에 대해 "증명"하는 것, 2) 전체 검증자 풀에서 무작위로 선택되었을 때 새 블록을 제안하는 것입니다. 검증자가 요청을 받았을 때 이 두 가지 작업 중 하나라도 수행하지 못하면 이더 지급을 놓치게 됩니다. 검증자는 때때로 서명 집계 및 동기화 위원회 참여 임무를 맡기도 합니다. 또한 동일한 슬롯에 대해 여러 블록을 제안하거나 동일한 슬롯에 대해 여러 블록을 증명하는 등 실수로 수행하기 매우 어렵고 악의적인 인텐트를 나타내는 일부 작업도 있습니다. 이는 "슬래싱" 가능한 행동으로, 검증자가 네트워크에서 제거되기 전에 일정량의 이더(최대 1 ETH)가 소각되며, 제거에는 36일이 걸립니다. 슬래싱된 검증자의 이더는 종료 기간 동안 서서히 줄어들지만, 18일째에는 "상관관계 페널티(correlation penalty)"를 받게 되며, 이는 비슷한 시기에 더 많은 검증자가 슬래싱될수록 커집니다. 따라서 합의 메커니즘의 인센티브 구조는 정직함에 보상하고 악의적인 행위자를 처벌합니다. 모든 보상과 페널티는 에포크당 한 번씩 적용됩니다. 자세한 내용은 계속 읽어보세요... [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/#rewards) 보상 및 페널티 ------------------------------------------------------------------------------------------------------------ ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/#rewards-2) 보상 검증자는 대다수의 다른 검증자와 일치하는 투표를 할 때, 블록을 제안할 때, 그리고 동기화 위원회에 참여할 때 보상을 받습니다. 각 에포크의 보상 가치는 `base_reward`에서 계산됩니다. 이는 다른 보상이 계산되는 기본 단위입니다. `base_reward`는 최적의 조건에서 검증자가 에포크당 받는 평균 보상을 나타냅니다. 이는 다음과 같이 검증자의 유효 잔고와 활성 검증자의 총 수에서 계산됩니다. base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) 복사 여기서 `base_reward_factor`는 64, `base_rewards_per_epoch`는 4, `sum(active balance)`는 모든 활성 검증자에 걸쳐 스테이킹된 총 이더입니다. 이는 기본 보상이 검증자의 유효 잔고에 비례하고 네트워크의 검증자 수에 반비례함을 의미합니다. 검증자가 많을수록 전체 발행량은 커지지만(`sqrt(N)`이므로), 검증자당 `base_reward`는 작아집니다(`1/sqrt(N)`이므로). 이러한 요소는 스테이킹 노드의 APR에 영향을 미칩니다. 이에 대한 근거는 [비탈릭의 노트 (새 탭에서 열림)](https://notes.ethereum.org/@vbuterin/serenity_design_rationale?type=view#Base-rewards) 에서 읽어보세요. 그런 다음 총 보상은 각 구성 요소가 총 보상에 얼마나 추가되는지를 결정하는 가중치를 가진 5가지 구성 요소의 합으로 계산됩니다. 구성 요소는 다음과 같습니다. 1. source vote: 검증자가 올바른 소스 체크포인트에 대해 적시에 투표했습니다. 2. target vote: 검증자가 올바른 타겟 체크포인트에 대해 적시에 투표했습니다. 3. head vote: 검증자가 올바른 헤드 블록에 대해 적시에 투표했습니다. 4. sync committee reward: 검증자가 동기화 위원회에 참여했습니다. 5. proposer reward: 검증자가 올바른 슬롯에 블록을 제안했습니다. 복사 각 구성 요소의 가중치는 다음과 같습니다. TIMELY_SOURCE_WEIGHT uint64(14) TIMELY_TARGET_WEIGHT uint64(26) TIMELY_HEAD_WEIGHT uint64(14) SYNC_REWARD_WEIGHT uint64(2) PROPOSER_WEIGHT uint64(8) 복사 이 가중치의 합은 64입니다. 보상은 적용 가능한 가중치의 합을 64로 나눈 값으로 계산됩니다. 적시에 소스, 타겟 및 헤드 투표를 하고, 블록을 제안하고, 동기화 위원회에 참여한 검증자는 `64/64 * base_reward == base_reward`를 받을 수 있습니다. 그러나 검증자는 일반적으로 블록 제안자가 아니므로 최대 보상은 `64-8 /64 * base_reward == 7/8 * base_reward`입니다. 블록 제안자도 아니고 동기화 위원회에도 속하지 않은 검증자는 `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`를 받을 수 있습니다. 빠른 증명을 장려하기 위해 추가 보상이 더해집니다. 이것이 `inclusion_delay_reward`입니다. 이는 `base_reward`에 `1/delay`를 곱한 값과 같으며, 여기서 `delay`는 블록 제안과 증명을 분리하는 슬롯의 수입니다. 예를 들어, 블록 제안 후 1 슬롯 이내에 증명이 제출되면 증명자는 `base_reward * 1/1 == base_reward`를 받습니다. 증명이 다음 슬롯에 도착하면 증명자는 `base_reward * 1/2`를 받는 식입니다. 블록 제안자는 블록에 포함된 **각 유효한 증명**에 대해 `8 / 64 * base_reward`를 받으므로, 실제 보상 가치는 증명하는 검증자의 수에 비례하여 증가합니다. 블록 제안자는 제안된 블록에 다른 검증자의 잘못된 행동에 대한 증거를 포함하여 보상을 늘릴 수도 있습니다. 이러한 보상은 검증자의 정직함을 장려하는 "당근"입니다. 슬래싱을 포함하는 블록 제안자는 `slashed_validators_effective_balance / 512`로 보상을 받습니다. ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/#penalties) 페널티 지금까지는 완벽하게 잘 행동하는 검증자를 고려했지만, 적시에 헤드, 소스 및 타겟 투표를 하지 않거나 느리게 하는 검증자는 어떨까요? 타겟 및 소스 투표를 누락한 것에 대한 페널티는 증명자가 이를 제출했을 때 받았을 보상과 같습니다. 즉, 보상이 잔고에 추가되는 대신 동일한 가치가 잔고에서 차감됩니다. 헤드 투표를 누락한 것에 대한 페널티는 없습니다(즉, 헤드 투표는 보상만 받을 뿐 페널티는 받지 않습니다). `inclusion_delay`와 관련된 페널티도 없습니다. 보상이 검증자의 잔고에 추가되지 않을 뿐입니다. 블록 제안에 실패한 것에 대한 페널티도 없습니다. 보상 및 페널티에 대한 자세한 내용은 [합의 사양 (새 탭에서 열림)](https://github.com/ethereum/consensus-specs/blob/master/specs/altair/beacon-chain.md) 에서 읽어보세요. 보상과 페널티는 벨라트릭스(Bellatrix) 업그레이드에서 조정되었습니다. 대니 라이언(Danny Ryan)과 비탈릭(Vitalik)이 이 [Peep an EIP 비디오 (새 탭에서 열림)](https://www.youtube.com/watch?v=iaAEGs1DMgQ) 에서 이에 대해 논의하는 것을 시청하세요. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/#slashing) 슬래싱 -------------------------------------------------------------------------------------------------------- 슬래싱은 검증자를 네트워크에서 강제로 제거하고 이와 관련된 스테이킹된 이더의 손실을 초래하는 더 심각한 조치입니다. 검증자가 슬래싱될 수 있는 방법에는 세 가지가 있으며, 모두 블록의 부정직한 제안 또는 증명에 해당합니다. * 동일한 슬롯에 대해 두 개의 다른 블록을 제안하고 서명하기 * 다른 블록을 "둘러싸는" 블록을 증명하기(사실상 역사 변경) * 동일한 블록에 대해 두 후보를 증명하여 "이중 투표"하기 이러한 행동이 감지되면 검증자는 슬래싱됩니다. 이는 32 ETH 검증자의 경우 0.0078125가 즉시 소각되며(활성 잔고에 따라 선형적으로 비례), 그 후 36일의 제거 기간이 시작됨을 의미합니다. 이 제거 기간 동안 검증자의 스테이크는 서서히 줄어듭니다. 중간 지점(18일째)에는 슬래싱 이벤트 이전 36일 동안 슬래싱된 모든 검증자의 총 스테이킹된 이더에 비례하는 추가 페널티가 적용됩니다. 이는 더 많은 검증자가 슬래싱될수록 슬래싱의 규모가 커짐을 의미합니다. 최대 슬래싱은 슬래싱된 모든 검증자의 전체 유효 잔고입니다(즉, 슬래싱되는 검증자가 많으면 스테이크 전체를 잃을 수 있습니다). 반면, 단일하고 고립된 슬래싱 이벤트는 검증자 스테이크의 작은 부분만 소각합니다. 슬래싱된 검증자의 수에 비례하는 이 중간 지점 페널티를 "상관관계 페널티(correlation penalty)"라고 합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/#inactivity-leak) 비활동 누수 ------------------------------------------------------------------------------------------------------------------ 합의 레이어가 완결성 없이 4 에포크 이상 진행되면 "비활동 누수"라는 비상 프로토콜이 활성화됩니다. 비활동 누수의 궁극적인 목표는 체인이 완결성을 회복하는 데 필요한 조건을 만드는 것입니다. 위에서 설명했듯이 완결성을 위해서는 총 스테이킹된 이더의 2/3 절대다수가 소스 및 타겟 체크포인트에 동의해야 합니다. 전체 검증자의 1/3 이상을 차지하는 검증자가 오프라인 상태가 되거나 올바른 증명을 제출하지 못하면 2/3 절대다수가 체크포인트를 완결하는 것이 불가능합니다. 비활동 누수는 비활성 검증자에 속한 스테이크가 전체 스테이크의 1/3 미만을 제어할 때까지 서서히 줄어들게 하여, 남은 활성 검증자가 체인을 완결할 수 있도록 합니다. 비활성 검증자 풀이 아무리 크더라도 남은 활성 검증자는 결국 스테이크의 2/3 이상을 제어하게 됩니다. 스테이크 손실은 비활성 검증자가 가능한 한 빨리 다시 활성화하도록 하는 강력한 인센티브입니다! 비활동 누수 시나리오는 메달라(Medalla) 테스트넷에서 활성 검증자의 66% 미만이 블록체인의 현재 헤드에 대해 합의에 도달할 수 있었을 때 발생했습니다. 비활동 누수가 활성화되었고 결국 완결성을 되찾았습니다! 합의 메커니즘의 보상, 페널티 및 슬래싱 설계는 개별 검증자가 올바르게 행동하도록 장려합니다. 그러나 이러한 설계 선택에서 여러 클라이언트에 걸쳐 검증자를 균등하게 분배하도록 강력하게 인센티브를 제공하고 단일 클라이언트의 지배를 강력하게 억제하는 시스템이 나타납니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/#further-reading) 더 읽어보기 ------------------------------------------------------------------------------------------------------------------ * [이더리움 업그레이드: 인센티브 레이어 (새 탭에서 열림)](https://eth2book.info/altair/part2/incentives) * [이더리움의 하이브리드 Casper 프로토콜의 인센티브 (새 탭에서 열림)](https://arxiv.org/pdf/1903.04205.pdf) * [비탈릭의 주석이 달린 사양 (새 탭에서 열림)](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) * [이더2 슬래싱 방지 팁 (새 탭에서 열림)](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) * [EIP-7251에 따른 슬래싱 페널티 분석 (새 탭에서 열림)](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) _출처_ * _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/ (새 탭에서 열림)](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/) _ --- # Ruby 개발자를 위한 이더리움 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/programming-languages/ruby/#main-content) Change page Ruby 개발자를 위한 이더리움 ================= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/ruby/index.md) 이 페이지의 내용 Ruby 기반 프로젝트와 도구를 사용하여 이더리움용으로 개발하는 방법을 배워보세요. 이더리움을 사용하여 암호화폐와 블록체인 기술의 이점을 활용하는 탈중앙화 애플리케이션 (dapp)(또는 "디앱")을 만들어보세요. 이러한 탈중앙화 애플리케이션 (dapp)은 무신뢰 특성을 가질 수 있으며, 이는 이더리움에 배포된 후에는 항상 프로그래밍된 대로 실행됨을 의미합니다. 또한 디지털 자산을 제어하여 새로운 종류의 금융 애플리케이션을 만들 수 있습니다. 이들은 탈중앙화되어 있어 단일 주체나 개인이 통제하지 않으며 검열이 거의 불가능합니다. [](https://ethereum.org/ko/developers/docs/programming-languages/ruby/#getting-started-with-smart-contracts-and-solidity) 스마트 컨트랙트 및 Solidity 언어 시작하기 ----------------------------------------------------------------------------------------------------------------------------------------------------- **Ruby와 이더리움을 통합하기 위한 첫걸음을 내딛어 보세요** 더 기초적인 입문서가 먼저 필요하신가요? [ethereum.org/learn](https://ethereum.org/ko/learn/) 또는 [ethereum.org/developers](https://ethereum.org/ko/developers/) 를 확인해 보세요. * [블록체인 설명 (새 탭에서 열림)](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [스마트 컨트랙트의 이해 (새 탭에서 열림)](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [첫 번째 스마트 컨트랙트 작성하기 (새 탭에서 열림)](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Solidity 컴파일 및 배포 방법 알아보기 (새 탭에서 열림)](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) [](https://ethereum.org/ko/developers/docs/programming-languages/ruby/#beginner-articles) 초급자용 아티클 -------------------------------------------------------------------------------------------------- * [이더리움 계정 완벽하게 이해하기 (새 탭에서 열림)](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) * [메타마스크로 Rails 사용자 인증하기 (새 탭에서 열림)](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj) * [Ruby를 사용하여 이더리움 네트워크에 연결하는 방법 (새 탭에서 열림)](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby) * [Ruby에서 새로운 이더리움 주소를 생성하는 방법 (새 탭에서 열림)](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby) [](https://ethereum.org/ko/developers/docs/programming-languages/ruby/#intermediate-articles) 중급자용 아티클 ------------------------------------------------------------------------------------------------------ * [Ruby로 만드는 블록체인 앱 (새 탭에서 열림)](https://www.nopio.com/blog/blockchain-app-ruby/) * [이더리움에 연결된 Ruby를 사용하여 스마트 컨트랙트 실행하기 (새 탭에서 열림)](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9) [](https://ethereum.org/ko/developers/docs/programming-languages/ruby/#ruby-projects-and-tools) Ruby 프로젝트 및 도구 -------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/ko/developers/docs/programming-languages/ruby/#active) 활성 상태 * [eth.rb (새 탭에서 열림)](https://github.com/q9f/eth.rb) - _이더리움 계정, 메시지 및 트랜잭션을 처리하기 위한 Ruby 라이브러리 및 RPC 클라이언트_ * [keccak.rb (새 탭에서 열림)](https://github.com/q9f/keccak.rb) - _이더리움에서 사용하는 Keccak (SHA3) 해시_ * [siwe-ruby (새 탭에서 열림)](https://github.com/signinwithethereum/siwe-ruby) - _이더리움으로 로그인(Sign-In with Ethereum)의 Ruby 구현체_ * [siwe-rails (새 탭에서 열림)](https://github.com/signinwithethereum/siwe-rails) - _SIWE 로컬 로그인 라우트를 추가하는 Rails gem_ * [siwe-rails-examples (새 탭에서 열림)](https://github.com/signinwithethereum/siwe-rails-examples) - _사용자 정의 컨트롤러와 함께 Ruby on Rails를 사용하는 SIWE 예제_ * [omniauth-siwe (새 탭에서 열림)](https://github.com/signinwithethereum/omniauth-siwe) - _이더리움으로 로그인(SIWE)을 위한 OmniAuth 전략_ * [omniauth-nft (새 탭에서 열림)](https://github.com/valthon/omniauth-nft) - _NFT 소유권을 통한 인증을 위한 OmniAuth 전략_ * [ethereum-on-rails (새 탭에서 열림)](https://github.com/q9f/ethereum-on-rails) - _메타마스크를 Ruby on Rails에 연결할 수 있게 해주는 Ethereum on Rails 템플릿_ ### [](https://ethereum.org/ko/developers/docs/programming-languages/ruby/#archived--no-longer-maintained) 보관됨 / 더 이상 유지보수되지 않음 * [web3-eth (새 탭에서 열림)](https://github.com/spikewilliams/vtada-ethereum) - _Ruby로 이더리움 노드의 RPC 메서드 호출하기_ * [ethereum\_tree (새 탭에서 열림)](https://github.com/longhoangwkm/ethereum_tree) - _BIP32 표준에 따라 계층적 결정론적(HD) 지갑에서 ETH 주소를 생성하는 Ruby 라이브러리_ * [etherlite (새 탭에서 열림)](https://github.com/budacom/etherlite) - _Ruby on Rails를 위한 이더리움 연동_ * [ethereum.rb (새 탭에서 열림)](https://github.com/EthWorks/ethereum.rb) - _트랜잭션 전송, 컨트랙트 생성 및 상호작용을 위해 JSON-RPC 인터페이스를 사용하는 Ruby 이더리움 클라이언트이자 이더리움 노드와 작업하기 위한 유용한 툴킷_ * [omniauth-ethereum.rb (새 탭에서 열림)](https://github.com/q9f/omniauth-ethereum.rb) - _OmniAuth를 위한 이더리움 프로바이더 전략 구현체_ 더 많은 자료를 찾고 계신가요? [개발자 홈](https://ethereum.org/ko/developers/) 을 확인해 보세요. [](https://ethereum.org/ko/developers/docs/programming-languages/ruby/#ruby-community-contributors) Ruby 커뮤니티 기여자 ----------------------------------------------------------------------------------------------------------------- [이더리움 Ruby 텔레그램 그룹 (새 탭에서 열림)](https://t.me/ruby_eth) 은 빠르게 성장하는 커뮤니티의 호스트이며, 위의 프로젝트 및 관련 주제에 대한 토론을 위한 전용 리소스입니다. --- # Token Standards | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/standards/tokens/#main-content) Change page Token Standards =============== Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/tokens/index.md) On this page [](https://ethereum.org/developers/docs/standards/tokens/#introduction) Introduction ------------------------------------------------------------------------------------ Many [Ethereum](https://ethereum.org/) development standards focus on token interfaces. These standards help ensure smart contracts remain composable, so when a new project issues a token, it stays compatible with existing decentralized exchanges and applications. Token standards define how tokens behave and interact across the Ethereum ecosystem. They make it easier for developers to build without reinventing the wheel, ensuring that tokens work seamlessly with wallets, exchanges, and DeFi platforms. Whether in gaming, governance, or other use cases, these standards provide consistency and make Ethereum more interconnected. [](https://ethereum.org/developers/docs/standards/tokens/#prerequisites) Prerequisites -------------------------------------------------------------------------------------- * [Ethereum development standards](https://ethereum.org/developers/docs/standards/) * [Smart contracts](https://ethereum.org/developers/docs/smart-contracts/) [](https://ethereum.org/developers/docs/standards/tokens/#token-standards) Token standards ------------------------------------------------------------------------------------------ Here are some of the most popular token standards on Ethereum: * [ERC-20](https://ethereum.org/developers/docs/standards/tokens/erc-20/) - A standard interface for fungible (interchangeable) tokens, like voting tokens, staking tokens or virtual currencies. ### [](https://ethereum.org/developers/docs/standards/tokens/#nft-standards) NFT standards * [ERC-721](https://ethereum.org/developers/docs/standards/tokens/erc-721/) - A standard interface for non-fungible tokens, like a deed for artwork or a song. * [ERC-1155](https://ethereum.org/developers/docs/standards/tokens/erc-1155/) - ERC-1155 allows for more efficient trades and bundling of transactions – thus saving costs. This token standard allows for creating both utility tokens (such as $BNB or $BAT) and Non-Fungible Tokens like CryptoPunks. The full list of [ERC (opens in a new tab)](https://eips.ethereum.org/erc) proposals. [](https://ethereum.org/developers/docs/standards/tokens/#further-reading) Further reading ------------------------------------------------------------------------------------------ _Know of a community resource that helped you? Edit this page and add it!_ * [Token Integration Checklist (opens in a new tab)](https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/token_integration.md) - _Trail of Bits_ * [OpenZeppelin Documentation: Tokens (opens in a new tab)](https://docs.openzeppelin.com/contracts/5.x/tokens) - _OpenZeppelin_ * [The Dangers of Token integration (PDF) (opens in a new tab)](https://github.com/OpenZeppelin/workshops/blob/master/11-dangers-token-integration/slides.pdf) - _OpenZeppelin_ [](https://ethereum.org/developers/docs/standards/tokens/#related-tutorials) Related tutorials ---------------------------------------------------------------------------------------------- * [Token integration checklist](https://ethereum.org/developers/tutorials/token-integration-checklist/) _– A checklist of things to consider when interacting with tokens._ * [Understand the ERC20 token smart contract](https://ethereum.org/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– An introduction to deploying your first smart contract on an Ethereum test network._ * [Transfers and approval of ERC20 tokens from a Solidity smart contract](https://ethereum.org/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– How to use a smart contract to interact with a token using the Solidity language._ * [Implementing an ERC721 market \[a how-to guide\]](https://ethereum.org/developers/tutorials/how-to-implement-an-erc721-market/) _– How to put tokenized items for sale on a decentralized classifieds board._ --- # Dart 개발자를 위한 이더리움 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/programming-languages/dart/#main-content) Change page Dart 개발자를 위한 이더리움 ================= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/dart/index.md) 이 페이지의 내용 [](https://ethereum.org/ko/developers/docs/programming-languages/dart/#getting-started-with-smart-contracts-and-solidity) 스마트 컨트랙트 및 Solidity 언어 시작하기 ----------------------------------------------------------------------------------------------------------------------------------------------------- [](https://ethereum.org/ko/developers/docs/programming-languages/dart/#tutorials) 튜토리얼 -------------------------------------------------------------------------------------- * [Flutter 및 블록체인 – Hello World Dapp (새 탭에서 열림)](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) 은 시작하기 위한 모든 단계를 안내합니다: 1. [Solidity (새 탭에서 열림)](https://soliditylang.org/) 로 스마트 컨트랙트 작성하기 2. Dart로 사용자 인터페이스 작성하기 * [Flutter로 모바일 탈중앙화 애플리케이션 (dapp) 구축하기 (새 탭에서 열림)](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) 는 훨씬 짧으며, 이미 기본 사항을 알고 있는 경우 더 적합할 수 있습니다. * 동영상으로 배우는 것을 선호한다면, 약 1시간 분량의 [첫 번째 블록체인 Flutter 앱 구축하기 (새 탭에서 열림)](https://www.youtube.com/watch?v=3Eeh3pJ6PeA) 를 시청할 수 있습니다. * 시간이 부족하다면, 약 20분 분량의 [이더리움에서 Flutter와 Dart로 블록체인 탈중앙화 애플리케이션 (dapp) 구축하기 (새 탭에서 열림)](https://www.youtube.com/watch?v=jaMFEOCq_1s) 를 선호할 수 있습니다. * [WalletConnect의 Web3Modal을 사용하여 Flutter 애플리케이션에 메타마스크 통합하기 (새 탭에서 열림)](https://www.youtube.com/watch?v=v_M2buHCpc4) - 이 짧은 동영상은 WalletConnect의 [Web3Modal (새 탭에서 열림)](https://pub.dev/packages/web3modal_flutter) 라이브러리를 사용하여 Flutter 애플리케이션에 메타마스크를 통합하는 단계를 안내합니다. * [Solidity 및 Flutter를 활용한 모바일 블록체인 개발자 부트캠프 코스 (새 탭에서 열림)](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - 풀스택 모바일 블록체인 개발자 코스 재생 목록 [](https://ethereum.org/ko/developers/docs/programming-languages/dart/#working-with-ethereum-clients) 이더리움 클라이언트 작업하기 --------------------------------------------------------------------------------------------------------------------- 이더리움을 사용하여 암호화폐 및 블록체인 기술의 이점을 활용하는 탈중앙화 애플리케이션 (dapp)을 만들 수 있습니다. 이더리움용 [JSON-RPC API](https://ethereum.org/ko/developers/docs/apis/json-rpc/) 를 사용하기 위해 현재 유지 관리되는 Dart용 라이브러리가 최소 두 개 있습니다. 1. [pwa.ir의 Web3dart (새 탭에서 열림)](https://pub.dev/packages/web3dart) 2. [darticulate.com의 Ethereum 5.0.0 (새 탭에서 열림)](https://pub.dev/packages/ethereum) 특정 이더리움 주소를 조작하거나 다양한 암호화폐의 가격을 검색할 수 있는 추가 라이브러리도 있습니다. [여기에서 전체 목록을 확인할 수 있습니다 (새 탭에서 열림)](https://pub.dev/dart/packages?q=ethereum) . --- # .NET 개발자를 위한 이더리움 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/programming-languages/dot-net/#main-content) Change page .NET 개발자를 위한 이더리움 ================= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/dot-net/index.md) 이 페이지의 내용 .NET 기반 프로젝트 및 도구를 사용하여 이더리움용으로 개발하는 방법을 알아보세요. 이더리움을 사용하여 암호화폐와 블록체인 기술의 이점을 활용하는 탈중앙화 애플리케이션 (dapp)을 만들어 보세요. 이러한 dapp은 신뢰할 수 있으며, 이는 이더리움에 배포된 후에는 항상 프로그래밍된 대로 실행됨을 의미합니다. 디지털 자산을 제어하여 새로운 종류의 금융 애플리케이션을 만들 수 있습니다. 또한 탈중앙화되어 있어 단일 주체나 개인이 통제하지 않으며 검열이 거의 불가능합니다. 마이크로소프트 기술 스택의 도구와 언어를 사용하여 이더리움 기반의 탈중앙화 애플리케이션을 구축하고 스마트 컨트랙트와 상호 작용해 보세요. .NET Framework/.NET Core/.NET Standard 전반에 걸쳐 VSCode 및 Visual Studio와 같은 도구에서 C#, # Visual Basic .NET, F#을 지원합니다. 마이크로소프트 Azure Blockchain을 사용하여 몇 분 만에 Azure에 이더리움 블록체인을 배포할 수 있습니다. .NET에 대한 애정을 이더리움으로 가져오세요! [](https://ethereum.org/ko/developers/docs/programming-languages/dot-net/#getting-started-with-smart-contracts-and-the-solidity-language) 스마트 컨트랙트 및 Solidity 언어 시작하기 --------------------------------------------------------------------------------------------------------------------------------------------------------------------- **.NET과 이더리움 통합을 위한 첫걸음 내딛기** 더 기초적인 입문서가 먼저 필요하신가요? [ethereum.org/learn](https://ethereum.org/ko/learn/) 또는 [ethereum.org/developers](https://ethereum.org/ko/developers/) 를 확인해 보세요. * [블록체인 설명 (새 탭에서 열림)](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [스마트 컨트랙트의 이해 (새 탭에서 열림)](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [첫 번째 스마트 컨트랙트 작성하기 (새 탭에서 열림)](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Solidity 컴파일 및 배포 방법 알아보기 (새 탭에서 열림)](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) [](https://ethereum.org/ko/developers/docs/programming-languages/dot-net/#beginner-references-and-links) 초보자용 참고 자료 및 링크 ------------------------------------------------------------------------------------------------------------------------ **Nethereum 라이브러리 및 VS Code Solidity 소개** * [Nethereum 시작하기 (새 탭에서 열림)](https://docs.nethereum.com/docs/getting-started/welcome/) * [VS Code Solidity 설치하기 (새 탭에서 열림)](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) * [이더리움 스마트 컨트랙트 생성 및 호출을 위한 .NET 개발자의 워크플로 (새 탭에서 열림)](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2) * [Nethereum을 활용한 스마트 컨트랙트 통합 (새 탭에서 열림)](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm) * [Nethereum을 사용하여 .NET과 이더리움 블록체인 스마트 컨트랙트 연결하기 (새 탭에서 열림)](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933) , [中文版 (새 탭에서 열림)](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1) 도 제공됨 * [Nethereum - 블록체인을 위한 오픈 소스 .NET 통합 라이브러리 (새 탭에서 열림)](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/) * [Nethereum을 사용하여 SQL 데이터베이스에 이더리움 트랜잭션 기록하기 (새 탭에서 열림)](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36) * [C# 및 VisualStudio를 사용하여 이더리움 스마트 컨트랙트를 쉽게 배포하는 방법 알아보기 (새 탭에서 열림)](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c) **지금은 설정을 건너뛰고 바로 샘플을 확인하고 싶으신가요?** * [Nethereum Playground (새 탭에서 열림)](https://playground.nethereum.com/) - 브라우저를 통해 이더리움과 상호 작용하고 Nethereum 사용법을 배워보세요. * [계정 잔액 조회하기 (새 탭에서 열림)](https://docs.nethereum.com/docs/core-foundation/guide-query-balance) * [ERC-20 스마트 컨트랙트 잔액 조회하기 (새 탭에서 열림)](https://docs.nethereum.com/docs/smart-contracts/erc20) * [계정으로 이더 전송하기 (새 탭에서 열림)](https://docs.nethereum.com/docs/core-foundation/guide-send-eth) * ... 그 외 다수! [](https://ethereum.org/ko/developers/docs/programming-languages/dot-net/#intermediate-articles) 중급자용 문서 -------------------------------------------------------------------------------------------------------- * [Nethereum 시작하기 및 첫 번째 프로젝트 (새 탭에서 열림)](https://docs.nethereum.com/docs/getting-started/first-project) * [나만의 개발용 테스트 체인 배포하기 (새 탭에서 열림)](https://github.com/Nethereum/Testchains) * [Nethereum 및 VS Code를 활용한 코드 생성 (새 탭에서 열림)](https://docs.nethereum.com/docs/smart-contracts/code-generation/) * [Unity와 이더리움: 이유와 방법 (새 탭에서 열림)](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how) * [이더리움 탈중앙화 애플리케이션(dapp)을 위한 ASP.NET Core 웹 API 만들기 (새 탭에서 열림)](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/) * [구조화된 온체인 애플리케이션을 위한 Nethereum MUD 프레임워크 (새 탭에서 열림)](https://docs.nethereum.com/docs/mud-framework/overview/) * [Nethereum 블록체인 처리 (새 탭에서 열림)](https://docs.nethereum.com/docs/data-and-indexing/guide-blockchain-processing) * [Nethereum 실시간 스트리밍 (새 탭에서 열림)](https://docs.nethereum.com/docs/core-foundation/guide-realtime-streaming/) * [Kaleido와 Nethereum (새 탭에서 열림)](https://kaleido.io/kaleido-and-nethereum/) * [Quorum과 Nethereum (새 탭에서 열림)](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md) [](https://ethereum.org/ko/developers/docs/programming-languages/dot-net/#advanced-use-patterns) 고급 사용 패턴 --------------------------------------------------------------------------------------------------------- * [Azure Key 볼트 및 Nethereum (새 탭에서 열림)](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum) * [Nethereum.DappHybrid (새 탭에서 열림)](https://github.com/Nethereum/Nethereum.DappHybrid) * [Ujo Nethereum 백엔드 참조 아키텍처 (새 탭에서 열림)](https://github.com/Nethereum/ujo-backend) [](https://ethereum.org/ko/developers/docs/programming-languages/dot-net/#dot-net-projects-tools-and-other-fun-stuff) .NET 프로젝트, 도구 및 기타 흥미로운 자료 ------------------------------------------------------------------------------------------------------------------------------------------------ * [Nethereum Playground (새 탭에서 열림)](https://playground.nethereum.com/) - _브라우저에서 Nethereum 코드 스니펫을 컴파일, 생성 및 실행합니다._ * [Nethereum Codegen Blazor (새 탭에서 열림)](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _Blazor UI가 포함된 Nethereum 코드 생성기_ * [Nethereum Blazor (새 탭에서 열림)](https://github.com/Nethereum/NethereumBlazor) - _.NET Wasm SPA 기반의 가벼운 블록체인 탐색기 및 간단한 지갑_ * [Wonka 비즈니스 규칙 엔진 (새 탭에서 열림)](https://github.com/Nethereum/Wonka) - _본질적으로 메타데이터 기반인 비즈니스 규칙 엔진(.NET 플랫폼 및 이더리움 플랫폼 모두 지원)_ * [네더마인드 (새 탭에서 열림)](https://github.com/NethermindEth/nethermind) - _Linux, Windows, MacOS용 .NET Core 이더리움 클라이언트_ * [eth-utils (새 탭에서 열림)](https://github.com/ethereum/eth-utils/) - _이더리움 관련 코드베이스 작업을 위한 유틸리티 함수_ * [TestChains (새 탭에서 열림)](https://github.com/Nethereum/TestChains) - _빠른 응답을 위해 사전 구성된 .NET 개발 체인(권위 증명(PoA))_ 더 많은 리소스를 찾고 계신가요? [ethereum.org/developers](https://ethereum.org/ko/developers/) 를 확인해 보세요. [](https://ethereum.org/ko/developers/docs/programming-languages/dot-net/#dot-net-community-contributors) .NET 커뮤니티 기여자 ----------------------------------------------------------------------------------------------------------------------- Nethereum 커뮤니티는 주로 [Gitter (새 탭에서 열림)](https://gitter.im/Nethereum/Nethereum) 에서 활동하며, 누구나 질문하고 답변하거나 도움을 받고 편하게 어울릴 수 있습니다. [Nethereum GitHub 리포지토리 (새 탭에서 열림)](https://github.com/Nethereum) 에서 자유롭게 PR을 작성하거나 이슈를 열어주시고, 저희가 보유한 다양한 사이드/샘플 프로젝트를 둘러보셔도 좋습니다. [디스코드 (새 탭에서 열림)](https://discord.gg/jQPrR58FxX) 에서도 저희를 만나보실 수 있습니다! 네더마인드를 처음 접하고 시작하는 데 도움이 필요하시다면 [디스코드 (새 탭에서 열림)](https://discord.gg/PaCMRFdvWT) 에 참여해 보세요. 개발자들이 여러분의 질문에 답변해 드립니다. [네더마인드 GitHub 리포지토리 (새 탭에서 열림)](https://github.com/NethermindEth/nethermind) 에서 주저하지 말고 PR을 열거나 이슈를 제기해 주세요. [](https://ethereum.org/ko/developers/docs/programming-languages/dot-net/#other-aggregated-lists) 기타 종합 목록 ---------------------------------------------------------------------------------------------------------- [공식 Nethereum 사이트 (새 탭에서 열림)](https://nethereum.com/) [공식 네더마인드 사이트 (새 탭에서 열림)](https://nethermind.io/) --- # Sidechains | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/scaling/sidechains/#main-content) Change page Sidechains ========== Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/scaling/sidechains/index.md) On this page A sidechain is a separate blockchain that runs independent of [Ethereum](https://ethereum.org/) and is connected to Ethereum Mainnet by a two-way bridge. Sidechains can have separate block parameters and [consensus algorithms](https://ethereum.org/developers/docs/consensus-mechanisms/) , which are often designed for efficient processing of transactions. Using a sidechain involves trade-offs, though, as they do not inherit Ethereum's security properties. Unlike [layer 2 scaling solutions](https://ethereum.org/layer-2/) , sidechains do not post state changes and transaction data back to Ethereum Mainnet. Sidechains also sacrifice some measure of decentralization or security to achieve high throughput ([scalability trilemma (opens in a new tab)](https://vitalik.eth.limo/general/2021/05/23/scaling.html) ). Ethereum is, however, committed to scaling without compromising on decentralization and security. [](https://ethereum.org/developers/docs/scaling/sidechains/#how-do-sidechains-work) How do sidechains work? ----------------------------------------------------------------------------------------------------------- Sidechains are independent blockchains, with different histories, development roadmaps, and design considerations. While a sidechain may share some surface-level similarities with Ethereum, it has several distinctive features. ### [](https://ethereum.org/developers/docs/scaling/sidechains/#consensus-algorithms) Consensus algorithms One of the qualities that make sidechains unique (i.e., different from Ethereum) is the consensus algorithm used. Sidechains don't rely on Ethereum for consensus and can choose alternative consensus protocols that suit their needs. Some examples of consensus algorithms used on sidechains include: * [Proof-of-authority](https://ethereum.org/developers/docs/consensus-mechanisms/poa/) * [Delegated proof-of-stake (opens in a new tab)](https://en.bitcoin.it/wiki/Delegated_proof_of_stake) * [Byzantine fault tolerance (opens in a new tab)](https://decrypt.co/resources/byzantine-fault-tolerance-what-is-it-explained) . Like Ethereum, sidechains have validating nodes that verify and process transactions, produce blocks, and store the blockchain state. Validators are also responsible for maintaining consensus across the network and securing it against malicious attacks. #### [](https://ethereum.org/developers/docs/scaling/sidechains/#block-parameters) Block parameters Ethereum places limits on [block times](https://ethereum.org/developers/docs/blocks/#block-time) (i.e., the time it takes to produce new blocks) and [block sizes](https://ethereum.org/developers/docs/blocks/#block-size) (i.e., the amount of data contained per block denominated in gas). Conversely, sidechains often adopt different parameters, such as faster block times and higher gas limits, to achieve high throughput, fast transactions, and low fees. While this has some benefits, it has critical implications for network decentralization and security. Block parameters, like fast block times and big block sizes, increase the difficulty of running a full node—leaving a few "supernodes" responsible for securing the chain. In such a scenario, the possibility of validator collusion or a malicious takeover of the chain increases. For blockchains to scale without harming decentralization, running a node must be open to everyone—not necessarily parties with specialized hardware. This is why efforts are underway to ensure everyone can [run a full node](https://ethereum.org/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node) on the Ethereum network. ### [](https://ethereum.org/developers/docs/scaling/sidechains/#evm-compatibility) EVM compatibility Some sidechains are EVM-compatible and are able to execute contracts developed for the [Ethereum Virtual Machine (EVM)](https://ethereum.org/developers/docs/evm/) . EVM-compatible sidechains support smart contracts [written in Solidity](https://ethereum.org/developers/docs/smart-contracts/languages/) , as well as other EVM smart contract languages, which means smart contracts written for Ethereum Mainnet will also work on EVM-compatible sidechains. This means if you want to use your [dapp](https://ethereum.org/developers/docs/dapps/) on a sidechain, it's just a matter of deploying your [smart contract](https://ethereum.org/developers/docs/smart-contracts/) to this sidechain. It looks, feels, and acts just like Mainnet—you write contracts in Solidity, and interact with the chain via the sidechains RPC. Because sidechains are EVM-compatible, they are considered a useful [scaling solution](https://ethereum.org/developers/docs/scaling/) for Ethereum-native dapps. With your dapp on a sidechain, users can enjoy lower gas fees and faster transactions, especially if Mainnet is congested. However, as explained previously, using a sidechain involves significant trade-offs. Each sidechain is responsible for its security and doesn't inherit Ethereum's security properties. This increases the possibility of malicious behavior which can affect your users or put their funds at risk. ### [](https://ethereum.org/developers/docs/scaling/sidechains/#asset-movement) Asset movement In order for a separate blockchain to become a sidechain to Ethereum Mainnet it needs the ability to facilitate the transfer of assets from and to Ethereum Mainnet. This interoperability with Ethereum is achieved using a blockchain bridge. [Bridges](https://ethereum.org/bridges/) use smart contracts deployed on Ethereum Mainnet and a sidechain to control the bridging of funds between them. While bridges help users move funds between Ethereum and the sidechain, the assets are not physically moved across the two chains. Instead, mechanisms that typically involve minting and burning are used for transferring value across chains. More on [how bridges work](https://ethereum.org/developers/docs/bridges/#how-do-bridges-work) . [](https://ethereum.org/developers/docs/scaling/sidechains/#pros-and-cons-of-sidechains) Pros and cons of sidechains -------------------------------------------------------------------------------------------------------------------- | Pros | Cons | | --- | --- | | The technology underpinning sidechains is well-established and benefits from extensive research and improvements in design. | Sidechains trade off some measure of decentralization and trustlessness for scalability. | | Sidechains support general computation and offer EVM compatibility (they can run Ethereum-native dapps). | A sidechain uses a separate consensus mechanism and doesn't benefit from Ethereum's security guarantees. | | Sidechains use different consensus models to efficiently process transactions and lower transaction fees for users. | Sidechains require higher trust assumptions (e.g., a quorum of malicious sidechain validators can commit fraud). | | EVM-compatible sidechains allow dapps to expand their ecosystem. | | ### [](https://ethereum.org/developers/docs/scaling/sidechains/#use-sidechains) Use Sidechains Multiple projects provide implementations of sidechains that you can integrate into your dapps: * [Polygon PoS (opens in a new tab)](https://polygon.technology/solutions/polygon-pos) * [Skale (opens in a new tab)](https://skale.network/) * [Gnosis Chain (formerly xDai) (opens in a new tab)](https://www.gnosischain.com/) * [Loom Network (opens in a new tab)](https://loomx.io/) * [Metis Andromeda (opens in a new tab)](https://www.metis.io/) [](https://ethereum.org/developers/docs/scaling/sidechains/#further-reading) Further reading -------------------------------------------------------------------------------------------- * [Scaling Ethereum dapps through Sidechains (opens in a new tab)](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _Feb 8, 2018 - Georgios Konstantopoulos_ _Know of a community resource that helped you? Edit this page and add it!_ --- # Ethereum for Rust developers | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/programming-languages/rust/#main-content) Change page Ethereum for Rust developers ============================ Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/programming-languages/rust/index.md) On this page Learn how to develop for Ethereum using Rust-based projects and tooling Use Ethereum to create decentralized applications (or "dapps") that utilize the benefits of cryptocurrency and blockchain technology. These dapps can be trustworthy, meaning that once they are deployed to Ethereum, they will always run as programmed. They can control digital assets in order to create new kinds of financial applications. They can be decentralized, meaning that no single entity or person controls them and are nearly impossible to censor. [](https://ethereum.org/developers/docs/programming-languages/rust/#getting-started-with-smart-contracts-and-solidity) Getting started with smart contracts and the Solidity language ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- **Take your first steps to integrating Rust with Ethereum** Need a more basic primer first? Check out [ethereum.org/learn](https://ethereum.org/learn/) or [ethereum.org/developers](https://ethereum.org/developers/) . * [Blockchain Explained (opens in a new tab)](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) * [Understanding Smart Contracts (opens in a new tab)](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) * [Write your First Smart Contract (opens in a new tab)](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) * [Learn How to Compile and Deploy Solidity (opens in a new tab)](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) [](https://ethereum.org/developers/docs/programming-languages/rust/#beginner-articles) Beginner articles -------------------------------------------------------------------------------------------------------- * [The Rust Ethereum Client (opens in a new tab)](https://openethereum.github.io/) \* **Note that OpenEthereum [has been deprecated (opens in a new tab)](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) and is no longer being maintained.** Use it with caution and preferably switch to another client implementation. * [Sending Transaction to Ethereum Using Rust (opens in a new tab)](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/) * [A step-by-step tutorial on how to write contracts in rust Wasm for Kovan (opens in a new tab)](https://github.com/paritytech/pwasm-tutorial) [](https://ethereum.org/developers/docs/programming-languages/rust/#intermediate-articles) Intermediate articles ---------------------------------------------------------------------------------------------------------------- [](https://ethereum.org/developers/docs/programming-languages/rust/#advanced-use-patterns) Advanced use patterns ---------------------------------------------------------------------------------------------------------------- * [pwasm\_ethereum externs library to interact with Ethereum-like network (opens in a new tab)](https://github.com/openethereum/pwasm-ethereum) * [Build A Decentralized Chat Using JavaScript and Rust (opens in a new tab)](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52) * [Build a Decentralized Todo App Using Vue.js & Rust (opens in a new tab)](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb) * [Build a blockchain in Rust (opens in a new tab)](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/) [](https://ethereum.org/developers/docs/programming-languages/rust/#rust-projects-and-tools) Rust projects and tools -------------------------------------------------------------------------------------------------------------------- * [pwasm-ethereum (opens in a new tab)](https://github.com/paritytech/pwasm-ethereum) - _Collection of externs to interact with Ethereum-like network_ * [Lighthouse (opens in a new tab)](https://github.com/sigp/lighthouse) - _Fast Ethereum consensus layer client_ * [Ethereum WebAssembly (opens in a new tab)](https://ewasm.readthedocs.io/en/mkdocs/) - _Proposed redesign of the Ethereum smart contract execution layer using a deterministic subset of WebAssembly_ * [oasis\_std (opens in a new tab)](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _OASIS API reference_ * [Solaris (opens in a new tab)](https://github.com/paritytech/sol-rs) - _Solidity Smart Contracts unit test harness using the native Parity Client EVM._ * [SputnikVM (opens in a new tab)](https://github.com/rust-blockchain/evm) - _Rust Ethereum Virtual Machine Implementation_ * [Wavelet (opens in a new tab)](https://github.com/perlin-network/smart-contract-rs) - _Wavelet smart contract in Rust_ * [Foundry (opens in a new tab)](https://github.com/foundry-rs/foundry) - _Toolkit for Ethereum application development_ * [Alloy (opens in a new tab)](https://alloy.rs/) - _High-performance, well-tested & documented libraries for interacting with Ethereum and other EVM-based chains._ * [Ethers\_rs (opens in a new tab)](https://github.com/gakonst/ethers-rs) - _Ethereum library and wallet implementation_ * [SewUp (opens in a new tab)](https://github.com/second-state/SewUp) - _A library to help you build your Ethereum webassembly contract with Rust and just like develop in a common backend_ * [Substreams (opens in a new tab)](https://github.com/streamingfast/substreams) - _Parallelized blockchain data indexing technology_ * [Reth (opens in a new tab)](https://github.com/paradigmxyz/reth) Reth (short for Rust Ethereum) is a new Ethereum full-node implementation * [Awesome Ethereum Rust (opens in a new tab)](https://github.com/Vid201/awesome-ethereum-rust) - _A curated collection of projects in the Ethereum ecosystem written in Rust_ * [Stylus (opens in a new tab)](https://github.com/OffchainLabs/stylus) - _Rust SDK for building smart contracts on Arbitrum_ Looking for more resources? Check out [ethereum.org/developers.](https://ethereum.org/developers/) [](https://ethereum.org/developers/docs/programming-languages/rust/#rust-community-contributors) Rust community contributors ---------------------------------------------------------------------------------------------------------------------------- * [Ethereum WebAssembly (opens in a new tab)](https://gitter.im/ewasm/Lobby) * [Oasis Gitter (opens in a new tab)](https://gitter.im/Oasis-official/Lobby) * [Parity Gitter (opens in a new tab)](https://gitter.im/paritytech/parity) * [Enigma (opens in a new tab)](https://discord.gg/SJK32GY) --- # ERC-1155 Multi-Token Standard | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#main-content) Change page ERC-1155 Multi-Token Standard ============================= Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/tokens/erc-1155/index.md) On this page [](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#introduction) Introduction --------------------------------------------------------------------------------------------- A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens or other configurations (e.g., semi-fungible tokens). **What is meant by Multi-Token Standard?** The idea is simple and seeks to create a smart contract interface that can represent and control any number of fungible and non-fungible token types. In this way, the ERC-1155 token can do the same functions as an [ERC-20](https://ethereum.org/developers/docs/standards/tokens/erc-20/) and [ERC-721](https://ethereum.org/developers/docs/standards/tokens/erc-721/) token, and even both at the same time. It improves the functionality of both the ERC-20 and ERC-721 standards, making it more efficient and correcting obvious implementation errors. The ERC-1155 token is described fully in [EIP-1155 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-1155) . [](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#prerequisites) Prerequisites ----------------------------------------------------------------------------------------------- To better understand this page, we recommend you first read about [token standards](https://ethereum.org/developers/docs/standards/tokens/) , [ERC-20](https://ethereum.org/developers/docs/standards/tokens/erc-20/) , and [ERC-721](https://ethereum.org/developers/docs/standards/tokens/erc-721/) . [](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#body) ERC-1155 Functions and Features: --------------------------------------------------------------------------------------------------------- * [Batch Transfer](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#batch-transfers) : Transfer multiple assets in a single call. * [Batch Balance](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#batch-balance) : Get the balances of multiple assets in a single call. * [Batch Approval](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#batch-approval) : Approve all tokens to an address. * [Hooks](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#receive-hook) : Receive tokens hook. * [NFT Support](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#nft-support) : If supply is only 1, treat it as NFT. * [Safe Transfer Rules](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#safe-transfer-rule) : Set of rules for secure transfer. ### [](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#batch-transfers) Batch Transfers The batch transfer works very similar to regular ERC-20 transfers. Let's look at the regular ERC-20 `transferFrom` function: // ERC-20 function transferFrom(address from, address to, uint256 value) external returns (bool); // ERC-1155 function safeBatchTransferFrom( address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data ) external; CopySolidity Show all (11) The only difference in ERC-1155 is that we pass the values as an array and we also pass an array of ids. For example given `ids=[3, 6, 13]` and `values=[100, 200, 5]`, the resulting transfers will be 1. Transfer 100 tokens with id 3 from `_from` to `_to`. 2. Transfer 200 tokens with id 6 from `_from` to `_to`. 3. Transfer 5 tokens with id 13 from `_from` to `_to`. In ERC-1155 we only have `transferFrom`, no `transfer`. To use it like a regular `transfer`, just set the from address to the address that's calling the function. ### [](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#batch-balance) Batch Balance The respective ERC-20 `balanceOf` call likewise has its partner function with batch support. As a reminder, this is the ERC-20 version: // ERC-20 function balanceOf(address owner) external view returns (uint256); // ERC-1155 function balanceOfBatch( address[] calldata _owners, uint256[] calldata _ids ) external view returns (uint256[] memory); CopySolidity Even simpler for the balance call, we can retrieve multiple balances in a single call. We pass the array of owners, followed by the array of token ids. For example given `_ids=[3, 6, 13]` and `_owners=[0xbeef..., 0x1337..., 0x1111...]`, the return value will be [\ balanceOf(0xbeef...),\ balanceOf(0x1337...),\ balanceOf(0x1111...)\ ] CopySolidity ### [](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#batch-approval) Batch Approval // ERC-1155 function setApprovalForAll( address _operator, bool _approved ) external; function isApprovedForAll( address _owner, address _operator ) external view returns (bool); CopySolidity Show all (10) The approvals are slightly different than ERC-20. Instead of approving specific amounts, you set an operator to approved or not approved via `setApprovalForAll`. Reading the current status can be done via `isApprovedForAll`. As you can see, it's an all-or-nothing operation. You cannot define how many tokens to approve or even which token class. This is intentionally designed with simplicity in mind. You can only approve everything for one address. ### [](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#receive-hook) Receive Hook function onERC1155BatchReceived( address _operator, address _from, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data ) external returns(bytes4); CopySolidity Given the [EIP-165 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-165) support, ERC-1155 supports receive hooks for smart contracts only. The hook function must return a magic predefined bytes4 value which is given as: bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) CopySolidity When the receiving contract returns this value, it is assumed the contract accepts the transfer and knows how to handle the ERC-1155 tokens. Great, no more stuck tokens in a contract! ### [](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#nft-support) NFT Support When the supply is just one, the token is essentially a non-fungible token (NFT). And as is standard for ERC-721, you can define a metadata URL. The URL can be read and modified by clients, see [here (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-1155#metadata) . ### [](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#safe-transfer-rule) Safe Transfer Rule We've touched on a few safe transfer rules already in the previous explanations. But let's look at the most important of the rules: 1. The caller must be approved to spend the tokens for the `_from` address or the caller must equal `_from`. 2. The transfer call must revert if 1. `_to` address is 0. 2. length of `_ids` is not the same as length of `_values`. 3. any of the balance(s) of the holder(s) for token(s) in `_ids` is lower than the respective amount(s) in `_values` sent to the recipient. 4. any other error occurs. _Note_: All batch functions including the hook also exist as versions without batch. This is done for gas efficiency, considering transferring just one asset will likely still be the most commonly used way. We've left them out for simplicity in the explanations, including safe transfer rules. The names are identical, just remove the 'Batch'. [](https://ethereum.org/developers/docs/standards/tokens/erc-1155/#further-reading) Further reading --------------------------------------------------------------------------------------------------- * [EIP-1155: Multi Token Standard (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-1155) * [ERC-1155: Openzeppelin Docs (opens in a new tab)](https://docs.openzeppelin.com/contracts/5.x/erc1155) * [ERC-1155: GitHub Repo (opens in a new tab)](https://github.com/enjin/erc-1155) * [Alchemy NFT API (opens in a new tab)](https://www.alchemy.com/docs/reference/nft-api-quickstart) --- # 디앱(dapp) 개발 프레임워크 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/frameworks/#main-content) Change page 디앱(dapp) 개발 프레임워크 ================= .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/frameworks/index.md) 이 페이지의 내용 [](https://ethereum.org/ko/developers/docs/frameworks/#introduction-to-frameworks) 프레임워크 소개 ------------------------------------------------------------------------------------------- 완성도 높은 탈중앙화 애플리케이션 (dapp)을 구축하려면 다양한 기술이 필요합니다. 소프트웨어 프레임워크는 필요한 많은 기능을 포함하고 있거나, 원하는 도구를 선택할 수 있는 쉬운 플러그인 시스템을 제공합니다. 프레임워크는 다음과 같이 기본적으로 제공되는 많은 기능을 갖추고 있습니다. * 로컬 블록체인 인스턴스를 구동하는 기능. * 스마트 컨트랙트를 컴파일하고 테스트하기 위한 유틸리티. * 동일한 프로젝트/저장소 내에서 사용자 대면 애플리케이션을 구축하기 위한 클라이언트 개발 애드온. * 로컬에서 실행 중인 인스턴스이든 이더리움의 퍼블릭 네트워크 중 하나이든, 이더리움 네트워크에 연결하고 컨트랙트를 배포하기 위한 구성. * 탈중앙화 앱 배포 - IPFS와 같은 스토리지 옵션과의 통합. [](https://ethereum.org/ko/developers/docs/frameworks/#prerequisites) 전제 조건 --------------------------------------------------------------------------- 프레임워크에 대해 자세히 알아보기 전에, 먼저 [디앱(dapp)](https://ethereum.org/ko/developers/docs/dapps/) 과 [이더리움 스택](https://ethereum.org/ko/developers/docs/ethereum-stack/) 에 대한 소개를 읽어보시기를 권장합니다. 사용 가능한 프레임워크 ------------ **Foundry** - **_Foundry는 이더리움 애플리케이션 개발을 위한 매우 빠르고 이식성이 뛰어나며 모듈화된 툴킷입니다._** * [Foundry 설치 (새 탭에서 열림)](https://book.getfoundry.sh/) * [Foundry 북 (새 탭에서 열림)](https://book.getfoundry.sh/) * [텔레그램의 Foundry 커뮤니티 채팅 (새 탭에서 열림)](https://t.me/foundry_support) * [Awesome Foundry (새 탭에서 열림)](https://github.com/crisgarner/awesome-foundry) **Hardhat -** **_전문가를 위한 이더리움 개발 환경입니다._** * [hardhat.org (새 탭에서 열림)](https://hardhat.org/) * [GitHub (새 탭에서 열림)](https://github.com/nomiclabs/hardhat) **Ape -** **_Python 개발자, 데이터 과학자 및 보안 전문가를 위한 스마트 컨트랙트 개발 도구입니다._** * [문서 (새 탭에서 열림)](https://docs.apeworx.io/ape/stable/) * [GitHub (새 탭에서 열림)](https://github.com/ApeWorX/ape) **Web3j -** **_JVM에서 블록체인 애플리케이션을 개발하기 위한 플랫폼입니다._** * [홈페이지 (새 탭에서 열림)](https://www.web3labs.com/web3j-sdk) * [문서 (새 탭에서 열림)](https://docs.web3j.io/) * [GitHub (새 탭에서 열림)](https://github.com/web3j/web3j) **ethers-kt -** **_EVM 기반 블록체인을 위한 비동기식 고성능 Kotlin/Java/Android 라이브러리입니다._** * [GitHub (새 탭에서 열림)](https://github.com/Kr1ptal/ethers-kt) * [예제 (새 탭에서 열림)](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) * [디스코드 (새 탭에서 열림)](https://discord.gg/rx35NzQGSb) **Create Eth App -** **_명령어 하나로 이더리움 기반 앱을 생성합니다. 선택할 수 있는 다양한 UI 프레임워크와 탈중앙화 금융 (DeFi) 템플릿이 함께 제공됩니다._** * [GitHub (새 탭에서 열림)](https://github.com/paulrberg/create-eth-app) * [템플릿 (새 탭에서 열림)](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates) **Scaffold-ETH 2 -** **_Next.js, Wagmi, Viem 및 RainbowKit과 함께 Hardhat 또는 Foundry를 선택할 수 있습니다. 컨트랙트 핫 리로드, 사용자 지정 React 훅, 버너 지갑 및 로컬 퍼싯, 풀스택 탈중앙화 애플리케이션 (dapp) 개발을 위한 확장 모듈을 제공합니다._** * [웹사이트 (새 탭에서 열림)](https://scaffoldeth.io/) * [GitHub (새 탭에서 열림)](https://github.com/scaffold-eth/scaffold-eth-2) **Tenderly -** **_블록체인 개발자가 스마트 컨트랙트를 구축, 테스트, 디버그, 모니터링 및 운영하고 dapp UX를 개선할 수 있도록 지원하는 Web3 개발 플랫폼입니다._** * [웹사이트 (새 탭에서 열림)](https://tenderly.co/) * [문서 (새 탭에서 열림)](https://docs.tenderly.co/) **The Graph -** **_블록체인 데이터를 효율적으로 쿼리하기 위한 The Graph입니다._** * [웹사이트 (새 탭에서 열림)](https://thegraph.com/) * [튜토리얼](https://ethereum.org/ko/developers/tutorials/the-graph-fixing-web3-data-querying/) **Alchemy -** **_이더리움 개발 플랫폼입니다._** * [alchemy.com (새 탭에서 열림)](https://www.alchemy.com/) * [GitHub (새 탭에서 열림)](https://github.com/alchemyplatform) * [디스코드 (새 탭에서 열림)](https://discord.com/invite/alchemyplatform) **NodeReal -** **_이더리움 개발 플랫폼입니다._** * [Nodereal.io (새 탭에서 열림)](https://nodereal.io/) * [GitHub (새 탭에서 열림)](https://github.com/node-real) * [디스코드 (새 탭에서 열림)](https://discord.gg/V5k5gsuE) **thirdweb SDK -** **_강력한 SDK 및 CLI를 사용하여 스마트 컨트랙트와 상호 작용할 수 있는 Web3 애플리케이션을 구축하세요._** * [문서 (새 탭에서 열림)](https://portal.thirdweb.com/sdk/) * [GitHub (새 탭에서 열림)](https://github.com/thirdweb-dev/) **Chainstack -** **_Web3 (이더리움 및 기타) 개발 플랫폼입니다._** * [chainstack.com (새 탭에서 열림)](https://www.chainstack.com/) * [GitHub (새 탭에서 열림)](https://github.com/chainstack) * [디스코드 (새 탭에서 열림)](https://discord.gg/BSb5zfp9AT) **Crossmint -** **_모든 주요 체인, EVM 체인(및 기타)에서 NFT 애플리케이션을 구축할 수 있는 엔터프라이즈급 Web3 개발 플랫폼입니다._** * [웹사이트 (새 탭에서 열림)](https://www.crossmint.com/) * [문서 (새 탭에서 열림)](https://docs.crossmint.com/) * [디스코드 (새 탭에서 열림)](https://discord.com/invite/crossmint) **Brownie -** **_Python 기반 개발 환경 및 테스트 프레임워크입니다._** * [문서 (새 탭에서 열림)](https://eth-brownie.readthedocs.io/en/latest/) * [GitHub (새 탭에서 열림)](https://github.com/eth-brownie/brownie) * **Brownie는 현재 유지 관리되지 않습니다** **오픈제플린 SDK -** **_궁극의 스마트 컨트랙트 툴킷: 스마트 컨트랙트를 개발, 컴파일, 업그레이드, 배포 및 상호 작용하는 데 도움이 되는 도구 모음입니다._** * [오픈제플린 Defender SDK (새 탭에서 열림)](https://docs.openzeppelin.com/defender/sdk) * [GitHub (새 탭에서 열림)](https://github.com/OpenZeppelin/openzeppelin-sdk) * [커뮤니티 포럼 (새 탭에서 열림)](https://forum.openzeppelin.com/c/support/17) * **오픈제플린 SDK 개발이 종료되었습니다** **Catapulta -** **_멀티 체인 스마트 컨트랙트 배포 도구로, 블록 탐색기에서의 검증을 자동화하고, 배포된 스마트 컨트랙트를 추적하며, 배포 보고서를 공유하고, Foundry 및 Hardhat 프로젝트를 위한 플러그 앤 플레이를 지원합니다._** * [GitHub (새 탭에서 열림)](https://github.com/catapulta-sh) **GoldRush (Covalent 기반) -** **_GoldRush는 개발자, 분석가 및 기업을 위한 가장 포괄적인 블록체인 데이터 API 제품군을 제공합니다. DeFi 대시보드, 지갑, 트레이딩 봇, AI 에이전트 또는 규정 준수 플랫폼 등 무엇을 구축하든, 데이터 API는 필요한 필수 온체인 데이터에 빠르고 정확하며 개발자 친화적인 액세스를 제공합니다._** * [웹사이트 (새 탭에서 열림)](https://goldrush.dev/) * [문서 (새 탭에서 열림)](https://goldrush.dev/docs/chains/ethereum) * [GitHub (새 탭에서 열림)](https://github.com/covalenthq) * [디스코드 (새 탭에서 열림)](https://www.covalenthq.com/discord/) **Wake -** **_컨트랙트 테스트, 퍼징, 배포, 취약점 스캐닝 및 코드 탐색을 위한 올인원 Python 프레임워크입니다._** * [홈페이지 (새 탭에서 열림)](https://getwake.io/) * [문서 (새 탭에서 열림)](https://ackeeblockchain.com/wake/docs/latest/) * [GitHub (새 탭에서 열림)](https://github.com/Ackee-Blockchain/wake) * [VS Code 확장 프로그램 (새 탭에서 열림)](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity) **Veramo -** **_오픈 소스이며 모듈화되어 있고 특정 기술에 종속되지 않는 프레임워크로, dapp 개발자가 애플리케이션에 탈중앙화 신원 및 검증 가능한 자격 증명을 쉽게 구축할 수 있도록 합니다._** * [홈페이지 (새 탭에서 열림)](https://veramo.io/) * [문서 (새 탭에서 열림)](https://veramo.io/docs/basics/introduction) * [GitHub (새 탭에서 열림)](https://github.com/uport-project/veramo) * [디스코드 (새 탭에서 열림)](https://discord.com/invite/FRRBdjemHV) * [NPM 패키지 (새 탭에서 열림)](https://www.npmjs.com/package/@veramo/core) **Moccasin -** **_Titanoboa를 기반으로 구축된 Vyper를 위한 빠르고 Pythonic한 스마트 컨트랙트 개발 및 테스트 프레임워크입니다._** * [문서 (새 탭에서 열림)](https://cyfrin.github.io/moccasin/) * [GitHub (새 탭에서 열림)](https://github.com/Cyfrin/moccasin) [](https://ethereum.org/ko/developers/docs/frameworks/#further-reading) 더 읽어보기 ------------------------------------------------------------------------------ _도움이 된 커뮤니티 리소스를 알고 계신가요? 이 페이지를 편집하여 추가해 주세요!_ [](https://ethereum.org/ko/developers/docs/frameworks/#related-topics) 관련 주제 ---------------------------------------------------------------------------- * [로컬 개발 환경 설정](https://ethereum.org/ko/developers/local-environment/) [](https://ethereum.org/ko/developers/docs/frameworks/#tutorials) 튜토리얼: 이더리움 개발 프레임워크 ------------------------------------------------------------------------------------- * [초보자를 위한 Hello World 스마트 컨트랙트 – 풀스택](https://ethereum.org/ko/developers/tutorials/hello-world-smart-contract-fullstack/) _– Hardhat을 사용하여 Hello World 스마트 컨트랙트를 구축 및 배포한 다음, 프론트엔드에 연결합니다._ --- # Scaling | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/scaling/#main-content) Change page Scaling ======= Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/scaling/index.md) On this page [](https://ethereum.org/developers/docs/scaling/#scaling-overview) Scaling overview ----------------------------------------------------------------------------------- As the number of people using [Ethereum](https://ethereum.org/) has grown, the blockchain has reached certain capacity limitations. This has driven up the cost of using the network, creating the need for "scaling solutions." There are multiple solutions being researched, tested and implemented that take different approaches to achieve similar goals. The main goal of scalability is to increase transaction speed (faster finality) and transaction throughput (higher number of transactions per second) without sacrificing decentralization or security. On the layer 1 Ethereum blockchain, high demand leads to slower transactions and nonviable [gas prices](https://ethereum.org/developers/docs/gas/) . Increasing the network capacity in terms of speed and throughput is fundamental to the meaningful and mass adoption of Ethereum. While speed and throughput are important, it is essential that scaling solutions enabling these goals remain decentralized and secure. Keeping the barrier to entry low for node operators is critical in preventing a progression towards centralized and insecure computing power. Conceptually we first categorize scaling as either onchain scaling or offchain scaling. [](https://ethereum.org/developers/docs/scaling/#prerequisites) Prerequisites ----------------------------------------------------------------------------- You should have a good understanding of all the foundational topics. Implementing scaling solutions is advanced as the technology is less battle-tested, and continues to be researched and developed. [](https://ethereum.org/developers/docs/scaling/#onchain-scaling) Onchain scaling --------------------------------------------------------------------------------- Onchain scaling requires changes to the Ethereum protocol (layer 1 ). For a long time, sharding the blockchain was expected to scale Ethereum. This was going to involve splitting the blockchain into discrete pieces (shards) to be verified by subsets of validators. However, scaling by layer-2 rollups has taken over as the primary scaling technique. This is supported by the addition of a new cheaper form of data attached to Ethereum blocks that is specially designed to make rollups cheap for users. ### [](https://ethereum.org/developers/docs/scaling/#sharding) Sharding Sharding is the process of splitting a database. Subsets of validators would be responsible for individual shards rather than keeping track of all of Ethereum. Sharding was on the Ethereum [roadmap](https://ethereum.org/roadmap/) for a long time, and was once intended to be shipped before The Merge to proof-of-stake. However, the rapid development of [layer 2 rollups](https://ethereum.org/developers/docs/scaling/#layer-2-scaling) and the invention of [Danksharding](https://ethereum.org/roadmap/danksharding/) (adding blobs of rollup data to Ethereum blocks that can be very efficiently verified by validators) has led the Ethereum community to favour rollup-centric scaling instead of scaling by sharding. This will also help to keep Ethereum's consensus logic simpler. [](https://ethereum.org/developers/docs/scaling/#offchain-scaling) Offchain scaling ----------------------------------------------------------------------------------- Offchain solutions are implemented separately from layer 1 Mainnet - they require no changes to the existing Ethereum protocol. Some solutions, known as "layer 2" solutions, derive their security directly from layer 1 Ethereum consensus, such as [optimistic rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) , [zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) or [state channels](https://ethereum.org/developers/docs/scaling/state-channels/) . Other solutions involve the creation of new chains in various forms that derive their security separately from Mainnet, such as [sidechains](https://ethereum.org/developers/docs/scaling/#sidechains) , [validiums](https://ethereum.org/developers/docs/scaling/#validium) , or [plasma chains](https://ethereum.org/developers/docs/scaling/#plasma) . These solutions communicate with Mainnet but derive their security differently to obtain a variety of goals. ### [](https://ethereum.org/developers/docs/scaling/#layer-2-scaling) Layer 2 scaling This category of offchain solutions derives its security from Mainnet Ethereum. Layer 2 is a collective term for solutions designed to help scale your application by handling transactions off the Ethereum Mainnet (layer 1) while taking advantage of the robust decentralized security model of Mainnet. Transaction speed suffers when the network is busy, making the user experience poor for certain types of dapps. And as the network gets busier, gas prices increase as transaction senders aim to outbid each other. This can make using Ethereum very expensive. Most layer 2 solutions are centered around a server or cluster of servers, each of which may be referred to as a node, validator, operator, sequencer, block producer, or similar term. Depending on the implementation, these layer 2 nodes may be run by the individuals, businesses or entities that use them, or by a 3rd party operator, or by a large group of individuals (similar to Mainnet). Generally speaking, transactions are submitted to these layer 2 nodes instead of being submitted directly to layer 1 (Mainnet). For some solutions, the layer 2 instance then batches them into groups before anchoring them to layer 1, after which they are secured by layer 1 and cannot be altered. The details of how this is done vary significantly between different layer 2 technologies and implementations. A specific layer 2 instance may be open and shared by many applications, or may be deployed by one project and dedicated to supporting only their application. #### [](https://ethereum.org/developers/docs/scaling/#why-is-layer-2-needed) Why is layer 2 needed? * Increased transactions per second greatly improves user experience, and reduces network congestion on Mainnet Ethereum. * Transactions are rolled up into a single transaction to Mainnet Ethereum, reducing gas fees for users and making Ethereum more inclusive and accessible for people everywhere. * Any updates to scalability should not be at the expense of decentralization or security – layer 2 builds on top of Ethereum. * There are application-specific layer 2 networks that bring their own set of efficiencies when working with assets at scale. [More on layer 2](https://ethereum.org/layer-2/) . #### [](https://ethereum.org/developers/docs/scaling/#rollups) Rollups Rollups perform transaction execution outside layer 1 and then the data is posted to layer 1 where consensus is reached. As transaction data is included in layer 1 blocks, this allows rollups to be secured by native Ethereum security. There are two types of rollups with different security models: * **Optimistic rollups**: assumes transactions are valid by default and only runs computation, via a , in the event of a challenge. [More on Optimistic rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) . * **Zero-knowledge rollups**: runs computation offchain and submits a to the chain. [More on zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) . #### [](https://ethereum.org/developers/docs/scaling/#channels) State channels State channels utilize multisig contracts to enable participants to transact quickly and freely offchain, then settle finality with Mainnet. This minimizes network congestion, fees, and delays. The two types of channels are currently state channels and payment channels. Learn more about [state channels](https://ethereum.org/developers/docs/scaling/state-channels/) . ### [](https://ethereum.org/developers/docs/scaling/#sidechains) Sidechains A sidechain is an independent EVM-compatible blockchain that runs in parallel to Mainnet. These are compatible with Ethereum via two-way bridges and run under their own chosen rules of consensus and block parameters. Learn more about [Sidechains](https://ethereum.org/developers/docs/scaling/sidechains/) . ### [](https://ethereum.org/developers/docs/scaling/#plasma) Plasma A plasma chain is a separate blockchain that is anchored to the main Ethereum chain and uses fraud proofs (like [optimistic rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) ) to arbitrate disputes. Learn more about [Plasma](https://ethereum.org/developers/docs/scaling/plasma/) . ### [](https://ethereum.org/developers/docs/scaling/#validium) Validium A Validium chain uses validity proofs like zero-knowledge rollups but data is not stored on the main layer 1 Ethereum chain. This can lead to 10k transactions per second per Validium chain and multiple chains can be run in parallel. Learn more about [Validium](https://ethereum.org/developers/docs/scaling/validium/) . [](https://ethereum.org/developers/docs/scaling/#why-do-we-need-these) Why are so many scaling solutions needed? ---------------------------------------------------------------------------------------------------------------- * Multiple solutions can help reduce the overall congestion on any one part of the network and also prevent single points of failure. * The whole is greater than the sum of its parts. Different solutions can exist and work in harmony, allowing for an exponential effect on future transaction speed and throughput. * Not all solutions require utilizing the Ethereum consensus algorithm directly, and alternatives can offer benefits that would otherwise be difficult to obtain. [](https://ethereum.org/developers/docs/scaling/#visual-learner) More of a visual learner? ------------------------------------------------------------------------------------------ ### Ethereum layer 2 scaling explained An overview of layer 2 scaling solutions for Ethereum, including rollups, Plasma, state channels, and sidechains. [Watch with transcript](https://ethereum.org/videos/layer-2-scaling-explained/)   _Note the explanation in the video uses the term "Layer 2" to refer to all offchain scaling solutions, while we differentiate "Layer 2" as an offchain solution that derives its security through layer 1 Mainnet consensus._ ### Rollups: the ultimate Ethereum scaling strategy? A deep dive into rollups as Ethereum's primary scaling strategy. [Watch with transcript](https://ethereum.org/videos/rollups-scaling-strategy/)   [](https://ethereum.org/developers/docs/scaling/#further-reading) Further reading --------------------------------------------------------------------------------- * [A rollup-centric Ethereum roadmap (opens in a new tab)](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _Vitalik Buterin_ * [Up-to-date analytics on Layer 2 scaling solutions for Ethereum (opens in a new tab)](https://www.l2beat.com/) * [Evaluating Ethereum layer 2 Scaling Solutions: A Comparison Framework (opens in a new tab)](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) * [An Incomplete Guide to Rollups (opens in a new tab)](https://vitalik.eth.limo/general/2021/01/05/rollup.html) * [Ethereum-powered ZK-Rollups: World Beaters (opens in a new tab)](https://hackmd.io/@canti/rkUT0BD8K) * [Optimistic Rollups vs ZK Rollups (opens in a new tab)](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/) * [Why rollups + data shards are the only sustainable solution for high scalability (opens in a new tab)](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48) * [What kind of Layer 3s make sense? (opens in a new tab)](https://vitalik.eth.limo/general/2022/09/17/layer_3.html) * [Data Availability Or: How Rollups Learned To Stop Worrying And Love Ethereum (opens in a new tab)](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) * [The Practical Guide to Ethereum Rollups (opens in a new tab)](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) _Know of a community resource that helped you? Edit this page and add it!_ [](https://ethereum.org/developers/docs/scaling/#tutorials) Tutorials: Build scalable Layer 2s on Ethereum ---------------------------------------------------------------------------------------------------------- * [All you can cache](https://ethereum.org/developers/tutorials/all-you-can-cache/) _– How to build and use a caching contract to reduce calldata costs on rollups._ * [Short ABIs for Calldata Optimization](https://ethereum.org/developers/tutorials/short-abi/) _– How to use shorter ABIs to reduce calldata costs for layer 2 transactions._ --- # 데이터 및 분석 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/data-and-analytics/#main-content) Change page 데이터 및 분석 ======== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/data-and-analytics/index.md) 이 페이지의 내용 [](https://ethereum.org/ko/developers/docs/data-and-analytics/#introduction) 소개 ------------------------------------------------------------------------------- 네트워크 활용도가 계속 증가함에 따라, 온체인 데이터에는 점점 더 많은 가치 있는 정보가 존재하게 될 것입니다. 데이터의 양이 급격히 증가함에 따라, 이 정보를 계산하고 집계하여 보고하거나 탈중앙화 애플리케이션 (dapp)을 구동하는 것은 시간과 프로세스가 많이 소요되는 작업이 될 수 있습니다. 기존 데이터 제공업체를 활용하면 개발을 가속화하고, 더 정확한 결과를 생성하며, 지속적인 유지보수 노력을 줄일 수 있습니다. 이를 통해 팀은 프로젝트가 제공하고자 하는 핵심 기능에 집중할 수 있습니다. [](https://ethereum.org/ko/developers/docs/data-and-analytics/#prerequisites) 전제 조건 ----------------------------------------------------------------------------------- 데이터 분석 컨텍스트에서 이를 사용하는 것을 더 잘 이해하려면 [블록 탐색기](https://ethereum.org/ko/developers/docs/data-and-analytics/block-explorers/) 의 기본 개념을 이해해야 합니다. 또한 시스템 설계에 추가되는 이점을 이해하기 위해 의 개념에 익숙해져야 합니다. 아키텍처의 기본 측면에서 [API (새 탭에서 열림)](https://www.wikipedia.org/wiki/API) 와 [REST (새 탭에서 열림)](https://www.wikipedia.org/wiki/Representational_state_transfer) 가 무엇인지 이론적으로라도 이해하는 것이 좋습니다. [](https://ethereum.org/ko/developers/docs/data-and-analytics/#block-explorers) 블록 탐색기 -------------------------------------------------------------------------------------- 많은 [블록 탐색기](https://ethereum.org/ko/developers/docs/data-and-analytics/block-explorers/) 는 개발자에게 블록, 트랜잭션, 검증자, 계정 및 기타 온체인 활동에 대한 실시간 데이터의 가시성을 제공하는 [RESTful (새 탭에서 열림)](https://www.wikipedia.org/wiki/Representational_state_transfer) [API (새 탭에서 열림)](https://www.wikipedia.org/wiki/API) 게이트웨이를 제공합니다. 그런 다음 개발자는 이 데이터를 처리하고 변환하여 사용자에게 과의 고유한 통찰력과 상호 작용을 제공할 수 있습니다. 예를 들어, [Etherscan (새 탭에서 열림)](https://etherscan.io/) 과 [Blockscout (새 탭에서 열림)](https://eth.blockscout.com/) 은 매 12초 슬롯마다 실행 및 합의 데이터를 제공합니다. [](https://ethereum.org/ko/developers/docs/data-and-analytics/#the-graph) The Graph ----------------------------------------------------------------------------------- [The Graph (새 탭에서 열림)](https://thegraph.com/) 는 서브그래프라고 알려진 개방형 API를 통해 블록체인 데이터를 쉽게 쿼리할 수 있는 방법을 제공하는 인덱싱 프로토콜입니다. The Graph를 사용하면 개발자는 다음과 같은 이점을 얻을 수 있습니다. * 탈중앙화된 인덱싱: 여러 인덱서를 통해 블록체인 데이터를 인덱싱할 수 있으므로 단일 장애점을 제거합니다. * GraphQL 쿼리: 인덱싱된 데이터를 쿼리하기 위한 강력한 GraphQL 인터페이스를 제공하여 데이터 검색을 매우 간단하게 만듭니다. * 사용자 정의: 블록체인 데이터를 변환하고 저장하기 위한 자체 로직을 정의하고, The Graph 네트워크에서 다른 개발자가 게시한 서브그래프를 재사용할 수 있습니다. 이 [빠른 시작 (새 탭에서 열림)](https://thegraph.com/docs/en/quick-start/) 가이드를 따라 5분 안에 서브그래프를 생성, 배포 및 쿼리해 보세요. [](https://ethereum.org/ko/developers/docs/data-and-analytics/#client-diversity) 클라이언트 다양성 ------------------------------------------------------------------------------------------ [클라이언트 다양성](https://ethereum.org/ko/developers/docs/nodes-and-clients/client-diversity/) 은 버그와 익스플로잇에 대한 복원력을 제공하기 때문에 이더리움 네트워크의 전반적인 건전성에 중요합니다. 현재 [clientdiversity.org (새 탭에서 열림)](https://clientdiversity.org/) , [rated.network (새 탭에서 열림)](https://www.rated.network/) , [supermajority.info (새 탭에서 열림)](https://supermajority.info//) 및 [Ethernodes (새 탭에서 열림)](https://ethernodes.org/) 를 포함한 여러 클라이언트 다양성 대시보드가 있습니다. [](https://ethereum.org/ko/developers/docs/data-and-analytics/#dune-analytics) Dune Analytics --------------------------------------------------------------------------------------------- [Dune Analytics (새 탭에서 열림)](https://dune.com/) 는 블록체인 데이터를 관계형 데이터베이스(DuneSQL) 테이블로 전처리하여, 사용자가 SQL을 사용하여 블록체인 데이터를 쿼리하고 쿼리 결과를 기반으로 대시보드를 구축할 수 있도록 합니다. 온체인 데이터는 `blocks`, `transactions`, (이벤트) `logs` 및 (호출) `traces`의 4가지 원시 테이블로 구성됩니다. 인기 있는 컨트랙트와 프로토콜은 디코딩되었으며, 각각 고유한 이벤트 및 호출 테이블 세트를 가지고 있습니다. 이러한 이벤트 및 호출 테이블은 추가로 처리되어 dex, 대출, 스테이블코인 등과 같은 프로토콜 유형별로 추상화 테이블로 구성됩니다. [](https://ethereum.org/ko/developers/docs/data-and-analytics/#sqd) SQD ----------------------------------------------------------------------- [SQD (새 탭에서 열림)](https://sqd.dev/) 는 대량의 데이터에 대한 효율적이고 무허가성 접근을 제공하는 데 최적화된 탈중앙화된 초확장성 데이터 플랫폼입니다. 현재 이벤트 로그, 트랜잭션 영수증, 트레이스 및 트랜잭션별 상태 차이를 포함한 과거 온체인 데이터를 제공합니다. SQD는 사용자 정의 데이터 추출 및 처리 파이프라인을 생성하기 위한 강력한 툴킷을 제공하여 초당 최대 15만 개의 블록 인덱싱 속도를 달성합니다. 시작하려면 [문서 (새 탭에서 열림)](https://docs.sqd.dev/) 를 방문하거나 SQD로 구축할 수 있는 [EVM 예제 (새 탭에서 열림)](https://github.com/subsquid-labs/squid-evm-examples) 를 확인하세요. [](https://ethereum.org/ko/developers/docs/data-and-analytics/#subquery-network) SubQuery 네트워크 ---------------------------------------------------------------------------------------------- [SubQuery (새 탭에서 열림)](https://subquery.network/) 는 개발자에게 Web3 프로젝트를 위한 빠르고 안정적이며 탈중앙화된 맞춤형 API를 제공하는 선도적인 데이터 인덱서입니다. SubQuery는 이더리움을 포함한 165개 이상의 생태계의 개발자에게 풍부한 인덱싱된 데이터를 제공하여 사용자를 위한 직관적이고 몰입감 있는 경험을 구축할 수 있도록 지원합니다. SubQuery 네트워크는 탄력적이고 탈중앙화된 인프라 네트워크를 통해 중단 없는 앱을 구동합니다. 데이터 처리 활동을 위한 맞춤형 백엔드를 구축하는 데 시간을 낭비하지 않고 SubQuery의 블록체인 개발자 툴킷을 사용하여 미래의 Web3 애플리케이션을 구축하세요. 시작하려면 [이더리움 빠른 시작 가이드 (새 탭에서 열림)](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) 를 방문하여 [SubQuery의 관리형 서비스 (새 탭에서 열림)](https://managedservice.subquery.network/) 또는 [SubQuery의 탈중앙화된 네트워크 (새 탭에서 열림)](https://app.subquery.network/dashboard) 에서 라이브로 전환하기 전에 테스트를 위해 로컬 Docker 환경에서 몇 분 만에 이더리움 블록체인 데이터 인덱싱을 시작해 보세요. [](https://ethereum.org/ko/developers/docs/data-and-analytics/#codex) Codex --------------------------------------------------------------------------- [Codex (새 탭에서 열림)](https://www.codex.io/) 는 80개 이상의 네트워크에 걸쳐 7천만 개 이상의 토큰에 대한 풍부한 데이터를 제공하는 실시간 블록체인 데이터 API입니다. 개발자는 맞춤형 인덱싱 인프라를 유지 관리하지 않고도 구조화된 토큰 가격 책정, 지갑 잔액, 트랜잭션 내역 및 집계된 분석(거래량, 유동성, 고유 지갑)에 접근할 수 있습니다. Codex는 WebSocket 및 웹훅 통합을 통해 1초 미만의 데이터 전송을 지원합니다. 시작하려면 [문서 (새 탭에서 열림)](https://docs.codex.io/) 를 방문하거나 [탐색기 (새 탭에서 열림)](https://docs.codex.io/explore) 를 사용해 보거나 [대시보드 (새 탭에서 열림)](https://dashboard.codex.io/signup) 에서 가입하세요. Mobula ------ [Mobula (새 탭에서 열림)](https://mobula.io/) 는 90개 이상의 블록체인에 걸쳐 실시간 및 과거 시장 데이터, 토큰 메타데이터, 지갑 포트폴리오 및 온체인 분석을 제공하는 고성능 암호화폐 데이터 API입니다. 개발자는 자체 인프라를 실행하지 않고도 토큰 가격, 시가총액, 거래량, 유동성 데이터 및 다중 체인 지갑 잔액에 대한 REST 및 GraphQL 엔드포인트에 접근할 수 있습니다. Mobula는 프로덕션 애플리케이션을 위해 무료(월 10만 건의 요청) 및 유료 플랜을 모두 제공합니다. 시작하려면 [문서 (새 탭에서 열림)](https://docs.mobula.io/) 를 방문하거나 [API 참조 (새 탭에서 열림)](https://docs.mobula.io/reference/) 를 탐색하거나 [대시보드 (새 탭에서 열림)](https://mobula.io/) 에서 가입하세요. [](https://ethereum.org/ko/developers/docs/data-and-analytics/#evm-query-language) EVM 쿼리 언어 -------------------------------------------------------------------------------------------- EVM 쿼리 언어(EQL)는 EVM(이더리움 가상 머신) 체인을 쿼리하도록 설계된 SQL 유사 언어입니다. EQL의 궁극적인 목표는 EVM 체인의 일급 객체(블록, 계정 및 트랜잭션)에 대한 복잡한 관계형 쿼리를 지원하는 동시에 개발자와 연구원에게 일상적인 사용을 위한 인체공학적 구문을 제공하는 것입니다. EQL을 사용하면 개발자는 친숙한 SQL 유사 구문을 사용하여 블록체인 데이터를 가져올 수 있으며 복잡한 보일러플레이트 코드가 필요하지 않습니다. EQL은 표준 블록체인 데이터 요청(예: 이더리움에서 계정의 논스 및 잔액 검색 또는 현재 블록 크기 및 타임스탬프 가져오기)을 지원하며 더 복잡한 요청 및 기능 세트에 대한 지원을 지속적으로 추가하고 있습니다. Envio ----- [Envio (새 탭에서 열림)](https://envio.dev/) 는 온체인 이벤트를 쿼리 가능한 GraphQL API로 변환하는 인덱싱 프레임워크입니다. 이더리움 및 모든 EVM 호환 체인을 지원합니다. 개발자는 TypeScript, JavaScript 또는 ReScript로 이벤트 핸들러를 작성하여 재구성 지원, 다중 체인 인덱싱, Envio Cloud의 관리형 호스팅 또는 자체 호스팅과 함께 실시간 및 과거 데이터를 제공할 수 있습니다. 시작하려면 [HyperIndex 빠른 시작 (새 탭에서 열림)](https://docs.envio.dev/docs/HyperIndex/quickstart) 을 따라 인덱서를 생성, 배포 및 쿼리해 보세요. [](https://ethereum.org/ko/developers/docs/data-and-analytics/#further-reading) 더 읽을거리 -------------------------------------------------------------------------------------- * [암호화폐 데이터 탐색 I: 데이터 흐름 아키텍처 (새 탭에서 열림)](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) * [Graph 네트워크 개요 (새 탭에서 열림)](https://thegraph.com/docs/en/about/) * [Graph 쿼리 플레이그라운드 (새 탭에서 열림)](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) * [Etherscan의 API 코드 예제 (새 탭에서 열림)](https://etherscan.io/apis#contracts) * [Blockscout의 API 문서 (새 탭에서 열림)](https://docs.blockscout.com/devs/apis) * [Beaconcha.in 비콘 체인 탐색기 (새 탭에서 열림)](https://beaconcha.in/) * [Dune 기초 (새 탭에서 열림)](https://docs.dune.com/#dune-basics) * [SubQuery 이더리움 빠른 시작 가이드 (새 탭에서 열림)](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) * [SQD 네트워크 개요 (새 탭에서 열림)](https://docs.sqd.dev/) * [EVM 쿼리 언어 (새 탭에서 열림)](https://web.archive.org/web/20250719151453/https://www.eql.sh/blog/alpha-release-notes) [](https://ethereum.org/ko/developers/docs/data-and-analytics/#tutorials) 튜토리얼: 데이터 및 분석 / 이더리움의 SQL ---------------------------------------------------------------------------------------------------- * [SQL로 이더리움 기초 주제 배우기](https://ethereum.org/ko/developers/tutorials/learn-foundational-ethereum-topics-with-sql/) _– SQL로 온체인 이더리움 데이터를 쿼리하여 트랜잭션, 블록 및 가스 기초를 이해합니다._ --- # Ethereum Development Standards | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/standards/#main-content) Change page Ethereum Development Standards ============================== Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/index.md) On this page [](https://ethereum.org/developers/docs/standards/#standards-overview) Standards overview ----------------------------------------------------------------------------------------- The Ethereum community has adopted many standards that help keep projects (such as [Ethereum clients](https://ethereum.org/developers/docs/nodes-and-clients/) and wallets) interoperable across implementations, and ensure smart contracts and dapps remain composable. Typically standards are introduced as [Ethereum Improvement Proposals](https://ethereum.org/eips/) (EIPs), which are discussed by community members through a [standard process (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-1) . * [Introduction to EIPs](https://ethereum.org/eips/) * [List of EIPs (opens in a new tab)](https://eips.ethereum.org/) * [EIP GitHub repo (opens in a new tab)](https://github.com/ethereum/EIPs) * [EIP discussion board (opens in a new tab)](https://ethereum-magicians.org/c/eips) * [Introduction to Ethereum Governance](https://ethereum.org/governance/) * [Ethereum Governance Overview (opens in a new tab)](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _March 31, 2019 - Boris Mann_ * [Ethereum Protocol Development Governance and Network Upgrade Coordination (opens in a new tab)](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _March 23, 2020 - Hudson Jameson_ * [Playlist of all Ethereum Core Dev Meetings (opens in a new tab)](https://www.youtube.com/@EthereumProtocol) _(YouTube Playlist)_ [](https://ethereum.org/developers/docs/standards/#types-of-standards) Types of standards ----------------------------------------------------------------------------------------- There are 3 types of EIPs: * Standards Track: describes any change that affects most or all Ethereum implementations * [Meta Track (opens in a new tab)](https://eips.ethereum.org/meta) : describes a process surrounding Ethereum or proposes a change to a process * [Informational Track (opens in a new tab)](https://eips.ethereum.org/informational) : describes an Ethereum design issue or provides general guidelines or information to the Ethereum community Furthermore, the Standard Track is subdivided into 4 categories: * [Core (opens in a new tab)](https://eips.ethereum.org/core) : improvements requiring a consensus fork * [Networking (opens in a new tab)](https://eips.ethereum.org/networking) : improvements around devp2p and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm. * [Interface (opens in a new tab)](https://eips.ethereum.org/interface) : improvements around client API/RPC specifications and standards, and certain language-level standards like method names and contract ABIs. * [ERC (opens in a new tab)](https://eips.ethereum.org/erc) : application-level standards and conventions More detailed information on these different types and categories can be found in [EIP-1 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-1#eip-types) ### [](https://ethereum.org/developers/docs/standards/#token-standards) Token standards * [ERC-20](https://ethereum.org/developers/docs/standards/tokens/erc-20/) - A standard interface for fungible (interchangeable) tokens, like voting tokens, staking tokens or virtual currencies. * [ERC-223](https://ethereum.org/developers/docs/standards/tokens/erc-223/) - A fungible tokens standard that makes tokens behave identical to ether and supports token transfers handling on the recipients side. * [ERC-1363](https://ethereum.org/developers/docs/standards/tokens/erc-1363/) - An extension interface for ERC-20 tokens that supports executing callback on recipient contracts in a single transaction. * [ERC-721](https://ethereum.org/developers/docs/standards/tokens/erc-721/) - A standard interface for non-fungible tokens, like a deed for artwork or a song. * [ERC-2309 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-2309) - A standardized event emitted when creating/transferring one, or many non-fungible tokens using consecutive token identifiers. * [ERC-4400 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-4400) - Interface extension for EIP-721 consumer role. * [ERC-4907 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-4907) - Add a time-limited role with restricted permissions to ERC-721 tokens. * [ERC-777](https://ethereum.org/developers/docs/standards/tokens/erc-777/) - **(NOT RECOMMENDED)** A token standard improving over ERC-20. * [ERC-1155](https://ethereum.org/developers/docs/standards/tokens/erc-1155/) - A token standard which can contain both fungible and non-fungible assets. * [ERC-4626](https://ethereum.org/developers/docs/standards/tokens/erc-4626/) - A tokenized vault standard designed to optimize and unify the technical parameters of yield-bearing vaults. Learn more about [token standards](https://ethereum.org/developers/docs/standards/tokens/) . [](https://ethereum.org/developers/docs/standards/#further-reading) Further reading ----------------------------------------------------------------------------------- * [Ethereum Improvement Proposals (EIPs)](https://ethereum.org/eips/) _Know of a community resource that helped you? Edit this page and add it!_ --- # Plasma chains | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/scaling/plasma/#main-content) Change page Plasma chains ============= Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/scaling/plasma/index.md) On this page A Plasma chain is a separate blockchain anchored to [Ethereum](https://ethereum.org/) Mainnet but executing transactions offchain with its own mechanism for block validation. Plasma chains are sometimes referred to as "child" chains, essentially smaller copies of the Ethereum Mainnet. Plasma chains use (like [optimistic rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) ) to arbitrate disputes. Merkle trees enable the creation of an endless stack of these chains that can work to offload bandwidth from parent chains (including Ethereum Mainnet). However, while these chains derive some security from Ethereum (via fraud proofs), their security and efficiency are affected by several design limitations. [](https://ethereum.org/developers/docs/scaling/plasma/#prerequisites) Prerequisites ------------------------------------------------------------------------------------ You should have a good understanding of all the foundational topics and a high-level understanding of [Ethereum scaling](https://ethereum.org/developers/docs/scaling/) . [](https://ethereum.org/developers/docs/scaling/plasma/#what-is-plasma) What is Plasma? --------------------------------------------------------------------------------------- Plasma is a framework for improving scalability in public blockchains like Ethereum. As described in the original [Plasma whitepaper (opens in a new tab)](https://plasma.io/plasma.pdf) , Plasma chains are built atop another blockchain (called a "root chain"). Each "child chain" extends from the root chain and is generally managed by a smart contract deployed on the parent chain. The Plasma contract functions, among other things, as a [bridge](https://ethereum.org/developers/docs/bridges/) allowing users to move assets between Ethereum Mainnet and the plasma chain. Although this makes them similar to [sidechains](https://ethereum.org/developers/docs/scaling/sidechains/) , plasma chains benefit—at least, to some extent—from Ethereum Mainnet's security. This is unlike sidechains that are solely responsible for their security. [](https://ethereum.org/developers/docs/scaling/plasma/#how-does-plasma-work) How does Plasma work? --------------------------------------------------------------------------------------------------- The basic components of the Plasma framework are: ### [](https://ethereum.org/developers/docs/scaling/plasma/#offchain-computation) Offchain computation Ethereum's current processing speed is limited to ~ 15-20 transactions per second, reducing the short-term possibility of scaling to handle more users. This problem exists mainly because Ethereum's [consensus mechanism](https://ethereum.org/developers/docs/consensus-mechanisms/) requires many peer-to-peer nodes to verify every update to the blockchain's state. Although Ethereum's consensus mechanism is necessary for security, it may not apply to every use case. For example, Alice may not need her daily payments to Bob for a cup of coffee verified by the entire Ethereum network since some trust exists between both parties. Plasma supposes that Ethereum Mainnet doesn't need to verify all transactions. Instead, we can process transactions off Mainnet, freeing nodes from having to validate every transaction. Offchain computation is necessary since Plasma chains can optimize for speed and cost. For example, a Plasma chain may—and most often does—use a single "operator" to manage the ordering and execution of transactions. With just one entity verifying transactions, processing times on a plasma chain are faster than Ethereum Mainnet. ### [](https://ethereum.org/developers/docs/scaling/plasma/#state-commitments) State commitments While Plasma executes transactions offchain, they are settled on the main Ethereum execution layer—otherwise, Plasma chains cannot benefit from Ethereum's security guarantees. But finalizing offchain transactions without knowing the state of the plasma chain would break the security model and allow the proliferation of invalid transactions. This is why the operator, the entity responsible for producing blocks on the plasma chain, is required to publish "state commitments" on Ethereum periodically. A [commitment scheme (opens in a new tab)](https://en.wikipedia.org/wiki/Commitment_scheme) is a cryptographic technique for committing to a value or statement without revealing it to another party. Commitments are "binding" in the sense that you cannot change the value or statement once you've committed to it. State commitments in Plasma take the form of "Merkle roots" (derived from a [Merkle tree](https://ethereum.org/whitepaper/#merkle-trees) ) which the operator sends at intervals to the Plasma contract on the Ethereum chain. Merkle roots are cryptographic primitives that enable compressing of large amounts of information. A Merkle root (also called a "block root" in this case) could represent all the transactions in a block. Merkle roots also make it easier to verify that a small piece of data is part of the larger dataset. For instance, a user can produce a [Merkle proof](https://ethereum.org/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content) to prove the inclusion of a transaction in a specific block. Merkle roots are important for providing information about the offchain's state to Ethereum. You can think of Merkle roots as "save points": the operator is saying, "This is the state of the Plasma chain at x point in time, and this is the Merkle root as proof." The operator is committing to the _current state_ of the plasma chain with a Merkle root, which is why it is called a "state commitment". ### [](https://ethereum.org/developers/docs/scaling/plasma/#entries-and-exits) Entries and exits For Ethereum users to take advantage of Plasma, there needs to be a mechanism for moving funds between Mainnet and plasma chains. We cannot arbitrarily send ether to an address on the plasma chain, though—these chains are incompatible, so the transaction would either fail or lead to lost funds. Plasma uses a master contract running on Ethereum to process user entries and exits. This master contract is also responsible for tracking state commitments (explained earlier) and punishing dishonest behavior via fraud proofs (more on this later). #### [](https://ethereum.org/developers/docs/scaling/plasma/#entering-the-plasma-chain) Entering the plasma chain To enter the plasma chain, Alice (the user) will have to deposit ETH or any ERC-20 token in the plasma contract. The plasma operator, who watches contract deposits, recreates an amount equal to Alice's initial deposit and releases it to her address on the plasma chain. Alice is required to attest to receiving the funds on the child chain and can then use these funds for transactions. #### [](https://ethereum.org/developers/docs/scaling/plasma/#exiting-the-plasma-chain) Exiting the plasma chain Exiting the plasma chain is more complex than entering it for several reasons. The biggest one is that, while Ethereum has information about the plasma chain's state, it cannot verify if the information is true or not. A malicious user could make an incorrect assertion ("I have 1000 ETH") and get away with providing fake proofs to back up the claim. To prevent malicious withdrawals, a "challenge period" is introduced. During the challenge period (usually a week), anyone can challenge a withdrawal request using a fraud-proof. If the challenge succeeds, then the withdrawal request is denied. However, it is usually the case that users are honest and make correct claims about the funds they own. In this scenario, Alice will initiate a withdrawal request on the root chain (Ethereum) by submitting a transaction to the plasma contract. She must also provide a Merkle proof verifying that a transaction creating her funds on the Plasma chain was included in a block. This is necessary for iterations of Plasma, such as Plasma MVP, that use a [Unspent Transaction Output (UTXO) (opens in a new tab)](https://en.wikipedia.org/wiki/Unspent_transaction_output) model. Others, like Plasma Cash, represent funds as [non-fungible tokens](https://ethereum.org/developers/docs/standards/tokens/erc-721/) instead of UTXOs. Withdrawing, in this case, requires proof of ownership of tokens on the Plasma chain. This is done by submitting the two latest transactions involving the token and providing a Merkle proof verifying the inclusion of those transactions in a block. The user must also add a bond to the withdrawal request as a guarantee of honest behavior. If a challenger proves Alice's withdrawal request invalid, her bond is slashed, and some of it goes to the challenger as a reward. If the challenge period elapses without anyone providing a fraud-proof, Alice's withdrawal request is considered valid, allowing her to retrieve deposits from the Plasma contract on Ethereum. ### [](https://ethereum.org/developers/docs/scaling/plasma/#dispute-arbitration) Dispute arbitration Like any blockchain, plasma chains need a mechanism for enforcing the integrity of transactions in case participants act maliciously (e.g., double-spending funds). To this end, plasma chains use fraud proofs to arbitrate disputes concerning the validity of state transitions and penalize bad behavior. Fraud proofs are used as a mechanism through which a Plasma child chain files a complaint to its parent chain or to the root chain. A fraud-proof is simply a claim that a particular state transition is invalid. An example is if a user (Alice) tries to spend the same funds twice. Perhaps she spent the UTXO in a transaction with Bob and wants to spend the same UTXO (which is now Bob's) in another transaction. To prevent the withdrawal, Bob will construct a fraud-proof by providing evidence of Alice spending the said UTXO in a previous transaction and a Merkle proof of the transaction's inclusion in a block. The same process works in Plasma Cash—Bob would need to provide proof that Alice earlier transferred the tokens she's trying to withdraw. If Bob's challenge succeeds, Alice's withdrawal request is canceled. However, this approach relies on Bob's ability to watch the chain for withdrawal requests. If Bob is offline, then Alice can process the malicious withdrawal once the challenge period elapses. [](https://ethereum.org/developers/docs/scaling/plasma/#the-mass-exit-problem-in-plasma) The mass exit problem in plasma ------------------------------------------------------------------------------------------------------------------------ The mass exit problem occurs when a large number of users try to withdraw from a plasma chain at the same time. Why this problem exists has to do with one of Plasma's biggest problems: **data unavailability**. Data availability is the ability to verify that the information for a proposed block was actually published on the blockchain network. A block is "unavailable" if the producer publishes the block itself but withholds data used to create the block. Blocks must be available if nodes are to be able to download the block and verify the validity of transactions. Blockchains ensure data availability by forcing block producers to post all transaction data onchain. Data availability also helps with securing offchain scaling protocols that build on Ethereum's base layer. By forcing operators on these chains to publish transaction data on Ethereum, anyone can challenge invalid blocks by constructing fraud proofs referencing the correct state of the chain. Plasma chains primarily store transaction data with the operator and **do not publish any data on Mainnet** (i.e., besides periodic state commitments). This means users must rely on the operator to provide block data if they need to create fraud proofs challenging invalid transactions. If this system works, then users can always use fraud proofs to secure funds. The problem starts when the operator, not just any user, is the party acting maliciously. Because the operator is in sole control of the blockchain, they have more incentive to advance invalid state transitions on a larger scale, such as stealing funds belonging to users on the plasma chain. In this case, using the classic fraud-proof system does not work. The operator could easily make an invalid transaction transferring Alice and Bob's funds to their wallet and hide the data necessary for creating the fraud-proof. This is possible because the operator isn't required to make data available to users or Mainnet. Therefore, the most optimistic solution is to attempt a "mass exit" of users from the plasma chain. The mass exit slows down the malicious operator's plan to steal funds and provides some measure of protection for users. Withdrawal requests are ordered based on when each UTXO (or token) was created, preventing malicious operators from front-running honest users. Nonetheless, we still need a way to verify the validity of withdrawal requests during a mass exit—to prevent opportunistic individuals from cashing in on the chaos processing invalid exits. The solution is simple: require users to post the last **valid state of the chain** to exit their money. But this approach still has problems. For instance, if all users on a plasma chain need to exit (which is possible in the case of a malicious operator), then the entire valid state of the plasma chain must be dumped on Ethereum's base layer at once. With the arbitrary size of plasma chains (high throughput = more data) and constraints on Ethereum's processing speeds, this is not an ideal solution. Although exit games sound nice in theory, real-life mass exits will likely trigger network-wide congestion on Ethereum itself. Besides harming Ethereum's functionality, a poorly coordinated mass exit means that users may be unable to withdraw funds before the operator drains every account on the plasma chain. [](https://ethereum.org/developers/docs/scaling/plasma/#pros-and-cons-of-plasma) Pros and cons of plasma -------------------------------------------------------------------------------------------------------- | 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. | | 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 offchain. | 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. | | | If too many users try to exit simultaneously, Ethereum Mainnet could get congested. | [](https://ethereum.org/developers/docs/scaling/plasma/#plasma-vs-layer-2) Plasma vs layer 2 scaling protocols -------------------------------------------------------------------------------------------------------------- While Plasma was once considered a useful scaling solution for Ethereum, it has since been dropped in favor of [layer 2 (L2) scaling protocols](https://ethereum.org/layer-2/) . L2 scaling solutions remedy several of Plasma's problems: ### [](https://ethereum.org/developers/docs/scaling/plasma/#efficiency) Efficiency [Zero-Knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) generate cryptographic proofs of the validity of each batch of transactions processed offchain. This prevents the users (and operators) from advancing invalid state transitions, eliminating the need for challenge periods and exit games. It also means users don't have to watch the chain periodically to secure their funds. ### [](https://ethereum.org/developers/docs/scaling/plasma/#support-for-smart-contracts) Support for smart contracts Another problem with the plasma framework was [the inability to support the execution of Ethereum smart contracts (opens in a new tab)](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4) . As a result, most implementations of Plasma were mostly built for simple payments or the exchange of ERC-20 tokens. Conversely, optimistic rollups, are compatible with the [Ethereum Virtual Machine](https://ethereum.org/developers/docs/evm/) and can run Ethereum-native [smart contracts](https://ethereum.org/developers/docs/smart-contracts/) , making them a useful and _secure_ solution for scaling [decentralized applications](https://ethereum.org/developers/docs/dapps/) . Similarly, plans are underway to [create a zero-knowledge implementation of the EVM (zkEVM) (opens in a new tab)](https://ethresear.ch/t/a-zk-evm-specification/11549) that would allow ZK-rollups to process arbitrary logic and execute smart contracts. ### [](https://ethereum.org/developers/docs/scaling/plasma/#data-unavailability) Data unavailability As explained earlier, plasma suffers from a data availability problem. If a malicious operator advanced an invalid transition on the plasma chain, users would be unable to challenge it since the operator can withhold data needed to create the fraud-proof. Rollups solve this problem by forcing operators to post transaction data on Ethereum, allowing anyone to verify the chain's state and create fraud proofs if necessary. ### [](https://ethereum.org/developers/docs/scaling/plasma/#mass-exit-problem) Mass exit problem ZK-rollups and optimistic rollups both solve Plasma's mass exit problem in various ways. For example, a ZK-rollup relies on cryptographic mechanisms that ensure operators cannot steal user funds under any scenario. Similarly, optimistic rollups impose a delay period on withdrawals during which anyone can initiate a challenge and prevent malicious withdrawal requests. While this is similar to Plasma, the difference is that verifiers have access to data needed to create fraud proofs. Thus, there's no need for rollup users to engage in a frenzied, "first-to-get-out" migration to Ethereum Mainnet. [](https://ethereum.org/developers/docs/scaling/plasma/#plasma-sidechains-sharding) How does Plasma differ from sidechains and sharding? ---------------------------------------------------------------------------------------------------------------------------------------- Plasma, sidechains, and sharding are fairly similar because they all connect to Ethereum Mainnet in some way. However, the level and strength of these connections vary, which affects the security properties of each scaling solution. ### [](https://ethereum.org/developers/docs/scaling/plasma/#plasma-vs-sidechains) Plasma vs sidechains A [sidechain](https://ethereum.org/developers/docs/scaling/sidechains/) is an independently operated blockchain connected to Ethereum Mainnet via a two-way bridge. [Bridges](https://ethereum.org/bridges/) allow users to exchange tokens between the two blockchains to transact on the sidechain, reducing congestion on Ethereum Mainnet and improving scalability. Sidechains use a separate consensus mechanism and are typically much smaller than Ethereum Mainnet. As a result, bridging assets to these chains involves increased risk; given the lack of security guarantees inherited from Ethereum Mainnet in the sidechain model, users risk the loss of funds in an attack on the sidechain. Conversely, plasma chains derive their security from Mainnet. This makes them measurably more secure than sidechains. Both sidechains and plasma chains can have different consensus protocols, but the difference is that plasma chains publish Merkle roots for each block on Ethereum Mainnet. Block roots are small pieces of information we can use to verify information about transactions that happen on a plasma chain. If an attack happens on a plasma chain, users can safely withdraw their funds back to Mainnet using the appropriate proofs. ### [](https://ethereum.org/developers/docs/scaling/plasma/#plasma-vs-sharding) Plasma vs sharding Both plasma chains and shard chains periodically publish cryptographic proofs to Ethereum Mainnet. However, both have different security properties. Shard chains commit "collation headers" to Mainnet containing detailed information about each data shard. Nodes on Mainnet verify and enforce the validity of data shards, reducing the possibility of invalid shard transitions and protecting the network against malicious activity. Plasma is different because Mainnet only receives minimal information about the state of child chains. This means Mainnet cannot effectively verify transactions conducted on child chains, making them less secure. **Note** that sharding the Ethereum blockchain is no longer on the roadmap. It has been superseded by scaling via rollups and [Danksharding](https://ethereum.org/roadmap/danksharding/) . ### [](https://ethereum.org/developers/docs/scaling/plasma/#use-plasma) Use Plasma Multiple projects provide implementations of Plasma that you can integrate into your dapps: * [Polygon (opens in a new tab)](https://polygon.technology/) (previously Matic Network) [](https://ethereum.org/developers/docs/scaling/plasma/#further-reading) Further reading ---------------------------------------------------------------------------------------- * [A quick reminder of what "shared security" means and why it's so important (opens in a new tab)](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/) * [Sidechains vs Plasma vs Sharding (opens in a new tab)](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html) * [Understanding Plasma, Part 1: The Basics (opens in a new tab)](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics) * [The Life and Death of Plasma (opens in a new tab)](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#) _Know of a community resource that helped you? Edit this page and add it!_ [](https://ethereum.org/developers/docs/scaling/plasma/#tutorials) Tutorials: Plasma chains on Ethereum ------------------------------------------------------------------------------------------------------- * [Write an app-specific plasma that preserves privacy](https://ethereum.org/developers/tutorials/app-plasma/) _– Build a privacy-preserving plasma application using zero-knowledge proofs and offchain components._ --- # Maximal extractable value (MEV) | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/mev/#main-content) Change page Maximal extractable value (MEV) =============================== Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/mev/index.md) On this page Maximal extractable value (MEV) refers to the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block. [](https://ethereum.org/developers/docs/mev/#maximal-extractable-value) Maximal extractable value ------------------------------------------------------------------------------------------------- Maximal extractable value was first applied in the context of [proof-of-work](https://ethereum.org/developers/docs/consensus-mechanisms/pow/) , and initially referred to as "miner extractable value". This is because in proof-of-work, miners control transaction inclusion, exclusion, and ordering. However, since the transition to proof-of-stake via [The Merge](https://ethereum.org/roadmap/merge/) validators have been responsible for these roles, and mining is no longer part of the [Ethereum](https://ethereum.org/) protocol. The value extraction methods still exist, though, so the term "Maximal extractable value" is now used instead. [](https://ethereum.org/developers/docs/mev/#prerequisites) Prerequisites ------------------------------------------------------------------------- Make sure you're familiar with [transactions](https://ethereum.org/developers/docs/transactions/) , [blocks](https://ethereum.org/developers/docs/blocks/) , [proof-of-stake](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) and [gas](https://ethereum.org/developers/docs/gas/) . Familiarity with [dapps](https://ethereum.org/apps/) and [DeFi](https://ethereum.org/defi/) is helpful as well. [](https://ethereum.org/developers/docs/mev/#mev-extraction) MEV extraction --------------------------------------------------------------------------- In theory MEV accrues entirely to validators because they are the only party that can guarantee the execution of a profitable MEV opportunity. In practice, however, a large portion of MEV is extracted by independent network participants referred to as "searchers." Searchers run complex algorithms on blockchain data to detect profitable MEV opportunities and have bots to automatically submit those profitable transactions to the network. Validators do get a portion of the full MEV amount anyway because searchers are willing to pay high gas fees (which go to the validator) in exchange for higher likelihood of inclusion of their profitable transactions in a block. Assuming searchers are economically rational, the gas fee that a searcher is willing to pay will be an amount up to 100% of the searcher's MEV (because if the gas fee was higher, the searcher would lose money). With that, for some highly competitive MEV opportunities, such as [DEX arbitrage](https://ethereum.org/developers/docs/mev/#mev-examples-dex-arbitrage) , searchers may have to pay 90% or even more of their total MEV revenue in gas fees to the validator because so many people want to run the same profitable arbitrage trade. This is because the only way to guarantee that their arbitrage transaction runs is if they submit the transaction with the highest gas price. ### [](https://ethereum.org/developers/docs/mev/#mev-extraction-gas-golfing) Gas golfing This dynamic has made being good at "gas golfing" — programming transactions so that they use the least amount of gas — a competitive advantage, because it allows searchers to set a higher gas price while keeping their total gas fees constant (since gas fees = gas price \* gas used). A few well-known gas golf techniques include: using addresses that start with a long string of zeroes (e.g., [0x0000000000C521824EaFf97Eac7B73B084ef9306 (opens in a new tab)](https://eth.blockscout.com/address/0x0000000000C521824EaFf97Eac7B73B084ef9306) ) since they take less space (and hence gas) to store; and leaving small [ERC-20](https://ethereum.org/developers/docs/standards/tokens/erc-20/) token balances in contracts, since it costs more gas to initialize a storage slot (the case if the balance is 0) than to update a storage slot. Finding more techniques to reduce gas usage is an active area of research among searchers. ### [](https://ethereum.org/developers/docs/mev/#mev-extraction-generalized-frontrunners) Generalized frontrunners Rather than programming complex algorithms to detect profitable MEV opportunities, some searchers run generalized frontrunners. Generalized frontrunners are bots that watch the mempool to detect profitable transactions. The frontrunner will copy the potentially profitable transaction's code, replace addresses with the frontrunner's address, and run the transaction locally to double-check that the modified transaction results in a profit to the frontrunner's address. If the transaction is indeed profitable, the frontrunner will submit the modified transaction with the replaced address and a higher gas price, "frontrunning" the original transaction and getting the original searcher's MEV. ### [](https://ethereum.org/developers/docs/mev/#mev-extraction-flashbots) Flashbots Flashbots is an independent project which extends execution clients with a service that allows searchers to submit MEV transactions to validators without revealing them to the public mempool. This prevents transactions from being frontrun by generalized frontrunners. [](https://ethereum.org/developers/docs/mev/#mev-examples) MEV examples ----------------------------------------------------------------------- MEV emerges on the blockchain in a few ways. ### [](https://ethereum.org/developers/docs/mev/#mev-examples-dex-arbitrage) DEX arbitrage (DEX) arbitrage is the simplest and most well-known MEV opportunity. As a result, it is also the most competitive. It works like this: if two DEXes are offering a token at two different prices, someone can buy the token on the lower-priced DEX and sell it on the higher-priced DEX in a single, atomic transaction. Thanks to the mechanics of the blockchain, this is true, riskless arbitrage. [Here's an example (opens in a new tab)](https://eth.blockscout.com/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4) of a profitable arbitrage transaction where a searcher turned 1,000 ETH into 1,045 ETH by taking advantage of different pricing of the ETH/DAI pair on Uniswap vs. Sushiswap. ### [](https://ethereum.org/developers/docs/mev/#mev-examples-liquidations) Liquidations Lending protocol liquidations present another well-known MEV opportunity. Lending protocols like Maker and Aave require users to deposit some collateral (e.g., ETH). This deposited collateral is then used to lend out to other users. Users can then borrow assets and tokens from others depending on what they need (e.g., you might borrow MKR if you want to vote in a MakerDAO governance proposal) up to a certain percentage of their deposited collateral. For example, if the borrowing amount is a maximum of 30%, a user who deposits 100 DAI into the protocol can borrow up to 30 DAI worth of another asset. The protocol determines the exact borrowing power percentage. As the value of a borrower's collateral fluctuates, so too does their borrowing power. If, due to market fluctuations, the value of borrowed assets exceeds say, 30% of the value of their collateral (again, the exact percentage is determined by the protocol), the protocol typically allows anyone to liquidate the collateral, instantly paying off the lenders (this is similar to how [margin calls (opens in a new tab)](https://www.investopedia.com/terms/m/margincall.asp) work in traditional finance). If liquidated, the borrower usually has to pay a hefty liquidation fee, some of which goes to the liquidator — which is where the MEV opportunity comes in. Searchers compete to parse blockchain data as fast as possible to determine which borrowers can be liquidated and be the first to submit a liquidation transaction and collect the liquidation fee for themselves. ### [](https://ethereum.org/developers/docs/mev/#mev-examples-sandwich-trading) Sandwich trading Sandwich trading is another common method of MEV extraction. To sandwich, a searcher will watch the mempool for large DEX trades. For instance, suppose someone wants to buy 10,000 UNI with DAI on Uniswap. A trade of this magnitude will have a meaningful effect on the UNI/DAI pair, potentially significantly raising the price of UNI relative to DAI. A searcher can calculate the approximate price effect of this large trade on the UNI/DAI pair and execute an optimal buy order immediately _before_ the large trade, buying UNI cheaply, then execute a sell order immediately _after_ the large trade, selling it for the higher price caused by the large order. Sandwiching, however, is riskier as it isn't atomic (unlike DEX arbitrage, as described above) and is prone to a [salmonella attack (opens in a new tab)](https://github.com/Defi-Cartel/salmonella) . ### [](https://ethereum.org/developers/docs/mev/#mev-examples-nfts) NFT MEV MEV in the NFT space is an emergent phenomenon, and isn't necessarily profitable. However, since NFT transactions happen on the same blockchain shared by all other Ethereum transactions, searchers can use similar techniques as those used in traditional MEV opportunities in the NFT market too. For example, if there's a popular NFT drop and a searcher wants a certain NFT or set of NFTs, they can program a transaction such that they are the first in line to buy the NFT, or they can buy the entire set of NFTs in a single transaction. Or if an NFT is [mistakenly listed at a low price (opens in a new tab)](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent) , a searcher can frontrun other purchasers and snap it up for cheap. One prominent example of NFT MEV occurred when a searcher spent $7 million to [buy (opens in a new tab)](https://eth.blockscout.com/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5?tab=txs) every single Cryptopunk at the price floor. A blockchain researcher [explained on Twitter (opens in a new tab)](https://twitter.com/IvanBogatyy/status/1422232184493121538) how the buyer worked with an MEV provider to keep their purchase secret. ### [](https://ethereum.org/developers/docs/mev/#mev-examples-long-tail) The long tail DEX arbitrage, liquidations, and sandwich trading are all very well-known MEV opportunities and are unlikely to be profitable for new searchers. However, there is a long tail of lesser known MEV opportunities (NFT MEV is arguably one such opportunity). Searchers who are just getting started may be able to find more success by searching for MEV in this longer tail. Flashbot's [MEV job board (opens in a new tab)](https://github.com/flashbots/mev-job-board) lists some emerging opportunities. [](https://ethereum.org/developers/docs/mev/#effects-of-mev) Effects of MEV --------------------------------------------------------------------------- MEV is not all bad — there are both positive and negative consequences to MEV on Ethereum. ### [](https://ethereum.org/developers/docs/mev/#effects-of-mev-the-good) The good Many DeFi projects rely on economically rational actors to ensure the usefulness and stability of their protocols. For instance, DEX arbitrage ensures that users get the best, most correct prices for their tokens, and lending protocols rely on speedy liquidations when borrowers fall below collateralization ratios to ensure lenders get paid back. Without rational searchers seeking and fixing economic inefficiencies and taking advantage of protocols' economic incentives, DeFi protocols and dapps in general may not be as robust as they are today. ### [](https://ethereum.org/developers/docs/mev/#effects-of-mev-the-bad) The bad At the application layer, some forms of MEV, like sandwich trading, result in an unequivocally worse experience for users. Users who are sandwiched face increased slippage and worse execution on their trades. At the network layer, generalized frontrunners and the gas-price auctions they often engage in (when two or more frontrunners compete for their transaction to be included in the next block by progressively raising their own transactions' gas price) result in network congestion and high gas prices for everyone else trying to run regular transactions. Beyond what's happening _within_ blocks, MEV can have deleterious effects _between_ blocks. If the MEV available in a block significantly exceeds the standard block reward, validators may be incentivized to reorg blocks and capture the MEV for themselves, causing blockchain re-organization and consensus instability. This possibility of blockchain re-organization has been [previously explored on the Bitcoin blockchain (opens in a new tab)](https://dl.acm.org/doi/10.1145/2976749.2978408) . As Bitcoin's block reward halves and transaction fees make up a greater and greater portion of the block reward, situations arise where it becomes economically rational for miners to give up the next block's reward and instead remine past blocks with higher fees. With the growth of MEV, the same sort of situation could occur in Ethereum, threatening the integrity of the blockchain. [](https://ethereum.org/developers/docs/mev/#state-of-mev) State of MEV ----------------------------------------------------------------------- MEV extraction ballooned in early 2021, resulting in extremely high gas prices in the first few months of the year. The emergence of Flashbots's MEV relay has reduced the effectiveness of generalized frontrunners and has taken gas price auctions offchain, lowering gas prices for ordinary users. While many searchers are still making good money from MEV, as opportunities become more well-known and more and more searchers compete for the same opportunity, validators will capture more and more total MEV revenue (because the same sort of gas auctions as originally described above also occur in Flashbots, albeit privately, and validators will capture the resulting gas revenue). MEV is also not unique to Ethereum, and as opportunities become more competitive on Ethereum, searchers are moving to alternate blockchains like Binance Smart Chain, where similar MEV opportunities as those on Ethereum exist with less competition. On the other hand, the transition from proof-of-work to proof-of-stake and the ongoing effort to scale Ethereum using rollups all change the MEV landscape in ways that are still somewhat unclear. It is not yet well known how having guaranteed block-proposers known slightly in advance changes the dynamics of MEV extraction compared to the probabilistic model in proof-of-work or how this will be disrupted when [single secret leader election (opens in a new tab)](https://ethresear.ch/t/secret-non-single-leader-election/11789) and [distributed validator technology](https://ethereum.org/staking/dvt/) get implemented. Similarly, it remains to be seen what MEV opportunities exist when most user activity is ported away from Ethereum and onto its layer 2 rollups and shards. [](https://ethereum.org/developers/docs/mev/#mev-in-ethereum-proof-of-stake) MEV in Ethereum Proof-of-Stake (PoS) ----------------------------------------------------------------------------------------------------------------- As explained, MEV has negative implications for overall user experience and consensus-layer security. But Ethereum’s transition to a proof-of-stake consensus (dubbed “The Merge”) potentially introduces new MEV-related risks: ### [](https://ethereum.org/developers/docs/mev/#validator-centralization) Validator centralization In post-Merge Ethereum, validators (having made security deposits of 32 ETH) come to consensus on the validity of blocks added to the Beacon Chain. Since 32 ETH may be out of the reach of many, [joining a staking pool](https://ethereum.org/staking/pools/) may be a more feasible option. Nevertheless, a healthy distribution of [solo stakers](https://ethereum.org/staking/solo/) is ideal, as it mitigates the centralization of validators and improves Ethereum’s security. However, MEV extraction is believed to be capable of accelerating validator centralization. This is partly because, as validators [earn less for proposing blocks](https://ethereum.org/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply) than miners previously did, MEV extraction has greatly [influenced validator earnings (opens in a new tab)](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb) since [The Merge](https://ethereum.org/roadmap/merge/) . Larger staking pools will likely have more resources to invest in necessary optimizations to capture MEV opportunities. The more MEV these pools extract, the more resources they have to improve their MEV-extraction capabilities (and increase overall revenue), essentially creating [economies of scale (opens in a new tab)](https://www.investopedia.com/terms/e/economiesofscale.asp#) . With fewer resources at their disposal, solo stakers may be unable to profit from MEV opportunities. This may increase the pressure on independent validators to join powerful staking pools to boost their earnings, reducing decentralization in Ethereum. ### [](https://ethereum.org/developers/docs/mev/#permissioned-mempools) Permissioned mempools In response to sandwiching and frontrunning attacks, traders may start conducting offchain deals with validators for transaction privacy. Instead of sending a potential MEV transaction to the public mempool, the trader sends it directly to the validator, who includes it in a block and splits profits with the trader. “Dark pools” are a larger version of this arrangement and function as permissioned, access-only mempools open to users willing to pay certain fees. This trend would diminish Ethereum’s permissionlessness and trustlessness and potentially transform the blockchain into a “pay-to-play” mechanism that favors the highest bidder. Permissioned mempools would also accelerate the centralization risks described in the previous section. Large pools running multiple validators will likely benefit from offering transaction privacy to traders and users, increasing their MEV revenues. Combating these MEV-related problems in post-Merge Ethereum is a core area of research. To date, two solutions proposed to reduce the negative impact of MEV on Ethereum’s decentralization and security after The Merge are [**Proposer-Builder Separation (PBS)**](https://ethereum.org/roadmap/pbs/) and the [**Builder API** (opens in a new tab)](https://github.com/ethereum/builder-specs) . ### [](https://ethereum.org/developers/docs/mev/#proposer-builder-separation) Proposer-Builder Separation In both proof-of-work and proof-of-stake, a node that builds a block proposes it for addition to the chain to other nodes participating in consensus. A new block becomes part of the canonical chain after another miner builds on top of it (in PoW) or it receives attestations from the majority of validators (in PoS). The combination of block producer and block proposer roles is what introduces most of the MEV-related problems described previously. For example, consensus nodes are incentivized to trigger chain reorganizations in [time-bandit attacks (opens in a new tab)](https://www.mev.wiki/attack-examples/time-bandit-attack) to maximize MEV earnings. [Proposer-builder separation (opens in a new tab)](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) (PBS) is designed to mitigate the impact of MEV, especially at the consensus layer. PBS’ major feature is the separation of block producer and block proposer rules. Validators are still responsible for proposing and voting on blocks, but a new class of specialized entities, called **block builders**, are tasked with ordering transactions and building blocks. Under PBS, a block builder creates a transaction bundle and places a bid for its inclusion in a Beacon Chain block (as the “execution payload”). The validator selected to propose the next block then checks the different bids and chooses the bundle with the highest fee. PBS essentially creates an auction market, where builders negotiate with validators selling blockspace. Current PBS designs use a [commit-reveal scheme (opens in a new tab)](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/) in which builders only publish a cryptographic commitment to a block’s contents (block header) along with their bids. After accepting the winning bid, the proposer creates a signed block proposal that includes the block header. The block builder is expected to publish the full block body after seeing the signed block proposal, and it must also receive enough from validators before it is finalized. #### [](https://ethereum.org/developers/docs/mev/#how-does-pbs-curb-mev-impact) How does proposer-builder separation mitigate MEV’s impact? In-protocol proposer-builder separation reduces MEV’s effect on consensus by removing MEV extraction from the purview of validators. Instead, block builders running specialized hardware will capture MEV opportunities going forward. This doesn’t exclude validators totally from MEV-related income, though, as builders must bid high to get their blocks accepted by validators. Nevertheless, with validators no longer directly focused on optimizing MEV income, the threat of time-bandit attacks reduces. Proposer-builder separation also reduces MEV’s centralization risks. For instance, the use of a commit-reveal scheme removes the need for builders to trust validators not to steal the MEV opportunity or expose it to other builders. This lowers the barrier for solo stakers to benefit from MEV, otherwise, builders would trend towards favoring large pools with offchain reputation and conducting offchain deals with them. Similarly, validators don’t have to trust builders not to withhold block bodies or publish invalid blocks because payment is unconditional. The validator’s fee still processes even if the proposed block is unavailable or declared invalid by other validators. In the latter case, the block is simply discarded, forcing the block builder to lose all transaction fees and MEV revenue. ### [](https://ethereum.org/developers/docs/mev/#builder-api) Builder API While proposer-builder separation promises to reduce the effects of MEV extraction, implementing it requires changes to the consensus protocol. Specifically, the [fork choice](https://ethereum.org/developers/docs/consensus-mechanisms/pos/#fork-choice) rule on the Beacon Chain would need to be updated. The [Builder API (opens in a new tab)](https://github.com/ethereum/builder-specs) is a temporary solution aimed at providing a working implementation of proposer-builder separation, albeit with higher trust assumptions. The Builder API is a modified version of the [Engine API (opens in a new tab)](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) used by consensus layer clients to request execution payloads from execution layer clients. As outlined in the [honest validator specification (opens in a new tab)](https://github.com/ethereum/consensus-specs/blob/master/specs/bellatrix/validator.md) , validators selected for block proposing duties request a transaction bundle from a connected execution client, which they include in the proposed Beacon Chain block. The Builder API also acts as a middleware between validators and execution-layer clients; but it is different because it allows validators on the Beacon Chain to source blocks from external entities (instead of building a block locally using an execution client). Below is an overview of how the Builder API works: 1. The Builder API connects the validator to a network of block builders running execution layer clients. Like in PBS, builders are specialized parties that invest in resource-intensive block-building and use different strategies to maximize revenue earned from MEV + priority tips. 2. A validator (running a consensus layer client) requests execution payloads along with bids from the network of builders. Bids from builders will contain the execution payload header—a cryptographic commitment to the payload's contents—and a fee to be paid to the validator. 3. The validator reviews the incoming bids and picks the execution payload with the highest fee. Using the Builder API, the validator creates a "blinded" Beacon block proposal that includes only their signature and the execution payload header and sends it to the builder. 4. The builder running the Builder API is expected to respond with the full execution payload upon seeing the blinded block proposal. This allows the validator to create a "signed" Beacon block, which they propagate throughout the network. 5. A validator using the Builder API is still expected to build a block locally in case the block builder fails to respond promptly, so they don't miss out on block proposal rewards. However, validator cannot create another block using either the now-revealed transactions or another set, as it would amount to _equivocation_ (signing two blocks within the same slot), which is a slashable offense. An example implementation of the Builder API is [MEV Boost (opens in a new tab)](https://github.com/flashbots/mev-boost) , an improvement on the [Flashbots auction mechanism (opens in a new tab)](https://docs.flashbots.net/flashbots-auction/overview) designed to curb the negative externalities of MEV on Ethereum. Flashbots auction allows validators in proof-of-stake to outsource the work of building profitable blocks to specialized parties called **searchers**. [![A diagram showing the MEV flow in detail](https://ethereum.org/_next/image/?url=%2Fcontent%2Fdevelopers%2Fdocs%2Fmev%2Fmev.png&w=1920&q=75)](https://ethereum.org/content/developers/docs/mev/mev.png) Searchers look for lucrative MEV opportunities and send transaction bundles to block proposers along with a [sealed-price bid (opens in a new tab)](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) for inclusion in the block. The validator running mev-geth, a forked version of the go-ethereum (Geth) client only has to choose the bundle with the most profit and include it as part of the new block. To protect block proposers (validators) from spam and invalid transactions, transaction bundles pass through **relayers** for validation before getting to the proposer. MEV Boost retains the same workings of the original Flashbots auction, albeit with new features designed for Ethereum’s switch to proof-of-stake. Searchers still find profitable MEV transactions for inclusion in blocks, but a new class of specialized parties, called **builders**, are responsible for aggregating transactions and bundles into blocks. A builder accepts sealed-price bids from searchers and runs optimizations to find the most profitable ordering. The relayer is still responsible for validating transaction bundles before passing them to the proposer. However, MEV Boost introduces **escrows** responsible for providing [data availability](https://ethereum.org/developers/docs/data-availability/) by storing block bodies sent by builders and block headers sent by validators. Here, a validator connected to a relay asks for available execution payloads and uses MEV Boost’s ordering algorithm to select the payload header with the highest bid + MEV tips. #### [](https://ethereum.org/developers/docs/mev/#how-does-builder-api-curb-mev-impact) How does the Builder API mitigate MEV’s impact? The core benefit of the Builder API is its potential to democratize access to MEV opportunities. Using commit-reveal schemes eliminates trust assumptions and reduces entry barriers for validators seeking to benefit from MEV. This should reduce the pressure on solo stakers to integrate with large staking pools in order to boost MEV profits. Widespread implementation of the Builder API will encourage greater competition among block builders, which increases censorship resistance. As validators review bids from multiple builders, a builder intent on censoring one or more user transactions must outbid all other non-censoring builders to be successful. This dramatically increases the cost of censoring users and discourages the practice. Some projects, such as MEV Boost, use the Builder API as part of an overall structure designed to provide transaction privacy to certain parties, such as traders trying to avoid frontrunning/sandwiching attacks. This is achieved by providing a private communication channel between users and block builders. Unlike the permissioned mempools described earlier, this approach is beneficial for the following reasons: 1. The existence of multiple builders on the market makes censoring impractical, which benefits users. In contrast, the existence of centralized and trust-based dark pools would concentrate power in the hands of a few block builders and increase the possibility of censoring. 2. The Builder API software is open-source, which allows anyone to offer block-builder services. This means users aren’t forced into using any particular block builder and improves Ethereum’s neutrality and permissionlessness. Moreover, MEV-seeking traders won’t inadvertently contribute to centralization by using private transaction channels. [](https://ethereum.org/developers/docs/mev/#related-resources) Related resources --------------------------------------------------------------------------------- * [Flashbots docs (opens in a new tab)](https://docs.flashbots.net/) * [Flashbots GitHub (opens in a new tab)](https://github.com/flashbots/pm) * [mevboost.org (opens in a new tab)](https://www.mevboost.org/) - _Tracker with real-time stats for MEV-Boost relays and block builders_ [](https://ethereum.org/developers/docs/mev/#further-reading) Further reading ----------------------------------------------------------------------------- * [What Is Miner-Extractable Value (MEV)? (opens in a new tab)](https://blog.chain.link/what-is-miner-extractable-value-mev/) * [MEV and Me (opens in a new tab)](https://www.paradigm.xyz/2021/02/mev-and-me) * [Ethereum is a Dark Forest (opens in a new tab)](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/) * [Escaping the Dark Forest (opens in a new tab)](https://samczsun.com/escaping-the-dark-forest/) * [Flashbots: Frontrunning the MEV Crisis (opens in a new tab)](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752) * [@bertcmiller's MEV Threads (opens in a new tab)](https://twitter.com/bertcmiller/status/1402665992422047747) * [MEV-Boost: Merge ready Flashbots Architecture (opens in a new tab)](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) * [What Is MEV Boost (opens in a new tab)](https://www.alchemy.com/overviews/mev-boost) * [Why run mev-boost? (opens in a new tab)](https://writings.flashbots.net/writings/why-run-mevboost/) * [The Hitchhikers Guide To Ethereum (opens in a new tab)](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) --- # State Channels | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/scaling/state-channels/#main-content) Change page State Channels ============== Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/scaling/state-channels/index.md) On this page State channels allow participants to securely transact offchain while keeping interaction with [Ethereum](https://ethereum.org/) Mainnet at a minimum. Channel peers can conduct an arbitrary number of offchain transactions while only submitting two onchain transactions to open and close the channel. This allows for extremely high transaction throughput and results in lower costs for users. [](https://ethereum.org/developers/docs/scaling/state-channels/#prerequisites) Prerequisites -------------------------------------------------------------------------------------------- You should have read and understood our pages on [Ethereum scaling](https://ethereum.org/developers/docs/scaling/) and [layer 2](https://ethereum.org/layer-2/) . [](https://ethereum.org/developers/docs/scaling/state-channels/#what-are-channels) What are channels? ----------------------------------------------------------------------------------------------------- Public blockchains, such as Ethereum, face scalability challenges due to their distributed architecture: onchain transactions must be executed by all nodes. Nodes have to be able to handle the volume of transactions in a block using modest hardware, imposing a limit on the transaction throughput to keep the network decentralized. Blockchain channels solve this problem by allowing users to interact offchain while still relying on the security of the main chain for final settlement. Channels are simple peer-to-peer protocols that allow two parties to make many transactions between themselves and then only post the final results to the blockchain. The channel uses cryptography to demonstrate that the summary data they generate is truly the result of a valid set of intermediate transactions. A ["multisig"](https://ethereum.org/developers/docs/smart-contracts/#multisig) smart contract ensures the transactions are signed by the correct parties. With channels, state changes are executed and validated by interested parties, minimizing computation on Ethereum's execution layer. This decreases congestion on Ethereum and also increases transaction processing speeds for users. Each channel is managed by a [multisig smart contract](https://ethereum.org/developers/docs/smart-contracts/#multisig) running on Ethereum. To open a channel, participants deploy the channel contract onchain and deposit funds into it. Both parties collectively sign a state update to initialize the channel's state, after which they can transact quickly and freely offchain. To close the channel, participants submit the last agreed-upon state of the channel onchain. Afterward, the smart contract distributes the locked funds according to each participant's balance in the channel's final state. Peer-to-peer channels are particularly useful for situations where some predefined participants wish to transact with high frequency without incurring visible overhead. Blockchain channels fall under two categories: **payment channels** and **state channels**. [](https://ethereum.org/developers/docs/scaling/state-channels/#payment-channels) Payment channels -------------------------------------------------------------------------------------------------- A payment channel is best described as a "two-way ledger" collectively maintained by two users. The ledger's initial balance is the sum of deposits locked into the onchain contract during the channel opening phase. Payment channel transfers can be performed instantaneously and without the involvement of the actual blockchain itself, except for an initial one-time onchain creation and an eventual closing of the channel. Updates to the ledger's balance (i.e., the payment channel's state) require the approval of all parties in the channel. A channel update, signed by all channel participants, is considered finalized, much like a transaction on Ethereum. Payment channels were among the earliest scaling solutions designed to minimize expensive onchain activity of simple user interactions (e.g., ETH transfers, atomic swaps, micropayments). Channel participants can conduct an unlimited amount of instant, feeless transactions between each other as long as the net sum of their transfers does not exceed the deposited tokens. [](https://ethereum.org/developers/docs/scaling/state-channels/#state-channels) State channels ---------------------------------------------------------------------------------------------- Apart from supporting offchain payments, payment channels have not proven useful for handling general state transition logic. State channels were created to solve this problem and make channels useful for scaling general-purpose computation. State channels still have a lot in common with payment channels. For example, users interact by exchanging cryptographically signed messages (transactions), which the other channel participants must also sign. If a proposed state update isn't signed by all participants, it is considered invalid. However, in addition to holding the user's balances, the channel also tracks the current state of the contract's storage (i.e., values of contract variables). This makes it possible to execute a smart contract offchain between two users. In this scenario, updates to the smart contract's internal state require only the approval of the peers who created the channel. While this solves the scalability problem described earlier, it has implications for security. On Ethereum, the validity of state transitions is enforced by the network's consensus protocol. This makes it impossible to propose an invalid update to a smart contract's state or alter smart contract execution. State channels don't have the same security guarantees. To some extent, a state channel is a miniature version of Mainnet. With a limited set of participants enforcing rules, the possibility of malicious behavior (e.g., proposing invalid state updates) increases. State channels derive their security from a dispute arbitration system based on . [](https://ethereum.org/developers/docs/scaling/state-channels/#how-state-channels-work) How state channels work ---------------------------------------------------------------------------------------------------------------- Basically, the activity in a state channel is a session of interactions involving users and a blockchain system. Users mostly communicate with each other offchain and only interact with the underlying blockchain to open the channel, close the channel, or settle potential disputes between participants. The following section outlines the basic workflow of a state channel: ### [](https://ethereum.org/developers/docs/scaling/state-channels/#opening-the-channel) Opening the channel Opening a channel requires participants to commit funds to a smart contract on Mainnet. The deposit also functions as a virtual tab, so participating actors can transact freely without needing to settle payments immediately. Only when the channel is finalized onchain do parties settle each other and withdraw what's left of their tab. This deposit also serves as a bond to guarantee honest behavior from each participant. If depositors are found guilty of malicious actions during the dispute resolution phase, the contract slashes their deposit. Channel peers must sign an initial state, which they all agree upon. This serves as the state channel's genesis, after which users can start transacting. ### [](https://ethereum.org/developers/docs/scaling/state-channels/#using-the-channel) Using the channel After initializing the channel's state, peers interact by signing transactions and sending them to each other for approval. Participants initiate state updates with these transactions and sign state updates from others. Each transaction comprises the following: * A **nonce**, which acts as a unique ID for transactions and prevents replay attacks. It also identifies the order in which state updates occurred (which is important for dispute resolution) * The channel's old state * The channel's new state * The transaction which triggers the state transition (e.g., Alice sends 5 ETH to Bob) State updates in the channel are not broadcasted onchain as is normally the case when users interact on Mainnet, which aligns with state channels' goal to minimize onchain footprint. As long as participants agree on state updates, they are as final as an Ethereum transaction. Participants only need to depend on Mainnet's consensus if a dispute arises. ### [](https://ethereum.org/developers/docs/scaling/state-channels/#closing-the-channel) Closing the channel Closing a state channel requires submitting the channel's final, agreed-upon state to the onchain smart contract. Details referenced in the state update include the number of each participant's moves and a list of approved transactions. After verifying that the state update is valid (i.e., it is signed by all parties) the smart contract finalizes the channel and distributes the locked funds according to the channel's outcome. Payments made offchain are applied to Ethereum's state and each participant receives their remaining portion of the locked funds. The scenario described above represents what happens in the happy case. Sometimes, users may be unable to reach an agreement and finalize the channel (the sad case). Any of the following could be true of the situation: * Participants go offline and fail to propose state transitions * Participants refuse to co-sign valid state updates * Participants try to finalize the channel by proposing an old state update to the onchain contract * Participants propose invalid state transitions for others to sign Whenever consensus breaks down between participating actors in a channel, the last option is to rely on Mainnet's consensus to enforce the channel's final, valid state. In this case, closing the state channel requires settling disputes onchain. ### [](https://ethereum.org/developers/docs/scaling/state-channels/#settling-disputes) Settling disputes Typically, parties in a channel agree on closing the channel beforehand and co-sign the last state transition, which they submit to the smart contract. Once the update is approved onchain, execution of the offchain smart contract ends and participants exit the channel with their money. However, one party can submit an onchain request to end the smart contract's execution and finalize the channel—without waiting for their counterpart's approval. If any of the consensus-breaking situations described earlier occur, either party can trigger the onchain contract to close the channel and distribute funds. This provides **trustlessness**, ensuring that honest parties can exit their deposits at any point, regardless of the other party's actions. To process the channel exit, the user must submit the application's last valid state update to the onchain contract. If this checks out (i.e., it bears the signature of all parties), then funds are redistributed in their favor. There is, however, a delay in executing single-user exit requests. If the request to conclude the channel was unanimously approved, then the onchain exit transaction is executed immediately. The delay comes into play in single-user exits due to the possibility of fraudulent actions. For example, a channel participant may try to finalize the channel on Ethereum by submitting an older state update onchain. As a countermeasure, state channels allow honest users to challenge invalid state updates by submitting the latest, valid state of the channel onchain. State channels are designed such that newer, agreed-upon state updates trump older state updates. Once a peer triggers the onchain dispute-resolution system, the other party is required to respond within a time limit (called the challenge window). This allows users to challenge the exit transaction, especially if the other party is applying a stale update. Whatever the case may be, channel users always have strong finality guarantees: if the state transition in their possession was signed by all members and is the most recent update, then it is of equal finality with a regular onchain transaction. They still have to challenge the other party onchain, but the only possible outcome is finalizing the last valid state, which they hold. ### [](https://ethereum.org/developers/docs/scaling/state-channels/#how-do-state-channels-interact-with-ethereum) How do state channels interact with Ethereum? Although they exist as offchain protocols, state channels have an onchain component: the smart contract deployed on Ethereum when opening the channel. This contract controls the assets deposited into the channel, verifies state updates, and arbitrates disputes between participants. State channels don't publish transaction data or state commitments to Mainnet, unlike [layer 2](https://ethereum.org/layer-2/) scaling solutions. However, they are more connected to Mainnet than, say, [sidechains](https://ethereum.org/developers/docs/scaling/sidechains/) , making them somewhat safer. State channels rely on the main Ethereum protocol for the following: #### [](https://ethereum.org/developers/docs/scaling/state-channels/#liveness) 1\. Liveness The onchain contract deployed when opening the channel is responsible for the channel's functionality. If the contract is running on Ethereum, then the channel is always available for usage. Conversely, a sidechain can always fail, even if Mainnet is operational, putting user funds at risk. #### [](https://ethereum.org/developers/docs/scaling/state-channels/#security) 2\. Security To some extent, state channels rely on Ethereum to provide security and protect users from malicious peers. As discussed in later sections, channels use a fraud proof mechanism that lets users challenge attempts to finalize the channel with an invalid or stale update. In this case, the honest party provides the latest valid state of the channel as a fraud proof to the onchain contract for verification. Fraud proofs enable mutually distrustful parties to conduct offchain transactions without risking their funds in the process. #### [](https://ethereum.org/developers/docs/scaling/state-channels/#finality) 3\. Finality State updates collectively signed by channel users are considered as good as onchain transactions. Still, all in-channel activity only achieves true finality when the channel is closed on Ethereum. In the optimistic case, both parties can cooperate and sign the final state update and submit onchain to close the channel, after which the funds are distributed according to the channel's final state. In the pessimistic case, where someone tries to cheat by posting an incorrect state update onchain, their transaction isn't finalized until the challenge window elapses. [](https://ethereum.org/developers/docs/scaling/state-channels/#virtual-state-channels) Virtual state channels -------------------------------------------------------------------------------------------------------------- The naive implementation of a state channel would be to deploy a new contract when two users wish to execute an application offchain. This is not only infeasible, but it also negates the cost-effectiveness of state channels (onchain transaction costs can quickly add up). To solve this problem, "virtual channels" were created. Unlike regular channels that require onchain transactions to open and terminate, a virtual channel can be opened, executed, and finalized without interacting with the main chain. It is even possible to settle disputes offchain using this method. This system relies on the existence of so-called "ledger channels", which have been funded onchain. Virtual channels between two parties can be built on top of an existing ledger channel, with the owner(s) of the ledger channel serving as an intermediary. Users in each virtual channel interact via a new contract instance, with the ledger channel able to support multiple contract instances. The ledger channel's state also contains more than one contract storage state, allowing for parallel execution of applications offchain between different users. Just like regular channels, users exchange state updates to progress the state machine. Unless a dispute arises, the intermediary only has to be contacted when opening or terminating the channel. ### [](https://ethereum.org/developers/docs/scaling/state-channels/#virtual-payment-channels) Virtual payment channels Virtual payment channels work off the same idea as virtual state channels: participants connected to the same network can pass messages without needing to open a new channel onchain. In virtual payment channels, value transfers are routed through one or more intermediaries, with guarantees that only the intended recipient can receive transferred funds. [](https://ethereum.org/developers/docs/scaling/state-channels/#applications-of-state-channels) Applications of state channels ------------------------------------------------------------------------------------------------------------------------------ ### [](https://ethereum.org/developers/docs/scaling/state-channels/#payments) Payments Early blockchain channels were simple protocols that allowed two participants to conduct rapid, low-fee transfers offchain without having to pay high transaction fees on Mainnet. Today, payment channels are still useful for applications designed for the exchange and deposits of ether and tokens. Channel-based payments have the following advantages: 1. **Throughput**: The amount of offchain transactions per channel is unconnected to Ethereum's throughput, which is influenced by various factors, especially block size and block time. By executing transactions offchain, blockchain channels can achieve higher throughput. 2. **Privacy**: Because channels exist offchain, details of interactions between participants are not recorded on Ethereum's public blockchain. Channel users only have to interact onchain when funding and closing channels or settling disputes. Thus, channels are useful for individuals who desire more private transactions. 3. **Latency**: Offchain transactions conducted between channel participants can be settled instantly, if both parties cooperate, reducing delays. In contrast, sending a transaction on Mainnet requires waiting for nodes to process the transaction, produce a new block with the transaction, and reach consensus. Users may also need to wait for more block confirmations before considering a transaction finalized. 4. **Cost**: State channels are particularly useful in situations where a set of participants will exchange many state updates over a long period. The only costs incurred are the opening and closing of the state channel smart contract; every state change between opening and closing the channel will be cheaper than the last as the settlement cost is distributed accordingly. Implementing state channels on layer 2 solutions, such as [rollups](https://ethereum.org/developers/docs/scaling/#rollups) , could make them even more attractive for payments. While channels offer cheap payments, the costs of setting up the onchain contract on Mainnet during the opening phase can be get expensive—especially when gas fees spike. Ethereum-based rollups offer [lower transaction fees (opens in a new tab)](https://l2fees.info/) and can reduce overhead for channel participants by bringing down setup fees. ### [](https://ethereum.org/developers/docs/scaling/state-channels/#microtransactions) Microtransactions Microtransactions are low-value payments (e.g., lower than a fraction of a dollar) that businesses cannot process without incurring losses. These entities must pay payment service providers, which they cannot do if the margin on customer payments is too low to make a profit. Payment channels solve this problem by reducing the overhead associated with microtransactions. For example, an Internet Service Provider (ISP) can open a payment channel with a customer, allowing them to stream small payments each time they use the service. Beyond the cost of opening and closing the channel, participants don't incur further costs on microtransactions (no gas fees). This is a win-win situation since customers have more flexibility in how much they pay for services and businesses don't lose out on profitable microtransactions. ### [](https://ethereum.org/developers/docs/scaling/state-channels/#decentralized-applications) Decentralized applications Like payment channels, state channels can make conditional payments according to the state machine's final states. State channels can also support arbitrary state transition logic, making them useful for executing generic apps offchain. State channels are often limited to simple turn-based applications, as this makes it easier to manage funds committed to the onchain contract. Also, with a limited number of parties updating the offchain application's state at intervals, punishing dishonest behavior is relatively straightforward. The efficiency of a state channel application also depends on its design. For example, a developer might deploy the app channel contract onchain once and allow other players to re-use the app without having to go onchain. In this case, the initial app channel serves as a ledger channel supporting multiple virtual channels, each running a new instance of the app's smart contract offchain. A potential use-case for state channel applications is simple two-player games, where funds are distributed based on the game's outcome. The benefit here is that players don't have to trust each other (trustlessness) and the onchain contract, not players, controls the allocation of funds and settlement of disputes (decentralization). Other possible use-cases for state channel apps include ENS name ownership, NFT ledgers, and many more. ### [](https://ethereum.org/developers/docs/scaling/state-channels/#atomic-transfers) Atomic transfers Early payment channels were restricted to transfers between two parties, limiting their usability. However, the introduction of virtual channels allowed individuals to route transfers through intermediaries (i.e., multiple p2p channels) without having to open a new channel onchain. Commonly described as "multi-hop transfers", routed payments are atomic (i.e., either all parts of the transaction succeed or it fails altogether). Atomic transfers use [Hashed Timelock Contracts (HTLCs) (opens in a new tab)](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts) to ensure the payment is released only if certain conditions are met, thereby reducing counterparty risk. [](https://ethereum.org/developers/docs/scaling/state-channels/#drawbacks-of-state-channels) Drawbacks of using state channels ------------------------------------------------------------------------------------------------------------------------------ ### [](https://ethereum.org/developers/docs/scaling/state-channels/#liveness-assumptions) Liveness assumptions To ensure efficiency, state channels place time limits on the ability of channel participants to respond to disputes. This rule assumes that peers will always be online to monitor channel activity and contest challenges when necessary. In reality, users can go offline for reasons out of their control (e.g., poor internet connection, mechanical failure, etc.). If an honest user goes offline, a malicious peer can exploit the situation by presenting old intermediate states to the adjudicator contract and stealing the committed funds. Some channels use "watchtowers"—entities responsible for watching onchain dispute events on behalf of others and taking necessary actions, like alerting concerned parties. However, this can add to the costs of using a state channel. ### [](https://ethereum.org/developers/docs/scaling/state-channels/#data-unavailability) Data unavailability As explained earlier, challenging an invalid dispute requires presenting the latest, valid state of the state channel. This is another rule based on an assumption—that users have access to the channel's latest state. Although expecting channel users to store copies of offchain application state is reasonable, this data may be lost due to error or mechanical failure. If the user doesn't have the data backed up, they can only hope that the other party doesn't finalize an invalid exit request using old state transitions in their possession. Ethereum users don't have to deal with this problem since the network enforces rules on data availability. Transaction data is stored and propagated by all nodes and available for users to download if and when necessary. ### [](https://ethereum.org/developers/docs/scaling/state-channels/#liquidity-issues) Liquidity issues To establish a blockchain channel, participants need to lock funds in an onchain smart contract for the channel's lifecycle. This reduces the liquidity of channel users and also limits channels to those who can afford to keep funds locked on Mainnet. However, ledger channels—operated by an offchain service provider (OSP)—can reduce liquidity issues for users. Two peers connected to a ledger channel can create a virtual channel, which they can open and finalize completely offchain, anytime they want. Offchain service providers could also open channels with multiple peers, making them useful for routing payments. Of course, users must pay fees to OSPs for their services, which may be undesirable for some. ### [](https://ethereum.org/developers/docs/scaling/state-channels/#griefing-attacks) Griefing attacks Griefing attacks are a common feature of fraud proof-based systems. A griefing attack does not directly benefit the attacker but causes grief (i.e., harm) to the victim, hence the name. Fraud proving is susceptible to griefing attacks because the honest party must respond to every dispute, even invalid ones, or risk losing their funds. A malicious participant can decide to repeatedly post stale state transitions onchain, forcing the honest party to respond with the valid state. The cost of those onchain transactions can quickly add up, causing honest parties to lose out in the process. ### [](https://ethereum.org/developers/docs/scaling/state-channels/#predefined-participant-sets) Predefined participant sets By design, the number of participants that comprise a state channel remains fixed throughout its lifetime. This is because updating the participant set would complicate the channel's operation, especially when funding the channel, or settling disputes. Adding or removing participants would also require additional onchain activity, which increases overhead for users. While this makes state channels easier to reason about, it limits the usefulness of channel designs to application developers. This partly explains why state channels have been dropped in favor of other scaling solutions, such as rollups. ### [](https://ethereum.org/developers/docs/scaling/state-channels/#parallel-transaction-processing) Parallel transaction processing Participants in the state channel send state updates in turns, which is why they work best for "turn-based applications" (e.g., a two-player chess game). This eliminates the need to handle simultaneous state updates and reduces the work the onchain contract must do to punish stale update posters. However, a side-effect of this design is that transactions are dependent on each other, increasing latency and diminishing the overall user experience. Some state channels solve this problem by using a "full-duplex" design that separates the offchain state into two unidirectional "simplex" states, allowing for concurrent state updates. Such designs improve offchain throughput and decrease transaction delays. [](https://ethereum.org/developers/docs/scaling/state-channels/#use-state-channels) Use state channels ------------------------------------------------------------------------------------------------------ Multiple projects provide implementations of state channels that you can integrate into your dapps: * [Connext (opens in a new tab)](https://connext.network/) * [Perun (opens in a new tab)](https://perun.network/) * [Raiden (opens in a new tab)](https://raiden.network/) * [Statechannels.org (opens in a new tab)](https://statechannels.org/) [](https://ethereum.org/developers/docs/scaling/state-channels/#further-reading) Further reading ------------------------------------------------------------------------------------------------ **State channels** * [Making Sense of Ethereum’s Layer 2 Scaling Solutions: State Channels, Plasma, and Truebit (opens in a new tab)](https://medium.com/l4-media/making-sense-of-ethereums-layer-2-scaling-solutions-state-channels-plasma-and-truebit-22cb40dcc2f4) _– Josh Stark, Feb 12 2018_ * [State Channels - an explanation (opens in a new tab)](https://www.jeffcoleman.ca/state-channels/) _Nov 6, 2015 - Jeff Coleman_ * [Basics of State Channels (opens in a new tab)](https://unlock-protocol.github.io/ethhub/ethereum-roadmap/layer-2-scaling/state-channels/) _District0x_ * [Blockchain State Channels: A State of the Art (opens in a new tab)](https://ieeexplore.ieee.org/document/9627997) _Know of a community resource that helped you? Edit this page and add it!_ --- # Zero-knowledge rollups | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/scaling/zk-rollups/#main-content) Change page Zero-knowledge rollups ====================== Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/scaling/zk-rollups/index.md) On this page Zero-knowledge rollups (ZK-rollups) are layer 2 [scaling solutions](https://ethereum.org/developers/docs/scaling/) that increase throughput on [Ethereum](https://ethereum.org/) Mainnet by moving computation and state-storage offchain. ZK-rollups can process thousands of transactions in a batch and then only post some minimal summary data to Mainnet. This summary data defines the changes that should be made to the Ethereum state and some cryptographic proof that those changes are correct. [](https://ethereum.org/developers/docs/scaling/zk-rollups/#prerequisites) Prerequisites ---------------------------------------------------------------------------------------- You should have read and understood our page on [Ethereum scaling](https://ethereum.org/developers/docs/scaling/) and [layer 2](https://ethereum.org/layer-2/) . [](https://ethereum.org/developers/docs/scaling/zk-rollups/#what-are-zk-rollups) What are zero-knowledge rollups? ----------------------------------------------------------------------------------------------------------------- **Zero-knowledge rollups (ZK-rollups)** bundle (or 'roll up') transactions into batches that are executed offchain. Offchain computation reduces the amount of data that has to be posted to the blockchain. ZK-rollup operators submit a summary of the changes required to represent all the transactions in a batch rather than sending each transaction individually. They also produce to prove the correctness of their changes. The ZK-rollup's state is maintained by a smart contract deployed on the Ethereum network. To update this state, ZK-rollup nodes must submit a validity proof for verification. As mentioned, the validity proof is a cryptographic assurance that the state-change proposed by the rollup is really the result of executing the given batch of transactions. This means that ZK-rollups only need to provide validity proofs to finalize transactions on Ethereum instead of posting all transaction data onchain like [optimistic rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) . There are no delays when moving funds from a ZK-rollup to Ethereum because exit transactions are executed once the ZK-rollup contract verifies the validity proof. Conversely, withdrawing funds from optimistic rollups is subject to a delay to allow anyone to challenge the exit transaction with a . ZK-rollups write transactions to Ethereum as `calldata`. `calldata` is where data that is included in external calls to smart contract functions gets stored. Information in `calldata` is published on the blockchain, allowing anyone to reconstruct the rollup’s state independently. ZK-rollups use compression techniques to reduce transaction data—for example, accounts are represented by an index rather than an address, which saves 28 bytes of data. Onchain data publication is a significant cost for rollups, so data compression can reduce fees for users. [](https://ethereum.org/developers/docs/scaling/zk-rollups/#zk-rollups-and-ethereum) How do ZK-rollups interact with Ethereum? ------------------------------------------------------------------------------------------------------------------------------ A ZK-rollup chain is an offchain protocol that operates on top of the Ethereum blockchain and is managed by onchain Ethereum smart contracts. ZK-rollups execute transactions outside of Mainnet, but periodically commit offchain transaction batches to an onchain rollup contract. This transaction record is immutable, much like the Ethereum blockchain, and forms the ZK-rollup chain. The ZK-rollup's core architecture is made up of the following components: 1. **Onchain contracts**: As mentioned, the ZK-rollup protocol is controlled by smart contracts running on Ethereum. This includes the main contract which stores rollup blocks, tracks deposits, and monitors state updates. Another onchain contract (the verifier contract) verifies zero-knowledge proofs submitted by block producers. Thus, Ethereum serves as the base layer or "layer 1" for the ZK-rollup. 2. **Offchain virtual machine (VM)**: While the ZK-rollup protocol lives on Ethereum, transaction execution and state storage happen on a separate virtual machine independent of the [EVM](https://ethereum.org/developers/docs/evm/) . This offchain VM is the execution environment for transactions on the ZK-rollup and serves as the secondary layer or "layer 2" for the ZK-rollup protocol. Validity proofs verified on Ethereum Mainnet guarantee the correctness of state transitions in the offchain VM. ZK-rollups are "hybrid scaling solutions"—offchain protocols that operate independently but derive security from Ethereum. Specifically, the Ethereum network enforces the validity of state updates on the ZK-rollup and guarantees the availability of data behind every update to the rollup's state. As a result, ZK-rollups are considerably safer than pure offchain scaling solutions, such as [sidechains](https://ethereum.org/developers/docs/scaling/sidechains/) , which are responsible for their security properties, or [validiums](https://ethereum.org/developers/docs/scaling/validium/) , which also verify transactions on Ethereum with validity proofs, but store transaction data elsewhere. ZK-rollups rely on the main Ethereum protocol for the following: ### [](https://ethereum.org/developers/docs/scaling/zk-rollups/#data-availability) Data availability ZK-rollups publish state data for every transaction processed offchain to Ethereum. With this data, it is possible for individuals or businesses to reproduce the rollup’s state and validate the chain themselves. Ethereum makes this data available to all participants of the network as `calldata`. ZK-rollups don’t need to publish much transaction data onchain because validity proofs already verify the authenticity of state transitions. Nevertheless, storing data onchain is still important because it allows permissionless, independent verification of the L2 chain's state which in turn allows anyone to submit batches of transactions, preventing malicious operators from censoring or freezing the chain. Onchain is required for users to interact with the rollup. Without access to state data users cannot query their account balance or initiate transactions (e.g., withdrawals) that rely on state information. ### [](https://ethereum.org/developers/docs/scaling/zk-rollups/#transaction-finality) Transaction finality Ethereum acts as a settlement layer for ZK-rollups: L2 transactions are finalized only if the L1 contract accepts the validity proof. This eliminates the risk of malicious operators corrupting the chain (e.g., stealing rollup funds) since every transaction must be approved on Mainnet. Also, Ethereum guarantees that user operations cannot be reversed once finalized on L1. ### [](https://ethereum.org/developers/docs/scaling/zk-rollups/#censorship-resistance) Censorship resistance Most ZK-rollups use a "supernode" (the operator) to execute transactions, produce batches, and submit blocks to L1. While this ensures efficiency, it increases the risk of censorship: malicious ZK-rollup operators can censor users by refusing to include their transactions in batches. As a security measure, ZK-rollups allow users to submit transactions directly to the rollup contract on Mainnet if they think they are being censored by the operator. This allows users to force an exit from the ZK-rollup to Ethereum without having to rely on the operator’s permission. [](https://ethereum.org/developers/docs/scaling/zk-rollups/#how-do-zk-rollups-work) How do ZK-rollups work? ----------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/developers/docs/scaling/zk-rollups/#transactions) Transactions Users in the ZK-rollup sign transactions and submit to L2 operators for processing and inclusion in the next batch. In some cases, the operator is a centralized entity, called a sequencer, who executes transactions, aggregates them into batches, and submits to L1. The sequencer in this system is the only entity allowed to produce L2 blocks and add rollup transactions to the ZK-rollup contract. Other ZK-rollups may rotate the operator role by using a [proof-of-stake](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) validator set. Prospective operators deposit funds in the rollup contract, with the size of each stake influencing the staker’s chances of getting selected to produce the next rollup batch. The operator’s stake can be slashed if they act maliciously, which incentivizes them to post valid blocks. #### [](https://ethereum.org/developers/docs/scaling/zk-rollups/#how-zk-rollups-publish-transaction-data-on-ethereum) How ZK-rollups publish transaction data on Ethereum As explained, transaction data is published on Ethereum as `calldata`. `calldata` is a data area in a smart contract used to pass arguments to a function and behaves similarly to [memory](https://ethereum.org/developers/docs/smart-contracts/anatomy/#memory) . While `calldata` isn’t stored as part of Ethereum’s state, it persists onchain as part of the Ethereum chain's [history logs (opens in a new tab)](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) . `calldata` does not affect Ethereum's state, making it a cheap way to store data onchain. The `calldata` keyword often identifies the smart contract method being called by a transaction and holds inputs to the method in the form of an arbitrary sequence of bytes. ZK-rollups use `calldata` to publish compressed transaction data onchain; the rollup operator simply adds a new batch by calling the required function in the rollup contract and passes the compressed data as function arguments. This helps reduce costs for users since a large part of rollup fees go toward storing transaction data onchain. ### [](https://ethereum.org/developers/docs/scaling/zk-rollups/#state-commitments) State commitments The ZK-rollup’s state, which includes L2 accounts and balances, is represented as a [Merkle tree](https://ethereum.org/whitepaper/#merkle-trees) . A cryptographic hash of the Merkle tree’s root (Merkle root) is stored in the onchain contract, allowing the rollup protocol to track changes in the state of the ZK-rollup. The rollup transitions to a new state after the execution of a new set of transactions. The operator who initiated the state transition is required to compute a new state root and submit to the onchain contract. If the validity proof associated with the batch is authenticated by the verifier contract, the new Merkle root becomes the ZK-rollup’s canonical state root. Besides computing state roots, the ZK-rollup operator also creates a batch root—the root of a Merkle tree comprising all transactions in a batch. When a new batch is submitted, the rollup contract stores the batch root, allowing users to prove a transaction (e.g., a withdrawal request) was included in the batch. Users will have to provide transaction details, the batch root, and a [Merkle proof](https://ethereum.org/developers/tutorials/merkle-proofs-for-offline-data-integrity/) showing the inclusion path. ### [](https://ethereum.org/developers/docs/scaling/zk-rollups/#validity-proofs) Validity proofs The new state root that the ZK-rollup operator submits to the L1 contract is the result of updates to the rollup’s state. Say Alice sends 10 tokens to Bob, the operator simply decreases Alice’s balance by 10 and increments Bob’s balance by 10. The operator then hashes the updated account data, rebuilds the rollup's Merkle tree, and submits the new Merkle root to the onchain contract. But the rollup contract won’t automatically accept the proposed state commitment until the operator proves the new Merkle root resulted from correct updates to the rollup’s state. The ZK-rollup operator does this by producing a validity proof, a succinct cryptographic commitment verifying the correctness of batched transactions. Validity proofs allow parties to prove the correctness of a statement without revealing the statement itself—hence, they are also called zero-knowledge proofs. ZK-rollups use validity proofs to confirm the correctness of offchain state transitions without having to re-execute transactions on Ethereum. These proofs can come in the form of a [ZK-SNARK (opens in a new tab)](https://arxiv.org/abs/2202.06877) (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) or [ZK-STARK (opens in a new tab)](https://eprint.iacr.org/2018/046) (Zero-Knowledge Scalable Transparent Argument of Knowledge). Both SNARKs and STARKs help attest to the integrity of offchain computation in ZK-rollups, although each proof type has distinctive features. **ZK-SNARKs** For the ZK-SNARK protocol to work, creating a Common Reference String (CRS) is necessary: the CRS provides public parameters for proving and verifying validity proofs. The security of the proving system depends on the CRS setup; if information used to create public parameters fall into the possession of malicious actors they may be able to generate false validity proofs. Some ZK-rollups attempt to solve this problem by using a [multi-party computation ceremony (MPC) (opens in a new tab)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) , involving trusted individuals, to generate public parameters for the ZK-SNARK circuit. Each party contributes some randomness (called "toxic waste") to the construct the CRS, which they must destroy immediately. Trusted setups are used because they increase the security of the CRS setup. As long as one honest participant destroys their input, the security of the ZK-SNARK system is guaranteed. Still, this approach requires trusting those involved to delete their sampled randomness and not undermine the system's security guarantees. Trust assumptions aside, ZK-SNARKs are popular for their small proof sizes and constant-time verification. As proof verification on L1 constitutes the larger cost of operating a ZK-rollup, L2s use ZK-SNARKs to generate proofs that can be verified quickly and cheaply on Mainnet. **ZK-STARKs** Like ZK-SNARKs, ZK-STARKs prove the validity of offchain computation without revealing the inputs. However, ZK-STARKs are considered an improvement on ZK-SNARKs because of their scalability and transparency. ZK-STARKs are 'transparent', as they can work without the trusted setup of a Common Reference String (CRS). Instead, ZK-STARKs rely on publicly verifiable randomness to set up parameters for generating and verifying proofs. ZK-STARKs also provide more scalability because the time needed to prove and verify validity proofs increases _quasilinearly_ in relation to the complexity of the underlying computation. With ZK-SNARKs, proving and verification times scale _linearly_ in relation to the size of the underlying computation. This means ZK-STARKs require less time than ZK-SNARKs for proving and verifying when large datasets are involved, making them useful for high-volume applications. ZK-STARKs are also secure against quantum computers, while the Elliptic Curve Cryptography (ECC) used in ZK-SNARKs is widely believed to be susceptible to quantum computing attacks. The downside to ZK-STARKs is that they produce larger proof sizes, which are more expensive to verify on Ethereum. #### [](https://ethereum.org/developers/docs/scaling/zk-rollups/#validity-proofs-in-zk-rollups) How do validity proofs work in ZK-rollups? ##### Proof generation Before accepting transactions, the operator will perform the usual checks. This includes confirming that: * The sender and receiver accounts are part of the state tree. * The sender has enough funds to process the transaction. * The transaction is correct and matches the sender’s public key on the rollup. * The sender’s nonce is correct, etc. Once the ZK-rollup node has enough transactions, it aggregates them into a batch and compiles inputs for the proving circuit to compile into a succinct ZK-proof. This includes: * A Merkle tree root comprising all the transactions in the batch. * Merkle proofs for transactions to prove inclusion in the batch. * Merkle proofs for each sender-receiver pair in transactions to prove those accounts are part of the rollup's state tree. * A set of intermediate state roots, derived from updating the state root after applying state updates for each transaction (i.e., decreasing sender accounts and increasing receiver accounts). The proving circuit computes the validity proof by "looping" over each transaction and performing the same checks the operator completed before processing the transaction. First, it verifies the sender's account is part of the existing state root using the provided Merkle proof. Then it reduces the sender's balance, increases their nonce, hashes the updated account data and combines it with the Merkle proof to generate a new Merkle root. This Merkle root reflects the sole change in the ZK-rollup's state: a change in the sender's balance and nonce. This is possible because the Merkle proof used to prove the account's existence is used to derive the new state root. The proving circuit performs the same process on the receiver's account. It checks if the receiver's account exists under the intermediate state root (using the Merkle proof), increases their balance, re-hashes the account data and combines it with the Merkle proof to generate a new state root. The process repeats for every transaction; each "loop" creates a new state root from updating the sender's account and a subsequent new root from updating the receiver's account. As explained, every update to the state root represents one part of the rollup's state tree changing. The ZK-proving circuit iterates over the entire transaction batch, verifying the sequence of updates that result in a final state root after the last transaction is executed. The last Merkle root computed becomes the newest canonical state root of the ZK-rollup. ##### Proof verification After the proving circuit verifies the correctness of state updates, the L2 operator submits the computed validity proof to the verifier contract on L1. The contract's verification circuit verifies the proof's validity and also checks public inputs that form part of the proof: * **Pre-state root**: The ZK-rollup’s old state root (i.e., before the batched transactions were executed), reflecting the L2 chain's last known valid state. * **Post-state root**: The ZK-rollup’s new state root (i.e., after the execution of batched transactions), reflecting the L2 chain's newest state. The post-state root is the final root derived after applying state updates in the proving circuit. * **Batch root**: The Merkle root of the batch, derived by _merklizing_ transactions in the batch and hashing the tree's root. * **Transaction inputs**: Data associated with the transactions executed as part of the submitted batch. If the proof satisfies the circuit (i.e., it is valid), it means that there exists a sequence of valid transactions that transition the rollup from the previous state (cryptographically fingerprinted by the pre-state root) to a new state (cryptographically fingerprinted by the post-state root). If the pre-state root matches the root stored in the rollup contract, and the proof is valid, the rollup contract takes the post-state root from the proof and updates its state tree to reflect the rollup's changed state. ### [](https://ethereum.org/developers/docs/scaling/zk-rollups/#entries-and-exits) Entries and exits Users enter the ZK-rollup by depositing tokens in the rollup's contract deployed on the L1 chain. This transaction is queued up since only operators can submit transactions to the rollup contract. If the pending deposit queue starts filling up, the ZK-rollup operator will take the deposit transactions and submit them to the rollup contract. Once the user's funds are in the rollup, they can start transacting by sending transactions to the operator for processing. Users can verify balances on the rollup by hashing their account data, sending the hash to the rollup contract, and providing a Merkle proof to verify against the current state root. Withdrawing from a ZK-rollup to L1 is straightforward. The user initiates the exit transaction by sending their assets on the rollup to a specified account for burning. If the operator includes the transaction in the next batch, the user can submit a withdrawal request to the onchain contract. This withdrawal request will include the following: * Merkle proof proving the inclusion of the user's transaction to the burn account in a transaction batch * Transaction data * Batch root * L1 address to receive deposited funds The rollup contract hashes the transaction data, checks if the batch root exists, and uses the Merkle proof to check if the transaction hash is part of the batch root. Afterward, the contract executes the exit transaction and sends funds to the user's chosen address on L1. [](https://ethereum.org/developers/docs/scaling/zk-rollups/#zk-rollups-and-evm-compatibility) ZK-rollups and EVM compatibility ------------------------------------------------------------------------------------------------------------------------------ Unlike optimistic rollups, ZK-rollups are not readily compatible with the [Ethereum Virtual Machine (EVM)](https://ethereum.org/developers/docs/evm/) . Proving general-purpose EVM computation in circuits is more difficult and resource-intensive than proving simple computations (like the token transfer described previously). However, [advances in zero-knowledge technology (opens in a new tab)](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now) are igniting renewed interest in wrapping EVM computation in zero-knowledge proofs. These efforts are geared towards creating a zero-knowledge EVM (zkEVM) implementation that can efficiently verify the correctness of program execution. A zkEVM recreates existing EVM opcodes for proving/verification in circuits, allowing to execute smart contracts. Like the EVM, a zkEVM transitions between states after computation is performed on some inputs. The difference is that the zkEVM also creates zero-knowledge proofs to verify the correctness of every step in the program’s execution. Validity proofs could verify the correctness of operations that touch the VM’s state (memory, stack, storage) and the computation itself (i.e., did the operation call the right opcodes and execute them correctly?). The introduction of EVM-compatible ZK-rollups is expected to help developers leverage the scalability and security guarantees of zero-knowledge proofs. More importantly, compatibility with native Ethereum infrastructure means developers can build ZK-friendly dapps using familiar (and battle-tested) tooling and languages. [](https://ethereum.org/developers/docs/scaling/zk-rollups/#how-do-zk-rollup-fees-work) How do ZK-rollup fees work? ------------------------------------------------------------------------------------------------------------------- How much users pay for transactions on ZK-rollups is dependent on the gas fee, just like on Ethereum Mainnet. However, gas fees work differently on L2 and are influenced by the following costs: 1. **State write**: There is a fixed cost for writing to Ethereum’s state (i.e., submitting a transaction on the Ethereum blockchain). ZK-rollups reduce this cost by batching transactions and spreading fixed costs across multiple users. 2. **Data publication**: ZK-rollups publish state data for every transaction to Ethereum as `calldata`. `calldata` costs are currently governed by [EIP-1559 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-1559) , which stipulates a cost of 16 gas for non-zero bytes and 4 gas for zero bytes of `calldata`, respectively. The cost paid on each transaction is influenced by how much `calldata` needs to be posted onchain for it. 3. **L2 operator fees**: This is the amount paid to the rollup operator as compensation for computational costs incurred in processing transactions, much like [transaction "priority fees (tips)"](https://ethereum.org/developers/docs/gas/#how-are-gas-fees-calculated) on Ethereum Mainnet. 4. **Proof generation and verification**: ZK-rollup operators must produce validity proofs for transaction batches, which is resource-intensive. Verifying zero-knowledge proofs on Mainnet also costs gas (~ 500,000 gas). Apart from batching transactions, ZK-rollups reduce fees for users by compressing transaction data. You can [see a real-time overview (opens in a new tab)](https://l2fees.info/) of how it costs to use Ethereum ZK-rollups. [](https://ethereum.org/developers/docs/scaling/zk-rollups/#scaling-ethereum-with-zk-rollups) How do ZK-rollups scale Ethereum? ------------------------------------------------------------------------------------------------------------------------------- ### [](https://ethereum.org/developers/docs/scaling/zk-rollups/#transaction-data-compression) Transaction data compression ZK-rollups extend the throughput on Ethereum’s base layer by taking computation offchain, but the real boost for scaling comes from compressing transaction data. Ethereum’s [block size](https://ethereum.org/developers/docs/blocks/#block-size) limits the data each block can hold and, by extension, the number of transactions processed per block. By compressing transaction-related data, ZK-rollups significantly increase the number of transactions processed per block. ZK-rollups can compress transaction data better than optimistic rollups since they don't have to post all the data required to validate each transaction. They only have to post the minimal data required to rebuild the latest state of accounts and balances on the rollup. ### [](https://ethereum.org/developers/docs/scaling/zk-rollups/#recursive-proofs) Recursive proofs An advantage of zero-knowledge proofs is that proofs can verify other proofs. For example, a single ZK-SNARK can verify other ZK-SNARKs. Such "proof-of-proofs" are called recursive proofs and dramatically increase throughput on ZK-rollups. Currently, validity proofs are generated on a block-by-block basis and submitted to the L1 contract for verification. However, verifying single block proofs limits the throughput that ZK-rollups can achieve since only one block can be finalized when the operator submits a proof. Recursive proofs, however, make it possible to finalize several blocks with one validity proof. This is because the proving circuit recursively aggregates multiple block proofs until one final proof is created. The L2 operator submits this recursive proof, and if the contract accepts it, all the relevant blocks will be finalized instantly. With recursive proofs, the number of ZK-rollup transactions that can be finalized on Ethereum at intervals increases. ### [](https://ethereum.org/developers/docs/scaling/zk-rollups/#zk-rollups-pros-and-cons) Pros and cons of ZK-rollups | Pros | Cons | | --- | --- | | Validity proofs ensure correctness of offchain transactions and prevent operators from executing invalid state transitions. | The cost associated with computing and verifying validity proofs is substantial and can increase fees for rollup users. | | Offers faster transaction finality as state updates are approved once validity proofs are verified on L1. | Building EVM-compatible ZK-rollups is difficult due to complexity of zero-knowledge technology. | | Relies on trustless cryptographic mechanisms for security, not the honesty of incentivized actors as with [optimistic rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons)
. | Producing validity proofs requires specialized hardware, which may encourage centralized control of the chain by a few parties. | | Stores data needed to recover the offchain state on L1, which guarantees security, censorship-resistance, and decentralization. | Centralized operators (sequencers) can influence the ordering of transactions. | | Users benefit from greater capital efficiency and can withdraw funds from L2 without delays. | Hardware requirements may reduce the number of participants that can force the chain to make progress, increasing the risk of malicious operators freezing the rollup's state and censoring users. | | Doesn't depend on liveness assumptions and users don't have to validate the chain to protect their funds. | Some proving systems (e.g., ZK-SNARK) require a trusted setup which, if mishandled, could potentially compromise a ZK-rollup's security model. | | Better data compression can help reduce the costs of publishing `calldata` on Ethereum and minimize rollup fees for users. | | ### [](https://ethereum.org/developers/docs/scaling/zk-rollups/#zk-video) A visual explanation of ZK-rollups Watch Finematics explain ZK-rollups: ### Rollups: the ultimate Ethereum scaling strategy? A deep dive into rollups as Ethereum's primary scaling strategy. [Watch with transcript](https://ethereum.org/videos/rollups-scaling-strategy/)   [](https://ethereum.org/developers/docs/scaling/zk-rollups/#zkevm-projects) Who is working on a zkEVM? ------------------------------------------------------------------------------------------------------ zkEVM for L2 vs L1 The projects below use zkEVM technology to build Layer 2 rollups. There is also research into using zkEVM for [L1 block verification](https://ethereum.org/roadmap/zkevm/) , which would enable validators to verify Ethereum blocks without re-executing transactions. Projects working on zkEVMs include: * **[zkEVM (opens in a new tab)](https://github.com/privacy-scaling-explorations/zkevm-specs) ** - _zkEVM is a project funded by the Ethereum Foundation to develop an EVM-compatible ZK-rollup and a mechanism for generating validity proofs for Ethereum blocks._ * **[Polygon zkEVM (opens in a new tab)](https://polygon.technology/solutions/polygon-zkevm) ** - _is a decentralized ZK Rollup on the Ethereum mainnet working on a zero-knowledge Ethereum Virtual Machine (zkEVM) that executes Ethereum transactions in a transparent way, including smart contracts with zero-knowledge-proof validations._ * **[Scroll (opens in a new tab)](https://scroll.io/blog/zkEVM) ** - _Scroll is a tech-driven company working on building a native zkEVM Layer 2 Solution for Ethereum._ * **[Taiko (opens in a new tab)](https://taiko.xyz/) ** - _Taiko is a decentralized, Ethereum-equivalent ZK-rollup (a [Type 1 ZK-EVM (opens in a new tab)](https://vitalik.eth.limo/general/2022/08/04/zkevm.html) )._ * **[ZKsync (opens in a new tab)](https://docs.zksync.io/) ** - _ZKsync Era is an EVM-compatible ZK Rollup built by Matter Labs, powered by its own zkEVM._ * **[Starknet (opens in a new tab)](https://starkware.co/starknet/) ** - _StarkNet is an EVM-compatible layer 2 scaling solution built by StarkWare._ * **[Morph (opens in a new tab)](https://www.morphl2.io/) ** - _Morph is a hybrid rollup scaling solution that utilizes zk-proof to address the Layer 2 state challenge issue._ * **[Linea (opens in a new tab)](https://linea.build/) ** - _Linea is an Ethereum-equivalent zkEVM Layer 2 built by Consensys, fully aligned with the Ethereum ecosystem._ [](https://ethereum.org/developers/docs/scaling/zk-rollups/#further-reading-on-zk-rollups) Further reading on ZK-rollups reading -------------------------------------------------------------------------------------------------------------------------------- * [What Are Zero-Knowledge Rollups? (opens in a new tab)](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups) * [What are zero-knowledge rollups? (opens in a new tab)](https://alchemy.com/blog/zero-knowledge-rollups) * [The Practical Guide To Ethereum Rollups (opens in a new tab)](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) * [STARKs vs SNARKs (opens in a new tab)](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) * [What is a zkEVM? (opens in a new tab)](https://www.alchemy.com/overviews/zkevm) * [ZK-EVM types: Ethereum-equivalent, EVM-equivalent, Type 1, Type 4, and other cryptic buzzwords (opens in a new tab)](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4) * [Intro to zkEVM (opens in a new tab)](https://hackmd.io/@yezhang/S1_KMMbGt) * [What are ZK-EVM L2s? (opens in a new tab)](https://linea.mirror.xyz/qD18IaQ4BROn_Y40EBMTUTdJHYghUtdECscSWyMvm8M) * [Awesome-zkEVM resources (opens in a new tab)](https://github.com/LuozhuZhang/awesome-zkevm) * [ZK-SNARKS under the hood (opens in a new tab)](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html) * [How are SNARKs possible? (opens in a new tab)](https://vitalik.eth.limo/general/2021/01/26/snarks.html) [](https://ethereum.org/developers/docs/scaling/zk-rollups/#tutorials) Tutorials: Privacy & zero-knowledge on Ethereum ---------------------------------------------------------------------------------------------------------------------- * [Using zero-knowledge for a secret state](https://ethereum.org/developers/tutorials/secret-state/) _– How to use ZK proofs and offchain server components to maintain secret game state on-chain._ * [Using Stealth Addresses](https://ethereum.org/developers/tutorials/stealth-addr/) _– How ERC-5564 stealth addresses enable anonymous ETH transfers using cryptographic key derivation._ * [Using Ethereum for web2 authentication](https://ethereum.org/developers/tutorials/ethereum-for-web2-auth/) _– How to integrate Ethereum wallet signatures with SAML-based web2 authentication systems._ --- # ERC-721 Non-Fungible Token Standard | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/standards/tokens/erc-721/#main-content) Change page ERC-721 Non-Fungible Token Standard =================================== Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/tokens/erc-721/index.md) On this page [](https://ethereum.org/developers/docs/standards/tokens/erc-721/#introduction) Introduction -------------------------------------------------------------------------------------------- **What is a Non-Fungible Token?** A Non-Fungible Token (NFT) is used to identify something or someone in a unique way. This type of Token is perfect to be used on platforms that offer collectible items, access keys, lottery tickets, numbered seats for concerts and sports matches, etc. This special type of Token has amazing possibilities so it deserves a proper Standard, the ERC-721 came to solve that! **What is ERC-721?** The ERC-721 introduces a standard for NFT, in other words, this type of Token is unique and can have different value than another Token from the same Smart Contract, maybe due to its age, rarity or even something else like its visual. Wait, visual? Yes! All NFTs have a `uint256` variable called `tokenId`, so for any ERC-721 Contract, the pair `contract address, uint256 tokenId` must be globally unique. That said, a dapp can have a "converter" that uses the `tokenId` as input and outputs an image of something cool, like zombies, weapons, skills or amazing kitties! [](https://ethereum.org/developers/docs/standards/tokens/erc-721/#prerequisites) Prerequisites ---------------------------------------------------------------------------------------------- * [Accounts](https://ethereum.org/developers/docs/accounts/) * [Smart Contracts](https://ethereum.org/developers/docs/smart-contracts/) * [Token standards](https://ethereum.org/developers/docs/standards/tokens/) [](https://ethereum.org/developers/docs/standards/tokens/erc-721/#body) Body ---------------------------------------------------------------------------- The ERC-721 ([Ethereum](https://ethereum.org/) Request for Comments 721), proposed by William Entriken, Dieter Shirley, Jacob Evans, Nastassia Sachs in January 2018, is a Non-Fungible Token Standard that implements an API for tokens within Smart Contracts. It provides functionalities like to transfer tokens from one account to another, to get the current token balance of an account, to get the owner of a specific token and also the total supply of the token available on the network. Besides these it also has some other functionalities like to approve that an amount of token from an account can be moved by a third party account. If a Smart Contract implements the following methods and events it can be called an ERC-721 Non-Fungible Token Contract and, once deployed, it will be responsible to keep track of the created tokens on Ethereum. From [EIP-721 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-721) : ### [](https://ethereum.org/developers/docs/standards/tokens/erc-721/#methods) Methods function balanceOf(address _owner) external view returns (uint256); function ownerOf(uint256 _tokenId) external view returns (address); function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable; function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable; function transferFrom(address _from, address _to, uint256 _tokenId) external payable; function approve(address _approved, uint256 _tokenId) external payable; function setApprovalForAll(address _operator, bool _approved) external; function getApproved(uint256 _tokenId) external view returns (address); function isApprovedForAll(address _owner, address _operator) external view returns (bool); CopySolidity Show all (9) ### [](https://ethereum.org/developers/docs/standards/tokens/erc-721/#events) Events event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId); event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId); event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); CopySolidity ### [](https://ethereum.org/developers/docs/standards/tokens/erc-721/#web3py-example) Examples Let's see how a Standard is so important to make things simple for us to inspect any ERC-721 Token Contract on Ethereum. We just need the Contract Application Binary Interface (ABI) to create an interface to any ERC-721 Token. As you can see below we will use a simplified ABI, to make it a low friction example. #### [](https://ethereum.org/developers/docs/standards/tokens/erc-721/#web3py-example-2) Web3.py Example First, make sure you have installed [Web3.py (opens in a new tab)](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) Python library: pip install web3 Copy from web3 import Web3 from web3._utils.events import get_event_data w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # CryptoKitties Contract acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # CryptoKitties Sales Auction # This is a simplified Contract Application Binary Interface (ABI) of an ERC-721 NFT Contract. # It will expose only the methods: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply() simplified_abi = [\ {\ 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}],\ 'name': 'balanceOf',\ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],\ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True\ },\ {\ 'inputs': [],\ 'name': 'name',\ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],\ 'stateMutability': 'view', 'type': 'function', 'constant': True\ },\ {\ 'inputs': [{'internalType': 'uint256', 'name': 'tokenId', 'type': 'uint256'}],\ 'name': 'ownerOf',\ 'outputs': [{'internalType': 'address', 'name': '', 'type': 'address'}],\ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True\ },\ {\ 'inputs': [],\ 'name': 'symbol',\ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],\ 'stateMutability': 'view', 'type': 'function', 'constant': True\ },\ {\ 'inputs': [],\ 'name': 'totalSupply',\ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],\ 'stateMutability': 'view', 'type': 'function', 'constant': True\ },\ ] ck_extra_abi = [\ {\ 'inputs': [],\ 'name': 'pregnantKitties',\ 'outputs': [{'name': '', 'type': 'uint256'}],\ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True\ },\ {\ 'inputs': [{'name': '_kittyId', 'type': 'uint256'}],\ 'name': 'isPregnant',\ 'outputs': [{'name': '', 'type': 'bool'}],\ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True\ }\ ] ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi) name = ck_contract.functions.name().call() symbol = ck_contract.functions.symbol().call() kitties_auctions = ck_contract.functions.balanceOf(acc_address).call() print(f"{name} [{symbol}] NFTs in Auctions: {kitties_auctions}") pregnant_kitties = ck_contract.functions.pregnantKitties().call() print(f"{name} [{symbol}] NFTs Pregnants: {pregnant_kitties}") # Using the Transfer Event ABI to get info about transferred Kitties. tx_event_abi = { 'anonymous': False, 'inputs': [\ {'indexed': False, 'name': 'from', 'type': 'address'},\ {'indexed': False, 'name': 'to', 'type': 'address'},\ {'indexed': False, 'name': 'tokenId', 'type': 'uint256'}], 'name': 'Transfer', 'type': 'event' } # We need the event's signature to filter the logs event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex() logs = w3.eth.get_logs({ "fromBlock": w3.eth.block_number - 120, "address": w3.to_checksum_address(ck_token_addr), "topics": [event_signature] }) # Notes: # - Increase the number of blocks up from 120 if no Transfer event is returned. # - If you didn't find any Transfer event you can also try to get a tokenId at: # https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events # Click to expand the event's logs and copy its "tokenId" argument recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs] if recent_tx: kitty_id = recent_tx[0]['tokenId'] # Paste the "tokenId" here from the link above is_pregnant = ck_contract.functions.isPregnant(kitty_id).call() print(f"{name} [{symbol}] NFTs {kitty_id} is pregnant: {is_pregnant}") CopyPython Show all (100) CryptoKitties Contract has some interesting Events other than the Standard ones. Let's check two of them, `Pregnant` and `Birth`. # Using the Pregnant and Birth Events ABI to get info about new Kitties. ck_extra_events_abi = [\ {\ 'anonymous': False,\ 'inputs': [\ {'indexed': False, 'name': 'owner', 'type': 'address'},\ {'indexed': False, 'name': 'matronId', 'type': 'uint256'},\ {'indexed': False, 'name': 'sireId', 'type': 'uint256'},\ {'indexed': False, 'name': 'cooldownEndBlock', 'type': 'uint256'}],\ 'name': 'Pregnant',\ 'type': 'event'\ },\ {\ 'anonymous': False,\ 'inputs': [\ {'indexed': False, 'name': 'owner', 'type': 'address'},\ {'indexed': False, 'name': 'kittyId', 'type': 'uint256'},\ {'indexed': False, 'name': 'matronId', 'type': 'uint256'},\ {'indexed': False, 'name': 'sireId', 'type': 'uint256'},\ {'indexed': False, 'name': 'genes', 'type': 'uint256'}],\ 'name': 'Birth',\ 'type': 'event'\ }] # We need the event's signature to filter the logs ck_event_signatures = [\ w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(),\ w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(),\ ] # Here is a Pregnant Event: # - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog pregnant_logs = w3.eth.get_logs({ "fromBlock": w3.eth.block_number - 120, "address": w3.to_checksum_address(ck_token_addr), "topics": [ck_event_signatures[0]] }) recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs] # Here is a Birth Event: # - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a birth_logs = w3.eth.get_logs({ "fromBlock": w3.eth.block_number - 120, "address": w3.to_checksum_address(ck_token_addr), "topics": [ck_event_signatures[1]] }) recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs] CopyPython Show all (49) [](https://ethereum.org/developers/docs/standards/tokens/erc-721/#popular-nfts) Popular NFTs -------------------------------------------------------------------------------------------- * [Etherscan NFT Tracker (opens in a new tab)](https://etherscan.io/nft-top-contracts) list the top NFT on Ethereum by transfers volume. * [CryptoKitties (opens in a new tab)](https://www.cryptokitties.co/) is a game centered around breedable, collectible, and oh-so-adorable creatures we call CryptoKitties. * [Sorare (opens in a new tab)](https://sorare.com/) is a global fantasy football game where you can collect limited editions collectibles, manage your teams and compete to earn prizes. * [The Ethereum Name Service (ENS) (opens in a new tab)](https://ens.domains/) offers a secure & decentralized way to address resources both on and off the blockchain using simple, human-readable names. * [POAP (opens in a new tab)](https://poap.xyz/) delivers free NFTs to people who attend events or complete specific actions. POAPs are free to create and distribute. * [Unstoppable Domains (opens in a new tab)](https://unstoppabledomains.com/) is a San Francisco-based company building domains on blockchains. Blockchain domains replace cryptocurrency addresses with human-readable names and can be used to enable censorship-resistant websites. * [Gods Unchained Cards (opens in a new tab)](https://godsunchained.com/) is a TCG on the Ethereum blockchain that uses NFT's to bring real ownership to in-game assets. * [Bored Ape Yacht Club (opens in a new tab)](https://boredapeyachtclub.com/) is a collection of 10,000 unique NFTs, which, as well as being a provably-rare piece of art, acts as a membership token to the club, providing member perks and benefits that increase over time as a result of community efforts. [](https://ethereum.org/developers/docs/standards/tokens/erc-721/#further-reading) Further reading -------------------------------------------------------------------------------------------------- * [EIP-721: ERC-721 Non-Fungible Token Standard (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-721) * [OpenZeppelin - ERC-721 Docs (opens in a new tab)](https://docs.openzeppelin.com/contracts/3.x/erc721) * [OpenZeppelin - ERC-721 Implementation (opens in a new tab)](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol) * [Alchemy NFT API (opens in a new tab)](https://www.alchemy.com/docs/reference/nft-api-quickstart) [](https://ethereum.org/developers/docs/standards/tokens/erc-721/#tutorials) Tutorials: Build with non-fungible tokens (ERC-721) on Ethereum -------------------------------------------------------------------------------------------------------------------------------------------- * [Vyper ERC-721 Contract Walkthrough](https://ethereum.org/developers/tutorials/erc-721-vyper-annotated-code/) _– An annotated walkthrough of a full ERC-721 NFT contract written in Vyper._ * [How to Write & Deploy an NFT (Part 1/3)](https://ethereum.org/developers/tutorials/how-to-write-and-deploy-an-nft/) _– Step-by-step guide to writing and deploying your first ERC-721 smart contract._ * [How to Mint an NFT (Part 2/3)](https://ethereum.org/developers/tutorials/how-to-mint-an-nft/) _– How to mint an ERC-721 NFT using your deployed smart contract and Web3._ * [How to View Your NFT in Your Wallet (Part 3/3)](https://ethereum.org/developers/tutorials/how-to-view-nft-in-metamask/) _– How to display your minted NFT in MetaMask after deployment._ * [NFT Minter Tutorial](https://ethereum.org/developers/tutorials/nft-minter/) _– Build a full-stack NFT minting dapp with a React frontend, MetaMask, and Alchemy._ --- # ERC-20 Token Standard | ethereum.org [Skip to main content](https://ethereum.org/developers/docs/standards/tokens/erc-20/#main-content) Change page ERC-20 Token Standard ===================== Copy .mdCopy .md [Edit page (opens in a new tab)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/standards/tokens/erc-20/index.md) On this page [](https://ethereum.org/developers/docs/standards/tokens/erc-20/#introduction) Introduction ------------------------------------------------------------------------------------------- **What is a Token?** Tokens can represent virtually anything in [Ethereum](https://ethereum.org/) : * reputation points in an online platform * skills of a character in a game * financial assets like a share in a company * a fiat currency like USD * an ounce of gold * and more... Such a powerful feature of Ethereum must be handled by a robust standard, right? That's exactly where the ERC-20 plays its role! This standard allows developers to build token applications that are interoperable with other products and services. The ERC-20 standard is also used to provide additional functionality to . **What is ERC-20?** The ERC-20 introduces a standard for Fungible Tokens, in other words, they have a property that makes each Token be exactly the same (in type and value) as another Token. For example, an ERC-20 Token acts just like the ETH, meaning that 1 Token is and will always be equal to all the other Tokens. [](https://ethereum.org/developers/docs/standards/tokens/erc-20/#prerequisites) Prerequisites --------------------------------------------------------------------------------------------- * [Accounts](https://ethereum.org/developers/docs/accounts/) * [Smart Contracts](https://ethereum.org/developers/docs/smart-contracts/) * [Token standards](https://ethereum.org/developers/docs/standards/tokens/) [](https://ethereum.org/developers/docs/standards/tokens/erc-20/#body) Body --------------------------------------------------------------------------- The ERC-20 (Ethereum Request for Comments 20), proposed by Fabian Vogelsteller in November 2015, is a Token Standard that implements an API for tokens within Smart Contracts. Example functionalities ERC-20 provides: * transfer tokens from one account to another * get the current token balance of an account * get the total supply of the token available on the network * approve whether an amount of token from an account can be spent by a third-party account If a Smart Contract implements the following methods and events it can be called an ERC-20 Token Contract and, once deployed, it will be responsible to keep track of the created tokens on Ethereum. From [EIP-20 (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-20) : ### [](https://ethereum.org/developers/docs/standards/tokens/erc-20/#methods) Methods function name() public view returns (string) function symbol() public view returns (string) function decimals() public view returns (uint8) function totalSupply() public view returns (uint256) function balanceOf(address _owner) public view returns (uint256 balance) function transfer(address _to, uint256 _value) public returns (bool success) function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) function approve(address _spender, uint256 _value) public returns (bool success) function allowance(address _owner, address _spender) public view returns (uint256 remaining) CopySolidity Show all (9) ### [](https://ethereum.org/developers/docs/standards/tokens/erc-20/#events) Events event Transfer(address indexed _from, address indexed _to, uint256 _value) event Approval(address indexed _owner, address indexed _spender, uint256 _value) CopySolidity ### [](https://ethereum.org/developers/docs/standards/tokens/erc-20/#web3py-example) Examples Let's see how a Standard is so important to make things simple for us to inspect any ERC-20 Token Contract on Ethereum. We just need the Contract Application Binary Interface (ABI) to create an interface to any ERC-20 Token. As you can see below we will use a simplified ABI, to make it a low friction example. #### [](https://ethereum.org/developers/docs/standards/tokens/erc-20/#web3py-example-2) Web3.py Example First, make sure you have installed [Web3.py (opens in a new tab)](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) Python library: pip install web3 Copy from web3 import Web3 w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH) acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2 # This is a simplified Contract Application Binary Interface (ABI) of an ERC-20 Token Contract. # It will expose only the methods: balanceOf(address), decimals(), symbol() and totalSupply() simplified_abi = [\ {\ 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}],\ 'name': 'balanceOf',\ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],\ 'stateMutability': 'view', 'type': 'function', 'constant': True\ },\ {\ 'inputs': [],\ 'name': 'decimals',\ 'outputs': [{'internalType': 'uint8', 'name': '', 'type': 'uint8'}],\ 'stateMutability': 'view', 'type': 'function', 'constant': True\ },\ {\ 'inputs': [],\ 'name': 'symbol',\ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],\ 'stateMutability': 'view', 'type': 'function', 'constant': True\ },\ {\ 'inputs': [],\ 'name': 'totalSupply',\ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],\ 'stateMutability': 'view', 'type': 'function', 'constant': True\ }\ ] dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi) symbol = dai_contract.functions.symbol().call() decimals = dai_contract.functions.decimals().call() totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals # DAI print("===== %s =====" % symbol) print("Total Supply:", totalSupply) print("Addr Balance:", addr_balance) weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi) symbol = weth_contract.functions.symbol().call() decimals = weth_contract.functions.decimals().call() totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals # WETH print("===== %s =====" % symbol) print("Total Supply:", totalSupply) print("Addr Balance:", addr_balance) CopyPython Show all (60) [](https://ethereum.org/developers/docs/standards/tokens/erc-20/#erc20-issues) Known issues ------------------------------------------------------------------------------------------- ### [](https://ethereum.org/developers/docs/standards/tokens/erc-20/#reception-issue) ERC-20 token reception issue **As of 06/20/2024 at least $83,656,418 worth of ERC-20 tokens were lost due to this issue. Note that a pure ERC-20 implementation is prone to this problem unless you implement a set of additional restrictions on top of the standard as listed below.** When ERC-20 tokens are sent to a smart contract that is not designed to handle ERC-20 tokens, those tokens can be permanently lost. This happens because the receiving contract does not have the functionality to recognize or respond to the incoming tokens, and there’s no mechanism in the ERC-20 standard to notify the receiving contract about the incoming tokens. The main ways this issue takes form is through: 1. Token transfer mechanism * ERC-20 tokens are transferred using the transfer or transferFrom functions * When a user sends tokens to a contract address using these functions, the tokens are transferred regardless of whether the receiving contract is designed to handle them 2. Lack of notification * The receiving contract does not receive a notification or callback that tokens have been sent to it * If the receiving contract lacks a mechanism to handle tokens (e.g., a fallback function or a dedicated function to manage token reception), the tokens are effectively stuck in the contract’s address 3. No built-in handling * The ERC-20 standard does not include a mandatory function for receiving contracts to implement, leading to a situation where many contracts are unable to manage incoming tokens properly **Possible Solutions** While it is not possible to prevent this issue with ERC-20 completely there are methods that would allow to significantly reduce the possibility of a tokens loss for the end user: * The most common problem is when a user sends tokens to the token contract address itself (e.g., USDT deposited to the address of USDT token contract). It is recommended to restrict `transfer(..)` function to revert such transfer attempts. Consider adding `require(_to != address(this));` check within the implementation of the `transfer(..)` function. * The `transfer(..)` function in general is not designed for depositing tokens to contracts. `approve(..) & transferFrom(..)` pattern is used to deposit ERC-20 tokens to contracts instead. It is possible to restrict the transfer function to disallow depositing tokens to any contracts with it, however it may break compatibility with contracts that assume tokens can be deposited to contracts with the `transfer(..)` function (e.g., Uniswap liquidity pools). * Always assume that ERC-20 tokens can end up in your contract even if your contract is not supposed to ever receive any. There is no way to prevent or reject accidental deposits on the recipients end. It is recommended to implement a function that would allow to extract accidentally deposited ERC-20 tokens. * Consider using alternative token standards. Some alternative standards have come out of this issue such as [ERC-223](https://ethereum.org/developers/docs/standards/tokens/erc-223/) or [ERC-1363](https://ethereum.org/developers/docs/standards/tokens/erc-1363/) . [](https://ethereum.org/developers/docs/standards/tokens/erc-20/#further-reading) Further reading ------------------------------------------------------------------------------------------------- * [EIP-20: ERC-20 Token Standard (opens in a new tab)](https://eips.ethereum.org/EIPS/eip-20) * [OpenZeppelin - Tokens (opens in a new tab)](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20) * [OpenZeppelin - ERC-20 Implementation (opens in a new tab)](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) * [Alchemy - Guide to Solidity ERC20 Tokens (opens in a new tab)](https://www.alchemy.com/overviews/erc20-solidity) [](https://ethereum.org/developers/docs/standards/tokens/erc-20/#fungible-token-standards) Other fungible token standards ------------------------------------------------------------------------------------------------------------------------- * [ERC-223](https://ethereum.org/developers/docs/standards/tokens/erc-223/) * [ERC-1363](https://ethereum.org/developers/docs/standards/tokens/erc-1363/) * [ERC-777](https://ethereum.org/developers/docs/standards/tokens/erc-777/) * [ERC-4626 - Tokenized vaults](https://ethereum.org/developers/docs/standards/tokens/erc-4626/) * [ERC-7540 - Asynchronous tokenized vaults](https://ethereum.org/developers/docs/standards/tokens/erc-7540/) [](https://ethereum.org/developers/docs/standards/tokens/erc-20/#tutorials) Tutorials: Build with ERC-20 on Ethereum -------------------------------------------------------------------------------------------------------------------- * [ERC-20 Contract Walk-Through](https://ethereum.org/developers/tutorials/erc20-annotated-code/) _– A line-by-line annotated walkthrough of the OpenZeppelin ERC-20 contract implementation._ * [ERC-20 with Safety Rails](https://ethereum.org/developers/tutorials/erc20-with-safety-rails/) _– How to add safeguards to ERC-20 tokens to help users avoid common mistakes._ * [Sending Tokens Using ethers.js](https://ethereum.org/developers/tutorials/send-token-ethersjs/) _– A beginner-friendly guide to transferring ERC-20 tokens using ethers.js._ * [Some tricks used by scam tokens and how to detect them](https://ethereum.org/developers/tutorials/scam-token-tricks/) _– A deep-dive into scam ERC-20 token patterns and how to identify them._ --- # スマート・コントラクトのデプロイ | ethereum.org [メインコンテンツへスキップ](https://ethereum.org/ja/developers/docs/smart-contracts/deploying/#main-content) Change page スマート・コントラクトのデプロイ ================ .mdをコピー.mdをコピー [ページを編集 （新しいタブで開きます）](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/smart-contracts/deploying/index.md) このページの内容 イーサリアムネットワークのユーザーが利用できるようにするには、スマート・コントラクトをデプロイする必要があります。 スマート・コントラクトをデプロイするには、受信者を指定せずに、スマート・コントラクトのコンパイル済みコードを含むイーサリアムのトランザクションを送信するだけです。 [](https://ethereum.org/ja/developers/docs/smart-contracts/deploying/#prerequisites) 前提条件 ----------------------------------------------------------------------------------------- スマート・コントラクトをデプロイする前に、[イーサリアムネットワーク](https://ethereum.org/ja/developers/docs/networks/) 、[トランザクション](https://ethereum.org/ja/developers/docs/transactions/) 、および[スマート・コントラクトの構造](https://ethereum.org/ja/developers/docs/smart-contracts/anatomy/) について理解しておく必要があります。 コントラクトはブロックチェーン上に保存されるため、デプロイにはイーサ(ETH)のコストもかかります。そのため、イーサリアムの[ガスと手数料](https://ethereum.org/ja/developers/docs/gas/) について理解しておく必要があります。 最後に、デプロイする前にコントラクトをコンパイルする必要があるため、[スマート・コントラクトのコンパイル](https://ethereum.org/ja/developers/docs/smart-contracts/compiling/) について必ず読んでおいてください。 [](https://ethereum.org/ja/developers/docs/smart-contracts/deploying/#how-to-deploy-a-smart-contract) スマート・コントラクトのデプロイ方法 ------------------------------------------------------------------------------------------------------------------------ ### [](https://ethereum.org/ja/developers/docs/smart-contracts/deploying/#what-youll-need) 必要なもの * コントラクトのバイトコード – これは[コンパイル](https://ethereum.org/ja/developers/docs/smart-contracts/compiling/) によって生成されます * ガス用のETH – 他のトランザクションと同様にガス・リミットを設定しますが、コントラクトのデプロイには単純なETHの送金よりもはるかに多くのガスが必要になることに注意してください * デプロイ用のスクリプトまたはプラグイン * 独自のノードを実行するか、パブリックノードに接続するか、または[ノードサービス](https://ethereum.org/ja/developers/docs/nodes-and-clients/nodes-as-a-service/) を使用してAPI鍵経由で[イーサリアムノード](https://ethereum.org/ja/developers/docs/nodes-and-clients/) へアクセスすること ### [](https://ethereum.org/ja/developers/docs/smart-contracts/deploying/#steps-to-deploy) スマート・コントラクトをデプロイする手順 具体的な手順は、使用する開発フレームワークによって異なります。たとえば、[コントラクトのデプロイに関するHardhatのドキュメント （新しいタブで開きます）](https://hardhat.org/docs/tutorial/deploying) や、[スマート・コントラクトのデプロイと検証に関するFoundryのドキュメント （新しいタブで開きます）](https://book.getfoundry.sh/forge/deploying) を確認できます。デプロイされると、コントラクトは他の[アカウント](https://ethereum.org/ja/developers/docs/accounts/) と同様にイーサリアムのアドレスを持ち、[ソース・コード検証ツール](https://ethereum.org/ja/developers/docs/smart-contracts/verifying/#source-code-verification-tools) を使用して検証できるようになります。 [](https://ethereum.org/ja/developers/docs/smart-contracts/deploying/#related-tools) 関連ツール ------------------------------------------------------------------------------------------ **Remix - _Remix IDEは、イーサリアムのようなブロックチェーン向けのスマート・コントラクトの開発、デプロイ、管理を可能にします_** * [Remix （新しいタブで開きます）](https://remix.ethereum.org/) **Tenderly - _スマート・コントラクトの開発、テスト、監視、運用のためのデバッグ、可観測性、インフラストラクチャの構成要素を提供するWeb3開発プラットフォーム_** * [tenderly.co （新しいタブで開きます）](https://tenderly.co/) * [ドキュメント （新しいタブで開きます）](https://docs.tenderly.co/) * [GitHub （新しいタブで開きます）](https://github.com/Tenderly) * [ディスコード （新しいタブで開きます）](https://discord.gg/eCWjuvt) **Hardhat - _イーサリアムソフトウェアのコンパイル、デプロイ、テスト、デバッグを行うための開発環境_** * [hardhat.org （新しいタブで開きます）](https://hardhat.org/getting-started/) * [コントラクトのデプロイに関するドキュメント （新しいタブで開きます）](https://hardhat.org/docs/tutorial/deploying) * [GitHub （新しいタブで開きます）](https://github.com/nomiclabs/hardhat) * [ディスコード （新しいタブで開きます）](https://discord.com/invite/TETZs2KK4k) **thirdweb - _単一のコマンドを使用して、任意のEVM互換チェーンに任意のコントラクトを簡単にデプロイします_** * [ドキュメント （新しいタブで開きます）](https://portal.thirdweb.com/deploy/) **Crossmint - _スマート・コントラクトのデプロイ、クレジットカードおよびクロスチェーン決済の有効化、APIを使用したNFTの作成、配布、販売、保存、編集を行うためのエンタープライズグレードのWeb3開発プラットフォーム。_** * [crossmint.com （新しいタブで開きます）](https://www.crossmint.com/) * [ドキュメント （新しいタブで開きます）](https://docs.crossmint.com/) * [ディスコード （新しいタブで開きます）](https://discord.com/invite/crossmint) * [ブログ （新しいタブで開きます）](https://blog.crossmint.com/) [](https://ethereum.org/ja/developers/docs/smart-contracts/deploying/#related-tutorials) 関連チュートリアル -------------------------------------------------------------------------------------------------- * [初めてのスマート・コントラクトのデプロイ](https://ethereum.org/ja/developers/tutorials/deploying-your-first-smart-contract/) _– イーサリアムのテストネットワークに初めてスマート・コントラクトをデプロイするための入門。_ * [Hello World | スマート・コントラクトのチュートリアル](https://ethereum.org/ja/developers/tutorials/hello-world-smart-contract/) _– イーサリアム上で基本的なスマート・コントラクトを作成してデプロイするためのわかりやすいチュートリアル。_ * [Solidityから他のコントラクトと対話する](https://ethereum.org/ja/developers/tutorials/interact-with-other-contracts-from-solidity/) _– 既存のコントラクトからスマート・コントラクトをデプロイし、それと対話する方法。_ * [コントラクトのサイズを縮小する方法](https://ethereum.org/ja/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _\- コントラクトのサイズを制限内に抑え、ガスを節約するためにサイズを縮小する方法_ [](https://ethereum.org/ja/developers/docs/smart-contracts/deploying/#further-reading) 参考文献 ------------------------------------------------------------------------------------------- * [https://docs.openzeppelin.com/learn/deploying-and-interacting （新しいタブで開きます）](https://docs.openzeppelin.com/learn/deploying-and-interacting) - _オープンツェッペリン_ * [Hardhatを使用したコントラクトのデプロイ （新しいタブで開きます）](https://hardhat.org/docs/tutorial/deploying) - _Nomic Labs_ _役に立つコミュニティリソースをご存知ですか？このページを編集して追加してください！_ [](https://ethereum.org/ja/developers/docs/smart-contracts/deploying/#related-topics) 関連トピック -------------------------------------------------------------------------------------------- * [開発フレームワーク](https://ethereum.org/ja/developers/docs/frameworks/) * [イーサリアムノードの実行](https://ethereum.org/ja/developers/docs/nodes-and-clients/run-a-node/) * [ノード・アズ・ア・サービス](https://ethereum.org/ja/developers/docs/nodes-and-clients/nodes-as-a-service/) --- # 채굴 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/#main-content) Change page 채굴 == .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/consensus-mechanisms/pow/mining/index.md) 이 페이지의 내용 작업증명(PoW)은 더 이상 이더리움의 합의 메커니즘 기반이 아니며, 이는 채굴이 중단되었음을 의미합니다. 대신, [이더리움](https://ethereum.org/ko/) 은 ETH를 스테이킹하는 검증자들에 의해 보호됩니다. 오늘부터 ETH 스테이킹을 시작할 수 있습니다. [머지](https://ethereum.org/roadmap/merge/) , [지분 증명 (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) , 그리고 [스테이킹](https://ethereum.org/staking/) 에 대해 자세히 알아보세요. 이 페이지는 역사적 참고용으로만 제공됩니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/#prerequisites) 전제 조건 ------------------------------------------------------------------------------------------------ 이 페이지를 더 잘 이해하려면 먼저 [트랜잭션](https://ethereum.org/ko/developers/docs/transactions/) , [블록](https://ethereum.org/ko/developers/docs/blocks/) 및 [작업증명 (PoW)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/) 에 대해 읽어보시기를 권장합니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/#what-is-ethereum-mining) 이더리움 채굴이란 무엇인가요? --------------------------------------------------------------------------------------------------------------------- 채굴은 현재는 사용되지 않는 이더리움의 작업증명 아키텍처에서 이더리움 블록체인에 추가될 트랜잭션 블록을 생성하는 과정입니다. 채굴이라는 단어는 암호화폐를 금에 비유하는 맥락에서 유래했습니다. 금이나 귀금속이 희소한 것처럼 디지털 토큰도 희소하며, 작업증명 시스템에서 총량을 늘리는 유일한 방법은 채굴뿐입니다. 작업증명 이더리움에서 유일한 발행 방식은 채굴을 통한 것이었습니다. 그러나 금이나 귀금속과 달리, 이더리움 채굴은 블록체인에서 블록을 생성, 검증, 게시 및 전파하여 네트워크를 보호하는 방법이기도 했습니다. 이더 채굴 = 네트워크 보호 채굴은 모든 작업증명 블록체인의 생명선입니다. 소프트웨어를 실행하는 컴퓨터인 이더리움 채굴자들은 지분 증명으로 전환하기 전까지 트랜잭션을 처리하고 블록을 생성하는 데 자신들의 시간과 컴퓨팅 파워를 사용했습니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/#why-do-miners-exist) 채굴자는 왜 존재하나요? -------------------------------------------------------------------------------------------------------------- 이더리움과 같은 탈중앙화된 시스템에서는 모든 사람이 트랜잭션 순서에 동의하도록 보장해야 합니다. 채굴자들은 계산적으로 어려운 퍼즐을 풀어 블록을 생성함으로써 이를 돕고, 공격으로부터 네트워크를 보호했습니다. [작업증명 (PoW)에 대해 더 알아보기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/) 이전에는 누구나 자신의 컴퓨터를 사용하여 이더리움 네트워크에서 채굴할 수 있었습니다. 하지만 모든 사람이 이더(ETH)를 수익성 있게 채굴할 수 있는 것은 아니었습니다. 대부분의 경우, 채굴자들은 전용 컴퓨터 하드웨어를 구매하고 저렴한 에너지원에 접근할 수 있어야 했습니다. 일반적인 컴퓨터로는 채굴과 관련된 비용을 충당할 만큼 충분한 블록 보상을 얻기 어려웠습니다. ### [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/#cost-of-mining) 채굴 비용 * 채굴기를 구축하고 유지하는 데 필요한 하드웨어의 잠재적 비용 * 채굴기를 가동하는 데 드는 전기 비용 * 풀(pool)에서 채굴하는 경우, 이러한 풀은 일반적으로 풀에서 생성된 각 블록에 대해 고정된 비율(%)의 수수료를 부과했습니다. * 채굴기를 지원하기 위한 장비의 잠재적 비용 (환기, 에너지 모니터링, 전기 배선 등) 채굴 수익성을 더 자세히 알아보려면 [Etherscan (새 탭에서 열림)](https://etherscan.io/ether-mining-calculator) 에서 제공하는 것과 같은 채굴 계산기를 사용해 보세요. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/#how-ethereum-transactions-were-mined) 이더리움 트랜잭션이 채굴된 방법 ----------------------------------------------------------------------------------------------------------------------------------- 다음은 이더리움 작업증명에서 트랜잭션이 어떻게 채굴되었는지에 대한 개요를 제공합니다. 이더리움 지분 증명에 대한 이 과정의 유사한 설명은 [여기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) 에서 찾을 수 있습니다. 1. 사용자가 특정 [계정](https://ethereum.org/ko/developers/docs/accounts/) 의 개인 키로 [트랜잭션](https://ethereum.org/ko/developers/docs/transactions/) 요청을 작성하고 서명합니다. 2. 사용자는 특정 [노드](https://ethereum.org/ko/developers/docs/nodes-and-clients/) 에서 전체 이더리움 네트워크로 트랜잭션 요청을 브로드캐스트합니다. 3. 새로운 트랜잭션 요청을 수신하면, 이더리움 네트워크의 각 노드는 해당 요청을 로컬 멤풀에 추가합니다. 멤풀은 수신했지만 아직 블록체인의 블록에 커밋되지 않은 모든 트랜잭션 요청의 목록입니다. 4. 어느 시점에서 채굴 노드는 수십 또는 수백 개의 트랜잭션 요청을 잠재적인 [블록](https://ethereum.org/ko/developers/docs/blocks/) 으로 집계합니다. 이때 블록 가스 한도를 초과하지 않으면서 자신이 얻는 [트랜잭션 수수료](https://ethereum.org/ko/developers/docs/gas/) 를 극대화하는 방식으로 진행합니다. 그런 다음 채굴 노드는 다음을 수행합니다. 1. 각 트랜잭션 요청의 유효성을 검증하고(예: 서명하지 않은 계정에서 이더를 전송하려고 시도하지 않는지, 요청 형식이 잘못되지 않았는지 등), 요청의 코드를 실행하여 로컬 EVM 복사본의 상태를 변경합니다. 채굴자는 이러한 각 트랜잭션 요청에 대한 트랜잭션 수수료를 자신의 계정에 부여합니다. 2. 블록 내의 모든 트랜잭션 요청이 로컬 EVM 복사본에서 검증되고 실행되면, 잠재적 블록에 대한 작업증명 "적법성 증명서(certificate of legitimacy)"를 생성하는 과정을 시작합니다. 5. 결국 채굴자는 우리의 특정 트랜잭션 요청이 포함된 블록에 대한 증명서 생성을 완료하게 됩니다. 그런 다음 채굴자는 증명서와 주장하는 새로운 EVM 상태의 체크섬이 포함된 완성된 블록을 브로드캐스트합니다. 6. 다른 노드들은 새로운 블록에 대해 수신합니다. 이들은 증명서를 검증하고, 블록의 모든 트랜잭션을 직접 실행하며(사용자가 원래 브로드캐스트한 트랜잭션 포함), 모든 트랜잭션 실행 후 새로운 EVM 상태의 체크섬이 채굴자의 블록이 주장하는 상태의 체크섬과 일치하는지 확인합니다. 그런 다음에야 이 노드들은 이 블록을 자신들의 블록체인 끝에 추가하고, 새로운 EVM 상태를 정식 상태로 수락합니다. 7. 각 노드는 미처리 트랜잭션 요청의 로컬 멤풀에서 새 블록에 포함된 모든 트랜잭션을 제거합니다. 8. 네트워크에 새로 참여하는 노드들은 우리가 관심 있는 트랜잭션이 포함된 블록을 포함하여 모든 블록을 순서대로 다운로드합니다. 이들은 로컬 EVM 복사본(빈 상태의 EVM으로 시작)을 초기화한 다음, 로컬 EVM 복사본 위에서 모든 블록의 모든 트랜잭션을 실행하는 과정을 거치며, 그 과정에서 각 블록의 상태 체크섬을 검증합니다. 모든 트랜잭션은 한 번 채굴되지만(새 블록에 포함되어 처음으로 전파됨), 정식 EVM 상태를 진행하는 과정에서 모든 참여자에 의해 실행되고 검증됩니다. 이는 블록체인의 핵심 만트라 중 하나를 강조합니다: **신뢰하지 말고, 검증하라(Don’t trust, verify)**. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/#ommer-blocks) 오머 (엉클) 블록 ---------------------------------------------------------------------------------------------------- 작업증명에서의 블록 채굴은 확률적이었으며, 이는 네트워크 지연으로 인해 때때로 두 개의 유효한 블록이 동시에 게시될 수 있음을 의미했습니다. 이 경우 프로토콜은 가장 긴(따라서 가장 "유효한") 체인을 결정하는 동시에, 제안되었으나 포함되지 않은 유효한 블록에 부분적으로 보상을 제공하여 채굴자에 대한 공정성을 보장해야 했습니다. 이는 더 큰 지연에 직면할 수 있는 소규모 채굴자들도 보상을 통해 수익을 창출할 수 있게 함으로써 네트워크의 탈중앙화를 더욱 촉진했습니다. "오머(ommer)"라는 용어는 부모 블록의 형제 블록을 지칭하는 성중립적인 용어로 선호되지만, 때로는 "엉클(uncle)"이라고도 불립니다. **이더리움이 지분 증명으로 전환한 이후, 각 슬롯에서 단 한 명의 제안자만 선출되므로 오머 (엉클) 블록은 더 이상 채굴되지 않습니다.** 채굴된 오머 (엉클) 블록의 [과거 차트 (새 탭에서 열림)](https://ycharts.com/indicators/ethereum_uncle_rate) 를 보면 이러한 변화를 확인할 수 있습니다. [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/#a-visual-demo) 시각적 데모 ------------------------------------------------------------------------------------------------- Austin이 채굴과 작업증명 블록체인에 대해 설명하는 영상을 시청해 보세요. ### Blockchain — ETH.BUILD A demonstration of how blockchain mining works, including how blocks are chained together, how proof of work secures blockchains, and what happens when someone tries to tamper with data. [대본과 함께 시청하기](https://ethereum.org/ko/videos/blockchain-eth-build/)   [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/#mining-algorithm) 채굴 알고리즘 ----------------------------------------------------------------------------------------------------- 이더리움 메인넷은 오직 하나의 채굴 알고리즘인 ['이더해시'](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/) 만을 사용했습니다. 이더해시는 ['Dagger-Hashimoto'](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/) 로 알려진 초기 R&D 알고리즘의 후속 버전이었습니다. [채굴 알고리즘에 대해 더 알아보기](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/) . [](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/mining/#related-topics) 관련 주제 ------------------------------------------------------------------------------------------------- * [가스](https://ethereum.org/ko/developers/docs/gas/) * [EVM](https://ethereum.org/ko/developers/docs/evm/) * [작업증명 (PoW)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pow/) --- # 이더리움 기술 소개 | ethereum.org [본문으로 건너뛰기](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#main-content) Change page 이더리움 기술 소개 ========== .md 복사.md 복사 [페이지 편집 (새 탭에서 열림)](https://github.com/ethereum/ethereum-org-website/tree/dev/public/content/developers/docs/intro-to-ethereum/index.md) 이 페이지의 내용 [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#what-is-a-blockchain) 블록체인이란 무엇인가요? ------------------------------------------------------------------------------------------------- 블록체인은 네트워크의 여러 컴퓨터에 걸쳐 업데이트되고 공유되는 퍼블릭 데이터베이스입니다. "블록"은 데이터와 상태가 "블록"이라고 알려진 연속적인 그룹에 저장되는 것을 의미합니다. 다른 사람에게 ETH를 전송하는 경우, 트랜잭션 데이터가 블록에 추가되어야 성공적으로 처리됩니다. "체인"은 각 블록이 암호학적으로 부모 블록을 참조한다는 사실을 의미합니다. 즉, 블록들이 서로 연결되어 체인을 형성합니다. 블록 내의 데이터는 이후의 모든 블록을 변경하지 않고는 바꿀 수 없으며, 이를 위해서는 전체 네트워크의 합의가 필요합니다. 네트워크의 모든 컴퓨터는 각각의 새로운 블록과 전체 체인에 대해 합의해야 합니다. 이러한 컴퓨터를 "노드"라고 합니다. 노드는 블록체인과 상호작용하는 모든 사람이 동일한 데이터를 갖도록 보장합니다. 이러한 분산된 합의를 달성하기 위해 블록체인에는 합의 메커니즘이 필요합니다. [이더리움](https://ethereum.org/ko/) 은 [지분 증명(PoS) 기반 합의 메커니즘](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/) 을 사용합니다. 체인에 새로운 블록을 추가하려는 사람은 누구나 이더리움의 기본 통화인 ETH를 담보로 스테이킹하고 검증자 소프트웨어를 실행해야 합니다. 그런 다음 이 "검증자"들은 무작위로 선택되어 블록을 제안할 수 있으며, 다른 검증자들이 이를 확인하고 블록체인에 추가합니다. 참여자들이 최대한 정직하게 행동하고 온라인 상태를 유지하도록 강력하게 장려하는 보상 및 페널티 시스템이 존재합니다. 블록체인 데이터가 어떻게 해시되고 이후 블록 참조 기록에 추가되는지 확인하고 싶다면, Anders Brownworth의 [이 데모 (새 탭에서 열림)](https://andersbrownworth.com/blockchain/blockchain) 를 확인하고 아래의 관련 영상을 시청해 보세요. 블록체인의 해시에 대한 Anders의 설명을 시청하세요: ### Blockchain 101: a visual demo A demonstration of how blockchain technology works, covering hashing, blocks, chains, distributed ledgers, and tokens to make blockchain concepts tangible and intuitive. [대본과 함께 시청하기](https://ethereum.org/ko/videos/blockchain-101-visual-demo/)   [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#what-is-ethereum) 이더리움이란 무엇인가요? --------------------------------------------------------------------------------------------- 이더리움은 컴퓨터가 내장된 블록체인입니다. 이는 탈중앙화되고 무허가성이며 검열에 저항하는 방식으로 앱과 조직을 구축하기 위한 기반입니다. 이더리움 생태계에는 이더리움 네트워크의 모든 사람이 상태에 동의하는 단일한 표준 컴퓨터(이더리움 가상 머신, 또는 EVM)가 존재합니다. 이더리움 네트워크에 참여하는 모든 사람(모든 이더리움 노드)은 이 컴퓨터 상태의 사본을 보관합니다. 또한, 모든 참여자는 이 컴퓨터가 임의의 연산을 수행하도록 요청을 브로드캐스트할 수 있습니다. 이러한 요청이 브로드캐스트될 때마다 네트워크의 다른 참여자들은 연산을 검증, 확인 및 수행("실행")합니다. 이 실행은 EVM에 상태 변경을 일으키며, 이는 전체 네트워크에 커밋되고 전파됩니다. 연산 요청을 트랜잭션 요청이라고 합니다. 모든 트랜잭션의 기록과 EVM의 현재 상태는 블록체인에 저장되며, 이는 다시 모든 노드에 의해 저장되고 합의됩니다. 암호학적 메커니즘은 트랜잭션이 유효한 것으로 검증되어 블록체인에 추가되면 나중에 조작될 수 없도록 보장합니다. 동일한 메커니즘은 또한 모든 트랜잭션이 적절한 "권한"을 가지고 서명되고 실행되도록 보장합니다(Alice 본인을 제외하고는 누구도 Alice의 계정에서 디지털 자산을 전송할 수 없어야 합니다). [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#what-is-ether) 이더란 무엇인가요? --------------------------------------------------------------------------------------- **이더(ETH)**는 이더리움의 기본 암호화폐입니다. ETH의 목적은 연산을 위한 시장을 형성하는 것입니다. 이러한 시장은 참여자들이 트랜잭션 요청을 검증 및 실행하고 네트워크에 컴퓨팅 리소스를 제공하도록 경제적 인센티브를 제공합니다. 트랜잭션 요청을 브로드캐스트하는 모든 참여자는 네트워크에 일정량의 ETH를 포상금으로 제공해야 합니다. 네트워크는 포상금의 일부를 소각하고, 나머지는 최종적으로 트랜잭션을 검증하고, 실행하며, 블록체인에 커밋하고, 네트워크에 브로드캐스트하는 작업을 수행한 사람에게 보상으로 지급합니다. 지불되는 ETH의 양은 연산을 수행하는 데 필요한 리소스에 비례합니다. 이러한 포상금은 악의적인 참여자가 무한 연산이나 기타 리소스 집약적인 스크립트의 실행을 요청하여 의도적으로 네트워크를 막히게 하는 것을 방지하기도 합니다. 이러한 참여자들은 연산 리소스에 대한 비용을 지불해야 하기 때문입니다. ETH는 또한 세 가지 주요 방식을 통해 네트워크에 암호경제적 보안을 제공하는 데 사용됩니다. 1) 블록을 제안하거나 다른 검증자의 부정직한 행동을 지적하는 검증자에게 보상하는 수단으로 사용됩니다. 2) 검증자에 의해 스테이킹되어 부정직한 행동에 대한 담보 역할을 합니다. 검증자가 잘못된 행동을 시도하면 그들의 ETH는 파괴될 수 있습니다. 3) 새로 제안된 블록에 대한 '투표'의 가중치를 부여하는 데 사용되어 합의 메커니즘의 포크 선택 부분에 반영됩니다. [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#what-are-smart-contracts) 스마트 컨트랙트란 무엇인가요? -------------------------------------------------------------------------------------------------------- 실제로 참여자들은 EVM에 연산을 요청할 때마다 새로운 코드를 작성하지 않습니다. 대신, 애플리케이션 개발자가 프로그램(재사용 가능한 코드 조각)을 EVM 상태에 업로드하고, 사용자는 다양한 매개변수를 사용하여 이 코드 조각을 실행하도록 요청합니다. 우리는 네트워크에 업로드되고 실행되는 프로그램을 "스마트 컨트랙트"라고 부릅니다. 가장 기본적인 수준에서 스마트 컨트랙트를 일종의 자판기라고 생각할 수 있습니다. 특정 매개변수와 함께 호출될 때 특정 조건이 충족되면 일부 작업이나 연산을 수행하는 스크립트입니다. 예를 들어, 간단한 판매자 스마트 컨트랙트는 호출자가 특정 수신자에게 ETH를 전송하면 디지털 자산을 생성하고 소유권을 할당할 수 있습니다. 모든 개발자는 네트워크에 수수료를 지불하고 블록체인을 데이터 레이어로 사용하여 스마트 컨트랙트를 생성하고 네트워크에 공개할 수 있습니다. 그러면 모든 사용자는 네트워크에 수수료를 지불하고 스마트 컨트랙트를 호출하여 해당 코드를 실행할 수 있습니다. 따라서 스마트 컨트랙트를 통해 개발자는 마켓플레이스, 금융 상품, 게임 등과 같이 임의로 복잡한 사용자 대면 앱과 서비스를 구축하고 배포할 수 있습니다. [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#terminology) 용어 ----------------------------------------------------------------------------- ### [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#blockchain) 블록체인 네트워크 역사상 이더리움 네트워크에 커밋된 모든 블록의 시퀀스입니다. 각 블록이 이전 블록에 대한 참조를 포함하고 있어 모든 블록(결과적으로 정확한 기록)에 대한 순서를 유지하는 데 도움이 되기 때문에 이렇게 명명되었습니다. ### [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#eth) ETH **이더(ETH)**는 이더리움의 기본 암호화폐입니다. 사용자는 코드 실행 요청을 처리하기 위해 다른 사용자에게 ETH를 지불합니다. [ETH에 대해 더 알아보기](https://ethereum.org/ko/developers/docs/intro-to-ether/) ### [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#evm) EVM 이더리움 가상 머신(Ethereum Virtual Machine)은 이더리움 네트워크의 모든 참여자가 상태를 저장하고 합의하는 글로벌 가상 컴퓨터입니다. 모든 참여자는 EVM에서 임의의 코드 실행을 요청할 수 있으며, 코드 실행은 EVM의 상태를 변경합니다. [EVM에 대해 더 알아보기](https://ethereum.org/ko/developers/docs/evm/) ### [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#nodes) 노드 EVM 상태를 저장하는 실제 머신입니다. 노드는 서로 통신하여 EVM 상태 및 새로운 상태 변경에 대한 정보를 전파합니다. 모든 사용자는 노드에서 코드 실행 요청을 브로드캐스트하여 코드 실행을 요청할 수도 있습니다. 이더리움 네트워크 자체는 모든 이더리움 노드와 그 통신의 집합체입니다. [노드에 대해 더 알아보기](https://ethereum.org/ko/developers/docs/nodes-and-clients/) ### [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#accounts) 계정 ETH가 저장되는 곳입니다. 사용자는 계정을 초기화하고, 계정에 ETH를 입금하며, 자신의 계정에서 다른 사용자에게 ETH를 전송할 수 있습니다. 계정과 계정 잔액은 EVM의 큰 테이블에 저장되며, 전체 EVM 상태의 일부입니다. [계정에 대해 더 알아보기](https://ethereum.org/ko/developers/docs/accounts/) ### [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#transactions) 트랜잭션 "트랜잭션 요청"은 EVM에서의 코드 실행 요청을 뜻하는 공식 용어이며, "트랜잭션"은 완료된 트랜잭션 요청과 그에 따른 EVM 상태의 변경을 의미합니다. 모든 사용자는 노드에서 네트워크로 트랜잭션 요청을 브로드캐스트할 수 있습니다. 트랜잭션 요청이 합의된 EVM 상태에 영향을 미치려면 다른 노드에 의해 검증되고, 실행되며, "네트워크에 커밋"되어야 합니다. 모든 코드의 실행은 EVM에 상태 변경을 일으키며, 커밋 시 이 상태 변경은 네트워크의 모든 노드에 브로드캐스트됩니다. 트랜잭션의 몇 가지 예는 다음과 같습니다. * 내 계정에서 Alice의 계정으로 X ETH를 전송합니다. * 일부 스마트 컨트랙트 코드를 EVM 상태에 게시합니다. * EVM의 주소 X에 있는 스마트 컨트랙트 코드를 인수 Y와 함께 실행합니다. [트랜잭션에 대해 더 알아보기](https://ethereum.org/ko/developers/docs/transactions/) ### [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#blocks) 블록 트랜잭션의 양이 매우 많기 때문에 트랜잭션은 일괄 처리, 즉 블록 단위로 "커밋"됩니다. 블록은 일반적으로 수십에서 수백 개의 트랜잭션을 포함합니다. [블록에 대해 더 알아보기](https://ethereum.org/ko/developers/docs/blocks/) ### [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#smart-contracts) 스마트 컨트랙트 개발자가 EVM 상태에 게시하는 재사용 가능한 코드 조각(프로그램)입니다. 누구나 트랜잭션 요청을 통해 스마트 컨트랙트 코드가 실행되도록 요청할 수 있습니다. 개발자는 스마트 컨트랙트를 게시하여 EVM에 임의의 실행 가능한 애플리케이션(게임, 마켓플레이스, 금융 상품 등)을 작성할 수 있기 때문에, 이를 종종 [탈중앙화 애플리케이션(dapp)](https://ethereum.org/ko/developers/docs/dapps/) 이라고도 부릅니다. [스마트 컨트랙트에 대해 더 알아보기](https://ethereum.org/ko/developers/docs/smart-contracts/) [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#where-to-go-next) 다음 단계 ------------------------------------------------------------------------------------- 대부분의 독자는 순서대로 문서를 읽지만, 가장 빠른 경로는 여러분이 구축하려는 것에 따라 다릅니다. * **이더리움과 상호작용하는 dapp:** [계정](https://ethereum.org/ko/developers/docs/accounts/) 과 [트랜잭션](https://ethereum.org/ko/developers/docs/transactions/) 을 살펴본 후 [프레임워크](https://ethereum.org/ko/developers/docs/frameworks/) 를 선택하세요. * **스마트 컨트랙 개발:** [스마트 컨트랙트](https://ethereum.org/ko/developers/docs/smart-contracts/) 와 [프로그래밍 언어](https://ethereum.org/ko/developers/docs/programming-languages/) 를 살펴보세요. * **노드 및 스테이킹:** [노드 및 클라이언트](https://ethereum.org/ko/developers/docs/nodes-and-clients/) 를 살펴본 후 [합의 메커니즘](https://ethereum.org/ko/developers/docs/consensus-mechanisms/) 을 살펴보세요. [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#further-reading) 추가 읽을거리 -------------------------------------------------------------------------------------- * [이더리움 백서](https://ethereum.org/ko/whitepaper/) * [이더리움은 도대체 어떻게 작동하나요? (새 탭에서 열림)](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasireddy_ (**참고:** 이 자료는 여전히 유용하지만 [머지](https://ethereum.org/ko/roadmap/merge/) 이전에 작성되었으므로 여전히 이더리움의 작업증명(PoW) 메커니즘을 언급하고 있다는 점에 유의하세요. 현재 이더리움은 실제로 [지분 증명(PoS)](https://ethereum.org/ko/developers/docs/consensus-mechanisms/pos/) 을 사용하여 보호됩니다.) ### [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#visual-learner) 시각적인 학습을 선호하시나요? 이 비디오 시리즈는 기초적인 주제에 대한 철저한 탐구를 제공합니다: ### Ethereum basics: intro An introductory lecture on Ethereum fundamentals, covering what Ethereum is, how it differs from Bitcoin, and the core concepts that underpin the Ethereum network. [대본과 함께 시청하기](https://ethereum.org/ko/videos/ethereum-basics-intro/)   [이더리움 기초 재생 목록 (새 탭에서 열림)](https://youtube.com/playlist?list=PLqgutSGloqiJyyoL0zvLVFPS-GMD2wKa5&si=kZTf5I7PKGTXDsOZ) _도움이 된 커뮤니티 리소스를 알고 계신가요? 이 페이지를 편집하여 추가해 주세요!_ [](https://ethereum.org/ko/developers/docs/intro-to-ethereum/#related-tutorials) 관련 튜토리얼 ---------------------------------------------------------------------------------------- * [개발자를 위한 이더리움 가이드, 파트 1](https://ethereum.org/ko/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– Python과 web3.py를 사용한 매우 초보자 친화적인 이더리움 탐구_ ---