Cosmos Blockchain App Architecture (공식 홈 자료)

이 섹션에서는 코스모스 SDK로 구축된 블록체인의 기반이 되는 애플리케이션 아키텍처에 대해 자세히 살펴보겠습니다.

이 섹션에서는 코스모스 SDK로 구축된 블록체인의 기반이 되는 애플리케이션 아키텍처에 대해 더 깊이 이해할 수 있습니다. 살펴봅니다:

텐더민트란 무엇인가요?
코스모스의 합의
애플리케이션 블록체인 인터페이스
코스모스 SDK
상태 머신

 

텐더민트란 무엇인가요?

 

2014년에 만들어진 텐더민트(새 창에서 열기)는 기성 네트워킹 및 합의 솔루션으로 각기 다른 블록체인의 개발을 가속화하므로, 개발자는 새로운 사례마다 이러한 기능을 다시 만들 필요가 없습니다. 하이퍼레저 버로우(새 창에서 열기)와 바이낸스 체인(새 창에서 열기)과 같은 다른 블록체인이 텐더민트를 사용하므로, 이미 텐더민트를 인지하지 못한 채 사용하고 계실 수도 있습니다.

텐더민트 모듈은 모든 블록체인의 중요한 구성 요소인 합의와 네트워킹에 집중합니다. 이를 통해 개발자는 피어 검색, 블록 전파, 합의, 트랜잭션 확정과 같은 하위 수준의 블록체인 문제에 신경 쓰지 않고 애플리케이션 수준에 집중할 수 있습니다. 텐더민트가 없다면 개발자는 이러한 문제를 해결하기 위해 소프트웨어를 구축해야 하며, 이는 애플리케이션 개발에 추가적인 시간, 복잡성, 비용을 추가할 것입니다.

 

 

코스모스 공식 홈페이지 자료

 

 

애플리케이션 중심의 코스모스 블록체인을 위한 블록체인 노드는 코스모스 SDK로 구축된 상태 머신과 텐더민트 코어에서 처리하는 합의 및 네트워킹 레이어로 구성됩니다(새 창에서 열기).

 

텐더민트 코어는 모든 언어의 상태 머신을 지원하는 블록체인 애플리케이션 플랫폼입니다. 언어에 구애받지 않는 텐더민트 코어는 개발자가 결정론적 유한 상태 머신을 안전하고 일관되게 복제할 수 있도록 도와줍니다.

텐더민트 BFT는 두 가지 구성 요소를 제공하여 전체 머신의 1/3이 실패하더라도 유지됩니다:

블록체인 합의 엔진.
일반 애플리케이션 인터페이스.

코스모스 SDK의 이 유용한 구성 요소를 계속 살펴보고 싶으신가요? 텐더민트 코어와 코스모스의 합의 아래 또는 텐더민트 코어 문서(새 창에서 열기)에서 자세한 정보를 찾아보세요.

텐더민트 코어와 코스모스의 컨센서스

 

텐더민트 코어는 엄격한 포크 책임성을 갖춘 고성능, 일관성, 유연성, 보안성을 갖춘 합의 모듈입니다. 위임과 실용적인 비잔틴 내결함성(새 창에서 열기)을 갖춘 지분 증명(PoS)에 의존합니다. 참여자는 블록을 생성하고 확인하는 잘 작동하고 신뢰할 수 있는 노드에 대한 지지를 보냅니다. 사용자는 ATOM 또는 각 체인의 네이티브 토큰을 스테이킹하여 지지를 알립니다. 스테이킹은 네트워크 트랜잭션 수수료의 일부를 획득할 수 있는 가능성을 제공하지만, 지원 노드가 신뢰할 수 없게 될 경우 수익이 감소하거나 손실이 발생할 수 있는 위험도 수반합니다.

