코다

코다(Corda)

코다(Corda)

R3(알쓰리)

코다(Corda)는 세계 최대의 블록체인 컨소시엄인 R3가 만든 분산원장 기술이다.

개요

코다는 핀테크 스타트업으로 80여 개 이상의 금융기업이 참여하는 글로벌 분산원장 컨소시엄의 운영주체인 R3의 분산원장 기술이다. 코다가 블록체인의 한 종류인지에 대한 여부는 끊이지 않고 있는데 코다는 블록체인이 아닌 분산원장 기술이다. 코다가 분산원장 기술인 이유는 블록체인이 R3에 많은 영향을 미쳤음에도 불구하고 코다 자체는 블록체인 개념과 상당한 차이가 있기 때문이다. 코다는 “기존의 블록체인이 금융권의 니즈를 충족시킬 수 없다”라는 판단에서 시작되었다. 코다는 애초에 기존의 블록체인 기술을 변경하는 수준이 아닌, 금융기관들의 요구를 충족하는 무엇을 만들기 위해 개발되었다. 그도 그럴 것이 블록체인 기술은 탈중앙화 방식의, 즉 금융기관 없이 자유롭고 평등한 참여자들에 의해 자율적으로 유지되고 운영되는 거래를 가능하게 하는 기술인데 금융기업들이 참여하여 스스로의 입지를 줄일 리 없다. 그래서 R3는 IBM에서 블록체인을 담당하던 리처드 겐달 브라운(Richard Gendal Brown)과 비트코인 코어 개발자 출신의 마이크 헌(Mike Hearn)을 영입하여 코다의 개발에 착수한다. 즉 코다는 블록체인 기술이 아닌, 분산원장 기술로서 기본적으로 금융산업에 최적화 된 기술이다.

비트코인, 이더리움, 코다의 비교

주의해야 할 점은 비트코인과 이더리움은 코다와 경쟁관계에 있거나 상충하는 개념이 아니라는 것이다. 비트코인, 이더리움, 코다 각자는 서로 다른 문제를 해결하기 위해 개발된 암호화폐 및 기술이다. 비트코인은 신뢰가 불가능한 익명 간의 가치이전이라는 역할을 수행하며 이더리움은 분산 프로그램이라는 역할을 훌륭히 이행하고 있다. 코다는 거래당사자 간의 합의를 통해서 계약 상태의 변화를 동일하게 기록 및 보관하는 분산 데이터베이스 기술이다. 이와 같이 코다는 블록체인 기술이 해결하고자 하는 문제와는 별개의 문제를 해결한다. 기존의 블록체인은 개인 또는 기관의 탈중개화(disintermediation) 혹은 탈중앙화(decentralization)를 통한 거래를 구현하고자 한다. 이와 다르게 코다는 데이터 보관 위치와는 관계없이 다수가 금융계약의 변화를 상호 간 컨트롤 하는 플랫폼을 구현하고자 한다. 오랫동안 유지되어 왔던 중개기관의 역할을 일방적으로 파괴하는 것이 아닌 역할의 변화를 통해 금융산업의 전반적인 효율성을 제고시키는 것이 더 현실적이라는 판단에서이다. 비트코인이나 이더리움과 같은 블록체인 기술이 파괴적 혁신으로 금융혁명을 꾀한다면, R3의 코다는 금융산업의 변화에 더욱 초점을 맞춘다.

많은 사람들이 냅스터(Napster)나 토렌트(Torrent)를 범용적으로 사용하고 있음에도 지적재산(IP)와 같은 규제로 인해 제도권 안으로 들어오지 못하고 있는 것처럼 비트코인과 이더리움도 암흑속의 금융으로 남을 가능성을 배재할 수는 없다. 급진적 혁명이냐 효율적 변화냐 꼭 어느 것이 무조건 옳다고 볼 수는 없지만 금융 역시 규제산업임을 간과해서는 안 된다. 그럼에도 여전히 블록체인 기술이 발전하면서 확장성, 프라이버시, 분산처리와 관련된 면이 지금보다 훨씬 개선된다면 규제산업, 즉 제도권 내에서도 받아들일 여지는 존재한다.

주요 인물

리처드 겐달 브라운 최고기술책임자

마이크 헌 수석개발자

제임스 칼라일 최고정보책임자

• 리처드 겐달 브라운(Richard G Brown) : R3의 기술총책임자이자 상무이사이다. 영국에 있는 케임브리지대학교(University of Cambridge)에서 수학 석사를 받았으며 컴퓨터공학 학위를 취득했다. R3는 수백 개의 은행, 기술회사, 규제기관, 무역협회 및 전문서비스 회사들로 구성된 컨소시엄이 지원하는 엔터프라이즈 소프트웨어 회사이다. R3에서 리처드 겐달 브라운과 그의 팀은 세계에서 가장 발전된 엔터프라이즈 블록체인 플랫폼인 코다를 구축한다. 또한 그는 영국 IBM의 은행 및 금융 시장 비즈니스를 위한 산업혁신 및 비즈니스 개발을 담당한 경영 설계자였다.

• 2000년 09월 ~ 2002년 04월 : IBM 소프트웨어 엔지니어
• 2002년 04월 ~ 2004년 01월 : IBM 개념증명 전달 컨설턴트
• 2004년 01월 ~ 2006년 12월 : IBM 선임 IT 전문가
• 2007년 01월 ~ 2011년 01월 : IBM 금융시장을 위한 통합 솔루션 설계자
• 2011년 01월 ~ 2013년 06월 : IBM 금융시장의 산업 설계자
• 2013년 07월 ~ 2015년 08월 : IBM 은행 및 금융시장의 경영 설계자
• 2015년 09월 ~ 현재 : R3 기술총책임자

• 마이크 헌(Mike Hearn) : R3의 수석 엔지니어이다. 그는 비트코인, 블록체인, 분산원장 시스템 관련 분야에서 5년 이상의 경력을 갖고 있으며 이 분야에 뛰어들기 전 구글에서 수석 소프트웨어 엔지니어로 8년을 근무했다. 마이크 헌은 세계 최초로 스마트 계약 기능을 포함하여 비트코인 플랫폼용 소프트웨어를 개발한 개발자 중 한 명이며 비트코인 지갑 소프트웨어를 개발하기도 했다.

• 2002년 09월 ~ 2002년 12월 : 핑아이덴티티(Ping Identity, Inc) 컨설턴트
• 2003년 02월 ~ 2006년 06월 : 코드위버(Codeweavers,Inc) 엔지니어
• 2006년 09월 ~ 2014년 01월 : 구글(Google) 선임 소프트웨어 엔지니어
• 2014년 04월 ~ 2015년 12월 : Vinumeris 최고경영자
• 2015년 11월 ~ 현재 : R3 CEV 수석 플랫폼 엔지니어

• 제임스 칼라일(James Carlyle) : R3의 최고정보책임자(CIO)로서 후보 아키텍처를 정의하고 개발을 위한 공동 연구소를 구축하는 업무를 맡고 있다. 그는 이전에 바클레이스 은행에서 수석 엔지니어로 근무하여 은행의 인터넷 채널과 달러 거래 플랫폼을 설계 및 제공했다. 바클레이스 은행에 근무하기 전에 제임스 칼라일은 두 개의 스타트업을 공동 설립했으며 모바일 데이터 검색과 디렉토리 기술에 대한 특허를 보유하고 있다. 그는 공인 엔지니어로 더럼 대학(Durham University College)에서 공학학위를 취득했다.

• 1988년 ~ 1994년 : 코마츠(Komatsu) 엔지니어
• 1994년 ~ 1994년 : 일본연구소(Japan Research Institute) 개발 관리자
• 1998년 ~ 2000년 : 포리프닷컴(Fourleaf.com) 최고 기술 책임자(CTO)
• 2000년 ~ 2002년 : 칼라바(Calaba) 공동 설립자 및 최고 운영 책임자
• 2002년 ~ 2004년 : 페이블플로우(FableFlow) 공동 설립자
• 2004년 ~ 2006년 : 스카이 위성방송(BSkyB PLC) 어플리케이션 설계자
• 2006년 ~ 2007년 : 바클레이스 은행(Barclays) 어플리케이션 설계자
• 2008년 ~ 2015년 : 바클레이스 은행(Barclays) 수석 엔지니어
• 2015년 ~ 2018년 : R3 수석 엔지니어, MD
• 2018년 ~ 현재 : 코다 네트워크 파운데이션(Corda Network Foundation) 이사회 의장
• 2018년 ~ 현재 : R3 프로덕션MD

