밴드 프로토콜은 되지만, 체인링크는 되지 않는 것. (What Band Protocol Can do, but Chainlink can’t)
글쓰기를 시작하며
우선 필자는 체인링크(Chainlink)를 비난하거나 비판할 목적으로 이 글을 쓰는 것이 아님을 명확하게 하고싶다. 체인링크는 탈 중앙 오라클 솔루션을 제공하는 프로젝트중 가장 성공한 프로젝트고 이에 대해서 아무도 이견이 없다. 2017년도부터 꾸준히 프로젝트를 개발해왔고 최근에서야 시장의 인정을 받고 어느새 메이저 프로젝트가 되었다. 결국 밴드 프로토콜과 체인링크는 탈 중앙 오라클 서비스라는 하나의 거대한 목표를 가지고 같은 도전을 하는 것이므로 체인링크의 성공이 밴드 프로토콜에게도 상당히 긍정적인 영향을 끼친다는 것을 잘 알고있다.
본 글의 목적은 단순히 밴드 프로토콜과 체인링크의 차이점을 다루는데에 있다. 결국 탈 중앙 오라클 서비스를 제공하는 프로젝트는 필연적으로 스마트 컨트랙트 플렛폼을 상대로 비즈니스를 해야하는데, 그럴 때 마다 밴드 프로토콜과 체인링크의 차이점이 무엇인지 궁금해하기 때문에 아예 그 점들을 밴드 프로토콜의 관점에서 정리해보는 것도 좋을거 같다는 판단에서 해당 미디엄 글을 작성하게 되었다. 해당 포스팅을 작성하기전에 이 점을 명확하게 하고자 한다.
밴드 프로토콜이 체인링크와 다를 수 밖에 없는 이유
체인링크는 오라클 솔루션의 선두주자로 2017년부터 시장에 나온 프로젝트고 밴드 프로토콜은 올해 9월, 바이낸스 런치패드 프로젝트로 선정되어 시장에 나왔다. 시기적으로 보더라도 밴드 프로토콜이 2년이 늦다. 밴드 프로토콜은 2년이란 시간동안 체인링크가 가지고 있는 단점을 최대한 보완하고자 했다. 물론, 더 늦게 나왔다고 하여서 무조건적으로 더 좋다는 이야기는 아니다. 체인링크도 2년이란 시간동안 수 많은 보완과 업데이트를 거쳤음을 알고있다. 하지만 밴드 프로토콜은 체인링크와 접근법 자체를 다르게 함으로써 체인링크와 경쟁력을 갖추려고 하였다. 밴드 프로토콜이 체인링크와 차별점을 둔 부분은 크게 두 부분이 있다:
- 확장성(Scaling Advantages)
- 개발자 친화적 환경(Developer Friendliness)
오늘의 포스팅은 밴드 프로토콜의 CEO인 소라비스의 입을 빌려 두 부분을 설명하고자 한다.
확장성(Scaling Advantages)
우선, 밴드 프로토콜은 프로토콜 레벨에서 데이터 제공자들(Data Providers)로 하여금 데이터 포인트들을 계속해서 블록체인으로 보낼 수 있게 한다. 그리고 이것은 데이터 쿼리를 스마트 컨트랙트에서 이용 가능하게 만들어준다. 그러므로, 단일 트랜잭션으로 복수의 디앱들이 쿼리를 요청할 수 있고 그렇기 때문에 데이터 제공자들에게 추가적인 비용이 들어가지 않는 구조이다.
체인링크에선 디앱이 데이터를 요청하면 각각의 데이터들은 모든 오라클 과정을 거쳐서 블록체인에 들어가게 된다. 이러한 특징 때문에 이더리움을 기준으로는 하나의 쿼리당 5–10개의 트랜잭션을 요하게 된다(디앱들에게서 한 번, 체인링크 자체로부터 한 번, 그리고 각각의 데이터 제공자들로부터 콜백 트랜잭션까지 요한다. 이 뜻은 X 개의 데이터 제공자가 있다면 X개의 트랜잭션이 필요하다는 뜻이다). 만약 체인링크에서 10개의 디앱들이 같은 데이터를 소비한다고 가정해보면 이는 이더리움상에서 50–100개의 트랜잭션을 요한다는 이야기다.
이러한 부분들을 미루어 봤을 때, 디앱들이 더 많은 쿼리를 요청할 수록 밴드 프로토콜이 더 효율적일 수 밖에 없다는 결론에 도달하게 된다.
개발자 친화적인 환경(Developer Friendliness)
밴드 프로토콜은 데이터를 온 체인에서 쉽게 이용할 수 있게 함으로써, 스마트 컨트랙트로 하여금 데이터를 가져오기 위한 동시 함수호출(synchronous function call)을 아주 간단하게 처리할 수 있도록 한다. 간단하게 말하면, 개발자 입장에서 밴드 프로토콜과 소통하기 위해선 간단히 함수 호출만 하면 된다는 것이다. 체인링크에서는 개발자들이 현재 진쟁하고 있는 함수 실행 상태를 저장하고 완전히 개별적인 트랜잭션에서 쿼리가 해결되면 그 때야 비로소 저장한 함수 실행 상태를 가져와서 진행하던 함수호출을 이어가야 하는 어려움이 있다. 이런 식의 소통환경은 사실 굉장히 복잡하기 때문에 밴드 프로토콜이 하는 것과 같이 동시 함수호출을 통해서 단일 트랜잭션에서 함수들을 동기화하여 개별 트랜잭션에 함수를 옮겨서 재실행하는 번거로움을 없애는 것이 훨씬 더 효율적이다.
밴드 프로토콜은 동시 함수호출을 통해서 단일 트랙잭션에서 데이터를 전달하지만, 체인링크의 경우, 데이터 리퀘스트에 한 번 트랜잭션을 발생시키고 블록체인 상에서 블록 확정시간까지 기다린 다음에 리퀘스트에 대한 반응을 하기 위해서 또 다른 트랜잭션을 발생시켜야 하는 번거로움이 있다. 이러한 부분들을 감안하면 밴드 프로토콜이 체인링크보다 오프체인 데이터를 훨씬 더 빠르게 전달할 수 있고 이러한 속도의 차이는 개발자들, 특히 디앱들로 하여금 훨씬 더 좋은 유저경험을 선사한다.
확장성과 개발자 친화적인 환경은 오라클의 성공에 굉장히 중요한 부분이라고 생각한다. 확장성은 단순히 속도의 문제만이 아니라 비용적인 측면에서도 상당히 중요하고 개발자 친화적인 환경 조성은 오라클 서비스의 궁극적인 고객인 디앱들에게 더 좋은 유저경험을 선사할 수 있다.
그 외에 존재하는 차별점들
필자가 가장 중요하다고 생각하는 부분들을 제외하고도 밴드는 체인링크와 차별점을 보이는데. 스테이킹도 그 중 하나이다. 밴드 프로토콜 토큰 자체는 스테이킹 한다고 할 수 없으나, 우리는 밴드 토큰을 스마트 컨트랙트에 예치하면 이를 담보화하여 데이터셋 토큰이 발행되고 데이터셋 토큰을 스테이킹하여 이자를 받을 수도 자신이 지지하는 데이터 제공자를 선출할 수도 있음을 알고있다. 또한, 본딩 커브를 통해서 데이터셋 토큰과 밴드 토큰을 거래하여 프로토콜 내부적으로 차익을 낼 수 있다(XFN/BAND의 가격은 변동되고 자체적으로 데이터셋 토큰과 BAND토큰을 거래하여 BAND토큰의 개수를 늘리는 것도 가능하다).
또한, 밴드 프로토콜은 각각의 데이터마다 데이터 세트들이 존재하고 각각의 데이터 세트마다 개별적인 데이터셋 토큰을 둘 수 있다. 이를 통해서 밴드 프로토콜은 데이터를 개별적으로 관리하고, 혹시나 악의적인 데이터 제공자가 발생할 경우 단일 토큰을 사용할 때 보다 더 빨리 감지할 수 있도록 하였다.
마지막으로 밴드는 네이티브 페이먼트를 가능하게 함으로써, 굳이 밴드 토큰이나 데이터셋 토큰을 가지고 있지 않더라도 쿼리 비용을 낼 수 있는 구조를 만들었다. 이는 모든 디앱들이 밴드 토큰이나 데이터셋 토큰을 가지고 있지 않을 것이라는 너무나도 당연한 사실에 기반한다. 밴드를 구매하지 않고도 밴드의 서비스를 사용할 수 있어야 하고, 밴드 프로토콜은 해당 기능을 유니스왑과 같은 DEX 서비스를 통해 구현하였다.
하지만 밴드가 갈 길은 멀다.
이러한 차별점들에도 불구하고 밴드 프로토콜이 탈 중앙 오라클 서비스로 성공하기 위해선 상당히 먼 길을 가야한다. 1) 일단 밴드 프로토콜이 시장에 나온지 3개월 밖에 안된 비교적으로 새로운 프로젝트라는 점. 2)그렇기 때문에 프로토콜 자체에 대한 검증이 필요하고, 디앱과 스마트 컨트랙트 플랫폼들에게 신뢰를 쌓아야 한다는 점. 3) 아직까지 파트너십이 탄탄하지 못해서 다양한 파트너십을 통해 유즈 케이스를 만들어야 한다는 점. 등이 밴드가 개선해야 할 점이다.
반면 체인링크는 어떤가? 1) API에 연동하는 것이 매우 유연하고. 2) 선구자로써 분명 시장에서 가지는 이점이 존재할 뿐만 아니라. 3) 탄탄한 파트너십을 갖추었고. 4) 굉장히 큰 규모의 커뮤니티를 구성하고 있다. 밴드 프로토콜이 한가지 거부할 수 없는 사실이 있다면 바로 체인링크가 있었기 때문에 지금의 밴드 프로토콜도 존재할 수 있다는 사실일 것이다. 체인링크가 업계의 선구자로써 다양한 문제들을 마주하고 해결하는 과정들을 보면서 밴드는 밴드만의 오라클 솔루션을 시장에 내놨다. 체인링크가 있었기 때문에 지금의 밴드도 존재할 수 있는 것이다.
경쟁도 좋지만, 탈 중앙 오라클 서비스를 제공하는 프로젝트로써 같이 성장하여 블록체인이 가진 문제들을 보완하고, 더 나아가 블록체인이 상용화 될 수 있는 세상을 같이 꿈꾸는 동지로써 모두가 다 잘 되었으면 하는 바람이다.
