Intro

저번 회차에 이어 Cosmos Developer Portal의 Interchain Concepts 항목에 대한 내용입니다

해당 항목을 보면서 정리한 글을 작성했기 때문에, 직접 사용하면서 알게된 사실에 비해서는 잘못 인지하고 있는 부분이나디테일에서 모자란 부분이 있을 수 있습니다 🥲🥲

항상 정확한 사실을 위해서는 Cosmos Developer Portal에 들어가서 직접 확인하시는 것을 추천드립니다!

그럼 시작하겠습니다~ 🙇🏻

Cosmos SDK

Account.

Cosmos SDK에서 키는 keyring이라는 객체에 저장 및 관리됩니다.

Cosmos SDK에서 사용하는 디지털 Key 스키마는 Cosmos SDK 패키지 내부에서 구현되어 있습니다.

• secp256k1 : crypto/keys/secp256k1 경로의 SDK의 패키지에 구현 되어있으며, 가장 일반적이며 Bitcoin에 사용되는 것과 동일합니다.
• secp256r1 : crypto/keys/secp256r1 경로의 SDK의 패키지에 구현되어 있습니다.
• tm-ed25519 : crypto/keys/ed25519 경로의 SDK 패키지에 구현되어 있으며, 합의 유효성 검사에만 지원됩니다.

Account의 주소값은 ADR-28을 이용하여 공개 키를 기준으로 파생되며, Account가 사용될 떄 세가지 유형의 Context가 지정됩니다.

• AccAddress : 메시지를 보낸 일반 사용자
• ValAddress : 일반 Validator Operator
• ConsAddress : 합의에 참여하는 Validator Node

Transaction

Cosmos SDK에서 Transaction은 컨택스트를 정의하는 하나 이상의 메타데이터로 구성되며 모듈의 Protobuf를 통해 작동됩니다.

Transaction Object

Transaction Object에는 아래 메서드들이 포함되어 있습니다.

• GetMsgs : 트랜잭션 내부 목록을 불러오며 하나의 트랜잭션에는 여러개의 Message가 포함되어 있을 수 있습니다.

• ValidateBasic : ABCI 메시지에서 사용하며, 트랜잭션이 유효하지 않은지 확인하기 위해 사용되는 경량의 상태 비저장 검사를 수행하며, 트랜잭션이 올바른 수의 서명자에 의해 서명되고 수수료가 사용자의 최대값을 초과하지 않는지 확인합니다.

Signing Transaction

Cosmos SDK는 현재 다음 두 가지 방법으로 트랜잭션 서명을 허용합니다.

• SIGN_MODE_DIRECT: 가장 많이 사용되는 인터페이스이며, 권장되는 방법이라고 합니다.
• SIGN_MODE_LEGACY_AMINO_JSON: Tx인터페이스의 이전 버젼으로, 이 방법으로는 더 이상 사용하지 않는다고 합니다.

Broadcasting Transaction

트랜잭션이 생성되고 서명되면 트랜잭션을 브로드캐스팅하는 세 가지 기본 방법이 있습니다 .

• 명령줄 인터페이스(CLI) : CLI 명령을 이용하여 트랜잭션 처리의 모든 단계를 하나의 간단한 명령으로 묶어 사용합니다.

• gRPC를 사용 : gRPC의 주요 용도는 모듈 쿼리 서비스 컨텍스트이지만, Cosmos SDK는 모듈에 구애받지 않는 다른 gRPC 서비스도 노출하며 트랜잭션 브로드캐스팅은 그 중 하나입니다.

• REST 엔드포인트 사용 : gRPC를 사용하는 대신 HTTP를 사용하여 POST /cosmos/tx/v1beta1/txs엔드포인트에서 동일한 트랜잭션을 브로드캐스팅을 할 수도 있다고합니다.

Message

메시지는 Cosmos SDK의 모듈에서 처리하는 두 가지 기본 개체 중 하나입니다. 모듈에서 처리하는 다른 기본 개체는 쿼리입니다. 메시지는 상태를 알리고 변경할 가능성이 있지만 쿼리는 모듈 상태를 검사하고 항상 읽기 전용입니다.

