[KYVE series] #02 KYVE, Bundlr 로직 분석
본 게시글은 Arweave을 사용한 데이터 영구 저장 검증 솔루션인 KYVE에 대해 분석합니다. KYVE 분석 글은 시리즈로 게시되었으며, 본 글을 읽기 전 Arweave 및 KYVE의 개요를 다룬 1편을 먼저 읽으시는 것을 추천해 드립니다. 이번 글에서는 KYVE의 핵심 기능인 데이터 업로드, 검증 방법을 분석하며 Arweave를 사용한 다른 솔루션인 Bundlr와의 차이점을 비교합니다.
Author
신우진(@pangyoalto)
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
Reviewed By 정재환
[KYVE series]
- Arweave와 KYVE의 개요 & Data availabilty
- KYVE, Bundlr 로직 분석
목차
- Intro
- 데이터 업로드
- 데이터 검증
- 다른 솔루션(Bundlr)의 데이터 검증 과정 살펴보기
- Bundlr와의 차이점
- 결론: KYVE의 의의
1. Intro— 프로토콜 노드와 체인 노드
앞글에서 살펴보았듯이, KYVE의 네트워크를 구성하는 노드의 종류는 두 가지입니다. 노드는 KYVE 블록체인을 지원하고 보안성을 책임지는 노드인 체인 노드, 사용자가 다른 프로젝트의 데이터를 Arweave에 업로드하고 검색할 수 있게 도와주는 프로토콜 노드가 있습니다.
체인 노드가 운영하는 KYVE 블록체인은 Cosmos SDK로 만들어졌으며 텐더민트(Tendermint) 합의 알고리즘을 사용하기 때문에 자체 토큰인 $KYVE를 위임하여 Proof of Stake로 합의를 진행합니다. 체인 노드는 $KYVE를 위임받고 합의 알고리즘을 통해 체인의 보안성을 유지하지만, $KYVE로 유틸리티 기능을 만들어내지 못합니다.
프로토콜 노드는 KYVE 체인 위에서 KYVE의 핵심 기능인 데이터 업로드 및 검증을 수행합니다. 즉, 유저에게서 들어온 데이터에 대해 합의를 진행해 유효성을 검사하고 Arweave를 통해 영구 저장을 보장합니다. 프로토콜 노드의 상태는 체인 노드로 넘겨져 저장됩니다.
프로토콜 노드는 풀(pool)에 참여하여 풀 안에서 밸리데이터로서 역할을 수행합니다. KYVE를 사용하는 체인마다 풀이 각각 존재합니다. 이는 데이터 스트림마다 고유의 특징이 있기 때문에, 런타임을 따로 만들어줘야 하기 때문입니다.
풀은 현재 최대 50개의 밸리데이터를 가질 수 있습니다. 밸리데이터의 개수가 제한되어 있기 때문에, 가장 적게 $KYVE를 스테이킹한 밸리데이터보다 더 많이 스테이킹을 해야 밸리데이터가 될 수 있습니다. 밸리데이터가 잘못된 행동을 하면, 스테이킹한 $KYVE를 슬래싱하여 올바른 행동을 하도록 유도합니다.
풀의 밸리데이터가 올바르게 데이터 업로드를 수행하면, 풀로부터 $KYVE를 보상으로 받습니다. 풀이 제공하는 $KYVE는 유저가 지불을 하는 것으로, 풀을 사용하는 유저가 많아질수록 비용을 공유하는 효과가 생깁니다.
이번 글에서는 프로토콜 노드가 수행하는 데이터 업로드, 검증 방법을 정리하고, 프로토콜 노드의 코드를 통해 실제로 어떻게 구현이 되었는지 확인합니다.
2. 데이터 업로드
데이터를 업로드하고 검증하는 것은 한 라운드 동안 진행이 되며, 라운드마다 밸리데이터 중에서 데이터를 업로드하는 업로더(uploader)가 선택됩니다. 업로더는 성공적으로 데이터를 업로드 시 보상을 받으므로, 밸리데이터가 스테이킹하거나 위임받은 $KYVE가 영향을 미치는 랜덤 함수를 통해 선택됩니다.
유저가 보낸 데이터들은 업로더에게 모이는데, 업로더는 충분한 데이터양이 모일 때까지 기다렸다가 데이터 묶음으로 Arweave로 업로드합니다. 이 데이터 묶음을 번들(bundle)이라고 합니다. 번들은 많은 데이터가 묶여 있기 때문에 각각 데이터를 따로 Arweave로 업로드를 하는 것보다 싸게 업로드를 할 수 있습니다. 따라서 유저는 KYVE를 통해 좀 더 효율적으로 Arweave를 이용할 수 있습니다.
실제 번들을 생성하는 함수를 보면 반복문으로 데이터(entry)를 번들에 추가하여 정해진 크기를 넘어야 반복문에서 나와 번들을 생성하는 것을 볼 수 있습니다.
번들이 생성되면 업로더는 Arweave로 번들을 업로드합니다. 코드를 보면 번들이 압축되어 Arweave에 제출이 되는 것을 확인할 수 있습니다. 이렇게 KYVE는 비용을 줄여 효율적으로 업로드를 합니다.
번들을 성공적으로 업로드하면 Arweave로부터 트랜잭션을 응답으로 받습니다. 응답으로 받은 트랜잭션에는 트랜잭션의 id가 기록되어 있어, 다른 노드가 나중에 해당 id를 통해 Arweave로부터 직접 번들을 받아 대조하여 검증을 할 수 있습니다.
트랜잭션에 담긴 id(bundleId)와 기타 정보들을 메시지로 담아 업로더가 사인하고 밸리데이터들로 번들을 업로드했음을 전파합니다.
전달받은 밸리데이터는 이제 업로더가 올바르게 번들을 처리했음을 검증하기 시작합니다.
3. 데이터 검증
밸리데이터는 전달받은 트랜잭션의 id를 통해 Arweave로부터 번들을 다운받습니다(this.downloadBundleFromArweave). 그리고 데이터베이스로부터 번들에 포함되어 있던 데이터들을 저장합니다(this.loadBundle).
다른 밸리데이터에게 번들 업로드를 했다는 사실을 전파할 때 트랜잭션의 id 뿐만 아니라 메시지에 fromHeight를 넣어 전파를 같이합니다(위의 submitBundleProposal 참고). 이를 통해 유저가 제출한 데이터를 임시로 담고 있는 데이터베이스로부터 원본 번들을 복구해낼 수 있는 것입니다.
밸리데이터는 복구한 번들과 Arweave로부터 다운받은 번들의 해시값을 비교함으로써 업로더가 제대로 역할을 수행했는지 확인합니다. 올바르게 수행이 되었음을 확인하면, 밸리데이터는 해당 번들에 대해 투표를 합니다.
번들의 찬성 투표가 50%를 넘어가면 번들 프로포절이 받아들여집니다. 이때부터 사용자는 KYVE를 통해 자신이 제출한 데이터에 대해 쿼리를 할 수 있습니다. 업로더는 올바르게 업로드한 것을 인정받아 번들에 대해 보상받습니다.
업로더가 보상받는 로직의 코드는 $KYVE 토큰이 이동하므로 프로토콜 노드가 아닌 체인 노드의 코드를 살펴봐야 합니다. 체인 노드의 코드는 앞에서 언급했듯 Cosmos-SDK로 만들어져 로직이 모듈의 keeper에 구현되어 있습니다.
체인 노드는 찬성 투표율이 50%가 넘는지 계산하여 해당 프로포절이 유효한지 확인합니다. 유효한 프로포절임이 확인이 되면 리워드(bundleReward)를 계산합니다.
- 리워드(bundleRward)는 최소 리워드 값(OperatingCost)에 바이트당 스토리지 값*번들의 바이트로 계산됩니다.
- 1에서 계산한 리워드에서 네트워크 비용(networkFee)으로 일부가 차감됩니다(약 1%).
- 업로더의 델리게이터에게 제공되는 리워드(delegationReward) 10%를 차감합니다.
- 남은 리워드가 최종적으로 업로더에게 돌아가는 보상이 됩니다(uploaderPayout).
프로포절이 완료되면 다음 라운드가 시작되어 새로운 업로더를 뽑습니다.
4. 다른 솔루션(Bundlr)의 데이터 검증 과정 살펴보기
이 글에서 다루는 Bundlr의 소스 코드는 2022.06.28 기준이며, 현재도 계속 업데이트가 되고 있습니다
KYVE 외에도 Arweave를 이용해 다른 체인의 데이터 스토리지 역할을 해주는 솔루션들이 여럿 있습니다. 그중에서도 최근 520만 달러의 투자 유치에 성공한 Bundlr가 수행하는 데이터 스토리지 역할을 KYVE와 비교해보겠습니다.
KYVE가 Arweave에서의 데이터 검색 프로세스를 표준화한 쿼리 인터페이스를 제공해서 사용자들로 하여금 데이터의 접근을 용이하게 했다면, Bundlr는 Arweave의 사용성 및 확장성을 높여주는 것에 초점을 맞추고 있습니다.
사용자가 데이터를 Bundlr에 업로드하면, Bundlr의 노드가 다른 업로드된 데이터와 합쳐서 일정 시간 동안 쌓인 데이터를 Bundle(묶음)로 만듭니다. Bundlr의 노드는 이 Bundle을 Arweave에 업로드하는데, 비용은 Bundlr가 보유하고 있는 AR 토큰 Treasury에서 처리합니다. Treasury에서 AR 토큰을 지불하므로 사용자들은 Arweave에 데이터를 업로드하기 위해 AR 토큰을 구매하지 않아도 됩니다. 그 대신 Bundlr는 사용자들에게 ETH와 SOL, MATIC 등 다른 토큰을 받을 계획입니다.
Bundlr는 특이하게 데이터를 업로드를 하는 Bundler 노드와 업로드된 bundle을 검증하는 밸리데이터의 코드가 나누어져 있습니다. KYVE와 다르게 밸리데이터가 업로더 역할도 하는 것이 아닌, 아예 별개의 역할로 나뉘어 있는 것입니다. 아직 Bundle을 업로드를 하는 노드의 코드는 아직 공개되어 있지 않아 밸리데이터의 코드만 살펴볼 수 있었습니다.
밸리데이터의 역할은 Bundler로부터 받은 증서에 서명하고 Bundlr 트랜잭션을 검증합니다. 증서는 총 3개의 밸리데이터가 서명하며 트랜잭션의 이동에 책임을 집니다. 트랜잭션이 성공적으로 종료되면 리포트를 작성하는 리더 밸리데이터와 그 외 2개의 밸리데이터가 인센티브를 나눠 갖습니다.
먼저 밸리데이터가 sign을 하는 과정을 알아봅시다. Bundler에게 Arweave로 업로드될 데이터를 받고 올바른 데이터인지 확인 후 이에 대해 sign을 합니다.
이후 Bundler 노드가 sign된 데이터를 Arweave에 업로드를 하면 밸리데이터들은 업로드된 데이터가 자신이 검증한 데이터가 맞는지 한 번 더 확인을 해야합니다.
밸리데이터들은 데이터를 보낸 bundler의 주소를 통해 arweave로부터 데이터를 다운로드합니다. Bundler가 보낸 가장 최신 트랜잭션을 query하여 가져오는 방식입니다(get_latest_transactions).
밸리데이터가 데이터를 잘 다운받았다면, 데이터들로부터 트랜잭션들을 뽑아내 각 트랜잭션으로부터 tx_receipt를 만듭니다. tx_receipt는 블록, 트랜잭션 id, 서명을 포함합니다. 밸리데이터는 이 서명을 검증함으로써 데이터의 유효성을 증명하게 됩니다.
서명을 검증하는 코드를 좀 더 살펴봅시다. 밸리데이터는 블록과 트랜잭션 id를 이용해 해시 함수를 통해 message라는 변수를 생성합니다. 이 message 변수와 tx_receipt의 서명을 decode한 것을 비교함으로써 arweave에 업로드된 데이터가 변조되었는지 확인합니다.
이 방식은 KYVE가 데이터의 유효성을 검사하는 방식과 사뭇 다른 방식입니다. 두 프로젝트가 검사하는 방식의 차이점을 다음 문단에서 간단히 정리해보겠습니다.
5. Bundlr와 KYVE의 데이터 검증 비교
KYVE의 밸리데이터들은 같은 체인 위에 있어, 유저가 보낸 데이터 원본을 각자의 노드가 가지고 있습니다. 그래서 자신이 가지고 있는 데이터를 Arweave에서 다운받은 데이터와 대조함으로써 유효성을 확인합니다.
반면 Bundlr는 데이터를 업로드하는 Bundler라는 노드가 밸리데이터와 구분되어 존재합니다. Bundler는 밸리데이터에게 데이터를 보내 sign을 받고, 밸리데이터는 Arweave에 업로드된 데이터를 다운로드 받아 해당 데이터의 서명이 위조되지 않았는지 확인합니다.
Bundlr의 문제점은 데이터를 업로드하는 Bundler가 밸리데이터에게 데이터를 전송한다는 점입니다. Bundler가 처음부터 밸리데이터에게 위조된 데이터를 주고, Arweave에도 업로드를 한다면 밸리데이터는 해당 데이터가 위조된 것인지 알 수 없습니다.
Bundlr는 Bundler 노드를 운영시 자체 토큰인 $BNDLR 토큰을 스테이킹하게 해 Bundler가 잘못된 행동을 할 시 슬래시를 한다고 명시해놓았습니다. 잘못된 행동을 감지할 수 있을지도 의문이지만, $BNDLR 토큰이 유의미한 가치를 가질지도 확실하지 않습니다.
KYVE는 유저가 데이터 업로드를 요청할 때 비용을 자체 토큰인 $KYVE로 받습니다. 그러나 앞서 말했듯 Bundlr는 ETH, SOL, MATIC 등 Native 토큰으로 비용을 청구할 계획이라고 합니다. 그렇다면 자체 토큰인 $BNDLR의 유틸리티가 Bundler 노드의 스테이킹 용도 외에 없기에 가격 낮게 유지될 확률이 높고, Bundler 노드가 큰 부담 없이 악의적인 행동을 할 가능성이 커집니다.
물론 Bundler의 노드 코드 공개가 안 되었을뿐더러 $BNDLR 토큰도 현재 사용되고 있지 않을 만큼 Bundlr가 초기 프로젝트이기 때문에 섣불리 판단을 내리기 어렵습니다. 하지만 현재까지 두 프로젝트의 진행 상황을 보았을 때, KYVE가 Bundlr에 비해 좀 더 신뢰할 수 있는 구조를 가졌다고 생각이 되었습니다.
6. 결론: KYVE의 의의
Arweave는 좋은 스토리지 프로토콜이지만 기존 블록체인과 연결해서 사용하기에 불편한 점이 있었습니다. 블록체인의 데이터를 Arweave로 업로드를 할 때 중앙화될 우려가 있으며, 유저는 자신이 제출한 데이터가 올바르게 업로드가 되었는지 확인을 할 수 없습니다.
KYVE는 이러한 니즈를 해결하기 위해 나온 프로젝트 중 가장 발전된 솔루션입니다. 앞에서 보았듯 Bundlr와 다르게 자체 L1 체인을 운영하는 부분이 유효했습니다. 이를 통해 자체 토큰인 $KYVE 토큰을 통해 인센티브 구조를 만들어 냈고, 데이터 업로드를 어느 정도 탈중앙화하는 데 성공하였습니다. 그뿐만 아니라 코스모스 생태계로 들어오면서 IBC로 타 체인에서 $KYVE를 사용할 수 있는 길도 열어놓았습니다.
KYVE는 아직 정식 출시를 하지 않고, 테스트넷만 운영하고 있습니다. 하지만 벌써 약 20개의 풀을 보유하고 있을 정도로 관심을 받고 있습니다. 특히 솔라나와 같은 데이터 스토리지에 단점을 가진 체인들은 KYVE와 같은 솔루션이 더욱 반가울 것입니다.
KYVE의 목표는 다른 프로젝트들이 KYVE를 이용하여 쉽게 프로젝트를 운영하는 것입니다. KYVE가 자신의 목표를 향해 나아가 타 레이어1 체인들의 든든한 조력자가 될 수 있을지 같이 지켜봅시다.
