What is Tendermint

이 문서는 Tendermint 오피셜 문서 중 What is Tendermint를 번역한 것으로 오번역되었거나 표현이 불분명한 부분에 대한 댓글은 언제든 환영합니다. 원문은 아래의 링크에서 확인하실 수 있습니다.

 

What is Tendermint

https://docs.tendermint.com/master/introduction/what-is-tendermint.html

What is Tendermint | Tendermint Core

What is Tendermint

텐더민트는 많은 컴퓨터에 애플리케이션을 안전하고 일관성 있게 복제하기 위한 소프트웨어다. 안전성 부분에서, 텐더민트는 예상치 못한 문제로 1/3의 참여자에게 이슈가 발생하더라도 정상적으로 작동한다. 일관성 부분에서는 이슈가 없는 모든 참여자들은 동일한 트랜잭션 로그를 보고 동일한 상태를 계산한다는 것을 의미한다. 안전하고 일관된 복제는 분산형 시스템에서 근본적인 것으로, 통화, 선거, 인프라 조정 등에 이르는 광범위한 애플리케이션의 장애 허용(fault tolerance)에 중요한 역할을 하게 된다.
노드가 악의적으로 행동하는 등 모종의 방법으로 문제를 일으키는 것을 용인하는 능력을 비잔틴 장애 허용(BFT)이라고 한다. BFT 이론은 수십 년된 오래된 이론이지만, 소프트웨어 구현은 비트코인이나 이더리움 같은 '블록체인 기술'의 성공으로 인해 최근에야 대중화되었다. 블록체인 기술은 P2P 네트워킹과 암호 인증에 중점을 두고 보다 현대적인 환경에서 BFT를 재구성한 것에 불과한 것이라고 할 수 있다. 블록체인이란 이름도 각 블록이 이전 블록의 암호 해시를 포함하고 체인을 형성하는 블록에서 트랜잭션을 일괄 처리하는 방식에서 유래한다. 실제로 블록체인 데이터 구조는 BFT 설계를 최적화한 것이다.
텐더민트는 블록체인의 합의 엔진과 일반적인 애플리케이션 인터페이스라는 두 가지 주요 기술적 요소로 구성된다. 텐더민트 코어라고 불리는 합의 엔진은 모든 노드에서 동일한 거래가 동일한 순서로 기록되도록 한다. ABCI(Application BlockChain Interface)라고 불리는 애플리케이션 인터페이스는 어떤 프로그래밍 언어로도 트랜잭션을 처리할 수 있게 한다. 다른 블록체인과 합의 솔루션들이 내장된 상태 머신(화려한 key-value 스토어, 또는 기발한 스크립팅 언어 등)으로 사전 포장되어 나오는 것과 달리 개발자들은 자신에게 적합한 프로그래밍 언어와 개발 환경으로 작성된 애플리케이션의 BFT 상태 머신 복제를 위해 텐더민트를 사용할 수 있다.
텐더민트는 사용하기 쉽고, 이해하기 쉽고, 성능이 뛰어나며, 다양한 분산 애플리케이션에 유용하도록 설계되었다.

 

Tendermint vs. X

텐더민트는 대체로 두 종류의 소프트웨어와 비슷하다. 첫번째는 분산 key-value 저장소로서 Zookeeper, etcd, consul인데 이는 non-BFT 합의를 사용하는 부류이다. 두번째는 '블록체인 기술'로서 비트코인, 이더리움 같은 암호화폐, 그리고 하이퍼렛져의 Burrow와 같은 대체 분산원장 부류이다.

 

Zookeeper, etcd, consul

Zookeeper, etcd 및 consul은 모두 고전적인 non-BFT 합의 알고리즘 위에 키-값 저장소를 구현 한 것이다. Zookeeper는 Zookeeper Atomic Broadcast라는 Paxos 버전을 사용하는 반면, etcd와 consul은 훨씬 더 간단하고 최신인 Raft 합의 알고리즘을 사용한다. 일반적으로 클러스터는 3 ~ 5개로 구성되어 있으며, 최대 1/2의 충돌 실패를 허용 할 수 있지만 단일 비잔틴 장애로도 시스템이 파괴 될 수 있다.
각 시스템은 약간씩 차이가 있지만 여러 기능을 포함한 key-value 저장소의 구현체를 제공하며, 일반적으로 모두 동적 구성, 서비스 검색, 잠금, 리더 선택 등과 같은 분산 시스템에 기본 서비스를 제공하는 데 중점을 두고 있다.

 