등장배경

기업형 블록체인을 엔터프라이즈 블록체인이라고 하는데, 이를 통해 해결하려고 하는 문제는 퍼블릭 블록체인으로 해결되는 문제와 분명한 연관성은 있지만 매우 다르다. R3가 코다를 통해 결국 이루려고 하는 것은 “내가 보는 정보가 곧 네가 보는 정보임을 확실히 안다”는 것을 기술적으로 가능하게 하여 좀 더 효율적인 기업운영을 가능하게 하는 것이다. 즉, 한 기업이 거래하고 있는 파트너들과 완벽하게 동기화 된 정보를 갖고 있고, 이러한 사실을 인지함으로써 주어지는 새로운 기회를 포착하는 것이다. “내가 보는 정보가 곧 네가 보는 정보임을 확실히 안다”는 것은 물론 기존에도 가능했다. 하지만 “나”와 “너” 사이에는 항상 정보를 동기화해주는 중개자가 있어왔다. 중앙에서 관리감독 하는 기관 없이 참가자들이 자신의 컴퓨터만 보고 “내가 보는 것이 곧 네가 보는 것”이라는 것을 처음 알 수 있도록 한 것은 퍼블릭 블록체인의 근본적인 기술혁신 중 하나이다. 이것이 비트코인의 탄생에 있어 가장 획기적인 기술 중 하나라는 것은 누구도 부정할 수 없는 사실이며 기존의 비즈니스 프로세스에 존재했던 높은 비용, 복제, 낭비 및 오류 위험을 없앨 수 있는 열쇠였다. 물론 퍼블릭 블록체인에 대한 매우 긍정적인 전망이 다음 크립토키티(Cryptokitties)를 발명하여 수십억 달러를 버는 것보다는 훨씬 시시하겠지만 그렇다고 흥미롭지 않은 것 또한 아니다.

예를 들어 금리스왑(IRS)에 블록체인을 적용했다고 생각해보자. 만약 당사자의 기록이 거래상대방의 기록과 동일할 뿐만 아니라 모든 이벤트(변동금리 정산 등)가 사전에 합의된 담보약정(CSA)과 스왑 파생상품 계약(ISDA Agreement)에 따라 모든 참가자들에 의해 동일하게 수신되고 처리된다는 것을 확신할 수 있다면 금융 산업은 훨씬 더 큰 발전을 이룰 것이다. 또한 이러한 과정에서 발생하는 비용 절감 효과 또한 상당할 것이다. 현재 모든 은행의 시스템은 각자가 다른 방식으로, 다른 가정 하에 작동하고 서로 다른 버그를 가지고 있다. 당사자와 거래상대방이 가지고 있는 기록이 항상 동기화되어 있다는 것에 대한 확신을 가질 수 있다면 이를 통해 은행의 거래방식에도 커다란 진전이 생길 것이다. 금융을 참가자들 간의 계약으로 보면 금융 산업에서의 블록체인에 대한 기회는 분명해지며 이를 통해 계약을 기록하고 관리하며 자동화하는 것으로 많은 비용을 절감할 수 있어 결과적으로 새로운 비즈니스 기회를 창출할 수 있을 것이다.

특징

오픈소스

R3는 회원으로 등록된 사람만 공유하는, 이른바 프라이빗 블록체인을 처음으로 시도한 곳 중 하나이다. 현재 R3가 더 많은 사람을 포함하는 분산원장 기술을 향해 나아가고 있지만 그렇다고 해도 여전히 모두가 참여하는 퍼블릭 블록체인과는 다르다. 리처드 겐달 브라운의 표현을 빌리자면, R3는 “공개된 공유 네트워크이지만, 여전히 승인된 사람들만 볼 수 있는 보안이 뛰어난 프라이빗 플랫폼”이다. R3 코다 팀은 모든 참여자가 같은 사업 원리를 공유하지만 서로 다른 앱들이 통하거나 마찰을 빚을 가능성을 애초에 차단해버린 이더리움의 강단에 큰 영향을 받았다. 그러나 상대적으로 단순한 원리의 비트코인이라면 모를까 굵직한 금융기업은 이러한 퍼블릭 블록체인을 전 세계적인 규모의 비즈니스에 사용하기는 쉽지 않다. 이에 대한 리처드 겐달 브라운의 입장은 다음과 같다. “기업들이 운영하는 블록체인은 누구에게나 제한 없이 데이터를 공유하는 플랫폼의 영향을 받아서인지 몰라도 너무 많은 것을 공유하는 경향이 있다.” 이와 같은 이유로 코다는 참가자들끼리 공유하는 데이터를 최소화하기 위해 참가자들 사이에서 데이터의 일부만 보여주고도 진본임을 입증하는 방식을 도입했다. 그것이 금융 거래든, 예약에 쓰이는 확인증이든 코다에서는 데이터 전체를 먼저 확인할 수 없으며, 거래 사실의 일부만 보여주는 시스템을 통하여 확인하지 못한 나머지 정보도 사실임을 확인하고 거래를 진행할 수 있다.

강력한 보안

코다 네트워크 안에서 승인된 이들에게만 데이터를 공유할 때, 데이터가 필요해 인터넷을 통해 공유하려고 해도 당장 문제가 발생한다. 대부분의 회사는 “보안”을 최고의 목적으로 둔 자체 데이터센터를 만들고, 각종 어플리케이션과 보안을 위한 시스템을 겹겹이 쌓아 놓은 방화벽 안에 구축한 인프라 위에서 운영되고 있다. 합의를 통해 거래를 진행하기 위해서는 같이 공유해야 하는 바로 그 데이터가 지금 은행과 대기업 각자가 만들어놓은 철통같은 데이터센터 안에 고이 모셔져 있다. 결국 은행과 기업들이 서로 필요한 데이터를 공유하는 작업은 공공 인터넷상에서밖에 할 수 없다. 이때, 모두가 들여다 볼 수 있는 인터넷상에 비트코인이나 이더리움 노드 같은 기업 블록체인 노드를 올려놓고 데이터를 공유하면 보안에 있어 매우 문제가 생길 수도 있다. 우선 기업 자체의 데이터도 아닐뿐더러 해킹이라도 당하는 날에는 매우 위험한 상황에 놓일 수 있다. 그럼에도 불구하고 인터넷으로 데이터를 주고받는 것은 공격의 표적이 될 가능성이 매우 높다.

이러한 문제를 해결하기 위해 코다 노드가 선택한 방법은 은행, 제조업체, 항공사 등 거래 당사자의 시스템에서 가까운 곳, 즉 이러한 회사들이 운영하는 자체 서버나 소유하고 있는 클라우드 내부에서 코다 노드를 운영하는 것이다. 해당하는 서버와 클라우드 컴퓨터를 가장 잘 운영하는 것은 코다도, 더 큰 규모의 기업도 아닌 그것을 소유하고 있는 기업이다. 이러한 방법에도 거래상대방이 합의를 내리고 거래를 진행하기 위해 접속하여 확인해 볼 수 있는 데이터의 일부분은 공공 인터넷에 올려야 한다는 점은 변하지 않는다. 리처드 겐달 브라운의 표현을 빌리자면, “코다는 노드의 극히 일부분을 떼어내 전체 노드에서 흘러나와 비무장지대라고 부르는 곳에 떠 있게 한다.” 그는 부표(float)라고 불리는 떼어낸 노드 일부분이 정말 작고 단단하며 보안에 있어 매우 강력하다고 강조한다. 코다에서 거래에 필요한 노드는 이러한 방식을 통해 거래당사자 사이에서 공유된다. 기본적인 비즈니스는 해당하는 개관의 내부에서 진행되며 합의와 거래가 필요할 때는 데이터의 일부만을 안전하게 처리해 부표로 띄워 보내 상대방과 정보를 안전하게 공유하고 합의하여 거래를 진행한다.

구성

코다의 구조를 알기 위해서는 분산원장을 금융 산업에 적용하기 위한 필수요건을 먼저 알아야 하는데, 다음은 금융권 대상의 분산원장을 개발하기 위해 기반이 되어야 하는 기능이다.

