애플리케이션 체인 이론: 코스모스 생태계가 번성하는 이유는 무엇입니까?

원본: https://rainandcoffee.substack.com/p/the-application-specific-chain-thesis?utm_source=%2Fprofile%2F14239335-rainandcoffee&utm_medium=reader2

저자: RainandCoffee

지난 몇 주 동안 애플리케이션과 빌더가 자체 애플리케이션별 체인을 구축하기로 결정했거나 그렇게 하는 데 관심을 표명하면서 더 넓은 Cosmos 생태계에서 부활을 보았습니다. 이것은 더 넓은 IBC 생태계에 약간의 영향을 미쳤던 Terra 생태계의 종말을 따릅니다. 그러나 전체 스택이 기술적으로 매우 잘 수행된다는 점에 유의하는 것이 중요하다고 생각합니다. 매우 변동성이 큰 거래량에도 불구하고 IBC를 통한 체인 간 내부 및 외부 메시지 및 자산 전송을 처리할 수 있을 뿐만 아니라 Tendermint, ABCI 및 맞춤형 VM이 포함된 Cosmos SDK를 통한 내부 체인에서도 처리할 수 있습니다. 이 기사에서 우리는 응용 프로그램별 블록체인의 등장 뒤에 있는 주장과 블록체인이 가져오는 주권, 구성 가능성 및 상호 운용성이 다가오는 주기에 다음 "킬러 앱" 및 생태계를 구축하는 데 중요한 이유를 설명하는 것을 목표로 합니다.시스템이 중요합니다.

이 주제를 다루기 전에 합의가 필요하므로 코스모스 생태계의 독특한 기술 몇 가지를 이해하기 쉽게 간략하게 소개합니다.

ABCI와 Cosmos SDK를 사용하는 Tendermint 기반 체인의 전체 아키텍처는 다음과 같습니다.

코스모스 SDK

Cosmos SDK는 블록체인 개발자가 VM에 구애받지 않는 방식으로 애플리케이션 계층 로직을 구축할 수 있는 모듈식 도구 세트입니다. Cosmos SDK는 ABCI를 통해 Tendermint와 인터페이스하도록 설계되었습니다. 애플리케이션별 블록체인을 생성할 수 있는 프레임워크일 뿐만 아니라 프로토콜에 구애받지 않는 거버넌스, 트랜잭션 및 스테이킹 메커니즘 등과 같은 다양한 사용자 지정 옵션도 허용합니다. SDK는 애플리케이션 논리 계층에서 필요한 대부분의 작업을 처리하므로 개발자가 처음부터 완전히 빌드할 필요가 없습니다. 라우터를 통해 Tendermint 합의 엔진에서 받은 트랜잭션을 처리하고 상태 변경과 함께 메시지를 적절한 처리 모듈로 보냅니다.

ABCI

ABCI는 블록체인의 애플리케이션 부분과 합의 및 네트워크 메커니즘을 제공하는 Tendermint 상태 복제 엔진을 연결하는 인터페이스입니다. ABCI는 블록체인 스택의 분할을 실현합니다. 즉, 블록체인 애플리케이션 부분이 가상 머신과 독립적일 수 있으므로 모든 가상 머신과 실행 환경을 스택의 애플리케이션 부분에 사용할 수 있습니다. 예를 들면 Junowasm, Cosmwasm, Agoric's Hardened Javascript, Cosmwasm의 Secret 버전(TEE 사용 가능) 등이 있습니다. Tendermint 자체는 mempool이 브로드캐스트할 때 트랜잭션 확인, 애플리케이션과 합의 엔진 간의 연결, 블록 제안에 사용하고 애플리케이션 상태를 쿼리하는 기능을 담당하는 애플리케이션 부분에 대한 3개의 ABCI 연결을 생성합니다.

텐더민트

Tendermint Core는 Cosmos 생태계에서 체인의 합의 및 네트워크 계층을 담당합니다. 합의 계층은 네트워크 참여자 간의 합의 알고리즘 프로세스를 통해 거래의 유효성과 순서를 보장하는 것으로, 네트워크 계층은 시스템 내 노드 간 점대점 통신을 용이하게 하고 타사 애플리케이션과 노드가 상호 작용할 수 있도록 하는 역할을 합니다. 합의 계층.

