LFT – loopchain consensus algorithm

저번 포스팅에서는 블록체인을 위한 합의 알고리즘 중, 기존의 상태 머신 복제 프로토콜에서 활용하던 BFT(Byzantine Fault Tolerance)계열 합의 알고리즘에 대해 설명하였습니다. BFT 계열 합의 알고리즘은 머신의 개수나, 지분을 통하여 투표를 하여 합의하는 방식으로 에너지 낭비가 없고 즉각적인 합의가 가능하다는 장점이 있습니다.

블록체인 기술 연재 시리즈

블록체인 기술 개요
스마트 컨트랙트(Smart Contract) 개요 -1
스마트 컨트랙트(Smart Contract) 개요 -2
loopchain SCORE(Smart Contract On Reliable Environment
합의 알고리즘 개요
작업증명(PoW, Proof-of-work)과 지분증명(PoS, Proof-of-stake)
BFT 기반 합의 알고리즘

이번 포스팅에서는 loopchain에서 사용하는 합의 알고리즘인 LFT에 대해서 공개하겠습니다.  LFT는 Tendermint나 PBFT(Practical Byzantine Fault Tolerance)와 마찬가지로 BFT 계열 합의 알고리즘입니다. 기존의 상태 머신 복제 프로토콜중 하나인 Raft를 비잔틴 노드의 공격을 극복할 수 있도록 개선한 알고리즘 입니다.

LFT

LFT는 현재 loopchain에서 사용하는 합의 알고리즘입니다. 그러나 loopchain은 Pulgin형태로 합의 알고리즘이 구현되어있기 때문에 필요에 따라 PBFT와 같은 다른 합의 알고리즘을 사용할 수 있습니다. 추후에 loopchain은 github를 통해 오픈소스 프로젝트로 공개될 것이기 때문에 직접 다운로드 받고 실행 시킬 수 있습니다.

LFT는 기존 PBFT를 사용하는 합의 알고리즘에서 발생하는 통신 오버헤드를 Piggybacking을 이용하여(네트워크에서 메시지를 통합하여 통신 오버헤드를 감소시키는 방법) 줄였으며 Spinning (리더를 매번 교체하는 기법)기법을 이용하여 악의적인 노드가 네트워크의 합의를 해치지 않는 범위에서 네트워크에 문제를 일으킬수 있는 특정 노드의 트랜잭션 거부 문제,  리더에 의한 네트워크 지연과 같은 문제를 해결하였습니다. 또한  기존 알고리즘들이 가지고 있던 지나치게 복잡한 리더 선정 알고리즘을 단순화 하였습니다.

LFT Normal Process

위 그림은 LFT 알고리즘의 합의 과정에 대한 그림입니다. 네트워크가 시작되면 검증 노드(검증을 통해 합의에 참여하는 노드)들은 사전에 결정되어 있는 리더 노드에게 처리를 원하는 트랜잭션을 전송합니다. 리더 노드는 수집한 트랜잭션을 이용하여 블록을 생성하고 자신의 서명과 함께 다른 모든 검증 노드에게 전송합니다.

각 검증 노드들은 블록을 받으면 1) 현 리더가 블록을 생성했는지 확인하고, 2) 블록의 높이와 이전 블록 해시가 올바른지 확인 3) 블록의 데이터가 올바른지 확인합니다. 검증 노드는 1~3번이 옳다면 Vote 데이터를 생성하여 네트워크의 모든 노드들에게 전파합니다. Vote 데이터를 전체 노드에게 전파하는 것은 매우 중요한데 이는 리더 노드가 비잔틴일 경우 정족 수 이상의 노드들에게만 블록을 전파하여 특정 노드들을 네트워크로 부터 분리하도록 시도할 수 있기 때문입니다. 이러한 문제를 방지하기 위해 모든 피어에게 Vote 데이터를 전파하며 이는 기존 Raft 알고리즘과의 다른 점입니다. 이 과정에서 블록을 못받은 노드는 블록이 생성되었는지에 대한 정보를 알 수 있고 다른 노드에게 블록을 요청할 수 있습니다.

본 포스팅에서는 LFT의 동작 방식에 대해 간략하게 설명하였습니다. 기존 알고리즘과의 비교 및 장애 상황 극복 시나리오 등의 자세한 내용은 LFT 백서를 통해 확인할 수 있습니다.

 

loopchain SCORE(Smart Contract On Reliable Environment)

이전 포스팅에서는 스마트 컨트랙트(Smart Contract) 기술이 블록체인 위에서 어떻게 동작하는지에 대해 알아보았습니다.

블록체인 기술 연재 시리즈
블록체인 기술 개요
스마트 컨트랙트(Smart Contract) 개요 -1
스마트 컨트랙트(Smart Contract) 개요 -2

이번 포스트에서는 loopchain의 스마트 컨트랙트인 SCORE(Smart Contract On Reliable Environment) 가 어떤 특징을 가지고 있는지에 대해 알아보도록 하겠습니다.

SCORE(Smart Contract On Reliable Environment)의 특징

loopchain SCORE의 가장 큰 특징은 개발 친화적 언어를 통해 자유롭게 개발환경을 구성할 수 있다는 점입니다. 대표적인 블록체인 기반 스마트 컨트랙트 플랫폼인 이더리움의 경우 특수한 가상머신 EVM(Ethereum Virtual Machine)에서 사용 가능한 언어로만 스마트 컨트랙트를 작성할 수 있습니다. 즉 Solidty, Serpent, LLL을 통해서 스마트 컨트랙트를 개발을 해야하고 데이터 접근 및 저장 또한 EVM 내부 변수를 통해서만 저장할 수 있습니다.

loopchain_archi
SCORE와 합의엔진(Blockchain)이 구조상 분리되어있는  loopchain 모듈 구조

loopchain SCORE는 합의엔진과 의존성을 최대한 떨어뜨린 별도의 모듈로 개발되었습니다. 합의 엔진과 SCORE는 내부 GRPC로 구현된 인터페이스를 통하여 통신을 하기 때문에 인터페이스만 맞으면 어떠한 언어로도 구현이 가능하나 현재는 파이썬 구현체만 허용하고 있습니다. 데이터 베이스 또한 자유롭게 사용할 수 있죠. 다만 이더리움 처럼 변수의 모든 데이터가 저장되지는 않고 데이터베이스에 직접 읽고 쓰고 한 결과만 저장됩니다.

 