네트워크 참여자들은 신뢰할 수 있는 서비스를 제공할 가능성이 가장 높은 노드에 ATOM을 스테이킹하고, 이러한 조건이 변경될 경우 지지를 철회할 수 있는 인센티브를 받게 됩니다. 코스모스 블록체인은 검증자 구성을 조정하고 불리한 조건에서도 계속 운영될 것으로 예상됩니다.

스테이킹된 ATOM을 기준으로 상위 175개 노드만이 트랜잭션 확정 과정에 검증자로 참여합니다. 블록을 생성할 수 있는 권한은 검증자가 가진 투표력에 비례하여 부여됩니다. 투표권은 검증자와 그 위임자가 스테이킹한 모든 ATOM 토큰으로 계산됩니다. 예를 들어, 특정 검증인의 투표권이 모든 검증인의 총 투표권의 15%인 경우, 해당 검증인은 블록 생성 권한의 15%를 받을 것으로 예상할 수 있습니다.

생성된 블록은 다른 검증인에게 브로드캐스트되며, 다른 검증인은 신속하고 정확하게 응답해야 합니다:

검증자는 후보 블록을 확인합니다.
검증자는 후보 블록을 확인하지 않을 경우 페널티를 받습니다.
검증자는 유효하지 않은 블록을 거부할 수 있으며 반드시 거부해야 합니다.
검증자는 서명을 반환함으로써 블록을 승인합니다.

 

블록 생성자가 충분한 서명을 수집하면 블록이 최종 확정되어 더 넓은 네트워크에 브로드캐스트됩니다. 이 과정에는 모호함이 없습니다. 블록에 필요한 서명이 있을 수도 있고 없을 수도 있습니다. 서명이 충분하지 않은 경우, 블록을 뒤집기에는 서명자가 부족하므로 블록이 확정된 것으로 이해할 수 있으며, 블록체인이 재구성되는 과정은 없습니다. 이는 작업 증명(PoW)과 같은 확률적 시스템이 따라올 수 없는 수준의 트랜잭션 완결성을 제공합니다.

고성능을 목표로 하고 네트워크 연결성이 좋은 전용 검증자를 기반으로 하기 때문에 공격적인 블록 타임이 가능합니다. 이는 포용성을 선호하며 지연 시간이 길고 신뢰성이 낮은 느린 노드를 수용해야 하는 작업 증명과는 상당히 다릅니다. 코스모스 블록체인은 초당 수천 건의 트랜잭션을 처리할 수 있으며, 확인에는 7초가 소요됩니다.

검증은 모든 네트워크 노드의 하위 집합에 위임되지만, 이 프로세스는 권한 집중을 방지합니다. 사용자 커뮤니티는 ATOM을 스테이킹하고 커밋에 따른 보상과 위험에 모두 참여함으로써 검증자를 선출하여 신뢰할 수 있고 책임감 있는 블록 검증 서비스를 제공합니다.

 

 

 

체인의 업그레이드 가능성

알려진 모든 블록체인에서 구현을 변경하려면 각 노드에서 실행되는 노드 소프트웨어를 업그레이드해야 합니다. 자발적인 참여로 무질서하게 진행되는 과정에서는 하드 포크(하드 포크: 한 컨센서스가 기존 규칙을 고수하고 다른 컨센서스가 새로운 규칙을 채택하는 상황)가 발생할 수 있습니다. 이 방식은 긍정적인 측면과 지지자가 있는 반면, 확실성이 엄격하게 요구되는 환경에서는 분명한 단점도 있습니다. 예를 들어, 거래 완결성에 대한 불확실성(불확실성의 정도에 관계없이)은 권위 있는 등록 기관 및 대규모 자산과 관련된 환경에서는 허용되지 않을 수 있습니다.

텐더민트 블록체인에서는 트랜잭션이 블록 생성 시 비가역적으로 최종 확정되며, 업그레이드 역시 블록 생성 및 검증 프로세스에 의해 관리됩니다. 따라서 노드들이 동시에 프로토콜을 업그레이드하는 데 동의하거나 업그레이드 제안이 실패하는 등 불확실성의 여지가 없습니다.

