From 36bff95e1a8a20584f8158021b4789eec83b83fd Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sat, 14 Feb 2026 00:03:38 +0000 Subject: [PATCH 1/2] i18n(ko): translation import part 04 of 13 (23 files) --- .../data-structures-and-encoding/ssz/index.md | 149 ++++++++++++ .../web3-secret-storage/index.md | 195 ++++++++++++++++ .../dex-design-best-practice/index.md | 220 +++++++++++++++++ .../heuristics-for-web3/index.md | 138 +++++++++++ .../ko/developers/docs/design-and-ux/index.md | 86 +++++++ .../docs/development-networks/index.md | 71 ++++++ .../developers/docs/ethereum-stack/index.md | 61 +++++ .../ko/developers/docs/evm/index.md | 88 +++++++ .../ko/developers/docs/evm/opcodes/index.md | 177 ++++++++++++++ .../ko/developers/docs/frameworks/index.md | 149 ++++++++++++ .../ko/developers/docs/gas/index.md | 151 ++++++++++++ .../ko/developers/docs/ides/index.md | 64 +++++ .../translations/ko/developers/docs/index.md | 25 ++ .../developers/docs/intro-to-ether/index.md | 78 +++++++ .../docs/intro-to-ethereum/index.md | 124 ++++++++++ .../ko/developers/docs/mev/index.md | 221 ++++++++++++++++++ .../developers/docs/networking-layer/index.md | 155 ++++++++++++ .../network-addresses/index.md | 39 ++++ .../networking-layer/portal-network/index.md | 89 +++++++ .../ko/developers/docs/networks/index.md | 216 +++++++++++++++++ .../nodes-and-clients/archive-nodes/index.md | 81 +++++++ .../docs/nodes-and-clients/bootnodes/index.md | 31 +++ .../client-diversity/index.md | 132 +++++++++++ 23 files changed, 2740 insertions(+) create mode 100644 public/content/translations/ko/developers/docs/data-structures-and-encoding/ssz/index.md create mode 100644 public/content/translations/ko/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md create mode 100644 public/content/translations/ko/developers/docs/design-and-ux/dex-design-best-practice/index.md create mode 100644 public/content/translations/ko/developers/docs/design-and-ux/heuristics-for-web3/index.md create mode 100644 public/content/translations/ko/developers/docs/design-and-ux/index.md create mode 100644 public/content/translations/ko/developers/docs/development-networks/index.md create mode 100644 public/content/translations/ko/developers/docs/ethereum-stack/index.md create mode 100644 public/content/translations/ko/developers/docs/evm/index.md create mode 100644 public/content/translations/ko/developers/docs/evm/opcodes/index.md create mode 100644 public/content/translations/ko/developers/docs/frameworks/index.md create mode 100644 public/content/translations/ko/developers/docs/gas/index.md create mode 100644 public/content/translations/ko/developers/docs/ides/index.md create mode 100644 public/content/translations/ko/developers/docs/index.md create mode 100644 public/content/translations/ko/developers/docs/intro-to-ether/index.md create mode 100644 public/content/translations/ko/developers/docs/intro-to-ethereum/index.md create mode 100644 public/content/translations/ko/developers/docs/mev/index.md create mode 100644 public/content/translations/ko/developers/docs/networking-layer/index.md create mode 100644 public/content/translations/ko/developers/docs/networking-layer/network-addresses/index.md create mode 100644 public/content/translations/ko/developers/docs/networking-layer/portal-network/index.md create mode 100644 public/content/translations/ko/developers/docs/networks/index.md create mode 100644 public/content/translations/ko/developers/docs/nodes-and-clients/archive-nodes/index.md create mode 100644 public/content/translations/ko/developers/docs/nodes-and-clients/bootnodes/index.md create mode 100644 public/content/translations/ko/developers/docs/nodes-and-clients/client-diversity/index.md diff --git a/public/content/translations/ko/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/ko/developers/docs/data-structures-and-encoding/ssz/index.md new file mode 100644 index 00000000000..eac06dc2158 --- /dev/null +++ b/public/content/translations/ko/developers/docs/data-structures-and-encoding/ssz/index.md @@ -0,0 +1,149 @@ +--- +title: "간단 직렬화" +description: "이더리움의 SSZ 형식에 대한 설명입니다." +lang: ko +sidebarDepth: 2 +--- + +\*\*간단 직렬화(SSZ)\*\*는 비콘 체인에서 사용되는 직렬화 방법입니다. 피어 검색 프로토콜을 제외하고 합의 레이어 전반의 실행 레이어에서 사용되는 RLP 직렬화를 대체합니다. RLP 직렬화에 대해 자세히 알아보려면 [재귀 길이 접두사(RLP)](/developers/docs/data-structures-and-encoding/rlp/)를 참조하세요. SSZ는 결정론적이며 효율적으로 머클화되도록 설계되었습니다. SSZ는 직렬화 방식과 직렬화된 데이터 구조와 효율적으로 작동하도록 설계된 머클화 방식의 두 가지 구성 요소를 갖는 것으로 생각할 수 있습니다. + +## SSZ는 어떻게 작동하나요? {#how-does-ssz-work} + +### 직렬화 {#serialization} + +SSZ는 자체 서술적이지 않은 직렬화 방식이며, 사전에 알려져야 하는 스키마에 의존합니다. SSZ 직렬화의 목표는 임의의 복잡성을 가진 객체를 바이트 문자열로 표현하는 것입니다. 이는 "기본 유형"에 대한 매우 간단한 프로세스입니다. 요소는 단순히 16진수 바이트로 변환됩니다. 기본 유형은 다음과 같습니다. + +- 부호 없는 정수 +- 불리언 + +복잡한 "복합" 유형의 경우, 복합 유형에 유형이나 크기가 다르거나 둘 다 다른 여러 요소가 포함되어 있으므로 직렬화가 더 복잡합니다. 이러한 객체가 모두 고정된 길이(즉, 요소의 크기가 실제 값에 관계없이 항상 일정함)를 갖는 경우 직렬화는 단순히 복합 유형의 각 요소를 리틀엔디언 바이트 문자열로 순서대로 변환하는 것입니다. 이러한 바이트 문자열은 함께 결합됩니다. 직렬화된 객체는 역직렬화된 객체에 나타나는 것과 동일한 순서로 고정 길이 요소의 바이트 목록 표현을 가집니다. + +가변 길이 유형의 경우, 실제 데이터는 직렬화된 객체의 해당 요소 위치에 있는 "오프셋" 값으로 대체됩니다. 실제 데이터는 직렬화된 객체의 끝에 있는 힙에 추가됩니다. 오프셋 값은 힙에 있는 실제 데이터의 시작 인덱스로, 관련 바이트에 대한 포인터 역할을 합니다. + +아래 예는 고정 및 가변 길이 요소를 모두 포함하는 컨테이너에 대한 오프셋 작동 방식을 보여줍니다. + +```Rust + + 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) + +``` + +`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의 number3 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`의 실제 값. +] +``` + +이것은 여전히 단순화된 것입니다. 위의 도식에 있는 정수와 0은 실제로는 다음과 같이 바이트 목록으로 저장됩니다. + +``` +[ + 10100101000000000000000000000000 # `number1`의 리틀엔디언 인코딩 + 10110111000000000000000000000000 # `number2`의 리틀엔디언 인코딩. + 10010000000000000000000000000000 # `vector` 값의 시작 위치를 나타내는 "오프셋"(리틀엔디언 16). + 10010110000000000000000000000000 # `number3`의 리틀엔디언 인코딩. + 10000001100000101000001110000100 # `bytes` 필드의 실제 값. +] +``` + +따라서 가변 길이 유형의 실제 값은 직렬화된 객체의 끝에 있는 힙에 저장되며, 오프셋은 정렬된 필드 목록의 올바른 위치에 저장됩니다. + +`BitList` 유형과 같이 직렬화 중에 길이 상한을 추가하고 역직렬화 중에 제거해야 하는 특정 처리가 필요한 몇 가지 특수한 경우도 있습니다. 전체 세부 정보는 [SSZ 사양](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md)에서 확인할 수 있습니다. + +### 역직렬화 {#deserialization} + +이 객체를 역직렬화하려면 스키마가 필요합니다. 스키마는 직렬화된 데이터의 정확한 레이아웃을 정의하여 각 특정 요소를 바이트 블롭에서 올바른 유형, 값, 크기 및 위치를 갖는 의미 있는 객체로 역직렬화할 수 있도록 합니다. 어떤 값이 실제 값이고 어떤 값이 오프셋인지를 역직렬화 프로그램에 알려주는 것이 바로 스키마입니다. 모든 필드 이름은 객체가 직렬화될 때 사라지지만, 스키마에 따라 역직렬화될 때 다시 인스턴스화됩니다. + +이에 대한 대화형 설명은 [ssz.dev](https://www.ssz.dev/overview)를 참조하세요. + +## 머클화 {#merkleization} + +그런 다음 이 SSZ 직렬화된 객체를 머클화할 수 있습니다. 즉, 동일한 데이터의 머클 트리 표현으로 변환할 수 있습니다. 먼저, 직렬화된 객체에서 32바이트 청크의 수를 결정합니다. 이것이 트리의 "리프"입니다. 리프를 함께 해싱하여 최종적으로 단일 해시 트리 루트를 생성할 수 있도록 총 리프 수는 2의 거듭제곱이어야 합니다. 자연스럽게 그렇지 않은 경우, 32바이트의 0을 포함하는 추가 리프가 추가됩니다. 도식적으로: + +``` + 해시 트리 루트 + / \ + / \ + / \ + / \ + 리프 1과 2의 해시 리프 3과 4의 해시 + / \ / \ + / \ / \ + / \ / \ + 리프1 리프2 리프3 리프4 +``` + +위의 예에서와 같이 트리의 리프가 자연스럽게 고르게 분포되지 않는 경우도 있습니다. 예를 들어, 리프 4는 머클 트리에 추가적인 "깊이"를 추가해야 하는 여러 요소를 가진 컨테이너일 수 있으며, 이로 인해 불균일한 트리가 생성됩니다. + +이러한 트리 요소를 리프 X, 노드 X 등으로 지칭하는 대신, 루트 = 1에서 시작하여 각 레벨을 따라 왼쪽에서 오른쪽으로 계산하는 일반화된 인덱스를 부여할 수 있습니다. 이것이 위에서 설명한 일반화된 인덱스입니다. 직렬화된 목록의 각 요소는 `2**depth + idx`와 같은 일반화된 인덱스를 가집니다. 여기서 idx는 직렬화된 객체에서 0부터 시작하는 위치이고, 깊이는 머클 트리의 레벨 수이며, 요소(리프) 수의 밑이 2인 로그로 결정될 수 있습니다. + +## 일반화된 인덱스 {#generalized-indices} + +일반화된 인덱스는 이진 머클 트리의 노드를 나타내는 정수이며, 각 노드는 `2 ** depth + 행의 인덱스`라는 일반화된 인덱스를 가집니다. + +``` + 1 --깊이 = 0 2**0 + 0 = 1 + 2 3 --깊이 = 1 2**1 + 0 = 2, 2**1+1 = 3 + 4 5 6 7 --깊이 = 2 2**2 + 0 = 4, 2**2 + 1 = 5... + +``` + +이 표현은 머클 트리의 각 데이터 조각에 대한 노드 인덱스를 산출합니다. + +## 다중 증명 {#multiproofs} + +특정 요소를 나타내는 일반화된 인덱스 목록을 제공하면 해시 트리 루트와 비교하여 이를 확인할 수 있습니다. 이 루트는 우리가 수용한 현실 버전입니다. 제공된 모든 데이터는 머클 트리의 올바른 위치(일반화된 인덱스에 의해 결정됨)에 삽입하고 루트가 일정하게 유지되는지 관찰함으로써 그 현실에 대해 검증될 수 있습니다. 사양에는 특정 일반화된 인덱스 세트의 내용을 확인하는 데 필요한 최소 노드 세트를 계산하는 방법을 보여주는 함수가 [여기](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs)에 있습니다. + +예를 들어, 아래 트리에서 인덱스 9의 데이터를 확인하려면 인덱스 8, 9, 5, 3, 1에 있는 데이터의 해시가 필요합니다. +(8,9)의 해시는 해시 (4)와 같아야 하며, 이는 5와 해싱되어 2를 생성하고, 이는 3과 해싱되어 트리 루트 1을 생성합니다. 9에 대해 잘못된 데이터가 제공되면 루트가 변경됩니다. 우리는 이를 감지하고 브랜치 확인에 실패할 것입니다. + +``` +* = 증명을 생성하는 데 필요한 데이터 + + 1* + 2 3* + 4 5* 6 7 +8* 9* 10 11 12 13 14 15 + +``` + +## 더 읽어보기 {#further-reading} + +- [이더리움 업그레이드: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) +- [이더리움 업그레이드: 머클화](https://eth2book.info/altair/part2/building_blocks/merkleization) +- [SSZ 구현](https://github.com/ethereum/consensus-specs/issues/2138) +- [SSZ 계산기](https://simpleserialize.com/) +- [SSZ.dev](https://www.ssz.dev/) diff --git a/public/content/translations/ko/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md b/public/content/translations/ko/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md new file mode 100644 index 00000000000..14cd52650cb --- /dev/null +++ b/public/content/translations/ko/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md @@ -0,0 +1,195 @@ +--- +title: "Web3 비밀 저장소 정의" +description: "웹3 비밀 저장 공간에 대한 공식적인 정의" +lang: ko +sidebarDepth: 2 +--- + +앱이 이더리움에서 작동하도록 하려면 web3.js 라이브러리에서 제공하는 웹3 객체를 사용할 수 있습니다. 내부적으로 RPC 호출을 통해 로컬 노드와 통신합니다. [web3](https://github.com/ethereum/web3.js/)는 RPC 레이어를 노출하는 모든 이더리움 노드와 함께 작동합니다. + +`web3`는 `eth` 객체(web3.eth)를 포함합니다. + +```js +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) +}) + +/** result + * [ 'web3', 3 ] 웹3(v3) 키 파일 + * [ 'ethersale', undefined ] Ethersale 키 파일 + * null 잘못된 키 파일 + */ +``` + +이 문서는 웹3 비밀 저장 공간 정의의 **버전 3**에 대한 내용입니다. + +## 정의 {#definition} + +파일의 실제 인코딩 및 디코딩은 버전 1과 거의 동일하지만, 암호화 알고리즘이 더 이상 AES-128-CBC로 고정되지 않는다는 점이 다릅니다(현재는 AES-128-CTR이 최소 요구 사항임). 대부분의 의미/알고리즘은 버전 1과 유사하지만 `mac`은 예외입니다. `mac`은 파생된 키의 왼쪽에서 두 번째 16바이트와 전체 `ciphertext`를 연결한 것의 SHA3(keccak-256)으로 지정됩니다. + +비밀 키 파일은 `~/.web3/keystore`(유닉스 계열 시스템의 경우) 및 `~/AppData/Web3/keystore`(윈도우의 경우)에 직접 저장됩니다. 이름은 무엇이든 될 수 있지만, `.json`이 좋은 규칙입니다. 여기서 ``는 비밀 키에 부여된 128비트 UUID(비밀 키 주소에 대한 개인정보 보호 프록시)입니다. + +이러한 모든 파일에는 연결된 비밀번호가 있습니다. 주어진 `.json` 파일의 비밀 키를 파생시키려면 먼저 파일의 암호화 키를 파생시켜야 합니다. 이 작업은 파일의 비밀번호를 가져와 `kdf` 키에 설명된 대로 키 파생 함수를 통해 전달하여 수행됩니다. KDF 함수에 대한 KDF 종속 정적 및 동적 파라미터는 `kdfparams` 키에 설명되어 있습니다. + +최소 준수 구현은 모두 PBKDF2를 지원해야 하며, 다음과 같이 표시됩니다. + +- `kdf`: `pbkdf2` + +PBKDF2의 경우, kdfparams는 다음을 포함합니다. + +- `prf`: `hmac-sha256`이어야 합니다(향후 확장될 수 있음). +- `c`: 반복 횟수, +- `salt`: PBKDF에 전달된 솔트, +- `dklen`: 파생된 키의 길이. 32 이상이어야 합니다. + +파일의 키가 파생되면 MAC 파생을 통해 확인해야 합니다. MAC은 파생된 키의 왼쪽에서 두 번째 16바이트와 `ciphertext` 키의 내용을 연결하여 형성된 바이트 배열의 SHA3(keccak-256) 해시로 계산되어야 합니다. 즉, + +```js +KECCAK(DK[16..31] ++ ) +``` + +(여기서 `++`는 연결 연산자입니다) + +이 값은 `mac` 키의 내용과 비교해야 합니다. 만약 값이 다르면 다른 비밀번호를 요청하거나 작업을 취소해야 합니다. + +파일의 키가 확인된 후, `cipher` 키로 지정되고 `cipherparams` 키를 통해 매개변수화된 대칭 암호화 알고리즘을 사용하여 암호문(`ciphertext` 키)을 복호화할 수 있습니다. 파생된 키 크기와 알고리즘의 키 크기가 일치하지 않는 경우, 파생된 키의 0으로 채워진 가장 오른쪽 바이트가 알고리즘의 키로 사용되어야 합니다. + +모든 최소 준수 구현은 AES-128-CTR 알고리즘을 지원해야 하며, 다음과 같이 표시됩니다. + +- `cipher: aes-128-ctr` + +이 암호는 cipherparams 키에 대한 키로 지정된 다음 매개변수를 사용합니다. + +- `iv`: 암호에 대한 128비트 초기화 벡터. + +암호의 키는 파생된 키의 가장 왼쪽 16바이트입니다(예: `DK[0..15]`) + +비밀 키의 생성/암호화는 기본적으로 이러한 지침의 역순이어야 합니다. `uuid`, `salt` 및 `iv`가 실제로 무작위인지 확인하십시오. + +버전의 "하드" 식별자 역할을 해야 하는 `version` 필드 외에도, 구현은 형식에 대한 더 작고 호환성을 깨뜨리지 않는 변경 사항을 추적하기 위해 `minorversion`을 사용할 수도 있습니다. + +## 테스트 벡터 {#test-vectors} + +세부 정보: + +- `주소`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b` +- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67` +- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6` +- `비밀번호`: `testpassword` +- `비밀`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d` + +### PBKDF2-SHA-256 {#PBKDF2-SHA-256} + +`AES-128-CTR` 및 `PBKDF2-SHA-256`을 사용한 테스트 벡터: + +`~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`의 파일 내용: + +```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 +} +``` + +**중간값**: + +`파생된 키`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` +`MAC 본문`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` +`MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` +`암호 키`: `f06d69cdc7da0faffb1008270bca38f5` + +### Scrypt {#scrypt} + +AES-128-CTR 및 Scrypt를 사용한 테스트 벡터: + +```json +{ + "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 +} +``` + +**중간값**: + +`파생된 키`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` +`MAC 본문`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` +`MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` +`암호 키`: `7446f59ecc301d2d79bc3302650d8a5c` + +## 버전 1의 변경 사항 {#alterations-from-v2} + +이 버전은 [여기](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`은 공백에 영향을 받지 않는 데이터 조각을 통해 계산됩니다(!). + +이전에 링크된 페이지의 예시와 기능적으로 동일한 다음 파일을 제공하기 위해 형식이 변경되었습니다. + +```json +{ + "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 +} +``` + +## 버전 2의 변경 사항 {#alterations-from-v2} + +버전 2는 여러 버그가 있는 초기 C++ 구현이었습니다. 모든 필수 요소는 그대로 유지됩니다. diff --git a/public/content/translations/ko/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/ko/developers/docs/design-and-ux/dex-design-best-practice/index.md new file mode 100644 index 00000000000..befda1745bf --- /dev/null +++ b/public/content/translations/ko/developers/docs/design-and-ux/dex-design-best-practice/index.md @@ -0,0 +1,220 @@ +--- +title: "탈중앙화 거래소(DEX) 디자인 모범 사례" +description: "토큰 교환을 위한 UX/UI 결정 사항을 설명하는 가이드입니다." +lang: ko +--- + +2018년 Uniswap 출시 이후 수십 개의 다른 체인에 걸쳐 수백 개의 탈중앙화 거래소가 출시되었습니다. +이들 중 다수는 새로운 요소를 도입하거나 고유한 특징을 추가했지만 인터페이스는 대체로 동일하게 유지되었습니다. + +그 이유 중 하나는 [제이콥의 법칙](https://lawsofux.com/jakobs-law/)입니다. + +> 사용자는 대부분의 시간을 다른 사이트에서 보냅니다. 이는 사용자가 자신의 사이트가 이미 알고 있는 다른 모든 사이트와 동일한 방식으로 작동하기를 선호한다는 것을 의미합니다. + +Uniswap, Pancakeswap, Sushiswap과 같은 초기 혁신가들 덕분에 디파이(DeFi) 사용자들은 DEX가 어떤 모습인지에 대한 집단적인 아이디어를 갖게 되었습니다. +이러한 이유로 '모범 사례'와 같은 것이 이제 막 나타나고 있습니다. 점점 더 많은 디자인 결정이 사이트 전반에 걸쳐 표준화되고 있음을 알 수 있습니다. DEX의 진화를 실시간 테스트의 거대한 예로 볼 수 있습니다. 효과가 있었던 것은 남고, 그렇지 않은 것은 버려졌습니다. 여전히 개성을 발휘할 여지는 있지만 DEX가 따라야 할 특정 표준이 있습니다. + +이 글은 다음에 대한 요약입니다. + +- 포함해야 할 사항 +- 최대한 사용하기 쉽게 만드는 방법 +- 디자인을 사용자 정의하는 주요 방법 + +모든 예시 와이어프레임은 실제 프로젝트를 기반으로 하지만 이 글을 위해 특별히 제작되었습니다. + +Figma 키트도 하단에 포함되어 있습니다. 자유롭게 사용하여 자신만의 와이어프레임 작업 속도를 높여보세요! + +## DEX의 기본 구조 {#basic-anatomy-of-a-dex} + +UI는 일반적으로 세 가지 요소를 포함합니다. + +1. 기본 양식 +2. 버튼 +3. 세부 정보 패널 + +![세 가지 주요 요소를 보여주는 일반적인 DEX UI](./1.png) + +## 변형 {#variations} + +이는 이 글에서 공통적인 주제이지만, 이러한 요소들을 구성하는 방법에는 여러 가지가 있습니다. '세부 정보 패널'은 다음과 같을 수 있습니다. + +- 버튼 위 +- 버튼 아래 +- 아코디언 패널에 숨김 +- 그리고/또는 '미리보기' 모달에 표시 + +참고 '미리보기' 모달은 선택 사항이지만, 메인 UI에 아주 적은 세부 정보만 표시하는 경우 필수적입니다. + +## 메인 양식의 구조 {#structure-of-the-main-form} + +이 상자는 실제로 교환하려는 토큰을 선택하는 곳입니다. 이 컴포넌트는 한 줄에 입력 필드와 작은 버튼으로 구성됩니다. + +DEX는 일반적으로 위 한 줄과 아래 한 줄에 추가 세부 정보를 표시하지만, 이는 다르게 구성할 수 있습니다. + +![위아래에 세부 정보 행이 있는 입력 행](./2.png) + +## 변형 {#variations2} + +여기에는 두 가지 UI 변형이 표시됩니다. 하나는 테두리가 전혀 없어 매우 개방적인 디자인을 만들고, 다른 하나는 입력 행에 테두리가 있어 해당 요소에 초점을 맞춥니다. + +![메인 양식의 두 가지 UI 변형](./3.png) + +이 기본 구조를 통해 **네 가지 핵심 정보**를 디자인에 표시할 수 있습니다. 각 모서리에 하나씩입니다. 상단/하단 행이 하나만 있는 경우, 두 개의 지점만 있습니다. + +디파이(DeFi)의 진화 과정에서 여기에 많은 다양한 것들이 포함되었습니다. + +## 포함할 핵심 정보 {#key-info-to-include} + +- 지갑 내 잔액 +- 최대 버튼 +- 법정 화폐 등가액 +- '받는' 금액에 대한 가격 영향 + +디파이(DeFi) 초기에는 법정 화폐 등가액이 종종 누락되었습니다. 어떤 종류의 웹3 프로젝트를 구축하든 법정 화폐 등가액을 표시하는 것이 필수적입니다. 사용자는 여전히 현지 통화로 생각하므로 실제 세계의 정신 모델과 일치시키기 위해 이를 포함해야 합니다. + +두 번째 필드(교환할 토큰을 선택하는 필드)에서는 입력 금액과 예상 출력 금액의 차이를 계산하여 법정 화폐 금액 옆에 가격 영향을 포함할 수도 있습니다. 이것은 포함하기에 매우 유용한 세부 정보입니다. + +백분율 버튼(예: 25%, 50%, 75%)은 유용한 기능일 수 있지만 더 많은 공간을 차지하고 더 많은 행동 유도를 추가하며 더 많은 정신적 부담을 줍니다. 백분율 슬라이더도 마찬가지입니다. 이러한 UI 결정 중 일부는 브랜드와 사용자 유형에 따라 달라집니다. + +추가 세부 정보는 메인 양식 아래에 표시할 수 있습니다. 이러한 유형의 정보는 대부분 전문 사용자를 위한 것이므로 다음 중 하나를 수행하는 것이 좋습니다. + +- 최대한 최소한으로 유지하거나, +- 아코디언 패널에 숨기기 + +![메인 양식의 모서리에 표시되는 세부 정보](./4.png) + +## 포함할 추가 정보 {#extra-info-to-include} + +- 토큰 가격 +- 슬리피지 +- 최소 수령액 +- 예상 출력 +- 가격 영향 +- 가스 비용 추정치 +- 기타 수수료 +- 주문 라우팅 + +논란의 여지가 있지만, 이러한 세부 정보 중 일부는 선택 사항일 수 있습니다. + +주문 라우팅은 흥미롭지만 대부분의 사용자에게는 큰 차이가 없습니다. + +일부 다른 세부 정보는 단순히 같은 내용을 다른 방식으로 다시 설명하는 것입니다. 예를 들어 '최소 수령액'과 '슬리피지'는 동전의 양면과 같습니다. 슬리피지를 1%로 설정한 경우, 수령할 수 있는 최소 금액 = 예상 출력 - 1%입니다. 일부 UI는 예상 금액, 최소 금액 및 슬리피지를 표시합니다... 유용하지만 과할 수 있습니다. + +어차피 대부분의 사용자는 기본 슬리피지를 그대로 둡니다. + +'가격 영향'은 '받는' 필드의 법정 화폐 등가액 옆 괄호 안에 표시되는 경우가 많습니다. 이것은 추가하기에 훌륭한 UX 세부 정보이지만, 여기에 표시된다면 아래에 다시 표시할 필요가 있을까요? 그리고 미리보기 화면에 또다시? + +많은 사용자(특히 소액을 교환하는 사용자)는 이러한 세부 정보에 신경 쓰지 않을 것입니다. 그들은 단순히 숫자를 입력하고 교환을 누를 것입니다. + +![일부 세부 정보는 동일한 내용을 보여줍니다](./5.png) + +정확히 어떤 세부 정보를 표시할지는 잠재고객과 앱이 어떤 느낌을 주기를 원하는지에 따라 달라집니다. + +세부 정보 패널에 슬리피지 허용치를 포함하는 경우, 여기에서 직접 편집할 수 있도록 해야 합니다. 이것은 '단축키'의 좋은 예입니다. 앱의 일반적인 사용성에 영향을 주지 않으면서 숙련된 사용자의 흐름을 가속화할 수 있는 깔끔한 UX 트릭입니다. + +![세부 정보 패널에서 슬리피지를 제어할 수 있습니다](./6.png) + +한 화면의 특정 정보 하나뿐만 아니라 전체 흐름에 대해 신중하게 생각하는 것이 좋습니다. +메인 양식에 숫자 입력 → 세부 정보 스캔 → 미리보기 화면으로 클릭(미리보기 화면이 있는 경우). +세부 정보 패널을 항상 표시해야 할까요, 아니면 사용자가 확장하려면 클릭해야 할까요? +미리보기 화면을 추가하여 마찰을 만들어야 할까요? 이는 사용자가 속도를 늦추고 거래를 고려하도록 강제하는데, 이는 유용할 수 있습니다. 하지만 그들은 모든 동일한 정보를 다시 보고 싶어할까요? 이 시점에서 그들에게 가장 유용한 것은 무엇일까요? + +## 디자인 옵션 {#design-options} + +앞서 언급했듯이, 이 중 많은 부분이 개인 스타일에 달려 있습니다 +사용자는 누구입니까? +당신의 브랜드는 무엇입니까? +모든 세부 정보를 보여주는 '전문가용' 인터페이스를 원하십니까, 아니면 미니멀리스트를 원하십니까? +가능한 모든 정보를 원하는 전문 사용자를 목표로 하더라도 Alan Cooper의 현명한 말을 기억해야 합니다. + +> 인터페이스가 아무리 아름답고 멋지더라도, 적을수록 좋습니다. + +### 구조 {#structure} + +- 토큰을 왼쪽에, 또는 토큰을 오른쪽에 +- 2행 또는 3행 +- 버튼 위 또는 아래의 세부 정보 +- 세부 정보 확장, 최소화 또는 표시 안 함 + +### 구성 요소 스타일 {#component-style} + +- 비어 있음 +- 윤곽선 +- 채워짐 + +순수한 UX 관점에서 볼 때 UI 스타일은 생각보다 덜 중요합니다. 시각적 트렌드는 주기를 그리며 나타났다 사라지며, 선호도 중 상당 부분은 주관적입니다. + +이에 대한 감을 잡고 다양한 구성을 생각해 보는 가장 쉬운 방법은 몇 가지 예를 살펴본 다음 직접 실험해 보는 것입니다. + +포함된 Figma 키트에는 비어 있거나, 윤곽선이 있거나, 채워진 구성 요소가 포함되어 있습니다. + +아래 예시를 보고 모든 것을 종합할 수 있는 다양한 방법을 확인하세요. + +![채워진 스타일의 3행](./7.png) + +![윤곽선 스타일의 3행](./8.png) + +![빈 스타일의 2행](./9.png) + +![윤곽선 스타일의 3행, 세부 정보 패널 포함](./10.png) + +![윤곽선 스타일의 입력 행이 있는 3행](./11.png) + +![채워진 스타일의 2행](./12.png) + +## 하지만 토큰은 어느 쪽에 있어야 할까요? {#but-which-side-should-the-token-go-on} + +결론은 사용성에 큰 차이를 만들지 않을 것이라는 점입니다. 그러나 한쪽으로 기울게 할 수 있는 몇 가지 명심해야 할 사항이 있습니다. + +시간이 지남에 따라 유행이 변하는 것을 보는 것은 약간 흥미로웠습니다. Uniswap은 처음에 토큰을 왼쪽에 두었지만, 이후 오른쪽으로 옮겼습니다. Sushiswap도 디자인 업그레이드 중에 이 변경을 했습니다. 전부는 아니지만 대부분의 프로토콜이 그 뒤를 따랐습니다. + +금융 관례상 전통적으로 통화 기호를 숫자 앞에 둡니다(예: $50, €50, £50). 하지만 우리는 50달러, 50유로, 50파운드라고 _말합니다_. + +일반 사용자, 특히 왼쪽에서 오른쪽으로, 위에서 아래로 읽는 사람에게는 오른쪽에 있는 토큰이 아마도 더 자연스럽게 느껴질 것입니다. + +![토큰이 왼쪽에 있는 UI](./13.png) + +토큰을 왼쪽에, 모든 숫자를 오른쪽에 배치하면 보기 좋게 대칭을 이루어 장점이지만, 이 레이아웃에는 또 다른 단점이 있습니다. + +근접성의 법칙은 서로 가까이 있는 항목들이 관련 있는 것으로 인식된다는 것을 명시합니다. 따라서 관련 항목을 서로 옆에 배치하고자 합니다. 토큰 잔액은 토큰 자체와 직접 관련이 있으며, 새 토큰이 선택될 때마다 변경됩니다. 따라서 토큰 잔액이 토큰 선택 버튼 옆에 있는 것이 조금 더 합리적입니다. 토큰 아래로 옮길 수도 있지만, 그러면 레이아웃의 대칭이 깨집니다. + +궁극적으로 두 옵션 모두 장단점이 있지만, 추세가 오른쪽 토큰으로 기우는 것처럼 보이는 것은 흥미롭습니다. + +## 버튼 동작 {#button-behavior} + +승인을 위한 별도의 버튼을 만들지 마세요. 또한 승인을 위한 별도의 클릭을 만들지 마세요. 사용자는 교환을 원하므로 버튼에 '교환'이라고 표시하고 첫 번째 단계로 승인을 시작하세요. 모달은 스텝퍼 또는 간단한 '거래 1/2 - 승인 중' 알림으로 진행 상황을 표시할 수 있습니다. + +![승인과 교환을 위한 별도의 버튼이 있는 UI](./14.png) + +![승인이라고 표시된 버튼이 하나 있는 UI](./15.png) + +### 상황별 도움말로서의 버튼 {#button-as-contextual-help} + +버튼은 경고로서 이중 역할을 할 수 있습니다! + +이것은 사실 웹3 밖에서는 상당히 이례적인 디자인 패턴이지만, 그 안에서는 표준이 되었습니다. 이는 공간을 절약하고 주의를 집중시키는 좋은 혁신입니다. + +오류로 인해 주된 작업인 교환을 사용할 수 없는 경우, 버튼으로 그 이유를 설명할 수 있습니다. 예: + +- 네트워크 전환 +- 지갑 연결 +- 다양한 오류 + +버튼은 수행해야 할 **작업에 매핑**될 수도 있습니다. 예를 들어, 사용자가 잘못된 네트워크에 있어 교환할 수 없는 경우, 버튼에 'Ethereum으로 전환'이라고 표시되어야 하며, 사용자가 버튼을 클릭하면 네트워크를 Ethereum으로 전환해야 합니다. 이렇게 하면 사용자 흐름이 크게 빨라집니다. + +![메인 CTA에서 시작되는 핵심 작업](./16.png) + +![메인 CTA 내에 표시되는 오류 메시지](./17.png) + +## 이 Figma 파일로 직접 만들어 보세요 {#build-your-own-with-this-figma-file} + +여러 프로토콜의 노력 덕분에 DEX 디자인이 많이 개선되었습니다. 우리는 사용자가 어떤 정보를 필요로 하는지, 어떻게 보여줘야 하는지, 그리고 어떻게 흐름을 최대한 원활하게 만들 수 있는지 알고 있습니다. +이 글이 UX 원칙에 대한 확실한 개요를 제공하기를 바랍니다. + +실험해보고 싶으시다면 Figma 와이어프레임 키트를 자유롭게 사용해 주세요. 최대한 단순하게 유지되지만 다양한 방식으로 기본 구조를 구축할 수 있는 충분한 유연성을 갖추고 있습니다. + +[Figma 와이어프레임 키트](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit) + +디파이(DeFi)는 계속해서 진화할 것이며, 항상 개선의 여지가 있습니다. + +행운을 빕니다! diff --git a/public/content/translations/ko/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/ko/developers/docs/design-and-ux/heuristics-for-web3/index.md new file mode 100644 index 00000000000..21d647f1861 --- /dev/null +++ b/public/content/translations/ko/developers/docs/design-and-ux/heuristics-for-web3/index.md @@ -0,0 +1,138 @@ +--- +title: "웹3 인터페이스 디자인을 위한 7가지 휴리스틱" +description: "웹3의 사용성을 개선하기 위한 원칙" +lang: ko +--- + +사용성 휴리스틱은 사이트의 사용성을 측정하는 데 사용할 수 있는 광범위한 '경험 법칙'입니다. +여기에 소개된 7가지 휴리스틱은 웹3에 특화된 것으로, Jakob Nielsen의 [상호작용 설계를 위한 10가지 일반 원칙](https://www.nngroup.com/articles/ten-usability-heuristics/)과 함께 사용해야 합니다. + +## 웹3를 위한 7가지 사용성 휴리스틱 {#seven-usability-heuristics-for-web3} + +1. 피드백은 행동을 따른다 +2. 보안 및 신뢰 +3. 가장 중요한 정보는 명확하다 +4. 이해하기 쉬운 용어 +5. 행동은 가능한 한 짧게 +6. 네트워크 연결은 가시적이고 유연해야 한다 +7. 지갑이 아닌 앱에서 제어 + +## 정의 및 예시 {#definitions-and-examples} + +### 1. 피드백은 행동을 따른다 {#feedback-follows-action} + +**어떤 일이 발생했거나 발생하고 있을 때 명확하게 알 수 있어야 합니다.** + +사용자는 이전 단계의 결과를 바탕으로 다음 단계를 결정합니다. 따라서 시스템 상태에 대한 정보를 계속 제공받는 것이 중요합니다. 웹3에서는 트랜잭션이 블록체인에 커밋되기까지 시간이 걸릴 수 있으므로 특히 중요합니다. 기다리라는 피드백이 없으면 사용자는 어떤 일이 일어났는지 확신할 수 없습니다. + +**팁:** + +- 메시지, 알림 및 기타 경고를 통해 사용자에게 알립니다. +- 대기 시간을 명확하게 전달합니다. +- 작업이 몇 초 이상 걸리는 경우 타이머나 애니메이션으로 사용자에게 무언가 진행되고 있다는 느낌을 주어 안심시킵니다. +- 프로세스에 여러 단계가 있는 경우 각 단계를 보여줍니다. + +**예시:** +트랜잭션과 관련된 각 단계를 보여주면 사용자가 프로세스의 어느 단계에 있는지 알 수 있습니다. 적절한 아이콘을 통해 사용자는 자신의 행동 상태를 알 수 있습니다. + +![토큰 교환 시 각 단계에 대해 사용자에게 알림](./Image1.png) + +### 2. 보안 및 신뢰 내재화 {#security-and-trust-are-backed-in} + +보안을 우선시해야 하며, 이는 사용자에게 강조되어야 합니다. +사람들은 자신의 데이터를 매우 중요하게 생각합니다. 안전은 종종 사용자의 주된 관심사이므로 설계의 모든 수준에서 고려되어야 합니다. 항상 사용자의 신뢰를 얻기 위해 노력해야 하지만, 이를 수행하는 방법은 앱마다 다를 수 있습니다. 나중에 생각할 것이 아니라, 전반에 걸쳐 의식적으로 설계되어야 합니다. 최종 UI뿐만 아니라 소셜 채널과 개발문서를 포함한 사용자 경험 전반에 걸쳐 신뢰를 구축하십시오. 탈중앙화 수준, 재무 다중 서명 상태, 팀의 신상 공개 여부 등이 모두 사용자의 신뢰에 영향을 미칩니다. + +**팁:** + +- 감사 내역을 자신 있게 나열하십시오 +- 여러 감사를 받으십시오 +- 설계한 안전 기능을 홍보하십시오 +- 기본 통합을 포함한 잠재적 위험을 강조하십시오 +- 전략의 복잡성을 전달하십시오 +- 사용자의 안전 인식에 영향을 미칠 수 있는 비UI 문제를 고려하십시오 + +**예시:** +눈에 잘 띄는 크기로 바닥글에 감사 내역을 포함시키십시오. + +![웹사이트 바닥글에 참조된 감사 내역](./Image2.png) + +### 3. 가장 중요한 정보는 명확하다 {#the-most-important-info-is-obvious} + +복잡한 시스템의 경우 가장 관련성 높은 데이터만 표시합니다. 가장 중요한 것이 무엇인지 결정하고 표시의 우선순위를 정합니다. +너무 많은 정보는 부담스럽고 사용자는 일반적으로 의사 결정을 할 때 한 가지 정보에 의존합니다. 디파이에서는 수익 앱의 연이율(APR)과 대출 앱의 담보인정비율(LTV)이 될 것입니다. + +**팁:** + +- 사용자 조사를 통해 가장 중요한 지표를 발견할 수 있습니다 +- 핵심 정보는 크게, 다른 세부 정보는 작고 눈에 띄지 않게 만드십시오 +- 사람들은 읽지 않고 훑어봅니다. 디자인이 훑어보기 쉽도록 하십시오 + +**예시:** 풀 컬러의 큰 토큰은 훑어볼 때 쉽게 찾을 수 있습니다. 연이율(APR)은 크고 강조 색으로 강조 표시됩니다. + +![토큰과 연이율(APR)을 쉽게 찾을 수 있음](./Image3.png) + +### 4. 명확한 용어 {#clear-terminology} + +용어는 이해하기 쉽고 적절해야 합니다. +전문 용어는 완전히 새로운 정신 모델을 구축해야 하므로 큰 장애물이 될 수 있습니다. 사용자는 디자인을 이미 알고 있는 단어, 구문 및 개념과 연관시킬 수 없습니다. 모든 것이 혼란스럽고 낯설게 보이며, 사용을 시도하기 전에 가파른 학습 곡선이 있습니다. 사용자는 돈을 절약하려는 목적으로 디파이에 접근할 수 있지만, 마주하는 것은 채굴, 파밍, 스테이킹, 배출, 뇌물, 볼트, 락커, ve토큰, 베스팅, 에폭, 탈중앙화 알고리즘, 프로토콜 소유 유동성 등입니다… +가장 넓은 그룹의 사람들이 이해할 수 있는 간단한 용어를 사용하려고 노력하십시오. 프로젝트만을 위한 새로운 용어를 만들지 마십시오. + +**팁:** + +- 간단하고 일관된 용어를 사용하십시오 +- 기존 언어를 최대한 많이 사용하십시오 +- 자신만의 용어를 만들지 마십시오 +- 나타나는 대로 관례를 따르십시오 +- 사용자를 최대한 교육하십시오 + +**예시:** +'나의 보상'은 이 프로젝트를 위해 만들어진 새로운 단어가 아니라 널리 이해되는 중립적인 용어입니다. 보상 자체가 다른 토큰으로 지급되더라도 실제 세계의 정신 모델과 일치시키기 위해 보상은 미국 달러로 표시됩니다. + +![토큰 보상, 미국 달러로 표시됨](./Image4.png) + +### 5. 행동은 가능한 한 짧게 {#actions-are-as-short-as-possible} + +하위 작업을 그룹화하여 사용자의 상호작용 속도를 높입니다. +이는 UI뿐만 아니라 스마트 계약 수준에서도 수행될 수 있습니다. 사용자가 일반적인 작업을 완료하기 위해 시스템의 한 부분에서 다른 부분으로 이동하거나 시스템을 완전히 벗어날 필요가 없어야 합니다. + +**팁:** + +- 가능한 경우 "승인"을 다른 작업과 결합하십시오 +- 서명 단계를 최대한 가깝게 묶으십시오 + +**예시:** '유동성 추가'와 '스테이킹'을 결합하는 것은 사용자의 시간과 가스를 모두 절약하는 가속기의 간단한 예입니다. + +![입금 및 스테이킹 작업을 결합하는 스위치를 보여주는 모달](./Image5.png) + +### 6. 네트워크 연결은 가시적이고 유연해야 한다 {#network-connections-are-visible-and-flexible} + +사용자에게 연결된 네트워크를 알리고 네트워크를 변경할 수 있는 명확한 바로 가기를 제공합니다. +이는 멀티체인 앱에서 특히 중요합니다. 연결이 끊어졌거나 지원되지 않는 네트워크에 연결된 상태에서도 앱의 주요 기능은 계속 표시되어야 합니다. + +**팁:** + +- 연결이 끊긴 동안 가능한 한 많은 앱을 표시하십시오 +- 사용자가 현재 연결된 네트워크를 표시하십시오 +- 사용자가 네트워크를 변경하기 위해 지갑으로 이동하게 하지 마십시오 +- 앱에서 사용자가 네트워크를 전환해야 하는 경우 기본 콜투액션에서 해당 작업을 유도하십시오 +- 앱에 여러 네트워크에 대한 마켓이나 볼트가 포함된 경우 사용자가 현재 보고 있는 세트를 명확하게 명시하십시오 + +**예시:** 앱바에서 사용자가 연결된 네트워크를 표시하고 변경할 수 있도록 하십시오. + +![연결된 네트워크를 보여주는 드롭다운 버튼](./Image6.png) + +### 7. 지갑이 아닌 앱에서 제어 {#control-from-the-app-not-the-wallet} + +UI는 사용자에게 알아야 할 모든 것을 알려주고 해야 할 모든 것을 제어할 수 있도록 해야 합니다. +웹3에는 UI에서 수행하는 작업과 지갑에서 수행하는 작업이 있습니다. 일반적으로 UI에서 작업을 시작한 다음 지갑에서 확인합니다. 이 두 가닥이 신중하게 통합되지 않으면 사용자는 불편함을 느낄 수 있습니다. + +**팁:** + +- UI의 피드백을 통해 시스템 상태를 전달하십시오 +- 기록을 보관하십시오 +- 이전 거래에 대한 블록 탐색기 링크를 제공하십시오 +- 네트워크를 변경할 수 있는 바로 가기를 제공하십시오. + +미묘한 컨테이너는 사용자가 지갑에 어떤 관련 토큰을 가지고 있는지 보여주고, 주요 CTA는 네트워크를 변경할 수 있는 바로 가기를 제공합니다. + +![사용자에게 네트워크 전환을 유도하는 주요 CTA](./Image7.png) diff --git a/public/content/translations/ko/developers/docs/design-and-ux/index.md b/public/content/translations/ko/developers/docs/design-and-ux/index.md new file mode 100644 index 00000000000..f3953e71840 --- /dev/null +++ b/public/content/translations/ko/developers/docs/design-and-ux/index.md @@ -0,0 +1,86 @@ +--- +title: "Web3의 디자인과 UX" +description: "Web3 공간과 이더리움의 UX 디자인 및 연구 소개" +lang: ko +--- + +이더리움을 사용한 디자인이 처음이신가요? 잘 찾아오셨습니다. 이더리움 커뮤니티는 Web3 디자인 및 연구 기초를 소개하는 자료를 작성했습니다. 여러분에게 익숙한 다른 앱 디자인과 다를 수 있는 핵심 개념에 대해 배우게 될 것입니다. + +Web3에 대한 기본적인 이해가 먼저 필요하신가요? [**학습 허브**](/learn/)를 확인해 보세요. + +## 사용자 조사로 시작하기 {#start-with-user-research} + +효과적인 디자인은 시각적으로 매력적인 사용자 인터페이스를 만드는 것 이상을 의미합니다. 사용자의 요구, 목표, 동기를 깊이 이해하는 과정이 포함됩니다. 따라서 모든 디자이너가 의도적이고 신중한 작업을 보장하기 위해 [**더블 다이아몬드 프로세스**](https://en.wikipedia.org/wiki/Double_Diamond_\(design_process_model\))와 같은 디자인 프로세스를 채택할 것을 적극 권장합니다. + +- [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 연구원으로 일하는 것에 대한 개인적인 견해 + +## Web3 연구 사례 {#research-in-web3} + +이것은 Web3에서 수행된 사용자 연구를 선별한 목록으로, 디자인 및 제품 결정에 도움이 되거나 자체 연구를 수행하는 데 영감을 줄 수 있습니다. + +| 중점 분야 | 이름 | +| :--------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 암호화폐 온보딩 | [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) | +| 암호화폐 온보딩 | [Consensys: 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/) | +| 디파이 | [보장 풀](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) | +| 디파이 | [Consensys: 디파이 사용자 연구 보고서 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분) | + +## Web3를 위한 디자인 {#design-for-web3} + +- [Web3 UX 디자인 핸드북](https://web3ux.design/) - Web3 앱 디자인 실용 가이드 +- [Web3 디자인 원칙](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - 블록체인 기반 탈중앙화앱을 위한 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분) + +## 시작하기 {#getting-started} + +- [Web3를 위한 휴리스틱](/developers/docs/design-and-ux/heuristics-for-web3/) - Web3 인터페이스 디자인을 위한 7가지 휴리스틱 +- [DEX 디자인 모범 사례](/developers/docs/design-and-ux/dex-design-best-practice/) - 탈중앙화 거래소 디자인 가이드 + +## Web3 디자인 사례 연구 {#design-case-studies} + +- [Deep Work Studio](https://www.deepwork.studio/case-studies) +- [OpenSea에서 NFT 판매하기](https://builtformars.com/case-studies/opensea) +- [지갑 UX 분석: 지갑은 어떻게 변해야 하는가](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (동영상, 20분) + +## 디자인 현상금 {#bounties} + +- [Dework](https://app.dework.xyz/bounties) +- [Buildbox 해커톤](https://app.buidlbox.io/) +- [ETHGlobal 해커톤](https://ethglobal.com/) + +## 디자인 DAO 및 커뮤니티 {#design-daos-and-communities} + +전문 커뮤니티 주도 조직에 참여하거나 디자인 그룹에 가입하여 다른 회원들과 디자인 및 연구 관련 주제와 동향에 대해 논의하세요. + +- [Vectordao.com](https://vectordao.com/) +- [Deepwork.studio](https://www.deepwork.studio/) +- [We3.co](https://we3.co/) +- [Openux.xyz](https://openux.xyz/) + +## 디자인 시스템 및 기타 디자인 자료 {#design-systems-and-resources} + +- [Optimism 디자인](https://www.figma.com/@optimism) (Figma) +- [Ethereum.org 디자인 시스템](https://www.figma.com/@ethdotorg) (Figma) +- [Finity, Polygon의 디자인 시스템](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/) + +**이 페이지에 나열된 기사 및 프로젝트는 공식적인 보증이 아니며**, 정보 제공 목적으로만 제공됩니다. +저희는 [목록 정책](/contributing/design/adding-design-resources)의 기준에 따라 이 페이지에 링크를 추가합니다. 프로젝트/기사 추가를 원하시면 [GitHub](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md)에서 이 페이지를 편집하세요. diff --git a/public/content/translations/ko/developers/docs/development-networks/index.md b/public/content/translations/ko/developers/docs/development-networks/index.md new file mode 100644 index 00000000000..b1f0c72e735 --- /dev/null +++ b/public/content/translations/ko/developers/docs/development-networks/index.md @@ -0,0 +1,71 @@ +--- +title: "개발 네트워크" +description: "개발 네트워크에 대한 개요 및 이더리움 애플리케이션 구축에 도움이 되는 도구에 대한 설명입니다." +lang: ko +--- + +스마트 계약을 사용하여 이더리움 애플리케이션을 구축할 때 배포하기 전에 로컬 네트워크에서 실행하여 어떻게 작동하는지 확인하는 것이 좋습니다. + +웹 개발을 위해 컴퓨터에서 로컬 서버를 실행하는 것과 유사하게, 개발 네트워크를 사용하여 로컬 블록체인 인스턴스를 생성하고 댑을 테스트할 수 있습니다. 이러한 이더리움 개발 네트워크는 공개 테스트넷보다 훨씬 빠른 반복 작업을 가능하게 하는 기능을 제공합니다(예: 테스트넷 수도꼭지에서 ETH를 얻을 필요가 없음). + +## 필수 구성 요소 {#prerequisites} + +[이더리움 스택의 기본 사항](/developers/docs/ethereum-stack/)과 [이더리움 네트워크](/developers/docs/networks/)를 이해한 후에 개발 네트워크에 대해 자세히 알아보는 것이 좋습니다. + +## 개발 네트워크란 무엇인가요? {#what-is-a-development-network}네트워크-충격 + +개발 네트워크는 기본적으로 로컬 개발을 위해 특별히 설계된 이더리움 클라이언트(이더리움 구현)입니다. + +**로컬에서 표준 이더리움 노드를 실행하면 안 되나요?** + +[노드를 실행](/developers/docs/nodes-and-clients/#running-your-own-node)할 수도 _있지만_, 개발 네트워크는 개발 목적으로 구축되었기 때문에 다음과 같은 편리한 기능이 포함된 경우가 많습니다. + +- 결정론적으로 로컬 블록체인에 데이터(예: ETH 잔액이 있는 계정)를 시딩합니다. +- 수신하는 각 트랜잭션에 대해 순서대로 지연 없이 즉시 블록을 생성합니다. +- 향상된 디버깅 및 로깅 기능 + +## 사용 가능한 도구 {#available-projects} + +**참고**: 대부분의 [개발 프레임워크](/developers/docs/frameworks/)에는 내장된 개발 네트워크가 포함되어 있습니다. 프레임워크로 시작하여 [로컬 개발 환경을 설정](/developers/local-environment/)하는 것을 추천합니다. + +### Hardhat 네트워크 {#hardhat-network} + +개발용으로 설계된 로컬 이더리움 네트워크입니다. 계약을 배포하고, 테스트를 실행하고, 코드를 디버그할 수 있습니다. + +Hardhat 네트워크는 전문가를 위한 이더리움 개발 환경인 Hardhat에 내장되어 있습니다. + +- [웹사이트](https://hardhat.org/) +- [GitHub](https://github.com/NomicFoundation/hardhat) + +### 로컬 비콘 체인 {#local-beacon-chains} + +일부 합의 클라이언트에는 테스트 목적으로 로컬 비콘 체인을 가동하기 위한 내장 도구가 있습니다. Lighthouse, Nimbus, Lodestar에 대한 지침은 다음과 같습니다. + +- [Lodestar를 사용한 로컬 테스트넷](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/) +- [Lighthouse를 사용한 로컬 테스트넷](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets) + +### 공개 이더리움 테스트 체인 {#public-beacon-testchains} + +유지 관리되는 두 가지 공개 이더리움 테스트 구현인 Sepolia와 Hoodi도 있습니다. 장기적으로 지원되는 권장 테스트넷은 Hoodi이며 누구나 자유롭게 검증할 수 있습니다. Sepolia는 허가된 검증자 집합을 사용하므로, 이 테스트넷의 신규 검증자는 일반적으로 접근할 수 없습니다. + +- [Hoodi 스테이킹 런치패드](https://hoodi.launchpad.ethereum.org/) + +### 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/) + +## 더 읽어보기 {#further-reading} + +_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_ + +## 관련 주제 {#related-topics} + +- [개발 프레임워크](/developers/docs/frameworks/) +- [로컬 개발 환경 설정](/developers/local-environment/) diff --git a/public/content/translations/ko/developers/docs/ethereum-stack/index.md b/public/content/translations/ko/developers/docs/ethereum-stack/index.md new file mode 100644 index 00000000000..0b7f7c194bf --- /dev/null +++ b/public/content/translations/ko/developers/docs/ethereum-stack/index.md @@ -0,0 +1,61 @@ +--- +title: "이더리움 스택 소개" +description: "이더리움 스택의 다양한 계층과 그들이 어떻게 결합되는지에 대한 설명." +lang: ko +--- + +여느 소프트웨어 스택과 마찬가지로 온전한 "이더리움스택"이란, 당신의 목표에 따라 프로젝트 마다 제각각일 것입니다. + +하지만 어떻게 응용프로그램과 이더리움 블록체인이 상호작용하는 지를 머리속에 그릴 수 있도록 돕는 핵심 컴퍼넌트들은 존재합니다. 이더리움 기술스택의 계층들을 이해하는 것은 이더리움이 소프트웨어 프로젝트에 통합되게끔 하는 서로 다른 방식들을 이해하는데 도움을 줍니다. + +## 레벨 1: 이더리움 가상 머신 {#ethereum-virtual-machine} + +[이더리움 가상 머신(EVM)](/developers/docs/evm/)은 이더리움에서 스마트 계약을 실행하는 런타임 환경입니다. 이더리움 블록체인의 모든 스마트 계약 및 상태 변경은 [트랜잭션](/developers/docs/transactions/)에 의해 실행됩니다. 이더리움 가상환경은 이더리움 네트워크상의 모든 트랜잭션 처리를 수행합니다. + +여느 가상머신과 마찬가지로 이더리움가상머신은 코드의 실행과 물리적인 장비(이더리움 노드) 사이에 추상화 계층을 만듭니다. 현재 EVM은 전 세계에 분산된 수천 개의 노드에서 실행되고 있습니다. + +이더리움 가상 머신은 내부적으로 특정한 작업 수행을 위해 일련의 opcode 명령어를 사용합니다. 이 (140개의 고유한) 연산 부호는 EVM이 [튜링 완전](https://en.wikipedia.org/wiki/Turing_completeness)하도록 하며, 이는 충분한 리소스가 주어진다면 EVM이 거의 모든 것을 계산할 수 있음을 의미합니다. + +dapp 개발자로서, EVM에 대해 많이 알 필요는 없으며, 단지 EVM이 존재하고 이더리움의 모든 애플리케이션을 중단 없이 안정적으로 구동한다는 사실만 알고 있으면 됩니다. + +## 레벨 2: 스마트 계약 {#smart-contracts} + +[스마트 계약](/developers/docs/smart-contracts/)은 이더리움 블록체인에서 실행되는 실행 가능한 프로그램입니다. + +스마트 계약은 EVM 바이트코드(연산 부호라고 불리는 저수준 기계 명령어)로 컴파일되는 특정 [프로그래밍 언어](/developers/docs/smart-contracts/languages/)를 사용하여 작성됩니다. + +스마트 계약은 오픈 소스 라이브러리 역할을 할 뿐만 아니라, 항상 실행 중이며 중단될 수 없는 공개 API 서비스이기도 합니다. 스마트 계약은 사용자와 애플리케이션([탈중앙화앱](/developers/docs/dapps/))이 허가 없이 상호 작용할 수 있는 공개 함수를 제공합니다. 모든 애플리케이션은 배포된 스마트 계약과 통합하여 [데이터 피드](/developers/docs/oracles/) 추가 또는 토큰 스왑 지원과 같은 기능을 구성할 수 있습니다. 또한, 누구나 새로운 스마트 계약을 이더리움에 배포하여 애플리케이션의 필요에 맞는 맞춤형 기능을 추가할 수 있습니다. + +dapp 개발자로서 이더리움 블록체인에 맞춤형 기능을 추가하고 싶을 때에만 스마트 계약을 작성해야 합니다. 프로젝트의 요구 사항을 대부분 또는 전부 기존 스마트 계약과의 통합으로 해결할 수 있을 것입니다. 예를 들어 스테이블코인 결제 지원이나 토큰의 분산형 교환 기능을 추가하는 경우입니다. + +## 레벨 3: 이더리움 노드 {#ethereum-nodes} + +애플리케이션이 이더리움 블록체인과 상호 작용하려면 [이더리움 노드](/developers/docs/nodes-and-clients/)에 연결해야 합니다. 노드에 연결하면 블록체인 데이터를 읽거나 네트워크에 트랜잭션을 전송할 수 있습니다. + +이더리움 노드는 소프트웨어를 실행하는 컴퓨터 - 즉, 이더리움 클라이언트입니다. 클라이언트는 각 블럭의 트랜잭션을 검증하여 네트워크를 안전하고 데이터가 무결하게 관리하는 이더리움의 구현체를 말합니다. **이더리움 노드가 이더리움 블록체인입니다**. 노드는 이더리움 블록체인의 상태를 집단적으로 저장하며, 블록체인 상태를 변경하기 위해 트랜잭션에 대한 합의를 이룹니다. + +애플리케이션을 이더리움 노드([JSON-RPC API](/developers/docs/apis/json-rpc/)를 통해)에 연결하면, 애플리케이션은 블록체인에서 데이터(예: 사용자 계정 잔액)를 읽을 수 있을 뿐만 아니라 네트워크에 새로운 트랜잭션(예: 사용자 계정 간 ETH 전송 또는 스마트 계약 함수 실행)을 브로드캐스트할 수 있습니다. + +## 레벨 4: 이더리움 클라이언트 API {#ethereum-client-apis} + +이더리움 오픈 소스 커뮤니티에서 제작하고 유지 관리하는 다양한 편리한 라이브러리가 애플리케이션이 이더리움 블록체인과 연결하고 통신할 수 있도록 도와줍니다. + +사용자 대상 애플리케이션이 웹 앱인 경우, 프런트엔드에 직접 [JavaScript API](/developers/docs/apis/javascript/)를 `npm install`할 수 있습니다. 또는 [Python](/developers/docs/programming-languages/python/)이나 [Java](/developers/docs/programming-languages/java/) API를 사용하여 서버 측에서 이 기능을 구현할 수도 있습니다. + +이 API는 스택에서 반드시 필요한 부분은 아니지만, 이더리움 노드와 직접 상호작용하는 복잡성을 대부분 추상화해줍니다. 또한 유틸리티 함수(예: ETH를 Gwei로 변환)를 제공하므로, 개발자는 이더리움 클라이언트의 복잡성을 다루는 데 시간을 덜 소비하고 애플리케이션의 특정 기능에 더 집중할 수 있습니다. + +## 레벨 5: 최종 사용자 애플리케이션 {#end-user-applications} + +스택의 최상위에는 사용자 대상 애플리케이션이 있습니다. 이들은 주로 웹 및 모바일 애플리케이션과 같은 여러분이 정기적으로 사용하고 개발하는 표준 애플리케이션입니다. + +이러한 사용자 인터페이스를 개발하는 방법은 본질적으로 변하지 않습니다. 대부분의 경우, 사용자는 그들이 사용하는 애플리케이션이 블록체인을 기반으로 구축되었는지 알 필요가 없습니다. + +## 스택을 선택할 준비가 되셨나요? {#ready-to-choose-your-stack} + +이더리움 애플리케이션을 위한 [로컬 개발 환경 설정](/developers/local-environment/) 가이드를 확인하세요. + +## 더 읽어보기 {#further-reading} + +- [웹 3.0 애플리케이션의 아키텍처](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ + +_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_ diff --git a/public/content/translations/ko/developers/docs/evm/index.md b/public/content/translations/ko/developers/docs/evm/index.md new file mode 100644 index 00000000000..d83d45f9e89 --- /dev/null +++ b/public/content/translations/ko/developers/docs/evm/index.md @@ -0,0 +1,88 @@ +--- +title: "이더리움 가상 머신(EVM)" +description: "이더리움 가상머신 소개 및 상태, 트랜잭션, 그리고 스마트 계약과의 관련성" +lang: ko +--- + +이더리움 가상머신(EVM)은 모든 이더리움 노드에서 코드를 일관되고 안전하게 실행하는 탈중앙화된 가상 환경입니다. 노드는 EVM을 실행하여 스마트 계약을 실행하고, "[가스](/developers/docs/gas/)"를 사용하여 [연산](/developers/docs/evm/opcodes/)에 필요한 연산량을 측정하며 효율적인 리소스 할당과 네트워크 보안을 보장합니다. + +## 필수 구성 요소 {#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)와 같은 암호학/블록체인 개념에 익숙하면 도움이 됩니다. + +## 원장에서 상태 머신으로 {#from-ledger-to-state-machine} + +'분산 원장'의 유사함은 암호학의 기본 도구들을 사용해서 분산 화폐를 가능하게 하는 비트코인과 같은 블록체인을 설명하는데 자주 사용된다. 원장은 누군가가 원장을 수정하기 위해 할 수 있는 것과 할 수 없는 것을 지배하는 일련의 규칙을 준수해야 하는 활동 기록을 유지한다. 예를 들어 하나의 비트코인 주소는 그 주소가 이전에 받은 것보다 더 많은 비트코인을 쓸 수 없다. 이런 규칙은 비트코인과 다른 많은 블록체인 상의 모든 트랜잭션의 근간이다. + +이더리움은 거의 동일하고 직관적인 규칙을 따르는 자체 네이티브 암호화폐(이더)를 가지고 있지만, [스마트 계약](/developers/docs/smart-contracts/)이라는 훨씬 더 강력한 기능도 지원합니다. 이 더 복잡한 기능을 위해서, 더 정교한 설명이 필요하다. 이더리움은 분산 원장이 아니라 분산 [상태 머신](https://wikipedia.org/wiki/Finite-state_machine)입니다. 이더리움의 상태는 모든 계정과 잔고뿐만 아니라 사전 정의된 규칙에 따라 블록마다 변경될 수 있고, 임의의 머신 코드를 실행할 수 있는 _머신 상태_까지 포함하는 거대한 자료 구조입니다. 블록에서 블록으로의 상태 변화에 대한 자세한 규칙은 EVM에 의해 정의된다. + +![EVM의 구성을 보여주는 다이어그램](./evm.png) +_[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)에서 발췌한 다이어그램_ + +## 이더리움 상태 전환 함수 {#the-ethereum-state-transition-function} + +EVM은 하나의 입력으로 하나의 결정된 출력을 생성하는 수학 함수처럼 동작한다. 따라서 이더리움을 **상태 전환 함수**를 갖는 것으로 보다 공식적으로 설명하는 것이 매우 유용합니다. + +``` +Y(S, T)= S' +``` + +이전 유효 상태 `(S)`와 새로운 유효 거래 집합 `(T)`이 주어지면 이더리움 상태 전환 함수 `Y(S, T)`는 새로운 유효 출력 상태 `S'`를 생성합니다. + +### 상태 {#state} + +이더리움의 맥락에서 상태는 [수정된 머클 패트리샤 트리](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)라고 불리는 거대한 자료 구조로, 이는 해시로 연결된 모든 [계정](/developers/docs/accounts/)을 유지하며 블록체인에 저장된 단일 루트 해시로 축소될 수 있습니다. + +### 트랜잭션 {#transactions} + +트랜잭션은 계정으로부터 암호학적으로 서명된 명령들이다. 트랜잭션은 두가지 종류가 있다. 메시지 콜을 만드는 것들, 그리고 컨트랙트를 생성하는 것들. + +계약 생성 시 컴파일된 [스마트 계약](/developers/docs/smart-contracts/anatomy/) 바이트코드가 포함된 새로운 계약 계정이 생성됩니다. 다른 게정이 그 컨트랙트로 메세지 콜을 보낼 때 마다, 그 바이트코드를 실행한다. + +## EVM 명령 {#evm-instructions} + +EVM은 1024개 항목의 깊이를 가진 [스택 머신](https://wikipedia.org/wiki/Stack_machine)으로 실행됩니다. 각 항목은 256비트 단어로 256비트 암호학(예: Keccak-256 해시 또는 secp256k1 서명)에서 사용하기 쉽도록 선택되었다. + +실행 중에 EVM은 트랜잭션 간에 유지되지 않는 일시적인 _메모리_(워드 주소 지정 바이트 배열)를 유지합니다. + +### 임시 저장 공간 + +임시 저장 공간은 `TSTORE` 및 `TLOAD` 연산 부호를 통해 액세스되는 트랜잭션별 키-값 저장소입니다. 동일한 트랜잭션 동안 모든 내부 호출에서 유지되지만, 트랜잭션이 끝나면 삭제됩니다. 메모리와 달리, 임시 저장 공간은 실행 프레임이 아닌 EVM 상태의 일부로 모델링되지만, 전역 상태에는 커밋되지 않습니다. 임시 저장 공간은 트랜잭션 중 내부 호출 간에 가스 효율적인 임시 상태 공유를 가능하게 합니다. + +### 스토리지 + +계약에는 해당 계정과 연결되어 있고 전역 상태의 일부인 머클 패트리샤 _저장 공간_ 트리(워드 주소 지정 워드 배열)가 포함됩니다. 이 영구 저장 공간은 단일 트랜잭션 기간 동안에만 사용할 수 있고 계정의 영구 저장 공간 트리의 일부를 구성하지 않는 임시 저장 공간과 다릅니다. + +### 연산 부호 + +컴파일된 스마트 계약 바이트코드는 `XOR`, `AND`, `ADD`, `SUB` 등과 같은 표준 스택 연산을 수행하는 다수의 EVM [연산 부호](/developers/docs/evm/opcodes)로 실행됩니다. EVM은 또한 `ADDRESS`, `BALANCE`, `BLOCKHASH` 등과 같은 여러 블록체인별 스택 연산도 구현합니다. 연산 부호 집합에는 임시 저장 공간에 대한 액세스를 제공하는 `TSTORE` 및 `TLOAD`도 포함됩니다. + +![EVM 연산에 가스가 필요한 위치를 보여주는 다이어그램](../gas/gas.png) +_[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)에서 발췌한 다이어그램_ + +## EVM 구현 {#evm-implementations} + +EVM의 모든 구현은 이더리움 옐로우 페이퍼에 설명된 스펙을 준수해야한다. + +이더리움의 10년 역사 동안 EVM은 여러 차례 개정되었으며, 다양한 프로그래밍 언어로 된 여러 EVM 구현이 있습니다. + +[이더리움 실행 클라이언트](/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_ + +## 추가 정보 {#further-reading} + +- [이더리움 황서(Yellowpaper)](https://ethereum.github.io/yellowpaper/paper.pdf) +- [Jellopaper, 일명 KEVM: K의 EVM 시맨틱](https://jellopaper.org/) +- [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) + +## 관련 주제 {#related-topics} + +- [가스](/developers/docs/gas/) diff --git a/public/content/translations/ko/developers/docs/evm/opcodes/index.md b/public/content/translations/ko/developers/docs/evm/opcodes/index.md new file mode 100644 index 00000000000..11ff5d06b9c --- /dev/null +++ b/public/content/translations/ko/developers/docs/evm/opcodes/index.md @@ -0,0 +1,177 @@ +--- +title: "EVM용 연산 부호" +description: "이더리움 가상 머신에서 사용할 수 있는 모든 연산 부호 목록입니다." +lang: ko +--- + +## 개요 {#overview} + +[wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes)에 있는 EVM 참조 페이지의 업데이트된 버전입니다. +또한 [옐로페이퍼](https://ethereum.github.io/yellowpaper/paper.pdf), [젤로페이퍼](https://jellopaper.org/evm/), [geth](https://github.com/ethereum/go-ethereum) 구현을 참고했습니다. +이 문서는 이해하기 쉬운 참조 자료로 만들어졌지만, 특별히 엄격하지는 않습니다. +정확성을 확인하고 모든 에지 케이스를 인지하고 싶다면, 젤로페이퍼 또는 클라이언트 구현을 사용하는 것이 좋습니다. + +상호작용형 참조 자료를 찾고 계신가요? [evm.codes](https://www.evm.codes/)를 확인해 보세요. + +동적 가스 비용이 드는 연산에 대해서는 [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md)를 참조하세요. + +💡 빠른 팁: 전체 라인을 보려면, 데스크톱에서 `[shift] + 스크롤`을 사용하여 가로로 스크롤하세요. + +| 스택 | 이름 | 가스 | 초기 스택 | 결과 스택 | 메모리 / 스토리지 | 참고사항 | | +| :---: | :------------- | :---------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | +| 00 | STOP | 0 | | | | 실행 중단 | | +| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 덧셈(모듈로 2\*\*256) | | +| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 곱셈(모듈로 2\*\*256) | | +| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 뺄셈(모듈로 2\*\*256) | | +| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 나눗셈 | | +| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 나눗셈 | | +| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 모듈로 | | +| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 모듈로 | | +| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 덧셈(모듈로 N) | | +| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 곱셈(모듈로 N) | | +| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 거듭제곱(모듈로 2\*\*256) | | +| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | `x`를 `(b+1)` 바이트에서 32바이트로 [부호 확장](https://wikipedia.org/wiki/Sign_extension) | | +| 0C-0F | _유효하지 않음_ | | | | | | | +| 10 | LT | 3 | `a, b` | `a < b` | | uint256 보다 작음 | | +| 11 | GT | 3 | `a, b` | `a > b` | | uint256 보다 큼 | | +| 12 | SLT | 3 | `a, b` | `a < b` | | int256 보다 작음 | | +| 13 | SGT | 3 | `a, b` | `a > b` | | int256 보다 큼 | | +| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 같음 | | +| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256이 0인지 확인 | | +| 16 | AND | 3 | `a, b` | `a && b` | | 비트 AND | | +| 17 | OR | 3 | `a, b` | `a \\|\\| b` | | 비트 OR | | +| 18 | XOR | 3 | `a, b` | `a ^ b` | | 비트 XOR | | +| 19 | NOT | 3 | `a` | `~a` | | 비트 NOT | | +| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | 왼쪽부터 (u)int256 `x`의 `i`번째 바이트 | | +| 1B | SHL | 3 | `shift, val` | `val << shift` | | 왼쪽으로 시프트 | | +| 1C | SHR | 3 | `shift, val` | `val >> shift` | | 논리적 오른쪽 시프트 | | +| 1D | SAR | 3 | `shift, val` | `val >> shift` | | 산술적 오른쪽 시프트 | | +| 1E-1F | _유효하지 않음_ | | | | | | | +| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | | +| 21-2F | _유효하지 않음_ | | | | | | | +| 30 | ADDRESS | 2 | `.` | `address(this)` | | 실행 중인 컨트랙트의 주소 | | +| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | 잔액, wei 단위 | | +| 32 | ORIGIN | 2 | `.` | `tx.origin` | | 트랜잭션을 시작한 주소 | | +| 33 | CALLER | 2 | `.` | `msg.sender` | | 메시지 발신자의 주소 | | +| 34 | CALLVALUE | 2 | `.` | `msg.value` | | 메시지 값, wei 단위 | | +| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | 인덱스 `idx`에서 메시지 데이터 워드 읽기 | | +| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | 메시지 데이터의 길이, 바이트 단위 | | +| 37 | CALLDATACOPY | [A3](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] | 메시지 데이터 복사 | | +| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | 실행 중인 컨트랙트 코드의 길이, 바이트 단위 | | +| 39 | CODECOPY | [A3](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` | | 트랜잭션의 가스 가격, 가스 단위당 wei [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | | +| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | addr에 있는 코드 크기, 바이트 단위 | | +| 3C | EXTCODECOPY | [A4](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] | `addr`에서 코드 복사 | | +| 3D | RETURNDATASIZE | 2 | `.` | `size` | | 마지막 외부 호출에서 반환된 데이터의 크기, 바이트 단위 | | +| 3E | RETURNDATACOPY | [A3](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] | 마지막 외부 호출에서 반환된 데이터 복사 | | +| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | 해시 = addr이 존재하는 경우 ? keccak256(addr.code) : 0 | | +| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | | +| 41 | COINBASE | 2 | `.` | `block.coinbase` | | 현재 블록 제안자의 주소 | | +| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | 현재 블록의 타임스탬프 | | +| 43 | NUMBER | 2 | `.` | `block.number` | | 현재 블록의 번호 | | +| 44 | PREVRANDAO | 2 | `.` | `랜덤성 비콘` | | 랜덤성 비콘 | | +| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | 현재 블록의 가스 한도 | | +| 46 | CHAINID | 2 | `.` | `chain_id` | | 현재 [체인 ID](https://eips.ethereum.org/EIPS/eip-155)를 스택에 푸시 | | +| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | 실행 중인 컨트랙트의 잔액, wei 단위 | | +| 48 | BASEFEE | 2 | `.` | `block.basefee` | | 현재 블록의 기본 수수료 | | +| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | | +| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | 현재 블록의 블롭 기본 수수료 ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | | +| 4B-4F | _유효하지 않음_ | | | | | | | +| 50 | POP | 2 | `_anon` | `.` | | 스택 맨 위에서 항목을 제거하고 폐기 | | +| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | 오프셋 `ost`의 메모리에서 워드 읽기 | | +| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | 메모리에 워드 쓰기 | | +| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | 메모리에 단일 바이트 쓰기 | | +| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | 스토리지에서 워드 읽기 | | +| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | 스토리지에 워드 쓰기 | | +| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst`는 `dst`가 유효한 점프 대상인 경우에만 `pc`가 할당됨을 표시 | | +| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ?` dst : $pc + 1` | | +| 58 | PC | 2 | `.` | `$pc` | | 프로그램 카운터 | | +| 59 | MSIZE | 2 | `.` | `len(mem)` | | 현재 실행 컨텍스트의 메모리 크기, 바이트 단위 | | +| 5A | GAS | 2 | `.` | `gasRemaining` | | | | +| 5B | JUMPDEST | 1 | | | 유효한 점프 대상 표시 | 유효한 점프 대상(예: 푸시 데이터 내부에 있지 않은 점프 대상) | | +| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | 임시 스토리지에서 워드 읽기 ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | | +| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | 임시 스토리지에 워드 쓰기 ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | | +| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | 한 영역에서 다른 영역으로 메모리 복사 ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | | +| 5F | PUSH0 | 2 | `.` | `uint8` | | 상수 값 0을 스택에 푸시 | | +| 60 | PUSH1 | 3 | `.` | `uint8` | | 1바이트 값을 스택에 푸시 | | +| 61 | PUSH2 | 3 | `.` | `uint16` | | 2바이트 값을 스택에 푸시 | | +| 62 | PUSH3 | 3 | `.` | `uint24` | | 3바이트 값을 스택에 푸시 | | +| 63 | PUSH4 | 3 | `.` | `uint32` | | 4바이트 값을 스택에 푸시 | | +| 64 | PUSH5 | 3 | `.` | `uint40` | | 5바이트 값을 스택에 푸시 | | +| 65 | PUSH6 | 3 | `.` | `uint48` | | 6바이트 값을 스택에 푸시 | | +| 66 | PUSH7 | 3 | `.` | `uint56` | | 7바이트 값을 스택에 푸시 | | +| 67 | PUSH8 | 3 | `.` | `uint64` | | 8바이트 값을 스택에 푸시 | | +| 68 | PUSH9 | 3 | `.` | `uint72` | | 9바이트 값을 스택에 푸시 | | +| 69 | PUSH10 | 3 | `.` | `uint80` | | 10바이트 값을 스택에 푸시 | | +| 6A | PUSH11 | 3 | `.` | `uint88` | | 11바이트 값을 스택에 푸시 | | +| 6B | PUSH12 | 3 | `.` | `uint96` | | 12바이트 값을 스택에 푸시 | | +| 6C | PUSH13 | 3 | `.` | `uint104` | | 13바이트 값을 스택에 푸시 | | +| 6D | PUSH14 | 3 | `.` | `uint112` | | 14바이트 값을 스택에 푸시 | | +| 6E | PUSH15 | 3 | `.` | `uint120` | | 15바이트 값을 스택에 푸시 | | +| 6F | PUSH16 | 3 | `.` | `uint128` | | 16바이트 값을 스택에 푸시 | | +| 70 | PUSH17 | 3 | `.` | `uint136` | | 17바이트 값을 스택에 푸시 | | +| 71 | PUSH18 | 3 | `.` | `uint144` | | 18바이트 값을 스택에 푸시 | | +| 72 | PUSH19 | 3 | `.` | `uint152` | | 19바이트 값을 스택에 푸시 | | +| 73 | PUSH20 | 3 | `.` | `uint160` | | 20바이트 값을 스택에 푸시 | | +| 74 | PUSH21 | 3 | `.` | `uint168` | | 21바이트 값을 스택에 푸시 | | +| 75 | PUSH22 | 3 | `.` | `uint176` | | 22바이트 값을 스택에 푸시 | | +| 76 | PUSH23 | 3 | `.` | `uint184` | | 23바이트 값을 스택에 푸시 | | +| 77 | PUSH24 | 3 | `.` | `uint192` | | 24바이트 값을 스택에 푸시 | | +| 78 | PUSH25 | 3 | `.` | `uint200` | | 25바이트 값을 스택에 푸시 | | +| 79 | PUSH26 | 3 | `.` | `uint208` | | 26바이트 값을 스택에 푸시 | | +| 7A | PUSH27 | 3 | `.` | `uint216` | | 27바이트 값을 스택에 푸시 | | +| 7B | PUSH28 | 3 | `.` | `uint224` | | 28바이트 값을 스택에 푸시 | | +| 7C | PUSH29 | 3 | `.` | `uint232` | | 29바이트 값을 스택에 푸시 | | +| 7D | PUSH30 | 3 | `.` | `uint240` | | 30바이트 값을 스택에 푸시 | | +| 7E | PUSH31 | 3 | `.` | `uint248` | | 31바이트 값을 스택에 푸시 | | +| 7F | PUSH32 | 3 | `.` | `uint256` | | 32바이트 값을 스택에 푸시 | | +| 80 | DUP1 | 3 | `a` | `a, a` | | 스택의 첫 번째 값 복제 | | +| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | 스택의 두 번째 값 복제 | | +| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | 스택의 세 번째 값 복제 | | +| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | 스택의 네 번째 값 복제 | | +| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | 스택의 다섯 번째 값 복제 | | +| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | 스택의 여섯 번째 값 복제 | | +| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | 스택의 일곱 번째 값 복제 | | +| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | 스택의 여덟 번째 값 복제 | | +| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | 스택의 아홉 번째 값 복제 | | +| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | 스택의 열 번째 값 복제 | | +| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | 스택의 열한 번째 값 복제 | | +| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | 스택의 열두 번째 값 복제 | | +| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | 스택의 열세 번째 값 복제 | | +| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | 스택의 열네 번째 값 복제 | | +| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | 스택의 열다섯 번째 값 복제 | | +| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | 스택의 열여섯 번째 값 복제 | | +| 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](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | | +| A1 | LOG1 | [A8](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](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](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](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 | _유효하지 않음_ | | | | | | | +| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([주소(this), this.nonce])) | | +| F1 | CALL | [AA](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](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 | DELEGATECALL과 동일하지만, 원래의 msg.sender와 msg.value는 전파하지 않습니다. | | +| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | mem[ost:ost+len-1] 반환 | | +| F4 | DELEGATECALL | [AA](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](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ 주소(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | | +| F6-F9 | _유효하지 않음_ | | | | | | | +| FA | STATICCALL | [AA](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 | _유효하지 않음_ | | | | | | | +| FD | REVERT | 0[\*](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](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | 지정된 유효하지 않은 연산 부호 - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | | +| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | 모든 ETH를 `addr`로 보냅니다. 컨트랙트가 생성된 것과 동일한 트랜잭션에서 실행되면 해당 컨트랙트를 파기합니다. | | diff --git a/public/content/translations/ko/developers/docs/frameworks/index.md b/public/content/translations/ko/developers/docs/frameworks/index.md new file mode 100644 index 00000000000..2a2f6e3d1c3 --- /dev/null +++ b/public/content/translations/ko/developers/docs/frameworks/index.md @@ -0,0 +1,149 @@ +--- +title: "디앱 개발 프레임워크" +description: "프레임워크 사용 시의 장점을 알아보고 가능한 옵션들을 비교해 봅니다." +lang: ko +--- + +## 프레임워크 소개 {#introduction-to-frameworks} + +온전한 형태의 디앱을 구축하려면 서로 다른 여러 기술들이 필요합니다. 소프트웨어 프레임워크는 필요한 기능을 많이 포함하거나 사용자가 원하는 도구를 찾도록 도와주는 다루기 쉬운 플러그인 시스템을 제공합니다. + +프레임워크에는 다음과 같이 추가 작업 없이 바로 사용할 수 있는 기능들이 있습니다. + +- 로컬 블록체인 인스턴스를 스핀업하기 위한 기능. +- 스마트 계약을 컴파일하고 테스트하기 위한 유틸리티. +- 동일한 프로젝트/리포지토리 내에서 사용자 대상 애플리케이션을 빌드하기 위한 클라이언트 개발 애드온. +- 로컬에서 실행되는 인스턴스 또는 이더리움 공개 네트워크 중 하나에 이더리움 네트워크를 연결하고 컨트랙트를 배포하기 위한 구성입니다. +- 탈중앙화 앱 배포 - IPFS와 같은 스토리지 옵션과의 통합. + +## 필수 구성 요소 {#prerequisites} + +프레임워크를 시작하기 전에 [탈중앙화앱](/developers/docs/dapps/)과 [이더리움 스택](/developers/docs/ethereum-stack/)에 대한 소개를 먼저 읽어보시는 것을 권장합니다. + +## 사용 가능한 프레임워크 {#available-frameworks} + +**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) +- [Discord](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 -** **_Ethers.js + Hardhat + web3용 React 컴포넌트 및 후크: 스마트 컨트랙트로 구동되는 탈중앙화 애플리케이션 구축을 시작하는 데 필요한 모든 것을 제공합니다._** + +- [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/) +- [튜토리얼](/developers/tutorials/the-graph-fixing-web3-data-querying/) + +**Alchemy -** **_이더리움 개발 플랫폼입니다._** + +- [alchemy.com](https://www.alchemy.com/) +- [GitHub](https://github.com/alchemyplatform) +- [Discord](https://discord.com/invite/alchemyplatform) + +**NodeReal -** **_이더리움 개발 플랫폼입니다._** + +- [Nodereal.io](https://nodereal.io/) +- [GitHub](https://github.com/node-real) +- [Discord](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) +- [Discord](https://discord.gg/BSb5zfp9AT) + +**Crossmint -** **_모든 주요 EVM 체인(및 기타)에서 NFT 애플리케이션을 빌드할 수 있는 엔터프라이즈급 web3 개발 플랫폼입니다._** + +- [웹사이트](https://www.crossmint.com) +- [개발문서](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) + +**Brownie -** **_Python 기반 개발 환경 및 테스트 프레임워크입니다._** + +- [문서](https://eth-brownie.readthedocs.io/en/latest/) +- [GitHub](https://github.com/eth-brownie/brownie) +- **Brownie는 현재 유지보수되지 않습니다** + +**OpenZeppelin SDK -** **_궁극의 스마트 컨트랙트 툴킷: 스마트 컨트랙트를 개발, 컴파일, 업그레이드, 배포하고 상호작용하는 데 도움이 되는 도구 모음입니다._** + +- [OpenZeppelin Defender SDK](https://docs.openzeppelin.com/defender/sdk) +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk) +- [커뮤니티 포럼](https://forum.openzeppelin.com/c/support/17) +- **OpenZeppelin SDK 개발이 종료되었습니다** + +**Catapulta -** **_다중 체인 스마트 컨트랙트 배포 도구로, 블록 탐색기에서 검증을 자동화하고 배포된 스마트 컨트랙트를 추적하며 배포 보고서를 공유합니다. Foundry 및 Hardhat 프로젝트를 위한 플러그 앤 플레이 방식입니다._** + +- [웹사이트](https://catapulta.sh/) +- [문서](https://catapulta.sh/docs) +- [GitHub](https://github.com/catapulta-sh) + +**GoldRush(Covalent 제공) -** **_GoldRush는 개발자, 분석가, 기업을 위한 가장 포괄적인 블록체인 데이터 API 제품군을 제공합니다. 디파이 대시보드, 지갑, 트레이딩 봇, AI 에이전트 또는 규정 준수 플랫폼을 구축하는 경우, 데이터 API는 필요한 필수 온체인 데이터에 빠르고 정확하며 개발자 친화적인 액세스를 제공합니다_** + +- [웹사이트](https://goldrush.dev/) +- [문서](https://goldrush.dev/docs/chains/ethereum) +- [GitHub](https://github.com/covalenthq) +- [Discord](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 -** **_탈중앙화 애플리케이션 개발자가 자신의 애플리케이션에 탈중앙화 신원 및 검증 가능한 자격 증명을 쉽게 구축할 수 있도록 지원하는 오픈 소스, 모듈식, 독립 프레임워크입니다._** + +- [홈페이지](https://veramo.io/) +- [문서](https://veramo.io/docs/basics/introduction) +- [GitHub](https://github.com/uport-project/veramo) +- [Discord](https://discord.com/invite/FRRBdjemHV) +- [NPM 패키지](https://www.npmjs.com/package/@veramo/core) + +## 더 읽어보기 {#further-reading} + +_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_ + +## 관련 주제 {#related-topics} + +- [로컬 개발 환경 설정](/developers/local-environment/) diff --git a/public/content/translations/ko/developers/docs/gas/index.md b/public/content/translations/ko/developers/docs/gas/index.md new file mode 100644 index 00000000000..a45657ca7de --- /dev/null +++ b/public/content/translations/ko/developers/docs/gas/index.md @@ -0,0 +1,151 @@ +--- +title: "가스와 수수료" +metaTitle: "이더리움 가스와 수수료: 기술적 개요" +description: "이더리움 가스 수수료, 계산 방법, 네트워크 보안 및 트랜잭션 처리에서 가스 수수료의 역할에 대해 알아보세요." +lang: ko +--- + +가스는 이더리움 네트워크의 필수적인 요소입니다. 자동차를 주행하기 위해 가솔린이 필요하듯이, 이더리움 네트워크의 연료와 같은 역할을 합니다. + +## 필수 구성 요소 {#prerequisites} + +이 페이지를 더 잘 이해하려면 먼저 [트랜잭션](/developers/docs/transactions/)과 [EVM](/developers/docs/evm/)에 대해 읽어보시는 것을 권장합니다. + +## 가스란 무엇인가요? {#what-is-gas} + +가스는 이더리움 네트워크에서 특정 동작을 실행하기 위해 요구되는 노력에 대한 양과 같습니다. + +각 이더리움 트랜잭션을 실행하려면 컴퓨팅 리소스가 필요하므로, 이더리움이 스팸에 취약하지 않고 무한한 계산 루프에 빠지지 않도록 하려면 이러한 리소스에 대한 비용을 지불해야 합니다. 연산에 대한 지불은 가스 수수료의 형태로 이루어집니다. + +가스 수수료는 **특정 작업을 수행하는 데 사용된 가스의 양에 단위 가스당 비용을 곱한 값**입니다. 수수료는 트랜잭션의 성공 여부와 관계없이 지불됩니다. + +![EVM 연산에 가스가 필요한 위치를 보여주는 다이어그램](./gas.png) +_[이더리움 EVM 일러스트](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)에서 발췌한 다이어그램_ + +가스 수수료는 이더리움의 고유 통화인 이더(ETH)로 지불해야 합니다. 가스 가격은 보통 ETH의 단위인 gwei로 표시됩니다. gwei는 1ETH의 10억분의 1(0.000000001 ETH or 10-9 ETH) 과 같습니다. + +예를 들어, 가스가 0.000000001 ETH라고 말하는 대신, 1 Gwei 라고 말할 수 있습니다. + +'gwei'라는 단어는 'giga-wei'의 축약어로, '10억 wei'를 의미합니다. 1 gwei는 10억 wei와 같습니다. Wei 자체([b-money](https://www.investopedia.com/terms/b/bmoney.asp)의 개발자인 [웨이 다이](https://wikipedia.org/wiki/Wei_Dai)의 이름을 따서 명명)는 ETH의 가장 작은 단위입니다. + +## 가스 수수료는 어떻게 계산되나요? {#how-are-gas-fees-calculated} + +트랜잭션을 제출할 때 지불하고자 하는 가스의 양을 설정할 수 있습니다. 특정 양의 가스를 제공함으로써 다음 블록에 트랜잭션이 포함되도록 입찰하는 것입니다. 너무 적은 금액을 제시하면 검증자가 트랜잭션을 포함하도록 선택할 가능성이 낮아지므로 트랜잭션이 늦게 실행되거나 전혀 실행되지 않을 수 있습니다. 너무 많이 제공하면 일부 ETH를 낭비할 수 있습니다. 그렇다면 얼마를 지불해야 하는지 어떻게 알 수 있을까요? + +총 가스 지불액은 `기본 수수료`와 `우선 수수료`(팁)의 두 가지 구성 요소로 나뉩니다. + +`기본 수수료`는 프로토콜에 의해 설정되며, 트랜잭션이 유효한 것으로 간주되려면 최소한 이 금액을 지불해야 합니다. `우선 수수료`는 기본 수수료에 추가하는 팁으로, 검증자가 다음 블록에 포함하도록 트랜잭션을 매력적으로 만드는 역할을 합니다. + +`기본 수수료`만 지불하는 트랜잭션은 기술적으로는 유효하지만, 검증자가 다른 트랜잭션보다 이를 선택할 인센티브가 없기 때문에 포함될 가능성이 낮습니다. '올바른' `우선` 수수료는 트랜잭션을 보낼 때의 네트워크 사용량에 따라 결정됩니다. 수요가 많으면 `우선` 수수료를 더 높게 설정해야 할 수도 있지만, 수요가 적을 때는 더 적게 지불할 수 있습니다. + +예를 들어, 조던이 테일러에게 1 ETH를 지불해야 한다고 가정해 봅시다. ETH 전송에는 21,000개의 가스 단위가 필요하며, 기본 요금은 10 gwei입니다. Jordan은 2gwei 만큼의 팁을 포함하고 있습니다. + +총 수수료는 다음과 같이 계산됩니다: + +`가스 사용 단위 * (기본 요금 + 우선 요금)` + +여기서 `기본 수수료`는 프로토콜에 의해 설정된 값이고, `우선 수수료`는 사용자가 검증자에게 팁으로 설정한 값입니다. + +예: `21,000 * (10 + 2) = 252,000 gwei` (0.000252 ETH). + +만약 Jordan이 1 ETH만큼의 돈을 보낸다면, 1.000252 이더만큼의 돈이 Jordan의 계좌에서 빠져나가게 됩니다. 그리고 Taylor는 1.0000ETH만큼의 돈을 얻게되죠. 검증자는 0.000042 ETH의 팁을 받습니다. 0.00021 ETH의 `기본 수수료`는 소각됩니다. + +### 기본 수수료 {#base-fee} + +모든 블록에는 예비 가격 역할을 하는 base fee이 있습니다. 블록에 포함될 자격이 있으려면 가스당 제시 가격이 최소한 base fee와 같아야 합니다. 기본 수수료는 현재 블록과 독립적으로 계산되며, 이전 블록에 의해 결정되므로 사용자가 거래 수수료를 더 쉽게 예측할 수 있습니다. 블록이 생성될 때 이 \*\*기본 수수료는 "소각"\*\*되어 유통에서 제거됩니다. + +기본 수수료는 이전 블록의 크기(모든 트랜잭션에 사용된 가스 양)를 목표 크기(가스 한도의 절반)와 비교하는 공식으로 계산됩니다. 목표 블록 크기가 목표보다 크거나 작을 경우, 기본 수수료는 블록당 최대 12.5%씩 증가하거나 감소합니다. 이러한 기하급수적인 성장은 블록 크기가 무한정 높게 유지되는 것을 경제적으로 불가능하게 만든다 + +| 블록 번호 | 포함된 가스 | 요금 상승률 | 현재 기본 요금 | +| ----- | -----: | --------------------: | -------------------------: | +| 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 | + +위 표에서는 가스 한도로 3,600만을 사용하여 예시를 보여줍니다. 이 예를 들어, 9번 블록에 트랜잭션을 생성하기 위해 지갑은 사용자에게 다음 블록에 추가될 **최대 기본 수수료**가 `현재 기본 수수료 * 112.5%` 또는 `202.7 gwei * 112.5% = 228.1 gwei`임을 확실하게 알려줍니다. + +기본 요금이 가득 찬 블록에 앞서 빠르게 증가하기 때문에 가득 찬 블록이 지속적으로 발생할 가능성은 낮습니다. + +| 블록 번호 | 포함된 가스 | 요금 상승률 | 현재 기본 요금 | +| --------------------------------------------------- | --------------------------------------------------: | --------------------: | --------------------------------------------------: | +| 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 | + +### 우선 수수료(팁) {#priority-fee} + +우선 수수료(팁)는 검증자가 블록 가스 한도에 의해서만 제한된 블록의 트랜잭션 수를 최대화하도록 장려합니다. 팁이 없다면, 합리적인 검증자는 스테이킹 보상이 블록에 있는 트랜잭션 수와 무관하므로 직접적인 실행 레이어나 합의 레이어 페널티 없이 더 적은 수의 트랜잭션(또는 0개의 트랜잭션)을 포함할 수 있습니다. 또한 팁은 사용자가 동일한 블록 내에서 우선순위를 위해 다른 사람보다 높은 가격을 제시할 수 있게 하여 사실상 긴급성을 알립니다. + +### 최대 수수료 {#maxfee} + +네트워크에서 트랜잭션을 실행하기 위해 사용자는 실행할 트랜잭션에 대해 지불할 최대 한도를 지정할 수 있습니다. 이 선택적 매개변수는 `maxFeePerGas`로 알려져 있습니다. 거래가 실행되려면 최대 수수료가 기본 수수료와 팁의 합계를 초과해야 합니다. 거래 발송자는 최대 수수료와 기본 수수료 및 팁의 합계액의 차액을 환불받는다. + +### 블록 크기 {#block-size} + +각 블록의 목표 크기는 현재 가스 한도의 절반이지만, 블록 크기는 네트워크 수요에 따라 블록 한도(목표 블록 크기의 2배)에 도달할 때까지 증가하거나 감소합니다. 이 프로토콜은 _tâtonnement_ 프로세스를 통해 목표에서 평균 평형 블록 크기를 달성합니다. 이는 블록 크기가 목표 블록 크기보다 클 경우 프로토콜이 다음 블록에 대한 기본 요금을 증가시킨다는 것을 의미합니다. 마찬가지로, 블록 크기가 목표 블록 크기보다 작으면 프로토콜은 기본 요금을 감소시킵니다. + +Base fee를 조정하는 금액은 현재 블록 크기가 대상에서 얼마나 멀리 떨어져 있는지에 비례합니다. 이는 빈 블록의 경우 -12.5%, 목표 크기에서 0%, 가스 한도에 도달하는 블록의 경우 최대 +12.5%까지 선형으로 계산됩니다. 가스 한도는 검증자 신호와 네트워크 업그레이드를 통해 시간에 따라 변동될 수 있습니다. [여기에서 시간 경과에 따른 가스 한도의 변화를 볼 수 있습니다](https://eth.blockscout.com/stats/averageGasLimit?interval=threeMonths). + +[블록에 대해 더 알아보기](/developers/docs/blocks/) + +### 실제 가스 수수료 계산 {#calculating-fees-in-practice} + +거래를 실행하기 위해 지불할 금액을 명시적으로 설정할 수 있습니다. 그러나 대부분의 지갑 제공업체는 사용자 부담을 줄이기 위해 권장 거래 수수료(기본 요금 + 권장 우선 요금)를 자동으로 설정합니다. + +## 왜 가스 요금이 있는지? {#why-do-gas-fees-exist} + +간단히, 가스 요금은 이더리움 네트워크를 더 안전하게 유지하도록 돕습니다. 네트워크에서 실행되는 모든 계산에 대해 수수료를 요구함으로써, 우리는 나쁜 행위자들이 네트워크를 스팸하는 것을 방지한다. 우발적이거나 적대적인 무한 루프 또는 코드의 다른 계산 낭비를 피하기 위해, 각 트랜잭션은 코드 실행의 몇 가지 계산 단계를 사용할 수 있는지에 대한 제한을 설정해야 한다. 연산의 기본 단위가 "가스"입니다. + +트랜잭션에 한도가 포함되어 있지만, 트랜잭션에서 사용되지 않은 가스는 사용자에게 반환됩니다(예: `최대 수수료 - (기본 수수료 + 팁)`이 반환됨). + +![사용하지 않은 가스가 환불되는 방식을 보여주는 다이어그램](../transactions/gas-tx.png) +_[이더리움 EVM 일러스트](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)에서 발췌한 다이어그램_ + +## 가스 한도란 무엇입니까? {#what-is-gas-limit} + +가스 한도는 거래에 소비할 수 있는 최대 가스 양을 의미합니다. [스마트 계약](/developers/docs/smart-contracts/)과 관련된 더 복잡한 트랜잭션은 더 많은 계산 작업을 필요로 하므로, 단순한 결제보다 더 높은 가스 한도를 요구합니다. 표준 ETH 전송에는 21,000 단위의 가스 제한이 필요합니다. + +예를 들어, 단순 ETH 전송을 위해 가스 제한을 50,000으로 설정하면 EVM이 21,000을 소비하고 나머지 29,000을 돌려받게 됩니다. 하지만 가스를 너무 적게 지정하면(예: 단순 ETH 전송에 대한 가스 한도를 20,000으로 설정) 트랜잭션은 유효성 검사 단계에서 실패합니다. 블록에 포함되기 전에 거부되며 가스가 소모되지 않습니다. 반면에, 실행 중에 트랜잭션의 가스가 부족하면(예: 스마트 계약이 중간에 모든 가스를 소진) EVM은 모든 변경 사항을 되돌리지만, 제공된 모든 가스는 수행된 작업에 대해 계속 소모됩니다. + +## 가스 요금이 왜 이렇게 높은 건가요? {#why-can-gas-fees-get-so-high} + +높은 가스 요금은 이더리움의 인기 때문이다. 수요가 너무 많으면 사용자는 다른 사용자의 거래보다 높은 팁을 제공하여 경쟁할 수 있습니다. 팁이 높을수록 거래가 다음 블록으로 이동할 가능성이 높아집니다. 또한, 복잡한 스마트 계약 앱은 기능을 지원하기 위해 많은 작업을 수행할 수 있어 많은 가스를 소비할 수 있습니다. + +## 가스 비용 절감 이니셔티브 {#initiatives-to-reduce-gas-costs} + +이더리움 [확장성 업그레이드](/roadmap/)는 궁극적으로 일부 가스 수수료 문제를 해결하여 플랫폼이 초당 수천 건의 트랜잭션을 처리하고 전 세계적으로 확장할 수 있도록 해야 합니다. + +계층 2 스케일링은 가스 비용, 사용자 경험 및 확장성을 크게 개선하기 위한 주요 계획입니다. + +[레이어 2 확장에 대해 더 알아보기](/developers/docs/scaling/#layer-2-scaling) + +## 가스 수수료 모니터링 {#monitoring-gas-fees} + +가스 가격을 모니터링하여 ETH를 더 저렴하게 전송하려면 다음과 같은 다양한 도구를 사용할 수 있습니다. + +- [Etherscan](https://etherscan.io/gastracker) _트랜잭션 가스 가격 추정기_ +- [Blockscout](https://eth.blockscout.com/gas-tracker) _오픈 소스 트랜잭션 가스 가격 추정기_ +- [ETH 가스 추적기](https://www.ethgastracker.com/) _이더리움 및 L2 가스 가격을 모니터링하고 추적하여 거래 수수료를 줄이고 비용을 절약하세요_ +- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _유형 0 레거시 트랜잭션과 유형 2 EIP-1559 트랜잭션을 모두 지원하는 가스 추정 Chrome 확장 프로그램입니다._ +- [Cryptoneur 가스 수수료 계산기](https://www.cryptoneur.xyz/gas-fees-calculator) _메인넷, Arbitrum, Polygon에서 다양한 트랜잭션 유형에 대한 가스 수수료를 현지 통화로 계산합니다._ + +## 관련 도구 {#related-tools} + +- [Blocknative 가스 플랫폼](https://www.blocknative.com/gas) _Blocknative의 글로벌 멤풀 데이터 플랫폼으로 구동되는 가스 추정 API_ +- [가스 네트워크](https://gas.network) 온체인 가스 오라클. 35개 이상의 체인 지원. + +## 더 읽어보기 {#further-reading} + +- [이더리움 가스 설명](https://defiprime.com/gas) +- [스마트 계약의 가스 소비량 줄이기](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a) +- [개발자를 위한 가스 최적화 전략](https://www.alchemy.com/overviews/solidity-gas-optimization) +- [EIP-1559 문서](https://eips.ethereum.org/EIPS/eip-1559). +- [팀 베이코의 EIP-1559 관련 자료](https://hackmd.io/@timbeiko/1559-resources) +- [EIP-1559: 밈과 메커니즘 분리](https://web.archive.org/web/20241126205908/https://research.2077.xyz/eip-1559-separating-mechanisms-from-memes) diff --git a/public/content/translations/ko/developers/docs/ides/index.md b/public/content/translations/ko/developers/docs/ides/index.md new file mode 100644 index 00000000000..8297449dca6 --- /dev/null +++ b/public/content/translations/ko/developers/docs/ides/index.md @@ -0,0 +1,64 @@ +--- +title: "통합 개발 환경(IDE)" +description: "리믹스, VS Code 및 인기 플러그인을 비롯한 이더리움 개발용 웹 기반 및 데스크톱 IDE에 대해 알아보세요." +lang: ko +--- + +[통합 개발 환경(IDE)](https://wikipedia.org/wiki/Integrated_development_environment)을 설정할 때, 이더리움 애플리케이션을 프로그래밍하는 것은 다른 소프트웨어 프로젝트를 프로그래밍하는 것과 유사합니다. 선택할 수 있는 옵션이 많으므로, 최종적으로는 자신의 취향에 가장 적합한 IDE 또는 코드 편집기를 선택하세요. 이더리움 개발을 위한 가장 좋은 IDE 선택은 전통적인 소프트웨어 개발에 이미 사용 중인 IDE일 가능성이 큽니다. + +## 웹 기반 IDE {#web-based-ides} + +[로컬 개발 환경을 설정](/developers/local-environment/)하기 전에 코드를 만져보고 싶다면, 이 웹 앱들은 이더리움 스마트 계약 개발을 위해 맞춤 제작되었습니다. + +**[Remix](https://remix.ethereum.org/)** - **_정적 분석 기능 및 테스트 블록체인 가상 머신이 내장된 웹 기반 IDE_** + +- [문서](https://remix-ide.readthedocs.io/en/latest/#) +- [Gitter](https://gitter.im/ethereum/remix) + +**[ChainIDE](https://chainide.com/)** - **_클라우드 기반 멀티체인 IDE_** + +- [문서](https://chainide.gitbook.io/chainide-english-1/) +- [도움말 포럼](https://forum.chainide.com/) + +**[Replit (Solidity Starter - Beta)](https://replit.com/@replit/Solidity-starter-beta)** - **_핫 리로딩, 오류 검사 및 최고 수준의 테스트넷 지원을 갖춘 맞춤형 이더리움 개발 환경_** + +- [문서](https://docs.replit.com/) + +**[Tenderly Sandbox](https://sandbox.tenderly.co/)** - **_솔리디티(Solidity)와 자바스크립트(JavaScript)를 사용하여 브라우저에서 스마트 계약을 작성, 실행, 디버깅할 수 있는 빠른 프로토타이핑 환경_** + +**[EthFiddle](https://ethfiddle.com/)** - **_스마트 계약을 작성, 컴파일, 디버깅할 수 있는 웹 기반 IDE_** + +- [Gitter](https://gitter.im/loomnetwork/ethfiddle) + +## 데스크톱 IDE {#desktop-ides} + +가장 잘 알려진 IDE들은 이더리움 개발 경험을 향상시키기 위해 플러그인을 내장하고 있습니다. 최소한 [스마트 계약 언어](/developers/docs/smart-contracts/languages/)에 대한 구문 강조 기능을 제공합니다. + +**Visual Studio Code -** **_이더리움(Ethereum)을 공식 지원하는 전문 크로스플랫폼 IDE_** + +- [Visual Studio Code](https://code.visualstudio.com/) +- [코드 샘플](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md) +- [GitHub](https://github.com/microsoft/vscode) + +**JetBrains IDEs (IntelliJ IDEA 등)** -\*\* **_소프트웨어 개발자와 팀을 위한 필수 도구_** + +- [JetBrains](https://www.jetbrains.com/) +- [GitHub](https://github.com/JetBrains) +- [IntelliJ Solidity](https://github.com/intellij-solidity/intellij-solidity/) + +**Remix Desktop -** **_로컬 컴퓨터에서 Remix IDE를 경험해 보세요_** + +- [다운로드](https://github.com/ethereum/remix-desktop/releases) +- [GitHub](https://github.com/ethereum/remix-desktop) + +## 플러그인 및 확장 프로그램 {#plugins-extensions} + +- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - Visual Studio Code용 이더리움 솔리디티 언어 +- [Solidity + Hardhat for VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) - Hardhat 팀의 솔리디티 및 Hardhat 지원 +- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) - Prettier를 사용하는 코드 포맷터 + +## 더 읽어보기 {#further-reading} + +- [Ethereum IDEs](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _- Alchemy의 이더리움 IDE 목록_ + +_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_ diff --git a/public/content/translations/ko/developers/docs/index.md b/public/content/translations/ko/developers/docs/index.md new file mode 100644 index 00000000000..ed6eb74d03e --- /dev/null +++ b/public/content/translations/ko/developers/docs/index.md @@ -0,0 +1,25 @@ +--- +title: "이더리움 개발 문서" +description: "ethereum.org 개발자 문서를 소개합니다." +lang: ko +--- + +이 문서는 이더리움 개발에 도움을 주기 위해 작성되었습니다. 이 문서는 이더리움의 개념, 이더리움 기술 스택에 대한 설명 그리고 더욱 복잡한 어플리케이션과 유스케이스를 위한 심화 주제를 다루고 있습니다. + +이 문서는 오픈소스 커뮤니티로 유지됩니다. 따라서 새로운 주제를 제안하거나, 새로운 내용을 추가하거나, 여러분이 생각하기에 도움이 될만한 예시를 추가하는데 주저하지 마시기 바랍니다. 모든 개발문서는 GitHub를 통해 수정할 수 있습니다. 방법을 잘 모르는 경우, [다음 지침을 따르세요](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md). + +## 개발 모듈 {#development-modules} + +여러분이 처음으로 이더리움 개발에 처음이라면, 책으로 공부하는 것처럼 여러분만의 방식으로 시작하길 추천합니다. + +### 기본 주제 {#foundational-topics} + + + +### 이더리움 스택 {#ethereum-stack} + + + +### 고급 {#advanced} + + diff --git a/public/content/translations/ko/developers/docs/intro-to-ether/index.md b/public/content/translations/ko/developers/docs/intro-to-ether/index.md new file mode 100644 index 00000000000..db5f62e9504 --- /dev/null +++ b/public/content/translations/ko/developers/docs/intro-to-ether/index.md @@ -0,0 +1,78 @@ +--- +title: "이더에 대한 기술적 소개" +description: "개발자를 위한 이더 암호화폐에 대한 소개" +lang: ko +--- + +## 필수 구성 요소 {#prerequisites} + +이 페이지를 더 잘 이해하기 위해 [이더리움 소개](/developers/docs/intro-to-ethereum/)를 먼저 읽어보시는 것을 권장합니다. + +## 암호화폐란 무엇인가요? {#what-is-a-cryptocurrency} + +암호화폐는 블록체인 기반의 원장으로 보호되는 교환 매체입니다. + +교환 매체란 상품 및 서비스에 대한 지불 수단으로 인정되는 모든 것을 통칭하며, 원장은 거래를 추적하는 데이터 저장소를 의미합니다. 블록체인 기술을 통해, 사용자는 제 3자에게 원장을 믿고 맡길 필요 없이 원장에서의 트랜잭션을 수행할 수 있습니다. + +최초의 암호화폐는 사토시 나카모토가 만든 비트코인입니다. 2009년 비트코인이 ​​출시된 이후, 사람들은 다양한 블록체인에서 수천 개의 암호화폐를 만들었습니다. + +## 이더는 무엇인가? {#what-is-ether} + +\*\*이더(ETH)\*\*는 이더리움 네트워크의 여러 곳에서 사용되는 암호화폐입니다. 기본적으로 거래 수수료에 대해 허용되는 유일한 지불 형식이며, [머지](/roadmap/merge) 이후 메인넷에서 블록을 검증하고 제안하려면 이더가 필요합니다. 이더는 [DeFi](/defi) 대출 시장에서 기본 담보 형태로 사용되고, NFT 마켓플레이스에서 계산 단위로, 서비스 수행 또는 실물 상품 판매에 대한 대가로 사용되는 등 다양한 용도로 활용됩니다. + +이더리움을 통해 개발자는 모두가 컴퓨팅 파워 풀을 공유하는 [**탈중앙화 애플리케이션(탈중앙화앱)**](/developers/docs/dapps)을 만들 수 있습니다. 이 공유 풀은 유한하므로, 누가 그것을 사용할지 결정하는 메커니즘이 필요합니다. 그렇지 않으면 어느 디앱이 실수로 또는 악의적으로 모든 네트워크 리소스를 써버릴 수 있고, 이는 다른 앱들이 리소스를 사용할 수 없도록 방해합니다. + +이더 암호화폐는 이더리움의 컴퓨팅 파워에 대한 가격 책정 메커니즘을 지원합니다. 사용자가 트랜잭션을 발생시키고자 한다면, 이더를 지불해야 블록체인에서 해당 트랜재션이 인식됩니다. 이러한 사용 비용은 [가스비](/developers/docs/gas/)로 알려져 있으며, 가스비는 트랜잭션 실행에 필요한 컴퓨팅 파워의 양과 당시 네트워크 전체의 컴퓨팅 파워 수요에 따라 달라집니다. + +따라서 악의적인 디앱이 무한 루프를 돌며 트랜잭션을 발생시키더라도, 해당 트랜잭션이 이더를 모두 소모한 후엔 결국 종료하게 되고, 이러한 메커니즘은 이더리움 네트워크가 정상으로 돌아갈 수 있도록 합니다. + +이더리움과 이더를 [혼동하는 것이 일반적입니다](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845). 사람들이 "이더리움의 가격"을 언급할 때, 그들은 이더의 가격을 말하는 것입니다. + +## 이더 민팅 {#minting-ether} + +발행은 이더리움 원장에 새로운 이더가 생성되는 과정을 말합니다. 이더리움 프로토콜이 새로운 이더를 생성하며, 사용자가 이더를 생성하는 것은 불가능합니다. + +이더는 제안된 각 블록과 합의에 도달하는 것과 관련된 다른 검증자 활동에 대한 모든 에포크 체크포인트에 대한 보상으로 주조된다. 발행된 총 금액은 검증자의 수와 그들이 얼마나 지분을 걸었는지에 따라 달라진다. 이 총 발행량은 모든 검증자가 정직하고 온라인인 이상적인 경우 검증자 간에 균등하게 분배되지만, 실제로는 검증자 성과에 따라 다르다. 전체 발행의 약 8분의 1은 블록 제안자에게 전달되고 나머지는 다른 검증자들에게 분배된다. 블록 제안자들은 거래 수수료와 MEV 관련 소득에서도 팁을 받지만, 이들은 신규 발행이 아닌 재활용 이더에서 나온다. + +## 이더 소각 {#burning-ether} + +블록 보상을 통해 이더를 생성하는 것 외에도 '소각'이라는 과정을 통해 이더를 소멸시킬 수 있습니다. 이더가 소각되면 네트워크에서 영구적으로 제거된다. + +이더 소각은 이더리움의 모든 트랜잭션에서 발생한다. 사용자가 트랜잭션에 대해 비용을 지불하면 기본 가스비가 소각되며, 이 기본 가스비는 네트워크상의 거래 수요에 따라 정해집니다. 여기에 블록 크기와 최대 가스비까지 연관되어, 이더리움상의 거래 수수료를 측정하는 것이 단순해집니다, 네트워크 수요가 높을 때, [블록](https://eth.blockscout.com/block/22580057)은 민팅하는 것보다 더 많은 이더를 소각할 수 있으며, 이는 효과적으로 이더 발행을 상쇄합니다. + +기본 수수료를 소각하면 블록 생성자가 트랜잭션을 조작하는 것을 방해합니다. 예를 들어, 블록 생산자들이 기본료를 받았다면, 그들은 그들 자신의 거래를 무료로 포함시킬 수 있고 다른 모든 사람들을 위한 기본료를 올릴 수 있다. 또는 일부 사용자에게 기본 수수료를 오프체인으로 환불하여 더 불투명하고 복잡한 거래 수수료 시장으로 이어질 수 있습니다. + +## 이더의 단위 {#denominations} + +이더리움의 많은 트랜잭션 가치는 작기 때문에, 이더는 더 작은 계산 단위로 참조될 수 있는 여러 단위를 가지고 있습니다. 그 중에서 Wei와 Gwei가 특히 중요하다. + +웨이는 가능한 가장 작은 이더 단위이며, 그 결과 [이더리움 옐로페이퍼](https://ethereum.github.io/yellowpaper/paper.pdf)와 같은 많은 기술적 구현은 모든 계산을 웨이 기준으로 합니다. + +Gwei는 giga-wei의 줄임말로 이더리움의 가스비를 설명하는 데 자주 사용된다. + +| 단위 | 이더 가치 | 목적 | +| ---- | ---------------- | ---------------- | +| Wei | 10-18 | 기술적 구현 | +| Gwei | 10-9 | 사람이 읽기 쉬운 가스비 단위 | + +## 이더 전송하기 {#transferring-ether} + +이더리움의 각 트랜잭션에는 `value` 필드가 포함되어 있으며, 이 필드는 보내는 사람의 주소에서 받는 사람의 주소로 전송될 이더의 양을 웨이 단위로 지정합니다. + +수신 주소가 [스마트 계약](/developers/docs/smart-contracts/)인 경우, 전송된 이더는 스마트 계약이 코드를 실행할 때 가스비를 지불하는 데 사용될 수 있습니다. + +[트랜잭션에 대해 더 알아보기](/developers/docs/transactions/) + +## 이더 조회하기 {#querying-ether} + +사용자는 계정의 `balance` 필드를 확인하여 모든 [계정](/developers/docs/accounts/)의 이더 잔액을 조회할 수 있으며, 이 필드는 웨이로 표시된 이더 보유량을 보여줍니다. + +[Etherscan](https://etherscan.io)과 [Blockscout](https://eth.blockscout.com)은 웹 기반 애플리케이션을 통해 주소 잔액을 확인할 수 있는 인기 있는 도구입니다. 예를 들어, [이 Blockscout 페이지](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe)는 이더리움 재단의 잔액을 보여줍니다. 계정 잔액은 지갑을 사용하거나 노드에 요청하여 직접 조회할 수도 있습니다. + +## 더 읽어보기 {#further-reading} + +- [이더와 이더리움 정의하기](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_ +- [이더리움 백서](/whitepaper/): 이더리움의 최초 제안서입니다. 이 문서는 이더에 대한 설명과 그 탄생 비화를 포함하고 있습니다. +- [Gwei 계산기](https://www.alchemy.com/gwei-calculator): 이 gwei 계산기를 사용하여 웨이, gwei, 이더를 쉽게 변환할 수 있습니다. wei, gwei 또는 ETH의 임의의 양을 입력만 하면 변환이 자동으로 계산됩니다. + +_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_ diff --git a/public/content/translations/ko/developers/docs/intro-to-ethereum/index.md b/public/content/translations/ko/developers/docs/intro-to-ethereum/index.md new file mode 100644 index 00000000000..edb2d5e0db6 --- /dev/null +++ b/public/content/translations/ko/developers/docs/intro-to-ethereum/index.md @@ -0,0 +1,124 @@ +--- +title: "이더리움에 대한 기술적 소개" +description: "이더리움의 핵심 개념에 대한 디앱 개발자의 소개" +lang: ko +--- + +## 블록체인이란 무엇인가요? 블록체인이란 무엇인가요? + +블록체인은 네트워크 상의 많은 컴퓨터들에 업데이트되고 공유되는 공공의 데이터베이스입니다. + +"블록"은 "블록들"이라고 하는 연속된 그룹에 저장된 데이터와 상태를 말합니다. ETH를 다른 사람에게 보내는 경우, 트랜잭션 데이터를 블록에 추가해야 성공적으로 보낼 수 있습니다. + +"체인"은 각각의 블록이 암호화된 방식으로 자신의 부모를 참조한다는 것을 말한다. 다시 말해, 블록들은 서로 체인 형태로 연결됩니다. 블록의 데이터를 변경하려면 모든 후속 블록을 변경해야만 하며, 이러한 과정은 네트워크 전체가 합의해야만 이루어집니다. + +네트워크 안의 모든 컴퓨터는 새로 생성되는 블록과 전체 체인에 대해서 반드시 합의해야만 합니다. 이 컴퓨터들을 "노드"라고 합니다. 노드는 블록체인과 상호 작용하는 모든 사람이 동일한 데이터를 갖도록 합니다. 이렇게 분산된 합의를 이루기 위해, 블록체인은 합의 메커니즘이 필요합니다. + +이더리움은 [지분 증명 기반 합의 메커니즘](/developers/docs/consensus-mechanisms/pos/)을 사용합니다. 체인에 새로운 블록을 추가하려는 사람은 이더리움의 기축 통화인 ETH를 담보로 스테이킹하고 검증 소프트웨어를 실행해야 합니다. 이러한 "검증자"는 무작위로 선택되어 다른 검증자가 블록을 확인하고 블록체인에 추가할 블록을 제안할 수 있습니다. 참가자들이 온라인에서 최대한 정직하게 정보를 제공하도록 강력하게 장려하는 보상 및 패널티 시스템이 있습니다. + +블록체인 데이터가 어떻게 해시되고 이후 블록 참조 기록에 추가되는지 알고 싶다면 Anders Brownworth의 [이 데모](https://andersbrownworth.com/blockchain/blockchain)를 확인하고 아래에 첨부된 비디오를 시청하세요. + +블록체인의 해시에 대한 Anders의 설명 영상을 확인해보세요. + + + +## 이더리움이란? 이더리움이란 무엇인가요? + +이더리움은 컴퓨터가 내장된 블록체인입니다. 그것은 분산되고 허가 없이 검열에 저항하는 방식으로 앱과 조직을 구축하기 위한 기반입니다. + +이더리움 세상에는 이더리움 네트워크 상의 모두가 동의하는 상태를 가지는 (이더리움 가상 머신, 또는 EVM이라고 부르는) 하나의 정식 컴퓨터가 있습니다. 이더리움 네트워크에 참여하는 모두(모든 이더리움 노드)는 이 컴퓨터 상태의 복사본을 보관합니다. 또한, 모든 참여자는 이 컴퓨터에 대한 요청을 브로드캐스트하여 임의의 계산을 수행할 수 있습니다. 이러한 요청이 브로드캐스트 될 때마다, 네트워크상의 다른 참가자들은 이 연산을 확인, 검증 및 "실행"합니다. 이 실행은 네트워크 전체에 전파되고, EVM의 상태 변화를 일으킵니다. + +이렇게 연산을 위한 요청들을 트랜잭션 요청이라고 합니다. 모든 트랜잭션에 대한 기록과 EVM의 현재 상태가 블록체인에 저장되고, 결과적으로 이러한 내용은 모든 노드들에 의해 저장되고 합의됩니다. + +트랜잭션이 한번 검증되고 블록체인에 추가되면, 암호학적으로 더 이상 변경될 수 없음이 보장됩니다. 같은 방식으로, 적절한 "권한"이 있어야만 트랜잭션을 서명하고 실행할 수 있음이 보장됩니다. (Alice가 아닌 어떤 누구도 Alice의 계정에 있는 디지털 자산을 전송할 수 있어서는 안 됩니다.) + +## 이더는 무엇인가? {#what-is-ether} + +\*\*이더(ETH)\*\*는 이더리움의 네이티브 암호화폐입니다. ETH의 목적은 계산을 위한 시장을 허용하는 것이다. 시장에서는 참가자들이 네트워크에 컴퓨터 자원을 제공하고 트랜잭션을 검증/실행한 데에 대한 경제적 보상을 제공합니다. + +트랜잭션 요청을 브로드캐스트하는 참가자는 네트워크에 현상금으로서 이더를 제공해야합니다. 네트워크는 보상의 일부를 소각하고 트랜잭션을 검증, 실행, 블록체인에 커밋, 네트워크에 브로드캐스팅하는 작업을 최종적으로 수행하는 사람에게 나머지를 수여합니다. + +연산에 들어간 시간에 따라 지불하는 이더의 양이 정해집니다. 이는 또한 악의적인 참가자들이 무한 루프나 리소스가 많이 소모되는 스크립트의 실행을 요청함으로써 고의로 네트워크를 막히도록 하는 것을 이들 행위자에게 계속 지불되게 함으로써 예방한다. + +ETH는 또한 세 가지 주요 방식으로 네트워크에 암호경제학적 보안을 제공하는 데 사용됩니다. 1) 블록을 제안하거나 다른 검증자의 부정 행위를 지적하는 검증자에게 보상하는 수단으로 사용됩니다. 2) 부정 행위에 대한 담보 역할을 하도록 검증자에 의해 스테이킹됩니다. 만약 검증자가 부정하게 행동하려고 시도하면 해당 ETH는 소각될 수 있습니다. 3) 합의 메커니즘의 포크 선택 부분에 반영되어, 새로 제안된 블록에 대한 '투표'에 가중치를 부여하는 데 사용됩니다. + +## 스마트 계약이란 무엇입니까? 스마트 계약이란 무엇인가요? + +EVM상의 연산을 요청하기 위해서 참가자들이 새로운 코드를 실제로 쓰지는 않습니다. 어플리케이션 개발자들이 EVM 상태에 프로그램(재사용 가능한 코드조각)을 올려두고, 사용자들이 이 프로그램에 다양한 값을 입력해서 사용합니다. 네트워크에 업로드되어 실행되는 프로그램을 "스마트 계약"이라고 부릅니다. + +쉽게 말해서, 스마트 컨트랙트는 자판기로 볼 수 있습니다. 특정 값이 들어오면, 정해진 행동을 하거나 어떤 조건이 충족됐을 때 연산을 합니다. 예를 들어, 간단한 벤더 스마트 컨트랙트는 호출자가 특정 수신자에게 이더를 보내면 어떤 디지털 자산의 소유권을 생성하고 할당할 수 있습니다. + +아무 개발자나 스마트 컨트랙트를 만들어 네트워크에 공개할 수 있고, 사용료를 네트워크에 지불하고 블록체인을 자체 데이터 계층으로서 활용할 수 있습니다. 또, 아무 사용자나 네트워크에 사용료를 지불하면, 이 스마트 컨트랙트를 실행할 수 있습니다. + +즉, 개발자들은 마켓플레이스나 금융 서비스, 게임과 같은 복잡한 앱이나 서비스를 스마트 컨트랙트를 사용해서 개발하고 배포할 수 있습니다. + +## 용어 {#terminology} + +### 블록체인 {#blockchain} + +이더리움 네트워크가 시작된 이례로 이더리움 네트워크에 제출된 모든 블록들의 순서들. 각 블록들이 그 이전 블록을 참조를 포함하고 있어서 이렇게 이름 붙었습니다. 이러한 이전 블록에 대한 참조는 모든 블록의 순서를 (정확한 내역을) 관리할 수 있도록 합니다. + +### ETH {#eth} + +\*\*이더(ETH)\*\*는 이더리움의 네이티브 암호화폐입니다. 사용자는 다른 사용자들에게 그들의 코드를 실행해달라고 요청하기 위해서 이더를 지불합니다. + +[ETH에 대해 더 알아보기](/developers/docs/intro-to-ether/) + +### EVM {#evm} + +이더리움 가상 머신은 이더리움 네트워크의 모든 사용자가 상태를 저장하고 합의하는 가상의 글로벌 컴퓨터입니다. 어떤 참가자나 EVM 상의 임의의 코드를 실행 요청할 수 있습니다. 코드 실행은 EVM의 상태를 바꿉니다. + +[EVM에 대해 더 알아보기](/developers/docs/evm/) + +### 노드 {#nodes} + +EVM 상태를 저장하는 실제 머신. 노드들은 각자와 EVM 상태와 새로운 상태 변화에 대한 정보를 퍼뜨리기 위해서 통신합니다. 어느 사용자나 코드 노드로부터 실행 요청을 브로드캐스트해서 코드 실행을 요청할 수 있습니다. 이더리움 네트워크 그 자체는 모든 이더리움 노드들과 그들의 통신의 집합체를 말합니다. + +[노드에 대해 더 알아보기](/developers/docs/nodes-and-clients/) + +### 계정 {#accounts} + +이더가 저장되는 곳. 사용자는 계정을 초기화하고, 계정 안에 이더를 입금하고, 자신의 계정에서 다른 사용자에게 이더를 송금할 수 있습니다. 계정과 계정 잔고는 EVM 내의 큰 테이블에 저장됩니다. 계정과 계정 잔고는 전체 EVM 상태 중 일부입니다. + +[계정에 대해 더 알아보기](/developers/docs/accounts/) + +### 트랜잭션 {#transactions} + +"트랜잭션 요청"이란 EVM상의 코드 실행 요청을 가리키는 용어입니다. "트랜잭션"이란 수행된 트랜잭션 요청과, 그에 관련된 EVM 상태 변화를 의미합니다. 어떤 사용자든 노드로부터 네트워크로 트랜잭션 요청을 브로드캐스트 할 수 있습니다. 합의되어 있는 EVM 상태에 트랜잭션 요청이 실제 영향을 미치기 위해서, 그는 반드시 유효성이 검사되고, 실행되며 다른 노드들에 의해 “네트워크에 제출되어야” 한다. 어떤 코드의 실행은 EVM 내의 상태 변화를 일으킨다; 제출 시 이 상태 변화는 네트워크 내의 모든 노드로 브로드캐스트 된다. 트랜잭션의 예제: + +- 내 계정에서 앨리스의 계정으로 X 이더를 보냄 +- EVM 메모리내로 어떤 스마트 컨트랙트 코드를 발행 +- EVM 내의 주소 X에서 스마트 컨트랙트 코드를 Y 인자로 실행. + +[트랜잭션에 대해 더 알아보기](/developers/docs/transactions/) + +### 블록 {#blocks} + +트랜잭션의 양은 매우 많아서 트랜잭션들은 한번에 모아서 또는 블록으로 “제출된다”. 블록들은 일반적으로 수백개의 트랜잭션을 담는다. + +[블록에 대해 더 알아보기](/developers/docs/blocks/) + +### 스마트 계약 {#smart-contracts} + +개발자들이 EVM 메모리로 발행하는 재사용 가능한 코드 조각(프로그램). 누구나 트랜잭션 요청을 해서 실행될 스마트 컨트랙트 코드 실행을 요청할 수 있다. 개발자는 EVM에 임의로 실행 가능한 애플리케이션(게임, 마켓플레이스, 금융 상품 등)을 작성할 수 있기 때문에 스마트 계약을 게시함으로써, 이것들은 종종 [디앱(dapp) 또는 탈중앙화 앱](/developers/docs/dapps/)이라고도 불립니다. + +[스마트 계약에 대해 더 알아보기](/developers/docs/smart-contracts/) + +## 더 읽어보기 {#further-reading} + +- [이더리움 백서](/whitepaper/) +- [이더리움은 어떻게 작동하는가?](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasireddy_ (**참고** 이 자료는 여전히 유용하지만 [병합](/roadmap/merge) 이전에 작성되어 이더리움의 작업 증명 메커니즘을 여전히 참조하고 있다는 점을 인지하시기 바랍니다. 이더리움은 현재 [지분 증명](/developers/docs/consensus-mechanisms/pos)을 사용하여 보안이 유지됩니다.) + +### 시각 자료를 찾고 있나요? 시각적 학습자 + +이 비디오 시리즈는 기초 주제에 대한 심층적인 탐구를 제공합니다. + + + +[이더리움 기초 플레이리스트](https://youtube.com/playlist?list=PLqgutSGloqiJyyoL0zvLVFPS-GMD2wKa5&si=kZTf5I7PKGTXDsOZ) + +_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_ + +## 관련 튜토리얼 {#related-tutorials} + +- [이더리움 개발자 가이드, 1부](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– Python과 web3.py를 사용해 이더리움을 탐구하는 아주 초보자 친화적인 자료_ diff --git a/public/content/translations/ko/developers/docs/mev/index.md b/public/content/translations/ko/developers/docs/mev/index.md new file mode 100644 index 00000000000..92c1e441ef3 --- /dev/null +++ b/public/content/translations/ko/developers/docs/mev/index.md @@ -0,0 +1,221 @@ +--- +title: "최대 추출 가능 값(MEV)" +description: "최대 추출 가능 값(MEV)에 대한 소개" +lang: ko +--- + +최대 추출 가능 가치(MEV)는 블록 내 트랜잭션의 포함, 제외 및 순서 변경을 통해 표준 블록 보상 및 가스 수수료를 초과하여 블록 생성에서 추출할 수 있는 최대 가치를 의미합니다. + +## 최대 추출 가능 가치 {#maximal-extractable-value} + +최대 추출 가능 가치는 [작업 증명](/developers/docs/consensus-mechanisms/pow/)의 맥락에서 처음 적용되었으며, 처음에는 "채굴자 추출 가능 가치"라고 불렸습니다. 작업 증명에서는 채굴자가 트랜잭션 포함, 제외, 순서를 제어하기 때문입니다. 하지만 [병합](/roadmap/merge)을 통한 지분 증명으로의 전환 이후, 검증자가 이러한 역할을 담당하게 되었으며 채굴은 더 이상 이더리움 프로토콜의 일부가 아닙니다. 그러나 가치 추출 방법은 여전히 존재하므로, 이제는 "최대 추출 가능 가치"라는 용어가 대신 사용됩니다. + +## 필수 구성 요소 {#prerequisites} + +[트랜잭션](/developers/docs/transactions/), [블록](/developers/docs/blocks/), [지분 증명](/developers/docs/consensus-mechanisms/pos), [가스](/developers/docs/gas/)에 대해 숙지하시기 바랍니다. [디앱스](/apps/)와 [디파이](/defi/)에 익숙하다면 도움이 될 것입니다. + +## MEV 추출 {#mev-extraction} + +이론적으로 수익성 있는 MEV 기회의 실행을 보장할 수 있는 유일한 주체는 검증자이므로 MEV는 전적으로 검증자에게 귀속됩니다. 하지만 실제로는 MEV의 상당 부분이 "검색자"라고 불리는 독립적인 네트워크 참여자에 의해 추출됩니다. 검색자는 블록체인 데이터에 복잡한 알고리즘을 실행하여 수익성 있는 MEV 기회를 감지하고, 해당 수익성 트랜잭션을 네트워크에 자동으로 제출하는 봇을 보유하고 있습니다. + +검색자는 수익성 있는 트랜잭션이 블록에 포함될 가능성을 높이는 대가로 높은 가스 수수료(검증자에게 지급됨)를 기꺼이 지불하기 때문에, 검증자는 어쨌든 전체 MEV 금액의 일부를 받게 됩니다. 검색자가 경제적으로 합리적이라고 가정하면, 검색자가 기꺼이 지불하려는 가스 수수료는 검색자 MEV의 최대 100%에 달하는 금액이 될 것입니다(가스 수수료가 더 높으면 검색자는 손해를 보기 때문입니다). + +따라서 [DEX 차익거래](#mev-examples-dex-arbitrage)와 같이 경쟁이 치열한 일부 MEV 기회의 경우, 많은 사람이 동일한 수익성 있는 차익거래를 실행하기를 원하기 때문에 검색자는 총 MEV 수익의 90% 이상을 검증자에게 가스 수수료로 지불해야 할 수도 있습니다. 자신의 차익거래 트랜잭션 실행을 보장할 수 있는 유일한 방법은 가장 높은 가스 가격으로 트랜잭션을 제출하는 것이기 때문입니다. + +### 가스 골핑 {#mev-extraction-gas-golfing} + +이러한 역학 관계는 "가스 골핑", 즉 트랜잭션을 프로그래밍하여 최소한의 가스를 사용하도록 하는 능력을 경쟁 우위로 만들었습니다. 이를 통해 검색자는 총 가스 수수료를 일정하게 유지하면서 더 높은 가스 가격을 설정할 수 있기 때문입니다(가스 수수료 = 가스 가격 \* 사용된 가스). + +잘 알려진 가스 골프 기술 몇 가지는 다음과 같습니다. 0으로 시작하는 긴 문자열의 주소([0x0000000000C521824EaFf97Eac7B73B084ef9306](https://eth.blockscout.com/address/0x0000000000C521824EaFf97Eac7B73B084ef9306) 등)를 사용하면 저장 공간(따라서 가스)이 덜 들기 때문에 이를 사용하고, 저장 공간 슬롯을 업데이트하는 것보다 초기화(잔액이 0인 경우)하는 데 더 많은 가스가 들기 때문에 계약에 소량의 [ERC-20](/developers/docs/standards/tokens/erc-20/) 토큰 잔액을 남겨두는 것 등이 있습니다. 가스 사용량을 줄이기 위한 더 많은 기술을 찾는 것은 검색자들 사이에서 활발한 연구 분야입니다. + +### 일반화된 프론트러너 {#mev-extraction-generalized-frontrunners} + +일부 검색자는 수익성 있는 MEV 기회를 감지하기 위해 복잡한 알고리즘을 프로그래밍하는 대신 일반화된 프론트러너를 실행합니다. 일반화된 프론트러너는 멤풀을 감시하여 수익성 있는 트랜잭션을 감지하는 봇입니다. 프론트러너는 잠재적으로 수익성이 있는 트랜잭션의 코드를 복사하고, 주소를 프론트러너의 주소로 교체한 다음, 트랜잭션을 로컬에서 실행하여 수정된 트랜잭션이 프론트러너의 주소에 이익을 가져다주는지 다시 한번 확인합니다. 트랜잭션이 실제로 수익성이 있는 경우, 프론트러너는 교체된 주소와 더 높은 가스 가격으로 수정된 트랜잭션을 제출하여 원래 트랜잭션을 "선행매매"하고 원래 검색자의 MEV를 획득합니다. + +### Flashbots {#mev-extraction-flashbots} + +Flashbots는 실행 클라이언트를 확장하여 검색자가 공개 멤풀에 노출하지 않고도 검증자에게 MEV 트랜잭션을 제출할 수 있는 서비스를 제공하는 독립 프로젝트입니다. 이를 통해 일반화된 프론트러너에 의한 트랜잭션 선행매매를 방지할 수 있습니다. + +## MEV 예시 {#mev-examples} + +MEV는 몇 가지 방식으로 블록체인에서 나타납니다. + +### DEX 차익거래 {#mev-examples-dex-arbitrage} + +[탈중앙화 거래소](/glossary/#dex)(DEX) 차익거래는 가장 간단하고 가장 잘 알려진 MEV 기회입니다. 결과적으로, 가장 경쟁이 치열하기도 합니다. + +작동 방식은 다음과 같습니다. 두 개의 DEX가 토큰을 서로 다른 가격으로 제공하는 경우, 누군가는 가격이 낮은 DEX에서 토큰을 구매하고 가격이 높은 DEX에서 단일 원자적 트랜잭션으로 판매할 수 있습니다. 블록체인의 메커니즘 덕분에 이것은 진정한 무위험 차익거래입니다. + +Uniswap과 Sushiswap에서 ETH/DAI 페어의 다른 가격 책정을 활용하여 검색자가 1,000 ETH를 1,045 ETH로 바꾼 수익성 있는 차익거래 트랜잭션의 [예시](https://eth.blockscout.com/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4)입니다. + +### 청산 {#mev-examples-liquidations} + +대출 프로토콜 청산은 또 다른 잘 알려진 MEV 기회를 제공합니다. + +Maker나 Aave와 같은 대출 프로토콜은 사용자가 담보(예: ETH)를 예치하도록 요구합니다. 이 예치된 담보는 다른 사용자에게 대출해 주는 데 사용됩니다. + +그런 다음 사용자는 예치된 담보의 특정 비율까지 필요한 것에 따라 다른 사람으로부터 자산과 토큰을 빌릴 수 있습니다(예: MakerDAO 거버넌스 제안에 투표하려면 MKR을 빌릴 수 있습니다). 예를 들어, 대출 금액이 최대 30%인 경우, 프로토콜에 100 DAI를 예치한 사용자는 다른 자산으로 최대 30 DAI 상당을 빌릴 수 있습니다. 프로토콜이 정확한 대출 능력 비율을 결정합니다. + +차용인의 담보 가치가 변동함에 따라 대출 능력도 변동합니다. 만약 시장 변동으로 인해 빌린 자산의 가치가 담보 가치의 30%(다시 말하지만, 정확한 비율은 프로토콜에 의해 결정됨)를 초과하면, 프로토콜은 일반적으로 누구나 담보를 청산하여 즉시 대출자에게 상환할 수 있도록 허용합니다(이는 전통적인 금융에서 [마진 콜](https://www.investopedia.com/terms/m/margincall.asp)이 작동하는 방식과 유사합니다). 청산될 경우, 차용인은 보통 막대한 청산 수수료를 지불해야 하며, 그 중 일부는 청산인에게 돌아갑니다. 바로 여기서 MEV 기회가 발생합니다. + +검색자들은 블록체인 데이터를 최대한 빨리 분석하여 어떤 차용인이 청산될 수 있는지 파악하고, 가장 먼저 청산 트랜잭션을 제출하여 청산 수수료를 챙기기 위해 경쟁합니다. + +### 샌드위치 거래 {#mev-examples-sandwich-trading} + +샌드위치 거래는 MEV 추출의 또 다른 일반적인 방법입니다. + +샌드위치 거래를 하기 위해, 검색자는 멤풀에서 대규모 DEX 거래를 주시합니다. 예를 들어, 누군가 Uniswap에서 DAI로 10,000 UNI를 구매하고 싶다고 가정해 봅시다. 이 정도 규모의 거래는 UNI/DAI 페어에 상당한 영향을 미쳐 DAI 대비 UNI의 가격을 크게 상승시킬 수 있습니다. + +검색자는 이 대규모 거래가 UNI/DAI 페어에 미치는 대략적인 가격 효과를 계산하고 대규모 거래 직전에 최적의 매수 주문을 실행하여 UNI를 저렴하게 구매한 다음, 대규모 거래 직후에 매도 주문을 실행하여 대규모 주문으로 인해 높아진 가격에 판매할 수 있습니다. + +그러나 샌드위치 거래는 (위에서 설명한 DEX 차익거래와 달리) 원자적이지 않고 [살모넬라 공격](https://github.com/Defi-Cartel/salmonella)에 취약하기 때문에 더 위험합니다. + +### NFT MEV {#mev-examples-nfts} + +NFT 분야의 MEV는 새로운 현상이며, 반드시 수익성이 있는 것은 아닙니다. + +하지만 NFT 트랜잭션은 다른 모든 이더리움 트랜잭션과 공유되는 동일한 블록체인에서 발생하므로, 검색자는 기존 MEV 기회에서 사용된 것과 유사한 기술을 NFT 시장에서도 사용할 수 있습니다. + +예를 들어, 인기 있는 NFT 드롭이 있고 검색자가 특정 NFT 또는 NFT 세트를 원하는 경우, NFT를 가장 먼저 구매하도록 트랜잭션을 프로그래밍하거나 단일 트랜잭션으로 전체 NFT 세트를 구매할 수 있습니다. 또는 NFT가 [실수로 낮은 가격에 등록](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent)된 경우, 검색자는 다른 구매자를 선행매매하여 저렴하게 구매할 수 있습니다. + +NFT MEV의 한 가지 두드러진 예는 한 검색자가 700만 달러를 들여 모든 크립토펑크(Cryptopunk)를 최저가에 [구매](https://eth.blockscout.com/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5?tab=txs)했을 때 발생했습니다. 한 블록체인 연구원은 [트위터에서](https://twitter.com/IvanBogatyy/status/1422232184493121538) 구매자가 MEV 제공업체와 협력하여 구매를 비밀로 유지한 방법을 설명했습니다. + +### 롱테일 {#mev-examples-long-tail} + +DEX 차익거래, 청산, 샌드위치 거래는 모두 매우 잘 알려진 MEV 기회이며 새로운 검색자에게는 수익성이 없을 가능성이 높습니다. 그러나 덜 알려진 MEV 기회의 롱테일이 있습니다(NFT MEV가 바로 그러한 기회 중 하나라고 할 수 있습니다). + +이제 막 시작하는 검색자들은 이 롱테일에서 MEV를 검색함으로써 더 많은 성공을 거둘 수 있습니다. Flashbot의 [MEV 채용 게시판](https://github.com/flashbots/mev-job-board)에는 몇 가지 새로운 기회가 나열되어 있습니다. + +## MEV의 효과 {#effects-of-mev} + +MEV가 모두 나쁜 것은 아닙니다. 이더리움의 MEV에는 긍정적인 결과와 부정적인 결과가 모두 있습니다. + +### 장점 {#effects-of-mev-the-good} + +많은 디파이 프로젝트는 프로토콜의 유용성과 안정성을 보장하기 위해 경제적으로 합리적인 행위자에게 의존합니다. 예를 들어, DEX 차익거래는 사용자가 자신의 토큰에 대해 가장 정확하고 최고의 가격을 받을 수 있도록 보장하고, 대출 프로토콜은 차용인이 담보 비율 아래로 떨어졌을 때 신속한 청산에 의존하여 대출자가 상환받을 수 있도록 보장합니다. + +경제적 비효율성을 찾아 수정하고 프로토콜의 경제적 인센티브를 활용하는 합리적인 검색자가 없다면, 디파이 프로토콜과 디앱스 전반이 오늘날처럼 견고하지 못할 수 있습니다. + +### 단점 {#effects-of-mev-the-bad} + +애플리케이션 레이어에서 샌드위치 거래와 같은 일부 MEV 형태는 사용자에게 명백히 더 나쁜 경험을 초래합니다. 샌드위치 공격을 당한 사용자는 거래에서 슬리피지 증가와 실행 악화에 직면하게 됩니다. + +네트워크 레이어에서 일반화된 프론트러너와 이들이 종종 참여하는 가스 가격 경매(둘 이상의 프론트러너가 다음 블록에 자신의 트랜잭션을 포함시키기 위해 점진적으로 자신의 트랜잭션 가스 가격을 올리며 경쟁하는 경우)는 네트워크 혼잡과 일반 트랜잭션을 실행하려는 다른 모든 사람들에게 높은 가스 가격을 초래합니다. + +블록 _내부_에서 일어나는 일 외에도, MEV는 블록 _간_에 해로운 영향을 미칠 수 있습니다. 블록에서 사용 가능한 MEV가 표준 블록 보상을 크게 초과하면, 검증자는 블록을 재구성하여 MEV를 자신을 위해 캡처하도록 장려될 수 있으며, 이는 블록체인 재구성과 합의 불안정성을 유발합니다. + +이러한 블록체인 재구성 가능성은 [이전에 비트코인 블록체인에서 탐구된 바 있습니다](https://dl.acm.org/doi/10.1145/2976749.2978408). 비트코인의 블록 보상이 반감되고 거래 수수료가 블록 보상에서 차지하는 비중이 점점 더 커짐에 따라, 채굴자들이 다음 블록의 보상을 포기하고 대신 더 높은 수수료를 가진 과거 블록을 재채굴하는 것이 경제적으로 합리적인 상황이 발생합니다. MEV의 성장으로 이더리움에서도 동일한 종류의 상황이 발생하여 블록체인의 무결성을 위협할 수 있습니다. + +## MEV 현황 {#state-of-mev} + +MEV 추출은 2021년 초에 급증하여 연초 몇 달 동안 극도로 높은 가스 가격을 초래했습니다. Flashbots의 MEV 릴레이의 출현은 일반화된 프론트러너의 효율성을 감소시켰고 가스 가격 경매를 오프 체임으로 가져와 일반 사용자의 가스 가격을 낮췄습니다. + +많은 검색자가 여전히 MEV로 좋은 수익을 내고 있지만, 기회가 더 잘 알려지고 점점 더 많은 검색자가 동일한 기회를 놓고 경쟁함에 따라 검증자는 점점 더 많은 총 MEV 수익을 차지하게 될 것입니다(원래 설명된 것과 동일한 종류의 가스 경매가 Flashbots에서도 비공개로 발생하며, 검증자가 그에 따른 가스 수익을 차지하기 때문입니다). MEV는 이더리움에만 국한된 것이 아니며, 이더리움에서 기회 경쟁이 치열해짐에 따라 검색자들은 바이낸스 스마트 체인과 같은 대체 블록체인으로 이동하고 있습니다. 그곳에는 이더리움과 유사한 MEV 기회가 경쟁이 덜한 상태로 존재합니다. + +반면에 작업 증명에서 지분 증명으로의 전환과 롤업을 사용하여 이더리움을 확장하려는 지속적인 노력은 모두 아직 다소 불분명한 방식으로 MEV 환경을 변화시킵니다. 보장된 블록 제안자를 약간 미리 아는 것이 작업 증명의 확률적 모델에 비해 MEV 추출의 역학을 어떻게 변화시키는지, 또는 [단일 비밀 리더 선출](https://ethresear.ch/t/secret-non-single-leader-election/11789) 및 [분산 검증자 기술](/staking/dvt/)이 구현될 때 이것이 어떻게 중단될지는 아직 잘 알려져 있지 않습니다. 마찬가지로, 대부분의 사용자 활동이 이더리움에서 레이어 2 롤업 및 샤드로 이전될 때 어떤 MEV 기회가 존재하는지는 아직 지켜봐야 합니다. + +## 이더리움 지분 증명(PoS)에서의 MEV {#mev-in-ethereum-proof-of-stake} + +설명한 바와 같이, MEV는 전반적인 사용자 경험과 합의 레이어 보안에 부정적인 영향을 미칩니다. 그러나 이더리움의 지분 증명 합의로의 전환("병합"이라고 불림)은 잠재적으로 새로운 MEV 관련 위험을 초래합니다. + +### 검증자 중앙화 {#validator-centralization} + +병합 후 이더리움에서는 검증자(32 ETH의 보안 예치금을 예치한)가 비콘 체인에 추가된 블록의 유효성에 대해 합의에 도달합니다. 32 ETH는 많은 사람에게 부담스러운 금액일 수 있으므로 [스테이킹 풀에 참여](/staking/pools/)하는 것이 더 실현 가능한 옵션일 수 있습니다. 그럼에도 불구하고, [단독 스테이커](/staking/solo/)의 건전한 분포는 검증자의 중앙화를 완화하고 이더리움의 보안을 향상시키므로 이상적입니다. + +그러나 MEV 추출은 검증자 중앙화를 가속화할 수 있는 것으로 여겨집니다. 이는 부분적으로 검증자가 이전에 채굴자가 했던 것보다 [블록 제안에 대해 더 적은 수입을 얻게 되면서](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply), [병합](/roadmap/merge/) 이후 MEV 추출이 [검증자 수입에 큰 영향](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb)을 미쳤기 때문입니다. + +더 큰 스테이킹 풀은 MEV 기회를 포착하기 위해 필요한 최적화에 투자할 더 많은 자원을 가질 가능성이 높습니다. 이러한 풀이 더 많은 MEV를 추출할수록 MEV 추출 능력을 향상시키고 전체 수익을 늘릴 수 있는 더 많은 자원을 갖게 되어 본질적으로 [규모의 경제](https://www.investopedia.com/terms/e/economiesofscale.asp#)를 창출합니다. + +가용 자원이 적은 단독 스테이커는 MEV 기회로부터 이익을 얻지 못할 수 있습니다. 이로 인해 독립 검증자들이 수입을 늘리기 위해 강력한 스테이킹 풀에 가입하라는 압력이 증가하여 이더리움의 탈중앙화를 감소시킬 수 있습니다. + +### 허가형 멤풀 {#permissioned-mempools} + +샌드위치 및 선행매매 공격에 대응하여 거래자들은 트랜잭션 개인 정보 보호를 위해 검증자와 오프 체임 거래를 시작할 수 있습니다. 잠재적인 MEV 트랜잭션을 공개 멤풀로 보내는 대신, 거래자는 이를 검증자에게 직접 보내고, 검증자는 이를 블록에 포함시키고 거래자와 이익을 나눕니다. + +"다크 풀"은 이러한 협의의 더 큰 버전이며 특정 수수료를 지불할 의사가 있는 사용자에게 개방된 허가형, 접근 전용 멤풀로 기능합니다. 이러한 추세는 이더리움의 무허가성과 무신뢰성을 감소시키고 잠재적으로 블록체인을 가장 높은 입찰자를 선호하는 "pay-to-play" 메커니즘으로 변형시킬 수 있습니다. + +허가형 멤풀은 또한 이전 섹션에서 설명한 중앙화 위험을 가속화할 것입니다. 여러 검증자를 운영하는 대규모 풀은 거래자와 사용자에게 트랜잭션 개인 정보 보호를 제공하여 MEV 수익을 늘리는 이점을 얻을 가능성이 높습니다. + +병합 후 이더리움에서 이러한 MEV 관련 문제를 해결하는 것은 핵심 연구 분야입니다. 현재까지, 병합 이후 이더리움의 탈중앙화 및 보안에 대한 MEV의 부정적인 영향을 줄이기 위해 제안된 두 가지 해결책은 [**제안자-빌더 분리(PBS)**](/roadmap/pbs/)와 [**빌더 API**](https://github.com/ethereum/builder-specs)입니다. + +### 제안자-빌더 분리 {#proposer-builder-separation} + +작업 증명과 지분 증명 모두에서, 블록을 생성하는 노드는 합의에 참여하는 다른 노드에게 체인에 추가할 것을 제안합니다. 새로운 블록은 다른 채굴자가 그 위에 빌드하거나(PoW에서) 또는 과반수의 검증자로부터 인증을 받은 후(지분 증명에서) 정식 체인의 일부가 됩니다. + +블록 생산자와 블록 제안자 역할의 조합이 이전에 설명한 대부분의 MEV 관련 문제를 야기합니다. 예를 들어, 합의 노드는 MEV 수익을 극대화하기 위해 [타임 밴딧 공격](https://www.mev.wiki/attack-examples/time-bandit-attack)에서 체인 재구성을 유발하도록 장려됩니다. + +[제안자-빌더 분리](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725)(PBS)는 특히 합의 레이어에서 MEV의 영향을 완화하도록 설계되었습니다. PBS의 주요 특징은 블록 생산자와 블록 제안자 역할의 분리입니다. 검증자는 여전히 블록을 제안하고 투표할 책임이 있지만, **블록 빌더**라고 불리는 새로운 종류의 전문화된 주체가 트랜잭션을 정렬하고 블록을 생성하는 임무를 맡습니다. + +PBS 하에서, 블록 빌더는 트랜잭션 번들을 생성하고 비콘 체인 블록에 포함시키기 위한 입찰을 합니다("실행 페이로드"로서). 다음 블록을 제안하도록 선택된 검증자는 여러 입찰을 확인하고 가장 높은 수수료를 가진 번들을 선택합니다. PBS는 본질적으로 빌더가 블록 공간을 판매하는 검증자와 협상하는 경매 시장을 만듭니다. + +현재 PBS 설계는 빌더가 입찰과 함께 블록 내용물(블록 헤더)에 대한 암호화된 커밋먼트만 게시하는 [커밋-리빌 체계](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/)를 사용합니다. 낙찰된 입찰을 수락한 후, 제안자는 블록 헤더를 포함하는 서명된 블록 제안을 생성합니다. 블록 빌더는 서명된 블록 제안을 본 후 전체 블록 본문을 게시해야 하며, 최종 확정되기 전에 검증자로부터 충분한 [인증](/glossary/#attestation)을 받아야 합니다. + +#### 제안자-빌더 분리는 MEV의 영향을 어떻게 완화합니까? {#how-does-pbs-curb-mev-impact} + +프로토콜 내 제안자-빌더 분리는 검증자의 권한에서 MEV 추출을 제거함으로써 합의에 대한 MEV의 영향을 줄입니다. 대신, 전문 하드웨어를 실행하는 블록 빌더가 앞으로 MEV 기회를 포착할 것입니다. + +그러나 빌더가 검증자에게 블록을 수락받기 위해 높은 가격으로 입찰해야 하므로, 이것이 검증자를 MEV 관련 수입에서 완전히 배제하는 것은 아닙니다. 그럼에도 불구하고, 검증자가 더 이상 MEV 수입 최적화에 직접적으로 집중하지 않게 됨에 따라 타임 밴딧 공격의 위협이 줄어듭니다. + +제안자-빌더 분리는 또한 MEV의 중앙화 위험을 줄입니다. 예를 들어, 커밋-리빌 체계를 사용하면 빌더가 검증자가 MEV 기회를 훔치거나 다른 빌더에게 노출하지 않을 것이라고 신뢰할 필요가 없어집니다. 이는 단독 스테이커가 MEV로부터 이익을 얻기 위한 장벽을 낮춥니다. 그렇지 않으면 빌더는 오프 체임 평판을 가진 대규모 풀을 선호하고 그들과 오프 체임 거래를 하는 경향이 있을 것입니다. + +마찬가지로, 지불이 무조건적이기 때문에 검증자는 빌더가 블록 본문을 보류하거나 유효하지 않은 블록을 게시하지 않을 것이라고 신뢰할 필요가 없습니다. 제안된 블록을 사용할 수 없거나 다른 검증자에 의해 유효하지 않다고 선언되더라도 검증자의 수수료는 여전히 처리됩니다. 후자의 경우, 블록은 단순히 폐기되어 블록 빌더가 모든 거래 수수료와 MEV 수익을 잃게 됩니다. + +### 빌더 API {#builder-api} + +제안자-빌더 분리는 MEV 추출의 영향을 줄일 것을 약속하지만, 이를 구현하려면 합의 프로토콜을 변경해야 합니다. 구체적으로, 비콘 체인의 [포크 선택](/developers/docs/consensus-mechanisms/pos/#fork-choice) 규칙을 업데이트해야 합니다. [빌더 API](https://github.com/ethereum/builder-specs)는 더 높은 신뢰 가정을 수반하지만, 제안자-빌더 분리의 작동 구현을 제공하기 위한 임시 해결책입니다. + +빌더 API는 합의 레이어 클라이언트가 실행 레이어 클라이언트로부터 실행 페이로드를 요청하는 데 사용되는 [엔진 API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)의 수정된 버전입니다. [정직한 검증자 사양](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/validator.md)에 설명된 대로, 블록 제안 의무를 위해 선택된 검증자는 연결된 실행 클라이언트로부터 트랜잭션 번들을 요청하고, 이를 제안된 비콘 체인 블록에 포함시킵니다. + +빌더 API는 또한 검증자와 실행 레이어 클라이언트 간의 미들웨어 역할을 합니다. 그러나 비콘 체인의 검증자가 외부 주체로부터 블록을 소싱할 수 있도록 허용한다는 점에서 다릅니다(실행 클라이언트를 사용하여 로컬에서 블록을 생성하는 대신). + +다음은 빌더 API의 작동 방식에 대한 개요입니다. + +1. 빌더 API는 검증자를 실행 레이어 클라이언트를 실행하는 블록 빌더 네트워크에 연결합니다. PBS에서와 같이, 빌더는 자원 집약적인 블록 생성에 투자하고 MEV + 우선순위 팁에서 얻는 수익을 극대화하기 위해 다양한 전략을 사용하는 전문 주체입니다. + +2. 검증자(합의 레이어 클라이언트를 실행 중인)는 빌더 네트워크로부터 입찰과 함께 실행 페이로드를 요청합니다. 빌더의 입찰에는 실행 페이로드 헤더(페이로드 내용에 대한 암호화된 커밋먼트)와 검증자에게 지불할 수수료가 포함됩니다. + +3. 검증자는 들어오는 입찰을 검토하고 가장 높은 수수료를 가진 실행 페이로드를 선택합니다. 빌더 API를 사용하여 검증자는 자신의 서명과 실행 페이로드 헤더만 포함하는 "블라인드" 비콘 블록 제안을 생성하여 빌더에게 보냅니다. + +4. 빌더 API를 실행하는 빌더는 블라인드 블록 제안을 보면 전체 실행 페이로드로 응답해야 합니다. 이를 통해 검증자는 "서명된" 비콘 블록을 생성하여 네트워크 전체에 전파할 수 있습니다. + +5. 빌더 API를 사용하는 검증자는 블록 빌더가 신속하게 응답하지 않을 경우를 대비해 로컬에서 블록을 생성하여 블록 제안 보상을 놓치지 않도록 해야 합니다. 그러나 검증자는 이제 공개된 트랜잭션이나 다른 세트를 사용하여 또 다른 블록을 생성할 수 없습니다. 이는 _이중 서명_(동일한 슬롯 내에서 두 개의 블록에 서명하는 것)에 해당하며, 이는 슬래싱 대상 범죄입니다. + +빌더 API의 구현 예로는 이더리움에 대한 MEV의 부정적인 외부 효과를 억제하기 위해 설계된 [Flashbots 경매 메커니즘](https://docs.flashbots.net/Flashbots-auction/overview)의 개선 사항인 [MEV Boost](https://github.com/flashbots/mev-boost)가 있습니다. Flashbots 경매를 통해 지분 증명 검증자는 수익성 있는 블록을 구축하는 작업을 **검색자**라는 전문 당사자에게 아웃소싱할 수 있습니다. +![MEV 흐름을 자세히 보여주는 다이어그램](./mev.png) + +검색자는 수익성 있는 MEV 기회를 찾아 블록에 포함시키기 위해 [밀봉 가격 입찰](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction)과 함께 트랜잭션 번들을 블록 제안자에게 보냅니다. go-ethereum(Geth) 클라이언트의 포크 버전인 mev-geth를 실행하는 검증자는 가장 수익성이 높은 번들을 선택하여 새 블록의 일부로 포함시키기만 하면 됩니다. 블록 제안자(검증자)를 스팸 및 유효하지 않은 트랜잭션으로부터 보호하기 위해 트랜잭션 번들은 제안자에게 도달하기 전에 검증을 위해 **릴레이어**를 통과합니다. + +MEV Boost는 이더리움의 지분 증명 전환을 위해 설계된 새로운 기능을 갖추고 있지만, 원래 Flashbots 경매의 동일한 작동 방식을 유지합니다. 검색자는 여전히 블록에 포함할 수익성 있는 MEV 트랜잭션을 찾지만, **빌더**라고 불리는 새로운 종류의 전문 당사자가 트랜잭션과 번들을 블록으로 집계하는 책임을 집니다. 빌더는 검색자로부터 밀봉 가격 입찰을 수락하고 최적화를 실행하여 가장 수익성 있는 순서를 찾습니다. + +릴레이어는 여전히 트랜잭션 번들을 제안자에게 전달하기 전에 검증할 책임이 있습니다. 그러나 MEV Boost는 빌더가 보낸 블록 본문과 검증자가 보낸 블록 헤더를 저장하여 [데이터 가용성](/developers/docs/data-availability/)을 제공하는 **에스크로**를 도입합니다. 여기서 릴레이에 연결된 검증자는 사용 가능한 실행 페이로드를 요청하고 MEV Boost의 정렬 알고리즘을 사용하여 가장 높은 입찰가 + MEV 팁이 있는 페이로드 헤더를 선택합니다. + +#### 빌더 API는 MEV의 영향을 어떻게 완화합니까? {#how-does-builder-api-curb-mev-impact} + +빌더 API의 핵심 이점은 MEV 기회에 대한 접근을 민주화할 수 있는 잠재력입니다. 커밋-리빌 체계를 사용하면 신뢰 가정이 제거되고 MEV로부터 이익을 얻으려는 검증자의 진입 장벽이 낮아집니다. 이는 단독 스테이커가 MEV 이익을 늘리기 위해 대규모 스테이킹 풀과 통합해야 하는 압력을 줄여야 합니다. + +빌더 API의 광범위한 구현은 블록 빌더 간의 경쟁을 더욱 촉진하여 검열 저항성을 높일 것입니다. 검증자가 여러 빌더의 입찰을 검토함에 따라, 하나 이상의 사용자 트랜잭션을 검열하려는 빌더는 성공하기 위해 다른 모든 비검열 빌더보다 높은 가격을 제시해야 합니다. 이는 사용자를 검열하는 비용을 극적으로 증가시키고 그러한 행위를 억제합니다. + +MEV Boost와 같은 일부 프로젝트는 선행매매/샌드위치 공격을 피하려는 거래자와 같은 특정 당사자에게 트랜잭션 개인 정보 보호를 제공하도록 설계된 전체 구조의 일부로 빌더 API를 사용합니다. 이는 사용자와 블록 빌더 간의 비공개 통신 채널을 제공함으로써 달성됩니다. 앞서 설명한 허가형 멤풀과 달리 이 접근 방식은 다음과 같은 이유로 유익합니다. + +1. 시장에 여러 빌더가 존재하면 검열이 비현실적이 되어 사용자에게 이익이 됩니다. 대조적으로, 중앙화되고 신뢰 기반의 다크 풀이 존재하면 소수의 블록 빌더 손에 권력이 집중되고 검열 가능성이 높아질 것입니다. + +2. 빌더 API 소프트웨어는 오픈 소스이므로 누구나 블록 빌더 서비스를 제공할 수 있습니다. 이는 사용자가 특정 블록 빌더를 강제로 사용하지 않아도 되며 이더리움의 중립성과 무허가성을 향상시킵니다. 또한, MEV를 추구하는 거래자들은 비공개 거래 채널을 사용함으로써 의도치 않게 중앙화에 기여하지 않게 됩니다. + +## 관련 자료 {#related-resources} + +- [Flashbots 문서](https://docs.flashbots.net/) +- [Flashbots GitHub](https://github.com/flashbots/pm) +- [mevboost.org](https://www.mevboost.org/) - _MEV-Boost 릴레이 및 블록 빌더에 대한 실시간 통계 추적기_ + +## 더 읽어보기 {#further-reading} + +- [채굴자 추출 가능 가치(MEV)란 무엇인가?](https://blog.chain.link/what-is-miner-extractable-value-mev/) +- [MEV와 나](https://www.paradigm.xyz/2021/02/mev-and-me) +- [이더리움은 어두운 숲이다](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/) +- [어두운 숲 탈출하기](https://samczsun.com/escaping-the-dark-forest/) +- [Flashbots: MEV 위기 선행매매](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752) +- [@bertcmiller의 MEV 스레드](https://twitter.com/bertcmiller/status/1402665992422047747) +- [MEV-Boost: 병합 준비가 된 Flashbots 아키텍처](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) +- [MEV Boost란 무엇인가](https://www.alchemy.com/overviews/mev-boost) +- [왜 mev-boost를 실행해야 하는가?](https://writings.flashbots.net/writings/why-run-mevboost/) +- [이더리움을 위한 히치하이커 안내서](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) diff --git a/public/content/translations/ko/developers/docs/networking-layer/index.md b/public/content/translations/ko/developers/docs/networking-layer/index.md new file mode 100644 index 00000000000..703ecb87714 --- /dev/null +++ b/public/content/translations/ko/developers/docs/networking-layer/index.md @@ -0,0 +1,155 @@ +--- +title: "네트워킹 계층" +description: "이더리움의 네트워크 계층 소개." +lang: ko +sidebarDepth: 2 +--- + +이더리움은 표준화된 프로토콜을 기반으로 서로 통신할 수 있어야 하는, 수천 개의 노드로 구성된 P2P 네트워크입니다. 네트워크 계층은 이러한 노드가 서로를 찾고 정보를 교환할 수 있도록 하는 프로토콜의 스택입니다. 이는 네트워크 상에서 “가십” 정보(일대다 통신)를 전파하는 것뿐만 아니라, 특정 노드 간(일대일 통신) 요청과 응답을 교환하는 것도 포함합니다. 각 노드는 올바른 정보를 주고받고 있음을 보장하기 위해 특정한 네트워크 규칙을 반드시 준수해야 합니다. + +클라이언트 소프트웨어는 실행 클라이언트와 합의 클라이언트의 두 부분으로 나누어지며, 각 부분은 고유한 네트워크 스택을 가집니다. 다른 이더리움 노드와 통신하는 것뿐만 아니라, 실행 및 합의 클라이언트는 서로 간 통신을 해야 합니다. 이 페이지는 이러한 소통을 가능하게 해주는 프로토콜에 대한 소개 설명을 제공합니다. + +실행 클라이언트는 P2P 네트워크의 실행 계층을 통한 거래를 . 이는 인증된 피어들 간의 암호화된 통신을 필요로 합니다. 검증자가 블록을 제안하기 위해 선택될 때, 노드의 로컬 트랜잭션 풀로부터의 트랜잭션은 비콘 블록으로 패키징될 RPC 연결을 통해 합의 클라이언트를 통과시킬 것입니다.검증자가 블록을 제안하기 위해 선택될 때, 노드의 로컬 트랜잭션 풀로부터의 트랜잭션은 비콘 블록으로 패키징될 RPC 연결을 통해 합의 클라이언트를 통과시킬 것입니다. 그러면 합의 클라이언트는 이를 위해서는 두 개의 개별 P2P 네트워크가 필요합니다. 하나는 트랜잭션 가십을 위해 실행 클라이언트를 연결하고, 다른 하나는 블록 가십을 위해 합의 클라이언트를 연결하는 네트워크입니다. + +## 필수 구성 요소 {#prerequisites} + +이더리움 [노드 및 클라이언트](/developers/docs/nodes-and-clients/)에 대한 지식이 있으면 이 페이지를 이해하는 데 도움이 됩니다. + +## 실행 레이어 {#execution-layer} + +실행 레이어의 네트워킹 프로토콜은 두 개의 스택으로 나뉩니다: + +- 검색 스택: UDP 위에 구축되어 새로운 노드가 연결할 피어를 찾을 수 있도록 합니다. + +- DevP2P 스택: TCP 위에 위치하며 노드가 정보를 교환할 수 있도록 합니다. + +두 스택은 병렬로 작동합니다. 검색 스택은 새로운 네트워크 참여자를 네트워크에 공급하고 DevP2P 스택은 이들의 상호 작용을 가능하게 합니다. + +### 검색 {#discovery} + +검색은 네트워크에서 다른 노드를 찾는 프로세스입니다. 이는 소규모 부트노드 집합을 사용하여 부트스트랩됩니다(주소가 클라이언트에 [하드코딩](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go)되어 즉시 찾을 수 있고 클라이언트를 피어에 연결할 수 있는 노드). 이러한 부트노드는 새로운 노드를 피어 집합에 소개하기 위해서만 존재합니다. 이것이 유일한 목적이며, 체인 동기화와 같은 일반적인 클라이언트 작업에는 참여하지 않으며 클라이언트가 처음 시작될 때만 사용됩니다. + +노드-부트노드 상호작용에 사용되는 프로토콜은 노드 목록을 공유하기 위해 [분산 해시 테이블](https://en.wikipedia.org/wiki/Distributed_hash_table)을 사용하는 수정된 형태의 [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f)입니다. 각 노드는 가장 가까운 피어에 연결하는 데 필요한 정보를 포함하는 이 테이블의 버전을 가지고 있습니다. 이 '근접성'은 지리적인 것이 아니라 노드 ID의 유사성으로 거리가 정의됩니다. 각 노드의 테이블은 보안 기능으로 정기적으로 새로 고쳐집니다. 예를 들어, [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) 검색 프로토콜에서 노드는 클라이언트가 지원하는 하위 프로토콜을 표시하는 '광고'를 전송하여 피어가 서로 통신하는 데 사용할 수 있는 프로토콜에 대해 협상할 수 있도록 합니다. + +검색은 PING-PONG 게임으로 시작됩니다. 성공적인 PING-PONG은 새 노드를 부트노드에 "결속"시킵니다. 네트워크에 진입하는 새 노드의 존재를 부트노드에 알리는 초기 메시지는 `PING`입니다. 이 `PING`에는 새 노드, 부트노드 및 만료 타임스탬프에 대한 해시된 정보가 포함됩니다. 부트노드는 `PING`을 수신하고 `PING` 해시를 포함하는 `PONG`을 반환합니다. `PING`과 `PONG` 해시가 일치하면 새 노드와 부트노드 간의 연결이 확인되고 "결속"되었다고 합니다. + +일단 결속되면, 새 노드는 부트노드에 `FIND-NEIGHBOURS` 요청을 보낼 수 있습니다. 부트노드가 반환하는 데이터에는 새 노드가 연결할 수 있는 피어 목록이 포함됩니다. 노드가 결속되지 않으면 `FIND-NEIGHBOURS` 요청이 실패하므로 새 노드는 네트워크에 진입할 수 없습니다. + +새 노드가 부트노드로부터 이웃 목록을 받으면 각 이웃과 PING-PONG 교환을 시작합니다. 성공적인 PING-PONG은 새 노드를 이웃과 결속시켜 메시지 교환을 가능하게 합니다. + +``` +클라이언트 시작 --> 부트노드에 연결 --> 부트노드에 결속 --> 이웃 찾기 --> 이웃에 결속 +``` + +실행 클라이언트는 현재 [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) 검색 프로토콜을 사용하고 있으며, [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) 프로토콜로 마이그레이션하려는 노력이 활발히 이루어지고 있습니다. + +#### ENR: 이더리움 노드 레코드 {#enr} + +[이더리움 노드 레코드(ENR)](/developers/docs/networking-layer/network-addresses/)는 서명(합의된 ID 체계에 따라 만들어진 레코드 콘텐츠의 해시), 레코드 변경 사항을 추적하는 시퀀스 번호, 임의의 키:값 쌍 목록 등 세 가지 기본 요소를 포함하는 객체입니다. 이는 새로운 피어 간에 식별 정보를 더 쉽게 교환할 수 있도록 하는 미래 보장형 형식이며 이더리움 노드에 선호되는 [네트워크 주소](/developers/docs/networking-layer/network-addresses) 형식입니다. + +#### 검색이 UDP를 기반으로 구축된 이유는 무엇인가요? {#why-udp} + +UDP는 오류 검사, 실패한 패킷 재전송 또는 동적으로 연결을 열고 닫는 것을 지원하지 않습니다. 대신 성공적으로 수신되었는지 여부에 관계없이 대상에 지속적인 정보 스트림을 보냅니다. 이러한 최소한의 기능은 오버헤드도 최소화하여 이런 종류의 연결을 매우 빠르게 만듭니다. 노드가 피어와 공식적인 연결을 설정하기 위해 자신의 존재를 알리기만 하면 되는 검색의 경우 UDP로 충분합니다. 그러나 나머지 네트워킹 스택의 경우 UDP는 목적에 적합하지 않습니다. 노드 간의 정보 교환은 매우 복잡하므로 재전송, 오류 검사 등을 지원할 수 있는 더 완벽한 기능을 갖춘 프로토콜이 필요합니다. TCP와 관련된 추가 오버헤드는 추가 기능만큼의 가치가 있습니다. 따라서 P2P 스택의 대부분은 TCP를 통해 작동합니다. + +### DevP2P {#devp2p} + +DevP2P는 이더리움이 P2P 네트워크를 구축하고 유지하기 위해 구현하는 전체 프로토콜 스택입니다. 새 노드가 네트워크에 들어온 후, 이들의 상호 작용은 [DevP2P](https://github.com/ethereum/devp2p) 스택의 프로토콜에 의해 제어됩니다. 이들은 모두 TCP 위에 있으며 RLPx 전송 프로토콜, 와이어 프로토콜 및 여러 하위 프로토콜을 포함합니다. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md)는 노드 간의 세션을 시작, 인증 및 유지 관리하는 프로토콜입니다. RLPx는 RLP(재귀 길이 접두사)를 사용하여 메시지를 인코딩하는데, 이는 노드 간 전송을 위해 데이터를 최소 구조로 인코딩하는 매우 공간 효율적인 방법입니다. + +두 노드 간의 RLPx 세션은 초기 암호화 핸드셰이크로 시작됩니다. 여기에는 노드가 인증 메시지를 보내고 피어가 이를 확인하는 과정이 포함됩니다. 확인에 성공하면 피어는 시작 노드로 반환할 인증-응답 메시지를 생성합니다. 이는 노드가 개인적으로 그리고 안전하게 통신할 수 있도록 하는 키 교환 프로세스입니다. 성공적인 암호화 핸드셰이크는 두 노드가 서로에게 "와이어상에서" "hello" 메시지를 보내도록 합니다. 와이어 프로토콜은 hello 메시지의 성공적인 교환으로 시작됩니다. + +hello 메시지에는 다음이 포함됩니다. + +- 프로토콜 버전 +- 클라이언트 ID +- 포트 +- 노드 ID +- 지원되는 하위 프로토콜 목록 + +이것은 두 노드 간에 공유되는 기능을 정의하고 통신을 구성하기 때문에 성공적인 상호 작용에 필요한 정보입니다. 각 노드에서 지원하는 하위 프로토콜 목록을 비교하고 두 노드에 공통적인 프로토콜을 세션에서 사용할 수 있는 하위 프로토콜 협상 프로세스가 있습니다. + +hello 메시지와 함께 와이어 프로토콜은 연결이 닫힐 것이라는 경고를 피어에게 제공하는 "연결 끊기" 메시지를 보낼 수도 있습니다. 와이어 프로토콜에는 세션을 열어두기 위해 주기적으로 전송되는 PING 및 PONG 메시지도 포함됩니다. 따라서 RLPx 및 와이어 프로토콜 교환은 노드 간 통신의 기반을 구축하여 특정 하위 프로토콜에 따라 유용한 정보를 교환하기 위한 발판을 제공합니다. + +### 하위 프로토콜 {#sub-protocols} + +#### 와이어 프로토콜 {#wire-protocol} + +피어가 연결되고 RLPx 세션이 시작되면 와이어 프로토콜은 피어가 통신하는 방법을 정의합니다. 처음에 와이어 프로토콜은 체인 동기화, 블록 전파, 트랜잭션 교환의 세 가지 주요 작업을 정의했습니다. 그러나 이더리움이 지분 증명으로 전환되면서 블록 전파와 체인 동기화는 합의 레이어의 일부가 되었습니다. 트랜잭션 교환은 여전히 실행 클라이언트의 권한 내에 있습니다. 트랜잭션 교환은 블록 빌더가 다음 블록에 포함할 일부 트랜잭션을 선택할 수 있도록 노드 간에 보류 중인 트랜잭션을 교환하는 것을 의미합니다. 이러한 작업에 대한 자세한 정보는 [여기](https://github.com/ethereum/devp2p/blob/master/caps/eth.md)에서 확인할 수 있습니다. 이러한 하위 프로토콜을 지원하는 클라이언트는 [JSON-RPC](/developers/docs/apis/json-rpc/)를 통해 이를 노출합니다. + +#### les (라이트 이더리움 하위 프로토콜) {#les} + +이것은 라이트 클라이언트를 동기화하기 위한 최소한의 프로토콜입니다. 전통적으로 이 프로토콜은 인센티브 없이 라이트 클라이언트에 데이터를 제공하기 위해 전체 노드가 필요하기 때문에 거의 사용되지 않았습니다. 실행 클라이언트의 기본 동작은 les를 통해 라이트 클라이언트 데이터를 제공하지 않는 것입니다. 자세한 정보는 les [사양](https://github.com/ethereum/devp2p/blob/master/caps/les.md)에서 확인할 수 있습니다. + +#### 스냅 {#snap} + +[스냅 프로토콜](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap)은 피어가 최근 상태의 스냅샷을 교환할 수 있도록 하는 선택적 확장으로, 피어가 중간 머클 트라이 노드를 다운로드할 필요 없이 계정 및 저장 공간 데이터를 확인할 수 있도록 합니다. + +#### Wit (증인 프로토콜) {#wit} + +[증인 프로토콜](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit)은 피어 간의 상태 증인 교환을 가능하게 하여 클라이언트를 체인의 끝으로 동기화하는 데 도움을 주는 선택적 확장입니다. + +#### 위스퍼 {#whisper} + +위스퍼는 블록체인에 정보를 쓰지 않고 피어 간에 보안 메시징을 제공하는 것을 목표로 하는 프로토콜이었습니다. DevP2P 와이어 프로토콜의 일부였지만 현재는 더 이상 사용되지 않습니다. 비슷한 목표를 가진 다른 [관련 프로젝트](https://wakunetwork.com/)가 있습니다. + +## 합의 레이어 {#consensus-layer} + +합의 클라이언트는 다른 사양을 가진 별도의 P2P 네트워크에 참여합니다. 합의 클라이언트는 블록 가십에 참여하여 피어로부터 새 블록을 수신하고 블록 제안자가 될 차례가 되면 이를 브로드캐스트해야 합니다. 실행 레이어와 유사하게, 이를 위해서는 먼저 노드가 피어를 찾고 블록, 인증 등을 교환하기 위한 보안 세션을 설정할 수 있도록 검색 프로토콜이 필요합니다. + +### 검색 {#consensus-discovery} + +실행 클라이언트와 마찬가지로 합의 클라이언트는 피어를 찾기 위해 UDP를 통해 [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5)를 사용합니다. 합의 레이어의 discv5 구현은 discv5를 [libP2P](https://libp2p.io/) 스택에 연결하는 어댑터를 포함하여 DevP2P를 더 이상 사용하지 않는다는 점에서만 실행 클라이언트의 구현과 다릅니다. 실행 레이어의 RLPx 세션은 libP2P의 노이즈 보안 채널 핸드셰이크를 위해 더 이상 사용되지 않습니다. + +### ENR {#consensus-enr} + +합의 노드를 위한 ENR에는 노드의 공개 키, IP 주소, UDP 및 TCP 포트, 그리고 인증 서브넷 비트필드와 `eth2` 키라는 두 가지 합의 관련 필드가 포함됩니다. 전자는 노드가 특정 인증 가십 하위 네트워크에 참여하는 피어를 더 쉽게 찾을 수 있도록 합니다. `eth2` 키에는 노드가 사용 중인 이더리움 포크 버전에 대한 정보가 포함되어 있어 피어가 올바른 이더리움에 연결되도록 보장합니다. + +### libP2P {#libp2p} + +libP2P 스택은 검색 후 모든 통신을 지원합니다. 클라이언트는 ENR에 정의된 대로 IPv4 및/또는 IPv6에서 다이얼하고 수신할 수 있습니다. libP2P 레이어의 프로토콜은 가십 및 요청/응답 도메인으로 세분화될 수 있습니다. + +### 가십 {#gossip} + +가십 도메인에는 네트워크 전체에 빠르게 퍼져야 하는 모든 정보가 포함됩니다. 여기에는 비콘 블록, 증명, 인증, 출금 및 슬래싱이 포함됩니다. 이는 libP2P gossipsub v1을 사용하여 전송되며 각 노드에 로컬로 저장된 다양한 메타데이터(수신 및 전송할 가십 페이로드의 최대 크기 포함)에 의존합니다. 가십 도메인에 대한 자세한 정보는 [여기](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub)에서 확인할 수 있습니다. + +### 요청-응답 {#request-response} + +요청-응답 도메인에는 클라이언트가 피어에게 특정 정보를 요청하기 위한 프로토콜이 포함됩니다. 예를 들어 특정 루트 해시와 일치하거나 특정 슬롯 범위 내에 있는 특정 비콘 블록을 요청하는 것이 있습니다. 응답은 항상 snappy로 압축된 SSZ 인코딩 바이트로 반환됩니다. + +## 합의 클라이언트는 왜 RLP보다 SSZ를 선호하나요? {#ssz-vs-rlp}콜데이터-블롭 + +SSZ는 simple serialization(단순 직렬화)의 약자입니다. 고정 오프셋을 사용하여 전체 구조를 디코딩할 필요 없이 인코딩된 메시지의 개별 부분을 쉽게 디코딩할 수 있으므로, 합의 클라이언트가 인코딩된 메시지에서 특정 정보를 효율적으로 가져올 수 있어 매우 유용합니다. 또한 머클 프로토콜과 통합되도록 특별히 설계되었으며, 머클화에 대한 관련 효율성 향상이 있습니다. 합의 레이어의 모든 해시는 머클 루트이므로 이는 상당한 개선으로 이어집니다. SSZ는 또한 값의 고유한 표현을 보장합니다. + +## 실행 및 합의 클라이언트 연결 {#connecting-clients} + +합의 클라이언트와 실행 클라이언트는 모두 병렬로 실행됩니다. 합의 클라이언트가 실행 클라이언트에 지침을 제공하고 실행 클라이언트가 비콘 블록에 포함할 트랜잭션 번들을 합의 클라이언트에 전달할 수 있도록 연결해야 합니다. 두 클라이언트 간의 통신은 로컬 RPC 연결을 사용하여 수행할 수 있습니다. ['Engine-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)로 알려진 API는 두 클라이언트 간에 전송되는 명령을 정의합니다. 두 클라이언트 모두 단일 네트워크 ID 뒤에 있으므로 각 클라이언트에 대한 별도의 키(eth1 키 및 eth2 키)를 포함하는 ENR(이더리움 노드 레코드)을 공유합니다. + +제어 흐름의 요약은 아래에 나와 있으며 관련 네트워킹 스택은 괄호 안에 있습니다. + +### 합의 클라이언트가 블록 생성자가 아닐 때: {#when-consensus-client-is-not-block-producer} + +- 합의 클라이언트는 블록 가십 프로토콜(합의 p2p)을 통해 블록을 수신합니다. +- 합의 클라이언트는 블록을 사전 검증합니다. 즉, 올바른 메타데이터를 가진 유효한 발신자로부터 도착했는지 확인합니다. +- 블록의 트랜잭션은 실행 페이로드로 실행 레이어에 전송됩니다(로컬 RPC 연결). +- 실행 레이어는 트랜잭션을 실행하고 블록 헤더의 상태를 검증합니다(즉, 해시 일치 여부 확인). +- 실행 레이어는 검증 데이터를 합의 레이어로 다시 전달하고, 이제 블록이 검증된 것으로 간주됩니다(로컬 RPC 연결). +- 합의 레이어는 블록을 자체 블록체인의 헤드에 추가하고 이를 인증하여 네트워크를 통해 인증을 브로드캐스트합니다(합의 p2p). + +### 합의 클라이언트가 블록 생성자일 때: {#when-consensus-client-is-block-producer} + +- 합의 클라이언트는 다음 블록 생성자라는 통지를 받습니다(합의 p2p). +- 합의 레이어는 실행 클라이언트에서 `create block` 메서드를 호출합니다(로컬 RPC). +- 실행 레이어는 트랜잭션 가십 프로토콜(실행 p2p)에 의해 채워진 트랜잭션 멤풀에 액세스합니다. +- 실행 클라이언트는 트랜잭션을 블록으로 묶고, 트랜잭션을 실행하고, 블록 해시를 생성합니다. +- 합의 클라이언트는 실행 클라이언트로부터 트랜잭션과 블록 해시를 가져와 비콘 블록에 추가합니다(로컬 RPC). +- 합의 클라이언트는 블록 가십 프로토콜(합의 p2p)을 통해 블록을 브로드캐스트합니다. +- 다른 클라이언트는 블록 가십 프로토콜을 통해 제안된 블록을 수신하고 위에서 설명한 대로 검증합니다(합의 p2p). + +블록이 충분한 검증자에 의해 인증되면 체인의 헤드에 추가되고, 정당화되며, 결국 최종 확정됩니다. + +![](cons_client_net_layer.png)\n![](exe_client_net_layer.png) + +[ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)에서 가져온 합의 및 실행 클라이언트를 위한 네트워크 레이어 개략도 + +## 추가 정보 {#further-reading} + +[DevP2P](https://github.com/ethereum/devp2p)\n[LibP2p](https://github.com/libp2p/specs)\n[합의 레이어 네트워크 사양](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure)\n[kademlia에서 discv5로](https://vac.dev/kademlia-to-discv5)\n[kademlia 논문](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf)\n[이더리움 p2p 소개](https://p2p.paris/en/talks/intro-ethereum-networking/)\n[eth1/eth2 관계](http://ethresear.ch/t/eth1-eth2-client-relationship/7248)\n[병합 및 eth2 클라이언트 세부 정보 영상](https://www.youtube.com/watch?v=zNIrIninMgg) diff --git a/public/content/translations/ko/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/ko/developers/docs/networking-layer/network-addresses/index.md new file mode 100644 index 00000000000..a1a23192422 --- /dev/null +++ b/public/content/translations/ko/developers/docs/networking-layer/network-addresses/index.md @@ -0,0 +1,39 @@ +--- +title: "네트워크 주소" +description: "네트워크 주소에 대한 소개." +lang: ko +sidebarDepth: 2 +--- + +이더리움 노드는 피어에 연결하기 위해 몇 가지 기본 정보로 자신을 식별해야 합니다. 잠재적 피어가 이 정보를 해석할 수 있도록 이더리움 노드가 이해할 수 있는 세 가지 표준화된 형식(multiaddr, enode 또는 이더리움 노드 레코드(ENR)) 중 하나로 전달됩니다. ENR은 이더리움 네트워크 주소의 현재 표준입니다. + +## 필수 구성 요소 {#prerequisites} + +이 페이지를 이해하려면 이더리움의 [네트워킹 층](/developers/docs/networking-layer/)에 대한 약간의 이해가 필요합니다. + +## Multiaddr {#multiaddr} + +최초의 이더리움 노드 주소 형식은 'multiaddr'('multi-addresses'의 약자)였습니다. Multiaddr는 피어투피어 네트워크를 위해 설계된 보편적인 형식입니다. 주소는 키와 값을 슬래시로 구분한 키-값 쌍으로 표시됩니다. 예를 들어, IPv4 주소 `192.168.22.27`을 사용하고 TCP 포트 `33000`에서 수신 대기하는 노드의 multiaddr는 다음과 같습니다. + +/ip4/192.168.22.27/tcp/33000 + +이더리움 노드의 경우, multiaddr에는 노드 ID(공개 키의 해시)가 포함됩니다. + +/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br + +## Enode {#enode} + +Enode는 URL 주소 형식을 사용하여 이더리움 노드를 식별하는 방법입니다. 16진수 노드 ID는 URL의 사용자 이름 부분에 인코딩되며 @ 기호를 사용하여 호스트와 구분됩니다. 호스트 이름은 IP 주소로만 지정할 수 있으며 DNS 이름은 허용되지 않습니다. 호스트 이름 섹션의 포트는 TCP 수신 대기 포트입니다. TCP와 UDP(검색) 포트가 다른 경우 UDP 포트는 쿼리 파라미터 "discport"로 지정됩니다. + +다음 예에서 노드 URL은 IP 주소가 `10.3.58.6`이고 TCP 포트가 `30303`이며 UDP 검색 포트가 `30301`인 노드를 설명합니다. + +enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301 + +## 이더리움 노드 레코드(ENR) {#enr} + +이더리움 노드 레코드(ENR)는 이더리움의 네트워크 주소에 대한 표준화된 형식입니다. 이것들은 multiaddr과 enode를 대체합니다. 이것들은 노드 간에 더 많은 정보 교환을 허용하기 때문에 특히 유용합니다. ENR에는 서명, 시퀀스 번호 및 서명을 생성하고 검증하는 데 사용되는 ID 체계를 자세히 설명하는 필드가 포함되어 있습니다. ENR은 키-값 쌍으로 구성된 임의의 데이터로 채워질 수도 있습니다. 이 키-값 쌍에는 노드의 IP 주소와 노드가 사용할 수 있는 하위 프로토콜에 대한 정보가 포함됩니다. 합의 클라이언트는 [특정 ENR 구조](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure)를 사용하여 부트 노드를 식별하고 현재 이더리움 포크 및 인증 가십 서브넷(인증이 함께 집계되는 특정 피어 집합에 노드를 연결)에 대한 정보가 포함된 `eth2` 필드도 포함합니다. + +## 추가 정보 {#further-reading} + +- [EIP-778: 이더리움 노드 레코드(ENR)](https://eips.ethereum.org/EIPS/eip-778) +- [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/) diff --git a/public/content/translations/ko/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/ko/developers/docs/networking-layer/portal-network/index.md new file mode 100644 index 00000000000..2998c3d1bac --- /dev/null +++ b/public/content/translations/ko/developers/docs/networking-layer/portal-network/index.md @@ -0,0 +1,89 @@ +--- +title: "포털 네트워크" +description: "포털 네트워크 개요 - 저사양 클라이언트를 지원하도록 설계된 개발 중인 네트워크입니다." +lang: ko +--- + +이더리움은 이더리움 클라이언트 소프트웨어를 실행하는 컴퓨터로 구성된 네트워크입니다. 이러한 각 컴퓨터를 '노드'라고 합니다. 클라이언트 소프트웨어를 통해 노드는 이더리움 네트워크에서 데이터를 보내고 받을 수 있으며, 이더리움 프로토콜 규칙에 따라 데이터를 검증합니다. 노드는 디스크 저장 공간에 많은 양의 기록 데이터를 보관하며 네트워크의 다른 노드로부터 블록이라고 하는 새로운 정보 패킷을 받을 때마다 이를 추가합니다. 이는 노드가 네트워크의 나머지 부분과 일치하는 정보를 가지고 있는지 항상 확인하는 데 필요합니다. 이는 노드를 실행하는 데 많은 디스크 공간이 필요할 수 있음을 의미합니다. 일부 노드 작업에는 많은 RAM이 필요할 수도 있습니다. + +이러한 디스크 저장 공간 문제를 해결하기 위해, 모든 정보를 직접 저장하는 대신 전체 노드에 정보를 요청하는 '라이트' 노드가 개발되었습니다. 하지만 이는 라이트 노드가 독립적으로 정보를 검증하지 않고 대신 다른 노드를 신뢰한다는 것을 의미합니다. 이는 또한 전체 노드가 해당 라이트 노드에 서비스를 제공하기 위해 추가 작업을 수행해야 함을 의미합니다. + +포털 네트워크는 필요한 데이터를 네트워크 전체에서 작은 조각으로 공유함으로써 전체 노드를 신뢰하거나 추가적인 부담을 주지 않고 "라이트" 노드의 데이터 가용성 문제를 해결하는 것을 목표로 하는 이더리움의 새로운 네트워킹 설계입니다. + +[노드 및 클라이언트](/developers/docs/nodes-and-clients/)에 대해 더 알아보기 + +## 포털 네트워크가 필요한 이유 {#why-do-we-need-portal-network} + +이더리움 노드는 이더리움 블록체인의 전체 또는 부분 사본을 자체적으로 저장합니다. 이 로컬 사본은 트랜잭션을 검증하고 노드가 올바른 체인을 따르고 있는지 확인하는 데 사용됩니다. 로컬에 저장된 이 데이터를 통해 노드는 다른 개체를 신뢰할 필요 없이 들어오는 데이터가 유효하고 올바른지 독립적으로 검증할 수 있습니다. + +이러한 블록체인의 로컬 사본과 관련 상태 및 영수증 데이터는 노드의 하드 디스크에서 많은 공간을 차지합니다. 예를 들어, [Geth](https://geth.ethereum.org)를 합의 클라이언트와 페어링하여 노드를 실행하려면 2TB 하드 디스크가 권장됩니다. 비교적 최근의 블록 세트에서 체인 데이터만 저장하는 스냅 동기화를 사용하면 Geth는 일반적으로 약 650GB의 디스크 공간을 차지하지만 주당 약 14GB씩 증가합니다(주기적으로 노드를 650GB로 다시 정리할 수 있습니다). + +이는 많은 양의 디스크 공간이 이더리움에 할당되어야 하므로 노드를 실행하는 데 비용이 많이 들 수 있음을 의미합니다. 이더리움 로드맵에는 [히스토리 만료](/roadmap/statelessness/#history-expiry), [상태 만료](/roadmap/statelessness/#state-expiry), [무상태성](/roadmap/statelessness/) 등 이 문제에 대한 몇 가지 해결책이 있습니다. 하지만, 이러한 기능이 구현되려면 몇 년이 걸릴 것으로 보입니다. 체인 데이터의 자체 사본을 저장하지 않고 전체 노드에서 필요한 데이터를 요청하는 [라이트 노드](/developers/docs/nodes-and-clients/light-clients/)도 있습니다. 하지만 이는 라이트 노드가 정직한 데이터를 제공하는 전체 노드를 신뢰해야 하며, 라이트 노드가 필요로 하는 데이터를 제공해야 하는 전체 노드에 부담을 준다는 것을 의미합니다. + +포털 네트워크는 라이트 노드가 전체 노드에서 수행해야 하는 작업에 대한 신뢰나 상당한 추가 작업 없이 데이터를 얻을 수 있는 대안적인 방법을 제공하는 것을 목표로 합니다. 이를 위해 이더리움 노드가 네트워크 전체에서 데이터를 공유할 수 있는 새로운 방법을 도입할 것입니다. + +## 포털 네트워크는 어떻게 작동하나요? {#how-does-portal-network-work} + +이더리움 노드에는 서로 통신하는 방법을 정의하는 엄격한 프로토콜이 있습니다. 실행 클라이언트는 [DevP2P](/developers/docs/networking-layer/#devp2p)로 알려진 하위 프로토콜 세트를 사용하여 통신하는 반면, 합의 클라이언트는 [libP2P](/developers/docs/networking-layer/#libp2p)라는 다른 하위 프로토콜 스택을 사용합니다. 이는 노드 간에 전달될 수 있는 데이터 유형을 정의합니다. + +![devP2P 및 libP2P](portal-network-devp2p-libp2p.png) + +노드는 [JSON-RPC API](/developers/docs/apis/json-rpc/)를 통해 특정 데이터를 제공할 수도 있으며, 이를 통해 앱과 지갑이 이더리움 노드와 정보를 교환합니다. 하지만 이들 중 어느 것도 라이트 클라이언트에 데이터를 제공하기에 이상적인 프로토콜은 아닙니다. + +라이트 클라이언트는 현재 DevP2P 또는 libP2p를 통해 특정 체인 데이터를 요청할 수 없습니다. 왜냐하면 이러한 프로토콜은 체인 동기화와 블록 및 트랜잭션의 가십(gossiping)을 가능하게 하도록 설계되었기 때문입니다. 라이트 클라이언트는 이 정보를 다운로드하고 싶어하지 않습니다. 그렇게 하면 "라이트"라는 특성을 잃게 되기 때문입니다. + +JSON-RPC API 또한 라이트 클라이언트 데이터 요청에 이상적인 선택이 아닙니다. 왜냐하면 데이터를 제공할 수 있는 특정 전체 노드 또는 중앙화된 RPC 제공자와의 연결에 의존하기 때문입니다. 이는 라이트 클라이언트가 특정 노드/제공자가 정직하다고 신뢰해야 하며, 전체 노드는 많은 라이트 클라이언트로부터 수많은 요청을 처리해야 하므로 대역폭 요구 사항이 추가될 수 있음을 의미합니다. + +포털 네트워크의 핵심은 기존 이더리움 클라이언트의 설계 제약에서 벗어나, 가벼움을 위해 특별히 구축하여 전체 설계를 재고하는 것입니다. + +포털 네트워크의 핵심 아이디어는 기록 데이터 및 현재 체인 헤드의 ID와 같이 라이트 클라이언트가 필요로 하는 정보를 [DHT](https://en.wikipedia.org/wiki/Distributed_hash_table)(비트토렌트와 유사)를 사용하는 경량 DevP2P 스타일의 P2P(peer-to-peer) 탈중앙화 네트워크를 통해 제공함으로써 현재 네트워킹 스택의 가장 좋은 부분을 취하는 것입니다. + +아이디어는 전체 이더리움 기록 데이터의 작은 부분과 일부 특정 노드 책임을 각 노드에 추가하는 것입니다. 그런 다음, 요청된 특정 데이터를 저장하는 노드를 찾아내고 그들로부터 데이터를 검색하여 요청을 처리합니다. + +이는 라이트 노드가 단일 노드를 찾아 대용량 데이터를 필터링하고 제공하도록 요청하는 일반적인 모델을 뒤집습니다. 대신, 각각 소량의 데이터를 처리하는 대규모 노드 네트워크를 신속하게 필터링합니다. + +목표는 경량 포털 클라이언트의 탈중앙화 네트워크가 다음을 수행할 수 있도록 하는 것입니다. + +- 체인 헤드 추적 +- 최신 및 과거 체인 데이터 동기화 +- 상태 데이터 검색 +- 트랜잭션 브로드캐스트 +- [EVM](/developers/docs/evm/)을 사용하여 트랜잭션 실행 + +이 네트워크 설계의 이점은 다음과 같습니다. + +- 중앙화된 제공자에 대한 의존도 감소 +- 인터넷 대역폭 사용량 감소 +- 최소화 또는 제로 동기화 +- 리소스가 제한된 장치에서 접근 가능(\<1GB RAM, \<100MB 디스크 공간, 1 CPU) + +아래 표는 포털 네트워크를 통해 제공될 수 있는 기존 클라이언트의 기능을 보여주며, 사용자는 매우 저사양 장치에서 이러한 기능에 접근할 수 있습니다. + +### 포털 네트워크 + +| 비콘 라이트 클라이언트 | 상태 네트워크 | 트랜잭션 가십 | 히스토리 네트워크 | +| ------------ | --------------- | ------- | --------- | +| 비콘 체인 라이트 | 계정 및 컨트랙트 저장 공간 | 경량 멤풀 | 헤더 | +| 프로토콜 데이터 | | | 블록 본문 | +| | | | 영수증 | + +## 기본적인 클라이언트 다양성 {#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로 작성됨 + +여러 개의 독립적인 클라이언트 구현이 있으면 이더리움 네트워크의 복원력과 탈중앙화가 향상됩니다. + +한 클라이언트에 문제나 취약점이 발생하더라도 다른 클라이언트는 원활하게 계속 작동하여 단일 실패 지점을 방지할 수 있습니다. 또한, 다양한 클라이언트 구현은 혁신과 경쟁을 촉진하여 생태계 내 개선을 이끌고 단일 문화의 위험을 줄입니다. + +## 더 읽어보기 {#further-reading} + +- [포털 네트워크 (Devcon 보고타에서 Piper Merriam 발표)](https://www.youtube.com/watch?v=0stc9jnQLXA). +- [포털 네트워크 디스코드](https://discord.gg/CFFnmE7Hbs) +- [포털 네트워크 웹사이트](https://www.ethportal.net/) diff --git a/public/content/translations/ko/developers/docs/networks/index.md b/public/content/translations/ko/developers/docs/networks/index.md new file mode 100644 index 00000000000..db2d6fdeb4f --- /dev/null +++ b/public/content/translations/ko/developers/docs/networks/index.md @@ -0,0 +1,216 @@ +--- +title: "네트워크" +description: "이더리움 네트워크에 대한 설명서 및 테스트용 이더(ETH)를 획득하는 방법" +lang: ko +--- + +이더리움 네트워크는 이더리움 프로토콜을 사용하여 통신하는 연결된 컴퓨터 그룹입니다. 이더리움 메인넷은 하나뿐이지만, 테스트 및 개발 목적으로 동일한 프로토콜 규칙을 따르는 독립적인 네트워크를 생성할 수 있습니다. 서로 상호 작용하지 않으면서 프로토콜을 준수하는 독립적인 "네트워크"가 많이 있습니다. 스마트 계약과 웹3 앱을 테스트하기 위해 자신의 컴퓨터에서 로컬로 네트워크를 시작할 수도 있습니다. + +이더리움 주소 (Ethereum account) 는 서로 다른 네트워크에서 똑같이 이용될 수 있습니다. 하지만 주소의 잔액 (balance) 및 거래 내역 (transaction history) 는 네트워크마다 다를 수 있습니다. 테스트 작업을 위해 어떤 네트워크가 필요한지, 그리고 테스트넷 이더리움을 획득하는 방법을 알면 유용합니다. 일반적으로 보안상의 이유로 테스트넷에서 메인넷 계정을 재사용하거나 그 반대의 경우는 권장하지 않습니다. + +## 필수 구성 요소 {#prerequisites} + +테스트넷은 저렴하고 안전한 버전의 이더리움을 제공하므로 여러 네트워크에 대해 알아보기 전에 [이더리움의 기본 사항](/developers/docs/intro-to-ethereum/)을 이해해야 합니다. + +## 공개 네트워크 {#public-networks} + +공용 네트워크에는 인터넷에 연결할 수 있는 모든 사람이 접근할 수 있습니다. 누구나 공용 블록체인 상의 트랜잭션을 읽거나 만들고 트랜잭션이 실행되도록 승인할 수 있습니다. 개인간의 합의를 통해 거래의 승인 및 네트워크의 상태가 결정된다. + +### 이더리움 메인넷 {#ethereum-mainnet} + +메인넷이란 실제 거래가 분산 장부에 기록되는 이더리움 블록체인이다. + +코인 거래소에서 보여주는 ETH 가격이 바로 메인넷 이더리움 가격이다. + +### 이더리움 테스트넷 {#ethereum-testnets} + +메인넷 외에도 공용 테스트넷이 있습니다. 테스트넷은 프로토콜 개발자 또는 스마트계약 개발자들이 메인넷에 배포하기 전 실제 환경과 비슷한 가상의 환경에서 프로토콜 업그레이드 또는 스마트계약 테스트를 위해 활용된다. 비유를 들자면, 프로덕션 서버와 스테이징 서버의 관계와 비슷하다. + +사실 메인넷에 배포하기 전 모든 스마트계약 코드는 테스트넷에서 테스트를 거쳐야 한다. 이미 배포된 스마트계약에 통합되는 댑 dapp 들은 대부분 테스트넷에 배포 단계를 거쳤다. + +대부분의 테스트넷은 허가된 proof-of-authority 합의 메커니즘을 사용하여 시작되었습니다. 즉, 소수의 노드가 거래 검증 및 새 블록 형성에 사용되며 이 때 각 과정에서 신분확인이 이뤄집니다. 또는 일부 테스트넷은 이더리움 메인넷처럼 모든 사람이 벨리데이터 실행을 테스트할 수 있는 개방형 PoS 합의 메커니즘을 특징으로 합니다. + +테스트넷의 ETH는 실제 가치가 없는 것으로 간주되지만, 희소해지거나 구하기 어려워진 특정 유형의 테스트넷 ETH에 대한 시장이 형성되기도 했습니다. 이더리움과 상호작용하려면(테스트넷에서도) ETH가 필요하기 때문에, 대부분의 사람들은 포싯에서 테스트넷 ETH를 무료로 받습니다. faucet은 ETH를 받을 주소를 입력할 수 있는 웹앱인 경우가 많다. + +#### 어떤 동기화 방법을 사용해야 할까요? + +현재 클라이언트 개발자들이 유지 관리하는 두 개의 공개 테스트넷은 Sepolia와 Hoodi입니다. Sepolia는 컨트랙트와 어플리케이션 개발자들이 그들의 어플리케이션을 테스트하기 위해서 필요한 네트워크입니다. Hoodi 네트워크를 통해 프로토콜 개발자는 네트워크 업그레이드를 테스트하고, 스테이커는 검증자 실행을 테스트할 수 있습니다. + +#### 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/) + +##### Faucets + +- [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) +- [Ethereum Ecosystem 포싯](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) + +#### Hoodi {#hoodi} + +Hoodi는 검증 및 스테이킹을 테스트하기 위한 테스트넷입니다. Hoodi 네트워크는 테스트넷 검증자를 실행하려는 사용자에게 열려 있습니다. 따라서 메인넷에 배포되기 전에 프로토콜 업그레이드를 테스트하려는 스테이커는 Hoodi를 사용해야 합니다. + +- 개방형 검증자 세트, staker가 네트워크 업그레이드를 테스트할 수 있음 +- 복잡한 스마트 계약 상호 작용을 테스트하는 데 유용한 대규모 state +- 동기화 시간이 길어지고 노드를 실행하는 데 더 많은 스토리지 필요 + +##### 참고 자료 + +- [웹사이트](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/) + +##### Faucets + +- [Chain Platform Hoodi 포싯](https://faucet.chainplatform.co/faucets/ethereum-hoodi/) +- [Hoodi 포싯](https://hoodi.ethpandaops.io/) +- [PoW 포싯](https://hoodi-faucet.pk910.de/) + +#### Ephemery {#ephemery} + +Ephemery는 매달 완전히 재설정되는 독특한 종류의 테스트넷입니다. 실행 및 합의 상태는 28일마다 제네시스로 되돌아가는데, 이는 테스트넷에서 발생하는 모든 것이 일시적이라는 것을 의미합니다. 따라서 영속성이 필요 없는 단기 테스트, 빠른 노드 부트스트랩 및 '헬로 월드' 유형의 애플리케이션에 이상적입니다. + +- 항상 최신 상태, 검증자 및 앱의 단기 테스트 +- 기본 계약 세트만 포함합니다. +- 개방형 검증자 세트 및 대량의 자금에 대한 쉬운 접근성 +- 가장 작은 노드 요구 사항과 가장 빠른 동기화, 평균 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/) + +#### Faucets + +- [Bordel 포싯](https://faucet.bordel.wtf/) +- [Pk910 PoW 포싯](https://ephemery-faucet.pk910.de/) + +#### Holesky(지원 중단) {#holesky} + +Holesky 테스트넷은 2025년 9월부터 지원이 중단됩니다. 스테이킹 운영자와 인프라 제공업체는 대신 검증자 테스트에 Hoodi를 사용해야 합니다. + +- [Holesky 테스트넷 종료 발표](https://blog.ethereum.org/2025/09/01/holesky-shutdown-announcement) - _EF 블로그, 2025년 9월 1일_ +- [Holesky 및 Hoodi 테스트넷 업데이트](https://blog.ethereum.org/en/2025/03/18/hoodi-holesky) - _EF 블로그, 2025년 3월 18일_ + +### 레이어 2 테스트넷 {#layer-2-testnets} + +[레이어 2(L2)](/layer-2/)는 특정 이더리움 확장 솔루션 세트를 설명하는 총칭입니다. 레이어 2는 이더리움 블록체인을 확장하는 또다른 블록체인이며 이더리움의 보안성을 그대로 이어 받는다. 레이어 2에 속한 테스트넷은 주로 이더리움 테스트넷과 큰 연관성을 보인다. + +#### Arbitrum Sepolia {#arbitrum-sepolia} + +[Arbitrum](https://arbitrum.io/)을 위한 테스트넷입니다. + +##### 참고 자료 + +- [Etherscan](https://sepolia.arbiscan.io/) +- [Blockscout](https://sepolia-explorer.arbitrum.io/) + +##### Faucets + +- [Alchemy Arbitrum Sepolia 포싯](https://www.alchemy.com/faucets/arbitrum-sepolia) +- [Chainlink Arbitrum Sepolia 포싯](https://faucets.chain.link/arbitrum-sepolia) +- [ethfaucet.com Arbitrum Sepolia 포싯](https://ethfaucet.com/networks/arbitrum) +- [QuickNode Arbitrum Sepolia 포싯](https://faucet.quicknode.com/arbitrum/sepolia) + +#### Optimistic Sepolia {#optimistic-sepolia} + +[Optimism](https://www.optimism.io/)을 위한 테스트넷입니다. + +##### 참고 자료 + +- [Etherscan](https://sepolia-optimistic.etherscan.io/) +- [Blockscout](https://optimism-sepolia.blockscout.com/) + +##### Faucets + +- [Alchemy 포싯](https://www.alchemy.com/faucets/optimism-sepolia) +- [Chainlink 포싯](https://faucets.chain.link/optimism-sepolia) +- [ethfaucet.com Optimism Sepolia 포싯](https://ethfaucet.com/networks/optimism) +- [테스트넷 포싯](https://docs.optimism.io/builders/tools/build/faucets) + +#### Starknet Sepolia {#starknet-sepolia} + +[Starknet](https://www.starknet.io)을 위한 테스트넷입니다. + +##### 참고 자료 + +- [Starkscan](https://sepolia.starkscan.co/) + +##### Faucets + +- [Alchemy 포싯](https://www.alchemy.com/faucets/starknet-sepolia) +- [Blast Starknet Sepolia 포싯](https://blastapi.io/faucets/starknet-sepolia-eth) +- [Starknet 포싯](https://starknet-faucet.vercel.app/) + +## 프라이빗 네트워크 {#private-networks} + +이더리움 네트워크의 노드가 공개 네트워크(즉, 메인넷 또는 테스트넷)에 연결되지 않은 경우 해당 네트워크는 프라이빗 네트워크입니다. 여기서 개인 (private) 이란 독립적이란 뜻이며 (reserved, isolated) 안전 (protected, secure) 하다는 뜻은 아니다. + +### 개발 네트워크 {#development-networks} + +이더리움 애플리케이션을 개발하려면 이를 배포하기 전 개인 네트워크에 돌려보면서 확인하는 것을 선호할 수 있다. 웹 개발자들이 로컬 환경에서 서버를 생성하여 작업하는 방식처럼 블록체인도 로컬 환경에서 인스턴스를 생성하여 댑을 테스트 할 수 있다. 이는 공개 테스트넷보다 속도 면에서 더 빠르다는 장점이 있다. + +개발 네트워크에 유용한 프로젝트와 개발툴들이 있다. [개발 네트워크](/developers/docs/development-networks/)에 대해 자세히 알아보세요. + +### 컨소시엄 네트워크 {#consortium-networks} + +합의 프로세스는 사전에 설정되고 검증된 노드들에 의해 관리된다. 교육 기관들의 개인 네트워크가 각각 단일 노드를 운영하며 네트워크 내 서명자 기준으로 인해 블록이 검증되는 경우를 예로 들을 수 있다. + +공개 이더리움 네트워크가 인터넷과 비유할 수 있다면, 공동 네트워크는 인트라넷과 비슷하다고 볼 수 있다. + +## 왜 이더리움 테스트넷은 지하철역의 이름을 따서 명명되었을까요? {#why-naming} + +많은 이더리움 테스트넷은 실제 지하철이나 기차역의 이름을 따서 명명되었습니다. 이 명명 전통은 초기에 시작되었으며 기여자들이 거주하거나 일했던 전 세계 도시를 반영합니다. 상징적이고 기억하기 쉬우며 실용적입니다. 테스트넷이 이더리움 메인넷과 분리되어 있는 것처럼, 지하철 노선도 지상 교통과 별도로 운행됩니다. + +### 일반적으로 사용되는 레거시 테스트넷 {#common-and-legacy-testnets} + +- **Sepolia** - 그리스 아테네의 지하철과 연결된 지역입니다. 현재 스마트 계약 및 탈중앙화앱 테스트에 사용됩니다. +- **Hoodi** - 인도 벵갈루루에 있는 Hoodi 지하철역의 이름을 딴 것입니다. 검증자 및 프로토콜 업그레이드 테스트에 사용됩니다. +- **Goerli** _(지원 중단)_ - 독일 베를린의 Görlitzer Bahnhof의 이름을 딴 것입니다. +- **Rinkeby** _(지원 중단)_ - 지하철역이 있는 스톡홀름 교외 지역의 이름을 딴 것입니다. +- **Ropsten** _(지원 중단)_ - 스톡홀름의 한 지역이자 이전의 페리/지하철 터미널을 가리킵니다. +- **Kovan** _(지원 중단)_ - 싱가포르 MRT 역의 이름을 딴 것입니다. +- **Morden** _(지원 중단)_ - 런던 지하철역의 이름을 딴 것입니다. 이더리움 최초의 공개 테스트넷입니다. + +### 기타 특수 테스트넷 {#other-testnets} + +일부 테스트넷은 단기 또는 업그레이드별 테스트를 위해 만들어졌으며 반드시 지하철을 테마로 하지는 않습니다. + +- **Holesky** _(지원 중단)_ - 프라하의 Holešovice 역의 이름을 딴 것입니다. 검증자 테스트에 사용되었으며, 2025년에 지원이 중단되었습니다. +- **Kiln**, **Zhejiang**, **Shandong**, **Prater**, **Pyrmont**, **Olympic** _(모두 지원 중단)_ 및 **Ephemery** - 머지, 상하이 또는 검증자 실험과 같은 업그레이드 시뮬레이션을 위해 특수 제작되었습니다. 일부 이름은 지하철 기반이 아닌 지역적이거나 주제별 이름입니다. + +지하철역 이름을 사용하면 개발자가 숫자 체인 ID에 의존할 필요 없이 테스트넷을 신속하게 식별하고 기억하는 데 도움이 됩니다. 또한 실용적이고, 세계적이며, 인간 중심적인 이더리움의 문화를 반영합니다. + +## 관련 도구 {#related-tools} + +- [Chainlist](https://chainlist.org/) _지갑과 공급자를 적절한 체인 ID 및 네트워크 ID에 연결하기 위한 EVM 네트워크 목록_ +- [EVM 기반 체인](https://github.com/ethereum-lists/chains) _Chainlist를 구동하는 체인 메타데이터의 GitHub 리포지토리_ + +## 더 읽어보기 {#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/) diff --git a/public/content/translations/ko/developers/docs/nodes-and-clients/archive-nodes/index.md b/public/content/translations/ko/developers/docs/nodes-and-clients/archive-nodes/index.md new file mode 100644 index 00000000000..aad64bb38a8 --- /dev/null +++ b/public/content/translations/ko/developers/docs/nodes-and-clients/archive-nodes/index.md @@ -0,0 +1,81 @@ +--- +title: "이더리움 아카이브 노드" +description: "아카이브 노드 개요" +lang: ko +sidebarDepth: 2 +--- + +아카이브 노드는 모든 기록 상태의 아카이브를 구축하기 위해 구성된 이더리움 클라이언트의 인스턴스입니다. 특정한 목적에는 유용한 기능이지만 풀 노드보다 실행하기가 더 까다로울 수 있습니다. + +## 필수 구성 요소 {#prerequisites} + +[이더리움 노드](/developers/docs/nodes-and-clients/), [아키텍처](/developers/docs/nodes-and-clients/node-architecture/), [동기화 전략](/developers/docs/nodes-and-clients/#sync-modes)의 개념과 노드를 [실행](/developers/docs/nodes-and-clients/run-a-node/)하고 [사용](/developers/docs/apis/json-rpc/)하는 방법을 이해해야 합니다. + +## 아카이브 노드란 + +아카이브 노드의 중요성을 이해하기 위해 "상태"의 개념을 명확히 해야 합니다. 이더리움은 _트랜잭션 기반 상태 머신_이라고 할 수 있습니다. 이는 상태를 변경하는 트랜잭션을 실행하는 계정과 애플리케이션으로 구성됩니다. 각 계정과 계약에 대한 정보가 포함된 글로벌 데이터는 상태라는 트라이 데이터베이스에 저장됩니다. 이는 실행 레이어(EL) 클라이언트에서 처리하며 다음을 포함합니다: + +- 계정 잔액 및 논스 +- 컨트랙트 코드 및 저장소 +- 합의 관련 데이터(예: 스테이킹 예치 계약) + +네트워크와 상호작용하고 새로운 블록 검증 및 생성을 위해서는 크더리움 클라이언트는 가장 최근의 변화(체인 마지막) 와 현재의 상태를 유지해야 합니다. 전체 노드로 구성된 실행 레이어 클라이언트는 네트워크의 최신 상태를 확인하고 따르지만, 체인 재구성을 처리하고 최근 데이터에 빠르게 액세스할 수 있도록 마지막 128개 블록과 관련된 상태와 같이 지난 몇 개의 상태만 캐시합니다. 최근 상태는 모든 클라이언트가 수신 트랜잭션을 검증하고 네트워크를 사용하기 위해 필요한 정보입니다. + +상태는 특정 블록의 순간적인 네트워크 스냅샷으로, 아카이브는 히스토리로 추측할 수 있습니다. + +과거 상태는 네트워크 작동에 필요하지 않으며 클라이언트가 모든 오래된 데이터를 보관하는 것은 불필요하게 중복되므로 안전하게 제거될 수 있습니다. 최근 블록(예: 헤드 이전 128개 블록) 이전에 존재했던 상태는 사실상 폐기됩니다. 전체 노드는 과거 블록체인 데이터(블록 및 트랜잭션)와 요청 시 이전 상태를 재생성하는 데 사용할 수 있는 간헐적인 과거 스냅샷만 보관합니다. 이는 EVM에서 과거 트랜잭션을 재실행하여 수행되는데, 원하는 상태가 가장 가까운 스냅샷에서 멀리 떨어져 있을 경우 계산 집약적일 수 있습니다. + +그러나 이는 전체 노드에서 과거 상태에 액세스하는 것이 많은 계산을 소모한다는 것을 의미합니다. 클라이언트는 모든 과거 트랜잭션을 실행하고 제네시스로부터 하나의 과거 상태를 계산해야 할 수도 있습니다. 아카이브 노드는 가장 최근 상태뿐만 아니라 각 블록 이후에 생성된 모든 과거 상태를 저장하여 이 문제를 해결합니다. 기본적으로 더 큰 디스크 공간 요구 사항과 절충합니다. + +네트워크가 모든 과거 데이터를 보관하고 제공하기 위해 아카이브 노드에 의존하지 않는다는 점에 유의하는 것이 중요합니다. 위에서 언급했듯이, 모든 과거 중간 상태는 전체 노드에서 파생될 수 있습니다. 트랜잭션은 모든 전체 노드에 저장되며(현재 400G 미만) 전체 아카이브를 구축하기 위해 재생될 수 있습니다. + +### 사용 사례 + +트랜잭션 전송, 계약 배포, 합의 확인 등과 같은 일반적인 이더리움 사용은 과거 상태에 대한 액세스를 필요로 하지 않습니다. 사용자는 네트워크와의 표준적인 상호작용을 위해 아카이브 노드를 필요로 하지 않습니다. + +상태 아카이브의 주요 이점은 과거 상태에 대한 쿼리에 빠르게 액세스할 수 있다는 것입니다. 예를 들어, 아카이브 노드는 다음과 같은 결과를 즉시 반환합니다. + +- _계정 0x1337...의 ETH 잔액은 얼마였습니까?_ 블록 15537393에서?_ +- _블록 1920000에서 계약 0x에 있는 토큰 0x의 잔액은 얼마입니까?_ + +위에서 설명한 대로, 전체 노드는 CPU를 사용하고 시간이 걸리는 EVM 실행을 통해 이 데이터를 생성해야 합니다. 아카이브 노드는 디스크에서 액세스하여 응답을 즉시 제공합니다. 이것은 인프라의 특정 부분에 유용한 기능입니다. 예를 들면 다음과 같습니다. + +- 블록 탐색기와 같은 서비스 제공자 +- 연구원 +- 보안 분석가 +- 탈중앙화앱 개발자 +- 감사 및 규정 준수 + +과거 데이터에 대한 액세스를 허용하는 다양한 무료 [서비스](/developers/docs/nodes-and-clients/nodes-as-a-service/)도 있습니다. 아카이브 노드를 실행하는 것이 더 까다롭기 때문에 이 액세스는 대부분 제한적이며 간헐적인 액세스에만 작동합니다. 프로젝트에 과거 데이터에 대한 지속적인 액세스가 필요한 경우 직접 하나를 실행하는 것을 고려해야 합니다. + +## 구현 및 사용법 + +이 맥락에서 아카이브 노드는 상태 데이터베이스를 처리하고 JSON-RPC 엔드포인트를 제공하는 사용자 대면 실행 레이어 클라이언트가 제공하는 데이터를 의미합니다. 구성 옵션, 동기화 시간 및 데이터베이스 크기는 클라이언트에 따라 다를 수 있습니다. 자세한 내용은 클라이언트에서 제공하는 개발문서를 참조하십시오. + +자신만의 아카이브 노드를 시작하기 전에 클라이언트 간의 차이점과 특히 다양한 [하드웨어 요구 사항](/developers/docs/nodes-and-clients/run-a-node/#requirements)에 대해 알아보십시오. 대부분의 클라이언트는 이 기능에 최적화되어 있지 않으며 해당 아카이브에는 12TB 이상의 공간이 필요합니다. 대조적으로, Erigon과 같은 구현은 동일한 데이터를 3TB 미만으로 저장할 수 있으므로 아카이브 노드를 실행하는 가장 효과적인 방법입니다. + +## 권장 사례 + +일반적인 [노드 실행 권장 사항](/developers/docs/nodes-and-clients/run-a-node/) 외에도 아카이브 노드는 하드웨어 및 유지 관리 측면에서 더 까다로울 수 있습니다. Erigon의 [주요 기능](https://github.com/ledgerwatch/erigon#key-features)을 고려할 때 가장 실용적인 접근 방식은 [Erigon](/developers/docs/nodes-and-clients/#erigon) 클라이언트 구현을 사용하는 것입니다. + +### 하드웨어 + +항상 클라이언트의 개발문서에서 특정 모드에 대한 하드웨어 요구 사항을 확인하십시오. +아카이브 노드의 가장 큰 요구 사항은 디스크 공간입니다. 클라이언트에 따라 3TB에서 12TB까지 다양합니다. HDD가 대용량 데이터에 더 나은 솔루션으로 간주될 수 있지만, 동기화하고 체인의 헤드를 지속적으로 업데이트하려면 SSD 드라이브가 필요합니다. [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) 드라이브로도 충분하지만, 최소한 [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences) 이상의 신뢰할 수 있는 품질이어야 합니다. 디스크는 충분한 슬롯이 있는 데스크톱 컴퓨터나 서버에 장착할 수 있습니다. 이러한 전용 장치는 가동 시간이 긴 노드를 실행하는 데 이상적입니다. 노트북에서 실행하는 것도 전적으로 가능하지만 휴대성에는 추가 비용이 따릅니다. + +모든 데이터는 하나의 볼륨에 들어가야 하므로 디스크를 결합해야 합니다(예: [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) 또는 LVM). 데이터가 하위 수준 오류 없이 디스크에 올바르게 기록되도록 보장하는 "기록 중 복사(Copy-on-write)"를 지원하므로 [ZFS](https://en.wikipedia.org/wiki/ZFS) 사용도 고려해 볼 가치가 있습니다. + +우발적인 데이터베이스 손상을 방지하고 안정성과 보안을 높이기 위해, 특히 전문적인 환경에서는 시스템이 지원하는 경우 [ECC 메모리](https://en.wikipedia.org/wiki/ECC_memory) 사용을 고려하십시오. RAM 크기는 일반적으로 전체 노드와 동일하게 권장되지만, RAM이 많을수록 동기화 속도를 높이는 데 도움이 될 수 있습니다. + +초기 동기화 중에 아카이브 모드의 클라이언트는 제네시스 이후의 모든 트랜잭션을 실행합니다. 실행 속도는 대부분 CPU에 의해 제한되므로 더 빠른 CPU는 초기 동기화 시간을 단축하는 데 도움이 될 수 있습니다. 평균적인 소비자용 컴퓨터에서 초기 동기화는 최대 한 달이 걸릴 수 있습니다. + +## 더 읽어보기 {#further-reading} + +- [이더리움 전체 노드 vs 아카이브 노드](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) - _QuickNode, 2022년 9월_ +- [나만의 이더리움 아카이브 노드 구축하기](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) - _Thomas Jay Rush, 2021년 8월_ +- [Erigon, Erigon RPC 및 TrueBlocks(스크레이프 및 API)를 서비스로 설정하는 방법](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– Magnus Hansson, 2022년 9월 업데이트됨_ + +## 관련 주제 {#related-topics} + +- [노드 및 클라이언트](/developers/docs/nodes-and-clients/) +- [노드 실행하기](/developers/docs/nodes-and-clients/run-a-node/) diff --git a/public/content/translations/ko/developers/docs/nodes-and-clients/bootnodes/index.md b/public/content/translations/ko/developers/docs/nodes-and-clients/bootnodes/index.md new file mode 100644 index 00000000000..fd37491c7cd --- /dev/null +++ b/public/content/translations/ko/developers/docs/nodes-and-clients/bootnodes/index.md @@ -0,0 +1,31 @@ +--- +title: "이더리움 부트노드 소개" +description: "부트노드를 이해하는 데 필요한 기본 정보" +lang: ko +--- + +새 노드가 이더리움 네트워크에 참여할 때 새로운 피어를 찾기 위해 네트워크에 이미 있는 노드에 연결해야 합니다. 이더리움 네트워크로 들어가는 이러한 진입점을 부트노드라고 합니다. 클라이언트에는 일반적으로 부트노드 목록이 하드코딩되어 있습니다. 이러한 부트노드는 일반적으로 이더리움 재단의 데브옵스 팀이나 클라이언트 팀 자체에서 운영합니다. 부트노드는 정적 노드와 같지 않다는 점에 유의하세요. 정적 노드는 반복적으로 호출되는 반면, 부트노드는 연결할 피어가 충분하지 않아 노드가 새로운 연결을 부트스트랩해야 하는 경우에만 호출됩니다. + +## 부트노드에 연결하기 {#connect-to-a-bootnode} + +대부분의 클라이언트에는 부트노드 목록이 내장되어 있지만, 직접 부트노드를 실행하거나 클라이언트의 하드코딩된 목록에 포함되지 않은 부트노드를 사용하고 싶을 수도 있습니다. 이 경우, 클라이언트를 시작할 때 다음과 같이 지정할 수 있습니다(예시는 Geth용이며, 사용 중인 클라이언트의 개발문서를 확인하시기 바랍니다): + +``` +geth --bootnodes "enode://<노드 ID>@:<포트>" +``` + +## 부트노드 실행하기 {#run-a-bootnode} + +부트노드는 NAT([네트워크 주소 변환](https://www.geeksforgeeks.org/network-address-translation-nat/)) 뒤에 있지 않은 풀노드입니다. 모든 풀노드는 공개적으로 사용 가능한 한 부트노드 역할을 할 수 있습니다. + +노드를 시작하면 다른 사용자가 노드에 연결하는 데 사용할 수 있는 공개 식별자인 [enode](/developers/docs/networking-layer/network-addresses/#enode)가 기록되어야 합니다. + +enode는 일반적으로 재시작할 때마다 재생성되므로, 부트노드에 대한 영구 enode를 생성하는 방법은 클라이언트 개발문서를 참조하세요. + +좋은 부트노드가 되려면 연결할 수 있는 최대 피어 수를 늘리는 것이 좋습니다. 많은 피어와 함께 부트노드를 실행하면 대역폭 요구 사항이 크게 증가합니다. + +## 사용 가능한 부트노드 {#available-bootnodes} + +go-ethereum에 내장된 부트노드 목록은 [여기](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23)에서 확인할 수 있습니다. 이 부트노드들은 이더리움 재단과 go-ethereum 팀에 의해 유지 관리됩니다. + +자원봉사자들이 유지 관리하는 다른 부트노드 목록도 있습니다. 항상 하나 이상의 공식 부트노드를 포함하도록 하세요. 그렇지 않으면 이클립스 공격을 받을 수 있습니다. diff --git a/public/content/translations/ko/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/ko/developers/docs/nodes-and-clients/client-diversity/index.md new file mode 100644 index 00000000000..59261b9b25b --- /dev/null +++ b/public/content/translations/ko/developers/docs/nodes-and-clients/client-diversity/index.md @@ -0,0 +1,132 @@ +--- +title: "클라이언트의 다양성" +description: "이더리움 클라이언트 다양성의 중요성에 대한 고급 설명" +lang: ko +sidebarDepth: 2 +--- + +이더리움 노드의 동작은 클라이언트 소프트웨어가 제어한다. 프로덕션 레벨의 이더리움 클라이언트는 다수 존재하는데 제각각 서로 다른 팀과 언어로 유지되고 있다. 클라이언트는 서로간의 원활한 통신을 보장하며 똑같은 기능과 UX를 가지는 공통 스펙이다. 하지만 노드 간 클라이언트 배포 시에는 해당 네트워크가 최대한으로 강해지게 할 만큼 충분하지는 않다. 이상적인 상황은 유저들이 서로다른 클라이언트들 사이로 엇비슷하게 나뉘어져서 네트워크에 클라이언트 다양성을 최대한으로 이끌어내는 것이다. + +## 필수 구성 요소 {#prerequisites} + +노드와 클라이언트가 무엇인지 아직 이해하지 못했다면 [노드와 클라이언트](/developers/docs/nodes-and-clients/)를 확인해 보세요. [실행](/glossary/#execution-layer) 레이어와 [합의](/glossary/#consensus-layer) 레이어는 용어집에 정의되어 있습니다. + +## 왜 클라이언트는 여러 개 있는가? {#why-multiple-clients} + +복수의 독립적으로 개발되고 유지되는 클라이언트는 클라이언트 다양성이 네트워크를 해킹과 버그에 더 내성이 강하기 때문에 존재한다. 복수의 클라이언트는 이더리움에 국한된 장점이다. - 다른 블록체인은 단일 클라이언트에 의존한다. 하지만 단순히 여러 클라이언트를 사용할 수 있는 것만으로는 충분하지 않으며, 커뮤니티에서 이를 채택하고 총 활성 노드가 여러 클라이언트에 걸쳐 비교적 고르게 분산되어야 합니다. + +## 클라이언트 다양성이 왜 중요한가요? {#client-diversity-importance}클라이언트-충격 + +독립적으로 개발되고 유지되는 다수의 클라이언트는 탈중앙화 네트워크의 상태를 좌지우지 한다. 왜 그런지 알아본다. + +### 버그 {#bugs} + +이더리움 노드의 작은 부분만을 차지하는 개별 클라이언트 내 버그는 전체 네트워크에 미치는 영향이 보다 덜 위협적이다. 다수의 클라이언트에 균등하게 분배된 노드라면 대부분의 클라이언트들이 공통 이슈를 겪게 될 확률이 적다. 따라서 보다 더 안정적인 네트워크가 된다. + +### 공격에 대한 복원력 {#resilience} + +클라이언트 다양성은 해킹 방어에도 도움이 된다. 예를 들어, [특정 클라이언트를 속여](https://twitter.com/vdWijden/status/1437712249926393858) 특정 체인 분기로 유도하는 공격은 성공할 가능성이 낮습니다. 다른 클라이언트는 동일한 방식으로 악용될 가능성이 낮고 정식 체인은 손상되지 않은 상태로 유지되기 때문입니다. 클라이언드 다양성이 크지 않으면 몇몇 클라이언트가 해킹되면 다른 클라이언트들도 취약해진다. 클라이언트 다양성은 네트워크에 대한 악의적인 공격에 대한 중요한 방어 수단임이 이미 입증되었습니다. 예를 들어, 2016년 상하이 서비스 거부 공격은 공격자가 지배적인 클라이언트(Geth)를 속여 블록당 수만 번의 느린 디스크 I/O 작업을 실행하도록 할 수 있었기 때문에 가능했습니다. 반면 이더리움은 클라이언트들이 해당 해킹에 취약점을 보이지 않았기 때문에 피해를 받지 않았으며 Geth 취약점이 보완될 때까지 문제없이 작동하였다. + +### 지분증명 완결성 {#finality} + +이더리움 노드의 33% 이상을 차지하는 합의 클라이언트의 버그는 합의 레이어의 완결을 막을 수 있습니다. 이는 사용자가 어느 시점에서 트랜잭션이 되돌려지거나 변경되지 않을 것이라고 신뢰할 수 없음을 의미합니다. 이것은 이더리움 위에 구축된 많은 앱, 특히 DeFi에 매우 문제가 될 것이다. + + 설상가상으로, 3분의 2의 다수를 차지하는 클라이언트의 심각한 버그는 체인이 잘못 분할되고 완결되는 원인이 될 수 있으며, 이는 많은 검증자들이 유효하지 않은 체인에 갇히게 되는 결과로 이어질 수 있습니다. 만약 그들이 올바른 체인에 다시 가입하기를 원한다면, 이러한 검증자들은 쫒겨나거나 느리고 비용이 많이 드는 자발적인 탈퇴와 재활성화에 직면하게 된다. 슬래싱의 크기는 최대로 대폭 삭감(32 ETH)된 2/3 다수의 과실이 있는 노드의 수에 따라 확장된다. + +비록 발생 확률이 적은 시나리오이지만, 이더리움 에코 시스템은 활성 노드들 간 클라이언트 분산을 더 반반하게 함으로서 위험성을 줄일 수 있다. 이상적으로는 컨센서스 클라이언트가 전체 노드의 33% 이상의 지분을 갖지 않는 것이 좋다. + +### 공동 책임 {#responsibility} + +다수의 클라이언트를 소유하는 것은 인건비가 들지 않기도 하다. 그러나 소규모 개발팀에는 과중된 업무와 책임이 될 수 있다. 클라이언트 다양성이 작을수록 개발자들은 다수 클라이언트를 유지하기 위한 책임이 더 커진다는 의미이다. 이러한 책임을 여러 팀들에 분담하는 것이 이더리움 네트워크 노드와 이용자들에게 더 좋은 일이다. + +## 현재 클라이언트 다양성 {#current-client-diversity} + +### 실행 클라이언트 {#execution-clients-breakdown} + + + +### 합의 클라이언트 {#consensus-clients-breakdown} + + + +이 다이어그램은 오래된 정보일 수 있습니다. 최신 정보는 [ethernodes.org](https://ethernodes.org) 및 [clientdiversity.org](https://clientdiversity.org)를 참조하세요. + +위의 두 파이 차트는 실행 및 합의 레이어에 대한 현재 클라이언트 다양성의 스냅샷을 보여줍니다(2025년 10월 작성 시점 기준). 수년에 걸쳐 클라이언트 다양성이 개선되었으며, 실행 레이어에서는 [Geth](https://geth.ethereum.org/)의 지배력이 감소했습니다. [Nethermind](https://www.nethermind.io/nethermind-client)가 근소한 차이로 2위를, [Besu](https://besu.hyperledger.org/)가 3위, [Erigon](https://github.com/ledgerwatch/erigon)이 4위를 차지했으며, 다른 클라이언트들은 네트워크의 3% 미만을 구성합니다. 합의 레이어에서 가장 일반적으로 사용되는 클라이언트인 [Lighthouse](https://lighthouse.sigmaprime.io/)는 두 번째로 많이 사용되는 클라이언트와 점유율이 비슷합니다. [Prysm](https://prysmaticlabs.com/#projects)과 [Teku](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) 참조). 위 다이어그램에서 이러한 모호한 분류는 '또는' 형식의 레이블(예: Nimbus/Teku)로 처리됩니다. 그럼에도 불구하고, 대다수의 네트워크가 Prysm을 운영하고 있는 것은 분명하다. 스냅샷에 불과하지만 다이어그램의 값은 클라이언트 다양성의 현재 상태에 대한 일반적인 느낌을 제공합니다. + +합의 레이어에 대한 최신 클라이언트 다양성 데이터는 이제 [clientdiversity.org](https://clientdiversity.org/)에서 확인할 수 있습니다. + +## 실행 레이어 {#execution-layer} + +지금까지, 클라이언트 다양성에 대한 대화는 주로 합의 계층에 초점을 맞추었다. 그러나 실행 클라이언트인 [Geth](https://geth.ethereum.org)는 현재 모든 노드의 약 85%를 차지합니다. 이 비율은 컨센서스 클라이언트과 같은 이유로 문제가 있습니다. 예를 들어, Geth의 버그가 트랜잭션 처리에 영향을 미치거나 실행 페이로드를 구성하면 합의된 클라이언트가 문제가 있거나 버그가 있는 트랜잭션을 finalizing할 수 있습니다. 따라서 이더리움은 네트워크의 33% 이상을 대표하는 클라이언트가 없는 것이 이상적이며 실행 클라이언트가 더 고르게 분포되어 있어 더 건강할 것이다. + +## 소수 클라이언트 사용하기 {#use-minority-client} + +클라이언트 다양성 문제를 해결하려면 개인 사용자가 소수 클라이언트를 선택하는 것 이상이 필요합니다. 주요 탈중앙화앱 및 거래소와 같은 검증자 풀 및 기관도 클라이언트를 전환해야 합니다. 그러나 모든 사용자는 현재의 불균형을 시정하고 사용 가능한 모든 이더리움 소프트웨어의 사용을 정상화하는 데 자신의 역할을 할 수 있다. The Merge 이후 모든 노드 운영자는 실행 클라이언트와 합의 클라이언트를 실행해야 합니다. 아래에서 제안된 클라이언트 조합을 선택하면 클라이언트의 다양성을 높이는 데 도움이 됩니다. + +### 실행 클라이언트 {#execution-clients} + +- [Besu](https://www.hyperledger.org/use/besu) +- [Nethermind](https://downloads.nethermind.io/) +- [Erigon](https://github.com/ledgerwatch/erigon) +- [Go-Ethereum](https://geth.ethereum.org/) +- [Reth](https://reth.rs/) + +### 합의 클라이언트 {#consensus-clients} + +- [Nimbus](https://nimbus.team/) +- [Lighthouse](https://github.com/sigp/lighthouse) +- [Teku](https://consensys.io/teku) +- [Lodestar](https://github.com/ChainSafe/lodestar) +- [Prysm](https://prysm.offchainlabs.com/docs/) +- [Grandine](https://docs.grandine.io/) + +기술 사용자는 소수 클라이언트를 위한 더 많은 튜토리얼과 문서를 작성하고 노드 운영 피어가 지배적인 클라이언트로부터 벗어나도록 권장함으로써 이 프로세스를 가속화할 수 있습니다. 소수 합의 클라이언트로 전환하기 위한 가이드는 [clientdiversity.org](https://clientdiversity.org/)에서 확인할 수 있습니다. + +## 클라이언트 다양성 대시보드 {#client-diversity-dashboards} + +여러 대시보드는 실행 및 합의 계층에 대한 실시간 클라이언트 다양성 통계를 제공합니다. + +**합의 계층:** + +- [Rated.network](https://www.rated.network/) +- [clientdiversity.org](https://clientdiversity.org/) + +**실행 계층:** + +- [supermajority.info](https://supermajority.info//) +- [Ethernodes](https://ethernodes.org/) + +## 더 읽어보기 {#further-reading} + +- [이더리움 합의 레이어의 클라이언트 다양성](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) +- [이더리움 병합: 다수 클라이언트 실행의 위험성!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fiest, 2022년 3월 24일_ +- [클라이언트 다양성의 중요성](https://our.status.im/the-importance-of-client-diversity/) +- [이더리움 노드 서비스 목록](https://ethereumnodes.com/) +- ["Five Whys"의 클라이언트 다양성 문제](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08) +- [이더리움 다양성 및 해결 방법 (YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU) +- [clientdiversity.org](https://clientdiversity.org/) + +## 관련 주제 {#related-topics} + +- [이더리움 노드 운영하기](/run-a-node/) +- [노드 및 클라이언트](/developers/docs/nodes-and-clients/) From 39fee85d5862cacf439a17bf45b9a6932f9e013c Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Mon, 16 Feb 2026 11:19:04 +0000 Subject: [PATCH 2/2] fix(i18n): remove Crowdin artifact from heading ID in Korean translation --- .../ko/developers/docs/development-networks/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ko/developers/docs/development-networks/index.md b/public/content/translations/ko/developers/docs/development-networks/index.md index b1f0c72e735..41650b6aba8 100644 --- a/public/content/translations/ko/developers/docs/development-networks/index.md +++ b/public/content/translations/ko/developers/docs/development-networks/index.md @@ -12,7 +12,7 @@ lang: ko [이더리움 스택의 기본 사항](/developers/docs/ethereum-stack/)과 [이더리움 네트워크](/developers/docs/networks/)를 이해한 후에 개발 네트워크에 대해 자세히 알아보는 것이 좋습니다. -## 개발 네트워크란 무엇인가요? {#what-is-a-development-network}네트워크-충격 +## 개발 네트워크란 무엇인가요? {#what-is-a-development-network} 개발 네트워크는 기본적으로 로컬 개발을 위해 특별히 설계된 이더리움 클라이언트(이더리움 구현)입니다.