SCORE 데모

아직 정확한 일정이 확정되지 않았지만 올해 하반기에 loopchain는 오픈소스로 공개될 예정이며 이때 SCORE 서비스 부분도 함께 공개될 것입니다.

공개 전에 SCORE를 이해하는데 도움이 되도록 SCORE기반 채팅 샘플에 대해 동작 방식과 함께 설명하겠습니다.

채팅서비스는 중계자가 필요한 대표적인 서비스입니다. 채팅 참여자는 각자가 직접 연결되지 않고 채팅서버와 연결한 후 채팅서버에서 보내주는 다른 참여자의 말을 믿고 대화를 진행합니다. 즉, 대화 당사자가 아닌 채팅서버라는 별도의 TTP(Trusted Third Party)가 대화라는 거래를 중계해주는 방식이라고 할 수 있습니다.

이를 스마트 컨트랙트로 간략히 구성한다면 아래와 같습니다.

  • 스마트 컨트랙트로 공유하는 내용
    • 채팅 참여자간 대화록
  • 스마트 컨트랙트 갱신 조건
    • 채팅 참여자가 보내온 대화의 서명이 해당 채팅 참여자의 서명이 맞으면 대화록에 추가함

즉, 채팅 참여자가 각각 블록체인 노드를 구성하고 대화 내용을 포함하고 서명을 하여 거래를 발생시키면 해당 거래가 동기화되고 거래 내역이 정당하면(채팅 참여자의 서명이 맞으면) 거래에 포함된 대화 내용을 전체 대화록에 추가하는 식입니다.

SCORE 기반 채팅 서비스 데모

이전 포스팅에서 설명하였듯이 스마트 컨트랙트는 Transaction과 Query라는 두가지 형태의 인터페이스를 가지고 있습니다. 위 동영상의 ‘보내기’는 Transaction으로써 다른 사람에게 메세지를 보내는 역활을 하며 ‘조회’는 Query로써 채팅방에 올려진 메세지를 확인할 수 있습니다. Query는 본인이 가지고 있는 스마트 컨트랙트의 내용을 확인하는 것이죠.

동영상 시나리오와 같이 한 사용자가 오프라인 상태가 되더라도 다른 사용자에게는 영향이 없으며 다시 온라인 상태가 되면 블록 동기화 과정을 통해 이전에 있던 모든 메세지를 받을 수 있습니다.

사실 채팅서비스는 블록체인이 유용한 어플리케이션이라고 하기는 어렵습니다. Socket.io 등을 이용하면 더 편리하고 실시간성으로 만들 수 있죠. 본 예제는 loopchain SCORE가 어떻게 돌아가는지 보여주기 위해 만든 샘플 정도로 보시면 됩니다. 그러나 예전에 야후 메신저가 내용 위변조가 안되고 모든 내용을 저장하는 특성 때문에 일부 도메인에서 사업 계약에 이용되었던 것을 생각하면 대화내용에 대한 무결성을 보장하는 블록체인 기반 채팅서비스도 상용화될 수 있습니다.

본 포스팅에서는 loopchain의 스마트 컨트랙트인 SCORE에 대해서 알아보았습니다. 다음 포스팅 부터는 블록체인의 또다른 주요 요소인 합의 알고리즘에 대해 알아보도록 하겠습니다.

스마트 컨트랙트(Smart Contract) 개요 -2

이전 포스팅에서는 블록체인 기술이 이렇게 여러 도메인에서 사용할 수 있게 가장 큰 역할을 한 스마트 컨트랙트(Smart Contract)이 무엇이고 어떤 역할을 하는지에 대해 알아보았습니다.

블록체인 기술 연재 시리즈
블록체인 기술 개요
스마트 컨트랙트(Smart Contract) 개요 -1

이번 포스트에서는 스마트 컨트랙트가 실제로 어떻게 동작하는지 알아보도록 하겠습니다.

이전 블록체인 기술 개요 포스팅에서 송금 서비스 예제를 통해서 블록체인 네트워크에 참여하는 노드의 종류와 역할, 그리고 각 노드가 가지고 있는 데이터에 대해서 알아보았습니다. 이번 글에서는 이 내용을 바탕으로 기술할 것입니다.

블록체인 기술 개요에서 설명한 것 처럼 블록체인 네트워크의 노드는 두 가지 데이터베이스를 가지고 있습니다. 하나는 모든 거래 내용이 보관된 트랜잭션 데이터베이스고 또 하나는 저장된 트랜잭션을 기반으로 서로 사전에 약속한 어플리케이션에 적용하는 어플리케이션 데이터베이스 입니다.

비트코인의 경우 스마트 컨트랙트가 지원되지는 않지만, 비트코인이라는 자산이 이동되는 단 하나의 송금 어플리케이션이 블록체인에 올라간 서비스라고 볼 수 있습니다.

Ethereum 같은 스마트 컨트랙트 지원 블록체인의 경우 스마트 컨트랙트의 상태를 변경시키는 트랜잭션 보관 데이터베이스와 스마트 컨트랙트의 최신 상태를 보관하고 있는 스마트컨트랙트 데이터베이스를 가지고 있습니다.

여기서 스마트 컨트랙트는 상태를 변경할 수 있는 어플리케이션이라고 할 수 있고 스마트 컨트랙트의 상태는 해당 어플리케이션에서 사용하는 변수라고 할 수 있으며 이를 변경하기 위한 입력값은 트랜잭션에 포함되어 있다고 볼 수 있습니다.

스마트 컨트랙트 상태(State)를 저장하는 데이터베이스의 경우 Ethereum처럼 높은 압축률을 위해 트랜잭션을 저장하는 데이터베이스와 합쳐져 있는 경우도 있고 아니면 분산합의와 스마트 컨트랙트의 낮은 의존성을 달성하기 위해 완전히 분리된 경우도 있습니다.

