97 KiB
97 KiB
코스모스
분산원장 네트워크
저자:
Jae Kwon mailto:jae@tendermint.com
Ethan Buchman mailto:ethan@tendermint.com
For discussions, join our community chat!
번역 및 제작:
한승환, 이승민, 김기현, 윤승완, HJ Kim(금마), 김석현
[toc]]
## 서 론 (Introduction)
오픈 소스 생태계, 탈중앙화 파일 공유, 퍼블릭 암호화폐 등이 연달아 성공하면서 탈중앙화 인터넷 프로토콜들이 사회경제적 인프라를 근본적으로 개선하는데 사용될 수 있다는 것을 알게 되었다. 비트코인[\[1\]](https://bitcoin.org/bitcoin.pdf)(암호화폐)과 제로캐시[\[2\]](http://zerocash-project.org/paper)(프라이버시용 암호화폐) 같은 특화된 블록체인 어플리케이션들이 있었고, Augur(예측 시장)와 TheDAO[\[4\]](https://download.slock.it/public/DAO/WhitePaper.pdf)(투자 클럽) 같은 무수한 분산 애플리케이션들을 가진 이더리움(Ethereum)[\[3\]](https://github.com/ethereum/wiki/wiki/White-Paper) 같은 범용 스마트 컨트랙트 플랫폼들이 있었다.
그러나 지금까지 이런 블록체인들은 엄청난 에너지 비효율, 형편없거나 제한적인 성능, 미성숙한 거버넌스 메커니즘 등을 비롯해 많은 결함들을 경험해왔다. 세그위트(Segregated-Witness)[\[5\]](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)와 비트코인 NG(BitconNG)[\[6\]](https://arxiv.org/pdf/1510.02037v2.pdf) 같은 비트코인 이체 처리량을 확장하기 위한 여러 제안들이 있었지만, 완전 감사가능성(complete auditability)을 희생하지 않는 이상, 여전히 단일한 기계의 용량에 제한을 받는 수직적 스케일링 솔루션이다. 라이트닝 네트워크(Lightning Network)[\[7\]](https://lightning.network/lightning-network-paper-DRAFT-0.5.pdf)는 원장에서 특정한 이체들을 완전히 제외하여 비트코인의 확장성에 도움을 주며, 소액결제와 프라이버시 보호형 지급 플랫폼(privacy preserving payment rails)에 적합하지만, 보다 범용적인 확장에는 적합하지 않을 수 있다.
가장 이상적인 해결책은 다수의 병렬 블록체인들이 각자의 보안 특성을 유지하면서 호환되는 것이다. 하지만 작업증명의 경우, 이것이 불가능은 아니더라도 상당히 어렵다는 것이 증명되었다. 예를 들어, 병합채굴(merged-mining)은 부모체인의 보안을 위해 수행된 작업을 자녀체인에서 재사용하는 것을 허용하지만, 이체들은 여전히 차례대로 각 노드에 의해 검증돼야 하고, 부모체인의 해시파워 대부분이 자녀체인에서도 병합채굴을 하고 있지 않을 경우, 병합 채굴된(merged mined) 블록체인이 공격에 취약해진다. 우리는 [대안 블록체인 네트워크 아키텍처들(alternative blockchain network architectures)](http://vukolic.com/iNetSec_2015.pdf)에 대한 학술적 고찰을 하였고, 그 중 일부에 대해서는 요약과 결점들을 아래의 [관련 연구(Related Work)](https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#related-work)에서 다루었다.
우리는 이 모든 문제들을 해결하는 새로운 블록체인 네트워크 아키텍처인 코스모스(Cosmos)를 제시하고자 한다. 코스모스는 존(zone)이라고 불리는 많은 독립된 블록체인들의 네트워크이다. 존은 텐더민트 코어(Tendermint Core)[\[8\]](https://github.com/tendermint/tendermint/wiki)를 통해 작동하는데, 텐더민트 코어는 일관적이고 안전한 고성능의 [유사](https://blog.cosmos.network/tendermint-vs-pbft-12e9f294c9ab?gi=7d54da26ffe)[PBFT](https://blog.cosmos.network/tendermint-vs-pbft-12e9f294c9ab?gi=c320a745ea23) 합의 엔진을 제공하며, 악의적인 공격자들에게 엄격한 [포크 책임(fork-accountability)](https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#fork-accountability)을 묻는다. 텐더민트 코어의 BFT 합의 알고리즘은 공개형 지분증명 블록체인들의 확장성을 확보하는데 적합하다.
코스모스 상의 첫 번째 존을 코스모스 허브(Cosmos Hub)라고 부른다. 코스모스 허브는 단순한 거버넌스 메커니즘을 통해 네트워크가 적응하고 업그레이드 할 수 있게 하는 ‘다중 자산 지분증명 암호화폐(multi-asset proof-of-stake cryptocurrency)’이다. 그에 더해서, 코스모스 허브는 다른 존들을 연결함으로 확장될 수 있다.
코스모스 네트워크의 허브와 존들은 블록체인 간 통신(IBC: inter-blockchain communication) 프로토콜을 통하여 상호 통신한다. 이 프로토콜은 블록체인들을 위한 일종의 가상 UDP 또는 TCP 역할을 한다. 토큰들은 존들 간 거래소의 유동성(exchange liquidity)없이도 안전하고 신속하게 하나의 존에서 다른 존으로 전송될 수 있다. 존들 간 토큰 전송은 코스모스 허브를 통과하며, 코스모스 허브는 각 존이 보유한 토큰 총액을 추적한다. 허브는 각 존을 다른 존들의 실패(failure)로부터 격리한다. 또한 누구든지 코스모스 허브에 새로운 존을 연결할 수 있기 때문에, 존들은 앞으로의 새로운 블록체인 혁신과의 장래 호환성도 확보한다.
## 텐더민트 (Tendermint)
본 절에서는 텐더민트 합의 프로토콜과 이를 통한 애플리케이션을 구축을 위해 사용되는 인터페이스를 다룬다. 상세한 내용은 [부록(appendix)](https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#appendix)참조
### 검증인 (Validators)
전형적인 비잔틴 장애 허용 알고리즘들(BFT: Byzantine fault-tolerant algorithms)에서는 각 노드가 동일한 가중치를 갖는다. 텐더민트에서는 노드들이 ‘0 이상’의 *투표권(voting power)*을 가지며, 양(+)의 투표권을 갖는 노드들을 *검증인\*\*(validators)*라고 부른다. 검증인들은 다음 블록에 동의하는 암호서명(cryptographic signature), 즉 *투표(vote)*를 전파(broadcast)함으로써 합의 프로토콜에 참여한다.
검증인(validator)들의 투표권은 제네시스(genesis) 당시에 결정되거나 블록체인에 의해 결정론적으로(deterministically) 변경되기도 한다. 예를 들어, 코스모스 허브와 같은 지분증명 애플리케이션에서는 투표권이 담보물로서 본딩된(bonded) 지분 토큰(staking token)의 양에 의해 결정될 수도 있다.
_주: ⅔, ⅓ 과 같은 분수들은 모든 **검증인**들이 동등한 가중치를 갖지 않는 한, **검증인**들의 총수가 결코 아니라 총 투표권**에서 차지하는** **비중**을 가리킨다. 주: +⅔ 는 " ⅔ 초과"를 의미하**며**, ⅓+은 "⅓ 이상"을 의미한다._
### 합의 (Consensus)
텐더민트는 DLS 합의 알고리즘에서 파생되는, 부분적 동기 BFT 합의 프로토콜(synchronous BFT consensus protocol)이다[\[20\]](http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf). 텐더민트는 단순함, 성능 그리고 [포크 책임(fork-accountability)](https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#fork-accountability)이 특징이다. 이 프로토콜은 공개되있고 고정된 세트의 검증인들(a fixed, known set of validators)을 요구하는데, 각 검증인 공개 키에 의해 식별된다. 검증인들은 한 번에 하나의 블록, 즉 이체 목록(a list of transactions)에 대해 합의를 시도한다. 블록에 대한 합의는 라운드(round)를 통해 진행된다. 각 라운드에는 블록을 제안하는 라운드 리더(round-leader), 즉 제안자(proposer)가 있다. 그 다음, 검증인들은 제안된 블록을 받아들일 것인지 또는 다음 라운드로 넘어갈 것인지에 대한 단계별 투표를 진행한다. 각 라운드의 제안자는 검증인 리스트(ordered list)에서 투표권에 비례해 결정론적으로 선택된다.
프로토콜에 대한 세부정보는 [여기](https://github.com/tendermint/tendermint/wiki/Byzantine-Consensus-Algorithm)를 참조
텐더민트 보안은 압도적 다수결(+⅔)과 잠금 메커니즘(locking mechanism)을 통해 최적의 비잔틴 장애 허용을 사용하는 것으로부터 유래한다. 다음을 보장한다.
- 안전성을 저해(violation of safety)하기 위해서는 ⅓+의 투표권이 비잔틴이어야 하고, ‘2 개를 초과하는 값들’이 커밋(commit)되어야 한다.
- 프로토콜은 임의의 검증인들 세트가 안전성을 저해하는 데 성공하거나 또는 시도만 하더라도, 이들을 식별할 수 있다. 충돌하는 블록들에 찬성 투표 하거나 정당하지 않은 투표들을 전파하는 이들 모두가 포함된다.
텐더민트는 강력한 보장들에 더해 성능면에서도 탁월하다. 5 개 대륙 7 개 데이터센터에 분산되어 있는 64 개 노드의 대중품 클라우드(commodity cloud)를 기준으로, 텐더민트 합의는 약 1~2 초의 커밋 지연속도(commit latencies)와 함께 초당 수천 개의 트랜잭션(transaction)를 처리한다. 특히, 검증인들이 실패하거나 악의적으로 조작된 투표를 전파하는 가혹한 공격 상황(adversarial conditions)에서도 초당 1,000 번 수준의 트랜잭션 성능은 가볍게 능가한다. _아래 그림 참조_
### 라이트 클라이언트 (Light Clients)
텐더민트 합의 알고리즘의 특징은 단순화된 라이트 클라이언트 보안인데, 모바일 및 사물인터넷에 사용되기도 적합하다. 비트코인 라이트 클라이언트는 ‘블록헤더 체인’들을 동기화(sync)하여 가장 많은 작업증명을 가진 체인을 찾아야 하지만, 텐더민트 라이트 클라이언트는 ‘검증인 세트’의 변경을 추적해서, 최신 블록에서 +⅔ 프리커밋(PreCommit)을 검증하기만 하면 최신 상태를 결정할 수 있다.
간결한 라이트 클라이언트 증명들은 [블록체인 간 통신(inter-blockchain communication)](https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#/h)도 가능하게 한다.
### 공격 방지 (Preventing Attacks)
텐더민트는 ‘[long-range-nothing-at-stake double spend](https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#/h)’나 [검열(censorship)](https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#/h) 등을 방지하기 위한 다양한 보호장치를 가지고 있다. 세부사항은 [부록(appendix)](https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#/h)참조
### TMSP
텐더민트 합의 알고리즘은 텐더민트 코어(Tendermint Core)라는 프로그램에서 구현된다. 텐더민트 코어는 모든 결정적 블랙박스 애플리케이션(deterministic blackbox application)을 분산 복제 블록체인(distributedly replicated blockchain)으로 전환시킬 수 있는 어플리케이션 어그노스틱(application-agnostic) "합의 엔진"이다. 아파치 웹 서버나 Nginx 가 CGI 나 FastCGI 를 통해 워드프레스 애플리케이션에 접속하는 것처럼, 텐더민트 코어는 텐더민트 소켓 프로토콜(TMSP: Tendermint Socket Protocol)을 통해 블록체인 애플리케이션들과 연결된다.
비트코인을 예로 들어보자면, 비트코인은 각 노드가 완전 감사되는 UTXO(fully audited Unspent Transaction Output) 데이터베이스를 유지하는 암호화폐 블록체인이다. 만일 누군가 비트코인과 같은 시스템(Bitcoin-like system)을 TMSP 상에 만들고자 하면, ‘**텐더민트 코어**’는 아래와 같은 부분들을 책임진다.
- 노드 간 블록 및 이체 공유
- 정규(canomical)/변경배제(immutable) 이체순서의 확립(블록체인)
반면, ‘**TMSP 의 어플리케이션**’은 다음을 책임진다.
- UTXO 데이터베이스 유지
- 이체의 암호서명 검증
- 존재하지 않는 이체를 지불방지
- 클라이언트들의 UTXO 데이터베이스에 대한 query 허용
텐더민트는 애플리케이션 프로세스와 합의 프로세스 사이에 매우 단순한 API 를 제공함으로써 블록체인 설계를 분해할 수 있다.
## 코스모스 개요 (Cosmos Overview)
코스모스는 독립 병렬 블록체인들의 네트워크이며, 해당 블록체인들은 각기 텐더민트와 같은 전형적인 BFT 합의 알고리즘에 기반한다[1].
코스모스의 최초 블록체인이 곧 코스모스 허브가 된다. 코스모스 허브는 블록체인 간 통신(IBC) 프로토콜을 통해 다른 많은 블록체인들(즉, _존들_)과 연결된다. 코스모스 허브는 수많은 유형의 토큰을 추적하고, 연결된 각 존의 토큰 총 수를 기록한다. 모든 존들 간의 코인 전송은 코스모스 허브를 거치기 때문에 토큰은 존들 간의 유동 거래소(liquid exchange) 방식 없이
이 아키텍처는 어플리케이션 상호운용성, 확장성 그리고 무결절 업그레이드 가능성(seamless upgradability)을 포함한 블록체인이 직면한 많은 문제들을 해결한다. 예를 들면, Bitcoind, Go-Ethereum, 크립토노트(CryptoNote), ZCash 등을 포함한 임의의 블록체인 시스템으로부터 파생된 존들이 코스모스 허브에 연결될 수 있다. 이러한 존들을 통해 코스모스는 전역 이체(global transaction) 요구를 충족시킬 때까지 무한히 확장할 수 있다. 그리고 존들은 탈중앙화 거래소(distributed exchange)에도 매우 적합하며, 실제로 지원될 것이다.
코스모스는 단일 분산 원장에 불과한 것이 아니며, 코스모스 허브도 폐쇄형 플랫폼(walled garden, 울타리 친 정원)이 아니다. 오히려 코스모스는 미래 금융 시스템의 새로운 기초가 될 수 있는 개방형 분산원장 네트워크를 위한 프로토콜이며, 암호학 원리, 잘 설계된 경제(sound economics), 합의 이론, 투명성, 책임(accountability) 등의 원칙에 기반하고 있다.
### Tendermint-BFT DPoS
코스모스 허브는 텐더민트 BFT 합의 알고리즘에 기반하는, 코스모스 네트워크 내 최초의 퍼블릭 블록체인이다. 텐더민트 오픈 소스 프로젝트는 비트코인의 작업증명(PoW) 합의 알고리즘이 지닌 속도, 확장성, 환경 등의 문제를 처리하기 위해서 2014 년에 탄생했다. 1988 년 MIT 에서 개발한 증명된 BFT 알고리즘들을 활용하고 개선해서, 텐더민트 팀은 제 1 세대 지분증명(PoS) 암호화폐들이 겪은 Nothing-at-stake 문제를 해결하는 지분증명 암호화폐를 최초로 개념증명하였다.
오늘날, 대부분의 비트코인 모바일 지갑들은 이체 검증(transaction verification)을 제공하는 신뢰할 수 있는 서버(trusted server)를 이용한다. 이는 PoS 가 여러번의 이체확인(confirmation)을 기다려야만, 이체확정된 것으로 간주되기 때문이다. 이중지불(double-spend) 공격이 이미 코인베이스(CoinBase) 같은 서비스들에서 일어난 바 있다.
다른 블록체인 합의 시스템들과는 달리 텐더민트는 즉각적이고 안전한(provably-secure) 모바일-클라이언트 지불 검증을 제공한다. 텐더민트는 분기(fork)할 수 없도록 설계되었기 때문에, 모바일 지갑들에서 즉시 이체확인이 가능하며 실제로 신뢰 없는(trustless) 지불을 실현한다. 이는 IoT 관련 어플리케이션들에도 큰 영향을 줄 것이다.
(비트코인 채굴자들과 유사한 역할이지만 그 대신에 암호서명을 통해 투표하는) 코스모스의 검증인들은 블록을 커밋 할 책임이 있는 안전한 전용 머신들이어야 한다. 검증인이 아닌 이들(non-validators)은 ‘아톰’이라고 부르는 지분 토큰(staking tokens)을 임의의 검증인에게 위임하여 일정한 블록 수수료(block fees)와 아톰 보상(atom rewards)을 얻을 수는 있으나, 위임 검증인(delegate validator)이 해킹당하거나 프로토콜을 위반할 경우, 처벌을 받게 되는 리스크가 있다. 텐터민트 BFT 합의의 입증된 안정성 보장과 (검증인 및 위임자) 주주들의 담보 보증(collateral deposit)은 노드들에 심지어는 라이트 클라이언트들에게 증명 가능하고 정량화 가능한 보안성(provable, quantifiable security)을 제공한다.
### 거버넌스 (Governance)
‘공개형 분산원장’은 헌법(constitution)과 거버넌스 시스템(governance system)을 가져야 한다. 비트코인은 업그레이드 등의 조정을 위해 일정 부분 비트코인 재단(Bitcoin Foundation)이나 채굴에 의존하지만, 진행속도가 느리다. 이더리움의 경우에는 The DAO 해킹의 처리를 위한 하드포크 후 ETH 와 ETC 로 분할되었는데, 이는 사전에 그런 의사결정을 하기 위한 사회적 계약이나 메커니즘이 존재하지 않았기 때문이다.
코스모스 허브의 검증인과 위임자는 코스모스 허브의 정책들을 위한 ‘코드가 아니라 평이한 언어로 된 헌법(규칙)’을 표결에 부쳐 수정할 뿐 아니라 ‘블록 가스 한계(block gas limit)’ 같은 시스템의 사전에 설정된 제한들을 업그레이드를 통해 자동으로 변경하는 프로포잘(proposals)도 표결에 부칠 수 있다. 헌법은 The DAO 사건 같은 절도 및 버그관련 문제들의 이해관계자들이 응집(cohesion)할 수 있도록 도우며, 보다 신속하고 깔끔한 해결책이 나올 수 있도록 한다.
각 존 역시 자체적인 헌법과 거버넌스 메커니즘을 가질 수 있다. 예를 들어, 코스모스 허브가 변경 배제(immutability) -코스모스 허브의 노드 실행 버그를 제외하고는 롤백 금지(no roll-backs)와 같은- 헌법을 적용한 경우라면, 각 존은 절도와 버그를 위한 롤백 관련 자체 정책을 설정할 수 있다.
코스모스 네트워크는 상이한 정책의 존들 간 상호운용성을 확보함으로 사용자들에게 궁극적 자유와 실험의 기회를 제공한다.
## 허브와 존 (The Hub and Zones)
여기서는 탈중앙화(decentralization)와 확장성(scalability)의 새로운 모델을 설명한다. 코스모스는 텐더민트에 기반한 복수의 블록체인들의 네트워크이다. 기존의 프로포잘들이 전역적 이체 순서(total global transaction ordering)를 가진 ‘단일 블록체인’을 목표로 하는 반면에, 코스모스는 수많은 블록체인들이 상호 병행 실행(run concurrently)하는 동시에 상호운용성을 확보하도록 한다.
기본적으로 코스모스 허브는 ‘존(zone)’이라고 부르는 여러 독립된 블록체인들을 관리한다(‘존’은 ‘샤드(shard)’로도 불림, 데이터베이스의 스케일링 기법인 ‘샤딩(sharding)’참조). 존들은 최근의 블록 커밋들을 끊임없이 허브로 전송하며, 허브는 이를 통해 항상 최신 상태를 유지한다. 마찬가지로, 각 존도 허브의 상태를 제공받는다(다만 허브를 통한 간접적인 경우를 제외하고는 존들끼리는 서로 이러한 작업을 하지 않는다). 존들은 정보의 송신과 수신의 증거인 머클 증명(Merkle-proofs)을 포스팅함으로 정보의 패킷들을 교환한다. 이 메커니즘을 ‘블록체인 간 통신(inter-blockchain communication)’ 또는 IBC 라고 칭한다.
어느 존이든 스스로 허브가 되어 비순환 그래프(acyclic graph)를 형성할 수 있으나 명료성을 위해 우리는 단지 하나의 허브와 많은 비-허브 존들이 존재하는 단순한 구성만 설명할 것이다.
### 허브 (The Hub)
코스모스 허브는 멀티자산 분산 원장(multi-asset distributed ledger)을 관리하는 블록체인인데, 여기서 토큰은 개인 사용자들이나 존 자체가 보유할 수 있다. 이 토큰들은 ‘코인 패킷(coin packet)’이라 부르는 특수 IBC 패킷을 통해 하나의 존에서 다른 존으로 이동할 수 있다. 허브는 존들에 걸쳐 각 토큰 총액의 전역적 불변성(global invariance)을 보존한다. IBC 코인 패킷 이체는 반드시 송신자, 허브 및 수신자 블록체인에 의해 커밋 되어야 한다.
코스모스 허브는 전체 시스템을 위한 토큰의 ‘중앙 원장’ 역할을 하기 때문에, 보안이 무엇보다도 중요하다. 각 존은 단 4 명(혹은 BFT 합의가 필요하지 않을 경우에는 훨씬 더 적은 수)의 검증인으로도 안전해지는 텐더민트 블록체인일 수 있는 반면, 허브는 대륙 네트워크 분할(continental network partition)이나 국가 주도적 공격(nation-state sponsored attack) 같은 가장 심각한 공격 시나리오들에도 견딜 수 있어야 한다. 따라서 전역적으로 탈중앙화된 검증인 세트로 보안되어야 한다.
### 존 (The Zones)
코스모스 존은 허브와 IBC 메시지를 교환하는 독립 블록체인이다. 허브의 관점에서, 존은 IBC 패킷을 사용하여 토큰을 송수신할 수 있는 ‘멀티자산 동적구성원 멀티시그너처 계정(multi-asset dynamic-membership multi-signature account)’이다. 암호화폐 계정과 마찬가지로 존은 보유 중인 토큰보다 더 많은 토큰을 전송할 수 없지만, 토큰을 보유한 다른 존으로부터 토큰을 수신할 수는 있다. 존은 토큰 유형들의 ‘소스(source)’로 지정되어, 해당 토큰을 추가 공급할 수도 있다.
코스모스 허브의 아톰들은 허브의 검증인이 아니라, ‘허브에 연결된 존의 검증인’들에 의해 스테이킹될 수도 있다. 이 존들에 대한 이중지불 공격은 텐더민트의 포크 책임인 아톰의 대폭 감소(slashing)라는 결과를 가져오게 되는 반면, 투표권의 +⅔ 이 비잔틴인 존이라면 무효한 상태(invalid state)를 커밋할 수 있다. 코스모스 허브는 다른 존들에 커밋 된 이체들은 검증하거나 실행하지 않으므로, 자신이 신뢰하는 존으로 토큰을 전송하는 것은 사용자들의 책임이다. 장래에는 코스모스 허브의 거버넌스 시스템이 존 실패(failures)를 위한 허브 개선 프로포잘을 만들수도 있다. 예를 들면, 공격이 탐지될 때, 일부(또는 전체) 존들의 아웃바운드 토큰 전송을 억제함으로 ‘긴급 서킷 브레이킹(토큰 전송 일시중단)’을 할 수도 있다.
## 블록체인 간 커뮤니케이션 (Inter-blockchain Communication (IBC))
여기서는 허브와 존 간의 상호 통신방법을 설명한다. 예를 들어, ‘존 1(Zone 1)’, ‘존 2(Zone 2)’와 ‘허브(Hub)’의 세 블록체인이 있고, ‘존 1’이 ‘허브’를 통과하여 ‘존 2’로 가는 패킷을 만들고자 한다. 패킷이 하나의 블록체인에서 다른 블록체인으로 이동하기 위해, 송신 체인(sending chain)이 수신지로 가는 패킷을 발행했다는 증거를 수신 체인(receiving chain)에 포스팅한다. 수신 체인이 이 증거를 확인하기 위해서는 송신자의 블록 헤더(block headers) 정보를 알아야 한다. 이 메커니즘은 사이드체인(sidechain)이 사용하는 메커니즘과 유사한데, 상호 작용하는 두 체인이 ‘존재 증명 데이터그램의 양방향 스트림(a bidirectional stream of proof-of-existence datagram)’을 통해 서로를 ‘인식’해야한다 (이체).
IBC 프로토콜을 두 가지 이체 방식을 통해 정의할 수 있다: 블록체인이 최근의 블록 해시를 임의의 관측자에게 증명하는 IBCBlockCommitTx 이체, 그리고 블록체인이 송신자의 어플리케이션이 패킷을 머클증명을 통해 최근 블록해시로 전파했다는 것을 증명하는 IBCPacketTx 이체
IBC 구동방식을 IBCBlockCommitTx 와 IBCPacketTx 로 분할함으로, 수신체인의 내부 수수료 시장 메커니즘(native fee market-mechanism)이 커밋될(승인될) 패킷을 결정하도록 하며, 송신체인이 얼마나 많은 아웃바운드 패킷들을 허용할 지 자유롭게 정할 수 있도록 한다.
위의 예에서, ‘존 1’의 블록해시를 (또는 ‘존 2’ 상의 ‘허브’의 블록 해시를) 업데이트 하기 위해서는, IBCBlockCommitTx 이체가 ‘존 1’의 블록해시와 함께 ‘허브’에 (또는 ‘허브’의 블록해시와 함께 ‘존 2’에) 반드시 포스팅 되어야 한다.
_두 IBC 이체 유형에 관한 보다 상세한 정보는 [IBCBlockCommitTx](#ibcblockcommittx) 와 [IBCPacketTx](#ibcpacketcommit) 를 참조._
## 사용사례 (Use Cases)
### 분산거래소 (Distributed Exchange)
비트코인이 원장을 복사하고 분산하여 더 안전해지는 것처럼, 거래소도 블록체인 상에 올림으로 내/외부의 해킹으로부터 더욱 안전해질 수 있다.
현재 커뮤니티에서 칭하는 탈중앙화 거래소(decentralized exchange)는 ‘아토믹 크로스체인(Atomic Cross-Chain, AXC)’ 이체에 기반하고 있다. 이를 통해 두 명의 유저는 두 개의 서로 다른 원장(체인)에서 이체를 일으키고 해당 이체는 동시에 각 원장에 기록되거나 또는 그 어떤 원장에도 기록되지 않는다. 예를 들어, AXC 를 이용하면 두 명의 유저가 서로의 이더와 비트코인(또는 서로 다른 원장의 토큰)을 교환할 수 있다. AXC 기반 거래소의 장점은, 두 명의 유저 모두 서로 또는 거래소 서비스를 신뢰할 필요가 없다는 점이다. 그러나 거래를 위해서는 양 당사자가 반드시 온라인 상태여야만 한다는 점이 치명적인 단점이다.
또 다른 방식의 탈중앙화 거래소는 자체적인 분산원장에서 작동하는 ‘대규모의 복제 분산 거래소(a mass-replicated distributed exchange)’이다. 유저는 ‘지정가 주문(limit order)’을 내고 컴퓨터를 종료한다. 이 경우, 유저가 온라인 상태가 아니어도 거래가 성사된다. 블록체인이 해당 거래를 매칭시키고 완료시키는 것이다.
중앙화된 거래소의 경우, 이미 많은 지정가 주문이 걸려 있고 따라서 유저들을 더 쉽게 유치하게 된다. 거래소에서 유동성은 더 큰 유동성을 야기하고 강한 네트워크 효과(또는 승자독식)를 일으키게 된다. 현재 24 시간 거래량 기준, Poloniex 가 $20M 으로 가장 많은 거래량을 가지고 있고, Bitfinex 가 $5M 로 그 다음에 위치하고 있다. 이러한 사례를 생각해보면, AXC 기반의 새로운 탈중앙화 거래소가 중앙화된 거래소를 이길 가능성은 거의 없다. 탈중앙화된 거래소가 중앙화된 거래소와 경쟁하기 위해서는 많은 거래량을 확보해야 한다. 오직 ‘분산 거래소(distributed exchange)’만이 그것을 가능하게 할 수 있다.
텐더민트는 또한 매우 빠른 이체 커밋을 제공한다. 일관성의 훼손없이 빠른 완결성을 우선순위에 둠으로써 코스모스 상의 존(zone)들의 이체를 빠르게 완결한다. 이는 거래소의 이체나 IBC 를 통한 존들 간의 이체에 동일하게 적용된다.
현재 암호화폐 거래소들의 상황을 고려할 때, 코스모스를 이용해 분산거래소(일명 ‘코스모스 덱스’)를 만드는 것은 매우 적절하다. 코스모스 덱스(Cosmos DEX)의 이체 처리량과 커밋 속도는 중앙화된 거래소에 필적한다. 유저들은 지정가 주문을 올리고, 이 주문은 당사자의 온라인 상태여부에 관계없이 완결된다. 트레이더들은 텐더민트, 코스모스 허브, 그리고 IBC 를 통해, 빠른 속도로 자금을 존(zone)들이나 거래소로 이동시킬 수 있다.
### 다른 화폐에 가치고정 (Pegging to Other Cryptocurrencies)
특권 존(privileged zone)은 다른 암호화폐를 페깅한 토큰의 소스 역할을 할 수 있다. 페그(peg)는 코스모스 허브와 존의 관계와 본질적으로 유사한데, 코스모스 허브와 존 모두는 토큰이 한 쪽에서 다른 쪽으로 이동했다는 증명을 검증하기 위해 상대방의 최신 블록을 반드시 알고 있어야 한다. 코스모스 네트워크의 페그 존(peg-zone)은 다른 암호화폐뿐 아니라 허브도 추적한다. 페그 존을 통한 간접참조(indirection)는 허브의 로직이 단순하면서도 비트코인의 작업증명 채굴 같은 다른 블록체인 합의 전략들에 독립적(agnostic)인 상태를 유지할 수 있게 한다.
예를 들어, 허브의 검증인 세트와 동일한 어떤 검증인 세트를 갖는 존이 이더-페그(ether-peg) 역할을 할 수 있을 것이다. 여기서 ‘페그-존(peg-zone)’의 TMSP 애플리케이션은 ‘외부 이더리움 블록체인의 페그 컨트랙트(peg contract)’와 IBC 메시지를 교환할 수 있다. 이더 보유자들이 이더리움 상의 페그 컨트랙트로 이더를 전송함으로 코스모스의 페그 존에 이더를 전송하게 된다. 이렇게 이더가 일단 한번 수신되면, 페그 컨트랙트가 페그 존으로부터 IBC 패킷을 수신하지 않는 한 이더는 인출되지 못 한다. 페그 컨트랙트에서 특정 이더리움 계정으로부터 이더를 수신했다는 IBC 패킷을 페그 존으로 보내면, 이에 대응되는 계정이 동일한 잔고와 함께 페그 존 위에 생성된다. 페그 존 위의 (페깅된) 이더를 허브로 또는 허브로부터 전송할 수 있으며, 페깅 이더를 폐기하면서 이더리움 상의 특정 인출 주소로 그 이더를 도로 전송할 수 있고, 이더의 인출을 허용하기 위해 페그 존에서 이체가 발생했음을 증명하는 IBC 패킷을 이더리움 페그 컨트랙트에.
물론 그런 페깅 컨트랙트는 악의적 검증인 세트를 통한 리스크에 노출되어 있다. ⅓+ 비잔틴 투표권이 분기(fork)를 만들어 페깅된 이더를 페그 존에 유지하는 동시에 이더리움 위의 페그 컨트랙트를 통해 이더를 인출할 수도 있다. 더 좋지 않은 시나리오는 +⅔ 비잔틴 투표권이, 페그 존의 원래 페깅 로직으로부터 이탈하여, 페그 컨트랙트로 보내지는 모든 이더를 노골적으로 훔칠 수도 있다는 것이다.
이런 문제들은 페그를 ‘완전 책임적(totally accountable)’으로 설계하여 해결할 수 있다. 예를 들면, 허브나 원점(페깅될 토큰의 원래 블록체인)으로부터의 모든 IBC 패킷이 페그-존의 응답(acknowledgment)을 요구하도록 할 수도 있을 것이다. 허브와 원점은 페그-존 검증인들이 담보물(collateral)을 포스팅(post) 할 수 있게 하고, 독립 감사들(independent auditors)의 도전을 허용하기 위해 페그 컨트랙트로부터 나가는 토큰 전송은 지연되도록 하는 식이다. 그리고 담보 언본딩(unbonding) 기간은 충분히 길어야 한다. 이 부분은 미확정 상태로 두고, 누구든지 향후에 관련 제안을 해서 코스모스 거버넌스 시스템에 승인을 받아 적용할 수 있도록 한다.
정치사회적 분위기가 아직은 갖추어져 있지 않긴 하지만, 국가 통화의 책임기관들, 특히 은행들의 조합으로부터 검증인 세트를 형성함으로 국가의 법정통화에 페깅하는 존들을 허용할 수도 있다. 물론, 강력한 법체계에 기반하는 화폐만 허용하도록 충분한 고려가 되어야 할 것이며, 충분히 큰 규모의 공증인이나 기관들을 통해 감사시스템을 강제하여 은행들의 활동을 관리해야할 것이다.
이렇게 통합이 된다면, 참여 은행에 은행계좌가 있는 누구든지 존에 있는 은행계좌로부터 존에 있는 다른 계좌나 허브나 혹은 또 다른 존으로 법정화폐를 자유롭게 이동시킬 수 있을 것이다. 이 점에서 코스모스 허브는 법정화폐들과 암호화폐들 간의 전달자 역할을 하고, 지금까지 상호운용성을 거래소(exchanges)의 영역으로 한정시킨 장벽들을 제거할 수 있다.
### 이더리움 확장성 (Ethereum Scaling)
이더리움의 해결되지 않은 쟁점 하나는 스케일링 문제를 해결하는 방법이다. 현재는 각 이더리움 노드들이 모든 이체를 처리하고 또 모든 상태를 저장한다. [링크](https://docs.google.com/presentation/d/1CjD0W4l4-CwHKUvfF5Vlps76fKLEC6pIwu1a_kC_YRQ/mobilepresent?slide=id.gd284b9333_0_28)
텐더민트는 이더리움의 작업증명보다 훨씬 빠르게 블록들을 커밋 할 수 있기 때문에, 텐더민트 합의에 기반한 페깅된 이더(pegged-ether)를 운용하는 EVM 존들은 이더리움 블록체인에 보다 높은 성능을 제공할 수 있다. 뿐만 아니라, 비록 코스모스 허브 및 IBC 패킷 자체는 임의계약 로직 실행을 허용하지 않지만, 서로 다른 존들에서 실행되는 이더리움 컨트랙트 간 토큰이동의 조정을 위해 사용되며, 샤딩(sharding)을 통한 토큰 중심 이더리움 스케일링을 위한 기반을 제공할 수 있다.
### 멀티 어플리케이션 통합 (Multi-Application Integration)
코스모스 존들은 존의 생성 초기에 정해진 어플리케이션 로직에 따라 작동하며, 거버넌스를 통해 지속적으로 업데이트될 수 있다. 그런 유연성 덕분에 코스모스 존들이 이더리움이나 비트코인 같은 다른 암호화폐들의 페그 역할을 하고, 동일한 코드베이스를 활용하면서도 상이한 검증인 세트와 초기 분포(initial distribution)를 갖는 블록체인 파생상품(derivatives)을 만들 수 있다. 이를 통해 이더리움, 제로캐시, 비트코인, 크립토노트 등과 같은 기존의 암호화폐 프레임워크들이 ‘고성능 합의 엔진(텐더민트 코어)’을 통해 공통의 네트워크에서 사용될 수 있으며, 엄청난 상호운용성의 기회를 가질 수 있게 된다. 뿐만 아니라, 멀티 자산 블록체인으로서, 단일 이체는 다수의 인풋과 아웃풋을 포함할 수 있고, 어떤 토큰이든지 인풋이 될 수 있기 때문에, 주문들은 다른 플랫폼들을 통해 매칭되더라도 코스모스가 직접 탈중앙화 거래소(exchange)를 위한 플랫폼 역할을 할 수 있다. 또한 존은 오더북 기능이 있는 ‘분산형 장애-허용 거래소’ 역할을 할 수도 있는데, 해킹 공격에 당하곤 하는 기존의 중앙집중형 암호화폐 거래소들에 대한 강력한 개선책이 될 수 있다.
존은 또한 기업 및 정부 시스템들의 블록체인 버전(blockchain-backed versions)을 지원할 수도 있다. 전통적으로 조직에 의해 운영된 서비스에 대해서 기반이 된느 부분은 통제권을 유지하고, 특정 부분만을 존 위의 TMSP 애플리케이션으로 운영한다면, 퍼블릭 코스모스 네트워크의 보안과 상호운용성을 활용할 수 있게 된다. 따라서 코스모스는 블록체인 기술을 활용하고자 하지만 (분산된) 제 3 자에게 통제를 완전히 내주는 것은 경계하는 조직들에 일거양득을 제공할 수 있다.
### 네트워크 분할 완화 (Network Partition Mitigation)
일각에서는 텐더민트 같은 ‘일관성선호 합의 알고리즘(consistency-favouring consensus algorithm)’에 심각한 문제가 있다고 주장한다. +⅔ 투표권(⅓+은 오프라인)을 갖는 분할이 생기지 않도록 방지하는 것이 합의과정 자체를 멈추도록 할 수 있다는 것이다. 코스모스 아키텍처는 지역 자치 존(regional autonomous zone)을 갖는 전역 허브(global hub)를 사용함으로 이 문제를 완화할 수 있는데, 이 지역적 자치 존은 각 존의 투표권이 지리적 위치에 기초하여 분배되는 존을 가리킨다. 예를 들어, 개별 도시들이나 지역들이 자체적인 존을 운영하면서 공통의 허브(예. 코스모스 허브)를 공유하여, 일시적인 네트워크 분할로 허브가 중단되더라도 자치활동은 지속될 수 있도록 할 수 있다. 강인한 연합형 장애허용 시스템(robust federated fault-tolerant system)이 설계되기 위해서는 실제 지리, 정치 및 네트워크 토폴로지 관련 특징들이 고려되어야 할 것이다.
### 연합 명칭 결의 시스템 (Federated Name Resolution System)
네임코인(NameCoin)은 비트코인 블록체인을 이용하여 ‘명칭 결의(name-resolution)’ 문제를 해결하고자 한 최초의 블록체인 중 하나였다. 안타깝지만 이 접근법에는 몇 가지 문제들이 있었다.
네임코인으로 예를 들면, *@satoshi*라는 명칭이 과거 어느 시점에 특정 공개키로 등록되었다는 것은 검증할 수 있지만, 이후의 모든 블록들을 다운로드 하지 않는 한 그 공개키가 이후로 업데이트 된 적이 있는지는 알 수 없다. 이는 비트코인의 UTXO 머클화 모델의 한계 때문인데, 이 모델에서는 ‘상태’가 아닌 ‘이체의 기록’만 블록 해시로 머클화된다--이는 존재를 증명하지만, 이후로 업데이트가 없었다는 것을 증명하지는 못한다. 따라서 완전 노드를 신뢰하거나 전체 블록체인을 다운로드 하면서 상당한 비용을 지불해야만 가장 최근 값을 확실히 알 수 있다.
머클 탐색 트리(Merkle-ized search tree)가 네임코인에 구현되더라도, 작업증명에 대한 의존성 때문에 라이트 클라이언트 검증에서 문제가 생긴다. 라이트 클라이언트는 전체 블록체인의 블록헤더들(또는 적어도 마지막 업데이트 이후의 모든 헤더들)을 모두 다운로드 해야 한다. 이는 대역폭 사용이 소모시간과 함께 선형으로 증가한다는 것을 의미한다[\[21\]]][21]. 또한 작업증명 블록체인 위의 명칭 변경을 위해서는 추가적인 블록확인을 기다려야 하는데 이것이 비트코인에서는 최대 1 시간까지도 걸릴 수 있다.
텐더민트의 경우, 변경을 위해 필요한 것은 (투표권을 통해) 검증인 정족수가 서명한 최근의 블록 해시, 그리고 명칭에 대한 현재 값(current value)의 머클 증명이다. 이를 통해, ‘명칭 값’을 간결하고 신속하며 안전한 라이트 클라이언트 검증을 할 수 있다.
코스모스에서 이 개념을 확장시킬 수 있다. 코스모스의 각 명칭등록 존(name-registration zone)은 ‘.com’이나 ‘.org’와 같은 최상위 도메인(TLD: top-level-domain)을 가질 수 있고, 자체적인 거버넌스와 등록규칙을 설정할 수 있다.
## 발행과 인센티브 (Issuance and Incentives)
### 아톰 토큰 (The Atom Token)
코스모스 허브는 ‘다중자산 분산원장’이며 특별한 내부 토큰인 ‘_아톰(atom)_’을 가지고 있다. 아톰은 코스모스 허브의 유일한 지분 토큰(staking token)이다. 아톰은 보유자가 투표, 검증 또는 다른 검증인들에게 위임을 하기 위해 필요하다. 이더리움의 이더와 마찬가지로 아톰 역시 스팸공격 완화를 위한 이체수수료(transaction fees) 지불을 위해 사용될 수 있다. 추가되는 인플레이션 아톰(inflationary atoms)과 블록 이체수수료가 검증인들에게 그리고 검증인들에게 위임한 위임자들(delegators)에게 보상된다.
BurnAtomTx 이체 기능을 통해 ‘지급 준비금 풀(reserve pool)’에서 일정 비율의 토큰 금액(proportionate amount of tokens)을 회수(recover)할 수 있다.
#### 크라우드펀딩 (Fundraiser)
코스모스가 최초로 생성될 때 아톰 토큰과 검증인의 배분은 코스모스 크라우드세일의 자금제공자들(75%), 사전 자금 제공자들(5%)과 코스모스 주식회사(Cosmos Corp)(20%)로 가게 된다. 그 이후, 아톰 총액 중 1/3 이 본딩된(bonded) 검증인들과 위임자들에게 매년 보상될 것이다.
이 계획은 변경될 수 있으며 상세내용은 [Crowdfund Plan](https://github.com/cosmos/cosmos/blob/master/PLAN.md) 참조
### 검증인수의 제한 (Limitations on the Number of Validators)
비트코인 등의 작업증명 블록체인들과는 달리, 텐더민트 블록체인은 검증인의 수가 많아질수록 통신의 복잡도가 증가하여 속도가 느려진다. 물론 충분한 검증인들을 통해 블록체인의 전세계 분산, 매우 빠른 이체확인 속도를 제공할 수 있다. 또한 대역폭, 저장공간 및 병렬 컴퓨팅 용량이 증가함에 따라 장래에 더욱 많은 검증인들을 지원할 수 있을 것이다.
제네시스 시에는 최대 검증인 수가 100 명으로 설정될 것이고, 이 수치는 10 년 동안 13%의 비율로 증가하여 최종적으로는 총 300 명의 검증인을 가지게 될 것이다.
Year 0: 100
Year 1: 113
Year 2: 127
Year 3: 144
Year 4: 163
Year 5: 184
Year 6: 208
Year 7: 235
Year 8: 265
Year 9: 300
Year 10: 300
...
### 제네시스 일이후에 검증인되기 (Becoming a Validator After Genesis Day)
아톰 보유자들은 ‘BondTx 이체’를 서명하여 제출함으로써 검증인이 될 수 있다. 담보로 제공된 아톰 액수는 ‘0’보다 많아야 한다. 현재 검증인 세트의 크기가 허용된 최대 검증인 수보다 많은 경우를 제외하고는 누구라도 언제든지 검증인이 될 수 있다. 만일 검증인의 수가 허용치 이상인 경우, 가장 적은 검증인이 보유한 유효 아톰의 액수보다 더 높은 아톰 액수(위임받은 아톰 포함)를 담보로 제공해야만 한다. 이러한 방식으로 새로운 검증인이 기존 검증인를 대체할 수 있으며, 기존 검증인은 비활성이 되고 모든 아톰과 위임 아톰(delegated atom)은 언본딩 상태(unbonding state)로 돌아간다.
### 검증인에 대한 처벌 (Penalties for Validators)
고의든 아니든 검증인이 정해진 프로토콜을 어길 때에는, 처벌이 주어져야 한다. 동일한 높이(height) 및 라운드에서의 이중 서명이나 "prevote-the-lock"(텐더민트 합의 프로토콜의 규칙)의 위반 같은 행위는 증거를 통해 즉시 인정된다. 이 경우, 검증인은 유효한 지위(good standing)를 상실하게 되며, 본딩된 아톰과 ‘지급준비금 풀(reserve pool)’내 토큰의 비례분 즉, 통칭하여 ‘지분(stake)’을 상당수 잃을 것이다.
때로는 지역 네트워크 단절, 전원 장애나 그 밖의 이유들로 인해 검증인이 단절될 수 있을 것이다. 만일 ‘과거 어느 시점의 ValidatorTimeoutWindow 블록’에서 검증인의 커밋 투표가 이루어지지 않은 횟수가 ValidatorTimeoutMax Absent 횟수 이상인 경우, 해당 검증인은 비활성화 되고 지분의 ‘Validator TimeoutPenalty(디폴트 1%)’만큼 잃게 될 것이다.
어떤 ‘악의적’ 행위는 블록체인에 명확한 증거를 남기지 않을 수 있다. 이런 경우, 압도적 다수의 합의가 존재한다면, 검증인들이 외부에서 합의한 뒤 악의적인 검증인을 강제로 타임아웃(timeout) 시킬 수 있다.
‘투표권 ⅓+’이 악의적으로 연합하여 코스모스를 중단시키거나, 이들이 악의적 행동의 증거가 블록체인으로 들어오지 않게 검열하여 삭제하는 경우, 허브는 하드포크를 통한 블록재조정(reorg) 프로포잘로 복구(recover)되어야 한다.
### 이체 수수료 (Transaction Fees)
코스모스 허브 검증인들은 아톰 뿐 아니라, 어떠한 유형의 토큰이라도 이체수수료로 받을 수 있다. 각 검증인은, BlockGasLimit 을 초과하지 않는 한, 원하는 어떤 교환비율이든 주관적으로 정할 수 있고 원하는 어떤 이체든 선택할 수 있다. 징수된 수수료는 아래에 명시된 세금들을 제외하고, 매 ValidatorPayoutPeriod(검증인지불기간, 디폴트 1 시간)마다 본딩된 아톰(bonded atoms)에 비례하여 본딩된 주주들(bonded stakeholders)에게 재분배된다.
징수된 이체수수료 중 ‘지급준비금 세금(Reserve Tax, 디폴트 2%)’은 ‘지금준비금 풀’에 충당되며 이를 통해 ‘지금준비금 풀’을 늘리고 코스모스 네트워크의 보안과 가치를 높이는데 사용될 것이다. 또한 공유세(Commons Tax, 디폴트 3%)는 공유재의 자금으로 충당될 것이다. 이 자금들은 CustodianAddress 로 가게 되고, 거버넌스 시스템의 결정에 따라 분배된다.
투표권을 다른 검증인들에게 위임하는 아톰 보유자들은 위임 받은 검증인에게 커미션(commission)을 지불한다. 커미션은 각 검증인이 정할 수 있다.
### 해커에 대한 인센티브 제공 (Incentivizing Hackers)
코스모스 허브의 보안은 검증인들과 위임자들의 검증인 선택에 달려있다. 취약성 발견 및 조기 보고를 권장하기 위해 코스모스 허브는 해커들이 "이 검증인은 해킹 당했다. 본 주소로 포상금을 보내주기 바란다."라고 알릴 수 있는 ‘ReporthackTx 이체’를 통해 해킹성공 발표를 권장한다. 해킹 즉시, 해당 검증인과 위임자들은 비활성화되고, 이들의 아톰 일부가 ‘HackPunishmentRatio(해킹처벌비율, 디폴트 5%)’만큼 감소되고, 해커는 포상금 주소를 통해 ‘HackRewardRatio(해크보상비율, 디폴트 5%)’만큼 보상받는다. 검증인은 백업 키(backup key)를 사용하여 나머지 아톰을 회수(recover)해야 한다.
이러한 방법을 이용해 ‘본딩이 완료되지 않은 비귀속(unvested) 아톰’을 전송하려는 악의적 시도를 막기위해, 감별자와 위임자들의 귀속과 비귀속 아톰 비율은 ReportHackTx 전후로 동일하게 유지될 것이다. 해커 포상금은, 존재할 경우, 얼마의 비귀속 아톰을 포함할 것이다.
### 거버넌스 (Governance Specification)
코스모스 허브는 소프트웨어 업그레이드와 헌법(규정) 수정뿐 아니라 시스템의 변수 파라미터들과 같은 블록체인의 다양한 변화를 조정하기 위해서 명확한 거버넌스 메커니즘을 가진 분산형 조직에 의해 운영된다.
모든 검증인들은 모든 프로포잘에 대한 투표책임이 있다. 적시에 투표하지 않는 경우, 해당 검증인은 ‘결석처벌기간(AbsenteeismPenaltyPeriod-디폴트 1 주)’ 동안 자동으로 비활성화된다.
위임자들(delegators)은 그들이 위임한 검증인의 투표를 자동으로 물려받는다. 이 투표는 수동으로 취소(overriden manually)될 수 있다. 언본딩된(unbonded) 아톰들은 어떤 투표권도 얻지 않는다.
각 프로포잘은 ‘최소 프로포잘 보증금(MinimumProposalDeposit)’ 토큰을 요구하는데, 이는 아톰을 포함한 하나 이상의 토큰들일 수 있다. 각 프로포잘에 대해 투표자들은 보증금을 사용하기로 투표할 수 있다. 투표자의 절반 이상이 보증금을 사용하기로 선택할 경우, 그 보증금은 지급보증금 풀에 충당된다. 다만, 프로포잘이 스팸이었다거나 기타의 경우라서 소각되는(burned) 아톰은 제외한다.
각 프로포잘에 대해, 투표자들은 다음의 옵션으로 투표할 수 있다:
- Yay(찬성)
- YayWithForce(강력히 찬성)
- Nay(반대)
- NayWithForce(강력히 반대)
- Abstain(기권)
프로포잘의 통과 여부를 결정시에는 과반수의 투표가 요구되지만, 1/3+이 "강력히(with force)" 반대 투표함으로써 과반수의 결정을 거부할 수 있다. 다만 이렇게 과반수가 거부될 경우, 모두가 ‘거부권패널티블록(VetoPenaltyFeeBlocks, 디폴트 1 일 가치의 블록)’을 통해 수수료를 상실함으로 처벌 받고, 과반수 결정을 거부한 당사자는 자신의 아톰 중 ‘거부권패널티아톰(VetoPenaltyAtoms, 디폴트 0.1%)’ 만큼을 추가로 상실한다.
### 파라미터 변경 프로포잘 (Parameter Change Proposal)
여기서 정의된 파라미터들 중 어느 것이든 ParameterChangeProposal 의 통과를 통해 변경될 수 있다.
### 텍스트 프로포잘 (Text Proposal)
다른 모든 프로포잘들(예. 업그레이드 프로포잘)은 일반적인 TextProposal 을 통해 조정된다.
## 로드맵 (Roadmap)
[Plan](https://github.com/cosmos/cosmos/blob/master/PLAN.md) 참조.
## 관련 연구 (Related Work)
지난 수십 년 동안 블록체인 합의구조와 확장성 부분에서 많은 혁신이 있었다. 아래에서 중요한 몇 가지를 간략히 개관한다.
### 합의 시스템 (Consensus Systems)
#### 고전적 비잔틴 장애 저항 (Classic Byzantine Fault Tolerance)
악의적인 참여자가 있는 합의는 80 년대 초로 거슬러 올라가는 문제인데, 이때 레슬리 램포트(Leslie Lamport)는 프로세스가 단순한 ‘충돌 장애(crash fault)’와는 대조되는 것으로, 의도된 행위로부터 벗어나는 임의의 프로세스 행위(process behavior)를 가리키는 ‘비잔틴 장애(Byzantine fault)'라는 용어를 만들었다. 초기의 솔루션들은 메시지 지연시간에 상한(upper bound)이 존재하는 동기식 네트워크들을 위한 것이었다. 하지만 실제 사용은 항공기 제어기와 원자시계를 통해 동기화되는 데이터센터 같은 고도로 통제된 환경들로 제한되었다. 임의의 프로세스 행위를 최대 ⅓ 까지 허용할 수 있는 효율적인 ‘부분 동기 합의 알고리즘’으로서 ‘실용적 비잔틴 장애 허용(PBFT: Practical Byzantine Fault Tolerance)’[\[11\]](11)이 도입된 것은 90 년대 말이 되고 나서였다. PBFT 는 표준 알고리즘이 되었고, 많은 파생 변형들을 만들어내었다. 가장 최근에는 IBM 이 하이퍼레저(Hyperledger)에 기여를 위해 만든 변형이 있다.
PBFT 와 비교할때 텐더민트 합의구조의 중요한 장점은 텐더민트가 단순하고 개선된 기반 구조를 가진다는 것이고, 이 구조 중의 일부는 블록체인 패러다임을 수용한 결과이다. 텐더민트 블록들은 순서대로 커밋되는데, 이것이 PBFT 의 관점 변화(view-changes)와 관련 있는 복잡도와 통신 오버헤드를 제거한다. 코스모스를 포함한 많은 암호화폐에서는, 블록 _N_ 자체가 아직 커밋되지 않았을 때에는 블록 _N+i_(_i >= 1_)의 커밋을 고려할 필요가 없다. 블록 *N*이 코스모스 존에 커밋되지 않은 이유가 대역폭인 경우, _N+i_ 블록들에 대해 대역폭 공유 투표(bandwidth sharing votes)를 사용해도 의미가 없다. 만일 네트워크 분할이나 오프라인 노드들 때문에 블록 *N*이 커밋되지 않은 경우, 블록 *N+i*은 어차피 커밋되지 않는다.
뿐만 아니라, 블록들 속으로 이체를 배칭(batching)함으로 PBFT 의 체크포인팅(checkpointing) 기법 같은 주기적 다이제스트가 아닌, ‘어플리케이션 상태의 정규 머클 해싱’이 가능하다. 또한 이를 통해, 라이트 클라이언트들을 위한 보다 빠른 증명 가능한 이체 커밋과, 보다 빠른 블록체인 간 통신이 가능하다.
텐더민트 코어는 PBFT 에 명시된 것 이상의 많은 최적화 사항들과 기능들을 가지고 있다. 예를 들면, 검증인이 제안하는 블록들은 전파 성능을 개선하는 방식으로 부분화되고 머클화(Merkle-ized) 되고 가십화(gossipped)된다(영감은 LibSwift[\[19\]](19) 참조). 또한 텐더민트 코어는 점 대 점(point-to-point) 접속에 관한 어떤 가정도 하지 않으며, P2P 네트워크가 연결되어 있기만 하다면 작동한다.
#### 비트쉐어 위임 지분 (BitShares delegated stake)
비트쉐어(BitShares)[\[12\]](12)는 최초의 지분증명(PoS: proof-of-stake) 적용 사례는 아니지만, PoS 블록체인들, 특히 ‘위임(delegated)’ PoS 블록체인의 연구와 채택에 상당한 기여를 했다. 비트쉐어에서 지분 보유자들은 이체명령 및 커밋 책임이 있는 '증인(witnesses)'과 소프트웨어 업데이트와 패러미터 변경 책임이 있는 '델리게이트(delegates)'를 선출한다. 비트쉐어는 이상적인 상태에서 고성능(100k tx/s, 1 초 지연시간)을 달성하기는 하지만, 악의적인 증인들이 아무런 경제적 처벌 없이 블록체인을 분기해 이중지불 공격을 가할 수 있다. 즉 '무보증(Nothing-at-Stake)' 문제를 겪는다. 비트쉐어는 이체들이 최근의 블록-해시들을 참조하게 함으로써 이 문제를 완화하고자 한다. 물론 주주들은 부정행위 증인들을 매일 제거하거나 대체할 수 있다. 하지만 이것이 성공한 이중지불공격에 대한 분명한 처벌은 결코 아니다.
#### 스텔라 (Stellar)
리플(Ripple)이 개척한 방식을 토대로, 스텔라(Stellar)[\[13\]](13)는 ‘연합형 비잔틴 합의(Federated Byzantine Agreement)’ 모델을 개선했는데, 여기에서는 합의참여 프로세스에서 ‘전역적으로 알려진 고정된 집합’을 요구하지는 않는다. 오히려 프로세스 노드는 각기 신뢰할 수 있는 프로세스 집합을 구성하는 하나 이상의 '정족수 슬라이스(quorum slices)'를 배포한다. 스텔라에서 '정족수'는 노드들의 집합(set)이며, 적어도 각 노드당 하나 이상의 정족수 슬라이스를 포함하여 합의에 도달하도록 한다.
스텔라 메커니즘의 보안은 _임의의_ 두 정족수의 교집합이 비공(non-empty)이라는 가정에 의존한다. 또한 노드의 가용성을 위해서는, 정족수 슬라이스들 중 적어도 하나가 완전히 올바른(entirely correct) 노드들로 구성되어야 하며, 신뢰에 관한 중요한 가정 없이는 큰 정족수 슬라이스와 작은 정족수 슬라이스 사용 간에 발생하는 상호관계의 균형유지가 어려울 수 있다. 궁극적으로는 노드들은 충분한 장애허용이 가능한 ‘적절한 정족수 슬라이스’ 또는 ‘온전한 노드들(intact nodes)’을 어떻게든 선택해야 한다. 또한 그런 구성을 보장하는 유일한 전략은 계층적이고, 경계 경로 프로토콜(BGP: Border Gateway Protocol)과도 유사하다. 이는 전역 라우팅 테이블 확립을 위해 인터넷의 최상위 계층 ISP 들에 의해 사용되며, TLS 인증서를 관리하기 위해 브라우저들이 사용하기도 한다. 그러나 두 가지 모두 약한 보안성으로 악명높다.
스텔라 논문에서 비판한 ‘텐더민트 기반 지분 증명 시스템’들은 이곳에 기술된 토큰 전략을 통해 해명할 수 있다. 이 전략에서는 미래의 수수료 및 보상에 대한 권리인 *아톰*이라는 이름의 새로운 유형의 토큰이 발행된다. ‘텐더민트 기반 지분 증명’은 상대적으로 단순성을 유지하면서도, 충분한 그리고 입증 가능한 보안을 제공한다는 점에서 이점이 있다.
#### 비트코인 NG (BitcoinNG)
BitcoinNG 는 블록 크기 확장과 같은 수직 확장성을 제공하는 방법이다. 또한 이러한 확장이 초래하는 부정적 경제 요인들을 최소화하였다. 이러한 개선은 리더 선정(leader election)과 이체 전파를 분리시킴으로 가능하다: 리더들은 우선 ‘마이크로 블록(micro-block)’들에 있는 작업증명(PoW)을 통해 선정되며, 그 이후 새로운 마이크로블록이 발견될 때까지 커밋할 이체내역들을 전파한다. 이러한 방식은 PoW 경쟁을 이기기 위해 소요되는 대역폭 요구량을 줄여준다. 또한 소규모 채굴자들이 더욱 공정하게 경쟁하고 이체가 더 정기적으로 커밋될 수 있도록 한다.
#### 캐스퍼 (Casper)
캐스퍼[\[16\]](16)는 이더리움 용으로 제안된 지분증명(PoS) 합의 알고리즘이다. 주요 운용 방식은 '베팅에 의한 합의(consensus-by-bet)'이며, 검증인들은 지금까지 본 다른 베팅들(bets)에 기초해 블록체인에 커밋 될 것으로 생각되는 블록에 반복적으로 베팅하게 되며, 이러한 방식으로 결국 완결성(finality)이 달성된다는 논리를 전제한다. [링크](https://blog.ethereum.org/2015/12/28/understanding-serenity-part-2-casper/). 이러한 ‘합의 베팅’이 캐스퍼 팀의 주요 연구영역인데, 도전이 되는 부분은 베팅 메커니즘을 ‘진화적으로 안정된 전략(evolutionarily stable strategy)’이 되도록 설계해야 한다는 점이다. 텐더민트와 비교할 때 캐스퍼의 강점은 '일관성(consistency)보다 가용성(availability)'을 제공하는 것으로 볼 수 있다. 합의는 투표권의 +⅔ 정족수를 요구하지 않으며 커밋 속도나 구현 복잡도를 희생했다고 볼 수 있다.
### 수평 스케일링 (Horizontal Scaling)
#### 인터레저 프로토콜 (Interledger Protocol)
인터레저 프로토콜(Interledger protocol)[\[14\]](14)은 엄밀히는 확장성 솔루션이 아니다. 느슨하게 연결된 ‘쌍방 관계 네트워크’를 통해 상이한 원장 시스템들 간 ‘애드혹 상호운용성(ad hoc interoperation)’을 제공하는 방식이다. 라이트닝 네트워크(Lightning Network)의 경우처럼, ILP 는 지불을 용이하게 하는 프로토콜인데, 특히 서로 다른 유형의 원장들 간 지불에 초점을 맞추며 ‘아톰 이체 메커니즘(atomic transaction mechanism)’을 확장하여 ‘해시 잠금(hash-locks)’과 ‘공증인 정족수(quorum of notaries)’를 포함하로독 했으며, 이를 ‘아톰 전송 프로트콜(Atomic Transport Protocol)’로 칭한다. ‘원장 간 이체의 원자성(atomicity)’을 확보하기 위한 이러한 메커니즘은 텐더민트의 ‘라이트 클라이언트 SPV’ 작동방식과도 유사하다. 하단에서 ILP 와 코스모스/IBC 를 비교해본다.
1. ILP 의 커넥터(connector) 공증인들은 구성원(membership) 변경을 지원하지 않으며 공증인들 간 유연한 가중치 부여를 지원하지 않는다. 반면에 IBC 는 블록체인 전용으로 설계되었고, 검증인들이 상이한 가중치를 가질 수 있으며 블록체인을 통해 구성원들의 변경이 가능하다.
2. 라이트닝 네트워크나 ILP 에서는 지불 수신자가 송신자에게 ‘확인’을 되돌려 보내기 위해 반드시 온라인 상태여야 한다. IBC 를 통한 토큰 전송에서는, 수신자가 아니라, 수신자 블록체인의 검증인 세트가 ‘확인’을 제공할 책임이 있다.
3. 가장 근본적인 차이는 ILP 커넥터들은 지불에 대한 책임을 지거나 권한 상태를 유지하고 있지 않은 반면에, 코스모스에서는 허브의 검증인들이 IBC 토큰 전송과 각 존이 가진 토큰 총액에 대한 권한을 가진다는 점이다(그러나 존 내 각 계정이 보유한 토큰 금액에 대한 권한은 없다). 이는 존에서 존으로 비대칭 토큰 전송을 안전하게 실행하기 위한 근본적 혁신이다.
4. ILP 에서 원장 간 지불을 하기 위해서는 거래소 오더북(exchange orderbook)의 지원이 필요한데, 이는 하나의 원장에서 다른 원장으로의 ‘코인 비대칭 전송’이 없고 ‘가치나 시장 등가물(market equivalents)’의 전송만 있기 때문이다.
#### 사이드체인 (Sidechains)
사이드체인(sidechains)[\[15\]](15)은 비트코인 블록체인에 '페깅(pegged)'된 ‘대안 블록체인’을 통해 비트코인 네트워크를 확장하고자 하는 시도이다. 사이드체인은 비트코인이 비트코인 블록체인으로부터 사이드체인으로 효과적으로 이동할 수 있게 하고 사이드체인에서 각 체인의 특징을 이용한 실험들을 가능하게 한다. 코스모스 허브와 마찬가지로, 사이드체인과 비트코인은 상호 간 라이트 클라이언트 역할을 하며 코인 전송 시점을 결정하기 위해 SPV 증명을 사용한다. 물론 비트코인은 작업증명을 사용하기 때문에 비트코인 중심의 사이드체인들은 작업증명 합의 메커니즘으로부터 발생하는 여러 문제들과 리스크를 갖는다. 이는 ‘비트코인 극단주의자(Bitcoin-maximalist)’적 솔루션이며, 코스모스처럼 자체적으로 다양한 토큰들과 존 간 네트워크 위상(inter-zone network topology)을 지원하지는 않는다. 하지만, ‘양방향 페그(two way peg)’의 핵심 메커니즘 자체는 코스모스 네트워크의 방식과 원칙적으로 동일하다.
#### 이더리움 확장성 노력 (Ethereum Scalability Efforts)
이더리움은 확장성 확보를 위해 ‘이더리움 블록체인 상태’를 샤딩(sharding)하기 위한 여러 전략들을 연구 중이다. 현재의 이더리움 가상 머신(EVM)를 통해 ‘공유 상태 공간(shared state space)’에 ‘대한 추상적 계층(abstraction layer)’을 유지하는 방식이다. 또한 다수의 연구들이 진행되고 있다.[\[18\]](18)[\[22\]](22)
#### 코스모스 vs 이더리움 2.0 Mauve (Cosmos vs Ethereum 2.0 Mauve)
코스모스와 이더리움 2.0 Mauve[\[22\]](22)의 설계 목표에는 차이가 있다.
- 코스모스가 토큰들에 대한 것이라면 Mauve 는 일반 계산(general computation)의 스케일링에 관한 것이다.
- 코스모스는 EVM 에 구속되지 않으며, 심지어는 서로 다른 VM 들이 상호 운용될 수 있다.
- 코스모스는 존의 검증 책임자를 존의 생성자가 결정하도록 한다.
- (거버넌스 시스템의 결정과 상충되지만 않는다면) 누구든지 코스모스에서 새 존을 시작할 수 있다.
- 허브는 존 실패(zone failures)를 격리시키며, 이를 통해 ‘전역 토큰 불변성(global token invariants)’을 보증한다.
### 일반 스케일링 (General Scaling)
#### 라이트닝 네트워크 (Lightning Network)
라이트닝 네트워크는 비트코인 블록체인(그리고 그 밖의 퍼블릭 블록체인들)의 상위 계층에서 운용되도록 제안된 토큰 전송 네트워크로, 합의원장(consensus ledger) 외부의 대다수 이체들을 소위 ‘지불채널(payment channels)’로 이동시켜서 이체처리량(throughput)을 획기적으로 개선시킨다. 온 체인(on-chain) 암호화폐 스크립트를 통해 당사자들이 쌍무 상태기반 계약(bilateral stateful contracts)을 체결할 수 있도록 한다. 계약들의 상태는 디지털 서명에 의해 업데이트 되며, 또한 ‘크로스 체인 아토믹 스왑(cross-chain atomic swap)’를 통해 최초에 설정된 방식에 따라 합당한 증명을 블록체인에 전파함으로 계약이 마감된다. 다수의 당사자와 함께 지불 채널을 개방함으로, 라이트닝 네트워크의 참여자들은 당사자들이 지불을 라우팅하는 ‘포컬포인트(focal point)’의 역할을 할 수 있다. 또한 이러한 지불 채널에 실제 자본을 고정시킴으로 완전히 연결된 지불 채널을 개설하는 것도 가능하다.
라이트닝 네트워크는 다수의 블록체인들에 걸쳐 확장되면서 교환시장을 통해 *가치(value)*를 전송하도록 하지만, 하나의 블록체인에서 다른 블록체인으로 *토큰(token)*을 비대칭적으로 전송하는 것은 불가능하다. 이와 관련된 코스모스 네트워크의 주된 이점은 그러한 토큰의 직접 전송을 지원한다는 것이다. 물론, 비용 절감과 프라이버시 차원에서 토큰 전송 메커니즘이 지불 채널들과 라이트닝 네트워크와 함께 적용되기를 기대한다.
#### 세그위트 (Segregated Witness)
세그위트(Segregated Witness)는 블록 당 이체처리량을 2-3 배 가량 증가시키는 것을 목적으로 하며, 동시에 신규 노드들이 더욱 빠르게 블록 동기화(block syncing)를 하도록 돕는 비트코인 개선 제안이다([참조](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)). 이 솔루션은 비트코인의 현재 프로토콜 내에서 작동하면서 소프트 포크 업그레이드(soft-fork upgrade)를 허용하는 방식이다. 따라서, 이전의 소프트웨어 버전을 가진 클라이언트들도 업그레이드를 받아 정상적으로 기능할 수 있다. 텐더민트의 경우, 새로운 프로토콜을 만드는데 아무런 제약이 없기 때문에 확장성에 대한 새로운 우선순위를 가진다. 주로 텐더민트는 채굴 대신 암호 서명에 기반한 ‘BFT 라운드 로빈 알고리즘(BFT round-robin algorithm)’을 사용한다. 이를 통해, 다중 병렬 블록체인을 이용한 수평 스케일링을 가능하게 하면서도, 보다 정기적이고 자주 발생하는 블록 커밋에는 수직 스케일링을 적용할 수도 있다.
<hr/>
## 부 록 (Appendix)
### 포크 책임 (Fork Accountability)
잘 설계된 합의 프로토콜이라면 허용 용량(tolerance capacity)이 초과되거나 합의가 실패할 경우에도 문제가 없어야 한다. 이는 ‘비잔틴 행동’에 상당한 금전적 보상이 있을 수 있는 경제시스템에서 특히 중요하다. 그러한 보장 중 가장 중요한 것이 ‘_포크 책임(fork-accountability)_’인데, 포킹과 같은 합의실패를 초래한 프로세스들이 프로토콜 규칙이나 법적 체계(가능하다면)에 의해 식별되고 처벌받을 수 있다. 법 체계를 신뢰할 수 없거나 적용하기에 과도한 비용이 들 경우, 검증인들이 담보 보증(security deposits)을 내고 참여하도록 하고 악영향을 주는 행위 시 해당 담보를 차감하거나 강제로 환수함으로 처벌할 수 있다[\[10\]](10).
‘포크 책임’에서 다루는 것은 비트코인에서처럼 ‘네트워크 비동시성’과 ‘부분적 해시충돌’ 특성으로 인해 일어나는 정상적 분기와는 큰 차이가 있다. 많은 경우, 비동시성 때문에 악의적 포킹을 가려내는 것이 거의 불가능하기 때문에 비트코인의 경우 채굴자들이 포킹을 시도하다가 고아블록이 되어버리는 기회비용을 제외하고는 특별히 ‘포크 책임’을 물게하는 것이 어렵다.
### 텐더민트 합의 (Tendermint Consensus)
투표 단계들은 *프리보트(PreVote)*와 *프리커밋(PreCommit)*으로 나뉜다. 투표는 특정 블록이나 ‘_무효(Nil)_’를 위해 행사될 수 있다. 동일 라운드에서 단일 블록에 대한 +⅔ PreVote 집합을 *폴카(Polka)*라고 부르며, 동일 라운드에서의 단일 블록에 대한 +⅔ PreCommit 집합을 *커밋(Commit)*이라고 부른다. 만일 동일 라운드에서 ‘무효(Nil)’에 +⅔ PreCommit 상태라면, 다음 라운드로 이동한다.
결함 있는 리더들을 검출하고 무시하기 위해 엄격한 결정성(determinism)을 사용하다가 오히려 약한 동시성(synchrony)을 초래할 수 있다. 따라서 검증인들은 무효(Nil)를 Prevote 하기 전에, 일정 시간(*TimeoutPropose)*을 기다리게 되며 이 TimeoutPropose 값은 매 라운드마다 점점 증가한다. 검증인이 네트워크의 +⅔ 로부터 전파받을 때에만 단 한번 진행이 되므로, 라운드의 나머지 부분 진행은 완전히 비동시적이다. 실제로, 약한 동시성 가정( weak synchrony assumption)을 계속해서 좌절시키고 결국 블록 커밋을 위한 합의를 실패시키기 위해서는 극단적으로 강한 공격자가 필요하다. 또한 각 검증인에게 서로 다른 TimeoutPropose 랜덤값을 적용한다면, 공격은 더욱 어려워진다.
‘추가 제약조건 집합’, 즉 ‘잠금 규칙(Locking Rules)’은 네트워크가 각 높이에서 단 하나의 블록만을 커밋하도록 보장한다. 특정한 높이에서 두 개 이상의 블록을 커밋되게 하려는 시도는 모두 발각될 수 있다. 첫째로, 블록에 대한 프리커밋(PreCommit)은 해당 블록에 대한 폴카의 형태로 정당화(justification)되어야 한다. 만일 검증인이 이미* R_1* 라운드에서 블록을 프리커밋했다면, 이는 해당 블록에 로킹*(locked)*되며, _R_2_ 라운드의 새로운 프리커밋은 반드시 *R_1 < R_polka <= R_2*인 ‘R_polka 라운드’에서 발생해야한다. 둘째로, 검증인들은 자신들이 로킹되어 있는 블록을 제안(Propose)하거나 아니면 사전투표(PreVote)하거나 또는 둘을 함께 해야한다. 이를 통해 검증인은 충분한 증거 없이 프리커밋하지 못하며, 이미 프리커밋한 검증인의 경우 다른 블록을 동시에 프리커밋할 수 없게 된다. 이렇게 합의 알고리즘의 안전성(safety)과 라이브성(liveness)을 보장하게 된다.
프로토콜의 전체 세부내용은 [여기](https://github.com/tendermint/tendermint/wiki/Byzantine-Consensus-Algorithm)를 참조
### 텐더민트 라이트 클라이언트 (Tendermint Light Clients)
대안 체인(포크)의 존재 덕분에 본딩된(bonded) 지분을 ⅓+이 대폭 삭감할(slashed) 수 있기 때문에, 텐더민트 PoS 에서는 모든 블록 헤더들을 동기화(sync)할 필요가 없다. 물론 이러한 삭감을 위해서는 누군가가 포킹의 증거를 공유해야 하기 때문에, 라이트 클라이언트는 전파받는 모든 블록해시 커밋을 저장해야 한다. 뿐만 아니라, 라이트 클라이언트들은 ‘검증인 세트의 변경’과 주기적으로 동기화하여 [장기 공격(long range attacks)](#preventing-long-range-attacks)을 피할 수 있을 것이다(물론 다른 방법도 적용가능).
이더리움과 유사한 의도로, 텐더민트는 애플리케이션들이 각 블록에 ‘전역 머클 루트 해시(global Merkle root hash)’를 임베딩(embed)하도록 하고, 계정 잔고, 컨트랙트내 저장 값, UTXO 등 각 어플리케이션에 적합한 쉽게 검증이 가능한 ‘상태 쿼리(state queries)’를 이용하도록 한다.
### 장기 공격 방지 (Preventing Long Range Attacks)
‘충분한 회복력(resilient)의 전파 네트워크 집합’과 ‘정적(static) 검증인 세트’가 있다면, 블록체인의 모든 포킹이 검출될 수 있으며 문제가 되는 검증인들의 보증금을 대폭 삭감시킬 수 있다. 2014 년 초에 비탈릭 뷰터린(Vitalik Buterin)은 처음 지분증명 암호화폐들의 ‘무처벌(nothing-at-stake)’ 문제에 대한 해결책을 제시한다([관련 연구](#related-work) 참조). 그러나 검증인 세트들이 항상 고정되어 있는 것이 아니기 때문에 오랜 기간에 걸쳐 원래의 검증인들은 모두 언본딩 될 수 있고(may all become unbonded) 묶어둔 보증금이 사라지면서, 어떤 비용도 치르지 않고 제네시스 블록으로부터 새로운 체인을 자유로이 생성할 수 있게 된다. 이 공격은 단기 공격(Short Range Attack)과 대조되는 개념으로 ‘장기 공격(Long Range Attack)’으로 알려지게 되었다. 텐더민트 합의와 같은 ‘포크 책임 BFT 알고리즘(folk-accountable BFT algorithm)’이 존재한다면 현재 본딩된 검증인들이 포크를 초래하는 단기공격은 처벌이 가능하다. 반면 장기 공격은 지분증명 방식에 치명적인 공격으로 간주된다.
다행히 ‘장기공격(LRA)’을 부분적으로 방지하는 것이 가능하다. 첫째로, 검증인이 보증금을 언본딩하여 보증금을 회수하고 동시에 더이상의 합의참여 수수료를 포기하기 위해서는 정해진 일정 기간, 즉 ‘언본딩 기간(unbonding period)’을 채워야 한다. 그 기간은 수주 또는 수개월이 된다. 둘째로, 라이트 클라이언트는 최초로 네트워크에 연결될 때 신뢰할 수 있는 한개 이상의 출처를 통해 네트워크의 최근 블록해시를 검증해야 한다. 이러한 조건을 ‘약한 주체성(weak subjectivity)’으로 부르기도 한다. 마지막으로, 보안성을 유지하기 위해서 적어도 매 ‘언본딩 기간’을 주기로 ‘최종 검증인 세트’와 동기화되어야 한다. 이를 통해, 라이트 클라이언트는 검증인이 보증금을 빼내고 ‘무보증 상태(Nothing at Stake)’가 되었는지 여부를 파악할 수 있게 된다. 이를 파악하지 못한다면, 검증인은 최초 본딩이 시작된 블록으로 돌아가 새로우 블록들을 다시 생성함으로 장기공격을 감행할 수 있다(물론 이를 위해서는 검증인이 충분히 많은 초기 개인키를 가지고 있어야 함).
이러한 방식의 LRA 대응 방안은 기존 ‘작업증명(Proof-of-Work)’ 방식의 보안 기법에 대한 완전한 분해정비를 필요로 한다. ‘작업증명’에서는, 라이트 클라이언트가 언제든 전체 블록헤더의 작업증명을 처리하기만 한다면 신뢰할 수 있는 제네시스 블록을 통해 최신 블록체인을 동기화할 수 있다. 그러나 LRA 에 대응하기 위해서는, 라이트 클라이언트가 정기적으로 온라인 상태가 되어 검증인 세트를 추적해야하며, 최초 온라인이 되었을 때 반드시 신뢰할 만한 출처를 통해 네트워크에서 제공하는 정보의 진실성을 확인해야만 한다. 물론 신뢰할만한 출처를 이용하는 방법은 비트코인에서도 동일한데, 프로토콜이나 소프트웨어를 반드시 신뢰할 수 있는 출처에서 얻어야 하기 때문이다.
LRA 를 방지하는 상기의 방법은, 검증인들과 텐더민트 기반 블록체인의 완전 노드들에 적합하다. 이 노드들은 네트워크에 계속 연결되어 있기 때문이다. 또한 이 방법은 네트워크에 자주 연결될 수 있는 라이트 클라이언트들에도 적합하다. 하지만 라이트 클라이언트들이 자주 연결될 수 없는 경우, 다른 방법이 사용될 수 있다. 검증인이 아닌 토큰 보유자들이 상당히 긴 기간동안 자신의 토큰을 담보로 제공하는 것이다. 그리고 라이트 클라이언트들에게 이차적인 방법으로 최근과 이전의 블록해시 값을 전달하는 것이다. 이러한 토큰들이 블록체인 합의와 관련된 보안에는 영향을 미치지 않으나 라이트 클라이언트에게는 강력한 보장을 제공할 수 있다. 역사적 블록-해시 질의가 이더리움에서 지원될 경우, 누구든지 특별 설계된 스마트 컨트랙트에서 자신의 토큰을 본딩하고 지불을 위한 인증 서비스(attestation services for pay)를 제공하여 라이트 클라이언트 LRA 보안 시장을 효과적으로 창출할 수 있을 것이다.
### 포크 및 검열 공격 극복 (Overcoming Forks and Censorship Attacks)
블록 커밋의 정의로 인해, ⅓+ 투표권 연합은 오프라인이 되거나 투표전파를 거부함으로 블록체인을 중단시킬 수 있다. 그러한 연합을 통해 특정한 이체를 포함한 블록을 검열하여 탈락시킬 수도 있으며, 이 경우 상당한 양의 프로포잘이 거부되고 블록커밋 속도를 늦추어 블록체인의 효용과 가치를 낮출수도 있다. 또한 연합은 소량의 투표만을 전파하여 블록체인의 블록커밋 속도를 서서히 늦출 수도 있다. 결정적으로 이들은 이중서명이나 잠금규정을 지키지 않음으로 블록체인을 분기(포킹)시킬 수도 있다.
전역적 능동 공격자(global active adversary)가 관여할 경우, 네트워크를 분할시키고 다른 이가 책임이 있는 것처럼 보이게 할 수도 있다. 이는 텐더민트만의 문제는 아니며 네트워크 상에 능동 공격자가 존재하는 모든 합의 프로토콜이 가진 한계이다.
이러한 유형의 공격이 가능해지려면, 발리데이터 부분집합(a subset of the validators)이 합동하여 외부수단을 이용해 포킹 목적의 블록재조정 프로포잘에 서명해야하고, 초기 발리데이터 부분집합도 이에 서명해야한다. 클라이언트들은 블록재조정 프로포잘의 서명을 유심히 검증하고, 이를 근거로 판단하거나 그 결정을 최종사용자에게 넘길 수 있다.
어떤 ‘비동시성 비잔틴 장애 저항 알고리즘(non-synchronous Byzantine fault-tolerant algorithm)’도 투표권의 ⅓+이 부정직할 경우, 합의에 도달할 수 없다. 하지만, 포크의 경우 투표권의 ⅓+이 이미 이중 서명이나 잠금 변경(lock-changing)에 의해 부정직한 것으로 가정한다. 따라서 블록재조정 프로포잘(reorg-proposal)에 서명하는 것은 어떤 비동시성 프로토콜에서도(즉, 자동적으로 그리고 기반 네트워크의 신뢰성에 관한 가정없이는) 해결할 수 없는 조정 문제이다. 현재로서는 ‘블록재조정 프로포잘 조정(reorg-proposal coordination)’ 문제를 인터넷 매체 상에서 일어나는 인간들의 사회적 합의에 맡기고 있다. 상충되는 두 블록재조정 프로포잘에 서명하는 것을 방지하기 위해, 검증인들은 서명에 앞서 남은 네트워크 분할이 없도록 주의해야 한다.
외부의 조정 수단 및 프로토콜이 강인하다면, 네트워크분기(포크)가 검열 공격보다는 덜 치명적이다.
⅓ 비잔틴 투표권을 요구하는 포크 및 검열 외에, +⅔ 투표권의 연합이 임의의 무효 상태를 커밋할 수도 있다. 이는 모든 BFT 합의 시스템의 특징이다. 쉽게 검증 가능한 포크가 생성되는 이중서명과는 달리, 무효 상태 커밋(commitment of an invalid state)을 검증하기 위해서는 발리데이터가 아닌 피어들(non-validating peers)도 전체 블록들을 검증해야한다. 이는 피어들이 상태의 지역 사본(local copy)을 가지고 각 이체를 실행하며, 상태 루트(state root)를 독립적으로 계산한다는 것을 의미한다. 또한 무효상태커밋이 검출되면, 사회적 합의만이 이를 처리하는 유일한 방법이다. 예를 들어, (2013 년 3 월처럼) 소프트웨어 버그로 인한 분기이든, 또는 (2015 년 7 월처럼) 채굴자들의 비잔틴 행동으로 인한 무효 상태 커밋이든 비트코인이 실패한 상황들에서, 비즈니스, 개발자, 채굴자 및 그 밖의 조직들의 잘 연결된 커뮤니티는 네트워크 회복을 위해서 참여자들의 무엇을 해야하는지에 대한 사회적 합의를 확립했다. 텐더민트의 경우, 블록체인의 검증인들이 식별될 수 있을 것으로 예상되기 때문에, 필요한 경우, 무효 상태의 커밋을 법률이나 어떤 외부 관할권을 통해 처벌하는 것까지도 가능할 수 있다.
### TMSP 명세 (TMSP specification)
TMSP 는 코어에서 애플리케이션으로 전달되는 3 가지 주요 메시지 유형으로 구성된다. 애플리케이션은 대응하는 응답 메시지로 응답한다.
AppendTx 메시지는 애플리케이션의 핵심 작업수단이다. 블록체인에서의 이체는 이 메시지와 함께 전달된다. 애플리케이션은 AppendTx 메시지와 함께 수신된 각 이체를 현재의 상태, 애플리케이션 프로토콜, 이체의 암호학적 요건 등과 비교해서 검증한다. 이후, 검증된 이체는 값을 키-값 저장장치(key values store)으로 결합하거나 UTXO 데이터베이스를 업데이트하여 애플리케이션 상태를 업데이트해야 한다.
CheckTx 메시지는 AppendTx 와 유사하지만 이체 검증에만 사용된다. 텐더민트 코어의 mempool(메모리 풀)은 CheckTx 로 이체의 유효성을 검사하고 유효한 이체만 피어들에 전파한다. 애플리케이션들은 이체의 증가 논스 (incrementing nonce)를 검사하고 논스가 오래된 경우, CheckTx 에 오류를 반환할 수도 있다.
Commit 메시지는 다음 블록 헤더에 포함될 현재 애플리케이션 상태에 대한 암호학적 커밋(cryptographic commitment)을 계산하기 위해 사용된다. 이를 통해 몇가지를 얻을 수 있다. 해당 상태 업데이트에서 불일치들이 포크의 형태로 나타나게 된다. 또한 머클-해시 증명들이 블록-해시와의 비교를 통해 검증될 수 있고 블록-해시는 (투표권에 의한) 검증인 정족수에 의해 서명되기 때문에, 단순한 방식으로 안전한 라이트 클라이언트 개발하는데 도움이 된다.
추가적 TMSP 메시지를 통해 애플리케이션이 검증인 세트를 추적(keep track of) 및 변경하고, 높이와 커밋 투표 같은 블록 정보를 수신할 수 있다.
TMSP 요구/응답(TMSP requests/responses)은 간단한 Protobuf 메시지들이다. [스키마 파일(schema file)](https://github.com/tendermint/abci/blob/master/types/types.proto) 확인
##### AppendTx
- **Arguments**:
- `Data ([]byte)`: The request transaction bytes
- **Returns**:
- `Code (uint32)`: Response code
- `Data ([]byte)`: Result bytes, if any
- `Log (string)`: Debug or error message
- **사용법**:<br/>
이체를 덧붙이고 실행한다. 이체가 유효할 경우, CodeType.OK 를 반환한다.
##### CheckTx
- **Arguments**:
- `Data ([]byte)`: The request transaction bytes
- **Returns**:
- `Code (uint32)`: Response code
- `Data ([]byte)`: Result bytes, if any
- `Log (string)`: Debug or error message
- **사용법**:<br/>
이체를 검증한다. 이 메시지가 상태를 변경(mutate)해서는 안 된다. 이체들은 mempool 계층의 피어들에게 전파되기 전, CheckTx 를 통해 먼저 실행된다. 동일 블록 내 이체의 발생 순서를 고려하기 위해 CheckTx 를 semi-stateful(준-상태기반)로 만들고 Commit 또는 BeginBlock 시에 상태를 클리어(clear) 할 수 있다.
##### 커밋 (Commit)
- **Returns**:
- `Data ([]byte)`: The Merkle root hash
- `Log (string)`: Debug or error message
- **사용법**:<br/>
애플리케이션 상태의 머클 루트 해시를 반환한다.
##### Query
- **Arguments**:
- `Data ([]byte)`: The query request bytes
- **Returns**:
- `Code (uint32)`: Response code
- `Data ([]byte)`: The query response bytes
- `Log (string)`: Debug or error message
##### Flush
- **사용법**:<br/>
응답 대기행렬(response queue)을 플러시(flush)한다. types.Application 을 구현하는 애플리케이션들은 이 메시지를 구현할 필요가 없다--프로젝트에 의해 처리되기 때문이다.
##### Info
- **Returns**:
- `Data ([]byte)`: The info bytes
- **사용법**:<br/>
애플리케이션 상태에 관한 정보를 반환한다. 애플리케이션 특정적이다.
##### SetOption
- **Arguments**:
- `Key (string)`: Key to set
- `Value (string)`: Value to set for key
- **Returns**:
- `Log (string)`: Debug or error message
- **사용법**:<br/>
애플리케이션 옵션을 설정한다. 예를 들어, mempool 연결을 위해서는 Key='mode', Value='mempool', 또는 합의 연결을 위해서는 Key='mode', Value='consensus'. 다른 옵션들은 각 애플리케이션마다 다르다.
##### InitChain
- **Arguments**:
- `Validators ([]Validator)`: Initial genesis-validators
- **사용법**:<br/>
제네시스 시, 1 회 호출됨.
##### BeginBlock
- **Arguments**:
- `Height (uint64)`: The block height that is starting
- **사용법**:<br/>
새 블록의 시작을 알린다. 모든 AppendTx 에 앞서 호출됨.
##### EndBlock
- **Arguments**:
- `Height (uint64)`: The block height that ended
- **Returns**:
- `Validators ([]Validator)`: Changed validators with new voting powers (0
to remove)
- **사용법**:<br/>
블록의 끝을 알린다. 이체 후, 각 커밋에 앞서 호출됨.
상세한 내용은 [TMSP 리포지토리(TMSP repository)](https://github.com/tendermint/abci) 참조.
### IBC 패킷 전송 확인응답 (IBC Packet Delivery Acknowledgement)
발신자가 수신 체인의 패킷전송 확인응답을 원할 여러 가지 경우가 존재한다. 예를 들어 장애가 있을 경우, 송신자는 수신 체인의 상태를 모를 수 있다. 또는 송신자는 (MaxHeight 패킷 필드로) 패킷에 타임아웃을 부여하기를 원하는 반면, 수신 체인이 갑작스런 수신 패킷 수 급증에 의한 서비스 거부(denial-of-service) 공격을 받을 수도 있다.
이런 경우, 송신자는 초기 패킷 상태를 AckPending 으로 설정하여 전송 확인응답을 요구할 수 있다. 그러면 앱 머클 해시에 abbreviatedIBCPacket 을 포함하여 전송을 확인해 주는 것이 수신 체인의 책임이다.
먼저, 'Zone 1'에 IBCPacket 이 존재함을 증명하는 '허브'가 있다. 그리고 이 허브 위에 IBCBlockCommit 과 IBCPacketTx 가 포스팅된다. 예를 들어 IBCPacketTx 는 다음과 같은 값을 갖는다:
- `FromChainID`: "Zone1"
- `FromBlockHeight`: 100 (say)
- `Packet`: an `IBCPacket`:
- `Header`: an `IBCPacketHeader`:
- `SrcChainID`: "Zone1"
- `DstChainID`: "Zone2"
- `Number`: 200 (say)
- `Status`: `AckPending`
- `Type`: "coin"
- `MaxHeight`: 350 (say "Hub" is currently at height 300)
- `Payload`: <The bytes of a "coin" payload>
다음으로, '허브'에 IBCPacket 이 존재함을 증명하는 'Zone 2' 위에 IBCBlockCommit 과 IBCPacketTx 가 포스팅된다. 예를 들면, IBCPacketTx 는 다음과 같다:
- `FromChainID`: "Hub"
- `FromBlockHeight`: 300
- `Packet`: an `IBCPacket`:
- `Header`: an `IBCPacketHeader`:
- `SrcChainID`: "Zone1"
- `DstChainID`: "Zone2"
- `Number`: 200
- `Status`: `AckPending`
- `Type`: "coin"
- `MaxHeight`: 350
- `Payload`: <The same bytes of a "coin" payload>
그 다음, 'Zone 2'는 앱-해시(app-hash)에 새로운 상태의 AckSent 를 보이는 생략형 패킷을 반드시 포함해야 한다. 생략형 IBCPacket 이 ‘Zone 2' 위에 존재함을 증명하는 '허브' 위에 IBCBlockCommit 와 IBCPacketTx 가 다시 포스팅된다. 예를 들면 IBCPacketTx 는 다음과 같다:
- `FromChainID`: "Zone2"
- `FromBlockHeight`: 400 (say)
- `Packet`: an `IBCPacket`:
- `Header`: an `IBCPacketHeader`:
- `SrcChainID`: "Zone1"
- `DstChainID`: "Zone2"
- `Number`: 200
- `Status`: `AckSent`
- `Type`: "coin"
- `MaxHeight`: 350
- `PayloadHash`: <The hash bytes of the same "coin" payload>
끝으로, '허브'는 패킷의 상태를 AckPending 에서 AckReceived 로 업데이트 해야 한다. 이 새로이 완결된 상태의 증거가 'Zone 2'로 되돌아간다. 예를 들면, IBCPacketTx 는 다음과 같은 값을 갖는다:
- `FromChainID`: "Hub"
- `FromBlockHeight`: 301
- `Packet`: an `IBCPacket`:
- `Header`: an `IBCPacketHeader`:
- `SrcChainID`: "Zone1"
- `DstChainID`: "Zone2"
- `Number`: 200
- `Status`: `AckReceived`
- `Type`: "coin"
- `MaxHeight`: 350
- `PayloadHash`: <The hash bytes of the same "coin" payload>
한편, 'Zone 1'은 ‘코인’패킷 전송의 실패가 '허브' 상에서 증명되지 않는 한, 성공적으로 전송될 것이라고 가정할 것이다. 위의 예에서, '허브'는 ‘블록 350’를 통해 'Zone 2'의 AckSent 상태를 수신하지 않는다면, 상태를 타임아웃(Timeout)으로 자동 설정했을 것이다. 이 타임아웃 증거가 'Zone 1'에 다시 포스팅 될 수 있고, 모든 토큰은 반환될 수 있다.
### 머클 트리와 증명 명세 (Merkle Tree & Proof Specification)
두 가지의 머클 트리 유형이 텐더민트/코스모스 생태계에서 지원된다: 단순 트리(Simple Tree)와 IAVL+ 트리.
#### 단순 트리 (Simple Tree)
단순트리는 요소들(elements)의 정적 리스트(static list)를 위한 머클 트리이다. 항목의 수가 2 의 거듭제곱이 아닐 경우, 잎들이 서로 다른 수준에 위치할 수 있다. 단순 트리는 트리의 양측면을 동일한 높이로 유지하고자 하지만, 좌측이 더 클 수도 있다. 이 머클 트리는 블록의 이체들을 그리고 애플리케이션 상태 루트의 최상위 요소들을 머클화 하기 위해 사용된다.
*
/ \
/ \
/ \
/ \
* *
/ \ / \
/ \ / \
/ \ / \
* * * h6
/ \ / \ / \
h0 h1 h2 h3 h4 h5
7요소의 단순트리
#### IAVL+ Tree
IAVL+ 데이터 구조의 목적은 애플리케이션 상태의 키-값 쌍들에 영구 저장(persistent storage)을 제공하는 것이다. 그렇게 하여 결정론적 머클 루트 해시를 효율적으로 계산한다. 트리는 [AVL 알고리즘](https://en.wikipedia.org/wiki/AVL_tree)의 변형(variant)을 사용하여 밸런싱되며(balancing), 모든 연산(operations)은 O(log(n))이다.
AVL 트리에서는 임의 노드의 2 개 ‘자식 서브트리(child subtree)’의 높이가 최대 1 차이가 난다. 업데이트 시, 이 조건이 위반될 때마다 트리는 이전 트리의 비수정 노드들을 가리키는 O(log(n))의 새 노드들을 만들어서 다시 균형을 잡는다. 기존 AVL 알고리즘에서는 내부 노드들이 키-값 쌍들도 보유할 수 있다. AVL+ 알고리즘(플러스에 주의한다)은 잎 노드 상의 모든 값을 유지하기 위해 AVL 알고리즘을 수정하며, 가지 노드들만 사용하여 키를 저장한다. 이를 통해 알고리즘을 단순화하고, 머클 해시 트레일(merkle hash trail)을 짧게 유지한다.
AVL+ 트리는 이더리움의 [패트리샤 트라이(Patricia tries)](https://en.wikipedia.org/wiki/Radix_tree)와 유사하다. 장단점이 존재한다. 키들은 IAVL+ 트리에 삽입되기 전에 해싱될 필요가 없고, 따라서 키 공간(key space)에서의 빠른 순서반복(ordered iteration)을 제공한다. 로직의 구현이 간편하고 내부 노드(inner nodes)와 잎 노드(leaf nodes)만 필요로 한다. 머클 증명은 일반적으로 짧고 균형 잡힌 이진 트리이다. 반면에 IAVL+ 트리의 머클 루트는 업데이트의 순서(order of updates)에 의존한다.
이진 변형(binary variant) 사용이 가능해지면, 이더리움의 패트리샤 트라이 같은 효율적 머클 트리들을 추가로 지원할 것이다.
### 이체 유형 (Transaction Types)
일반적으로, 이체들은 TMSP 인터페이스를 통해 코스모스 허브 애플리케이션으로 흘러간다.
코스모스 허브는 앞으로 SendTx, BondTx, UnbondTx, ReportHackTx, SlashTx, BurnAtomTx, ProposalCreateTx, ProposalVoteTx 등을 포함한 많은 주요 이체 유형들(primary transaction types)을 추가할 것이고 문서화할 것이다. 여기서는 IBC 의 두 주요 이체 유형인 IBCBlockCommitTx 와 IBCPacketTx 에 대해 설명한다.
#### IBCBlockCommitTx
IBCBlockCommitTx 이체는 다음으로 구성된다:
- `ChainID (string)`: The ID of the blockchain
- `BlockHash ([]byte)`: The block-hash bytes, the Merkle root which includes the
app-hash
- `BlockPartsHeader (PartSetHeader)`: The block part-set header bytes, only
needed to verify vote signatures
- `BlockHeight (int)`: The height of the commit
- `BlockRound (int)`: The round of the commit
- `Commit ([]Vote)`: The +⅔ Tendermint `Precommit` votes that comprise a block
commit
- `ValidatorsHash ([]byte)`: A Merkle-tree root hash of the new validator set
- `ValidatorsHashProof (SimpleProof)`: A SimpleTree Merkle-proof for proving the
`ValidatorsHash` against the `BlockHash`
- `AppHash ([]byte)`: A IAVLTree Merkle-tree root hash of the application state
- `AppHashProof (SimpleProof)`: A SimpleTree Merkle-proof for proving the
`AppHash` against the `BlockHash`
#### IBCPacketTx
IBCPacket 은 다음으로 구성된다:
- `Header (IBCPacketHeader)`: The packet header
- `Payload ([]byte)`: The bytes of the packet payload. _Optional_
- `PayloadHash ([]byte)`: The hash for the bytes of the packet. _Optional_
Payload 또는 PayloadHash 가 반드시 존재해야 한다. IBCPacket 의 해시는 Header 와 Payload 의 단순 머클 루트이다. 전체 페이로드(full payload)가 없는 IBCPacket 은 _생략형 패킷_(_abbreviated packet_)이라고 부른다.
IBCPacketHeader 는 다음으로 구성된다.
- `SrcChainID (string)`: The source blockchain ID
- `DstChainID (string)`: The destination blockchain ID
- `Number (int)`: A unique number for all packets
- `Status (enum)`: Can be one of `AckPending`, `AckSent`, `AckReceived`,
`NoAck`, or `Timeout`
- `Type (string)`: The types are application-dependent. Cosmos reserves the
"coin" packet type
- `MaxHeight (int)`: If status is not `NoAckWanted` or `AckReceived` by this
height, status becomes `Timeout`. _Optional_
IBCPacketTx 이체는 다음으로 구성된다:
- `FromChainID (string)`: The ID of the blockchain which is providing this
packet; not necessarily the source
- `FromBlockHeight (int)`: The blockchain height in which the following packet
is included (Merkle-ized) in the block-hash of the source chain
- `Packet (IBCPacket)`: A packet of data, whose status may be one of
`AckPending`, `AckSent`, `AckReceived`, `NoAck`, or `Timeout`
- `PacketProof (IAVLProof)`: A IAVLTree Merkle-proof for proving the packet's
hash against the `AppHash` of the source chain at given height
'허브'를 통해 '존 1'에서 '존 2'로 패킷을 송신하기 위한 순서가 {그림 X}에 도시되어 있다. 먼저, IBCPacketTx 가 패킷이 '존 1'의 앱-상태(app-state)에 포함되어 있음을 '허브'에 증명한다. 그 다음에 또 다른 IBCPacketTx 가 패킷이 '허브'의 앱-상태에 포함되어 있음을 '존 2'에 증명한다. 이 절차 동안, IBCPacket 필드들은 동일하다: SrcChainID 는 언제나 'Zone1(존 1)'이고 DstChainID 는 언제나 'Zone2(존 2)'이다.
PacketProof 은 반드시 다음과 같은 올바른 머클 증명 경로를 포함해야 한다:
IBC/<SrcChainID>/<DstChainID>/<Number>
'존 1'이 '허브'를 통해 '존 2'로 패킷을 전송할 경우, 패킷이 '존 1', '허브' 또는 '존 2'의 어디에서 머클화 되든지 상관 없이 IBCPacket 데이터는 동일하다. 변경 가능한 유일한 필드는 전송 추적을 위한 Status(상태)이다.
## 감사의 글 (Acknowledgements)
We thank our friends and peers for assistance in conceptualizing, reviewing, and
providing support for our work with Tendermint and Cosmos.
- [Zaki Manian](https://github.com/zmanian) of
[SkuChain](http://www.skuchain.com/) provided much help in formatting and
wording, especially under the TMSP section
- [Jehan Tremback](https://github.com/jtremback) of Althea and Dustin Byington
for helping with initial iterations
- [Andrew Miller](https://soc1024.com/) of [Honey
Badger](https://eprint.iacr.org/2016/199) for feedback on consensus
- [Greg Slepak](https://fixingtao.com/) for feedback on consensus and wording
- Also thanks to [Bill Gleim](https://github.com/gleim) and [Seunghwan
Han](http://www.seunghwanhan.com) for various contributions.
- **Your name and organization here for your contribution**
## 인용 (Citations)
- [1] Bitcoin: <https://bitcoin.org/bitcoin.pdf>
- [2] ZeroCash: <http://zerocash-project.org/paper>
- [3] Ethereum: <https://github.com/ethereum/wiki/wiki/White-Paper>
- [4] TheDAO: <https://download.slock.it/public/DAO/WhitePaper.pdf>
- [5] Segregated Witness: <https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki>
- [6] BitcoinNG: <https://arxiv.org/pdf/1510.02037v2.pdf>
- [7] Lightning Network: <https://lightning.network/lightning-network-paper-DRAFT-0.5.pdf>
- [8] Tendermint: <https://github.com/tendermint/tendermint/wiki>
- [9] FLP Impossibility: <https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf>
- [10] Slasher: <https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/>
- [11] PBFT: <http://pmg.csail.mit.edu/papers/osdi99.pdf>
- [12] BitShares: <https://bitshares.org/technology/delegated-proof-of-stake-consensus/>
- [13] Stellar: <https://www.stellar.org/papers/stellar-consensus-protocol.pdf>
- [14] Interledger: <https://interledger.org/rfcs/0001-interledger-architecture/>
- [15] Sidechains: <https://blockstream.com/sidechains.pdf>
- [16] Casper: <https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/>
- [17] TMSP: <https://github.com/tendermint/abci>
- [18] Ethereum Sharding: <https://github.com/ethereum/EIPs/issues/53>
- [19] LibSwift: <http://www.ds.ewi.tudelft.nl/fileadmin/pds/papers/PerformanceAnalysisOfLibswift.pdf>
- [20] DLS: <http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf>
- [21] Thin Client Security: <https://en.bitcoin.it/wiki/Thin_Client_Security>
- [22] Ethereum 2.0 Mauve Paper: <https://cdn.hackaday.io/files/10879465447136/Mauve%20Paper%20Vitalik.pdf>
#### 기타 링크 (Unsorted links)
- [https://www.docdroid.net/ec7xGzs/314477721-ethereum-platform-review-opportunities-and-challenges-for-private-and-consortium-blockchains.pdf]