검증자와 위임자는 제안에 투표하는 당사자이며, 각자의 지분에 비례하는 가중치를 갖습니다. 위임자가 제안에 투표하지 않으면 위임자의 투표는 위임된 검증자의 투표로 간주됩니다. 즉, 위임자는 자신의 기본 투표권을 검증인에게 빌려주는 것이기 때문에 행동할 때 매우 까다로워야 합니다.

 

 

애플리케이션 블록체인 인터페이스(ABCI)

텐더민트 BFT(새 창에서 열기)는 블록체인의 네트워킹과 합의 레이어를 패키징하고 애플리케이션 레이어인 애플리케이션 블록체인 인터페이스(ABCI)에 대한 인터페이스를 제공합니다. 개발자는 고차적인 문제에 집중하고 피어 검색, 검증자 선택, 스테이킹, 업그레이드, 합의를 텐더민트 BFT에 위임할 수 있습니다. 합의 엔진은 한 프로세스에서 실행되고 스테이트 머신을 제어하며, 애플리케이션은 다른 프로세스에서 실행됩니다. 이 아키텍처는 프라이빗 또는 퍼블릭 블록체인에 동일하게 적합합니다.

텐더민트 BFT 엔진은 소켓 프로토콜을 통해 애플리케이션에 연결됩니다. ABCI는 다른 언어로 작성된 애플리케이션을 위한 소켓을 제공합니다. 애플리케이션이 텐더민트 구현과 동일한 언어로 작성된 경우 소켓은 사용되지 않습니다.

 

텐더민트 BFT는 다음을 포함한 보안 보장을 제공합니다:

 

• 최소 절반 이상의 검증자가 정직하지 않은 경우 포크가 생성되지 않습니다.
• 포크 생성에 대한 엄격한 책임 규정을 통해 책임을 결정할 수 있습니다.
• 트랜잭션은 블록이 생성되는 즉시 확정됩니다.

 

텐더민트 BFT는 트랜잭션의 해석에 관여하지 않습니다. 이는 애플리케이션 레이어에서 발생합니다. 텐더민트는 확인되고 잘 형성된 트랜잭션과 트랜잭션 블록을 불가지론적으로 제시합니다. 텐더민트는 트랜잭션이 갖는 의미에 대해 의견을 제시하지 않습니다.

블록 생성 시간은 약 7초이며, 블록에는 수천 개의 트랜잭션이 포함될 수 있습니다. 트랜잭션은 확정되며 블록에 표시되는 즉시 되돌릴 수 없습니다.

 

합의와 텐더민트에 대해 자세히 알아보려면 여기를 방문하세요:

• Ethan Buchman과 함께하는 합의 시스템에 관한 팟캐스트(새 창에서 열기)를 확인하세요.
• 합의에 관한 텐더민트 코어 문서

블록체인을 사용하는 애플리케이션 수준의 문제에 대한 접근 방식은 크게 두 가지가 있습니다:

• 수행 가능한 모든 것이 프로토콜에 정의되어 있는 애플리케이션별 블록체인을 생성합니다.
  프로그래밍 가능한 상태 머신을 생성하고 상위 레벨 언어를 해석하는 컴파일러가 생성한 바이트코드와 같은 상위 레벨로 애플리케이션 문제를 푸시합니다.
  
  
• 이더리움과 유사한 블록체인은 두 번째 범주에 속하며, 컨트랙트 생성, 상호작용, 실행 규칙을 정의하는 온체인 프로토콜에는 스테이트 머신만 정의되어 있고 그 외에는 거의 정의되어 있지 않습니다.
  
  

이 방법들도 제한이 있는 것은 아닙니다.