예제 스마트 컨트랙트 설명 

스마트 컨트랙트 블록체인은 두 가지 인터페이스를 공개하고 있습니다. 하나는 트랜잭션(Transaction) 이고 하나는 쿼리(Query)입니다. 트랜잭션을 통한 인터페이스는 트랜잭션 데이터베이스에 저장되고 스마트 컨트랙트의 State를 변경시키는 접근방법입니다. 쿼리는 트랜잭션 데이터베이스에 기록이 남지 않으면서 스마트 컨트랙트의 State를 읽는 작업입니다. 트랜잭션은 Write, Delete, Modify를 실행한다면 보면 되고 Query는 Read만을 실행한다고 생각하시면 됩니다.

본 포스팅에서는 스마트 컨트랙트를 통한 디지털 컨텐츠 거래 예제를 통해 스마트 컨트랙트가 실제로 어떻게 동작하는지 알아보도록 하겠습니다. 거래되는 디지털 컨텐츠는 DNS와 같은 온라인 자산일 수도 있고 Hash나 금 일련번호와 같은 다른 자산을 나타내는 증거 데이터일 수도 있습니다.

본 예제 스마트 컨트랙트에서 제공할 인터페이스는 다음과 같습니다.

Transaction

  • 컨텐츠 등록
  • 컨텐츠 구매

Query

  • 컨텐츠 조회

디지털 컨텐츠 거래 예제를 통한 스마트 컨트랙트 동작 방식

SoWkIImgAStDuKfCBialKdZRC-7ryYLlvas0ybzjNGFbmsKKTEqKNk-OydhXt3URjhoPkqF1Ik7DxXLlMoUysR50uVNaZK09BhWsl8hVBDpmTbOFaOeXghWSKlDIWCu50000.png
디지털 컨텐츠 거래 순서

스마트 컨트랙트를 통한 디지털 컨텐츠 거래 시나리오는 위의 예제 시나리오와 같이 동작할 것입니다. 각 내용에 따라 어떤 일을 실제로 수행하는지 알아보도록 하죠.

  1. 컨텐츠 판매자가 컨텐츠 등록 트랜잭션을 블록체인에 보낸다.
스크린샷 2017-04-03 오후 5.27.23.png
상품 등록 트랜잭션 생성시 네트워크 동작

컨텐츠 등록 트랜잭션 발생 시 블록체인 네트워크 내부에서는 위의 다이어그램과 같이 동작합니다. 네트워크의 모든 노드는 컨텐츠 등록 트랜잭션을 공유하고 트랜잭션 데이터베이스에 저장하게 됩니다. 여기까지가 비트코인과 같은 스마트 컨트랙트가 지원되지 않는 데이터 공유 기반의 블록체인이라고 할 수 있습니다. 스마트 컨트랙트 지원 블록체인은 이 단계 이후에 트랜잭션의 내용에 따라 스마트 컨트랙트 어플리케이션을 실행하고 그 결과를 스마트 컨트랙트 데이터베이스를 반영합니다. 이후 모든 트랜잭션은 전부 위 그림과 같은 방식으로 동작합니다.

  1. 구매자는 블록체인 네트워크에서 컨텐츠 조회한다
스크린샷 2017-04-03 오후 5.45.07.png
상품 조회 내부 동작

위의 다이어그램은 컨텐츠 조회 동작 방식을 나타낸 것입니다. 매우 간단합니다. 클라이언트가 검색 쿼리를 보내면 노드는 그에 대해 응답을 해줍니다.

블록체인의 어떤 데이터도 변경시킬 필요 없이 스마트 컨트랙트 데이터베이스 내 저장된 상태 값만 조회하면 되기 때문에 쿼리 정보는 블록체인에 동기화할 필요 없고 블록 동기화 타이밍에 상관없이 바로 응답할 수 있습니다. 블록체인의 트랜잭션 속도는 다른 네트워크보다 느리지만 쿼리 속도는 같은 머신의 내부 DB를 사용해서 쿼리 해주고 어떤 노드에 접속해도 같은 결과를 얻을 수 있기 때문에 중계자를 통한 서비스보다 오히려 속도가 빠를 수도 있습니다.

  1. 컨텐츠 구매
    구매자가 컨텐츠 구매 트랜잭션을 보내면 1의 다이어그램과 같이 트랜잭션을 공유하고 블록체인 네트워크에 동기화합니다. 모든 노드의 스마트 컨트랙트 데이터베이스에 컨텐츠 구매자를 등록하고 돈을 판매자에게 전송합니다. 또한, 등록된 컨텐츠의 소유권을 구매자로 이동합니다.

이번 포스팅에서는 스마트 컨트랙트 동작 방식을 스마트 컨트랙트를 통한 디지털 컨텐츠 거래를 통해 알아보았습니다. 특히 Transaction과 Query는 모든 스마트 컨트렉트 블록체인에서 동작하는 방식이 거의 유사하므로 대부분 블록체인이 이와 같은 방식으로 동작합니다.

R3 Corda나 Hyperledger Fabric 1.0처럼 블록체인에 참여한 모든 노드가 거래를 공유하지 않고 해당 거래에 참여한 노드끼리만 거래를 공유하고 스마트 컨트랙트를 실행하는 것도 해당 거래에 있어서는 이와 동일하다고 할 수 있습니다.

다음 포스팅에서는 이와 같은 스마트 컨트랙트가 실제 구현체에서는 어떻게 작동하는지 loopchain의 스마트컨트랙트인 SCORE(Smart Contract on Reliable Envirement)를 기반으로 예제 어플리케이션과 함께 설명하도록 하겠습니다.

스마트 컨트랙트(Smart Contract) 개요 -1

이전 포스팅에서는 블록체인 기술 시리즈 1부로 블록체인의 기능과 블록체인의 메인 자료구조 그리고 블록체인 네트워크가 어떻게 동작하는지에 대해 거래 시나리오를 통해 설명하였습니다.

블록체인 기술 개요

본 포스팅에서는 블록체인을 단순한 원장 기반의 디지털 화폐 거래 플랫폼을 넘어 다양한 서비스에 적용할 수 있도록 만들어준 스마트 컨트랙트(Smart Contract)에 대해 알아보도록 하겠습니다.

