본문 바로가기
WBS - 2023 Summer/Fintech 금융혁신과 Internet

(Fintech #7-8) Smart Contract

by fastcho 2023. 6. 26.
반응형

 

 

 

  • Smart Contract란?
    • Digital로 표현되는 자산을 미리 정해진 Rule에 따라 자동으로 이전 및 상태 전환을 하는 구조
      • Ethereum에서는 [Program Code와 Data를 Blockchain에 기록하고,
        Transaction의 지시에 따라 Block 검증 시 실행하는 구조]를 말한다.
        • Digital로 표현되는 자산 → Data
        • 미리 정해진 Rule → Program Code
        • 자동으로 이전・상태 전이 → Transaction의 지시에 따라 실행
  • 어감과는 맞지 않습니다.
    • [미리 정해진 Rule] 부분이 본래는 [계약]인데, 이것으로는 외부에서 이루어진 계약이 주어졌다고 가정하고
      [그에 따라 실행한다]고만 말하고 있는 것 아닌가요?
      • 그리고 Smart한, 혹은 자동화된 구조라는 것은 대체로 그런 것이 아닐까요?
    • 하지만 이 좁은 의미에는 의미가 있습니다.
      • Blockchain으로 가능한 것은 어디까지나 Blockchain에 닫힌 범위에서의 증명이기 때문입니다.

 

좁은 의미의 이야기

 

 

 

  • Smart Contract란?
    • 계약을 기계로 구현하는 구조
    • 그리고 그렇게 구현된 계약
      ↑ 미래의 사전에 실릴 정의
  • 원론적으로는 자판기 등도 Smart Contract에 해당한다.
  • 반대로 말하면, 이 넓은 의미는 그다지 의미가 없습니다.

 

넓은 의미의 이야기

 

 

 

  • 계약이란 (by 광사전)
    • 1. 약속
    • 2. 대립하는 복수의 의사표시의 합치에 의하여 성립하는 법률행위.
      • 증여, 매매, 교환, 대차, 도급, 고용, 위임, 위탁 등이 그 예이다.
  • 성립의 본질적 요건
    • 당사자 간 의사표시의 일치
    • 이를 위한 Media는
      • 구두, 악수, 점토판에 새기거나 굽거나 깨뜨리는 행위, 종이(필기), 종이(인쇄), . . .
      • 기계로 할 수 있는 것은?
      • cf. '미디어가 메시지다' by McLuhan
      • cf. '구텐베르크의 은하계' by McLuhan → 활판인쇄술의 등장이 산업사회 형성에 크게 기여했다.

계약이란?

  •  

 

Gutenberg의 은하계 by 활판인쇄술

 

Gutenberg의 은하계 by 활판인쇄술 뒤집히는 Gutenberg의 은하계 by Digital Technology
저자라는 개념의 탄생
- 완전한 복제가 불가능하다면 [저자]는 무의미하다.
작가라는 개념의 파괴
- SNS의 Timeline, AI가 생성하는 그림과 음악, 동영상
과학적 방법론의 확립
- 논문이 완전히 복제되기 때문에 추적을 통해 지식을 확인할 수 있다
과학적 방법론의 재검토
- AI가 가설과 검증 Loop를 돌며 새로운 발견을 한다.
민족주의 촉진
- 통일된 [국어]의 탄생
지구 규모의 시점의 촉진
- Global으로 Share되는
영화의 탄생을 준비
- 작가가 카메라를 통해 하나의 시점으로 촬영한 사진의 연속성 확보
모든 사람이 영상 작가가 되다
- 누구나 관점을 공개하고 Share할 수 있다
완제품과 미완성품의 명확한 구분 확립 ⇒ 제품
- 손글씨는 미완성, 인쇄하면 완성
완제품과 미완성품의 불분명화 ⇒ Open Design
- 어디까지나 손을 대면서 변화시킬 수 있다.
개인주의 확립
- 지식을 개인이 가지고 다닌다.
협업(Collaboration) 촉진
- 언제든 동료와 연결됨
대중문화의 획일화
- 많은 사람들이 같은 내용을 보고 듣는다.
문화 이벤트의 다양화
- 다양성과 Long Tail
⇒ 산업사회를 준비했다 ⇒ 산업사회의 다음 사회를 준비

 

뒤집히는 Gutenberg의 은하계 by Digital Technology

 

 

 

  • Vitalik Buterin, "Ethereum White Paper: A NEXT GENERATION SMART CONTRACT & DECENTRALIZED APPLICATION PLATFORM" (2013.12. ∼)
  • Blockchain 기술 적용
    • 12초 간격의 Slot 내에서 Block을 생성 (간혹 생성하지 못하는 경우도 있음)
  • 거기에 Programming 언어 (= Turing완전)를 얹는다는 Idea
    • Turing 완전 = 만능 Turing Machine을 Emulate할 수 있다.
      = Random Access 가능한 (무한한) Memory와 CPU로 구성된 계산기를 Emulate할 수 있다.
      ⇒ 실제로는 작성할 수 있는 Program의 종류에 제한이 있다.
  • [분산 Application]을 위한 기반
    • 단, 기능 분산이 아닌 복제이므로 [DApps]라고 부르는 것이 타당하다.
      • DApps = 탈중앙화 / 중앙 자동화 Application

Ethereum이란?

 

 

Blockchain과 상태 전이

  • Blockchain = 상태 Machine (상태 전이 System)의 run = Computer의 동작
  • 상태 Machine을 복제하여 Event와 상태를 검증 가능하게 함
    모든 사람이 올바르게 작동하고 있는지 검증 가능한 World Computer

 

 

 

 

 

  • 정말 의미 있는 응용은,
  • Digital 서명의 시간 증명이나 알리바이 증명이 필요한 곳입니다.
    • Bitcoin은 이를 필요로 합니다.
    • 2009년에 이루어진 송금은 여전히 유효하고, 없던 송금을 조작할 수 없습니다.
      ↑라는 상황을 유지하고 싶다.
      • 14년이라는 세월은 예를 들어 My Number Card에 의한 전자서명의 수명을 넘어섰습니다.
        (공개키 인증서의 유효기간이 갱신 후 5 번째 생일까지로 되어 있다)

어떤 응용이 있을까?

 

  • ADR (Active (space) Debris Removal) 통화
  • 지뢰제거 통화
  • 해양 Plastic 제거 통화
  • 이산화탄소 제거 화폐
  • 노동증서 (1930년대 Stamp 지폐 재현) 
  • 공공사업 화폐 (주민투표로서의 측면도 )

감가되는 통화(Policy Tool)

 


Blockchain과 상태추이

  • Blockchain = 상태 Machine(상태 전이 System)의 run = Computer의 동작
  • 상태 Machine을 복하여 Event와 상태를 검증 가능하게 한다.
    올바르게 작동하고 있는지 모두가 검증 가능한 World Computer

 

 

 

  • 다음과 같이 하면 참여 Node(Computer)에 상태가 복제된다.
    • (1) 동일한 초기 상태로부터 시작
      • Blockchain에서는 Block 번호 0(Genesis Block)을 모두가 공유한다.
    • (2) 모든 참여 Node에 모든 Event가 Copy된다.
      • Blockchain은 Transaction이나 그 집합인 Block을 Network에 분산시켜
    • (3) 동시에 동일한 순서로 Copy된다.
      • Blockchain에서는 나카모토 Consensus에 의해 결국 이렇게 된다.
    • (4) 모든 Event는 상태에 대해 결정적으로(모든 Node에서 동일하게) 작용한다.
      • 그래서 Smart Contract에서는 그 안에서 주사위를 굴리는 것과 같은 동작을 할 수 없다.
  • 따라서 내결함성을 유지할 수 있다.← 이 방법의 원래 목적
  • Blockchain에서는 이 과정을 Open으로 누구나 참여할 수 있게 함으로써 검열 저항성 확보에 Challenge하고 있다.

 

상태 Machine의 복제 (Lamport 1984)(Schneider 1990)

 

  • Ether (ETH)
    • Ethereum의 통화
  • 외부 Actor
    • Digital 서명이 가능한 실존하는 Account을 가짐
      • EOA : Externally-Owned Account
  • 자율 (자동) Object (내부 Actor)
    • System 내에서 자율적으로 작동하며, Account을 가지고 있음
      • 하지만 Message를 보내지 않으면 움직이지 않음 (그리고 Validator가 움직여줌)
        ← '자율적'이라기보다는 '자동적'
  • Account
    • Ether 잔고를 가지고, Storage(상태)와 EVM Code를 가질 수 있다.
  • EVM Code
    • Smart Contract의 Program
      • Smart Contract = Ethereum에서의 응용 Program ≠ Smart한 계약
      • Blockchain에 기록됨으로써 진본성이 보장됨

용어체계

 

 

EVM : Ethereum Virtual Machine

  • 자율(자동) Object가 Message를 받으면 실행되어 Contract를 실행하고 상태를 변화시킴.
  • 실행 Step마다 Gas 대금 공급 필요
    (무한 Loop를 피하기 위해 'EVM의 실행자 = Validator'에게 수수료가 발생 (대부분 burn))
    • 종량제이기 때문에 보급에 어려움

 

 

 

 

  • 야심찬! 세계 최초? Ethereum의 작동 원리를 물리 Model로 설명합니다!
  • 전제조건
    • Beaker에 대하여
      • Bitcoin과 달리 Beaker는 Transaction마다 새롭게 생성되는 것이 아니라
        개인키와 Set로 만들어지며, 각각 특정 주소에 배치됩니다.
      • 비밀 키로 뚜껑을 열면, 그 안의 액체를 어딘가에 주입할 수 있다(비우지 않아도 OK).
      • 주둥이는 항상 열려있어 액체를 주입할 수 있습니다.
    • 액체에 대해
      • 액체는 기계식 계산기가 수동이 아닌 자동으로 움직일 수 있는 '연료'로 사용됩니다.
    • 계산기에 대해
      • 세계 유일의 기계식 계산기를 사용합니다.
      • 방대한 Memory를 가지고 있으며, Punch Card를 꽂고 Beaker를 Set하면 작동됩니다.
    • Programmer가 갑자기 Punch Card에 입력할 수 없기 때문에
      • 사람이 읽을 수 있는 Code를 Punch Card에 'Compile'하는 Service를 이용합니다.

Beaker / 신문 / 기계식 계산기 Model (1)

 

 

 

  • Transaction
    • 계산기를 사용하는 처리를 'Transaction'이라고 하며, 다음과 같은 세 가지 종류가 있습니다.
      • 주입원 Beaker와 주입처 Beaker를 설정하여 연료를 지정한 양만큼 이동시킨다.
      • 응용 Program과 초기 Parameter를 기록한 장문의 Card와 Beaker를 Set하여,
        Memory에 Program을 작성한다(Deploy한다).
        - 계산기는 그 Program의 초기화 Code도 실행하여 응용 Program을 Set up한다.
      • 짧고 작은 Card와 Beaker를 Set하고, Memory에 있는 Program을 호출하여 사용한다.
  • 서명된 신문 기사
    • Transaction을 실행하고자 하는 사람은 자신의 '서명된 신문기사'로
      다음과 같은 내용이 적힌 Copy지를 후술할 Validator 등에게 배포합니다.
      • 연료를 주입한 Beaker의 주소 (서명이 있어 본인임을 알 수 있음)
      • 펀치 카드의 내용
      • 계산기를 구동하는 검증인에게 양도할 수 있는 연료의 양(우선 요금)과 사용할 수 있는 최대 연료의 양
    • 실행된 Transaction에 대한 기사가 정리되어 신문의 한 Page를 구성합니다.

Beaker / 신문 / 기계식 계산기 Model (2)

 

  • 연비
    • 기계식 계산기는 일정한 연비로 움직이는 것이 아니라, Transaction이 혼잡할 때
      연비가 나빠지고 (연료를 더 많이 필요로 하며), 비어있으면 연비가 좋아집니다 (연료를 덜 필요로 합니다).
    • 연료를 소비하는 계산의 1단위를 헷갈리기 쉽지만 'Gas'라고 부릅니다.
    • 신문의 지면 크기도 Gas로 측정됩니다 (실행된 Transaction의 Gas 사용량의 총합).
    • 신문지면의 기준 크기는 1,500만 Gas이며, 최대 크기는 3,000만 Gas입니다.
    • 종이의 기준을 초과하면 다음 지면에서는 거래의 연비가 더 나빠지고,
      기준보다 낮으면 다음 지면에서 연비가 더 좋아집니다.
      • 사람들은 연비가 좋을 때 계산기를 사용하고 싶어하기 때문에 혼잡을 조정할 수 있기를 기대합니다.
  • 작업 증명 추첨 Cost이 충분히 축적된 후 이후 방식으로 전환합니다.
    • 다음 Page부터 설명할 방식은 갑자기 시작할 수 없습니다.
    • Ethereum은 2022년 9월에 작업증명 방식에서 이후 방식으로 전환했습니다.

Beaker / 신문 / 기계식 계산기 Model (3)

 

 

 

 

  • Deposit 및 Validator
    • 연료는 'Gwei'라는 단위로 측정되며, 'Giga Gwei'는 'ETH'입니다.
    • 32 ETH (!) 을 System에 Deposit한 사람은 'Validator'이 됩니다.
    • Validator은 다음과 같은 업무를 수행해야 하며, 성실하게 수행하면 예치된 ETH가 늘어나며,
      게으름 피우면 ETH를 몰수당할 수 있습니다.
      - 최대 32 ETH까지만 Deposit으로 인정 (실제 금액은 그 이상도 OK)
      - 16 ETH 이하로 떨어지면 Validator가 추방됩니다.
  • Slot과 신문 지면 (Block) 제안
    • 12초 간격의 'Slot'으로 시간을 구분합니다.
    • 각 Slot에서 Validator 중 누군가가 (일반적인 의미의) 복권에 당첨됩니다.
      • 당첨된 Validator은 수집한 기사 중 실제로 실행할 분량을 결정하고, 계산기를 실행하여
        (작동에 실패하면 기사를 버립니다), 신문의 한 Page를 구성하여 모두에게 제안합니다.
      • 만약 빠지면 그 Slot에서 신문을 만들지 못했다는 뜻입니다.
    • 신문을 받은 다른 Validator는 확인 계산을 합니다.

Beaker / 신문 / 기계식 계산기 Model (4)

 

 

  • Epoch 및 확정
    • 32개의 Slot을 1 Epoch(384초)로 간주합니다.
    • Validator는 해당 Epoch의 Slot을 담당하는 위원회(Beacon 위원회)에 배정되어
      해당 Slot에 제안된 지면의 정확성을 증언(서명)합니다.
    • Epoch의 첫 번째 Slot을 Check Point라고 합니다.
    • Validator은 특히 두 개의 연속된 Epoch Check Point에 대해 증언합니다.
    • Deposit 총액의 2/3에 해당하는 Validator의 증언을 받았다면
      • 최신 Check Point는 정당화됩니다.
      • 그 이전 Check Point가 확정됩니다 (이전 페이퍼는 최종 버전이 됩니다).
  • 동기화 위원회
    • 256 Epoch마다 512명의 Validator이 위원회에 선정되어 해당 Slot의 지면에 대한 증언을 하게 됩니다.
    • 이는 Validator가 아닌 사람들이 지면의 정확성을 검토하는 데 도움이 됩니다.

Beaker / 신문 / 기계식 계산기 Model (5)

 

 

 

  • Epoch 내 지면 열에 분기가 생기면?
    • 위의 내용을 모두가 마음대로 하기 때문에 분기가 발생할 수 있습니다.
      • 예를 들어, 어떤 Validator은 앞의 Slot에서 Block이 제안되지 않았다고 생각할 수 있습니다.
    • 이 경우, Deposit 환산으로 가장 많은 증언을 얻은 이력을 채택합니다.
      (변형된 나카모토 Consensus)
  • 몰수와 추방
    • 동기화 위원회에 선정되었으나 응답하지 않으면 Deposit을 몰수합니다.
    • Check Point에 증언하지 않으면 Deposit을 몰수합니다.
    • 5 Epoch 이상 확정에 실패한 경우, Majority 측에 증언하지 않은 Validator 등의 Deposit을 몰수합니다
      (그 동안 Majority 측에도 보상 없음).
      • 이렇게 함으로써 Majority 측이 2/3 이상을 얻기가 더 쉬워질 것으로 기대합니다.
    • 같은 Slot에 여러 개의 지면을 제안하거나, 이력 조작을 시도하거나, 이중 투표를 하면,
      Deposit 몰수 후 (36일 후) 추방합니다.
      • 동시에 악행을 저지른 Validator가 여러 명일 경우, 공모로 간주하여 심하게 몰수할 것입니다.

Beaker / 신문 / 기계식 계산기 Model (6)

 

 

 

  • 보상
    • Validator으로서 성실하게 일하면 Deposit이 증가함에 따라 받을 수 있는 보상은
      자신의 Deposit에 비례하며, 모두의 Deposit 총액의 제곱근에 반비례합니다.
    • 증언이 늦어질수록 보상 금액이 감소합니다.
    • Epoch마다 보상을 받을 수 있습니다.
  • (일반적인) 추첨이나 위원회 선출 방식 (이것은 기존 Metaphor입니다)
    • 난수를 생성하기 위해 개념적인 DAO (RANDAO)를 사용합니다.
    • 이것은 계산기의 Memory에 있는 Card(Trump)의 Deck입니다.
    • 지면을 제안하는 Validator는 제안할 때 이 Deck을 한 번 Shuffle하여 제안합니다.
      • 실제로는 Epock 번호에 기반한 Data에 대한 서명의 Digest와 기존 값의 배타적 논리 합을 취합니다.
    • 지면이 나올 때마다 한 번씩 Shuffle을 하기 때문에, Deck에 충분한 헛소리가 쌓이게 됩니다.
      • 게다가 모두가 같은 Deck을 보고 있기 때문에 헛소리임에도 불구하고 결정적입니다.
      • 각 Epoch 마지막 시점의 Deck을 사용하여 2 Epoch 후의 제안자와 위원회 Member를 결정합니다.

Beaker / 신문 / 기계식 계산기 Model (7)

 

 

 

  • 상태 변화를 계산하는 계산기 자원량을 Gas라고 한다,
  • 이용자는 Gas에 가격을 매겨 ETH로 구입 (Gas 사용료)
    • ⇒ 무한 Loop를 피할 수 있다.
    • 기본요금으로 혼잡을 제어할 수 있다.
    • ETH의 가치의 원천이 된다.
  • Gasoline와 Engine의 은유
    • Engine = Ethereum Virtual Machine (EVM)
  • Deposit 총액의 2/3 ETH를 모두 매입하는 것이 어려운 것에 의존
    ⇒ ETH의 시장가격이 높아야 함

Ethereum의 구조

 

 


 

쉽게 말해 '은행 등 금융기관을 Bypass하는 금융'(DeFi : Decentralized Finance)

  • '유언장 Test'를 통과하는 원장 기술이 있다고 가정하면
    • ⇒ 자기주권성, 검열 저항성, 장애 저항성, 변조 저항성을 가짐
  • 그 원장에 기록한 Program Code가 있고
    • ⇒ 'Smart Contract'라고 불림
  • 그 Code로 금융 Application을 작동시킨다.
    • ⇒ 진정한 Code(Bug가 없다고는 말하지 않음)가 작동하고 있다는 것이 증명된다.
  • 예시
    • BTC, ETH 등의 암호화폐 (Native 통화는 원장과 통합되어 있음)
    • 분산 거래소(DEX)(예: Uniswap), Stable Coin(예: MakerDAO/DAI)
    • NFT (Non-Fungible Token) (DeFi에 포함되지 않는 개념도 있음) 및 그 응용 등

DeFi(분산Finance)

 

 

  • 특징
    • Block의 검증 과정에서 Program을 실행하고 그 결과를 상태에 반영한다.
      • 복수의 검증자가 중복으로 실행 (확인 산술을 함)
      • Blockchain 안에서 폐쇄적
    • Ethereum의 체계 안에서 정합적
  • 과제
    • Program 내부에서 입출력 Command을 내릴 수 없음
      • 외부 Actor 이외의 외부 세계의 영향을 받거나 (ex. Censor의 Data를 직접 읽어올 수 없음)
      • 외부 세계에 직접적으로 영향을 줄 수 없음 (ex. Motor를 돌리라는 Command을 보낼 수 없음)
    • 시계도 읽을 수 없으므로 주기적 기동 등을 사용하여
      자발적으로 동작하는 Program도 움직일 수 없다.
      ⇒ 외부 세계와 함께 움직이는 시스템에는 반드시 검증 불가능한 부분이 있다 → 간판에 거짓이 있다.

 

특징과 과제


 

 

  • 화폐는 Blockchain이 가장 잘하는 응용 분야입니다.
  • 그 응용력을 폭넓게 개방하는 추상화 Class

Token의 설계

 

 

 

ERC-20 Token

  • 그 외 Option으로 name/이름, symbol/단위·기호, decimals/소숫점 이하 몇 자리
  • approve는 다른 User로부터의 인출을 허용하고, allowance는 그 Limit를 반환한다.
  • ERC-777 (오발송 방지 기능 포함)으로 Update 되었으나, 적절한 구현이 어려워 권장하지 않는다.

 

 

 

  • ERC-20은 말하자면 '추상 Class' ← 구현이 들어있지 않기 때문에 그대로 구체화(Deploy)할 수 없다.
    • Token형 Object에 대해 가능한 '조작(Interface)' 정의
  • ⇒ ERC-20 Object를 상정하여 만들어진 소프트웨어
    (조작하는 대상을 ERC-20 Object라고 가정하고 작성된 Software)는,
    ERC-20을 준수하는 모든 Token에 대해 동작한다.
    • Object 지향의 추상 Date형과 Class 상속의 효과.
  • ⇒ 개발 효율성과 적용성이 크게 향상된다.

ERC-20이 초래한 Impact

 

  • 대체 가능 (fungible)
    • ERC-20 → ERC-223 (draft) or ERC-777 (표준형 Token)(결국 권장되지 않음)
  • 대체 불가능 (non-fungible)
    • ERC-721
    • 실물자산, 가상자산, 부채(음의 가치의 Asset) 등을 표현할 수 있음 (Trust필요)
  • Multi Token 표준
    • ERC-1155 (여러 종류의 Token을 하나의 Contract로 처리 가능)
    • ERC-3525 (ERC-721 상위 호환, SLOT을 정의하고 동일 SLOT 내에서 분할 및 Merge 가능)

Token 유형

 

 

 

Full Stack 응용의 정리

 

 


 

  • 실제로 Digital 화폐로 자산을 구매할 때 어떤 어려움이 있을까요?

Demonstration

 

 

 

  • 요구
    • Asset 및 요금 탈취를 방지하기 위해
    • Asset과 Digital 화폐의 transfer가 동시에 이루어지도록 합니다.
      • 각각 Escrow Service에 예치하고, 모두 모이면 거래를 실행할 수 있습니다.
      • 일치하지 않으면 판매자나 구매자 모두 취소할 수 있습니다.
  • 설계 정책
    • 일회용 Escrow Contract를 준비합니다.
      • 구매 통화, 구매자, Asset, 판매자, 가격을 Deploy할 때 지정합니다.
      • settle, retrieve asset, retrieve token의 세 가지 작업을 제공합니다.

요구와 설계방침

 

공중약속고정장치(참고로 화폐는 '정량화된 의무'(부채론))

  • 정의된 공중은 참가자들의 힘으로 유지 (특정 관리자가 없을 수도 있음)
  • 약속 / Asset은 권한이 있는 참여자만 조작할 수 있다.
  • 정의된 공중이 존속하는 한 약속/Asset도 존속할 수 있다.

 

 

 

예제 - 자동 Escrow에 의한 토지의 매매

  • 1. 토지나 대금의 도피를 막기 위해 매매계약서를 공중에 고정 (어느 쪽이든 내용 확인 가능)
  • 2. 토지 권리 및 대금을 매매계약서에 예치한다(마음이 바뀌면 되찾을 수 있다).
  • 3. 실행 (이것도 어느 쪽이든 가능) 그러면 조건이 맞으면 토지 권리와 대금이 동시에 이전된다.

 

 

 

 

  • token Project (ERC-20 준수)을 생성합니다.
    $ brownie bake token
  • Saple Code를 GitHub에서 git clone 한다.
    $ git clone https://github.com/ks91/sample-smart-contracts.git
  • sample-smart-contracts Directory 아래에 있는 contracts, scripts 및 tests 파일군을 
    token Project의 동일한 Directory에 각각 Copy합니다. 
    • Token과 함께 실행합니다.

Sample Code

 

 

 

OneTimeEscrow의 Settle()

  • settle() 부분만 소개합니다.
  • 요금와 Asset이 모두 자신에게 예치된 경우에만 가능합니다,
    • 판매자에게 요금을, 구매자에게 Asset을 transfer 합니다.
  • Compile합니다.
    $ brownie compile

 

 

Test Code (1)

Token과 Asset에 대한 Contract을 Deploy하고 있습니다.

 

 

 

 

 

 

  • accounts[0]/seller 에서 accounts[1]/buyer 에 300 Coin을 보냈습니다.
    • 구매자로서 300 Coin을 지불하는 TX를 투입하기 위해서 입니다
  • Escrow Contract를 Deploy하고 있습니다.
    • 구매자는 buyer, 판매자는 seller, 가격은 300 Coin입니다.
  • bake 된 Token의 Sample 인수를 그대로 사용하고 있기 때문에,
    300 Coin이라는 것은 ETH에서 말하는 wei와 같은 작은 단위입니다.

Test Code (2)

 

 

Test Code (3)

  • buyer (구매자)가 300 Coin을 Escrow에 예치했습니다,
  • seller (판매자)가 Escrow에 Asset을 예치하고 있습니다.

 

 

Test Code (4)

  • settle()을 호출하여 거래를 성사시키고 있습니다.
    • 이 Code에서는 seller가 호출하고 있지만, 어느 쪽에서 호출해도 OK입니다.

 

 

 

반응형