검수요청.png검수요청.png

크로미아

위키원
이동: 둘러보기, 검색
크로미아(Chromia)
크로미아(Chromia)
크로마웨이(ChromaWay)
헨릭 옐테(Henrik Hjelte)

크로미아(Chromia)는 디앱(DApp)의 확장성 문제를 해결하기 위한 블록체인 플랫폼 암호화폐이다. 이전에는 크로마폴리스(Chromapolis)라고 불렸다. 관계형 블록체인 네트워크로 구성되며, 기본 유틸리티 암호화폐이다. 크로미아를 개발한 크로마웨이(ChromaWay)의 대표는 헨릭 옐테(Henrik Hjelte)이다. 암호화폐 단위는 CHR이다.

개요[편집]

크로미아는 디앱의 확장성 문제를 해결하기 위한 블록체인 암호화폐이다. 또한, 토큰 경제에 대한 다른 접근 방식으로 데이터베이스 중심의 분산 응용 프로그램 지향 플랫폼이다. 크로미아는 기본 유틸리티 토큰으로 사용자는 디앱 내에서 크로미아 토큰을 사용할 수 있으며, 디앱은 크로미아 토큰을 사용하여 생산자를 판단하기 위해 거래 수수료를 지불할 수 있다. 크로미아는 디앱이 크로미아 지원 토큰을 발행할 수 있도록 하는 반면 디앱 프로젝트의 투자자는 이익 공유 계약을 크로미아에서 보상받을 수 있다. 개발자에게 크로미아는 디앱에서 수입을 얻을 수 있는 기회를 제공한다. 또한, 인기 있는 디앱은 개발자가 소유한 토큰에 대해 더 많은 수입을 요구한다.

이더리움의 샤딩과 마찬가지로 크로미아 내의 각 블록체인은 크로미아에 속한 모든 노드의 하위 집합인 유효성 검사기 노드 세트와 관련이 있다. 이 노드 하위 집합은 비잔틴 장애 허용(BFT) 합의 알고리즘을 실행한다. 비트코인 및 이더리움과 같은 작업증명(PoW) 블록체인에 크로미아의 거래 내역을 고정함으로써 네트워크 합의가 더욱 강화된다. 일단 블록이 고정되면 최종으로 간주된다.[1]

특징[편집]

디앱[편집]

크로미아에서 디앱은 단순한 스마트 계약 모음이 아니다. 각 디앱에는 특정 노드 세트에서 실행되는 사이드체인 자체 블록체인이 있다. 자체 토큰, 수익 창출 및 자체 거버넌스를 갖는다. 또한, 모든 거래소가 아닌 호스팅 비용을 지불한다. 이는 디앱 개발자에게 높은 수준의 유연성과 제어 기능을 제공한다. 크로미아에서 모든 디앱은 자신의 선택을 할 자유가 있다. 초고속 상호작용 및 I/O 처리량으로 데이터 쿼리 및 업데이트는 엄청나게 최적화된 관계형 데이터베이스에 위임되어 디앱이 몇 초안에 블록 이상의

플랫폼 아키텍쳐[편집]

포스트체인[편집]

크로미아는 포스트체인(Postchain) 프레임워크에 기반을 두고 있다. 포스트체인은 블록체인 기반 시스템의 구성요소들 사이의 인터페이스를 정의하고 네트워킹, 합의, 암호화 등을 위한 여러 가지 구성요소를 제공한다. 포스트체인과 다른 블록체인 프레임워크의 주요 차이점은 포스트체인이 블록체인 데이터 블록체인 콘텐츠와 애플리케이션 상태를 관계형 데이터베이스에 저장하도록 설계되었다. 또한, 포스트체인은 트랜잭션 논리와 합의를 관계형 데이터베이스와 완전히 일치시킬 수 있다. 예를 들면, 데이터베이스의 계약 조건을 위반하는 트랜잭션은 거부되고 합의에서 제외되며, 어떠한 종류의 치명적인 오류도 초래하지 않는다. 포스트체인은 주로 코틀린(Kotlin)에서 구현되어 자바 가상머신(JVM)에서 실행된다. 자바 가상머신은 가장 일반적으로 사용되는 가상 머신중 하나로, 서버 사용 사례에 맞춰져 있어 사용 가능한 라이브러리가 많다. 자바 가상머신은 버퍼 오버런 및 언더런, 데이터 유출 등과 같은 취약점에 대해 고유한 보호 기능을 제공하며, 개체에 대한 액세스를 제어하고, 어레이 경제 검사를 수행하여 원시 포인터와 같은 오류 발생 기능을 노출하지 않는다. 따라서 자바 가상머신에 구현된 애플리케이션은 버그가 포함되어 있을 때에도 대개 원격 코드 실행과 같은 문제가 없다. 이것은 원격 코드 실행이 엄청난 손실을 초래할 수 있기 때문에 블록체인 스프트웨어에 매우 중요하다.

