어쩌다, 블로그

R3는 금융 서비스를 위해 설계된 엔터프라이즈 블록체인 플랫폼인 corda를 개발하고 서비스하는 소프트웨어 회사다. R3는 2014년 소규모의 가족 회사로 출발했는데 R3중 R은 CEO인 David Rutter의 성을 뜻하고, 3은 공동 설립자의 수를 뜻한다.

R3는 2014년 동안 암호화폐 회사들이 금융 기관들을 대체하고자 하는 시도를 계속해서 지켜봐왔고, 블록체인 기술이 금융시장에 가져올 혁신을 대응하기 위해 비트코인과 이더리움 등 성공적으로 동작하고 있는 블록체인에 대한 연구를 진행했다. 연구의 목적은 암호화폐 회사들의 공격에 대응하는 것도 있었지만, 블록체인을 금융시장에 어떻게 적용할지, 실무적인 측면에서 바라보고 금융시장에 적용할 수 있는 기존 블록체인 기술에 대한 리뷰와 선택을 진행하는 것도 포함되어 있었다.

R3는 2014부터 2015년까지 수차례의 컨퍼런스를 진행하면서 블록체인과 분산원장에 대한 차이점을 분명히 하는 최초의 논문인 CaaS(Consensus-as-a-Service)를 발표했고, FX 결제를 초함한 구체적인 금융 유즈케이스를 포함한 협의를 진행했다. 또한 다양한 은행과 블로체인 기업, 금융기관들이 함께하는 컨소시엄을 구성하게 되면서 2015년 11월 말 42개의 금융 기관이 참여하는 DLG(Distributed Ledger Group)를 발표하며 R3라는 이름을 대체하게 되었다.

IBM에서 하이퍼레저를 개발하던 Richard Brown은 여러차례의 컨퍼런스와 대화를 통해 기존의 블록체인 플랫폼으로는 실 금융시장에 적용할 수 없다는 판단을 내렸고, 영국 버클레이 은행의 아키택트였던 James Carlyle, 비트코인 초기 개발자 Mike Hearn 등을 영입하여 Corda라는 새로운 금융 특화 블록체인 플랫폼을 개발하였고 2016년 1분기 말에 Corda라는 새로운 시스템을 구축하였다. 2016년 4월 5일 Richard는 Corda가 무엇인지, 설계 목표가 무엇진지, Corda는 블록체인이나 Cryptocurrency가 아니라 분산 원장이라는는 점에 대해 처음으로 공개적으로 설명했다. (Corda의 블록체인에 대한 기술적 정의는 다음편에 다루는 것으로...) 

기존의 비트코인, 이더리움, 리플과 같은 블록체인 플랫폼을 실 금융시장에 적용할 수 없었던 이유에 대하여 백종찬님의 글을 인용하였다.

1. 데이터 프라이버시

기존의 블록체인 구조는 네트워크 참여자가 모든 거래 내역을 보관하고 열람하는 구조다. 즉 A와 B간의 거래를 C가 검증해야한다. 고객 또는 자산의 기밀성을 보호해야 하는 금융산업에서 이와 같은 공개적인 데이터 검증 구조는 적용될 수 없다.

2. 확장성

모든 네트워크 참여자가 거래에 대한 합의를 도출하고 검증을 하게 되면 참여자가 많아질수록 거래 처리의 속도가 느려진다. 업계에서 주로 "초당 거래수"라고 얘기하는데, 빠른 속도가 생경인 긍융거래에서 이러한 확장성의 한계는 큰 문제다.

3. 법률적 책임

스마트계약의 경우 기존의 블록체인은 법률적 책임의 소재가 불분명하다. 컴퓨터 코드에 의한 비가역적인 실행은 가능하지만 실제로 그것이 법률적 강제성을 가지는 것은 아니다.

4. 개연적 결제 완결성

기존의 블록체인, 특히 비트코인이나 이더리움과 같은 퍼블릭 블록체인의 경우, 결제의 완결성을 법률 또 기술적으로 100% 보장하지 않는다. 항상 네트워크의 포크 또는 블록 재종에 등의 가능성이 존재한다. 은행거래의 경우 결제의 완결성은 중앙은행이 법적으로 보장하기 때문에 법률적인 특면에서도 문제가 있다.

2017년 R3 컨소시엄은 공식적으로 두 그룹으로 나누었다. 한 그룹은 Corda 플랫폼 구축에 중점을 두고 있으며, 다른 하나는 컨소시엄 멤버에게 적절한 서비스를 제공하는데 중점을 두는 연구 그룹이다. 연구팀은 40개가 넘는 프로젝트를 진행중이며 20개 이상의 프로젝트를 완료했다. 그들이 진행하는 프로젝트들은 모두 이더리움, 리블, 패브릭, 코다, 캐나다 중앙은행, 바클레이즈 은행 등 블록체인에 국한되지 않은, 다양한 플랫폼과 관련되어 있다. 