• 분산원장의 기록은 계약상 용인되는 증거로 채택될 수 있어야 하며 분쟁이 있을 경우를 대비해 법적 구속력을 지녀야 한다.
• 분산원장의 기록은 그 자체로서 권위성이 있어야 하며, 원장에 기록된 정보는 다른 곳에 구비되어 있는 기록의 복사본일 수 없다. 즉 기록의 처리는 반드시 분산원장에서 직접 일어나야 한다.
• 분산원장의 기록은 완결성과 비가역성을 지녀야 한다. 만약 오류가 있을 경우 기록의 삭제 또는 변경이 불가능하기 때문에 신규거래를 발생시켜 수정해야 한다.
• 원칙적으로 모든 참여기관은 원장에 직접적으로 연결해야 하고 원장은 거래상대방과 체결한 계약을 기록하는 용도로 사용해야 한다. 어떠한 참여기관도 거래상대방에게 거래를 강요할 수 없다.
• 금융거래의 상세 내용에 대한 열람권은 그 거래에 직접적으로 참여한 기관이거나 거래를 열람할 이유가 있는 기관에 한해 주어져야 한다.

원장

기존의 블록체인은 모든 데이터를 거래에 참여하는 모든 참여자에게 전파하기 때문에 각 노드의 관점에서 원장은 객관적이기 때문에 내 원장에 기록된 데이터가 나와 관계가 있든 없든 객관적인 사실로서 받아들여진다. 반면 코다의 원장은 일부의 데이터를, 제한된 참여자에게 전파하기 때문에 기본적으로 각 노드의 관점에서 매우 주관적이다. 때문에 자신과 관련 있는 정보에 대해서만 보관한다. 코다의 원장은 크게 on-ledger와 off-ledger로 나뉘는데, 이는 말 그대로 데이터가 안과 밖, 양쪽에서 관리될 수 있음을 의미한다. 데이터가 원장의 안에 기록되어 있다고 해서 데이터가 누군가와 공유되고 있다는 것을 뜻하지는 않지만, 누군가와 공유되고 있는 데이터라면 반드시 on-ledger에 기록되어야 하며 마찬가지로 원장의 밖에 기록된 정보는 반드시 혼자만 관리되어야 한다. 즉, 코다의 원장 구조에서는 어느 곳에도 중앙 집중적인 원장이 존재하지 않고 각 네트워크 참여자는 팩트(fact)가 기록된 원장을 독립적으로 관리하며 거래에 관련이 있는 당사자 간의 정보는 항상 동일한 가운데 on-ledger에 기록된 데이터라고 하더라도 반드시 공유되어야 하는 것은 아니다.

상태

금융거래에 있어서 계약은 두 거래당사자의 관점에서 사실로 받아들여져야 하고 가장 최신 상태를 서로 보관해야 한다. 여기에서 사실이란 두 개체 간의 공통된 데이터를 의미하는데 그 예로 금융계약, 금융자산 등이 있다. 상태는 그 사실의 현재 상태, 즉 최신 버전을 의미한다. 상태는 특정 시간에 공유된 사실에 대한 데이터를 보관하는 객체로서 복잡하고 다양한 계약 또는 자산을 표현하는 데 사용된다. 현금, 어음, 채권 등의 자산이나 금리스왑, 신디케이트 등과 같은 금융상품 및 다자간 계약까지도 구현할 수 있다. 상태객체에는 다양한 속성이 포함될 수 있는데, 예를 들어 채권은 발행날짜, 상환날짜, 명목금액 등이 포함된다. 상태는 비가역성이라는 특징을 가지고 있기 때문에 특정 유형으로 작성되면 다른 유형으로의 변경이 불가능하다. 즉 채권 형태의 상태 객체가 생성되면 항상 채권의 형태이어야 한다.

하지만 계약과 자산의 상태는 항상 변화하기 때문에 관련된 상태의 업데이트 또는 진화는 가능하다. 특히 금융업계에서는 계약이 새로 생성되고 기존의 계약은 파기되는 일련의 과정들이 계속해서 반복되기 때문에 이 계약의 현 상황을 나타내는 상태라는 개념은 매우 중요하다. 하나의 상태는 특정 시점에서 트랜잭션의 참여자들끼리 공유된 정보를 나타내는데 이는 장부에 올라가므로 수정이 절대 불가능하다. 모든 상태는 임의의 정보를 포함할 수 있으며 주식 정보나 채권정보, KYC 데이터, 신원확인 정보 등 어떠한 종류의 정보도 반영할 수 있다. 주의해야 할 점은 하나의 정보를 담기로 정했으면 다른 정보를 담아 해당 상태를 변경할 수 없다는 것이다. 예를 들어, 여러 상태를 담은 하나의 그룹(pool)이 시큐리티 코인에 대한 소유권을 보여주는 상태들로 구성되어있다. 이 묶음(Vault)이 갑자기 KYC 데이터나 신원확인 정보를 담은 상태들의 묶음으로 바뀌는 것은 불가능하다.

• 상태의 변화 과정

앞서 말한 것과 같이 모든 상태는 수정되거나 삭제될 수 없기 때문에 하나의 상태 자체는 현실 세계의 변화를 직접적으로 반영할 수 없어 상태가 누적되는 과정을 통해 현실을 드러낸다. 만약 하나의 상태가 새롭게 반영되어야 할 때 이전 상태를 그대로 복사하여 새로운 상태를 생성하고 이전의 상태는 처리됨으로 표시된다. 대신 새로운 상태에는 이전의 상태에서 어떻게 변화되었는지에 대한 기록을 해야 하고 상태의 묶음(Vault)에서 맨 위에 보여지도록 해야 하며 이러한 상태를 최신의 상태라고 기록한다. 이러한 과정을 통해 상태의 모든 변화 과정을 장부에서 확인할 수 있게 된다. 따라서 장부상에 기록된 이전 상태를 하나씩 뜯어보면 최신 상태를 드러내는 상태를 검증할 수 있다.

• 상태의 기록 묶음

모든 네트워크의 노드는 각자의 상태를 기록하는 묶음(Vault)을 가지고 있어 묶음을 확인하여 최신 현황을 반영하는 상태가 어떠한 변화를 겪어왔는지에 대한 정보를 얻을 수 있다. 이 묶음은 금고 또는 볼트(Vault)라고 불리기도 한다. 이는 암호화폐를 지갑에 보관하는 것과 같이 코다 네트워크에서 발행되고 유통되는 다양한 금융계약 또는 금융자산들이 저장되고 관리되는 관계형 데이터베이스이다. 볼트는 상태 시퀀스의 헤드(최신 버전)를 추적하고 보관하며 거래 참여자 간의 상태 헤드는 항상 일치한다.

네트워크

코다 네트워크는 사전에 협의된 노드끼리의 통신망이다. 각각의 노드는 Java EVM 환경에서 구동되는 코다 서비스와 코댑(CorDapps)라고 불리는 코다의 자체적인 디앱을 구동할 수 있다. 노드 간의 통신은 직접 연결되며, 미들웨어의 메시지를 전달할 때 표준 프로토콜로 사용되는 AMQP(Advanced Message Queuing Protocol) 1.0을 활용한다. 이 과정에서 메시지를 TLS 암호화하여 전송하기 때문에 모든 메시지는 이해관계자끼리만 공유되며 네트워크 전체에 메시지를 전파하지 않는다. 각각의 네트워크는 네트워크 맵 서비스(Network Map Service)를 지원하는데, 이는 네트워크상에 있는 노드와 통신할 수 있도록 모든 노드에 IP 주소를 부여하는 서비스이다. 네트워크 맵 서비스는 일종의 전화번호부 역할을 수행한다고 생각하면 되는데, 노드의 신원을 보증하는 역할 역시 네트워크 맵 서비스가 도맡는다. 이 서비스에는 네트워크상의 모든 노드에 연락할 수 있는 정보가 담겨있어 메시지를 받는 노드가 오프라인 상태라면 대기하고 있다가 온라인이 되면 메시지가 전달된다. 따라서 모든 메시지는 수신자를 명시해야 하며 발신자는 수신자와 수신자가 보게 될 내용을 모두 컨트롤 할 수 있다.

