크로미아는 클러스터 구조, 데이터베이스 저장 방식, 자체적인 개발 언어 등에서 기술적으로 매우 독자적인 노선을 제시하고 있다.
크로미아는 디앱 클러스터와 시스템 클러스터를 포함하는 클러스터 구조로 구성되어 있으며, 클러스터 내의 사이드체인들을 각기 독립적으로 운영하여 블록체인의 수평적인 확장성을 확보할 수 있다.
크로미아 블록체인의 포스트 체인은 eBFT 합의 프로토콜을 기반으로 클러스터로부터 발생하는 트랜잭션과 쿼리를 검증하고, 디앱 체인의 코드를 실행하여 각 디앱 체인의 상태를 업데이트한다.
크로미아는 기존의 키-값 데이터베이스이 아닌 관계형 데이터베이스를 채택하고 SQL과 유사한 프로그래밍 언어인 Rell을 자체적으로 도입함으로써 복잡한 쿼리를 처리하는 데 효과적이면서도 기존의 개발자로 하여금 친숙한 개발 환경을 제공할 수 있다.
크로미아는 메인넷의 런칭과 함께 $CHR의 네이티브 스테킹이나 익스텐션 등의 기능을 도입하고 있으며, 특히 관계형 데이터베이스라는 특징을 극대화하여 AI 인프라를 위한 데이터 레이어로의 발전을 도모한다.
블록체인이라는 개념이 상당 수준 대중화된 현시점에서는, 더 이상 블록체인의 정의에 대해 논하는 이들을 찾아보기 힘들다. 하지만 블록체인에 대한 심층적인 고찰을 위해서는, 그 본질적 특성에 대한 이해가 선행되어야 한다. 블록체인이란 무엇인가? 일반적으로 블록체인을 분산 장부 시스템이라 정의하곤 하지만, 더 본질적인 차원에서 블록체인은 결국 데이터베이스 시스템에 불과하다. 모든 사용자 활동이 데이터로서 저장되고, 블록체인 상에서 발생하는 모든 트랜잭션은 전체 시스템의 상태(State) 값 변화에 직접적인 영향을 미치기 때문이다.
그리고 현존하는 대다수의 블록체인은 키-값 데이터베이스 구조를 채택하고 있다. 이는 우연이 아닌, 명확한 기술적 이점에 기반한 선택이다. 키-값 데이터베이스가 제공하는 단순성과 확장성은 분산 시스템 구현에 있어 핵심적인 이점을 제공한다. 복잡한 스키마를 요구하는 관계형 데이터베이스와 달리, 키-값 구조는 분산 환경에서의 데이터 일관성 유지가 용이하며, 트랜잭션 처리와 상태 관리라는 블록체인의 본질적 기능에 최적화되어 있다(자세한 내용은 나중에 좀 더 후술하도록 하겠다). 더불어 머클 트리와 같은 암호학적 자료구조와의 통합도 자연스럽게 이루어진다.
그렇다면 블록체인 아키텍처에 있어 키-값 구조의 채택은 필연적인 것일까? 다른 데이터베이스 패러다임으로는 효율적인 블록체인 구현이 불가능한 것일까?
이에 대한 답은 단호히 "아니다"이다. 리서처의 관점에서, 이 분야가 지닌 가장 큰 매력은 아직 확립된 절대적 해답이 존재하지 않는다는 점에 있다. 이는 곧 다양한 기술적 시도들이 모두 잠재적 가치를 지님을 의미한다. 필자는 리서처로서, 기존 블록체인들이 채택한 지배적 방식을 맹목적으로 수용하기보다, 이를 과감히 탈피하여 혁신적 방법론을 제시하는 프로젝트들에도 주목해야 할 책임이 있다고 판단한다.
예를 들어, 만약 어떤 블록체인이 키-값 구조 대신 필자가 앞서 언급한 복잡성을 지닌 관계형 데이터베이스 구조를 채택했다면, 적어도 한 번 정도는 다뤄볼 가치가 있지 않을까? 해당 프로젝트의 성공 또는 실패 여부와는 별개로 말이다(그리고 아직 무엇이 성공했고 실패했다고 단언하기엔 시장이 너무 이른 단계이기도 하고 말이다). 키-값 구조의 명백한 이점에도 불구하고 관계형 데이터베이스를 선택했다면, 그들만의 고유한 기술적 근거가 존재할 것이다. 이에 본 아티클에서는, 관계형 데이터베이스 구조를 채택했을 뿐만 아니라, 프로그래밍 언어 선택에 있어서도 기존의 패러다임을 탈피한 흥미로운 블록체인 프로젝트를 소개하고자 한다. 바로 크로미아(Chromia)에 대한 이야기다.
위에서도 잠깐 언급했듯 크로미아는 블록체인이 데이터를 저장하는 방식에서 기존 블록체인들과 차별화를 했을 뿐만 아니라, 자체적인 개발 언어를 고안하였다는 점이 매우 주목할만하다. 하지만 우리가 여기서 분명히 해야할 것은 주류를 따르지 않는다는 것이 언제나 좋은 결과를 보장하는 접근은 아니라는 부분이다. 오히려 새로운 방법론을 제시하기 위해서는 해당 분야에 대한 더 깊고 넓은 지식을 기반으로 기존에 채택되어 온 방법론과 비교하여 더 많은 문제들을 해결해야 할 수도 있다. 그러한 점에서 크로미아의 시도를 조명해볼 만한 이유가 또 하나 있는데, 크로미아의 흥미로운 접근은 단순히 새로운 메타를 제시하는 것이 아닌, 크로미아를 만든 인물들의 독특한 배경과 블록체인에 대한 높은 이해도를 근거로 하기 때문이다.
Source: Chromia
크로미아를 만든 ChromaWay의 구성원들은 비교적 일찍부터 블록체인 업계에서 이력을 다져왔다. 특히 CTO인 Alex Mizarhi와 COO인 Or Perelman은 2013년도 매우 초기에 생겨난 비트코인 월렛 프로젝트의 파운더이자 개발진으로 활동한 바 있으며, 비트코인에 특정성을 부여하는 프로토콜인 Colored Coin의 초기 기여자로도 참여하였다. 2012년에 개발된 Colored Coin은 비트코인 거래에 고유한 식별값 혹은 메타데이터를 추가하여 비트코인을 특정할 수 있는 자산으로 정의하는 프로토콜로, 추후에 등장한 NFT의 전신인 기술로 특히 잘 알려져있다.
현재는 NFT나 자산 토큰화와 같은 개념이 널리 사용되고, 또 온체인 애플리케이션을 사용해본 사람이라면 누구나 지갑을 사용해봤듯이 토큰 표준이나 월렛은 이제 당연하게 자리잡은 인프라라고 할 수 있다. 그러나 이들이 비트코인 월렛이나 컬러드 코인을 개발하던 시점이, 블록체인이 처음으로 생겨나고서 얼마되지 않은 시점이었음을 상기한다면, 이들 또한 일찍부터 블록체인의 활용성을 시험하기 위해 미개척된 영역에 뛰어든 인물들 중 하나였음을 알 수 있다. 그리고 이러한 이력들이 입증하는 사실은, 유난히 고유한 아키텍처를 가진 크로미아가 그러하듯 ChromiaWay의 구성원들이 현존하는 방법론을 맹목적으로 수용하지 않고 새로운 문법들을 제시하는 것에 이미 익숙한 인물들이었다는 것이다.
또한 ChromaWay는 본래 2016년에 포스트 체인(Postchain)이라는 프라이빗 블록체인을 만드는 것에서 시작하여, e-Krona라는 스웨덴 정부의 CBDC 프로젝트에 참여한 바있다. 이때부터 이미 포스트 체인은 외부 스토리지에 대한 의존성과 데이터 쿼리의 복잡성을 가진 키-값 데이터베이스에 문제 의식을 갖고 SQL 데이터베이스를 차용하고 있었다. 그리고 이러한 포스트 체인에 디앱의 구축을 위한 사이드 체인을 통합하고 합의 모델을 변경하여 내놓은 퍼블릭 블록체인이 우리가 현재 알고있는 크로미아이다.
그렇게 출시된 크로미아가 거쳐온 연원도 꽤나 독특하다. 크로미아가 본격적으로 출범하기까지는 2019년에 화이트 페이퍼를 공개한 이래, 약 4-5년의 시간이 걸렸다. 이에 대한 솔직한 평가로, 대부분의 블록체인 프로젝트가 대개 1년 전후의 시간에 걸쳐 사전 캠페인과 메인넷 런칭을 진행한다는 전형적인 문법을 고려했을 때, 메인넷 런칭까지 5년이라는 긴 시간을 할애하였다는 사실은 이례적인 경우라 말할 수 있다.
그렇다면, 크로미아는 무엇을 위해 이토록 긴 개발 기간을 필요로 했을까? 아래서부터 설명할 크로미아의 구조가 그에 대한 대답이 될 수도 있겠다. 네트워크의 수평적인 확장을 확보하기 위한 클러스터 구조, 노드 간의 합의를 위한 포스트 체인, 그리고 관계형 데이터베이스와 그러한 구조에 최적화하여 SQL을 기반으로 자체 개발한 Rell 프로그래밍 언어까지, 기술적으로 독자적인 노선을 만들기 위해 크로미아가 제시하고 있는 독특한 구조를 하나씩 살펴보자.
2.2.1 클러스터란?
Source: Chromia Docs
크로미아 블록체인은 각기 특화된 기능에 따라 구분되는 노드 그룹이 상호적으로 연결되는 클러스터의 형태를 띈다. 그러한 클러스터들은 다시 디앱 클러스터와 시스템 클러스터로 구분되어 각기 다른 역할을 하는데, 디앱 클러스터는 노드가 디앱을 호스팅하는 역할을 담당하며 시스템 클러스터는 크로미아 네트워크의 블록 헤더 수집, EVM 호환, 코드 저장 등의 오퍼레이션을 담당하는 중앙 허브 역할을 담당한다.
이러한 구조는 디앱 클러스터와 시스템 클러스터가 각기 책임하는 영역을 구분함으로써 크로미아 블록체인의 수평적인 확장을 달성하는 데에 특화되어있다. 만약 어떠한 디앱에 대한 수요가 증가한다면, 그에 따라 디앱이 발생시키는 트랜잭션도 급격히 증가할 것이다.
이때, 기존의 단일 체인 구조에서는 모든 트랜잭션이 하나의 체인에서 순차적으로 처리되어야 하는 제약이 있기 때문에 특정 디앱의 트랜잭션 증가는 전체 네트워크의 처리 용량을 압박하게 된다. 물론 이와 관련해서는 벨리데이터의 하드웨어 성능을 향상시키거나 트랜잭션 병렬처리와 같은 솔루션을 통해 레이턴시를 최적화하는 방법으로 해결책이 제시되고 있다. 그러나 앞서도 언급하였듯, 크로미아는 지배적인 방식을 맹목적으로 수용하기보다 크로미아 블록체인에 최적화된 새로운 방법을 제시하여 네트워크의 성능 저하 문제를 해결하고자 한다. (특히, 관계형 데이터베이스에 최적화하기 위함에 있는데, 이에 대한 자세한 내용은 후술하도록 한다.)
크로미아가 제시하는 방식은 각각의 디앱이 자체적으로 사이드체인을 갖는 다중 체인 구조이다. 각각의 디앱이 자체적으로 컴퓨팅 리소스, 스토리지, 전용 노드 등을 보유하는 사이드체인으로 관리되고 그러한 사이드체인들을 클러스터로 묶는 방법으로 하나의 디앱이 전체 네트워크에 영향을 미치는 문제를 해결하는 것이다. 이러한 독특한 구조는 단일한 운영 체제가 블록체인을 작동하기 위한 모든 오퍼레이션을 책임지는 여타 블록체인 네트워크와 달리, 각각의 디앱이 독립적인 사이드 체인으로 트래픽을 소화하고 사이드 체인을 클러스터로 연결하는 구조이기 때문에 하나의 디앱으로 인해 네트워크 전체의 성능이 저하되는 문제를 방지할 수 있다.
따라서 크로미아에서는 사이드 체인과 클러스터들이 연결되는 구조가 핵심적으로 위치한다. 다음으로는, 디앱의 사이드 체인을 뜻하는 디앱 체인과, 각기 다른 디앱 체인과 각기 다른 역할에 의해 나누어지는 디앱 클러스터와 시스템 클러스터를 하나씩 알아볼 것이다.
2.2.2 디앱 클러스터
우선 디앱 클러스터는 크로미아 네트워크에서 노드가 디앱을 호스팅하는 환경이라고 볼 수 있다. 디앱 클러스터에 대한 설명을 위해서는 먼저 디앱 클러스터에 포함되는 구성요소들에 대한 이해가 선제되어야 한다. 하나의 디앱 클러스터는 여러 개의 1)디앱 체인(Dapp chain)들과 2)클러스터 앵커링 체인(Cluster anchoring chain)을 관리하는 방식으로 운영되는데, 먼저 수평적인 확장을 위한 출발점에 놓여있는 디앱 체인(Dapp chain)부터 살펴보자.
1)디앱 체인
크로미아의 디앱들은 각기 다른 사이드 체인을 보유하는 디앱 체인으로 구축된다. 디앱 체인은 해당 디앱의 운영에 필요한 데이터를 저장하고 있으며, 디앱의 일관된 트랜잭션 처리량을 보장하기 위해 전용 컴퓨팅 리소스와 스토리지 등을 크로미아 네트워크로부터 임대하여 사용한다.
크로미아의 디앱 체인은 일반적인 사이드 체인의 이점을 그대로 가져온다. 디앱 체인은 사이드 체인이 일반적으로 갖게되는, 양방향으로 페그되어 있는 형태, 곧 부모 체인(Parent Chain)과 연결하는 방식으로 데이터를 증명하거나 부모 체인에 해시를 커밋함으로써 사이드 체인의 무결성을 확보할 수 있다. 여기에서 각각의 디앱 체인의 검증을 맡는 부모 체인은 뒤에서 설명할 클러스터 앵커링 체인이 된다.
이렇게 디앱 클러스터 내의 디앱들이 자체적인 사이드 체인을 갖는 구조는 크로미아가 수평적인 확장을 확보하는 데 유용하다. 예를 들어, 하나의 디앱 체인에서 보안적 문제가 발생하거나 네트워크의 혼잡이 발생하더라도, 나머지 디앱 체인들은 해당 문제로부터 영향을 받지 않고 정상적인 작동을 유지할 수 있다. 이러한 설계는 각 사이드 체인이 별도의 오프체인 스토리지에 의존하지 않는 상태로 모든 트랜잭션 데이터를 온체인으로 저장하고 처리할 수 있도록 하며, 다량의 데이터 쿼리를 요구하는 게임이나 LLM(Large Language Model) 학습 등의 작업을 수행하는 데도 용이한 환경을 제공한다.
2)클러스터 앵커링 체인
디앱 체인들이 생성하는 데이터의 무결성을 보장하기 위한 체인이 클러스터 앵커링 체인이다. 앵커링이란, 해시된 블록 헤더를 다른 블록체인에 저장하는 방식을 의미하는데, 하나의 블록체인이 다른 하나의 블록체인을 참고하여 합의 과정에서 발생할 수 있는 결함이나 조작을 방지하는 것이다. 크로미아의 디앱 클러스터에서 사용되는 앵커링도 동일한 방식으로 작동한다.
디앱 체인이 클러스터 앵커링 체인에 앵커링을 한 이후, 클러스터 앵커링 체인은 뒤에서 후술할 시스템 체인의 ‘시스템 앵커링 체인’까지 한번 더 앵커링하는 과정을 거친다. 정리히자면, 디앱 체인이 클러스터 앵커링 체인에, 앵커링 체인은 다시 한번 시스템 앵커링 체인에 앵커링하여 계층적으로 보안성을 확보해주는 메커니즘이다. 보다 자세한 절차는 아래와 같다.
디앱 체인에서 생성되는 블록마다, 해당 블록의 헤더가 클러스터 앵커링으로 전송되어 해시된다.
클러스터 앵커링 체인은 디앱 체인으로부터 블록 헤더를 받기위해 대기한다.
블록 헤더를 수신하면 해당 블록 헤더를 해시 처리한 다음, 클러스터 앵커링 체인이 블록을 생성할 때 해시 처리했던 블록 헤더를 포함시킨다.
시스템 앵커링 블록체인도 동일한 프로세스를 따르는데, 시스템 앵커링 체인은 클러스터 앵커링 체인으로부터 블록 헤더를 수신하고 블록을 생성한다. 만약 합의가 실패할 시에, 시스템 앵커링 체인은 해시된 블록 헤더를 참조하여 모든 클러스터의 상태를 검증할 수 있다.
마지막으로, 시스템 앵커링 체인은 추가적인 보안을 확보하기 위해 한번 더 이더리움에 앵커링함으로써, 리오그 어택과 같은 공격에 대해 보완책을 마련한다.
상기한 방식에 따라 디앱 체인이 해당 디앱을 운영하기 위한 사이드 체인으로 존재하고 클러스터 앵커링 체인이 디앱 체인의 보안을 확보한다. 그렇다면, 디앱 체인과 클러스터 앵커링 체인을 하나의 클러스터로 통합하여 오퍼레이션하는 디앱 클러스터의 노드는 어떠한 역할을 할까?
첫째로, 디앱 클러스터의 노드는 디앱 체인의 트랜잭션을 검증하고, 검증된 트랜잭션을 다시 디앱 체인으로 적절하게 라우팅하는 역할을 한다. 따라서 디앱 체인이 새롭게 배포되거나 업데이트를 할 때, 디앱 체인의 상태(State)는 항상 디앱 클러스터의 모든 노드에게 검증 및 복제되는 과정을 거친다.
둘째로, 디앱 클러스터의 노드들은 디앱 체인의 작동을 위해 작성된 Rell 코드와 디앱 체인의 노드 세부사항까지, 디앱 체인에 대한 모든 정보를 저장하고 있는 상태를 유지한다. 해당 정보를 토대로 노드는 디앱 클러스터 내에서 어떠한 디앱을 실행해야 하는지 결정한다.
이때 노드는 디앱 체인의 정보를 저장하기 위해 시스템 클러스터의 일환인 ‘디렉토리 체인(Directory chain)’의 복제본을 보유하는데, 여기에서 디렉토리 체인이란 시스템 클러스터에서 데이터의 저장을 담당하는 체인에 해당한다. 이처럼 디앱 클러스터 내에 디렉토리 체인에 대한 별도의 복제본을 보유하는 구조는 어떠한 상황에서도 노드들이 클러스터에 속해있는 모든 디앱 체인의 오퍼레이션 상태를 유지할 수 있게하여 크로미아 네트워크 전체의 복원력을 확보하기 위한 목적으로 고안되었다.
2.2.3 시스템 클러스터
디앱 클러스터가 디앱 체인들의 오퍼레이션을 관리한다면, 시스템 클러스터는 크로미아 네트워크의 중앙 허브 역할을 한다. 시스템 클러스터의 내부 구조를 보면, 각기 다른 역할을 가진 사이드 체인들이 크로미아 네트워크의 전반적인 운영을 담당하고 있다. 시스템 클러스터 내에 존재하는 사이드체인들은 1)디렉토리 체인, 2)이코노미 체인, 3)시스템 앵커링 체인, 4)트랜잭션 제출자 체인(Transaction Submitter Chain), 5)EVM 이벤트 수신 체인(EVM Event Receiver Chain)들이 있고, 다른 말로는 각각의 시스템 체인들로 다시 구분된다. 이들은 상호보완적인 관계로써 서로간에 상호작용하며 크로미아 블록체인을 원활하게 작동시킨다.
1)디렉토리 체인
디렉토리 체인은 디앱 클러스터 내의 디앱 체인이 내장한 Rell 코드와, 체인 업데이트, 노드 정보 등의 세부사항들을 저장한다. 위에서 설명했다시피, 디앱 클러스터는 디렉토리 체인의 복제본을 갖고 있기 때문에 디앱 클러스터나 디앱 체인에 문제가 발생한다면, 네트워크 내에 저장된 모든 데이터의 원천 역할을 하는 디렉토리 체인이 클러스터의 데이터 손실을 신속하게 복원한다.
2)이코노미 체인
이코노미 체인은, 말그대로 크로미아 블록체인의 경제적인 부분을 책임지는 시스템 체인이다. 이코노미 체인은 디앱 체인들로 하여금 ‘디앱 컨테이너(Dapp Container)’를 임대하는 것에 대한 비용을 청구하고, 해당 임대 비용을 통해 노드 제공자에게 검증에 따른 인센티브를 제공한다.
이코노미 체인과 함께 자세히 짚고 넘어가야 하는 부분은 이코노미 체인이 디앱 체인의 빌더들에게 청구하는 컨테이너 비용이다. 디앱 클러스터와 디앱 체인은 일관된 트랜잭션 처리량을 보장하기 위해 크로미아 네트워크로부터 전용 컴퓨팅 리소스와 스토리지 등의 리소스를 임대하여 충당하는데, 해당 리소스를 관리하는 하나의 프레임 워크를 디앱 컨테이너라고 부른다.
이러한 디앱 컨테이너를 임대하는 대가로 디앱 체인은 크로미아의 네이티브 토큰인 $CHR을 비용으로 지불하고, 그 대신 자체적으로 노드를 운영할 필요가 없게 된다. 여기에서 이코노미 체인은 디앱 체인이 사용하는 리소스에 따라서 지출해야 하는 컨테이너 임대 비용을 산정하고 청구하는 역할을 담당하는 것이다.
3)시스템 앵커링 체인
시스템 앵커링 체인은 일전에 살펴본 디앱 클러스터의 클러스터 앵커링 체인과 동일한 역할을 하며, 디앱 클러스터의 클러스터 앵커링 체인으로부터 블록 헤더를 수집하고 블록을 생성함으로써 크로미아 네트워크의 무결성을 보장한다. 즉, 클러스터 앵커링 체인이 디앱 체인의 블록 헤더를 수신하여 블록을 생성하고 나면, 시스템 앵커링 체인이 클러스터 앵커링 체인의 블록 헤더를 다시 수신하여 블록을 생성하는 것이다. 이처럼 계층적으로 연결되는 크로미아 네트워크의 메커니즘에서 시스템 앵커링 체인은 이더리움 네트워크에 추가적으로 앵커링하기 이전에 최종적으로 블록 헤더를 저장함으로써 전체 네트워크 보안의 주요한 역할을 담당한다.
4)트랜잭션 제출자 체인
트랜잭션 제출자 체인은 이더리움에 블록을 생성하기 위해 시스템 앵커링 체인으로부터 블록 헤더를 수신하고 주기적으로 이더리움 블록체인에 트랜잭션을 제출한다. 이쯤에서 오해해선 안되는 부분은, 크로미아가 트랜잭션을 최종적으로 이더리움에 제출한다고 하여 L2와 같이 이더리움으로부터 트랜잭션의 완결성을 보장받는 구조가 아니라는 점이다.
오히려, 크로미아의 디앱 체인과 시스템 체인들은 모두 사이드 체인으로 구성되어 있기 때문에 체인 별로 거래의 완결성을 확보할 수 있다. 특히 각각의 체인에서 노드의 3분의 2가 블록에 서명하고 커밋하여 블록을 추가시킬 때 완결성이 확보된 것으로 간주한다. 다만, 리오그 공격과 같은 추가적인 공격 벡터들을 방지하기 위해서 체인 자체적으로 완결성을 확보하는 것 말고도 이더리움에 최종적으로 블록 헤더를 저장함으로써 추가적인 보안을 확보하고 있다고 볼 수 있다. 여기에서 이더리움에 앵커링하기 위해 시스템 앵커링 체인의 블록 헤더를 제출하는 시스템 체인이 바로 트랜잭션 제출자 체인이다.
5)EVM 수신자 체인
앞에서 언급하지 않았지만, 크로미아의 장점 중 하나는 EVM 실행 환경과 원활하게 호환된다는 것이다. 따라서 EVM과 브릿지 역할을 하는 시스템 체인이 필요한데, EVM 수신자 체인이 그러한 역할을 담당한다. 예를 들어, 사용자가 이더리움 기반의 $CHR 토큰 컨트랙트에 $CHR 토큰을 예치하면, EVM 이벤트 수신자 체인이 컨트랙트의 업데이트된 스테이트먼트를 읽고 새롭게 업데이트된 세부사항을 이코노미 체인에 알린다. 그렇게 정상적으로 이더리움 기반 $CHR의 예치가 확인되고나면, 이코노미 체인은 크로미아 네트워크에 예치된 수량만큼의 메인넷 기반 $CHR 토큰을 할당한다.
2.2.4 크로스체인 인프라
여기까지 크로미아의 클러스터 구조를 전체적으로 살펴봤을 때, 따라오는 질문은 각기 다른 역할을 하는 클러스터와 클러스터 내의 사이드 체인들을 어떻게 연결할 것인가에 대한 의문이다. 크로미아가 채택하는 클러스터 구조는 사이드 체인을 통해 디앱이 자체적으로 리소스와 트랜잭션 완결성을 확보할 수 있으며, 하나의 디앱이 일으키는 다량의 트래픽에 따라 그 외 모든 디앱의 성능이 저하되는 문제를 방지하여 수평적인 확장을 달성한다는 점에서 분명한 장점을 지닌다. 그러나 수평적인 확장에 따른 트레이드 오프로, 사이드 체인드링 서로 경제적, 보안적으로 파편화될 수 있다는 점은 분명한 단점으로 작용한다.
따라서 크로미아 블록체인서 핵심적인 역할을 하는 인프라가 크로미아 내의 클러스터 간에, 그리고 클러스터 내의 디앱 체인간에 이벤트와 데이터를 원활히 주고받을 수 있도록 연결하는 크로스체인이다. 특히 크로미아는 ICMF(Interchgain Messaging Facility)와 ICCF(Interchain Confirmation Facility) 프로토콜을 사용하는데, ICMF는 같은 클러스터 내에 있는 사이드 체인 간의 소통을 지원하고 ICCF는 서로 다른 클러스터에 있는 사이드 체인 간의 소통을 돕는다. 또한 크로미아의 크로스체인을 활용하여 클러스터 내의 사이드 체인 뿐만 아니라, 이더리움을 비롯한 EVM 체인들과 토큰, 이벤트 등의 데이터를 브릿지할 수 있다.
상기한 클러스터 구조도 결국 블록체인이라는 기술의 범주 안에서 작동하기 때문에 크로미아 또한 블록의 상태를 검증하고 합의하는 과정이 필요하다. 이를 위한 역할은 크로미아 네트워크의 노드가 담당하는데, 노드는 포스트 체인(Postchain)이라는 프레임워크를 통해 클러스터로부터 발생하는 트랜잭션과 쿼리를 검증하고 블록을 생성한다. 또한 노드가 디앱 체인의 Rell 코드를 해석하거나 관계형 데이터베이스와 상호작용하는 것도 모두 포스트 체인을 통해서 이루어진다. 크로미아에서 발생한 트랜잭션의 생애 주기를 따라가며 포스트 체인의 주요한 기능을 자세히 살펴보면 다음과 같다:
트랜잭션 처리: 사용자 또는 디앱 체인이 서명하여 제출한 트랜잭션을 수락하고 처리한다.
합의 관리: PBFT를 수정하여 만든 eBFT 합의 프로토콜을 기반으로 블록을 검증하고 노드 간의 합의를 달성한다.
데이터 저장: 검증된 트랜잭션의 히스토리와 각 디앱 체인의 상태를 포함한 블록체인 데이터를 저장하기 위해 PostgreSQL과 상호작용한다.
디앱 코드 실행: Rell 프로그래밍 언어로 작성된 디앱 체인의 코드를 실행하여 각 디앱 체인의 상태를 업데이트한다.
2.4.1 포스트 체인이 합의를 달성하는 방법
Source: Chromia Docs
상기한 과정에서 노드는 크로미아의 eBFT 합의 프로토콜에 의거하여 트랜잭션을 검증하고 블록을 생성한다. 해당 과정을 따라가보면, 노드가 트랜잭션을 수신하고 해당 트랜잭션을 클러스터에 있는 다른 모든 노드들에게 전파한다. 이후, 권한 증명(Proof of Authority)에 의해 선택된 벨리데이터 노드 그룹이 새로운 블록을 생성할 수 있는 권한을 얻어 유효한 트랜잭션만을 블록에 추가하는데, 보다 자세히는 아래의 절차를 따르고 있다.
노드는 특정한 시간 간격 내에 수신한 트랜잭션을 수집하여 현재 라운드의 블록으로 제안한다.
노드는 제안된 블록을 다른 모든 노드에 전파한다.
제안된 블록을 수신한 다른 노드들은 블록 내의 트랜잭션을 실행하여 블록을 검증한다. 유효한 경우, 블록에 서명하고 그들의 서명을 다른 모든 노드에 전파한다.
노드들의 2/3 이상이 블록에 서명을 완료하면, 각 노드는 블록을 데이터베이스에 커밋한다.
이처럼 포스트 체인의 eBFT 합의 프로토콜은 블록체인의 트랜잭션을 안전한 방식으로 검증한다. 특히 제안된 블록을 전파하고 모든 노드가 그것을 실행하여 서명하는 과정을 걸쳐 최종적으로 블록을 커밋하는 방식은 노드 중에 1/3 미만이 악의적으로 행동하거나 작동 불능상태에 처하더라도 안정적으로 네트워크를 유지할 수 있도록 한다.
2.4.2 포스트 체인이 관계형 데이터베이스와 상호작용하는 방법
노드 간에 안정적으로 트랜잭션을 전파하고 합의 상태를 달성하는 것은 기본적인 블록체인의 기능이다. 이에서 나아간, 포스트체인만의 좀더 특별한 기능은 크로미아 네트워크의 관계형 데이터베이스와 상호작용하는 역할에 있다. 디앱 클러스터의 구조에서 살펴봤듯이, 크로미아의 디앱 체인은 자체적인 데이터베이스를 내장하고 있으며, 디앱 체인에서 발생한 트랜잭션을 관계형 데이터베이스로 저장한다. 그에 따라 포스트 체인의 또 다른 역할은 새로운 디앱이 생성되거나 디앱의 상태를 업데이트할 때, 직접 관계형 데이터베이스 상호작용하는 것이다.
먼저, 새로운 디앱 체인이 배포거되거나 업데이트를 진행할 때, 포스트 체인은 디앱 체인의 Rell 코드를 읽어 디앱이 필요로 하는 데이터베이스를 결정한다. 이후 디앱이 원활하게 실행될 수 있도록 데이터베이스에 데이터 테이블과 컬럼(열)을 자동으로 생성한다.
또한 포스트체인은 트랜잭션의 결과에 따라 데이터베이스를 업데이트한다. 사용자가 디앱을 사용하면서 디앱의 특정한 기능을 호출한다면 트랜잭션이 생성될 것이다. 그리고 해당 트랜잭션은 디앱 체인의 Rell 코드로 정의된 오퍼레이션을 실행하도록 호출한다. 이때, 포스트체인은 디앱 체인의 Rell 코드를 해석하여 SQL 쿼리로 변환하고, 변환된 SQL를 디앱 체인의 관계형 데이터베이스에 적용하여 데이터베이스를 업데이트한다. 포스트 체인의 이러한 기능이 중요한 이유는, 디앱 체인의 빌더가 디앱 체인에 내장된 관계형 데이터베이스를 변경하기 위해 원시 수준의 SQL 쿼리를 직접 수행하지 않아도 된다는 점이다. 대신, 빌더는 SQL로 복잡한 데이터 베이스 연산을 하지 않고도 간단한 Rell 코드를 통해 데이터베이스를 변경할 수 있다.
2.4.3 포스트 체인이 쿼리에 응답하는 방법
포스트 체인은 관계형 데이터베이스 상호작용하는 기능 외에도 디앱에 대한 읽기 전용 쿼리(Read-only Queries)를 구현해준다. 읽기 전용 쿼리란, 말 그대로 데이터의 호출을 통해 정보를 조회하는 것만을 목적으로 하는 쿼리이다. 읽기 전용 쿼리의 유용한 점은 단순히 데이터를 조회만 하는 것이기 때문에, 벨리데이터 노드에 의해서 이미 커밋된 데이터를 변경하거나 새롭게 블록을 제안하지 않아도 빠르게 데이터를 제공할 수 있다는 것이다.
예를 들어, DEX 서비스를 제공하는 디앱 체인에서 사용자가 자신의 어카운트 잔액이나 최근 거래 내역을 조회한다고 해보자. 이때, 읽기 전용 쿼리를 이용하면 해당 정보에 대한 즉각적인 응답을 제공할 수 있다. 즉 별 다른 지연 없이도 그저 프론트 엔드를 통해 관계형 데이터베이스에 저장되어 있던 쿼리를 호출하여 실시간으로 응답을 제공할 수 있는 것이다. 이러한 읽기 전용 쿼리는 실시간의 데이터 처리와 호출이 중요한 애플리케이션에서 유용하게 사용될 수 있으며, 동시에 노드의 추가적인 합의 과정을 요구하지 않기 때문에 전체 네트워크가 리소스를 아끼는 측면에서도 효율적인 방법이라 할 수 있다.
이렇게 크로미아의 연원과 클러스터 구조, 그리고 포스트 체인을 살펴보면서 크로미아가 기본적으로 어떻게 작동하는지 알 수 있었다. 여기까지 봤을 때, 크로미아는 좀처럼 단순하지 않게 보이는 구조를 채택하고 있어 복잡하다는 평가를 내릴지 모른다. 그러나 해당 설계는 사실 다음에 소개할 아키텍처에 최적화하는 데 목적이 있어 충분한 당위를 갖는다고 생각한다. 여타 블록체인과 눈에 띄게 다른 아키텍처인 관계형 데이터베이스가 바로 그것이다.
누군가가 필자에게 2024년의 블록체인 시장을 요약해달라고 한다면, 주저 없이 "다양성"이라고 답하고싶을 정도로 블록체인 시장은 지난 사이클에 비해 상당히 많은 부분에서 다양성을 추구하게 되었다. 여기서 말하는 다양성이란, 단순히 가상머신과 프로그래밍 언어에서의 기술적 선택지가 늘어난 것을 넘어서, 블록체인의 기본 구조나 데이터베이스 설계 방식과 같은 근본적인 아키텍처에서부터 차별화를 시도하는 혁신적인 네트워크들이 속속 등장하고 있다는 점이 특히 주목할 만하다. 이러한 시도의 대표적인 예시는 바로 수이(Sui) 네트워크다. 수이 네트워크는 Move라는 새로운 프로그래밍 언어를 선보였을 뿐만 아니라, 스토리지 구조도 객체 중심의 모델을 도입함으로써 블록체인 인프라 구축에 있어 다양한 방법론이 적용될 수 있음을 입증하였다.
물론 이처럼 과감한 시도들이 일부의 관점에서는 상당히 위험해 보일 수 있다. 하지만 반대로 생각해보면, 이는 현 시장 상황에서 오히려 매우 합리적인 전략이기도 하다. 특색 없이 비슷한 인프라들이 범람하는 현재 블록체인 생태계에서는 뚜렷한 차별점 없이는 개발자들과 빌더들의 관심을 끌기 어렵다. "왜 이 블록체인을 선택해야 하는가?"라는 근본적인 질문에 대한 명확한 답을 제시하지 못한다면, 그저 수많은 대체 가능한 옵션 중 하나로 머물 수밖에 없기 때문이다.
어찌 보면 크로미아도 이러한 관점에서 매우 주목할 만한 시도를 보여주고 있다. 필자가 앞서 크로미아 블록체인의 구조를 살펴보며 설명했듯이, 크로미아는 이미 그 근본적인 아키텍처부터 다른 블록체인들과 차별화된 길을 걸어가고 있다. 특히 이들 중에서도 단연 돋보이는 부분은 크로미아의 독특한 데이터베이스 구조와 프로그래밍 언어다. 또한 흥미로운 점은 크로미아의 이러한 기술적 선택이 최근 주목받고 있는 수이(Sui)의 접근 방식과도 뚜렷한 차별점을 보인다는 것이다. 그렇다면 크로미아의 데이터베이스와 프로그래밍 언어는 무엇이며, 이들은 어떠한 장점과 차별점이 있을까?
우선, 관계형 데이터베이스 모델은 크로미아가 고안한 개념은 아니다. 그 역사를 거슬러 올라가면 1970년대까지 올라가는 굉장히 유구한 역사의 데이터베이스 모델로 다른 데이터베이스와 다르게 데이터들을 테이블 형태로 구성해서 테이블들 간의 관계를 정의한 다음에 데이터를 효율적으로 관리하는 것에 중점을 뒀다는 부분이 차별점이다. 이 덕분에 관계형 데이터베이스에선 복잡한 쿼리의 실행이 가능하다는 장점이 있다.
3.1.1 관계형 데이터베이스의 한계점들과 이를 해결하기 위한 크로미아의 노력들
하지만 그럼에도 불구하고, 왜 관계형 데이터베이스는 블록체인 업계에선 생소한 개념일까? 그 이유는 여태까지 관계형 데이터베이스 모델이 블록체인에 적합하지 않다고 판단했기 때문이다. 그러한 이유는 아래와 같다:
관계형 데이터베이스는 데이터의 수정이 자유로운 것이 특징인데, 이는 불변성을 강조하는 블록체인의 성질과는 본질적으로 맞지 않는다.
관계형 데이터베이스는 중앙 집중 형태로 데이터베이스를 관리하는데, 이 역시 블록체인의 탈중앙화와 어울리지 않는 방식이다.
마지막으로, 관계형 데이터베이스의 테이블 형태가, 이전 블록의 해시값을 포함하는 체인 구조와 알맞지 않다.
이 외에도 여러 이유로 지금까지 대부분의 블록체인들은 관계형 데이터베이스가 아닌 키-값 데이터베이스를 사용해왔다. 하지만 크로미아는 과감하게 관계형 데이터베이스를 채택했다. 그렇다면 크로미아는 관계형 데이터베이스를 어떻게 블록체인에 활용하고 있을까?
그 답은 바로 크로미아의 포스트 체인(Post Chain)과 앵커링 체인(Anchoring Chain)에서 찾을 수 있다. 앞서 설명했듯이, 크로미아는 각각 다른 역할을 수행하는 여러 종류의 체인들로 구성되어 있다. 이 중 포스트 체인은 단순히 쿼리를 검증하고 블록을 생성하는 것을 넘어서 관계형 데이터베이스와 직접 상호작용하는 역할을 수행한다. 관계형 데이터베이스 자체는 블록체인과 성격상 맞지 않는 부분이 있을 수 있지만, 그 중간에 포스트 체인이 있기 때문에 블록체인의 특성인 탈중앙성과 불변성을 유지할 수 있게 되었다. 또한 해시값을 저장하는 역할은 앵커링 체인이 담당하기 때문에 기존 관계형 데이터베이스가 가졌던 단점들을 보완할 수 있게 된 것이다.
누군가는 크로미아의 다중 체인 구조를 보면서 "복잡하다"라고 평가할 수 있지만, 사용자들은 모든 체인과 직접 상호작용할 필요가 없다. 오히려 이러한 다중 체인 구조가 있기에 관계형 데이터베이스의 단점들을 보완할 수 있어서, 이는 필수적인 설계라고 할 수 있다. 그렇다면 관계형 데이터베이스를 사용함으로써 크로미아가 얻게 되는 장점들은 무엇일까?
3.1.2 관계형 데이터베이스가 가지는 장점
우선 필자가 언급했듯 관계형 데이터베이스는 복잡한 쿼리 처리가 가능하기 때문에, 기존 블록체인에서는 불가능했던 쿼리를 블록체인 상에서 직접 실행할 수 있고, 자동으로 인덱싱이 되어 데이터 인덱싱 작업에 있어 제3자에 의존하지 않아도 된다. 무엇보다 중요한 것은, 대부분의 AI 모델들이 관계형 데이터베이스 위에서 작동되고 있기 때문에 크로미아가 향후 AI 인프라로서도 적합하다는 점이 큰 장점이다(크로미아가 AI로 어떻게 활용되는지에 대해서는 후술하도록 하겠다).
마지막으로, 관계형 데이터베이스를 사용하면 SQL과 같이 기존 개발자들에게 매우 친숙한 언어와 유사한 프로그래밍 언어를 사용할 수 있다는 장점이 있다. 이는 개발자 경험이 매우 중요한 블록체인 플랫폼의 입장에서 핵심적인 부분이라고 할 수 있다. 크로미아도 관계형 데이터베이스를 사용하기 때문에 SQL과 유사한 언어를 사용하는데, 바로 크로미아 팀이 개발한 Rell이라는 프로그래밍 언어이다. 이제 Rell에 대해 자세히 살펴보도록 하자.
Source: Stack Overflow
최근 Stack Overflow에서 발표한 자료에 따르면, 개발자들에게 가장 친숙한 프로그래밍 언어는 자바스크립트(JavaScript), 파이썬, 그리고 SQL로 나타났다. 블록체인 업계에서 개발자들을 온보딩해야 하는 입장에서 가장 중요한 것은 개발자들의 사용/프로그래밍 경험을 개선하는 것인 만큼, 프로그래밍 언어 또한 기존 개발자들에게 가장 친숙해야 할 것이다.
이러한 맥락에서 Rell은 블록체인 업계의 여러 프로그래밍 언어들에 비해 비교우위를 제공한다. Rell은 SQL과 유사한 관계형 데이터 모델링과 쿼리 기능을 제공하면서도(예: 개발자는 ‘entity’키워드를 사용하여 데이터 구조를 정의 할 수 있다) SQL의 불필요한 장황함을 줄이고, 필수적인 세부사항을 명확하고 정확하게 전달하는 데 중점을 두었다. 또한 JavaScript와 Kotlin과 같은 언어들과 유사한 문법을 구현하기 때문에 Rell을 처음 접하는 개발자들이라 할지라도 빠르게 언어를 학습하여 크로미아에 애플리케이션을 구축할 수 있다.
Rell은 안정성 측면에서도 주목할 만한 특징들을 보유하고 있다. 우선 Rell의 모든 변수와 표현식에는 명확한 타입이 존재하여 런타임 오류를 최소화할 수 있다. 또한 쿼리에서 반환된 타입이 코드에서 사용된 타입과 일치하는지 컴파일 시점에서 확인할 수 있다는 것이 큰 장점이다. 여기에 더해 산술 연산에서 발생할 수 있는 오버플로우를 방지하는 기능도 갖추고 있다.
물론 아직 크로미아 생태계가 크지 않기 때문에 Rell이 블록체인 생태계에서 얼마나 널리 사용될지는 지켜봐야 하겠지만, "새로운 프로그래밍 언어"이기 때문에 가지는 단점들은 많이 상쇄된 것으로 여겨진다. 오히려 기존 개발자들에게 더 익숙한 구조이기 때문에 대량의 웹2 개발자들을 온보딩하는 데 더 큰 장점으로 작용할 수도 있을 것이다.
여기까지 크로미아의 아키텍처와 관계형 데이터베이스를 살펴봤을 때, 크로미아는 분명히 블록체인을 설계하는 방법론에 있어 독창적인 접근을 제시하고 있다. 사이드체인이 계층적으로 연결되는 클러스터 구조는 수평적인 확장성을 달성하는 데 유용하며, 관계형 데이터베이스를 통해 기존의 키-값 데이터베이스가 지닌 한계를 보완하는 시도를 전개하며 범람하는 블록체인들 가운데 크로미아가 존재해야 하는 이유를 비교적 명백하게 설명한다.
그럼에도 크로미아가 기술적으로 보여주는 혁신성과 별개로 한가지 남아있는 의문은, 크로미아 생태계가 시장과 산업의 동향에 발맞춰 시장 참여자로 하여금 관심을 받거나 생태계를 채우는 빌더들의 유입을 기대할만한 요인이 충분한가에 대한 부분이다. 특히 크로미아는 메인넷의 런칭까지 4-5년이라는 긴 개발 기간을 거쳐왔으며 최근 주류로 자리하고 있는 블록체인들의 아키텍처와도 구조상에서 거리가 멀다. 그러한 맥락에서 크로미아는 시의성이 떨어진다는 우려를 받기에 충분할지 모르는데, 시시각각 변하는 시장동향과 기술을 기반하여 로드맵을 빠르게 전환하며 발전해나가는 것이 블록체인 산업의 특징이기 때문이다.
그러나 우연인지, 필연인지 크로미아는 현재 시장에서 가장 많은 관심을 받고 있는 AI와 탁월한 시너지를 내며 활발한 이니셔티브를 전개하고 있다. 특히, 최근에는 크로미아에서 2천만 달러 규모의 데이터 및 AI 생태계 펀드를 출시하였다는 소식을 전하여 크립토 x AI에 대한 관심이 한창 점화되던 시점에 많은 관심을 이끌어낸 바있다. 더욱이, 크로미아는 본격적인 메인넷의 출시와 함께 관계형 데이터베이스와 좋은 시너지 효과를 갖는 프로젝트들과 협업을 진행하며 앞으로의 시장에 적응해나가기 위한 만반의 준비를 하고 있다.
Source: Chromia Blog
크로미아가 올해 10월, 본격적으로 메인넷을 런칭한 것이 첫번째 중요한 마일스톤이었다. 또한 메인넷의 런칭과 함께 소프트웨어 업그레이드인 아스가르드 업데이트를 예고하면서 크로미아가 앞으로 나아가기 위한 계획들을 공개하였다.
첫 번째로, MVP 단계의 메인넷에서 본격적인 메인넷으로 전환하면서 크로미아의 네이티브 토큰인 $CHR이 출시되었다. 기존의 $CHR이 ERC-20 표준으로 생성되어 별다른 유틸리티 없이 존재하던 것과 달리, 이제는 네트워크를 운영하는 데 필수적으로 기능하는 네이티브 토큰이 된 것이다.
네이티브 토큰의 출시와 함께 스테이킹 기능도 출시하였는데, 이를 통해 토큰의 보유자는 CHR를 스테이킹하고 보상을 받을 수 있게 되었다. 크로미아의 프로바이더(벨리데이터 등의 노드)로 참여하기 위해서는 최소 금액의 CHR 스테이킹이 충족되어야 하기 때문에, $CHR의 보유자는 프로바이더에게 토큰을 위임하고 네트워크 보상을 분배받을 수 있는 선택지가 추가적으로 생긴 것이다.
이렇듯 $CHR이 네트워크에 중요한 기능을 하는 토큰으로 사용된다는 점은 토큰의 가치 획득 측면에서 중요하게 언급할 대목이다. 앞으로, 디앱 체인은 컨테이너를 임대할 시에 $CHR으로 컨테이너 수수료를 지불한다. 그렇게 디앱 체인으로부터 모인 수수료는 하나의 풀에 모여지고 네트워크의 프로바이더와 스테이커 홀더들에게 분배될 예정이다. 이로써 디앱 체인의 활성도가 높아지고 더 많은 디앱 체인이 새롭게 생성됨에 따라 $CHR 토큰이 가치를 획득할 수 있는 메커니즘이 마련되었으며, 이는 생태계의 네트워크 효과를 만드는 토크노믹스 측면에서 중요한 전환점으로 꼽을 수 있다.
Source: Chromia Blog
두 번째로 주목할 만한 업데이트는 곧 진행될 예정인 아스가르드 업데이트이다. 해당 업데이트를 통해 모든 노드 프로바이더들이 일괄적으로 소프트웨어를 업그레이드할 예정이다. 주요한 업그레이드 중 하나는 모듈식 프레임워크를 통해 크로미아 블록체인의 기능을 확장할 수 있는 ‘크로미아 익스텐션(Chromia Extension)’의 도입이다. 크로미아는 앞으로 다양한 디앱 체인에게 탈중앙화 클라우드를 제공하는 데이터 레이어로 사용되는 양상을 구상하고 있는데, 익스텐션은 그러한 로드맵을 달성하기 위한 주요 업그레이드 중 하나이다.
가장 먼저 출시된 익스텐션은 오프체인 데이터를 실시간으로 연동할 수 있는 오라클 익스텐션으로, 최근에 오라클 솔루션인 Stork와 협력을 발표한 바있다. 협력을 통해 구축될 오라클 익스텐션은 다양한 유형의 디앱 체인이 가격 추적과 거래에 필요한 실시간 데이터 피드를 제공할 예정이며, 이로써 디앱 체인들이 게임이나 RWA 혹은 머니마켓 프로토콜과 같은 분야에 진입하는 가능성을 확보하고자 한다. 오라클 익스텐션 이후로는, AI 추론, 데이터 가용성, 영지식 증명 등과 관련한 익스텐션이 차례로 출시될 예정이다.
4.2.1 크로미아 아키텍처와 AI의 시너지
본질적으로 크로미아는 게임, RWA, 디파이, 컨슈머 애플리케이션 등의 다양한 디앱 체인이 생태계를 구성하는 범용 블록체인이지만, 그 중에서도 특히 크로미아는 관계형 데이터베이스와의 높은 시너지를 바탕으로 AI 중심의 로드맵을 전개하고 있다.
보통 AI를 자율적으로 지각하는 소프트웨어 정도로 포괄적이게 정의할 수도 있다. 다만 데이터를 중심으로 AI를 다시 정의한다면, 데이터를 표준화하고 정제한 다음, 데이터의 처리를 자동화한 결과물이 바로 AI라고 말할 수 있다. 보다 구체적으로는, 서로 다른 구조를 가진 데이터를 일괄된 형식으로 변환하는 표준화 과정을 거치고, 원본 데이터를 모델링에 적합한 형태로 가공하는 전처리 과정을 거친 이후, 데이터의 수집과 입출력 등의 과정을 자동화하면 우리가 알고 있는 AI의 모습이 된다.
그러한 관점에서 AI의 근간에는 데이터가 중요하게 자리하고 있다. 또한 동시에 크로미아 블록체인의 근간에도 탈중앙화된 방식으로 데이터베이스를 저장하고 처리하는 기능이 핵심적으로 자리한다. 이렇듯 데이터를 효율적으로 처리하는 것이 핵심적으로 요구되는 AI, 그리고 데이터를 효율적으로 처리하는 데 특화되어 있는 크로미아는 구조적인 면에서 높은 시너지 효과를 내며 결합되는 가능성을 갖는다.
무엇보다 크로미아의 프로그래밍 언어인 Rell은 AI와 관련한 데이터 작업을 수행하는 적합한 특성을 지닌다. AI가 데이터를 활용하는 양상을 먼저 살펴보면, AI의 자연어 처리(NLP, Nature Language Processing) 모델은 AI의 학습과 추론을 위한 대량의 텍스트를 저장하는 과정에서 관계형 데이터베이스를 필요로 한다. 그리고 이때 구조화된 텍스트를 저장하는 작업에 적합한 SQL이 데이터를 효율적으로 쿼리하고 저장하는 목적으로 사용된다. 이처럼 본래도 AI의 자연어 처리에는 SQL이 표준으로 사용되기 때문에, SQL을 기반으로 제작된 크로미아의 Rell 언어는 AI와 관련한 작업과도 높은 호환성을 보인다.
마지막으로, 크로미아의 클러스터 구조도 AI와 관련한 데이터 작업과 정합성이 높다. 크로미아의 클러스터 구조는 하나의 디앱에서 과부화가 일어난다 하더라도 각각의 디앱이 자체적인 사이드 체인으로 작동하기 때문에, 네트워크는 AI의 학습이나 추론을 위한 대규모의 데이터를 처리하는 과정에서 발생하는 병목현상에 영향을 받지 않고 높은 처리량을 안정적으로 유지할 수 있다.
4.2.2 Crypto x AI의 미래에 크로미아가 중요한 이유: Proof of AI
크립토 산업에서 AI가 중요한 주제로 떠오르면서 크립토와 AI가 결합되는 양상은 다양하게 펼쳐지고 있다. 그에 맞춰 토큰 인센티브를 통해 AI 학습을 위한 데이터를 확보하는 데이터 마켓부터 GPU 마켓 플레이스까지 다양한 양상으로 프로덕트가 구축되고 있지만, 그 중에서도 시장 참여자들의 관심을 한몫에 받고있는 유즈케이스는 AI가 자율적으로 의사결정을 하고 작업을 수행하는 AI 에이전트라는 영역이다. GOAT와 Terminal of Truth, 그리고 LUNA 등의 부상을 통해 AI 에이전트에 대한 담론이 크립토 산업에서 본격적으로 가시화된 이후, 무엇보다 크립토 인프라에 최적화하여 AI 에이전트가 자율적으로 어카운트를 보유하고 크립토 거래를 수행하는 발전양상을 보인다.
그러한 발전양상 가운데 아직까지 AI 에이전트가 많은 권한과 함께 고도화된 금융 활동을 수행하는 데 걸림돌이 있는데, AI의 추론을 어떻게 검증할 것인가에 대한 문제가 그것이다. 가령, AI가 자율적으로 온체인 토큰을 전송하고 Mozaic과 같이 합성자산 펀드를 리밸런싱한다고 하였을 때, AI의 추론에 인간에 개입하지 않았는지 혹은 AI가 어떠한 과정을 거쳐 추론의 결과를 내놓았는지 투명하게 확인하는 절차는 중요해진다.
Source: Chormia LLM Explorer
여기에서 크로미아가 AI의 추론 데이터에 대한 투명성을 확보하는 솔루션을 제시한다. 이미 크로미아는 압축적인 네 줄의 Rell 코드만으로 AI의 추론 데이터를 블록체인에 저장하여 AI 에이전트에 투명성을 더하고, 해당 데이터를 확인할 수 있는 익스플로러를 제공하고 있다. 이를 통해 누구나 크로미아 블록체인에 저장된 opML 추론 데이터를 활용하여 AI의 결과를 검증하며 결과에 대한 이의를 제기하는 데 사용할 수 있다. 결과적으로, AI의 의사결정이 편향되거나 조작되기 어렵게 만들고 AI에 대한 검증 가능성을 확보함으로써 AI 에이전트에 대한 신뢰도를 높인다.
이와 같은 방식으로 크로미아는 AI와 관련한 프로토콜로 하여금 데이터 레이어로 활용되기에 잠재력이 높다. 최근에는 Chasm Network가 opML 데이터베이스만을 위한 디앱 체인을 새롭게 배포하여 추론 데이터를 위한 레이어로 크로미아 네트워크를 활용하고자 한다. 이로써 디앱 체인의 빌더는 크로미아의 디앱 컨테이너를 활용하여 효율적인 비용으로 데이터 인프라를 구축하고 사용자는 누구나 디앱 체인에 접근하여 AI의 의사결정 프로세스를 검증할 수 있다.
필자가 크로미아에 대해 리서치를 하며 가장 강렬하게 느낀 점은 그 구조가 매우 생소하다는 부분이었다. 전문적으로 다양한 블록체인들을 분석하고 그 구조들을 면밀히 살펴보는 것이 업이지만, 크로미아가 가진 구조는 그 자체만으로도 기존의 블록체인들과는 확연히 다른 차별점을 보여준다. 다중 체인 구조는 얼핏 보면 아발란체의 서브넷이나 폴카닷의 구조를 떠올리게 하지만, 체인들의 자세한 설계를 들여다보면 이들과는 완전히 다른 방향성을 보인다. 각각의 체인들이 명확한 역할을 부여받고 서로 유기적으로 상호작용하는 독특한 구조를 가지고 있기 때문이다. 여기에 더해 기존 블록체인들이 시도하지 않았던 관계형 데이터베이스를 도입하고 자체 개발한 프로그래밍 언어(Rell)를 사용하며, 나아가 FT4라는 독자적인 토큰 스탠다드까지 제시했다. 사실 이러한 파격적인 시도들은 빌더의 입장에서 봤을 때 상당한 모험이라고 할 수 있다. 일반 사용자들은 차치하더라도, 기존 블록체인 환경에 익숙한 개발자들이 이러한 혁신적 구조에 어떤 반응을 보일지 예측하기 어렵기 때문이다.
하지만 이러한 과감한 시도야말로 현재 블록체인 생태계에 꼭 필요한 혁신이라고 생각한다. 특히 요즘같이 SDK와 개발 툴이 고도로 발달하여 누구나 쉽게 양산형 블록체인을 만들어낼 수 있는 시기에는, 블록체인의 근본적인 설계 철학부터 다시 고민해보는 팀들의 존재가 더욱 값지다. 물론 이러한 혁신적 시도는 그만큼 실패의 위험도 동반한다. 이는 기술적인 펀더멘탈의 문제라기보다는, 생소함으로 인해 생태계 조성 과정에서 직면할 수 있는 현실적인 도전들 때문이다. 하지만 역사적으로 모든 시장에서의 혁신은 항상 기존의 틀을 깨는 과감한 시도에서 비롯되었음을 상기할 필요가 있다. 현재 정체되어 있는 블록체인 시장에 신선한 바람을 불어넣는 이러한 도전적 시도들은, 그 최종적인 결과와는 별개로 충분한 주목과 평가를 받을 자격이 있다. 어쩌면 훗날 크로미아의 이러한 혁신적 접근이 수많은 양산형 블록체인들의 새로운 표준이 될지도 모를 일이다.
특히나, 크로미아는 데이터베이스와 프로그래밍 언어에서 굉장히 큰 차별점을 가지고 있기에 기존 블록체인들과는 다른, 새로운 시장을 개척하는 모습을 보여주길 기대한다.
