Update docs/kr/intro and fix typo in docs/intro (#5979)

- update docs/kr/intro to latest documentation - fix link typo in docs/intro/sdk-design Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
2020-05-05 07:05:28 +09:00 · 2020-05-05 07:05:28 +09:00 · 84f1261c7b
parent 106bcd5e13
commit 84f1261c7b
6 changed files with 249 additions and 37 deletions
--- a/docs/intro/sdk-design.md
+++ b/docs/intro/sdk-design.md
@ -25,7 +25,7 @@ For more on `baseapp`, please click [here](../core/baseapp.md).

 ## Multistore

-The Cosmos SDK provides a [`multistore`](../core/store.md#multisotre) for persisting state. The multistore allows developers to declare any number of [`KVStores`](../core/store.md#base-layer-kvstores). These `KVStores` only accept the `[]byte` type as value and therefore any custom structure needs to be marshalled using [a codec](../core/encoding.md) before being stored.
+The Cosmos SDK provides a [`multistore`](../core/store.md#multistore) for persisting state. The multistore allows developers to declare any number of [`KVStores`](../core/store.md#base-layer-kvstores). These `KVStores` only accept the `[]byte` type as value and therefore any custom structure needs to be marshalled using [a codec](../core/encoding.md) before being stored.

 The multistore abstraction is used to divide the state in distinct compartments, each managed by its own module. For more on the multistore, click [here](../core/store.md#multistore)

--- a/docs/kr/intro/README.md
+++ b/docs/kr/intro/README.md
@ -1,15 +1,16 @@
-# SDK 소개
+<!--
+order: false
+parent:
+  order: 1
+-->

+# 소개

+이 폴더에는 Cosmos-SDK에 대한 소개 자료가 포함되어 있습니다.

-[Cosmos-SDK](https://github.com/cosmos/cosmos-sdk)는 코스모스 허브 같은 멀티애셋 지분증명(Proof-of-Stake) 블록체인 또는 권한증명(Proof-of-Authority) 같은 블록체인들을 만들 수 있는 하나의 프레임워크입니다.
+1. [SDK 소개](./overview.md)
+2. [애플리케이션 특화 블록체인](./why-app-specific.md)
+3. [SDK 애플리케이션의 아키텍쳐](./sdk-app-architecture.md)
+4. [코스모스 SDK 디자인 소개](./sdk-design.md)

-코스모스 SDK의 목표는 개발자들이 본인만의 커스텀 블록체인을 처음부터 쉽게 만들고, 이런 블록체인들이 상호호환성을 가질 수 있게 하는 것입니다. 우리는 코스모스 SDK가 [Tendermint](https://github.com/tendermint/tendermint) 기반의 안전한 블록체인 애플리케이션의 npm 프레임워크 같은 역할을 할수 있을 것을 기대하고 있습니다.
-
-코스모스 SDK는 다음과 같은 원칙에 의거합니다:
-
- **구성성:** 누구나 코스모스-SDK 모듈을 만들 수 있다. 또한 이미 만들어진 기존 모듈을 내가 만드려는 블록체인 애플리케이션에 손쉽게 도입할 수 있다.
-
- **능력성:** 코스모스-SDK는 능력기반 보안(capabilities-based security)과 수년의 블록체인 스테이트 머신에 대한 고민을 기반으로 만들어졌습니다. 대다수의 개발자들은 본인들의 모듈을 개발할때 제3자의 모듈을 사용해야되는 경우가 많습니다. 코스모스-SDK는 오픈 프레임워크이기 때문에, 일부 악의적인 모듈이 존재할 수 있다는 것을 배제할 수 없습니다. 이런 환경에서는 보안과 안전성을 확보하기 위해 모듈간 인터랙션에서 기본적인 보안 원칙이 존재해야 합니다. 이런 원칙은 오브젝트-능력(object-capabilities) 기반으로 만들어졌습니다. 각 모듈이 다른 모든 모듈들의 액세스 권한 리스트를 관리하기 보다, 각 모듈은 키퍼(Keeper)라는 특수 오브젝트를 도입할 수 있습니다. 이런 '키퍼' 들은 다른 모듈에게 전달되어 사전에 정의된 능력(기능)을 수행할 수 있는 권한을 부여합니다. 예를 들어, 모듈 A의 키퍼가 모듈 B에게 전달되었을 경우, 모듈 B는 사전에 정의되어있는 한정된 모듈 A의 기능을 호출할 수 있습니다. 각 키퍼가 수행할 수 있는 기능은 해당 모듈의 개발자가 정의할 수 있으며, 모듈 기능으로 발생할 수 있는 안전/보안 문제를 감사하는 책임은 각 개발자에게 있습니다. 능력(capability)에 대한 더 자세한 설명은 다음 [링크](./ocap.md)에서 확인하실 수 있습니다.
-
-### 다음은 [SDK 애플리케이션 아키텍쳐](./sdk-app-architecture.md)에 대해서 알아보겠습니다
+해당 기본 자료를 읽으신 후 [basics](../basics/README.md) 폴더에 있는 자료를 읽어보시는 것을 추천드립니다.
--- a/docs/kr/intro/overview.md
+++ b/docs/kr/intro/overview.md
@ -0,0 +1,33 @@
+---
+order: 1
+---
+
+# SDK 소개
+
+## 코스모스 SDK는 무엇인가?
+
+[코스모스 SDK](https://github.com/cosmos/cosmos-sdk)는 코스모스 허브와 같은 다수 자산(multi-asset) 퍼블릭 지분증명 블록체인과 권한증명(PoA, Proof-of-Authority) 블록체인을 만들 수 있는 오픈소스 프레임워크입니다. 코스모스 SDK를 사용하여 만들어진 블록체인은 통상 **애플리케이션 특화 블록체인(application-specific blockchain)**이라 불립니다.
+
+코스모스 SDK의 목적은 개발자가 간편하게 처음부터 다른 블록체인과 상호환이 가능한 블록체인을 만들 수 있게 하는 것이 목적입니다. 코스모스 SDK는 npm과 같은 프레임워크로 자리잡으며 [텐더민트](https://github.com/tendermint/tendermint) 상의 안전한 블록체인 애플리케이션을 만들 수 있게 자리잡는 것이 목표입니다. SDK 기반 블록체인은 구성적(composable) 모듈을 기반으로 만들어지며, 대다수의 모듈은 오픈 소스로 모든 개발자가 사용할 수 있습니다. 누구나 코스모스 SDK 모듈을 만들 수 있으며, 단순히 블록체인 애플리케이션에 모듈을 불러와 이미 개발된 모듈을 간편하게 사용할 수 있습니다. 또한, 코스모스 SDK는 능력성 기반(capabilities-based) 시스템으로 모듈 간 인터랙션의 보안성을 더욱 직관적으로 설계할 수 있습니다. 능력성 기반 시스템에 대해 더 알고싶으시다면 [이 항목](./ocap.md)을 참고하세요.
+
+## 애플리케이션 특화 블록체인은 무엇인가?
+
+최근 블록체인 업계의 개발 패러다임 중 하나는 이더리움과 같은 버추얼 머신(virtual-machine) 기반 블록체인입니다. 이런 시스템에서는 기존 블록체인 상위에 스마트 컨트랙트 기반의 탈중앙화 애플리케이션을 만드는 형태로 개발됩니다. 스마트 컨트랙트는 단순 애플리케이션 (예, ICO) 용도로 적합하지만, 복잡한 탈중앙화 플랫폼을 개발하는 목적에는 적합하지 않습니다. 스마트 컨트랙트는 유연성, 존엄성 그리고 성능 측면에서 한계가 존재합니다.
+
+애플리케이션 특화 블록체인은 기존 버추얼 머신 기반 블록체인과는 획기적으로 다른 개발 패러다임을 제공합니다. 애플리케이션 특화 블록체인은 하나의 애플리케이션을 구동하기 위해 특화되며, 개발자는 애플리케이션이 최적한 환경에서 구동될 수 있는 디자인 결정을 내릴 수 있습니다. 또한 애플리케이션 특화 블록체인은 애플리케이션 존엄성, 보안 그리고 성능 측면에서 장점을 가집니다.
+
+애플리케이션 특화 블록체인에 대한 더 자세한 정보는 [여기](./why-app-specific.md)를 참고하세요.
+
+## 왜 코스모스 SDK인가?
+
+코스모스 SDK는 고유 애플리케이션 특화 블록체인을 만들기 위한 가장 우수한 프레임워크입니다. 다음은 코스모스 SDK가  탈중앙화 애플리케이션을 개발하는데 제공하는 장점들입니다:
+
+- 코스모스 SDK가 기본적으로 제공하는 합의 엔진은 [텐더민트 코어](https://github.com/tendermint/tendermint)입니다. 텐더민트는 가장 오랜 기간 증명된 BFT 기반 컨센서스 엔진입니다. 텐더민트 코어는 업계 내의 수 많은 환경에서 지분증명 시스템을 개발하는데 사용되고 있습니다.
+- 코스모스 SDK는 오픈소스이며 구성적(composable) 모듈을 기반으로 간편하게 블록체인을 만들 수 있습니다. 블록체인 생태계가 성장하며 더욱 다양한 코스모스 SDK 모듈들이 개발되고 있으며, 이런 모듈들을 기반으로 복잡한 탈중앙화 플랫폼을 개발하는 과정이 간소화됩니다.
+- 코스모스 SDK는 능력성 기반(capabilities-based) 보안 아키텍쳐를 기반으로 설계되었습니다. 이런 디자인 결정은 수년간 블록체인 스테이트 머신(state machine)에 대한 고민을 기반으로 설계되었으며, 더욱 안전한 블록체인을 개발할 수 있는 환경을 제공합니다.
+- 가장 중요한 것은 바로 코스모스 SDK가 실제 작동하고 있는 다수의 애플리케이션 특화 블록체인을 개발하는데 사용되고 있다는 점입니다. [코스모스 허브](https://hub.cosmos.network), [아이리스 허브](https://irisnet.org), [바이낸스 체인](https://docs.binance.org), [테라](https://terra.money), [Lino](https://lino.network) 등의 프로젝트가 코스모스 SDK 기반으로 개발되었습니다. 코스모스 기반 프로젝트 목록은 [여기](https://cosmos.network/ecosystem)에서 확인하실 수 있습니다.
+
+## 코스모스 SDK 입문하기
+
+- [코스모스 SDK 기반 애플리케이션의 구조](./sdk-app-architecture.md)에 대해서 더 알아보세요
+- 애플리케이션 특화 블록체인을 처음부터 개발하는 방법을 [코스모스 SDK 투토리얼](https://cosmos.network/docs/tutorial)을 통해 배워보세요
--- a/docs/kr/intro/sdk-app-architecture.md
+++ b/docs/kr/intro/sdk-app-architecture.md
@ -1,71 +1,74 @@
+<!--
+order: 3
+-->
+
+
 # SDK 애플리케이션 아키텍쳐

-## 스테이트 머신 (상태 기계, State machine)
+## 상태 기계 (state machine)

 블록체인 애플리케이션은 근본적으로 [결정론적 복제 상태 기계(replicated deterministic state machine)](https://ko.wikipedia.org/wiki/%EC%83%81%ED%83%9C_%EA%B8%B0%EA%B3%84_%EB%B3%B5%EC%A0%9C)입니다.

-스테이트 머신은 특정 기계(머신, machine)이 오랜 기간동안 다수의 상태(스테이트, state)를 보유할 수 있지만, 특정 시점에 오직 하나의 상태를 유지하는 있는 컴퓨터 공학 개념입니다. 여기서 '스테이트 머신' 개념에는 시스템의 현 상태를 뜻하는 '스테이트(state)'가 있으며, 스테이트의 변경을 유발하는 
+상태 기계는 특정 시점에 오직 하나의 상태를 유지하는 있는 컴퓨터 공학 개념입니다. 여기서 '상태 기계' 개념에는 시스템의 현 상태를 뜻하는 '상태(state)'가 있으며, 상태의 변경을 유발하는 
 트랜잭션(transaction)'이 있습니다.

-`S` 라는 스테이트와 `T` 라는 트랜잭션이 있는 경우, 스테이트 머신은 `S'`라는 새로운 스테이트를 리턴합니다.
+`S` 라는 상태와 `T` 라는 트랜잭션이 있는 경우, 상태 기계는 `S'`라는 새로운 상태를 리턴합니다.

 ```
 +--------+                 +--------+
 |        |                 |        |
 |   S    +---------------->+   S'   |
-|        |    apply(T)     |        |
+|        |     (T)적용     |        |
 +--------+                 +--------+
 ```

-실전에서는 트랜잭션들이 일종의 '블록' 단위로 묶여 스테이트 변경 과정을 더 효율적일 수 있게 합니다. `S`라는 스테이트와 `B`라는 트랜잭션들이 있는 경우, 스테이트 머신은 `S'`라는 새로운 스테이트를 리턴합니다.
+실질적으로는 트랜잭션은 블록 단위로 묶여 상태 변경 과정을 더 효율적일 수 있게 합니다. `S`라는 상태와 `B`라는 트랜잭션이 있는 경우, 상태 기계는 `S'`라는 새로운 상태를 리턴합니다.

 ```
 +--------+                              +--------+
 |        |                              |        |
 |   S    +----------------------------> |   S'   |
-|        |   For each T in B: apply(T)  |        |
+|        |    B의 T 수만큼: (T)적용     |        |
 +--------+                              +--------+
 ```

-블록체인이라는 시스템 내의 개념으로 볼때 스테이트 머신은 결정론적(deterministic)입니다. 즉, 특정 스테이트에서 시작한 후 동일한 트랜잭션들을 반복할 경우, 결과 스테이트는 언제나 동일합니다.
+블록체인 시스템 개념으로 점그할때, 상태 기계는 결정론적(deterministic)입니다. 즉, 노드가 특정 상태에서 시작된 후 동일한 트랜잭션들을 반복할 경우, 결과 상태는 언제나 동일합니다.

-코스모스 SDK는 애플리케이션의 스테이트, 트랜잭션 형태 그리고 스테이트 변경 기능(state-transition function)을 정의하는데 최대한의 유연성을 제공합니다. 코스모스 SDK를 이용해 스테이트 머신을 만드는 과정은 이후 항목에서 다루겠습니다. 우선 이 시스템 내에서 어떻게 **텐더민트**를 사용해 '스테이트'가 복제되는지 알아보겠습니다.
+코스모스 SDK는 애플리케이션의 상태, 트랜잭션 형태 그리고 상태 변경 기능(state-transition function)을 정의하는데 최대한의 유연성을 제공합니다. 코스모스 SDK를 이용해 상태 기계를 만드는 과정은 이후 항목에서 다루겠습니다. 우선 이 시스템 내에서 어떻게 **텐더민트**를 사용해 '상태'가 복제되는지 알아보겠습니다.

 ## 텐더민트

-개발자는 코스모스 SDK를 사용하여 스테이트 머신만을 정의하면 되며, 해당 스테이트를 네트워크에 복제하는 기능은 [*텐더민트*](https://tendermint.com/docs/introduction/introduction.html)가 제공합니다.
+개발자는 코스모스 SDK를 사용하여 상태 기계만을 정의하면 되며, 해당 상태를 네트워크에 복제하는 기능은 [*텐더민트*](https://tendermint.com/docs/introduction/introduction.html)가 제공합니다.


 ```
                ^  +-------------------------------+  ^
                |  |                               |  |   코스모스 SDK로 개발
-                |  |      스테이트 머신 = 애플리케이션    |  |
+                |  |    상태 기계 = 애플리케이션   |  |
                |  |                               |  v
                |  +-------------------------------+
                |  |                               |  ^
-    블록체인 노드   |  |             컨센서스            |  |
+  블록체인 노드 |  |            컨센서스           |  |
                |  |                               |  |
                |  +-------------------------------+  |   텐더민트 코어
                |  |                               |  |
-                |  |             네트워킹            |  |
+                |  |            네트워킹           |  |
                |  |                               |  |
                v  +-------------------------------+  v
 ```

-텐더민트는 오직 블록체인의 *네트워킹*과 *합의(컨센서스)* 계층을 처리하는 애플리케이션-불가지성(application-agnostic) 엔진입니다. 실전적으로 볼때, 텐더민트는 단순히 트랜잭션의 바이트를 나열하고, 해당 트랜잭션을 네트워크에 전파하는 역할만을 한다는 것입니다. 텐더민트 코어는 텐더민트 비잔틴 결함 감내(BFT, Byzantine-fault tolerant) 알고리즘을 사용하여 트랜잭션 순서에 대한 합의를 합니다. 텐더민트에 대해서 더 알고싶으시다면 [여기](https://tendermint.com/docs/introduction/introduction.html)를 확인하세요.
+텐더민트는 오직 블록체인의 *네트워킹*과 *합의(컨센서스)* 계층을 처리하는 애플리케이션-불가지성(application-agnostic) 엔진입니다. 실질적으로 텐더민트는 단순히 트랜잭션의 바이트를 나열하고, 해당 트랜잭션을 네트워크에 전파하는 역할만을 한는 것입니다. 텐더민트 코어는 텐더민트 비잔틴 결함 감내(BFT, Byzantine-fault tolerant) 알고리즘을 사용하여 트랜잭션 순서에 대한 합의를 합니다.

-텐더민트 합의 알고리즘은 '검증인(Validators)'이라는 특정 노드 세트를 기반으로 작동합니다. 검증인의 주 역할은 트랜잭션을 블록 단위로 블록체인에 추가하는 것입니다. 특정 블록에는 V 검증인 세트 검증인 존재하며, 이 V 검증인 세트 안에 있는 검증인 중 하나의 검증인이 다음 블록 생성자로 알고리즘에 의해 선택됩니다. 만약 블록이 V 검증인 세트 2/3 이상의 [프리보트(prevote)](https://tendermint.com/docs/spec/consensus/consensus.html#prevote-step-height-h-round-r)와 [프리커밋(precommit)](https://tendermint.com/docs/spec/consensus/consensus.html#precommit-step-height-h-round-r)을 받고 내용 트랜잭션이 유효한 경우 해당 블록은 '유효(valid)'한 것으로 간주됩니다. 검증인 세트는 스테이트 머신에 작성된 규칙에 따라서 바뀔 수 있습니다. 알고리즘에 대해 더 자세한 정보는 [여기](https://tendermint.com/docs/introduction/what-is-tendermint.html#consensus-overview)를 참고하세요.
-
-코스모스 SDK 애플리케이션의 주요 파트는 네트워크에 포함되어있는 노드가 각자 로컬 환경에서 운영하는 블록체인 데몬(daemon)입니다. 만약 *검증인 세트*의 1/3 이하가 악의적(byzantine)인 경우, 각 노드는 동시에 스테이트를 조회할때 동일한 결과를 받게됩니다.
+텐더민트 합의 알고리즘은 '검증인(Validators)'이라는 특정 노드 세트를 기반으로 작동합니다. 특정 블록에는 V 검증인 세트 검증인 존재하며, 이 V 검증인 세트 안에 있는 검증인 중 하나의 검증인이 다음 블록 생성자로 알고리즘에 의해 선택됩니다. 만약 블록이 V 검증인 세트 2/3 이상의 [프리보트(prevote)](https://tendermint.com/docs/spec/consensus/consensus.html#prevote-step-height-h-round-r)와 [프리커밋(precommit)](https://tendermint.com/docs/spec/consensus/consensus.html#precommit-step-height-h-round-r)을 받고 내용 트랜잭션이 유효한 경우 해당 블록은 '유효(valid)'한 것으로 간주됩니다. 검증인 세트는 상태 기계에 작성된 규칙에 따라서 바뀔 수 있습니다.

 ## ABCI

-텐더민트는 네트워크에서 어플리케이션으로 거래를 넘겨줍니다. 이때, ABCI 라고 불리우는 인터페이스를 사용합니다. 그리고 이는 어플리케이션이 반드시 구현해야하는 부분입니다. 
+텐더민트는 ABCI라를 인터페이스를 사용해 트랜잭션을 애플리케이션에게 전달합니다. 이는 어플리케이션이 반드시 구현해야하는 부분입니다. 

 ```
 +---------------------+
 |                     |
-|     Application     |
+|     애플리케이션    |
 |                     |
 +--------+---+--------+
         ^   |
@ -74,7 +77,7 @@
 +--------+---+--------+
 |                     |
 |                     |
-|     Tendermint      |
+|       텐더민트      |
 |                     |
 |                     |
 +---------------------+
@ -84,14 +87,14 @@

 아래에 ABCI 의 메세지들 중 가장 중요한 것들을 나열해놓았습니다:

- `CheckTx`: 텐더민트 코어로부터 거래를 받게 될 때, 이 거래는 어플리케이션에 넘겨져서 몇가지 기본 요건을 잘 만족했는지를 확인합니다. `CheckTx` 는 풀노드의 mempool을 스팸행위로 부터 보호하는데 사용됩니다. "Ante Handler" 라고 불리우는 특별한 handler 는 일련의 검증 과정을 실행하는데 사용됩니다. 예를 들면, 충분한 수수료가 있는지와 서명이 유효한지를 확인합니다. 만약 검사 결과가 유효한 것으로 나오게 되면, 그 거래는 [mempool](https://tendermint.com/docs/spec/reactors/mempool/functionality.html#mempool-functionality) 에 더해지게 됩니다. 그리고 피어 노드들에게도 전달됩니다. 거래가 블록에 담기기 전까지는 `CheckTx` 과정은 진행되지 않는다. (즉, 상태의 변경이 일어나지 않는다.) 
+- `CheckTx`: 텐더민트 코어로부터 거래를 받게 될 때, 이 거래는 어플리케이션에 넘겨져서 몇 가지 기본 요건을 충족하는지 확인합니다. `CheckTx` 는 풀노드의 mempool을 스팸행위로 부터 보호하는데 사용됩니다. "Ante Handler" 라고 불리우는 특별한 handler 는 일련의 검증 과정을 실행하는데 사용됩니다. 예를 들면, 충분한 수수료가 있는지, 그리고 서명이 유효한지 확인합니다. 만약 검사 결과가 유효한 경우 되면, 해당 거래는 [mempool](https://tendermint.com/docs/spec/reactors/mempool/functionality.html#mempool-functionality)에 추가되고 피어 노드에게 전달됩니다. 참고로 트랜잭션이 블록에 추가되기 전까지는 `CheckTx` 과정이 진행되지 않습니다. (즉, 상태의 변경이 일어나지 않습니다.) 

- `DelieverTx` : [유효한 블록](https://tendermint.com/docs/spec/blockchain/blockchain.html#validation)이 텐더민트 코어에 의해서 전달되었을 때, 해당 블록에 있는 모든 개별 거래들은 `DeliverTx`에 의해서 어플리케이션에게 전달됩니다. 상태 변환이 일어나는 단계가 이 단계이다. "Ante Handler" 는 실제 handler 와 함께 거래 내의 각 메세지에 대한 검증을 위해 다시 실행한다. 
+- `DeliverTx` : 텐더민트 코어가 [유효한 블록](https://tendermint.com/docs/spec/blockchain/blockchain.html#validation)을 전달받는 경우, 각 블록의 트래잭션은 `DeliverTx`를 통해 애플리케이션에 전달합니다. 이 단계에서 상태 변경이 일어납니다. `AnteHandler`는 트랜잭션에 포함된 각 메세지를 검증하기 위해 다시 실행됩니다. 

- `BeginBlock`/`EndBlock` : 이 메세지들은 블록이 거래를 담고 있던 아니던 각 블록의 시작과 끝에 실행됩니다. 과정을 자동화 해놓으면 상당히 유용할 것입니다. 하지만, 진행 중 주의해야 할 사안이 하나 있습니다. 과도하게 컴퓨팅 자원이 많이 필요로 하는 루프는 블록체인의 속도 면에서 악영향을 끼칠 수 있고 만약 무한 루프라면 작동을 멈출 수도 있습니다. 
+- `BeginBlock`/`EndBlock` : 해당 메세지는 블록내 트랜잭션 유뮤와는 별개로 블록 시작과 끝 단계에서 실행됩니다. 여기에서 로직의 자동 실행을 설정하는 것이 유용합니다. 하지만 복잡한 연산 또는 루프는 블록체인의 속도를 저하할 수 있으며, 무한 루프의 경우 블록체인을 멈출 수 있습니다.

-ABCI 메소드와 타입에 대해서 더 자세하게 싶다면, [여기](https://tendermint.com/docs/spec/abci/abci.html#overview)를 클릭하십시오. 
+ABCI 메소드와 타입에 대해서 더 자세하게 싶다면, [텐더민트 문서](https://tendermint.com/docs/spec/abci/abci.html#overview)를 참고하세요. 

-텐더민트 상에서 구현된 모든 어플리케이션은 ABCI 인터페이스를 구현해야만 합니다. 그래야 로컬 텐더민트 엔진과 통신할 수 있습니다. 다행스럽게도, 당신이 스스로 직접 ABCI 인터페이스를 구현할 필요는 없습니다. Cosmos SDK 가 [baseapp](https://cosmos.network/docs/intro/sdk-design.html#baseapp) 의 형태로 boilerplate 를 제공합니다. 
+텐더민트 위에 구현된 모든 어플리케이션은 하위 텐더민트 엔진과 소통하기 위해 ABCI 인터페이스를 구현해야만 합니다. 물론 코스모스 SDK를 사용하는 경우, 코스모스 SDK가 [baseapp](https://cosmos.network/docs/intro/sdk-design.html#baseapp) 의 형태로 일종의 템플릿를 제공합니다. 

-### 자 이제 다음단계로 [SDK 고수준 설계 원칙에 대해서 알아보자.](https://cosmos.network/docs/intro/sdk-design.html#baseapp)  
+### 다음은 [SDK 설계 원칙에 대해서 알아보세요](https://cosmos.network/docs/intro/sdk-design.html#baseapp)  
--- a/docs/kr/intro/sdk-design.md
+++ b/docs/kr/intro/sdk-design.md
@ -0,0 +1,95 @@
+<!--
+order: 4
+-->
+
+# 코스모스 SDK의 주요 구성 요소
+
+코스모스 SDK는 텐더민트 위에서 안전한 상태 기계를 구현하는 프레임워크입니다. 핵심적으로, 코스모스 SDK는 일종의 Go 언어로 구현된 [ABCI](./sdk-app-architecture.md#abci) 구현체 템플릿입니다. 코스모스 SDK에는 데이터를 지속하는 [`multistore`](../core/store.md#multistore)와 트래잭션을 처리하는 [`router`](../core/baseapp.md#routing)가 내장되어 있습니다.
+
+다음은 코스모스 SDK로 만들어진 애플리케이션에서 텐더민트에서 `DeliverTx`로 전달된 트랜잭션이 처리되는 과정을 간소화한 설명입니다:
+
+1. 텐더민트 컨센서스 엔진(텐더민트는 `[]bytes`만을 다룬다는 것을 참고하세요)에서 전달된 `transaction`을 디코딩
+2. `transaction`에서 `messages`를 추출한 후 기본적인 타당성 검사를 진행
+3. 각 메시지가 처리될 수 있게 올바른 모듈에게 라우팅
+4. 상태 변경 실행
+
+## `baseapp`
+
+`baseapp`은 코스모스 SDK 애플리케이션 구현체 템플릿입니다. 하위 컨센서스 엔진과 연결을 처리하기 위한 구현체가 포함 되어있습니다. 통상, 코스모스 SDK 애플리케이션에서는 [`app.go`](../basics/app-anatomy.md#core-application-file)내에 `baseapp`을 임베딩합니다. 이에 대한 예시는 코스모스 SDK 애플리케이션 튜토리얼을 참고하세요:
+
+++ https://github.com/cosmos/sdk-tutorials/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/app.go#L72-L92
+
+`baseapp`의 목표는 스토어와 확장 가능한 상태 기계간의 안전한 인터페이스를 제공함과 동시에 상태 기계를 최소한으로 정의하는(ABCI 디자인 목적에 따라) 것입니다.
+
+`baseapp`에 대한 추가 정보는 [여기](../core/baseapp.md)를 참조하세요.
+
+## 멀티스토어
+
+코스모스 SDK는 지속되는 상태를 위해 [`멀티스토어/multistore`](../core/store.md#multistore)를 제공합니다.멀티스토어는 개발자가 원하는 수량의 [`KVtore`](../core/store.md#base-layer-kvtores)를 선언할 수 있도록 합니다. `KVStore`는 오직 `[]byte` 타입만을 유효한 값으로 받기 때문에 자체 스트럭쳐는 [코덱](../core/encoding.md)을 사용해 마셜된 후 저장되어야 합니다.
+
+멀티스토어를 추상화한 이유는 상태를 구획화하기 위한 목적이 있으며, 각자 해당되는 모듈에 의해 관리됩니다. 멀티스토어 대한 추가 정보는 [여기](../core/store.md#multistore)를 확인하세요.
+
+## 모듈
+
+코스모스 SDK의 강점은 바로 모듈성에 있습니다. SDK 기반 애플리케이션은 다수의 상호 호환되는 모듈을 모아서 개발됩니다. 각 모듈은 상태의 특정 분야를 정의하고 자체적인 메시지/트랜잭션 처리 기능을 가지고 있으며, 코스모스 SDK는 각 메시지를 해당되는 모듈에 라우팅하는 역할을 합니다.
+
+다음은 어떻게 트랜잭션이 각 풀노드가 유효한 블록을 받았을때 애플리케이션에 의해 처리되는지를 설명합니다:
+
+```
+                                      +
+                                      |
+                                      |  DeliverTx를 통해 풀노드의 텐더민트에서
+                                      |  노드의 애플리케이션으로 전달된 트랜잭션
+                                      |
+                                      |
+                                      |
+                +---------------------v--------------------------+
+                |                애플리케이션                    |
+                |                                                |
+                |     베이스앱의 메서드를 사용해: Tx 디코딩,     |
+                |            메시지 추출 후 라우팅               |
+                |                                                |
+                +---------------------+--------------------------+
+                                      |
+                                      |
+                                      |
+                                      +---------------------------+
+                                                                  |
+                                                                  |
+                                                                  |
+                                                                  |  처리를 위해 올바른
+                                                                  |  모듈로 라우팅된 메시지
+                                                                  |
+                                                                  |
+----------------+  +---------------+  +----------------+  +------v----------+
+|                |  |               |  |                |  |                 |
+|    AUTH 모듈   |  |   BANK 모듈   |  |  STAKING 모듈  |  |    GOV 모듈     |
+|                |  |               |  |                |  |                 |
+|                |  |               |  |                |  |   메시지 처리,  |
+|                |  |               |  |                |  |  상태 업데이트  |
+|                |  |               |  |                |  |                 |
+----------------+  +---------------+  +----------------+  +------+----------+
+                                                                  |
+                                                                  |
+                                                                  |
+                                                                  |
+                                       +--------------------------+
+                                       |
+                                       | 결과 값 텐더민트로 전달
+                                       | (0=Ok, 1=Err)
+                                       v
+```
+
+각 모듈은 미니 상태 기계로 볼 쑤 있습니다. 개발자는 각 모듈이 처리하는 상태의 부분과 상태를 바꾸는 고유 메시지 타입을 정의해야합니다(*참고*: 메시지는 트랜잭션에서 `baseapp`을 통해 추출됩니다). 통상적으로, 각 모듈은 각자의 `KVStore`를 `multistore`에 선언하여 해당 모듈이 정의하는 상태의 부분을 지속합니다. 개발자는 본인의 모듈을 만들때 제 삼자의 모듈을 액세스해야할 수 있습니다. 코스모스-SDK는 오픈 프레임워크이기 때문에, 일부 모듈은 악성 모듈일 가능성이 존재하며 이런 인터-모듈 소통에서 보안 원칙이 존재합니다. 이런 원칙은 [오브젝트-가능성(object-capabilities)](../core/ocap.md)를 따릅니다. 실전에서는, 각 모듈이 다른 모듈의 액세스 권한 리스트를 관리하는 것이 아니라, 각 모듈이 `keeper`라는 특별 오브젝트를 구현하여 접근 가능한 권한을 사전에 정의합니다.
+
+SDK의 모듈은 `x/` 폴더 내에 정의되며, 핵심 모듈 중 일부는 다음과 같습니다:
+
+- `x/auth`: 계정과 서명 관리에 사용됨
+- `x/bank`: 토큰과 토큰 전송 기능에 사용됨
+- `x/staking` + `x/slashing`: 지분증명 블록체인을 만들기 위해 사용됨
+
+모두가 본인의 앱을 만들기 위해 사용할 수 있는 `x/` 내 존재하는 모듈 외에도, 코스모스 SDK는 자체 모듈을 개발할 수 있도록합니다. 이에 대한 예시는 [이 튜토리얼](https://cosmos.network/docs/tutorial/keeper.html)을 참고하세요.
+
+## 다음 {hide}
+
+[코스모스 SDK 애플리케이션 해부학](../basics/app-anatomy.md)에 대해서 알아보세요 {hide}
--- a/docs/kr/intro/why-app-specific.md
+++ b/docs/kr/intro/why-app-specific.md
@ -0,0 +1,80 @@
+<!--
+order: 2
+-->
+
+# 애플리케이션 특화 블록체인
+
+이 문서는 애플리케이션 특화 블록체인(application-specific blockchain)을 정의하고, 왜 개발자들이 스마트 컨트랙트 대신 애플리케이션 특화 블록체인을 사용하는데 장점이 있는지 설명합니다. {synopsis}
+
+## 애플리케이션 특화 블록체인은 무엇인가?
+
+애플리케이션 특화 블록체인은 하나의 애플리케이션을 운영하는데 특화된 블록체인입니다. 이더리움과 같이 하나의 블록체인 플랫폼 위에서 탈중앙화 애플리케이션을 만드는 것이 아니라, 애플리케이션 특화 블록체인은 블록체인의 모든 계층을 직접 만드는 형태입니다. 즉, 풀 노드 클라이언트, 라이트 클라이언트, 필수 인터페이스(CLI, REST, 등)를 노드와 소통하도록 개발하게 됩니다
+
+```
+                ^  +-------------------------------+  ^
+                |  |                               |  |   코스모스 SDK로 개발
+                |  |    상태 기계 = 애플리케이션   |  |
+                |  |                               |  v
+                |  +-------------------------------+
+                |  |                               |  ^
+  블록체인 노드 |  |            컨센서스           |  |
+                |  |                               |  |
+                |  +-------------------------------+  |   텐더민트 코어
+                |  |                               |  |
+                |  |            네트워킹           |  |
+                |  |                               |  |
+                v  +-------------------------------+  v
+```
+
+## 스마트 컨트랙트의 한계는 무엇인가?
+
+이더리움과 같은 버추얼 머신(virtual machine) 기반 블록체인은 2014년 당시 블록체인의 프로그램화에 대한 수요를 충족했습니다. 다수의 개발자는 복잡하고 한계가 있는 비트코인 스크립트 언어로 애플리케이션을 개발하거나, 수정하기 어려운 비트코인 코드 포크해야하는 어려움이 있었기 때문입니다.
+
+이런 시기에, 버추얼 머신 기반 블록체인은 새로운 가치 제안을 하게됩니다. 상태 기계(state machine)가 일종의 버추얼 머신을 운용하여 '스마트 컨트랙트'라는 튜링 완전한 프로그램을 실행할 수 있도록 했습니다. 이런 스마트 컨트랙트는 일시적 이벤트에 매우 적절하지만 (예, ICO) 복잡한 탈중앙화 플랫폼을 개발하는대에는 한계가 있습니다. 이유는 다음과 같습니다:
+
+- 스마트 컨트랙트는 통상 해당 버추얼 머신이 이해할 수 있는 특정 언어만으로만 개발될 수 있습니다. 이런 언어들은 다른 언어에 비교해 미숙한 부분이 많으며, 근본적으로 버추얼 머신의 한계에 의해 제한됩니다. 예를 들어, 이더리움 버추얼 머신(Ethereum Virtual Machine, EVM)은 개발자의 코드의 자동 실행을 허용하지 않습니다. 또한 개발자는 EVM의 계정 시스템을 사용해야 하며, 제한된 함수만으로 암호학 연산을 할 수 있습니다. 위 예시들은 통상 스마트 컨트랙트 플랫폼의 근본적인 **유연성의 부족함**을 보여줍니다.
+- 모든 스마트 컨트랙트는 동일한 버추얼 머신에서 실행됩니다. 이는 근본적으로 모든 스마트 컨트랙트가 한정된 자원을 위해 경쟁해야하는 구조며 **성능**의 한계를 불러옵니다. 상태 기계가 (샤딩 같은 기술을 통해) 다수의 서브 세트(subset)로 나눈다는 가정에서도, 스마트 컨트랙트는 동일한 버추얼 머신에서 실행되어야 하기 때문에 상태 기계단에서 구현된 네이티브 애플리케이션 보다 많은 성능 제한이 있습니다(내부적인 벤치마크 테스트에 따르면, 버추얼 머신을 제거함으로 약 10배 가량의 성능 증가가 있었습니다).
+- 또 다른 문제는 모든 스마트 컨트랙트가 근본적으로 동일한 환경을 공유하기 때문에 **독립성(sovereignty)**에 대한 한계가 존재합니다. 탈중앙화 애플리케이션은 다수의 이해관계자들이 존재하는 생태계입니다. 만약 애플리케이션이 범용적 버추얼 머신 블록체인에서 개발되는 경우, 애플리케이션의 이해관계자는 본인 애플리케이션에 대한 주권이 제한되며 하위 블록체인 거버넌스를 따라야합니다. 만약 애플리케이션에 버그가 존재하는 경우, 조치할 수 있는 방법이 많이 존재하지 않습니다.
+
+애플리케이션 특화 블록체인은 이런 한계점을 극복하기 위해 설계되었습니다.
+
+## 애플리케이션 특화 블록체인의 장점
+
+### 유연성
+
+애플리케이션 특화 블록체인은 개발자에게 최고의 유연성을 제공합니다:
+
+- 코스모스 블록체인의 경우, 상태 기계는 [ABCI](https://tendermint.com/docs/spec/abci/)라는 인터페이스를 통해 하위 컨센서스 엔진과 연결됩니다. 이런 인터페이스는 어떤 프로그램 언어로 구현될 수 있으며, 이는 개발자가 본인이 선호하는 프로그램 언어로 상태 기계를 구현할 수 있다는 것을 의미합니다.
+- 개발자는 본인의 상태 기계를 구현하기 위해서 다수의 프레임워크 중 하나를 선택할 수 있습니다. 현재 가장 많이 사용되는 프레임워크는 코스모스 SDK이지만, 다른 프레임워크(예, [Lotion](https://github.com/nomic-io/lotion), [Weave](https://github.com/iov-one/weave), 등)의 프레임워크가 존재합니다. 통상 프레임워크는 개발자가 선호하는 언어에 따라 결정됩니다 (예, 코스모스 SDK와 Weave는 Go언어, Lotion은 자바스크립트 등).
+- ABCI는 개발자가 본인의 애플리케이션 특화 블록체인의 컨센서스 엔진을 변경할 수 있게 합니다. 현재로써는 텐더민트만이 검증된 프레임워크이지만, 앞으로 더 많은 컨센서스 엔진이 존재할 것으로 예상됩니다.
+- 개발자가 특정 프레임워크와 컨센서스 엔진을 선택하는 경우에도, 해당 개발자는 해당 프레임워크와 엔진을 본인이 필요하는대로 변경할 수 있는 자유가 있습니다.
+- 개발자는 다수의 트레이오프(예, 검증인의 숫자 vs 트랜잭션 처리량, 안전성 vs 비동기적 환경에서의 생존성 등)와 디자인 아키텍쳐(스토리지에서 DB 또는 IAVL 트리를 사용할지, UTXO 또는 계정 모델을 사용할지)를 선택할 수 있습니다.
+- 개발자는 코드의 자동 실행을 구현할 수 이습니다. 코스모스 SDK에서는 매 블록의 시작과 끝에서 로직이 자동으로 실행될 수 있게 설계할 수 있습니다. 또한 사용하는 버추얼 머신의 환경에 극한되지 않게 애플리케이션에서 사용될 암호학을 직접 선택할 수 있습니다.
+
+위 항목들은 애플리케이션 특화 블록체인이 개발자에게 주는 유연성의 예시를 보여줍니다. 코스모스와 코스모스 SDK의 목표는 개발자 툴링이 최대한 일반적(generic)이고 구성성(composable)있도록 만드는 것에 있기때문에, 스택의 각 컴포넌트가 포크되고, 변경되고, 개선되어도 호환성을 지킬 수 있도록 설계되었습니다. 커뮤니티가 성장할수록 코어 모듈들에 대한 대안이 나올 것으로 기대되며, 이는 개발자들에게 더 많은 선택권을 제공하게 됩니다.
+
+### 성능
+
+스마트 컨트랙트의 형태로 구현되는 탈중앙화 애플리케이션은 하위 환경의 성능에 제한될 수밖에 없습니다. 탈중앙화 애플리케이션이 성능을 최적화하기 위해서는 애플리케이션 특화 블록체인으로 구성되어야 합니다. 다음은 애플리케이션 특화 블록체인의 성능적인 장점을 설명합니다:
+
+- 애플리케이션 특화 블록체인 개발자는 텐더민트 같은 새로운 컨센서스 엔진을 사용할 수 있으며, 이는 작업증명(Proof-of-work, PoW)에 비해서 상당한 성능 개선을 제공합니다.
+- 애플리케이션 특화 블록체인은 하나의 애플리케이션만을 실행하기 때문에 해당 애플리케이션은 다른 애플리케이션과 스토리지와 연산력에 대한 경쟁을 하지 않습니다. 이는 연산력과 스토리지를 위해 다른 애플리케이션과 경쟁해야하는 기존 (샤딩을 도입하지 않은) 버추얼 머신 기반 블록체인 시스템과 대치합니다.
+- 만약 버추얼 머신 기바의 블록체인이 애플리케이션 기반 샤딩과 효율적인 컨센서스 알고리즘을 제공한다고 해도, 애플리케이션의 성능은 버추얼 머신 자체에 의해 제한됩니다. 처리량(throughput)에 대한 한계는 상태 기계이며, 트랜잭션이 버추얼 머신을 통해 처리되어야 하는 것 자체가 트랜잭션 처리의 연산 복잡성을 인상하게 됩니다.
+
+### 보안 
+
+보안을 수치화하는 것은 쉽지 않으며, 플랫폼의 특성마다 다를 수 있습니다. 다만, 애플리케이션 특화 블록체인이 보안적으로 제공하는 특정 장점은 존재합니다:
+
+- 개발자는 Go 언어같은 검증된 언어로 애플리케이션 특화 블록체인을 개발할 수 있는 반면, 스마트 컨트랙트는 보통 미성숙한 언어로 개발해야 합니다.
+- 개발자는 하위 버추얼 머신이 제공하는 암호학 함수를 사용해야하는 제한이 없으며, 검증된 암호학 라이브러리를 사용하거나 자체적인 암호학 알고리즘을 적용할 수 있습니다.
+- 개발자는 하위 버추얼 머신에서 존재할 수 있는 버그 또는 메커니즘에 대한 걱정을 하지 않아도 되며, 애플리케이션 보안에만 집중할 수 있습니다.
+
+### 독립성
+
+애플리케이션 특화 블록체인이 제공하는 가장 큰 장점 중 하나는 독립성(sovereignty, 존엄성)입니다. 탈중앙화 애플리케이션에는 유저, 개발자, 서비스 제공자 등 다수의 이해 관계자가 존재합니다. 개발자가 다수의 애플리케이션이 공존하는 버추얼 머신 기반 블록체인에서 본인의 애플리케이션을 개발하는 경우 본인 애플리케이션 커뮤니티와 하위 블록체인 플랫폼 커뮤니티가 다를 수 있으며, 하위 블록체인 플랫폼 커뮤니티가 애플리케이션 커뮤니티의 거버넌스를 지배하는 관계가 형성됩니다. 버그가 존재하거나 새로운 기능이 추가되는 경우, 애플리케이션의 이해관계자는 업그레이드를 실행하는데 제한되며 하위 플랫폼의 커뮤니티가 해당 과정을 받아드리지 않는 경우, 할 수 있는 것이 없게됩니다.
+
+여기서 근본적으로 존재하는 문제는 애플리케이션의 거버넌스와 플랫폼의 거버넌스가 일치하지 않는다는 것입니다. 애플리케이션 특화 블록체인에서는 블록체인이 한 애플리케이션을 위해 존재하기 때문에 애플리케이션의 이해관계자가 블록체인 전체에 대한 통제권을 부여받게 됩니다. 이는 커뮤니티가 버그를 발견하는 경우 조치를 할 수 있는 권한을 가질 수 있으며, 자체적으로 진화하는 방향을 정할 수도 있는 장점이 있습니다.
+
+## 다음 {hide}
+
+코스모스 SDK [애플리케이션의 구조](./sdk-app-architecture.md)에 대해 알아보세요{hide}