Week 0 코스모스 개발

Good-To-Know Dev Terms

이번 섹션에서는 인터체인과 코스모스SDK를 사용하기 위한 용어들을 설명합니다.
커리큘럼을 보면 추후에 계속 나오는 것들인데 이번에 간단하게 정리하네요.
제가 이해한 것도 아니고 읽으면서 의역하는 중입니다. 말은 많은데 그래서 뭔데 이런 생각이 드네요. 하나도 모르겠습니다. 교육 과정이 week7까지 있는데 지금 week0의 마지막입니다. 공부하다보면 이해할 수 있겠죠. 그냥 간단히 뭐구나 하는 생각으로 넘어가고 있습니다. 복잡한 문장은 deepL을 통해서 번역하고 있습니다. 영어 단어와 한국어를 혼용하는 것은 제가 헷갈리기도 하고 마땅히 한국말로 번역하기 어려워서 그렇습니다. 그래도 얼추 무슨 말인지 이해하실 겁니다.
생략하는 부분도 있기 때문에 궁금하시면 원문 읽어보세요.

• The Interchain, and the Interchain Stack
• LCD
• RPC
• Protobuf - Protocol Buffers
• gRPC, gRPC-web, and gRPC-Gateway
• Amino

이것들은 전부 코스모스 SDK 블록체인에서 사용됩니다.
Let' go

Inter Chain

인터체인은 Inter-Block Communication Protocol(IBC)를 통해서 상호 연결된 인터 체인 스택으로 만들어진 어플리케이션 블록체인의 네트워크입니다.

In case you stumble across the term Cosmos, please be aware that the Interchain used to be known as Cosmos. The terms "Cosmos", "Interchain Ecosystem", and "Interchain" can be understood as synonymous.
-> Cosmos = interchain = Interchain Ecosystem

The Interchain Stack

인터체인 개발자가 사용할 수 있는 다양한 도구를 통칭하여 인터체인 스택이라고 부를 수 있습니다.

LCD - Light client daemon

A light client는 전체 노드와 비교해서 블록체인의 특정 정보를 추적합니다. Light client는 블록체인의 모든 정보를 확인하지도 않고 체인의 트렌젝션이나 블록을 포함하지도 않습니다.

Tendermint consensus(텐더민트 합의 결정법)에서 Light client 프로토콜은 클라이언트가 풀 노드가 누리는 것과 동일한 수준의 보안을 누리면서 대역폭의 요구사항을 최소화 할 수 있도록 합니다. 클라이언트는 모든 블록이나 헤더값을 동기화하지 않고 블록체인의 상태와 트렌젝션의 암호적 증명을 받을 수 있습니다.
Light Client in Tendermint Consensus

그래서 Light client는 IBC에서 중요한 역할을 합니다. Light client가 타임스탬프, 루트 해시, 다음 검증자 set hash의 정보를 추적하는데 필수적이기 때문입니다. 이것들은 공간을 절약하고 상태 업데이트 처리의 효율성을 높입니다.

Light Clien Daemon(LCD)는 Cosmos SDK를 통해서 HTTP1.1 server에서 노출되며 기본 포트는 1317입니다. 이 서버는 체인을 위해 REST API로 노출되는데 (representatinal state transfer applicaion progammin interface) - 이 API는 RESTful 웹 서비스와 상호작용할 수 있도록 합니다. 기존에는 모든 쿼리가 LCD로 재구현되었고 백그라운드에서 RPC로 라우팅되었습니다.

Remote procedure call (RPC)

RPC는 소프트웨어 커뮤니케이션 프로토콜입니다. RPC는 종종 분산 컴퓨팅에서 사용되는데 RPC가 inter-procss communication의 기술이기 때문입니다. 이것은 다른 주소, 다른 기계에서 서브루틴 프로시져가 실행될 수 있게 합니다.
RPC는 caller라고 할 수 있는 클라이언트와 executor라고 할 수 있는 서버(서비스를 제공하는 프로그램)를 통한 클라인트-서버의 상호 작용으로 이해할 수 있는데 이 상호작용은 request-response message-passing 시스템을 통해서 구현됩니다.

정리하자면 RPC는 request-response 프로토콜인데, server가 원격으로 서브루틴을 실행할 수 있는 request를 client가 보내면서 시작됩니다.

RPC는 다른 주소 공간에 있는 함수를 실행할 수 있도록 합니다. 일반적으로 호출된 함수는 호출한 컴퓨터와 다른 컴퓨터에서 실행됩니다. 그러나 RPC를 통해서 서브루틴이 실행이 로컬에 있는 것처럼 코딩할 수 있습니다. RPC를 사용할 때 코드들이 로컬에 있으나 원격으로 호출되나 둘은 독립적이지만 본질적으로 똑같습니다.

• RPC를 만들 때 원격 실행이 네트워크 환경에 따라서 실패할 수 있습니다.

  How does an RPC request work?

  일반적으로 원격 프로시저 호출이 호출되면 프로시저 매개변수가 네트워크를 통해 프로시저가 실행되는 실행 환경으로 전송됩니다. 호출이 완료되면 호출된 프로시저 호출의 결과가 호출 환경으로 전송됩니다. 그런 다음 일반 로컬 프로시저 호출과 마찬가지로 호출 환경에서 실행이 재개됩니다.

  ** 11가지 RPC step이 있으나 생략하겠습니다.
  해당 파트에서 읽어보세용