• 토큰과 같은 기본적인 관심사에 대한 표준은 자발적인 참여를 통해 유기적으로 생겨나기 때문에 보편적으로 정의된 것은 거의 없습니다.
• 컨트랙트에는 개발자의 의도를 올바르게 구현할 수도 있고 그렇지 않을 수도 있는 반복적인 코드가 포함될 수 있으며 실제로도 있습니다.
• 이러한 고유한 유연성 때문에 무엇이 올바른지, 심지어 무엇이 우호적인지 추론하기가 어렵습니다.
• 작업의 복잡성에는 현실적인 한계가 있으며, 다른 환경에서 가능한 것과 비교하면 매우 낮습니다.

 

이러한 제한으로 인해 분석을 수행하거나 데이터를 재구성하기가 특히 어려우며, 개발자는 제약 조건에 적응해야 합니다.

특정 목적이나 애플리케이션에 특화된 블록체인은 다릅니다. 개발자가 만든 프로토콜로 애플리케이션 문제를 해결할 수 있기 때문에 "튜링 완전" 언어나 범용 프로그래밍 가능한 상태 머신을 제시할 필요가 없습니다.

이더리움 가상 머신(EVM) 기반 블록체인을 사용해본 개발자는 우려 사항을 해결하는 방식이 달라졌다는 것을 인지할 것입니다. 권한 부여와 액세스 제어, 스토리지와 상태의 레이아웃, 애플리케이션 거버넌스는 스테이트 머신에서 컨트랙트로 구현되지 않습니다. 대신 이러한 요소는 특정 목적을 위해 구축된 고유한 블록체인의 속성이 됩니다.

코스모스 SDK로 애플리케이션에 특화된 블록체인을 생성하는 것은 주로 잘 해결된 모듈을 선택, 구성, 통합하는 과정이며, 이를 "모듈 구성"이라고도 합니다. 이렇게 하면 개발이 애플리케이션의 진정으로 새로운 측면에 집중되므로 필요한 오리지널 개발의 범위가 크게 줄어듭니다.


블록체인 간 통신 프로토콜(IBC)은 블록체인 간 정보 교환을 위한 공통 프레임워크입니다. 지금은 이 프로토콜이 존재한다는 것만으로도 충분하며, 가치 전송(토큰 전송)과 정보 교환을 원하는 블록체인 간의 원활한 상호 작용을 가능하게 합니다. 이는 별도의 애플리케이션별 블록체인에서 실행되는 애플리케이션 간의 통신을 가능하게 합니다.

애플리케이션, 합의, 네트워크 레이어는 커스텀 블록체인의 기반을 형성하는 커스텀 블록체인 노드 내에 포함되어 있습니다.