Smart Contract 

스마트 컨트랙트는 Nick Szabo가 1994년 최초 제안한 개념입니다. 기존 계약서(Contract)는 서면으로 되어있어 계약 조건을 이행하려면 실제 사람이 계약서 대로 수행을 해야 하지만 디지털 명령어로 계약을 작성하면 조건에 따라 계약 내용을 자동으로 실행할 수 있다고 주장하였습니다.

SmartContract

디지털로 된 계약서는 조건에 따른 계약 결과가 명확하고, 계약 내용을 즉각 이행할 수 있습니다. 각자의 자산이 연결된 디지털로 양자 합의를 하고 계약서를 작성하고 실행하기로 한다면 계약을 이행하는데 복잡한 프로세스를 엄청나게 간소화 될 것 입니다. 또한 다양한 그러나 디지털로 된 자료들은 쉽게 복사되고 조작이 쉬워 1994년에 제안한 스마트 컨트랙트는 개념으로만 존재하고 구체적인 서비스에 이용될 수 없었습니다.

블록체인(Blockchain)과 스마트 컨트랙트 (Smart Contract)

이전 포스팅 들에서 설명하였듯이 블록체인은 디지털 데이터를 신뢰할 수 있게 만들어 주는 기술입니다. 다수의 노드가 같은 데이터를 공유하고 검증하는 방식을 통해 디지털상에 신뢰관계를 만들었죠.

스마트 컨트랙트는 이러한 블록체인과 함께 급부상하게 됐습니다. 스마트 컨트랙트를 만들 수 있는 환경이 20여 년이 지나 구체화 된 것이죠. 최초의 블록체인 기반 스마트 컨트랙트는 비트코인 스크립트입니다. 비트코인 트랜잭션에 원시 언어인 OPCODE로 스크립트를 작성해서 보내면 조건에 따라 자동으로 거래를 수행합니다. 스크립트가 정상이면(기존에 보유한 비트코인의 잔액이 정확하고 거래를 보낸 사람의 서명이 정확한지 보는 것이 가장 기본적인 스크립트) 거래를 정상으로 본다는 일종의 계약(Contract) 개념이 있으므로 Contract Code로 불리기도 합니다.

하지만 비트코인 스크립트는 반복문을 사용할 수 없고, 비트코인 잔고 외의 다른 정보를 관리 할 수 없는 한계가 있습니다. 이는 블록체인의 특이한 구조 때문인데 비트코인 스크립트에서 반복문을 허용할 경우 만약 스크립트 조건 때문에 무한 루프가 발생할 경우 네트워크 전체가 멈출 수 있습니다. 사용자는 무한루프를 통해 쉽게 DoS(Denial of Service) 공격을 할 수 있습니다.

이더리움(Ethereum)은 이러한 비트코인 스크립팅 시스템의 한계를 극복하고자 나온 스마트 컨트랙트 특화 블록체인 플랫폼입니다. 사실 스마트 컨트랙트란 용어가 본격적으로 사용하기 시작한 것은 이더리움 이후라고 보면 됩니다. 이더리움은 비트코인 스크립팅 시스템의 한계인 다양한 상태 저장과 반복문을 허용한 스마트 컨트랙트를 만들었습니다. 여기에 각 라인을 실행할 때마다 수수료를 발생시키고 네트워크상에 수수료의 한계를 설정하여 무한루프를 막았습니다. 무한히 반복되는 조건을 만들어 스마트 컨트랙트를 실행시키면 돌다가 중간에 수수료 한계점에 도달하면 중단됩니다.

스크린샷 2017-03-28 오전 10.58.59.png
Solidity 온라인 컴파일러를 통해 스마트 컨트랙트를 작성하고 가스 소모량을 확인할 수 있다. (출처: ethereum.github.io)

이는 기발하지만 뜻밖에 간단한 논리에 의해 구현되게 되었는데 블록체인을 통해 함수 내용과 함수의 입력을 공유하면서 무결성을 보장한다면, 함수의 결과는 별도로 공유하지 않더라도 그 무결성이 보장된다는 것이죠. 이더리움은 함수를 컴파일된 코드 형태로 거래에 포함하여 블록체인을 통해 동기화합니다. 이때 거래에 포함된 정보를 함수의 입력으로 하여 코드로 표현된 함수를 실행한 후 그 결과를 별도의 상태로 보관하는 방식으로 스마트 컨트랙트를 구현하게 되었습니다.

그리하여 독자 코인인 이더 외에 다른 디지털 객체의 상태를 저장하는 방식을 허용하여 다양한 재화를 이더리움 네트워크 위에 만들고 거래할 수 있게 되었습니다. 이더리움 상에서의 가장 유명한 스마트 컨트랙트의 예는 DAO(Decentralized Autonomous Organization)라고 불리는 탈중앙화된 자율 조직입니다. 이는 회사의 의결권을 토큰(DAO Token)으로 행사할 수 있도록 크라우드 펀딩을 통해 토큰을 이더로 구입할 수 있도록 판매하였고 그 과정에서 모인 약 2000억원 가량의 이더를 어떻게 사용할지 토큰을 기반으로 투표할 수 있도록 한 스마트 컨트랙트로서 특정 운영주체가 없이 참여자의 투표로 운영되도록 했습니다.

The-DAO-.jpg
DAO 주주들의 지분을 통한 의사 참여 방법 (출처 : themerkle.com)

참고로 DAO는 DAO 스마트 컨트랙트 코드의 논리 오류 때문에 해커의 공격을 당해 엄청난 피해가 발생하게 되자 이더리움 전체를 Hard fork, 즉 롤백하는 등 우여곡절이 있었습니다. 기회가 되면 다음에 이 사례에 관해서도 설명하도록 하겠습니다.

이더리움 기반 다양한 스마트 컨트랙트들은 여기서 확인하실 수 있습니다.

