Amazon Managed Blockchain

220.Blockchain 블로그 이더리움 ethereum aws qldb 티스토리

11/28일, AWS 에서 AWS Blockchain Template 에 이어 Amazon Managed Blockchain 서비스와 QLDB 를 소개하였다. 지금 시점에는 Preview 상태인데 이마저도 Sign Up 을 해야 하기는 하다.

일단 Preview Signup 을 하고나면 시간이 좀 지났더니 아래 처럼 메일이 온다

위 메일이 왔다고 해서 Preview Applicant 가 되었다는게 아니다. 기다려야 한다..
Apply 를 했지만 이틀 째 아직 회신이 오거나 하지 않는다 그냥 계속 기다려야 한다.

혹시나 사용 가능해지면 써보고 바로 다시 글을 올려보겠다

어디에 있나

AWS Console 에 들어가면 아래 처럼 Amazon Managed Blockchain 이 있는걸 볼 수 있다

마치 될 것 같은 느낌이지만 클릭하면 다시 Preview sign up 페이지로 넘어간다

현재 AMB Preview 가 지원되는 Region 은 US East (Virginia) 뿐이다
현 시점에 QLDB 메뉴는 어디에 있는지 발견하지 못하였다

Amazon Managed Blockchain

아직은 들어가보지도 못하고 자료도 거의 전무한 상태이므로, AWS 상의 서비스 소개 페이지를 참고하여 어떤것인가 정리해놓겠다

전체 구성

AMB 는 독립된 Member 별로 Peer Node 를 구성하게 하고, Ordering Service 와 Client 를 Fabric Network 으로 연결해주기 위한 VPC Endpoint Service 등은 공용할 수 있는 컴포넌트 형태로 제공하는 것으로 보인다.

아래 가격표를 보아도 알겠지만, Ordering Service 를 위한 별도의 Node 는 구매하지 않는다. 이부분은 AWS 에서 제공하는 것으로 보이며, 대신 Membership 금액을 시간당으로 받는 것으로 생각된다

Benefits (&Features)

Fully Managed

• 여러 AWS 계정에 걸쳐 Blockchain Network 을 쉽게 생성
• 멤버 그룹과 Account 의 Transaction 실행, 데이터 공유를 설정
• Infra 와 S/W 설치 등이 필요 없다
• 모니터링 기능 제공한다
• 멤버 추가와 삭제를 위한 투표 기능 API를 제공한다

Fabric 과 Ethereum 중 선택

• Privacy 와 Permission 중요한 곳에 Fabric 추천
• Transparency 와 분산화 중요한 곳에 Ethereum 추천
• Ethereum 은 Public / Private Network 지원할 것으로 보임

Scalable and Secure

• Peer node 추가를 위한 API 를 제공
• 원하는 H/W spec 을 조합
• AWS KMS(Key Management System)를 통한 Key 관리로 안전

Easily analyze Blockchain Activity (향후 예정)

• Blockchain network 활동을 QLDB 에 저장할 수 있음
• 변경되거나 삭제될 수 없는 형태로 영구히 남게됨
• 누가 Transaction 을 발생하였는지, Transaction Rate 이 어떻게 되는지 등 Query 가능

Reliability

• Ordering service 에 QLDB 를 접목, Transaction 의 Full History 를 조회 가능하도록 함

가격

N. Virginia Region 에 대한 가격만 나와있는 상황으로, 아래와 같이 가격표가 나온다

Membership

• Starter Edition : $0.30/h (337원/시간)
  
  • 네트워크 상 최대 5개 멤버
  • 멤버 당 최대 2개 Peer Node
  • bc.t3.small 또는 medium 타입 Peer Node 가능
  • 최대 1 TB 의 Peer node storage
  • Orderer 성능 제약(Standard 에 비해 떨어짐. 수치는 안나옴)
• Standard Edition : $0.55/h (617원/시간)
  
  • 네트워크 상 최대 30개 멤버
  • 멤버 당 최대 10개 Peer Node
  • bc.t3, bc.m5, bc.c5 타입 Peer Node 가능
  • 최대 15 TB 의 Peer node storage

On Demand peer node pricing

• 38 원 ~ 1,220 원 / 시간

Peer node storage
최소 10GB 부터 최대 15TB 까지 선택할 수 있음

• $0.10 / 월 (112원/월)

Data Written
Fabric Network 에 Write 되는 모든 Transaction Payload 를 포함한 Data 총량

• $0.10 / GB (112원/GB)

가격 예시

✸ Starter Edition 기준으로 아래와 같이 세팅 한다고 하자

2 개 Starter Member
각 멤버가 bc.t3.small 1개씩 운영
20GB Storage
시간당 9MB 의 Network 사용

위 Spec 이면 간단한 내부 PoC 정도가 가능한 사양이라고 봐야 하겠다. 음.. 사실 PoC 를 위한 개발 정도?

