[BlockChain/Hyperledger Fabric] 스마트 컨트랙트와 체인코드

yujeongkwon·2023년 8월 7일
0

BlockChain

목록 보기
2/10

스마트 컨트랙트

: 공통의 집합을 정의함.

  • 일반적인 용어, 데이터, 규칙, 개념 정의 및 프로세스

  • = 비지니스 모델 종합 -> 거래 당사자 간의 상호작용을 관리

  • 스마트 컨트렉트 : 실행 가능한 코드에서 서로 다른 조직의 규칙을 정의

    • world state에 포함되는 비지니스 객체의 생명주기를 컨트롤하는 트랜잭션을 정의
    • 체인코드로 정의됨
    • 다중 스마트 컨트렉트들은 같은 체인코드 내서 정의될 수 있음
    • 체인코드가 배포될 때, 모든 스마트 컨트랙트들은 어프리케이션에서 실행가능하다.
  • 애플리케이션 : 원장에 기록되는 트랜잭션을 생성하는 스마트 컨트랙트를 호출함.

  • 블록체인 네트워크 : 위 컨트랙틀르 실행 가능한 프로그램으로 전환해줌.
    스마트 컨트랙트


컨트랙트와 체인코드

  • vehicle의 체인코드에는 3개의 컨트랙트가 있음 : cars, boats, trucks
  • insurance의 체인코드에는 4개의 컨트랙트가 있음 : policy, liability, syndication, securitization
  • 컨트랙트 : 특정 비즈니스와 관련된 도인 특정 프로그램
    • 체인코드 : 관련 프로세스 그룹의 기술 컨테이너
      컨트렉트와 체인코드

Ledger

  • 가장 단순한 레벨에서 블록체인은 원장에 state를 업데이트하는 트랜잭션을 불변하게 기록
  • 스마트 컨트렉트가 접근하는 두 가지 원장의 조각
    – 블록체인 : 불변의 history를 기록하는 모든 트랜잭션들
    • world state : 해당 states의 현재 값의 캐시를 보유

스마트 컨트렉트

  • world state에서 state의 put, get, delete
  • 변경할 수 없는 트랜잭션의 블록체인 기록을 쿼리
    • get : 일반적으로 비즈니스 객체의 현재 상태에 대한 정보를 검색하는 쿼리
    • Put : world state 원장에 새 비즈니스 개체를 생성하거나 기존 비즈니스 개체를 수정
    • delete : 일반적으로 비즈니스 객체의 삭제를 나타내지만, 기록은 아님(?)..

Development

  • 스마트 계약은 애플리케이션 개발의 초점
  • 하나 이상의 스마트 계약은 단일 체인코드 내에서 정의될 수 있음.
  • 네트워크에 체인코드를 배포하면 해당 네트워크의 조직에서 모든 스마트 계약을 사용 가능
    • 즉, 관리자만 체인코드를 고려면됨.
    • 다른 모든 사람은 스마트 컨트렉트 측면에서 생각할 수 있습니다.
  • 스마트 계약의 핵심 :transaction정의.

  • ex) assetTransfer.js : 새 자산(asset)을 생성하는 스마트 계약 트랜잭션

    async CreateAsset(ctx, id, color, size, owner, appraisedValue) {
    const asset = {
    ID: id,
    Color: color,
    Size: size,
    Owner: owner,
    AppraisedValue: appraisedValue,
    };
    return ctx.stub.putState(id, Buffer.from(JSON.stringify(asset)));
    }


