블록체인 확장성 솔루션 시리즈 3–1 :: Interchain Overview
Youngtaek OH(@robbieinertia)
Hyun-Cheol Gong (@hyuncheol0)
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
서울대학교 블록체인 학회 ‘디사이퍼(Decipher)’에서 블록체인의 스케일링 솔루션에 관한 글들을 시리즈로 연재합니다. 시리즈의 세 번째 주인공은 Interchain solution 입니다. 3–1. Interchain Overview(Focus on 사이드체인), 3–2. Relayer코드 리뷰로 나누어 설명합니다.
인터체인과 사이드체인은 무엇이고 왜 필요한가?
블록체인에서 인터체인과 사이드체인은 마치 전산학에서 분산컴퓨팅과 병렬컴퓨팅의 차이를 묻는 것처럼 특별한 구분 없이 혼용되어 쓰이는 단어이다. 이 글에서는 두 용어에 대해 학문적으로 정의하기 보다는, 공통적으로 담고 있는 의미와 어감의 차이로 구분하고자 한다. 우선 두 용어는 공통적으로 체인과 체인 간의 정보 교환 기술이라는 뜻을 담고있다. 예를 들어, 비트코인 블록체인에서 발생한 트랜잭션을 이더리움 블록체인에 반영할 수 있는 기술이 있다면 이를 인터체인 또는 사이드체인 기술이라고 말할 수 있다. 다만 사이드체인은 인터체인보다 조금 더 좁은 의미를 담고있다. 사이드체인이라는 개념은 2014년에 발표된 Adam Back의 Enabling Blockchain Innovations with Pegged Sidechains이라는 논문[1]에서 처음 등장하였는데, 여기에서 사이드체인은 뒤에서 소개할 Two Way Pegging을 통한 체인 간 자산 이동을 의미한다. 본 글에서는 넓은 의미의 체인간 통신 기술을 지칭할 때 ‘인터체인’을, Adam Back이 논문에서 정의한 기술을 지칭할 때 ‘사이드체인’을 사용하도록 하겠다.
그렇다면 인터체인은 왜 필요할까? 이 질문에 대한 대답은 TCP/IP라는 표준 네트워크 프로토콜의 발전사를통해 유추할 수 있을 것 같다. TCP/IP는 1972년에 미국 국방부의 ARPAnet이라는 사설망에서 이메일을 주고받기 위해 나왔다. 1990년대에 들어서는 Sun, HP등 큰 기업들이 해당 프로토콜을 사용하기 시작했고, 이메일을 비솟한 e-commerce등 다른 분야에서도 응용이 되었다. 급기야 인터넷의 발전으로 사설망이 아닌 공용망으로까지 번져서 전 세상을 연결시키는데까지 이르렀다. 이 모든것이 컴퓨터간 전송 프로토콜인 TCP/IP가 널리 사용되었기에 가능했다. 인터체인은 한마디로 정의하면 블록체인계의 TCP/IP같은 역할을 하고자 하는 기술이다. 현재 블록체인은 비트코인과 다양한 알트코인의 블록체인 네트워크로 분화되어있다. 하지만 언젠가 인터넷처럼 모든 Localized된 체인들이 표준화된 프로토콜로 서로 통신하여 자유롭게 자산거래가 가능하다면 어떨까? 그 파급력은 쉽게 예상하기 어렵다.
그런데 사실 인터체인은 이런 이상적인 목표 뿐 아니라 다음과 같은 현실적인 장점 때문에 등장했다.
확장성
확장성이란 특정 자원이 투입된 양에 대해 얼마만큼의 성능이 향상될 수 있는지 나타내는 지표이다. 현재 비트코인의 트랜잭션 처리속도는 약 7 TPS 정도이다. TPS는 Transaction Per Second의 약자로, 초당 처리할 수 있는 트랜잭션의 수를 의미한다. VISA같은 서비스를 제공하려면 약 2000TPS 정도가 필요한데, 비트코인의 전송 속도는 이에 한참 못미친다.
비트코인의 더 큰 문제는 마이너의 수가 아무리 많아져도 TPS가 증가하지 않는다는 점이다. 즉, 비트코인은 마이너를 투입했을 때 트랜잭션 처리 속도에 대한 확장성이 전혀 없다. 그렇다면 이를 해결하기 위해서 어떻게 해야할까? 여러가지 방법이 있겠지만 그 중 간단한 해결책은 비트코인과 독립적인 별도의 체인을 만드는 것이다. 비트코인 네트워크 1개가 7 TPS의 속도를 가진다고 하자. 별도의 네트워크도 똑같은 속도라고 가정한다면, 이상적으로는 같은 트랜잭션을 처리할때 14TPS의 속도를 가질 수 있다. 하지만 단순히 별개의 체인을 만든다고 문제가 해결되는 것이 아니다. 결국 하나의 자산은 하나의 원장으로 확정되어야 한다. 따라서 확장성을 이유로 별개의 체인을 만들기만 해서는 안되고 인터체인과 같이 일관된 체인간 정보 교환 프로토콜이 있어야 한다.
Polyculture
비트코인 구현 및 기타 대부분의 블록체인 기술의 구현은 어느 하나가 잘못되면 모든 것이 바로 망가진다. 이러한 구조를 모노컬처라고 하는데 이는 프로그램 아키텍처 디자인 관점에서 바람직하지 않다. 인터체인은 메인 체인의 업무 중 일부를 가져가면서 부분적으로 모노컬처 구조를 탈피할 수 있다. 예를 들어 페이먼트를 위한 체인과 부동산같은 증서를 후청산하는 체인을 나눌 수도 있다. 페이먼트는 빠른 속도가 중요하므로 샤딩이나 오프체인 등의 기술이 도입되고, 증서의 청산절차는 속도보다 정확성이 더 중요하므로 신뢰도 높은 합의 알고리즘을 도입할 수 있다. 이더리움의 예시를 들자면, 캐시의 성격을 가진 ERC 20토큰과 증서의 성격을 가진 ERC 721토큰이 처리되는 체인을 달리하는 샘이다.
소프트웨어 업데이트
블록체인은 본질적으로 업데이트 하기 힘들다. 해당 네트워크에 참여하는 노드들의 승인을 얻어야 하기 때문이다. 그래서 특정 업데이트에 대해 하드 포크를 하는 등 네트워크의 분화가 일어난다. 또한 현실적으로 업데이트가 잘못되면 네트워크에 저장되어있는 모든 자산이 가치를 잃을 수 있으므로 업데이트 자체가 조심 스러울 수 밖에 없다. 인터체인은 바로 이런 메이저 업데이트가 힘든 블록체인의 한계를 어느정도 극복할 수 있는 현실적인 대안이다. 예를 들어 특정 회사에서 사용하는 서비스를 위하여 블록체인 전체를 업데이트 하기는 힘들다. 이 경우 인터체인 솔루션이 있다면 별도의 체인을 만들어 전체 노드를 업데이트 하지 않아도 되고 만약 해당 체인에 결함이 있어도 원래 네트워크의 피해를 최소화 할 수 있다.
필요한 부분만 개발, 낮은 변동성
모든 알트코인의 백서는 비트코인의 한계를 지적하고 자신들이 그 한계를 어떻게 극복했는지 밝히고 있다. 즉, 모든 알트코인은 비트코인 블록체인이 문제가 있으니 본인들이 제시한 새로운 알트체인을 만들자고 제안한다. 하지만 알트코인의 설계가 얼마나 완벽한가와 상관 없이, 수 많은 알트코인의 탄생으로 인해 발생하는 부작용이 있다. 우선 대부분의 알트코인은 기존에 비트코인이 해결했던 문제까지 다시 풀려고 노력하고 있다. 한마디로 바퀴를 다시 개발하고 있다는 것인데 이는 개발 자원의 낭비가 아닐 수 없다. 또한 알트코인의 경제는 비트코인 경제보다 규모가 작으므로 변동성이 더 심할 가능성이 있다. 물론 누군가는 이를 즐기겠지만 블록체인 기술로 풀고자하는 대부분의 실용적인 문제에 대해 가격 변동성은 결코 긍정적인 영향을 끼치지 않는다. 예를 들어 지역 화폐로 사용되는 토큰이 있다고 하자. 지역 화폐란 특정 지역에서 현금처럼 쓸 수 있는 것을 말한다. 그렇다면 해당 지역 이발소 이용 가격이 어제는 5천원이였다가 오늘은 1만원이 된다면 그 토큰은 화폐로서의 역할을 할 수 없을 것 이다.
만약 알트코인을 개발하는 대신 인터체인 기술을 도입한다면, 기존 체인이 이미 잘하고 있는 부분에 대해서는 다시 디자인 할 필요가 없다. 또한 기존 체인이 이미 어느정도 변동성에 저항성이 있는 규모라고 한다면, 그 가치와 동일한 토큰을 유통하는 별개의 체인을 만들어 기존 체인의 안정적인 경제에 의존할 수 있다.
어떤 방식으로 체인간 정보 교환이 일어나는가?
체인간 정보 교환에 대해 다양한 방식이 제안되었다. 대표적으로 Adam Back이 논문에서 제시한 Two Way Pegging, Tier Nolan이 2013년에 bitcointalk.org에 포스팅한 Atomic Swap방식, 그리고 블록체인 네트워크를 중계하는 Relay방식 등 다양한 안이 있다. 이번 글에서는 Two Way Pegging 사이드체인방식을 자세히 다루되, Atomic Swap이나 Relay방식에 대해서도 간단히 설명하려 한다.
Two Way Pegging(사이드체인)
Two Way Pegging을 한 문장으로 설명하자면, 한쪽 체인(Parent Chain)에서 자산 동결(pegging)을 증명하면 다른 쪽 체인(사이드체인)이 그것을 확인하고 동일한 가치의 자산을 발행하여 유통하는 기술이다. 이 기술을 소개하기 이전에 우선 이해하는데 도움이 될 만한 용어부터 먼저 소개하도록 하겠다.
Reorganisation(Reorg)
이 용어를 이해하려면 우선 비트코인 작업증명이 어떤 식으로 합의를 이루는지 알아야 한다. 평균적으로 블록을 만드는 시간이 비슷하다고 가정하면 블록이 가장 많이 달린 체인 즉, 가장 긴 체인이 만드는데 가장 많은 시간이 걸렸을 것이라고 추측할 수 있다. 큰 수의 법칙에 따르면 많은 시행을 반복할 수록 저 추측은 참에 한없이 가깝게 수렴한다. 비트코인은 위와 같은 이유로 가장 긴 체인을 노드들이 가장 많은 작업 증명(PoW)을 하였다고 생각하여 그 체인에 담겨있는 트랜잭션을 신뢰한다. 문제는 체인이 2개로 분화되었을 때다. 같은 높이의 서로 다른 갈래의 체인이 2개 이상 발생하여 경쟁 관계에 있을 때 이를 ‘race condition’ 이라 부른다. 이 경우 체인의 높이가 동일하므로 작업증명 방식으로 1개의 체인으로 합의를 이루지 못한다. 예시를 통해 이 문제를 조금 더 구체화 해보자.
위의 예시에서 K+3번째에 순서 3 까지는 위에 있는 체인을 신뢰하여야 한다. 하지만 순서 4에서 해당 체인은 race condition에 돌입하였고 순서 5가 되었을 때 가장 긴 체인이 바뀌었다. 이 현상을 Reorganization (Reorg)라고 한다. 만약 어떤 거래 당사자가 위에 있는 체인을 신뢰하여 거래를 하였다면, 나중에 아래쪽 체인에서 해당 거래와 모순되는 거래가 발생할 수 있다. 따라서 비트코인에서는 보통 특정 트랜잭션을 6 confirmation 즉, 해당 블록에 담긴 후 뒤에 6개의 블록이 더 붙어야 신뢰를 한다. 다시 말하면 트랜잭션이 블록에 담겼다고 해서 바로 그 트랜잭션을 신뢰하면 안되고, reorganization이 일어나기 힘들어질 때 까지 기다려야 한다는 의미이다.
SPV(Simplified Payment Verification)
비트코인 블록체인에 있는 모든 블록 및 트랜잭션 정보를 저장하려면 수 백 GB의 저장공간이 필요하다. 하지만 대부분의 사용자들에게 이러한 저장공간을 확보하도록 하는 것은 현실적이지 않기 때문에 비트코인 백서에서는 SPV라는 방식의 트랜잭션 검증법을 제시하고 있다. 비트코인의 트랜잭션은 머클 트리라는 자료구조를 이용하여 저장하기 때문에 특정 트랜잭션의 해시값(ID라고 생각해도 좋다)을 알고 있으면 쉽게 해당 트리의 루트를 찾을 수 있다. 그리고 비트코인의 모든 블록은 각 블록의 머클 트리 루트 값을 가지고 있으므로 트랜잭션 ID를 이용해서 해당 트랜잭션이 어떤 블록에 속하는지를 바로 알 수 있다. 만약 그 블록이 가장 긴 체인에 속해있다면 우리는 그 트랜잭션을 신뢰할 수 있다. SPV client는 이런식으로 체인의 헤더값만 저장하여 트랜잭션을 저장하는 노드를 말한다.
One-Way Peg
Two-Way Peg와 다르게 One-Way Peg는 한 쪽 방향으로만 자산이 이동하는 방법을 말한다. 예를 들어, A 체인과 B체 인이 One-Way Peg되어 있다면 A 체인에서 B체인으로는 자산을 보낼 수는 있지만 B체인에서 A체인으로 자산을 다시 보낼 수 없다. 이런 경우 다시 돌아올 수 없기 때문에 A 체인에서 B 체인에게 자신의 자산을 동결(peg)하는 것이 아니라 소각(burn)되었음을 증명해야한다.
자 이제 주요한 용어에 대한 설명이 끝났으니 본격적으로 Two-Way Peg가 어떻게 진행되는지 논의하여보자.
Two way peg의 목적 및 디자인 철학
비트코인과 이더리움을 교환하는 가장 단순한 방법은 거래소를 이용하는 것이다. 하지만 대부분의 거래소에서 발생하는 거래는 블록체인 상에서 일어나지 않는다. 우리는 거래소를 신뢰하고 비트코인과 이더리움의 지갑을 맡긴다. 심지어 거래되자마자 지갑으로 들어오지 않아도 크게 개의치 않는다. 하지만 Two Way Pegging은 이러한 중앙화된 신뢰에 의지하지 않는다. 즉, 비트코인이 달성한 탈중앙화 신뢰기반을 조금도 변경하지 않고 서로 다른 체인간 자산 거래를 하는 것이 목표다.
자산 이동의 전반적인 흐름
메인체인에서 사이드체인으로 1 BTC를 보내기 위해서는 여러가지 과정을 거친다. 우선 사이드체인에 있는 계좌로 바로 보내줄 수는 없다. 왜냐하면 아직까지 사이드체인의 계좌는 메인체인에서 유효한 계좌가 아니기 때문이다. 그 대신 메인체인은 1 BTC를 동결(peg) 한다. 사이드체인에서는 메인체인이 동결한 자산과 동일한 가치를 지니는 자산이 발행되어 유통된다. 그리고 사이드체인에서 다시 메인체인으로 자산을 보내고 싶다면, 사이드체인에서 발행했던 1 BTC는 동결되고 메인체인에 묶여있던 1BTC는 다시 풀리게 된다.
위의 그림을 통해 조금 더 자세히 어떤 일이 일어나는지 시간 순서대로 살펴보자.
- 메인체인에서 confirmation period동안 lock이 걸린 트랜잭션을 만든다. confirmation period의 목적은, DoS 공격을 하는 사람의 유인을 줄이기 위해 딜레이를 주기 위함이다. 마치 DDoS공격을 막기 위해 홈페이지에서 일정 시간동안 임시페이지를 띄우는 것(cloudflare같이)과 원리가 유사하다.
- 메인체인에서 만든 트랜잭션의 lock이 풀렸다면 이제 사이드체인에서 해당 트랜잭션을 SPV를 이용해 유효성을 검증한다. 여기서 SPV로 트랜잭션을 검증했다 하더라도 contest period동안 해당 트랜잭션을 유효하다고 보면 안된다. 왜냐하면 위에서 언급한 Reorganization이 일어날 가능성이 있기 때문이다.
- 다시 사이드체인에서 메인체인으로 자산을 보내고 싶다면 똑같은 과정을 거친다. 위의 그림에서는 사이드체인에서 메인체인으로 보낼 때 첫번째 시도에서 Reorg가 일어난 상황을 가정하고 있다. 특정 노드가 트랜잭션이 Reorg된 체인에 담겨있는 것을 확인하면, 메인체인에 Reorganization Proof를 제시할 수 있다. 메인체인은 이를 쉽게 확인 가능할 것이며(SPV가 가능하기 때문에) 해당 트랜잭션을 유효하지 않은 트랜잭션으로 판단할 수 있다. 또한 Adam의 논문에서는 Reorganization Proof를 하는 사람에게 보상을 줘서 해당 행동을 할 유인을 만들 수 있다고 간단히 언급하고 있다.
- 마지막으로 다시 사이드체인에서 트랜잭션을 발생시키고 이번에는 confirmation period와 contest period 둘 다 통과하여 자산이 메인체인으로 넘어가고 있다.
Two Way Pegging을 하기 위해 메인체인과 사이드체인에 들어가야할 추가적인 기능
위의 시나리오를 수행하려면 기존 체인에는 없는 다음과 같은 스펙을 구현해야 한다.
- 상대방 체인의 트랜잭션을 SPV로 검증하는 script
- 상대방 체인의 Reorg를 관찰하고 Reorg proof를 하여 체인간 자산 전송을 되돌리기
종합하면 서로 상대방 체인의 상황을 관찰할 수 있는 노드가 있어야 한다. 그래야 상대방이 트랜잭션을 보냈는지 확인도 가능하고, 그 트랜잭션이 유효한지 확인 가능하다.
공격상황
그리고 위에서 언급하였다 시피 confirmation, contest period를 둠으로써 DoS 공격과 Reorganization에 대해 완벽하진 않지만 유효한 방비책을 마련하고 있다고 할 수 있다. 하지만 그럼에도 불구하고 다음과 같은 상황이 발생하는 것을 완벽히 막을 수 없다
- 사이드체인이 만약 메인체인의 자산을 일부 보관하는 용도로 쓰인다면, 메인체인보다 경제 규모가 작을 가능성이 높다. 비유를 하자면 메인체인은 미국 같은 선진국이고 사이드체인은 개발도상국인 샘이다. 그럴 경우 사이드체인에서 거래가 활발하게 일어나지 않는다면 메인체인 쪽으로 자산이 쏠릴 가능성( 뱅크런)이 있다.
- Peg된 코인은 reorg가 일어나든 여러가지 이유로 그 결과가 뒤바뀔 가능성이 0이 아니다. 따라서 Peg가 되지 않은 코인을 더 선호할 가능성이 있다.
- 교환 비율을 정하는 방법에 따라서 코인의 총량이 변할 수 있다. 사실 교환 비율에 따른 장난 시나리오는 수도 없이 많다. Two-Way Peg는 자산 이동 자체에 대한 방법이라서 이에 대한 방어책은 없다고 할 수 있다.
근본적인 문제
사실 블록체인에 추가적인 신뢰 모델을 도입하지 않으려면 각 체인마다 서로 다른 체인을 SPV로 검증할 수 있는 프로토콜을 지원해야 한다. 예를 들어 비트코인 블록체인에서 이더리움 블록체인의 트랜잭션을 검증할 수 있는 프로토콜이 있어야 한다는 소리다. 블록체인 자체적인 결함이 있어도 업그레이드 하기 어려운데 다른 블록체인의 트랜잭션 검증기능을 넣기란 과연 쉬울까? 즉, Two-Way Pegging은 물론 되면 좋지만 정치적인 이유로 사실상 구현하기 매우 어렵다.
Two-Way Pegging을 제안한 Blockstream사도 이런 사실을 모를리 없어서 2016년에 Strong Federations: An Interoperable Blockchain Solution to Centralized Third Party Risks 이라는 논문을 발표한다. 이에 대한 복선은 이미 2014년 논문 Appendix A에 Federated peg라는 아이디어를 제안하면서 깔아놓았다. 현재 Blockstream은 이에 대한 구현체인 Liquid를 개발하고 있다.
이 외에도 보안을 위해서 contest, confirmation period를 절대 낮게 잡을 수 없다는 단점도 있다. 논문에서는 1,2일로 잡으라고 권고하고 있는데 그러면 체인간 단일 트랜잭션을 확정하기 까지 최소 2일 이상 걸린다는 얘기다. 따라서 개인과 개인이 실시간으로 거래하는 응용에는 적합하지 않다.
Atomic Swap
Atomic Swap은 T.Nolan이 bitcointalk.org에 2013년 올린 글[4]에 그 대략적인 청사진이 제시되어있다. Two-Way Pegging는 자산을 A체인에서 B체인으로 전달하는데 그 목적이 있다면, Atomic Swap은 체인 A에 있는 자산a와 B에 있는 자산 b사이의 교환이 주 목적이다. Atomic Swap이 일어난다면 a는 체인 A에서 소유권이 바뀌고 b역시 체인 B에서 소유권이 바뀌게 된다. 대략적으로 다음과 같은 방식으로 교환이 일어난다.
- A체인에 자산이 있는 철수와 B체인에 자산이 있는 영희가 각각 자신의 자산인 a,b를 서로에게 교환하고 싶다고 하자.
- 철수는 a를 영희의 전자서명과 자신만 알고 있는 숫자 n으로 가져갈 수 있도록 트랜잭션을 발생시킨다. 그리고 그와 동시에 a를 48시간 뒤에 다시 자신에게 돌아오도록 하는 트랜잭션을 발생시킨다. 두 번째 트랜잭션은 혹시 거래가 성사되지 않을 경우 되돌리기 위함이다.
- 철수는 자신만 알고 있는 숫자 n에 대한 공개키를 네트워크에 전파한다
- 영희는 철수가 전파한 트랜잭션과 공개키를 듣고, b를 주는 트랜잭션을 발생시킨다. 이 트랜잭션은 철수의 전자서명과 철수만 알고 있는 숫자 n으로 가져갈 수 있도록 만든다(공개키를 가지고 있으므로 n을 몰라도 만들 수 있다). 동시에 b를 24시간 뒤에 자기 자신에게 돌아오도록 하는 트랜잭션을 만든다.
- 철수는 b 를 가져가기 위해 체인 B에 자신만 알고 있는 숫자 n과 자신의 전자서명을 이용해 b를 자신의 지갑으로 입금한다.
- 철수가 b를 소비(spend)하는 순간, 영희는 숫자 n을 볼 수 있다. 따라서 철수가 트랜잭션을 발생한지 48시간이 되기 전에 체인 A로 가서 자신의 전자서명과 숫자 n을 이용해 a를 자신의 지갑에 넣으면 된다.
왜 철수의 locking time이 영희의 locking time보다 길까? 그건 아래의 그림을 보면 확인이 가능하다.
Atomic Swap은 이렇게 상호 신뢰 없이도 다른 체인간 자산 교환이 가능하다는 장점이 있다. 실제로 Komodo나 Decred등의 프로젝트가 Atomic Swap을 지원하고자 하는 프로젝트이다. 하지만 Atomic Swap은 일단 PoW기반의 같은 해시 알고리즘을 써야 쓸 수 있다는 단점과, 상호 여러단계에 거쳐서 성실히 자신의 몫을 해야 교환이 가능하다는 단점이 있다. 상대방이 게으름을 피우면 계약이 48시간 후에나 끝날지도 모른다는 말이다.
Relayer
위에서 언급 하였듯 Two-Way Pegging의 가장 큰 단점은 현재 블록체인 위에서 구현하기 힘들다는 점이다. 이에 대한 타협안으로 나온 방안이 Relayer이다. Relayer는 쉽게 말하면 protocol translator이다. 블록체인 간 소통이 안되니 그걸 번역해주는 중간자 역할의 무엇이라고 이해하면 된다. 대표적으로 BTC-Relayer(Consensys)와 Peggy(Cosmos)등의 구현이 있다. 예를 들어 비트코인 노드와 이더리움 노드를 두 개 동시에 운영하고 있는 사람이 있다고 하자. 비트코인에서 이더리움으로 자산을 이동하고 싶은 다른 사람이 있으면, 이 사람이 비트코인 블록체인에서 발생한 트랜잭션을 책임지고 이더리움에 알리고 수수료를 받는게 relayer다.
relayer가 받을 비판은 명확하다. relayer는 블록체인 밖에서 문제를 해결하려 하고 있다. 물론 relayer 자체를 탈중앙화 하려는 여러 시도들이 있다(blockstream의 federated peg라든지). 하지만 위에서 인터체인 기술을 훑어보았으면 느꼈겠지만 relayer보다 더 현실적이고 당장 구현 가능할만한 대안이 많지는 않다.
결론
초창기 일부 기관들이 쓰던 인트라넷이 지금의 인터넷이 되었 듯, 블록체인도 언젠가는 표준적인 체인간 정보 교환 프로토콜이 나와 모든 체인이 연결될 날이 올 수도 있다. 하지만 Harvard Business Review의 The Truth About Blockchain라는 기사에서 재미있는 시각을 빌려오자면 블록체인의 발전양상을 4단계로 나눴을 때 그런 날은 마지막 단계에 가서야 실현될 것이다. 그 때가 TCP/IP처럼 20,30년이 지나야 올 수도 있고 더 늦게 올 수도 있고 어쩌면 더 빨리 올 수도 있다. 이 글을 읽는 여러분이 그 날을 앞당기는 주인공이 될 수도 있다.
참고자료
[1] https://blockstream.com/sidechains.pdf
[2] https://en.bitcoin.it/wiki/Scalability
[3] https://hbr.org/2017/01/the-truth-about-blockchain
[4] https://bitcointalk.org/index.php?topic=193281.0
[5] https://medium.com/balance-io/what-is-the-interchain-799b187735de
[6] https://blockstream.com/2017/01/16/strong-federations-paper-released-liquid.html
[8] https://blockstream.com/technology/
[9] https://www.slideshare.net/DavidEvansUVa/silk-road-46953307
