텐더민트, 그리고 ABCI

1. 텐더민트란 무엇인가?

1.1 텐더민트의 구성요소

간단히 말하자면, 텐더민트는 어떤 언어로든 블록체인을 만들기 위한 소프트웨어이다.

텐더민트는 크게 블록체인 합의 엔진(a.k.a 텐더민트 코어)와 Generic Application Interface(a.k.a ABCI)로 이뤄져 있다.

텐더민트 사이트의 설명에 의하면, 합의 엔진은 모든 State Machine(=node)에 동일한 Transaction이 동일한 순서로 기록되게 하고, ABCI(Application Blockchain Interface)는 어떤 언어로든 이 작업이 이뤄질 수 있게 해준다. 조금 더 가볍게 설명하자면, 텐더민트 코어는 비잔틴이 1/3 이하일 때, 모든 노드가 올바른 Transaction에 합의하고, 기록하는 작업을 도와주는 모듈이고, ABCI는 이 합의과정 중에서 필요한 작업들을 구현하기 편하게 하기 위한 API라고 생각하면 좋다.

1.2. 왜 이런 구조를 가졌을까?

텐더민트는 다른 블록체인과는 다르게 합의 엔진과 ABCI로 나뉘어진 구조를 가지고 있다. 텐더민트는 이런 구조를 통해서 기존 블록체인(비트코인, 이더리움)의 단점을 개선하고자 했다.

텐더민트 페이지에서 기술된 단점은 다음과 같다.

1.2.1코드를 재사용하기 어렵다

비트코인이나 이더리움의 경우, p2p connectivity, mempool bradcasting of transactions 등의 모든 작업을 하나의 프로그램에서 모두 다룬다. 따라서, 이 중 하나의 작업을 바꾸고자 한다면 아무리 추상화 작업이 잘되었다고 하더라도, 프로그램 전체에 대한 전반적인 이해가 필요하다.

1.2.2. 블록체인을 구성하는 언어를 강제한다.

예를 들어, 이더리움의 경우, Turing Computable Byte Code를 사용한다. 따라서, 이더리움을 사용하고자 한다면, 이 Byte Code로 컴파일할 수 있는 언어를 선택해야만 한다.

2. Intro to ABCI

2.1 ABCI에 대한 간단한 이해

텐더민트 코어는 ABCI를 만족하는 Socket Protocol을 사용하여 Application과 소통한다.

더 자세하게 설명을 하자면, 우리가 사용하는 Application이 있고, 실제로 블록체인에 대한 합의가 이뤄지고, Broadcasting하는 엔진이 있는데, 이 사이를 ABCI를 사용한 어떤 Protocol로 연결한다는 의미이다.

(더 구체적인 예시로 핸드폰을 생각해보자. State Machine에 해당하는 핸드폰 단말에서 앱 버튼 하나를 누르면 그 버튼에 연결된 일련의 API들이 실행되어서 실제 서버에 작업을 요청하고 그 결과를 보여준다고 생각하면 이해가 편할 수도 있겠다.)

따라서, ABCI는 텐더민트(State Machine Replication Engine)과 Application(The Actual State Machine)사이의 인터페이스이다.

2.1.1 더 자세한 이해

ABCI의 실체는 set of methods로 이뤄져 있으며, 각 method는 Request 와 Response Message Type으로 이뤄져 있다.

뜬금없이 Message Type이 나와서 이해가 가지 않는 사람을 위한 부가설명을 하자면, 실제 State Machine과 Engine 사이에서 ABCI가 각 State Machine과 Engine사이에서 요청하고 응답하는 시스템으로 이뤄지고 있다. 그래서 이를 Message라고 부르고 있다. 아래의 그림에서 Mempool과 Application Logic사이에 ABCI를 통해 서로 요청하고 응답하는 것을 볼 수 있다. 이 그림에 대해서는 나중에 더 자세히 알아볼 예정이다.

2.1.2 예시) Bitcoin-like System with Tendermint

비트코인의 노드는 UTXO(Unspent Transaction Output) Database를 모두 유지하며 따라간다.

만약 누군가 ABCI를 사용해서 Bitcoin-like system을 만들고자 한다면, 텐더민트 코어는 다음과 같은 역할을 수행한다.

• 노드 간 Block과 Transaction을 공유
• Canonical하고 Immutable한 Order of Transaction을 만들기.

반면 Application은 다음과 같은 역할을 해야할 것이다.

• UTXO Database 유지하기
• Transaction의 암호학적 서명을 증명하고, 서명하기
• 클라이언트가 UTXO Database에 쿼리를 보내게 해준다.