코틀린은 형식 점검을 더욱 강화하여 기록된 코드 내에서 가치 없는 안전을 보장한다. 크로미아는 안전을 위해 고안된 현대 프로그래밍 언어를 사용하면 결함의 수를 줄일 수 있고 남은 결점이 극단적인 결과로 이어지지 않도록 돕는다. 프스트체인은 여러 블록체인을 단일 데이터베이스에서 호스팅할 수 있도록 하며, 해당 데이터가 최종 커밋이될 때 한 블록체인이 다른 블록체인에 속하는 데이터를 보기할 수 있다. 블록체인은 추가 오버헤드나 복잡성 없이 공유 데이터를 참조할 수 있음으로 블록체인 간 상호 작용의 구현을 단순화한다. 블록체인간 자산 이전에 사용될 수도 있다.

체인[편집]

크로미아는 수평적 확장성을 달성하기 위해 여러 블록체인으로 나뉜다. 이 모델에서 각 노드는 해당 블록체인 관련 데이터로만 작업하면 된다. 이 아키텍처는 단일 블록체인 업데이트로 다른 사람에게 영향을 미치지 않아 확장성을 높이고 업데이트를 단순화한다. 전체 시스템은 크로미아 기능에 필수적인 다수의 시스템 블록체인 및 특정 애플리케이션에 특정한 다수의 애플리케이션 블록체인으로 구성된다.

  • 디렉터리 체인(Directory Chain) : 모든 중요 정보를 추적하고 시스템의 작동을 조정한다. 유효성 검사기는 루트 노드이다. 모든 제공자, 노드 애플리케이션 블록체인 및 검사기를 추적한다.
  • 토큰 루트 체인(Token Roots Chain) : 다른 체인간의 토큰 분포를 추적한다. 유효성 검사기는 디렉터리에 정의된대로이며, 크로미아 토큰을 추적한다.
  • 앵커링 체인(Anchoring Chain) : 다른 체인의 부스러기를 기록한다. 이는 합의된 실패를 감지하는 것을 가능하게 한다. 합의 실패의 경우에는, 다른 버전의 앵커링 체인에 고정된 블록이 우선한다. 정박 체인점은 비트코인과 이더리움 블록체인 자체로 고정되어 있다. 유효성 검사기는 디렉터리에 정의된 대로이며, 노드의 하위 집합에 대한 공격으로부터 방어한다.

거버넌스[편집]

시스템 구조와 규칙 등에 대한 업데이트, 경제 현실에 따른 디앱 운영 가격 등의 매개 변수 조정, 시스템에 신규 멤버의 수용, 악역 배제 등의 지배구조는 분산적이어야 하고 하나의 실체가 그 시스템에 대한 통제권을 가져가서는 안된다. 크로미아는 제공자들이 지배구조 의무를 수행하는 가장 좋은 위치에 있다. 크로미아는 프로젝트를 검토하며, 사용자와 애플리케이션 개발자에게 크로미아를 흥미록게하는 동기가 부여된다. 잘못된 거버넌스 결정은 제공자들에 의해 수집된 수익과 이익에 영향을 미친다. 그러므로, 크로미아는 3분의 2의 제공자들이 승인하기 위한 지배구조 제안에 찬성하도록 요구한다.

