Intro
지난 Cosmos 글을 작성하면서 아쉽다는 생각이 들어 찾아본 결과
Cosmos Developer Portal을 찾게 되어 알게된 내용을
이전 글을 기준으로 보충하여 포스팅하려고 합니다 !
자세한 정보를 원하신다면 해당 링크를 통해 알아보시는 것을 추천드립니다 ☻
CometBFT
Desc.
CometBFT는 PBFT를 갖춘 DPoS를 기반으로 작동하는 합의 모듈입니다.
네트워크의 참여자들은 신뢰할 수 있는 서비스를 제공할 확률에 높은 노드에 ATOM을 스테이킹하며 지원을 받은 노드들 중 상위 175개의 노드들만 Validator로 참여합니다.
Validator들의 Voting Power는 해당 Validator와 대리인들이 스테이킹한 ATOM의 총 합으로 계산되며 블록을 생성할 수 있는 확률은 Voting Power에 비례되어 부여가 됩니다.
✏️ 만약 A Validator의 Voting Power가 20%라고 한다면, 20%의 확률로 블록을 생성할 권리를 받을 것으로 기대 가능하다고 합니다.
이렇게 생성된 블록은 신뢰할 수 있는 다른 Validator에게 전파되며 다른 Validator들에게 충분한 서명을 받은 후 네트워크에 전파됩니다.
이를 통해 CometBFT의 TPS는 수천건이 넘고, 블록 생성시간은 7초 정도의 시간이 걸립니다.
Chain Update
블록체인 네트워크에서는 업데이트를 위해서는 각 노드들에서 실행되는 노드의 소프트웨어를 업데이트를 해야하는데,
다른 퍼블릭 블록체인에서는 이 과정에서 하드포크가 발생할 수 있습니다.
✏️ 예를 들어 어떤 노드들은 업데이트를 받아드리고, 어떤 노드들은 받아드리지 않는 상황에서 발생할 수 있는데, 이는 물론 긍정적인 부분이 있을 수는 있지만, 분명한 단점 역시도 있습니다.
이를 고려해 CometBFT에서는 각 노드들이 소프트웨어를 동시에 업데이트하는 것에 대한 투표를 하고, 동의하면 전체 노드들이 업데이트하고, 그렇지 않으면 업데이트 제안이 실패하도록 되어 있다고 합니다
ABCI
CometBFT는 블록체인의 네트워킹 및 합의 계층을 패키징하고 Application 계층에 대한 인터페이스인 ABCI(Application BlockChain Interface)를 제공하며,
이를 통해 피어 검색, 유효성 검사기 선택, 스테이킹, 업그레이드 및 합의 등을 CometBFT에게 위임하여 사용 가능합니다.
CometBFT는 소켓 프로토콜로 애플리케이션에 연결됩니다. ABCI는 다른 언어로 작성된 응용 프로그램용 소켓을 제공하며, Applcation이 CometBFT 구현과 동일한 언어로 작성된 경우 소켓이 사용되지 않습니다.
Security
CometBFT는 다음을 포함한 보안을 제공한다고 합니다.
- Voring Power의 2/3 이상이 정직하다면 잘못된 합의는 이루어지지 않습니다.
- Update에 대한 합의 후 전체 노드가 업데이트를 하거나 하지 않기 때문에 포크가 발생하지 않습니다.
- 블록이 생성되는 즉시 트랜잭션이 완료 됩니다
또한 CometBFT는 트랜잭션 해석에 관해서는 관여하지 않으며, 확인되고 잘 구성된 트랜잭션과 트랜잭션 블록을 불가지론적으로 제시한다고 합니다.
Cosmos 시리즈를 보기 전에 알면 좋은 기술 및 개념
InterChain Stack
Inter Chain 개발자들이 사용할 수 있는 다양한 Tool을 의미하며 이름에 "Cosmos"가 포함된 인터체인 스택 내의 도구는 Cosmos SDK 및 Cosmos 같은 현재 용어 변경에 따라 변경되지 않는다고 합니다.
Light Client Demon (LCD)
먼저 Light Client는 full node와 다르게 블록체인 네트워크 상 특정 정보만을 추적하며 체인의 모든 트랜잭션 및 블록을 포함하지도 않습니다.
Tendermint 합의 알고리즘에서 Light client protocol은 요구사항은 최소화하면서 전체 노드가 얻는 것과 동일한 수준의 보안 혜택을 누릴 수 있도록하며, client는 모든 블록 또는 헤더를 동기화 하지 않고도 블록체인 상태 및 트랜잭션에 대한 암호화 증명을 받을 수 있다고 합니다.
따라서 Light Client는 IBC, 타임스탬프, 루트 해시 등에도 중요한 역할을 합니다. 이로 인해 공간이 절약되고 상태 업데이트 처리의 효율성이 향상된다고 합니다.
LCD(Light Client Daemon)는 Cosmos SDK에서 노출하는 HTTP1.1서버이며, 기본 포트는 :1337입니다. 해당 포트는 체인에 대한 REST API를 노출하며 해당 API는 RESTful 웹서비스와 상호작용이 가능합니다.
모든 쿼리는 LCD에 대해 다시 구현되고 RPC로 라우팅된다고 합니다.
Amino
Amino는 Go 언어 기반의 바이너리 객체 직렬화 및 직렬화 해제 라이브러리이며, Cosmos SDK에서 모든 모듈은 유형과 인터페이스를 직렬화하는 데 도움이 되는 Amino codec을 사용합니다.
Amino는 구체적인 유형 앞에 바이트를 접두사로 붙여 인터페이스를 처리합니다.일반적으로 아미노 코덱 유형 및 인터페이스는 모듈의 도메인에 등록됩니다.
✏️ Amino의 여러 타입에 대한 정보는 여기에서 확인 가능하며, 더 자세한 정보는 Tendermint의 go-amino레포에서 더 자세한 정보를 얻을 수 있습니다!
ProtoBuf
Protobuf(Protocol Buffers)는 Google에서 개발한 오픈 소스 교차 플랫폼 데이터 형식이며, 구조화된 데이터를 직렬화하고 네트워크 또는 데이터 저장 시 프로그램 통신을 지원하며,
Interchain 스택에서 Protobuf는 개발자가 메시지 형식을 설명하는 데 사용하는 데이터 직렬화 방법입니다.
✏️ Cosmos SDK v0.40에서부터 체인 상태 및 트랜잭션의 데이터 인코딩 형식을 기존의 Amino에서 더 좋은 인코딩/디코딩 성능이 나오는 Protobuf로 대체하기 시작했으며 Protobuf가 gRPC 기능을 자동으로 정의하고 생성하므로 gRPC 사용이 촉진된다는 장점도 기여했다고 합니다.
Remote Procedure Call (RPC)
RPC는 분산 컴퓨팅에서 자주 언급되는 소프트웨어 통신 프로토콜로, 프로그램이 다른 디바이스에서 실행되는 서브루틴 절차를 발생시킬 수 있도록 하여 프로세스 간의 통신을 실션시키는 특징을 갖고 있습니다
RPC를 사용하면 개발자들은 서브루틴이 로컬인 것처럼 코드를 작성할 수 있으며, RPC를 사용한다는 것은 로컬 또는 원격 호출과 관계없이 모든 호출 절차와는 관계없이 기본적으로 동일하다는 것을 의미한다고 합니다.
💡 RPC는 원격 요청-응답 프로토콜을 구현하므로 네트워크 문제가 발생할 경우 원격 프로시저 호출이 실패할 수 있습니다!
RPC 작동 원리
일반적으로 원격 프로시저 호출이 호출되면 프로시저 매개변수가 네트워크를 통해 프로시저가 실행되는 실행 환경으로 전송됩니다.
완료되면 호출된 프로시저 호출의 결과가 호출 환경으로 전송되며,
그 후 다음 일반 로컬 프로시저 호출에서와 마찬가지로 호출 환경에서 실행이 다시 시작됩니다.
단계별 RPC 요청은 아래와 같습니다.
1. 클라이언트는 RPC 중에 클라이언트와 서버 간에 전달되는 매개 변수를 변환하는 코드 조각인 클라이언트 Stub을 호출합니다. 호출은 로컬 프로시저 호출
↪ 원격 시스템의 프로그램이 로컬에서 작동하는 것 처럼 동작할 수 있도록 도와주는 작은 프로그램 루틴을Stub이라고 하며,
클라이언트와 서버 사이에서 인터페이스를 통일 및 해당 메소드 호출을 추상화하는 역할을 하므로 클라이언트는 네트워크 프로토콜, 직렬화, 역질렬화 등의 세부사항에 신경 쓰지 않고도 원격 메소드를 호출할 수 있게 도와줍니다2. 클라이언트 Stub은 프로시저 매개변수를 메시지에 패킹
↪ 원격 서버에서 처리할 수 있는 형태로 데이터를 변환하거나 패키징하는 과정을Marshaling이라고 하며, 마샬링된 데이터는 네트워크를 통해 전송될 수 있도록 바이트 스트림 등의 형태로 직렬화 되어 변환합니다.3. 그런 다음 클라이언트 Stub은 시스템 호출을 만들어 메시지를 보냅니다.
4. 클라이언트의 로컬 운영 체제(OS)는 해당 전송 계층을 통해 클라이언트에서 서버로 메시지를 보냅니다.
5. 서버 OS는 수신 패킷을 서버 스텁으로 전달합니다.
6. 서버 스텁은 메시지와 함께 포함된 프로시저 매개변수를 압축 해제합니다. 이를 UnMarshaling이라고 합니다.
7. 서버 Stub이 서버 프로시저를 호출하고 프로시저가 실행됩니다.
8. 절차가 완료되면 출력이 서버 Stub으로 반환되며, 반환값을 메세지에 페킹
9. 메시지는 클라이언트의 전송 계층을 통해서 메시지를 전송합니다.
10. 클라이언트 스텁은 반환 매개 변수를 해제하고 원래 호출 클라이언트로 반환
RPC & Interchain
Interchain 스택에서 RPC는 CLI에서 체인에 엑세스 하는데 사용됩니다. 또한 노드는 gRPC, REST API 및 ComentBFT Endpoint 등을 지원합니다.
CometBFT의 RPC Endpoint는 HTTP1.1 Server이며 기본 포트는 :26657를 사용하고 있고, 데이터 인코딩에는 HTTP POST 및 JSON-RPC 2.0을 사용합니다
또한 gRPC 서버의 기본 포트는 :9090이고, REST 서버의 기본 포트는 :1317입니다.
🖊️ 자세한정보는 여기에서 확인 가능합니다.
gRPC
gRPC는 google에서 RPC를 더 고성능으로 처리하기 위해 개발한 오픈소스 프레임워크입니다.
gRPC는 단일 사양을 가지고 있으므로, 일관된 구현을 지원하며, ProtoBuf(Protocol Buffers)를 이용해서 데이터를 인코딩 하여 HTTP2를 통해 전송합니다
Interchain 스택에서 gRPC는 ProtoBuf를 사용하는 TCP 서버로, 데이터 인코딩에 사용하며 기본 포트는 :9090입니다.
Cosmos SDK에서 Encoding
Cosmos SDK에는 클라이언트 인코딩과 저장소 인코딩의 두 가지 범주가 있다고 합니다.
클라이언트 인코딩은 트랜잭션 처리 및 서명 트랜잭션을 처리하는 반면, 스토어 인코딩은 상태-기계 트랜잭션과 Merkle Trie에 저장된 것을 처리합니다.
Cosmos SDK는 Amino와 ProtoBuf(Protocol Buffers), 두 개의 바이너리 와이어 인코딩 프로토콜을 사용합니다
그러나 현재는 성능, 언어지원 등과 같은 이유로 인해 Protocol Buffer가 Amino보다 점점 더 많이 사용됩니다.
✏️ Cosmos SDK에서의 Encoding에 대한 자세한 정보는 여기에서 확인 가능합니다!
Outro
사실 어떻게 지속적으로 Cosmos를 공부를 진행해야하나 고민했는데
Cosmos Developer Portal을 찾게 되어 천천히 공부를 지속할 예정입니다.
이번 포스팅에서 CometBFT에 대해 조금 더 알게 되었고,
Cosmos Develop Portal을 보다 보면 RPC와 ProtoBuf 등 자주 등장하는 기술들을 정리해보았습니다.
Cosmos 시리즈를 보기 전에 알면 좋은 기술 및 개념들은 꼭 Cosmos 시리즈가 아니더라도,
여러 곳에서 사용하니 이번 기회에 정리하면서 많이 배우게 되었고,
다음 포스팅은 Cosmos SDK에 대해서 준비해서 찾아오겠습니다 🙂🙂
Refer