텐더민트는 본질적으로 유사한 소프트웨어지만, 두가지 주요 차이점이 있다:

 

비잔틴 장애허용이다. 즉, 최대 1/3의 오류만 허용할 수 있으며 이러한 오류에는 해킹 및 악의적인 공격을 포함한 임의의 동작이 포함될 수 있다. 대신 텐더민트는 임의의 상태 머신 복제에 중점을 두므로 개발자는 key-value 저장소에서 암호 화폐, 전자 투표 플랫폼 등 자신에게 적합한 애플리케이션 로직을 구축 할 수 있다.

It is Byzantine Fault Tolerant, meaning it can only tolerate up to a 1/3 of failures, but those failures can include arbitrary behaviour - including hacking and malicious attacks. - It does not specify a particular application, like a fancy key-value store. Instead, it focuses on arbitrary state machine replication, so developers can build the application logic that's right for them, from key-value store to cryptocurrency to e-voting platform and beyond.

 

Bitcoin, Ethereum, etc

 

텐더민트는 비트코인의 작업증명보다 더 효율적이고 안전한 합의 알고리즘을 제공하기 위해 비트코인, 이더리움 등과 같은 전통적인 암호 화폐에서 등장했다. 초기에 텐더민트는 간단한 통화를 내장하고 있었고 합의에 참여하기 위해 사용자는 통화 단위를 보안 보증금에 "결합"해야했다. 이 보증금 개념은 텐더민트가 Proof-of-Stake 알고리즘을 선택한 것을 의미한다.
그 이후 텐더민트는 임의의 애플리케이션 상태를 호스팅 할 수 있는 범용 블록체인 합의 엔진으로 발전해왔다. 즉, 다른 블록 체인 소프트웨어의 합의 엔진에 대한 plug-and-play 대체제로 사용할 수 있다. 이는 Rust, Go 또는 Haskell에서 현재 이더리움 코드베이스를 가져와 텐더민트 합의를 사용하여 ABCI 애플리케이션으로 실행할 수 있다는 것을 의미한다. 실제로 이와 같은 방식으로 이더리움을 구현하였으며, 비트코인, ZCash 및 기타 다양한 결정론적 애플리케이션에 대해서도 동일한 작업을 수행할 계획이다.

텐더민트로 이루어진 다른 암호화폐 애플리케이션으로는 코스모스 네트워크가 있다.

 

ethermint

https://github.com/cosmos/ethermint

cosmos/ethermint

cosmos network

https://cosmos.network

Cosmos Network - Internet of Blockchains

Other Blockchain Projects

Fabric은 텐더민트와 유사한 접근 방식을 취하지만 상태가 관리되는 방식에 대해 더 많은 의견을 갖고 있으며 모든 애플리케이션 동작이 잠재적으로 많은 도커 컨테이너, "체인 코드"라고 부르는 모듈에서 실행되어야 한다. Fabric은 잠재적으로 비결정적 체인코드를 처리하기 위해서 IBM 팀에 의한 PBFT의 구현체를 사용한다. 이 도커 기반 동작을 텐더민트에서 ABCI 앱으로 구현할 수 있지만, 비결정론을 처리하도록 Tendermint를 확장하는 것은 향후 작업을 위해 남아 있다.

Fabric takes a similar approach to Tendermint, but is more opinionated about how the state is managed, and requires that all application behaviour runs in potentially many docker containers, modules it calls "chaincode". It uses an implementation of PBFT. from a team at IBM that is augmented to handle potentially non-deterministic chaincode It is possible to implement this docker-based behaviour as a ABCI app in Tendermint, though extending Tendermint to handle non-determinism remains for future work.

 

Burrow는 이더리움 가상머신 및 이더리움 트랜잭션 메커니즘의 구현이며 name-registry, 권한 및 기본 계약에 대한 추가 기능과 대체 블록체인 API가 있다. 텐더민트를 합의 엔진으로 사용하고 특정 애플리케이션 상태를 제공한다.