Cosmos SDK에서 트랜잭션에는 하나 이상의 메시지가 포함됩니다 . 모듈은 트랜잭션이 합의 계층에 의해 블록에 포함된 후 메시지를 처리합니다.

Message & Transaction Lifecycle

하나 이상의 유효한 메세지를 포함하는 트랜잭션은 CometBFT에 의해 직렬화 및 확인되며 확인된 트랜잭션은 Cosmos SDK에 전달됩니다.

그 후 트랜잭션이 검증자에 의해 서명되고 합의 계층에 의해 블록에 포함된 후에만 메시지가 처리됩니다.

Protobuf

프로토콜 버퍼(Protobuf)는 네트워크 통신 및 저장을 위해 개체 데이터를 직렬화하는 오픈 소스, 확장 가능, 교차 플랫폼 및 언어에 구애받지 않는 방법입니다. 여러 언어용 라이브러리는 공통 인터페이스 설명 언어를 구문 분석하여 구조화된 데이터를 나타내는 바이트 스트림을 인코딩 및 디코딩하기 위한 소스 코드를 생성합니다.

Working with Protocol Buffers

먼저 .proto 파일에 데이터 구조를 정의합니다.

.proto는 설명 구문이 있는 일반 텍스트 파일이며, 데이터는 필드라고 불리는 name-value 값을 포함하는 메시지로 표현됩니다.

그 후 Protobof schema.protoc는 명령줄 옵션에 따라 설정된 언어로 각 필드에 대한 접근자와 함께 데이터 액세스 클래스를 생성합니다.

접근자에는 직렬화, 병렬화 및 구문 분석이 포함됩니다.

Types

코스모스 SDK 애플리케이션의 핵심은 주로 유형 정의와 생성자 기능으로 구성되며 app.go에 정의된 사용자 지정 애플리케이션의 유형 정의는 단순히 다음과 같은 구조로 구성됩니다

• Reference to BaseApp : BaseApp 참조는 애플리케이션에 대한 사용자 지정 애플리케이션 유형 임베딩 BaseApp을 정의합니다. BaseApp 참조를 사용하면 사용자 지정 애플리케이션이 ABCI Method 및 라우팅 로직과 같은 BaseApp의 핵심 로직 대부분을 상속할 수 있습니다.

• list of store keys: 코스모스 SDK의 각 모듈은 상태 일부를 유지하기 위해 멀티스토어를 사용합니다. 이러한 스토어에 액세스하려면 앱의 유형 정의에 선언된 키 목록이 필요합니다.

• list of each keepers: 키퍼는 각 모듈의 추상적인 조각으로 모듈의 스토어와의 상호 작용을 처리하고 다른 모듈의 키퍼에 대한 참조를 지정하며 모듈의 다른 핵심 기능을 구현합니다. 크로스 모듈 상호 작용이 작동하려면 코스모스 SDK의 모든 모듈이 애플리케이션의 유형 정의에 키퍼를 선언하고 다른 모듈에 대한 인터페이스로 내보내야 합니다. 이를 통해 한 모듈의 키퍼 방법을 권한이 있을 때 다른 모듈에서 호출하고 액세스할 수 있습니다.

• Reference to codec: 기본값은 go-amino이며, Cosmos SDK 응용 프로그램의 코덱은 바이트 슬라이스로 데이터 저장소를 유지하고 결정론적인 경우 다른 적절한 인코딩 프레임워크로 대체할 수 있습니다.

• Reference to the module manager : 모듈 관리자로 알려진 응용 모듈 목록을 포함하는 개체 참조

👍🏻 Protocol Buffers(ProtoBuf)에 대해 잘 기억이 안나신다면 이전 게시글을 참고해 주세요!

MultiStore & Keeper

애플리케이션별 블록체인의 Cosmos SDK 애플리케이션은 일반적으로 별도의 문제를 처리하는 여러 모듈로 구성됩니다.

