이더리움이 처음이시면 디파이 애플리케이션에 대한 제안을 살펴보세요.
디파이 앱 둘러보기
@@ -78,43 +79,43 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
대부분의 금융 서비스에는 탈중앙화된 대안이 있습니다. 그러나 이더리움은 완전히 새로운 금융 상품을 만들 수 있는 기회도 제공합니다. 이 목록은 계속 늘어납니다.
- [전 세계로 송금하기](#send-money)
-- [전 세계로 돈을 스트리밍하기](#stream-money)
-- [안정적인 통화에 액세스하기](#stablecoins)
+- [전 세계로 자금 스트리밍하기](#stream-money)
+- [스테이블코인 이용하기](#stablecoins)
- [담보로 자금 대출하기](#lending)
- [무담보 대출하기](#flash-loans)
- [암호화폐 저축 시작하기](#saving)
- [토큰 거래하기](#swaps)
-- [포트폴리오 확장하기](#investing)
-- [아이디어 자금 모으기](#crowdfunding)
+- [포트폴리오 성장시키기](#investing)
+- [아이디어에 자금 지원하기](#crowdfunding)
- [보험 가입하기](#insurance)
- [포트폴리오 관리하기](#aggregators)
-### 전 세계로 빠르게 송금하세요 {#send-money}
+### 전 세계로 빠르게 송금하기 {#send-money}
-이더리움은 블록체인으로서 안전하고 글로벌하게 트랜잭션을 전송할 수 있도록 설계되었습니다. 비트코인과 마찬가지로 이더리움은 이메일을 보내는 것만큼 쉽게 전 세계로 돈을 송금할 수 있습니다. 수령인의 [ENS 이름](/glossary/#ens)(예: bob.eth) 또는 지갑의 계정 주소를 입력하기만 하면 (일반적으로) 몇 분 내에 수령인에게 직접 지급됩니다. 지불금을 보내거나 받으려면 [지갑](/wallets/)이 필요합니다.
+이더리움은 블록체인으로서 안전하고 글로벌하게 트랜잭션을 전송할 수 있도록 설계되었습니다. 비트코인과 마찬가지로 이더리움은 이메일을 보내는 것만큼 쉽게 전 세계로 돈을 송금할 수 있습니다. 수령인의 [ENS 이름](/glossary/#ens)(예: bob.eth) 또는 지갑에 있는 계정 주소를 입력하기만 하면 일반적으로 몇 분 내에 결제 금액이 수령인에게 직접 전달됩니다. 결제를 보내거나 받으려면 [지갑](/wallets/)이 필요합니다.
- 결제 디앱 보기
+ 결제 탈중앙화앱 보기
#### 전 세계로 돈을 스트리밍하세요... {#stream-money}
이더리움으로 돈을 스트리밍할 수도 있습니다. 이렇게 하면 누군가에게 초 단위로 월급을 지급하여 필요할 때마다 돈을 받을 수 있습니다. 또는 초 단위로 보관 사물함이나 전기 스쿠터를 빌릴 수 있습니다.
-이더리움의 가치 변동 때문에 [이더](/glossary/#ether)를 전송하거나 스트리밍하고 싶지 않다면, 이더리움의 대체 화폐인 [스테이블코인](/glossary/#stablecoin)을 사용해 볼 수 있습니다.
+가치 변동 때문에 [ETH](/glossary/#ether)를 전송하거나 스트리밍하고 싶지 않다면, 이더리움에 대한 대체 통화인 [스테이블코인](/glossary/#stablecoin)이 있습니다.
-### 안정적인 화폐에 액세스하세요 {#stablecoins}
+### 스테이블코인 이용하기 {#stablecoins}
암호 화폐 변동성은 많은 금융상품과 일반 지출에 문제가 됩니다. 디파이 커뮤니티는 스테이블 코인으로 이 문제를 해결했습니다. 그것의 가치는 보통 달러처럼 인기 있는 통화인 또 다른 자산에 고정되어 있습니다.
다이 또는 USDC와 같은 코인의 가치는 몇 센트 이내입니다. 이런 점 때문에 스테이블 코인은 돈 버는 것 또는 소매업에 적합합니다. 라틴 아메리카의 많은 사람들은 정부가 발행한 화폐로 매우 불확실한 시기에 저축한 돈을 지키는 방법으로 스테이블 코인을 사용했습니다.
- 스테이블 코인에 대해 더 보기
+스테이블코인에 대한 자세한 내용
@@ -127,26 +128,26 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
- 대출 기관에서 자산을 대출자가 대출할 수 있는 풀로 지급하는(유동성) 풀 기반.
- 대출용 디앱 보기
+ 대출 탈중앙화앱 보기
탈중앙화된 대출 기관을 사용하는 것은 이점이 많습니다.
-#### 개인 정보 보호를 통한 대출 {#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: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
전형적인 금융 세계에서 위의 예시를 가능하게 하려면 엄청난 돈이 필요합니다. 이러한 돈벌이 전략은 기존의 부를 가진 사람들만이 접근할 수 있습니다. 플래시 론은 돈을 버는 것의 전제 조건이 돈을 소유하는 것이 아니라는 미래의 예시입니다.
- 플래시 론에 대해 더 보기
+ 플래시 론에 대해 더 알아보기
-### 암호화폐로 저축을 시작하세요 {#saving}
+### 암호화폐로 저축 시작하기 {#saving}
#### 대출 {#lending}
빌려주는 것으로 암호화폐의 이자를 벌어 실시간으로 자산이 늘어가는 걸 볼 수 있습니다. 현재 이자율은 지역 은행에서 얻을 수 있는 것보다 훨씬 높습니다(운 좋게 은행에 갈 수 있다면). 예시는 다음과 같습니다.
-- Aave와 같은 제품에 [스테이블 코인](/stablecoins/)인 100다이를 빌려줍니다.
+- Aave와 같은 제품에 [스테이블코인](/stablecoins/)인 100 다이를 대여합니다.
- 대출한 다이를 상징하는 토큰인 Aave 다이(aDai) 백 개를 받습니다.
-- 이자율에 따라 aDai는 증가하고 지갑에서 잔고가 늘어가는 걸 보실 수 있습니다. [연이율](/glossary/#apr)에 따라 지갑 잔액에는 며칠 또는 몇 시간 후에 100.1234와 같은 수치가 표시됩니다!
+- 이자율에 따라 aDai는 증가하고 지갑에서 잔고가 늘어가는 걸 보실 수 있습니다. [APR](/glossary/#apr)에 따라, 며칠 또는 몇 시간 후 지갑 잔액이 100.1234와 같이 표시됩니다!
- 언제든지 aDai 잔액과 동일한 금액의 일반 다이를 인출할 수 있습니다.
- 대출 디앱 보기
+ 대출 탈중앙화앱 보기
#### 무손실 복권 {#no-loss-lotteries}
@@ -205,12 +206,12 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
상금 풀은 위의 대출 예시와 같이 티켓 예금을 대출하여 발생하는 모든 이자로 생성됩니다.
- 풀투게더 사용해보기
+ PoolTogether 사용해 보기
-### 토큰을 교환하세요 {#swaps}
+### 토큰 교환 {#swaps}
이더리움에는 수천 개의 토큰이 있습니다. 탈중앙화 거래소(DEX)를 사용하면 원할 때마다 다른 토큰을 거래할 수 있습니다. 자산에 대한 통제권을 포기하지 마세요. 이것은 마치 다른 나라를 방문할 때 환전소를 이용하는 것과 같습니다. 하지만 디파이 버전은 절대 문을 닫지 않습니다. 시장은 연중무휴로 365일 운영되며 기술 덕에 거래를 수락할 사람을 항상 구할 수 있습니다.
@@ -229,24 +230,24 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
중앙화 거래소를 이용하면 거래 전에 자산을 예치해야 하고, 그 자산을 책임질 거래소를 신뢰해야 합니다. 자산이 예치되어 있으면 중앙화 거래소는 해커에게 매력적인 대상이기 때문에 자산이 위험합니다.
- 거래 디앱 보기
+ 거래 탈중앙화앱 보기
-### 포트폴리오를 확장하세요 {#investing}
+### 포트폴리오 성장시키기 {#investing}
이더리움에는 선택한 전략에 따라 포트폴리오를 확장하는 펀드 관리 제품이 있습니다. 이것은 자동적이고 모두에게 공개되며, 수익의 일부를 가져가는 인간 관리자가 필요 없습니다.
-좋은 예가 [디파이 펄스 인덱스 펀드(DPI)](https://defipulse.com/blog/defi-pulse-index/)입니다. 이 펀드는 포트폴리오에 항상 시가총액 기준 상위 디파이 토큰이 포함되도록 자동으로 편입 종목을 재조정합니다. 세부 사항을 관리할 필요가 없으며 원할 때마다 펀드에서 인출할 수 있습니다.
+좋은 예로 [DeFi Pulse Index fund (DPI)](https://defipulse.com/blog/defi-pulse-index/)가 있습니다. 이 펀드는 포트폴리오에 항상 시가총액 기준 상위 디파이 토큰이 포함되도록 자동으로 편입 종목을 재조정합니다. 세부 사항을 관리할 필요가 없으며 원할 때마다 펀드에서 인출할 수 있습니다.
- 투자 디앱 보기
+ 투자 탈중앙화앱 보기
-### 아이디어 자금을 모으세요 {#crowdfunding}
+### 아이디어에 자금 지원하기 {#crowdfunding}
이더리움은 크라우드 펀딩을 위한 이상적인 플랫폼입니다.
@@ -255,10 +256,10 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
- 예를 들면 모금자는 구체적인 기한과 최소 금액이 충족되지 않는 경우 자동 환불을 설정할 수 있습니다.
- 크라우드 펀딩 디앱 보기
+ 크라우드펀딩 탈중앙화앱 보기
-#### 2차 펀딩 {#quadratic-funding}
+#### 이차 펀딩 {#quadratic-funding}
이더리움은 오픈 소스 소프트웨어이며 지금까지의 많은 작업물이 커뮤니티에서 자금을 지원받았습니다. 이는 2차 펀딩이라는 흥미롭고 새로운 모금 모델의 성장으로 이어졌습니다. 2차 펀딩은 미래에 모든 공공재 유형에 자금을 지원하는 방식을 개선할 잠재력이 있습니다.
@@ -272,7 +273,7 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
이는 1달러의 기부를 100번 받은 프로젝트 A가 만 달러 기부를 한 번 받은 프로젝트 B보다 더 많은 펀딩을 받았다는 것을 의미합니다(매칭 풀의 크기에 따라 다름).
- 2차 펀딩에 대해 더 보기
+ 이차 펀딩에 대해 더 알아보기
@@ -281,10 +282,10 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
탈중앙화 보험은 보험을 더 싸고, 더 빠르게 돈을 지불할 수 있고, 더 투명하게 하는 것을 목표로 합니다. 더 많은 자동화가 이뤄지면 보험이 더욱 저렴해지고 지불도 훨씬 빨라집니다. 당신의 청구를 결정하는 데 사용되는 데이터는 완전히 투명합니다.
-이더리움 제품은 다른 소프트웨어와 마찬가지로 버그와 악용에 시달릴 수 있습니다. 그래서 현재 이 분야의 많은 보험 상품들은 자금 손실로부터 사용자를 보호하는 데 초점을 맞추고 있습니다. 그러나 살면서 발생할 수 있는 모든 사안으로 보장 범위를 확장하는 프로젝트가 있습니다. 이것의 좋은 예는 [케냐의 소규모 농부들을 가뭄과 홍수로부터 보호하는 것](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc)을 목표로 하는 이더리스크의 농작물 보험입니다. 탈중앙화 보험은 종종 일반적인 보험에서 제외되는 농부들에게 더 저렴한 보험을 제공할 수 있습니다.
+이더리움 제품은 다른 소프트웨어와 마찬가지로 버그와 악용에 시달릴 수 있습니다. 그래서 현재 이 분야의 많은 보험 상품들은 자금 손실로부터 사용자를 보호하는 데 초점을 맞추고 있습니다. 그러나 살면서 발생할 수 있는 모든 사안으로 보장 범위를 확장하는 프로젝트가 있습니다. 좋은 예로 [케냐의 소규모 자작농을 가뭄과 홍수로부터 보호](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc)하는 것을 목표로 하는 Etherisc의 농작물 보험이 있습니다. 탈중앙화 보험은 종종 일반적인 보험에서 제외되는 농부들에게 더 저렴한 보험을 제공할 수 있습니다.
- 보험 디앱 보기
+ 보험 탈중앙화앱 보기
@@ -294,14 +295,14 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
많은 일이 진행됨에 따라 모든 투자, 대출 및 거래를 추적할 수 있는 방법이 필요할 것입니다. 한 곳에서 디파이 활동을 조율할 수 있는 여러 제품이 있습니다. 이것이 디파이의 개방형 아키텍처의 아름다움입니다. 팀에서 여러 제품 간의 잔액을 볼 수 있는 인터페이스를 구축할 수 있을 뿐만 아니라 기능을 사용할 수도 있습니다. 디파이에 대해 더 알아갈 수록 이것이 유용할 것입니다.
- 포트폴리오 디앱 보기
+ 포트폴리오 탈중앙화앱 보기
## 디파이는 어떻게 작동하나요? {#how-defi-works}
-디파이는 암호화폐와 스마트 계약으로 중개인이 필요 없는 서비스를 제공합니다. 오늘날의 금융 세계에서 금융 기관은 거래의 보증인 역할을 합니다. 돈이 금융 기관을 통해 흐르기 때문에 금융 기관이 엄청난 힘을 갖게 됩니다. 게다가 전 세계 수십억 명의 사람들은 은행 계좌에 접근할 수도 없습니다.
+디파이는 암호화폐와 스마트 계약으로 중개인이 필요 없는 서비스를 제공합니다. 오늘날의 금융 세계에서 금융 기관은 거래의 보증인 역할을 합니다. 돈이 금융 기관을 통해 흐르기 때문에 금융 기관이 엄청난 힘을 갖게 됩니다. 게다가 전 세계 수십억 명의 사람들이 은행 계좌조차 이용할 수 없습니다.
디파이에서는 거래 시에 스마트 계약이 금융 기관을 대신합니다. 스마트 계약은 자금을 보유할 수 있고 특정 조건에 따라 송금/환불할 수 있는 일종의 이더리움 계정입니다. 스마트 계약이 실행 중에는 아무도 변경할 수 없습니다. 항상 프로그래밍된 대로 실행됩니다.
@@ -323,38 +324,43 @@ summaryPoint3: 누구나 프로그래밍할 수 있는 오픈 소스 기술을
디파이를 레이어 구조로 생각해 볼 수 있습니다.
1. 블록체인 – 이더리움에 거래 내역과 계정 상태가 들어있습니다.
-2. 자산 – [ETH](/what-is-ether/) 및 기타 토큰(화폐)입니다.
-3. 프로토콜 – 예를 들어 자산의 탈중앙화 대출을 제공하는 서비스와 같은 기능을 제공하는 [스마트 계약](/glossary/#smart-contract)입니다.
+2. 자산 – [ETH](/what-is-ether/) 및 기타 토큰(통화).
+3. 프로토콜 – 예를 들어 자산의 탈중앙화 대출을 허용하는 서비스와 같이 기능을 제공하는 [스마트 계약](/glossary/#smart-contract)입니다.
4. [애플리케이션](/apps/) – 프로토콜을 관리하고 액세스하는 데 사용하는 제품입니다.
-참고: 대부분의 탈중앙 금융은 [ERC-20 표준](/glossary/#erc-20)을 사용합니다. 디파이 애플리케이션은 랩드 이더(WETH)라는 이더리움 래퍼를 사용합니다. [랩드이더에 대해 자세히 알아보세요](/wrapped-eth).
+참고: 디파이의 상당 부분은 [ERC-20 표준](/glossary/#erc-20)을 사용합니다. 디파이 애플리케이션은 랩드 이더(WETH)라는 ETH용 래퍼를 사용합니다. [랩트 이더에 대해 더 알아보기](/wrapped-eth).
-## 디파이를 구축하세요 {#build-defi}
+## 디파이 구축하기 {#build-defi}
디파이는 오픈 소스 캠페인입니다. 디파이 프로토콜과 애플리케이션은 검사하고, 포크하고, 혁신할 수 있도록 누구에게나 열려 있습니다. 이러한 계층화된 스택(모두 동일한 베이스 블록체인과 자산을 공유함)으로 인해 프로토콜을 합치고 맞춰서 독특한 콤보 기회를 열 수 있습니다.
- 디앱 구축에 대해 더 보기
+ 탈중앙화앱 구축에 대해 더 알아보기
-## 부록 {#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)
+
+
+
+
diff --git a/public/content/translations/ko/desci/index.md b/public/content/translations/ko/desci/index.md
index 97b0c809ef4..ed961545dec 100644
--- a/public/content/translations/ko/desci/index.md
+++ b/public/content/translations/ko/desci/index.md
@@ -1,88 +1,89 @@
---
-title: 탈중앙화 과학(DeSci)
-description: 이더리움의 탈중앙화 과학 개요
+title: "탈중앙화 과학(DeSci)"
+description: "이더리움의 탈중앙화 과학 개요"
lang: ko
template: use-cases
emoji: ":microscope:"
sidebarDepth: 2
image: /images/future_transparent.png
alt: ""
-summaryPoint1: 현재 금융 시스템에 대한 글로벌하고 개방적인 대안입니다.
-summaryPoint2: 과학자들이 자금을 모으고, 실험을 실행하고, 데이터를 공유하고, 통찰력을 배포할 수 있게 하는 기술.
-summaryPoint3: 열린 과학 운동을 기반으로 합니다.
+summaryPoint1: "현재 금융 시스템에 대한 글로벌하고 개방적인 대안입니다."
+summaryPoint2: "과학자들이 자금을 모으고, 실험을 실행하고, 데이터를 공유하고, 통찰력을 배포할 수 있게 하는 기술."
+summaryPoint3: "열린 과학 운동을 기반으로 합니다."
---
## 탈중앙화 과학(DeSci)이란 무엇인가요? {#what-is-desci}
-탈중앙화 과학(DeSci)은 Web3 스택을 사용하여 과학 지식을 공정하고 공평하게 자금 조달, 생성, 검토, 신용, 저장 및 보급하기 위한 공공 인프라를 구축하는 것을 목표로 하는 운동입니다.
+탈중앙화 과학(DeSci)은 [Web3](/glossary/#web3) 스택을 사용하여 과학적 지식을 공정하고 공평하게 지원, 생성, 검토, 인정, 저장, 배포하기 위한 공공 인프라를 구축하려는 운동입니다.
DeSci는 과학자들이 그들의 연구를 공개적으로 공유하고 그들의 작업에 대한 공로를 인정받도록 장려하는 동시에 누구나 연구에 쉽게 접근하고 기여할 수 있는 생태계를 만드는 것을 목표로 합니다. DeSci는 과학적 지식은 모든 사람이 접근할 수 있어야 하며 과학 연구 과정은 투명해야 한다는 생각을 바탕으로 합니다. DeSci는 더 탈중앙화 과학 연구 모델을 만들고 있으며, 중앙 당국의 검열과 통제에 더 저항하고 있습니다. DeSci는 자금, 과학 도구 및 통신 채널에 대한 접근을 탈중앙화 시킴으로써 새롭고 틀에 얽매이지 않는 아이디어가 번창할 수 있는 환경을 조성하기를 희망합니다.
-탈중앙화 과학은 더 다양한 자금을 허용합니다 ([다오](/dao/), [ 펀딩 등에 대한 이차 기부](https://papers.ssrn.com/sol3/papers.cfm?Abstract_id=2003531)), 더 접근 가능한 접근 데이터와 방법, 그리고 재현에 대한 보상 제공함으로써.
+탈중앙화 과학은 ([DAO](/glossary/#dao), [이차 기부](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531), 크라우드펀딩 등) 더 다양한 자금 출처를 허용하고, 데이터와 방법에 더 쉽게 접근할 수 있게 하며, 재현성에 대한 인센티브를 제공합니다.
### Juan Benet - DeSci 운동
-## DeSci가 과학을 개선시키는 방법 {#desci-improves-science}
+## DeSci가 과학을 개선하는 방법 {#desci-improves-science}
과학의 주요 문제에 대한 불완전한 목록과 탈중앙화 과학이 이러한 문제를 해결하는 데 어떻게 도움이 될 수 있는지
-| **탈중앙화된 과학** | **기존 과학** |
-| --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
-| 자금 분배는 이차 기부 또는 DAO와 같은 메커니즘을 사용하여 대중에 의해 결정됩니다. | 작고 폐쇄된 중앙 집권 그룹이 자금 분배를 통제합니다. |
-| 여러분은 역동적인 팀으로 전 세계의 동료들과 협력합니다. | 자금 조달 기관과 가정 기관은 당신의 협력을 제한합니다. |
-| 자금 조달 결정은 온라인에서 투명하게 이루어집니다. 새로운 자금 조달 메커니즘이 탐구되었습니다. | 자금 조달 결정은 긴 처리 시간과 제한된 투명성으로 이루어집니다. 자금 조달 메커니즘은 거의 존재하지 않습니다. |
-| 실험실 서비스 공유는 Web3 기초 요소를 사용하여 더 쉽고 투명하게 만들어졌습니다. | 실험실 자원을 공유하는 것은 종종 느리고 불투명합니다. |
-| 신뢰, 투명성 및 보편적 접근을 위해 Web3 기초 요소를 사용하는 새로운 출판 모델을 개발할 수 있습니다. | 여러분은 비효율적이고 편향적이고 착취적인 것으로 자주 인정되는 확립된 경로를 통해 출판합니다. |
-| 동료 검토 작업으로 토큰과 명성을 얻을 수 있습니다. | 동료 검토 작업은 무급이며, 영리 출판사에 도움이 됩니다. |
-| 여러분은 투명한 조건에 따라 생성하고 배포하는 지적 재산권(IP) 을 소유합니다. | 여러분의 홈 기관은 여러분이 생성한 IP를 소유합니다. IP에 대한 접근은 투명하지 않습니다. |
-| 모든 단계를 체인에 연결함으로써 실패한 노력의 데이터를 포함한 모든 연구를 공유합니다. | 출판 편향은 연구자들이 성공적인 결과를 얻은 실험을 공유할 가능성이 더 높다는 것을 의미합니다. |
+| **탈중앙화된 과학** | **기존 과학** |
+| ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
+| 자금 분배는 이차 기부 또는 DAO와 같은 메커니즘을 사용하여 **대중이 결정**합니다. | 작고, 폐쇄적이며, **중앙화된 그룹**이 자금 분배를 통제합니다. |
+| **전 세계**의 동료들과 역동적인 팀에서 협력합니다. | 자금 지원 기관과 소속 기관이 협업을 **제한**합니다. |
+| 자금 지원 결정은 온라인에서 **투명하게** 이루어집니다. 새로운 자금 조달 메커니즘이 탐구되었습니다. | 자금 지원 결정은 처리 시간이 길고 **투명성이 제한적**입니다. 자금 조달 메커니즘은 거의 존재하지 않습니다. |
+| [Web3](/glossary/#web3) 기술을 사용하여 실험실 서비스를 더 쉽고 투명하게 공유할 수 있습니다. | 실험실 자원 공유는 종종 **느리고 불투명**합니다. |
+| **신뢰, 투명성, 보편적 접근을 위해 Web3 프리미티브를 사용하는 새로운 퍼블리싱 모델**을 개발할 수 있습니다. | 자주 **비효율적이고, 편향되며, 착취적**이라고 인정받는 기존 경로를 통해 출판합니다. |
+| 동료 검토 작업을 통해 **토큰과 평판을 얻을 수 있습니다**. | **동료 검토 작업은 무급**이며 영리 목적의 출판사에 이익이 됩니다. |
+| 투명한 조건에 따라 생성하고 배포하는 **지적 재산(IP)을 소유**합니다. | 생성한 **IP는 소속 기관이 소유**합니다. IP에 대한 접근은 투명하지 않습니다. |
+| 모든 단계를 온체인에 기록하여 실패한 노력의 데이터를 포함한 **모든 연구를 공유**합니다. | **게재 편향**은 연구자들이 성공적인 결과를 얻은 실험을 공유할 가능성이 더 높다는 것을 의미합니다. |
## 이더리움과 DeSci {#ethereum-and-desci}
-탈중앙화 과학 시스템은 강력한 보안, 최소한의 통화 및 거래 비용, 그리고 애플리케이션 개발을 위한 풍부한 생태계를 요구할 것입니다. 이더리움은 탈중앙화 과학 스택을 구축하는 데 필요한 모든 것을 제공합니다.
+탈중앙화 과학 시스템은 강력한 보안, 최소한의 통화 및 거래 비용, 그리고 애플리케이션 개발을 위한 풍부한 생태계를 요구할 것입니다. 이더리움은 탈중앙화 과학 기술을 구축하는 데 필요한 모든 것을 제공합니다.
## DeSci 사용 사례 {#use-cases}
-DeSci는 Web2 학계를 디지털 세계로 전환하기 위한 과학적 도구 세트를 구축하고 있습니다. 아래는 Web3가 과학계에 제공할 수 있는 사용 사례 샘플입니다.
+DeSci는 기존 학계를 디지털 세계로 온보딩하기 위한 과학적 툴셋을 구축하고 있습니다. 아래는 Web3가 과학계에 제공할 수 있는 사용 사례 샘플입니다.
-### 출판 사업 {#publishing}
+### 퍼블리싱 {#publishing}
-과학 출판은 논문을 생성하기 위해 과학자, 평론가 및 편집자의 무료 노동에 의존하지만 엄청난 출판 비용을 부과하는 출판사에 의해 관리되기 때문에 문제가 있는 것으로 유명합니다. 보통 세금을 통해 작품과 출판 비용을 간접적으로 지불한 대중은 종종 출판사에 다시 지불하지 않고는 같은 작품에 접근할 수 없습니다. 개별 과학 논문 출판에 드는 총 비용은 종종 5자리 숫자($USD)이며, 이는 과학 지식의 전체 개념을 [ 공익](https://www.econlib.org/library/Enc/PublicGoods.html)과 동시에 소수의 출판사에게 막대한 이익을 창출합니다.
+과학 출판은 논문을 생성하기 위해 과학자, 평론가 및 편집자의 무료 노동에 의존하지만 엄청난 출판 비용을 부과하는 출판사에 의해 관리되기 때문에 문제가 있는 것으로 유명합니다. 보통 세금을 통해 작품과 출판 비용을 간접적으로 지불한 대중은 종종 출판사에 다시 지불하지 않고는 같은 작품에 접근할 수 없습니다. 개별 과학 논문을 출판하는 데 드는 총비용은 종종 5자리 숫자(USD)에 달하며, 이는 소수의 출판사에 막대한 이익을 창출하는 동시에 과학적 지식을 [공공재](/glossary/#public-goods)로 보는 전체 개념을 훼손합니다.
-무료 및 오픈 액세스 플랫폼은 [ArXiv와 같은](https://arxiv.org/) 사전 인쇄 서버의 형태로 존재합니다. 그러나 이러한 플랫폼은 품질 관리, [반시빌(anti-sybil) 메커니즘 mechanisms](https://csrc.nist.gov/glossary/term/sybil_attack)이 부족하며 일반적으로 기사 수준의 글을 추적하지 않습니다. 즉, 일반적으로 전통적인 출판사에 제출하기 전에 작업을 홍보하는 데만 사용됩니다. 탈중앙화 허브 는 또한 출판된 논문에 무료로 접근할 수 있도록 하지만, 법적으로는 접근하지 않으며, 출판사가 이미 지불을 받고 엄격한 저작권법으로 작품을 포장한 후에만 가능합니다. 이것은 내장된 합법 메커니즘과 보상 모델로 접근 가능한 과학 논문과 데이터에 중요한 격차를 남깁니다. 그러한 시스템을 구축하기 위한 도구는 Web3에 존재합니다.
+무료 오픈 액세스 플랫폼은 [ArXiv](https://arxiv.org/)와 같은 사전 인쇄 서버의 형태로 존재합니다. 그러나 이러한 플랫폼은 품질 관리, [시빌 방지 메커니즘](/glossary/#anti-sybil)이 부족하고 일반적으로 논문 수준의 메트릭을 추적하지 않으므로, 보통 전통적인 출판사에 제출하기 전에 작업을 홍보하는 데만 사용됩니다. 탈중앙화 허브 는 또한 출판된 논문에 무료로 접근할 수 있도록 하지만, 법적으로는 접근하지 않으며, 출판사가 이미 지불을 받고 엄격한 저작권법으로 작품을 포장한 후에만 가능합니다. 이것은 내장된 합법 메커니즘과 보상 모델로 접근 가능한 과학 논문과 데이터에 중요한 격차를 남깁니다. 그러한 시스템을 구축하기 위한 도구는 Web3에 존재합니다.
-### 재생 가능성과 복제 가능성 {#reproducibility-and-replicability}
+### 재현성 및 복제성 {#reproducibility-and-replicability}
재생 가능성과 복제 가능성은 양질의 과학적 발견의 기초입니다.
- 재현 가능한 결과는 동일한 방법론을 사용하여 동일한 팀에서 연속으로 여러 번 달성할 수 있습니다.
- 동일한 실험 설정을 사용하여 다른 그룹에서 복제 가능한 결과를 얻을 수 있습니다.
-새로운 Web3 네이티브 도구는 재생 가능성과 복제 가능성이 검색의 기반이 되도록 보장할 수 있습니다. 우리는 학계의 기술 구조에 양질의 과학을 엮을 수 있습니다. Web3는 원시 데이터, 계산 엔진 및 응용 프로그램 결과와 같은 각 분석 구성 요소에 대한 증명을 만들 수 있는 기능을 제공합니다. 합의 시스템의 장점은 이러한 구성 요소를 유지하기 위해 신뢰할 수 있는 네트워크가 생성될 때, 각 네트워크 참가자는 계산을 재현하고 각 결과를 검증할 책임이 있다는 것입니다.
+새로운 Web3 네이티브 도구는 재생 가능성과 복제 가능성이 검색의 기반이 되도록 보장할 수 있습니다. 우리는 학계의 기술 구조에 양질의 과학을 엮을 수 있습니다. Web3는 원시 데이터, 계산 엔진, 애플리케이션 결과 등 각 분석 구성 요소에 대한 [증명](/glossary/#attestation)을 생성하는 기능을 제공합니다. 합의 시스템의 장점은 이러한 구성 요소를 유지하기 위해 신뢰할 수 있는 네트워크가 생성될 때, 각 네트워크 참가자는 계산을 재현하고 각 결과를 검증할 책임이 있다는 것입니다.
-### 펀딩 {#funding}
+### 자금 지원 {#funding}
-과학 자금 조달을 위한 현재 표준 모델은 개인이나 과학자 그룹이 자금 조달 기관에 서면 신청서를 작성하는 것입니다. 신뢰할 수 있는 개인으로 구성된 소규모 패널이 응용 프로그램을 평가한 다음 지원자 중 일부에게 기금을 수여하기 전에 지원자를 인터뷰합니다. 보조금 신청과 수령 사이에 때때로 수년의 대기 시간으로 이어지는 병목 현상을 제외하고 이 모델은 검토 패널의 편견, 이기심 및 정치에 매우 취약한 것으로 알려져 있습니다.
+과학 자금 조달을 위한 현재 표준 모델은 개인이나 과학자 그룹이 자금 조달 기관에 서면 신청서를 작성하는 것입니다. 신뢰할 수 있는 개인으로 구성된 소규모 패널이 응용 프로그램을 평가한 다음 지원자 중 일부에게 기금을 수여하기 전에 지원자를 인터뷰합니다. 보조금을 신청하고 수령하기까지 때로는 **수년을 기다려야** 하는 병목 현상을 만드는 것 외에도, 이 모델은 심사위원단의 **편견, 사리사욕, 정치에 매우 취약**한 것으로 알려져 있습니다.
연구에 따르면 보조금 검토 패널은 다른 패널에 주어진 동일한 제안이 매우 다른 결과를 가지고 있기 때문에 고품질 제안을 선택하는 데 열악한 역할을 합니다. 자금이 더 부족해짐에 따라, 그것은 더 지적으로 보수적인 프로젝트를 가진 더 많은 고위 연구자들의 더 작은 풀에 집중되었습니다. 그 효과는 비뚤어진 보상을 확고히 하고 혁신을 억누르는 경쟁적인 자금 조달 환경을 조성했습니다.
-Web3는 DAO와 Web3가 광범위하게 개발한 다양한 보상 모델을 실험함으로써 이 깨진 자금 조달 모델을 혼란에 빠뜨릴 가능성이 있습니다. [소급 공공재 자금 조달](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c), [이차 자금 조달](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531), [다오 운영 방식](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead) 그리고 [토큰화된 보상구조](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design)는 과학 자금에 혁명을 일으킬 수 있는 Web3 도구 중 일부입니다.
+Web3는 DAO와 Web3가 광범위하게 개발한 다양한 보상 모델을 실험함으로써 이 깨진 자금 조달 모델을 혼란에 빠뜨릴 가능성이 있습니다. [소급적 공공재 자금 지원](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c), [이차 펀딩](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531), [DAO 거버넌스](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead), [토큰화된 인센티브 구조](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design)는 과학 자금 지원에 혁명을 일으킬 수 있는 Web3 도구의 일부입니다.
### IP 소유권 및 개발 {#ip-ownership}
-지적 재산권(IP)은 대학에 갇히거나 생명공학에 사용되지 않는 것부터 평가하기 어려운 악명 높은 것까지 전통적인 과학에서 큰 문제입니다. 그러나 디지털 자산(과학 데이터 또는 기사와 같은) 의 소유권은 Web3가 [대체 불가능한 토큰(NFT)](/nft/)을 사용하여 예외적으로 잘 하는 것입니다.
+지적 재산권(IP)은 대학에 갇히거나 생명공학에 사용되지 않는 것부터 평가하기 어려운 악명 높은 것까지 전통적인 과학에서 큰 문제입니다. 그러나 과학 데이터나 논문과 같은 디지털 자산의 소유권은 Web3가 [대체 불가능한 토큰(NFT)](/glossary/#nft)을 사용하여 특히 잘 처리하는 부분입니다.
NFT가 향후 거래에 대한 수익을 원래 작성자에게 다시 전달할 수 있는 것과 같은 방식으로 연구자, 관리 기관(예: DAO) 또는 데이터를 수집한 주체에게 보상하기 위해 투명한 가치 귀속 체인을 설정할 수 있습니다.
-[IP-NFT](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6)는 또한 수행 중인 연구 실험의 분산된 데이터 저장소의 열쇠 역할을 할 수 있으며 NFT 및 [DeFi](/defi/) 금융화(금융에서 대출 풀 및 가치 평가까지)에 연결할 수 있습니다. 또한 [VitaDAO](https://www.vitadao.com/)와 같은 DAO와 같은 본질적으로 온체인 단체가 온 체인에서 직접 연구를 수행할 수 있습니다. 양도할 수 없는 ["soulbound" 토큰](https://vitalik.eth.limo/general/2022/01/26/soulbound.html)의 출현은 또한 개인이 이더리움 주소와 연결된 경험과 자격 증명을 증명할 수 있도록 함으로써 DeFi 에서 중요한 역할을 할 수 있습니다.
+[IP-NFT](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6)는 수행 중인 연구 실험의 탈중앙화된 데이터 저장소에 대한 키 역할을 할 수도 있으며, NFT 및 [DeFi](/glossary/#defi) 금융화(분할부터 대출 풀 및 가치 평가까지)에 연결할 수 있습니다. 또한 [VitaDAO](https://www.vitadao.com/)와 같은 DAO와 같은 네이티브 온체인 엔티티가 온체인에서 직접 연구를 수행할 수 있도록 합니다.
+양도 불가능한 ["소울바운드" 토큰](https://vitalik.eth.limo/general/2022/01/26/soulbound.html)의 등장은 개인이 자신의 이더리움 주소에 연결된 경험과 자격 증명을 증명할 수 있도록 하여 DeSci에서 중요한 역할을 할 수 있습니다.
### 데이터 저장, 액세스 및 아키텍처 {#data-storage}
과학적 데이터는 Web3 패턴을 사용하여 훨씬 더 쉽게 접근할 수 있으며, 분산 저장은 연구가 무시무시한 사건에서 살아남을 수 있게 해줍니다.
-출발점은 적절한 검증 가능한 자격 증명을 보유한 탈중앙화된 신원이 접근할 수 있는 시스템이어야 합니다. 이를 통해 신뢰할 수 있는 당사자가 민감한 데이터를 안전하게 복제할 수 있으며, 중복 및 검열 저항, 결과 재현, 심지어 여러 당사자가 협력하고 데이터 세트에 새로운 데이터를 추가할 수 있습니다. [Compute-to-data](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol)와 같은 기밀 컴퓨팅 방법은 원시 데이터 복제에 대한 대체 액세스 메커니즘을 제공하여 대부분의 민감한 데이터에 대한 신뢰할 수 있는 연구 환경을 조성합니다. 신뢰할 수 있는 연구 환경은 [NHS에 의해 인용되었으며](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb) 연구자들이 코드와 관행을 공유하기 위해 표준화 환경을 사용하여 현장에서 데이터와 안전하게 작업할 수 있는 생태계를 만드는 데이터 개인정보 보호 및 협업에 대한 미래 지향적인 솔루션입니다.
+출발점은 적절한 검증 가능한 자격 증명을 보유한 탈중앙화된 신원이 접근할 수 있는 시스템이어야 합니다. 이를 통해 신뢰할 수 있는 당사자가 민감한 데이터를 안전하게 복제할 수 있으며, 중복 및 검열 저항, 결과 재현, 심지어 여러 당사자가 협력하고 데이터 세트에 새로운 데이터를 추가할 수 있습니다. [컴퓨트 투 데이터](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol)와 같은 기밀 컴퓨팅 방법은 원시 데이터 복제에 대한 대안적인 액세스 메커니즘을 제공하여 가장 민감한 데이터에 대한 신뢰할 수 있는 연구 환경을 만듭니다. 신뢰할 수 있는 연구 환경은 연구자가 코드 및 관행 공유를 위해 표준화된 환경을 사용하여 현장에서 데이터를 안전하게 사용할 수 있는 생태계를 조성함으로써 데이터 개인 정보 보호 및 협업을 위한 미래 지향적인 솔루션으로 [NHS에 의해 인용되었습니다](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb).
유연한 Web3 데이터 해결책은 위의 시나리오를 지원하고 연구자가 액세스 권한이나 수수료 없이 공공재 만들 수 있는 진정한 개방형 과학의 기반을 제공합니다. IPFS, Arweave 및 Filecoin과 같은 Web3 공용 데이터 해결책은 탈중앙화에 최적화되어 있습니다. 예를 들어, 기후변화는 기상 관측소와 예측 기후 모델을 포함한 기후 및 날씨 데이터에 대한 보편적인 접근을 제공합니다.
@@ -90,48 +91,49 @@ NFT가 향후 거래에 대한 수익을 원래 작성자에게 다시 전달할
프로젝트를 탐색하고 DeSci 커뮤니티에 가입하세요.
-- [DeSci.Global: 글로벌 이벤트 및 모임 일정](https://desci.global)
-- [과학을 위한 블록체인 Telegram](https://t.me/BlockchainForScience)
-- [Molecule: 연구 프로젝트에 자금을 지원하고 자금을 지원받으세요](https://discover.molecule.to/)
-- [VitaDAO: 장수 연구를 위한 후원 연구 계약을 통해 자금을 받으세요](https://www.vitadao.com/)
-- [ResearchHub: 과학적 결과를 게시하고 동료들과 대화에 참여하세요](https://www.researchhub.com/)
-- [dClimate API: 분산된 커뮤니티에서 수집한 기후 데이터 쿼리](https://www.dclimate.net/)
-- [DeFi Foundation: DeFi 게시 도구 빌더](https://descifoundation.org/)
-- [DeSci.World: 사용자가 보고, 탈중앙화 과학에 참여할 수 있는 원스톱 상점](https://desci.world)
-- [플레밍 프로토콜: 협업 생물 의학 발견을 촉진하는 오픈 소스 데이터 경제](https://medium.com/@FlemingProtocol/a-data-economy-for-patient-driven-biomedical-innovation-9d56bf63d3dd)
-- [OceanDAO: DAO에서 관리하는 데이터 관련 과학을 위한 펀딩](https://oceanprotocol.com/dao)
-- [Opscientia: 개방형 탈중앙화 과학 작업 흐름](https://opsci.io/research/)
-- [Bio.xyz: 생명공학 DAO 또는 desci 프로젝트에 자금을 지원받으세요](https://www.molecule.to/)
-- [ResearchHub: 과학적 결과를 게시하고 동료들과 대화에 참여하세요](https://www.researchhub.com/)
-- [VitaDAO: 장수 연구를 위한 후원 연구 계약을 통해 자금을 받으세요](https://www.vitadao.com/)
-- [플레밍 프로토콜: 협업 생물 의학 발견을 촉진하는 오픈 소스 데이터 경제](https://medium.com/@FlemingProtocol/a-data-economy-for-patient-driven-biomedical-innovation-9d56bf63d3dd)
-- [능동적 추론 실험실](https://www.activeinference.org/)
-- [CureDAO: 지역 사회 소유의 정밀 건강 플랫폼.](https://docs.curedao.org/)
-- [IdeaMarkets: 탈중앙화 과학적 신뢰성을 가능하게 합니다.](https://ideamarket.io/)
+- [DeSci.Global: 글로벌 이벤트 및 밋업 캘린더](https://desci.global)
+- [Blockchain for Science 텔레그램](https://t.me/BlockchainForScience)
+- [Molecule: 연구 프로젝트에 자금을 지원하고 자금 지원받기](https://www.molecule.xyz/)
+- [VitaDAO: 수명 연장 연구를 위한 후원 연구 계약을 통해 자금 지원받기](https://www.vitadao.com/)
+- [ResearchHub: 과학적 결과를 게시하고 동료들과 대화하기](https://www.researchhub.com/)
+- [dClimate API: 탈중앙화 커뮤니티에서 수집한 기후 데이터 쿼리](https://www.dclimate.net/)
+- [DeSci Foundation: DeSci 퍼블리싱 도구 빌더](https://descifoundation.org/)
+- [DeSci.World: 사용자가 탈중앙화 과학을 보고 참여할 수 있는 원스톱 숍](https://desci.world)
+- [OceanDAO: 데이터 관련 과학을 위한 DAO 거버넌스 펀딩](https://oceanprotocol.com/)
+- [Opscientia: 개방형 탈중앙화 과학 워크플로](https://opsci.io/research/)
+- [Bio.xyz: 생명공학 DAO 또는 desci 프로젝트를 위한 자금 지원받기](https://www.bio.xyz/)
+- [Fleming Protocol: 협업 생물의학 발견을 촉진하는 오픈 소스 데이터 경제](http://flemingprotocol.io/)
+- [Active Inference Institute](https://www.activeinference.org/)
+- [IdeaMarkets: 탈중앙화된 과학적 신뢰성 지원](https://ideamarket.io/)
- [DeSci Labs](https://www.desci.com/)
+- [ValleyDAO: 합성 생물학 연구를 위한 자금 및 중개 연구를 지원하는 개방형 글로벌 커뮤니티](https://www.valleydao.bio)
+- [Cerebrum DAO: 뇌 건강을 증진하고 신경 퇴행을 예방하기 위한 솔루션 소싱 및 육성](https://www.cerebrumdao.com/)
+- [CryoDAO: 동결 보존 분야의 문샷 연구에 자금 지원](https://www.cryodao.org)
+- [Elata: 정신과 의학의 미래에 목소리를 내세요](https://www.elata.bio/)
-우리는 새로운 프로젝트에 대한 제안을 환영합니다 - 시작하려면 [목록 정책](/contributing/adding-desci-projects/)을 보세요!
+등록할 새로운 프로젝트에 대한 제안을 환영합니다. 시작하려면 [등록 정책](/contributing/adding-desci-projects/)을 확인해 주세요!
-## 더 읽을거리 {#further-reading}
+## 더 읽어보기 {#further-reading}
-- [Jocelynn Pearl과 Ultrarare의 DeSci Wiki](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#)
-- [A16z 미래를 위한 Jocelynn Pearl의 분산형 생명공학 가이드](https://future.a16z.com/a-guide-to-decentralized-biotech/)
-- [DeSci의 사례](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/)
+- [Jocelynn Pearl 및 Ultrarare의 DeSci 위키](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#)
+- [a16z future를 위해 Jocelynn Pearl이 작성한 탈중앙화 생명공학 가이드](https://future.a16z.com/a-guide-to-decentralized-biotech/)
+- [DeSci를 지지하는 이유](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/)
- [DeSci 가이드](https://future.com/what-is-decentralized-science-aka-desci/)
-- [탈중앙화 과학 참고 자료](https://www.vincentweisser.com/desci)
-- [분자의 바이오제약회사 IP-NFT - 기술 설명](https://molecule.to/blog/molecules-biopharma-ip-nfts-a-technical-description)
-- [존 스타의 신뢰할 수 없는 과학 시스템 구축](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673)
-- [생명공학 DAO의 출현](https://molecule.to/blog/the-emergence-of-biotech-daos)
-- [Paul Kohlhaas - DeSci: 분산 과학의 미래(팟캐스트)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a)
-- [분산 과학을 위한 적극적인 추론 존재론: 위치한 감각 만들기에서 Epistemic Commons까지](https://zenodo.org/record/6320575)
-- [DeSci: 사무엘 아키노쇼의 연구의 미래](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec)
-- [나디아의 과학 자금 조달 (끝맺음말: DeSci 및 새로운 암호화 기초 요소)](https://nadia.xyz/science-funding)
-- [탈중앙화는 약물 개발을 방해하고 있습니다.](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f)
-
-### 영상 {#videos}
-
-- [탈중앙화 과학이란 무엇인가요?](https://www.youtube.com/watch?v=-DeMklVWNdA)
-- [장수 연구와 암호화폐의 교차점에 대한 비탈릭 부테린과 과학자 오브리 드 그레이의 대화](https://www.youtube.com/watch?v=x9TSJK1widA)
-- [과학 출판이 망가졌습니다. Web3가 고칠 수 있나요?](https://www.youtube.com/watch?v=WkvzYgCvWj8)
-- [후안 베넷 - DeSci, 독립 연구소 및 대규모 데이터 과학](https://www.youtube.com/watch?v=zkXM9H90g_E)
-- [Sebastian Brunemeier - DeSci가 생물 의학 연구 및 벤처 캐피탈을 변화시킬 수 있는 방법](https://www.youtube.com/watch?v=qB4Tc3FcVbM)
+- [탈중앙화 과학 리소스](https://www.vincentweisser.com/desci)
+- [Molecule의 바이오제약 IP-NFT - 기술 설명](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description)
+- [Jon Starr의 신뢰가 필요 없는 과학 시스템 구축](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673)
+- [Paul Kohlhaas - DeSci: 탈중앙화 과학의 미래(팟캐스트)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a)
+- [탈중앙화 과학을 위한 능동적 추론 온톨로지: 상황 기반 의미 형성에서 인식적 공유지로](https://zenodo.org/record/6320575)
+- [Samuel Akinosho의 DeSci: 연구의 미래](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec)
+- [Nadia의 과학 자금 지원(에필로그: DeSci와 새로운 암호화 프리미티브)](https://nadia.xyz/science-funding)
+- [탈중앙화가 신약 개발을 혁신하다](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f)
+- [DeSci란 무엇인가 – 탈중앙화 과학?](https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/)
+
+### 동영상 {#videos}
+
+- [탈중앙화 과학이란?](https://www.youtube.com/watch?v=-DeMklVWNdA)
+- [장수 연구와 암호화폐의 교차점에 대한 Vitalik Buterin과 과학자 Aubrey de Grey의 대화](https://www.youtube.com/watch?v=x9TSJK1widA)
+- [과학 출판이 망가졌습니다. Web3가 해결할 수 있을까?](https://www.youtube.com/watch?v=WkvzYgCvWj8)
+- [Juan Benet - DeSci, 독립 연구소 및 대규모 데이터 과학](https://www.youtube.com/watch?v=zkXM9H90g_E)
+- [Sebastian Brunemeier - DeSci가 생물의학 연구 및 벤처 캐피털을 혁신하는 방법](https://www.youtube.com/watch?v=qB4Tc3FcVbM)
+- [Paige Donner - Web3 및 블록체인을 이용한 오픈 사이언스 툴링](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s)
diff --git a/public/content/translations/ko/developers/docs/accounts/index.md b/public/content/translations/ko/developers/docs/accounts/index.md
new file mode 100644
index 00000000000..457bdacd55b
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/accounts/index.md
@@ -0,0 +1,137 @@
+---
+title: "이더리움 계정"
+description: "이더리움 계정에 대한 설명 - 이더리움 데이터 구조와 주요 키 페어 크립토그래피들의 관계"
+lang: ko
+---
+
+이더리움 계정은 이더(ETH) 잔액이 있으며 이더리움에 메시지를 전송할 수 있는 개체입니다. 계정은 사용자가 직접 제어하거나 스마트 계약을 통해 배포할 수도 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 [이더리움 소개](/developers/docs/intro-to-ethereum/)를 읽어보시는 것을 권장합니다.
+
+## 계정 유형 {#types-of-account}
+
+이더리움에는 두 가지의 계정 종류가 있습니다.
+
+- 외부 계정 - 해당 계정의 개인 키가 있는 사람이라면 누구나 제어할 수 있습니다
+- 컨트랙트 계정 - 네트워크에 배포된 스마트 계약이며 코드를 통해 제어합니다 [스마트 계약](/developers/docs/smart-contracts/)에 대해 알아보기
+
+두 가지의 계정 종류 모두 아래와 같은 기능이 있습니다.
+
+- ETH 및 토큰 수령, 보유, 전송
+- 배포된 스마트 계약과 상호작용
+
+### 주요 차이점 {#key-differences}
+
+**외부 소유 계정**
+
+- 비용 없이 계정을 만들 수 있습니다.
+- 트랜잭션을 개시할 수 있습니다.
+- 외부 소유 계정 간에는 ETH 또는 토큰 전송 거래만 가능합니다.
+- 계정 활동을 제어하는 공개키와 비밀키로 만들어집니다.
+
+**컨트랙트 계정**
+
+- 네트워크 스토리지를 사용하기 때문에 계정을 만들 때 비용이 듭니다.
+- 트랜잭션 수신에 대한 응답으로만 메시지를 전송할 수 있습니다.
+- 외부 소유 계정에서 컨트랙트 계정으로의 트랜잭션은 토큰 전송이나 더 나아가 신규 컨트랙트 생성과 같은 다양한 작업을 실행할 수 있는 코드를 트리거 할 수 있습니다.
+- 컨트랙트 계정은 비밀키를 갖고 있지 않습니다. 대신, 스마트 컨트랙트 로직에 의해 제어됩니다.
+
+## 계정 살펴보기 {#an-account-examined}
+
+이더리움 계정에는 네 가지의 값이 있습니다.
+
+- `nonce` – 외부 소유 계정에서 전송한 트랜잭션 수 또는 컨트랙트 계정으로 생성된 컨트랙트 수를 나타내는 카운터입니다. 주어진 논스로는 한 계정당 하나의 트랜잭션만 수행될 수 있으며, 이는 이미 수행된 트랜잭션의 반복적인 전송과 수행을 이용한 반복 공격을 방지할 수 있습니다.
+- `balance` – 해당 주소가 보유하고 있는 wei의 값입니다. 웨이(Wei)는 ETH의 단위이며 100경 Wei는 1 ETH를 나타냅니다.
+- `codeHash` – 이 해시는 이더리움 가상 머신(EVM)에 있는 계정의 _코드_를 나타냅니다. 계약 계정에는 서로 다른 작업을 실행할 수 있도록 프로그램된 코드 조각들이 있습니다. 이 EVM 코드는 계정이 메시지 콜을 받았을 때 실행됩니다. 이 값은 다른 계정 값과는 다르게 바꿀 수 없습니다. 추후 검색을 위해 모든 코드 조각들은 상태 데이터베이스 내에 그에 해당하는 해쉬값 아래 보관됩니다. 이 해쉬값이 바로 codeHash입니다. 외부 소유 계정의 경우, codeHash 필드는 빈 문자열 해시입니다.
+- `storageRoot` – 스토리지 해시라고도 합니다. 계정의 스토리지 콘텐츠(256비트 정수 값 간의 매핑)를 인코딩하는 [머클 패트리샤 트리](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) 루트 노드의 256비트 해시입니다. 이는 256비트 정수 키의 Keccak-256 해시에서 RLP로 인코딩된 256비트 정수 값으로의 매핑으로 트라이에 인코딩됩니다. 이 트리는 계정에 저장된 내용을 해시로 인코딩한 것으로, 기본적으로는 비어 있습니다.
+
+
+_[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)에서 발췌한 다이어그램_
+
+## 외부 소유 계정과 키 쌍 {#externally-owned-accounts-and-key-pairs}
+
+계정은 공개 및 비공개 암호화 키 쌍으로 구성됩니다. 이러한 키 쌍들로 발송인이 실제로 트랜잭션에 서명하였는 지 증명하고 위조를 방지할 수 있습니다. 개인 키는 트랜잭션에 서명하는 데 쓰이며, 계정과 연결된 자금을 보관할 수 있도록 합니다. 본인은 실제로 암호화폐를 소유하지 않으며, 개인 키만을 가지고 있다는 사실을 기억하세요. 자금은 언제나 이더리움 원장 상에 존재합니다.
+
+트랜잭션 전송인을 항상 검증할 수 있기 때문에 의심스러운 사용자들이 가짜 트랜잭션을 전송하는 것을 방지할 수 있습니다.
+
+앨리스가 계정에서 밥의 계정으로 이더를 보내려면 엘리스는 트랜잭션 요청을 생성한 후 검증을 위해 트랜잭션을 네트워크로 보내야 합니다. 이더리움의 공개 키 암호 사용은 앨리스가 그 트랜잭션 요청을 처음 개시함을 증명할 수 있음을 보장합니다. 암호화 메커니즘이 없다면, 악의적 상대방인 이브가 "앨리스의 계정에서 이브의 계정으로 5 ETH 전송"과 같은 요청을 그냥 공개적으로 퍼뜨릴 수 있고 아무도 그러한 요청이 앨리스로부터 오지 않았음을 검증할 수 없을 겁니다.
+
+## 계정 생성 {#account-creation}
+
+계정을 생성하려면 대부분의 라이브러리가 무작위 비공개 키를 생성해 줍니다.
+
+개인 키는 64개의 16진수 문자로 이루어져 있고 비밀번호로 암호화 가능합니다.
+
+예시:
+
+`fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036415f`
+
+[타원 곡선 디지털 서명 알고리즘](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)을 사용하여 개인 키에서 공개 키가 생성됩니다. 공개 키의 Keccak-256 해시값 중 마지막 20바이트를 가져와 맨 앞에 `0x`를 추가하면 계정의 공개 주소를 얻을 수 있습니다.
+
+즉, 외부 소유 계정(EOA)은 42자의 주소(20바이트 세그먼트, 40개의 16진수 문자와 `0x` 접두사)로 구성됩니다.
+
+예시:
+
+`0x5e97870f263700f46aa00d967821199b9bc5a120`
+
+다음 예제는 [Clef](https://geth.ethereum.org/docs/tools/clef/introduction)라는 서명 도구를 사용하여 새 계정을 생성하는 방법을 보여줍니다. Clef는 계정 관리 및 서명 도구로 이더리움 클라이언트인 [Geth](https://geth.ethereum.org)와 함께 제공됩니다. `clef newaccount` 명령어는 새로운 키 쌍을 생성하고 암호화된 키스토어에 저장합니다.
+
+```
+> clef newaccount --keystore
+
+생성할 새 계정의 암호를 입력하세요:
+>
+
+------------
+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}
+
+오스틴이 해시 함수와 키 쌍에 대해 설명하는 것을 보세요.
+
+
+
+
+
+## 더 읽어보기 {#further-reading}
+
+- [이더리움 계정 이해하기](https://info.etherscan.com/understanding-ethereum-accounts/) - etherscan
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
+
+## 관련 주제 {#related-topics}
+
+- [스마트 계약](/developers/docs/smart-contracts/)
+- [트랜잭션](/developers/docs/transactions/)
diff --git a/public/content/translations/ko/developers/docs/apis/backend/index.md b/public/content/translations/ko/developers/docs/apis/backend/index.md
new file mode 100644
index 00000000000..92475a9e7c6
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/apis/backend/index.md
@@ -0,0 +1,211 @@
+---
+title: "백엔드 API 라이브러리"
+description: "사용자의 애플리케이션에서 블록체인과 상호작용 할 수 있는 이더리움 클라이언트 API에 대한 소개."
+lang: ko
+---
+
+소프트웨어 애플리케이션이 이더리움 블록체인과 상호작용하려면(즉, 블록체인 데이터를 읽거나 네트워크에 트랜잭션을 보내려면) 이더리움 노드에 연결해야 합니다.
+
+이러한 목적을 위해 모든 이더리움 클라이언트는 [JSON-RPC](/developers/docs/apis/json-rpc/) 사양을 구현하므로 애플리케이션이 의존할 수 있는 통일된 [메서드](/developers/docs/apis/json-rpc/#json-rpc-methods) 세트가 있습니다.
+
+특수 프로그래밍 언어를 사용하여 이더리움 노드과 연결하려는 경우, 생태계 내부에 이러한 작업을 훨씬 용이하게 하는 편리한 라이브러리가 많이 있습니다. 개발자는 이러한 라이브러리를 사용하여 이더리움과 상호작용하는 JSON-RPC 요청(후드 아래)을 초기화하는 직관적인 단일 방법을 작성할 수 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+[이더리움 스택](/developers/docs/ethereum-stack/)과 [이더리움 클라이언트](/developers/docs/nodes-and-clients/)를 이해하면 도움이 될 수 있습니다.
+
+## 라이브러리를 왜 사용할까요? {#why-use-a-library}
+
+이러한 라이브러리는 이더리움 노드와 직접적으로 상호작용하는 많은 복잡성을 일반화합니다. 또한 유틸리티 함수(예: ETH를 Gwei로 변환)도 제공하므로 개발자는 이더리움 클라이언트의 복잡성을 처리하는 데 시간을 덜 들이고 애플리케이션의 고유 기능에 더 집중할 수 있습니다.
+
+## 사용 가능한 라이브러리 {#available-libraries}
+
+### 인프라 및 노드 서비스 {#infrastructure-and-node-services}
+
+**Alchemy -** **_이더리움 개발 플랫폼입니다._**
+
+- [alchemy.com](https://www.alchemy.com/)
+- [개발문서](https://www.alchemy.com/docs/)
+- [GitHub](https://github.com/alchemyplatform)
+- [Discord](https://discord.com/invite/alchemyplatform)
+
+**All That Node -** **_서비스형 노드._**
+
+- [All That Node.com](https://www.allthatnode.com/)
+- [개발문서](https://docs.allthatnode.com)
+- [Discord](https://discord.gg/GmcdVEUbJM)
+
+**Blast by Bware Labs -** **_이더리움 메인넷 및 테스트넷을 위한 탈중앙화 API._**
+
+- [blastapi.io](https://blastapi.io/)
+- [개발문서](https://docs.blastapi.io)
+- [Discord](https://discord.gg/SaRqmRUjjQ)
+
+**BlockPi -** **_보다 효율적이고 빠른 RPC 서비스 제공_**
+
+- [blockpi.io](https://blockpi.io/)
+- [개발문서](https://docs.blockpi.io/)
+- [GitHub](https://github.com/BlockPILabs)
+- [Discord](https://discord.com/invite/xTvGVrGVZv)
+
+\*\* Cloudflare Ethereum 게이트웨이. \*\*
+
+- [cloudflare-eth.com](https://www.cloudflare.com/application-services/products/web3/)
+
+**Etherscan - 블록 탐색기 및 거래 API**
+
+- [개발문서](https://docs.etherscan.io/)
+
+**Blockscout - 오픈소스 블록 탐색기**
+
+- [개발문서](https://docs.blockscout.com/)
+
+**GetBlock-** **_Web3 개발을 위한 서비스형 블록체인_**
+
+- [GetBlock.io](https://getblock.io/)
+- [개발문서](https://docs.getblock.io/)
+
+**Infura -** **_서비스형 이더리움 API._**
+
+- [infura.io](https://infura.io)
+- [개발문서](https://docs.infura.io/api)
+- [GitHub](https://github.com/INFURA)
+
+**Node RPC - _저비용의 EVM JSON-RPC 제공업체_**
+
+- [noderpc.xyz](https://www.noderpc.xyz/)
+- [개발문서](https://docs.noderpc.xyz/node-rpc)
+
+**NOWNodes - _풀노드 및 블록 탐색기._**
+
+- [NOWNodes.io](https://nownodes.io/)
+- [개발문서](https://nownodes.gitbook.io/documentation)
+
+**QuickNode -** **_서비스형 블록체인 인프라._**
+
+- [quicknode.com](https://quicknode.com)
+- [개발문서](https://www.quicknode.com/docs/welcome)
+- [Discord](https://discord.gg/quicknode)
+
+**Rivet -** **_오픈소스 소프트웨어로 구동되는 서비스형 이더리움 및 이더리움 클래식 API._**
+
+- [rivet.cloud](https://rivet.cloud)
+- [개발문서](https://rivet.cloud/docs/)
+- [GitHub](https://github.com/openrelayxyz/ethercattle-deployment)
+
+**Zmok -** **_속도 중심의 이더리움 노드인 JSON-RPC/WebSockets API._**
+
+- [zmok.io](https://zmok.io/)
+- [GitHub](https://github.com/zmok-io)
+- [개발문서](https://docs.zmok.io/)
+- [Discord](https://discord.gg/fAHeh3ka6s)
+
+### 개발 도구 {#development-tools}
+
+**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)
+
+**Nethereum -** **_블록체인을 위한 오픈소스 .NET 통합 라이브러리._**
+
+- [GitHub](https://github.com/Nethereum/Nethereum)
+- [개발문서](http://docs.nethereum.com/en/latest/)
+- [Discord](https://discord.com/invite/jQPrR58FxX)
+
+**Python Tooling -** **_Python을 통해 이더리움과 상호작용하기 위한 다양한 라이브러리._**
+
+- [py.ethereum.org](https://snakecharmers.ethereum.org/)
+- [web3.py GitHub](https://github.com/ethereum/web3.py)
+- [web3.py Chat](https://gitter.im/ethereum/web3.py)
+
+**Tatum -** **_최고의 블록체인 개발 플랫폼._**
+
+- [Tatum](https://tatum.io/)
+- [GitHub](https://github.com/tatumio/)
+- [개발문서](https://docs.tatum.io/)
+- [Discord](https://discord.gg/EDmW3kjTC9)
+
+**web3j -** **_이더리움을 위한 Java/Android/Kotlin/Scala 통합 라이브러리._**
+
+- [GitHub](https://github.com/web3j/web3j)
+- [개발문서](https://docs.web3j.io/)
+- [Gitter](https://gitter.im/web3j/web3j)
+
+### 블록체인 서비스 {#blockchain-services}
+
+**BlockCypher -** **_이더리움 웹 API._**
+
+- [blockcypher.com](https://www.blockcypher.com/)
+- [개발문서](https://www.blockcypher.com/dev/ethereum/)
+
+**Chainbase -** **_이더리움을 위한 올인원 web3 데이터 인프라._**
+
+- [chainbase.com](https://chainbase.com/)
+- [개발문서](https://docs.chainbase.com/)
+- [Discord](https://discord.gg/Wx6qpqz4AF)
+
+**Chainstack -** **_서비스형 탄력적 및 전용 이더리움 노드._**
+
+- [chainstack.com](https://chainstack.com)
+- [개발문서](https://docs.chainstack.com/)
+- [이더리움 API 레퍼런스](https://docs.chainstack.com/reference/ethereum-getting-started)
+
+**Coinbase Cloud Node -** **_블록체인 인프라 API._**
+
+- [Coinbase Cloud Node](https://www.coinbase.com/developer-platform)
+- [개발문서](https://docs.cdp.coinbase.com/)
+
+**DataHub by Figment -** **_이더리움 메인넷 및 테스트넷을 갖춘 Web3 API 서비스._**
+
+- [DataHub](https://www.figment.io/)
+- [개발문서](https://docs.figment.io/)
+
+**Moralis -** **_엔터프라이즈급 EVM API 제공업체._**
+
+- [moralis.io](https://moralis.io)
+- [개발문서](https://docs.moralis.io/)
+- [GitHub](https://github.com/MoralisWeb3)
+- [Discord](https://moralis.io/joindiscord/)
+- [포럼](https://forum.moralis.io/)
+
+**NFTPort -** **_이더리움 데이터 및 민팅 API._**
+
+- [nftport.xyz](https://www.nftport.xyz/)
+- [개발문서](https://docs.nftport.xyz/)
+- [GitHub](https://github.com/nftport/)
+- [Discord](https://discord.com/invite/K8nNrEgqhE)
+
+**Tokenview -** **_범용 멀티 암호화폐 블록체인 API 플랫폼._**
+
+- [services.tokenview.io](https://services.tokenview.io/)
+- [개발문서](https://services.tokenview.io/docs?type=api)
+- [GitHub](https://github.com/Tokenview)
+
+**Watchdata -** **_이더리움 블록체인에 간단하고 신뢰할 수 있는 API 액세스를 제공합니다._**
+
+- [Watchdata](https://watchdata.io/)
+- [개발문서](https://docs.watchdata.io/)
+- [Discord](https://discord.com/invite/TZRJbZ6bdn)
+
+**Covalent -** **_200개 이상의 체인을 위한 풍부한 기능의 블록체인 API._**
+
+- [covalenthq.com](https://www.covalenthq.com/)
+- [개발문서](https://www.covalenthq.com/docs/api/)
+- [GitHub](https://github.com/covalenthq)
+- [Discord](https://www.covalenthq.com/discord/)
+
+## 더 읽어보기 {#further-reading}
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
+
+## 관련 주제 {#related-topics}
+
+- [노드 및 클라이언트](/developers/docs/nodes-and-clients/)
+- [개발 프레임워크](/developers/docs/frameworks/)
+
+## 관련 튜토리얼 {#related-tutorials}
+
+- [JavaScript에서 이더리움 블록체인을 사용하도록 Web3js 설정하기](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– 프로젝트에 web3.js를 설정하는 방법에 대한 안내입니다._
+- [JavaScript에서 스마트 계약 호출하기](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– DAI 토큰을 사용하여 JavaScript로 계약 함수를 호출하는 방법을 알아보세요._
diff --git a/public/content/translations/ko/developers/docs/apis/javascript/index.md b/public/content/translations/ko/developers/docs/apis/javascript/index.md
new file mode 100644
index 00000000000..6a4255a9ac5
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/apis/javascript/index.md
@@ -0,0 +1,289 @@
+---
+title: "자바스크립트 API 라이브러리"
+description: "애플리케이션에서 블록체인과 상호작용할 수 있는 자바스크립트 클라이언트 라이브러리를 소개합니다."
+lang: ko
+---
+
+웹 앱이 이더리움 블록체인과 상호작용하려면(즉, 블록체인 데이터를 읽거나 네트워크에 트랜잭션을 보내려면) 이더리움 노드에 연결해야 합니다.
+
+이를 위해 모든 이더리움 클라이언트는 [JSON-RPC](/developers/docs/apis/json-rpc/) 사양을 구현하므로 애플리케이션이 의존할 수 있는 통일된 [메서드](/developers/docs/apis/json-rpc/#json-rpc-methods) 집합이 있습니다.
+
+자바스크립트를 사용하여 이더리움 노드에 연결하려는 경우, 바닐라 자바스크립트를 사용할 수도 있지만, 생태계 내에 이를 훨씬 쉽게 만들어주는 여러 편의 라이브러리가 존재합니다. 개발자는 이러한 라이브러리를 사용하여 이더리움과 상호작용하는 JSON-RPC 요청(후드 아래)을 초기화하는 직관적인 단일 방법을 작성할 수 있습니다.
+
+[병합](/roadmap/merge/) 이후, 노드를 실행하려면 실행 클라이언트와 합의 클라이언트라는 두 개의 연결된 이더리움 소프트웨어가 필요하다는 점에 유의하세요. 노드에 실행 클라이언트와 합의 클라이언트가 모두 포함되어 있는지 확인하세요. 노드가 로컬 컴퓨터에 없는 경우(예: AWS 인스턴스에서 노드가 실행되는 경우), 튜토리얼의 IP 주소를 적절하게 업데이트하세요. 자세한 내용은 [노드 실행하기](/developers/docs/nodes-and-clients/run-a-node/) 페이지를 참조하세요.
+
+## 필수 구성 요소 {#prerequisites}
+
+자바스크립트를 이해하는 것 외에도 [이더리움 스택](/developers/docs/ethereum-stack/)과 [이더리움 클라이언트](/developers/docs/nodes-and-clients/)를 이해하는 것이 도움이 될 수 있습니다.
+
+## 라이브러리를 왜 사용할까요? {#why-use-a-library}
+
+이러한 라이브러리는 이더리움 노드와 직접적으로 상호작용하는 많은 복잡성을 일반화합니다. 또한 유틸리티 함수(예: ETH를 Gwei로 변환)도 제공하므로 개발자는 이더리움 클라이언트의 복잡성을 처리하는 데 시간을 덜 들이고 애플리케이션의 고유 기능에 더 집중할 수 있습니다.
+
+## 라이브러리 기능 {#library-features}
+
+### 이더리움 노드에 연결 {#connect-to-ethereum-nodes}
+
+이 라이브러리는 공급자를 사용하여 JSON-RPC, INFURA, Etherscan, Alchemy 또는 MetaMask를 통해 이더리움에 연결하고 데이터를 읽을 수 있게 해줍니다.
+
+> **경고:** Web3.js는 2025년 3월 4일에 아카이브되었습니다. [공지 사항 읽기](https://blog.chainsafe.io/web3-js-sunset/). 새로운 프로젝트에는 [ethers.js](https://ethers.org) 또는 [viem](https://viem.sh)과 같은 대체 라이브러리를 사용하는 것을 고려해 보세요.
+
+**Ethers 예시**
+
+```js
+// BrowserProvider는 표준 Web3 공급자를 래핑하며,
+// 이는 MetaMask가 각 페이지에 window.ethereum으로 주입하는 것입니다
+const provider = new ethers.BrowserProvider(window.ethereum)
+
+// MetaMask 플러그인을 사용하면 트랜잭션에 서명하여
+// 이더를 전송하고 블록체인 내 상태를 변경하기 위해 지불할 수 있습니다.
+// 이를 위해 계정 서명자가 필요합니다...
+const signer = provider.getSigner()
+```
+
+**Web3js 예시**
+
+```js
+var web3 = new Web3("http://localhost:8545")
+// 또는
+var web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"))
+
+// 공급자 변경
+web3.setProvider("ws://localhost:8546")
+// 또는
+web3.setProvider(new Web3.providers.WebsocketProvider("ws://localhost:8546"))
+
+// node.js에서 IPC 공급자 사용
+var net = require("net")
+var web3 = new Web3("/Users/myuser/Library/Ethereum/geth.ipc", net) // mac os 경로
+// 또는
+var web3 = new Web3(
+ new Web3.providers.IpcProvider("/Users/myuser/Library/Ethereum/geth.ipc", net)
+) // mac os 경로
+// windows에서의 경로는 다음과 같습니다: "\\\\.\\pipe\\geth.ipc"
+// linux에서의 경로는 다음과 같습니다: "/users/myuser/.ethereum/geth.ipc"
+```
+
+설정이 완료되면 블록체인에 다음을 쿼리할 수 있습니다.
+
+- 블록 번호
+- 가스 추정치
+- 스마트 계약 이벤트
+- 네트워크 ID
+- 그 이상 많은것들...
+
+### 지갑 기능 {#wallet-functionality}
+
+이 라이브러리들은 지갑을 만들고, 키를 관리하고, 트랜잭션에 서명하는 기능을 제공합니다.
+
+다음은 Ethers의 예시입니다
+
+```js
+// 니모닉으로 지갑 인스턴스를 생성합니다...
+mnemonic =
+ "announce room limb pattern dry unit scale effort smooth jazz weasel alcohol"
+walletMnemonic = Wallet.fromPhrase(mnemonic)
+
+// ...또는 개인 키로 생성합니다
+walletPrivateKey = new Wallet(walletMnemonic.privateKey)
+
+walletMnemonic.address === walletPrivateKey.address
+// 참
+
+// 서명자 API에 따른 Promise로서의 주소
+walletMnemonic.getAddress()
+// { Promise: '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' }
+
+// 지갑 주소는 동기적으로도 사용할 수 있습니다
+walletMnemonic.address
+// '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1'
+
+// 내부 암호화 구성 요소
+walletMnemonic.privateKey
+// '0x1da6847600b0ee25e9ad9a52abbd786dd2502fa4005dd5af9310b7cc7a3b25db'
+walletMnemonic.publicKey
+// '0x04b9e72dfd423bcf95b3801ac93f4392be5ff22143f9980eb78b3a860c4843bfd04829ae61cdba4b3b1978ac5fc64f5cc2f4350e35a108a9c9a92a81200a60cd64'
+
+// 지갑 니모닉
+walletMnemonic.mnemonic
+// {
+// locale: 'en',
+// path: 'm/44\'/60\'/0\'/0/0',
+// phrase: 'announce room limb pattern dry unit scale effort smooth jazz weasel alcohol'
+// }
+
+// 참고: 개인 키로 생성된 지갑은
+// 니모닉을 가지지 않습니다(파생 과정에서 이를 방지함)
+walletPrivateKey.mnemonic
+// null
+
+// 메시지 서명
+walletMnemonic.signMessage("Hello World")
+// { Promise: '0x14280e5885a19f60e536de50097e96e3738c7acae4e9e62d67272d794b8127d31c03d9cd59781d4ee31fb4e1b893bd9b020ec67dfa65cfb51e2bdadbb1de26d91c' }
+
+tx = {
+ to: "0x8ba1f109551bD432803012645Ac136ddd64DBA72",
+ value: utils.parseEther("1.0"),
+}
+
+// 트랜잭션 서명
+walletMnemonic.signTransaction(tx)
+// { Promise: '0xf865808080948ba1f109551bd432803012645ac136ddd64dba72880de0b6b3a7640000801ca0918e294306d177ab7bd664f5e141436563854ebe0a3e523b9690b4922bbb52b8a01181612cec9c431c4257a79b8c9f0c980a2c49bb5a0e6ac52949163eeb565dfc' }
+
+// connect 메서드는 공급자에 연결된
+// 지갑의 새 인스턴스를 반환합니다
+wallet = walletMnemonic.connect(provider)
+
+// 네트워크 쿼리
+wallet.getBalance()
+// { Promise: { BigNumber: "42" } }
+wallet.getTransactionCount()
+// { Promise: 0 }
+
+// 이더 전송
+wallet.sendTransaction(tx)
+```
+
+[전체 문서 읽기](https://docs.ethers.io/v5/api/signer/#Wallet)
+
+설정이 완료되면 다음을 수행할 수 있습니다.
+
+- 계정 생성
+- 트랜잭션 전송
+- 트랜잭션 서명
+- 그 이상 많은것들...
+
+### 스마트 계약 함수와 상호작용하기 {#interact-with-smart-contract-functions}
+
+자바스크립트 클라이언트 라이브러리를 사용하면 애플리케이션에서 컴파일된 계약의 애플리케이션 바이너리 인터페이스(ABI)를 읽어 스마트 계약 함수를 호출할 수 있습니다.
+
+ABI는 기본적으로 계약의 함수를 JSON 형식으로 설명하며, 이를 일반적인 자바스크립트 객체처럼 사용할 수 있게 해줍니다.
+
+따라서 다음 솔리디티 계약은:
+
+```solidity
+contract Test {
+ uint a;
+ address d = 0x12345678901234567890123456789012;
+
+ constructor(uint testInt) { a = testInt;}
+
+ event Event(uint indexed b, bytes32 c);
+
+ event Event2(uint indexed b, bytes32 c);
+
+ function foo(uint b, bytes32 c) returns(address) {
+ Event(b, c);
+ return d;
+ }
+}
+```
+
+다음과 같은 JSON이 생성됩니다.
+
+```json
+[{
+ "type":"constructor",
+ "payable":false,
+ "stateMutability":"nonpayable"
+ "inputs":[{"name":"testInt","type":"uint256"}],
+ },{
+ "type":"function",
+ "name":"foo",
+ "constant":false,
+ "payable":false,
+ "stateMutability":"nonpayable",
+ "inputs":[{"name":"b","type":"uint256"}, {"name":"c","type":"bytes32"}],
+ "outputs":[{"name":"","type":"address"}]
+ },{
+ "type":"event",
+ "name":"Event",
+ "inputs":[{"indexed":true,"name":"b","type":"uint256"}, {"indexed":false,"name":"c","type":"bytes32"}],
+ "anonymous":false
+ },{
+ "type":"event",
+ "name":"Event2",
+ "inputs":[{"indexed":true,"name":"b","type":"uint256"},{"indexed":false,"name":"c","type":"bytes32"}],
+ "anonymous":false
+}]
+```
+
+즉, 다음을 수행할 수 있습니다.
+
+- 스마트 계약에 트랜잭션을 보내고 메서드를 실행합니다
+- EVM에서 실행될 때 메서드 실행에 소요될 가스를 추정하기 위해 호출합니다
+- 계약 배포
+- 기타 등등...
+
+### 유틸리티 함수 {#utility-functions}
+
+유틸리티 함수는 이더리움 기반의 빌드를 좀 더 쉽게 만들어주는 편리한 단축 기능을 제공합니다.
+
+ETH 값은 기본적으로 Wei 단위입니다. 1 ETH = 1,000,000,000,000,000,000 WEI – 이는 매우 큰 숫자를 다룬다는 의미입니다! `web3.utils.toWei`는 이더를 Wei로 변환해 줍니다.
+
+그리고 ethers에서는 다음과 같습니다.
+
+```js
+// 계정의 잔액을 가져옵니다(주소 또는 ENS 이름으로)
+balance = await provider.getBalance("ethers.eth")
+// { BigNumber: "2337132817842795605" }
+
+// 종종 사용자에게 보여주기 위해 출력을 포맷해야 합니다
+// 사용자는 wei 대신 이더 단위의 값을 선호합니다
+ethers.utils.formatEther(balance)
+// '2.337132817842795605'
+```
+
+- [Web3js 유틸리티 함수](https://docs.web3js.org/api/web3-utils)
+- [Ethers 유틸리티 함수](https://docs.ethers.org/v6/api/utils/)
+
+## 사용 가능한 라이브러리 {#available-libraries}
+
+**Web3.js -** **_이더리움 자바스크립트 API._**
+
+- [개발문서](https://docs.web3js.org)
+- [GitHub](https://github.com/ethereum/web3.js)
+
+**Ethers.js -** **_자바스크립트 및 타입스크립트의 완전한 이더리움 지갑 구현 및 유틸리티._**
+
+- [Ethers.js 홈](https://ethers.org/)
+- [개발문서](https://docs.ethers.io)
+- [GitHub](https://github.com/ethers-io/ethers.js)
+
+**The Graph -** **_이더리움 및 IPFS 데이터를 인덱싱하고 GraphQL을 사용하여 쿼리하기 위한 프로토콜입니다._**
+
+- [The Graph](https://thegraph.com)
+- [그래프 탐색기](https://thegraph.com/explorer)
+- [개발문서](https://thegraph.com/docs)
+- [GitHub](https://github.com/graphprotocol)
+- [Discord](https://thegraph.com/discord)
+
+**Alchemy SDK -** **_향상된 API가 포함된 Ethers.js 래퍼._**
+
+- [개발문서](https://www.alchemy.com/docs)
+- [GitHub](https://github.com/alchemyplatform/alchemy-sdk-js)
+
+**viem -** **_이더리움을 위한 타입스크립트 인터페이스._**
+
+- [개발문서](https://viem.sh)
+- [GitHub](https://github.com/wagmi-dev/viem)
+
+**Drift -** **_내장 캐싱, 후크, 테스트 목(mock)이 포함된 타입스크립트 메타 라이브러리._**
+
+- [개발문서](https://ryangoree.github.io/drift/)
+- [GitHub](https://github.com/ryangoree/drift/)
+
+## 더 읽어보기 {#further-reading}
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
+
+## 관련 주제 {#related-topics}
+
+- [노드 및 클라이언트](/developers/docs/nodes-and-clients/)
+- [개발 프레임워크](/developers/docs/frameworks/)
+
+## 관련 튜토리얼 {#related-tutorials}
+
+- [JavaScript에서 이더리움 블록체인을 사용하도록 Web3js 설정하기](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– 프로젝트에 web3.js를 설정하는 방법에 대한 안내입니다._
+- [JavaScript에서 스마트 계약 호출하기](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– DAI 토큰을 사용하여 JavaScript로 계약 함수를 호출하는 방법을 알아보세요._
+- [web3와 Alchemy를 사용하여 트랜잭션 보내기](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– 백엔드에서 트랜잭션을 보내는 단계별 안내입니다._
diff --git a/public/content/translations/ko/developers/docs/apis/json-rpc/index.md b/public/content/translations/ko/developers/docs/apis/json-rpc/index.md
new file mode 100644
index 00000000000..798a184121c
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/apis/json-rpc/index.md
@@ -0,0 +1,1898 @@
+---
+title: JSON-RPC APIs
+description: "이더리움 클라이언트를 위한, 무상태성 경량 RPC(원격 프로시저 호출) 프로토콜"
+lang: ko
+---
+
+소프트웨어 애플리케이션이 블록체인 데이터를 읽거나 네트워크에 트랜잭션을 전송하여 이더리움 블록체인과 상호작용하려면 이더리움 노드에 연결해야 합니다.
+
+이를 위해 모든 [이더리움 클라이언트](/developers/docs/nodes-and-clients/#execution-clients)는 [JSON-RPC 사양](https://github.com/ethereum/execution-apis)을 구현하므로 애플리케이션은 특정 노드나 클라이언트 구현에 관계없이 의존할 수 있는 통일된 메서드 집합이 있습니다.
+
+[JSON-RPC](https://www.jsonrpc.org/specification)는 무상태, 경량 원격 프로시저 호출(RPC) 프로토콜입니다. 여러 데이터 구조와 그 처리에 관한 규칙을 정의합니다. 소켓이나 HTTP 또는 다양한 메시지 전달 환경을 포함한 동일한 프로세스 내에서 개념을 사용할 수 있다는 점에서 전송의 추상화가 잘 이루어져 있습니다. (원문: agnostic; 불가지론자; 어떤 운영 체제나 프로세서의 조합에 대한 지식 없이도 기능을 수행할 수 있는, 여기에서는 추상화로 대체) 데이터 형식은 JSON(RFC 4627)으로 사용합니다.
+
+## 클라이언트 구현 {#client-implementations}
+
+이더리움 클라이언트는 JSON-RPC 사양을 구현할 때 각기 다른 프로그래밍 언어를 사용할 수 있습니다. 특정 프로그래밍 언어와 관련된 자세한 내용은 개별 [클라이언트 문서](/developers/docs/nodes-and-clients/#execution-clients)를 참조하세요. 최신 API 지원 정보는 각 클라이언트의 문서를 확인하는 게 좋습니다.
+
+## 편의성 라이브러리 {#convenience-libraries}
+
+JSON-RPC API를 통해 이더리움 클라이언트와 직접 상호 작용하는 방식을 선택할 수 있습니다. 그러나 dapp 개발자를 위한 더 쉬운 옵션도 있습니다. JSON-RPC API 위에 래퍼를 제공하기 위해 많은 [JavaScript](/developers/docs/apis/javascript/#available-libraries) 및 [백엔드 API](/developers/docs/apis/backend/#available-libraries) 라이브러리가 존재합니다. 개발자는 이런 라이브러리를 사용하여 이더리움과 상호 작용하는 JSON-RPC 요청을 초기화할 수 있습니다. 라이브러리를 잘 사용하면 개발을 위해 선택한 프로그래밍 언어로, 직관적인 한 줄 메서드를 작성할 수 있습니다.
+
+## 합의 클라이언트 API {#consensus-clients}
+
+이 페이지는 주로 이더리움 실행 클라이언트에서 사용하는 JSON-RPC API를 다룹니다. 그러나 합의 클라이언트에는 사용자가 노드에 대한 정보를 쿼리하고, 비콘 블록, 비콘 상태 및 기타 합의 관련 정보를 노드에서 직접 요청할 수 있는 RPC API도 있습니다. 이 API는 [Beacon API 웹페이지](https://ethereum.github.io/beacon-APIs/#/)에 문서화되어 있습니다.
+
+내부 API는 노드 내의 클라이언트 간 통신에도 사용됩니다. 즉, 합의 클라이언트와 실행 클라이언트가 데이터를 교환할 수 있게 해줍니다. 이를 '엔진 API'라고 하며 사양은 [GitHub](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)에서 확인할 수 있습니다.
+
+## 실행 클라이언트 사양 {#spec}
+
+[GitHub에서 전체 JSON-RPC API 사양 읽기](https://github.com/ethereum/execution-apis). 이 API는 [실행 API 웹페이지](https://ethereum.github.io/execution-apis/)에 문서화되어 있으며 사용 가능한 모든 방법을 시험해 볼 수 있는 검사기를 포함합니다.
+
+## 규칙 {#conventions}
+
+### 16진수 값 인코딩 {#hex-encoding}
+
+형식이 지정되지 않은 바이트 배열과 수량이라는 두 가지 주요 데이터 유형이 JSON을 통해 전달됩니다. 둘 다 16진수 인코딩으로 전달되지만 형식 지정에 대한 요구 사항은 다릅니다.
+
+#### 수량 {#quantities-encoding}
+
+수량(정수, 숫자)을 인코딩할 때: 16진수로 인코딩하고, "0x"를 접두사로 붙이며, 가장 간결한 표현을 사용합니다(약간의 예외: 0은 "0x0"으로 표현해야 함).
+
+몇 가지 예는 다음과 같습니다.
+
+- 0x41 (10진수로 65)
+- 0x400 (10진수로 1024)
+- 잘못됨: 0x (항상 하나 이상의 숫자가 있어야 함 - 0은 "0x0")
+- 잘못됨: 0x0400 (앞에 0을 붙일 수 없음)
+- 잘못됨: ff (접두사 0x가 있어야 함)
+
+### 형식 없는 데이터 {#unformatted-data-encoding}
+
+형식 없는 데이터(바이트 배열, 계정 주소, 해시, 바이트코드 배열)를 인코딩할 때: 16진수로 인코딩하고, 접두사 "0x"를 붙이며, 바이트당 2개의 16진수 숫자를 사용합니다.
+
+몇 가지 예는 다음과 같습니다.
+
+- 0x41 (크기 1, "A")
+- 0x004200 (크기 3, "0B0")
+- 0x (크기 0, "")
+- 잘못됨: 0xf0f0f (짝수 개의 숫자여야 함)
+- 잘못됨: 004200 (접두사 0x가 있어야 함)
+
+### 블록 매개변수 {#block-parameter}
+
+다음 메서드에는 블록 매개변수가 있습니다:
+
+- [eth_getBalance](#eth_getbalance)
+- [eth_getCode](#eth_getcode)
+- [eth_getTransactionCount](#eth_gettransactioncount)
+- [eth_getStorageAt](#eth_getstorageat)
+- [eth_call](#eth_call)
+
+이더리움의 상태를 쿼리하는 요청이 이루어지면 제공된 블록 매개변수가 블록의 높이를 결정합니다.
+
+블록 매개변수에 대해 다음 옵션을 사용할 수 있습니다:
+
+- `16진수 문자열` - 정수 블록 번호
+- `문자열 "earliest"` - 가장 오래된/제네시스 블록
+- `문자열 "latest"` - 최신 제안 블록
+- `문자열 "safe"` - 최신 안전 헤드 블록
+- `문자열 "finalized"` - 최신 확정 블록
+- `문자열 "pending"` - 보류 중인 상태/트랜잭션
+
+## 예시
+
+이 페이지에서는 명령줄 도구인 [curl](https://curl.se)을 사용하여 개별 JSON_RPC API 엔드포인트를 사용하는 방법에 대한 예를 제공합니다. 이러한 개별 엔드포인트 예는 아래의 [Curl 예제](#curl-examples) 섹션에서 찾을 수 있습니다. 페이지의 뒷부분에서는 Geth 노드, JSON_RPC API 및 curl을 사용하여 스마트 계약을 컴파일하고 배포하는 [엔드투엔드 예제](#usage-example)도 제공합니다.
+
+## Curl 예제 {#curl-examples}
+
+이더리움 노드에 [curl](https://curl.se) 요청을 하여 JSON_RPC API를 사용하는 예제가 아래에 제공됩니다. 각 예제에는
+특정 엔드포인트에 대한 설명, 매개변수, 반환 유형 및 사용 방법에 대한 실제 예제가 포함됩니다.
+
+curl 요청은 콘텐츠 유형과 관련된 오류 메시지를 반환할 수 있습니다. 이는 `--data` 옵션이 콘텐츠 유형을 `application/x-www-form-urlencoded`로 설정하기 때문입니다. 노드에서 이와 관련하여 불만을 제기하는 경우, 호출 시작 부분에 `-H "Content-Type: application/json"`을 배치하여 헤더를 수동으로 설정하세요. 예제에는 curl에 마지막 인수로 제공되어야 하는 URL/IP 및 포트 조합(예: `127.0.0.1:8545`)도 포함되어 있지 않습니다. 이러한 추가 데이터를 포함하는 전체 curl 요청은 다음 형식을 취합니다:
+
+```shell
+curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545
+```
+
+## 가십, 상태, 기록 {#gossip-state-history}
+
+소수의 핵심 JSON-RPC 메서드는 이더리움 네트워크의 데이터가 필요하며, _가십, 상태, 기록_이라는 세 가지 주요 범주로 깔끔하게 분류됩니다. 이 섹션의 링크를 사용하여 각 메서드로 이동하거나 목차를 사용하여 전체 메서드 목록을 탐색하세요.
+
+### 가십 메서드 {#gossip-methods}
+
+> 이 메서드들은 체인의 헤드를 추적합니다. 이것이 트랜잭션이 네트워크를 돌아다니고, 블록으로 들어가며, 클라이언트가 새로운 블록에 대해 알게 되는 방식입니다.
+
+- [eth_blockNumber](#eth_blocknumber)
+- [eth_sendRawTransaction](#eth_sendrawtransaction)
+
+### 상태 메서드 {#state_methods}
+
+> 저장된 모든 데이터의 현재 상태를 보고하는 메서드입니다. '상태'는 하나의 큰 공유 RAM 조각과 같으며 계정 잔액, 계약 데이터 및 가스 추정치를 포함합니다.
+
+- [eth_getBalance](#eth_getbalance)
+- [eth_getStorageAt](#eth_getstorageat)
+- [eth_getTransactionCount](#eth_gettransactioncount)
+- [eth_getCode](#eth_getcode)
+- [eth_call](#eth_call)
+- [eth_estimateGas](#eth_estimategas)
+
+### 기록 메서드 {#history_methods}
+
+> 제네시스까지 모든 블록의 과거 기록을 가져옵니다. 이것은 하나의 큰 추가 전용 파일과 같으며 모든 블록 헤더, 블록 본문, 엉클 블록 및 트랜잭션 영수증을 포함합니다.
+
+- [eth_getBlockTransactionCountByHash](#eth_getblocktransactioncountbyhash)
+- [eth_getBlockTransactionCountByNumber](#eth_getblocktransactioncountbynumber)
+- [eth_getUncleCountByBlockHash](#eth_getunclecountbyblockhash)
+- [eth_getUncleCountByBlockNumber](#eth_getunclecountbyblocknumber)
+- [eth_getBlockByHash](#eth_getblockbyhash)
+- [eth_getBlockByNumber](#eth_getblockbynumber)
+- [eth_getTransactionByHash](#eth_gettransactionbyhash)
+- [eth_getTransactionByBlockHashAndIndex](#eth_gettransactionbyblockhashandindex)
+- [eth_getTransactionByBlockNumberAndIndex](#eth_gettransactionbyblocknumberandindex)
+- [eth_getTransactionReceipt](#eth_gettransactionreceipt)
+- [eth_getUncleByBlockHashAndIndex](#eth_getunclebyblockhashandindex)
+- [eth_getUncleByBlockNumberAndIndex](#eth_getunclebyblocknumberandindex)
+
+## JSON-RPC API 플레이그라운드
+
+[플레이그라운드 도구](https://ethereum-json-rpc.com)를 사용하여 API 메서드를 검색하고 사용해 볼 수 있습니다. 또한 다양한 노드 제공업체에서 지원하는 메서드와 네트워크를 보여줍니다.
+
+## JSON-RPC API 메서드 {#json-rpc-methods}
+
+### web3_clientVersion {#web3_clientversion}
+
+현재 클라이언트의 버전을 반환합니다.
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+`문자열` - 현재 클라이언트 버전
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}'
+// 결과
+{
+ "id":67,
+ "jsonrpc":"2.0",
+ "result": "Geth/v1.12.1-stable/linux-amd64/go1.19.1"
+}
+```
+
+### web3_sha3 {#web3_sha3}
+
+주어진 데이터의 Keccak-256(표준화된 SHA3-256이 _아님_)을 반환합니다.
+
+**매개변수**
+
+1. `DATA` - SHA3 해시로 변환할 데이터
+
+```js
+params: ["0x68656c6c6f20776f726c64"]
+```
+
+**반환 값**
+
+`DATA` - 주어진 문자열의 SHA3 결과입니다.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}'
+// 결과
+{
+ "id":64,
+ "jsonrpc": "2.0",
+ "result": "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad"
+}
+```
+
+### net_version {#net_version}
+
+현재 네트워크 ID를 반환합니다.
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+`문자열` - 현재 네트워크 ID입니다.
+
+현재 네트워크 ID의 전체 목록은 [chainlist.org](https://chainlist.org)에서 확인할 수 있습니다. 일반적인 몇 가지 예는 다음과 같습니다:
+
+- `1`: 이더리움 메인넷
+- `11155111`: 세폴리아 테스트넷
+- `560048` : Hoodi 테스트넷
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}'
+// 결과
+{
+ "id":67,
+ "jsonrpc": "2.0",
+ "result": "3"
+}
+```
+
+### net_listening {#net_listening}
+
+클라이언트가 네트워크 연결을 활발하게 수신하고 있으면 `true`를 반환합니다.
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+`부울` - 수신 중일 때는 `true`, 그렇지 않으면 `false`입니다.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}'
+// 결과
+{
+ "id":67,
+ "jsonrpc":"2.0",
+ "result":true
+}
+```
+
+### net_peerCount {#net_peercount}
+
+현재 클라이언트에 연결된 피어 수를 반환합니다.
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+`QUANTITY` - 연결된 피어 수의 정수입니다.
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}'
+// 결과
+{
+ "id":74,
+ "jsonrpc": "2.0",
+ "result": "0x2" // 2
+}
+```
+
+### eth_protocolVersion {#eth_protocolversion}
+
+현재 이더리움 프로토콜 버전을 반환합니다. 이 메서드는 [Geth에서 사용할 수 없음](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924)에 유의하세요.
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+`문자열` - 현재 이더리움 프로토콜 버전
+
+**예시**
+
+```js
+// 요청
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}'
+// 결과
+{
+ "id":67,
+ "jsonrpc": "2.0",
+ "result": "54"
+}
+```
+
+### eth_syncing {#eth_syncing}
+
+동기화 상태에 대한 데이터가 있는 객체 또는 `false`를 반환합니다.
+
+
+ 플레이그라운드에서 엔드포인트 시도하기
+
+
+**매개변수**
+
+없음
+
+**반환 값**
+
+정확한 반환 데이터는 클라이언트 구현에 따라 다릅니다. 모든 클라이언트는 노드가 동기화되지 않을 때 `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..f8ef4ba8ec1
--- /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}
+
+이더리움에서 사용되는 다양한 합의 메커니즘에 대해 자세히 알아보세요.
+
+
+
+### 시빌 저항 및 체인 선택 {#sybil-chain}
+
+작업 증명과 지분 증명은 실제로는 합의 프로토콜이 아니지만, 간단하게 설명하기 위해 종종 그렇게 불립니다. 사실, 이들은 시빌 저항 메커니즘이자 블록 작성자를 선택하는 방법입니다. 체인 선택(또는 포크 선택) 알고리즘은 여러 블록이 동일한 위치에 있을 때 한 블록을 선택하는 데 사용됩니다.
+
+**시빌 저항성**은 프로토콜이 시빌 공격에 얼마나 잘 대처하는지를 측정합니다. 탈중앙화된 블록체인의 핵심인 시빌 저항은 채굴자와 검증자가 자원 투입에 따라 공정하게 보상받도록 합니다. 작업 증명과 지분 증명은 사용자가 많은 에너지를 소비하거나 많은 담보를 걸도록 하여 시빌 공격을 방어합니다. 이러한 보호 장치는 시빌 공격에 대한 경제적 억제책입니다.
+
+**체인 선택 규칙**은 어떤 체인이 "올바른" 체인인지 결정하는 데 사용됩니다. 비트코인은 "가장 긴 체인" 규칙을 사용합니다. 즉, 가장 긴 블록체인이 나머지 노드가 유효하다고 인식하고 작업할 블록체인입니다. 작업증명 체인에서는 체인의 총 누적 작업증명 난이도로 가장 긴 체인이 결정됩니다. 이전에는 이더리움도 가장 긴 체인 규칙을 사용했으나, 현재 이더리움은 작업증명에서 지분증명으로 전환되어 '체인의 무게'를 측정하는 업데이트된 포크 선택 알고리즘을 채택했습니다. 이 무게는 검증자의 지분-이더리움 잔액에 의해 가중된 검증자 투표의 누적 합계입니다.
+
+이더리움은 [Casper FFG 지분 증명](https://arxiv.org/abs/1710.09437)과 [GHOST 포크 선택 규칙](https://arxiv.org/abs/2003.03052)을 결합한 [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)라는 합의 메커니즘을 사용합니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [블록체인 합의 알고리즘이란?](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm)
+- [나카모토 합의란 무엇인가요? 완전 초보자 가이드](https://blockonomi.com/nakamoto-consensus/)
+- [Casper는 어떻게 작동하는가?](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d)
+- [작업 증명 블록체인의 보안 및 성능에 관하여](https://eprint.iacr.org/2016/555.pdf)
+- [비잔틴 장애](https://en.wikipedia.org/wiki/Byzantine_fault)
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
+
+## 관련 주제 {#related-topics}
+
+- [작업 증명](/developers/docs/consensus-mechanisms/pow/)
+- [채굴](/developers/docs/consensus-mechanisms/pow/mining/)
+- [지분 증명](/developers/docs/consensus-mechanisms/pos/)
+- [권위 증명](/developers/docs/consensus-mechanisms/poa/)
diff --git a/public/content/translations/ko/developers/docs/consensus-mechanisms/poa/index.md b/public/content/translations/ko/developers/docs/consensus-mechanisms/poa/index.md
new file mode 100644
index 00000000000..9868d6e1906
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/consensus-mechanisms/poa/index.md
@@ -0,0 +1,80 @@
+---
+title: "권한 증명(Proof-of-authority, PoA)"
+description: "권위 증명 합의 프로토콜과 블록체인 생태계에서의 역할에 대한 설명입니다."
+lang: ko
+---
+
+\*\*권위 증명(PoA)\*\*은 [지분 증명](/developers/docs/consensus-mechanisms/pos/)을 수정한 버전으로, 평판 기반의 합의 알고리즘입니다. 주로 프라이빗 체인, 테스트넷 및 로컬 개발 네트워크에서 사용됩니다. PoA는 지분 증명(PoS)의 지분 기반 메커니즘 대신 승인된 서명자 집합을 신뢰하여 블록을 생성해야 하는 평판 기반 합의 알고리즘입니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 [트랜잭션](/developers/docs/transactions/), [블록](/developers/docs/blocks/), [합의 메커니즘](/developers/docs/consensus-mechanisms/)에 대해 읽어보시는 것을 추천합니다.
+
+## 권위 증명(PoA)이란 무엇인가요? {#what-is-poa}
+
+권위 증명은 \*\*[지분 증명](/developers/docs/consensus-mechanisms/pos/)(PoS)\*\*의 수정된 버전으로, PoS의 지분 기반 메커니즘 대신 평판 기반의 합의 알고리즘을 사용합니다. 이 용어는 2017년 개빈 우드(Gavin Wood)가 처음 소개했으며, 이 합의 알고리즘은 작업 증명(PoW)처럼 고품질의 리소스를 필요로 하지 않고 블록체인을 저장하고 블록을 생성하는 노드의 작은 하위 집합을 통해 지분 증명(PoS)의 확장성 문제를 극복하므로 주로 프라이빗 체인, 테스트넷, 로컬 개발 네트워크에서 사용되어 왔습니다.
+
+권위 증명은 [제네시스 블록](/glossary/#genesis-block)에 설정된 승인된 서명자 집합을 신뢰해야 합니다. 대부분의 현재 구현에서 모든 승인된 서명자는 체인의 합의를 결정할 때 동등한 권한과 특권을 보유합니다. 평판 스테이킹의 기본 아이디어는 고객 신원 확인(KYC) 등을 통해 모든 승인된 검증자가 모든 사람에게 잘 알려져 있거나, 잘 알려진 조직이 유일한 검증자가 되는 것입니다. 이렇게 하면 검증자가 잘못된 행동을 할 경우 신원이 알려집니다.
+
+PoA에는 여러 구현이 있지만, 표준 이더리움 구현은 [EIP-225](https://eips.ethereum.org/EIPS/eip-225)를 구현하는 **clique**입니다. Clique는 개발자 친화적이고 구현하기 쉬운 표준이며, 모든 클라이언트 동기화 유형을 지원합니다. 다른 구현으로는 [IBFT 2.0](https://besu.hyperledger.org/private-networks/concepts/poa) 및 [Aura](https://openethereum.github.io/Chain-specification)가 있습니다.
+
+## 작동 방식 {#how-it-works}
+
+PoA에서는 승인된 서명자 집합이 새 블록을 생성하도록 선택됩니다. 서명자는 평판에 따라 선택되며, 새 블록을 생성할 수 있는 유일한 주체입니다. 서명자는 라운드 로빈 방식으로 선택되며, 각 서명자는 특정 시간 프레임 내에 블록을 생성할 수 있습니다. 블록 생성 시간은 고정되어 있으며, 서명자는 해당 시간 프레임 내에 블록을 생성해야 합니다.
+
+이 맥락에서 평판은 정량화된 것이 아니라 Microsoft나 Google과 같은 잘 알려진 기업의 평판을 의미합니다. 따라서 신뢰할 수 있는 서명자를 선택하는 방식은 알고리즘적인 것이 아니라, 예를 들어 Microsoft가 수백 또는 수천 개의 스타트업 간에 PoA 프라이빗 네트워크를 생성하고 유일하게 신뢰할 수 있는 서명자로서 역할을 수행하며 향후 Google과 같은 다른 잘 알려진 서명자를 추가할 가능성을 두는 것과 같이 _신뢰_라는 일반적인 인간의 행위입니다. 스타트업들은 의심의 여지 없이 Microsoft가 항상 정직하게 행동하고 네트워크를 사용할 것이라고 신뢰할 것입니다. 이는 많은 전력과 리소스를 소비하는 채굴자의 필요성과 함께, 서로 다른 목적으로 구축된 다양한 소규모/프라이빗 네트워크를 분산화되고 기능하도록 유지하기 위해 스테이킹할 필요를 해결합니다. VeChain과 같은 일부 프라이빗 네트워크는 PoA 표준을 그대로 사용하고, Binance와 같은 일부는 PoA와 지분 증명(PoS)의 맞춤형 수정 버전인 [PoSA](https://academy.binance.com/en/glossary/proof-of-staked-authority-posa)를 사용하여 이를 수정합니다.
+
+투표 과정은 서명자 자신에 의해 수행됩니다. 각 서명자는 새 블록을 생성할 때 자신의 블록에서 서명자의 추가 또는 제거에 투표합니다. 투표는 노드에 의해 집계되며, 투표가 특정 임계값 `SIGNER_LIMIT`에 도달하면 서명자가 추가되거나 제거됩니다.
+
+작은 포크가 발생하는 상황이 있을 수 있으며, 블록의 난이도는 블록이 순서대로 서명되었는지 또는 순서에 맞지 않게 서명되었는지에 따라 달라집니다. “순서대로” 서명된 블록은 난이도 2를 갖고, “순서에 맞지 않게” 서명된 블록은 난이도 1을 갖습니다. 작은 포크의 경우, 대부분의 서명자가 “순서대로” 블록을 봉인하는 체인이 가장 높은 난이도를 축적하여 승리하게 됩니다.
+
+## 공격 벡터 {#attack-vectors}
+
+### 악의적인 서명자 {#malicious-signers}
+
+악의적인 사용자가 서명자 목록에 추가되거나 서명 키/기기가 손상될 수 있습니다. 이러한 시나리오에서 프로토콜은 재구성과 스팸으로부터 자신을 방어할 수 있어야 합니다. 제안된 해결책은 N명의 승인된 서명자 목록이 주어졌을 때, 모든 서명자는 K 블록마다 1개의 블록만 발행할 수 있다는 것입니다. 이를 통해 피해를 제한하고 나머지 검증자가 악의적인 사용자를 투표로 퇴출시킬 수 있습니다.
+
+### 검열 {#censorship-attack}
+
+또 다른 흥미로운 공격 벡터는 서명자(또는 서명자 그룹)가 승인 목록에서 자신을 제거하는 데 투표하는 블록을 검열하려고 시도하는 경우입니다. 이 문제를 해결하기 위해 서명자의 허용된 발행 빈도는 N/2 중 1로 제한됩니다. 이를 통해 악의적인 서명자는 서명 계정의 최소 51%를 제어해야 하며, 이 시점에서 이들은 사실상 체인의 새로운 신뢰의 원천이 됩니다.
+
+### 스팸 {#spam-attack}
+
+또 다른 작은 공격 벡터는 악의적인 서명자가 발행하는 모든 블록 내에 새로운 투표 제안을 주입하는 것입니다. 노드는 실제 승인된 서명자 목록을 생성하기 위해 모든 투표를 집계해야 하므로 시간이 지남에 따라 모든 투표를 기록해야 합니다. 투표 창에 제한을 두지 않으면 이 목록은 느리지만 무한정으로 증가할 수 있습니다. 해결책은 W 블록의 _이동_ 창을 두어 그 이후의 투표는 오래된 것으로 간주하는 것입니다. _합리적인 창은 1~2 에폭이 될 수 있습니다._
+
+### 동시 블록 {#concurrent-blocks}
+
+PoA 네트워크에서 N명의 승인된 서명자가 있을 때 각 서명자는 K 블록 중 1개의 블록을 발행할 수 있습니다. 이는 특정 시점에 N-K+1명의 검증자가 발행할 수 있음을 의미합니다. 이러한 검증자들이 블록 경쟁을 하는 것을 방지하기 위해 각 서명자는 새 블록을 릴리스하는 시간에 작은 무작위 "오프셋"을 추가해야 합니다. 이 프로세스는 작은 포크를 드물게 만들지만, 메인넷처럼 가끔 포크가 발생할 수 있습니다. 서명자가 권력을 남용하고 혼란을 야기하는 것이 발견되면 다른 서명자들이 투표를 통해 퇴출시킬 수 있습니다.
+
+예를 들어, 10명의 승인된 서명자가 있고 각 서명자가 20개의 블록 중 1개의 블록을 생성할 수 있다면, 특정 시점에 11명의 검증자가 블록을 생성할 수 있습니다. 그들이 블록 생성을 위해 경쟁하는 것을 방지하기 위해 각 서명자는 새 블록을 릴리스하는 시간에 작은 무작위 "오프셋"을 추가합니다. 이는 작은 포크의 발생을 줄이지만 이더리움 메인넷에서 볼 수 있듯이 가끔 포크가 발생할 수 있습니다. 서명자가 자신의 권한을 오용하고 혼란을 야기하면 네트워크에서 투표로 퇴출될 수 있습니다.
+
+## 장단점 {#pros-and-cons}
+
+| 장점 | 단점 |
+| ------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
+| 제한된 수의 블록 서명자를 기반으로 하므로 지분 증명(PoS) 및 작업 증명(PoW)과 같은 다른 인기 있는 메커니즘보다 확장성이 뛰어납니다. | PoA 네트워크는 일반적으로 상대적으로 적은 수의 검증 노드를 가집니다. 이로 인해 PoA 네트워크는 더 중앙화됩니다. |
+| PoA 블록체인은 운영 및 유지 비용이 매우 저렴합니다. | 블록체인은 확립된 평판을 가진 주체를 요구하기 때문에, 일반인이 승인된 서명자가 되는 것은 일반적으로 어렵습니다. |
+| 새 블록을 검증하는 데 제한된 수의 서명자만 필요하기 때문에 트랜잭션이 1초 이내로 매우 빠르게 확인될 수 있습니다. | 악의적인 서명자는 네트워크에서 재구성을 하거나, 이중 지불을 하거나, 트랜잭션을 검열할 수 있으며, 이러한 공격은 완화되었지만 여전히 가능합니다. |
+
+## 더 읽어보기 {#further-reading}
+
+- [EIP-225](https://eips.ethereum.org/EIPS/eip-225) _Clique 표준_
+- [권위 증명 연구](https://github.com/cryptoeconomics-study/website/blob/master/docs/sync/2.4-lecture.md) _Cryptoeconomics_
+- [권위 증명이란 무엇인가](https://forum.openzeppelin.com/t/proof-of-authority/3577) _OpenZeppelin_
+- [권위 증명 설명](https://academy.binance.com/en/articles/proof-of-authority-explained) _binance_
+- [블록체인의 PoA](https://medium.com/techskill-brew/proof-of-authority-or-poa-in-blockchain-part-11-blockchain-series-be15b3321cba)
+- [Clique 설명](https://medium.com/@Destiner/clique-cross-client-proof-of-authority-algorithm-for-ethereum-8b2a135201d)
+- [더 이상 사용되지 않는 PoA, Aura 사양](https://openethereum.github.io/Chain-specification)
+- [IBFT 2.0, 또 다른 PoA 구현](https://besu.hyperledger.org/private-networks/concepts/poa)
+
+### 시각 자료를 찾고 있나요? 시각적 학습자
+
+권위 증명에 대한 시각적 설명을 시청하세요:
+
+
+
+## 관련 주제 {#related-topics}
+
+- [작업 증명](/developers/docs/consensus-mechanisms/pow/)
+- [지분 증명](/developers/docs/consensus-mechanisms/pos/)
+
diff --git a/public/content/translations/ko/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/ko/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md
new file mode 100644
index 00000000000..f26059493cc
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md
@@ -0,0 +1,166 @@
+---
+title: "이더리움 지분 증명 공격과 방어"
+description: "지분 증명 이더리움에 대해 알려진 공격 벡터와 방어 방법에 대해 알아보세요."
+lang: ko
+---
+
+도둑과 사보타주들은 이더리움의 클라이언트 소프트웨어를 공격할 기회를 끊임없이 찾고 있습니다. 이 페이지에서는 이더리움의 합의 레이어에 대해 알려진 공격 벡터와 해당 공격을 방어하는 방법을 간략하게 설명합니다. 이 페이지의 정보는 [더 긴 버전](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)에서 발췌한 것입니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+[지분 증명](/developers/docs/consensus-mechanisms/pos/)에 대한 몇 가지 기본 지식이 필요합니다. 또한 이더리움의 [인센티브 레이어](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)와 포크 선택 알고리즘인 [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper)에 대한 기본적 이해가 있으면 도움이 될 것입니다.
+
+## 공격자는 무엇을 원할까요? {#what-do-attackers-want}
+
+성공적인 공격자가 새로운 이더를 생성하거나 임의의 계정에서 이더를 빼낼 수 있다는 것은 일반적인 오해입니다. 네트워크의 모든 실행 클라이언트가 모든 트랜잭션을 실행하기 때문에 이 두 가지 모두 불가능합니다. 유효성의 기본 조건(예: 발신자의 개인 키로 트랜잭션이 서명되었는지, 발신자에게 충분한 잔액이 있는지 등)을 충족해야 하며, 그렇지 않으면 간단히 되돌려집니다. 공격자가 현실적으로 목표로 삼을 수 있는 결과에는 재구성(reorgs), 이중 최종 승인 또는 최종 승인 지연의 세 가지 종류가 있습니다.
+
+\*\*“재구성(reorg)”\*\*은 정규 체인에 일부 블록이 추가되거나 제거되면서 블록이 새로운 순서로 재조정되는 것입니다. 악의적인 재구성은 특정 블록이 포함되거나 제외되도록 보장하여 이중 지불 또는 선행 매매 및 후행 매매 트랜잭션(MEV)을 통한 가치 추출을 허용할 수 있습니다. 재구성은 특정 트랜잭션이 정규 체인에 포함되는 것을 막는 데 사용될 수도 있는데, 이는 일종의 검열입니다. 재구성의 가장 극단적인 형태는 이전에 최종 승인된 블록을 제거하거나 대체하는 "최종 승인 되돌리기(finality reversion)"입니다. 이는 공격자에 의해 전체 스테이킹된 이더의 ⅓ 이상이 파괴되어야만 가능하며, 이 보증은 "경제적 최종 승인(economic finality)"으로 알려져 있습니다. 이에 대해서는 나중에 자세히 설명하겠습니다.
+
+**이중 최종 승인**은 두 개의 포크가 동시에 최종 승인될 수 있는, 가능성은 낮지만 심각한 상태로, 체인에 영구적인 분열을 일으킵니다. 이것은 전체 스테이킹된 이더의 34%를 감수할 의향이 있는 공격자에게 이론적으로 가능합니다. 커뮤니티는 오프체인에서 협력하여 어떤 체인을 따를지에 대한 합의에 도달해야 하며, 이를 위해서는 소셜 레이어의 힘이 필요합니다.
+
+**최종 승인 지연** 공격은 네트워크가 체인의 섹션을 최종 승인하는 데 필요한 조건에 도달하는 것을 방해합니다. 최종 승인이 없으면 이더리움 위에 구축된 금융 애플리케이션을 신뢰하기 어렵습니다. 최종 승인 지연 공격의 목표는 공격자가 전략적 공매도 포지션을 가지고 있지 않는 한 직접적인 이익을 얻기보다는 단순히 이더리움을 방해하는 것일 가능성이 높습니다.
+
+소셜 레이어에 대한 공격은 이더리움에 대한 대중의 신뢰를 약화시키고, 이더의 가치를 떨어뜨리고, 채택을 줄이거나, 이더리움 커뮤니티를 약화시켜 대역 외(out-of-band) 조정을 더 어렵게 만드는 것을 목표로 할 수 있습니다.
+
+적대자가 이더리움을 공격할 수 있는 이유를 확인했으므로 다음 섹션에서는 그들이 _어떻게_ 공격할 수 있는지 살펴봅니다.
+
+## 공격 방법 {#methods-of-attack}
+
+### 레이어 0 공격 {#layer-0}
+
+우선, 이더리움에 적극적으로 참여하지 않는 개인(클라이언트 소프트웨어를 실행하여)은 소셜 레이어(레이어 0)를 표적으로 삼아 공격할 수 있습니다. 레이어 0은 이더리움이 구축된 기반이며, 따라서 스택의 나머지 부분에 파급 효과를 미치는 공격에 대한 잠재적인 공격 표면을 나타냅니다. 몇 가지 예는 다음과 같습니다.
+
+- 잘못된 정보 캠페인은 커뮤니티가 이더리움의 로드맵, 개발자 팀, 앱 등에 대해 가지고 있는 신뢰를 약화시킬 수 있습니다. 이는 네트워크 보안에 기꺼이 참여하려는 개인의 수를 감소시켜 탈중앙화와 암호 경제적 보안을 모두 저하시킬 수 있습니다.
+
+- 개발자 커뮤니티를 대상으로 한 표적 공격 및/또는 위협. 이는 개발자의 자발적인 이탈로 이어져 이더리움의 발전을 늦출 수 있습니다.
+
+- 지나치게 열성적인 규제 또한 레이어 0에 대한 공격으로 간주될 수 있는데, 이는 참여와 채택을 급격히 저해할 수 있기 때문입니다.
+
+- 자전거 보관소 논쟁(bike-shedding)으로 진행을 늦추고, 핵심 결정을 지연시키며, 스팸을 생성하는 등을 목표로 하는 지식이 있지만 악의적인 행위자가 개발자 커뮤니티에 침투하는 것.
+
+- 의사 결정에 영향을 미치기 위해 이더리움 생태계의 핵심 인물에게 제공되는 뇌물.
+
+이러한 공격이 특히 위험한 이유는 많은 경우에 자본이나 기술적 노하우가 거의 필요하지 않기 때문입니다. 레이어 0 공격은 암호 경제적 공격에 대한 승수(multiplier)가 될 수 있습니다. 예를 들어, 악의적인 대다수 지분 보유자에 의해 검열이나 최종 승인 되돌리기가 달성되면, 소셜 레이어를 약화시켜 커뮤니티가 대역 외로 대응을 조정하기가 더 어려워질 수 있습니다.
+
+레이어 0 공격에 대한 방어는 아마도 간단하지 않겠지만, 몇 가지 기본 원칙을 수립할 수 있습니다. 한 가지는 블로그, 디스코드 서버, 주석이 달린 사양, 책, 팟캐스트, 유튜브를 통해 커뮤니티의 정직한 구성원들이 생성하고 전파하는 이더리움에 대한 공개 정보에 대해 전반적으로 높은 신호 대 잡음비를 유지하는 것입니다. 저희 ethereum.org에서는 정확한 정보를 유지하고 가능한 한 많은 언어로 번역하기 위해 열심히 노력하고 있습니다. 공간을 고품질 정보와 밈(meme)으로 채우는 것은 잘못된 정보에 대한 효과적인 방어입니다.
+
+소셜 레이어 공격에 대한 또 다른 중요한 방어책은 명확한 사명 선언문과 거버넌스 프로토콜입니다. 이더리움은 스마트 계약 레이어 1 중에서 탈중앙화 및 보안의 챔피언으로 자리매김했으며 확장성과 지속 가능성도 매우 중요하게 생각합니다. 이더리움 커뮤니티에서 어떤 의견 차이가 발생하더라도 이러한 핵심 원칙은 최소한으로만 훼손됩니다. 이러한 핵심 원칙에 비추어 내러티브를 평가하고 EIP(이더리움 개선 제안) 프로세스에서 연속적인 검토 라운드를 통해 이를 검토하면 커뮤니티가 선한 행위자와 악의적인 행위자를 구별하고 악의적인 행위자가 이더리움의 미래 방향에 영향을 미칠 수 있는 범위를 제한하는 데 도움이 될 수 있습니다.
+
+마지막으로, 이더리움 커뮤니티가 모든 참여자에게 개방적이고 환영하는 자세를 유지하는 것이 중요합니다. 문지기(gatekeeper)와 배타성이 있는 커뮤니티는 "우리와 그들"이라는 내러티브를 구축하기 쉽기 때문에 사회적 공격에 특히 취약합니다. 부족주의와 유해한 극단주의는 커뮤니티에 해를 끼치고 레이어 0의 보안을 약화시킵니다. 네트워크 보안에 기득권을 가진 이더리안은 온라인과 현실 세계(meatspace)에서의 행동을 이더리움 레이어 0의 보안에 직접적인 기여자로 보아야 합니다.
+
+### 프로토콜 공격 {#attacking-the-protocol}
+
+누구나 이더리움의 클라이언트 소프트웨어를 실행할 수 있습니다. 클라이언트에 검증자를 추가하려면 사용자는 예치 계약에 32 이더를 스테이킹해야 합니다. 검증자를 통해 사용자는 새로운 블록을 제안하고 증명함으로써 이더리움의 네트워크 보안에 적극적으로 참여할 수 있습니다. 검증자는 이제 블록체인의 미래 내용에 영향을 미칠 수 있는 목소리를 갖게 됩니다. 그들은 정직하게 그렇게 하여 보상을 통해 이더 보유량을 늘리거나, 자신의 스테이킹을 위험에 빠뜨리면서 자신의 이익을 위해 프로세스를 조작하려고 시도할 수 있습니다. 공격을 감행하는 한 가지 방법은 총 스테이킹의 더 큰 비율을 축적한 다음 이를 사용하여 정직한 검증자를 투표로 이기는 것입니다. 공격자가 통제하는 스테이킹의 비율이 클수록 투표권이 커지며, 특히 나중에 살펴볼 특정 경제적 이정표에서 더욱 그렇습니다. 그러나 대부분의 공격자는 이런 방식으로 공격할 만큼 충분한 이더를 축적할 수 없으므로, 대신 정직한 다수가 특정 방식으로 행동하도록 조종하기 위해 미묘한 기술을 사용해야 합니다.
+
+기본적으로 모든 소규모 스테이킹 공격은 두 가지 유형의 검증자 부정 행위에 대한 미묘한 변형입니다. 즉, 활동 부족(증명/제안 실패 또는 늦게 수행) 또는 과잉 활동(슬롯에서 너무 여러 번 제안/증명)입니다. 가장 기본적인 형태에서 이러한 행동은 포크 선택 알고리즘과 인센티브 레이어에서 쉽게 처리되지만, 공격자의 이익을 위해 시스템을 이용하는 영리한 방법이 있습니다.
+
+### 소량의 ETH를 사용한 공격 {#attacks-by-small-stakeholders}
+
+#### 재구성(reorgs) {#reorgs}
+
+몇몇 논문에서는 총 스테이킹된 이더의 일부만으로 재구성 또는 최종 승인 지연을 달성하는 이더리움에 대한 공격을 설명했습니다. 이러한 공격은 일반적으로 공격자가 다른 검증자로부터 일부 정보를 보류한 다음 미묘한 방식으로 및/또는 적절한 순간에 공개하는 것에 의존합니다. 일반적으로 정규 체인에서 일부 정직한 블록을 대체하는 것을 목표로 합니다. [Neuder 외 2020](https://arxiv.org/pdf/2102.02247.pdf)은 공격하는 검증자가 특정 슬롯 `n+1`에 대한 블록(`B`)을 생성하고 증명할 수 있지만 네트워크의 다른 노드에 전파하는 것을 자제하는 방법을 보여주었습니다. 대신, 다음 슬롯 `n+2`까지 증명된 블록을 보유합니다. 정직한 검증자는 슬롯 `n+2`에 대한 블록(`C`)을 제안합니다. 거의 동시에 공격자는 보류된 블록(`B`)과 그에 대한 보류된 인증을 공개하고, 슬롯 `n+2`에 대한 투표로 `B`가 체인의 헤드임을 증명하여 정직한 블록 `C`의 존재를 효과적으로 부정할 수 있습니다. 정직한 블록 `D`가 공개되면 포크 선택 알고리즘은 `B` 위에 구축된 `D`가 `C` 위에 구축된 `D`보다 더 무겁다고 봅니다. 따라서 공격자는 1블록 사전 재구성(ex ante reorg)을 사용하여 슬롯 `n+2`의 정직한 블록 `C`를 정규 체인에서 제거하는 데 성공했습니다. [이 노트](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair)에 설명된 바와 같이, [34%의 스테이킹을 가진 공격자](https://www.youtube.com/watch?v=6vzXwwk12ZE)는 이 공격에 성공할 가능성이 매우 높습니다. 하지만 이론적으로는 더 작은 스테이킹으로도 이 공격을 시도할 수 있습니다. [Neuder 외 2020](https://arxiv.org/pdf/2102.02247.pdf)은 30%의 스테이킹으로 이 공격이 작동한다고 설명했지만, 나중에 [총 스테이킹의 2%](https://arxiv.org/pdf/2009.04987.pdf)로도 가능하며, 다음 섹션에서 살펴볼 균형 조정 기술을 사용하여 [단일 검증자](https://arxiv.org/abs/2110.10086#)에 대해서도 가능하다는 것이 밝혀졌습니다.
+
+
+
+위에 설명된 1블록 재구성 공격의 개념도(https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair에서 발췌)
+
+더 정교한 공격은 정직한 검증자 집합을 체인의 헤드에 대해 서로 다른 견해를 가진 개별 그룹으로 분할할 수 있습니다. 이를 \*\*균형 공격(balancing attack)\*\*이라고 합니다. 공격자는 블록을 제안할 기회를 기다리다가 기회가 오면 이중 제안을 합니다. 그들은 한 블록을 정직한 검증자 집합의 절반에 보내고 다른 블록을 나머지 절반에 보냅니다. 이중 제안은 포크 선택 알고리즘에 의해 감지되고 블록 제안자는 슬래싱되어 네트워크에서 퇴출되지만, 두 블록은 여전히 존재하며 각 포크에 대해 약 절반의 검증자 집합이 증명하게 됩니다. 한편, 나머지 악의적인 검증자들은 자신의 인증을 보류합니다. 그런 다음 포크 선택 알고리즘이 실행될 때 한쪽 또는 다른 쪽 포크를 선호하는 인증을 필요한 만큼의 검증자에게만 선택적으로 공개함으로써 누적된 인증 가중치를 한쪽 또는 다른 쪽 포크에 유리하도록 기울입니다. 이는 공격하는 검증자들이 두 포크에 걸쳐 검증자들을 균등하게 분할하여 무기한 계속될 수 있습니다. 어느 포크도 2/3의 절대다수를 확보할 수 없으므로 네트워크는 최종 승인되지 않습니다.
+
+\*\*바운싱 공격(Bouncing attack)\*\*도 비슷합니다. 공격하는 검증자들은 다시 투표를 보류합니다. 두 포크 간에 균등한 분할을 유지하기 위해 투표를 공개하는 대신, 그들은 적절한 순간에 투표를 사용하여 포크 A와 포크 B 사이를 번갈아 가며 체크포인트를 정당화합니다. 두 포크 간에 이러한 정당화의 번복은 어느 체인에서도 최종 승인될 수 있는 정당화된 소스 및 타겟 체크포인트 쌍이 존재하는 것을 막아 최종 승인을 중단시킵니다.
+
+
+
+바운싱 및 균형 공격 모두 공격자가 네트워크 전체의 메시지 타이밍을 매우 정밀하게 제어하는 데 의존하며, 이는 가능성이 낮습니다. 그럼에도 불구하고, 느린 메시지에 비해 신속한 메시지에 추가 가중치를 부여하는 형태로 프로토콜에 방어 기능이 내장되어 있습니다. 이는 [제안자 가중치 부스팅](https://github.com/ethereum/consensus-specs/pull/2730)으로 알려져 있습니다. 바운싱 공격을 방어하기 위해 포크 선택 알고리즘이 업데이트되어, 최신 정당화된 체크포인트는 [각 에포크의 슬롯 중 처음 1/3 동안](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114)에만 대체 체인의 체크포인트로 전환될 수 있습니다. 이 조건은 공격자가 나중에 배포하기 위해 투표를 저장하는 것을 방지합니다. 포크 선택 알고리즘은 대부분의 정직한 검증자가 투표했을 에포크의 처음 1/3 동안 선택한 체크포인트에 충실하게 유지됩니다.
+
+종합적으로, 이러한 조치들은 정직한 블록 제안자가 슬롯 시작 직후 매우 빠르게 블록을 내보내고, 그 다음 약 1/3 슬롯(4초) 동안 해당 새 블록이 포크 선택 알고리즘을 다른 체인으로 전환하게 할 수 있는 시나리오를 만듭니다. 해당 마감 시간 이후에 느린 검증자로부터 도착하는 인증은 더 일찍 도착한 인증에 비해 가중치가 낮아집니다. 이는 체인의 헤드를 결정하는 데 있어 신속한 제안자와 검증자에게 강력하게 유리하며, 성공적인 균형 또는 바운싱 공격의 가능성을 크게 줄입니다.
+
+제안자 부스팅만으로는 "저렴한 재구성(cheap reorgs)", 즉 소규모 스테이킹을 가진 공격자가 시도하는 재구성에만 방어한다는 점에 유의할 가치가 있습니다. 사실, 제안자 부스팅 자체는 더 큰 지분 보유자에 의해 이용될 수 있습니다. [이 게시물](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127)의 저자들은 7%의 스테이킹을 가진 공격자가 정직한 블록을 재구성하여 정직한 검증자를 속여 자신의 포크 위에 구축하도록 전략적으로 투표를 배포하는 방법을 설명합니다. 이 공격은 매우 가능성이 낮은 이상적인 지연 시간 조건을 가정하여 고안되었습니다. 공격자의 성공 확률은 여전히 매우 낮으며, 더 큰 스테이킹은 더 많은 자본이 위험에 처해 있고 더 강력한 경제적 저해 요인이 있음을 의미합니다.
+
+제안자 부스팅에도 불구하고 실행 가능하다고 제안된 [LMD 규칙을 구체적으로 겨냥한 균형 공격](https://ethresear.ch/t/balancing-attack-lmd-edition/11853)도 제안되었습니다. 공격자는 블록 제안을 이중으로 하고 각 블록을 네트워크의 약 절반에 전파하여 두 개의 경쟁 체인을 설정하고 포크 간에 대략적인 균형을 맞춥니다. 그런 다음, 공모하는 검증자들은 투표를 이중으로 하여 네트워크의 절반이 포크 `A`에 대한 투표를 먼저 받고 나머지 절반이 포크 `B`에 대한 투표를 먼저 받도록 시간을 맞춥니다. LMD 규칙은 두 번째 인증을 버리고 각 검증자에 대해 첫 번째 인증만 유지하므로, 네트워크의 절반은 `A`에 대한 투표를 보고 `B`에 대한 투표는 보지 못하며, 나머지 절반은 `B`에 대한 투표를 보고 `A`에 대한 투표는 보지 못합니다. 저자들은 LMD 규칙이 적에게 균형 공격을 감행할 "놀라운 힘"을 준다고 설명합니다.
+
+이 LMD 공격 벡터는 [포크 선택 알고리즘을 업데이트](https://github.com/ethereum/consensus-specs/pull/2845)하여 이중 투표하는 검증자를 포크 선택 고려에서 완전히 제외함으로써 해결되었습니다. 이중 투표하는 검증자는 또한 포크 선택 알고리즘에 의해 미래의 영향력이 할인됩니다. 이는 위에서 설명한 균형 공격을 방지하는 동시에 애벌랜치 공격에 대한 복원력을 유지합니다.
+
+[**애벌랜치 공격**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3)이라는 또 다른 종류의 공격은 [2022년 3월 논문](https://arxiv.org/pdf/2203.01315.pdf)에서 설명되었습니다. 애벌랜치 공격을 감행하려면 공격자는 여러 연속적인 블록 제안자를 제어해야 합니다. 각 블록 제안 슬롯에서 공격자는 자신의 블록을 보류하고 정직한 체인이 보류된 블록과 동일한 하위 트리 가중치에 도달할 때까지 수집합니다. 그런 다음, 보류된 블록은 최대한 이중 제안되도록 공개됩니다. 저자들은 균형 및 바운싱 공격에 대한 주요 방어책인 제안자 부스팅이 일부 애벌랜치 공격 변종에 대해서는 보호하지 못한다고 제안합니다. 그러나 저자들은 또한 이더리움의 포크 선택 알고리즘의 매우 이상화된 버전(LMD 없이 GHOST를 사용)에서만 공격을 시연했습니다.
+
+애벌랜치 공격은 LMD-GHOST 포크 선택 알고리즘의 LMD 부분에 의해 완화됩니다. LMD는 “최신 메시지 기반(latest-message-driven)”을 의미하며, 각 검증자가 다른 검증자로부터 받은 최신 메시지를 포함하는 테이블을 참조합니다. 해당 필드는 새 메시지가 특정 검증자에 대해 테이블에 이미 있는 슬롯보다 더 늦은 슬롯에서 온 경우에만 업데이트됩니다. 실제로 이는 각 슬롯에서 수신된 첫 번째 메시지가 수락된 메시지이며 추가 메시지는 무시해야 할 이중 제안임을 의미합니다. 다시 말해, 합의 클라이언트는 이중 제안을 계산하지 않습니다. 각 검증자로부터 처음 도착한 메시지를 사용하고 이중 제안은 단순히 폐기되어 애벌랜치 공격을 방지합니다.
+
+제안자 부스트가 제공하는 보안에 추가될 수 있는 포크 선택 규칙에 대한 몇 가지 다른 잠재적인 미래 업그레이드가 있습니다. 하나는 [뷰 병합](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739)으로, 증명자는 슬롯 시작 `n`초 전에 포크 선택에 대한 뷰를 동결하고 제안자는 네트워크 전체에서 체인 뷰를 동기화하는 데 도움을 줍니다. 또 다른 잠재적인 업그레이드는 [단일 슬롯 최종 승인](https://notes.ethereum.org/@vbuterin/single_slot_finality)으로, 단 하나의 슬롯 후에 체인을 최종 승인함으로써 메시지 타이밍에 기반한 공격으로부터 보호합니다.
+
+#### 최종 승인 지연 {#finality-delay}
+
+저비용 단일 블록 재구성 공격을 처음 설명한 [같은 논문](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf)은 또한 공격자가 에포크 경계 블록의 블록 제안자가 되는 것에 의존하는 최종 승인 지연(일명 “활성 실패(liveness failure)”) 공격을 설명했습니다. 이러한 에포크 경계 블록은 Casper FFG가 체인의 일부를 최종 승인하는 데 사용하는 체크포인트가 되기 때문에 중요합니다. 공격자는 충분한 수의 정직한 검증자가 현재 최종 승인 대상으로 이전 에포크 경계 블록을 선호하는 FFG 투표를 사용할 때까지 단순히 블록을 보류합니다. 그런 다음 보류된 블록을 공개합니다. 그들은 자신의 블록을 증명하고 나머지 정직한 검증자들도 그렇게 하여 다른 타겟 체크포인트를 가진 포크를 생성합니다. 타이밍을 제대로 맞추면 어느 포크에도 2/3의 절대다수가 증명하지 않기 때문에 최종 승인을 막을 수 있습니다. 스테이킹이 작을수록 공격자가 직접 제어하는 인증 수가 적고, 주어진 에포크 경계 블록을 제안하는 검증자를 공격자가 제어할 확률이 낮기 때문에 타이밍이 더 정확해야 합니다.
+
+#### 장기 공격 {#long-range-attacks}
+
+또한 제네시스 블록에 참여한 검증자가 정직한 블록체인과 함께 별도의 블록체인 포크를 유지하다가 훨씬 나중에 적절한 시기에 정직한 검증자 집합을 해당 포크로 전환하도록 설득하는 것과 관련된 지분 증명 블록체인에 특정한 공격 유형이 있습니다. 이러한 유형의 공격은 모든 검증자가 정기적인 간격("체크포인트")으로 정직한 체인의 상태에 동의하도록 보장하는 최종 승인 장치 때문에 이더리움에서는 불가능합니다. 이 간단한 메커니즘은 이더리움 클라이언트가 최종 승인된 블록을 재구성하지 않기 때문에 장거리 공격자를 무력화합니다. 네트워크에 참여하는 새로운 노드는 신뢰할 수 있는 최근 상태 해시("[약한 주관성](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) 체크포인트")를 찾아 이를 의사 제네시스 블록으로 사용하여 그 위에 구축함으로써 그렇게 합니다. 이는 네트워크에 진입하는 새로운 노드가 스스로 정보를 확인하기 전에 '신뢰 게이트웨이'를 생성합니다.
+
+#### 서비스 거부 {#denial-of-service}
+
+이더리움의 지분 증명 메커니즘은 각 슬롯에서 전체 검증자 집합에서 단일 검증자를 블록 제안자로 선택합니다. 이는 공개적으로 알려진 함수를 사용하여 계산할 수 있으며, 적이 블록 제안 약간 전에 다음 블록 제안자를 식별하는 것이 가능합니다. 그런 다음 공격자는 블록 제안자에게 스팸을 보내 동료와 정보를 교환하는 것을 방지할 수 있습니다. 네트워크의 나머지 부분에는 블록 제안자가 오프라인인 것처럼 보이고 슬롯은 단순히 비어 있게 됩니다. 이는 특정 검증자에 대한 검열의 한 형태로, 그들이 블록체인에 정보를 추가하는 것을 막을 수 있습니다. 단일 비밀 리더 선출(SSLE) 또는 비단일 비밀 리더 선출을 구현하면 블록 제안자만이 자신이 선택되었음을 알고 선택이 사전에 알려지지 않기 때문에 서비스 거부(DoS) 위험을 완화할 수 있습니다. 이는 아직 구현되지 않았지만 활발한 [연구 개발](https://ethresear.ch/t/secret-non-single-leader-election/11789) 분야입니다.
+
+이 모든 것은 적은 스테이킹으로 이더리움을 성공적으로 공격하기가 매우 어렵다는 사실을 가리킵니다. 여기에 설명된 실행 가능한 공격은 이상적인 포크 선택 알고리즘, 비현실적인 네트워크 조건을 요구하거나, 클라이언트 소프트웨어에 대한 비교적 사소한 패치로 이미 공격 벡터가 닫혔습니다. 물론 이것이 제로데이 공격이 실제로 존재할 가능성을 배제하는 것은 아니지만, 소수 지분 공격자가 효과적이 되기 위해 요구되는 기술적 적성, 합의 레이어 지식 및 운의 매우 높은 기준을 보여줍니다. 공격자의 관점에서 최선의 방법은 가능한 한 많은 이더를 축적하고 총 스테이킹의 더 큰 비율로 무장하여 돌아오는 것일 수 있습니다.
+
+### 총 스테이킹의 >= 33%를 사용하는 공격자 {#attackers-with-33-stake}
+
+이 글에서 앞서 언급한 모든 공격은 공격자가 투표할 스테이킹된 이더가 더 많고 각 슬롯에서 블록을 제안하도록 선택될 수 있는 검증자가 더 많을 때 성공할 가능성이 더 높아집니다. 따라서 악의적인 검증자는 가능한 한 많은 스테이킹된 이더를 제어하는 것을 목표로 할 수 있습니다.
+
+스테이킹된 이더의 33%는 공격자의 벤치마크입니다. 왜냐하면 이 양보다 많으면 다른 검증자의 행동을 미세하게 제어할 필요 없이 체인이 최종 승인되는 것을 막을 수 있기 때문입니다. 그들은 단순히 함께 사라질 수 있습니다. 스테이킹된 이더의 1/3 이상이 악의적으로 증명하거나 증명에 실패하면 2/3의 절대다수가 존재할 수 없으며 체인은 최종 승인될 수 없습니다. 이에 대한 방어는 비활동 유출입니다. 비활동 유출은 증명에 실패하거나 다수와 반대로 증명하는 검증자를 식별합니다. 이러한 비증명 검증자가 소유한 스테이킹된 이더는 점차적으로 소멸되어 결국 전체의 1/3 미만을 차지하게 되어 체인이 다시 최종 승인될 수 있도록 합니다.
+
+비활동 유출의 목적은 체인이 다시 최종 승인되도록 하는 것입니다. 그러나 공격자도 스테이킹된 이더의 일부를 잃게 됩니다. 검증자가 슬래싱되지 않더라도 총 스테이킹된 이더의 33%를 차지하는 검증자들의 지속적인 비활동은 매우 비용이 많이 듭니다.
+
+이더리움 네트워크가 비동기적(즉, 메시지가 전송되고 수신되는 사이에 지연이 있음)이라고 가정하면, 총 스테이킹의 34%를 제어하는 공격자는 이중 최종 승인을 유발할 수 있습니다. 이는 공격자가 블록 생산자로 선택되었을 때 이중 제안을 한 다음 모든 검증자로 이중 투표를 할 수 있기 때문입니다. 이는 블록체인의 포크가 존재하는 상황을 만들며, 각 포크는 스테이킹된 이더의 34%가 투표합니다. 각 포크는 나머지 검증자의 50%만 찬성 투표하면 두 포크 모두 절대다수의 지지를 받게 되며, 이 경우 두 체인 모두 최종 승인될 수 있습니다(공격자 검증자의 34% + 나머지 66%의 절반 = 각 포크당 67%). 경쟁하는 블록은 각각 정직한 검증자의 약 50%에 의해 수신되어야 하므로 이 공격은 공격자가 네트워크를 통해 전파되는 메시지의 타이밍을 어느 정도 제어하여 정직한 검증자의 절반을 각 체인으로 유도할 수 있을 때만 실행 가능합니다. 공격자는 이 이중 최종 승인을 달성하기 위해 전체 스테이킹(오늘날의 검증자 집합으로 약 천만 이더의 34%)을 필연적으로 파괴할 것입니다. 왜냐하면 검증자의 34%가 동시에 이중 투표를 하기 때문이며, 이는 최대 상관 관계 페널티가 부과되는 슬래싱 가능한 위반입니다. 이 공격에 대한 방어는 총 스테이킹된 이더의 34%를 파괴하는 데 드는 막대한 비용입니다. 이 공격에서 복구하려면 이더리움 커뮤니티가 "대역 외"로 조정하여 한 포크 또는 다른 포크를 따르고 다른 포크를 무시하는 데 동의해야 합니다.
+
+### 총 스테이킹의 ~50%를 사용하는 공격자 {#attackers-with-50-stake}
+
+스테이킹된 이더의 50%에서 악의적인 검증자 그룹은 이론적으로 체인을 두 개의 동일한 크기의 포크로 분할한 다음 전체 50% 스테이킹을 사용하여 정직한 검증자 집합과 반대로 투표하여 두 포크를 유지하고 최종 승인을 막을 수 있습니다. 두 포크의 비활동 유출은 결국 두 체인 모두 최종 승인으로 이어질 것입니다. 이 시점에서 유일한 선택은 사회적 복구에 의존하는 것입니다.
+
+정직한 검증자 수, 네트워크 지연 시간 등의 변동을 고려할 때 적대적인 검증자 그룹이 총 스테이킹의 정확히 50%를 지속적으로 제어할 가능성은 매우 낮습니다. 이러한 공격을 감행하는 데 드는 막대한 비용과 성공 가능성이 낮은 점은 이성적인 공격자에게 강력한 저해 요인으로 보이며, 특히 50%를 초과하여 얻는 데 약간의 추가 투자를 하면 훨씬 더 많은 힘을 얻을 수 있습니다.
+
+총 스테이킹의 50% 이상에서 공격자는 포크 선택 알고리즘을 지배할 수 있습니다. 이 경우 공격자는 다수 투표로 증명할 수 있으므로 정직한 클라이언트를 속일 필요 없이 짧은 재구성을 할 수 있는 충분한 제어권을 갖게 됩니다. 정직한 검증자들의 포크 선택 알고리즘도 공격자가 선호하는 체인을 가장 무겁게 볼 것이므로 체인은 최종 승인될 수 있습니다. 이를 통해 공격자는 특정 트랜잭션을 검열하고, 단거리 재구성을 수행하며, 자신에게 유리하도록 블록을 재정렬하여 최대 MEV를 추출할 수 있습니다. 이에 대한 방어는 다수 스테이킹의 막대한 비용(현재 약 190억 달러)이며, 소셜 레이어가 개입하여 정직한 소수 포크를 채택하고 공격자의 스테이킹 가치를 극적으로 떨어뜨릴 가능성이 있기 때문에 공격자에 의해 위험에 처하게 됩니다.
+
+### 총 스테이킹의 >=66%를 사용하는 공격자 {#attackers-with-66-stake}
+
+총 스테이킹된 이더의 66% 이상을 가진 공격자는 정직한 검증자를 강요할 필요 없이 선호하는 체인을 최종 승인할 수 있습니다. 공격자는 단순히 선호하는 포크에 투표한 다음 최종 승인할 수 있습니다. 이는 그들이 부정직한 절대다수로 투표할 수 있기 때문입니다. 절대다수 지분 보유자로서 공격자는 항상 최종 승인된 블록의 내용을 제어하며, 지출, 되감기, 재지출, 특정 트랜잭션 검열, 의지에 따라 체인 재구성 등의 권한을 갖게 됩니다. 51% 대신 66%를 제어하기 위해 추가 이더를 구매함으로써 공격자는 사실상 사후 재구성 및 최종 승인 되돌리기(즉, 미래를 제어할 뿐만 아니라 과거를 변경하는 능력)를 구매하는 것입니다. 여기서 유일한 실제 방어책은 총 스테이킹된 이더의 66%에 달하는 막대한 비용과 대체 포크의 채택을 조정하기 위해 소셜 레이어로 돌아가는 옵션입니다. 다음 섹션에서 이에 대해 더 자세히 살펴볼 수 있습니다.
+
+## 사람: 최후의 방어선 {#people-the-last-line-of-defense}
+
+부정직한 검증자들이 선호하는 버전의 체인을 최종 승인하는 데 성공하면 이더리움 커뮤니티는 어려운 상황에 처하게 됩니다. 정규 체인에는 역사에 부정직한 부분이 포함되어 있는 반면, 정직한 검증자들은 대체(정직한) 체인에 증명한 것에 대해 처벌을 받을 수 있습니다. 최종 승인되었지만 잘못된 체인은 다수 클라이언트의 버그로 인해 발생할 수도 있습니다. 결국 궁극적인 대안은 소셜 레이어, 즉 레이어 0에 의존하여 상황을 해결하는 것입니다.
+
+이더리움의 지분 증명 합의의 강점 중 하나는 공격에 직면했을 때 커뮤니티가 사용할 수 있는 [다양한 방어 전략](https://youtu.be/1m12zgJ42dI?t=1712)이 있다는 것입니다. 최소한의 대응은 추가적인 페널티 없이 공격자의 검증자를 네트워크에서 강제로 퇴출시키는 것일 수 있습니다. 네트워크에 다시 참여하려면 공격자는 검증자 집합이 점진적으로 증가하도록 보장하는 활성화 대기열에 참여해야 합니다. 예를 들어, 스테이킹된 이더의 양을 두 배로 늘리기에 충분한 검증자를 추가하는 데는 약 200일이 걸리며, 이는 공격자가 또 다른 51% 공격을 시도하기 전에 정직한 검증자에게 200일을 벌어줍니다. 그러나 커뮤니티는 과거 보상을 취소하거나 스테이킹된 자본의 일부(최대 100%)를 소각하는 등 공격자를 더 가혹하게 처벌하기로 결정할 수도 있습니다.
+
+공격자에게 부과되는 페널티가 무엇이든, 커뮤니티는 또한 이더리움 클라이언트에 코딩된 포크 선택 알고리즘이 선호하는 체인임에도 불구하고 부정직한 체인이 사실상 유효하지 않으며 커뮤니티가 대신 정직한 체인 위에 구축해야 하는지 여부를 함께 결정해야 합니다. 정직한 검증자들은 예를 들어 공격이 시작되기 전에 정규 체인에서 포크되었거나 공격자의 검증자가 강제로 제거된, 커뮤니티가 수용한 이더리움 블록체인의 포크 위에 집합적으로 구축하기로 동의할 수 있습니다. 정직한 검증자들은 공격자의 체인에 (당연히) 증명하지 못한 것에 대해 적용되는 페널티를 피할 수 있기 때문에 이 체인 위에 구축하도록 인센티브를 받을 것입니다. 이더리움 위에 구축된 거래소, 온램프 및 애플리케이션은 아마도 정직한 체인에 있기를 선호할 것이며 정직한 검증자를 따라 정직한 블록체인으로 이동할 것입니다.
+
+그러나 이것은 상당한 거버넌스 과제가 될 것입니다. 일부 사용자와 검증자는 의심할 여지 없이 정직한 체인으로 다시 전환한 결과 손실을 입을 것이며, 공격 후 검증된 블록의 트랜잭션은 잠재적으로 롤백되어 애플리케이션 레이어를 방해할 수 있으며, 이는 단순히 "코드가 법이다"라고 믿는 경향이 있는 일부 사용자의 윤리를 훼손합니다. 거래소와 애플리케이션은 이제 롤백될 수 있는 온체인 트랜잭션에 오프체인 작업을 연결했을 가능성이 높으며, 이는 특히 부당 이득이 혼합되거나 DeFi 또는 다른 파생 상품에 예치되어 정직한 사용자에게 부차적인 영향을 미치는 경우 공정하게 풀기 어려운 취소 및 수정의 연쇄 반응을 시작할 것입니다. 의심할 여지 없이 일부 사용자, 아마도 기관 사용자조차도 약삭빠르거나 우연에 의해 부정직한 체인으로부터 이미 이익을 얻었을 것이며, 자신의 이익을 보호하기 위해 포크에 반대할 수 있습니다. 합리적이고 조정된 완화 조치가 신속하게 실행될 수 있도록 51% 초과 공격에 대한 커뮤니티 대응을 연습하라는 요구가 있었습니다. Vitalik이 ethresear.ch에서 [여기](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925)와 [여기](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363), 그리고 트위터에서 [여기](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw)에 유용한 논의가 있습니다. 조정된 사회적 대응의 목표는 공격자를 처벌하고 다른 사용자에 대한 영향을 최소화하는 데 매우 표적화되고 구체적이어야 합니다.
+
+거버넌스는 이미 복잡한 주제입니다. 부정직한 최종 승인 체인에 대한 레이어-0 비상 대응을 관리하는 것은 의심할 여지 없이 이더리움 커뮤니티에 어려운 일이겠지만, 이더리움 역사상 [두 번](/ethereum-forks/#tangerine-whistle)이나 [일어난 일](/ethereum-forks/#dao-fork-summary)입니다.
+
+그럼에도 불구하고, 최종적인 대안이 현실 세계에 있다는 것은 상당히 만족스러운 일입니다. 궁극적으로, 우리 위에 이 경이로운 기술 스택이 있더라도, 최악의 상황이 발생하면 실제 사람들이 협력하여 해결해야 할 것입니다.
+
+## 요약 {#summary}
+
+이 페이지에서는 공격자가 이더리움의 지분 증명 합의 프로토콜을 악용하려는 몇 가지 방법을 탐구했습니다. 총 스테이킹된 이더의 비율이 증가하는 공격자에 대한 재구성 및 최종 승인 지연이 탐구되었습니다. 전반적으로, 더 부유한 공격자는 자신의 스테이킹이 미래 블록의 내용에 영향을 미치는 데 사용할 수 있는 투표권으로 변환되기 때문에 성공할 가능성이 더 높습니다. 특정 임계값의 스테이킹된 이더에서 공격자의 힘은 다음과 같이 레벨업됩니다.
+
+33%: 최종 승인 지연
+
+34%: 최종 승인 지연, 이중 최종 승인
+
+51%: 최종 승인 지연, 이중 최종 승인, 검열, 블록체인 미래에 대한 통제권
+
+66%: 최종 승인 지연, 이중 최종 승인, 검열, 블록체인 미래와 과거에 대한 통제권
+
+또한 적은 양의 스테이킹된 이더를 필요로 하지만 매우 정교한 공격자가 메시지 타이밍을 정밀하게 제어하여 정직한 검증자 집합을 자신에게 유리하게 흔드는 데 의존하는 더 정교한 공격도 있습니다.
+
+전반적으로, 이러한 잠재적인 공격 벡터에도 불구하고 성공적인 공격의 위험은 낮으며, 확실히 작업 증명에 상응하는 것보다 낮습니다. 이는 투표력으로 정직한 검증자를 압도하려는 공격자가 위험에 빠뜨리는 스테이킹된 이더의 막대한 비용 때문입니다. 내장된 “당근과 채찍” 인센티브 레이어는 특히 낮은 스테이킹 공격자에 대해 대부분의 부정 행위로부터 보호합니다. 실제 네트워크 조건에서는 특정 검증자 하위 집합에 대한 메시지 전달의 정밀한 제어를 달성하기가 매우 어렵고, 클라이언트 팀이 알려진 바운싱, 균형 및 애벌랜치 공격 벡터를 간단한 패치로 신속하게 닫았기 때문에 더 미묘한 바운싱 및 균형 공격도 성공할 가능성이 낮습니다.
+
+34%, 51% 또는 66% 공격은 해결하기 위해 대역 외 사회적 조정이 필요할 가능성이 높습니다. 이것이 커뮤니티에 고통스러울 수 있지만, 커뮤니티가 대역 외로 대응할 수 있는 능력은 공격자에게 강력한 저해 요인입니다. 이더리움 소셜 레이어는 궁극적인 방어책입니다. 기술적으로 성공한 공격이라도 커뮤니티가 정직한 포크를 채택하기로 동의하면 무력화될 수 있습니다. 공격자와 이더리움 커뮤니티 사이에는 경쟁이 있을 것입니다. 66% 공격에 지출된 수십억 달러는 충분히 신속하게 전달된다면 성공적인 사회적 조정 공격에 의해 아마도 소멸될 것이며, 공격자는 이더리움 커뮤니티가 무시하는 알려진 부정직한 체인에 비유동적인 스테이킹된 이더의 무거운 가방을 남기게 될 것입니다. 이것이 공격자에게 수익성이 있을 가능성은 효과적인 억제책이 될 만큼 충분히 낮습니다. 이것이 바로 긴밀하게 정렬된 가치를 가진 응집력 있는 소셜 레이어를 유지하는 데 투자하는 것이 중요한 이유입니다.
+
+## 추가 정보 {#further-reading}
+
+- [이 페이지의 더 자세한 버전](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)
+- [Vitalik의 결제 최종 승인에 대하여](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
+- [LMD GHOST 논문](https://arxiv.org/abs/2003.03052)
+- [Casper-FFG 논문](https://arxiv.org/abs/1710.09437)
+- [Gasper 논문](https://arxiv.org/pdf/2003.03052.pdf)
+- [제안자 가중치 부스팅 합의 사양](https://github.com/ethereum/consensus-specs/pull/2730)
+- [ethresear.ch의 바운싱 공격](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114)
+- [SSLE 연구](https://ethresear.ch/t/secret-non-single-leader-election/11789)