Burrow is an implementation of the Ethereum Virtual Machine and Ethereum transaction mechanics, with additional features for a name-registry, permissions, and native contracts, and an alternative blockchain API. It uses Tendermint as its consensus engine, and provides a particular application state.

 

PBFT

http://pmg.csail.mit.edu/papers/osdi99.pdf

 

ABCI Overview

ABCI (Application BlockChain Interface)는 모든 프로그래밍 언어로 작성된 애플리케이션의 비잔틴 장애허용 복제를 허용한다.

 

ABCI

https://github.com/tendermint/tendermint/tree/master/abci

 

Motivation

지금까지의 모든 블록체인 "스택"(ie. 비트 코인)은 모놀리식 디자인을 가지고 있다. 즉, 각 블록체인 스택은 분산 원장의 모든 문제를 처리하는 단일 프로그램이다. 여기에는 P2P 연결, 트랜잭션의 "mempool" 브로드캐스팅, 가장 최근 블록에 대한 합의, 계정 잔액, 튜링 완전한 컨트랙트, 사용자 레벨의 권한 등이 포함된다.
모놀리식 아키텍처를 사용하는 것에 대해 일반적으로 CS에서는 좋지 않다고 이야기 된다. 이는 코드의 구성 요소를 재사용하기 어렵게 만들고 이를 시도하면 코드베이스 포크에 대한 복잡한 유지 관리 절차가 발생하기 때문이다. 이는 코드베이스가 모듈식 설계가 아니어서 "스파게티 코드" 복잡하게 얽혀있어 어려움을 겪을 때 더욱 그렇다.
모놀리식 디자인의 또 다른 문제는 블록체인 스택의 언어로 제한된다는 것이다(또는 그 반대의 경우도 마찬가지). 튜링 완전 바이트 코드 가상머신을 지원하는 이더리움의 경우, 해당 바이트 코드로 컴파일되는 언어로 제한된다. 해당 언어들이 Serpent과 Solidity이다.
대조적으로, 우리의 접근 방식은 특정 블록체인 애플리케이션의 애플리케이션 상태 세부 정보에서 합의 엔진과 P2P 레이어를 분리하는 것이었다. 우리는 소켓 프로토콜로 구현되는 인터페이스에 애플리케이션의 세부 사항을 추상화하여 이를 수행한다.
텐더민트는 이를 위해 인터페이스인 애플리케이션 블록체인 인터페이스 (ABCI)가 존재하며, 기본 구현체인 Tendermint 소켓 프로토콜 (TSP 또는 Teaspoon)이 있다.

 

Intro to ABCI

텐더민트 코어("합의 엔진")는 ABCI를 충족하는 소켓 프로토콜을 통해 애플리케이션과 통신한다.
비유를 위해 잘알려진 암호화폐인 비트코인에 대해 이야기해보겠다. 비트코인은 각 노드가 완전히 확정한 UTXO(Unspent Transaction Output) 데이터베이스를 유지하는 암호화폐 블록체인이다. 만일 누군가가 ABCI 위에 비트코인 같은 시스템을 만들고자 한다면 텐더민트 코어가 노드간 블록 및 트랜잭션을 공유하는 것과 표준/불변 거래 순서 설정 (블록체인)하는 것을 책임져줄 수 있다.
그 애플리케이션은 UTXO 데이터베이스를 유지하고, 트랜잭션의 암호학적 사인을 검증하며, 존재하지 않는 트랜잭션을 사용하는 것을 방지하고, 사용자들이 UTXO 데이터베이스에 질의하는 기능을 포함할 것이다.
텐더민트는 애플리케이션 프로세스와 합의 프로세스 사이에 매우 간단한 API (ie. ABCI)를 제공하여 블록체인 디자인을 분해할 수 있다.
ABCI는 코어에서 애플리케이션으로 전달되는 3가지 기본 메시지 유형으로 구성된다. 애플리케이션은 해당 응답 메시지로 응답한다.

 

ABCI Message Types
https://github.com/tendermint/tendermint/blob/master/abci/README.md#message-types

 