• 문지기 : 코다 네트워크는 사설 네트워크의 특징을 가지고 있는데, 각각의 네트워크는 모두 문지기 역할을 하는 노드를 가지고 있다. 따라서 네트워크 내부의 노드가 지켜야 하는 규정을 강제하고 신규 네트워크 참여자의 신원을 확인하는 KYC(Know-your-customers) 과정을 거친다. 네트워크에 참여하기 위해서 모든 노드는 반드시 문지기 노드와 사전에 연락을 취하고 필요한 정보를 서로 공유해야 한다. 문지기 노드는 네트워크에 새로 참여하고자 하는 노드를 네트워크에 참여시킬 때 Trust Root CA 인증서를 발급하는데, 이는 네트워크 내부에서 다른 참여노드와 통신을 할 때 해당 노드의 신원을 인증하는 역할을 한다.

• 네트워크 서비스

• 검증인 역할 : 검증인 역할을 하는 노드 개수에는 제한이 없다. 검증인은 트랜잭션의 유일성을 최종적으로 확인하는 역할을 수행하며 트랜잭션의 유효성을 검증하는 역할도 한다. 검증인 노드는 특정한 하나의 노드와 함께 통신할 수 있으며 혹은 여러 개의 노드 묶음과도 함께 통신할 수 있다.

• 오라클 역할 : 오라클 역할을 하는 노드의 존재유무에 따른 문제는 없다. 실제 세계에서 일어난 현상을 제대로 반영하여 트랜잭션에 올렸다는 사실을 검증하는 역할을 수행하며 오라클 문제를 해결하기 위해 나타난 노드 역할이다.

신원인증

코다에 참여하는 모든 노드는 자신의 신원을 입증해야 한다. 네트워크상에서 자신의 신원을 인증한 노드는 자신이 참여하는 서비스나 기구의 법률적 권리와 그 책임을 모두 맡게 된다. 다음은 코다의 참여하는 모든 노드가 입증해야 할 두 가지 신원이다.

• 법률적 신원 : 법률적 신원은 실제로 자신이 누구인가에 대한 인증이다. KYC(Know-your-customers)와 동일하게 생각하면 된다. 노드는 자신의 실제 신원을 입증했기 때문에 이에 대한 합당한 역할과 책임이 생긴다. 예를 들어 A는 대한민국 서울 출신의 1995년생임을 네트워크에서 인증해야 한다. 이를 인증한 후 금융거래를 실제로 네트워크상에서 이행할 수 있게 된다.

• 서비스 신원 : 서비스 신원은 코다 서비스 내부에서 자신이 하는 역할에 대한 입증을 의미한다. 법률적 신원은 자신의 실제 신분을 인증하는 것이라면 서비스 신원은 자신이 특정한 단체나 기구에서 어떠한 역할을 맡고 있는지를 인증하고 확인받는 것이다. 예를 들어 A는 어느 기업의 회장직을 역임하고 있다. 해당 기업이 코다를 활용하고 싶다면 네트워크에 본인이 회장직에 있음을 인증해야 한다.

이 두 가지의 신원을 입증한 후 코다의 분산 네트워크에서 하나의 노드가 여러 개의 네트워크에 참여할 수 있게 된다. 코다에 참여하는 모든 노드는 자신이 인증한 신원이 Composite Keys에 올라가게 되며 이는 서비스에 실제로 참여하고 있는 노드의 서명값을 모아둔 것이다. Composite Keys에 올라가게 되었다고 해서 자신의 신원이 모든 노드에게 공개되었다는 것은 아니다. 네트워크상에서 자기 자신을 숨길 수도 있는데 이는 자신이 처음 네트워크에 가입했을 때 어떤 종류로 참여했느냐에 따라 달라진다. 자신의 네트워크 신원은 X.509 인증서에 담긴다. 신원을 모두 공개하는 노드는 법적인 효력이 있는 서비스를 활용할 수 있는 공개키를 부여받게 되어 해당 노드에게 발급되는 인증서는 누구나 열람할 수 있다. 즉, 해당 노드의 존재 사실을 모든 노드가 확인할 수 있게 되어 자신의 신원을 숨기고 비밀통신을 해야 하는 경우에는 적합하지 않다. 반면 비밀노드는 자신의 신원을 꼭 확인해야 하는 상대 노드에게만 자신의 신분을 밝힐 수 있다. 해당 노드의 공개키는 검증인 노드 같은 제3자에게는 보여질 수 있지만 노드의 이름과 X.509 인증서 제공은 철저하게 비공개된다. 설령 제3자가 암호화되지 않은 트랜잭션에 접근한다고 하더라도 비밀노드에 대한 추가적인 정보가 주어지지 않는다면 해당 트랜잭션의 수신자 혹은 발신자에 대한 정보를 알 수 없다.

• 인증서 : 노드는 반드시 공개키의 소유자가 누구인지 알 수 있어야 하며 이 과정에서 X.509 인증서가 사용된다. 첫 번째 노드가 공개키와 개인키를 생성하고 문지기 노드에게 서명을 요청하는 인증서를 네트워크상에 제출한다고 가정해보자. 문지기노드는 신원을 확인하는 절차를 거친 후 해당 노드의 인증서를 최종적으로 발급한다. 문지기 노드가 서명한 이 인증서는 해당 노드의 신원을 공식적으로 인증하는 문서가 된다. 문지기 노드가 서명한 CA(Node Certificate Authority)를 발급받은 노드는 해당 인증서를 바탕으로 TLS 인증서를 포함한 두 개의 문서를 더 만든다. 마지막으로 노드는 자신의 주소와 신원이 담긴 문서를 만들어 네트워크 맵 서비스에 등록한다.

트랜잭션

코다에서 트랜잭션이란 “원장을 업데이트 하는 상태의 원자적 변화”를 일컫는다. 이때 원자적이란 줄어들 수 없고, 쪼개질 수 없으며, 참이나 거짓 중 단 하나의 진리 값을 가지는 것을 뜻한다. 즉, 원자적인 트랜잭션은 1) 소비되었거나, 2) 소비되지 않았거나, 3) 아예 유효하지 않거나 로만 나뉘어야 하고 이는 상태가 모호하지 않고 결정적임을 의미한다. 코다는 비트코인처럼 UTXO(Unspent Transaction Output) 모델을 사용한다. 비트코인과 같이 코다의 원장은 소비되지 않은 상태의 집합이며, 트랜잭션의 아웃풋은 다음 트랜잭션의 인풋으로 쓰일 수 있다. 코다에서는 트랜잭션을 통해 세 가지 변화가 구현될 수 있다.

• 발행 : 발행이란 새로운 상태를 원장에 기록하는 것이다. 비트코인은 채굴자들이 채굴을 하여 코인을 발행하지만 코다는 내부적인 화폐가 존재하지 않기 때문에 참여기관이 직접 상태를 발행해야 한다. 발행의 대표적인 예는 중앙은행이 국채와 통화를 발행하는 것, 시중은행이 예금을 기반으로 신용을 창출하거나 새로운 계약을 만드는 것 등이 있다. 때문에 상태를 신규로 발행할 때만큼은 상태의 인풋 레퍼런스가 필요하다.

• 업데이트 : 업데이트는 발행된 상태가 다음 상태로 변화하는 것을 의미하는데 자산의 소유자가 바뀌는 것을 업데이트의 예로 들 수 있다. 상태가 업데이트 될 때에는 새로 만들어진 상태의 인풋이 기존의 아웃풋을 레퍼런스로 가지고 있어야 하며 이를 인풋 상태 레퍼런스(Input State References)라고 부른다. 인풋 상태 레퍼런스는 트랜잭션ID와 인덱스로 구성되어 있다. 트랜잭션ID는 상태를 생성한 트랜잭션의 해시값이고 인덱스는 아웃풋 값들의 리스트에서 상태의 포지션을 의미한다.

• 종료 : 종료는 상태의 시퀀스를 종료함으로써 원장에서 상태를 삭제하는 것을 의미하며 채권의 만기일에 현금으로 환매하는 경우가 그 예이다. 코다에서 트랜잭션은 이 발행, 업데이트, 종료의 세 가지 변화가 유기적으로 일어난다. 복잡한 금융거래에 맞춰 이 세 가지 변화는 합쳐질 수도 있고, 다양한 상태들이 한 개의 트랜잭션 안에 포함될 수 있으며, 현금과 같은 대체가능한 자산을 나눌 수도 있다.