본 포스팅에서는 스마트 컨트랙트의 개념을 설명하였습니다. 스마트 컨트랙트에 대한 개념 설명이라 잘 이해가 안 되실 수 있습니다. 다음 포스팅에서는 스마트 컨트랙트가 실제로 어떻게 동작하는지에 대해 예제를 통해 구체적으로 설명하도록 하겠습니다.

블록체인 기술 개요

지금까지는 금융권이 왜 블록체인 기술에 관심 있고 금융권을 위한 블록체인에는 어떠한 요구사항이 있는지, 현재 프라이빗 블록체인 진영은 어떤 식으로 발전하고 있는지에 대해서 살펴봤습니다.

금융권을 위한 블록체인 관련글 보러가기

  1. 왜 금융권에서는 블록체인에 주목할까?
  2. 퍼블릭 블록체인의 한계와 프라이빗 블록체인 -1
  3. 퍼블릭 블록체인의 한계와 프라이빗 블록체인 -2
  4. Hyperledger Fabric, R3 Corda
  5. theloop loopchain

지금까지의 포스팅에서는 금융권 블록체인에 대한 요구사항과 현 상황에 대해 알아보았습니다.

이번 글부터는 블록체인 상에서의 거래, 합의, 스마트 컨트랙트 등 주요 요소에 대해 기술적으로 살펴보려고 합니다. 우선 블록체인이 어떻게 동작하는지 거래 예제를 통해 설명하도록 하겠습니다.

블록체인 네트워크 구성원

대표적인 블록체인 네트워크인 비트코인을 포함하여 일반적인 블록체인 네트워크 구성요소는 두 가지입니다. 바로 블록체인 노드와 블록체인 클라이언트입니다.

  • 노드 : 트랜잭션 내역 보관, 트랜잭션 승인, 분산합의
  • 클라이언트 : 트랜잭션 생성, 거래 내역 확인 (비트코인의 경우 지갑)

사용자 관점에서는 블록체인의 노드는 일반적인 서비스의 백엔드(Backend) 역할을 하고 블록체인 클라이언트는 클라이언트 역할을 합니다. 클라이언트가 새로운 트랜잭션을 발생시키면 노드들은 트랜잭션을 분산합의 과정을 통해 공유하고 트랜잭션을 실행하죠. 클라이언트는 트랜잭션의 결과를 확인할 수 있습니다.

블록체인 노드는 두 가지 종류의 데이터베이스를 가지고 있습니다. 올바른 트랜잭션을 모두 보관하는 블록체인 트랜잭션 보관 데이터베이스와 저장된 트랜잭션을 어플리케이션에 적용한 어플리케이션 데이터베이스를 가지고 있습니다.

스크린샷 2017-03-13 오후 3.30.51.png
블록체인 자료구조(트랜잭션 내역 DB)

노드가 가지고 있는 두 가지 DB 중 트랜잭션 목록을 보관하는 DB는 블록체인(Block-chain)이라는 특이한 구조로 되어 있습니다. 이 DB의 특이한 구조가 이제는 전체를 대표하는 명칭이 되었죠. 트랜잭션 내역 DB는 블록체인이라는 이름처럼 블록이 연결된 구조로 되어 있습니다. 각 블록은 순서가 정해진 트랜잭션 리스트가 있고 각 블록들은 시간의 순서대로 연결되어 있죠(순서가 기재되어 있습니다). 블록체인 자료구조를 이용하면 모든 트랜잭션의 순서를 확정 지을 수 있습니다.

암호화 화폐 거래 예제 

블록체인 네트워크에 참여하는 객체에 이어 실제 블록체인 기반 암호화 화폐(Cryptocurrency) 송금 예제를 통해 실제로 어떻게 동작하는지 알아봅시다.

잠깐 이야기를 돌려서 실물화폐의 경우 실제 전달하는 방법은 매우 간단합니다. 자신이 가지고 있는 화폐를 실제 전달받는 사람에게 전하면 되죠. 하지만 디지털 거래의 경우 실제 화폐를 주고받을 수 없으므로 다른 방식으로 거래를 합니다. 거래 내용에 맞게 장부를 갱신하는 것이죠.

A와 B가 OO 은행을 이용한다고 가정했을 때 A가 B에게 10만 원을 송금하면 OO 은행에 있는 장부에서 A가 B에게 10만 원을 보냈다는 기록과 함께 A의 잔액이 10만 원이 감소하고 B의 잔액이 10만 원이 증가합니다. 즉, 거래 내용과 잔액의 상태, 두 가지 정보가 있고 거래 내역이 검증되면 잔액의 상태가 변경됩니다. 암호화 화폐 거래 방식도 이와 같은 방식입니다.

블록체인이 Peer-to-Peer 네트워크라고 해서 다른 사람에게 직접 돈을 보낸다고 생각할 수 있지만, 노드들의 네트워크 위상(Topology)이 전부 같은 Peer-to-Peer 네트워크인 것이지 실제 돈이 오가는 것은 노드들이 보관하는 데이터베이스를 갱신하는 방식으로 동작합니다. 은행에서 일어나는 거래 방식과 유사하죠.  은행의 경우 거래 데이터를 유지하는 은행이 거래에 대한 보증 주체라면 블록체인 네트워크의 경우 블록체인에 참여하는 모든 노드가 전부 같은 장부를 유지한다는 것이 다르고 나머지 과정은 유사합니다.

스크린샷 2017-03-13 오후 2.43.49
디지털 화폐 거래 순서도

위의 그림은 암호화 화폐 송금 시 일어나는 일에 대해서 그린 다이어그램입니다. A가 B에게 돈을 보내기 위해 트랜잭션을 생성하여 블록체인 네트워크에 전파하면 블록을 생성하는 노드는 트랜잭션을 모아 블록에 저장합니다. 이때 A의 잔액이 충분한지, 중복 으로 사용하지 않는지 등 거래에 대한 검증은 별도로 이루어지며 이러한 검증 방법은 거래에 따라 달라지게 됩니다.

이후 해당 트랜잭션들을 적용해 자신의 잔액 DB를 갱신하고 다른 노드들에 블록을 전파합니다. 다른 노드들은 전파된 블록 데이터에 따라 자신의 잔액 DB를 갱신하고 블록을 저장합니다. 이제 모든 노드의 잔액 DB와 트랜잭션 내역 DB가 갱신되었습니다. 장부가 갱신되었다는 것은 송금이 완료되었다는 것입니다. 거래가 완료되었습니다.

