영어를 완전히 한국어로 대체하기 어려울 것 같은건 그냥 단어 자체를 적습니다. 나름 문맥에 맞게 생각해서 적습니다. 이상하면 본문을 읽어보세요!
하나씩 하면 시간이 너무 끌려서 요약해서 정리합니다. 본문 링크 남기니까 궁금하면 본문 읽으시는걸 추천드립니다.
사실말로만이렇다저렇다이론이야기가너무길어져서저도힘들고뭔소린지도모르겠어서생략하는것들이많아요.Week2부터실습이니그냥그럽갑다하고넘어갑시다
Transactions
트랜젝션은 어플리케이션의 상태 변화를 위해서 end-user가 트리거로 사용하는 객체입니다. 트랜젝션은 컨택스트를 정의하는 메타데이터와 Protobuf 메시지 서비스를 통해서 모듈에서 상태를 변화시키기 위한 트리거로 구성됩니다.
Transaction process from an end-user perspective
스택에 대해 알기 전에 트랜젝션 프로세스를 알아봅시다.
Decide
Decide는 트렌젝션에 메세지를 포함시킵니다. 이것은 일반적으로 지갑이나 어플리케이션이 지원하거나 사용자 인터페이스로 이루어집니다.
Sign
트랜젝션에 서명합니다. 트랜젝션은 검증자(validator)가 블록에 포함하기 전에 반드시 서명(Sign)해야합니다.
Generate
Cosmos SDK의 TxBuilder를 사용해서 트랜젝션을 생성(Generate)합니다.
Broadcast
서명된 트렌젝션을 사용가능한 인터페이스를 통해서 Broadcast합니다.
Decide와 Sign은 사용자의 주요 상호작용입니다. Generate와 Broadcast는 사용자 인터페이스나 다른 자동화를 통해서 처리됩니다.
Transaction objects
Transaction 객체는 Cosmos SDK의 Tx인터페이스로 구현되는 타입입니다.
그러나 아마도 Tx 객체를 직접적으로 사용할 일을 드물 겁니다. 이것은 트랜젝션을 생성하기 위해서 사용하는 중간 단계 타입입니다. 개발자들은 일반적으로 Txbuilder 인터페이스를 사용합니다.
Messages
트랜젝션 메세지는 CometBFT와 application layers의 상호작용을 정의하는 ABCI 메세지와 혼동해서는 안됩니다.
Message는 Cosmos SDK의 모듈에 의해 관리되는 두가지 중요한 객체 중 하나입니다. 다른 하나는 Qeuries입니다. Message는 모듈의 상태를 만들고 그것을 바꿀 수 있는 반면에 Qeuries는 모듈의 상태를 관찰하고 오직 읽을 수만 있습니다.
CosmosSDK에서 트랜젝션은 한가지 이상의 메세지를 포함합니다. 모듈은 트랜젝션이 합의 계층으로 블럭에 포함된 후에 메세지를 처리합니다.
Message and the transaction lifecycle
트랜젝션이 블록에 포함되고 나면 그것은 체인에서 취소하거나 다시 생성할 수 없습니다. 체인과 블럭은 확정되면 결정되고 수정이 불가능하기 때문입니다. 확인된 트랜젝션은 Cosmos SDK 어플리케이션에 전달됩니다. 각각의 메세지는 BaseAppd의 MsgServiceRouter를 이용해서 적절한 모듈에 라우팅됩니다.
MsgService
기술적으로 MsgService를 만드는 것도 가능하지만 권장하는 방법은 Protobuf Msg 서비스를 정의하는 것입니다. 각 모듈은 tx.proto에서 Protobuf Msg메세지 서비스를 가지고 있습니다. 그리고 RPC서비스는 모듈의 각 메세지 유형에 해당하는 메소드를 가지고 있습니다. Protobuf 메세지는 모듈의 프로세스를 변경하는 인터페이스 계층을 암시적으로 정의합니다.
// Msg defines the bank Msg service.
service Msg {
// Send defines a method for sending coins from one account to another account.
rpc Send(MsgSend) returns (MsgSendResponse);
// MultiSend defines a method for sending coins from some accounts to other accounts.
rpc MultiSend(MsgMultiSend) returns (MsgMultiSendResponse);
}
*Each Msg service method has exactly one argument, such as MsgSend, which must implement the sdk.Msg interface and a Protobuf response.
*The standard naming convention is to call the RPC argument Msg<service-rpc-name> and the RPC response Msg<service-rpc-name>Response.(코드봐도 설명 이해 안가서 생략함.)
Client and server code generation
Cosmos SDK는 Protobuf 정의를 사용해서 클라이언트와 서버 코드를 생성합니다.
- The MsgServer interface defines the server API for the Msg service. Its implementation is described in the Msg services documentation
- Structures are generated for all RPC requests and response types.
Module
모듈은 토큰 관리나 거버넌스와 같은 애플리케이션 수준의 문제를 해결하는 기능적 구성 요소입니다. 코스모스 SDK에는 애플리케이션 개발자가 애플리케이션의 고유한 측면에 집중할 수 있도록 몇 가지 기성 모듈이 포함되어 있습니다.
코스모스 SDK 모듈은 각 체인의 고유한 속성을 정의합니다. 모듈은 더 큰 스테이트 머신 내의 스테이트 머신으로 간주할 수 있습니다. 모듈에는 스토리지 레이아웃, 즉 상태와 메시지 메서드인 상태 전환 함수가 포함되어 있습니다.
트랜젝션이 CometBFT 합의 엔진으로부터 각 노드 어플리케이션에 전달받되면, 노드의 BaseApp은 트랜젝션에 포함된 MEssages를 분해하고 적절한 모듈로 전달합니다. 모듈이 Message를 받고 메세지를 처리할 때 해석과 실행이 진행됩니다.
모듈은 모든 블록체인 노드가 필요로하는 핵심 기능을 포함하고 있습니다.
-
CometBFT를 통한 communication를 가능하게 하는 어플리케이션 블록체인 인터페이스 (Application Blockchain Interface - ABCI)의 보일러 플레이트
-
multistore라고 불리는 모듈 상태를 유지하는 범용 데이터 저장소
-
노드끼리 상호작용할 수 있도록 하는 서버와 인터페이스
코어가 wiring 및 인프라 문제를 처리하는 동안 모듈은 대부분의 애플리케이션 로직을 구현하고 모듈을 상위 모듈로 구성할 수 있습니다.
모듈은 다음을 사용하여 전체 상태의 하위 집합을 정의합니다:
- 하나 이상의 키 또는 값 저장소(KVStore라고 함).
- 애플리케이션에 필요하지만 아직 존재하지 않는 메시지 유형의 하위 집합.
모듈은 이미 존재하는 다른 모듈과의 상호 작용도 정의합니다.
Modul components
모듈은 x/moduleName 폴더에 정의하는 것이 가장 좋습니다. 예를 들어 Checkers라는 모듈은 x/checkers에 들어갑니다. Cosmos SDK의 기본 코드도 x/ 폴더에 정의되어 있습니다.
모듈은 Interface, Protobuf, Keeper를 구현합니다.
Interfaces
모듈은 어플리케이션의 다른 부분과 통합되기 위해서 반드시 3가지의 인터페이스가 구현되어야 합니다.
-
AppModulBasic : 모듈의 의존적이지 않은 요소를 구현
-
AppModule : 어플리케이션의 고유성을 지니는 모듈의 상호 의존적이고 특화된 요소
-
AppModulGenesis : 블록체인의 초기 상태를 설정하는 상호 의존적인 초기 요소
모듈의 x/moduleName/module.go 파일에서 앱 모듈과 앱 모듈 베이직, 그리고 함수를 정의합니다.
Protobuf services
각 모듈은 두가지 Protobuf services를 정의합니다.
-
Msg : 메세지를 처리하고 Protobuf request 유형과 one-to-one으로 연결된 RPC 집합
-
Query : query들을 처리하기 위한 gRPC query 서비스
Msg service
Keep in mind:
-
tx.proto 파일에 Msg Protobuf service를 정의하는 것이 best!
-
각각의 모듈은 AppModule 인터페이스의 RegisterServices메소드로 구현되어야 합니다. 이것을 통해 어플리케이션은 messages와 queries가 모듈이 처리할 수 있다는 것을 알 수 있습니다.
-
Service 메소드는 keeper를 사용해야합니다. keeper는 storage layout에 대한 지식을 캡슐화하고 상태 업에티르 방법을 제시합니다.
gRPC Query service
Keep in mind:
-
query.proto 파일에 Query Protobuf 서비스를 정의하는 것이 best 입니다
-
사용자들이 gRPC를 사용해서 상태를 query할 수 있게 합니다. (It allows users to query the state using gRPC.
) -
각 gRPC 엔드포인트는 서비스 메서드에 해당하며, gRPC 쿼리 서비스 내에서 접두사 rpc로 이름이 지정됩니다.
-
app.toml의 grpc.enable과 grpc.address 필드에서 구성됩니다.
Protobuf는 각 모듈의 서비스 메소드를 포함하는 QueryServer 인터페이스를 생성합니다. 모듈은 별도의 파일에 서비스 메소드의 구현을 맡김으로써 QueryServer 인터페이스를 구현합니다. 이러한 구현 메소드는 gRPC 쿼리 엔드포인트의 핸들러가 입니다. 다른 파일에 염려를 나누면 Protobuf의 파일 재생성으로부터 안전해집니다.
Command-line commands
각 모듈은 CLI 명령어를 정의할 수 있습니다. 명령어는 cliend/cli라고 명명된 폴더에서 정의된 모듈과 연관되어있습니다. CLI는 두 카테고리로 명령어를 구분할 수 있습니다. : transactions and queries.
tx.go and query.go에 정의된 것과 동일합니다.Keeper
Keeper는 모듈의 저장소의 gatekeeper입니다.모듈의 keepter를 통해서 저장소에 접근하는 것은 필수적입니다. keeper는 저장소의 storage layout에 대한 정보를 캡슐화하고 이를 업데이트하는 메소드를 포함하고 있습니다. module-view-controller(MVC)에 익숙하다면 keeper를 controller라고 생각해도 괜찮습니다.
어떤 모듈이 저장소에 접근하려고 할 때, 그 모듈이 악의적일 가능적이 있습니다. 이러한 이유로 개발자는 누가, 무엇이 모듈의 저장소에 접근하려고 하는지 고려해야합니다. 모듈이 런타임중에 다른 모듈에 무작위로 접근하는 것을 예방하기 위해서 모듈은 생성할 때 어떤 어뮬을 사용할지 선언해야 합니다. 이런 부분에서 다른 모듈에 접근할 수 있는 런타임 키가 부여됩니다. 오직 이 키를 가진 모듈만 저장소에 접근할 수 있습니다. 이것을 object-capability model이라고 합니다.Core modules
Cosmos SDK는 일반적인 문제를 잘 해결한 Core module이 있습니다. Core module은 Tokens,staking,goveranace와 같은 것을 포함합니다.
코어 모듈은 ad-hoc 솔루션에 비해 몇 가지 장점이 있습니다:
-
표준화가 초기에 되어서 지갑, 분석, 다른 모듈, 다른 Cosmos 어플리케이션과의 상호 운영성을 잘 확보햇습니다.
-
중복되는 노력을 효과적으로 줄였습니다. 어플리케이션 개발잗르이 그들의 어플리케이션의 고유성에 집중하기 때문입니다.
-
코어 모듈은 잘 작동하는 Cosmos SDK 모듈의 예시입니다. Cosmos SDK 모듈은 구조,스타일, 모범 사례의 좋은 사례가 됩니다.
개발자는 처음에 코어 모듈을 잘 고르고 결합하여 그들의 로직를 구현하여 일관적인 어플리케이션을 만들 수 있습니다.
Query
Query는 정보를 요청하는 것입니다. 이것은 어플리케이션의 엔드유저가 인터페이스를 통해서 만들고 모든 노드가 처리합니다.
-
네트워크에 대한 정보
-
어플리케이션에 대한 정보
-
어플리케이션의 상태에 관한 정보
3가지 유형의 정보를 찾을 수 있습니다.Query는 합의를 필요로 하지 않습니다.그러므로 모든 노드에서 독립적으로 Query를 처리할 수 있습니다.
-
