diff --git a/public/content/translations/ko/developers/docs/scaling/zk-rollups/index.md b/public/content/translations/ko/developers/docs/scaling/zk-rollups/index.md
new file mode 100644
index 00000000000..876219a901b
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/scaling/zk-rollups/index.md
@@ -0,0 +1,257 @@
+---
+title: "영지식 롤업"
+description: "영지식 롤업 소개 - 이더리움 커뮤니티에서 사용하는 확장성 솔루션"
+lang: ko
+---
+
+영지식 롤업(ZK-롤업)은 연산과 상태 저장을 오프체인으로 이동시켜 이더리움 메인넷에서 처리량을 높이는 레이어 2 [확장 솔루션](/developers/docs/scaling/)입니다. 영지식 롤업은 수천 개의 트랜잭션을 일괄적으로 처리한 다음 최소한의 요약 데이터만 메인넷에 올린다. 요약 데이터는 이더리움 상태에 적용해야하는 변경 사항과 변경 사항이 옳다는 암호학적 증거를 정의합니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+[이더리움 확장](/developers/docs/scaling/) 및 [레이어 2](/layer-2)에 대한 페이지를 읽고 이해해야 합니다.
+
+## 영지식 롤업이란? {#what-are-zk-rollups}
+
+\*\*영지식 롤업(ZK-롤업)\*\*은 오프체인에서 실행되는 배치로 트랜잭션을 묶습니다(또는 '롤업'합니다). 오프체인 연산은 블록체인에 게시해야 하는 데이터의 양을 줄입니다. 영지식 롤업 운영자(operator)는 각 트랜잭션을 개별적으로 보내는 대신 모든 트랜잭션 묶음을 나타내는 데 필요한 변경사항의 요약을 제출합니다. 또한 변경 사항의 정확성을 증명하기 위해 [유효성 증명](/glossary/#validity-proof)을 생성합니다.
+
+영지식 롤업의 상태는 이더리움 네트워크에 배포된 스마트 컨트랙트에 의해 유지됩니다. 이 상태를 업데이트 하기 위해서는 영지식 롤업 노드가 검증을 위한 유효성 증명을 제출해야합니다. 언급했듯이, 유효성 증명은 롤업에 의해 제안된 상태 변화가 주어진 트랜잭션 묶음을 실제로 실행한 결과라는 암호화된 보증입니다. 이는 ZK-롤업이 [낙관적 롤업](/developers/docs/scaling/optimistic-rollups/)처럼 모든 트랜잭션 데이터를 온체인에 게시하는 대신, 이더리움에서 트랜잭션을 확정하기 위해 유효성 증명만 제공하면 된다는 것을 의미합니다.
+
+영지식 롤업 계약이 유효성 증명을 확인하면 출금 트랜잭션(exit transaction)이 실행되기때문에 이더리움으로 자금을 이동시킬 때 지연이 없습니다. 반대로, 낙관적 롤업에서 자금을 인출하는 경우 누구나 [사기 증명](/glossary/#fraud-proof)으로 출금 트랜잭션에 이의를 제기할 수 있도록 지연이 발생합니다.
+
+ZK-롤업은 트랜잭션을 `calldata`로 이더리움에 기록합니다. `calldata`는 스마트 계약 함수에 대한 외부 호출에 포함된 데이터가 저장되는 위치입니다. `calldata`의 정보는 블록체인에 게시되므로 누구나 독립적으로 롤업의 상태를 재구성할 수 있습니다. 영지식 롤업은 압축기술을 사용하여 트랜잭션 데이터를 줄입니다. 예를들어, 계정은 주소가 아닌 인덱스로 표시되어 28바이트의 데이터로 저장합니다. 온체인 데이터 게시는 롤업에 상당한 비용이 들기 때문에, 데이터 압축을 통해 사용자 수수료를 줄일 수 있습니다.
+
+## 영지식 롤업은 이더리움과 어떻게 상호 작용하나요? {#zk-rollups-and-ethereum}
+
+ZK-롤업 체인은 이더리움 블록체인 위에서 작동하는 오프체인 프로토콜이며 온체인 이더리움 스마트 계약에 의해 관리됩니다. ZK-롤업은 메인넷 외부에서 트랜잭션을 실행하지만, 주기적으로 오프체인 트랜잭션 배치를 온체인 롤업 계약에 커밋합니다. 이 거래 기록은 이더리움 블록체인과 마찬가지로 불변이며, 영지식 롤업 체인을 형성합니다.
+
+영지식 롤업의 핵심 아키텍처 구성은 다음과 같습니다.
+
+1. **온체인 계약**: 앞서 언급했듯이, ZK-롤업 프로토콜은 이더리움에서 실행되는 스마트 계약에 의해 제어됩니다. 여기에는 롤업 블록을 저장하고 예금을 추적하며 상태 업데이트를 모니터링하는 메인 스마트 컨트랙트가 포함됩니다. 또 다른 온체인 계약(검증자 계약)은 블록 생산자가 제출한 영지식 증명을 검증합니다. 따라서 이더리움은 영지식 롤업의 기본 계층 또는 "레이어 1" 역할을 합니다.
+
+2. **오프체인 가상 머신(VM)**: ZK-롤업 프로토콜은 이더리움에 있지만, 트랜잭션 실행 및 상태 저장은 [EVM](/developers/docs/evm/)과 독립적인 별도의 가상 머신에서 이루어집니다. 이 오프체인 VM은 ZK-롤업에서 트랜잭션을 실행하기 위한 환경이며 ZK-롤업 프로토콜의 보조 레이어 또는 "레이어 2" 역할을 합니다. 이더리움 메인넷에서 검증된 유효성 증명은 오프체인 VM의 상태 전환에 대한 정확성을 보장합니다.
+
+ZK-롤업은 "하이브리드 확장 솔루션"으로, 독립적으로 작동하지만 이더리움으로부터 보안을 파생하는 오프체인 프로토콜입니다. 특히 이더리움 네트워크는 영지식 롤업에 대한 상태 업데이트의 유효성을 강화하고 롤업 상태에 대한 모든 업데이트 뒤에 있는 데이터의 가용성을 보장합니다. 결과적으로, ZK-롤업은 자체 보안 속성을 책임지는 [사이드체인](/developers/docs/scaling/sidechains/)이나, 유효성 증명을 통해 이더리움에서 트랜잭션을 검증하지만 트랜잭션 데이터는 다른 곳에 저장하는 [밸리디움](/developers/docs/scaling/validium/)과 같은 순수 오프체인 확장 솔루션보다 훨씬 더 안전합니다.
+
+영지식 롤업은 다음을 위해 메인 이더리움 프로토콜에 의존합니다.
+
+### 데이터 가용성 {#data-availability}
+
+ZK-롤업은 오프체인에서 처리된 모든 트랜잭션의 상태 데이터를 이더리움에 게시합니다. 이 데이터를 사용해 개인이나 기업에서 롤업의 상태를 재생산하고 스스로 체인의 유효성을 검증할 수 있습니다. 이더리움은 이 데이터를 `calldata`로 네트워크의 모든 참여자가 사용할 수 있도록 합니다.
+
+유효성 증명이 이미 상태 전환의 진위 여부를 검증하기 때문에, ZK-롤업은 많은 트랜잭션 데이터를 온체인에 게시할 필요가 없습니다. 그럼에도 불구하고 온체인에 데이터를 저장하는 것은 중요합니다. L2 체인의 상태를 무허가적이고 독립적으로 검증할 수 있게 해주기 때문입니다. 이는 결국 누구나 트랜잭션 배치를 제출할 수 있게 하여 악의적인 운영자가 체인을 검열하거나 동결하는 것을 방지합니다.
+
+사용자가 롤업과 상호 작용하려면 온체인이 필요합니다. 상태 데이터 접근 없이 유저는 그들의 잔고나 상태 정보에 의존하는 트랜잭션 (예, 출금) 을 실행할 수 없습니다.
+
+### 트랜잭션 완결성 {#transaction-finality}
+
+이더리움은 ZK-롤업의 정산 레이어 역할을 합니다. L2 트랜잭션은 L1 계약이 유효성 증명을 수락해야만 완결됩니다. 모든 트랜잭션이 메인넷에서 승인되어야 하므로, 악의적인 운영자가 체인을 손상시키는(예: 롤업 자금 탈취) 위험을 제거합니다. 또한 이더리움은 사용자 작업이 L1에서 완결되면 되돌릴 수 없음을 보장합니다.
+
+### 검열 저항성 {#censorship-resistance}
+
+대부분의 ZK-롤업은 "슈퍼노드"(운영자)를 사용하여 트랜잭션을 실행하고, 배치를 생성하며, 블록을 L1에 제출합니다. 이는 효율성을 보장하지만 검열의 위험을 증가시킵니다. 악의적인 ZK-롤업 운영자는 사용자의 트랜잭션을 배치에 포함시키기를 거부함으로써 사용자를 검열할 수 있습니다.
+
+보안 조치로서, ZK-롤업은 사용자가 운영자에 의해 검열되고 있다고 생각하는 경우, 메인넷의 롤업 계약에 직접 트랜잭션을 제출할 수 있도록 합니다. 이를 통해 사용자는 운영자의 허가에 의존하지 않고 ZK-롤업에서 이더리움으로 강제 출금을 할 수 있습니다.
+
+## ZK-롤업은 어떻게 작동하나요? {#how-do-zk-rollups-work}
+
+### 트랜잭션 {#transactions}
+
+ZK-롤업의 사용자는 트랜잭션에 서명하고 다음 배치에 포함되도록 처리를 위해 L2 운영자에게 제출합니다. 어떤 경우에는 운영자가 시퀀서라고 불리는 중앙화된 주체이며, 트랜잭션을 실행하고, 배치로 집계하여 L1에 제출합니다. 이 시스템의 시퀀서는 L2 블록을 생성하고 ZK-롤업 계약에 롤업 트랜잭션을 추가할 수 있는 유일한 주체입니다.
+
+다른 ZK-롤업은 [지분 증명](/developers/docs/consensus-mechanisms/pos/) 검증자 세트를 사용하여 운영자 역할을 순환시킬 수 있습니다. 예비 운영자는 롤업 계약에 자금을 예치하며, 각 스테이킹의 크기는 스테이커가 다음 롤업 배치를 생성하도록 선택될 확률에 영향을 미칩니다. 운영자가 악의적으로 행동하면 스테이킹이 삭감될 수 있으며, 이는 유효한 블록을 게시하도록 장려합니다.
+
+#### ZK-롤업이 이더리움에 트랜잭션 데이터를 게시하는 방법 {#how-zk-rollups-publish-transaction-data-on-ethereum}
+
+설명한 바와 같이, 트랜잭션 데이터는 `calldata`로 이더리움에 게시됩니다. `calldata`는 함수에 인수를 전달하는 데 사용되는 스마트 계약의 데이터 영역이며 [메모리](/developers/docs/smart-contracts/anatomy/#memory)와 유사하게 동작합니다. `calldata`는 이더리움의 상태의 일부로 저장되지는 않지만, 이더리움 체인의 [기록 로그](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs)의 일부로 온체인에 유지됩니다. `calldata`는 이더리움의 상태에 영향을 미치지 않으므로 온체인에 데이터를 저렴하게 저장하는 방법입니다.
+
+`calldata` 키워드는 종종 트랜잭션에 의해 호출되는 스마트 계약 메서드를 식별하고 임의의 바이트 시퀀스 형태로 메서드에 대한 입력을 보유합니다. ZK-롤업은 `calldata`를 사용하여 압축된 트랜잭션 데이터를 온체인에 게시합니다. 롤업 운영자는 롤업 계약에서 필요한 함수를 호출하여 새 배치를 추가하고 압축된 데이터를 함수 인수로 전달하기만 하면 됩니다. 롤업 수수료의 상당 부분이 온체인에 트랜잭션 데이터를 저장하는 데 사용되므로 이는 사용자 비용을 줄이는 데 도움이 됩니다.
+
+### 상태 커밋먼트 {#state-commitments}
+
+L2 계정 및 잔액을 포함하는 ZK-롤업의 상태는 [머클 트리](/whitepaper/#merkle-trees)로 표시됩니다. 머클 트리의 루트(머클 루트)에 대한 암호화 해시는 온체인 계약에 저장되어 롤업 프로토콜이 ZK-롤업 상태의 변경 사항을 추적할 수 있도록 합니다.
+
+롤업은 새로운 트랜잭션 세트가 실행된 후 새로운 상태로 전환됩니다. 상태 전환을 시작한 운영자는 새로운 상태 루트를 계산하여 온체인 계약에 제출해야 합니다. 배치와 관련된 유효성 증명이 검증자 계약에 의해 인증되면 새로운 머클 루트는 ZK-롤업의 정식 상태 루트가 됩니다.
+
+상태 루트를 계산하는 것 외에도 ZK-롤업 운영자는 배치 루트, 즉 배치의 모든 트랜잭션으로 구성된 머클 트리의 루트도 생성합니다. 새 배치가 제출되면 롤업 계약은 배치 루트를 저장하여 사용자가 트랜잭션(예: 인출 요청)이 배치에 포함되었음을 증명할 수 있도록 합니다. 사용자는 트랜잭션 세부 정보, 배치 루트 및 포함 경로를 보여주는 [머클 증명](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)을 제공해야 합니다.
+
+### 유효성 증명 {#validity-proofs}
+
+ZK-롤업 운영자가 L1 계약에 제출하는 새로운 상태 루트는 롤업 상태 업데이트의 결과입니다. 예를 들어 앨리스가 밥에게 10개의 토큰을 보내면 운영자는 앨리스의 잔액을 10만큼 줄이고 밥의 잔액을 10만큼 늘립니다. 그런 다음 운영자는 업데이트된 계정 데이터를 해시하고 롤업의 머클 트리를 다시 빌드한 다음 새 머클 루트를 온체인 계약에 제출합니다.
+
+그러나 롤업 계약은 운영자가 새 머클 루트가 롤업 상태에 대한 올바른 업데이트의 결과임을 증명할 때까지 제안된 상태 약정을 자동으로 수락하지 않습니다. ZK-롤업 운영자는 배치된 트랜잭션의 정확성을 검증하는 간결한 암호화 약정인 유효성 증명을 생성하여 이를 수행합니다.
+
+유효성 증명을 사용하면 당사자가 진술 자체를 공개하지 않고도 진술의 정확성을 증명할 수 있으므로 영지식 증명이라고도 합니다. ZK-롤업은 유효성 증명을 사용하여 이더리움에서 트랜잭션을 다시 실행하지 않고도 오프체인 상태 전환의 정확성을 확인합니다. 이러한 증명은 [ZK-SNARK](https://arxiv.org/abs/2202.06877)(영지식 간결 비대화형 지식 논증) 또는 [ZK-STARK](https://eprint.iacr.org/2018/046)(영지식 확장형 투명 지식 논증)의 형태를 띨 수 있습니다.
+
+SNARK와 STARK는 각각 독특한 특징을 가지고 있지만 ZK-롤업에서 오프체인 계산의 무결성을 증명하는 데 도움이 됩니다.
+
+**ZK-SNARK**
+
+ZK-SNARK 프로토콜이 작동하려면 공통 참조 문자열(CRS)을 생성해야 합니다. CRS는 유효성 증명을 증명하고 검증하기 위한 공개 매개변수를 제공합니다. 증명 시스템의 보안은 CRS 설정에 따라 달라집니다. 공개 매개변수를 생성하는 데 사용된 정보가 악의적인 행위자의 손에 들어가면 거짓 유효성 증명을 생성할 수 있습니다.
+
+일부 ZK-롤업은 신뢰할 수 있는 개인을 포함하는 [다자간 계산(MPC) 행사](https://zkproof.org/2021/06/30/setup-ceremonies/amp/)를 사용하여 ZK-SNARK 회로에 대한 공개 매개변수를 생성함으로써 이 문제를 해결하려고 시도합니다. 각 당사자는 CRS를 구성하기 위해 약간의 무작위성("독성 폐기물"이라고 함)을 제공하며, 이를 즉시 파기해야 합니다.
+
+신뢰 기반 설정은 CRS 설정의 보안을 높이기 때문에 사용됩니다. 한 명의 정직한 참가자가 자신의 입력을 파기하는 한 ZK-SNARK 시스템의 보안은 보장됩니다. 하지만 이 접근 방식은 관련된 사람들이 샘플링된 무작위성을 삭제하고 시스템의 보안 보장을 훼손하지 않을 것이라고 신뢰해야 합니다.
+
+신뢰 가정을 제외하고, ZK-SNARK는 작은 증명 크기와 상수 시간 검증으로 인기가 있습니다. L1에서의 증명 검증은 ZK-롤업 운영 비용의 더 큰 부분을 차지하므로 L2는 ZK-SNARK를 사용하여 메인넷에서 빠르고 저렴하게 검증할 수 있는 증명을 생성합니다.
+
+**ZK-STARK**
+
+ZK-SNARK와 마찬가지로 ZK-STARK는 입력을 공개하지 않고 오프체인 계산의 유효성을 증명합니다. 그러나 ZK-STARK는 확장성과 투명성 때문에 ZK-SNARK보다 개선된 것으로 간주됩니다.
+
+ZK-STARK는 공통 참조 문자열(CRS)의 신뢰 기반 설정 없이도 작동할 수 있으므로 '투명'합니다. 대신 ZK-STARK는 공개적으로 검증 가능한 무작위성에 의존하여 증명을 생성하고 검증하기 위한 매개변수를 설정합니다.
+
+ZK-STARK는 또한 유효성 증명을 증명하고 검증하는 데 필요한 시간이 기본 계산의 복잡성과 관련하여 _준선형적으로_ 증가하기 때문에 더 많은 확장성을 제공합니다. ZK-SNARK의 경우 증명 및 검증 시간은 기본 계산의 크기에 비례하여 _선형적으로_ 확장됩니다. 이는 대규모 데이터세트가 관련될 때 ZK-STARK가 증명 및 검증에 ZK-SNARK보다 시간이 덜 걸린다는 것을 의미하며, 따라서 대용량 애플리케이션에 유용합니다.
+
+ZK-STARK는 양자 컴퓨터에 대해서도 안전하지만, ZK-SNARK에 사용되는 타원 곡선 암호화(ECC)는 양자 컴퓨팅 공격에 취약한 것으로 널리 알려져 있습니다. ZK-STARK의 단점은 더 큰 증명 크기를 생성하여 이더리움에서 검증하는 데 더 많은 비용이 든다는 것입니다.
+
+#### ZK-롤업에서 유효성 증명은 어떻게 작동하나요? {#validity-proofs-in-zk-rollups}
+
+##### 증명 생성
+
+트랜잭션을 수락하기 전에 운영자는 일반적인 검사를 수행합니다. 여기에는 다음 확인 사항이 포함됩니다.
+
+- 송금인과 수취인 계정이 상태 트리의 일부입니다.
+- 송금인이 트랜잭션을 처리하기에 충분한 자금을 가지고 있습니다.
+- 트랜잭션이 정확하고 롤업의 송금인 공개 키와 일치합니다.
+- 송금인의 논스가 정확합니다.
+
+ZK-롤업 노드에 충분한 트랜잭션이 있으면 이를 배치로 집계하고 증명 회로가 간결한 ZK-증명으로 컴파일할 수 있도록 입력을 컴파일합니다. 여기에는 다음이 포함됩니다.
+
+- 배치의 모든 트랜잭션으로 구성된 머클 트리 루트.
+- 배치 포함을 증명하기 위한 트랜잭션에 대한 머클 증명.
+- 해당 계정이 롤업 상태 트리의 일부임을 증명하기 위해 트랜잭션의 각 송금인-수취인 쌍에 대한 머클 증명.
+- 각 트랜잭션에 대한 상태 업데이트를 적용한 후 상태 루트를 업데이트하여 파생된 중간 상태 루트 세트(즉, 송금인 계정 감소 및 수취인 계정 증가).
+
+증명 회로는 각 트랜잭션을 "반복"하고 운영자가 트랜잭션을 처리하기 전에 완료한 것과 동일한 검사를 수행하여 유효성 증명을 계산합니다. 먼저 제공된 머클 증명을 사용하여 송금인의 계정이 기존 상태 루트의 일부인지 확인합니다. 그런 다음 송금인의 잔액을 줄이고, 논스를 증가시키고, 업데이트된 계정 데이터를 해시한 다음 머클 증명과 결합하여 새로운 머클 루트를 생성합니다.
+
+이 머클 루트는 ZK-롤업 상태의 유일한 변경 사항인 송금인의 잔액과 논스 변경을 반영합니다. 계정의 존재를 증명하는 데 사용되는 머클 증명이 새로운 상태 루트를 도출하는 데 사용되기 때문에 이것이 가능합니다.
+
+증명 회로는 수취인의 계정에서 동일한 프로세스를 수행합니다. 중간 상태 루트 아래에 수취인의 계정이 있는지 확인하고(머클 증명 사용), 잔액을 늘리고, 계정 데이터를 다시 해시한 다음 머클 증명과 결합하여 새로운 상태 루트를 생성합니다.
+
+이 프로세스는 모든 트랜잭션에 대해 반복됩니다. 각 "루프"는 송금인의 계정을 업데이트하여 새로운 상태 루트를 생성하고 수취인의 계정을 업데이트하여 후속 새로운 루트를 생성합니다. 설명한 바와 같이 상태 루트에 대한 모든 업데이트는 롤업 상태 트리의 한 부분이 변경되었음을 나타냅니다.
+
+ZK 증명 회로는 전체 트랜잭션 배치를 반복하여 마지막 트랜잭션이 실행된 후 최종 상태 루트가 되는 업데이트 순서를 확인합니다. 계산된 마지막 머클 루트는 ZK-롤업의 최신 정식 상태 루트가 됩니다.
+
+##### 증명 검증
+
+증명 회로가 상태 업데이트의 정확성을 확인한 후 L2 운영자는 계산된 유효성 증명을 L1의 검증자 계약에 제출합니다. 계약의 검증 회로는 증명의 유효성을 확인하고 증명의 일부를 구성하는 공개 입력도 확인합니다.
+
+- **이전 상태 루트**: ZK-롤업의 이전 상태 루트(즉, 일괄 처리된 트랜잭션이 실행되기 전)로, L2 체인의 마지막으로 알려진 유효한 상태를 반영합니다.
+
+- **이후 상태 루트**: ZK-롤업의 새로운 상태 루트(즉, 일괄 처리된 트랜잭션이 실행된 후)로, L2 체인의 최신 상태를 반영합니다. 이후 상태 루트는 증명 회로에서 상태 업데이트를 적용한 후 파생된 최종 루트입니다.
+
+- **배치 루트**: 배치의 머클 루트로, 배치의 트랜잭션을 _머클화_하고 트리의 루트를 해시화하여 파생됩니다.
+
+- **트랜잭션 입력**: 제출된 배치의 일부로 실행된 트랜잭션과 관련된 데이터.
+
+증명이 회로를 만족시키는 경우(즉, 유효한 경우) 이전 상태(이전 상태 루트로 암호화 지문 채취)에서 새로운 상태(이후 상태 루트로 암호화 지문 채취)로 롤업을 전환하는 유효한 트랜잭션 시퀀스가 존재함을 의미합니다. 이전 상태 루트가 롤업 계약에 저장된 루트와 일치하고 증명이 유효하면 롤업 계약은 증명에서 이후 상태 루트를 가져와 롤업의 변경된 상태를 반영하도록 상태 트리를 업데이트합니다.
+
+### 진입 및 탈출 {#entries-and-exits}
+
+사용자는 L1 체인에 배포된 롤업 계약에 토큰을 예치하여 ZK-롤업에 참여합니다. 운영자만 롤업 계약에 트랜잭션을 제출할 수 있으므로 이 트랜잭션은 대기열에 추가됩니다.
+
+보류 중인 예금 대기열이 채워지기 시작하면 ZK-롤업 운영자는 예금 트랜잭션을 가져와 롤업 계약에 제출합니다. 사용자의 자금이 롤업에 있으면 처리를 위해 운영자에게 트랜잭션을 전송하여 거래를 시작할 수 있습니다. 사용자는 계정 데이터를 해시하고 해시를 롤업 계약에 보낸 다음 머클 증명을 제공하여 현재 상태 루트에 대해 확인하여 롤업의 잔액을 확인할 수 있습니다.
+
+ZK-롤업에서 L1으로 인출하는 것은 간단합니다. 사용자는 롤업의 자산을 소각을 위해 지정된 계정으로 보내 출금 트랜잭션을 시작합니다. 운영자가 다음 배치에 트랜잭션을 포함하면 사용자는 온체인 계약에 인출 요청을 제출할 수 있습니다. 이 인출 요청에는 다음이 포함됩니다.
+
+- 사용자의 트랜잭션이 소각 계정으로 전송되었음을 증명하는 머클 증명
+
+- 트랜잭션 데이터
+
+- 배치 루트
+
+- 예치된 자금을 받을 L1 주소
+
+롤업 계약은 트랜잭션 데이터를 해시하고 배치 루트가 있는지 확인한 다음 머클 증명을 사용하여 트랜잭션 해시가 배치 루트의 일부인지 확인합니다. 그 후 계약은 출금 트랜잭션을 실행하고 L1에서 사용자가 선택한 주소로 자금을 보냅니다.
+
+## ZK-롤업 및 EVM 호환성 {#zk-rollups-and-evm-compatibility}
+
+낙관적 롤업과 달리 ZK-롤업은 [이더리움 가상 머신(EVM)](/developers/docs/evm/)과 쉽게 호환되지 않습니다. 회로에서 범용 EVM 계산을 증명하는 것은 이전에 설명한 토큰 전송과 같은 간단한 계산을 증명하는 것보다 더 어렵고 리소스 집약적입니다.
+
+그러나 [영지식 기술의 발전](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now)으로 인해 EVM 계산을 영지식 증명으로 래핑하는 것에 대한 관심이 다시 불붙고 있습니다. 이러한 노력은 프로그램 실행의 정확성을 효율적으로 검증할 수 있는 영지식 EVM(zkEVM) 구현을 만드는 것을 목표로 합니다. zkEVM은 회로에서 증명/검증을 위해 기존 EVM 옵코드를 재생성하여 스마트 계약을 실행할 수 있도록 합니다.
+
+EVM과 마찬가지로 zkEVM은 일부 입력에 대한 계산이 수행된 후 상태 간에 전환됩니다. 차이점은 zkEVM이 프로그램 실행의 모든 단계의 정확성을 검증하기 위해 영지식 증명을 생성한다는 것입니다. 유효성 증명은 VM의 상태(메모리, 스택, 스토리지)에 영향을 미치는 작업의 정확성과 계산 자체(즉, 작업이 올바른 옵코드를 호출하고 올바르게 실행했는지 여부)를 확인할 수 있습니다.
+
+EVM 호환 ZK-롤업의 도입은 개발자가 영지식 증명의 확장성과 보안 보장을 활용하는 데 도움이 될 것으로 예상됩니다. 더 중요한 것은 네이티브 이더리움 인프라와의 호환성은 개발자가 익숙하고 검증된 툴링과 언어를 사용하여 ZK 친화적인 탈중앙화앱을 구축할 수 있음을 의미합니다.
+
+## ZK-롤업 수수료는 어떻게 작동하나요? {#how-do-zk-rollup-fees-work}
+
+ZK-롤업에서 사용자가 트랜잭션에 대해 지불하는 금액은 이더리움 메인넷과 마찬가지로 가스 수수료에 따라 다릅니다. 그러나 가스 수수료는 L2에서 다르게 작동하며 다음 비용의 영향을 받습니다.
+
+1. **상태 쓰기**: 이더리움 상태에 쓰는 데(즉, 이더리움 블록체인에 트랜잭션을 제출하는 것) 고정 비용이 있습니다. ZK-롤업은 트랜잭션을 일괄 처리하고 여러 사용자에게 고정 비용을 분산시켜 이 비용을 줄입니다.
+
+2. **데이터 게시**: ZK-롤업은 모든 트랜잭션의 상태 데이터를 `calldata`로 이더리움에 게시합니다. `calldata` 비용은 현재 [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)에 의해 관리되며, 이는 0이 아닌 바이트에 대해 16 가스, `calldata`의 0바이트에 대해 각각 4 가스의 비용을 규정합니다. 각 트랜잭션에 대해 지불하는 비용은 온체인에 게시해야 하는 `calldata`의 양에 따라 영향을 받습니다.
+
+3. **L2 운영자 수수료**: 이더리움 메인넷의 [트랜잭션 "우선 수수료(팁)"](/developers/docs/gas/#how-are-gas-fees-calculated)와 마찬가지로 트랜잭션 처리 시 발생하는 계산 비용에 대한 보상으로 롤업 운영자에게 지불되는 금액입니다.
+
+4. **증명 생성 및 검증**: ZK-롤업 운영자는 트랜잭션 배치에 대한 유효성 증명을 생성해야 하며, 이는 리소스 집약적입니다. 메인넷에서 영지식 증명을 검증하는 데에도 가스(~500,000 가스)가 소요됩니다.
+
+트랜잭션을 일괄 처리하는 것 외에도 ZK-롤업은 트랜잭션 데이터를 압축하여 사용자 수수료를 줄입니다. 이더리움 ZK-롤업 사용 비용에 대한 [실시간 개요](https://l2fees.info/)를 볼 수 있습니다.
+
+## ZK-롤업은 이더리움을 어떻게 확장하나요? {#scaling-ethereum-with-zk-rollups}
+
+### 트랜잭션 데이터 압축 {#transaction-data-compression}
+
+ZK-롤업은 계산을 오프체인으로 가져와 이더리움의 기본 레이어에서 처리량을 확장하지만, 확장을 위한 진정한 이점은 트랜잭션 데이터를 압축하는 데 있습니다. 이더리움의 [블록 크기](/developers/docs/blocks/#block-size)는 각 블록이 보유할 수 있는 데이터의 양과 나아가 블록당 처리되는 트랜잭션 수를 제한합니다. 트랜잭션 관련 데이터를 압축함으로써 ZK-롤업은 블록당 처리되는 트랜잭션 수를 크게 늘립니다.
+
+ZK-롤업은 각 트랜잭션을 검증하는 데 필요한 모든 데이터를 게시할 필요가 없으므로 낙관적 롤업보다 트랜잭션 데이터를 더 잘 압축할 수 있습니다. 롤업에서 계정 및 잔액의 최신 상태를 재구성하는 데 필요한 최소한의 데이터만 게시하면 됩니다.
+
+### 재귀적 증명 {#recursive-proofs}
+
+영지식 증명의 장점은 증명이 다른 증명을 검증할 수 있다는 것입니다. 예를 들어, 단일 ZK-SNARK는 다른 ZK-SNARK를 검증할 수 있습니다. 이러한 "증명의 증명"은 재귀적 증명이라고 하며 ZK-롤업의 처리량을 극적으로 증가시킵니다.
+
+현재 유효성 증명은 블록 단위로 생성되어 검증을 위해 L1 계약에 제출됩니다. 그러나 운영자가 증명을 제출할 때 하나의 블록만 완결될 수 있으므로 단일 블록 증명을 검증하면 ZK-롤업이 달성할 수 있는 처리량이 제한됩니다.
+
+그러나 재귀적 증명을 사용하면 하나의 유효성 증명으로 여러 블록을 완결할 수 있습니다. 이는 증명 회로가 최종 증명이 하나 생성될 때까지 여러 블록 증명을 재귀적으로 집계하기 때문입니다. L2 운영자는 이 재귀적 증명을 제출하며, 계약이 이를 수락하면 모든 관련 블록이 즉시 완결됩니다. 재귀적 증명을 사용하면 일정 간격으로 이더리움에서 완결될 수 있는 ZK-롤업 트랜잭션의 수가 증가합니다.
+
+### ZK-롤업의 장단점 {#zk-rollups-pros-and-cons}
+
+| 장점 | 단점 |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- |
+| 유효성 증명은 오프체인 트랜잭션의 정확성을 보장하고 운영자가 잘못된 상태 전환을 실행하는 것을 방지합니다. | 유효성 증명을 계산하고 검증하는 데 드는 비용이 상당하며 롤업 사용자의 수수료를 증가시킬 수 있습니다. |
+| L1에서 유효성 증명이 검증되면 상태 업데이트가 승인되므로 더 빠른 트랜잭션 완결성을 제공합니다. | 영지식 기술의 복잡성으로 인해 EVM 호환 ZK-롤업을 구축하는 것은 어렵습니다. |
+| [낙관적 롤업](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons)과 같이 인센티브를 받는 행위자의 정직성이 아니라 보안을 위해 무신뢰 암호화 메커니즘에 의존합니다. | 유효성 증명을 생성하려면 특수 하드웨어가 필요하며, 이는 소수 당사자에 의한 체인의 중앙 집중식 제어를 조장할 수 있습니다. |
+| L1에서 오프체인 상태를 복구하는 데 필요한 데이터를 저장하여 보안, 검열 저항성 및 탈중앙화를 보장합니다. | 중앙화된 운영자(시퀀서)는 트랜잭션 순서에 영향을 미칠 수 있습니다. |
+| 사용자는 더 큰 자본 효율성의 이점을 누리고 지연 없이 L2에서 자금을 인출할 수 있습니다. | 하드웨어 요구 사항으로 인해 체인을 강제로 진행시킬 수 있는 참여자 수가 줄어들어 악의적인 운영자가 롤업 상태를 동결하고 사용자를 검열할 위험이 증가할 수 있습니다. |
+| 활성 가정에 의존하지 않으며 사용자는 자금을 보호하기 위해 체인을 검증할 필요가 없습니다. | 일부 증명 시스템(예: ZK-SNARK)은 신뢰 기반 설정을 필요로 하며, 이를 잘못 처리하면 ZK-롤업의 보안 모델이 손상될 수 있습니다. |
+| 더 나은 데이터 압축은 이더리움에서 `calldata`를 게시하는 비용을 줄이고 사용자의 롤업 수수료를 최소화하는 데 도움이 될 수 있습니다. | |
+
+### ZK-롤업에 대한 시각적 설명 {#zk-video}
+
+Finematics에서 영지식 증명에 대해 설명합니다.
+
+
+
+## zkEVM을 개발하는 곳은 어디인가요? {#zkevm-projects}
+
+zkEVM을 개발하는 프로젝트는 다음과 같습니다.
+
+- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** - _zkEVM은 이더리움 재단이 EVM 호환 ZK-롤업과 이더리움 블록에 대한 유효성 증명 생성 메커니즘을 개발하기 위해 자금을 지원하는 프로젝트입니다._
+
+- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** - _이더리움 메인넷의 탈중앙화된 ZK 롤업으로, 영지식 증명 검증을 통해 스마트 계약을 포함한 이더리움 트랜잭션을 투명하게 실행하는 영지식 이더리움 가상 머신(zkEVM)을 개발하고 있습니다._
+
+- **[Scroll](https://scroll.io/blog/zkEVM)** - _Scroll은 이더리움을 위한 네이티브 zkEVM 레이어 2 솔루션을 구축하는 기술 중심 회사입니다._
+
+- **[Taiko](https://taiko.xyz)** - _Taiko는 탈중앙화된 이더리움 동등 ZK-롤업([유형 1 ZK-EVM](https://vitalik.eth.limo/general/2022/08/04/zkevm.html))입니다._
+
+- **[ZKsync](https://docs.zksync.io/)** - _ZKsync Era는 Matter Labs가 구축한 EVM 호환 ZK 롤업으로, 자체 zkEVM으로 구동됩니다._
+
+- **[Starknet](https://starkware.co/starknet/)** - _StarkNet은 StarkWare가 구축한 EVM 호환 레이어 2 확장 솔루션입니다._
+
+- **[Morph](https://www.morphl2.io/)** - _Morph는 zk-증명을 활용하여 레이어 2 상태 문제 문제를 해결하는 하이브리드 롤업 확장 솔루션입니다._
+
+- **[Linea](https://linea.build)** - _Linea는 Consensys가 구축한 이더리움 동등 zkEVM 레이어 2로, 이더리움 생태계와 완벽하게 일치합니다._
+
+## ZK-롤업에 대한 추가 자료 {#further-reading-on-zk-rollups}
+
+- [영지식 롤업이란?](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups)
+- [영지식 롤업이란?](https://alchemy.com/blog/zero-knowledge-rollups)
+- [이더리움 롤업 실용 가이드](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups)
+- [STARK 대 SNARK](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/)
+- [zkEVM이란?](https://www.alchemy.com/overviews/zkevm)
+- [ZK-EVM 유형: 이더리움 동등, EVM 동등, 유형 1, 유형 4 및 기타 암호화된 유행어](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4)
+- [zkEVM 소개](https://hackmd.io/@yezhang/S1_KMMbGt)
+- [ZK-EVM L2란?](https://linea.mirror.xyz/qD18IaQ4BROn_Y40EBMTUTdJHYghUtdECscSWyMvm8M)
+- [Awesome-zkEVM 리소스](https://github.com/LuozhuZhang/awesome-zkevm)
+- [ZK-SNARK 내부 구조](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html)
+- [SNARK는 어떻게 가능한가?](https://vitalik.eth.limo/general/2021/01/26/snarks.html)
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/anatomy/index.md b/public/content/translations/ko/developers/docs/smart-contracts/anatomy/index.md
new file mode 100644
index 00000000000..fab057e51df
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/anatomy/index.md
@@ -0,0 +1,658 @@
+---
+title: "스마트 계약의 구조"
+description: "스마트 컨트랙트 구성 요소에 대해 자세히 알아보기 - 함수, 데이터, 변수"
+lang: ko
+---
+
+스마트 컨트랙트는 이더리움 주소 체계 상에서 실행되는 프로그램이며, 거래가 발생할 때 실행되는 데이터와 함수로 구성되어 있습니다. 지금부터 그 구성 요소에 대해 전반적으로 살펴보도록 하겠습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+[스마트 계약](/developers/docs/smart-contracts/)에 대해 먼저 읽어보시기 바랍니다. 자바 스크립트나 파이썬과 같은 프로그래밍 언어에 상당히 익숙하다는 것을 전제합니다.
+
+## 데이터 {#data}
+
+모든 계약 데이터는 `storage` 또는 `memory` 위치에 할당되어야 합니다. 이 중 스토리지 사용은 비용이 더 발생하므로 여러분은 어떤 것을 활용할 지 미리 고려해야 합니다.
+
+### 저장 공간 {#storage}
+
+영구적인 데이터는 스토리지로 간주되며 상태 변수 형태로 표현됩니다. 이런 값은 블록체인 상에 영구히 남게 되므로, 컨트랙트 컴파일 시에 스토리지 형태로 사용할 변수를 명확히 구분할 필요가 있습니다.
+
+```solidity
+// Solidity 예시
+contract SimpleStorage {
+ uint storedData; // 상태 변수
+ // ...
+}
+```
+
+```python
+# Vyper 예시
+storedData: int128
+```
+
+여러분이 객체 지향적인 언어를 사용해 보았다면 대부분의 변수 타입에는 익숙할 것입니다. 하지만 이더리움 개발이 처음이라면 `address`는 생소할 수 있습니다.
+
+`address` 유형은 이더리움 주소를 저장할 수 있으며, 이는 20바이트 또는 160비트와 같습니다. 또한 16진수로 표기되며 0x로 시작합니다.
+
+기타 유형에는 다음이 포함됩니다:
+
+- 불리언
+- 정수
+- 고정 소수점 숫자
+- 고정 크기 바이트 배열
+- 동적 크기 바이트 배열
+- 유리수 및 정수 리터럴
+- 문자열 리터럴
+- 16진수 리터럴
+- 열거형
+
+더 많은 설명은 문서를 참고하십시오:
+
+- [Vyper 유형 보기](https://docs.vyperlang.org/en/v0.1.0-beta.6/types.html#value-types)
+- [Solidity 유형 보기](https://docs.soliditylang.org/en/latest/types.html#value-types)
+
+### 메모리 {#memory}
+
+메모리 변수는 컨트랙스 함수가 실행되는 시간에만 사용이 가능하기 때문에, 블록체인에는 저장되지 않고 비용도 저렴합니다.
+
+[Solidity 문서](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#storage-memory-and-the-stack)에서 EVM이 데이터(저장 공간, 메모리, 스택)를 저장하는 방법에 대해 자세히 알아보세요.
+
+### 환경 변수 {#environment-variables}
+
+여러분이 컨트랙트에 정의한 변수 외에도 특별하게 사용할 수 있는 전역 변수가 있습니다. 그것을 통해 주로 블록체인과 현재 트랜잭션에 대한 정보를 알 수 있습니다.
+
+예시:
+
+| **속성** | **상태 변수** | **설명** |
+| ----------------- | --------- | ---------------------------------- |
+| `block.timestamp` | uint256 | 현재 블록 에포크 타임스탬프 |
+| `msg.sender` | 주소 | 메시지의 발신자(현재 호출) |
+
+## 함수 {#functions}
+
+함수는 거래에 대한 정보를 간단한 방법으로 가져오거나 설정할 수 있습니다.
+
+함수 호출에는 두 가지 방법이 있습니다.
+
+- `internal` – EVM 호출을 생성하지 않습니다
+ - 내부 함수와 상태 변수는 내부에서만 (즉, 현재 계약 또는 그로부터 파생된 계약 내에서만) 접근할 수 있습니다
+- `external` – EVM 호출을 생성합니다
+ - 외부 함수는 계약 인터페이스의 일부로, 다른 계약 및 트랜잭션을 통해 호출할 수 있습니다. 외부 함수 `f`는 내부에서 호출할 수 없습니다(예: `f()`는 작동하지 않지만 `this.f()`는 작동합니다).
+
+`public` 또는 `private`일 수도 있습니다
+
+- `public` 함수는 계약 내에서 내부적으로 또는 메시지를 통해 외부에서 호출할 수 있습니다
+- `private` 함수는 정의된 계약에서만 볼 수 있으며 파생된 계약에서는 볼 수 없습니다
+
+함수와 상태 변수 모두 public 또는 private 설정이 가능합니다.
+
+계약의 상태 변수를 업데이트하는 함수 예제입니다:
+
+```solidity
+// Solidity 예시
+function update_name(string value) public {
+ dapp_name = value;
+}
+```
+
+- `string` 유형의 매개변수 `value`가 `update_name` 함수에 전달됩니다
+- `public`으로 선언되어 누구나 접근할 수 있습니다
+- `view`로 선언되지 않았으므로 계약 상태를 수정할 수 있습니다
+
+### View 함수 {#view-functions}
+
+이 함수들은 컨트랙트 데이터를 변경하지 않습니다. 흔히 "getter" 함수라고도 하며 사용자의 지갑의 잔액을 얻을 때 사용될 때의 예시입니다.
+
+```solidity
+// Solidity 예시
+function balanceOf(address _owner) public view returns (uint256 _balance) {
+ return ownerPizzaCount[_owner];
+}
+```
+
+```python
+dappName: public(string)
+
+@view
+@public
+def readName() -> string:
+ return dappName
+```
+
+상태를 수정하는 것으로 간주되는 것:
+
+1. 상태 변수에 쓰기
+2. [이벤트 발생시키기](https://docs.soliditylang.org/en/v0.7.0/contracts.html#events).
+3. [다른 계약 생성하기](https://docs.soliditylang.org/en/v0.7.0/control-structures.html#creating-contracts).
+4. `selfdestruct` 사용하기.
+5. 호출을 통해 이더 전송
+6. `view` 또는 `pure`로 표시되지 않은 함수 호출하기.
+7. 저수준 호출 사용
+8. 특정 오프코드를 포함하는 인라인 어셈블리 사용
+
+### 생성자 함수 {#constructor-functions}
+
+`constructor` 함수는 계약이 처음 배포될 때 한 번만 실행됩니다. 많은 클래스 기반 프로그래밍 언어의 `constructor`와 마찬가지로, 이 함수는 종종 상태 변수를 지정된 값으로 초기화합니다.
+
+```solidity
+// Solidity 예시
+// 계약의 데이터를 초기화하고, `owner`를
+// 계약 생성자의 주소로 설정합니다.
+constructor() public {
+ // 모든 스마트 계약은 외부 트랜잭션에 의존하여 함수를 실행합니다.
+ // `msg`는 보낸 사람의 주소 및 트랜잭션에 포함된 ETH 값과 같은
+ // 주어진 트랜잭션의 관련 데이터를 포함하는 전역 변수입니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties
+ owner = msg.sender;
+}
+```
+
+```python
+# Vyper 예시
+
+@external
+def __init__(_beneficiary: address, _bidding_time: uint256):
+ self.beneficiary = _beneficiary
+ self.auctionStart = block.timestamp
+ self.auctionEnd = self.auctionStart + _bidding_time
+```
+
+### 내장 함수 {#built-in-functions}
+
+컨트랙트를 작성할 때 정의하는 변수와 함수 외에 추가적으로 사용할 수 있는 특별한 내장 함수가 있습니다. 대표적인 함수에는 아래가 있으며,
+
+- `address.send()` – 솔리디티
+- `send(address)` – Vyper
+
+다른 계정으로 ETH를 송금할 때 사용할 수 있습니다.
+
+## 함수 작성하기 {#writing-functions}
+
+당신의 함수에는 다음이 필요합니다:
+
+- 매개변수 변수 및 타입(매개변수를 받는 경우)
+- 내부/외부 선언
+- 순수(pure)/뷰(view)/지급(payable) 선언
+- 반환 타입(값을 반환하는 경우)
+
+```solidity
+pragma solidity >=0.4.0 <=0.6.0;
+
+contract ExampleDapp {
+ string dapp_name; // 상태 변수
+
+ // 계약이 배포될 때 호출되어 값을 초기화합니다
+ constructor() public {
+ dapp_name = "My Example dapp";
+ }
+
+ // Get 함수
+ function read_name() public view returns(string) {
+ return dapp_name;
+ }
+
+ // Set 함수
+ function update_name(string value) public {
+ dapp_name = value;
+ }
+}
+```
+
+완전한 계약은 다음과 같을 수 있습니다. 여기서 `constructor` 함수는 `dapp_name` 변수에 대한 초기값을 제공합니다.
+
+## 이벤트와 로그 {#events-and-logs}
+
+이벤트는 스마트 계약이 프론트엔드나 다른 구독 애플리케이션과 통신할 수 있게 합니다. 트랜잭션이 검증되어 블록에 추가되면, 스마트 계약은 이벤트를 방출하고 정보를 로그로 기록할 수 있으며, 프론트엔드는 이를 처리하고 활용할 수 있습니다.
+
+## 주석이 달린 예시 {#annotated-examples}
+
+이것들은 Solidity로 작성된 몇 가지 예시입니다. 코드를 사용해보고 싶다면 [Remix](http://remix.ethereum.org)에서 상호작용할 수 있습니다.
+
+### Hello world {#hello-world}
+
+```solidity
+// 시맨틱 버저닝을 사용하여 Solidity 버전을 지정합니다.
+// 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma
+pragma solidity ^0.5.10;
+
+// `HelloWorld`라는 이름의 계약을 정의합니다.
+// 계약은 함수와 데이터(상태)의 모음입니다.
+// 배포된 계약은 이더리움 블록체인의 특정 주소에 존재합니다.
+// 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html
+contract HelloWorld {
+
+ // `string` 유형의 상태 변수 `message`를 선언합니다.
+ // 상태 변수는 계약 저장 공간에 영구적으로 저장되는 변수입니다.
+ // `public` 키워드를 사용하면 계약 외부에서 변수에 접근할 수 있으며
+ // 다른 계약이나 클라이언트가 값을 접근하기 위해 호출할 수 있는 함수를 생성합니다.
+ string public message;
+
+ // 많은 클래스 기반 객체 지향 언어와 마찬가지로, 생성자는
+ // 계약 생성 시에만 실행되는 특별한 함수입니다.
+ // 생성자는 계약의 데이터를 초기화하는 데 사용됩니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors
+ constructor(string memory initMessage) public {
+ // 문자열 인수 `initMessage`를 받아 계약의 `message` 저장 공간 변수에
+ // 값을 설정합니다.
+ message = initMessage;
+ }
+
+ // 문자열 인수를 받아
+ // `message` 저장 공간 변수를 업데이트하는 public 함수입니다.
+ function update(string memory newMessage) public {
+ message = newMessage;
+ }
+}
+```
+
+### 토큰 {#token}
+
+```solidity
+pragma solidity ^0.5.10;
+
+contract Token {
+ // `address`는 이메일 주소와 비슷하며, 이더리움에서 계정을 식별하는 데 사용됩니다.
+ // 주소는 스마트 계약 또는 외부(사용자) 계정을 나타낼 수 있습니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/types.html#address
+ address public owner;
+
+ // `mapping`은 기본적으로 해시 테이블 데이터 구조입니다.
+ // 이 `mapping`은 부호 없는 정수(토큰 잔액)를 주소(토큰 보유자)에 할당합니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types
+ mapping (address => uint) public balances;
+
+ // 이벤트를 통해 블록체인 활동을 기록할 수 있습니다.
+ // 이더리움 클라이언트는 계약 상태 변경에 반응하기 위해 이벤트를 수신할 수 있습니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events
+ event Transfer(address from, address to, uint amount);
+
+ // 계약 데이터를 초기화하고, `owner`를
+ // 계약 생성자의 주소로 설정합니다.
+ constructor() public {
+ // 모든 스마트 계약은 외부 트랜잭션에 의존하여 함수를 실행합니다.
+ // `msg`는 보낸 사람의 주소 및 트랜잭션에 포함된 ETH 값과 같은
+ // 주어진 트랜잭션의 관련 데이터를 포함하는 전역 변수입니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties
+ owner = msg.sender;
+ }
+
+ // 새로운 토큰을 생성하여 주소로 보냅니다.
+ function mint(address receiver, uint amount) public {
+ // `require`는 특정 조건을 강제하는 데 사용되는 제어 구조입니다.
+ // `require`문이 `false`로 평가되면 예외가 발생하며,
+ // 현재 호출 동안 상태에 적용된 모든 변경 사항이 되돌려집니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions
+
+ // 계약 소유자만 이 함수를 호출할 수 있습니다
+ require(msg.sender == owner, "당신은 소유자가 아닙니다.");
+
+ // 토큰의 최대량을 강제합니다
+ require(amount < 1e60, "최대 발행량을 초과했습니다");
+
+ // `receiver`의 잔액을 `amount`만큼 증가시킵니다
+ balances[receiver] += amount;
+ }
+
+ // 호출자로부터 주소로 기존 토큰을 보냅니다.
+ function transfer(address receiver, uint amount) public {
+ // 보내는 사람은 보낼 만큼의 충분한 토큰을 가지고 있어야 합니다
+ require(amount <= balances[msg.sender], "잔액이 부족합니다.");
+
+ // 두 주소의 토큰 잔액을 조정합니다
+ balances[msg.sender] -= amount;
+ balances[receiver] += amount;
+
+ // 이전에 정의된 이벤트를 발생시킵니다
+ emit Transfer(msg.sender, receiver, amount);
+ }
+}
+```
+
+### 고유 디지털 자산 {#unique-digital-asset}
+
+```solidity
+pragma solidity ^0.5.10;
+
+// 다른 파일의 심볼을 현재 계약으로 가져옵니다.
+// 이 경우 OpenZeppelin의 일련의 헬퍼 계약입니다.
+// 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files
+
+import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721.sol";
+import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol";
+import "../node_modules/@openzeppelin/contracts/introspection/ERC165.sol";
+import "../node_modules/@openzeppelin/contracts/math/SafeMath.sol";
+
+// `is` 키워드는 외부 계약에서 함수와 키워드를 상속받는 데 사용됩니다.
+// 이 경우, `CryptoPizza`는 `IERC721` 및 `ERC165` 계약에서 상속받습니다.
+// 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance
+contract CryptoPizza is IERC721, ERC165 {
+ // OpenZeppelin의 SafeMath 라이브러리를 사용하여 산술 연산을 안전하게 수행합니다.
+ // 자세히 알아보기: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath
+ using SafeMath for uint256;
+
+ // Solidity의 상수 상태 변수는 다른 언어와 유사하지만
+ // 컴파일 시에 상수인 표현식에서 할당해야 합니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables
+ uint256 constant dnaDigits = 10;
+ uint256 constant dnaModulus = 10 ** dnaDigits;
+ bytes4 private constant _ERC721_RECEIVED = 0x150b7a02;
+
+ // Struct 유형을 사용하면 자신만의 유형을 정의할 수 있습니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs
+ struct Pizza {
+ string name;
+ uint256 dna;
+ }
+
+ // Pizza 구조체의 빈 배열을 생성합니다.
+ Pizza[] public pizzas;
+
+ // 피자 ID에서 소유자 주소로의 매핑
+ mapping(uint256 => address) public pizzaToOwner;
+
+ // 소유자 주소에서 소유한 토큰 수로의 매핑
+ mapping(address => uint256) public ownerPizzaCount;
+
+ // 토큰 ID에서 승인된 주소로의 매핑
+ mapping(uint256 => address) pizzaApprovals;
+
+ // 매핑을 중첩할 수 있습니다. 이 예는 소유자를 운영자 승인에 매핑합니다.
+ mapping(address => mapping(address => bool)) private operatorApprovals;
+
+ // 문자열(이름)과 DNA로부터 임의의 피자를 생성하는 내부 함수
+ function _createPizza(string memory _name, uint256 _dna)
+ // `internal` 키워드는 이 함수가 이 계약과
+ // 이 계약을 파생하는 계약 내에서만 보인다는 것을 의미합니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters
+ internal
+ // `isUnique`는 피자가 이미 존재하는지 확인하는 함수 제어자입니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers
+ isUnique(_name, _dna)
+ {
+ // 피자 배열에 피자를 추가하고 id를 얻습니다.
+ uint256 id = SafeMath.sub(pizzas.push(Pizza(_name, _dna)), 1);
+
+ // 피자 소유자가 현재 사용자와 동일한지 확인합니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions
+
+ // note that address(0)은 제로 주소이며,
+ // pizza[id]가 아직 특정 사용자에게 할당되지 않았음을 나타냅니다.
+
+ assert(pizzaToOwner[id] == address(0));
+
+ // 피자를 소유자에게 매핑합니다.
+ pizzaToOwner[id] = msg.sender;
+ ownerPizzaCount[msg.sender] = SafeMath.add(
+ ownerPizzaCount[msg.sender],
+ 1
+ );
+ }
+
+ // 문자열(이름)로부터 임의의 피자를 생성합니다.
+ function createRandomPizza(string memory _name) public {
+ uint256 randDna = generateRandomDna(_name, msg.sender);
+ _createPizza(_name, randDna);
+ }
+
+ // 문자열(이름)과 소유자 주소(생성자)로부터 임의의 DNA를 생성합니다.
+ function generateRandomDna(string memory _str, address _owner)
+ public
+ // `pure`로 표시된 함수는 상태를 읽거나 수정하지 않을 것을 약속합니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions
+ pure
+ returns (uint256)
+ {
+ // 문자열(이름) + 주소(소유자)로부터 임의의 uint를 생성합니다.
+ uint256 rand = uint256(keccak256(abi.encodePacked(_str))) +
+ uint256(_owner);
+ rand = rand % dnaModulus;
+ return rand;
+ }
+
+ // 소유자가 찾은 피자 배열을 반환합니다.
+ function getPizzasByOwner(address _owner)
+ public
+ // `view`로 표시된 함수는 상태를 수정하지 않을 것을 약속합니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions
+ view
+ returns (uint256[] memory)
+ {
+ // `memory` 저장 위치를 사용하여 이 함수 호출의
+ // 수명 주기 동안만 값을 저장합니다.
+ // 자세히 알아보기: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack
+ uint256[] memory result = new uint256[](ownerPizzaCount[_owner]);
+ uint256 counter = 0;
+ for (uint256 i = 0; i < pizzas.length; i++) {
+ if (pizzaToOwner[i] == _owner) {
+ result[counter] = i;
+ counter++;
+ }
+ }
+ return result;
+ }
+
+ // 피자와 소유권을 다른 주소로 이전합니다.
+ function transferFrom(address _from, address _to, uint256 _pizzaId) public {
+ require(_from != address(0) && _to != address(0), "유효하지 않은 주소입니다.");
+ require(_exists(_pizzaId), "피자가 존재하지 않습니다.");
+ require(_from != _to, "같은 주소로 전송할 수 없습니다.");
+ require(_isApprovedOrOwner(msg.sender, _pizzaId), "주소가 승인되지 않았습니다.");
+
+ ownerPizzaCount[_to] = SafeMath.add(ownerPizzaCount[_to], 1);
+ ownerPizzaCount[_from] = SafeMath.sub(ownerPizzaCount[_from], 1);
+ pizzaToOwner[_pizzaId] = _to;
+
+ // 가져온 IERC721 계약에 정의된 이벤트를 발생시킵니다.
+ emit Transfer(_from, _to, _pizzaId);
+ _clearApproval(_to, _pizzaId);
+ }
+
+ /**
+ * 주어진 토큰 ID의 소유권을 다른 주소로 안전하게 이전합니다.
+ * 대상 주소가 계약인 경우, `onERC721Received`를 구현해야 하며,
+ * 이는 안전한 전송 시 호출되고 매직 값
+ * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`을 반환해야 합니다.
+ * 그렇지 않으면 전송이 되돌려집니다.
+ */
+ function safeTransferFrom(address from, address to, uint256 pizzaId)
+ public
+ {
+ // solium-disable-next-line arg-overflow
+ this.safeTransferFrom(from, to, pizzaId, "");
+ }
+
+ /**
+ * 주어진 토큰 ID의 소유권을 다른 주소로 안전하게 이전합니다.
+ * 대상 주소가 계약인 경우, `onERC721Received`를 구현해야 하며,
+ * 이는 안전한 전송 시 호출되고 매직 값
+ * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`을 반환해야 합니다.
+ * 그렇지 않으면 전송이 되돌려집니다.
+ */
+ function safeTransferFrom(
+ address from,
+ address to,
+ uint256 pizzaId,
+ bytes memory _data
+ ) public {
+ this.transferFrom(from, to, pizzaId);
+ require(_checkOnERC721Received(from, to, pizzaId, _data), "onERC721Received를 구현해야 합니다.");
+ }
+
+ /**
+ * 대상 주소에서 `onERC721Received`를 호출하는 내부 함수
+ * 대상 주소가 계약이 아닌 경우 호출이 실행되지 않습니다.
+ */
+ function _checkOnERC721Received(
+ address from,
+ address to,
+ uint256 pizzaId,
+ bytes memory _data
+ ) internal returns (bool) {
+ if (!isContract(to)) {
+ return true;
+ }
+
+ bytes4 retval = IERC721Receiver(to).onERC721Received(
+ msg.sender,
+ from,
+ pizzaId,
+ _data
+ );
+ return (retval == _ERC721_RECEIVED);
+ }
+
+ // 피자를 소각합니다 - 토큰을 완전히 파괴합니다.
+ // `external` 함수 제어자는 이 함수가
+ // 계약 인터페이스의 일부이며 다른 계약이 호출할 수 있음을 의미합니다.
+ function burn(uint256 _pizzaId) external {
+ require(msg.sender != address(0), "유효하지 않은 주소입니다.");
+ require(_exists(_pizzaId), "피자가 존재하지 않습니다.");
+ require(_isApprovedOrOwner(msg.sender, _pizzaId), "주소가 승인되지 않았습니다.");
+
+ ownerPizzaCount[msg.sender] = SafeMath.sub(
+ ownerPizzaCount[msg.sender],
+ 1
+ );
+ pizzaToOwner[_pizzaId] = address(0);
+ }
+
+ // 주소별 피자 수를 반환합니다.
+ function balanceOf(address _owner) public view returns (uint256 _balance) {
+ return ownerPizzaCount[_owner];
+ }
+
+ // id로 찾은 피자의 소유자를 반환합니다.
+ function ownerOf(uint256 _pizzaId) public view returns (address _owner) {
+ address owner = pizzaToOwner[_pizzaId];
+ require(owner != address(0), "유효하지 않은 피자 ID입니다.");
+ return owner;
+ }
+
+ // 다른 주소가 피자의 소유권을 이전하도록 승인합니다.
+ function approve(address _to, uint256 _pizzaId) public {
+ require(msg.sender == pizzaToOwner[_pizzaId], "피자 소유자여야 합니다.");
+ pizzaApprovals[_pizzaId] = _to;
+ emit Approval(msg.sender, _to, _pizzaId);
+ }
+
+ // 특정 피자에 대해 승인된 주소를 반환합니다.
+ function getApproved(uint256 _pizzaId)
+ public
+ view
+ returns (address operator)
+ {
+ require(_exists(_pizzaId), "피자가 존재하지 않습니다.");
+ return pizzaApprovals[_pizzaId];
+ }
+
+ /**
+ * 주어진 토큰 ID의 현재 승인을 지우는 비공개 함수
+ * 주어진 주소가 토큰의 소유자가 아닌 경우 되돌립니다.
+ */
+ function _clearApproval(address owner, uint256 _pizzaId) private {
+ require(pizzaToOwner[_pizzaId] == owner, "피자 소유자여야 합니다.");
+ require(_exists(_pizzaId), "피자가 존재하지 않습니다.");
+ if (pizzaApprovals[_pizzaId] != address(0)) {
+ pizzaApprovals[_pizzaId] = address(0);
+ }
+ }
+
+ /*
+ * 주어진 운영자의 승인을 설정하거나 해제합니다.
+ * 운영자는 보낸 사람을 대신하여 모든 토큰을 이전할 수 있습니다.
+ */
+ function setApprovalForAll(address to, bool approved) public {
+ require(to != msg.sender, "자신의 주소를 승인할 수 없습니다.");
+ operatorApprovals[msg.sender][to] = approved;
+ emit ApprovalForAll(msg.sender, to, approved);
+ }
+
+ // 주어진 소유자가 운영자를 승인했는지 여부를 알려줍니다.
+ function isApprovedForAll(address owner, address operator)
+ public
+ view
+ returns (bool)
+ {
+ return operatorApprovals[owner][operator];
+ }
+
+ // 피자 소유권을 가져옵니다 - 승인된 사용자만 가능합니다.
+ function takeOwnership(uint256 _pizzaId) public {
+ require(_isApprovedOrOwner(msg.sender, _pizzaId), "주소가 승인되지 않았습니다.");
+ address owner = this.ownerOf(_pizzaId);
+ this.transferFrom(owner, msg.sender, _pizzaId);
+ }
+
+ // 피자가 존재하는지 확인합니다.
+ function _exists(uint256 pizzaId) internal view returns (bool) {
+ address owner = pizzaToOwner[pizzaId];
+ return owner != address(0);
+ }
+
+ // 주소가 소유자인지 또는 피자를 이전하도록 승인되었는지 확인합니다.
+ function _isApprovedOrOwner(address spender, uint256 pizzaId)
+ internal
+ view
+ returns (bool)
+ {
+ address owner = pizzaToOwner[pizzaId];
+ // 다음으로 인해 solium 검사를 비활성화합니다.
+ // https://github.com/duaraghav8/Solium/issues/175
+ // solium-disable-next-line operator-whitespace
+ return (spender == owner ||
+ this.getApproved(pizzaId) == spender ||
+ this.isApprovedForAll(owner, spender));
+ }
+
+ // 피자가 고유하고 아직 존재하지 않는지 확인합니다.
+ modifier isUnique(string memory _name, uint256 _dna) {
+ bool result = true;
+ for (uint256 i = 0; i < pizzas.length; i++) {
+ if (
+ keccak256(abi.encodePacked(pizzas[i].name)) ==
+ keccak256(abi.encodePacked(_name)) &&
+ pizzas[i].dna == _dna
+ ) {
+ result = false;
+ }
+ }
+ require(result, "같은 이름의 피자가 이미 존재합니다.");
+ _;
+ }
+
+ // 대상 주소가 계약인지 여부를 반환합니다.
+ function isContract(address account) internal view returns (bool) {
+ uint256 size;
+ // 현재 주소에 계약이 있는지 확인하는 더 좋은 방법은 없습니다.
+ // 해당 주소의 코드 크기를 확인하는 것보다.
+ // 이것이 어떻게 작동하는지에 대한 자세한 내용은 https://ethereum.stackexchange.com/a/14016/36603을
+ // 참조하세요.
+ // TODO Serenity 릴리스 전에 이것을 다시 확인하세요. 모든 주소가
+ // 계약이 될 것이기 때문입니다.
+ // solium-disable-next-line security/no-inline-assembly
+ assembly {
+ size := extcodesize(account)
+ }
+ return size > 0;
+ }
+}
+```
+
+## 더 읽어보기 {#further-reading}
+
+스마트 계약에 대한 더 완전한 개요를 원한다면 Solidity와 Vyper의 문서를 확인하세요:
+
+- [솔리디티](https://docs.soliditylang.org/)
+- [Vyper](https://docs.vyperlang.org/en/stable/)
+
+## 관련 주제 {#related-topics}
+
+- [스마트 계약](/developers/docs/smart-contracts/)
+- [이더리움 가상 머신](/developers/docs/evm/)
+
+## 관련 튜토리얼 {#related-tutorials}
+
+- [계약 크기 제한에 대응하기 위한 계약 축소](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– 스마트 계약의 크기를 줄이기 위한 몇 가지 실용적인 팁입니다._
+- [이벤트를 사용하여 스마트 계약에서 데이터 기록하기](/developers/tutorials/logging-events-smart-contracts/) _– 스마트 계약 이벤트에 대한 소개와 이를 사용하여 데이터를 기록하는 방법입니다._
+- [Solidity에서 다른 계약과 상호작용하기](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– 기존 계약에서 스마트 계약을 배포하고 상호작용하는 방법입니다._
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/compiling/index.md b/public/content/translations/ko/developers/docs/smart-contracts/compiling/index.md
new file mode 100644
index 00000000000..39f3f6f5198
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/compiling/index.md
@@ -0,0 +1,282 @@
+---
+title: "스마트 계약 컴파일"
+description: "스마트 계약을 컴파일해야 하는 이유와 컴파일이 실제로 무엇을 하는지에 대한 설명입니다."
+lang: ko
+incomplete: true
+---
+
+웹 앱과 이더리움 가상 머신(EVM)이 스마트 계약을 이해할 수 있도록 하기 위해 계약을 컴파일해야 합니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+컴파일에 대해 읽기 전에 [스마트 계약](/developers/docs/smart-contracts/)과 [이더리움 가상 머신](/developers/docs/evm/)에 대한 소개를 읽어보시면 도움이 될 수 있습니다.
+
+## EVM {#the-evm}
+
+[EVM](/developers/docs/evm/)이 계약을 실행하려면 **바이트코드**여야 합니다. 컴파일이 이 작업을 수행합니다.
+
+```solidity
+pragma solidity 0.4.24;
+
+contract Greeter {
+
+ function greet() public view returns (string memory) {
+ return "Hello";
+ }
+
+}
+```
+
+**다음과 같이**
+
+```
+PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH2 0x41 JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCFAE3217 EQ PUSH2 0x46 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH2 0x52 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH2 0x5B PUSH2 0xD6 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP4 DUP2 DUP2 MLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0x9B JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x80 JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0xC8 JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x60 PUSH1 0x40 DUP1 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 PUSH1 0x5 DUP2 MSTORE PUSH1 0x20 ADD PUSH32 0x48656C6C6F000000000000000000000000000000000000000000000000000000 DUP2 MSTORE POP SWAP1 POP SWAP1 JUMP STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 SLT 0xec 0xe 0xf5 0xf8 SLT 0xc7 0x2d STATICCALL ADDRESS SHR 0xdb COINBASE 0xb1 BALANCE 0xe8 0xf8 DUP14 0xda 0xad DUP13 LOG1 0x4c 0xb4 0x26 0xc2 DELEGATECALL PUSH7 0x8994D3E002900
+```
+
+이를 **연산 부호**라고 합니다. EVM 옵코드는 이더리움 가상 머신(EVM)이 실행할 수 있는 저수준 명령어입니다. 각 옵코드는 산술 연산, 논리 연산, 데이터 조작, 제어 흐름 등을 나타냅니다.
+
+[연산 부호에 대해 더 알아보기](/developers/docs/evm/opcodes/)
+
+## 웹 애플리케이션 {#web-applications}
+
+컴파일러는 애플리케이션이 계약을 이해하고 계약의 함수를 호출하는 데 필요한 \*\*애플리케이션 바이너리 인터페이스(ABI)\*\*도 생성합니다.
+
+ABI는 배포된 계약과 스마트 계약 기능을 설명하는 JSON 파일입니다. 이는 웹2와 웹3 간의 격차를 좁히는 데 도움이 됩니다.
+
+[JavaScript 클라이언트 라이브러리](/developers/docs/apis/javascript/)는 웹 앱 인터페이스에서 스마트 계약을 호출할 수 있도록 **ABI**를 읽습니다.
+
+아래는 ERC-20 토큰 계약에 대한 ABI입니다. ERC-20은 이더리움에서 거래할 수 있는 토큰입니다.
+
+```json
+[
+ {
+ "constant": true,
+ "inputs": [],
+ "name": "name",
+ "outputs": [
+ {
+ "name": "",
+ "type": "string"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "view",
+ "type": "function"
+ },
+ {
+ "constant": false,
+ "inputs": [
+ {
+ "name": "_spender",
+ "type": "address"
+ },
+ {
+ "name": "_value",
+ "type": "uint256"
+ }
+ ],
+ "name": "approve",
+ "outputs": [
+ {
+ "name": "",
+ "type": "bool"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "nonpayable",
+ "type": "function"
+ },
+ {
+ "constant": true,
+ "inputs": [],
+ "name": "totalSupply",
+ "outputs": [
+ {
+ "name": "",
+ "type": "uint256"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "view",
+ "type": "function"
+ },
+ {
+ "constant": false,
+ "inputs": [
+ {
+ "name": "_from",
+ "type": "address"
+ },
+ {
+ "name": "_to",
+ "type": "address"
+ },
+ {
+ "name": "_value",
+ "type": "uint256"
+ }
+ ],
+ "name": "transferFrom",
+ "outputs": [
+ {
+ "name": "",
+ "type": "bool"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "nonpayable",
+ "type": "function"
+ },
+ {
+ "constant": true,
+ "inputs": [],
+ "name": "decimals",
+ "outputs": [
+ {
+ "name": "",
+ "type": "uint8"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "view",
+ "type": "function"
+ },
+ {
+ "constant": true,
+ "inputs": [
+ {
+ "name": "_owner",
+ "type": "address"
+ }
+ ],
+ "name": "balanceOf",
+ "outputs": [
+ {
+ "name": "balance",
+ "type": "uint256"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "view",
+ "type": "function"
+ },
+ {
+ "constant": true,
+ "inputs": [],
+ "name": "symbol",
+ "outputs": [
+ {
+ "name": "",
+ "type": "string"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "view",
+ "type": "function"
+ },
+ {
+ "constant": false,
+ "inputs": [
+ {
+ "name": "_to",
+ "type": "address"
+ },
+ {
+ "name": "_value",
+ "type": "uint256"
+ }
+ ],
+ "name": "transfer",
+ "outputs": [
+ {
+ "name": "",
+ "type": "bool"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "nonpayable",
+ "type": "function"
+ },
+ {
+ "constant": true,
+ "inputs": [
+ {
+ "name": "_owner",
+ "type": "address"
+ },
+ {
+ "name": "_spender",
+ "type": "address"
+ }
+ ],
+ "name": "allowance",
+ "outputs": [
+ {
+ "name": "",
+ "type": "uint256"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "view",
+ "type": "function"
+ },
+ {
+ "payable": true,
+ "stateMutability": "payable",
+ "type": "fallback"
+ },
+ {
+ "anonymous": false,
+ "inputs": [
+ {
+ "indexed": true,
+ "name": "owner",
+ "type": "address"
+ },
+ {
+ "indexed": true,
+ "name": "spender",
+ "type": "address"
+ },
+ {
+ "indexed": false,
+ "name": "value",
+ "type": "uint256"
+ }
+ ],
+ "name": "Approval",
+ "type": "event"
+ },
+ {
+ "anonymous": false,
+ "inputs": [
+ {
+ "indexed": true,
+ "name": "from",
+ "type": "address"
+ },
+ {
+ "indexed": true,
+ "name": "to",
+ "type": "address"
+ },
+ {
+ "indexed": false,
+ "name": "value",
+ "type": "uint256"
+ }
+ ],
+ "name": "Transfer",
+ "type": "event"
+ }
+]
+```
+
+## 더 읽어보기 {#further-reading}
+
+- [ABI 사양](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _– Solidity_
+
+## 관련 주제 {#related-topics}
+
+- [JavaScript 클라이언트 라이브러리](/developers/docs/apis/javascript/)
+- [이더리움 가상 머신](/developers/docs/evm/)
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/composability/index.md b/public/content/translations/ko/developers/docs/smart-contracts/composability/index.md
new file mode 100644
index 00000000000..562f20c0765
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/composability/index.md
@@ -0,0 +1,76 @@
+---
+title: "스마트 계약 구성 가능성"
+description: "스마트 계약이 레고 블록처럼 결합되어 기존 구성 요소를 재사용하여 복잡한 탈중앙화앱을 구축하는 방법을 알아보세요."
+lang: ko
+incomplete: true
+---
+
+## 간단한 소개 {#a-brief-introduction}
+
+스마트 컨트랙트는 이더리움 상에서 공개되어 오픈 API처럼 생각할 수 있습니다. dapp 개발자가 되기 위해서는 직접 스마트 계약을 작성할 필요가 없습니다. 계약과 상호작용하는 방법만 알면 됩니다. 예를 들어, 탈중앙화 거래소인 [Uniswap](https://uniswap.exchange/swap)의 기존 스마트 계약을 사용하여 앱의 모든 토큰 스왑 로직을 처리할 수 있습니다. 처음부터 시작할 필요가 없습니다. [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) 및 [v3](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts) 계약 중 일부를 확인해 보세요.
+
+## 구성 가능성이란? {#what-is-composability}
+
+구성 가능성이란 별개의 구성 요소를 결합하여 새로운 시스템이나 출력을 생성하는 것입니다. 소프트웨어 개발에서 구성 가능성은 개발자가 기존 소프트웨어 구성 요소를 재사용하여 새로운 애플리케이션을 구축할 수 있음을 의미합니다. 구성 가능성을 이해하는 좋은 방법은 구성 요소를 레고 블록으로 생각하는 것입니다. 각 레고 블록은 다른 블록과 결합될 수 있으며, 서로 다른 레고 블록을 결합하여 복잡한 구조를 만들 수 있습니다.
+
+이더리움에서는 모든 스마트 계약이 일종의 레고입니다. 다른 프로젝트의 스마트 계약을 사용하여 프로젝트의 구성 요소로 사용할 수 있습니다. 이는 기본 기능을 처음부터 다시 만들 필요가 없다는 것을 의미합니다.
+
+## 구성 가능성은 어떻게 작동합니까? {#how-does-composability-work}
+
+이더리움 스마트 계약은 공개 API와 같아서 누구나 계약과 상호작용하거나 이를 dapp에 통합하여 기능을 추가할 수 있습니다. 스마트 계약 구성 가능성은 주로 세 가지 원칙에 따라 작동합니다: 모듈성, 자율성, 검색 가능성:
+
+**1.** **모듈성**: 개별 구성 요소가 특정 작업을 수행할 수 있는 능력입니다. 이더리움에서는 모든 스마트 계약이 특정 사용 사례를 가지고 있습니다(유니스왑 예시에서 보여준 것처럼).
+
+**2.** **자율성**: 구성 가능한 구성 요소는 독립적으로 작동할 수 있어야 합니다. 이더리움의 각 스마트 계약은 스스로 실행되며 시스템의 다른 부분에 의존하지 않고도 작동할 수 있습니다.
+
+**3.** **검색 가능성**: 외부 계약이나 소프트웨어 라이브러리가 공개적으로 사용 가능하지 않은 경우 개발자가 이를 호출하거나 애플리케이션에 통합할 수 없습니다. 스마트 계약은 기본적으로 오픈소스입니다. 누구나 스마트 계약을 호출하거나 코드베이스를 포크할 수 있습니다.
+
+## 구성 가능성의 이점 {#benefits-of-composability}
+
+### 개발 주기 단축 {#shorter-development-cycle}
+
+구성 가능성은 개발자가 [탈중앙화앱](/apps/#what-are-dapps)을 만들 때 해야 할 작업을 줄여줍니다. [Naval Ravikant가 말했듯이:](https://twitter.com/naval/status/1444366754650656770) "오픈 소스는 모든 문제를 한 번만 해결하면 된다는 것을 의미합니다."
+
+어떤 문제를 해결하는 스마트 계약이 있다면, 다른 개발자들은 그것을 재사용할 수 있으므로 같은 문제를 다시 해결할 필요가 없습니다. 이 방법으로 개발자는 기존 소프트웨어 라이브러리를 사용하여 새로운 dapp을 만들기 위해 추가 기능을 추가할 수 있습니다.
+
+### 혁신 증대 {#greater-innovation}
+
+구성 가능성은 개발자가 오픈소스 코드를 자유롭게 재사용, 수정, 복제 또는 통합하여 원하는 결과를 만들 수 있기 때문에 혁신과 실험을 장려합니다. 결과적으로 개발 팀은 기본 기능에 더 적은 시간을 할애하고 새로운 기능을 실험하는 데 더 많은 시간을 할애할 수 있습니다.
+
+### 더 나은 사용자 경험 {#better-user-experience}
+
+이더리움 생태계의 구성 요소 간 상호 운용성은 사용자 경험을 향상시킵니다. dapp이 외부 스마트 계약을 통합하면 사용자들은 더 큰 기능을 사용할 수 있습니다.
+
+우리는 상호 운용성의 이점을 설명하기 위해 차익 거래의 예를 사용할 것입니다:
+
+`exchange A`에서 토큰이 `exchange B`보다 더 높은 가격으로 거래된다면, 가격 차이를 이용해 수익을 낼 수 있습니다. 하지만 거래에 자금을 댈 충분한 자본이 있는 경우에만 가능합니다(즉, `exchange B`에서 토큰을 구매하여 `exchange A`에 판매하는 것).
+
+거래 자금을 충분히 확보하지 못한 경우, 플래시 론이 적합할 수 있습니다. [플래시 론](/defi/#flash-loans)은 고도로 기술적이지만, 기본 개념은 (담보 없이) 자산을 빌리고 _하나의_ 거래 내에서 동일한 자산을 반환할 수 있다는 것입니다.
+
+처음의 예시로 돌아가서, 차익 거래자는 대규모 플래시 론을 받아 `exchange B`에서 토큰을 구매하고 `exchange A`에서 판매한 후, 동일한 거래 내에서 원금과 이자를 상환하고 수익을 챙길 수 있습니다. 이러한 복잡한 로직은 여러 계약에 대한 호출을 결합해야 하며, 이는 스마트 계약이 상호운용성이 부족할 경우 불가능할 것입니다.
+
+## 이더리움의 구성 가능성 예시 {#composability-in-ethereum}
+
+### 토큰 스왑 {#token-swaps}
+
+ETH로 거래 비용을 지불해야 하는 Dapp을 생성하는 경우, 토큰 교환 로직을 통합하여 사용자가 다른 ERC-20 토큰으로 지불할 수 있도록 할 수 있습니다. 코드는 사용자의 토큰을 ETH로 자동 변환한 후 계약이 호출된 기능을 실행할 수 있습니다.
+
+### 거버넌스 {#governance}
+
+[DAO](/dao/)를 위한 맞춤형 거버넌스 시스템을 구축하는 것은 비용과 시간이 많이 소요될 수 있습니다. 대신 [Aragon Client](https://client.aragon.org/)와 같은 오픈소스 거버넌스 툴킷을 사용하여 DAO를 부트스트랩하고 거버넌스 프레임워크를 신속하게 만들 수 있습니다.
+
+### 신원 관리 {#identity-management}
+
+맞춤 인증 시스템을 구축하거나 중앙 집중식 제공자에 의존하는 대신, 분산된 신원 (DID) 도구를 통합하여 사용자 인증을 관리할 수 있습니다. 예를 들어 [SpruceID](https://www.spruceid.com/)는 사용자가 이더리움 지갑으로 신원을 인증할 수 있도록 하는 "이더리움으로 로그인" 기능을 제공하는 오픈소스 툴킷입니다.
+
+## 관련 튜토리얼 {#related-tutorials}
+
+- [create-eth-app으로 탈중앙화앱 프론트엔드 개발 시작하기](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _– create-eth-app을 사용하여 인기 있는 스마트 계약이 포함된 앱을 바로 만드는 방법에 대한 개요입니다._
+
+## 더 읽어보기 {#further-reading}
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
+
+- [구성 가능성은 혁신이다](https://a16zcrypto.com/posts/article/how-composability-unlocks-crypto-and-everything-else/)
+- [웹3에서 구성 가능성이 중요한 이유](https://hackernoon.com/why-composability-matters-for-web3)
+- [구성 가능성이란 무엇인가?](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.)
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/deploying/index.md b/public/content/translations/ko/developers/docs/smart-contracts/deploying/index.md
new file mode 100644
index 00000000000..0b24afc72f4
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/deploying/index.md
@@ -0,0 +1,81 @@
+---
+title: "스마트 컨트랙트 배포"
+description: "필수 구성 요소, 도구, 배포 단계를 포함하여 이더리움 네트워크에 스마트 계약을 배포하는 방법을 알아보세요."
+lang: ko
+---
+
+이더리움 네트워크 유저들이 스마트 계약을 이용할 수 있으려면 스마트계약 배포를 마쳐야 합니다.
+
+스마트 계약 배포는 컴파일된 코드를 포함하는 이더리움 거래를 받는 이를 지정하지 않고 보내는 식으로 이루어 집니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+스마트 계약을 배포하기 전에 [이더리움 네트워크](/developers/docs/networks/), [거래](/developers/docs/transactions/) 및 [스마트 계약의 구조](/developers/docs/smart-contracts/anatomy/)를 이해해야 합니다.
+
+계약은 블록체인에 저장되므로 배포 시 이더(ETH)가 필요합니다. 따라서 이더리움의 [가스 및 수수료](/developers/docs/gas/)에 대해 잘 알고 있어야 합니다.
+
+마지막으로, 계약을 배포하기 전에 컴파일해야 하므로 [스마트 계약 컴파일](/developers/docs/smart-contracts/compiling/)에 대해 읽어보시기 바랍니다.
+
+## 스마트 계약 배포 방법 {#how-to-deploy-a-smart-contract}
+
+### 필요한 것 {#what-youll-need}
+
+- 계약의 바이트코드 – [컴파일](/developers/docs/smart-contracts/compiling/)을 통해 생성됩니다.
+- 가스비(이더) - 일반 거래처럼 가스 한도를 설정이 필요합니다. 그러나 일반 거래보다는 계약 배포가 더 많은 가스 한도를 설정하십시오.
+- 배포 스크립트 또는 플러그인
+- 자체 노드 실행, 공용 노드 연결, 또는 [노드 서비스](/developers/docs/nodes-and-clients/nodes-as-a-service/)의 API 키를 통한 [이더리움 노드](/developers/docs/nodes-and-clients/) 액세스
+
+### 스마트 계약 배포 단계 {#steps-to-deploy}
+
+구체적인 단계는 개발 프레임워크에 따라 다릅니다. 예를 들어, [계약 배포에 관한 Hardhat 문서](https://hardhat.org/docs/tutorial/deploying) 또는 [스마트 계약 배포 및 검증에 관한 Foundry 문서](https://book.getfoundry.sh/forge/deploying)를 확인할 수 있습니다. 배포되면 계약은 다른 [계정](/developers/docs/accounts/)과 마찬가지로 이더리움 주소를 갖게 되며, [소스 코드 검증 도구](/developers/docs/smart-contracts/verifying/#source-code-verification-tools)를 사용하여 확인할 수 있습니다.
+
+## 관련 도구 {#related-tools}
+
+**Remix - _Remix IDE는 이더리움과 같은 블록체인을 위한 스마트 계약을 개발, 배포 및 관리할 수 있도록 지원합니다_**
+
+- [Remix](https://remix.ethereum.org)
+
+**Tenderly - _스마트 계약을 개발, 테스트, 모니터링, 운영하기 위한 디버깅, 관찰 가능성 및 인프라 구성 요소를 제공하는 Web3 개발 플랫폼_**
+
+- [tenderly.co](https://tenderly.co/)
+- [문서](https://docs.tenderly.co/)
+- [GitHub](https://github.com/Tenderly)
+- [Discord](https://discord.gg/eCWjuvt)
+
+**Hardhat - _이더리움 소프트웨어를 컴파일, 배포, 테스트 및 디버그할 수 있는 개발 환경_**
+
+- [hardhat.org](https://hardhat.org/getting-started/)
+- [계약 배포에 관한 문서](https://hardhat.org/docs/tutorial/deploying)
+- [GitHub](https://github.com/nomiclabs/hardhat)
+- [Discord](https://discord.com/invite/TETZs2KK4k)
+
+**thirdweb - _단일 명령어로 모든 EVM 호환 체인에 계약을 쉽게 배포하세요_**
+
+- [문서](https://portal.thirdweb.com/deploy/)
+
+**Crossmint - _엔터프라이즈급 웹3 개발 플랫폼으로 스마트 계약을 배포하고, 신용카드 및 크로스체인 결제를 활성화하며, API를 사용하여 NFT를 생성, 배포, 판매, 저장 및 편집할 수 있습니다._**
+
+- [crossmint.com](https://www.crossmint.com)
+- [개발문서](https://docs.crossmint.com)
+- [Discord](https://discord.com/invite/crossmint)
+- [블로그](https://blog.crossmint.com)
+
+## 관련 튜토리얼 {#related-tutorials}
+
+- [첫 번째 스마트 계약 배포하기](/developers/tutorials/deploying-your-first-smart-contract/) _– 이더리움 테스트넷에 첫 번째 스마트 계약을 배포하는 방법을 소개합니다._
+- [Hello World | 스마트 계약 튜토리얼](/developers/tutorials/hello-world-smart-contract/) _– 이더리움에 기본적인 스마트 계약을 생성 및 배포하는, 따라하기 쉬운 튜토리얼입니다._
+- [Solidity에서 다른 계약과 상호작용하기](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– 기존 계약에서 스마트 계약을 배포하고 상호작용하는 방법입니다._
+- [계약 크기 줄이는 방법](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _- 계약 크기를 제한 아래로 줄여 가스를 절약하는 방법_
+
+## 더 읽어보기 {#further-reading}
+
+- [https://docs.openzeppelin.com/learn/deploying-and-interacting](https://docs.openzeppelin.com/learn/deploying-and-interacting) - _OpenZeppelin_
+- [Hardhat으로 계약 배포하기](https://hardhat.org/docs/tutorial/deploying) - _Nomic Labs_
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
+
+## 관련 주제 {#related-topics}
+
+- [개발 프레임워크](/developers/docs/frameworks/)
+- [이더리움 노드 실행하기](/developers/docs/nodes-and-clients/run-a-node/)
+- [서비스형 노드](/developers/docs/nodes-and-clients/nodes-as-a-service)
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/ko/developers/docs/smart-contracts/formal-verification/index.md
new file mode 100644
index 00000000000..2f7ecd83d39
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/formal-verification/index.md
@@ -0,0 +1,284 @@
+---
+title: "스마트 계약의 형식 검증"
+description: "이더리움 스마트 계약을 위한 형식 검증 개요"
+lang: ko
+---
+
+[스마트 계약](/developers/docs/smart-contracts/)은 새로운 사용 사례를 제시하고 사용자에게 가치를 창출하는 탈중앙화되고 신뢰가 필요 없으며 견고한 애플리케이션을 만들 수 있도록 합니다. 스마트 계약은 막대한 가치를 다루기 때문에 보안은 개발자에게 매우 중요한 고려 사항입니다.
+
+형식 검증은 [스마트 계약 보안](/developers/docs/smart-contracts/security/)을 향상시키기 위해 권장되는 기술 중 하나입니다. 프로그램을 명시하고, 설계하고, 검증하기 위해 [형식적 방법](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/)을 사용하는 형식 검증은 수년 동안 중요한 하드웨어 및 소프트웨어 시스템의 정확성을 보장하는 데 사용되어 왔습니다.
+
+스마트 계약에 구현될 때, 형식 검증은 계약의 비즈니스 로직이 사전에 정의된 사양을 충족함을 증명할 수 있습니다. 테스트와 같이 계약 코드의 정확성을 평가하는 다른 방법에 비해 형식 검증은 스마트 계약이 기능적으로 올바르다는 것을 더 강력하게 보장합니다.
+
+## 형식 검증이란 무엇인가요? {#what-is-formal-verification}
+
+형식 검증은 형식 사양에 대한 시스템의 정확성을 평가하는 과정을 의미합니다. 간단히 말해 형식 검증을 통해 시스템의 동작이 일부 요구 사항을 충족하는지(즉, 원하는 대로 작동하는지) 확인할 수 있습니다.
+
+시스템(이 경우 스마트 계약)의 예상 동작은 형식 모델링을 사용하여 설명되는 반면, 사양 언어는 형식적 속성을 생성할 수 있도록 합니다. 형식 검증 기술은 계약의 구현이 해당 사양을 준수하는지 검증하고 전자의 정확성에 대한 수학적 증명을 도출할 수 있습니다. 계약이 사양을 충족하면 '기능적으로 올바름', '설계에 따라 올바름' 또는 '구성에 따라 올바름'으로 설명됩니다.
+
+### 형식 모델이란 무엇인가요? {#what-is-a-formal-model}
+
+컴퓨터 과학에서 [형식 모델](https://en.wikipedia.org/wiki/Model_of_computation)은 계산 과정에 대한 수학적 설명입니다. 프로그램은 수학적 함수(방정식)로 추상화되며, 모델은 입력이 주어졌을 때 함수에 대한 출력이 어떻게 계산되는지를 설명합니다.
+
+형식 모델은 프로그램의 동작 분석을 평가할 수 있는 추상화 수준을 제공합니다. 형식 모델의 존재는 해당 모델의 바람직한 속성을 설명하는 _형식 사양_을 생성할 수 있게 합니다.
+
+형식 검증을 위해 스마트 계약을 모델링하는 데는 여러 기술이 사용됩니다. 예를 들어, 일부 모델은 스마트 계약의 상위 수준 동작에 대해 추론하는 데 사용됩니다. 이러한 모델링 기술은 스마트 계약에 블랙박스 관점을 적용하여, 입력을 수락하고 해당 입력을 기반으로 계산을 실행하는 시스템으로 봅니다.
+
+상위 수준 모델은 스마트 계약과 외부 소유 계정(EOA), 계약 계정, 블록체인 환경과 같은 외부 에이전트 간의 관계에 중점을 둡니다. 이러한 모델은 특정 사용자 상호 작용에 대한 계약의 동작 방식을 지정하는 속성을 정의하는 데 유용합니다.
+
+반대로, 다른 형식 모델은 스마트 계약의 하위 수준 동작에 중점을 둡니다. 상위 수준 모델은 계약의 기능에 대한 추론에 도움이 될 수 있지만, 구현의 내부 작동에 대한 세부 정보를 포착하지 못할 수 있습니다. 하위 수준 모델은 프로그램 분석에 화이트박스 관점을 적용하고 프로그램 추적 및 [제어 흐름 그래프](https://en.wikipedia.org/wiki/Control-flow_graph)와 같은 스마트 계약 애플리케이션의 하위 수준 표현에 의존하여 계약 실행과 관련된 속성을 추론합니다.
+
+하위 수준 모델은 이더리움의 실행 환경(즉, [EVM](/developers/docs/evm/))에서 스마트 계약의 실제 실행을 나타내므로 이상적인 것으로 간주됩니다. 하위 수준 모델링 기술은 스마트 계약에서 중요한 안전 속성을 설정하고 잠재적인 취약점을 감지하는 데 특히 유용합니다.
+
+### 형식 사양이란 무엇인가요? {#what-is-a-formal-specification}
+
+사양은 특정 시스템이 충족해야 하는 기술적 요구 사항입니다. 프로그래밍에서 사양은 프로그램 실행에 대한 일반적인 아이디어(즉, 프로그램이 무엇을 해야 하는지)를 나타냅니다.
+
+스마트 계약의 맥락에서 형식 사양은 계약이 충족해야 하는 요구 사항에 대한 형식적 설명인 _속성_을 의미합니다. 이러한 속성은 '불변성'으로 설명되며 예외 없이 모든 가능한 상황에서 참으로 유지되어야 하는 계약 실행에 대한 논리적 주장을 나타냅니다.
+
+따라서 형식 사양을 스마트 계약의 의도된 실행을 설명하는 형식 언어로 작성된 문장의 모음으로 생각할 수 있습니다. 사양은 계약의 속성을 다루고 다양한 상황에서 계약이 어떻게 작동해야 하는지 정의합니다. 형식 검증의 목적은 스마트 계약이 이러한 속성(불변성)을 소유하고 있는지, 그리고 이러한 속성이 실행 중에 위반되지 않는지를 확인하는 것입니다.
+
+형식 사양은 스마트 계약의 보안 구현을 개발하는 데 중요합니다. 불변성을 구현하지 못하거나 실행 중에 속성이 위반된 계약은 기능을 손상시키거나 악의적인 익스플로잇을 유발할 수 있는 취약점에 노출되기 쉽습니다.
+
+## 스마트 계약의 형식 사양 유형 {#formal-specifications-for-smart-contracts}
+
+형식 사양을 통해 프로그램 실행의 정확성에 대한 수학적 추론이 가능합니다. 형식 모델과 마찬가지로 형식 사양은 계약 구현의 상위 수준 속성이나 하위 수준 동작을 포착할 수 있습니다.
+
+형식 사양은 프로그램의 속성에 대한 형식적 추론을 허용하는 [프로그램 논리](https://en.wikipedia.org/wiki/Logic_programming)의 요소를 사용하여 파생됩니다. 프로그램 논리에는 프로그램의 예상 동작을 (수학적 언어로) 표현하는 형식 규칙이 있습니다. [도달 가능성 논리](https://en.wikipedia.org/wiki/Reachability_problem), [시간 논리](https://en.wikipedia.org/wiki/Temporal_logic), [호어 논리](https://en.wikipedia.org/wiki/Hoare_logic)를 포함하여 형식 사양을 만드는 데 다양한 프로그램 논리가 사용됩니다.
+
+스마트 계약에 대한 형식 사양은 크게 **상위 수준** 또는 **하위 수준** 사양으로 분류할 수 있습니다. 사양이 속한 범주에 관계없이 분석 중인 시스템의 속성을 적절하고 명확하게 설명해야 합니다.
+
+### 상위 수준 사양 {#high-level-specifications}
+
+이름에서 알 수 있듯이 상위 수준 사양('모델 지향 사양'이라고도 함)은 프로그램의 상위 수준 동작을 설명합니다. 상위 수준 사양은 스마트 계약을 작업을 수행하여 상태 간에 전환할 수 있는 [유한 상태 머신](https://en.wikipedia.org/wiki/Finite-state_machine)(FSM)으로 모델링하며, 시간 논리를 사용하여 FSM 모델의 형식적 속성을 정의합니다.
+
+[시간 논리](https://en.wikipedia.org/wiki/Temporal_logic)는 '시간의 관점에서 한정된 명제에 대해 추론하기 위한 규칙(예: '나는 _항상_ 배고프다' 또는 '나는 _결국_ 배고플 것이다')'입니다. 형식 검증에 적용될 때, 시간 논리는 상태 머신으로 모델링된 시스템의 올바른 동작에 대한 주장을 진술하는 데 사용됩니다. 특히, 시간 논리는 스마트 계약이 있을 수 있는 미래 상태와 상태 간 전환 방법을 설명합니다.
+
+상위 수준 사양은 일반적으로 스마트 계약에 대한 두 가지 중요한 시간적 속성인 **안전성**과 **활성**을 포착합니다. 안전성 속성은 '나쁜 일은 절대 일어나지 않는다'는 아이디어를 나타내며 일반적으로 불변성을 표현합니다. 안전성 속성은 [교착 상태](https://www.techtarget.com/whatis/definition/deadlock)로부터의 자유와 같은 일반적인 소프트웨어 요구 사항을 정의하거나 계약에 대한 도메인별 속성(예: 함수에 대한 접근 제어의 불변성, 상태 변수의 허용 값 또는 토큰 전송 조건)을 표현할 수 있습니다.
+
+예를 들어, ERC-20 토큰 계약에서 `transfer()` 또는 `transferFrom()` 사용 조건을 다루는 다음과 같은 안전성 요구 사항을 살펴보겠습니다. _'전송자의 잔액은 전송 요청된 토큰의 양보다 결코 낮아서는 안 된다.'_ 계약 불변성에 대한 이 자연어 설명은 형식(수학적) 사양으로 변환될 수 있으며, 그 후 유효성을 엄격하게 확인할 수 있습니다.
+
+활성 속성은 '결국 좋은 일이 일어난다'고 주장하며, 계약이 여러 상태를 거쳐 진행할 수 있는 능력과 관련이 있습니다. 활성 속성의 예로는 '유동성'이 있으며, 이는 요청 시 사용자에게 잔액을 전송하는 계약의 능력을 의미합니다. [Parity 지갑 사건](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html)에서 발생했던 것처럼 이 속성이 위반되면 사용자는 계약에 저장된 자산을 인출할 수 없게 됩니다.
+
+### 하위 수준 사양 {#low-level-specifications}
+
+상위 수준 사양은 계약의 유한 상태 모델을 시작점으로 삼고 이 모델의 바람직한 속성을 정의합니다. 이와 대조적으로 하위 수준 사양('속성 지향 사양'이라고도 함)은 종종 프로그램(스마트 계약)을 수학적 함수 모음으로 구성된 시스템으로 모델링하고 이러한 시스템의 올바른 동작을 설명합니다.
+
+간단히 말해, 하위 수준 사양은 _프로그램 추적_을 분석하고 이러한 추적을 통해 스마트 계약의 속성을 정의하려고 시도합니다. 추적은 스마트 계약의 상태를 변경하는 함수 실행 시퀀스를 의미합니다. 따라서 하위 수준 사양은 계약의 내부 실행에 대한 요구 사항을 지정하는 데 도움이 됩니다.
+
+하위 수준 형식 사양은 호어 스타일 속성 또는 실행 경로에 대한 불변성으로 주어질 수 있습니다.
+
+### 호어 스타일 속성 {#hoare-style-properties}
+
+[호어 논리](https://en.wikipedia.org/wiki/Hoare_logic)는 스마트 계약을 포함한 프로그램의 정확성에 대해 추론하기 위한 일련의 형식 규칙을 제공합니다. 호어 스타일 속성은 호어 삼중항 `{P}c{Q}`로 표시됩니다. 여기서 `c`는 프로그램이고 `P`와 `Q`는 `c`의 상태(즉, 프로그램)에 대한 술어이며, 각각 공식적으로 _사전 조건_과 _사후 조건_으로 설명됩니다.
+
+사전 조건은 함수의 올바른 실행에 필요한 조건을 설명하는 술어입니다. 계약을 호출하는 사용자는 이 요구 사항을 충족해야 합니다. 사후 조건은 함수가 올바르게 실행될 경우 함수가 설정하는 조건을 설명하는 술어입니다. 사용자는 함수를 호출한 후 이 조건이 참일 것으로 기대할 수 있습니다. 호어 논리에서 _불변성_은 함수 실행에 의해 보존되는(즉, 변경되지 않는) 술어입니다.
+
+호어 스타일 사양은 _부분적 정확성_ 또는 _전체 정확성_을 보장할 수 있습니다. 계약 함수의 구현은 함수가 실행되기 전에 사전 조건이 참이고 실행이 종료되면 사후 조건도 참인 경우 '부분적으로 올바름'입니다. 함수가 실행되기 전에 사전 조건이 참이고, 실행이 종료되는 것이 보장되며, 종료될 때 사후 조건이 참이면 전체 정확성의 증명이 얻어집니다.
+
+일부 실행은 종료되기 전에 지연되거나 전혀 종료되지 않을 수 있으므로 전체 정확성의 증명을 얻는 것은 어렵습니다. 즉, 이더리움의 가스 메커니즘이 무한 프로그램 루프를 방지하므로(실행이 성공적으로 종료되거나 '가스 부족' 오류로 인해 종료됨) 실행이 종료되는지 여부는 논란의 여지가 있는 문제입니다.
+
+호어 논리를 사용하여 생성된 스마트 계약 사양에는 계약의 함수 및 루프 실행에 대해 정의된 사전 조건, 사후 조건 및 불변성이 포함됩니다. 사전 조건에는 종종 함수에 대한 잘못된 입력 가능성이 포함되며, 사후 조건은 이러한 입력에 대한 예상 응답(예: 특정 예외 발생)을 설명합니다. 이러한 방식으로 호어 스타일 속성은 계약 구현의 정확성을 보장하는 데 효과적입니다.
+
+많은 형식 검증 프레임워크는 함수의 의미론적 정확성을 증명하기 위해 호어 스타일 사양을 사용합니다. 또한 솔리디티의 `require` 및 `assert` 문을 사용하여 호어 스타일 속성(어설션으로)을 계약 코드에 직접 추가할 수도 있습니다.
+
+`require` 문은 사전 조건 또는 불변성을 표현하며 종종 사용자 입력을 검증하는 데 사용되는 반면, `assert`는 안전에 필요한 사후 조건을 포착합니다. 예를 들어, 호출하는 계정의 ID에 대한 사전 조건 확인으로 `require`를 사용하여 함수에 대한 적절한 접근 제어(안전성 속성의 예)를 달성할 수 있습니다. 마찬가지로, 계약의 상태 변수 허용 값에 대한 불변성(예: 유통 중인 총 토큰 수)은 함수 실행 후 계약의 상태를 확인하기 위해 `assert`를 사용하여 위반으로부터 보호될 수 있습니다.
+
+### 추적 수준 속성 {#trace-level-properties}
+
+추적 기반 사양은 계약을 여러 상태 간에 전환하는 작업과 이러한 작업 간의 관계를 설명합니다. 앞서 설명했듯이 추적은 특정 방식으로 계약의 상태를 변경하는 작업의 시퀀스입니다.
+
+이 접근 방식은 미리 정의된 전환 집합(계약 함수에 의해 설명됨)과 함께 일부 미리 정의된 상태(상태 변수에 의해 설명됨)를 가진 상태 전환 시스템으로서의 스마트 계약 모델에 의존합니다. 또한, 프로그램의 실행 흐름을 그래픽으로 표현한 [제어 흐름 그래프](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/)(CFG)가 계약의 운영 의미론을 설명하는 데 자주 사용됩니다. 여기서 각 추적은 제어 흐름 그래프의 경로로 표시됩니다.
+
+주로 추적 수준 사양은 스마트 계약의 내부 실행 패턴에 대해 추론하는 데 사용됩니다. 추적 수준 사양을 생성함으로써 스마트 계약에 대한 허용 가능한 실행 경로(즉, 상태 전환)를 주장합니다. 기호 실행과 같은 기술을 사용하여 형식 모델에 정의되지 않은 경로를 실행이 따르지 않음을 형식적으로 검증할 수 있습니다.
+
+[DAO](/dao/) 계약의 예를 사용하여 추적 수준 속성을 설명해 보겠습니다. 이 계약에는 공개적으로 접근 가능한 몇 가지 기능이 있습니다. 여기서는 DAO 계약이 사용자가 다음 작업을 수행할 수 있도록 허용한다고 가정합니다.
+
+- 자금 예치
+
+- 자금 예치 후 제안에 투표
+
+- 제안에 투표하지 않으면 환불 요청
+
+추적 수준 속성의 예로는 _'자금을 예치하지 않은 사용자는 제안에 투표할 수 없음'_ 또는 _'제안에 투표하지 않은 사용자는 항상 환불을 요청할 수 있어야 함'_이 있습니다. 두 속성 모두 선호되는 실행 순서를 주장합니다(투표는 자금을 예치하기 _전_에 발생할 수 없으며 환불 요청은 제안에 투표한 _후_에 발생할 수 없습니다).
+
+## 스마트 계약의 형식 검증 기술 {#formal-verification-techniques}
+
+### 모델 체킹 {#model-checking}
+
+모델 체킹은 알고리즘이 스마트 계약의 형식 모델을 해당 사양과 대조하여 확인하는 형식 검증 기술입니다. 모델 체킹에서 스마트 계약은 종종 상태 전환 시스템으로 표현되며, 허용 가능한 계약 상태에 대한 속성은 시간 논리를 사용하여 정의됩니다.
+
+모델 체킹은 시스템(즉, 계약)의 추상적인 수학적 표현을 생성하고 [명제 논리](https://www.baeldung.com/cs/propositional-logic)에 기반한 공식을 사용하여 이 시스템의 속성을 표현해야 합니다. 이는 모델 체킹 알고리즘의 작업, 즉 수학적 모델이 주어진 논리 공식을 만족함을 증명하는 작업을 단순화합니다.
+
+형식 검증에서의 모델 체킹은 주로 시간 경과에 따른 계약의 동작을 설명하는 시간적 속성을 평가하는 데 사용됩니다. 스마트 계약의 시간적 속성에는 이전에 설명한 _안전성_과 _활성_이 포함됩니다.
+
+예를 들어, 접근 제어와 관련된 보안 속성(예: _계약 소유자만 `selfdestruct`를 호출할 수 있음_)은 형식 논리로 작성할 수 있습니다. 그 후, 모델 체킹 알고리즘은 계약이 이 형식 사양을 만족하는지 검증할 수 있습니다.
+
+모델 체킹은 상태 공간 탐색을 사용하며, 이는 스마트 계약의 모든 가능한 상태를 구성하고 속성 위반을 초래하는 도달 가능한 상태를 찾으려고 시도하는 것을 포함합니다. 그러나 이는 무한한 수의 상태( '상태 폭발 문제'로 알려짐)로 이어질 수 있으므로, 모델 체커는 스마트 계약의 효율적인 분석을 가능하게 하기 위해 추상화 기술에 의존합니다.
+
+### 정리 증명 {#theorem-proving}
+
+정리 증명은 스마트 계약을 포함한 프로그램의 정확성에 대해 수학적으로 추론하는 방법입니다. 계약 시스템의 모델과 해당 사양을 수학 공식(논리 문)으로 변환하는 과정이 포함됩니다.
+
+정리 증명의 목표는 이러한 문장 간의 논리적 동등성을 검증하는 것입니다. '논리적 동등성'('논리적 쌍방함의'라고도 함)은 첫 번째 문장이 참일 _경우에만_ 두 번째 문장이 참이 되는 두 문장 사이의 관계 유형입니다.
+
+계약 모델과 그 속성에 대한 문장 간의 필요한 관계(논리적 동등성)는 증명 가능한 문장(정리라고 함)으로 공식화됩니다. 형식적 추론 시스템을 사용하여 자동 정리 증명기는 정리의 유효성을 검증할 수 있습니다. 즉, 정리 증명기는 스마트 계약의 모델이 해당 사양과 정확히 일치함을 결정적으로 증명할 수 있습니다.
+
+모델 체킹은 계약을 유한 상태를 가진 전환 시스템으로 모델링하는 반면, 정리 증명은 무한 상태 시스템의 분석을 처리할 수 있습니다. 그러나 이는 자동 정리 증명기가 논리 문제가 '결정 가능'한지 여부를 항상 알 수 없다는 것을 의미합니다.
+
+결과적으로, 정리 증명기가 정확성 증명을 도출하도록 안내하기 위해 종종 인간의 도움이 필요합니다. 정리 증명에 인간의 노력을 사용하는 것은 완전히 자동화된 모델 체킹보다 사용 비용이 더 비쌉니다.
+
+### 기호 실행 {#symbolic-execution}
+
+기호 실행은 _구체적인 값_(예: `x == 5`) 대신 _기호 값_(예: `x > 5`)을 사용하여 함수를 실행함으로써 스마트 계약을 분석하는 방법입니다. 형식 검증 기술로서 기호 실행은 계약 코드의 추적 수준 속성에 대해 형식적으로 추론하는 데 사용됩니다.
+
+기호 실행은 실행 추적을 기호 입력 값에 대한 수학 공식으로 나타내며, 이를 _경로 술어_라고도 합니다. [SMT 솔버](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories)는 경로 술어가 '만족 가능'한지(즉, 공식을 만족할 수 있는 값이 존재하는지) 확인하는 데 사용됩니다. 취약한 경로가 만족 가능하면, SMT 솔버는 실행을 해당 경로로 유도하는 구체적인 값을 생성합니다.
+
+스마트 계약의 함수가 `uint` 값(`x`)을 입력으로 받고 `x`가 `5`보다 크고 `10`보다 작을 때 되돌린다고 가정해 보겠습니다. 일반적인 테스트 절차를 사용하여 오류를 유발하는 `x` 값을 찾는 것은 오류를 유발하는 입력을 실제로 찾을 수 있다는 보장 없이 수십 개(또는 그 이상)의 테스트 사례를 실행해야 합니다.
+
+반대로, 기호 실행 도구는 기호 값 `X > 5 ∧ X < 10` (즉, `x`가 5보다 크고 10보다 작음)으로 함수를 실행합니다. 연관된 경로 술어 `x = X > 5 ∧ X < 10`은 해결을 위해 SMT 솔버에 주어집니다. 특정 값이 `x = X > 5 ∧ X < 10` 공식을 만족하면 SMT 솔버가 이를 계산합니다. 예를 들어, 솔버는 `x`의 값으로 `7`을 생성할 수 있습니다.
+
+기호 실행은 프로그램에 대한 입력에 의존하고, 도달 가능한 모든 상태를 탐색하기 위한 입력 집합은 잠재적으로 무한하므로 여전히 테스트의 한 형태입니다. 그러나 예에서 보듯이, 기호 실행은 속성 위반을 유발하는 입력을 찾는 데 있어 일반적인 테스트보다 더 효율적입니다.
+
+또한, 기호 실행은 함수에 대한 입력을 무작위로 생성하는 다른 속성 기반 기술(예: 퍼징)보다 거짓 양성이 적습니다. 기호 실행 중에 오류 상태가 트리거되면, 오류를 트리거하는 구체적인 값을 생성하고 문제를 재현하는 것이 가능합니다.
+
+기호 실행은 또한 어느 정도의 수학적 정확성 증명을 제공할 수 있습니다. 오버플로 방지 기능이 있는 계약 함수의 다음 예를 고려해 보십시오.
+
+```
+function safe_add(uint x, uint y) returns(uint z){
+
+ z = x + y;
+ require(z>=x);
+ require(z>=y);
+
+ return z;
+}
+```
+
+정수 오버플로를 초래하는 실행 추적은 `z = x + y AND (z >= x) AND (z >= y) AND (z < x OR z < y)` 공식을 만족해야 합니다. 이러한 공식은 해결될 가능성이 거의 없으므로, `safe_add` 함수가 절대 오버플로되지 않는다는 수학적 증거 역할을 합니다.
+
+### 스마트 계약에 형식 검증을 사용하는 이유는 무엇인가요? {#benefits-of-formal-verification}
+
+#### 신뢰성의 필요성 {#need-for-reliability}
+
+형식 검증은 실패 시 사망, 부상 또는 재정적 파탄과 같은 파괴적인 결과를 초래할 수 있는 안전이 중요한 시스템의 정확성을 평가하는 데 사용됩니다. 스마트 계약은 막대한 가치를 제어하는 고부가가치 애플리케이션이며, 설계상의 사소한 오류는 [사용자에게 복구 불가능한 손실](https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce/amp/)을 초래할 수 있습니다. 그러나 배포 전에 계약을 형식적으로 검증하면 블록체인에서 실행될 때 예상대로 작동할 것이라는 보장을 높일 수 있습니다.
+
+신뢰성은 모든 스마트 계약에서 매우 바람직한 품질이며, 특히 이더리움 가상 머신(EVM)에 배포된 코드는 일반적으로 불변이기 때문입니다. 출시 후 업그레이드에 쉽게 접근할 수 없기 때문에 계약의 신뢰성을 보장해야 하므로 형식 검증이 필요합니다. 형식 검증은 감사자 및 테스터가 놓칠 수 있는 정수 언더플로 및 오버플로, 재진입성, 부실한 가스 최적화와 같은 까다로운 문제를 감지할 수 있습니다.
+
+#### 기능적 정확성 증명 {#prove-functional-correctness}
+
+프로그램 테스트는 스마트 계약이 일부 요구 사항을 충족함을 증명하는 가장 일반적인 방법입니다. 이는 계약이 처리할 것으로 예상되는 데이터 샘플로 계약을 실행하고 그 동작을 분석하는 것을 포함합니다. 계약이 샘플 데이터에 대해 예상 결과를 반환하면 개발자는 그 정확성에 대한 객관적인 증거를 갖게 됩니다.
+
+그러나 이 접근 방식은 샘플에 포함되지 않은 입력 값에 대한 올바른 실행을 증명할 수 없습니다. 따라서 계약을 테스트하면 버그를 감지하는 데 도움이 될 수 있지만(즉, 일부 코드 경로가 실행 중에 원하는 결과를 반환하지 못하는 경우), **버그가 없음을 결정적으로 증명할 수는 없습니다**.
+
+반대로 형식 검증은 계약을 전혀 실행하지 _않고도_ 스마트 계약이 무한한 실행 범위에 대한 요구 사항을 만족함을 형식적으로 증명할 수 있습니다. 이를 위해서는 올바른 계약 동작을 정확하게 설명하는 형식 사양을 만들고 계약 시스템의 형식(수학적) 모델을 개발해야 합니다. 그런 다음 형식 증명 절차에 따라 계약 모델과 해당 사양 간의 일관성을 확인할 수 있습니다.
+
+형식 검증을 통해 계약의 비즈니스 로직이 요구 사항을 만족하는지 검증하는 문제는 증명되거나 반증될 수 있는 수학적 명제입니다. 명제를 형식적으로 증명함으로써 유한한 단계로 무한한 수의 테스트 사례를 검증할 수 있습니다. 이러한 방식으로 형식 검증은 계약이 사양에 대해 기능적으로 올바르다는 것을 증명할 더 나은 가능성을 가집니다.
+
+#### 이상적인 검증 대상 {#ideal-verification-targets}
+
+검증 대상은 형식적으로 검증될 시스템을 설명합니다. 형식 검증은 '임베디드 시스템'(더 큰 시스템의 일부를 형성하는 작고 간단한 소프트웨어 조각)에 가장 잘 사용됩니다. 또한 규칙이 거의 없는 전문화된 도메인에도 이상적입니다. 이는 도메인별 속성을 검증하기 위한 도구를 수정하기 쉽게 만들기 때문입니다.
+
+스마트 계약은 어느 정도까지는 두 요구 사항을 모두 충족합니다. 예를 들어, 이더리움 계약의 작은 크기는 형식 검증에 적합하게 만듭니다. 마찬가지로, EVM은 간단한 규칙을 따르므로 EVM에서 실행되는 프로그램의 의미론적 속성을 지정하고 검증하기가 더 쉽습니다.
+
+### 더 빠른 개발 주기 {#faster-development-cycle}
+
+모델 체킹 및 기호 실행과 같은 형식 검증 기술은 일반적으로 스마트 계약 코드의 일반적인 분석(테스트 또는 감사 중에 수행됨)보다 더 효율적입니다. 이는 형식 검증이 주장을 테스트하기 위해 기호 값에 의존하기 때문입니다('사용자가 _n_ 이더를 인출하려고 하면 어떻게 될까?') 구체적인 값을 사용하는 테스트와는 다릅니다('사용자가 5 이더를 인출하려고 하면 어떻게 될까?').
+
+기호 입력 변수는 여러 클래스의 구체적인 값을 포함할 수 있으므로, 형식 검증 접근 방식은 더 짧은 시간 내에 더 많은 코드 범위를 약속합니다. 효과적으로 사용하면 형식 검증은 개발자의 개발 주기를 가속화할 수 있습니다.
+
+형식 검증은 또한 비용이 많이 드는 설계 오류를 줄여 탈중앙화 애플리케이션(탈중앙화앱) 구축 과정을 개선합니다. 취약점을 수정하기 위해 (가능한 경우) 계약을 업그레이드하려면 코드베이스를 광범위하게 다시 작성하고 개발에 더 많은 노력을 기울여야 합니다. 형식 검증은 테스터와 감사자가 놓칠 수 있는 계약 구현의 많은 오류를 감지하고 계약을 배포하기 전에 이러한 문제를 해결할 충분한 기회를 제공합니다.
+
+## 형식 검증의 단점 {#drawbacks-of-formal-verification}
+
+### 수작업 비용 {#cost-of-manual-labor}
+
+형식 검증, 특히 인간이 증명기가 정확성 증명을 도출하도록 안내하는 반자동 검증은 상당한 수작업을 필요로 합니다. 또한, 형식 사양을 만드는 것은 높은 수준의 기술을 요구하는 복잡한 활동입니다.
+
+이러한 요인(노력과 기술)은 형식 검증을 테스트 및 감사와 같은 계약의 정확성을 평가하는 일반적인 방법에 비해 더 까다롭고 비용이 많이 들게 만듭니다. 그럼에도 불구하고, 스마트 계약 구현의 오류 비용을 감안할 때 전체 검증 감사 비용을 지불하는 것은 실용적입니다.
+
+### 거짓 음성 {#false-negatives}
+
+형식 검증은 스마트 계약의 실행이 형식 사양과 일치하는지 여부만 확인할 수 있습니다. 따라서 사양이 스마트 계약의 예상 동작을 올바르게 설명하는지 확인하는 것이 중요합니다.
+
+사양이 잘못 작성되면, 속성 위반(취약한 실행을 가리킴)이 형식 검증 감사에 의해 감지될 수 없습니다. 이 경우 개발자는 계약에 버그가 없다고 잘못 가정할 수 있습니다.
+
+### 성능 문제 {#performance-issues}
+
+형식 검증은 여러 성능 문제에 부딪힙니다. 예를 들어, 모델 체킹 및 기호 체킹 중에 각각 발생하는 상태 및 경로 폭발 문제는 검증 절차에 영향을 미칠 수 있습니다. 또한 형식 검증 도구는 종종 기본 레이어에서 SMT 솔버 및 기타 제약 조건 솔버를 사용하며, 이러한 솔버는 계산 집약적인 절차에 의존합니다.
+
+또한 프로그램이 절대 종료되지 않을 수 있기 때문에 프로그램 검증기가 속성(논리 공식으로 설명됨)이 만족될 수 있는지 여부를 항상 결정할 수 있는 것은 아닙니다('[결정 문제](https://en.wikipedia.org/wiki/Decision_problem)'). 따라서 잘 명시되어 있더라도 계약에 대한 일부 속성을 증명하는 것이 불가능할 수 있습니다.
+
+## 이더리움 스마트 계약을 위한 형식 검증 도구 {#formal-verification-tools}
+
+### 형식 사양 생성을 위한 사양 언어 {#specification-languages}
+
+**Act**: __Act는 저장소 업데이트, 사전/사후 조건 및 계약 불변성의 사양을 허용합니다. 해당 도구 제품군에는 Coq, SMT 솔버 또는 hevm을 통해 많은 속성을 증명할 수 있는 증명 백엔드도 있습니다.__
+
+- [GitHub](https://github.com/ethereum/act)
+- [개발문서](https://github.com/argotorg/act)
+
+**Scribble** - __Scribble은 Scribble 사양 언어의 코드 주석을 사양을 확인하는 구체적인 주장으로 변환합니다.__
+
+- [개발문서](https://docs.scribble.codes/)
+
+**Dafny** - __Dafny는 코드의 정확성을 추론하고 증명하기 위해 상위 수준 주석에 의존하는 검증 준비 프로그래밍 언어입니다.__
+
+- [GitHub](https://github.com/dafny-lang/dafny)
+
+### 정확성 확인을 위한 프로그램 검증기 {#program-verifiers}
+
+**Certora Prover** - _Certora Prover는 스마트 계약의 코드 정확성을 확인하기 위한 자동 형식 검증 도구입니다. 사양은 CVL(Certora Verification Language)로 작성되며, 속성 위반은 정적 분석과 제약 조건 해결의 조합을 사용하여 감지됩니다._
+
+- [웹사이트](https://www.certora.com/)
+- [개발문서](https://docs.certora.com/en/latest/index.html)
+
+**Solidity SMTChecker** - __Solidity의 SMTChecker는 SMT(Satisfiability Modulo Theories) 및 Horn 해결을 기반으로 하는 내장 모델 체커입니다. 컴파일 중에 계약의 소스 코드가 사양과 일치하는지 확인하고 안전 속성 위반을 정적으로 확인합니다.__
+
+- [GitHub](https://github.com/ethereum/solidity)
+
+**solc-verify** - __solc-verify는 주석 및 모듈식 프로그램 검증을 사용하여 Solidity 코드에 대한 자동 형식 검증을 수행할 수 있는 Solidity 컴파일러의 확장 버전입니다.__
+
+- [GitHub](https://github.com/SRI-CSL/solidity)
+
+**KEVM** - __KEVM은 K 프레임워크로 작성된 이더리움 가상 머신(EVM)의 형식 의미론입니다. KEVM은 실행 가능하며 도달 가능성 논리를 사용하여 특정 속성 관련 주장을 증명할 수 있습니다.__
+
+- [GitHub](https://github.com/runtimeverification/evm-semantics)
+- [개발문서](https://jellopaper.org/)
+
+### 정리 증명을 위한 논리적 프레임워크 {#theorem-provers}
+
+**Isabelle** - _Isabelle/HOL은 수학 공식을 형식 언어로 표현하고 해당 공식을 증명하기 위한 도구를 제공하는 증명 보조 도구입니다. 주요 애플리케이션은 수학적 증명의 형식화, 특히 컴퓨터 하드웨어 또는 소프트웨어의 정확성을 증명하고 컴퓨터 언어 및 프로토콜의 속성을 증명하는 것을 포함하는 형식 검증입니다._
+
+- [GitHub](https://github.com/isabelle-prover)
+- [개발문서](https://isabelle.in.tum.de/documentation.html)
+
+**Rocq** - _Rocq는 정리를 사용하여 프로그램을 정의하고 기계 검사된 정확성 증명을 대화형으로 생성할 수 있는 대화형 정리 증명기입니다._
+
+- [GitHub](https://github.com/rocq-prover/rocq)
+- [개발문서](https://rocq-prover.org/docs)
+
+### 스마트 계약의 취약한 패턴을 감지하기 위한 기호 실행 기반 도구 {#symbolic-execution-tools}
+
+**Manticore** - __기호 실행을 기반으로 하는 EVM 바이트코드 분석 도구_._
+
+- [GitHub](https://github.com/trailofbits/manticore)
+- [개발문서](https://github.com/trailofbits/manticore/wiki)
+
+**hevm** - __hevm은 EVM 바이트코드에 대한 기호 실행 엔진 및 등가성 검사기입니다.__
+
+- [GitHub](https://github.com/dapphub/dapptools/tree/master/src/hevm)
+
+**Mythril** - _이더리움 스마트 계약의 취약점을 감지하기 위한 기호 실행 도구_
+
+- [GitHub](https://github.com/ConsenSys/mythril-classic)
+- [개발문서](https://mythril-classic.readthedocs.io/en/develop/)
+
+## 더 읽어보기 {#further-reading}
+
+- [스마트 계약의 형식 검증 작동 방식](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/)
+- [형식 검증이 완벽한 스마트 계약을 보장하는 방법](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1)
+- [이더리움 생태계의 형식 검증 프로젝트 개요](https://github.com/leonardoalt/ethereum_formal_verification_overview)
+- [이더리움 2.0 예치 스마트 계약의 종단 간 형식 검증](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/)
+- [세계에서 가장 인기 있는 스마트 계약 형식 검증하기](https://www.zellic.io/blog/formal-verification-weth)
+- [SMTChecker 및 형식 검증](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html)
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/index.md b/public/content/translations/ko/developers/docs/smart-contracts/index.md
new file mode 100644
index 00000000000..6a69ad8df35
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/index.md
@@ -0,0 +1,112 @@
+---
+title: "스마트 계약 소개"
+description: "스마트 컨트랙트의 개요, 고유한 특징과 한계에 집중하여"
+lang: ko
+---
+
+## 스마트 컨트랙트란 무엇인가요? 스마트 계약이란 무엇인가요? {#what-is-a-smart-contract}
+
+"스마트 컨트랙트"란 간단히 말해서 이더리움 블록체인 상에서 작동하는 프로그램입니다. 이것은 이더리움 블록체인 상에서 특정한 주소에 살고 있는 코드(함수들) 와 데이터(상태) 의 모음입니다.
+
+스마트 계약은 [이더리움 계정](/developers/docs/accounts/)의 한 유형입니다. 이는 잔액을 가지고 있으며 트랜잭션의 대상이 될 수 있음을 의미합니다. 그러나 사용자에 의해 조작되지 않고, 대신에 네트워크에 의해 배포되고 프로그램된 대로 작동합니다. 그렇기에 사용자 계정은 스마트 컨트랙트에 정의된 함수를 실행하는 트랜잭션을 제출함으로써 스마트 컨트랙트와 상호 작용할 수 있습니다. 스마트 컨트랙트는 일반적인 계약처럼 규칙을 정의할 수 있고, 코드를 통해 자동으로 규칙을 시행하기도 합니다. 스마트 계약은 기본적으로 삭제할 수 없으며, 스마트 계약과의 상호작용은 되돌릴 수 없습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이제 막 시작하셨거나 덜 기술적인 소개를 찾고 계신다면, 저희의 [스마트 계약 소개](/smart-contracts/)를 추천합니다.
+
+스마트 계약의 세계로 뛰어들기 전에 [계정](/developers/docs/accounts/), [트랜잭션](/developers/docs/transactions/), 그리고 [이더리움 가상 머신](/developers/docs/evm/)에 대해 충분히 숙지하시기 바랍니다.
+
+## 디지털 자판기 {#a-digital-vending-machine}
+
+스마트 계약에 대한 가장 좋은 비유는 [Nick Szabo](https://unenumerated.blogspot.com/)가 설명한 자판기일 것입니다. 올바른 입력으로, 확실한 결과가 보장됩니다.
+
+자판기에서 snack을 사려면:
+
+```
+돈 + 간식 선택 = 간식 제공
+```
+
+이 로직은 자판기 안에 프로그램되었습니다.
+
+자판기처럼 스마트 컨트랙트는 내부에 프로그램된 로직을 갖고 있습니다. 이 자판기가 솔리디티로 작성된 스마트 계약이라면 다음과 같이 보일 것입니다.
+
+```solidity
+pragma solidity 0.8.7;
+
+contract VendingMachine {
+
+ // 계약의 상태 변수 선언
+ address public owner;
+ mapping (address => uint) public cupcakeBalances;
+
+ // 'VendingMachine' 계약이 배포될 때:
+ // 1. 배포하는 주소를 계약의 소유자로 설정
+ // 2. 배포된 스마트 계약의 컵케이크 잔액을 100으로 설정
+ constructor() {
+ owner = msg.sender;
+ cupcakeBalances[address(this)] = 100;
+ }
+
+ // 소유자가 스마트 계약의 컵케이크 잔액을 늘릴 수 있도록 허용
+ function refill(uint amount) public {
+ require(msg.sender == owner, "소유자만 리필할 수 있습니다.");
+ cupcakeBalances[address(this)] += amount;
+ }
+
+ // 누구나 컵케이크를 구매할 수 있도록 허용
+ function purchase(uint amount) public payable {
+ require(msg.value >= amount * 1 ether, "컵케이크당 최소 1 ETH를 지불해야 합니다.");
+ require(cupcakeBalances[address(this)] >= amount, "이 구매를 완료하기에 재고가 충분하지 않습니다.");
+ cupcakeBalances[address(this)] -= amount;
+ cupcakeBalances[msg.sender] += amount;
+ }
+}
+```
+
+자판기가 종업원에 대한 필요성을 없앤 것처럼, 스마트 컨트랙트는 많은 산업에서 중재자를 대체할 수 있습니다.
+
+## 무허가성 {#permissionless}
+
+누구나 스마트 컨트랙트를 작성할 수 있고 네트워크에 배포할 수 있습니다. 그저 [스마트 계약 언어](/developers/docs/smart-contracts/languages/)로 코딩하는 법을 배우고, 계약을 배포하기에 충분한 ETH만 있으면 됩니다. 스마트 계약 배포는 기술적으로 트랜잭션이므로, 간단한 ETH 전송에 가스를 지불해야 하는 것과 같은 방식으로 [가스](/developers/docs/gas/)를 지불해야 합니다. 그러나 계약 배포의 가스 비용은 훨씬 높습니다.
+
+이더리움은 스마트 컨트랙트 작성을 위한 개발자-친화적인 언어들을 갖고 있습니다.
+
+- 솔리디티
+- Vyper
+
+[언어에 대해 더 알아보기](/developers/docs/smart-contracts/languages/)
+
+그러나, 이더리움 가상 머신이 컨트랙트를 해석하고 저장하기 위해서 이 언어들은 배포되기 전에 컴파일 되어야 합니다. [컴파일에 대해 더 알아보기](/developers/docs/smart-contracts/compiling/)
+
+## 구성 가능성 {#composability}
+
+스마트 컨트랙트는 이더리움 상에서 공개되어 오픈 API처럼 생각할 수 있습니다. 이는 스마트 계약에서 다른 스마트 계약을 호출하여 가능성을 크게 확장할 수 있음을 의미합니다. 심지어 컨트랙트는 다른 컨트랙트를 배포하기도 가능합니다.
+
+[스마트 계약 구성 가능성](/developers/docs/smart-contracts/composability/)에 대해 더 알아보세요.
+
+## 한계 {#limitations}
+
+스마트 계약만으로는 오프체인 소스에서 데이터를 가져올 수 없기 때문에 "현실 세계" 이벤트에 대한 정보를 얻을 수 없습니다. 이들은 현실 세계의 사건에 반응할 수 없습니다. 이는 설계된 것입니다. 외부 정보에 의존하는 것은 합의를 위협할 수 있고, 이는 보안과 탈중앙화에 중요합니다.
+
+그러나 블록체인 애플리케이션이 오프체인 데이터를 사용할 수 있는 것이 중요합니다. 해결책은 오프체인 데이터를 가져와 스마트 계약에서 사용할 수 있도록 하는 도구인 [오라클](/developers/docs/oracles/)입니다.
+
+스마트 컨트랙트의 다른 한계는 컨트랙트 최대 사이즈입니다. 스마트 컨트랙트는 최대 24KB까지 가능하거나 가스를 다 써버릴 수도 있습니다. [다이아몬드 패턴(The Diamond Pattern)](https://eips.ethereum.org/EIPS/eip-2535)을 사용하여 이 문제를 해결할 수 있습니다.
+
+## 멀티시그 계약 {#multisig}
+
+멀티시그(다중 서명) 계약은 거래를 실행하기 위해 여러 유효한 서명을 필요로 하는 스마트 계약 계정입니다. 이는 상당한 양의 이더 또는 기타 토큰을 보유한 계약에서 단일 실패 지점을 방지하는 데 매우 유용합니다. 멀티시그는 또한 계약 실행 및 키 관리를 여러 당사자로 분산시키며, 단일 프라이빗 키의 손실로 인해 자금을 영구적으로 잃지 않도록 합니다. 이러한 이유로 멀티시그 계약은 간단한 DAO 거버넌스에도 사용할 수 있습니다. 멀티시그는 실행을 위해 M개의 허용 가능한 서명 중 N개의 서명을 필요로 합니다(N ≤ M, 그리고 M > 1). `N = 3, M = 5`와 `N = 4, M = 7`이 일반적으로 사용됩니다. 4/7 멀티시그는 7개의 가능한 서명 중 4개가 유효한 서명임을 요구합니다. 이는 3개의 서명을 잃어도 자금을 여전히 복구할 수 있다는 의미입니다. 이 경우 또한 계약을 실행하려면 다수의 키 보유자가 동의하고 서명해야 한다는 것을 의미합니다.
+
+## 스마트 계약 참고 자료 {#smart-contract-resources}
+
+**OpenZeppelin Contracts -** **_안전한 스마트 계약 개발을 위한 라이브러리._**
+
+- [openzeppelin.com/contracts/](https://openzeppelin.com/contracts/)
+- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts)
+- [커뮤니티 포럼](https://forum.openzeppelin.com/c/general/16)
+
+## 더 읽어보기 {#further-reading}
+
+- [Coinbase: 스마트 계약이란 무엇인가요?](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract)
+- [Chainlink: 스마트 계약이란 무엇인가요?](https://chain.link/education/smart-contracts)
+- [영상: 간단한 설명 - 스마트 계약](https://youtu.be/ZE2HxTmxfrI)
+- [Cyfrin Updraft: 웹3 학습 및 감사 플랫폼](https://updraft.cyfrin.io)
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/languages/index.md b/public/content/translations/ko/developers/docs/smart-contracts/languages/index.md
new file mode 100644
index 00000000000..339709fd401
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/languages/index.md
@@ -0,0 +1,343 @@
+---
+title: "스마트 컨트랙트 언어"
+description: "두 종류의 주요 smart contract 언어에 대한 요약과 비교 - Solidity 와 Vyper"
+lang: ko
+---
+
+이더리움의 가장 좋은 점은 smart contract을 개발자 친화적인 언어로 프로그래밍 할 수 있다는 점이다. Python 또는 [중괄호 언어](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages)에 익숙하다면 친숙한 구문을 가진 언어를 찾을 수 있습니다.
+
+가장 활발하고 유지되는 언어들은 다음과 같다:
+
+- 솔리디티
+- Vyper
+
+Remix IDE는 Solidity 및 Vyper에서 계약을 생성하고 테스트하기 위한 종합 개발 환경을 제공합니다. [브라우저 내 Remix IDE](https://remix.ethereum.org)에서 코딩을 시작하세요.
+
+더 숙련된 개발자들은 [이더리움 가상 머신](/developers/docs/evm/)을 위한 중간 언어인 Yul 또는 Yul의 확장판인 Yul+를 사용할 수도 있습니다.
+
+만약 당신이 궁금하고 아직 힘들게 개발중인 새로운 언어 테스트를 도와주고 싶다면, smart contract 언어로 떠오르고 있지만 아직은 초창기 단계인 Fe 언어를 시도해볼 수 있다.
+
+## 필수 구성 요소 {#prerequisites}
+
+특히 Javascript나 Python에 대해 미리 알고 있다면, smart contract 언어의 차이를 이해하는데 도움을 줄 수 있다. 언어에 대한 차이를 너무 깊게 파고들기 전에 smart contract 개념을 먼저 이해하는 것을 추천한다. [스마트 계약 소개](/developers/docs/smart-contracts/).
+
+## 솔리디티 {#solidity}
+
+- Smart contract를 구현하기 위한 객체지향의 고급 언어 (high-level language).
+- C++로부터 영향을 가장 많이 받은 Curly-bracket 언어.
+- 정적 프로그래밍 언어 (자료형이 컴파일 시 결정되는 언어).
+- 지원:
+ - 상속 (다른 contract으로 확장할 수 있음).
+ - 라이브러리 (객체지향 프로그래밍 언어에서 정적(static) 클래스에 있는 정적 함수처럼 서로 다른 contract에서 부를 수 있는 재사용이 가능한 코드를 만들 수 있음).
+ - Complex user-defined types.
+
+### 중요 링크 {#important-links}
+
+- [개발문서](https://docs.soliditylang.org/en/latest/)
+- [솔리디티 언어 포털](https://soliditylang.org/)
+- [솔리디티 예제](https://docs.soliditylang.org/en/latest/solidity-by-example.html)
+- [GitHub](https://github.com/ethereum/solidity/)
+- [Solidity Gitter 채팅방](https://gitter.im/ethereum/solidity), [Solidity Matrix 채팅방](https://matrix.to/#/#ethereum_solidity:gitter.im)과 브리지됨
+- [치트 시트](https://reference.auditless.com/cheatsheet)
+- [솔리디티 블로그](https://blog.soliditylang.org/)
+- [솔리디티 트위터](https://twitter.com/solidity_lang)
+
+### 예제 계약 {#example-contract}
+
+```solidity
+// SPDX-License-Identifier: GPL-3.0
+pragma solidity >= 0.7.0;
+
+contract Coin {
+ // "public" 키워드는 변수를
+ // 다른 계약에서 접근할 수 있도록 합니다
+ address public minter;
+ mapping (address => uint) public balances;
+
+ // 이벤트는 클라이언트가 선언한 특정
+ // 계약 변경에 반응할 수 있도록 합니다
+ event Sent(address from, address to, uint amount);
+
+ // 생성자 코드는 계약이
+ // 생성될 때만 실행됩니다
+ constructor() {
+ minter = msg.sender;
+ }
+
+ // 새로 생성된 코인을 주소로 전송합니다
+ // 계약 생성자만 호출할 수 있습니다
+ function mint(address receiver, uint amount) public {
+ require(msg.sender == minter);
+ require(amount < 1e60);
+ balances[receiver] += amount;
+ }
+
+ // 기존 코인을
+ // 모든 호출자로부터 주소로 전송합니다
+ function send(address receiver, uint amount) public {
+ require(amount <= balances[msg.sender], "잔액이 부족합니다.");
+ balances[msg.sender] -= amount;
+ balances[receiver] += amount;
+ emit Sent(msg.sender, receiver, amount);
+ }
+}
+```
+
+이 예제를 통해 Solidity contract 문법이 어떤지 감을 찾을 수 있다. 함수와 변수에 대한 더 자세한 설명은 [문서를 참조하세요](https://docs.soliditylang.org/en/latest/contracts.html).
+
+## Vyper {#vyper}
+
+- Pythonic 프로그래밍 언어
+- 강한 타입
+- 작고 이해하기 쉬운 컴파일러 코드
+- 효율적인 바이트코드 생성
+- Contract을 더 안전하고 검사하기 쉽게 일부러 Solidity보다 기능이 적음. Vyper는 아래를 지원하지 않음:
+ - 제어자 (Modifiers)
+ - 상속
+ - 인라인 어셈블리 (Inline assembly)
+ - 함수 오버로드
+ - 연산자 오버로드
+ - 재귀 호출
+ - 무한 루프
+ - 이진 고정점 (Binary fixed points)
+
+자세한 내용은 [Vyper의 기본 원칙을 읽어보세요](https://vyper.readthedocs.io/en/latest/index.html).
+
+### 중요 링크 {#important-links-1}
+
+- [개발문서](https://vyper.readthedocs.io)
+- [예제로 배우는 Vyper](https://vyper.readthedocs.io/en/latest/vyper-by-example.html)
+- [예제로 배우는 Vyper 더 보기](https://vyper-by-example.org/)
+- [GitHub](https://github.com/vyperlang/vyper)
+- [Vyper 커뮤니티 Discord 채팅](https://discord.gg/SdvKC79cJk)
+- [치트 시트](https://reference.auditless.com/cheatsheet)
+- [Vyper를 위한 스마트 계약 개발 프레임워크 및 도구](/developers/docs/programming-languages/python/)
+- [VyperPunk - Vyper 스마트 계약을 보호하고 해킹하는 방법 배우기](https://github.com/SupremacyTeam/VyperPunk)
+- [개발을 위한 Vyper 허브](https://github.com/zcor/vyper-dev)
+- [Vyper 인기 스마트 계약 예제](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts)
+- [엄선된 Vyper 참고 자료 모음](https://github.com/spadebuilders/awesome-vyper)
+
+### 예제 {#example}
+
+```python
+# 공개 경매
+
+# 경매 매개변수
+
+# 수익자는 최고 입찰자로부터 금액을 받습니다
+
+beneficiary: public(address)
+auctionStart: public(uint256)
+auctionEnd: public(uint256)
+
+# 경매의 현재 상태
+
+highestBidder: public(address)
+highestBid: public(uint256)
+
+# 종료 시 true로 설정, 모든 변경을 금지합니다
+
+ended: public(bool)
+
+# 출금 패턴을 따를 수 있도록 환불된 입찰을 추적합니다
+
+pendingReturns: public(HashMap[address, uint256])
+
+# `_bidding_time`을 사용하여 간단한 경매를 생성합니다
+
+# `_beneficiary` 주소를 대신하여
+
+# 초 단위 입찰 시간을 지정합니다.
+
+@external
+def __init__(_beneficiary: address, _bidding_time: uint256):
+ self.beneficiary = _beneficiary
+ self.auctionStart = block.timestamp
+ self.auctionEnd = self.auctionStart + _bidding_time
+
+# 이 트랜잭션과 함께 전송된 금액으로 경매에
+
+# 입찰합니다.
+
+# 이 금액은 경매에서 이기지 못할 경우에만
+
+# 환불됩니다.
+
+@external
+@payable
+def bid():
+ # 입찰 기간이 끝났는지 확인합니다.
+ assert block.timestamp < self.auctionEnd
+ # 입찰가가 충분히 높은지 확인합니다.
+ assert msg.value > self.highestBid
+ # 이전 최고 입찰자에 대한 환불을 추적합니다.
+ self.pendingReturns[self.highestBidder] += self.highestBid
+ # 새로운 최고 입찰가를 추적합니다.
+ self.highestBidder = msg.sender
+ self.highestBid = msg.value
+
+# 이전에 환불된 입찰을 출금합니다. 출금 패턴은
+
+# 보안 문제를 피하기 위해 여기서 사용됩니다. 만약 환불이
+
+# bid()의 일부로 직접 전송된다면, 악의적인 입찰 계약이
+
+# 해당 환불을 막고, 따라서 더 높은 새로운 입찰이 들어오는 것을
+
+# 막을 수 있습니다.
+
+@external
+def withdraw():
+ pending_amount: uint256 = self.pendingReturns[msg.sender]
+ self.pendingReturns[msg.sender] = 0
+ send(msg.sender, pending_amount)
+
+# 경매를 종료하고 최고 입찰가를
+
+# 수익자에게 전송합니다.
+
+@external
+def endAuction():
+ # 다른 계약과 상호 작용하는(즉, 함수를 호출하거나 이더를 보내는)
+ # 함수를 세 단계로 구성하는 것이 좋은 지침입니다.
+ # 1. 조건 확인
+ # 2. 작업 수행(조건을 변경할 수 있음)
+ # 3. 다른 계약과 상호 작용
+ # 이러한 단계가 혼합되면 다른 계약이
+ # 현재 계약으로 다시 호출하여 상태를 수정하거나
+ # 효과(이더 지급)가 여러 번 수행되도록 할 수 있습니다.
+ # 내부적으로 호출된 함수가 외부 계약과의
+ # 상호 작용을 포함하는 경우, 이들도 외부 계약과의
+ # 상호 작용으로 간주되어야 합니다.
+
+ # 1. 조건
+ # 경매 종료 시간에 도달했는지 확인합니다.
+ assert block.timestamp >= self.auctionEnd
+ # 이 함수가 이미 호출되었는지 확인합니다.
+ assert not self.ended
+
+ # 2. 효과
+ self.ended = True
+
+ # 3. 상호 작용
+ send(self.beneficiary, self.highestBid)
+```
+
+이 예제를 통해 Vyper contract 문법이 어떤지 감을 찾을 수 있다. 함수와 변수에 대한 더 자세한 설명은 [문서를 참조하세요](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction).
+
+## Yul 및 Yul+ {#yul}
+
+이더리움을 처음 접하고 아직 스마트 계약 언어로 코딩해본 적이 없다면, Solidity 또는 Vyper로 시작하는 것이 좋습니다. 스마트 계약 보안 모범 사례와 EVM 작업의 구체적인 사항에 익숙해진 후에 Yul 또는 Yul+를 탐색하세요.
+
+**Yul**
+
+- 이더리움을 위한 중간 언어입니다.
+- [EVM](/developers/docs/evm)과 이더리움 기반의 웹어셈블리인 [Ewasm](https://github.com/ewasm)을 지원하며, 두 플랫폼 모두에서 사용할 수 있는 공통 분모로 설계되었습니다.
+- EVM과 Ewasm 플랫폼 모두에 유리한 고급 최적화 단계를 위한 좋은 목표입니다.
+
+**Yul+**
+
+- Yul의 저수준 및 고효율 확장입니다.
+- 처음에는 [낙관적 롤업](/developers/docs/scaling/optimistic-rollups/) 계약을 위해 설계되었습니다.
+- Yul+는 Yul의 새로운 기능을 추가하는 실험적 업그레이드 제안으로 볼 수 있습니다.
+
+### 중요 링크 {#important-links-2}
+
+- [Yul 개발문서](https://docs.soliditylang.org/en/latest/yul.html)
+- [Yul+ 개발문서](https://github.com/fuellabs/yulp)
+- [Yul+ 소개 게시물](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f)
+
+### 예제 계약 {#example-contract-2}
+
+다음의 간단한 예는 제곱 함수(power function)를 구현합니다. `solc --strict-assembly --bin input.yul`을 사용하여 컴파일할 수 있습니다. 이 예시는 input.yul 파일에 저장해야 합니다.
+
+```
+{
+ function power(base, exponent) -> result
+ {
+ switch exponent
+ case 0 { result := 1 }
+ case 1 { result := base }
+ default
+ {
+ result := power(mul(base, base), div(exponent, 2))
+ if mod(exponent, 2) { result := mul(base, result) }
+ }
+ }
+ let res := power(calldataload(0), calldataload(32))
+ mstore(0, res)
+ return(0, 32)
+}
+```
+
+스마트 계약에 이미 매우 익숙하다면 Yul로 구현된 전체 ERC20을 [여기](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example)에서 찾을 수 있습니다.
+
+## Fe {#fe}
+
+- 이더리움 가상 머신(EVM)을 위한 정적 타입 언어입니다.
+- Python과 Rust에서 영감을 받았습니다.
+- 이더리움 생태계에 처음인 개발자도 쉽게 배울 수 있도록 설계되었습니다.
+- Fe 개발은 아직 초기 단계이며, 2021년 1월에 알파 버전이 출시되었습니다.
+
+### 중요 링크 {#important-links-3}
+
+- [GitHub](https://github.com/ethereum/fe)
+- [Fe 발표](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/)
+- [Fe 2021 로드맵](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg)
+- [Fe Discord 채팅](https://discord.com/invite/ywpkAXFjZH)
+- [Fe 트위터](https://twitter.com/official_fe)
+
+### 예제 계약 {#example-contract-3}
+
+다음은 Fe로 구현된 간단한 계약입니다.
+
+```
+type BookMsg = bytes[100]
+
+contract GuestBook:
+ pub guest_book: map
+
+ event Signed:
+ book_msg: BookMsg
+
+ pub def sign(book_msg: BookMsg):
+ self.guest_book[msg.sender] = book_msg
+
+ emit Signed(book_msg=book_msg)
+
+ pub def get_msg(addr: address) -> BookMsg:
+ return self.guest_book[addr].to_mem()
+
+```
+
+## 선택 방법 {#how-to-choose}
+
+다른 프로그래밍 언어와 마찬가지로 작업에 적합한 도구를 선택하는 것이 중요하며, 개인적인 선호도도 고려해야 합니다.
+
+솔리디티의 장점은 무엇인가요?
+
+### 초보자에게는 다양한 튜토리얼과 학습 도구가 있습니다. {#solidity-advantages}
+
+- 코딩으로 배우기 섹션에서 더 알아볼 수 있습니다. 자세한 내용은 [코딩으로 배우기](/developers/learning-tools/) 섹션을 참조하세요.
+- 좋은 개발자 툴링을 사용할 수 있습니다.
+- 솔리디티는 큰 개발자 커뮤니티가 있어 질문에 대한 답변을 쉽게 찾을 수 있습니다.
+
+### Vyper의 장점은 무엇인가요? {#vyper-advatages}
+
+- 스마트 계약을 작성하고자 하는 Python 개발자에게 훌륭한 출발점입니다.
+- 기능 수가 적어 아이디어를 빠르게 프로토타입하는 데 적합합니다.
+- Vyper는 감사하기 쉽고 가독성이 뛰어납니다.
+
+### Yul과 Yul+의 장점은 무엇인가요? {#yul-advantages}
+
+- 간단하고 기능적인 저수준 언어입니다.
+- 계약의 가스 사용량 최적화에 도움이 되는 원시 EVM에 더 가깝게 접근할 수 있습니다.
+
+## 언어 비교 {#language-comparisons}
+
+기본 구문, 계약 수명 주기, 인터페이스, 연산자, 데이터 구조, 함수, 제어 흐름 등을 비교하려면 Auditless의 [치트 시트](https://reference.auditless.com/cheatsheet/)를 확인하세요.
+
+## 더 읽어보기 {#further-reading}
+
+- [OpenZeppelin의 솔리디티 계약 라이브러리](https://docs.openzeppelin.com/contracts/5.x/)
+- [예제로 배우는 솔리디티](https://solidity-by-example.org)
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/libraries/index.md b/public/content/translations/ko/developers/docs/smart-contracts/libraries/index.md
new file mode 100644
index 00000000000..fb9c6f499c5
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/libraries/index.md
@@ -0,0 +1,117 @@
+---
+title: "스마트 계약 라이브러리"
+description: "재사용 가능한 스마트 계약 라이브러리 및 구성 요소를 찾아 이더리움 개발 프로젝트를 가속화하세요."
+lang: ko
+---
+
+프로젝트에서 모든 스마트 계약을 처음부터 작성할 필요가 없습니다. 프로젝트에 재사용 가능한 빌딩 블록을 제공하는 많은 오픈 소스 스마트 계약 라이브러리가 있어, 처음부터 모든 것을 다시 만들 필요 없이 시간을 절약할 수 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+스마트 계약 라이브러리에 뛰어들기 전에, 스마트 계약의 구조를 잘 이해하는 것이 좋습니다. 아직 확인하지 않았다면 [스마트 계약 구조](/developers/docs/smart-contracts/anatomy/)로 이동하세요.
+
+## 라이브러리 구성 {#whats-in-a-library}
+
+스마트 계약 라이브러리에서는 보통 두 가지 유형의 빌딩 블록을 찾을 수 있습니다: 계약에 추가할 수 있는 재사용 가능한 동작과 다양한 표준의 구현입니다.
+
+### 동작 {#behaviors}
+
+스마트 계약을 작성할 때, 계약에서 보호된 작업을 수행하기 위해 _admin_ 주소를 할당하거나 예기치 않은 문제가 발생했을 때 긴급 _pause_ 버튼을 추가하는 것처럼, 유사한 패턴을 여러 번 작성하게 될 가능성이 큽니다.
+
+스마트 계약 라이브러리는 일반적으로 솔리디티(Solidity)에서 [라이브러리](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) 또는 [상속](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance)을 통해 이러한 동작의 재사용 가능한 구현을 제공합니다.
+
+예를 들어, 다음은 [OpenZeppelin Contracts 라이브러리](https://github.com/OpenZeppelin/openzeppelin-contracts)의 [`Ownable` 계약](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol)의 간소화된 버전입니다. 이 계약은 주소를 계약의 소유자로 지정하고 해당 소유자에게만 메서드에 대한 접근을 제한하는 제어자를 제공합니다.
+
+```solidity
+contract Ownable {
+ address public owner;
+
+ constructor() internal {
+ owner = msg.sender;
+ }
+
+ modifier onlyOwner() {
+ require(owner == msg.sender, "Ownable: 호출자가 소유자가 아닙니다");
+ _;
+ }
+}
+```
+
+이러한 빌딩 블록을 계약에 사용하려면 먼저 이를 가져와 계약에서 확장해야 합니다. 이를 통해 기본 `Ownable` 계약에서 제공하는 제어자를 사용하여 자신의 함수를 보호할 수 있습니다.
+
+```solidity
+import ".../Ownable.sol"; // 가져온 라이브러리의 경로
+
+contract MyContract is Ownable {
+ // 다음 함수는 소유자만 호출할 수 있습니다
+ function secured() onlyOwner public {
+ msg.sender.transfer(1 ether);
+ }
+}
+```
+
+또 다른 인기 있는 예는 [SafeMath](https://docs.openzeppelin.com/contracts/3.x/utilities#math) 또는 [DsMath](https://dappsys.readthedocs.io/en/latest/ds_math.html)입니다. 이들은 언어에서 제공되지 않는 오버플로우 검사를 포함한 산술 기능을 제공하는 라이브러리입니다. 계약을 오버플로우로부터 보호하기 위해 기본 산술 연산 대신 이러한 라이브러리 중 하나를 사용하는 것이 좋은 관행입니다.
+
+### 표준 {#standards}
+
+[구성 가능성 및 상호 운용성](/developers/docs/smart-contracts/composability/)을 촉진하기 위해 이더리움 커뮤니티는 **ERC** 형식으로 여러 표준을 정의했습니다. 자세한 내용은 [표준](/developers/docs/standards/) 섹션에서 확인할 수 있습니다.
+
+계약의 일부로 ERC를 포함할 때는, 직접 구현하는 대신 표준 구현을 찾는 것이 좋습니다. 많은 스마트 계약 라이브러리에는 가장 인기 있는 ERC의 구현이 포함되어 있습니다. 예를 들어, 널리 사용되는 [ERC20 대체 가능 토큰 표준](/developers/tutorials/understand-the-erc-20-token-smart-contract/)은 [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md), [DappSys](https://github.com/dapphub/ds-token/), [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20)에서 찾아볼 수 있습니다. 또한, 일부 ERC는 ERC 자체의 일부로 표준 구현을 제공합니다.
+
+몇몇 ERC는 독립적인 것이 아니라 다른 ERC에 추가로 제공되는 경우도 있습니다. 예를 들어, [ERC2612](https://eips.ethereum.org/EIPS/eip-2612)는 ERC20의 사용성 개선을 위한 확장 기능을 추가합니다.
+
+## 라이브러리 추가 방법 {#how-to}
+
+프로젝트에 라이브러리를 포함하는 구체적인 방법에 대해서는 항상 라이브러리의 문서를 참조하세요. 일부 솔리디티(Solidity) 계약 라이브러리는 `npm`을 사용하여 패키지로 제공되므로 `npm install`을 사용하여 간단히 설치할 수 있습니다. 계약 [컴파일](/developers/docs/smart-contracts/compiling/)을 위한 대부분의 도구는 스마트 계약 라이브러리를 `node_modules`에서 찾으므로 다음과 같이 할 수 있습니다.
+
+```solidity
+// node_modules에서 @openzeppelin/contracts 라이브러리를 로드합니다
+import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
+
+contract MyNFT is ERC721 {
+ constructor() ERC721("MyNFT", "MNFT") public { }
+}
+```
+
+사용하는 방법에 관계없이 라이브러리를 포함할 때는 항상 [언어](/developers/docs/smart-contracts/languages/) 버전을 주시해야 합니다. 예를 들면 솔리디티 0.5에서 계약을 작성하고 있는 경우 솔리디티 0.6 라이브러리를 사용할 수 없습니다.
+
+## 사용 시점 {#when-to-use}
+
+프로젝트에서 스마트 계약 라이브러리를 사용하는 것은 여러 가지 장점이 있습니다. 첫째, 직접 코딩하지 않고도 시스템에 포함할 수 있는 즉시 사용 가능한 빌딩 블록을 제공하여 시간을 절약할 수 있습니다.
+
+보안도 중요한 장점입니다. 오픈 소스 스마트 계약 라이브러리는 많은 프로젝트가 이를 의존하므로, 커뮤니티에서 지속적인 검토가 이루어집니다. 응용 프로그램 코드에서 오류를 발견하는 것이 재사용 가능한 계약 라이브러리에서 오류를 발견하는 것보다 훨씬 더 흔합니다. 응용 프로그램 코드에서 오류를 발견하는 것이 재사용 가능한 계약 라이브러리에서 오류를 발견하는 것보다 훨씬 더 흔합니다. 일부 라이브러리는 보안 강화를 위해 [외부 감사](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits)를 받기도 합니다.
+
+그러나 스마트 계약 라이브러리를 사용할 때는 익숙하지 않은 코드를 프로젝트에 포함할 위험이 있습니다. 계약을 가져와 프로젝트에 바로 포함시키는 것은 유혹적이지만, 해당 계약이 무엇을 하는지 잘 모르면, 예상치 못한 동작으로 인해 시스템에 문제를 도입할 수 있습니다. 가져온 코드의 문서를 읽고, 코드를 검토한 후 프로젝트의 일부로 만들도록 하세요!
+
+마지막으로 라이브러리를 포함할지 여부를 결정할 때, 그 라이브러리의 전체적인 사용성을 고려하세요. 광범위하게 채택된 라이브러리는 커뮤니티가 더 크고 더 많은 사람들이 문제를 점검할 가능성이 있습니다. 스마트 계약을 사용하여 구축할 때 보안을 최우선으로 생각해야 합니다!
+
+## 관련 도구 {#related-tools}
+
+**OpenZeppelin Contracts -** **_안전한 스마트 계약 개발을 위한 가장 인기 있는 라이브러리_**
+
+- [문서](https://docs.openzeppelin.com/contracts/)
+- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts)
+- [커뮤니티 포럼](https://forum.openzeppelin.com/c/general/16)
+
+**DappSys -** **_안전하고 단순하며 유연한 스마트 계약용 구성 요소_**
+
+- [문서](https://dappsys.readthedocs.io/)
+- [GitHub](https://github.com/dapphub/dappsys)
+
+**HQ20 -** **_실제 환경에서 모든 기능을 갖춘 분산 애플리케이션을 구축하는 데 도움이 되는 계약, 라이브러리 및 예제가 포함된 솔리디티(Solidity) 프로젝트_**
+
+- [GitHub](https://github.com/HQ20/contracts)
+
+**thirdweb 솔리디티(Solidity) SDK -** **_맞춤형 스마트 계약을 효율적으로 구축하는 데 필요한 도구를 제공합니다_**
+
+- [문서](https://portal.thirdweb.com/contracts/build/overview)
+- [GitHub](https://github.com/thirdweb-dev/contracts)
+
+## 관련 튜토리얼 {#related-tutorials}
+
+- [이더리움 개발자를 위한 보안 고려사항](/developers/docs/smart-contracts/security/) _– 라이브러리 사용을 포함하여 스마트 계약을 구축할 때의 보안 고려사항에 대한 튜토리얼입니다._
+- [ERC-20 토큰 스마트 계약 이해하기](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _- 여러 라이브러리에서 제공하는 ERC20 표준에 대한 튜토리얼입니다._
+
+## 더 읽어보기 {#further-reading}
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/naming/index.md b/public/content/translations/ko/developers/docs/smart-contracts/naming/index.md
new file mode 100644
index 00000000000..13ee813accc
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/naming/index.md
@@ -0,0 +1,101 @@
+---
+title: "스마트 계약 이름 지정"
+description: "ENS로 이더리움 스마트 계약 이름을 지정하는 모범 사례"
+lang: ko
+---
+
+스마트 계약은 이더리움 탈중앙화 인프라의 핵심으로, 자율적인 애플리케이션과 프로토콜을 가능하게 합니다. 하지만 계약 기능이 발전함에도 불구하고 사용자와 개발자는 여전히 원시 16진수 주소에 의존하여 이러한 계약을 식별하고 참조합니다.
+
+[Ethereum Name Service(ENS)](https://ens.domains/)로 스마트 계약에 이름을 지정하면 16진수 계약 주소를 제거하여 사용자 경험을 개선하고 주소 포이즈닝 및 스푸핑 공격과 같은 공격의 위험을 줄일 수 있습니다. 이 가이드에서는 스마트 계약 이름 지정이 중요한 이유, 구현 방법, 그리고 [Enscribe](https://www.enscribe.xyz)와 같이 프로세스를 간소화하고 개발자가 이 관행을 채택하는 데 도움이 되는 도구에 대해 설명합니다.
+
+## 스마트 계약에 이름을 지정하는 이유는 무엇일까요? {#why-name-contracts}
+
+### 사람이 읽을 수 있는 식별자 {#human-readable-identifiers}
+
+개발자와 사용자는 `0x8f8e...f9e3`과 같이 불투명한 계약 주소와 상호작용하는 대신 `v2.myapp.eth`와 같이 사람이 읽을 수 있는 이름을 사용할 수 있습니다. 이는 스마트 계약 상호작용을 간소화합니다.
+
+이는 이더리움 주소에 대한 탈중앙화 이름 지정 서비스를 제공하는 [Ethereum Name Service](https://ens.domains/)를 통해 가능합니다. 이는 인터넷 사용자가 `104.18.176.152`와 같은 IP 주소 대신 ethereum.org와 같은 이름을 사용하여 네트워크 주소에 접속할 수 있도록 하는 도메인 이름 서비스(DNS)와 유사합니다.
+
+### 향상된 보안 및 신뢰 {#improved-security-and-trust}
+
+이름이 지정된 계약은 잘못된 주소로의 의도치 않은 거래를 줄이는 데 도움이 됩니다. 또한 사용자가 특정 앱 또는 브랜드와 연결된 계약을 식별하는 데 도움이 됩니다. 이는 특히 `uniswap.eth`와 같이 잘 알려진 상위 도메인에 이름이 연결된 경우 평판 신뢰도를 한층 더 높여줍니다.
+
+이더리움 주소는 42자 길이이므로 사용자가 몇 글자만 수정된 주소의 작은 변화를 식별하기가 매우 어렵습니다. 예를 들어, `0x58068646C148E313CB414E85d2Fe89dDc3426870`과 같은 주소는 일반적으로 지갑과 같은 사용자용 애플리케이션에서 `0x580...870`으로 잘립니다. 사용자는 몇 글자가 변경된 악의적인 주소를 알아차리기 어렵습니다.
+
+이러한 유형의 기술은 주소 스푸핑 및 포이즈닝 공격에 사용되며, 사용자는 올바른 주소와 상호작용하거나 자금을 보내고 있다고 믿게 되지만 실제로는 해당 주소가 올바른 주소와 유사할 뿐 동일하지는 않습니다.
+
+지갑과 계약에 대한 ENS 이름은 이러한 유형의 공격으로부터 보호합니다. DNS 스푸핑 공격과 마찬가지로 ENS 스푸핑 공격도 발생할 수 있지만, 사용자는 16진수 주소의 작은 수정보다 ENS 이름의 오타를 더 쉽게 알아차릴 수 있습니다.
+
+### 지갑 및 탐색기를 위한 더 나은 UX {#better-ux}
+
+스마트 계약이 ENS 이름으로 구성된 경우 지갑 및 블록체인 탐색기와 같은 앱에서 16진수 주소 대신 스마트 계약에 대한 ENS 이름을 표시할 수 있습니다. 이는 사용자에게 상당한 사용자 경험(UX) 향상을 제공합니다.
+
+예를 들어, Uniswap과 같은 앱과 상호작용할 때 사용자는 일반적으로 상호작용하는 앱이 `uniswap.org` 웹사이트에서 호스팅된다는 것을 알 수 있지만, Uniswap이 스마트 계약에 ENS 이름을 지정하지 않은 경우 16진수 계약 주소가 표시됩니다. 계약에 이름이 지정된 경우 대신 훨씬 더 유용한 `v4.contracts.uniswap.eth`를 볼 수 있습니다.
+
+## 배포 시점의 이름 지정 vs. 배포 후 이름 지정 {#when-to-name}
+
+스마트 계약에 이름을 지정할 수 있는 시점은 두 가지입니다.
+
+- **배포 시점**: 계약이 배포될 때 ENS 이름을 할당합니다.
+- **배포 후**: 기존 계약 주소를 새로운 ENS 이름에 매핑합니다.
+
+두 가지 접근 방식 모두 ENS 레코드를 생성하고 설정할 수 있도록 ENS 도메인에 대한 소유자 또는 관리자 액세스 권한이 있어야 합니다.
+
+## 계약에 대한 ENS 이름 지정 작동 방식 {#how-ens-naming-works}
+
+ENS 이름은 온체인에 저장되며 ENS 확인자를 통해 이더리움 주소로 확인됩니다. 스마트 계약에 이름을 지정하려면:
+
+1. 상위 ENS 도메인(예: `myapp.eth`)을 등록하거나 제어합니다.
+2. 하위 도메인(예: `v1.myapp.eth`)을 생성합니다.
+3. 하위 도메인의 `address` 레코드를 계약 주소로 설정합니다.
+4. 계약의 역방향 레코드를 ENS로 설정하여 주소를 통해 이름을 찾을 수 있도록 합니다.
+
+ENS 이름은 계층적이며 무제한의 하위 이름을 지원합니다. 이러한 레코드를 설정하려면 일반적으로 ENS 레지스트리 및 공용 확인자 계약과 상호작용해야 합니다.
+
+## 계약 이름 지정을 위한 도구 {#tools}
+
+스마트 계약에 이름을 지정하는 데는 두 가지 접근 방식이 있습니다. 몇 가지 수동 단계를 거쳐 [ENS 앱](https://app.ens.domains)을 사용하거나 [Enscribe](https://www.enscribe.xyz)를 사용하는 방법이 있습니다. 이에 대한 내용은 아래에 설명되어 있습니다.
+
+### 수동 ENS 설정 {#manual-ens-setup}
+
+[ENS 앱](https://app.ens.domains/)을 사용하여 개발자는 수동으로 하위 이름을 생성하고 정방향 주소 레코드를 설정할 수 있습니다. 그러나 ENS 앱을 통해 이름에 대한 역방향 레코드를 설정하여 스마트 계약의 기본 이름을 설정할 수는 없습니다. [ENS 문서](https://docs.ens.domains/web/naming-contracts/)에 설명된 수동 단계를 수행해야 합니다.
+
+### Enscribe {#enscribe}
+
+[Enscribe](https://www.enscribe.xyz)는 ENS를 사용하여 스마트 계약 이름 지정을 간소화하고 스마트 계약에 대한 사용자 신뢰를 향상시킵니다. 다음과 같은 기능을 제공합니다.
+
+- **원자적 배포 및 이름 지정**: 새 계약을 배포할 때 ENS 이름을 할당합니다.
+- **배포 후 이름 지정**: 이미 배포된 계약에 이름을 연결합니다.
+- **멀티체인 지원**: ENS가 지원되는 이더리움 및 L2 네트워크에서 작동합니다.
+- **계약 검증 데이터**: 여러 소스에서 가져온 계약 검증 데이터를 포함하여 사용자의 신뢰를 높입니다.
+
+Enscribe는 사용자가 제공한 ENS 이름 또는 사용자가 ENS 이름이 없는 경우 자체 도메인을 지원합니다.
+
+[Enscribe 앱](https://app.enscribe.xyz)에 접속하여 스마트 계약의 이름을 지정하고 볼 수 있습니다.
+
+## 모범 사례 {#best-practices}
+
+- **`v1.myapp.eth`와 같이 명확하고 버전이 지정된 이름 사용**: 계약 업그레이드를 투명하게 만듭니다.
+- **역방향 레코드 설정**: 계약을 ENS 이름에 연결하여 지갑 및 블록체인 탐색기와 같은 앱에서 가시성을 확보합니다.
+- **만료일 면밀히 모니터링**: 의도치 않은 소유권 변경을 방지하려면 만료일을 면밀히 모니터링하세요.
+- **계약 소스 확인**: 사용자가 이름이 지정된 계약이 예상대로 작동하는지 신뢰할 수 있도록 계약 소스를 확인하세요.
+
+## 위험 {#risks}
+
+스마트 계약의 이름을 지정하면 이더리움 사용자에게 상당한 이점을 제공하지만, ENS 도메인 소유자는 관리에 주의를 기울여야 합니다. 주요 위험은 다음과 같습니다.
+
+- **만료**: DNS 이름과 마찬가지로 ENS 이름 등록은 유한한 기간 동안만 유효합니다. 따라서 소유자는 도메인 만료일을 모니터링하고 만료일보다 훨씬 전에 갱신하는 것이 중요합니다. ENS 앱과 Enscribe 모두 만료가 다가올 때 도메인 소유자에게 시각적 표시기를 제공합니다.
+- **소유권 변경**: ENS 레코드는 이더리움에서 NFT로 표시되며, 특정 `.eth` 도메인의 소유자는 관련 NFT를 소유하게 됩니다. 따라서 다른 계정이 이 NFT의 소유권을 갖게 되면 새 소유자는 자신의 재량에 따라 모든 ENS 레코드를 수정할 수 있습니다.
+
+이러한 위험을 완화하려면 `.eth` 2단계 도메인(2LD)의 소유자 계정을 다중 서명 지갑을 통해 보호하고 하위 도메인을 생성하여 계약 이름 지정을 관리해야 합니다. 그렇게 하면 하위 도메인 수준에서 우발적이거나 악의적인 소유권 변경이 발생하더라도 2LD 소유자가 이를 무효화할 수 있습니다.
+
+## 계약 이름 지정의 미래 {#future}
+
+계약 이름 지정은 웹에서 도메인 이름이 IP 주소를 대체한 것과 유사하게 디앱 개발의 모범 사례가 되고 있습니다. 지갑, 탐색기, 대시보드와 같은 더 많은 인프라가 계약에 대한 ENS 확인 기능을 통합함에 따라, 이름이 지정된 계약은 생태계 전반의 안전성을 개선하고 오류를 줄일 것입니다.
+
+스마트 계약을 더 쉽게 인식하고 추론할 수 있도록 함으로써, 이름 지정은 이더리움의 사용자와 앱 간의 간극을 메워 사용자의 안전과 UX를 모두 향상시키는 데 도움이 됩니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [ENS로 스마트 계약 이름 지정하기](https://docs.ens.domains/web/naming-contracts/)
+- [Enscribe로 스마트 계약 이름 지정하기](https://www.enscribe.xyz/docs).
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/security/index.md b/public/content/translations/ko/developers/docs/smart-contracts/security/index.md
new file mode 100644
index 00000000000..37d20b5346a
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/security/index.md
@@ -0,0 +1,573 @@
+---
+title: "스마트 콘트랙트 감사"
+description: "안전한 이더리움 스마트 계약을 구축하기 위한 가이드라인 개요"
+lang: ko
+---
+
+스마트 계약은 블록체인에 배포된 코드를 기반으로 변경 불가능한 로직을 실행하면서, 매우 유연하고 막대한 가치와 데이터를 제어할 수 있습니다. 이로 인해 기존 시스템보다 많은 이점을 제공하는 무신뢰 및 탈중앙화 애플리케이션의 활발한 생태계가 조성되었습니다. 또한 스마트 계약의 취약점을 악용하여 이익을 얻으려는 공격자에게는 기회가 되기도 합니다.
+
+이더리움과 같은 퍼블릭 블록체인은 스마트 계약 보안 문제를 더욱 복잡하게 만듭니다. 배포된 계약 코드는 _보통_ 보안 결함을 패치하기 위해 변경될 수 없으며, 스마트 계약에서 도난당한 자산은 불변성 때문에 추적이 매우 어렵고 대부분 복구할 수 없습니다.
+
+수치는 다양하지만, 스마트 계약의 보안 결함으로 인해 도난당하거나 손실된 총 가치는 10억 달러를 훌쩍 넘는 것으로 추정됩니다. 여기에는 [DAO 해킹](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/)(360만 ETH 도난, 현재 시가로 10억 달러 이상), [Parity 다중 서명 지갑 해킹](https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach)(해커에게 3,000만 달러 손실), [Parity 지갑 동결 문제](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether)(3억 달러 이상의 ETH가 영구적으로 동결) 등 세간의 이목을 끈 사건들이 포함됩니다.
+
+앞서 언급한 문제들로 인해 개발자들은 안전하고, 견고하며, 복원력 있는 스마트 계약을 구축하는 데 노력을 기울여야 합니다. 스마트 계약 보안은 중요한 문제이며, 모든 개발자가 잘 배워두면 좋은 것입니다. 이 가이드에서는 이더리움 개발자를 위한 보안 고려 사항을 다루고 스마트 계약 보안을 개선하기 위한 참고 자료를 알아봅니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+보안 문제를 다루기 전에 [스마트 계약 개발의 기초](/developers/docs/smart-contracts/)에 익숙해지도록 하세요.
+
+## 안전한 이더리움 스마트 계약을 구축하기 위한 가이드라인 {#smart-contract-security-guidelines}
+
+### 1. 적절한 접근 제어 설계 {#design-proper-access-controls}
+
+스마트 계약에서 `public` 또는 `external`로 표시된 함수는 모든 외부 소유 계정(EOA) 또는 계약 계정에서 호출할 수 있습니다. 다른 사람이 사용자의 계약과 상호 작용하기를 원한다면 함수에 공용 가시성을 지정해야 합니다. 그러나 `private`로 표시된 함수는 스마트 계약 내의 함수에서만 호출할 수 있으며 외부 계정에서는 호출할 수 없습니다. 모든 네트워크 참여자에게 계약 함수에 대한 접근 권한을 부여하면 문제가 발생할 수 있으며, 특히 누구나 민감한 작업(예: 새로운 토큰 발행)을 수행할 수 있다는 것을 의미하는 경우 더욱 그렇습니다.
+
+스마트 계약 함수의 무단 사용을 방지하려면 안전한 접근 제어를 구현해야 합니다. 접근 제어 메커니즘은 스마트 계약에서 특정 함수를 사용할 수 있는 권한을 계약 관리를 책임지는 계정과 같이 승인된 주체로 제한합니다. **소유 가능 패턴**과 **역할 기반 제어**는 스마트 계약에서 접근 제어를 구현하는 데 유용한 두 가지 패턴입니다.
+
+#### 소유 가능 패턴 {#ownable-pattern}
+
+소유 가능 패턴에서는 계약 생성 과정에서 주소가 계약의 '소유자'로 설정됩니다. 보호된 함수에는 `OnlyOwner` 수정자가 할당되어 계약이 함수를 실행하기 전에 호출 주소의 신원을 인증하도록 합니다. 계약 소유자가 아닌 다른 주소에서 보호된 함수를 호출하면 항상 되돌려지므로 원치 않는 접근을 방지할 수 있습니다.
+
+#### 역할 기반 접근 제어 {#role-based-access-control}
+
+스마트 계약에서 단일 주소를 `Owner`로 등록하면 중앙화의 위험이 발생하고 단일 실패 지점이 됩니다. 소유자의 계정 키가 손상되면 공격자가 소유 계약을 공격할 수 있습니다. 이것이 여러 관리 계정이 있는 역할 기반 접근 제어 패턴을 사용하는 것이 더 나은 선택일 수 있는 이유입니다.
+
+역할 기반 접근 제어에서 민감한 기능에 대한 접근은 신뢰할 수 있는 참여자 집합 간에 분산됩니다. 예를 들어, 한 계정은 토큰 발행을 담당하고 다른 계정은 계약을 업그레이드하거나 일시 중지하는 작업을 수행할 수 있습니다. 이러한 방식으로 접근 제어를 분산하면 단일 실패 지점을 제거하고 사용자에 대한 신뢰 가정을 줄일 수 있습니다.
+
+##### 다중 서명 지갑 사용
+
+안전한 접근 제어를 구현하는 또 다른 방법은 [다중 서명 계정](/developers/docs/smart-contracts/#multisig)을 사용하여 계약을 관리하는 것입니다. 일반 EOA와 달리 다중 서명 계정은 여러 엔티티가 소유하며 트랜잭션을 실행하려면 최소 계정 수(예: 5개 중 3개)의 서명이 필요합니다.
+
+접근 제어에 다중 서명을 사용하면 대상 계약에 대한 조치에 여러 당사자의 동의가 필요하므로 보안 계층이 추가됩니다. 이는 공격자나 불량 내부자가 악의적인 목적으로 민감한 계약 기능을 조작하기 어렵게 만들기 때문에 소유 가능 패턴을 사용하는 것이 필요한 경우 특히 유용합니다.
+
+### 2. require(), assert() 및 revert() 문을 사용하여 계약 작업을 보호하세요 {#use-require-assert-revert}
+
+언급했듯이 스마트 계약이 블록체인에 배포되면 누구나 스마트 계약의 공용 함수를 호출할 수 있습니다. 외부 계정이 계약과 어떻게 상호 작용할지 미리 알 수 없으므로 배포하기 전에 문제가 있는 작업에 대한 내부 보호 장치를 구현하는 것이 이상적입니다. 실행이 특정 요구 사항을 충족하지 못하는 경우 예외를 트리거하고 상태 변경을 되돌리기 위해 `require()`, `assert()` 및 `revert()` 문을 사용하여 스마트 계약에서 올바른 동작을 적용할 수 있습니다.
+
+**`require()`**: `require`는 함수 시작 부분에 정의되며 호출된 함수가 실행되기 전에 미리 정의된 조건이 충족되도록 합니다. `require` 문은 함수를 진행하기 전에 사용자 입력을 검증하거나, 상태 변수를 확인하거나, 호출 계정의 신원을 인증하는 데 사용할 수 있습니다.
+
+**`assert()`**: `assert()`는 내부 오류를 감지하고 코드의 '불변' 위반을 확인하는 데 사용됩니다. 불변은 모든 함수 실행에 대해 사실이어야 하는 계약의 상태에 대한 논리적 주장입니다. 불변의 예는 토큰 계약의 최대 총 공급량 또는 잔액입니다. `assert()`를 사용하면 계약이 취약한 상태에 도달하지 않도록 하고, 만약 그렇게 되면 상태 변수에 대한 모든 변경 사항이 롤백됩니다.
+
+**`revert()`**: `revert()`는 필요한 조건이 충족되지 않으면 예외를 트리거하는 if-else 문에서 사용할 수 있습니다. 아래 샘플 계약은 `revert()`를 사용하여 함수 실행을 보호합니다.
+
+```
+pragma solidity ^0.8.4;
+
+contract VendingMachine {
+ address owner;
+ error Unauthorized();
+ function buy(uint amount) public payable {
+ if (amount > msg.value / 2 ether)
+ revert("제공된 이더가 충분하지 않습니다.");
+ // 구매를 수행합니다.
+ }
+ function withdraw() public {
+ if (msg.sender != owner)
+ revert Unauthorized();
+
+ payable(msg.sender).transfer(address(this).balance);
+ }
+}
+```
+
+### 3. 스마트 계약 테스트 및 코드 정확성 확인 {#test-smart-contracts-and-verify-code-correctness}
+
+[이더리움 가상 머신](/developers/docs/evm/)에서 실행되는 코드의 불변성은 스마트 계약이 개발 단계에서 더 높은 수준의 품질 평가를 요구함을 의미합니다. 계약을 광범위하게 테스트하고 예기치 않은 결과가 있는지 관찰하면 보안이 크게 향상되고 장기적으로 사용자를 보호할 수 있습니다.
+
+일반적인 방법은 계약이 사용자로부터 받을 것으로 예상되는 모의 데이터를 사용하여 작은 단위 테스트를 작성하는 것입니다. [단위 테스트](/developers/docs/smart-contracts/testing/#unit-testing)는 특정 기능의 기능을 테스트하고 스마트 계약이 예상대로 작동하는지 확인하는 데 좋습니다.
+
+불행히도 단위 테스트는 단독으로 사용될 때 스마트 계약 보안을 향상시키는 데 최소한의 효과만 있습니다. 단위 테스트는 모의 데이터에 대해 함수가 제대로 실행됨을 증명할 수 있지만, 단위 테스트는 작성된 테스트만큼만 효과적입니다. 이로 인해 스마트 계약의 안전을 위협할 수 있는 누락된 엣지 케이스와 취약점을 감지하기가 어렵습니다.
+
+더 나은 접근 방식은 [정적 및 동적 분석](/developers/docs/smart-contracts/testing/#static-dynamic-analysis)을 사용하여 수행되는 속성 기반 테스트와 단위 테스트를 결합하는 것입니다. 정적 분석은 [제어 흐름 그래프](https://en.wikipedia.org/wiki/Control-flow_graph) 및 [추상 구문 트리](https://deepsource.io/glossary/ast/)와 같은 저수준 표현에 의존하여 도달 가능한 프로그램 상태 및 실행 경로를 분석합니다. 한편, [스마트 계약 퍼징](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry)과 같은 동적 분석 기술은 임의의 입력 값으로 계약 코드를 실행하여 보안 속성을 위반하는 작업을 감지합니다.
+
+[공식 검증](/developers/docs/smart-contracts/formal-verification)은 스마트 계약의 보안 속성을 검증하는 또 다른 기술입니다. 일반 테스트와 달리 공식 검증은 스마트 계약에 오류가 없음을 결정적으로 증명할 수 있습니다. 이는 원하는 보안 속성을 캡처하는 공식 사양을 만들고 계약의 공식 모델이 이 사양을 준수함을 증명함으로써 달성됩니다.
+
+### 4. 코드에 대한 독립적인 검토를 요청하세요 {#get-independent-code-reviews}
+
+계약을 테스트한 후 다른 사람들에게 소스 코드에 보안 문제가 있는지 확인하도록 요청하는 것이 좋습니다. 테스트를 통해 스마트 계약의 모든 결함을 발견할 수는 없지만 독립적인 검토를 받으면 취약점을 발견할 가능성이 높아집니다.
+
+#### 감사 {#audits}
+
+스마트 계약 감사를 의뢰하는 것은 독립적인 코드 검토를 수행하는 한 가지 방법입니다. 감사자는 스마트 계약이 안전하고 품질 결함 및 설계 오류가 없는지 확인하는 데 중요한 역할을 합니다.
+
+그렇다고 감사를 만병통치약으로 취급해서는 안 됩니다. 스마트 계약 감사는 모든 버그를 잡지 못하며 대부분 추가 검토를 제공하도록 설계되어 개발자가 초기 개발 및 테스트 중에 놓친 문제를 감지하는 데 도움이 될 수 있습니다. 또한 스마트 계약 감사의 이점을 극대화하려면 코드를 적절하게 문서화하고 인라인 주석을 추가하는 등 감사자와 작업하기 위한 모범 사례를 따라야 합니다.
+
+- [스마트 계약 감사 팁 및 요령](https://twitter.com/tinchoabbate/status/1400170232904400897) - _@tinchoabbate_
+- [감사를 최대한 활용하기](https://inference.ag/blog/2023-08-14-tips/) - _Inference_
+
+#### 버그 포상금 {#bug-bounties}
+
+버그 포상금 프로그램을 설정하는 것은 외부 코드 검토를 구현하는 또 다른 접근 방식입니다. 버그 포상금은 애플리케이션에서 취약점을 발견한 개인(보통 화이트햇 해커)에게 주어지는 금전적 보상입니다.
+
+적절하게 사용하면 버그 포상금은 해커 커뮤니티 구성원에게 코드에 중요한 결함이 있는지 검사하도록 인센티브를 제공합니다. 실제 예는 이더리움에서 실행되는 [레이어 2](/layer-2/) 프로토콜인 [Optimism](https://www.optimism.io/)에서 공격자가 무제한의 이더를 생성할 수 있었던 '무한 돈 버그'입니다. 다행히 화이트햇 해커가 [결함을 발견하고](https://www.saurik.com/optimism.html) 팀에 통보하여 [그 과정에서 큰 포상금을 받았습니다](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/).
+
+유용한 전략은 이해 관계가 있는 자금의 양에 비례하여 버그 포상금 프로그램의 지불금을 설정하는 것입니다. “[스케일링 버그 포상금](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)”으로 설명되는 이 접근 방식은 개인이 취약점을 악용하는 대신 책임감 있게 공개하도록 재정적 인센티브를 제공합니다.
+
+### 5. 스마트 계약 개발 중 모범 사례 따르기 {#follow-smart-contract-development-best-practices}
+
+감사 및 버그 포상금의 존재가 고품질 코드를 작성해야 할 책임을 면제해주지는 않습니다. 우수한 스마트 계약 보안은 적절한 설계 및 개발 프로세스를 따르는 것에서 시작됩니다.
+
+- git과 같은 버전 제어 시스템에 모든 코드를 저장
+
+- 풀 리퀘스트를 통해 모든 코드 수정하기
+
+- 풀 리퀘스트에 최소 한 명의 독립적인 검토자가 있는지 확인하세요. 프로젝트에서 단독으로 작업하는 경우 다른 개발자를 찾아 코드 검토를 교환하는 것을 고려하세요.
+
+- 스마트 계약 테스트, 컴파일, 배포를 위해 [개발 환경](/developers/docs/frameworks/)을 사용하세요.
+
+- 코드를 [Cyfrin Aderyn](https://github.com/Cyfrin/aderyn), Mythril 및 Slither와 같은 기본 코드 분석 도구로 실행하세요. 이상적으로는 각 풀 리퀘스트가 병합되기 전에 이 작업을 수행하고 출력의 차이점을 비교해야 합니다.
+
+- 코드가 오류 없이 컴파일되고 솔리디티 컴파일러가 경고를 내보내지 않도록 확인하세요.
+
+- 코드를 ([NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html)을 사용하여) 적절히 문서화하고 계약 아키텍처에 대한 세부 정보를 이해하기 쉬운 언어로 설명하세요. 이렇게 하면 다른 사람들이 코드를 감사하고 검토하기가 더 쉬워집니다.
+
+### 6. 견고한 재해 복구 계획 구현 {#implement-disaster-recovery-plans}
+
+안전한 접근 제어 설계, 기능 수정자 구현 및 기타 제안은 스마트 계약 보안을 향상시킬 수 있지만 악의적인 공격의 가능성을 배제할 수는 없습니다. 안전한 스마트 계약을 구축하려면 '실패에 대비'하고 공격에 효과적으로 대응하기 위한 대체 계획을 마련해야 합니다. 적절한 재해 복구 계획에는 다음 구성 요소의 일부 또는 전부가 포함됩니다.
+
+#### 계약 업그레이드 {#contract-upgrades}
+
+이더리움 스마트 계약은 기본적으로 불변이지만 업그레이드 패턴을 사용하여 어느 정도의 가변성을 달성할 수 있습니다. 계약 업그레이드는 중요한 결함으로 인해 기존 계약을 사용할 수 없게 되고 새로운 로직을 배포하는 것이 가장 실현 가능한 옵션인 경우에 필요합니다.
+
+계약 업그레이드 메커니즘은 다르게 작동하지만 '프록시 패턴'은 스마트 계약 업그레이드를 위한 더 인기 있는 접근 방식 중 하나입니다. [프록시 패턴](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern)은 애플리케이션의 상태와 로직을 _두_ 계약으로 나눕니다. 첫 번째 계약('프록시 계약')은 상태 변수(예: 사용자 잔액)를 저장하고, 두 번째 계약('로직 계약')은 계약 기능을 실행하기 위한 코드를 보유합니다.
+
+계정은 프록시 계약과 상호 작용하며, 프록시 계약은 [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries) 저수준 호출을 사용하여 모든 함수 호출을 로직 계약으로 보냅니다. 일반 메시지 호출과 달리 `delegatecall()`은 로직 계약의 주소에서 실행되는 코드가 호출 계약의 컨텍스트에서 실행되도록 보장합니다. 이는 로직 계약이 항상 자신의 저장 공간 대신 프록시의 저장 공간에 쓰고 `msg.sender` 및 `msg.value`의 원래 값이 보존됨을 의미합니다.
+
+로직 계약에 대한 호출을 위임하려면 해당 주소를 프록시 계약의 저장 공간에 저장해야 합니다. 따라서 계약의 로직을 업그레이드하는 것은 다른 로직 계약을 배포하고 새 주소를 프록시 계약에 저장하는 문제일 뿐입니다. 프록시 계약에 대한 후속 호출은 자동으로 새 로직 계약으로 라우팅되므로 실제로 코드를 수정하지 않고도 계약을 '업그레이드'하게 됩니다.
+
+[계약 업그레이드에 대해 더 알아보기](/developers/docs/smart-contracts/upgrading/).
+
+#### 긴급 중지 {#emergency-stops}
+
+언급했듯이 광범위한 감사 및 테스트로 스마트 계약의 모든 버그를 발견할 수는 없습니다. 배포 후 코드에 취약점이 나타나면 계약 주소에서 실행되는 코드를 변경할 수 없으므로 패치하는 것이 불가능합니다. 또한 업그레이드 메커니즘(예: 프록시 패턴)은 구현하는 데 시간이 걸릴 수 있으며(종종 다른 당사자의 승인이 필요함), 이는 공격자에게 더 많은 피해를 입힐 시간을 줄 뿐입니다.
+
+핵심 옵션은 계약의 취약한 기능에 대한 호출을 차단하는 '긴급 중지' 기능을 구현하는 것입니다. 긴급 중지는 일반적으로 다음 구성 요소로 구성됩니다.
+
+1. 스마트 계약이 중지된 상태인지 여부를 나타내는 전역 부울 변수입니다. 이 변수는 계약 설정 시 `false`로 설정되지만 계약이 중지되면 `true`로 되돌아갑니다.
+
+2. 실행 시 부울 변수를 참조하는 함수. 이러한 함수는 스마트 계약이 중지되지 않았을 때 접근할 수 있으며, 긴급 중지 기능이 트리거되면 접근할 수 없게 됩니다.
+
+3. 부울 변수를 `true`로 설정하는 긴급 중지 기능에 접근할 수 있는 엔티티입니다. 악의적인 행위를 방지하기 위해 이 함수에 대한 호출은 신뢰할 수 있는 주소(예: 계약 소유자)로 제한될 수 있습니다.
+
+계약이 긴급 중지를 활성화하면 특정 함수를 호출할 수 없게 됩니다. 이는 전역 변수를 참조하는 수정자로 선택 함수를 래핑하여 달성됩니다. 아래는 계약에서 이 패턴의 구현을 설명하는 [예제](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol)입니다.
+
+```solidity
+// 이 코드는 전문적인 감사를 받지 않았으며 안전성이나 정확성에 대해 어떠한 약속도 하지 않습니다. 자신의 책임 하에 사용하세요.
+
+contract EmergencyStop {
+
+ bool isStopped = false;
+
+ modifier stoppedInEmergency {
+ require(!isStopped);
+ _;
+ }
+
+ modifier onlyWhenStopped {
+ require(isStopped);
+ _;
+ }
+
+ modifier onlyAuthorized {
+ // 여기에서 msg.sender의 권한을 확인하세요
+ _;
+ }
+
+ function stopContract() public onlyAuthorized {
+ isStopped = true;
+ }
+
+ function resumeContract() public onlyAuthorized {
+ isStopped = false;
+ }
+
+ function deposit() public payable stoppedInEmergency {
+ // 입금 로직이 여기서 발생합니다
+ }
+
+ function emergencyWithdraw() public onlyWhenStopped {
+ // 긴급 인출이 여기서 발생합니다
+ }
+}
+```
+
+이 예제는 긴급 중지의 기본 기능을 보여줍니다.
+
+- `isStopped`는 처음에 `false`로 평가되고 계약이 긴급 모드로 들어가면 `true`로 평가되는 부울입니다.
+
+- 함수 수정자 `onlyWhenStopped`와 `stoppedInEmergency`는 `isStopped` 변수를 확인합니다. `stoppedInEmergency`는 계약이 취약할 때 접근할 수 없어야 하는 함수(예: `deposit()`)를 제어하는 데 사용됩니다. 이러한 함수에 대한 호출은 단순히 되돌려집니다.
+
+`onlyWhenStopped`는 긴급 상황 시 호출 가능해야 하는 함수(예: `emergencyWithdraw()`)에 사용됩니다. 이러한 함수는 상황 해결에 도움이 될 수 있으므로 '제한된 함수' 목록에서 제외됩니다.
+
+긴급 중지 기능을 사용하면 스마트 계약의 심각한 취약점을 처리하기 위한 효과적인 임시 방편을 제공합니다. 그러나 사용자가 개발자가 이기적인 이유로 이를 활성화하지 않을 것이라고 신뢰해야 할 필요성이 증가합니다. 이를 위해 온체인 투표 메커니즘, 타임락 또는 다중 서명 지갑의 승인을 통해 긴급 중지 제어를 분산하는 것이 가능한 해결책입니다.
+
+#### 이벤트 모니터링 {#event-monitoring}
+
+[이벤트](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events)를 사용하면 스마트 계약 함수에 대한 호출을 추적하고 상태 변수의 변경 사항을 모니터링할 수 있습니다. 어떤 당사자가 안전에 중요한 조치(예: 자금 인출)를 취할 때마다 이벤트를 발생시키도록 스마트 계약을 프로그래밍하는 것이 이상적입니다.
+
+이벤트를 로깅하고 오프체인에서 모니터링하면 계약 운영에 대한 통찰력을 제공하고 악의적인 행동을 더 빨리 발견하는 데 도움이 됩니다. 이는 팀이 해킹에 더 빨리 대응하고 기능 일시 중지 또는 업그레이드 수행과 같은 사용자에게 미치는 영향을 완화하기 위한 조치를 취할 수 있음을 의미합니다.
+
+누군가 계약과 상호 작용할 때마다 자동으로 알림을 전달하는 기성 모니터링 도구를 선택할 수도 있습니다. 이러한 도구를 사용하면 트랜잭션 양, 함수 호출 빈도 또는 관련된 특정 함수와 같은 다양한 트리거를 기반으로 사용자 지정 알림을 만들 수 있습니다. 예를 들어, 단일 트랜잭션에서 인출된 금액이 특정 임계값을 초과할 때 들어오는 알림을 프로그래밍할 수 있습니다.
+
+### 7. 안전한 거버넌스 시스템 설계 {#design-secure-governance-systems}
+
+핵심 스마트 계약의 통제권을 커뮤니티 구성원에게 넘겨 애플리케이션을 분산화할 수 있습니다. 이 경우 스마트 계약 시스템에는 거버넌스 모듈, 즉 커뮤니티 구성원이 온체인 거버넌스 시스템을 통해 관리 조치를 승인할 수 있는 메커니즘이 포함됩니다. 예를 들어, 프록시 계약을 새 구현으로 업그레이드하자는 제안은 토큰 보유자들의 투표에 부쳐질 수 있습니다.
+
+분산형 거버넌스는 특히 개발자와 최종 사용자의 이익을 일치시키기 때문에 유익할 수 있습니다. 그럼에도 불구하고 스마트 계약 거버넌스 메커니즘은 잘못 구현될 경우 새로운 위험을 초래할 수 있습니다. 있을 법한 시나리오는 공격자가 [플래시 론](/defi/#flash-loans)을 이용하여 엄청난 투표권(보유 토큰 수로 측정)을 획득하고 악의적인 제안을 통과시키는 경우입니다.
+
+온체인 거버넌스와 관련된 문제를 예방하는 한 가지 방법은 [타임락을 사용하는 것](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/)입니다. 타임락은 스마트 계약이 특정 시간이 지날 때까지 특정 작업을 실행하지 못하도록 합니다. 다른 전략으로는 각 토큰이 잠겨 있던 기간에 따라 '투표 가중치'를 할당하거나, 현재 블록이 아닌 과거의 특정 기간(예: 2-3 블록 전)에 주소의 투표권을 측정하는 것이 있습니다. 두 방법 모두 온체인 투표를 흔들기 위해 투표권을 빠르게 축적할 가능성을 줄여줍니다.
+
+공유된 링크에서 [안전한 거버넌스 시스템 설계](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/), [DAO의 다양한 투표 메커니즘](https://hackernoon.com/governance-is-the-holy-grail-for-daos) 및 [DeFi를 활용한 일반적인 DAO 공격 벡터](https://dacian.me/dao-governance-defi-attacks)에 대해 더 자세히 알아보세요.
+
+### 8. 코드의 복잡성을 최소화하세요 {#reduce-code-complexity}
+
+기존 소프트웨어 개발자들은 소프트웨어 설계에 불필요한 복잡성을 도입하지 말 것을 권고하는 KISS('keep it simple, stupid') 원칙에 익숙합니다. 이는 '복잡한 시스템은 복잡한 방식으로 실패한다'는 오랜 생각에 따른 것으로, 비용이 많이 드는 오류에 더 취약합니다.
+
+스마트 계약은 잠재적으로 막대한 가치를 제어하므로 스마트 계약을 작성할 때 단순함을 유지하는 것이 특히 중요합니다. 스마트 계약을 작성할 때 단순성을 달성하기 위한 팁은 가능한 경우 [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)와 같은 기존 라이브러리를 재사용하는 것입니다. 이러한 라이브러리는 개발자들에 의해 광범위하게 감사되고 테스트되었기 때문에, 이를 사용하면 처음부터 새로운 기능을 작성함으로써 버그를 도입할 가능성을 줄일 수 있습니다.
+
+또 다른 일반적인 조언은 작은 함수를 작성하고 비즈니스 로직을 여러 계약에 분산하여 계약을 모듈식으로 유지하는 것입니다. 더 간단한 코드를 작성하면 스마트 계약의 공격 표면을 줄일 수 있을 뿐만 아니라 전체 시스템의 정확성을 추론하고 가능한 설계 오류를 조기에 감지하기가 더 쉬워집니다.
+
+### 9. 일반적인 스마트 계약 취약점 방어 {#mitigate-common-smart-contract-vulnerabilities}
+
+#### 재진입 {#reentrancy}
+
+EVM은 동시성을 허용하지 않으므로 메시지 호출에 관련된 두 계약이 동시에 실행될 수 없습니다. 외부 호출은 호출이 반환될 때까지 호출 계약의 실행과 메모리를 일시 중지하며, 그 시점에서 실행은 정상적으로 진행됩니다. 이 과정은 다른 계약으로 [제어 흐름](https://www.computerhope.com/jargon/c/contflow.htm)을 이전하는 것으로 공식적으로 설명될 수 있습니다.
+
+대부분 무해하지만 신뢰할 수 없는 계약으로 제어 흐름을 이전하면 재진입과 같은 문제가 발생할 수 있습니다. 재진입 공격은 악성 계약이 원래 함수 호출이 완료되기 전에 취약한 계약으로 다시 호출할 때 발생합니다. 이 유형의 공격은 예시를 통해 가장 잘 설명됩니다.
+
+누구나 이더를 입금하고 인출할 수 있는 간단한 스마트 계약('Victim')을 고려해 보세요.
+
+```solidity
+// 이 계약은 취약합니다. 프로덕션에서 사용하지 마세요
+
+contract Victim {
+ mapping (address => uint256) public balances;
+
+ function deposit() external payable {
+ balances[msg.sender] += msg.value;
+ }
+
+ function withdraw() external {
+ uint256 amount = balances[msg.sender];
+ (bool success, ) = msg.sender.call.value(amount)("");
+ require(success);
+ balances[msg.sender] = 0;
+ }
+}
+```
+
+이 계약은 사용자가 이전에 계약에 입금한 ETH를 인출할 수 있도록 `withdraw()` 함수를 노출합니다. 인출을 처리할 때 계약은 다음 작업을 수행합니다.
+
+1. 사용자의 ETH 잔액 확인
+2. 호출 주소로 자금 전송
+3. 사용자의 추가 인출을 방지하기 위해 잔액을 0으로 재설정
+
+`Victim` 계약의 `withdraw()` 함수는 '확인-상호작용-효과' 패턴을 따릅니다. 실행에 필요한 조건이 충족되었는지 _확인_(즉, 사용자가 양의 ETH 잔액을 가지고 있는지)하고, 트랜잭션의 _효과_(즉, 사용자 잔액 감소)를 적용하기 전에 호출자의 주소로 ETH를 전송하여 _상호작용_을 수행합니다.
+
+`withdraw()`가 외부 소유 계정(EOA)에서 호출되면 함수는 예상대로 실행됩니다. `msg.sender.call.value()`는 호출자에게 ETH를 보냅니다. 그러나 `msg.sender`가 스마트 계약 계정이고 `withdraw()`를 호출하면, `msg.sender.call.value()`를 사용하여 자금을 보내는 것은 해당 주소에 저장된 코드를 실행하게 합니다.
+
+이것이 계약 주소에 배포된 코드라고 상상해보세요.
+
+```solidity
+ contract Attacker {
+ function beginAttack() external payable {
+ Victim(victim_address).deposit.value(1 ether)();
+ Victim(victim_address).withdraw();
+ }
+
+ function() external payable {
+ if (gasleft() > 40000) {
+ Victim(victim_address).withdraw();
+ }
+ }
+}
+```
+
+이 계약은 세 가지를 하도록 설계되었습니다.
+
+1. 다른 계정(공격자의 EOA일 가능성 있음)으로부터 입금 받기
+2. Victim 계약에 1 ETH 입금하기
+3. 스마트 계약에 저장된 1 ETH 인출하기
+
+여기에는 아무런 문제가 없지만, `Attacker`는 들어오는 `msg.sender.call.value`에서 남은 가스가 40,000 이상이면 `Victim`에서 `withdraw()`를 다시 호출하는 또 다른 함수를 가지고 있습니다. 이는 `Attacker`가 `Victim`에 재진입하여 첫 번째 `withdraw` 호출이 완료되기 _전에_ 더 많은 자금을 인출할 수 있는 능력을 부여합니다. 주기는 다음과 같습니다.
+
+```solidity
+- 공격자의 EOA가 1 ETH로 `Attacker.beginAttack()`을 호출합니다
+- `Attacker.beginAttack()`이 `Victim`에 1 ETH를 입금합니다
+- `Attacker`가 `Victim`에서 `withdraw()`를 호출합니다
+- `Victim`이 `Attacker`의 잔액(1 ETH)을 확인합니다
+- `Victim`이 `Attacker`에게 1 ETH를 전송합니다(기본 함수를 트리거함)
+- `Attacker`가 `Victim.withdraw()`를 다시 호출합니다(`Victim`은 첫 번째 인출에서 `Attacker`의 잔액을 줄이지 않았음에 유의)
+- `Victim`이 `Attacker`의 잔액을 확인합니다(첫 번째 호출의 효과를 적용하지 않았기 때문에 여전히 1 ETH임)
+- `Victim`이 `Attacker`에게 1 ETH를 전송합니다(기본 함수를 트리거하고 `Attacker`가 `withdraw` 함수에 재진입할 수 있게 함)
+- `Attacker`가 가스를 모두 소진할 때까지 프로세스가 반복되며, 그 시점에서 `msg.sender.call.value`는 추가 인출을 트리거하지 않고 반환됩니다
+- `Victim`은 마침내 첫 번째 트랜잭션(및 후속 트랜잭션)의 결과를 상태에 적용하므로 `Attacker`의 잔액은 0으로 설정됩니다
+```
+
+요약하자면, 함수 실행이 완료될 때까지 호출자의 잔액이 0으로 설정되지 않기 때문에 후속 호출이 성공하여 호출자가 잔액을 여러 번 인출할 수 있게 됩니다. [2016년 DAO 해킹](https://www.coindesk.com/learn/understanding-the-dao-attack)에서 일어난 것처럼, 이러한 종류의 공격은 스마트 계약의 자금을 고갈시키는 데 사용될 수 있습니다. [재진입 공격의 공개 목록](https://github.com/pcaversaccio/reentrancy-attacks)에서 알 수 있듯이, 재진입 공격은 오늘날에도 여전히 스마트 계약의 중요한 문제입니다.
+
+##### 재진입 공격을 예방하는 방법
+
+재진입을 처리하는 한 가지 방법은 [확인-효과-상호작용 패턴](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern)을 따르는 것입니다. 이 패턴은 실행을 진행하기 전에 필요한 확인을 수행하는 코드가 먼저 오고, 그 다음 계약 상태를 조작하는 코드가 오고, 마지막으로 다른 계약이나 EOA와 상호작용하는 코드가 오도록 함수 실행 순서를 정합니다.
+
+확인-효과-상호작용 패턴은 아래에 표시된 `Victim` 계약의 수정된 버전에서 사용됩니다.
+
+```solidity
+contract NoLongerAVictim {
+ function withdraw() external {
+ uint256 amount = balances[msg.sender];
+ balances[msg.sender] = 0;
+ (bool success, ) = msg.sender.call.value(amount)("");
+ require(success);
+ }
+}
+```
+
+이 계약은 사용자의 잔액을 _확인_하고, `withdraw()` 함수의 _효과_(사용자 잔액을 0으로 재설정)를 적용한 후 _상호작용_(사용자 주소로 ETH 전송)을 수행합니다. 이를 통해 계약은 외부 호출 전에 저장 공간을 업그레이드하여 첫 번째 공격을 가능하게 했던 재진입 조건을 제거합니다. `Attacker` 계약은 여전히 `NoLongerAVictim`을 다시 호출할 수 있지만, `balances[msg.sender]`가 0으로 설정되었기 때문에 추가 인출은 오류를 발생시킵니다.
+
+또 다른 옵션은 함수 호출이 완료될 때까지 계약 상태의 일부를 잠그는 상호 배제 잠금(일반적으로 '뮤텍스'라고 함)을 사용하는 것입니다. 이는 함수가 실행되기 전에 `true`로 설정되고 호출이 완료된 후 `false`로 되돌아가는 부울 변수를 사용하여 구현됩니다. 아래 예에서 볼 수 있듯이, 뮤텍스를 사용하면 원래 호출이 아직 처리 중인 동안 재귀 호출로부터 함수를 보호하여 재진입을 효과적으로 막을 수 있습니다.
+
+```solidity
+pragma solidity ^0.7.0;
+
+contract MutexPattern {
+ bool locked = false;
+ mapping(address => uint256) public balances;
+
+ modifier noReentrancy() {
+ require(!locked, "재진입이 차단되었습니다.");
+ locked = true;
+ _;
+ locked = false;
+ }
+ // 이 함수는 뮤텍스로 보호되므로 'msg.sender.call' 내에서 재진입 호출을 통해 'withdraw'를 다시 호출할 수 없습니다.
+ // 'return'문은 'true'로 평가되지만 여전히 수정자에서 'locked = false'문을 평가합니다
+ function withdraw(uint _amount) public payable noReentrancy returns(bool) {
+ require(balances[msg.sender] >= _amount, "인출할 잔액이 없습니다.");
+
+ balances[msg.sender] -= _amount;
+ (bool success, ) = msg.sender.call{value: _amount}("");
+ require(success);
+
+ return true;
+ }
+}
+```
+
+계정으로 자금을 보내는 '푸시 지불' 시스템 대신, 사용자가 스마트 계약에서 자금을 인출해야 하는 [풀 지불](https://docs.openzeppelin.com/contracts/5.x/api/security#PullPayment) 시스템을 사용할 수도 있습니다. 이는 알 수 없는 주소에서 의도치 않게 코드를 트리거할 가능성을 제거하고 특정 서비스 거부 공격을 예방할 수도 있습니다.
+
+#### 정수 언더플로우 및 오버플로우 {#integer-underflows-and-overflows}
+
+정수 오버플로우는 산술 연산의 결과가 허용 가능한 값 범위를 벗어나 가장 낮은 표현 가능한 값으로 '롤오버'될 때 발생합니다. 예를 들어, `uint8`은 2^8-1=255까지의 값만 저장할 수 있습니다. 값이 `255`보다 큰 산술 연산은 오버플로우되어 `uint`를 `0`으로 재설정합니다. 이는 자동차의 주행 거리계가 최대 주행 거리(999999)에 도달하면 0으로 재설정되는 것과 유사합니다.
+
+정수 언더플로우도 비슷한 이유로 발생합니다. 산술 연산의 결과가 허용 가능한 범위 아래로 떨어지는 것입니다. 예를 들어 `uint8`에서 `0`을 감소시키려고 하면 결과는 단순히 표현 가능한 최대값(`255`)으로 롤오버됩니다.
+
+정수 오버플로우와 언더플로우 모두 계약의 상태 변수에 예기치 않은 변경을 초래하고 계획되지 않은 실행을 초래할 수 있습니다. 아래는 공격자가 스마트 계약에서 산술 오버플로우를 악용하여 잘못된 작업을 수행하는 방법을 보여주는 예입니다.
+
+```
+pragma solidity ^0.7.6;
+
+// 이 계약은 시간 금고 역할을 하도록 설계되었습니다.
+// 사용자는 이 계약에 입금할 수 있지만 최소 일주일 동안은 인출할 수 없습니다.
+// 사용자는 1주 대기 기간을 초과하여 대기 시간을 연장할 수도 있습니다.
+
+/*
+1. TimeLock 배포
+2. TimeLock의 주소로 Attack 배포
+3. 1이더를 보내는 Attack.attack 호출. 즉시 이더를 인출할 수 있습니다.
+
+무슨 일이 일어났나요?
+Attack은 TimeLock.lockTime을 오버플로우시켜 1주 대기 기간 전에 인출할 수 있었습니다.
+*/
+
+contract TimeLock {
+ mapping(address => uint) public balances;
+ mapping(address => uint) public lockTime;
+
+ function deposit() external payable {
+ balances[msg.sender] += msg.value;
+ lockTime[msg.sender] = block.timestamp + 1 weeks;
+ }
+
+ function increaseLockTime(uint _secondsToIncrease) public {
+ lockTime[msg.sender] += _secondsToIncrease;
+ }
+
+ function withdraw() public {
+ require(balances[msg.sender] > 0, "자금 부족");
+ require(block.timestamp > lockTime[msg.sender], "잠금 시간이 만료되지 않았습니다");
+
+ uint amount = balances[msg.sender];
+ balances[msg.sender] = 0;
+
+ (bool sent, ) = msg.sender.call{value: amount}("");
+ require(sent, "이더 전송 실패");
+ }
+}
+
+contract Attack {
+ TimeLock timeLock;
+
+ constructor(TimeLock _timeLock) {
+ timeLock = TimeLock(_timeLock);
+ }
+
+ fallback() external payable {}
+
+ function attack() public payable {
+ timeLock.deposit{value: msg.value}();
+ /*
+ t가 현재 잠금 시간이라면 x + t = 2**256 = 0이 되는 x를 찾아야 합니다
+ 따라서 x = -t
+ 2**256 = type(uint).max + 1
+ 따라서 x = type(uint).max + 1 - t
+ */
+ timeLock.increaseLockTime(
+ type(uint).max + 1 - timeLock.lockTime(address(this))
+ );
+ timeLock.withdraw();
+ }
+}
+```
+
+##### 정수 언더플로우 및 오버플로우 예방 방법
+
+버전 0.8.0부터 솔리디티 컴파일러는 정수 언더플로우 및 오버플로우를 초래하는 코드를 거부합니다. 그러나 더 낮은 컴파일러 버전으로 컴파일된 계약은 산술 연산과 관련된 함수에 대한 확인을 수행하거나 언더플로우/오버플로우를 확인하는 라이브러리(예: [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math))를 사용해야 합니다.
+
+#### 오라클 조작 {#oracle-manipulation}
+
+[오라클](/developers/docs/oracles/)은 오프체인 정보를 소싱하여 스마트 계약이 사용할 수 있도록 온체인으로 보냅니다. 오라클을 사용하면 자본 시장과 같은 오프체인 시스템과 상호 운용되는 스마트 계약을 설계하여 애플리케이션을 크게 확장할 수 있습니다.
+
+그러나 오라클이 손상되어 잘못된 정보를 온체인으로 보내면 스마트 계약은 잘못된 입력을 기반으로 실행되어 문제가 발생할 수 있습니다. 이것이 블록체인 오라클의 정보가 정확하고 최신이며 시기적절한지 확인하는 작업을 다루는 '오라클 문제'의 기초입니다.
+
+관련된 보안 문제는 탈중앙화 거래소와 같은 온체인 오라클을 사용하여 자산의 현물 가격을 얻는 것입니다. [탈중앙화 금융(DeFi)](/defi/) 산업의 대출 플랫폼은 사용자가 얼마나 빌릴 수 있는지 결정하기 위해 사용자의 담보 가치를 결정하기 위해 종종 이 작업을 수행합니다.
+
+DEX 가격은 주로 차익 거래자들이 시장의 균형을 회복하기 때문에 종종 정확합니다. 그러나 특히 온체인 오라클이 역사적 거래 패턴에 따라 자산 가격을 계산하는 경우(보통 그렇듯이) 조작에 개방되어 있습니다.
+
+예를 들어, 공격자는 대출 계약과 상호 작용하기 직전에 플래시 론을 받아 자산의 현물 가격을 인위적으로 부풀릴 수 있습니다. DEX에서 자산 가격을 조회하면 (공격자의 대규모 '매수 주문'이 자산 수요를 왜곡하기 때문에) 평소보다 높은 가치가 반환되어 실제보다 더 많이 빌릴 수 있습니다. 이러한 '플래시 론 공격'은 디파이 애플리케이션 간의 가격 오라클 의존도를 악용하는 데 사용되어 프로토콜에 수백만 달러의 자금 손실을 초래했습니다.
+
+##### 오라클 조작 예방 방법
+
+[오라클 조작을 피하기 위한](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples) 최소 요구 사항은 단일 실패 지점을 피하기 위해 여러 소스에서 정보를 쿼리하는 탈중앙화 오라클 네트워크를 사용하는 것입니다. 대부분의 경우 탈중앙화 오라클에는 오라클 노드가 올바른 정보를 보고하도록 장려하는 암호경제적 인센티브가 내장되어 있어 중앙화 오라클보다 더 안전합니다.
+
+자산 가격에 대해 온체인 오라클을 쿼리할 계획이라면 시간 가중 평균 가격(TWAP) 메커니즘을 구현하는 오라클을 사용하는 것을 고려하세요. [TWAP 오라클](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles)은 서로 다른 두 시점(수정 가능)에서 자산 가격을 쿼리하고 얻은 평균을 기반으로 현물 가격을 계산합니다. 더 긴 기간을 선택하면 최근에 실행된 대규모 주문이 자산 가격에 영향을 미칠 수 없으므로 프로토콜을 가격 조작으로부터 보호할 수 있습니다.
+
+## 개발자를 위한 스마트 계약 보안 참고 자료 {#smart-contract-security-resources-for-developers}
+
+### 스마트 계약 분석 및 코드 정확성 검증 도구 {#code-analysis-tools}
+
+- **[테스트 도구 및 라이브러리](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** - _스마트 계약에 대한 단위 테스트, 정적 분석 및 동적 분석을 수행하기 위한 업계 표준 도구 및 라이브러리 모음._
+
+- **[공식 검증 도구](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** - _스마트 계약의 기능적 정확성을 검증하고 불변을 확인하기 위한 도구._
+
+- **[스마트 계약 감사 서비스](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** - _이더리움 개발 프로젝트를 위한 스마트 계약 감사 서비스를 제공하는 조직 목록._
+
+- **[버그 포상금 플랫폼](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** - _버그 포상금을 조정하고 스마트 계약의 중요한 취약점에 대한 책임 있는 공개를 보상하기 위한 플랫폼._
+
+- **[Fork Checker](https://forkchecker.hashex.org/)** - _포크된 계약에 관한 모든 사용 가능한 정보를 확인하기 위한 무료 온라인 도구._
+
+- **[ABI Encoder](https://abi.hashex.org/)** - _솔리디티 계약 기능 및 생성자 인수를 인코딩하기 위한 무료 온라인 서비스._
+
+- **[Aderyn](https://github.com/Cyfrin/aderyn)** - _추상 구문 트리(AST)를 순회하여 의심되는 취약점을 찾아내고 문제를 쉽게 소비할 수 있는 마크다운 형식으로 출력하는 솔리디티 정적 분석기._
+
+### 스마트 계약 모니터링 도구 {#smart-contract-monitoring-tools}
+
+- **[Tenderly 실시간 알림](https://tenderly.co/monitoring)** - _스마트 계약이나 지갑에서 비정상적이거나 예상치 못한 이벤트가 발생했을 때 실시간 알림을 받기 위한 도구._
+
+### 스마트 계약의 안전한 관리를 위한 도구 {#smart-contract-administration-tools}
+
+- **[Safe](https://safe.global/)** - _이더리움에서 실행되는 스마트 계약 지갑으로, 트랜잭션이 발생하기 전에 최소한의 사람들이 승인해야 합니다(M-of-N)._
+
+- **[OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)** - _계약 소유권, 업그레이드, 접근 제어, 거버넌스, 일시 중지 기능 등을 포함한 관리 기능을 구현하기 위한 계약 라이브러리._
+
+### 스마트 계약 감사 서비스 {#smart-contract-auditing-services}
+
+- **[ConsenSys Diligence](https://diligence.consensys.io/)** - _블록체인 생태계 전반의 프로젝트가 프로토콜을 출시할 준비가 되어 있고 사용자를 보호하도록 구축되었는지 확인하는 데 도움이 되는 스마트 계약 감사 서비스._
+
+- **[CertiK](https://www.certik.com/)** - _스마트 계약 및 블록체인 네트워크에 대한 최첨단 공식 검증 기술 사용을 개척하는 블록체인 보안 회사._
+
+- **[Trail of Bits](https://www.trailofbits.com/)** - _보안 연구와 공격자 사고방식을 결합하여 위험을 줄이고 코드를 강화하는 사이버 보안 회사._
+
+- **[PeckShield](https://peckshield.com/)** - _전체 블록체인 생태계의 보안, 개인 정보 보호 및 유용성을 위한 제품과 서비스를 제공하는 블록체인 보안 회사._
+
+- **[QuantStamp](https://quantstamp.com/)** - _보안 및 위험 평가 서비스를 통해 블록체인 기술의 주류 채택을 촉진하는 감사 서비스._
+
+- **[OpenZeppelin](https://www.openzeppelin.com/security-audits)** - _분산 시스템에 대한 보안 감사를 제공하는 스마트 계약 보안 회사._
+
+- **[Runtime Verification](https://runtimeverification.com/)** - _스마트 계약의 공식 모델링 및 검증을 전문으로 하는 보안 회사._
+
+- **[Hacken](https://hacken.io)** - _360도 접근 방식을 블록체인 보안에 도입하는 웹3 사이버 보안 감사자._
+
+- **[Nethermind](https://www.nethermind.io/smart-contract-audits)** - _솔리디티 및 Cairo 감사 서비스로, 이더리움 및 Starknet 전반에 걸쳐 스마트 계약의 무결성과 사용자 안전을 보장합니다._
+
+- **[HashEx](https://hashex.org/)** - _HashEx는 암호화폐의 보안을 보장하기 위해 블록체인 및 스마트 계약 감사에 중점을 두며, 스마트 계약 개발, 침투 테스트, 블록체인 컨설팅과 같은 서비스를 제공합니다._
+
+- **[Code4rena](https://code4rena.com/)** - _스마트 계약 보안 전문가들이 취약점을 찾아내고 웹3를 더 안전하게 만드는 데 도움을 주도록 인센티브를 제공하는 경쟁적인 감사 플랫폼._
+
+- **[CodeHawks](https://codehawks.com/)** - _보안 연구원들을 위한 스마트 계약 감사 대회를 개최하는 경쟁적인 감사 플랫폼._
+
+- **[Cyfrin](https://cyfrin.io)** - _제품 및 스마트 계약 감사 서비스를 통해 암호화 보안을 육성하는 웹3 보안 강자._
+
+- **[ImmuneBytes](https://immunebytes.com/smart-contract-audit/)** - _경험 많은 감사자 팀과 최고 수준의 도구를 통해 블록체인 시스템에 대한 보안 감사를 제공하는 웹3 보안 회사._
+
+- **[Oxorio](https://oxor.io/)** - _암호화 회사 및 디파이 프로젝트를 위한 EVM, 솔리디티, ZK, 크로스체인 기술 전문 지식을 갖춘 스마트 계약 감사 및 블록체인 보안 서비스._
+
+- **[Inference](https://inference.ag/)** - _EVM 기반 블록체인을 위한 스마트 계약 감사를 전문으로 하는 보안 감사 회사._ 전문 감사자 덕분에 잠재적인 문제를 식별하고 배포 전에 이를 해결하기 위한 실행 가능한 해결책을 제안합니다.
+
+### 버그 포상금 플랫폼 {#bug-bounty-platforms}
+
+- **[Immunefi](https://immunefi.com/)** - _스마트 계약 및 디파이 프로젝트를 위한 버그 포상금 플랫폼으로, 보안 연구원들이 코드를 검토하고, 취약점을 공개하고, 보상을 받고, 암호화폐를 더 안전하게 만듭니다._
+
+- **[HackerOne](https://www.hackerone.com/)** - _기업과 침투 테스터 및 사이버 보안 연구원을 연결하는 취약점 조정 및 버그 포상금 플랫폼._
+
+- **[HackenProof](https://hackenproof.com/)** - _암호화 프로젝트(디파이, 스마트 계약, 지갑, CEX 등)를 위한 전문 버그 포상금 플랫폼으로, 보안 전문가들이 분류 서비스를 제공하고 연구원들은 관련 있고 검증된 버그 보고서에 대해 보상을 받습니다._
+
+- **[Sherlock](https://www.sherlock.xyz/)** - _스마트 계약 보안을 위한 웹3의 보험사로, 스마트 계약을 통해 감사자에게 지급되는 보상금을 관리하여 관련 버그가 공정하게 지급되도록 보장합니다._
+
+- **[CodeHawks](https://www.codehawks.com/)** - _감사자들이 보안 대회 및 챌린지에 참여하고 (곧) 자신들의 개인 감사에도 참여하는 경쟁적인 버그 포상금 플랫폼._
+
+### 알려진 스마트 계약 취약점 및 공격 사례 발표 {#common-smart-contract-vulnerabilities-and-exploits}
+
+- **[ConsenSys: 스마트 계약 알려진 공격](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/)** - _가장 중요한 계약 취약점에 대한 초보자 친화적인 설명으로, 대부분의 경우에 대한 샘플 코드가 포함되어 있습니다._
+
+- **[SWC 레지스트리](https://swcregistry.io/)** - _이더리움 스마트 계약에 적용되는 공통 취약점 목록(CWE) 항목의 선별된 목록._
+
+- **[Rekt](https://rekt.news/)** - _주목할 만한 암호화폐 해킹 및 공격 사례에 대한 정기적으로 업데이트되는 간행물로, 상세한 사후 보고서가 함께 제공됩니다._
+
+### 스마트 계약 보안 학습을 위한 챌린지 {#challenges-for-learning-smart-contract-security}
+
+- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** - _블록체인 보안 워게임, 챌린지 및 [캡처 더 플래그](https://www.webopedia.com/definitions/ctf-event/amp/) 대회 및 솔루션 풀이의 선별된 목록._
+
+- **[Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/)** - _디파이 스마트 계약의 공격적 보안을 배우고 버그 헌팅 및 보안 감사 기술을 구축하기 위한 워게임._
+
+- **[Ethernaut](https://ethernaut.openzeppelin.com/)** - _각 레벨이 '해킹'되어야 하는 스마트 계약인 웹3/솔리디티 기반 워게임._
+
+- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** - _판타지 모험을 배경으로 한 스마트 계약 해킹 챌린지._ 챌린지를 성공적으로 완료하면 비공개 버그 포상금 프로그램에 접근할 수도 있습니다.
+
+### 스마트 계약 보안을 위한 모범 사례 {#smart-contract-security-best-practices}
+
+- **[ConsenSys: 이더리움 스마트 계약 보안 모범 사례](https://consensys.github.io/smart-contract-best-practices/)** - _이더리움 스마트 계약 보안을 위한 포괄적인 가이드라인 목록._
+
+- **[Nascent: 단순 보안 툴킷](https://github.com/nascentxyz/simple-security-toolkit)** - _스마트 계약 개발을 위한 실용적인 보안 중심 가이드 및 체크리스트 모음._
+
+- **[솔리디티 패턴](https://fravoll.github.io/solidity-patterns/)** - _스마트 계약 프로그래밍 언어인 솔리디티를 위한 안전한 패턴 및 모범 사례의 유용한 모음집._
+
+- **[솔리디티 문서: 보안 고려 사항](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** - _솔리디티로 안전한 스마트 계약을 작성하기 위한 가이드라인._
+
+- **[스마트 계약 보안 검증 표준](https://github.com/securing/SCSVS)** - _개발자, 설계자, 보안 검토자 및 공급업체를 위해 스마트 계약의 보안을 표준화하기 위해 만들어진 14개 부분으로 구성된 체크리스트._
+
+- **[스마트 계약 보안 및 감사 학습](https://updraft.cyfrin.io/courses/security)** - _보안 모범 사례를 향상시키고 보안 연구원이 되고자 하는 스마트 계약 개발자를 위해 만들어진 최고의 스마트 계약 보안 및 감사 과정._
+
+### 스마트 계약 보안에 관한 튜토리얼 {#tutorials-on-smart-contract-security}
+
+- [안전한 스마트 계약 작성 방법](/developers/tutorials/secure-development-workflow/)
+
+- [Slither를 사용하여 스마트 계약 버그를 찾는 방법](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
+
+- [Manticore를 사용하여 스마트 계약 버그를 찾는 방법](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
+
+- [스마트 계약 보안 가이드라인](/developers/tutorials/smart-contract-security-guidelines/)
+
+- [토큰 계약을 임의의 토큰과 안전하게 통합하는 방법](/developers/tutorials/token-integration-checklist/)
+
+- [Cyfrin Updraft - 스마트 계약 보안 및 감사 전체 과정](https://updraft.cyfrin.io/courses/security)
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/testing/index.md b/public/content/translations/ko/developers/docs/smart-contracts/testing/index.md
new file mode 100644
index 00000000000..2ec6206ddff
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/testing/index.md
@@ -0,0 +1,310 @@
+---
+title: "스마트 계약 테스트"
+description: "Ethereum 스마트 계약을 테스트하기 위한 기술 및 고려 사항의 개요입니다."
+lang: ko
+---
+
+Ethereum과 같은 공공 블록체인은 불변성이 있어, 배포 후 스마트 계약 코드를 변경하는 것이 어렵습니다. “가상 업그레이드”를 수행하기 위한 `[계약 업그레이드 패턴](/developers/docs/smart-contracts/upgrading/)`이 존재하지만, 이는 구현하기 어렵고 사회적 합의가 필요합니다. 또한 업그레이드는 오류가 발견된 `후에만` 수정할 수 있습니다. 만약 공격자가 취약점을 먼저 발견하면 스마트 계약은 공격에 노출될 위험이 있습니다.
+
+이러한 이유로 `[배포](/developers/docs/smart-contracts/deploying/)`하기 전에 스마트 계약을 테스트하는 것은 `[보안](/developers/docs/smart-contracts/security/)`을 위한 최소한의 요구 사항입니다. 스마트 계약을 테스트하고 코드의 정확성을 평가하기 위한 다양한 기술이 존재하며, 사용자는 필요에 따라 적절한 방법을 선택할 수 있습니다. 그러나 경미한 보안 결함부터 주요 결함까지 잡아내기 위해서는 다양한 도구와 접근 방식을 포함한 테스트 스위트가 이상적입니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지는 Ethereum 네트워크에 배포하기 전에 스마트 계약을 테스트하는 방법을 설명합니다. 이 문서는 독자가 `[스마트 계약](/developers/docs/smart-contracts/)`에 익숙하다고 가정합니다.
+
+## 스마트 계약 테스트란 무엇입니까? 스마트 계약 테스트란? {#what-is-smart-contract-testing}
+
+스마트 계약 테스트는 스마트 계약 코드가 예상대로 작동하는지 확인하는 과정입니다. 테스트는 특정 스마트 계약이 신뢰성, 사용성 및 보안 요구 사항을 충족하는지 확인하는 데 유용합니다.
+
+접근 방식은 다양하지만, 대부분의 테스트 방법은 스마트 계약이 처리할 것으로 예상되는 데이터의 소규모 샘플로 계약을 실행하는 것이 필요합니다. 계약이 샘플 데이터에 대해 올바른 결과를 생성하면 정상적으로 작동하는 것으로 간주됩니다. 대부분의 테스트 도구는 계약의 실행이 예상 결과와 일치하는지 확인하기 위해 `[테스트 케이스](https://en.m.wikipedia.org/wiki/Test_case)`를 작성하고 실행하기 위한 리소스를 제공합니다.
+
+### 스마트 계약을 테스트하는 것이 왜 중요한가요? 스마트 계약 테스트의 중요성 {#importance-of-testing-smart-contracts}
+
+스마트 계약은 종종 고가의 금융 자산을 관리하기 때문에, 사소한 프로그래밍 오류가 `[사용자에게 막대한 손실](https://rekt.news/leaderboard/)`로 이어질 수 있으며, 실제로도 종종 그렇습니다. 엄격한 테스트를 통해 스마트 계약 코드의 결함과 문제를 조기에 발견하고 메인넷에 배포하기 전에 수정할 수 있습니다.
+
+버그가 발견되면 계약을 업그레이드할 수 있지만, 업그레이드는 복잡하며 부적절하게 처리될 경우 `[오류를 초래](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/)`할 수 있습니다. 계약을 업그레이드하는 것은 불변성의 원칙을 무시하고 사용자가 추가 신뢰 가정을 가지게 합니다. 반대로, 계약 테스트에 대한 포괄적인 계획은 스마트 계약 보안 위험을 완화하고 배포 후 복잡한 논리 업그레이드 수행 필요성을 줄입니다.
+
+## 스마트 계약 테스트 방법 {#methods-for-testing-smart-contracts}
+
+이더리움 스마트 계약 테스트 방법은 **자동화된 테스트**와 **수동 테스트**라는 두 가지 큰 범주로 나뉩니다. 자동화 테스트와 수동 테스트는 각각 고유한 장점과 단점을 제공하지만, 두 가지를 결합하여 계약 분석을 위한 강력한 계획을 수립할 수 있습니다.
+
+### 자동화된 테스트 {#automated-testing}
+
+자동화 테스트는 스마트 계약 코드의 실행 오류를 자동으로 검사하는 도구를 사용합니다. 자동화된 테스트의 이점은 계약 기능성 평가를 안내하기 위해 `[스크립트](https://www.techtarget.com/whatis/definition/script?amp=1)`를 사용하는 데서 비롯됩니다. 스크립트화된 테스트는 최소한의 인간 개입으로 반복적으로 실행되도록 예약할 수 있어 수동 테스트 접근 방식보다 효율적입니다.
+
+자동화 테스트는 테스트가 반복적이거나 시간 소모적일 때, 수동으로 수행하기 어려울 때, 인간의 실수가 발생할 수 있을 때 또는 중요한 계약 기능을 평가할 때 특히 유용합니다. 그러나 자동화된 테스트 도구는 특정 버그를 놓치거나 많은 `[오탐](https://www.contrastsecurity.com/glossary/false-positive)`을 생성할 수 있다는 단점이 있을 수 있습니다. 따라서 스마트 계약의 경우 자동화 테스트와 수동 테스트를 결합하는 것이 이상적입니다.
+
+### 수동 테스트 {#manual-testing}
+
+수동 테스트는 인간의 도움이 필요하며 스마트 계약의 정확성을 분석할 때 테스트 케이스를 하나씩 실행하는 것입니다. 이는 계약에서 여러 독립 테스트를 동시에 실행하고 모든 실패 및 성공 테스트를 보여주는 보고서를 얻는 자동화 테스트와 다릅니다.
+
+수동 테스트는 다양한 테스트 시나리오를 포함하는 작성된 테스트 계획에 따라 단일 개인이 수행할 수도 있습니다. 또한 여러 개인 또는 그룹이 지정된 기간 동안 스마트 계약과 상호 작용하는 수동 테스트의 일환으로 참여할 수 있습니다. 테스터는 계약의 실제 동작을 예상 동작과 비교하고 차이점이 발견되면 이를 버그로 표시합니다.
+
+효과적인 수동 테스트에는 상당한 자원(기술, 시간, 비용, 노력)이 필요하며, 실행 중 실수로 인해 특정 오류가 누락될 수 있습니다. 그러나 수동 테스트는 직관을 사용하여 자동화 테스트 도구에서 놓칠 수 있는 경계 사례를 탐지하는 인간 테스터(예: 감사자)에게 유용할 수 있습니다.
+
+## 스마트 계약을 위한 자동화된 테스트 {#automated-testing-for-smart-contracts}
+
+### 단위 테스트 {#unit-testing-for-smart-contracts}
+
+유닛 테스트는 계약 기능을 개별적으로 평가하고 각 구성 요소가 올바르게 작동하는지 확인합니다. 좋은 유닛 테스트는 간단하고 실행이 빠르며, 테스트 실패 시 어떤 문제가 발생했는지 명확하게 알 수 있습니다.
+
+유닛 테스트는 함수가 예상된 값을 반환하고 함수 실행 후 계약 저장소가 제대로 업데이트되는지 확인하는 데 유용합니다. 또한, 계약 코드베이스에 변경 사항을 추가한 후 유닛 테스트를 실행하면 새로운 로직이 오류를 도입하지 않았는지 확인할 수 있습니다. 다음은 효과적인 유닛 테스트를 실행하기 위한 몇 가지 지침입니다:
+
+#### 스마트 계약 단위 테스트 지침 {#unit-testing-guidelines}
+
+##### 1. 계약의 비즈니스 로직과 워크플로를 이해하세요
+
+유닛 테스트를 작성하기 전에 스마트 계약이 제공하는 기능과 사용자가 해당 기능에 액세스하고 사용하는 방법을 아는 것이 좋습니다. 이는 계약의 함수가 유효한 사용자 입력에 대해 올바른 출력을 반환하는지 판단하는 `[해피 패스 테스트](https://en.m.wikipedia.org/wiki/Happy_path)`를 실행하는 데 특히 유용합니다. 이 개념을 `[경매 계약](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction)`의 (축약된) 예시를 사용하여 설명하겠습니다.
+
+```solidity
+constructor(
+ uint biddingTime,
+ address payable beneficiaryAddress
+ ) {
+ beneficiary = beneficiaryAddress;
+ auctionEndTime = block.timestamp + biddingTime;
+ }
+
+function bid() external payable {
+
+ if (block.timestamp > auctionEndTime)
+ revert AuctionAlreadyEnded();
+
+ if (msg.value <= highestBid)
+ revert BidNotHighEnough(highestBid);
+
+ if (highestBid != 0) {
+ pendingReturns[highestBidder] += highestBid;
+ }
+ highestBidder = msg.sender;
+ highestBid = msg.value;
+ emit HighestBidIncreased(msg.sender, msg.value);
+ }
+
+ function withdraw() external returns (bool) {
+ uint amount = pendingReturns[msg.sender];
+ if (amount > 0) {
+ pendingReturns[msg.sender] = 0;
+
+ if (!payable(msg.sender).send(amount)) {
+ pendingReturns[msg.sender] = amount;
+ return false;
+ }
+ }
+ return true;
+ }
+
+function auctionEnd() external {
+ if (block.timestamp < auctionEndTime)
+ revert AuctionNotYetEnded();
+ if (ended)
+ revert AuctionEndAlreadyCalled();
+
+ ended = true;
+ emit AuctionEnded(highestBidder, highestBid);
+
+ beneficiary.transfer(highestBid);
+ }
+}
+```
+
+이것은 입찰 기간 동안 입찰을 받도록 설계된 간단한 경매 계약입니다. `highestBid`가 증가하면 이전 최고 입찰자는 자신의 돈을 돌려받습니다. 입찰 기간이 끝나면 `beneficiary`는 계약을 호출하여 자신의 돈을 받습니다.
+
+이와 같은 계약에 대한 유닛 테스트는 사용자가 계약과 상호 작용할 때 호출할 수 있는 다양한 기능을 다룹니다. 예를 들어, 경매가 진행 중일 때 사용자가 입찰할 수 있는지 확인하는 단위 테스트(`bid()` 호출이 성공하는지)나 사용자가 현재의 `highestBid`보다 높은 입찰을 할 수 있는지 확인하는 테스트가 있을 수 있습니다.
+
+계약의 운영 워크플로를 이해하면 실행이 요구 사항을 충족하는지 확인하는 유닛 테스트를 작성하는 데 도움이 됩니다. 예를 들어, 경매 계약은 경매가 종료되었을 때(즉, `auctionEndTime`이 `block.timestamp`보다 낮을 때) 사용자가 입찰할 수 없다고 명시합니다. 따라서 개발자는 경매가 끝났을 때(즉, `auctionEndTime` > `block.timestamp`일 때) `bid()` 함수 호출이 성공하는지 또는 실패하는지를 확인하는 단위 테스트를 실행할 수 있습니다.
+
+##### 2. 계약 실행과 관련된 모든 가정을 평가하세요
+
+계약의 실행에 대한 모든 가정을 문서화하고 해당 가정의 타당성을 확인하는 유닛 테스트를 작성하는 것이 중요합니다. 예상치 못한 실행에 대한 보호를 제공할 뿐만 아니라, 테스트 가정을 통해 스마트 계약의 보안 모델을 위반할 수 있는 작업에 대해 생각하게 합니다. 유용한 팁은 "행복한 사용자 테스트"를 넘어서 잘못된 입력에 대해 함수가 실패하는지 확인하는 부정 테스트를 작성하는 것입니다.
+
+많은 유닛 테스트 프레임워크는 계약이 할 수 있는 것과 할 수 없는 것을 명시하는 간단한 문장인 어설션을 생성하고, 해당 어설션이 실행 중에 유지되는지 확인하는 테스트를 실행할 수 있습니다. 위에서 설명한 경매 계약을 작업하는 개발자는 부정 테스트를 실행하기 전에 다음과 같은 행동에 대한 어설션을 만들 수 있습니다:
+
+- 경매가 종료되었거나 시작되지 않았을 때 사용자는 입찰할 수 없습니다.
+
+- 입찰이 허용 가능한 기준에 미달하면 경매 계약이 복구됩니다.
+
+- 입찰에 실패한 사용자는 자금이 반환됩니다.
+
+**참고**: 가정을 테스트하는 또 다른 방법은 계약에서, 특히 `require`, `assert`, `if…else` 문과 같은 `[함수 제어자](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers)`를 트리거하는 테스트를 작성하는 것입니다.
+
+##### 3. 코드 커버리지 측정
+
+`[코드 커버리지](https://en.m.wikipedia.org/wiki/Code_coverage)`는 테스트 중에 실행된 코드의 분기, 줄, 문의 수를 추적하는 테스트 지표입니다. 테스트되지 않은 취약점의 위험을 최소화하기 위해 테스트는 우수한 코드 커버리지를 가져야 합니다. 충분한 커버리지가 없으면 모든 테스트가 통과하기 때문에 계약이 안전하다고 잘못 가정할 수 있지만, 테스트되지 않은 코드 경로에는 여전히 취약점이 존재합니다. 높은 코드 커버리지를 기록하면 스마트 계약의 모든 문장/함수가 충분히 테스트되어 올바르게 작동함을 보장합니다.
+
+##### 4. 잘 개발된 테스트 프레임워크를 사용하십시오.
+
+스마트 계약의 단위 테스트를 실행할 때 사용하는 도구의 품질은 매우 중요합니다. 이상적인 테스트 프레임워크는 정기적으로 유지 보수되고, 유용한 기능(예: 로깅 및 보고 기능)을 제공하며, 다른 개발자들에 의해 광범위하게 사용되고 검증된 프레임워크입니다.
+
+Solidity 스마트 계약을 위한 단위 테스트 프레임워크는 다양한 언어(주로 JavaScript, Python, Rust) 로 제공됩니다. 아래 가이드에서 다양한 테스트 프레임워크로 단위 테스트를 시작하는 방법에 대한 정보를 확인하십시오:
+
+- **[Brownie로 단위 테스트 실행하기](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)**
+- **[Foundry로 단위 테스트 실행하기](https://book.getfoundry.sh/forge/writing-tests)**
+- **[Waffle로 단위 테스트 실행하기](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)**
+- **[Remix로 단위 테스트 실행하기](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)**
+- **[Ape로 단위 테스트 실행하기](https://docs.apeworx.io/ape/stable/userguides/testing.html)**
+- **[Hardhat으로 단위 테스트 실행하기](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)**
+- **[Wake로 단위 테스트 실행하기](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)**
+
+### 통합 테스트 {#integration-testing-for-smart-contracts}
+
+단위 테스트가 계약 함수들을 개별적으로 디버깅하는 동안, 통합 테스트는 스마트 계약의 모든 구성 요소를 평가합니다. 통합 테스트는 다른 스마트 계약 간의 상호작용이나 같은 스마트 계약 내의 다양한 함수 간의 호출로 인해 발생하는 문제를 감지할 수 있습니다. 예를 들어, 통합 테스트는 `[상속](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance)` 및 종속성 주입과 같은 기능이 제대로 작동하는지 확인하는 데 도움이 될 수 있습니다.
+
+통합 테스트는 계약이 모듈식 아키텍처를 채택하거나 실행 중에 다른 온체인 계약과 인터페이스하는 경우에 유용합니다. 통합 테스트를 실행하는 한 가지 방법은 특정 높이에서 `[블록체인을 포크](/glossary/#fork)`하고(`[Forge](https://book.getfoundry.sh/forge/fork-testing)` 또는 `[Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks)`과 같은 도구 사용) 계약과 배포된 계약 간의 상호 작용을 시뮬레이션하는 것입니다.
+
+포크된 블록체인은 메인넷과 유사하게 작동하며 관련 상태와 잔액을 가진 계정을 포함합니다. 그러나 이 환경은 로컬 개발 환경에만 국한되므로 예를 들어 실제 이더리움(ETH)이 트랜잭션에 필요하지 않으며, 실제 이더리움 프로토콜에 영향을 주지 않습니다.
+
+### 속성 기반 테스트 {#property-based-testing-for-smart-contracts}
+
+속성 기반 테스트는 스마트 계약이 정의된 속성을 충족하는지 확인하는 과정입니다. 속성은 계약의 동작에 대해 다양한 시나리오에서 참으로 유지될 것으로 예상되는 사실을 나타냅니다—예를 들어, "계약의 산술 연산은 오버플로 또는 언더플로를 발생시키지 않는다"라는 것이 스마트 계약 속성의 예일 수 있습니다.
+
+**정적 분석**과 **동적 분석**은 속성 기반 테스트를 실행하기 위한 두 가지 일반적인 기술이며, 두 기술 모두 프로그램(이 경우 스마트 계약)의 코드가 미리 정의된 속성을 만족하는지 확인할 수 있습니다. 일부 속성 기반 테스트 도구는 예상되는 계약 속성에 대한 미리 정의된 규칙을 제공하며, 코드가 이러한 규칙을 준수하는지 확인합니다. 다른 도구는 스마트 계약에 대한 사용자 지정 속성을 생성할 수 있도록 합니다.
+
+#### 정적 분석 {#static-analysis}
+
+정적 분석 도구는 스마트 계약의 소스 코드를 입력으로 받아 계약이 속성을 충족하는지 여부를 선언하는 결과를 출력합니다. 동적 분석과는 달리, 정적 분석은 계약을 실행하지 않고 올바름을 분석합니다. 정적 분석은 대신 계약이 실행 중에 가질 수 있는 모든 경로를 추론하며(즉, 소스 코드 구조를 검사하여 런타임에 계약의 작동이 어떻게 되는지 결정합니다).
+
+`[린팅](https://www.perforce.com/blog/qac/what-is-linting)`과 `[정적 테스트](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis)`는 계약에 대한 정적 분석을 실행하는 일반적인 방법입니다. 두 방법 모두 컴파일러가 출력하는 `[추상 구문 트리](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree)` 및 `[제어 흐름 그래프](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/)`와 같은 계약 실행의 저수준 표현을 분석해야 합니다.
+
+대부분의 경우, 정적 분석은 코드에서 안전하지 않은 구조물 사용, 구문 오류 또는 코딩 표준 위반과 같은 안전 문제를 감지하는 데 유용합니다. 그러나 정적 분석기는 더 깊은 취약점을 감지하는 데는 일반적으로 효과적이지 않으며, 과도한 거짓 양성 결과를 생성할 수 있습니다.
+
+#### 동적 분석 {#dynamic-analysis}
+
+동적 분석은 스마트 계약 함수의 `[심볼릭 실행](https://en.m.wikipedia.org/wiki/Symbolic_execution)`에서의 심볼릭 입력이나 `[퍼징](https://owasp.org/www-community/Fuzzing)`에서의 구체적인 입력과 같은 것을 생성하여 실행 추적이 특정 속성을 위반하는지 확인합니다. 이러한 속성 기반 테스트는 테스트 케이스가 여러 시나리오를 포괄하며 프로그램이 테스트 케이스를 생성하는 방식에서 단위 테스트와 다릅니다.
+
+`[퍼징](https://www.halborn.com/blog/post/what-is-fuzz-testing-fuzzing)`은 스마트 계약에서 임의의 속성을 검증하기 위한 동적 분석 기법의 한 예입니다. 퍼저는 정의된 입력 값의 무작위 또는 잘못된 변형으로 대상 계약의 함수를 호출합니다. 스마트 계약이 오류 상태(예: 단언이 실패하는 상태)에 들어가면 문제가 플래그 처리되며 취약한 경로로 실행을 유도하는 입력이 보고서에 생성됩니다.
+
+퍼징은 스마트 계약의 입력 유효성 검사 메커니즘을 평가하는 데 유용합니다. 예상치 못한 입력을 적절히 처리하지 않으면 의도치 않은 실행이 발생하고 위험한 영향을 초래할 수 있기 때문입니다. 이러한 속성 기반 테스트는 여러 이유로 이상적일 수 있습니다:
+
+1. **많은 시나리오를 다루는 테스트 케이스를 작성하는 것은 어렵습니다.** 속성 테스트는 동작을 정의하고 해당 동작을 테스트할 데이터의 범위를 정의하기만 하면 됩니다. 프로그램은 정의된 속성을 기반으로 테스트 케이스를 자동으로 생성합니다.
+
+2. **테스트 스위트가 프로그램 내의 모든 가능한 경로를 충분히 다루지 못할 수 있습니다.** 100%의 커버리지를 달성하더라도 에지 케이스를 놓칠 수 있습니다.
+
+3. **단위 테스트는 샘플 데이터에 대해 계약이 올바르게 실행됨을 증명하지만, 샘플 외부의 입력에 대해 계약이 올바르게 실행되는지는 알 수 없습니다.** 속성 테스트는 주어진 입력 값의 다양한 변형으로 대상 계약을 실행하여 어설션 실패를 유발하는 실행 추적을 찾습니다. 따라서 속성 테스트는 계약이 광범위한 입력 데이터 클래스에 대해 올바르게 실행됨을 더 많이 보장합니다.
+
+### 스마트 계약의 속성 기반 테스트 실행 지침 {#running-property-based-tests}
+
+속성 기반 테스트 실행은 일반적으로 스마트 계약에서 검증하려는 속성(예: `[정수 오버플로](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)`의 부재) 또는 속성 모음을 정의하는 것으로 시작됩니다. 속성 테스트를 작성할 때 트랜잭션 입력에 대해 프로그램이 생성할 수 있는 값의 범위를 정의해야 할 수도 있습니다.
+
+적절하게 구성된 속성 테스트 도구는 무작위로 생성된 입력을 사용하여 스마트 계약 기능을 실행합니다. 어설션 위반이 있으면 평가 중인 속성을 위반하는 구체적인 입력 데이터를 포함한 보고서를 받을 수 있습니다. 다음 가이드를 통해 다양한 도구로 속성 기반 테스트를 실행하는 방법을 시작할 수 있습니다:
+
+- **[Slither를 사용한 스마트 계약의 정적 분석](https://github.com/crytic/slither)**
+- **[Wake를 사용한 스마트 계약의 정적 분석](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)**
+- **[Brownie를 사용한 속성 기반 테스트](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)**
+- **[Foundry를 사용한 계약 퍼징](https://book.getfoundry.sh/forge/fuzz-testing)**
+- **[Echidna를 사용한 계약 퍼징](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)**
+- **[Wake를 사용한 계약 퍼징](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)**
+- **[Manticore를 사용한 스마트 계약의 심볼릭 실행](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)**
+- **[Mythril을 사용한 스마트 계약의 심볼릭 실행](https://mythril-classic.readthedocs.io/en/master/tutorial.html)**
+
+## 스마트 계약의 수동 테스트 {#manual-testing-for-smart-contracts}
+
+스마트 계약의 수동 테스트는 일반적으로 자동화된 테스트를 실행한 후 개발 주기 후반에 수행됩니다. 이 형태의 테스트는 스마트 계약을 하나의 통합된 제품으로 평가하여 기술 요구 사항에 지정된 대로 성능을 발휘하는지 확인합니다.
+
+### 로컬 블록체인에서 계약 테스트하기 {#testing-on-local-blockchain}
+
+로컬 개발 환경에서 수행된 자동화 테스트는 유용한 디버깅 정보를 제공할 수 있지만, 프로덕션 환경에서 스마트 계약이 어떻게 작동하는지 알아야 합니다. 그러나 메인 이더리움 체인에 배포하면 가스 요금이 발생하며, 스마트 계약에 여전히 버그가 있을 경우 실제 돈을 잃을 수도 있습니다.
+
+로컬 블록체인(`[개발 네트워크](/developers/docs/development-networks/)`라고도 함)에서 계약을 테스트하는 것은 메인넷에서 테스트하는 것에 대한 권장 대안입니다. 로컬 블록체인은 컴퓨터에서 로컬로 실행되는 이더리움 블록체인의 사본으로 이더리움의 실행 레이어의 동작을 시뮬레이션합니다. 따라서 상당한 오버헤드 없이 계약과 상호 작용하는 트랜잭션을 프로그래밍할 수 있습니다.
+
+로컬 블록체인에서 계약을 실행하는 것은 수동 통합 테스트의 한 형태로 유용할 수 있습니다. `[스마트 계약은 구성성이 높기 때문에](/developers/docs/smart-contracts/composability/)` 기존 프로토콜과 통합할 수 있습니다. 하지만 이러한 복잡한 온체인 상호 작용이 올바른 결과를 생성하는지 확인해야 합니다.
+
+`[개발 네트워크에 대해 자세히 알아보기](/developers/docs/development-networks/)`
+
+### 테스트넷에서 계약 테스트하기 {#testing-contracts-on-testnets}
+
+테스트 네트워크 또는 테스트넷은 실제 가치가 없는 이더(ETH)를 사용한다는 점을 제외하면 이더리움 메인넷과 똑같이 작동합니다. 계약을 `[테스트넷](/developers/docs/networks/#ethereum-testnets)`에 배포하면 누구나 자금의 위험 없이 계약과 상호 작용할 수 있습니다(예: 탈중앙화앱의 프론트엔드를 통해).
+
+이 형태의 수동 테스트는 애플리케이션의 엔드투엔드 플로우를 사용자의 관점에서 평가하는 데 유용합니다. 여기에서 베타 테스터도 시운전을 수행하고 계약의 비즈니스 논리 및 전반적인 기능과 관련된 문제를 보고할 수 있습니다.
+
+로컬 블록체인에서 테스트한 후 테스트넷에 배포하는 것이 이상적입니다. 테스트넷의 동작이 이더리움 가상 머신과 유사하기 때문입니다. 따라서 많은 이더리움 네이티브 프로젝트가 실제 조건에서 스마트 계약 작동을 평가하기 위해 테스트넷에 dapp을 배포하는 것이 일반적입니다.
+
+`[이더리움 테스트넷에 대해 자세히 알아보기](/developers/docs/development-networks/#public-beacon-testchains)`
+
+## 테스트와 형식 검증 비교 {#testing-vs-formal-verification}
+
+테스트는 특정 데이터 입력에 대해 계약이 예상 결과를 반환하는지 확인하는 데 도움이 되지만, 테스트에 사용되지 않은 입력에 대해 동일한 결과를 확정적으로 입증할 수는 없습니다. 따라서 스마트 계약을 테스트하는 것은 '기능적 정확성'을 보장할 수 없습니다(즉, 프로그램이 `모든` 입력값 세트에 대해 요구되는 대로 동작한다는 것을 보여줄 수 없습니다).
+
+형식 검증은 프로그램의 형식 모델이 형식 명세와 일치하는지 확인하여 소프트웨어의 정확성을 평가하는 접근 방식입니다. 형식 모델은 프로그램의 추상적 수학적 표현이며, 형식 명세는 프로그램의 속성(즉, 프로그램 실행에 대한 논리적 어설션)을 정의합니다.
+
+속성이 수학적 용어로 작성되므로 시스템의 형식(수학적) 모델이 논리적 추론 규칙을 사용하여 명세를 충족하는지 검증할 수 있습니다. 따라서 형식 검증 도구는 시스템의 정확성에 대한 '수학적 증거'를 제공한다고 합니다.
+
+테스트와 달리, 형식 검증은 샘플 데이터로 실행할 필요 없이 `모든` 실행에 대해 스마트 계약 실행이 형식 사양을 만족하는지(즉, 버그가 없는지) 확인하는 데 사용할 수 있습니다. 이는 수많은 단위 테스트를 실행하는 데 걸리는 시간을 줄일 뿐만 아니라 숨겨진 취약점을 잡는 데도 더 효과적입니다. 말하자면, 형식 검증 기술은 구현의 난이도와 유용성에 따라 범위에 따라 다릅니다.
+
+`[스마트 계약의 형식 검증에 대해 자세히 알아보기](/developers/docs/smart-contracts/formal-verification)`
+
+## 테스트와 감사 및 버그 바운티 비교 {#testing-vs-audits-bug-bounties}
+
+앞서 언급했듯이, 엄격한 테스트는 계약에서 버그가 없음을 보장하기 어렵습니다. 형식 검증 접근 방식은 더 강력한 정확성 보증을 제공할 수 있지만, 현재 사용하기 어렵고 상당한 비용이 듭니다.
+
+그럼에도 불구하고 타인으로 하여금 계약을 분석하도록 하여 계약의 취약점을 포착할 가능성을 높일 수 있습니다. `[스마트 계약 감사](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/)`와 `[버그 바운티](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)`는 다른 사람이 여러분의 계약을 분석하게 하는 두 가지 방법입니다.
+
+감사는 스마트 계약에서 보안 결함 및 개발 관행의 부족한 사례를 찾는 데 경험이 많은 감사자가 수행합니다. 감사는 테스트(그리고 가능하면 형식 검증)뿐만 아니라 전체 코드베이스에 대한 수동 검토도 포함됩니다.
+
+반대로 버그 바운티 프로그램은 일반적으로 스마트 계약의 취약점을 발견하여 개발자에게 공개하는 개인(`[화이트햇 해커]()`라고 흔히 칭함)에게 금전적 보상을 제공하는 것을 포함합니다. 버그 바운티는 스마트 계약에서 결함을 찾는 데 다른 사람의 도움을 요청하는 점에서 감사와 유사합니다.
+
+주요 차이점은 버그 바운티 프로그램이 더 넓은 개발자/해커 커뮤니티에 개방되어 있으며 독특한 기술과 경험을 가진 다양한 윤리적 해커와 독립 보안 전문가들을 끌어들인다는 것입니다. 이것은 제한되거나 좁은 전문 지식을 가진 팀에 의존하는 스마트 계약 감사를 능가하는 장점이 될 수 있습니다.
+
+## 테스트 도구 및 라이브러리 {#testing-tools-and-libraries}
+
+### 단위 테스트 도구 {#unit-testing-tools}
+
+- **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** - _Solidity로 작성된 스마트 계약을 위한 코드 커버리지 도구입니다._
+
+- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** - _고급 스마트 계약 개발 및 테스트를 위한 프레임워크(ethers.js 기반)입니다._
+
+- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _Solidity 스마트 계약 테스트용 도구입니다._ Remix IDE의 "Solidity Unit Testing" 플러그인을 통해 계약의 테스트 케이스를 작성하고 실행하는 데 사용됩니다._
+
+- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _이더리움 스마트 계약 테스트를 위한 어설션 라이브러리입니다._ 계약이 예상대로 작동하는지 확인하세요!_
+
+- **[Brownie 단위 테스트 프레임워크](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _Brownie는 기능이 풍부한 테스트 프레임워크인 Pytest를 활용하여 최소한의 코드로 작은 테스트를 작성하고, 대규모 프로젝트에 맞게 확장하며, 높은 확장성을 제공합니다._
+
+- **[Foundry 테스트](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** - _Foundry는 간단한 단위 테스트, 가스 최적화 확인, 계약 퍼징을 실행할 수 있는 빠르고 유연한 이더리움 테스트 프레임워크인 Forge를 제공합니다._
+
+- **[Hardhat 테스트](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _ethers.js, Mocha, Chai를 기반으로 한 스마트 계약 테스트용 프레임워크입니다._
+
+- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _이더리움 가상 머신을 대상으로 하는 스마트 계약을 위한 Python 기반 개발 및 테스트 프레임워크입니다._
+
+- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _강력한 디버깅 기능과 교차 체인 테스트를 지원하는 단위 테스트 및 퍼징을 위한 Python 기반 프레임워크로, 최상의 사용자 경험과 성능을 위해 pytest와 Anvil을 활용합니다._
+
+### 속성 기반 테스트 도구 {#property-based-testing-tools}
+
+#### 정적 분석 도구 {#static-analysis-tools}
+
+- **[Slither](https://github.com/crytic/slither)** - _취약점 발견, 코드 이해도 향상, 스마트 계약을 위한 맞춤형 분석 작성을 위한 Python 기반 Solidity 정적 분석 프레임워크입니다._
+
+- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _Solidity 스마트 계약 프로그래밍 언어에 대한 스타일 및 보안 모범 사례를 적용하기 위한 린터입니다._
+
+- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** - _Web3 스마트 계약 보안 및 개발을 위해 특별히 설계된 Rust 기반 정적 분석기입니다._
+
+- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _취약성 및 코드 품질 감지기, 코드에서 유용한 정보를 추출하기 위한 프린터, 맞춤형 하위 모듈 작성을 지원하는 Python 기반 정적 분석 프레임워크입니다._
+
+- **[Slippy](https://github.com/fvictorio/slippy)** - _Solidity를 위한 간단하고 강력한 린터입니다._
+
+#### 동적 분석 도구 {#dynamic-analysis-tools}
+
+- **[Echidna](https://github.com/crytic/echidna/)** - _속성 기반 테스트를 통해 스마트 계약의 취약점을 탐지하는 빠른 계약 퍼저입니다._
+
+- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _스마트 계약 코드에서 속성 위반을 탐지하는 데 유용한 자동화된 퍼징 도구입니다._
+
+- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** - _EVM 바이트코드 분석을 위한 동적 심볼릭 실행 프레임워크입니다._
+
+- **[Mythril](https://github.com/ConsenSys/mythril-classic)** - _테인트 분석, 콘콜릭 분석 및 제어 흐름 검사를 사용하여 계약 취약점을 탐지하는 EVM 바이트코드 평가 도구입니다._
+
+- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _Scribble은 명세 언어이자 런타임 검증 도구로, 스마트 계약에 속성을 주석으로 달아 Diligence Fuzzing이나 MythX와 같은 도구로 계약을 자동으로 테스트할 수 있게 해줍니다._
+
+## 관련 튜토리얼 {#related-tutorials}
+
+- [다양한 테스트 제품 개요 및 비교](/developers/tutorials/guide-to-smart-contract-security-tools/) \_
+- [Echidna를 사용하여 스마트 계약을 테스트하는 방법](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/)
+- [Manticore를 사용하여 스마트 계약 버그를 찾는 방법](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
+- [Slither를 사용하여 스마트 계약 버그를 찾는 방법](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
+- [테스트를 위해 Solidity 계약을 모의하는 방법](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/)
+- [Foundry를 사용하여 Solidity에서 단위 테스트를 실행하는 방법](https://www.rareskills.io/post/foundry-testing-solidity)
+
+## 더 읽어보기 {#further-reading}
+
+- [이더리움 스마트 계약 테스트에 대한 심층 가이드](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297)
+- [이더리움 스마트 계약을 테스트하는 방법](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d)
+- [MolochDAO의 개발자를 위한 단위 테스트 가이드](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide)
+- [록스타처럼 스마트 계약을 테스트하는 방법](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001)
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/upgrading/index.md b/public/content/translations/ko/developers/docs/smart-contracts/upgrading/index.md
new file mode 100644
index 00000000000..05c7dba06ac
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/upgrading/index.md
@@ -0,0 +1,165 @@
+---
+title: "스마트 계약 업그레이드"
+description: "이더리움 스마트 계약의 업그레이드 패턴 개요"
+lang: ko
+---
+
+이더리움의 스마트 계약은 이더리움 가상 머신(EVM)에서 실행되는 자동 실행 프로그램입니다. 이 프로그램은 설계상 불변성을 가지므로 계약이 배포된 후에는 비즈니스 로직을 업데이트할 수 없습니다.
+
+불변성은 스마트 계약의 무신뢰성, 탈중앙화 및 보안에 필수적이지만, 경우에 따라 단점이 될 수 있습니다. 예를 들어, 불변 코드로 인해 개발자가 취약한 계약을 수정하는 것이 불가능할 수 있습니다.
+
+그러나 스마트 계약 개선에 대한 연구가 증가하면서 여러 업그레이드 패턴이 도입되었습니다. 이러한 업그레이드 패턴을 통해 개발자는 비즈니스 로직을 다른 계약에 배치하여 (불변성을 유지하면서) 스마트 계약을 업그레이드할 수 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+[스마트 계약](/developers/docs/smart-contracts/), [스마트 계약 구조](/developers/docs/smart-contracts/anatomy/), [이더리움 가상 머신(EVM)](/developers/docs/evm/)에 대해 잘 이해하고 있어야 합니다. 또한 이 가이드는 독자가 스마트 계약 프로그래밍에 대한 이해가 있다고 가정합니다.
+
+## 스마트 계약 업그레이드란 무엇인가요? {#what-is-a-smart-contract-upgrade}
+
+스마트 계약 업그레이드는 계약의 상태를 보존하면서 스마트 계약의 비즈니스 로직을 변경하는 것을 포함합니다. 특히 스마트 계약의 맥락에서 업그레이드 가능성과 가변성은 동일하지 않다는 점을 명확히 하는 것이 중요합니다.
+
+이더리움 네트워크의 주소에 배포된 프로그램은 여전히 변경할 수 없습니다. 하지만 사용자가 스마트 계약과 상호 작용할 때 실행되는 코드는 변경할 수 있습니다.
+
+다음과 같은 방법을 통해 수행할 수 있습니다.
+
+1. 스마트 계약의 여러 버전을 만들고 이전 계약에서 계약의 새 인스턴스로 상태(즉, 데이터)를 마이그레이션합니다.
+
+2. 비즈니스 로직과 상태를 저장하기 위해 별도의 계약을 생성합니다.
+
+3. 프록시 패턴을 사용하여 불변 프록시 계약에서 수정 가능한 로직 계약으로 함수 호출을 위임합니다.
+
+4. 특정 함수를 실행하기 위해 유연한 위성 계약과 인터페이스하고 의존하는 불변 메인 계약을 생성합니다.
+
+5. 다이아몬드 패턴을 사용하여 프록시 계약에서 로직 계약으로 함수 호출을 위임합니다.
+
+### 업그레이드 메커니즘 #1: 계약 마이그레이션 {#contract-migration}
+
+계약 마이그레이션은 버전 관리를 기반으로 합니다. 이는 동일한 소프트웨어의 고유한 상태를 생성하고 관리하는 개념입니다. 계약 마이그레이션은 기존 스마트 계약의 새 인스턴스를 배포하고 저장 공간과 잔액을 새 계약으로 이전하는 것을 포함합니다.
+
+새로 배포된 계약은 빈 저장 공간을 가지므로 이전 계약에서 데이터를 복구하고 새 구현에 쓸 수 있습니다. 그 후에는 이전 계약과 상호 작용했던 모든 계약을 업데이트하여 새 주소를 반영해야 합니다.
+
+계약 마이그레이션의 마지막 단계는 사용자가 새 계약을 사용하도록 설득하는 것입니다. 새로운 계약 버전은 사용자 잔액과 주소를 유지하여 불변성을 보존합니다. 토큰 기반 계약인 경우 거래소에 연락하여 이전 계약을 폐기하고 새 계약을 사용하도록 해야 합니다.
+
+계약 마이그레이션은 사용자 상호 작용을 방해하지 않고 스마트 계약을 업그레이드하는 비교적 간단하고 안전한 방법입니다. 그러나 사용자 저장 공간과 잔액을 새 계약으로 수동으로 마이그레이션하는 것은 시간이 많이 걸리고 높은 가스 비용이 발생할 수 있습니다.
+
+[계약 마이그레이션에 대해 더 알아보기.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/)
+
+### 업그레이드 메커니즘 #2: 데이터 분리 {#data-separation}
+
+스마트 계약을 업그레이드하는 또 다른 방법은 비즈니스 로직과 데이터 저장 공간을 별도의 계약으로 분리하는 것입니다. 즉, 사용자는 로직 계약과 상호 작용하고 데이터는 저장 공간 계약에 저장됩니다.
+
+로직 계약에는 사용자가 애플리케이션과 상호 작용할 때 실행되는 코드가 포함됩니다. 또한 저장 공간 계약의 주소를 보유하고 이와 상호 작용하여 데이터를 가져오고 설정합니다.
+
+한편, 저장 공간 계약은 사용자 잔액 및 주소와 같은 스마트 계약과 관련된 상태를 보유합니다. 저장 공간 계약은 로직 계약이 소유하며 배포 시 로직 계약의 주소로 구성됩니다. 이를 통해 승인되지 않은 계약이 저장 공간 계약을 호출하거나 데이터를 업데이트하는 것을 방지할 수 있습니다.
+
+기본적으로 저장 공간 계약은 불변이지만, 가리키는 로직 계약을 새로운 구현으로 교체할 수 있습니다. 이렇게 하면 EVM에서 실행되는 코드가 변경되지만 저장 공간과 잔액은 그대로 유지됩니다.
+
+이 업그레이드 방법을 사용하려면 저장 공간 계약에서 로직 계약의 주소를 업데이트해야 합니다. 앞서 설명한 이유로 새 로직 계약을 저장 공간 계약의 주소로 구성해야 합니다.
+
+데이터 분리 패턴은 계약 마이그레이션에 비해 구현하기가 더 쉽다고 할 수 있습니다. 하지만 여러 계약을 관리하고 악의적인 업그레이드로부터 스마트 계약을 보호하기 위해 복잡한 권한 부여 체계를 구현해야 합니다.
+
+### 업그레이드 메커니즘 #3: 프록시 패턴 {#proxy-patterns}
+
+프록시 패턴은 또한 데이터 분리를 사용하여 비즈니스 로직과 데이터를 별도의 계약에 보관합니다. 그러나 프록시 패턴에서는 저장 공간 계약(프록시라고 함)이 코드 실행 중에 로직 계약을 호출합니다. 이것은 로직 계약이 저장 공간 계약을 호출하는 데이터 분리 방법의 반대입니다.
+
+프록시 패턴에서 일어나는 일은 다음과 같습니다.
+
+1. 사용자는 데이터를 저장하지만 비즈니스 로직은 보유하지 않는 프록시 계약과 상호 작용합니다.
+
+2. 프록시 계약은 로직 계약의 주소를 저장하고 `delegatecall` 함수를 사용하여 모든 함수 호출을 로직 계약(비즈니스 로직을 보유함)에 위임합니다.
+
+3. 호출이 로직 계약으로 전달된 후, 로직 계약에서 반환된 데이터는 검색되어 사용자에게 반환됩니다.
+
+프록시 패턴을 사용하려면 **delegatecall** 함수에 대한 이해가 필요합니다. 기본적으로 `delegatecall`은 계약이 다른 계약을 호출할 수 있도록 하는 옵코드이며, 실제 코드 실행은 호출하는 계약의 컨텍스트에서 발생합니다. 프록시 패턴에서 `delegatecall`을 사용하는 것의 한 가지 의미는 프록시 계약이 내부 함수를 호출하는 것처럼 저장 공간을 읽고 쓰며 로직 계약에 저장된 로직을 실행한다는 것입니다.
+
+[Solidity 개발문서](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries)에서:
+
+> _**delegatecall**이라는 특별한 메시지 호출 변형이 존재합니다. 이는 대상 주소의 코드가 호출 계약의 컨텍스트(즉, 주소)에서 실행되고 `msg.sender`와 `msg.value`의 값이 변경되지 않는다는 점을 제외하면 메시지 호출과 동일합니다._ _이는 계약이 런타임에 다른 주소에서 코드를 동적으로 로드할 수 있음을 의미합니다. 저장 공간, 현재 주소 및 잔액은 여전히 호출 계약을 참조하며, 코드는 호출된 주소에서만 가져옵니다._
+
+프록시 계약은 내장된 `fallback` 함수가 있기 때문에 사용자가 함수를 호출할 때마다 `delegatecall`을 호출해야 한다는 것을 알고 있습니다. Solidity 프로그래밍에서 [폴백 함수](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function)는 함수 호출이 계약에 지정된 함수와 일치하지 않을 때 실행됩니다.
+
+프록시 패턴이 작동하려면 프록시 계약이 지원하지 않는 함수 호출을 처리하는 방법을 지정하는 사용자 지정 폴백 함수를 작성해야 합니다. 이 경우 프록시의 폴백 함수는 delegatecall을 시작하고 사용자의 요청을 현재 로직 계약 구현으로 다시 라우팅하도록 프로그래밍됩니다.
+
+프록시 계약은 기본적으로 불변이지만, 업데이트된 비즈니스 로직을 가진 새로운 로직 계약을 만들 수 있습니다. 그런 다음 업그레이드를 수행하는 것은 프록시 계약에서 참조되는 로직 계약의 주소를 변경하는 문제입니다.
+
+프록시 계약이 새로운 로직 계약을 가리키도록 함으로써 사용자가 프록시 계약 함수를 호출할 때 실행되는 코드가 변경됩니다. 이를 통해 사용자에게 새로운 계약과 상호 작용하도록 요청하지 않고도 계약의 로직을 업그레이드할 수 있습니다.
+
+프록시 패턴은 계약 마이그레이션과 관련된 어려움을 없애주기 때문에 스마트 계약을 업그레이드하는 데 널리 사용되는 방법입니다. 그러나 프록시 패턴은 사용하기가 더 복잡하며 부적절하게 사용될 경우 [함수 선택자 충돌](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357)과 같은 치명적인 결함을 유발할 수 있습니다.
+
+[프록시 패턴에 대해 더 알아보기.](https://blog.openzeppelin.com/proxy-patterns/)
+
+### 업그레이드 메커니즘 #4: 전략 패턴 {#strategy-pattern}
+
+이 기술은 특정 기능을 구현하기 위해 다른 프로그램과 인터페이스하는 소프트웨어 프로그램을 만들도록 장려하는 [전략 패턴](https://en.wikipedia.org/wiki/Strategy_pattern)의 영향을 받았습니다. 전략 패턴을 이더리움 개발에 적용하는 것은 다른 계약의 함수를 호출하는 스마트 계약을 구축하는 것을 의미합니다.
+
+이 경우 메인 계약에는 핵심 비즈니스 로직이 포함되어 있지만, 특정 함수를 실행하기 위해 다른 스마트 계약("위성 계약")과 인터페이스합니다. 이 메인 계약은 각 위성 계약의 주소를 저장하고 위성 계약의 다른 구현 간에 전환할 수 있습니다.
+
+새로운 위성 계약을 구축하고 메인 계약을 새 주소로 구성할 수 있습니다. 이를 통해 스마트 계약의 _전략_을 변경(즉, 새로운 로직 구현)할 수 있습니다.
+
+앞서 논의한 프록시 패턴과 유사하지만, 전략 패턴은 사용자가 상호 작용하는 메인 계약이 비즈니스 로직을 보유하기 때문에 다릅니다. 이 패턴을 사용하면 핵심 인프라에 영향을 주지 않고 스마트 계약에 제한적인 변경을 도입할 수 있습니다.
+
+주요 단점은 이 패턴이 주로 사소한 업그레이드를 배포하는 데 유용하다는 것입니다. 또한, 메인 계약이 손상된 경우(예: 해킹) 이 업그레이드 방법을 사용할 수 없습니다.
+
+### 업그레이드 메커니즘 #5: 다이아몬드 패턴 {#diamond-pattern}
+
+다이아몬드 패턴은 프록시 패턴의 개선된 버전으로 간주될 수 있습니다. 다이아몬드 패턴은 다이아몬드 프록시 계약이 하나 이상의 로직 계약에 함수 호출을 위임할 수 있다는 점에서 프록시 패턴과 다릅니다.
+
+다이아몬드 패턴의 로직 계약은 _패싯_으로 알려져 있습니다. 다이아몬드 패턴이 작동하려면 프록시 계약에 [함수 선택자](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector)를 다른 패싯 주소에 매핑하는 매핑을 만들어야 합니다.
+
+사용자가 함수를 호출하면 프록시 계약은 매핑을 확인하여 해당 함수 실행을 담당하는 패싯을 찾습니다. 그런 다음 `delegatecall`(폴백 함수 사용)을 호출하고 해당 로직 계약으로 호출을 리디렉션합니다.
+
+다이아몬드 업그레이드 패턴은 기존 프록시 업그레이드 패턴에 비해 몇 가지 장점이 있습니다.
+
+1. 모든 코드를 변경하지 않고도 계약의 작은 부분을 업그레이드할 수 있습니다. 업그레이드를 위해 프록시 패턴을 사용하려면 사소한 업그레이드라도 완전히 새로운 로직 계약을 만들어야 합니다.
+
+2. 모든 스마트 계약(프록시 패턴에서 사용되는 로직 계약 포함)은 24KB 크기 제한이 있으며, 이는 특히 더 많은 기능이 필요한 복잡한 계약의 경우 제한이 될 수 있습니다. 다이아몬드 패턴은 여러 로직 계약에 함수를 분할하여 이 문제를 쉽게 해결할 수 있습니다.
+
+3. 프록시 패턴은 액세스 제어에 대해 포괄적인 접근 방식을 채택합니다. 업그레이드 함수에 접근할 수 있는 엔티티는 _전체_ 계약을 변경할 수 있습니다. 하지만 다이아몬드 패턴은 모듈식 권한 접근 방식을 가능하게 하여, 스마트 계약 내에서 특정 함수를 업그레이드하는 것을 엔티티에 제한할 수 있습니다.
+
+[다이아몬드 패턴에 대해 더 알아보기](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w).
+
+## 스마트 계약 업그레이드의 장단점 {#pros-and-cons-of-upgrading-smart-contracts}
+
+| 장점 | 단점 |
+| --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
+| 스마트 계약 업그레이드를 통해 배포 후 단계에서 발견된 취약점을 더 쉽게 수정할 수 있습니다. | 스마트 계약을 업그레이드하는 것은 코드 불변성이라는 개념에 위배되며, 이는 탈중앙화와 보안에 영향을 미칩니다. |
+| 개발자는 로직 업그레이드를 사용하여 탈중앙화 애플리케이션에 새로운 기능을 추가할 수 있습니다. | 사용자는 개발자가 스마트 계약을 임의로 수정하지 않을 것이라고 신뢰해야 합니다. |
+| 스마트 계약 업그레이드는 버그를 신속하게 수정할 수 있으므로 최종 사용자의 안전을 향상시킬 수 있습니다. | 스마트 계약에 업그레이드 기능을 프로그래밍하는 것은 또 다른 복잡성을 더하고 치명적인 결함의 가능성을 높입니다. |
+| 계약 업그레이드는 개발자에게 다양한 기능을 실험하고 시간이 지남에 따라 탈중앙화앱을 개선할 수 있는 더 많은 여지를 제공합니다. | 스마트 계약을 업그레이드할 수 있는 기회는 개발자가 개발 단계에서 실사를 수행하지 않고 프로젝트를 더 빨리 출시하도록 장려할 수 있습니다. |
+| | 스마트 계약의 안전하지 않은 접근 제어 또는 중앙 집중화는 악의적인 행위자가 무단 업그레이드를 수행하기 쉽게 만들 수 있습니다. |
+
+## 스마트 계약 업그레이드 시 고려 사항 {#considerations-for-upgrading-smart-contracts}
+
+1. 특히 프록시 패턴, 전략 패턴 또는 데이터 분리를 사용하는 경우 무단 스마트 계약 업그레이드를 방지하기 위해 안전한 접근 제어/권한 부여 메커니즘을 사용하세요. 예를 들어, 계약의 소유자만 호출할 수 있도록 업그레이드 기능에 대한 접근을 제한하는 것입니다.
+
+2. 스마트 계약 업그레이드는 복잡한 활동이며 취약점 도입을 방지하기 위해 높은 수준의 주의가 필요합니다.
+
+3. 업그레이드 구현 프로세스를 탈중앙화하여 신뢰 가정을 줄이세요. [다중 서명 지갑 계약](/developers/docs/smart-contracts/#multisig)을 사용하여 업그레이드를 제어하거나 [DAO 구성원](/dao/)이 업그레이드 승인에 투표하도록 요구하는 전략이 포함될 수 있습니다.
+
+4. 계약 업그레이드에 수반되는 비용을 인지하세요. 예를 들어, 계약 마이그레이션 중에 이전 계약에서 새 계약으로 상태(예: 사용자 잔액)를 복사하는 데 두 개 이상의 트랜잭션이 필요할 수 있으며, 이는 더 많은 가스 수수료를 의미합니다.
+
+5. 사용자를 보호하기 위해 **타임락** 구현을 고려하세요. 타임락은 시스템 변경에 적용되는 지연을 의미합니다. 타임락은 다중 서명 거버넌스 시스템과 결합하여 업그레이드를 제어할 수 있습니다. 제안된 조치가 필요한 승인 임계값에 도달하면 사전 정의된 지연 기간이 경과할 때까지 실행되지 않습니다.
+
+타임락은 사용자가 제안된 변경(예: 로직 업그레이드 또는 새로운 수수료 체계)에 동의하지 않을 경우 시스템을 종료할 시간을 줍니다. 타임락이 없으면 사용자는 개발자가 사전 통지 없이 스마트 계약에 임의의 변경을 구현하지 않을 것이라고 신뢰해야 합니다. 여기서 단점은 타임락이 취약점을 신속하게 패치하는 능력을 제한한다는 것입니다.
+
+## 참고 자료 {#resources}
+
+**OpenZeppelin 업그레이드 플러그인 - _업그레이드 가능한 스마트 계약을 배포하고 보안을 유지하기 위한 도구 모음._**
+
+- [GitHub](https://github.com/OpenZeppelin/openzeppelin-upgrades)
+- [개발문서](https://docs.openzeppelin.com/upgrades)
+
+## 튜토리얼 {#tutorials}
+
+- [스마트 계약 업그레이드하기 | 유튜브 튜토리얼](https://www.youtube.com/watch?v=bdXJmWajZRY) - Patrick Collins
+- [이더리움 스마트 계약 마이그레이션 튜토리얼](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) - Austin Griffith
+- [UUPS 프록시 패턴을 사용한 스마트 계약 업그레이드](https://blog.logrocket.com/author/praneshas/) - Pranesh A.S
+- [Web3 튜토리얼: OpenZeppelin을 사용하여 업그레이드 가능한 스마트 계약(프록시) 작성하기](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) - fangjun.eth
+
+## 더 읽어보기 {#further-reading}
+
+- [스마트 계약 업그레이드의 현황](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) - Santiago Palladino
+- [Solidity 스마트 계약을 업그레이드하는 여러 방법](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - Crypto Market Pool 블로그
+- [학습: 스마트 계약 업그레이드](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - OpenZeppelin 개발문서
+- [Solidity 계약의 업그레이드 가능성을 위한 프록시 패턴: 투명 프록시 vs UUPS 프록시](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) - Naveen Sahu
+- [다이아몬드 업그레이드 작동 방식](https://dev.to/mudgen/how-diamond-upgrades-work-417j) - Nick Mudge
diff --git a/public/content/translations/ko/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/ko/developers/docs/smart-contracts/verifying/index.md
new file mode 100644
index 00000000000..1955e42d22f
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/smart-contracts/verifying/index.md
@@ -0,0 +1,113 @@
+---
+title: "스마트 계약 인증"
+description: "이더리움 스마트 계약의 소스 코드 검증 개요"
+lang: ko
+---
+
+[스마트 계약](/developers/docs/smart-contracts/)은 '무신뢰성(trustless)'을 갖도록 설계되었습니다. 즉, 사용자가 계약과 상호 작용하기 전에 제3자(예: 개발자 및 회사)를 신뢰할 필요가 없다는 것을 의미합니다. 무신뢰성을 위한 전제 조건으로, 사용자와 다른 개발자는 스마트 계약의 소스 코드를 검증할 수 있어야 합니다. 소스 코드 검증은 게시된 계약 코드가 이더리움 블록체인의 계약 주소에서 실행되는 코드와 동일하다는 것을 사용자와 개발자에게 보장합니다.
+
+"소스 코드 검증"과 "[정형 검증](/developers/docs/smart-contracts/formal-verification/)"을 구별하는 것이 중요합니다. 아래에서 자세히 설명하겠지만 소스 코드 검증은 고급 언어(예: Solidity)로 작성된 스마트 계약의 주어진 소스 코드가 계약 주소에서 실행될 바이트코드와 동일하게 컴파일되는지 검증하는 것을 말합니다. 하지만 정형 검증은 스마트 계약의 정확성을 검증하는 것을 의미하며, 이는 계약이 예상대로 작동하는 것을 의미합니다. 문맥에 따라 다르지만, 계약 검증은 일반적으로 소스 코드 검증을 의미합니다.
+
+## 소스 코드 검증이란 무엇인가요? {#what-is-source-code-verification}
+
+[이더리움 가상 머신(EVM)](/developers/docs/evm/)에 스마트 계약을 배포하기 전에 개발자들은 계약의 소스 코드, 즉 [솔리디티](/developers/docs/smart-contracts/languages/) 또는 다른 고급 프로그래밍 언어로 작성된 지침을 바이트코드로 [컴파일](/developers/docs/smart-contracts/compiling/)합니다. EVM은 고급 지침을 해석할 수 없으므로, 소스 코드를 바이트코드(즉, 저수준 기계 명령어)로 컴파일하는 것은 EVM에서 계약 로직을 실행하는 데 필요합니다.
+
+소스 코드 검증은 스마트 계약의 소스 코드와 계약 생성 중에 사용된 컴파일된 바이트코드를 비교하여 차이점을 감지하는 것입니다. 스마트 계약을 검증하는 것이 중요한 이유는 광고된 계약 코드가 블록체인에서 실행되는 것과 다를 수 있기 때문입니다.
+
+스마트 계약 검증을 통해 기계 코드를 읽을 필요 없이 계약이 작성된 고급 언어를 통해 계약이 수행하는 작업을 조사할 수 있습니다. 함수, 값, 그리고 일반적으로 변수 이름과 주석은 컴파일 및 배포된 원본 소스 코드와 동일하게 유지됩니다. 이를 통해 코드를 훨씬 쉽게 읽을 수 있습니다. 소스 검증은 또한 최종 사용자가 스마트 계약이 무엇을 하도록 설계되었는지 알 수 있도록 코드 문서화를 제공합니다.
+
+### 전체 검증이란 무엇인가요? {#full-verification}
+
+소스 코드에는 주석이나 변수 이름과 같이 컴파일된 바이트코드에 영향을 주지 않는 일부 부분이 있습니다. 이는 서로 다른 변수 이름과 다른 주석을 가진 두 개의 소스 코드가 모두 동일한 계약을 검증할 수 있다는 것을 의미합니다. 이로 인해 악의적인 행위자가 소스 코드 내에 기만적인 주석을 추가하거나 오해의 소지가 있는 변수 이름을 부여하고 원본 소스 코드와 다른 소스 코드로 계약을 검증받을 수 있습니다.
+
+소스 코드의 정확성에 대한 _암호화 보증_과 컴파일 정보의 _지문_ 역할을 하도록 바이트코드에 추가 데이터를 추가하여 이를 방지할 수 있습니다. 필요한 정보는 [솔리디티의 계약 메타데이터](https://docs.soliditylang.org/en/v0.8.15/metadata.html)에 있으며, 이 파일의 해시는 계약의 바이트코드에 추가됩니다. [메타데이터 플레이그라운드](https://playground.sourcify.dev)에서 작동하는 것을 볼 수 있습니다.
+
+메타데이터 파일에는 소스 파일과 그 해시를 포함하여 계약의 컴파일에 대한 정보가 포함되어 있습니다. 즉, 컴파일 설정이나 소스 파일 중 하나의 바이트라도 변경되면 메타데이터 파일이 변경됩니다. 결과적으로 바이트코드에 추가되는 메타데이터 파일의 해시도 변경됩니다. 즉, 계약의 바이트코드 + 추가된 메타데이터 해시가 주어진 소스 코드 및 컴파일 설정과 일치하면, 이것이 원본 컴파일에 사용된 소스 코드와 정확히 동일하며 단 한 바이트도 다르지 않다는 것을 확신할 수 있습니다.
+
+메타데이터 해시를 활용하는 이러한 유형의 검증은 **"[전체 검증](https://docs.sourcify.dev/docs/full-vs-partial-match/)"**(또는 "완벽한 검증")이라고 합니다. 메타데이터 해시가 일치하지 않거나 검증에서 고려되지 않으면 "부분 일치"가 되며, 이는 현재 계약을 검증하는 더 일반적인 방법입니다. 전체 검증 없이는 검증된 소스 코드에 반영되지 않는 [악성 코드](https://samczsun.com/hiding-in-plain-sight/)를 삽입하는 것이 가능합니다. 대부분의 개발자는 전체 검증을 인지하지 못하고 컴파일의 메타데이터 파일을 보관하지 않으므로, 지금까지 부분 검증이 계약을 검증하는 사실상의 방법이었습니다.
+
+## 소스 코드 검증이 왜 중요한가요? {#importance-of-source-code-verification}
+
+### 무신뢰성 {#trustlessness}
+
+무신뢰성은 스마트 계약과 [탈중앙화 애플리케이션(탈중앙화앱)](/developers/docs/dapps/)의 가장 큰 전제라고 할 수 있습니다. 스마트 계약은 “불변”이며 변경할 수 없습니다. 계약은 배포 시점에 코드에 정의된 비즈니스 로직만 실행합니다. 이는 개발자와 기업이 이더리움에 배포한 후 계약 코드를 변조할 수 없음을 의미합니다.
+
+스마트 계약이 무신뢰성을 가지려면 계약 코드를 독립적으로 검증할 수 있어야 합니다. 모든 스마트 계약의 컴파일된 바이트코드는 블록체인에 공개적으로 사용할 수 있지만, 저수준 언어는 개발자와 사용자 모두에게 이해하기 어렵습니다.
+
+프로젝트는 계약의 소스 코드를 게시하여 신뢰 가정을 줄입니다. 하지만 이는 또 다른 문제로 이어집니다. 게시된 소스 코드가 계약 바이트코드와 일치하는지 확인하기 어렵다는 것입니다. 이 시나리오에서는 사용자가 개발자가 블록체인에 배포하기 전에 계약의 비즈니스 로직(즉, 바이트코드를 변경)을 변경하지 않을 것이라고 신뢰해야 하므로 무신뢰성의 가치가 상실됩니다.
+
+소스 코드 검증 도구는 스마트 계약의 소스 코드 파일이 어셈블리 코드와 일치함을 보장합니다. 그 결과 사용자가 제3자를 맹목적으로 신뢰하지 않고 계약에 자금을 예치하기 전에 코드를 검증하는 무신뢰 생태계가 만들어집니다.
+
+### 사용자 안전 {#user-safety}
+
+스마트 계약에는 일반적으로 많은 돈이 걸려 있습니다. 따라서 스마트 계약을 사용하기 전에 더 높은 보안 보장과 로직 검증이 필요합니다. 문제는 비양심적인 개발자가 스마트 계약에 악성 코드를 삽입하여 사용자를 속일 수 있다는 것입니다. 검증 없이는 악성 스마트 계약에 [백도어](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts), 논란의 여지가 있는 접근 제어 메커니즘, 악용 가능한 취약점 및 감지되지 않은 채 사용자 안전을 위협하는 기타 사항들이 있을 수 있습니다.
+
+스마트 계약의 소스 코드 파일을 게시하면 감사자와 같은 이해관계자들이 잠재적인 공격 벡터에 대해 계약을 평가하기가 더 쉬워집니다. 여러 당사자가 독립적으로 스마트 계약을 검증함으로써 사용자는 보안에 대한 더 강력한 보증을 받게 됩니다.
+
+## 이더리움 스마트 계약의 소스 코드를 검증하는 방법 {#source-code-verification-for-ethereum-smart-contracts}
+
+[이더리움에 스마트 계약 배포](/developers/docs/smart-contracts/deploying/)는 데이터 페이로드(컴파일된 바이트코드)가 포함된 트랜잭션을 특수 주소로 보내야 합니다. 데이터 페이로드는 소스 코드를 컴파일하여 생성되며, 여기에 트랜잭션의 데이터 페이로드에 추가된 계약 인스턴스의 [생성자 인수](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor)가 더해집니다. 컴파일은 결정론적입니다. 즉, 동일한 소스 파일과 컴파일 설정(예: 컴파일러 버전, 최적화 프로그램)이 사용되는 경우 항상 동일한 출력(즉, 계약 바이트코드)을 생성합니다.
+
+
+
+스마트 계약을 검증하는 것은 기본적으로 다음 단계를 포함합니다:
+
+1. 컴파일러에 소스 파일과 컴파일 설정을 입력합니다.
+
+2. 컴파일러는 계약의 바이트코드를 출력합니다.
+
+3. 지정된 주소에서 배포된 계약의 바이트코드를 가져옵니다.
+
+4. 배포된 바이트코드를 다시 컴파일된 바이트코드와 비교합니다. 코드가 일치하면 계약은 주어진 소스 코드와 컴파일 설정으로 검증됩니다.
+
+5. 추가로, 바이트코드 끝에 있는 메타데이터 해시가 일치하면 전체 일치가 됩니다.
+
+이는 검증에 대한 단순한 설명이며, [불변 변수](https://docs.sourcify.dev/docs/immutables/)를 갖는 것과 같이 이 방법으로 작동하지 않는 많은 예외가 있다는 점에 유의하세요.
+
+## 소스 코드 검증 도구 {#source-code-verification-tools}
+
+계약을 검증하는 전통적인 프로세스는 복잡할 수 있습니다. 이것이 이더리움에 배포된 스마트 계약의 소스 코드를 검증하기 위한 도구가 있는 이유입니다. 이러한 도구는 소스 코드 검증의 많은 부분을 자동화하고 사용자의 이익을 위해 검증된 계약을 큐레이션합니다.
+
+### Etherscan {#etherscan}
+
+주로 [이더리움 블록체인 탐색기](/developers/docs/data-and-analytics/block-explorers/)로 알려져 있지만, Etherscan은 스마트 계약 개발자와 사용자를 위한 [소스 코드 검증 서비스](https://etherscan.io/verifyContract)도 제공합니다.
+
+Etherscan을 사용하면 원본 데이터 페이로드(소스 코드, 라이브러리 주소, 컴파일러 설정, 계약 주소 등)에서 계약 바이트코드를 다시 컴파일할 수 있습니다. 다시 컴파일된 바이트코드가 온체인 계약의 바이트코드(및 생성자 매개변수)와 연결되면 [계약이 검증됩니다](https://info.etherscan.com/types-of-contract-verification/).
+
+검증이 완료되면 계약의 소스 코드는 "검증됨" 라벨을 받고 다른 사람들이 감사할 수 있도록 Etherscan에 게시됩니다. 또한 검증된 소스 코드가 있는 스마트 계약의 저장소인 [검증된 계약](https://etherscan.io/contractsVerified/) 섹션에도 추가됩니다.
+
+Etherscan은 계약을 검증하는 데 가장 많이 사용되는 도구입니다. 그러나 Etherscan의 계약 검증에는 단점이 있습니다. 온체인 바이트코드와 재컴파일된 바이트코드의 **메타데이터 해시**를 비교하지 못합니다. 따라서 Etherscan에서의 일치는 부분 일치입니다.
+
+[Etherscan에서 계약 검증에 대해 더 알아보기](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327).
+
+### Blockscout {#blockscout}
+
+[Blockscout](https://blockscout.com/)은 오픈소스 블록체인 탐색기로 스마트 계약 개발자와 사용자를 위한 [계약 검증 서비스](https://eth.blockscout.com/contract-verification)도 제공합니다. 오픈 소스 대안으로서 Blockscout은 검증이 수행되는 방식의 투명성을 제공하고 커뮤니티가 검증 프로세스를 개선하는 데 기여할 수 있도록 합니다.
+
+다른 검증 서비스와 마찬가지로 Blockscout을 사용하면 바이트코드를 다시 컴파일하고 배포된 계약과 비교하여 계약의 소스 코드를 검증할 수 있습니다. 검증이 완료되면 계약은 검증 상태를 받게 되며 소스 코드는 감사 및 상호 작용을 위해 공개적으로 사용할 수 있게 됩니다. 검증된 계약은 쉽게 찾아보고 발견할 수 있도록 Blockscout의 [검증된 계약 저장소](https://eth.blockscout.com/verified-contracts)에도 나열됩니다.
+
+### Sourcify {#sourcify}
+
+[Sourcify](https://sourcify.dev/#/verifier)는 오픈 소스이고 분산된 또 다른 계약 검증 도구입니다. 이것은 블록 탐색기가 아니며 [다양한 EVM 기반 네트워크](https://docs.sourcify.dev/docs/chains)에서 계약만 검증합니다. 이는 다른 도구가 그 위에 구축할 수 있는 공용 인프라 역할을 하며, 메타데이터 파일에 있는 [ABI](/developers/docs/smart-contracts/compiling/#web-applications) 및 [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) 주석을 사용하여 보다 인간 친화적인 계약 상호 작용을 가능하게 하는 것을 목표로 합니다.
+
+Etherscan과 달리 Sourcify는 메타데이터 해시와의 전체 일치를 지원합니다. 검증된 계약은 HTTP 및 분산된 [콘텐츠 주소 지정](https://docs.storacha.network/concepts/content-addressing/) 스토리지인 [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs)의 [공개 리포지토리](https://docs.sourcify.dev/docs/repository/)에서 제공됩니다. 추가된 메타데이터 해시가 IPFS 해시이므로 이를 통해 IPFS를 통해 계약의 메타데이터 파일을 가져올 수 있습니다.
+
+또한 이 파일들의 IPFS 해시도 메타데이터에서 찾을 수 있으므로 IPFS를 통해 소스 코드 파일을 검색할 수도 있습니다. API 또는 [UI](https://sourcify.dev/#/verifier)를 통해 메타데이터 파일과 소스 파일을 제공하거나 플러그인을 사용하여 계약을 확인할 수 있습니다. Sourcify 모니터링 도구는 또한 새 블록에서 계약 생성을 수신하고 메타데이터 및 소스 파일이 IPFS에 게시된 경우 계약을 확인하려고 시도합니다.
+
+[Sourcify에서 계약 검증에 대해 더 알아보기](https://soliditylang.org/blog/2020/06/25/sourcify-faq/).
+
+### Tenderly {#tenderly}
+
+[Tenderly 플랫폼](https://tenderly.co/)은 웹3 개발자가 스마트 계약을 구축, 테스트, 모니터링 및 운영할 수 있도록 합니다. 디버깅 도구와 관찰 가능성 및 인프라 구성 요소를 결합하여 Tenderly는 개발자가 스마트 계약 개발을 가속화하도록 돕습니다. Tenderly 기능을 완전히 활성화하려면 개발자는 여러 방법을 사용하여 [소스 코드 검증을 수행](https://docs.tenderly.co/monitoring/contract-verification)해야 합니다.
+
+계약을 비공개 또는 공개적으로 확인할 수 있습니다. 비공개로 확인된 경우 스마트 계약은 귀하(및 프로젝트의 다른 구성원)에게만 표시됩니다. 계약을 공개적으로 확인하면 Tenderly 플랫폼을 사용하는 모든 사람이 볼 수 있습니다.
+
+[대시보드](https://docs.tenderly.co/contract-verification), [Tenderly Hardhat 플러그인](https://docs.tenderly.co/contract-verification/hardhat) 또는 [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli)를 사용하여 계약을 확인할 수 있습니다.
+
+대시보드를 통해 계약을 확인할 때 Solidity 컴파일러에서 생성된 소스 파일 또는 메타데이터 파일, 주소/네트워크 및 컴파일러 설정을 가져와야 합니다.
+
+Tenderly Hardhat 플러그인을 사용하면 더 적은 노력으로 검증 프로세스를 더 많이 제어할 수 있으므로 자동(코드 없음) 및 수동(코드 기반) 검증 중에서 선택할 수 있습니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [계약 소스 코드 검증](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/)
diff --git a/public/content/translations/ko/developers/docs/standards/index.md b/public/content/translations/ko/developers/docs/standards/index.md
new file mode 100644
index 00000000000..2067fd392a2
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/index.md
@@ -0,0 +1,59 @@
+---
+title: "이더리움 개발 표준"
+description: "EIP, ERC-20, ERC-721과 같은 토큰 표준, 개발 컨벤션을 포함한 이더리움 표준에 대해 알아보세요."
+lang: ko
+incomplete: true
+---
+
+## 표준 개요 {#standards-overview}
+
+이더리움 커뮤니티는 [이더리움 클라이언트](/developers/docs/nodes-and-clients/) 및 지갑과 같은 프로젝트가 여러 구현에서 상호 운용성을 유지하고 스마트 계약과 탈중앙화앱이 구성 가능하도록 유지하는 데 도움이 되는 많은 표준을 채택했습니다.
+
+일반적으로 표준은 [이더리움 개선 제안](/eips/)(EIP)으로 도입되며, 이는 [표준 절차](https://eips.ethereum.org/EIPS/eip-1)를 통해 커뮤니티 구성원들이 논의합니다.
+
+- [EIP 소개](/eips/)
+- [EIP 목록](https://eips.ethereum.org/)
+- [EIP GitHub 리포지토리](https://github.com/ethereum/EIPs)
+- [EIP 토론 게시판](https://ethereum-magicians.org/c/eips)
+- [이더리움 거버넌스 소개](/governance/)
+- [이더리움 거버넌스 개요](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _2019년 3월 31일 - Boris Mann_
+- [이더리움 프로토콜 개발 거버넌스 및 네트워크 업그레이드 조정](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _2020년 3월 23일 - Hudson Jameson_
+- [모든 이더리움 코어 개발자 회의 재생목록](https://www.youtube.com/@EthereumProtocol) _(YouTube 재생목록)_
+
+## 표준의 유형 {#types-of-standards}
+
+EIP에는 3가지 유형이 있습니다:
+
+- 표준 트랙: 대부분 또는 모든 이더리움 구현에 영향을 미치는 변경 사항을 설명합니다
+- [메타 트랙](https://eips.ethereum.org/meta): 이더리움 관련 프로세스를 설명하거나 프로세스 변경을 제안합니다
+- [정보 트랙](https://eips.ethereum.org/informational): 이더리움 설계 문제를 설명하거나 이더리움 커뮤니티에 일반적인 가이드라인이나 정보를 제공합니다
+
+또한 표준 트랙은 4가지 카테고리로 세분화됩니다:
+
+- [코어](https://eips.ethereum.org/core): 합의 포크가 필요한 개선 사항
+- [네트워킹](https://eips.ethereum.org/networking): devp2p 및 라이트 이더리움 하위 프로토콜 관련 개선 사항, 그리고 위스퍼 및 스웜의 네트워크 프로토콜 사양에 대한 제안된 개선 사항.
+- [인터페이스](https://eips.ethereum.org/interface): 클라이언트 API/RPC 사양 및 표준 관련 개선 사항, 그리고 메서드 이름 및 계약 ABI와 같은 특정 언어 수준 표준.
+- [ERC](https://eips.ethereum.org/erc): 애플리케이션 수준의 표준 및 관례
+
+이러한 다양한 유형 및 카테고리에 대한 자세한 정보는 [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types)에서 확인할 수 있습니다
+
+### 토큰 표준 {#token-standards}
+
+- [ERC-20](/developers/docs/standards/tokens/erc-20/) - 투표 토큰, 스테이킹 토큰 또는 가상 화폐와 같은 대체 가능한(상호 교환 가능한) 토큰을 위한 표준 인터페이스입니다.
+ - [ERC-223](/developers/docs/standards/tokens/erc-223/) - 토큰이 이더와 동일하게 작동하도록 하고 수신자 측에서 토큰 전송 처리를 지원하는 대체 가능한 토큰 표준입니다.
+ - [ERC-1363](/developers/docs/standards/tokens/erc-1363/) - 단일 트랜잭션에서 수신자 계약에 대한 콜백 실행을 지원하는 ERC-20 토큰의 확장 인터페이스입니다.
+- [ERC-721](/developers/docs/standards/tokens/erc-721/) - 예술품이나 노래의 증서와 같은 대체 불가능한 토큰을 위한 표준 인터페이스입니다.
+ - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - 연속적인 토큰 식별자를 사용하여 하나 또는 여러 개의 대체 불가능한 토큰을 생성/전송할 때 방출되는 표준화된 이벤트입니다.
+ - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - EIP-721 소비자 역할을 위한 인터페이스 확장입니다.
+ - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - ERC-721 토큰에 제한된 권한을 가진 시간 제한 역할을 추가합니다.
+- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **(권장되지 않음)** ERC-20을 개선한 토큰 표준입니다.
+- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - 대체 가능한 자산과 대체 불가능한 자산을 모두 포함할 수 있는 토큰 표준입니다.
+- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - 수익률 생성 볼트의 기술적 파라미터를 최적화하고 통합하도록 설계된 토큰화된 볼트 표준입니다.
+
+[토큰 표준](/developers/docs/standards/tokens/)에 대해 더 자세히 알아보세요.
+
+## 더 읽어보기 {#further-reading}
+
+- [이더리움 개선 제안(EIP)](/eips/)
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-1155/index.md
new file mode 100644
index 00000000000..4c6f68f331f
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-1155/index.md
@@ -0,0 +1,146 @@
+---
+title: "ERC-1155 멀티 토큰 표준"
+description: "단일 계약에서 대체 가능 토큰과 대체 불가 토큰을 결합하는 멀티 토큰 표준인 ERC-1155에 대해 알아보세요."
+lang: ko
+---
+
+## 소개 {#introduction}
+
+여러 토큰 유형을 관리하는 계약을 위한 표준 인터페이스입니다. 배포된 단일 계약은 대체 가능 토큰, 대체 불가 토큰 또는 기타 구성(예: 준대체 가능 토큰)의 모든 조합을 포함할 수 있습니다.
+
+**멀티 토큰 표준이란 무엇인가요?**
+
+이 아이디어는 간단하며, 모든 수의 대체 가능 토큰 유형과 대체 불가 토큰 유형을 나타내고 제어할 수 있는 스마트 계약 인터페이스를 만드는 것을 목표로 합니다. 이러한 방식으로 ERC-1155 토큰은 [ERC-20](/developers/docs/standards/tokens/erc-20/) 및 [ERC-721](/developers/docs/standards/tokens/erc-721/) 토큰과 동일한 기능을 수행할 수 있으며, 심지어 동시에 두 가지 기능 모두를 수행할 수도 있습니다. ERC-20 및 ERC-721 표준의 기능을 모두 개선하여 더 효율적이고 명백한 구현 오류를 수정합니다.
+
+ERC-1155 토큰은 [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155)에 자세히 설명되어 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 [토큰 표준](/developers/docs/standards/tokens/), [ERC-20](/developers/docs/standards/tokens/erc-20/), [ERC-721](/developers/docs/standards/tokens/erc-721/)에 대해 읽어보시는 것을 권장합니다.
+
+## ERC-1155의 기능과 특징: {#body}
+
+- [일괄 전송](#batch_transfers): 단일 호출로 여러 자산을 전송합니다.
+- [일괄 잔액 조회](#batch_balance): 단일 호출로 여러 자산의 잔액을 조회합니다.
+- [일괄 승인](#batch_approval): 주소에 모든 토큰을 승인합니다.
+- [훅](#receive_hook): 토큰 수신 훅입니다.
+- [NFT 지원](#nft_support): 공급량이 1인 경우 NFT로 취급합니다.
+- [안전 전송 규칙](#safe_transfer_rule): 안전한 전송을 위한 규칙 집합입니다.
+
+### 일괄 전송 {#batch-transfers}
+
+일괄 전송은 일반적인 ERC-20 전송과 매우 유사하게 작동합니다. 일반적인 ERC-20의 `transferFrom` 함수를 살펴보겠습니다.
+
+```solidity
+// ERC-20
+function transferFrom(address from, address to, uint256 value) external returns (bool);
+
+// ERC-1155
+function safeBatchTransferFrom(
+ address _from,
+ address _to,
+ uint256[] calldata _ids,
+ uint256[] calldata _values,
+ bytes calldata _data
+) external;
+```
+
+ERC-1155의 유일한 차이점은 값을 배열로 전달하고, ID 배열도 전달한다는 것입니다. 예를 들어, `ids=[3, 6, 13]`과 `values=[100, 200, 5]`가 주어지면 결과적인 전송은 다음과 같습니다.
+
+1. `_from`에서 `_to`로 ID가 3인 토큰 100개를 전송합니다.
+2. `_from`에서 `_to`로 ID가 6인 토큰 200개를 전송합니다.
+3. `_from`에서 `_to`로 ID가 13인 토큰 5개를 전송합니다.
+
+ERC-1155에는 `transfer`는 없고 `transferFrom`만 있습니다. 일반 `transfer`처럼 사용하려면, from 주소를 함수를 호출하는 주소로 설정하기만 하면 됩니다.
+
+### 일괄 잔액 조회 {#batch-balance}
+
+각각의 ERC-20 `balanceOf` 호출에도 마찬가지로 일괄 처리를 지원하는 파트너 함수가 있습니다. 참고로, ERC-20 버전은 다음과 같습니다.
+
+```solidity
+// ERC-20
+function balanceOf(address owner) external view returns (uint256);
+
+// ERC-1155
+function balanceOfBatch(
+ address[] calldata _owners,
+ uint256[] calldata _ids
+) external view returns (uint256[] memory);
+```
+
+잔액 호출의 경우, 단일 호출로 여러 잔액을 훨씬 간단하게 검색할 수 있습니다. 소유자 배열을 전달하고, 이어서 토큰 ID 배열을 전달합니다.
+
+예를 들어 `_ids=[3, 6, 13]`과 `_owners=[0xbeef..., 0x1337..., 0x1111...]`가 주어지면 반환 값은 다음과 같습니다.
+
+```solidity
+[
+ balanceOf(0xbeef...),
+ balanceOf(0x1337...),
+ balanceOf(0x1111...)
+]
+```
+
+### 일괄 승인 {#batch-approval}
+
+```solidity
+// ERC-1155
+function setApprovalForAll(
+ address _operator,
+ bool _approved
+) external;
+
+function isApprovedForAll(
+ address _owner,
+ address _operator
+) external view returns (bool);
+```
+
+승인은 ERC-20과 약간 다릅니다. 특정 금액을 승인하는 대신 `setApprovalForAll`을 통해 운영자를 승인 또는 미승인으로 설정합니다.
+
+현재 상태는 `isApprovedForAll`을 통해 확인할 수 있습니다. 보시다시피, 이것은 전부 아니면 전무 방식의 작업입니다. 승인할 토큰 수나 토큰 클래스를 정의할 수 없습니다.
+
+이것은 단순함을 염두에 두고 의도적으로 설계되었습니다. 하나의 주소에 대해서만 모든 것을 승인할 수 있습니다.
+
+### 수신 훅 {#receive-hook}
+
+```solidity
+function onERC1155BatchReceived(
+ address _operator,
+ address _from,
+ uint256[] calldata _ids,
+ uint256[] calldata _values,
+ bytes calldata _data
+) external returns(bytes4);
+```
+
+[EIP-165](https://eips.ethereum.org/EIPS/eip-165) 지원에 따라, ERC-1155는 스마트 계약에 대해서만 수신 훅을 지원합니다. 훅 함수는 다음과 같이 지정된 미리 정의된 특정 bytes4 값을 반환해야 합니다.
+
+```solidity
+bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))
+```
+
+수신 계약이 이 값을 반환하면, 해당 계약이 전송을 수락하고 ERC-1155 토큰을 처리하는 방법을 알고 있는 것으로 간주됩니다. 더 이상 계약에 토큰이 묶이는 일이 없습니다!
+
+### NFT 지원 {#nft-support}
+
+공급량이 1일 때, 토큰은 본질적으로 대체 불가 토큰(NFT)입니다. 또한 ERC-721의 표준과 마찬가지로, 메타데이터 URL을 정의할 수 있습니다. 클라이언트가 URL을 읽고 수정할 수 있습니다. 자세한 내용은 [여기](https://eips.ethereum.org/EIPS/eip-1155#metadata)를 참조하세요.
+
+### 안전 전송 규칙 {#safe-transfer-rule}
+
+앞선 설명에서 이미 몇 가지 안전 전송 규칙을 다루었습니다. 하지만 가장 중요한 규칙들을 살펴보겠습니다.
+
+1. 호출자는 `_from` 주소의 토큰을 사용할 수 있도록 승인받았거나, 호출자가 `_from`과 같아야 합니다.
+2. 다음과 같은 경우 전송 호출이 되돌려져야 합니다.
+ 1. `_to` 주소가 0인 경우.
+ 2. `_ids`의 길이가 `_values`의 길이와 같지 않은 경우.
+ 3. `_ids`에 있는 토큰 보유자의 잔액 중 어느 하나라도 수신자에게 전송된 `_values`의 해당 금액보다 낮은 경우.
+ 4. 기타 오류가 발생하는 경우.
+
+_참고_: 훅을 포함한 모든 일괄 함수는 일괄 처리 기능이 없는 버전으로도 존재합니다. 단일 자산을 전송하는 것이 여전히 가장 보편적으로 사용되는 방법일 가능성이 높다는 점을 고려할 때, 이는 가스 효율성을 위한 것입니다. 설명을 간단하게 하기 위해 안전 전송 규칙을 포함한 해당 내용들을 생략했습니다. 이름은 동일하며, 'Batch'만 제거하면 됩니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [EIP-1155: 멀티 토큰 표준](https://eips.ethereum.org/EIPS/eip-1155)
+- [ERC-1155: Openzeppelin 문서](https://docs.openzeppelin.com/contracts/5.x/erc1155)
+- [ERC-1155: GitHub 저장소](https://github.com/enjin/erc-1155)
+- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-1363/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-1363/index.md
new file mode 100644
index 00000000000..16e5314e34b
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-1363/index.md
@@ -0,0 +1,82 @@
+---
+title: "ERC-1363 지불 가능 토큰 표준"
+description: "ERC-1363은 단일 트랜잭션 내에서 전송 후 수신자 계약에서 또는 승인 후 지출자 계약에서 맞춤형 로직 실행을 지원하는 ERC-20 토큰의 확장 인터페이스입니다."
+lang: ko
+---
+
+## 소개 {#introduction}
+
+### ERC-1363은 무엇인가요? {#what-is-erc1363}
+
+ERC-1363은 단일 트랜잭션 내에서 전송 후 수신자 계약에서 또는 승인 후 지출자 계약에서 맞춤형 로직 실행을 지원하는 ERC-20 토큰의 확장 인터페이스입니다.
+
+### ERC-20과의 차이점 {#erc20-differences}
+
+`transfer`, `transferFrom` 및 `approve`와 같은 표준 ERC-20 작업은 별도의 트랜잭션 없이는 수신자 또는 지출자 계약에서 코드 실행을 허용하지 않습니다.
+사용자는 첫 번째 트랜잭션을 실행한 다음 두 번째 트랜잭션을 제출해야 하므로 이는 UI 개발의 복잡성을 가중시키고 채택에 마찰을 일으킵니다.
+또한 가스를 두 번 지불해야 합니다.
+
+ERC-1363을 사용하면 대체 가능 토큰이 더 쉽게 작업을 수행하고 오프체인 리스너 없이 작동할 수 있습니다.
+단일 트랜잭션에서 전송 또는 승인 후 수신자 또는 지출자 계약에 대한 콜백을 수행할 수 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 다음에 대해 읽어보는 것을 권장합니다.
+
+- [토큰 표준](/developers/docs/standards/tokens/)
+- [ERC-20](/developers/docs/standards/tokens/erc-20/)
+
+## 본문 {#body}
+
+ERC-1363은 `transfer`, `transferFrom` 또는 `approve` 이후 ERC-20 토큰이 스마트 계약과 상호 작용할 수 있는 표준 API를 도입합니다.
+
+이 표준은 토큰을 전송하는 기본 기능을 제공하며, 토큰이 다른 온체인 제3자에 의해 사용될 수 있도록 승인한 다음 수신자 또는 지출자 계약에 대한 콜백을 수행할 수 있도록 합니다.
+
+ERC-20 콜백을 수락할 수 있는 스마트 계약의 제안된 용도가 많이 있습니다.
+
+예는 다음과 같습니다.
+
+- **크라우드세일**: 전송된 토큰이 즉시 보상 할당을 트리거합니다.
+- **서비스**: 결제로 한 단계에서 서비스 액세스가 활성화됩니다.
+- **인보이스**: 토큰이 자동으로 인보이스를 정산합니다.
+- **구독**: 연간 요금을 승인하면 첫 달 결제 내에서 구독이 활성화됩니다.
+
+이러한 이유로 원래 \*\*\"Payable Token\"\*\*이라고 명명되었습니다.
+
+콜백 동작은 유틸리티를 더욱 확장하여 다음과 같은 원활한 상호 작용을 가능하게 합니다.
+
+- **스테이킹**: 전송된 토큰이 스테이킹 계약에서 자동 잠금을 트리거합니다.
+- **투표**: 수신된 토큰이 거버넌스 시스템에 투표를 등록합니다.
+- **스왑**: 토큰 승인으로 한 단계에서 스왑 로직이 활성화됩니다.
+
+ERC-1363 토큰은 전송 또는 승인 수신 후 콜백을 실행해야 하는 모든 경우에 특정 유틸리티에 사용될 수 있습니다.
+ERC-1363은 수신자의 토큰 처리 능력을 확인함으로써 스마트 계약에서 토큰 손실이나 토큰 잠김을 방지하는 데에도 유용합니다.
+
+다른 ERC-20 확장 제안과 달리, ERC-1363은 ERC-20 `transfer` 및 `transferFrom` 메서드를 재정의하지 않고 ERC-20과의 하위 호환성을 유지하면서 구현할 인터페이스 ID를 정의합니다.
+
+[EIP-1363](https://eips.ethereum.org/EIPS/eip-1363)에서:
+
+### 메서드 {#methods}
+
+ERC-1363 표준을 구현하는 스마트 계약은 `ERC1363` 인터페이스의 모든 함수와 `ERC20` 및 `ERC165` 인터페이스를 **반드시** 구현해야 합니다.
+
+```solidity
+pragma solidity ^0.8.0;\n\n/**\n * @title ERC1363\n * @dev 단일 트랜잭션에서 `transfer` 또는 `transferFrom` 후 수신자 계약에서 코드를 실행하거나, `approve` 후 지출자 계약에서 코드를 실행하는 것을 지원하는 ERC-20 토큰의 확장 인터페이스입니다.\n */\ninterface ERC1363 is ERC20, ERC165 {\n /*\n * 참고: 이 인터페이스의 ERC-165 식별자는 0xb0202a11입니다.\n * 0xb0202a11 ===\n * bytes4(keccak256('transferAndCall(address,uint256)')) ^\n * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^\n * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^\n * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^\n * bytes4(keccak256('approveAndCall(address,uint256)')) ^\n * bytes4(keccak256('approveAndCall(address,uint256,bytes)'))\n */\n\n /**\n * @dev 호출자의 계정에서 `to`로 `value` 양의 토큰을 이동시킨 다음\n * `to`에서 `ERC1363Receiver::onTransferReceived`를 호출합니다.\n * @param to 토큰이 전송될 주소입니다.\n * @param value 전송될 토큰의 양입니다.\n * @return 예외를 발생시키지 않는 한 작업이 성공했음을 나타내는 불리언 값입니다.\n */\n function transferAndCall(address to, uint256 value) external returns (bool);\n\n /**\n * @dev 호출자의 계정에서 `to`로 `value` 양의 토큰을 이동시킨 다음\n * `to`에서 `ERC1363Receiver::onTransferReceived`를 호출합니다.\n * @param to 토큰이 전송될 주소입니다.\n * @param value 전송될 토큰의 양입니다.\n * @param data 지정된 형식이 없는 추가 데이터로, `to`를 호출할 때 전송됩니다.\n * @return 예외를 발생시키지 않는 한 작업이 성공했음을 나타내는 불리언 값입니다.\n */\n function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool);\n\n /**\n * @dev 허용량 메커니즘을 사용하여 `from`에서 `to`로 `value` 양의 토큰을 이동시킨 다음\n * `to`에서 `ERC1363Receiver::onTransferReceived`를 호출합니다.\n * @param from 토큰을 보낼 주소입니다.\n * @param to 토큰이 전송될 주소입니다.\n * @param value 전송될 토큰의 양입니다.\n * @return 예외를 발생시키지 않는 한 작업이 성공했음을 나타내는 불리언 값입니다.\n */\n function transferFromAndCall(address from, address to, uint256 value) external returns (bool);\n\n /**\n * @dev 허용량 메커니즘을 사용하여 `from`에서 `to`로 `value` 양의 토큰을 이동시킨 다음\n * `to`에서 `ERC1363Receiver::onTransferReceived`를 호출합니다.\n * @param from 토큰을 보낼 주소입니다.\n * @param to 토큰이 전송될 주소입니다.\n * @param value 전송될 토큰의 양입니다.\n * @param data 지정된 형식이 없는 추가 데이터로, `to`를 호출할 때 전송됩니다.\n * @return 예외를 발생시키지 않는 한 작업이 성공했음을 나타내는 불리언 값입니다.\n */\n function transferFromAndCall(address from, address to, uint256 value, bytes calldata data) external returns (bool);\n\n /**\n * @dev 호출자의 토큰에 대해 `spender`의 허용량으로 `value` 양의 토큰을 설정한 다음\n * `spender`에서 `ERC1363Spender::onApprovalReceived`를 호출합니다.\n * @param spender 자금을 사용할 주소입니다.\n * @param value 사용될 토큰의 양입니다.\n * @return 예외를 발생시키지 않는 한 작업이 성공했음을 나타내는 불리언 값입니다.\n */\n function approveAndCall(address spender, uint256 value) external returns (bool);\n\n /**\n * @dev 호출자의 토큰에 대해 `spender`의 허용량으로 `value` 양의 토큰을 설정한 다음\n * `spender`에서 `ERC1363Spender::onApprovalReceived`를 호출합니다.\n * @param spender 자금을 사용할 주소입니다.\n * @param value 사용될 토큰의 양입니다.\n * @param data 지정된 형식이 없는 추가 데이터로, `spender`를 호출할 때 전송됩니다.\n * @return 예외를 발생시키지 않는 한 작업이 성공했음을 나타내는 불리언 값입니다.\n */\n function approveAndCall(address spender, uint256 value, bytes calldata data) external returns (bool);\n}\n\ninterface ERC20 {\n event Transfer(address indexed from, address indexed to, uint256 value);\n event Approval(address indexed owner, address indexed spender, uint256 value);\n function transfer(address to, uint256 value) external returns (bool);\n function transferFrom(address from, address to, uint256 value) external returns (bool);\n function approve(address spender, uint256 value) external returns (bool);\n function totalSupply() external view returns (uint256);\n function balanceOf(address account) external view returns (uint256);\n function allowance(address owner, address spender) external view returns (uint256);\n}\n\ninterface ERC165 {\n function supportsInterface(bytes4 interfaceId) external view returns (bool);\n}
+```
+
+`transferAndCall` 또는 `transferFromAndCall`을 통해 ERC-1363 토큰을 수락하려는 스마트 계약은 `ERC1363Receiver` 인터페이스를 **반드시** 구현해야 합니다.
+
+```solidity
+/**\n * @title ERC1363Receiver\n * @dev ERC-1363 토큰 계약에서 `transferAndCall` 또는 `transferFromAndCall`을 지원하려는 모든 계약을 위한 인터페이스입니다.\n */\ninterface ERC1363Receiver {\n /**\n * @dev `operator`가 `from`에서 `ERC1363::transferAndCall` 또는 `ERC1363::transferFromAndCall`을 통해\n * ERC-1363 토큰을 이 계약으로 전송할 때마다 이 함수가 호출됩니다.\n *\n * 참고: 전송을 수락하려면 이 함수는\n * `bytes4(keccak256(\"onTransferReceived(address,address,uint256,bytes)\"))`\n * (예: 0x88a7ca5c 또는 자체 함수 선택자)를 반환해야 합니다.\n *\n * @param operator `transferAndCall` 또는 `transferFromAndCall` 함수를 호출한 주소입니다.\n * @param from 토큰이 전송된 주소입니다.\n * @param value 전송된 토큰의 양입니다.\n * @param data 지정된 형식이 없는 추가 데이터입니다.\n * @return 예외를 발생시키지 않는 한 전송이 허용되는 경우 `bytes4(keccak256(\"onTransferReceived(address,address,uint256,bytes)\"))`입니다.\n */\n function onTransferReceived(address operator, address from, uint256 value, bytes calldata data) external returns (bytes4);\n}
+```
+
+`approveAndCall`을 통해 ERC-1363 토큰을 수락하려는 스마트 계약은 `ERC1363Spender` 인터페이스를 **반드시** 구현해야 합니다.
+
+```solidity
+/**\n * @title ERC1363Spender\n * @dev ERC-1363 토큰 계약에서 `approveAndCall`을 지원하려는 모든 계약을 위한 인터페이스입니다.\n */\ninterface ERC1363Spender {\n /**\n * @dev ERC-1363 토큰 `owner`가 `ERC1363::approveAndCall`을 통해 이 계약이\n * 자신의 토큰을 사용하도록 승인할 때마다 이 함수가 호출됩니다.\n *\n * 참고: 승인을 수락하려면 이 함수는\n * `bytes4(keccak256(\"onApprovalReceived(address,uint256,bytes)\"))`\n * (예: 0x7b04a2d0 또는 자체 함수 선택자)를 반환해야 합니다.\n *\n * @param owner `approveAndCall` 함수를 호출하고 이전에 토큰을 소유했던 주소입니다.\n * @param value 사용될 토큰의 양입니다.\n * @param data 지정된 형식이 없는 추가 데이터입니다.\n * @return 예외를 발생시키지 않는 한 승인이 허용되는 경우 `bytes4(keccak256(\"onApprovalReceived(address,uint256,bytes)\"))`입니다.\n */\n function onApprovalReceived(address owner, uint256 value, bytes calldata data) external returns (bytes4);\n}
+```
+
+## 더 읽어보기 {#further-reading}
+
+- [ERC-1363: 지불 가능 토큰 표준](https://eips.ethereum.org/EIPS/eip-1363)
+- [ERC-1363: GitHub 리포지토리](https://github.com/vittominacori/erc1363-payable-token)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-20/index.md
new file mode 100644
index 00000000000..7eef6f2aebd
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-20/index.md
@@ -0,0 +1,186 @@
+---
+title: "ERC-20 토큰 표준"
+description: "상호 운용 가능한 토큰 애플리케이션을 지원하는 이더리움의 대체 가능한 토큰 표준인 ERC-20에 대해 알아보세요."
+lang: ko
+---
+
+## 소개 {#introduction}
+
+**토큰이란 무엇인가요?**
+
+이더리움에서 토큰은 거의 모든 것을 표현할 수 있습니다.
+
+- 온라인 플랫폼의 평판점수
+- 게임 캐릭터의 스킬
+- 회사 주식지분 같은 금융자산
+- 미국달러와 같은 법정통화
+- 1 온스의 금
+- 그 이상 많은것들...
+
+이더리움의 이러한 강력한 특성은 견고한 표준 위에서 동작해야 하지 않을까요? 그것이 바로 ERC-20의 역할입니다! 이 표준을 통해서 개발자들은 다른 제품 및 서비스와 상호 연계 운용 가능한 토큰 애플리케이션을 구축할 수 있습니다. ERC-20 표준은 [이더](/glossary/#ether)에 추가적인 기능을 제공하는 데에도 사용됩니다.
+
+**ERC-20은 무엇인가요?**
+
+ERC-20은 대체가능 토큰의 표준을 제시합니다. 즉, 각 토큰은 다른 토큰과 정확히 동일(유형 및 가치) 하게 만드는 속성을 가지고 있습니다. 예를 들어 ERC-20 토큰은 ETH로 취급되며, 이는 1 토큰이 다른 모든 토큰과 항상 동일함을 의미합니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+- [계정](/developers/docs/accounts)
+- [스마트 계약](/developers/docs/smart-contracts/)
+- [토큰 표준](/developers/docs/standards/tokens/)
+
+## 본문 {#body}
+
+2015년 11월 Fabian Vogelsteller가 제안한 ERC-20(Ethereum Request for Comments 20) 은 스마트 계약 내에서 토큰용 API를 구현하는 토큰 표준이다.
+
+ERC-20에서 제공하는 기능 예시
+
+- 서로 다른 계정간에 토큰 전송하기
+- 계정에서 토큰 잔고 확인하기
+- 가용 중인 네트워크 상의 토큰 총 공급량 확인하기
+- 특정 계정의 토큰을 다른 외부 계정에서 사용 가능한 지 여부를 승인하기
+
+스마트 계약이 다음과 같은 방법과 이벤트를 실행할 경우 이를 ERC-20 토큰 계약이라고 할 수 있으며, 한번 구축되면 이더리움에서 생성된 토큰들을 추적해야 한다.
+
+[EIP-20](https://eips.ethereum.org/EIPS/eip-20)에서:
+
+### 메서드 {#methods}
+
+```solidity
+function name() public view returns (string)
+function symbol() public view returns (string)
+function decimals() public view returns (uint8)
+function totalSupply() public view returns (uint256)
+function balanceOf(address _owner) public view returns (uint256 balance)
+function transfer(address _to, uint256 _value) public returns (bool success)
+function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
+function approve(address _spender, uint256 _value) public returns (bool success)
+function allowance(address _owner, address _spender) public view returns (uint256 remaining)
+```
+
+### 이벤트 {#events}
+
+```solidity
+event Transfer(address indexed _from, address indexed _to, uint256 _value)
+event Approval(address indexed _owner, address indexed _spender, uint256 _value)
+```
+
+### 예시 {#web3py-example}
+
+우리가 이더리움상의 어느 ERC-20 토큰 계약을 검사하는데 있어서 이 표준이 얼마나 주요하게 그 검사를 간단히 만드는지 살펴보자.
+ERC-20 토큰에 대한 인터페이스를 생성하려면 계약 애플리케이션 바이너리 인터페이스(ABI) 가 필요하다. 아래 보이는 것처럼 우리는 잡음을 줄이기 위해 단순화된 ABI를 사용해 예제를 만들것이다.
+
+#### Web3.py 예시 {#web3py-example}
+
+먼저, [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) 파이썬 라이브러리를 설치했는지 확인하세요.
+
+```
+pip install web3
+```
+
+```python
+from web3 import Web3
+
+
+w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
+
+dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI
+weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH)
+
+acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2
+
+# 이것은 ERC-20 토큰 계약의 단순화된 계약 애플리케이션 바이너리 인터페이스(ABI)입니다.
+# balanceOf(address), decimals(), symbol() 및 totalSupply() 메서드만 노출합니다.
+simplified_abi = [
+ {
+ 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}],
+ 'name': 'balanceOf',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'decimals',
+ 'outputs': [{'internalType': 'uint8', 'name': '', 'type': 'uint8'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'symbol',
+ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'totalSupply',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ }
+]
+
+dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi)
+symbol = dai_contract.functions.symbol().call()
+decimals = dai_contract.functions.decimals().call()
+totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals
+addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals
+
+# DAI
+print("===== %s =====" % symbol)
+print("Total Supply:", totalSupply)
+print("Addr Balance:", addr_balance)
+
+weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi)
+symbol = weth_contract.functions.symbol().call()
+decimals = weth_contract.functions.decimals().call()
+totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals
+addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals
+
+# WETH
+print("===== %s =====" % symbol)
+print("Total Supply:", totalSupply)
+print("Addr Balance:", addr_balance)
+```
+
+## 알려진 문제점 {#erc20-issues}
+
+### ERC-20 토큰 수신 문제 {#reception-issue}
+
+**2024년 6월 20일 기준, 이 문제로 인해 최소 83,656,418달러 상당의 ERC-20 토큰이 손실되었습니다. 아래 목록에 명시된 대로 표준 외에 추가적인 제한 사항을 구현하지 않는 한 순수한 ERC-20 구현은 이 문제에 취약하다는 점에 유의하세요.**
+
+ERC-20 토큰이 ERC-20 토큰을 처리하도록 설계되지 않은 스마트 계약으로 전송되면, 해당 토큰은 영구적으로 손실될 수 있습니다. 이는 수신 계약이 들어오는 토큰을 인식하거나 응답할 수 있는 기능이 없기 때문에 발생하며, ERC-20 표준에는 수신 계약에 들어오는 토큰을 알리는 메커니즘이 없습니다. 이 문제는 다음과 같은 방식으로 발생합니다:
+
+1. 토큰 전송 메커니즘
+
+- ERC-20 토큰은 transfer 또는 transferFrom 함수를 사용하여 전송됩니다.
+ - 사용자가 이러한 함수를 사용하여 토큰을 계약 주소로 전송할 때, 수신 계약이 토큰을 처리하도록 설계되었는지와 상관없이 토큰은 전송됩니다.
+
+2. 알림의 부재
+ - 수신 계약은 토큰이 전송되었다는 알림이나 콜백을 받지 않습니다.
+ - 수신 계약에 토큰을 처리할 메커니즘(예: 폴백 함수나 토큰 수신을 관리하는 전용 함수)이 없는 경우, 토큰은 사실상 계약의 주소에 갇히게 됩니다.
+3. 내장된 처리 없음
+ - ERC-20 표준은 수신 계약이 구현해야 할 필수 기능을 포함하지 않으므로, 많은 계약이 들어오는 토큰을 적절히 관리할 수 없는 상황이 발생합니다.
+
+**가능한 해결책**
+
+ERC-20으로 이 문제를 완전히 방지할 수는 없지만, 최종 사용자의 토큰 손실 가능성을 크게 줄일 수 있는 방법들이 있습니다.
+
+- 가장 흔한 문제는 사용자가 토큰 계약 주소 자체로 토큰을 보내는 경우입니다(예: USDT 토큰 계약 주소로 USDT를 예치하는 경우). `transfer(..)` 함수를 제한하여 이러한 전송 시도를 되돌리는 것을 권장합니다. `transfer(..)` 함수의 구현 내에 `require(_to != address(this));` 확인을 추가하는 것을 고려하세요.
+- 일반적으로 `transfer(..)` 함수는 계약에 토큰을 예치하기 위해 설계되지 않았습니다. `approve(..)` & transferFrom(..)`패턴은 대신 ERC-20 토큰을 계약에 예치하는 데 사용됩니다. 전송 함수를 제한하여 이를 통해 어떤 계약에도 토큰을 예치하는 것을 허용하지 않도록 할 수 있지만,`trasnfer(..)` 함수를 사용하여 계약에 토큰을 예치할 수 있다고 가정하는 계약(예: Uniswap 유동성 풀)과의 호환성을 깨뜨릴 수 있습니다.
+- 계약이 어떠한 토큰도 받지 않도록 되어 있더라도 ERC-20 토큰이 계약에 들어올 수 있다고 항상 가정하세요. 수신자 측에서 우발적인 예치를 방지하거나 거부할 방법은 없습니다. 우발적으로 예치된 ERC-20 토큰을 추출할 수 있는 함수를 구현하는 것을 권장합니다.
+- 대안 토큰 표준 사용을 고려해 보세요.
+
+이 문제에서 [ERC-223](/developers/docs/standards/tokens/erc-223) 또는 [ERC-1363](/developers/docs/standards/tokens/erc-1363)과 같은 일부 대안 표준이 나왔습니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [EIP-20: ERC-20 토큰 표준](https://eips.ethereum.org/EIPS/eip-20)
+- [OpenZeppelin - 토큰](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20)
+- [OpenZeppelin - ERC-20 구현](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)
+- [Alchemy - Solidity ERC20 토큰 가이드](https://www.alchemy.com/overviews/erc20-solidity)
+
+## 기타 대체 가능한 토큰 표준 {#fungible-token-standards}
+
+- [ERC-223](/developers/docs/standards/tokens/erc-223)
+- [ERC-1363](/developers/docs/standards/tokens/erc-1363)
+- [ERC-777](/developers/docs/standards/tokens/erc-777)
+- [ERC-4626 - 토큰화된 금고](/developers/docs/standards/tokens/erc-4626)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-223/index.md
new file mode 100644
index 00000000000..8b6aaed3d95
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-223/index.md
@@ -0,0 +1,197 @@
+---
+title: "ERC-223 토큰 표준"
+description: "ERC-223 대체 가능 토큰 표준에 대한 개요, 작동 방식 및 ERC-20과의 비교."
+lang: ko
+---
+
+## 소개 {#introduction}
+
+### ERC-223은 무엇인가요? {#what-is-erc223}
+
+ERC-223은 ERC-20 표준과 유사한 대체 가능 토큰 표준입니다. 주요 차이점은 ERC-223이 토큰 API뿐만 아니라 발신자에서 수신자로 토큰을 전송하는 로직도 정의한다는 것입니다. 수신자 측에서 토큰 전송을 처리할 수 있는 통신 모델을 도입합니다.
+
+### ERC-20과의 차이점 {#erc20-differences}
+
+ERC-223은 ERC-20의 몇 가지 한계를 해결하고 토큰 계약과 토큰을 받을 수 있는 계약 간의 새로운 상호 작용 방법을 도입합니다. ERC-20에서는 불가능하지만 ERC-223에서는 가능한 몇 가지 사항이 있습니다.
+
+- 수신자 측에서의 토큰 전송 처리: 수신자는 ERC-223 토큰이 입금되고 있음을 감지할 수 있습니다.
+- 부적절하게 전송된 토큰 거부: 사용자가 토큰을 받지 않아야 하는 계약에 ERC-223 토큰을 보내는 경우, 해당 계약은 트랜잭션을 거부하여 토큰 손실을 방지할 수 있습니다.
+- 전송 시 메타데이터: ERC-223 토큰은 메타데이터를 포함할 수 있어 토큰 트랜잭션에 임의의 정보를 첨부할 수 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+- [계정](/developers/docs/accounts)
+- [스마트 계약](/developers/docs/smart-contracts/)
+- [토큰 표준](/developers/docs/standards/tokens/)
+- [ERC-20](/developers/docs/standards/tokens/erc-20/)
+
+## 본문 {#body}
+
+ERC-223은 스마트 계약 내의 토큰을 위한 API를 구현하는 토큰 표준입니다. 또한 ERC-223 토큰을 받도록 되어 있는 계약을 위한 API를 선언합니다. ERC-223 수신자 API를 지원하지 않는 계약은 ERC-223 토큰을 받을 수 없어 사용자 실수를 방지합니다.
+
+스마트 계약이 다음 메서드와 이벤트를 구현하면 ERC-223 호환 토큰 계약이라고 할 수 있습니다. 배포되면 이더리움에서 생성된 토큰을 추적할 책임이 있습니다.
+
+계약이 이러한 함수만 가질 의무는 없으며, 개발자는 다른 토큰 표준의 다른 기능을 이 계약에 추가할 수 있습니다. 예를 들어, `approve` 및 `transferFrom` 함수는 ERC-223 표준의 일부는 아니지만 필요한 경우 구현할 수 있습니다.
+
+[EIP-223](https://eips.ethereum.org/EIPS/eip-223)에서:
+
+### 메서드 {#methods}
+
+ERC-223 토큰은 다음 메서드를 구현해야 합니다.
+
+```solidity
+function name() public view returns (string)
+function symbol() public view returns (string)
+function decimals() public view returns (uint8)
+function totalSupply() public view returns (uint256)
+function balanceOf(address _owner) public view returns (uint256 balance)
+function transfer(address _to, uint256 _value) public returns (bool success)
+function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success)
+```
+
+ERC-223 토큰을 받도록 되어 있는 계약은 다음 메서드를 구현해야 합니다.
+
+```solidity
+function tokenReceived(address _from, uint _value, bytes calldata _data)
+```
+
+`tokenReceived(..)` 함수를 구현하지 않는 계약으로 ERC-223 토큰을 보내면 전송이 실패해야 하며, 토큰이 발신자의 잔액에서 이동해서는 안 됩니다.
+
+### 이벤트 {#events}
+
+```solidity
+event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes calldata _data)
+```
+
+### 예시 {#examples}
+
+ERC-223 토큰의 API는 ERC-20과 유사하므로 UI 개발 관점에서 차이가 없습니다. 여기서 유일한 예외는 ERC-223 토큰에 `approve` + `transferFrom` 함수가 없을 수 있다는 것입니다. 이 함수들은 이 표준에서 선택 사항이기 때문입니다.
+
+#### 솔리디티 예제 {#solidity-example}
+
+다음 예제는 기본 ERC-223 토큰 계약이 어떻게 작동하는지 보여줍니다.
+
+```solidity
+pragma solidity ^0.8.19;
+abstract contract IERC223Recipient {
+ function tokenReceived(address _from, uint _value, bytes memory _data) public virtual;
+}
+contract VeryBasicERC223Token {
+ event Transfer(address indexed from, address indexed to, uint value, bytes data);
+ string private _name;
+ string private _symbol;
+ uint8 private _decimals;
+ uint256 private _totalSupply;
+ mapping(address => uint256) private balances;
+ function name() public view returns (string memory) { return _name; }
+ function symbol() public view returns (string memory) {return _symbol; }
+ function decimals() public view returns (uint8) { return _decimals; }
+ function totalSupply() public view returns (uint256) { return _totalSupply; }
+ function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; }
+ function isContract(address account) internal view returns (bool) {
+ uint256 size;
+ assembly { size := extcodesize(account) }
+ return size > 0;
+ }
+ function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success){
+ balances[msg.sender] = balances[msg.sender] - _value;
+ balances[_to] = balances[_to] + _value;
+ if(isContract(_to)) {
+ IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data);
+ }
+ emit Transfer(msg.sender, _to, _value, _data);
+ return true;
+ }
+ function transfer(address _to, uint _value) public returns (bool success){
+ bytes memory _empty = hex"00000000";
+ balances[msg.sender] = balances[msg.sender] - _value;
+ balances[_to] = balances[_to] + _value;
+ if(isContract(_to)) {
+ IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty);
+ }
+ emit Transfer(msg.sender, _to, _value, _empty);
+ return true;
+ }
+}
+```
+
+이제 tokenA가 ERC-223 토큰이라고 가정하고, `tokenA`의 입금을 수락하는 다른 계약을 원합니다. 계약은 tokenA만 수락하고 다른 모든 토큰은 거부해야 합니다. 계약이 tokenA를 받으면 `Deposit()` 이벤트를 발생시키고 내부 `deposits` 변수의 값을 증가시켜야 합니다.
+
+코드는 다음과 같습니다.
+
+```solidity
+contract RecipientContract is IERC223Recipient {
+ event Deposit(address whoSentTheTokens);
+ uint256 deposits = 0;
+ address tokenA; // 우리가 수락하려는 유일한 토큰입니다.
+ function tokenReceived(address _from, uint _value, bytes memory _data) public override
+ {
+ // 이 함수 내에서 다음을 이해하는 것이 중요합니다
+ // msg.sender는 수신 중인 토큰의 주소이며,
+ // msg.value는 대부분의 경우 토큰 계약이 이더를 소유하거나 전송하지 않으므로 항상 0입니다,
+ // _from은 토큰 전송의 발신자이고,
+ // _value는 입금된 토큰의 양입니다.
+ require(msg.sender == tokenA);
+ deposits += _value;
+ emit Deposit(_from);
+ }
+}
+```
+
+## 자주 묻는 질문 {#faq}
+
+### 계약에 tokenB를 보내면 어떻게 될까요? {#sending-tokens}
+
+트랜잭션이 실패하고 토큰 전송이 발생하지 않습니다. 토큰은 발신자의 주소로 반환됩니다.
+
+### 이 계약에 어떻게 입금할 수 있나요? {#contract-deposits}
+
+ERC-223 토큰의 `transfer(address,uint256)` 또는 `transfer(address,uint256,bytes)` 함수를 호출하여 `RecipientContract`의 주소를 지정합니다.
+
+### 이 계약에 ERC-20 토큰을 전송하면 어떻게 될까요? {#erc-20-transfers}
+
+`RecipientContract`에 ERC-20 토큰을 보내면 토큰은 전송되지만, 전송이 인식되지 않습니다(`Deposit()` 이벤트가 발생하지 않으며, deposits 값도 변경되지 않음). 원치 않는 ERC-20 입금은 필터링하거나 방지할 수 없습니다.
+
+### 토큰 입금이 완료된 후 일부 함수를 실행하려면 어떻게 해야 할까요? {#function-execution}
+
+여러 가지 방법이 있습니다. 이 예제에서는 ERC-223 전송을 이더 전송과 동일하게 만드는 방법을 따릅니다.
+
+```solidity
+contract RecipientContract is IERC223Recipient {
+ event Foo();
+ event Bar(uint256 someNumber);
+ address tokenA; // 수락하려는 유일한 토큰입니다.
+ function tokenReceived(address _from, uint _value, bytes memory _data) public override
+ {
+ require(msg.sender == tokenA);
+ address(this).call(_data); // 들어오는 트랜잭션을 처리하고 후속 함수 호출을 수행합니다.
+ }
+ function foo() public
+ {
+ emit Foo();
+ }
+ function bar(uint256 _someNumber) public
+ {
+ emit Bar(_someNumber);
+ }
+}
+```
+
+`RecipientContract`가 ERC-223 토큰을 받으면, 계약은 이더리움 트랜잭션이 트랜잭션 `data`로 함수 호출을 인코딩하는 방식과 동일하게 토큰 트랜잭션의 `_data` 매개변수로 인코딩된 함수를 실행합니다. 자세한 내용은 [데이터 필드](/developers/docs/transactions/#the-data-field)를 읽어보세요.
+
+위 예에서 ERC-223 토큰은 `transfer(address,uin256,bytes calldata _data)` 함수를 사용하여 `RecipientContract`의 주소로 전송되어야 합니다. 데이터 매개변수가 `0xc2985578`(`foo()` 함수의 서명)인 경우, 토큰 입금이 수신된 후 foo() 함수가 호출되고 Foo() 이벤트가 발생합니다.
+
+매개변수는 토큰 전송의 `data`에도 인코딩될 수 있습니다. 예를 들어, `_someNumber`에 12345 값을 사용하여 bar() 함수를 호출할 수 있습니다. 이 경우 `data`는 `0x0423a13200000000000000000000000000000000000000000000000000000000000004d2`여야 합니다. 여기서 `0x0423a132`는 `bar(uint256)` 함수의 서명이고 `00000000000000000000000000000000000000000000000000000000000004d2`는 uint256으로서의 12345입니다.
+
+## 한계 {#limitations}
+
+ERC-223이 ERC-20 표준에서 발견된 여러 문제를 해결하지만, 자체적인 한계도 있습니다.
+
+- 채택 및 호환성: ERC-223은 아직 널리 채택되지 않아 기존 도구 및 플랫폼과의 호환성이 제한될 수 있습니다.
+- 하위 호환성: ERC-223은 ERC-20과 하위 호환되지 않습니다. 즉, 기존 ERC-20 계약 및 도구는 수정 없이는 ERC-223 토큰과 작동하지 않습니다.
+- 가스 비용: ERC-223 전송의 추가 확인 및 기능으로 인해 ERC-20 트랜잭션에 비해 가스 비용이 더 많이 발생할 수 있습니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [EIP-223: ERC-223 토큰 표준](https://eips.ethereum.org/EIPS/eip-223)
+- [초기 ERC-223 제안](https://github.com/ethereum/eips/issues/223)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-4626/index.md
new file mode 100644
index 00000000000..c1945e9b37c
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-4626/index.md
@@ -0,0 +1,227 @@
+---
+title: "ERC-4626 토큰화된 볼트 표준"
+description: "수익을 내는 볼트를 위한 표준입니다."
+lang: ko
+---
+
+## 소개 {#introduction}
+
+ERC-4626은 수익을 내는 볼트의 기술적 매개변수를 최적화하고 통합하기 위한 표준입니다. 단일 기본 ERC-20 토큰의 지분을 나타내는 토큰화된 수익 볼트를 위한 표준 API를 제공합니다. ERC-4626은 또한 ERC-20을 활용하는 토큰화된 볼트를 위한 선택적 확장의 개요를 설명하며, 토큰 예치, 인출 및 잔액 조회를 위한 기본 기능을 제공합니다.
+
+**수익을 내는 볼트에서 ERC-4626의 역할**
+
+대출 시장, 애그리게이터 및 내재적으로 이자가 발생하는 토큰은 다양한 전략을 실행하여 사용자가 자신의 암호화폐 토큰에 대한 최고의 수익률을 찾을 수 있도록 돕습니다. 이러한 전략은 약간의 변형을 거쳐 수행되며, 이로 인해 오류가 발생하기 쉽거나 개발 리소스가 낭비될 수 있습니다.
+
+수익을 내는 볼트에서 ERC-4626은 보다 일관되고 강력한 구현 패턴을 만들어 개발자의 전문적인 노력을 거의 들이지 않고도 통합 노력을 줄이고 다양한 애플리케이션에서 수익에 대한 액세스를 열어줄 것입니다.
+
+ERC-4626 토큰은 [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626)에 완전히 설명되어 있습니다.
+
+**비동기 볼트 확장(ERC-7540)**
+
+ERC-4626은 한도까지의 원자적 예치 및 상환에 최적화되어 있습니다. 한도에 도달하면 새로운 예치나 상환을 제출할 수 없습니다. 이러한 제한은 볼트와 인터페이스하기 위한 전제 조건으로 비동기 작업 또는 지연이 있는 모든 스마트 계약 시스템(예: 실물 자산 프로토콜, 담보 부족 대출 프로토콜, 교차 체인 대출 프로토콜, 유동 스테이킹 토큰 또는 보험 안전 모듈)에서는 잘 작동하지 않습니다.
+
+ERC-7540은 비동기 사용 사례를 위해 ERC-4626 볼트의 유용성을 확장합니다. 기존 볼트 인터페이스(`deposit`/`withdraw`/`mint`/`redeem`)는 비동기 요청을 처리하기 위해 완전히 활용됩니다.
+
+ERC-7540 확장은 [ERC-7540](https://eips.ethereum.org/EIPS/eip-7540)에 완전히 설명되어 있습니다.
+
+**다중 자산 볼트 확장(ERC-7575)**
+
+ERC-4626에서 지원하지 않는 한 가지 누락된 사용 사례는 유동성 공급자(LP) 토큰과 같이 여러 자산 또는 진입점을 가진 볼트입니다. 이들은 일반적으로 ERC-4626 자체가 ERC-20이어야 한다는 요구사항으로 인해 다루기 어렵거나 규정을 준수하지 않습니다.
+
+ERC-7575는 ERC-4626 구현에서 ERC-20 토큰 구현을 외부화하여 다중 자산을 가진 볼트에 대한 지원을 추가합니다.
+
+ERC-7575 확장은 [ERC-7575](https://eips.ethereum.org/EIPS/eip-7575)에 완전히 설명되어 있습니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 [토큰 표준](/developers/docs/standards/tokens/) 및 [ERC-20](/developers/docs/standards/tokens/erc-20/)에 대해 읽어보시는 것을 추천합니다.
+
+## ERC-4626 기능 및 특징: {#body}
+
+### 메서드 {#methods}
+
+#### 자산 {#asset}
+
+```solidity
+function asset() public view returns (address assetTokenAddress)
+```
+
+이 함수는 회계, 예치, 인출을 위해 볼트에 사용되는 기본 토큰의 주소를 반환합니다.
+
+#### 총자산 {#totalassets}
+
+```solidity
+function totalAssets() public view returns (uint256)
+```
+
+이 함수는 볼트가 보유한 기본 자산의 총액을 반환합니다.
+
+#### 지분으로 전환 {#convertoshares}
+
+```solidity
+function convertToShares(uint256 assets) public view returns (uint256 shares)
+```
+
+이 함수는 제공된 `assets`의 양에 대해 볼트가 교환할 `shares`의 양을 반환합니다.
+
+#### 자산으로 전환 {#convertoassets}
+
+```solidity
+function convertToAssets(uint256 shares) public view returns (uint256 assets)
+```
+
+이 함수는 제공된 `shares`의 양에 대해 볼트가 교환할 `assets`의 양을 반환합니다.
+
+#### 최대 예치 {#maxdeposit}
+
+```solidity
+function maxDeposit(address receiver) public view returns (uint256 maxAssets)
+```
+
+이 함수는 단일 [`deposit`](#deposit) 호출에서 예치할 수 있는 기본 자산의 최대 금액을 반환하며, 지분은 `receiver`를 위해 발행됩니다.
+
+#### 예치 미리보기 {#previewdeposit}
+
+```solidity
+function previewDeposit(uint256 assets) public view returns (uint256 shares)
+```
+
+이 함수를 통해 사용자는 현재 블록에서 자신의 예치가 미치는 영향을 시뮬레이션할 수 있습니다.
+
+#### 예치 {#deposit}
+
+```solidity
+function deposit(uint256 assets, address receiver) public returns (uint256 shares)
+```
+
+이 함수는 기본 토큰의 `assets`를 볼트에 예치하고 `shares`의 소유권을 `receiver`에게 부여합니다.
+
+#### 최대 발행 {#maxmint}
+
+```solidity
+function maxMint(address receiver) public view returns (uint256 maxShares)
+```
+
+이 함수는 단일 [`mint`](#mint) 호출에서 발행할 수 있는 최대 지분 금액을 반환하며, 지분은 `receiver`를 위해 발행됩니다.
+
+#### 발행 미리보기 {#previewmint}
+
+```solidity
+function previewMint(uint256 shares) public view returns (uint256 assets)
+```
+
+이 함수를 통해 사용자는 현재 블록에서 자신의 발행이 미치는 영향을 시뮬레이션할 수 있습니다.
+
+#### 발행 {#mint}
+
+```solidity
+function mint(uint256 shares, address receiver) public returns (uint256 assets)
+```
+
+이 함수는 기본 토큰의 `assets`를 예치하여 `receiver`에게 정확히 `shares`만큼의 볼트 지분을 발행합니다.
+
+#### 최대 인출 {#maxwithdraw}
+
+```solidity
+function maxWithdraw(address owner) public view returns (uint256 maxAssets)
+```
+
+이 함수는 단일 [`withdraw`](#withdraw) 호출로 `owner`의 잔액에서 인출할 수 있는 기본 자산의 최대 금액을 반환합니다.
+
+#### 인출 미리보기 {#previewwithdraw}
+
+```solidity
+function previewWithdraw(uint256 assets) public view returns (uint256 shares)
+```
+
+이 함수를 통해 사용자는 현재 블록에서 자신의 인출이 미치는 영향을 시뮬레이션할 수 있습니다.
+
+#### 인출 {#withdraw}
+
+```solidity
+function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares)
+```
+
+이 함수는 `owner`로부터 `shares`를 소각하고 볼트에서 `receiver`에게 정확히 `assets` 토큰을 보냅니다.
+
+#### 최대 상환 {#maxredeem}
+
+```solidity
+function maxRedeem(address owner) public view returns (uint256 maxShares)
+```
+
+이 함수는 [`redeem`](#redeem) 호출을 통해 `owner`의 잔액에서 상환할 수 있는 최대 지분 금액을 반환합니다.
+
+#### 상환 미리보기 {#previewredeem}
+
+```solidity
+function previewRedeem(uint256 shares) public view returns (uint256 assets)
+```
+
+이 함수를 통해 사용자는 현재 블록에서 자신의 상환이 미치는 영향을 시뮬레이션할 수 있습니다.
+
+#### 상환 {#redeem}
+
+```solidity
+function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets)
+```
+
+이 함수는 `owner`로부터 특정 수량의 `shares`를 상환하고 볼트에서 `receiver`에게 기본 토큰의 `assets`를 보냅니다.
+
+#### 총 공급량 {#totalsupply}
+
+```solidity
+function totalSupply() public view returns (uint256)
+```
+
+유통 중인 상환되지 않은 볼트 지분의 총 수량을 반환합니다.
+
+#### 잔액 {#balanceof}
+
+```solidity
+function balanceOf(address owner) public view returns (uint256)
+```
+
+`owner`가 현재 보유하고 있는 볼트 지분의 총량을 반환합니다.
+
+### 인터페이스 맵 {#mapOfTheInterface}
+
+
+
+### 이벤트 {#events}
+
+#### 예치 이벤트
+
+[`mint`](#mint) 및 [`deposit`](#deposit) 메서드를 통해 토큰이 볼트에 예치될 때 **반드시** 방출되어야 합니다.
+
+```solidity
+event Deposit(
+ address indexed sender,
+ address indexed owner,
+ uint256 assets,
+ uint256 shares
+)
+```
+
+여기서 `sender`는 `assets`를 `shares`로 교환하고 해당 `shares`를 `owner`에게 전송한 사용자입니다.
+
+#### 인출 이벤트
+
+[`redeem`](#redeem) 또는 [`withdraw`](#withdraw) 메서드에서 예금자가 볼트에서 지분을 인출할 때 **반드시** 방출되어야 합니다.
+
+```solidity
+event Withdraw(
+ address indexed sender,
+ address indexed receiver,
+ address indexed owner,
+ uint256 assets,
+ uint256 shares
+)
+```
+
+여기서 `sender`는 인출을 트리거하고 `owner`가 소유한 `shares`를 `assets`로 교환한 사용자입니다. `receiver`는 인출된 `assets`를 받은 사용자입니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [EIP-4626: 토큰화된 볼트 표준](https://eips.ethereum.org/EIPS/eip-4626)
+- [ERC-4626: GitHub 리포지토리](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-721/index.md
new file mode 100644
index 00000000000..2f701439210
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-721/index.md
@@ -0,0 +1,248 @@
+---
+title: "ERC-721 대체 불가능 토큰 표준"
+description: "이더리움에서 고유한 디지털 자산을 나타내는 대체 불가 토큰(NFT)의 표준인 ERC-721에 대해 알아보세요."
+lang: ko
+---
+
+## 소개 {#introduction}
+
+**대체 불가능 토큰이란 무엇인가요?**
+
+대체 불가능 토큰(NFT)은 무언가나 누군가를 독특한 방식으로 식별하는 데 사용됩니다. 이 유형의 토큰은 수집품, 접근 키, 복권, 콘서트 및 스포츠 경기의 번호 매겨진 좌석 등을 제공하는 플랫폼에서 사용하기에 적합합니다. 이 특별한 유형의 토큰은 놀라운 가능성을 가지고 있어 ERC-721이라는 적절한 표준이 필요합니다!
+
+**ERC-721은 무엇인가요?**
+
+ERC-721은 NFT 표준을 도입하였으며, 즉, 이 유형의 토큰은 고유하며 같은 스마트 계약의 다른 토큰과는 나이나 희귀성 또는 시각적인 요소 등으로 인해 다른 가치를 가질 수 있습니다.
+잠깐, 시각적인 요소라고요?
+
+네! 모든 NFT에는 `tokenId`라는 `uint256` 변수가 있으므로 모든 ERC-721 계약의 경우
+`contract address, uint256 tokenId` 쌍은 전역적으로 고유해야 합니다. 즉, 탈중앙화앱은 `tokenId`를 입력으로 사용하고 좀비, 무기, 기술 또는 놀라운 고양이 같은 멋진 것을 이미지로 출력하는 "변환기"를 가질 수 있습니다!
+
+## 필수 구성 요소 {#prerequisites}
+
+- [계정](/developers/docs/accounts/)
+- [스마트 계약](/developers/docs/smart-contracts/)
+- [토큰 표준](/developers/docs/standards/tokens/)
+
+## 본문 {#body}
+
+ERC-721(Ethereum Request for Comments 721)은 2018년 1월 William Entriken, Dieter Shirley, Jacob Evans, Nastassia Sachs가 제안한 대체 불가능 토큰 표준으로, 스마트 계약 내에서 토큰을 위한 API를 구현합니다.
+
+이 표준은 한 계정에서 다른 계정으로 토큰을 전송하고, 계정의 현재 토큰 잔액을 확인하고, 특정 토큰의 소유자를 확인하며 네트워크에서 사용 가능한 토큰의 총 공급량을 가져오는 기능을 제공합니다.
+또한, 다른 계정이 특정 계정에서 일정량의 토큰을 이동하도록 승인하는 기능도 포함되어 있습니다.
+
+스마트 계약이 다음 메서드와 이벤트를 구현하면 ERC-721 대체 불가능 토큰 계약이라 부를 수 있으며, 배포되면 이더리움 상에서 생성된 토큰을 추적하는 책임을 갖게 됩니다.
+
+[EIP-721](https://eips.ethereum.org/EIPS/eip-721)에서 발췌:
+
+### 메서드 {#methods}
+
+```solidity
+ function balanceOf(address _owner) external view returns (uint256);
+ function ownerOf(uint256 _tokenId) external view returns (address);
+ function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
+ function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
+ function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
+ function approve(address _approved, uint256 _tokenId) external payable;
+ function setApprovalForAll(address _operator, bool _approved) external;
+ function getApproved(uint256 _tokenId) external view returns (address);
+ function isApprovedForAll(address _owner, address _operator) external view returns (bool);
+```
+
+### 이벤트 {#events}
+
+```solidity
+ event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
+ event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);
+ event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);
+```
+
+### 예시 {#web3py-example}
+
+표준이 이더리움의 모든 ERC-721 토큰 계약을 간단하게 검사하는 데 얼마나 중요한지 살펴보겠습니다.
+모든 ERC-721 토큰에 대한 인터페이스를 생성하려면 계약 애플리케이션 바이너리 인터페이스(ABI)만 있으면 됩니다. 아래 보이는 것처럼 우리는 잡음을 줄이기 위해 단순화된 ABI를 사용해 예제를 만들것이다.
+
+#### Web3.py 예시 {#web3py-example}
+
+먼저, [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) 파이썬 라이브러리를 설치했는지 확인하세요.
+
+```
+pip install web3
+```
+
+```python
+from web3 import Web3
+from web3._utils.events import get_event_data
+
+
+w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
+
+ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # 크립토키티 계약
+
+acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # 크립토키티 판매 경매
+
+# 이것은 ERC-721 NFT 계약의 단순화된 계약 애플리케이션 바이너리 인터페이스(ABI)입니다.
+# balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply() 메서드만 노출합니다.
+simplified_abi = [
+ {
+ 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}],
+ 'name': 'balanceOf',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'name',
+ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [{'internalType': 'uint256', 'name': 'tokenId', 'type': 'uint256'}],
+ 'name': 'ownerOf',
+ 'outputs': [{'internalType': 'address', 'name': '', 'type': 'address'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'symbol',
+ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'totalSupply',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+]
+
+ck_extra_abi = [
+ {
+ 'inputs': [],
+ 'name': 'pregnantKitties',
+ 'outputs': [{'name': '', 'type': 'uint256'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [{'name': '_kittyId', 'type': 'uint256'}],
+ 'name': 'isPregnant',
+ 'outputs': [{'name': '', 'type': 'bool'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ }
+]
+
+ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi)
+name = ck_contract.functions.name().call()
+symbol = ck_contract.functions.symbol().call()
+kitties_auctions = ck_contract.functions.balanceOf(acc_address).call()
+print(f"{name} [{symbol}] 경매 중인 NFT: {kitties_auctions}")
+
+pregnant_kitties = ck_contract.functions.pregnantKitties().call()
+print(f"{name} [{symbol}] 임신 중인 NFT: {pregnant_kitties}")
+
+# 전송 이벤트 ABI를 사용하여 전송된 키티에 대한 정보 얻기
+tx_event_abi = {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'from', 'type': 'address'},
+ {'indexed': False, 'name': 'to', 'type': 'address'},
+ {'indexed': False, 'name': 'tokenId', 'type': 'uint256'}],
+ 'name': 'Transfer',
+ 'type': 'event'
+}
+
+# 로그를 필터링하려면 이벤트의 서명이 필요합니다
+event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex()
+
+logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [event_signature]
+})
+
+# 참고:
+# - 전송 이벤트가 반환되지 않으면 블록 수를 120개 이상으로 늘립니다.
+# - 전송 이벤트를 찾지 못한 경우 다음에서 tokenId를 얻을 수도 있습니다.
+# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events
+# 이벤트 로그를 확장하고 "tokenId" 인수를 복사하려면 클릭하십시오.
+recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs]
+
+if recent_tx:
+ kitty_id = recent_tx[0]['tokenId'] # 위 링크에서 "tokenId"를 여기에 붙여넣습니다.
+ is_pregnant = ck_contract.functions.isPregnant(kitty_id).call()
+ print(f"{name} [{symbol}] NFT {kitty_id} 임신 여부: {is_pregnant}")
+```
+
+CryptoKitties 계약은 표준 이벤트 외에도 몇 가지 흥미로운 이벤트가 있습니다.
+
+그중 `Pregnant`와 `Birth` 두 가지를 확인해 보겠습니다.
+
+```python
+# Pregnant 및 Birth 이벤트 ABI를 사용하여 새로운 키티에 대한 정보 얻기
+ck_extra_events_abi = [
+ {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'owner', 'type': 'address'},
+ {'indexed': False, 'name': 'matronId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'sireId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'cooldownEndBlock', 'type': 'uint256'}],
+ 'name': 'Pregnant',
+ 'type': 'event'
+ },
+ {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'owner', 'type': 'address'},
+ {'indexed': False, 'name': 'kittyId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'matronId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'sireId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'genes', 'type': 'uint256'}],
+ 'name': 'Birth',
+ 'type': 'event'
+ }]
+
+# 로그를 필터링하려면 이벤트의 서명이 필요합니다
+ck_event_signatures = [
+ w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(),
+ w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(),
+]
+
+# 다음은 Pregnant 이벤트입니다:
+# - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog
+pregnant_logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [ck_event_signatures[0]]
+})
+
+recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs]
+
+# 다음은 Birth 이벤트입니다:
+# - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a
+birth_logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [ck_event_signatures[1]]
+})
+
+recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs]
+```
+
+## 인기 있는 NFT {#popular-nfts}
+
+- [Etherscan NFT 추적기](https://etherscan.io/nft-top-contracts)는 전송량을 기준으로 이더리움의 상위 NFT를 나열합니다.
+- [CryptoKitties](https://www.cryptokitties.co/)는 우리가 CryptoKitties라고 부르는 번식 가능하고 수집 가능하며 아주 사랑스러운 생물을 중심으로 하는 게임입니다.
+- [Sorare](https://sorare.com/)는 한정판 수집품을 수집하고, 팀을 관리하며 상품을 획득하기 위해 경쟁하는 글로벌 판타지 축구 게임입니다.
+- [이더리움 이름 서비스(ENS)](https://ens.domains/)는 간단하고 사람이 읽을 수 있는 이름을 사용하여 블록체인 온체인과 오프체인 리소스의 주소를 지정하는 안전하고 분산된 방법을 제공합니다.
+- [POAP](https://poap.xyz)는 이벤트에 참석하거나 특정 작업을 완료하는 사람들에게 무료 NFT를 제공합니다. POAP는 무료로 생성 및 배포할 수 있습니다.
+- [Unstoppable Domains](https://unstoppabledomains.com/)는 샌프란시스코에 본사를 둔 블록체인 도메인 구축 회사입니다. 블록체인 도메인은 암호화폐 주소를 사람이 읽을 수 있는 이름으로 대체하며, 검열 저항성 웹사이트를 활성화하는 데 사용할 수 있습니다.
+- [Gods Unchained Cards](https://godsunchained.com/)는 NFT를 사용하여 게임 내 자산에 대한 실제 소유권을 부여하는 이더리움 블록체인 기반의 TCG입니다.
+- [Bored Ape Yacht Club](https://boredapeyachtclub.com)은 10,000개의 고유한 NFT 컬렉션으로, 증명할 수 있는 희귀한 예술 작품일 뿐만 아니라 클럽의 멤버십 토큰 역할을 하며, 커뮤니티의 노력의 결과로 시간이 지남에 따라 증가하는 회원 특전과 혜택을 제공합니다.
+
+## 더 읽어보기 {#further-reading}
+
+- [EIP-721: ERC-721 대체 불가 토큰 표준](https://eips.ethereum.org/EIPS/eip-721)
+- [OpenZeppelin - ERC-721 문서](https://docs.openzeppelin.com/contracts/3.x/erc721)
+- [OpenZeppelin - ERC-721 구현](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol)
+- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/ko/developers/docs/standards/tokens/erc-777/index.md
new file mode 100644
index 00000000000..c14939885c5
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/erc-777/index.md
@@ -0,0 +1,45 @@
+---
+title: "ERC-777 토큰 표준"
+description: "훅(hook)을 통해 개선된 대체 가능한 토큰 표준인 ERC-777에 대해 알아보세요. 단, 보안을 위해 ERC-20 사용을 권장합니다."
+lang: ko
+---
+
+## 경고 {#warning}
+
+**ERC-777은 [다양한 형태의 공격에 취약](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2620)하기 때문에 제대로 구현하기가 어렵습니다. 대신 [ERC-20](/developers/docs/standards/tokens/erc-20/)을 사용하는 것이 좋습니다.** 이 페이지는 역사적 기록물로 남아 있습니다.
+
+## 소개? {#introduction}
+
+ERC-777은 기존의 [ERC-20](/developers/docs/standards/tokens/erc-20/) 표준을 개선한 대체 가능한 토큰 표준입니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+이 페이지를 더 잘 이해하려면 먼저 [ERC-20](/developers/docs/standards/tokens/erc-20/)에 대해 읽어보는 것을 권장합니다.
+
+## ERC-777은 ERC-20에 비해 어떤 개선점을 제안하나요? {#-erc-777-vs-erc-20}콜데이터-블롭
+
+ERC-777은 ERC-20에 비해 다음과 같은 개선점을 제공합니다.
+
+### 훅 {#hooks}
+
+훅은 스마트 계약의 코드에 기술된 함수입니다. 훅은 계약을 통해 토큰을 보내거나 받을 때 호출됩니다. 이를 통해 스마트 계약은 수신 또는 발신 토큰에 반응할 수 있습니다.
+
+훅은 [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820) 표준을 사용하여 등록되고 발견됩니다.
+
+#### 훅의 장점은 무엇인가요? {#why-are-hooks-great}
+
+1. 이를 위해 이중 호출(`approve`/`transferFrom`)이 필요한 [ERC-20](https://eips.ethereum.org/EIPS/eip-20)과 달리 훅은 단일 트랜잭션으로 계약에 토큰을 보내고 계약에 알림을 보낼 수 있습니다.
+2. 훅을 등록하지 않은 계약은 ERC-777과 호환되지 않습니다. 수신 계약이 훅을 등록하지 않은 경우 송신 계약은 트랜잭션을 중단합니다. 이는 비-ERC-777 스마트 계약으로의 의도치 않은 전송을 방지합니다.
+3. 훅은 트랜잭션을 거부할 수 있습니다.
+
+### 소수 자릿수 {#decimals}
+
+이 표준은 또한 ERC-20에서 발생한 `decimals` 관련 혼란을 해결합니다. 이러한 명확성은 개발자 경험을 개선합니다.
+
+### ERC-20과의 하위 호환성 {#backwards-compatibility-with-erc-20}
+
+ERC-777 계약은 마치 ERC-20 계약인 것처럼 상호작용할 수 있습니다.
+
+## 추가 정보 {#further-reading}
+
+[EIP-777: 토큰 표준](https://eips.ethereum.org/EIPS/eip-777)
diff --git a/public/content/translations/ko/developers/docs/standards/tokens/index.md b/public/content/translations/ko/developers/docs/standards/tokens/index.md
new file mode 100644
index 00000000000..dd45932ecb8
--- /dev/null
+++ b/public/content/translations/ko/developers/docs/standards/tokens/index.md
@@ -0,0 +1,41 @@
+---
+title: "토큰 표준"
+description: "대체 가능 토큰 및 대체 불가능 토큰을 위한 ERC-20, ERC-721, ERC-1155를 비롯한 이더리움 토큰 표준을 살펴보세요."
+lang: ko
+incomplete: true
+---
+
+## 소개 {#introduction}
+
+많은 이더리움 개발 표준이 토큰 인터페이스에 초점을 맞추고 있습니다. 이러한 표준은 스마트 계약이 구성 가능성을 유지하도록 도와주므로, 새로운 프로젝트가 토큰을 발행할 때 기존 탈중앙화 거래소 및 애플리케이션과의 호환성을 유지할 수 있습니다.
+
+토큰 표준은 이더리움 생태계 전반에서 토큰이 어떻게 작동하고 상호작용하는지를 정의합니다. 이는 개발자가 불필요한 수고를 덜고 더 쉽게 구축할 수 있도록 하며, 토큰이 지갑, 거래소 및 디파이 플랫폼과 원활하게 작동하도록 보장합니다. 게임, 거버넌스 또는 기타 사용 사례 등에서 이러한 표준은 일관성을 제공하고 이더리움의 상호 연결성을 더욱 강화합니다.
+
+## 필수 구성 요소 {#prerequisites}
+
+- [이더리움 개발 표준](/developers/docs/standards/)
+- [스마트 계약](/developers/docs/smart-contracts/)
+
+## 토큰 표준 {#token-standards}
+
+다음은 이더리움에서 가장 인기 있는 토큰 표준 중 일부입니다:
+
+- [ERC-20](/developers/docs/standards/tokens/erc-20/) - 투표 토큰, 스테이킹 토큰 또는 가상 화폐와 같은 대체 가능한(상호 교환 가능한) 토큰을 위한 표준 인터페이스입니다.
+
+### NFT 표준 {#nft-standards}
+
+- [ERC-721](/developers/docs/standards/tokens/erc-721/) - 예술품이나 노래의 증서와 같은 대체 불가능한 토큰을 위한 표준 인터페이스입니다.
+- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - ERC-1155는 거래 및 트랜잭션 묶음의 효율성을 높여 비용을 절감합니다. 이 토큰 표준은 $BNB 또는 $BAT 같은 유틸리티 토큰과 CryptoPunks와 같은 대체 불가능한 토큰을 만들 수 있습니다.
+
+[ERC](https://eips.ethereum.org/erc) 제안 전체 목록.
+
+## 더 읽어보기 {#further-reading}
+
+_도움이 되었던 커뮤니티 참고 자료를 알고 계신가요? 이 페이지를 편집해서 추가하세요!_
+
+## 관련 튜토리얼 {#related-tutorials}
+
+- [토큰 통합 체크리스트](/developers/tutorials/token-integration-checklist/) _– 토큰과 상호작용할 때 고려해야 할 사항에 대한 체크리스트입니다._
+- [ERC20 토큰 스마트 계약 이해하기](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– 이더리움 테스트넷에 첫 스마트 계약을 배포하는 방법에 대한 소개입니다._
+- [솔리디티 스마트 계약에서 ERC20 토큰 전송 및 승인하기](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– 솔리디티 언어를 사용하여 스마트 계약으로 토큰과 상호작용하는 방법입니다._
+- [ERC721 마켓 구현하기[실용 가이드]](/developers/tutorials/how-to-implement-an-erc721-market/) _– 탈중앙화된 게시판에서 토큰화된 아이템을 판매하는 방법입니다._