Cosmos SDK는 개발자가 원치 않는 모듈 간 상호 작용으로부터 애플리케이션을 더 잘 보호할 수 있도록 개체 기능 기반 접근 방식을 채택합니다.

Keeper는 모듈에서 정의한 상태의 하위 집합에 대한 액세스를 관리하는 Cosmos SDK 추상화이며, 모듈의 데이터에 대한 모든 액세스는 모듈의 Keeper를 거쳐야 하므로 이 접근법의 핵심은 Keeper입니다.

키퍼는 모듈 저장소의 문자 그대로 게이트키퍼로 생각할 수 있습니다.

모듈이 다른 모듈에 정의된 상태와 상호 작용해야 하는 경우 다른 모듈 키퍼의 메서드와 상호 작용하여 수행합니다.

개발자는 메서드를 정의하고 액세스를 제어하여 해당 모듈이 다른 모듈과 가질 수 있는 상호 작용을 제어합니다.

Store Types

Cosmos SDK는 작업할 수 있는 다양한 스토어 유형을 제공합니다. 개발에 사용할 수 있는 다양한 Store 유형에 대한 좋은 개요를 얻는 것이 중요하다고 합니다!

KVStore & MuiltiStore in the interchain

각 Cosmos SDK 애플리케이션에는 Root인 Multistore에 상태가 포함되어 있습니다.

Multistore는 Multistore Interface를 따르는 Key-Value Store( KVStores )의 저장소이며, 기본 KVStore 및 Multistore 구현은 특수 동작을 제공하는 확장으로 래핑됩니다.

CommitMultistore는 커미터가 있는 다중 저장소이며, Cosmos SDK에서 사용되는 Multistore의 주요 유형입니다.

rootMulti.Store는 CommitMultiStore 인터페이스의 구현입니다. 여러 KVStore를 마운트할 수 있는 데이터베이스 주변에 구축된 기본 계층 다중 저장소이며, BaseApp에서 사용되는 기본 Multistore입니다.

Modules

모듈에는 노드들에 필요한 다음과 같은 핵심 기능들을 포함하고 있습니다.

• CometBFT와 통신하는 ABCI(Application Blockchain Interface)의 상용구 구현

• MultiStore라는 모듈 상태를 유지하는 범용 데이터 저장소

• 노드와의 상호 작용을 용이하게 하는 서버 및 인터페이스.

Module은 애플리케이션 로직의 대부분을 구현하는 반면, 코어는 배선 및 인프라 문제에 주의를 기울이고 모듈을 상위 모듈로 구성 가능합니다.

Module은 다음을 사용하여 전체 상태의 하위 집합을 정의합니다.

• KVStore라는 하나 이상의 키 또는 값 저장소

• 애플리케이션에 필요하지만 아직 존재하지 않는 메시지 유형의 하위 집합

모듈은 또한 이미 존재하는 다른 모듈과의 상호 작용을 정의합니다.

Module Component

폴더 내부에 모듈을 정의하는 방법이 권장되고 있으며, 모듈은 다음을 포함하는 여러 요소를 구현합니다

Interface

모듈은 애플리케이션의 나머지 부분과 호환되기 위해 다음과 같은 3개의 애플리케이션 모듈 인터페이스를 구현해야 합니다

• AppModuleBasic: 모듈의 비의존적 요소

• AppModule: 응용 프로그램에 고유한 모듈의 상호 의존적이고 전문화된 요소

• AppModuleGenesis: 시작 시 블록체인의 초기 상태를 설정하는 모듈의 상호의존적인 생성/초기화 요소

ProtoBuf

각 모듈은 두 가지 ProtoBuf를 정의합니다

• Msg: 메시지를 처리하기 위해 요청 유형의 Protob와 일대일로 관련된 RPC 메서드 집합

• Query: 쿼리를 처리하는 gRPC 쿼리 서비스

Keeper

