From 9139a5578daccb871829d8ef4695c011fb602799 Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Thu, 14 Feb 2019 18:34:34 +0900 Subject: [PATCH 01/25] Start to M/W intro translate in Korean --- doc/intro.md | 87 +++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 63 insertions(+), 24 deletions(-) diff --git a/doc/intro.md b/doc/intro.md index 6124448526..feeac0c56b 100644 --- a/doc/intro.md +++ b/doc/intro.md @@ -7,68 +7,107 @@ extremely good scalability, privacy and fungibility by relying on strong cryptographic primitives. It addresses gaps existing in almost all current blockchain implementations. +MimbleWimlbe ㅇㅡㄴ 블록체인 포맷이면서 프로토콜 입니다. +MimbleWimble 은 암호학적 기반에 의해서 극대화된 좋은 확장성, 프라이버시, 그리고 대체가능성을 제공합니다. +이러한 특성은 지금 현존하는 모든 블록체인 구현체에 존재하는 문제점들을 처리합니다. + + Grin is an open source software project that implements a MimbleWimble blockchain and fills the gaps required for a full blockchain and cryptocurrency deployment. +Grin 은 Mimble Wimble 블록체인을 구현한 오픈소스 프로젝트 입니다. +또한 완전한 블록체인와 크립토 커런시의 배포에 필요한 갭을 채워줍니다. + The main goal and characteristics of the Grin project are: +Grin 프로젝트의 주요 목적과 특성들은 아래 설명을 참고하십시오. * Privacy by default. This enables complete fungibility without precluding the ability to selectively disclose information as needed. +* 프라이버시가 기본으로 제공됩니다. 이 기능은 필요에 따라서 선택적으로 정보를 공개 할 수 없도록 해서 완전한 대체가능성을 할 수 있게 합니다. * Scales mostly with the number of users and minimally with the number of transactions (<100 byte `kernel`), resulting in a large space saving compared to other blockchains. +* 주로 유저의 규모와 최소한의 트랜잭션 수의 규모로 (100byte 미만의 kernel(transaction)) 다른 블록체인들과 비교하면 많은 공간을 절약할 수 있습니다. * Strong and proven cryptography. MimbleWimble only relies on Elliptic Curve Cryptography which has been tried and tested for decades. +* Mimble Wimble 은 수십년 동안 테스트하고 사용되었던 강력한 암호기술인 ECC만 사용합니다. * Design simplicity that makes it easy to audit and maintain over time. +* 간단한 디자인은 감사와 유지보수를 시간이 지나도 수월하게 만듭니다. * Community driven, encouraging mining decentralization. - +* 커뮤니티가 주도하며, 채굴 탈중앙화가 권장됩니다. + ## Tongue Tying for Everyone - +## 모두의 혀를 묶자. This document is targeted at readers with a good -understanding of blockchains and basic cryptography. With that in mind, we attempt -to explain the technical buildup of MimbleWimble and how it's applied in Grin. We hope -this document is understandable to most technically-minded readers. Our objective is +understanding of blockchains and basic cryptography. +이 문서는 블록체인에 대해 어느정도 이해가 있고 암호학에 대한 기본적인 이해가 있는 독자들을 대상으로 합니다. + +With that in mind, we attempt to explain the technical buildup of MimbleWimble and how it's applied in Grin. +이것을 염두에 두고 우리는 MimbleWimble의 기술적인 발전과 어떻게 Grin에 적용되었는지 관해 설명할것입니다. + +We hope this document is understandable to most technically-minded readers. Our objective is to encourage you to get interested in Grin and contribute in any way possible. +저희는 이 문서가 대부분의 기술적인 성격을 가진 독자들을 이해시킬 수 있길 바랍니다. +우리의 목적은 독자가 Grin에 대해 흥기를 느끼게 하고 어떤 방식으로든 Grin에 기여할 수 있게 이끄는 것입니다. + +To achieve this objective, we will introduce the main concepts required for a good understanding of Grin as a MimbleWimble implementation. +이러한 목적을 이루기 위해, 우리는 MimbleWimble 의 구현체인 Grin을 이해하는데 필요한 주요 컨셉들에 대해서 소개할것입니다. -To achieve this objective, we will introduce the main concepts required for a good -understanding of Grin as a MimbleWimble implementation. We will start with a brief -description of some relevant properties of Elliptic Curve Cryptography (ECC) to lay the -foundation on which Grin is based and then describe all the key elements of a -MimbleWimble blockchain's transactions and blocks. +We will start with a brief description of some relevant properties of Elliptic Curve Cryptography (ECC) to lay the foundation on which Grin is based and then describe all the key elements of a MimbleWimble blockchain's transactions and blocks. +우선 Grin이 어디에서 부터 기초로 하고 있는지에 대해 이해하기 위해서 타원 곡선 암호 (ECC)의 몇몇 속성들에 대한 간단한 설명으로 시작하겠습니다. 그 다음, MimbleWimble 블록체인의 트랜잭션과 블록에 한 모든 요소들을 설명하겠습니다. ### Tiny Bits of Elliptic Curves +### 타원곡선에 대한 조그마한 조각들 We start with a brief primer on Elliptic Curve Cryptography, reviewing just the properties necessary to understand how MimbleWimble works and without -delving too much into the intricacies of ECC. For readers who would want to -dive deeper into those assumptions, there are other opportunities to -[learn more](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/). +delving too much into the intricacies of ECC. + +- ECC의 너무 복잡한 사항을 캐지 않고 어떻게 mimble wimble 이 어떻게 작동하는지에 대해 이해하는데 필요한 요소들만 리뷰할 것입니다. + + For readers who would want to dive deeper into those assumptions, there are other opportunities to [learn more](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/). +- 이런 가정들을 좀 더 알고싶은 독자들은 [이 링크]() 를 참고하세요. An Elliptic Curve for the purpose of cryptography is simply a large set of points that we will call _C_. These points can be added, subtracted, or multiplied by integers (also called scalars). -Given an integer _k_ and -using the scalar multiplication operation we can compute `k*H`, which is also a point on -curve _C_. Given another integer _j_ we can also calculate `(k+j)*H`, which equals -`k*H + j*H`. The addition and scalar multiplication operations on an elliptic curve -maintain the commutative and associative properties of addition and multiplication: +암호학에서의 타원 곡선이란 우리가 _C_ 라고 부르는 단순히 아주 큰 좌표의 집합입니다. +이 좌표들은 정수들로 (인티저, 또는 스칼라 ) 더하고 빼고 곱할수 있습니다. + +Given an integer _k_ and using the scalar multiplication operation we can compute `k*H`, which is also a point on curve _C_. +주어진 정수 _K_ 에 스칼라 곱셈을 한다면 우리는 곡선 _c_ 위에 있는 좌표 K*H를 계산 할 수 있습니다. + +Given another integer _j_ we can also calculate `(k+j)*H`, which equals `k*H + j*H`. +또 달리 주어진 정수 _j_ 에 우리는`k*H + j*H` 와 같은 `(k+j)*H`를 계산 할 수 있습니다. + +The addition and scalar multiplication operations on an elliptic curve maintain the commutative and associative properties of addition and multiplication: +타원곡선 위에서의 덧셈과 정수 곱셈은 제시덴 수의 순서에 관계없이 결과가 동일하다는 성질과 덧셈과 곱셈의 계산 순서와 관계없이 동일한 결과가 나온다는 성질을 가지고 있습니다. + + (k+j)*H = k*H + j*H In ECC, if we pick a very large number _k_ as a private key, `k*H` is -considered the corresponding public key. Even if one knows the -value of the public key `k*H`, deducing _k_ is close to impossible (or said -differently, while multiplication is trivial, "division" by curve points is +considered the corresponding public key. +ECC 안에서 우리가 매우 큰 숫자인 _k_ 를 프라이빗 키로 가정할 때 `k*H` 는 해당하는 퍼블릭 키로 해당되어 집니다. + +Even if one knows the value of the public key `k*H`, deducing _k_ is close to impossible (or said differently, while multiplication is trivial, "division" by curve points is extremely difficult). + + The previous formula `(k+j)*H = k*H + j*H`, with _k_ and _j_ both private keys, demonstrates that a public key obtained from the addition of two private keys (`(k+j)*H`) is identical to the addition of the public keys for each of those -two private keys (`k*H + j*H`). In the Bitcoin blockchain, Hierarchical -Deterministic wallets heavily rely on this principle. MimbleWimble and the Grin -implementation do as well. +two private keys (`k*H + j*H`). + +In the Bitcoin blockchain, Hierarchical Deterministic wallets heavily rely on this principle. +Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. +MimbleWimble and the Grin implementation do as well. +MimbleWimble 과 Grin의 구현또한 마찬가지 입니다. ### Transacting with MimbleWimble +### MimbleWimble 함께 거래하기 The structure of transactions demonstrates a crucial tenet of MimbleWimble: strong privacy and confidentiality guarantees. From 30cf99f37fdf1e6be51205253bb1bc34f6f9036e Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Thu, 14 Feb 2019 18:58:05 +0900 Subject: [PATCH 02/25] translate in Korean --- doc/intro.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/doc/intro.md b/doc/intro.md index feeac0c56b..c66b53d11d 100644 --- a/doc/intro.md +++ b/doc/intro.md @@ -93,7 +93,7 @@ ECC 안에서 우리가 매우 큰 숫자인 _k_ 를 프라이빗 키로 가정 Even if one knows the value of the public key `k*H`, deducing _k_ is close to impossible (or said differently, while multiplication is trivial, "division" by curve points is extremely difficult). - +누군가 공개키인 `k*H`의 값을 알더라도 _k_ 를 추론해 내는것은 불가능에 가깝습니다. ( 달리 얘기하자면, 곱셉은 쉬우나 곡선 좌표에 의한 "나눗셈"은 정말 어렵습니다. ) The previous formula `(k+j)*H = k*H + j*H`, with _k_ and _j_ both private @@ -101,6 +101,8 @@ keys, demonstrates that a public key obtained from the addition of two private keys (`(k+j)*H`) is identical to the addition of the public keys for each of those two private keys (`k*H + j*H`). + + In the Bitcoin blockchain, Hierarchical Deterministic wallets heavily rely on this principle. Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. MimbleWimble and the Grin implementation do as well. From 7898bda3e773f5ac3d3bcfcb8163019578193433 Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Thu, 14 Feb 2019 21:33:38 +0900 Subject: [PATCH 03/25] translate in Korean --- doc/intro.md | 33 +++++++++++++++++++-------------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/doc/intro.md b/doc/intro.md index c66b53d11d..f75842d3a9 100644 --- a/doc/intro.md +++ b/doc/intro.md @@ -83,8 +83,6 @@ Given another integer _j_ we can also calculate `(k+j)*H`, which equals `k*H + j The addition and scalar multiplication operations on an elliptic curve maintain the commutative and associative properties of addition and multiplication: 타원곡선 위에서의 덧셈과 정수 곱셈은 제시덴 수의 순서에 관계없이 결과가 동일하다는 성질과 덧셈과 곱셈의 계산 순서와 관계없이 동일한 결과가 나온다는 성질을 가지고 있습니다. - - (k+j)*H = k*H + j*H In ECC, if we pick a very large number _k_ as a private key, `k*H` is @@ -100,8 +98,7 @@ The previous formula `(k+j)*H = k*H + j*H`, with _k_ and _j_ both private keys, demonstrates that a public key obtained from the addition of two private keys (`(k+j)*H`) is identical to the addition of the public keys for each of those two private keys (`k*H + j*H`). - - +_k_ 와 _j_ 둘다 비밀키인 이전 공식 `(k+j)*H = k*H + j*H` 는 두개의 비밀키를 더해서 얻은 한 개의 공개키 (`(k+j)*H`) 와 각각 두개의 비밀키에 공개키를 더한것과 같습니다. In the Bitcoin blockchain, Hierarchical Deterministic wallets heavily rely on this principle. Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. @@ -112,40 +109,48 @@ MimbleWimble 과 Grin의 구현또한 마찬가지 입니다. ### MimbleWimble 함께 거래하기 The structure of transactions demonstrates a crucial tenet of MimbleWimble: +트랜잭션의 구조는 MimbleWimble의 강력한 프라이버시와 비밀이 유지된다라고 하는 중요한 규칙을 나타냅니다. strong privacy and confidentiality guarantees. The validation of MimbleWimble transactions relies on two basic properties: - +MimbleWimble 트랜잭션의 확인은 두가지 기본적인 성격을 전제로 합니다. * **Verification of zero sums.** The sum of outputs minus inputs always equals zero, proving that the transaction did not create new funds, _without revealing the actual amounts_. +* **제로섬의 검증** 결과값에서 입력값을 뺸 합은 항상 0과 같습니다. 이것은 실제 전송되는 코인의 양을 드러내지 않고도 트랜잭션ㅇ이 새로운 코인을 만들지 않았다는 것을 증명합니다. * **Possession of private keys.** Like with most other cryptocurrencies, ownership of transaction outputs is guaranteed by the possession of ECC private keys. However, the proof that an entity owns those private keys is not achieved by directly signing the transaction. +* **비밀키의 소유** 다른 많은 크립토커런시들 처럼 , 트랜잭션의 소유권은 ECC 비밀키에 의해 보장됩니다. 그러나 어떤 실체가 이런 비밀키들을 소유하고 있다고 증명하는것이 직접적으로 트랜잭션에 사인한다고해서 얻어지는 것은 아닙니다. The next sections on balance, ownership, change and proofs details how those two fundamental properties are achieved. +다음 섹션들에서는 잔고, 소유권, 거스름돈과 증명들의 상세들이 어떻게 저 두가지 기본적인 성질에 의해서 얻어지는지 알아보겠습니다. #### Balance +#### 잔고 Building upon the properties of ECC we described above, one can obscure the values in a transaction. +위에서 언급한 ECC의 특성들을 기반으로 해서 트랜잭션안의 가치들을 보기 어렵게 할 수 있습니다. If _v_ is the value of a transaction input or output and _H_ an elliptic curve, we can simply -embed `v*H` instead of _v_ in a transaction. This works because using the ECC -operations, we can still validate that the sum of the outputs of a transaction equals the -sum of inputs: +embed `v*H` instead of _v_ in a transaction. +만약 _v_ 가 트랜잭션 입력값이거나 출력값이고 _H_가 타원곡선이라면 , 단순히 _v_ 대신 `v*H`를 끼워넣을 수 있습니다. + +This works because using the ECC operations, we can still validate that the sum of the outputs of a transaction equals the sum of inputs: +이것은 ECC를 사용하기 때문에 작동하는 것입니다. 우리는 출력값의 합이 입력값의 합과 같다는 것을 여전히 확인할 수 있습니다. v1 + v2 = v3 => v1*H + v2*H = v3*H Verifying this property on every transaction allows the protocol to verify that a transaction doesn't create money out of thin air, without knowing what the actual -values are. However, there are a finite number of usable values and one could try every single -one of them to guess the value of your transaction. In addition, knowing v1 (from -a previous transaction for example) and the resulting `v1*H` reveals all outputs with -value v1 across the blockchain. For these reasons, we introduce a second elliptic curve -_G_ (practically _G_ is just another generator point on the same curve group as _H_) and -a private key _r_ used as a *blinding factor*. +values are. +이 특성을 모든 트랜잭션에 확인하는것은 프로토콜이 트랜잭션은 돈을 난데없이 만들지 않는다는 것을 실제 돈이 얼마나 있는지 알지 않아도 검증할 수 있게 합니다. +However, there are a finite number of usable values and one could try every single +one of them to guess the value of your transaction. +그러나 +In addition, knowing v1 (from a previous transaction for example) and the resulting `v1*H` reveals all outputs with value v1 across the blockchain. For these reasons, we introduce a second elliptic curve _G_ (practically _G_ is just another generator point on the same curve group as _H_) and a private key _r_ used as a *blinding factor*. An input or output value in a transaction can then be expressed as: From 2c9f57ff1b1e8e03b37ecbc8f0a5793c1e39edf5 Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Thu, 14 Feb 2019 21:53:52 +0900 Subject: [PATCH 04/25] translate in Korean --- doc/intro.md | 57 +++++++++++++++++++++++++++++----------------------- 1 file changed, 32 insertions(+), 25 deletions(-) diff --git a/doc/intro.md b/doc/intro.md index f75842d3a9..6f6caf39e2 100644 --- a/doc/intro.md +++ b/doc/intro.md @@ -98,34 +98,33 @@ The previous formula `(k+j)*H = k*H + j*H`, with _k_ and _j_ both private keys, demonstrates that a public key obtained from the addition of two private keys (`(k+j)*H`) is identical to the addition of the public keys for each of those two private keys (`k*H + j*H`). -_k_ 와 _j_ 둘다 비밀키인 이전 공식 `(k+j)*H = k*H + j*H` 는 두개의 비밀키를 더해서 얻은 한 개의 공개키 (`(k+j)*H`) 와 각각 두개의 비밀키에 공개키를 더한것과 같습니다. - +_k_ 와 _j_ 둘다 비밀키인 이전 공식 `(k+j)*H = k*H + j*H` 는 두개의 비밀키를 더해서 얻은 한 개의 공개키 (`(k+j)*H`) 와 각각 두개의 비밀키에 공개키를 더한것과 같습니다. In the Bitcoin blockchain, Hierarchical Deterministic wallets heavily rely on this principle. Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. MimbleWimble and the Grin implementation do as well. -MimbleWimble 과 Grin의 구현또한 마찬가지 입니다. +MimbleWimble 과 Grin의 구현또한 마찬가지 입니다. ### Transacting with MimbleWimble ### MimbleWimble 함께 거래하기 The structure of transactions demonstrates a crucial tenet of MimbleWimble: -트랜잭션의 구조는 MimbleWimble의 강력한 프라이버시와 비밀이 유지된다라고 하는 중요한 규칙을 나타냅니다. +트랜잭션의 구조는 MimbleWimble의 강력한 프라이버시와 비밀이 유지된다라고 하는 중요한 규칙을 나타냅니다. strong privacy and confidentiality guarantees. The validation of MimbleWimble transactions relies on two basic properties: -MimbleWimble 트랜잭션의 확인은 두가지 기본적인 성격을 전제로 합니다. +MimbleWimble 트랜잭션의 확인은 두가지 기본적인 성격을 전제로 합니다. * **Verification of zero sums.** The sum of outputs minus inputs always equals zero, proving that the transaction did not create new funds, _without revealing the actual amounts_. -* **제로섬의 검증** 결과값에서 입력값을 뺸 합은 항상 0과 같습니다. 이것은 실제 전송되는 코인의 양을 드러내지 않고도 트랜잭션ㅇ이 새로운 코인을 만들지 않았다는 것을 증명합니다. +* **제로섬의 검증** 결과값에서 입력값을 뺸 합은 항상 0과 같습니다. 이것은 실제 전송되는 코인의 양을 드러내지 않고도 트랜잭션ㅇ이 새로운 코인을 만들지 않았다는 것을 증명합니다. * **Possession of private keys.** Like with most other cryptocurrencies, ownership of transaction outputs is guaranteed by the possession of ECC private keys. However, the proof that an entity owns those private keys is not achieved by directly signing the transaction. -* **비밀키의 소유** 다른 많은 크립토커런시들 처럼 , 트랜잭션의 소유권은 ECC 비밀키에 의해 보장됩니다. 그러나 어떤 실체가 이런 비밀키들을 소유하고 있다고 증명하는것이 직접적으로 트랜잭션에 사인한다고해서 얻어지는 것은 아닙니다. +* **비밀키의 소유** 다른 많은 크립토커런시들 처럼 , 트랜잭션의 소유권은 ECC 비밀키에 의해 보장됩니다. 그러나 어떤 실체가 이런 비밀키들을 소유하고 있다고 증명하는것이 직접적으로 트랜잭션에 사인한다고해서 얻어지는 것은 아닙니다. The next sections on balance, ownership, change and proofs details how those two fundamental properties are achieved. -다음 섹션들에서는 잔고, 소유권, 거스름돈과 증명들의 상세들이 어떻게 저 두가지 기본적인 성질에 의해서 얻어지는지 알아보겠습니다. +다음 섹션들에서는 잔고, 소유권, 거스름돈과 증명들의 상세들이 어떻게 저 두가지 기본적인 성질에 의해서 얻어지는지 알아보겠습니다. #### Balance #### 잔고 @@ -135,65 +134,73 @@ in a transaction. 위에서 언급한 ECC의 특성들을 기반으로 해서 트랜잭션안의 가치들을 보기 어렵게 할 수 있습니다. If _v_ is the value of a transaction input or output and _H_ an elliptic curve, we can simply -embed `v*H` instead of _v_ in a transaction. -만약 _v_ 가 트랜잭션 입력값이거나 출력값이고 _H_가 타원곡선이라면 , 단순히 _v_ 대신 `v*H`를 끼워넣을 수 있습니다. +embed `v*H` instead of _v_ in a transaction. +만약 _v_ 가 트랜잭션 입력값이거나 출력값이고 _H_가 타원곡선이라면 , 단순히 _v_ 대신 `v*H`를 끼워넣을 수 있습니다. This works because using the ECC operations, we can still validate that the sum of the outputs of a transaction equals the sum of inputs: -이것은 ECC를 사용하기 때문에 작동하는 것입니다. 우리는 출력값의 합이 입력값의 합과 같다는 것을 여전히 확인할 수 있습니다. +이것은 ECC를 사용하기 때문에 작동하는 것입니다. 우리는 출력값의 합이 입력값의 합과 같다는 것을 여전히 확인할 수 있습니다. v1 + v2 = v3 => v1*H + v2*H = v3*H Verifying this property on every transaction allows the protocol to verify that a transaction doesn't create money out of thin air, without knowing what the actual -values are. -이 특성을 모든 트랜잭션에 확인하는것은 프로토콜이 트랜잭션은 돈을 난데없이 만들지 않는다는 것을 실제 돈이 얼마나 있는지 알지 않아도 검증할 수 있게 합니다. +values are. +이 특성을 모든 트랜잭션에 확인하는것은 프로토콜이 트랜잭션은 돈을 난데없이 만들지 않는다는 것을 실제 돈이 얼마나 있는지 알지 않아도 검증할 수 있게 합니다. However, there are a finite number of usable values and one could try every single -one of them to guess the value of your transaction. -그러나 -In addition, knowing v1 (from a previous transaction for example) and the resulting `v1*H` reveals all outputs with value v1 across the blockchain. For these reasons, we introduce a second elliptic curve _G_ (practically _G_ is just another generator point on the same curve group as _H_) and a private key _r_ used as a *blinding factor*. +one of them to guess the value of your transaction. +그러나 사용가능한 한정된 숫자가 있고 그 숫자 중 하나를 사용해서 당신의 트랜잭션이 얼마만큼의 코인을 가졌는지 추측해 할 수 있습니다. +In addition, knowing v1 (from a previous transaction for example) and the resulting `v1*H` reveals all outputs with value v1 across the blockchain. +더해서 , v1을 알고 ( 예시로 사용된 이전의 트랜잭션에서 온 값 ) 그에따른 `v1*H`의 결과를 알면 블록체인 전체에 걸쳐서 v1 값이 있는 모든 출력값들이 드러나게 됩니다. -An input or output value in a transaction can then be expressed as: +For these reasons, we introduce a second elliptic curve _G_ (practically _G_ is just another generator point on the same curve group as _H_) and a private key _r_ used as a *blinding factor*. +이러한 이유때문에 우리는 두번째 타원곡선인 _G_를 제시합니다. ( 실제로 _G_ 는 _H_ 의 그룹과 같은 곡선에 있는 단지 다른 좌표를 생성해 냅니다.) 그리고 비밀키 _r_은 *blinding factor* 로 사용됩니다. +An input or output value in a transaction can then be expressed as: +그렇다면 트랜잭션 안의 입력값과 출력값은 다음과 같이 표현됩니다. r*G + v*H - Where: - +여기서 * _r_ is a private key used as a blinding factor, _G_ is an elliptic curve and their product `r*G` is the public key for _r_ on _G_. +* _r_ 은 비밀키이고 blinding factor 로 사용됩니다. _G_ 는 타원 곡선 이고 `r*G`는 _G_ 안에 있는 _r_ 의 공개키 입니다. * _v_ is the value of an input or output and _H_ is another elliptic curve. - +* _v_ 는 출력값이거나 입력값이고 _H_ 는 다른 타원곡선입니다. Neither _v_ nor _r_ can be deduced, leveraging the fundamental properties of Elliptic Curve Cryptography. `r*G + v*H` is called a _Pedersen Commitment_. - +타원곡선의 근본적인 특성을 이용했기 때문에 _v_ 와 _r_ 은 추측될 수 없습니다. `r*G + v*H`를 _Pedersen Commitment_ 라고 부릅니다. As a an example, let's assume we want to build a transaction with two inputs and one output. We have (ignoring fees): - +예를 들어 , ( 전송료는 무시하고) 두개의 입력값과 한개의 출력값으로 트랜잭션을 만들기 원한다고 가정해봅시다. * vi1 and vi2 as input values. +* vi1 과 v2 는 출력값 * vo3 as output value. - +* vo3는 출력값 이라면 Such that: vi1 + vi2 = vo3 Generating a private key as a blinding factor for each input value and replacing each value with their respective Pedersen Commitments in the previous equation, we obtain: +각각의 입력값에 대해서 blining factor 로 비밀키를 만들고 각각의 값을 각각의 이전의 공식에 있던 Pederson Commitment로 교체한다고 하면 다음과 같습니다. (ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vo3*H) Which as a consequence requires that: - +결과로 다음과 같습니다. ri1 + ri2 = ro3 This is the first pillar of MimbleWimble: the arithmetic required to validate a transaction can be done without knowing any of the values. +이것이 MimbleWimble의 첫번째 특징입니다. 트랜잭션을 검증하는 산술적인 연산은 아무런 값을 알지 못해도 가능합니다. As a final note, this idea is actually derived from Greg Maxwell's [Confidential Transactions](https://elementsproject.org/features/confidential-transactions/investigation), which is itself derived from an Adam Back proposal for homomorphic values applied to Bitcoin. +마지막으로 이 아이디어는 Greg Maxwell 의 [Confidential Transactions](https://elementsproject.org/features/confidential-transactions/investigation) 에서 유래했습니다. Confidential transaction은 Adam back의 비트코인에 동형암호를 적용하자는 제안에서 비롯되었습니다. #### Ownership - +#### 소유권 In the previous section we introduced a private key as a blinding factor to obscure the transaction's values. The second insight of MimbleWimble is that this private key can be leveraged to prove ownership of the value. From 470b1ccb2607700fa74154f41acc1db4272b3d01 Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Thu, 14 Feb 2019 22:34:49 +0900 Subject: [PATCH 05/25] translate in Korean --- doc/intro.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/doc/intro.md b/doc/intro.md index 6f6caf39e2..df4993f6de 100644 --- a/doc/intro.md +++ b/doc/intro.md @@ -202,7 +202,9 @@ to Bitcoin. #### Ownership #### 소유권 In the previous section we introduced a private key as a blinding factor to obscure the -transaction's values. The second insight of MimbleWimble is that this private +transaction's values. + +The second insight of MimbleWimble is that this private key can be leveraged to prove ownership of the value. Alice sends you 3 coins and to obscure that amount, you chose 28 as your From ca9560ba8d7e09d8fa732ae7e647f80e57abe368 Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Fri, 15 Feb 2019 14:32:30 +0900 Subject: [PATCH 06/25] add korean translation on intro --- doc/intro.KR.md | 508 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 508 insertions(+) create mode 100644 doc/intro.KR.md diff --git a/doc/intro.KR.md b/doc/intro.KR.md new file mode 100644 index 0000000000..9650e676cd --- /dev/null +++ b/doc/intro.KR.md @@ -0,0 +1,508 @@ +# Introduction to MimbleWimble and Grin + +*Read this in other languages: [English](intro.md), [简体中文](intro.zh-cn.md), [Español](intro_ES.md), [Русский](intro.ru.md), [日本語　](intro.jp.md).* + +MimbleWimble is a blockchain format and protocol that provides +extremely good scalability, privacy and fungibility by relying on strong +cryptographic primitives. It addresses gaps existing in almost all current +blockchain implementations. + +MimbleWimlbe ㅇㅡㄴ 블록체인 포맷이면서 프로토콜 입니다. +MimbleWimble 은 암호학적 기반에 의해서 극대화된 좋은 확장성, 프라이버시, 그리고 대체가능성을 제공합니다. +이러한 특성은 지금 현존하는 모든 블록체인 구현체에 존재하는 문제점들을 처리합니다. + + +Grin is an open source software project that implements a MimbleWimble +blockchain and fills the gaps required for a full blockchain and +cryptocurrency deployment. + +Grin 은 Mimble Wimble 블록체인을 구현한 오픈소스 프로젝트 입니다. +또한 완전한 블록체인와 크립토 커런시의 배포에 필요한 갭을 채워줍니다. + +The main goal and characteristics of the Grin project are: +Grin 프로젝트의 주요 목적과 특성들은 아래 설명을 참고하십시오. + +* Privacy by default. This enables complete fungibility without precluding + the ability to selectively disclose information as needed. +* 프라이버시가 기본으로 제공됩니다. 이 기능은 필요에 따라서 선택적으로 정보를 공개 할 수 없도록 해서 완전한 대체가능성을 할 수 있게 합니다. +* Scales mostly with the number of users and minimally with the number of + transactions (<100 byte `kernel`), resulting in a large space saving compared + to other blockchains. +* 주로 유저의 규모와 최소한의 트랜잭션 수의 규모로 (100byte 미만의 kernel(transaction)) 다른 블록체인들과 비교하면 많은 공간을 절약할 수 있습니다. +* Strong and proven cryptography. MimbleWimble only relies on Elliptic Curve + Cryptography which has been tried and tested for decades. +* Mimble Wimble 은 수십년 동안 테스트하고 사용되었던 강력한 암호기술인 ECC만 사용합니다. +* Design simplicity that makes it easy to audit and maintain over time. +* 간단한 디자인은 감사와 유지보수를 시간이 지나도 수월하게 만듭니다. +* Community driven, encouraging mining decentralization. +* 커뮤니티가 주도하며, 채굴 탈중앙화가 권장됩니다. + +## Tongue Tying for Everyone +## 모두의 혀를 묶자. +This document is targeted at readers with a good +understanding of blockchains and basic cryptography. +이 문서는 블록체인에 대해 어느정도 이해가 있고 암호학에 대한 기본적인 이해가 있는 독자들을 대상으로 합니다. + +With that in mind, we attempt to explain the technical buildup of MimbleWimble and how it's applied in Grin. +이것을 염두에 두고 우리는 MimbleWimble의 기술적인 발전과 어떻게 Grin에 적용되었는지 관해 설명할것입니다. + +We hope this document is understandable to most technically-minded readers. Our objective is +to encourage you to get interested in Grin and contribute in any way possible. +저희는 이 문서가 대부분의 기술적인 성격을 가진 독자들을 이해시킬 수 있길 바랍니다. +우리의 목적은 독자가 Grin에 대해 흥기를 느끼게 하고 어떤 방식으로든 Grin에 기여할 수 있게 이끄는 것입니다. + +To achieve this objective, we will introduce the main concepts required for a good understanding of Grin as a MimbleWimble implementation. +이러한 목적을 이루기 위해, 우리는 MimbleWimble 의 구현체인 Grin을 이해하는데 필요한 주요 컨셉들에 대해서 소개할것입니다. + +We will start with a brief description of some relevant properties of Elliptic Curve Cryptography (ECC) to lay the foundation on which Grin is based and then describe all the key elements of a MimbleWimble blockchain's transactions and blocks. +우선 Grin이 어디에서 부터 기초로 하고 있는지에 대해 이해하기 위해서 타원 곡선 암호 (ECC)의 몇몇 속성들에 대한 간단한 설명으로 시작하겠습니다. 그 다음, MimbleWimble 블록체인의 트랜잭션과 블록에 한 모든 요소들을 설명하겠습니다. + +### Tiny Bits of Elliptic Curves +### 타원곡선에 대한 조그마한 조각들 + +We start with a brief primer on Elliptic Curve Cryptography, reviewing just the +properties necessary to understand how MimbleWimble works and without +delving too much into the intricacies of ECC. + +- ECC의 너무 복잡한 사항을 캐지 않고 어떻게 mimble wimble 이 어떻게 작동하는지에 대해 이해하는데 필요한 요소들만 리뷰할 것입니다. + + For readers who would want to dive deeper into those assumptions, there are other opportunities to [learn more](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/). +- 이런 가정들을 좀 더 알고싶은 독자들은 [이 링크]() 를 참고하세요. + +An Elliptic Curve for the purpose of cryptography is simply a large set of points that +we will call _C_. These points can be added, subtracted, or multiplied by integers (also called scalars). +암호학에서의 타원 곡선이란 우리가 _C_ 라고 부르는 단순히 아주 큰 좌표의 집합입니다. +이 좌표들은 정수들로 (인티저, 또는 스칼라 ) 더하고 빼고 곱할수 있습니다. + +Given an integer _k_ and using the scalar multiplication operation we can compute `k*H`, which is also a point on curve _C_. +주어진 정수 _K_ 에 스칼라 곱셈을 한다면 우리는 곡선 _c_ 위에 있는 좌표 K*H를 계산 할 수 있습니다. + +Given another integer _j_ we can also calculate `(k+j)*H`, which equals `k*H + j*H`. +또 달리 주어진 정수 _j_ 에 우리는`k*H + j*H` 와 같은 `(k+j)*H`를 계산 할 수 있습니다. + +The addition and scalar multiplication operations on an elliptic curve maintain the commutative and associative properties of addition and multiplication: +타원곡선 위에서의 덧셈과 정수 곱셈은 제시덴 수의 순서에 관계없이 결과가 동일하다는 성질과 덧셈과 곱셈의 계산 순서와 관계없이 동일한 결과가 나온다는 성질을 가지고 있습니다. + + (k+j)*H = k*H + j*H + +In ECC, if we pick a very large number _k_ as a private key, `k*H` is +considered the corresponding public key. +ECC 안에서 우리가 매우 큰 숫자인 _k_ 를 프라이빗 키로 가정할 때 `k*H` 는 해당하는 퍼블릭 키로 해당되어 집니다. + +Even if one knows the value of the public key `k*H`, deducing _k_ is close to impossible (or said differently, while multiplication is trivial, "division" by curve points is +extremely difficult). +누군가 공개키인 `k*H`의 값을 알더라도 _k_ 를 추론해 내는것은 불가능에 가깝습니다. ( 달리 얘기하자면, 곱셉은 쉬우나 곡선 좌표에 의한 "나눗셈"은 정말 어렵습니다. ) + + +The previous formula `(k+j)*H = k*H + j*H`, with _k_ and _j_ both private +keys, demonstrates that a public key obtained from the addition of two private +keys (`(k+j)*H`) is identical to the addition of the public keys for each of those +two private keys (`k*H + j*H`). +_k_ 와 _j_ 둘다 비밀키인 이전 공식 `(k+j)*H = k*H + j*H` 는 두개의 비밀키를 더해서 얻은 한 개의 공개키 (`(k+j)*H`) 와 각각 두개의 비밀키에 공개키를 더한것과 같습니다. +In the Bitcoin blockchain, Hierarchical Deterministic wallets heavily rely on this principle. +Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. +MimbleWimble and the Grin implementation do as well. +MimbleWimble 과 Grin의 구현또한 마찬가지 입니다. + +### Transacting with MimbleWimble +### MimbleWimble 함께 거래하기 + +The structure of transactions demonstrates a crucial tenet of MimbleWimble: +트랜잭션의 구조는 MimbleWimble의 강력한 프라이버시와 비밀이 유지된다라고 하는 중요한 규칙을 나타냅니다. +strong privacy and confidentiality guarantees. + +The validation of MimbleWimble transactions relies on two basic properties: +MimbleWimble 트랜잭션의 확인은 두가지 기본적인 성격을 전제로 합니다. +* **Verification of zero sums.** The sum of outputs minus inputs always equals zero, + proving that the transaction did not create new funds, _without revealing the actual amounts_. +* **제로섬의 검증** 결과값에서 입력값을 뺸 합은 항상 0과 같습니다. 이것은 실제 전송되는 코인의 양을 드러내지 않고도 트랜잭션ㅇ이 새로운 코인을 만들지 않았다는 것을 증명합니다. +* **Possession of private keys.** Like with most other cryptocurrencies, ownership of + transaction outputs is guaranteed by the possession of ECC private keys. However, + the proof that an entity owns those private keys is not achieved by directly signing + the transaction. +* **비밀키의 소유** 다른 많은 크립토커런시들 처럼 , 트랜잭션의 소유권은 ECC 비밀키에 의해 보장됩니다. 그러나 어떤 실체가 이런 비밀키들을 소유하고 있다고 증명하는것이 직접적으로 트랜잭션에 사인한다고해서 얻어지는 것은 아닙니다. + +The next sections on balance, ownership, change and proofs details how those two +fundamental properties are achieved. +다음 섹션들에서는 잔고, 소유권, 거스름돈과 증명들의 상세들이 어떻게 저 두가지 기본적인 성질에 의해서 얻어지는지 알아보겠습니다. + +#### Balance +#### 잔고 + +Building upon the properties of ECC we described above, one can obscure the values +in a transaction. +위에서 언급한 ECC의 특성들을 기반으로 해서 트랜잭션안의 가치들을 보기 어렵게 할 수 있습니다. + +If _v_ is the value of a transaction input or output and _H_ an elliptic curve, we can simply +embed `v*H` instead of _v_ in a transaction. +만약 _v_ 가 트랜잭션 입력값이거나 출력값이고 _H_가 타원곡선이라면 , 단순히 _v_ 대신 `v*H`를 끼워넣을 수 있습니다. + +This works because using the ECC operations, we can still validate that the sum of the outputs of a transaction equals the sum of inputs: +이것은 ECC를 사용하기 때문에 작동하는 것입니다. 우리는 출력값의 합이 입력값의 합과 같다는 것을 여전히 확인할 수 있습니다. + + v1 + v2 = v3 => v1*H + v2*H = v3*H + +Verifying this property on every transaction allows the protocol to verify that a +transaction doesn't create money out of thin air, without knowing what the actual +values are. +이 특성을 모든 트랜잭션에 확인하는것은 프로토콜이 트랜잭션은 돈을 난데없이 만들지 않는다는 것을 실제 돈이 얼마나 있는지 알지 않아도 검증할 수 있게 합니다. +However, there are a finite number of usable values and one could try every single +one of them to guess the value of your transaction. +그러나 사용가능한 한정된 숫자가 있고 그 숫자 중 하나를 사용해서 당신의 트랜잭션이 얼마만큼의 코인을 가졌는지 추측해 할 수 있습니다. +In addition, knowing v1 (from a previous transaction for example) and the resulting `v1*H` reveals all outputs with value v1 across the blockchain. +더해서 , v1을 알고 ( 예시로 사용된 이전의 트랜잭션에서 온 값 ) 그에따른 `v1*H`의 결과를 알면 블록체인 전체에 걸쳐서 v1 값이 있는 모든 출력값들이 드러나게 됩니다. + +For these reasons, we introduce a second elliptic curve _G_ (practically _G_ is just another generator point on the same curve group as _H_) and a private key _r_ used as a *blinding factor*. +이러한 이유때문에 우리는 두번째 타원곡선인 _G_를 제시합니다. ( 실제로 _G_ 는 _H_ 의 그룹과 같은 곡선에 있는 단지 다른 좌표를 생성해 냅니다.) 그리고 비밀키 _r_은 *blinding factor* 로 사용됩니다. + +An input or output value in a transaction can then be expressed as: +그렇다면 트랜잭션 안의 입력값과 출력값은 다음과 같이 표현됩니다. + r*G + v*H +Where: +여기서 +* _r_ is a private key used as a blinding factor, _G_ is an elliptic curve and + their product `r*G` is the public key for _r_ on _G_. +* _r_ 은 비밀키이고 blinding factor 로 사용됩니다. _G_ 는 타원 곡선 이고 `r*G`는 _G_ 안에 있는 _r_ 의 공개키 입니다. +* _v_ is the value of an input or output and _H_ is another elliptic curve. +* _v_ 는 출력값이거나 입력값이고 _H_ 는 다른 타원곡선입니다. +Neither _v_ nor _r_ can be deduced, leveraging the fundamental properties of Elliptic +Curve Cryptography. `r*G + v*H` is called a _Pedersen Commitment_. +타원곡선의 근본적인 특성을 이용했기 때문에 _v_ 와 _r_ 은 추측될 수 없습니다. `r*G + v*H`를 _Pedersen Commitment_ 라고 부릅니다. +As a an example, let's assume we want to build a transaction with two inputs and one +output. We have (ignoring fees): +예를 들어 , ( 전송료는 무시하고) 두개의 입력값과 한개의 출력값으로 트랜잭션을 만들기 원한다고 가정해봅시다. +* vi1 and vi2 as input values. +* vi1 과 v2 는 출력값 +* vo3 as output value. +* vo3는 출력값 이라면 +Such that: + + vi1 + vi2 = vo3 + +Generating a private key as a blinding factor for each input value and replacing each value +with their respective Pedersen Commitments in the previous equation, we obtain: +각각의 입력값에 대해서 blining factor 로 비밀키를 만들고 각각의 값을 각각의 이전의 공식에 있던 Pederson Commitment로 교체한다고 하면 다음과 같습니다. + + (ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vo3*H) + +Which as a consequence requires that: +결과로 다음과 같습니다. + ri1 + ri2 = ro3 + +This is the first pillar of MimbleWimble: the arithmetic required to validate a +transaction can be done without knowing any of the values. +이것이 MimbleWimble의 첫번째 특징입니다. 트랜잭션을 검증하는 산술적인 연산은 아무런 값을 알지 못해도 가능합니다. + +As a final note, this idea is actually derived from Greg Maxwell's +[Confidential Transactions](https://elementsproject.org/features/confidential-transactions/investigation), +which is itself derived from an Adam Back proposal for homomorphic values applied +to Bitcoin. +마지막으로 이 아이디어는 Greg Maxwell 의 [Confidential Transactions](https://elementsproject.org/features/confidential-transactions/investigation) 에서 유래했습니다. Confidential transaction은 Adam back의 비트코인에 동형암호를 적용하자는 제안에서 비롯되었습니다. + +#### Ownership +#### 소유권 +In the previous section we introduced a private key as a blinding factor to obscure the +transaction's values. +이전의 섹션에서 우리는 트랜잭션의 값을 보기 어렵게 하는 Blinding factor로서 비밀키를 소개했습니다. +The second insight of MimbleWimble is that this private key can be leveraged to prove ownership of the value. +MimbleWimble 의 두번째 통찰은 비밀키가 어떤 값의 소유권을 증명하는데 사용할 수 있다는 것입니다. +Alice sends you 3 coins and to obscure that amount, you chose 28 as your +blinding factor (note that in practice, the blinding factor being a private key, it's an +extremely large number). +Alice는 당신에게 3 코인을 보내면서 그 양을 가렸고, 당신은 28을 당신의 blinding factor로 선택했습니다. ( 실제로 blinding factor는 비밀키로 정말 무진장 큰 숫자 입니다.) + +Somewhere on the blockchain, the following output appears and should only be spendable by you: +블록체인 어딘가에 다음과 같은 출력값이 나타나 있고 당신에 의해서만 소비될 수 있습니다. + X = 28*G + 3*H + +_X_, the result of the addition, is visible by everyone. The value 3 is only known to you and Alice, and 28 is only known to you. +_X_ 는 덧셈의 결과이면서 모두에게 다 보여집니다. 3은 당신과 Alice만 알고 있고 28은 당신만이 알고 있습니다. + +To transfer those 3 coins again, the protocol requires 28 to be known somehow. +다시 3코인을 보내기 위해선, 프로토콜은 어떻게든 28을 알고 있어야 됩니다. + +To demonstrate how this works, let's say you want to transfer those 3 same coins to Carol. +You need to build a simple transaction such that: +어떻게 이것이 작동하는지 보기 위해서, 당신이 캐롤에게 같은 3코인을 보내고 싶어한다고 합시다. +그렇다면 당신은 아래와 같은 간단한 트랜잭션을 작성해야 합니다. + + Xi => Y + +Where _Xi_ is an input that spends your _X_ output and Y is Carol's output. +여기서 _Xi_는 _X_ 출력을 사용하는 입력이고 Y는 Carol의 출력입니다. +There is no way to build such a transaction and balance it without knowing your private key of 28. +당신의 비밀키인 28을 모르고서는 트랜잭션과 잔액을 만들 수 있는 방법이 없습니다. + +Indeed, if Carol is to balance this transaction, she needs to know both the value sent and your private key +실제로 캐롤이 이 트랜잭션의 잔액을 위해선 그녀는 받는 값과 당신의 비밀키를 알아야 합니다. +so that: +그러므로 + Y - Xi = (28*G + 3*H) - (28*G + 3*H) = 0*G + 0*H + +By checking that everything has been zeroed out, we can again make sure that +no new money has been created. +모든계산이 0으로 되었는지 확인함으로써, 새로운 돈이 만들어지지 않았다는 것을 확인할 수 있습니다. +Wait! Stop! Now you know the private key in Carol's output (which, in this case, must +be the same as yours to balance out) and so you could steal the money back from Carol! +오 잠시만요! 당신은 지금 캐롤의 출력값에 비밀키가 있다는것을 알았습니다. ( 이런경우에는 당신의 잔액이 나간것과 동일 해야 합니다.) 그리고 당신은 캐롤로 부터 돈을 훔칠수 있습니다. + +To solve this, Carol uses a private key of her choosing. +이걸 해결하기위해서 캐롤은 그녀가 선택한 비밀키를 사용합니다. +She picks 113 say, and what ends up on the blockchain is: +113을 비밀키로 선택했다면 블록체인 안에서는 아래와 같이 마무리 됩니다. + Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H + +Now the transaction no longer sums to zero and we have an _excess value_ on _G_ +(85), which is the result of the summation of all blinding factors. +모든 blinding factor합계 결과로 타원곡선 _G_ 위에서 트랜잭션은 _초과값_ 을 가지게 되고 트랜잭션의 합은 더이상 0 이 아닙니다. + +But because `85*G` is a valid public key on the elliptic curve _G_, with private key 85, +for any x and y, only if `y = 0` is `x*G + y*H` a valid public key on _G_. +그러나 `85*G` 은 비밀키 85 와 함께 타원곡선 _G_ 에서 유효한 공개키이기 때문에 모든 x와 y는 `y = 0`가 `x*G + y*H`일때 곡선 _G_ 에서 유효한 공개키입니다. + +So all the protocol needs to verify is that (`Y - Xi`) is a valid public key on _G_ and that +the transacting parties collectively know the private key (85 in our transaction with Carol). +그러므로 모든 프로토콜은 (`Y - Xi`) 가 _G_위에서 유효한 공개키인지 ,거래당사자들이 비밀키를 알고있는지 ( 캐롤과의 트랜잭션에서는 85) 를 검증해야 할 필요가 있습니다. + +The simplest way to do so is to require a signature built with the excess value (85), +which then validates that: +가장 간단하게 검증하는 방법은 Signature가 초과값과 함께 만들어졌다는 것을 요구한 다음 아래와 같은것을 인증하는 겁니다. +* The transacting parties collectively know the private key, and +* 거래하는 당사자들은 모두 비밀키를 알고 있고 +* The sum of the transaction outputs, minus the inputs, sum to a zero value + (because only a valid public key, matching the private key, will check against + the signature). +* 트랜잭션의 입력값을 뺀 출력값들의 합은 0입니다. ( 왜냐하면 비밀키와 매칭된 유효한 공개키만 Signature 를 체크할 것이기 때문입니다. ) + +This signature, attached to every transaction, together with some additional data (like mining +fees), is called a _transaction kernel_ and is checked by all validators. +모든 트랜잭션에 포함된 이 Signature 는 덧붙여진 어떤 데이터와 함께(채굴 수수료와 같은 데이터) _transaction kernel_ 이라고 부르고 모든 Validator 에 의해 체크됩니다. + +#### Some Finer Points +#### 몇몇 좋은 점들 +This section elaborates on the building of transactions by discussing how change is +introduced and the requirement for range proofs so all values are proven to be +non-negative. +이 섹션은 트랜잭션을 만들때 잔돈이 어떻게 보여지고 범위 증명(range proofs)의 요구사항에 대해서 모든 값이 음수가 아닌지에 대해서 좀 더 자세하게 설명하려고 합니다. +Neither of these are absolutely required to understand MimbleWimble and Grin, so if you're in a hurry, feel free to jump straight to [Putting It All Together](#putting-it-all-together). +이러한 개념들 역시 MimbleWimble 과 Grin 에 대한 이해가 당연히 필요합니다. +만약 당신이 조급하다면 +##### Change + +Let's say you only want to send 2 coins to Carol from the 3 you received from +Alice. To do this you would send the remaining 1 coin back to yourself as change. +You generate another private key (say 12) as a blinding factor to +protect your change output. Carol uses her own private key as before. + + Change output: 12*G + 1*H + Carol's output: 113*G + 2*H + +What ends up on the blockchain is something very similar to before. +And the signature is again built with the excess value, 97 in this example. + + (12*G + 1*H) + (113*G + 2*H) - (28*G + 3*H) = 97*G + 0*H + +##### Range Proofs + +In all the above calculations, we rely on the transaction values to always be positive. The +introduction of negative amounts would be extremely problematic as one could +create new funds in every transaction. + +For example, one could create a transaction with an input of 2 and outputs of 5 +and -3 and still obtain a well-balanced transaction, following the definition in +the previous sections. This can't be easily detected because even if _x_ is +negative, the corresponding point `x.H` on the curve looks like any other. + +To solve this problem, MimbleWimble leverages another cryptographic concept (also +coming from Confidential Transactions) called +range proofs: a proof that a number falls within a given range, without revealing +the number. We won't elaborate on the range proof, but you just need to know +that for any `r.G + v.H` we can build a proof that will show that _v_ is greater than +zero and does not overflow. + +It's also important to note that in order to create a valid range proof from the example above, both of the values 113 and 28 used in creating and signing for the excess value must be known. The reason for this, as well as a more detailed description of range proofs are further detailed in the [range proof paper](https://eprint.iacr.org/2017/1066.pdf). + +#### Putting It All Together + +A MimbleWimble transaction includes the following: + +* A set of inputs, that reference and spend a set of previous outputs. +* A set of new outputs that include: + * A value and a blinding factor (which is just a new private key) multiplied on + a curve and summed to be `r.G + v.H`. + * A range proof that shows that v is non-negative. +* An explicit transaction fee, in clear. +* A signature, computed by taking the excess blinding value (the sum of all + outputs plus the fee, minus the inputs) and using it as a private key. + +### Blocks and Chain State + +We've explained above how MimbleWimble transactions can provide +strong anonymity guarantees while maintaining the properties required for a valid +blockchain, i.e., a transaction does not create money and proof of ownership +is established through private keys. + +The MimbleWimble block format builds on this by introducing one additional +concept: _cut-through_. With this addition, a MimbleWimble chain gains: + +* Extremely good scalability, as the great majority of transaction data can be + eliminated over time, without compromising security. +* Further anonymity by mixing and removing transaction data. +* And the ability for new nodes to sync up with the rest of the network very + efficiently. + +#### Transaction Aggregation + +Recall that a transaction consists of the following - + +* a set of inputs that reference and spent a set of previous outputs +* a set of new outputs (Pedersen commitments) +* a transaction kernel, consisting of + * kernel excess (Pedersen commitment to zero) + * transaction signature (using kernel excess as public key) + +A tx is signed and the signature included in a _transaction kernel_. The signature is generated using the _kernel excess_ as a public key proving that the transaction sums to 0. + + (42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H + +The public key in this example being `28*G`. + +We can say the following is true for any valid transaction (ignoring fees for simplicity) - + + sum(outputs) - sum(inputs) = kernel_excess + +The same holds true for blocks themselves once we realize a block is simply a set of aggregated inputs, outputs and transaction kernels. We can sum the tx outputs, subtract the sum of the tx inputs and compare the resulting Pedersen commitment to the sum of the kernel excesses - + + sum(outputs) - sum(inputs) = sum(kernel_excess) + +Simplifying slightly, (again ignoring transaction fees) we can say that MimbleWimble blocks can be treated exactly as MimbleWimble transactions. + +##### Kernel Offsets + +There is a subtle problem with MimbleWimble blocks and transactions as described above. It is possible (and in some cases trivial) to reconstruct the constituent transactions in a block. This is clearly bad for privacy. This is the "subset" problem - given a set of inputs, outputs and transaction kernels a subset of these will recombine to reconstruct a valid transaction. + +For example, given the following two transactions - + + (in1, in2) -> (out1), (kern1) + (in3) -> (out2), (kern2) + +We can aggregate them into the following block (or aggregate transaction) - + + (in1, in2, in3) -> (out1, out2), (kern1, kern2) + +It is trivially easy to try all possible permutations to recover one of the transactions (where it sums successfully to zero) - + + (in1, in2) -> (out1), (kern1) + +We also know that everything remaining can be used to reconstruct the other valid transaction - + + (in3) -> (out2), (kern2) + +To mitigate this we include a _kernel offset_ with every transaction kernel. This is a blinding factor (private key) that needs to be added back to the kernel excess to verify the commitments sum to zero - + + sum(outputs) - sum(inputs) = kernel_excess + kernel_offset + +When we aggregate transactions in a block we store a _single_ aggregate offset in the block header. And now we have a single offset that cannot be decomposed into the individual transaction kernel offsets and the transactions can no longer be reconstructed - + + sum(outputs) - sum(inputs) = sum(kernel_excess) + kernel_offset + +We "split" the key `k` into `k1+k2` during transaction construction. For a transaction kernel `(k1+k2)*G` we publish `k1*G` (the excess) and `k2` (the offset) and sign the transaction with `k1*G` as before. +During block construction we can simply sum the `k2` offsets to generate a single aggregate `k2` offset to cover all transactions in the block. The `k2` offset for any individual transaction is unrecoverable. + +#### Cut-through + +Blocks let miners assemble multiple transactions into a single set that's added +to the chain. In the following block representations, containing 3 transactions, +we only show inputs and +outputs of transactions. Inputs reference outputs they spend. An output included +in a previous block is marked with a lower-case x. + + I1(x1) --- O1 + |- O2 + + I2(x2) --- O3 + I3(O2) -| + + I4(O3) --- O4 + |- O5 + +We notice the two following properties: + +* Within this block, some outputs are directly spent by included inputs (I3 + spends O2 and I4 spends O3). +* The structure of each transaction does not actually matter. As all transactions + individually sum to zero, the sum of all transaction inputs and outputs must be zero. + +Similarly to a transaction, all that needs to be checked in a block is that ownership +has been proven (which comes from _transaction kernels_) and that the whole block did +not add any money supply (other than what's allowed by the coinbase). +Therefore, matching inputs and outputs can be eliminated, as their contribution to the overall +sum cancels out. Which leads to the following, much more compact block: + + I1(x1) | O1 + I2(x2) | O4 + | O5 + +Note that all transaction structure has been eliminated and the order of inputs and +outputs does not matter anymore. However, the sum of all outputs in this block, +minus the inputs, is still guaranteed to be zero. + +A block is simply built from: + +* A block header. +* The list of inputs remaining after cut-through. +* The list of outputs remaining after cut-through. +* A single kernel offset to cover the full block. +* The transaction kernels containing, for each transaction: + * The public key `r*G` obtained from the summation of all the commitments. + * The signatures generated using the excess value. + * The mining fee. + +When structured this way, a MimbleWimble block offers extremely good privacy +guarantees: + +* Intermediate (cut-through) transactions will be represented only by their transaction kernels. +* All outputs look the same: just very large numbers that are impossible to + differentiate from one another. If one wanted to exclude some outputs, they'd have + to exclude all. +* All transaction structure has been removed, making it impossible to tell which output + was matched with each input. + +And yet, it all still validates! + +#### Cut-through All The Way + +Going back to the previous example block, outputs x1 and x2, spent by I1 and +I2, must have appeared previously in the blockchain. So after the addition of +this block, those outputs as well as I1 and I2 can also be removed from the +overall chain, as they do not contribute to the overall sum. + +Generalizing, we conclude that the chain state (excluding headers) at any point +in time can be summarized by just these pieces of information: + +1. The total amount of coins created by mining in the chain. +2. The complete set of unspent outputs. +3. The transactions kernels for each transaction. + +The first piece of information can be deduced just using the block +height (its distance from the genesis block). And both the unspent outputs and the +transaction kernels are extremely compact. This has 2 important consequences: + +* The state a given node in a MimbleWimble blockchain needs to maintain is very + small (on the order of a few gigabytes for a bitcoin-sized blockchain, and + potentially optimizable to a few hundreds of megabytes). +* When a new node joins a network building up a MimbleWimble chain, the amount of + information that needs to be transferred is also very small. + +In addition, the complete set of unspent outputs cannot be tampered with, even +only by adding or removing an output. Doing so would cause the summation of all +blinding factors in the transaction kernels to differ from the summation of blinding +factors in the outputs. + +### Conclusion + +In this document we covered the basic principles that underlie a MimbleWimble +blockchain. By using the addition properties of Elliptic Curve Cryptography, we're +able to build transactions that are completely opaque but can still be properly +validated. And by generalizing those properties to blocks, we can eliminate a large +amount of blockchain data, allowing for great scaling and fast sync of new peers. From 7d10edf01c9655b063e4e0d20b343e879b660e71 Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Sat, 16 Feb 2019 16:37:07 +0900 Subject: [PATCH 07/25] table_of_content.md translate in Korean. --- ...e_of_contents.md => table_of_contents_.md} | 0 doc/table_of_contents_KR.md | 35 +++++++++++++++++++ 2 files changed, 35 insertions(+) rename doc/{table_of_contents.md => table_of_contents_.md} (100%) create mode 100644 doc/table_of_contents_KR.md diff --git a/doc/table_of_contents.md b/doc/table_of_contents_.md similarity index 100% rename from doc/table_of_contents.md rename to doc/table_of_contents_.md diff --git a/doc/table_of_contents_KR.md b/doc/table_of_contents_KR.md new file mode 100644 index 0000000000..4c5c630918 --- /dev/null +++ b/doc/table_of_contents_KR.md @@ -0,0 +1,35 @@ +# 문서 목록 + +## Grin 에 대한 설명들 + +- [intro](intro.md) - Grin 에 대한 기술적인 소개 +- [grin4bitcoiners](grin4bitcoiners.md) - Bitcoinner 의 관점에서 Grin 을 설명하기 + +## Grin 구현에 대해서 이해하기 + +- [grin4bitcoiners](grin4bitcoiners.md) - Grin 의 Blockchain이 어떻게 동기화 되는가에 대해서 +- [blocks_and_headers](chain/blocks_and_headers.md) - Grin이 어떻게 block과 header 를 chain안에서 찾는지에 대해서 +- [contract_ideas](contract_ideas.md) - 어떻게 smart contract 를 구현할 것인가에 대한 아이디어 +- [dandelion/dandelion](dandelion/dandelion.md) - 트랜잭션 전파 와 [컷 스루 방식](http://www.ktword.co.kr/abbr_view.php?m_temp1=1823). 어간추출과 부풀리기. +- [dandelion/simulation](dandelion/simulation.md) - Dandelion 시뮬레이션 - lock height 스테밍과 플러핑 없이 트랜잭션 합치기 +- [internal/pool](internal/pool.md) - 트랜잭션 풀에 대한 기술적인 설명에 대해서 +- [merkle](merkle.md) - Grin의 Merkle tree 에 대한 기술적인 설명 +- [merkle_proof graph](merkle_proof/merkle_proof.png) - Prunning 이 적용된 merkle proof의 예시 +- [pruning](pruning.md) - Pruning 의 기술적인 설명 +- [stratum](stratum.md) -Grin Stratum RPC protocol 의 기술적 설명 +- [transaction UML](wallet/transaction/basic-transaction-wf.png) - UML of an interactive transaction (aggregating transaction without `lock_height`) + +## Build and use + +- [api](api/api.md) - Explaining the different APIs in Grin and how to use them +- [build](build.md) - Explaining how to build and run the Grin binaries +- [release](release_instruction.md) - Instructions of making a release +- [usage](usage.md) - Explaining how to use grin in Testnet3 +- [wallet](wallet/usage.md) - Explains the wallet design and `grin wallet` sub-commands + +## External (wiki) + +- [FAQ](https://github.com/mimblewimble/docs/wiki/FAQ) - Frequently Asked Questions +- [Building grin](https://github.com/mimblewimble/docs/wiki/Building) +- [How to use grin](https://github.com/mimblewimble/docs/wiki/How-to-use-grin) +- [Hacking and contributing](https://github.com/mimblewimble/docs/wiki/Hacking-and-contributing) From 1276a4ae6ac1a025a3013a7e9f87351953fe11d8 Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Sat, 16 Feb 2019 17:36:33 +0900 Subject: [PATCH 08/25] table_of_content_KR.md finish translate in Korean, start to translate State_KR.md --- doc/table_of_contents_KR.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/doc/table_of_contents_KR.md b/doc/table_of_contents_KR.md index 4c5c630918..10484d3f56 100644 --- a/doc/table_of_contents_KR.md +++ b/doc/table_of_contents_KR.md @@ -10,26 +10,26 @@ - [grin4bitcoiners](grin4bitcoiners.md) - Grin 의 Blockchain이 어떻게 동기화 되는가에 대해서 - [blocks_and_headers](chain/blocks_and_headers.md) - Grin이 어떻게 block과 header 를 chain안에서 찾는지에 대해서 - [contract_ideas](contract_ideas.md) - 어떻게 smart contract 를 구현할 것인가에 대한 아이디어 -- [dandelion/dandelion](dandelion/dandelion.md) - 트랜잭션 전파 와 [컷 스루 방식](http://www.ktword.co.kr/abbr_view.php?m_temp1=1823). 어간추출과 부풀리기. +- [dandelion/dandelion](dandelion/dandelion.md) - 트랜잭션 전파 와 [컷 스루 방식](http://www.ktword.co.kr/abbr_view.php?m_temp1=1823). Stemming과 fluffing. - [dandelion/simulation](dandelion/simulation.md) - Dandelion 시뮬레이션 - lock height 스테밍과 플러핑 없이 트랜잭션 합치기 - [internal/pool](internal/pool.md) - 트랜잭션 풀에 대한 기술적인 설명에 대해서 - [merkle](merkle.md) - Grin의 Merkle tree 에 대한 기술적인 설명 - [merkle_proof graph](merkle_proof/merkle_proof.png) - Prunning 이 적용된 merkle proof의 예시 - [pruning](pruning.md) - Pruning 의 기술적인 설명 - [stratum](stratum.md) -Grin Stratum RPC protocol 의 기술적 설명 -- [transaction UML](wallet/transaction/basic-transaction-wf.png) - UML of an interactive transaction (aggregating transaction without `lock_height`) +- [transaction UML](wallet/transaction/basic-transaction-wf.png) - 상호작용 트랜잭션의 UML (`lock_height` 없이 트랜잭션 합치기) -## Build and use +## 빌드하고 사용하기 -- [api](api/api.md) - Explaining the different APIs in Grin and how to use them -- [build](build.md) - Explaining how to build and run the Grin binaries -- [release](release_instruction.md) - Instructions of making a release -- [usage](usage.md) - Explaining how to use grin in Testnet3 -- [wallet](wallet/usage.md) - Explains the wallet design and `grin wallet` sub-commands +- [api](api/api.md) - Grin 에 있는 다른 API 들과 어떻게 사용하는지에 대해서 +- [build](build.md) - Grin 바이너리를 어떻게 빌드하고 작동시키는 지에 대해서 +- [release](release_instruction.md) - Release 를 만드는것에 대한 안내 +- [usage](usage.md) - Testnet3 에서 어떻게 Grin 을 사용하는지에 대한 설명 +- [wallet](wallet/usage.md) - wallet 디자인에 대한 설명과 `grin wallet` 의 세부 명령어 -## External (wiki) +## 외부자료 (위키) -- [FAQ](https://github.com/mimblewimble/docs/wiki/FAQ) - Frequently Asked Questions -- [Building grin](https://github.com/mimblewimble/docs/wiki/Building) -- [How to use grin](https://github.com/mimblewimble/docs/wiki/How-to-use-grin) -- [Hacking and contributing](https://github.com/mimblewimble/docs/wiki/Hacking-and-contributing) +- [FAQ](https://github.com/mimblewimble/docs/wiki/FAQ) - 자주 물어보는 질문들 +- [Grin 빌드하기](https://github.com/mimblewimble/docs/wiki/Building) +- [Grin을 어떻게 사용하나요?](https://github.com/mimblewimble/docs/wiki/How-to-use-grin) +- [해킹과 기여하기](https://github.com/mimblewimble/docs/wiki/Hacking-and-contributing) From 6c0913b6e87866dbac0bd2f640ec4b3b8d64b7c7 Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Sat, 16 Feb 2019 17:37:33 +0900 Subject: [PATCH 09/25] add state_KR.md & commit some translation in State_KR.md --- doc/state_KR.md | 70 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 doc/state_KR.md diff --git a/doc/state_KR.md b/doc/state_KR.md new file mode 100644 index 0000000000..cf2adfa557 --- /dev/null +++ b/doc/state_KR.md @@ -0,0 +1,70 @@ +# 상태와 스토리지 + +## Grin의 상태 + +### 구조 + +Grin chain의 모든 상태는 다음 데이터와 같이 이루어져 있습니다. + +1. unspent output(UTXO) 세트 +2. 각 출력값에 대한 range proof +3. 모든 트랜잭션 커널(kernel)들 +4. A MMR for each of the above (with the exception that the output MMR includes + hashes for *all* outputs, not only the unspent ones). +4. 상기에 언급했던 각각의 것들에 대한 MMR (예외적으로 출력값 MMR은 사용되지 않은 것 뿐만 아니라 *모든* 출력값의 해쉬를 포함합니다.) +In addition, all headers in the chain are required to anchor the above state +with a valid proof of work (the state corresponds to the most worked chain). +더해서 chain 안의 모든 헤더들은 유효한 PoW 와 상기 상태에 대한 anchor가 요구됩니다. ( 상태는 가장 많이 일한 체인와 일치합니다.) +We note that once each range proof is validated and the sum of all kernels +commitment is computed, range proofs and kernels are not strictly necessary for +a node to function anymore. +한번 각각의 range proof 가 인증되고 모든 kernel의 실행 합계가 계산되었다면 node 의 작동에 굳이 꼭 필요하진 않습니다. + +### 인증하기 + +With a full Grin state, we can validate the following: +완전한 Grin의 상태를 사용해서 우리는 다음과 같은 것들을 인증 할 수 있습니다. + +1. The kernel signature is valid against its commitment (public key). This + proves the kernel is valid. + Kernel 의 signature 가 Kernel의 실행에 대해 유효하다면 ( 공개키). 이것은 Kernel이 유요하다는것을 증명합니다. +2. The sum of all kernel commitments equals the sum of all UTXO commitments + minus the total supply. This proves that kernels and output commitments are all valid and no coins have unexpectedly been created. + 모든 커밋 실행의 합이 모든 UTXO 실행의 합에서 총 공급량을 뺸 값이 같다면 이것은 Kernal과 출력값의 실행들이 유효하고 코인이 새로이 만들어지지 않았다는 것을 증명합니다. +3. All UTXOs, range proofs and kernels hashes are present in their respective + MMR and those MMRs hash to a valid root. + 모든 UTXO, range prook 와 Kernel 해쉬들은 각각의 MMR이 있고 그 MMR 들은 유효한 root 를 해쉬합니다. +4. A known block header with the most work at a given point in time includes + the roots of the 3 MMRs. + + This validates the MMRs and proves that the whole state has been produced by the most worked chain. + 이것은 MMR과 인증하고 전체 상태가 가장 많이 일한 chain ( 가장 긴 체인)에서 만들어졌다는 것을 증명합니다. + +### MMRs and Pruning + +The data used to produce the hashes for leaf nodes in each MMR (in addition to +their position is the following: + +* The output MMR hashes the feature field and the commitments of all outputs + since genesis. +* The range proof MMR hashes the whole range proof data. +* The kernel MMR hashes all fields of the kernel: feature, fee, lock height, + excess commitment and excess signature. + +Note that all outputs, range proofs and kernels are added in their respective +MMRs in the order they occur in each block (recall that block data is required +to be sorted). + +As outputs get spent, both their commitment and range proof data can be +removed. In addition, the corresponding output and range proof MMRs can be +pruned. + +## State Storage + +Data storage for outputs, range proofs and kernels in Grin is simple: a plain +append-only file that's memory-mapped for data access. As outputs get spent, +a remove log maintains which positions can be removed. Those positions nicely +match MMR node positions as they're all inserted in the same order. When the +remove log gets large, corresponding files can be occasionally compacted by +rewriting them without the removed pieces (also append-only) and the remove +log can be emptied. As for MMRs, we need to add a little more complexity. From f47f1b11e3c6e92f6fe9df53f21b08b91f4e143e Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Sat, 16 Feb 2019 17:57:49 +0900 Subject: [PATCH 10/25] WIP stat_KR.md translation --- doc/state_KR.md | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/doc/state_KR.md b/doc/state_KR.md index cf2adfa557..c6d7b82d9e 100644 --- a/doc/state_KR.md +++ b/doc/state_KR.md @@ -36,11 +36,11 @@ With a full Grin state, we can validate the following: 모든 UTXO, range prook 와 Kernel 해쉬들은 각각의 MMR이 있고 그 MMR 들은 유효한 root 를 해쉬합니다. 4. A known block header with the most work at a given point in time includes the roots of the 3 MMRs. - + 특정 시점에 가장 많이 일했다고 알려진 Block header 에는 3개의 MMR에 대한 root 가 포함됩니다. This validates the MMRs and proves that the whole state has been produced by the most worked chain. 이것은 MMR과 인증하고 전체 상태가 가장 많이 일한 chain ( 가장 긴 체인)에서 만들어졌다는 것을 증명합니다. -### MMRs and Pruning +### MMR 과 Pruning The data used to produce the hashes for leaf nodes in each MMR (in addition to their position is the following: @@ -59,12 +59,15 @@ As outputs get spent, both their commitment and range proof data can be removed. In addition, the corresponding output and range proof MMRs can be pruned. -## State Storage +## 상태 스토리지 -Data storage for outputs, range proofs and kernels in Grin is simple: a plain -append-only file that's memory-mapped for data access. As outputs get spent, -a remove log maintains which positions can be removed. Those positions nicely -match MMR node positions as they're all inserted in the same order. When the -remove log gets large, corresponding files can be occasionally compacted by -rewriting them without the removed pieces (also append-only) and the remove -log can be emptied. As for MMRs, we need to add a little more complexity. +Data storage for outputs, range proofs and kernels in Grin is simple: +Grin 에 있는 출력값에 대한 데이터 스토리지, Range proof 와 kernel은 간단합니다. +a plain append-only file that's memory-mapped for data access. As outputs get spent,a remove log maintains which positions can be removed. + +Those positions nicely match MMR node positions as they're all inserted in the same order. + +When the remove log gets large, corresponding files can be occasionally compacted by rewriting them without the removed pieces (also append-only) and the remove log can be emptied. + +As for MMRs, we need to add a little more complexity. +MMR 에 대해서는 약간의 복잡함을 더할 필요가 있습니다. From f832719d30223035dd643fa53f3a8e06c686df1c Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Sat, 16 Feb 2019 18:04:50 +0900 Subject: [PATCH 11/25] translation intro.md --- doc/intro.md | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/doc/intro.md b/doc/intro.md index df4993f6de..f3aec3de4e 100644 --- a/doc/intro.md +++ b/doc/intro.md @@ -1,17 +1,16 @@ # Introduction to MimbleWimble and Grin -*Read this in other languages: [English](intro.md), [简体中文](intro.zh-cn.md), [Español](intro_ES.md), [Русский](intro.ru.md), [日本語　](intro.jp.md).* +*Read this in other languages: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md).* MimbleWimble is a blockchain format and protocol that provides extremely good scalability, privacy and fungibility by relying on strong cryptographic primitives. It addresses gaps existing in almost all current blockchain implementations. -MimbleWimlbe ㅇㅡㄴ 블록체인 포맷이면서 프로토콜 입니다. +MimbleWimlbe은 블록체인 포맷이면서 프로토콜 입니다. MimbleWimble 은 암호학적 기반에 의해서 극대화된 좋은 확장성, 프라이버시, 그리고 대체가능성을 제공합니다. 이러한 특성은 지금 현존하는 모든 블록체인 구현체에 존재하는 문제점들을 처리합니다. - Grin is an open source software project that implements a MimbleWimble blockchain and fills the gaps required for a full blockchain and cryptocurrency deployment. @@ -39,8 +38,8 @@ Grin 프로젝트의 주요 목적과 특성들은 아래 설명을 참고하십 ## Tongue Tying for Everyone ## 모두의 혀를 묶자. -This document is targeted at readers with a good -understanding of blockchains and basic cryptography. + +This document is targeted at readers with a good understanding of blockchains and basic cryptography. 이 문서는 블록체인에 대해 어느정도 이해가 있고 암호학에 대한 기본적인 이해가 있는 독자들을 대상으로 합니다. With that in mind, we attempt to explain the technical buildup of MimbleWimble and how it's applied in Grin. @@ -58,6 +57,7 @@ We will start with a brief description of some relevant properties of Elliptic C 우선 Grin이 어디에서 부터 기초로 하고 있는지에 대해 이해하기 위해서 타원 곡선 암호 (ECC)의 몇몇 속성들에 대한 간단한 설명으로 시작하겠습니다. 그 다음, MimbleWimble 블록체인의 트랜잭션과 블록에 한 모든 요소들을 설명하겠습니다. ### Tiny Bits of Elliptic Curves + ### 타원곡선에 대한 조그마한 조각들 We start with a brief primer on Elliptic Curve Cryptography, reviewing just the @@ -67,7 +67,7 @@ delving too much into the intricacies of ECC. - ECC의 너무 복잡한 사항을 캐지 않고 어떻게 mimble wimble 이 어떻게 작동하는지에 대해 이해하는데 필요한 요소들만 리뷰할 것입니다. For readers who would want to dive deeper into those assumptions, there are other opportunities to [learn more](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/). -- 이런 가정들을 좀 더 알고싶은 독자들은 [이 링크]() 를 참고하세요. +- 이런 가정들을 좀 더 알고싶은 독자들은 [이 링크](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/) 를 참고하세요. An Elliptic Curve for the purpose of cryptography is simply a large set of points that we will call _C_. These points can be added, subtracted, or multiplied by integers (also called scalars). @@ -93,19 +93,19 @@ Even if one knows the value of the public key `k*H`, deducing _k_ is close to im extremely difficult). 누군가 공개키인 `k*H`의 값을 알더라도 _k_ 를 추론해 내는것은 불가능에 가깝습니다. ( 달리 얘기하자면, 곱셉은 쉬우나 곡선 좌표에 의한 "나눗셈"은 정말 어렵습니다. ) - The previous formula `(k+j)*H = k*H + j*H`, with _k_ and _j_ both private keys, demonstrates that a public key obtained from the addition of two private keys (`(k+j)*H`) is identical to the addition of the public keys for each of those two private keys (`k*H + j*H`). _k_ 와 _j_ 둘다 비밀키인 이전 공식 `(k+j)*H = k*H + j*H` 는 두개의 비밀키를 더해서 얻은 한 개의 공개키 (`(k+j)*H`) 와 각각 두개의 비밀키에 공개키를 더한것과 같습니다. -In the Bitcoin blockchain, Hierarchical Deterministic wallets heavily rely on this principle. -Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. +In the Bitcoin blockchain, Hierarchical Deterministic wallets heavily rely on this principle. +Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. MimbleWimble and the Grin implementation do as well. MimbleWimble 과 Grin의 구현또한 마찬가지 입니다. ### Transacting with MimbleWimble -### MimbleWimble 함께 거래하기 + +### MimbleWimble 로 거래하기 The structure of transactions demonstrates a crucial tenet of MimbleWimble: 트랜잭션의 구조는 MimbleWimble의 강력한 프라이버시와 비밀이 유지된다라고 하는 중요한 규칙을 나타냅니다. @@ -113,6 +113,7 @@ strong privacy and confidentiality guarantees. The validation of MimbleWimble transactions relies on two basic properties: MimbleWimble 트랜잭션의 확인은 두가지 기본적인 성격을 전제로 합니다. + * **Verification of zero sums.** The sum of outputs minus inputs always equals zero, proving that the transaction did not create new funds, _without revealing the actual amounts_. * **제로섬의 검증** 결과값에서 입력값을 뺸 합은 항상 0과 같습니다. 이것은 실제 전송되는 코인의 양을 드러내지 않고도 트랜잭션ㅇ이 새로운 코인을 만들지 않았다는 것을 증명합니다. @@ -127,6 +128,7 @@ fundamental properties are achieved. 다음 섹션들에서는 잔고, 소유권, 거스름돈과 증명들의 상세들이 어떻게 저 두가지 기본적인 성질에 의해서 얻어지는지 알아보겠습니다. #### Balance + #### 잔고 Building upon the properties of ECC we described above, one can obscure the values @@ -160,6 +162,7 @@ An input or output value in a transaction can then be expressed as: r*G + v*H Where: 여기서 + * _r_ is a private key used as a blinding factor, _G_ is an elliptic curve and their product `r*G` is the public key for _r_ on _G_. * _r_ 은 비밀키이고 blinding factor 로 사용됩니다. _G_ 는 타원 곡선 이고 `r*G`는 _G_ 안에 있는 _r_ 의 공개키 입니다. @@ -167,10 +170,12 @@ Where: * _v_ 는 출력값이거나 입력값이고 _H_ 는 다른 타원곡선입니다. Neither _v_ nor _r_ can be deduced, leveraging the fundamental properties of Elliptic Curve Cryptography. `r*G + v*H` is called a _Pedersen Commitment_. -타원곡선의 근본적인 특성을 이용했기 때문에 _v_ 와 _r_ 은 추측될 수 없습니다. `r*G + v*H`를 _Pedersen Commitment_ 라고 부릅니다. -As a an example, let's assume we want to build a transaction with two inputs and one +타원곡선 암호의 기본적인 성질을 이용해서 _v_, _r_ 둘다 유추 할 수 없습니다. +`r*G + v*H`은 _Pederson Commitment_ 라고 불립니다. +As an example, let's assume we want to build a transaction with two inputs and one output. We have (ignoring fees): -예를 들어 , ( 전송료는 무시하고) 두개의 입력값과 한개의 출력값으로 트랜잭션을 만들기 원한다고 가정해봅시다. +예를 들어 , ( 전송료는 무시하고) 두개의 입력값과 한개의 출력값으로 트랜잭션을 만들기 원한다고 가정해봅시다. + * vi1 and vi2 as input values. * vi1 과 v2 는 출력값 * vo3 as output value. From 0ecd3ababa5d18fc23a269ff8ccd52c17fbb20cb Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Sun, 17 Feb 2019 02:07:37 +0900 Subject: [PATCH 12/25] intro_KR.md translate in Korean --- doc/intro.KR.md | 140 +++++++++++++++++++++++++++++++++--------------- 1 file changed, 98 insertions(+), 42 deletions(-) diff --git a/doc/intro.KR.md b/doc/intro.KR.md index 9650e676cd..ff04c8fedd 100644 --- a/doc/intro.KR.md +++ b/doc/intro.KR.md @@ -7,11 +7,10 @@ extremely good scalability, privacy and fungibility by relying on strong cryptographic primitives. It addresses gaps existing in almost all current blockchain implementations. -MimbleWimlbe ㅇㅡㄴ 블록체인 포맷이면서 프로토콜 입니다. -MimbleWimble 은 암호학적 기반에 의해서 극대화된 좋은 확장성, 프라이버시, 그리고 대체가능성을 제공합니다. +MimbleWimlbe은 블록체인 포맷이면서 프로토콜 입니다. +MimbleWimble은 암호학적 기반에 의해서 극대화된 좋은 확장성, 프라이버시, 그리고 대체가능성을 제공합니다. 이러한 특성은 지금 현존하는 모든 블록체인 구현체에 존재하는 문제점들을 처리합니다. - Grin is an open source software project that implements a MimbleWimble blockchain and fills the gaps required for a full blockchain and cryptocurrency deployment. @@ -28,7 +27,7 @@ Grin 프로젝트의 주요 목적과 특성들은 아래 설명을 참고하십 * Scales mostly with the number of users and minimally with the number of transactions (<100 byte `kernel`), resulting in a large space saving compared to other blockchains. -* 주로 유저의 규모와 최소한의 트랜잭션 수의 규모로 (100byte 미만의 kernel(transaction)) 다른 블록체인들과 비교하면 많은 공간을 절약할 수 있습니다. +* 주로 유저의 규모와 최소한의 트랜잭션 수의 규모로 (100byte 미만의 kernel(transaction)) 다른 블록체인들과 비교하면 많은 저장공간을 절약할 수 있습니다. * Strong and proven cryptography. MimbleWimble only relies on Elliptic Curve Cryptography which has been tried and tested for decades. * Mimble Wimble 은 수십년 동안 테스트하고 사용되었던 강력한 암호기술인 ECC만 사용합니다. @@ -49,7 +48,7 @@ With that in mind, we attempt to explain the technical buildup of MimbleWimble a We hope this document is understandable to most technically-minded readers. Our objective is to encourage you to get interested in Grin and contribute in any way possible. 저희는 이 문서가 대부분의 기술적인 성격을 가진 독자들을 이해시킬 수 있길 바랍니다. -우리의 목적은 독자가 Grin에 대해 흥기를 느끼게 하고 어떤 방식으로든 Grin에 기여할 수 있게 이끄는 것입니다. +우리의 목적은 독자가 Grin에 대해 흥미를 느끼게 하고 어떤 방식으로든 Grin에 기여할 수 있게 이끄는 것입니다. To achieve this objective, we will introduce the main concepts required for a good understanding of Grin as a MimbleWimble implementation. 이러한 목적을 이루기 위해, 우리는 MimbleWimble 의 구현체인 Grin을 이해하는데 필요한 주요 컨셉들에 대해서 소개할것입니다. @@ -64,10 +63,10 @@ We start with a brief primer on Elliptic Curve Cryptography, reviewing just the properties necessary to understand how MimbleWimble works and without delving too much into the intricacies of ECC. -- ECC의 너무 복잡한 사항을 캐지 않고 어떻게 mimble wimble 이 어떻게 작동하는지에 대해 이해하는데 필요한 요소들만 리뷰할 것입니다. +ECC의 너무 복잡한 사항을 캐지 않고 어떻게 mimble wimble 이 어떻게 작동하는지에 대해 이해하는데 필요한 요소들만 리뷰할 것입니다. - For readers who would want to dive deeper into those assumptions, there are other opportunities to [learn more](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/). -- 이런 가정들을 좀 더 알고싶은 독자들은 [이 링크]() 를 참고하세요. +For readers who would want to dive deeper into those assumptions, there are other opportunities to [learn more](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/). +이런 가정들을 좀 더 알고싶은 독자들은 [이 링크](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/)를 참고하세요. An Elliptic Curve for the purpose of cryptography is simply a large set of points that we will call _C_. These points can be added, subtracted, or multiplied by integers (also called scalars). @@ -93,14 +92,13 @@ Even if one knows the value of the public key `k*H`, deducing _k_ is close to im extremely difficult). 누군가 공개키인 `k*H`의 값을 알더라도 _k_ 를 추론해 내는것은 불가능에 가깝습니다. ( 달리 얘기하자면, 곱셉은 쉬우나 곡선 좌표에 의한 "나눗셈"은 정말 어렵습니다. ) - The previous formula `(k+j)*H = k*H + j*H`, with _k_ and _j_ both private keys, demonstrates that a public key obtained from the addition of two private keys (`(k+j)*H`) is identical to the addition of the public keys for each of those two private keys (`k*H + j*H`). -_k_ 와 _j_ 둘다 비밀키인 이전 공식 `(k+j)*H = k*H + j*H` 는 두개의 비밀키를 더해서 얻은 한 개의 공개키 (`(k+j)*H`) 와 각각 두개의 비밀키에 공개키를 더한것과 같습니다. -In the Bitcoin blockchain, Hierarchical Deterministic wallets heavily rely on this principle. -Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. +_k_ 와 _j_ 둘다 비밀키인 이전 공식 `(k+j)*H = k*H + j*H` 는 두개의 비밀키를 더해서 얻은 한 개의 공개키 (`(k+j)*H`) 와 각각 두개의 비밀키에 공개키를 더한것과 같습니다. +In the Bitcoin blockchain, Hierarchical Deterministic wallets heavily rely on this principle. +Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. MimbleWimble and the Grin implementation do as well. MimbleWimble 과 Grin의 구현또한 마찬가지 입니다. @@ -160,8 +158,8 @@ An input or output value in a transaction can then be expressed as: r*G + v*H Where: 여기서 -* _r_ is a private key used as a blinding factor, _G_ is an elliptic curve and - their product `r*G` is the public key for _r_ on _G_. + +* _r_ is a private key used as a blinding factor, _G_ is an elliptic curve and their product `r*G` is the public key for _r_ on _G_. * _r_ 은 비밀키이고 blinding factor 로 사용됩니다. _G_ 는 타원 곡선 이고 `r*G`는 _G_ 안에 있는 _r_ 의 공개키 입니다. * _v_ is the value of an input or output and _H_ is another elliptic curve. * _v_ 는 출력값이거나 입력값이고 _H_ 는 다른 타원곡선입니다. @@ -170,7 +168,7 @@ Curve Cryptography. `r*G + v*H` is called a _Pedersen Commitment_. 타원곡선의 근본적인 특성을 이용했기 때문에 _v_ 와 _r_ 은 추측될 수 없습니다. `r*G + v*H`를 _Pedersen Commitment_ 라고 부릅니다. As a an example, let's assume we want to build a transaction with two inputs and one output. We have (ignoring fees): -예를 들어 , ( 전송료는 무시하고) 두개의 입력값과 한개의 출력값으로 트랜잭션을 만들기 원한다고 가정해봅시다. +예를 들어 , ( 전송료는 무시하고) 두개의 입력값과 한개의 출력값으로 트랜잭션을 만들기 원한다고 가정해봅시다. * vi1 and vi2 as input values. * vi1 과 v2 는 출력값 * vo3 as output value. @@ -200,7 +198,9 @@ to Bitcoin. 마지막으로 이 아이디어는 Greg Maxwell 의 [Confidential Transactions](https://elementsproject.org/features/confidential-transactions/investigation) 에서 유래했습니다. Confidential transaction은 Adam back의 비트코인에 동형암호를 적용하자는 제안에서 비롯되었습니다. #### Ownership + #### 소유권 + In the previous section we introduced a private key as a blinding factor to obscure the transaction's values. 이전의 섹션에서 우리는 트랜잭션의 값을 보기 어렵게 하는 Blinding factor로서 비밀키를 소개했습니다. @@ -212,7 +212,7 @@ extremely large number). Alice는 당신에게 3 코인을 보내면서 그 양을 가렸고, 당신은 28을 당신의 blinding factor로 선택했습니다. ( 실제로 blinding factor는 비밀키로 정말 무진장 큰 숫자 입니다.) Somewhere on the blockchain, the following output appears and should only be spendable by you: -블록체인 어딘가에 다음과 같은 출력값이 나타나 있고 당신에 의해서만 소비될 수 있습니다. +블록체인 어딘가에 다음과 같은 출력값이 나타나 있고 당신에 의해서만 소비될 수 있습니다. X = 28*G + 3*H _X_, the result of the addition, is visible by everyone. The value 3 is only known to you and Alice, and 28 is only known to you. @@ -228,7 +228,7 @@ You need to build a simple transaction such that: Xi => Y -Where _Xi_ is an input that spends your _X_ output and Y is Carol's output. +Where _Xi_ is an input that spends your _X_ output and Y is Carol's output. 여기서 _Xi_는 _X_ 출력을 사용하는 입력이고 Y는 Carol의 출력입니다. There is no way to build such a transaction and balance it without knowing your private key of 28. 당신의 비밀키인 28을 모르고서는 트랜잭션과 잔액을 만들 수 있는 방법이 없습니다. @@ -236,7 +236,7 @@ There is no way to build such a transaction and balance it without knowing your Indeed, if Carol is to balance this transaction, she needs to know both the value sent and your private key 실제로 캐롤이 이 트랜잭션의 잔액을 위해선 그녀는 받는 값과 당신의 비밀키를 알아야 합니다. so that: -그러므로 +그러므로 Y - Xi = (28*G + 3*H) - (28*G + 3*H) = 0*G + 0*H By checking that everything has been zeroed out, we can again make sure that @@ -253,7 +253,7 @@ She picks 113 say, and what ends up on the blockchain is: Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H Now the transaction no longer sums to zero and we have an _excess value_ on _G_ -(85), which is the result of the summation of all blinding factors. +(85), which is the result of the summation of all blinding factors. 모든 blinding factor합계 결과로 타원곡선 _G_ 위에서 트랜잭션은 _초과값_ 을 가지게 되고 트랜잭션의 합은 더이상 0 이 아닙니다. But because `85*G` is a valid public key on the elliptic curve _G_, with private key 85, @@ -261,12 +261,13 @@ for any x and y, only if `y = 0` is `x*G + y*H` a valid public key on _G_. 그러나 `85*G` 은 비밀키 85 와 함께 타원곡선 _G_ 에서 유효한 공개키이기 때문에 모든 x와 y는 `y = 0`가 `x*G + y*H`일때 곡선 _G_ 에서 유효한 공개키입니다. So all the protocol needs to verify is that (`Y - Xi`) is a valid public key on _G_ and that -the transacting parties collectively know the private key (85 in our transaction with Carol). -그러므로 모든 프로토콜은 (`Y - Xi`) 가 _G_위에서 유효한 공개키인지 ,거래당사자들이 비밀키를 알고있는지 ( 캐롤과의 트랜잭션에서는 85) 를 검증해야 할 필요가 있습니다. +the transacting parties collectively know the private key (85 in our transaction with Carol). +그러므로 모든 프로토콜은 (`Y - Xi`) 가 _G_위에서 유효한 공개키인지 ,거래당사자들이 비밀키를 알고있는지 ( 캐롤과의 트랜잭션에서는 85) 를 검증해야 할 필요가 있습니다. The simplest way to do so is to require a signature built with the excess value (85), which then validates that: 가장 간단하게 검증하는 방법은 Signature가 초과값과 함께 만들어졌다는 것을 요구한 다음 아래와 같은것을 인증하는 겁니다. + * The transacting parties collectively know the private key, and * 거래하는 당사자들은 모두 비밀키를 알고 있고 * The sum of the transaction outputs, minus the inputs, sum to a zero value @@ -279,89 +280,136 @@ fees), is called a _transaction kernel_ and is checked by all validators. 모든 트랜잭션에 포함된 이 Signature 는 덧붙여진 어떤 데이터와 함께(채굴 수수료와 같은 데이터) _transaction kernel_ 이라고 부르고 모든 Validator 에 의해 체크됩니다. #### Some Finer Points -#### 몇몇 좋은 점들 +#### 몇몇 더 좋은 점들 + This section elaborates on the building of transactions by discussing how change is introduced and the requirement for range proofs so all values are proven to be -non-negative. +non-negative. 이 섹션은 트랜잭션을 만들때 잔돈이 어떻게 보여지고 범위 증명(range proofs)의 요구사항에 대해서 모든 값이 음수가 아닌지에 대해서 좀 더 자세하게 설명하려고 합니다. Neither of these are absolutely required to understand MimbleWimble and Grin, so if you're in a hurry, feel free to jump straight to [Putting It All Together](#putting-it-all-together). -이러한 개념들 역시 MimbleWimble 과 Grin 에 대한 이해가 당연히 필요합니다. -만약 당신이 조급하다면 +이러한 개념들 역시 MimbleWimble 과 Grin 에 대한 이해가 당연히 필요합니다. +만약 당신이 조급하다면 [이 링크를 참고하세요.](#putting-it-all-together). + ##### Change +##### 잔돈에 대해서 + Let's say you only want to send 2 coins to Carol from the 3 you received from -Alice. To do this you would send the remaining 1 coin back to yourself as change. +Alice. +캐롤에게 2개의 코인을 보내고 3개를 앨리스에게서 받는다고 해봅시다. +To do this you would send the remaining 1 coin back to yourself as change. +이렇게 하려면 당신은 남은 1개의 코인을 잔돈으로 당신에게 돌려줘야 합니다. You generate another private key (say 12) as a blinding factor to protect your change output. Carol uses her own private key as before. +이때, 다른 비밀키를 blinding factor 로 만들어서 (12라고 합시다.) 출력값을 보호해야 합니다. 캐롤은 이전에 썻던 그녀의 비밀키를 씁니다. Change output: 12*G + 1*H Carol's output: 113*G + 2*H What ends up on the blockchain is something very similar to before. +블록체인 안에서의 결과는 예전과 매우 흡사합니다. And the signature is again built with the excess value, 97 in this example. - +그리고 Signature 은 초과되는 값과 함께 다시 만들어질겁니다. 이 예시에서는 97이라고 합시다. (12*G + 1*H) + (113*G + 2*H) - (28*G + 3*H) = 97*G + 0*H ##### Range Proofs -In all the above calculations, we rely on the transaction values to always be positive. The -introduction of negative amounts would be extremely problematic as one could +In all the above calculations, we rely on the transaction values to always be positive. +위의 모든 게산에서 트랜잭션의 값들은 항상 양의(+)값입니다. +The introduction of negative amounts would be extremely problematic as one could create new funds in every transaction. +음의 값은 모든 트랜잭션마다 새로운 돈을 만들수 있다는 것이므로 매우 문제점이 될겁니다. For example, one could create a transaction with an input of 2 and outputs of 5 and -3 and still obtain a well-balanced transaction, following the definition in -the previous sections. This can't be easily detected because even if _x_ is +the previous sections. +예를 들어 입력값이 3이고 출력값이 5과 -3인 트랜잭션을 만들수 있고 이전 섹션의 정의에 따라 잘 구성된 트랜잭션입니다. +This can't be easily detected because even if _x_ is negative, the corresponding point `x.H` on the curve looks like any other. +적잘한 좌표 `x.H`가 다른 좌표처럼 곡선위에 있어서 _x_가 음수이더라도 찾기가 쉽지 않습니다. To solve this problem, MimbleWimble leverages another cryptographic concept (also -coming from Confidential Transactions) called -range proofs: a proof that a number falls within a given range, without revealing -the number. We won't elaborate on the range proof, but you just need to know +coming from Confidential Transactions) called range proofs: +이 문제점을 해결하기 위해서, MimbleWimble 은 Range proofs 라는 다른 암호학 개념을 사용합니다. ( 이 또한 Confidential Transaction 에서 유래했습니다.) +a proof that a number falls within a given range, without revealing +the number. +Range proof 란 숫자를 밝히지 않고 어떤 숫자가 주어진 범위안에 있는지 증명하는 것입니다. +We won't elaborate on the range proof, but you just need to know that for any `r.G + v.H` we can build a proof that will show that _v_ is greater than zero and does not overflow. - -It's also important to note that in order to create a valid range proof from the example above, both of the values 113 and 28 used in creating and signing for the excess value must be known. The reason for this, as well as a more detailed description of range proofs are further detailed in the [range proof paper](https://eprint.iacr.org/2017/1066.pdf). +Range proof 에 대해서 자세히 설명하지 않을것이지만은, 그래도 어떤 `r.G + v.H` 의 결과가 _v_ 가 0보다 크고 오버플로우가 일어나지 않는다는 것을 증명할 수 있습니다. +It's also important to note that in order to create a valid range proof from the example above, both of the values 113 and 28 used in creating and signing for the excess value must be known. 또한 위의 예에서 유효한 Range proof 를 만들기 위해서 트랜잭션을 만들고 Signing 할때 사용된 초과값인 113과 28 두 값이 알려지는것은 중요합니다. +The reason for this, as well as a more detailed description of range proofs are further detailed in the [range proof paper](https://eprint.iacr.org/2017/1066.pdf). +그 이유는, [range proof paper](https://eprint.iacr.org/2017/1066.pdf)에 Range proof에 대해 좀더 자세한 설명이 있습니다. #### Putting It All Together +#### 모든것을 함깨 놓고 이해하기 + A MimbleWimble transaction includes the following: +MimbleWimlbe 트랜잭션은 다음을 포함합니다. * A set of inputs, that reference and spend a set of previous outputs. +* 이전의 출력값들이 참조하고 사용한 입력값의 셋트들 * A set of new outputs that include: +* 새로운 출력값들은 다음을 포함합니다. * A value and a blinding factor (which is just a new private key) multiplied on a curve and summed to be `r.G + v.H`. + * 곡선위에서 `r.G + v.H` 로 합해 지는 값 과 blinding factor (그냥 새로운 비밀 키). * A range proof that shows that v is non-negative. + * v 가 음수가 아님을 보여주는 Range proof. * An explicit transaction fee, in clear. +* 분명히 명시된 트랜잭션 수수료 * A signature, computed by taking the excess blinding value (the sum of all outputs plus the fee, minus the inputs) and using it as a private key. +* 수수료가 더해진 모든 출력밧에서 입력값을 뺸 초과 blinding 값이 계산되고 그것이 비밀키로 사용된 Signature. ### Blocks and Chain State +### 블록들과 체인 state에 대해서 + We've explained above how MimbleWimble transactions can provide strong anonymity guarantees while maintaining the properties required for a valid -blockchain, i.e., a transaction does not create money and proof of ownership +blockchain, +위에서 MimbleWimble 트랜잭션이 유요한 블록체인에 필요한 속성을 유지하면서 어떻게 강한 익명성을 보장하는지 설명했습니다. +i.e., a transaction does not create money and proof of ownership is established through private keys. +예를들면 트랜잭션이 더이상 코인을 만들지 않으면서 비밀키를 통해 소유권을 증명하지 않는 방법들 같은것 말이죠. The MimbleWimble block format builds on this by introducing one additional -concept: _cut-through_. With this addition, a MimbleWimble chain gains: +concept: _cut-through_. +추가적으로 _cut-through_ 라는 개념이 MimbleWimble 블록 포멧에 사용 됩니다. + With this addition, a MimbleWimble chain gains: +이로 인해 MimbleWimble 체인은 아래와 같은 장점을 얻습니다. * Extremely good scalability, as the great majority of transaction data can be eliminated over time, without compromising security. +* 대부분의 트랜잭션 데이터는 보안을 희생하지 않고서도 시간이 지나면 없어 질 수 있으므로 엄청나게 좋은 확장성을 얻게 됩니다. * Further anonymity by mixing and removing transaction data. +* 트랜잭션 데이터를 섞고 없애서 익명성을 추가로 획득합니다. * And the ability for new nodes to sync up with the rest of the network very efficiently. +* 새로운 노드가 네트웍에서 동기화를 이룰때 매우 효과적입니다. #### Transaction Aggregation +#### 트랜잭션 합치기 + Recall that a transaction consists of the following - +트랜잭션언 다음와 같은것들로 이뤄져 있다는걸 상기해봅시다. * a set of inputs that reference and spent a set of previous outputs +* 이전의 출력값들이 참조하고 사용한 입력값의 셋트들 * a set of new outputs (Pedersen commitments) +* 새로운 출력값의 세트들 ( Pederson commitment) * a transaction kernel, consisting of * kernel excess (Pedersen commitment to zero) * transaction signature (using kernel excess as public key) +* kernal execess와 (kernel 초과값이 공개키로 사용된) 트랜잭션 Signature로 이뤄진 트랜잭션 Kernel + +A tx is signed and the signature included in a _transaction kernel_. -A tx is signed and the signature included in a _transaction kernel_. The signature is generated using the _kernel excess_ as a public key proving that the transaction sums to 0. +The signature is generated using the _kernel excess_ as a public key proving that the transaction sums to 0. (42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H @@ -471,9 +519,12 @@ guarantees: And yet, it all still validates! #### Cut-through All The Way +#### 내내 Cut-through 하기 Going back to the previous example block, outputs x1 and x2, spent by I1 and -I2, must have appeared previously in the blockchain. So after the addition of +I2, must have appeared previously in the blockchain. + +So after the addition of this block, those outputs as well as I1 and I2 can also be removed from the overall chain, as they do not contribute to the overall sum. @@ -500,9 +551,14 @@ blinding factors in the transaction kernels to differ from the summation of blin factors in the outputs. ### Conclusion - +### 결론 내리기 In this document we covered the basic principles that underlie a MimbleWimble -blockchain. By using the addition properties of Elliptic Curve Cryptography, we're +blockchain. +이 문서에서는 MimbleWimble 블록체인 안의 기본적인 원리에 대해서 다루었습니다. +By using the addition properties of Elliptic Curve Cryptography, we're able to build transactions that are completely opaque but can still be properly -validated. And by generalizing those properties to blocks, we can eliminate a large +validated. +타원 곡선 암호의 다른 성질을 사용해서 알아보기 어려우나 적절하게 입증될 수 있는 트랜잭션을 만들수 있습니다. +And by generalizing those properties to blocks, we can eliminate a large amount of blockchain data, allowing for great scaling and fast sync of new peers. +블록들에 이러한 성질들을 일반화 시키면 큰 용량의 블록체인 데이터를 없앨 수 있고 새로운 피어들에게 높은 확장성과 빠른 동기화를 가능하게 할 수 있습니다. From fa448f34165181ffb0d051d95c6dc8635d97ef3f Mon Sep 17 00:00:00 2001 From: YOUNGJUN KO Date: Sun, 17 Feb 2019 16:01:43 +0900 Subject: [PATCH 13/25] add build_KR.md && stratum_KR.md --- doc/build_KR.md | 141 +++++++++++ doc/code_structure.md | 2 +- doc/intro.KR.md | 5 +- doc/stratum_KR.md | 543 ++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 688 insertions(+), 3 deletions(-) create mode 100644 doc/build_KR.md create mode 100644 doc/stratum_KR.md diff --git a/doc/build_KR.md b/doc/build_KR.md new file mode 100644 index 0000000000..8b9f4755b2 --- /dev/null +++ b/doc/build_KR.md @@ -0,0 +1,141 @@ +# Grin - Build, Configuration, and Running + +*다른 언어로 되어있는 문서를 읽으려면:[에스파냐어](build_ES.md). + +## 지원하는 플랫폼들에 대해서 + +Longer term, most platforms will likely be supported to some extent. +장기적으로는 대부분의 플랫폼에서 어느정도의 규모로 지원하게 될 것입니다. +Grin's programming language `rust` has build targets for most platforms. +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 can also be built in debug mode (without the `--release` flag, but using the `--debug` or the `--verbose` flag) but this will render fast sync prohibitively slow due to the large overhead of cryptographic operations. +Grin은 Debug 모드로 Build 할 수 있습니다. (`--release` 플래그가 아닌, but `--debug` 또는 `--verbose` 플래그를 사용하세요.) 그러나 이 명령어는 암호 오퍼레이션으로 인해 큰 오버헤드를 가지므로 fast sync 가 어려울 정도로 느려집니다. + +## Build 에러들 + +[트러블 슈팅 관련해서는 이 링크를 클릭하세요.](https://github.com/mimblewimble/docs/wiki/Troubleshooting) + +## 무엇을 Build 해야 되나요? + +A successful build gets you: + +* `~/.grin/main/grin-server.toml`. +모든 데이터, 설정, 로그 파일들은 기본적으로 (지정되지 않는다면) `~/.grin` 에 만들어지고 사용됩니다. (user home 디렉토리 안에 있습니다.) +`~/.grin/main/grin-server.toml` 을 수정해서 모든 설정값들을 바꿀 수 있습니다. + +Grin은 현재 디렉토리 내에서도 데이터 파일들을 만들 수 있습니다. +밑에 있는 Bash 명령어를 작동하세요. + +```sh +grin server config +``` + +Which will generate a `grin-server.toml` file in the current directory, pre-configured to use +the current directory for all of its data. +TODO 위에있는 영어문장 번역기에 돌려볼것. +현재 디렉토리에서 모함한 모든 데이터에 대해 미리 설정된 `grin-server.toml` 파일 내의 값들이 사용됩니다. + +Testing 중에서는 Grin 바이너리를 이렇게 path 에 삽입 할 수도 있습니다. + +```sh +export PATH=`pwd`/target/release:$PATH +``` + +만약 Grin을 root 디렉토리에서 실행한다면, `grin` 명령어를 바로 실행할 수 있습니다. (`grin help` 명령어를 통해서 좀 더 많은 옵션을 알아보세요.) + +## 설정하기 + +Grin attempts to run with sensible defaults, and can be further configured via +the `grin-server.toml` file. This file is generated by grin on its first run, and +contains documentation on each available option. + +While it's recommended that you perform all grin server configuration via +`grin-server.toml`, it's also possible to supply command line switches to grin that +override any settings in the file. + +For help on grin commands and their switches, try: + +```sh +grin help +grin wallet help +grin client help +``` + +## Docker 사용하기 + +```sh +docker build -t grin -f etc/Dockerfile . +``` + +floonet을 사용하려면 `etc/Dockerfile.floonet` 을 사용하세요. +You can bind-mount your grin cache to run inside the container. + +```sh +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 + +## 크로스 플랫폼 빌드 + +Rust (cargo) can build grin for many platforms, so in theory running `grin` +as a validating node on your low powered device might be possible. +To cross-compile `grin` on a x86 Linux platform and produce ARM binaries, +say, for a Raspberry Pi. + +## Grin 사용하기 + +The wiki page [Wallet User Guide](https://github.com/mimblewimble/docs/wiki/Wallet-User-Guide) +and linked pages have more information on what features we have, +troubleshooting, etc. + +## Grin 채굴하기 + +Please note that all mining functions for Grin have moved into a separate, standalone package called +[grin-miner](https://github.com/mimblewimble/grin-miner). Once your Grin code node is up and running, +you can start mining by building and running grin-miner against your running Grin node. + +For grin-miner to be able to communicate with your grin node, make sure that you have `enable_stratum_server = true` +in your `grin-server.toml` configuration file and you have a wallet listener running (`grin wallet listen`). diff --git a/doc/code_structure.md b/doc/code_structure.md index 04ba1f0680..f284eab15f 100644 --- a/doc/code_structure.md +++ b/doc/code_structure.md @@ -1,7 +1,7 @@ # Grin code structure Grin is built in [Rust](https://www.rust-lang.org/), a memory safe, compiled language. Performance critical parts like the Cuckoo mining algorithm are built as plugins, making it easy to swap between algorithm implementations for various hardware. Grin comes with CPU and experimental GPU support. - +markdown ## Files in project root List of files tracked in `git` and some files you'll create when you use grin. diff --git a/doc/intro.KR.md b/doc/intro.KR.md index ff04c8fedd..361bb59b4d 100644 --- a/doc/intro.KR.md +++ b/doc/intro.KR.md @@ -405,12 +405,13 @@ Recall that a transaction consists of the following - * a transaction kernel, consisting of * kernel excess (Pedersen commitment to zero) * transaction signature (using kernel excess as public key) -* kernal execess와 (kernel 초과값이 공개키로 사용된) 트랜잭션 Signature로 이뤄진 트랜잭션 Kernel +* kernal execess와 (kernel 초과값이 공개키로 사용된) 트랜잭션 Signature로 이뤄진 트랜잭션 Kernel. A tx is signed and the signature included in a _transaction kernel_. +sign 된 트랜잭션과 Signature 은 _transaction kernel_ 에 포함됩니다. The signature is generated using the _kernel excess_ as a public key proving that the transaction sums to 0. - +Signature 은 (42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H The public key in this example being `28*G`. diff --git a/doc/stratum_KR.md b/doc/stratum_KR.md new file mode 100644 index 0000000000..273116b97a --- /dev/null +++ b/doc/stratum_KR.md @@ -0,0 +1,543 @@ +# Grin Stratum RPC Protocol + +This document describes the current Stratum RPC protocol implemented in Grin. +이 문서는 Grin에 구현되어 있는 현재 Stratum RPC protocol 을 설명한 것입니다. + +## Table of Contents +## 목차 + +1. [Messages](#messages) + 1. [getjobtemplate](#getjobtemplate) + 1. [job](#job) + 1. [keepalive](#keepalive) + 1. [login](#login) + 1. [status](#status) + 1. [submit](#submit) +1. [Error Messages](#error-messages) +1. [Miner Behavior](#miner-behavior) +1. [Reference Implementation](#reference-implementation) + +## Messages + +In this section, we detail each message and the potential response. +이 섹션에서는 각 메시지와 그 응답에 대해서 상술합니다. +At any point, if miner the tries to do one of the following request (except login) and login is required, the miner will receive the following error message. +어느때든, 채굴자가 로그인을 제외한 다음 중 한 요청을 하고 login 이 요구된다면 채굴자는 다음과 같은 에러 메시지를 받게 됩니다. + +| Field | Content | +| :------------ | :-------------------------------------- | +| id | ID of the request | +| id | 요청한 ID | +| jsonrpc | "2.0" | +| method | method sent by the miner | +| method | 채굴자가 보낸 method | +| error | {"code":-32500,"message":"login first"} | + +Example: +예시 + +```JSON +{ + "id":"10", + "jsonrpc":"2.0", + "method":"getjobtemplate", + "error":{ + "code":-32500, + "message":"login first" + } +} +``` + +if the request is not one of the following, the stratum server will give this error response: + +| Field | Content | +| :------------ | :------------------------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | method sent by the miner | +| error | {"code":-32601,"message":"Method not found"} | + +Example: + +```JSON +{ + "id":"10", + "jsonrpc":"2.0", + "method":"getgrins", + "error":{ + "code":-32601, + "message":"Method not found" + } +} +``` + +### `getjobtemplate` + +A message initiated by the miner. +Miner can request a job with this message. + +#### Request + +| Field | Content | +| :------------ | :----------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "getjobtemplate" | +| params | null | + +Example: + +``` JSON +{ + "id":"2", + "jsonrpc":"2.0", + "method":"getjobtemplate", + "params":null +} +``` + +#### Response + +The response can be of two types: + +##### OK response + +Example: + +``` JSON +{ + "id":"0", + "jsonrpc":"2.0", + "method":"getjobtemplate", + "result":{ + "difficulty":1, + "height":13726, + "job_id":4, + "pre_pow":"00010000000000003c4d0171369781424b39c81eb39de10cdf4a7cc27bbc6769203c7c9bc02cc6a1dfc6000000005b50f8210000000000395f123c6856055aab2369fe325c3d709b129dee5c96f2db60cdbc0dc123a80cb0b89e883ae2614f8dbd169888a95c0513b1ac7e069de82e5d479cf838281f7838b4bf75ea7c9222a1ad7406a4cab29af4e018c402f70dc8e9ef3d085169391c78741c656ec0f11f62d41b463c82737970afaa431c5cabb9b759cdfa52d761ac451276084366d1ba9efff2db9ed07eec1bcd8da352b32227f452dfa987ad249f689d9780000000000000b9e00000000000009954" + } +} +``` + +##### Error response + +If the node is syncing, it will send the following message: + +| Field | Content | +| :------------ | :-------------------------------------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "getjobtemplate" | +| error | {"code":-32701,"message":"Node is syncing - Please wait"} | + +Example: + +```JSON +{ + "id":"10", + "jsonrpc":"2.0", + "method":"getjobtemplate", + "error":{ + "code":-32000, + "message":"Node is syncing - Please wait" + } +} +``` + +### `job` + +A message initiated by the Stratum server. +Stratum server will send job automatically to connected miners. +The miner SHOULD interrupt current job if job_id = 0, and SHOULD replace the current job with this one after the current graph is complete. + +#### Request + +| Field | Content | +| :------------ | :------------------------------------------------------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "job" | +| params | Int `difficulty`, `height`, `job_id` and string `pre_pow` | + +Example: + +``` JSON +{ + "id":"Stratum", + "jsonrpc":"2.0", + "method":"job", + "params":{ + "difficulty":1, + "height":16375, + "job_id":5, + "pre_pow":"00010000000000003ff723bc8c987b0c594794a0487e52260c5343288749c7e288de95a80afa558c5fb8000000005b51f15f00000000003cadef6a45edf92d2520bf45cbd4f36b5ef283c53d8266bbe9aa1b8daaa1458ce5578fcb0978b3995dd00e3bfc5a9277190bb9407a30d66aec26ff55a2b50214b22cdc1f3894f27374f568b2fe94d857b6b3808124888dd5eff7e8de7e451ac805a4ebd6551fa7a529a1b9f35f761719ed41bfef6ab081defc45a64a374dfd8321feac083741f29207b044071d93904986fa322df610e210c543c2f95522c9bdaef5f598000000000000c184000000000000a0cf" + } +} +``` + +#### Response + +No response is required for this message. + +### `keepalive` + +A message initiated by the miner in order to keep the connection alive. + +#### Request + +| Field | Content | +| :------------ | :--------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "keepalive" | +| params | null | + +Example: + +``` JSON +{ + "id":"2", + "jsonrpc":"2.0", + "method":"keepalive", + "params":null +} +``` + +#### Response + +| Field | Content | +| :------------ | :----------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "keepalive" | +| result | "ok" | +| error | null | + +Example: + +``` JSON +{ + "id":"2", + "jsonrpc":"2.0", + "method":"keepalive", + "result":"ok", + "error":null +} +``` + +### `login` + +*** + +A message initiated by the miner. +Miner can log in on a Grin Stratum server with a login, password and agent (usually statically set by the miner program). + +#### Request + +| Field | Content | +| :------------ | :----------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "login" | +| params | Strings: login, pass and agent | + +Example: + +``` JSON + +{ + "id":"0", + "jsonrpc":"2.0", + "method":"login", + "params":{ + "login":"login", + "pass":"password", + "agent":"grin-miner" + } +} + +``` +#### Response + +The response can be of two types: + +##### OK response + +| Field | Content | +| :------------ | :----------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "login" | +| result | "ok" | +| error | null | + +Example: + +``` JSON +{ + "id":"1", + "jsonrpc":"2.0", + "method":"login", + "result":"ok", + "error":null +} +``` + +##### Error response + +Not yet implemented. Should return error -32500 "Login first" when login is required. + +### `status` + +A message initiated by the miner. +This message allows a miner to get the status of its current worker and the network. + +#### Request + +| Field | Content | +| :------------ | :--------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "status" | +| params | null | + +Example: + +``` JSON +{ + "id":"2", + "jsonrpc":"2.0", + "method":"status", + "params":null +} +``` + +#### Response + +The response is the following: + +| Field | Content | +| :------------ | :------------------------------------------------------------------------------------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "status" | +| result | String `id`. Integers `height`, `difficulty`, `accepted`, `rejected` and `stale` | +| error | null | + +Example: + +```JSON +{ + "id":"5", + "jsonrpc":"2.0", + "method":"status", + "result":{ + "id":"5", + "height":13726, + "difficulty":1, + "accepted":0, + "rejected":0, + "stale":0 + }, + "error":null +} +``` + +### `submit` + +A message initiated by the miner. +When a miner find a share, it will submit it to the node. + +#### Request + +The miner submit a solution to a job to the Stratum server. + +| Field | Content | +| :------------ | :-------------------------------------------------------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "submit" | +| params | Int `edge_bits`,`nonce`, `height`, `job_id` and array of integers `pow` | + +Example: + +``` JSON +{ + "id":"0", + "jsonrpc":"2.0", + "method":"submit", + "params":{ + "edge_bits":29, + "height":16419, + "job_id":0, + "nonce":8895699060858340771, + "pow":[ + 4210040,10141596,13269632,24291934,28079062,84254573,84493890,100560174,100657333,120128285,130518226,140371663,142109188,159800646,163323737,171019100,176840047,191220010,192245584,198941444,209276164,216952635,217795152,225662613,230166736,231315079,248639876,263910393,293995691,298361937,326412694,330363619,414572127,424798984,426489226,466671748,466924466,490048497,495035248,496623057,502828197, 532838434 + ] + } +} +``` + +#### Response + +The response can be of three types. + +##### OK response + +The share is accepted by the Stratum but is not a valid cuck(at)oo solution at the network target difficulty. + +| Field | Content | +| :------------ | :----------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "submit" | +| result | "ok" | +| error | null | + +Example: + +``` JSON +{ + "id":"2", + "jsonrpc":"2.0", + "method":"submit", + "result":"ok", + "error":null +} +``` + +##### Blockfound response + +The share is accepted by the Stratum and is a valid cuck(at)oo solution at the network target difficulty. + +| Field | Content | +| :------------ | :----------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "submit" | +| result | "block - " + hash of the block | +| error | null | + +Example: + +``` JSON +{ + "id":"6", + "jsonrpc":"2.0", + "method":"submit", + "result":"blockfound - 23025af9032de812d15228121d5e4b0e977d30ad8036ab07131104787b9dcf10", + "error":null +} +``` + +##### Error response + +The error response can be of two types: stale and rejected. + +##### Stale share error response + +The share is a valid solution to a previous job not the current one. + +| Field | Content | +| :------------ | :-------------------------------------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "submit" | +| error | {"code":-32503,"message":"Solution submitted too late"} | + +Example: + +```JSON +{ + "id":"5", + "jsonrpc":"2.0", + "method":"submit", + "error":{ + "code":-32503, + "message":"Solution submitted too late" + } +} +``` + +##### Rejected share error responses + +Two possibilities: the solution cannot be validated or the solution is of too low difficulty. + +###### Failed to validate solution error + +The submitted solution cannot be validated. + +| Field | Content | +| :------------ | :-------------------------------------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "submit" | +| error | {"code":-32502,"message":"Failed to validate solution"} | + +Example: + +```JSON +{ + "id":"5", + "jsonrpc":"2.0", + "method":"submit", + "error":{ + "code":-32502, + "message":"Failed to validate solution" + } +} +``` + +###### Share rejected due to low difficulty error + +The submitted solution is of too low difficulty. + +| Field | Content | +| :------------ | :--------------------------------------------------------------- | +| id | ID of the request | +| jsonrpc | "2.0" | +| method | "submit" | +| error | {"code":-32501,"message":"Share rejected due to low difficulty"} | + +Example: + +```JSON +{ + "id":"5", + "jsonrpc":"2.0", + "method":"submit", + "error":{ + "code":-32501, + "message":"Share rejected due to low difficulty" + } +} +``` + +## Error Messages + +Grin Stratum protocol implementation contains the following error message: + +| Error code | Error Message | +| :---------- | :------------------------------------- | +| -32000 | Node is syncing - please wait | +| -32500 | Login first | +| -32501 | Share rejected due to low difficulty | +| -32502 | Failed to validate solution | +| -32503 | Solution Submitted too late | +| -32600 | Invalid Request | +| -32601 | Method not found | + +## Miner behavior + +Miners SHOULD, MAY or MUST respect the following rules: + +- Miners SHOULD randomize the job nonce before starting +- Miners MUST continue mining the same job until the server sends a new one, though a miner MAY request a new job at any time +- Miners MUST NOT send an rpc response to a job request from the server +- Miners MAY set the RPC "id" and expect responses to have that same id +- Miners MAY send a keepalive message +- Miners MAY send a login request (to identify which miner finds shares / solutions in the logs), the login request MUST have all 3 params. +- Miners MUST return the supplied job_id with submit messages. + +## Reference Implementation + +The current reference implementation is available at [mimblewimble/grin-miner](https://github.com/mimblewimble/grin-miner/blob/master/src/bin/client.rs). From 117d0b63630690e28e0a4eac32d416bca4a621a0 Mon Sep 17 00:00:00 2001 From: YOUNGJUN KO Date: Sun, 17 Feb 2019 16:04:42 +0900 Subject: [PATCH 14/25] [WIP] stratum_KR translation. --- doc/stratum_KR.md | 33 +++++++++++++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-) diff --git a/doc/stratum_KR.md b/doc/stratum_KR.md index 273116b97a..83ae4109df 100644 --- a/doc/stratum_KR.md +++ b/doc/stratum_KR.md @@ -4,6 +4,7 @@ This document describes the current Stratum RPC protocol implemented in Grin. 이 문서는 Grin에 구현되어 있는 현재 Stratum RPC protocol 을 설명한 것입니다. ## Table of Contents + ## 목차 1. [Messages](#messages) @@ -22,7 +23,7 @@ This document describes the current Stratum RPC protocol implemented in Grin. In this section, we detail each message and the potential response. 이 섹션에서는 각 메시지와 그 응답에 대해서 상술합니다. At any point, if miner the tries to do one of the following request (except login) and login is required, the miner will receive the following error message. -어느때든, 채굴자가 로그인을 제외한 다음 중 한 요청을 하고 login 이 요구된다면 채굴자는 다음과 같은 에러 메시지를 받게 됩니다. +어느때든, 채굴자가 로그인을 제외한 다음 중 한 요청을 하고 login 이 요구된다면 채굴자는 다음과 같은 에러 메시지를 받게 됩니다. | Field | Content | | :------------ | :-------------------------------------- | @@ -34,7 +35,7 @@ At any point, if miner the tries to do one of the following request (except logi | error | {"code":-32500,"message":"login first"} | Example: -예시 +예시: ```JSON { @@ -49,6 +50,7 @@ Example: ``` if the request is not one of the following, the stratum server will give this error response: +만약에 요청이 다음중 하나가 아니라면, Stratum 서버가 이런 에러 메시지를 보내게 됩니다. | Field | Content | | :------------ | :------------------------------------------- | @@ -58,6 +60,7 @@ if the request is not one of the following, the stratum server will give this er | error | {"code":-32601,"message":"Method not found"} | Example: +예시: ```JSON { @@ -74,7 +77,9 @@ Example: ### `getjobtemplate` A message initiated by the miner. +채굴자에 의해 초기화 되는 메시지입니다. Miner can request a job with this message. +채굴자는 이 메시지로 작업을 요청 할 수 있습니다. #### Request @@ -86,6 +91,7 @@ Miner can request a job with this message. | params | null | Example: +예시 : ``` JSON { @@ -99,6 +105,7 @@ Example: #### Response The response can be of two types: +Response 는 두가지 타입이 될 수 있습니다. ##### OK response @@ -121,6 +128,7 @@ Example: ##### Error response If the node is syncing, it will send the following message: +만약 노드가 동기화 중이라면, 다음과 같은 메시지를 보낼것입니다. | Field | Content | | :------------ | :-------------------------------------------------------- | @@ -130,6 +138,7 @@ If the node is syncing, it will send the following message: | error | {"code":-32701,"message":"Node is syncing - Please wait"} | Example: +예시: ```JSON { @@ -146,8 +155,11 @@ Example: ### `job` A message initiated by the Stratum server. +Stratum 서버가 초기화 하는 메세지입니다. Stratum server will send job automatically to connected miners. +Stratum 서버는 연결된 채굴자에게 작업을 자동적으로 보냅니다. The miner SHOULD interrupt current job if job_id = 0, and SHOULD replace the current job with this one after the current graph is complete. +채굴자는 job_id=0 이면 현재의 작업을 중단해야 합니다. 그리고 현재의 작업을 현재 graph 가 완료되면 이 작업으로 대체해야 합니다. #### Request @@ -177,10 +189,12 @@ Example: #### Response No response is required for this message. +이 메세지에는 Response 가 필요하지 않습니다. ### `keepalive` A message initiated by the miner in order to keep the connection alive. +연결을 계속 하기 위해서 채굴자에 의해 초기화 되는 메시지입니다. #### Request @@ -229,7 +243,9 @@ Example: *** A message initiated by the miner. +채굴자에 의해 시작되는 메시지입니다. Miner can log in on a Grin Stratum server with a login, password and agent (usually statically set by the miner program). +채굴자는 보통 마이너 프로그램으로 고정적으로 정해지는 login, password, agent 로 Grin Stratum 서버에 로그인 할 수 있습니다. #### Request @@ -241,6 +257,7 @@ Miner can log in on a Grin Stratum server with a login, password and agent (usua | params | Strings: login, pass and agent | Example: +예시: ``` JSON @@ -256,9 +273,11 @@ Example: } ``` + #### Response The response can be of two types: +Response 는 두가지 타입 일 수 있습니다. ##### OK response @@ -285,11 +304,14 @@ Example: ##### Error response Not yet implemented. Should return error -32500 "Login first" when login is required. +아직 구현되지 않았습니다. login이 필요할때, -32500 "Login firtst" 라는 에러를 리턴합니다. ### `status` A message initiated by the miner. +채굴자에 의해 시작되는 메시지입니다. This message allows a miner to get the status of its current worker and the network. +이 메시지는 채굴자에게 현재의 워커와 네트워크의 상태를 얻을 수 있게 합니다. #### Request @@ -314,6 +336,7 @@ Example: #### Response The response is the following: +Response 는 아래와 같습니다. | Field | Content | | :------------ | :------------------------------------------------------------------------------------------------------- | @@ -324,6 +347,7 @@ The response is the following: | error | null | Example: +예시: ```JSON { @@ -345,11 +369,14 @@ Example: ### `submit` A message initiated by the miner. +채굴자에 의해 시작되는 메시지입니다. When a miner find a share, it will submit it to the node. +마이너가 쉐어를 찾았을때, 노드에게 보내집니다. #### Request The miner submit a solution to a job to the Stratum server. +채굴자는 Stratum 서버에 작업 정답을 보냅니다. | Field | Content | | :------------ | :-------------------------------------------------------------------------- | @@ -359,6 +386,7 @@ The miner submit a solution to a job to the Stratum server. | params | Int `edge_bits`,`nonce`, `height`, `job_id` and array of integers `pow` | Example: +예시: ``` JSON { @@ -380,6 +408,7 @@ Example: #### Response The response can be of three types. +Response 는 세가지 타입이 될것입니다. ##### OK response From 6ae5484c764698ca3e813863a57ffa224fff83b5 Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Sun, 17 Feb 2019 21:09:15 +0900 Subject: [PATCH 15/25] finish State translate in Korean --- doc/stratum_KR.md | 180 +++++++++++++++++++--------------------------- 1 file changed, 72 insertions(+), 108 deletions(-) diff --git a/doc/stratum_KR.md b/doc/stratum_KR.md index 83ae4109df..65fe4fbb34 100644 --- a/doc/stratum_KR.md +++ b/doc/stratum_KR.md @@ -1,40 +1,32 @@ -# Grin Stratum RPC Protocol +# Grin Stratum RPC 프로토콜 -This document describes the current Stratum RPC protocol implemented in Grin. 이 문서는 Grin에 구현되어 있는 현재 Stratum RPC protocol 을 설명한 것입니다. -## Table of Contents +## 목차 -## 목차 - -1. [Messages](#messages) +1. [Messages](#메세지_들) 1. [getjobtemplate](#getjobtemplate) - 1. [job](#job) - 1. [keepalive](#keepalive) - 1. [login](#login) - 1. [status](#status) - 1. [submit](#submit) -1. [Error Messages](#error-messages) -1. [Miner Behavior](#miner-behavior) -1. [Reference Implementation](#reference-implementation) - -## Messages - -In this section, we detail each message and the potential response. + 2. [job](#job) + 3. [keepalive](#keepalive) + 4. [login](#login) + 5. [status](#status) + 6. [submit](#submit) +2. [에러 메시지들](#error-messages) +3. [채굴자의 행동양식](#채굴자-행동양식) +4. [참고 구현체](#참고-구현체) + +## 메세지 들 + 이 섹션에서는 각 메시지와 그 응답에 대해서 상술합니다. -At any point, if miner the tries to do one of the following request (except login) and login is required, the miner will receive the following error message. 어느때든, 채굴자가 로그인을 제외한 다음 중 한 요청을 하고 login 이 요구된다면 채굴자는 다음과 같은 에러 메시지를 받게 됩니다. | Field | Content | | :------------ | :-------------------------------------- | -| id | ID of the request | -| id | 요청한 ID | +| id | 요청 ID | | jsonrpc | "2.0" | -| method | method sent by the miner | | method | 채굴자가 보낸 method | | error | {"code":-32500,"message":"login first"} | -Example: 예시: ```JSON @@ -48,18 +40,15 @@ Example: } } ``` - -if the request is not one of the following, the stratum server will give this error response: -만약에 요청이 다음중 하나가 아니라면, Stratum 서버가 이런 에러 메시지를 보내게 됩니다. +만약에 요청이 다음중 하나가 아니라면, Stratum 서버가 아래와 같은 에러 메시지를 보내게 됩니다. | Field | Content | | :------------ | :------------------------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | -| method | method sent by the miner | +| method | 채굴자가 보낸 method | | error | {"code":-32601,"message":"Method not found"} | -Example: 예시: ```JSON @@ -76,21 +65,18 @@ Example: ### `getjobtemplate` -A message initiated by the miner. -채굴자에 의해 초기화 되는 메시지입니다. -Miner can request a job with this message. +채굴자에 의해 시작되는 메시지입니다. 채굴자는 이 메시지로 작업을 요청 할 수 있습니다. #### Request | Field | Content | | :------------ | :----------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | | method | "getjobtemplate" | | params | null | -Example: 예시 : ``` JSON @@ -104,12 +90,11 @@ Example: #### Response -The response can be of two types: Response 는 두가지 타입이 될 수 있습니다. ##### OK response -Example: +예시 ``` JSON { @@ -127,17 +112,15 @@ Example: ##### Error response -If the node is syncing, it will send the following message: 만약 노드가 동기화 중이라면, 다음과 같은 메시지를 보낼것입니다. | Field | Content | | :------------ | :-------------------------------------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | | method | "getjobtemplate" | | error | {"code":-32701,"message":"Node is syncing - Please wait"} | -Example: 예시: ```JSON @@ -154,23 +137,20 @@ Example: ### `job` -A message initiated by the Stratum server. -Stratum 서버가 초기화 하는 메세지입니다. -Stratum server will send job automatically to connected miners. +Stratum 서버로 인해 시작되는 메세지입니다. Stratum 서버는 연결된 채굴자에게 작업을 자동적으로 보냅니다. -The miner SHOULD interrupt current job if job_id = 0, and SHOULD replace the current job with this one after the current graph is complete. 채굴자는 job_id=0 이면 현재의 작업을 중단해야 합니다. 그리고 현재의 작업을 현재 graph 가 완료되면 이 작업으로 대체해야 합니다. #### Request | Field | Content | | :------------ | :------------------------------------------------------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | | method | "job" | | params | Int `difficulty`, `height`, `job_id` and string `pre_pow` | -Example: +예시: ``` JSON { @@ -188,24 +168,22 @@ Example: #### Response -No response is required for this message. -이 메세지에는 Response 가 필요하지 않습니다. +이 메세지에는 Response 가 필요하지 않습니다. ### `keepalive` -A message initiated by the miner in order to keep the connection alive. -연결을 계속 하기 위해서 채굴자에 의해 초기화 되는 메시지입니다. +연결을 계속 하기 위해서 채굴자에 의해 초기화 되는 메시지입니다. #### Request | Field | Content | | :------------ | :--------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | | method | "keepalive" | | params | null | -Example: +예시: ``` JSON { @@ -220,13 +198,13 @@ Example: | Field | Content | | :------------ | :----------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | | method | "keepalive" | | result | "ok" | | error | null | -Example: +예시: ``` JSON { @@ -241,22 +219,18 @@ Example: ### `login` *** - -A message initiated by the miner. 채굴자에 의해 시작되는 메시지입니다. -Miner can log in on a Grin Stratum server with a login, password and agent (usually statically set by the miner program). -채굴자는 보통 마이너 프로그램으로 고정적으로 정해지는 login, password, agent 로 Grin Stratum 서버에 로그인 할 수 있습니다. +채굴자는 보통 채굴 프로그램으로 고정적으로 정해지는 login, password, agent 로 Grin Stratum 서버에 로그인 할 수 있습니다. #### Request | Field | Content | | :------------ | :----------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | | method | "login" | | params | Strings: login, pass and agent | -Example: 예시: ``` JSON @@ -276,20 +250,19 @@ Example: #### Response -The response can be of two types: -Response 는 두가지 타입 일 수 있습니다. +Response 는 두가지 타입이 될 수 있습니다. ##### OK response | Field | Content | | :------------ | :----------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | | method | "login" | | result | "ok" | | error | null | -Example: +예사: ``` JSON { @@ -303,26 +276,23 @@ Example: ##### Error response -Not yet implemented. Should return error -32500 "Login first" when login is required. 아직 구현되지 않았습니다. login이 필요할때, -32500 "Login firtst" 라는 에러를 리턴합니다. ### `status` -A message initiated by the miner. 채굴자에 의해 시작되는 메시지입니다. -This message allows a miner to get the status of its current worker and the network. 이 메시지는 채굴자에게 현재의 워커와 네트워크의 상태를 얻을 수 있게 합니다. #### Request | Field | Content | | :------------ | :--------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | | method | "status" | | params | null | -Example: +예시: ``` JSON { @@ -335,18 +305,16 @@ Example: #### Response -The response is the following: Response 는 아래와 같습니다. | Field | Content | | :------------ | :------------------------------------------------------------------------------------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | | method | "status" | -| result | String `id`. Integers `height`, `difficulty`, `accepted`, `rejected` and `stale` | +| result | String `id`. Integers `height`, `difficulty`, `accepted`, `rejected` and `stale` | | error | null | -Example: 예시: ```JSON @@ -368,24 +336,20 @@ Example: ### `submit` -A message initiated by the miner. 채굴자에 의해 시작되는 메시지입니다. -When a miner find a share, it will submit it to the node. 마이너가 쉐어를 찾았을때, 노드에게 보내집니다. #### Request -The miner submit a solution to a job to the Stratum server. -채굴자는 Stratum 서버에 작업 정답을 보냅니다. +채굴자는 Stratum 서버에 작업 솔루션을 보냅니다. | Field | Content | | :------------ | :-------------------------------------------------------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | | method | "submit" | -| params | Int `edge_bits`,`nonce`, `height`, `job_id` and array of integers `pow` | +| params | Int `edge_bits`,`nonce`, `height`, `job_id` and array of integers `pow` | -Example: 예시: ``` JSON @@ -407,22 +371,21 @@ Example: #### Response -The response can be of three types. -Response 는 세가지 타입이 될것입니다. +Response 는 세가지 타입이 될 수 있습니다. ##### OK response -The share is accepted by the Stratum but is not a valid cuck(at)oo solution at the network target difficulty. +이 타입은 Stratum 에 받아들여지지만 네트워크 타켓 난이도에서는 유효한 cuck(at)oo 솔루션이 아닙니다. | Field | Content | | :------------ | :----------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | | method | "submit" | | result | "ok" | | error | null | -Example: +예시: ``` JSON { @@ -436,17 +399,17 @@ Example: ##### Blockfound response -The share is accepted by the Stratum and is a valid cuck(at)oo solution at the network target difficulty. +이 타입은 Stratum 에 받아들여지고 네트워크 타켓 난이도에서는 유효한 cuck(at)oo 솔루션 입니다. | Field | Content | | :------------ | :----------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | | method | "submit" | | result | "block - " + hash of the block | | error | null | -Example: +예시: ``` JSON { @@ -460,18 +423,18 @@ Example: ##### Error response -The error response can be of two types: stale and rejected. +에러 response는 stale과 rejected 라는 두가지 타입이 될 수 있습니다. ##### Stale share error response -The share is a valid solution to a previous job not the current one. +이 타입은 유효한 솔루션이나 지난 작업이 현재의 것이 아닙니다. | Field | Content | | :------------ | :-------------------------------------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | -| method | "submit" | -| error | {"code":-32503,"message":"Solution submitted too late"} | +| method | "submit" | +| error | {"code":-32503,"message":"Solution submitted too late"} | Example: @@ -489,18 +452,18 @@ Example: ##### Rejected share error responses -Two possibilities: the solution cannot be validated or the solution is of too low difficulty. +솔루션이 유효하지 않거나 너무 낮은 난이도일 수 있는 두 가지 가능성이 있습니다. ###### Failed to validate solution error -The submitted solution cannot be validated. +재출된 솔루션이 유효하지 않을 수 았습니다. | Field | Content | | :------------ | :-------------------------------------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | -| method | "submit" | -| error | {"code":-32502,"message":"Failed to validate solution"} | +| method | "submit" | +| error | {"code":-32502,"message":"Failed to validate solution"} | Example: @@ -518,11 +481,11 @@ Example: ###### Share rejected due to low difficulty error -The submitted solution is of too low difficulty. +제출된 솔루션의 난이도가 너무 낮습니다. | Field | Content | | :------------ | :--------------------------------------------------------------- | -| id | ID of the request | +| id | 요청 ID | | jsonrpc | "2.0" | | method | "submit" | | error | {"code":-32501,"message":"Share rejected due to low difficulty"} | @@ -543,7 +506,7 @@ Example: ## Error Messages -Grin Stratum protocol implementation contains the following error message: +Grin Stratum protocole 구현체는 다음과 같은 에러 메시지를 포함하고 있습니다. | Error code | Error Message | | :---------- | :------------------------------------- | @@ -557,16 +520,17 @@ Grin Stratum protocol implementation contains the following error message: ## Miner behavior -Miners SHOULD, MAY or MUST respect the following rules: +채굴자들은 반드시 다음과 같은 규칙들을 존중해야 할 것입니다. -- Miners SHOULD randomize the job nonce before starting -- Miners MUST continue mining the same job until the server sends a new one, though a miner MAY request a new job at any time -- Miners MUST NOT send an rpc response to a job request from the server -- Miners MAY set the RPC "id" and expect responses to have that same id -- Miners MAY send a keepalive message -- Miners MAY send a login request (to identify which miner finds shares / solutions in the logs), the login request MUST have all 3 params. +- 마이너들은 작업을 시작하기 전에 작업 nounce를 랜덤화 시켜야 합니다. +- 채굴자들은 반드시 서버가 샤로운 작업을 보낼때끼지 같은 작업을 채굴해야 하지만 언제든 새로운 작업을 요청 할 수 있습니다. +- 채굴자들은 서버로 부터 온 작업 요청을 rpc response로 보내면 안됩니다. +- 채굴자들은 RPC "id"를 정할 수 있고 같은 id로 response를 받기를 요구 할 수 있습니다. +- 마이너들은 keepalive 메시지를 보낼수 있습니다. +- 채굴자들은 로그인 request를 보낼 수 있습니다.(어떤 채굴자가 쉐어를 찾았는지 확인하기 위해서 / Log안에서 솔루션을 확인하기 위해 ) 로그인 request는 3가지 파라미터를 가지고 있어야만 합니다. - Miners MUST return the supplied job_id with submit messages. +- 채굴자들은 주어진 job_id를 제출하는 메시지에 리턴해야 합니다. ## Reference Implementation -The current reference implementation is available at [mimblewimble/grin-miner](https://github.com/mimblewimble/grin-miner/blob/master/src/bin/client.rs). +현재 구현체는 [mimblewimble/grin-miner](https://github.com/mimblewimble/grin-miner/blob/master/src/bin/client.rs) 에서 참고하세요. From 0ecbb416c2aa24519168b9208d3e3c8b6cf7a40c Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Sun, 17 Feb 2019 22:11:36 +0900 Subject: [PATCH 16/25] [WIP] --- doc/build_KR.md | 8 +++++--- doc/state_KR.md | 46 +++++++++++++--------------------------------- 2 files changed, 18 insertions(+), 36 deletions(-) diff --git a/doc/build_KR.md b/doc/build_KR.md index 8b9f4755b2..0e551d711d 100644 --- a/doc/build_KR.md +++ b/doc/build_KR.md @@ -108,7 +108,7 @@ grin client help docker build -t grin -f etc/Dockerfile . ``` -floonet을 사용하려면 `etc/Dockerfile.floonet` 을 사용하세요. +floonet을 사용하려면 `etc/Dockerfile.floonet` 을 사용하세요. You can bind-mount your grin cache to run inside the container. ```sh @@ -122,14 +122,16 @@ Using a named volume copies default configurations upon volume creation Rust (cargo) can build grin for many platforms, so in theory running `grin` as a validating node on your low powered device might be possible. +Rust(Cargo)는 여러 플랫폼에서 Grin을 빌드 할 수 있습니다. 그래서 이론적으로 낮은 성능의 디바이스 에서도 인증받은 노드로 grin을 작동 시킬 수 있습니다. To cross-compile `grin` on a x86 Linux platform and produce ARM binaries, say, for a Raspberry Pi. + ## Grin 사용하기 The wiki page [Wallet User Guide](https://github.com/mimblewimble/docs/wiki/Wallet-User-Guide) -and linked pages have more information on what features we have, -troubleshooting, etc. +and linked pages have more information on what features we have, troubleshooting, etc. +[Wallet User Guide](https://github.com/mimblewimble/docs/wiki/Wallet-User-Guide) 위키페이지와 링크된 페이지들은 어떤 Feature 를 가지고 있는지 , 트러블 슈팅 등등에 대한 좀 더 많은 정보를 가지고 있습니다. ## Grin 채굴하기 diff --git a/doc/state_KR.md b/doc/state_KR.md index c6d7b82d9e..2c6fc7fda6 100644 --- a/doc/state_KR.md +++ b/doc/state_KR.md @@ -9,44 +9,26 @@ Grin chain의 모든 상태는 다음 데이터와 같이 이루어져 있습니 1. unspent output(UTXO) 세트 2. 각 출력값에 대한 range proof 3. 모든 트랜잭션 커널(kernel)들 -4. A MMR for each of the above (with the exception that the output MMR includes - hashes for *all* outputs, not only the unspent ones). -4. 상기에 언급했던 각각의 것들에 대한 MMR (예외적으로 출력값 MMR은 사용되지 않은 것 뿐만 아니라 *모든* 출력값의 해쉬를 포함합니다.) -In addition, all headers in the chain are required to anchor the above state -with a valid proof of work (the state corresponds to the most worked chain). -더해서 chain 안의 모든 헤더들은 유효한 PoW 와 상기 상태에 대한 anchor가 요구됩니다. ( 상태는 가장 많이 일한 체인와 일치합니다.) -We note that once each range proof is validated and the sum of all kernels -commitment is computed, range proofs and kernels are not strictly necessary for -a node to function anymore. -한번 각각의 range proof 가 인증되고 모든 kernel의 실행 합계가 계산되었다면 node 의 작동에 굳이 꼭 필요하진 않습니다. +4. 상기에 언급했던 각각의 MMR (예외적으로 출력값 MMR은 사용되지 않은 것 뿐만 아니라 *모든* 출력값의 해쉬를 포함합니다.) 더해서, 유효한 Proof of work 와 함께 chain 안의 모든 헤더들은 상기 상태에 대해 고정되어야 합니다. ( 상태는 가장 많이 일한 체인와 일치합니다.) +한번 각각의 range proof 가 인증되고 모든 kernel의 실행 합계가 계산되었다면 node 의 작동에 더이상 엄격하게 필요하진 않습니다. ### 인증하기 -With a full Grin state, we can validate the following: 완전한 Grin의 상태를 사용해서 우리는 다음과 같은 것들을 인증 할 수 있습니다. -1. The kernel signature is valid against its commitment (public key). This - proves the kernel is valid. - Kernel 의 signature 가 Kernel의 실행에 대해 유효하다면 ( 공개키). 이것은 Kernel이 유요하다는것을 증명합니다. -2. The sum of all kernel commitments equals the sum of all UTXO commitments - minus the total supply. This proves that kernels and output commitments are all valid and no coins have unexpectedly been created. - 모든 커밋 실행의 합이 모든 UTXO 실행의 합에서 총 공급량을 뺸 값이 같다면 이것은 Kernal과 출력값의 실행들이 유효하고 코인이 새로이 만들어지지 않았다는 것을 증명합니다. -3. All UTXOs, range proofs and kernels hashes are present in their respective - MMR and those MMRs hash to a valid root. - 모든 UTXO, range prook 와 Kernel 해쉬들은 각각의 MMR이 있고 그 MMR 들은 유효한 root 를 해쉬합니다. -4. A known block header with the most work at a given point in time includes - the roots of the 3 MMRs. - 특정 시점에 가장 많이 일했다고 알려진 Block header 에는 3개의 MMR에 대한 root 가 포함됩니다. - This validates the MMRs and proves that the whole state has been produced by the most worked chain. - 이것은 MMR과 인증하고 전체 상태가 가장 많이 일한 chain ( 가장 긴 체인)에서 만들어졌다는 것을 증명합니다. +1. Kernel 의 signature 가 Kernel의 실행에 대해 유효하다면 ( 공개키). 이것은 Kernel이 유요하다는것을 증명합니다. +2. 모든 커밋 실행의 합이 모든 UTXO 실행의 합에서 총 공급량을 뺸 값이 같다면 이것은 Kernal과 출력값의 실행들이 유효하고 코인이 새로이 만들어지지 않았다는 것을 증명합니다. +3. 모든 UTXO, range prook 와 Kernel 해쉬들은 각각의 MMR이 있고 그 MMR 들은 유효한 root 를 해쉬합니다. +4. 특정 시점에 가장 많이 일했다고 알려진 Block header 에는 3개의 MMR에 대한 root 가 포함됩니다. 이것은 전체 상태가 가장 많이 일한 chain ( 가장 긴 체인)에서 MMR과 증명들이 만들어졌다는 것을 입증합니다. ### MMR 과 Pruning The data used to produce the hashes for leaf nodes in each MMR (in addition to their position is the following: - +데이터는 리프 노드안의 각 MMR의 Hash를 만들어 냈었지만 * The output MMR hashes the feature field and the commitments of all outputs since genesis. +* 출력값의 MMR 해 * The range proof MMR hashes the whole range proof data. * The kernel MMR hashes all fields of the kernel: feature, fee, lock height, excess commitment and excess signature. @@ -54,6 +36,7 @@ their position is the following: Note that all outputs, range proofs and kernels are added in their respective MMRs in the order they occur in each block (recall that block data is required to be sorted). +모든 출력값, Range proof, 그리고 kernel은 각각의 MMR에 더해지고 As outputs get spent, both their commitment and range proof data can be removed. In addition, the corresponding output and range proof MMRs can be @@ -61,13 +44,10 @@ pruned. ## 상태 스토리지 -Data storage for outputs, range proofs and kernels in Grin is simple: Grin 에 있는 출력값에 대한 데이터 스토리지, Range proof 와 kernel은 간단합니다. -a plain append-only file that's memory-mapped for data access. As outputs get spent,a remove log maintains which positions can be removed. - -Those positions nicely match MMR node positions as they're all inserted in the same order. - -When the remove log gets large, corresponding files can be occasionally compacted by rewriting them without the removed pieces (also append-only) and the remove log can be emptied. +그 형태는 데이터 엑세스를 위한 메모리 매핑 된 append only 파일입니다. +출력값이 소비되는것에 따라서 제거 로그는 지울수 있는 위치를 유지힙니다. +이런 포지션은 MMR과 노드 포지션이 같은 순서로 입력되었으므로 잘 일치합니다. +제거 로그가 커지면 (Append only 파일도 )때때로 해당 파일을 지워진 부분 없이 다시 작성해서 압축하고 제거 로그를 비울 수 있습니다. -As for MMRs, we need to add a little more complexity. MMR 에 대해서는 약간의 복잡함을 더할 필요가 있습니다. From be3672da1fc6bb246e29befb52f9dc1c906b51a1 Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Tue, 19 Feb 2019 21:28:46 +0900 Subject: [PATCH 17/25] finish translate stratum_KR.md & table_of_content_KR.md --- doc/build_KR.md | 32 ++-- doc/intro.KR.md | 417 +++++++++++----------------------------------- doc/stratum_KR.md | 4 +- 3 files changed, 110 insertions(+), 343 deletions(-) diff --git a/doc/build_KR.md b/doc/build_KR.md index 0e551d711d..14cb209358 100644 --- a/doc/build_KR.md +++ b/doc/build_KR.md @@ -4,10 +4,9 @@ ## 지원하는 플랫폼들에 대해서 -Longer term, most platforms will likely be supported to some extent. 장기적으로는 대부분의 플랫폼에서 어느정도의 규모로 지원하게 될 것입니다. -Grin's programming language `rust` has build targets for most platforms. Grin 프로그래밍 언어는 `rust`로 대부분의 플랫폼들에서 빌드 할 수 있습니다. + 지금까지 작동하는 플랫폼은 무엇인가요? * Linux x86_64 그리고 macOS [grin + mining + development] * Windows 10은 아직 지원하지 않습니다 [grin kind-of builds, mining은 아직 지원하지 않음 . 도움이 필요해요!] @@ -49,7 +48,6 @@ cd grin cargo build --release ``` -Grin can also be built in debug mode (without the `--release` flag, but using the `--debug` or the `--verbose` flag) but this will render fast sync prohibitively slow due to the large overhead of cryptographic operations. Grin은 Debug 모드로 Build 할 수 있습니다. (`--release` 플래그가 아닌, but `--debug` 또는 `--verbose` 플래그를 사용하세요.) 그러나 이 명령어는 암호 오퍼레이션으로 인해 큰 오버헤드를 가지므로 fast sync 가 어려울 정도로 느려집니다. ## Build 에러들 @@ -64,17 +62,13 @@ A successful build gets you: 모든 데이터, 설정, 로그 파일들은 기본적으로 (지정되지 않는다면) `~/.grin` 에 만들어지고 사용됩니다. (user home 디렉토리 안에 있습니다.) `~/.grin/main/grin-server.toml` 을 수정해서 모든 설정값들을 바꿀 수 있습니다. -Grin은 현재 디렉토리 내에서도 데이터 파일들을 만들 수 있습니다. -밑에 있는 Bash 명령어를 작동하세요. +Grin은 현재 디렉토리 내에서도 데이터 파일들을 만들 수 있습니다. 밑에 있는 Bash 명령어를 작동하세요. ```sh grin server config ``` -Which will generate a `grin-server.toml` file in the current directory, pre-configured to use -the current directory for all of its data. -TODO 위에있는 영어문장 번역기에 돌려볼것. -현재 디렉토리에서 모함한 모든 데이터에 대해 미리 설정된 `grin-server.toml` 파일 내의 값들이 사용됩니다. +현재 디렉토리에서 모함한 모든 데이터에 대해 미리 설정된 `grin-server.toml` 파일 내의 값들이 사용될겁니다. Testing 중에서는 Grin 바이너리를 이렇게 path 에 삽입 할 수도 있습니다. @@ -87,12 +81,11 @@ export PATH=`pwd`/target/release:$PATH ## 설정하기 Grin attempts to run with sensible defaults, and can be further configured via -the `grin-server.toml` file. This file is generated by grin on its first run, and -contains documentation on each available option. +the `grin-server.toml` file. This file is generated by grin on its first run, and contains documentation on each available option. +Grin은 While it's recommended that you perform all grin server configuration via -`grin-server.toml`, it's also possible to supply command line switches to grin that -override any settings in the file. +`grin-server.toml`, it's also possible to supply command line switches to grin that override any settings in the file. For help on grin commands and their switches, try: @@ -116,22 +109,17 @@ 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 ## 크로스 플랫폼 빌드 -Rust (cargo) can build grin for many platforms, so in theory running `grin` -as a validating node on your low powered device might be possible. Rust(Cargo)는 여러 플랫폼에서 Grin을 빌드 할 수 있습니다. 그래서 이론적으로 낮은 성능의 디바이스 에서도 인증받은 노드로 grin을 작동 시킬 수 있습니다. -To cross-compile `grin` on a x86 Linux platform and produce ARM binaries, -say, for a Raspberry Pi. - +`grin` 크로스 컴파일을 하기 위해서 x96 리눅스플랫폼 위에서 ARM 바이너릐를 만듭니다. 예를 라즈베리 파이 가 있습니다. ## Grin 사용하기 -The wiki page [Wallet User Guide](https://github.com/mimblewimble/docs/wiki/Wallet-User-Guide) -and linked pages have more information on what features we have, troubleshooting, etc. -[Wallet User Guide](https://github.com/mimblewimble/docs/wiki/Wallet-User-Guide) 위키페이지와 링크된 페이지들은 어떤 Feature 를 가지고 있는지 , 트러블 슈팅 등등에 대한 좀 더 많은 정보를 가지고 있습니다. +[지갑 유저 가이드](https://github.com/mimblewimble/docs/wiki/Wallet-User-Guide) 위키페이지와 링크된 페이지들은 어떤 Feature 를 가지고 있는지 , 트러블 슈팅 등등에 대한 좀 더 많은 정보를 가지고 있습니다. ## Grin 채굴하기 @@ -139,5 +127,7 @@ Please note that all mining functions for Grin have moved into a separate, stand [grin-miner](https://github.com/mimblewimble/grin-miner). Once your Grin code node is up and running, you can start mining by building and running grin-miner against your running Grin node. + + For grin-miner to be able to communicate with your grin node, make sure that you have `enable_stratum_server = true` in your `grin-server.toml` configuration file and you have a wallet listener running (`grin wallet listen`). diff --git a/doc/intro.KR.md b/doc/intro.KR.md index 361bb59b4d..ed7b277db3 100644 --- a/doc/intro.KR.md +++ b/doc/intro.KR.md @@ -1,470 +1,255 @@ -# Introduction to MimbleWimble and Grin +# MimbleWimble 과 Grin 에 대한 소개 -*Read this in other languages: [English](intro.md), [简体中文](intro.zh-cn.md), [Español](intro_ES.md), [Русский](intro.ru.md), [日本語　](intro.jp.md).* - -MimbleWimble is a blockchain format and protocol that provides -extremely good scalability, privacy and fungibility by relying on strong -cryptographic primitives. It addresses gaps existing in almost all current -blockchain implementations. +*다른 언어로 Intro를 읽으시려면: [English](intro.md), [简体中文](intro.zh-cn.md), [Español](intro_ES.md), [Русский](intro.ru.md), [日本語](intro.jp.md).* MimbleWimlbe은 블록체인 포맷이면서 프로토콜 입니다. -MimbleWimble은 암호학적 기반에 의해서 극대화된 좋은 확장성, 프라이버시, 그리고 대체가능성을 제공합니다. -이러한 특성은 지금 현존하는 모든 블록체인 구현체에 존재하는 문제점들을 처리합니다. - -Grin is an open source software project that implements a MimbleWimble -blockchain and fills the gaps required for a full blockchain and -cryptocurrency deployment. - -Grin 은 Mimble Wimble 블록체인을 구현한 오픈소스 프로젝트 입니다. -또한 완전한 블록체인와 크립토 커런시의 배포에 필요한 갭을 채워줍니다. +MimbleWimble은 암호학적 기반에 의해서 극대화된 좋은 확장성, 프라이버시, 그리고 대체가능성을 제공합니다. 이러한 특성은 지금 현존하는 모든 블록체인 구현체에 존재하는 문제점들을 처리합니다. -The main goal and characteristics of the Grin project are: +Grin 은 Mimble Wimble 블록체인을 구현한 오픈소스 프로젝트 입니다. 또한 완전한 블록체인와 크립토 커런시의 배포에 필요한 갭을 채워줍니다. Grin 프로젝트의 주요 목적과 특성들은 아래 설명을 참고하십시오. -* Privacy by default. This enables complete fungibility without precluding - the ability to selectively disclose information as needed. * 프라이버시가 기본으로 제공됩니다. 이 기능은 필요에 따라서 선택적으로 정보를 공개 할 수 없도록 해서 완전한 대체가능성을 할 수 있게 합니다. -* Scales mostly with the number of users and minimally with the number of - transactions (<100 byte `kernel`), resulting in a large space saving compared - to other blockchains. * 주로 유저의 규모와 최소한의 트랜잭션 수의 규모로 (100byte 미만의 kernel(transaction)) 다른 블록체인들과 비교하면 많은 저장공간을 절약할 수 있습니다. -* Strong and proven cryptography. MimbleWimble only relies on Elliptic Curve - Cryptography which has been tried and tested for decades. * Mimble Wimble 은 수십년 동안 테스트하고 사용되었던 강력한 암호기술인 ECC만 사용합니다. -* Design simplicity that makes it easy to audit and maintain over time. * 간단한 디자인은 감사와 유지보수를 시간이 지나도 수월하게 만듭니다. -* Community driven, encouraging mining decentralization. * 커뮤니티가 주도하며, 채굴 탈중앙화가 권장됩니다. -## Tongue Tying for Everyone ## 모두의 혀를 묶자. -This document is targeted at readers with a good -understanding of blockchains and basic cryptography. -이 문서는 블록체인에 대해 어느정도 이해가 있고 암호학에 대한 기본적인 이해가 있는 독자들을 대상으로 합니다. - -With that in mind, we attempt to explain the technical buildup of MimbleWimble and how it's applied in Grin. -이것을 염두에 두고 우리는 MimbleWimble의 기술적인 발전과 어떻게 Grin에 적용되었는지 관해 설명할것입니다. - -We hope this document is understandable to most technically-minded readers. Our objective is -to encourage you to get interested in Grin and contribute in any way possible. -저희는 이 문서가 대부분의 기술적인 성격을 가진 독자들을 이해시킬 수 있길 바랍니다. -우리의 목적은 독자가 Grin에 대해 흥미를 느끼게 하고 어떤 방식으로든 Grin에 기여할 수 있게 이끄는 것입니다. - -To achieve this objective, we will introduce the main concepts required for a good understanding of Grin as a MimbleWimble implementation. +이 문서는 블록체인에 대해 어느정도 이해가 있고 암호학에 대한 기본적인 이해가 있는 독자들을 대상으로 합니다. 이것을 염두에 두고 우리는 MimbleWimble의 기술적인 발전과 어떻게 Grin에 적용되었는지 관해 설명 할 것입니다. +저희는 이 문서가 대부분의 기술적인 성격을 가진 독자들을 이해시킬 수 있길 바랍니다. 우리의 목적은 독자가 Grin에 대해 흥미를 느끼게 하고 어떤 방식으로든 Grin에 기여할 수 있게 이끄는 것입니다. 이러한 목적을 이루기 위해, 우리는 MimbleWimble 의 구현체인 Grin을 이해하는데 필요한 주요 컨셉들에 대해서 소개할것입니다. -We will start with a brief description of some relevant properties of Elliptic Curve Cryptography (ECC) to lay the foundation on which Grin is based and then describe all the key elements of a MimbleWimble blockchain's transactions and blocks. -우선 Grin이 어디에서 부터 기초로 하고 있는지에 대해 이해하기 위해서 타원 곡선 암호 (ECC)의 몇몇 속성들에 대한 간단한 설명으로 시작하겠습니다. 그 다음, MimbleWimble 블록체인의 트랜잭션과 블록에 한 모든 요소들을 설명하겠습니다. + 우선 Grin이 어디에서 부터 기초로 하고 있는지에 대해 이해하기 위해서 타원 곡선 암호 (ECC)의 몇몇 속성들에 대한 간단한 설명으로 시작하겠습니다. 그 다음, MimbleWimble 블록체인의 트랜잭션과 블록에 한 모든 요소들을 설명하겠습니다. -### Tiny Bits of Elliptic Curves ### 타원곡선에 대한 조그마한 조각들 +ECC의 너무 복잡한 사항을 캐지 않고 어떻게 mimble wimble 이 어떻게 작동하는지에 대해 이해하는데 필요한 요소들만 리뷰할 것입니다. 이런 가정들을 좀 더 알고싶은 독자들은 [이 링크](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/)를 참고하세요. -We start with a brief primer on Elliptic Curve Cryptography, reviewing just the -properties necessary to understand how MimbleWimble works and without -delving too much into the intricacies of ECC. - -ECC의 너무 복잡한 사항을 캐지 않고 어떻게 mimble wimble 이 어떻게 작동하는지에 대해 이해하는데 필요한 요소들만 리뷰할 것입니다. - -For readers who would want to dive deeper into those assumptions, there are other opportunities to [learn more](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/). -이런 가정들을 좀 더 알고싶은 독자들은 [이 링크](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/)를 참고하세요. - -An Elliptic Curve for the purpose of cryptography is simply a large set of points that -we will call _C_. These points can be added, subtracted, or multiplied by integers (also called scalars). 암호학에서의 타원 곡선이란 우리가 _C_ 라고 부르는 단순히 아주 큰 좌표의 집합입니다. -이 좌표들은 정수들로 (인티저, 또는 스칼라 ) 더하고 빼고 곱할수 있습니다. +이 좌표들은 정수들로 (인티저, 또는 스칼라 ) 더하고 빼고 곱할 수 있습니다. -Given an integer _k_ and using the scalar multiplication operation we can compute `k*H`, which is also a point on curve _C_. 주어진 정수 _K_ 에 스칼라 곱셈을 한다면 우리는 곡선 _c_ 위에 있는 좌표 K*H를 계산 할 수 있습니다. - -Given another integer _j_ we can also calculate `(k+j)*H`, which equals `k*H + j*H`. 또 달리 주어진 정수 _j_ 에 우리는`k*H + j*H` 와 같은 `(k+j)*H`를 계산 할 수 있습니다. -The addition and scalar multiplication operations on an elliptic curve maintain the commutative and associative properties of addition and multiplication: -타원곡선 위에서의 덧셈과 정수 곱셈은 제시덴 수의 순서에 관계없이 결과가 동일하다는 성질과 덧셈과 곱셈의 계산 순서와 관계없이 동일한 결과가 나온다는 성질을 가지고 있습니다. +타원곡선 위에서의 덧셈과 정수 곱셈은 제시된 수의 순서에 관계없이 결과가 동일하다는 성질과 덧셈과 곱셈의 계산 순서와 관계없이 동일한 결과가 나온다는 성질을 가지고 있습니다. (k+j)*H = k*H + j*H -In ECC, if we pick a very large number _k_ as a private key, `k*H` is -considered the corresponding public key. -ECC 안에서 우리가 매우 큰 숫자인 _k_ 를 프라이빗 키로 가정할 때 `k*H` 는 해당하는 퍼블릭 키로 해당되어 집니다. - -Even if one knows the value of the public key `k*H`, deducing _k_ is close to impossible (or said differently, while multiplication is trivial, "division" by curve points is -extremely difficult). -누군가 공개키인 `k*H`의 값을 알더라도 _k_ 를 추론해 내는것은 불가능에 가깝습니다. ( 달리 얘기하자면, 곱셉은 쉬우나 곡선 좌표에 의한 "나눗셈"은 정말 어렵습니다. ) - -The previous formula `(k+j)*H = k*H + j*H`, with _k_ and _j_ both private -keys, demonstrates that a public key obtained from the addition of two private -keys (`(k+j)*H`) is identical to the addition of the public keys for each of those -two private keys (`k*H + j*H`). -_k_ 와 _j_ 둘다 비밀키인 이전 공식 `(k+j)*H = k*H + j*H` 는 두개의 비밀키를 더해서 얻은 한 개의 공개키 (`(k+j)*H`) 와 각각 두개의 비밀키에 공개키를 더한것과 같습니다. -In the Bitcoin blockchain, Hierarchical Deterministic wallets heavily rely on this principle. -Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. -MimbleWimble and the Grin implementation do as well. -MimbleWimble 과 Grin의 구현또한 마찬가지 입니다. - -### Transacting with MimbleWimble -### MimbleWimble 함께 거래하기 +ECC 안에서 우리가 매우 큰 숫자인 _k_ 를 프라이빗 키로 가정할 때 `k*H` 는 해당하는 퍼블릭 키로 해당되어 집니다. 누군가 공개키인 `k*H`의 값을 알더라도 _k_ 를 추론해 내는것은 불가능에 가깝습니다. ( 달리 얘기하자면, 곱셉은 쉬우나 곡선 좌표에 의한 "나눗셈"은 정말 어렵습니다. ) + +_k_ 와 _j_ 둘다 비밀키인 이전 공식 `(k+j)*H = k*H + j*H` 는 두개의 비밀키를 더해서 얻은 한 개의 공개키 (`(k+j)*H`) 와 각각 두개의 비밀키에 공개키를 더한것과 같습니다. Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. MimbleWimble 과 Grin의 구현또한 마찬가지 입니다. -The structure of transactions demonstrates a crucial tenet of MimbleWimble: +### MimbleWimble 함께 거래하기 트랜잭션의 구조는 MimbleWimble의 강력한 프라이버시와 비밀이 유지된다라고 하는 중요한 규칙을 나타냅니다. -strong privacy and confidentiality guarantees. -The validation of MimbleWimble transactions relies on two basic properties: MimbleWimble 트랜잭션의 확인은 두가지 기본적인 성격을 전제로 합니다. -* **Verification of zero sums.** The sum of outputs minus inputs always equals zero, - proving that the transaction did not create new funds, _without revealing the actual amounts_. -* **제로섬의 검증** 결과값에서 입력값을 뺸 합은 항상 0과 같습니다. 이것은 실제 전송되는 코인의 양을 드러내지 않고도 트랜잭션ㅇ이 새로운 코인을 만들지 않았다는 것을 증명합니다. -* **Possession of private keys.** Like with most other cryptocurrencies, ownership of - transaction outputs is guaranteed by the possession of ECC private keys. However, - the proof that an entity owns those private keys is not achieved by directly signing - the transaction. -* **비밀키의 소유** 다른 많은 크립토커런시들 처럼 , 트랜잭션의 소유권은 ECC 비밀키에 의해 보장됩니다. 그러나 어떤 실체가 이런 비밀키들을 소유하고 있다고 증명하는것이 직접적으로 트랜잭션에 사인한다고해서 얻어지는 것은 아닙니다. - -The next sections on balance, ownership, change and proofs details how those two -fundamental properties are achieved. + +* **제로섬의 검증:** 결과값에서 입력값을 뺸 합은 항상 0과 같습니다. 이것은 실제 전송되는 코인의 양을 드러내지 않고도 트랜잭션ㅇ이 새로운 코인을 만들지 않았다는 것을 증명합니다. +* **비밀키의 소유:** 다른 많은 크립토 커런시 들처럼 , 트랜잭션의 소유권은 ECC 비밀키에 의해 보장됩니다. 그러나 어떤 실체가 이런 비밀키들을 소유하고 있다고 증명하는것이 직접적으로 트랜잭션에 사인한다고해서 얻어지는 것은 아닙니다. + 다음 섹션들에서는 잔고, 소유권, 거스름돈과 증명들의 상세들이 어떻게 저 두가지 기본적인 성질에 의해서 얻어지는지 알아보겠습니다. -#### Balance #### 잔고 - -Building upon the properties of ECC we described above, one can obscure the values -in a transaction. 위에서 언급한 ECC의 특성들을 기반으로 해서 트랜잭션안의 가치들을 보기 어렵게 할 수 있습니다. +만약 _v_ 가 트랜잭션 입력값이거나 출력값이고 _H_ 가 타원곡선이라면 , 단순히 _v_ 대신 `v*H`를 끼워 넣을 수 있습니다. -If _v_ is the value of a transaction input or output and _H_ an elliptic curve, we can simply -embed `v*H` instead of _v_ in a transaction. -만약 _v_ 가 트랜잭션 입력값이거나 출력값이고 _H_가 타원곡선이라면 , 단순히 _v_ 대신 `v*H`를 끼워넣을 수 있습니다. - -This works because using the ECC operations, we can still validate that the sum of the outputs of a transaction equals the sum of inputs: 이것은 ECC를 사용하기 때문에 작동하는 것입니다. 우리는 출력값의 합이 입력값의 합과 같다는 것을 여전히 확인할 수 있습니다. v1 + v2 = v3 => v1*H + v2*H = v3*H -Verifying this property on every transaction allows the protocol to verify that a -transaction doesn't create money out of thin air, without knowing what the actual -values are. 이 특성을 모든 트랜잭션에 확인하는것은 프로토콜이 트랜잭션은 돈을 난데없이 만들지 않는다는 것을 실제 돈이 얼마나 있는지 알지 않아도 검증할 수 있게 합니다. -However, there are a finite number of usable values and one could try every single -one of them to guess the value of your transaction. -그러나 사용가능한 한정된 숫자가 있고 그 숫자 중 하나를 사용해서 당신의 트랜잭션이 얼마만큼의 코인을 가졌는지 추측해 할 수 있습니다. -In addition, knowing v1 (from a previous transaction for example) and the resulting `v1*H` reveals all outputs with value v1 across the blockchain. -더해서 , v1을 알고 ( 예시로 사용된 이전의 트랜잭션에서 온 값 ) 그에따른 `v1*H`의 결과를 알면 블록체인 전체에 걸쳐서 v1 값이 있는 모든 출력값들이 드러나게 됩니다. +그러나 사용가능한 한정된 숫자가 있고 그 숫자 중 하나를 사용해서 당신의 트랜잭션이 얼마만큼의 코인을 가졌는지 추측 할 수 있습니다. 더해서, v1을 알고 ( 예시로 사용된 이전의 트랜잭션에서 온 값 ) 그에따른 `v1*H`의 결과를 알면 블록체인 전체에 걸쳐서 v1 값이 있는 모든 출력값들이 드러나게 됩니다. -For these reasons, we introduce a second elliptic curve _G_ (practically _G_ is just another generator point on the same curve group as _H_) and a private key _r_ used as a *blinding factor*. -이러한 이유때문에 우리는 두번째 타원곡선인 _G_를 제시합니다. ( 실제로 _G_ 는 _H_ 의 그룹과 같은 곡선에 있는 단지 다른 좌표를 생성해 냅니다.) 그리고 비밀키 _r_은 *blinding factor* 로 사용됩니다. +이러한 이유로 두번째 타원곡선인 _G_ 를 제시합니다. ( 실제로 _G_ 는 _H_ 의 그룹과 같은 곡선에 있으며 단지 다른 좌표를 생성해 냅니다.) 그리고 비밀키 _r_ 은 *blinding factor* 로 사용됩니다. -An input or output value in a transaction can then be expressed as: 그렇다면 트랜잭션 안의 입력값과 출력값은 다음과 같이 표현됩니다. + r*G + v*H -Where: + 여기서 -* _r_ is a private key used as a blinding factor, _G_ is an elliptic curve and their product `r*G` is the public key for _r_ on _G_. * _r_ 은 비밀키이고 blinding factor 로 사용됩니다. _G_ 는 타원 곡선 이고 `r*G`는 _G_ 안에 있는 _r_ 의 공개키 입니다. -* _v_ is the value of an input or output and _H_ is another elliptic curve. -* _v_ 는 출력값이거나 입력값이고 _H_ 는 다른 타원곡선입니다. -Neither _v_ nor _r_ can be deduced, leveraging the fundamental properties of Elliptic -Curve Cryptography. `r*G + v*H` is called a _Pedersen Commitment_. -타원곡선의 근본적인 특성을 이용했기 때문에 _v_ 와 _r_ 은 추측될 수 없습니다. `r*G + v*H`를 _Pedersen Commitment_ 라고 부릅니다. -As a an example, let's assume we want to build a transaction with two inputs and one -output. We have (ignoring fees): +* _v_ 는 출력값이거나 입력값이고 _H_ 는 다른 타원곡선입니다.타원곡선의 근본적인 특성을 이용했기 때문에 _v_ 와 _r_ 은 추측될 수 없습니다. `r*G + v*H`를 _Pedersen Commitment_ 라고 부릅니다. + 예를 들어 , ( 전송료는 무시하고) 두개의 입력값과 한개의 출력값으로 트랜잭션을 만들기 원한다고 가정해봅시다. -* vi1 and vi2 as input values. + * vi1 과 v2 는 출력값 -* vo3 as output value. * vo3는 출력값 이라면 -Such that: + +그렇다면 vi1 + vi2 = vo3 -Generating a private key as a blinding factor for each input value and replacing each value -with their respective Pedersen Commitments in the previous equation, we obtain: +입니다. + 각각의 입력값에 대해서 blining factor 로 비밀키를 만들고 각각의 값을 각각의 이전의 공식에 있던 Pederson Commitment로 교체한다고 하면 다음과 같습니다. (ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vo3*H) -Which as a consequence requires that: 결과로 다음과 같습니다. + ri1 + ri2 = ro3 -This is the first pillar of MimbleWimble: the arithmetic required to validate a -transaction can be done without knowing any of the values. 이것이 MimbleWimble의 첫번째 특징입니다. 트랜잭션을 검증하는 산술적인 연산은 아무런 값을 알지 못해도 가능합니다. -As a final note, this idea is actually derived from Greg Maxwell's -[Confidential Transactions](https://elementsproject.org/features/confidential-transactions/investigation), -which is itself derived from an Adam Back proposal for homomorphic values applied -to Bitcoin. -마지막으로 이 아이디어는 Greg Maxwell 의 [Confidential Transactions](https://elementsproject.org/features/confidential-transactions/investigation) 에서 유래했습니다. Confidential transaction은 Adam back의 비트코인에 동형암호를 적용하자는 제안에서 비롯되었습니다. - -#### Ownership +이 아이디어는 Greg Maxwell 의 [Confidential Transactions](https://elementsproject.org/features/confidential-transactions/investigation) 에서 유래했습니다. Confidential transaction은 Adam back의 비트코인에 동형암호를 적용하자는 제안에서 비롯되었습니다. #### 소유권 -In the previous section we introduced a private key as a blinding factor to obscure the -transaction's values. -이전의 섹션에서 우리는 트랜잭션의 값을 보기 어렵게 하는 Blinding factor로서 비밀키를 소개했습니다. -The second insight of MimbleWimble is that this private key can be leveraged to prove ownership of the value. -MimbleWimble 의 두번째 통찰은 비밀키가 어떤 값의 소유권을 증명하는데 사용할 수 있다는 것입니다. -Alice sends you 3 coins and to obscure that amount, you chose 28 as your -blinding factor (note that in practice, the blinding factor being a private key, it's an -extremely large number). +이전의 섹션에서 트랜잭션의 값을 보기 어렵게 하는 Blinding factor로서 비밀키를 소개했습니다. MimbleWimble 의 두번째 통찰은 비밀키가 어떤 값의 소유권을 증명하는데 사용할 수 있다는 것입니다. + Alice는 당신에게 3 코인을 보내면서 그 양을 가렸고, 당신은 28을 당신의 blinding factor로 선택했습니다. ( 실제로 blinding factor는 비밀키로 정말 무진장 큰 숫자 입니다.) -Somewhere on the blockchain, the following output appears and should only be spendable by you: 블록체인 어딘가에 다음과 같은 출력값이 나타나 있고 당신에 의해서만 소비될 수 있습니다. - X = 28*G + 3*H -_X_, the result of the addition, is visible by everyone. The value 3 is only known to you and Alice, and 28 is only known to you. -_X_ 는 덧셈의 결과이면서 모두에게 다 보여집니다. 3은 당신과 Alice만 알고 있고 28은 당신만이 알고 있습니다. + X = 28*G + 3*H -To transfer those 3 coins again, the protocol requires 28 to be known somehow. -다시 3코인을 보내기 위해선, 프로토콜은 어떻게든 28을 알고 있어야 됩니다. +_X_ 는 덧셈의 결과이면서 모두에게 다 보여집니다. 3은 당신과 Alice만 알고 있고 28은 당신만이 알고 있습니다. -To demonstrate how this works, let's say you want to transfer those 3 same coins to Carol. -You need to build a simple transaction such that: -어떻게 이것이 작동하는지 보기 위해서, 당신이 캐롤에게 같은 3코인을 보내고 싶어한다고 합시다. -그렇다면 당신은 아래와 같은 간단한 트랜잭션을 작성해야 합니다. +다시 3코인을 보내기 위해선, 프로토콜은 어떻게든 28을 알고 있어야 됩니다. 어떻게 이것이 작동하는지 보기 위해서, 당신이 캐롤에게 같은 3코인을 보내고 싶어한다고 합시다. 그렇다면 당신은 아래와 같은 간단한 트랜잭션을 작성해야 합니다. Xi => Y -Where _Xi_ is an input that spends your _X_ output and Y is Carol's output. 여기서 _Xi_는 _X_ 출력을 사용하는 입력이고 Y는 Carol의 출력입니다. -There is no way to build such a transaction and balance it without knowing your private key of 28. 당신의 비밀키인 28을 모르고서는 트랜잭션과 잔액을 만들 수 있는 방법이 없습니다. -Indeed, if Carol is to balance this transaction, she needs to know both the value sent and your private key 실제로 캐롤이 이 트랜잭션의 잔액을 위해선 그녀는 받는 값과 당신의 비밀키를 알아야 합니다. -so that: + 그러므로 + Y - Xi = (28*G + 3*H) - (28*G + 3*H) = 0*G + 0*H -By checking that everything has been zeroed out, we can again make sure that -no new money has been created. +입니다. + 모든계산이 0으로 되었는지 확인함으로써, 새로운 돈이 만들어지지 않았다는 것을 확인할 수 있습니다. -Wait! Stop! Now you know the private key in Carol's output (which, in this case, must -be the same as yours to balance out) and so you could steal the money back from Carol! -오 잠시만요! 당신은 지금 캐롤의 출력값에 비밀키가 있다는것을 알았습니다. ( 이런경우에는 당신의 잔액이 나간것과 동일 해야 합니다.) 그리고 당신은 캐롤로 부터 돈을 훔칠수 있습니다. - -To solve this, Carol uses a private key of her choosing. -이걸 해결하기위해서 캐롤은 그녀가 선택한 비밀키를 사용합니다. -She picks 113 say, and what ends up on the blockchain is: -113을 비밀키로 선택했다면 블록체인 안에서는 아래와 같이 마무리 됩니다. +오 잠시만요! 당신은 지금 캐롤의 출력값에 비밀키가 있다는것을 알았습니다. ( 이런경우에는 당신의 잔액이 나간것과 동일 해야 합니다.) 그리고 당신은 캐롤로 부터 돈을 훔칠수 있습니다. 이걸 해결하기위해서 캐롤은 그녀가 선택한 비밀키를 사용합니다. + +캐롤이 113을 비밀키로 선택했다면 블록체인 안에서는 아래와 같이 마무리 됩니다. + Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H -Now the transaction no longer sums to zero and we have an _excess value_ on _G_ -(85), which is the result of the summation of all blinding factors. -모든 blinding factor합계 결과로 타원곡선 _G_ 위에서 트랜잭션은 _초과값_ 을 가지게 되고 트랜잭션의 합은 더이상 0 이 아닙니다. +모든 blinding factor합계 결과로 타원곡선 _G_ 위에서 트랜잭션은 _초과값_ (85) 을 가지게 되고 트랜잭션의 합은 더이상 0 이 아닙니다. -But because `85*G` is a valid public key on the elliptic curve _G_, with private key 85, -for any x and y, only if `y = 0` is `x*G + y*H` a valid public key on _G_. 그러나 `85*G` 은 비밀키 85 와 함께 타원곡선 _G_ 에서 유효한 공개키이기 때문에 모든 x와 y는 `y = 0`가 `x*G + y*H`일때 곡선 _G_ 에서 유효한 공개키입니다. -So all the protocol needs to verify is that (`Y - Xi`) is a valid public key on _G_ and that -the transacting parties collectively know the private key (85 in our transaction with Carol). -그러므로 모든 프로토콜은 (`Y - Xi`) 가 _G_위에서 유효한 공개키인지 ,거래당사자들이 비밀키를 알고있는지 ( 캐롤과의 트랜잭션에서는 85) 를 검증해야 할 필요가 있습니다. +그러므로 모든 프로토콜은 (`Y - Xi`) 가 _G_위에서 유효한 공개키인지 ,거래당사자들이 비밀키를 알고있는지 ( 캐롤과의 트랜잭션에서는 85) 를 검증해야 할 필요가 있습니다. 가장 간단하게 검증하는 방법은 Signature가 초과값과 함께 만들어졌다는 것을 요구한 다음 아래와 같은것을 인증하는 겁니다. -The simplest way to do so is to require a signature built with the excess value (85), -which then validates that: -가장 간단하게 검증하는 방법은 Signature가 초과값과 함께 만들어졌다는 것을 요구한 다음 아래와 같은것을 인증하는 겁니다. - -* The transacting parties collectively know the private key, and * 거래하는 당사자들은 모두 비밀키를 알고 있고 -* The sum of the transaction outputs, minus the inputs, sum to a zero value - (because only a valid public key, matching the private key, will check against - the signature). * 트랜잭션의 입력값을 뺀 출력값들의 합은 0입니다. ( 왜냐하면 비밀키와 매칭된 유효한 공개키만 Signature 를 체크할 것이기 때문입니다. ) -This signature, attached to every transaction, together with some additional data (like mining -fees), is called a _transaction kernel_ and is checked by all validators. 모든 트랜잭션에 포함된 이 Signature 는 덧붙여진 어떤 데이터와 함께(채굴 수수료와 같은 데이터) _transaction kernel_ 이라고 부르고 모든 Validator 에 의해 체크됩니다. -#### Some Finer Points #### 몇몇 더 좋은 점들 -This section elaborates on the building of transactions by discussing how change is -introduced and the requirement for range proofs so all values are proven to be -non-negative. -이 섹션은 트랜잭션을 만들때 잔돈이 어떻게 보여지고 범위 증명(range proofs)의 요구사항에 대해서 모든 값이 음수가 아닌지에 대해서 좀 더 자세하게 설명하려고 합니다. -Neither of these are absolutely required to understand MimbleWimble and Grin, so if you're in a hurry, feel free to jump straight to [Putting It All Together](#putting-it-all-together). -이러한 개념들 역시 MimbleWimble 과 Grin 에 대한 이해가 당연히 필요합니다. -만약 당신이 조급하다면 [이 링크를 참고하세요.](#putting-it-all-together). - -##### Change +이 섹션은 트랜잭션을 만들때 잔돈이 어떻게 보여지고 범위 증명(range proofs)의 요구사항에 대해서 모든 값이 음수가 아닌지에 대해서 좀 더 자세하게 설명하려고 합니다. 이러한 개념들 역시 MimbleWimble 과 Grin 에 대한 이해가 당연히 필요합니다. 만약 당신이 조급하다면 [이 링크를 참고하세요.](#putting-it-all-together). ##### 잔돈에 대해서 -Let's say you only want to send 2 coins to Carol from the 3 you received from -Alice. -캐롤에게 2개의 코인을 보내고 3개를 앨리스에게서 받는다고 해봅시다. -To do this you would send the remaining 1 coin back to yourself as change. -이렇게 하려면 당신은 남은 1개의 코인을 잔돈으로 당신에게 돌려줘야 합니다. -You generate another private key (say 12) as a blinding factor to -protect your change output. Carol uses her own private key as before. -이때, 다른 비밀키를 blinding factor 로 만들어서 (12라고 합시다.) 출력값을 보호해야 합니다. 캐롤은 이전에 썻던 그녀의 비밀키를 씁니다. - - Change output: 12*G + 1*H - Carol's output: 113*G + 2*H - -What ends up on the blockchain is something very similar to before. -블록체인 안에서의 결과는 예전과 매우 흡사합니다. -And the signature is again built with the excess value, 97 in this example. -그리고 Signature 은 초과되는 값과 함께 다시 만들어질겁니다. 이 예시에서는 97이라고 합시다. +캐롤에게 2개의 코인을 보내고 3개를 앨리스에게서 받는다고 해봅시다.이렇게 하려면 당신은 남은 1개의 코인을 잔돈으로 당신에게 돌려줘야 합니다. 이때, 다른 비밀키를 blinding factor 로 만들어서 (12라고 합시다.) 출력값을 보호해야 합니다. 캐롤은 이전에 썻던 그녀의 비밀키를 씁니다. + + 잔돈의 출력값 : 12*G + 1*H + 캐롤의 출력값 : 113*G + 2*H + +블록체인 안에서의 결과는 예전과 매우 흡사합니다. 그리고 Signature 은 초과되는 값과 함께 다시 만들어질겁니다. 이 예시에서는 97이라고 합시다. + (12*G + 1*H) + (113*G + 2*H) - (28*G + 3*H) = 97*G + 0*H ##### Range Proofs -In all the above calculations, we rely on the transaction values to always be positive. -위의 모든 게산에서 트랜잭션의 값들은 항상 양의(+)값입니다. -The introduction of negative amounts would be extremely problematic as one could -create new funds in every transaction. -음의 값은 모든 트랜잭션마다 새로운 돈을 만들수 있다는 것이므로 매우 문제점이 될겁니다. - -For example, one could create a transaction with an input of 2 and outputs of 5 -and -3 and still obtain a well-balanced transaction, following the definition in -the previous sections. -예를 들어 입력값이 3이고 출력값이 5과 -3인 트랜잭션을 만들수 있고 이전 섹션의 정의에 따라 잘 구성된 트랜잭션입니다. -This can't be easily detected because even if _x_ is -negative, the corresponding point `x.H` on the curve looks like any other. -적잘한 좌표 `x.H`가 다른 좌표처럼 곡선위에 있어서 _x_가 음수이더라도 찾기가 쉽지 않습니다. - -To solve this problem, MimbleWimble leverages another cryptographic concept (also -coming from Confidential Transactions) called range proofs: +위의 모든 계산에서 트랜잭션의 값들은 항상 양의(+)값입니다. 음의 값은 모든 트랜잭션마다 새로운 돈을 만들수 있다는 것이므로 매우 문제점이 될겁니다. + +예를 들어 입력값이 3이고 출력값이 5과 -3인 트랜잭션을 만들수 있으며 이것은 이전 섹션의 정의에 따라 잘 구성된 트랜잭션입니다. 적절한 좌표 `x.H`가 다른 좌표처럼 곡선위에 있어서 _x_가 음수이더라도 찾기가 쉽지 않습니다. + 이 문제점을 해결하기 위해서, MimbleWimble 은 Range proofs 라는 다른 암호학 개념을 사용합니다. ( 이 또한 Confidential Transaction 에서 유래했습니다.) -a proof that a number falls within a given range, without revealing -the number. Range proof 란 숫자를 밝히지 않고 어떤 숫자가 주어진 범위안에 있는지 증명하는 것입니다. -We won't elaborate on the range proof, but you just need to know -that for any `r.G + v.H` we can build a proof that will show that _v_ is greater than -zero and does not overflow. -Range proof 에 대해서 자세히 설명하지 않을것이지만은, 그래도 어떤 `r.G + v.H` 의 결과가 _v_ 가 0보다 크고 오버플로우가 일어나지 않는다는 것을 증명할 수 있습니다. -It's also important to note that in order to create a valid range proof from the example above, both of the values 113 and 28 used in creating and signing for the excess value must be known. 또한 위의 예에서 유효한 Range proof 를 만들기 위해서 트랜잭션을 만들고 Signing 할때 사용된 초과값인 113과 28 두 값이 알려지는것은 중요합니다. -The reason for this, as well as a more detailed description of range proofs are further detailed in the [range proof paper](https://eprint.iacr.org/2017/1066.pdf). -그 이유는, [range proof paper](https://eprint.iacr.org/2017/1066.pdf)에 Range proof에 대해 좀더 자세한 설명이 있습니다. - -#### Putting It All Together +Range proof 에 대해서 자세히 설명하지 않을것이지만은, 그래도 어떤 `r.G + v.H` 의 결과가 _v_ 가 0보다 크고 오버플로우가 일어나지 않는다는 것을 증명할 수 있습니다. 또한 위의 예에서 유효한 Range proof 를 만들기 위해서 트랜잭션을 만들고 Signing 할때 사용된 초과값인 113과 28 두 값이 알려지는것은 중요합니다. 그 이유에 대해선 [range proof paper](https://eprint.iacr.org/2017/1066.pdf) 안에 Range proof에 대해 좀더 자세한 설명이 있습니다. #### 모든것을 함깨 놓고 이해하기 -A MimbleWimble transaction includes the following: MimbleWimlbe 트랜잭션은 다음을 포함합니다. -* A set of inputs, that reference and spend a set of previous outputs. * 이전의 출력값들이 참조하고 사용한 입력값의 셋트들 -* A set of new outputs that include: * 새로운 출력값들은 다음을 포함합니다. - * A value and a blinding factor (which is just a new private key) multiplied on - a curve and summed to be `r.G + v.H`. * 곡선위에서 `r.G + v.H` 로 합해 지는 값 과 blinding factor (그냥 새로운 비밀 키). - * A range proof that shows that v is non-negative. * v 가 음수가 아님을 보여주는 Range proof. -* An explicit transaction fee, in clear. * 분명히 명시된 트랜잭션 수수료 -* A signature, computed by taking the excess blinding value (the sum of all - outputs plus the fee, minus the inputs) and using it as a private key. * 수수료가 더해진 모든 출력밧에서 입력값을 뺸 초과 blinding 값이 계산되고 그것이 비밀키로 사용된 Signature. -### Blocks and Chain State - ### 블록들과 체인 state에 대해서 -We've explained above how MimbleWimble transactions can provide -strong anonymity guarantees while maintaining the properties required for a valid -blockchain, -위에서 MimbleWimble 트랜잭션이 유요한 블록체인에 필요한 속성을 유지하면서 어떻게 강한 익명성을 보장하는지 설명했습니다. -i.e., a transaction does not create money and proof of ownership -is established through private keys. -예를들면 트랜잭션이 더이상 코인을 만들지 않으면서 비밀키를 통해 소유권을 증명하지 않는 방법들 같은것 말이죠. - -The MimbleWimble block format builds on this by introducing one additional -concept: _cut-through_. -추가적으로 _cut-through_ 라는 개념이 MimbleWimble 블록 포멧에 사용 됩니다. - With this addition, a MimbleWimble chain gains: -이로 인해 MimbleWimble 체인은 아래와 같은 장점을 얻습니다. - -* Extremely good scalability, as the great majority of transaction data can be - eliminated over time, without compromising security. +위에서 MimbleWimble 트랜잭션이 유요한 블록체인에 필요한 속성을 유지하면서 어떻게 강한 익명성을 보장하는지 설명했습니다.예를 들면 트랜잭션이 더이상 코인을 만들지 않으면서 비밀키를 통해 소유권을 증명하지 않는 방법들 같은것 말이죠. + +추가적으로 _cut-through_ 라는 개념이 MimbleWimble 블록 포멧에 사용 됩니다. 이로 인해 MimbleWimble 체인은 아래와 같은 장점을 얻습니다. + * 대부분의 트랜잭션 데이터는 보안을 희생하지 않고서도 시간이 지나면 없어 질 수 있으므로 엄청나게 좋은 확장성을 얻게 됩니다. -* Further anonymity by mixing and removing transaction data. * 트랜잭션 데이터를 섞고 없애서 익명성을 추가로 획득합니다. -* And the ability for new nodes to sync up with the rest of the network very - efficiently. * 새로운 노드가 네트웍에서 동기화를 이룰때 매우 효과적입니다. -#### Transaction Aggregation - #### 트랜잭션 합치기 -Recall that a transaction consists of the following - -트랜잭션언 다음와 같은것들로 이뤄져 있다는걸 상기해봅시다. +트랜잭션은 다음와 같은것들로 이뤄져 있다는걸 상기해봅시다. -* a set of inputs that reference and spent a set of previous outputs * 이전의 출력값들이 참조하고 사용한 입력값의 셋트들 -* a set of new outputs (Pedersen commitments) * 새로운 출력값의 세트들 ( Pederson commitment) -* a transaction kernel, consisting of - * kernel excess (Pedersen commitment to zero) - * transaction signature (using kernel excess as public key) -* kernal execess와 (kernel 초과값이 공개키로 사용된) 트랜잭션 Signature로 이뤄진 트랜잭션 Kernel. +* kernal execess와 (kernel 초과값이 공개키로 사용된) 트랜잭션 Signature로 이뤄진 트랜잭션 Kernel. -A tx is signed and the signature included in a _transaction kernel_. sign 된 트랜잭션과 Signature 은 _transaction kernel_ 에 포함됩니다. +Signature 공개키로서 트랜잭션의 합이 0임을 증명하는 _kernel excess_ 를 이용해서 생성됩니다. -The signature is generated using the _kernel excess_ as a public key proving that the transaction sums to 0. -Signature 은 (42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H -The public key in this example being `28*G`. +이번 예시에서 공개키는 `28*G` 입니다. -We can say the following is true for any valid transaction (ignoring fees for simplicity) - +다음은 어떠한 유효한 트랜잭션에서도 참이라고 말 할 수 있습니다. (단순함을 위해 수수료는 무시합니다. ) - sum(outputs) - sum(inputs) = kernel_excess + 출력값의 합 - 입력값의 합 = kernel_excess -The same holds true for blocks themselves once we realize a block is simply a set of aggregated inputs, outputs and transaction kernels. We can sum the tx outputs, subtract the sum of the tx inputs and compare the resulting Pedersen commitment to the sum of the kernel excesses - +블록이 입력값과 출력값의 합 그리고 트랜잭션 kernel들의 집합이면 블록도 마찬가지라고 할 수 있습니다. 트랜잭션의 출력값을 더할 수 있고 입력값의 합을 뺀다음 그 결과인 Perderson commitment 와 kernal excess와 비교합니다. - sum(outputs) - sum(inputs) = sum(kernel_excess) + 출력값의 합 - 입력값의 합 = kernel_excess의 합 -Simplifying slightly, (again ignoring transaction fees) we can say that MimbleWimble blocks can be treated exactly as MimbleWimble transactions. +약간 단순화 시켜서 ( 트랜잭션 수수료를 무시하고) 우리는 MimbleWimbl block 이 MimbleWimble 트랜잭션들로 다뤄진다고 말 할 수 있습니다. -##### Kernel Offsets +##### Kernel 오프셋들 -There is a subtle problem with MimbleWimble blocks and transactions as described above. It is possible (and in some cases trivial) to reconstruct the constituent transactions in a block. This is clearly bad for privacy. This is the "subset" problem - given a set of inputs, outputs and transaction kernels a subset of these will recombine to reconstruct a valid transaction. +위에 설명했던겉 처럼 MimbleWimble 블록과 트랜잭션에 조그마한 문제가 있습니다. 그것은 블록에 있는 구성 트랜잭션을 재구성하는것이 가능합다는 겁니다.(그리고 어떤 사소한 경우에도요). +이것은 분명히 프라이버시에는 좋지 않습니다. 이걸 "subset" 문제 라고 합니다. +"Subset" 문제란 주어진 입력값들, 출력값들과 트랜잭션 kernel들의 Subset 들이 재조합되어서 유효한 트랜잭션을 다시 만든다는 것입니다. -For example, given the following two transactions - +예를 들어 다음과 같이 두 트랜잭션이 있다고 해봅시다. (in1, in2) -> (out1), (kern1) (in3) -> (out2), (kern2) -We can aggregate them into the following block (or aggregate transaction) - +다음과 같은 블록에 합칠 수 있을겁니다. ( 아니면 트랜잭션을 합쳐도 됩니다.) (in1, in2, in3) -> (out1, out2), (kern1, kern2) -It is trivially easy to try all possible permutations to recover one of the transactions (where it sums successfully to zero) - +(합계가 0일경우 ) 트랜잭션들 중 하나를 복구하기 위해서 가능한 모든 순열 조합을 조합해보는것은 쉽습니다. (in1, in2) -> (out1), (kern1) -We also know that everything remaining can be used to reconstruct the other valid transaction - +또한 남은 트랜잭션이 다른 유효한 트랜잭션을 만드는데 사용되기도 합니다. (in3) -> (out2), (kern2) -To mitigate this we include a _kernel offset_ with every transaction kernel. This is a blinding factor (private key) that needs to be added back to the kernel excess to verify the commitments sum to zero - +이런것을 완화 시키기 위해 _kernel offset_ 이라는 것을 모든 트랜잭션 kernel 에 포함시킵니다. 실행 값이 0이라는 것을 증명하기 위해 kernel excess 에 더해져야 하는 blinding factor (비밀키)입니다. - sum(outputs) - sum(inputs) = kernel_excess + kernel_offset + 출력값의 합 - 입력값의 합 = kernel_excess + kernel 오프셋(offset) -When we aggregate transactions in a block we store a _single_ aggregate offset in the block header. And now we have a single offset that cannot be decomposed into the individual transaction kernel offsets and the transactions can no longer be reconstructed - +블록 안에서 트랜잭션을 합칠때, _single_ 통합 오프셋(offset)을 블록 헤더에 저장합니다. +그래서 single 오프셋으로 인해 개별 트랜잭션 kernel offset 을 개별로 분리할 수 없고 트랜잭션 들은 더이상 재구성 될 수 없습니다. - sum(outputs) - sum(inputs) = sum(kernel_excess) + kernel_offset + 출력값의 합 - 입력값의 합 = kernel_excess의 합 + kernel_offset -We "split" the key `k` into `k1+k2` during transaction construction. For a transaction kernel `(k1+k2)*G` we publish `k1*G` (the excess) and `k2` (the offset) and sign the transaction with `k1*G` as before. -During block construction we can simply sum the `k2` offsets to generate a single aggregate `k2` offset to cover all transactions in the block. The `k2` offset for any individual transaction is unrecoverable. +키 `k`를 트랜잭션 구성 중에 `k1+k2` 안에 나누어서 넣었습니다. 트랜잭션 커널인`(k1+k2)*G` 에 대해 excess 인 `k1*G`와 오프셋(offset) 인 `k2`를 보여주고 이전처럼 `k1*G`로 트랜잭션에 sign 합니다. -#### Cut-through +블록을 만드는 동안 블록안의 모든 트랜잭션을 커버하기 위한 한개의 통합 `k` 오프셋을 만들기 위해 `k2`오프셋을 간단히 합할 수 있습니다. `k2`오프셋은 어떤 개별 트랜잭션이 복구되지 못하도록 합니다. -Blocks let miners assemble multiple transactions into a single set that's added -to the chain. In the following block representations, containing 3 transactions, -we only show inputs and -outputs of transactions. Inputs reference outputs they spend. An output included -in a previous block is marked with a lower-case x. +#### 컷 스루 (Cut-through) + +블록들은 채굴자들이 여러 트랜잭션들을 하나의 세트에 넣고 체인에 더할수 있게 합니다. +다음 블록은 3개의 트랜잭션을 포함하고 있습니다. 오직 입력과 출력만을 보여줍니다. +소비한 출력값은 입력값을 참고 합니다. 출력값은 소문자 x로 표시된 이전 블록을 포함합니다. I1(x1) --- O1 |- O2 @@ -475,10 +260,8 @@ in a previous block is marked with a lower-case x. I4(O3) --- O4 |- O5 -We notice the two following properties: - -* Within this block, some outputs are directly spent by included inputs (I3 - spends O2 and I4 spends O3). +다음과 같은 두가지 성질을 알려드리자면: +* 이 블록 안에서는 어떤 출력값은 포함된 입력값을 바로 사용합니다.(I3는 02를 소비하고 I4는 03을 소비합니다.) * The structure of each transaction does not actually matter. As all transactions individually sum to zero, the sum of all transaction inputs and outputs must be zero. @@ -551,15 +334,9 @@ only by adding or removing an output. Doing so would cause the summation of all blinding factors in the transaction kernels to differ from the summation of blinding factors in the outputs. -### Conclusion + ### 결론 내리기 -In this document we covered the basic principles that underlie a MimbleWimble -blockchain. + 이 문서에서는 MimbleWimble 블록체인 안의 기본적인 원리에 대해서 다루었습니다. -By using the addition properties of Elliptic Curve Cryptography, we're -able to build transactions that are completely opaque but can still be properly -validated. 타원 곡선 암호의 다른 성질을 사용해서 알아보기 어려우나 적절하게 입증될 수 있는 트랜잭션을 만들수 있습니다. -And by generalizing those properties to blocks, we can eliminate a large -amount of blockchain data, allowing for great scaling and fast sync of new peers. 블록들에 이러한 성질들을 일반화 시키면 큰 용량의 블록체인 데이터를 없앨 수 있고 새로운 피어들에게 높은 확장성과 빠른 동기화를 가능하게 할 수 있습니다. diff --git a/doc/stratum_KR.md b/doc/stratum_KR.md index 65fe4fbb34..d91589e05f 100644 --- a/doc/stratum_KR.md +++ b/doc/stratum_KR.md @@ -12,8 +12,8 @@ 5. [status](#status) 6. [submit](#submit) 2. [에러 메시지들](#error-messages) -3. [채굴자의 행동양식](#채굴자-행동양식) -4. [참고 구현체](#참고-구현체) +3. [채굴자의 행동양식](#miner-behavior) +4. [참고 구현체](#reference-implementation) ## 메세지 들 From a92b581f0822dc84759cbe1a263456780b77dfed Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Tue, 19 Feb 2019 21:30:21 +0900 Subject: [PATCH 18/25] rename intro.KR.md to intro_KR.md --- doc/intro_KR.md | 342 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 342 insertions(+) create mode 100644 doc/intro_KR.md diff --git a/doc/intro_KR.md b/doc/intro_KR.md new file mode 100644 index 0000000000..ed7b277db3 --- /dev/null +++ b/doc/intro_KR.md @@ -0,0 +1,342 @@ +# MimbleWimble 과 Grin 에 대한 소개 + +*다른 언어로 Intro를 읽으시려면: [English](intro.md), [简体中文](intro.zh-cn.md), [Español](intro_ES.md), [Русский](intro.ru.md), [日本語](intro.jp.md).* + +MimbleWimlbe은 블록체인 포맷이면서 프로토콜 입니다. +MimbleWimble은 암호학적 기반에 의해서 극대화된 좋은 확장성, 프라이버시, 그리고 대체가능성을 제공합니다. 이러한 특성은 지금 현존하는 모든 블록체인 구현체에 존재하는 문제점들을 처리합니다. + +Grin 은 Mimble Wimble 블록체인을 구현한 오픈소스 프로젝트 입니다. 또한 완전한 블록체인와 크립토 커런시의 배포에 필요한 갭을 채워줍니다. +Grin 프로젝트의 주요 목적과 특성들은 아래 설명을 참고하십시오. + +* 프라이버시가 기본으로 제공됩니다. 이 기능은 필요에 따라서 선택적으로 정보를 공개 할 수 없도록 해서 완전한 대체가능성을 할 수 있게 합니다. +* 주로 유저의 규모와 최소한의 트랜잭션 수의 규모로 (100byte 미만의 kernel(transaction)) 다른 블록체인들과 비교하면 많은 저장공간을 절약할 수 있습니다. +* Mimble Wimble 은 수십년 동안 테스트하고 사용되었던 강력한 암호기술인 ECC만 사용합니다. +* 간단한 디자인은 감사와 유지보수를 시간이 지나도 수월하게 만듭니다. +* 커뮤니티가 주도하며, 채굴 탈중앙화가 권장됩니다. + +## 모두의 혀를 묶자. +이 문서는 블록체인에 대해 어느정도 이해가 있고 암호학에 대한 기본적인 이해가 있는 독자들을 대상으로 합니다. 이것을 염두에 두고 우리는 MimbleWimble의 기술적인 발전과 어떻게 Grin에 적용되었는지 관해 설명 할 것입니다. +저희는 이 문서가 대부분의 기술적인 성격을 가진 독자들을 이해시킬 수 있길 바랍니다. 우리의 목적은 독자가 Grin에 대해 흥미를 느끼게 하고 어떤 방식으로든 Grin에 기여할 수 있게 이끄는 것입니다. +이러한 목적을 이루기 위해, 우리는 MimbleWimble 의 구현체인 Grin을 이해하는데 필요한 주요 컨셉들에 대해서 소개할것입니다. + + 우선 Grin이 어디에서 부터 기초로 하고 있는지에 대해 이해하기 위해서 타원 곡선 암호 (ECC)의 몇몇 속성들에 대한 간단한 설명으로 시작하겠습니다. 그 다음, MimbleWimble 블록체인의 트랜잭션과 블록에 한 모든 요소들을 설명하겠습니다. + +### 타원곡선에 대한 조그마한 조각들 +ECC의 너무 복잡한 사항을 캐지 않고 어떻게 mimble wimble 이 어떻게 작동하는지에 대해 이해하는데 필요한 요소들만 리뷰할 것입니다. 이런 가정들을 좀 더 알고싶은 독자들은 [이 링크](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/)를 참고하세요. + +암호학에서의 타원 곡선이란 우리가 _C_ 라고 부르는 단순히 아주 큰 좌표의 집합입니다. +이 좌표들은 정수들로 (인티저, 또는 스칼라 ) 더하고 빼고 곱할 수 있습니다. + +주어진 정수 _K_ 에 스칼라 곱셈을 한다면 우리는 곡선 _c_ 위에 있는 좌표 K*H를 계산 할 수 있습니다. +또 달리 주어진 정수 _j_ 에 우리는`k*H + j*H` 와 같은 `(k+j)*H`를 계산 할 수 있습니다. + +타원곡선 위에서의 덧셈과 정수 곱셈은 제시된 수의 순서에 관계없이 결과가 동일하다는 성질과 덧셈과 곱셈의 계산 순서와 관계없이 동일한 결과가 나온다는 성질을 가지고 있습니다. + + (k+j)*H = k*H + j*H + +ECC 안에서 우리가 매우 큰 숫자인 _k_ 를 프라이빗 키로 가정할 때 `k*H` 는 해당하는 퍼블릭 키로 해당되어 집니다. 누군가 공개키인 `k*H`의 값을 알더라도 _k_ 를 추론해 내는것은 불가능에 가깝습니다. ( 달리 얘기하자면, 곱셉은 쉬우나 곡선 좌표에 의한 "나눗셈"은 정말 어렵습니다. ) + +_k_ 와 _j_ 둘다 비밀키인 이전 공식 `(k+j)*H = k*H + j*H` 는 두개의 비밀키를 더해서 얻은 한 개의 공개키 (`(k+j)*H`) 와 각각 두개의 비밀키에 공개키를 더한것과 같습니다. Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. MimbleWimble 과 Grin의 구현또한 마찬가지 입니다. + +### MimbleWimble 함께 거래하기 +트랜잭션의 구조는 MimbleWimble의 강력한 프라이버시와 비밀이 유지된다라고 하는 중요한 규칙을 나타냅니다. + +MimbleWimble 트랜잭션의 확인은 두가지 기본적인 성격을 전제로 합니다. + +* **제로섬의 검증:** 결과값에서 입력값을 뺸 합은 항상 0과 같습니다. 이것은 실제 전송되는 코인의 양을 드러내지 않고도 트랜잭션ㅇ이 새로운 코인을 만들지 않았다는 것을 증명합니다. +* **비밀키의 소유:** 다른 많은 크립토 커런시 들처럼 , 트랜잭션의 소유권은 ECC 비밀키에 의해 보장됩니다. 그러나 어떤 실체가 이런 비밀키들을 소유하고 있다고 증명하는것이 직접적으로 트랜잭션에 사인한다고해서 얻어지는 것은 아닙니다. + +다음 섹션들에서는 잔고, 소유권, 거스름돈과 증명들의 상세들이 어떻게 저 두가지 기본적인 성질에 의해서 얻어지는지 알아보겠습니다. + +#### 잔고 +위에서 언급한 ECC의 특성들을 기반으로 해서 트랜잭션안의 가치들을 보기 어렵게 할 수 있습니다. +만약 _v_ 가 트랜잭션 입력값이거나 출력값이고 _H_ 가 타원곡선이라면 , 단순히 _v_ 대신 `v*H`를 끼워 넣을 수 있습니다. + +이것은 ECC를 사용하기 때문에 작동하는 것입니다. 우리는 출력값의 합이 입력값의 합과 같다는 것을 여전히 확인할 수 있습니다. + + v1 + v2 = v3 => v1*H + v2*H = v3*H + +이 특성을 모든 트랜잭션에 확인하는것은 프로토콜이 트랜잭션은 돈을 난데없이 만들지 않는다는 것을 실제 돈이 얼마나 있는지 알지 않아도 검증할 수 있게 합니다. +그러나 사용가능한 한정된 숫자가 있고 그 숫자 중 하나를 사용해서 당신의 트랜잭션이 얼마만큼의 코인을 가졌는지 추측 할 수 있습니다. 더해서, v1을 알고 ( 예시로 사용된 이전의 트랜잭션에서 온 값 ) 그에따른 `v1*H`의 결과를 알면 블록체인 전체에 걸쳐서 v1 값이 있는 모든 출력값들이 드러나게 됩니다. + +이러한 이유로 두번째 타원곡선인 _G_ 를 제시합니다. ( 실제로 _G_ 는 _H_ 의 그룹과 같은 곡선에 있으며 단지 다른 좌표를 생성해 냅니다.) 그리고 비밀키 _r_ 은 *blinding factor* 로 사용됩니다. + +그렇다면 트랜잭션 안의 입력값과 출력값은 다음과 같이 표현됩니다. + + r*G + v*H + +여기서 + +* _r_ 은 비밀키이고 blinding factor 로 사용됩니다. _G_ 는 타원 곡선 이고 `r*G`는 _G_ 안에 있는 _r_ 의 공개키 입니다. +* _v_ 는 출력값이거나 입력값이고 _H_ 는 다른 타원곡선입니다.타원곡선의 근본적인 특성을 이용했기 때문에 _v_ 와 _r_ 은 추측될 수 없습니다. `r*G + v*H`를 _Pedersen Commitment_ 라고 부릅니다. + +예를 들어 , ( 전송료는 무시하고) 두개의 입력값과 한개의 출력값으로 트랜잭션을 만들기 원한다고 가정해봅시다. + +* vi1 과 v2 는 출력값 +* vo3는 출력값 이라면 + +그렇다면 + + vi1 + vi2 = vo3 + +입니다. + +각각의 입력값에 대해서 blining factor 로 비밀키를 만들고 각각의 값을 각각의 이전의 공식에 있던 Pederson Commitment로 교체한다고 하면 다음과 같습니다. + + (ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vo3*H) + +결과로 다음과 같습니다. + + ri1 + ri2 = ro3 + +이것이 MimbleWimble의 첫번째 특징입니다. 트랜잭션을 검증하는 산술적인 연산은 아무런 값을 알지 못해도 가능합니다. + +이 아이디어는 Greg Maxwell 의 [Confidential Transactions](https://elementsproject.org/features/confidential-transactions/investigation) 에서 유래했습니다. Confidential transaction은 Adam back의 비트코인에 동형암호를 적용하자는 제안에서 비롯되었습니다. + +#### 소유권 + +이전의 섹션에서 트랜잭션의 값을 보기 어렵게 하는 Blinding factor로서 비밀키를 소개했습니다. MimbleWimble 의 두번째 통찰은 비밀키가 어떤 값의 소유권을 증명하는데 사용할 수 있다는 것입니다. + +Alice는 당신에게 3 코인을 보내면서 그 양을 가렸고, 당신은 28을 당신의 blinding factor로 선택했습니다. ( 실제로 blinding factor는 비밀키로 정말 무진장 큰 숫자 입니다.) + +블록체인 어딘가에 다음과 같은 출력값이 나타나 있고 당신에 의해서만 소비될 수 있습니다. + + X = 28*G + 3*H + +_X_ 는 덧셈의 결과이면서 모두에게 다 보여집니다. 3은 당신과 Alice만 알고 있고 28은 당신만이 알고 있습니다. + +다시 3코인을 보내기 위해선, 프로토콜은 어떻게든 28을 알고 있어야 됩니다. 어떻게 이것이 작동하는지 보기 위해서, 당신이 캐롤에게 같은 3코인을 보내고 싶어한다고 합시다. 그렇다면 당신은 아래와 같은 간단한 트랜잭션을 작성해야 합니다. + + Xi => Y + +여기서 _Xi_는 _X_ 출력을 사용하는 입력이고 Y는 Carol의 출력입니다. +당신의 비밀키인 28을 모르고서는 트랜잭션과 잔액을 만들 수 있는 방법이 없습니다. + +실제로 캐롤이 이 트랜잭션의 잔액을 위해선 그녀는 받는 값과 당신의 비밀키를 알아야 합니다. + +그러므로 + + Y - Xi = (28*G + 3*H) - (28*G + 3*H) = 0*G + 0*H + +입니다. + +모든계산이 0으로 되었는지 확인함으로써, 새로운 돈이 만들어지지 않았다는 것을 확인할 수 있습니다. +오 잠시만요! 당신은 지금 캐롤의 출력값에 비밀키가 있다는것을 알았습니다. ( 이런경우에는 당신의 잔액이 나간것과 동일 해야 합니다.) 그리고 당신은 캐롤로 부터 돈을 훔칠수 있습니다. 이걸 해결하기위해서 캐롤은 그녀가 선택한 비밀키를 사용합니다. + +캐롤이 113을 비밀키로 선택했다면 블록체인 안에서는 아래와 같이 마무리 됩니다. + + Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H + +모든 blinding factor합계 결과로 타원곡선 _G_ 위에서 트랜잭션은 _초과값_ (85) 을 가지게 되고 트랜잭션의 합은 더이상 0 이 아닙니다. + +그러나 `85*G` 은 비밀키 85 와 함께 타원곡선 _G_ 에서 유효한 공개키이기 때문에 모든 x와 y는 `y = 0`가 `x*G + y*H`일때 곡선 _G_ 에서 유효한 공개키입니다. + +그러므로 모든 프로토콜은 (`Y - Xi`) 가 _G_위에서 유효한 공개키인지 ,거래당사자들이 비밀키를 알고있는지 ( 캐롤과의 트랜잭션에서는 85) 를 검증해야 할 필요가 있습니다. 가장 간단하게 검증하는 방법은 Signature가 초과값과 함께 만들어졌다는 것을 요구한 다음 아래와 같은것을 인증하는 겁니다. + +* 거래하는 당사자들은 모두 비밀키를 알고 있고 +* 트랜잭션의 입력값을 뺀 출력값들의 합은 0입니다. ( 왜냐하면 비밀키와 매칭된 유효한 공개키만 Signature 를 체크할 것이기 때문입니다. ) + +모든 트랜잭션에 포함된 이 Signature 는 덧붙여진 어떤 데이터와 함께(채굴 수수료와 같은 데이터) _transaction kernel_ 이라고 부르고 모든 Validator 에 의해 체크됩니다. + +#### 몇몇 더 좋은 점들 + +이 섹션은 트랜잭션을 만들때 잔돈이 어떻게 보여지고 범위 증명(range proofs)의 요구사항에 대해서 모든 값이 음수가 아닌지에 대해서 좀 더 자세하게 설명하려고 합니다. 이러한 개념들 역시 MimbleWimble 과 Grin 에 대한 이해가 당연히 필요합니다. 만약 당신이 조급하다면 [이 링크를 참고하세요.](#putting-it-all-together). + +##### 잔돈에 대해서 + +캐롤에게 2개의 코인을 보내고 3개를 앨리스에게서 받는다고 해봅시다.이렇게 하려면 당신은 남은 1개의 코인을 잔돈으로 당신에게 돌려줘야 합니다. 이때, 다른 비밀키를 blinding factor 로 만들어서 (12라고 합시다.) 출력값을 보호해야 합니다. 캐롤은 이전에 썻던 그녀의 비밀키를 씁니다. + + 잔돈의 출력값 : 12*G + 1*H + 캐롤의 출력값 : 113*G + 2*H + +블록체인 안에서의 결과는 예전과 매우 흡사합니다. 그리고 Signature 은 초과되는 값과 함께 다시 만들어질겁니다. 이 예시에서는 97이라고 합시다. + + (12*G + 1*H) + (113*G + 2*H) - (28*G + 3*H) = 97*G + 0*H + +##### Range Proofs + +위의 모든 계산에서 트랜잭션의 값들은 항상 양의(+)값입니다. 음의 값은 모든 트랜잭션마다 새로운 돈을 만들수 있다는 것이므로 매우 문제점이 될겁니다. + +예를 들어 입력값이 3이고 출력값이 5과 -3인 트랜잭션을 만들수 있으며 이것은 이전 섹션의 정의에 따라 잘 구성된 트랜잭션입니다. 적절한 좌표 `x.H`가 다른 좌표처럼 곡선위에 있어서 _x_가 음수이더라도 찾기가 쉽지 않습니다. + +이 문제점을 해결하기 위해서, MimbleWimble 은 Range proofs 라는 다른 암호학 개념을 사용합니다. ( 이 또한 Confidential Transaction 에서 유래했습니다.) +Range proof 란 숫자를 밝히지 않고 어떤 숫자가 주어진 범위안에 있는지 증명하는 것입니다. +Range proof 에 대해서 자세히 설명하지 않을것이지만은, 그래도 어떤 `r.G + v.H` 의 결과가 _v_ 가 0보다 크고 오버플로우가 일어나지 않는다는 것을 증명할 수 있습니다. 또한 위의 예에서 유효한 Range proof 를 만들기 위해서 트랜잭션을 만들고 Signing 할때 사용된 초과값인 113과 28 두 값이 알려지는것은 중요합니다. 그 이유에 대해선 [range proof paper](https://eprint.iacr.org/2017/1066.pdf) 안에 Range proof에 대해 좀더 자세한 설명이 있습니다. + +#### 모든것을 함깨 놓고 이해하기 + +MimbleWimlbe 트랜잭션은 다음을 포함합니다. + +* 이전의 출력값들이 참조하고 사용한 입력값의 셋트들 +* 새로운 출력값들은 다음을 포함합니다. + * 곡선위에서 `r.G + v.H` 로 합해 지는 값 과 blinding factor (그냥 새로운 비밀 키). + * v 가 음수가 아님을 보여주는 Range proof. +* 분명히 명시된 트랜잭션 수수료 +* 수수료가 더해진 모든 출력밧에서 입력값을 뺸 초과 blinding 값이 계산되고 그것이 비밀키로 사용된 Signature. + +### 블록들과 체인 state에 대해서 + +위에서 MimbleWimble 트랜잭션이 유요한 블록체인에 필요한 속성을 유지하면서 어떻게 강한 익명성을 보장하는지 설명했습니다.예를 들면 트랜잭션이 더이상 코인을 만들지 않으면서 비밀키를 통해 소유권을 증명하지 않는 방법들 같은것 말이죠. + +추가적으로 _cut-through_ 라는 개념이 MimbleWimble 블록 포멧에 사용 됩니다. 이로 인해 MimbleWimble 체인은 아래와 같은 장점을 얻습니다. + +* 대부분의 트랜잭션 데이터는 보안을 희생하지 않고서도 시간이 지나면 없어 질 수 있으므로 엄청나게 좋은 확장성을 얻게 됩니다. +* 트랜잭션 데이터를 섞고 없애서 익명성을 추가로 획득합니다. +* 새로운 노드가 네트웍에서 동기화를 이룰때 매우 효과적입니다. + +#### 트랜잭션 합치기 + +트랜잭션은 다음와 같은것들로 이뤄져 있다는걸 상기해봅시다. + +* 이전의 출력값들이 참조하고 사용한 입력값의 셋트들 +* 새로운 출력값의 세트들 ( Pederson commitment) +* kernal execess와 (kernel 초과값이 공개키로 사용된) 트랜잭션 Signature로 이뤄진 트랜잭션 Kernel. + +sign 된 트랜잭션과 Signature 은 _transaction kernel_ 에 포함됩니다. +Signature 공개키로서 트랜잭션의 합이 0임을 증명하는 _kernel excess_ 를 이용해서 생성됩니다. + + (42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H + +이번 예시에서 공개키는 `28*G` 입니다. + +다음은 어떠한 유효한 트랜잭션에서도 참이라고 말 할 수 있습니다. (단순함을 위해 수수료는 무시합니다. ) + + 출력값의 합 - 입력값의 합 = kernel_excess + +블록이 입력값과 출력값의 합 그리고 트랜잭션 kernel들의 집합이면 블록도 마찬가지라고 할 수 있습니다. 트랜잭션의 출력값을 더할 수 있고 입력값의 합을 뺀다음 그 결과인 Perderson commitment 와 kernal excess와 비교합니다. + + 출력값의 합 - 입력값의 합 = kernel_excess의 합 + +약간 단순화 시켜서 ( 트랜잭션 수수료를 무시하고) 우리는 MimbleWimbl block 이 MimbleWimble 트랜잭션들로 다뤄진다고 말 할 수 있습니다. + +##### Kernel 오프셋들 + +위에 설명했던겉 처럼 MimbleWimble 블록과 트랜잭션에 조그마한 문제가 있습니다. 그것은 블록에 있는 구성 트랜잭션을 재구성하는것이 가능합다는 겁니다.(그리고 어떤 사소한 경우에도요). +이것은 분명히 프라이버시에는 좋지 않습니다. 이걸 "subset" 문제 라고 합니다. +"Subset" 문제란 주어진 입력값들, 출력값들과 트랜잭션 kernel들의 Subset 들이 재조합되어서 유효한 트랜잭션을 다시 만든다는 것입니다. + +예를 들어 다음과 같이 두 트랜잭션이 있다고 해봅시다. + + (in1, in2) -> (out1), (kern1) + (in3) -> (out2), (kern2) + +다음과 같은 블록에 합칠 수 있을겁니다. ( 아니면 트랜잭션을 합쳐도 됩니다.) + + (in1, in2, in3) -> (out1, out2), (kern1, kern2) + +(합계가 0일경우 ) 트랜잭션들 중 하나를 복구하기 위해서 가능한 모든 순열 조합을 조합해보는것은 쉽습니다. + + (in1, in2) -> (out1), (kern1) + +또한 남은 트랜잭션이 다른 유효한 트랜잭션을 만드는데 사용되기도 합니다. + + (in3) -> (out2), (kern2) + +이런것을 완화 시키기 위해 _kernel offset_ 이라는 것을 모든 트랜잭션 kernel 에 포함시킵니다. 실행 값이 0이라는 것을 증명하기 위해 kernel excess 에 더해져야 하는 blinding factor (비밀키)입니다. + + 출력값의 합 - 입력값의 합 = kernel_excess + kernel 오프셋(offset) + +블록 안에서 트랜잭션을 합칠때, _single_ 통합 오프셋(offset)을 블록 헤더에 저장합니다. +그래서 single 오프셋으로 인해 개별 트랜잭션 kernel offset 을 개별로 분리할 수 없고 트랜잭션 들은 더이상 재구성 될 수 없습니다. + + 출력값의 합 - 입력값의 합 = kernel_excess의 합 + kernel_offset + +키 `k`를 트랜잭션 구성 중에 `k1+k2` 안에 나누어서 넣었습니다. 트랜잭션 커널인`(k1+k2)*G` 에 대해 excess 인 `k1*G`와 오프셋(offset) 인 `k2`를 보여주고 이전처럼 `k1*G`로 트랜잭션에 sign 합니다. + +블록을 만드는 동안 블록안의 모든 트랜잭션을 커버하기 위한 한개의 통합 `k` 오프셋을 만들기 위해 `k2`오프셋을 간단히 합할 수 있습니다. `k2`오프셋은 어떤 개별 트랜잭션이 복구되지 못하도록 합니다. + +#### 컷 스루 (Cut-through) + +블록들은 채굴자들이 여러 트랜잭션들을 하나의 세트에 넣고 체인에 더할수 있게 합니다. +다음 블록은 3개의 트랜잭션을 포함하고 있습니다. 오직 입력과 출력만을 보여줍니다. +소비한 출력값은 입력값을 참고 합니다. 출력값은 소문자 x로 표시된 이전 블록을 포함합니다. + + I1(x1) --- O1 + |- O2 + + I2(x2) --- O3 + I3(O2) -| + + I4(O3) --- O4 + |- O5 + +다음과 같은 두가지 성질을 알려드리자면: +* 이 블록 안에서는 어떤 출력값은 포함된 입력값을 바로 사용합니다.(I3는 02를 소비하고 I4는 03을 소비합니다.) +* The structure of each transaction does not actually matter. As all transactions + individually sum to zero, the sum of all transaction inputs and outputs must be zero. + +Similarly to a transaction, all that needs to be checked in a block is that ownership +has been proven (which comes from _transaction kernels_) and that the whole block did +not add any money supply (other than what's allowed by the coinbase). +Therefore, matching inputs and outputs can be eliminated, as their contribution to the overall +sum cancels out. Which leads to the following, much more compact block: + + I1(x1) | O1 + I2(x2) | O4 + | O5 + +Note that all transaction structure has been eliminated and the order of inputs and +outputs does not matter anymore. However, the sum of all outputs in this block, +minus the inputs, is still guaranteed to be zero. + +A block is simply built from: + +* A block header. +* The list of inputs remaining after cut-through. +* The list of outputs remaining after cut-through. +* A single kernel offset to cover the full block. +* The transaction kernels containing, for each transaction: + * The public key `r*G` obtained from the summation of all the commitments. + * The signatures generated using the excess value. + * The mining fee. + +When structured this way, a MimbleWimble block offers extremely good privacy +guarantees: + +* Intermediate (cut-through) transactions will be represented only by their transaction kernels. +* All outputs look the same: just very large numbers that are impossible to + differentiate from one another. If one wanted to exclude some outputs, they'd have + to exclude all. +* All transaction structure has been removed, making it impossible to tell which output + was matched with each input. + +And yet, it all still validates! + +#### Cut-through All The Way +#### 내내 Cut-through 하기 + +Going back to the previous example block, outputs x1 and x2, spent by I1 and +I2, must have appeared previously in the blockchain. + +So after the addition of +this block, those outputs as well as I1 and I2 can also be removed from the +overall chain, as they do not contribute to the overall sum. + +Generalizing, we conclude that the chain state (excluding headers) at any point +in time can be summarized by just these pieces of information: + +1. The total amount of coins created by mining in the chain. +2. The complete set of unspent outputs. +3. The transactions kernels for each transaction. + +The first piece of information can be deduced just using the block +height (its distance from the genesis block). And both the unspent outputs and the +transaction kernels are extremely compact. This has 2 important consequences: + +* The state a given node in a MimbleWimble blockchain needs to maintain is very + small (on the order of a few gigabytes for a bitcoin-sized blockchain, and + potentially optimizable to a few hundreds of megabytes). +* When a new node joins a network building up a MimbleWimble chain, the amount of + information that needs to be transferred is also very small. + +In addition, the complete set of unspent outputs cannot be tampered with, even +only by adding or removing an output. Doing so would cause the summation of all +blinding factors in the transaction kernels to differ from the summation of blinding +factors in the outputs. + + +### 결론 내리기 + +이 문서에서는 MimbleWimble 블록체인 안의 기본적인 원리에 대해서 다루었습니다. +타원 곡선 암호의 다른 성질을 사용해서 알아보기 어려우나 적절하게 입증될 수 있는 트랜잭션을 만들수 있습니다. +블록들에 이러한 성질들을 일반화 시키면 큰 용량의 블록체인 데이터를 없앨 수 있고 새로운 피어들에게 높은 확장성과 빠른 동기화를 가능하게 할 수 있습니다. From 1e873ba70c433360b7fc582a300c4b2dcead2274 Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Tue, 19 Feb 2019 21:31:24 +0900 Subject: [PATCH 19/25] git rm intro.KR.md --- doc/intro.KR.md | 342 ------------------------------------------------ 1 file changed, 342 deletions(-) delete mode 100644 doc/intro.KR.md diff --git a/doc/intro.KR.md b/doc/intro.KR.md deleted file mode 100644 index ed7b277db3..0000000000 --- a/doc/intro.KR.md +++ /dev/null @@ -1,342 +0,0 @@ -# MimbleWimble 과 Grin 에 대한 소개 - -*다른 언어로 Intro를 읽으시려면: [English](intro.md), [简体中文](intro.zh-cn.md), [Español](intro_ES.md), [Русский](intro.ru.md), [日本語](intro.jp.md).* - -MimbleWimlbe은 블록체인 포맷이면서 프로토콜 입니다. -MimbleWimble은 암호학적 기반에 의해서 극대화된 좋은 확장성, 프라이버시, 그리고 대체가능성을 제공합니다. 이러한 특성은 지금 현존하는 모든 블록체인 구현체에 존재하는 문제점들을 처리합니다. - -Grin 은 Mimble Wimble 블록체인을 구현한 오픈소스 프로젝트 입니다. 또한 완전한 블록체인와 크립토 커런시의 배포에 필요한 갭을 채워줍니다. -Grin 프로젝트의 주요 목적과 특성들은 아래 설명을 참고하십시오. - -* 프라이버시가 기본으로 제공됩니다. 이 기능은 필요에 따라서 선택적으로 정보를 공개 할 수 없도록 해서 완전한 대체가능성을 할 수 있게 합니다. -* 주로 유저의 규모와 최소한의 트랜잭션 수의 규모로 (100byte 미만의 kernel(transaction)) 다른 블록체인들과 비교하면 많은 저장공간을 절약할 수 있습니다. -* Mimble Wimble 은 수십년 동안 테스트하고 사용되었던 강력한 암호기술인 ECC만 사용합니다. -* 간단한 디자인은 감사와 유지보수를 시간이 지나도 수월하게 만듭니다. -* 커뮤니티가 주도하며, 채굴 탈중앙화가 권장됩니다. - -## 모두의 혀를 묶자. -이 문서는 블록체인에 대해 어느정도 이해가 있고 암호학에 대한 기본적인 이해가 있는 독자들을 대상으로 합니다. 이것을 염두에 두고 우리는 MimbleWimble의 기술적인 발전과 어떻게 Grin에 적용되었는지 관해 설명 할 것입니다. -저희는 이 문서가 대부분의 기술적인 성격을 가진 독자들을 이해시킬 수 있길 바랍니다. 우리의 목적은 독자가 Grin에 대해 흥미를 느끼게 하고 어떤 방식으로든 Grin에 기여할 수 있게 이끄는 것입니다. -이러한 목적을 이루기 위해, 우리는 MimbleWimble 의 구현체인 Grin을 이해하는데 필요한 주요 컨셉들에 대해서 소개할것입니다. - - 우선 Grin이 어디에서 부터 기초로 하고 있는지에 대해 이해하기 위해서 타원 곡선 암호 (ECC)의 몇몇 속성들에 대한 간단한 설명으로 시작하겠습니다. 그 다음, MimbleWimble 블록체인의 트랜잭션과 블록에 한 모든 요소들을 설명하겠습니다. - -### 타원곡선에 대한 조그마한 조각들 -ECC의 너무 복잡한 사항을 캐지 않고 어떻게 mimble wimble 이 어떻게 작동하는지에 대해 이해하는데 필요한 요소들만 리뷰할 것입니다. 이런 가정들을 좀 더 알고싶은 독자들은 [이 링크](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/)를 참고하세요. - -암호학에서의 타원 곡선이란 우리가 _C_ 라고 부르는 단순히 아주 큰 좌표의 집합입니다. -이 좌표들은 정수들로 (인티저, 또는 스칼라 ) 더하고 빼고 곱할 수 있습니다. - -주어진 정수 _K_ 에 스칼라 곱셈을 한다면 우리는 곡선 _c_ 위에 있는 좌표 K*H를 계산 할 수 있습니다. -또 달리 주어진 정수 _j_ 에 우리는`k*H + j*H` 와 같은 `(k+j)*H`를 계산 할 수 있습니다. - -타원곡선 위에서의 덧셈과 정수 곱셈은 제시된 수의 순서에 관계없이 결과가 동일하다는 성질과 덧셈과 곱셈의 계산 순서와 관계없이 동일한 결과가 나온다는 성질을 가지고 있습니다. - - (k+j)*H = k*H + j*H - -ECC 안에서 우리가 매우 큰 숫자인 _k_ 를 프라이빗 키로 가정할 때 `k*H` 는 해당하는 퍼블릭 키로 해당되어 집니다. 누군가 공개키인 `k*H`의 값을 알더라도 _k_ 를 추론해 내는것은 불가능에 가깝습니다. ( 달리 얘기하자면, 곱셉은 쉬우나 곡선 좌표에 의한 "나눗셈"은 정말 어렵습니다. ) - -_k_ 와 _j_ 둘다 비밀키인 이전 공식 `(k+j)*H = k*H + j*H` 는 두개의 비밀키를 더해서 얻은 한 개의 공개키 (`(k+j)*H`) 와 각각 두개의 비밀키에 공개키를 더한것과 같습니다. Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. MimbleWimble 과 Grin의 구현또한 마찬가지 입니다. - -### MimbleWimble 함께 거래하기 -트랜잭션의 구조는 MimbleWimble의 강력한 프라이버시와 비밀이 유지된다라고 하는 중요한 규칙을 나타냅니다. - -MimbleWimble 트랜잭션의 확인은 두가지 기본적인 성격을 전제로 합니다. - -* **제로섬의 검증:** 결과값에서 입력값을 뺸 합은 항상 0과 같습니다. 이것은 실제 전송되는 코인의 양을 드러내지 않고도 트랜잭션ㅇ이 새로운 코인을 만들지 않았다는 것을 증명합니다. -* **비밀키의 소유:** 다른 많은 크립토 커런시 들처럼 , 트랜잭션의 소유권은 ECC 비밀키에 의해 보장됩니다. 그러나 어떤 실체가 이런 비밀키들을 소유하고 있다고 증명하는것이 직접적으로 트랜잭션에 사인한다고해서 얻어지는 것은 아닙니다. - -다음 섹션들에서는 잔고, 소유권, 거스름돈과 증명들의 상세들이 어떻게 저 두가지 기본적인 성질에 의해서 얻어지는지 알아보겠습니다. - -#### 잔고 -위에서 언급한 ECC의 특성들을 기반으로 해서 트랜잭션안의 가치들을 보기 어렵게 할 수 있습니다. -만약 _v_ 가 트랜잭션 입력값이거나 출력값이고 _H_ 가 타원곡선이라면 , 단순히 _v_ 대신 `v*H`를 끼워 넣을 수 있습니다. - -이것은 ECC를 사용하기 때문에 작동하는 것입니다. 우리는 출력값의 합이 입력값의 합과 같다는 것을 여전히 확인할 수 있습니다. - - v1 + v2 = v3 => v1*H + v2*H = v3*H - -이 특성을 모든 트랜잭션에 확인하는것은 프로토콜이 트랜잭션은 돈을 난데없이 만들지 않는다는 것을 실제 돈이 얼마나 있는지 알지 않아도 검증할 수 있게 합니다. -그러나 사용가능한 한정된 숫자가 있고 그 숫자 중 하나를 사용해서 당신의 트랜잭션이 얼마만큼의 코인을 가졌는지 추측 할 수 있습니다. 더해서, v1을 알고 ( 예시로 사용된 이전의 트랜잭션에서 온 값 ) 그에따른 `v1*H`의 결과를 알면 블록체인 전체에 걸쳐서 v1 값이 있는 모든 출력값들이 드러나게 됩니다. - -이러한 이유로 두번째 타원곡선인 _G_ 를 제시합니다. ( 실제로 _G_ 는 _H_ 의 그룹과 같은 곡선에 있으며 단지 다른 좌표를 생성해 냅니다.) 그리고 비밀키 _r_ 은 *blinding factor* 로 사용됩니다. - -그렇다면 트랜잭션 안의 입력값과 출력값은 다음과 같이 표현됩니다. - - r*G + v*H - -여기서 - -* _r_ 은 비밀키이고 blinding factor 로 사용됩니다. _G_ 는 타원 곡선 이고 `r*G`는 _G_ 안에 있는 _r_ 의 공개키 입니다. -* _v_ 는 출력값이거나 입력값이고 _H_ 는 다른 타원곡선입니다.타원곡선의 근본적인 특성을 이용했기 때문에 _v_ 와 _r_ 은 추측될 수 없습니다. `r*G + v*H`를 _Pedersen Commitment_ 라고 부릅니다. - -예를 들어 , ( 전송료는 무시하고) 두개의 입력값과 한개의 출력값으로 트랜잭션을 만들기 원한다고 가정해봅시다. - -* vi1 과 v2 는 출력값 -* vo3는 출력값 이라면 - -그렇다면 - - vi1 + vi2 = vo3 - -입니다. - -각각의 입력값에 대해서 blining factor 로 비밀키를 만들고 각각의 값을 각각의 이전의 공식에 있던 Pederson Commitment로 교체한다고 하면 다음과 같습니다. - - (ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vo3*H) - -결과로 다음과 같습니다. - - ri1 + ri2 = ro3 - -이것이 MimbleWimble의 첫번째 특징입니다. 트랜잭션을 검증하는 산술적인 연산은 아무런 값을 알지 못해도 가능합니다. - -이 아이디어는 Greg Maxwell 의 [Confidential Transactions](https://elementsproject.org/features/confidential-transactions/investigation) 에서 유래했습니다. Confidential transaction은 Adam back의 비트코인에 동형암호를 적용하자는 제안에서 비롯되었습니다. - -#### 소유권 - -이전의 섹션에서 트랜잭션의 값을 보기 어렵게 하는 Blinding factor로서 비밀키를 소개했습니다. MimbleWimble 의 두번째 통찰은 비밀키가 어떤 값의 소유권을 증명하는데 사용할 수 있다는 것입니다. - -Alice는 당신에게 3 코인을 보내면서 그 양을 가렸고, 당신은 28을 당신의 blinding factor로 선택했습니다. ( 실제로 blinding factor는 비밀키로 정말 무진장 큰 숫자 입니다.) - -블록체인 어딘가에 다음과 같은 출력값이 나타나 있고 당신에 의해서만 소비될 수 있습니다. - - X = 28*G + 3*H - -_X_ 는 덧셈의 결과이면서 모두에게 다 보여집니다. 3은 당신과 Alice만 알고 있고 28은 당신만이 알고 있습니다. - -다시 3코인을 보내기 위해선, 프로토콜은 어떻게든 28을 알고 있어야 됩니다. 어떻게 이것이 작동하는지 보기 위해서, 당신이 캐롤에게 같은 3코인을 보내고 싶어한다고 합시다. 그렇다면 당신은 아래와 같은 간단한 트랜잭션을 작성해야 합니다. - - Xi => Y - -여기서 _Xi_는 _X_ 출력을 사용하는 입력이고 Y는 Carol의 출력입니다. -당신의 비밀키인 28을 모르고서는 트랜잭션과 잔액을 만들 수 있는 방법이 없습니다. - -실제로 캐롤이 이 트랜잭션의 잔액을 위해선 그녀는 받는 값과 당신의 비밀키를 알아야 합니다. - -그러므로 - - Y - Xi = (28*G + 3*H) - (28*G + 3*H) = 0*G + 0*H - -입니다. - -모든계산이 0으로 되었는지 확인함으로써, 새로운 돈이 만들어지지 않았다는 것을 확인할 수 있습니다. -오 잠시만요! 당신은 지금 캐롤의 출력값에 비밀키가 있다는것을 알았습니다. ( 이런경우에는 당신의 잔액이 나간것과 동일 해야 합니다.) 그리고 당신은 캐롤로 부터 돈을 훔칠수 있습니다. 이걸 해결하기위해서 캐롤은 그녀가 선택한 비밀키를 사용합니다. - -캐롤이 113을 비밀키로 선택했다면 블록체인 안에서는 아래와 같이 마무리 됩니다. - - Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H - -모든 blinding factor합계 결과로 타원곡선 _G_ 위에서 트랜잭션은 _초과값_ (85) 을 가지게 되고 트랜잭션의 합은 더이상 0 이 아닙니다. - -그러나 `85*G` 은 비밀키 85 와 함께 타원곡선 _G_ 에서 유효한 공개키이기 때문에 모든 x와 y는 `y = 0`가 `x*G + y*H`일때 곡선 _G_ 에서 유효한 공개키입니다. - -그러므로 모든 프로토콜은 (`Y - Xi`) 가 _G_위에서 유효한 공개키인지 ,거래당사자들이 비밀키를 알고있는지 ( 캐롤과의 트랜잭션에서는 85) 를 검증해야 할 필요가 있습니다. 가장 간단하게 검증하는 방법은 Signature가 초과값과 함께 만들어졌다는 것을 요구한 다음 아래와 같은것을 인증하는 겁니다. - -* 거래하는 당사자들은 모두 비밀키를 알고 있고 -* 트랜잭션의 입력값을 뺀 출력값들의 합은 0입니다. ( 왜냐하면 비밀키와 매칭된 유효한 공개키만 Signature 를 체크할 것이기 때문입니다. ) - -모든 트랜잭션에 포함된 이 Signature 는 덧붙여진 어떤 데이터와 함께(채굴 수수료와 같은 데이터) _transaction kernel_ 이라고 부르고 모든 Validator 에 의해 체크됩니다. - -#### 몇몇 더 좋은 점들 - -이 섹션은 트랜잭션을 만들때 잔돈이 어떻게 보여지고 범위 증명(range proofs)의 요구사항에 대해서 모든 값이 음수가 아닌지에 대해서 좀 더 자세하게 설명하려고 합니다. 이러한 개념들 역시 MimbleWimble 과 Grin 에 대한 이해가 당연히 필요합니다. 만약 당신이 조급하다면 [이 링크를 참고하세요.](#putting-it-all-together). - -##### 잔돈에 대해서 - -캐롤에게 2개의 코인을 보내고 3개를 앨리스에게서 받는다고 해봅시다.이렇게 하려면 당신은 남은 1개의 코인을 잔돈으로 당신에게 돌려줘야 합니다. 이때, 다른 비밀키를 blinding factor 로 만들어서 (12라고 합시다.) 출력값을 보호해야 합니다. 캐롤은 이전에 썻던 그녀의 비밀키를 씁니다. - - 잔돈의 출력값 : 12*G + 1*H - 캐롤의 출력값 : 113*G + 2*H - -블록체인 안에서의 결과는 예전과 매우 흡사합니다. 그리고 Signature 은 초과되는 값과 함께 다시 만들어질겁니다. 이 예시에서는 97이라고 합시다. - - (12*G + 1*H) + (113*G + 2*H) - (28*G + 3*H) = 97*G + 0*H - -##### Range Proofs - -위의 모든 계산에서 트랜잭션의 값들은 항상 양의(+)값입니다. 음의 값은 모든 트랜잭션마다 새로운 돈을 만들수 있다는 것이므로 매우 문제점이 될겁니다. - -예를 들어 입력값이 3이고 출력값이 5과 -3인 트랜잭션을 만들수 있으며 이것은 이전 섹션의 정의에 따라 잘 구성된 트랜잭션입니다. 적절한 좌표 `x.H`가 다른 좌표처럼 곡선위에 있어서 _x_가 음수이더라도 찾기가 쉽지 않습니다. - -이 문제점을 해결하기 위해서, MimbleWimble 은 Range proofs 라는 다른 암호학 개념을 사용합니다. ( 이 또한 Confidential Transaction 에서 유래했습니다.) -Range proof 란 숫자를 밝히지 않고 어떤 숫자가 주어진 범위안에 있는지 증명하는 것입니다. -Range proof 에 대해서 자세히 설명하지 않을것이지만은, 그래도 어떤 `r.G + v.H` 의 결과가 _v_ 가 0보다 크고 오버플로우가 일어나지 않는다는 것을 증명할 수 있습니다. 또한 위의 예에서 유효한 Range proof 를 만들기 위해서 트랜잭션을 만들고 Signing 할때 사용된 초과값인 113과 28 두 값이 알려지는것은 중요합니다. 그 이유에 대해선 [range proof paper](https://eprint.iacr.org/2017/1066.pdf) 안에 Range proof에 대해 좀더 자세한 설명이 있습니다. - -#### 모든것을 함깨 놓고 이해하기 - -MimbleWimlbe 트랜잭션은 다음을 포함합니다. - -* 이전의 출력값들이 참조하고 사용한 입력값의 셋트들 -* 새로운 출력값들은 다음을 포함합니다. - * 곡선위에서 `r.G + v.H` 로 합해 지는 값 과 blinding factor (그냥 새로운 비밀 키). - * v 가 음수가 아님을 보여주는 Range proof. -* 분명히 명시된 트랜잭션 수수료 -* 수수료가 더해진 모든 출력밧에서 입력값을 뺸 초과 blinding 값이 계산되고 그것이 비밀키로 사용된 Signature. - -### 블록들과 체인 state에 대해서 - -위에서 MimbleWimble 트랜잭션이 유요한 블록체인에 필요한 속성을 유지하면서 어떻게 강한 익명성을 보장하는지 설명했습니다.예를 들면 트랜잭션이 더이상 코인을 만들지 않으면서 비밀키를 통해 소유권을 증명하지 않는 방법들 같은것 말이죠. - -추가적으로 _cut-through_ 라는 개념이 MimbleWimble 블록 포멧에 사용 됩니다. 이로 인해 MimbleWimble 체인은 아래와 같은 장점을 얻습니다. - -* 대부분의 트랜잭션 데이터는 보안을 희생하지 않고서도 시간이 지나면 없어 질 수 있으므로 엄청나게 좋은 확장성을 얻게 됩니다. -* 트랜잭션 데이터를 섞고 없애서 익명성을 추가로 획득합니다. -* 새로운 노드가 네트웍에서 동기화를 이룰때 매우 효과적입니다. - -#### 트랜잭션 합치기 - -트랜잭션은 다음와 같은것들로 이뤄져 있다는걸 상기해봅시다. - -* 이전의 출력값들이 참조하고 사용한 입력값의 셋트들 -* 새로운 출력값의 세트들 ( Pederson commitment) -* kernal execess와 (kernel 초과값이 공개키로 사용된) 트랜잭션 Signature로 이뤄진 트랜잭션 Kernel. - -sign 된 트랜잭션과 Signature 은 _transaction kernel_ 에 포함됩니다. -Signature 공개키로서 트랜잭션의 합이 0임을 증명하는 _kernel excess_ 를 이용해서 생성됩니다. - - (42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H - -이번 예시에서 공개키는 `28*G` 입니다. - -다음은 어떠한 유효한 트랜잭션에서도 참이라고 말 할 수 있습니다. (단순함을 위해 수수료는 무시합니다. ) - - 출력값의 합 - 입력값의 합 = kernel_excess - -블록이 입력값과 출력값의 합 그리고 트랜잭션 kernel들의 집합이면 블록도 마찬가지라고 할 수 있습니다. 트랜잭션의 출력값을 더할 수 있고 입력값의 합을 뺀다음 그 결과인 Perderson commitment 와 kernal excess와 비교합니다. - - 출력값의 합 - 입력값의 합 = kernel_excess의 합 - -약간 단순화 시켜서 ( 트랜잭션 수수료를 무시하고) 우리는 MimbleWimbl block 이 MimbleWimble 트랜잭션들로 다뤄진다고 말 할 수 있습니다. - -##### Kernel 오프셋들 - -위에 설명했던겉 처럼 MimbleWimble 블록과 트랜잭션에 조그마한 문제가 있습니다. 그것은 블록에 있는 구성 트랜잭션을 재구성하는것이 가능합다는 겁니다.(그리고 어떤 사소한 경우에도요). -이것은 분명히 프라이버시에는 좋지 않습니다. 이걸 "subset" 문제 라고 합니다. -"Subset" 문제란 주어진 입력값들, 출력값들과 트랜잭션 kernel들의 Subset 들이 재조합되어서 유효한 트랜잭션을 다시 만든다는 것입니다. - -예를 들어 다음과 같이 두 트랜잭션이 있다고 해봅시다. - - (in1, in2) -> (out1), (kern1) - (in3) -> (out2), (kern2) - -다음과 같은 블록에 합칠 수 있을겁니다. ( 아니면 트랜잭션을 합쳐도 됩니다.) - - (in1, in2, in3) -> (out1, out2), (kern1, kern2) - -(합계가 0일경우 ) 트랜잭션들 중 하나를 복구하기 위해서 가능한 모든 순열 조합을 조합해보는것은 쉽습니다. - - (in1, in2) -> (out1), (kern1) - -또한 남은 트랜잭션이 다른 유효한 트랜잭션을 만드는데 사용되기도 합니다. - - (in3) -> (out2), (kern2) - -이런것을 완화 시키기 위해 _kernel offset_ 이라는 것을 모든 트랜잭션 kernel 에 포함시킵니다. 실행 값이 0이라는 것을 증명하기 위해 kernel excess 에 더해져야 하는 blinding factor (비밀키)입니다. - - 출력값의 합 - 입력값의 합 = kernel_excess + kernel 오프셋(offset) - -블록 안에서 트랜잭션을 합칠때, _single_ 통합 오프셋(offset)을 블록 헤더에 저장합니다. -그래서 single 오프셋으로 인해 개별 트랜잭션 kernel offset 을 개별로 분리할 수 없고 트랜잭션 들은 더이상 재구성 될 수 없습니다. - - 출력값의 합 - 입력값의 합 = kernel_excess의 합 + kernel_offset - -키 `k`를 트랜잭션 구성 중에 `k1+k2` 안에 나누어서 넣었습니다. 트랜잭션 커널인`(k1+k2)*G` 에 대해 excess 인 `k1*G`와 오프셋(offset) 인 `k2`를 보여주고 이전처럼 `k1*G`로 트랜잭션에 sign 합니다. - -블록을 만드는 동안 블록안의 모든 트랜잭션을 커버하기 위한 한개의 통합 `k` 오프셋을 만들기 위해 `k2`오프셋을 간단히 합할 수 있습니다. `k2`오프셋은 어떤 개별 트랜잭션이 복구되지 못하도록 합니다. - -#### 컷 스루 (Cut-through) - -블록들은 채굴자들이 여러 트랜잭션들을 하나의 세트에 넣고 체인에 더할수 있게 합니다. -다음 블록은 3개의 트랜잭션을 포함하고 있습니다. 오직 입력과 출력만을 보여줍니다. -소비한 출력값은 입력값을 참고 합니다. 출력값은 소문자 x로 표시된 이전 블록을 포함합니다. - - I1(x1) --- O1 - |- O2 - - I2(x2) --- O3 - I3(O2) -| - - I4(O3) --- O4 - |- O5 - -다음과 같은 두가지 성질을 알려드리자면: -* 이 블록 안에서는 어떤 출력값은 포함된 입력값을 바로 사용합니다.(I3는 02를 소비하고 I4는 03을 소비합니다.) -* The structure of each transaction does not actually matter. As all transactions - individually sum to zero, the sum of all transaction inputs and outputs must be zero. - -Similarly to a transaction, all that needs to be checked in a block is that ownership -has been proven (which comes from _transaction kernels_) and that the whole block did -not add any money supply (other than what's allowed by the coinbase). -Therefore, matching inputs and outputs can be eliminated, as their contribution to the overall -sum cancels out. Which leads to the following, much more compact block: - - I1(x1) | O1 - I2(x2) | O4 - | O5 - -Note that all transaction structure has been eliminated and the order of inputs and -outputs does not matter anymore. However, the sum of all outputs in this block, -minus the inputs, is still guaranteed to be zero. - -A block is simply built from: - -* A block header. -* The list of inputs remaining after cut-through. -* The list of outputs remaining after cut-through. -* A single kernel offset to cover the full block. -* The transaction kernels containing, for each transaction: - * The public key `r*G` obtained from the summation of all the commitments. - * The signatures generated using the excess value. - * The mining fee. - -When structured this way, a MimbleWimble block offers extremely good privacy -guarantees: - -* Intermediate (cut-through) transactions will be represented only by their transaction kernels. -* All outputs look the same: just very large numbers that are impossible to - differentiate from one another. If one wanted to exclude some outputs, they'd have - to exclude all. -* All transaction structure has been removed, making it impossible to tell which output - was matched with each input. - -And yet, it all still validates! - -#### Cut-through All The Way -#### 내내 Cut-through 하기 - -Going back to the previous example block, outputs x1 and x2, spent by I1 and -I2, must have appeared previously in the blockchain. - -So after the addition of -this block, those outputs as well as I1 and I2 can also be removed from the -overall chain, as they do not contribute to the overall sum. - -Generalizing, we conclude that the chain state (excluding headers) at any point -in time can be summarized by just these pieces of information: - -1. The total amount of coins created by mining in the chain. -2. The complete set of unspent outputs. -3. The transactions kernels for each transaction. - -The first piece of information can be deduced just using the block -height (its distance from the genesis block). And both the unspent outputs and the -transaction kernels are extremely compact. This has 2 important consequences: - -* The state a given node in a MimbleWimble blockchain needs to maintain is very - small (on the order of a few gigabytes for a bitcoin-sized blockchain, and - potentially optimizable to a few hundreds of megabytes). -* When a new node joins a network building up a MimbleWimble chain, the amount of - information that needs to be transferred is also very small. - -In addition, the complete set of unspent outputs cannot be tampered with, even -only by adding or removing an output. Doing so would cause the summation of all -blinding factors in the transaction kernels to differ from the summation of blinding -factors in the outputs. - - -### 결론 내리기 - -이 문서에서는 MimbleWimble 블록체인 안의 기본적인 원리에 대해서 다루었습니다. -타원 곡선 암호의 다른 성질을 사용해서 알아보기 어려우나 적절하게 입증될 수 있는 트랜잭션을 만들수 있습니다. -블록들에 이러한 성질들을 일반화 시키면 큰 용량의 블록체인 데이터를 없앨 수 있고 새로운 피어들에게 높은 확장성과 빠른 동기화를 가능하게 할 수 있습니다. From ea7c2b1dced8e6f1d6f03644f939e29349bb049f Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Tue, 19 Feb 2019 22:49:02 +0900 Subject: [PATCH 20/25] finish translate intro.md to intro_KR.md --- doc/intro_KR.md | 88 ++++++++++++++++++------------------------------- 1 file changed, 32 insertions(+), 56 deletions(-) diff --git a/doc/intro_KR.md b/doc/intro_KR.md index ed7b277db3..cd42d8d6cd 100644 --- a/doc/intro_KR.md +++ b/doc/intro_KR.md @@ -262,81 +262,57 @@ Signature 공개키로서 트랜잭션의 합이 0임을 증명하는 _kernel ex 다음과 같은 두가지 성질을 알려드리자면: * 이 블록 안에서는 어떤 출력값은 포함된 입력값을 바로 사용합니다.(I3는 02를 소비하고 I4는 03을 소비합니다.) -* The structure of each transaction does not actually matter. As all transactions - individually sum to zero, the sum of all transaction inputs and outputs must be zero. - -Similarly to a transaction, all that needs to be checked in a block is that ownership -has been proven (which comes from _transaction kernels_) and that the whole block did -not add any money supply (other than what's allowed by the coinbase). -Therefore, matching inputs and outputs can be eliminated, as their contribution to the overall -sum cancels out. Which leads to the following, much more compact block: +* 실제로 각 트랜잭션의 구조는 문제가 아닙니다. 모든 트랜잭션들의 개개의 합계가 0이듯이 모든 트랜잭션의 입력값과 출력값이 0이여야만 합니다. +트랜잭션과 비슷하게 블록에서 체크해야 되는 것은 _transaction kernels_ 에서 비롯되는 소유권의 증명과 coinbase 에서 증가하는 코인 외 모든 블록이 돈의 공급을 추가하지 않았다는 것입니다. +매칭된 값은 전체의 값을 상쇄하므로 매치되는 입력값과 출력값은 없앨 수 있고 다음과 같이 좀 더 작은 블록이 됩니다. + I1(x1) | O1 I2(x2) | O4 | O5 -Note that all transaction structure has been eliminated and the order of inputs and -outputs does not matter anymore. However, the sum of all outputs in this block, -minus the inputs, is still guaranteed to be zero. +모든 트랜잭션 구조는 다 제거되었고 입력값과 출력값의 순서는 더이상 중요하지 않습니다. +그러나 블록에서 입력값을 뺸 모든 출력값의 합은 여전히 0임을 보증합니다. -A block is simply built from: +블록은 아래와 간단히 말하자면 아래를 포함합니다. -* A block header. -* The list of inputs remaining after cut-through. -* The list of outputs remaining after cut-through. -* A single kernel offset to cover the full block. -* The transaction kernels containing, for each transaction: +* 블록헤더 +* 컷 스루 이후 남은 입력값의 리스트 +* 컷 스루 이후 남은 출력값의 리스트 +* 모든 블록을 커버하기 위한 단일 kernel offset +* 트랜잭션 kernel들은 각 트랜잭션에 아래와 같은 것들을 포함합니다. * The public key `r*G` obtained from the summation of all the commitments. - * The signatures generated using the excess value. - * The mining fee. - -When structured this way, a MimbleWimble block offers extremely good privacy -guarantees: + * 모든 커밋들의 합을 포함한 공개키 `r*G` + * 초과값 (excess value) 을 이용해 생성된 Signature + * 채굴 수수료 -* Intermediate (cut-through) transactions will be represented only by their transaction kernels. -* All outputs look the same: just very large numbers that are impossible to - differentiate from one another. If one wanted to exclude some outputs, they'd have - to exclude all. -* All transaction structure has been removed, making it impossible to tell which output - was matched with each input. +이런 방법으로 구조가 만들어진다면 MimbleWimblw 블록은 엄청나게 좋은 프라이버시를 보장할 수 있습니다. -And yet, it all still validates! +* 중간 트랜잭션 ( 컷 스루 트랜잭션) 은 트랜잭션 kernel에서만 표시될것 입니다. +* 모든 출력값은 똑같이 보일것입니다. 출력값은 다른 것과 구분하기 블가능한 아주 큰 숫자일겁니다. 만약 하나를 다른 출력값에서 제외하려면 모든 출력값을 제외해야 합니다. +* 모든 트랜잭션 구조는 지워지고 출력값이 각 입력값과 매치된다고 말하기엔 불가능 해집니다. -#### Cut-through All The Way -#### 내내 Cut-through 하기 +그리고 아직까진 모든게 유효합니다! -Going back to the previous example block, outputs x1 and x2, spent by I1 and -I2, must have appeared previously in the blockchain. - -So after the addition of -this block, those outputs as well as I1 and I2 can also be removed from the -overall chain, as they do not contribute to the overall sum. +#### 모두 컷 스루( Cut-through ) 하기 + +이전 예시의 블록으로 돌아가서 출력값인 x1,과 x2는 I1과 I2에 대해서 사용되고 이것은 반드시 이전 블록체인 안에서 나타나야 합니다. 이 블록이 추가된 이후에 I1과 I2 과 출력값들은 전체 합계에 영향을 주지 않으므로 모든 체인에서 지워 질 수 있습니다. -Generalizing, we conclude that the chain state (excluding headers) at any point -in time can be summarized by just these pieces of information: +일반화 하자면, 헤더를 제외하고 어떤 시점에서든 체인의 스테이트는 다음과 같은 정보로 요약될 수 있습니다. -1. The total amount of coins created by mining in the chain. -2. The complete set of unspent outputs. -3. The transactions kernels for each transaction. -The first piece of information can be deduced just using the block -height (its distance from the genesis block). And both the unspent outputs and the -transaction kernels are extremely compact. This has 2 important consequences: +1. 체인안에서 채굴에 의해서 만들어진 코인의 총량 +2. 쓰지 않은 출력값의 모든 세트 +3. 각 트랜잭션의 트랜잭션 kernel -* The state a given node in a MimbleWimble blockchain needs to maintain is very - small (on the order of a few gigabytes for a bitcoin-sized blockchain, and - potentially optimizable to a few hundreds of megabytes). -* When a new node joins a network building up a MimbleWimble chain, the amount of - information that needs to be transferred is also very small. +첫번째 정보는 Genesis 블록으로부터의 거리인 블록 높이를 가지고 유추 될 수 있습니다. 그리고 쓰지 않는 출력값과 트랜잭션 kernel은 매우 작습니다. 이것에는 아래와 같이 2가지 중요한 결과를 가지고 있습니다. -In addition, the complete set of unspent outputs cannot be tampered with, even -only by adding or removing an output. Doing so would cause the summation of all -blinding factors in the transaction kernels to differ from the summation of blinding -factors in the outputs. +* MimbleWimble 블록체인에 있는 노드가 유지해야 되는 스테이트가 매우 작습니다.(비트코인 사이즈의 Blockchain의 경우 수 기가 바이트이고 잠재젹으로 수백 메가바이트까지 최적화 될 수 있습니다.) +* 새로운 노드가 MimbleWimble 체인에 가입히면, 전달해야 하는 정보의 양이 매우 적습니다. +덧붙여서 출력값을 더하거나 제거하더라도 쓰지 않는 출력값의 모든 세트를 조작할 순 없습니다. 그렇게 하면 트랜잭션 kernel 내의 모든 blinding factor의 합과 출력값 내의 blinding factor의 합이 달라집니다. ### 결론 내리기 이 문서에서는 MimbleWimble 블록체인 안의 기본적인 원리에 대해서 다루었습니다. -타원 곡선 암호의 다른 성질을 사용해서 알아보기 어려우나 적절하게 입증될 수 있는 트랜잭션을 만들수 있습니다. -블록들에 이러한 성질들을 일반화 시키면 큰 용량의 블록체인 데이터를 없앨 수 있고 새로운 피어들에게 높은 확장성과 빠른 동기화를 가능하게 할 수 있습니다. +타원 곡선 암호의 다른 성질을 사용해서 알아보기 어려우나 적절하게 입증될 수 있는 트랜잭션을 만들수 있습니다. 블록에 이러한 성질들을 일반화 시키면 큰 용량의 블록체인 데이터를 없앨 수 있고 새로운 피어들에게 높은 확장성과 빠른 동기화를 가능하게 할 수 있습니다. From 1f495a77c1a9588b2abab5f84099abd203b5a09e Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Tue, 19 Feb 2019 22:53:59 +0900 Subject: [PATCH 21/25] add intro_KR.md file path each language's intro.md --- doc/intro.md | 146 +++++++++++++-------------------------------- doc/intro_DE.md | 2 +- doc/intro_ES.md | 2 +- doc/intro_JP.md | 2 +- doc/intro_KR.md | 6 +- doc/intro_NL.md | 2 +- doc/intro_PT-BR.md | 2 +- doc/intro_RU.md | 2 +- doc/intro_SE.md | 2 +- doc/intro_ZH-CN.md | 2 +- 10 files changed, 52 insertions(+), 116 deletions(-) diff --git a/doc/intro.md b/doc/intro.md index 4ae0753329..973b4ba44c 100644 --- a/doc/intro.md +++ b/doc/intro.md @@ -1,219 +1,155 @@ # Introduction to MimbleWimble and Grin -*Read this in other languages: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md).* +*Read this in other languages: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).* MimbleWimble is a blockchain format and protocol that provides extremely good scalability, privacy and fungibility by relying on strong cryptographic primitives. It addresses gaps existing in almost all current blockchain implementations. -MimbleWimlbe은 블록체인 포맷이면서 프로토콜 입니다. -MimbleWimble 은 암호학적 기반에 의해서 극대화된 좋은 확장성, 프라이버시, 그리고 대체가능성을 제공합니다. -이러한 특성은 지금 현존하는 모든 블록체인 구현체에 존재하는 문제점들을 처리합니다. - Grin is an open source software project that implements a MimbleWimble blockchain and fills the gaps required for a full blockchain and cryptocurrency deployment. -Grin 은 Mimble Wimble 블록체인을 구현한 오픈소스 프로젝트 입니다. -또한 완전한 블록체인와 크립토 커런시의 배포에 필요한 갭을 채워줍니다. - The main goal and characteristics of the Grin project are: -Grin 프로젝트의 주요 목적과 특성들은 아래 설명을 참고하십시오. * Privacy by default. This enables complete fungibility without precluding the ability to selectively disclose information as needed. -* 프라이버시가 기본으로 제공됩니다. 이 기능은 필요에 따라서 선택적으로 정보를 공개 할 수 없도록 해서 완전한 대체가능성을 할 수 있게 합니다. * Scales mostly with the number of users and minimally with the number of transactions (<100 byte `kernel`), resulting in a large space saving compared to other blockchains. -* 주로 유저의 규모와 최소한의 트랜잭션 수의 규모로 (100byte 미만의 kernel(transaction)) 다른 블록체인들과 비교하면 많은 공간을 절약할 수 있습니다. * Strong and proven cryptography. MimbleWimble only relies on Elliptic Curve Cryptography which has been tried and tested for decades. -* Mimble Wimble 은 수십년 동안 테스트하고 사용되었던 강력한 암호기술인 ECC만 사용합니다. * Design simplicity that makes it easy to audit and maintain over time. -* 간단한 디자인은 감사와 유지보수를 시간이 지나도 수월하게 만듭니다. * Community driven, encouraging mining decentralization. -* 커뮤니티가 주도하며, 채굴 탈중앙화가 권장됩니다. - -## Tongue Tying for Everyone -## 모두의 혀를 묶자. -This document is targeted at readers with a good understanding of blockchains and basic cryptography. -이 문서는 블록체인에 대해 어느정도 이해가 있고 암호학에 대한 기본적인 이해가 있는 독자들을 대상으로 합니다. - -With that in mind, we attempt to explain the technical buildup of MimbleWimble and how it's applied in Grin. -이것을 염두에 두고 우리는 MimbleWimble의 기술적인 발전과 어떻게 Grin에 적용되었는지 관해 설명할것입니다. +## Tongue Tying for Everyone -We hope this document is understandable to most technically-minded readers. Our objective is +This document is targeted at readers with a good +understanding of blockchains and basic cryptography. With that in mind, we attempt +to explain the technical buildup of MimbleWimble and how it's applied in Grin. We hope +this document is understandable to most technically-minded readers. Our objective is to encourage you to get interested in Grin and contribute in any way possible. -저희는 이 문서가 대부분의 기술적인 성격을 가진 독자들을 이해시킬 수 있길 바랍니다. -우리의 목적은 독자가 Grin에 대해 흥기를 느끼게 하고 어떤 방식으로든 Grin에 기여할 수 있게 이끄는 것입니다. - -To achieve this objective, we will introduce the main concepts required for a good understanding of Grin as a MimbleWimble implementation. -이러한 목적을 이루기 위해, 우리는 MimbleWimble 의 구현체인 Grin을 이해하는데 필요한 주요 컨셉들에 대해서 소개할것입니다. -We will start with a brief description of some relevant properties of Elliptic Curve Cryptography (ECC) to lay the foundation on which Grin is based and then describe all the key elements of a MimbleWimble blockchain's transactions and blocks. -우선 Grin이 어디에서 부터 기초로 하고 있는지에 대해 이해하기 위해서 타원 곡선 암호 (ECC)의 몇몇 속성들에 대한 간단한 설명으로 시작하겠습니다. 그 다음, MimbleWimble 블록체인의 트랜잭션과 블록에 한 모든 요소들을 설명하겠습니다. +To achieve this objective, we will introduce the main concepts required for a good +understanding of Grin as a MimbleWimble implementation. We will start with a brief +description of some relevant properties of Elliptic Curve Cryptography (ECC) to lay the +foundation on which Grin is based and then describe all the key elements of a +MimbleWimble blockchain's transactions and blocks. ### Tiny Bits of Elliptic Curves -### 타원곡선에 대한 조그마한 조각들 - We start with a brief primer on Elliptic Curve Cryptography, reviewing just the properties necessary to understand how MimbleWimble works and without -delving too much into the intricacies of ECC. - -- ECC의 너무 복잡한 사항을 캐지 않고 어떻게 mimble wimble 이 어떻게 작동하는지에 대해 이해하는데 필요한 요소들만 리뷰할 것입니다. - - For readers who would want to dive deeper into those assumptions, there are other opportunities to [learn more](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/). -- 이런 가정들을 좀 더 알고싶은 독자들은 [이 링크](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/) 를 참고하세요. +delving too much into the intricacies of ECC. For readers who would want to +dive deeper into those assumptions, there are other opportunities to +[learn more](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/). An Elliptic Curve for the purpose of cryptography is simply a large set of points that we will call _C_. These points can be added, subtracted, or multiplied by integers (also called scalars). -암호학에서의 타원 곡선이란 우리가 _C_ 라고 부르는 단순히 아주 큰 좌표의 집합입니다. -이 좌표들은 정수들로 (인티저, 또는 스칼라 ) 더하고 빼고 곱할수 있습니다. - -Given an integer _k_ and using the scalar multiplication operation we can compute `k*H`, which is also a point on curve _C_. -주어진 정수 _K_ 에 스칼라 곱셈을 한다면 우리는 곡선 _c_ 위에 있는 좌표 K*H를 계산 할 수 있습니다. - -Given another integer _j_ we can also calculate `(k+j)*H`, which equals `k*H + j*H`. -또 달리 주어진 정수 _j_ 에 우리는`k*H + j*H` 와 같은 `(k+j)*H`를 계산 할 수 있습니다. - -The addition and scalar multiplication operations on an elliptic curve maintain the commutative and associative properties of addition and multiplication: -타원곡선 위에서의 덧셈과 정수 곱셈은 제시덴 수의 순서에 관계없이 결과가 동일하다는 성질과 덧셈과 곱셈의 계산 순서와 관계없이 동일한 결과가 나온다는 성질을 가지고 있습니다. +Given an integer _k_ and +using the scalar multiplication operation we can compute `k*H`, which is also a point on +curve _C_. Given another integer _j_ we can also calculate `(k+j)*H`, which equals +`k*H + j*H`. The addition and scalar multiplication operations on an elliptic curve +maintain the commutative and associative properties of addition and multiplication: (k+j)*H = k*H + j*H In ECC, if we pick a very large number _k_ as a private key, `k*H` is -considered the corresponding public key. -ECC 안에서 우리가 매우 큰 숫자인 _k_ 를 프라이빗 키로 가정할 때 `k*H` 는 해당하는 퍼블릭 키로 해당되어 집니다. - -Even if one knows the value of the public key `k*H`, deducing _k_ is close to impossible (or said differently, while multiplication is trivial, "division" by curve points is +considered the corresponding public key. Even if one knows the +value of the public key `k*H`, deducing _k_ is close to impossible (or said +differently, while multiplication is trivial, "division" by curve points is extremely difficult). -누군가 공개키인 `k*H`의 값을 알더라도 _k_ 를 추론해 내는것은 불가능에 가깝습니다. ( 달리 얘기하자면, 곱셉은 쉬우나 곡선 좌표에 의한 "나눗셈"은 정말 어렵습니다. ) The previous formula `(k+j)*H = k*H + j*H`, with _k_ and _j_ both private keys, demonstrates that a public key obtained from the addition of two private keys (`(k+j)*H`) is identical to the addition of the public keys for each of those -two private keys (`k*H + j*H`). -_k_ 와 _j_ 둘다 비밀키인 이전 공식 `(k+j)*H = k*H + j*H` 는 두개의 비밀키를 더해서 얻은 한 개의 공개키 (`(k+j)*H`) 와 각각 두개의 비밀키에 공개키를 더한것과 같습니다. -In the Bitcoin blockchain, Hierarchical Deterministic wallets heavily rely on this principle. -Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. -MimbleWimble and the Grin implementation do as well. -MimbleWimble 과 Grin의 구현또한 마찬가지 입니다. +two private keys (`k*H + j*H`). In the Bitcoin blockchain, Hierarchical +Deterministic wallets heavily rely on this principle. MimbleWimble and the Grin +implementation do as well. ### Transacting with MimbleWimble -### MimbleWimble 로 거래하기 - The structure of transactions demonstrates a crucial tenet of MimbleWimble: -트랜잭션의 구조는 MimbleWimble의 강력한 프라이버시와 비밀이 유지된다라고 하는 중요한 규칙을 나타냅니다. strong privacy and confidentiality guarantees. The validation of MimbleWimble transactions relies on two basic properties: -MimbleWimble 트랜잭션의 확인은 두가지 기본적인 성격을 전제로 합니다. * **Verification of zero sums.** The sum of outputs minus inputs always equals zero, proving that the transaction did not create new funds, _without revealing the actual amounts_. -* **제로섬의 검증** 결과값에서 입력값을 뺸 합은 항상 0과 같습니다. 이것은 실제 전송되는 코인의 양을 드러내지 않고도 트랜잭션ㅇ이 새로운 코인을 만들지 않았다는 것을 증명합니다. * **Possession of private keys.** Like with most other cryptocurrencies, ownership of transaction outputs is guaranteed by the possession of ECC private keys. However, the proof that an entity owns those private keys is not achieved by directly signing the transaction. -* **비밀키의 소유** 다른 많은 크립토커런시들 처럼 , 트랜잭션의 소유권은 ECC 비밀키에 의해 보장됩니다. 그러나 어떤 실체가 이런 비밀키들을 소유하고 있다고 증명하는것이 직접적으로 트랜잭션에 사인한다고해서 얻어지는 것은 아닙니다. The next sections on balance, ownership, change and proofs details how those two fundamental properties are achieved. -다음 섹션들에서는 잔고, 소유권, 거스름돈과 증명들의 상세들이 어떻게 저 두가지 기본적인 성질에 의해서 얻어지는지 알아보겠습니다. #### Balance -#### 잔고 - Building upon the properties of ECC we described above, one can obscure the values in a transaction. -위에서 언급한 ECC의 특성들을 기반으로 해서 트랜잭션안의 가치들을 보기 어렵게 할 수 있습니다. If _v_ is the value of a transaction input or output and _H_ an elliptic curve, we can simply -embed `v*H` instead of _v_ in a transaction. -만약 _v_ 가 트랜잭션 입력값이거나 출력값이고 _H_가 타원곡선이라면 , 단순히 _v_ 대신 `v*H`를 끼워넣을 수 있습니다. - -This works because using the ECC operations, we can still validate that the sum of the outputs of a transaction equals the sum of inputs: -이것은 ECC를 사용하기 때문에 작동하는 것입니다. 우리는 출력값의 합이 입력값의 합과 같다는 것을 여전히 확인할 수 있습니다. +embed `v*H` instead of _v_ in a transaction. This works because using the ECC +operations, we can still validate that the sum of the outputs of a transaction equals the +sum of inputs: v1 + v2 = v3 => v1*H + v2*H = v3*H Verifying this property on every transaction allows the protocol to verify that a transaction doesn't create money out of thin air, without knowing what the actual -values are. -이 특성을 모든 트랜잭션에 확인하는것은 프로토콜이 트랜잭션은 돈을 난데없이 만들지 않는다는 것을 실제 돈이 얼마나 있는지 알지 않아도 검증할 수 있게 합니다. -However, there are a finite number of usable values and one could try every single -one of them to guess the value of your transaction. -그러나 사용가능한 한정된 숫자가 있고 그 숫자 중 하나를 사용해서 당신의 트랜잭션이 얼마만큼의 코인을 가졌는지 추측해 할 수 있습니다. -In addition, knowing v1 (from a previous transaction for example) and the resulting `v1*H` reveals all outputs with value v1 across the blockchain. -더해서 , v1을 알고 ( 예시로 사용된 이전의 트랜잭션에서 온 값 ) 그에따른 `v1*H`의 결과를 알면 블록체인 전체에 걸쳐서 v1 값이 있는 모든 출력값들이 드러나게 됩니다. - -For these reasons, we introduce a second elliptic curve _G_ (practically _G_ is just another generator point on the same curve group as _H_) and a private key _r_ used as a *blinding factor*. -이러한 이유때문에 우리는 두번째 타원곡선인 _G_를 제시합니다. ( 실제로 _G_ 는 _H_ 의 그룹과 같은 곡선에 있는 단지 다른 좌표를 생성해 냅니다.) 그리고 비밀키 _r_은 *blinding factor* 로 사용됩니다. +values are. However, there are a finite number of usable values and one could try every single +one of them to guess the value of your transaction. In addition, knowing v1 (from +a previous transaction for example) and the resulting `v1*H` reveals all outputs with +value v1 across the blockchain. For these reasons, we introduce a second elliptic curve +_G_ (practically _G_ is just another generator point on the same curve group as _H_) and +a private key _r_ used as a *blinding factor*. An input or output value in a transaction can then be expressed as: -그렇다면 트랜잭션 안의 입력값과 출력값은 다음과 같이 표현됩니다. + r*G + v*H + Where: -여기서 * _r_ is a private key used as a blinding factor, _G_ is an elliptic curve and their product `r*G` is the public key for _r_ on _G_. -* _r_ 은 비밀키이고 blinding factor 로 사용됩니다. _G_ 는 타원 곡선 이고 `r*G`는 _G_ 안에 있는 _r_ 의 공개키 입니다. * _v_ is the value of an input or output and _H_ is another elliptic curve. -* _v_ 는 출력값이거나 입력값이고 _H_ 는 다른 타원곡선입니다. + Neither _v_ nor _r_ can be deduced, leveraging the fundamental properties of Elliptic Curve Cryptography. `r*G + v*H` is called a _Pedersen Commitment_. -<<<<<<< HEAD -타원곡선 암호의 기본적인 성질을 이용해서 _v_, _r_ 둘다 유추 할 수 없습니다. -`r*G + v*H`은 _Pederson Commitment_ 라고 불립니다. -======= ->>>>>>> dc6542d82b04cbab65abfd3e986946f86267db44 As an example, let's assume we want to build a transaction with two inputs and one output. We have (ignoring fees): -예를 들어 , ( 전송료는 무시하고) 두개의 입력값과 한개의 출력값으로 트랜잭션을 만들기 원한다고 가정해봅시다. * vi1 and vi2 as input values. -* vi1 과 v2 는 출력값 * vo3 as output value. -* vo3는 출력값 이라면 + Such that: vi1 + vi2 = vo3 Generating a private key as a blinding factor for each input value and replacing each value with their respective Pedersen Commitments in the previous equation, we obtain: -각각의 입력값에 대해서 blining factor 로 비밀키를 만들고 각각의 값을 각각의 이전의 공식에 있던 Pederson Commitment로 교체한다고 하면 다음과 같습니다. (ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vo3*H) Which as a consequence requires that: -결과로 다음과 같습니다. + ri1 + ri2 = ro3 This is the first pillar of MimbleWimble: the arithmetic required to validate a transaction can be done without knowing any of the values. -이것이 MimbleWimble의 첫번째 특징입니다. 트랜잭션을 검증하는 산술적인 연산은 아무런 값을 알지 못해도 가능합니다. As a final note, this idea is actually derived from Greg Maxwell's [Confidential Transactions](https://elementsproject.org/features/confidential-transactions/investigation), which is itself derived from an Adam Back proposal for homomorphic values applied to Bitcoin. -마지막으로 이 아이디어는 Greg Maxwell 의 [Confidential Transactions](https://elementsproject.org/features/confidential-transactions/investigation) 에서 유래했습니다. Confidential transaction은 Adam back의 비트코인에 동형암호를 적용하자는 제안에서 비롯되었습니다. #### Ownership -#### 소유권 -In the previous section we introduced a private key as a blinding factor to obscure the -transaction's values. -The second insight of MimbleWimble is that this private +In the previous section we introduced a private key as a blinding factor to obscure the +transaction's values. The second insight of MimbleWimble is that this private key can be leveraged to prove ownership of the value. Alice sends you 3 coins and to obscure that amount, you chose 28 as your diff --git a/doc/intro_DE.md b/doc/intro_DE.md index e9ae8697a3..275e7d8b05 100644 --- a/doc/intro_DE.md +++ b/doc/intro_DE.md @@ -1,6 +1,6 @@ # Einführung in MimbleWimble und Grin -*In anderen Sprachen lesen: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md).* +*In anderen Sprachen lesen: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md)* MimbleWimble ist ein Blockchain-Format und Protokoll, welches auf starke kryptographische Primitiven setzt und dadurch äußerst gute Skalierbarkeit, Privatsphäre und Fungibilität bietet. Es befasst sich mit Lücken, die in fast allen gegenwärtigen Blockchainimplementierungen existieren. diff --git a/doc/intro_ES.md b/doc/intro_ES.md index 90b59122ec..d29171c787 100644 --- a/doc/intro_ES.md +++ b/doc/intro_ES.md @@ -1,6 +1,6 @@ # Introducción a MimbleWimble y Grin -*Lea esto en otros idiomas: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md).* +*Lea esto en otros idiomas: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).* MimbleWimble es un formato y un protocolo de cadena de bloques que proporciona una escalabilidad, privacidad y funcionalidad extremadamente buenas al basarse en fuertes algoritmos criptográficos. Aborda los vacíos existentes en casi todas las diff --git a/doc/intro_JP.md b/doc/intro_JP.md index 6beafa8d12..519668d025 100644 --- a/doc/intro_JP.md +++ b/doc/intro_JP.md @@ -1,6 +1,6 @@ # MimbleWimble と Grin 概論 -*この文章を他の言語で読む： [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md).* +*この文章を他の言語で読む： [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).* MimbleWimble は、極めてよいスケーラビリティ、プライバシー、そして代替可能性（fungibility）の解決法を提供 するブロックチェーンのフォーマット・プロトコルである。MimbleWimble は、ほとんどすべてのブロックチェーンの diff --git a/doc/intro_KR.md b/doc/intro_KR.md index cd42d8d6cd..01d3a21b05 100644 --- a/doc/intro_KR.md +++ b/doc/intro_KR.md @@ -295,10 +295,10 @@ Signature 공개키로서 트랜잭션의 합이 0임을 증명하는 _kernel ex 그리고 아직까진 모든게 유효합니다! #### 모두 컷 스루( Cut-through ) 하기 - -이전 예시의 블록으로 돌아가서 출력값인 x1,과 x2는 I1과 I2에 대해서 사용되고 이것은 반드시 이전 블록체인 안에서 나타나야 합니다. 이 블록이 추가된 이후에 I1과 I2 과 출력값들은 전체 합계에 영향을 주지 않으므로 모든 체인에서 지워 질 수 있습니다. -일반화 하자면, 헤더를 제외하고 어떤 시점에서든 체인의 스테이트는 다음과 같은 정보로 요약될 수 있습니다. +이전 예시의 블록으로 돌아가서 출력값인 x1,과 x2는 I1과 I2에 대해서 사용되고 이것은 반드시 이전 블록체인 안에서 나타나야 합니다. 이 블록이 추가된 이후에 I1과 I2 과 출력값들은 전체 합계에 영향을 주지 않으므로 모든 체인에서 지워 질 수 있습니다. + +일반화 하자면, 헤더를 제외하고 어떤 시점에서든 체인의 스테이트는 다음과 같은 정보로 요약될 수 있습니다. 1. 체인안에서 채굴에 의해서 만들어진 코인의 총량 diff --git a/doc/intro_NL.md b/doc/intro_NL.md index 0d8c6e5efc..2b39e7270e 100644 --- a/doc/intro_NL.md +++ b/doc/intro_NL.md @@ -1,6 +1,6 @@ # Inleiding tot MimbleWimble en Grin -*Lees dit in andere talen: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md).* +*Lees dit in andere talen: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).* MimbleWimble is een blockchain formaat en protocol die extreem goede schaalbaarheid, privacy en fungibiliteit biedt door zich te berusten op sterke cryptografische primiteven. Het adresseert de lacunes die in bijna alle huidige blockchain-implementaties bestaan. diff --git a/doc/intro_PT-BR.md b/doc/intro_PT-BR.md index 5ecc9dd128..2be97ea76e 100644 --- a/doc/intro_PT-BR.md +++ b/doc/intro_PT-BR.md @@ -1,6 +1,6 @@ # Introdução ao MimbleWimble e ao Grin -*Leia isto em outros idiomas: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md).* +*Leia isto em outros idiomas: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).* O MimbleWimble é um formato e protocolo blockchain que fornece ótima escalabilidade, privacidade e fungibilidade, para isso contando com primitivas criptográficas fortes. Ele aborda as lacunas existentes em quase todos as implementações blockchain atuais. diff --git a/doc/intro_RU.md b/doc/intro_RU.md index 04242bbdba..16c3a7825b 100644 --- a/doc/intro_RU.md +++ b/doc/intro_RU.md @@ -1,6 +1,6 @@ # Введение в МимблВимбл и Grin -*На других языках: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md).* +*На других языках: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).* МимблВимбл это формат и протокол блокчейна, предоставляющий исключительную масштабируемость, приватность и обезличенность криптовалюты, diff --git a/doc/intro_SE.md b/doc/intro_SE.md index 8a47caf71e..8bb841a43d 100644 --- a/doc/intro_SE.md +++ b/doc/intro_SE.md @@ -1,6 +1,6 @@ # Introduktion till MimbleWimble och Grin -*Läs detta på andra språk: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md).* +*Läs detta på andra språk: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).* MimbleWimble är ett blockkedjeformat och protokoll som erbjuder extremt bra skalbarhet, integritet, och fungibilitet genom starka kryptografiska primitiver. diff --git a/doc/intro_ZH-CN.md b/doc/intro_ZH-CN.md index ca0dc1ec32..b5c3662d28 100644 --- a/doc/intro_ZH-CN.md +++ b/doc/intro_ZH-CN.md @@ -1,7 +1,7 @@ MimbleWimble 和 Grin 简介 ===================================== -*阅读其它语言版本: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md).* +*阅读其它语言版本: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).* MimbleWimble是一个区块链格式和协议，依托于健壮的加密原语，提供非常好的可扩展性、隐私和可替代性。它解决了当前几乎所有实现的区块链（与现实需求之间）差距。MimbleWimble 的白皮书在[本项目的WiKi](https://github.com/mimblewimble/docs/wiki/A-Brief-History-of-MinbleWimble-White-Paper)中可以找到，WiKi是开放的。 From 2ce4d5fa7b509af02359a119dfbfaf202e71fad3 Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Tue, 19 Feb 2019 22:58:22 +0900 Subject: [PATCH 22/25] add Korean translation file path to stratum.md & table_of_contents.md --- doc/build_KR.md | 133 -------------------------------------- doc/state_KR.md | 53 --------------- doc/stratum.md | 2 + doc/table_of_contents_.md | 2 + 4 files changed, 4 insertions(+), 186 deletions(-) delete mode 100644 doc/build_KR.md delete mode 100644 doc/state_KR.md diff --git a/doc/build_KR.md b/doc/build_KR.md deleted file mode 100644 index 14cb209358..0000000000 --- a/doc/build_KR.md +++ /dev/null @@ -1,133 +0,0 @@ -# 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` 플래그가 아닌, but `--debug` 또는 `--verbose` 플래그를 사용하세요.) 그러나 이 명령어는 암호 오퍼레이션으로 인해 큰 오버헤드를 가지므로 fast sync 가 어려울 정도로 느려집니다. - -## Build 에러들 - -[트러블 슈팅 관련해서는 이 링크를 클릭하세요.](https://github.com/mimblewimble/docs/wiki/Troubleshooting) - -## 무엇을 Build 해야 되나요? - -A successful build gets you: - -* `~/.grin/main/grin-server.toml`. -모든 데이터, 설정, 로그 파일들은 기본적으로 (지정되지 않는다면) `~/.grin` 에 만들어지고 사용됩니다. (user home 디렉토리 안에 있습니다.) -`~/.grin/main/grin-server.toml` 을 수정해서 모든 설정값들을 바꿀 수 있습니다. - -Grin은 현재 디렉토리 내에서도 데이터 파일들을 만들 수 있습니다. 밑에 있는 Bash 명령어를 작동하세요. - -```sh -grin server config -``` - -현재 디렉토리에서 모함한 모든 데이터에 대해 미리 설정된 `grin-server.toml` 파일 내의 값들이 사용될겁니다. - -Testing 중에서는 Grin 바이너리를 이렇게 path 에 삽입 할 수도 있습니다. - -```sh -export PATH=`pwd`/target/release:$PATH -``` - -만약 Grin을 root 디렉토리에서 실행한다면, `grin` 명령어를 바로 실행할 수 있습니다. (`grin help` 명령어를 통해서 좀 더 많은 옵션을 알아보세요.) - -## 설정하기 - -Grin attempts to run with sensible defaults, and can be further configured via -the `grin-server.toml` file. This file is generated by grin on its first run, and contains documentation on each available option. -Grin은 - -While it's recommended that you perform all grin server configuration via -`grin-server.toml`, it's also possible to supply command line switches to grin that override any settings in the file. - -For help on grin commands and their switches, try: - -```sh -grin help -grin wallet help -grin client help -``` - -## Docker 사용하기 - -```sh -docker build -t grin -f etc/Dockerfile . -``` - -floonet을 사용하려면 `etc/Dockerfile.floonet` 을 사용하세요. -You can bind-mount your grin cache to run inside the container. - -```sh -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 - -## 크로스 플랫폼 빌드 - -Rust(Cargo)는 여러 플랫폼에서 Grin을 빌드 할 수 있습니다. 그래서 이론적으로 낮은 성능의 디바이스 에서도 인증받은 노드로 grin을 작동 시킬 수 있습니다. -`grin` 크로스 컴파일을 하기 위해서 x96 리눅스플랫폼 위에서 ARM 바이너릐를 만듭니다. 예를 라즈베리 파이 가 있습니다. - -## Grin 사용하기 - -[지갑 유저 가이드](https://github.com/mimblewimble/docs/wiki/Wallet-User-Guide) 위키페이지와 링크된 페이지들은 어떤 Feature 를 가지고 있는지 , 트러블 슈팅 등등에 대한 좀 더 많은 정보를 가지고 있습니다. - -## Grin 채굴하기 - -Please note that all mining functions for Grin have moved into a separate, standalone package called -[grin-miner](https://github.com/mimblewimble/grin-miner). Once your Grin code node is up and running, -you can start mining by building and running grin-miner against your running Grin node. - - - -For grin-miner to be able to communicate with your grin node, make sure that you have `enable_stratum_server = true` -in your `grin-server.toml` configuration file and you have a wallet listener running (`grin wallet listen`). diff --git a/doc/state_KR.md b/doc/state_KR.md deleted file mode 100644 index 2c6fc7fda6..0000000000 --- a/doc/state_KR.md +++ /dev/null @@ -1,53 +0,0 @@ -# 상태와 스토리지 - -## Grin의 상태 - -### 구조 - -Grin chain의 모든 상태는 다음 데이터와 같이 이루어져 있습니다. - -1. unspent output(UTXO) 세트 -2. 각 출력값에 대한 range proof -3. 모든 트랜잭션 커널(kernel)들 -4. 상기에 언급했던 각각의 MMR (예외적으로 출력값 MMR은 사용되지 않은 것 뿐만 아니라 *모든* 출력값의 해쉬를 포함합니다.) 더해서, 유효한 Proof of work 와 함께 chain 안의 모든 헤더들은 상기 상태에 대해 고정되어야 합니다. ( 상태는 가장 많이 일한 체인와 일치합니다.) -한번 각각의 range proof 가 인증되고 모든 kernel의 실행 합계가 계산되었다면 node 의 작동에 더이상 엄격하게 필요하진 않습니다. - -### 인증하기 - -완전한 Grin의 상태를 사용해서 우리는 다음과 같은 것들을 인증 할 수 있습니다. - -1. Kernel 의 signature 가 Kernel의 실행에 대해 유효하다면 ( 공개키). 이것은 Kernel이 유요하다는것을 증명합니다. -2. 모든 커밋 실행의 합이 모든 UTXO 실행의 합에서 총 공급량을 뺸 값이 같다면 이것은 Kernal과 출력값의 실행들이 유효하고 코인이 새로이 만들어지지 않았다는 것을 증명합니다. -3. 모든 UTXO, range prook 와 Kernel 해쉬들은 각각의 MMR이 있고 그 MMR 들은 유효한 root 를 해쉬합니다. -4. 특정 시점에 가장 많이 일했다고 알려진 Block header 에는 3개의 MMR에 대한 root 가 포함됩니다. 이것은 전체 상태가 가장 많이 일한 chain ( 가장 긴 체인)에서 MMR과 증명들이 만들어졌다는 것을 입증합니다. - -### MMR 과 Pruning - -The data used to produce the hashes for leaf nodes in each MMR (in addition to -their position is the following: -데이터는 리프 노드안의 각 MMR의 Hash를 만들어 냈었지만 -* The output MMR hashes the feature field and the commitments of all outputs - since genesis. -* 출력값의 MMR 해 -* The range proof MMR hashes the whole range proof data. -* The kernel MMR hashes all fields of the kernel: feature, fee, lock height, - excess commitment and excess signature. - -Note that all outputs, range proofs and kernels are added in their respective -MMRs in the order they occur in each block (recall that block data is required -to be sorted). -모든 출력값, Range proof, 그리고 kernel은 각각의 MMR에 더해지고 - -As outputs get spent, both their commitment and range proof data can be -removed. In addition, the corresponding output and range proof MMRs can be -pruned. - -## 상태 스토리지 - -Grin 에 있는 출력값에 대한 데이터 스토리지, Range proof 와 kernel은 간단합니다. -그 형태는 데이터 엑세스를 위한 메모리 매핑 된 append only 파일입니다. -출력값이 소비되는것에 따라서 제거 로그는 지울수 있는 위치를 유지힙니다. -이런 포지션은 MMR과 노드 포지션이 같은 순서로 입력되었으므로 잘 일치합니다. -제거 로그가 커지면 (Append only 파일도 )때때로 해당 파일을 지워진 부분 없이 다시 작성해서 압축하고 제거 로그를 비울 수 있습니다. - -MMR 에 대해서는 약간의 복잡함을 더할 필요가 있습니다. diff --git a/doc/stratum.md b/doc/stratum.md index eb4f8e7580..28a5fff0cf 100644 --- a/doc/stratum.md +++ b/doc/stratum.md @@ -1,5 +1,7 @@ # Grin Stratum RPC Protocol +*Read this in other languages: [Korean](stratum_KR.md).* + This document describes the current Stratum RPC protocol implemented in Grin. ## Table of Contents diff --git a/doc/table_of_contents_.md b/doc/table_of_contents_.md index 77f3831304..67dc673b06 100644 --- a/doc/table_of_contents_.md +++ b/doc/table_of_contents_.md @@ -1,5 +1,7 @@ # Documentation structure +*Read this in other languages: [Korean](table_of_contents_KR.md).* + ## Explaining grin - [intro](intro.md) - Technical introduction to grin From 9000c5d48a154950f7612d23aebc23976bbc8646 Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Tue, 19 Feb 2019 23:00:35 +0900 Subject: [PATCH 23/25] fix difference with grin/master --- doc/code_structure.md | 1 - 1 file changed, 1 deletion(-) diff --git a/doc/code_structure.md b/doc/code_structure.md index 838e4102a1..ad3990cfe5 100644 --- a/doc/code_structure.md +++ b/doc/code_structure.md @@ -1,7 +1,6 @@ # Grin code structure Grin is built in [Rust](https://www.rust-lang.org/), a memory safe, compiled language. Performance critical parts like the Cuckoo mining algorithm are built as plugins, making it easy to swap between algorithm implementations for various hardware. Grin comes with CPU and experimental GPU support. -markdown ## Files in project root List of files tracked in `git` and some files you'll create when you use grin. From e7a587544cf5e6f235df0c869d009c1c68a2e58f Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Fri, 1 Mar 2019 00:37:12 +0900 Subject: [PATCH 24/25] change in table_of_contents_KR.md --- doc/table_of_contents_KR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/table_of_contents_KR.md b/doc/table_of_contents_KR.md index 10484d3f56..cd3b756caf 100644 --- a/doc/table_of_contents_KR.md +++ b/doc/table_of_contents_KR.md @@ -2,7 +2,7 @@ ## Grin 에 대한 설명들 -- [intro](intro.md) - Grin 에 대한 기술적인 소개 +- [intro](intro_KR.md) - Grin 에 대한 기술적인 소개 - [grin4bitcoiners](grin4bitcoiners.md) - Bitcoinner 의 관점에서 Grin 을 설명하기 ## Grin 구현에 대해서 이해하기 From 3e03b1f9d0ba57ba783d620e97f2b6229863b08f Mon Sep 17 00:00:00 2001 From: cmcm2222 Date: Fri, 1 Mar 2019 00:38:58 +0900 Subject: [PATCH 25/25] add line break --- doc/code_structure.md | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/code_structure.md b/doc/code_structure.md index ad3990cfe5..51579fc0d6 100644 --- a/doc/code_structure.md +++ b/doc/code_structure.md @@ -1,6 +1,7 @@ # Grin code structure Grin is built in [Rust](https://www.rust-lang.org/), a memory safe, compiled language. Performance critical parts like the Cuckoo mining algorithm are built as plugins, making it easy to swap between algorithm implementations for various hardware. Grin comes with CPU and experimental GPU support. + ## Files in project root List of files tracked in `git` and some files you'll create when you use grin.