Tendermint는 BFT(Byzantine Fault Tolerant) 합의 모델을 사용하고 즉각적인 완결성을 달성합니다. BFT 프로세스는 제안된 블록의 최종 커밋 단계 전에 세 단계를 거칩니다. 세 단계는 다음과 같습니다.

• 제안 단계에서 블록은 특정 높이로 지정됩니다.
• 사전 투표 단계에서 검증자의 2/3가 제안된 블록에 사전 투표합니다.
• pre-commit 단계에서는 검증자의 2/3가 제안된 블록을 pre-commit합니다.

IBC

IBC( Inter-Blockchain Communication)의 핵심은 동종 블록체인을 위한 교차 체인 정보 전송 프로토콜입니다. 이것은 유사한 기능을 공유하는 체인을 연결한다는 것을 의미합니다. 이 경우 Tendermint 합의 알고리즘과 가벼운 클라이언트 기능이 있는 체인이 제공하는 즉각적인 완결성입니다. IBC가 작동하는 방식은 서로 연결하는 데 관심이 있는 두 개의 체인이 대상 체인에 대한 거버넌스를 제안하는 것입니다. 이것은 일반적으로 Cosmos Hub 또는 Osmosis를 통해 이루어집니다(현재 Osmosis는 45개를 연결하고 Cosmos는 40개를 연결합니다). 즉, 프로토콜 수준에서 합의가 있으므로 외부 브리지에서 신뢰할 수 있는 제3자를 사용할 필요가 없습니다.

그런 다음 두 체인은 두 체인 간의 합의 상태를 암호화 방식으로 확인하기 위해 서로의 체인에 라이트 클라이언트가 필요하고 두 체인의 라이트 클라이언트 간에 정보를 전달하기 위해 리피터가 필요합니다. 노드 간에 정보를 교환하고 노드가 성공적으로 합의에 도달하려면 활동에 릴레이가 필요합니다. 실제 상황을 살펴보겠습니다.

이것은 신뢰 가정이 블록체인을 연결하는 두 검증자에 있다는 것을 의미하므로 신뢰 가정은 다른 유형의 교차 체인 브리지 및 메시징 프로토콜보다 훨씬 적습니다. 예를 들어 Polkadot 생태계의 XCMP에서 신뢰 가정은 릴레이 체인(Polkadot)에만 있습니다.

Cosmos 생태계에서 IBC의 호환성과 퍼베이시브, 그리고 연결된 체인 수를 보여주기 위해 현재 실시간 연결 규모를 살펴보겠습니다.

ICS

ICS는 Interchain Standard의 약자로 IBC에서 발생하는 체인간 트랜잭션 설정 파라미터를 사용합니다. ICS는 기본적으로 IBC 트랜잭션을 위한 모듈 사양이며 두 체인이 IBC를 사용하려면 동일한 ICS를 가져야 합니다.

흥미롭고 독특한 ICS 중 하나는 인터체인 계정으로도 알려진 ICS-27입니다.

ICS-27

인터체인 계정은 구성 가능성, 즉 상호 운용성을 가능하게 합니다. 이를 통해 체인에 있는 사람들은 데이터를 교환할 수 있을 뿐만 아니라 한 체인의 스마트 계약에서 다른 체인으로 상태를 쓸 수 있습니다. 이는 자산이나 메시지가 전송될 때 다양한 인터페이스 사이를 이동할 필요 없이 사용자가 트랜잭션의 끝점을 지정하기만 하면 소스 체인의 단일 인터페이스를 활용할 수 있음을 의미합니다. ICS-27 지원 체인은 다른 ICS-27 지원 체인에 계정을 만들고 IBC 트랜잭션을 통해 해당 계정을 제어할 수 있습니다. 인터체인 계정은 일반 계정의 모든 기능을 유지하지만 IBC를 통해 별도의 체인 또는 최종 사용자가 운영하므로 소스 체인의 소유자가 대상 체인에 등록한 모든 크로스체인 계정에 대한 완전한 제어를 유지합니다.

