KYVE
Cosmos
시간이 지날수록 블록체인의 크기는 비대해지고, 이에 따라 데이터 접근성의 문제가 발생한다.
해서 카이브는 별도의 독립적인 블록체인이지만, 다른 블록체인들이 쉽게 데이터에 접근 가능하도록 데이터 저장과 접근을 도와준다.
메인넷 런칭 후 1년이 지난 지금, 카이브는 약 7개의 블록체인에게 데이터 서비스를 제공해주고 있는데, 앞으로 인플레이션 분할(Inflation splitting)과 같은 공격적인 정책들을 통해 생태계를 확장해나갈 카이브의 귀추가 주목된다.
테라와 FTX 사태 이후로 새로운 레이어1들이 등장하는 추세가 꺾이는듯 싶더니, 온 체인 활동이 다시금 활발해지고 이더리움과 롤업이 감당할 수 있는 확장성의 한계가 명확하게 드러나자 “빠르고 독립적인 블록체인”에 대한 시장의 수요가 다시금 생기게 되었다. 덕분에 트랜잭션 병렬처리 (특히나 EVM 병렬처리)를 지원하는 신규 레이어1 체인들이 시장의 큰 주목을 받기도 하였고(트랜잭션의 연관성을 파악하고 병렬처리를 진행하는 수이나 솔라나 같은 블록체인들과, 트랜잭션들의 연관성을 파악하기 전에 옵티미스틱하게 병렬처리를 실행하고보는 세이, 모나드, 앱토스와 같은 블록체인들이 바로 그것들이다), 트랜잭션이 최종적으로 확정되는데에 걸리는 시간인 파이널리티가 1초 미만인 블록체인들(인젝티브, 수이, 세이, 앱토스, 등이 여기에 해당된다)도 덩달아 큰 주목을 받게 되었다.
느리게만 느껴졌던 블록체인들이 트랜잭션을 즉각적으로 처리하고, 트랜잭션 병렬처리를 통해서 주어진 시간동안 처리할 수 있는 트랜잭션의 수가 늘어난 것은 유저 경험 측면에서 굉장히 큰 가치라고 할 수 있다. 이제 블록체인이 진정으로 ‘사용 가능한’ 수준까지 올라오려는 시도라고 생각하기 때문이다. 하지만, 이러한 블록체인들도 문제가 없지는 않다. 당장에 많은 사람들이 걱정하는 ‘탈중앙성’문제는 차치하더라도, 블록체인 자체적으로 수많은 트랜잭션을 너무 빠르게 처리하기 때문에 블록체인의 스테이트 값이 커지게 되고 이는 벨리데이터간에 스테이트 값을 싱크하는 것도 어렵게 만든다. 빠른 블록체인일수록 더 많은 트랜잭션을 담은 블록을, 빠른 시간에 더 많이 처리해야 하기 때문에, 블록이 쌓이는 양도, 처리 하는데 소요되는 시간도 굉장히 짧아야 할 것이다. 결국 이러한 결과들은 1) 노드 운영 비용을 증가시키고 2)블록체인의 전반적인 퍼포먼스를 저하시키며 3) 노드간에 싱크를 하는 것도 어렵게 만드는 문제들을 야기한다(이 문제들에 대해선 밑에서 좀 더 자세히 후술하겠다).
물론 “빠른 블록체인”을 만들고 있는 재단들이 이러한 문제를 모르는 것은 아니고, 각자만의 방법으로 해결하려고 노력하고 있으나, 모든 체인들이 각자만의 해결책을 강구하기란 비용적으로도 시간적으로 어려움이 많은 것 역시 사실이다. 그래서 오늘은, 독자적인 블록체인으로서 다른 블록체인들이 가지고 있는 데이터 문제를 해결하려는 프로젝트를 소개하고자 한다. 바로 카이브 네트워크(KYVE Network)다.
정말로 다양한 블록체인들이 등장하고 있는 가운데, 필자가 가치있는 블록체인을 보는 기준은 간단하다. “이들이 풀려는 문제가 명확한가?”가 바로 그것이다. 물론 모든 블록체인들이 각자 저마다의 문제의식은 있겠지만, 정말로 그 문제의식이 이 시장에 필요한지에 대한 여부가 굉장히 중요하다고 생각한다. 그리고 필자가 카이브를 처음 알게 되었을 때가, 카이브가 솔라나와 협업을 한다는 발표 때였는데, 그 때 필자가 카이브를 보고서 느꼈던 인식은, 이들이 정말로 해결 되어야 하는 문제를 파고들고 있었다는 것이었다. 그렇다면 이들은 어떤 문제의식들을 가지고 있었으며, 그 문제들이 왜 해결되어야 하는지를 한 번 살펴보자.
첫 번째 문제는 바로 비용에 있다. 블록체인의 과거 데이터들에 접근하고 관리하기 위해서는 아카이브 노드(Archival Nodes)를 필연적으로 운영해야 하는데, 이는 개발자들이 과거 데이터에 잡근함에 있어서 큰 비용을 부과하게 만든다. 개발자들이 데이터에 원활학게 접근하기 위해서는 블록체인 데이터 전체를 저장해야 하는데, 그 스토리지 비용 역시 시간이 지남에 따라서 더 늘어난다. 뿐만 아니라, 블록체인 자체적으로 아카이브 노드에게 주는 별도의 인센티브가 없기 때문에 노드 참여자들이 자발적으로 아카이브 노드를 운영해야할 인센티브가 없다. 결국 이런 문제는 블록체인이 더 오래되면 오래될수록 아카이브 노드의 수는 줄어드는 현상을 야기한다.
아카이브 노드의 수가 줄어들면 이는 필연적으로 중앙화의 문제로 연결된다. 과거 데이터에 접근하려고 할 때 소수의 아카이브 노드에 의존해야 하기 때문이다. 또한 기존 데이터 관리 솔루션들은 대부분 중앙화 되어있는 경향이 있기 때문에 데이터를 관리하기 위해서 중앙화 솔루션을 사용하게 되면, 애초에 블록체인을 사용하게 된 이유를 상당부분 희석시키기 때문에 결과적으로 모순적인 상황이 발생한다. 탈 중앙 네트워크를 표방하는 블록체인에는 데이터 관리 솔루션 역시 탈 중앙화 되어야 논리적으로 모순이 없고, 블록체인을 사용하는 목적이 희석되지 않는다. 이러한 이유로 카이브 역시 블록체인으로 구축되었다고 볼 수 있다.
리소스의 문제로 아카이브 노드의 수가 줄어들고, 결국 이 때문에 중앙화 문제가 발생하면, 블록체인 데이터는 점차 접근/검증하기 어려워지게 된다. 이러한 문제는 필자가 처음에 언급한 일명 ‘고성능 블록체인’들을 제외하고도, 웬만한 블록체인들은 언젠가 마주할 수 밖에 없는 문제다. 왜냐하면 블록체인은 본질적으로 팽창하는 네트워크이기 때문이다. 이게 무슨 말일까? 블록체인은 체인의 시작점인 제네시스 블록부터, 가장 최근의 블록까지를 누군가가 저장을 하고 계속해서 실시간으로 블록들을 추가해야한다. 그 뜻은, 시간이 지나면 지날수록 블록체인이 차지하는 용량은 커질 수 밖에 없다는 것이고 블록체인의 용량이 커질수록 방대한 양의 데이터를 저장하는 것과 더불어 이들에 접근하는 것도 매우 여러워진다. 하지만 위에서 언급했듯 블록체인 데이터 전체를 저장하는 아카이브 노드의 수는 점진적으로 줄어들게 되고, 중앙화 되어있는 데이터 솔루션들에 의존할 수 밖에 없어짐에 따라서 데이터에 대한 접근과 검증이 어려워지는 것이다.
노드들이 트랜잭션을 처리하는데에 드는 시간이 늘어나면, 이는 블록체인의 퍼포먼스 저하를 의미한다. 이는 고성능 블록체인들을 저성능 블록체인으로 만들고, 기존의 블록체인들도 더 느린 블록체인들로 만들게 된다. 안그래도 느려서 대중화가 어려운 블록체인의 성능이 더 느려진다면, 누가 블록체인을 사용하려고 할까? 해서 카이브는 써드파티 블록체인이지만 데이터 접근과 검증을 별도로 해주어서, 블록체인들의 데이터 접근과 검증 문제를 해결하려고 하는 것이다.
요약하자면, 카이브는 데이터 저장과, 접근, 그리고 검증을 효율적으로 만들어줄 뿐만 아니라 다른 블록체인들로 하여금 비용을 아낄 수 있도록 해주고, 자체적인 블록체인을 도입하여 카이브에 의존하는 블록체인들이 중앙화 문제에 노출되지 않도록 프로덕트를 설계했다고 볼 수 있다. 그렇다면 카이브는 어떤 구조로 이루어져 있기에 이런 서비스들을 효율적으로 제공할 수 있는 것일까? 카이브 네트워크는 사실 다른 블록체인들과 비교했을 때 꽤 독특한 구조를 가지고 있는데, 해서 다음 챕터에서는 카이브 네트워크의 구조와 작동 방식들에 대해서 알아보고자 한다.
필자는 다양한 블록체인들을 리서치 하면서 수많은 블록체인들이 가진 다양한 구조들을 살펴봐왔지만, 카이브 네트워크는 이들중에서도 가장 독특한 구조를 가지고 있다. 물론 카이브 네트워크도 자체적인 컨센서스를 가지고 있다는 점 레이어1 블록체인으로 분류되지만 그 내부를 살펴보면 모듈러 블록체인처럼 두 가지 레이어들을 가지고 있기 때문이다. 카이브에서는 이 구조를 듀얼 레이어 구조라고 부르는데, 듀얼 레이어는, 컨센서스 레이어와 프로토콜 레이어로 분류되어 이 두 레이어가 각자 다른 역할을 수행하는 구조를 의미한다. 카이브는 왜 이렇게 독특한 구조로 네트워크를 설계했을까?
카이브 네트워크의 구조에 대해서 자세히 알아보기에 앞서서, 카이브 네트워크의 구조를 완벽하게 이해하기 위해 먼저 숙지해야하는 개념들을 정의하고 시작해보자.
2.1.1 Data Pool 또는 Storage Pool
우선 첫 번째로 데이터 풀(Data Pool or Storage Pool)이다. 이들은 단어 그대로 데이터 소스들(하나의 데이터 풀당 하나의 데이터 소스에서만 데이터를 가지고 있을 수 있다. 즉 코스모스 허브에서 데이터를 가져오는 데이터 풀은 오직 코스모스 허브에서만 온 데이터들을 저장하고 검증할 수 있다)을 중심으로 만들어지는 하나의 풀이라고 볼 수 있고, 누구나 거버넌스를 통해서 자유롭게 풀을 생성할 수 있고 해당 풀에 저장하고자 하는 데이터 스트림을 설정할 수 있다. 또한 데이터 풀은 100% 온 체인에서 작동하기 때문에 투명하고 탈 중앙화된 환경에서 운영된다. 그렇다면 여기서 드는 의문점은, 누가, 왜 이 풀들을 만들고 관리해야 하냐는 부분이다. 그래서 등장하는 것이 카이브의 프로토콜 레이어이고, 필자가 후에 후술할 프로토콜 레이어의 벨리데이터가 해당 풀들에 자유롭게 참여하여 데이터를 검증하는 형태로 풀이 운영된다.
즉, 다시 말하면 데이터 풀에 들어가있는 데이터들은 아직 검증되기 전의 데이터들이 모여있는 하나의 풀이라고 볼 수 있고, 여기서 벨리데이터들이 해당 데이터들을 검증하면 해당 데이터들이 저장되는 형태다.
2.1.2 Data Bundle Proposal
데이터 번들은 말 그대로 여러 데이터를 번들 형태로 모으는 것을 이야기 한다. 데이터를 왜 모아야 할까? 그냥 데이터를 저장하는 것은 어렵지 않은 일이지만, 데이터를 다양한 곳에서 가져와 저장하는 것은 꽤나 복잡한 일이기 때문이다. 그래서 카이브에서는 데이터들을 한 그룹으로 모아서 좀 더 효율적으로 처리하는 방법인 번들 프로포절을 제시한다.
카이브는 이러한 작업을 통해 데이터들을 계속해서 가져오기 보단, 각각 번들을 라운드마다 제출해서 효율적인 데이터 전달,저장 작업을 가능하게한다. 각각의 라운드마다 하나의 번들이 제시되고, 해당 번들에는 다양한 출처에서 넘어온 데이터들이 들어있다고 볼 수 있다. 데이터의 번들들이 최종적으로 제출되는 곳은 바로 위에서 설명된 데이터 풀이고, 해당 번들을 벨리데이터들이 검증하게된다.
2.1.3 Uploader and uploader selection
업로더는 위에서 언급한 번들 프로포절을, 데이터 풀에 제시하는 역할을 한다. 좀 더 자세히 말하면, 업로더들은 데이터의 출처들로부터 데이터를 가져와서 탈 중앙 저장소에 저장하는 역할을 하고, 데이터들을 데이터 풀에 보내서, 이를 벨리데이터로 하여금 검증할 수 있도록 하는 중요한 역할을 한다.
업로더는 라운드별로 (바로 밑에서 후술할) 프로토콜 벨리데이터들 중(체인 벨리데이터가 아닌)에서 선정되고, 위임 받은 토큰의 양(보팅 파워)이 더 많은 벨리데이터가 더 높은 확률로 업로더에 선정될 수 있는 방식이다.
2.1.4 Protocol Validator
프로토콜 벨리데이터들은 업로더들이 보낸 데이터 번들이 유효한지 아닌지를 검증하는 검증자 역할을 수행한다. 벨리데이터들은 데이터의 검증을 위해서, 분산 스토리지에 저장되어있는 데이터를 불러와 자신들이 불러온 데이터와 업로더들이 보낸 데이터들을 대조하여 검증한다. 그 이후 해당 데이터들이 일치하는지(Valid), 일치하지 않는지(Invalid)에 대해서 투표할 수 있다.
*한 가지 유의할 점은, 카이브 네트워크엔 두 종류의 벨리데이터가 있으며 필자가 여기서 설명한 벨리데이터는 프로토콜 레이어의 벨리데이터라는 부분이다.
2.1.5 후원자(Funder)
후원자들은 카이브의 데이터 풀에 자금을 후원해주는 역할을 한다. 이들은 특정 풀이 저장하는 데이터에 대한 니즈가 있는 주체들로써, 특정 풀이 관리하고 있는 데이터를 사용하고자 하는 프로젝트거나 자신들에 대한 데이터를 저장하길 바라는 재단일 수도 있다. 누구나 후원자가 될 수는 있지만 특정 풀을 후원하는 것에 대한 보상은 별도로 존재하지 않는다.
위의 개념들을 숙지하였다면, 이제 본격적으로 카이브의 독특한 듀얼 레이어에 대해서 살펴보고, 왜 카이브가 레이어1 블록체인임에도 불구하고 레이어를 두 개로 나눠서 태스크를 수행하는지에 대해서도 살펴보자.
2.2.1 Chain Layer
체인 레이어는 우리가 흔하게 알고있는 레이어1 체인과 다를바 없이 컨센서스와 이에 따른 프로토콜의 보안을 담당한다. 카이브는 코스모스 SDK를 기반으로 만들어졌으며, 여느 코스모스 SDK 기반 블록체인들과 다를바 없이 dPoS 시스템을 가져갔다. 체인 벨리데이터의 역할 역시 여느 코스모스 SDK 기반 블록체인의 벨리데이터의 역할과 차이점이 없기 때문에 체인 벨리데이터들에 대한 자세한 설명을 생략하도록 하겠다.
2.2.2 Protocol Layer
체인 레이어가 기존 블록체인과 비슷한 부분이라고 한다면, 프로토콜 레이어가 기존 블록체인들과 다른 부분이라고 할 수 있는데, 프로토콜 레이어는 필자가 위에서 설명한 데이터 풀을 관리하는 것이 주 역할이라고 할 수 있다. 이곳이 카이브에 대한 실질적인 유즈케이스가 나오는 곳이라고 할 수 있으며, 프로토콜 레이어의 벨리데이터는 데이터를 수집하고 분산 영구저장 프로토콜인 Arweave(이하 알위브)에 데이터를 저장한 뒤, 저장된 데이터를 검증(어떤 데이터가 유저들이 원하는 데이터인지 계속 검증하는 역할)하는 역할까지 수행한다(물론 반대로, 알위브에 저장된 데이터를 가져와서 데이터를 요청한 유저에게 데이터를 검증해서 전달하는 역할도 수행한다).
*밑에서 후술하겠지만, 유저들은 체인 벨리데이터와 프로토콜 벨리데이터 모두에게 토큰을 위임할 수 있다.
2.2.3 Why Dual Layer?
카이브의 듀얼 레이어 구조를 접하면 처음 드는 생각은 이 구조가 꽤 ‘복잡하다.’라는 것이다. 왜 카이브는 복잡성을 감수하면서까지 듀얼 레이어 구조를 채택했을까? 그 이유들은 여러가지가 될 수 있을 거 같은데 우선 첫 번째 이유로는 바로 최적화에 있다고 생각한다. 만일 같은 벨리데이터가 데이터 풀에 대한 관리까지 진행하면서 블록체인의 보안까지 담당한다면 한 쪽을 최적화 시키지 못할 수 있는 상황이 발생할 수 있다. 체인 벨리데이터의 역할은 단순히 네트워크를 유지보수 하는 것이 아니다. 거버넌스를 포함한 부가적인 업무들도 수행해야 하는데 이들이 데이터 풀에 있는 데이터를 검증하고 가져오고 저장하는 역할까지 수행한다면 전반적인 퍼포먼스가 떨어질 수도 있다.
두 번째로, 확장성측면에서도 듀얼 레이어 구조가 이점이 있다고 보여지는데, 각각 다른 업무를 수행하는 레이어를 둘로 나눔으로써 데이터에 대한 수요가 증가했을 때 체인 레벨에서의 영향을 주지 않고 프로토콜 레이어가 독자적으로 스케일업 할 수 있다는 부분도 굉장히 큰 장점이라고 보여진다.
마지막으로, 카이브는 다양한 체인들을 지원해야 하는데(보통 다른 블록체인이나 개발자들을 위해 존재하므로) 프로토콜 레이어는 체인 레이어와 독립적으로 움직이기 때문에 체인의 코어를 건드리지 않고도 다양한 체인들을 지원해줄 수 있다는 부분 역시나 듀얼 레이어가 가지는 장점이라고 생각한다.
카이브 네트워크의 독특한 구조에 대해서 이해가 되었다면, 이제 본격적으로 카이브 네트워크가 어떻게 작동하는지에 대해서 알아보도록 하자.
2.3.1 How does Data Pool work
데이터 풀이 운영되려면 1) 누군가가 데이터를 받아서 번들로 묶은 뒤 2)해당 번들을 풀에 제출하고 3)제출 된 데이터를 검증한 다음에 4) 분산 스토리지에 저장을 해야한다. 블록체인의 핵심은 보상을 통한 행동 유도인 만큼, 카이브의 데이터 풀에도 이 네 가지 태스크를 자생적으로 수행시키기 위해서 인센티브 구조를 설계하였다.
카이브 데이터 풀의 보상은 후원자(funder)들로부터 채워지는데, 카이브가 검증하고 저장하는 데이터는 결과적으로 누군가가 필요로하는 데이터들이기 때문에, 해당 풀을 지원해주는 주체(funder)들은 카이브가 대신 검증해주고 저장해주는 데이터들을 원하는 프로젝트들이나 재단이 될 가능성이 높다(물론 후원자(funder)는 누구나 될 수 있다.) 카이브를 통해 후원자들은 효율적으로 검증된 데이터에 접근할 수 있고, 카이브의 프로토콜 벨리데이터들은 자신들이 데이터를 가져오고, 저장하고, 검증하는 행위들에 대한 보상을 받을 수 있다.
그렇다면 일반 유저들은 어떨까? 일반 유저들도 ‘위임’을 통해 풀 보상을 받을 수 있다. 필자가 잠깐 위에서 언급했듯 유저들은 체인 벨리데이터 또는 프로토콜 벨리데이터들에게 토큰을 위임할 수 있고, 프로토콜 벨리데이터들에게 토큰을 위임하는 경우 위임하는 양에 비래해서 프로토콜 벨리데이터들이 가져가는 보상의 일부를 가져갈 수 있다. 반대로, 만약 자신이 토큰을 위임한 벨리데이터가 데이터를 잘못 검증하거나 잘못된 데이터를 가져온 경우 슬래싱을 당할 수 있기 때문에 위임을 할 때 프로토콜 벨리데이터를 신중하게 선택해야한다. 체인딴에서 뿐만 아니라 프로토콜딴에서도 이런 PoS 메커니즘을 둔 이유는, 블록체인을 유지하는 원리를 그대로 데이터 풀에 적용하기 위해서다. 델리게이션을 많이 받은 벨리데이터는 데이터를 검증하거나 업로드로 선정될 수 있는 확률이 높아지기 때문에 이에 따른 보상도 더 많이 받아갈 수 있다.
Interpool Security
Source: KYVE Docs
기존의 카이브는 프로토콜 벨리데이터 하나당 하나의 데이터 풀만 관리할 수 있도록 하였다. 하지만 이러한 방식은 여러 방면에서 비효율을 야기했는데, 벨리데이터 하나당 하나의 풀만 관리하게 할 경우 많은 위임을 받은, 비교적 안정적인 벨리데이터가 관리하는 데이터 풀의 수가 적어지기 때문에 카이브가 제공하는 서비스 자체의 확장성에 문제가 생긴다. 결국 데이터 풀의 안정성도 해당 풀을 관리하는 벨리데이터가 얼마나 많은 양의 토큰을 위임받았는지에 따라서 결정되기 때문에, 카이브는 신뢰받는 벨리데이터들이 좀 더 다양한 데이터 풀을 관리할 수 있도록 새로운 이니셔티브를 도입하였다.
이것을 가능하게 하기 위해서는, 새로운 개념을 추가해야만 했는데, Valaccounts가 바로 그것이다. 벨리데이터들은 각각의 valaccount에 검증을 할 수 있는 일종의 권한을 부여하여 프라이빗 키나 메모닉을 건내주지 않고도 다양한 각각의 풀을 관리할 수 있도록 설계하였기 때문에 안전하게 데이터 풀을 여러개 운영할 수 있게 된다. 이를 통해 카이브는 데이터 풀의 보안성을 높히고, 벨리데이터와 스테이커는 수익을 창출할 수 있는 윈윈 상황을 만들 수 있다.
2.3.2 Lifecycle of data in KYVE
데이터 풀이 어떻게 작동하는지를 이해했다면, 카이브에서 데이터가 전반적으로 어떻게 움직이는지 그 경로를 다양한 경우의 수에 따라서 살펴보도록 하자.
Source: KYVE Docs
우선 카이브에서 데이터가 움직이는 경로는 세 가지로 나뉘는데 각각의 경우의 수를 한 번 살펴보면서 카이브가 어떻게 작동하는지를 알아보자. 보통은 데이터의 출처에서 아카이빙 할 새로운 데이터가 나왔을 때 아카이빙 작업을 시작하기 때문에, 데이터의 출처로부터 새로운 데이터가 있는 경우부터 경로들을 알아보도록 하겠다.
데이터의 출처로부터 데이터를 받았으나 주어진 시간내에 데이터를 제시하지 못한 경우
데이터의 출처로부터 추가적으로 가져올 데이터가 있기 때문에 데이터들을 하나로 모아서 번들로 만든다→ 번들을 스토리지 ID와 메타데이터와 함께 데이터 풀에 제시한다 → 주어진 시간이 지났다 → 업로더는 주어진 시간내에 번들을 제시하지 못한 것에 대한 벌점(포인트)를 받는다 → 일정 포인트 이상을 받게 되면 해당 업로더는 슬래싱을 당한다.
데이터의 출처로부터 새로운 데이터가 있었고, 성공적으로 번들을 제시했으나 검증에 실패한 경우
데이터의 출처로부터 추가적으로 가져올 데이터가 있기 때문에 데이터들을 하나로 모아서 번들로 만든다 → 번들을 스토리지 ID와 메타데이터와 함께 데이터 풀에 제시한다 → 번들에 있는 데이터들에 대한 벨리데이터들의 투표가 시작된다 → 데이터들이 유효하지 않다는 결론에 도달한다 → 업로더들은 유효하지 않은 데이터들을 제시한 것에 대한 패널티로 슬래싱을 당한다.
데이터의 출처로부터 새로운 데이터가 있었고, 성공적으로 번들을 제시하였으며 검증에 성공한 경우
데이터의 출처로부터 추가적으로 가져올 데이터가 있기 때문에 데이터들을 하나로 모아서 번들로 만든다 → 번들을 스토리지 ID와 메타데이터와 함께 데이터 풀에 제시한다 → 번들에 있는 데이터들에 대한 벨리데이터들의 투표가 시작된다 → 데이터들이 유효하다는 결론에 도달한다 → 업로더들은 보상을 수령하고 번들은 분산 스토리지에 저장된다.
우리는 지금까지 카이브 네트워크의 독특한 구조와 그 작동원리에 대해서 알아보았다. 하지만 카이브의 구조에 대해서 이해한 사람들은, 도대체 이 구조를 어떻게 유지하고 강화하는지에 대한 질문이 들 수 밖에 없는데, 카이브의 네트워크 구조가 독특한 만큼 토크노믹스 역시나 다른 블록체인들과의 차별점이 존재한다.해서, 이번 챕터에서는 카이브의 토크노믹스를 알아보고, 카이브 토큰이 어떤 방식으로 분배가 되며 보상을 주는지에 대해서 살펴보고자 한다.
체인 레벨에서의 토크노믹스는 기존 코스모스 SDK 기반 체인들과 비교해서 크게 다른 점이 없다. 다른 점이라고 한다면 체인 레벨에서의 소각 모델이 있다는 부분이라고 할 수 있는데, 카이브는 벨리데이터의 이해관계(꾸준한 인플레이션을 통해서 지속적으로 토큰 보상이 나오는 것)와 토큰 홀더의 이해관계(토큰의 가치를 제고하는 것)를 최대한 일치시키기 위해서 EIP-1559 모델을 일부 차용하여 인플레이션에 상한을 두지 않으면서도 프로토콜 수수료의 일부를 꾸준하게 소각시켜 토큰의 가치를 제고하고자 하는 모델을 도입하였다.
프로토콜 레벨에서의 토크노믹스는 필자가 위에서도 설명했지만, 인플레이션으로 유지되는 체인 레벨의 토크노믹스와 달리 제 3자의 후원자에 의해서 유지가 된다. 즉, 카이브를 통해서 데이터 서비스를 받고 싶어하는 주체들이 카이브 토큰을 사서(물론 이것도 다중 토큰 펀딩 이후로 바뀔 예정이고 이에 대해서는 후술하겠다), 자신이 원하는 데이터가 있는 풀에 자본을 할당하여 프로토콜 벨리데이터들이 해당 풀을 관리할 인센티브를 지급하는 형태로 움직인다.
만약 특정 풀에 대한 후원이 멈추게 되면, 해당 풀은 후원이 들어오기 전 까지 멈추게 되고, 해당 풀이 멈추면 데이터를 더 이상 활용할 수 없기 때문에 해당 풀을 사용하던 프로젝트들이나 재단들이 지속적으로 풀에 대한 후원을 하도록 장려한다.
하지만 여기서 드는 질문, 과연 후원으로 유지되는 데이터 풀이 얼마나 영속 가능한지에 대한 부분이다. 카이브의 차별점은 프로토콜 레이어에서 나온다. 하지만 이에 비해서 네트워크 딴에서 프로토콜 레이어를 유지하고 영속 가능하게 만들어주는 이니셔티브는 전혀 없다는 것이 사실 모순적이다. 카이브가 프로토콜 레이어를 실질적인 유즈 케이스가 나오는 곳으로 강조하고 싶다면, 네트워크 레벨에서도 프로토콜 레이어를 보완하고 강화할 수 있는 이니셔티브가 필요하다.
그래서 등장한 것이 인플레이션 분할(Inflation splitiing)이다.
굉장히 거창한 워딩 같지만 간단하게 말하면, 기존에는 체인 레이어에만 보상으로 갔던 인플레이션의 일부가 프로토콜 레이어에도 가게됨으로써 후원자에게 의존하던 프로토콜 레이어의 인센티브 구조를 강화하여 프로토콜 레이어가 좀 더 안정적으로 운영될 수 있도록 토크노믹스를 수정하였다.
카이브는 v1.5 업그레이드를 통해 다중 코인 후원 이니셔티브를 계획하고 있다. 다중 코인 후원은 말 그대로 여태까지 카이브 토큰으로만 운영되던 후원을, 좀 더 다양한 체인들의 토큰으로 확장하는 이니시티브를 말한다. 이는 후원자 입장에서도, 스테이커의 입장에서도 윈윈이 될 수 있는 이니셔티브라고 할 수 있는데, 왜냐하면 후원자의 입장에선(특히 재단일 경우) 자신들의 토큰을 카이브 토큰으로 변환하지 않아도 직접적으로 자신들의 토큰을 후원하여 카이브의 데이터를 사용할 수 있고, 보상을 받는 입장에서도 카이브 뿐만 아니라 다양한 토큰으로 보상을 받을 수 있기 때문이다.
프로토콜 레이어에 스테이킹 한 유저는 카이브를 스테이킹하고, $TIA(셀레스티아), $ATOM(코스모스), AXL(악셀러)등의 토큰을 수령할 수 있게 될 예정이다. 카이브의 파트너 프로토콜들에 장기적으로 긍정적인 전망을 가지고 있다면, 카이브 토큰을 프로토콜 레이어에 스테이킹 하는 것도 좋은 방법이 될 수 있을 거 같다.
필자가 해당 아티클을 쓰는 날짜를 기준(2024년7월30일)으로, 카이브의 메인넷은 런청된지 약 14개월이 조금 넘었다. 카이브는 지난 14개월간 약 6TB의 데이터를 아카이빙 하였고, 5,700만개의 트랜잭션을 소화했으며, 약 7개의 블록체인들에 대해서 11개의 데이터 풀을 운영하고 있으니 꽤 괄목할만한 성장을 했다고 할 수 있다. 이는, 카이브와 같은 서비스를 필요로 하는 써드파티가 있다는 증빙이라고 할 수 있으며 카이브의 입장에서는 PMF(Product Market Fit)을 찾아가는 단계라고 할 수 있을 것이다.
그럼에도 불구하고, 카이브가 지원해주는 7개의 블록체인들 모두가 다 코스모스 기반이라는 점, 또 필자가 서론에서 이야기 했던, 카이브와 같은 프로토콜이 진정으로 필요한 고성능 블록체인들이 아직 카이브에 온보딩하지 않았다는 점에서 조금은 아쉬운 부분이 존재한다. 또한, 카이브와 파트너십을 맺은 블록체인들이 꽤 많은데에 반해 이들 모두에게 데이터 풀을 제공해주고 있지 않고 있다는 사실이 아쉽게 느껴진다.
그렇다면 카이브가 외연확장을 하기위해서는 무엇이 필요할까? 개인적으로 답은 현재 카이브가 실행하는 이니셔티브들에 있다고 생각하는데, 그것과 연관지어 필자의 생각을 공유하자면 아래와 같다:
공격적인 비즈니스 확장이 필요하다.
공격적인 비즈니스 확장이라는 말이 조금 모호하게 들릴 수 있지만, 여느 스타트업이 그렇듯 우선은 재정적인 출혈이 불가피 하더라도, 공격적으로 자신들의 븨즈니스를 확장할 필요가 있다. 이 논리를 카이브에 적용하면, 제3의 후원자(funder)가 나타나기 전에 메이저 블록체인들과 관련된 데이터 풀을 카이브 자체적으로 구성하여 토큰으로 리워드를 주는 것이 될 것이다. 이를 위해서는 네트워크 레벨에서의 인플레이션은 불가피한데, 과도한 인플레이션이 프로토콜의 입장에서 적자라고 한다면, 기존 스타트업이 확장하는 방식과 일맥상통 하다고 생각한다.
고객의 리텐션을 만들기 위해서 가장 먼저 선행되어야 하는 것은 우선 ‘사용해보는 것’이다. 필자는 카이브의 서비스와 프로덕트가 좋다고 생각하지만, 사용하지 않으면 모른다. 해서 필자는 카이브가 공격적으로 지출을 늘려서 비즈니스를 확장하면 새로운 기회들을 모색할 수 있을 것이라는 생각이 든다. 그리고 카이브는 이미 infation spliting 과 같은 이니셔티브를 통해 프로토콜 레이어를 강화하려는 움직임을 보여주고 있어서, 여기서 좀 더 지출을 확장해보면 어떨까 하는 생각이 든다.
B2C 딴의 이니셔티브가 필요하다.
카이브는 프로토콜이나 탈중앙 애플리케이션과 같은 주체들이 고객이라고 할 수 있기 때문에 B2C보다는 B2B에 가깝다. 보통 B2B 프로토콜들의 가장 큰 문제는 리테일과의 연관성이 적다는 부분이다. 결국 그렇게 되면 프로토콜 자체의 인지도도 떨어지고, 이는 결국 카이브로 하여금 프로토콜을 온보딩 시키기에 어려움을 만든다. B2C딴에서의 인지도를 올리게 되면, 더 많은 프로토콜들이 카이브에 온보딩이 되는 것을 희망할 것이다.
필자와 카이브의 개인적인 인연은 꽤 오래되었다. 메인넷을 런칭하기 전에 카이브에 대한 리서치 아티클을 작성한 것도 필자였고, 그 이후에도 꾸준히 관계를 맺어오면서 카이브를 지켜봐왔다. 필자는 누구보다 오랜시간동안 카이브를 지켜봐왔지만, 이들만큼 본질에 집중하는 네트워크는 찾아보기 어렵다. 다른 프로토콜들이 단기적인 내러티브에 편승했을 때도 카이브는 꾸준히 자신들의 역할을 수행하며 데이터 풀을 하나씩 늘려나갔다. 비록 현재 크립토 시장이 투기와 밈으로 점철되어 있다고는 하나, 카이브와 같이 묵묵하게 자신들의 역할을 수행하는 네트워크들이 주목을 받아야 한다고 생각했다. 그리고 이번에 카이브에 대해서 다시 리서치를 하면서 느낀 것은, 카이브 커뮤니티와 카이브 팀원들도 계속해서 자신들의 부족한 점을 찾고, 보완해나가기 위해서 노력하고 있다는 부분이다. 다중 코인 후원도 그렇고, inflation spliting도 그런 보완들의 일환이라고 생각한다. 그래서 카이브의 앞으로가 더 기대가 되고, 많은 사람들이 카이브에 대해서 좀 더 알아갔으면 하는 마음에서 아티클을 작성하게 되었다. 결국 블록체인은 시간이 지날수록 데이터 접근과 저장에 부담을 느끼기 때문에 분명히 카이브가 해줄 수 있는 역할이 크다고 생각한다. 시간은 카이브의 편이다.