상태 머신
블록체인의 핵심은 복제된 상태 기계입니다. 상태 머신은 컴퓨터 과학 개념으로, 기계는 여러 상태를 가질 수 있지만 한 번에 하나의 상태만 가질 수 있습니다. 상태 머신은 상태 전환 프로세스(또는 정의된 프로세스 집합)를 따르며, 이는 상태가 이전 상태 또는 초기 상태(S)에서 새로운 상태(S')로 변경되는 유일한 방법입니다.

 

블록체인의 상태 전환 기능은 트랜잭션과 동의어입니다. 초기 상태, 확인된 트랜잭션, 해당 트랜잭션을 해석하는 일련의 규칙이 주어지면 기계는 새로운 상태로 전환합니다. 해석 규칙은 애플리케이션 레이어에서 정의됩니다.

블록체인은 결정론적입니다. 트랜잭션에 대한 유일한 올바른 해석은 이전 이미지에서 S-프라임(S')으로 표시된 새 상태입니다.

블록체인은 분산되어 있으며 트랜잭션은 블록이라는 일괄 처리로 도착합니다. 머신 상태는 블록의 각 트랜잭션이 올바르게 해석된 후에 존재합니다. 각 트랜잭션은 모든 이전 트랜잭션의 결과인 상태 머신의 컨텍스트에서 실행됩니다. 모든 트랜잭션이 실행된 후의 머신 상태는 특히 기록 상태의 경우 유용한 체크포인트가 됩니다.

초기화된 블록체인의 상태, 즉 "아직 아무 일도 일어나지 않은" 상태를 제네시스 상태(S)라고 합니다. 블록체인의 현재 상태(S')는 항상 제네시스 상태에 수행된 모든 트랜잭션을 적용하여 얻을 수 있습니다.

 

개발자는 코스모스 SDK를 사용하여 스테이트 머신을 생성할 수 있습니다. 여기에는 다음이 포함됩니다:

• 스토리지 조직: 상태라고도 합니다.
• 상태 전환 기능: 트랜잭션으로 인해 허용되는 것과 상태 조정이 필요한지 여부를 결정합니다.
  
  이러한 맥락에서 "합의"는 잘 정렬된 트랜잭션을 포함하는 잘 정렬된 블록의 표준 집합을 설정합니다. 
  모든 노드는 표준 세트가 모든 확정된 트랜잭션의 유일한 관련 세트라는 데 동의합니다. 스테이트 머신의 결정론으로 인해 특정 트랜잭션 실행 또는 블록 높이에서 표준 트랜잭션 세트에 대한 올바른 해석은 단 하나뿐입니다.
  
  이 상태 머신 정의는 트랜잭션을 확인하고 전파하는 프로세스에 대해서는 침묵합니다. 텐더민트는 구성하는 블록의 해석에 구애받지 않습니다. 텐더민트 합의는 트랜잭션의 순서 집합을 설정합니다. 그런 다음 노드는 애플리케이션의 상태에 대한 합의에 도달합니다.

 

추가 세부 정보
트랜잭션과 블록은 몇 가지 주요 방법과 메시지 유형을 활용합니다:

 

CheckTx

브로드캐스트될 수 있는 많은 트랜잭션은 브로드캐스트되지 않아야 합니다. 예를 들면 잘못된 트랜잭션과 스팸과 유사한 아티팩트 등이 있습니다. 그러나 텐더민트는 트랜잭션에 대해 불가지론적이기 때문에 트랜잭션 해석을 결정할 수 없습니다. 이 문제를 해결하기 위해 애플리케이션 블록체인 인터페이스에는 CheckTx 메서드가 포함되어 있습니다. 텐더민트는 이 메서드를 사용하여 트랜잭션이 유효한지 애플리케이션 레이어에 묻습니다. 애플리케이션은 이 기능을 구현합니다.

DeliverTx

텐더민트는 블록 정보를 애플리케이션 레이어에 전달하여 해석 및 가능한 상태 머신 전환을 위해 DeliverTx 메서드를 호출합니다.

BeginBlock and EndBlock

블록에 트랜잭션이 포함되어 있지 않더라도 BeginBlock 및 EndBlock 메시지는 ABCI를 통해 전송됩니다. 이는 기본적인 연결성을 긍정적으로 확인하고 작업이 없는 기간을 식별하는 데 도움이 됩니다. 이러한 메서드는 개발자가 프로세스를 정의하는 애플리케이션 수준에서 메서드를 호출하기 때문에 항상 실행되어야 하는 예약된 프로세스의 실행을 용이하게 합니다.


블록은 약 7초 간격으로 도착하므로 각 블록의 시작 또는 완료 시 너무 많은 연산량을 추가하지 않도록 주의하는 것이 좋습니다. 너무 많은 작업을 수행하면 블록체인 속도가 느려질 수 있습니다.

합의를 위해 텐더민트를 사용하는 모든 애플리케이션은 ABCI를 구현해야 합니다. 코스모스 SDK는 베이스앱이라는 상용구를 제공하기 때문에 이 작업을 수동으로 수행할 필요는 없습니다.

다음 연습에서는 코스모스 SDK로 최소한의 분산 상태 머신을 생성하고 개념을 구현하는 코드 샘플을 점진적으로 살펴볼 것입니다. 여러분의 스테이트 머신은 합의를 위해 텐더민트에 의존할 것입니다.

출처: https://tutorials.cosmos.network/academy/2-cosmos-concepts/1-architecture.html

A Blockchain App Architecture | Developer Portal