DeliverTx 메시지는 애플리케이션의 전달자라고 할 수 있다. 블록체인에서의 각 트랜잭션은 메시지를 전달한다. 애플리케이션은 현재 상태, 애플리케이션 프로토콜 및 트랜잭션의 암호화 자격증명에 대해 DeliverTx 메시지와 함께 수신된 각 트랜잭션의 유효성을 검사해야한다. 그런 다음 검증된 트랜잭션은 값을 key-value 저장소에 바인딩하거나 UTXO 데이터베이스를 업데이트하는 등의 방법으로 애플리케이션 상태를 업데이트해야한다.
CheckTx 메시지는 DeliverTx와 유사하지만 트랜잭션 유효성 검사에만 사용된다. 텐더민트 코어의 mempool은 먼저 CheckTx로 트랜잭션의 유효성을 확인하고 유효한 트랜잭션만 peer에게 중계한다. 예를 들어 애플리케이션은 트랜잭션에서 증가하는 시퀀스 번호를 확인하고 시퀀스 번호가 이전 값인 경우 CheckTx에 오류를 반환할 수 있다. 또는 모든 트랜잭션에서 기능을 갱신해야하는 기능 기반 시스템을 사용할 수 있다.
Commit 메시지는 다음 블록 헤더에 배치될 현재 애플리케이션 상태에 대한 암호화 커밋을 계산하는 데 사용된다. 이것은 몇 가지 편리한 속성을 가지고 있다. 해당 상태 업데이트의 불일치는 이제 전체 종류의 프로그래밍 오류를 포착하는 블록체인 포크로 나타난다. 또한 Merkle-hash 증명은 블록 해시와 대조하여 확인하고 블록 해시가 필요 최소 인원들에 의해 서명되었는지 확인할 수 있으므로 안전한 경량 클라이언트의 개발을 단순화한다.
애플리케이션에 대해 여러 ABCI 소켓 연결이 있을 수 있다. 텐더민트 코어는 애플리케이션에 대한 세 가지 ABCI 연결을 생성한다. 하나는 mempool에서 브로드캐스팅 할 때 트랜잭션 검증을 위한 것이고, 하나는 블록 제안을 실행하기 위한 합의 엔진을 위한 것이고, 다른 하나는 애플리케이션 상태를 질의하기 위한 것이다.
애플리케이션 설계자는 유용한 모든 작업을 수행하는 블록체인을 만들기 위해 메시지 핸들러를 매우 신중하게 설계하는데 이 아키텍처는 그 시작을 제공할 수 있다. 아래 다이어그램은 ABCI를 통한 메시지 흐름을 보여준다.

 

A Note on Determinism

블록체인 트랜잭션 처리를 위한 로직은 결정적이어야한다. 애플리케이션 로직이 결정적이지 않다면 텐더민트 코어 복제 노드간 합의에 도달하지 못할 것이다.
이더리움의 Solidity는 다른 이유 중에서도 완전히 결정론적인 프로그래밍 언어이기 때문에 블록체인 애플리케이션을 위한 훌륭한 언어라고 할 수 있다. 그러나 Java, C++, Python 또는 Go와 같은 기존에 널리 사용되는 언어를 사용하여 결정론적 애플리케이션을 만드는 것도 가능하다. 게임 개발자와 블록체인 개발자는 이미 다음과 같은 비결정성 소스를 피함으로써 결정론적 프로그램을 만드는 데 익숙하다.

- 난수 생성기 (결정적 시드 없음)
- 스레드에 대한 경쟁 조건 (또는 스레드를 모두 회피)
- 시스템 시계
- 초기화되지 않은 메모리 (C 또는 C++와 같은 안전하지 않은 프로그래밍 언어)
- 부동 소수점 연산
- 임의의 언어 기능 (e.g. map iteration in Go)

개발자는 주의를 기울여 비결정성을 피할 수 있지만, 결정성을 확인하기 위해 각 언어에 대한 특수한 linter 또는 정적 분석기를 만드는 것도 가능하다. 앞으로 파트너들과 협력하여 이러한 도구를 만들 수 있을 것이다.

Consensus Overview

