블록체인 전문 리서치 스타트업 ‘피넥터’ 팀이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.

코다의 아키텍처에 대한 설명 이전에, 분산원장을 금융에 적용하기 위한 필수요건을 먼저 알아보아야 한다. 이는 금융권 대상의 분산원장 또는 블록체인을 개발하는 회사라면 꼭 알아야 할 기능들이다.

1. 분산원장의 기록(fact)은 계약상 용인되는 증거로 받아들여져야 하며 분쟁이 있을 경우를 대비하여 법적 구속력(legal enforceability)을 지녀야 한다.

2. 분산원장의 기록은 그 자체로서 권위성(authoritative)을 지녀야 하며, 원장에 기록된 정보가 다른 곳에 구비되어있는 기록의 복사본(shadow)일 수 없다. 즉 기록의 처리 (예. 금융거래의 결제)가 분산원장 위에서 직접 일어나야 한다.

3. 분산원장의 기록(예. 금융거래)은 완결성(final)과 비가역성(immutable)을 지녀야 한다. 오류가 있을 경우, 기록의 삭제 또는 변경이 불가능하기 때문에 신규거래를 발생시켜 수정해야 한다.

4. 원칙적으로 모든 참여기관은 원장에 직접적으로 연결해야 하고, 원장은 거래상대방과 체결한 계약을 기록하는 용도로 사용해야 한다. 어떠한 참여기관도 거래상대방에게 거래를 강요할 수 없다.

5. 금융거래의 상세 내용에 대한 열람권한은 그 거래에 직접적으로 참여한 기관이거나 거래를 열람할 이유가 있는 기관 (예. 규제/감독기구)에 한에 주어져야 한다.


기존 블록체인과 비교하여 코다의 아키텍처 구성이 어떤 점에서 다른지 알아보자.

정보 전파 (Data broadcasting)

기본적으로 블록체인은 모든 정보를 모든 참여자에게 전파한다. 정보가 복사(double spending)됐거나 위변조 및 삭제가 되면 안 되기 때문에 최대한 많은 컴퓨터의 합의(consensus)를 받기 위함이다. 즉 A가 B에게 돈을 지급하면, 그 거래의 정보를 전체 네트워크에 공개함으로써 거래를 검증한다. 비트코인/이더리움과 같은 공개형 블록체인은 거래를 검증하는 주체가 전 세계에 분포된 익명의 컴퓨터들이고, 제한형 블록체인은 거래 검증의 주체를 특정 네트워크 참여자로 제한한다.

정보를 관련 없는 참여자에게까지 전달하고 검증까지 받게 되면 확장성이 뒤떨어질 수밖에 없다. 다수의 합의를 도출해야 하는 구조이기 때문에 네트워크의 속도는 항상 하양 평준식이다. 즉 가장 느린 컴퓨터의 속도를 따라가야 한다. 초당 수천/수만 건이 일어나는 금융에는 적합하지 않다. 그 외에도 나와 관련 없는 불필요한 정보를 기록/검증/관리해야 하기 때문에 금융사간 이해관계에도 맞지 않는다.

코다는 정보의 전달을 그 정보와 관련이 있는 당사자에게만 전달한다. A와 B의 거래를 관련 없는 C와 D에게 전달하지 않을뿐더러, 거래가 유효한지 검증을 요청하지도 않는다.

1

교집합으로 보면 이해하기 쉽다. 위 그림은 “가, 나, 다”로 표현되는 개체와, 그 개체 간의 거래를 “A, B, C”로 표현하고 있다. 모든 거래를 모든 개체가 공유하는 블록체인 방식과 달리, 코다는 관련 있는 거래만 참여자에 한에서 공유한다.

합의 (consensus)

코다는 거래의 합의를 거래당사자간의 딜(deal) 단위에서 일으킨다. 앞서 언급했듯이, 블록체인 네트워크에선 모든 참여자(예. 비트코인의 채굴자)가 거래를 검증한다. 코다는 합의를 유효성(validity)과 유일성(uniqueness)으로 나눈다. 유효성이란 거래당사자 간의 거래내용을 만족하고 각각 서명하여 거래가 유효(valid)함을 확인하는 것이고, 유일성이란 그 거래가 두 번 쓰이지 않았는지(double spend)에 대한 검증을 의미한다. (*기존의 블록체인은 합의의 유효성과 유일성을 구분하지 않는다. 거래의 유일성을 곧 유효성이다.)

현실에서 금융거래의 유효성은 비즈니스단에서 이루어진다. 즉 금융거래에선 거래당사자 A와 B가 모두 동의한 거래여야만 체결될 수 있다. 하지만 기존의 블록체인에서는 과반수 이상이 합의를 도출하면 거래의 유효성이 인정된다. 다섯개의 금융사가 참여한 동일한 거래에서 두기관이 동의하지 않더라도 무조건 따라야 하는 강제성을 지닌다는 뜻이다. 이는 금융 비즈니스와는 맞지 않다.