모든 스토에 엑세스하기 위해서는 모듈의 Keeper를 거쳐야하며 Keeper는 스토어 내부의 스토리지 레이아웃에 대해 캡슐화, 업데이트 및 검사를 포함하므로 MVC(Model-View-Controller)패턴에 대한 지식이 있을 경우 좋다고 합니다.

Module_Folder

직렬화 가능한 데이터 유형 및 Protobuf 인터페이스 코드요소

proto
└── {project_name}
    └── {module_name}
        └── {proto_version}
            ├── {module_name}.proto
            ├── event.proto
            ├── genesis.proto
            ├── query.proto
            └── tx.proto

• {module_name}.proto: 모듈의 공통 메시지 유형 정의
• event.proto: 이벤트와 관련된 모듈의 메시지 유형 정의
• genesis.proto: 기원 상태와 관련된 모듈의 메시지 유형 정의
• query.protoQuery: 모듈의 서비스 및 관련 메시지 유형 정의
• tx.protoMsg: 모듈의 서비스 및 관련 메시지 유형 정의

나머지 코드 요소

x/{module_name}
├── client
│   ├── cli
│   │   ├── query.go
│   │   └── tx.go
│   └── testutil
│       ├── cli_test.go
│       └── suite.go
├── exported
│   └── exported.go
├── keeper
│   ├── genesis.go
│   ├── grpc_query.go
│   ├── hooks.go
│   ├── invariants.go
│   ├── keeper.go
│   ├── keys.go
│   ├── msg_server.go
│   └── querier.go
├── module
│   └── module.go
├── simulation
│   ├── decoder.go
│   ├── genesis.go
│   ├── operations.go
│   └── params.go
├── spec
│   ├── 01_concepts.md
│   ├── 02_state.md
│   ├── 03_messages.md
│   └── 04_events.md
├── {module_name}.pb.go
├── abci.go
├── codec.go
├── errors.go
├── events.go
├── events.pb.go
├── expected_keepers.go
├── genesis.go
├── genesis.pb.go
├── keys.go
├── msgs.go
├── params.go
├── query.pb.go
└── tx.pb.go

• client/: 모듈의 CLI 클라이언트 기능 구현 및 모듈의 통합 테스트
• exported/: 모듈의 export된 유형 - 일반적으로 인터페이스 유형
• keeper/: Keeper 및 Msg Server 모듈 및 구현.
• module/: AppModule 및 AppModuleBasic 모듈 및 구현.
• simulation/: 모듈의 시뮬레이션 패키지는 블록체인 시뮬레이터 애플리케이션(simapp)에서 사용되는 함수를 정의
• spec/: 중요한 개념, 상태 저장 구조, 메시지 및 이벤트 유형 정의를 요약한 모듈의 사양을 정리한 문서
• Root Directory에는 프로토콜 버퍼에서 생성한 유형 정의를 포함하여 메시지, 이벤트 및 제네시스 상태에 대한 유형 정의가 포함되어 있습니다
  • abci.go: 모듈의 BeginBlocker 및 EndBlocker 구현이며, 이 파일은 BeginBlocker 또는 EndBlocker를 정의해야 하는 경우에만 필요
  • codec.go: 인터페이스 유형에 대한 모듈의 레지스트리 메소드
  • errors.go: 모듈의 오류.
  • events.go: 모듈의 이벤트 유형 및 생성자.
  • expected_keepers.go: 모듈의 예상되는 다른 키퍼 인터페이스.
  • genesis.go: 모듈의 제네시스 상태 메서드 및 헬퍼 함수.
  • keys.go: 모듈의 저장 키 및 관련 도우미 기능.
  • msgs.go: 모듈의 메시지 유형 정의 및 관련 메소드.
  • params.go: 모듈의 매개변수 유형 정의 및 관련 메소드.
  • .pb.go.proto: 각 파일에 정의된 프로토콜 버퍼에 의해 생성된 모듈의 유형 정의 .

BaseApp