IBC 트랜잭션 이후의 절차는 각 체인이 가져야 하는 ICS 사양에 따라 진행됩니다. 즉, 트랜잭션이 응용 프로그램별에서 응용 프로그램 독립적으로 이동할 수 있습니다. 즉, 다양한 네트워크에서 진정한 결합성을 가능하게 합니다.

인터체인 보안

체인 간 보안을 통해 하나의 체인 또는 허브가 다른 체인에 대한 블록을 생성할 수 있습니다. 유효성 검사기는 각 체인에서 하나씩 두 개(또는 그 이상)의 노드를 실행하지만 기본 토큰만 메인 체인에 스테이킹하면 됩니다. 이는 IBC 수준의 프로토콜인 교차 체인 검증을 통해 가능합니다. 서브체인은 IBC를 사용하여 메인체인과 통신하여 크로스체인 검증을 사용하여 어떤 검증인이 인터체인 보안에 참여하고 있는지 추적합니다. 이런 식으로 메인 체인에 잠긴 값에서 얻은 보안은 차일드 체인과 공유됩니다. 따라서 소비자/서브체인은 자체 검증자를 설정하지 않고도 메인체인에서 보안을 확보합니다. 이를 통해 자본 부담이 적은 애플리케이션이 기존 유효성 검사기의 강력한 보안 수준을 유지하면서 자체 체인을 쉽게 스핀업할 수 있습니다.

메인 체인은 일련의 하위 체인에 대한 블록 생성을 담당하고 검증자는 검증하는 체인에서 스테이킹 보상을 받으며 슬래싱은 검증자가 악의적인 일을 하지 않도록 방지합니다.

요약하다

애플리케이션별 블록체인은 우리가 블록 공간의 "저장소"라고 부르는 것을 가능하게 합니다. 블록체인 스택을 공급망으로 생각하면 스택의 각 부분에 대한 블록 공간은 스택이 있는 체인/계층의 애플리케이션에서 기술적으로 "구매"합니다. 이것은 동일한 블록 공간에 상주하는 가스에 대해 지불하는 수많은 다른 응용 프로그램에 합류하여 매우 혼잡하고 경쟁이 치열해져 수수료가 상승한다는 것을 의미합니다.

수천 개의 애플리케이션이 거주하는 매우 혼잡한 모놀리식 체인으로 인해 발생하는 이러한 수수료 급증은 무거운 비용을 부담해야 하는 사용자에게 푸시됩니다. 이것의 좋은 예는 애플리케이션 자체가 주어진 애플리케이션 체인에서 최종 사용자가 지불하는 수수료를 더 잘 제어하고 일정한 수준으로 유지할 수 있는 기능을 제공할 수 있는 Osmosis입니다.

그러한 애플리케이션은 창고로서 체인 X 또는 Y에 의존하지 않기 때문에 이는 매장의 재고 위험과 유사하게 애플리케이션에 대한 더 높은 평균 수수료의 위험을 감수한다는 것을 의미합니다. 즉, 애플리케이션 자체와 확장된 커뮤니티가 인벤토리 위험에 참여하고 관리할 수 있습니다. 이는 리소스 가격 책정의 효율성으로 이어지며, 이는 응용 프로그램의 경제성을 향상시킵니다.

애플리케이션이 상주하는 체인의 소유자이기 때문에 수수료 구조를 자체적으로 관리할 수 있습니다. 즉, 더 이상 상주하는 체인의 영향을 받지 않고 체인의 각 리소스 비용을 결정할 수 있습니다.

이 외에도 기본 기술 스택이 허용하는 유연성은 응용 프로그램 계층에서 최적화를 허용하는 동시에 기본 크로스 체인 메시징 시스템으로 인해 더 큰 생태계의 체인 간 구성 가능성을 유지하면서 구성 가능성에 타사 신뢰가 전혀 필요하지 않습니다. .

Cosmos가 널리 보급되기 전에는 애플리케이션과 인프라(체인) 사이에 명확한 격차가 있었고 IBC가 포함된 특정 애플리케이션 체인은 이 장벽을 허물고 애플리케이션이 연결되고 구성 가능한 인프라가 되도록 할 것입니다.