원장을 업데이트하기 전에 트랜잭션은 거래 참여자가 모두 서명을 하는 커밋(commit) 과정을 거쳐야 한다. 전자서명은 아웃풋 상태의 비가역성을 강제하고 이미 커밋 된 트랜잭션의 아웃풋 상태를 변경하기 위한 시도는 트랜잭션에 추가된 전자서명을 확인하여 쉽게 감지될 수 있다. 새로운 트랜잭션은 이전 트랜잭션의 해시를 참조하여 비가역성을 지니는 체인과 같은 구조로 만들어진다. 이더리움 및 IBM의 하이퍼레저 패브릭(Hyperledger Fabric)과 코다의 차이점은 트랜잭션은 원장을 업데이트하는 행위를 위한 지시가 아니라는 점이다. 이더리움이나 하이퍼레저 패브릭에서 원장을 업데이트하기 위해서는 각 피어들이 원장의 새 상태를 계산하는 코드를 작성해야 한다. 각각의 피어는 원장의 새로운 상태를 계산하기 위해 지시를 내리고, 원장이 업데이트되기 전에 각 피어의 결과 값을 비교한다. 트랜잭션은 코다에서 검증을 필요로 하는 제안이다. 거래의 제안자가 먼저 원장의 새로운 상태를 제안하고, 제안된 원장의 상태가 관련 있는 피어에게 전달한다. 이후 피어가 계약코드를 통해 거래의 유효성을 검증한 후 서명하여 원장을 업데이트한다. 코다에서는 트랜잭션 제안자가 아웃풋 상태를 반영하는 업데이트된 원장을 계산하는데 이는 곧 아웃풋 상태들이 업데이트된 원장임을 의미한다.

계약

상태 객체는 크게 1) 특정 시간의 계약 및 자산의 상태를 반영하는 속성, 2) 트랜잭션 안의 상태를 소비하는 참여자, 3) 트랜잭션을 검증하는 함수를 규정하는 계약 레퍼런스의 세 가지 요소를 포함하고 있다. 코다에서 각각의 상태는 항상 계약을 레퍼런스로 가리켜야 한다. 계약 레퍼런스는 계약 코드와 법률 언어로 구성된다. 계약 코드는 트랜잭션을 검증하고 거래에 참여하는 모든 피어로부터 실행되어야 하는 코드로서 코다는 계약 코드가 항상 동일한 아웃풋의 출력을 보장한다. 계약 코드는 피어로부터 항상 같은 결과 값을 도출해야 하기 때문에 랜덤 수를 발생시키는 등의 비결정적인 코드는 실행될 수 없다. 따라서 변형된 버전의 JVM인 샌드박스 형태의 환경에서 결정성을 보장받은 후에야 코다의 계약 코드가 실행될 수 있다.

• 트랜잭션의 검증 : 트랜잭션은 모든 참여자의 서명이 있어야 검증할 수 있다. 하지만 특정한 트랜잭션이 필요한 모든 서명을 얻었다고 하더라도 계약의 내용상으로 참이어야 올바른 트랜잭션이라고 할 수 있다. 계약상의 검증은 다음과 같은 상황을 일컫는다.

• 모든 상태는 하나의 계약을 행하고 있어야 하며 계약의 내용과 합치해야 한다.
• 계약이 트랜잭션을 입력 값으로 받으면 트랜잭션 내부의 상태가 계약의 규칙과 합치하여 이루어졌는지 검증한다.
• 모든 트랜잭션은 계약의 입력 상태와 출력 상태가 모두 계약의 규칙과 내용상에 부합하다고 판단될 때에만 참이라고 인식된다.

JVM으로 계약이 써졌기 때문에 모든 계약은 JVM을 지원하는 언어로 써져야 한다. 때문에 트랜잭션과 상태의 입력값, 출력값, 명령값, 시간에 대한 정보 및 이와 관련된 부가 정보에 대한 모든 접근 권한을 가질 수 있게 된다. 상수와 변수의 지정, 함수의 호출에 대한 모든 실행을 할 수 있으며 유사한 정보를 하나로 묶어 그룹으로 만들 수도 있다. 계약의 규칙과 맞지 않는 트랜잭션은 장부에 업데이트 되지 않기 때문에 참여 노드끼리 계약상으로 올바르지 않은 트랜잭션에 서명하더라도 장부상에는 올라가지 않는다. 이러한 과정을 통해 계약의 강제성이 실현된다.

• 계약 샌드박스 : 모든 트랜잭션은 결정적 상태로 확증되어야 하며 모든 계약은 하나의 트랜잭션만을 승인 및 거절할 수 있다. 모든 트랜잭션은 해당 트랜잭션이 언제 실행되었는지에 대한 정보와 함께 계약이 실행될 때 담겨야 하는 정보의 양에 대한 서술이 반드시 포함되어야 한다. 이는 네트워크상의 모든 노드가 장부의 업데이트를 승인하기 위한 필요조건이다. 결정적 샌드박스는 계약의 트랜잭션 승인 여부를 판단하기 위해 활용된다. 이 샌드박스는 비결정적 요소가 될 수 있는 라이브러리를 계약에 들어오지 못하도록 막는데 궁극적으로 트랜잭션을 검증할 때 필요한 정보만 계약에 담아 실행될 수 있도록 한다.

• 계약의 한계 : 계약 자체는 현실 세계와 접점을 가지기 쉽지 않아 계약은 내부의 정보만을 바탕으로 트랜잭션을 검증한다. 즉, 계약은 실제 외부 세계에서 합의된 사항에 대해서는 사전 계약에 조건으로 담기지 않은 이상 확인할 수 없다. 따라서 트랜잭션에 참가하는 노드들은 트랜잭션에 합의한 내용이 제대로 담겼는지를 서로 확인하고 서명을 해야 한다.

• 오라클문제와 법률문제 : 오라클문제는 트랜잭션에 참가하는 당사자들끼리 결정되어야 하는 문제인데, 트랜잭션이 실제 상황을 반영하는 데에는 여러 가지 변수가 생길 가능성이 있다. 예를 들어 해당 트랜잭션이 환율을 반영해야 하는 해외송금이면 오라클이슈를 해결해줄 수 있는 노드가 반드시 존재해야 한다. 혹은 법률적 문제를 담은 계약의 경우 법률적 문서를 계약상에 작성한 다음 법률적 판단을 해줄 수 있는 상관없는 노드가 지정될 수도 있다.

합의

하나의 트랜잭션이 장부에 반영되기 위해서는 유일성과 유효성이 검증되어야 한다. 유효성 검증은 트랜잭션에 참여한 노트끼리 검증을 한 후 서로 서명을 하는 것이며 유일성 검증은 검증인 노드에 의하여 검증된다.

• 유효성 합의

유효성 합의란 계약의 입력상태와 출력상태에 의하여 트랜잭션이 승인되었는지를 판단하고, 필요한 모든 참여자의 서명을 받았는지 확인하는 과정을 뜻한다. 즉, 거래 당사자들끼리 거래내용에 만족하여 올바르게 거래가 처리되었음을 확인하고 각각의 서명을 통해 해당 트랜잭션이 유용하다는 것을 증명하는 것이다. 이 과정에서는 입력 트랜잭션 값을 생성시키도록 한 이전 트랜잭션의 모든 기록을 다 검사해야 하는데, 이를 체인 위를 걷는다(Walking the chain)라고 표현한다. 예를 들어 장기국채에 대한 트랜잭션을 한 노드가 제안했다. 이때 채권이 다른 사람들에게 거래되었을 때 해당 거래가 올바르게 성사되었을 경우에만 채권의 거래가 유효하다고 볼 수 있다.

이를 확인하기 위해서는 트랜잭션의 과거 기록을 모두 확인해야 한다. 트랜잭션 하나를 검증할 때 트랜잭션을 검증해야 하는 노드가 검증해야 하는 모든 기록을 보유하고 있지 않는 경우가 생길 수도 있다. 이 때, 해당 노드는 트랜잭션을 체인에 올리고자 하는 사람에게 자신이 보보유하고 있지 않는 트랜잭션의 기록을 요구한다. 트랜잭션을 체인에 올리기 위해 제안한 사람은 해당 트랜잭션을 과거에 검증할 때 트랜잭션의 과거 기록을 확인했기 때문에 해당 노드는 트랜잭션의 전체 기록을 가지고 있다.

