vrde
🖋
Richard McSorley
💻
Alejandro Santander
🖋
Alejandro Santander
🖋
Jason Carver
🖋
Chaitanya Potti
🖋
chriseth
🖋 👀
Sunghee Lee
🖋
awallendahl
🖋
Boris Mann
🖋
carumusan
🖋
carumusan
🖋
econoar
🖋
Gustavo Esquinca
🖋
Javier Tarazaga
🖋
{t(descriptionKey)}
{t(ctaKey)}
@@ -434,11 +440,7 @@ const Page = async ({ params }: { params: PageParams }) => {+ {t("page-community-support-hero-subtitle-1")} +
++ {t.rich("page-community-support-hero-subtitle-2", { + a: (chunks) => {chunks}, + })} +
++ {t("page-community-support-something-went-wrong-description")} +
+ + {t("page-community-support-lost-funds-scam")} + + + {t("page-community-support-secure-remaining-funds")} + + + {t("page-community-support-report-scam")} + + + {t("page-community-support-trace-funds")} + + + {t("page-community-support-sent-wrong-address")} + + + {t("page-community-support-lost-wallet-access")} + + + {t("page-community-support-stuck-transaction")} + ++ {t("page-community-support-protect-yourself-description")} +
+ + {t("page-community-support-common-scam-tactics")} + + + {t("page-community-support-recovery-experts-scams")} + + + {t("page-community-support-identify-scam-tokens")} + + + {t("page-community-support-full-security-guide")} + + + {t("page-community-support-revoke-approvals")} + ++ {t("page-community-support-using-ethereum-description")} +
+ + {t("page-community-support-create-account")} + + + {t("page-community-support-use-wallet")} + + + {t("page-community-support-swap-tokens")} + + + {t("page-community-support-bridge-tokens")} + + + {t("page-community-support-revoke-token-access")} + ++ {t( + "page-community-support-common-misconceptions-description" + )} +
+ + {t("page-community-support-is-ethereum-company")} + + + {t("page-community-support-recover-freeze-funds")} + + + {t("page-community-support-mine-ethereum")} + + + {t("page-community-support-is-support-team")} + ++ {t("page-community-support-still-need-help-description")} +
+Last updated by { + lastSetterAddress === account.address ? "you" : lastSetterAddress + }
+ )} ``` -We don't want to clutter the UI with all the information, so to make it possible to view them or close them, we use a [`details`](https://www.w3schools.com/tags/tag_details.asp) tag. +If we know who set the greeting last, display that information. `Greeter` does not keep track of this information, and we don't want to look back for `SetGreeting` events, so we only get it once the greeting is changed while we are running. ```tsx -
- {JSON.stringify(attrs.object, null, 2)}
+
+
+
```
-Most of the fields are displayed using [`JSON.stringify`](https://www.w3schools.com/js/js_json_stringify.asp).
+This is the input text field where the user can set a new greeting. Every time the user presses a key, we call `greetingChange`, which calls `setNewGreeting`. Since `setNewGreeting` comes from `useState`, it causes the `Greeter` component to be re-rendered. This means that:
+
+- We need to specify `value` to keep the value of the new greeting, because otherwise it would turn back into the default, the empty string.
+- `simulation` is also updated every time `newGreeting` changes, which means that we'll get a simulation with the correct greeting. This could be relevant because the gas cost depends on the size of the call data, which depends on the length of the string.
```tsx
-
- { funs.length > 0 &&
- <>
- Functions:
- Updated
유용한 정보
+AI 에이전트 및 관련 도구는 아직 초기 개발 단계이며 실험적인 성격이 강하므로 사용에 주의하십시오.
+`nonce``
+
+`` - _코드 스니펫을 포함하는 여는 태그_
+
+nonce - _번역 불가능한 텍스트_
+
+`` - _닫는 태그_
+
+
+
+원문 텍스트에는 숫자만 포함된 단축 태그도 포함되어 있어 해당 기능이 즉시 명확하지 않습니다. 이러한 태그 위에 마우스 커서를 올려놓으면 해당 태그가 어떤 기능을 제공하는지 정확하게 확인할 수 있습니다.
+
+아래 예시에서 `<0>` 태그에 마우스를 올리면 해당 태그가 ``를 나타내며 코드 스니펫을 포함하고 있음을 알 수 있으므로, 이 태그 내부의 내용은 번역해서는 안 됩니다.
+
+
+
+## 약어 대 전체 형식 {#short-vs-full-forms}
+
+웹사이트에는 dapps, NFT, DAO, DeFi 등 많은 약어가 사용됩니다. 이러한 약어는 일반적으로 영어로 사용되며 웹사이트 방문자 대부분이 친숙한 표현입니다.
+
+일반적으로 다른 언어로 정해진 번역이 없기 때문에, 이러한 용어와 유사한 용어에 접근하는 가장 좋은 방법은 전체 형식을 설명하는 번역을 제공하고 괄호 안에 영어 약어를 추가하는 것입니다.
+
+대부분의 사람들이 이러한 약어에 친숙하지 않을 것입니다. 그리고 지역화된 설명들은 대부분의 방문자들에게 별로 의미가 없을 것이기 때문에, 이러한 약어를 번역하지 마세요.
+
+dapps 번역 예시:
+
+- 탈중앙화 애플리케이션(dapps) → _번역된 전체 형식(괄호 안에 영어 약어)_
+
+## 정립된 번역어가 없는 용어 {#terms-without-established-translations}
+
+일부 용어는 다른 언어로 번역되지 않았을 수 있으며 원래 영어 용어로 널리 알려져 있습니다. 이러한 용어에는 proof-of-work, proof-of-stake, Beacon Chain, staking 등과 같은 새로운 개념이 대부분 포함됩니다.
+
+이러한 용어들을 번역하는 것은 부자연스럽게 들릴 수 있지만, 영어 설명은 다른 언어에서도 일반적으로 사용되기 때문에 번역하는 것을 강력하게 추천합니다.
+
+이러한 용어들을 번역할 때 자유롭게 창의력을 발휘하거나 설명적인 번역을 해보세요. 또는 단순히 직역하세요.
+
+**일부만 영어로 남기지 않고 대부분의 용어를 번역해야 하는 이유는 앞으로 이더리움과 관련 기술을 사용하는 사람들이 늘어나면서 이 새로운 용어가 더욱 널리 보급될 것이라는 사실 때문입니다. 그래서 전 세계의 더 많은 사람들이 이더리움에 합류하려면, 우리가 직접 용어를 만들 필요가 있더라도 가능한 많은 언어로 이해할 수 있는 용어로 제공해야 합니다.**
+
+## 버튼 및 CTA {#buttons-and-ctas}
+
+웹사이트에는 다른 콘텐츠와 다르게 번역되어야 하는 수많은 버튼들이 있습니다.
+
+버튼 텍스트는 대부분의 문자열과 연결된 문맥 스크린샷을 보거나 "버튼(button)" 단어가 포함된 맥락을 에디터에서 확인하여 식별할 수 있습니다.
+
+버튼의 번역은 형식 불일치를 방지하기 위해 가능한 짧아야 합니다. 또한 버튼 번역은 명령형, 즉 명령이나 요청을 나타내야 합니다.
+
+
+
+## 포용성을 위한 번역 {#translating-for-inclusivity}
+
+Ethereum.org 방문자들은 전 세계와 다른 환경에서 옵니다. 따라서 웹사이트의 언어는 중립적이어야 합니다. 그리고 모두를 환영해야 하며 배타적이지 않아야 합니다.
+
+공정성을 위한 번역의 중요한 측면은 성 중립성입니다. 이는 격식적인 표현 형식을 사용하고 번역에서 성별에 따른 단어를 지양함으로써 쉽게 달성할 수 있습니다.
+
+공정성의 또 다른 형태는 특정 국가, 인종 또는 지역이 아닌 전 세계 사용자를 대상으로 번역을 시도해보는 겁니다.
+
+마지막으로 언어는 모든 청중과 연령대에 적합해야 합니다.
+
+## 언어별 번역 {#language-specific-translations}
+
+번역할 때 원본에서 복사하는 것과는 달리 모국어에서 사용되는 문법 규칙, 관례와 형식을 따르는 것이 중요합니다. 하지만 원문 텍스트는 다른 언어에는 적용되지 않는 영어 문법 규칙 및 관례를 따릅니다.
+
+그래서 모국어에 대한 규칙을 알고 그에 알맞게 번역해야 합니다. 도움이 필요하면 저희에게 연락해 주세요. 그러면 모국어에서 이러한 요소를 어떻게 사용해야 하는지에 대한 몇 가지 자료를 찾아보실 수 있도록 도와드리겠습니다.
+
+특히 주의해야 할 몇 가지 예시:
+
+### 구두점 및 서식 {#punctuation-and-formatting}
+
+**대문자**
+
+- 다른 언어에서는 대문자 사용에 큰 차이가 있습니다.
+- 영어에서는 제목과 이름, 월과 일, 언어 이름, 공휴일 등의 모든 단어를 대문자로 시작하는 것이 일반적입니다. 다른 많은 언어에서는 대문자 사용 규칙이 다르기 때문에 문법적으로 올바르지 않습니다.
+- 어떤 언어에는 영어에서 대문자가 아닌 인칭 대명사, 명사, 특정 형용사를 대문자로 표기하는 규칙이 있습니다.
+
+**띄어쓰기**
+
+- 맞춤법 규칙은 각 언어에 대한 띄어쓰기를 정의합니다. 왜냐하면 띄어쓰기는 모든 곳에서 사용되기 때문입니다. 맞춤법 규칙은 가장 구별되는 요소 중 일부이며 띄어쓰기는 가장 잘못 번역된 요소 중 일부입니다.
+- 영어와 다른 언어 사이의 띄어쓰기의 몇 가지 일반적인 차이점:
+ - 측정 단위 및 통화 앞 띄어쓰기(예: USD, EUR, kB, MB)
+ - 온도 기호 앞 띄어쓰기(예: °C, ℉)
+ - 일부 구두점 앞 띄어쓰기, 특히 줄임표(…)
+ - 빗금(/) 앞뒤 띄어쓰기
+
+**목록**
+
+- 모든 언어에는 목록 작성에 대한 다양하고 복합한 규칙이 있습니다. 목록 작성은 영어와 상당히 다를 수 있습니다.
+- 일부 언어는 각 새 행의 첫 단어를 대문자로 써야 하는 반면, 다른 언어에서는 새 행은 소문자로 시작해야 합니다. 또한 많은 언어는 각 행의 길이에 따라 목록의 대문자에 대한 다른 규칙을 가지고 있습니다.
+- 행 항목의 구두점도 동일하게 적용됩니다. 목록의 끝 구두점은 언어에 따라 마침표(.), 쉼표(,) 또는 쌍반점(;)일 수 있습니다.
+
+**따옴표**
+
+- 언어는 다양한 따옴표를 사용합니다. 단순히 원문에서 영어 따옴표를 복사하는 것은 종종 부정확합니다.
+- 따옴표의 가장 일반적인 유형은 다음과 같습니다:
+ - „예시 텍스트“
+ - ‚예시 텍스트’
+ - »예시 텍스트«
+ - “예시 텍스트”
+ - ‘예시 텍스트’
+ - «예시 텍스트»
+
+**붙임표와 줄표**
+
+- 영어에서 붙임표(-)는 단어나 단어의 다른 부분을 연결하는 데 사용되며 줄표(–)는 범위 또는 일시 중지를 나타내는 데 사용됩니다.
+- 많은 언어에는 준수해야 하는 붙임표와 줄표 사용에 대한 다른 규칙이 있습니다.
+
+### 형식 {#formats}
+
+**숫자**
+
+- 다른 언어로 숫자를 쓸 때의 주요 차이점은 소수와 천 단위에 사용되는 구분 기호입니다. 숫자 천의 경우 마침표, 쉼표 또는 띄어쓰기가 될 수 있습니다. 유사하게 일부 언어에서는 소수점을 사용하는 반면 다른 언어에서는 소수점 쉼표를 사용합니다.
+ - 큰 숫자의 몇 가지 예시:
+ - 영어 – **1,000.50**
+ - 스페인어 – **1.000,50**
+ - 프랑스어 – **1 000,50**
+- 숫자를 번역할 때 고려해야 할 또 다른 중요한 사항은 백분율 기호입니다. **100%**, **100 %** 또는 %100과 같이 다양한 방식으로 표기할 수 있습니다.
+- 마지막으로, 음수는 언어에 따라 다르게 표시될 수 있습니다.: -100, 100-, (100) 또는 [100]
+
+**날짜**
+
+- 날짜를 번역할 때 언어에 따라 여러 고려 사항과 차이점이 있습니다. 여기에는 날짜 형식, 구분 기호, 대문자 및 숫자 앞에 0으로 채우기가 포함됩니다. 또한 전체 날짜와 숫자 날짜 사이에는 차이가 있습니다.
+ - 다른 날짜 형식의 몇 가지 예시:
+ - 영어 - 영국 (dd/mm/yyyy) – 1st January, 2022
+ - 영어 - 미국 (mm/dd/yyyy) – January 1st, 2022
+ - 중국어 (yyyy-mm-dd) – 2022 年 1 月 1 日
+ - 프랑스어 (dd/mm/yyyy) – 1er janvier 2022
+ - 이탈리아어 (dd/mm/yyyy) – 1º gennaio 2022
+ - 독일어 (dd/mm/yyyy) – 1. Januar 2022
+
+**통화**
+
+- 다른 형식, 관례 및 환율으로 인해 통화를 번역하는 것이 어려울 수 있습니다. 원칙적으로, 통화는 출처와 동일하게 유지하세요. 하지만 독자의 편의를 위해 대괄호 안에 현지 통화 및 환율을 추가할 수 있습니다.
+- 언어별로 통화를 쓸 때의 주요 차이점은 기호 배치, 소수점 기호: 쉼표 vs. 마침표, 띄어쓰기, 약어 vs. 기호가 있습니다.
+ - 기호 배치: $100 또는 100$
+ - 소수점 기호: 100,50$ 또는 100.50$
+ - 띄어쓰기: 100$ 또는 100 $
+ - 약어 vs. 기호: 100 $ 또는 100 USD
+
+**측정 단위**
+
+- 원칙적으로, 측정 단위는 출처와 동일하게 유지하세요. 국가에서 다른 시스템을 사용하는 경우 대괄호 안에 환산값을 포함할 수 있습니다.
+- 측정 단위는 현지화와는 별도로 언어가 이러한 단위에 접근하는 방식의 차이에 주목하는 것도 중요합니다. 가장 큰 차이점은 숫자와 단위 사이의 띄어쓰기이며 언어에 따라 다를 수 있습니다. 예를 들면 100kB vs. 100 kB or 50ºF vs. 50 ºF가 있습니다.
+
+## 결론 {#conclusion}
+
+Ethereum.org를 번역한다는 것은 이더리움의 다른면을 배우는데 매우 좋은 기회입니다.
+
+번역을 할 때, 성급하게 하려 하지 마세요. 편하게 즐기시면 됩니다!
+
+번역 프로그램에 참여해 주셔서 감사드리며 더 많은 대중들이 이 웹사이트를 이용할 수 있도록 도와주셔서 감사합니다. 이더리움 커뮤니티는 글로벌적이며, 저희는 번역가님이 그 중 하나의 일원이 되주셔서 기쁩니다.
diff --git a/public/content/translations/ko/dao/index.md b/public/content/translations/ko/dao/index.md
index c62a4b51b7c..0a83e9b70a4 100644
--- a/public/content/translations/ko/dao/index.md
+++ b/public/content/translations/ko/dao/index.md
@@ -1,24 +1,25 @@
---
-title: 탈중앙화 자율 조직(DAO)
-description: 이더리움의 DAO 개요
+title: "다오란 무엇인가요?"
+metaTitle: "다오란 무엇인가요? | 탈중앙화된 자율 조직"
+description: "이더리움의 DAO 개요"
lang: ko
template: use-cases
emoji: ":handshake:"
sidebarDepth: 2
image: /images/use-cases/dao-2.png
-alt: 제안에 투표하는 DAO의 표현.
-summaryPoint1: 중앙화된 리더십이 없는 회원 소유 커뮤니티.
-summaryPoint2: 인터넷에서 낯선 사람과 협업할 수 있는 안전한 방법.
-summaryPoint3: 특정 목적을 위해 자금을 넣을 수 있는 안전한 장소.
+alt: "제안에 투표하는 DAO의 표현."
+summaryPoint1: "중앙화된 리더십이 없는 회원 소유 커뮤니티."
+summaryPoint2: "인터넷에서 낯선 사람과 협업할 수 있는 안전한 방법."
+summaryPoint3: "특정 목적을 위해 자금을 넣을 수 있는 안전한 장소."
---
-## DAO란 무엇입니까? {#what-are-daos}
+## DAO란 무엇인가요? {#what-are-daos}
-DAO는 공동의 사명을 위해 일하는 집단 소유의, 블록체인 관리 조직입니다.
+DAO는 공통된 사명을 위해서 일하는 공동 소유의 조직입니다.
DAO는 자금이나 운영을 관리하는 자비로운 리더를 신뢰하지 않고도, 우리가 전 세계의 비슷한 생각을 가진 사람들과 함께 일할 수 있게 해줍니다. 변덕스럽게 자금을 쓸 수 있는 CEO나 장부를 조작할 수 있는 CFO는 없습니다. 대신, 코드에 적용된 블록체인 기반 규칙은 조직의 작동 방식과 자금 사용 방식을 정의합니다.
-DAO는 그룹의 승인 없이는 누구도 접근할 수 없는 내장된 자산을 가지고 있습니다. 결정은 조직의 모든 사람이 목소리를 낼 수 있도록 하기 위해 제안과 투표를 통해 이루어지며, 모든 것이 온체인에서 투명하게 진행됩니다.
+DAO는 그룹의 승인 없이는 누구도 접근할 수 없는 내장된 자산을 가지고 있습니다. 의사 결정은 제안과 투표에 따라 관리되어 조직의 모든 구성원이 목소리를 낼 수 있도록 보장하며, 모든 과정은 [온체인](/glossary/#onchain)에서 투명하게 진행됩니다.
## DAO가 필요한 이유는 무엇입니까? {#why-dao}
@@ -28,37 +29,35 @@ DAO는 그룹의 승인 없이는 누구도 접근할 수 없는 내장된 자
### 비교 {#dao-comparison}
-| 탈중앙화 자율 조직 | 기존의 조직 |
-| ------------------------------------------- | ------------------------------------------------- |
-| 일반적으로 수평적이고, 완전히 민주화되어 있습니다. | 일반적으로 계층적입니다. |
-| 변경 사항을 구현하려면 회원의 투표가 필요합니다. | 구조에 따라 단독 주체가 변경을 요구하거나 투표가 제안될 수 있습니다. |
-| 투표가 집계되고, 결과는 신뢰할 수 있는 중개자 없이 자동으로 구현됩니다. | 투표가 시행되는 경우, 투표는 내부적으로 집계되고 투표 결과는 수동으로 처리해야 합니다. |
+| 탈중앙화 자율 조직 | 기존의 조직 |
+| ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
+| 일반적으로 수평적이고, 완전히 민주화되어 있습니다. | 일반적으로 계층적입니다. |
+| 변경 사항을 구현하려면 회원의 투표가 필요합니다. | 구조에 따라 단독 주체가 변경을 요구하거나 투표가 제안될 수 있습니다. |
+| 투표가 집계되고, 결과는 신뢰할 수 있는 중개자 없이 자동으로 구현됩니다. | 투표가 시행되는 경우, 투표는 내부적으로 집계되고 투표 결과는 수동으로 처리해야 합니다. |
| 제공되는 서비스는 탈중앙화된 방식으로 자동 처리됩니다(예: 자선 기금 분배). | 사람이 직접 처리하거나 중앙에서 제어되는 자동화가 필요하며 조작하기 쉽습니다. |
-| 모든 활동은 투명하고 완전히 공개됩니다. | 활동은 일반적으로 비공개로 이루어지며 공개에 제한적입니다. |
+| 모든 활동은 투명하고 완전히 공개됩니다. | 활동은 일반적으로 비공개로 이루어지며 공개에 제한적입니다. |
### DAO 예시 {#dao-examples}
이해를 더 돕기 위해 다음은 DAO를 사용하는 방법에 대한 몇 가지 예시입니다.
-- 자선 활동 – 전 세계 모든 사람의 기부를 수락하고 기금의 원천에 대해 투표할 수 있습니다.
-- 집합적 소유권 – 물리적 또는 디지털 자산을 구매할 수 있으며, 회원은 사용 방법에 대해 투표할 수 있습니다.
-- 벤처 및 보조금 - 투자 자본을 모으고 벤처에 대한 투표를 지원하는 벤처 펀드를 만들 수 있습니다. 상환된 금액은 나중에 DAO 회원들에게 재분배될 수 있습니다.
+- **자선 단체** – 전 세계 누구에게나 기부를 받고 어떤 활동에 자금을 지원할지 투표할 수 있습니다.
+- **집단 소유권** – 물리적 또는 디지털 자산을 구매하고 구성원들은 그것을 어떻게 사용할 것인지에 대해 투표할 수 있습니다.
+- **벤처 및 보조금** – 투자 자금을 모아 지원할 벤처를 투표로 결정하는 벤처 펀드를 만들 수 있습니다. 상환된 금액은 나중에 DAO 회원들에게 재분배될 수 있습니다.
+
+
- 스마트 계약에 대한 자세한 정보
-
-
## 이더리움과 DAO {#ethereum-and-daos}
이더리움은 여러 가지 이유로 DAO의 완벽한 기반입니다.
-- 이더리움 자체의 합의는 조직이 네트워크를 신뢰할 수 있을 만큼 충분히 분산되어있고, 형성되어 있습니다.
+- 이더리움의 자체 합의는 탈중앙화되어 있으며, 조직들이 네트워크를 신뢰할 만큼 충분히 확립되어 있습니다.
- 스마트 계약 코드는 이더리움에서 일단 활성화되면 소유자일지라도 수정할 수 없습니다. 이는 DAO가 프로그래밍된 규칙에 따라 실행될 수 있게 합니다.
- 스마트 계약은 자금을 보내고 받을 수 있습니다. 이것이 없다면 그룹 자금을 관리하기 위해 신뢰할 수 있는 중개자가 필요합니다.
- 이더리움 커뮤니티는 경쟁보다 협력적임이 입증되었으며, 모범 사례와 지원 시스템이 빠르게 등장할 수 있게 합니다.
@@ -73,27 +72,25 @@ DAO의 중추는 조직의 규칙을 정의하고 그룹의 자금을 보유하
#### 유명한 예시 {#governance-example}
-[ENS](https://claim.ens.domains/delegate-ranking) – ENS 보유자는 그들을 대표할 참여 커뮤니티 구성원에게 투표를 위임할 수 있습니다.
-
-### 자동 거래 거버넌스 {#governance-example}
+### 자동 트랜잭션 거버넌스 {#governance-example}
많은 DAO에서는 구성원의 정족수가 찬성하면 거래가 자동으로 실행됩니다.
#### 유명한 예시 {#governance-example}
-[Noun](https://nouns.wtf) –Noun DAO에서는 설립자가 거부하지 않는 한 투표 정족수가 충족되고 과반수가 찬성하면 트랜잭션이 자동으로 실행됩니다.
+[Nouns](https://nouns.wtf) – Nouns DAO에서는 투표 정족수가 충족되고 과반수가 찬성하면, 창립자가 거부권을 행사하지 않는 한 트랜잭션이 자동으로 실행됩니다.
-### 다중서명 거버넌스 {#governance-example}
+### 다중 서명 거버넌스 {#governance-example}
-DAO에는 수천 명의 의결권을 가진 회원이 있을 수 있지만, 자금은 신뢰할 수 있고 일반적으로 공개된(커뮤니티에 알려진 공개 ID) 5~20명의 활동적인 커뮤니티 회원이 공유하는 지갑에 있을 수 있습니다. 투표이후에 다중서명자가 커뮤니티의 의지를 실행하게 됩니다.
+DAO에는 수천 명의 투표 구성원이 있을 수 있지만, 자금은 신뢰할 수 있고 일반적으로 신원이 공개된(커뮤니티에 알려진 공개 신원) 5-20명의 활성 커뮤니티 구성원이 공유하는 [지갑](/glossary/#wallet)에 보관될 수 있습니다. 투표 후, [다중 서명](/glossary/#multisig) 서명자들이 커뮤니티의 의사를 실행합니다.
-## DAO 법 {#dao-laws}
+## DAO 법률 {#dao-laws}
1977년 와이오밍 주에서 기업가를 보호하고 책임을 제한하는 유한책임회사를 고안했습니다. 더 최근에는 DAO의 법적 상태를 확립하는 DAO 법을 제정하기도 했습니다. 현재 와이오밍, 버몬트 및 버진 아일랜드에는 어떤 형태로든 DAO 법률이 존재합니다.
### 유명한 예시 {#law-example}
-[CityDAO](https://citizen.citydao.io/) - CityDAO는 와이오밍의 DAO 법을 사용하여 옐로스톤 국립공원 근처의 40에이커의 땅을 구입했습니다.
+[CityDAO](https://citizen.citydao.io/) – CityDAO는 와이오밍의 DAO 법을 이용해 옐로스톤 국립공원 근처의 토지 40에이커를 매입했습니다.
## DAO 멤버십 {#dao-membership}
@@ -101,15 +98,15 @@ DAO 멤버십에는 다양한 모델이 있습니다. 멤버십은 투표 방식
### 토큰 기반 멤버십 {#token-based-membership}
-사용되는 토큰에 따라 일반적으로 완전한 권한이 없습니다. 대부분 이러한 거버넌스 토큰은 탈중앙화 거래소에서 허가 없이 거래될 수 있습니다. 나머지는 유동성 또는 기타 '작업 증명'을 제공하여 벌어야 합니다. 어느 방식이든, 단순히 토큰을 보유하면 투표에 대한 접근 권한이 부여됩니다.
+사용되는 토큰에 따라 일반적으로 완전히 [무허가형](/glossary/#permissionless)입니다. 대부분의 경우 이러한 거버넌스 토큰은 [탈중앙화 거래소](/glossary/#dex)에서 무허가로 거래될 수 있습니다. 나머지는 유동성 또는 기타 '작업 증명'을 제공하여 벌어야 합니다. 어느 방식이든, 단순히 토큰을 보유하면 투표에 대한 접근 권한이 부여됩니다.
_일반적으로 광범위한 분산 프로토콜 및/또는 토큰 자체를 관리하는 데 사용됩니다._
#### 유명한 예시 {#token-example}
-[MakerDAO](https://makerdao.com) – MakerDAO의 토큰 MKR은 탈중앙화 거래소에서 널리 사용 가능하며, 누구나 구매하여 Maker 프로토콜의 미래에 대한 투표권을 가질 수 있습니다.
+[MakerDAO](https://makerdao.com) – MakerDAO의 토큰 MKR은 탈중앙화 거래소에서 널리 사용 가능하며, 누구나 구매를 통해 Maker 프로토콜의 미래에 대한 투표권을 가질 수 있습니다.
-### 주식 기반 멤버십 {#share-based-membership}
+### 지분 기반 멤버십 {#share-based-membership}
주식 기반 DAO는 더 많은 권한이 있지만, 여전히 열려 있습니다. DAO 가입 희망자는 누구나 DAO에 가입하기 위한 제안을 제출할 수 있으며, 보통 토큰이나 작업의 형태로 어느 정도의 가치를 제공할 수 있습니다. 주식은 직접 의결권과 소유권을 나타냅니다. 회원들은 비례적 지분을 가지고 언제든지 탈퇴할 수 있습니다.
@@ -117,49 +114,54 @@ _일반적으로 자선 단체, 근로자 집단 및 투자 클럽과 같이 보
#### 유명한 예시 {#share-example}
-[MolochDAO](http://molochdao.com/) - MolochDAO는 이더리움 프로젝트 펀딩에 중점을 두고 있습니다. 그룹에서는 잠재적 수혜자가 정보를 바탕으로 판단을 하는 데 필요한 전문 지식과 자본이 있는지 평가할 수 있도록 멤버십 제안을 요구합니다. 공개 시장에서 단순히 DAO에 대한 액세스 권한을 구매할 수는 없습니다.
+[MolochDAO](http://molochdao.com/) – MolochDAO는 이더리움 프로젝트 자금 지원에 중점을 둡니다. 그룹에서는 잠재적 수혜자가 정보를 바탕으로 판단을 하는 데 필요한 전문 지식과 자본이 있는지 평가할 수 있도록 멤버십 제안을 요구합니다. 공개 시장에서 단순히 DAO에 대한 액세스 권한을 구매할 수는 없습니다.
### 평판 기반 멤버십 {#reputation-based-membership}
-평판은 참여 사실을 나타내며 DAO에서 투표할 수 있는 권한을 제공합니다. 토큰 또는 주식 기반 멤버십과 다르게 평판 기반 DAO는 기여자에게 소유권을 이전하지 않습니다. 평판은 구매하거나 이전 또는 임의로 부여될 수 없으며 DAO 구성원이 참여를 통해 직접 획득해야 합니다. 온체인 투표에는 권한이 필요하지 않아 원하는 구성원은 자유롭게 DAO 가입 신청을 제출하고 기여에 대한 보상으로 거래소에서 평판과 토큰을 받도록 요청할 수 있습니다.
+평판은 참여 사실을 나타내며 DAO에서 투표할 수 있는 권한을 제공합니다. 토큰 또는 주식 기반 멤버십과 다르게 평판 기반 DAO는 기여자에게 소유권을 이전하지 않습니다. 평판은 구매하거나 이전 또는 임의로 부여될 수 없으며 DAO 구성원이 참여를 통해 직접 획득해야 합니다. 온체인 투표는 별도 허가 없이 진행되며, 예비 회원은 자유롭게 다오 가입과 관련된 제안을 제출할 수 있습니다. 또한, 기여에 따라 명성과 토큰을 보상으로 받을 수 있도록 요청할 수 있습니다.
-_보통은 분산형 개발 및 프로토콜, 디앱의 운영 방식에 사용되지만, 자선 단체, 노동자 집단, 투자 동아리 등의 다양한 용도의 조직에도 적합합니다._
+_일반적으로 프로토콜과 [탈중앙화앱](/glossary/#dapp)의 탈중앙화된 개발 및 거버넌스에 사용되지만, 자선 단체, 노동자 조합, 투자 클럽 등 다양한 조직에도 적합합니다._
#### 유명한 예시 {#reputation-example}
-[DXdao](https://DXdao.eth.link) – DXdao는 세계적인 주권 집합체이며 2019년부터 분산형 프로토콜 및 애플리케이션을 운영해오고 있습니다. 자금을 조정하고 관리하기 위해 평판 기반 운영 방식과 홀로그래픽 합의 메커니즘을 활용하는데, 이는 그 누구도 미래에 영향을 미칠 수 없음을 의미합니다.
+[DXdao](https://DXdao.eth.limo) – DXdao는 2019년부터 탈중앙화 프로토콜과 애플리케이션을 구축하고 관리하는 글로벌 주권 집단이었습니다. 평판 기반 거버넌스와 [홀로그래픽 합의](/glossary/#holographic-consensus)를 활용하여 자금을 조정하고 관리했으며, 이는 누구도 돈으로 미래나 거버넌스에 영향력을 행사할 수 없음을 의미합니다.
-## DAO 가입/시작 {#join-start-a-dao}
+## DAO 가입 / 시작하기 {#join-start-a-dao}
### DAO 가입하기 {#join-a-dao}
- [이더리움 커뮤니티 DAO](/community/get-involved/#decentralized-autonomous-organizations-daos)
- [DAOHaus의 DAO 목록](https://app.daohaus.club/explore)
-- [Tally.xyz DAO 명단](https://www.tally.xyz)
+- [Tally.xyz의 DAO 목록](https://www.tally.xyz/explore)
+- [DeGov.AI의 DAO 목록](https://apps.degov.ai/)
### DAO 시작하기 {#start-a-dao}
-- [DAOHaus로 DAO 호출](https://app.daohaus.club/summon)
-- [Tally로 거버너 DAO 시작하기](https://www.tally.xyz/add-a-dao)
-- [Aragon 기반 DAO 만들기](https://aragon.org/product)
+- [DAOHaus로 DAO 소환하기](https://app.daohaus.club/summon)
+- [Tally로 거버너 DAO 시작하기](https://www.tally.xyz/get-started)
+- [Aragon으로 DAO 생성하기](https://aragon.org/product)
- [콜로니 시작하기](https://colony.io/)
-- [DAOstack의 홀로그램 합의를 이용하여 DAO 만들기](https://alchemy.daostack.io/daos/create)
+- [DAOstack의 홀로그래픽 합의로 DAO 생성하기](https://alchemy.daostack.io/daos/create)
+- [DeGov Launcher로 DAO 실행하기](https://docs.degov.ai/integration/deploy)
+
+## 더 읽어보기 {#further-reading}
+
+### DAO 관련 문서 {#dao-articles}
-## 더 읽을거리 {#further-reading}
+- [DAO란 무엇인가?](https://aragon.org/dao) – [Aragon](https://aragon.org/)
+- [House of DAOs](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/)
+- [DAO란 무엇이며, 어떤 용도로 사용되는가?](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/)
+- [DAO 기반 디지털 커뮤니티 시작하는 방법](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/)
+- [DAO란 무엇인가?](https://coinmarketcap.com/alexandria/article/what-is-a-dao) – [Coinmarketcap](https://coinmarketcap.com)
+- [홀로그래픽 합의란 무엇인가?](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) - [DAOstack](https://daostack.io/)
+- [DAO는 기업이 아니다: 자율 조직에서 탈중앙화가 중요한 이유 by Vitalik](https://vitalik.eth.limo/general/2022/09/20/daos.html)
+- [DAO, DAC, DA 등: 불완전한 용어 안내서](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [이더리움 블로그](https://blog.ethereum.org)
-### DAO 기사 {#dao-articles}
+### 동영상 {#videos}
-- [DAO란?](https://aragon.org/dao) – [Aragon](https://aragon.org/)
-- [DAO 핸드북](https://daohandbook.xyz)
-- [DAO의 집](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/)
-- [DAO란 무엇이며 무엇을 위한 것일까요?](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/)
-- [DAO 기반 디지털 커뮤니티를 시작하는 방법](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/)
-- [DAO란?](https://coinmarketcap.com/alexandria/article/what-is-a-dao) – [Coinmarketcap](https://coinmarketcap.com)
-- [홀로그램 합의란 무엇인가요?](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) - [DAOstack](https://daostack.io/)
-- [DAO는 기업이 아닙니다: 비탈릭의 자율적 조직의 탈중앙화가 중요한 이유](https://vitalik.eth.limo/general/2022/09/20/daos.html)
-- [DAO, DAC, DA 그리고...: 완성되지 않은 용어 가이드](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [이더리움 블로그](https://blog.ethereum.org)
+- [암호화폐에서 DAO란 무엇인가?](https://youtu.be/KHm0uUPqmVE)
+- [DAO가 도시를 건설할 수 있을까?](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city) – [TED](https://www.ted.com/)
-### 영상 {#videos}
+
@@ -55,17 +56,17 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
여러 면에서 비트코인은 최초의 디파이 애플리케이션이었습니다. 비트코인으로 가치를 소유하고 통제하며 전 세계 어디서든 보낼 수 있습니다. 이것은 서로를 믿지 않는 많은 사람들에게 신뢰할 수 있는 중개자가 없이도 계정 장부에 합의할 수 있도록 방법을 제공하는 것으로 이뤄집니다. 비트코인은 누구에게나 열려 있으며 누구도 규칙을 변경할 권한이 없습니다. 희소성 및 개방성과 같은 비트코인의 규칙은 기술에 포함되어 있습니다. 정부가 화폐를 찍어내 개인이 저축한 돈의 가치가 낮아지고 기업이 시장을 폐쇄할 수 있는 기존 금융과는 다릅니다.
-이더리움은 이를 기반으로 합니다. 비트코인과 마찬가지로 규칙을 변경할 수 없으며 모든 사람이 액세스할 수 있습니다. 또한 [스마트 계약](/glossary/#smart-contract)을 사용하여 이 디지털 화폐를 프로그래밍할 수 있으며, 가치를 저장하고 보내는 것 이상의 작업이 가능합니다.
+이더리움은 이를 기반으로 합니다. 비트코인과 마찬가지로 규칙을 변경할 수 없으며 모든 사람이 액세스할 수 있습니다. 또한 [스마트 계약](/glossary/#smart-contract)을 사용하여 이 디지털 화폐를 프로그래밍할 수 있으므로, 가치를 저장하고 전송하는 것 이상의 작업을 할 수 있습니다.
+
이더리움이 처음이시면 디파이 애플리케이션에 대한 제안을 살펴보세요.
디파이 앱 둘러보기
@@ -78,43 +79,43 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
대부분의 금융 서비스에는 탈중앙화된 대안이 있습니다. 그러나 이더리움은 완전히 새로운 금융 상품을 만들 수 있는 기회도 제공합니다. 이 목록은 계속 늘어납니다.
- [전 세계로 송금하기](#send-money)
-- [전 세계로 돈을 스트리밍하기](#stream-money)
-- [안정적인 통화에 액세스하기](#stablecoins)
+- [전 세계로 자금 스트리밍하기](#stream-money)
+- [스테이블코인 이용하기](#stablecoins)
- [담보로 자금 대출하기](#lending)
- [무담보 대출하기](#flash-loans)
- [암호화폐 저축 시작하기](#saving)
- [토큰 거래하기](#swaps)
-- [포트폴리오 확장하기](#investing)
-- [아이디어 자금 모으기](#crowdfunding)
+- [포트폴리오 성장시키기](#investing)
+- [아이디어에 자금 지원하기](#crowdfunding)
- [보험 가입하기](#insurance)
- [포트폴리오 관리하기](#aggregators)
- 결제 디앱 보기
+ 결제 탈중앙화앱 보기
#### 전 세계로 돈을 스트리밍하세요... {#stream-money}
이더리움으로 돈을 스트리밍할 수도 있습니다. 이렇게 하면 누군가에게 초 단위로 월급을 지급하여 필요할 때마다 돈을 받을 수 있습니다. 또는 초 단위로 보관 사물함이나 전기 스쿠터를 빌릴 수 있습니다.
-이더리움의 가치 변동 때문에 [이더](/glossary/#ether)를 전송하거나 스트리밍하고 싶지 않다면, 이더리움의 대체 화폐인 [스테이블코인](/glossary/#stablecoin)을 사용해 볼 수 있습니다.
+가치 변동 때문에 [ETH](/glossary/#ether)를 전송하거나 스트리밍하고 싶지 않다면, 이더리움에 대한 대체 통화인 [스테이블코인](/glossary/#stablecoin)이 있습니다.
- 스테이블 코인에 대해 더 보기
+스테이블코인에 대한 자세한 내용
- 대출용 디앱 보기
+ 대출 탈중앙화앱 보기
탈중앙화된 대출 기관을 사용하는 것은 이점이 많습니다.
-#### 개인 정보 보호를 통한 대출 {#borrowing-privacy}
+#### 개인 정보 보호 대출 {#borrowing-privacy}
오늘날, 돈을 빌려주고 대출하는 것은 모두 관련된 개인들을 중심으로 돌아갑니다. 은행은 돈을 빌려주기 전에 당신이 대출을 상환할 수 있는지 알아야 합니다.
-탈중앙화 대출은 어느 당사자도 신원을 확인할 필요 없이 가능합니다. 대신 차주는 대출이 상환되지 않을 경우 대주에게 자동으로 지급되는 담보를 설정해야 합니다. 일부 대출 기관은 [NFT](/glossary/#nft)를 담보로 받기도 합니다. NFT는 그림과 같은 고유 자산에 대한 증서입니다. [NFT에 대해 더 보기](/nft/)
+탈중앙화 대출은 어느 당사자도 신원을 확인할 필요 없이 가능합니다. 대신 차주는 대출이 상환되지 않을 경우 대주에게 자동으로 지급되는 담보를 설정해야 합니다. 일부 대출 기관에서는 [NFT](/glossary/#nft)를 담보로 받기도 합니다. NFT는 그림과 같은 고유 자산에 대한 증서입니다. [NFT에 대해 더 알아보기](/nft/)
이를 통해 신용 확인이나 개인 정보 양도 없이 돈을 빌릴 수 있습니다.
-#### 글로벌 펀드에 대한 액세스 {#access-global-funds}
+#### 글로벌 자금 접근성 {#access-global-funds}
-탈중앙화된 대출 기관을 이용하면 선택하신 은행이나 기관에서 보관하는 자금뿐만 아니라 전 세계에 예치된 자산에 액세스할 수 있게 됩니다. 이를 통해 대출을 더 쉽게 실행하고 금리를 향상합니다.
+탈중앙화된 대출 기관을 이용하면 선택하신 은행이나 기관에서 보관하는 자금뿐만 아니라 전 세계에 예치된 자산에 액세스할 수 있게 됩니다. 이를 통해 대출 접근성이 높아지고 이자율이 개선됩니다.
-#### 조세 효율성 {#tax-efficiencies}
+#### 세금 효율성 {#tax-efficiencies}
-대출을 통해 ETH(과세 대상 이벤트)를 판매하지 않고도 필요한 자금을 이용할 수 있습니다. 대신 스테이블 코인 대출을 위한 담보로 ETH를 사용할 수 있습니다. 이렇게 하면 필요한 현금 흐름이 생기고 ETH를 유지할 수 있습니다. 스테이블 코인은 ETH처럼 가치가 변동하지 않아 현금이 필요할 때 훨씬 좋은 토큰입니다. [스테이블 코인에 대해 더 보기](#stablecoins)
+대출을 통해 ETH(과세 대상 이벤트)를 판매하지 않고도 필요한 자금을 이용할 수 있습니다. 대신 스테이블 코인 대출을 위한 담보로 ETH를 사용할 수 있습니다. 이렇게 하면 필요한 현금 흐름이 생기고 ETH를 유지할 수 있습니다. 스테이블 코인은 ETH처럼 가치가 변동하지 않아 현금이 필요할 때 훨씬 좋은 토큰입니다. [스테이블코인에 대해 더 알아보기](#stablecoins)
#### 플래시 론 {#flash-loans}
@@ -172,24 +173,24 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
전형적인 금융 세계에서 위의 예시를 가능하게 하려면 엄청난 돈이 필요합니다. 이러한 돈벌이 전략은 기존의 부를 가진 사람들만이 접근할 수 있습니다. 플래시 론은 돈을 버는 것의 전제 조건이 돈을 소유하는 것이 아니라는 미래의 예시입니다.
- 플래시 론에 대해 더 보기
+ 플래시 론에 대해 더 알아보기
- 대출 디앱 보기
+ 대출 탈중앙화앱 보기
#### 무손실 복권 {#no-loss-lotteries}
@@ -205,12 +206,12 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
상금 풀은 위의 대출 예시와 같이 티켓 예금을 대출하여 발생하는 모든 이자로 생성됩니다.
- 풀투게더 사용해보기
+ PoolTogether 사용해 보기
- 거래 디앱 보기
+ 거래 탈중앙화앱 보기
- 투자 디앱 보기
+ 투자 탈중앙화앱 보기
- 크라우드 펀딩 디앱 보기
+ 크라우드펀딩 탈중앙화앱 보기
-#### 2차 펀딩 {#quadratic-funding}
+#### 이차 펀딩 {#quadratic-funding}
이더리움은 오픈 소스 소프트웨어이며 지금까지의 많은 작업물이 커뮤니티에서 자금을 지원받았습니다. 이는 2차 펀딩이라는 흥미롭고 새로운 모금 모델의 성장으로 이어졌습니다. 2차 펀딩은 미래에 모든 공공재 유형에 자금을 지원하는 방식을 개선할 잠재력이 있습니다.
@@ -272,7 +273,7 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
이는 1달러의 기부를 100번 받은 프로젝트 A가 만 달러 기부를 한 번 받은 프로젝트 B보다 더 많은 펀딩을 받았다는 것을 의미합니다(매칭 풀의 크기에 따라 다름).
- 2차 펀딩에 대해 더 보기
+ 이차 펀딩에 대해 더 알아보기
- 보험 디앱 보기
+ 보험 탈중앙화앱 보기
- 포트폴리오 디앱 보기
+ 포트폴리오 탈중앙화앱 보기
- 디앱 구축에 대해 더 보기
+ 탈중앙화앱 구축에 대해 더 알아보기
-## 부록 {#further-reading}
+## 더 읽어보기 {#further-reading}
### 디파이 데이터 {#defi-data}
-- [디파이 프라임](https://defiprime.com/)
-- [디파이 라마](https://defillama.com/)
+- [DeFi Prime](https://defiprime.com/)
+- [DeFi Llama](https://defillama.com/)
-### 디파이 기사 {#defi-articles}
+### 디파이 관련 기사 {#defi-articles}
-- [디파이 초보자 가이드](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _시드 코엘로-프라부, 2020년 1월 6일_
+- [디파이 초보자 가이드](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu, 2020년 1월 6일_
+- [EEA 디파이 위험 평가 가이드라인](https://entethalliance.org/specs/defi-risks/) – 디파이 프로토콜의 주요 위험을 식별하고 평가하는 방법에 대한 업계 지원 개요입니다.
-### 영상 {#videos}
+### 동영상 {#videos}
-- [Finematics - 탈중앙화 금융 교육](https://finematics.com/) – _디파이에 대한 영상_
-- [디파이언트](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _디파이 기초: 가끔은 혼란스러운 이곳에서 시작하려면 알아야 할 모든 것._
-- [화이트보드 크립토](https://youtu.be/17QRFlml4pA) _디파이란 무엇인가요?_
+- [Finematics - 탈중앙화 금융 교육](https://finematics.com/) – _DeFi에 관한 영상_
+- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _디파이 기초: 가끔은 난해한 이 분야를 시작하기 위해 알아야 할 모든 것._
+- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _디파이란 무엇인가?_
### 커뮤니티 {#communities}
-- [디파이 라마 디스코드 서버](https://discord.defillama.com/)
-- [디파이 펄스 디스코드 서버](https://discord.gg/Gx4TCTk)
+- [DeFi Llama 디스코드 서버](https://discord.defillama.com/)
+- [DeFi Pulse 디스코드 서버](https://discord.gg/Gx4TCTk)
+
+
+
+생성할 새 계정의 암호를 입력하세요:
+>
+
+------------
+INFO [10-28|16:19:09.156] 새 키가 생성되었습니다 address=0x5e97870f263700f46aa00d967821199b9bc5a120
+WARN [10-28|16:19:09.306] 키 파일을 백업하세요 path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120
+WARN [10-28|16:19:09.306] 암호를 꼭 기억하세요!
+생성된 계정 0x5e97870f263700f46aa00d967821199b9bc5a120
+```
+
+[Geth 문서](https://geth.ethereum.org/docs)
+
+개인 키로부터 새 공개 키를 파생하는 것은 가능하지만, 공개 키로부터 개인 키를 파생할 수는 없습니다. 개인 키를 안전하게 보관하고 이름 그대로 비공개(PRIVATE)로 유지하는 것이 중요합니다.
+
+여러분은 메세지와 트랜잭션을 서명해서 서명을 만들기 위해서 개인 키가 필요합니다. 그러면 다른이들은 여러분의 공개 키를 도출해서 그 메시지의 작성자를 증명하기 위해서 그 서명을 획득 할 수 있습니다. 애플리케이션에서 JavaScript 라이브러리를 사용하여 네트워크에 트랜잭션을 전송할 수 있습니다.
+
+## 컨트랙트 계정 {#contract-accounts}
+
+컨트랙트 계정 또한 42개 문자로 이루어진 16진수 주소를 갖습니다.
+
+예시:
+
+`0x06012c8cf97bead5deae237070f9587f8e7a266d`
+
+컨트랙트 주소는 대개 컨트랙트가 이더리움 블록체인에 배포되는 시점에 주어집니다. 이 주소는 그 생성자의 주소와 그 주소로부터 전송된 트랜잭션 번호("논스") 에서 추출됩니다.
+
+## 검증자 키 {#validators-keys}
+
+이더리움이 작업 증명에서 합의에 기반한 지분증명으로 바뀌면서 다른 타입의 키가 만들어집니다. 일명 BLS라는 키로, 이 키는 누가 검증자인지 구별하는데 쓰입니다. 이러한 키를 효율적으로 집계하여 네트워크가 합의에 도달하는 데 필요한 대역폭을 줄일 수 있습니다. 이 키 집계가 없으면 검증자의 최소 지분은 훨씬 더 높아질 것입니다.
+
+[검증자 키에 대해 더 알아보기](/developers/docs/consensus-mechanisms/pos/keys/).
+
+## 지갑에 대한 참고 사항 {#a-note-on-wallets}
+
+계정은 지갑이 아닙니다. 지갑은 외부 소유 계정 또는 계약 계정과 상호작용할 수 있게 해주는 인터페이스 또는 애플리케이션입니다.
+
+## 시각적 데모 {#a-visual-demo}
+
+오스틴이 해시 함수와 키 쌍에 대해 설명하는 것을 보세요.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+정확한 반환 데이터는 클라이언트 구현에 따라 다릅니다. 모든 클라이언트는 노드가 동기화되지 않을 때 `False`를 반환하고, 모든 클라이언트는 다음 필드를 반환합니다.
+
+`객체|부울`, 동기화 상태 데이터가 있는 객체 또는 동기화되지 않을 때 `FALSE`:
+
+- `startingBlock`: `QUANTITY` - 가져오기가 시작된 블록(동기화가 헤드에 도달한 후에만 재설정됨)
+- `currentBlock`: `QUANTITY` - 현재 블록, eth_blockNumber와 동일
+- `highestBlock`: `QUANTITY` - 추정된 가장 높은 블록
+
+그러나 개별 클라이언트는 추가 데이터를 제공할 수도 있습니다. 예를 들어 Geth는 다음을 반환합니다:
+
+```json
+{
+ "jsonrpc": "2.0",
+ "id": 1,
+ "result": {
+ "currentBlock": "0x3cf522",
+ "healedBytecodeBytes": "0x0",
+ "healedBytecodes": "0x0",
+ "healedTrienodes": "0x0",
+ "healingBytecode": "0x0",
+ "healingTrienodes": "0x0",
+ "highestBlock": "0x3e0e41",
+ "startingBlock": "0x3cbed5",
+ "syncedAccountBytes": "0x0",
+ "syncedAccounts": "0x0",
+ "syncedBytecodeBytes": "0x0",
+ "syncedBytecodes": "0x0",
+ "syncedStorage": "0x0",
+ "syncedStorageBytes": "0x0"
+ }
+}
+```
+
+반면에 Besu는 다음을 반환합니다:
+
+```json
+{
+ "jsonrpc": "2.0",
+ "id": 51,
+ "result": {
+ "startingBlock": "0x0",
+ "currentBlock": "0x1518",
+ "highestBlock": "0x9567a3",
+ "pulledStates": "0x203ca",
+ "knownStates": "0x200636"
+ }
+}
+```
+
+자세한 내용은 특정 클라이언트의 설명서를 참조하세요.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": {
+ startingBlock: '0x384',
+ currentBlock: '0x386',
+ highestBlock: '0x454'
+ }
+}
+// 또는 동기화되지 않을 때
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": false
+}
+```
+
+### eth_coinbase {#eth_coinbase}
+
+클라이언트 코인베이스 주소를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+> **참고:** 이 메서드는 v1.14.0부터 더 이상 사용되지 않으며 지원되지 않습니다. 이 메서드를 사용하려고 하면 "메서드가 지원되지 않음" 오류가 발생합니다.
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+`DATA`, 20바이트 - 현재 코인베이스 주소.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":64}'
+// 결과
+{
+ "id":64,
+ "jsonrpc": "2.0",
+ "result": "0x407d73d8a49eeb85d32cf465507dd71d507100c1"
+}
+```
+
+### eth_chainId {#eth_chainId}
+
+재생 보호 트랜잭션 서명에 사용되는 체인 ID를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+`chainId`, 현재 체인 ID의 정수를 나타내는 문자열로서의 16진수 값.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}'
+// 결과
+{
+ "id":67,
+ "jsonrpc": "2.0",
+ "result": "0x1"
+}
+```
+
+### eth_mining {#eth_mining}
+
+클라이언트가 새 블록을 활발하게 채굴하는 경우 `true`를 반환합니다. 이것은 작업 증명 네트워크에 대해서만 `true`를 반환할 수 있으며 [병합](/roadmap/merge/) 이후 일부 클라이언트에서는 사용할 수 없을 수도 있습니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+`부울` - 클라이언트가 채굴 중이면 `true`, 그렇지 않으면 `false`를 반환합니다.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}'
+//
+{
+ "id":71,
+ "jsonrpc": "2.0",
+ "result": true
+}
+```
+
+### eth_hashrate {#eth_hashrate}
+
+노드가 채굴 중인 초당 해시 수를 반환합니다. 이것은 작업 증명 네트워크에 대해서만 `true`를 반환할 수 있으며 [병합](/roadmap/merge/) 이후 일부 클라이언트에서는 사용할 수 없을 수도 있습니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+`QUANTITY` - 초당 해시 수.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":71}'
+// 결과
+{
+ "id":71,
+ "jsonrpc": "2.0",
+ "result": "0x38a"
+}
+```
+
+### eth_gasPrice {#eth_gasprice}
+
+웨이 단위의 가스당 현재 가격 추정치를 반환합니다. 예를 들어, Besu 클라이언트는 마지막 100개 블록을 검사하고 기본적으로 중간 가스 단가를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+`QUANTITY` - 웨이 단위의 현재 가스 가격의 정수.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}'
+// 결과
+{
+ "id":73,
+ "jsonrpc": "2.0",
+ "result": "0x1dfd14000" // 8049999872 웨이
+}
+```
+
+### eth_accounts {#eth_accounts}
+
+클라이언트가 소유한 주소 목록을 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+`DATA 배열`, 20바이트 - 클라이언트가 소유한 주소.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": ["0x407d73d8a49eeb85d32cf465507dd71d507100c1"]
+}
+```
+
+### eth_blockNumber {#eth_blocknumber}
+
+가장 최신 블록의 번호를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+`QUANTITY` - 클라이언트가 있는 현재 블록 번호의 정수.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}'
+// 결과
+{
+ "id":83,
+ "jsonrpc": "2.0",
+ "result": "0x4b7" // 1207
+}
+```
+
+### eth_getBalance {#eth_getbalance}
+
+지정된 주소에 있는 계정의 잔액을 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `DATA`, 20바이트 - 잔액을 확인할 주소.
+2. `QUANTITY|TAG` - 정수 블록 번호 또는 문자열 `"latest"`, `"earliest"`, `"pending"`, `"safe"` 또는 `"finalized"`, [블록 매개변수](/developers/docs/apis/json-rpc/#block-parameter) 참조
+
+```js
+params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
+```
+
+**반환 값**
+
+`QUANTITY` - 웨이 단위의 현재 잔액의 정수.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x0234c8a3397aab58" // 158972490234375000
+}
+```
+
+### eth_getStorageAt {#eth_getstorageat}
+
+지정된 주소의 스토리지 위치에서 값을 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `DATA`, 20바이트 - 스토리지 주소.
+2. `QUANTITY` - 스토리지 내 위치의 정수.
+3. `QUANTITY|TAG` - 정수 블록 번호 또는 문자열 `"latest"`, `"earliest"`, `"pending"`, `"safe"`, `"finalized"`, [블록 매개변수](/developers/docs/apis/json-rpc/#block-parameter) 참조
+
+**반환 값**
+
+`DATA` - 이 스토리지 위치의 값.
+
+**예제**
+올바른 위치 계산은 검색할 스토리지에 따라 다릅니다. 주소 `0x391694e7e0b0cce554cb130d723a9d27458f9298`에 의해 `0x295a70b2de5e3953354a6a8344e616ed314d7251`에 배포된 다음 계약을 고려해 보세요.
+
+```
+contract Storage {
+ uint pos0;
+ mapping(address => uint) pos1;
+ constructor() {
+ pos0 = 1234;
+ pos1[msg.sender] = 5678;
+ }
+}
+```
+
+pos0의 값을 검색하는 것은 간단합니다.
+
+```js
+curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
+{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"}
+```
+
+맵의 요소를 검색하는 것은 더 어렵습니다. 맵에 있는 요소의 위치는 다음과 같이 계산됩니다:
+
+```js
+keccak(LeftPad32(key, 0), LeftPad32(map position, 0))
+```
+
+즉, pos1["0x391694e7e0b0cce554cb130d723a9d27458f9298"]의 스토리지를 검색하려면 다음을 사용하여 위치를 계산해야 합니다:
+
+```js
+keccak(
+ decodeHex(
+ "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" +
+ "0000000000000000000000000000000000000000000000000000000000000001"
+ )
+)
+```
+
+web3 라이브러리와 함께 제공되는 geth 콘솔을 사용하여 계산할 수 있습니다:
+
+```js
+> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"
+undefined
+> web3.sha3(key, {"encoding": "hex"})
+"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"
+```
+
+이제 스토리지를 가져옵니다:
+
+```js
+curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545
+{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"}
+```
+
+### eth_getTransactionCount {#eth_gettransactioncount}
+
+주소에서 _보낸_ 트랜잭션 수를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `DATA`, 20바이트 - 주소.
+2. `QUANTITY|TAG` - 정수 블록 번호 또는 문자열 `"latest"`, `"earliest"`, `"pending"`, `"safe"` 또는 `"finalized"`, [블록 매개변수](/developers/docs/apis/json-rpc/#block-parameter) 참조
+
+```js
+params: [
+ "0x407d73d8a49eeb85d32cf465507dd71d507100c1",
+ "latest", // 최신 블록의 상태
+]
+```
+
+**반환 값**
+
+`QUANTITY` - 이 주소에서 보낸 트랜잭션 수의 정수입니다.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1","latest"],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_getBlockTransactionCountByHash {#eth_getblocktransactioncountbyhash}
+
+주어진 블록 해시와 일치하는 블록의 트랜잭션 수를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `DATA`, 32바이트 - 블록의 해시
+
+```js
+params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"]
+```
+
+**반환 값**
+
+`QUANTITY` - 이 블록의 트랜잭션 수의 정수.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHash","params":["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x8b" // 139
+}
+```
+
+### eth_getBlockTransactionCountByNumber {#eth_getblocktransactioncountbynumber}
+
+주어진 블록 번호와 일치하는 블록의 트랜잭션 수를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `QUANTITY|TAG` - 블록 번호의 정수, 또는 문자열 `"earliest"`, `"latest"`, `"pending"`, `"safe"` 또는 `"finalized"`, [블록 매개변수](/developers/docs/apis/json-rpc/#block-parameter)에서와 같이.
+
+```js
+params: [
+ "0x13738ca", // 20396234
+]
+```
+
+**반환 값**
+
+`QUANTITY` - 이 블록의 트랜잭션 수의 정수.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNumber","params":["0x13738ca"],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x8b" // 139
+}
+```
+
+### eth_getUncleCountByBlockHash {#eth_getunclecountbyblockhash}
+
+주어진 블록 해시와 일치하는 블록의 엉클 수를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `DATA`, 32바이트 - 블록의 해시
+
+```js
+params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"]
+```
+
+**반환 값**
+
+`QUANTITY` - 이 블록의 엉클 수의 정수.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_getUncleCountByBlockNumber {#eth_getunclecountbyblocknumber}
+
+주어진 블록 번호와 일치하는 블록의 엉클 수를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `QUANTITY|TAG` - 정수 블록 번호, 또는 문자열 `"latest"`, `"earliest"`, `"pending"`, `"safe"` 또는 `"finalized"`, [블록 매개변수](/developers/docs/apis/json-rpc/#block-parameter) 참조
+
+```js
+params: [
+ "0xe8", // 232
+]
+```
+
+**반환 값**
+
+`QUANTITY` - 이 블록의 엉클 수의 정수.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber","params":["0xe8"],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x0" // 0
+}
+```
+
+### eth_getCode {#eth_getcode}
+
+지정된 주소의 코드를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `DATA`, 20바이트 - 주소
+2. `QUANTITY|TAG` - 정수 블록 번호 또는 문자열 `"latest"`, `"earliest"`, `"pending"`, `"safe"` 또는 `"finalized"`, [블록 매개변수](/developers/docs/apis/json-rpc/#block-parameter) 참조
+
+```js
+params: [
+ "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
+ "0x5daf3b", // 6139707
+]
+```
+
+**반환 값**
+
+`DATA` - 지정된 주소의 코드.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "0x5daf3b"],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x6060604052600436106100af576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146100b9578063095ea7b31461014757806318160ddd146101a157806323b872dd146101ca5780632e1a7d4d14610243578063313ce5671461026657806370a082311461029557806395d89b41146102e2578063a9059cbb14610370578063d0e30db0146103ca578063dd62ed3e146103d4575b6100b7610440565b005b34156100c457600080fd5b6100cc6104dd565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561010c5780820151818401526020810190506100f1565b50505050905090810190601f1680156101395780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561015257600080fd5b610187600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061057b565b604051808215151515815260200191505060405180910390f35b34156101ac57600080fd5b6101b461066d565b6040518082815260200191505060405180910390f35b34156101d557600080fd5b610229600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061068c565b604051808215151515815260200191505060405180910390f35b341561024e57600080fd5b61026460048080359060200190919050506109d9565b005b341561027157600080fd5b610279610b05565b604051808260ff1660ff16815260200191505060405180910390f35b34156102a057600080fd5b6102cc600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610b18565b6040518082815260200191505060405180910390f35b34156102ed57600080fd5b6102f5610b30565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561033557808201518184015260208101905061031a565b50505050905090810190601f1680156103625780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561037b57600080fd5b6103b0600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091908035906020019091905050610bce565b604051808215151515815260200191505060405180910390f35b6103d2610440565b005b34156103df57600080fd5b61042a600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610be3565b6040518082815260200191505060405180910390f35b34600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055503373ffffffffffffffffffffffffffffffffffffffff167fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c346040518082815260200191505060405180910390a2565b60008054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156105735780601f1061054857610100808354040283529160200191610573565b820191906000526020600020905b81548152906001019060200180831161055657829003601f168201915b505050505081565b600081600460003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b60003073ffffffffffffffffffffffffffffffffffffffff1631905090565b600081600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054101515156106dc57600080fd5b3373ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff16141580156107b457507fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205414155b156108cf5781600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541015151561084457600080fd5b81600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055505b81600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000206000828254039250508190555081600360008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205410151515610a2757600080fd5b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055503373ffffffffffffffffffffffffffffffffffffffff166108fc829081150290604051600060405180830381858888f193505050501515610ab457600080fd5b3373ffffffffffffffffffffffffffffffffffffffff167f7fcf532c15f0a6db0bd6d0e038bea71d30d808c7d98cb3bf7268a95bf5081b65826040518082815260200191505060405180910390a250565b600260009054906101000a900460ff1681565b60036020528060005260406000206000915090505481565b60018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610bc65780601f10610b9b57610100808354040283529160200191610bc6565b820191906000526020600020905b815481529060010190602001808311610ba957829003601f168201915b505050505081565b6000610bdb33848461068c565b905092915050565b60046020528160005260406000206020528060005260406000206000915091505054815600a165627a7a72305820deb4c2ccab3c2fdca32ab3f46728389c2fe2c165d5fafa07661e4e004f6c344a0029"
+}
+```
+
+### eth_sign {#eth_sign}
+
+sign 메서드는 `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`로 이더리움 특정 서명을 계산합니다.
+
+메시지에 접두사를 추가하면 계산된 서명을 이더리움 특정 서명으로 인식할 수 있습니다. 이를 통해 악의적인 탈중앙화앱이 임의의 데이터(예: 트랜잭션)에 서명하고 서명을 사용하여 피해자를 사칭하는 오용을 방지할 수 있습니다.
+
+참고: 서명할 주소는 잠금 해제되어야 합니다.
+
+**매개변수**
+
+1. `DATA`, 20바이트 - 주소
+2. `DATA`, N 바이트 - 서명할 메시지
+
+**반환 값**
+
+`DATA`: 서명
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
+}
+```
+
+### eth_signTransaction {#eth_signtransaction}
+
+[eth_sendRawTransaction](#eth_sendrawtransaction)을 사용하여 나중에 네트워크에 제출할 수 있는 트랜잭션에 서명합니다.
+
+**매개변수**
+
+1. `객체` - 트랜잭션 객체
+
+- `type`:
+- `from`: `DATA`, 20바이트 - 트랜잭션이 전송된 주소.
+- `to`: `DATA`, 20바이트 - (새 계약 생성 시 선택 사항) 트랜잭션이 보내지는 주소.
+- `gas`: `QUANTITY` - (선택 사항, 기본값: 90000) 트랜잭션 실행을 위해 제공된 가스의 정수. 사용하지 않은 가스를 반환합니다.
+- `gasPrice`: `QUANTITY` - (선택 사항, 기본값: 추후 결정) 지불된 각 가스에 사용되는 가스 가격의 정수(웨이 단위).
+- `value`: `QUANTITY` - (선택 사항) 이 트랜잭션과 함께 전송된 값의 정수(웨이 단위).
+- `data`: `DATA` - 계약의 컴파일된 코드 또는 호출된 메서드 서명의 해시 및 인코딩된 매개변수.
+- `nonce`: `QUANTITY` - (선택 사항) 논스의 정수. 이를 통해 동일한 논스를 사용하는 자신의 보류 중인 트랜잭션을 덮어쓸 수 있습니다.
+
+**반환 값**
+
+`DATA`, 지정된 계정으로 서명된 RLP 인코딩 트랜잭션 객체.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","params": [{"data":"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675","from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155","gas": "0x76c0","gasPrice": "0x9184e72a000","to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567","value": "0x9184e72a"}]}'
+// 결과
+{
+ "id": 1,
+ "jsonrpc": "2.0",
+ "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
+}
+```
+
+### eth_sendTransaction {#eth_sendtransaction}
+
+데이터 필드에 코드가 포함된 경우 새 메시지 호출 트랜잭션 또는 계약 생성을 만들고 `from`에 지정된 계정을 사용하여 서명합니다.
+
+**매개변수**
+
+1. `객체` - 트랜잭션 객체
+
+- `from`: `DATA`, 20바이트 - 트랜잭션이 전송된 주소.
+- `to`: `DATA`, 20바이트 - (새 계약 생성 시 선택 사항) 트랜잭션이 보내지는 주소.
+- `gas`: `QUANTITY` - (선택 사항, 기본값: 90000) 트랜잭션 실행을 위해 제공된 가스의 정수. 사용하지 않은 가스를 반환합니다.
+- `gasPrice`: `QUANTITY` - (선택 사항, 기본값: 추후 결정) 지불된 각 가스에 사용되는 가스 가격의 정수.
+- `value`: `QUANTITY` - (선택 사항) 이 트랜잭션과 함께 전송된 값의 정수.
+- `input`: `DATA` - 계약의 컴파일된 코드 또는 호출된 메서드 서명의 해시 및 인코딩된 매개변수.
+- `nonce`: `QUANTITY` - (선택 사항) 논스의 정수. 이를 통해 동일한 논스를 사용하는 자신의 보류 중인 트랜잭션을 덮어쓸 수 있습니다.
+
+```js
+params: [
+ {
+ from: "0xb60e8dd61c5d32be8058bb8eb970870f07233155",
+ to: "0xd46e8dd67c5d32be8058bb8eb970870f07244567",
+ gas: "0x76c0", // 30400
+ gasPrice: "0x9184e72a000", // 10000000000000
+ value: "0x9184e72a", // 2441406250
+ input:
+ "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675",
+ },
+]
+```
+
+**반환 값**
+
+`DATA`, 32바이트 - 트랜잭션 해시, 또는 트랜잭션을 아직 사용할 수 없는 경우 0 해시.
+
+계약을 생성했을 때 트랜잭션이 블록에 제안된 후 [eth_getTransactionReceipt](#eth_gettransactionreceipt)를 사용하여 계약 주소를 가져옵니다.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{위 참조}],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
+}
+```
+
+### eth_sendRawTransaction {#eth_sendrawtransaction}
+
+서명된 트랜잭션에 대한 새 메시지 호출 트랜잭션 또는 계약 생성을 만듭니다.
+
+**매개변수**
+
+1. `DATA`, 서명된 트랜잭션 데이터.
+
+```js
+params: [
+ "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675",
+]
+```
+
+**반환 값**
+
+`DATA`, 32바이트 - 트랜잭션 해시, 또는 트랜잭션을 아직 사용할 수 없는 경우 0 해시.
+
+계약을 생성했을 때 트랜잭션이 블록에 제안된 후 [eth_getTransactionReceipt](#eth_gettransactionreceipt)를 사용하여 계약 주소를 가져옵니다.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":[{위 참조}],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
+}
+```
+
+### eth_call {#eth_call}
+
+블록체인에 트랜잭션을 생성하지 않고 즉시 새 메시지 호출을 실행합니다. ERC-20 계약의 `balanceOf`와 같이 읽기 전용 스마트 계약 함수를 실행하는 데 자주 사용됩니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `객체` - 트랜잭션 호출 객체
+
+- `from`: `DATA`, 20바이트 - (선택 사항) 트랜잭션이 전송된 주소.
+- `to`: `DATA`, 20바이트 - 트랜잭션이 보내지는 주소.
+- `gas`: `QUANTITY` - (선택 사항) 트랜잭션 실행을 위해 제공된 가스의 정수. eth_call은 가스를 소비하지 않지만 일부 실행에서는 이 매개변수가 필요할 수 있습니다.
+- `gasPrice`: `QUANTITY` - (선택 사항) 지불된 각 가스에 사용되는 가스 가격의 정수
+- `value`: `QUANTITY` - (선택 사항) 이 트랜잭션과 함께 전송된 값의 정수
+- `input`: `DATA` - (선택 사항) 메서드 서명의 해시 및 인코딩된 매개변수. 자세한 내용은 [솔리디티 문서의 이더리움 계약 ABI](https://docs.soliditylang.org/en/latest/abi-spec.html)를 참조하세요.
+
+2. `QUANTITY|TAG` - 정수 블록 번호 또는 문자열 `"latest"`, `"earliest"`, `"pending"`, `"safe"` 또는 `"finalized"`, [블록 매개변수](/developers/docs/apis/json-rpc/#block-parameter) 참조
+
+**반환 값**
+
+`DATA` - 실행된 계약의 반환 값.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{위 참조}],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x"
+}
+```
+
+### eth_estimateGas {#eth_estimategas}
+
+트랜잭션이 완료되는 데 필요한 가스 양에 대한 추정치를 생성하고 반환합니다. 트랜잭션은 블록체인에 추가되지 않습니다. EVM 메커니즘 및 노드 성능을 포함한 다양한 이유로 인해 추정치가 트랜잭션에서 실제로 사용된 가스 양보다 훨씬 많을 수 있다는 점에 유의하세요.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+모든 속성이 선택 사항이라는 점을 제외하고 [eth_call](#eth_call) 매개변수를 참조하세요. 가스 한도가 지정되지 않은 경우 geth는 보류 중인 블록의 블록 가스 한도를 상한으로 사용합니다. 결과적으로 가스 양이 보류 중인 블록 가스 한도보다 높을 경우 반환된 추정치가 호출/트랜잭션을 실행하기에 충분하지 않을 수 있습니다.
+
+**반환 값**
+
+`QUANTITY` - 사용된 가스의 양.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{위 참조}],"id":1}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x5208" // 21000
+}
+```
+
+### eth_getBlockByHash {#eth_getblockbyhash}
+
+해시로 블록에 대한 정보를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `DATA`, 32바이트 - 블록의 해시.
+2. `부울` - `true`이면 전체 트랜잭션 객체를 반환하고, `false`이면 트랜잭션의 해시만 반환합니다.
+
+```js
+params: [
+ "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae",
+ false,
+]
+```
+
+**반환 값**
+
+`객체` - 블록 객체, 또는 블록을 찾을 수 없는 경우 `null`:
+
+- `number`: `QUANTITY` - 블록 번호. 보류 중인 블록인 경우 `null`.
+- `hash`: `DATA`, 32바이트 - 블록의 해시. 보류 중인 블록인 경우 `null`.
+- `parentHash`: `DATA`, 32바이트 - 부모 블록의 해시.
+- `nonce`: `DATA`, 8바이트 - 생성된 작업 증명의 해시. 보류 중인 블록인 경우 `null`, 지분 증명 블록의 경우 `0x0`(병합 이후)
+- `sha3Uncles`: `DATA`, 32바이트 - 블록에 있는 엉클 데이터의 SHA3.
+- `logsBloom`: `DATA`, 256바이트 - 블록의 로그에 대한 블룸 필터. 보류 중인 블록인 경우 `null`.
+- `transactionsRoot`: `DATA`, 32바이트 - 블록의 트랜잭션 트리의 루트.
+- `stateRoot`: `DATA`, 32바이트 - 블록의 최종 상태 트리의 루트.
+- `receiptsRoot`: `DATA`, 32바이트 - 블록의 영수증 트리의 루트.
+- `miner`: `DATA`, 20바이트 - 블록 보상을 받은 수혜자의 주소.
+- `difficulty`: `QUANTITY` - 이 블록의 난이도 정수.
+- `totalDifficulty`: `QUANTITY` - 이 블록까지의 체인 총 난이도 정수.
+- `extraData`: `DATA` - 이 블록의 "추가 데이터" 필드.
+- `size`: `QUANTITY` - 이 블록의 크기(바이트) 정수.
+- `gasLimit`: `QUANTITY` - 이 블록에서 허용되는 최대 가스.
+- `gasUsed`: `QUANTITY` - 이 블록의 모든 트랜잭션에서 사용된 총 가스.
+- `timestamp`: `QUANTITY` - 블록이 수집된 유닉스 타임스탬프.
+- `transactions`: `배열` - 트랜잭션 객체의 배열, 또는 마지막으로 주어진 매개변수에 따라 32바이트 트랜잭션 해시.
+- `uncles`: `배열` - 엉클 해시의 배열.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}'
+// 결과
+{
+ "jsonrpc": "2.0",
+ "id": 1,
+ "result": {
+ "difficulty": "0x4ea3f27bc",
+ "extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32",
+ "gasLimit": "0x1388",
+ "gasUsed": "0x0",
+ "hash": "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae",
+ "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
+ "miner": "0xbb7b8287f3f0a933474a79eae42cbca977791171",
+ "mixHash": "0x4fffe9ae21f1c9e15207b1f472d5bbdd68c9595d461666602f2be20daf5e7843",
+ "nonce": "0x689056015818adbe",
+ "number": "0x1b4",
+ "parentHash": "0xe99e022112df268087ea7eafaf4790497fd21dbeeb6bd7a1721df161a6657a54",
+ "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
+ "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
+ "size": "0x220",
+ "stateRoot": "0xddc8b0234c2e0cad087c8b389aa7ef01f7d79b2570bccb77ce48648aa61c904d",
+ "timestamp": "0x55ba467c",
+ "totalDifficulty": "0x78ed983323d",
+ "transactions": [
+ ],
+ "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
+ "uncles": [
+ ]
+ }
+}
+```
+
+### eth_getBlockByNumber {#eth_getblockbynumber}
+
+블록 번호로 블록에 대한 정보를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `QUANTITY|TAG` - 블록 번호의 정수, 또는 문자열 `"earliest"`, `"latest"`, `"pending"`, `"safe"` 또는 `"finalized"`, [블록 매개변수](/developers/docs/apis/json-rpc/#block-parameter)에서와 같이.
+2. `부울` - `true`이면 전체 트랜잭션 객체를 반환하고, `false`이면 트랜잭션의 해시만 반환합니다.
+
+```js
+params: [
+ "0x1b4", // 436
+ true,
+]
+```
+
+**반환 값**
+[eth_getBlockByHash](#eth_getblockbyhash)를 참조하세요
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}'
+```
+
+결과는 [eth_getBlockByHash](#eth_getblockbyhash)를 참조하세요
+
+### eth_getTransactionByHash {#eth_gettransactionbyhash}
+
+트랜잭션 해시로 요청된 트랜잭션에 대한 정보를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `DATA`, 32바이트 - 트랜잭션의 해시
+
+```js
+params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"]
+```
+
+**반환 값**
+
+`객체` - 트랜잭션 객체, 또는 트랜잭션을 찾을 수 없는 경우 `null`:
+
+- `blockHash`: `DATA`, 32바이트 - 이 트랜잭션이 포함된 블록의 해시. 보류 중일 때 `null`.
+- `blockNumber`: `QUANTITY` - 이 트랜잭션이 포함된 블록 번호. 보류 중일 때 `null`.
+- `from`: `DATA`, 20바이트 - 발신자의 주소.
+- `gas`: `QUANTITY` - 발신자가 제공한 가스.
+- `gasPrice`: `QUANTITY` - 발신자가 웨이 단위로 제공한 가스 가격.
+- `hash`: `DATA`, 32바이트 - 트랜잭션의 해시.
+- `input`: `DATA` - 트랜잭션과 함께 전송된 데이터.
+- `nonce`: `QUANTITY` - 이 트랜잭션 이전에 발신자가 수행한 트랜잭션 수.
+- `to`: `DATA`, 20바이트 - 수신자의 주소. 계약 생성 트랜잭션인 경우 `null`.
+- `transactionIndex`: `QUANTITY` - 블록 내 트랜잭션 인덱스 위치의 정수. 보류 중일 때 `null`.
+- `value`: `QUANTITY` - 웨이 단위로 전송된 값.
+- `v`: `QUANTITY` - ECDSA 복구 ID
+- `r`: `QUANTITY` - ECDSA 서명 r
+- `s`: `QUANTITY` - ECDSA 서명 s
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}'
+// 결과
+{
+ "jsonrpc":"2.0",
+ "id":1,
+ "result":{
+ "blockHash":"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
+ "blockNumber":"0x5daf3b", // 6139707
+ "from":"0xa7d9ddbe1f17865597fbd27ec712455208b6b76d",
+ "gas":"0xc350", // 50000
+ "gasPrice":"0x4a817c800", // 20000000000
+ "hash":"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b",
+ "input":"0x68656c6c6f21",
+ "nonce":"0x15", // 21
+ "to":"0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb",
+ "transactionIndex":"0x41", // 65
+ "value":"0xf3dbb76162000", // 4290000000000000
+ "v":"0x25", // 37
+ "r":"0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea",
+ "s":"0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c"
+ }
+}
+```
+
+### eth_getTransactionByBlockHashAndIndex {#eth_gettransactionbyblockhashandindex}
+
+블록 해시 및 트랜잭션 인덱스 위치로 트랜잭션에 대한 정보를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `DATA`, 32바이트 - 블록의 해시.
+2. `QUANTITY` - 트랜잭션 인덱스 위치의 정수.
+
+```js
+params: [
+ "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
+ "0x0", // 0
+]
+```
+
+**반환 값**
+[eth_getTransactionByHash](#eth_gettransactionbyhash)를 참조하세요
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
+```
+
+결과는 [eth_getTransactionByHash](#eth_gettransactionbyhash)를 참조하세요
+
+### eth_getTransactionByBlockNumberAndIndex {#eth_gettransactionbyblocknumberandindex}
+
+블록 번호 및 트랜잭션 인덱스 위치로 트랜잭션에 대한 정보를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `QUANTITY|TAG` - 블록 번호 또는 문자열 `"earliest"`, `"latest"`, `"pending"`, `"safe"` 또는 `"finalized"`, [블록 매개변수](/developers/docs/apis/json-rpc/#block-parameter)에서와 같이.
+2. `QUANTITY` - 트랜잭션 인덱스 위치.
+
+```js
+params: [
+ "0x9c47cf", // 10241999
+ "0x24", // 36
+]
+```
+
+**반환 값**
+[eth_getTransactionByHash](#eth_gettransactionbyhash)를 참조하세요
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}'
+```
+
+결과는 [eth_getTransactionByHash](#eth_gettransactionbyhash)를 참조하세요
+
+### eth_getTransactionReceipt {#eth_gettransactionreceipt}
+
+트랜잭션 해시로 트랜잭션의 영수증을 반환합니다.
+
+**참고** 보류 중인 트랜잭션에 대해서는 영수증을 사용할 수 없습니다.
+
+**매개변수**
+
+1. `DATA`, 32바이트 - 트랜잭션의 해시
+
+```js
+params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"]
+```
+
+**반환 값**
+`객체` - 트랜잭션 영수증 객체, 또는 영수증을 찾을 수 없는 경우 `null`:
+
+- `transactionHash `: `DATA`, 32바이트 - 트랜잭션의 해시.
+- `transactionIndex`: `QUANTITY` - 블록 내 트랜잭션 인덱스 위치의 정수.
+- `blockHash`: `DATA`, 32바이트 - 이 트랜잭션이 포함된 블록의 해시.
+- `blockNumber`: `QUANTITY` - 이 트랜잭션이 포함된 블록 번호.
+- `from`: `DATA`, 20바이트 - 발신자의 주소.
+- `to`: `DATA`, 20바이트 - 수신자의 주소. 계약 생성 트랜잭션인 경우 null.
+- `cumulativeGasUsed` : `QUANTITY` - 이 트랜잭션이 블록에서 실행되었을 때 사용된 총 가스 양.
+- `effectiveGasPrice` : `QUANTITY` - 가스 단위당 지불된 기본 수수료와 팁의 합계.
+- `gasUsed `: `QUANTITY` - 이 특정 트랜잭션에서만 사용된 가스 양.
+- `contractAddress `: `DATA`, 20바이트 - 트랜잭션이 계약 생성인 경우 생성된 계약 주소, 그렇지 않으면 `null`.
+- `logs`: `배열` - 이 트랜잭션이 생성한 로그 객체의 배열.
+- `logsBloom`: `DATA`, 256바이트 - 라이트 클라이언트가 관련 로그를 빠르게 검색할 수 있도록 하는 블룸 필터.
+- `type`: `QUANTITY` - 트랜잭션 유형의 정수, 레거시 트랜잭션의 경우 `0x0`, 액세스 목록 유형의 경우 `0x1`, 동적 수수료의 경우 `0x2`.
+
+또한 다음 중 하나를 반환합니다.
+
+- `root` : `DATA` 트랜잭션 후 상태 루트의 32바이트(비잔티움 이전)
+- `status`: `QUANTITY` `1`(성공) 또는 `0`(실패)
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],"id":1}'
+// 결과
+{
+ "jsonrpc": "2.0",
+ "id": 1,
+ "result": {
+ "blockHash":
+ "0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3",
+ "blockNumber": "0xeff35f",
+ "contractAddress": null, // 생성된 경우 주소 문자열
+ "cumulativeGasUsed": "0xa12515",
+ "effectiveGasPrice": "0x5a9c688d4",
+ "from": "0x6221a9c005f6e47eb398fd867784cacfdcfff4e7",
+ "gasUsed": "0xb4c8",
+ "logs": [{
+ // getFilterLogs 등이 반환한 로그
+ }],
+ "logsBloom": "0x00...0", // 256바이트 블룸 필터
+ "status": "0x1",
+ "to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
+ "transactionHash":
+ "0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5",
+ "transactionIndex": "0x66",
+ "type": "0x2"
+ }
+}
+```
+
+### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex}
+
+해시 및 엉클 인덱스 위치로 블록의 엉클에 대한 정보를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `DATA`, 32바이트 - 블록의 해시.
+2. `QUANTITY` - 엉클의 인덱스 위치.
+
+```js
+params: [
+ "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
+ "0x0", // 0
+]
+```
+
+**반환 값**
+[eth_getBlockByHash](#eth_getblockbyhash)를 참조하세요
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
+```
+
+결과는 [eth_getBlockByHash](#eth_getblockbyhash)를 참조하세요
+
+**참고**: 엉클은 개별 트랜잭션을 포함하지 않습니다.
+
+### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex}
+
+번호 및 엉클 인덱스 위치로 블록의 엉클에 대한 정보를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+1. `QUANTITY|TAG` - 블록 번호 또는 문자열 `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, [블록 매개변수](/developers/docs/apis/json-rpc/#block-parameter)에서와 같이.
+2. `QUANTITY` - 엉클의 인덱스 위치.
+
+```js
+params: [
+ "0x29c", // 668
+ "0x0", // 0
+]
+```
+
+**반환 값**
+[eth_getBlockByHash](#eth_getblockbyhash)를 참조하세요
+
+**참고**: 엉클은 개별 트랜잭션을 포함하지 않습니다.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}'
+```
+
+결과는 [eth_getBlockByHash](#eth_getblockbyhash)를 참조하세요
+
+### eth_newFilter {#eth_newfilter}
+
+필터 옵션을 기반으로 필터 객체를 생성하여 상태가 변경될 때(로그) 알립니다.
+상태가 변경되었는지 확인하려면 [eth_getFilterChanges](#eth_getfilterchanges)를 호출하세요.
+
+**토픽 필터 지정에 대한 참고 사항:**
+토픽은 순서에 따라 다릅니다. 토픽 [A, B]가 있는 로그가 포함된 트랜잭션은 다음 토픽 필터와 일치합니다:
+
+- `[]` "모든 것"
+- `[A]` "첫 번째 위치에 A(그리고 그 뒤에 모든 것)"
+- `[null, B]` "첫 번째 위치에 모든 것 AND 두 번째 위치에 B(그리고 그 뒤에 모든 것)"
+- `[A, B]` "첫 번째 위치에 A AND 두 번째 위치에 B(그리고 그 뒤에 모든 것)"
+- `[[A, B], [A, B]]` "첫 번째 위치에 (A 또는 B) AND 두 번째 위치에 (A 또는 B)(그리고 그 뒤에 모든 것)"
+- **매개변수**
+
+1. `객체` - 필터 옵션:
+
+- `fromBlock`: `QUANTITY|TAG` - (선택 사항, 기본값: `"latest"`) 정수 블록 번호 또는 `"latest"`(최신 제안 블록), `"safe"`(최신 안전 블록), `"finalized"`(최신 확정 블록), `"pending"`, `"earliest"`(아직 블록에 포함되지 않은 트랜잭션).
+- `toBlock`: `QUANTITY|TAG` - (선택 사항, 기본값: `"latest"`) 정수 블록 번호 또는 `"latest"`(최신 제안 블록), `"safe"`(최신 안전 블록), `"finalized"`(최신 확정 블록), `"pending"`, `"earliest"`(아직 블록에 포함되지 않은 트랜잭션).
+- `address`: `DATA|배열`, 20바이트 - (선택 사항) 로그가 발생해야 하는 계약 주소 또는 주소 목록.
+- `topics`: `DATA 배열` - (선택 사항) 32바이트 `DATA` 토픽의 배열. 토픽은 순서에 따라 다릅니다. 각 토픽은 "or" 옵션이 있는 DATA 배열일 수도 있습니다.
+
+```js
+params: [
+ {
+ fromBlock: "0x1",
+ toBlock: "0x2",
+ address: "0x8888f1f195afa192cfee860698584c030f4c9db1",
+ topics: [
+ "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
+ null,
+ [
+ "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
+ "0x0000000000000000000000000aff3454fce5edbc8cca8697c15331677e6ebccc",
+ ],
+ ],
+ },
+]
+```
+
+**반환 값**
+`QUANTITY` - 필터 ID.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":["0x12341234"]}],"id":73}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_newBlockFilter {#eth_newblockfilter}
+
+새 블록이 도착하면 알림을 보내도록 노드에 필터를 생성합니다.
+상태가 변경되었는지 확인하려면 [eth_getFilterChanges](#eth_getfilterchanges)를 호출하세요.
+
+**매개변수**
+없음
+
+**반환 값**
+`QUANTITY` - 필터 ID.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":73}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter}
+
+새로운 보류 중인 트랜잭션이 도착하면 알림을 보내도록 노드에 필터를 생성합니다.
+상태가 변경되었는지 확인하려면 [eth_getFilterChanges](#eth_getfilterchanges)를 호출하세요.
+
+**매개변수**
+없음
+
+**반환 값**
+`QUANTITY` - 필터 ID.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":73}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_uninstallFilter {#eth_uninstallfilter}
+
+지정된 ID의 필터를 제거합니다. 감시가 더 이상 필요하지 않을 때 항상 호출해야 합니다.
+또한 필터는 일정 기간 동안 [eth_getFilterChanges](#eth_getfilterchanges)로 요청되지 않으면 시간 초과됩니다.
+
+**매개변수**
+
+1. `QUANTITY` - 필터 ID.
+
+```js
+params: [
+ "0xb", // 11
+]
+```
+
+**반환 값**
+`부울` - 필터가 성공적으로 제거되면 `true`, 그렇지 않으면 `false`입니다.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0xb"],"id":73}'
+// 결과
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": true
+}
+```
+
+### eth_getFilterChanges {#eth_getfilterchanges}
+
+마지막 폴링 이후 발생한 로그 배열을 반환하는 필터용 폴링 메서드입니다.
+
+**매개변수**
+
+1. `QUANTITY` - 필터 ID.
+
+```js
+params: [
+ "0x16", // 22
+]
+```
+
+**반환 값**
+`배열` - 로그 객체의 배열, 또는 마지막 폴링 이후 변경된 사항이 없는 경우 빈 배열.
+
+- `eth_newBlockFilter`로 생성된 필터의 경우 반환값은 블록 해시(`DATA`, 32바이트)입니다. 예: `["0x3454645634534..."]`.
+
+- `eth_newPendingTransactionFilter`로 생성된 필터의 경우 반환값은 트랜잭션 해시(`DATA`, 32바이트)입니다. 예: `["0x6345343454645..."]`.
+
+- `eth_newFilter`로 생성된 필터의 경우 로그는 다음 매개변수가 있는 객체입니다:
+ - `removed`: `TAG` - 체인 재구성으로 인해 로그가 제거된 경우 `true`입니다. 유효한 로그인 경우 `false`입니다.
+ - `logIndex`: `QUANTITY` - 블록 내 로그 인덱스 위치의 정수. 보류 중인 로그일 때 `null`.
+ - `transactionIndex`: `QUANTITY` - 로그가 생성된 트랜잭션 인덱스 위치의 정수. 보류 중인 로그일 때 `null`.
+ - `transactionHash`: `DATA`, 32바이트 - 이 로그가 생성된 트랜잭션의 해시. 보류 중인 로그일 때 `null`.
+ - `blockHash`: `DATA`, 32바이트 - 이 로그가 포함된 블록의 해시. 보류 중일 때 `null`. 보류 중인 로그일 때 `null`.
+ - `blockNumber`: `QUANTITY` - 이 로그가 포함된 블록 번호. 보류 중일 때 `null`. 보류 중인 로그일 때 `null`.
+ - `address`: `DATA`, 20바이트 - 이 로그가 시작된 주소.
+ - `data`: `DATA` - 가변 길이의 인덱싱되지 않은 로그 데이터. (solidity에서: 0개 이상의 32바이트 비인덱싱 로그 인수.)
+ - `topics`: `DATA 배열` - 인덱싱된 로그 인수의 0에서 4개의 32바이트 `DATA` 배열. (solidity에서: `anonymous` 지정자로 이벤트를 선언한 경우를 제외하고 첫 번째 토픽은 이벤트 서명의 해시입니다(예: `Deposit(address,bytes32,uint256)`).
+
+- **예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}'
+// 결과
+{
+ "id":1,
+ "jsonrpc":"2.0",
+ "result": [{
+ "logIndex": "0x1", // 1
+ "blockNumber":"0x1b4", // 436
+ "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d",
+ "transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf",
+ "transactionIndex": "0x0", // 0
+ "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d",
+ "data":"0x0000000000000000000000000000000000000000000000000000000000000000",
+ "topics": ["0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5"]
+ },{
+ ...
+ }]
+}
+```
+
+### eth_getFilterLogs {#eth_getfilterlogs}
+
+지정된 ID와 일치하는 필터의 모든 로그 배열을 반환합니다.
+
+**매개변수**
+
+1. `QUANTITY` - 필터 ID.
+
+```js
+params: [
+ "0x16", // 22
+]
+```
+
+**반환 값**
+[eth_getFilterChanges](#eth_getfilterchanges)를 참조하세요
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}'
+```
+
+결과는 [eth_getFilterChanges](#eth_getfilterchanges)를 참조하세요
+
+### eth_getLogs {#eth_getlogs}
+
+지정된 필터 객체와 일치하는 모든 로그의 배열을 반환합니다.
+
+**매개변수**
+
+1. `객체` - 필터 옵션:
+
+- `fromBlock`: `QUANTITY|TAG` - (선택 사항, 기본값: `"latest"`) 정수 블록 번호 또는 `"latest"`(최신 제안 블록), `"safe"`(최신 안전 블록), `"finalized"`(최신 확정 블록), `"pending"`, `"earliest"`(아직 블록에 포함되지 않은 트랜잭션).
+- `toBlock`: `QUANTITY|TAG` - (선택 사항, 기본값: `"latest"`) 정수 블록 번호 또는 `"latest"`(최신 제안 블록), `"safe"`(최신 안전 블록), `"finalized"`(최신 확정 블록), `"pending"`, `"earliest"`(아직 블록에 포함되지 않은 트랜잭션).
+- `address`: `DATA|배열`, 20바이트 - (선택 사항) 로그가 발생해야 하는 계약 주소 또는 주소 목록.
+- `topics`: `DATA 배열` - (선택 사항) 32바이트 `DATA` 토픽의 배열. 토픽은 순서에 따라 다릅니다. 각 토픽은 "or" 옵션이 있는 DATA 배열일 수도 있습니다.
+- `blockHash`: `DATA`, 32바이트 - (선택 사항, **향후**) EIP-234가 추가되면서 `blockHash`는 반환되는 로그를 32바이트 해시 `blockHash`가 있는 단일 블록으로 제한하는 새로운 필터 옵션이 될 것입니다. `blockHash`를 사용하는 것은 `fromBlock` = `toBlock` = 해시 `blockHash`가 있는 블록 번호와 동일합니다. 필터 기준에 `blockHash`가 있는 경우 `fromBlock`이나 `toBlock`은 허용되지 않습니다.
+
+```js
+params: [
+ {
+ topics: [
+ "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
+ ],
+ },
+]
+```
+
+**반환 값**
+[eth_getFilterChanges](#eth_getfilterchanges)를 참조하세요
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}'
+```
+
+결과는 [eth_getFilterChanges](#eth_getfilterchanges)를 참조하세요
+
+## 사용 예제 {#usage-example}
+
+### JSON_RPC를 사용하여 계약 배포하기 {#deploying-contract}
+
+이 섹션에서는 RPC 인터페이스만 사용하여 계약을 배포하는 방법에 대한 시연을 포함합니다. 이러한 복잡성이 추상화된 계약 배포를 위한 대체 경로가 있습니다. 예를 들어, [web3.js](https://web3js.readthedocs.io/) 및 [web3.py](https://github.com/ethereum/web3.py)와 같이 RPC 인터페이스 위에 구축된 라이브러리를 사용하는 것입니다. 이러한 추상화는 일반적으로 이해하기 쉽고 오류가 발생할 가능성이 적지만, 내부에서 어떤 일이 일어나고 있는지 이해하는 것은 여전히 유용합니다.
+
+다음은 이더리움 노드에 JSON-RPC 인터페이스를 사용하여 배포될 `Multiply7`이라는 간단한 스마트 계약입니다. 이 튜토리얼은 독자가 이미 Geth 노드를 실행하고 있다고 가정합니다. 노드와 클라이언트에 대한 자세한 정보는 [여기](/developers/docs/nodes-and-clients/run-a-node)에서 확인할 수 있습니다. Geth가 아닌 클라이언트의 경우 HTTP JSON-RPC를 시작하는 방법을 보려면 개별 [클라이언트](/developers/docs/nodes-and-clients/) 문서를 참조하세요. 대부분의 클라이언트는 기본적으로 `localhost:8545`에서 제공됩니다.
+
+```javascript
+contract Multiply7 {
+ event Print(uint);
+ function multiply(uint input) returns (uint) {
+ Print(input * 7);
+ return input * 7;
+ }
+}
+```
+
+가장 먼저 할 일은 HTTP RPC 인터페이스가 활성화되었는지 확인하는 것입니다. 즉, 시작 시 Geth에 `--http` 플래그를 제공합니다. 이 예에서는 비공개 개발 체인에서 Geth 노드를 사용합니다. 이 방법을 사용하면 실제 네트워크에서 이더가 필요하지 않습니다.
+
+```bash
+geth --http --dev console 2>>geth.log
+```
+
+이렇게 하면 `http://localhost:8545`에서 HTTP RPC 인터페이스가 시작됩니다.
+
+[curl](https://curl.se)을 사용하여 코인베이스 주소(계정 배열에서 첫 번째 주소를 가져옴)와 잔액을 검색하여 인터페이스가 실행 중인지 확인할 수 있습니다. 이 예제의 데이터는 로컬 노드에서 다를 수 있다는 점에 유의하세요. 이 명령을 사용해 보려면 두 번째 curl 요청의 요청 매개변수를 첫 번째 요청에서 반환된 결과로 바꾸세요.
+
+```bash
+curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[], "id":1}' -H "Content-Type: application/json" localhost:8545
+{"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]}
+
+curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545
+{"id":2,"jsonrpc":"2.0","result":"0x1639e49bba16280000"}
+```
+
+숫자는 16진수로 인코딩되므로 잔액은 웨이 단위의 16진수 문자열로 반환됩니다. 잔액을 이더 단위의 숫자로 갖고 싶다면 Geth 콘솔에서 web3를 사용할 수 있습니다.
+
+```javascript
+web3.fromWei("0x1639e49bba16280000", "ether")
+// "410"
+```
+
+이제 비공개 개발 체인에 이더가 있으므로 계약을 배포할 수 있습니다. 첫 번째 단계는 Multiply7 계약을 EVM으로 보낼 수 있는 바이트 코드로 컴파일하는 것입니다. 솔리디티 컴파일러인 solc를 설치하려면 [솔리디티 문서](https://docs.soliditylang.org/en/latest/installing-solidity.html)를 따르세요. (예제에 사용된 컴파일러 버전](https://github.com/ethereum/solidity/releases/tag/v0.4.20)과 일치시키기 위해 이전 `solc` 릴리스를 사용하고 싶을 수도 있습니다.)
+
+다음 단계는 Multiply7 계약을 EVM으로 보낼 수 있는 바이트 코드로 컴파일하는 것입니다.
+
+```bash
+echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin
+
+======= :Multiply7 =======
+Binary:
+6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029
+```
+
+이제 컴파일된 코드가 있으므로 이를 배포하는 데 드는 가스 비용을 결정해야 합니다. RPC 인터페이스에는 추정치를 제공하는 `eth_estimateGas` 메서드가 있습니다.
+
+```bash
+curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545
+{"jsonrpc":"2.0","id":5,"result":"0x1c31e"}
+```
+
+그리고 마지막으로 계약을 배포합니다.
+
+```bash
+curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "gas": "0x1c31e", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 6}' -H "Content-Type: application/json" localhost:8545
+{"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"}
+```
+
+트랜잭션이 노드에 의해 수락되고 트랜잭션 해시가 반환됩니다. 이 해시는 트랜잭션을 추적하는 데 사용할 수 있습니다. 다음 단계는 계약이 배포된 주소를 결정하는 것입니다. 실행된 각 트랜잭션은 영수증을 생성합니다. 이 영수증에는 트랜잭션이 포함된 블록과 EVM에서 사용한 가스 양과 같은 트랜잭션에 대한 다양한 정보가 포함되어 있습니다. 트랜잭션이
+계약을 생성하는 경우 계약 주소도 포함됩니다. `eth_getTransactionReceipt` RPC 메서드로 영수증을 검색할 수 있습니다.
+
+```bash
+curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545
+{"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}}
+```
+
+우리의 계약은 `0x4d03d617d700cf81935d7f797f4e2ae719648262`에서 생성되었습니다. 영수증 대신 null 결과가 나오면 트랜잭션이 아직 블록에 포함되지 않았다는 의미입니다. 잠시 기다린 후 합의 클라이언트가 실행 중인지 확인하고 다시 시도하십시오.
+
+#### 스마트 계약과 상호작용하기 {#interacting-with-smart-contract}
+
+이 예제에서는 `eth_sendTransaction`을 사용하여 `multiply` 계약의 메서드에 트랜잭션을 전송합니다.
+
+`eth_sendTransaction`에는 `from`, `to`, `data`와 같은 여러 인수가 필요합니다. `From`은 우리 계정의 공개 주소이고 `to`는 계약 주소입니다. `data` 인수는 어떤 메서드를 어떤 인수로 호출해야 하는지를 정의하는 페이로드를 포함합니다. 이것이 [ABI(애플리케이션 바이너리 인터페이스)](https://docs.soliditylang.org/en/latest/abi-spec.html)가 사용되는 부분입니다. ABI는 EVM에 대한 데이터를 정의하고 인코딩하는 방법을 정의하는 JSON 파일입니다.
+
+페이로드의 바이트는 계약에서 호출되는 메서드를 정의합니다. 이것은 함수 이름과 인수 유형에 대한 Keccak 해시의 처음 4바이트를 16진수로 인코딩한 것입니다. multiply 함수는 uint256의 별칭인 uint를 허용합니다. 그러면 다음과 같이 됩니다.
+
+```javascript
+web3.sha3("multiply(uint256)").substring(0, 10)
+// "0xc6888fa1"
+```
+
+다음으로 인수를 인코딩해 보겠습니다. 값 6과 같은 uint256이 하나만 있습니다. ABI에는 uint256 유형을 인코딩하는 방법을 지정하는 섹션이 있습니다.
+
+`int: enc(X)`는 X의 빅엔디언 2의 보수 인코딩으로, 음수 X의 경우 상위(왼쪽)에 0xff를, 양수 X의 경우 0바이트를 채워 길이가 32바이트의 배수가 되도록 합니다.
+
+이것은 `0000000000000000000000000000000000000000000000000000000000000006`으로 인코딩됩니다.
+
+함수 선택기와 인코딩된 인수를 결합하면 데이터는 `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`이 됩니다.
+
+이제 이것을 노드로 보낼 수 있습니다.
+
+```bash
+curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0xeb85a5557e5bdc18ee1934a89d8bb402398ee26a", "to": "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", "data": "0xc6888fa10000000000000000000000000000000000000000000000000000000000000006"}], "id": 8}' -H "Content-Type: application/json" localhost:8545
+{"id":8,"jsonrpc":"2.0","result":"0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74"}
+```
+
+트랜잭션이 전송되었으므로 트랜잭션 해시가 반환되었습니다. 영수증을 검색하면 다음과 같이 표시됩니다.
+
+```javascript
+{
+ blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55",
+ blockNumber: 268,
+ contractAddress: null,
+ cumulativeGasUsed: 22631,
+ gasUsed: 22631,
+ logs: [{
+ address: "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d",
+ blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55",
+ blockNumber: 268,
+ data: "0x000000000000000000000000000000000000000000000000000000000000002a",
+ logIndex: 0,
+ topics: ["0x24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"],
+ transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74",
+ transactionIndex: 0
+ }],
+ transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74",
+ transactionIndex: 0
+}
+```
+
+영수증에는 로그가 포함되어 있습니다. 이 로그는 트랜잭션 실행 시 EVM에 의해 생성되어 영수증에 포함되었습니다. `multiply` 함수는 입력값에 7을 곱한 값으로 `Print` 이벤트가 발생했음을 보여줍니다. `Print` 이벤트의 인수가 uint256이었으므로 ABI 규칙에 따라 디코딩하면 예상되는 10진수 42를 얻을 수 있습니다. 데이터 외에도 토픽을 사용하여 어떤 이벤트가 로그를 생성했는지 확인할 수 있다는 점에 주목할 가치가 있습니다.
+
+```javascript
+web3.sha3("Print(uint256)")
+// "24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"
+```
+
+이것은 JSON-RPC의 직접적인 사용을 보여주는 가장 일반적인 작업 중 일부에 대한 간략한 소개였습니다.
+
+## 관련 주제 {#related-topics}
+
+- [JSON-RPC 사양](http://www.jsonrpc.org/specification)
+- [노드 및 클라이언트](/developers/docs/nodes-and-clients/)
+- [JavaScript API](/developers/docs/apis/javascript/)
+- [백엔드 API](/developers/docs/apis/backend/)
+- [실행 클라이언트](/developers/docs/nodes-and-clients/#execution-clients)
diff --git a/public/content/translations/ko/developers/docs/blocks/index.md b/public/content/translations/ko/developers/docs/blocks/index.md
new file mode 100644
index 00000000000..acd4581d457
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/blocks/index.md
@@ -0,0 +1,153 @@
+---
+title: "블록"
+description: "이더리움 블록체인 내의 블록 개요 - 데이터 구조, 왜 필요한지 그리고 어떻게 만들어지는지"
+lang: ko
+---
+
+블록은 이전 블록의 해시를 포함하는 체인 내의 트랜잭션의 묶음입니다. 블록을 체인으로 연결하는 이유는 해시는 암호화 방식으로 블록 데이터에서 파생되기 때문입니다. 이것은 이전의 어느 블록의 하나의 변경이 모든 이어지는 해시를 바꾸면서 그 다음의 모든 블록을 무효화하고, 블록체인을 실행하는 모두에게 알리기 때문에 사기를 막는다.
+
+## 필수 구성 요소 {#prerequisites}
+
+블록은 입문자에게 매우 친근한 주제입니다. 하지만 이 페이지를 더 잘 이해하는 데 도움이 되도록 먼저 [계정](/developers/docs/accounts/), [트랜잭션](/developers/docs/transactions/), [이더리움 소개](/developers/docs/intro-to-ethereum/)를 읽어보시는 것을 추천합니다.
+
+## 블록을 사용하는 이유 {#why-blocks}
+
+이더리움 네트워크의 모든 참여자가 동기화된 상태를 유지하고 정확한 트랜잭션 기록에 동의할 수 있도록 트랜잭션을 블록으로 일괄 처리합니다. 이는 수십(수백) 개의 트랜잭션이 제출되고, 합의하며, 한번에 동기화된다는 것을 의미합니다.
+
+
+_다이어그램은 [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)에서 발췌_
+
+제출 간격을 두어, 모든 네트워크 참여자들에게 합의할 수 있는 충분한 시간을 줍니다. 요청 트랜잭션이 초당 수십개가 발생하더라도, 블록은 매 12초마다 한번 생성되어 제출됩니다.
+
+## 블록 작동 방식 {#how-blocks-work}
+
+트랜잭션 기록을 보존하기 위해서, 블록은 엄격히 순서를 정하고 (모든 생성된 새로운 블록은 그 부모 블록의 참조를 갖는다), 블록 내의 트랜잭션도 엄격히 순서가 잘 정해진다. 드문 경우를 제외하고, 언제나 네트워크 상의 모든 참여자들은 정확한 숫자와 블록 기록 상에서 합의되어 있고, 현재 라이브 트랜잭션 요청을 다음 블록으로 묶기 위해 동작 중이다.
+
+네트워크에서 무작위로 선택된 검증인이 블록을 구성하면 해당 블록은 네트워크의 나머지 부분으로 전파됩니다. 모든 노드는 이 블록을 블록체인 끝에 추가하고 다음 블록을 생성하기 위해 새로운 검증자가 선택됩니다 정확한 블록-구성 과정과 제출/합의 과정은 현재 이더리움의 "작업증명" 프로토콜에 명시되어있다.
+
+## 지분 증명 프로토콜 {#proof-of-stake-protocol}
+
+작업 증명은 다음을 의미합니다.
+
+- 검증 노드는 나쁜 행동에 대한 담보로 예금 계좌에 32 ETH를 스테이킹해야 한다. 이는 부정직한 활동으로 인해 해당 지분의 일부 또는 전부가 파괴될 수 있으므로 네트워크를 보호하는 데 도움이 된다.
+- 모든 슬롯(12초 간격) 에서 검증인은 블록 제안자로 무작위로 선택된다. 그들은 트랜잭션들을 하나로 묶어서 실행하고 새로운 'state'를 결정한다. 그들은 정보를 블럭에 담아 다른 검증자에게 전달한다.
+- 새로운 블록에 대한 소식을 들은 다른 검증인은 트랜잭션을 다시 실행하여 글로벌 상태에 대한 제안된 변경 사항에 동의하는지 확인합니다. 블록이 유효하다고 가정하면 이를 자신의 데이터베이스에 추가합니다.
+- 검증인이 동일한 슬롯에서 두 개의 충돌하는 블록에 대해 듣게 되면 포크 선택 알고리즘을 사용하여 가장 많이 스테이킹된 ETH가 지원하는 블록을 선택합니다.
+
+[지분 증명에 대해 더 알아보기](/developers/docs/consensus-mechanisms/pos)
+
+## 블록 내에 무엇이 있나요? {#block-anatomy}
+
+블록은 수많은 정보를 담고 있습니다. 가장 높은 레벨의 블록에는 다음 필드가 포함됩니다:
+
+| 필드 | 설명 |
+| :--------------- | :--------------------- |
+| `슬롯` | 블록이 속한 슬롯 |
+| `proposer_index` | 블록을 제안하는 검증자의 ID |
+| `parent_root` | 이전 블록의 해시 |
+| `state_root` | 상태 객체의 루트 해시 |
+| `본문` | 아래에 정의된 여러 필드를 포함하는 객체 |
+
+블록 `body`는 자체적으로 여러 필드를 포함합니다:
+
+| 필드 | 설명 |
+| :------------------- | :------------------------------------- |
+| `randao_reveal` | 다음 블록 제안자를 선택하는 데 사용되는 값 |
+| `eth1_data` | 예금 계약에 대한 정보 |
+| `graffiti` | 블록에 태그를 지정하는 데 사용되는 임의의 데이터 |
+| `proposer_slashings` | 슬래싱될 검증자 목록 |
+| `attester_slashings` | 슬래싱될 인증자 목록 |
+| `인증` | 이전 슬롯에 대해 이루어진 인증 목록 |
+| `입금` | 예금 계약에 대한 새로운 예금 목록 |
+| `voluntary_exits` | 네트워크를 나가는 검증자 목록 |
+| `sync_aggregate` | 라이트 클라이언트에 서비스를 제공하는 데 사용되는 검증자의 하위 집합 |
+| `execution_payload` | 실행 클라이언트에서 전달된 트랜잭션 |
+
+`attestations` 필드에는 블록에 있는 모든 인증 목록이 포함됩니다. 인증서에는 데이터 타입과 여러 조각의 데이터가 포함됩니다. 각 인증에는 다음이 포함됩니다.
+
+| 필드 | 설명 |
+| :----------------- | :-------------------------- |
+| `aggregation_bits` | 이 인증에 참여한 검증자 목록 |
+| `데이터` | 여러 하위 필드가 있는 컨테이너 |
+| `signature` | `data` 부분에 대한 검증자 집합의 집계 서명 |
+
+`attestation`의 `data` 필드에는 다음이 포함됩니다.
+
+| 필드 | 설명 |
+| :------------------ | :------------------------ |
+| `슬롯` | 인증과 관련된 슬롯 |
+| `index` | 인증하는 검증자의 인덱스 |
+| `beacon_block_root` | 체인의 헤드로 간주되는 비콘 블록의 루트 해시 |
+| `출처` | 마지막으로 정당화된 체크포인트 |
+| `target` | 최신 에폭 경계 블록 |
+
+`execution_payload`에서 트랜잭션을 실행하면 전역 상태가 업데이트됩니다. 모든 클라이언트는 `execution_payload`의 트랜잭션을 다시 실행하여 새로운 상태가 새 블록의 `state_root` 필드에 있는 상태와 일치하는지 확인합니다. 이것이 클라이언트가 새 블록이 유효하고 블록체인에 안전하게 추가할 수 있는지 알 수 있는 방법입니다. `execution payload` 자체는 여러 필드가 있는 객체입니다. 또한 실행 데이터에 대한 중요한 요약 정보가 포함된 `execution_payload_header`가 있습니다. 이러한 데이터 구조는 다음과 같이 구성됩니다.
+
+`execution_payload_header`에는 다음 필드가 포함됩니다.
+
+| 필드 | 설명 |
+| :------------------ | :---------------------------------- |
+| `parent_hash` | 부모 블록의 해시 |
+| `fee_recipient` | 거래 수수료를 지불할 계정 주소 |
+| `state_root` | 이 블록의 변경 사항을 적용한 후의 전역 상태에 대한 루트 해시 |
+| `receipts_root` | 거래 영수증 트리의 해시 |
+| `logs_bloom` | 이벤트 로그를 포함하는 데이터 구조 |
+| `prev_randao` | 임의 검증자 선택에 사용되는 값 |
+| `block_number` | 현재 블록의 번호 |
+| `gas_limit` | 이 블록에서 허용되는 최대 가스 |
+| `gas_used` | 이 블록에서 실제 사용된 가스량 |
+| `timestamp` | 블록 시간 |
+| `extra_data` | 원시 바이트로서의 임의의 추가 데이터 |
+| `base_fee_per_gas` | 기본 수수료 값 |
+| `block_hash` | 실행 블록의 해시 |
+| `transactions_root` | 페이로드에 있는 트랜잭션의 루트 해시 |
+| `withdrawal_root` | 페이로드에 있는 인출의 루트 해시 |
+
+`execution_payload` 자체에는 다음이 포함됩니다(트랜잭션의 루트 해시 대신 실제 트랜잭션 목록 및 인출 정보가 포함된다는 점을 제외하면 헤더와 동일합니다):
+
+| 필드 | 설명 |
+| :----------------- | :---------------------------------- |
+| `parent_hash` | 부모 블록의 해시 |
+| `fee_recipient` | 거래 수수료를 지불할 계정 주소 |
+| `state_root` | 이 블록의 변경 사항을 적용한 후의 전역 상태에 대한 루트 해시 |
+| `receipts_root` | 거래 영수증 트리의 해시 |
+| `logs_bloom` | 이벤트 로그를 포함하는 데이터 구조 |
+| `prev_randao` | 임의 검증자 선택에 사용되는 값 |
+| `block_number` | 현재 블록의 번호 |
+| `gas_limit` | 이 블록에서 허용되는 최대 가스 |
+| `gas_used` | 이 블록에서 실제 사용된 가스량 |
+| `timestamp` | 블록 시간 |
+| `extra_data` | 원시 바이트로서의 임의의 추가 데이터 |
+| `base_fee_per_gas` | 기본 수수료 값 |
+| `block_hash` | 실행 블록의 해시 |
+| `트랜잭션` | 실행할 트랜잭션 목록 |
+| `출금` | 인출 객체 목록 |
+
+`withdrawals` 목록에는 다음과 같이 구성된 `withdrawal` 객체가 포함됩니다.
+
+| 필드 | 설명 |
+| :--------------- | :-------- |
+| `주소` | 인출한 계정 주소 |
+| `amount` | 인출 금액 |
+| `index` | 인출 인덱스 값 |
+| `validatorIndex` | 검증자 인덱스 값 |
+
+## 블록 시간 {#block-time}
+
+블록 시간이란 블록 사이의 시간을 의미합니다. 이더리움에서 시간은 '슬롯'이라고 하는 12초 단위로 나뉩니다. 각 슬롯에서 단일 검증자가 블록을 제안하도록 선택됩니다. 모든 검증자가 온라인 상태이고 완벽하게 작동한다고 가정하면 모든 슬롯에 블록이 존재하게 되며, 이는 블록 시간이 12초임을 의미합니다. 그러나 때로는 검증자가 블록을 제안하도록 호출되었을 때 오프라인 상태일 수 있으며, 이는 슬롯이 비어 있을 수 있음을 의미합니다.
+
+이 구현은 블록 시간이 확률적이며 프로토콜의 목표 채굴 난이도에 따라 조정되는 작업 증명 기반 시스템과 다릅니다. 이더리움의 [평균 블록 시간](https://etherscan.io/chart/blocktime)은 작업 증명에서 지분 증명으로의 전환이 새로운 12초 블록 시간의 일관성을 기반으로 명확하게 추론될 수 있는 완벽한 예입니다.
+
+## 블록 크기 {#block-size}
+
+마지막 중요한 유의점은 블록 그 자체가 크기 한계를 가진다는 것이다. 각 블록의 목표 크기는 3,000만 가스이지만, 네트워크 수요에 따라 블록 크기는 6,000만 가스(목표 블록 크기의 2배) 한도까지 증가하거나 감소합니다. 블록 가스 한도는 이전 블록의 가스 한도에서 1/1024만큼 상향 또는 하향 조정될 수 있습니다. 결과적으로, 검증자는 합의를 통해 블록 가스 한도를 변경할 수 있습니다. 블록 내 모든 트랜잭션에서 소비된 총 가스량은 블록 가스 한도보다 작아야 합니다. 블록이 제멋대로 커질 수 없도록 보장하기 때문에 이는 중요하다. 블록이 제멋대로 커질 수 있다면, 적은 성능 기준의 풀 노드들이 공간과 시간적 요구 사항으로 인해 네트워크 유지를 차츰 멈출 것이다. 블록이 클수록 다음 슬롯 시간에 맞춰 처리하는 데 더 큰 컴퓨팅 파워가 필요합니다. 이는 중앙화 요인이며, 블록 크기를 제한함으로써 이를 방지합니다.
+
+## 더 읽어보기 {#further-reading}
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
+
+## 관련 주제 {#related-topics}
+
+- [트랜잭션](/developers/docs/transactions/)
+- [가스](/developers/docs/gas/)
+- [지분 증명](/developers/docs/consensus-mechanisms/pos)
diff --git a/public/content/translations/ko/developers/docs/bridges/index.md b/public/content/translations/ko/developers/docs/bridges/index.md
new file mode 100644
index 00000000000..03b17b1d992
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/bridges/index.md
@@ -0,0 +1,138 @@
+---
+title: "브릿지"
+description: "개발자를 위한 브리징 개요"
+lang: ko
+---
+
+L1 블록체인과 L2 [확장](/developers/docs/scaling/) 솔루션이 확산되고, 점점 더 많은 탈중앙화 애플리케이션이 크로스체인으로 전환됨에 따라, 체인 간 통신 및 자산 이동의 필요성은 네트워크 인프라의 필수적인 부분이 되었습니다. 이를 가능하게 하기 위해 다양한 유형의 브리지가 존재합니다.
+
+## 브리지의 필요성 {#need-for-bridges}
+
+브리지는 블록체인 네트워크를 연결하기 위해 존재합니다. 브리지는 블록체인 간의 연결성과 상호운용성을 가능하게 합니다.
+
+블록체인은 분리된 환경에 존재하므로, 블록체인이 다른 블록체인과 자연스럽게 거래하고 통신할 방법이 없습니다. 결과적으로, 한 생태계 내에서 상당한 활동과 혁신이 있을 수 있지만, 다른 생태계와의 연결성 및 상호운용성 부족으로 인해 제한됩니다.
+
+브리지는 고립된 블록체인 환경이 서로 연결될 수 있는 방법을 제공합니다. 브리지는 토큰, 메시지, 임의의 데이터, 심지어 [스마트 계약](/developers/docs/smart-contracts/) 호출까지 한 체인에서 다른 체인으로 전송할 수 있는 블록체인 간의 전송 경로를 설정합니다.
+
+## 브리지의 이점 {#benefits-of-bridges}
+
+간단히 말해, 브리지는 블록체인 네트워크가 데이터를 교환하고 자산을 이동할 수 있도록 하여 수많은 사용 사례를 가능하게 합니다.
+
+블록체인은 애플리케이션 구축에 있어 고유한 강점, 약점, 접근 방식(예: 속도, 처리량, 비용 등)을 가지고 있습니다. 브리지는 블록체인이 서로의 혁신을 활용할 수 있도록 하여 전체 암호화폐 생태계의 발전에 기여합니다.
+
+개발자에게 브리지는 다음을 가능하게 합니다.
+
+- 체인 간 모든 데이터, 정보 및 자산의 전송.
+- 브리지가 프로토콜이 제공할 수 있는 설계 공간을 확장함에 따라 프로토콜에 대한 새로운 기능과 사용 사례를 발굴합니다. 예를 들어, 원래 이더리움 메인넷에 배포된 이자 농사 프로토콜은 모든 EVM 호환 체인에 유동성 풀을 제공할 수 있습니다.
+- 다양한 블록체인의 강점을 활용할 기회. 예를 들어, 개발자는 롤업 및 사이드체인 전반에 탈중앙화앱을 배포하여 다양한 L2 솔루션이 제공하는 더 낮은 수수료의 이점을 누릴 수 있으며, 사용자는 이를 통해 브리지를 이용할 수 있습니다.
+- 다양한 블록체인 생태계의 개발자 간 협력을 통해 새로운 제품을 구축합니다.
+- 다양한 생태계의 사용자와 커뮤니티를 자신의 탈중앙화앱으로 유치합니다.
+
+## 브리지는 어떻게 작동하나요? {#how-do-bridges-work}
+
+다양한 [유형의 브리지 설계](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/)가 있지만, 자산의 크로스체인 전송을 용이하게 하는 세 가지 방법이 두드러집니다.
+
+- **잠금 및 발행 –** 소스 체인에서 자산을 잠그고 대상 체인에서 자산을 발행합니다.
+- **소각 및 발행 –** 소스 체인에서 자산을 소각하고 대상 체인에서 자산을 발행합니다.
+- **아토믹 스왑 –** 다른 당사자와 소스 체인의 자산을 대상 체인의 자산으로 교환합니다.
+
+## 브리지 유형 {#bridge-types}
+
+브리지는 일반적으로 다음 유형 중 하나로 분류할 수 있습니다.
+
+- **네이티브 브리지 –** 이 브리지는 일반적으로 특정 블록체인의 유동성을 부트스트랩하기 위해 구축되어 사용자가 생태계로 자금을 쉽게 이동할 수 있도록 합니다. 예를 들어, [Arbitrum Bridge](https://bridge.arbitrum.io/)는 사용자가 이더리움 메인넷에서 Arbitrum으로 편리하게 브리징할 수 있도록 구축되었습니다. 이러한 브리지에는 Polygon PoS Bridge, [Optimism Gateway](https://app.optimism.io/bridge) 등이 있습니다.
+- **검증자 또는 오라클 기반 브리지 –** 이 브리지는 외부 검증자 세트 또는 오라클에 의존하여 크로스체인 전송을 검증합니다. 예: Multichain 및 Across.
+- **일반화된 메시지 전달 브리지 –** 이 브리지는 메시지 및 임의의 데이터와 함께 자산을 체인 간에 전송할 수 있습니다. 예: Axelar, LayerZero, Nomad.
+- **유동성 네트워크 –** 이 브리지는 주로 아토믹 스왑을 통해 한 체인에서 다른 체인으로 자산을 전송하는 데 중점을 둡니다. 일반적으로 크로스체인 메시지 전달을 지원하지 않습니다. 예: Connext 및 Hop.
+
+## 고려해야 할 절충안 {#trade-offs}
+
+브리지에는 완벽한 해결책이 없습니다. 오히려 목적을 달성하기 위한 절충안만 있을 뿐입니다. 개발자와 사용자는 다음 요소를 기반으로 브리지를 평가할 수 있습니다.
+
+- **보안 –** 누가 시스템을 검증하나요? 외부 검증자에 의해 보호되는 브리지는 일반적으로 블록체인의 검증자에 의해 로컬 또는 네이티브로 보호되는 브리지보다 안전하지 않습니다.
+- **편의성 –** 트랜잭션을 완료하는 데 얼마나 걸리며, 사용자는 몇 개의 트랜잭션에 서명해야 했나요? 개발자의 경우, 브리지를 통합하는 데 얼마나 걸리며 그 과정은 얼마나 복잡한가요?
+- **연결성 –** 브리지가 연결할 수 있는 대상 체인(예: 롤업, 사이드체인, 기타 레이어 1 블록체인 등)은 무엇이며, 새로운 블록체인을 통합하는 것은 얼마나 어려운가요?
+- **더 복잡한 데이터 전달 능력 –** 브리지가 체인 간에 메시지와 더 복잡한 임의의 데이터를 전송할 수 있나요, 아니면 크로스체인 자산 전송만 지원하나요?
+- **비용 효율성 –** 브리지를 통해 체인 간 자산을 전송하는 데 드는 비용은 얼마인가요? 일반적으로 브리지는 가스 비용 및 특정 경로의 유동성에 따라 고정 또는 가변 수수료를 부과합니다. 또한 보안을 보장하는 데 필요한 자본을 기반으로 브리지의 비용 효율성을 평가하는 것도 중요합니다.
+
+크게 보면, 브리지는 신뢰 기반과 무신뢰 기반으로 분류할 수 있습니다.
+
+- **신뢰 기반 –** 신뢰 기반 브리지는 외부에서 검증됩니다. 이들은 외부 검증자 세트(다중 서명 연합, 다자간 컴퓨팅 시스템, 오라클 네트워크)를 사용하여 체인 간 데이터를 전송합니다. 결과적으로, 이들은 뛰어난 연결성을 제공하고 체인 간에 완전히 일반화된 메시지 전달을 가능하게 할 수 있습니다. 또한 속도와 비용 효율성 측면에서도 우수한 성능을 보이는 경향이 있습니다. 이는 사용자가 브리지의 보안에 의존해야 하므로 보안을 희생하는 대가로 이루어집니다.
+- **무신뢰 기반 –** 이 브리지는 연결하는 블록체인과 해당 검증자에 의존하여 메시지와 토큰을 전송합니다. 이들은 (블록체인 외에) 새로운 신뢰 가정을 추가하지 않기 때문에 '무신뢰'입니다. 결과적으로 무신뢰 기반 브리지는 신뢰 기반 브리지보다 더 안전한 것으로 간주됩니다.
+
+다른 요소를 기반으로 무신뢰 기반 브리지를 평가하려면, 이를 일반화된 메시지 전달 브리지와 유동성 네트워크로 나누어야 합니다.
+
+- **일반화된 메시지 전달 브리지 –** 이 브리지는 보안과 체인 간에 더 복잡한 데이터를 전송하는 능력에서 뛰어납니다. 일반적으로 비용 효율성도 우수합니다. 그러나 이러한 강점은 일반적으로 라이트 클라이언트 브리지(예: IBC)의 연결성 저하와 사기 증명을 사용하는 낙관적 브리지(예: Nomad)의 속도 저하를 대가로 합니다.
+- **유동성 네트워크 –** 이 브리지는 아토믹 스왑을 사용하여 자산을 전송하며 로컬에서 검증되는 시스템입니다(즉, 기본 블록체인의 검증자를 사용하여 트랜잭션을 검증합니다). 결과적으로, 이들은 보안과 속도에서 뛰어납니다. 또한, 비교적 비용 효율적이며 우수한 연결성을 제공하는 것으로 간주됩니다. 그러나 주요 절충안은 크로스체인 메시지 전달을 지원하지 않기 때문에 더 복잡한 데이터를 전달할 수 없다는 것입니다.
+
+## 브리지의 위험성 {#risk-with-bridges}
+
+브리지는 [DeFi에서 가장 큰 해킹](https://rekt.news/leaderboard/) 상위 3건을 차지하며, 아직 개발 초기 단계에 있습니다. 어떤 브리지를 사용하든 다음과 같은 위험이 따릅니다.
+
+- **스마트 계약 위험 –** 많은 브리지가 성공적으로 감사를 통과했지만, 스마트 계약의 단 하나의 결함만으로도 자산이 해킹에 노출될 수 있습니다(예: [솔라나의 웜홀 브리지](https://rekt.news/wormhole-rekt/)).
+- **시스템적 금융 위험** – 많은 브리지가 래핑된 자산을 사용하여 새 체인에서 원본 자산의 표준 버전을 발행합니다. 이는 생태계를 시스템적 위험에 노출시키는데, 우리는 래핑된 버전의 토큰이 악용되는 것을 보았습니다.
+- **거래 상대방 위험 –** 일부 브리지는 사용자가 검증자들이 공모하여 사용자 자금을 훔치지 않을 것이라는 가정에 의존해야 하는 신뢰 기반 설계를 사용합니다. 사용자가 이러한 제3자 행위자를 신뢰해야 할 필요성은 러그 풀, 검열 및 기타 악의적인 활동과 같은 위험에 노출시킵니다.
+- **미해결 문제 –** 브리지가 개발 초기 단계에 있다는 점을 감안할 때, 네트워크 혼잡 시나 네트워크 수준 공격 또는 상태 롤백과 같은 예기치 않은 이벤트 동안 브리지가 다양한 시장 상황에서 어떻게 작동할지에 대한 많은 미해결 질문이 있습니다. 이러한 불확실성은 특정 위험을 제기하며, 그 정도는 아직 알려지지 않았습니다.
+
+## 탈중앙화앱은 브리지를 어떻게 사용할 수 있나요? {#how-can-dapps-use-bridges}
+
+다음은 개발자가 브리지 및 탈중앙화앱의 크로스체인 전환에 대해 고려할 수 있는 몇 가지 실용적인 애플리케이션입니다.
+
+### 브리지 통합하기 {#integrating-bridges}
+
+개발자를 위해 브리지 지원을 추가하는 방법은 여러 가지가 있습니다.
+
+1. **자체 브리지 구축 –** 안전하고 신뢰할 수 있는 브리지를 구축하는 것은 쉽지 않으며, 특히 신뢰를 최소화하는 경로를 택하는 경우 더욱 그렇습니다. 또한, 확장성 및 상호운용성 연구와 관련된 수년간의 경험과 기술 전문 지식이 필요합니다. 또한, 브리지를 유지하고 실행 가능하게 만들기 위해 충분한 유동성을 유치할 실무 팀이 필요합니다.
+
+2. **사용자에게 여러 브리지 옵션 표시 –** 많은 [탈중앙화앱](/developers/docs/dapps/)은 사용자가 상호 작용하기 위해 네이티브 토큰을 보유해야 합니다. 사용자가 자신의 토큰에 액세스할 수 있도록 웹사이트에서 다양한 브리지 옵션을 제공합니다. 그러나 이 방법은 사용자를 탈중앙화앱 인터페이스에서 벗어나게 하고 다른 탈중앙화앱 및 브리지와 상호 작용해야 하므로 문제에 대한 임시방편입니다. 이는 실수를 할 가능성이 높아지는 번거로운 온보딩 경험입니다.
+
+3. **브리지 통합 –** 이 솔루션은 탈중앙화앱이 사용자를 외부 브리지 및 DEX 인터페이스로 보낼 필요가 없습니다. 이를 통해 탈중앙화앱은 사용자 온보딩 경험을 개선할 수 있습니다. 하지만 이 접근 방식에는 한계가 있습니다.
+
+ - 브리지의 평가 및 유지 관리는 어렵고 시간이 많이 소요됩니다.
+ - 하나의 브리지를 선택하면 단일 장애점과 종속성이 발생합니다.
+ - 탈중앙화앱은 브리지의 기능에 의해 제한됩니다.
+ - 브리지만으로는 충분하지 않을 수 있습니다. 탈중앙화앱은 크로스체인 스왑과 같은 더 많은 기능을 제공하기 위해 DEX가 필요할 수 있습니다.
+
+4. **여러 브리지 통합 –** 이 솔루션은 단일 브리지 통합과 관련된 많은 문제를 해결합니다. 그러나 여러 브리지를 통합하는 것은 리소스를 많이 소모하고 개발자에게 기술 및 통신 오버헤드를 발생시키기 때문에 한계가 있습니다. 이는 암호화폐에서 가장 부족한 리소스입니다.
+
+5. **브리지 애그리게이터 통합 –** 탈중앙화앱을 위한 또 다른 옵션은 여러 브리지에 대한 액세스를 제공하는 브리지 애그리게이터 솔루션을 통합하는 것입니다. 브리지 애그리게이터는 모든 브리지의 강점을 상속하므로 단일 브리지의 기능에 의해 제한되지 않습니다. 특히, 브리지 애그리게이터는 일반적으로 브리지 통합을 유지 관리하므로 탈중앙화앱이 브리지 통합의 기술 및 운영 측면을 파악해야 하는 번거로움을 덜어줍니다.
+
+그렇긴 하지만, 브리지 애그리게이터에도 한계가 있습니다. 예를 들어, 더 많은 브리지 옵션을 제공할 수 있지만, 일반적으로 시장에는 애그리게이터 플랫폼에서 제공하는 것 외에 더 많은 브리지가 있습니다. 또한, 브리지와 마찬가지로 브리지 애그리게이터도 스마트 계약 및 기술 위험에 노출됩니다(더 많은 스마트 계약 = 더 많은 위험).
+
+탈중앙화앱이 브리지 또는 애그리게이터를 통합하는 경로를 택하는 경우, 통합의 깊이에 따라 다양한 옵션이 있습니다. 예를 들어, 사용자 온보딩 경험을 개선하기 위한 프런트엔드 통합일 뿐이라면 탈중앙화앱은 위젯을 통합할 것입니다. 그러나 통합이 스테이킹, 이자 농사 등과 같은 더 깊은 크로스체인 전략을 탐색하기 위한 것이라면 탈중앙화앱은 SDK 또는 API를 통합합니다.
+
+### 여러 체인에 탈중앙화앱 배포하기 {#deploying-a-dapp-on-multiple-chains}
+
+여러 체인에 탈중앙화앱을 배포하기 위해 개발자는 [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/) 등과 같은 개발 플랫폼을 사용할 수 있습니다. 일반적으로 이러한 플랫폼에는 탈중앙화앱이 크로스체인으로 전환할 수 있도록 하는 구성 가능한 플러그인이 함께 제공됩니다. 예를 들어, 개발자는 [hardhat-deploy plugin](https://github.com/wighawag/hardhat-deploy)에서 제공하는 결정론적 배포 프록시를 사용할 수 있습니다.
+
+#### 예시:
+
+- [크로스체인 탈중앙화앱을 구축하는 방법](https://moralis.io/how-to-build-cross-chain-dapps/)
+- [크로스체인 NFT 마켓플레이스 구축하기](https://youtu.be/WZWCzsB1xUE)
+- [Moralis: 크로스체인 NFT 탈중앙화앱 구축하기](https://www.youtube.com/watch?v=ehv70kE1QYo)
+
+### 체인 간 계약 활동 모니터링하기 {#monitoring-contract-activity-across-chains}
+
+체인 간 계약 활동을 모니터링하기 위해 개발자는 서브그래프 및 Tenderly와 같은 개발자 플랫폼을 사용하여 스마트 계약을 실시간으로 관찰할 수 있습니다. 이러한 플랫폼에는 [계약에서 발생한 이벤트](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events) 확인 등 크로스체인 활동에 대한 더 큰 데이터 모니터링 기능을 제공하는 도구도 있습니다.
+
+#### 도구
+
+- [The Graph](https://thegraph.com/en/)
+- [Tenderly](https://tenderly.co/)
+
+## 더 읽어보기 {#further-reading}
+
+- [블록체인 브리지](/bridges/) – ethereum.org
+- [L2Beat 브리지 위험 프레임워크](https://l2beat.com/bridges/summary)
+- [블록체인 브리지: 암호화폐 네트워크의 네트워크 구축](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) - 2021년 9월 8일 – Dmitriy Berenzon
+- [상호운용성 트릴레마](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) - 2021년 10월 1일 – Arjun Bhuptani
+- [클러스터: 신뢰 기반 및 신뢰 최소화 브리지가 멀티체인 환경을 형성하는 방법](https://blog.celestia.org/clusters/) - 2021년 10월 4일 – Mustafa Al-Bassam
+- [LI.FI: 브리지에서 신뢰는 스펙트럼입니다](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) - 2022년 4월 28일 – Arjun Chand
+- [롤업 상호운용성 솔루션의 현황](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - 2024년 6월 20일 – Alex Hook
+- [안전한 크로스체인 상호운용성을 위한 공유 보안 활용: Lagrange State Committees 등](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - 2024년 6월 12일 – Emmanuel Awosika
+
+또한, [James Prestwich](https://twitter.com/_prestwich)가 브리지에 대한 더 깊은 이해를 돕기 위해 제공한 통찰력 있는 발표 자료가 있습니다.
+
+- [벽으로 둘러싸인 정원이 아닌 브리지 구축하기](https://youtu.be/ZQJWMiX4hT0)
+- [브리지 분석하기](https://youtu.be/b0mC-ZqN8Oo)
+- [브리지는 왜 불타고 있는가](https://youtu.be/c7cm2kd20j8)
diff --git a/public/content/translations/ko/developers/docs/consensus-mechanisms/index.md b/public/content/translations/ko/developers/docs/consensus-mechanisms/index.md
new file mode 100644
index 00000000000..f08c1a23da0
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/consensus-mechanisms/index.md
@@ -0,0 +1,92 @@
+---
+title: "합의 메커니즘"
+description: "분산 시스템에서 합의 프로토콜에 대한 설명과 이더리움에서의 역할."
+lang: ko
+---
+
+'합의 메커니즘'이라는 용어는 일반적으로 '지분 증명', '작업 증명' 또는 '권위 증명' 프로토콜을 지칭할 때 사용됩니다. 하지만 이는 [시빌 공격](/glossary/#sybil-attack)으로부터 보호하는 합의 메커니즘의 구성 요소일 뿐입니다. 합의 메커니즘은 분산된 노드들이 블록체인의 상태에 동의할 수 있게 해주는 아이디어, 프로토콜 및 인센티브의 전체 스택입니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 [이더리움 소개](/developers/docs/intro-to-ethereum/)를 읽어보시는 것을 추천합니다.
+
+## 합의란 무엇인가요? {#what-is-consensus}
+
+합의를 통해 기본적인 동의가 완료됩니다. 영화관에 가려고 하는 사람들을 사람들을 생각해 봅시다. 같이 보려고 하는 영화에 대해 누구도 거부하지 않는다면 합의가 이루어진 것입니다. 누군가가 거부한다면 사람들은 어떤 영화를 볼 지 정해야 합니다. 심한 경우에는 결국 사람들이 나뉠 수 있습니다.
+
+이더리움 블록체인에서 이 프로세스는 정형화되어 있으며, 합의에 도달한다는 것은 네트워크 노드의 66% 이상이 네트워크의 글로벌 상태에 동의한다는 것을 의미합니다.
+
+## 합의 메커니즘이란 무엇인가요? 합의 메커니즘이란? {#what-is-a-consensus-mechanism}
+
+합의 메커니즘은 노드 네트워크가 블록체인의 상태에 동의할 수 있도록 하는 모든 프로토콜, 인센티브 및 아이디어의 집합체입니다.
+
+이더리움은 지분 증명 기반의 합의 메커니즘을 사용하여 스테이커가 잠근 자본에 적용된 일련의 보상 및 불이익을 통해 암호화폐 경제의 보안을 유지합니다. 이러한 인센티브 구조를 통해 개인 스테이커는 검증자를 정직하게 운영하도록 하고, 그러지 않는 사람에게 불이익을 가하며, 네트워크 공격에 필요한 가격을 극도로 높입니다.
+
+또한, 정직한 검증자가 블록을 제안하거나 검증하도록 선택되는 프로토콜이 있습니다. 드문 상황에서 여러 블록이 체인의 맨 앞에 있는 경우, 포크 선택 메커니즘이 검증자가 지분한 이더 잔액에 따라 블록을 선택합니다.
+
+코드로 명시적으로 정의되지 않은 추가 보안 개념은 네트워크 공격에 대한 마지막 방어 수단으로 작동할 수 있습니다.
+
+이러한 구성 요소들이 합쳐져 합의 메커니즘을 형성합니다.
+
+## 합의 메커니즘의 유형 {#types-of-consensus-mechanisms}
+
+### 작업 증명 기반 {#proof-of-work}
+
+비트코인처럼 이더리움은 한때 **작업 증명(PoW)** 기반 합의 프로토콜을 사용했습니다.
+
+#### 블록 생성 {#pow-block-creation}
+
+채굴자들이 처리된 트랜잭션으로 가득 찬 새 블록을 만들기 위해 경쟁합니다. 승자는 새 블록을 네트워크에 공유하고 새로 발행된 ETH를 얻습니다. 수학 문제를 가장 빠르게 푸는 컴퓨터가 경주에서 이깁니다. 이 과정이 현재 블록과 이전 블록 간의 암호학적 연결을 만듭니다. 이 퍼즐을 푸는 것이 작업 증명에서의 '작업'입니다. 정통 체인은 채굴된 블록에 가장 많은 작업이 들어간 블록 세트를 선택하는 포크 선택 규칙에 의해 결정됩니다.
+
+#### 보안 {#pow-security}
+
+네트워크는 체인을 속이려면 네트워크의 51% 컴퓨팅 파워가 필요하기 때문에 안전하게 유지됩니다. 이 정도의 장비와 에너지를 투자하면 얻는 것보다 더 많은 돈을 쓸 가능성이 큽니다.
+
+[작업 증명](/developers/docs/consensus-mechanisms/pow/)에 대한 자세한 정보
+
+### 지분 증명 기반 {#proof-of-stake}
+
+현재 이더리움은 **지분 증명(PoS)** 기반 합의 프로토콜을 사용합니다.
+
+#### 블록 생성 {#pos-block-creation}
+
+검증자가 블록을 생성합니다. 각 슬롯에서 무작위로 선택된 한 명의 검증자가 블록 제안자가 됩니다. 그들의 합의 클라이언트는 쌍을 이루는 실행 클라이언트에서 '실행 페이로드'로 트랜잭션 번들을 요청합니다. 검증자는 이를 합의 데이터로 감싸 블록을 생성하고, 이를 이더리움 네트워크의 다른 노드에 보냅니다. 이 블록 생성은 ETH로 보상받습니다. 드문 경우지만 여러 가능한 블록이 존재할 경우, 포크 선택 알고리즘은 가장 많은 검증자의 지지를 받은 블록을 선택합니다.
+
+#### 보안 {#pos-security}
+
+지분 증명 시스템은 경제적으로 안전합니다. 공격자가 체인을 장악하려면 막대한 양의 ETH를 잃어야 하기 때문입니다. 보상 시스템은 개별 스테이커가 정직하게 행동하도록 인센티브를 제공하며, 처벌은 악의적 행동을 억제합니다.
+
+[지분 증명](/developers/docs/consensus-mechanisms/pos/)에 대한 자세한 정보
+
+### 시각적 가이드 {#types-of-consensus-video}
+
+이더리움에서 사용되는 다양한 합의 메커니즘에 대해 자세히 알아보세요.
+
+
+
+
+ 작업 증명은 이제 더 이상 사용되지 않습니다. 이더리움은 더 이상 작업 증명을 합의 메커니즘으로 사용하지 않습니다. 대신 지분 증명을 사용합니다. [지분 증명](/developers/docs/consensus-mechanisms/pos/) 및 [스테이킹](/staking/)에 대해 자세히 알아보세요.
+
+
+
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 [트랜잭션](/developers/docs/transactions/), [블록](/developers/docs/blocks/), [합의 메커니즘](/developers/docs/consensus-mechanisms/)에 대해 읽어보시는 것을 추천합니다.
+
+## 작업 증명(Proof-of-Work, PoW)이란 무엇입니까? {#what-is-pow}
+
+작업 증명을 활용하는 나카모토 합의는 한때 탈중앙화된 이더리움 네트워크가 계정 잔액 및 트랜잭션 순서와 같은 사항에 대해 합의(즉, 모든 노드가 동의)에 도달할 수 있도록 한 메커니즘이었습니다. 이는 사용자가 자신이 소유한 코인을 "이중 지출"하는 것을 방지하고, 이더리움 체인이 공격이나 조작이 매우 어려워지도록 보장했습니다. 이러한 보안 속성은 이제 [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)로 알려진 합의 메커니즘을 사용하는 지분 증명에서 비롯됩니다.
+
+## 작업 증명과 채굴 {#pow-and-mining}
+
+작업 증명은 작업 증명 블록체인에서 채굴자들이 수행하는 작업의 난이도와 규칙을 설정하는 기본 알고리즘입니다. 채굴은 그 "작업" 자체입니다. 채굴은 유효한 블록을 체인에 추가하는 행위입니다. 이는 체인의 길이가 네트워크가 블록체인의 올바른 포크를 따르는 데 중요한 역할을 하기 때문입니다. 더 많은 "작업"이 수행될수록 체인은 더 길어지며, 블록 번호가 높아지고, 네트워크는 현재 상태에 대한 확신을 더 가질 수 있습니다.
+
+[채굴에 대한 자세한 정보](/developers/docs/consensus-mechanisms/pow/mining/)
+
+## 이더리움의 작업 증명은 어떻게 작동했습니까? {#how-it-works}
+
+이더리움 트랜잭션은 블록에 처리됩니다. 이제 더 이상 사용되지 않는 작업 증명 기반 이더리움에서 각 블록은 다음을 포함했습니다:
+
+- 블록 난이도 – 예시: 3,324,092,183,262,715
+- mixHash – 예시: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29`
+- nonce – 예시: `0xd3ee432b4fb3d26b`
+
+이 블록 데이터는 작업 증명과 직접적으로 관련이 있었습니다.
+
+### 작업 증명에서의 '작업' {#the-work}
+
+작업 증명 프로토콜인 Ethash는 채굴자들이 블록의 논스를 찾기 위해 강렬한 시도와 실패 과정을 거쳐야 했습니다. 유효한 논스를 가진 블록만 체인에 추가될 수 있었습니다.
+
+블록을 생성하는 과정에서 채굴자는 전체 체인을 다운로드하고 실행하여 얻을 수 있는 데이터 세트를 반복적으로 수학적 함수에 넣었습니다. 이 데이터 세트는 블록 난이도가 지시하는 목표 아래의 믹스해시를 생성하는 데 사용되었습니다. 이를 해결하는 가장 좋은 방법은 시행착오를 통한 것입니다.
+
+난이도가 해시 목표를 결정했습니다. 목표가 낮을수록 유효한 해시 집합이 작아집니다. 생성되면 다른 채굴자와 클라이언트가 이를 확인하는 것이 매우 쉬웠습니다. 하나의 트랜잭션이 변경되더라도 해시는 완전히 달라져 사기를 나타냅니다.
+
+해싱은 사기를 쉽게 발견하게 만듭니다. 그러나 작업 증명 과정은 체인을 공격하는 데 큰 방해 요소였습니다.
+
+### 작업 증명과 보안 {#security}
+
+채굴자들은 이더리움 메인 체인에서 이 작업을 수행할 인센티브를 받았습니다. 일부 채굴자가 독자적인 체인을 시작할 인센티브는 거의 없었습니다. 이는 시스템을 약화시킵니다. 블록체인은 진실의 원천으로서 단일 상태를 유지하는 것에 의존합니다.
+
+작업 증명의 목표는 체인을 확장하는 것이었습니다. 가장 긴 체인이 유효한 것으로 여겨졌습니다. 왜냐하면 그것을 생성하기 위해 가장 많은 계산 작업이 이루어졌기 때문입니다. 이더리움의 작업 증명 시스템 내에서는 트랜잭션을 삭제하거나 가짜 블록을 만들거나 두 번째 체인을 유지하는 것이 거의 불가능했습니다. 그 이유는 악의적인 채굴자가 항상 다른 사람들보다 더 빨리 블록 논스를 풀어야 했기 때문입니다.
+
+악의적인 채굴자가 일관되게 악의적인 유효 블록을 만들기 위해서는 네트워크 채굴 파워의 51% 이상이 필요했습니다. 그만큼의 "작업"에는 많은 비용이 드는 컴퓨팅 파워가 필요하며, 소모된 에너지가 공격으로 얻은 이익을 초과할 수도 있었습니다.
+
+### 작업 증명 경제학 {#economics}
+
+작업 증명은 또한 시스템에 새로운 화폐를 발행하고 채굴자들이 일을 하도록 인센티브를 제공했습니다.
+
+[콘스탄티노플 업그레이드](/ethereum-forks/#constantinople) 이후, 블록을 성공적으로 생성한 채굴자들은 새로 발행된 ETH 2개와 트랜잭션 수수료의 일부를 보상으로 받았습니다. 오머 블록은 또한 1.75 ETH를 보상받았습니다. 오머 블록은 다른 채굴자가 표준 블록을 생성한 것과 거의 동시에 생성된 유효한 블록이었으며, 결국 어떤 체인이 먼저 구축되었는지에 따라 결정되었습니다. 오머 블록은 주로 네트워크 지연으로 인해 발생했습니다.
+
+## 최종 승인 {#finality}
+
+트랜잭션은 변경될 수 없는 블록의 일부가 될 때 이더리움에서 "최종성"을 갖습니다.
+
+채굴자들이 분산된 방식으로 작업했기 때문에 두 개의 유효한 블록이 동시에 채굴될 수 있었습니다. 이는 일시적인 포크를 만듭니다. 결국, 후속 블록이 채굴되어 체인에 추가되면서 이 체인들 중 하나가 더 길어져서 승인된 체인이 됩니다.
+
+상황을 더 복잡하게 만드는 것은 임시 포크에서 거부된 트랜잭션이 승인된 체인에 포함되지 않았을 수 있다는 것입니다. 이는 되돌려질 수 있음을 의미합니다. 따라서 최종성은 트랜잭션이 되돌릴 수 없다고 간주하기 전에 기다려야 하는 시간을 나타냅니다. 이전의 작업 증명 이더리움에서는 특정 블록 `N` 위에 더 많은 블록이 채굴될수록 `N`의 트랜잭션이 성공적이며 되돌려지지 않을 것이라는 확신이 높아졌습니다. 이제 지분 증명에서는 블록의 최종성이 확률적 특성이 아니라 명시적 특성입니다.
+
+## 작업 증명의 에너지 사용량 {#energy}
+
+작업 증명에 대한 주요 비판은 네트워크를 안전하게 유지하는 데 필요한 에너지 소비량입니다. 보안과 탈중앙화를 유지하기 위해 작업 증명 방식의 이더리움은 많은 에너지를 소비했습니다. 지분 증명으로 전환하기 직전, 이더리움 채굴자들은 연간 약 70TWh(체코 공화국과 거의 같은 수준 - 2022년 7월 18일 [digiconomist](https://digiconomist.net/)에 따르면)를 집단적으로 소비하고 있었습니다.
+
+## 장단점 {#pros-and-cons}
+
+| 장점 | 단점 |
+| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
+| 작업 증명은 중립적입니다. 시작할 때 ETH가 필요하지 않으며, 블록 보상을 통해 0ETH에서 긍정적인 잔고로 전환할 수 있습니다. [지분 증명](/developers/docs/consensus-mechanisms/pos/)을 사용하려면 시작하기 위해 ETH가 필요합니다. | 작업 증명은 너무 많은 에너지를 소모하여 환경에 해롭습니다. |
+| 작업 증명은 오랜 시간 동안 비트코인과 이더리움을 안전하고 탈중앙화된 상태로 유지한 입증된 합의 메커니즘입니다. | 채굴을 하려면 매우 특수한 장비가 필요하므로 초기 비용이 많이 듭니다. |
+| 지분증명과 비교했을 때 구현이 상대적으로 쉽습니다. | 필요한 계산량이 증가함에 따라, 채굴 풀들이 채굴 경쟁에서 우위를 점할 수 있으며, 이로 인해 중앙 집중화와 보안 위험이 발생할 수 있습니다. |
+
+## 지분 증명과의 비교 {#compared-to-pos}
+
+높은 수준에서 지분증명은 작업증명과 동일한 최종 목표를 가지고 있습니다: 분산 네트워크가 안전하게 합의에 도달하도록 돕는 것입니다. 그러나 프로세스와 참여자 측면에서 몇 가지 차이점이 있습니다:
+
+- 지분증명은 계산 능력의 중요성을 스테이킹된 ETH로 대체합니다.
+- 지분증명은 채굴자를 검증자로 대체합니다. 검증자는 자신의 ETH를 스테이킹하여 새 블록을 생성할 수 있는 능력을 활성화합니다.
+- 최종성은 더 명확해졌습니다: 특정 체크포인트에서 2/3의 검증자가 블록 상태에 동의하면 최종으로 간주됩니다.
+- 검증자는 전액을 걸어야 하므로, 나중에 결탁하려고 하면 전액을 잃게 됩니다. 검증자는 전체 스테이크를 걸어야 하며, 만약 나중에 공모를 시도한다면 전체 스테이크를 잃게 됩니다.
+
+[지분 증명에 대한 자세한 정보](/developers/docs/consensus-mechanisms/pos/)
+
+## 시각 자료를 찾고 있나요? 시각적 학습자
+
+
+
+
+작업증명은 더 이상 이더리움의 합의 메커니즘의 기초가 아니며, 채굴이 중단되었습니다. 대신, 이더리움은 ETH를 스테이킹하는 검증자에 의해 보안이 유지됩니다. 오늘부터 ETH 스테이킹을 시작할 수 있습니다. 더 알아보려면 The Merge, 지분증명, 그리고 스테이킹에 대해 읽어보세요. 이 페이지는 역사적인 참고만을 위한 것입니다.
+
+
+
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 [트랜잭션](/developers/docs/transactions/), [블록](/developers/docs/blocks/) 및 [작업 증명](/developers/docs/consensus-mechanisms/pow/)에 대해 읽어보는 것을 권장합니다.
+
+## 이더리움 채굴이란 무엇인가요? {#what-is-ethereum-mining}
+
+채굴은 더 이상 이더리움의 작업증명 아키텍처에서 블록체인에 추가할 트랜잭션 블록을 생성하는 과정입니다.
+
+채굴이라는 단어는 암호화폐에 대한 금 비유에서 유래했습니다. 금이나 귀금속은 희소하듯이 디지털 토큰도 마찬가지이며, 작업증명 시스템에서는 채굴을 통해서만 총 발행량을 늘릴 수 있습니다. 작업증명 이더리움에서 유일한 발행 방법은 채굴을 통한 것이었습니다. 그러나 금이나 귀금속과 달리, 이더리움 채굴은 또한 블록체인에서 블록을 생성하고, 검증하고, 발표하며, 전파하는 방식으로 네트워크를 보안하는 방법이었습니다.
+
+이더 채굴은 네트워크 보안과 같습니다.
+
+채굴은 작업증명 블록체인의 핵심입니다. 이더리움 채굴자 - 소프트웨어를 실행하는 컴퓨터 - 는 이더리움이 지분증명으로 전환되기 전까지 트랜잭션을 처리하고 블록을 생성하기 위해 시간과 컴퓨팅 자원을 사용했습니다.
+
+## 채굴자는 왜 존재하나요? {#why-do-miners-exist}
+
+이더리움과 같은 분산 시스템에서는 모든 사람들이 트랜잭션 순서에 동의하는지 확인해야 합니다. 채굴자는 계산적으로 어려운 퍼즐을 풀어 블록을 생성함으로써 이 과정이 이루어지도록 돕고, 네트워크를 공격으로부터 보호했습니다.
+
+[작업 증명에 대해 더 알아보기](/developers/docs/consensus-mechanisms/pow/)
+
+이전에는 누구나 자신의 컴퓨터로 이더리움 네트워크에서 채굴을 할 수 있었습니다. 그러나 모든 사람들이 ETH(이더)를 수익성 있게 채굴할 수 있는 것은 아니었습니다. 대부분의 경우, 채굴자는 전용 컴퓨터 하드웨어를 구입하고, 저렴한 에너지원을 이용해야 했습니다. 일반적인 컴퓨터로는 채굴에 필요한 블록 보상을 얻어 채굴 비용을 충당하기 어렵습니다.
+
+### 채굴 비용 {#cost-of-mining}
+
+- 채굴 장비를 구축하고 유지하는 데 필요한 하드웨어의 잠재적 비용
+- 채굴 장비를 운영하는 데 필요한 전기 비용
+- 채굴 풀에서 채굴하는 경우, 이러한 풀은 일반적으로 생성된 블록의 일정 비율을 수수료로 부과했습니다.
+- 채굴 장비를 지원하기 위한 장비 비용(환기 장치, 에너지 모니터링, 전기 배선 등)
+
+채굴 수익성을 더 자세히 알아보려면 [Etherscan](https://etherscan.io/ether-mining-calculator)에서 제공하는 채굴 계산기를 사용하세요.
+
+## 이더리움 트랜잭션 채굴 방법 {#how-ethereum-transactions-were-mined}
+
+다음은 이더리움 작업증명에서 트랜잭션이 어떻게 채굴되었는지에 대한 개요를 제공합니다. 이더리움 지분 증명 과정에 대한 유사한 설명은 [여기](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos)에서 확인할 수 있습니다.
+
+1. 사용자는 일부 [계정](/developers/docs/accounts/)의 개인 키를 사용하여 [트랜잭션](/developers/docs/transactions/) 요청을 작성하고 서명합니다.
+2. 사용자는 특정 [노드](/developers/docs/nodes-and-clients/)에서 전체 이더리움 네트워크로 트랜잭션 요청을 브로드캐스트합니다.
+3. 이더리움 네트워크의 각 노드는 새로운 트랜잭션 요청에 대해 듣게 되면 해당 요청을 로컬 메모리 풀에 추가합니다. 이 목록은 아직 블록체인에 블록으로 기록되지 않은 모든 트랜잭션 요청을 포함합니다.
+4. 어느 시점에서 채굴 노드는 블록 가스 한도 내에서 획득하는 [거래 수수료](/developers/docs/gas/)를 최대화하는 방식으로 수십 또는 수백 개의 트랜잭션 요청을 잠재적 [블록](/developers/docs/blocks/)으로 집계합니다. 그 다음 채굴 노드는:
+ 1. 각 트랜잭션 요청의 유효성을 검증합니다(예: 서명이 없는 계정에서 이더를 전송하려 하지 않음, 요청이 올바르지 않음 등). 그런 다음 요청의 코드를 실행하여 로컬 EVM 복사본의 상태를 변경합니다. 채굴자는 각 트랜잭션 요청에 대한 수수료를 자신의 계정에 부여합니다.
+ 2. 블록 내의 모든 트랜잭션 요청이 검증되고 로컬 EVM 복사본에서 실행되면 잠재적인 블록에 대한 작업 증명 "합법성 증명서"를 생성하는 과정을 시작합니다.
+5. 결국, 채굴자는 특정 트랜잭션 요청을 포함하는 블록에 대한 증명서를 완성하게 됩니다. 그 다음 채굴자는 새로 주장된 EVM 상태의 증명서와 체크섬을 포함하는 완료된 블록을 브로드캐스트합니다.
+6. 다른 노드들은 새로운 블록에 대해 듣게 됩니다. 그들은 인증서를 확인하고, 블록 내 모든 트랜잭션을 직접 실행하며(사용자가 원래 전송한 트랜잭션 포함), 모든 트랜잭션을 실행한 후 새 EVM 상태의 체크섬이 채굴자가 제시한 블록의 상태 체크섬과 일치하는지 확인합니다. 그런 다음 이 노드들은 이 블록을 블록체인의 마지막에 추가하고, 새로운 EVM 상태를 표준 상태로 받아들입니다.
+7. 각 노드는 새 블록에 있는 모든 트랜잭션을 자신들의 미완료 트랜잭션 요청 메모리 풀에서 제거합니다.
+8. 네트워크에 새로 참여하는 노드들은 모든 블록을 순차적으로 다운로드하며, 여기에는 우리가 관심을 가지는 트랜잭션이 포함된 블록도 있습니다. 그들은 로컬 EVM 사본을 초기화한 후(빈 상태의 EVM으로 시작), 로컬 EVM 사본에서 각 블록의 상태 체크섬을 확인하면서 모든 블록의 트랜잭션을 실행합니다.
+
+모든 트랜잭션은 한 번 채굴되지만(새 블록에 포함되고 처음 전파됨), 표준 EVM 상태를 갱신하는 과정에서 모든 참가자가 트랜잭션을 실행하고 검증합니다. 이는 블록체인의 핵심 원칙 중 하나인 '신뢰하지 말고 검증하라'를 강조합니다.
+
+## 옴머(엉클) 블록 {#ommer-blocks}
+
+작업 증명(Proof-of-Work)에서 블록 채굴은 확률적이었으며, 네트워크 지연으로 인해 때때로 두 개의 유효한 블록이 동시에 게시되었습니다. 이 경우, 프로토콜은 가장 긴(따라서 가장 "유효한") 체인을 결정해야 했으며, 포함되지 않은 유효한 블록을 제안한 채굴자에게 부분적으로 보상하여 공정성을 유지했습니다. 이는 지연 시간이 더 길어질 수 있는 소규모 채굴자들이 [옴머](/glossary/#ommer) 블록 보상을 통해 계속해서 수익을 창출할 수 있게 하여 네트워크의 탈중앙화를 더욱 촉진했습니다.
+
+"옴머"라는 용어는 부모 블록의 형제 블록에 대한 성 중립적인 용어로 선호되지만, 때때로 "uncle"로도 불립니다. **이더리움이 지분 증명으로 전환된 이후에는 각 슬롯에서 단 한 명의 제안자만 선출되므로 옴머 블록은 더 이상 채굴되지 않습니다.** 채굴된 옴머 블록의 [과거 차트](https://ycharts.com/indicators/ethereum_uncle_rate)를 보면 이러한 변화를 확인할 수 있습니다.
+
+## 시각적 데모 {#a-visual-demo}
+
+오스틴이 작업 증명 블록체인을 채굴하는 과정을 안내하는 영상을 시청하세요.
+
+xᵐ mod P ≡ 1
인 최소 `m`으로 정의됩니다.
+이러한 정의가 주어지면 다음과 같습니다.
+
+> 관찰 1. 안전 소수 `P`에 대해 `x`를 곱셈 그룹 `ℤ/Pℤ`의 멤버라고 합시다. 만약 `x mod P ≠ 1 mod P`이고 `x mod P ≠ P-1 mod P`이면, `x`의 위수는 `P-1` 또는 `(P-1)/2`입니다.
+
+_증명_. `P`가 안전 소수이므로 [라그랑주의 정리][lagrange]에 따라 `x`의 위수는 `1`, `2`, `(P-1)/2` 또는 `P-1` 중 하나입니다.
+
+`x`의 위수는 `1`이 될 수 없습니다. 페르마의 소정리에 따르면 다음과 같습니다.
+
+xP-1 mod P ≡ 1
+
+따라서 `x`는 `ℤ/nℤ`의 곱셈 항등원이어야 하며, 이는 유일합니다. 가정에 따라 `x ≠ 1`이라고 가정했으므로 이는 불가능합니다.
+
+`x`의 위수는 `x = P-1`이 아닌 한 `2`가 될 수 없습니다. 이는 `P`가 소수라는 사실에 위배되기 때문입니다.
+
+위의 명제로부터 `(picker * init) % P`를 반복하면 최소 `(P-1)/2`의 주기 길이를 가질 것임을 알 수 있습니다. 이는 우리가 `P`를 2의 거듭제곱에 가까운 안전 소수로 선택했고, `init`이 `[2,2**256+1]` 구간에 있기 때문입니다. `P`의 크기를 고려할 때, 모듈러 지수화에서 주기가 발생할 것으로 예상해서는 안 됩니다.
+
+DAG의 첫 번째 셀(변수 `init`)을 할당할 때, `pow(sha3(seed) + 2, 3, P)`를 계산합니다. 언뜻 보기에 이것은 결과가 `1`도 아니고 `P-1`도 아니라는 것을 보장하지 않습니다. 그러나 `P-1`이 안전 소수이므로, 관찰 1의 따름정리인 다음과 같은 추가적인 보장을 얻을 수 있습니다.
+
+> 관찰 2. 안전 소수 `P`에 대해 `x`를 곱셈 그룹 `ℤ/Pℤ`의 멤버라고 하고, `w`를 자연수라고 합시다. 만약 `x mod P ≠ 1 mod P`이고 `x mod P ≠ P-1 mod P`이며, `w mod P ≠ P-1 mod P`이고 `w mod P ≠ 0 mod P`이면, `xʷ mod P ≠ 1 mod P`이고 `xʷ mod P ≠ P-1 mod P`입니다.
+
+### 해시 함수로서의 모듈러 지수화 {#modular-exponentiation}
+
+특정 `P`와 `w` 값에 대해, `pow(x, w, P)` 함수는 많은 충돌을 가질 수 있습니다. 예를 들어, `pow(x,9,19)`는 `{1,18}` 값만 가집니다.
+
+`P`가 소수라는 점을 감안할 때, 모듈러 지수 해싱 함수에 적합한 `w`는 다음 결과를 사용하여 선택할 수 있습니다.
+
+> 관찰 3. `P`를 소수라고 할 때, `w`와 `P-1`이 서로소인 것은, `ℤ/Pℤ`에 있는 모든 `a`와 `b`에 대해 `aʷ mod P ≡ bʷ mod P`인 것이 `a mod P ≡ b mod P`인 것과 동치 라는 것입니다.
+
+따라서 `P`가 소수이고 `w`가 `P-1`과 서로소일 때, `|{pow(x, w, P) : x ∈ ℤ}| = P`가 성립하며, 이는 해싱 함수가 가능한 최소 충돌률을 가짐을 의미합니다.
+
+우리가 선택한 것처럼 `P`가 안전 소수인 특수한 경우, `P-1`은 1, 2, `(P-1)/2`, `P-1`만을 인수로 가집니다. `P` > 7이므로, 3은 `P-1`과 서로소이며, 따라서 `w=3`은 위 명제를 만족합니다.
+
+## 보다 효율적인 캐시 기반 평가 알고리즘 {#cache-based-evaluation}
+
+```python
+def quick_calc(params, seed, p):
+ cache = produce_dag(params, seed, params["cache_size"])
+ return quick_calc_cached(cache, params, p)
+
+def quick_calc_cached(cache, params, p):
+ P = params["P"]
+ if p < len(cache):
+ return cache[p]
+ else:
+ x = pow(cache[0], p + 1, P)
+ for _ in range(params["k"]):
+ x ^= quick_calc_cached(cache, params, x % p)
+ return pow(x, params["w"], P)
+
+def quick_hashimoto(seed, dagsize, params, header, nonce):
+ cache = produce_dag(params, seed, params["cache_size"])
+ return quick_hashimoto_cached(cache, dagsize, params, header, nonce)
+
+def quick_hashimoto_cached(cache, dagsize, params, header, nonce):
+ m = dagsize // 2
+ mask = 2**64 - 1
+ mix = sha3(encode_int(nonce) + header)
+ for _ in range(params["accesses"]):
+ mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m)
+ return dbl_sha3(mix)
+```
diff --git a/public/content/translations/ko/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/ko/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
new file mode 100644
index 00000000000..726c6954af0
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
@@ -0,0 +1,1022 @@
+---
+title: Ethash
+description: "이더해시 알고리즘 자세히 살펴보기."
+lang: ko
+---
+
+
+
+
+ Ethash는 이더리움의 작업 증명 채굴 알고리즘이었습니다. 이제 작업 증명은 완전히 중단되었으며, 대신 [지분 증명](/developers/docs/consensus-mechanisms/pos/)을 사용하여 이더리움을 보호합니다. [병합](/roadmap/merge/), [지분 증명](/developers/docs/consensus-mechanisms/pos/), [스테이킹](/staking/)에 대해 자세히 알아보세요. 이 페이지는 역사적 참고 자료로만 제공됩니다!
+
+
+
+
+이더해시는 [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) 알고리즘의 수정된 버전입니다. 이더해시 작업 증명은 [메모리 집약적](https://wikipedia.org/wiki/Memory-hard_function)이며, 이는 이 알고리즘을 ASIC 저항적으로 만든다고 여겨졌습니다. 결국 이더해시 ASIC가 개발되었지만, 작업 증명이 중단될 때까지 GPU 채굴은 여전히 실행 가능한 옵션이었습니다. 이더해시는 이더리움이 아닌 다른 작업 증명 네트워크에서 다른 코인을 채굴하는 데 여전히 사용됩니다.
+
+## 이더해시는 어떻게 작동하나요? {#how-does-ethash-work}
+
+메모리 집약성은 nonce 및 블록 헤더에 따라 고정된 리소스의 하위 집합을 선택해야 하는 작업 증명 알고리즘을 통해 달성됩니다. 이 리소스(크기는 수 기가바이트)를 DAG라고 합니다. DAG는 30,000 블록마다 변경되며, 에폭(약 5.2일)이라고 하는 약 125시간의 기간이며 생성하는 데 시간이 걸립니다. DAG는 블록 높이에만 의존하기 때문에 사전 생성이 가능하지만, 그렇지 않은 경우 클라이언트는 블록을 생성하기 위해 이 프로세스가 끝날 때까지 기다려야 합니다. 클라이언트가 미리 DAG를 생성하여 캐시하지 않으면 각 에폭 전환 시 네트워크에 엄청난 블록 지연이 발생할 수 있습니다. 작업 증명을 검증하기 위해 DAG를 생성할 필요가 없으므로 낮은 CPU와 적은 메모리로도 검증이 가능합니다.
+
+알고리즘이 따르는 일반적인 경로는 다음과 같습니다.
+
+1. 각 블록의 헤더를 해당 지점까지 스캔하여 계산할 수 있는 시드가 존재합니다.
+2. 시드에서 16MB 의사 난수 캐시를 계산할 수 있습니다. 라이트 클라이언트는 캐시를 저장합니다.
+3. 캐시에서 1GB 데이터세트를 생성할 수 있으며, 데이터세트의 각 항목은 캐시의 적은 수의 항목에만 종속된다는 속성이 있습니다. 풀 클라이언트와 채굴자는 데이터세트를 저장합니다. 데이터세트는 시간에 따라 선형적으로 증가합니다.
+4. 채굴에는 데이터세트의 무작위 슬라이스를 가져와 함께 해싱하는 작업이 포함됩니다. 캐시를 사용하여 필요한 데이터세트의 특정 부분을 재생성하여 적은 메모리로 검증할 수 있으므로 캐시만 저장하면 됩니다.
+
+대용량 데이터세트는 30,000 블록마다 한 번씩 업데이트되므로, 채굴자 노력의 대부분은 데이터세트를 변경하는 것이 아니라 읽는 데 사용됩니다.
+
+## 정의 {#definitions}
+
+다음과 같은 정의를 사용합니다.
+
+```
+WORD_BYTES = 4 # 워드의 바이트
+DATASET_BYTES_INIT = 2**30 # 제네시스의 데이터세트 바이트
+DATASET_BYTES_GROWTH = 2**23 # 에폭당 데이터세트 증가량
+CACHE_BYTES_INIT = 2**24 # 제네시스의 캐시 바이트
+CACHE_BYTES_GROWTH = 2**17 # 에폭당 캐시 증가량
+CACHE_MULTIPLIER=1024 # 캐시에 대한 DAG의 크기
+EPOCH_LENGTH = 30000 # 에폭당 블록 수
+MIX_BYTES = 128 # 믹스 너비
+HASH_BYTES = 64 # 해시 길이(바이트)
+DATASET_PARENTS = 256 # 각 데이터세트 요소의 부모 수
+CACHE_ROUNDS = 3 # 캐시 생성 라운드 수
+ACCESSES = 64 # 해시모토 루프의 액세스 수
+```
+
+### 'SHA3'의 사용 {#sha3}
+
+이더리움 개발은 SHA3 표준 개발과 동시에 이루어졌으며,
+표준화 과정에서 최종 해시 알고리즘의 패딩이 늦게 변경되어 이더리움의
+'sha3_256' 및 'sha3_512' 해시는 표준 sha3 해시가 아니라 다른 맥락에서 흔히
+'Keccak-256' 및 'Keccak-512'라고 불리는 변형입니다. 예를 들어 [여기](https://eips.ethereum.org/EIPS/eip-1803), [여기](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), 또는 [여기](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057)의 논의를 참조하세요.
+
+아래 알고리즘 설명에서 'sha3' 해시가 언급되므로 이 점을 유념해 주시기 바랍니다.
+
+## 파라미터 {#parameters}
+
+이더해시의 캐시 및 데이터세트 파라미터는 블록 번호에 따라 달라집니다. 캐시 크기와 데이터세트 크기는 모두 선형적으로 증가하지만, 주기적인 동작으로 이어지는 우발적인 규칙성의 위험을 줄이기 위해 선형적으로 증가하는 임계값보다 낮은 가장 높은 소수를 항상 사용합니다.
+
+```python
+def get_cache_size(block_number):
+ sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH)
+ sz -= HASH_BYTES
+ while not isprime(sz / HASH_BYTES):
+ sz -= 2 * HASH_BYTES
+ return sz
+
+def get_full_size(block_number):
+ sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH)
+ sz -= MIX_BYTES
+ while not isprime(sz / MIX_BYTES):
+ sz -= 2 * MIX_BYTES
+ return sz
+```
+
+데이터세트 및 캐시 크기 값의 표는 부록에 제공됩니다.
+
+## 캐시 생성 {#cache-generation}
+
+이제 캐시를 생성하는 함수를 지정합니다.
+
+```python
+def mkcache(cache_size, seed):
+ n = cache_size // HASH_BYTES
+
+ # 초기 데이터세트를 순차적으로 생성
+ o = [sha3_512(seed)]
+ for i in range(1, n):
+ o.append(sha3_512(o[-1]))
+
+ # randmemohash의 낮은 라운드 버전을 사용
+ for _ in range(CACHE_ROUNDS):
+ for i in range(n):
+ v = o[i][0] % n
+ o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v]))
+
+ return o
+```
+
+캐시 생성 과정은 먼저 32MB의 메모리를 순차적으로 채운 다음, [_엄격한 메모리 집약적 해싱 함수(Strict Memory Hard Hashing Functions)_ (2014)](http://www.hashcash.org/papers/memohash.pdf)에서 Sergio Demian Lerner의 _RandMemoHash_ 알고리즘을 두 번 통과시키는 것을 포함합니다. 출력은 524288개의 64바이트 값 집합입니다.
+
+## 데이터 집계 함수 {#date-aggregation-function}
+
+경우에 따라 XOR의 비결합적 대체물로 [FNV 해시](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function)에서 영감을 받은 알고리즘을 사용합니다. 소수에 차례로 1바이트(옥텟)를 곱하는 FNV-1 사양과 달리, 전체 32비트 입력에 소수를 곱한다는 점에 유의하세요.
+
+```python
+FNV_PRIME = 0x01000193
+
+def fnv(v1, v2):
+ return ((v1 * FNV_PRIME) ^ v2) % 2**32
+```
+
+옐로페이퍼에서는 fnv를 v1\*(FNV_PRIME ^ v2)로 지정하고 있지만, 현재 모든 구현에서는 일관되게 위의 정의를 사용하고 있습니다.
+
+## 전체 데이터세트 계산 {#full-dataset-calculation}
+
+전체 1GB 데이터세트의 각 64바이트 항목은 다음과 같이 계산됩니다.
+
+```python
+def calc_dataset_item(cache, i):
+ n = len(cache)
+ r = HASH_BYTES // WORD_BYTES
+ # 믹스 초기화
+ mix = copy.copy(cache[i % n])
+ mix[0] ^= i
+ mix = sha3_512(mix)
+ # i를 기반으로 하는 많은 무작위 캐시 노드로 fnv 수행
+ for j in range(DATASET_PARENTS):
+ cache_index = fnv(i ^ j, mix[j % r])
+ mix = map(fnv, mix, cache[cache_index % n])
+ return sha3_512(mix)
+```
+
+기본적으로 256개의 의사 난수적으로 선택된 캐시 노드의 데이터를 결합하고 이를 해싱하여 데이터세트 노드를 계산합니다. 그런 다음 전체 데이터세트는 다음에 의해 생성됩니다.
+
+```python
+def calc_dataset(full_size, cache):
+ return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)]
+```
+
+## 메인 루프 {#main-loop}
+
+이제 특정 헤더와 nonce에 대한 최종 값을 생성하기 위해 전체 데이터세트의 데이터를 집계하는 메인 '해시모토'와 유사한 루프를 지정합니다. 아래 코드에서 `header`는 **mixHash** 및 **nonce** 필드를 제외한 _잘린_ 블록 헤더, 즉 RLP 표현의 SHA3-256 해시를 나타냅니다. `nonce`는 빅 엔디안 순서의 64비트 부호 없는 정수의 8바이트입니다. 따라서 `nonce[::-1]`는 해당 값의 8바이트 리틀 엔디안 표현입니다.
+
+```python
+def hashimoto(header, nonce, full_size, dataset_lookup):
+ n = full_size / HASH_BYTES
+ w = MIX_BYTES // WORD_BYTES
+ mixhashes = MIX_BYTES / HASH_BYTES
+ # 헤더+nonce를 64바이트 시드로 결합
+ s = sha3_512(header + nonce[::-1])
+ # 복제된 s로 믹스 시작
+ mix = []
+ for _ in range(MIX_BYTES / HASH_BYTES):
+ mix.extend(s)
+ # 무작위 데이터세트 노드에서 믹스
+ for i in range(ACCESSES):
+ p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
+ newdata = []
+ for j in range(MIX_BYTES / HASH_BYTES):
+ newdata.extend(dataset_lookup(p + j))
+ mix = map(fnv, mix, newdata)
+ # 믹스 압축
+ cmix = []
+ for i in range(0, len(mix), 4):
+ cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3]))
+ return {
+ "mix digest": serialize_hash(cmix),
+ "result": serialize_hash(sha3_256(s+cmix))
+ }
+
+def hashimoto_light(full_size, cache, header, nonce):
+ return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x))
+
+def hashimoto_full(full_size, dataset, header, nonce):
+ return hashimoto(header, nonce, full_size, lambda x: dataset[x])
+```
+
+기본적으로 128바이트 너비의 '믹스'를 유지하고 전체 데이터세트에서 128바이트를 반복적으로 순차적으로 가져와 `fnv` 함수를 사용하여 믹스와 결합합니다. 128바이트의 순차적 액세스는 알고리즘의 각 라운드가 항상 RAM에서 전체 페이지를 가져오도록 하여 이론적으로 ASIC이 피할 수 있는 변환 색인 버퍼(TLB) 누락을 최소화하는 데 사용됩니다.
+
+이 알고리즘의 출력이 원하는 대상보다 낮으면 nonce는 유효합니다. 마지막에 `sha3_256`을 추가로 적용하면 최소한의 작업이 수행되었음을 증명하기 위해 제공할 수 있는 중간 nonce가 존재하도록 보장합니다. 이 빠른 외부 PoW 검증은 안티-DDoS 목적으로 사용될 수 있습니다. 또한 결과가 편향되지 않은 256비트 숫자라는 통계적 보증을 제공하는 역할도 합니다.
+
+## 채굴 {#mining}
+
+채굴 알고리즘은 다음과 같이 정의됩니다.
+
+```python
+def mine(full_size, dataset, header, difficulty):
+ # 동일한 숫자의 해시와 비교하기 위해 대상에 0을 채움
+ target = zpad(encode_int(2**256 // difficulty), 64)[::-1]
+ from random import randint
+ nonce = randint(0, 2**64)
+ while hashimoto_full(full_size, dataset, header, nonce) > target:
+ nonce = (nonce + 1) % 2**64
+ return nonce
+```
+
+## 시드 해시 정의 {#seed-hash}
+
+주어진 블록 위에 채굴하는 데 사용될 시드 해시를 계산하기 위해 다음 알고리즘을 사용합니다.
+
+```python
+ def get_seedhash(block):
+ s = '\x00' * 32
+ for i in range(block.number // EPOCH_LENGTH):
+ s = serialize_hash(sha3_256(s))
+ return s
+```
+
+원활한 채굴 및 검증을 위해 별도의 스레드에서 향후 시드해시 및 데이터세트를 미리 계산하는 것을 권장합니다.
+
+## 더 읽어보기 {#further-reading}
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
+
+## 부록 {#appendix}
+
+위의 파이썬 사양을 코드로 실행하는 데 관심이 있다면 다음 코드를 앞에 추가해야 합니다.
+
+```python
+import sha3, copy
+
+# 리틀 엔디안 비트 순서를 가정합니다 (인텔 아키텍처와 동일)
+def decode_int(s):
+ return int(s[::-1].encode('hex'), 16) if s else 0
+
+def encode_int(s):
+ a = "%x" % s
+ return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1]
+
+def zpad(s, length):
+ return s + '\x00' * max(0, length - len(s))
+
+def serialize_hash(h):
+ return ''.join([zpad(encode_int(x), 4) for x in h])
+
+def deserialize_hash(h):
+ return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)]
+
+def hash_words(h, sz, x):
+ if isinstance(x, list):
+ x = serialize_hash(x)
+ y = h(x)
+ return deserialize_hash(y)
+
+def serialize_cache(ds):
+ return ''.join([serialize_hash(h) for h in ds])
+
+serialize_dataset = serialize_cache
+
+# sha3 해시 함수, 64바이트 출력
+def sha3_512(x):
+ return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x)
+
+def sha3_256(x):
+ return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x)
+
+def xor(a, b):
+ return a ^ b
+
+def isprime(x):
+ for i in range(2, int(x**0.5)):
+ if x % i == 0:
+ return False
+ return True
+```
+
+### 데이터 크기 {#data-sizes}
+
+다음 조회 테이블은 약 2048개의 표로 정리된 데이터 크기 및 캐시 크기의 에폭을 제공합니다.
+
+```python
+def get_datasize(block_number):
+ return data_sizes[block_number // EPOCH_LENGTH]
+
+def get_cachesize(block_number):
+ return cache_sizes[block_number // EPOCH_LENGTH]
+
+data_sizes = [
+1073739904, 1082130304, 1090514816, 1098906752, 1107293056,
+1115684224, 1124070016, 1132461952, 1140849536, 1149232768,
+1157627776, 1166013824, 1174404736, 1182786944, 1191180416,
+1199568512, 1207958912, 1216345216, 1224732032, 1233124736,
+1241513344, 1249902464, 1258290304, 1266673792, 1275067264,
+1283453312, 1291844992, 1300234112, 1308619904, 1317010048,
+1325397376, 1333787776, 1342176128, 1350561664, 1358954368,
+1367339392, 1375731584, 1384118144, 1392507008, 1400897408,
+1409284736, 1417673344, 1426062464, 1434451072, 1442839168,
+1451229056, 1459615616, 1468006016, 1476394112, 1484782976,
+1493171584, 1501559168, 1509948032, 1518337664, 1526726528,
+1535114624, 1543503488, 1551892096, 1560278656, 1568669056,
+1577056384, 1585446272, 1593831296, 1602219392, 1610610304,
+1619000192, 1627386752, 1635773824, 1644164224, 1652555648,
+1660943488, 1669332608, 1677721216, 1686109312, 1694497664,
+1702886272, 1711274624, 1719661184, 1728047744, 1736434816,
+1744829056, 1753218944, 1761606272, 1769995904, 1778382464,
+1786772864, 1795157888, 1803550592, 1811937664, 1820327552,
+1828711552, 1837102976, 1845488768, 1853879936, 1862269312,
+1870656896, 1879048064, 1887431552, 1895825024, 1904212096,
+1912601216, 1920988544, 1929379456, 1937765504, 1946156672,
+1954543232, 1962932096, 1971321728, 1979707264, 1988093056,
+1996487552, 2004874624, 2013262208, 2021653888, 2030039936,
+2038430848, 2046819968, 2055208576, 2063596672, 2071981952,
+2080373632, 2088762752, 2097149056, 2105539712, 2113928576,
+2122315136, 2130700672, 2139092608, 2147483264, 2155872128,
+2164257664, 2172642176, 2181035392, 2189426048, 2197814912,
+2206203008, 2214587264, 2222979712, 2231367808, 2239758208,
+2248145024, 2256527744, 2264922752, 2273312128, 2281701248,
+2290086272, 2298476672, 2306867072, 2315251072, 2323639168,
+2332032128, 2340420224, 2348808064, 2357196416, 2365580416,
+2373966976, 2382363008, 2390748544, 2399139968, 2407530368,
+2415918976, 2424307328, 2432695424, 2441084288, 2449472384,
+2457861248, 2466247808, 2474637184, 2483026816, 2491414144,
+2499803776, 2508191872, 2516582272, 2524970368, 2533359232,
+2541743488, 2550134144, 2558525056, 2566913408, 2575301504,
+2583686528, 2592073856, 2600467328, 2608856192, 2617240448,
+2625631616, 2634022016, 2642407552, 2650796416, 2659188352,
+2667574912, 2675965312, 2684352896, 2692738688, 2701130624,
+2709518464, 2717907328, 2726293376, 2734685056, 2743073152,
+2751462016, 2759851648, 2768232832, 2776625536, 2785017728,
+2793401984, 2801794432, 2810182016, 2818571648, 2826959488,
+2835349376, 2843734144, 2852121472, 2860514432, 2868900992,
+2877286784, 2885676928, 2894069632, 2902451584, 2910843008,
+2919234688, 2927622784, 2936011648, 2944400768, 2952789376,
+2961177728, 2969565568, 2977951616, 2986338944, 2994731392,
+3003120256, 3011508352, 3019895936, 3028287104, 3036675968,
+3045063808, 3053452928, 3061837696, 3070228352, 3078615424,
+3087003776, 3095394944, 3103782272, 3112173184, 3120562048,
+3128944768, 3137339264, 3145725056, 3154109312, 3162505088,
+3170893184, 3179280256, 3187669376, 3196056704, 3204445568,
+3212836736, 3221224064, 3229612928, 3238002304, 3246391168,
+3254778496, 3263165824, 3271556224, 3279944576, 3288332416,
+3296719232, 3305110912, 3313500032, 3321887104, 3330273152,
+3338658944, 3347053184, 3355440512, 3363827072, 3372220288,
+3380608384, 3388997504, 3397384576, 3405774208, 3414163072,
+3422551936, 3430937984, 3439328384, 3447714176, 3456104576,
+3464493952, 3472883584, 3481268864, 3489655168, 3498048896,
+3506434432, 3514826368, 3523213952, 3531603584, 3539987072,
+3548380288, 3556763264, 3565157248, 3573545344, 3581934464,
+3590324096, 3598712704, 3607098752, 3615488384, 3623877248,
+3632265856, 3640646528, 3649043584, 3657430144, 3665821568,
+3674207872, 3682597504, 3690984832, 3699367808, 3707764352,
+3716152448, 3724541056, 3732925568, 3741318016, 3749706368,
+3758091136, 3766481536, 3774872704, 3783260032, 3791650432,
+3800036224, 3808427648, 3816815488, 3825204608, 3833592704,
+3841981568, 3850370432, 3858755968, 3867147904, 3875536256,
+3883920512, 3892313728, 3900702592, 3909087872, 3917478784,
+3925868416, 3934256512, 3942645376, 3951032192, 3959422336,
+3967809152, 3976200064, 3984588416, 3992974976, 4001363584,
+4009751168, 4018141312, 4026530432, 4034911616, 4043308928,
+4051695488, 4060084352, 4068472448, 4076862848, 4085249408,
+4093640576, 4102028416, 4110413696, 4118805632, 4127194496,
+4135583104, 4143971968, 4152360832, 4160746112, 4169135744,
+4177525888, 4185912704, 4194303616, 4202691968, 4211076736,
+4219463552, 4227855488, 4236246656, 4244633728, 4253022848,
+4261412224, 4269799808, 4278184832, 4286578048, 4294962304,
+4303349632, 4311743104, 4320130432, 4328521088, 4336909184,
+4345295488, 4353687424, 4362073472, 4370458496, 4378852736,
+4387238528, 4395630208, 4404019072, 4412407424, 4420790656,
+4429182848, 4437571456, 4445962112, 4454344064, 4462738048,
+4471119232, 4479516544, 4487904128, 4496289664, 4504682368,
+4513068416, 4521459584, 4529846144, 4538232704, 4546619776,
+4555010176, 4563402112, 4571790208, 4580174464, 4588567936,
+4596957056, 4605344896, 4613734016, 4622119808, 4630511488,
+4638898816, 4647287936, 4655675264, 4664065664, 4672451968,
+4680842624, 4689231488, 4697620352, 4706007424, 4714397056,
+4722786176, 4731173248, 4739562368, 4747951744, 4756340608,
+4764727936, 4773114496, 4781504384, 4789894784, 4798283648,
+4806667648, 4815059584, 4823449472, 4831835776, 4840226176,
+4848612224, 4857003392, 4865391488, 4873780096, 4882169728,
+4890557312, 4898946944, 4907333248, 4915722368, 4924110976,
+4932499328, 4940889728, 4949276032, 4957666432, 4966054784,
+4974438016, 4982831488, 4991221376, 4999607168, 5007998848,
+5016386432, 5024763776, 5033164672, 5041544576, 5049941888,
+5058329728, 5066717056, 5075107456, 5083494272, 5091883904,
+5100273536, 5108662144, 5117048192, 5125436032, 5133827456,
+5142215296, 5150605184, 5158993024, 5167382144, 5175769472,
+5184157568, 5192543872, 5200936064, 5209324928, 5217711232,
+5226102656, 5234490496, 5242877312, 5251263872, 5259654016,
+5268040832, 5276434304, 5284819328, 5293209728, 5301598592,
+5309986688, 5318374784, 5326764416, 5335151488, 5343542144,
+5351929472, 5360319872, 5368706944, 5377096576, 5385484928,
+5393871232, 5402263424, 5410650496, 5419040384, 5427426944,
+5435816576, 5444205952, 5452594816, 5460981376, 5469367936,
+5477760896, 5486148736, 5494536832, 5502925952, 5511315328,
+5519703424, 5528089984, 5536481152, 5544869504, 5553256064,
+5561645696, 5570032768, 5578423936, 5586811264, 5595193216,
+5603585408, 5611972736, 5620366208, 5628750464, 5637143936,
+5645528192, 5653921408, 5662310272, 5670694784, 5679082624,
+5687474048, 5695864448, 5704251008, 5712641408, 5721030272,
+5729416832, 5737806208, 5746194304, 5754583936, 5762969984,
+5771358592, 5779748224, 5788137856, 5796527488, 5804911232,
+5813300608, 5821692544, 5830082176, 5838468992, 5846855552,
+5855247488, 5863636096, 5872024448, 5880411008, 5888799872,
+5897186432, 5905576832, 5913966976, 5922352768, 5930744704,
+5939132288, 5947522432, 5955911296, 5964299392, 5972688256,
+5981074304, 5989465472, 5997851008, 6006241408, 6014627968,
+6023015552, 6031408256, 6039796096, 6048185216, 6056574848,
+6064963456, 6073351808, 6081736064, 6090128768, 6098517632,
+6106906496, 6115289216, 6123680896, 6132070016, 6140459648,
+6148849024, 6157237376, 6165624704, 6174009728, 6182403712,
+6190792064, 6199176064, 6207569792, 6215952256, 6224345216,
+6232732544, 6241124224, 6249510272, 6257899136, 6266287744,
+6274676864, 6283065728, 6291454336, 6299843456, 6308232064,
+6316620928, 6325006208, 6333395584, 6341784704, 6350174848,
+6358562176, 6366951296, 6375337856, 6383729536, 6392119168,
+6400504192, 6408895616, 6417283456, 6425673344, 6434059136,
+6442444672, 6450837376, 6459223424, 6467613056, 6476004224,
+6484393088, 6492781952, 6501170048, 6509555072, 6517947008,
+6526336384, 6534725504, 6543112832, 6551500672, 6559888768,
+6568278656, 6576662912, 6585055616, 6593443456, 6601834112,
+6610219648, 6618610304, 6626999168, 6635385472, 6643777408,
+6652164224, 6660552832, 6668941952, 6677330048, 6685719424,
+6694107776, 6702493568, 6710882176, 6719274112, 6727662976,
+6736052096, 6744437632, 6752825984, 6761213824, 6769604224,
+6777993856, 6786383488, 6794770816, 6803158144, 6811549312,
+6819937664, 6828326528, 6836706176, 6845101696, 6853491328,
+6861880448, 6870269312, 6878655104, 6887046272, 6895433344,
+6903822208, 6912212864, 6920596864, 6928988288, 6937377152,
+6945764992, 6954149248, 6962544256, 6970928768, 6979317376,
+6987709312, 6996093824, 7004487296, 7012875392, 7021258624,
+7029652352, 7038038912, 7046427776, 7054818944, 7063207808,
+7071595136, 7079980928, 7088372608, 7096759424, 7105149824,
+7113536896, 7121928064, 7130315392, 7138699648, 7147092352,
+7155479168, 7163865728, 7172249984, 7180648064, 7189036672,
+7197424768, 7205810816, 7214196608, 7222589824, 7230975104,
+7239367552, 7247755904, 7256145536, 7264533376, 7272921472,
+7281308032, 7289694848, 7298088832, 7306471808, 7314864512,
+7323253888, 7331643008, 7340029568, 7348419712, 7356808832,
+7365196672, 7373585792, 7381973888, 7390362752, 7398750592,
+7407138944, 7415528576, 7423915648, 7432302208, 7440690304,
+7449080192, 7457472128, 7465860992, 7474249088, 7482635648,
+7491023744, 7499412608, 7507803008, 7516192384, 7524579968,
+7532967296, 7541358464, 7549745792, 7558134656, 7566524032,
+7574912896, 7583300992, 7591690112, 7600075136, 7608466816,
+7616854912, 7625244544, 7633629824, 7642020992, 7650410368,
+7658794112, 7667187328, 7675574912, 7683961984, 7692349568,
+7700739712, 7709130368, 7717519232, 7725905536, 7734295424,
+7742683264, 7751069056, 7759457408, 7767849088, 7776238208,
+7784626816, 7793014912, 7801405312, 7809792128, 7818179968,
+7826571136, 7834957184, 7843347328, 7851732352, 7860124544,
+7868512384, 7876902016, 7885287808, 7893679744, 7902067072,
+7910455936, 7918844288, 7927230848, 7935622784, 7944009344,
+7952400256, 7960786048, 7969176704, 7977565312, 7985953408,
+7994339968, 8002730368, 8011119488, 8019508096, 8027896192,
+8036285056, 8044674688, 8053062272, 8061448832, 8069838464,
+8078227328, 8086616704, 8095006592, 8103393664, 8111783552,
+8120171392, 8128560256, 8136949376, 8145336704, 8153726848,
+8162114944, 8170503296, 8178891904, 8187280768, 8195669632,
+8204058496, 8212444544, 8220834176, 8229222272, 8237612672,
+8246000768, 8254389376, 8262775168, 8271167104, 8279553664,
+8287944064, 8296333184, 8304715136, 8313108352, 8321497984,
+8329885568, 8338274432, 8346663296, 8355052928, 8363441536,
+8371828352, 8380217984, 8388606592, 8396996224, 8405384576,
+8413772672, 8422161536, 8430549376, 8438939008, 8447326592,
+8455715456, 8464104832, 8472492928, 8480882048, 8489270656,
+8497659776, 8506045312, 8514434944, 8522823808, 8531208832,
+8539602304, 8547990656, 8556378752, 8564768384, 8573154176,
+8581542784, 8589933952, 8598322816, 8606705024, 8615099264,
+8623487872, 8631876992, 8640264064, 8648653952, 8657040256,
+8665430656, 8673820544, 8682209152, 8690592128, 8698977152,
+8707374464, 8715763328, 8724151424, 8732540032, 8740928384,
+8749315712, 8757704576, 8766089344, 8774480768, 8782871936,
+8791260032, 8799645824, 8808034432, 8816426368, 8824812928,
+8833199488, 8841591424, 8849976448, 8858366336, 8866757248,
+8875147136, 8883532928, 8891923328, 8900306816, 8908700288,
+8917088384, 8925478784, 8933867392, 8942250368, 8950644608,
+8959032704, 8967420544, 8975809664, 8984197504, 8992584064,
+9000976256, 9009362048, 9017752448, 9026141312, 9034530688,
+9042917504, 9051307904, 9059694208, 9068084864, 9076471424,
+9084861824, 9093250688, 9101638528, 9110027648, 9118416512,
+9126803584, 9135188096, 9143581312, 9151969664, 9160356224,
+9168747136, 9177134464, 9185525632, 9193910144, 9202302848,
+9210690688, 9219079552, 9227465344, 9235854464, 9244244864,
+9252633472, 9261021824, 9269411456, 9277799296, 9286188928,
+9294574208, 9302965888, 9311351936, 9319740032, 9328131968,
+9336516736, 9344907392, 9353296768, 9361685888, 9370074752,
+9378463616, 9386849408, 9395239808, 9403629184, 9412016512,
+9420405376, 9428795008, 9437181568, 9445570688, 9453960832,
+9462346624, 9470738048, 9479121536, 9487515008, 9495903616,
+9504289664, 9512678528, 9521067904, 9529456256, 9537843584,
+9546233728, 9554621312, 9563011456, 9571398784, 9579788672,
+9588178304, 9596567168, 9604954496, 9613343104, 9621732992,
+9630121856, 9638508416, 9646898816, 9655283584, 9663675776,
+9672061312, 9680449664, 9688840064, 9697230464, 9705617536,
+9714003584, 9722393984, 9730772608, 9739172224, 9747561088,
+9755945344, 9764338816, 9772726144, 9781116544, 9789503872,
+9797892992, 9806282624, 9814670464, 9823056512, 9831439232,
+9839833984, 9848224384, 9856613504, 9865000576, 9873391232,
+9881772416, 9890162816, 9898556288, 9906940544, 9915333248,
+9923721088, 9932108672, 9940496512, 9948888448, 9957276544,
+9965666176, 9974048384, 9982441088, 9990830464, 9999219584,
+10007602816, 10015996544, 10024385152, 10032774016, 10041163648,
+10049548928, 10057940096, 10066329472, 10074717824, 10083105152,
+10091495296, 10099878784, 10108272256, 10116660608, 10125049216,
+10133437312, 10141825664, 10150213504, 10158601088, 10166991232,
+10175378816, 10183766144, 10192157312, 10200545408, 10208935552,
+10217322112, 10225712768, 10234099328, 10242489472, 10250876032,
+10259264896, 10267656064, 10276042624, 10284429184, 10292820352,
+10301209472, 10309598848, 10317987712, 10326375296, 10334763392,
+10343153536, 10351541632, 10359930752, 10368318592, 10376707456,
+10385096576, 10393484672, 10401867136, 10410262144, 10418647424,
+10427039104, 10435425664, 10443810176, 10452203648, 10460589952,
+10468982144, 10477369472, 10485759104, 10494147712, 10502533504,
+10510923392, 10519313536, 10527702656, 10536091264, 10544478592,
+10552867712, 10561255808, 10569642368, 10578032768, 10586423168,
+10594805632, 10603200128, 10611588992, 10619976064, 10628361344,
+10636754048, 10645143424, 10653531776, 10661920384, 10670307968,
+10678696832, 10687086464, 10695475072, 10703863168, 10712246144,
+10720639616, 10729026688, 10737414784, 10745806208, 10754190976,
+10762581376, 10770971264, 10779356288, 10787747456, 10796135552,
+10804525184, 10812915584, 10821301888, 10829692288, 10838078336,
+10846469248, 10854858368, 10863247232, 10871631488, 10880023424,
+10888412032, 10896799616, 10905188992, 10913574016, 10921964672,
+10930352768, 10938742912, 10947132544, 10955518592, 10963909504,
+10972298368, 10980687488, 10989074816, 10997462912, 11005851776,
+11014241152, 11022627712, 11031017344, 11039403904, 11047793024,
+11056184704, 11064570752, 11072960896, 11081343872, 11089737856,
+11098128256, 11106514816, 11114904448, 11123293568, 11131680128,
+11140065152, 11148458368, 11156845696, 11165236864, 11173624192,
+11182013824, 11190402688, 11198790784, 11207179136, 11215568768,
+11223957376, 11232345728, 11240734592, 11249122688, 11257511296,
+11265899648, 11274285952, 11282675584, 11291065472, 11299452544,
+11307842432, 11316231296, 11324616832, 11333009024, 11341395584,
+11349782656, 11358172288, 11366560384, 11374950016, 11383339648,
+11391721856, 11400117376, 11408504192, 11416893568, 11425283456,
+11433671552, 11442061184, 11450444672, 11458837888, 11467226752,
+11475611776, 11484003968, 11492392064, 11500780672, 11509169024,
+11517550976, 11525944448, 11534335616, 11542724224, 11551111808,
+11559500672, 11567890304, 11576277376, 11584667008, 11593056128,
+11601443456, 11609830016, 11618221952, 11626607488, 11634995072,
+11643387776, 11651775104, 11660161664, 11668552576, 11676940928,
+11685330304, 11693718656, 11702106496, 11710496128, 11718882688,
+11727273088, 11735660416, 11744050048, 11752437376, 11760824704,
+11769216128, 11777604736, 11785991296, 11794381952, 11802770048,
+11811157888, 11819548544, 11827932544, 11836324736, 11844713344,
+11853100928, 11861486464, 11869879936, 11878268032, 11886656896,
+11895044992, 11903433088, 11911822976, 11920210816, 11928600448,
+11936987264, 11945375872, 11953761152, 11962151296, 11970543488,
+11978928512, 11987320448, 11995708288, 12004095104, 12012486272,
+12020875136, 12029255552, 12037652096, 12046039168, 12054429568,
+12062813824, 12071206528, 12079594624, 12087983744, 12096371072,
+12104759936, 12113147264, 12121534592, 12129924992, 12138314624,
+12146703232, 12155091584, 12163481216, 12171864704, 12180255872,
+12188643968, 12197034112, 12205424512, 12213811328, 12222199424,
+12230590336, 12238977664, 12247365248, 12255755392, 12264143488,
+12272531584, 12280920448, 12289309568, 12297694592, 12306086528,
+12314475392, 12322865024, 12331253632, 12339640448, 12348029312,
+12356418944, 12364805248, 12373196672, 12381580928, 12389969024,
+12398357632, 12406750592, 12415138432, 12423527552, 12431916416,
+12440304512, 12448692352, 12457081216, 12465467776, 12473859968,
+12482245504, 12490636672, 12499025536, 12507411584, 12515801728,
+12524190592, 12532577152, 12540966272, 12549354368, 12557743232,
+12566129536, 12574523264, 12582911872, 12591299456, 12599688064,
+12608074624, 12616463488, 12624845696, 12633239936, 12641631616,
+12650019968, 12658407296, 12666795136, 12675183232, 12683574656,
+12691960192, 12700350592, 12708740224, 12717128576, 12725515904,
+12733906816, 12742295168, 12750680192, 12759071872, 12767460736,
+12775848832, 12784236928, 12792626816, 12801014656, 12809404288,
+12817789312, 12826181504, 12834568832, 12842954624, 12851345792,
+12859732352, 12868122496, 12876512128, 12884901248, 12893289088,
+12901672832, 12910067584, 12918455168, 12926842496, 12935232896,
+12943620736, 12952009856, 12960396928, 12968786816, 12977176192,
+12985563776, 12993951104, 13002341504, 13010730368, 13019115392,
+13027506304, 13035895168, 13044272512, 13052673152, 13061062528,
+13069446272, 13077838976, 13086227072, 13094613632, 13103000192,
+13111393664, 13119782528, 13128157568, 13136559232, 13144945024,
+13153329536, 13161724288, 13170111872, 13178502784, 13186884736,
+13195279744, 13203667072, 13212057472, 13220445824, 13228832128,
+13237221248, 13245610624, 13254000512, 13262388352, 13270777472,
+13279166336, 13287553408, 13295943296, 13304331904, 13312719488,
+13321108096, 13329494656, 13337885824, 13346274944, 13354663808,
+13363051136, 13371439232, 13379825024, 13388210816, 13396605056,
+13404995456, 13413380224, 13421771392, 13430159744, 13438546048,
+13446937216, 13455326848, 13463708288, 13472103808, 13480492672,
+13488875648, 13497269888, 13505657728, 13514045312, 13522435712,
+13530824576, 13539210112, 13547599232, 13555989376, 13564379008,
+13572766336, 13581154432, 13589544832, 13597932928, 13606320512,
+13614710656, 13623097472, 13631477632, 13639874944, 13648264064,
+13656652928, 13665041792, 13673430656, 13681818496, 13690207616,
+13698595712, 13706982272, 13715373184, 13723762048, 13732150144,
+13740536704, 13748926592, 13757316224, 13765700992, 13774090112,
+13782477952, 13790869376, 13799259008, 13807647872, 13816036736,
+13824425344, 13832814208, 13841202304, 13849591424, 13857978752,
+13866368896, 13874754688, 13883145344, 13891533184, 13899919232,
+13908311168, 13916692096, 13925085056, 13933473152, 13941866368,
+13950253696, 13958643584, 13967032192, 13975417216, 13983807616,
+13992197504, 14000582272, 14008973696, 14017363072, 14025752192,
+14034137984, 14042528384, 14050918016, 14059301504, 14067691648,
+14076083584, 14084470144, 14092852352, 14101249664, 14109635968,
+14118024832, 14126407552, 14134804352, 14143188608, 14151577984,
+14159968384, 14168357248, 14176741504, 14185127296, 14193521024,
+14201911424, 14210301824, 14218685056, 14227067264, 14235467392,
+14243855488, 14252243072, 14260630144, 14269021568, 14277409408,
+14285799296, 14294187904, 14302571392, 14310961792, 14319353728,
+14327738752, 14336130944, 14344518784, 14352906368, 14361296512,
+14369685376, 14378071424, 14386462592, 14394848128, 14403230848,
+14411627392, 14420013952, 14428402304, 14436793472, 14445181568,
+14453569664, 14461959808, 14470347904, 14478737024, 14487122816,
+14495511424, 14503901824, 14512291712, 14520677504, 14529064832,
+14537456768, 14545845632, 14554234496, 14562618496, 14571011456,
+14579398784, 14587789184, 14596172672, 14604564608, 14612953984,
+14621341312, 14629724288, 14638120832, 14646503296, 14654897536,
+14663284864, 14671675264, 14680061056, 14688447616, 14696835968,
+14705228416, 14713616768, 14722003328, 14730392192, 14738784128,
+14747172736, 14755561088, 14763947648, 14772336512, 14780725376,
+14789110144, 14797499776, 14805892736, 14814276992, 14822670208,
+14831056256, 14839444352, 14847836032, 14856222848, 14864612992,
+14872997504, 14881388672, 14889775744, 14898165376, 14906553472,
+14914944896, 14923329664, 14931721856, 14940109696, 14948497024,
+14956887424, 14965276544, 14973663616, 14982053248, 14990439808,
+14998830976, 15007216768, 15015605888, 15023995264, 15032385152,
+15040768384, 15049154944, 15057549184, 15065939072, 15074328448,
+15082715008, 15091104128, 15099493504, 15107879296, 15116269184,
+15124659584, 15133042304, 15141431936, 15149824384, 15158214272,
+15166602368, 15174991232, 15183378304, 15191760512, 15200154496,
+15208542592, 15216931712, 15225323392, 15233708416, 15242098048,
+15250489216, 15258875264, 15267265408, 15275654528, 15284043136,
+15292431488, 15300819584, 15309208192, 15317596544, 15325986176,
+15334374784, 15342763648, 15351151744, 15359540608, 15367929728,
+15376318336, 15384706432, 15393092992, 15401481856, 15409869952,
+15418258816, 15426649984, 15435037568, 15443425664, 15451815296,
+15460203392, 15468589184, 15476979328, 15485369216, 15493755776,
+15502146944, 15510534272, 15518924416, 15527311232, 15535699072,
+15544089472, 15552478336, 15560866688, 15569254528, 15577642624,
+15586031488, 15594419072, 15602809472, 15611199104, 15619586432,
+15627975296, 15636364928, 15644753792, 15653141888, 15661529216,
+15669918848, 15678305152, 15686696576, 15695083136, 15703474048,
+15711861632, 15720251264, 15728636288, 15737027456, 15745417088,
+15753804928, 15762194048, 15770582656, 15778971008, 15787358336,
+15795747712, 15804132224, 15812523392, 15820909696, 15829300096,
+15837691264, 15846071936, 15854466944, 15862855808, 15871244672,
+15879634816, 15888020608, 15896409728, 15904799104, 15913185152,
+15921577088, 15929966464, 15938354816, 15946743424, 15955129472,
+15963519872, 15971907968, 15980296064, 15988684928, 15997073024,
+16005460864, 16013851264, 16022241152, 16030629248, 16039012736,
+16047406976, 16055794816, 16064181376, 16072571264, 16080957824,
+16089346688, 16097737856, 16106125184, 16114514816, 16122904192,
+16131292544, 16139678848, 16148066944, 16156453504, 16164839552,
+16173236096, 16181623424, 16190012032, 16198401152, 16206790528,
+16215177344, 16223567744, 16231956352, 16240344704, 16248731008,
+16257117824, 16265504384, 16273898624, 16282281856, 16290668672,
+16299064192, 16307449216, 16315842176, 16324230016, 16332613504,
+16341006464, 16349394304, 16357783168, 16366172288, 16374561664,
+16382951296, 16391337856, 16399726208, 16408116352, 16416505472,
+16424892032, 16433282176, 16441668224, 16450058624, 16458448768,
+16466836864, 16475224448, 16483613056, 16492001408, 16500391808,
+16508779648, 16517166976, 16525555328, 16533944192, 16542330752,
+16550719616, 16559110528, 16567497088, 16575888512, 16584274816,
+16592665472, 16601051008, 16609442944, 16617832064, 16626218624,
+16634607488, 16642996096, 16651385728, 16659773824, 16668163712,
+16676552576, 16684938112, 16693328768, 16701718144, 16710095488,
+16718492288, 16726883968, 16735272832, 16743661184, 16752049792,
+16760436608, 16768827008, 16777214336, 16785599104, 16793992832,
+16802381696, 16810768768, 16819151744, 16827542656, 16835934848,
+16844323712, 16852711552, 16861101952, 16869489536, 16877876864,
+16886265728, 16894653056, 16903044736, 16911431296, 16919821696,
+16928207488, 16936592768, 16944987776, 16953375616, 16961763968,
+16970152832, 16978540928, 16986929536, 16995319168, 17003704448,
+17012096896, 17020481152, 17028870784, 17037262208, 17045649536,
+17054039936, 17062426496, 17070814336, 17079205504, 17087592064,
+17095978112, 17104369024, 17112759424, 17121147776, 17129536384,
+17137926016, 17146314368, 17154700928, 17163089792, 17171480192,
+17179864192, 17188256896, 17196644992, 17205033856, 17213423488,
+17221811072, 17230198912, 17238588032, 17246976896, 17255360384,
+17263754624, 17272143232, 17280530048, 17288918912, 17297309312,
+17305696384, 17314085504, 17322475136, 17330863744, 17339252096,
+17347640192, 17356026496, 17364413824, 17372796544, 17381190016,
+17389583488, 17397972608, 17406360704, 17414748544, 17423135872,
+17431527296, 17439915904, 17448303232, 17456691584, 17465081728,
+17473468288, 17481857408, 17490247552, 17498635904, 17507022464,
+17515409024, 17523801728, 17532189824, 17540577664, 17548966016,
+17557353344, 17565741184, 17574131584, 17582519168, 17590907008,
+17599296128, 17607687808, 17616076672, 17624455808, 17632852352,
+17641238656, 17649630848, 17658018944, 17666403968, 17674794112,
+17683178368, 17691573376, 17699962496, 17708350592, 17716739968,
+17725126528, 17733517184, 17741898112, 17750293888, 17758673024,
+17767070336, 17775458432, 17783848832, 17792236928, 17800625536,
+17809012352, 17817402752, 17825785984, 17834178944, 17842563968,
+17850955648, 17859344512, 17867732864, 17876119424, 17884511872,
+17892900224, 17901287296, 17909677696, 17918058112, 17926451072,
+17934843776, 17943230848, 17951609216, 17960008576, 17968397696,
+17976784256, 17985175424, 17993564032, 18001952128, 18010339712,
+18018728576, 18027116672, 18035503232, 18043894144, 18052283264,
+18060672128, 18069056384, 18077449856, 18085837184, 18094225792,
+18102613376, 18111004544, 18119388544, 18127781248, 18136170368,
+18144558976, 18152947328, 18161336192, 18169724288, 18178108544,
+18186498944, 18194886784, 18203275648, 18211666048, 18220048768,
+18228444544, 18236833408, 18245220736]
+
+cache_sizes = [
+16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072,
+17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088,
+18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208,
+19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968,
+20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216,
+21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104,
+22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096,
+23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112,
+24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488,
+25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096,
+25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472,
+26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744,
+27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504,
+28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752,
+29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976,
+30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248,
+31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392,
+32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768,
+33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992,
+34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984,
+35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976,
+36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656,
+36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904,
+37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672,
+38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632,
+39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032,
+40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304,
+41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912,
+42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696,
+43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432,
+44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448,
+45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208,
+46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328,
+47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936,
+47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312,
+48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712,
+49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472,
+50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848,
+51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968,
+52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576,
+53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744,
+54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248,
+55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856,
+56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488,
+57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632,
+58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984,
+58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512,
+59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968,
+60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752,
+61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512,
+62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656,
+63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392,
+64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792,
+65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296,
+66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672,
+67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304,
+68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912,
+69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184,
+69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816,
+70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168,
+71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568,
+72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944,
+73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832,
+74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544,
+75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072,
+76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832,
+77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336,
+78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664,
+79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472,
+80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848,
+81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304,
+81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984,
+82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464,
+83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608,
+84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496,
+85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112,
+86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632,
+87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264,
+88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384,
+89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376,
+90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776,
+91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384,
+92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912,
+92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136,
+93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896,
+94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016,
+95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544,
+96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536,
+97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168,
+98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928,
+99352384, 99482816, 99614272, 99745472, 99876416, 100007104,
+100138048, 100267072, 100401088, 100529984, 100662592, 100791872,
+100925248, 101056064, 101187392, 101317952, 101449408, 101580608,
+101711296, 101841728, 101973824, 102104896, 102235712, 102366016,
+102498112, 102628672, 102760384, 102890432, 103021888, 103153472,
+103284032, 103415744, 103545152, 103677248, 103808576, 103939648,
+104070976, 104201792, 104332736, 104462528, 104594752, 104725952,
+104854592, 104988608, 105118912, 105247808, 105381184, 105511232,
+105643072, 105774784, 105903296, 106037056, 106167872, 106298944,
+106429504, 106561472, 106691392, 106822592, 106954304, 107085376,
+107216576, 107346368, 107478464, 107609792, 107739712, 107872192,
+108003136, 108131392, 108265408, 108396224, 108527168, 108657344,
+108789568, 108920384, 109049792, 109182272, 109312576, 109444928,
+109572928, 109706944, 109837888, 109969088, 110099648, 110230976,
+110362432, 110492992, 110624704, 110755264, 110886208, 111017408,
+111148864, 111279296, 111410752, 111541952, 111673024, 111803456,
+111933632, 112066496, 112196416, 112328512, 112457792, 112590784,
+112715968, 112852672, 112983616, 113114944, 113244224, 113376448,
+113505472, 113639104, 113770304, 113901376, 114031552, 114163264,
+114294592, 114425536, 114556864, 114687424, 114818624, 114948544,
+115080512, 115212224, 115343296, 115473472, 115605184, 115736128,
+115867072, 115997248, 116128576, 116260288, 116391488, 116522944,
+116652992, 116784704, 116915648, 117046208, 117178304, 117308608,
+117440192, 117569728, 117701824, 117833024, 117964096, 118094656,
+118225984, 118357312, 118489024, 118617536, 118749632, 118882112,
+119012416, 119144384, 119275328, 119406016, 119537344, 119668672,
+119798464, 119928896, 120061376, 120192832, 120321728, 120454336,
+120584512, 120716608, 120848192, 120979136, 121109056, 121241408,
+121372352, 121502912, 121634752, 121764416, 121895744, 122027072,
+122157632, 122289088, 122421184, 122550592, 122682944, 122813888,
+122945344, 123075776, 123207488, 123338048, 123468736, 123600704,
+123731264, 123861952, 123993664, 124124608, 124256192, 124386368,
+124518208, 124649024, 124778048, 124911296, 125041088, 125173696,
+125303744, 125432896, 125566912, 125696576, 125829056, 125958592,
+126090304, 126221248, 126352832, 126483776, 126615232, 126746432,
+126876608, 127008704, 127139392, 127270336, 127401152, 127532224,
+127663552, 127794752, 127925696, 128055232, 128188096, 128319424,
+128449856, 128581312, 128712256, 128843584, 128973632, 129103808,
+129236288, 129365696, 129498944, 129629888, 129760832, 129892288,
+130023104, 130154048, 130283968, 130416448, 130547008, 130678336,
+130807616, 130939456, 131071552, 131202112, 131331776, 131464384,
+131594048, 131727296, 131858368, 131987392, 132120256, 132250816,
+132382528, 132513728, 132644672, 132774976, 132905792, 133038016,
+133168832, 133299392, 133429312, 133562048, 133692992, 133823296,
+133954624, 134086336, 134217152, 134348608, 134479808, 134607296,
+134741056, 134872384, 135002944, 135134144, 135265472, 135396544,
+135527872, 135659072, 135787712, 135921472, 136052416, 136182848,
+136313792, 136444864, 136576448, 136707904, 136837952, 136970048,
+137099584, 137232064, 137363392, 137494208, 137625536, 137755712,
+137887424, 138018368, 138149824, 138280256, 138411584, 138539584,
+138672832, 138804928, 138936128, 139066688, 139196864, 139328704,
+139460032, 139590208, 139721024, 139852864, 139984576, 140115776,
+140245696, 140376512, 140508352, 140640064, 140769856, 140902336,
+141032768, 141162688, 141294016, 141426496, 141556544, 141687488,
+141819584, 141949888, 142080448, 142212544, 142342336, 142474432,
+142606144, 142736192, 142868288, 142997824, 143129408, 143258944,
+143392448, 143523136, 143653696, 143785024, 143916992, 144045632,
+144177856, 144309184, 144440768, 144570688, 144701888, 144832448,
+144965056, 145096384, 145227584, 145358656, 145489856, 145620928,
+145751488, 145883072, 146011456, 146144704, 146275264, 146407232,
+146538176, 146668736, 146800448, 146931392, 147062336, 147193664,
+147324224, 147455936, 147586624, 147717056, 147848768, 147979456,
+148110784, 148242368, 148373312, 148503232, 148635584, 148766144,
+148897088, 149028416, 149159488, 149290688, 149420224, 149551552,
+149683136, 149814976, 149943616, 150076352, 150208064, 150338624,
+150470464, 150600256, 150732224, 150862784, 150993088, 151125952,
+151254976, 151388096, 151519168, 151649728, 151778752, 151911104,
+152042944, 152174144, 152304704, 152435648, 152567488, 152698816,
+152828992, 152960576, 153091648, 153222976, 153353792, 153484096,
+153616192, 153747008, 153878336, 154008256, 154139968, 154270912,
+154402624, 154533824, 154663616, 154795712, 154926272, 155057984,
+155188928, 155319872, 155450816, 155580608, 155712064, 155843392,
+155971136, 156106688, 156237376, 156367424, 156499264, 156630976,
+156761536, 156892352, 157024064, 157155008, 157284416, 157415872,
+157545536, 157677248, 157810496, 157938112, 158071744, 158203328,
+158334656, 158464832, 158596288, 158727616, 158858048, 158988992,
+159121216, 159252416, 159381568, 159513152, 159645632, 159776192,
+159906496, 160038464, 160169536, 160300352, 160430656, 160563008,
+160693952, 16082208, 160956352, 161086784, 161217344, 161349184,
+161480512, 161611456, 161742272, 161873216, 162002752, 162135872,
+162266432, 162397888, 162529216, 162660032, 162790976, 162922048,
+163052096, 163184576, 163314752, 163446592, 163577408, 163707968,
+163839296, 163969984, 164100928, 164233024, 164364224, 164494912,
+164625856, 164756672, 164887616, 165019072, 165150016, 165280064,
+165412672, 165543104, 165674944, 165805888, 165936832, 166067648,
+166198336, 166330048, 166461248, 166591552, 166722496, 166854208,
+166985408, 167116736, 167246656, 167378368, 167508416, 167641024,
+167771584, 167903168, 168034112, 168164032, 168295744, 168427456,
+168557632, 168688448, 168819136, 168951616, 169082176, 169213504,
+169344832, 169475648, 169605952, 169738048, 169866304, 169999552,
+170131264, 170262464, 170393536, 170524352, 170655424, 170782016,
+170917696, 171048896, 171179072, 171310784, 171439936, 171573184,
+171702976, 171835072, 171966272, 172097216, 172228288, 172359232,
+172489664, 172621376, 172747712, 172883264, 173014208, 173144512,
+173275072, 173407424, 173539136, 173669696, 173800768, 173931712,
+174063424, 174193472, 174325696, 174455744, 174586816, 174718912,
+174849728, 174977728, 175109696, 175242688, 175374272, 175504832,
+175636288, 175765696, 175898432, 176028992, 176159936, 176291264,
+176422592, 176552512, 176684864, 176815424, 176946496, 177076544,
+177209152, 177340096, 177470528, 177600704, 177731648, 177864256,
+177994816, 178126528, 178257472, 178387648, 178518464, 178650176,
+178781888, 178912064, 179044288, 179174848, 179305024, 179436736,
+179568448, 179698496, 179830208, 179960512, 180092608, 180223808,
+180354752, 180485696, 180617152, 180748096, 180877504, 181009984,
+181139264, 181272512, 181402688, 181532608, 181663168, 181795136,
+181926592, 182057536, 182190016, 182320192, 182451904, 182582336,
+182713792, 182843072, 182976064, 183107264, 183237056, 183368384,
+183494848, 183631424, 183762752, 183893824, 184024768, 184154816,
+184286656, 184417984, 184548928, 184680128, 184810816, 184941248,
+185072704, 185203904, 185335616, 185465408, 185596352, 185727296,
+185859904, 185989696, 186121664, 186252992, 186383552, 186514112,
+186645952, 186777152, 186907328, 187037504, 187170112, 187301824,
+187429184, 187562048, 187693504, 187825472, 187957184, 188087104,
+188218304, 188349376, 188481344, 188609728, 188743616, 188874304,
+189005248, 189136448, 189265088, 189396544, 189528128, 189660992,
+189791936, 189923264, 190054208, 190182848, 190315072, 190447424,
+190577984, 190709312, 190840768, 190971328, 191102656, 191233472,
+191364032, 191495872, 191626816, 191758016, 191888192, 192020288,
+192148928, 192282176, 192413504, 192542528, 192674752, 192805952,
+192937792, 193068608, 193198912, 193330496, 193462208, 193592384,
+193723456, 193854272, 193985984, 194116672, 194247232, 194379712,
+194508352, 194641856, 194772544, 194900672, 195035072, 195166016,
+195296704, 195428032, 195558592, 195690304, 195818176, 195952576,
+196083392, 196214336, 196345792, 196476736, 196607552, 196739008,
+196869952, 197000768, 197130688, 197262784, 197394368, 197523904,
+197656384, 197787584, 197916608, 198049472, 198180544, 198310208,
+198442432, 198573632, 198705088, 198834368, 198967232, 199097792,
+199228352, 199360192, 199491392, 199621696, 199751744, 199883968,
+200014016, 200146624, 200276672, 200408128, 200540096, 200671168,
+200801984, 200933312, 201062464, 201194944, 201326144, 201457472,
+201588544, 201719744, 201850816, 201981632, 202111552, 202244032,
+202374464, 202505152, 202636352, 202767808, 202898368, 203030336,
+203159872, 203292608, 203423296, 203553472, 203685824, 203816896,
+203947712, 204078272, 204208192, 204341056, 204472256, 204603328,
+204733888, 204864448, 204996544, 205125568, 205258304, 205388864,
+205517632, 205650112, 205782208, 205913536, 206044736, 206176192,
+206307008, 206434496, 206569024, 206700224, 206831168, 206961856,
+207093056, 207223616, 207355328, 207486784, 207616832, 207749056,
+207879104, 208010048, 208141888, 208273216, 208404032, 208534336,
+208666048, 208796864, 208927424, 209059264, 209189824, 209321792,
+209451584, 209582656, 209715136, 209845568, 209976896, 210106432,
+210239296, 210370112, 210501568, 210630976, 210763712, 210894272,
+211024832, 211156672, 211287616, 211418176, 211549376, 211679296,
+211812032, 211942592, 212074432, 212204864, 212334016, 212467648,
+212597824, 212727616, 212860352, 212991424, 213120832, 213253952,
+213385024, 213515584, 213645632, 213777728, 213909184, 214040128,
+214170688, 214302656, 214433728, 214564544, 214695232, 214826048,
+214956992, 215089088, 215219776, 215350592, 215482304, 215613248,
+215743552, 215874752, 216005312, 216137024, 216267328, 216399296,
+216530752, 216661696, 216790592, 216923968, 217054528, 217183168,
+217316672, 217448128, 217579072, 217709504, 217838912, 217972672,
+218102848, 218233024, 218364736, 218496832, 218627776, 218759104,
+218888896, 219021248, 219151936, 219281728, 219413056, 219545024,
+219675968, 219807296, 219938624, 220069312, 220200128, 220331456,
+220461632, 220592704, 220725184, 220855744, 220987072, 221117888,
+221249216, 221378368, 221510336, 221642048, 221772736, 221904832,
+222031808, 222166976, 222297536, 222428992, 222559936, 222690368,
+222820672, 222953152, 223083968, 223213376, 223345984, 223476928,
+223608512, 223738688, 223869376, 224001472, 224132672, 224262848,
+224394944, 224524864, 224657344, 224788288, 224919488, 225050432,
+225181504, 225312704, 225443776, 225574592, 225704768, 225834176,
+225966784, 226097216, 226229824, 226360384, 226491712, 226623424,
+226754368, 226885312, 227015104, 227147456, 227278528, 227409472,
+227539904, 227669696, 227802944, 227932352, 228065216, 228196288,
+228326464, 228457792, 228588736, 228720064, 228850112, 228981056,
+229113152, 229243328, 229375936, 229505344, 229636928, 229769152,
+229894976, 230030272, 230162368, 230292416, 230424512, 230553152,
+230684864, 230816704, 230948416, 231079616, 231210944, 231342016,
+231472448, 231603776, 231733952, 231866176, 231996736, 232127296,
+232259392, 232388672, 232521664, 232652608, 232782272, 232914496,
+233043904, 233175616, 233306816, 233438528, 233569984, 233699776,
+233830592, 233962688, 234092224, 234221888, 234353984, 234485312,
+234618304, 234749888, 234880832, 235011776, 235142464, 235274048,
+235403456, 235535936, 235667392, 235797568, 235928768, 236057152,
+236190272, 236322752, 236453312, 236583616, 236715712, 236846528,
+236976448, 237108544, 237239104, 237371072, 237501632, 237630784,
+237764416, 237895232, 238026688, 238157632, 238286912, 238419392,
+238548032, 238681024, 238812608, 238941632, 239075008, 239206336,
+239335232, 239466944, 239599168, 239730496, 239861312, 239992384,
+240122816, 240254656, 240385856, 240516928, 240647872, 240779072,
+240909632, 241040704, 241171904, 241302848, 241433408, 241565248,
+241696192, 241825984, 241958848, 242088256, 242220224, 242352064,
+242481856, 242611648, 242744896, 242876224, 243005632, 243138496,
+243268672, 243400384, 243531712, 243662656, 243793856, 243924544,
+244054592, 244187072, 244316608, 244448704, 244580032, 244710976,
+244841536, 244972864, 245104448, 245233984, 245365312, 245497792,
+245628736, 245759936, 245889856, 246021056, 246152512, 246284224,
+246415168, 246545344, 246675904, 246808384, 246939584, 247070144,
+247199552, 247331648, 247463872, 247593536, 247726016, 247857088,
+247987648, 248116928, 248249536, 248380736, 248512064, 248643008,
+248773312, 248901056, 249036608, 249167552, 249298624, 249429184,
+249560512, 249692096, 249822784, 249954112, 250085312, 250215488,
+250345792, 250478528, 250608704, 250739264, 250870976, 251002816,
+251133632, 251263552, 251395136, 251523904, 251657792, 251789248,
+251919424, 252051392, 252182464, 252313408, 252444224, 252575552,
+252706624, 252836032, 252968512, 253099712, 253227584, 253361728,
+253493056, 253623488, 253754432, 253885504, 254017216, 254148032,
+254279488, 254410432, 254541376, 254672576, 254803264, 254933824,
+255065792, 255196736, 255326528, 255458752, 255589952, 255721408,
+255851072, 255983296, 256114624, 256244416, 256374208, 256507712,
+256636096, 256768832, 256900544, 257031616, 257162176, 257294272,
+257424448, 257555776, 257686976, 257818432, 257949632, 258079552,
+258211136, 258342464, 258473408, 258603712, 258734656, 258867008,
+258996544, 259127744, 259260224, 259391296, 259522112, 259651904,
+259784384, 259915328, 260045888, 260175424, 260308544, 260438336,
+260570944, 260700992, 260832448, 260963776, 261092672, 261226304,
+261356864, 261487936, 261619648, 261750592, 261879872, 262011968,
+262143424, 262274752, 262404416, 262537024, 262667968, 262799296,
+262928704, 263061184, 263191744, 263322944, 263454656, 263585216,
+263716672, 263847872, 263978944, 264108608, 264241088, 264371648,
+264501184, 264632768, 264764096, 264895936, 265024576, 265158464,
+265287488, 265418432, 265550528, 265681216, 265813312, 265943488,
+266075968, 266206144, 266337728, 266468032, 266600384, 266731072,
+266862272, 266993344, 267124288, 267255616, 267386432, 267516992,
+267648704, 267777728, 267910592, 268040512, 268172096, 268302784,
+268435264, 268566208, 268696256, 268828096, 268959296, 269090368,
+269221312, 269352256, 269482688, 269614784, 269745856, 269876416,
+270007616, 270139328, 270270272, 270401216, 270531904, 270663616,
+270791744, 270924736, 271056832, 271186112, 271317184, 271449536,
+271580992, 271711936, 271843136, 271973056, 272105408, 272236352,
+272367296, 272498368, 272629568, 272759488, 272891456, 273022784,
+273153856, 273284672, 273415616, 273547072, 273677632, 273808448,
+273937088, 274071488, 274200896, 274332992, 274463296, 274595392,
+274726208, 274857536, 274988992, 275118656, 275250496, 275382208,
+275513024, 275643968, 275775296, 275906368, 276037184, 276167872,
+276297664, 276429376, 276560576, 276692672, 276822976, 276955072,
+277085632, 277216832, 277347008, 277478848, 277609664, 277740992,
+277868608, 278002624, 278134336, 278265536, 278395328, 278526784,
+278657728, 278789824, 278921152, 279052096, 279182912, 279313088,
+279443776, 279576256, 279706048, 279838528, 279969728, 280099648,
+280230976, 280361408, 280493632, 280622528, 280755392, 280887104,
+281018176, 281147968, 281278912, 281411392, 281542592, 281673152,
+281803712, 281935552, 282066496, 282197312, 282329024, 282458816,
+282590272, 282720832, 282853184, 282983744, 283115072, 283246144,
+283377344, 283508416, 283639744, 283770304, 283901504, 284032576,
+284163136, 284294848, 284426176, 284556992, 284687296, 284819264,
+284950208, 285081536]
+```
diff --git a/public/content/translations/ko/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/ko/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
new file mode 100644
index 00000000000..98a54930350
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
@@ -0,0 +1,42 @@
+---
+title: "채굴 알고리즘"
+description: "이더리움 채굴에 사용되는 알고리즘 자세히 살펴보기 "
+lang: ko
+---
+
+
+
+
+작업증명은 더 이상 이더리움의 합의 메커니즘의 기초가 아니며, 채굴이 중단되었습니다. 대신, 이더리움은 ETH를 스테이킹하는 검증자에 의해 보안이 유지됩니다. 오늘부터 ETH 스테이킹을 시작할 수 있습니다. 더 알아보려면 The Merge, 지분증명, 그리고 스테이킹에 대해 읽어보세요. 이 페이지는 역사적인 참고만을 위한 것입니다.
+
+
+
+
+이더리움 채굴은 Ethash라는 알고리즘을 사용했습니다. 이 알고리즘의 근본적 아이디어는 채굴자가 브루트 포스 계산-무작위 대입-을 통해 논스 입력값을 알아내려고 시도하여 그 결과 해쉬값이, 계산 난이도에 의해 결정된 임계값보다 작아지게 만드는 것입니다. 이 난이도는 동적으로 조절되어, 블록 생성이 일정한 주기로 이루어지도록 합니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 [작업 증명 합의](/developers/docs/consensus-mechanisms/pow) 및 [채굴](/developers/docs/consensus-mechanisms/pow/mining)에 대해 읽어보는 것을 권장합니다.
+
+## 대거-해시모토 {#dagger-hashimoto}
+
+대거-하시모토 알고리즘은 이더리움 채굴에 있어서 Ethash가 대체한 선행적 검색 알고리즘이었습니다. 두 개의 서로 다른 알고리즘: 대거와 하시모토의 결합이었습니다. 그것은 단지 연구 구현이었고 이더리움 메인넷이 출시되었을 때는 Ethash로 대체되었습니다.
+
+[Dagger](http://www.hashcash.org/papers/dagger.html)는 [방향성 비순환 그래프(Directed Acyclic Graph)](https://en.wikipedia.org/wiki/Directed_acyclic_graph)를 생성하고, 이 그래프의 임의의 조각들을 함께 해시하는 과정을 포함합니다. 핵심 원칙은 각 논스값은 오직 거대한 전체 데이터 트리의 일부만 필요로 한다는 것입니다. 논스 값 각각에 대한 서브트리를 다시 계산하는 것은 채굴에 매우 부담이 되므로, 트리를 저장할 필요가 있습니다. 하지만 단일 논스 값에 대한 검증 작업으로는 재계산이 충분히 가능합니다. 대거 알고리즘은 메모리 집약적이지만 메모리 부담이 안전한 수준으로 증가하면 검증하기 어려운 기존의 Scrypt 알고리즘의 대안으로 설계되었습니다. 하지만 대거 알고리즘은 공유 메모리 하드웨어 가속에 취약하여 다른 연구 방향들이 선호됨에 따라 사용이 감소했습니다.
+
+[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf)는 I/O 바운드(즉, 메모리 읽기가 채굴 과정의 제한 요소가 됨) 방식을 통해 ASIC 저항성을 추가하는 알고리즘입니다. 그 이론은 RAM이 계산보다 더 쉽게 이용 가능하다는 것입니다. 이미 수십억 달러 가치의 연구가 다양한 목적을 위해 RAM을 최적화하는 방법을 조사해왔으며, 이들 연구는 종종 거의 무작위 접근 패턴(따라서 ‘랜덤 액세스 메모리’)을 포함합니다. 그 결과로, 기존의 RAM은 알고리즘을 평가하는 데 있어 상당히 최적에 가까운 상태라고 할 수 있습니다. 하시모토 알고리즘은 블록체인을 데이터 소스로 사용하면서 위에 있는 (1)과 (3)을 동시에 만족합니다.
+
+대거 하시모토 알고리즘은 대거 및 하시모토의 변경된 버전을 사용했습니다. 대거-하시모토 알고리즘과 하시모토 알고리즘의 차이점은, 하시모토 알고리즘이 블록체인을 데이터 소스로 사용하는 반면에, 대거-하시모토 알고리즘은 맞춤형으로 생성된 데이터 세트를 사용한다는 점입니다. 이 맞춤형 데이터 세트는 매 N개의 블록이 쌓일 때마다 블록 데이터에 기반하여 업데이트됩니다. 이 데이터 세트는 대거 알고리즘을 활용해 생성되고, 라이트 클라이언트 검증 알고리즘 검증 시 모든 논스값의 특정한 서브셋을 효율적으로 계산합니다. 대거-해시모토와 대거의 차이점은 기존 대거와 달리, 블록을 쿼리하는 데 사용되는 데이터 세트가 반영구적이며 간헐적인 간격(예: 주 1회)으로만 업데이트된다는 것입니다. 이는 데이터 세트를 생성하는 데 들어가는 노력이 거의 없다는 것을 의미하며, 이에 따라 공유 메모리 속도 향상과 관련한 세르지오 레르너의 주장은 크게 약화됩니다.
+
+[대거-해시모토](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto)에 대해 더 알아보기.
+
+## Ethash {#ethash}
+
+Ethash는 현재는 더 이상 사용되지 않는 작업 증명-PoW- 방식 하에서, 실제 이더리움 메인넷에서 사용된 채굴 알고리즘이었습니다. Ethash는 이전 버전의 기본 원칙을 계승하면서도, 알고리즘이 상당히 업데이트된 후 대거-하시모토 알고리즘의 특정한 버전으로써 새로운 이름이 붙여졌습니다. 이더리움 메인넷은 Ethash만 사용했습니다. 대거-해시모토는 채굴 알고리즘의 R&D 버전이었으며, 이더리움 메인넷에서 채굴이 시작되기 전에 대체되었습니다.
+
+[Ethash에 대해 더 알아보기](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash).
+
+## 더 읽어보기 {#further-reading}
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
diff --git a/public/content/translations/ko/developers/docs/dapps/index.md b/public/content/translations/ko/developers/docs/dapps/index.md
new file mode 100644
index 00000000000..204cbff168a
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/dapps/index.md
@@ -0,0 +1,96 @@
+---
+title: "탈중앙화앱에 대한 기술적 소개"
+description:
+lang: ko
+---
+
+탈중앙화 애플리케이션(탈중앙화앱)은 [스마트 계약](/developers/docs/smart-contracts/)과 프런트엔드 사용자 인터페이스를 결합한 탈중앙화 네트워크상에 구축된 애플리케이션입니다. 이더리움에서 스마트 계약은 오픈 API처럼 접근하기 쉽고 투명합니다. 즉, 여러분의 디앱에는 다른 사람이 작성한 스마트 계약이 포함될 수 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+탈중앙화앱에 대해 배우기 전에 [블록체인 기초](/developers/docs/intro-to-ethereum/)를 다루고 이더리움 네트워크와 탈중앙화 방식에 대해 읽어보아야 합니다.
+
+## 탈중앙화앱의 정의 {#definition-of-a-dapp}
+
+디앱에는 분산형 피어-투-피어 네트워크 상에서 실행되는 백엔드 코드가 있습니다. 백엔드 코드가 중앙화된 서버에서 실행되는 앱과 이를 비교해보시기 바랍니다.
+
+디앱은 일반 앱처럼, 아떤 언어로 작성된 백엔드도 호출할 수 있는 프론트엔드 코드와 유저 인터페이스를 가지고 있다. 또한 프런트엔드는 [IPFS](https://ipfs.io/)와 같은 탈중앙화된 스토리지에서 호스팅될 수 있습니다.
+
+- **탈중앙화** - 탈중앙화앱은 어느 한 사람이나 그룹이 통제할 수 없는 개방형 공용 탈중앙화 플랫폼인 이더리움에서 작동합니다.
+- **결정적** - 탈중앙화앱은 실행되는 환경에 관계없이 동일한 기능을 수행합니다.
+- **튜링 완전** - 탈중앙화앱은 필요한 리소스가 주어지면 모든 작업을 수행할 수 있습니다.
+- **격리됨** - 탈중앙화앱은 이더리움 가상 머신으로 알려진 가상 환경에서 실행되므로 스마트 계약에 버그가 있더라도 블록체인 네트워크의 정상적인 기능을 방해하지 않습니다.
+
+### 스마트 계약에 대하여 {#on-smart-contracts}
+
+디앱을 소개하려면, 디앱의 백엔드인 스마트 컨트랙트를 이해할 필요가 있다. 자세한 개요는 [스마트 계약](/developers/docs/smart-contracts/)에 대한 섹션을 참조하세요.
+
+스마트 컨트랙트는 이더리움 블록체인 상에서 살아있는 그리고 프로그램된대로 정확히 실행하는 코드이다. 스마트 계약이 네트워크에 배포되면, 변경할 수 없습니다. 디앱은 그들이 개인이나 회사가 아닌 컨트랙트에 적힌 로직에 의해 제어되기 때문에 탈중앙화될 수 있다. 이는 또한 스마트 계약를 매우 조심해서 설계하고, 철저히 테스트할 필요가 있음을 의미한다.
+
+## 탈중앙화앱 개발의 이점 {#benefits-of-dapp-development}
+
+- **무중단** – 스마트 계약이 블록체인에 배포되면, 전체 네트워크는 계약과 상호 작용하려는 클라이언트에게 항상 서비스를 제공할 수 있습니다. 따라서 악의적인 의도를 가진 사람들은 개별 디앱에 서비스 거부 공격을 할 수 없습니다.
+- **개인정보보호** – 탈중앙화앱을 배포하거나 상호 작용하기 위해 실제 신원을 제공할 필요가 없습니다.
+- **검열 저항성** – 네트워크상의 단일 개체는 사용자가 트랜잭션을 제출하거나, 탈중앙화앱을 배포하거나, 블록체인에서 데이터를 읽는 것을 차단할 수 없습니다.
+- **완전한 데이터 무결성** – 블록체인에 저장된 데이터는 암호화 프리미티브 덕분에 불변하며 논쟁의 여지가 없습니다. 악의적인 행위자들은 이미 공개된 트랜잭션이나 다른 데이터를 위조할 수 없다.
+- **무신뢰 계산/검증 가능한 동작** – 스마트 계약은 중앙 기관을 신뢰할 필요 없이 분석할 수 있으며 예측 가능한 방식으로 실행되도록 보장됩니다. 이는 전통적인 모델에서는 불가능하다. 예를 들어, 우리가 온라인 뱅킹 시스템을 사용할 때 우리는 금융 기관들이 우리의 금융 데이터를 오용하거나, 기록을 함부로 조작하거나 해킹 당하지 않을 것이라고 믿어야 한다.
+
+## 탈중앙화앱 개발의 단점 {#drawbacks-of-dapp-development}
+
+- **유지보수** – 블록체인에 게시된 코드와 데이터는 수정하기가 더 어렵기 때문에 탈중앙화앱은 유지보수가 더 어려울 수 있습니다. 이전 버전에서 버그나 보안 위험이 식별되더라도, 배포된 후에는 디앱(또는 디엡에 저장된 기본 데이터) 을 업데이트하기가 어렵습니다.
+- **성능 오버헤드** – 상당한 성능 오버헤드가 있으며 확장이 정말 어렵습니다. 이더리움이 요구하는 보안성, 무결성, 투명성 그리고 신뢰성 레벨을 달성하기 위해서는 모든 노드가 실행하고, 모든 트랜잭션을 저장한다. 더욱이, 지분 증명 합의에도 시간이 걸립니다.
+- **네트워크 혼잡** – 하나의 탈중앙화앱이 너무 많은 계산 리소스를 사용하면 전체 네트워크가 정체됩니다. 현재 네트워크는 초당 약 10\~15 트랜잭션만 처리 가능하다; 트랜잭션들이 이보다 빠르게 보내지면, 컨펌되지 않은 트랜잭션 풀이 빠르게 불어날 수 있다.
+- **사용자 경험** – 평균적인 최종 사용자가 진정으로 안전한 방식으로 블록체인과 상호 작용하는 데 필요한 도구 스택을 설정하는 것이 너무 어렵다고 느낄 수 있으므로 사용자 친화적인 경험을 설계하는 것이 더 어려울 수 있습니다.
+- **중앙화** – 이더리움의 베이스 레이어 위에 구축된 사용자 친화적이고 개발자 친화적인 솔루션은 어쨌든 중앙화된 서비스처럼 보일 수 있습니다. 예를 들어, 이러한 서비스는 키 또는 기타 민감한 정보를 서버 측에 저장하거나, 중앙 집중식 서버를 사용하여 프런트엔드를 제공하거나, 블록체인에 쓰기 전에 중앙 집중식 서버에서 중요한 비즈니스 로직을 실행할 수 있습니다. 중앙 집중화는 블록체인의 많은 이점을 제거합니다.
+
+## 시각 자료를 찾고 있나요? 시각적 학습자
+
+,
+ 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..fea3a020bb8
--- /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..30ed7718dab
--- /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. 세부 정보 패널
+
+
+
+## 변형 {#variations}
+
+이는 이 글에서 공통적인 주제이지만, 이러한 요소들을 구성하는 방법에는 여러 가지가 있습니다. '세부 정보 패널'은 다음과 같을 수 있습니다.
+
+- 버튼 위
+- 버튼 아래
+- 아코디언 패널에 숨김
+- 그리고/또는 '미리보기' 모달에 표시
+
+참고 '미리보기' 모달은 선택 사항이지만, 메인 UI에 아주 적은 세부 정보만 표시하는 경우 필수적입니다.
+
+## 메인 양식의 구조 {#structure-of-the-main-form}
+
+이 상자는 실제로 교환하려는 토큰을 선택하는 곳입니다. 이 컴포넌트는 한 줄에 입력 필드와 작은 버튼으로 구성됩니다.
+
+DEX는 일반적으로 위 한 줄과 아래 한 줄에 추가 세부 정보를 표시하지만, 이는 다르게 구성할 수 있습니다.
+
+
+
+## 변형 {#variations2}
+
+여기에는 두 가지 UI 변형이 표시됩니다. 하나는 테두리가 전혀 없어 매우 개방적인 디자인을 만들고, 다른 하나는 입력 행에 테두리가 있어 해당 요소에 초점을 맞춥니다.
+
+
+
+이 기본 구조를 통해 네 가지 핵심 정보를 디자인에 표시할 수 있습니다. 각 모서리에 하나씩입니다. 상단/하단 행이 하나만 있는 경우, 두 개의 지점만 있습니다.
+
+디파이(DeFi)의 진화 과정에서 여기에 많은 다양한 것들이 포함되었습니다.
+
+## 포함할 핵심 정보 {#key-info-to-include}
+
+- 지갑 내 잔액
+- 최대 버튼
+- 법정 화폐 등가액
+- '받는' 금액에 대한 가격 영향
+
+디파이(DeFi) 초기에는 법정 화폐 등가액이 종종 누락되었습니다. 어떤 종류의 웹3 프로젝트를 구축하든 법정 화폐 등가액을 표시하는 것이 필수적입니다. 사용자는 여전히 현지 통화로 생각하므로 실제 세계의 정신 모델과 일치시키기 위해 이를 포함해야 합니다.
+
+두 번째 필드(교환할 토큰을 선택하는 필드)에서는 입력 금액과 예상 출력 금액의 차이를 계산하여 법정 화폐 금액 옆에 가격 영향을 포함할 수도 있습니다. 이것은 포함하기에 매우 유용한 세부 정보입니다.
+
+백분율 버튼(예: 25%, 50%, 75%)은 유용한 기능일 수 있지만 더 많은 공간을 차지하고 더 많은 행동 유도를 추가하며 더 많은 정신적 부담을 줍니다. 백분율 슬라이더도 마찬가지입니다. 이러한 UI 결정 중 일부는 브랜드와 사용자 유형에 따라 달라집니다.
+
+추가 세부 정보는 메인 양식 아래에 표시할 수 있습니다. 이러한 유형의 정보는 대부분 전문 사용자를 위한 것이므로 다음 중 하나를 수행하는 것이 좋습니다.
+
+- 최대한 최소한으로 유지하거나,
+- 아코디언 패널에 숨기기
+
+
+
+## 포함할 추가 정보 {#extra-info-to-include}
+
+- 토큰 가격
+- 슬리피지
+- 최소 수령액
+- 예상 출력
+- 가격 영향
+- 가스 비용 추정치
+- 기타 수수료
+- 주문 라우팅
+
+논란의 여지가 있지만, 이러한 세부 정보 중 일부는 선택 사항일 수 있습니다.
+
+주문 라우팅은 흥미롭지만 대부분의 사용자에게는 큰 차이가 없습니다.
+
+일부 다른 세부 정보는 단순히 같은 내용을 다른 방식으로 다시 설명하는 것입니다. 예를 들어 '최소 수령액'과 '슬리피지'는 동전의 양면과 같습니다. 슬리피지를 1%로 설정한 경우, 수령할 수 있는 최소 금액 = 예상 출력 - 1%입니다. 일부 UI는 예상 금액, 최소 금액 및 슬리피지를 표시합니다... 유용하지만 과할 수 있습니다.
+
+어차피 대부분의 사용자는 기본 슬리피지를 그대로 둡니다.
+
+'가격 영향'은 '받는' 필드의 법정 화폐 등가액 옆 괄호 안에 표시되는 경우가 많습니다. 이것은 추가하기에 훌륭한 UX 세부 정보이지만, 여기에 표시된다면 아래에 다시 표시할 필요가 있을까요? 그리고 미리보기 화면에 또다시?
+
+많은 사용자(특히 소액을 교환하는 사용자)는 이러한 세부 정보에 신경 쓰지 않을 것입니다. 그들은 단순히 숫자를 입력하고 교환을 누를 것입니다.
+
+
+
+정확히 어떤 세부 정보를 표시할지는 잠재고객과 앱이 어떤 느낌을 주기를 원하는지에 따라 달라집니다.
+
+세부 정보 패널에 슬리피지 허용치를 포함하는 경우, 여기에서 직접 편집할 수 있도록 해야 합니다. 이것은 '단축키'의 좋은 예입니다. 앱의 일반적인 사용성에 영향을 주지 않으면서 숙련된 사용자의 흐름을 가속화할 수 있는 깔끔한 UX 트릭입니다.
+
+
+
+한 화면의 특정 정보 하나뿐만 아니라 전체 흐름에 대해 신중하게 생각하는 것이 좋습니다.
+메인 양식에 숫자 입력 → 세부 정보 스캔 → 미리보기 화면으로 클릭(미리보기 화면이 있는 경우).
+세부 정보 패널을 항상 표시해야 할까요, 아니면 사용자가 확장하려면 클릭해야 할까요?
+미리보기 화면을 추가하여 마찰을 만들어야 할까요? 이는 사용자가 속도를 늦추고 거래를 고려하도록 강제하는데, 이는 유용할 수 있습니다. 하지만 그들은 모든 동일한 정보를 다시 보고 싶어할까요? 이 시점에서 그들에게 가장 유용한 것은 무엇일까요?
+
+## 디자인 옵션 {#design-options}
+
+앞서 언급했듯이, 이 중 많은 부분이 개인 스타일에 달려 있습니다
+사용자는 누구입니까?
+당신의 브랜드는 무엇입니까?
+모든 세부 정보를 보여주는 '전문가용' 인터페이스를 원하십니까, 아니면 미니멀리스트를 원하십니까?
+가능한 모든 정보를 원하는 전문 사용자를 목표로 하더라도 Alan Cooper의 현명한 말을 기억해야 합니다.
+
+> 인터페이스가 아무리 아름답고 멋지더라도, 적을수록 좋습니다.
+
+### 구조 {#structure}
+
+- 토큰을 왼쪽에, 또는 토큰을 오른쪽에
+- 2행 또는 3행
+- 버튼 위 또는 아래의 세부 정보
+- 세부 정보 확장, 최소화 또는 표시 안 함
+
+### 구성 요소 스타일 {#component-style}
+
+- 비어 있음
+- 윤곽선
+- 채워짐
+
+순수한 UX 관점에서 볼 때 UI 스타일은 생각보다 덜 중요합니다. 시각적 트렌드는 주기를 그리며 나타났다 사라지며, 선호도 중 상당 부분은 주관적입니다.
+
+이에 대한 감을 잡고 다양한 구성을 생각해 보는 가장 쉬운 방법은 몇 가지 예를 살펴본 다음 직접 실험해 보는 것입니다.
+
+포함된 Figma 키트에는 비어 있거나, 윤곽선이 있거나, 채워진 구성 요소가 포함되어 있습니다.
+
+아래 예시를 보고 모든 것을 종합할 수 있는 다양한 방법을 확인하세요.
+
+
+
+
+
+
+
+
+
+
+
+
+
+## 하지만 토큰은 어느 쪽에 있어야 할까요? {#but-which-side-should-the-token-go-on}
+
+결론은 사용성에 큰 차이를 만들지 않을 것이라는 점입니다. 그러나 한쪽으로 기울게 할 수 있는 몇 가지 명심해야 할 사항이 있습니다.
+
+시간이 지남에 따라 유행이 변하는 것을 보는 것은 약간 흥미로웠습니다. Uniswap은 처음에 토큰을 왼쪽에 두었지만, 이후 오른쪽으로 옮겼습니다. Sushiswap도 디자인 업그레이드 중에 이 변경을 했습니다. 전부는 아니지만 대부분의 프로토콜이 그 뒤를 따랐습니다.
+
+금융 관례상 전통적으로 통화 기호를 숫자 앞에 둡니다(예: $50, €50, £50). 하지만 우리는 50달러, 50유로, 50파운드라고 _말합니다_.
+
+일반 사용자, 특히 왼쪽에서 오른쪽으로, 위에서 아래로 읽는 사람에게는 오른쪽에 있는 토큰이 아마도 더 자연스럽게 느껴질 것입니다.
+
+
+
+토큰을 왼쪽에, 모든 숫자를 오른쪽에 배치하면 보기 좋게 대칭을 이루어 장점이지만, 이 레이아웃에는 또 다른 단점이 있습니다.
+
+근접성의 법칙은 서로 가까이 있는 항목들이 관련 있는 것으로 인식된다는 것을 명시합니다. 따라서 관련 항목을 서로 옆에 배치하고자 합니다. 토큰 잔액은 토큰 자체와 직접 관련이 있으며, 새 토큰이 선택될 때마다 변경됩니다. 따라서 토큰 잔액이 토큰 선택 버튼 옆에 있는 것이 조금 더 합리적입니다. 토큰 아래로 옮길 수도 있지만, 그러면 레이아웃의 대칭이 깨집니다.
+
+궁극적으로 두 옵션 모두 장단점이 있지만, 추세가 오른쪽 토큰으로 기우는 것처럼 보이는 것은 흥미롭습니다.
+
+## 버튼 동작 {#button-behavior}
+
+승인을 위한 별도의 버튼을 만들지 마세요. 또한 승인을 위한 별도의 클릭을 만들지 마세요. 사용자는 교환을 원하므로 버튼에 '교환'이라고 표시하고 첫 번째 단계로 승인을 시작하세요. 모달은 스텝퍼 또는 간단한 '거래 1/2 - 승인 중' 알림으로 진행 상황을 표시할 수 있습니다.
+
+
+
+
+
+### 상황별 도움말로서의 버튼 {#button-as-contextual-help}
+
+버튼은 경고로서 이중 역할을 할 수 있습니다!
+
+이것은 사실 웹3 밖에서는 상당히 이례적인 디자인 패턴이지만, 그 안에서는 표준이 되었습니다. 이는 공간을 절약하고 주의를 집중시키는 좋은 혁신입니다.
+
+오류로 인해 주된 작업인 교환을 사용할 수 없는 경우, 버튼으로 그 이유를 설명할 수 있습니다. 예:
+
+- 네트워크 전환
+- 지갑 연결
+- 다양한 오류
+
+버튼은 수행해야 할 작업에 매핑될 수도 있습니다. 예를 들어, 사용자가 잘못된 네트워크에 있어 교환할 수 없는 경우, 버튼에 'Ethereum으로 전환'이라고 표시되어야 하며, 사용자가 버튼을 클릭하면 네트워크를 Ethereum으로 전환해야 합니다. 이렇게 하면 사용자 흐름이 크게 빨라집니다.
+
+
+
+
+
+## 이 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에서는 트랜잭션이 블록체인에 커밋되기까지 시간이 걸릴 수 있으므로 특히 중요합니다. 기다리라는 피드백이 없으면 사용자는 어떤 일이 일어났는지 확신할 수 없습니다.
+
+**팁:**
+
+- 메시지, 알림 및 기타 경고를 통해 사용자에게 알립니다.
+- 대기 시간을 명확하게 전달합니다.
+- 작업이 몇 초 이상 걸리는 경우 타이머나 애니메이션으로 사용자에게 무언가 진행되고 있다는 느낌을 주어 안심시킵니다.
+- 프로세스에 여러 단계가 있는 경우 각 단계를 보여줍니다.
+
+**예시:**
+트랜잭션과 관련된 각 단계를 보여주면 사용자가 프로세스의 어느 단계에 있는지 알 수 있습니다. 적절한 아이콘을 통해 사용자는 자신의 행동 상태를 알 수 있습니다.
+
+
+
+### 2. 보안 및 신뢰 내재화 {#security-and-trust-are-backed-in}
+
+보안을 우선시해야 하며, 이는 사용자에게 강조되어야 합니다.
+사람들은 자신의 데이터를 매우 중요하게 생각합니다. 안전은 종종 사용자의 주된 관심사이므로 설계의 모든 수준에서 고려되어야 합니다. 항상 사용자의 신뢰를 얻기 위해 노력해야 하지만, 이를 수행하는 방법은 앱마다 다를 수 있습니다. 나중에 생각할 것이 아니라, 전반에 걸쳐 의식적으로 설계되어야 합니다. 최종 UI뿐만 아니라 소셜 채널과 개발문서를 포함한 사용자 경험 전반에 걸쳐 신뢰를 구축하십시오. 탈중앙화 수준, 재무 다중 서명 상태, 팀의 신상 공개 여부 등이 모두 사용자의 신뢰에 영향을 미칩니다.
+
+**팁:**
+
+- 감사 내역을 자신 있게 나열하십시오
+- 여러 감사를 받으십시오
+- 설계한 안전 기능을 홍보하십시오
+- 기본 통합을 포함한 잠재적 위험을 강조하십시오
+- 전략의 복잡성을 전달하십시오
+- 사용자의 안전 인식에 영향을 미칠 수 있는 비UI 문제를 고려하십시오
+
+**예시:**
+눈에 잘 띄는 크기로 바닥글에 감사 내역을 포함시키십시오.
+
+
+
+### 3. 가장 중요한 정보는 명확하다 {#the-most-important-info-is-obvious}
+
+복잡한 시스템의 경우 가장 관련성 높은 데이터만 표시합니다. 가장 중요한 것이 무엇인지 결정하고 표시의 우선순위를 정합니다.
+너무 많은 정보는 부담스럽고 사용자는 일반적으로 의사 결정을 할 때 한 가지 정보에 의존합니다. 디파이에서는 수익 앱의 연이율(APR)과 대출 앱의 담보인정비율(LTV)이 될 것입니다.
+
+**팁:**
+
+- 사용자 조사를 통해 가장 중요한 지표를 발견할 수 있습니다
+- 핵심 정보는 크게, 다른 세부 정보는 작고 눈에 띄지 않게 만드십시오
+- 사람들은 읽지 않고 훑어봅니다. 디자인이 훑어보기 쉽도록 하십시오
+
+**예시:** 풀 컬러의 큰 토큰은 훑어볼 때 쉽게 찾을 수 있습니다. 연이율(APR)은 크고 강조 색으로 강조 표시됩니다.
+
+
+
+### 4. 명확한 용어 {#clear-terminology}
+
+용어는 이해하기 쉽고 적절해야 합니다.
+전문 용어는 완전히 새로운 정신 모델을 구축해야 하므로 큰 장애물이 될 수 있습니다. 사용자는 디자인을 이미 알고 있는 단어, 구문 및 개념과 연관시킬 수 없습니다. 모든 것이 혼란스럽고 낯설게 보이며, 사용을 시도하기 전에 가파른 학습 곡선이 있습니다. 사용자는 돈을 절약하려는 목적으로 디파이에 접근할 수 있지만, 마주하는 것은 채굴, 파밍, 스테이킹, 배출, 뇌물, 볼트, 락커, ve토큰, 베스팅, 에폭, 탈중앙화 알고리즘, 프로토콜 소유 유동성 등입니다…
+가장 넓은 그룹의 사람들이 이해할 수 있는 간단한 용어를 사용하려고 노력하십시오. 프로젝트만을 위한 새로운 용어를 만들지 마십시오.
+
+**팁:**
+
+- 간단하고 일관된 용어를 사용하십시오
+- 기존 언어를 최대한 많이 사용하십시오
+- 자신만의 용어를 만들지 마십시오
+- 나타나는 대로 관례를 따르십시오
+- 사용자를 최대한 교육하십시오
+
+**예시:**
+'나의 보상'은 이 프로젝트를 위해 만들어진 새로운 단어가 아니라 널리 이해되는 중립적인 용어입니다. 보상 자체가 다른 토큰으로 지급되더라도 실제 세계의 정신 모델과 일치시키기 위해 보상은 미국 달러로 표시됩니다.
+
+
+
+### 5. 행동은 가능한 한 짧게 {#actions-are-as-short-as-possible}
+
+하위 작업을 그룹화하여 사용자의 상호작용 속도를 높입니다.
+이는 UI뿐만 아니라 스마트 계약 수준에서도 수행될 수 있습니다. 사용자가 일반적인 작업을 완료하기 위해 시스템의 한 부분에서 다른 부분으로 이동하거나 시스템을 완전히 벗어날 필요가 없어야 합니다.
+
+**팁:**
+
+- 가능한 경우 "승인"을 다른 작업과 결합하십시오
+- 서명 단계를 최대한 가깝게 묶으십시오
+
+**예시:** '유동성 추가'와 '스테이킹'을 결합하는 것은 사용자의 시간과 가스를 모두 절약하는 가속기의 간단한 예입니다.
+
+
+
+### 6. 네트워크 연결은 가시적이고 유연해야 한다 {#network-connections-are-visible-and-flexible}
+
+사용자에게 연결된 네트워크를 알리고 네트워크를 변경할 수 있는 명확한 바로 가기를 제공합니다.
+이는 멀티체인 앱에서 특히 중요합니다. 연결이 끊어졌거나 지원되지 않는 네트워크에 연결된 상태에서도 앱의 주요 기능은 계속 표시되어야 합니다.
+
+**팁:**
+
+- 연결이 끊긴 동안 가능한 한 많은 앱을 표시하십시오
+- 사용자가 현재 연결된 네트워크를 표시하십시오
+- 사용자가 네트워크를 변경하기 위해 지갑으로 이동하게 하지 마십시오
+- 앱에서 사용자가 네트워크를 전환해야 하는 경우 기본 콜투액션에서 해당 작업을 유도하십시오
+- 앱에 여러 네트워크에 대한 마켓이나 볼트가 포함된 경우 사용자가 현재 보고 있는 세트를 명확하게 명시하십시오
+
+**예시:** 앱바에서 사용자가 연결된 네트워크를 표시하고 변경할 수 있도록 하십시오.
+
+
+
+### 7. 지갑이 아닌 앱에서 제어 {#control-from-the-app-not-the-wallet}
+
+UI는 사용자에게 알아야 할 모든 것을 알려주고 해야 할 모든 것을 제어할 수 있도록 해야 합니다.
+웹3에는 UI에서 수행하는 작업과 지갑에서 수행하는 작업이 있습니다. 일반적으로 UI에서 작업을 시작한 다음 지갑에서 확인합니다. 이 두 가닥이 신중하게 통합되지 않으면 사용자는 불편함을 느낄 수 있습니다.
+
+**팁:**
+
+- UI의 피드백을 통해 시스템 상태를 전달하십시오
+- 기록을 보관하십시오
+- 이전 거래에 대한 블록 탐색기 링크를 제공하십시오
+- 네트워크를 변경할 수 있는 바로 가기를 제공하십시오.
+
+미묘한 컨테이너는 사용자가 지갑에 어떤 관련 토큰을 가지고 있는지 보여주고, 주요 CTA는 네트워크를 변경할 수 있는 바로 가기를 제공합니다.
+
+
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..41650b6aba8
--- /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..9c83d2e4b5e
--- /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에 의해 정의된다.
+
+
+_[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`도 포함됩니다.
+
+
+_[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..0e281e627cc
--- /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 일러스트](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}
+
+간단히, 가스 요금은 이더리움 네트워크를 더 안전하게 유지하도록 돕습니다. 네트워크에서 실행되는 모든 계산에 대해 수수료를 요구함으로써, 우리는 나쁜 행위자들이 네트워크를 스팸하는 것을 방지한다. 우발적이거나 적대적인 무한 루프 또는 코드의 다른 계산 낭비를 피하기 위해, 각 트랜잭션은 코드 실행의 몇 가지 계산 단계를 사용할 수 있는지에 대한 제한을 설정해야 한다. 연산의 기본 단위가 "가스"입니다.
+
+트랜잭션에 한도가 포함되어 있지만, 트랜잭션에서 사용되지 않은 가스는 사용자에게 반환됩니다(예: `최대 수수료 - (기본 수수료 + 팁)`이 반환됨).
+
+
+_[이더리움 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}
+
+:<포트>"
+```
+
+## 부트노드 실행하기 {#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..886610ebb07
--- /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에 매우 문제가 될 것이다.
+
+
+
+Delphi 프로그래밍 언어를 사용하여 Ethereum을 개발하는 방법 배우기
+
+
+
+이더리움 기반으로 개발된 탈중앙화 애플리케이션(또는 “디앱”)은 암호화폐와 블록체인 기술의 장점을 가지게 됩니다. 탈중앙화 애플리케이션은 일단 이더리움에 배포되면 항상 프로그래밍된 대로 동작하므로 완전히 신뢰할 수 있습니다. 그러므로 새로운 형태의 금융 애플리케이션을 제작하기 위해 디지털 자산을 제어하는 데 사용될 수 있습니다. 그뿐만 아니라 해당 금융 애플리케이션을 어떤 특정 단체나 개인이 제어할 수 없고 검열이 거의 불가능하도록 탈중앙화할 수 있습니다.
+
+Ethereum 위에서 분산 애플리케이션을 빌드하고 스마트 계약과 상호작용하기
+
+## 스마트 계약과 솔리디티 언어 시작하기 {#getting-started-with-smart-contracts-and-the-solidity-language}
+
+**Delphi와 Ethereum을 통합하는 첫 단계**
+
+먼저 기본 지식이 더 필요하시나요? [ethereum.org/learn](/learn/) 또는 [ethereum.org/developers](/developers/)를 확인해 보세요.
+
+- [블록체인 설명](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [스마트 계약 이해하기](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [첫 스마트 계약 작성하기](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [솔리디티 컴파일 및 배포 방법 알아보기](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## 초보자를 위한 참고 자료 및 링크 {#beginner-references-and-links}
+
+**Delphereum 라이브러리 소개**
+
+- [Delphereum이란 무엇인가요?](https://github.com/svanas/delphereum/blob/master/README.md)
+- [Delphi를 로컬(인메모리) 블록체인에 연결하기](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0)
+- [Delphi를 이더리움 메인넷에 연결하기](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83)
+- [Delphi를 스마트 계약에 연결하기](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1)
+
+**설정을 건너뛰고 곧바로 샘플을 확인하고 싶으세요?**
+
+- [3분 완성 스마트 계약과 Delphi - 파트 1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d)
+- [3분 완성 스마트 계약과 Delphi - 파트 2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b)
+
+## 중급자용 아티클 {#intermediate-articles}
+
+- [Delphi에서 이더리움 서명 메시지 시그니처 생성하기](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b)
+- [Delphi로 이더 전송하기](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4)
+- [Delphi로 ERC-20 토큰 전송하기](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d)
+
+## 고급 사용 패턴 {#advanced-use-patterns}
+
+- [Delphi와 이더리움 네임 서비스(ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7)
+- [QuikNode, 이더리움 및 Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23)
+- [Delphi와 이더리움 다크 포레스트](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93)
+- [Delphi에서 토큰 교환하기](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7)
+
+더 많은 참고 자료를 확인하고 싶으신가요? [ethereum.org/developers](/developers/)를 확인해 보세요.
diff --git a/public/content/translations/ko/developers/docs/programming-languages/dot-net/index.md b/public/content/translations/ko/developers/docs/programming-languages/dot-net/index.md
new file mode 100644
index 00000000000..1883cdc90b4
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/programming-languages/dot-net/index.md
@@ -0,0 +1,86 @@
+---
+title: ".NET 개발자를 위한 이더리움"
+description: ".NET 기반 프로젝트 및 툴링을 사용하여 이더리움 개발 방법 알아보기"
+lang: ko
+incomplete: true
+---
+
+.NET 기반 프로젝트와 툴링을 사용하여 이더리움용으로 개발하는 방법을 알아보세요
+
+이더리움 기반으로 개발된 탈중앙화 애플리케이션(또는 “디앱”)은 암호화폐와 블록체인 기술의 장점을 가지게 됩니다. 탈중앙화 애플리케이션은 일단 이더리움에 배포되면 항상 프로그래밍된 대로 동작하므로 완전히 신뢰할 수 있습니다. 그러므로 새로운 형태의 금융 애플리케이션을 제작하기 위해 디지털 자산을 제어하는 데 사용될 수 있습니다. 그뿐만 아니라 해당 금융 애플리케이션을 어떤 특정 단체나 개인이 제어할 수 없고 검열이 거의 불가능하도록 탈중앙화할 수 있습니다.
+
+이더리움 기반으로 개발된 탈중앙화 애플리케이션은 마이크로스프트(Microsoft) 기술 스택의 도구와 언어를 사용하여 스마트 계약과 상호 작용합니다. 지원되는 언어에는 C#, # Visual Basic .NET, F# 등이 있으며 .NET Framework/.NET Core/.NET Standard에서 VSCode 및 Visual Studio와 같은 도구를 통해 실행됩니다. 마이크로소프트 애저(Microsoft Azure) 블록체인을 사용하여 애저에서 수 분 이내에 이더리움 블록체인을 배포할 수 있습니다. 이더리움에서 .NET에 대한 열정을 표현해 보세요!
+
+## 스마트 계약과 솔리디티 언어 시작하기 {#getting-started-with-smart-contracts-and-the-solidity-language}
+
+**이더리움과 .NET을 통합하기 위한 첫걸음을 내딛으세요**
+
+먼저 기본 지식이 더 필요하시나요? [ethereum.org/learn](/learn/) 또는 [ethereum.org/developers](/developers/)를 확인해 보세요.
+
+- [블록체인 설명](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [스마트 계약 이해하기](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [첫 스마트 계약 작성하기](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [솔리디티 컴파일 및 배포 방법 알아보기](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## 초보자를 위한 참고 자료 및 링크 {#beginner-references-and-links}
+
+**네더리움 라이브러리(Nethereum library) 및 VS 코드 솔리디티(Code Solidity) 소개**
+
+- [Nethereum, 시작하기](https://docs.nethereum.com/en/latest/getting-started/)
+- [VS Code 솔리디티 설치하기](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity)
+- [.NET 개발자의 이더리움 스마트 계약 생성 및 호출 워크플로](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2)
+- [Nethereum을 이용한 스마트 계약 통합](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm)
+- [Nethereum으로 .NET 및 이더리움 블록체인 스마트 계약 연동하기](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933), [중문판](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1)으로도 제공
+- [Nethereum - 블록체인을 위한 오픈 소스 .NET 통합 라이브러리](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/)
+- [Nethereum을 사용하여 이더리움 트랜잭션을 SQL 데이터베이스에 작성하기](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36)
+- [C#과 VisualStudio를 사용하여 이더리움 스마트 계약을 쉽게 배포하는 방법 알아보기](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c)
+
+**설정을 건너뛰고 곧바로 샘플을 확인하고 싶으세요?**
+
+- [Playground](http://playground.nethereum.com/) - 브라우저를 통해 이더리움과 상호작용하고 Nethereum 사용법을 알아보세요.
+ - 계정 잔액 조회하기 [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001)
+ - ERC20 스마트 계약 잔액 조회하기 [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004)
+ - 계정으로 이더 전송하기 [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003)
+ - ... 기타
+
+## 중급자용 아티클 {#intermediate-articles}
+
+- [Nethereum 워크북/샘플 목록](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/)
+- [자체 개발 테스트 체인 배포하기](https://github.com/Nethereum/Testchains)
+- [솔리디티용 VSCode Codegen 플러그인](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/)
+- [Unity와 이더리움: 왜, 그리고 어떻게](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how)
+- [이더리움 탈중앙화앱용 ASP.NET Core 웹 API 만들기](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/)
+- [Nethereum Web3를 사용하여 공급망 추적 시스템 구현하기](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4)
+- [Nethereum 블록 처리](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/), [C# Playground 샘플](http://playground.nethereum.com/csharp/id/1025) 포함
+- [Nethereum 웹소켓 스트리밍](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/)
+- [Kaleido와 Nethereum](https://kaleido.io/kaleido-and-nethereum/)
+- [Quorum과 Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md)
+
+## 고급 사용 패턴 {#advanced-use-patterns}
+
+- [Azure Key Vault와 Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum)
+- [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid)
+- [Ujo Nethereum 백엔드 참조 아키텍처](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/)
+
+## .NET 프로젝트, 도구 및 기타 흥미로운 자료 {#dot-net-projects-tools-and-other-fun-stuff}
+
+- [Nethereum Playground](http://playground.nethereum.com/) - _브라우저에서 Nethereum 코드 스니펫 컴파일, 생성 및 실행_
+- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _Blazor의 UI를 사용한 Nethereum codegen_
+- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _.NET Wasm SPA 라이트 블록체인 익스플로러 및 간단한 지갑_
+- [Wonka 비즈니스 규칙 엔진](https://docs.nethereum.com/en/latest/wonka/) - _근본적으로 메타데이터 기반인 비즈니스 규칙 엔진(.NET 및 이더리움 플랫폼 모두 지원)_
+- [Nethermind](https://github.com/NethermindEth/nethermind) - _Linux, Windows, MacOS용 .NET Core 이더리움 클라이언트_
+- [eth-utils](https://github.com/ethereum/eth-utils/) - _이더리움 관련 코드베이스 작업을 위한 유틸리티 함수_
+- [TestChains](https://github.com/Nethereum/TestChains) - _빠른 응답을 위해 사전 구성된 .NET 개발 체인(PoA)_
+
+더 많은 참고 자료를 확인하고 싶으신가요? [ethereum.org/developers](/developers/)를 확인해 보세요.
+
+## .NET 커뮤니티 기여자 {#dot-net-community-contributors}
+
+Nethereum에서는 주로 [Gitter](https://gitter.im/Nethereum/Nethereum)에서 활동하며, 누구나 자유롭게 질문과 답변을 하고, 도움을 받거나 편안하게 시간을 보낼 수 있습니다. [Nethereum GitHub 리포지토리](https://github.com/Nethereum)에서 자유롭게 PR을 보내거나 이슈를 열거나, 저희가 보유한 다양한 사이드/샘플 프로젝트를 둘러보세요. [Discord](https://discord.gg/jQPrR58FxX)에서도 저희를 만나보실 수 있습니다!
+
+Nethermind가 처음이고 시작하는 데 도움이 필요하시면, 저희 [Discord](http://discord.gg/PaCMRFdvWT)에 참여하세요. 저희 개발자들이 질문에 답변해 드립니다. [Nethermind GitHub 리포지토리](https://github.com/NethermindEth/nethermind)에서 주저하지 말고 PR을 열거나 이슈를 제기하세요.
+
+## 기타 수집된 목록 {#other-aggregated-lists}
+
+[Nethereum 공식 사이트](https://nethereum.com/)
+[Nethermind 공식 사이트](https://nethermind.io/)
diff --git a/public/content/translations/ko/developers/docs/programming-languages/elixir/index.md b/public/content/translations/ko/developers/docs/programming-languages/elixir/index.md
new file mode 100644
index 00000000000..90edf40dc86
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/programming-languages/elixir/index.md
@@ -0,0 +1,55 @@
+---
+title: "엘릭서 개발자를 위한 이더리움"
+description: "엘릭서 기반 프로젝트와 툴링을 사용하여 이더리움 개발 방법을 알아보세요."
+lang: ko
+incomplete: false
+---
+
+엘릭서 기반 프로젝트와 툴링을 사용하여 이더리움 개발 방법을 알아보세요.
+
+이더리움 기반으로 개발된 탈중앙화 애플리케이션(또는 “디앱”)은 암호화폐와 블록체인 기술의 장점을 가지게 됩니다. 이러한 탈중앙화앱은 무신뢰성을 가질 수 있습니다. 즉, 이더리움에 배포되면 항상 프로그래밍된 대로 실행됩니다. 탈중앙화앱은 디지털 자산을 제어하여 새로운 종류의 금융 애플리케이션을 만들 수 있습니다. 그뿐만 아니라 해당 금융 애플리케이션을 어떤 특정 단체나 개인이 제어할 수 없고 검열이 거의 불가능하도록 탈중앙화할 수 있습니다.
+
+## 스마트 계약 및 솔리디티 언어 시작하기 {#getting-started-with-smart-contracts-and-solidity}
+
+**엘릭서와 이더리움 통합을 위한 첫 단계**
+
+먼저 기본 지식이 더 필요하시나요? [ethereum.org/learn](/learn/) 또는 [ethereum.org/developers](/developers/)를 확인해 보세요.
+
+- [블록체인 설명](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [스마트 계약 이해하기](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [첫 스마트 계약 작성하기](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [솔리디티 컴파일 및 배포 방법 알아보기](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## 초급자용 아티클 {#beginner-articles}
+
+- [드디어 이더리움 계정 이해하기](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe)
+- [Ethers — 엘릭서를 위한 최고 수준의 이더리움 웹3 라이브러리](https://medium.com/@alisinabh/announcing-ethers-a-first-class-ethereum-web3-library-for-elixir-1d64e9409122)
+
+## 중급자용 아티클 {#intermediate-articles}
+
+- [엘릭서로 원시 이더리움 계약 트랜잭션에 서명하는 방법](https://kohlerjp.medium.com/how-to-sign-raw-ethereum-contract-transactions-with-elixir-f8822bcc813b)
+- [이더리움 스마트 계약과 엘릭서](https://medium.com/agile-alpha/ethereum-smart-contracts-and-elixir-c7c4b239ddb4)
+
+## 엘릭서 프로젝트 및 도구 {#elixir-projects-and-tools}
+
+### 활성 {#active}
+
+- [block_keys](https://github.com/ExWeb3/block_keys) - _엘릭서의 BIP32 및 BIP44 구현 (결정적 지갑을 위한 다중 계정 계층 구조)_
+- [ethereumex](https://github.com/mana-ethereum/ethereumex) - _이더리움 블록체인을 위한 엘릭서 JSON-RPC 클라이언트_
+- [ethers](https://github.com/ExWeb3/elixir_ethers) - _엘릭서를 사용하여 이더리움의 스마트 계약과 상호 작용하기 위한 포괄적인 웹3 라이브러리_
+- [ethers_kms](https://github.com/ExWeb3/elixir_ethers_kms) - _Ethers를 위한 KMS 서명자 라이브러리 (AWS KMS로 트랜잭션 서명)_
+- [ex_abi](https://github.com/poanetwork/ex_abi) - _엘릭서의 이더리움 ABI 파서/디코더/인코더 구현_
+- [ex_keccak](https://github.com/ExWeb3/ex_keccak) - _tiny-keccak Rust 크레이트로 빌드된 NIF를 사용하여 Keccak SHA3-256 해시를 계산하기 위한 엘릭서 라이브러리_
+- [ex_rlp](https://github.com/mana-ethereum/ex_rlp) - _이더리움의 RLP(재귀 길이 접두사) 인코딩의 엘릭서 구현_
+
+### 보관됨 / 더 이상 유지 관리되지 않음 {#archived--no-longer-maintained}
+
+- [eth](https://hex.pm/packages/eth) - _엘릭서용 이더리움 유틸리티_
+- [exw3](https://github.com/hswick/exw3) - _엘릭서를 위한 고급 이더리움 RPC 클라이언트_
+- [mana](https://github.com/mana-ethereum/mana) - _엘릭서로 작성된 이더리움 전체 노드 구현_
+
+더 많은 참고 자료를 확인하고 싶으신가요? 저희 [개발자 홈](/developers/)을 확인해 보세요.
+
+## 엘릭서 커뮤니티 기여자 {#elixir-community-contributors}
+
+[엘릭서 Slack #ethereum 채널](https://elixir-lang.slack.com/archives/C5RPZ3RJL)은 빠르게 성장하는 커뮤니티가 활동하는 곳이며, 위에 언급된 프로젝트 및 관련 주제에 대한 논의를 위한 전용 공간입니다.
diff --git a/public/content/translations/ko/developers/docs/programming-languages/golang/index.md b/public/content/translations/ko/developers/docs/programming-languages/golang/index.md
new file mode 100644
index 00000000000..a313c43b5fc
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/programming-languages/golang/index.md
@@ -0,0 +1,84 @@
+---
+title: "Go 개발자를 위한 이더리움"
+description: "Go 기반 프로젝트 및 툴링을 사용한 이더리움 개발 방법 알아보기"
+lang: ko
+incomplete: true
+---
+
+Go 기반 프로젝트와 툴링을 사용하여 이더리움용으로 개발하는 방법을 알아보세요.
+
+이더리움을 통한 탈중앙화 애플리케이션 (또는 디앱) 개발하기. 탈중앙화 애플리케이션은 일단 이더리움에 배포되면 항상 프로그래밍된 대로 동작하므로 완전히 신뢰할 수 있습니다. 탈중앙화되었다라는 것은 서비스가 중단되지 않는 다수의 노드가 연결된 네크워크 망에서의 동작을 의미합니다. 상태를 검열할 수 있는 어떤 단체나 개인도 없습니다. 새로운 유형의 애플리케이션을 제작하기 위해 디지털 자산을 사용할 수 있습니다.
+
+## 스마트 계약 및 솔리디티 언어 시작하기 {#getting-started-with-smart-contracts-and-solidity}
+
+**Go와 이더리움을 통합하기 위한 첫 단계**
+
+먼저 기본 지식이 더 필요하시나요? [ethereum.org/learn](/learn/) 또는 [ethereum.org/developers](/developers/)를 확인해 보세요.
+
+- [블록체인 설명](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [스마트 계약 이해하기](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [첫 스마트 계약 작성하기](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [솔리디티 컴파일 및 배포 방법 알아보기](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [계약 튜토리얼](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial)
+
+## 초보자용 아티클 및 서적 {#beginner-articles-and-books}
+
+- [Geth 시작하기](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458)
+- [Golang을 사용하여 이더리움에 연결하기](https://www.youtube.com/watch?v=-7uChuO_VzM)
+- [Golang을 사용하여 이더리움 스마트 계약 배포하기](https://www.youtube.com/watch?v=pytGqQmDslE)
+- [Go로 이더리움 스마트 계약을 테스트하고 배포하는 단계별 가이드](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78)
+- [eBook: Go를 사용한 이더리움 개발](https://goethereumbook.org/) - _Go를 사용하여 이더리움 애플리케이션을 개발합니다_
+
+## 중급자용 아티클 및 문서 {#intermediate-articles-and-docs}
+
+- [Go 이더리움 개발 문서](https://geth.ethereum.org/docs/) - _Go 언어를 사용한 공식 이더리움 개발 문서_
+- [Erigon 프로그래머 가이드](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _상태 트리, 다중 증명 및 트랜잭션 처리를 포함한 그림 설명 가이드_
+- [Erigon과 무상태 이더리움](https://youtu.be/3-Mn7OckSus?t=394) - _2020 이더리움 커뮤니티 콘퍼런스(EthCC 3)_
+- [Erigon: 이더리움 클라이언트 최적화](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _2018 Devcon 4_
+- [Go 이더리움 GoDoc](https://godoc.org/github.com/ethereum/go-ethereum)
+- [Geth와 Go로 디앱 만들기](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/)
+- [Golang 및 Geth를 사용하여 이더리움 프라이빗 네트워크와 작업하기](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php)
+- [Go를 사용하여 이더리움에서 솔리디티 계약 단위 테스트하기](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281)
+- [Geth를 라이브러리로 사용하기 위한 빠른 참조](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e)
+
+## 고급 사용 패턴 {#advanced-use-patterns}
+
+- [GETH 시뮬레이션된 백엔드](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top)
+- [이더리움 및 Quorum을 사용한 서비스형 블록체인 앱](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html)
+- [이더리움 블록체인 애플리케이션의 분산 스토리지 IPFS 및 Swarm](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html)
+- [모바일 클라이언트: 라이브러리 및 Inproc 이더리움 노드](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes)
+- [네이티브 디앱스: 이더리움 계약에 대한 Go 바인딩](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts)
+
+## Go 프로젝트 및 도구 {#go-projects-and-tools}
+
+- [Geth / Go 이더리움](https://github.com/ethereum/go-ethereum) - _이더리움 프로토콜의 공식 Go 구현체_
+- [Go 이더리움 코드 분석](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Go 이더리움 소스 코드 검토 및 분석_
+- [Erigon](https://github.com/ledgerwatch/erigon) - _아카이브 노드에 중점을 둔 더 빠른 Go 이더리움 파생 클라이언트_
+- [Golem](https://github.com/golemfactory/golem) - _Golem은 컴퓨팅 파워를 위한 글로벌 시장을 만들고 있습니다_
+- [Quorum](https://github.com/jpmorganchase/quorum) - _데이터 개인 정보 보호를 지원하는 허가형 이더리움 구현체_
+- [Prysm](https://github.com/prysmaticlabs/prysm) - _이더리움 '세레니티' 2.0 Go 구현체_
+- [Eth Tweet](https://github.com/yep/eth-tweet) - _탈중앙화된 트위터: 이더리움 블록체인에서 실행되는 마이크로블로깅 서비스_
+- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _최소 실행 가능 플라즈마(Minimum Viable Plasma) 사양의 Golang 구현 및 확장_
+- [오픈 이더리움 채굴 풀](https://github.com/sammy007/open-ethereum-pool) - _오픈 소스 이더리움 채굴 풀_
+- [이더리움 HD 지갑](https://github.com/miguelmota/go-ethereum-hdwallet) - _Go의 이더리움 HD 지갑 파생_
+- [Multi Geth](https://github.com/multi-geth/multi-geth) - _다양한 종류의 이더리움 네트워크 지원_
+- [Geth 라이트 클라이언트](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _라이트 이더리움 하위 프로토콜의 Geth 구현체_
+- [Ethereum Golang SDK](https://github.com/everFinance/goether) - _Golang의 간단한 이더리움 지갑 구현 및 유틸리티_
+- [Covalent Golang SDK](https://github.com/covalenthq/covalent-api-sdk-go) - _200개 이상의 블록체인을 위한 Go SDK를 통한 효율적인 블록체인 데이터 접근_
+
+더 많은 참고 자료를 확인하고 싶으신가요? [ethereum.org/developers](/developers/)를 확인해 보세요
+
+## Go 커뮤니티 기여자 {#go-community-contributors}
+
+- [Geth 디스코드](https://discordapp.com/invite/nthXNEv)
+- [Geth Gist](https://gitter.im/ethereum/go-ethereum)
+- [Gophers 슬랙](https://invite.slack.golangbridge.org/) - [#ethereum 채널](https://gophers.slack.com/messages/C9HP1S9V2)
+- [StackExchange - 이더리움](https://ethereum.stackexchange.com/)
+- [Multi Geth Gitter](https://gitter.im/ethoxy/multi-geth)
+- [이더리움 Gitter](https://gitter.im/ethereum/home)
+- [Geth 라이트 클라이언트 Gitter](https://gitter.im/ethereum/light-client)
+
+## 기타 수집된 목록 {#other-aggregated-lists}
+
+- [Awesome Ethereum](https://github.com/btomashvili/awesome-ethereum)
+- [Consensys: 이더리움 개발자 도구 최종 목록](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [GitHub 소스](https://github.com/ConsenSys/ethereum-developer-tools-list)
diff --git a/public/content/translations/ko/developers/docs/programming-languages/index.md b/public/content/translations/ko/developers/docs/programming-languages/index.md
new file mode 100644
index 00000000000..af19b6d1fc9
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/programming-languages/index.md
@@ -0,0 +1,32 @@
+---
+title: "프로그래밍 언어"
+description: "JavaScript, Python, Go, Rust 등 다양한 프로그래밍 언어를 위한 이더리움 개발 참고 자료를 찾아보세요."
+lang: ko
+---
+
+개발자들이 오해하고 있는 부분 중 하나는 이더리움 상에서 구축하려면 반드시 [스마트 계약](/developers/docs/smart-contracts/)을 작성해야 한다는 것입니다. 하지만 이는 사실이 아닙니다.
+이더리움 네트워크와 커뮤니티의 장점 중 하나는 거의 모든 프로그래밍 언어로 [참여](/community/)할 수 있다는 것입니다.
+
+이더리움과 그 커뮤니티는 오픈 소스를 적극적으로 수용합니다. 여러분은 커뮤니티 프로젝트 - 클라이언트 구현, API, 개발 프레임워크, 테스팅 툴-을 매우 다양한 언어로 찾을 수 있다.
+
+## 언어 선택 {#data}
+
+프로젝트, 리소스 및 가상 커뮤니티를 찾기 위해 선택할 프로그래밍 언어를 선택하십시오.
+
+- [Dart 개발자를 위한 이더리움](/developers/docs/programming-languages/dart/)
+- [Delphi 개발자를 위한 이더리움](/developers/docs/programming-languages/delphi/)
+- [.NET 개발자를 위한 이더리움](/developers/docs/programming-languages/dot-net/)
+- [Elixir 개발자를 위한 이더리움](/developers/docs/programming-languages/elixir/)
+- [Go 개발자를 위한 이더리움](/developers/docs/programming-languages/golang/)
+- [Java 개발자를 위한 이더리움](/developers/docs/programming-languages/java/)
+- [JavaScript 개발자를 위한 이더리움](/developers/docs/programming-languages/javascript/)
+- [Python 개발자를 위한 이더리움](/developers/docs/programming-languages/python/)
+- [Ruby 개발자를 위한 이더리움](/developers/docs/programming-languages/ruby/)
+- [Rust 개발자를 위한 이더리움](/developers/docs/programming-languages/rust/)
+
+### 사용하는 언어가 지원되지 않는다면 어떻게 해야 하나요? {#other-lang}
+
+추가적인 프로그래밍 언어에 대한 참고 자료를 링크하거나 가상 커뮤니티를 안내하고 싶다면 [이슈를 등록](https://github.com/ethereum/ethereum-org-website/issues/new/choose)하여 새 페이지를 요청할 수 있습니다.
+
+현재 지원되지 않는 언어를 사용하여 블록체인과 연동하는 코드를 작성하고 싶다면
+[JSON-RPC 인터페이스](/developers/docs/apis/json-rpc/)를 사용하여 이더리움 네트워크에 연결할 수 있습니다. TCP/IP를 사용할 수 있는 모든 프로그래밍 언어는 이 인터페이스를 사용할 수 있습니다.
diff --git a/public/content/translations/ko/developers/docs/programming-languages/java/index.md b/public/content/translations/ko/developers/docs/programming-languages/java/index.md
new file mode 100644
index 00000000000..3c65914a1b2
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/programming-languages/java/index.md
@@ -0,0 +1,64 @@
+---
+title: "Java 개발자를 위한 이더리움"
+description: "Java 기반 프로젝트 및 툴링을 사용한 이더리움 개발 방법 알아보기"
+lang: ko
+incomplete: true
+---
+
+Java 기반 프로젝트 및 툴링을 사용한 이더리움 개발 방법 알아보기
+
+이더리움 기반으로 개발된 탈중앙화 애플리케이션(또는 “디앱”)은 암호화폐와 블록체인 기술의 장점을 가지게 됩니다. 탈중앙화 애플리케이션은 일단 이더리움에 배포되면 항상 프로그래밍된 대로 동작하므로 완전히 신뢰할 수 있습니다. 그러므로 새로운 형태의 금융 애플리케이션을 제작하기 위해 디지털 자산을 제어하는 데 사용될 수 있습니다. 그뿐만 아니라 해당 금융 애플리케이션을 어떤 특정 단체나 개인이 제어할 수 없고 검열이 거의 불가능하도록 탈중앙화할 수 있습니다.
+
+## 스마트 계약 및 솔리디티 언어 시작하기 {#getting-started-with-smart-contracts-and-solidity}
+
+**Java와 이더리움을 통합하기 위한 첫 단계**
+
+먼저 기본 지식이 더 필요하시나요? [ethereum.org/learn](/learn/) 또는 [ethereum.org/developers.](/developers/)를 확인해 보세요.
+
+- [블록체인 설명](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [스마트 계약 이해하기](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [첫 스마트 계약 작성하기](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [솔리디티 컴파일 및 배포 방법 알아보기](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## 이더리움 클라이언트 사용하기 {#working-with-ethereum-clients}
+
+두 개의 주요 Java 이더리움 클라이언트인 [Web3J](https://github.com/web3j/web3j)와 하이퍼레저 Besu 사용법을 알아보세요.
+
+- [Java, Eclipse, Web3J로 이더리움 클라이언트에 연결하기](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j)
+- [Java 및 Web3j로 이더리움 계정 관리하기](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j)
+- [스마트 계약에서 Java 래퍼 생성하기](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract)
+- [이더리움 스마트 계약과 상호 작용하기](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java)
+- [이더리움 스마트 계약 이벤트 수신하기](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java)
+- [Linux에서 Java 이더리움 클라이언트인 Besu(Pantheon) 사용하기](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux)
+- [Java 통합 테스트에서 하이퍼레저 Besu(Pantheon) 노드 실행하기](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests)
+- [Web3j 치트 시트](https://kauri.io/web3j-cheat-sheet-\(java-ethereum\)/5dfa1ea941ac3d0001ce1d90/c)
+
+EVM 기반 블록체인과 상호 작용하기 위한 비동기, 고성능 Kotlin 라이브러리인 [ethers-kt](https://github.com/Kr1ptal/ethers-kt) 사용법을 알아보세요. JVM 및 Android 플랫폼 대상으로 합니다.
+
+- [ERC20 토큰 전송하기](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt)
+- [이벤트 수신을 포함한 UniswapV2 교환](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt)
+- [ETH / ERC20 잔액 추적기](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt)
+
+## 중급자용 아티클 {#intermediate-articles}
+
+- [IPFS를 사용하여 Java 애플리케이션의 저장 공간 관리하기](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs)
+- [Java에서 Web3j를 사용하여 ERC20 토큰 관리하기](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j)
+- [Web3j 트랜잭션 관리자](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers)
+
+## 고급 사용 패턴 {#advanced-use-patterns}
+
+- [Eventeum을 사용하여 Java 스마트 계약 데이터 캐시 구축하기](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache)
+
+## Java 프로젝트 및 도구 {#java-projects-and-tools}
+
+- [Web3J(이더리움 클라이언트와 상호 작용하기 위한 라이브러리)](https://github.com/web3j/web3j)
+- [ethers-kt(EVM 기반 블록체인을 위한 비동기, 고성능 Kotlin/Java/Android 라이브러리)](https://github.com/Kr1ptal/ethers-kt)
+- [Eventeum(이벤트 리스너)](https://github.com/ConsenSys/eventeum)
+- [Mahuta(IPFS 개발 도구)](https://github.com/ConsenSys/mahuta)
+
+더 많은 참고 자료를 확인하고 싶으신가요? [ethereum.org/developers.](/developers/)를 확인해 보세요.
+
+## Java 커뮤니티 기여자 {#java-community-contributors}
+
+- [IO Builders](https://io.builders)
+- [Kauri](https://kauri.io)
diff --git a/public/content/translations/ko/developers/docs/programming-languages/javascript/index.md b/public/content/translations/ko/developers/docs/programming-languages/javascript/index.md
new file mode 100644
index 00000000000..7714ed3bc47
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/programming-languages/javascript/index.md
@@ -0,0 +1,72 @@
+---
+title: "JavaScript 개발자를 위한 이더리움"
+description: "JavaScript 기반 프로젝트 및 툴링을 사용한 이더리움 개발 방법 알아보기."
+lang: ko
+---
+
+자바스크립트는 이더리움 생태계에서 가장 유명한 언어입니다. 실제로 가능한 많은 이더리움을 JavaScript로 가져오는 전담 [팀](https://github.com/ethereumjs)이 있습니다.
+
+JavaScript(또는 그와 유사한 언어)를 사용하여 [스택의 모든 레벨](/developers/docs/ethereum-stack/)에서 코드를 작성할 수 있습니다.
+
+## 이더리움과 상호작용하기 {#interact-with-ethereum}
+
+### JavaScript API 라이브러리 {#javascript-api-libraries}
+
+블록체인에 쿼리를 요청하고 트랜잭션을 전송하는 등 다양한 작업을 JavaScript로 작성하고 싶다면 [JavaScript API 라이브러리](/developers/docs/apis/javascript/)를 사용하는 것이 가장 편리한 방법입니다. 이러한 API를 통해 개발자는 [이더리움 네트워크의 노드](/developers/docs/nodes-and-clients/)와 쉽게 상호작용할 수 있습니다.
+
+라이브러리를 사용해 이더리움의 스마트 컨트랙트와 상호작용 할 수 있으므로 자바스크립트를 사용하여 기존의 계약과 상호작용 할 수 있는 디앱을 구죽할 수 있습니다.
+
+**자세히 알아보기**
+
+- [Web3.js](https://web3js.readthedocs.io)
+- [Ethers.js](https://ethers.org) – _JavaScript 및 TypeScript의 이더리움 지갑 구현 및 유틸리티가 포함되어 있습니다._
+- [viem](https://viem.sh) – _이더리움과 상호작용하기 위한 저수준 무상태 프리미티브를 제공하는 TypeScript 인터페이스입니다._
+- [Drift](https://ryangoree.github.io/drift/) – _내장된 캐싱, 후크, 테스트 목(mock)을 사용하여 여러 웹3 라이브러리에서 이더리움 개발을 쉽게 할 수 있도록 지원하는 TypeScript 메타 라이브러리입니다._
+
+### 스마트 계약 {#smart-contracts}
+
+JavaScript 개발자이고 직접 스마트 계약을 작성하고 싶다면, [Solidity](https://solidity.readthedocs.io)에 익숙해지는 것이 좋습니다. 이것은 가장 인기 있는 스마트 계약 언어이며, 구문이 JavaScript와 유사하여 배우기 쉬울 수 있습니다.
+
+[스마트 계약](/developers/docs/smart-contracts/)에 대해 더 알아보기.
+
+## 프로토콜 이해하기 {#understand-the-protocol}
+
+### 이더리움 가상 머신 {#the-ethereum-virtual-machine}
+
+[이더리움 가상 머신](/developers/docs/evm/)의 JavaScript 구현이 있습니다. 최신 포크 규칙을 지원합니다. 포크 규칙은 계획된 업그레이드의 결과로 EVM에 가해진 변경 사항을 의미합니다.
+
+다양한 JavaScript 패키지로 나뉘어 있으며, 이를 확인하여 더 잘 이해할 수 있습니다:
+
+- 계정
+- 블록
+- 블록체인 자체
+- 트랜잭션
+- 기타 등등...
+
+이것은 "계정의 데이터 구조가 무엇인가?"와 같은 것들을 이해하는 데 도움이 됩니다.
+
+코드를 읽는 것을 선호한다면, 이 JavaScript는 문서를 읽는 것에 대한 훌륭한 대안이 될 수 있습니다.
+
+**EVM 자세히 알아보기**
+[`@ethereumjs/evm`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm)
+
+### 노드 및 클라이언트 {#nodes-and-clients}
+
+이해할 수 있는 언어인 JavaScript로 이더리움 클라이언트가 어떻게 작동하는지 파악할 수 있는 Ethereumjs 클라이언트가 활발히 개발 중입니다.
+
+**클라이언트 자세히 알아보기**
+[`@ethereumjs/client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client)
+
+## 기타 프로젝트 {#other-projects}
+
+이더리움 JavaScript 분야에서는 다음과 같은 많은 일들이 일어나고 있습니다:
+
+- 지갑 유틸리티 라이브러리.
+- 이더리움 키를 생성, 가져오기, 내보내기 위한 도구들.
+- `merkle-patricia-tree`의 구현 – 이더리움 옐로우 페이퍼에 기술된 데이터 구조입니다.
+
+[EthereumJS 리포지토리](https://github.com/ethereumjs)에서 가장 관심 있는 것을 깊이 파고들어 보세요.
+
+## 더 읽어보기 {#further-reading}
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
diff --git a/public/content/translations/ko/developers/docs/programming-languages/python/index.md b/public/content/translations/ko/developers/docs/programming-languages/python/index.md
new file mode 100644
index 00000000000..3e26f8fe47e
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/programming-languages/python/index.md
@@ -0,0 +1,99 @@
+---
+title: "Python 개발자를 위한 이더리움"
+description: "Python 기반 프로젝트 및 툴링을 사용한 이더리움 개발 방법 알아보기"
+lang: ko
+incomplete: true
+---
+
+Python 기반 프로젝트 및 툴링을 사용한 이더리움 개발 방법 알아보기
+
+이더리움 기반으로 개발된 탈중앙화 애플리케이션(또는 “디앱”)은 암호화폐와 블록체인 기술의 장점을 가지게 됩니다. 탈중앙화 애플리케이션은 일단 이더리움에 배포되면 항상 프로그래밍된 대로 동작하므로 완전히 신뢰할 수 있습니다. 그러므로 새로운 형태의 금융 애플리케이션을 제작하기 위해 디지털 자산을 제어하는 데 사용될 수 있습니다. 그뿐만 아니라 해당 금융 애플리케이션을 어떤 특정 단체나 개인이 제어할 수 없고 검열이 거의 불가능하도록 탈중앙화할 수 있습니다.
+
+## 스마트 계약 및 솔리디티 언어 시작하기 {#getting-started-with-smart-contracts-and-solidity}
+
+**Python과 이더리움을 통합하기 위한 첫 단계**
+
+먼저 기본 지식이 더 필요하시나요? [ethereum.org/learn](/learn/) 또는 [ethereum.org/developers](/developers/)를 확인해 보세요.
+
+- [블록체인 설명](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [스마트 계약 이해하기](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [첫 스마트 계약 작성하기](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [솔리디티 컴파일 및 배포 방법 알아보기](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [2023년 블록체인 파이썬 현황 보고서](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023)
+
+## 초급자용 아티클 {#beginner-articles}
+
+- [web3.py 개요](https://web3py.readthedocs.io/en/latest/overview.html)
+- [이더리움 파이썬 생태계 둘러보기](https://snakecharmers.ethereum.org/python-ecosystem/)
+- [파이썬 개발자를 위한 이더리움 가이드](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/)
+- [수상을 위한: 이더리움 파이썬 해커톤 가이드](https://snakecharmers.ethereum.org/prize-worthy/)
+- [Vyper를 사용한 스마트 계약 소개](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/)
+- [Python Flask를 사용하여 이더리움 계약을 개발하는 방법](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e)
+- [Web3.py 소개 · 파이썬 개발자를 위한 이더리움](https://www.dappuniversity.com/articles/web3-py-intro)
+- [파이썬과 web3.py를 사용하여 스마트 계약 함수를 호출하는 방법](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py)
+
+## 중급자용 아티클 {#intermediate-articles}
+
+- [web3.py 관련 도구: Ape 소개](https://snakecharmers.ethereum.org/intro-to-ape/)
+- [파이썬 프로그래머를 위한 탈중앙화앱 개발](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28)
+- [파이썬 이더리움 인터페이스 만들기: 1부](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d)
+- [파이썬의 이더리움 스마트 계약: 종합에 가까운 가이드](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988)
+
+## 고급 사용 패턴 {#advanced-use-patterns}
+
+- [web3.py 패턴: 실시간 이벤트 구독](https://snakecharmers.ethereum.org/subscriptions/)
+- [web3.py 패턴: WebSocketProvider](https://snakecharmers.ethereum.org/websocketprovider/)
+- [파이썬을 사용하여 이더리움 스마트 계약 컴파일, 배포 및 호출하기](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/)
+- [Slither로 솔리디티 스마트 계약 분석하기](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither)
+- [블록체인 핀테크 튜토리얼: 파이썬으로 대출 및 차입 구현하기](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/)
+
+## 보관된 아티클
+
+- [파이썬과 브라우니로 나만의 ERC20 토큰 배포하기](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58)
+- [브라우니와 파이썬을 사용하여 스마트 계약 배포하기](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp)
+- [브라우니로 OpenSea에서 NFT 만들기](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/)
+
+## 파이썬 프로젝트 및 도구 {#python-projects-and-tools}
+
+### 활성: {#active}
+
+- [Web3.py](https://github.com/ethereum/web3.py) - _이더리움과 상호작용하기 위한 파이썬 라이브러리_
+- [Vyper](https://github.com/ethereum/vyper/) - _EVM을 위한 파이썬다운 스마트 계약 언어_
+- [Ape](https://github.com/ApeWorX/ape) - _Python 개발자, 데이터 과학자 및 보안 전문가를 위한 스마트 계약 개발 도구_
+- [py-evm](https://github.com/ethereum/py-evm) - _이더리움 가상 머신(EVM) 구현_
+- [eth-tester](https://github.com/ethereum/eth-tester) - _이더리움 기반 애플리케이션 테스트용 도구_
+- [eth-utils](https://github.com/ethereum/eth-utils/) - _이더리움 관련 코드베이스 작업을 위한 유틸리티 함수_
+- [py-solc-x](https://pypi.org/project/py-solc-x/) - _0.5.x 버전을 지원하는 solc 솔리디티 컴파일러용 파이썬 래퍼_
+- [pymaker](https://github.com/makerdao/pymaker) - _메이커 계약을 위한 파이썬 API_
+- [siwe](https://github.com/signinwithethereum/siwe-py) - _파이썬용 이더리움으로 로그인하기(siwe)_
+- [이더리움 통합을 위한 Web3 DeFi](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _ERC-20, Uniswap 및 기타 인기 프로젝트와 즉시 통합할 수 있는 파이썬 패키지_
+- [Wake](https://getwake.io) - _계약 테스트, 퍼징, 배포, 취약점 스캔 및 코드 탐색을 위한 올인원 파이썬 프레임워크(언어 서버 - [솔리디티용 도구](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_
+
+### 보관됨 / 더 이상 유지보수되지 않음: {#archived--no-longer-maintained}
+
+- [Trinity](https://github.com/ethereum/trinity) - _이더리움 파이썬 클라이언트_
+- [Mamba](https://github.com/arjunaskykok/mamba) - _Vyper 언어로 작성된 스마트 계약을 작성, 컴파일 및 배포하기 위한 프레임워크_
+- [Brownie](https://github.com/eth-brownie/brownie) - _이더리움 스마트 계약을 배포, 테스트 및 상호작용하기 위한 파이썬 프레임워크_
+- [pydevp2p](https://github.com/ethereum/pydevp2p) - _이더리움 P2P 스택 구현_
+- [py-wasm](https://github.com/ethereum/py-wasm) - _웹 어셈블리 인터프리터의 파이썬 구현_
+
+더 많은 참고 자료를 확인하고 싶으신가요? [ethereum.org/developers](/developers/)를 확인해 보세요.
+
+## 파이썬 툴링을 사용하는 프로젝트 {#projects-using-python-tooling}
+
+아래 이더리움 기반 프로젝트들은 본 페이지에서 언급된 도구를 사용합니다. 모범 사례와 함께 링크된 오픈 소스 저장소에서 좋은 예제 코드를 참조할 수 있습니다.
+
+- [Yearn Finance](https://yearn.finance/) 및 [Yearn Vault 계약 저장소](https://github.com/yearn/yearn-vaults)
+- [Curve](https://www.curve.finance/) 및 [Curve 스마트 계약 저장소](https://github.com/curvefi/curve-contract)
+- [BadgerDAO](https://badger.com/) 및 [브라우니 툴체인을 사용하는 스마트 계약](https://github.com/Badger-Finance/badger-system)
+- [Sushi](https://sushi.com/)는 [베스팅 계약을 관리하고 배포하는 데 파이썬을 사용합니다](https://github.com/sushiswap/sushi-vesting-protocols)
+- Alpha Homora로 유명한 [Alpha Finance](https://alphafinance.io/)는 [스마트 계약을 테스트하고 배포하는 데 브라우니를 사용합니다](https://github.com/AlphaFinanceLab/alpha-staking-contract)
+
+## 파이썬 커뮤니티 토론 {#python-community-contributors}
+
+- Web3.py 및 기타 파이썬 프레임워크 토론을 위한 [이더리움 파이썬 커뮤니티 디스코드](https://discord.gg/9zk7snTfWe)
+- Vyper 스마트 계약 프로그래밍 토론을 위한 [Vyper 디스코드](https://discord.gg/SdvKC79cJk)
+
+## 기타 수집된 목록 {#other-aggregated-lists}
+
+Vyper 위키에는 [Vyper를 위한 훌륭한 참고 자료 목록](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources)이 있습니다.
\ No newline at end of file
diff --git a/public/content/translations/ko/developers/docs/programming-languages/ruby/index.md b/public/content/translations/ko/developers/docs/programming-languages/ruby/index.md
new file mode 100644
index 00000000000..56c0139362d
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/programming-languages/ruby/index.md
@@ -0,0 +1,60 @@
+---
+title: "루비 개발자를 위한 이더리움"
+description: "루비 기반 프로젝트와 툴링을 사용해 이더리움용으로 개발하는 방법을 알아보세요."
+lang: ko
+incomplete: false
+---
+
+루비 기반 프로젝트와 툴링을 사용해 이더리움용으로 개발하는 방법을 알아보세요.
+
+이더리움 기반으로 개발된 탈중앙화 애플리케이션(또는 “디앱”)은 암호화폐와 블록체인 기술의 장점을 가지게 됩니다. 이러한 탈중앙화앱은 무신뢰성을 가질 수 있습니다. 즉, 이더리움에 배포되면 항상 프로그래밍된 대로 실행됩니다. 탈중앙화앱은 디지털 자산을 제어하여 새로운 종류의 금융 애플리케이션을 만들 수 있습니다. 그뿐만 아니라 해당 금융 애플리케이션을 어떤 특정 단체나 개인이 제어할 수 없고 검열이 거의 불가능하도록 탈중앙화할 수 있습니다.
+
+## 스마트 계약 및 솔리디티 언어 시작하기 {#getting-started-with-smart-contracts-and-solidity}
+
+**루비와 이더리움을 통합하기 위한 첫걸음을 내딛어 보세요**
+
+먼저 기본 지식이 더 필요하시나요? [ethereum.org/learn](/learn/) 또는 [ethereum.org/developers](/developers/)를 확인해 보세요.
+
+- [블록체인 설명](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [스마트 계약 이해하기](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [첫 스마트 계약 작성하기](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [솔리디티 컴파일 및 배포 방법 알아보기](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## 초급자용 아티클 {#beginner-articles}
+
+- [드디어 이더리움 계정 이해하기](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe)
+- [드디어 MetaMask로 Rails 사용자 인증하기](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj)
+- [루비를 사용하여 이더리움 네트워크에 연결하는 방법](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby)
+- [루비에서 새로운 이더리움 주소를 생성하는 방법](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby)
+
+## 중급자용 아티클 {#intermediate-articles}
+
+- [루비를 사용한 블록체인 앱](https://www.nopio.com/blog/blockchain-app-ruby/)
+- [이더리움에 연결된 루비를 사용하여 스마트 계약 실행하기](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9)
+
+## 루비 프로젝트 및 도구 {#ruby-projects-and-tools}
+
+### 활성 {#active}
+
+- [eth.rb](https://github.com/q9f/eth.rb) - _이더리움 계정, 메시지, 트랜잭션을 처리하기 위한 루비 라이브러리 및 RPC 클라이언트_
+- [keccak.rb](https://github.com/q9f/keccak.rb) - _이더리움에서 사용되는 Keccak(SHA3) 해시_
+- [siwe-ruby](https://github.com/signinwithethereum/siwe-ruby) - _이더리움으로 로그인(Sign-In with Ethereum)의 루비 구현_
+- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) - _SIWE 로컬 로그인 라우트를 추가하는 Rails gem_
+- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) - _커스텀 컨트롤러를 사용하여 Ruby on Rails를 이용한 SIWE 예제_
+- [omniauth-siwe](https://github.com/signinwithethereum/omniauth-siwe) - _이더리움으로 로그인(SIWE)을 위한 OmniAuth 전략_
+- [omniauth-nft](https://github.com/valthon/omniauth-nft) - _NFT 소유권을 통해 인증하기 위한 OmniAuth 전략_
+- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) - _MetaMask를 Ruby on Rails에 연결할 수 있는 Ethereum on Rails 템플릿_
+
+### 보관됨 / 더 이상 유지 관리되지 않음 {#archived--no-longer-maintained}
+
+- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) - _루비를 사용하여 이더리움 노드의 RPC 메서드 호출_
+- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) - _BIP32 표준에 따라 계층적 결정적 지갑에서 ETH 주소를 생성하기 위한 루비 라이브러리_
+- [etherlite](https://github.com/budacom/etherlite) - _Ruby on Rails를 위한 이더리움 통합_
+- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) - _트랜잭션 전송, 계약 생성 및 상호 작용을 위해 JSON-RPC 인터페이스를 사용하는 루비 이더리움 클라이언트이자 이더리움 노드와 함께 작동하는 유용한 툴킷_
+- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) - _OmniAuth를 위한 이더리움 공급자 전략 구현_
+
+더 많은 참고 자료를 확인하고 싶으신가요? 저희 [개발자 홈](/developers/)을 확인해 보세요.
+
+## 루비 커뮤니티 기여자 {#ruby-community-contributors}
+
+[이더리움 루비 텔레그램 그룹](https://t.me/ruby_eth)은 빠르게 성장하는 커뮤니티의 장이며, 위에 언급된 모든 프로젝트 및 관련 주제에 대한 논의를 위한 전용 참고 자료입니다.
diff --git a/public/content/translations/ko/developers/docs/programming-languages/rust/index.md b/public/content/translations/ko/developers/docs/programming-languages/rust/index.md
new file mode 100644
index 00000000000..a266282c6b5
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/programming-languages/rust/index.md
@@ -0,0 +1,65 @@
+---
+title: "Rust 개발자를 위한 이더리움"
+description: "Rust 기반 프로젝트 및 툴링을 사용한 이더리움 개발 방법 알아보기"
+lang: ko
+incomplete: true
+---
+
+Rust 기반 프로젝트 및 툴링을 사용하여 이더리움을 개발하는 방법을 알아보세요
+
+이더리움 기반으로 개발된 탈중앙화 애플리케이션(또는 “디앱”)은 암호화폐와 블록체인 기술의 장점을 가지게 됩니다. 탈중앙화 애플리케이션은 일단 이더리움에 배포되면 항상 프로그래밍된 대로 동작하므로 완전히 신뢰할 수 있습니다. 그러므로 새로운 형태의 금융 애플리케이션을 제작하기 위해 디지털 자산을 제어하는 데 사용될 수 있습니다. 그뿐만 아니라 해당 금융 애플리케이션을 어떤 특정 단체나 개인이 제어할 수 없고 검열이 거의 불가능하도록 탈중앙화할 수 있습니다.
+
+## 스마트 계약 및 솔리디티 언어 시작하기 {#getting-started-with-smart-contracts-and-solidity}
+
+**러스트와 이더리움을 통합하기 위한 첫 단계**
+
+먼저 기본 지식이 더 필요하시나요? [ethereum.org/learn](/learn/) 또는 [ethereum.org/developers](/developers/)를 확인해 보세요.
+
+- [블록체인 설명](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [스마트 계약 이해하기](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [첫 스마트 계약 작성하기](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [솔리디티 컴파일 및 배포 방법 알아보기](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## 초급자용 아티클 {#beginner-articles}
+
+- [Rust 이더리움 클라이언트](https://openethereum.github.io/) \* **참고: OpenEthereum은 [더 이상 사용되지 않으며](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) 더 이상 유지 관리되지 않습니다.** 주의하여 사용하고 가급적 다른 클라이언트 구현으로 전환하십시오.
+- [Rust를 사용하여 이더리움으로 트랜잭션 보내기](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/)
+- [Kovan용 rust Wasm으로 컨트랙트를 작성하는 방법에 대한 단계별 튜토리얼](https://github.com/paritytech/pwasm-tutorial)
+
+## 중급자용 아티클 {#intermediate-articles}
+
+## 고급 사용 패턴 {#advanced-use-patterns}
+
+- [이더리움과 유사한 네트워크와 상호작용하기 위한 pwasm_ethereum 외부 라이브러리](https://github.com/openethereum/pwasm-ethereum)
+
+- [JavaScript와 Rust를 사용하여 탈중앙화 채팅 구축하기](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52)
+
+- [Vue.js와 Rust를 사용하여 탈중앙화 Todo 앱 구축하기](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb)
+
+- [Rust로 블록체인 구축하기](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/)
+
+## Rust 프로젝트 및 도구 {#rust-projects-and-tools}
+
+- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _이더리움과 유사한 네트워크와 상호작용하기 위한 외부 모음_
+- [Lighthouse](https://github.com/sigp/lighthouse) - _빠른 이더리움 합의 레이어 클라이언트_
+- [Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) - _결정론적 WebAssembly 하위 집합을 사용한 이더리움 스마트 계약 실행 레이어의 제안된 재설계_
+- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _OASIS API 레퍼런스_
+- [Solaris](https://github.com/paritytech/sol-rs) - _네이티브 Parity 클라이언트 EVM을 사용하는 Solidity 스마트 계약 단위 테스트 하네스._
+- [SputnikVM](https://github.com/rust-blockchain/evm) - _Rust 이더리움 가상 머신 구현_
+- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _Rust의 Wavelet 스마트 계약_
+- [Foundry](https://github.com/foundry-rs/foundry) - _이더리움 애플리케이션 개발을 위한 툴킷_
+- [Alloy](https://alloy.rs) - _이더리움 및 기타 EVM 기반 체인과 상호작용하기 위한 고성능의 잘 테스트되고 문서화된 라이브러리._
+- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _이더리움 라이브러리 및 지갑 구현_
+- [SewUp](https://github.com/second-state/SewUp) - _일반적인 백엔드에서 개발하는 것처럼 Rust로 이더리움 웹어셈블리 계약을 구축하는 데 도움이 되는 라이브러리_
+- [Substreams](https://github.com/streamingfast/substreams) - _병렬화된 블록체인 데이터 인덱싱 기술_
+- [Reth](https://github.com/paradigmxyz/reth) Reth(Rust Ethereum의 줄임말)는 새로운 이더리움 전체 노드 구현입니다
+- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) - _Rust로 작성된 이더리움 생태계의 프로젝트 큐레이션 모음_
+
+더 많은 참고 자료를 확인하고 싶으신가요? [ethereum.org/developers.](/developers/)를 확인해 보세요.
+
+## Rust 커뮤니티 기여자 {#rust-community-contributors}
+
+- [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby)
+- [Oasis Gitter](https://gitter.im/Oasis-official/Lobby)
+- [Parity Gitter](https://gitter.im/paritytech/parity)
+- [Enigma](https://discord.gg/SJK32GY)
diff --git a/public/content/translations/ko/developers/docs/scaling/index.md b/public/content/translations/ko/developers/docs/scaling/index.md
new file mode 100644
index 00000000000..774bb3e56f9
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/scaling/index.md
@@ -0,0 +1,113 @@
+---
+title: "확장"
+description: "현재 Ethereum 커뮤니티에서 개발 중인 다양한 레이어 롤업 스케일링 솔루션에 대한 소개"
+lang: ko
+sidebarDepth: 3
+---
+
+## 확장 개요 {#scaling-overview}
+
+이더리움을 사용하는 사람들이 증가함에 따라 블록체인은 여러 가지 용량 제한에 도달했습니다. 이 때문에 네트워크 사용 비용은 높아졌으며 "확장 솔루션"이 필요하게 되었습니다. 유사한 목표를 달성하기 위해 다양한 접근 방식을 취하는 여러 솔루션이 연구, 테스트 및 구현되고 있습니다.
+
+확장성의 주요 목표는 탈중앙성이나 보안을 희생하지 않으면서 트랜잭션 속도(더 빠른 완결성)와 트랜잭션 처리량(초당 더 많은 트랜잭션)을 높이는 것입니다. 레이어 1 이더리움 블록체인에서는 수요가 높으면 트랜잭션이 느려지고 [가스 가격](/developers/docs/gas/)이 비현실적으로 높아집니다. 속도와 처리량 측면에서 네트워크 용량을 늘리는 것은 이더리움의 의미 있는 대규모 채택을 위해 기본적입니다.
+
+속도와 처리량이 중요하지만, 이러한 목표를 가능하게 하는 확장 솔루션이 탈중앙화되고 안전하게 유지되는 것이 필수적입니다. 노드 운영자의 진입 장벽을 낮게 유지하는 것은 중앙집중화되고 안전하지 않은 컴퓨팅 파워로의 진행을 방지하는 데 중요합니다.
+
+개념적으로 우리는 먼저 확장을 온체인 또는 오프라인 확장으로 분류합니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+모든 기초 주제에 대해 잘 이해하고 있어야 합니다. 확장 솔루션을 구현하는 것은 기술이 덜 검증되었고 지속적으로 연구 및 개발되고 있기 때문에 고급 단계입니다.
+
+## 온체인 확장 {#onchain-scaling}
+
+온체인 확장은 이더리움 프로토콜(레이어 1 [메인넷](/glossary/#mainnet))의 변경을 필요로 합니다. 오랫동안 블록체인 샤딩은 이더리움을 확장할 것으로 예상되었습니다. 이는 블록체인을 개별 조각(샤드)으로 분할하여 검증자 하위 집합에 의해 검증되도록 하는 것을 포함할 예정이었습니다. 그러나 레이어 2 롤업을 통한 확장이 주요 확장 기술로 자리잡았습니다. 이는 사용자에게 롤업을 저렴하게 만들기 위해 특별히 설계된 이더리움 블록에 첨부된 새로운 저렴한 형태의 데이터 추가로 지원됩니다.
+
+### 샤딩 {#sharding}
+
+샤딩은 데이터베이스를 분할하는 과정입니다. 검증자의 하위 집합이 이더리움 전체를 추적하는 대신 개별 샤드를 담당하게 됩니다. 샤딩은 오랫동안 이더리움 [로드맵](/roadmap/)에 있었으며, 한때 지분 증명으로 전환하는 더 머지 이전에 출시될 예정이었습니다. 하지만 [레이어 2 롤업](#layer-2-scaling)의 빠른 개발과 [댕크샤딩](/roadmap/danksharding)(검증자가 매우 효율적으로 검증할 수 있는 롤업 데이터 블롭을 이더리움 블록에 추가하는 것)의 발명으로 이더리움 커뮤니티는 샤딩을 통한 확장 대신 롤업 중심의 확장을 선호하게 되었습니다. 이는 또한 이더리움의 합의 로직을 더 단순하게 유지하는 데 도움이 될 것입니다.
+
+## 오프체인 확장 {#offchain-scaling}
+
+오프체인 솔루션은 레이어 1 메인넷과는 별도로 구현됩니다- 그들은 현재의 이더리움 프로토콜에 변화를 요구하지 않습니다. "레이어 2" 솔루션으로 알려진 일부 솔루션은 [낙관적 롤업](/developers/docs/scaling/optimistic-rollups/), [영지식 롤업](/developers/docs/scaling/zk-rollups/) 또는 [상태 채널](/developers/docs/scaling/state-channels/)과 같이 레이어 1 이더리움 합의에서 직접 보안을 확보합니다. 다른 솔루션들은 [사이드체인](#sidechains), [밸리디움](#validium), 또는 [플라즈마 체인](#plasma)과 같이 메인넷과 별개로 보안을 확보하는 다양한 형태의 새로운 체인 생성을 포함합니다. 이러한 솔루션들은 메인넷과 통신하지만 다양한 목표를 달성하기 위해 보안을 다르게 도출합니다.
+
+### 레이어 2 확장 {#layer-2-scaling}
+
+이러한 오프체인 해결책의 분류는.
+
+레이어 2는 당신의 어플리케이션을 확장시킬 수 있도록 하기 위해 Ethereum 메인넷 (레이어 1) 에서 트랜잭션을 처리하면서 메인넷의 탈중앙화된 강력한 보안 모델을 활용하도록 설계된 솔루션을 총칭합니다. 네트워크가 혼잡할 때는 트랜잭션 속도가 저하되어, 특정 유형의 dapp에서는 사용자 환경이 좋지 않습니다. 네트워크가 더 혼잡해지면, 트랜잭션 발신자들 서로가 가격을 비싸게 매기게 되면서 가스 가격이 상승합니다. 이러한 현상은 Ethereum을 더욱 비싸게 만듭니다.
+
+대부분의 레이어 2 솔루션은 서버 또는 서버 클러스터를 중심으로 구성되며, 각각을 노드, 검증자, 운영자, 시퀀서, 블록 프로듀서 또는 유사한 용어로 지칭할 수 있습니다. 구현에 따라 이러한 레이어 2 노드는 이를 사용하는 개인, 기업 또는 단체에 의해 운영되거나, 제3자 운영자에 의해 운영되거나, 많은 개인 그룹에 의해 운영될 수 있습니다(메인넷과 유사). 일반적으로 거래는 레이어 1(메인넷)에 직접 제출되는 대신 이러한 레이어 2 노드에 제출됩니다. 몇 가지 해결책으로, 레이어 2 인스턴스는 데이터를 그룹으로 일괄 배치하고 레이어 1 에 고정합니다. 그런 뒤 데이터는 레이어 1 에 의해 보호되고 변경할 수 없습니다. 이 작업이 수행되는 방식의 세부 사항은 다양한 레이어 2 기술 및 구현 간에 크게 다릅니다.
+
+특정 레이어 2 인스턴스는 많은 애플리케이션이 열어 공유할 수도 있고, 하나의 프로젝트에 의해 배포되어 해당 애플리케이션만 지원하도록 전용될 수도 있습니다.
+
+#### 레이어 2란 무엇인가요? {#why-is-layer-2-needed}
+
+- 초당 거래 수의 증가는 사용자 경험을 크게 향상시키고 메인넷 이더리움의 네트워크 혼잡을 줄입니다.
+- 거래는 메인넷 이더리움으로 하나의 거래로 롤업되며, 이를 통해 사용자에게 가스 요금을 줄이고 이더리움을 모든 사람에게 더 포괄적이고 접근 가능하게 만듭니다.
+- 확장성에 관한 어떤 업데이트도 분산 및 보안을 희생해서는 안됩니다 - Ethereum의 가장 위에 레이어 2가 세워집니다.
+- 규모에 맞게 자산을 다룰 때 자체적인 효율성을 제공하는 애플리케이션 전용 레이어 2 네트워크가 있습니다.
+
+[레이어 2에 대해 더 알아보기](/layer-2/).
+
+#### 롤업 {#rollups}
+
+롤업은 트랜잭션 실행을 레이어 1 외부에서 수행한 다음 데이터를 레이어 1에 게시하여 합의가 이루어집니다. 트랜잭션 데이터가 레이어 1 블록에 포함되기 때문에 롤업은 이더리움 네이티브 보안에 의해 보호됩니다.
+
+다른 보안 모델을 가지는 두 가지 종류의 롤업이 있습니다:
+
+- **낙관적 롤업**: 트랜잭션이 기본적으로 유효하다고 가정하고, 이의가 제기될 경우에만 [**사기 증명**](/glossary/#fraud-proof)을 통해 연산을 실행합니다. [낙관적 롤업에 대해 더 알아보기](/developers/docs/scaling/optimistic-rollups/).
+- **영지식 롤업**: 오프체인에서 연산을 실행하고 체인에 [**유효성 증명**](/glossary/#validity-proof)을 제출합니다. [영지식 롤업에 대해 더 알아보기](/developers/docs/scaling/zk-rollups/).
+
+#### 상태 채널 {#channels}
+
+상태 채널은 다중 계약을 사용해 참여자들이 오프체인에서 거래를 빠르고 자유롭게 거래한 뒤 메인넷에서 거래를 확정하게 합니다. 이것은 네트워크 혼잡, 수수료 그리고 딜레이를 최소화 합니다. 현재 두 가지 채널 유형은 State 채널과 Payment 채널입니다.
+
+[상태 채널에 대해 더 알아보기](/developers/docs/scaling/state-channels/).
+
+### 사이드체인 {#sidechains}
+
+사이드체인은 메인넷과 병렬로 실행되는 독립적인 EVM 호환 블록체인입니다. 이들은 이더리움과 양방향 브리지로 호환되며, 독자적인 합의 규칙과 블록 매개변수를 따릅니다.
+
+[사이드체인에 대해 더 알아보기](/developers/docs/scaling/sidechains/).
+
+### 플라즈마 {#plasma}
+
+플라즈마 체인은 메인 이더리움 체인에 고정된 별도의 블록체인으로, 분쟁 중재를 위해 ([낙관적 롤업](/developers/docs/scaling/optimistic-rollups/)처럼) 사기 증명을 사용합니다.
+
+[플라즈마에 대해 더 알아보기](/developers/docs/scaling/plasma/).
+
+### 밸리디움 {#validium}
+
+Validium 체인은 Zero-knowledge 롤업과 유사한 유효성 증명을 사용하지만 데이터는 메인 레이어 1 이더리움 체인에 저장되지 않습니다. 이로 인해 Validium 체인당 초당 10,000건의 트랜잭션이 가능하며, 여러 체인이 병렬로 실행될 수 있습니다.
+
+[밸리디움에 대해 더 알아보기](/developers/docs/scaling/validium/).
+
+## 왜 이렇게 많은 확장 솔루션이 필요한가요? {#why-do-we-need-these}
+
+- 여러 솔루션은 네트워크의 특정 부분에 대한 혼잡을 줄이고 단일 장애 지점을 방지할 수 있습니다.
+- 전체는 각 부분의 합보다 큽니다. 다양한 솔루션이 공존하고 조화를 이루어 미래의 트랜잭션 속도와 처리량에 기하급수적인 영향을 미칠 수 있습니다.
+- 모든 솔루션이 이더리움 합의 알고리즘을 직접 활용할 필요는 없으며, 대안은 얻기 어려운 이점을 제공할 수 있습니다.
+
+## 시각 자료를 찾고 있나요? 시각적 학습자
+
+
+
+ event Signed:
+ book_msg: BookMsg
+
+ pub def sign(book_msg: BookMsg):
+ self.guest_book[msg.sender] = book_msg
+
+ emit Signed(book_msg=book_msg)
+
+ pub def get_msg(addr: address) -> BookMsg:
+ return self.guest_book[addr].to_mem()
+
+```
+
+## 선택 방법 {#how-to-choose}
+
+다른 프로그래밍 언어와 마찬가지로 작업에 적합한 도구를 선택하는 것이 중요하며, 개인적인 선호도도 고려해야 합니다.
+
+솔리디티의 장점은 무엇인가요?
+
+### 초보자에게는 다양한 튜토리얼과 학습 도구가 있습니다. {#solidity-advantages}
+
+- 코딩으로 배우기 섹션에서 더 알아볼 수 있습니다. 자세한 내용은 [코딩으로 배우기](/developers/learning-tools/) 섹션을 참조하세요.
+- 좋은 개발자 툴링을 사용할 수 있습니다.
+- 솔리디티는 큰 개발자 커뮤니티가 있어 질문에 대한 답변을 쉽게 찾을 수 있습니다.
+
+### Vyper의 장점은 무엇인가요? {#vyper-advatages}
+
+- 스마트 계약을 작성하고자 하는 Python 개발자에게 훌륭한 출발점입니다.
+- 기능 수가 적어 아이디어를 빠르게 프로토타입하는 데 적합합니다.
+- Vyper는 감사하기 쉽고 가독성이 뛰어납니다.
+
+### Yul과 Yul+의 장점은 무엇인가요? {#yul-advantages}
+
+- 간단하고 기능적인 저수준 언어입니다.
+- 계약의 가스 사용량 최적화에 도움이 되는 원시 EVM에 더 가깝게 접근할 수 있습니다.
+
+## 언어 비교 {#language-comparisons}
+
+기본 구문, 계약 수명 주기, 인터페이스, 연산자, 데이터 구조, 함수, 제어 흐름 등을 비교하려면 Auditless의 [치트 시트](https://reference.auditless.com/cheatsheet/)를 확인하세요.
+
+## 더 읽어보기 {#further-reading}
+
+- [OpenZeppelin의 솔리디티 계약 라이브러리](https://docs.openzeppelin.com/contracts/5.x/)
+- [예제로 배우는 솔리디티](https://solidity-by-example.org)
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/libraries/index.md b/public/content/translations/ko/developers/docs/smart-contracts/libraries/index.md
new file mode 100644
index 00000000000..fb9c6f499c5
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/libraries/index.md
@@ -0,0 +1,117 @@
+---
+title: "스마트 계약 라이브러리"
+description: "재사용 가능한 스마트 계약 라이브러리 및 구성 요소를 찾아 이더리움 개발 프로젝트를 가속화하세요."
+lang: ko
+---
+
+프로젝트에서 모든 스마트 계약을 처음부터 작성할 필요가 없습니다. 프로젝트에 재사용 가능한 빌딩 블록을 제공하는 많은 오픈 소스 스마트 계약 라이브러리가 있어, 처음부터 모든 것을 다시 만들 필요 없이 시간을 절약할 수 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+스마트 계약 라이브러리에 뛰어들기 전에, 스마트 계약의 구조를 잘 이해하는 것이 좋습니다. 아직 확인하지 않았다면 [스마트 계약 구조](/developers/docs/smart-contracts/anatomy/)로 이동하세요.
+
+## 라이브러리 구성 {#whats-in-a-library}
+
+스마트 계약 라이브러리에서는 보통 두 가지 유형의 빌딩 블록을 찾을 수 있습니다: 계약에 추가할 수 있는 재사용 가능한 동작과 다양한 표준의 구현입니다.
+
+### 동작 {#behaviors}
+
+스마트 계약을 작성할 때, 계약에서 보호된 작업을 수행하기 위해 _admin_ 주소를 할당하거나 예기치 않은 문제가 발생했을 때 긴급 _pause_ 버튼을 추가하는 것처럼, 유사한 패턴을 여러 번 작성하게 될 가능성이 큽니다.
+
+스마트 계약 라이브러리는 일반적으로 솔리디티(Solidity)에서 [라이브러리](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) 또는 [상속](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance)을 통해 이러한 동작의 재사용 가능한 구현을 제공합니다.
+
+예를 들어, 다음은 [OpenZeppelin Contracts 라이브러리](https://github.com/OpenZeppelin/openzeppelin-contracts)의 [`Ownable` 계약](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol)의 간소화된 버전입니다. 이 계약은 주소를 계약의 소유자로 지정하고 해당 소유자에게만 메서드에 대한 접근을 제한하는 제어자를 제공합니다.
+
+```solidity
+contract Ownable {
+ address public owner;
+
+ constructor() internal {
+ owner = msg.sender;
+ }
+
+ modifier onlyOwner() {
+ require(owner == msg.sender, "Ownable: 호출자가 소유자가 아닙니다");
+ _;
+ }
+}
+```
+
+이러한 빌딩 블록을 계약에 사용하려면 먼저 이를 가져와 계약에서 확장해야 합니다. 이를 통해 기본 `Ownable` 계약에서 제공하는 제어자를 사용하여 자신의 함수를 보호할 수 있습니다.
+
+```solidity
+import ".../Ownable.sol"; // 가져온 라이브러리의 경로
+
+contract MyContract is Ownable {
+ // 다음 함수는 소유자만 호출할 수 있습니다
+ function secured() onlyOwner public {
+ msg.sender.transfer(1 ether);
+ }
+}
+```
+
+또 다른 인기 있는 예는 [SafeMath](https://docs.openzeppelin.com/contracts/3.x/utilities#math) 또는 [DsMath](https://dappsys.readthedocs.io/en/latest/ds_math.html)입니다. 이들은 언어에서 제공되지 않는 오버플로우 검사를 포함한 산술 기능을 제공하는 라이브러리입니다. 계약을 오버플로우로부터 보호하기 위해 기본 산술 연산 대신 이러한 라이브러리 중 하나를 사용하는 것이 좋은 관행입니다.
+
+### 표준 {#standards}
+
+[구성 가능성 및 상호 운용성](/developers/docs/smart-contracts/composability/)을 촉진하기 위해 이더리움 커뮤니티는 **ERC** 형식으로 여러 표준을 정의했습니다. 자세한 내용은 [표준](/developers/docs/standards/) 섹션에서 확인할 수 있습니다.
+
+계약의 일부로 ERC를 포함할 때는, 직접 구현하는 대신 표준 구현을 찾는 것이 좋습니다. 많은 스마트 계약 라이브러리에는 가장 인기 있는 ERC의 구현이 포함되어 있습니다. 예를 들어, 널리 사용되는 [ERC20 대체 가능 토큰 표준](/developers/tutorials/understand-the-erc-20-token-smart-contract/)은 [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md), [DappSys](https://github.com/dapphub/ds-token/), [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20)에서 찾아볼 수 있습니다. 또한, 일부 ERC는 ERC 자체의 일부로 표준 구현을 제공합니다.
+
+몇몇 ERC는 독립적인 것이 아니라 다른 ERC에 추가로 제공되는 경우도 있습니다. 예를 들어, [ERC2612](https://eips.ethereum.org/EIPS/eip-2612)는 ERC20의 사용성 개선을 위한 확장 기능을 추가합니다.
+
+## 라이브러리 추가 방법 {#how-to}
+
+프로젝트에 라이브러리를 포함하는 구체적인 방법에 대해서는 항상 라이브러리의 문서를 참조하세요. 일부 솔리디티(Solidity) 계약 라이브러리는 `npm`을 사용하여 패키지로 제공되므로 `npm install`을 사용하여 간단히 설치할 수 있습니다. 계약 [컴파일](/developers/docs/smart-contracts/compiling/)을 위한 대부분의 도구는 스마트 계약 라이브러리를 `node_modules`에서 찾으므로 다음과 같이 할 수 있습니다.
+
+```solidity
+// node_modules에서 @openzeppelin/contracts 라이브러리를 로드합니다
+import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
+
+contract MyNFT is ERC721 {
+ constructor() ERC721("MyNFT", "MNFT") public { }
+}
+```
+
+사용하는 방법에 관계없이 라이브러리를 포함할 때는 항상 [언어](/developers/docs/smart-contracts/languages/) 버전을 주시해야 합니다. 예를 들면 솔리디티 0.5에서 계약을 작성하고 있는 경우 솔리디티 0.6 라이브러리를 사용할 수 없습니다.
+
+## 사용 시점 {#when-to-use}
+
+프로젝트에서 스마트 계약 라이브러리를 사용하는 것은 여러 가지 장점이 있습니다. 첫째, 직접 코딩하지 않고도 시스템에 포함할 수 있는 즉시 사용 가능한 빌딩 블록을 제공하여 시간을 절약할 수 있습니다.
+
+보안도 중요한 장점입니다. 오픈 소스 스마트 계약 라이브러리는 많은 프로젝트가 이를 의존하므로, 커뮤니티에서 지속적인 검토가 이루어집니다. 응용 프로그램 코드에서 오류를 발견하는 것이 재사용 가능한 계약 라이브러리에서 오류를 발견하는 것보다 훨씬 더 흔합니다. 응용 프로그램 코드에서 오류를 발견하는 것이 재사용 가능한 계약 라이브러리에서 오류를 발견하는 것보다 훨씬 더 흔합니다. 일부 라이브러리는 보안 강화를 위해 [외부 감사](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits)를 받기도 합니다.
+
+그러나 스마트 계약 라이브러리를 사용할 때는 익숙하지 않은 코드를 프로젝트에 포함할 위험이 있습니다. 계약을 가져와 프로젝트에 바로 포함시키는 것은 유혹적이지만, 해당 계약이 무엇을 하는지 잘 모르면, 예상치 못한 동작으로 인해 시스템에 문제를 도입할 수 있습니다. 가져온 코드의 문서를 읽고, 코드를 검토한 후 프로젝트의 일부로 만들도록 하세요!
+
+마지막으로 라이브러리를 포함할지 여부를 결정할 때, 그 라이브러리의 전체적인 사용성을 고려하세요. 광범위하게 채택된 라이브러리는 커뮤니티가 더 크고 더 많은 사람들이 문제를 점검할 가능성이 있습니다. 스마트 계약을 사용하여 구축할 때 보안을 최우선으로 생각해야 합니다!
+
+## 관련 도구 {#related-tools}
+
+**OpenZeppelin Contracts -** **_안전한 스마트 계약 개발을 위한 가장 인기 있는 라이브러리_**
+
+- [문서](https://docs.openzeppelin.com/contracts/)
+- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts)
+- [커뮤니티 포럼](https://forum.openzeppelin.com/c/general/16)
+
+**DappSys -** **_안전하고 단순하며 유연한 스마트 계약용 구성 요소_**
+
+- [문서](https://dappsys.readthedocs.io/)
+- [GitHub](https://github.com/dapphub/dappsys)
+
+**HQ20 -** **_실제 환경에서 모든 기능을 갖춘 분산 애플리케이션을 구축하는 데 도움이 되는 계약, 라이브러리 및 예제가 포함된 솔리디티(Solidity) 프로젝트_**
+
+- [GitHub](https://github.com/HQ20/contracts)
+
+**thirdweb 솔리디티(Solidity) SDK -** **_맞춤형 스마트 계약을 효율적으로 구축하는 데 필요한 도구를 제공합니다_**
+
+- [문서](https://portal.thirdweb.com/contracts/build/overview)
+- [GitHub](https://github.com/thirdweb-dev/contracts)
+
+## 관련 튜토리얼 {#related-tutorials}
+
+- [이더리움 개발자를 위한 보안 고려사항](/developers/docs/smart-contracts/security/) _– 라이브러리 사용을 포함하여 스마트 계약을 구축할 때의 보안 고려사항에 대한 튜토리얼입니다._
+- [ERC-20 토큰 스마트 계약 이해하기](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _- 여러 라이브러리에서 제공하는 ERC20 표준에 대한 튜토리얼입니다._
+
+## 더 읽어보기 {#further-reading}
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/naming/index.md b/public/content/translations/ko/developers/docs/smart-contracts/naming/index.md
new file mode 100644
index 00000000000..13ee813accc
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/naming/index.md
@@ -0,0 +1,101 @@
+---
+title: "스마트 계약 이름 지정"
+description: "ENS로 이더리움 스마트 계약 이름을 지정하는 모범 사례"
+lang: ko
+---
+
+스마트 계약은 이더리움 탈중앙화 인프라의 핵심으로, 자율적인 애플리케이션과 프로토콜을 가능하게 합니다. 하지만 계약 기능이 발전함에도 불구하고 사용자와 개발자는 여전히 원시 16진수 주소에 의존하여 이러한 계약을 식별하고 참조합니다.
+
+[Ethereum Name Service(ENS)](https://ens.domains/)로 스마트 계약에 이름을 지정하면 16진수 계약 주소를 제거하여 사용자 경험을 개선하고 주소 포이즈닝 및 스푸핑 공격과 같은 공격의 위험을 줄일 수 있습니다. 이 가이드에서는 스마트 계약 이름 지정이 중요한 이유, 구현 방법, 그리고 [Enscribe](https://www.enscribe.xyz)와 같이 프로세스를 간소화하고 개발자가 이 관행을 채택하는 데 도움이 되는 도구에 대해 설명합니다.
+
+## 스마트 계약에 이름을 지정하는 이유는 무엇일까요? {#why-name-contracts}
+
+### 사람이 읽을 수 있는 식별자 {#human-readable-identifiers}
+
+개발자와 사용자는 `0x8f8e...f9e3`과 같이 불투명한 계약 주소와 상호작용하는 대신 `v2.myapp.eth`와 같이 사람이 읽을 수 있는 이름을 사용할 수 있습니다. 이는 스마트 계약 상호작용을 간소화합니다.
+
+이는 이더리움 주소에 대한 탈중앙화 이름 지정 서비스를 제공하는 [Ethereum Name Service](https://ens.domains/)를 통해 가능합니다. 이는 인터넷 사용자가 `104.18.176.152`와 같은 IP 주소 대신 ethereum.org와 같은 이름을 사용하여 네트워크 주소에 접속할 수 있도록 하는 도메인 이름 서비스(DNS)와 유사합니다.
+
+### 향상된 보안 및 신뢰 {#improved-security-and-trust}
+
+이름이 지정된 계약은 잘못된 주소로의 의도치 않은 거래를 줄이는 데 도움이 됩니다. 또한 사용자가 특정 앱 또는 브랜드와 연결된 계약을 식별하는 데 도움이 됩니다. 이는 특히 `uniswap.eth`와 같이 잘 알려진 상위 도메인에 이름이 연결된 경우 평판 신뢰도를 한층 더 높여줍니다.
+
+이더리움 주소는 42자 길이이므로 사용자가 몇 글자만 수정된 주소의 작은 변화를 식별하기가 매우 어렵습니다. 예를 들어, `0x58068646C148E313CB414E85d2Fe89dDc3426870`과 같은 주소는 일반적으로 지갑과 같은 사용자용 애플리케이션에서 `0x580...870`으로 잘립니다. 사용자는 몇 글자가 변경된 악의적인 주소를 알아차리기 어렵습니다.
+
+이러한 유형의 기술은 주소 스푸핑 및 포이즈닝 공격에 사용되며, 사용자는 올바른 주소와 상호작용하거나 자금을 보내고 있다고 믿게 되지만 실제로는 해당 주소가 올바른 주소와 유사할 뿐 동일하지는 않습니다.
+
+지갑과 계약에 대한 ENS 이름은 이러한 유형의 공격으로부터 보호합니다. DNS 스푸핑 공격과 마찬가지로 ENS 스푸핑 공격도 발생할 수 있지만, 사용자는 16진수 주소의 작은 수정보다 ENS 이름의 오타를 더 쉽게 알아차릴 수 있습니다.
+
+### 지갑 및 탐색기를 위한 더 나은 UX {#better-ux}
+
+스마트 계약이 ENS 이름으로 구성된 경우 지갑 및 블록체인 탐색기와 같은 앱에서 16진수 주소 대신 스마트 계약에 대한 ENS 이름을 표시할 수 있습니다. 이는 사용자에게 상당한 사용자 경험(UX) 향상을 제공합니다.
+
+예를 들어, Uniswap과 같은 앱과 상호작용할 때 사용자는 일반적으로 상호작용하는 앱이 `uniswap.org` 웹사이트에서 호스팅된다는 것을 알 수 있지만, Uniswap이 스마트 계약에 ENS 이름을 지정하지 않은 경우 16진수 계약 주소가 표시됩니다. 계약에 이름이 지정된 경우 대신 훨씬 더 유용한 `v4.contracts.uniswap.eth`를 볼 수 있습니다.
+
+## 배포 시점의 이름 지정 vs. 배포 후 이름 지정 {#when-to-name}
+
+스마트 계약에 이름을 지정할 수 있는 시점은 두 가지입니다.
+
+- **배포 시점**: 계약이 배포될 때 ENS 이름을 할당합니다.
+- **배포 후**: 기존 계약 주소를 새로운 ENS 이름에 매핑합니다.
+
+두 가지 접근 방식 모두 ENS 레코드를 생성하고 설정할 수 있도록 ENS 도메인에 대한 소유자 또는 관리자 액세스 권한이 있어야 합니다.
+
+## 계약에 대한 ENS 이름 지정 작동 방식 {#how-ens-naming-works}
+
+ENS 이름은 온체인에 저장되며 ENS 확인자를 통해 이더리움 주소로 확인됩니다. 스마트 계약에 이름을 지정하려면:
+
+1. 상위 ENS 도메인(예: `myapp.eth`)을 등록하거나 제어합니다.
+2. 하위 도메인(예: `v1.myapp.eth`)을 생성합니다.
+3. 하위 도메인의 `address` 레코드를 계약 주소로 설정합니다.
+4. 계약의 역방향 레코드를 ENS로 설정하여 주소를 통해 이름을 찾을 수 있도록 합니다.
+
+ENS 이름은 계층적이며 무제한의 하위 이름을 지원합니다. 이러한 레코드를 설정하려면 일반적으로 ENS 레지스트리 및 공용 확인자 계약과 상호작용해야 합니다.
+
+## 계약 이름 지정을 위한 도구 {#tools}
+
+스마트 계약에 이름을 지정하는 데는 두 가지 접근 방식이 있습니다. 몇 가지 수동 단계를 거쳐 [ENS 앱](https://app.ens.domains)을 사용하거나 [Enscribe](https://www.enscribe.xyz)를 사용하는 방법이 있습니다. 이에 대한 내용은 아래에 설명되어 있습니다.
+
+### 수동 ENS 설정 {#manual-ens-setup}
+
+[ENS 앱](https://app.ens.domains/)을 사용하여 개발자는 수동으로 하위 이름을 생성하고 정방향 주소 레코드를 설정할 수 있습니다. 그러나 ENS 앱을 통해 이름에 대한 역방향 레코드를 설정하여 스마트 계약의 기본 이름을 설정할 수는 없습니다. [ENS 문서](https://docs.ens.domains/web/naming-contracts/)에 설명된 수동 단계를 수행해야 합니다.
+
+### Enscribe {#enscribe}
+
+[Enscribe](https://www.enscribe.xyz)는 ENS를 사용하여 스마트 계약 이름 지정을 간소화하고 스마트 계약에 대한 사용자 신뢰를 향상시킵니다. 다음과 같은 기능을 제공합니다.
+
+- **원자적 배포 및 이름 지정**: 새 계약을 배포할 때 ENS 이름을 할당합니다.
+- **배포 후 이름 지정**: 이미 배포된 계약에 이름을 연결합니다.
+- **멀티체인 지원**: ENS가 지원되는 이더리움 및 L2 네트워크에서 작동합니다.
+- **계약 검증 데이터**: 여러 소스에서 가져온 계약 검증 데이터를 포함하여 사용자의 신뢰를 높입니다.
+
+Enscribe는 사용자가 제공한 ENS 이름 또는 사용자가 ENS 이름이 없는 경우 자체 도메인을 지원합니다.
+
+[Enscribe 앱](https://app.enscribe.xyz)에 접속하여 스마트 계약의 이름을 지정하고 볼 수 있습니다.
+
+## 모범 사례 {#best-practices}
+
+- **`v1.myapp.eth`와 같이 명확하고 버전이 지정된 이름 사용**: 계약 업그레이드를 투명하게 만듭니다.
+- **역방향 레코드 설정**: 계약을 ENS 이름에 연결하여 지갑 및 블록체인 탐색기와 같은 앱에서 가시성을 확보합니다.
+- **만료일 면밀히 모니터링**: 의도치 않은 소유권 변경을 방지하려면 만료일을 면밀히 모니터링하세요.
+- **계약 소스 확인**: 사용자가 이름이 지정된 계약이 예상대로 작동하는지 신뢰할 수 있도록 계약 소스를 확인하세요.
+
+## 위험 {#risks}
+
+스마트 계약의 이름을 지정하면 이더리움 사용자에게 상당한 이점을 제공하지만, ENS 도메인 소유자는 관리에 주의를 기울여야 합니다. 주요 위험은 다음과 같습니다.
+
+- **만료**: DNS 이름과 마찬가지로 ENS 이름 등록은 유한한 기간 동안만 유효합니다. 따라서 소유자는 도메인 만료일을 모니터링하고 만료일보다 훨씬 전에 갱신하는 것이 중요합니다. ENS 앱과 Enscribe 모두 만료가 다가올 때 도메인 소유자에게 시각적 표시기를 제공합니다.
+- **소유권 변경**: ENS 레코드는 이더리움에서 NFT로 표시되며, 특정 `.eth` 도메인의 소유자는 관련 NFT를 소유하게 됩니다. 따라서 다른 계정이 이 NFT의 소유권을 갖게 되면 새 소유자는 자신의 재량에 따라 모든 ENS 레코드를 수정할 수 있습니다.
+
+이러한 위험을 완화하려면 `.eth` 2단계 도메인(2LD)의 소유자 계정을 다중 서명 지갑을 통해 보호하고 하위 도메인을 생성하여 계약 이름 지정을 관리해야 합니다. 그렇게 하면 하위 도메인 수준에서 우발적이거나 악의적인 소유권 변경이 발생하더라도 2LD 소유자가 이를 무효화할 수 있습니다.
+
+## 계약 이름 지정의 미래 {#future}
+
+계약 이름 지정은 웹에서 도메인 이름이 IP 주소를 대체한 것과 유사하게 디앱 개발의 모범 사례가 되고 있습니다. 지갑, 탐색기, 대시보드와 같은 더 많은 인프라가 계약에 대한 ENS 확인 기능을 통합함에 따라, 이름이 지정된 계약은 생태계 전반의 안전성을 개선하고 오류를 줄일 것입니다.
+
+스마트 계약을 더 쉽게 인식하고 추론할 수 있도록 함으로써, 이름 지정은 이더리움의 사용자와 앱 간의 간극을 메워 사용자의 안전과 UX를 모두 향상시키는 데 도움이 됩니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [ENS로 스마트 계약 이름 지정하기](https://docs.ens.domains/web/naming-contracts/)
+- [Enscribe로 스마트 계약 이름 지정하기](https://www.enscribe.xyz/docs).
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/security/index.md b/public/content/translations/ko/developers/docs/smart-contracts/security/index.md
new file mode 100644
index 00000000000..9c4bdbeec85
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/security/index.md
@@ -0,0 +1,573 @@
+---
+title: "스마트 콘트랙트 감사"
+description: "안전한 이더리움 스마트 계약을 구축하기 위한 가이드라인 개요"
+lang: ko
+---
+
+스마트 계약은 블록체인에 배포된 코드를 기반으로 변경 불가능한 로직을 실행하면서, 매우 유연하고 막대한 가치와 데이터를 제어할 수 있습니다. 이로 인해 기존 시스템보다 많은 이점을 제공하는 무신뢰 및 탈중앙화 애플리케이션의 활발한 생태계가 조성되었습니다. 또한 스마트 계약의 취약점을 악용하여 이익을 얻으려는 공격자에게는 기회가 되기도 합니다.
+
+이더리움과 같은 퍼블릭 블록체인은 스마트 계약 보안 문제를 더욱 복잡하게 만듭니다. 배포된 계약 코드는 _보통_ 보안 결함을 패치하기 위해 변경될 수 없으며, 스마트 계약에서 도난당한 자산은 불변성 때문에 추적이 매우 어렵고 대부분 복구할 수 없습니다.
+
+수치는 다양하지만, 스마트 계약의 보안 결함으로 인해 도난당하거나 손실된 총 가치는 10억 달러를 훌쩍 넘는 것으로 추정됩니다. 여기에는 [DAO 해킹](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/)(360만 ETH 도난, 현재 시가로 10억 달러 이상), [Parity 다중 서명 지갑 해킹](https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach)(해커에게 3,000만 달러 손실), [Parity 지갑 동결 문제](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether)(3억 달러 이상의 ETH가 영구적으로 동결) 등 세간의 이목을 끈 사건들이 포함됩니다.
+
+앞서 언급한 문제들로 인해 개발자들은 안전하고, 견고하며, 복원력 있는 스마트 계약을 구축하는 데 노력을 기울여야 합니다. 스마트 계약 보안은 중요한 문제이며, 모든 개발자가 잘 배워두면 좋은 것입니다. 이 가이드에서는 이더리움 개발자를 위한 보안 고려 사항을 다루고 스마트 계약 보안을 개선하기 위한 참고 자료를 알아봅니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+보안 문제를 다루기 전에 [스마트 계약 개발의 기초](/developers/docs/smart-contracts/)에 익숙해지도록 하세요.
+
+## 안전한 이더리움 스마트 계약을 구축하기 위한 가이드라인 {#smart-contract-security-guidelines}
+
+### 1. 적절한 접근 제어 설계 {#design-proper-access-controls}
+
+스마트 계약에서 `public` 또는 `external`로 표시된 함수는 모든 외부 소유 계정(EOA) 또는 계약 계정에서 호출할 수 있습니다. 다른 사람이 사용자의 계약과 상호 작용하기를 원한다면 함수에 공용 가시성을 지정해야 합니다. 그러나 `private`로 표시된 함수는 스마트 계약 내의 함수에서만 호출할 수 있으며 외부 계정에서는 호출할 수 없습니다. 모든 네트워크 참여자에게 계약 함수에 대한 접근 권한을 부여하면 문제가 발생할 수 있으며, 특히 누구나 민감한 작업(예: 새로운 토큰 발행)을 수행할 수 있다는 것을 의미하는 경우 더욱 그렇습니다.
+
+스마트 계약 함수의 무단 사용을 방지하려면 안전한 접근 제어를 구현해야 합니다. 접근 제어 메커니즘은 스마트 계약에서 특정 함수를 사용할 수 있는 권한을 계약 관리를 책임지는 계정과 같이 승인된 주체로 제한합니다. 소유 가능 패턴과 역할 기반 제어는 스마트 계약에서 접근 제어를 구현하는 데 유용한 두 가지 패턴입니다.
+
+#### 소유 가능 패턴 {#ownable-pattern}
+
+소유 가능 패턴에서는 계약 생성 과정에서 주소가 계약의 '소유자'로 설정됩니다. 보호된 함수에는 `OnlyOwner` 수정자가 할당되어 계약이 함수를 실행하기 전에 호출 주소의 신원을 인증하도록 합니다. 계약 소유자가 아닌 다른 주소에서 보호된 함수를 호출하면 항상 되돌려지므로 원치 않는 접근을 방지할 수 있습니다.
+
+#### 역할 기반 접근 제어 {#role-based-access-control}
+
+스마트 계약에서 단일 주소를 `Owner`로 등록하면 중앙화의 위험이 발생하고 단일 실패 지점이 됩니다. 소유자의 계정 키가 손상되면 공격자가 소유 계약을 공격할 수 있습니다. 이것이 여러 관리 계정이 있는 역할 기반 접근 제어 패턴을 사용하는 것이 더 나은 선택일 수 있는 이유입니다.
+
+역할 기반 접근 제어에서 민감한 기능에 대한 접근은 신뢰할 수 있는 참여자 집합 간에 분산됩니다. 예를 들어, 한 계정은 토큰 발행을 담당하고 다른 계정은 계약을 업그레이드하거나 일시 중지하는 작업을 수행할 수 있습니다. 이러한 방식으로 접근 제어를 분산하면 단일 실패 지점을 제거하고 사용자에 대한 신뢰 가정을 줄일 수 있습니다.
+
+##### 다중 서명 지갑 사용
+
+안전한 접근 제어를 구현하는 또 다른 방법은 [다중 서명 계정](/developers/docs/smart-contracts/#multisig)을 사용하여 계약을 관리하는 것입니다. 일반 EOA와 달리 다중 서명 계정은 여러 엔티티가 소유하며 트랜잭션을 실행하려면 최소 계정 수(예: 5개 중 3개)의 서명이 필요합니다.
+
+접근 제어에 다중 서명을 사용하면 대상 계약에 대한 조치에 여러 당사자의 동의가 필요하므로 보안 계층이 추가됩니다. 이는 공격자나 불량 내부자가 악의적인 목적으로 민감한 계약 기능을 조작하기 어렵게 만들기 때문에 소유 가능 패턴을 사용하는 것이 필요한 경우 특히 유용합니다.
+
+### 2. require(), assert() 및 revert() 문을 사용하여 계약 작업을 보호하세요 {#use-require-assert-revert}
+
+언급했듯이 스마트 계약이 블록체인에 배포되면 누구나 스마트 계약의 공용 함수를 호출할 수 있습니다. 외부 계정이 계약과 어떻게 상호 작용할지 미리 알 수 없으므로 배포하기 전에 문제가 있는 작업에 대한 내부 보호 장치를 구현하는 것이 이상적입니다. 실행이 특정 요구 사항을 충족하지 못하는 경우 예외를 트리거하고 상태 변경을 되돌리기 위해 `require()`, `assert()` 및 `revert()` 문을 사용하여 스마트 계약에서 올바른 동작을 적용할 수 있습니다.
+
+**`require()`**: `require`는 함수 시작 부분에 정의되며 호출된 함수가 실행되기 전에 미리 정의된 조건이 충족되도록 합니다. `require` 문은 함수를 진행하기 전에 사용자 입력을 검증하거나, 상태 변수를 확인하거나, 호출 계정의 신원을 인증하는 데 사용할 수 있습니다.
+
+**`assert()`**: `assert()`는 내부 오류를 감지하고 코드의 '불변' 위반을 확인하는 데 사용됩니다. 불변은 모든 함수 실행에 대해 사실이어야 하는 계약의 상태에 대한 논리적 주장입니다. 불변의 예는 토큰 계약의 최대 총 공급량 또는 잔액입니다. `assert()`를 사용하면 계약이 취약한 상태에 도달하지 않도록 하고, 만약 그렇게 되면 상태 변수에 대한 모든 변경 사항이 롤백됩니다.
+
+**`revert()`**: `revert()`는 필요한 조건이 충족되지 않으면 예외를 트리거하는 if-else 문에서 사용할 수 있습니다. 아래 샘플 계약은 `revert()`를 사용하여 함수 실행을 보호합니다.
+
+```
+pragma solidity ^0.8.4;
+
+contract VendingMachine {
+ address owner;
+ error Unauthorized();
+ function buy(uint amount) public payable {
+ if (amount > msg.value / 2 ether)
+ revert("제공된 이더가 충분하지 않습니다.");
+ // 구매를 수행합니다.
+ }
+ function withdraw() public {
+ if (msg.sender != owner)
+ revert Unauthorized();
+
+ payable(msg.sender).transfer(address(this).balance);
+ }
+}
+```
+
+### 3. 스마트 계약 테스트 및 코드 정확성 확인 {#test-smart-contracts-and-verify-code-correctness}
+
+[이더리움 가상 머신](/developers/docs/evm/)에서 실행되는 코드의 불변성은 스마트 계약이 개발 단계에서 더 높은 수준의 품질 평가를 요구함을 의미합니다. 계약을 광범위하게 테스트하고 예기치 않은 결과가 있는지 관찰하면 보안이 크게 향상되고 장기적으로 사용자를 보호할 수 있습니다.
+
+일반적인 방법은 계약이 사용자로부터 받을 것으로 예상되는 모의 데이터를 사용하여 작은 단위 테스트를 작성하는 것입니다. [단위 테스트](/developers/docs/smart-contracts/testing/#unit-testing)는 특정 기능의 기능을 테스트하고 스마트 계약이 예상대로 작동하는지 확인하는 데 좋습니다.
+
+불행히도 단위 테스트는 단독으로 사용될 때 스마트 계약 보안을 향상시키는 데 최소한의 효과만 있습니다. 단위 테스트는 모의 데이터에 대해 함수가 제대로 실행됨을 증명할 수 있지만, 단위 테스트는 작성된 테스트만큼만 효과적입니다. 이로 인해 스마트 계약의 안전을 위협할 수 있는 누락된 엣지 케이스와 취약점을 감지하기가 어렵습니다.
+
+더 나은 접근 방식은 [정적 및 동적 분석](/developers/docs/smart-contracts/testing/#static-dynamic-analysis)을 사용하여 수행되는 속성 기반 테스트와 단위 테스트를 결합하는 것입니다. 정적 분석은 [제어 흐름 그래프](https://en.wikipedia.org/wiki/Control-flow_graph) 및 [추상 구문 트리](https://deepsource.io/glossary/ast/)와 같은 저수준 표현에 의존하여 도달 가능한 프로그램 상태 및 실행 경로를 분석합니다. 한편, [스마트 계약 퍼징](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry)과 같은 동적 분석 기술은 임의의 입력 값으로 계약 코드를 실행하여 보안 속성을 위반하는 작업을 감지합니다.
+
+[공식 검증](/developers/docs/smart-contracts/formal-verification)은 스마트 계약의 보안 속성을 검증하는 또 다른 기술입니다. 일반 테스트와 달리 공식 검증은 스마트 계약에 오류가 없음을 결정적으로 증명할 수 있습니다. 이는 원하는 보안 속성을 캡처하는 공식 사양을 만들고 계약의 공식 모델이 이 사양을 준수함을 증명함으로써 달성됩니다.
+
+### 4. 코드에 대한 독립적인 검토를 요청하세요 {#get-independent-code-reviews}
+
+계약을 테스트한 후 다른 사람들에게 소스 코드에 보안 문제가 있는지 확인하도록 요청하는 것이 좋습니다. 테스트를 통해 스마트 계약의 모든 결함을 발견할 수는 없지만 독립적인 검토를 받으면 취약점을 발견할 가능성이 높아집니다.
+
+#### 감사 {#audits}
+
+스마트 계약 감사를 의뢰하는 것은 독립적인 코드 검토를 수행하는 한 가지 방법입니다. 감사자는 스마트 계약이 안전하고 품질 결함 및 설계 오류가 없는지 확인하는 데 중요한 역할을 합니다.
+
+그렇다고 감사를 만병통치약으로 취급해서는 안 됩니다. 스마트 계약 감사는 모든 버그를 잡지 못하며 대부분 추가 검토를 제공하도록 설계되어 개발자가 초기 개발 및 테스트 중에 놓친 문제를 감지하는 데 도움이 될 수 있습니다. 또한 스마트 계약 감사의 이점을 극대화하려면 코드를 적절하게 문서화하고 인라인 주석을 추가하는 등 감사자와 작업하기 위한 모범 사례를 따라야 합니다.
+
+- [스마트 계약 감사 팁 및 요령](https://twitter.com/tinchoabbate/status/1400170232904400897) - _@tinchoabbate_
+- [감사를 최대한 활용하기](https://inference.ag/blog/2023-08-14-tips/) - _Inference_
+
+#### 버그 포상금 {#bug-bounties}
+
+버그 포상금 프로그램을 설정하는 것은 외부 코드 검토를 구현하는 또 다른 접근 방식입니다. 버그 포상금은 애플리케이션에서 취약점을 발견한 개인(보통 화이트햇 해커)에게 주어지는 금전적 보상입니다.
+
+적절하게 사용하면 버그 포상금은 해커 커뮤니티 구성원에게 코드에 중요한 결함이 있는지 검사하도록 인센티브를 제공합니다. 실제 예는 이더리움에서 실행되는 [레이어 2](/layer-2/) 프로토콜인 [Optimism](https://www.optimism.io/)에서 공격자가 무제한의 이더를 생성할 수 있었던 '무한 돈 버그'입니다. 다행히 화이트햇 해커가 [결함을 발견하고](https://www.saurik.com/optimism.html) 팀에 통보하여 [그 과정에서 큰 포상금을 받았습니다](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/).
+
+유용한 전략은 이해 관계가 있는 자금의 양에 비례하여 버그 포상금 프로그램의 지불금을 설정하는 것입니다. “[스케일링 버그 포상금](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)”으로 설명되는 이 접근 방식은 개인이 취약점을 악용하는 대신 책임감 있게 공개하도록 재정적 인센티브를 제공합니다.
+
+### 5. 스마트 계약 개발 중 모범 사례 따르기 {#follow-smart-contract-development-best-practices}
+
+감사 및 버그 포상금의 존재가 고품질 코드를 작성해야 할 책임을 면제해주지는 않습니다. 우수한 스마트 계약 보안은 적절한 설계 및 개발 프로세스를 따르는 것에서 시작됩니다.
+
+- git과 같은 버전 제어 시스템에 모든 코드를 저장
+
+- 풀 리퀘스트를 통해 모든 코드 수정하기
+
+- 풀 리퀘스트에 최소 한 명의 독립적인 검토자가 있는지 확인하세요. 프로젝트에서 단독으로 작업하는 경우 다른 개발자를 찾아 코드 검토를 교환하는 것을 고려하세요.
+
+- 스마트 계약 테스트, 컴파일, 배포를 위해 [개발 환경](/developers/docs/frameworks/)을 사용하세요.
+
+- 코드를 [Cyfrin Aderyn](https://github.com/Cyfrin/aderyn), Mythril 및 Slither와 같은 기본 코드 분석 도구로 실행하세요. 이상적으로는 각 풀 리퀘스트가 병합되기 전에 이 작업을 수행하고 출력의 차이점을 비교해야 합니다.
+
+- 코드가 오류 없이 컴파일되고 솔리디티 컴파일러가 경고를 내보내지 않도록 확인하세요.
+
+- 코드를 ([NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html)을 사용하여) 적절히 문서화하고 계약 아키텍처에 대한 세부 정보를 이해하기 쉬운 언어로 설명하세요. 이렇게 하면 다른 사람들이 코드를 감사하고 검토하기가 더 쉬워집니다.
+
+### 6. 견고한 재해 복구 계획 구현 {#implement-disaster-recovery-plans}
+
+안전한 접근 제어 설계, 기능 수정자 구현 및 기타 제안은 스마트 계약 보안을 향상시킬 수 있지만 악의적인 공격의 가능성을 배제할 수는 없습니다. 안전한 스마트 계약을 구축하려면 '실패에 대비'하고 공격에 효과적으로 대응하기 위한 대체 계획을 마련해야 합니다. 적절한 재해 복구 계획에는 다음 구성 요소의 일부 또는 전부가 포함됩니다.
+
+#### 계약 업그레이드 {#contract-upgrades}
+
+이더리움 스마트 계약은 기본적으로 불변이지만 업그레이드 패턴을 사용하여 어느 정도의 가변성을 달성할 수 있습니다. 계약 업그레이드는 중요한 결함으로 인해 기존 계약을 사용할 수 없게 되고 새로운 로직을 배포하는 것이 가장 실현 가능한 옵션인 경우에 필요합니다.
+
+계약 업그레이드 메커니즘은 다르게 작동하지만 '프록시 패턴'은 스마트 계약 업그레이드를 위한 더 인기 있는 접근 방식 중 하나입니다. [프록시 패턴](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern)은 애플리케이션의 상태와 로직을 _두_ 계약으로 나눕니다. 첫 번째 계약('프록시 계약')은 상태 변수(예: 사용자 잔액)를 저장하고, 두 번째 계약('로직 계약')은 계약 기능을 실행하기 위한 코드를 보유합니다.
+
+계정은 프록시 계약과 상호 작용하며, 프록시 계약은 [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries) 저수준 호출을 사용하여 모든 함수 호출을 로직 계약으로 보냅니다. 일반 메시지 호출과 달리 `delegatecall()`은 로직 계약의 주소에서 실행되는 코드가 호출 계약의 컨텍스트에서 실행되도록 보장합니다. 이는 로직 계약이 항상 자신의 저장 공간 대신 프록시의 저장 공간에 쓰고 `msg.sender` 및 `msg.value`의 원래 값이 보존됨을 의미합니다.
+
+로직 계약에 대한 호출을 위임하려면 해당 주소를 프록시 계약의 저장 공간에 저장해야 합니다. 따라서 계약의 로직을 업그레이드하는 것은 다른 로직 계약을 배포하고 새 주소를 프록시 계약에 저장하는 문제일 뿐입니다. 프록시 계약에 대한 후속 호출은 자동으로 새 로직 계약으로 라우팅되므로 실제로 코드를 수정하지 않고도 계약을 '업그레이드'하게 됩니다.
+
+[계약 업그레이드에 대해 더 알아보기](/developers/docs/smart-contracts/upgrading/).
+
+#### 긴급 중지 {#emergency-stops}
+
+언급했듯이 광범위한 감사 및 테스트로 스마트 계약의 모든 버그를 발견할 수는 없습니다. 배포 후 코드에 취약점이 나타나면 계약 주소에서 실행되는 코드를 변경할 수 없으므로 패치하는 것이 불가능합니다. 또한 업그레이드 메커니즘(예: 프록시 패턴)은 구현하는 데 시간이 걸릴 수 있으며(종종 다른 당사자의 승인이 필요함), 이는 공격자에게 더 많은 피해를 입힐 시간을 줄 뿐입니다.
+
+핵심 옵션은 계약의 취약한 기능에 대한 호출을 차단하는 '긴급 중지' 기능을 구현하는 것입니다. 긴급 중지는 일반적으로 다음 구성 요소로 구성됩니다.
+
+1. 스마트 계약이 중지된 상태인지 여부를 나타내는 전역 부울 변수입니다. 이 변수는 계약 설정 시 `false`로 설정되지만 계약이 중지되면 `true`로 되돌아갑니다.
+
+2. 실행 시 부울 변수를 참조하는 함수. 이러한 함수는 스마트 계약이 중지되지 않았을 때 접근할 수 있으며, 긴급 중지 기능이 트리거되면 접근할 수 없게 됩니다.
+
+3. 부울 변수를 `true`로 설정하는 긴급 중지 기능에 접근할 수 있는 엔티티입니다. 악의적인 행위를 방지하기 위해 이 함수에 대한 호출은 신뢰할 수 있는 주소(예: 계약 소유자)로 제한될 수 있습니다.
+
+계약이 긴급 중지를 활성화하면 특정 함수를 호출할 수 없게 됩니다. 이는 전역 변수를 참조하는 수정자로 선택 함수를 래핑하여 달성됩니다. 아래는 계약에서 이 패턴의 구현을 설명하는 [예제](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol)입니다.
+
+```solidity
+// 이 코드는 전문적인 감사를 받지 않았으며 안전성이나 정확성에 대해 어떠한 약속도 하지 않습니다. 자신의 책임 하에 사용하세요.
+
+contract EmergencyStop {
+
+ bool isStopped = false;
+
+ modifier stoppedInEmergency {
+ require(!isStopped);
+ _;
+ }
+
+ modifier onlyWhenStopped {
+ require(isStopped);
+ _;
+ }
+
+ modifier onlyAuthorized {
+ // 여기에서 msg.sender의 권한을 확인하세요
+ _;
+ }
+
+ function stopContract() public onlyAuthorized {
+ isStopped = true;
+ }
+
+ function resumeContract() public onlyAuthorized {
+ isStopped = false;
+ }
+
+ function deposit() public payable stoppedInEmergency {
+ // 입금 로직이 여기서 발생합니다
+ }
+
+ function emergencyWithdraw() public onlyWhenStopped {
+ // 긴급 인출이 여기서 발생합니다
+ }
+}
+```
+
+이 예제는 긴급 중지의 기본 기능을 보여줍니다.
+
+- `isStopped`는 처음에 `false`로 평가되고 계약이 긴급 모드로 들어가면 `true`로 평가되는 부울입니다.
+
+- 함수 수정자 `onlyWhenStopped`와 `stoppedInEmergency`는 `isStopped` 변수를 확인합니다. `stoppedInEmergency`는 계약이 취약할 때 접근할 수 없어야 하는 함수(예: `deposit()`)를 제어하는 데 사용됩니다. 이러한 함수에 대한 호출은 단순히 되돌려집니다.
+
+`onlyWhenStopped`는 긴급 상황 시 호출 가능해야 하는 함수(예: `emergencyWithdraw()`)에 사용됩니다. 이러한 함수는 상황 해결에 도움이 될 수 있으므로 '제한된 함수' 목록에서 제외됩니다.
+
+긴급 중지 기능을 사용하면 스마트 계약의 심각한 취약점을 처리하기 위한 효과적인 임시 방편을 제공합니다. 그러나 사용자가 개발자가 이기적인 이유로 이를 활성화하지 않을 것이라고 신뢰해야 할 필요성이 증가합니다. 이를 위해 온체인 투표 메커니즘, 타임락 또는 다중 서명 지갑의 승인을 통해 긴급 중지 제어를 분산하는 것이 가능한 해결책입니다.
+
+#### 이벤트 모니터링 {#event-monitoring}
+
+[이벤트](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events)를 사용하면 스마트 계약 함수에 대한 호출을 추적하고 상태 변수의 변경 사항을 모니터링할 수 있습니다. 어떤 당사자가 안전에 중요한 조치(예: 자금 인출)를 취할 때마다 이벤트를 발생시키도록 스마트 계약을 프로그래밍하는 것이 이상적입니다.
+
+이벤트를 로깅하고 오프체인에서 모니터링하면 계약 운영에 대한 통찰력을 제공하고 악의적인 행동을 더 빨리 발견하는 데 도움이 됩니다. 이는 팀이 해킹에 더 빨리 대응하고 기능 일시 중지 또는 업그레이드 수행과 같은 사용자에게 미치는 영향을 완화하기 위한 조치를 취할 수 있음을 의미합니다.
+
+누군가 계약과 상호 작용할 때마다 자동으로 알림을 전달하는 기성 모니터링 도구를 선택할 수도 있습니다. 이러한 도구를 사용하면 트랜잭션 양, 함수 호출 빈도 또는 관련된 특정 함수와 같은 다양한 트리거를 기반으로 사용자 지정 알림을 만들 수 있습니다. 예를 들어, 단일 트랜잭션에서 인출된 금액이 특정 임계값을 초과할 때 들어오는 알림을 프로그래밍할 수 있습니다.
+
+### 7. 안전한 거버넌스 시스템 설계 {#design-secure-governance-systems}
+
+핵심 스마트 계약의 통제권을 커뮤니티 구성원에게 넘겨 애플리케이션을 분산화할 수 있습니다. 이 경우 스마트 계약 시스템에는 거버넌스 모듈, 즉 커뮤니티 구성원이 온체인 거버넌스 시스템을 통해 관리 조치를 승인할 수 있는 메커니즘이 포함됩니다. 예를 들어, 프록시 계약을 새 구현으로 업그레이드하자는 제안은 토큰 보유자들의 투표에 부쳐질 수 있습니다.
+
+분산형 거버넌스는 특히 개발자와 최종 사용자의 이익을 일치시키기 때문에 유익할 수 있습니다. 그럼에도 불구하고 스마트 계약 거버넌스 메커니즘은 잘못 구현될 경우 새로운 위험을 초래할 수 있습니다. 있을 법한 시나리오는 공격자가 [플래시 론](/defi/#flash-loans)을 이용하여 엄청난 투표권(보유 토큰 수로 측정)을 획득하고 악의적인 제안을 통과시키는 경우입니다.
+
+온체인 거버넌스와 관련된 문제를 예방하는 한 가지 방법은 [타임락을 사용하는 것](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/)입니다. 타임락은 스마트 계약이 특정 시간이 지날 때까지 특정 작업을 실행하지 못하도록 합니다. 다른 전략으로는 각 토큰이 잠겨 있던 기간에 따라 '투표 가중치'를 할당하거나, 현재 블록이 아닌 과거의 특정 기간(예: 2-3 블록 전)에 주소의 투표권을 측정하는 것이 있습니다. 두 방법 모두 온체인 투표를 흔들기 위해 투표권을 빠르게 축적할 가능성을 줄여줍니다.
+
+공유된 링크에서 [안전한 거버넌스 시스템 설계](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/), [DAO의 다양한 투표 메커니즘](https://hackernoon.com/governance-is-the-holy-grail-for-daos) 및 [DeFi를 활용한 일반적인 DAO 공격 벡터](https://dacian.me/dao-governance-defi-attacks)에 대해 더 자세히 알아보세요.
+
+### 8. 코드의 복잡성을 최소화하세요 {#reduce-code-complexity}
+
+기존 소프트웨어 개발자들은 소프트웨어 설계에 불필요한 복잡성을 도입하지 말 것을 권고하는 KISS('keep it simple, stupid') 원칙에 익숙합니다. 이는 '복잡한 시스템은 복잡한 방식으로 실패한다'는 오랜 생각에 따른 것으로, 비용이 많이 드는 오류에 더 취약합니다.
+
+스마트 계약은 잠재적으로 막대한 가치를 제어하므로 스마트 계약을 작성할 때 단순함을 유지하는 것이 특히 중요합니다. 스마트 계약을 작성할 때 단순성을 달성하기 위한 팁은 가능한 경우 [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)와 같은 기존 라이브러리를 재사용하는 것입니다. 이러한 라이브러리는 개발자들에 의해 광범위하게 감사되고 테스트되었기 때문에, 이를 사용하면 처음부터 새로운 기능을 작성함으로써 버그를 도입할 가능성을 줄일 수 있습니다.
+
+또 다른 일반적인 조언은 작은 함수를 작성하고 비즈니스 로직을 여러 계약에 분산하여 계약을 모듈식으로 유지하는 것입니다. 더 간단한 코드를 작성하면 스마트 계약의 공격 표면을 줄일 수 있을 뿐만 아니라 전체 시스템의 정확성을 추론하고 가능한 설계 오류를 조기에 감지하기가 더 쉬워집니다.
+
+### 9. 일반적인 스마트 계약 취약점 방어 {#mitigate-common-smart-contract-vulnerabilities}
+
+#### 재진입 {#reentrancy}
+
+EVM은 동시성을 허용하지 않으므로 메시지 호출에 관련된 두 계약이 동시에 실행될 수 없습니다. 외부 호출은 호출이 반환될 때까지 호출 계약의 실행과 메모리를 일시 중지하며, 그 시점에서 실행은 정상적으로 진행됩니다. 이 과정은 다른 계약으로 [제어 흐름](https://www.computerhope.com/jargon/c/contflow.htm)을 이전하는 것으로 공식적으로 설명될 수 있습니다.
+
+대부분 무해하지만 신뢰할 수 없는 계약으로 제어 흐름을 이전하면 재진입과 같은 문제가 발생할 수 있습니다. 재진입 공격은 악성 계약이 원래 함수 호출이 완료되기 전에 취약한 계약으로 다시 호출할 때 발생합니다. 이 유형의 공격은 예시를 통해 가장 잘 설명됩니다.
+
+누구나 이더를 입금하고 인출할 수 있는 간단한 스마트 계약('Victim')을 고려해 보세요.
+
+```solidity
+// 이 계약은 취약합니다. 프로덕션에서 사용하지 마세요
+
+contract Victim {
+ mapping (address => uint256) public balances;
+
+ function deposit() external payable {
+ balances[msg.sender] += msg.value;
+ }
+
+ function withdraw() external {
+ uint256 amount = balances[msg.sender];
+ (bool success, ) = msg.sender.call.value(amount)("");
+ require(success);
+ balances[msg.sender] = 0;
+ }
+}
+```
+
+이 계약은 사용자가 이전에 계약에 입금한 ETH를 인출할 수 있도록 `withdraw()` 함수를 노출합니다. 인출을 처리할 때 계약은 다음 작업을 수행합니다.
+
+1. 사용자의 ETH 잔액 확인
+2. 호출 주소로 자금 전송
+3. 사용자의 추가 인출을 방지하기 위해 잔액을 0으로 재설정
+
+`Victim` 계약의 `withdraw()` 함수는 '확인-상호작용-효과' 패턴을 따릅니다. 실행에 필요한 조건이 충족되었는지 _확인_(즉, 사용자가 양의 ETH 잔액을 가지고 있는지)하고, 트랜잭션의 _효과_(즉, 사용자 잔액 감소)를 적용하기 전에 호출자의 주소로 ETH를 전송하여 상호작용을 수행합니다.
+
+`withdraw()`가 외부 소유 계정(EOA)에서 호출되면 함수는 예상대로 실행됩니다. `msg.sender.call.value()`는 호출자에게 ETH를 보냅니다. 그러나 `msg.sender`가 스마트 계약 계정이고 `withdraw()`를 호출하면, `msg.sender.call.value()`를 사용하여 자금을 보내는 것은 해당 주소에 저장된 코드를 실행하게 합니다.
+
+이것이 계약 주소에 배포된 코드라고 상상해보세요.
+
+```solidity
+ contract Attacker {
+ function beginAttack() external payable {
+ Victim(victim_address).deposit.value(1 ether)();
+ Victim(victim_address).withdraw();
+ }
+
+ function() external payable {
+ if (gasleft() > 40000) {
+ Victim(victim_address).withdraw();
+ }
+ }
+}
+```
+
+이 계약은 세 가지를 하도록 설계되었습니다.
+
+1. 다른 계정(공격자의 EOA일 가능성 있음)으로부터 입금 받기
+2. Victim 계약에 1 ETH 입금하기
+3. 스마트 계약에 저장된 1 ETH 인출하기
+
+여기에는 아무런 문제가 없지만, `Attacker`는 들어오는 `msg.sender.call.value`에서 남은 가스가 40,000 이상이면 `Victim`에서 `withdraw()`를 다시 호출하는 또 다른 함수를 가지고 있습니다. 이는 `Attacker`가 `Victim`에 재진입하여 첫 번째 `withdraw` 호출이 완료되기 _전에_ 더 많은 자금을 인출할 수 있는 능력을 부여합니다. 주기는 다음과 같습니다.
+
+```solidity
+- 공격자의 EOA가 1 ETH로 `Attacker.beginAttack()`을 호출합니다
+- `Attacker.beginAttack()`이 `Victim`에 1 ETH를 입금합니다
+- `Attacker`가 `Victim`에서 `withdraw()`를 호출합니다
+- `Victim`이 `Attacker`의 잔액(1 ETH)을 확인합니다
+- `Victim`이 `Attacker`에게 1 ETH를 전송합니다(기본 함수를 트리거함)
+- `Attacker`가 `Victim.withdraw()`를 다시 호출합니다(`Victim`은 첫 번째 인출에서 `Attacker`의 잔액을 줄이지 않았음에 유의)
+- `Victim`이 `Attacker`의 잔액을 확인합니다(첫 번째 호출의 효과를 적용하지 않았기 때문에 여전히 1 ETH임)
+- `Victim`이 `Attacker`에게 1 ETH를 전송합니다(기본 함수를 트리거하고 `Attacker`가 `withdraw` 함수에 재진입할 수 있게 함)
+- `Attacker`가 가스를 모두 소진할 때까지 프로세스가 반복되며, 그 시점에서 `msg.sender.call.value`는 추가 인출을 트리거하지 않고 반환됩니다
+- `Victim`은 마침내 첫 번째 트랜잭션(및 후속 트랜잭션)의 결과를 상태에 적용하므로 `Attacker`의 잔액은 0으로 설정됩니다
+```
+
+요약하자면, 함수 실행이 완료될 때까지 호출자의 잔액이 0으로 설정되지 않기 때문에 후속 호출이 성공하여 호출자가 잔액을 여러 번 인출할 수 있게 됩니다. [2016년 DAO 해킹](https://www.coindesk.com/learn/understanding-the-dao-attack)에서 일어난 것처럼, 이러한 종류의 공격은 스마트 계약의 자금을 고갈시키는 데 사용될 수 있습니다. [재진입 공격의 공개 목록](https://github.com/pcaversaccio/reentrancy-attacks)에서 알 수 있듯이, 재진입 공격은 오늘날에도 여전히 스마트 계약의 중요한 문제입니다.
+
+##### 재진입 공격을 예방하는 방법
+
+재진입을 처리하는 한 가지 방법은 [확인-효과-상호작용 패턴](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern)을 따르는 것입니다. 이 패턴은 실행을 진행하기 전에 필요한 확인을 수행하는 코드가 먼저 오고, 그 다음 계약 상태를 조작하는 코드가 오고, 마지막으로 다른 계약이나 EOA와 상호작용하는 코드가 오도록 함수 실행 순서를 정합니다.
+
+확인-효과-상호작용 패턴은 아래에 표시된 `Victim` 계약의 수정된 버전에서 사용됩니다.
+
+```solidity
+contract NoLongerAVictim {
+ function withdraw() external {
+ uint256 amount = balances[msg.sender];
+ balances[msg.sender] = 0;
+ (bool success, ) = msg.sender.call.value(amount)("");
+ require(success);
+ }
+}
+```
+
+이 계약은 사용자의 잔액을 확인하고, `withdraw()` 함수의 _효과_(사용자 잔액을 0으로 재설정)를 적용한 후 _상호작용_(사용자 주소로 ETH 전송)을 수행합니다. 이를 통해 계약은 외부 호출 전에 저장 공간을 업그레이드하여 첫 번째 공격을 가능하게 했던 재진입 조건을 제거합니다. `Attacker` 계약은 여전히 `NoLongerAVictim`을 다시 호출할 수 있지만, `balances[msg.sender]`가 0으로 설정되었기 때문에 추가 인출은 오류를 발생시킵니다.
+
+또 다른 옵션은 함수 호출이 완료될 때까지 계약 상태의 일부를 잠그는 상호 배제 잠금(일반적으로 '뮤텍스'라고 함)을 사용하는 것입니다. 이는 함수가 실행되기 전에 `true`로 설정되고 호출이 완료된 후 `false`로 되돌아가는 부울 변수를 사용하여 구현됩니다. 아래 예에서 볼 수 있듯이, 뮤텍스를 사용하면 원래 호출이 아직 처리 중인 동안 재귀 호출로부터 함수를 보호하여 재진입을 효과적으로 막을 수 있습니다.
+
+```solidity
+pragma solidity ^0.7.0;
+
+contract MutexPattern {
+ bool locked = false;
+ mapping(address => uint256) public balances;
+
+ modifier noReentrancy() {
+ require(!locked, "재진입이 차단되었습니다.");
+ locked = true;
+ _;
+ locked = false;
+ }
+ // 이 함수는 뮤텍스로 보호되므로 'msg.sender.call' 내에서 재진입 호출을 통해 'withdraw'를 다시 호출할 수 없습니다.
+ // 'return'문은 'true'로 평가되지만 여전히 수정자에서 'locked = false'문을 평가합니다
+ function withdraw(uint _amount) public payable noReentrancy returns(bool) {
+ require(balances[msg.sender] >= _amount, "인출할 잔액이 없습니다.");
+
+ balances[msg.sender] -= _amount;
+ (bool success, ) = msg.sender.call{value: _amount}("");
+ require(success);
+
+ return true;
+ }
+}
+```
+
+계정으로 자금을 보내는 '푸시 지불' 시스템 대신, 사용자가 스마트 계약에서 자금을 인출해야 하는 [풀 지불](https://docs.openzeppelin.com/contracts/5.x/api/security#PullPayment) 시스템을 사용할 수도 있습니다. 이는 알 수 없는 주소에서 의도치 않게 코드를 트리거할 가능성을 제거하고 특정 서비스 거부 공격을 예방할 수도 있습니다.
+
+#### 정수 언더플로우 및 오버플로우 {#integer-underflows-and-overflows}
+
+정수 오버플로우는 산술 연산의 결과가 허용 가능한 값 범위를 벗어나 가장 낮은 표현 가능한 값으로 '롤오버'될 때 발생합니다. 예를 들어, `uint8`은 2^8-1=255까지의 값만 저장할 수 있습니다. 값이 `255`보다 큰 산술 연산은 오버플로우되어 `uint`를 `0`으로 재설정합니다. 이는 자동차의 주행 거리계가 최대 주행 거리(999999)에 도달하면 0으로 재설정되는 것과 유사합니다.
+
+정수 언더플로우도 비슷한 이유로 발생합니다. 산술 연산의 결과가 허용 가능한 범위 아래로 떨어지는 것입니다. 예를 들어 `uint8`에서 `0`을 감소시키려고 하면 결과는 단순히 표현 가능한 최대값(`255`)으로 롤오버됩니다.
+
+정수 오버플로우와 언더플로우 모두 계약의 상태 변수에 예기치 않은 변경을 초래하고 계획되지 않은 실행을 초래할 수 있습니다. 아래는 공격자가 스마트 계약에서 산술 오버플로우를 악용하여 잘못된 작업을 수행하는 방법을 보여주는 예입니다.
+
+```
+pragma solidity ^0.7.6;
+
+// 이 계약은 시간 금고 역할을 하도록 설계되었습니다.
+// 사용자는 이 계약에 입금할 수 있지만 최소 일주일 동안은 인출할 수 없습니다.
+// 사용자는 1주 대기 기간을 초과하여 대기 시간을 연장할 수도 있습니다.
+
+/*
+1. TimeLock 배포
+2. TimeLock의 주소로 Attack 배포
+3. 1이더를 보내는 Attack.attack 호출. 즉시 이더를 인출할 수 있습니다.
+
+무슨 일이 일어났나요?
+Attack은 TimeLock.lockTime을 오버플로우시켜 1주 대기 기간 전에 인출할 수 있었습니다.
+*/
+
+contract TimeLock {
+ mapping(address => uint) public balances;
+ mapping(address => uint) public lockTime;
+
+ function deposit() external payable {
+ balances[msg.sender] += msg.value;
+ lockTime[msg.sender] = block.timestamp + 1 weeks;
+ }
+
+ function increaseLockTime(uint _secondsToIncrease) public {
+ lockTime[msg.sender] += _secondsToIncrease;
+ }
+
+ function withdraw() public {
+ require(balances[msg.sender] > 0, "자금 부족");
+ require(block.timestamp > lockTime[msg.sender], "잠금 시간이 만료되지 않았습니다");
+
+ uint amount = balances[msg.sender];
+ balances[msg.sender] = 0;
+
+ (bool sent, ) = msg.sender.call{value: amount}("");
+ require(sent, "이더 전송 실패");
+ }
+}
+
+contract Attack {
+ TimeLock timeLock;
+
+ constructor(TimeLock _timeLock) {
+ timeLock = TimeLock(_timeLock);
+ }
+
+ fallback() external payable {}
+
+ function attack() public payable {
+ timeLock.deposit{value: msg.value}();
+ /*
+ t가 현재 잠금 시간이라면 x + t = 2**256 = 0이 되는 x를 찾아야 합니다
+ 따라서 x = -t
+ 2**256 = type(uint).max + 1
+ 따라서 x = type(uint).max + 1 - t
+ */
+ timeLock.increaseLockTime(
+ type(uint).max + 1 - timeLock.lockTime(address(this))
+ );
+ timeLock.withdraw();
+ }
+}
+```
+
+##### 정수 언더플로우 및 오버플로우 예방 방법
+
+버전 0.8.0부터 솔리디티 컴파일러는 정수 언더플로우 및 오버플로우를 초래하는 코드를 거부합니다. 그러나 더 낮은 컴파일러 버전으로 컴파일된 계약은 산술 연산과 관련된 함수에 대한 확인을 수행하거나 언더플로우/오버플로우를 확인하는 라이브러리(예: [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math))를 사용해야 합니다.
+
+#### 오라클 조작 {#oracle-manipulation}
+
+[오라클](/developers/docs/oracles/)은 오프체인 정보를 소싱하여 스마트 계약이 사용할 수 있도록 온체인으로 보냅니다. 오라클을 사용하면 자본 시장과 같은 오프체인 시스템과 상호 운용되는 스마트 계약을 설계하여 애플리케이션을 크게 확장할 수 있습니다.
+
+그러나 오라클이 손상되어 잘못된 정보를 온체인으로 보내면 스마트 계약은 잘못된 입력을 기반으로 실행되어 문제가 발생할 수 있습니다. 이것이 블록체인 오라클의 정보가 정확하고 최신이며 시기적절한지 확인하는 작업을 다루는 '오라클 문제'의 기초입니다.
+
+관련된 보안 문제는 탈중앙화 거래소와 같은 온체인 오라클을 사용하여 자산의 현물 가격을 얻는 것입니다. [탈중앙화 금융(DeFi)](/defi/) 산업의 대출 플랫폼은 사용자가 얼마나 빌릴 수 있는지 결정하기 위해 사용자의 담보 가치를 결정하기 위해 종종 이 작업을 수행합니다.
+
+DEX 가격은 주로 차익 거래자들이 시장의 균형을 회복하기 때문에 종종 정확합니다. 그러나 특히 온체인 오라클이 역사적 거래 패턴에 따라 자산 가격을 계산하는 경우(보통 그렇듯이) 조작에 개방되어 있습니다.
+
+예를 들어, 공격자는 대출 계약과 상호 작용하기 직전에 플래시 론을 받아 자산의 현물 가격을 인위적으로 부풀릴 수 있습니다. DEX에서 자산 가격을 조회하면 (공격자의 대규모 '매수 주문'이 자산 수요를 왜곡하기 때문에) 평소보다 높은 가치가 반환되어 실제보다 더 많이 빌릴 수 있습니다. 이러한 '플래시 론 공격'은 디파이 애플리케이션 간의 가격 오라클 의존도를 악용하는 데 사용되어 프로토콜에 수백만 달러의 자금 손실을 초래했습니다.
+
+##### 오라클 조작 예방 방법
+
+[오라클 조작을 피하기 위한](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples) 최소 요구 사항은 단일 실패 지점을 피하기 위해 여러 소스에서 정보를 쿼리하는 탈중앙화 오라클 네트워크를 사용하는 것입니다. 대부분의 경우 탈중앙화 오라클에는 오라클 노드가 올바른 정보를 보고하도록 장려하는 암호경제적 인센티브가 내장되어 있어 중앙화 오라클보다 더 안전합니다.
+
+자산 가격에 대해 온체인 오라클을 쿼리할 계획이라면 시간 가중 평균 가격(TWAP) 메커니즘을 구현하는 오라클을 사용하는 것을 고려하세요. [TWAP 오라클](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles)은 서로 다른 두 시점(수정 가능)에서 자산 가격을 쿼리하고 얻은 평균을 기반으로 현물 가격을 계산합니다. 더 긴 기간을 선택하면 최근에 실행된 대규모 주문이 자산 가격에 영향을 미칠 수 없으므로 프로토콜을 가격 조작으로부터 보호할 수 있습니다.
+
+## 개발자를 위한 스마트 계약 보안 참고 자료 {#smart-contract-security-resources-for-developers}
+
+### 스마트 계약 분석 및 코드 정확성 검증 도구 {#code-analysis-tools}
+
+- **[테스트 도구 및 라이브러리](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** - _스마트 계약에 대한 단위 테스트, 정적 분석 및 동적 분석을 수행하기 위한 업계 표준 도구 및 라이브러리 모음._
+
+- **[공식 검증 도구](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** - _스마트 계약의 기능적 정확성을 검증하고 불변을 확인하기 위한 도구._
+
+- **[스마트 계약 감사 서비스](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** - _이더리움 개발 프로젝트를 위한 스마트 계약 감사 서비스를 제공하는 조직 목록._
+
+- **[버그 포상금 플랫폼](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** - _버그 포상금을 조정하고 스마트 계약의 중요한 취약점에 대한 책임 있는 공개를 보상하기 위한 플랫폼._
+
+- **[Fork Checker](https://forkchecker.hashex.org/)** - _포크된 계약에 관한 모든 사용 가능한 정보를 확인하기 위한 무료 온라인 도구._
+
+- **[ABI Encoder](https://abi.hashex.org/)** - _솔리디티 계약 기능 및 생성자 인수를 인코딩하기 위한 무료 온라인 서비스._
+
+- **[Aderyn](https://github.com/Cyfrin/aderyn)** - _추상 구문 트리(AST)를 순회하여 의심되는 취약점을 찾아내고 문제를 쉽게 소비할 수 있는 마크다운 형식으로 출력하는 솔리디티 정적 분석기._
+
+### 스마트 계약 모니터링 도구 {#smart-contract-monitoring-tools}
+
+- **[Tenderly 실시간 알림](https://tenderly.co/monitoring)** - _스마트 계약이나 지갑에서 비정상적이거나 예상치 못한 이벤트가 발생했을 때 실시간 알림을 받기 위한 도구._
+
+### 스마트 계약의 안전한 관리를 위한 도구 {#smart-contract-administration-tools}
+
+- **[Safe](https://safe.global/)** - _이더리움에서 실행되는 스마트 계약 지갑으로, 트랜잭션이 발생하기 전에 최소한의 사람들이 승인해야 합니다(M-of-N)._
+
+- **[OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)** - _계약 소유권, 업그레이드, 접근 제어, 거버넌스, 일시 중지 기능 등을 포함한 관리 기능을 구현하기 위한 계약 라이브러리._
+
+### 스마트 계약 감사 서비스 {#smart-contract-auditing-services}
+
+- **[ConsenSys Diligence](https://diligence.consensys.io/)** - _블록체인 생태계 전반의 프로젝트가 프로토콜을 출시할 준비가 되어 있고 사용자를 보호하도록 구축되었는지 확인하는 데 도움이 되는 스마트 계약 감사 서비스._
+
+- **[CertiK](https://www.certik.com/)** - _스마트 계약 및 블록체인 네트워크에 대한 최첨단 공식 검증 기술 사용을 개척하는 블록체인 보안 회사._
+
+- **[Trail of Bits](https://www.trailofbits.com/)** - _보안 연구와 공격자 사고방식을 결합하여 위험을 줄이고 코드를 강화하는 사이버 보안 회사._
+
+- **[PeckShield](https://peckshield.com/)** - _전체 블록체인 생태계의 보안, 개인 정보 보호 및 유용성을 위한 제품과 서비스를 제공하는 블록체인 보안 회사._
+
+- **[QuantStamp](https://quantstamp.com/)** - _보안 및 위험 평가 서비스를 통해 블록체인 기술의 주류 채택을 촉진하는 감사 서비스._
+
+- **[OpenZeppelin](https://www.openzeppelin.com/security-audits)** - _분산 시스템에 대한 보안 감사를 제공하는 스마트 계약 보안 회사._
+
+- **[Runtime Verification](https://runtimeverification.com/)** - _스마트 계약의 공식 모델링 및 검증을 전문으로 하는 보안 회사._
+
+- **[Hacken](https://hacken.io)** - _360도 접근 방식을 블록체인 보안에 도입하는 웹3 사이버 보안 감사자._
+
+- **[Nethermind](https://www.nethermind.io/smart-contract-audits)** - _솔리디티 및 Cairo 감사 서비스로, 이더리움 및 Starknet 전반에 걸쳐 스마트 계약의 무결성과 사용자 안전을 보장합니다._
+
+- **[HashEx](https://hashex.org/)** - _HashEx는 암호화폐의 보안을 보장하기 위해 블록체인 및 스마트 계약 감사에 중점을 두며, 스마트 계약 개발, 침투 테스트, 블록체인 컨설팅과 같은 서비스를 제공합니다._
+
+- **[Code4rena](https://code4rena.com/)** - _스마트 계약 보안 전문가들이 취약점을 찾아내고 웹3를 더 안전하게 만드는 데 도움을 주도록 인센티브를 제공하는 경쟁적인 감사 플랫폼._
+
+- **[CodeHawks](https://codehawks.com/)** - _보안 연구원들을 위한 스마트 계약 감사 대회를 개최하는 경쟁적인 감사 플랫폼._
+
+- **[Cyfrin](https://cyfrin.io)** - _제품 및 스마트 계약 감사 서비스를 통해 암호화 보안을 육성하는 웹3 보안 강자._
+
+- **[ImmuneBytes](https://immunebytes.com/smart-contract-audit/)** - _경험 많은 감사자 팀과 최고 수준의 도구를 통해 블록체인 시스템에 대한 보안 감사를 제공하는 웹3 보안 회사._
+
+- **[Oxorio](https://oxor.io/)** - _암호화 회사 및 디파이 프로젝트를 위한 EVM, 솔리디티, ZK, 크로스체인 기술 전문 지식을 갖춘 스마트 계약 감사 및 블록체인 보안 서비스._
+
+- **[Inference](https://inference.ag/)** - _EVM 기반 블록체인을 위한 스마트 계약 감사를 전문으로 하는 보안 감사 회사._ 전문 감사자 덕분에 잠재적인 문제를 식별하고 배포 전에 이를 해결하기 위한 실행 가능한 해결책을 제안합니다.
+
+### 버그 포상금 플랫폼 {#bug-bounty-platforms}
+
+- **[Immunefi](https://immunefi.com/)** - _스마트 계약 및 디파이 프로젝트를 위한 버그 포상금 플랫폼으로, 보안 연구원들이 코드를 검토하고, 취약점을 공개하고, 보상을 받고, 암호화폐를 더 안전하게 만듭니다._
+
+- **[HackerOne](https://www.hackerone.com/)** - _기업과 침투 테스터 및 사이버 보안 연구원을 연결하는 취약점 조정 및 버그 포상금 플랫폼._
+
+- **[HackenProof](https://hackenproof.com/)** - _암호화 프로젝트(디파이, 스마트 계약, 지갑, CEX 등)를 위한 전문 버그 포상금 플랫폼으로, 보안 전문가들이 분류 서비스를 제공하고 연구원들은 관련 있고 검증된 버그 보고서에 대해 보상을 받습니다._
+
+- **[Sherlock](https://www.sherlock.xyz/)** - _스마트 계약 보안을 위한 웹3의 보험사로, 스마트 계약을 통해 감사자에게 지급되는 보상금을 관리하여 관련 버그가 공정하게 지급되도록 보장합니다._
+
+- **[CodeHawks](https://www.codehawks.com/)** - _감사자들이 보안 대회 및 챌린지에 참여하고 (곧) 자신들의 개인 감사에도 참여하는 경쟁적인 버그 포상금 플랫폼._
+
+### 알려진 스마트 계약 취약점 및 공격 사례 발표 {#common-smart-contract-vulnerabilities-and-exploits}
+
+- **[ConsenSys: 스마트 계약 알려진 공격](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/)** - _가장 중요한 계약 취약점에 대한 초보자 친화적인 설명으로, 대부분의 경우에 대한 샘플 코드가 포함되어 있습니다._
+
+- **[SWC 레지스트리](https://swcregistry.io/)** - _이더리움 스마트 계약에 적용되는 공통 취약점 목록(CWE) 항목의 선별된 목록._
+
+- **[Rekt](https://rekt.news/)** - _주목할 만한 암호화폐 해킹 및 공격 사례에 대한 정기적으로 업데이트되는 간행물로, 상세한 사후 보고서가 함께 제공됩니다._
+
+### 스마트 계약 보안 학습을 위한 챌린지 {#challenges-for-learning-smart-contract-security}
+
+- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** - _블록체인 보안 워게임, 챌린지 및 [캡처 더 플래그](https://www.webopedia.com/definitions/ctf-event/amp/) 대회 및 솔루션 풀이의 선별된 목록._
+
+- **[Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/)** - _디파이 스마트 계약의 공격적 보안을 배우고 버그 헌팅 및 보안 감사 기술을 구축하기 위한 워게임._
+
+- **[Ethernaut](https://ethernaut.openzeppelin.com/)** - _각 레벨이 '해킹'되어야 하는 스마트 계약인 웹3/솔리디티 기반 워게임._
+
+- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** - _판타지 모험을 배경으로 한 스마트 계약 해킹 챌린지._ 챌린지를 성공적으로 완료하면 비공개 버그 포상금 프로그램에 접근할 수도 있습니다.
+
+### 스마트 계약 보안을 위한 모범 사례 {#smart-contract-security-best-practices}
+
+- **[ConsenSys: 이더리움 스마트 계약 보안 모범 사례](https://consensys.github.io/smart-contract-best-practices/)** - _이더리움 스마트 계약 보안을 위한 포괄적인 가이드라인 목록._
+
+- **[Nascent: 단순 보안 툴킷](https://github.com/nascentxyz/simple-security-toolkit)** - _스마트 계약 개발을 위한 실용적인 보안 중심 가이드 및 체크리스트 모음._
+
+- **[솔리디티 패턴](https://fravoll.github.io/solidity-patterns/)** - _스마트 계약 프로그래밍 언어인 솔리디티를 위한 안전한 패턴 및 모범 사례의 유용한 모음집._
+
+- **[솔리디티 문서: 보안 고려 사항](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** - _솔리디티로 안전한 스마트 계약을 작성하기 위한 가이드라인._
+
+- **[스마트 계약 보안 검증 표준](https://github.com/securing/SCSVS)** - _개발자, 설계자, 보안 검토자 및 공급업체를 위해 스마트 계약의 보안을 표준화하기 위해 만들어진 14개 부분으로 구성된 체크리스트._
+
+- **[스마트 계약 보안 및 감사 학습](https://updraft.cyfrin.io/courses/security)** - _보안 모범 사례를 향상시키고 보안 연구원이 되고자 하는 스마트 계약 개발자를 위해 만들어진 최고의 스마트 계약 보안 및 감사 과정._
+
+### 스마트 계약 보안에 관한 튜토리얼 {#tutorials-on-smart-contract-security}
+
+- [안전한 스마트 계약 작성 방법](/developers/tutorials/secure-development-workflow/)
+
+- [Slither를 사용하여 스마트 계약 버그를 찾는 방법](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
+
+- [Manticore를 사용하여 스마트 계약 버그를 찾는 방법](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
+
+- [스마트 계약 보안 가이드라인](/developers/tutorials/smart-contract-security-guidelines/)
+
+- [토큰 계약을 임의의 토큰과 안전하게 통합하는 방법](/developers/tutorials/token-integration-checklist/)
+
+- [Cyfrin Updraft - 스마트 계약 보안 및 감사 전체 과정](https://updraft.cyfrin.io/courses/security)
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/testing/index.md b/public/content/translations/ko/developers/docs/smart-contracts/testing/index.md
new file mode 100644
index 00000000000..691d8ec7991
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/testing/index.md
@@ -0,0 +1,310 @@
+---
+title: "스마트 계약 테스트"
+description: "Ethereum 스마트 계약을 테스트하기 위한 기술 및 고려 사항의 개요입니다."
+lang: ko
+---
+
+Ethereum과 같은 공공 블록체인은 불변성이 있어, 배포 후 스마트 계약 코드를 변경하는 것이 어렵습니다. “가상 업그레이드”를 수행하기 위한 [계약 업그레이드 패턴](/developers/docs/smart-contracts/upgrading/)이 존재하지만, 이는 구현하기 어렵고 사회적 합의가 필요합니다. 또한 업그레이드는 오류가 발견된 _후에만_ 수정할 수 있습니다—만약 공격자가 취약점을 먼저 발견하면 스마트 계약은 공격에 노출될 위험이 있습니다.
+
+이러한 이유로 [배포](/developers/docs/smart-contracts/deploying/)하기 전에 스마트 계약을 테스트하는 것은 [보안](/developers/docs/smart-contracts/security/)을 위한 최소한의 요구 사항입니다. 스마트 계약을 테스트하고 코드의 정확성을 평가하기 위한 다양한 기술이 존재하며, 사용자는 필요에 따라 적절한 방법을 선택할 수 있습니다. 그러나 경미한 보안 결함부터 주요 결함까지 잡아내기 위해서는 다양한 도구와 접근 방식을 포함한 테스트 스위트가 이상적입니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지는 Ethereum 네트워크에 배포하기 전에 스마트 계약을 테스트하는 방법을 설명합니다. 이 문서는 독자가 [스마트 계약](/developers/docs/smart-contracts/)에 익숙하다고 가정합니다.
+
+## 스마트 계약 테스트란 무엇입니까? 스마트 계약 테스트란? {#what-is-smart-contract-testing}
+
+스마트 계약 테스트는 스마트 계약 코드가 예상대로 작동하는지 확인하는 과정입니다. 테스트는 특정 스마트 계약이 신뢰성, 사용성 및 보안 요구 사항을 충족하는지 확인하는 데 유용합니다.
+
+접근 방식은 다양하지만, 대부분의 테스트 방법은 스마트 계약이 처리할 것으로 예상되는 데이터의 소규모 샘플로 계약을 실행하는 것이 필요합니다. 계약이 샘플 데이터에 대해 올바른 결과를 생성하면 정상적으로 작동하는 것으로 간주됩니다. 대부분의 테스트 도구는 계약의 실행이 예상 결과와 일치하는지 확인하기 위해 [테스트 케이스](https://en.m.wikipedia.org/wiki/Test_case)를 작성하고 실행하기 위한 리소스를 제공합니다.
+
+### 스마트 계약을 테스트하는 것이 왜 중요한가요? 스마트 계약 테스트의 중요성 {#importance-of-testing-smart-contracts}
+
+스마트 계약은 종종 고가의 금융 자산을 관리하기 때문에, 사소한 프로그래밍 오류가 [사용자에게 막대한 손실](https://rekt.news/leaderboard/)로 이어질 수 있으며, 실제로도 종종 그렇습니다. 엄격한 테스트를 통해 스마트 계약 코드의 결함과 문제를 조기에 발견하고 메인넷에 배포하기 전에 수정할 수 있습니다.
+
+버그가 발견되면 계약을 업그레이드할 수 있지만, 업그레이드는 복잡하며 부적절하게 처리될 경우 [오류를 초래](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/)할 수 있습니다. 계약을 업그레이드하는 것은 불변성의 원칙을 무시하고 사용자가 추가 신뢰 가정을 가지게 합니다. 반대로, 계약 테스트에 대한 포괄적인 계획은 스마트 계약 보안 위험을 완화하고 배포 후 복잡한 논리 업그레이드 수행 필요성을 줄입니다.
+
+## 스마트 계약 테스트 방법 {#methods-for-testing-smart-contracts}
+
+이더리움 스마트 계약 테스트 방법은 자동화된 테스트와 수동 테스트라는 두 가지 큰 범주로 나뉩니다. 자동화 테스트와 수동 테스트는 각각 고유한 장점과 단점을 제공하지만, 두 가지를 결합하여 계약 분석을 위한 강력한 계획을 수립할 수 있습니다.
+
+### 자동화된 테스트 {#automated-testing}
+
+자동화 테스트는 스마트 계약 코드의 실행 오류를 자동으로 검사하는 도구를 사용합니다. 자동화된 테스트의 이점은 계약 기능성 평가를 안내하기 위해 [스크립트](https://www.techtarget.com/whatis/definition/script?amp=1)를 사용하는 데서 비롯됩니다. 스크립트화된 테스트는 최소한의 인간 개입으로 반복적으로 실행되도록 예약할 수 있어 수동 테스트 접근 방식보다 효율적입니다.
+
+자동화 테스트는 테스트가 반복적이거나 시간 소모적일 때, 수동으로 수행하기 어려울 때, 인간의 실수가 발생할 수 있을 때 또는 중요한 계약 기능을 평가할 때 특히 유용합니다. 그러나 자동화된 테스트 도구는 특정 버그를 놓치거나 많은 [오탐](https://www.contrastsecurity.com/glossary/false-positive)을 생성할 수 있다는 단점이 있을 수 있습니다. 따라서 스마트 계약의 경우 자동화 테스트와 수동 테스트를 결합하는 것이 이상적입니다.
+
+### 수동 테스트 {#manual-testing}
+
+수동 테스트는 인간의 도움이 필요하며 스마트 계약의 정확성을 분석할 때 테스트 케이스를 하나씩 실행하는 것입니다. 이는 계약에서 여러 독립 테스트를 동시에 실행하고 모든 실패 및 성공 테스트를 보여주는 보고서를 얻는 자동화 테스트와 다릅니다.
+
+수동 테스트는 다양한 테스트 시나리오를 포함하는 작성된 테스트 계획에 따라 단일 개인이 수행할 수도 있습니다. 또한 여러 개인 또는 그룹이 지정된 기간 동안 스마트 계약과 상호 작용하는 수동 테스트의 일환으로 참여할 수 있습니다. 테스터는 계약의 실제 동작을 예상 동작과 비교하고 차이점이 발견되면 이를 버그로 표시합니다.
+
+효과적인 수동 테스트에는 상당한 자원(기술, 시간, 비용, 노력)이 필요하며, 실행 중 실수로 인해 특정 오류가 누락될 수 있습니다. 그러나 수동 테스트는 직관을 사용하여 자동화 테스트 도구에서 놓칠 수 있는 경계 사례를 탐지하는 인간 테스터(예: 감사자)에게 유용할 수 있습니다.
+
+## 스마트 계약을 위한 자동화된 테스트 {#automated-testing-for-smart-contracts}
+
+### 단위 테스트 {#unit-testing-for-smart-contracts}
+
+유닛 테스트는 계약 기능을 개별적으로 평가하고 각 구성 요소가 올바르게 작동하는지 확인합니다. 좋은 유닛 테스트는 간단하고 실행이 빠르며, 테스트 실패 시 어떤 문제가 발생했는지 명확하게 알 수 있습니다.
+
+유닛 테스트는 함수가 예상된 값을 반환하고 함수 실행 후 계약 저장소가 제대로 업데이트되는지 확인하는 데 유용합니다. 또한, 계약 코드베이스에 변경 사항을 추가한 후 유닛 테스트를 실행하면 새로운 로직이 오류를 도입하지 않았는지 확인할 수 있습니다. 다음은 효과적인 유닛 테스트를 실행하기 위한 몇 가지 지침입니다:
+
+#### 스마트 계약 단위 테스트 지침 {#unit-testing-guidelines}
+
+##### 1. 계약의 비즈니스 로직과 워크플로를 이해하세요
+
+유닛 테스트를 작성하기 전에 스마트 계약이 제공하는 기능과 사용자가 해당 기능에 액세스하고 사용하는 방법을 아는 것이 좋습니다. 이는 계약의 함수가 유효한 사용자 입력에 대해 올바른 출력을 반환하는지 판단하는 [해피 패스 테스트](https://en.m.wikipedia.org/wiki/Happy_path)를 실행하는 데 특히 유용합니다. 이 개념을 [경매 계약](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction)의 (축약된) 예시를 사용하여 설명하겠습니다.
+
+```solidity
+constructor(
+ uint biddingTime,
+ address payable beneficiaryAddress
+ ) {
+ beneficiary = beneficiaryAddress;
+ auctionEndTime = block.timestamp + biddingTime;
+ }
+
+function bid() external payable {
+
+ if (block.timestamp > auctionEndTime)
+ revert AuctionAlreadyEnded();
+
+ if (msg.value <= highestBid)
+ revert BidNotHighEnough(highestBid);
+
+ if (highestBid != 0) {
+ pendingReturns[highestBidder] += highestBid;
+ }
+ highestBidder = msg.sender;
+ highestBid = msg.value;
+ emit HighestBidIncreased(msg.sender, msg.value);
+ }
+
+ function withdraw() external returns (bool) {
+ uint amount = pendingReturns[msg.sender];
+ if (amount > 0) {
+ pendingReturns[msg.sender] = 0;
+
+ if (!payable(msg.sender).send(amount)) {
+ pendingReturns[msg.sender] = amount;
+ return false;
+ }
+ }
+ return true;
+ }
+
+function auctionEnd() external {
+ if (block.timestamp < auctionEndTime)
+ revert AuctionNotYetEnded();
+ if (ended)
+ revert AuctionEndAlreadyCalled();
+
+ ended = true;
+ emit AuctionEnded(highestBidder, highestBid);
+
+ beneficiary.transfer(highestBid);
+ }
+}
+```
+
+이것은 입찰 기간 동안 입찰을 받도록 설계된 간단한 경매 계약입니다. `highestBid`가 증가하면 이전 최고 입찰자는 자신의 돈을 돌려받습니다. 입찰 기간이 끝나면 `beneficiary`는 계약을 호출하여 자신의 돈을 받습니다.
+
+이와 같은 계약에 대한 유닛 테스트는 사용자가 계약과 상호 작용할 때 호출할 수 있는 다양한 기능을 다룹니다. 예를 들어, 경매가 진행 중일 때 사용자가 입찰할 수 있는지 확인하는 단위 테스트(`bid()` 호출이 성공하는지)나 사용자가 현재의 `highestBid`보다 높은 입찰을 할 수 있는지 확인하는 테스트가 있을 수 있습니다.
+
+계약의 운영 워크플로를 이해하면 실행이 요구 사항을 충족하는지 확인하는 유닛 테스트를 작성하는 데 도움이 됩니다. 예를 들어, 경매 계약은 경매가 종료되었을 때(즉, `auctionEndTime`이 `block.timestamp`보다 낮을 때) 사용자가 입찰할 수 없다고 명시합니다. 따라서 개발자는 경매가 끝났을 때(즉, `auctionEndTime` > `block.timestamp`일 때) `bid()` 함수 호출이 성공하는지 또는 실패하는지를 확인하는 단위 테스트를 실행할 수 있습니다.
+
+##### 2. 계약 실행과 관련된 모든 가정을 평가하세요
+
+계약의 실행에 대한 모든 가정을 문서화하고 해당 가정의 타당성을 확인하는 유닛 테스트를 작성하는 것이 중요합니다. 예상치 못한 실행에 대한 보호를 제공할 뿐만 아니라, 테스트 가정을 통해 스마트 계약의 보안 모델을 위반할 수 있는 작업에 대해 생각하게 합니다. 유용한 팁은 "행복한 사용자 테스트"를 넘어서 잘못된 입력에 대해 함수가 실패하는지 확인하는 부정 테스트를 작성하는 것입니다.
+
+많은 유닛 테스트 프레임워크는 계약이 할 수 있는 것과 할 수 없는 것을 명시하는 간단한 문장인 어설션을 생성하고, 해당 어설션이 실행 중에 유지되는지 확인하는 테스트를 실행할 수 있습니다. 위에서 설명한 경매 계약을 작업하는 개발자는 부정 테스트를 실행하기 전에 다음과 같은 행동에 대한 어설션을 만들 수 있습니다:
+
+- 경매가 종료되었거나 시작되지 않았을 때 사용자는 입찰할 수 없습니다.
+
+- 입찰이 허용 가능한 기준에 미달하면 경매 계약이 복구됩니다.
+
+- 입찰에 실패한 사용자는 자금이 반환됩니다.
+
+**참고**: 가정을 테스트하는 또 다른 방법은 계약에서, 특히 `require`, `assert`, `if…else` 문과 같은 [함수 제어자](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers)를 트리거하는 테스트를 작성하는 것입니다.
+
+##### 3. 코드 커버리지 측정
+
+[코드 커버리지](https://en.m.wikipedia.org/wiki/Code_coverage)는 테스트 중에 실행된 코드의 분기, 줄, 문의 수를 추적하는 테스트 지표입니다. 테스트되지 않은 취약점의 위험을 최소화하기 위해 테스트는 우수한 코드 커버리지를 가져야 합니다. 충분한 커버리지가 없으면 모든 테스트가 통과하기 때문에 계약이 안전하다고 잘못 가정할 수 있지만, 테스트되지 않은 코드 경로에는 여전히 취약점이 존재합니다. 높은 코드 커버리지를 기록하면 스마트 계약의 모든 문장/함수가 충분히 테스트되어 올바르게 작동함을 보장합니다.
+
+##### 4. 잘 개발된 테스트 프레임워크를 사용하십시오.
+
+스마트 계약의 단위 테스트를 실행할 때 사용하는 도구의 품질은 매우 중요합니다. 이상적인 테스트 프레임워크는 정기적으로 유지 보수되고, 유용한 기능(예: 로깅 및 보고 기능)을 제공하며, 다른 개발자들에 의해 광범위하게 사용되고 검증된 프레임워크입니다.
+
+Solidity 스마트 계약을 위한 단위 테스트 프레임워크는 다양한 언어(주로 JavaScript, Python, Rust) 로 제공됩니다. 아래 가이드에서 다양한 테스트 프레임워크로 단위 테스트를 시작하는 방법에 대한 정보를 확인하십시오:
+
+- **[Brownie로 단위 테스트 실행하기](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)**
+- **[Foundry로 단위 테스트 실행하기](https://book.getfoundry.sh/forge/writing-tests)**
+- **[Waffle로 단위 테스트 실행하기](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)**
+- **[Remix로 단위 테스트 실행하기](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)**
+- **[Ape로 단위 테스트 실행하기](https://docs.apeworx.io/ape/stable/userguides/testing.html)**
+- **[Hardhat으로 단위 테스트 실행하기](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)**
+- **[Wake로 단위 테스트 실행하기](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)**
+
+### 통합 테스트 {#integration-testing-for-smart-contracts}
+
+단위 테스트가 계약 함수들을 개별적으로 디버깅하는 동안, 통합 테스트는 스마트 계약의 모든 구성 요소를 평가합니다. 통합 테스트는 다른 스마트 계약 간의 상호작용이나 같은 스마트 계약 내의 다양한 함수 간의 호출로 인해 발생하는 문제를 감지할 수 있습니다. 예를 들어, 통합 테스트는 [상속](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) 및 종속성 주입과 같은 기능이 제대로 작동하는지 확인하는 데 도움이 될 수 있습니다.
+
+통합 테스트는 계약이 모듈식 아키텍처를 채택하거나 실행 중에 다른 온체인 계약과 인터페이스하는 경우에 유용합니다. 통합 테스트를 실행하는 한 가지 방법은 특정 높이에서 [블록체인을 포크](/glossary/#fork)하고([Forge](https://book.getfoundry.sh/forge/fork-testing) 또는 [Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks)과 같은 도구 사용) 계약과 배포된 계약 간의 상호 작용을 시뮬레이션하는 것입니다.
+
+포크된 블록체인은 메인넷과 유사하게 작동하며 관련 상태와 잔액을 가진 계정을 포함합니다. 그러나 이 환경은 로컬 개발 환경에만 국한되므로 예를 들어 실제 이더리움(ETH)이 트랜잭션에 필요하지 않으며, 실제 이더리움 프로토콜에 영향을 주지 않습니다.
+
+### 속성 기반 테스트 {#property-based-testing-for-smart-contracts}
+
+속성 기반 테스트는 스마트 계약이 정의된 속성을 충족하는지 확인하는 과정입니다. 속성은 계약의 동작에 대해 다양한 시나리오에서 참으로 유지될 것으로 예상되는 사실을 나타냅니다—예를 들어, "계약의 산술 연산은 오버플로 또는 언더플로를 발생시키지 않는다"라는 것이 스마트 계약 속성의 예일 수 있습니다.
+
+정적 분석과 동적 분석은 속성 기반 테스트를 실행하기 위한 두 가지 일반적인 기술이며, 두 기술 모두 프로그램(이 경우 스마트 계약)의 코드가 미리 정의된 속성을 만족하는지 확인할 수 있습니다. 일부 속성 기반 테스트 도구는 예상되는 계약 속성에 대한 미리 정의된 규칙을 제공하며, 코드가 이러한 규칙을 준수하는지 확인합니다. 다른 도구는 스마트 계약에 대한 사용자 지정 속성을 생성할 수 있도록 합니다.
+
+#### 정적 분석 {#static-analysis}
+
+정적 분석 도구는 스마트 계약의 소스 코드를 입력으로 받아 계약이 속성을 충족하는지 여부를 선언하는 결과를 출력합니다. 동적 분석과는 달리, 정적 분석은 계약을 실행하지 않고 올바름을 분석합니다. 정적 분석은 대신 계약이 실행 중에 가질 수 있는 모든 경로를 추론하며(즉, 소스 코드 구조를 검사하여 런타임에 계약의 작동이 어떻게 되는지 결정합니다).
+
+[린팅](https://www.perforce.com/blog/qac/what-is-linting)과 [정적 테스트](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis)는 계약에 대한 정적 분석을 실행하는 일반적인 방법입니다. 두 방법 모두 컴파일러가 출력하는 [추상 구문 트리](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) 및 [제어 흐름 그래프](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/)와 같은 계약 실행의 저수준 표현을 분석해야 합니다.
+
+대부분의 경우, 정적 분석은 코드에서 안전하지 않은 구조물 사용, 구문 오류 또는 코딩 표준 위반과 같은 안전 문제를 감지하는 데 유용합니다. 그러나 정적 분석기는 더 깊은 취약점을 감지하는 데는 일반적으로 효과적이지 않으며, 과도한 거짓 양성 결과를 생성할 수 있습니다.
+
+#### 동적 분석 {#dynamic-analysis}
+
+동적 분석은 스마트 계약 함수의 [심볼릭 실행](https://en.m.wikipedia.org/wiki/Symbolic_execution)에서의 심볼릭 입력이나 [퍼징](https://owasp.org/www-community/Fuzzing)에서의 구체적인 입력과 같은 것을 생성하여 실행 추적이 특정 속성을 위반하는지 확인합니다. 이러한 속성 기반 테스트는 테스트 케이스가 여러 시나리오를 포괄하며 프로그램이 테스트 케이스를 생성하는 방식에서 단위 테스트와 다릅니다.
+
+[퍼징](https://www.halborn.com/blog/post/what-is-fuzz-testing-fuzzing)은 스마트 계약에서 임의의 속성을 검증하기 위한 동적 분석 기법의 한 예입니다. 퍼저는 정의된 입력 값의 무작위 또는 잘못된 변형으로 대상 계약의 함수를 호출합니다. 스마트 계약이 오류 상태(예: 단언이 실패하는 상태)에 들어가면 문제가 플래그 처리되며 취약한 경로로 실행을 유도하는 입력이 보고서에 생성됩니다.
+
+퍼징은 스마트 계약의 입력 유효성 검사 메커니즘을 평가하는 데 유용합니다. 예상치 못한 입력을 적절히 처리하지 않으면 의도치 않은 실행이 발생하고 위험한 영향을 초래할 수 있기 때문입니다. 이러한 속성 기반 테스트는 여러 이유로 이상적일 수 있습니다:
+
+1. **많은 시나리오를 다루는 테스트 케이스를 작성하는 것은 어렵습니다.** 속성 테스트는 동작을 정의하고 해당 동작을 테스트할 데이터의 범위를 정의하기만 하면 됩니다. 프로그램은 정의된 속성을 기반으로 테스트 케이스를 자동으로 생성합니다.
+
+2. **테스트 스위트가 프로그램 내의 모든 가능한 경로를 충분히 다루지 못할 수 있습니다.** 100%의 커버리지를 달성하더라도 에지 케이스를 놓칠 수 있습니다.
+
+3. **단위 테스트는 샘플 데이터에 대해 계약이 올바르게 실행됨을 증명하지만, 샘플 외부의 입력에 대해 계약이 올바르게 실행되는지는 알 수 없습니다.** 속성 테스트는 주어진 입력 값의 다양한 변형으로 대상 계약을 실행하여 어설션 실패를 유발하는 실행 추적을 찾습니다. 따라서 속성 테스트는 계약이 광범위한 입력 데이터 클래스에 대해 올바르게 실행됨을 더 많이 보장합니다.
+
+### 스마트 계약의 속성 기반 테스트 실행 지침 {#running-property-based-tests}
+
+속성 기반 테스트 실행은 일반적으로 스마트 계약에서 검증하려는 속성(예: [정수 오버플로](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)의 부재) 또는 속성 모음을 정의하는 것으로 시작됩니다. 속성 테스트를 작성할 때 트랜잭션 입력에 대해 프로그램이 생성할 수 있는 값의 범위를 정의해야 할 수도 있습니다.
+
+적절하게 구성된 속성 테스트 도구는 무작위로 생성된 입력을 사용하여 스마트 계약 기능을 실행합니다. 어설션 위반이 있으면 평가 중인 속성을 위반하는 구체적인 입력 데이터를 포함한 보고서를 받을 수 있습니다. 다음 가이드를 통해 다양한 도구로 속성 기반 테스트를 실행하는 방법을 시작할 수 있습니다:
+
+- **[Slither를 사용한 스마트 계약의 정적 분석](https://github.com/crytic/slither)**
+- **[Wake를 사용한 스마트 계약의 정적 분석](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)**
+- **[Brownie를 사용한 속성 기반 테스트](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)**
+- **[Foundry를 사용한 계약 퍼징](https://book.getfoundry.sh/forge/fuzz-testing)**
+- **[Echidna를 사용한 계약 퍼징](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)**
+- **[Wake를 사용한 계약 퍼징](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)**
+- **[Manticore를 사용한 스마트 계약의 심볼릭 실행](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)**
+- **[Mythril을 사용한 스마트 계약의 심볼릭 실행](https://mythril-classic.readthedocs.io/en/master/tutorial.html)**
+
+## 스마트 계약의 수동 테스트 {#manual-testing-for-smart-contracts}
+
+스마트 계약의 수동 테스트는 일반적으로 자동화된 테스트를 실행한 후 개발 주기 후반에 수행됩니다. 이 형태의 테스트는 스마트 계약을 하나의 통합된 제품으로 평가하여 기술 요구 사항에 지정된 대로 성능을 발휘하는지 확인합니다.
+
+### 로컬 블록체인에서 계약 테스트하기 {#testing-on-local-blockchain}
+
+로컬 개발 환경에서 수행된 자동화 테스트는 유용한 디버깅 정보를 제공할 수 있지만, 프로덕션 환경에서 스마트 계약이 어떻게 작동하는지 알아야 합니다. 그러나 메인 이더리움 체인에 배포하면 가스 요금이 발생하며, 스마트 계약에 여전히 버그가 있을 경우 실제 돈을 잃을 수도 있습니다.
+
+로컬 블록체인([개발 네트워크](/developers/docs/development-networks/)라고도 함)에서 계약을 테스트하는 것은 메인넷에서 테스트하는 것에 대한 권장 대안입니다. 로컬 블록체인은 컴퓨터에서 로컬로 실행되는 이더리움 블록체인의 사본으로 이더리움의 실행 레이어의 동작을 시뮬레이션합니다. 따라서 상당한 오버헤드 없이 계약과 상호 작용하는 트랜잭션을 프로그래밍할 수 있습니다.
+
+로컬 블록체인에서 계약을 실행하는 것은 수동 통합 테스트의 한 형태로 유용할 수 있습니다. [스마트 계약은 구성성이 높기 때문에](/developers/docs/smart-contracts/composability/) 기존 프로토콜과 통합할 수 있습니다. 하지만 이러한 복잡한 온체인 상호 작용이 올바른 결과를 생성하는지 확인해야 합니다.
+
+[개발 네트워크에 대해 자세히 알아보기](/developers/docs/development-networks/)
+
+### 테스트넷에서 계약 테스트하기 {#testing-contracts-on-testnets}
+
+테스트 네트워크 또는 테스트넷은 실제 가치가 없는 이더(ETH)를 사용한다는 점을 제외하면 이더리움 메인넷과 똑같이 작동합니다. 계약을 [테스트넷](/developers/docs/networks/#ethereum-testnets)에 배포하면 누구나 자금의 위험 없이 계약과 상호 작용할 수 있습니다(예: 탈중앙화앱의 프론트엔드를 통해).
+
+이 형태의 수동 테스트는 애플리케이션의 엔드투엔드 플로우를 사용자의 관점에서 평가하는 데 유용합니다. 여기에서 베타 테스터도 시운전을 수행하고 계약의 비즈니스 논리 및 전반적인 기능과 관련된 문제를 보고할 수 있습니다.
+
+로컬 블록체인에서 테스트한 후 테스트넷에 배포하는 것이 이상적입니다. 테스트넷의 동작이 이더리움 가상 머신과 유사하기 때문입니다. 따라서 많은 이더리움 네이티브 프로젝트가 실제 조건에서 스마트 계약 작동을 평가하기 위해 테스트넷에 dapp을 배포하는 것이 일반적입니다.
+
+[이더리움 테스트넷에 대해 자세히 알아보기](/developers/docs/development-networks/#public-beacon-testchains)
+
+## 테스트와 형식 검증 비교 {#testing-vs-formal-verification}
+
+테스트는 특정 데이터 입력에 대해 계약이 예상 결과를 반환하는지 확인하는 데 도움이 되지만, 테스트에 사용되지 않은 입력에 대해 동일한 결과를 확정적으로 입증할 수는 없습니다. 따라서 스마트 계약을 테스트하는 것은 '기능적 정확성'을 보장할 수 없습니다(즉, 프로그램이 `모든` 입력값 세트에 대해 요구되는 대로 동작한다는 것을 보여줄 수 없습니다).
+
+형식 검증은 프로그램의 형식 모델이 형식 명세와 일치하는지 확인하여 소프트웨어의 정확성을 평가하는 접근 방식입니다. 형식 모델은 프로그램의 추상적 수학적 표현이며, 형식 명세는 프로그램의 속성(즉, 프로그램 실행에 대한 논리적 어설션)을 정의합니다.
+
+속성이 수학적 용어로 작성되므로 시스템의 형식(수학적) 모델이 논리적 추론 규칙을 사용하여 명세를 충족하는지 검증할 수 있습니다. 따라서 형식 검증 도구는 시스템의 정확성에 대한 '수학적 증거'를 제공한다고 합니다.
+
+테스트와 달리, 형식 검증은 샘플 데이터로 실행할 필요 없이 `모든` 실행에 대해 스마트 계약 실행이 형식 사양을 만족하는지(즉, 버그가 없는지) 확인하는 데 사용할 수 있습니다. 이는 수많은 단위 테스트를 실행하는 데 걸리는 시간을 줄일 뿐만 아니라 숨겨진 취약점을 잡는 데도 더 효과적입니다. 말하자면, 형식 검증 기술은 구현의 난이도와 유용성에 따라 범위에 따라 다릅니다.
+
+[스마트 계약의 형식 검증에 대해 자세히 알아보기](/developers/docs/smart-contracts/formal-verification)
+
+## 테스트와 감사 및 버그 바운티 비교 {#testing-vs-audits-bug-bounties}
+
+앞서 언급했듯이, 엄격한 테스트는 계약에서 버그가 없음을 보장하기 어렵습니다. 형식 검증 접근 방식은 더 강력한 정확성 보증을 제공할 수 있지만, 현재 사용하기 어렵고 상당한 비용이 듭니다.
+
+그럼에도 불구하고 타인으로 하여금 계약을 분석하도록 하여 계약의 취약점을 포착할 가능성을 높일 수 있습니다. [스마트 계약 감사](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/)와 [버그 바운티](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)는 다른 사람이 여러분의 계약을 분석하게 하는 두 가지 방법입니다.
+
+감사는 스마트 계약에서 보안 결함 및 개발 관행의 부족한 사례를 찾는 데 경험이 많은 감사자가 수행합니다. 감사는 테스트(그리고 가능하면 형식 검증)뿐만 아니라 전체 코드베이스에 대한 수동 검토도 포함됩니다.
+
+반대로 버그 바운티 프로그램은 일반적으로 스마트 계약의 취약점을 발견하여 개발자에게 공개하는 개인(`[화이트햇 해커]()`라고 흔히 칭함)에게 금전적 보상을 제공하는 것을 포함합니다. 버그 바운티는 스마트 계약에서 결함을 찾는 데 다른 사람의 도움을 요청하는 점에서 감사와 유사합니다.
+
+주요 차이점은 버그 바운티 프로그램이 더 넓은 개발자/해커 커뮤니티에 개방되어 있으며 독특한 기술과 경험을 가진 다양한 윤리적 해커와 독립 보안 전문가들을 끌어들인다는 것입니다. 이것은 제한되거나 좁은 전문 지식을 가진 팀에 의존하는 스마트 계약 감사를 능가하는 장점이 될 수 있습니다.
+
+## 테스트 도구 및 라이브러리 {#testing-tools-and-libraries}
+
+### 단위 테스트 도구 {#unit-testing-tools}
+
+- **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** - _Solidity로 작성된 스마트 계약을 위한 코드 커버리지 도구입니다._
+
+- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** - _고급 스마트 계약 개발 및 테스트를 위한 프레임워크(ethers.js 기반)입니다._
+
+- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _Solidity 스마트 계약 테스트용 도구입니다._ Remix IDE의 "Solidity Unit Testing" 플러그인을 통해 계약의 테스트 케이스를 작성하고 실행하는 데 사용됩니다._
+
+- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _이더리움 스마트 계약 테스트를 위한 어설션 라이브러리입니다._ 계약이 예상대로 작동하는지 확인하세요!_
+
+- **[Brownie 단위 테스트 프레임워크](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _Brownie는 기능이 풍부한 테스트 프레임워크인 Pytest를 활용하여 최소한의 코드로 작은 테스트를 작성하고, 대규모 프로젝트에 맞게 확장하며, 높은 확장성을 제공합니다._
+
+- **[Foundry 테스트](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** - _Foundry는 간단한 단위 테스트, 가스 최적화 확인, 계약 퍼징을 실행할 수 있는 빠르고 유연한 이더리움 테스트 프레임워크인 Forge를 제공합니다._
+
+- **[Hardhat 테스트](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _ethers.js, Mocha, Chai를 기반으로 한 스마트 계약 테스트용 프레임워크입니다._
+
+- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _이더리움 가상 머신을 대상으로 하는 스마트 계약을 위한 Python 기반 개발 및 테스트 프레임워크입니다._
+
+- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _강력한 디버깅 기능과 교차 체인 테스트를 지원하는 단위 테스트 및 퍼징을 위한 Python 기반 프레임워크로, 최상의 사용자 경험과 성능을 위해 pytest와 Anvil을 활용합니다._
+
+### 속성 기반 테스트 도구 {#property-based-testing-tools}
+
+#### 정적 분석 도구 {#static-analysis-tools}
+
+- **[Slither](https://github.com/crytic/slither)** - _취약점 발견, 코드 이해도 향상, 스마트 계약을 위한 맞춤형 분석 작성을 위한 Python 기반 Solidity 정적 분석 프레임워크입니다._
+
+- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _Solidity 스마트 계약 프로그래밍 언어에 대한 스타일 및 보안 모범 사례를 적용하기 위한 린터입니다._
+
+- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** - _Web3 스마트 계약 보안 및 개발을 위해 특별히 설계된 Rust 기반 정적 분석기입니다._
+
+- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _취약성 및 코드 품질 감지기, 코드에서 유용한 정보를 추출하기 위한 프린터, 맞춤형 하위 모듈 작성을 지원하는 Python 기반 정적 분석 프레임워크입니다._
+
+- **[Slippy](https://github.com/fvictorio/slippy)** - _Solidity를 위한 간단하고 강력한 린터입니다._
+
+#### 동적 분석 도구 {#dynamic-analysis-tools}
+
+- **[Echidna](https://github.com/crytic/echidna/)** - _속성 기반 테스트를 통해 스마트 계약의 취약점을 탐지하는 빠른 계약 퍼저입니다._
+
+- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _스마트 계약 코드에서 속성 위반을 탐지하는 데 유용한 자동화된 퍼징 도구입니다._
+
+- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** - _EVM 바이트코드 분석을 위한 동적 심볼릭 실행 프레임워크입니다._
+
+- **[Mythril](https://github.com/ConsenSys/mythril-classic)** - _테인트 분석, 콘콜릭 분석 및 제어 흐름 검사를 사용하여 계약 취약점을 탐지하는 EVM 바이트코드 평가 도구입니다._
+
+- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _Scribble은 명세 언어이자 런타임 검증 도구로, 스마트 계약에 속성을 주석으로 달아 Diligence Fuzzing이나 MythX와 같은 도구로 계약을 자동으로 테스트할 수 있게 해줍니다._
+
+## 관련 튜토리얼 {#related-tutorials}
+
+- [다양한 테스트 제품 개요 및 비교](/developers/tutorials/guide-to-smart-contract-security-tools/) \_
+- [Echidna를 사용하여 스마트 계약을 테스트하는 방법](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/)
+- [Manticore를 사용하여 스마트 계약 버그를 찾는 방법](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
+- [Slither를 사용하여 스마트 계약 버그를 찾는 방법](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
+- [테스트를 위해 Solidity 계약을 모의하는 방법](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/)
+- [Foundry를 사용하여 Solidity에서 단위 테스트를 실행하는 방법](https://www.rareskills.io/post/foundry-testing-solidity)
+
+## 더 읽어보기 {#further-reading}
+
+- [이더리움 스마트 계약 테스트에 대한 심층 가이드](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297)
+- [이더리움 스마트 계약을 테스트하는 방법](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d)
+- [MolochDAO의 개발자를 위한 단위 테스트 가이드](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide)
+- [록스타처럼 스마트 계약을 테스트하는 방법](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001)
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/upgrading/index.md b/public/content/translations/ko/developers/docs/smart-contracts/upgrading/index.md
new file mode 100644
index 00000000000..8d7c3939257
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/upgrading/index.md
@@ -0,0 +1,165 @@
+---
+title: "스마트 계약 업그레이드"
+description: "이더리움 스마트 계약의 업그레이드 패턴 개요"
+lang: ko
+---
+
+이더리움의 스마트 계약은 이더리움 가상 머신(EVM)에서 실행되는 자동 실행 프로그램입니다. 이 프로그램은 설계상 불변성을 가지므로 계약이 배포된 후에는 비즈니스 로직을 업데이트할 수 없습니다.
+
+불변성은 스마트 계약의 무신뢰성, 탈중앙화 및 보안에 필수적이지만, 경우에 따라 단점이 될 수 있습니다. 예를 들어, 불변 코드로 인해 개발자가 취약한 계약을 수정하는 것이 불가능할 수 있습니다.
+
+그러나 스마트 계약 개선에 대한 연구가 증가하면서 여러 업그레이드 패턴이 도입되었습니다. 이러한 업그레이드 패턴을 통해 개발자는 비즈니스 로직을 다른 계약에 배치하여 (불변성을 유지하면서) 스마트 계약을 업그레이드할 수 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+[스마트 계약](/developers/docs/smart-contracts/), [스마트 계약 구조](/developers/docs/smart-contracts/anatomy/), [이더리움 가상 머신(EVM)](/developers/docs/evm/)에 대해 잘 이해하고 있어야 합니다. 또한 이 가이드는 독자가 스마트 계약 프로그래밍에 대한 이해가 있다고 가정합니다.
+
+## 스마트 계약 업그레이드란 무엇인가요? {#what-is-a-smart-contract-upgrade}
+
+스마트 계약 업그레이드는 계약의 상태를 보존하면서 스마트 계약의 비즈니스 로직을 변경하는 것을 포함합니다. 특히 스마트 계약의 맥락에서 업그레이드 가능성과 가변성은 동일하지 않다는 점을 명확히 하는 것이 중요합니다.
+
+이더리움 네트워크의 주소에 배포된 프로그램은 여전히 변경할 수 없습니다. 하지만 사용자가 스마트 계약과 상호 작용할 때 실행되는 코드는 변경할 수 있습니다.
+
+다음과 같은 방법을 통해 수행할 수 있습니다.
+
+1. 스마트 계약의 여러 버전을 만들고 이전 계약에서 계약의 새 인스턴스로 상태(즉, 데이터)를 마이그레이션합니다.
+
+2. 비즈니스 로직과 상태를 저장하기 위해 별도의 계약을 생성합니다.
+
+3. 프록시 패턴을 사용하여 불변 프록시 계약에서 수정 가능한 로직 계약으로 함수 호출을 위임합니다.
+
+4. 특정 함수를 실행하기 위해 유연한 위성 계약과 인터페이스하고 의존하는 불변 메인 계약을 생성합니다.
+
+5. 다이아몬드 패턴을 사용하여 프록시 계약에서 로직 계약으로 함수 호출을 위임합니다.
+
+### 업그레이드 메커니즘 #1: 계약 마이그레이션 {#contract-migration}
+
+계약 마이그레이션은 버전 관리를 기반으로 합니다. 이는 동일한 소프트웨어의 고유한 상태를 생성하고 관리하는 개념입니다. 계약 마이그레이션은 기존 스마트 계약의 새 인스턴스를 배포하고 저장 공간과 잔액을 새 계약으로 이전하는 것을 포함합니다.
+
+새로 배포된 계약은 빈 저장 공간을 가지므로 이전 계약에서 데이터를 복구하고 새 구현에 쓸 수 있습니다. 그 후에는 이전 계약과 상호 작용했던 모든 계약을 업데이트하여 새 주소를 반영해야 합니다.
+
+계약 마이그레이션의 마지막 단계는 사용자가 새 계약을 사용하도록 설득하는 것입니다. 새로운 계약 버전은 사용자 잔액과 주소를 유지하여 불변성을 보존합니다. 토큰 기반 계약인 경우 거래소에 연락하여 이전 계약을 폐기하고 새 계약을 사용하도록 해야 합니다.
+
+계약 마이그레이션은 사용자 상호 작용을 방해하지 않고 스마트 계약을 업그레이드하는 비교적 간단하고 안전한 방법입니다. 그러나 사용자 저장 공간과 잔액을 새 계약으로 수동으로 마이그레이션하는 것은 시간이 많이 걸리고 높은 가스 비용이 발생할 수 있습니다.
+
+[계약 마이그레이션에 대해 더 알아보기.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/)
+
+### 업그레이드 메커니즘 #2: 데이터 분리 {#data-separation}
+
+스마트 계약을 업그레이드하는 또 다른 방법은 비즈니스 로직과 데이터 저장 공간을 별도의 계약으로 분리하는 것입니다. 즉, 사용자는 로직 계약과 상호 작용하고 데이터는 저장 공간 계약에 저장됩니다.
+
+로직 계약에는 사용자가 애플리케이션과 상호 작용할 때 실행되는 코드가 포함됩니다. 또한 저장 공간 계약의 주소를 보유하고 이와 상호 작용하여 데이터를 가져오고 설정합니다.
+
+한편, 저장 공간 계약은 사용자 잔액 및 주소와 같은 스마트 계약과 관련된 상태를 보유합니다. 저장 공간 계약은 로직 계약이 소유하며 배포 시 로직 계약의 주소로 구성됩니다. 이를 통해 승인되지 않은 계약이 저장 공간 계약을 호출하거나 데이터를 업데이트하는 것을 방지할 수 있습니다.
+
+기본적으로 저장 공간 계약은 불변이지만, 가리키는 로직 계약을 새로운 구현으로 교체할 수 있습니다. 이렇게 하면 EVM에서 실행되는 코드가 변경되지만 저장 공간과 잔액은 그대로 유지됩니다.
+
+이 업그레이드 방법을 사용하려면 저장 공간 계약에서 로직 계약의 주소를 업데이트해야 합니다. 앞서 설명한 이유로 새 로직 계약을 저장 공간 계약의 주소로 구성해야 합니다.
+
+데이터 분리 패턴은 계약 마이그레이션에 비해 구현하기가 더 쉽다고 할 수 있습니다. 하지만 여러 계약을 관리하고 악의적인 업그레이드로부터 스마트 계약을 보호하기 위해 복잡한 권한 부여 체계를 구현해야 합니다.
+
+### 업그레이드 메커니즘 #3: 프록시 패턴 {#proxy-patterns}
+
+프록시 패턴은 또한 데이터 분리를 사용하여 비즈니스 로직과 데이터를 별도의 계약에 보관합니다. 그러나 프록시 패턴에서는 저장 공간 계약(프록시라고 함)이 코드 실행 중에 로직 계약을 호출합니다. 이것은 로직 계약이 저장 공간 계약을 호출하는 데이터 분리 방법의 반대입니다.
+
+프록시 패턴에서 일어나는 일은 다음과 같습니다.
+
+1. 사용자는 데이터를 저장하지만 비즈니스 로직은 보유하지 않는 프록시 계약과 상호 작용합니다.
+
+2. 프록시 계약은 로직 계약의 주소를 저장하고 `delegatecall` 함수를 사용하여 모든 함수 호출을 로직 계약(비즈니스 로직을 보유함)에 위임합니다.
+
+3. 호출이 로직 계약으로 전달된 후, 로직 계약에서 반환된 데이터는 검색되어 사용자에게 반환됩니다.
+
+프록시 패턴을 사용하려면 **delegatecall** 함수에 대한 이해가 필요합니다. 기본적으로 `delegatecall`은 계약이 다른 계약을 호출할 수 있도록 하는 옵코드이며, 실제 코드 실행은 호출하는 계약의 컨텍스트에서 발생합니다. 프록시 패턴에서 `delegatecall`을 사용하는 것의 한 가지 의미는 프록시 계약이 내부 함수를 호출하는 것처럼 저장 공간을 읽고 쓰며 로직 계약에 저장된 로직을 실행한다는 것입니다.
+
+[Solidity 개발문서](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries)에서:
+
+> _**delegatecall**이라는 특별한 메시지 호출 변형이 존재합니다. 이는 대상 주소의 코드가 호출 계약의 컨텍스트(즉, 주소)에서 실행되고 `msg.sender`와 `msg.value`의 값이 변경되지 않는다는 점을 제외하면 메시지 호출과 동일합니다._ _이는 계약이 런타임에 다른 주소에서 코드를 동적으로 로드할 수 있음을 의미합니다. 저장 공간, 현재 주소 및 잔액은 여전히 호출 계약을 참조하며, 코드는 호출된 주소에서만 가져옵니다._
+
+프록시 계약은 내장된 `fallback` 함수가 있기 때문에 사용자가 함수를 호출할 때마다 `delegatecall`을 호출해야 한다는 것을 알고 있습니다. Solidity 프로그래밍에서 [폴백 함수](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function)는 함수 호출이 계약에 지정된 함수와 일치하지 않을 때 실행됩니다.
+
+프록시 패턴이 작동하려면 프록시 계약이 지원하지 않는 함수 호출을 처리하는 방법을 지정하는 사용자 지정 폴백 함수를 작성해야 합니다. 이 경우 프록시의 폴백 함수는 delegatecall을 시작하고 사용자의 요청을 현재 로직 계약 구현으로 다시 라우팅하도록 프로그래밍됩니다.
+
+프록시 계약은 기본적으로 불변이지만, 업데이트된 비즈니스 로직을 가진 새로운 로직 계약을 만들 수 있습니다. 그런 다음 업그레이드를 수행하는 것은 프록시 계약에서 참조되는 로직 계약의 주소를 변경하는 문제입니다.
+
+프록시 계약이 새로운 로직 계약을 가리키도록 함으로써 사용자가 프록시 계약 함수를 호출할 때 실행되는 코드가 변경됩니다. 이를 통해 사용자에게 새로운 계약과 상호 작용하도록 요청하지 않고도 계약의 로직을 업그레이드할 수 있습니다.
+
+프록시 패턴은 계약 마이그레이션과 관련된 어려움을 없애주기 때문에 스마트 계약을 업그레이드하는 데 널리 사용되는 방법입니다. 그러나 프록시 패턴은 사용하기가 더 복잡하며 부적절하게 사용될 경우 [함수 선택자 충돌](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357)과 같은 치명적인 결함을 유발할 수 있습니다.
+
+[프록시 패턴에 대해 더 알아보기.](https://blog.openzeppelin.com/proxy-patterns/)
+
+### 업그레이드 메커니즘 #4: 전략 패턴 {#strategy-pattern}
+
+이 기술은 특정 기능을 구현하기 위해 다른 프로그램과 인터페이스하는 소프트웨어 프로그램을 만들도록 장려하는 [전략 패턴](https://en.wikipedia.org/wiki/Strategy_pattern)의 영향을 받았습니다. 전략 패턴을 이더리움 개발에 적용하는 것은 다른 계약의 함수를 호출하는 스마트 계약을 구축하는 것을 의미합니다.
+
+이 경우 메인 계약에는 핵심 비즈니스 로직이 포함되어 있지만, 특정 함수를 실행하기 위해 다른 스마트 계약("위성 계약")과 인터페이스합니다. 이 메인 계약은 각 위성 계약의 주소를 저장하고 위성 계약의 다른 구현 간에 전환할 수 있습니다.
+
+새로운 위성 계약을 구축하고 메인 계약을 새 주소로 구성할 수 있습니다. 이를 통해 스마트 계약의 전략을 변경(즉, 새로운 로직 구현)할 수 있습니다.
+
+앞서 논의한 프록시 패턴과 유사하지만, 전략 패턴은 사용자가 상호 작용하는 메인 계약이 비즈니스 로직을 보유하기 때문에 다릅니다. 이 패턴을 사용하면 핵심 인프라에 영향을 주지 않고 스마트 계약에 제한적인 변경을 도입할 수 있습니다.
+
+주요 단점은 이 패턴이 주로 사소한 업그레이드를 배포하는 데 유용하다는 것입니다. 또한, 메인 계약이 손상된 경우(예: 해킹) 이 업그레이드 방법을 사용할 수 없습니다.
+
+### 업그레이드 메커니즘 #5: 다이아몬드 패턴 {#diamond-pattern}
+
+다이아몬드 패턴은 프록시 패턴의 개선된 버전으로 간주될 수 있습니다. 다이아몬드 패턴은 다이아몬드 프록시 계약이 하나 이상의 로직 계약에 함수 호출을 위임할 수 있다는 점에서 프록시 패턴과 다릅니다.
+
+다이아몬드 패턴의 로직 계약은 패싯으로 알려져 있습니다. 다이아몬드 패턴이 작동하려면 프록시 계약에 [함수 선택자](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector)를 다른 패싯 주소에 매핑하는 매핑을 만들어야 합니다.
+
+사용자가 함수를 호출하면 프록시 계약은 매핑을 확인하여 해당 함수 실행을 담당하는 패싯을 찾습니다. 그런 다음 `delegatecall`(폴백 함수 사용)을 호출하고 해당 로직 계약으로 호출을 리디렉션합니다.
+
+다이아몬드 업그레이드 패턴은 기존 프록시 업그레이드 패턴에 비해 몇 가지 장점이 있습니다.
+
+1. 모든 코드를 변경하지 않고도 계약의 작은 부분을 업그레이드할 수 있습니다. 업그레이드를 위해 프록시 패턴을 사용하려면 사소한 업그레이드라도 완전히 새로운 로직 계약을 만들어야 합니다.
+
+2. 모든 스마트 계약(프록시 패턴에서 사용되는 로직 계약 포함)은 24KB 크기 제한이 있으며, 이는 특히 더 많은 기능이 필요한 복잡한 계약의 경우 제한이 될 수 있습니다. 다이아몬드 패턴은 여러 로직 계약에 함수를 분할하여 이 문제를 쉽게 해결할 수 있습니다.
+
+3. 프록시 패턴은 액세스 제어에 대해 포괄적인 접근 방식을 채택합니다. 업그레이드 함수에 접근할 수 있는 엔티티는 _전체_ 계약을 변경할 수 있습니다. 하지만 다이아몬드 패턴은 모듈식 권한 접근 방식을 가능하게 하여, 스마트 계약 내에서 특정 함수를 업그레이드하는 것을 엔티티에 제한할 수 있습니다.
+
+[다이아몬드 패턴에 대해 더 알아보기](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w).
+
+## 스마트 계약 업그레이드의 장단점 {#pros-and-cons-of-upgrading-smart-contracts}
+
+| 장점 | 단점 |
+| --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
+| 스마트 계약 업그레이드를 통해 배포 후 단계에서 발견된 취약점을 더 쉽게 수정할 수 있습니다. | 스마트 계약을 업그레이드하는 것은 코드 불변성이라는 개념에 위배되며, 이는 탈중앙화와 보안에 영향을 미칩니다. |
+| 개발자는 로직 업그레이드를 사용하여 탈중앙화 애플리케이션에 새로운 기능을 추가할 수 있습니다. | 사용자는 개발자가 스마트 계약을 임의로 수정하지 않을 것이라고 신뢰해야 합니다. |
+| 스마트 계약 업그레이드는 버그를 신속하게 수정할 수 있으므로 최종 사용자의 안전을 향상시킬 수 있습니다. | 스마트 계약에 업그레이드 기능을 프로그래밍하는 것은 또 다른 복잡성을 더하고 치명적인 결함의 가능성을 높입니다. |
+| 계약 업그레이드는 개발자에게 다양한 기능을 실험하고 시간이 지남에 따라 탈중앙화앱을 개선할 수 있는 더 많은 여지를 제공합니다. | 스마트 계약을 업그레이드할 수 있는 기회는 개발자가 개발 단계에서 실사를 수행하지 않고 프로젝트를 더 빨리 출시하도록 장려할 수 있습니다. |
+| | 스마트 계약의 안전하지 않은 접근 제어 또는 중앙 집중화는 악의적인 행위자가 무단 업그레이드를 수행하기 쉽게 만들 수 있습니다. |
+
+## 스마트 계약 업그레이드 시 고려 사항 {#considerations-for-upgrading-smart-contracts}
+
+1. 특히 프록시 패턴, 전략 패턴 또는 데이터 분리를 사용하는 경우 무단 스마트 계약 업그레이드를 방지하기 위해 안전한 접근 제어/권한 부여 메커니즘을 사용하세요. 예를 들어, 계약의 소유자만 호출할 수 있도록 업그레이드 기능에 대한 접근을 제한하는 것입니다.
+
+2. 스마트 계약 업그레이드는 복잡한 활동이며 취약점 도입을 방지하기 위해 높은 수준의 주의가 필요합니다.
+
+3. 업그레이드 구현 프로세스를 탈중앙화하여 신뢰 가정을 줄이세요. [다중 서명 지갑 계약](/developers/docs/smart-contracts/#multisig)을 사용하여 업그레이드를 제어하거나 [DAO 구성원](/dao/)이 업그레이드 승인에 투표하도록 요구하는 전략이 포함될 수 있습니다.
+
+4. 계약 업그레이드에 수반되는 비용을 인지하세요. 예를 들어, 계약 마이그레이션 중에 이전 계약에서 새 계약으로 상태(예: 사용자 잔액)를 복사하는 데 두 개 이상의 트랜잭션이 필요할 수 있으며, 이는 더 많은 가스 수수료를 의미합니다.
+
+5. 사용자를 보호하기 위해 **타임락** 구현을 고려하세요. 타임락은 시스템 변경에 적용되는 지연을 의미합니다. 타임락은 다중 서명 거버넌스 시스템과 결합하여 업그레이드를 제어할 수 있습니다. 제안된 조치가 필요한 승인 임계값에 도달하면 사전 정의된 지연 기간이 경과할 때까지 실행되지 않습니다.
+
+타임락은 사용자가 제안된 변경(예: 로직 업그레이드 또는 새로운 수수료 체계)에 동의하지 않을 경우 시스템을 종료할 시간을 줍니다. 타임락이 없으면 사용자는 개발자가 사전 통지 없이 스마트 계약에 임의의 변경을 구현하지 않을 것이라고 신뢰해야 합니다. 여기서 단점은 타임락이 취약점을 신속하게 패치하는 능력을 제한한다는 것입니다.
+
+## 참고 자료 {#resources}
+
+**OpenZeppelin 업그레이드 플러그인 - _업그레이드 가능한 스마트 계약을 배포하고 보안을 유지하기 위한 도구 모음._**
+
+- [GitHub](https://github.com/OpenZeppelin/openzeppelin-upgrades)
+- [개발문서](https://docs.openzeppelin.com/upgrades)
+
+## 튜토리얼 {#tutorials}
+
+- [스마트 계약 업그레이드하기 | 유튜브 튜토리얼](https://www.youtube.com/watch?v=bdXJmWajZRY) - Patrick Collins
+- [이더리움 스마트 계약 마이그레이션 튜토리얼](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) - Austin Griffith
+- [UUPS 프록시 패턴을 사용한 스마트 계약 업그레이드](https://blog.logrocket.com/author/praneshas/) - Pranesh A.S
+- [Web3 튜토리얼: OpenZeppelin을 사용하여 업그레이드 가능한 스마트 계약(프록시) 작성하기](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) - fangjun.eth
+
+## 더 읽어보기 {#further-reading}
+
+- [스마트 계약 업그레이드의 현황](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) - Santiago Palladino
+- [Solidity 스마트 계약을 업그레이드하는 여러 방법](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - Crypto Market Pool 블로그
+- [학습: 스마트 계약 업그레이드](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - OpenZeppelin 개발문서
+- [Solidity 계약의 업그레이드 가능성을 위한 프록시 패턴: 투명 프록시 vs UUPS 프록시](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) - Naveen Sahu
+- [다이아몬드 업그레이드 작동 방식](https://dev.to/mudgen/how-diamond-upgrades-work-417j) - Nick Mudge
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/ko/developers/docs/smart-contracts/verifying/index.md
new file mode 100644
index 00000000000..e51bc39c8aa
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/verifying/index.md
@@ -0,0 +1,113 @@
+---
+title: "스마트 계약 인증"
+description: "이더리움 스마트 계약의 소스 코드 검증 개요"
+lang: ko
+---
+
+[스마트 계약](/developers/docs/smart-contracts/)은 '무신뢰성(trustless)'을 갖도록 설계되었습니다. 즉, 사용자가 계약과 상호 작용하기 전에 제3자(예: 개발자 및 회사)를 신뢰할 필요가 없다는 것을 의미합니다. 무신뢰성을 위한 전제 조건으로, 사용자와 다른 개발자는 스마트 계약의 소스 코드를 검증할 수 있어야 합니다. 소스 코드 검증은 게시된 계약 코드가 이더리움 블록체인의 계약 주소에서 실행되는 코드와 동일하다는 것을 사용자와 개발자에게 보장합니다.
+
+"소스 코드 검증"과 "[정형 검증](/developers/docs/smart-contracts/formal-verification/)"을 구별하는 것이 중요합니다. 아래에서 자세히 설명하겠지만 소스 코드 검증은 고급 언어(예: Solidity)로 작성된 스마트 계약의 주어진 소스 코드가 계약 주소에서 실행될 바이트코드와 동일하게 컴파일되는지 검증하는 것을 말합니다. 하지만 정형 검증은 스마트 계약의 정확성을 검증하는 것을 의미하며, 이는 계약이 예상대로 작동하는 것을 의미합니다. 문맥에 따라 다르지만, 계약 검증은 일반적으로 소스 코드 검증을 의미합니다.
+
+## 소스 코드 검증이란 무엇인가요? {#what-is-source-code-verification}
+
+[이더리움 가상 머신(EVM)](/developers/docs/evm/)에 스마트 계약을 배포하기 전에 개발자들은 계약의 소스 코드, 즉 [솔리디티](/developers/docs/smart-contracts/languages/) 또는 다른 고급 프로그래밍 언어로 작성된 지침을 바이트코드로 [컴파일](/developers/docs/smart-contracts/compiling/)합니다. EVM은 고급 지침을 해석할 수 없으므로, 소스 코드를 바이트코드(즉, 저수준 기계 명령어)로 컴파일하는 것은 EVM에서 계약 로직을 실행하는 데 필요합니다.
+
+소스 코드 검증은 스마트 계약의 소스 코드와 계약 생성 중에 사용된 컴파일된 바이트코드를 비교하여 차이점을 감지하는 것입니다. 스마트 계약을 검증하는 것이 중요한 이유는 광고된 계약 코드가 블록체인에서 실행되는 것과 다를 수 있기 때문입니다.
+
+스마트 계약 검증을 통해 기계 코드를 읽을 필요 없이 계약이 작성된 고급 언어를 통해 계약이 수행하는 작업을 조사할 수 있습니다. 함수, 값, 그리고 일반적으로 변수 이름과 주석은 컴파일 및 배포된 원본 소스 코드와 동일하게 유지됩니다. 이를 통해 코드를 훨씬 쉽게 읽을 수 있습니다. 소스 검증은 또한 최종 사용자가 스마트 계약이 무엇을 하도록 설계되었는지 알 수 있도록 코드 문서화를 제공합니다.
+
+### 전체 검증이란 무엇인가요? {#full-verification}
+
+소스 코드에는 주석이나 변수 이름과 같이 컴파일된 바이트코드에 영향을 주지 않는 일부 부분이 있습니다. 이는 서로 다른 변수 이름과 다른 주석을 가진 두 개의 소스 코드가 모두 동일한 계약을 검증할 수 있다는 것을 의미합니다. 이로 인해 악의적인 행위자가 소스 코드 내에 기만적인 주석을 추가하거나 오해의 소지가 있는 변수 이름을 부여하고 원본 소스 코드와 다른 소스 코드로 계약을 검증받을 수 있습니다.
+
+소스 코드의 정확성에 대한 암호화 보증과 컴파일 정보의 _지문_ 역할을 하도록 바이트코드에 추가 데이터를 추가하여 이를 방지할 수 있습니다. 필요한 정보는 [솔리디티의 계약 메타데이터](https://docs.soliditylang.org/en/v0.8.15/metadata.html)에 있으며, 이 파일의 해시는 계약의 바이트코드에 추가됩니다. [메타데이터 플레이그라운드](https://playground.sourcify.dev)에서 작동하는 것을 볼 수 있습니다.
+
+메타데이터 파일에는 소스 파일과 그 해시를 포함하여 계약의 컴파일에 대한 정보가 포함되어 있습니다. 즉, 컴파일 설정이나 소스 파일 중 하나의 바이트라도 변경되면 메타데이터 파일이 변경됩니다. 결과적으로 바이트코드에 추가되는 메타데이터 파일의 해시도 변경됩니다. 즉, 계약의 바이트코드 + 추가된 메타데이터 해시가 주어진 소스 코드 및 컴파일 설정과 일치하면, 이것이 원본 컴파일에 사용된 소스 코드와 정확히 동일하며 단 한 바이트도 다르지 않다는 것을 확신할 수 있습니다.
+
+메타데이터 해시를 활용하는 이러한 유형의 검증은 **"[전체 검증](https://docs.sourcify.dev/docs/full-vs-partial-match/)"**(또는 "완벽한 검증")이라고 합니다. 메타데이터 해시가 일치하지 않거나 검증에서 고려되지 않으면 "부분 일치"가 되며, 이는 현재 계약을 검증하는 더 일반적인 방법입니다. 전체 검증 없이는 검증된 소스 코드에 반영되지 않는 [악성 코드](https://samczsun.com/hiding-in-plain-sight/)를 삽입하는 것이 가능합니다. 대부분의 개발자는 전체 검증을 인지하지 못하고 컴파일의 메타데이터 파일을 보관하지 않으므로, 지금까지 부분 검증이 계약을 검증하는 사실상의 방법이었습니다.
+
+## 소스 코드 검증이 왜 중요한가요? {#importance-of-source-code-verification}
+
+### 무신뢰성 {#trustlessness}
+
+무신뢰성은 스마트 계약과 [탈중앙화 애플리케이션(탈중앙화앱)](/developers/docs/dapps/)의 가장 큰 전제라고 할 수 있습니다. 스마트 계약은 “불변”이며 변경할 수 없습니다. 계약은 배포 시점에 코드에 정의된 비즈니스 로직만 실행합니다. 이는 개발자와 기업이 이더리움에 배포한 후 계약 코드를 변조할 수 없음을 의미합니다.
+
+스마트 계약이 무신뢰성을 가지려면 계약 코드를 독립적으로 검증할 수 있어야 합니다. 모든 스마트 계약의 컴파일된 바이트코드는 블록체인에 공개적으로 사용할 수 있지만, 저수준 언어는 개발자와 사용자 모두에게 이해하기 어렵습니다.
+
+프로젝트는 계약의 소스 코드를 게시하여 신뢰 가정을 줄입니다. 하지만 이는 또 다른 문제로 이어집니다. 게시된 소스 코드가 계약 바이트코드와 일치하는지 확인하기 어렵다는 것입니다. 이 시나리오에서는 사용자가 개발자가 블록체인에 배포하기 전에 계약의 비즈니스 로직(즉, 바이트코드를 변경)을 변경하지 않을 것이라고 신뢰해야 하므로 무신뢰성의 가치가 상실됩니다.
+
+소스 코드 검증 도구는 스마트 계약의 소스 코드 파일이 어셈블리 코드와 일치함을 보장합니다. 그 결과 사용자가 제3자를 맹목적으로 신뢰하지 않고 계약에 자금을 예치하기 전에 코드를 검증하는 무신뢰 생태계가 만들어집니다.
+
+### 사용자 안전 {#user-safety}
+
+스마트 계약에는 일반적으로 많은 돈이 걸려 있습니다. 따라서 스마트 계약을 사용하기 전에 더 높은 보안 보장과 로직 검증이 필요합니다. 문제는 비양심적인 개발자가 스마트 계약에 악성 코드를 삽입하여 사용자를 속일 수 있다는 것입니다. 검증 없이는 악성 스마트 계약에 [백도어](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts), 논란의 여지가 있는 접근 제어 메커니즘, 악용 가능한 취약점 및 감지되지 않은 채 사용자 안전을 위협하는 기타 사항들이 있을 수 있습니다.
+
+스마트 계약의 소스 코드 파일을 게시하면 감사자와 같은 이해관계자들이 잠재적인 공격 벡터에 대해 계약을 평가하기가 더 쉬워집니다. 여러 당사자가 독립적으로 스마트 계약을 검증함으로써 사용자는 보안에 대한 더 강력한 보증을 받게 됩니다.
+
+## 이더리움 스마트 계약의 소스 코드를 검증하는 방법 {#source-code-verification-for-ethereum-smart-contracts}
+
+[이더리움에 스마트 계약 배포](/developers/docs/smart-contracts/deploying/)는 데이터 페이로드(컴파일된 바이트코드)가 포함된 트랜잭션을 특수 주소로 보내야 합니다. 데이터 페이로드는 소스 코드를 컴파일하여 생성되며, 여기에 트랜잭션의 데이터 페이로드에 추가된 계약 인스턴스의 [생성자 인수](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor)가 더해집니다. 컴파일은 결정론적입니다. 즉, 동일한 소스 파일과 컴파일 설정(예: 컴파일러 버전, 최적화 프로그램)이 사용되는 경우 항상 동일한 출력(즉, 계약 바이트코드)을 생성합니다.
+
+
+
+스마트 계약을 검증하는 것은 기본적으로 다음 단계를 포함합니다:
+
+1. 컴파일러에 소스 파일과 컴파일 설정을 입력합니다.
+
+2. 컴파일러는 계약의 바이트코드를 출력합니다.
+
+3. 지정된 주소에서 배포된 계약의 바이트코드를 가져옵니다.
+
+4. 배포된 바이트코드를 다시 컴파일된 바이트코드와 비교합니다. 코드가 일치하면 계약은 주어진 소스 코드와 컴파일 설정으로 검증됩니다.
+
+5. 추가로, 바이트코드 끝에 있는 메타데이터 해시가 일치하면 전체 일치가 됩니다.
+
+이는 검증에 대한 단순한 설명이며, [불변 변수](https://docs.sourcify.dev/docs/immutables/)를 갖는 것과 같이 이 방법으로 작동하지 않는 많은 예외가 있다는 점에 유의하세요.
+
+## 소스 코드 검증 도구 {#source-code-verification-tools}
+
+계약을 검증하는 전통적인 프로세스는 복잡할 수 있습니다. 이것이 이더리움에 배포된 스마트 계약의 소스 코드를 검증하기 위한 도구가 있는 이유입니다. 이러한 도구는 소스 코드 검증의 많은 부분을 자동화하고 사용자의 이익을 위해 검증된 계약을 큐레이션합니다.
+
+### Etherscan {#etherscan}
+
+주로 [이더리움 블록체인 탐색기](/developers/docs/data-and-analytics/block-explorers/)로 알려져 있지만, Etherscan은 스마트 계약 개발자와 사용자를 위한 [소스 코드 검증 서비스](https://etherscan.io/verifyContract)도 제공합니다.
+
+Etherscan을 사용하면 원본 데이터 페이로드(소스 코드, 라이브러리 주소, 컴파일러 설정, 계약 주소 등)에서 계약 바이트코드를 다시 컴파일할 수 있습니다. 다시 컴파일된 바이트코드가 온체인 계약의 바이트코드(및 생성자 매개변수)와 연결되면 [계약이 검증됩니다](https://info.etherscan.com/types-of-contract-verification/).
+
+검증이 완료되면 계약의 소스 코드는 "검증됨" 라벨을 받고 다른 사람들이 감사할 수 있도록 Etherscan에 게시됩니다. 또한 검증된 소스 코드가 있는 스마트 계약의 저장소인 [검증된 계약](https://etherscan.io/contractsVerified/) 섹션에도 추가됩니다.
+
+Etherscan은 계약을 검증하는 데 가장 많이 사용되는 도구입니다. 그러나 Etherscan의 계약 검증에는 단점이 있습니다. 온체인 바이트코드와 재컴파일된 바이트코드의 메타데이터 해시를 비교하지 못합니다. 따라서 Etherscan에서의 일치는 부분 일치입니다.
+
+[Etherscan에서 계약 검증에 대해 더 알아보기](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327).
+
+### Blockscout {#blockscout}
+
+[Blockscout](https://blockscout.com/)은 오픈소스 블록체인 탐색기로 스마트 계약 개발자와 사용자를 위한 [계약 검증 서비스](https://eth.blockscout.com/contract-verification)도 제공합니다. 오픈 소스 대안으로서 Blockscout은 검증이 수행되는 방식의 투명성을 제공하고 커뮤니티가 검증 프로세스를 개선하는 데 기여할 수 있도록 합니다.
+
+다른 검증 서비스와 마찬가지로 Blockscout을 사용하면 바이트코드를 다시 컴파일하고 배포된 계약과 비교하여 계약의 소스 코드를 검증할 수 있습니다. 검증이 완료되면 계약은 검증 상태를 받게 되며 소스 코드는 감사 및 상호 작용을 위해 공개적으로 사용할 수 있게 됩니다. 검증된 계약은 쉽게 찾아보고 발견할 수 있도록 Blockscout의 [검증된 계약 저장소](https://eth.blockscout.com/verified-contracts)에도 나열됩니다.
+
+### Sourcify {#sourcify}
+
+[Sourcify](https://sourcify.dev/#/verifier)는 오픈 소스이고 분산된 또 다른 계약 검증 도구입니다. 이것은 블록 탐색기가 아니며 [다양한 EVM 기반 네트워크](https://docs.sourcify.dev/docs/chains)에서 계약만 검증합니다. 이는 다른 도구가 그 위에 구축할 수 있는 공용 인프라 역할을 하며, 메타데이터 파일에 있는 [ABI](/developers/docs/smart-contracts/compiling/#web-applications) 및 [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) 주석을 사용하여 보다 인간 친화적인 계약 상호 작용을 가능하게 하는 것을 목표로 합니다.
+
+Etherscan과 달리 Sourcify는 메타데이터 해시와의 전체 일치를 지원합니다. 검증된 계약은 HTTP 및 분산된 [콘텐츠 주소 지정](https://docs.storacha.network/concepts/content-addressing/) 스토리지인 [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs)의 [공개 리포지토리](https://docs.sourcify.dev/docs/repository/)에서 제공됩니다. 추가된 메타데이터 해시가 IPFS 해시이므로 이를 통해 IPFS를 통해 계약의 메타데이터 파일을 가져올 수 있습니다.
+
+또한 이 파일들의 IPFS 해시도 메타데이터에서 찾을 수 있으므로 IPFS를 통해 소스 코드 파일을 검색할 수도 있습니다. API 또는 [UI](https://sourcify.dev/#/verifier)를 통해 메타데이터 파일과 소스 파일을 제공하거나 플러그인을 사용하여 계약을 확인할 수 있습니다. Sourcify 모니터링 도구는 또한 새 블록에서 계약 생성을 수신하고 메타데이터 및 소스 파일이 IPFS에 게시된 경우 계약을 확인하려고 시도합니다.
+
+[Sourcify에서 계약 검증에 대해 더 알아보기](https://soliditylang.org/blog/2020/06/25/sourcify-faq/).
+
+### Tenderly {#tenderly}
+
+[Tenderly 플랫폼](https://tenderly.co/)은 웹3 개발자가 스마트 계약을 구축, 테스트, 모니터링 및 운영할 수 있도록 합니다. 디버깅 도구와 관찰 가능성 및 인프라 구성 요소를 결합하여 Tenderly는 개발자가 스마트 계약 개발을 가속화하도록 돕습니다. Tenderly 기능을 완전히 활성화하려면 개발자는 여러 방법을 사용하여 [소스 코드 검증을 수행](https://docs.tenderly.co/monitoring/contract-verification)해야 합니다.
+
+계약을 비공개 또는 공개적으로 확인할 수 있습니다. 비공개로 확인된 경우 스마트 계약은 귀하(및 프로젝트의 다른 구성원)에게만 표시됩니다. 계약을 공개적으로 확인하면 Tenderly 플랫폼을 사용하는 모든 사람이 볼 수 있습니다.
+
+[대시보드](https://docs.tenderly.co/contract-verification), [Tenderly Hardhat 플러그인](https://docs.tenderly.co/contract-verification/hardhat) 또는 [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli)를 사용하여 계약을 확인할 수 있습니다.
+
+대시보드를 통해 계약을 확인할 때 Solidity 컴파일러에서 생성된 소스 파일 또는 메타데이터 파일, 주소/네트워크 및 컴파일러 설정을 가져와야 합니다.
+
+Tenderly Hardhat 플러그인을 사용하면 더 적은 노력으로 검증 프로세스를 더 많이 제어할 수 있으므로 자동(코드 없음) 및 수동(코드 기반) 검증 중에서 선택할 수 있습니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [계약 소스 코드 검증](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/)
diff --git a/public/content/translations/ko/developers/docs/standards/index.md b/public/content/translations/ko/developers/docs/standards/index.md
new file mode 100644
index 00000000000..2067fd392a2
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/index.md
@@ -0,0 +1,59 @@
+---
+title: "이더리움 개발 표준"
+description: "EIP, ERC-20, ERC-721과 같은 토큰 표준, 개발 컨벤션을 포함한 이더리움 표준에 대해 알아보세요."
+lang: ko
+incomplete: true
+---
+
+## 표준 개요 {#standards-overview}
+
+이더리움 커뮤니티는 [이더리움 클라이언트](/developers/docs/nodes-and-clients/) 및 지갑과 같은 프로젝트가 여러 구현에서 상호 운용성을 유지하고 스마트 계약과 탈중앙화앱이 구성 가능하도록 유지하는 데 도움이 되는 많은 표준을 채택했습니다.
+
+일반적으로 표준은 [이더리움 개선 제안](/eips/)(EIP)으로 도입되며, 이는 [표준 절차](https://eips.ethereum.org/EIPS/eip-1)를 통해 커뮤니티 구성원들이 논의합니다.
+
+- [EIP 소개](/eips/)
+- [EIP 목록](https://eips.ethereum.org/)
+- [EIP GitHub 리포지토리](https://github.com/ethereum/EIPs)
+- [EIP 토론 게시판](https://ethereum-magicians.org/c/eips)
+- [이더리움 거버넌스 소개](/governance/)
+- [이더리움 거버넌스 개요](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _2019년 3월 31일 - Boris Mann_
+- [이더리움 프로토콜 개발 거버넌스 및 네트워크 업그레이드 조정](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _2020년 3월 23일 - Hudson Jameson_
+- [모든 이더리움 코어 개발자 회의 재생목록](https://www.youtube.com/@EthereumProtocol) _(YouTube 재생목록)_
+
+## 표준의 유형 {#types-of-standards}
+
+EIP에는 3가지 유형이 있습니다:
+
+- 표준 트랙: 대부분 또는 모든 이더리움 구현에 영향을 미치는 변경 사항을 설명합니다
+- [메타 트랙](https://eips.ethereum.org/meta): 이더리움 관련 프로세스를 설명하거나 프로세스 변경을 제안합니다
+- [정보 트랙](https://eips.ethereum.org/informational): 이더리움 설계 문제를 설명하거나 이더리움 커뮤니티에 일반적인 가이드라인이나 정보를 제공합니다
+
+또한 표준 트랙은 4가지 카테고리로 세분화됩니다:
+
+- [코어](https://eips.ethereum.org/core): 합의 포크가 필요한 개선 사항
+- [네트워킹](https://eips.ethereum.org/networking): devp2p 및 라이트 이더리움 하위 프로토콜 관련 개선 사항, 그리고 위스퍼 및 스웜의 네트워크 프로토콜 사양에 대한 제안된 개선 사항.
+- [인터페이스](https://eips.ethereum.org/interface): 클라이언트 API/RPC 사양 및 표준 관련 개선 사항, 그리고 메서드 이름 및 계약 ABI와 같은 특정 언어 수준 표준.
+- [ERC](https://eips.ethereum.org/erc): 애플리케이션 수준의 표준 및 관례
+
+이러한 다양한 유형 및 카테고리에 대한 자세한 정보는 [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types)에서 확인할 수 있습니다
+
+### 토큰 표준 {#token-standards}
+
+- [ERC-20](/developers/docs/standards/tokens/erc-20/) - 투표 토큰, 스테이킹 토큰 또는 가상 화폐와 같은 대체 가능한(상호 교환 가능한) 토큰을 위한 표준 인터페이스입니다.
+ - [ERC-223](/developers/docs/standards/tokens/erc-223/) - 토큰이 이더와 동일하게 작동하도록 하고 수신자 측에서 토큰 전송 처리를 지원하는 대체 가능한 토큰 표준입니다.
+ - [ERC-1363](/developers/docs/standards/tokens/erc-1363/) - 단일 트랜잭션에서 수신자 계약에 대한 콜백 실행을 지원하는 ERC-20 토큰의 확장 인터페이스입니다.
+- [ERC-721](/developers/docs/standards/tokens/erc-721/) - 예술품이나 노래의 증서와 같은 대체 불가능한 토큰을 위한 표준 인터페이스입니다.
+ - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - 연속적인 토큰 식별자를 사용하여 하나 또는 여러 개의 대체 불가능한 토큰을 생성/전송할 때 방출되는 표준화된 이벤트입니다.
+ - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - EIP-721 소비자 역할을 위한 인터페이스 확장입니다.
+ - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - ERC-721 토큰에 제한된 권한을 가진 시간 제한 역할을 추가합니다.
+- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **(권장되지 않음)** ERC-20을 개선한 토큰 표준입니다.
+- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - 대체 가능한 자산과 대체 불가능한 자산을 모두 포함할 수 있는 토큰 표준입니다.
+- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - 수익률 생성 볼트의 기술적 파라미터를 최적화하고 통합하도록 설계된 토큰화된 볼트 표준입니다.
+
+[토큰 표준](/developers/docs/standards/tokens/)에 대해 더 자세히 알아보세요.
+
+## 더 읽어보기 {#further-reading}
+
+- [이더리움 개선 제안(EIP)](/eips/)
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-1155/index.md
new file mode 100644
index 00000000000..4c6f68f331f
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-1155/index.md
@@ -0,0 +1,146 @@
+---
+title: "ERC-1155 멀티 토큰 표준"
+description: "단일 계약에서 대체 가능 토큰과 대체 불가 토큰을 결합하는 멀티 토큰 표준인 ERC-1155에 대해 알아보세요."
+lang: ko
+---
+
+## 소개 {#introduction}
+
+여러 토큰 유형을 관리하는 계약을 위한 표준 인터페이스입니다. 배포된 단일 계약은 대체 가능 토큰, 대체 불가 토큰 또는 기타 구성(예: 준대체 가능 토큰)의 모든 조합을 포함할 수 있습니다.
+
+**멀티 토큰 표준이란 무엇인가요?**
+
+이 아이디어는 간단하며, 모든 수의 대체 가능 토큰 유형과 대체 불가 토큰 유형을 나타내고 제어할 수 있는 스마트 계약 인터페이스를 만드는 것을 목표로 합니다. 이러한 방식으로 ERC-1155 토큰은 [ERC-20](/developers/docs/standards/tokens/erc-20/) 및 [ERC-721](/developers/docs/standards/tokens/erc-721/) 토큰과 동일한 기능을 수행할 수 있으며, 심지어 동시에 두 가지 기능 모두를 수행할 수도 있습니다. ERC-20 및 ERC-721 표준의 기능을 모두 개선하여 더 효율적이고 명백한 구현 오류를 수정합니다.
+
+ERC-1155 토큰은 [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155)에 자세히 설명되어 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 [토큰 표준](/developers/docs/standards/tokens/), [ERC-20](/developers/docs/standards/tokens/erc-20/), [ERC-721](/developers/docs/standards/tokens/erc-721/)에 대해 읽어보시는 것을 권장합니다.
+
+## ERC-1155의 기능과 특징: {#body}
+
+- [일괄 전송](#batch_transfers): 단일 호출로 여러 자산을 전송합니다.
+- [일괄 잔액 조회](#batch_balance): 단일 호출로 여러 자산의 잔액을 조회합니다.
+- [일괄 승인](#batch_approval): 주소에 모든 토큰을 승인합니다.
+- [훅](#receive_hook): 토큰 수신 훅입니다.
+- [NFT 지원](#nft_support): 공급량이 1인 경우 NFT로 취급합니다.
+- [안전 전송 규칙](#safe_transfer_rule): 안전한 전송을 위한 규칙 집합입니다.
+
+### 일괄 전송 {#batch-transfers}
+
+일괄 전송은 일반적인 ERC-20 전송과 매우 유사하게 작동합니다. 일반적인 ERC-20의 `transferFrom` 함수를 살펴보겠습니다.
+
+```solidity
+// ERC-20
+function transferFrom(address from, address to, uint256 value) external returns (bool);
+
+// ERC-1155
+function safeBatchTransferFrom(
+ address _from,
+ address _to,
+ uint256[] calldata _ids,
+ uint256[] calldata _values,
+ bytes calldata _data
+) external;
+```
+
+ERC-1155의 유일한 차이점은 값을 배열로 전달하고, ID 배열도 전달한다는 것입니다. 예를 들어, `ids=[3, 6, 13]`과 `values=[100, 200, 5]`가 주어지면 결과적인 전송은 다음과 같습니다.
+
+1. `_from`에서 `_to`로 ID가 3인 토큰 100개를 전송합니다.
+2. `_from`에서 `_to`로 ID가 6인 토큰 200개를 전송합니다.
+3. `_from`에서 `_to`로 ID가 13인 토큰 5개를 전송합니다.
+
+ERC-1155에는 `transfer`는 없고 `transferFrom`만 있습니다. 일반 `transfer`처럼 사용하려면, from 주소를 함수를 호출하는 주소로 설정하기만 하면 됩니다.
+
+### 일괄 잔액 조회 {#batch-balance}
+
+각각의 ERC-20 `balanceOf` 호출에도 마찬가지로 일괄 처리를 지원하는 파트너 함수가 있습니다. 참고로, ERC-20 버전은 다음과 같습니다.
+
+```solidity
+// ERC-20
+function balanceOf(address owner) external view returns (uint256);
+
+// ERC-1155
+function balanceOfBatch(
+ address[] calldata _owners,
+ uint256[] calldata _ids
+) external view returns (uint256[] memory);
+```
+
+잔액 호출의 경우, 단일 호출로 여러 잔액을 훨씬 간단하게 검색할 수 있습니다. 소유자 배열을 전달하고, 이어서 토큰 ID 배열을 전달합니다.
+
+예를 들어 `_ids=[3, 6, 13]`과 `_owners=[0xbeef..., 0x1337..., 0x1111...]`가 주어지면 반환 값은 다음과 같습니다.
+
+```solidity
+[
+ balanceOf(0xbeef...),
+ balanceOf(0x1337...),
+ balanceOf(0x1111...)
+]
+```
+
+### 일괄 승인 {#batch-approval}
+
+```solidity
+// ERC-1155
+function setApprovalForAll(
+ address _operator,
+ bool _approved
+) external;
+
+function isApprovedForAll(
+ address _owner,
+ address _operator
+) external view returns (bool);
+```
+
+승인은 ERC-20과 약간 다릅니다. 특정 금액을 승인하는 대신 `setApprovalForAll`을 통해 운영자를 승인 또는 미승인으로 설정합니다.
+
+현재 상태는 `isApprovedForAll`을 통해 확인할 수 있습니다. 보시다시피, 이것은 전부 아니면 전무 방식의 작업입니다. 승인할 토큰 수나 토큰 클래스를 정의할 수 없습니다.
+
+이것은 단순함을 염두에 두고 의도적으로 설계되었습니다. 하나의 주소에 대해서만 모든 것을 승인할 수 있습니다.
+
+### 수신 훅 {#receive-hook}
+
+```solidity
+function onERC1155BatchReceived(
+ address _operator,
+ address _from,
+ uint256[] calldata _ids,
+ uint256[] calldata _values,
+ bytes calldata _data
+) external returns(bytes4);
+```
+
+[EIP-165](https://eips.ethereum.org/EIPS/eip-165) 지원에 따라, ERC-1155는 스마트 계약에 대해서만 수신 훅을 지원합니다. 훅 함수는 다음과 같이 지정된 미리 정의된 특정 bytes4 값을 반환해야 합니다.
+
+```solidity
+bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))
+```
+
+수신 계약이 이 값을 반환하면, 해당 계약이 전송을 수락하고 ERC-1155 토큰을 처리하는 방법을 알고 있는 것으로 간주됩니다. 더 이상 계약에 토큰이 묶이는 일이 없습니다!
+
+### NFT 지원 {#nft-support}
+
+공급량이 1일 때, 토큰은 본질적으로 대체 불가 토큰(NFT)입니다. 또한 ERC-721의 표준과 마찬가지로, 메타데이터 URL을 정의할 수 있습니다. 클라이언트가 URL을 읽고 수정할 수 있습니다. 자세한 내용은 [여기](https://eips.ethereum.org/EIPS/eip-1155#metadata)를 참조하세요.
+
+### 안전 전송 규칙 {#safe-transfer-rule}
+
+앞선 설명에서 이미 몇 가지 안전 전송 규칙을 다루었습니다. 하지만 가장 중요한 규칙들을 살펴보겠습니다.
+
+1. 호출자는 `_from` 주소의 토큰을 사용할 수 있도록 승인받았거나, 호출자가 `_from`과 같아야 합니다.
+2. 다음과 같은 경우 전송 호출이 되돌려져야 합니다.
+ 1. `_to` 주소가 0인 경우.
+ 2. `_ids`의 길이가 `_values`의 길이와 같지 않은 경우.
+ 3. `_ids`에 있는 토큰 보유자의 잔액 중 어느 하나라도 수신자에게 전송된 `_values`의 해당 금액보다 낮은 경우.
+ 4. 기타 오류가 발생하는 경우.
+
+_참고_: 훅을 포함한 모든 일괄 함수는 일괄 처리 기능이 없는 버전으로도 존재합니다. 단일 자산을 전송하는 것이 여전히 가장 보편적으로 사용되는 방법일 가능성이 높다는 점을 고려할 때, 이는 가스 효율성을 위한 것입니다. 설명을 간단하게 하기 위해 안전 전송 규칙을 포함한 해당 내용들을 생략했습니다. 이름은 동일하며, 'Batch'만 제거하면 됩니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [EIP-1155: 멀티 토큰 표준](https://eips.ethereum.org/EIPS/eip-1155)
+- [ERC-1155: Openzeppelin 문서](https://docs.openzeppelin.com/contracts/5.x/erc1155)
+- [ERC-1155: GitHub 저장소](https://github.com/enjin/erc-1155)
+- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-1363/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-1363/index.md
new file mode 100644
index 00000000000..a939e576656
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-1363/index.md
@@ -0,0 +1,82 @@
+---
+title: "ERC-1363 지불 가능 토큰 표준"
+description: "ERC-1363은 단일 트랜잭션 내에서 전송 후 수신자 계약에서 또는 승인 후 지출자 계약에서 맞춤형 로직 실행을 지원하는 ERC-20 토큰의 확장 인터페이스입니다."
+lang: ko
+---
+
+## 소개 {#introduction}
+
+### ERC-1363은 무엇인가요? {#what-is-erc1363}
+
+ERC-1363은 단일 트랜잭션 내에서 전송 후 수신자 계약에서 또는 승인 후 지출자 계약에서 맞춤형 로직 실행을 지원하는 ERC-20 토큰의 확장 인터페이스입니다.
+
+### ERC-20과의 차이점 {#erc20-differences}
+
+`transfer`, `transferFrom` 및 `approve`와 같은 표준 ERC-20 작업은 별도의 트랜잭션 없이는 수신자 또는 지출자 계약에서 코드 실행을 허용하지 않습니다.
+사용자는 첫 번째 트랜잭션을 실행한 다음 두 번째 트랜잭션을 제출해야 하므로 이는 UI 개발의 복잡성을 가중시키고 채택에 마찰을 일으킵니다.
+또한 가스를 두 번 지불해야 합니다.
+
+ERC-1363을 사용하면 대체 가능 토큰이 더 쉽게 작업을 수행하고 오프체인 리스너 없이 작동할 수 있습니다.
+단일 트랜잭션에서 전송 또는 승인 후 수신자 또는 지출자 계약에 대한 콜백을 수행할 수 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 다음에 대해 읽어보는 것을 권장합니다.
+
+- [토큰 표준](/developers/docs/standards/tokens/)
+- [ERC-20](/developers/docs/standards/tokens/erc-20/)
+
+## 본문 {#body}
+
+ERC-1363은 `transfer`, `transferFrom` 또는 `approve` 이후 ERC-20 토큰이 스마트 계약과 상호 작용할 수 있는 표준 API를 도입합니다.
+
+이 표준은 토큰을 전송하는 기본 기능을 제공하며, 토큰이 다른 온체인 제3자에 의해 사용될 수 있도록 승인한 다음 수신자 또는 지출자 계약에 대한 콜백을 수행할 수 있도록 합니다.
+
+ERC-20 콜백을 수락할 수 있는 스마트 계약의 제안된 용도가 많이 있습니다.
+
+예는 다음과 같습니다.
+
+- **크라우드세일**: 전송된 토큰이 즉시 보상 할당을 트리거합니다.
+- **서비스**: 결제로 한 단계에서 서비스 액세스가 활성화됩니다.
+- **인보이스**: 토큰이 자동으로 인보이스를 정산합니다.
+- **구독**: 연간 요금을 승인하면 첫 달 결제 내에서 구독이 활성화됩니다.
+
+이러한 이유로 원래 \"Payable Token\"이라고 명명되었습니다.
+
+콜백 동작은 유틸리티를 더욱 확장하여 다음과 같은 원활한 상호 작용을 가능하게 합니다.
+
+- **스테이킹**: 전송된 토큰이 스테이킹 계약에서 자동 잠금을 트리거합니다.
+- **투표**: 수신된 토큰이 거버넌스 시스템에 투표를 등록합니다.
+- **스왑**: 토큰 승인으로 한 단계에서 스왑 로직이 활성화됩니다.
+
+ERC-1363 토큰은 전송 또는 승인 수신 후 콜백을 실행해야 하는 모든 경우에 특정 유틸리티에 사용될 수 있습니다.
+ERC-1363은 수신자의 토큰 처리 능력을 확인함으로써 스마트 계약에서 토큰 손실이나 토큰 잠김을 방지하는 데에도 유용합니다.
+
+다른 ERC-20 확장 제안과 달리, ERC-1363은 ERC-20 `transfer` 및 `transferFrom` 메서드를 재정의하지 않고 ERC-20과의 하위 호환성을 유지하면서 구현할 인터페이스 ID를 정의합니다.
+
+[EIP-1363](https://eips.ethereum.org/EIPS/eip-1363)에서:
+
+### 메서드 {#methods}
+
+ERC-1363 표준을 구현하는 스마트 계약은 `ERC1363` 인터페이스의 모든 함수와 `ERC20` 및 `ERC165` 인터페이스를 **반드시** 구현해야 합니다.
+
+```solidity
+pragma solidity ^0.8.0;\n\n/**\n * @title ERC1363\n * @dev 단일 트랜잭션에서 `transfer` 또는 `transferFrom` 후 수신자 계약에서 코드를 실행하거나, `approve` 후 지출자 계약에서 코드를 실행하는 것을 지원하는 ERC-20 토큰의 확장 인터페이스입니다.\n */\ninterface ERC1363 is ERC20, ERC165 {\n /*\n * 참고: 이 인터페이스의 ERC-165 식별자는 0xb0202a11입니다.\n * 0xb0202a11 ===\n * bytes4(keccak256('transferAndCall(address,uint256)')) ^\n * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^\n * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^\n * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^\n * bytes4(keccak256('approveAndCall(address,uint256)')) ^\n * bytes4(keccak256('approveAndCall(address,uint256,bytes)'))\n */\n\n /**\n * @dev 호출자의 계정에서 `to`로 `value` 양의 토큰을 이동시킨 다음\n * `to`에서 `ERC1363Receiver::onTransferReceived`를 호출합니다.\n * @param to 토큰이 전송될 주소입니다.\n * @param value 전송될 토큰의 양입니다.\n * @return 예외를 발생시키지 않는 한 작업이 성공했음을 나타내는 불리언 값입니다.\n */\n function transferAndCall(address to, uint256 value) external returns (bool);\n\n /**\n * @dev 호출자의 계정에서 `to`로 `value` 양의 토큰을 이동시킨 다음\n * `to`에서 `ERC1363Receiver::onTransferReceived`를 호출합니다.\n * @param to 토큰이 전송될 주소입니다.\n * @param value 전송될 토큰의 양입니다.\n * @param data 지정된 형식이 없는 추가 데이터로, `to`를 호출할 때 전송됩니다.\n * @return 예외를 발생시키지 않는 한 작업이 성공했음을 나타내는 불리언 값입니다.\n */\n function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool);\n\n /**\n * @dev 허용량 메커니즘을 사용하여 `from`에서 `to`로 `value` 양의 토큰을 이동시킨 다음\n * `to`에서 `ERC1363Receiver::onTransferReceived`를 호출합니다.\n * @param from 토큰을 보낼 주소입니다.\n * @param to 토큰이 전송될 주소입니다.\n * @param value 전송될 토큰의 양입니다.\n * @return 예외를 발생시키지 않는 한 작업이 성공했음을 나타내는 불리언 값입니다.\n */\n function transferFromAndCall(address from, address to, uint256 value) external returns (bool);\n\n /**\n * @dev 허용량 메커니즘을 사용하여 `from`에서 `to`로 `value` 양의 토큰을 이동시킨 다음\n * `to`에서 `ERC1363Receiver::onTransferReceived`를 호출합니다.\n * @param from 토큰을 보낼 주소입니다.\n * @param to 토큰이 전송될 주소입니다.\n * @param value 전송될 토큰의 양입니다.\n * @param data 지정된 형식이 없는 추가 데이터로, `to`를 호출할 때 전송됩니다.\n * @return 예외를 발생시키지 않는 한 작업이 성공했음을 나타내는 불리언 값입니다.\n */\n function transferFromAndCall(address from, address to, uint256 value, bytes calldata data) external returns (bool);\n\n /**\n * @dev 호출자의 토큰에 대해 `spender`의 허용량으로 `value` 양의 토큰을 설정한 다음\n * `spender`에서 `ERC1363Spender::onApprovalReceived`를 호출합니다.\n * @param spender 자금을 사용할 주소입니다.\n * @param value 사용될 토큰의 양입니다.\n * @return 예외를 발생시키지 않는 한 작업이 성공했음을 나타내는 불리언 값입니다.\n */\n function approveAndCall(address spender, uint256 value) external returns (bool);\n\n /**\n * @dev 호출자의 토큰에 대해 `spender`의 허용량으로 `value` 양의 토큰을 설정한 다음\n * `spender`에서 `ERC1363Spender::onApprovalReceived`를 호출합니다.\n * @param spender 자금을 사용할 주소입니다.\n * @param value 사용될 토큰의 양입니다.\n * @param data 지정된 형식이 없는 추가 데이터로, `spender`를 호출할 때 전송됩니다.\n * @return 예외를 발생시키지 않는 한 작업이 성공했음을 나타내는 불리언 값입니다.\n */\n function approveAndCall(address spender, uint256 value, bytes calldata data) external returns (bool);\n}\n\ninterface ERC20 {\n event Transfer(address indexed from, address indexed to, uint256 value);\n event Approval(address indexed owner, address indexed spender, uint256 value);\n function transfer(address to, uint256 value) external returns (bool);\n function transferFrom(address from, address to, uint256 value) external returns (bool);\n function approve(address spender, uint256 value) external returns (bool);\n function totalSupply() external view returns (uint256);\n function balanceOf(address account) external view returns (uint256);\n function allowance(address owner, address spender) external view returns (uint256);\n}\n\ninterface ERC165 {\n function supportsInterface(bytes4 interfaceId) external view returns (bool);\n}
+```
+
+`transferAndCall` 또는 `transferFromAndCall`을 통해 ERC-1363 토큰을 수락하려는 스마트 계약은 `ERC1363Receiver` 인터페이스를 **반드시** 구현해야 합니다.
+
+```solidity
+/**\n * @title ERC1363Receiver\n * @dev ERC-1363 토큰 계약에서 `transferAndCall` 또는 `transferFromAndCall`을 지원하려는 모든 계약을 위한 인터페이스입니다.\n */\ninterface ERC1363Receiver {\n /**\n * @dev `operator`가 `from`에서 `ERC1363::transferAndCall` 또는 `ERC1363::transferFromAndCall`을 통해\n * ERC-1363 토큰을 이 계약으로 전송할 때마다 이 함수가 호출됩니다.\n *\n * 참고: 전송을 수락하려면 이 함수는\n * `bytes4(keccak256(\"onTransferReceived(address,address,uint256,bytes)\"))`\n * (예: 0x88a7ca5c 또는 자체 함수 선택자)를 반환해야 합니다.\n *\n * @param operator `transferAndCall` 또는 `transferFromAndCall` 함수를 호출한 주소입니다.\n * @param from 토큰이 전송된 주소입니다.\n * @param value 전송된 토큰의 양입니다.\n * @param data 지정된 형식이 없는 추가 데이터입니다.\n * @return 예외를 발생시키지 않는 한 전송이 허용되는 경우 `bytes4(keccak256(\"onTransferReceived(address,address,uint256,bytes)\"))`입니다.\n */\n function onTransferReceived(address operator, address from, uint256 value, bytes calldata data) external returns (bytes4);\n}
+```
+
+`approveAndCall`을 통해 ERC-1363 토큰을 수락하려는 스마트 계약은 `ERC1363Spender` 인터페이스를 **반드시** 구현해야 합니다.
+
+```solidity
+/**\n * @title ERC1363Spender\n * @dev ERC-1363 토큰 계약에서 `approveAndCall`을 지원하려는 모든 계약을 위한 인터페이스입니다.\n */\ninterface ERC1363Spender {\n /**\n * @dev ERC-1363 토큰 `owner`가 `ERC1363::approveAndCall`을 통해 이 계약이\n * 자신의 토큰을 사용하도록 승인할 때마다 이 함수가 호출됩니다.\n *\n * 참고: 승인을 수락하려면 이 함수는\n * `bytes4(keccak256(\"onApprovalReceived(address,uint256,bytes)\"))`\n * (예: 0x7b04a2d0 또는 자체 함수 선택자)를 반환해야 합니다.\n *\n * @param owner `approveAndCall` 함수를 호출하고 이전에 토큰을 소유했던 주소입니다.\n * @param value 사용될 토큰의 양입니다.\n * @param data 지정된 형식이 없는 추가 데이터입니다.\n * @return 예외를 발생시키지 않는 한 승인이 허용되는 경우 `bytes4(keccak256(\"onApprovalReceived(address,uint256,bytes)\"))`입니다.\n */\n function onApprovalReceived(address owner, uint256 value, bytes calldata data) external returns (bytes4);\n}
+```
+
+## 더 읽어보기 {#further-reading}
+
+- [ERC-1363: 지불 가능 토큰 표준](https://eips.ethereum.org/EIPS/eip-1363)
+- [ERC-1363: GitHub 리포지토리](https://github.com/vittominacori/erc1363-payable-token)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-20/index.md
new file mode 100644
index 00000000000..7eef6f2aebd
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-20/index.md
@@ -0,0 +1,186 @@
+---
+title: "ERC-20 토큰 표준"
+description: "상호 운용 가능한 토큰 애플리케이션을 지원하는 이더리움의 대체 가능한 토큰 표준인 ERC-20에 대해 알아보세요."
+lang: ko
+---
+
+## 소개 {#introduction}
+
+**토큰이란 무엇인가요?**
+
+이더리움에서 토큰은 거의 모든 것을 표현할 수 있습니다.
+
+- 온라인 플랫폼의 평판점수
+- 게임 캐릭터의 스킬
+- 회사 주식지분 같은 금융자산
+- 미국달러와 같은 법정통화
+- 1 온스의 금
+- 그 이상 많은것들...
+
+이더리움의 이러한 강력한 특성은 견고한 표준 위에서 동작해야 하지 않을까요? 그것이 바로 ERC-20의 역할입니다! 이 표준을 통해서 개발자들은 다른 제품 및 서비스와 상호 연계 운용 가능한 토큰 애플리케이션을 구축할 수 있습니다. ERC-20 표준은 [이더](/glossary/#ether)에 추가적인 기능을 제공하는 데에도 사용됩니다.
+
+**ERC-20은 무엇인가요?**
+
+ERC-20은 대체가능 토큰의 표준을 제시합니다. 즉, 각 토큰은 다른 토큰과 정확히 동일(유형 및 가치) 하게 만드는 속성을 가지고 있습니다. 예를 들어 ERC-20 토큰은 ETH로 취급되며, 이는 1 토큰이 다른 모든 토큰과 항상 동일함을 의미합니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+- [계정](/developers/docs/accounts)
+- [스마트 계약](/developers/docs/smart-contracts/)
+- [토큰 표준](/developers/docs/standards/tokens/)
+
+## 본문 {#body}
+
+2015년 11월 Fabian Vogelsteller가 제안한 ERC-20(Ethereum Request for Comments 20) 은 스마트 계약 내에서 토큰용 API를 구현하는 토큰 표준이다.
+
+ERC-20에서 제공하는 기능 예시
+
+- 서로 다른 계정간에 토큰 전송하기
+- 계정에서 토큰 잔고 확인하기
+- 가용 중인 네트워크 상의 토큰 총 공급량 확인하기
+- 특정 계정의 토큰을 다른 외부 계정에서 사용 가능한 지 여부를 승인하기
+
+스마트 계약이 다음과 같은 방법과 이벤트를 실행할 경우 이를 ERC-20 토큰 계약이라고 할 수 있으며, 한번 구축되면 이더리움에서 생성된 토큰들을 추적해야 한다.
+
+[EIP-20](https://eips.ethereum.org/EIPS/eip-20)에서:
+
+### 메서드 {#methods}
+
+```solidity
+function name() public view returns (string)
+function symbol() public view returns (string)
+function decimals() public view returns (uint8)
+function totalSupply() public view returns (uint256)
+function balanceOf(address _owner) public view returns (uint256 balance)
+function transfer(address _to, uint256 _value) public returns (bool success)
+function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
+function approve(address _spender, uint256 _value) public returns (bool success)
+function allowance(address _owner, address _spender) public view returns (uint256 remaining)
+```
+
+### 이벤트 {#events}
+
+```solidity
+event Transfer(address indexed _from, address indexed _to, uint256 _value)
+event Approval(address indexed _owner, address indexed _spender, uint256 _value)
+```
+
+### 예시 {#web3py-example}
+
+우리가 이더리움상의 어느 ERC-20 토큰 계약을 검사하는데 있어서 이 표준이 얼마나 주요하게 그 검사를 간단히 만드는지 살펴보자.
+ERC-20 토큰에 대한 인터페이스를 생성하려면 계약 애플리케이션 바이너리 인터페이스(ABI) 가 필요하다. 아래 보이는 것처럼 우리는 잡음을 줄이기 위해 단순화된 ABI를 사용해 예제를 만들것이다.
+
+#### Web3.py 예시 {#web3py-example}
+
+먼저, [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) 파이썬 라이브러리를 설치했는지 확인하세요.
+
+```
+pip install web3
+```
+
+```python
+from web3 import Web3
+
+
+w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
+
+dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI
+weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH)
+
+acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2
+
+# 이것은 ERC-20 토큰 계약의 단순화된 계약 애플리케이션 바이너리 인터페이스(ABI)입니다.
+# balanceOf(address), decimals(), symbol() 및 totalSupply() 메서드만 노출합니다.
+simplified_abi = [
+ {
+ 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}],
+ 'name': 'balanceOf',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'decimals',
+ 'outputs': [{'internalType': 'uint8', 'name': '', 'type': 'uint8'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'symbol',
+ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'totalSupply',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ }
+]
+
+dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi)
+symbol = dai_contract.functions.symbol().call()
+decimals = dai_contract.functions.decimals().call()
+totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals
+addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals
+
+# DAI
+print("===== %s =====" % symbol)
+print("Total Supply:", totalSupply)
+print("Addr Balance:", addr_balance)
+
+weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi)
+symbol = weth_contract.functions.symbol().call()
+decimals = weth_contract.functions.decimals().call()
+totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals
+addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals
+
+# WETH
+print("===== %s =====" % symbol)
+print("Total Supply:", totalSupply)
+print("Addr Balance:", addr_balance)
+```
+
+## 알려진 문제점 {#erc20-issues}
+
+### ERC-20 토큰 수신 문제 {#reception-issue}
+
+**2024년 6월 20일 기준, 이 문제로 인해 최소 83,656,418달러 상당의 ERC-20 토큰이 손실되었습니다. 아래 목록에 명시된 대로 표준 외에 추가적인 제한 사항을 구현하지 않는 한 순수한 ERC-20 구현은 이 문제에 취약하다는 점에 유의하세요.**
+
+ERC-20 토큰이 ERC-20 토큰을 처리하도록 설계되지 않은 스마트 계약으로 전송되면, 해당 토큰은 영구적으로 손실될 수 있습니다. 이는 수신 계약이 들어오는 토큰을 인식하거나 응답할 수 있는 기능이 없기 때문에 발생하며, ERC-20 표준에는 수신 계약에 들어오는 토큰을 알리는 메커니즘이 없습니다. 이 문제는 다음과 같은 방식으로 발생합니다:
+
+1. 토큰 전송 메커니즘
+
+- ERC-20 토큰은 transfer 또는 transferFrom 함수를 사용하여 전송됩니다.
+ - 사용자가 이러한 함수를 사용하여 토큰을 계약 주소로 전송할 때, 수신 계약이 토큰을 처리하도록 설계되었는지와 상관없이 토큰은 전송됩니다.
+
+2. 알림의 부재
+ - 수신 계약은 토큰이 전송되었다는 알림이나 콜백을 받지 않습니다.
+ - 수신 계약에 토큰을 처리할 메커니즘(예: 폴백 함수나 토큰 수신을 관리하는 전용 함수)이 없는 경우, 토큰은 사실상 계약의 주소에 갇히게 됩니다.
+3. 내장된 처리 없음
+ - ERC-20 표준은 수신 계약이 구현해야 할 필수 기능을 포함하지 않으므로, 많은 계약이 들어오는 토큰을 적절히 관리할 수 없는 상황이 발생합니다.
+
+**가능한 해결책**
+
+ERC-20으로 이 문제를 완전히 방지할 수는 없지만, 최종 사용자의 토큰 손실 가능성을 크게 줄일 수 있는 방법들이 있습니다.
+
+- 가장 흔한 문제는 사용자가 토큰 계약 주소 자체로 토큰을 보내는 경우입니다(예: USDT 토큰 계약 주소로 USDT를 예치하는 경우). `transfer(..)` 함수를 제한하여 이러한 전송 시도를 되돌리는 것을 권장합니다. `transfer(..)` 함수의 구현 내에 `require(_to != address(this));` 확인을 추가하는 것을 고려하세요.
+- 일반적으로 `transfer(..)` 함수는 계약에 토큰을 예치하기 위해 설계되지 않았습니다. `approve(..)` & transferFrom(..)`패턴은 대신 ERC-20 토큰을 계약에 예치하는 데 사용됩니다. 전송 함수를 제한하여 이를 통해 어떤 계약에도 토큰을 예치하는 것을 허용하지 않도록 할 수 있지만,`trasnfer(..)` 함수를 사용하여 계약에 토큰을 예치할 수 있다고 가정하는 계약(예: Uniswap 유동성 풀)과의 호환성을 깨뜨릴 수 있습니다.
+- 계약이 어떠한 토큰도 받지 않도록 되어 있더라도 ERC-20 토큰이 계약에 들어올 수 있다고 항상 가정하세요. 수신자 측에서 우발적인 예치를 방지하거나 거부할 방법은 없습니다. 우발적으로 예치된 ERC-20 토큰을 추출할 수 있는 함수를 구현하는 것을 권장합니다.
+- 대안 토큰 표준 사용을 고려해 보세요.
+
+이 문제에서 [ERC-223](/developers/docs/standards/tokens/erc-223) 또는 [ERC-1363](/developers/docs/standards/tokens/erc-1363)과 같은 일부 대안 표준이 나왔습니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [EIP-20: ERC-20 토큰 표준](https://eips.ethereum.org/EIPS/eip-20)
+- [OpenZeppelin - 토큰](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20)
+- [OpenZeppelin - ERC-20 구현](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)
+- [Alchemy - Solidity ERC20 토큰 가이드](https://www.alchemy.com/overviews/erc20-solidity)
+
+## 기타 대체 가능한 토큰 표준 {#fungible-token-standards}
+
+- [ERC-223](/developers/docs/standards/tokens/erc-223)
+- [ERC-1363](/developers/docs/standards/tokens/erc-1363)
+- [ERC-777](/developers/docs/standards/tokens/erc-777)
+- [ERC-4626 - 토큰화된 금고](/developers/docs/standards/tokens/erc-4626)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-223/index.md
new file mode 100644
index 00000000000..8b6aaed3d95
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-223/index.md
@@ -0,0 +1,197 @@
+---
+title: "ERC-223 토큰 표준"
+description: "ERC-223 대체 가능 토큰 표준에 대한 개요, 작동 방식 및 ERC-20과의 비교."
+lang: ko
+---
+
+## 소개 {#introduction}
+
+### ERC-223은 무엇인가요? {#what-is-erc223}
+
+ERC-223은 ERC-20 표준과 유사한 대체 가능 토큰 표준입니다. 주요 차이점은 ERC-223이 토큰 API뿐만 아니라 발신자에서 수신자로 토큰을 전송하는 로직도 정의한다는 것입니다. 수신자 측에서 토큰 전송을 처리할 수 있는 통신 모델을 도입합니다.
+
+### ERC-20과의 차이점 {#erc20-differences}
+
+ERC-223은 ERC-20의 몇 가지 한계를 해결하고 토큰 계약과 토큰을 받을 수 있는 계약 간의 새로운 상호 작용 방법을 도입합니다. ERC-20에서는 불가능하지만 ERC-223에서는 가능한 몇 가지 사항이 있습니다.
+
+- 수신자 측에서의 토큰 전송 처리: 수신자는 ERC-223 토큰이 입금되고 있음을 감지할 수 있습니다.
+- 부적절하게 전송된 토큰 거부: 사용자가 토큰을 받지 않아야 하는 계약에 ERC-223 토큰을 보내는 경우, 해당 계약은 트랜잭션을 거부하여 토큰 손실을 방지할 수 있습니다.
+- 전송 시 메타데이터: ERC-223 토큰은 메타데이터를 포함할 수 있어 토큰 트랜잭션에 임의의 정보를 첨부할 수 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+- [계정](/developers/docs/accounts)
+- [스마트 계약](/developers/docs/smart-contracts/)
+- [토큰 표준](/developers/docs/standards/tokens/)
+- [ERC-20](/developers/docs/standards/tokens/erc-20/)
+
+## 본문 {#body}
+
+ERC-223은 스마트 계약 내의 토큰을 위한 API를 구현하는 토큰 표준입니다. 또한 ERC-223 토큰을 받도록 되어 있는 계약을 위한 API를 선언합니다. ERC-223 수신자 API를 지원하지 않는 계약은 ERC-223 토큰을 받을 수 없어 사용자 실수를 방지합니다.
+
+스마트 계약이 다음 메서드와 이벤트를 구현하면 ERC-223 호환 토큰 계약이라고 할 수 있습니다. 배포되면 이더리움에서 생성된 토큰을 추적할 책임이 있습니다.
+
+계약이 이러한 함수만 가질 의무는 없으며, 개발자는 다른 토큰 표준의 다른 기능을 이 계약에 추가할 수 있습니다. 예를 들어, `approve` 및 `transferFrom` 함수는 ERC-223 표준의 일부는 아니지만 필요한 경우 구현할 수 있습니다.
+
+[EIP-223](https://eips.ethereum.org/EIPS/eip-223)에서:
+
+### 메서드 {#methods}
+
+ERC-223 토큰은 다음 메서드를 구현해야 합니다.
+
+```solidity
+function name() public view returns (string)
+function symbol() public view returns (string)
+function decimals() public view returns (uint8)
+function totalSupply() public view returns (uint256)
+function balanceOf(address _owner) public view returns (uint256 balance)
+function transfer(address _to, uint256 _value) public returns (bool success)
+function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success)
+```
+
+ERC-223 토큰을 받도록 되어 있는 계약은 다음 메서드를 구현해야 합니다.
+
+```solidity
+function tokenReceived(address _from, uint _value, bytes calldata _data)
+```
+
+`tokenReceived(..)` 함수를 구현하지 않는 계약으로 ERC-223 토큰을 보내면 전송이 실패해야 하며, 토큰이 발신자의 잔액에서 이동해서는 안 됩니다.
+
+### 이벤트 {#events}
+
+```solidity
+event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes calldata _data)
+```
+
+### 예시 {#examples}
+
+ERC-223 토큰의 API는 ERC-20과 유사하므로 UI 개발 관점에서 차이가 없습니다. 여기서 유일한 예외는 ERC-223 토큰에 `approve` + `transferFrom` 함수가 없을 수 있다는 것입니다. 이 함수들은 이 표준에서 선택 사항이기 때문입니다.
+
+#### 솔리디티 예제 {#solidity-example}
+
+다음 예제는 기본 ERC-223 토큰 계약이 어떻게 작동하는지 보여줍니다.
+
+```solidity
+pragma solidity ^0.8.19;
+abstract contract IERC223Recipient {
+ function tokenReceived(address _from, uint _value, bytes memory _data) public virtual;
+}
+contract VeryBasicERC223Token {
+ event Transfer(address indexed from, address indexed to, uint value, bytes data);
+ string private _name;
+ string private _symbol;
+ uint8 private _decimals;
+ uint256 private _totalSupply;
+ mapping(address => uint256) private balances;
+ function name() public view returns (string memory) { return _name; }
+ function symbol() public view returns (string memory) {return _symbol; }
+ function decimals() public view returns (uint8) { return _decimals; }
+ function totalSupply() public view returns (uint256) { return _totalSupply; }
+ function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; }
+ function isContract(address account) internal view returns (bool) {
+ uint256 size;
+ assembly { size := extcodesize(account) }
+ return size > 0;
+ }
+ function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success){
+ balances[msg.sender] = balances[msg.sender] - _value;
+ balances[_to] = balances[_to] + _value;
+ if(isContract(_to)) {
+ IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data);
+ }
+ emit Transfer(msg.sender, _to, _value, _data);
+ return true;
+ }
+ function transfer(address _to, uint _value) public returns (bool success){
+ bytes memory _empty = hex"00000000";
+ balances[msg.sender] = balances[msg.sender] - _value;
+ balances[_to] = balances[_to] + _value;
+ if(isContract(_to)) {
+ IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty);
+ }
+ emit Transfer(msg.sender, _to, _value, _empty);
+ return true;
+ }
+}
+```
+
+이제 tokenA가 ERC-223 토큰이라고 가정하고, `tokenA`의 입금을 수락하는 다른 계약을 원합니다. 계약은 tokenA만 수락하고 다른 모든 토큰은 거부해야 합니다. 계약이 tokenA를 받으면 `Deposit()` 이벤트를 발생시키고 내부 `deposits` 변수의 값을 증가시켜야 합니다.
+
+코드는 다음과 같습니다.
+
+```solidity
+contract RecipientContract is IERC223Recipient {
+ event Deposit(address whoSentTheTokens);
+ uint256 deposits = 0;
+ address tokenA; // 우리가 수락하려는 유일한 토큰입니다.
+ function tokenReceived(address _from, uint _value, bytes memory _data) public override
+ {
+ // 이 함수 내에서 다음을 이해하는 것이 중요합니다
+ // msg.sender는 수신 중인 토큰의 주소이며,
+ // msg.value는 대부분의 경우 토큰 계약이 이더를 소유하거나 전송하지 않으므로 항상 0입니다,
+ // _from은 토큰 전송의 발신자이고,
+ // _value는 입금된 토큰의 양입니다.
+ require(msg.sender == tokenA);
+ deposits += _value;
+ emit Deposit(_from);
+ }
+}
+```
+
+## 자주 묻는 질문 {#faq}
+
+### 계약에 tokenB를 보내면 어떻게 될까요? {#sending-tokens}
+
+트랜잭션이 실패하고 토큰 전송이 발생하지 않습니다. 토큰은 발신자의 주소로 반환됩니다.
+
+### 이 계약에 어떻게 입금할 수 있나요? {#contract-deposits}
+
+ERC-223 토큰의 `transfer(address,uint256)` 또는 `transfer(address,uint256,bytes)` 함수를 호출하여 `RecipientContract`의 주소를 지정합니다.
+
+### 이 계약에 ERC-20 토큰을 전송하면 어떻게 될까요? {#erc-20-transfers}
+
+`RecipientContract`에 ERC-20 토큰을 보내면 토큰은 전송되지만, 전송이 인식되지 않습니다(`Deposit()` 이벤트가 발생하지 않으며, deposits 값도 변경되지 않음). 원치 않는 ERC-20 입금은 필터링하거나 방지할 수 없습니다.
+
+### 토큰 입금이 완료된 후 일부 함수를 실행하려면 어떻게 해야 할까요? {#function-execution}
+
+여러 가지 방법이 있습니다. 이 예제에서는 ERC-223 전송을 이더 전송과 동일하게 만드는 방법을 따릅니다.
+
+```solidity
+contract RecipientContract is IERC223Recipient {
+ event Foo();
+ event Bar(uint256 someNumber);
+ address tokenA; // 수락하려는 유일한 토큰입니다.
+ function tokenReceived(address _from, uint _value, bytes memory _data) public override
+ {
+ require(msg.sender == tokenA);
+ address(this).call(_data); // 들어오는 트랜잭션을 처리하고 후속 함수 호출을 수행합니다.
+ }
+ function foo() public
+ {
+ emit Foo();
+ }
+ function bar(uint256 _someNumber) public
+ {
+ emit Bar(_someNumber);
+ }
+}
+```
+
+`RecipientContract`가 ERC-223 토큰을 받으면, 계약은 이더리움 트랜잭션이 트랜잭션 `data`로 함수 호출을 인코딩하는 방식과 동일하게 토큰 트랜잭션의 `_data` 매개변수로 인코딩된 함수를 실행합니다. 자세한 내용은 [데이터 필드](/developers/docs/transactions/#the-data-field)를 읽어보세요.
+
+위 예에서 ERC-223 토큰은 `transfer(address,uin256,bytes calldata _data)` 함수를 사용하여 `RecipientContract`의 주소로 전송되어야 합니다. 데이터 매개변수가 `0xc2985578`(`foo()` 함수의 서명)인 경우, 토큰 입금이 수신된 후 foo() 함수가 호출되고 Foo() 이벤트가 발생합니다.
+
+매개변수는 토큰 전송의 `data`에도 인코딩될 수 있습니다. 예를 들어, `_someNumber`에 12345 값을 사용하여 bar() 함수를 호출할 수 있습니다. 이 경우 `data`는 `0x0423a13200000000000000000000000000000000000000000000000000000000000004d2`여야 합니다. 여기서 `0x0423a132`는 `bar(uint256)` 함수의 서명이고 `00000000000000000000000000000000000000000000000000000000000004d2`는 uint256으로서의 12345입니다.
+
+## 한계 {#limitations}
+
+ERC-223이 ERC-20 표준에서 발견된 여러 문제를 해결하지만, 자체적인 한계도 있습니다.
+
+- 채택 및 호환성: ERC-223은 아직 널리 채택되지 않아 기존 도구 및 플랫폼과의 호환성이 제한될 수 있습니다.
+- 하위 호환성: ERC-223은 ERC-20과 하위 호환되지 않습니다. 즉, 기존 ERC-20 계약 및 도구는 수정 없이는 ERC-223 토큰과 작동하지 않습니다.
+- 가스 비용: ERC-223 전송의 추가 확인 및 기능으로 인해 ERC-20 트랜잭션에 비해 가스 비용이 더 많이 발생할 수 있습니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [EIP-223: ERC-223 토큰 표준](https://eips.ethereum.org/EIPS/eip-223)
+- [초기 ERC-223 제안](https://github.com/ethereum/eips/issues/223)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-4626/index.md
new file mode 100644
index 00000000000..c1945e9b37c
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-4626/index.md
@@ -0,0 +1,227 @@
+---
+title: "ERC-4626 토큰화된 볼트 표준"
+description: "수익을 내는 볼트를 위한 표준입니다."
+lang: ko
+---
+
+## 소개 {#introduction}
+
+ERC-4626은 수익을 내는 볼트의 기술적 매개변수를 최적화하고 통합하기 위한 표준입니다. 단일 기본 ERC-20 토큰의 지분을 나타내는 토큰화된 수익 볼트를 위한 표준 API를 제공합니다. ERC-4626은 또한 ERC-20을 활용하는 토큰화된 볼트를 위한 선택적 확장의 개요를 설명하며, 토큰 예치, 인출 및 잔액 조회를 위한 기본 기능을 제공합니다.
+
+**수익을 내는 볼트에서 ERC-4626의 역할**
+
+대출 시장, 애그리게이터 및 내재적으로 이자가 발생하는 토큰은 다양한 전략을 실행하여 사용자가 자신의 암호화폐 토큰에 대한 최고의 수익률을 찾을 수 있도록 돕습니다. 이러한 전략은 약간의 변형을 거쳐 수행되며, 이로 인해 오류가 발생하기 쉽거나 개발 리소스가 낭비될 수 있습니다.
+
+수익을 내는 볼트에서 ERC-4626은 보다 일관되고 강력한 구현 패턴을 만들어 개발자의 전문적인 노력을 거의 들이지 않고도 통합 노력을 줄이고 다양한 애플리케이션에서 수익에 대한 액세스를 열어줄 것입니다.
+
+ERC-4626 토큰은 [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626)에 완전히 설명되어 있습니다.
+
+**비동기 볼트 확장(ERC-7540)**
+
+ERC-4626은 한도까지의 원자적 예치 및 상환에 최적화되어 있습니다. 한도에 도달하면 새로운 예치나 상환을 제출할 수 없습니다. 이러한 제한은 볼트와 인터페이스하기 위한 전제 조건으로 비동기 작업 또는 지연이 있는 모든 스마트 계약 시스템(예: 실물 자산 프로토콜, 담보 부족 대출 프로토콜, 교차 체인 대출 프로토콜, 유동 스테이킹 토큰 또는 보험 안전 모듈)에서는 잘 작동하지 않습니다.
+
+ERC-7540은 비동기 사용 사례를 위해 ERC-4626 볼트의 유용성을 확장합니다. 기존 볼트 인터페이스(`deposit`/`withdraw`/`mint`/`redeem`)는 비동기 요청을 처리하기 위해 완전히 활용됩니다.
+
+ERC-7540 확장은 [ERC-7540](https://eips.ethereum.org/EIPS/eip-7540)에 완전히 설명되어 있습니다.
+
+**다중 자산 볼트 확장(ERC-7575)**
+
+ERC-4626에서 지원하지 않는 한 가지 누락된 사용 사례는 유동성 공급자(LP) 토큰과 같이 여러 자산 또는 진입점을 가진 볼트입니다. 이들은 일반적으로 ERC-4626 자체가 ERC-20이어야 한다는 요구사항으로 인해 다루기 어렵거나 규정을 준수하지 않습니다.
+
+ERC-7575는 ERC-4626 구현에서 ERC-20 토큰 구현을 외부화하여 다중 자산을 가진 볼트에 대한 지원을 추가합니다.
+
+ERC-7575 확장은 [ERC-7575](https://eips.ethereum.org/EIPS/eip-7575)에 완전히 설명되어 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 [토큰 표준](/developers/docs/standards/tokens/) 및 [ERC-20](/developers/docs/standards/tokens/erc-20/)에 대해 읽어보시는 것을 추천합니다.
+
+## ERC-4626 기능 및 특징: {#body}
+
+### 메서드 {#methods}
+
+#### 자산 {#asset}
+
+```solidity
+function asset() public view returns (address assetTokenAddress)
+```
+
+이 함수는 회계, 예치, 인출을 위해 볼트에 사용되는 기본 토큰의 주소를 반환합니다.
+
+#### 총자산 {#totalassets}
+
+```solidity
+function totalAssets() public view returns (uint256)
+```
+
+이 함수는 볼트가 보유한 기본 자산의 총액을 반환합니다.
+
+#### 지분으로 전환 {#convertoshares}
+
+```solidity
+function convertToShares(uint256 assets) public view returns (uint256 shares)
+```
+
+이 함수는 제공된 `assets`의 양에 대해 볼트가 교환할 `shares`의 양을 반환합니다.
+
+#### 자산으로 전환 {#convertoassets}
+
+```solidity
+function convertToAssets(uint256 shares) public view returns (uint256 assets)
+```
+
+이 함수는 제공된 `shares`의 양에 대해 볼트가 교환할 `assets`의 양을 반환합니다.
+
+#### 최대 예치 {#maxdeposit}
+
+```solidity
+function maxDeposit(address receiver) public view returns (uint256 maxAssets)
+```
+
+이 함수는 단일 [`deposit`](#deposit) 호출에서 예치할 수 있는 기본 자산의 최대 금액을 반환하며, 지분은 `receiver`를 위해 발행됩니다.
+
+#### 예치 미리보기 {#previewdeposit}
+
+```solidity
+function previewDeposit(uint256 assets) public view returns (uint256 shares)
+```
+
+이 함수를 통해 사용자는 현재 블록에서 자신의 예치가 미치는 영향을 시뮬레이션할 수 있습니다.
+
+#### 예치 {#deposit}
+
+```solidity
+function deposit(uint256 assets, address receiver) public returns (uint256 shares)
+```
+
+이 함수는 기본 토큰의 `assets`를 볼트에 예치하고 `shares`의 소유권을 `receiver`에게 부여합니다.
+
+#### 최대 발행 {#maxmint}
+
+```solidity
+function maxMint(address receiver) public view returns (uint256 maxShares)
+```
+
+이 함수는 단일 [`mint`](#mint) 호출에서 발행할 수 있는 최대 지분 금액을 반환하며, 지분은 `receiver`를 위해 발행됩니다.
+
+#### 발행 미리보기 {#previewmint}
+
+```solidity
+function previewMint(uint256 shares) public view returns (uint256 assets)
+```
+
+이 함수를 통해 사용자는 현재 블록에서 자신의 발행이 미치는 영향을 시뮬레이션할 수 있습니다.
+
+#### 발행 {#mint}
+
+```solidity
+function mint(uint256 shares, address receiver) public returns (uint256 assets)
+```
+
+이 함수는 기본 토큰의 `assets`를 예치하여 `receiver`에게 정확히 `shares`만큼의 볼트 지분을 발행합니다.
+
+#### 최대 인출 {#maxwithdraw}
+
+```solidity
+function maxWithdraw(address owner) public view returns (uint256 maxAssets)
+```
+
+이 함수는 단일 [`withdraw`](#withdraw) 호출로 `owner`의 잔액에서 인출할 수 있는 기본 자산의 최대 금액을 반환합니다.
+
+#### 인출 미리보기 {#previewwithdraw}
+
+```solidity
+function previewWithdraw(uint256 assets) public view returns (uint256 shares)
+```
+
+이 함수를 통해 사용자는 현재 블록에서 자신의 인출이 미치는 영향을 시뮬레이션할 수 있습니다.
+
+#### 인출 {#withdraw}
+
+```solidity
+function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares)
+```
+
+이 함수는 `owner`로부터 `shares`를 소각하고 볼트에서 `receiver`에게 정확히 `assets` 토큰을 보냅니다.
+
+#### 최대 상환 {#maxredeem}
+
+```solidity
+function maxRedeem(address owner) public view returns (uint256 maxShares)
+```
+
+이 함수는 [`redeem`](#redeem) 호출을 통해 `owner`의 잔액에서 상환할 수 있는 최대 지분 금액을 반환합니다.
+
+#### 상환 미리보기 {#previewredeem}
+
+```solidity
+function previewRedeem(uint256 shares) public view returns (uint256 assets)
+```
+
+이 함수를 통해 사용자는 현재 블록에서 자신의 상환이 미치는 영향을 시뮬레이션할 수 있습니다.
+
+#### 상환 {#redeem}
+
+```solidity
+function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets)
+```
+
+이 함수는 `owner`로부터 특정 수량의 `shares`를 상환하고 볼트에서 `receiver`에게 기본 토큰의 `assets`를 보냅니다.
+
+#### 총 공급량 {#totalsupply}
+
+```solidity
+function totalSupply() public view returns (uint256)
+```
+
+유통 중인 상환되지 않은 볼트 지분의 총 수량을 반환합니다.
+
+#### 잔액 {#balanceof}
+
+```solidity
+function balanceOf(address owner) public view returns (uint256)
+```
+
+`owner`가 현재 보유하고 있는 볼트 지분의 총량을 반환합니다.
+
+### 인터페이스 맵 {#mapOfTheInterface}
+
+
+
+### 이벤트 {#events}
+
+#### 예치 이벤트
+
+[`mint`](#mint) 및 [`deposit`](#deposit) 메서드를 통해 토큰이 볼트에 예치될 때 **반드시** 방출되어야 합니다.
+
+```solidity
+event Deposit(
+ address indexed sender,
+ address indexed owner,
+ uint256 assets,
+ uint256 shares
+)
+```
+
+여기서 `sender`는 `assets`를 `shares`로 교환하고 해당 `shares`를 `owner`에게 전송한 사용자입니다.
+
+#### 인출 이벤트
+
+[`redeem`](#redeem) 또는 [`withdraw`](#withdraw) 메서드에서 예금자가 볼트에서 지분을 인출할 때 **반드시** 방출되어야 합니다.
+
+```solidity
+event Withdraw(
+ address indexed sender,
+ address indexed receiver,
+ address indexed owner,
+ uint256 assets,
+ uint256 shares
+)
+```
+
+여기서 `sender`는 인출을 트리거하고 `owner`가 소유한 `shares`를 `assets`로 교환한 사용자입니다. `receiver`는 인출된 `assets`를 받은 사용자입니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [EIP-4626: 토큰화된 볼트 표준](https://eips.ethereum.org/EIPS/eip-4626)
+- [ERC-4626: GitHub 리포지토리](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-721/index.md
new file mode 100644
index 00000000000..2f701439210
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-721/index.md
@@ -0,0 +1,248 @@
+---
+title: "ERC-721 대체 불가능 토큰 표준"
+description: "이더리움에서 고유한 디지털 자산을 나타내는 대체 불가 토큰(NFT)의 표준인 ERC-721에 대해 알아보세요."
+lang: ko
+---
+
+## 소개 {#introduction}
+
+**대체 불가능 토큰이란 무엇인가요?**
+
+대체 불가능 토큰(NFT)은 무언가나 누군가를 독특한 방식으로 식별하는 데 사용됩니다. 이 유형의 토큰은 수집품, 접근 키, 복권, 콘서트 및 스포츠 경기의 번호 매겨진 좌석 등을 제공하는 플랫폼에서 사용하기에 적합합니다. 이 특별한 유형의 토큰은 놀라운 가능성을 가지고 있어 ERC-721이라는 적절한 표준이 필요합니다!
+
+**ERC-721은 무엇인가요?**
+
+ERC-721은 NFT 표준을 도입하였으며, 즉, 이 유형의 토큰은 고유하며 같은 스마트 계약의 다른 토큰과는 나이나 희귀성 또는 시각적인 요소 등으로 인해 다른 가치를 가질 수 있습니다.
+잠깐, 시각적인 요소라고요?
+
+네! 모든 NFT에는 `tokenId`라는 `uint256` 변수가 있으므로 모든 ERC-721 계약의 경우
+`contract address, uint256 tokenId` 쌍은 전역적으로 고유해야 합니다. 즉, 탈중앙화앱은 `tokenId`를 입력으로 사용하고 좀비, 무기, 기술 또는 놀라운 고양이 같은 멋진 것을 이미지로 출력하는 "변환기"를 가질 수 있습니다!
+
+## 필수 구성 요소 {#prerequisites}
+
+- [계정](/developers/docs/accounts/)
+- [스마트 계약](/developers/docs/smart-contracts/)
+- [토큰 표준](/developers/docs/standards/tokens/)
+
+## 본문 {#body}
+
+ERC-721(Ethereum Request for Comments 721)은 2018년 1월 William Entriken, Dieter Shirley, Jacob Evans, Nastassia Sachs가 제안한 대체 불가능 토큰 표준으로, 스마트 계약 내에서 토큰을 위한 API를 구현합니다.
+
+이 표준은 한 계정에서 다른 계정으로 토큰을 전송하고, 계정의 현재 토큰 잔액을 확인하고, 특정 토큰의 소유자를 확인하며 네트워크에서 사용 가능한 토큰의 총 공급량을 가져오는 기능을 제공합니다.
+또한, 다른 계정이 특정 계정에서 일정량의 토큰을 이동하도록 승인하는 기능도 포함되어 있습니다.
+
+스마트 계약이 다음 메서드와 이벤트를 구현하면 ERC-721 대체 불가능 토큰 계약이라 부를 수 있으며, 배포되면 이더리움 상에서 생성된 토큰을 추적하는 책임을 갖게 됩니다.
+
+[EIP-721](https://eips.ethereum.org/EIPS/eip-721)에서 발췌:
+
+### 메서드 {#methods}
+
+```solidity
+ function balanceOf(address _owner) external view returns (uint256);
+ function ownerOf(uint256 _tokenId) external view returns (address);
+ function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
+ function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
+ function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
+ function approve(address _approved, uint256 _tokenId) external payable;
+ function setApprovalForAll(address _operator, bool _approved) external;
+ function getApproved(uint256 _tokenId) external view returns (address);
+ function isApprovedForAll(address _owner, address _operator) external view returns (bool);
+```
+
+### 이벤트 {#events}
+
+```solidity
+ event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
+ event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);
+ event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);
+```
+
+### 예시 {#web3py-example}
+
+표준이 이더리움의 모든 ERC-721 토큰 계약을 간단하게 검사하는 데 얼마나 중요한지 살펴보겠습니다.
+모든 ERC-721 토큰에 대한 인터페이스를 생성하려면 계약 애플리케이션 바이너리 인터페이스(ABI)만 있으면 됩니다. 아래 보이는 것처럼 우리는 잡음을 줄이기 위해 단순화된 ABI를 사용해 예제를 만들것이다.
+
+#### Web3.py 예시 {#web3py-example}
+
+먼저, [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) 파이썬 라이브러리를 설치했는지 확인하세요.
+
+```
+pip install web3
+```
+
+```python
+from web3 import Web3
+from web3._utils.events import get_event_data
+
+
+w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
+
+ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # 크립토키티 계약
+
+acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # 크립토키티 판매 경매
+
+# 이것은 ERC-721 NFT 계약의 단순화된 계약 애플리케이션 바이너리 인터페이스(ABI)입니다.
+# balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply() 메서드만 노출합니다.
+simplified_abi = [
+ {
+ 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}],
+ 'name': 'balanceOf',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'name',
+ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [{'internalType': 'uint256', 'name': 'tokenId', 'type': 'uint256'}],
+ 'name': 'ownerOf',
+ 'outputs': [{'internalType': 'address', 'name': '', 'type': 'address'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'symbol',
+ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'totalSupply',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+]
+
+ck_extra_abi = [
+ {
+ 'inputs': [],
+ 'name': 'pregnantKitties',
+ 'outputs': [{'name': '', 'type': 'uint256'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [{'name': '_kittyId', 'type': 'uint256'}],
+ 'name': 'isPregnant',
+ 'outputs': [{'name': '', 'type': 'bool'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ }
+]
+
+ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi)
+name = ck_contract.functions.name().call()
+symbol = ck_contract.functions.symbol().call()
+kitties_auctions = ck_contract.functions.balanceOf(acc_address).call()
+print(f"{name} [{symbol}] 경매 중인 NFT: {kitties_auctions}")
+
+pregnant_kitties = ck_contract.functions.pregnantKitties().call()
+print(f"{name} [{symbol}] 임신 중인 NFT: {pregnant_kitties}")
+
+# 전송 이벤트 ABI를 사용하여 전송된 키티에 대한 정보 얻기
+tx_event_abi = {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'from', 'type': 'address'},
+ {'indexed': False, 'name': 'to', 'type': 'address'},
+ {'indexed': False, 'name': 'tokenId', 'type': 'uint256'}],
+ 'name': 'Transfer',
+ 'type': 'event'
+}
+
+# 로그를 필터링하려면 이벤트의 서명이 필요합니다
+event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex()
+
+logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [event_signature]
+})
+
+# 참고:
+# - 전송 이벤트가 반환되지 않으면 블록 수를 120개 이상으로 늘립니다.
+# - 전송 이벤트를 찾지 못한 경우 다음에서 tokenId를 얻을 수도 있습니다.
+# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events
+# 이벤트 로그를 확장하고 "tokenId" 인수를 복사하려면 클릭하십시오.
+recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs]
+
+if recent_tx:
+ kitty_id = recent_tx[0]['tokenId'] # 위 링크에서 "tokenId"를 여기에 붙여넣습니다.
+ is_pregnant = ck_contract.functions.isPregnant(kitty_id).call()
+ print(f"{name} [{symbol}] NFT {kitty_id} 임신 여부: {is_pregnant}")
+```
+
+CryptoKitties 계약은 표준 이벤트 외에도 몇 가지 흥미로운 이벤트가 있습니다.
+
+그중 `Pregnant`와 `Birth` 두 가지를 확인해 보겠습니다.
+
+```python
+# Pregnant 및 Birth 이벤트 ABI를 사용하여 새로운 키티에 대한 정보 얻기
+ck_extra_events_abi = [
+ {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'owner', 'type': 'address'},
+ {'indexed': False, 'name': 'matronId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'sireId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'cooldownEndBlock', 'type': 'uint256'}],
+ 'name': 'Pregnant',
+ 'type': 'event'
+ },
+ {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'owner', 'type': 'address'},
+ {'indexed': False, 'name': 'kittyId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'matronId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'sireId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'genes', 'type': 'uint256'}],
+ 'name': 'Birth',
+ 'type': 'event'
+ }]
+
+# 로그를 필터링하려면 이벤트의 서명이 필요합니다
+ck_event_signatures = [
+ w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(),
+ w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(),
+]
+
+# 다음은 Pregnant 이벤트입니다:
+# - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog
+pregnant_logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [ck_event_signatures[0]]
+})
+
+recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs]
+
+# 다음은 Birth 이벤트입니다:
+# - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a
+birth_logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [ck_event_signatures[1]]
+})
+
+recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs]
+```
+
+## 인기 있는 NFT {#popular-nfts}
+
+- [Etherscan NFT 추적기](https://etherscan.io/nft-top-contracts)는 전송량을 기준으로 이더리움의 상위 NFT를 나열합니다.
+- [CryptoKitties](https://www.cryptokitties.co/)는 우리가 CryptoKitties라고 부르는 번식 가능하고 수집 가능하며 아주 사랑스러운 생물을 중심으로 하는 게임입니다.
+- [Sorare](https://sorare.com/)는 한정판 수집품을 수집하고, 팀을 관리하며 상품을 획득하기 위해 경쟁하는 글로벌 판타지 축구 게임입니다.
+- [이더리움 이름 서비스(ENS)](https://ens.domains/)는 간단하고 사람이 읽을 수 있는 이름을 사용하여 블록체인 온체인과 오프체인 리소스의 주소를 지정하는 안전하고 분산된 방법을 제공합니다.
+- [POAP](https://poap.xyz)는 이벤트에 참석하거나 특정 작업을 완료하는 사람들에게 무료 NFT를 제공합니다. POAP는 무료로 생성 및 배포할 수 있습니다.
+- [Unstoppable Domains](https://unstoppabledomains.com/)는 샌프란시스코에 본사를 둔 블록체인 도메인 구축 회사입니다. 블록체인 도메인은 암호화폐 주소를 사람이 읽을 수 있는 이름으로 대체하며, 검열 저항성 웹사이트를 활성화하는 데 사용할 수 있습니다.
+- [Gods Unchained Cards](https://godsunchained.com/)는 NFT를 사용하여 게임 내 자산에 대한 실제 소유권을 부여하는 이더리움 블록체인 기반의 TCG입니다.
+- [Bored Ape Yacht Club](https://boredapeyachtclub.com)은 10,000개의 고유한 NFT 컬렉션으로, 증명할 수 있는 희귀한 예술 작품일 뿐만 아니라 클럽의 멤버십 토큰 역할을 하며, 커뮤니티의 노력의 결과로 시간이 지남에 따라 증가하는 회원 특전과 혜택을 제공합니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [EIP-721: ERC-721 대체 불가 토큰 표준](https://eips.ethereum.org/EIPS/eip-721)
+- [OpenZeppelin - ERC-721 문서](https://docs.openzeppelin.com/contracts/3.x/erc721)
+- [OpenZeppelin - ERC-721 구현](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol)
+- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-777/index.md
new file mode 100644
index 00000000000..4c898125d7a
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-777/index.md
@@ -0,0 +1,45 @@
+---
+title: "ERC-777 토큰 표준"
+description: "훅(hook)을 통해 개선된 대체 가능한 토큰 표준인 ERC-777에 대해 알아보세요. 단, 보안을 위해 ERC-20 사용을 권장합니다."
+lang: ko
+---
+
+## 경고 {#warning}
+
+**ERC-777은 [다양한 형태의 공격에 취약](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2620)하기 때문에 제대로 구현하기가 어렵습니다. 대신 [ERC-20](/developers/docs/standards/tokens/erc-20/)을 사용하는 것이 좋습니다.** 이 페이지는 역사적 기록물로 남아 있습니다.
+
+## 소개? {#introduction}
+
+ERC-777은 기존의 [ERC-20](/developers/docs/standards/tokens/erc-20/) 표준을 개선한 대체 가능한 토큰 표준입니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 [ERC-20](/developers/docs/standards/tokens/erc-20/)에 대해 읽어보는 것을 권장합니다.
+
+## ERC-777은 ERC-20에 비해 어떤 개선점을 제안하나요? {#-erc-777-vs-erc-20}
+
+ERC-777은 ERC-20에 비해 다음과 같은 개선점을 제공합니다.
+
+### 훅 {#hooks}
+
+훅은 스마트 계약의 코드에 기술된 함수입니다. 훅은 계약을 통해 토큰을 보내거나 받을 때 호출됩니다. 이를 통해 스마트 계약은 수신 또는 발신 토큰에 반응할 수 있습니다.
+
+훅은 [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820) 표준을 사용하여 등록되고 발견됩니다.
+
+#### 훅의 장점은 무엇인가요? {#why-are-hooks-great}
+
+1. 이를 위해 이중 호출(`approve`/`transferFrom`)이 필요한 [ERC-20](https://eips.ethereum.org/EIPS/eip-20)과 달리 훅은 단일 트랜잭션으로 계약에 토큰을 보내고 계약에 알림을 보낼 수 있습니다.
+2. 훅을 등록하지 않은 계약은 ERC-777과 호환되지 않습니다. 수신 계약이 훅을 등록하지 않은 경우 송신 계약은 트랜잭션을 중단합니다. 이는 비-ERC-777 스마트 계약으로의 의도치 않은 전송을 방지합니다.
+3. 훅은 트랜잭션을 거부할 수 있습니다.
+
+### 소수 자릿수 {#decimals}
+
+이 표준은 또한 ERC-20에서 발생한 `decimals` 관련 혼란을 해결합니다. 이러한 명확성은 개발자 경험을 개선합니다.
+
+### ERC-20과의 하위 호환성 {#backwards-compatibility-with-erc-20}
+
+ERC-777 계약은 마치 ERC-20 계약인 것처럼 상호작용할 수 있습니다.
+
+## 추가 정보 {#further-reading}
+
+[EIP-777: 토큰 표준](https://eips.ethereum.org/EIPS/eip-777)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/index.md b/public/content/translations/ko/developers/docs/standards/tokens/index.md
new file mode 100644
index 00000000000..dd45932ecb8
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/index.md
@@ -0,0 +1,41 @@
+---
+title: "토큰 표준"
+description: "대체 가능 토큰 및 대체 불가능 토큰을 위한 ERC-20, ERC-721, ERC-1155를 비롯한 이더리움 토큰 표준을 살펴보세요."
+lang: ko
+incomplete: true
+---
+
+## 소개 {#introduction}
+
+많은 이더리움 개발 표준이 토큰 인터페이스에 초점을 맞추고 있습니다. 이러한 표준은 스마트 계약이 구성 가능성을 유지하도록 도와주므로, 새로운 프로젝트가 토큰을 발행할 때 기존 탈중앙화 거래소 및 애플리케이션과의 호환성을 유지할 수 있습니다.
+
+토큰 표준은 이더리움 생태계 전반에서 토큰이 어떻게 작동하고 상호작용하는지를 정의합니다. 이는 개발자가 불필요한 수고를 덜고 더 쉽게 구축할 수 있도록 하며, 토큰이 지갑, 거래소 및 디파이 플랫폼과 원활하게 작동하도록 보장합니다. 게임, 거버넌스 또는 기타 사용 사례 등에서 이러한 표준은 일관성을 제공하고 이더리움의 상호 연결성을 더욱 강화합니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+- [이더리움 개발 표준](/developers/docs/standards/)
+- [스마트 계약](/developers/docs/smart-contracts/)
+
+## 토큰 표준 {#token-standards}
+
+다음은 이더리움에서 가장 인기 있는 토큰 표준 중 일부입니다:
+
+- [ERC-20](/developers/docs/standards/tokens/erc-20/) - 투표 토큰, 스테이킹 토큰 또는 가상 화폐와 같은 대체 가능한(상호 교환 가능한) 토큰을 위한 표준 인터페이스입니다.
+
+### NFT 표준 {#nft-standards}
+
+- [ERC-721](/developers/docs/standards/tokens/erc-721/) - 예술품이나 노래의 증서와 같은 대체 불가능한 토큰을 위한 표준 인터페이스입니다.
+- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - ERC-1155는 거래 및 트랜잭션 묶음의 효율성을 높여 비용을 절감합니다. 이 토큰 표준은 $BNB 또는 $BAT 같은 유틸리티 토큰과 CryptoPunks와 같은 대체 불가능한 토큰을 만들 수 있습니다.
+
+[ERC](https://eips.ethereum.org/erc) 제안 전체 목록.
+
+## 더 읽어보기 {#further-reading}
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
+
+## 관련 튜토리얼 {#related-tutorials}
+
+- [토큰 통합 체크리스트](/developers/tutorials/token-integration-checklist/) _– 토큰과 상호작용할 때 고려해야 할 사항에 대한 체크리스트입니다._
+- [ERC20 토큰 스마트 계약 이해하기](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– 이더리움 테스트넷에 첫 스마트 계약을 배포하는 방법에 대한 소개입니다._
+- [솔리디티 스마트 계약에서 ERC20 토큰 전송 및 승인하기](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– 솔리디티 언어를 사용하여 스마트 계약으로 토큰과 상호작용하는 방법입니다._
+- [ERC721 마켓 구현하기[실용 가이드]](/developers/tutorials/how-to-implement-an-erc721-market/) _– 탈중앙화된 게시판에서 토큰화된 아이템을 판매하는 방법입니다._
diff --git a/public/content/translations/ko/developers/docs/storage/index.md b/public/content/translations/ko/developers/docs/storage/index.md
new file mode 100644
index 00000000000..fdfd3f02633
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/storage/index.md
@@ -0,0 +1,216 @@
+---
+title: "분산형 스토리지"
+description: "탈중앙화 저장소의 정의와 이를 하나의 디앱으로 통합하는 데 사용할 수 있는 도구들에 대한 개요"
+lang: ko
+---
+
+하나의 회사나 조직이 운영하는 중앙집중형 서버와 달리, 탈중앙화 저장소 시스템은 전체 데이터의 일부를 보유하는 사용자-운영자들의 P2P 네트워크로 구성되어 안정성 있는 파일 저장소 공유 시스템을 구축합니다. 이런 시스템들은 블록체인 기반 애플리케이션이나 모든 P2P 기반 네트워크에 있을 수 있습니다.
+
+이더리움은 그 자체로 탈중앙화 저장소 시스템으로 활용될 수 있으며, 모든 스마트 컨트랙트에서의 코드 저장공간이 바로 그것입니다. 하지만 많은 양의 데이터를 저장하는 경우, 이더리움이 설계된 목적에 부합하지 않습니다. 체인은 꾸준히 성장하고 있지만, 이 글을 쓰는 시점에서 이더리움 체인은 약 500GB\~1TB([클라이언트에 따라 다름](https://etherscan.io/chartsync/chaindefault))이며, 네트워크의 모든 노드는 모든 데이터를 저장할 수 있어야 합니다. 체인을 대량의 데이터(예: 5TB)로 확장해야 하는 경우 모든 노드가 계속 실행되는 것은 실현 가능하지 않을 수 있습니다. 또한, 이 많은 양의 데이터를 메인넷에 배포하는 비용은 [가스](/developers/docs/gas) 수수료 때문에 엄청나게 비쌀 것입니다.
+
+이러한 제약으로 인해, 많은 양의 데이터를 탈중앙화된 방식으로 저장할 수 있는 다른 체인이나 방법론이 필요합니다.
+
+탈중앙화 저장소(dStorage) 옵션을 살펴볼 때, 사용자가 유의해야 할 몇가지 사항이 있습니다.
+
+- 지속성 메카니즘 / 인센티브 구조
+- 데이터 보존 시행
+- 분산성
+- 합의
+
+## 지속성 메커니즘 / 인센티브 구조 {#persistence-mechanism}
+
+### 블록체인 기반 {#blockchain-based}
+
+데이터 조각이 영원히 지속되려면 지속성 메커니즘을 사용해야 합니다. 예를 들어, 이더리움에서 지속성 메커니즘이란 노드를 실행할 때 전체 체인을 고려해야 한다는 것입니다. 새로운 데이터 조각이 체인의 끝에 추가되고 계속해서 성장하여 모든 노드가 임베디드 데이터를 복제해야 합니다.
+
+이를 **블록체인 기반** 지속성이라고 합니다.
+
+블록체인 기반 지속성의 문제점은 체인이 너무 커져서 모든 데이터를 실현 가능한 방식으로 유지하고 저장하기 어렵다는 것입니다(예: [여러 출처](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/)에 따르면 인터넷에는 40제타바이트 이상의 저장 공간 용량이 필요하다고 추정됩니다).
+
+블록체인은 또한 일종의 인센티브 구조가 있어야 합니다. 블록체인 기반 지속성을 위해서는 검증자에게 지급되는 대가가 있습니다. 데이터가 체인에 추가될 때 검증자들이 데이터를 추가하기 위해 대가를 받습니다.
+
+블록체인 기반 지속성을 갖춘 플랫폼
+
+- 이더리움
+- [Arweave](https://www.arweave.org/)
+
+### 계약 기반 {#contract-based}
+
+**계약 기반** 지속성은 모든 노드에서 데이터를 복제하고 영구적으로 저장할 수 없으며, 대신 계약 합의에 따라 유지되어야 한다는 개념을 기반으로 합니다. 이것은 일정 기간 동안 데이터 조각을 보유하기로 약속한 여러 노드와 맺은 합의입니다. 데이터를 계속 유지하려면 소진될 때마다 재지불하거나 갱신해야 합니다.
+
+대부분의 경우, 모든 데이터를 온체인으로 저장하는 대신, 체인 상에 데이터가 위치하는 곳의 해시가 저장됩니다. 이렇게 하면 모든 데이터를 유지하기 위해 전체 체인을 확장할 필요가 없습니다.
+
+컨트랙트 기반 지속성을 갖춘 플랫폼:
+
+- [Filecoin](https://docs.filecoin.io/basics/what-is-filecoin)
+- [Skynet](https://sia.tech/)
+- [Storj](https://storj.io/)
+- [Züs](https://zus.network/)
+- [Crust Network](https://crust.network)
+- [Swarm](https://www.ethswarm.org/)
+- [4EVERLAND](https://www.4everland.org/)
+
+### 추가 고려사항 {#additional-consideration}
+
+IPFS는 파일, 웹사이트, 애플리케이션 및 데이터를 저장하고 액세스하기 위한 분산 시스템입니다. 이 시스템은 내장된 인센티브 체계가 없지만, 장기적인 지속성을 위해 위에 언급된 계약 기반 인센티브 솔루션 중 하나와 함께 사용할 수 있습니다. 또 다른 방법으로 IPFS에서 데이터를 지속시키는 방법은 '고정 서비스'와 협력하는 것입니다. 이 서비스는 사용자의 데이터를 "고정"해 줍니다. 사용자는 자신의 IPFS 노드를 실행하여 자신 또는 다른 사람의 데이터를 무료로 지속시킬 수 있습니다!
+
+- [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/)
+- [Pinata](https://www.pinata.cloud/) _(IPFS 피닝 서비스)_
+- [web3.storage](https://web3.storage/) _(IPFS/Filecoin 피닝 서비스)_
+- [Infura](https://infura.io/product/ipfs) _(IPFS 피닝 서비스)_
+- [IPFS Scan](https://ipfs-scan.io) _(IPFS 피닝 탐색기)_
+- [4EVERLAND](https://www.4everland.org/)_（IPFS 피닝 서비스）_
+- [Filebase](https://filebase.com) _(IPFS 피닝 서비스)_
+- [Spheron Network](https://spheron.network/) _(IPFS/Filecoin 피닝 서비스)_
+
+SWARM은 저장 인센티브 시스템과 저장 임대 가격 예측 시스템을 갖춘 분산 데이터 저장 및 배포 기술입니다.
+
+## 데이터 보존 {#data-retention}
+
+데이터를 보존하기 위해, 시스템은 데이터가 확실히 보존되도록 하는 일종의 메커니즘을 가지고 있어야 합니다.
+
+### 챌린지 메커니즘 {#challenge-mechanism}
+
+확실히 데이터가 보존되도록 하는 가장 일반적인 방법 중 하나는, 노드에 전송되는 일종의 암호학적 문제를 사용하여 노드가 데이터를 가지고 있는지 확인하는 것입니다. 간단한 방법은 아르위브의 PoA를 살펴보는 것입니다. 이것은 노드에게 가장 최근 블록과 과거의 랜덤 블록 하나에 있는 데이터가 모두 있는지 확인하는 문제를 냅니다. 만약 노드가 답을 내놓지 못하면, 해당 노드는 불이익을 받습니다.
+
+챌린지 메커니즘을 갖춘 dStorage 유형:
+
+- Züs
+- 스카이넷
+- 아르위브
+- 파일코인
+- Crust Network
+- 4EVERLAND
+
+### 탈중앙성 {#decentrality}
+
+플랫폼의 분산화 수준을 측정할 수 있는 좋은 도구는 없지만, 일반적으로 KYC의 형태가 없는 도구를 사용하여 중앙집중화되지 않았다는 증거를 제시하고자 할 것입니다.
+
+KYC가 없는 탈중앙화 도구:
+
+- 스카이넷
+- 아르위브
+- 파일코인
+- IPFS
+- 이더리움
+- Crust Network
+- 4EVERLAND
+
+### 합의 {#consensus}
+
+이 도구 대부분은 자체 버전의 [합의 메커니즘](/developers/docs/consensus-mechanisms/)을 가지고 있지만, 일반적으로 [**작업 증명(PoW)**](/developers/docs/consensus-mechanisms/pow/) 또는 [**지분 증명(PoS)**](/developers/docs/consensus-mechanisms/pos/)에 기반합니다.
+
+작업 증명 기반:
+
+- 스카이넷
+- 아르위브
+
+지분 증명 기반:
+
+- 이더리움
+- 파일코인
+- Züs
+- Crust Network
+
+## 관련 도구 {#related-tools}
+
+**IPFS - _InterPlanetary File System은 이더리움을 위한 탈중앙화 저장 공간 및 파일 참조 시스템입니다._**
+
+- [Ipfs.io](https://ipfs.io/)
+- [개발문서](https://docs.ipfs.io/)
+- [GitHub](https://github.com/ipfs/ipfs)
+
+**Storj DCS - _개발자를 위한 안전하고, 프라이빗하며, S3와 호환되는 탈중앙화 클라우드 객체 저장 공간입니다._**
+
+- [Storj.io](https://storj.io/)
+- [개발문서](https://docs.storj.io/)
+- [GitHub](https://github.com/storj/storj)
+
+**Sia - _암호학을 활용하여 구매자와 판매자가 직접 거래할 수 있도록 하는 무신뢰 클라우드 저장 공간 마켓플레이스를 만듭니다._**
+
+- [Skynet.net](https://sia.tech/)
+- [개발문서](https://docs.sia.tech/)
+- [GitHub](https://github.com/SiaFoundation/)
+
+**Filecoin - _Filecoin은 IPFS를 개발한 바로 그 팀에서 만들었습니다. IPFS 이상 위에 있는 인센티브 계층입니다._**
+
+- [Filecoin.io](https://filecoin.io/)
+- [개발문서](https://docs.filecoin.io/)
+- [GitHub](https://github.com/filecoin-project/)
+
+**Arweave - _Arweave는 데이터 저장을 위한 dStorage 플랫폼입니다._**
+
+- [Arweave.org](https://www.arweave.org/)
+- [개발문서](https://docs.arweave.org/info/)
+- [Arweave](https://github.com/ArweaveTeam/arweave/)
+
+**Züs - _Züs는 샤딩과 블로버(blobber)를 갖춘 지분 증명 dStorage 플랫폼입니다._**
+
+- [zus.network](https://zus.network/)
+- [개발문서](https://docs.zus.network/zus-docs/)
+- [GitHub](https://github.com/0chain/)
+
+**Crust Network - _Crust는 IPFS 위에 구축된 dStorage 플랫폼입니다._**
+
+- [Crust.network](https://crust.network)
+- [개발문서](https://wiki.crust.network)
+- [GitHub](https://github.com/crustio)
+
+**Swarm - _이더리움 웹3 스택을 위한 분산형 저장 공간 플랫폼 및 콘텐츠 배포 서비스입니다._**
+
+- [EthSwarm.org](https://www.ethswarm.org/)
+- [개발문서](https://docs.ethswarm.org/)
+- [GitHub](https://github.com/ethersphere/)
+
+**OrbitDB - _IPFS 기반의 탈중앙화 P2P 데이터베이스입니다._**
+
+- [OrbitDB.org](https://orbitdb.org/)
+- [개발문서](https://github.com/orbitdb/field-manual/)
+- [GitHub](https://github.com/orbitdb/orbit-db/)
+
+**Aleph.im - _탈중앙화 클라우드 프로젝트(데이터베이스, 파일 저장 공간, 컴퓨팅 및 DID)입니다._** 오프체인과 온체인 P2P 기술의 독특한 조합. IPFS와 멀티체인 양립 가능._\*\*
+
+- [Aleph.im](https://aleph.cloud/)
+- [개발문서](https://docs.aleph.cloud/)
+- [GitHub](https://github.com/aleph-im/)
+
+**Ceramic - _데이터가 풍부하고 흥미로운 애플리케이션을 위한 사용자 제어 IPFS 데이터베이스 저장 공간입니다._**
+
+- [Ceramic.network](https://ceramic.network/)
+- [개발문서](https://developers.ceramic.network/)
+- [GitHub](https://github.com/ceramicnetwork/js-ceramic/)
+
+**Filebase - _S3와 호환되는 탈중앙화 저장 공간 및 지역 중복 IPFS 피닝 서비스. Filebase를 통해 IPFS에 업로드된 모든 파일은 전 세계에 걸쳐 3중으로 복제되어 Filebase 인프라에 자동으로 피닝됩니다._**
+
+- [Filebase.com](https://filebase.com/)
+- [개발문서](https://docs.filebase.com/)
+- [GitHub](https://github.com/filebase)
+
+**4EVERLAND - _저장 공간, 컴퓨팅, 네트워킹 핵심 기능을 통합한 웹3.0 클라우드 컴퓨팅 플랫폼으로, S3와 호환되며 IPFS, Arweave와 같은 탈중앙화 저장 공간 네트워크에서 동기식 데이터 저장을 제공합니다._**
+
+- [4everland.org](https://www.4everland.org/)
+- [개발문서](https://docs.4everland.org/)
+- [GitHub](https://github.com/4everland)
+
+**Kaleido - _클릭 버튼으로 IPFS 노드를 제공하는 서비스형 블록체인(BaaS) 플랫폼입니다._**
+
+- [Kaleido](https://kaleido.io/)
+- [개발문서](https://docs.kaleido.io/kaleido-services/ipfs/)
+- [GitHub](https://github.com/kaleido-io)
+
+**Spheron Network - _Spheron은 최고의 성능을 갖춘 탈중앙화 인프라에서 애플리케이션을 출시하려는 탈중앙화앱을 위해 설계된 서비스형 플랫폼(PaaS)입니다. 컴퓨팅, 탈중앙화 저장 공간, CDN 및 웹 호스팅을 기본으로 제공합니다._**
+
+- [spheron.network](https://spheron.network/)
+- [개발문서](https://docs.spheron.network/)
+- [GitHub](https://github.com/spheronFdn)
+
+## 더 읽어보기 {#further-reading}
+
+- [탈중앙화 저장 공간이란?](https://coinmarketcap.com/academy/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_
+- [탈중앙화 저장 공간에 대한 5가지 일반적인 오해 바로잡기](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
+
+## 관련 주제 {#related-topics}
+
+- [개발 프레임워크](/developers/docs/frameworks/)
diff --git a/public/content/translations/ko/developers/docs/transactions/index.md b/public/content/translations/ko/developers/docs/transactions/index.md
new file mode 100644
index 00000000000..0d6be0ae39d
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/transactions/index.md
@@ -0,0 +1,231 @@
+---
+title: "트랜잭션"
+description: "이더리움 트랜잭션의 개요 - 어떻게 동작하는지, 데이터 구조, 그리고 애플리케이션을 통해 어떻게 전송되는지"
+lang: ko
+---
+
+트랜잭션은 계정으로부터 암호학적으로 서명된 명령들이다. 계정은 이더리움 네트워크의 상태를 업데이트하기 위해 트랜잭션을 초기화 할 것이다. 가장 간단한 트랜잭션은 한 계정에서 다른 계정으로 ETH를 보내는 것이다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해할 수 있도록 [계정](/developers/docs/accounts/) 및 [이더리움 소개](/developers/docs/intro-to-ethereum/)를 먼저 읽어보시는 것을 권장합니다.
+
+## 트랜잭션이란 무엇인가? 트랜잭션이란 무엇인가요? {#whats-a-transaction}
+
+이더리움 트랜잭션은 외부 계정, 즉 컨트랙트가 아니라 사람이 관리하는 계정에 의해 초기화된 하나의 동작을 말한다. 예를 들어, 밥이 앨리스에게 1 ETH를 보낸다면, 밥의 계정은 인출되어야 하고, 앨리스의 것은 입금되어야 한다. 이 상태-변경 동작은 트랜잭션 안에서 이루어진다.
+
+
+_[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)에서 발췌한 다이어그램_
+
+EVM의 상태를 변경하는 트랜잭션은 전체 네트워크로 브로드캐스트되어야 한다. 어떤 노드든 EVM 위에서 실행되는 트랜잭션을 위한 요청을 브로드캐스트 할 수 있다. 이 과정을 거치고나서, 검증자는 트랜잭션을 실행하고 상태변경 결과를 나머지 네트워크로 전파한다.
+
+트랜잭션은 수수료가 필요하고 검증된 블록에 포함되어 있어야한다. 이 개요를 더 간단히 하기 위해서 우리는 다른곳에서 가스 수수료와 검증에 대해서 다룰 것이다.
+
+제출된 트랜잭션은 다음 정보를 갖는다.
+
+- `from` – 트랜잭션에 서명할 보내는 사람의 주소입니다. 컨트랙트 계정은 트랜잭션을 보낼 수 없기 때문에 외부계정에만 존재한다
+- `to` – 받는 주소(외부 소유 계정인 경우, 트랜잭션이 값을 전송합니다). 컨트랙트 계정이라면 트랜잭션은 컨트랙트 코드를 실행할 것이다)
+- `signature` – 보내는 사람의 식별자입니다. 이것은 송신자의 개인 키로 트랜잭션을 서명하고 송신자가 트랜잭션을 인증함을 확정하면 생성된다.
+- `nonce` - 계정의 트랜잭션 수를 나타내는 순차적으로 증가하는 카운터입니다.
+- `value` – 보내는 사람에서 받는 사람으로 전송할 ETH 금액(WEI 단위이며, 1ETH는 1e+18wei와 같습니다).
+- `input data` – 임의의 데이터를 포함하기 위한 선택적 필드입니다.
+- `gasLimit` – 트랜잭션이 소비할 수 있는 가스 단위의 최대량입니다. [EVM](/developers/docs/evm/opcodes)은 각 계산 단계에 필요한 가스 단위를 명시합니다.
+- `maxPriorityFeePerGas` - 검증인에게 팁으로 포함될 소비된 가스의 최대 가격입니다.
+- `maxFeePerGas` - 트랜잭션에 대해 지불하고자 하는 가스 단위당 최대 수수료(`baseFeePerGas` 및 `maxPriorityFeePerGas` 포함)입니다.
+
+가스는 채굴자에 의해 트랜잭션을 처리하는데 필요한 컴퓨팅 계산에 대한 참조이다. 사용자들은 이 컴퓨팅에 수수료를 지불해야 한다. `gasLimit`과 `maxPriorityFeePerGas`는 검증인에게 지불되는 최대 트랜잭션 수수료를 결정합니다. [가스에 대한 자세한 정보](/developers/docs/gas/).
+
+트랜잭션 객체는 아래처럼 보일 것이다.
+
+```js
+{
+ from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
+ to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
+ gasLimit: "21000",
+ maxFeePerGas: "300",
+ maxPriorityFeePerGas: "10",
+ nonce: "0",
+ value: "10000000000"
+}
+```
+
+그러나 트랜잭션 객체는 송신자의 개인 키를 사용해서 서명되어야 한다. 이는 그 트랜잭션이 그 송신자로부터만 왔고, 부정하게 보내지지 않았음을 증명한다.
+
+Geth 같은 이더리움 클라이언트가 이 서명 과정을 처리할 것이다.
+
+[JSON-RPC](/developers/docs/apis/json-rpc) 호출 예시:
+
+```json
+{
+ "id": 2,
+ "jsonrpc": "2.0",
+ "method": "account_signTransaction",
+ "params": [
+ {
+ "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
+ "gas": "0x55555",
+ "maxFeePerGas": "0x1234",
+ "maxPriorityFeePerGas": "0x1234",
+ "input": "0xabcd",
+ "nonce": "0x0",
+ "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
+ "value": "0x1234"
+ }
+ ]
+}
+```
+
+예시 응답:
+
+```json
+{
+ "jsonrpc": "2.0",
+ "id": 2,
+ "result": {
+ "raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
+ "tx": {
+ "nonce": "0x0",
+ "maxFeePerGas": "0x1234",
+ "maxPriorityFeePerGas": "0x1234",
+ "gas": "0x55555",
+ "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
+ "value": "0x1234",
+ "input": "0xabcd",
+ "v": "0x26",
+ "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e",
+ "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
+ "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e"
+ }
+ }
+}
+```
+
+- `raw`는 [RLP(Recursive Length Prefix)](/developers/docs/data-structures-and-encoding/rlp)로 인코딩된 서명된 트랜잭션입니다.
+- `tx`는 JSON 형식의 서명된 트랜잭션입니다.
+
+해시를 서명함으로써, 트랜잭션이 네트워크로부터 제출되었음과 송신자로부터 왔음을 암호학적으로 입증할 수 있다.
+
+### 데이터 필드 {#the-data-field}
+
+대부분의 트랜잭션은 외부 소유 계정의 컨트랙트를 액세스한다.
+대부분의 컨트랙트는 솔리디티(Solidity)로 작성되며, [ABI(애플리케이션 바이너리 인터페이스)](/glossary/#abi)에 따라 데이터 필드를 해석합니다.
+
+처음 4 바이트는 함수 이름과 arguments의 해시를 사용하여 호출할 함수를 명시합니다.
+[이 데이터베이스](https://www.4byte.directory/signatures/)를 사용하여 셀렉터로부터 함수를 식별할 수 있습니다.
+
+나머지 calldata는 인자이며, [ABI 사양에 명시된 대로 인코딩됩니다](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding).
+
+예를 들어, [이 트랜잭션](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1)을 살펴보겠습니다.
+calldata를 보려면 Click to see More를 사용하세요.
+
+함수 셀렉터는 `0xa9059cbb`입니다. [이 서명을 가진 여러 알려진 함수](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb)가 있습니다.
+이 경우 [컨트랙트 소스 코드](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code)가 Etherscan에 업로드되었으므로 함수가 `transfer(address,uint256)`임을 알 수 있습니다.
+
+나머지 데이터는:
+
+```
+0000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279
+000000000000000000000000000000000000000000000000000000003b0559f4
+```
+
+ABI 명세서에 따르면, 정수값 (예를 들어 20바이트 정수인 주소) 은 ABI에서 앞에 0이 추가된 32 바이트 단어로 표시된다.
+따라서 `to` 주소는 [`4f6742badb049791cd9a37ea913f2bac38d01279`](https://etherscan.io/address/0x4f6742badb049791cd9a37ea913f2bac38d01279)임을 알 수 있습니다.
+`value`는 0x3b0559f4 = 990206452입니다.
+
+## 트랜잭션 유형 {#types-of-transactions}
+
+이더리움에서는 다른 몇가지 다른 유형의 트랜잭션이 있다.
+
+- 보통의 트랜잭션: 한 계정에서 다른 계정으로의 트랜잭션
+- Contract deployment transactions: 'to' address 가 없는 트랜잭션으로, 데이터 필드가 컨트랙트 코드로 사용된다.
+- 컨트랙트의 실행: 배포된 스마트 컨트랙트와 상호작용하는 트랜잭션이다. 이 경우, 'to' 주소는 스마트 컨트랙트의 주소이다.
+
+### 가스에 대하여 {#on-gas}
+
+앞서 언급했듯이 트랜잭션을 실행하려면 [가스](/developers/docs/gas/)가 필요합니다. 간단한 전송 트랜잭션은 21000 단위의 가스가 필요하다.
+
+따라서 밥이 앨리스에게 `baseFeePerGas` 190gwei와 `maxPriorityFeePerGas` 10gwei로 1ETH를 보내려면, 밥은 다음 수수료를 지불해야 합니다:
+
+```
+(190 + 10) * 21000 = 4,200,000 gwei
+--또는--
+0.0042 ETH
+```
+
+밥의 계정에서 -1.0042 ETH가 인출됩니다(앨리스에게 1 ETH + 가스 수수료 0.0042 ETH).
+
+앨리스의 계정에 +1.0 ETH가 입금됩니다.
+
+-0.00399 ETH의 기본 수수료는 소각됩니다.
+
+검증인은 팁으로 +0.000210 ETH를 받습니다.
+
+
+_[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)에서 발췌한 다이어그램_
+
+트랜잭션 내에서 사용되지 않은 가스는 사용자 계정으로 환불된다.
+
+### 스마트 계약 상호작용 {#smart-contract-interactions}
+
+스마트 계약과 관련된 모든 트랜잭션에는 가스가 필요합니다.
+
+스마트 계약에는 컨트랙트의 상태를 변경하지 않는 [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) 또는 [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions) 함수로 알려진 함수가 포함될 수도 있습니다. 따라서 EOA에서 이러한 함수를 호출할 때 가스가 필요하지 않습니다. 이 시나리오의 기본 RPC 호출은 [`eth_call`](/developers/docs/apis/json-rpc#eth_call)입니다.
+
+`eth_call`을 사용하여 액세스할 때와 달리, 이러한 `view` 또는 `pure` 함수는 내부적으로(즉, 컨트랙트 자체 또는 다른 컨트랙트에서) 호출될 때도 가스를 소모합니다.
+
+## 트랜잭션 생명주기 {#transaction-lifecycle}
+
+트랜잭션이 제출되면 다음이 일어난다.
+
+1. 트랜잭션 해시는 암호화 방식으로 생성됩니다:
+ `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017`
+2. 트랜잭션은 네트워크로 브로드캐스트 되고 다른 모든 보류 중인 네트워크 트랜잭션으로 구성된 트랜잭션 풀에 추가됩니다.
+3. 검증인은 트랜잭션을를 입증하고 성공적이라고 처리하기 위해 트랜잭션을 선택하고 이를 블록에 포함해야 한다.
+4. 시간이 지날 수록 블록에 포함된 당신의 트랜잭션은 "justified" 에서 "finalized"로 업그레이드 될 것이다. 이러한 업그레이드를 통해 트랜잭션이 성공적으로 완료되고 절대 변경되지 않을 것이라고 훨씬 더 확신할 수 있습니다. 블록이 "완료(finalized)"되면 수십억 달러의 비용이 드는 네트워크 수준의 공격에 의해서만 변경될 수 있습니다.
+
+## 시각적 데모 {#a-visual-demo}
+
+오스틴의 트랜잭션, 가스, 그리고 채굴에 대한 안내를 보라.
+
+참고: 이더리움은 고정 크기 값('해시')을 생성하기 위해 해시 함수를 정기적으로 사용합니다. 해시는 이더리움에서 중요한 역할을 하지만, 지금은 고유 ID라고 생각해도 무방합니다.
+
+
+
+_블록체인은 본질적으로 각 블록이 이전 블록을 참조하는 연결 리스트입니다._
+
+이 데이터 구조는 새로운 것이 아니지만, 네트워크를 관장하는 규칙(즉, P2P 프로토콜)은 새롭습니다. 중앙 기관이 없습니다. 피어들의 네트워크는 네트워크를 유지하기 위해 협력해야 하며, 다음 블록에 어떤 트랜잭션을 포함할지 결정하기 위해 경쟁해야 합니다. 따라서 친구에게 돈을 보내려면 해당 트랜잭션을 네트워크에 브로드캐스트한 다음, 다가오는 블록에 포함될 때까지 기다려야 합니다.
+
+블록체인이 한 사용자에게서 다른 사용자에게로 돈이 실제로 전송되었는지 확인하는 유일한 방법은 해당 블록체인 고유의(즉, 해당 블록체인에 의해 생성 및 관리되는) 통화를 사용하는 것입니다. 이더리움에서 이 통화는 이더(ether)라고 하며, 이더리움 블록체인에는 계정 잔액에 대한 유일한 공식 기록이 포함되어 있습니다.
+
+## 새로운 패러다임 {#a-new-paradigm}
+
+이 새로운 탈중앙화 기술 스택은 새로운 개발자 도구를 탄생시켰습니다. 이러한 도구는 많은 프로그래밍 언어에 존재하지만, 우리는 Python의 관점에서 살펴보겠습니다. 다시 한번 강조하지만, Python이 선호하는 언어가 아니더라도 따라가는 데 큰 어려움은 없을 것입니다.
+
+이더리움과 상호 작용하려는 Python 개발자는 [Web3.py](https://web3py.readthedocs.io/)를 사용할 가능성이 높습니다. Web3.py는 이더리움 노드에 연결하고 데이터를 주고받는 방식을 크게 단순화하는 라이브러리입니다.
+
+참고: '이더리움 노드'와 '이더리움 클라이언트'는 같은 의미로 사용됩니다. 두 경우 모두 이더리움 네트워크 참여자가 실행하는 소프트웨어를 의미합니다. 이 소프트웨어는 블록 데이터를 읽고, 새로운 블록이 체인에 추가될 때 업데이트를 수신하고, 새로운 트랜잭션을 브로드캐스트하는 등 다양한 작업을 수행할 수 있습니다. 기술적으로, 클라이언트는 소프트웨어이고, 노드는 소프트웨어를 실행하는 컴퓨터입니다.
+
+[이더리움 클라이언트](/developers/docs/nodes-and-clients/)는 [IPC](https://wikipedia.org/wiki/Inter-process_communication), HTTP 또는 웹소켓으로 연결할 수 있도록 구성할 수 있으므로, Web3.py도 이 구성을 미러링해야 합니다. Web3.py는 이러한 연결 옵션을 공급자(providers)라고 부릅니다. Web3.py 인스턴스를 노드에 연결하려면 세 가지 공급자 중 하나를 선택해야 합니다.
+
+
+
+_이더리움 노드와 Web3.py가 동일한 프로토콜(예: 이 다이어그램의 IPC)을 통해 통신하도록 구성하세요._
+
+Web3.py가 제대로 구성되면 블록체인과 상호 작용을 시작할 수 있습니다. 앞으로 나올 내용에 대한 미리보기로 Web3.py 사용 예시 몇 가지를 소개합니다.
+
+```python
+# 블록 데이터 읽기:
+w3.eth.get_block('latest')
+
+# 트랜잭션 전송:
+w3.eth.send_transaction({'from': ..., 'to': ..., 'value': ...})
+```
+
+## 설치 {#installation}
+
+이번 연습에서는 Python 인터프리터 내에서만 작업할 것입니다. 디렉터리, 파일, 클래스, 함수 등은 생성하지 않습니다.
+
+참고: 아래 예제에서 `$`로 시작하는 명령어는 터미널에서 실행되도록 의도된 것입니다. (`$`는 입력하지 마세요. 줄의 시작을 의미할 뿐입니다.)
+
+먼저, 탐색하기 쉬운 사용자 친화적 환경을 위해 [IPython](https://ipython.org/)을 설치하세요. IPython은 다른 기능들 중에서도 탭 완성 기능을 제공하여 Web3.py 내에서 무엇이 가능한지 훨씬 쉽게 확인할 수 있도록 해줍니다.
+
+```bash
+pip install ipython
+```
+
+Web3.py는 `web3`라는 이름으로 배포됩니다. 다음과 같이 설치하세요.
+
+```bash
+pip install web3
+```
+
+한 가지 더 말씀드리자면, 나중에 블록체인을 시뮬레이션할 건데, 몇 가지 의존성이 더 필요합니다. 다음을 통해 설치할 수 있습니다.
+
+```bash
+pip install 'web3[tester]'
+```
+
+이제 모든 준비가 끝났습니다!
+
+참고: `web3[tester]` 패키지는 Python 3.10.xx 버전까지 작동합니다.
+
+## 샌드박스 실행하기 {#spin-up-a-sandbox}
+
+터미널에서 `ipython`을 실행하여 새로운 Python 환경을 엽니다. 이는 `python`을 실행하는 것과 비슷하지만, 더 많은 부가 기능을 제공합니다.
+
+```bash
+ipython
+```
+
+실행 중인 Python 및 IPython 버전에 대한 정보가 출력된 후, 입력을 기다리는 프롬프트가 표시됩니다.
+
+```python
+In [1]:
+```
+
+지금 대화형 Python 셸을 보고 계십니다. 기본적으로, 마음껏 테스트해볼 수 있는 샌드박스입니다. 여기까지 오셨다면 이제 Web3.py를 가져올 차례입니다.
+
+```python
+In [1]: from web3 import Web3
+```
+
+## Web3 모듈 소개 {#introducing-the-web3-module}
+
+[Web3](https://web3py.readthedocs.io/en/stable/overview.html#base-api) 모듈은 이더리움으로 가는 관문일 뿐만 아니라 몇 가지 편의 함수를 제공합니다. 몇 가지를 살펴보겠습니다.
+
+이더리움 애플리케이션에서는 보통 통화 단위를 변환해야 합니다. Web3 모듈은 바로 이 작업을 위한 몇 가지 헬퍼 메서드를 제공합니다. 바로 [from_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.from_wei)와 [to_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.to_wei)입니다.
+
+
+참고: 컴퓨터는 소수점 연산을 잘 처리하지 못하는 것으로 악명 높습니다. 이 문제를 해결하기 위해 개발자들은 종종 달러 금액을 센트 단위로 저장합니다. 예를 들어, 가격이 $5.99인 품목은 데이터베이스에 599로 저장될 수 있습니다.
+
+이더로 트랜잭션을 처리할 때도 비슷한 패턴이 사용됩니다. 하지만 이더는 소수점 두 자리 대신 18자리를 가집니다! 이더의 가장 작은 단위는 wei라고 하며, 트랜잭션을 보낼 때 지정하는 값이 바로 이것입니다.
+
+1 이더 = 1,000,000,000,000,000,000 wei
+
+1 wei = 0.000000000000000001 이더
+
+
+
+몇 가지 값을 wei와 주고받으며 변환해 보세요. 이더와 wei 사이에는 [많은 단위에 대한 이름이 있다](https://web3py.readthedocs.io/en/stable/troubleshooting.html#how-do-i-convert-currency-denominations)는 점에 유의하세요. 그중 더 잘 알려진 단위 중 하나는 gwei인데, 거래 수수료가 종종 이 단위로 표시되기 때문입니다.
+
+```python
+In [2]: Web3.to_wei(1, 'ether')
+Out[2]: 1000000000000000000
+
+In [3]: Web3.from_wei(500000000, 'gwei')
+Out[3]: Decimal('0.5')
+```
+
+Web3 모듈의 다른 유틸리티 메서드에는 데이터 형식 변환기(예: [`toHex`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.toHex)), 주소 헬퍼(예: [`isAddress`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.isAddress)), 해시 함수(예: [`keccak`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.keccak))가 포함됩니다. 이들 중 상당수는 시리즈의 뒷부분에서 다룰 것입니다. 사용 가능한 모든 메서드와 속성을 보려면, `Web3.`을 입력하고 IPython의 자동 완성 기능을 활용하세요. 마침표 뒤에 탭 키를 두 번 누르세요.
+
+## 체인과 소통하기 {#talk-to-the-chain}
+
+편리한 메서드들도 좋지만, 이제 블록체인으로 넘어가 봅시다. 다음 단계는 이더리움 노드와 통신하도록 Web3.py를 구성하는 것입니다. 여기서는 IPC, HTTP 또는 웹소켓 공급자를 사용할 수 있습니다.
+
+우리는 이 경로를 따르지는 않겠지만, HTTP 공급자를 사용하는 전체 워크플로의 예는 다음과 같을 수 있습니다.
+
+- 이더리움 노드, 예: [Geth](https://geth.ethereum.org/)를 다운로드합니다.
+- 한 터미널 창에서 Geth를 시작하고 네트워크와 동기화될 때까지 기다립니다. 기본 HTTP 포트는 `8545`이지만, 구성할 수 있습니다.
+- Web3.py에 `localhost:8545`에서 HTTP를 통해 노드에 연결하도록 지시합니다.
+ `w3 = Web3(Web3.HTTPProvider('http://127.0.0.1:8545'))`
+- `w3` 인스턴스를 사용하여 노드와 상호 작용합니다.
+
+이것이 '실제' 방법 중 하나이긴 하지만, 동기화 과정은 몇 시간이 걸리며 단순히 개발 환경을 원하는 경우에는 불필요합니다. Web3.py는 이러한 목적을 위해 네 번째 공급자인 EthereumTesterProvider를 제공합니다. 이 테스터 공급자는 완화된 권한과 테스트용 가짜 통화를 가진 시뮬레이션된 이더리움 노드에 연결됩니다.
+
+
+
+_EthereumTesterProvider는 시뮬레이션된 노드에 연결되며 빠른 개발 환경에 유용합니다._
+
+그 시뮬레이션된 노드는 [eth-tester](https://github.com/ethereum/eth-tester)라고 불리며, `pip install web3[tester]` 명령의 일부로 설치했습니다. 이 테스터 공급자를 사용하도록 Web3.py를 구성하는 것은 다음과 같이 간단합니다.
+
+```python
+In [4]: w3 = Web3(Web3.EthereumTesterProvider())
+```
+
+이제 체인을 서핑할 준비가 되었습니다! 사람들이 그렇게 말하지는 않아요. 방금 제가 지어낸 말입니다. 간단히 둘러봅시다.
+
+## 간단한 둘러보기 {#the-quick-tour}
+
+가장 먼저, 간단한 확인부터 해보겠습니다.
+
+```python
+In [5]: w3.is_connected()
+Out[5]: True
+```
+
+테스터 공급자를 사용하고 있기 때문에 이것이 그다지 가치 있는 테스트는 아니지만, 만약 실패한다면 `w3` 변수를 인스턴스화할 때 무언가를 잘못 입력했을 가능성이 있습니다. 내부 괄호, 즉 `Web3.EthereumTesterProvider()`를 포함했는지 다시 확인하세요.
+
+## 둘러보기 #1: [계정](/developers/docs/accounts/) {#tour-stop-1-accounts}
+
+편의를 위해, 테스터 공급자는 몇 개의 계정을 생성하고 테스트 이더를 미리 채워 넣었습니다.
+
+먼저, 해당 계정들의 목록을 살펴보겠습니다.
+
+```python
+In [6]: w3.eth.accounts
+Out[6]: ['0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf',
+ '0x2B5AD5c4795c026514f8317c7a215E218DcCD6cF',
+ '0x6813Eb9362372EEF6200f3b1dbC3f819671cBA69', ...]
+```
+
+이 명령을 실행하면 `0x`로 시작하는 10개의 문자열 목록이 표시됩니다. 각각은 공개 주소이며, 어떤 면에서는 은행 계좌의 계좌 번호와 유사합니다. 이더를 보내려는 사람에게 이 주소를 제공하면 됩니다.
+
+언급했듯이, 테스터 공급자는 이러한 각 계정에 일부 테스트 이더를 미리 로드해 두었습니다. 첫 번째 계정에 얼마가 있는지 알아봅시다.
+
+```python
+In [7]: w3.eth.get_balance(w3.eth.accounts[0])
+Out[7]: 1000000000000000000000000
+```
+
+0이 정말 많네요! 가짜 은행으로 달려가기 전에, 앞에서 배운 통화 단위에 대한 교훈을 떠올려 보세요. 이더 값은 가장 작은 단위인 wei로 표시됩니다. 이 값을 이더로 변환해 보세요.
+
+```python
+In [8]: w3.from_wei(1000000000000000000000000, 'ether')
+Out[8]: Decimal('1000000')
+```
+
+백만 테스트 이더, 여전히 나쁘지 않네요.
+
+## 둘러보기 #2: 블록 데이터 {#tour-stop-2-block-data}
+
+이 시뮬레이션된 블록체인의 상태를 살짝 들여다봅시다.
+
+```python
+In [9]: w3.eth.get_block('latest')
+Out[9]: AttributeDict({
+ 'number': 0,
+ 'hash': HexBytes('0x9469878...'),
+ 'parentHash': HexBytes('0x0000000...'),
+ ...
+ 'transactions': []
+})
+```
+
+블록에 대해 많은 정보가 반환되지만, 여기서 몇 가지만 짚고 넘어가겠습니다.
+
+- 블록 번호는 0입니다. 테스터 제공자를 얼마나 오래 전에 구성했는지는 중요하지 않습니다. 약 12초마다 새 블록을 추가하는 실제 이더리움 네트워크와 달리, 이 시뮬레이션은 어떤 작업을 지시할 때까지 기다립니다.
+- `transactions`는 빈 목록입니다. 같은 이유로, 우리는 아직 아무것도 하지 않았습니다. 이 첫 번째 블록은 체인을 시작하기 위한 빈 블록입니다.
+- `parentHash`가 단지 빈 바이트들의 묶음이라는 점을 주목하세요. 이는 이 블록이 체인의 첫 번째 블록, 즉 제네시스 블록임을 의미합니다.
+
+## 둘러보기 #3: [트랜잭션](/developers/docs/transactions/) {#tour-stop-3-transactions}
+
+보류 중인 트랜잭션이 있을 때까지 블록 0에 갇혀 있으니, 하나 만들어 봅시다. 한 계정에서 다른 계정으로 몇 개의 테스트 이더를 보내세요.
+
+```python
+In [10]: tx_hash = w3.eth.send_transaction({
+ 'from': w3.eth.accounts[0],
+ 'to': w3.eth.accounts[1],
+ 'value': w3.to_wei(3, 'ether'),
+ 'gas': 21000
+})
+```
+
+일반적으로 이 시점에서 트랜잭션이 새 블록에 포함될 때까지 몇 초간 기다려야 합니다. 전체 과정은 다음과 같습니다.
+
+1. 트랜잭션을 제출하고 트랜잭션 해시를 보관합니다. 트랜잭션을 포함하는 블록이 생성되고 브로드캐스트될 때까지 트랜잭션은 '보류 중(pending)' 상태입니다.
+ `tx_hash = w3.eth.send_transaction({ … })`
+2. 트랜잭션이 블록에 포함될 때까지 기다립니다:
+ `w3.eth.wait_for_transaction_receipt(tx_hash)`
+3. 애플리케이션 로직을 계속 진행합니다. 성공적인 트랜잭션을 보려면:
+ `w3.eth.get_transaction(tx_hash)`
+
+우리의 시뮬레이션 환경은 트랜잭션을 즉시 새 블록에 추가하므로, 트랜잭션을 바로 볼 수 있습니다.
+
+```python
+In [11]: w3.eth.get_transaction(tx_hash)
+Out[11]: AttributeDict({
+ 'hash': HexBytes('0x15e9fb95dc39...'),
+ 'blockNumber': 1,
+ 'transactionIndex': 0,
+ 'from': '0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf',
+ 'to': '0x2B5AD5c4795c026514f8317c7a215E218DcCD6cF',
+ 'value': 3000000000000000000,
+ ...
+})
+```
+
+여기서 익숙한 세부 정보들을 볼 수 있습니다. `from`, `to`, `value` 필드는 `send_transaction` 호출의 입력값과 일치해야 합니다. 또 다른 안심할 수 있는 점은 이 트랜잭션이 블록 번호 1 내의 첫 번째 트랜잭션(`'transactionIndex': 0`)으로 포함되었다는 것입니다.
+
+관련된 두 계정의 잔액을 확인하여 이 거래의 성공 여부를 쉽게 확인할 수도 있습니다. 3 이더가 한 계정에서 다른 계정으로 이동했어야 합니다.
+
+```python
+In [12]: w3.eth.get_balance(w3.eth.accounts[0])
+Out[12]: 999996999979000000000000
+
+In [13]: w3.eth.get_balance(w3.eth.accounts[1])
+Out[13]: 1000003000000000000000000
+```
+
+두 번째 것은 좋아 보입니다! 잔액이 1,000,000 이더에서 1,000,003 이더로 증가했습니다. 그런데 첫 번째 계정은 어떻게 된 걸까요? 3 이더보다 약간 더 많이 잃은 것처럼 보입니다. 아쉽게도, 인생에 공짜는 없으며 이더리움 퍼블릭 네트워크를 사용하려면 동료들의 지원 역할에 대해 보상해야 합니다. 트랜잭션을 제출한 계정에서 소액의 거래 수수료가 차감되었습니다. 이 수수료는 소모된 가스량(ETH 전송의 경우 21,000 가스 단위)에 네트워크 활동량에 따라 달라지는 기본 수수료를 곱한 값과, 트랜잭션을 블록에 포함하는 검증자에게 가는 팁을 더한 금액입니다.
+
+[가스](/developers/docs/gas/#post-london)에 대해 더 알아보기
+
+참고: 퍼블릭 네트워크에서 거래 수수료는 네트워크 수요와 트랜잭션 처리 속도에 따라 변동됩니다. 수수료 계산 방식에 대한 자세한 내용이 궁금하다면, 이전에 작성한 '트랜잭션이 블록에 포함되는 방법'에 대한 게시물을 참조하세요.
+
+## 그리고 숨 고르기 {#and-breathe}
+
+꽤 오랫동안 달려왔으니, 이쯤에서 잠시 쉬어가는 것이 좋겠습니다. 토끼굴은 계속 이어지며, 이 시리즈의 2부에서 계속 탐험할 것입니다. 앞으로 다룰 개념: 실제 노드에 연결하기, 스마트 계약, 그리고 토큰. 궁금한 점이 있으신가요? 알려주세요! 여러분의 피드백은 앞으로의 방향에 영향을 미칠 것입니다. 요청은 [트위터](https://twitter.com/wolovim)를 통해 환영합니다.
diff --git a/public/content/translations/ko/developers/tutorials/ai-trading-agent/index.md b/public/content/translations/ko/developers/tutorials/ai-trading-agent/index.md
new file mode 100644
index 00000000000..bf4d7dcb6c7
--- /dev/null
+++ b/public/content/translations/ko/developers/tutorials/ai-trading-agent/index.md
@@ -0,0 +1,980 @@
+---
+title: "이더리움에서 자신만의 AI 트레이딩 에이전트 만들기"
+description: "이 튜토리얼에서는 간단한 AI 트레이딩 에이전트를 만드는 방법을 배웁니다. 이 에이전트는 블록체인에서 정보를 읽고, 해당 정보를 기반으로 LLM에 추천을 요청하고, LLM이 추천하는 교환을 수행한 후, 대기하고 반복합니다."
+author: Ori Pomerantz
+tags: [ "AI", "트레이딩", "에이전트", "python" ]
+skill: intermediate
+published: 2026-02-13
+lang: ko
+sidebarDepth: 3
+---
+
+이 튜토리얼에서는 간단한 AI 트레이딩 에이전트를 구축하는 방법을 배웁니다. 이 에이전트는 다음 단계를 사용하여 작동합니다.
+
+1. 토큰의 현재 및 과거 가격과 기타 잠재적으로 관련 있는 정보를 읽습니다.
+2. 이 정보와 함께 그 관련성을 설명하는 배경 정보로 쿼리를 작성합니다.
+3. 쿼리를 제출하고 예상 가격을 받습니다.
+4. 추천에 따라 교환합니다.
+5. 대기하고 반복합니다.
+
+이 에이전트는 정보를 읽고, 사용 가능한 답변을 생성하는 쿼리로 변환하고, 해당 답변을 사용하는 방법을 보여줍니다. 이 모든 단계는 AI 에이전트에 필요합니다. 이 에이전트는 Python으로 구현되었습니다. Python이 AI에서 가장 일반적으로 사용되는 언어이기 때문입니다.
+
+## 왜 이렇게 해야 할까요? {#why-do-this}
+
+자동화된 트레이딩 에이전트는 개발자가 트레이딩 전략을 선택하고 실행할 수 있도록 합니다. [AI 에이전트](/ai-agents)는 개발자가 사용을 고려조차 하지 않았던 정보와 알고리즘을 잠재적으로 사용하여 더 복잡하고 동적인 트레이딩 전략을 가능하게 합니다.
+
+## 도구 {#tools}
+
+이 튜토리얼은 시세 조회 및 트레이딩을 위해 [Python](https://www.python.org/), [Web3 라이브러리](https://web3py.readthedocs.io/en/stable/), [Uniswap v3](https://github.com/Uniswap/v3-periphery)를 사용합니다.
+
+### 왜 Python인가요? {#python}
+
+AI에 가장 널리 사용되는 언어는 [Python](https://www.python.org/)이므로 여기서도 사용합니다. Python을 모르더라도 걱정하지 마세요. 언어가 매우 명확하며, 무엇을 하는지 정확히 설명해 드리겠습니다.
+
+[Web3 라이브러리](https://web3py.readthedocs.io/en/stable/)는 가장 일반적인 Python 이더리움 API입니다. 사용하기가 매우 쉽습니다.
+
+### 블록체인에서 트레이딩하기 {#trading-on-blockchain}
+
+이더리움에서 토큰을 교환할 수 있는 [많은 분산형 거래소(DEX)](/apps/categories/defi/)가 있습니다. 하지만 [차익거래](/developers/docs/smart-contracts/composability/#better-user-experience) 때문에 환율은 비슷한 경향이 있습니다.
+
+[Uniswap](https://app.uniswap.org/)은 널리 사용되는 DEX이며, 시세 조회(토큰 상대 가치 확인)와 교환 모두에 사용할 수 있습니다.
+
+### OpenAI {#openai}
+
+대규모 언어 모델의 경우, [OpenAI](https://openai.com/)로 시작하기로 했습니다. 이 튜토리얼의 애플리케이션을 실행하려면 API 액세스 비용을 지불해야 합니다. 최소 결제 금액인 5달러는 충분하고도 남습니다.
+
+## 단계별 개발 {#step-by-step}
+
+개발을 단순화하기 위해 단계별로 진행합니다. 각 단계는 GitHub의 브랜치입니다.
+
+### 시작하기 {#getting-started}
+
+UNIX 또는 Linux([WSL](https://learn.microsoft.com/en-us/windows/wsl/install) 포함)에서 시작하는 단계가 있습니다.
+
+1. 아직 설치하지 않았다면 [Python](https://www.python.org/downloads/)을 다운로드하여 설치하세요.
+
+2. GitHub 리포지토리를 복제합니다.
+
+ ```sh
+ git clone https://github.com/qbzzt/260215-ai-agent.git -b 01-getting-started
+ cd 260215-ai-agent
+ ```
+
+3. [`uv`](https://docs.astral.sh/uv/getting-started/installation/)를 설치합니다. 시스템에 따라 명령어가 다를 수 있습니다.
+
+ ```sh
+ pipx install uv
+ ```
+
+4. 라이브러리를 다운로드합니다.
+
+ ```sh
+ uv sync
+ ```
+
+5. 가상 환경을 활성화합니다.
+
+ ```sh
+ source .venv/bin/activate
+ ```
+
+6. Python과 Web3가 올바르게 작동하는지 확인하려면 `python3`을 실행하고 이 프로그램을 제공하세요. `>>>` 프롬프트에 입력할 수 있으며 파일을 만들 필요는 없습니다.
+
+ ```python
+ from web3 import Web3
+ MAINNET_URL = "https://eth.drpc.org"
+ w3 = Web3(Web3.HTTPProvider(MAINNET_URL))
+ w3.eth.block_number
+ quit()
+ ```
+
+### 블록체인에서 읽기 {#read-blockchain}
+
+다음 단계는 블록체인에서 읽는 것입니다. 그렇게 하려면 `02-read-quote` 브랜치로 변경한 다음 `uv`를 사용하여 프로그램을 실행해야 합니다.
+
+```sh
+git checkout 02-read-quote
+uv run agent.py
+```
+
+타임스탬프, 가격, 자산(현재는 항상 `WETH/USDC`)을 포함하는 `Quote` 객체 목록을 받게 됩니다.
+
+다음은 한 줄씩 설명한 것입니다.
+
+```python
+from web3 import Web3
+from web3.contract import Contract
+from decimal import Decimal, ROUND_HALF_UP
+from dataclasses import dataclass
+from datetime import datetime, timezone
+from pprint import pprint
+import time
+import functools
+import sys
+```
+
+필요한 라이브러리를 가져옵니다. 사용 시 아래에 설명되어 있습니다.
+
+```python
+print = functools.partial(print, flush=True)
+```
+
+Python의 `print`를 항상 출력을 즉시 플러시하는 버전으로 바꿉니다. 상태 업데이트나 디버깅 출력을 기다릴 필요가 없으므로 장기 실행 스크립트에서 유용합니다.
+
+```python
+MAINNET_URL = "https://eth.drpc.org"
+```
+
+메인넷에 접속하기 위한 URL입니다. [서비스형 노드](/developers/docs/nodes-and-clients/nodes-as-a-service/)에서 얻거나 [Chainlist](https://chainlist.org/chain/1)에 광고된 것 중 하나를 사용할 수 있습니다.
+
+```python
+BLOCK_TIME_SECONDS = 12
+MINUTE_BLOCKS = int(60 / BLOCK_TIME_SECONDS)
+HOUR_BLOCKS = MINUTE_BLOCKS * 60
+DAY_BLOCKS = HOUR_BLOCKS * 24
+```
+
+이더리움 메인넷 블록은 일반적으로 12초마다 생성되므로, 이는 특정 기간에 생성될 것으로 예상되는 블록 수입니다. 이것은 정확한 수치가 아닙니다. [블록 제안자](/developers/docs/consensus-mechanisms/pos/block-proposal/)가 다운되면 해당 블록은 건너뛰어지고 다음 블록까지의 시간은 24초가 됩니다. 타임스탬프에 대한 정확한 블록을 얻으려면 [이진 검색](https://en.wikipedia.org/wiki/Binary_search)을 사용합니다. 하지만, 우리의 목적에는 이 정도로도 충분합니다. 미래를 예측하는 것은 정확한 과학이 아닙니다.
+
+```python
+CYCLE_BLOCKS = DAY_BLOCKS
+```
+
+주기의 크기입니다. 주기당 한 번씩 시세를 검토하고 다음 주기 말의 가치를 추정합니다.
+
+```python
+# 읽고 있는 풀의 주소
+WETHUSDC_ADDRESS = Web3.to_checksum_address("0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640")
+```
+
+시세 값은 [`0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640`](https://eth.blockscout.com/address/0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640?tab=read_write_contract) 주소의 Uniswap 3 USDC/WETH 풀에서 가져옵니다. 이 주소는 이미 체크섬 형식이지만, 코드 재사용성을 높이려면 [`Web3.to_checksum_address`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.to_checksum_address)를 사용하는 것이 좋습니다.
+
+```python
+POOL_ABI = [
+ { "name": "slot0", ... },
+ { "name": "token0", ... },
+ { "name": "token1", ... },
+]
+
+ERC20_ABI = [
+ { "name": "symbol", ... },
+ { "name": "decimals", ... }
+]
+```
+
+이는 우리가 연결해야 하는 두 계약의 [ABI](https://docs.soliditylang.org/en/latest/abi-spec.html)입니다. 코드를 간결하게 유지하기 위해 호출해야 하는 함수만 포함합니다.
+
+```python
+w3 = Web3(Web3.HTTPProvider(MAINNET_URL))
+```
+
+[`Web3`](https://web3py.readthedocs.io/en/stable/quickstart.html#remote-providers) 라이브러리를 시작하고 이더리움 노드에 연결합니다.
+
+```python
+@dataclass(frozen=True)
+class ERC20Token:
+ address: str
+ symbol: str
+ decimals: int
+ contract: Contract
+```
+
+이것은 Python에서 데이터 클래스를 만드는 한 가지 방법입니다. [`Contract`](https://web3py.readthedocs.io/en/stable/web3.contract.html) 데이터 유형은 계약에 연결하는 데 사용됩니다. `(frozen=True)`에 주목하세요. Python에서 [불리언](https://en.wikipedia.org/wiki/Boolean_data_type)은 대문자로 시작하는 `True` 또는 `False`로 정의됩니다. 이 데이터 클래스는 `frozen`이며, 필드를 수정할 수 없음을 의미합니다.
+
+들여쓰기에 주목하세요. [C 파생 언어](https://en.wikipedia.org/wiki/List_of_C-family_programming_languages)와 달리 Python은 들여쓰기를 사용하여 블록을 나타냅니다. Python 인터프리터는 다음 정의가 데이터 클래스 필드와 동일한 들여쓰기에서 시작하지 않기 때문에 이 데이터 클래스의 일부가 아님을 압니다.
+
+```python
+@dataclass(frozen=True)
+class PoolInfo:
+ address: str
+ token0: ERC20Token
+ token1: ERC20Token
+ contract: Contract
+ asset: str
+ decimal_factor: Decimal = 1
+```
+
+[`Decimal`](https://docs.python.org/3/library/decimal.html) 유형은 십진 분수를 정확하게 처리하는 데 사용됩니다.
+
+```python
+ def get_price(self, block: int) -> Decimal:
+```
+
+이것이 Python에서 함수를 정의하는 방법입니다. 이 정의는 여전히 `PoolInfo`의 일부임을 보여주기 위해 들여쓰기됩니다.
+
+데이터 클래스의 일부인 함수에서 첫 번째 매개변수는 항상 여기에서 호출된 데이터 클래스 인스턴스인 `self`입니다. 여기에는 블록 번호라는 또 다른 매개변수가 있습니다.
+
+```python
+ assert block <= w3.eth.block_number, "블록이 미래에 있습니다"
+```
+
+미래를 읽을 수 있다면 트레이딩에 AI가 필요하지 않을 것입니다.
+
+```python
+ sqrt_price_x96 = Decimal(self.contract.functions.slot0().call(block_identifier=block)[0])
+```
+
+Web3에서 EVM의 함수를 호출하는 구문은 다음과 같습니다. `.functions."().call()`. 매개변수는 EVM 함수의 매개변수(있는 경우, 여기서는 없음)이거나 블록체인 동작을 수정하기 위한 [명명된 매개변수](https://en.wikipedia.org/wiki/Named_parameter)일 수 있습니다. 여기서는 `block_identifier`를 사용하여 실행하려는 [블록 번호](/developers/docs/apis/json-rpc/#default-block)를 지정합니다.
+
+결과는 [배열 형식의 이 구조체](https://github.com/Uniswap/v3-core/blob/main/contracts/UniswapV3Pool.sol#L56-L72)입니다. 첫 번째 값은 두 토큰 간의 환율 함수입니다.
+
+```python
+ raw_price = (sqrt_price_x96 / Decimal(2**96)) ** 2
+```
+
+온체인 계산을 줄이기 위해 Uniswap v3는 실제 환율 요소가 아닌 제곱근을 저장합니다. EVM은 부동 소수점 연산이나 분수를 지원하지 않으므로 실제 값 대신 응답은