BaseApp은 Cosmos SDK 애플리케이션의 상용구 구현이며, 이 추상화는 CometBFT 애플리케이션 블록체인 인터페이스(ABCI)의 구현으로 시작하여 모든 인터체인 애플리케이션에 필요한 기능을 구현합니다.

CometBFT 합의에 의존하는 애플리케이션은 ABCI 인터페이스를 지원하는 구체적인 기능을 구현해야하지만, BaseApp에는 ABCI 구현이 포함되어 있으므로 개발자가 ABCI를 구성할 필요가 없습니다.

또한, BaseApp은 ABCI 구현뿐만 아니라 상태 시스템 구현도 제공합니다.

State Machine의 구현은 CometBFT 합의가 애플리케이션에 구애받지 않기 때문에 애플리케이션 수준의 문제입니다. Cosmos SDK State Machine 구현에는 다양한 하위 상태로 세분화되는 전체 상태가 포함됩니다. 세분에는 모듈 상태, 지속 상태 및 임시 상태가 포함됩니다.

이들은 모두 BaseApp에서 구현됩니다.

Query

Query는 애플리케이션의 최종 사용자가 인터페이스를 통해 만들고 전체 노드에서 처리하는 정보 요청입니다. 사용 가능한 정보는 다음과 같습니다.

• 네트워크에 대한 정보

• 응용 프로그램 자체에 대한 정보

• 애플리케이션 상태에 대한 정보

쿼리는 상태 전환을 트리거하지 않으므로 합의를 처리할 필요가 없습니다. 따라서 쿼리는 전체 노드에서 완전히 독립적으로 처리할 수 있다고 합니다.

Event

Event는 응용 프로그램 실행에 대한 정보를 포함하는 개체입니다. 이벤트는 블록 탐색기 및 지갑과 같은 서비스 공급자가 다양한 메시지 및 인덱스 트랜잭션의 실행을 추적하는 데 사용됩니다.

Context

Context에는 애플리케이션, 블록 및 트랜잭션의 현재 상태에 대한 정보가 포함되며, 트랜잭션이 실행되는 영역입니다.

컨텍스트는 응용 프로그램의 현재 상태에 대한 정보를 전달하는 데이터 구조로 표현되며 함수에서 함수로 전달됩니다. 컨텍스트는 블록 높이 및 합의 매개 변수와 같은 유용한 개체 및 정보뿐만 아니라 전체 상태의 안전한 분기인 분기된 저장소에 대한 액세스를 제공합니다.

컨텍스트는 모듈이 다중 저장소의 각 저장소에 쉽게 액세스하고 블록 헤더 및 가스 계량기와 같은 트랜잭션 컨텍스트를 검색할 수 있도록 하므로 트랜잭션 처리에 필수적입니다.

Bridge

Gravity Bridge

Gravity Bridge는 ERC-20 토큰을 Interchain 기반 블록체인으로 쉽게 이전하는 것을 목표로 현재 Althea에서 구축 중인 진행 중인 프로젝트입니다.

개발자는 이더리움 스마트 계약으로 수행하기에는 비용이 많이 들거나 불가능한 계산을 위해 코스모스 체인을 사용할 수 있습니다. 개발자는 이더리움 ERC-20 토큰을 지불로 수락하거나 이더리움 토큰을 중심으로 전체 인터체인 애플리케이션을 구축할 수 있습니다.

Gravity Bridge는 Cosmos Hub에서 실행되도록 설계되었으며, 최대한의 디자인 단순성과 효율성에 중점을 둡니다. Bridge는 이더리움에서 시작된 ERC-20 자산을 코스모스 기반 체인으로, 그리고 다시 이더리움으로 전송할 수 있습니다. 거래는 일괄 처리되며 이체는 제외됩니다. 이는 대규모 효율성을 창출하고 각 전송에 대한 트랜잭션 비용을 낮춥니다.

Migration

일반적으로 블록체인을 업그레이드할 때 모든 노드가 동일한 블록 높이에서 동시에 업그레이드되는 것이 중요하지만,무질서한 환경에서는 달성하기 어렵습니다.