• 유일성 컨센서스

예를 들어, A는 시중은행에 1백만 달러의 예금을 들고 있으며 A는 두 개의 트랜잭션을 만들고자 한다.

1. 1백만 달러를 B에게 주고 80유로를 받는 경우
2. 1백만 달러를 C에게 주고 90파운드를 받는 경우

A는 자신의 1백만 달러를 두 번 사용할 수 있으며 유로와 파운드를 동시에 받았다. 따라서 위의 두 가지 트랜잭션에 대해 모든 참여자들이 합의했다고 하더라도 이중지불 문제가 발생할 수 있으므로 트랜잭션이 반드시 올바르다고 말할 수 없다. 이러한 상황을 예방하기 위해서 해당 트랜잭션은 오로지 한 번만 트랜잭션이 일어났다는 것을 증명하는 유일성을 반드시 보여주어야 한다. 이때 자신이 거래를 두 번이나 발생시키지 않았다는 사실은 자신이 아닌 대신 검증인 노드가 증명하게 된다.

• 합의 알고리즘

코다 네트워크는 필요에 따라 원하는 합의 방식을 채택하는데, 이는 만약 검증인 노드 간에 합의를 이루었을 때 기존의 다른 블록체인에서 사용되고 있는 알고리즘을 활용할 수 있다는 뜻이다. 검증인 노드는 하나의 네트워크 노드일 수도 있고 여러 노드의 묶음일 수도 있다. 혹은 서로 믿지 못하는 배반의 노드 묶음이어도 괜찮다. 검증인 노드가 여러 노드의 묶음인 경우 노드들의 투표에 의해 거래를 보증하는 알고리즘을 사용할 수도 있다. 예를 들어 PBFT나 RAFT를 직접 차용하여 금융사들이 검증인 그룹을 결성하는 경우가 있다. 이 때 과반수에 이르는 동의가 있을 경우 해당 트랜잭션을 유효한 거래로 처리할 수 있다.

노드

검증인 노드는 유일성을 검증해주는 노드로 주어진 트랜잭션에 대하여 다른 트랜잭션이 이루어지지 않았다는 사실을 보증하는 역할을 한다. 즉 다른 트랜잭션에서 특정 트랜잭션의 입력상태가 아직 소비되지 않았다는 것을 검증하는데 어떠한 트랜잭션을 검증해달라는 요청을 받은 검증인 노드는 두 가지 역할을 수행한다. 첫 번째, 만약 다른 트랜잭션이 요청을 받은 트랜잭션의 입력 상태를 소비하지 않은 경우 트랜잭션에서 소비한다. 두 번째, 만약 이중지불을 하려는 시도가 감지된 경우 트랜잭션을 파기한다. 이러한 과정을 통해 검증인 노드는 시스템 전반의 완결성을 보장하며 검증인의 서명이 포함되기 전까지 트랜잭션은 유효하다고 볼 수 없다. 만약 충돌되는 두 개의 트랜잭션이 동시에 존재할 경우 검증인 노드가 어느 하나의 트랜잭션이 유효하다는 평가를 내리기 전까지 해당 트랜잭션들은 승인되지 않는다. 반대로 검증인 노드의 서명이 포함된 경우 해당 트랜잭션의 입력 값이 이전 트랜잭션에 의해 소비되지 않았다는 것 또한 증명할 수 있다. 따라서 검증인 제도는 시스템 전체의 완결성을 보장해주고 모든 상태는 검증인이 있어야 하며 검증인은 자신이 맡은 트랜잭션의 검증인인 경우에만 해당 트랜잭션을 검증하는 역할을 하게 된다.

• 검증의 생략과 수행 : 검증인 노드는 트랜잭션을 검증하기 전에 반드시 자신이 해당 트랜잭션을 검증할 것인지를 결정해야 하는데, 경우에 따라서 검증인 노드는 트랜잭션의 검증을 생략할 수도 있다. 트랜잭션을 검증하기로 한 경우에는 해당 트랜잭션의 모든 기록을 하나씩 유효한지 확인해야 하는데 이 때 검증인 노드는 다음과 같은 사항을 고려해야 한다.

• 트랜잭션의 검증을 생략한 경우 : 네트워크는 디도스 공격을 받을 가능성이 있다. 악의적인 노드가 고의로 유효하지 않은 트랜잭션을 대량으로 생산하여 검증인 노드에게 보내면 소비되지 않은 상태가 소비되었다고 처리될 가능성이 존재한다. 이러한 경우 트랜잭션에 참여한 모든 노드의 신원을 저장한 후 추후에 디도스 공격 등의 문제가 발생할 경우 검증인 노드는 책임을 묻게 된다.
• 트랜잭션을 검증한 경우 : 검증인 노드는 반드시 트랜잭션 전체의 기록을 검토하고 관련된 사항을 모두 꼼꼼하게 검증해야 한다. 이는 검증인 노드가 일부 기밀 정보를 유출할 수 있는 가능성을 갖게 된다는 것을 의미하는데, 이러한 경우 보증이 노드에게 새로운 공개키를 부여함으로써 검증인 노드가 거래인의 정보를 확인할 수 있는 범위를 제한할 수 있다.

• 여러 검증인과 그에 따른 장점 : 각각의 코다 네트워크는 서로 다른 검증인을 가질 수 있으며 각자가 원하는 방식의 합의 알고리즘을 채택할 수 있다. 이러한 방식은 몇몇 장점을 가지고 있다.

1. 프라이버시 보호 : 트랜잭션 전체를 검증하거나 검증하는 노드, 검증을 하지 않는 노드, 두 검증인 노드 모두를 같은 네트워크에서 보유함으로써 서로 다른 합의 알고리즘을 채택할 수 있도록 이끌 수 있다. 이러한 과정을 통해 특정 트랜잭션이 원하는 검증인과 합의 알고리즘을 적용하도록 할 수 있다. 이는 기밀을 지켜야 할 필요성이 있는 거래에는 그럴 필요가 없는 거래와는 다른 검증인과 합의 알고리즘을 채택할 수 있다는 수 있다는 의미이다.
2. 속도의 제고 : 하나의 트랜잭션을 다양한 검증인 노드에게 보내 플랫폼 전체의 트랜잭션 속도를 제고할 수 있다.
3. 낮은 대기시간 : 물리적으로 가까운 노드를 검증인으로 지정함으로써 대기시간을 현실적으로 낮출 수 있다.

• 검증인의 교체 : 요청받은 트랜잭션의 입력상태를 보증할 수 있도록 검증인 노드는 사전에 지정되어 있어야 한다. 하지만 경우에 따라서 특정 상태의 지정된 검증인 노드를 교체해야 할 상황이 생길 수도 있다. 예를 들어 만약 하나의 특정 트랜잭션이 다양한 상태에 의해서 이미 소비되어 서로 다른 검증인이 이미 지정되어 있는 경우가 발생할 수 있다. 또한 트랜잭션을 보증해달라고 요청하는 노드가 프라이버시 문제나 효율성 문제로 인해 다른 검증인 노드가 승인해달라고 특별하게 요청하는 경우가 있다. 이러한 검증인 노드의 전환 요청은 특별히 생성되는 트랜잭션에 의해 처리될 수 있다.

법률언어

법률언어는 계약코드와 함께 계약 레퍼런스를 구성하는 아주 중요한 요소이다. 법률언어는 상태객체에 포함되어야 하는데, 그 이유는 거래 과정에서 문제가 생겼을 때 법적으로 이를 해결하고 체결된 거래가 법적으로 용인되어야 하기 때문이다. 컴퓨터에 의해 실행된 계약 또한 법적 구속력을 지녀야 한다. 코다는 실제 법률계약서와 계약의 변수, 예를 들어 발행자, 이자, 금액, 기간 등 특정 계약에 맞는 변수값에서 도출된 해시값을 계약 레퍼런스에 입력한다. 즉 계약코드 단독으로는 충분하지 못한 상태를 계약서와 변수값의 해시 레퍼런스로서 입력하여 법적 유효성을 보장하는 것이다.

활용사례

엑스칼리버

코다의 엑스칼리버 프로젝트