앞선 과정 중 블록 생성 노드를 정하는 과정이나 동시에 블록이 생성되었을 때 올바른 블록을 선택하는 과정은 분산합의 알고리즘에 따라 달라집니다. (Proof of Work와 같은 경쟁 형태의 분산합의 알고리즘의 경우 여러 개의 블록 생성 노드가 정해질 수 있습니다) 다음에 분산합의 관련 포스팅을 통해 이 과정에 대해 자세히 설명하겠습니다.

이번 포스팅에서는 블록체인 기술 개요로 블록체인 네트워크에 참여하는 객체들에 대한 설명과 암호화 화폐 예제를 통해 실제로 어떻게 돌아가는지 알아보았습니다. 다음에는 블록체인을 단순한 화폐 시스템이 아니라 다양한 서비스에 적용할 수 있게 확장한 스마트 컨트랙트에 대해 알아보도록 하겠습니다.

theloop loopchain

저번 포스팅에서는 금융권 블록체인 요구사항과 Hyperledger Fabric과 R3 Corda가 금융권 요구사항을 만족시키기 위해 어떠한 방식으로 프라이빗 블록체인을 구현하였는지 알아보았습니다.

이전 포스팅 바로가기 

이번 포스팅에서는 드디어! 더루프가 어떤 회사이고 더루프에서 개발하고 있는 블록체인인 loopchain에 대해 소개하도록 하겠습니다.

더루프(theloop)

더루프는 2016년 탄생한 프라이빗 블록체인 전문 기업입니다. 블록체인 기술을 이용해서 공유와 신뢰에 필요한 사회적 비용을 감소시키고 서로 신뢰할  수 있는 디지털 세계를 만들기 위해 여의도 IFC에서 밤낮으로 노력하고 있습니다. 루프라는 이름은 외부에 폐쇄되고 내부가 모두 연결된 또한 중지 없이 운영되는 블록체인 네트워크 환경을 상징하고 있습니다.

[참고] 더루프 블로그를 시작하며

더루프는 블록체인 엔진인 loopchain을 독자개발하였으며 현재 금융투자업권 컨소시엄에 기술 파트너로 참여하고 있습니다. 이외에 대학 내 디지털 화폐 프로젝트인 서강코인 PoC를 마쳤고 프라이빗 블록체인 기반 디지털 화폐 서비스를 구현하는 등 블록체인을 활용할 수 있는 모든 분야에 대해 고민하고 있습니다.

더루프를 소개하는데 금융투자업권 컨소시움을 빼놓을 수 없을 것 같습니다. 금융투자업권 컨소시움은 금융투자협회내 26개 증권사와 IT기술회사 5개가 모여 금융권을 혁신할 블록체인 기술에 대해 연구 개발 및 실제 서비스를 하기 위해 만든 국내 최초의 블록체인 컨소시움입니다. 더루프는 금융투자업권 컨소시움에서 블록체인 엔진 및 솔루션을 지원하고 있습니다. 올해는 블록체인 기반 사설인증서 시범 서비스를 통해 실제 서비스에 적용할 계획을 가지고 있습니다. 사설인증서 서비스를 시작으로 향후 금융권을 혁신할 다양한 블록체인 기반  서비스를 제공할 것입니다.

loopchain

loopchain은 더루프가 독자개발한 프라이빗 블록체인 엔진입니다. 우선적으로 금융거래를 지원하는 것을 목적으로 개발되고 있으며 추후 IoT 환경 등 블록체인이 적용 가능한 다양한 서비스를 구성하기 위한 엔진 개발을 목표로 하고 있습니다.

loopchain은 이전 포스팅에서 포스팅한 Hyperledger Fabric이나 R3 Corda에 비해 블록체인의 기본에 더욱 충실한 구조를 가지고 있습니다. Hyperledger Fabric처럼 중앙에 트랜잭션 순서를 정해주는 무엇인가가 있고 체인은 이 내용을 검증해주는 구조랑 달리 기본 비트코인 블록체인 처럼 블록이 연결된 구조를 모두가 합의 하는 방식으로 순서를 정해주고 있습니다.  R3처럼 Instant Network를 추구하는 것이 아닌 이해관계가 있는 노드들이 반 영구적으로 네트워크를 구성하는 블록체인입니다.

loopchain_archi
loopchain 모듈 방식

더루프는 금융권 요구사항을 만족하면서 새로운 요구사항에 맞게 시스템을 변화하기 위하여 loopchain을 유연한 구조로 만들기 위해 노력했습니다. loopchain 모듈에서 Admin Layer는 주로 블록체인 네트워크 관리를 위해 노드의 장애 상황을 감독하고, 스마트 컨트렉트(SCORE : Smart Contract on Reliable Environment)의 버전을 관리하고, 각 노드의 권한을 감독합니다.  Engine Layer는 블록체인 노드의 주 역활인 분산합의, 원장 저장, 스마트 계약 실행을 담당 합니다. 특히 분산합의를 위한 엔진 모듈인 Blockchain과 실제 블록체인에 올라가는 서비스와 실행환경인 SCORE가 분리되어 있습니다. 마지막으로 Interface Layer는 다른 비지니스 어플리케이션이 블록체인 네트워크에 접속할 수 있는 환경을 만들어줍니다.

%e1%84%89%e1%85%b3%e1%84%8f%e1%85%b3%e1%84%85%e1%85%b5%e1%86%ab%e1%84%89%e1%85%a3%e1%86%ba-2017-03-03-%e1%84%8b%e1%85%a9%e1%84%8c%e1%85%a5%e1%86%ab-11-30-43
loopchain 특징

블록체인을 통해 다양한 서비스를 제공하기 위해서는 앞선 포스팅에서 설명하였던 기존 블록체인의 한계점을 극복하는 엔진을 개발하고 거래에 따른 커스트마이징이 필요합니다. 특히 loopchain의 1차 목표는 금융권을 위한 블록체인이기 때문에 이해당사자끼리만 데이터를 볼수 있는 Private Channel 기능, 블록체인 네트워크 참여 기관 별로 다른 기능을 가지게 하는 Tried System, 마지막으로 다양한 금융 서비스를 원할하게 지원하기 위한 빠른 속도를 목표로 개발한 블록체인 입니다.