Endorsement

  • 모든 체인코드와 관련된 보증 정책은 그 안에 정의된 모든 스마트 컨트렉트에 적용
  • 보증 정책 : 주어진 스마트 컨트렉트에 의해 생성된 거래에 서명해야 하는 블록체인 네트워크의 조직 for 해당 거래가 유효하다고 선언
    • 모든 스마트 계약에는 관련된 보증 정책이 있음
    • 트랜잭션이 유효한 것으로 식별되기 전에 스마트 계약에 의해 생성된 트랜잭션을 승인해야 하는 조직을 식별
    • ex) 블록체인 네트워크에 참여하는 4개 조직 중 3개의 조직이 트랜잭션에 서명해야 유효한 것으로 인정
      -> 유효 여부에 관계X 모든 트랜잭션 분산 원장 추가 but, 유효한 트랜잭션만 world state를 업데이트
    • 아래 예에서 자동차를 양도하기 위한 스마트 계약 트랜잭션이 유효하려면 ORG1과 ORG2 모두에 의해 실행되고 서명되어야 함.
    • 트랜잭션은 네트워크에서 신뢰할 수 있는 조직에 의해 검증됨.
      • ex) 정부 기관에서 유효한 issueIdentity 거래에 서명하거나 자동차 구매자와 판매자 모두 자동차 양도 거래에 서명
    • 원장 질의, 업데이트 / 참가자 추가, 제거 등을 할 수 있는 사람을 식별하기 위해 다른 정책을 정의 가능
    • 일반적으로, 정책이 확정되지는 않았더라도 블록체인 네트워크의 조직 컨소시엄에서 사전에 합의해야함.
      - 물론 정책을 변경할 수 있는 규칙을 정의 가능 + 사용자 정의 보증 정책 규칙 정의 가능
      보증정책 스마트 컨트렉트 다이어 그램

Valid transactions

  • 스마트 컨트렉트는 블록체인 네트워크의 조직이 소유한 피어 노드에서 실행됨
  • 컨트랙트는 transaction proposal(제안) 이라는 일련의 입력 매개변수를 사용하고 이를 프로그램 로직와 함께 사용하여 원장을 읽고 씀.
  • world state에 대한 변경 사항은 '원래 상태' + '트랜잭션이 유효한 경우 기록될 새 상태' 둘 다를 가지는 읽기-쓰기 세트의 트랜잭션 제안 응답(트랜잭션 응답)으로 캡처됨.
  • 스마트 계약이 실행될 때 world state가 업데이트되지 않는다는 점에 유의
  • 일련의 조직에서 모든 트랜잭션에는 서명한 식별자, 제안 및 응답이 있음.
    - 유효 여부에 관계없이 모든 거래는 블록체인에 기록되지만 유효한 거래만 world state에 기여

ex 자동차 이체 거래

  • t3 : ORG1과 ORG2 사이의 자동차 환승에 대한 트랜잭션

    • 입력 : {CAR1, ORG1, ORG2}

    • 출력 : {CAR1.owner=ORG1, CAR1.owner=ORG2}
      => ORG1에서 ORG2로 소유자가 변경되었음을 나타내는 방법

      애플리케이션의 조직 ORG1에서 입력이 서명
      보증 정책 ORG1 및 ORG2로 식별된 두 조직에서 출력이 서명

    • 서명은 개인 키를 사용하여 생성

    • 네트워크의 모든 노드가 트랜잭션에 대해 동의, 네트워크의 모든 사람이 확인 가능

  • 트랜잭션 : 두 단계의 검증

    1. 보증 정책에 따라 충분한 조직에서 서명했는지 확인
    2. world state의 현재 값이 보증 피어 노드에 의해 서명되었을 때 트랜잭션의 읽기 세트와 일치하는지 확인
      즉, 중간에 업데이트가 없었는지 확인
    • 트랜잭션이 이 테스트를 모두 통과하면 유효한 것으로 표시됩니다.
  • 아래 예에서 t3은 유효한 트랜잭션이므로 CAR1의 소유자가 ORG2로 업데이트됨
    but, t4(표시되지 않음)는 유효하지 않은 트랜잭션이므로 원장에 기록되는 동안 world state가 업데이트되지 않았으며 CAR2는 ORG2의 소유로 남음.


