Merge PR #3615: Add 'translations/kr'
This commit is contained in:
dogemos
Christopher Goes
parent
2faee621e2
commit
c71893ed2d
|
|
@ -0,0 +1,39 @@
|
|||
# 코스모스 SDK 문서에 오신 걸 환영합니다!
|
||||
|
||||
::: warning
|
||||
번역된 문서는 **참고용**으로 번역되었습니다. 다수의 오타, 오류가 존재할 수 있으며, 영문 업데이트보다 번역이 느리게 진행될 수 있다는 점을 인지하시기 바랍니다.
|
||||
|
||||
코스모스 관련 가장 정확한 정보를 확인하시기 위해서는 영어 원문을 참고하시기 바랍니다.
|
||||
:::
|
||||
|
||||
## 코스모스 SDK 배우기
|
||||
|
||||
### SDK 소개
|
||||
|
||||
만약 코스모스 SDK가 처음이지만 배우고 싶으시다면 여기에서 시작하시는 것을 추천드립니다.
|
||||
|
||||
### SDK 튜토리얼
|
||||
|
||||
직접 해보면서 학습하는 방식을 선호하신다면 SDK 애플리케이션 튜토리얼을 따라하실 수 있습니다. 튜토리얼은 **[SDK 기반 블록체인을](https://github.com/cosmos/sdk-application-tutorial)** 만드는 방법을 처음부터 끝까지 가르쳐 드립니다. 이 과정에서 코스모스 SDK의 기본적인 개념 또한 함께 배우실 수 있습니다.
|
||||
|
||||
## 코스모스 SDK 사용하기
|
||||
|
||||
다음 항목은 실제로 작동하는 SDK 기반 블록체인에 필요한 모든 정보를 포함하고 있습니다.
|
||||
|
||||
>*NOTE*: 코스모스 SDK 지원 문서의 완성도와 정확성을 높이기 위해 해당 문서는 꾸준히 업데이트 되고 있습니다. 혹시 오류나 제안사항이 있으시다면 [코스모스 포럼](https://forum.cosmos.network) 또는 [깃허브 이슈를](https://github.com/cosmos/cosmos-sdk/issues/new) 통해서 알려주시면 감사하겠습니다.
|
||||
|
||||
- [인트로](./intro/README.md): 코스모스 SDK에 대한 high-level 소개 자료
|
||||
- [Gaia](./gaia/README.md): Gaia 애플리케이션(현재 코스모스 허브 명칭)에 대한 모든 문서들이 있습니다. Gaia 테스트넷에 참여하는 방법에 대한 정보
|
||||
- [클라이언트](./clients/README.md): SDK Command-Line Interface 와 SDK 라이트 클라이언트 같은 SDK 클라이언트에 관련한 문서
|
||||
- [스펙](./spec/README.md): SDK와 모듈들에 대한 스펙 정의
|
||||
|
||||
## 코스모스 허브 테스트넷
|
||||
|
||||
`gaia` 애플리케이션(코스모스 허브의 애플리케이션)을 설치하고 퍼블릭 테스트넷에 참가하고 싶으시다면 여기를 클릭해주세요.
|
||||
자체적인 `gaia` 테스트넷을 운영하고 싶으시다면 **[여기](./gaia/join-testnet.md)** 를 클릭해주세요.
|
||||
|
||||
자체적인 `gaia` 테스트넷 운영을 원하시는 경우 **[여기](./gaia/deploy-testnet.md)** 를 확인하세요
|
||||
|
||||
## 기여하기
|
||||
|
||||
코스모스 도큐멘테이션 또는 코드 업데이트 규칙에 관련해서는 [이 파일](https://github.com/cosmos/cosmos-sdk/blob/master/docs/DOCS_README.md)을 참고해주세요.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
# 클라이언트
|
||||
|
||||
이 항목은 SDK 기반 블록체인을 위한 클라이언트에 대한 정보가 포함되어있습니다.
|
||||
|
||||
>*참고*: 이 항목은 작업이 진행중입니다.
|
||||
|
||||
## 라이트 클라이언트(Light-client)
|
||||
|
||||
라이트 클라이언트는 유저가 특정 블록체인 상태 전체를 다운로드 받지 않고도 안전성이 확보될 수 있는 환경에서 블록체인 애플리케이션과 소통할 수 있게 합니다.
|
||||
|
||||
- [라이트 클라이언트 개요](./lite/README.md)
|
||||
- [라이트 클라이언트 서버 구동하기](./lite/getting_started.md)
|
||||
- [라이트 클라이언트 스펙](./lite/specification.md)
|
||||
|
||||
## 다른 클라이언트
|
||||
|
||||
- [SDK 기반 블록체인을 위한 커맨드 라인 기반 인터페이스](./cli.md)
|
||||
- [서비스 제공자 문서](./service-providers.md)
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
# CLI
|
||||
|
||||
> TODO: Rewrite this section to explain how CLI works for a generic SDK app.
|
||||
|
|
@ -0,0 +1,63 @@
|
|||
# 라이트 클라이언트 개요
|
||||
|
||||
**코스모스 SDK 라이트 클라이언트 RPC 문서를 [여기]에서 확인하세요(https://cosmos.network/rpc/)**
|
||||
|
||||
## 소개
|
||||
|
||||
라이트 클라이언트는 핸드폰 같은 클라이언트에서 블록체인 상태(state)에 대한 증거(proof)를 풀노드로부터 전달받을 수 있게 합니다. 라이트 클라이언트는 전송받은 증거에 대한 검증을 자체적으로 수행할 수 있기 때문에 풀노드를 신뢰하지 않아도 되며, 풀노드의 거짓 정보 전달을 확인할 수 있다.
|
||||
|
||||
라이트 클라이언트는 대역폭(bandwidth), 컴퓨터 연산력 그리고 저장공간 측면에서 큰 리소스를 소모하지 않고도 풀노드와 동일한 보안을 제공할 수 있다. 또한 유저의 설정에 따라 모듈화 된 기능성을 제공할 수 있다. 이런 우수한 기능은 개발자들이 풀 블록체인 노드가 없이도 안전하고, 효율적이고, 사용성이 높은 모바일 애플리케이션, 웹사이트 등을 만들 수 있게 한다.
|
||||
|
||||
### 라이트 클라이언트란 무엇인가
|
||||
|
||||
코스모스 SDK 라이트 클라이언트 (Gaia-lite)는 두 가지 요소로 나뉘어 있다. 첫 번째 요소는 모든 텐더민트 기반 애플리케이션들의 기본적인 컴포넌트다. 해당 컴포넌트는 헤더 체인을 따르면서 풀노드가 제공하는 증거를 신뢰할 수 있는 검증인을 통해 확인하는 방식으로 보안과 연결성 측면을 담당한다. 두 번째 요소는 코스모스 허브(`gaiad`)에 고유한 컴포넌트다. 일종의 쿼리 엔드포인트(query endpoint)로써 애플리케이션 특정 기능을 드러내는 역할을 수행한다. 애플리케이션 상태에 대한 모든 쿼리는 쿼리 엔드포인트(query endpoint)를 통해 이루어진다. 쿼리 엔드포인트를 이용하는 것에 가장 큰 장점은 애플리케이션이 리턴하는 증거를 검증할 수 있다는 것이다.
|
||||
|
||||
### 하이레벨 아키텍처(High-level Architecture)
|
||||
|
||||
코스모스 허브(또는 다른 존)를 위한 제삼자 클라이언트 애플리케이션을 만드려고 하는 개발자는 기본 규례적(canonical) API를 기반으로 개발을 해야 합니다. API는 여러 가지 부품으로 이루어져 있습니다. 코스모스 생태계의 모든 존은 기본적으로 ICS0(텐더민트API)를 공개해야 하나, 그 외에 모듈들은 선택 사항입니다. 모든 존은 모듈 API를 도입할 여부를 기능에 따라 선택할 권리가 있습니다.
|
||||
|
||||
기본적으로 코스모스 허브는 [ICS0](https://cosmos.network/rpc/#/ICS0) (텐더민트API), [ICS1](https://cosmos.network/rpc/#/ICS1) (키API), [ICS20](https://cosmos.network/rpc/#/ICS20) (토큰API), [ICS21](https://cosmos.network/rpc/#/ICS21) (스테이킹API),
|
||||
[ICS22](https://cosmos.network/rpc/#/ICS22) (거버넌스API) and [ICS23](https://cosmos.network/rpc/#/ICS23) (슬래싱API)를 도입하고 있습니다.
|
||||
|
||||
|
||||
|
||||
모든 애플리케이션은 Gaia-lite 클라이언트를 기반으로 운영되는 것을 원칙으로 삼습니다. Gaia-lite 외의 소프트웨어는 특정 존 API에 대한 안정성을 보장하지 않습니다.
|
||||
|
||||
### 비교
|
||||
|
||||
ABCI 풀노드는 다음과 같은 항목에서 라이트 클라이언트와 다릅니다:
|
||||
|
||||
|| 풀노드 | 라이트 클라이언트 | 설명|
|
||||
|-| ------------- | ----- | -------------- |
|
||||
| 트랜잭션 검증 및 실행|Yes|No|풀노드는 모든 트랜잭션을 검증하고 실행하지만, 라이트 클라이언트는 모든 트랜잭션을 처리하지 않습니다|
|
||||
| 검증 및 블록 저장|Yes|No|풀노드는 모든 블록을 검증하고 보관하지만, 라이트 클라이언트는 블록 저장을 하지 않습니다|
|
||||
| 합의 절차 참여| Yes|No|검증인 세트에 포함된 풀노드는 합의 절차에 참여하지만, 라이트 클라이언트는 절대로 합의 절차에 참여할 수 없습니다|
|
||||
| 대역폭 사용량|대량|소량|풀노드는 모든 블록을 전달받기 때문에 충분한 대역폭이 확보되지 않는 경우 다른 뒤질 확률이 있습니다. 검증인 풀노드가 낮은 대역폭으로 지연되는 경우 합의 절차 전체가 늦어질 수 있습니다. 라이트 클라이언트는 로컬 호출만을 처리하기 때문에 소량의 대역폭을 사용합니다|
|
||||
| 연산력 사용량|대량|소량|풀노드는 모든 트랜잭션을 처리하며 모든 블록을 검증해야 하기 때문에 대량의 컴퓨터 연산력을 사용합니다.|
|
||||
| 저장 공간 사용량|대량|소량|풀노드는 모든 블록과 ABCI 상태를 저장합니다. 라이트 클라이언트는 검증인 세트와 일부 체크포인트만을 저장합니다.|
|
||||
| 전력 사용량|대량|소량|풀노드는 24시간 돌아가는 고성능 머신 환경이 제공되어야 하기 때문에 대량의 전력을 소모합니다. 라이트 클라이언트의 경우 유저 애플리케이션과 동일한 환경에서 운용될 수 있습니다. 라이트 클라이언트는 모바일 기기 같은 저성능 기기에서도 사용될 수 있습니다. 또한 라이트 클라이언트는 필요에 따라 클라이언트 작동을 출 수 있기 때문에 모바일 기기 같은 저전력 소모를 필요로 하는 환경에서 이용될 수 있습니다.|
|
||||
| API 제공|모든 코스모스 API|모듈 API|풀노드는 모든 코스모스 API를 지원합니다. 라이트 클라이언트는 유저 설정에 따라 모듈 API를 제공합니다.|
|
||||
| 보안|높음|높음|풀노드는 자체적으로 모든 트랜잭션과 블록을 검증합니다. 라이트 클라이언트는 모든 트랜잭션을 검증하지 않지만 다른 풀노드를 통해 데이터를 전달받아 자체적인 검증을 할 수 있습니다. 풀노드와 라이트 클라이언트는 둘 다 제삼자 노드를 신뢰할 필요 없이 데이터 검증이 가능하기 때문에 높은 수준의 보안을 제공합니다|
|
||||
|
||||
위 표와 같이 가이아 라이트 클라이언트는 소량의 대역폭, 연산력, 저장 공간, 전력을 가지고도 유저가 필요로 하는 모든 기능과 보안을 제공합니다.
|
||||
|
||||
## 보안 유지하기
|
||||
|
||||
### 신뢰 가능한 검증인 세트
|
||||
|
||||
가이아 라이트 클라이언트의 디자인 철학은 다음과 같은 원칙을 따릅니다:
|
||||
|
||||
1. **검증인 노드와 다른 풀 노드를 포함한 모든 블록체인 노드를 신뢰하지 않는다**
|
||||
2. **오직 전체적인 검증인 세트(validator set) 만을 신뢰한다**
|
||||
|
||||
초기에 신뢰될 수 있는 검증인 세트(통상 제네시스 파일에 있는 검증인 세트)는 신뢰 저장소(trust store)에 미리 세팅되어야 합니다. 이후, 런타임에서 라이트 클라이언트가 다른 검증인 세트를 발견하게 된다면 클라이언트는 해당 검증인 세트를 별도로 검증한 후 새로운 검증인 세트를 저장소에 보관하게 됩니다.
|
||||
|
||||
|
||||
|
||||
### 신뢰 전파(trust propagation)
|
||||
|
||||
위에 항목에 나열된 바와 같이, 라이트 클라이언트(lcd)는 신뢰할 수 있는 검증인 세트를 별도로 검증합니다. 검증인 세트는 일종의 신뢰의 기반이 되며, 이런 신뢰를 기반으로 블록 정보와 트랜잭션 정보 같은 다른 블록체인 데이터에 신뢰를 전파(propogate)하는데 이용됩니다. 신뢰 전파 아키텍처는 다음과 같습니다.
|
||||
|
||||
|
||||
|
||||
라이트 클라이언트는 통상 신뢰 가능한 검증인 세트를 통해 모든 프리 커밋 정보와 블록 헤더 정보가 포함된 각 블록의 커밋을 검증할 수 있습니다. 이후 블록 해시 값, 데이터 해시 값 그리고 앱해시(appHash)에 대한 신뢰를 파생합니다. 머클 증거(merkle proof)와 위의 정보를 이용해 모든 트랜잭션 데이터와 ABCI의 상태(state)를 검증할 수 있게 됩니다.
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
# REST 서버 시작하기
|
||||
|
||||
REST 서버를 가동하기 위해서는 다음과 같은 파라미터 값을 정의해야 합니다:
|
||||
|
||||
|
||||
| 파라미터 | 형태 | 기본 값 | 필수/선택 | 설명 |
|
||||
| ----------- | --------- | ----------------------- | -------- | ---------------------------------------------------- |
|
||||
| chain-id | string | null | 필수 | 연결할 체인의 chain-id |
|
||||
| node | URL | "tcp://localhost:46657" | 필수 | 연결할 풀노드의 주소 |
|
||||
| laddr | URL | "tcp://localhost:1317" | 필수 | REST 서버를 가동할 주소 |
|
||||
| trust-node | bool | "false" | 필수 | 연결할 풀노드의 신뢰가능 여부 |
|
||||
| trust-store | DIRECTORY | "$HOME/.lcd" | 선택 | 체크포인트와 검증인 세트를 저장할 디렉터리 |
|
||||
|
||||
예를 들어::
|
||||
|
||||
```bash
|
||||
gaiacli rest-server --chain-id=test \
|
||||
--laddr=tcp://localhost:1317 \
|
||||
--node tcp://localhost:26657 \
|
||||
--trust-node=false
|
||||
```
|
||||
|
||||
서버는 기본적으로 HTTP를 확인합니다. 보안 계층을 사용하시려면 `--tls` 플래그를 추가해주세요. 기본적으로 자체 서명이 된 인증서가 생성되며, fingerprint가 프린트됩니다. 서버에 특정 SSL 인증서를 사용하기 ㅜ이해서는 `--ssl-certfile`과 `--ssl-keyfile` 플래그를 지정해주세요:
|
||||
|
||||
```bash
|
||||
gaiacli rest-server --chain-id=test \
|
||||
--laddr=tcp://localhost:1317 \
|
||||
--node tcp://localhost:26657 \
|
||||
--trust-node=false \
|
||||
--ssl-certfile=mycert.pem --ssl-keyfile=mykey.key
|
||||
```
|
||||
|
||||
Gaia-Lite RPC에 대한 추가적인 정보를 원하시면 [Swagger 문서](https://cosmos.network/rpc/)를 확인하세요.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 31 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 95 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 31 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 63 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 94 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
|
|
@ -0,0 +1,185 @@
|
|||
# 라이트 클라이언트 스펙
|
||||
|
||||
이 문서는 LCD(Light Client Daemon)을 사용하는 방법을 설명합니다. LCD는 모듈러 API를 지원합니다. 현재 LCD는 ICS0 (텐더민트API), ICS1 (키API)와 ICS20 (토큰API) 만을 지원하는 상태입니다. 추후에 추가 모듈을 지원할 예정입니다.
|
||||
|
||||
## ABCI 상태 빌드/검증하기
|
||||
|
||||
코스모스 SDK 기반 애플리케이션은 멀티-서브스토어(multi-substore)를 이용해 저장을 합니다. 각 서브스토어는 IAVL 스토어를 응용합니다. 서브스토어는 단순한 머클 트리(Merkle tree) 형태로 정렬됩니다. 머클 트리를 만들기 위해서는 각 서브스토어의 이름, 블록 높이 그리고 스토어 루트 해시(store root hash) 필요하며, 이를 기반으로 간단한 머클 가지 노드(Merkle leaf node)를 만들 수 있습니다. 이후 가지 노드를 이용해 해시값을 머클 뿌리(Merkle root)까지 연산하게 됩니다. 단순 머클 트리(simple Merkle tree)의 루트 해시(Root hash)는 블록 헤더에 포함되는 앱 해시(AppHash)입니다.
|
||||
|
||||
|
||||
|
||||
[LCD 신뢰 전파](https://github.com/irisnet/cosmos-sdk/tree/bianjie/lcd_spec/docs/spec/lcd#trust-propagation)에서 설명했던바와 같이, 앱해시는 신뢰할 수 있는 검증인 세트의 보팅파워(총 스테이킹 수량)를 검증하는 방식으로 확인할 수 있습니다. 이 절차에는 ABCI 상태에서부터 앱해시 증거를 찾으면 됩니다. 증거에는 다음과 같은 정보가 포함되어있습니다:
|
||||
|
||||
* IAVL 증거
|
||||
* 섭스토어에서 앱해시까지의 증거
|
||||
|
||||
### IAVL 증거 (IAVL proof)
|
||||
|
||||
증거물에는 두 가지의 종류가 있습니다: 존재 증거(existance proof)와 부재 증거(absence proof). 만약 쿼리 키가 IAVL 스토어에 존재하는 경우 키 밸류(key-value)와 존재 증거를 제공하게 됩니다. 반면, 만약 키가 존재하지 않는다면 해당 키가 존재하지 않는 것을 증명할 수 있는 부재 증거를 제공합니다.
|
||||
|
||||
### IAVL 존재 증거 (IAVL Existance Proof)
|
||||
|
||||
```go
|
||||
type CommitID struct {
|
||||
Version int64
|
||||
Hash []byte
|
||||
}
|
||||
|
||||
type storeCore struct {
|
||||
CommitID CommitID
|
||||
}
|
||||
|
||||
type MultiStoreCommitID struct {
|
||||
Name string
|
||||
Core storeCore
|
||||
}
|
||||
|
||||
type proofInnerNode struct {
|
||||
Height int8
|
||||
Size int64
|
||||
Version int64
|
||||
Left []byte
|
||||
Right []byte
|
||||
}
|
||||
|
||||
type KeyExistsProof struct {
|
||||
MultiStoreCommitInfo []MultiStoreCommitID //All substore commitIDs
|
||||
StoreName string //Current substore name
|
||||
Height int64 //The commit height of current substore
|
||||
RootHash cmn.HexBytes //The root hash of this IAVL tree
|
||||
Version int64 //The version of the key-value in this IAVL tree
|
||||
InnerNodes []proofInnerNode //The path from to root node to key-value leaf node
|
||||
}
|
||||
```
|
||||
|
||||
존재 증거의 데이터 형식은 위와 같이 나열되어 있습니다. 존재 증거를 생성하고 검증하는 방식은 다음과 같습니다:
|
||||
|
||||
|
||||
|
||||
|
||||
증거 생성 절차:
|
||||
|
||||
* 루트 노드에서 IAVL 트리를 액세스
|
||||
* 방문 노드(visited node)를 InnerNodes에 기록
|
||||
* 타겟 가지 노드(leaf node)를 찾은 경우, 가지 노드 버전을 증거 버전에 할당
|
||||
* 현재 IAVL 트리 높이(IAVL tree height)를 증거 높이(proof height)에 할당
|
||||
* 현재 IAVL 트리의 루트해시(rootHash)를 증거 루트해시에 할당
|
||||
* 현재 서브스토어 이름을 증거 스토어 이름(proof StoreName)에 할당
|
||||
* db에서 멀티스토어 커밋 정보(multistore commitInfo)를 읽은 후 증거 StoreCommitInfo에 할당
|
||||
|
||||
검증 절차:
|
||||
|
||||
* 키, 값 그리고 증거 버전(proof version)을 이용해 리프 노드(leaf node)를 생성
|
||||
* 리프 노드 해시값을 연산
|
||||
* 해시 값을 innerNoder의 rightHash에 할당한 후, 첫 innnerNode의 해시를 연산
|
||||
* 해시 연산 절차를 전파. 만약 위의 innerNode가 다음 innerNode의 left child(좌측 자녀)인 경우, 해당 innerNode를 다음 innerNode의 좌측 해시로 배정한다. 이 외의 경우, 위의 innerNode 해시를 다음 innerNode의 우측 해시로 배정한다.
|
||||
* 마지막 innerNode의 해시값은 해당 증거의 rootHash와 동일해야 한다. 그렇지 않은 경우, 증거는 무효하다.
|
||||
|
||||
### IAVL 부재 증거(IAVL Absence Proof)
|
||||
|
||||
모든 IAVL 리프 노드는 각 리프노드의 키로 정렬되어있습니다. 그렇기 때문에 IAVL 트리의 전체 키 내의 목표 키 위치를 찾을 수 있습니다. 아래와 같이, 키가 좌측 키 또는 우측 키인지 확인이 가능합니다. 만약 우측 키와 좌측 키의 존재를 증명할 수 있을 경우, 인접 노드(adjecent node) 여부를 증명할 수 있는 것이며 타겟 키가 존재하지 않는다는 것을 증명하게 됩니다.
|
||||
|
||||
|
||||
|
||||
만약 타겟 키가 최우측 리프 노드(right most leaf node) 보다 크거나 또는 최좌측 키(left most key) 보다 작은 경우 타겟 키는 존재하지 않음을 증명합니다.
|
||||
|
||||
|
||||
|
||||
```go
|
||||
type proofLeafNode struct {
|
||||
KeyBytes cmn.HexBytes
|
||||
ValueBytes cmn.HexBytes
|
||||
Version int64
|
||||
}
|
||||
|
||||
type pathWithNode struct {
|
||||
InnerNodes []proofInnerNode
|
||||
Node proofLeafNode
|
||||
}
|
||||
|
||||
type KeyAbsentProof struct {
|
||||
MultiStoreCommitInfo []MultiStoreCommitID
|
||||
StoreName string
|
||||
Height int64
|
||||
RootHash cmn.HexBytes
|
||||
Left *pathWithNode // Proof the left key exist
|
||||
Right *pathWithNode //Proof the right key exist
|
||||
}
|
||||
```
|
||||
|
||||
위는 부재 증거의 데이터 구조입니다. 증거를 생성하는 절차는 다음과 같습니다:
|
||||
|
||||
* 루트 노드에서 IAVL 트리를 액세스
|
||||
* 전체 키 세트의 deserved index(INDEX로 표기됨)을 받는다
|
||||
* 만약 받은 인덱스의 값이 0일 경우, 우측 인덱스의 값은 0이며 좌측 노드는 존재하지 않는다
|
||||
* 만약 받은 인덱스의 값이 전체 키 세트의 크기와 동일한 경우, 좌측 노드 인덱스는 INDEX-1 이어야 하며 우측 노드는 존재하지 않는다
|
||||
* 이외의 경우, 우측 노드 인덱스는 INDEX여야 하며 좌측 노드 인덱스는 INDEX-1이다
|
||||
* 현재 IAVL 트리의 높이를 증거 높이에 할당한다
|
||||
* 현재 IAVL 트리의 rootHash를 증거 rootHash로 할당한다
|
||||
* 현재 substore 이름을 증거의 StoreName으로 할당한다
|
||||
* db에서 multistore commitInfo를 읽은 후 증거의 StoreCommitInfo에 할당한다
|
||||
|
||||
증거 검증 절차:
|
||||
|
||||
* 만약 우측 노드만 존재하는 경우, 존재 증거(exist proof)를 검증하여 최좌특 노드인지 확인한다
|
||||
* 만약 우측 노드만 존재하는 경우, 존재 증거(exist proof)를 검증하여 최우측 노드인지 확인한다
|
||||
* 만약 좌측 노드와 우측 노드가 동시에 존재하는 경우, 두 노드가 인접(adjacent)한지 확인한다
|
||||
|
||||
### Substores 증거와 AppHash 증거 확인하기
|
||||
|
||||
IAVL 증거를 검증했다면 substore 증거와 AppHash를 비교하여 검증할 수 있습니다. 우선 MultiStoreCommitInfo를 반복(iterate)하여 proof StoreName을 이용해 서브스토어의 commitID를 찾을 수 있습니다. 여기에서 commitID의 해시가 RootHash의 proof와 동일하다는 것을 검증합니다. 만약 동일하지 않을 경우, 증거는 유효하지 않습니다. 이후 서브스토어 commitInfo 어레이를 서브스토어 이름의 해시 값으로 정렬합니다. 마지막으로, 모든 서브스토어 commitInfo 어레이를 기반으로 단순 머클 트리(simple Merkle tree)를 빌드하여 머클 루트 해시가 앱 해시와 동일한지 검증합니다.
|
||||
|
||||
|
||||
|
||||
|
||||
```go
|
||||
func SimpleHashFromTwoHashes(left []byte, right []byte) []byte {
|
||||
var hasher = ripemd160.New()
|
||||
|
||||
err := encodeByteSlice(hasher, left)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
|
||||
err = encodeByteSlice(hasher, right)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
|
||||
return hasher.Sum(nil)
|
||||
}
|
||||
|
||||
func SimpleHashFromHashes(hashes [][]byte) []byte {
|
||||
// Recursive impl.
|
||||
switch len(hashes) {
|
||||
case 0:
|
||||
return nil
|
||||
case 1:
|
||||
return hashes[0]
|
||||
default:
|
||||
left := SimpleHashFromHashes(hashes[:(len(hashes)+1)/2])
|
||||
right := SimpleHashFromHashes(hashes[(len(hashes)+1)/2:])
|
||||
return SimpleHashFromTwoHashes(left, right)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 검증인 세트를 이용한 블록헤더 검증하기
|
||||
|
||||
위 항목에서는 appHash를 자주 언급합니다. 그렇다면 appHash는 어디에서 존재하는 것일까요? appHash는 블록 헤더에 존재합니다. 그렇기 때문에 특정 블록 높이의 블록헤더를 LCD가 신뢰하는 검증인 세트에 검증해야 합니다. 검증 절차는 다음과 같습니다:
|
||||
|
||||
|
||||
|
||||
만약 신뢰 검증인 세트가 블록 헤더와 일치하지 않는 경우, 해당 블록 높이의 검증인 세트로 업데이트를 해야합니다. LCD는 검증인 세트의 변경이 보팅 파워의 1/3을 초과할 수 없다는 규칙을 따릅니다. 만약 타겟 검증인 세트가 현재 신뢰되는 검증인 세트에서 1/3 보팅파워를 초과하는 변화가 있는 경우, 타겟 검증인 세트 전에 숨겨진 검증인 세트 변경이 있었는지 확인해야 합니다. 모든 검증인 세트 변경이 이 규칙을 따를때 검증인 세트 업데이트가 이루어질 수 있습니다.
|
||||
|
||||
예를 들어:
|
||||
|
||||
|
||||
|
||||
* Update to 10000, tooMuchChangeErr
|
||||
* Update to 5050, tooMuchChangeErr
|
||||
* Update to 2575, Success
|
||||
* Update to 5050, Success
|
||||
* Update to 10000,tooMuchChangeErr
|
||||
* Update to 7525, Success
|
||||
* Update to 10000, Success
|
||||
|
|
@ -0,0 +1,115 @@
|
|||
# 서비스 제공자(Service Providers)
|
||||
|
||||
'서비스 제공자'는 코스모스 SDK 기반 블록체인(코스모스 허브도 포함됩니다)과 교류하는 서비스를 엔드유저에게 제공하는 특정 인원/기관을 뜻합니다. 이 문서는 주로 토큰 인터랙션에 대한 정보를 다룹니다.
|
||||
|
||||
다음 항목은 [Light-Client](https://github.com/cosmos/cosmos-sdk/tree/develop/docs/light) 기능을 제공하려는 월렛 개발자들에게 해당하지 않습니다. 서비스 제공자는 엔드 유저와 블록체인을 이어주는 신뢰할 수 있는 기관/개인입니다.
|
||||
|
||||
## 보편적 아키텍처 설명
|
||||
|
||||
다음 세가지 항목을 고려해야 합니다:
|
||||
|
||||
- 풀 노드(Full-nodes): 블록체인과의 인터랙션.
|
||||
- REST 서버(Rest Server): HTTP 콜을 전달하는 역할.
|
||||
- REST API: REST 서버의 활용 가능한 엔드포인트를 정의.
|
||||
|
||||
## 풀노드 운영하기
|
||||
|
||||
### 설치 및 설정
|
||||
|
||||
다음은 코스모스 허브의 풀노드를 설정하고 운용하는 방법입니다. 다른 코스모스 SDK 기반 블록체인 또한 비슷한 절차를 가집니다.
|
||||
|
||||
우선 [소프트웨어를 설치하세요](../getting-started/installation.md).
|
||||
|
||||
이후, [풀노드를 운영하세요](../getting-started/join-testnet.md).
|
||||
|
||||
### 커맨드 라인 인터페이스
|
||||
|
||||
다음은 풀노드를 이용할 수 있는 유용한 CLI 커맨드입니다.
|
||||
|
||||
#### 키페어 생성하기
|
||||
|
||||
새로운 키를 생성하기 위해서는 (기본적으로 secp256k1 엘립틱 커브 기반):
|
||||
|
||||
```bash
|
||||
gaiacli keys add <your_key_name>
|
||||
```
|
||||
|
||||
이후 해당 키페어에 대한 비밀번호(최소 8글지)를 생성할 것을 요청받습니다. 커맨드는 다음 4개 정보를 리턴합니다:
|
||||
|
||||
|
||||
- `NAME`: 키 이름
|
||||
- `ADDRESS`: 주소 (토큰 전송을 받을때 이용)
|
||||
- `PUBKEY`: 퍼블릭 키 (검증인들이 사용합니다)
|
||||
- `Seed phrase`: 12 단어 백업 시드키 **이 시드는 안전한 곳에 별도로 보관하셔야 합니다**. 이 시드키는 비밀번호를 잊었을 경우, 계정을 복구할때 사용됩니다.
|
||||
|
||||
다음 명령어를 통해서 사용 가능한 모든 키를 확인할 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli keys list
|
||||
```
|
||||
|
||||
#### 잔고 조회하기
|
||||
|
||||
해당 주소로 토큰을 받으셨다면 다음 명령어로 계정 잔고를 확인하실 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli account <YOUR_ADDRESS>
|
||||
```
|
||||
|
||||
*참고: 토큰이 0인 계정을 조회하실 경우 다음과 같은 에러 메시지가 표시됩니다: 'No account with address <YOUR_ADDRESS> was found in the state'. 해당 에러 메시지는 정상이며 앞으로 에러 메시지 개선이 들어갈 예정입니다.*
|
||||
|
||||
#### CLI로 코인 전송하기
|
||||
|
||||
다음은 CLI를 이용해 코인을 전송하는 명령어입니다:
|
||||
|
||||
```bash
|
||||
gaiacli send --amount=10faucetToken --chain-id=<name_of_testnet_chain> --from=<key_name> --to=<destination_address>
|
||||
```
|
||||
|
||||
플래그:
|
||||
- `--amount`: `<value|coinName>` 포맷의 코인 이름/코인 수량입니다.
|
||||
- `--chain-id`: 이 플래그는 특정 체인의 ID를 설정할 수 있게 합니다. 앞으로 테스트넷 체인과 메인넷 체인은 각자 다른 아이디를 보유하게 됩니다.
|
||||
- `--from`: 전송하는 계정의 키 이름.
|
||||
- `--to`: 받는 계정의 주소.
|
||||
|
||||
#### Help
|
||||
|
||||
이 외의 기능을 이용하시려면 다음 명령어를 사용하세요:
|
||||
|
||||
```bash
|
||||
gaiacli
|
||||
```
|
||||
|
||||
사용 가능한 모든 명령어를 표기하며, 각 명령어 별로 `--help` 플래그를 사용하여 더 자세한 정보를 확인하실 수 있습니다.
|
||||
|
||||
## REST 서버 설정하기
|
||||
|
||||
REST 서버는 풀노드와 프론트엔드 사이의 중계역할을 합니다. REST 서버는 풀노드와 다른 머신에서도 운영이 가능합니다.
|
||||
|
||||
REST 서버를 시작하시려면:
|
||||
|
||||
```bash
|
||||
gaiacli advanced rest-server --node=<full_node_address:full_node_port>
|
||||
```
|
||||
|
||||
플래그:
|
||||
- `--trust-node`: 불리언 값. `true`일 경우, 라이트 클라이언트 검증 절차가 비활성화 됩니다. 만약 `false`일 경우, 절차가 활성화됩니다. 서비스 제공자의 경우 `true` 값을 이용하시면 됩니다. 기본 값은 `true`입니다.
|
||||
- `--node`: 플노드의 주소와 포트를 입력하시면 됩니다. 만약 풀노드와 REST 서버가 동일한 머신에서 운영될 경우 주소 값은 `tcp://localhost:26657`로 설정하시면 됩니다.
|
||||
- `--laddr`: REST 서버의 주소와 포트를 정하는 플래그입니다(기본 값 `1317`). 대다수의 경우에는 포트를 정하기 위해서 사용됩니다, 이 경우 주소는 "localhost"로 입력하시면 됩니다. 포맷은 <rest_server_address:port>입니다.
|
||||
|
||||
|
||||
### 트랜잭션 수신 모니터링
|
||||
|
||||
추천하는 수신 트랜잭션을 모니터링하는 방식은 LCD의 다음 엔드포인트를 정기적으로 쿼리하는 것입니다:
|
||||
|
||||
[`/bank/balance/{account}`](https://cosmos.network/rpc/#/ICS20/get_bank_balances__address_)
|
||||
|
||||
## Rest API
|
||||
|
||||
REST API는 풀노드와 인터랙션이 가능한 모든 엔드포인트를 정의합니다. 다음 [링크](https://cosmos.network/rpc/)에서 확인이 가능합니다.
|
||||
|
||||
API는 엔드포인트의 카테고리에 따라 ICS 스탠다드로 나뉘어집니다. 예를 들어 [ICS20](https://cosmos.network/rpc/#/ICS20/)은 토큰 인터랙션 관련 API를 정의합니다.
|
||||
|
||||
서비스 제공자에게 더 많은 유연성을 제공하기 위해서 미서명 트랜잭션을 생성, [서명](https://cosmos.network/rpc/#/ICS20/post_tx_sign)과 [전달](https://cosmos.network/rpc/#/ICS20/post_tx_broadcast) 등의 다양한 API 엔드포인트가 제공됩니다. 이는 서비스 제공자가 자체 서명 메커니즘을 이용할 수 있게 합니다.
|
||||
|
||||
미서명 트랜잭션을 생성하기 위해서는 (예를 들어 [코인 전송](https://cosmos.network/rpc/#/ICS20/post_bank_accounts__address__transfers))을 생성하기 위해서는 `base_req` body에서 `generate_only` 플래그를 이용하셔야 합니다.
|
||||
|
|
@ -0,0 +1,85 @@
|
|||
# 베이스앱(BaseApp)
|
||||
|
||||
베이스앱(BaseApp)은 코스모스 SDK 애플리케이션이 텐더민트 노드와 소통할 수 있게하는 기본적 ABCI 애플리케이션의 기반을 정의합니다.
|
||||
|
||||
베이스앱은 다수의 내부 컴포넌트로 구성되어있습니다. 이 중 가장 중요한 컴포넌트는 `CommitMultiStore`와 해당 컴포넌트의 내부 상태(internal state)입니다. 내부 상태는 하위 두 개의 서브스테이트(substate)로 구성되어있으며, 두 서브 스테이트는 각자 트랜잭션 실행 단계의 `CheckTx`와 `DeliverTx` 이용됩니다. 블록 커밋 단계에서는 `DeliverTx`만이 유지됩니다.
|
||||
|
||||
베이스앱은 capabilities keys를 통해 스토어에 마운트 되어야 합니다. 핸들러는 키가 부여된 스토어에만 접근할 수 있습니다. 베이스앱은 모든 스토어가 정상적으로 로딩, 캐쉬 그리고 커밋되는 것을 보장합니다. 마운트 된 스토어 중 '메인(`baseApp.MainstoreKey`' 스토어는 최신 블록 헤더 정보를 보관하며, 이를 기반으로 가장 최근 상태(state)를 찾고 불러올 수 있습니다.
|
||||
|
||||
베이스앱은 `AnteHandler`와 `MsgHandler` 두 가지의 핸들러 타입을 받습니다. `AnteHandler`는 논스값 확인, 서명 확인, 수수료 지불 가능 잔고 확인 등 모든 모듈에서 이용되는 트랜잭션 기능의 글로벌 유효성 검증(global validity check)을 수행합니다. `MsgHandler`의 경우 상태 변경(full state transition) 기능을 수행합니다.
|
||||
|
||||
`CheckTx` 단계에서 상태 변경 기능은 `checkTxState`에만 적용되며, 값비싼 스테이트 변경 작업이 실행되기 전에 리턴을 해야합니다(관련 절차 설계는 각 개발자의 자유입니다). 또한 예상 가스 비용을 리턴해야 합니다.
|
||||
|
||||
`DeliverTx` 단계에서는 상태 변경 기능이 블록체인 상태에 적용되며 트랜잭션은 완전하게 실행되어야 합니다.
|
||||
|
||||
베이스앱은 핸들러에게 전달되는 컨텍스트(context)를 관리하는 역할을 합니다. 또한 `CheckTx`와 `DeliverTx`에게 할당되는 스토어와 블록헤더 정보를 제공합니다. 베이스앱은 시리얼화 포맷(serialization format)에 불가지론적(agnostic)입니다.
|
||||
|
||||
## 트랜잭션 라이프 사이클(Transaction Life Cycle)
|
||||
|
||||
트랜잭션은 실행 단계에서 ABCI 스펙 정의에 따라 `CheckTx`와 `DeliverTx`를 거칠 수 있습니다. `CheckTx`는 블록 제안 검증인이 실행하며 모든 풀노드의 텐더민트 멤풀에서 이용됩니다.
|
||||
|
||||
`CheckTx`와 `DeliverTx`는 (정의된 경우) 애플리케이션의 안티핸들러(AnteHandler)를 실행합니다. 여기서 안티핸들러는 메시지-전(pre-message) 검증을 수행하여 계정, 서명 검증, 수수료 삭감, 수수료 수금, 시퀀스 번호 추가 등의 기능을 수행합니다.
|
||||
|
||||
### CheckTx
|
||||
|
||||
`CheckTx`의 실행 단계에서는 안티핸들러(AnteHandler)만이 실행됩니다.
|
||||
|
||||
안티핸들러로 발생하는 상태 변경은 안티핸들러가 실패하여 중단되는 경우를 제외하고는 check-tx 상태의 `CheckTx`의 추후 콜(call)까지 지속됩니다.
|
||||
|
||||
### DeliverTx
|
||||
|
||||
`DeliverTx`의 실행 단계에서는 안티핸들러(AnteHandler)와 핸들러(Handler)가 함께 실행됩니다.
|
||||
|
||||
`DeliverTx`의 트랜잭션 실행 절차는 `CheckTx`와 유사하게 진행됩니다. 다만, 안티핸들러로 발생하는 상태 변경은 핸들러의 프로세싱 로직이 실패하여도 지속됩니다.
|
||||
|
||||
악의적 제안자(proposer)가 안티핸들러를 통과하지 못하는 트랜잭션을 발생할 수 있는 경우가 발생할 수도 있습니다. 이 경우에는 악의적 트랜잭션의 상태 변경은 버려집니다(무시됩니다).
|
||||
|
||||
## 다른 ABCI 메시지
|
||||
|
||||
`CheckTx`와 `DeliverTx` 외에도 베이스앱은 다음과 같은 ABCI 메시지를 처리합니다.
|
||||
|
||||
### Info
|
||||
TODO complete description (추후 업데이트 예정)
|
||||
|
||||
### SetOption
|
||||
TODO complete description (추후 업데이트 예정)
|
||||
|
||||
### Query
|
||||
TODO complete description (추후 업데이트 예정)
|
||||
|
||||
### InitChain
|
||||
TODO complete description (추후 업데이트 예정)
|
||||
|
||||
체인 시동(chain initialization) 단계에서 `InitChain`은 `CommitMultiStore`에 직접적으로 할당되어 있는 시동 로직을 실행합니다. check state와 deliver state는 정의된 ChainID로 시작됩니다.
|
||||
|
||||
참고할 것은 InitChain 이후에 커밋을 실행하지 않습니다. 그렇기 때문에 블록 1의 BeginBlock은 InitChain이 시작한대로 deliver state에서 시작됩니다.
|
||||
|
||||
### BeginBlock
|
||||
TODO complete description (추후 업데이트 예정)
|
||||
|
||||
### EndBlock
|
||||
TODO complete description (추후 업데이트 예정)
|
||||
|
||||
### Commit
|
||||
TODO complete description (추후 업데이트 예정)
|
||||
|
||||
|
||||
## 가스 관리(Gas Management)
|
||||
|
||||
### 가스: InitChain
|
||||
|
||||
InitChain 실행 단계에서 블록 가스 미터는 제네시스 트랜잭션을 처리하기 위하여 무한대 가스 수량을 기준으로 시작됩니다.
|
||||
|
||||
또한, InitChain의 리퀘스트 메시지에는 genesis.json 파일이 정의하는 ConsensusParams가 포함되어있습니다.
|
||||
|
||||
|
||||
### 가스: BeginBlock
|
||||
|
||||
블록 가스 미터는 BeginBlock의 deliver state에서 리셋됩니다. 만약 베이스앱에서 최대 블록 가스가 설정되어있지 않은 경우, 가스 미터는 무한으로 설정됩니다. 최대 블록 가스가 설정되었을 경우, 가스 미터는 `ConsensusParam.BlockSize.MaxGas`를 통해 설정됩니다.
|
||||
|
||||
### 가스: DeliverTx
|
||||
|
||||
특정 트랜잭션이 실행되기 전, `BlockGasMeter`를 우선 확인하여 남은 가스가 있는지 확인합니다. 만약 남은 가스가 없다면 `DeliverTx`는 즉시 에러를 리턴합니다.
|
||||
|
||||
트랜잭션이 처리된 후, 사용된 가스는 (설정된 가스 리밋에 따라) `BlockGasMeter`에서 차감됩니다. 만약 잔류 가스가 가스 미터의 한도를 초과할 경우, `DeliverTx`는 에러를 리턴하고 해당 트랜잭션은 커밋되지 않습니다.
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 283 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 186 KiB |
|
|
@ -0,0 +1,19 @@
|
|||
# Gaia Documentation
|
||||
|
||||
`Gaia` docs에 오신 것을 환영합니다. `Gaia` 는 코스모스 허브를 위한 코스모스 애플리케이션의 현재 명칭입니다.
|
||||
|
||||
## 코스모스 퍼블릭 테스트넷에 참가하세요
|
||||
|
||||
- [`gaia` 애플리케이션 설치하기](./installation.md)
|
||||
- [풀노드를 세팅하고 현재 퍼블릭 테스트넷 참가하기](./join-testnet.md)
|
||||
- [벨리데이터 노드로 업그레이드 하기](./validators/validator-setup.md)
|
||||
|
||||
## 자체 `gaia` 테스트넷 세팅하기
|
||||
|
||||
- [자체 `gaia` 테스트넷 세팅하기](./deploy-testnet.md)
|
||||
|
||||
## 추가 리소스
|
||||
|
||||
- [밸리데이터에 대한 소개](./validators/overview.md)
|
||||
- [밸리데이터 FAQ](./validators/validator-faq.md)
|
||||
- [밸리데이터가 알아야할 보안](./validators/security.md)
|
||||
|
|
@ -0,0 +1,426 @@
|
|||
# 위임자 가이드라인 (CLI)
|
||||
|
||||
이 분서는 위임자가 커맨드라인 인터페이스(CLI, Command-Line Interface)를 통해 코스모스 허브와 소통하기 위해 필요한 모든 정보를 포함하고 있습니다.
|
||||
|
||||
또한 계정 관리, 코스모스 펀드레이저로 받은 계정을 복구하는 방법, 그리고 렛저 나노 하드웨어 지갑 사용법 또한 포함되어있습니다.
|
||||
|
||||
__중요__: 이 문서에 설명되어있는 모든 단계를 신중하게 진행하십시오. 특정 행동의 실수는 소유하고 있는 아톰의 손실을 초래할 수 있습니다. 진행 전 이 문서에 있는 모든 절차를 자세히 확인하시고 필요시 코스모스 팀에게 연락하십시오. **이 문서는 참고용 정보를 제공하기 위해 번역된 영어 원문의 번역본입니다. 이 문서에 포함되어있는 정보의 완결성은 보장되지 않으며, 개인의 행동에 따른 손실을 책임지지 않습니다. 꼭 영어 원문을 참고하시기 바랍니다. 만약 이 문서의 정보와 영어 원문의 정보가 다른 경우, 영어 문서의 정보가 상위 권한을 가지게 됩니다.**
|
||||
|
||||
CLI를 사용하는 위임자는 매우 실험적인 블록체인 기술이 사용되고 있는 코스모스 허브를 사용하게됩니다. 코스모스 허브는 우수한 기술을 기반으로 다수의 보안 감사를 진행했으나 문제, 업데이트 그리고 버그가 존재할 수 있습니다. 또한 블록체인 기술을 사용하는 것은 상당한 기술적 배경을 필요로 하며, 공식 팀의 컨트롤 밖에 있는 리스크가 따릅니다. 유저는 이 소프트웨어를 사용함으로써 암호학 기반 소프트웨어를 사용하는 리스크를 인지하고 있음을 인정하는 것입니다. (참고 문서: [인터체인 코스모스 펀드레이저 약관](https://github.com/cosmos/cosmos/blob/master/fundraiser/Interchain%20Cosmos%20Contribution%20Terms%20-%20FINAL.pdf))
|
||||
|
||||
인터체인 재단(Interchain Foundation)과 텐더민트 팀은 소프트웨어 사용으로 발생하는 모든 손실에 대해서 책임을 지지 않습니다. Apache 2.0 라이선스 기반의 오픈소스 소프트웨어를 사용하는 것은 각 개인의 책임이며, 소프트웨어는 그 어떤 보증과 조건이 없는 'As Is(있는 그대로)' 기반으로 제공됩니다.
|
||||
|
||||
모든 행동은 신중하고 침착하게 진행하시기 바랍니다.
|
||||
|
||||
## 목차
|
||||
|
||||
- [`gaiacli` 설치하기](#installing-gaiacli)
|
||||
- [코스모스 계정](#cosmos-accounts)
|
||||
+ [펀드레이저 계정 복구하기](#restoring-an-account-from-the-fundraiser)
|
||||
+ [계정 생성하기](#creating-an-account)
|
||||
- [코스모스 허브 네트워크 액세스하기](#accessing-the-cosmos-hub-network)
|
||||
+ [자체 풀노드 운영하기](#running-your-own-full-node)
|
||||
+ [다른 풀노드와 연결하기](#connecting-to-a-remote-full-node)
|
||||
- [`gaiacli` 설정하기](#setting-up-gaiacli)
|
||||
- [상태(state) 조회하기](#querying-the-state)
|
||||
- [아톰 위임하기 / 위임 철회(unbond)하기 / 보상 수령하기](#bonding-atoms-and-withdrawing-rewards)
|
||||
- [거버넌스에 참여하기](#participating-in-governance)
|
||||
- [오프라인 컴퓨터에서 트랜잭션 서명하기](#signing-transactions-from-an-offline-computer)
|
||||
|
||||
## `gaiacli` 설치하기
|
||||
|
||||
`gaiacli`: `gaiacli`는 `gaiad` 풀노드와 소통하기 위해 사용되는 명령어 기반 인터페이스입니다.
|
||||
|
||||
::: 경고
|
||||
**추가적인 행동을 진행하기 전 최신 `gaiacli` 클라이언트를 다운로드 하셨는지 확인하십시오**
|
||||
:::
|
||||
|
||||
[**바이너리 설치하기**]
|
||||
|
||||
[**소스에서 설치하기**](https://cosmos.network/docs/gaia/installation.html)
|
||||
|
||||
## 코스모스 계정
|
||||
|
||||
모든 코스모스 계정에는 12개 또는 24개의 단어로 이루어진 '시드(Seed)'가 할당됩니다. 이 시드 단어(또는 시드 키)를 기반으로 다수의 코스모스 계정을 생성할 수 있습니다 (예를들어: 다수의 프라이빗 키/퍼블릭 키 쌍). 이런 형태의 월렛은 HD(Hierarchical deterministic) 월렛이라고 불립니다 (HD 월렛에 대한 자세한 정보는 [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)를 참고하세요).
|
||||
|
||||
|
||||
```
|
||||
계정 0 계정 1 계정 2
|
||||
|
||||
+------------------+ +------------------+ +------------------+
|
||||
| | | | | |
|
||||
| 주소 0 | | 주소 1 | | 주소 2 |
|
||||
| ^ | | ^ | | ^ |
|
||||
| | | | | | | | |
|
||||
| | | | | | | | |
|
||||
| | | | | | | | |
|
||||
| + | | + | | + |
|
||||
| 퍼블릭 키 0 | | 퍼블릭 키 1 | | 퍼블릭 키 2 |
|
||||
| ^ | | ^ | | ^ |
|
||||
| | | | | | | | |
|
||||
| | | | | | | | |
|
||||
| | | | | | | | |
|
||||
| + | | + | | + |
|
||||
| 프라이빗 키 0 | | 프라이빗 키 1 | | 프라이빗 키 2 |
|
||||
| ^ | | ^ | | ^ |
|
||||
+------------------+ +------------------+ +------------------+
|
||||
| | |
|
||||
| | |
|
||||
| | |
|
||||
+--------------------------------------------------------------------+
|
||||
|
|
||||
|
|
||||
+---------+---------+
|
||||
| |
|
||||
| Mnemonic (시드) |
|
||||
| |
|
||||
+-------------------+
|
||||
```
|
||||
특정 계좌에 보관된 자산은 프라이빗 키에 의해 관리됩니다. 이 프라이빗 키는 시드의 일방적 기능(one-way function)을 통해 생성됩니다. 프라이빗 키를 분실한 경우, 시드 키를 사용하여 프라이빗 키를 다시 복구하는 것이 가능합니다. 하지만 시드 키를 분실한 경우, 모든 프라이빗 키에 대한 사용권을 잃게 됩니다. 누군가 본인의 시드 키를 가진 경우, 해당 키와 연관된 모든 계정의 소유권을 가진 것과 동일합니다.
|
||||
|
||||
::: warning
|
||||
**12 단어 시드키를 분실하거나 그 누구와도 공유하지 마세요. 자금 탈취와 손실을 예방하기 위해서는 다수의 시드키 사본을 만드시고 금고 같이 본인만이 알 수 있는 안전한 곳에 보관하는 것을 추천합니다. 누군가 시드키를 가지게 된 경우, 관련 프라이빗 키와 모든 계정의 소유권을 가지게 됩니다.**
|
||||
:::
|
||||
|
||||
주소는 특정 계정을 구분하는 용도로 사용되며, 단어로 이루어진 특정 프리픽스(예, cosmos10)와 스트링 값을 조합한 값입니다 (예, `cosmos10snjt8dmpr5my0h76xj48ty80uzwhraqalu4eg`). 주소는 누군가 자산을 특정 계정으로 전송할때 사용되며, 퍼블릭키를 사용해 프라이빗 키를 추출하는 것은 불가능합니다.
|
||||
|
||||
### 펀드레이저 계정 복구하기
|
||||
|
||||
::: tip
|
||||
*참고: 이 항목은 코스모스 펀드레이저 참가자만을 위한 정보입니다*
|
||||
:::
|
||||
|
||||
코스모스 펀드레이저에 참가한 인원은 12개의 단어로 구성된 시드키를 부여받습니다. 새로 생성된 시드키는 24개 단어로 이루어졌으나, 12개 단어로 이루어진 시드키 또한 모든 코스모스가 제공하는 도구에서 호환됩니다.
|
||||
|
||||
#### 렛저(Ledger) 기기 사용하기
|
||||
|
||||
모든 렛저 기기에는 (코스모스 허브를 포함한) 다수의 블록체인에서 계정을 생성하기 위해 사용되는 시드키가 있습니다. 통상 시드키는 렛저 기기를 처음 활성화 할때 생성하지만, 유저가 시드키를 직접 입력하는 것 또한 가능합니다. 이제 펀드레이저를 통해 받은 시드키를 어떻게 렛저 하드웨어 지갑에 입력하는지 알아보겠습니다.
|
||||
|
||||
::: warning
|
||||
*참고: 이번 단계를 진행하실때 **한번도 사용되지 않은 신규 기기를 사용하는 것을 권장합니다**. 한 렛저 기기에는 하나의 시드키만을 입력할 수 있습니다. 만약 이미 사용하시던 하드웨어 지갑을 사용하시기를 바라는 경우, `Settings`>`Device`>`Reset All`를 통해 리셋을 진행한 후 펀드레이저 시드를 입력할 수 있습니다. **렛저 기기를 리셋할 경우, 기존에 사용했던 시드키는 기기에서 삭제됩니다. 리셋을 진행하기 전 기존 기기의 시드키를 백업하셨는지 확인하신 후 진행하시기 바랍니다.** 백업 되지 않은 상태로 기기를 리셋하는 경우, 관련 계정의 자산을 잃을 수 있습니다.*
|
||||
:::
|
||||
|
||||
|
||||
다음 단계는 신규 렛저 기기 또는 초기화 된 렛저 기기에서 진행되어야 합니다:
|
||||
|
||||
1. USB를 사용해 렛저 기기를 컴퓨터에 연결하세요
|
||||
2. 두개의 버튼을 동시에 누르세요
|
||||
3. "Restore Configuration"을 선택하세요. **"Config as a new device"를 선택하시면 안됩니다**
|
||||
4. 원하시는 핀 번호를 입력하세요
|
||||
5. 12-words 옵션을 선택하세요
|
||||
6. 코스모스 펀드레이저에서 부여 받은 시드키를 차례대로 정확하게 입력하세요
|
||||
|
||||
이제 렛저 하드웨어 지갑 기기가 펀드레이저 시드로 활성화되었습니다. 기존의 펀드레이저 시드를 파기하지 마십시오! 만약 렛저 기기가 고장나거나 분실된 경우, 동일한 시드키를 이용해 복구가 가능합니다.
|
||||
|
||||
이제 [여기](#using-a-ledger-device)를 클릭하여 계정을 생성하는 방법을 확인하세요.
|
||||
|
||||
#### 컴퓨터 사용하기
|
||||
|
||||
::: warning
|
||||
**참고: 다음 행동은 오프라인 상태인 컴퓨터에서 진행하는 것이 더욱 안전합니다.**
|
||||
:::
|
||||
|
||||
컴퓨터를 이용해 펀드레이저 시드키를 복구하시고 컴퓨터에 프라이빗 키를 저장사기 위해서는 다음 명령어를 실행하세요:
|
||||
|
||||
```bash
|
||||
gaiacli keys add <키 명칭 지정(YourKeyName)> --recover
|
||||
```
|
||||
|
||||
명령어를 입력하셨다면 프로그램이 지금 생성(복구)하시는 계정의 프라이빗 키를 암호화할때 사용될 비밀번호를 입력할 것을 요청합니다. 해당 계정을 이용해 트랜잭션을 보낼때마다 이 비밀번호를 입력하셔야 합니다. 만약 비밀번호를 잃어버리셨다면 시드키를 사용해 계정을 다시 복구할 수 있습니다.
|
||||
|
||||
- `<yourKeyName>` 은 계정의 이름입니다. 이는 시드키로부터 키 페어를 파생할때 레퍼런스로 사용됩니다. 이 이름은 토큰을 전송할때 보내는 계정을 구분하기 위해서 사용됩니다.
|
||||
- 추가적인 선택 사항으로 명령어에 `--account` 플래그를 추가해 특정 패스(`0`, `1`, `2`, 등)를 지정할 수 있습니다. 기본적으로 `0`을 사용하여 계정이 생성됩니다.
|
||||
|
||||
### 계정 생성하기
|
||||
|
||||
새로운 계정을 생성하기 위해서는 `gaiacli`를 설치해야합니다. 신규 계정을 생성하기 전, 프라이빗 키를 어디에 저장하고 어떻게 불러올지 미리 인지를 하셔야 합니다. 프라이빗 키를 보관하기 가장 좋은 곳은 오프라인 컴퓨터 또는 렛저 하드웨어 월렛 기기입니다. 흔히 사용되는 온라인 컴퓨터에 프라이빗 키를 보관하게 될 경우, 인터넷을 통해 컴퓨터를 침투한 공격자가 프라이빗 키를 탈취할 수 있기 때문에 상당한 리스크가 존재합니다.
|
||||
|
||||
#### 렛저(Ledger) 하드웨어 월렛 기기 사용하기
|
||||
|
||||
::: warning
|
||||
**새로 주문한 렛저 기기 또는 신뢰할 수 있는 렛저 기기만을 사용하세요**
|
||||
:::
|
||||
|
||||
렛저 기기를 처음 활성화할때 24개 단어로 구성된 시드키가 생성되고 기기에 저장됩니다. 렛저 기기의 시드키는 코스모스와 코스모스 계정과 호환이 되며, 해당 시드키를 기반으로 계정을 생성할 수 있습니다. 렛저 기기는 `gaiacli`와 호환될 수 있게 설정이 되어야 합니다. 렛저 기기를 설정하는 방법은 다음과 같습니다:
|
||||
|
||||
1. [Ledger Live 앱](https://www.ledger.com/pages/ledger-live) 다운로드
|
||||
2. 렛저 기기를 USB로 연결한 후 최신 펌웨어 버전으로 업데이트
|
||||
3. Ledger Live 앱스토어로 이동한 후, "Cosmos" 애플리케이션 다운로드. (이 단계는 다소 시간이 걸릴 수 있습니다)
|
||||
4. 렛저 기기에서 코스모스 앱 선택
|
||||
|
||||
계정을 생성하기 위해서는 다음 명령어를 실행하십시오:
|
||||
|
||||
```bash
|
||||
gaiacli keys add <키 명칭 지정(yourKeyName)> --ledger
|
||||
```
|
||||
|
||||
- `<yourKeyName>` 은 계정의 이름입니다. 이는 시드키로부터 키 페어를 파생할때 레퍼런스로 사용됩니다. 이 이름은 토큰을 전송할때 보내는 계정을 구분하기 위해서 사용됩니다.
|
||||
- 추가적인 선택 사항으로 명령어에 `--account` 플래그를 추가해 특정 패스(`0`, `1`, `2`, 등)를 지정할 수 있습니다. 기본적으로 `0`을 사용하여 계정이 생성됩니다.
|
||||
|
||||
#### 컴퓨터 사용하기
|
||||
|
||||
::: warning
|
||||
**참고: 다음 행동은 오프라인 상태인 컴퓨터에서 진행하는 것이 더욱 안전합니다.**
|
||||
:::
|
||||
|
||||
계정을 생성하기 위해서는 다음 명령어를 입력하세요:
|
||||
|
||||
```bash
|
||||
gaiacli keys add <키 명칭 지정(yourKeyName)>
|
||||
```
|
||||
|
||||
위 명령어는 새로운 24단어로 구성된 시드키를 생성하고, 계정 `0`의 프라이빗 키와 퍼블릭 키를 저장합니다. 이후, 디스크에 저장될 계정 `0`의 프라이빗 키를 암호화할때 사용될 비밀번호를 입력할 것을 요청합니다. 해당 계정을 이용해 트랜잭션을 보낼때마다 이 비밀번호를 입력하셔야 합니다. 만약 비밀번호를 잃어버리셨다면 시드키를 사용해 계정을 다시 복구할 수 있습니다.
|
||||
|
||||
::: danger
|
||||
**경고: 12 단어 시드키를 분실하거나 그 누구와도 공유하지 마세요. 자금 탈취와 손실을 예방하기 위해서는 다수의 시드키 사본을 만드시고 금고 같이 본인만이 알 수 있는 안전한 곳에 보관하는 것을 추천합니다. 누군가 시드키를 가지게 된 경우, 관련 프라이빗 키와 모든 계정의 소유권을 가지게 됩니다.**
|
||||
:::
|
||||
|
||||
::: warning
|
||||
시드키를 안전하게 보관하셨다면 (두번 세번씩이라도 정확하게 작성되었는지 확인하셔야 합니다!) 커맨드 라인의 기록을 다음과 같이 삭제하시면 됩니다:
|
||||
|
||||
```bash
|
||||
history -c
|
||||
rm ~/.bash_history
|
||||
```
|
||||
:::
|
||||
|
||||
- `<yourKeyName>` 은 계정의 이름입니다. 이는 시드키로부터 키 페어를 파생할때 레퍼런스로 사용됩니다. 이 이름은 토큰을 전송할때 보내는 계정을 구분하기 위해서 사용됩니다.
|
||||
- 추가적인 선택 사항으로 명령어에 `--account` 플래그를 추가해 특정 패스(`0`, `1`, `2`, 등)를 지정할 수 있습니다. 기본적으로 `0`을 사용하여 계정이 생성됩니다.
|
||||
|
||||
|
||||
동일한 시드키로 추가적인 계정을 생성하기 원한다면, 다음 명령어를 사용하세요:
|
||||
|
||||
```bash
|
||||
gaiacli keys add <키 명칭 지정(yourKeyName)> --recover --account 1
|
||||
```
|
||||
|
||||
해당 명령어는 비밀번호와 시드키를 입력할 것을 요청할 것입니다. 이 외에 추가적인 계정을 생성하시기 원한다면 account 플래그의 번호를 바꾸십시오.
|
||||
|
||||
|
||||
## 코스모스 허브 네트워크 사용하기
|
||||
|
||||
블록체인의 상태(state)를 확인하거나 트랜잭션을 전송하기 위해서는 직접 풀노드를 운영하거나 다른 사람이 운영하는 풀노드에 연결할 수 있습니다.
|
||||
|
||||
::: danger
|
||||
**경고: 12개 단어 / 24개 단어 시드키를 그 누구와도 공유하지 마세요. 시드키는 본인만이 알고있어야 합니다. 특히 이메일, 메시지 등의 수단으로 블록체인 서비스 지원을 사칭해 시드키를 요청할 수 있으니 주의를 바랍니다. 코스모스 팀, 텐더민트 팀 그리고 인터체인 재단은 절대로 이메일을 통해 개인 정보 또는 시드키를 요청하지 않습니다.**.
|
||||
:::
|
||||
|
||||
### 직접 풀노드 운영하기
|
||||
|
||||
이 방법이 가장 안전한 방법이지만, 대량의 리소스를 필요로 합니다. 풀노드를 직접 운영하기 위해서는 우수한 인터넷 대역폭과 최소 1TB 상당의 하드디스크 용량을 필요로 합니다.
|
||||
|
||||
[풀노드를 운영하는 절차](https://cosmos.network/docs/gaia/join-testnet.html)와 [`gaiad`를 설치하는 방법](https://cosmos.network/docs/gaia/installation.html)은 첨부된 링크를 확인하세요.
|
||||
|
||||
### 외부 풀노드에 연결하기
|
||||
|
||||
만약 본인이 직접 풀노드를 운영하는 것을 원하지 않는다면 다른 사람의 풀노드에 연결을 할 수 있습니다. 이 과정에서는 신뢰할 수 있는 풀노드 운영자에만 연결하세요. 악의적인 풀노드 운영자는 트랜잭션을 막거나 틀린 정보를 전달할 가능성이 있습니다. 하지만 프라이빗 키는 당신의 컴퓨터/렛저 기기에 저장되어 있기 때문에 풀노드 운영자는 절대로 자금을 탈취할 수 없습니다. 검증된 검증인, 월렛 제공자, 거래소 등의 풀노드에만 연결하는 것을 추천드립니다.
|
||||
|
||||
풀노드에 연결하기 위해서는 다음과 같은 형식의 주소가 필요합니다: `https://77.87.106.33:26657` (*이는 예시를 위한 주소이며 실제 풀노드 주소가 아닙니다*). 이 계정은 신뢰할 수 있는 풀노드 운영자에게서 직접 받으시기 바랍니다. 이 주소는 [다음 항목](#setting-up-gaiacli)에서 사용됩니다.
|
||||
|
||||
## `gaiacli` 설정하기
|
||||
|
||||
::: warning
|
||||
**`gaiacli`의 최신 스테이블 버전을 사용하고 있는지 확인해주세요**
|
||||
:::
|
||||
|
||||
`gaiacli`는 코스모스 허브 네트워크에서 운영되고 있는 노드와 소통할 수 있게 하는 도구입니다. 풀노드는 본인이 직접 운영하거나, 타인이 운영하는 풀노드를 사용할 수 있습니다. 이제 `gaiacli`의 설정을 진행하겠습니다.
|
||||
|
||||
`gaiacli`을 설정하기 위해서는 다음 명령어를 실행하세요:
|
||||
|
||||
```bash
|
||||
gaiacli config <플래그(flag)> <값(value)>
|
||||
```
|
||||
|
||||
해당 명령어는 각 플래그에 대한 값을 설정할 수 있게 합니다. 우선 연결하고 싶은 풀노드의 주소를 입력하겠습니다:
|
||||
|
||||
|
||||
```bash
|
||||
gaiacli config node <호스트(host)>:<포트(port)>
|
||||
|
||||
// 예시: gaiacli config node https://77.87.106.33:26657
|
||||
```
|
||||
|
||||
만약 풀노드를 직접 운영하시는 경우, `tcp://localhost:26657`을 주소 값으로 입력하세요.
|
||||
|
||||
이제 `--trust-node` 플래그의 값을 설정하겠습니다:
|
||||
|
||||
```bash
|
||||
gaiacli config trust-node false
|
||||
|
||||
// 만약 라이트 클라이언트 노드를 운영하고 싶으신 경우 `true` 값을 입력하세요. 그렇지 않은 경우 `false`를 입력하세요
|
||||
```
|
||||
|
||||
마지막으로 소통하고 싶은 블록체인의 `chain-id`를 입력하겠습니다:
|
||||
|
||||
```bash
|
||||
gaiacli config chain-id gos-3
|
||||
```
|
||||
|
||||
## 블록체인 상태 조회하기
|
||||
|
||||
[`gaiacli`](https://cosmos.network/docs/gaia/gaiacli.html)는 계정 잔고, 스테이킹 중인 토큰 수량, 지급 가능한 보상, 거버넌스 프로포절 등 블록체인과 관련된 모든 정보를 확인할 수 있게 합니다. 다음은 위임자에게 유용한 명령어들입니다. 다음 명령어를 실행하기 전 [gaiacli 설정](#setting-up-gaiacli)을 진행하세요.
|
||||
|
||||
```bash
|
||||
// 계정 잔고와 계정 관련 정보 조회
|
||||
gaiacli query account
|
||||
|
||||
// 검증인 목록 조회
|
||||
gaiacli query validators
|
||||
|
||||
// 검증인 주소로 (예시: cosmos10snjt8dmpr5my0h76xj48ty80uzwhraqalu4eg) 검증인 정보 조회
|
||||
gaiacli query validator <검증인 주소(validatorAddress)>
|
||||
|
||||
// 위임자 주소로 (예시: cosmos10snjt8dmpr5my0h76xj48ty80uzwhraqalu4eg) 계정의 모든 위임 기록 조회
|
||||
gaiacli query delegations <위임자 주소(delegatorAddress)>
|
||||
|
||||
// 위임자가 특정 검증인에게 위임한 기록 조회
|
||||
gaiacli query delegations <위임자 주소(delegatorAddress)> <검증인 주소(validatorAddress)>
|
||||
|
||||
// 위임자 주소로 (예시: cosmos10snjt8dmpr5my0h76xj48ty80uzwhraqalu4eg) 위임자 리워드 조회
|
||||
gaiacli query distr rewards <위임자 주소(delegatorAddress)>
|
||||
|
||||
// 예치금(deposit)을 대기중인 모든 프로포절 조회
|
||||
gaiacli query proposals --status deposit_period
|
||||
|
||||
// 투표가 가능한 모든 프로포절 조회
|
||||
gaiacli query proposals --status voting_period
|
||||
|
||||
// 특정 프로포절 ID로 프로포절 정보 조회
|
||||
gaiacli query proposal <proposalID>
|
||||
```
|
||||
|
||||
더 많은 명령어를 확인하기 위해서는 다음 명령어를 실행하세요:
|
||||
|
||||
```bash
|
||||
gaiacli query
|
||||
```
|
||||
|
||||
각 명령어에는 `-h` 또는 `--help`를 추가하여 관련 정보를 확인하실 수 있습니다.
|
||||
|
||||
## 아톰 위임하기 / 리워드 수령하기
|
||||
|
||||
::: warning
|
||||
**아톰을 위임하기 전에 [위임자 faq](https://cosmos.network/resources/delegators)를 먼저 확인하시고 위임에 따르는 책임과 위험을 사전에 인지하시기 바랍니다**
|
||||
:::
|
||||
|
||||
::: warning
|
||||
**참고: 다음 명령어는 온라인 상태인 컴퓨터에서 실행되어야 합니다. 해당 명령은 렛저 하드웨어 월렛 기기를 사용해 실행하는 것을 추천드립니다. 오프라인으로 트랜잭션을 발생하는 방법을 확인하기 위해서는 [여기](#signing-transactions-from-an-offline-computer)를 참고하세요.**
|
||||
:::
|
||||
|
||||
```bash
|
||||
// 아톰 위임하기
|
||||
// 각 플래그 값 예시: <위임할 수량(amountToBound)> = 10000stake, <검증인의 bech32 주소(bech32AddressOfValidator)> = cosmosvaloper18thamkhnj9wz8pa4nhnp9rldprgant57pk2m8s, <가스 가격(gasPrice)> = 0.001stake
|
||||
|
||||
gaiacli tx staking --amount <위임할 수량(amountToBond)> --validator <검증인의 bech32 주소(bech32AddressOfValidator)> --from <위임자 키 명칭(delegatorKeyName)> --gas auto --gas-prices <가스 가격(gasPrice)>
|
||||
|
||||
// 리워드 수령하기
|
||||
|
||||
gaiacli tx distr withdraw-rewards --from <위임자 키 명칭(delegatorKeyName)>
|
||||
```
|
||||
|
||||
::: tip
|
||||
렛저 기기를 사용해 트랜잭션을 발생하시는 경우, 기기에서 트랜잭션을 확인하는 과정이 추가적으로 발생됩니다. 기기에서 트랜잭션을 서명하셔야 네트워크로 전파됩니다
|
||||
:::
|
||||
|
||||
해당 트랜잭션이 성공적으로 진행된 것을 확인하기 위해서는 다음 조회 명령어를 사용하세요:
|
||||
|
||||
```bash
|
||||
// 아톰을 위임하거나 리워드를 수령하신 후 계정 잔고가 달라집니다 (계정 잔고 확인 명령어)
|
||||
gaiacli query account
|
||||
|
||||
// 위임을 진행하셨다면 스테이킹 잔고가 표시됩니다 (스테이킹 확인 명령어)
|
||||
gaiacli query delegations <위임자 주소(delegatorAddress)>
|
||||
|
||||
// 트랜잭션이 블록체인에 포함되었으면 해당 tx 정보를 전달합니다
|
||||
// 트랜잭션을 생성하셨을때 표시되었던 tx hash를 입력하세요 (트랜잭션 확인 명령어)
|
||||
gaiacli query tx <tx 해시값(txHash)>
|
||||
|
||||
```
|
||||
|
||||
만약 외부 풀노드를 통해서 블록체인을 사용하신 경우 블록 익스플로러를 통해 트랜잭션을 확인하십시오.
|
||||
|
||||
### 가스와 수수료에 대해서
|
||||
|
||||
코스모스 허브 네트워크는 트랜잭션 처리를 위해 트랜잭션 수수료를 부과합니다. 해당 수수료는 트랜잭션을 실행하기 위한 가스로 사용됩니다. 공식은 다음과 같습니다:
|
||||
|
||||
|
||||
```
|
||||
수수료(Fee) = 가스(Gas) * 가스 값(GasPrices)
|
||||
```
|
||||
|
||||
위 공식에서 `gas`는 전송하는 트랜잭션에 따라 다릅니다. 다른 형태의 트랜잭션은 각자 다른 `gas`량을 필요로 합니다. `gas` 수량은 트랜잭션이 실행될때 계산됨으로 사전에 정확한 값을 확인할 수 있는 방법은 없습니다. 다만, `gas` 플래그의 값을 `auto`로 설정함으로 예상 값을 추출할 수는 있습니다. 예상 값을 수정하기 위해서는 `--gas-adjustment` (기본 값 `1.0`) 플래그 값을 변경하셔서 트랜잭션이 충분한 가스를 확보할 수 있도록 하십시오.
|
||||
|
||||
`gasPrice`는 각 `gas` 유닛의 가격입니다. 각 검증인은 직접 최소 가스 가격인 `min-gas-price`를 설정하며, 트랜잭션의 `gasPrice`가 설정한 `min-gas-price`보다 높을때 트랜잭션을 처리합니다.
|
||||
|
||||
트랜잭션 피(`fees`)는 `gas` 수량과 `gasPrice`를 곱한 값입니다. 유저는 3개의 값 중 2개의 값을 입력하게 됩니다. `gasPrice`가 높을수록 트랜잭션이 블록에 포함될 확률이 높아집니다.
|
||||
|
||||
## 거버넌스 참가하기
|
||||
|
||||
### 거버넌스에 대해서
|
||||
|
||||
코스모스 허브는 아톰을 스테이킹 한 위임자들이 투표를 할 수 있는 시스템이 내장되어있습니다. 프로포절의 종류는 3개가 있으며 다음과 같습니다:
|
||||
|
||||
- `텍스트 프로포절(Text Proposals)`: 가장 기본적인 형태의 프로포절입니다. 특정 주제에 대한 네트워크의 의견을 확인하기 위해서 사용됩니다.
|
||||
- `파라미터 프로포절(Parameter Proposals)`: 네트워크의 기존 파라미터 값을 변경하는 것을 제안하기 위해서 사용됩니다.
|
||||
- `소프트웨어 업그레이드 프로포절(Software Upgrade Proposal)`: 코스모스 허브의 소프트웨어를 업그레이드 하는 것을 제안하기 위해서 사용됩니다.
|
||||
|
||||
모든 아톰 보유자는 프로포절을 제안할 수 있습니다. 특정 프로포절의 투표가 활성화되기 위해서는 `minDeposit`값에 정의된 예치금 보다 높은 `deposit` 비용이 예치되어야 합니다. `deposit`은 프로포절 제안자 외에도 예치를 할 수 있습니다. 만약 제안자가 충분하지 않은 `deposit`을 예치한 경우, 프로포절은 `deposit_period` 상태로 들어가 추가 예치금을 대기합니다. 모든 아톰 보유자는 `depositTx` 트랜잭션을 통해 예치금을 추가할 수 있습니다.
|
||||
|
||||
프로포절의 `deposit`이 `minDeposit`을 도달하게 되면 해당 프로포절의 2주 간의 `voting_period`(투표 기간)이 시작됩니다. **위임된 아톰**의 보유자는 해당 프로포절에 투표를 행사할 수 있으며, `Yes`, `No`, `NoWithVeto` 또는 `Abstain` 표를 선택할 수 있습니다. 각 표는 투표자의 위임된 아톰 수량을 반영하게 됩니다. 만약 위임자가 직접 투표를 진행하지 않은 경우, 위임자는 검증인의 표를 따르게 됩니다. 하지만 모든 위임자는 직접 투표를 행사하여 검증인의 표와 다른 표를 행사할 수 있습니다.
|
||||
|
||||
투표 기간이 끝난 후, 프로포절이 50% 이상의 `Yes`표를 받았고 (`Abstain` 표를 제외하고) `NoWithVeto` (`Abstain` 표를 제외하고) 표가 33.33% 이하일 경우 통과하게 됩니다.
|
||||
|
||||
### 거버넌스 트랜잭션
|
||||
|
||||
::: warning
|
||||
**참고: 다음 명령어는 온라인 상태인 컴퓨터에서만 진행이 가능합니다. 해당 명령은 렛저 하드웨어 월렛 기기를 사용해 실행하는 것을 추천드립니다. 오프라인으로 트랜잭션을 발생하는 방법을 확인하기 위해서는 [여기](#signing-transactions-from-an-offline-computer)를 참고하세요.**
|
||||
:::
|
||||
|
||||
```bash
|
||||
// 프로포절 제안하기
|
||||
// <프로포절 종류(type)>=text/parameter_change/software_upgrade
|
||||
// 플래그 값 예시: <가스 가격(gasPrice)>=0.0001stake
|
||||
|
||||
gaiacli tx gov submit-proposal --title "Test Proposal" --description "My awesome proposal" --type <프로포절 종류(type)> --deposit=10stake --gas auto --gas-prices <가스 가격(gasPrice)> --from <위임자 키 명칭(delegatorKeyName)>
|
||||
|
||||
// 프로포절의 예치금 추가하기
|
||||
// 프로포절의 proposalID 조회: $gaiacli query gov proposals --status deposit_period
|
||||
// 파라미터 값 예시: <예치금(deposit)>=1stake
|
||||
|
||||
gaiacli tx gov deposit <프로포절 ID(proposalID)> <추가할 예치금(deposit)> --gas auto --gas-prices <가스 가격(gasPrice)> --from <위임자 키 명칭(delegatorKeyName)>
|
||||
|
||||
// 프로포절에 투표하기
|
||||
// 프로포절의 proposalID 조회: $gaiacli query gov proposals --status voting_period
|
||||
// <표 선택(option)>=yes/no/no_with_veto/abstain
|
||||
|
||||
gaiacli tx gov vote <프로포절 ID(proposalID)> <표 선택(option)> --gas auto --gas-prices <가스 가격(gasPrice)> --from <위임자 키 명칭(delegatorKeyName)>
|
||||
```
|
||||
|
||||
## 오프라인 컴퓨터에서 트랜잭션 서명하기
|
||||
|
||||
렛저 기기가 없거나 오프라인 컴퓨터에서 프라이빗 키를 관리하고 싶으신 경우, 다음 절차를 따라하세요. 우선 **온라인** 컴퓨터에서 미서명 트랜잭션을 다음과 같이 생성하십시오 (예시 명령어에는 본딩 트랜잭션이 포함되어 있습니다):
|
||||
|
||||
```bash
|
||||
// 아톰 본딩하기
|
||||
// 플래그 값 예시: <본딩할 수량(amountToBond)>=10000stake, <위임할 검증인의 bech32 주소(bech32AddressOfValidator)>=cosmosvaloper18thamkhnj9wz8pa4nhnp9rldprgant57pk2m8s, <가스 가격(gasPrice)>=0.001stake
|
||||
|
||||
gaiacli tx staking --amount <본딩할 수량(amountToBond)> --validator <위임할 검증인의 bech32 주소(bech32AddressOfValidator)> --gas auto --gas-prices <가스 가격(gasPrice)> --generate-only > unsignedTX.json
|
||||
```
|
||||
|
||||
이후 서명이 진행되지 않은 `unsignedTx.json` 파일을 복사하신 후 (USB 등을 이용하여) 오프라인 컴퓨터로 이동하십시오. 만약 오프라인 컴퓨터에 아직 계정을 생성하지 않으셨을 경우, [이 항목](#using-a-computer)을 참고하여 오프라인 컴퓨터에서 계정을 생성하세요. 안전을 위해서 서명하기 전에 다음 명령어를 실행해 트랜잭션의 파라미터를 한번 더 확인하십시오:
|
||||
|
||||
```bash
|
||||
cat unsignedTx.json
|
||||
```
|
||||
|
||||
이제 다음 명령어를 실행해 트랜잭션을 서명합니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx sign unsignedTx.json --from <위임자 키 명칭(delegatorKeyName)> > signedTx.json
|
||||
```
|
||||
|
||||
서명된 `signedTx.json` 파일을 복사하시고 다시 온라인 컴퓨터로 이동하세요. 다음 명령어를 실행해 해당 트랜잭션을 네트워크에 전파하세요:
|
||||
|
||||
```bash
|
||||
gaiacli tx broadcast signedTx.json
|
||||
```
|
||||
|
|
@ -0,0 +1,249 @@
|
|||
# 자체 테스트넷 구축하기
|
||||
|
||||
해당 문서는 `gaiad` 노드 네트워크를 구축하는 세가지 방법을 제시합니다. 각 모델은 다른 이용 사례에 특화되어 있습니다.
|
||||
|
||||
1. 싱글-노드, 로컬, 수동 테스트넷
|
||||
2. 멀티-노드, 로컬, 자동 테스트넷
|
||||
3. 멀티-노드, 리모트, 자동 테스트넷
|
||||
|
||||
관련 코드는 [네트워크 디렉토리](https://github.com/cosmos/cosmos-sdk/tree/develop/networks)와 하단의 `local`과 `remote` 서브 디렉토리에서 찾으실 수 있습니다.
|
||||
|
||||
> 참고: 현재 `remote` 관련 정보는 최신 릴리즈와 호환성이 맞지 않을 수 있으므로 참고하시기 바랍니다.
|
||||
|
||||
## 싱글-노드, 로컬, 수동 테스트넷
|
||||
|
||||
이 가이드는 하나의 검증인 노드를 로컬 환경에서 운영하는 방식을 알려드립니다. 이런 환경은 테스트/개발 환경을 구축하는데 이용될 수 있습니다.
|
||||
|
||||
### 필수 사항
|
||||
|
||||
- [gaia 설치](./installation.md)
|
||||
- [`jq` 설치](https://stedolan.github.io/jq/download/) (선택 사항)
|
||||
|
||||
### 제네시스 파일 만들기, 네트워크 시작하기
|
||||
|
||||
```bash
|
||||
# You can run all of these commands from your home directory
|
||||
cd $HOME
|
||||
|
||||
# Initialize the genesis.json file that will help you to bootstrap the network
|
||||
gaiad init --chain-id=testing testing
|
||||
|
||||
# Create a key to hold your validator account
|
||||
gaiacli keys add validator
|
||||
|
||||
# Add that key into the genesis.app_state.accounts array in the genesis file
|
||||
# NOTE: this command lets you set the number of coins. Make sure this account has some coins
|
||||
# with the genesis.app_state.staking.params.bond_denom denom, the default is staking
|
||||
gaiad add-genesis-account $(gaiacli keys show validator -a) 1000stake,1000validatortoken
|
||||
|
||||
# Generate the transaction that creates your validator
|
||||
gaiad gentx --name validator
|
||||
|
||||
# Add the generated bonding transaction to the genesis file
|
||||
gaiad collect-gentxs
|
||||
|
||||
# Now its safe to start `gaiad`
|
||||
gaiad start
|
||||
```
|
||||
|
||||
이 셋업은 모든 `gaiad` 정보를 `~/.gaiad`에 저장힙니다. 생성하신 제네시스 파일을 확인하고 싶으시다면 `~/.gaiad/config/genesis.json`에서 확인이 가능합니다. 위의 세팅으로 `gaiacli`가 이용이 가능하며, 토큰(스테이킹/커스텀)이 있는 계정 또한 함께 생성됩니다.
|
||||
|
||||
## 멀티 노드, 로컬, 자동 테스트넷
|
||||
|
||||
관련 코드 [networks/local 디렉토리](https://github.com/cosmos/cosmos-sdk/tree/develop/networks/local):
|
||||
|
||||
### 필수 사항
|
||||
|
||||
- [gaia 설치](./installation.md)
|
||||
- [docker 설치](https://docs.docker.com/engine/installation/)
|
||||
- [docker-compose 설치](https://docs.docker.com/compose/install/)
|
||||
|
||||
### 빌드
|
||||
|
||||
`localnet` 커맨드를 운영하기 위한 `gaiad` 바이너리(리눅스)와 `tendermint/gaiadnode` docker 이미지를 생성합니다. 해당 바이너리는 컨테이너에 마운팅 되며 업데이트를 통해 이미지를 리빌드 하실 수 있습니다.
|
||||
|
||||
Build the `gaiad` binary (linux) and the `tendermint/gaiadnode` docker image required for running the `localnet` commands. This binary will be mounted into the container and can be updated rebuilding the image, so you only need to build the image once.
|
||||
|
||||
```bash
|
||||
# Work from the SDK repo
|
||||
cd $GOPATH/src/github.com/cosmos/cosmos-sdk
|
||||
|
||||
# Build the linux binary in ./build
|
||||
make build-linux
|
||||
|
||||
# Build tendermint/gaiadnode image
|
||||
make build-docker-gaiadnode
|
||||
```
|
||||
|
||||
### 테스트넷 실행하기
|
||||
|
||||
4개 노드 테스트넷을 실행하기 위해서는:
|
||||
|
||||
```
|
||||
make localnet-start
|
||||
```
|
||||
|
||||
이 커맨드는 4개 노드로 구성되어있는 네트워크를 gaiadnode 이미지를 기반으로 생성합니다. 각 노드의 포트는 하단 테이블에서 확인하실 수 있습니다:
|
||||
|
||||
|
||||
| 노드 ID | P2P 포트 | RPC 포트 |
|
||||
| --------|-------|------|
|
||||
| `gaianode0` | `26656` | `26657` |
|
||||
| `gaianode1` | `26659` | `26660` |
|
||||
| `gaianode2` | `26661` | `26662` |
|
||||
| `gaianode3` | `26663` | `26664` |
|
||||
|
||||
바이너리를 업데이트 하기 위해서는 리빌드를 하신 후 노드를 재시작 하시면 됩니다:
|
||||
|
||||
```
|
||||
make build-linux localnet-start
|
||||
```
|
||||
|
||||
### 설정
|
||||
|
||||
`make localnet-start`는 `gaiad testnet` 명령을 호출하여 4개 노드로 구성된 테스트넷에 필요한 파일을 `./build`에 저장합니다. 이 명령은 `./build` 디렉토리에 다수의 파일을 내보냅니다.
|
||||
|
||||
|
||||
```bash
|
||||
$ tree -L 2 build/
|
||||
build/
|
||||
├── gaiacli
|
||||
├── gaiad
|
||||
├── gentxs
|
||||
│ ├── node0.json
|
||||
│ ├── node1.json
|
||||
│ ├── node2.json
|
||||
│ └── node3.json
|
||||
├── node0
|
||||
│ ├── gaiacli
|
||||
│ │ ├── key_seed.json
|
||||
│ │ └── keys
|
||||
│ └── gaiad
|
||||
│ ├── ${LOG:-gaiad.log}
|
||||
│ ├── config
|
||||
│ └── data
|
||||
├── node1
|
||||
│ ├── gaiacli
|
||||
│ │ └── key_seed.json
|
||||
│ └── gaiad
|
||||
│ ├── ${LOG:-gaiad.log}
|
||||
│ ├── config
|
||||
│ └── data
|
||||
├── node2
|
||||
│ ├── gaiacli
|
||||
│ │ └── key_seed.json
|
||||
│ └── gaiad
|
||||
│ ├── ${LOG:-gaiad.log}
|
||||
│ ├── config
|
||||
│ └── data
|
||||
└── node3
|
||||
├── gaiacli
|
||||
│ └── key_seed.json
|
||||
└── gaiad
|
||||
├── ${LOG:-gaiad.log}
|
||||
├── config
|
||||
└── data
|
||||
```
|
||||
|
||||
각 `./build/nodeN` 디렉토리는 각자 컨테이너 안에 있는 `/gaiad`에 마운팅 됩니다.
|
||||
|
||||
### 로깅
|
||||
|
||||
로그는 각 `./build/nodeN/gaiad/gaia.log`에 저장됩니다. 로그는 docker를 통해서 바로 확인하실 수도 있습니다:
|
||||
|
||||
```
|
||||
docker logs -f gaiadnode0
|
||||
```
|
||||
|
||||
### 키와 계정
|
||||
|
||||
`gaiacli`를 이용해 tx를 생성하거나 상태를 쿼리 하시려면, 특정 노드의 `gaiacli` 디렉토리를 `home`처럼 이용하시면 됩니다. 예를들어:
|
||||
|
||||
|
||||
```shell
|
||||
gaiacli keys list --home ./build/node0/gaiacli
|
||||
```
|
||||
이제 계정이 존재하니 추가로 새로운 계정을 만들고 계정들에게 토큰을 전송할 수 있습니다.
|
||||
|
||||
::: tip
|
||||
**참고**: 각 노드의 시드는 `./build/nodeN/gaiacli/key_seed.json`에서 확인이 가능하며 `gaiacli keys add --restore` 명령을 통해 CLI로 복원될 수 있습니다.
|
||||
:::
|
||||
|
||||
### 특수 바이너리
|
||||
|
||||
다수의 이름을 가진 다수의 바이너리를 소유하신 경우, 어떤 바이너리의 환경 변수(environment variable)를 기준으로 실행할지 선택할 수 있습니다. 바이너리의 패스(path)는 관련 볼륨(volume)에 따라 달라집니다. 예시:
|
||||
```
|
||||
# Run with custom binary
|
||||
BINARY=gaiafoo make localnet-start
|
||||
```
|
||||
|
||||
## 멀티 노드, 리모트, 자동 테스트넷
|
||||
|
||||
다음 환경은 [네트워크 디렉터리](https://github.com/cosmos/cosmos-sdk/tree/develop/networks)에서 실행하셔야 합니다.
|
||||
|
||||
### Terraform 과 Ansible
|
||||
|
||||
자동 디플로이멘트(deployment)는 [Terraform](https://www.terraform.io/)를 이용해 AWS 서버를 만든 후 [Ansible](http://www.ansible.com/)을 이용해 해당 서버에서 테스트넷을 생성하고 관리하여 운영됩니다.
|
||||
|
||||
### 필수 사항
|
||||
|
||||
- [Terraform](https://www.terraform.io/downloads.html) 과 [Ansible](http://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html)를 리눅스 머신에 설치.
|
||||
- EC2 create 권한이 있는 [AWS API 토큰](https://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html) 생성
|
||||
- SSH 키 생성.
|
||||
|
||||
```
|
||||
export AWS_ACCESS_KEY_ID="2345234jk2lh4234"
|
||||
export AWS_SECRET_ACCESS_KEY="234jhkg234h52kh4g5khg34"
|
||||
export TESTNET_NAME="remotenet"
|
||||
export CLUSTER_NAME= "remotenetvalidators"
|
||||
export SSH_PRIVATE_FILE="$HOME/.ssh/id_rsa"
|
||||
export SSH_PUBLIC_FILE="$HOME/.ssh/id_rsa.pub"
|
||||
```
|
||||
|
||||
해당 명령은 `terraform` 과 `ansible`에서 이용됩니다..
|
||||
|
||||
### 리모트 네트워크 만들기
|
||||
|
||||
```
|
||||
SERVERS=1 REGION_LIMIT=1 make validators-start
|
||||
```
|
||||
|
||||
테스트넷 이름은 --chain-id에서 이용될 값이며, 클러스터 이름은 AWS 서버 관리 태그에서 이용될 값입니다. 코드는 각 존의
|
||||
|
||||
The testnet name is what's going to be used in --chain-id, while the cluster name is the administrative tag in AWS for the servers. The code will create SERVERS amount of servers in each availability zone up to the number of REGION_LIMITs, starting at us-east-2. (us-east-1 is excluded.) The below BaSH script does the same, but sometimes it's more comfortable for input.
|
||||
|
||||
```
|
||||
./new-testnet.sh "$TESTNET_NAME" "$CLUSTER_NAME" 1 1
|
||||
```
|
||||
|
||||
### Quickly see the /status endpoint
|
||||
|
||||
```
|
||||
make validators-status
|
||||
```
|
||||
|
||||
### Delete servers
|
||||
|
||||
```
|
||||
make validators-stop
|
||||
```
|
||||
|
||||
### Logging
|
||||
|
||||
You can ship logs to Logz.io, an Elastic stack (Elastic search, Logstash and Kibana) service provider. You can set up your nodes to log there automatically. Create an account and get your API key from the notes on [this page](https://app.logz.io/#/dashboard/data-sources/Filebeat), then:
|
||||
|
||||
```
|
||||
yum install systemd-devel || echo "This will only work on RHEL-based systems."
|
||||
apt-get install libsystemd-dev || echo "This will only work on Debian-based systems."
|
||||
|
||||
go get github.com/mheese/journalbeat
|
||||
ansible-playbook -i inventory/digital_ocean.py -l remotenet logzio.yml -e LOGZIO_TOKEN=ABCDEFGHIJKLMNOPQRSTUVWXYZ012345
|
||||
```
|
||||
|
||||
### Monitoring
|
||||
|
||||
You can install the DataDog agent with:
|
||||
|
||||
```
|
||||
make datadog-install
|
||||
```
|
||||
|
|
@ -0,0 +1,758 @@
|
|||
# Gaia 클라이언트
|
||||
|
||||
## Gaia CLI
|
||||
|
||||
::: tip 참고
|
||||
다음과 같은 에러 메시지가 나오는 경우:
|
||||
|
||||
```bash
|
||||
Must specify these options: --chain-id when --trust-node is false
|
||||
```
|
||||
|
||||
라이트 클라이언트 증거를 검증할지 선택하셔야 합니다. 만약 쿼리를 요청하고 있는 노드를 신뢰할 수 있다면, `--trust-node=true`를 입력하시고, 그렇지 않다면 `--chain-id`를 입력하세요.
|
||||
:::
|
||||
|
||||
`gaiacli`는 코스모스 테스트넷에서 이루어지는 트랜잭션과 계정을 관리하는 커맨드 라인 인터페이스입니다. 다음은 유용할 수 있는 `gaiacli` 명령어입니다:
|
||||
|
||||
`gaiacli`의 설정 파일은 `$HOME/.gaiacli/config/config.toml` 경로에 저장되며, 파일 수정 또는 `gaiacli config` 명령어를 통해 수정할 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli config chain-id gaia-9004
|
||||
```
|
||||
|
||||
명령어 사용에 관련한 정보는 help를 참고하세요: `gaiacli config --help`.
|
||||
|
||||
이 문서에는 유용한 `gaiacli` 명령어와 예시가 포함되어있습니다.
|
||||
|
||||
### 키(Keys)
|
||||
|
||||
#### 키 종류
|
||||
|
||||
키의 형태는 총 3개가 있습니다:
|
||||
|
||||
- `cosmos`
|
||||
- `gaiacli keyts add`로 생성되는 계정 키
|
||||
- 자금을 받는데 사용
|
||||
- 예시) `cosmos15h6vd5f0wqps26zjlwrc6chah08ryu4hzzdwhc`
|
||||
|
||||
* `cosmosvaloper`
|
||||
- 특정 검증인을 운영자와 연관하는데 사용됨
|
||||
- 스테이킹 명령 요청에 이용됨
|
||||
- 예시) `cosmosvaloper1carzvgq3e6y3z5kz5y6gxp3wpy3qdrv928vyah`
|
||||
|
||||
- `cosmospub`
|
||||
- `gaiacli keys add`로 생성되는 계정 키
|
||||
- 예시) `cosmospub1zcjduc3q7fu03jnlu2xpl75s2nkt7krm6grh4cc5aqth73v0zwmea25wj2hsqhlqzm`
|
||||
- `cosmosvalconspub`
|
||||
- `gaiad init`로 새로운 노드가 생성될때 같이 생성되는 키.
|
||||
- `gaiad tendermint show-validator` 명령으로 키 값을 확인할 수 있음
|
||||
- 예시) `cosmosvalconspub1zcjduepq0ms2738680y72v44tfyqm3c9ppduku8fs6sr73fx7m666sjztznqzp2emf`
|
||||
|
||||
#### 키 생성하기
|
||||
|
||||
자금을 받거나, 트랜잭션을 전송하거나, 스테이킹을 하기 위해서는 프라이빗 키(`sk`)와 퍼블릭 키(`pk`) 쌍이 필요합니다.
|
||||
|
||||
새로운 _secp256k1_ 키를 생성하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli keys add <account_name>
|
||||
```
|
||||
|
||||
새로운 키를 생성하는 과정에서 나오는 _시트키(seed phrase)_ 는 안전하게 저장하시길 바랍니다. 시드키는 다음과 같은 명령을 이용해 잊어버린 퍼블릭/프라이빗 키를 복구하는데 이용됩니다:
|
||||
|
||||
```bash
|
||||
gaiacli keys add --recover
|
||||
```
|
||||
|
||||
이제 프라이빗 키를 확인하고 `<account_name>`을 찾으면 됩니다:
|
||||
|
||||
```bash
|
||||
gaiacli keys show <account_name>
|
||||
```
|
||||
|
||||
검증인 운영자 주소는 다음과 같이 확인하시고:
|
||||
|
||||
```shell
|
||||
gaiacli keys show <account_name> --bech=val
|
||||
```
|
||||
|
||||
관련 되어 있는 모든 키 목록은 다음 명령어로 찾으실 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli keys list
|
||||
```
|
||||
|
||||
본인 노드의 검증인 pubkey는 다음과 같이 확인할 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiad tendermint show-validator
|
||||
```
|
||||
|
||||
위 키는 텐더민트 사이닝 키이며, 위임 트랜잭션에서 이용되는 오퍼레이터 키가 아니라는 점을 참고하세요.
|
||||
|
||||
::: danger 경고
|
||||
다수의 키에 동일한 passphrase를 이용하는 것을 추천하지 않습니다. 텐더민트 팀과 인터체인 재단은 자산 손실에 대한 책임을 지지 않습니다.
|
||||
:::
|
||||
|
||||
#### 멀티시그 퍼블릭 키 생성하기
|
||||
|
||||
새로운 멀티시그 퍼블릭키를 생성하고 확인하시려면 다음과 같은 명령을 입력하세요:
|
||||
|
||||
```bash
|
||||
gaiacli keys add --multisig=name1,name2,name3[...] --multisig-threshold=K new_key_name
|
||||
```
|
||||
|
||||
여기서 `K`는 트랜잭션이 승인되기 위해서 필요한 최소의 키 개수입니다.
|
||||
|
||||
`--multisig` 플래그는 로컬 데이터베이스에 `new_key_name`으로 저장될 멀티시그 퍼블릭 키를 생성할때 사용되는 다수의 퍼블릭 키들의 값을 뜻합니다. `--multisig` 값에 포함될 키들은 로컬 데이터베이스에 존재하는 상태여야 합니다. `--nosort` 플래그가 정의된지 않은 경우, 멀티시그 조합에 필요한 키들이 입력되는 순서는 무관합니다. 예를 들어 다음 두 명령어는 두개의 동일한 멀티시그 퍼블릭 키를 생성합니다:
|
||||
|
||||
```bash
|
||||
gaiacli keys add --multisig=foo,bar,baz --multisig-threshold=2 multisig_address
|
||||
gaiacli keys add --multisig=baz,foo,bar --multisig-threshold=2 multisig_address
|
||||
```
|
||||
|
||||
멀티시그 키의 주소는 다음과 같이 빠르게 생성하여 커맨드라인에 프린트할 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli keys show --multisig-threshold K name1 name2 name3 [...]
|
||||
```
|
||||
|
||||
멀티시그 트랜잭션를 생성, 사인, 전파하는 방법은 [멀티시그 트랜잭션](#멀티시그-트랜잭션) 항목을 참고하세요.
|
||||
|
||||
### 수수료와 가스
|
||||
|
||||
각 트랜잭션은 수수료(fee)를 지정하거나 가스 가격(gas price)을 지정할 수 있지만, 두 값을 함께 지정하는 것은 불가능합니다. 대다수의 유저는 지정된 비용만을 수수료로 사용하기 위해 수수료(fee)를 지정하는 방식으로 트랜잭션을 발생할 것으로 예상됩니다.
|
||||
|
||||
각 검증인은 최소 가스 가격(minimum gas price)를 (다수 토큰 사용 가능) 설정할 수 있으며 이 값을 기준으로 `CheckTx` 단계에서 특정 트랜잭션을 블록에 포함시킬지 확인합니다. `gasPrices >= minGasPrices`일때 검증인은 트랜잭션을 처리합니다. 참고로 트랜잭션 전파시 검증인이 요구하는 토큰 중 하나를 수수료 지불 토큰으로 사용하셔야 합니다.
|
||||
|
||||
__참고__: 위와 같은 메커니즘에서 일부 검증인은 멤풀에 있는 트랜잭션 중 높은 `gasPrice`의 트랜잭션을 우선적으로 처리할 수 있습니다. 그렇기 때문에 높은 수수료는 트랜잭션 처리 우선 순위를 높힐 수 있습니다.
|
||||
|
||||
예시)
|
||||
|
||||
```bash
|
||||
gaiacli tx send ... --fees=100photino
|
||||
```
|
||||
|
||||
또는
|
||||
|
||||
```bash
|
||||
gaiacli tx send ... --gas-prices=0.000001stake
|
||||
```
|
||||
|
||||
### 계정
|
||||
|
||||
#### 테스트 토큰 받기
|
||||
|
||||
토큰을 받기 가장 쉬운 곳은 [코스모스 테스트넷 faucet](https://faucetcosmos.network) 입니다. 만약 해당 faucet이 작동하지 않는 경우 [#cosmos-validators](https://riot.im/app/#/room/#cosmos-validators:matrix.org) 채팅 방에서 요청을 하실 수 있습니다. 해당 faucet은 스테이킹을 하려고 하시는 계정의 `cosmos` 주소를 입력하시면 됩니다.
|
||||
|
||||
#### 계정 잔고 조회하기
|
||||
|
||||
주소에 토큰을 받으신 후 잔고를 확인하시려면 다음 명령어를 입력하시면 됩니다:
|
||||
|
||||
```bash
|
||||
gaiacli query account <account_cosmos>
|
||||
```
|
||||
|
||||
::: warning 참고
|
||||
계정의 토큰 잔고가 `0`인 계정을 조회하실 경우 다음과 같은 에러 메시지가 표시될 수 있습니다: `No account with address <account_cosmos> was found in the state.` 노드가 체인과 완벽하게 연동이 안된 상태에서 조회를 할 경우 동일한 에러가 발생할 수 있습니다.
|
||||
:::
|
||||
|
||||
### 토큰 전송하기
|
||||
|
||||
한 계정에서 다른 계정으로 토큰/코인을 전송하기 위해서는 다음 명령어를 이용하시면 됩니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx send <destination_cosmos> 10faucetToken \
|
||||
--chain-id=<chain_id> \
|
||||
--from=<key_name> \
|
||||
```
|
||||
|
||||
::: warning 참고
|
||||
`--amount` 플래그는 다음과 같은 포맷을 사용합니다 `--amount=<수량|코인 이름>`.
|
||||
:::
|
||||
|
||||
::: tip 참고
|
||||
해당 트랜잭션이 사용하는 가스 값의 최대치를 설정하기 원하시면 `--gas` 플래그를 이용하세요. 만약 `--gas=auto`를 이용하시는 경우, 트랜잭션이 실행되기 전에 가스 서플라이가 자동으로 예측됩니다. 예측된 가스 값과 실제 트랜잭션이 일어나는 사이에 블록체인 상태가 변경될 수 있으며, 기존 예측 수량에서 값이 변경이 될 수 있다는 점을 유의하세요. 변경 값은 `--gas-adjustment` 플래그를 이용해 설정하실 수 있으며 기본 값은 1.0입니다.
|
||||
:::
|
||||
|
||||
이제 토큰을 전송한 계정과 토큰을 받은 계정의 잔고를 확인합니다:
|
||||
|
||||
```bash
|
||||
gaiacli query account <account_cosmos>
|
||||
gaiacli query account <destination_cosmos>
|
||||
```
|
||||
|
||||
특정 블록에서의 잔고를 확인하고 싶으시다면 `--block` 플래그를 사용하실 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli query account <account_cosmos> --block=<block_height>
|
||||
```
|
||||
|
||||
트랜잭션을 실제 전파하지 않고 시뮬레이션을 하시려면 명령어 뒤에 `--dry-run` 플래그를 추가하세요:
|
||||
|
||||
```bash
|
||||
gaiacli tx send <destination_cosmosaccaddr> 10faucetToken \
|
||||
--chain-id=<chain_id> \
|
||||
--from=<key_name> \
|
||||
--dry-run
|
||||
```
|
||||
|
||||
또한 트랜잭션을 빌드한 후 해당 트랜잭션을 JSON 포맷으로 STDOUT에 프린트 하시기를 원하면 `--generate-only`를 명령어에 추가하시면 됩니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx send <destination_cosmosaccaddr> 10faucetToken \
|
||||
--chain-id=<chain_id> \
|
||||
--from=<key_name> \
|
||||
--generate-only > unsignedSendTx.json
|
||||
```
|
||||
|
||||
::: tip 참고
|
||||
시뮬레이션은 퍼블릭 키를 필요로 하고 generate only는 키베이스를 사용하지 않기 때문에 시뮬레이션은 tx generate only 기능과 함께 사용될 수 없습니다.
|
||||
:::
|
||||
|
||||
이제 `--generate-only`를 통해 프린트된 트랜잭션 파일을 서명하시려면 다음 명령어를 통해 키를 입력하시면 됩니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx sign \
|
||||
--chain-id=<chain_id> \
|
||||
--from=<key_name>
|
||||
unsignedSendTx.json > signedSendTx.json
|
||||
```
|
||||
|
||||
트랜잭션의 서명을 검증하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli tx sign --validate-signatures signedSendTx.json
|
||||
```
|
||||
|
||||
서명된 트랜잭션을 노드로 전파하기 위해서는 JSON 파일을 다음 명령어를 통해 전달하면 됩니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx broadcast --node=<node> signedSendTx.json
|
||||
```
|
||||
|
||||
### 트랜잭션 조회하기
|
||||
|
||||
#### 태그 매칭하기
|
||||
|
||||
트랜잭션 검색 명령을 이용하여 모든 트랜잭션에 추가되는 특정 `tags` 세트를 검색할 수 있습니다.
|
||||
|
||||
각 태그의 키-값 페어는 `<tag>:<value>` 형태로 이루어집니다. 더 상세한 검색을 원하실 경우 `&` 를 사용하여 태그를 추가할 수 있습니다.
|
||||
|
||||
`tag`를 이용한 트랜잭션 조회는 다음과 같이 합니다:
|
||||
|
||||
```bash
|
||||
gaiacli query txs --tags='<tag>:<value>'
|
||||
```
|
||||
|
||||
다수의 `tags`를 이용하실 경우:
|
||||
|
||||
```bash
|
||||
gaiacli query txs --tags='<tag1>:<value1>&<tag2>:<value2>'
|
||||
```
|
||||
|
||||
페이지네이션은 `page`와 `limit` 값으로 지원됩니다.
|
||||
|
||||
```bash
|
||||
gaiacli query txs --tags='<tag>:<value>' --page=1 --limit=20
|
||||
```
|
||||
|
||||
::: tip 참고
|
||||
|
||||
액션 태그는 관련 메시지의 `Type()` 명령이 응답하는 메시지 타입과 언제나 동일합니다.
|
||||
|
||||
각 SDK 모듈에 대한 `tags`는 여기에서 확인할 수 있습니다:
|
||||
|
||||
- [Common tags](https://github.com/cosmos/cosmos-sdk/blob/d1e76221d8e28824bb4791cb4ad8662d2ae9051e/types/tags.go#L57-L63)
|
||||
- [Staking tags](https://github.com/cosmos/cosmos-sdk/blob/d1e76221d8e28824bb4791cb4ad8662d2ae9051e/x/staking/tags/tags.go#L8-L24)
|
||||
- [Governance tags](https://github.com/cosmos/cosmos-sdk/blob/d1e76221d8e28824bb4791cb4ad8662d2ae9051e/x/gov/tags/tags.go#L8-L22)
|
||||
- [Slashing tags](https://github.com/cosmos/cosmos-sdk/blob/d1e76221d8e28824bb4791cb4ad8662d2ae9051e/x/slashing/handler.go#L52)
|
||||
- [Distribution tags](https://github.com/cosmos/cosmos-sdk/blob/develop/x/distribution/tags/tags.go#L8-L17)
|
||||
- [Bank tags](https://github.com/cosmos/cosmos-sdk/blob/d1e76221d8e28824bb4791cb4ad8662d2ae9051e/x/bank/keeper.go#L193-L206)
|
||||
:::
|
||||
|
||||
#### 트랜잭션 해시로 검색하기
|
||||
|
||||
다음과 같은 명령어를 이용하여 한 트랜잭션의 해시값을 이용해 조회를 할 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli query tx [hash]
|
||||
```
|
||||
|
||||
### 슬래싱
|
||||
|
||||
#### 언제일(Unjailing)
|
||||
|
||||
제일링 된 검증인을 언제일 하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli tx slashing unjail --from <validator-operator-addr>
|
||||
```
|
||||
|
||||
#### 서명 정보
|
||||
|
||||
특정 검증인의 서명 정보를 확인하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query slashing signing-info <validator-pubkey>
|
||||
```
|
||||
|
||||
#### 슬래싱 파라미터 조회
|
||||
|
||||
현재 슬래싱 파라미터를 확인하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query slashing params
|
||||
```
|
||||
|
||||
### 스테이킹
|
||||
|
||||
#### 검증인 세팅하기
|
||||
검증인 후보가 되기 위한 가이드는 [검증인 세팅](../validators/validator-setup.md) 문서를 참고하세요.
|
||||
|
||||
#### 검증인에게 위임하기
|
||||
|
||||
메인넷에서는 `atom`을 특정 검증인에게 위임할 수 있습니다. 스테이킹에 참여하는 [위임인](/resources/delegators-faq)은 검증인 보상의 일부를 받을 수 있습니다. 관련 정보는 [코스모스 토큰 모델](https://github.com/cosmos/cosmos/raw/master/Cosmos_Token_Model.pdf)에서 확인하세요.
|
||||
|
||||
##### 검증인 조회하기
|
||||
|
||||
특정 체인의 모든 검증인 목록을 확인하기 위해서는 다음 명령을 실행하세요:
|
||||
|
||||
```bash
|
||||
gaiacli query staking validators
|
||||
```
|
||||
|
||||
특정 검증인에 대한 정보를 원하실 경우 다음 명령을 실행하세요:
|
||||
|
||||
```bash
|
||||
gaiacli query staking validator <account_cosmosval>
|
||||
```
|
||||
|
||||
#### 토큰 본딩하기
|
||||
|
||||
테스트넷의 경우 `atom`이 아닌 `steak`를 위임합니다. 특정 테스트넷 검증인에게 토큰을 본딩하기 위해서는:
|
||||
|
||||
|
||||
```bash
|
||||
gaiacli tx staking delegate \
|
||||
--amount=10steak \
|
||||
--validator=<validator> \
|
||||
--from=<key_name> \
|
||||
--chain-id=<chain_id>
|
||||
```
|
||||
|
||||
`<validator>` 는 검증 대상 검증인의 운영자 주소입니다. 로컬 테스트넷을 운영하시는 경우, 다음 명령어로 관련 주소를 확인하실 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli keys show [name] --bech val
|
||||
```
|
||||
|
||||
여기에서`[name]`은 `gaiad`를 처음 설정하셨을때 정의한 키의 명칭입니다.
|
||||
|
||||
토큰이 본딩되고 있는 기간 동안에는 다른 본딩된 토큰과 함께 하나의 '풀'을 이룹니다. 검증인들과 위임인들은 해당 풀의 소유량에 비례하는 보상을 받게 됩니다.
|
||||
|
||||
|
||||
::: tip 참고
|
||||
보유하고 있는 `steak` 이상을 사용하지 마세요. `steak`가 더 필요한 경우 [Faucet](https://faucetcosmos.network/)에서 추가로 받으실 수 있습니다!
|
||||
:::
|
||||
|
||||
##### 위임 조회
|
||||
|
||||
위임 요청을 검증인에게 전송한 경우, 관련 정보를 다음 명령을 통해 조회하실 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli query staking delegation <delegator_addr> <validator_addr>
|
||||
|
||||
```
|
||||
|
||||
만약 특정 검증인에 대한 모든 위임 상태를 확인하고 싶으실 경우 다음 명령을 이용하세요:
|
||||
|
||||
```bash
|
||||
gaiacli query staking delegation <delegator_addr>
|
||||
```
|
||||
|
||||
과거 위임 기록에 대해서는 `--height` 플래그를 추가 하셔서 해당 블록 높이에 대한 기록을 조회하실 수 있습니다.
|
||||
|
||||
#### 토큰 언본딩 하기
|
||||
|
||||
만약 특정 검증인이 악의적인 행동을 했거나 또는 본인이 개인적인 이유로 일부 토큰을 언본딩을 워하는 경우 다음 명령어를 통해 토큰을 언본딩 할 수 있습니다. 언본딩은 정확한 수량인 `shares-amount`(예시, `12.1`) 또는 언본딩을 원하는 물량의 비율인 `shares-fraction`(예시, `0.25`) 값으로 표현될 수 있습니다.
|
||||
|
||||
|
||||
```bash
|
||||
gaiacli tx staking unbond \
|
||||
--validator=<account_cosmosval> \
|
||||
--shares-fraction=0.5 \
|
||||
--from=<key_name> \
|
||||
--chain-id=<chain_id>
|
||||
```
|
||||
|
||||
언본딩은 언본딩 기간이 끝나는 대로 완료됩니다.
|
||||
|
||||
##### 언본딩 조회하기
|
||||
|
||||
언본딩 절차를 시작하신 후 관련 정보를 조회하는 방법은 다음과 같습니다:
|
||||
|
||||
```bash
|
||||
gaiacli query staking unbonding-delegation <delegator_addr> <validator_addr>
|
||||
```
|
||||
|
||||
또는 모든 언본딩 정보를 확인하고 싶으신 경우:
|
||||
|
||||
```bash
|
||||
gaiacli query staking unbonding-delegations <account_cosmos>
|
||||
```
|
||||
|
||||
추가적으로 특정 검증인으로 부터 언본딩하는 정보를 확인하고 싶으신 경우:
|
||||
|
||||
```bash
|
||||
gaiacli query staking unbonding-delegations-from <account_cosmosval>
|
||||
```
|
||||
|
||||
과거 언본딩 정보는 `--height` 플래그를 통해서 특정 블록 높이에 대한 언본딩 정보를 조회할 수 있습니다.
|
||||
|
||||
#### 재위임(Redelegate) 하기
|
||||
|
||||
재위임이란 본딩 되어있는 토큰을 한 검증인으로 부터 다른 검증인으로 옮기는 것입니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx staking redelegate \
|
||||
--addr-validator-source=<account_cosmosval> \
|
||||
--addr-validator-dest=<account_cosmosval> \
|
||||
--shares-fraction=50 \
|
||||
--from=<key_name> \
|
||||
--chain-id=<chain_id>
|
||||
```
|
||||
|
||||
위 예시와 같이 재위임될 토큰의 수량은 특정 수량(`shares-amount`) 또는 일정 비율(`shares-fraction`)로 표현될 수 있습니다.
|
||||
|
||||
언본딩 기간이 지나면 재위임은 자동으로 완료됩니다.
|
||||
|
||||
##### 재위임 조회하기
|
||||
|
||||
재위임을 시작하신 후, 다음 명령을 통해서 관련 정보를 조회하실 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli query staking redelegation <delegator_addr> <src_val_addr> <dst_val_addr>
|
||||
```
|
||||
|
||||
모든 검증인에 대한 재위임을 확인하고 싶으신 경우:
|
||||
|
||||
```bash
|
||||
gaiacli query staking redelegations <account_cosmos>
|
||||
```
|
||||
|
||||
특정 검증인에 대한 재위임을 확인하고 싶으신 경우:
|
||||
|
||||
```bash
|
||||
gaiacli query staking redelegations-from <account_cosmosval>
|
||||
```
|
||||
|
||||
과거 재위임에 대한 정보는 다른 트랜잭션과 동일하게 `--height` 플래그를 이용하여 특정 블록 높이에 대한 재위임 정보를 확인하실 수 있습니다.
|
||||
|
||||
#### 파라미터 조회
|
||||
|
||||
파라미터는 스테이킹의 하이-레벨 설정을 정의합니다. 현재 값은 다음 명령어를 통해서 조회할 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli query staking params
|
||||
```
|
||||
|
||||
위 명령어는 다음과 같은 정보를 표기합니다:
|
||||
|
||||
- 언본딩 기간
|
||||
- 최대 검증인 수
|
||||
- 스테이킹 코인 표기
|
||||
|
||||
해당 값은 거버넌스 절차의 `ParameterChange`(파라미터 변경) 프로포절을 통해서 변경됩니다.
|
||||
|
||||
#### 스테이킹 풀 조회하기
|
||||
|
||||
스티이킹 풀은 현재 상태(state)에 대한 다이내믹 파라미터(dynamic parameter)를 정의합니다. 관련 정보는 다음 명령을 통해 조회할 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli query staking pool
|
||||
```
|
||||
|
||||
`pool` 명령은 다음과 같은 정보에 대한 현재 값을 제공합니다:
|
||||
- 본딩된 토큰 / 본딩 되어있지 않은 토큰
|
||||
- 총 토큰 수량
|
||||
- 연 인플레이션 비율과 가장 최근에 인플레이션이 변경된 블록 높이
|
||||
- 가장 최근 기록된 bonded shares
|
||||
|
||||
##### 검증인 위임 조회하기
|
||||
|
||||
특정 검증인에 대한 모든 위임은 다음 명령으로 조회가 가능합니다:
|
||||
|
||||
```bash
|
||||
gaiacli query delegations-to <account_cosmosval>
|
||||
```
|
||||
|
||||
### 거버넌스
|
||||
|
||||
거버넌스는 코스모스 허브의 유저가 소프트웨어 업그레이드, 메인넷 파라미터 또는 문서 형태의 프로포절 등에 대한 합의를 하는 절차입니다. 유저는 프로포절에 대한 투표를 함으로 이 절차에 참여할 수 있으며, 투표권은 메인넷 아톰 홀더들에게만 주어집니다.
|
||||
|
||||
다음은 투표 절차에 대한 정보입니다:
|
||||
|
||||
- 투표권은 본딩된 `Atom`을 소유한 유저에게만 주어지며, `본딩된 아톰 1개 = 1표` 기준으로 집계됩니다
|
||||
- 투표권을 행사하지 않은 위임인들은 본인이 위임한 검증인들의 투표를 따르게 됩니다
|
||||
- **검증인은 모든 프로포절에 투표를 해야합니다.** 프로포절에 투표를 하지 않는 검증인들은 부분적 슬래싱 페널티를 받게 됩니다
|
||||
- 표는 각 프로포절의 투표 마감 시점(메인넷 기준 2주)에서 집계됩니다. 각 계정은 투표기간 중 표를 변경할 수 있으며(트랜잭션 수수료는 부과됩니다), 가장 마지막 표가 유효한 표로 집계됩니다
|
||||
- 투표자들은 `Yes`, `No`, `NoWithVeto`와 `Abstain` 중에서 하나를 선택하여 투표할 수 있습니다
|
||||
- 프로포절은 `(YesVote/(YesVotes+NoVotes+NoWithVetoVotes))>1/2` 또는 `(NoWithVetoVotes/(YesVotes+NoVotes+NoWithVetoVotes))<1/3`일 경우에만 통과하며, 이 외의 경우 부결됩니다.
|
||||
|
||||
거버넌스 절차에 대한 더 자세한 정보는 [거버넌스 모듈 스펙](./../spec/governance)을 확인하세요.
|
||||
|
||||
#### 거버넌스 프로포절 생성하기
|
||||
|
||||
새로운 거버넌스 프로포절을 생성하기 위해서는 프로포절 정보와 일정의 보증금을 예치해야 합니다:
|
||||
|
||||
- `title`: 프로포절 제목
|
||||
- `description`: 프로포절 설명
|
||||
- `type`: 프로포절 유형. _Text_ 형태여야 합니다 (_SoftwareUpgrade_ 와 _ParameterChange_ 는 아직 지원되지 않습니다).
|
||||
|
||||
```bash
|
||||
gaiacli tx gov submit-proposal \
|
||||
--title=<title> \
|
||||
--description=<description> \
|
||||
--type=<Text/ParameterChange/SoftwareUpgrade> \
|
||||
--deposit=<40steak> \
|
||||
--from=<name> \
|
||||
--chain-id=<chain_id>
|
||||
```
|
||||
|
||||
##### 프로포절 조회
|
||||
|
||||
프로포절이 생성된 후 관련 정보를 조회하는 방법은 다음과 같습니다:
|
||||
|
||||
```bash
|
||||
gaiacli query gov proposal <proposal_id>
|
||||
```
|
||||
|
||||
모든 프로포절에 대한 조회를 하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query gov proposals
|
||||
```
|
||||
|
||||
프로포절을 `voter` 또는 `depositor`로 필터링 해서 조회할 수도 있습니다.
|
||||
|
||||
특정 거버넌스 프로포절의 제안자를 확인하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query gov proposer <proposal_id>
|
||||
```
|
||||
|
||||
#### 보증금 추가하기
|
||||
|
||||
프로포절이 네트워크에 전파되기 위해서는 해당 프로포절의 보증금이 `minDeposit` 값 이상이어야 합니다 (현재 기본 값은 `10 steak`입니다). 만약 사전에 생성한 프로포절이 해당 기준을 충족하지 못하였다면 추후에 보증금을 추가 예치하여 활성화할 수 있습니다. 프로포절의 보증금이 최소 값을 도달하면 해당 프로포절의 투표는 활성화 됩니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx gov deposit <proposal_id> <200steak> \
|
||||
--from=<name> \
|
||||
--chain-id=<chain_id>
|
||||
```
|
||||
|
||||
> _참고_: 기본 보증금 기준을 충족하지 못한 프로포절은 `MaxDepositPeriod`이 지나면 자동으로 삭제됩니다.
|
||||
|
||||
##### 보증금 조회하기
|
||||
|
||||
새로운 프로포절이 생성된 후, 해당 프로포절에 대한 보증금은 다음과 같이 조회할 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli query gov deposits <proposal_id>
|
||||
```
|
||||
|
||||
특정 주소에 대한 보증금은 다음과 같이 확인하실 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli query gov deposit <proposal_id> <depositor_address>
|
||||
```
|
||||
|
||||
#### 프로포절 투표하기
|
||||
|
||||
프로포절의 보증금이 `MinDeposit` 값에 도달하면 투표 기간이 시작됩니다. 본딩된 `Atom`을 보유한 홀더들은 각자 투표를 할 수 있습니다:
|
||||
|
||||
|
||||
```bash
|
||||
gaiacli tx gov vote <proposal_id> <Yes/No/NoWithVeto/Abstain> \
|
||||
--from=<name> \
|
||||
--chain-id=<chain_id>
|
||||
```
|
||||
|
||||
##### 표 조회하기
|
||||
|
||||
특정 표와 관련한 정보를 조회하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query gov vote <proposal_id> <voter_address>
|
||||
```
|
||||
과거 프로포절에 대한 표 정보를 확인하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query gov votes <proposal_id>
|
||||
```
|
||||
|
||||
#### 프로포절 결과 조회하기
|
||||
|
||||
특정 프로포절에 대한 결과를 확인하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query gov tally <proposal_id>
|
||||
```
|
||||
|
||||
#### 거버넌스 파라미터 조회하기
|
||||
|
||||
현재 거버넌스 파라미터를 조회하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query gov param voting
|
||||
gaiacli query gov param tallying
|
||||
gaiacli query gov param deposit
|
||||
```
|
||||
|
||||
### 스테이킹 리워드 분배
|
||||
|
||||
#### 리워드 분배 파라미터 조회
|
||||
|
||||
현재 리워드 분배 파라미터 값을 조회하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query distr params
|
||||
```
|
||||
|
||||
#### 수령되지 않은 리워드를 받기
|
||||
|
||||
수령하지 않은 리워드를 수령하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query distr outstanding-rewards
|
||||
```
|
||||
|
||||
#### 검증인 커미션 조회
|
||||
|
||||
특정 검증인의 커미션을 조회하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query distr commission <validator_address>
|
||||
```
|
||||
|
||||
#### 검증인 슬래싱 조회
|
||||
|
||||
특정 검증인의 슬래싱 기록을 조회하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query distr slashes <validator_address> <start_height> <end_height>
|
||||
```
|
||||
|
||||
#### 특정 검증인에서 수령되지 않은 리워드 조회
|
||||
|
||||
위임자의 특정 검증인에서 발생된 미수령 리워드를 조회하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query distr rewards <delegator_address> <validator_address>
|
||||
```
|
||||
|
||||
#### 위임자의 수령 대기중인 모든 리워드 조회
|
||||
|
||||
위임자의 모든 수령 대기 리워드를 조회하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli query distr rewards <delegator_address>
|
||||
```
|
||||
|
||||
### 멀티시그 트랜잭션
|
||||
|
||||
멀티시그 트랜잭션을 서명하기 위해서는 다수의 프라이빗 기가 필요합니다. 그렇기 때문에 멀티시그 계정에서 트랜잭션을 생성하고 서명하기 위해서는 여러 인원간의 협동이 필요합니다. 멀티시그 키 보유자 누구나 트랜잭션을 생성할 수 있으며, 멀티시그 퍼블릭키를 생성하고 트랜잭션을 전파하기 위해서는 키 소유자 중 최소 한명이 다른 키 소유자들의 모든 퍼블릭 키를 로컬 데이터베이스에 보유해야합니다.
|
||||
|
||||
예를 들어 멀티시그 키가 `p1`, `p2`, `p3` 키로 이루어진다면, `p1` 키 보유자는 `p2`와 `p3`의 키가 있어야 멀티시그 계정의 퍼블릭 키를 생성할 수 있습니다.
|
||||
|
||||
```
|
||||
gaiacli keys add \
|
||||
--pubkey=cosmospub1addwnpepqtd28uwa0yxtwal5223qqr5aqf5y57tc7kk7z8qd4zplrdlk5ez5kdnlrj4 \
|
||||
p2
|
||||
gaiacli keys add \
|
||||
--pubkey=cosmospub1addwnpepqgj04jpm9wrdml5qnss9kjxkmxzywuklnkj0g3a3f8l5wx9z4ennz84ym5t \
|
||||
p3
|
||||
gaiacli keys add \
|
||||
--multisig-threshold=2
|
||||
--multisig=p1,p2,p3
|
||||
p1p2p3
|
||||
```
|
||||
|
||||
이제 새로운 멀티시그 키 `p1p2p3`이 보관되었으며 이 주소를 기반으로 멀티 트랜잭션이 서명됩니다:
|
||||
|
||||
```bash
|
||||
gaiacli keys show --address p1p2p3
|
||||
```
|
||||
|
||||
위 주소를 기반으로 멀티시그 트랜잭션을 생성하는 과정의 첫 단계는 다음과 같습니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx send cosmos1570v2fq3twt0f0x02vhxpuzc9jc4yl30q2qned 10stake \
|
||||
--from=<multisig_address> \
|
||||
--generate-only > unsignedTx.json
|
||||
```
|
||||
|
||||
`unsignedTx.json` 파일은 서명되지 않은 트랜잭션을 JSON 형태로 보관합니다. 이제 `p1`은 본인의 프라이빗 키를 사용해 트랜잭션을 서명할 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx sign \
|
||||
--multisig=<multisig_address> \
|
||||
--name=p1 \
|
||||
--output-document=p1signature.json \
|
||||
unsignedTx.json
|
||||
```
|
||||
|
||||
서명이 생성된 후, `p1`은 `unsignedTx.json`과 `p1signature.json`을 `p2` 또는 `p3`에게 전다합니다. `p2`와 `p3`은 이를 기반으로 서명을 진행합니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx sign \
|
||||
--multisig=<multisig_address> \
|
||||
--name=p2 \
|
||||
--output-document=p2signature.json \
|
||||
unsignedTx.json
|
||||
```
|
||||
|
||||
`p1p2p3`은 3명 중 2명의 서명을 필요로 하는 멀티시그 키입니다. 그렇기 때문에 `p1`이 서명한 트랜잭션에 하나의 프라이빗 키만 더해지면 트랜잭션이 유효합니다. 이제 다른 키 보유자들은 필요한 서명 파일을 결합하여 멀티시그 트랜잭션을 생성할 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx multisign \
|
||||
unsignedTx.json \
|
||||
p1p2p3 \
|
||||
p1signature.json p2signature.json > signedTx.json
|
||||
```
|
||||
|
||||
서명된 트랜잭션은 다음과 같은 명령을 실행하여 노드에 전파합니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx broadcast signedTx.json
|
||||
```
|
||||
|
||||
## Shell 완료 스크립트
|
||||
|
||||
흔히 사용되는 `Bash`와 `Zsh` 같은 UNIX의 완료 스크립트(completion script)는 `completion` 명령어를 사용해 생성될 수 있습니다. 이 명령은 `gaiad`와 `gaiacli`에서 사용 가능합니다.
|
||||
|
||||
`Bash` 완료 스크립트를 생성하기 위해서는 다음 명령어를 실행하세요:
|
||||
|
||||
```bash
|
||||
gaiad completion > gaiad_completion
|
||||
gaiacli completion > gaiacli_completion
|
||||
```
|
||||
|
||||
`Zsh` 완료 스크립트를 생성하기 위해서는 다음 명령어를 실행하세요:
|
||||
|
||||
```bash
|
||||
gaiad completion --zsh > gaiad_completion
|
||||
gaiacli completion --zsh > gaiacli_completion
|
||||
```
|
||||
|
||||
::: tip 참고
|
||||
대다수의 UNIX 시스템에서는 이런 스크립트를 `.bashrc` 또는 `.bash_profile`을 사용해 로딩할 수 있습니다:
|
||||
|
||||
```bash
|
||||
echo '. gaiad_completion' >> ~/.bashrc
|
||||
echo '. gaiacli_completion' >> ~/.bashrc
|
||||
```
|
||||
|
||||
셸 자동 완성을 사용하시려면 사용하시는 OS의 매뉴얼을 참고하십시오.
|
||||
:::
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
# Gaia 제네시스 스테이트
|
||||
|
||||
Gaia의 제네시스 스테이트인 `GenesisState`는 계정 정보, 모듈 스테이트 그리고 제네시스 트랜잭션 같은 메타데이터 등으로 구성됩니다. 각 모듈은 각자의 `GenesisState`를 지정할 수 있습니다. 또한, 각 모듈은 각자의 제네시스 스테이트 검증, 임포트, 엑스포트 기능 등을 지정할 수 있습니다.
|
||||
|
||||
Gaia 제네시스 스테이트는 다음과 같이 정의됩니다:
|
||||
|
||||
```go
|
||||
type GenesisState struct {
|
||||
Accounts []GenesisAccount `json:"accounts"`
|
||||
AuthData auth.GenesisState `json:"auth"`
|
||||
BankData bank.GenesisState `json:"bank"`
|
||||
StakingData staking.GenesisState `json:"staking"`
|
||||
MintData mint.GenesisState `json:"mint"`
|
||||
DistrData distr.GenesisState `json:"distr"`
|
||||
GovData gov.GenesisState `json:"gov"`
|
||||
SlashingData slashing.GenesisState `json:"slashing"`
|
||||
GenTxs []json.RawMessage `json:"gentxs"`
|
||||
}
|
||||
```
|
||||
|
||||
ABCI `initChainer`에서는 Gaia의 `initFromGenesisState`를 기반으로 각 모듈의 `InitGenesis`를 호출해 각 모듈들의 `GenesisState`를 파라미터 값으로 불러옵니다.
|
||||
|
||||
## 계정
|
||||
|
||||
`GenesisState`에서 제네시스 계정은 다음과 같이 정의됩니다:
|
||||
|
||||
```go
|
||||
type GenesisAccount struct {
|
||||
Address sdk.AccAddress `json:"address"`
|
||||
Coins sdk.Coins `json:"coins"`
|
||||
Sequence uint64 `json:"sequence_number"`
|
||||
AccountNumber uint64 `json:"account_number"`
|
||||
|
||||
// vesting account fields
|
||||
OriginalVesting sdk.Coins `json:"original_vesting"` // total vesting coins upon initialization
|
||||
DelegatedFree sdk.Coins `json:"delegated_free"` // delegated vested coins at time of delegation
|
||||
DelegatedVesting sdk.Coins `json:"delegated_vesting"` // delegated vesting coins at time of delegation
|
||||
StartTime int64 `json:"start_time"` // vesting start time (UNIX Epoch time)
|
||||
EndTime int64 `json:"end_time"` // vesting end time (UNIX Epoch time)
|
||||
}
|
||||
```
|
||||
|
||||
각 계정은 시퀀스 수(sequence number (nonce))와 주소 외에도 유효한 고유 계정 번호를 보유해야 합니다.
|
||||
|
||||
만약 계정이 베스팅 계정인 경우, 필수 베스팅 정보가 제공되어야 합니다. 베스팅 계정은 최소 `OriginalVestin` 값과 `EndTime` 값이 정의되어야 합니다. 먄약 `StartTime`이 함께 정의된 경우, 계정은 "연속되는(continuous)" 베스팅 계정으로 처리되며, 지정된 스케줄 안에서 꾸준히 토큰을 언락합니다. 여기에서 `StartTime`의 값은 `EndTime`의 값 보다 작아야 하지만, `StartTime`의 값은 미래 값으로 지정할 수는 있습니다 (제네시스 시간과 동일하지 않아도 괜찮습니다). 새로운 스테이트(엑스포트 되지 않은 스테이트)에서 시작하는 체인의 경우, `OriginalVestin`의 값은 `Coins`의 값과 동일하거나 적어야 합니다.
|
||||
|
||||
<!-- TODO: Remaining modules and components in GenesisState -->
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
## Gaia 설치하기
|
||||
|
||||
이 가이드는 `gaiad`와 `gaiacli`를 엔트리포인트를 시스템에 설치하는 방법을 설명합니다. `gaiad`와 `gaiacli`가 설치된 서버를 통해 [풀노드](./join-testnet.md#run-a-full-node) 또는 [밸리데이터로](./validators/validator-setup.md)써 최신 테스트넷에 참가하실 수 있습니다.
|
||||
|
||||
### Go 설치하기
|
||||
|
||||
공식 [Go 문서](https://golang.org/doc/install)를 따라서 `go`를 설치하십시오. `$GOPATH`, `$GOBIN`, 그리고 `$PATH`의 환경을 꼭 세팅하세요. 예시:
|
||||
|
||||
```bash
|
||||
mkdir -p $HOME/go/b4n
|
||||
echo "export GOPATH=$HOME/go" >> ~/.bash_profile
|
||||
echo "export GOBIN=$GOPATH/bin" >> ~/.bash_profile
|
||||
echo "export PATH=$PATH:$GOBIN" >> ~/.bash_profile
|
||||
```
|
||||
|
||||
::: tip
|
||||
코스모스 SDK를 운영하기 위해서는 **Go 1.11.ㅎ+** 이상 버전이 필요합니다.
|
||||
:::
|
||||
|
||||
### 바이너리 설치하기
|
||||
|
||||
다음은 최신 Gaia 버전을 설치하는 것입니다. 예시에서는 최신 스테이블 릴리즈가 포함되어있는 `master` 브랜치를 이용해 진행됩니다. 필요에 따라 `git checkout`을 통해 [최신 릴리즈](https://github.com/cosmos/cosmos-sdk/releases)가 설치되어있는지 확인하세요.
|
||||
|
||||
```bash
|
||||
mkdir -p $GOPATH/src/github.com/cosmos
|
||||
cd $GOPATH/src/github.com/cosmos
|
||||
git clone https://github.com/cosmos/cosmos-sdk
|
||||
cd cosmos-sdk && git checkout master
|
||||
make tools install
|
||||
```
|
||||
|
||||
> *참고*: 여기에서 문제가 발생한다면, Go의 최신 스테이블 버전이 설치되어있는지 확인하십시오.
|
||||
|
||||
위 절차를 따라하시면 `gaiad`와 `gaiacli` 바이너리가 설치될 것입니다. 설치가 잘 되어있는지 확인하십시오:
|
||||
|
||||
|
||||
```bash
|
||||
$ gaiad version
|
||||
$ gaiacli version
|
||||
```
|
||||
|
||||
### 다음 절차
|
||||
|
||||
축하합니다! 이제 [퍼블릭 테스트넷](./join-testnet.md)에 참가하시거나 or [프라이빗 테스트넷](./deploy-testnet.md)을 운영하실 수 있습니다.
|
||||
|
|
@ -0,0 +1,157 @@
|
|||
# 최신 퍼블릭 테스트넷에 참가하기
|
||||
|
||||
::: tip 최신 테스트넷
|
||||
최신 테스트넷에 대한 정보는 다음의 [테스트넷 리포](https://github.com/cosmos/testnets)를 참고하세요. 어떤 코스모스 SDK 버전과 제네시스 파일에 대한 정보가 포합되어있습니다.
|
||||
:::
|
||||
|
||||
::: warning
|
||||
**여기에서 더 진행하시기 전에 [gaia](./installation.md)가 꼭 설치되어있어야 합니다.**
|
||||
:::
|
||||
|
||||
## 새로운 노드 세팅하기
|
||||
|
||||
> 참고: 과거 테스트넷에서 풀 노드를 운영하셨다면 이 항목은 건너뛰시고 [과거 테스트넷에서 업그레이드 하기](#upgrading-from-previous-testnet)를 참고하세요.
|
||||
|
||||
다음 절차는 새로운 풀노드를 처음부터 세팅하는 절차입니다.
|
||||
|
||||
우선 노드를 실행하고 필요한 config 파일을 생성합니다:
|
||||
|
||||
```bash
|
||||
gaiad init --moniker <your_custom_moniker>
|
||||
```
|
||||
|
||||
::: warning 참고
|
||||
`--moniker`는 ASCII 캐릭터만을 지원합니다. Unicode 캐릭터를 이용하는 경우 노드 접근이 불가능할 수 있으니 참고하세요.
|
||||
:::
|
||||
|
||||
`moniker`는 `~/.gaiad/config/config.toml` 파일을 통해 추후에 변경이 가능합니다:
|
||||
|
||||
```toml
|
||||
# A custom human readable name for this node
|
||||
moniker = "<your_custom_moniker>"
|
||||
```
|
||||
|
||||
최소 수수료보다 낮은 트랜잭션을 거절하는 스팸 방지 메커니즘을 활성화 하시려면 `~/.gaiad/config/gaiad.toml` 파일을 변경하시면 됩니다:
|
||||
|
||||
```
|
||||
# This is a TOML config file.
|
||||
# For more information, see https://github.com/toml-lang/toml
|
||||
|
||||
##### main base config options #####
|
||||
|
||||
# Validators reject any tx from the mempool with less than the minimum fee per gas.
|
||||
minimum_fees = ""
|
||||
```
|
||||
|
||||
|
||||
당신의 풀노드가 활성화 되었습니다! [제네시스와 시드](#genesis-seeds)로 넘어가주세요.
|
||||
|
||||
## 과거 테스트넷에서 업그레이드 하기
|
||||
|
||||
다음은 과거 테스트넷에서 운영을 했었던 풀노드가 최신 테스트넷으로 업그레이드를 하기 위한 절차입니다.
|
||||
|
||||
### 데이터 리셋
|
||||
|
||||
우선, 과거 파일을 삭제하고 데이터를 리셋합니다.
|
||||
|
||||
```bash
|
||||
rm $HOME/.gaiad/config/addrbook.json $HOME/.gaiad/config/genesis.json
|
||||
gaiad unsafe-reset-all
|
||||
```
|
||||
|
||||
이제 `priv_validator.json`과 `config.toml`을 제외하고 노드가 초기화 되었습니다. 만약 해당 노드에 연결된적이 있는 센트리노드나 풀노드가 같이 업그레이드 되지 않았다면 연결이 실패할 수 있습니다.
|
||||
|
||||
::: danger 경고
|
||||
각 노드가 **고유한** `priv_validator.json`을 보유하고 있는 것을 확인하세요. 오래된 노드의 `priv_validator.json`을 다수의 새로운 노드로 복사하지 마세요. 동일한 `priv_validator.json`을 보유한 두개 이상의 노드가 동시에 운영될 경우, **더블 사이닝**이 일어날 수 있습니다.
|
||||
:::
|
||||
|
||||
### 소프트웨어 업그레이드
|
||||
|
||||
이제 소프트웨어를 업그레이드할 시간입니다:
|
||||
|
||||
```bash
|
||||
cd $GOPATH/src/github.com/cosmos/cosmos-sdk
|
||||
git fetch --all && git checkout master
|
||||
make update_tools install
|
||||
```
|
||||
|
||||
::: tip
|
||||
*참고*: 이 단계에서 문제가 있으시다면 최신 스테이블 GO 버전이 설치되어있는지 확인해주세요.
|
||||
:::
|
||||
|
||||
위 예시에서는 가장 최신 스테이블 릴리즈가 있는 `master`를 사용합니다. 테스트넷마다 운용하는 릴리즈가 다를 경우가 있으니 [testnet repo](https://github.com/cosmos/testnets)를 확인하셔서 어떤 버전이 필요한지 확인하시고, [SDK 릴리즈 페이지](https://github.com/cosmos/cosmos-sdk/releases)에서 각 릴리즈에 대한 정보를 확인하세요.
|
||||
|
||||
이제 풀 노드가 깔끔하게 업그레이드 되었습니다!
|
||||
|
||||
## 제네시스와 시드
|
||||
|
||||
### 제네시스 파일 복사하기
|
||||
|
||||
테스트넷의 `genesis.json`파일을 `gaiad`의 config 디렉토리로 가져옵니다.
|
||||
|
||||
```bash
|
||||
mkdir -p $HOME/.gaiad/config
|
||||
curl https://raw.githubusercontent.com/cosmos/testnets/master/latest/genesis.json > $HOME/.gaiad/config/genesis.json
|
||||
```
|
||||
|
||||
위 예시에서는 최신 테스트넷에 대한 정보가 포함되어있는 [테스트넷 repo]의 `latest`를 이용하는 것을 참고하세요. 만약 다른 테스트넷에 연결하신다면 해당 테스트넷의 파일을 가져오는 것인지 확인하세요.
|
||||
|
||||
설정이 올바르게 작동하는지 확인하기 위해서는 다음을 실행하세요:
|
||||
|
||||
```bash
|
||||
gaiad start
|
||||
```
|
||||
|
||||
### 시드 노드 추가하기
|
||||
|
||||
이제 노드가 다른 피어들을 찾는 방법을 알아야합니다. `$HOME/.gaiad/config/config.toml`에 안정적인 시드 노드들을 추가할 차례입니다. `testnets` repo에 각 테스트넷에 대한 시드 노드 링크가 포함되어있습니다. 만약 현재 운영되고 있는 테스트넷을 참가하고 싶으시다면 [여기](https://github.com/cosmos/testnets)에서 어떤 노드를 이용할지 확인하세요.
|
||||
|
||||
만약 해당 시드가 작동하지 않는다면, 추가적인 시드와 피어들을 [코스모스 익스플로러](https://explorer.cosmos.network/nodes)를 통해 확인하실 수 있습니다. `Full Nodes` 탭을 들어가셔서 프라이빗(`10.x.x.x`) 또는 로컬 IP 주소(https://en.wikipedia.org/wiki/Private_network)가 *아닌* 노드를 열어보세요. `Persistent Peer` 값에 연결 스트링(connection string)이 표기되어 있습니다. 가장 최적화된 결과를 위해서는 4-6을 이용하세요.
|
||||
|
||||
이 외에도 [밸리데이터 라이엇 채팅방](https://riot.im/app/#/room/#cosmos-validators:matrix.org)을 통해서 피어 요청을 할 수 있습니다.
|
||||
|
||||
시드와 피어에 대한 더 많은 정보를 원하시면 [여기](https://github.com/tendermint/tendermint/blob/develop/docs/tendermint-core/using-tendermint.md#peers)를 확인하세요.
|
||||
|
||||
## 풀노드 운영하기
|
||||
|
||||
다음 커맨드로 풀노드를 시작하세요:
|
||||
|
||||
```bash
|
||||
gaiad start
|
||||
```
|
||||
|
||||
모든 것이 잘 작동하고 있는지 확인하기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiacli status
|
||||
```
|
||||
|
||||
네트워크 상태를 [코스모스 익스플로러](https://explorecosmos.network)를 통해 확인하세요. 현재 풀 노드가 현재 블록높이로 싱크되었을 경우, 익스플로러의 [풀 노드 리스트](https://explorecosmos.network/validators)에 표시가 될 것입니다. 익스플로러가 모든 노드에 연결하지는 않아 표시가 되지 않을 수 있다는 점 참고해주십시오.
|
||||
|
||||
## 상태 내보내기(Export State)
|
||||
|
||||
Gaia는 현재 애플리케이션의 상태를 JSON파일 형태로 내보낼 수 있습니다. 이런 데이터는 수동 분석과 새로운 네트워크의 제네시스 파일로 이용될 때 유용할 수 있습니다.
|
||||
|
||||
현재 상태를 내보내기 위해서는:
|
||||
|
||||
```bash
|
||||
gaiad export > [filename].json
|
||||
```
|
||||
|
||||
특정 블록 높이의 상태를 내보낼 수 있습니다(해당 블록 처리 후 상태):
|
||||
|
||||
```bash
|
||||
gaiad export --height [height] > [filename].json
|
||||
```
|
||||
|
||||
만약 해당 상태를 기반으로 새로운 네트워크를 시작하시려 한다면, `--for-zero-height` 플래그를 이용하셔서 내보내기를 실행해주세요:
|
||||
|
||||
```bash
|
||||
gaiad export --height [height] --for-zero-height > [filename].json
|
||||
```
|
||||
|
||||
## 밸리데이터 노드로 업그레이드 하기
|
||||
|
||||
이제 풀노드가 활성화 되었습니다! 다음은 무엇일까요?
|
||||
|
||||
이제는 해당 풀노드를 업그레이드 하여 코스모스 밸리데이터가 될 수 있습니다. 상위 100개 밸리데이터는 코스모스 허브의 블록 생성과 제안을 할 수 있습니다. 밸리데이터 노드로 업그레이드 하시기 위해서는 [밸리데이터 설정하기](./validators/validator-setup.md) 항목으로 넘어가주세요.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
# 키
|
||||
|
||||
키 관리에 대해서는 [텐더민트 스펙](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/encoding.md#public-key-cryptography)을 확인하세요.
|
||||
|
||||
`gaiacli keys --help` 명령어를 통해 추가 정보를 얻으실 수 있습니다.
|
||||
|
||||
[테스트넷 투토리얼](https://github.com/cosmos/cosmos-sdk/tree/develop/cmd/gaia/testnets)에서 관련 정보를 확인하실 수 있습니다.
|
||||
|
||||
참고: 이 문서는 현재 작업중에 있습니다.
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
# 레저(Ledger) 나노 하드웨어 지갑 지원
|
||||
|
||||
### 레저 시드를 이용한 계정 키 관리
|
||||
|
||||
이제 `gaiacli` 가 레저(Ledger) 시드를 통한 계정 키 관리를 지원합니다. 해당 기능을 이용하시기 위해서는 다음이 필요합니다:
|
||||
|
||||
- 이용하실 네트워크와 연결된 `gaiad` 인스턴스.
|
||||
- 사용하시는 `gaiad` 인스턴스와 연동된 `gaiacli` 인스턴스.
|
||||
- `ledger-cosmos` 앱이 설치된 레저 나노 기기.
|
||||
* 레저 기기에 코스모스 앱을 설치하기 위해서는 [`ledger-cosmos`](https://github.com/cosmos/ledger-cosmos/blob/master/docs/BUILD.md) 깃허브 레포지토리를 확인하세요.
|
||||
* 실전 운용 가능한 앱 버전은 추후 [레저 앱스토어](https://www.ledgerwallet.com/apps)를 통해 배포될 예정입니다.
|
||||
|
||||
> **참고:** 코스모스 키는 [BIP 44 Hierarchical Deterministic wallet 스펙](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)에 파생되었습니다. 관련 패스에 대한 정보는 [hd package](https://github.com/cosmos/cosmos-sdk/blob/develop/crypto/keys/hd/hdpath.go#L30)를 참고하세요.
|
||||
|
||||
코스모스 앱을 레저 기기에 성공적으로 설치하시고, `gaiacli` 에서 레저와 연결하는데 성공하셨다면 다음과 같이 레저 키를 생성하실 수 있습니다:
|
||||
|
||||
```bash
|
||||
$ gaiacli keys add {{ .Key.Name }} --ledger
|
||||
NAME: TYPE: ADDRESS: PUBKEY:
|
||||
{{ .Key.Name }} ledger cosmos1aw64xxr80lwqqdk8u2xhlrkxqaxamkr3e2g943 cosmospub1addwnpepqvhs678gh9aqrjc2tg2vezw86csnvgzqq530ujkunt5tkuc7lhjkz5mj629
|
||||
```
|
||||
|
||||
이 키는 레저가 연결되고 잠금 해제된 상태에서면 사용이 가능합니다. 해당 키를 이용해 코인을 전송하시려면 다음 명령을 실행하세요:
|
||||
|
||||
|
||||
```bash
|
||||
$ gaiacli tx send { .Destination.AccAddr } 10stake --from { .Key.Name } --chain-id=gaia-7000
|
||||
```
|
||||
|
||||
레저 기기에서 해당 트랜잭션을 검토하신 후 서명이 되었다면 트랜잭션 결과를 레저 기기에서 확인하실 수 있습니다.
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
# 검증인(밸리데이터) 개요
|
||||
|
||||
## 소개
|
||||
|
||||
[코스모스 허브](/introduction/cosmos-hub.md)는 [텐더민트](/introduction/tendermint.md) 기반으로 만들어졌으며 특정 검증인들이 블록체인에 새로운 블록을 기록하는 절차를 기반으로 설계되었습니다. 검증인들은 각 검증인들의 프라이빗키로 서명된 암호화된 표(votes)를 전파하면서 합의 프로토콜에 참여합니다.
|
||||
|
||||
검증인 후보는 본인들의 아톰을 자체적으로 위임하거나, 위임자들의 아톰을 위임받을 수 있습니다. 코스모스 허브는 100개의 검증인으로 시작하여 300개의 검증인으로 숫자를 늘려나갈 예정입니다. 검증인은 위임량에 따라서 정해지며, 상위 100위 검증인은 코스모스 검증인으로 선출됩니다.
|
||||
|
||||
검증인들과 위임자들은 텐더민트 합의 프로토콜에 참여하며 블록생성에 대한 보상을 지급받게 됩니다. 초기에 트랜잭션 수수료는 아톰으로 결제되지만, 거버넌스로 통과된 '화이트리스트 토큰'들이 수수료 토큰으로 이용될 수 있습니다. 추가적으로 검증인들은 본인의 검증인 서비스 제공에 대한 커미션을 측정할 수 있습니다.
|
||||
|
||||
만약 검증인이 이중서명(double sign)을 하거나, 자주 오프라인 되거나 또는 거버넌스에 참여하지 않는 경우, 그들의 아톰과 해당 검증인에게 위임된 아톰은 '슬래싱'당할 수 있습니다. 슬래싱 페널티는 악의적 행동의 중대성에 따라 비례합니다.
|
||||
|
||||
## 하드웨어
|
||||
|
||||
현재 검증인의 키 관리에 적합한 클라우드 솔루션은 없습니다. 앞으로 클라우드 SGX 도입이 되면서 조금 더 안전한 솔루션이 제공될 수 있을 것으로 기대되고 있습니다. 하지만 현재로써 클라우드 키 관리에 리스크가 있기 때문에 검증인들은 제한된 안전한 구역에 장비를 세팅하는 것을 추천합니다. 보안이 확보되는 특정 데이터 센터의 코로케이션(co-location) 같은 형태로 운영이 될 수 있습니다.
|
||||
|
||||
검증인들은 서버 장비가 운영되는 데이터센터에 스토리지 백업, 복수 회선, 그리고 전력 백업 등의 시스템이 갖춰져 있는 것을 확인해야 합니다. 광선, 방화벽, 스위칭 등 또한 중복되어있는 것을 추천드립니다. 하드웨어 성능에는 중저형 서버로 시작해도 충분할 것으로 예상되나, 충분한 검증과 테스팅을 실행하시는 것을 추천드립니다.
|
||||
|
||||
코스모스 생태계 초기의 네트워크 사용량은 크지 않을 것으로 예상되며, 현재 테스트넷은 대량의 리소스를 필요로 하지 않습니다. 하지만 네트워크가 성장하며 대역폭, CPU와 메모리 사용량이 높아질 것으로 예상됩니다. 추가적으로, 몇년의 블록체인 기록을 저장해야되기 때문에 대용량 하드드라이브를 이용하시는 것을 추천드립니다.
|
||||
|
||||
## 웹사이트 세팅하기
|
||||
|
||||
검증인의 고유 웹사이트를 만드시고, 코스모스 [포럼](https://forum.cosmos.network/t/validator-candidates-websites/127/3)을 통해서 검증인 참여 의사를 알려주십시오. 위임인들은 위임 대상 검증인에 대한 정보를 확인하려 할 수 있으니, 관련 정보를 기제해주시기 바랍니다.
|
||||
|
||||
## 법적 검토
|
||||
|
||||
검증인 사업을 운영하시기 전에 전문 법적 검토를 미리 받으실 것을 추천드립니다.
|
||||
|
||||
## 검증인 커뮤니티
|
||||
|
||||
추가적으로 검증인을 운영하는 것에 대한 질문과 정보는 검증인 커뮤니티 채팅방과 포럼을 이용하세요:
|
||||
|
||||
* [검증인 채팅](https://riot.im/app/#/room/#cosmos_validators:matrix.org)
|
||||
* [검증인 포럼](https://forum.cosmos.network/c/validating)
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
## 검증인 보안
|
||||
|
||||
검증인 세팅의 다양성이 네트워크 전체의 탄력성을 증가하기 때문에 각 검증인은 각자 독립적인 형태로 노드를 운영하는 것을 추천합니다. 메인넷을 대비하기 위해서 지금 부터 노드 운영을 시작하실 것을 추천합니다.
|
||||
|
||||
## 키 관리 - HSM
|
||||
|
||||
안전한 노드 운영의 기초는 공격자가 검증인의 프라이빗키를 탈취할 수 없게 하는 것입니다. 만약 이 것이 가능하다면, 키가 탈취된 모든 위임된 코인은 위험에 처해질 수 있습니다. 이런 리스크를 줄이기 위한 가장 좋은 방법은 하드웨어 보안 모듈(HSM, Hardware Security Module)을 이용하는 것입니다.
|
||||
|
||||
코스모스 허브에서 HSM을 사용하시는 경우, 해당 모듈은 `ed25519` 서명을 지원해야 합니다. YubiHSM2는 `ed25519`를 지원하며 이에 대한 어답터 라이브러리(adapter library)는 추후 지원할 계획입니다. YubiHSM은 프라이빗 키 탈취에 대한 보안을 지원하지만, 동일한 블록을 두번 서명하는 것에 대한 안전성은 제공하지 않는다는 것에 유의하시기 바랍니다.
|
||||
|
||||
이 외에도 텐더민트 팀은 현재 검증인 서명을 위한 Ledger Nano S 지원을 준비하고 있습니다. Ledger Nano S의 경우 최신 블록을 저장하기 떄문에 더블사인 공격을 막을 수 있을 것으로 보입니다.
|
||||
|
||||
추후 솔루션들이 준비되는대로 이 페이지는 업데이트 됩니다.
|
||||
|
||||
## 센트리노드 (DDOS 방어)
|
||||
|
||||
검증인은 코스모스 네트워크가 일정의 서비스 거부 공격(denial of service) 공격을 감내할 수 있도록 해야 합니다.
|
||||
|
||||
이런 공격을 방어할 방법 중 하나는 검증인이 본인의 네트워크를 '센트리노드 아키텍쳐' 형태로 구성하는 것입니다.
|
||||
|
||||
검증인은 신뢰할 수 있는 풀노드에만 연결해야 합니다. 이는 본인이 직접 운영하는 노드 또는 사회적으로(개인적으로) 아는 검증인들이 운영하는 풀노드 등이 포함될 수 있습니다. 대다수의 검증인 노드는 데이터센터에서 운영됩니다. 대다수의 데이터센터는 다른 주요 클라우드 서비스 제공자와 직접적인 링크를 제공합니다. 검증인들은 이런 링크를 통해서 클라우드 기반 센트리를 연결할 수 있습니다. 이런 형태의 아키텍쳐는 DDoS 공격의 부담을 검증 노드에서 센트리노드로 우회시키기 때문에 상황에 따라 추가적인 센트리노드를 운영해야될 수 있습니다.
|
||||
|
||||
센트리노드는 빠르게 추가될 수 있으며 상황에 따라 IP 주소를 변경할 수 있습니다. 센트리노드와 검증인 노드 간의 연결은 프라이빗 IP를 통해 이루어지기 때문에, 인터넷 기반 공격의 피해를 줄일 수 있습니다. 이런 형태의 디자인은 검증인의 블록 제안과 투표가 언제나 네트워크에 전달될 수 있게 합니다.
|
||||
|
||||
센트리노드 아키텍쳐를 세팅하시기 위해서는 다음 절차를 참고하십시오:
|
||||
|
||||
검증인 노드는 해당 노드의 `config.toml`을 수정해야 합니다:
|
||||
|
||||
```bash
|
||||
# Comma separated list of nodes to keep persistent connections to
|
||||
# Do not add private peers to this list if you don't want them advertised
|
||||
persistent_peers =[list of sentry nodes]
|
||||
|
||||
# Set true to enable the peer-exchange reactor
|
||||
pex = false
|
||||
```
|
||||
|
||||
센트리노드 또한 해당 노드의 `config.toml` 파일을 수정해야 합니다:
|
||||
|
||||
```bash
|
||||
# Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
|
||||
private_peer_ids = "ipaddress of validator nodes"
|
||||
```
|
||||
|
||||
## 환경 변수
|
||||
|
||||
기본적으로 다음 프리픽스(prefix)의 대문자 환경 변수(environment variables)는 소문자 커맨드라인 플래그를 대체하게 됩니다:
|
||||
|
||||
- `GA` (for Gaia 플래그)
|
||||
- `TM` (for Tendermint 플래그)
|
||||
- `BC` (for democli 또는 basecli 플래그)
|
||||
|
||||
예를들어 `GA_CHAIN_ID` 환경 변수는 `--chain-id` 커맨드라인 플래그에 매핑됩니다. 명백한(explicit) 커맨드라인 플래그는 환경 변수 보다 상위에 속하며, 환경 변수는 모든 설정 파일 보다 상위에 속합니다. 중요한 파라미터는 CLI의 플래그로 정의되어야 하며 환경 변수의 수정 가능성을 줄이는 것이 중요합니다.
|
||||
|
||||
|
|
@ -0,0 +1,308 @@
|
|||
# 검증인 FAQ
|
||||
|
||||
::: warning 경고
|
||||
코스모스 프로젝트는 현재 진행형입니다. 메커니즘과 값은 추후 변경될 수 있다는 점을 확인하십시오.
|
||||
:::
|
||||
|
||||
## 기본 개념
|
||||
|
||||
### 검증인이란 무엇인가?
|
||||
|
||||
[코스모스 허브](/introduction/cosmos-hub.md)는 [텐더민트](/introduction/tendermint.md) 기반으로 특정 [검증인](/validators/overview.md) 들이 네트워크의 보안을 지키는 허브입니다. 검증인들은 풀노드를 운영하며 본인의 프라이빗키로 서명된 암호화된 서명으로 투표를 하며, 이 표를 네트워크에 전파하여 합의 절차에 참여하게 됩니다. 검증인들은 새로운 블록은 블록체인에 기록하고, 이런 역할에 대한 보상을 받게됩니다. 또한 검증인은 프로포절에 대한 투표를 하며 거버넌스 절차에 참여합니다. 검증인들의 순위는 위임 받은 코인 수량에 따라서 정해집니다.
|
||||
|
||||
### '스테이킹'은 무엇인가?
|
||||
|
||||
코스모스 허브는 퍼블릭 지분증명 블록체인입니다. 이는 각 검증인들의 순위가 각자가 위임받아 본딩된 스테이킹 토큰(아톰)의 수량에 따라 순위가 정해진다는 것입니다. 검증인은 스테이킹은 검증인 자체 물량 또는 위임자가 위임한 토큰이 될 수 있습니다.
|
||||
|
||||
검증인이 될 의사가 있는 유저는 누구나 `create-validator` 트랜잭션을 발생시켜 의사를 표시하고 검증인이 될 수 있습니다.
|
||||
|
||||
(스테이킹 수량으로 결정되는) 검증인의 가중치(weight)는 해당 검증인이 실제 블록 생성에 참여할 수 있는지를 결정하며, 얼마나 자주 블록은 제안할 수 있는지와 얼마나 많은 보상을 가저가는지에 영향을 끼칩니다. 초기에는 가중치가 높은 100개의 검증인들이 실제 블록생성에 참여합니다. 만약 검증인이 이중서명을 하거나, 자주 오프라인 상태로 전환되거나, 거버넌스 절차에 참여하지 않을경우 위임된 모든 아톰(자체물량과 위임 받은 물량 포함)은 '슬래싱'되어 사라지게 됩니다.
|
||||
|
||||
### 풀노드는 무엇인가?
|
||||
|
||||
풀노드는 블록의 블록과 트랜잭션을 검증하는 프로그램입니다. 라이트노드와의 차이점은 라이트노드의 경우 블록헤더와 일부 소량의 트랜잭션을 처리하지만, 풀노드는 모든 거래와 모든 기록을 저장하고 검증합니다. 풀노드를 운영하기 위해서는 라이트노드보다 많은 리소스가 필요하지만, 검증인을 운영하기 위해서는 필수적입니다. 실질적으로 풀노드를 운영한다는 것은 최신 버전과 안전성이 확보된 소프트웨어를 다운타임과 네트워크 지연없이 운영하는 것입니다.
|
||||
|
||||
검증인을 운영할 의사가 없는 유저들도 풀노드를 운영할 수 있습니다.
|
||||
|
||||
### 위임인은 무엇인가?
|
||||
|
||||
위임자/위임인은 아톰을 보유하고 있지만 검증인을 운영할 수 없거나, 운영할 의사가 없는 유저입니다. 위임인은 [코스모스 보이저][Cosmos Voyager](/getting-started/voyager.md) 또는 다른 지갑을 통해 본인의 아톰을 검증인에게 위임하여 검증인 보상의 일부를 돌려받을 수 있습니다(보상 분배에 대한 자세한 정보는 **스테이킹의 인센티브**와 **검증인 커미션은 무엇인가?** 항목을 확인하십시오).
|
||||
|
||||
위임인은 검증인들과 보상을 나누기 때문에, 위임인에게도 책임이 주어집니다. 만약 검증인이 악의적인 행동을 한다면 위임인들의 토큰 또한 함께 슬래싱될 수 있습니다. 그렇기 때문에 위임인들은 위임을 하기 전 충분한 검토와 조사를 실시한 후 위임을 해야하며, 다수의 검증인에게 분산위임하는 방법을 추천합니다.
|
||||
|
||||
위임인들은 코스모스 네트워크를 운영하는 검증인들을 선택하는 역할을 하기 때문에네 네트워크의 핵심적인 역할을 하는 유저입니다. 위임인은 수동적인 역할을 하는 유저가 아닙니다. 활발하게 검증인들의 활동과 행동을 모니터링하고 그들의 거버넌스 참여 투표 등을 자주 확인해야할 필요가 있습니다.
|
||||
|
||||
## 검증인 되기
|
||||
|
||||
### 어떻게 검증인이 되는가?
|
||||
|
||||
네트워크에 참여하는 모든 유저는 `create-validator` 트랜잭션을 통해 본인이 검증인이 될 의사를 표시할 수 있습니다. 해당 트랜잭션에는 다음과 같은 값이 포함되어야 합니다:
|
||||
|
||||
* 검증인의 PubKey: PubKey와 연관된 프라이빗키는 _prevote_ 와 _precommit_ 을 서명하는데 사용됩니다. 이런 방식을 통해서 검증인은 유동적 자금이 있는 계정과 검증용 계정을 따로 관리할 수 있습니다.
|
||||
* 검증인 주소: 애플리케이션 단 주소입니다. 이 주소는 공개적으로 검증인의 신원을 확인할때 이용됩니다. 해당 주소와 연관되어있는 프라이빗키는 본딩, 언본딩, 보상 수령, 거버넌스 참여 등에서 이용됩니다.
|
||||
* 검증인 이름(moniker)
|
||||
* 검증인 웹사이트(선택 사항)
|
||||
* 검증인 설명(선택 사항)
|
||||
* 최초 커미션: 블록 검증으로 받는 보상에서 위임인들 지불되기 전 삭감되는 수수료
|
||||
* 최대 커미션: 해당 검증인이 설정한 최대 수수료
|
||||
* 최소 셀프본딩 수량: 검증인이 최소로 본딩해야 하는 아톰의 수량. 만약 해당 검증인의 총 위임 수량이 이 값보다 떨어지는 경우, 스테이킹 풀 전체는 언본딩 됩니다.
|
||||
* 최초 셀프본딩 수량: 최초로 검증인이 자체 스테이킹 하는 수량.
|
||||
|
||||
이제 검증인이 만들어지면, 위임인들은 해당 검증인에게 아톰을 위임하며 해당 스테이킹 풀의 수량을 늘려갈 수 있습니다. 특정 주소의 총 스테이크는 자체 스테이킹 물량 + 위임 받은 스테이킹 물량입니다.
|
||||
|
||||
검증인으로 참가할 의사를 밝힌 모든 검증인 중 스테이킹 수량이 가장 많은 상위 100개의 검증인은 '활성화된 검증인'으로 블록생성에 참여할 수 있게 됩니다. 상위 100 순위 밖으로 나가게 되는 검증인은 **bonded 검증인**이 되며 검증인 권한을 일게됩니다. 이때 해당 검증인의 물량은 **언본딩 모드**로 들어가면서 서서히 **언본딩** 됩니다.
|
||||
|
||||
코스모스 허브의 검증인 수는 시간이 지날수록 다음과 같이 인상될 예정입니다:
|
||||
|
||||
* **0년차:** 100
|
||||
* **1년차:** 113
|
||||
* **2년차:** 127
|
||||
* **3년차:** 144
|
||||
* **4년차:** 163
|
||||
* **5년차:** 184
|
||||
* **6년차:** 208
|
||||
* **7년차:** 235
|
||||
* **8년차:** 265
|
||||
* **9년차:** 300
|
||||
* **10년차:** 300
|
||||
|
||||
## 테스트넷
|
||||
|
||||
### 어떻게 테스트넷에 참여할 수 있나요?
|
||||
|
||||
테스트넷은 로치 전에 검증인 세팅을 확인할 수 있는 좋은 환경입니다. 테스트넷에 참가함으로 본인이 검증인 운영을 위해 준비해왔다는 것을 보여주는 기회가 될 수도 있습니다. 테스트넷에 관련된 정보는 [여기](https://github.com/cosmos/cosmos-sdk/tree/develop/cmd/gaia/testnets) 와 [여기](https://github.com/cosmos/testnets)에서 확인하실 수 있습니다.
|
||||
|
||||
### 어떤 종류들의 '키'가 있나요?
|
||||
|
||||
간략하게 설명하면 두가지 종류의 키가 있습니다:
|
||||
|
||||
* **텐더민트 키**: 이 키는 블록 해시를 서명할때 이용되는 고유 키입니다. 해당 키는 `cosmosvalconspub` 퍼블릭키와 연관되어 있습니다.
|
||||
* gaiad init으로 노드가 생성될때 키가 생성되며
|
||||
* 해당 키 정보는 `gaiad tendermint show-validator` 명령어로 확인하실 수 있습니다. 예) `cosmosvalconspub1zcjduc3qcyj09qc03elte23zwshdx92jm6ce88fgc90rtqhjx8v0608qh5ssp0w94c`
|
||||
|
||||
* **애플리케이션 키**: 이 키는 애플리케이션에 의하여 생성되고 트랜잭션을 서명할때 이용됩니다. 검증인으로써는 이 키를 스테이킹 관련 트랜잭션과 거버넌스 관련 트랜잭션을 서명할때 이용하시게 됩니다. 애플리케이션 키는 `cosmospub` 퍼블릭키와 `cosmos` 주소와 연관되어있습니다. 두 키 모두 `gaiacli keys add` 명령으로 생성됩니다.
|
||||
* 참고: 특정 검증인의 운영키는 애플리케이션키와 연관이 있으나 `cosmosvaloper`와 `cosmosvaloperpub`같은 특정 용도에만 맞는 사전 정의된 prefix를 이용합니다.
|
||||
|
||||
### 밸리데이터들의 '상태(state)'에는 어떤 것들이 있나요?
|
||||
|
||||
`create-validator` 트랜잭션을 통해 만들어진 검증인은 총 3개의 상태가 있을 수 있습니다:
|
||||
|
||||
- `bonded`: 검증인은 현재 합의에 참가하고 있는 활성화된 검증인입니다. 이 검증인은 블록 보상을 받을 수 있으며, 악의적인 행동에 대한 슬래싱 페널티를 받을 수도 있습니다.
|
||||
- `unbonding`: 검증인은 현재 합의에 참가하고 있지 않으면 활성화된 검증인 세트에 포함되어있지 않습니다. 검증인은 블록 생성을 받지 않지만 악의적인 행동에 대한 슬래싱 페널티는 적용될 수 있습니다. 이 상태는 `bonded` 상태인 검증인이 `unbonded`으로 전환되는 중간 상태이며, 만약 `unbonding` 상태에서 `rebond` 트랜잭션을 발생하지 않으면 최대 3주간 중간 단계에 머무를 수 있습니다.
|
||||
- `unbonded`: 검증인은 합의에 참가하고 있지 않은 검증인이며, 활성화된 검증인 세트에 포함되어있지 않습니다. 이 검증인은 블록 생성 보상을 받지 않으며 슬래싱 페널티도 적용되지도 않습니다. 이 검증인에게 아톰을 위임하는 것은 가능합니다. `unbonded` 상태인 검증인으로 부터의 언본딩은 바로 처리 됩니다.
|
||||
|
||||
위임인들은 관련 검증인들과 동일한 상태를 가지게 됩니다.
|
||||
|
||||
*Note that delegation are not necessarily bonded. Atoms can be delegated and bonded, delegated and unbonding, delegated and unbonded, or liquid*
|
||||
|
||||
|
||||
### 셀프본딩은 무엇이며 어떻게 셀프본딩을 늘릴 수 있나요?
|
||||
|
||||
### 테스트넷 토큰은 어떻게 받을 수 있나요?
|
||||
|
||||
테스트넷 토큰을 받고 싶으시다면 [faucet](https://gaia.faucetcosmos.network/)을 통해서 받으실 수 있습니다.
|
||||
|
||||
### 활성화된 검증인이 되기 위해서 최소 필요한 아톰 수량이 있나요?
|
||||
|
||||
합의 프로세스에 참여하며 블록을 생성하는 검증인이 되기 위해서 특정 수량의 아톰이 필요하지는 않습니다. 다만, 셀프본딩 수량과 위임 받은 수량의 합이 사우이 100위에 들어야 활성화된 검증인이 되실 수 있습니다.
|
||||
|
||||
### 위임인들은 어떻게 검증인들을 선택하나요?
|
||||
|
||||
위임인들은 본인들이 설정한 기준에 따라 검증인을 선택할 자유가 있습니다. 검증인을 선택할때 고려해야하는 주요 사항은 다음과 같습니다:
|
||||
|
||||
* **셀프본딩 수랑:** 특정 검증인이 자체 본딩한 아톰의 수량입니다. 셀프본딩 수량이 높은 검증인은 본인의 행동에 따라 잃을 수 있는 것이 많기 때문에 더 많은 책임감이 부여될 수 있습니다.
|
||||
* **위임된 아톰 수량:** 해당 검증인이 위임받은 아톰의 총 수량. 높은 위임 수량은 해당 검증인에 대한 신뢰도가 높다는 것을 뜻할 수 있습니다. 다만, 대형 검증인은 책임지고 있는 물량이 많기 때문에 해커들의 타겟이 될 수 있다는 위험이 존재할 수 있습니다. 해커들은 특정 검증인이 위임하고 있는 물량의 일정 %를 보상으로 받기 때문에 해커는 대형 검증인을 타겟할 확률이 높습니다. 검증인이 위임받고 있는 아톰이 과도할 경우, 높은 위임 수량은 단점으로 적용될 수 있습니다.
|
||||
* **커미션:** 해당 검증인이 생성하는 보상에 대하여 위임인들에게 청구하는 수수료입니다.
|
||||
* **검증인 활동 기록:** 위임인들은 본인들의 아톰을 위임하기 전 검증인들의 활동 기록을 먼저 살펴볼 수 있습니다. 이 항목에는 활동 기간, 과거 투표 현황, 업타임 기록, 노드 공격 기록 등이 포함될 수 있습니다.
|
||||
|
||||
위에 표기된 항목 외에도 검증인 정보에 포함되어있는 웹사이트를 통해서 검증인에 대한 정보를 받을 수 있습니다. 검증인 세팅에 대해 외부 감사를 받은 경우 이를 표기하는 것도 좋은 기록이 될 수 있습니다. 참고로 텐더민트 팀은 특정 검증인에 대한 감사를 진행하지 않습니다. 검증인 선택 기준에 대한 더 많은 정보는 [이 블로그 글](https://medium.com/@interchain_io/3d0faf10ce6f)에서 확인하실 수 있습니다.
|
||||
|
||||
## 검증인들의 책임
|
||||
|
||||
### 검증인을 하기 위해서는 신원을 밝혀야 하나요?
|
||||
|
||||
아닙니다. 각 위임인들은 본인들이 설정한 기준으로 각자 투표를 합니다. 검증인들은 홍보 용도를 위해서 본인들에 대한 정보가 표기된 웹사이트를 공개하는 것을 추천합니다. 해당 웹사이트에서 본인들의 정보를 공개할 것인지 또는 익명으로 본인들의 활동 기록만을 공개할 것인지는 검증인의 선택입니다. 코스모스 허브에는 익명의 팀과 팀 정보를 공개하는 팀이 공존할 확률이 높습니다.
|
||||
|
||||
### 검증인들이 되기 위해서는 어떤 책임이 있나요?
|
||||
|
||||
검증인들은 다음과 같은 책임이 있습니다:
|
||||
|
||||
* **언제나 올바른 소프트웨어로 노드를 운영하기:** 검증인들은 본인들의 서버가 언제나 온라인 상태며 프라이빗키가 탈취당하지 않게 관리를 해야합니다.
|
||||
* **활발하게 거버넌스에 참가하기:** 검증인들은 모든 프로포절에 투표를 해야 합니다.
|
||||
|
||||
추가적으로 검증인들은 코스모스 커뮤니티에서 활동을 해야합니다. 검증인들은 생태계의 현재 상황에 대해 언제나 인지하며 혹시 있을 변화에 유연하게 대처할 수 있어야 합니다.
|
||||
|
||||
### '거버넌스에 참여'한다는 것은 무슨 뜻인가요?
|
||||
|
||||
코스모스 허브의 검증인들과 위임인들은 블록 가스 제한 같은 운영적 파라미터(operational parameters) 변경을 요청하거나, 소프트웨어 업그레이드를 조율하거나, 코스모스 허브에 대한 헌법을 제안할 수 있습니다.
|
||||
|
||||
검증인들은 거버넌스 시스템에서 특별한 역할을 합니다. 검증인들은 코스모스 허브의 기둥으로써 모든 프로포절에 투표를 해야합니다. 이는 투표에 참가하지 않는 위임인들이 검증인들의 투표를 따르기 때문에 특히 중요합니다. 프로포절에 투표를 하지 않는 검증인에게는 슬래싱 페널티가 부여됩니다.
|
||||
|
||||
### 스테이킹은 어떤 의미를 가지나요?
|
||||
|
||||
아톰을 스테이킹하는 것은 검증 활동에 대한 보증금이라고 생각하시면 됩니다. 만약 특정 검증인 또는 위임인이 본인의 아톰의 전체(또는 일부)를 언본딩 하기 위해서는 언본딩 트랜잭션을 발생해야 합니다. 이후, 해당 아톰은 _3주 간의_ 언본딩 기간을 두며 검증인들의 악의적인 행동에 대해 함께 책임을 지게 됩니다.
|
||||
|
||||
검증인과 해당 검증인에 위임을 한 위임인들은 블록 생성에 대한 보상, 수수료 보상, 그리고 거버넌스에 참여할 권한을 부여받습니다. 만약 특정 검증인이 악의적인 행동을 한다면 해당 검증인의 검증 권한에 있는 아톰은 슬래싱 페널티를 받을 수 있습니다. 그렇기 때문에, 위임인들은 검증인이 안정적이고 안전성을 보장할 수 있는 여부를 확인할 필요가 있습니다.
|
||||
|
||||
### 검증인은 위임인들의 위임된 아톰을 탈취할 수 있나요?
|
||||
|
||||
검증인에게 위임을 하는 위임인은 '스테이킹 파워(staking power)'를 위임하는 것입니다. 검증인의 스테이킹 파워가 많을수록 해당 검증인은 합의 절차와 거버넌스 절차에서 가지는 힘이 커집니다. 하지만 검증인은 위임인의 아톰의 소유권을 가지지는 앖습니다. 코스모스 허브의 설계는 검증인이 위임인들의 아톰을 탈취할 수 없게 설계되었습니다.
|
||||
|
||||
검증인들은 위임인들의 자산을 직접적으로 탈취할 수 없지만, 검증인들의 악의적인 행동으로 발생하는 페널티에 대한 슬래싱은 검증인과 위임인들에게 동일하게 적용됩니다.
|
||||
|
||||
### 검증인들은 얼마나 자주 블록 생성 제안을 할 수 있는건가요? 확률은 스테이킹된 아톰에 비례해서 올라가나요?
|
||||
|
||||
블록체인의 다음 블록을 제안하는 검증인은 '제안자(proposer)'라고 불립니다. 각 제안자는 결정론적이게 선택되며, 제안자로 선택될 확률은 총 스테이킹 물량(셀프 본딩 스테이크 + 위임받은 스테이크)에 비례합니다. 예를들어, 모든 검증인들의 시스템상의 모든 스테이킹 수량이 100 아톰이고, 특정 검증인의 스테이킹 수량이 10아톰일 경우, 해당 검증인이 제안자로 선택될 확률은 10% 입니다.
|
||||
|
||||
### 코스모스 허브의 검증인은 코스모스 생태계 내 다른 존을 검증해야될 수도 있나요?
|
||||
|
||||
네, 그렇습니다. 초기에는 코스모스 허브의 검증인은 최초 이더민트 존을 검증해야합니다. 거버넌스에 의하여 결정된 경우, 코스모스 허브의 검증인은 코스모스 생태계 내의 다른 존 또한 검증해야 합니다. 검증인들은 이더민트 존과 동일하게 다른 존을 검증하는 것에 대한 블록 생성 보상과 트랜잭션 수수료를 보상으로 받을 수 있습니다.
|
||||
|
||||
## 인센티브
|
||||
|
||||
### 스테이킹을 할 인센티브는 무엇이 있나요?
|
||||
|
||||
특정 검증인의 스테이킹 풀의 참여자는 다수의 형태로 수익을 받을 수 있습니다:
|
||||
|
||||
* **블록 생성 보상:** 검증인들이 운영하는 특정 블록체인 애플리케이션의 고유 스테이킹 토큰(예, 코스모스 허브의 아톰)은 블록 생성을 통한 인플레이션이 있습니다. 인플레이션은 아톰 부유자들이 스테이킹을 할 인센티브를 부여하기 위한 목적이 있으며, 스테이킹을 하지 않는 아톰의 가치는 시간이 지날수록 희석됩니다.
|
||||
* **블록 리워드:**: 이더민트 존의 경우, 블록 생성 보상은 포톤(photon) 토큰으로 지급됩니다. 포톤은 초기에 이더리움에서 '하드 스푼(hard spoon)'을 통해 분배되며 이더리움 수량의 1:1 비율로 지급될 예정입니다(거버넌스에 따라 해당 사항은 변경될 수 있습니다).
|
||||
* **트랜잭션 수수료:** 코스모스 허브는 트랜잭션 수수료로 지불이 가능한 토큰들의 화이트리스트를 관리합니다.
|
||||
|
||||
위에 나열된 보상과 수수료로 발생하는 수익은 각 검증인의 총 스테이킹 물량에 비례하여 지급되며, 각 검증인 풀에 위임한 위임인들은 이 수익을 분배받습니다. 보상 수익은 각 검증인의 커미션을 차감한 후 지급된다는 점을 참고하시기 바랍니다.
|
||||
|
||||
### 검증인을 운영할 인센티브는 무엇이 있나요?
|
||||
|
||||
검증인은 커미션을 통해서 위임인들 보다 많은 보상을 받을 수 있습니다.
|
||||
|
||||
또한, 검증인들은 거버넌스 절차에서 더 큰 권한을 보유합니다. 예를 들어, 거버넌스 투표를 하지 않는 위임인은 본인이 스테이킹 한 검증인들의 표를 따르게 됩니다. 이런 이유로 검증인들은 생태계 내에서 중대한 책임감을 지게 됩니다.
|
||||
|
||||
### 검증인 커미션은 무엇인가요?
|
||||
|
||||
검증인 풀에게 지급되는 수익은 검증인과 위임인들 사이에서 나눠어집니다. 각 검증인은 위임인들에게 지급하는 수익에서 일정의 수수료를 '커미션'의 형태로 차감할 수 있습니다. 커미션은 퍼센트 값으로 설정됩니다. 각 검증인은 본인 정책에 따라 최초 커미션을 설정할 수 있으며, 일일 최대 변경값 또한 정할 수 있습니다. 코스모스 허브는 해당 검증인이 설정한 파라미터를 따릅니다. 이런 값은 검증인이 초기에 검증인 참여 의사를 밝힐때 설정할 수만 있으며, 검증인으로 선택된 이후 변경될 수 없습니다.
|
||||
|
||||
### 블록 생성 보상은 어떻게 나누어지나요?
|
||||
|
||||
블록 생성 보상은 검증인의 총 위임 물량에 비례하여 분배됩니다. 코스모스 허브는 블록을 생성한 검증인만 보상을 받지만 확률적으로 특정 기간 안에서 검증인들의 전체적인 블록 보상률은 스테이킹 수량에 비례하게 설계되었습니다.
|
||||
|
||||
10명의 검증인이 동일한 스테이킹 물량과 동일한 1%의 커미션을 가진 경우를 예시롤 들겠습니다. 만약 블록 생성에 대한 보상이 1,000 아톰이며 검증인들은 각자 20%의 스테이킹 물량을 자체 위임(셀프본딩) 했다고 보겠습니다. 1,000개의 블록생성 보상은 제안자에게 바로 지급되지 않으며, 검증인들 사이에서 스테이킹 수량에 비례하여 분배됩니다. 즉, 10명의 검증인들은 각자 100 아톰의 보상을 받게되는 것입니다. 이후 이 100 아톰은 다음과 같이 위임인들과 검증인들 사이에서 분배됩니다:
|
||||
|
||||
* 커미션: `100*80%*1% = 0.8아톰`
|
||||
* 밸리데이터가 가지는 보상: `100\*20% + 커미션 = 20.8 아톰`
|
||||
* 모든 위임인들이 나누는 보상: `100\*80% - 커시면 = 79.2 아톰`
|
||||
|
||||
이후 각 위임인은 79.2 아톰 중에서 각자 위임한 물량에 비례하는 보상을 수령할 수 있습니다. 포톤(photon) 또한 이와 동일한 메커니즘을 통해 분배됩니다.
|
||||
|
||||
### 수수료는 어떻게 나누어지나요?
|
||||
|
||||
수수료는 위와 비슷하게 분배되지만, 제안자가 최소 프리커밋(precommit) 보다 많은 프리커밋을 받을 경우 수수료에 대한 보너스를 지급 받습니다.
|
||||
|
||||
블록 제안자로 선택된 검증인은 다른 검증인 2/3 이상의 서명을 통해 프리커밋을 받아야 블록을 생성할 수 있습니다. 추가적으로, 제안자는 특정 블록에서 검증인 2/3 이상의 서명을 받는 것에 대한 인센티브가 존재합니다. 보너스는 선형적으로 증가합니다: 2/3의 프리커밋을 받은 경우 1% 보너스로 시작하여 100% 프리커밋을 받은 경우 5% 보너스로 증가합니다. 하지만 제안자는 프리커밋을 과도하게 기다릴 경우 블록 제안 시간을 초과하여 제안자 순서가 다른 검증인으로 넘어갈 수 있다는 점을 유의해야 합니다. 이런 이유로 검증인들은 시간을 초과하지 않되 최대한 많은 프리커밋을 받을 수 있는 기간의 균형을 찾아야 합니다. 이 메커니즘은 검증인이 빈 블록을 생성하는 것을 방지하고 검증인 간 네트워킹 향상하며 검증인 검열을 방지하기 위해 도입되었습니다.
|
||||
|
||||
이 개념에 대한 예시를 들겠습니다. 10명의 동일한 스테이킹 물량을 가진 검증인들이 각자 1% 커미션과 20% 자체 본딩을 하고 있는 상황을 가정합니다. 새로운 총 1025.51020408 아톰의 보상이 있는 새로운 블록이 생성됩니다.
|
||||
|
||||
우선 2% 수수료가 삭감되고 예비 풀(reserve pool)로 이동합니다. 이 예비 풀은 거버넌스를 통해 업그레이드와 버그 바운티를 지급하는데 이용됩니다.
|
||||
|
||||
* `2% \* 1025.51020408 = 20.51020408` 아톰이 예비 풀로 이동합니다.
|
||||
|
||||
이제 1005 아톰이 남아있습니다. 만약 블록 제안자가 해당 블록에 100% 프리커밋 서명을 포함했다면 최대 보너스인 5%를 지급받습니다.
|
||||
|
||||
각 검증인들에 대한 보상인 R을 찾기 위해서는 다음의 공식을 적용합니다:
|
||||
|
||||
`9*R + R R*5% = 1005 ⇔ R = 1005/10.05 = 100`
|
||||
|
||||
* 제안자 검증인:
|
||||
* 풀(pool)이 `R + R * 5%`를 얻음: 105 아톰
|
||||
* 커미션: `105 * 80% * 1%` = 0.84 아톰
|
||||
* 검증인 보상: `105 * 20% + 커미션` = 21.84 아톰
|
||||
* 위임인 보상: `105 * 80% - 커미션` = 83.16 아톰 (각 위임인은 본인의 위임 수량에 비례하는 보상을 받음)
|
||||
|
||||
* 제안을 하지 않은 검증인:
|
||||
* 풀이 R 아톰을 얻음: 100 아톰
|
||||
* 커미션: `100 * 80% * 1%` = 0.8 아톰
|
||||
* 검증인 보상: `105 * 20% + 커미션` = 20.8 아톰
|
||||
* 위임인 보상: `100 * 80% - 커미션` = 79.2 아톰 (각 위임인은 본인의 위임 수량에 비례하는 보상을 받음)
|
||||
|
||||
### 슬래싱 페널티를 발생하는 경우는 무엇이 있나요?
|
||||
|
||||
특정 검증인이 악의적으로 행동할 경우, 검증인에게 본딩된 아톰(위임인들의 아톰 포함)은 슬래싱이 됩니다. 슬래싱 페널티는 악의적인 행동에 비례한 가중치가 적용됩니다. 검증인과 위임인들의 스테이크가 슬래싱 되는 경우는 3개가 있습니다:
|
||||
|
||||
* **이중 서명(더블 사이닝):** 누군가 체인A에서 특정 검증인이 동일한 높이의 두개의 블록을 체인A와 체인B에서 서명한 경우 (체인A 와 체인B 가 동일한 ancestor에서 유례한 경우) 해당 검증인은 체인A에서 슬래싱될 수 있습니다.
|
||||
* **오프라인(unavailability):** 특정 검증인의 서명이 X 블록동안 포함되지 않았을 경우, 해당 검증인은 X 에 비례한 소량의 아톰이 슬래싱됩니다. 만약 X가 사전에 설정된 Y 한도보다 높을 경우, 해당 검증인은 언본딩 됩니다.
|
||||
* **미투표(non-voting):** 특정 검증인이 거버넌스 프로포절에 투표를 하지 않는 경우 소량의 스테이크가 슬래싱될 수 있습니다.
|
||||
|
||||
검증인의 행동의 의도적으로 악의적이지 않아도(예시: 노드 에러, 인터넷 연결 문제, DDoS, 프라이빗 탈취) 검증인은 슬래싱될 수 있다는 점을 참고하시기 바랍니다.
|
||||
|
||||
### 검증인은 꼭 자체 위임(셀프본딩)을 해야하나요?
|
||||
|
||||
검증인은 자체 위임을 하지 않아도 검증인을 할 수 있습니다. 검증인의 총 스테이킹 수량은 셀프본딩 수량과 위임 수량의 합입니다. 셀프본딩이 낮은 검증인은 많은 위임인들의 스테이크를 통해 총 스테이킹 수량을 늘릴수 있습니다. 이런 이유로 검증인의 평판은 중요한 요소로 적용합니다.
|
||||
|
||||
검증인이 셀프본딩 할 의무는 없을 수 있지만, 위임인들의 대다수는 검증인들이 셀프본딩을 하는 것을 선호할 수 있습니다. 본인에 행동에 대한 책임감을 보여줄 수 있기 때문입니다.
|
||||
|
||||
검증인들은 본인의 책임감을 표기하기 위해서 자체적인 최소 셀프본딩 수량을 설정할 수 있습니다. 만약 해당 검증인의 셀프본딩률이 해당 수치보다 낮아질 경우, 해당 검증인들과 모든 위임인들의 아톰은 언본딩 됩니다.
|
||||
|
||||
### 상위 검증인에게 스테이킹이 몰리는 현상은 어떻게 막을 수 있나요?
|
||||
|
||||
현재로써는 커뮤니티가 자체적으로 이런 위험성을 인지하고 위임하는 것을 예상하고 있습니다. 비트코인의 경우, 특정 채굴풀이 과도한 해시파워를 확보한 경우 커뮤니티는 자체적으로 해당 채굴풀에 대한 위임을 멈춥니다. 코스모스는 초기에 이와 비슷한 형태로 채굴풀의 중앙화를 조절할 수 있을 것으로 기대하고 있습니다. 추후에는 이런 현상을 막을 수 있는 장치들이 소개될 예정입니다:
|
||||
|
||||
* **무-페널티 재위임(penalty-free re-delegation):** 특정 검증인에 과도하게 묶여있는 현상을 줄이기 위해서 한 검증인에서 다른 검증인으로 위임을 쉽게 바꿀 수 있는 방식.
|
||||
* **해킹 바운티:** 커뮤니티가 검증인을 해킹하는 것을 장려하는 정책. 바운티 보상은 검증인이 스테이킹 하고 있는 물량의 크기에 비례.
|
||||
* **UI 경고:** 코스모스 보이저(Cosmos Voyager) 지갑을 이용하는 유저는 이미 과도한 스테이킹 물량을 보유하고 있는 검증인에게 위임을 하려고 할때 경고를 받는다.
|
||||
|
||||
## 기술적 요건
|
||||
|
||||
### 필요한 하드웨어 장비는 무엇인가요?
|
||||
|
||||
검증인은 전력, 네트워킹, 방화벽, 하드웨어 보안 모듈과 서버 백업이 있는 하나 이상의 데이터 센터를 제공할 것을 추천합니다.
|
||||
|
||||
네트워크 초기의 하드웨어 요건은 그리 고성능이 아닐 것으로 예상하고 있지만, 네트워크 사용량이 증가하면서 하드웨어 스펙 또한 증가할 것을 예상하고 있습니다. 테스트넷에 참가해서 하드웨어 세팅을 실험해보는 것을 추천드립니다.
|
||||
|
||||
### 필요한 소프트웨어는 무엇인가요?
|
||||
|
||||
코스모스 허브 노드 외에도 모니터링, 알림, 관리 솔루션을 준비해야할 것으로 예상하고 있습니다.
|
||||
|
||||
### 필요한 대역폭은 어느 정도 인가요?
|
||||
|
||||
코스모스 네트워크는 이더리움과 비트코인에 비교해서 많은 대역폭과 쓰루풋(throughput)을 필요로 합니다.
|
||||
|
||||
데이터 센터 노드는 신뢰할 수 있는 클라우드 풀노드와 사회적으로 신뢰할 수 있는 다른 검증인들에게만 연결하는 것을 추천드립니다. 이는 데이터 센터의 노드과 DDoS 공격의 피해를 입는 것을 방지할 수 있습니다.
|
||||
|
||||
네트워크가 성장하면서 매일 몇 기가바이트 이상의 대역폭을 사용하는 것은 현실적인 것으로 판단됩니다.
|
||||
|
||||
### 검증인을 하는 것은 운영 측면에서 어떤가요?
|
||||
|
||||
성공적인 검증인은 다수의 실력있는 운영 인력이 확보되어야 할 것으로 예측됩니다. 코스모스 검증인 운영은 비트코인 채굴에 비해서 높은 난이도에 속합니다.
|
||||
|
||||
### 키 관리는 어떻게 하는 것이 바람직한가요?
|
||||
|
||||
검증인은 ed25519 키를 지원하는 하드웨어 보안 모듈(HSM, Hardware Security Module)을 이용하는 것을 추천드립니다. 다음은 추천이 가능한 HSM들의 일부입니다:
|
||||
|
||||
* YubiHSM 2
|
||||
* Ledger Nano S
|
||||
* Ledger BOLOS SGX enclave
|
||||
* Thales nShield support
|
||||
|
||||
텐더민트 팀은 특정 회사의 솔루션을 지목하여 추천하지 않습니다. 검증인 커뮤니티는 자체적으로 HSM을 이용한 보안 솔루션을 연구하여 향상시킬 것을 권장합니다.
|
||||
|
||||
### 운영 측면에서 어떤 요소들이 있나요?
|
||||
|
||||
효율적으로 검증인을 운영하는 것은 예측 할 수 없는 언본딩과 슬래싱을 막는 것입니다. 이는 공격에 대한 대응, 전력 단절, 네트워크 단절, 보안 등에 대한 모든 위험 요소를 차단하고 준비하는 것입니다.
|
||||
|
||||
### 보수 측면에서 어떤 것들이 요구되나요?
|
||||
|
||||
검증인은 정기적으로 소프트웨어 업그레이드와 버그 패치를 적용해야합니다. 네트워크 초기에는 다수의 문제들이 발생할 수 있을 것으로 예상되기 때문에 검증인들은 유심히 네트워크 상태를 모니터링 해야 합니다.
|
||||
|
||||
### 검증인은 어떻게 DDoS 공격에 방어를 할 수 있을까요?
|
||||
|
||||
DDoS 공격은 공격자가 특정 IP의 서버에게 인터넷 트래픽을 과도하게 발생시켜 인터넷에 연결되는 것을 막는 공격입니다.
|
||||
|
||||
공격자는 네트워크를 스캔하여 특정 IP 주소를 지목하고 엄청난 트래픽을 발생시켜 공격을 하여 해당 노드의 정상적인 운영을 막습니다.
|
||||
|
||||
이런 공격을 막을 수 있는 하나의 방법은 노드에 센트리노드 아키텍쳐를 도입하여 방어율을 높이는 것입니다.
|
||||
|
||||
검증인 노드는 본인이 직접 운영하는 풀노드 또는 사회적으로 신뢰가 가능한 다른 검증인이 운영하는 풀노드에만 연결해야 합니다. 검증인 노드의 대다수는 데이터 센터에서 운영이 되며, 대다수의 데이터 센터는 다른 클라우드 서비스 제공자와 직접적인 연결을 제공합니다. 검증이는 이런 직접 연결을 통해서 클라우드에 있는 센트리노드를 연결할 수 있습니다. 이런 형태의 아키텍처는 DDoS 공격의 부담을 검증 노드에서 센트리 노드로 우회합니다. 공격 상황에서 새로운 센트리노드를 생성하는 것은 다소 쉽기 때문에 공격의 위험성을 줄일 수 있습니다.
|
||||
|
||||
센트리노드는 새로 생성되거나 IP 주소를 변경할 수 있습니다. 센트리노드와 검증노드 간의 연결은 프라이빗 IP를 통해서 이루어지기 떄문에 공격자는 직접적으로 공격을 할 수 없습니다. 이는 검증 노드가 언제나 블록 제안과 블록 투표에 참여할 수 있게 합니다.
|
||||
|
||||
올바른 운영과 아키텍쳐를 이용하는 검증이는 이런 공격 가능성을 막을 수 있을 것으로 기대됩니다.
|
||||
|
||||
센트리노드에 대한 추가적인 정보는 [여기](https://forum.cosmos.network/t/sentry-node-architecture-overview/454)에서 확인 가능합니다.
|
||||
|
|
@ -0,0 +1,264 @@
|
|||
# 퍼블릭 테스트넷에서 밸리데이터 운영하기
|
||||
|
||||
::: tip
|
||||
현재 테스트넷을 참가하는 방법은 [`testnet` repo](https://github.com/cosmos/testnets/tree/master/latest)에 있습니다. 최신 테스트넷에 대한 정보를 확인하시려면 해당 링크를 확인해주세요.
|
||||
:::
|
||||
|
||||
__Note__: 이 문서는 **퍼블릭 테스트넷** 검증인들을 위해서만 작성되었습니다.
|
||||
|
||||
밸리데이터 노드를 세팅하기 전, [풀노드 세팅](../join-testnet.md) 가이드를 먼저 확인해주세요.
|
||||
|
||||
## 밸리데이터란 무엇인가?
|
||||
|
||||
[밸리데이터](./overview.md)는 블록체인의 투표를 통해서 새로운 블록은 생성하는 역할을 합니다. 만약 특정 밸리데이터가 오프라인이 되거나, 같은 블록높이에서 중복 사이닝을 한 경우 해당 밸리데이터의 지분은 삭감(슬래싱, slashing) 됩니다. 노드를 DDOS 공격에서 보호하고 높은 접근성을 유지하기 위해서는 [센트리노드 아키텍쳐](./validator-faq.md#how-can-validators-protect-themselves-from-denial-of-service-attacks)에 대해서 읽어보세요.
|
||||
|
||||
|
||||
::: danger 경고
|
||||
코스모스 허브의 검증인이 되는 것을 검토하신다면, [보안에 대한 분석](./security.md)을 사전에 하시기를 바랍니다.
|
||||
:::
|
||||
|
||||
만약 [풀노드](../join-testnet.md)를 이미 운영중이시다면, 다음 항목을 건너뛰셔도 좋습니다.
|
||||
|
||||
## 밸리데이터 생성하기
|
||||
|
||||
토큰 스테이킹을 통해 `cosmosvalconspub`로 새로운 밸리데이터를 생성할 수 있습니다. 본인의 밸리데이터 pubkey를 확인하기 위해서는 다음 명령어를 입력하세요:
|
||||
|
||||
|
||||
```bash
|
||||
gaiad tendermint show-validator
|
||||
```
|
||||
|
||||
다음은 `gaiad gentx` 명령을 입력하세요:
|
||||
|
||||
::: warning 참고
|
||||
보유하고 있는 `STAKE`이상을 이용하지 마십시오. 언제나 [Faucet](https://faucet.cosmos.network/)을 통해서 추가 `STAKE`를 받으실 수 있습니다.
|
||||
:::
|
||||
|
||||
```bash
|
||||
gaiacli tx staking create-validator \
|
||||
--amount=5STAKE \
|
||||
--pubkey=$(gaiad tendermint show-validator) \
|
||||
--moniker="choose a moniker" \
|
||||
--chain-id=<chain_id> \
|
||||
--from=<key_name> \
|
||||
--commission-rate="0.10" \
|
||||
--commission-max-rate="0.20" \
|
||||
--commission-max-change-rate="0.01"
|
||||
```
|
||||
|
||||
__참고__: 커미션 값을 설정하실 때, `commission-max-change-rate`는 기존 `commission-rate`에서의 *퍼센트 포인트* 변경을 기준으로 측정됩니다. 예) 커미션이 1%에서 2%로 변경되는 것은 100% 상승되는 것이지만, 1%p 변경.
|
||||
|
||||
__참고__: `consensus_pubkey` 값이 지정되지 않은 경우, 기본적으로 `gaiad tendermint show-validator` 의 값으로 설정됩니다. `key_name`은 트랙잭션을 서명할때 이용되는 프라이빗키의 명칭입니다.
|
||||
|
||||
## 밸리데이터로써 제네시스 참가하기
|
||||
|
||||
__참고__: 이 문항은 제네시스 파일에 참가하려는 밸리데이터에게만 해당됩니다. 만약 검증을 하려는 체인이 이미 작동되고 있는 상태라면 이 항목을 건너뛰셔도 좋습니다.
|
||||
|
||||
|
||||
밸리데이터로써 제네시스에 참가하고 싶으시다면 우선 본인(또는 위임자)가 stake를 보유하고 있다는 것을 증명해야 합니다. 스테이크를 검증인에게 본딩하는 하나 이상의 트랜잭션을 발생하신 후, 해당 트랜잭션을 제네시스 파일에 추가하시기 바랍니다.
|
||||
|
||||
우선 두가지의 케이스가 존재합니다:
|
||||
|
||||
- 경우 1: 본인 밸리데이터의 stake를 본딩(위임)한다.
|
||||
- 경우 2: 타인(위임자)의 stake를 본딩한다.
|
||||
|
||||
### Case 1: 최초 위임이 밸리데이터 본인 주소에서 발생하는 경우
|
||||
|
||||
이런 경우에는 `gentx`를 생성하셔야 합니다:
|
||||
|
||||
```bash
|
||||
gaiad gentx \
|
||||
--amount <amount_of_delegation> \
|
||||
--commission-rate <commission_rate> \
|
||||
--commission-max-rate <commission_max_rate> \
|
||||
--commission-max-change-rate <commission_max_change_rate> \
|
||||
--pubkey <consensus_pubkey> \
|
||||
--name <key_name>
|
||||
```
|
||||
|
||||
__참고__: 이 명령어는 제네시스에서의 처리를 위해 `gentx`를 `~/.gaiad/config/gentx`에 저장합니다.
|
||||
|
||||
::: tip
|
||||
명령어 플래그에 대한 정보는 `gaiad gentx --help`를 사용에 확인하십시오.
|
||||
:::
|
||||
|
||||
`gentx`는 자체위임 정보가 포함된 JSON 파일입니다. 모든 제네시스 트랜잭셕은 `genesis coordinator`에 의하여 모아진 후 최초 `genesis.json`파일과 대치하여 검증합니다. 최초 `genesis.json`에는 계정 리스트와 각 계정이 보유하고 있는 코인 정보가 포함되어있습니다. 트랜잭션이 처리되었다면 해당 정보는 `genesis.json`의 `gentx` 항목에 머지(merge)됩니다.
|
||||
|
||||
### Case 2: 최초 위임이 위임자(delegator) 주소에서 발생하는 경우
|
||||
|
||||
이런 경우에는 위임자와 검증인의 서명이 둘다 필요합니다. 우선 서명이 되지 않은 `create-validator` 트랜잭션을 생성하신 후 `unsignedValTx`라는 파일에 저장하십시오:
|
||||
|
||||
```bash
|
||||
gaiacli tx staking create-validator \
|
||||
--amount=5STAKE \
|
||||
--pubkey=$(gaiad tendermint show-validator) \
|
||||
--moniker="choose a moniker" \
|
||||
--chain-id=<chain_id> \
|
||||
--from=<key_name> \
|
||||
--commission-rate="0.10" \
|
||||
--commission-max-rate="0.20" \
|
||||
--commission-max-change-rate="0.01" \
|
||||
--address-delegator="address of the delegator" \
|
||||
--generate-only \
|
||||
> unsignedValTx.json
|
||||
```
|
||||
|
||||
이제 해당 `unsignedValTx`를 밸리데이터의 프라이빗 키를 이용해 서명합니다. 서명이된 아웃풋을 `signedValTx.json`이라는 파일에 저장합니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx sign unsignedValTx.json --from=<validator_key_name> > signedValTx.json
|
||||
```
|
||||
|
||||
이제 이 파일을 위임자에게 전달하세요. 위임인은 다음 명령어를 실행하면 됩니다:
|
||||
|
||||
```bash
|
||||
gaiacli tx sign signedValTx.json --from=<delegator_key_name> > gentx.json
|
||||
```
|
||||
|
||||
이 파일은 제네시스 절차에서 필요하기 때문에 Case 1과 동일하게 `gentx.json`은 밸리데이터 머신의 `~/.gaiad/config/gentx` 폴더에 포함되어야 합니다 (Case 2 에서는 직접 해당 파을을 이동해야 합니다).
|
||||
|
||||
|
||||
### 제네시스 파일 복사, 제네시스 트랜잭션 처리하기
|
||||
|
||||
우선 `genesis.json`파일을 `gaiad`의 config 디렉토리로 가져옵니다.
|
||||
|
||||
Fetch the `genesis.json` file into `gaiad`'s config directory.
|
||||
|
||||
```bash
|
||||
mkdir -p $HOME/.gaiad/config
|
||||
curl https://raw.githubusercontent.com/cosmos/testnets/master/latest/genesis.json > $HOME/.gaiad/config/genesis.json
|
||||
```
|
||||
|
||||
__참고:__ 이 항목에서는 최신 테스트넷 관련 정보가 있는 [테스트넷 repo](https://github.com/cosmos/testnets)의 `latest` 디렉토리를 사용합니다. 만약 다른 테스트넷에 연결하신다면 이용하시는 파일을 확인하시기 바랍니다.
|
||||
|
||||
이제 다른 제네시스 밸리데이터들의 제네시스 트랜잭션을 가져옵니다. 현재 밸리데이터들이 본인들의 제네시스 트랜잭션을 제공할 수 있는 리포지토리가 없는 상태이나, 추후 테스트넷에서 검증 후 추가될 예정입니다.
|
||||
|
||||
모든 제네시스 트랜잭션을 받으시고 `~/.gaiad/config/gentx`에 저장하셨다면 다음 명령어를 실행하십시오:
|
||||
|
||||
```bash
|
||||
gaiad collect-gentxs
|
||||
```
|
||||
|
||||
__참고:__ `gentx`에서 위임을 하는 계정에 스테이크(stake) 토큰이 있는 것을 확인하세요. 만약 해당 계정에 토큰이 없다면 `collect-gentx`가 실패하게 됩니다.
|
||||
|
||||
이전에 실행하신 명령어는 모든 제네시스 트랜잭션을 모으고 `genesis.json`을 파이널라이즈(finalize)합니다. 설정이 올바르게 되었는지 확인하기 위해서는 노드를 시작하십시오:
|
||||
|
||||
```bash
|
||||
gaiad start
|
||||
```
|
||||
|
||||
## 검증인 설명 수정하기
|
||||
|
||||
검증인의 공개 설명 문구와 정보는 수정이 가능합니다. 이 정보는 위임자들이 어떤 검증인에게 위임을 할지 결정할때 이용될 수 있습니다. 각 플래그에 대해서 정보를 꼭 입력하시기 바랍니다. 만약 비어있는 항목이 있다면 해당 값은 빈 상태로 유지됩니다 (`--moniker`의 경우 머신 이름 값이 사용됩니다).
|
||||
|
||||
`--identity` 값은 Keybase 또는 UPort 같은 시스템을 이용해서 신분(identity)를 검증하는데 이용될 수 있습니다. Keybase를 사용하시는 경우 `--identity`는 [keybase.io](https://keybase.io) 계정으로 생성하신 16자리 string 값이 입력되어야 합니다. 이런 절차는 다수의 온라인 네트워크에서 본인의 신분을 증명하는데 이용될 수 있습니다. 또한 Keybase API를 이용해서 Keybase 아바타를 가져와 밸리데이터 프로파일에 이용하실 수 있습니다.
|
||||
|
||||
```bash
|
||||
gaiacli tx staking edit-validator
|
||||
--moniker="choose a moniker" \
|
||||
--website="https://cosmos.network" \
|
||||
--identity=6A0D65E29A4CBC8E \
|
||||
--details="To infinity and beyond!" \
|
||||
--chain-id=<chain_id> \
|
||||
--from=<key_name> \
|
||||
--commission-rate="0.10"
|
||||
```
|
||||
|
||||
__참고__: `commission-rate` 값은 다음의 규칙을 따라야 합니다:
|
||||
|
||||
- 0 과 `commission-max-rate` 값의 사이
|
||||
- 검증인의 `commission-max-change-rate` 값을 초과할 수 없습니다. `commission-max-change-rate`는 하루에 최대 커미션 값을 변경할 수 있는 한도입니다. 밸리데이터는 하루에 한번 `commission-max-change-rate`의 한도 안에서만 커미션을 변경할 수 있습니다.
|
||||
|
||||
## 밸리데이터 설명 확인하기
|
||||
|
||||
검증인의 정보는 다음 명령어로 확인이 가능합니다:
|
||||
|
||||
```bash
|
||||
gaiacli query staking validator <account_cosmos>
|
||||
```
|
||||
|
||||
## 밸리데이터 서명 정보 추적하기
|
||||
|
||||
특정 검증인의 과거 서명 정보를 확인하기 위해서는 `signing-info` 명령어를 이용하실 수 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli query slashing signing-info <validator-pubkey>\
|
||||
--chain-id=<chain_id>
|
||||
```
|
||||
|
||||
## 밸리데이터 석방(Unjail)하기
|
||||
|
||||
특정 검증인이 과도한 다운타임으로 '구속(jailed)' 상태로 전환되면 운영자의 계정에서 '석방(unjail)' 요청 트랜잭션을 전송해야만 다시 블록 생성 리워드를 받을 수 있습니다(각 존의 리워드 분배 정책에 따라 다를 수 있음).
|
||||
|
||||
```bash
|
||||
gaiacli tx slashing unjail \
|
||||
--from=<key_name> \
|
||||
--chain-id=<chain_id>
|
||||
```
|
||||
|
||||
## 밸리데이터 작동상태 확인
|
||||
|
||||
다음 명령어가 반응을 준다면 당신의 밸리데이터는 작동하고 있습니다:
|
||||
|
||||
```bash
|
||||
gaiacli query tendermint-validator-set | grep "$(gaiad tendermint show-validator)"
|
||||
```
|
||||
|
||||
코스모스 테스트넷의 경우 코스모스 [익스플로러](https://explorecosmos.network/validators)를 통해서 밸리데이터가 운영되고 있는지 확인하실 수 있습니다. `~/.gaiad/config/priv_validator.json` 파일의 `bech32` 인코딩이된 `address` 항목을 참고하세요.
|
||||
|
||||
::: warning 참고
|
||||
검증인 세트에 포함되시기 원하신다면 100등 밸리데이터보다 보팅 파워(voting power)가 높아야 합니다.
|
||||
:::
|
||||
|
||||
## 흔히 발생하는 문제들
|
||||
|
||||
### 문제 #1: 내 검증인의 보팅 파워가 0 입니다
|
||||
|
||||
밸리데이터가 자동 언본딩 되었습니다. `gaia-8000`의 경우, 100개 블록 중 50개의 블록에 투표하지 않을 경우 언본딩 됩니다. 블록은 대략 ~2초 마다 생성되기 때문에 ~100초 이상 비활성화 상태를 유지하는 밸리데이터는 언본딩 될 수 있습니다. 가장 흔한 이유는 `gaiad` 프로세스가 멈춘 경우입니다.
|
||||
|
||||
보팅 파워를 다시 밸리데이터에게 되돌리기 위해서, 우선 `gaiad`가 실행되고 있는지 확인하십시오. 만약 실행되고 있지 않은 경우 다음 명령어를 실행하십시오:
|
||||
|
||||
```bash
|
||||
gaiad start
|
||||
```
|
||||
|
||||
당신의 풀노드가 최신 블록높이에 싱크될때까지 기다리십시오. 이후, 다음 명령어를 실행하십시오. 참고로 `<cosmos>` 항목은 밸리데이터 계정의 주소이며, `<name>`은 밸리데이터 계정의 이름입니다. 해당 정보는 `gaiacli keys list` 명령어를 통해 확인하실 수 있습니다.
|
||||
|
||||
```bash
|
||||
gaiacli tx slashing unjail <cosmos> --chain-id=<chain_id> --from=<from>
|
||||
```
|
||||
|
||||
::: danger 경고
|
||||
`gaiad`가 싱크되지 않은 상태에서 `unjail` 명령을 실행하실 경우, 검증인이 아직 '구속' 상태라는 메시지를 받게 됩니다.
|
||||
:::
|
||||
|
||||
마지막으로 밸리데이터의 보팅파워가 복구 되었는지 확인하십시오.
|
||||
|
||||
```bash
|
||||
gaiacli status
|
||||
```
|
||||
|
||||
만약 보팅 파워가 예전보다 감소되었다면 다운타임에 대한 슬래싱이 이유일 수 있습니다.
|
||||
|
||||
### 문제 #2: `too many open files`때문에 `gaiad`가 강제 종료됩니다
|
||||
|
||||
리눅스가 각 프로세스당 열 수 있는는 파일 수는 최대 `1024`개입니다. `gaiad`는 1024개 이상의 열게될 수 있음으로 프로세스가 중단될 수 있습니다. 가장 간편한 해결책은 `ulimit -n 4096` (열 수 있는 최대 파일 수)명령어를 입력하고 프로세스를 `gaiad start`로 재시작하는 것입니다. 만약 `systemd` 또는 다른 프로세스 매니저로 `gaiad`를 실행하신다면 해당 레벨에서 몇가지 설정을 해야합니다. 문제 해결 샘플 `systemd` 파일은 다음과 같습니다:
|
||||
|
||||
```toml
|
||||
# /etc/systemd/system/gaiad.service
|
||||
[Unit]
|
||||
Description=Cosmos Gaia Node
|
||||
After=network.target
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
User=ubuntu
|
||||
WorkingDirectory=/home/ubuntu
|
||||
ExecStart=/home/ubuntu/go/bin/gaiad start
|
||||
Restart=on-failure
|
||||
RestartSec=3
|
||||
LimitNOFILE=4096
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
# Gaia는 무엇인가요?
|
||||
|
||||
가이아(`gaia`)는 코스모스 허브의 코스모스 SDK 애플리케이션의 이름입니다. 가이아는 두개의 엔트리 포인트로 구성돼있습니다:
|
||||
|
||||
- `gaiad`: 가이아 데몬, `gaia` 애플리케이션의 풀노드를 운영합니다.
|
||||
- `gaiacli`: 가이아 커맨드 라인 인터페이스는 유저가 가이아 풀노드와 소통할 수 있게 합니다.
|
||||
|
||||
`gaia`는 코스모스 SDK의 다음 모듈들을 이용해 제작되었습니다:
|
||||
|
||||
- `x/auth`: 계정 및 서명
|
||||
- `x/bank`: 토큰 전송
|
||||
- `x/staking`: 스테이킹 로직
|
||||
- `x/mint`: 인플레이션 로직
|
||||
- `x/distribution`: 수수료(보상) 분배 로직(fee distribution logic)
|
||||
- `x/slashing`: 슬래싱 로직
|
||||
- `x/gov`: 거버넌스 로직
|
||||
- `x/ibc`: 인터블록체인 전송
|
||||
- `x/params`: 앱레벨 파라미터 관리
|
||||
|
||||
|
||||
|
||||
>코스모스 허브에 대해서: 코스모스 허브는 코스모스 네트워크의 최초 허브입니다. 허브는 블록체인 간 전송을 수행하는 역할을 합니다. IBC를 통해 특정 허브에 연결된 블록체인은 해당 허브에 연결되어있는 모든 블록체인과 함께 연결됩니다. 코스모스 허브는 지분증명 기반 퍼블릭 블록체인이며, 고유 토큰은 아톰(Atom)입니다. 다음은 Gaia를 [설치하는 방법](./installation.md)을 알아보겠습니다.
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
# SDK 소개
|
||||
|
||||
|
||||
|
||||
[Cosmos-SDK](https://github.com/cosmos/cosmos-sdk)는 코스모스 허브 같은 멀티애셋 지분증명(Proof-of-Stake) 블록체인 또는 권한증명(Proof-of-Authority) 같은 블록체인들을 만들 수 있는 하나의 프레임워크입니다.
|
||||
|
||||
코스모스 SDK의 목표는 개발자들이 본인만의 커스텀 블록체인을 처음부터 쉽게 만들고, 이런 블록체인들이 상호호환성을 가질 수 있게 하는 것입니다. 우리는 코스모스 SDK가 [Tendermint](https://github.com/tendermint/tendermint) 기반의 안전한 블록체인 애플리케이션의 npm 프레임워크 같은 역할을 할수 있을 것을 기대하고 있습니다.
|
||||
|
||||
코스모스 SDK는 다음과 같은 원칙에 의거합니다:
|
||||
|
||||
- **구성성:** 누구나 코스모스-SDK 모듈을 만들 수 있다. 또한 이미 만들어진 기존 모듈을 내가 만드려는 블록체인 애플리케이션에 손쉽게 도입할 수 있다.
|
||||
|
||||
- **능력성:** 코스모스-SDK는 능력기반 보안(capabilities-based security)과 수년의 블록체인 스테이트 머신에 대한 고민을 기반으로 만들어졌습니다. 대다수의 개발자들은 본인들의 모듈을 개발할때 제3자의 모듈을 사용해야되는 경우가 많습니다. 코스모스-SDK는 오픈 프레임워크이기 때문에, 일부 악의적인 모듈이 존재할 수 있다는 것을 배제할 수 없습니다. 이런 환경에서는 보안과 안전성을 확보하기 위해 모듈간 인터랙션에서 기본적인 보안 원칙이 존재해야 합니다. 이런 원칙은 오브젝트-능력(object-capabilities) 기반으로 만들어졌습니다. 각 모듈이 다른 모든 모듈들의 액세스 권한 리스트를 관리하기 보다, 각 모듈은 키퍼(Keeper)라는 특수 오브젝트를 도입할 수 있습니다. 이런 '키퍼' 들은 다른 모듈에게 전달되어 사전에 정의된 능력(기능)을 수행할 수 있는 권한을 부여합니다. 예를 들어, 모듈 A의 키퍼가 모듈 B에게 전달되었을 경우, 모듈 B는 사전에 정의되어있는 한정된 모듈 A의 기능을 호출할 수 있습니다. 각 키퍼가 수행할 수 있는 기능은 해당 모듈의 개발자가 정의할 수 있으며, 모듈 기능으로 발생할 수 있는 안전/보안 문제를 감사하는 책임은 각 개발자에게 있습니다. 능력(capability)에 대한 더 자세한 설명은 다음 [링크](./ocap.md)에서 확인하실 수 있습니다.
|
||||
|
||||
### 다음은 [SDK 애플리케이션 아키텍쳐](./sdk-app-architecture.md)에 대해서 알아보겠습니다
|
||||
|
|
@ -0,0 +1,68 @@
|
|||
# 오브젝트-가능성 모델(Object-Capability Model)
|
||||
|
||||
## 개요
|
||||
|
||||
보안을 검토하기 위해서는 특정 위협 모델(threat model)을 검토하는 것으로 시작하는 것이 좋습니다. 우리가 제시하는 모델은 다음과 같습니다:
|
||||
|
||||
> 코스모스-SDK 모듈을 기반으로 만들어진 블록체인 애플리케이션이 활성화된 생태계에는 허점이 있거나 악의적인 모듈이 존재할 수 있다고 전재합니다.
|
||||
|
||||
코스모스 SDK는 오브젝트-가능성 시스템의 토대가 됨으로 이런 문제점을 해결할 수 있습니다.
|
||||
|
||||
> 오브젝트 가능성 시스템의 구조적 속성은 코드 디자인의 모듈화와 안정적인 캡슐화(encapsulation)를 선호합니다.
|
||||
>
|
||||
> 이런 구조적 속성은 오브젝트-가능 프로그램 또는 운영체제의 보안적 속성의 분석을 가능하게 합니다. 정보 플로우 속성(information flow properties) 같은 일부 속성은 특정 오브젝트의 행동을 결정하는 코드의 지식 또는 분석 없이도 오직 오브젝트 레퍼런스와 연결구조만으로 분석이 가능합니다.
|
||||
>
|
||||
> 그렇기 때문에, 악의적인 코드가 포함되있을 확률이 있는 새로운 오브젝트가 소개되더라도 보안적 속성은 지켜질 수 있습니다.
|
||||
>
|
||||
> 이런 구조적 속성은 해당 오브젝트를 통치하는 두가지 법칙에 의해 지켜질 수 있습니다:
|
||||
> 1. 오브젝트 'A'는 'B'에 대한 레퍼런스를 보유하고 있을 경우에만 메시지를 전송할 수 있다.
|
||||
> 2. 오브젝트 'A'가 'C'에 대한 레퍼런스를 가지고 싶다면 오브젝트 'A'는 'C'에 대한 레퍼런스가 포함된 메시지를 수신해야 한다.
|
||||
>
|
||||
> 이 두 법칙에 따르면 특정 오브젝트는 기존에 존재하는 레퍼런스 체인을 통해서만 다른 오브젝트에 대한 레퍼런스를 받을 수 있는 것입니다. 단순하게 설명하면 "연결성이 연결성을 불러온다"는 것입니다.
|
||||
|
||||
오브젝트 가능성에 대한 소개는 [이 글(영문)](http://habitatchronicles.com/2017/05/what-are-capabilities/)을 참고하세요.
|
||||
|
||||
원칙적으로 말하면, 다음과 같은 문제점 때문에 Golang은 엄격한 오브젝트 가능성을 도입하지 않는다고 볼 수 있습니다:
|
||||
|
||||
- 보편적으로 "unsafe" 또는 "os" 같은 원시적 모듈(primitive module)을 임포트할 수 있음.
|
||||
- 보편적으로 [모듈 vars 오버라이드(https://github.com/golang/go/issues/23161)]가 가능.
|
||||
- 2개 이상의 goroutine이 illegal interface value를 만들 수 있는 data-race 허점.
|
||||
|
||||
문제점 중 첫번째 문제는 임포트 감사(import audit)과 체계적인 디펜던시 버전 컨트롤 시스템(dependency version control system)을 이용하여 문제점을 사전에 찾을 수 있습니다. 다만, 두번째와 세번째 문제는 다서 불편하기는 하지만 노력을 통해서 감사(audit)가 가능합니다.
|
||||
|
||||
현재로써는 [Go2에서 오브젝트 가능성 모델이 도입되는](https://github.com/golang/go/issues/23157)것을 기대하는 상태입니다.
|
||||
|
||||
## 실전에서의 오브젝트 가능성 모델(Ocaps)
|
||||
|
||||
Ocaps의 핵심 아이디어는 특정 일을 수행하는데 필요한 정보만을 공개하는 것입니다.
|
||||
|
||||
예를 들어, 다음의 코드는 오브젝트 가능성 원칙을 위해합니다:
|
||||
|
||||
```go
|
||||
type AppAccount struct {...}
|
||||
var account := &AppAccount{
|
||||
Address: pub.Address(),
|
||||
Coins: sdk.Coins{sdk.NewInt64Coin("ATM", 100)},
|
||||
}
|
||||
var sumValue := externalModule.ComputeSumValue(account)
|
||||
```
|
||||
|
||||
위 코드의 `ComputeSumValue` 메소드는 순수한(pure) 함수를 암시하지만, 포인터 밸류를 받아드리는 것의 암시된 가능성(implied capability)은 해당 밸류를 변경할 수 있는 가능성입니다. 서명 메소드는 그대로 포인터 밸류를 받아들이지 않고 해당 밸류의 사본을 사용하는 것이 바람직합니다.
|
||||
|
||||
```go
|
||||
var sumValue := externalModule.ComputeSumValue(*account)
|
||||
```
|
||||
|
||||
코스모스 SDK에서 이 원칙을 응용한 것을 [gaia 앱](../gaia/app/app.go)에서 확인이 가능합니다.
|
||||
|
||||
```go
|
||||
// register message routes
|
||||
app.Router().
|
||||
AddRoute(bank.RouterKey, bank.NewHandler(app.bankKeeper)).
|
||||
AddRoute(staking.RouterKey, staking.NewHandler(app.stakingKeeper)).
|
||||
AddRoute(distr.RouterKey, distr.NewHandler(app.distrKeeper)).
|
||||
AddRoute(slashing.RouterKey, slashing.NewHandler(app.slashingKeeper)).
|
||||
AddRoute(gov.RouterKey, gov.NewHandler(app.govKeeper))
|
||||
```
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
# SDK 애플리케이션 아키텍쳐
|
||||
|
||||
## 스테이트 머신 (상태 기계, State machine)
|
||||
|
||||
블록체인 애플리케이션은 근본적으로 [결정론적 복제 상태 기계(replicated deterministic state machine)](https://ko.wikipedia.org/wiki/%EC%83%81%ED%83%9C_%EA%B8%B0%EA%B3%84_%EB%B3%B5%EC%A0%9C)입니다.
|
||||
|
||||
스테이트 머신은 특정 기계(머신, machine)이 오랜 기간동안 다수의 상태(스테이트, state)를 보유할 수 있지만, 특정 시점에 오직 하나의 상태를 유지하는 있는 컴퓨터 공학 개념입니다. 여기서 '스테이트 머신' 개념에는 시스템의 현 상태를 뜻하는 '스테이트(state)'가 있으며, 스테이트의 변경을 유발하는
|
||||
트랜잭션(transaction)'이 있습니다.
|
||||
|
||||
`S` 라는 스테이트와 `T` 라는 트랜잭션이 있는 경우, 스테이트 머신은 `S'`라는 새로운 스테이트를 리턴합니다.
|
||||
|
||||
```
|
||||
+--------+ +--------+
|
||||
| | | |
|
||||
| S +---------------->+ S' |
|
||||
| | apply(T) | |
|
||||
+--------+ +--------+
|
||||
```
|
||||
|
||||
실전에서는 트랜잭션들이 일종의 '블록' 단위로 묶여 스테이트 변경 과정을 더 효율적일 수 있게 합니다. `S`라는 스테이트와 `B`라는 트랜잭션들이 있는 경우, 스테이트 머신은 `S'`라는 새로운 스테이트를 리턴합니다.
|
||||
|
||||
```
|
||||
+--------+ +--------+
|
||||
| | | |
|
||||
| S +----------------------------> | S' |
|
||||
| | For each T in B: apply(T) | |
|
||||
+--------+ +--------+
|
||||
```
|
||||
|
||||
블록체인이라는 시스템 내의 개념으로 볼때 스테이트 머신은 결정론적(deterministic)입니다. 즉, 특정 스테이트에서 시작한 후 동일한 트랜잭션들을 반복할 경우, 결과 스테이트는 언제나 동일합니다.
|
||||
|
||||
코스모스 SDK는 애플리케이션의 스테이트, 트랜잭션 형태 그리고 스테이트 변경 기능(state-transition function)을 정의하는데 최대한의 유연성을 제공합니다. 코스모스 SDK를 이용해 스테이트 머신을 만드는 과정은 이후 항목에서 다루겠습니다. 우선 이 시스템 내에서 어떻게 **텐더민트**를 사용해 '스테이트'가 복제되는지 알아보겠습니다.
|
||||
|
||||
## 텐더민트
|
||||
|
||||
개발자는 코스모스 SDK를 사용하여 스테이트 머신만을 정의하면 되며, 해당 스테이트를 네트워크에 복제하는 기능은 [*텐더민트*](https://tendermint.com/docs/introduction/introduction.html)가 제공합니다.
|
||||
|
||||
|
||||
```
|
||||
^ +-------------------------------+ ^
|
||||
| | | | 코스모스 SDK로 개발
|
||||
| | 스테이트 머신 = 애플리케이션 | |
|
||||
| | | v
|
||||
| +-------------------------------+
|
||||
| | | ^
|
||||
블록체인 노드 | | 컨센서스 | |
|
||||
| | | |
|
||||
| +-------------------------------+ | 텐더민트 코어
|
||||
| | | |
|
||||
| | 네트워킹 | |
|
||||
| | | |
|
||||
v +-------------------------------+ v
|
||||
```
|
||||
|
||||
텐더민트는 오직 블록체인의 *네트워킹*과 *합의(컨센서스)* 계층을 처리하는 애플리케이션-불가지성(application-agnostic) 엔진입니다. 실전적으로 볼때, 텐더민트는 단순히 트랜잭션의 바이트를 나열하고, 해당 트랜잭션을 네트워크에 전파하는 역할만을 한다는 것입니다. 텐더민트 코어는 텐더민트 비잔틴 결함 감내(BFT, Byzantine-fault tolerant) 알고리즘을 사용하여 트랜잭션 순서에 대한 합의를 합니다. 텐더민트에 대해서 더 알고싶으시다면 [여기](https://tendermint.com/docs/introduction/introduction.html)를 확인하세요.
|
||||
|
||||
텐더민트 합의 알고리즘은 '검증인(Validators)'이라는 특정 노드 세트를 기반으로 작동합니다. 검증인의 주 역할은 트랜잭션을 블록 단위로 블록체인에 추가하는 것입니다. 특정 블록에는 V 검증인 세트 검증인 존재하며, 이 V 검증인 세트 안에 있는 검증인 중 하나의 검증인이 다음 블록 생성자로 알고리즘에 의해 선택됩니다. 만약 블록이 V 검증인 세트 2/3 이상의 [프리보트(prevote)](https://tendermint.com/docs/spec/consensus/consensus.html#prevote-step-height-h-round-r)와 [프리커밋(precommit)](https://tendermint.com/docs/spec/consensus/consensus.html#precommit-step-height-h-round-r)을 받고 내용 트랜잭션이 유효한 경우 해당 블록은 '유효(valid)'한 것으로 간주됩니다. 검증인 세트는 스테이트 머신에 작성된 규칙에 따라서 바뀔 수 있습니다. 알고리즘에 대해 더 자세한 정보는 [여기](https://tendermint.com/docs/introduction/what-is-tendermint.html#consensus-overview)를 참고하세요.
|
||||
|
||||
코스모스 SDK 애플리케이션의 주요 파트는 네트워크에 포함되어있는 노드가 각자 로컬 환경에서 운영하는 블록체인 데몬(daemon)입니다. 만약 *검증인 세트*의 1/3 이하가 악의적(byzantine)인 경우, 각 노드는 동시에 스테이트를 조회할때 동일한 결과를 받게됩니다.
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Cosmos SDK Documentation Translation (Korean)
|
||||
|
||||
This document tracks the progress of the Korean translation of the official Cosmos SDK documentation.
|
||||
|
||||
Documentation has been translated for **reference use only** and may contain typos, factual errors and be out-of-date with the latest english documentation.
|
||||
|
||||
Please refer to the official english version of the documentation for the latest and accurate information.
|
||||
|
||||
|
||||
## 코스모스 SDK 도큐멘테이션 번역 (한국어)
|
||||
|
||||
이 문서는 코스모스 공식 문서의 번역 작업 트래킹을 위한 문서입니다.
|
||||
|
||||
번역된 문서는 **참고용**으로 번역되었습니다. 다수의 오타, 오류가 존재할 수 있으며, 영문 업데이트보다 번역이 느리게 진행될 수 있다는 점을 인지하시기 바랍니다.
|
||||
|
||||
코스모스 관련 가장 정확한 정보를 확인하시기 위해서는 영어 원문을 참고하시기 바랍니다.
|
||||
|
||||
|
||||
## Progress by directory
|
||||
|
||||
|
||||
### [`concepts`](../concepts/)
|
||||
- Synced until commit [14ebc65](https://github.com/cosmos/cosmos-sdk/commit/14ebc65daffd63e1adf17995c103aac9380207ef#diff-f874f370376bf359320af0543de53fcf)
|
||||
|
||||
### [`spec`](../spec/)
|
||||
- Redacted from until completion
|
||||
|
||||
### [`gaia`](../gaia/)
|
||||
- Synced until commit [288df6f](https://github.com/cosmos/cosmos-sdk/commit/288df6fe69dcef8fa95aca022039f92ba1e98c11#diff-3302fe357e01f0996ddb0f10adec85f0)
|
||||
|
||||
### [`intro`](../intro/)
|
||||
- Synced until commit [0043912](https://github.com/cosmos/cosmos-sdk/commit/0043912548808b4cfd6ab84ec49ba73bd5f65b5b#diff-e518eaec0d99787e6f75682d54751821)
|
||||
|
||||
### [`modules`](../modules/)
|
||||
- Synced until commit [78a2135](https://github.com/cosmos/cosmos-sdk/commit/78a21353da978d6c2a9b711f29b3874ff9ca14ae#diff-449cc65858e8929d15f4a170950e7758)
|
||||
|
||||
### [`clients`](../clients/)
|
||||
- Synced until Commit [857a65d](https://github.com/cosmos/cosmos-sdk/commit/857a65dc610cd736a47980b5d4778e5123206a3d#diff-93dd988c16d20a1bce170b86ad89425a)
|
||||
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
# Bank
|
||||
|
||||
`x/bank` 모듈은 계정 간 코인을 이동할때 사용됩니다.
|
||||
|
||||
[API 문서](https://godoc.org/github.com/cosmos/cosmos-sdk/x/bank)를 확인하세요.
|
||||
|
||||
# Stake
|
||||
|
||||
`x/staking` 모듈은 코스모스 위임형 지분증명(Delegated-Proof-of-Stake) 시스템에서 사용됩니다.
|
||||
|
||||
[API 문서](https://godoc.org/github.com/cosmos/cosmos-sdk/x/staking)를 확인하세요.
|
||||
|
||||
관련 스펙은 [여기](https://github.com/cosmos/cosmos-sdk/tree/develop/docs/spec/staking)에서 확인하실 수 있습니다.
|
||||
|
||||
|
||||
# Slashing
|
||||
|
||||
`x/slashing` 모듈은 코스모스 위임형 지분증명(Delegated-Proof-of-Stake) 시스템에서 사용됩니다.
|
||||
|
||||
[API 문서](https://godoc.org/github.com/cosmos/cosmos-sdk/x/slashing)를 확인하세요.
|
||||
|
||||
관련 스펙은 [여기](https://github.com/cosmos/cosmos-sdk/tree/develop/docs/spec/slashing)에서 확인하실 수 있습니다.
|
||||
|
||||
# Provisions
|
||||
|
||||
`x/provisions` 모듈은 수수료 보상 분배와 스테이킹 인플레이션을 조정할때 사용됩니다.
|
||||
|
||||
[API 문서](https://godoc.org/github.com/cosmos/cosmos-sdk/x/provisions)를 확인하세요.
|
||||
|
||||
관련 스펙은 [여기](https://github.com/cosmos/cosmos-sdk/tree/develop/docs/spec/provisions)에서 확인하실 수 있습니다.
|
||||
|
||||
# Governance
|
||||
|
||||
`x/gov` 모듈은 본딩한 토큰 보유자들이 프로포절을 만들고 투표를 진행할때 사용됩니다.
|
||||
|
||||
[API 문서](https://godoc.org/github.com/cosmos/cosmos-sdk/x/gov)를 확인하세요.
|
||||
|
||||
관렉 스펙은 [여기](https://github.com/cosmos/cosmos-sdk/tree/develop/docs/spec/governance)에서 확인하실 수 있습니다.
|
||||
|
||||
# IBC
|
||||
|
||||
`x/ibc` 모듈은 블록체인간 통신(InterBlockchain Communication)에서 사용됩니다.
|
||||
|
||||
[API 문서를](https://godoc.org/github.com/cosmos/cosmos-sdk/x/ibc) 확인하세요.
|
||||
|
||||
관련 스펙은 [여기](https://github.com/cosmos/cosmos-sdk/tree/develop/docs/spec/ibc)에서 확인하실 수 있습니다.
|
||||
Loading…
Reference in New Issue