텐더민트는 이해하기 쉬운 일부 비동기로 구성된 BFT 합의 프로토콜이다. 프로토콜은 다음과 같은 간단한 state machine이다.

프로토콜의 참가자를 검증자(Validator)라고 한다. 그들은 번갈아가며 거래 블록을 제안하고 투표한다. 블록은 각 높이(height)에 하나의 블록으로 체인에 커밋된다. 블록이 커밋되지 않을 수 있으며, 이 경우 프로토콜이 다음 라운드로 이동하고 새 검증자가 해당 높이에 대한 블록을 제안하게 된다. 블록을 성공적으로 커밋하려면 두 단계의 투표가 필요하다. 우리는 그들을 사전 투표(prevote) 및 사전 커밋(precommit)이라고 부른다. 2/3 이상의 검증자가 동일한 라운드에서 동일한 블록에 대해 사전 커밋하면 블록이 커밋된다.
검증인이 폴카 댄스와 같은 형태로 처리하고 있기 때문에 폴카를 하는 커플의 사진이 있다. 2/3 이상이 동일한 블록에 대해 사전 투표를 하면 이를 폴카라고 부른다. 모든 사전 커밋은 같은 라운드에서 폴카로 정당화되어야한다.
검증인은 여러 가지 이유로 블록을 커밋하지 못할 수 있다. 현재 제안자가 오프라인이거나 네트워크가 느릴 수 있을 것이다. 텐더민트를 사용하면 특정 상황에서 검증인을 건너 뛰어야 함을 확인할 수 있다. 검증인은 다음 라운드로 이동하기 위해 투표하기 전에 제안자로부터 완전한 제안 블록을 받기까지 약간의 시간을 기다리게 된다. 시간 초과에 대한 이러한 의존으로 인해 텐더민트는 비동기 프로토콜이 아닌 약한 동기 프로토콜이 된다. 그러나 나머지 프로토콜은 비동기식이며 검증인은 검증인 세트의 3 분의 2 이상을 확인한 후에만 ​​진행된다. 텐더민트의 단순화 요소는 다음 라운드로 건너 뛰는 것과 동일한 메커니즘을 사용하여 블록을 커밋한다는 것이다.
3 분의 1 미만의 검증인이 비잔틴이라고 가정하면 텐더민트는 안전이 침해되지 않을 것임을 보장한다. 즉, 검증인은 동일한 높이에서 충돌하는 블록을 절대로 커밋하지 않는다. 이를 위해 흐름도에서 따라갈 수 있는 경로를 조정하는 몇 가지 잠금 규칙을 도입한다. 검증자가 블록을 사전 커밋하면 해당 블록에서 잠긴다. 그때,
1. 잠겨있는 블록에 대해 사전 투표해야한다.
2. 나중에 라운드에서 해당 블록에 폴카가 있는 경우 잠금을 해제하고 새 블록에 대해 사전 커밋 할 수 있다.

 

Stake

많은 시스템에서 모든 검증자가 합의 프로토콜에서 동일한 "가중치"를 갖는 것은 아니다. 따라서 우리는 3 분의 1 또는 2/3의 검증자에 관심이 없지만, 개별 검증자에게 균일하게 분배되지 않을 수 있는 총 투표권의 비율에 관심이 있다.
텐더민트는 임의의 애플리케이션을 복제할 수 있으므로 통화를 정의하고 해당 통화로 투표권을 표시할 수 있다. 투표권이 기본 통화로 표시되는 경우 해당 시스템을 지분 증명(Proof-of-Stake)이라고 한다. 검증인은 애플리케이션의 로직에 따라 합의 프로토콜에서 잘못된 행동을 한 것으로 밝혀지면 파괴될 수 있는 보증금에 통화 보유를 "결합"하도록 강제할 수 있다. 이것은 프로토콜의 보안에 경제적 요소를 추가하여 투표권의 1/3 미만이 비잔틴이라는 가정을 위반하는 비용을 정량화 할 수 있게 한다.

 

코스모스 네트워크는 ABCI 애플리케이션으로서 지분증명 메커니즘을 사용하여 설계되었다.
다음 다이어그램은 Tendermint의 간단한 요약이다.