요즘 개인적으로 재미있게 보고 있는 프로젝트가 하나 있어서 스토밍을 목적으로 이야기를 해보려합니다.
이더리움의 스케일링 솔루션에 대해서는 이전의 자료들을 통해서 다들 어느정도는 이해를 하셨으리라고 생각합니다. 샤딩, 플라즈마, 오프체인과 같은 방식들에 대해서 말이죠. 최근에는 우리가 익히 알고 있는 이러한 개념보다 조금은 '발전된' 모습들이 선보여지려 하고 있습니다. 플라즈마의 개념에서 안정성을 더한 플라즈마 캐시, 라이덴 네트워크의 라우팅 문제를 N-Hub과 리밸런싱으로 극복하고자하는 Liquidity.network가 그것입니다.(이더리움 Dapp에서 발생하는 네트워크 연산에 대한 문제를 RLC(iexec)가 해결하고자 한다는 이야기가 있는데 백서에 명확하게 나와있지 않아 제외했습니다.)
오늘 이야기할 것은 기존의 오프체인 솔루션에서 개선점을 찾으려하는 Liquidity.network입니다. ICO에 해당하는 암호화폐이니 만큼, 주관적인 생각과 판단보다는 기술적인 부분에 한정하여 어떻게 라우팅문제를 풀어가려 하는지에 대해 이야기하고자 합니다. 나중에 기회가 되면 플라즈마캐시에 대해서도 이야기를 해볼 예정입니다.
Liquidity.network or Raiden network?
Liquidity.network는 이더리움 네트워크 내에서 사용될 것으로 기대되는 새로운 오프체인 솔루션입니다. 이전에 채널방식의 전송과 결제에서 이야기한 대부분의 문제점의 해결책을 제시한 프로젝트라는 점이 눈에 띄는 부분입니다. 예치금이 채널에 묶이는 문제점, 그리고 A->B->C->D와 같이 수 많은 hub으로 연결되는 오프체인의 결제방식에서 발생하는 fee에 대한 문제에 대한 것들입니다. 각각의 문제점이 무엇인지 간략하게 다시 한번 알아보면 다음과 같습니다.
첫 번째, 예치금이 채널에 묶임에 따라 발생하는 문제점은 유동성 문제입니다. 이러한 유동성에 대한 이슈는 수많은 오프체인 채널이 중첩되는 중심점(Center hub)에서 더욱 부각 될 수 있습니다. 중심점에 위치하고 있는 참여자는 자신을 통해 열려있는 수 많은 오프체인 채널이 닫히지 않는다면 자신의 예치금을 유동화 시킬 수 있는 기회를 얻기 힘들기 때문입니다. 중심점이 아니라 하더라도 거래에 직접 참여하는 사람들의 예치금의 유동성에 대한 문제도 적다고 보기 어렵습니다.
두 번째는 hub에 대한 문제점은 위에서 이야기한 fee에 대한 문제점도 있지만, 라우팅의 문제점도 존재합니다. A->D로 한번에 처리할 수 있는 오프체인 채널이 서로간의 링크를 통해서 A->B->C->D로 연결될시에 연산에 대한 어려움(HTLC의 복잡성)이 필수적으로 발생한다는 것이죠. 라이덴 네트워크의 FAQ를 참고하면 해당 라우팅 문제에 대해서 이미 인지를 하고있습니다. 다음은 라이덴에서 라우팅의 복잡성에 대해서 답변한 라이덴의 답변입니다.
"라우팅의 효율화를 가져가기 위해서는 중앙화를 가져가거나, 익명성을 포기해야한다"
Liquidity.network는 이 문제들을 어떻게 해결하려하는가? - 중앙화, 익명서의 포기
참고 : 항상 그렇듯 ICO에선 자신들의 문제점을 이야기하진 않는다
Liquidity.network의 개발자중에 한명이 작성한 REVIVE라는 논문에서 기존 오프체인 방식의 문제점 중에 하나인 예치금에 대한 해결책에 대해서 이야기를 해놓았습니다. 핵심은 예치금에 대한 지속적인 '오프체인' 리밸런싱입니다. 예를들어 오프체인의 참여자가 총 10이더리움 만큼을 오프체인에 기입했다고 가정해보겠습니다. 이 참여자는 자신이 오프체인을 통해서 사용할 이더리움을 예상하여 넣어놨으나, 시간이 흘러 대략 5이더만 사용하면 되었고 나머지를 리밸런싱(오프체인을 빠져나오는, 또는 다른채널로 넘어가려는)하려고합니다. 기존에 오프체인 결제방식에서는 여기서 필히 온체인에 해당 내역이 기입되는 전송이 발생하게 되고 비용적인 문제가 발생을 하게됩니다. 인출시에는 5인더만큼이 오프체인에서 나왔다는 기록이 필요하고, 다른 채널로 들어가기 위해서는 나오고 들어오는 2번의 온체인의 기록이 필요한 것이죠.
이러한 일반적인 채널 결제 방식에서 리밸런싱이 없다면, 참여자의 잔고의 쏠림은 필연적으로 발생합니다. 그리고 이러한 쏠림은 채널결제 방식에 대한 무용론을 만들어내는 이유가 됩니다. 끊임없이 리밸런싱을 온체인상에 기록해야하기에 더이상 싸지 않다는 것이죠.
위의 그림과 같이 A,B,C가 모두 연결되어 있음에도 불구하고, 서로간의 채널에서 잔고의 쏠림으로 연결이 전혀 이루어지지 않습니다. 만약 여기서 A,B,C가 서로간에 거래를 하기위해서는 2가지 선택지가 있습니다. 다른 참여자를 통해서 연결을 하던지(라우팅의 복잡성), 잔고 리밸런싱을 한다는 것입니다.
다른참여자를 통해서 연결을 할 경우를 우리는 Multi-hub이라고 부릅니다. 이들은 자신의 자산을 채널에 담보로 제공하기에 fee를 지급받기에, hub이 많아진다면 비용에 대한 문제가 발생합니다. 밸런스의 리밸런싱이 이루어진다면 A->B와 같이 한번에 연결될 문제가, A->E->B로 연결된다는 것입니다. 이러한 hub의 복잡성은 오프체인임에도 불구하고 거래를 싸지 않게 만듭니다.
대부분의 오프체인 솔루션이 안고 있는 문제점이 이러한 라우팅의 복잡성과 복잡성이 만들어내는 비용입니다. 그런데 만약 A,B,C 가 서로 보유하고 있는 채널간의 리벨런싱이 이루어진다면(위에서 이야기한 이더리움의 리밸런싱처럼) 라우팅의 복잡성의 문제는 사라집니다. 그런데 이게 말처럼 쉬울까요? 채널의 개설시점에서 서로간의 오프체인 잔고를 기입하는 특성상 말입니다. Liquidity.network는 해당 문제를 해결하고자 하고 있습니다.
참고 : Liquidity.network의 리밸런싱 구조, 리더가 채널참여자들의 컨센서스를 취합하는 역활
바로 채널간 통신을 위한 커뮤니케이션 네트워크를 통해서 말입니다. 여기서 리더의 역활이 중요합니다. 리더는 투표로 인해 선출됩니다. 리더는 수많은 채널의 참여자들의 리밸런신 요청을 취합하여 정리하는 역활을 합니다. 당연하겠지만 수많은 참여자들의 정확한 리밸런싱 계산을 위해서 리더는 가장 최근의 채널 참여자 잔고를 알아야합니다. 여기서 문제점이 발생합니다. 바로 익명성이 희석된다는 것입니다.
리더만이 전체 잔고의 변화를 확인 할 수 있게 되지만, 과거 오프체인의 거래에서는 익명성에 대한 보안이 유지가 되었습니다. Liquidity.network는 리밸런싱을 위해 익명성을 부분적으로 나마 포기했습니다. 이더리움의 투명성을 완화시키기 위해 도입된 오프체인인데, 빅브라더가 등장해버린 것과 같은 것입니다.
빠르고, 비용이 싸지만, 약간이지만 투명해져 버렸습니다. 트레이드 오프의 관계에서 이전의 오프체인 채널방식과는 다른선택을 한것입니다. Liquidity.network에서 개발의 근간이 되었다는 REVIVE논문은 리밸런싱을 통해 익명성이 희석되나 리더에게만 잔고가 오픈되므로 문제는 없다는 결론으로 끝나고 맙니다.
참고 : N-Hub
여기까지 이야기한 예치금의 리밸런싱은 이미 연결된 수많은 채널에서의 효율화입니다. 다만 리밸런싱을 통해서 줄일 수 없는 채널의 길이에 대한 문제 또한 라우팅의 복잡성중에 하나입니다. Liquidity.network는 이에 대한 해결책으로 중앙화된 hub을 제시하고 있습니다. 기존에 라이덴 네트워크, 라이트닝 네트워크에서는 사용자간의 연결을 위해 수 많은 hub의 거치기 마련입니다.
이는 앞서 State Channel의 문제점에서 한번 언급한 문제입니다. 예를들어 A가 D에게 채널을 통해서 전송을하기위해서는, 그 사이에 있는 수많은 hub을 통해서 가야한다는 것입니다. 이로인해 hub들의 유동성 유지에 대한 문제부터(위에서 이야기한 리밸런싱을 통해 해결하고자함), hub을 거쳐가는 과정에서 발생하는 fee의 발생은 필수 적입니다.(변동성 자산을 예치함에 따른 보상)
이를 수많은 참여자를 연결한 센터 헙(Center hub, 임의로 만든 단어)의 도입을 통해서 해결하고자 합니다. 기존 수개의 hub을 지나는게 아니라 대략 4번정도의 hub만을 거치면 채널이 완성되게 만드는 구조입니다. 기존 오프체인 채널 결재 방식대비 빠르고, 효과적일 수 있습니다.
다만 이는 중앙화에 대한 문제점을 만들어내게 됩니다. 채널결제의 참여자들은 센터에 대한 신뢰를 필히 가져야한다는 것이겠지요. 기존의 오프체인 솔루션들이 목적으로 하는 신경망의 모습을 가정해보겠습니다. 서로가 모두 연결되는 모습을 추구하게 된다면, 이는 Liquidity.network에서 이야기하는 hub의 중앙화 없이도 효율적인 연결과정을 추구할 수 있게 됩니다.
위에 있는 라이트닝 네트워크의 최근 테스트넷 신경망 구성도를 본다면, 이미 어느정도 hub의 중앙화는 진행중에 있습니다. 오프체인의 확장을 위해 기꺼이 자신의 자산을 변동성에 노출하려하는 참여자가 존재한다는 것입니다. 이미 Liquidity.network에서 이야기하려하는(디자인상으로 강제하려는) 중앙화는 진행 중에 있습니다. (다만 기존의 오프체인 채널방식은 장기적으로는 중앙화가 아닌, 수많은 hub의 시장진입으로 탈중앙화가 진행될 것으로 기대) 하지만 Liquidity.network가 과연 단기적인 시각으로, 라우팅의 효율화만을 위해 Center hub이라는 개념을 도입했을까요?
추가적으로 Liquidity.network는 hub의 중앙화를 통해 참여자의 자산 유동성을 만들어내고자 합니다. hub에 참여하고 있는 멤버는 해당 hub의 다른 참여자를 위해 대신 유동성을 공급해줄 수 있습니다. 이로 인해 수많은 멤버가 포함되어있는 Center hub의 경우에는 그만큼 편리성이 높아질 수 있을 것입니다. 다만 여기서 궁금증은 하나 생겨납니다. Center에 유동성을 제공하는 해당 hub의 참여자에게 낮은 fee가 주어지지는 않을 것입니다. 역활의 집중화는 fee의 상승을 이끌 가능성이 높기 때문입니다.
Liquidity.network의 개발진척도는 투명한가?
현재 깃헙에는 REVIVE의 프로토타입만이 업로드 되어있습니다. 카피캣을 막기위해 현재 개발과정들은 오픈되지 않고 내부적으로 진행되고 있다고 합니다. 마지막 Commit이 6개월 전이라 개발의 속도에 대한 판단은 불가합니다. 향후 코드가 오픈된다면 과연 Liquidity.network가 기존의 오프체인 스케일링 솔루션에서 단순 포크 + REVIVE(리밸런싱)인지, 초기부터 코드를 만들어냈는지 판단할 수 있을 듯합니다.
현재 프로젝트의 참여자는 2명입니다. 단순 포크 + REVIVE라는 방식으로 판명이 날 경우에는 향후의 개발 속도에 대한 우려감이 부각될 수 있을 것으로 판단합니다.
Conclusion
대부분의 암호화폐에 존재하고 있는 문제점을 해결하기 위해서는 기존에 암호화폐가 가지고가 했던 것들을 하나씩 포기해야합니다. 속도를 위해서 탈중앙화를 포기하고, 속도를 위해서 안정성을 포기하는. Liquidity.network도 라우팅의 효율화를 위해서 익명성을 포기했습니다. 다만 최근 ICO모금액을 본다면 시장은 익명성을 버리더라도 오프체인의 라우팅 문제를 더 크게 인식을 한듯합니다.
이러한 발전이 지속되다 보면 어느센가 우리가 알고 있는 암호화폐가 아닐 수 있습니다. 탈중앙화와 연결를 통한 효율화의 개념이 아닌, 오히려 집중되고 보안이 낮은 그런 블록체인말입니다. 지금의 암호화페가 발전을 하기 위해서 얼마나 자신의 특징과 장점을 버리는지 보는것은 가슴아프지만, 재미있는 포인트가 될 듯 합니다.
감사합니다.