✸ Standard Edition 으로 가보자. 상용에서는 자신의 Org 에 대한 비용만 내는 경우가 많은것이므로 아래와 같이 구성했다고 가정한다

1 개 Standard Member
3 개 Peer Node (m5.2xlarge)
Node 당 1TB Storage
시간당 200MB Network 사용

위 Spec 이면 상용 서비스를 위한 구성 으로 알맞는다고 본다. Offchain 시스템을 위한 부분은 추가로 갖추어져야 한다.

이상이 AMB(Amazon Managed Blockchain) 의 소개 이다. 대략 어떤 서비스가 가능한지 감이 온다. 설치와 설정을 위한 노가다가 줄어들고, 모니터링 기능이 추가될 것이고, Key 저장을 안전하게 해주고, QLDB 를 활용하여 모든 Transaction 과 Activity 가 저장되니 의미있는 데이터를 QLDB 에서 뽑아쓸 수 있다 정도가 핵심일듯 싶다.

그리고 소개 페이지나 Guide 등에 보면 대부분 Fabric 중심으로 설명되어 있어서 사실 Ethereum 은 기존의 Blockchain Template 기능 정도를 재탕하여 해주지 않을까 생각이 든다

사용 가능한 상태가 되면 실제 사용해보고 (설마 돈내라는건 아니겠지..) 추가로 글을 써보도록 하겠다

Multisig Wallet #1

Ethereum multisigwallet ethereum

Multisig Wallet 을 구현해보자. 블록체인의 응용을 이야기 하거나 할 때 빠지지 않는 단골 메뉴이기도 한 Multi Signature 를 활용하는 Wallet 을 만들어 보고, gnosis, consensys 애들이 만든 Multisign Wallet 은 어떤 구조를 갖고 있는지도 봐보는 재미진 시간을 가져보자

Blockchain 의 Wallet

일단 Wallet 의 개념은 다 알것이다. 특히 Blockchain 의 Wallet 또한 모두 잘 알 것이다. Blockchain 의 Wallet 은

• Key Pair (Private / Public Key) 를 생성하여 안전하게 보관
• Transaction 을 생성하고 여기에 본인의 전자서명을 첨부 (보통 Transaction 의 Hash 값을 원문으로 함)
• Account 기반의 State Model 인 경우, Account Nonce 를 관리

를 기본 기능으로 가지며, 추가적으로

• 복수의 계좌(Account)를 생성/관리 하는 HD Wallet 의 경우 KDF(Key Derivation Function)를 통한 루트 키와 Derived Key 관리
• Mnemonic 기반의
• Web 기반 dApp 실행을 위한 Web View 와 web3.js 등의 JS Injection
• (Ethereum) ERC 20 기반의 Token 및 기타 EIP 제안 중 널리 쓰이는 ERC 지원(ERC721 등)

등의 기능을 가지는 Wallet 들이 많아지고 있다.

Wallet 에 관해서는 이번 주제 끝나고 다음에 한번 상세히 다루어 보도록 하겠다
HD Wallet 이나 Cold Wallet 에 대해서도 재미난 것들이 많이 있으니 그때 또~

일반 Crypto Wallet 의 Transfer Transaction

Multisig Wallet 은 Crypto Wallet 자체에서 지원하는 기능은 아니다. UTXO 내의 Script 혹은 Smart Contract 의 코드로 Blockchain 내에 존재한다.

일단 아래는 단순화 된 일반적인 Wallet 의 Transfer 과정이다

그림을 단순화 해서 그렇지 Wallet 내부에서는 아래와 같은 과정을 거친다

1. (secp256k1 으로 Private Key 는 이미 생성 되었다고 가정한다. 즉, 주소는 이미 생성 되었다고 가정한다)
2. ECDSA 전자서명이 붙지 않은, 100 Ether 를 Value 로 하는 Raw Transaction 을 구성한다
3. Raw Transaction 의 keccak256 Hash 를 원문으로 한 ECDSA 전자서명 값 r,s,v 를 추가하여 Transaction 을 만든다
4. Wallet 서비스를 하는 Gateway 를 거치거나 혹은 직접 Node 에게(이런경우는 흔치 않다) Transaction 을 Submit 한다
5. 100 Ether 는 to address 에 해당하는 Account 의 State 에 더해진다

UTXO 기반 모델의 Blockchain 도 Wallet 의 기능은 마찬가지이다

Multisig Wallet 의 Transfer Transaction

일반적으로 Multisig Wallet 은 2개 이상의 서명이 있어야 실제 Token 의 이체가 일어나게 할 수 있는 기능을 갖는 Wallet 을 말한다.

