8) Smart Contracts and Chaincode

원서 : https://hyperledger-fabric.readthedocs.io/en/release-1.4/smartcontract/smartcontract.html

• (What's) Smart Contracts and Chaincode
  
  • Hyperledger Fabric 개발자 입장에서는 smart-contract(chaincode)가 가장 중요합니다. 비지니스적으로  ledger가 현재상태 및 히스토리 기록 이라면, smart-contract 앞으로 추가될 정보입니다. 일반적으로 chaincode는 각 administrator에 의해 배포되고, 시스템 전반적으로 다 쓰입니다. 자 그럼 smart-contract(chaincode)를 알아보아요.
• Smart contract
  
  • 사업자간 비지니스를 할때에는 일단 먼저 계약서를 쓰죠? 계약서에는 각종 용어, 데이터, 룰, 개념정의, 프로세스등이 명시 될것입니다. 바로 이런 계약서으로 사업자간 상호거래를 통제할수있는 '비지니스 model'이 완성 되는것 입니다.

  • 

    smart-contract는 chaincode로써 서로다른 organization간에 rule를 정의한것 입니다. application이 chaincode를 실행시켜, ledger에 반영될 transaction을 생성하는것이죠.

  • 블로체인을 활용하면, 계약서를 실행가능한 프로그램으로 만들수 있습니다. 이것이 바로 smart-contract입니다. 다양한 사업군에서 이 smart-contract을 사용 할 수 있으며, 자동 효율화에 아주 유용합니다. (예를들면, smart-contract을 통해서~ 새차 납품을 정해진 기간보증을 할수도있고 자금의 흐름을 자동적으로 향상시킬수도 있습니다.) 잘 와닿지 않는다고요? 그냥 사람이 계약을 진행하는것 보다... 무조건 효율적이라는 것만 기억하세요! (복덕방 계약를 그냥 직방서버가 알아서 다 해준다고 상상해 봐요)
• Terminology
  
  • Hyperledger Fabric에서 smart-contract 와 chaincode는 똑같은 의미 입니다. smart-contract는 '비지니스 데이터'의 lifecycle를 제어하는 'transaction logic' 입니다. 이건이 blockchain-network에 chaincode형태로 배포되는것 입니다. 
• Ledger
  
  • 단순히 말하자면, blockchain이란 ledge를 업데이트 하는 transaction을 불변하게 기록하는 방식으로 볼수있습니다. smart-contract는 프로그래밍 적으로 2가지 측면으로 접근할수 있습니다. 바로, blockchain(모든 transaction 히스토리를 불변하게 기록) 과 world-state(현재의 상태 캐시값) 입니다. smart-contract는 주로 world-state를 put, get, delete 하고~ 뭐 blockchain 쿼리도 할수있습니다.
  • 물론 다양한 smart-contract API는 다 제공이 됩니다. 참 좋죠?
• Development
  
  • 하나의 chaincode에서 여러게의 smart-contract를 정의할 수 있고, blockchain-network 배포되면~ organization들에서 바로 쓸수 있다는것을 의미합니다.
  • 더 나아가, 하나의 smart-contract은 여러게의 transaction을 정의 할수있습니다.
  • 개발자로 각종 다양한 비지니스를 프로그래밍 할수있고, java, golang, js 가 지원됩니다.
• Endorsement
  
  • 모든 chaincode에는 그 smart-contract에 적용되는 각각의 '보증정책'을 정의 할 수 있습니다. '보증정책'은 해당 smart-contract의 transaction을 반영하기위해서~ 보증 받아야할 blockchain-network의 organization 이라고 보시면 됩니다.
  • (보증 합의 방식에 관해서는 굳이 더 설명 안하겠습니다.)
  • Hyperledger Fabric '보증정책'은 이더리움, 비트코딩 등과 좀 다릅니다. 이런류의 blockchain-network에서는 아무 node에서나 transaction 검증을 합니다. 반면 Hyperledger Fabric은 좀더 실세계의 비지니스 모델을 반영 했는데, transaction 는 반듯이 신뢰 할 수있는 organization에게 검증받아야 합니다. 예를들면 정부기관이 여러가지 신원확인을 해주듯이~ 특정 organization의 도장을 받아야 하는식입니다.
  • 끝으로 '보증정책'는 Hyperledger Fabric의 여러 정책중 하나일 뿐입니다. '단순쿼리', '업데이트', 'node 추가제거' 등을 하는 다른정책들도 있습니다. 일반적으로 정책이란 organization들의 동의를 얻어서 세워지게 되는것이고... 정책을 변경하기위한 정책도 또한, 고급주체로 배우실수있습니다.
• Valid transactions
  
  • smart-contract는 blockchain-network의 organization의 peer-node에서 실행된다. smart-contract는 'transaction proposal' 이라 불리는 파라미터를 가지고, ledger를 R/W하는 프로그램 로직을 처리한다.
  • world-state의 변경은 'transaction proposal response'으로 되어짐니다. 참고로 'transaction proposal response'는 read-set 및 write-set 둘다 있습니다. 또한 smart-contract가 실행 되었다고, world-state에 반영되는것 아닙니다.

  • 

    모든 transaction은 identifier 및 proposal 및 organization서명response 를 가지고 있습니다. 일단 모든 transaction은 검증값 상관없이blockchain에 기록은 됩니다.

  • 위 그림의 "car transfer"를 보면, transaction의 id값은 t3이고, input은 '{CAR1, ORG1, ORG2}' output은 '{CAR1.owner=ORG1, CAR1.owner=ORG2}' 입니다. (CAR1의 주인이 1에서->2으로 바뀜) input의 서명은 ORG1의 application 으로 되어있고, output의 서명은 '보증 정책'에 따라 ORG1 및 ORG2 둘다 되어있습니다. 서명은 각자의 private key으로 되는거 아시죠? 이렇기 때문에 blockchain-network의 모든이에 동의여부를 판단 할수있는것 입니다.
  • 또 transaction는 모든  blockchain-network의 peer에게 분배된 이후, 두번에 걸쳐서 검증되어 집니다. 첫번째는 해당 transaction이 '보증 정책'에 따라 충분한 organization들로부터 서명을 받았는지? 확인하는것 입니다. 두번쨰는 현재의 world-state값 과 ('endorsing peer' 서명받은 당시) transaction의 'read-set'값이 대응되는지? 확인하는것 입니다. (고사이에 값 상태변화가 없는지? 확인 한다는 의미)
  • 이렇게 두번에 걸친 테스트를 통과하면, 검증된 transaction으로 표시됩니다. 물론 모든 transaction 검증결과 상관없이 blockchain 히스토리에는 기록 됩니다. (ledger는 히스토리 및 world-state으로 구성되있는거? 다 아시죠?)
• Channels
  
  • Hyperledger Fabric에서는 channel을 통해서, organization이 복수개의 blockchain-network에 참여 할 수 있습니다. 바로 channel을 통해 망을 공유할수있고, 데이터의 프라이버시를 지킬수있게 됩니다. 그러기 때문에 organization은 각 사업부 별로 관리망을 분리하기도 용이해지는것 입니다. (오직 거대한 blockchain-network망 하나로 모든것을 하는게 아니라, 사업별로 각각의 망을 구축) 

  • 

    channel은 organization간 독립적인 통신망을 제공하는것 이고, 각각의 channel에 chaincode가 각각 인스턴티 되고~ '보증정책'도 각각 정해짐.

  • organization의 administrator는 chaincode을 인스턴티 할 때, '보증정책'을 정 할 수 있습니다. '보증정책'은 당연 모든 smart-contract에게 동일하게 적용이 되겠죠? 물론 서로다른 channel의 smart-contract은 '보증정책'이 서로다르게 정해질 수도 있겠죠.
• Intercommunication
  • 특정 smart-contract는 동일channel 및 타channel 의 다른 smart-contract를 모두 호출 할 수 있습니다. 이런방식으로 'smart-contract namespace'에 제약이있어도, world-state 데이터를 R/W 할수있습니다. 이런 상호통신은 'chaincode namespace' 시간에 자세히 보아요.
• System chaincode
  
  • chaincode으로 개발된 smart-contract는 (blockchain-network의 organization 동의하에~) '비지니스 rule'을 정하는것 이라고 볼 수 있지만, chaincode로는 비지니스와 관련없는 시스템으로써의 low-level 프로그래밍도 할 수 있습니다. 이런 '시스템 chaincode' 종류와 그 약어도 한번 알아두면 좋겠죠?
    • Lifecycle system chaincode (LSCC) : 모든 peer에서 chaincode의 signing, install, instantiate, upgrad을 처리함.
    • Configuration system chaincode (CSCC) : 모든 peer에서 channel 설정(정책)을 처리함.
    • Query system chaincode (QSCC) : 모든 peer에서 ledger API (block query, transaction query)을 처리 합니다.
    • Endorsement system chaincode (ESCC) : 'endorsing peer'에서 transaction response 암호화 서명을 처리함.
    • Validation system chaincode (VSCC) : transaction의 '보증정책' 검증 및 'read-write 버젼' 검증을 합니다.
  • low-level 수준의 시스템 프로그래밍을 하는 개발자 분들은... administrator으로써 시스템 수정도 하실 수 있는것 입니다. 하지만... 생각만해도 무시무시한(?) 작업인 느낌! 딱 오시죠?ㅎㅎ Hyperledger Fabric에서 이렇식으로 '시스템 chaincode' 건드리다보면~ 타 peer들 과의 consensus 결함으로, 결과적으로 원치않은 'ledger fork'가 날 수 도 있겠죠? ㅎㄷㄷ

 

 

-끝-