Message,Modules를 읽어보시길 권합니다
Protobuf
Protobuf는 개발자들이 message 포멧을 설명(describe)하기 위한 데이터 직렬화 방법입니다. 인터체인 어플리케이션에는 많은 내부 의사소통 방법이 있습니다. Protobuf는 의사소통 방법의 핵심입니다.
.proto 파일은 message라고 부르는 데이터 구조를 포함하고 있습니다. 컴파일러는 protoc를 .proto file로 해석하고 지원하는 언어(C++, C#, Dart, Go, Java, and Python)의 소스코드로 생성합니다.
Working with Protocol Buffers
제일 먼저 .proto 파일 안에 데이터 구조를 정의해야 합니다. 데이터는 name-value 쌍의 메세지로 표현될 수 있습니다. 다음은 Protobuf 스키마를 컴파일 합니다. .protoc는 command-line 옵션으로 입력한 선호하는 언어의 accessors와 데이터 접근 객체를 생성합니다. Accessors는 직렬화, 역직렬화, parsing을 포함합니다.
gRPC
gRPC는 Protobuf를 사용해서 인터페이스 정의 언어와 메세지 포멧을 변환할 수 있습니다.
Mulistore and Keepers
Keepers는 모듈에 의해 정의된 상태에 접근하는 것을 관리합니다. States는 keeper를 통해서 접근될 수 있기 때문에 불변성과 보안 원칙이 적용됩니다.
Cosmos SDK 어플리케이션은 별도의 문제를 해결하기 위한 여러 모듈로 구성됩니다. 각 모듈은 전체 어플리케이션의 상태의 부분 집합의 상태를 가집니다. Cosmos SDK는 object-capabilites-based 접근을 통해서 개발자들이 더 좋은 어플리케이션을 개발할 수 있도록 합니다. Keeper는 이 방법의 핵심입니다.
Keeper를 통해서만 Module의 데이터에 접근할 수 있습니다.
키퍼는 말 그대로 모듈의 스토어에 대한 게이트키퍼라고 생각하면 됩니다. 모듈 내에 정의된 각 저장소(일반적으로 IAVL 저장소)에는 무제한 액세스 권한을 부여하는 storeKey가 제공됩니다. 모듈의 키퍼는 노출되지 않은 상태로 유지되어야 하는 이 storeKey를 보유하고 있으며, 모든 스토어에 대한 읽기 및 쓰기 메서드를 정의합니다.
모듈이 다른 모듈에 정의된 상태와 상호 작용해야 하는 경우 다른 모듈의 키퍼 메서드와 상호 작용하여 그렇게 합니다. 개발자는 메서드를 정의하고 액세스를 제어하여 모듈이 다른 모듈과 수행할 수 있는 상호작용을 제어합니다.
Format
keeper는 /keeper/keeper.go 파일에 정의됩니다. 모듈의 keeper 타입은 컨벤션에 따라 단순히 keeper.go로 이름을 정합니다.
type Keeper struct {
// Expected external keepers, if any
// Store key(s)
// codec
}
Keeper는 getter와 setter 메소드를 제공합니다. 이것들을 통해서 단순함과 엄격함을 유지합니다.
Store types
Cosmos SDK는 작업을 위한 다른 Store type을 제공합니다.개발할 수 있는 다른 Store type을 잘 파악하는 것이 중요합니다.
KVStore and Multistore in the Interchain
Cosmos SDK 어플리케이션은 루트에 Multistore 상태를 포함하고 있습니다. 이것은 어플리케이션의 각 모듈에 의해 관리되도록 세분화됩니다. Multistore은 Multistore interface를 따르는 KVStore의 저장소입니다.
AnteHandler
AnteHandler는 AnteHandler 인터페이스로 구현되는 중요한 handler입니다. 이것은 트랜젝션의 내부 메세지가 처리되기 전에 트렌젝션을 인정하는데 사용됩니다.사용은 선택이지만 3가지 목적에서 Public blockchain network에서 중요한 컴포넌트입니다.
-
스팸과 수수료 차감 및 시퀀스 확인을 통한 트랜젝션의 반복을 막습니다.
-
서명이 유효한지, 송신자가 충분한 요금을 가지고 있는지와 같은 상태 정보를 확인합니다.
-
트랜젝션 요금과 같은 stakeholder의 인센티브 역할을 합니다.
BaseApp은 어플리케이션 생성자가 초기화될 때 AnteHandler를 파라미터로 받습니다. 이것이 AnteHandler가 인증 모듈로 사용되는 이유입니다.
BaseApp
어플리케이션 상태 머신과 서비스 라우터를 정의하는 방법, 어떻게 커스텀 트랜젝션 처리를 하는지, 블록의 시작이나 끝에서 주기적으로 실행되는 프로세스를 만드는 방법을 알아봅시다.
BaseApp은 CosmosSDK 어플리케이션의 보일러 플레이트입니다. 이 추상화는 인터체인 어플리케이션이 필요로 하는 기능을 구현하고, CometBFT의 ABCI(Application Blockchain Interface)를 구현부터 시작합니다. CometBFT를 사용하는 어플리케이션은 반드시 ABCI 인터페이스를 지원하는 함수를 만들어야합니다. BaseApp은 ABCI의 구현을 포함하고 있어서 개발자들이 구축할 필요가 없습니다.
ABCI는 DeliverTx와 같이 트랜젝션을 전달하는 메소드를 포함하고 있습니다. 트랜젝션의 해석은 어플리케이션 레벨이 해야합니다. 일반적인 어플리케이션은 하나 이상의 트랜잭션 유형을 존재합니다. 이는 트랜젝션 유형에 따라서 해석을 지원하는 곳으로 전송하는 서비스 라우터가 필요하다는 것을 의미합니다. BaseApp은 해석을 위한 서비스 라우터 구현을 포함합니다.
BaseApp은 어플리케이션, 블록체인, 상태 머신에 따른 보안 인터페이스를 제공하면서 가능한 상태머신을 작게 정의합니다.Defining an application
개발자들은 일반적으로 BaseApp, store key, module manager, keeper를 이용해서 어플리케이션을 커스텀합니다.
type App struct { // reference to a BaseApp *baseapp.BaseApp // list of application store keys // list of application keepers // module manager }
BaseApp으로 어플리케이션을 확장하면 이전 BaseApp의 모든 메소드에도 접근할 수 있습니다. 개발자들은 그들이 원하는 모듈과 어플리케이션을 구성합니다. 그 때 ABCI, 서비스 라우터, 상태 관리 로직을 구현 하기 위해서 심혈을 기울이지 않아도 괜찮습니다.
[Parameters for Bootstrapp](https://ida.interchain.io/academy/2-cosmos-concepts/8-base-app.html#bootstrapping)
BaseApp을 사용할 때 optional한 파라미터들의 대한 설명은 위 링크에 있습니다.