[마소 394호] 스토리체인이 사이드체인을 선택하기까지

입력 2018.11.01 10:01

소프트웨어 전문지 마이크로소프트웨어 394호는 클라우드(Cloud)와 백엔드(Back-End)를 주제로 담았습니다. 사이드체인, 블록체인, 데브옵스, PaaS, 마이크로서비스 아키텍처 등 마소 394호의 주요 기사들을 IT조선 독자에게도 소개합니다. [편집자주]

2017년 12월 비트코인의 미승인 거래 수가 급증했다. 비트코인 네트워크에 과부하가 일어나 트랜잭션 처리가 지연됐고 덩달아 거래수수료까지 크게 올랐다. 알트코인 대표인 이더리움뿐 아니라 다른 알트코인들도 네트워크 과부하가 발생했다. 당시 블록체인의 현실적인 문제를 해결하고자 사이드체인이 등장했다.

사이드체인은 기존의 비트코인이나 이더리움 같은 블록체인에 별도 블록체인을 추가 연결해 특정 목적의 기능을 수행하는 블록체인을 말한다. 사이드체인을 활용하면 온라인에서만 결제할 수 있는 비트코인을 오프라인에서도 결제할 수 있도록 별도의 블록체인을 구동하거나, 처리 용량이 작은 기존 이더리움을 확장해 처리용량을 몇 배 늘려서 기능을 확장할 수 있다. 여기서 굳이 별도의 블록체인을 새로 구축하지 않고, 기존의 블록체인에 연결하는 이유는 기존 블록체인이 이미 만들어 놓은 코인의 가치와 세계적인 네트워크를 그대로 사용할 수 있기 때문이다.

사이드체인의 역사는 블록체인의 확장성과 관련 있다. 확장성 문제를 해결하는 한 방법으로 사이드체인이 등장했다. 사이드체인은 2014년 발표된 아담 백(Adam Back)의 논문(blockstream.com/sidechains.pdf)이 시발점이다.

사이드체인 이외에도 확장성 문제를 해결하는 방법에는 블록체인 간 통신을 위한 인터체인(Interchain), 블록체인 간 자산교환을 위한 아토믹 스왑(Atomic Swap), 블록체인 간 네트워크 중계하는 릴레이(Relay) 방식 등 다양한 방법이 있다.

양방향 페그 작동원리(블록체인 확장성 솔루션 시리즈 3-1::Interchain Overview). / 마이크로소프트웨어 394호 발췌
2014년 아담 백이 사이드체인은 양방향 페그라고 정의한 이후 사이드체인의 용도와 범위가 확대되고 있다. 그래서 새로운 정의가 필요한 시점이지만 지속적으로 변화하고 있어 선을 긋기가 어렵다. 우선 초기기술인 양방향 페그의 작동방식을 이해한 후, 사이드체인의 발전 방향을 통찰할 수 있길 바란다.

양방향 페그를 한 문장으로 설명하면, 한쪽 체인(Parent Chain)에서 자산 동결(Pegging)을 증명하면 다른 쪽 체인(사이드체인)이 그것을 확인하고 같은 가치의 자산을 발행해 유통하는 기술이다.

사실 블록체인에 신뢰 모델을 추가적으로 도입하지 않으려면 체인마다 서로 다른 체인을 SPV로 검증할 수 있는 프로토콜을 지원해야 한다. 예를 들어 비트코인 블록체인에서 이더리움 블록체인의 트랜잭션을 검증할 수 있는 프로토콜이 있어야 한다는 소리다. 블록체인에 자체적인 결함이 있어도 업그레이드하기 어려운데, 다른 블록체인의 트랜잭션 검증기능을 넣기가 과연 쉬울까? 물론 양방향 페그는 되면 좋지만, 정치적인 이유로 사실상 구현하기 매우 어렵다.

양방향 페그를 제안한 블록스트림(Blockstream)도 이런 사실을 모를리 없다. 블록스트림은 2016년 ‘Strong Federations: An Interoperable Blockchain Solution to Centralized Third Party Risks’라는 논문(arxiv.org/pdf/1612.05491.pdf)을 발표했다. 이에 대한 복선은 이미 아담 백이 2014년 발표한 사이드체인의 시발점이 된 논문 중 ‘Appendix A’에 ‘Federated peg’라는 아이디어 제안에서 깔아놓았다. 현재 블록스트림은 이에 대한 구현체인 리퀴드(Liquid)를 개발하고 있다.

이 외에도 보안을 고려해 검증 기간(Confirmation Period)을 절대 낮게 잡을 수 없다는 단점도 있다. 논문에서는 1~2일로 권고하고 있지만, 이 경우 체인간 단일 트랜잭션을 확정하기까지 최소 2일 이상 걸린다는 뜻이다. 따라서 개인과 개인이 실시간으로 거래하는 응용에는 적합하지 않다.

경호연 필자의 ‘스토리체인이 사이드체인을 선택하기까지’에 대한 자세한 내용은 ‘마이크로소프트웨어 394호(https://www.imaso.co.kr/archives/3939)’에서 확인할 수 있다.


키워드

관련기사를 더 보시려면,

[마소 394호] RxJava로 생각하기 오세용 기자
[마소 394호] 플라스크 효과적으로 사용하기 오세용 기자
[마소 394호] 모바일 앱 테스트 자동화용 디바이스팜 구축 오세용 기자
[마소 394호] 되돌아 보는 1만 개의 클라이언트 문제 오세용 기자
[마소 394호] 클릭만으로 도커 개발 환경을 완성시켜주는 애저 PaaS 오세용 기자
[마소 394호] DDD와 MSA로 쇼핑몰 구축하기 오세용 기자
[마소 394호] 이스티오 서비스 메시를 이용한 MSA 구축 오세용 기자
[마소 394호] 제대로 구성하는 마이크로서비스 아키텍처 오세용 기자
[마소 394호] 아마존 API 게이트웨이와 AWS 람다로 구성하는 다운로드 서버 오세용 기자
[마소 394호] AWS EC2와 트래비스CI를 활용한 무중단 배포 서비스 오세용 기자
[마소 394호] 스타트업의 좌충우돌 CI/CD 구성 오세용 기자
[마소 394호] AWS 이메일 서비스 써보니 오세용 기자
[마소 394호] 클라우드의 성능 품질 이야기 오세용 기자
[마소 394호] 클라우드 시대 토종 호스팅 업체의 변신 오세용 기자
[마소 394호] 데이터베이스의 게임 체인저, 오라클 클라우드 오세용 기자
[마소 394호] 알아두면 쓸데없는 신비한 TLS 1.3 오세용 기자
[마소 394호] 다시 보는 PaaS, 어디서 와서 어디로 가는가 오세용 기자
[마소 394호] 코드로 관리하는 인프라스트럭처, 테라폼 오세용 기자
[마소 394호] 더 웨더 컴퍼니의 데브옵스 오세용 기자
[마소 394호] 사설 클라우드의 끝판왕 오픈스택 오세용 기자
[마소 394호] 개발운영 퀀텀 점프를 위한 도커 오세용 기자
[마소 394호] IT 서비스와 모니터링 역사 오세용 기자
[마소 394호] 오픈스택 커뮤니티 동고동락 오세용 기자
[마소 394호] 데브옵스를 꿈꾸는 개발자를 위한 안내서 오세용 기자