Admin Layer에서는 각 네트워크에 참여하는 노드들을 관리 감독 합니다. Admin Layer에서 각 노드의 권한을 제한하고, 암호화 프로토콜을 통한 메세지 교환 방식, 또 비트코인 라이트닝 네트워크 프로토콜을 이용해 Tried System과 Private Channel을 구현하고 있습니다. 현재 각 특징을 구현하는 두가지 방식이 있는데 추후에 늘어 날 수도 아니면 한가지 방식으로 통합될 수도 있습니다.

loopchain에서는 높은 성능을 보장하기 위해 PBFT방식과는 다른 리더 중심의 분산합의 방식과 리더 장애 극복 알고리즘을 통해 BFT 문제를 해결하고 있습니다. 추후 포스팅에서 분산합의 알고리즘에 대한 개요 및 전체 이야기를 할 때 자세히 소개하도록 하겠습니다. 또한 블록체인 서비스를 동작하는 부분(SCORE)과 합의엔진을 완전히 분리하였고 합의엔진 내에서도 모듈 및 가용성 요구사항에 따라 프로세스를 여러개 분리하는 방식으로 고성능 블록체인이 구현되었습니다.

그 밖의 중요한 특징으로는 Portal이라는  자체 개발한 프로토콜을 이용하여 리더 노드를 통한 블록체인 외부 데이터(외부 블록체인) 접근 및 분산합의 방법(R3 Corda및 일부 블록체인에서 제공하는 Oracle과 유사하다고 생각하시면 됩니다.), SCORE (Smart Contract on Reliability Environment)의 버전 방식과 Migration없이 동작하는 네트워크에서의 업데이트 및 하위 호환성 지원, SCORE Store를 통한 스마트컨트랙트 배포 및 버전관리등의 특징이 있습니다. 또한 더루프는 블록체인 내에서 인증서를 발급하는 독자기술을 개발하여 이번에 금융투자업권 컨소시움의 첫번째 시범 모델로 사용할 예정입니다.

본 포스팅에서는 더루프에 대한 소개와 함께 금융거래 요구사항을 loopchain에서 어떻게 구현하고 있는지 알아봤습니다. 이 포스팅으로 금융권을 위한 블록체인에 관한 내용을 마무리 합니다. 이후 포스팅에서는 블록체인 기술에 대한 조금 더 심도있는 내용으로서 분산합의, 스마트컨트랙트, Oracle, 라이트닝 네트워크 등 기술적인 내용들을 중심적으로 포스팅하도록 하겠습니다.

Hyperledger Fabric, R3 Corda

이전 포스팅에서는 퍼블릭 블록체인의 한계에 대한 두 번째 글로서 사이드 체인과, 퍼블릭 블록체인 구현체의 한계에 대해 정리하였습니다.
이전 포스팅 바로 가기

이번 포스팅에서는 앞선 포스팅에서 논의했던 금융권 블록체인 요구사항에 대해서 정리하고 유명세를 얻고 있는 프라이빗 블록체인 솔루션인 Hyperledger Fabric과 R3 Corda에서는 어떤 방식을 통하여 이 러한 요구사항을 만족시키고 있는지 알아보겠습니다.

금융권 블록체인 요구사항

금융권에서는 금융서비스 특성과 관련 법률 및 규제로 인한 다양한 요구사항들이 있습니다. 이러한 요구사항을 비트코인, 이더리움이나 퍼블릭 블록체인 구현체를 기반으로 만족하기는 쉽지 않은 일입니다. 다음은 금융권 블록체인에서 요구하는 대표적인 요구사항입니다.

  • Private Channel
  • 권한이 다른 노드들
  • 빠른 속도
  • 스마트 컨트랙트
  • 커스터 마이징

Private Channel 거래 시 거래와 직접적인 관계가 있지 않은 참여자에게는 거래 내용을 공개해서는 안 된다는 조건입니다. 사실 당연한 이야기지만 전통적인 블록체인을 이용할 경우 어려울 수 있습니다. 또한, 블록체인 네트워크에 참여한 노드들이 전부 같은 권한을 가지면 안 됩니다. 금융업 특성상 거래에 대한 검증을 수행하는 기관, 향후 감사를 수행하는 감독 기관 등 다양한 권한의 노드가 블록체인 네트워크에 참여해야 할 가능성이 높습니다. 이때 감독 기관은 모든 Private Channel의 내용을 확인해야 합니다. 그러나 트랜잭션을 발생시키면 안 되겠죠.

빠른 속도는 이유를 설명할 필요 없을 정도로 당연한 요구사항입니다. 우리가 사용하는 금융서비스는 주식거래 등 촌각을 다투는 거래를 포함해서 실시간성 거래 비중이 높습니다. 서비스 속도가 느릴 경우 쾌적하지 못한 사용자 경험뿐 아니라 업무에 따라 금전적인 손해가 발생하는 등 실제 금융 사고로까지 이어질 수 있습니다.

또한, 금융서비스에서 거래 데이터에 대한 분산 저장을 통한 데이터 무결성 보장도 중요한 가치이긴 하지만 블록체인을 단순히 원장 정보를 복제하는 클러스터링 솔루션 정도로 바라보는 것은 아닙니다. 금융기관들은 블록체인을 통해 기존의 청산소(Clearing house)와 같은 중계자없이 금융거래를 수행하고자 하며 이를 위해 스마트 컨트랙트는 필수요소가 되었습니다. 스마트컨트랙트는 블록체인을 단순한 분산 원장이 아닌 분산 어플리케이션 서버로서 자리 잡게 한 요즘 블록체인에서 가장 뜨거운 기술입니다.