노드가 조정되지 않으면 블록체인은 공통 기록을 가진 두 개의 블록체인으로 "포크"됩니다. 하나는 새 규칙을 준수하는 체인이고 다른 하나는 이전 규칙을 준수하는 체인입니다. 일반적으로는 이 두 체인이 미래에 공통 합의에 도달하거나 병합하는 것은 불가능합니다.

그러나 특정 애플리케이션용으로 구축된 코스모스 SDK 블록체인은 포크 없이 업그레이드 가능합니다.

블록체인 애플리케이션의 새 버전이 체인에 있는 것과 다른 데이터 레이아웃을 사용하는 경우 새 버전의 애플리케이션이 온라인 상태가 되기 전에 기존 데이터를 재구성할 수 있습니다.

데이터 마이그레이션은 개발자가 정의하며 노드가 서비스로 돌아가기 전에 각 노드에서 빠르고 효율적으로 실행된다고 합니다.

Adventage

업그레이드 이후 블록체인 애플리케이션 및 블록체인 플랫폼을 업데이트하는 프로세스를 실행하며 이러한 형태의 공동 업그레이드의 주요 이점은 다음과 같습니다.

• 분기 방지: 모든 유효성 검사기는 미리 결정된 블록 높이에서 함께 이동

• 바이너리 업그레이드: 새 소프트웨어는 자동화된 방식으로 채택

• 데이터 저장소 재구성: 블록 가스 한도와 같은 요인에 의해 제한되지 않는 프로세스에서 필요에 따라 미사용 데이터를 재구성 가능

Migration Process

Migration은 다음과 같은 단계로 이루어집니다.

Plan

향후 특정 블록 높이에서 수행되는 업그레이드 프로세스입니다. 여기에는 계획의 이름을 지정하고 실행할 블록 높이를 지정하는 업그레이드가 시작될 때 실행되는 SideCar 프로세스가 포함됩니다.

Side car

SideCar는 노드가 Cosmos 바이너리 외부의 프로세스에 참석하기 위해 실행할 수 있는 바이너리입니다. 여기에는 리포지토리의 특정 커밋에서 소프트웨어 다운로드 및 컴파일과 같은 단계가 포함될 수 있습니다.

Upgrade Handler

SideCar 프로세스가 완료되고 바이너리가 업그레이드된 후에 UpgradeHandler가 실행될 수 있습니다. 정상적인 처리가 재개되기 전에 필요할 수 있는 온체인 활동에 주의를 기울입니다. 업그레이드 핸들러는 StoreLoader를 트리거할 수 있습니다.

StoreLoader

StoreLoader는 새 바이너리에서 사용할 온체인 상태를 준비합니다. 여기에는 기존 데이터 재구성이 포함될 수 있습니다. 노드는 스토어 로더가 반환되고 핸들러가 작업을 완료할 때까지 정상 작동을 재개하지 않습니다.

Proposal

거버넌스는 투표를 통해 채택된 제안을 사용합니다. 업그레이드 제안은 거버넌스를 통해 준비 및 제출된 계획을 수락하거나 거부하는 형식을 취합니다. 취소 제안으로 실행 전에 제안을 철회할 수 있습니다.

Outro

Cosmos Developer Portal의 Interchain Concepts 항목에 대한 내용으로 전부는 아닙니다....

제가 읽으면서 나름 요약한 내용을 기준으로 작성하였고, 이 글을 통해 관심이 생기신다면 해당 페이지를 통해 직접 읽어 보시는걸 추천드립니다..

양이 너무 많다보니 하루에 다 보기에는 불가능에 가까웠고,,,, 그렇다고 며칠 뒤에 이어서 읽으니 죽을맛이었습니다......🥲🥲🤮

이제 어느정도 이론적인 부분은 읽었고, 앞으로는 실제로 개발을 진행해보면서 포스팅을 해보려고 합니다..!

긴 글 읽어주셔서 감사합니다~🙇🏻

Reference

• Gravity Bridge

• Cosmos Developer Portal