2

위 그림에서 볼 수 있듯이, 코다는 거래의 유효성과 유일성을 분리한다. 거래의 유효성은 거래당사자 간 확인이고, 거래의 유일성은 노터리(Notary)라는 개념을 도입해 보장한다. 자산이 두 번 사용되지 않았다는 사실은 거래당사자간 보장할 수 있는 것이 아니기 때문에 노터리가 대신 검증한다. 노터리의 구성은 국가마다 다르겠지만, 결제원이나 중앙은행처럼 산업기구나 규제/감독기구가 단독적으로 될 수도 있고, 금융사들이 그룹 (pool)을 구성해 탈중앙화 된 형태로 직접 유일성을 검증할 수 있다. 금융사들이 직접 노터리 그룹을 구성할 경우, 과반수 선택에 따르는 PBFT나 RAFT기반의 합의 알고리즘을 선택할 수 있다. 코다는 다양한 합의 메커니즘을 지원할 예정이다.

프라이버시 (privacy)

기존의 블록체인은 앞서 얘기했듯이 정보를 모든 네트워크 참여자에게 전달된다. 제도권 블록체인을 개발하는 몇몇 기업들은 위의 정보들을 암호화(encryption)하여 전파하는 방식을 사용하지만, 이러한 방식에는 여러 문제점들이 있다.

1. 확장성(scalability)
2. 관련 없는 데이터를 저장/관리하는 문제
3. 복호화 가능성
4. 키 분실과 같은 보안 문제
5. 금융정보의 기밀성

3

위 그림처럼, 블록체인/분산원장에서 기밀성은 세 가지 영역으로 나눌 수 있다.

1. 계좌(고객정보) 프라이버시
2. 거래기록(역사) 프라이버시
3. 자산(잔고) 프라이버시

코다는 위 세 가지 프라이버시를 모두 보호한다. 현재 시스템과 마찬가지로 기밀성이 보장되는 정보들은 거래당사자 간 need-to-know 기반으로 전달된다. 이러한 정보의 프라이버시를 보호할 수 있는 이유는 합의과정에서 거래의 유효성과 유일성을 분리해놓았기 때문이다.

법적 구속력 (legal enforceability)

법적 구속력이란 거래 과정에서 문제가 발생했을 경우 법적으로 해소할 수 있고, 체결된 거래가 법적으로 용인될 수 있음을 뜻한다. 즉 블록체인에서 법적 구속력은 법률 계약(legal contract) 기반의 금융거래에 대한 이해, 체결, 실행을 컴퓨터가 대신할 경우(= 스마트 계약) 법적으로 인정해주느냐의 문제이다. 자연어 (human language)로 작성되는 계약서를 컴퓨터 언어로 바꾸는 것은 현재 기술로는 현실적이지 못하고, 설령 가능하다고 하더라도 법정에서 이를 인정하기 어렵다. 법은 계약의 참여자와 판단자가 공통의 언어를 사용해야 하기 때문이다.

4

따라서 R3는 기존 블록체인 개발자들이 주장하는 “코드가 곧 법이다. (Code is law)”라는 개념에 동의하지 않는다. 코다는 “코드 = 법”보다 “코드 + 법” 방식이다. 코다에서 금융계약은 법률언어(legal prose)를 컴퓨터 코드와 유기적으로 연결한다. 위 그림을 보면, 계약의 상태 (state of agreement)에는 두 개의 레퍼런스 (컴퓨터 코드와 법률문서)가 담겨있음을 알 수 있다. 법률문서는 계약으로서의 법적 구속력을, 컴퓨터 코드는 계약의 실행을 담당한다.

더 흥미로운 건 거래당사자간 금융계약을 상호적으로 단 한 번만 기록/보관하고, 계약의 상태(state of contract)가 변하는 과정(pt.1 참조)에서 계약의 체결과 실행이 자동으로 이루어진다. 기존처럼 계약을 맺고 대사(reconciliation)를 하거나, 계약의 상태가 변한 후에 다시 같은 과정을 거칠 필요가 없어진다.

5
Distributed ledgers: “Confirm-as-you-go” – Antony Lewis (bitsonblocks.net)

 


기존 블록체인과 비교점을 중점으로 코다를 설명해봤다. 다음 포스팅은 코다의 구성요소에 대한 글이다.

 

[블록체인에 대하여] 시리즈

– (12) R3의 분산원장 코다(Corda) 이해하기 pt.1
– (11) R3, 넌 도대체 누구냐?
– (10) IBM은 왜 블록체인을 연구할까?

88x31

 

[fbcomments url=”http://www.mobiinside.com/kr/2017/06/21/blockchain-part2/” width=”100%” count=”off” num=”5″ countmsg=”wonderful comments!”]