Bitcoin Wallet 개발하시는 분들은 Multisig Wallet 하면, Wallet 에서 생성한 Tx(Transaction) 내 Output 의 Locking Script(Pubkey Script) 부분에 OP_CHECKMULTISIG 를 포함하도록 만드는 것을 생각 할 수 있겠다.

Ethereum 과 같이 Smart Contract 를 지원하는 블록체인의 경우는 좀더 세련된 방식으로 Multisig Wallet 을 만든다. 또한, Token Asset 의 이체를 위한 Transfer Transaction 뿐만이 아니라 Smart Contract 실행을 위한 Message Transaction 또한 조건을 만족하는 복수개의 서명이 Submit 되었을때에만 실행되게 할 수 있다(보통 이렇게 만든다).

왜 갑자기 Wallet 얘기를 하는데 Smart Contract 얘기가 나오는가 할 수도 있다. 예전부터 많은 사람들이 이부분을 헷갈려 한다는걸 느꼈다. Multisig Wallet 은 결국 내가 제출한 Transaction 에 대해, 미리 지정된 복수의 Account Owner 가 전자서명을 통해 허락해야지만 실제로 그 Transaction 이 실행되어야 하는 규칙 이다.

이러한 규칙은 Wallet App 에 구현되고 저장되는 경우 충분히 위변조 될 수 있으며 중요한 돈거래의 경우 보안성과 범용성의 측면에서 뭐하나 이로울게 없다. 그 얘기는, 블록체인 기술과 Smart Contract 의 필요성이 가장 강한 형태의 dApp 중 하나가 바로 Multisig Wallet 인 것이다.

아래의 Diagram 은 Multisig Wallet 의 동작을 단순화 해본 그림이다
상황은 0xa0c9… 주소를 갖는 EOA 가 0x039b… 에게 100 Ether 를 이체하려고 하며, 이때 미리 지정한 0x0248… EOA 의 최종 승인 이 있어야지만 실제로 100 Ether 가 0x039b… 에게 이체되는 Transaction 이 실행되게 해야 한다.

구성요소

• Wallet - Account 소유자가 설치한 Browser Plug-in, Desktop, Mobile 용의 Wallet App (Metamask, MEW, Jaxx, Exodus …) 이거나 Smart Contract 실행을 위한 Message Transaction 을 만들어낼 수 있는 어떠한 dApp 도 될 수 있다
• Multisig Wallet Contract
  
  • 이체하고자 하는 Token 을 보관
  • 제출 된 Transaction 실행 요건 지정 (n of m 개의 전자서명 요구와 같은)
  • 전자서명 주체가 되는 Wallet Owner 들의 등록 및 관리
  • Transaction 제출 알림
  • 요건을 만족한 경우 Transaction 의 실제 실행

이외에도 Wallet 앱을 개발하고 서비스 하는 회사의 경우, 아무나 자신들이 운영하는 Node 에 수많은 Transaction 을 날려 DoS Attack 을 하거나 부하를 일으키지 않도록 하고 부가적인 서비스를 제공하기위한 목적으로 Wallet Service Gateway 를 둘 수도 있겠지만 Offchain 시스템은 모두 생략하였다

위 구성요소의 설명을 보면 알겠지만 핵심은 Multisig Wallet Contract 이다. Multisig Wallet의 모든 핵심 기능은 이 Contract 에서 이루어진다. 예전에 문제가 된 Parity 의 Multisig Wallet 도 물론 Smart Contract 이다.

흐름

위 Multisig Wallet Contract 를 사용하는 흐름을 보면 간단하다 하지만 이전 글에서는 다루지 않았던 새로운 요소가 하나 등장한다

1. submitTransaction
   submitTranaction() 을 실행하기 위한 Message Transaction 의 Parameter 를 이용하여 실제 Token(Ether) 을 받을 주소를 넣어준다

   이때, Token 을 받을 대상이 다른 Smart Contract 이고 Transaction 종류가 Message Transaction 인 경우, submitTransaction() 의 파라미터 중 하나에 실행해야 하는 Smart Contract 의 Method 와 파라미터를 포함하는 Data Payload 를 넣어준다 (web3 의 .getData() 사용)

   추가적으로, 예의상 submitTransaction() 이 되면 Event 로 transaction 이 submit 되었다고 알려주는 센스 정도는 설명하지 않아도 구현 되어야 한다고 느낌이 올 것이다

이부분은 구현 부분에서 설명하겠다. 향후 CALL, CALLCODE, DELEGATECALL 과 관련 있는 부분이니 그때 또 설명 하겠다 (음.. 오랜만이 시작하려니 설명할게 산더미같다..)

2. confirmTransaction
   위 submitTransaction() 으로 제출 된 Transaction 을 승인 하는 단계이다. Contract 에 등록된 승인 권한이 있는 EOA 가 confirmTransaction() 을 통해 confirm 해주면 된다. 이때, 각 confirm 시 마다 등록된 조건(최소 n 개의 confirm 필요)을 만족하는 confirm 을 받았는지 check 한다