Channels

  • 조직이 채널을 통해 여러 개의 개별 블록체인 네트워크에 동시에 참여 가능
  • 채널은 데이터 및 통신 프라이버시를 유지하면서 효율적인 인프라 공유를 제공
  • 조직이 서로 다른 상대방과 작업 트래픽을 분리하는 데 도움이 될 만큼 충분히 독립적
    + 필요할 때 독립적인 활동을 조정할 수 있도록 충분히 통합됨.
  • 일련의 조직 간에 완전히 분리된 통신 메커니즘
    • 체인코드 정의가 채널에 커밋될 때, 체인코드 내 모든 스마트 컨트렉트는 해당 채널의 애플리케이션에서 사용가능
  • 스마트 컨트렉트 코드가 조직 피어의 체인코드 패키지 내에 설치되는 동안 채널 구성원은 체인코드가 채널에 정의된 후에만 스마트 컨트렉트를 실행가능
  • 체인코드 정의 : 체인코드가 작동하는 방식을 제어하는 매개변수를 포함하는 구조체 (체인코드 이름, 버전 및 보증 정책)
    • 채널 구성원이 스마트 컨트렉트를 사용하여 채널에서 거래를 시작하기 전에 체인코드의 거버넌스에 동의하는 방법을 제공
      1. 각 채널 구성원은 조직에 대한 체인코드 정의를 승인하여 체인코드의 매개변수에 동의
    1. 충분한 수의 조직(기본적으로 대다수)이 동일한 체인코드 정의를 승인하면 정의가 채널에 커밋
    2. 체인코드 내부의 스마트 컨트렉트은 체인코드 정의에 지정된 보증 정책에 따라 채널 구성원이 실행
    • 보증 정책은 동일한 체인 코드 내에서 정의된 모든 스마트 계약에 동일하게 적용

ex

  • 아래 예에서 자동차 계약: VEHICLE 채널 / 보험 계약: INSURANCE 채널에 정의
  • car의 체인코드 정의는 ORG1과 ORG2가 유효한 것으로 간주되기 전에 트랜잭션에 서명하도록 요구하는 보증 정책을 지정
  • 보험 계약의 체인코드 정의는 트랜잭션을 승인하는 데 ORG3만 필요하다고 지정
  • ORG1은 VEHICLE 채널과 INSURANCE 네트워크의 두 네트워크에 참여하고 이 두 네트워크에서 ORG2 및 ORG3과의 활동을 조정 가능
  • ORG1과 ORG2는 모두 자동차 계약을 호출하는 트랜잭션을 승인하려고 한다.
    • 기본 정책에서는 대부분의 조직이 체인코드 정의를 승인 = 두 조직 모두 AND{ORG1,ORG2}의 보증 정책을 승인해야 함.
    • 그렇지 않으면 ORG1과 ORG2는 서로 다른 체인코드 정의를 승인 -> 커밋 불가
    • 이 프로세스는 자동차 스마트 계약의 트랜잭션이 두 조직의 승인을 받아야 함을 보장
      채널 체인코드 클래스 다이어그램

Intercommunication

  • 스마트 컨트렉트는 동일 또는 다른 채널에서 다른 스마트 계약을 호출 가능
    => 스마트 컨트렉트 네임스페이스로 인해 액세스할 수 없는 world state 데이터 read/write 가능

시스템 체인코드

  • 체인코드 내에 정의된 스마트 컨트렉트는 도메인 종속 규칙을 인코딩
  • 체인코드 내에 정의된 스마트 컨트렉트는 일련의 블록체인 조직 간에 합의된 비즈니스 프로세스에 대한 도메인 종속 규칙을 인코딩
  • 도메인 독립 시스템 상호 작용에 해당하는(=비즈니스 프로세스의 스마트 컨트렉트와 관련이 없는)
    하위 수준 프로그램 코드도 정의 가능

약어

  • _lifecycle : 모든 피어에서 실행되며 피어에 체인코드 설치, 조직에 대한 체인코드 정의 승인, 채널에 대한 체인코드 정의 커밋을 관리
  • 수명 주기 시스템 체인코드(LSCC) : Fabric의 1.x 릴리스에 대한 체인코드 수명 주기를 관리
    • 버전 낮아 ㄱㅊㄱㅊ
  • 구성 시스템 체인코드(CSCC) : 모든 피어에서 정책 업데이트와 같은 채널 구성에 대한 변경 사항을 처리
  • 쿼리 시스템 체인코드(QSCC) : 모든 피어에서 블록 쿼리, 트랜잭션 쿼리 등을 포함하는 원장 API를 제공
  • 보증 시스템 체인코드(ESCC) : 트랜잭션 응답에 암호로 서명하기 위해 동료를 보증
  • 유효성 검사 시스템 체인코드(VSCC) : 승인 정책 및 읽기-쓰기 세트 버전 관리를 확인하는 것을 포함하여 트랜잭션의 유효성을 검사

저수준 개발은 니멋대로 시스템 체인코드 수정 가능한데 굳이 필요해? 잘못 만지면 ㅈ댐!

출처 : Hyperledger fabic 공식 문서

profile
인생 살자.

0개의 댓글