프로젝트 엑스칼리버는 2016년 05월에 개발된 스마트 계약 템플릿이다. 코다는 금융계약을 기록하고 관리하며 자동화하기 위해 처음 제작되었는데, 초기 개발자들은 설계를 위한 지침을 세우기 위하여 현금, 회사채, 신용 디폴트 스왑 등을 활용했다. 하지만 최초 실제 구현은 이들이 아닌 자산이었는데 그게 바로 금리스왑(IRS)이었다. 금리스왑이 코다에 적합하다고 검증하게 된 것은 코다가 올바른 프라이빗 블록체인을 디자인 했다는 것을 확인시켜주는 계기였다. 프로젝트 엑스칼리버는 바클레이스(Barclays) 투자부문 최고기술책임자 리 브라인(Lee Braine)의 비디오 프레젠테이션에도 잘 설명되어 있다. 코다는 계약을 위한 거래를 추적하고 급리스왑 계약에 관련된 당사자 간의 거래 출처를 확인할 수 있도록 구현했다. 특히 실시간 협상을 수행하고 플랫폼 간에 개인적으로 명령을 공유하는 기능은 당시 다양한 프로젝트에 많은 영향을 주었다.

코다는 쌍방 간의 계약 확정을 기반으로 원장에 기록하는 과정을 통해 원자적 거래를 가능하게 한다. 코다 노드는 플로우 프레임워크(Flow Framework)라고 하는 포인트-투-포인트(point-to-point) 합의 방식을 통해 동일한 정보를 각자의 원장에 저장하게 된다. 코댑(CorDapp) 개발자는 플로우 프레임워크를 이용해서 유동적인 방식으로 참가자들의 트랜잭션에 대한 서명을 가능하게 한다. 프로젝트 엑스칼리버가 기업에게 주는 이점은 바로 부분결제에서 전체결제까지 이르기까지 모든 과정이 거래체인에 기록된다는 점이다. 이 사례의 스마트 계약 템플릿은ISDA의 매개변수를 작성하고 이를 DLT에 반영하는 기능을 보여주었다.

코다의 베가 프로젝트

베가

프로젝트 베가는 공유된 표준 초기 마진 모델(Standard Initial Margin Model, SIMM)을 계산하는 프로젝트이다. 코다의 아키텍처는 이더리움과 달리 전통적인 UTXO 모델 기반의 스마트 계약이며, 인스트럭션의 실행에 의존하지 않는다. 스마트 계약 코드는 베리파이(verify) 함수를 통해 입력상태(Input State)를 출력상태(Output State)로 정확하게 변환하기 위해 통한 거래의 유효성 검증과정을 거치게 된다.

표준 초기 마진 모델 프로젝트의 특정 사용 사례는 담보약정(CSA)에 대한 초기 담보 계산 규칙을 따른다. 여기서 오라클 노드는 거래의 당사자들이 공통된 기준 정보를 활용할 수 있도록 디자인 되었으며 오픈 감마(Open Gamma : 회사이름)의 결정적 Java 라이브러리를 사용했다. 결과적으로 오라클 노드를 통해서 여러 가지 상태값을 받아 필요한 담보 금액을 계산하고, 아무런 대사과정 없이 거래 당사자들에게 전이된 값을 보낼 수 있었다. 이 오라클 디자인 패턴은 결정적 계산에 종종 사용되었지만 시장 데이터를 확인하는 데도 사용할 수 있다.

비교

블록체인

정보전파

기본적으로 블록체인은 정보의 위변조 및 삭제가 불가능하기 때문에 최대한 많은 참여자의 합의를 받기 위해 모든 정보를 거래에 참여하고 있는 모든 참여자에게 공유한다. 간단한 예를 들어, A가 B에게 돈을 지급했을 경우 그 거래의 정보를 전체 네트워크에 공개함으로써 거래를 검증하는 것이다. 비트코인 및 이더리움과 같은 퍼블릭 블록체인은 거래를 검증하는 주체는 전 세계에 분포된 익명의 컴퓨터인 반면에 프라이빗 블록체인은 거래 검증의 주체를 특정한 네트워크의 참여자로 제한한다. 블록체인 기술과 같이 정보를 연관성이 없는 참여자에게까지 전달하고 그들에게 검증까지 받게 되면 확장성이 떨어지는 것은 너무나도 당연한 결과이다. 다수의 합의를 도출해야 하는 구조이기 때문에 블록체인 네트워크의 속도는 항상 하향평준화, 즉 가장 느린 컴퓨터의 속도에 맞춰지게 된다. 따라서 초당 수천, 수만 건이 일어나는 금융 산업에서 블록체인은 적합하지 않다. 그 외에도 거래당사자와 관련이 없는 불필요한 정보를 기록하고 검증하며 관리해야 하기 때문에 업무가 많고 보안이 중요한 금융사 간 이해관계에도 블록체인 기술은 적합하지 않다. 블록체인과 다르게 코다는 해당 정보와 관련이 있는 당사자들에게만 정보를 전달한다. A와 B의 거래를 관련 없는 C와 D에게 공유하지 않으며 해당 거래가 유효한지에 대한 검증을 요청하지도 않는다. 모든 거래를 모든 개체가 공유하는 블록체인 방식과 다르게 코다는 관련이 있는 거래만 참여자에 한해서 공유한다.

합의

코다는 거래의 합의를 거래당사자 간의 딜(deal) 단위에서 일으킨다. 앞서 언급한 것과 같이 블록체인 네트워크에서는 모든 참여자가 거래를 검증하는 반면에 코다는 합의를 유효성과 유일성으로 나눈다. 여기서 유효성이란 거래당사자 간의 거래내용을 만족하고 각각 서명하여 거래가 유효함을 확인하는 것이고, 유일성이란 그 거래가 두 번 쓰이지 않았는지에 대한 검증을 의미한다. 기존 블록체인은 합의의 유효성과 유일성을 구분하지 않아 거래의 유일성이 곧 유효성이다. 현실에서 금융거래의 유효성은 비즈니스적인 측면에서 이루어진다. 즉 금융거래에서는 거래당사자 A와 B가 모두 동의한 거래여야만 체결될 수 있다. 하지만 기존의 블록체인에서는 과반수이상의 합의를 도출하면 거래의 유효성이 인정되어 거래가 체결된다. 이를 금융시장에 대입해보면, 다섯 개의 은행이 참여한 동일한 거래에서 두 은행이 동의하지 않더라도 과반수에 의한 합의를 무조건 따라야 하는 강제성을 지닌다는 뜻이다. 이는 금융 비즈니스의 성격과는 매우 거리가 멀다. 코다는 거래의 유효성과 유일성을 분리한다. 거래의 유효성은 거래당사자 간의 합의이고 거래의 유일성은 노터리(Notary)라는 개념을 도입하여 보장한다. 거래당사자 간 거래가 두 번 사용되지 않았다는 사실은 보장할 수 있지 않기 때문에 노터리가 대신 검증하는 것이다. 노터리는 국가마다 다르지만 결제원이나 중앙은행과 같은 산업기구나 규제감독기구가 단독적으로 될 수도 있고, 금융기관들이 그룹(pool)을 구성하여 탈중앙화 된 형태로 직접 유일성을 검증할 수도 있다. 만약 금융기관들이 그룹을 구성하는 후자의 경우, 과반수의 선택에 따르는 프랙티컬 비잔틴 장애 허용(PBFT)이나 래프트(RAFT) 기반의 합의 알고리즘을 선택할 수 있으며, 코다는 이 밖에도 다양한 합의 알고리즘을 지원할 예정이다.

프라이버시

기존의 블록체인은 앞서 얘기한 것과 같이 거래를 거래당사자뿐만 아니라 모든 네트워크 참여자에게 공유한다. 제도권 블록체인을 개발하는 몇몇 기업들은 이러한 정보들을 암호화하여 공유하는 방식을 사용하지만 이러한 방식에도 여러 문제점들이 있다. 확장성, 금융정보의 기밀성, 키 분실과 같은 보안 문제가 발생할 수 있으며 암호화 된 정보들을 복호화 할 가능성도 배제할 수 없다. 또한 관련 없는 데이터를 저장 및 관리하는 문제 또한 발생할 수 있다. 한편 블록체인 및 분산원장에서 기밀성은 1) 계좌(고객정보) 프라이버시, 2) 거래기록(역사) 프라이버시, 3) 잔고(자산) 프라이버시의 세 가지 영역으로 나눌 수 있다. 코다는 이 세 가지 프라이버시를 모두 보호한다. 현재 시스템과 마찬가지로 기밀성이 보장되는 정보들은 거래당사자 간 need-to-know 기반으로 전달된다. 이러한 정보의 프라이버시를 보호할 수 있는 이유는 합의 과정에서 거래의 유효성과 유일성을 분리해놓았기 때문이다.