3. executeTransaction
   confirmTransaction() 실행 시 만족하는 confirm 수가 채워졌으면 submitTransaction() 시에 제출 된 token 의 양 만큼을 원래 보내고자 했던 주소로 보내주도록 Transaction 의 value 값을 채우며, submitTransaction() 단계에서 제출 된 Message Transaction 이 있었다면 Wallet Contract 가(msg.sender == Wallet Contract) 해당 Message Transaction 을 실행한다

Multisig 인데, 서명은 언제하는가?

전에 Multisig Wallet 에 대해 차분히 설명 해주고 나서 들었던 질문이 있었다. “그런데 다른사람들(EOA)이 전자서명은 언제 해줘요?” 전자서명은 이미 Smart Contract 를 실행하는 submitTransaction(), confirmTransaction() 단계에서 Message Transaction 을 보내기 위해 Raw Transaction 에 대고 다 했다. 그래야 Transaction 이 submit 되었지 않겠는가..요.. 라고 답을 해줬던 기억이 난다.

(단, Smart Contract 이 internal call 을 하는 구간에는 전자서명이 당연히 없다. EOA 에서 이미 했지않은가. Smart Contract 는 서명할 수 있는 놈이 아니다. Smart Contract 을 실행한 놈이 이미 전자서명을 해서 Message Transaction 을 보낸 것이다)

이름이 문제다. Multisig.. 사실 confirmTransaction() 단계에서 파라미터로 메시지와 전자서명값 r,s,v 를 넣어줄 수도 있다. 그러나 다른 EOA 의 전자서명을 전달하는 상황이 아니고 confirmTransaction() 을 실행하는 주체 자체가 승인 권한을 가진 EOA 이므로 이미 transaction 내에 들어있는 전자서명을 Multisig Wallet Contract 의 파라미터로 보낼 이유가 없는 것이다

마치며

오랜만에 올리는 글 치고는 매우 기본적인 주제를 올려본다. 사실 0xProtocol, Plasma, Raiden, ERC20 Token 기반으로 돌아가는 dApp 만들기, plasma-mvp … 또는 Enterprise Blockchain, Quorum 등등 무엇부터 시작할까를 많이 고민해보았다.

그리고 이전에 올렸던 글들을 다시 훑어보다가, 블로그의 흐름이 갑자기 끊기는것 보다는 이전의 Context 를 이어나아가면서 좀더 빠르게 진행해보는 것으로 일단 마음을 먹어본다. (그래도 기본은 기본대로 가고, 중간중간 발표자료도 좀 올리고, 이런저런 구현 샘플들도 짬짬이 올리겠다^^;;)

다음은 Multisig Wallet 구현 예제를 1회 정도 올리고 퀵하게 마무리 하고 또 그 다음으로 넘어가 보도록 하는걸 목표로 해보겠다

Reboot

220.Blockchain 이더리움 Ethereum 티스토리 ethereum

2년여 라는 정말 긴 시간을 흘려보냈다. 블록체인 안하냐고 물어보는 분들도 계셨지만, 블록체인은 계속 해오고 있었고, 다만 블로그는 그만두고 있었다. 긴 시간, 우리나라에 그렇게 많은 적극적인 블록체인 투자자가 계신줄 몰랐다. OOOO 만들어 줄 수 있겠냐.. (뭐 주로 코인 등) 강의 해줘라 해서 가면 다단계 판인 경우도 있고.. 회의감이 들고 기술 보다는 투기와 관련된 쪽으로 몰려가는 것 같아 블로그나 외부 발표 등을 모두 중지한 상태였다.

스타트업이 아닌 회사 특성 상 (맘에 안드는) 엔터프라이즈 블록체인 위주로 프로젝트를 하며 개인적으로 몇가지 Ethereum dApp 들을 만들어 가며.. Quorum 도 돌려가보며.. 시간을 보내다 보니 벌써 2018년 겨울이 되고… 아싸~

각설하고, 다시 블로그를 통해 기술적인 글들을 올려보려고 한다. 물론 다른 주제들도 쓰겠지만 블록체인 주제는 좀더 각별하다. 그간 다양한 세미나, Meetup 등에 나가 보았지만 Study 를 통해 분석한 내용을 공유하거나 개념을 전파하는 자리가 대부분이었고, 실제 Code를 통해 dApp 을 개발하는 Hands-On 세션은 아직도 Crowd Sale 과 ERC20 Token 개발이 대부분이라는것이 조금 서글프긴 하다.

앞으로 시간 되는대로 이전 글들의 흐름에 맞는, 이어지는 글들도 올려보고, 중간중간 색다르거나 새로운 소식과 기술과 관련한 글들도 올리며 즐겁게 지내보려 한다~