[DOC] state.md, build.md and chain directory documents translate in K…

…orean. (#2649)

*  add md files for translation.

*  start to translation fast-sync, code_structure. add file build_KR.md, states_KR.md

* add dandelion_KR.md && simulation_KR.md for Korean translation.

*  add md files for translation.

*  start to translation fast-sync, code_structure. add file build_KR.md, states_KR.md

* add dandelion_KR.md && simulation_KR.md for Korean translation.

* remove some useless md files for translation. this is rearrange set up translation order.

*  add dot end of sentence & translate build.md in korean

*  remove fast-sync_KR.md

*  finish build_KR.md translation

*  finish build_KR.md translation

*  finish translation state_KR.md & add phrase in state.md to move other language md file

* translate blocks_and_headers.md && chain_sync.md in Korean

*  add . in chain_sync.md , translation finished in doc/chain dir.

* fix some miss typos

doc/build.md

@@ -1,6 +1,6 @@
 # Grin - Build, Configuration, and Running
 
-*Read this in other languages: [Español](build_ES.md).*
+*Read this in other languages: [Español](build_ES.md), [Korean](build_KR.md).*
 
 ## Supported Platforms
 
@@ -115,7 +115,7 @@ You can bind-mount your grin cache to run inside the container.
 docker run -it -d -v $HOME/.grin:/root/.grin grin
 ```
 If you prefer to use a docker named volume, you can pass `-v dotgrin:/root/.grin` instead.
-Using a named volume copies default configurations upon volume creation
+Using a named volume copies default configurations upon volume creation.
 
 ## Cross-platform builds
 

doc/build_KR.md

@@ -0,0 +1,131 @@
+# Grin - Build, Configuration, and Running
+
+*다른 언어로 되어있는 문서를 읽으려면:[에스파냐어](build_ES.md).
+
+## 지원하는 플랫폼들에 대해서
+
+장기적으로는 대부분의 플랫폼에서 어느정도 지원하게 될 것입니다.
+Grin 프로그래밍 언어는 `rust`로 대부분의 플랫폼들에서 빌드 할 수 있습니다.
+
+지금까지 작동하는 플랫폼은 무엇인가요?
+
+* Linux x86_64 그리고 macOS [grin + mining + development]
+* Windows 10은 아직 지원하지 않습니다 [grin kind-of builds, mining은 아직 지원하지 않음 . 도움이 필요해요!]
+
+## 요구사항
+
+* rust 1.31 버전 이상  (다음 명령어를 사용하세요. [rustup]((https://www.rustup.rs/))- 예.) `curl https://sh.rustup.rs -sSf | sh; source $HOME/.cargo/env`)
+
+  * 만약 rust 가 설치되어 있다면, 다음 명령어를 사용해서 업데이트 할 수 있습니다.
+    `rustup update`
+* clang
+* ncurses 과 libs (ncurses, ncursesw5)
+* zlib libs (zlib1g-dev or zlib-devel)
+* pkg-config
+* libssl-dev
+* linux-headers (reported needed on Alpine linux)
+* llvm
+
+Debian 기반의 배포들은 (Debian, Ubuntu, Mint, 등등) 다음 명령어 한 줄로 설치 됩니다.
+
+```sh
+apt install build-essential cmake git libgit2-dev clang libncurses5-dev libncursesw5-dev zlib1g-dev pkg-config libssl-dev llvm
+```
+
+Mac 사용자:
+
+```sh
+xcode-select --install
+brew install --with-toolchain llvm
+brew install pkg-config
+brew install openssl
+```
+
+## 빌드 순서
+
+```sh
+git clone https://github.com/mimblewimble/grin.git
+cd grin
+cargo build --release
+```
+
+Grin은 Debug 모드로 Build 할 수 있습니다. (`--release` 플래그가 사용하지 않고, `--debug` 또는 `--verbose` 플래그를 사용하세요.) 그러나 이 명령어는 암호 오퍼레이션으로 인해 큰 오버헤드를 가지므로 fast sync 가 어려울 정도로 느려집니다.
+
+## Build 에러들
+
+[트러블 슈팅 관련해서는 이 링크를 클릭하세요.](https://github.com/mimblewimble/docs/wiki/Troubleshooting)
+
+## 무엇을 Build 해야 되나요?
+
+성공적으로 빌드한다면:
+
+* `target/release/grin` - 메인 grin 바이너리 디렉토리가 생성됩니다.
+
+모든 데이터, 설정, 로그 파일들은 기본적으로 숨겨진 `~/.grin` 디렉토리에 생성되고 사용됩니다. (user home 디렉토리 안에 있습니다.)
+`~/.grin/main/grin-server.toml` 을 수정해서 모든 설정값들을 바꿀 수 있습니다.
+
+Grin은 현재 디렉토리 내에서도 데이터 파일들을 만들 수 있습니다. 밑에 있는 Bash 명령어를 작동하세요.
+
+```sh
+grin server config
+```
+
+이 명령어는 `grin-server.toml`를 현재 디렉토리에서 생성합니다.
+이 파일은 현재 디렉토리 내의 모든 데이터에 대해서 사용하도록 미리 구성되어 있습니다.
+`grin-server.toml` 파일이 있는 디렉토리에서 grin을 실행하면 기본값`~ / .grin / main / grin-server.toml` 대신 그 파일의 값을 사용하게됩니다.
+
+Testing 중에서는 Grin 바이너리를 이렇게 path 에 삽입 할 수도 있습니다.
+
+```sh
+export PATH=`pwd`/target/release:$PATH
+```
+
+만약 Grin을 root 디렉토리에서 실행한다고 가정하면, `grin` 명령어를 바로 실행할 수 있습니다. (`grin help` 명령어를 통해서 좀 더 많은 옵션을 알아보세요.)
+
+## 설정하기
+
+Grin 은 기본적으로 설정되어 있는 올바른 값으로 실행하고 `grin-server.toml`를 통해 추가로 설정하는 것이 가능합니다.
+Grin이 처음 실행될때 설정파일이 생성되고 각 사용가능한 옵션에 대한 매뉴얼을 포함하고 있습니다.
+
+`grin-server.toml` 파일을 통해 모든 Grin 서버 구성을 수행하는 것이 좋지만,
+커맨드 라인 명령어를 사용하면 `grin-server.toml` 파일의 모든설정을 덮어쓰는 것이 가능합니다.
+
+Grin을 작동시키는 명령어에 대한 도움말은 다음 명령어를 실행하세요.
+
+```sh
+grin help
+grin wallet help
+grin client help
+```
+
+## Docker 사용하기
+
+```sh
+docker build -t grin -f etc/Dockerfile .
+```
+
+floonet을 사용하려면 `etc/Dockerfile.floonet` 을 사용하세요.
+container 안에서 grin cache를 bind-mount로 사용 할 수 있습니다.
+
+```sh
+docker run -it -d -v $HOME/.grin:/root/.grin grin
+```
+
+Docker를 named volume으로 사용하는 것을 선호한다면 `-v dotgrin:/root/.grin` 명령어를 대신 사용할 수 있습니다.
+named volume샤용시 volume 생성시 기본 설정을 복사합니다.
+
+## 크로스 플랫폼 빌드
+
+Rust(Cargo)는 여러 플랫폼에서 Grin을 빌드 할 수 있습니다. 그래서 이론적으로 낮은 성능의 디바이스 에서도 인증받은 노드로 grin을 아마도 작동 시킬 수 있을것 입니다.
+예를 들자면 라즈베리 파이 같은 x96 리눅스플랫폼 위에서 `grin` 크로스 컴파일을 하고 ARM 바이너릐를 만듭니다.
+
+## Grin 사용하기
+
+[지갑 유저 가이드](https://github.com/mimblewimble/docs/wiki/Wallet-User-Guide) 위키페이지와 링크된 페이지들은 어떤 Feature 를 가지고 있는지 , 트러블 슈팅 등등에 대한 좀 더 많은 정보를 가지고 있습니다.
+
+## Grin 채굴하기
+
+Grin의 모든 마이닝 기능은 분리된 독랍형 패키지인 [grin-miner](https://github.com/mimblewimble/grin-miner)로 옮겨졌습니다.
+일단 Grin 노드가 실행되면 실행중인 노드에 대해 grin-miner를 빌드하고 실행하여 마이닝을 시작할 수 있습니다.
+
+grin-miner가 grin 노드와 통신 할 수 있게 하려면, `grin-server.toml` 설정 파일에서`enable_stratum_server = true`가 설정되어 있는지 확인하세요. 그 다음 Wallet listener인 `grin wallet listen` 명령어를 실행하세요 .

doc/chain/blocks_and_headers.md

@@ -1,5 +1,7 @@
 # Blocks and Block headers
 
+*Read this in other languages: [Korean](blocks_and_headers_KR.md).*
+
 ## Node receives block from peer (normal operation)
 
 During normal operation the Grin node will receive blocks from connected peers via the gossip protocol.

doc/chain/blocks_and_headers_KR.md

@@ -0,0 +1,38 @@
+# Blocks and Block headers
+
+## 정상 운영시 노드가 피어로부터 블록을 받는것에 대해서
+
+정상 동작 중에 Grin 노드는 가십 프로토콜을 통해 연결된 피어로부터 블록을 받습니다.
+블록과 블록 헤더의 유효성이 성공적으로 확인되면 둘 다 저장됩니다. 헤더 헤드가 최신 블록 헤더를 가리키도록 업데이트되고 블록 헤드가 최신 블록을 가리키도록 업데이트됩니다.
+
+![Simple Block](images/simple_block.png)
+
+## 노드가 처음 동기화 될때
+
+[tbd]
+
+## 노드가 블록의 상태를 따라잡기 위해 피어와 동기화 하는것에 대해서
+
+노드는 주기적으로 현재의`total_difficulty`와 연결된 모든 피어들의 `total_difficulty`를 비교할 것입니다. total_difficulty가 더 높은 피어가 표시되면이 가장 많이 일한 피어(most_work_peer)와 동기화를 시도합니다. most_work_peers가 여러 개 있으면 그 중 하나가 무작위로 선택됩니다.
+동기화 프로세스는 현재 알려진 체인 상태 (locator에 대한 자세한 정보는 [tbd] 참고하세요.)를 기반으로 "locator"를 빌드하고 그 다음 피어에게서 헤더 목록을 요청하고 해당 헤더를 선택하는 데 도움이되는 locator를 전달하면서 시작됩니다.
+헤더 목록을 수신하면 노드는 노드의 유효성을 확인한 다음 저장합니다. 각 헤더에 대해 가장 최근 헤더를 반영하도록 헤더 헤드가 업데이트 됩니다.
+그러면 노드는 헤더체인 (헤더 헤드에서 부터 역순으로)과 현재 블록체인 (블록 헤드에서부터 역순으로)을 비교하여 각 "누락한" 블록을 요청합니다. 블록은 노드보다 total_difficulty가 큰 피어에게 요청됩니다. 이 프로세스는 (노드보다) 더 높은 total_difficulty를 가진 피어가 보이지 않고 두 헤드(헤더헤드 & 블록헤드) 가 일치한 상태 (동일한 헤드 / 블록을 가리키고 있음)에 있을 때까지 반복됩니다.
+
+![Simple sync](images/simple_sync.png)
+
+## 새로운 피어가 이전에 알려지지 않은 가장 긴 fork 와 연결된 경우
+
+![Sync on fork](images/sync_on_fork.png)
+
+## 노드가 매우 뒤떨어져 있을때에 대해서 ( 500 블록 이상 )
+
+현재 헤더 검색은 약 500 헤더 (512?)의 배치로 제한됩니다.  500개 헤더의  첫 배치를 받은 이후에 새로운 헤더 체인이 되지만 새로운 체인의  total_difficulty가 기존 체인을 추월하기에 충분하지 않을 때 어떤 일이 발생하는지 정확히 설명해야합니다.
+여기서 어떻게될까요?
+
+## 노드가 블록을 성공적으로 마이닝 했을때에 대해서
+
+[tbd]
+
+## 두 블록이 같이 채굴 되었을때 ( 일시적인 포크)에 대해서
+
+[tbd]

doc/chain/chain_sync.md

@@ -1,5 +1,7 @@
 # Blockchain Syncing
 
+*Read this in other languages: [Korean](chain_sync_KR.md).*
+
 We describe here the different methods used by a new node when joining the network
 to catch up with the latest chain state. We start with reminding the reader of the
 following assumptions, which are all characteristics of Grin or MimbleWimble:
@@ -110,7 +112,7 @@ that block.
 
 If a hard fork occurs, the network may become split, forcing new nodes to always
 push their horizon back to when the hard fork occurred. While this is not a problem
-for short-term hard forks, it may become an issue for long-term or permanent forks
+for short-term hard forks, it may become an issue for long-term or permanent forks.
 To prevent this situation, peers should always be checked for hard fork related
 capabilities (a bitmask of features a peer exposes) on connection.
 

doc/chain/chain_sync_KR.md

@@ -0,0 +1,79 @@
+# 블록체인의 동기화
+
+최신 노드 상태를 따라 가기 위해 네트워크에 참여할 때 새 노드가 사용하는 여러 가지 방법을 설명합니다.
+먼저, 독자에게 다음과 같은 Grin 또는 MimbleWimble의 특성을 먼저 전제 하고 설명하겠습니다.
+
+* 해당 블록 안의 모든 블록 헤더는 체인 안에 사용하지 않는 출력값의 모든 루트해시를 가지고 있습니다.
+* 입력 또는 출력은 전체 블록 상태를 무효화하지 않고선 변조되거나 위조 될 수 없습니다
+
+오직 보안 모델에 영향을 줄 수있는 주요 노드 유형과 고급 알고리즘에만 의도적으로 초점을 두고 있습니다. 예를 들어 헤더 우선 같은 몇몇 추가 개선점들을 줄 수 있는 휴리스틱은 유용하지만 이 섹션에서는 언급하지 않을것입니다.
+
+## Full 히스토리 동기화
+
+### 설명
+
+이 모델은 대부분의 메이저 퍼블릭 블록체인 에서 "풀 노드"가 사용하는 모델입니다. 새로운 노드는 제네시스 블록에 대한 사전 정보를 가지고 있습니다. 노드는 네트워크의 다른 피어와 연결되어 피어에게 알려진 최신 블록(호라이즌 블록)에 도달 할 때까지 블록을 요청하기 시작합니다.
+
+보안 모델은 비트 코인과 비슷합니다. 전체 체인, 총 작업, 각 블록의 유효성, 전체 내용 등을 검증 할 수 있습니다. 또한 MimbleWimble 및 전체 UTXO 세트 실행들을 통해 훨씬 더 무결성 검증이 잘 수행될 수 있습니다.
+
+이 모드에서는 저장공간 최적화 또는 대역폭 최적화를 시도하지 않습니다 (예를 들자면 유효성 검증 후 Range proof 가 삭제 될 수 있습니다). 여기서 중요한 것은 기록 아카이브를 제공하고 나중에 확인 및 증명을 하게 하는 것입니다.
+
+### 무엇이 잘못 될 수 있나요?
+
+다른 블록체인과 동일하게 아래와 같은 문제가 생길 수 있습니다.
+
+* 연결된 모든 노드가 부정직하다면 (sybil 공격 또는 그와 비슷한 상태를 말합니다.), 전체 체인 상태에 대해 거짓말을 할 수 있습니다.
+* 엄청난 마이닝 파워를 가진 누군가가 전체 블록체인 기록을 다시 쓸 수 있습니다.
+* Etc.
+
+## 부분 블록체인 히스토리 동기화
+
+이 모델에서는 보안에 대해서 가능한 한 적게 ​​타협하면서 매우 빠른 동기화를 위힌 최적화를 하려고 합니다. 사실 보안 모델은 다운로드 할 데이터의 양이 훨씬 적음에도 불구하고 풀 노드와 거의 동일합니다.
+
+새로 네트워크에 참여하는 노드는 블록헤드에서 블록 수만큼 떨어진 값인 `Z`로 미리 구성됩니다. ( 원문에서는 horizon `Z` 로 표현되었습니다. 블록헤드 - 블록 = `Z`라고 할 수 있습니다. - 역자 주 ) 예를 들어 `Z = 5000` 이고 헤드가 높이 `H = 23000` 에 있으면, 가장 높은 블록은 가장 긴 체인에서 높이가 `h = 18000`인 블록입니다.
+
+또한 새로운 노드에는 제네시스 블록에 대한 사전 정보가 있습니다. 노드는 다른 피어들과 연결하고 가장 긴 체인의 헤드에 대해 알게 됩니다. 가장 높은 블록의 블록 헤더(horizon block 이라고 원문에 표시되어 있음 - 역자 주 )를 요청하며 다른 피어의 동의가 필요하게 됩니다. 컨센서스가 `h = H - Z`에 이르지 않으면 노드는 `Z`값( horizon Z 라고 원문에 표시되어 있음 - 역자 주 )을 점차 증가시켜 컨센서스가 이루어질 때까지`h`를 뒤로 이동시킵니다. 그런 다음 가장 긴 블록에서의 전체 UTXO 정보를 얻습니다. 이 정보를 통해 다음을 증명할 수 있습니다.
+
+* 모든 블록헤더안에 있는 해당 체인의 전체 난이도
+* 예상되는 코인 공급량과 같은 모든 UTXO 실행값의 합.
+* 블록헤더에 있는 루트 해시와 매치되는 모든 UTXO의 루트해시
+
+블록의 유효성 검사가 완료되면 피어는 블록 콘텐츠를 `Z`값에서 (from the horizon 이라고 원문에 표시되어 있음 - 역자 주) 헤드까지 다운로드하고 유효성을 검사 할 수 있습니다.
+
+이 알고리즘은 `Z`의 매우 낮은 값 (또는 `Z = 1`인 극단적인 경우에도)에서도 작동합니다. 그러나 어느 블록체인에서도 발생할 수있는 정상적인 포크 때문에 낮은 값이 문제가 될 수 있습니다. 이러한 문제를 방지하고 로컬 검증된 을 늘리려면 최소한 며칠 분량의 `Z`값에서 최대 몇 주간의 `Z`값을 사용하는 것을 권장합니다.
+
+### 무엇이 잘못 될 수 있나요?
+
+이 동기화 모드는 간단하게 설명 할 수 있지만 어떻게 보안을 유지 할 것인가에 대해선 불분명해 보일 수 있습니다.
+여기서는 몇몇 가능 할 수 있는 공격 유형과 퇴치 방식 및 기타 가능한 실패 시나리오에 대해 설명합니다.
+
+### 공격자가 가장 긴 블록에서 부터 상태를 위조하려고 할때
+
+이 공격은 노드가 네트워크와 올바르게 동기화되었다고 노드가 인식하도록 하나 실제로 노드가 위조 상태에 있게 합니다.
+이에 대해 아래와 같은 여러 전략을 시도 할 수 있습니다.
+
+* 완전히 가짜지만 유효한 최신 블록상태 (horizon state 라고 원문에 표시되 어있음 - 역자 주) 일때 (헤더 및 작업 증명 포함), 최소한 하나의 정직한 피어가 있다고 가정하면, UTXO 세트의 루트 해시와 블록 해시도 다른 피어의 수평 상태와 일치하지 않습니다.
+* 유효한 블록 헤더이지만 가짜 UTXO 세트일때, 헤더의 UTXO 세트의 루트 해시는 노드가 수신 한 UTXO 세트 자체에서 계산 한 것과 일치하지 않습니다.
+* 가짜 총 난이도를 가진 완전히 유효한 블록으로 노드를 가짜 포크로 유도할 경우, 전체 난이도가 변경되면 블록 해시가 변경되며 어떤 정직한 피어도 해당 해시에 유효한 헤드를 생성하지 않습니다.
+
+### 로컬 UTXO 히스토리 보다 오래된 포크가 발생하려 할때
+
+노드는 최신 블록 높이 (horizon height - 역자 주) 로 설정된 전체 UTXO를 다운로드 했습니다. 만약 수평선 H + delta에 있는 블록에서 포크가 발생하면 UTXO 세트의 유효성을 검사 할 수 없습니다. 이 상황에서 노드는 `Z '= Z + delta`인 새로운 `Z`값 (new horizon - 역자 주) 을 가진 동기화 모드로 돌아 갈 수 밖에 없습니다.
+
+(네트웍에서 받아들여지는) 승리한 포크는 현재의 (우리의) 헤드보다 작업 증명의 총 량이 더 많은 헤드일 뿐이라서 현재의 헤드보다 더 적은 작업 증명인 Z + delta의 다른 포크는 무시 될 수 있습니다. 이 방법을 위해서 모든 블록 헤더에는 해당 블록까지의 총 체인 난이도가 포함됩니다.
+
+#### 체인이 완전히 포크되었을 때
+
+하드포크가 발생하면 네트워크가 분리되고 새로운 노드는 하드포크가 발생했을 때로 자신의 최신 블록 상태(horizon)을 항상 되돌릴 것을 강제합니다. 짧은 기간의 하드포크에는 문제가 되지 않지만 장기 또는 완전한 하드포크에선 문제가 될 수 있습니다. 이러한 상황을 방지하기 위해, 피어는 연결이 될때 하드포크 관련 기능 (피어가 노출하는 피쳐의 bitmask)을 항상 확인해야합니다.
+
+### 몇몇 노드가 가짜 최신블록 (호라이즌 블록)을 지속적으로 줄 때
+
+피어가 만약 h의 헤더에서 컨센서스에 도달 할 수 없으면 서서히 뒤로 돌아갑니다 (블록의 유효성을 확인하기 위해). 뒤로 물러나는 유효성을 확인하는 경우, 사기꾼 피어는 시스템적으로 합의가 이뤄지는것을 막고 가짜 헤더를 보내 줌으로써 모든 새로운 피어가 제네시스 블록까지 (유효성을 확인하기 위해) 뒤로 이동하게 함으로써 항상 풀 노드가 되도록 강제 할 수 있습니다.
+
+상기 얘기한 상태는 유효한 문제이긴 하지만 이래와 같이 몇가지 완화 전략이 있습니다.
+
+* 피어는`Z`값 (Horizon Z)에서 유효한 블록 헤더를 제공해야합니다. 여기에는 작업 증명이 포함됩니다.
+* 최신 블록 (Horizon) 주위의 블록 헤더 그룹은 공격 비용을 증가 시키도록 요청받을 수 있습니다.
+* 현저하게 낮은 작업 증명을 제공하는 상이한 블록 헤더는 거부 될 수 있습니다.
+* 사용자 또는 노드 운영자는 블록 해시를 확인하도록 요청받을 수 있습니다.
+* 최후의 수단으로 위의 전략 중 어느 것도 효과적이지 않으면 체크포인트를 사용할 수 있습니다.

doc/state.md

@@ -1,5 +1,7 @@
 # State and Storage
 
+*Read this in other languages: [Korean](state_KR.md).*
+
 ## The Grin State
 
 ### Structure