2.2 Type of ABCI

2.2 파트는 ABCI의 primitive한 타입에 대해 다루는 파트로, 텐더민트의 세부내용이 아닌 개괄적인 내용에 대해 관심이 있다면, 이런 타입이 있구나 하고 넘어가도 좋고, 그냥 넘어가도 좋습니다.

앞서 언급했던, ABCI의 Message type에는 Request 와 Response 가 있다. 그리고 조금 더 자세히 들어가면 세 가지의 primitive message type이 존재한다. 각각, DeliverTx , CheckTx , Commit 이다.

각 Type이 의미하는 바는 아래에서 설명하고자 한다.

2.2.1 DeliverTx

DeliverTx는 말 그대로 Transaction을 Deliver해주는 메세지 타입을 추상화한 타입이다.

따라서 이 메세지들은 Transaction을 담고 있으며, Application이 DeliverTx message를 받은 경우, 메세지에 있는 Transaction(e.g. Current State, Application protocol and cryptographic credentials of the transaction)을 입증해야한다. 만약 transaction이 입증된다면, 그 transaction들은 application state를 업데이트해줘야 한다. (KV Store에서 value를 잡아준다던지, UTXO database를 업데이트한다던지하는 방식으로)

2.2.2 CheckTx

CheckTx는 말 그대로, 어떤 transaction을 validating하기 위한 메세지 타입이다.

블록체인내에서 많은 작업들은 증명을 필요로 한다. 그런 경우에 사용한다.

예시로는 텐더민트 코어의 mempool은 transaction은 transaction의 validity를 CheckTx로 확인한 이후에야 p2p network를 통해서 valid transaction을 전파한다.

2.2.3 Commit

Commit은 현재 application state에 대한 암호학적 commitment를 계산할 때 사용된다.

DeliverTx와 CheckTx에 비해 불명확하게 보일 수 있다. 더 자세히 설명하자면, 블록체인에서 주로 다음 블록 헤더에는 현재 블록에 대한 내용이 들어가있다. 그래야 체인이 연속적으로 유지될 수 있기 때문이다.

Commit은 이 과정을 계산해준다. 다음 블록 헤더에 들어가야할 내용, 그 중 현재 Application state의 cryptographic commitment를 계산해준다.

CheckTx와는 달리 블록 자체에 대한 검증을 가지고 있다고 보면 더 쉽게 이해할 수 있을 것이다.

Commit은 몇 가지 편리한 특성을 가지고 있다.

1. 쉽게 에러를 간파할 수 있다.
   current state를 계산하는 과정에서 Inconsistency가 발견된다면, 포크된 블록에 대해서 계산되었음을 알 수 있다.
   (이전 블록헤더의 내용이 잘못되었다면, 현재 계산하고 있는 블록은 forked chain위에 있는 블록임이 자명하다.)
2. 이 특성을 통해, light client의 보안성을 더 간편하게 발전시킬 수 있다. 예시를 들자면, Merkle-hash proof는 block hash를 체크함으로서 쉽게 증명될 수 있다.

3. 어디에서 ABCI가 사용되는가?

텐더민트 코어에서는 크게 3곳에서 ABCI connection이 존재한다.

1. Mempool Connection: validation of transactions when broadcasting in the mempool
2. Consensus Connectoin: consensus engine to run block proposals
3. Info(Query) Connection: querying the application state

3곳이라고 했는데, 막상 그림에서는 ABCI가 2곳밖에 없다. Mempool과 Consensus Logic사이에 ABCI가 하나 더 있어야 할 것 같지만, 다시금 되새겨보자면, ABCI는 Application과 Consensus Engine사이의 Interface이다.

조금 더 자세히 보면, 1번이 Application과 Mempool사이에서 작용한다. 2번, 그리고 3번이 Application과 Consensus Logic사이에서 작용한다.

Transaction을 Mempool로 보내고, 해당 Transaction이 valid한지 확인하는 과정이 1번이다.

새로운 블록이 commit되었을 때, 다른 State Machine들도 이 블록에 대한 정보을 통해 State를 따라가는 것이 2번

마지막으로, Consensus Engine에서 Application으로 쿼리를 보내거나 그 역이 3번이라고 생각하면 될 것이다.

 

추가적으로, 4번째의 경우인, Snapshot Connection에도 ABCI Connection이 있다고 하는데, 이는 optional connection이기 때문에 나중에 기회가 되면 알아보고자 한다.

Reference

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