위키원
루프체인
루프체인(Loopchain)은 ㈜더루프(theloop)가 독자 개발한 프라이빗 블록체인 엔진이다. 금융거래를 지원하는 것을 목적으로 개발되고 있으며, 추후 IoT환경 등 블록체인이 적용 가능한 다양한 서비스를 구성하기 위한 엔진 개발을 목표로 하고 있다.
개요
루프체인은 하이퍼레저 패브릭(Hyperledger Fabric)이나 R3 코다(R3 Co에 비해 블록체인의 기본에 더욱 충실한 구조를 가지고 있다. 하이퍼레저 패브릭의 컨센서스 서비스나 공증인(Notary)처럼 중앙에서 트랜잭션 순서를 정해주며, 체인은 이 내용을 검증해주는 구조와 달리, 기본 비트코인 블록체인처럼 이해관계자들의 트랜잭션 순서를 합의 보증 하는 방식으로 순서를 정해주고 있다.
㈜더루프는 금융권 요구사항을 만족하면서 새로운 요구사항에 맞게 시스템을 변화하기 위해 루프체인을 유연한 구조로 만들고자 했다. 루프체인 모듈에서 어드민 레이어는 주로 블록체인 네트워크 관리를 위해 노드의 장애 상황을 감독하고, 스마트 계약의 버전을 관리하고, 각 노드의 권한을 감독한다. 엔진 레이어는 블록체인 노드의 주 역할인 분산합의, 원장 저장, 스마트 계약 실행을 담당하며, 특히 분산합의를 위한 엔진 모듈인 블록체인과 실제 블록체인에 올라가는 서비스와 실행환경인 스코어(Smart Contract on Reliable Environment; SCORE)가 분리되어 있다. 인터페이스 레이어는 다른 비즈니스 애플리케이션이 블록체인 네트워크에 접속할 수 있는 환경을 만들어준다.[1]
특징
루프체인의 1차 목표는 금융권을 위한 블록체인이기 때문에 이해당사자끼리만 데이터를 볼수 있는 프라이빗 채널 기능, 블록체인 네트워크 참여 기관별로 다른 기능을 가지게 하는 트라이드 시스템, 마지막으로 다양한 금융 서비스를 원할하게 지원하기 위한 빠른 속도를 목표로 개발한 블록체인이다.
어드민 레이어에서는 각 네트워크에 참여하는 노드들을 관리·감독한다. 어드민 레이어에서 각 노드의 권한을 제한하고, 암호화 프로토콜을 통한 메세지 교환 방식, 또 비트코인 라이트닝 네트워크 프로토콜을 이용해 트라이드 시스템과 프라이빗 채널을 구현하고 있다. 현재, 각 특징을 구현하는 2가지 방식이 있는데 추후에 늘어날 수도, 한가지 방식으로 통합될 수도 있다.
루프체인에서는 높은 성능을 보장하기 위해 프랙티컬 비잔틴 장애 허용(Practical Byzantine Fault Tolerance; PBFT) 방식과는 다른, 리더 중심의 분산합의 방식과 리더 장애 극복 알고리즘을 통해 비잔틴 장애 허용(Byzantine Fault Tolerance; BFT) 문제를 해결하고 있다. 또한 블록체인 서비스를 동작하는 부분(SCORE)과 합의엔진을 완전히 분리했고, 합의엔진 내에서도 모듈 및 가용성 요구사항에 따라 프로세스를 여러 개 분리하는 방식으로 고성능 블록체인이 구현되었다.
그 밖의 중요한 특징으로는 '포털'이라는 자체 개발한 프로토콜을 이용해 리더 노드를 통한 블록체인 외부 데이터(외부 블록체인) 접근 및 분산합의 방법, 스코어의 버전 방식과 마이그레이션 없이 동작하는 네트워크에서의 업데이트 및 하위 호환성 지원, 스코어 스토어를 통한 스마트 계약 배포 및 버전관리 등의 특징이 있다. 또한 더루프는 블록체인 내에서 인증서를 발급하는 독자 기술을 개발해 이번에 금융투자업권 컨소시움의 첫 번째 시범 모델로 사용할 예정이다.[1]
스코어
루프체인 스코어(SCORE)의 가장 큰 특징은 개발 친화적 언어를 통해 자유롭게 개발환경을 구성할 수 있다는 점이다. 대표적인 블록체인 기반 스마트 계약 플랫폼인 이더리움의 경우, 특수한 가상머신 EVM(Ethereum Virtual Machine)에서 사용 가능한 언어로만 스마트 계약을 작성할 수 있다. 즉 솔리디티(Solidty), 서펀트(Serpent), 저급언어(Low Level Language; LLL)를 통해서 스마트 계약을 개발 해야하고 데이터 접근 및 저장 또한 EVM 내부 변수를 통해서만 저장할 수 있다.
루프체인 스코어는 합의엔진과 의존성을 최대한 떨어뜨린 별도의 모듈로 개발되었다. 합의 엔진과 스코어는 내부 gRPC로 구현된 인터페이스를 통하여 통신을 하기 때문에 인터페이스만 맞으면 어떠한 언어로도 구현이 가능하나 현재는 파이썬 구현체만 허용하고 있다. 데이터베이스 또한 자유롭게 사용할 수 있다. 다만 이더리움 처럼 변수의 모든 데이터가 저장되지는 않고 데이터베이스에 직접 읽고 쓴 결과만 저장된다.
채팅서비스는 중계자가 필요한 대표적인 서비스이다. 채팅 참여자는 각자가 직접 연결되지 않고 채팅서버와 연결한 후 채팅서버에서 보내주는 다른 참여자의 말을 믿고 대화를 진행한다. 즉, 대화 당사자가 아닌 채팅서버라는 별도의 TTP(Trusted Third Party)가 대화라는 거래를 중계해주는 방식이라고 할 수 있다. 이를 스마트 계약으로 구성한다면, 채팅 참여자가 각각 블록체인 노드를 구성하고 대화 내용을 포함하고 서명을 하여 거래를 발생시키면 해당 거래가 동기화되고 거래 내역이 정당하면(채팅 참여자의 서명이 맞으면) 거래에 포함된 대화 내용을 전체 대화록에 추가하는 방식인 것이다.[2]
루프 장애 허용
루프 장애 허용(Loop Fault Tolerance; LFT)은 현재 루프체인에서 사용하는 합의 알고리즘이다. 그러나 루프체인은 플러그인(Pulgin)형태로 합의 알고리즘이 구현되어 있기 때문에 필요에 따라 프랙티컬 비잔틴 장애 허용과 같은 다른 합의 알고리즘을 사용할 수 있다. 추후에 루프체인은 깃허브(Github)를 통해 오픈소스 프로젝트로 공개될 것이기 때문에 직접 다운로드 받고 실행 시킬 수 있다.
루프 장애 허용은 기존 프랙티컬 비잔틴 장애 허용을 사용하는 합의 알고리즘에서 발생하는 통신 오버헤드를 피기배킹(Piggybacking)을 이용하여(네트워크에서 메시지를 통합하여 통신 오버헤드를 감소시키는 방법) 줄였으며, 스피닝(Spinning)기법(리더를 매번 교체하는 기법)을 이용하여 악의적인 노드가 네트워크의 합의를 해치지 않는 범위에서 네트워크에 문제를 일으킬수 있는 특정 노드의 트랜잭션 거부 문제, 리더에 의한 네트워크 지연과 같은 문제를 해결했다. 또한 기존 알고리즘들이 가지고 있던 지나치게 복잡한 리더 선정 알고리즘을 단순화 하였다.
네트워크가 시작되면 검증 노드(검증을 통해 합의에 참여하는 노드)들은 사전에 결정되어 있는 리더 노드에게 처리를 원하는 트랜잭션을 전송한다. 리더 노드는 수집한 트랜잭션을 이용하여 블록을 생성하고 자신의 서명과 함께 다른 모든 검증 노드에게 전송한다. 각 검증 노드들은 블록을 받으면 현 리더가 블록을 생성했는지 확인하고, 블록의 높이와 이전 블록 해시가 올바른지 확인하며, 블록의 데이터가 올바른지 확인한다. 검증 노드는 위 세가지 방법이 옳다면 투표(Vote) 데이터를 생성하여 네트워크의 모든 노드들에게 전파한다. 투표 데이터를 전체 노드에게 전파하는 것은 매우 중요한데, 이는 리더 노드가 비잔틴일 경우 정족 수 이상의 노드들에게만 블록을 전파하여 특정 노드들을 네트워크로 부터 분리하도록 시도할 수 있기 때문이다. 이러한 문제를 방지하기 위해 모든 피어에게 투표 데이터를 전파하며 이는 기존 Raft 알고리즘과 다른 부분이다. 이 과정에서 블록을 못받은 노드는 블록이 생성되었는지에 대한 정보를 알 수 있고 다른 노드에게 블록을 요청할 수 있다.[2]
비교
| 특성 항목 | 엔터프라이즈 블록체인 | 퍼블릭 블록체인 | ||
|---|---|---|---|---|
| 루프체인 | 비트코인 | 이더리움 | ||
| 시멘틱 데이터 구조 | 바로 이전 블록의 해시값, 트랜잭션 리스트, 블록 생성 노드 ID, 블록 검증 피어의 서명, 블록 생성 노드의 서명 등 | 바로 이전 블록의 해시값, 트랜잭션 리스트, 블록 생성 노드 ID, 블록 검증 피어의 서명, 블록 생성 노드의 서명 등 | 바로 이전 블록의 해시값, 트랜잭션 리스트, 엉클 블록 리스트를 포함하는 헤더 | |
| 네트워크 타입 | 프라이빗, 컨소시엄 | 퍼블릭 | 노드의 배치에 따라 프라이빗, 컨소시엄, 퍼블릭 형태 지원 | |
| 참여자 | 신원이 판명된 참여자 | 불특정 다수 (신뢰할 수 없는 사용자 포함) |
노드의 배치에 따라 상이 (불특정 다수/신원이 판명된 참여자) | |
| 합의 | 알고리즘 | 프랙티컬 비잔틴 장애 허용 | 작업증명(Proof of Work; PoW) | 작업증명/지분증명(Proof of Stake; PoS) |
| 완결성 | 비잔틴 장애 허용 알고리즘으로 분기가 존재하지 않는다. 하나의 블록 검증 시 즉시 완결 | 시간의 흐름에 따라 새 블록의 검증 시 거래 역분개의 가능성 존재 | 시간의 흐름에 따라 새 블록의 검증 시 거래 역분개의 가능성 존재 | |
| 계약 | 계산력 | 튜링 완전성 지원 | 스택 기반 언어 (단순한 인스트럭션만 제공) |
튜링 완전성 지원 |
| 프로그래밍 언어 |
파이썬 | 스크립트(Script) | 솔리디티, 서펀트, 저급언어 등 처리되는 다양한 언어 지원 | |
| 지연 시간 |
블록 확정 시간 |
1초 미만 | 10분당 1블록 | 14초당 1블록 |
| 최대 트랜잭션 /계약 크기 |
애플리케이션에 따라 유동적 | 100KB | 가스 사용량에 따라 유동적 | |
| 확장성/트랜잭션 처리량 | 1000TPS 이상 | 7TPS | 15TPS | |
| 프라이버시 | 서비스 채널 암호화를 통해 프라이버시 보호 | 개방 | 개방 | |
| 항목 | 루프체인 | 하이퍼레저 패브릭 | R3 코다 |
|---|---|---|---|
| 허가된 사용자만 접근 가능 | ○ | ○ | ○ |
| 스마트 계약 지원 | ○ | ○ | ○ |
| 다양한 합의 알고리즘 지원 | ○ | ○ | ○ |
| 스마트 계약 버전 지원 | ○ | Ｘ | Ｘ |
| 장애 허용 | ○ | Ｘ | Ｘ |
| 트랜잭션 커스터마이징 | ○ | Ｘ | Ｘ |
| SDK 지원 플랫폼 | 자바, C, 파이썬, Node.js | Go, 자바 | 코틀린(Kotlin) |
| 비고 | 거래 및 규제에 따라 전체 스택 커스터마이징 가능 | 0.x 버전과 1.0 버전 호환이 불가하며, 1.0 버전에 대한 릴리즈 일정 미정 | R3 회원사가 아니면 기술지원 불가 |
각주
- ↑ 1.0 1.1 더루프, 〈(블록체인 톺아보기) 더루프, 루프체인〉, 《블로터》, 2017-03-28
- ↑ 2.0 2.1 아이콘루프, 〈LFT – loopchain consensus algorithm〉, 《아이콘루프 블로그》, 2017-07-04
- ↑ 〈loopchain 101〉, 《theloop》
참고자료
- 더루프, 〈(블록체인 톺아보기) 더루프, 루프체인〉, 《블로터》, 2017-03-28
- 아이콘루프, 〈LFT – loopchain consensus algorithm〉, 《아이콘루프 블로그》, 2017-07-04
- 〈loopchain 101〉, 《theloop》
같이 보기