R3 컨소시엄의 프로젝트 중 하나인 제네시스 프로젝트는 42개 금융사들이 블록체인 위에서 기업어음을 보내는 프로젝트를 진행했고 그 이후에도 60개가 넘는 다양한 프로젝트에 은행들이 자발적으로 참여하여 매우 빠른 발전을 이루었다. 또한 국내 사례로 2017년 5월 국내 은행 중 국민,신한,우리,하나,기업은행 등 5개 시중은행이 R와 함께 고객확인 정보를 블록체인으로 저장,관리하는 프로젝트를 성공한 바 있다. 다만 금융사들의 고객정보를 공유하는 행위 등 법적으로 금지되어 있는 문제가 있기 때문에 상용화까지 처리해야할 이슈가 있을것으로 보인다.

지금까지 R3와 Corda의 탄생 배경과 발전 과정을 알아보았다. 다음 글에서는 Corda의 기술적 바탕을 좀 더 살펴보고 기존의 블록체인과 다른점은 무엇인지, 엔터프라이즈 플랫폼으로서 하이퍼레져와 차이점은 무엇인지 등 기술적인 부분을 좀 더 살펴 보고 Corda에 대한 이해도를 높이고자 한다.

참조

A brief history of R3 – the Distributed Ledger Group 

THE CORDA WAY OF THINKING

R3, 넌 도데체 누구냐!  

개요

결혼을 하게 되어 모바일 청첩장을 직접 만들기로 했다.

기획자가 확실하신 분이라 그분의 니즈를 만족시키기 위한 템플릿을 찾을 수 없었다.

기획자님은 선과 원이 만나 우리가 된다는 것을 강조하길 원하셨고 

나는 스크롤을 내리면 화면의 구성을 변경할 수 있는 parallax scrolling라는 기술로 개발하기로 했다.

Parallax scrolling를 위한 라이브러리는 skrollr.js 를 사용했다.

개발

최대한 단순화 하기 위해서 index.html 안에 css와 js 모두 인라인으로 개발했다.

jquery, skrollr 두개의 라이브러리를 사용했고, 이미지는 상대경로로 설정해서, 사용하고자 하는 분은 이미지만 바꾸면 된다.

나는 AWS S3에 public 저장소를 하나 생성하고, FrontCloud CDN 을 연결해서 하객들에게 공유했다.

사용자 환경은 모바일에 최적화 했고, PC화면에서 보아도 깨지지 않도록 살짝 설정해 두었다.

청첩장을 직접 만드시는 분들께 도움이 될 수 있길 바라며 포스팅한다.

데모

• https://s3.ap-northeast-2.amazonaws.com/wedding-github/index.html

깃헙

• https://github.com/wantutopia/mobileWeddingTemplate

스크린샷

개요

호가창 무결성을 보장하고 트랜잭션을 쉽게 관리하기위해서  RDB를 이용한 구현을 찾아봤다.

하지만 RDB를 이용한 구현은 수평적으로 확장이 어렵기 때문에 IO를 담당할 하나의 MASTER DB에 의존성이 매우 높다.

또한 물리적 성능 향상을 위해서는 더 좋은 장비를 구매해야하고 단일장비의 성능엔 한계가 존재한다. (물리적으로나 비용적으로나)

그래서 호가 매칭 알고리즘에서 IO가 많이 발생하는 사용자 주문 생성, 주문 매칭 단계는 수평적 확장이  쉬운 Redis를 사용하여 처리하고

매칭된 주문 트랜잭션 생성 및 처리는 Mysql에서 관리하는 방향으로 설계해 보았다.

Redis 살펴보기

1. 레디스는 메모리 기반 저장소라서 클러스터 서버 전체 다운시 데이터가 날아간다??
   
   1. Redis가 Memory 기반 저장소라서 캐시 전용 저장소로 오해하는 부분이 많은데, Redis도 옵션에 따라 텍스트 형태의 파일로 데이터를 저장할 수 있다.
      때문에 클러스터가 전체 다운되어도 파일을 통해 데이터를 복구할 수 있다.
2. 트랜잭션 관리가 어렵다??
   1. 레디스는 싱글 쓰레드 기반이라 트랜잭션 관리가 쉬운편이다.
      또한 Lua Script 를 사용하거나 트랜잭션을 지원하는 명령어 (MULTI) 를 통해서 트랜잭션을 보장할 수 있다.
   2. 오히려 싱글 쓰레드라 대량 작업시 블럭되는 점을 조심해야 한다. (keys 명령어나, 대용량 삭제와 같은 작업을 조심해야한다.)
3. 대용량 데이터 저장이 어렵다??
   1. 하나의 Key 당 최대 512MB까지 저장가능하다. 적지않은 사이즈지만 히스토리 정보까지 모두 메모리에 올려두기엔 부담스러운게 사실이다.
      그래서 IO 관련 데이터들만 redis에 저장하고 거래/히스토리 데이터는 RDB에서 관리하는 방향으로 설계해야한다.