초기 중앙 집중화는 크로미아 MVP의 최초 출시로 충분한 양의 독립 제공자를 보유하지 못한다. 이에, 초기 단계에서 거버넌스는 집중되어 모든 결정은 시스템 이해당사자들과 협의하여 크로마웨이(ChromaWay)에 의해 결정된다. 시스템이 기술적 관점에서 준비되고 제공자 생태계가 건강할 때 적절한 분산적 지배구조로의 전환이 일어난다. 크로미아의 거부된 대안으로는 온체인 거버넌스가 있는 블록체인에서 광범위한 지배구조 모델은 이해관계자 투표와 코인투표이다. 이해관계자는 투표가 시빌 통제와 합의 메커니즘의 필수적인 부분이기 때문에 이것은 위임지분증명(DPoS) 블록체인에서 흔하며, 이 모델은 철저히 검토하여 다음과 같은 이유로 거절된다.

  1. 보통 지분 분산을 통제할 수 없다. 즉, 토큰이 몇 손에 집중될 수 있기 때문에 분권형 지배를 보장할 수 없다.
  2. 돈 많은 이해 당사자들이 더 많은 권력을 가지고 있다는 점에서 공평하지 않다.
  3. 많은 사용자들은 교환에 대한 그들의 토큰을 보관하며, 교환이 그들에게 투표할 기회를 준다.
  4. 위임지분증명 방식의 투표는 뇌물, 카르텔, 중앙집권화에 문제가 되기 쉽다.
  5. 토큰이 더 많든 적든 간에 균등하게 퍼지든 실제로 투표의 번거로움을 겪는 사용자는 거의 없고, 제안서를 이해할 수 있는 사용자도 거의 없다.

코로미아는 정식 거버넌스가 없다. 비트코인과 같은 일부 암호 해독기는 공식적인 거버넌스가 없다는 것에 자부심을 갖고 있다. 그들이 원하는 것이 디지털 골드라면, 골드 그 자체는 통치권이 없다. 하지만, 크로미아는 더욱 복잡하여 도전에 시기적절하고 조정된 방식으로 대응할 수 있어야 하며, 공식적인 지배체제를 필요로 한다. 다음은 고유 사용자로 사용자 한 명당 한 표를 주는 것은 유혹적이기 때문에, 지배구조를 돈으로 투표하는 것보다 더 공정하게 만든다. 이는 분산된 환경에서 고유한 사용자를 식별하는 것은 불가능하며, 지분 투표와 관련된 많은 무제들이 여전히 적용된다. 특히, 사용자는 충분한 정보를 제공받지 못해 좋은 결정을 할 수 없다. 그럼에도 크로미아는 이러한 종류의 관리를 실험할 계획이다. 크로미아의 계획은 적극적으로 거버넌스에 참여하기를 원하는 사용자이다. 즉, 크로미아 시민을 식별하는 것이다. 시빌 컨트롤은 소셜 그래프를 추적하여 구현할 수 있다. 크로미아는 이러한 사용자에게 공식적인 거버넌스 권한을 부여할 즉각적인 계획은 없지만, 자문 투표를 실시할 수 있다.

애플리케이션 거버넌스[편집]

애플리케이션마다 거버넌스 요구사항이 다르다. 어떤 것들은 불변하도록 설계되어 있기 때문에 통치를 전혀 요구하지 않으며, 다른 사람들은 직접 민줒주의를 행사하고 각 사용자에게 투표권을 준다. 또 다른 선택사항은 토큰에 비례하는 가중 투표를 시행한다. 디앱 개발자도 거버넌스에서 역할을 하며, 대표적을 완전한 통제 유지와 투표를 통해 사용자와 협력하는 것이다. 크로미아는 애플리케이션 데이터에 액세스하고 복사할 수 있으며, 이는 공공의 블록체인 고유 재산이다. 또한, 애플리케이션을 포크로 묶을 수 있으며, 무료 오픈 소스 소프트웨어와 공공 데이터의 본질적인 속성이다. 크로미아는 사용자가 거버넌스에 불쾌감을 느끼거나 다른 무언가를 실험하고 싶을 때 사용자가 디앱을 포크할 수 있는 도구를 제공한다.

보안[편집]