1. A client calls a client stub - a piece of code converting parameters that are passed between client and servers during an RPC. The call is a local procedure call.

2. The client stub packs the procedure parameters into a message.

3. The client stub then makes a system call to send the message.

4. The client's local operating system (OS) sends the message from the client (machine A) to the server (machine B) through the corresponding transport layers.

5. The server OS passes the incoming packets to the server stub.

6. The server stub unpacks the message and with it the included procedure parameters - this is called unmarshaling.

7. The server stub calls a server procedure and the procedure is executed.

8. Once the procedure is finalized, the output is returned to the server stub.

9. The server stub packs the return values into a message.

10. The message is sent to the transport layer, which sends the message to the 3. client's transport layer.

11. The client stub unmarshals the return parameters and returns them to the original calling client.

    In an Open Systems Interconnection (OSI) model, RPC touches the transport and application layers.

    RPC and the Interchain

    인터체인 스택에서 RPC는 체인에 접근하는 command-line interface(CLI)로 사용됩니다.
    노드는 다양한 엔드포인트를 노출합니다 - gRPC, REST, CometBFT

    CometBFT로 노출되었을 때, CometBFT RPC 엔드포인트는 HTTP1.1 서버이고 디폴트 포트는 26657입니다. gRPC서버의 디폴트 포트는 9090입니다. REST서버의 디폴트 포트는 1317입니다.
    CometBFT RPC는 CosmosSDK와 독립적이고 구성될 수 있습니다. 데이터 인코딩을 위해 HTTP port와 JSON-RPC 2.0을 사용합니다.

    엔드포인트에 대한 더 많은 정보

    Protobuf

    Protobuf(Protocol Buffers)는 구글이 개발한 크로스 플랫폼 데이터 포멧입니다. 이것은 구조화된 데이터를 직렬화하고 데이터가 저장할 때나 프로그램의 communication을 지원합니다.
    Protocol Buffer

    인터체인에서 Protobuf는 메세지 포멧을 설명하기 위해서 개발자들이 사용하는 데이터 직렬화 방법입니다. 인터체인 어플리케이션에서 내부적인 communication이 많습니다. 그래서 Protobuf는 communication 방식의 핵심으로서 사용됩니다.

    gRPC

    gRPC는 고성능의 원격 프로시져 실행 프레임워크입니다. 이것은 RPC를 다루기 위해서 구글이 만들었습니다(갓글...혼자 다했네) gRPC는 다양한 언어와 환경에서 사용할 수 있습니다.
    gRPC

    gRPC는 HTTP2를 통해 전달하고 와 Protocol Buffers(Protobuf)를 사용해서 데이터를 인코딩합니다. gRPC는 단일 사양을 가지고 있어서 모든 gRPC 구현의 일관성이 유지되도록 합니다.

    gRPC and Interchain

    인터체인 스택에서 gRPC는 TCP서버라고 볼 수 있습니다. 기본 포트는 9090

    gRPC-web

    gRPC는 다른 소프트웨어와 하드웨어 플랫폼을 지원합니다. gRPC-web은 자바스크립으로 구현된 브라우저 클라이언트를 위한 gRPC입니다. gRPC-web 클라이언트는 특별한 프록시를 통해서 gRPC서비스와 연결합니다.

    gRPC-gateway

    gRPC-gateway는 gRPC 엔드포인트를 REST 엔드포인트로 노출시키는 도구입니다. gRPC의 API를 RESTful 스타일로 제공하는 것과 gRPC 서비스의 정의를 읽고 RESTful JSON API를 gRPC로 변환할 수 있는 역방향 프록시 서버를 만드는 것을 지원합ㄴ디ㅏ.
    각각의 gRPC 엔드포인트는 Protobuf의 Query 서비스로 정의되는데 Cosmos SDK는 해당 REST 엔드포인트를 제공합니다.

    gRPC-gateway는 HTPP+ JSON 인터페이스를 gRPC 서비스로 제공하는 것이 목적입니다. 이를 통해서 개발자들은 gRPC의 모든 이점을 얻고 당신이 웹 어플리케이션을 개발하고 싶지만 브라우저가 HTTP2를 지원하지 않을 때에도 RESTful API의 유용함을 얻을 수 있습니다. 이는 이전 버전과 호환성, 다국어, 다중 클라이언트 지원을 보장합니다. (너무 번역투이긴한데 음 ㅎㅎ...)

    gRPC-Gateway

    Cosmos SDK에서 gRPC-gateway는 HTTP1.1서버를 제공합니다. 이 서버는 REST API와 데이터 인코딩을 위한 Protobuf를 사용합니다. 만약에 gRPC를 어플리케이션에서 사용할 수 없을 때 Cosmos SDK르 ㄹ사용하면 gRPC-Gateway를 통해서 REST 라우팅이 제공됩니다.

    Amino

    Amino는 객체 인코딩 specification입니다. Cosmos SDK에서 모든 모듈은 Amino codec을 사용하는데 이는 타입과 인터페이스를 직렬화하는데 도움을 줍니다. 일반적으로 Amino codec은 모듈의 도메인에 등록됩니다.

    한 파트 적는데 2시간 넘게 걸리네요.. 길지도 않고 제 생각을 많이 적어내지도 않았는데...