4. 클러스터링을 지원하여 가용성이 높다?
   1. Redis를 사용하는 가장 큰 이유이기도하지만 가장 조심해야할 부분이기도 하다.
      클러스터 구성에 따라 다르지만 보통 레디스 클러스터는 Master - Slave 구조로 구성된다.
      Master가 다운될 시 Slave가 자동으로 Master로 승격되는데 이때 승격될 Slave 에 데이터가 비어있으면 모든 클러스터의 데이터가 비워지게 된다.
      우리는 Redis 클러스터를 직접 구현하지않고 AWS 를 사용할거라 다행이다 ^^

설계

필요한 자료구조

1. 주문 상황판
   (buy/sell 주문의 order price 별로 order quantity 를 가지는 Sorted Set<score, orderSum>)
   
2. 주문 리스트
   (Map<typeAndCoinAndPrice, List<order>> buyList, Map<typeAndCoinAndPrice, List<order>> sellList ) 
   
3. 내 주문
   (내 주문 상태를 관리하고 목록을 확인할 수 있는 Map<memberNo, Map<orderId, order>>)
   
   
4. 매칭된 두개의 Order 를 저장/처리할 Transaction RDB 테이블
   
   

동작 시나리오

1. 주문생성 (Create)  - (주문 생성 전 주문이 필요로하는 코인/현금만큼 사용자의 잔고를 freeze 해야한다.)
   1. 새로운 주문이 들어오면 시퀀스 시작. 
   2. (redis 트랜잭션 시작)
      '주문 상황판'을보고 매칭할 주문 리스트 진입점을 찾는다. (매칭되는 진입점이 없으면 v 단계로 이동)
      1. 주문 타입이 Buy면 주문 가격이하의 Sell List중 가장 저렴한 리스트를 찾는다.
      2. 주문 타입이 Sell이면 주문 가격 이상의 Buy List중 가장 비싼 리스트를 찾는
   3. 매칭되는 리스트가 있으면 LPOP으로 order를 꺼내오고, '주문 상황판'과 '내 주문'에서 해당 order를 제거한다. 
   4. 요청 들어온 주문과 매칭된 주문의 거래량을 비교하여 분기 시퀀스를 따른다. 
      1. IF (RequestOrder.quantity > MatchedOrder.quantity)면  두개의 주문을 갖는 Transaction 객체를 생성하고,
         RequestOrder.quantity 를 차감한다. 
         처리된 MatchedOrder를 상황판과 사용자별 주문에 반영한다.
         (redis 트랜잭션 커밋 후 다시 ii 단계부터 시작)
      2. ELSE IF (RequestOrder.quantity <= MatchedOrder.quantity) Matched Order을 RequestOrder.quantity 기준으로 분리한 후
         Transaction 객체를 추가하고, 분리된 여유분의 Order를  다시 주문리스트로 LPUSH한다. (RequestOrder 의 주문량은 0이됨)
         스플릿되어 처리된 MatchedOrder를 상황판과 사용자별 주문에 반영한다.
         (redis 트랜잭션 커밋후 vi 단계로 이동) 
   5. 매칭되는 리스트가 없으면 Request Order의 가격 리스트에 RPUSH 하고 상황판과 내 주문에 반영한다. 
      (redis 트랜잭션 커밋)
   6. 생성된 Transaction 객체들을 처리한다.
      
      1. 주문 밸리데이션 (잔고, 요청내용 2중 검증)
      2. 사용자별 잔고 증감 및 수수료 취득 
2. 주문 관리 (Read)
   1. 고객별 My 주문 리스트는 사용자 별 '내 주문' 모델을 통해 관리한다.
   2. 전체 주문량은 '주문 상환판' 모델을 통해 관리한다.
   3. 체결내역은 Transaction 테이블을 통해 관리한다.
3. 주문 수정 (Update)
   1. 주문량/주문가 수정의 경우
      (redis 트랜잭션 시작)
      대상 주문을 리스트에서 POP 하여 값 수정 후 RPUSH 
      주문 상황판, 내 주문도 업데이트
      (redis 트랜잭션 종료)
4. 주문 취소(Delete)
   1. 주문 취소의 경우
      (redis 트랜잭션 시작)
      대상 주문을 리스트에서 POP
      주문 상황판, 내 주문도 업데이트
      (redis 트랜잭션 종료)

예외 처리

1. 모든 주문은 요청 전에 검증(잔고확인, 소유자 확인, 권한 확인)을 통과해야한다.
2. 검증된 주문이라도 트랜잭션 처리 전에 한번 더 검증한다.
3. 주문처리 우선순위는 가격 > 시간이다.
4. 트랜잭션 생성을 위해 주문을 LPOP 하여 거래량 차감 후 LPUSH 하는사이 시간 우선순위를 위배할 수 있다.