블록체인의 역할은 모든 사용자가 볼 수 있는 단일 애플리케이션 상태가 있는지 이중 지출과 재생 공격이 가능하지 않은지 확인하는 것이다. 라이트 클라이언트 보안 모델에서 블록체인 노드는 상태 전환 및 트랜잭션의 유효성 검사도 담당한다. 크로미아가 보호하고 있는 가장 기본적인 위협은 단일 노드가 고의로 시스템의 규칙을 위반하는 것이다. 전통적인 소프트웨어 아키텍처를 사용하여 구축된 중앙 집중식 시스템은 이에 대한 보호가 없다. 단 하나의 손상된 서버는 임의의 데이터 수정을 초래할 수 있으며, 금융 데이터의 경우 임의의 손실을 초래할 수 있다. 특히, 소프트웨어하드웨어 취약점 이용에 의한 외부침입, 로그 직원으로 시스템 관리자, 호스팅 제공자의 변조 등에서 발생할 수 있다. 이에, 첫 번째 보호 계층은 암호화 인증과 결정론적 계산 모델을 모두 필요로하는 애플리케이션 타당성이다. 사용자의 노드가 완전한 데이터를 가지고 있을 때 그들은 규칙이 위반되는 경우를 감지할 수 있어 잘못된 애플리케이션 상태를 거부할 수 있다. 크로미아에서 렐(Rell)은 결정론적 계산 모델을 가지고 있고 모든 데이터 변이에 대한 암호 인증을 쉽게 구현한다. 전체 아키텍처는 사용자 노드가 완전한 입력 데이터를 수신하고 애플리케이션 상태를 독립적으로 계산할 수 있다.

노드보안

크로미아는 공급자들 사이의 담합은 지분 손실, 이익, 가능한 법적 조치가 방해 역할을 하여 가능성이 낮다고 보고 있다. 그러나, 공격자가 크로미아 노드에서 임의 코드를 실행할 수 있는 소프트웨어 공격이 발견되면 여러 크로미아 노드가 동시에 손상될 수 있다. 원격으로 악용할 수 있는 취약성의 가장 일반적인 원인은 애플리케이션 코드 내의 메모리 손상 버그이다. 크로미아는 메모리 손상으로부터 보호하는 안전한 언어를 사용하여 구현되며, 메모리 안전을 제공하는 자바 가상머신에서 실현된다. 또한, 다른 취약성의 원천으로는 디앱 코드가 있다. 크로미아 디앱은 그 자체가 메모리 안전 언어인 렐에서 구현된다. 렐 실행 환경은 코틀린에서 구현되어 자바 가상머신 내에서 실행된다. 취약성 소스는 C언어에 작성된 코드로서, 호스트 OS와 데이터베이스 관리 시스템(DBMS)이다. 리눅스 커널 자체의 폭발적인 취약성은 극히 드물며, 포스트그레(Postgre)에 대한 액세스 권한 SQL은 공격 가능성을 제한하는 렐에 의해 조정된다.

또한, 다른 가능한 공격 벡터는 하드웨어와 퍼므워(firmwar)이다. 예를 들면, 인텔 매니지먼트 엔진(Intel Management Engine)은 대부분의 인텔 제품에 존재하며, 잠재적으로 손상될 수 있는 별도의 OS를 효과적으로 실행한다. 이는 동일한 중앙처리장치(CPU)에서 실행되는 노드를 손상시킬 수 있는 벡터를 제공할 수 있다. 이 공격 벡터를 완화하기 위해 크로미아는 제공자들이 서로 다른 벤더의 하드웨어를 다양화하고 사용할 것을 권고한다. 제공자들에게 클라우드 제공자에 대한 노출을 제한한다.

거버넌스 보안

거버넌스는 보안 문제의 근원이 된다. 크로미아는 기업 세계에서 예를 들면, 대표 자신이 서버를 조작할 수는 없지만, 시스템 관리자를 중요한 데이터를 삭제하는 사람으로 교체할 수는 있다. 이렇듯 크로미아 거버넌스 메커니즘은 보안을 염두에 두고 설계되어야 한다. 블록체인 포크를 하거나 파괴하는 데 사용되는 변경사항을 도입하는 것이 불가능해야 한다. 모든 변경은 검토될 수 있도록 지연을 적용해야 하며, 필요할 시 완화 조치를 취할 수 있어 가장 심각한 경우에는 비상 하드 포커가 될 수 있다. 또한, 변화율은 제한되어야 한다.

라이트 클라이언트 보안