마지막으로 블록체인 엔진 자체를 커스터 마이징 하며 확장 가능해야 합니다. 금융권 블록체인이라고 카테고리를 지었지만, 금융권 자체에도 정말 다양한 서비스가 있습니다. 이러한 서비스마다 요구사항이 다르기 때문에 블록체인은 합의 엔진 부터 전체 스택을 커스터 마이징 할수 있어야 합니다.

Hyperledger Fabric와 R3 Corda 

Hyperledger Fabric과 R3 Corda에 대해서 간략하게 이야기해 보도록 하겠습니다. Fabric은 Linux foundation에서 주도하는 블록체인 프로젝트인 HyperLedger 소속의 프로젝트로 R3 Corda와 함께 가장 많은 관심을 받는 블록체인 프로젝트입니다. 금융권 뿐 아니라 범용 블록체인을 표방하고 있는 블록체인입니다.

스크린샷 2017-02-15 오후 5.31.32.png
HyperLedger Architecture(출처 HyperLedger)

Fabric의 가장 큰 특징은 네트워크 분리입니다. Fabric은 이해관계자와 응용프로그램의 종류에 따라 새로운 Channel(일종의 소규모 블록체인)을 구성합니다. 또한 권한 관리 모듈인 COP을 통하여 각 Channel에서 각 노드가 가지는 권한이 무엇인지 구분합니다.

R3는 분산 원장 기반의 스타트업으로 골드만 삭스 등 대형 금융업체의 투자를 받았으며 세계적인 대형 은행들과 협약을 맺고 컨소시움을 이뤘습니다. 현재 세계적으로 가장 많은 블록체인 은행들이 참여하고 있는 컨소시움을 주도하고 있습니다.

screen-shot-2016-04-26-at-2-56-34-pm
R3 Corda 합의 과정(출처 : R3 Cev)

R3의 분산원장 플랫폼 Corda의 가장 큰 특징은 탈 블록 체인화 입니다. 블록체인이 아니라 굳이 분산원장이라고 한 이유는 R3는 블록체인을 버렸습니다. R3는 블록체인의 여러 가지 한계를 극복하고자 모든 네트워크 참여 원들이 같은 데이터를 공유하는 블록체인을 버리고 이해 관계자들끼리만 같은 데이터를 공유하는 방식을 선택하였습니다. 하나의 스마트 계약을 실행하면 이때 이해관계자의 역할에 따라 스마트 컨트렉트 검증, 데이터 공유 일을 수행합니다.

Fabric과 Corda는 금융권 요구사항을 어떻게 해결하였을까?

Fabric은 범용 블록체인을 표방하고 있지만, 그 이야기가 금융권을 포함하지 않는다는 이야기가 아닙니다. 여전히 블록체인은 비금융권 보다는 금융권에서 관심이 있으므로 Fabric은 금융권 요구사항을 대부분 만족하고 있습니다. Corda는 금융업을 위해서 만들어진 분산원장 플랫폼이기 때문에 당연히 이러한 부분을 만족하고 있습니다. 이들은 어떤 식으로 해결할까요?

Private Channel는 두 플랫폼이 특이한 구조를 통해 해결합니다. 이해관계가 있는 노드만 합의하는 방식이죠. Fabric 같은 경우 이해관계가 있는 노드들만 채널을 구성합니다. 다른 Channel의 노드들은 해당 내용을 볼 수 없죠. Corda의 경우 애초에 스마트 컨트랙트 하나를 실행할 때 이해관계자들끼리만 내용을 공유하여 문제를 해결합니다.

노드 별로 다른 권한을 주는 이슈는 Fabric의 경우 COP이라 불리는 권한관리 모듈을 통해 내용 보관 노드, 순서 검증 노드, 트랜잭션 생성 노드, 내용 검사 노드 등의 권한을 나누어 처리합니다. 이러한 권한은 채널마다 다르죠. Corda의 경우 각 스마트 계약에 관계된 노드들의 역할과 권한이 명시되어 있습니다. 만약 거래에 판매자 A, 구매자 B, 감독기관 C가 필요하면 Corda는 스마트 컨트랙트 실행을 통해 이 이해관계자들이 얻어 스마트 컨트랙트를 실행하는 방식입니다.

성능 이슈 관련해서는 두 솔루션 전부 아직 언급이 없습니다. 그러나 네트워크를 가볍게 하는 작업을 기본적인 요구사항을 충족할 정도가 되지 않을까 생각합니다.

커스터 마이징에 관해서는 Fabric의 경우 분산합의 알고리즘 변경, 체인코드(스마트 컨트랙트) 변경 등이 가능할 것으로 보입니다. Corda의 경우 엔진 자체를 변경하는 것은 어렵고 스마트 컨트랙트 변경과 각 스마트 컨트랙트 합의 과정(Consensus Protocol) 커스터 마이징 가능할 것으로 보입니다. 두 프로젝트 다 엔진 자체의 커스터 마이징은 어렵지만 핵심 기능인 컨트랙트와 합의 알고리즘을 커스터 마이징 할 수 있었습니다.

본 포스팅에서는 대표적인 프라이빗 블록체인 프로젝트인 Hyperledger Fabric과 R3 Corda가 어떻게 금융권의 요구사항을 만족하였는지 알아보았습니다. 두 블록체인은 기존 블록체인에 없는 개념들을 많이 추가하여 전통적인 블록체인과 다른 완전히 새로운 블록체인을 만들었습니다. R3는 이제 블록체인 개념에서 완전히 벗어났죠. 하지만 두 블록체인 모두 아직은 개발 중인 프로젝트입니다. 아직 모자란 개념이 있을 수 있고 더욱 발전하는 프로젝트이죠. Hyperledger Fabric의 경우 올해 초 1.0 버전이 나왔고 R3의 경우 작년 말에 처음으로 소스를 공개하였습니다. 두 프로젝트 모두 현재까지 지속해서 발전하고 있으며 더루프도 이러한 공개 프로젝트를 통해 국내외의 다양한 요구사항에 대한 정보를 얻을 수 있었고 loopchain을 만드는 데 많은 도움이 되었습니다.

다음 포스팅에서는 드디어 loopchain의 특징과 금융권의 요구사항을 어떠한 방식으로 해결하였는지에 대해 글을 써보도록 하겠습니다.