법적 구속력

법적 구속력이란 체결된 거래가 법적으로 용인될 수 있고 이 거래 과정에서 문제가 발생했을 경우 법적으로 해소할 수 있음을 뜻한다. 블록체인에서의 법적 구속력은 법률 계약 기반의 금융거래에 대한 이해와 체결, 실행을 스마트 계약으로 대신할 경우를 법적으로 인정하느냐의 문제이다. 자연어로 작성되는 계약서를 컴퓨터 언어로 바꾸는 것이 현재 기술로 완벽하게 구현하지 못했을 뿐더러 설령 이를 완벽하게 구현했다고 하더라도 법정이서 인정하기가 어렵다는 문제가 있다. 법은 계약의 참여자와 판단하는 사람이 공통의 언어를 사용해야 하기 때문이다. 따라서 R3는 블록체인의 개발자들이 주장하는 “코드가 곧 법이다(Code is law)”라는 개념에 동의하지 않는다. 코다는 ‘코드=법’보다 ‘코드+법’이라는 개념 하에 개발된다. 코다에서 금융계약은 법률언어를 컴퓨터 코드와 유기적으로 연결하여 계약의 상태에 두 개의 레퍼런스(컴퓨터 코드와 법률문서)를 담는다. 법률문서는 계약으로서의 법적 구속력을 담당하며 컴퓨터 코드는 계약의 실행을 담당한다. 여기에서 더욱 흥미로운 점은 거래당사자 간 금융계약을 상호적으로 단 한 번만 기록 및 보관하고, 계약의 상태가 변화는 과정에서 계약의 체결과 실행이 자동으로 이루어진다는 것이다. 기존처럼 계약을 맺고 대사를 하거나 계약의 상태가 변한 후에 또 다시 같은 과정을 거칠 필요가 없어진다.

하이퍼레저 패브릭

하이퍼레저 패브릭(Hyperledger Fabric)

R3 코다와 함께 가장 많은 관심을 받는 블록체인 프로젝트인 하이퍼레저 패브릭은 리눅스재단에서 주도하는 블록체인 프로젝트인 하이퍼레저 소속 프로젝트로, 금융권뿐만 아니라 범용 블록체인을 표방하고 있는 프로젝트이다. 하이퍼레저 패브릭은 범용 블록체인을 표방하고 있지만, 이는 금융권을 포함하고 있지 않는다는 의미는 아니며 금융권의 요구사항을 대부분 만족하고 있다. 코다는 하이퍼레저 패브릭보다는 더 금융업에 초점이 맞춰진 분산원장 플랫폼이기 때문에 금융권의 요구사항을 만족하고 있다. 다음은 각각의 이슈에 대한 코다와 하이퍼레저 패브릭을 비교한 것이다.

• 프라이빗 채널 : 코다와 하이퍼레저 패브릭은 특이한 구조를 통해 프라이빗 채널을 해결한다. 바로 이해관계가 있는 노드만 합의하는 방식인데, 패브릭의 경우 이해관계가 있는 노드로만 채널을 구성하여 다른 채널의 노드는 해당 내용을 알 수 없다. 반면 코다의 경우 애초에 스마트 계약을 실행할 때 이해관계자끼리만 내용을 공유하여 문제를 해결한다.

• 노드별 권한 : 노드별로 다른 권한을 주는 이슈와 관련하여 하이퍼레저 패브릭은 COP이라 불리는 권한관리 모듈을 이용하여 내용 보관 노드, 순서 검증 노드, 트랜잭션 생성 노드, 내용 검사 노드 등으로 권한을 나누어 처리한다. 이러한 권한은 채널마다 상이하다. 반면 코다의 경우 각 스마트 계약에 관계된 노드들의 역할과 권한이 확실히 명시되어 있는데, 만약 거래에 판매자, 구매자, 감독기관이 필요하다면 코다는 스마트 계약을 실행하여 이 이해관계자들이 스마트 계약을 실행하는 방식이다.

• 커스터마이징 : 하이퍼레저 패브릭의 경우 분산합의 알고리즘 변경, 체인코드 변경 등은 가능하다. 코다의 경우 엔진 자체를 변경하는 것은 어렵다. 다만 스마트 계약 변경과 각 스마트 계약의 합의 알고리즘은 커스터마이징이 가능하다. 두 프로젝트 다 엔진 자체의 커스터마이징은 불가능하지만 핵심 기능인 계약과 합의 알고리즘을 커스터마이징 할 수 있다는 공통점을 가지고 있다.

참고자료

• 코다 공식 홈페이지 - https://www.corda.net/
• 백종찬, 〈R3의 분산원장 코다(Corda) 이해하기 pt.1〉, 《브런치》, 2017-04-17
• 백종찬, 〈R3의 분산원장 코다(Corda) 이해하기 pt.2〉, 《브런치》, 2017-04-13
• 백종찬, 〈R3의 분산원장 코다(Corda) 이해하기 pt.3〉, 《브런치》, 2017-04-27
• Jin Hyung Park, 〈R3 Corda의 주요 컨셉 이해하기 — 1부〉, 《미디엄》, 2018-10-27
• 블록체인 코다(Corda), 〈우리는 블록체인 코다(Corda)로 어떤 문제를 해결하고자 하는가?〉, 《미디엄》, 2018-07-01
• 야옹메롱, 〈(블록체인) 블록체인에 대한 연구, R3와 코다〉, 《네이버 블로그》, 2017-12-12
• Ian Allison, 〈금융을 넘어 글로벌 블록체인의 표준을 꿈꾸는 R3〉, 《코인데스크코리아》, 2018-04-18
• 가빈아빠, 〈(블록체인 플랫폼) R3의 분산원장 코다(Corda) 이해하기 pt.1〉, 《네이버 블로그》, 2017-06-26
• Skkrypto, 〈#Hyperledger#1〉, 《브런치》, 2018-11-23
• 백종찬, 〈R3, 넌 도대체 누구냐!〉, 《브런치》, 2016-12-03
• 야옹메롱, 〈( 금융과 블록체인 ) 활용과 규제 어떻게 해야할까?〉, 《네이버 블로그》, 2018-12-13

같이 보기

• R3
• 하이퍼레저
• 하이퍼레저 패브릭
• 리처드 겐달 브라운

이 코다 문서는 블록체인 플랫폼에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.

블록체인 : 블록체인 기술, 합의 알고리즘, 암호 알고리즘, 알고리즘, 블록체인 플랫폼 □■⊕, 블록체인 솔루션, 블록체인 서비스 프라이빗 블록체인 플랫폼 넥스레저 • 딜리버 • 레지스 엔터프라이즈 • 루니버스 • 리플 • 멀티체인 • 모나체인 • 바이두 블록체인 엔진(BBE) • 뱅크사인 • 블루브릭 • 애니블록 • 에이치체인 • 인솔라 • 지브릭 • 케이티 바스(KT BaaS) • 코다 • 코인스택 • 쿼럼 플랫폼 • 프롭테크 플랫폼 • 하이퍼레저 • 하이퍼레저 버로우 • 하이퍼레저 소투스 • 하이퍼레저 이로하 • 하이퍼레저 인디 • 하이퍼레저 패브릭 퍼블릭 블록체인 플랫폼 바이낸스체인 • 보스아고라 • 스텔라루멘 • 시그마체인 • 심버스 • 아이콘 • 야오네트워크 • 오투오체인 • 웨이브즈 • 이더리움 • 이오스 • 큐텀 • 클레이튼 • 테조스 • 티티씨 • 파라메타 프레임워크 • 하이콘 하이브리드 블록체인 플랫폼 레지스 • 카데나 NFT 플랫폼 그래그래 위키 : 자동차, 교통, 지역, 산업, 기업, 단체, 업무, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반