대부분의 크로미아 사용자는 블록체인 데이터 전체를 처리하지 않는 가벼운 클라이언트를 사용한다. 그들은 블록체인 상태에서 데이터를 조회하고 거래와 지불의 확인 상태를 제공하기 위해 크로미아 노드에 의존해야 한다. 라이트 클라이언트 사용자가 이 데이터를 인증하는 방법은 그들이 검증자 노드를 신뢰해야 한다. 각 블록은 유효성 검사기 노드의 비잔틴 장애 허용 다수에 의해 서명된다. 그러므로, 잘못된 거래를 확인하기 위해서는 3분의 2 이상의 검증자 노드가 손상되어야 한다. 라이트 클라이언트 보안은 전체 노드 보안보다 크게 나쁘지 않다. 포크를 생산하려면 노드의 3분의 1 이상이 손상되어야 하지만 유효하지 않은 블록을 생산하려면 3분의 2 이상이 손상되어야 한다. 첫 번째 시나리오는 훨씬 가능성이 높으며, 라이트 클라이언트는 전체 노드와 동일한 수준으로 보호된다. 라이트 클라이언트는 작업증명(PoW) 블록체인들에 앵커링 하는 것을 포함하여 고정한다. 크로미아에서 사용되는 고정 방법은 컴팩트한 증명을 만들 수 있으며, 이는 사용자가 전체 노드를 실행할 필요 없이 고정으로 이득을 볼 수 있다는 것을 의미한다. 또한, 노드에서 검색된 데이터가 중요하지 않음으로 인증할 필요가 없다. 데이터를 인증해야 하는 시나리오에서는 데이터의 특성에 따라 다른 데이터 구조를 사용할 수 있으며, 다음과 같다.

  1. 트랜젝션 머클 트리(Transaction Merkle tree) : 트랜젝션이 확인되고 유효한지 확인하는 데 사용할 수 있다. 예를 들면, 지불을 확인하는 데 사용된다. 트랜젝션 머클 트리 루트는 블록 헤더에 있으며, 합의 알고리즘의 일부로 노드에 의해 서명된다.
  2. 국가공약 머클 트리(State commitment Merkle tree) : 일반적으로 블록 헤더는 블록체인 상태를 나타내는 행집합을 커밋한다. 이를 통해 경량 클라이언트는 쿼리에 응답하여 반환된 특정 행이 최신 블록체인 상태에 있는지 확인할 수 있다. 국가 공약은 블록체인 오버헤드를 증가시키기기 때문에 고성능 블록체인에서는 비활성화될 수 있다. 블록 헤더에는 상태 약속 머클루트가 존재하며, 트랜잭션 머클루트와 동일한 방식으로 서명된다.
  3. 주장 및 인덱서(Assertions and indexers) : 전체 질의응답이 올바르고 어떤 데이터도 빠뜨리지 않는다는 것을 증명하기 위해 특별한 데이터 구조를 사용한다. 존재하는 경우에는 블록 헤더에서 동일한 방식으로 서명된다.
  4. 서명된 쿼리 응답 : 쿼리 응답이 중요하지만, 인덱서를 통해 입증할 수 없는 경우에는, 라이트 클라이언트는 여러 노드에 요청을 제출하고 서명된 응답을 받는다.

라이트 클라이언트 검증기 노드 공개키를 알고 있어야만 검증기 노드 서명을 통해 데이터를 인증할 수 있다. 검증기 노드 공개키는 디렉터리 체인을 통해 얻는다. 디렉터리 체인 자체는 루트 체인을 사용하여 검증한다. 이를 해결하기 위해서 라이트 클라이언트는 블록체인의 기원 블록의 내장 하드코드 해시와 루트 노드 공개키의 초기 목록을 함께 제공하며, 루트 블록체인 전체를 다운로드하여 루트 노드의 최신 목록을 얻는다. 루트체인은 하루에 한 블록밖에 없는 극히 희소하므로 이 작업은 가벼운 클라이언트에게도 큰 부담이 되지 않는다. 라이트 클라이언트는 어떤 디렉터리 체인 복제본에도 질의하여 관심 있는 블록체인에 대한 유효성 검증기 목록을 검색하고 상태 약속 메커니즘으로 검증할 수 있다. 또한, 디렉터리 체인에 대한 쿼리 결과도 앵커링 체인과 작업증명 앵커링을 통해 확인해야 한다.

각주[편집]

  1. 크로 미아 (CHR)〉, 《바이낸스리서치》, 2020-05-08

참고자료[편집]

같이 보기[편집]


  검수요청.png검수요청.png 이 크로미아 문서는 암호화폐 종류에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.