[하이퍼레저 공식문서]Tutorials - Chaincode for Operators

Chaincode는 Go로 쓰여진 프로그램으로, Java와 같은 다른 프로그래밍 언어로 구현 가능합니다.  

ChainCode는 규정된 인터페이스를 실행합니다.

Chaincode는 Endorsing Peer Process와 격리된  안전한 Docker container에서 실행됩니다.

어플리케이션에서 제출한 트랜잭션을 통해, Chaincode는 원장 State 초기화 및 관리를 합니다.

 

Chaincode는 네트워크의 구성원으로부터 동의된 비즈니스 로직을 일반적으로 다루고, Smart Contract와 유사합니다.

Chaincode는 트랜잭션 제안에 업데이트 또는 쿼리를 하기 위해서 호출될 수 있습니다.

Chaincode에 의해 생성된 상태(state)의 범위는 해당 체인코드로 한정되며, 다른 체인코드에 의해서 직접 access할 수 없습니다.

그러나, 동일 네트워트 상에서 적절한 권한이 주어지면 체인 코드는 다른 체인코드를 호출하여 해당 상태(state) 상태에 acess할 수 있습니다.

 

 이번 섹션에선 블록체인 네트워크 Operator 관점에서 Chaincode를 알아볼 것입니다.

Operator 관점에선 Noah라고 불리는데, Noah의 관심점은, Chaincode의 생애주기 오퍼레이션에 중점을 둘 예정입니다;

이는 패키징, 설치, 인스턴스화 그리고 업그레이드 같은 블록체인 내부의 Chaincode의 operational한 생애주기입니다.

Chaincode 생애주기

Hyperledger Fabric API는 피어, Orderer 및 MSP와 같은 블록 체인 네트워크의 다양한 노드와의 상호 작용을 가능하게 합니다.

또한 인증 피어 노드에 Chaincode를 패키징, 설치, 인스턴스화 및 업그레이드 할 수있게 합니다. 

Hyperledger Fabric 언어 - 특히 SDK는,  Hypercode Fabric API의 특성을 추상화하여 응용 프로그램 개발을 용이하게하지만 Chaincode의 수명주기를 관리하는 데 사용할 수 있습니다. 또한 Hyperledger 패브릭 API는 CLI를 통해 직접 액세스 할 수 있습니다.  이 문서에서는 CLI를 사용합니다.

 

우리는 chaincode의 라이프 사이클을 관리 할 수있는 네 개의 명령 - package, install, instantiate, 및 upgrade 을 제공 합니다.

향후 버전에서는 Chaincode를 실제로 제거하지 않고도 Chaincode를 비활성화하고 다시 활성화하는 트랜잭션을  stop하고 start하는 트랜잭션을 추가할 것입니다. Chaincode가 성공적으로 설치되고 인스턴스화 된 후에는 Chaincode가 활성화되어 실행 중인 invoke 트랜잭션을 통해 트랜잭션을 처리 할 수 ​​있습니다. Chaincode는 설치 후 언제든지 업그레이드 할 수 있습니다.

패키징

chaincode 패키지는 다음 세 부분으로 구성됩니다.

• ChaincodeDeploymentSpec또는 CDS에 의해 정의 된 Chaincode , 
  CDS는 코드와 이름 및 버전과 같은 기타 속성의 chaincode 패키지를 정의합니다
• • Endorsement에 사용 된 동일한 정책에 의해 구문 적으로 설명 될 수 있고 Endorsement Policy에 설명되어있는 선택적 인스턴스 정책. 그리고
• Chaincode를 "소유하고있는"엔티티에 의한 일련의 서명.

서명은 다음과 같은 용도로 사용됩니다.

• Chaincode의 소유권을 확립하고,
• 패키지의 내용을 검증 할 수 있으며,
• 패키지 변조를 탐지 할 수 있습니다.

채널상의 Chaincode의 인스턴스 생성 트랜잭션 생성자는 Chaincode의 인스턴스화 정책에 대해 유효성이 검사됩니다.

패키지 만들기

Chaincode를 패키징하는 데는 두 가지 방법이 있습니다. 하나는 Chaincode의 소유자를 여러 명 갖고 싶어하므로 여러 ID로 서명 된 chaincode 패키지가 있어야합니다. 이 작업 과정에서는 초기에 서명 된 Chaincode 패키지 (a SignedCDS)를 생성해야하며, 서명 된 Chaincode 패키지 는 연속적으로 서명을 위해 다른 각 소유자에게 전달됩니다.

더 간단한 워크 플로우는 install 트랜잭션을 _ 행하는 노드의 ID의 서명 만 갖는 SignedCDS를 전개 할 때 사용 됩니다.

먼저 복잡한 사례를 다룰 것입니다. 그러나 아직 여러 소유자를 걱정할 필요가없는 경우 아래 Chaincode 설치 섹션으로 건너 뛸 수 있습니다 .

서명 된 chaincode 패키지를 만들려면 다음 명령을 사용하십시오.

peer chaincode package -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -v 0 -s -S -i "AND('OrgA.admin')" ccpack.out

이 -s옵션은 단순히 원시 CDS를 작성하는 것이 아니라 여러 소유자가 서명 할 수있는 패키지를 작성합니다.  이때 -s가 지정되면, -S 옵션은 다른 소유자가 로그인해야 위하여려고하는 경우에 지정해야합니다. 그렇지 않으면, 프로세스는 CDS뿐만 아니라 인스턴스화 정책 만 포함하는 SignedCDS를 작성합니다.

 

이 -S옵션은에있는 localMspid속성 의 값으로 식별되는 MSP를 사용하여 패키지에 서명하도록 프로세스에 지시합니다 core.yaml.

이 -S옵션은 선택 사항입니다. 그러나 패키지가 서명없이 작성된 경우, signpackage명령을 사용하여 다른 소유자가 서명 할 수 없습니다 .

선택적 -i옵션은 chaincode에 대한 인스턴스화 정책을 지정할 수있게합니다. 인스턴스화 정책은 승인 정책과 동일한 형식을 가지며 Chaincode를 인스턴스화 할 수있는 ID를 지정합니다. 위의 예에서 OrgA의 관리자 만이 chaincode를 인스턴스화 할 수 있습니다. 정책이 제공되지 않으면 기본 정책이 사용되며 피어의 MSP의 관리자 ID 만 Chaincode를 인스턴스화 할 수 있습니다.

패키지 서명

작성시 서명 된 Chaincode 패키지는 검사 및 서명을 위해 다른 소유자에게 양도 될 수 있습니다. 워크 플로는 Chaincode 패키지의 대역 외 서명을 지원합니다.

ChaincodeDeploymentSpec는 선택적으로 만들기 위해 공동 소유자에 의해 서명 될 수있습니다.

SignedChaincodeDeploymentSpec (또는 SignedCDS을). SignedCDS는 3 가지 요소를 포함합니다 :

1. CDS에는 Chaincode의 소스 코드, 이름 및 버전이 들어 있습니다.
2. Endorsement Policy로 표현 된 Chaincode의 인스턴스 정책.
3. 배서의 수단으로 정의 된 Chaincode 소유자 목록 .

노트

이 인증 정책은 일부 채널에서 Chaincode가 인스턴스화 될 때 적절한 MSP 보안 주체를 제공하기 위해 대역 외로 결정됩니다. 인스턴스화 정책이 지정되지 않은 경우 기본 정책은 채널의 모든 MSP 관리자입니다.

각 소유자는 ChaincodeDeploymentSpec을 해당 소유자의 신원 (예 : 인증서)과 결합하고 결합 된 결과에 서명함으로써 ChaincodeDeploymentSpec을 승인합니다.

Chaincode 소유자는 다음 명령을 사용하여 이전에 작성한 서명 된 패키지에 서명 할 수 있습니다.

peer chaincode signpackage ccpack.out signedccpack.out

여기서 ccpack.out, signedccpack.out는 입력 및 출력 패키지입니다. signedccpack.out로컬 MSP를 사용하여 서명 된 패키지에 대한 추가 서명을 포함합니다.

Chaincode 설치

install 트랜잭션은 ChaincodeDeploymentSpec 또는 CDS의 형태로 정리된 포맷으로 Chaincode 소스코드를 패키징 해줍니다.

그리고 피어 노드에 설치하고 해당 Chaincode를 실행할 것입니다.

노트

Chaincode를 실행할 채널의 각 엔드 피어 노드에 Chaincode를 설치해야합니다 .

단순히 ChaincodeDeploymentSpec이 주어진 Install API일 때, 기본적으로 인스턴스화 정책과 빈 오너 리스트를 가지게 될 것입니다.

노트

Chaincode는 Chaincode 소유 구성원의 피어 노드를 승인하는 경우에만 설치해야 네트워크의 다른 구성원으로부터 Chaincode 논리의 기밀성을 보호 할 수 있습니다. Chaincode가없는 멤버는 Chaincode의 트랜잭션을 승인 할 수 없습니다. 즉, Chaincode를 실행할 수 없습니다. 그러나 이들은 여전히 ​​장부에 대한 트랜잭션의 유효성을 검사하고 커밋 할 수 있습니다.

Chaincode를 설치하기 위해선, SignedProposal을 시스템 Chaincode 섹션에서 설명된 lifecycle system chaincode를 전송하십시오.

예를 들어, CLI를 사용하여 Simple Asset Chaincode 섹션에 설명 된 sacc 샘플 체인 코드 를 설치하려면 명령이 다음과 같아야합니다.

peer chaincode install -n asset_mgmt -v 1.0 -p sacc

CLI는 내부적으로 sacc에 SignedChaincodeDeploySpec을 만들고, 로컬 피어에 전송합니다. 이는 LSCC에서 install 메소드로 불립니다.

인자 -p는 chaincode의 경로를 의미하고, 유저의 GOPATH에 있어야합니다.(예:GOPATH/src/sacc) CLI 섹션을 확인하시면 커맨드 옵션에 완벽한 설명이 되어 있습니다.

피어에 설치하기 위해선, SignedProposal의 서명이 로컬 MSP 관리자 중 하나여야만 합니다.

인스턴스화

instantiate 트랜잭션이 호출 (LSCC)를 작성하고 채널에 chaincode를 초기화 할 수 있습니다. 이것은 Chaincode 채널 바인딩 프로세스입니다. Chaincode는 여러 채널에 바인딩되어 각 채널에서 개별적으로 독립적으로 작동 할 수 있습니다. 즉, Chaincode를 설치하고 인스턴스화 할 수있는 다른 채널 수에 관계없이 State는 트랜잭션이 제출 된 채널과 격리되어 있습니다.lifecycle System Chaincode

instantiate 트랜잭션 생성자는 SignedCDS에 포함 된 Chaincode의 인스턴스화 정책을 충족해야하며 채널 작성자로 채널 작성자로 구성되어야합니다. 채널의 보안이 악성 엔티티가 Chaincode를 배포하거나 구성원을 속여 언 바운드 채널에서 Chaincode를 실행하는 것을 방지하는 데 중요합니다.

예를 들어 기본 인스턴스화 정책은 모든 채널 MSP 관리자이므로 Chaincode 인스턴스 생성 트랜잭션 작성자는 채널 관리자의 구성원이어야합니다. 트랜잭션 제안서가 엔도 서에 도착하면 생성자의 서명을 인스턴스화 정책과 비교하여 검증합니다. 이 작업은 장부에 커밋하기 전에 트랜잭션 유효성 검사 중에 다시 수행됩니다.

또한 인스턴스 생성 트랜잭션은 채널에서 해당 Chaincode에 대한 Endorsement Policy를 설정합니다. Endorsement Policy는 채널 구성원이 승인 한 트랜잭션 결과에 대한 증명 요구 사항을 설명합니다.

예를 들어, 인스턴스화 CLI를 사용하여 SACC chaincode와 함께 State를 john과 0으로 초기화하고, 명령은 다음과 같습니다

peer chaincode instantiate -n sacc -v 1.0 -c '{"Args":["john","0"]}' -P "OR ('Org1.member','Org2.member')"

노트

Endorsement Policy에 유의하십시오 .이 경우 모든 트랜잭션이 sacc 할 수 있도록 Org1 또는 Org2 구성원의 Endorsement가 필요합니다 . 즉, Org1 또는 Org2는 유효한 트랜잭션이되도록 sacc 에서  를 실행 한 결과에 서명해야 합니다.

성공적으로 인스턴스화 된 후에는 Chaincode가 채널의 활성 State가되며 ENDORSER_TRANSACTION 유형의 모든 트랜잭션 제안을 처리 할 준비가됩니다 . 트랜잭션은 Endorsement 피어에 도착하면서 동시에 처리됩니다.

업그레이드

체인 코드는 SignedCDS의 일부 버전을 변경하여 언제든지 업그레이드 할 수 있습니다. 소유자 및 인스턴스 정책과 같은 다른 부분은 선택 사항입니다. 그러나 체인 코드 이름은 동일해야합니다. 그렇지 않으면 완전히 다른 체인 코드로 간주됩니다.

업그레이드하기 전에 새 버전의 체인 코드를 필요한 endorser에 설치해야합니다. 업그레이드는 체인 코드의 새 버전을 채널에 바인드하는 인스턴스화 트랜잭션과 유사한 트랜잭션입니다. 체인 코드의 이전 버전에 바인딩 된 다른 채널은 여전히 ​​이전 버전과 함께 실행됩니다. 즉, upgrade트랜잭션은 한 번에 하나의 채널 (트랜잭션이 제출되는 채널)에만 영향을줍니다.

노트

체인 코드의 여러 버전이 동시에 활성화 될 수 있으므로 업그레이드 프로세스가 자동으로 이전 버전을 제거하지 않으므로 사용자는 당분간이를 관리해야합니다.

instantiate트랜잭션 과의 미묘한 차이점이 있습니다. upgrade트랜잭션은 새 정책 (지정된 경우)이 아닌 현재 체인 코드 인스턴스화 정책에 대해 검사됩니다. 이것은 현재 인스턴스화 정책에 지정된 기존 구성원 만이 체인 코드를 업그레이드 할 수 있도록하기위한 것입니다.

노트

업그레이드 중에 chaincode Init함수가 호출되어 데이터 관련 업데이트를 수행하거나 다시 초기화하므로 체인 코드를 업그레이드 할 때 State를 다시 설정하지 않도록주의해야합니다.

중지 및 시작

stop 및 start라이프 사이클 트랜잭션은 아직 구현되지 않았습니다. 그러나 각 endorsers에서 chaincode 컨테이너와 SignedCDS 패키지를 제거하여 체인 코드를 수동으로 중지 할 수 있습니다.  이것은 인증 피어 노드가 실행중인 각 호스트 또는 가상 시스템에서 체인 코드의 컨테이너를 삭제 한 다음 각 인증 피어 노드에서 SignedCDS를 삭제하여 수행됩니다.

참고 : 피어 노드에서 CDS를 삭제하려면 먼저 피어 노드의 컨테이너에 들어가야합니다. 이를 수행 할 수있는 유틸리티 스크립트를 제공해야합니다.

docker rm -f <container id>
rm /var/hyperledger/production/chaincodes/<ccname>:<ccversion>

Stop은 업그레이드를하기 전에 모든 피어의 채널에서 체인 코드를 중지 할 수있는 제어 된 방식으로 업그레이드를 수행하는 워크 플로에서 유용합니다.

CLI

 참고 : 우리는 Hyperledger Fabric 바이너리 용 플랫폼 특정 peer 바이너리를 배포 할 필요성을 평가하고 있습니다. 당분간, 실행중인 도커 컨테이너에서 명령을 간단히 호출 할 수 있습니다.

현재 사용 가능한 CLI 명령을 보려면 실행중인 fabric-peerDocker 컨테이너 에서 다음 명령을 실행하십시오 .

docker run -it hyperledger/fabric-peer bash 
# peer chaincode --help

아래 예제와 비슷한 출력을 보여줍니다 :

Usage:
  peer chaincode [command]

Available Commands:
  install     Package the specified chaincode into a deployment spec and save it on the peer's path.
  instantiate Deploy the specified chaincode to the network.
  invoke      Invoke the specified chaincode.
  list        Get the instantiated chaincodes on a channel or installed chaincodes on a peer.
  package     Package the specified chaincode into a deployment spec.
  query       Query using the specified chaincode.
  signpackage Sign the specified chaincode package
  upgrade     Upgrade chaincode.

Flags:
      --cafile string      Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
  -h, --help               help for chaincode
  -o, --orderer string     Ordering service endpoint
      --tls                Use TLS when communicating with the orderer endpoint
      --transient string   Transient map of arguments in JSON encoding

Global Flags:
      --logging-level string       Default logging level and overrides, see core.yaml for full syntax
      --test.coverprofile string   Done (default "coverage.cov")
  -v, --version

Use "peer chaincode [command] --help" for more information about a command.

스크립트 응용 프로그램에서의 사용을 용이하게하기 위해 peer명령은 명령 실패시 항상 0이 아닌 리턴 코드를 생성합니다.

체인 코드 명령의 예 :

peer chaincode install -n mycc -v 0 -p path/to/my/chaincode/v0
peer chaincode instantiate -n mycc -v 0 -c '{"Args":["a", "b", "c"]}' -C mychannel
peer chaincode install -n mycc -v 1 -p path/to/my/chaincode/v1
peer chaincode upgrade -n mycc -v 1 -c '{"Args":["d", "e", "f"]}' -C mychannel
peer chaincode query -C mychannel -n mycc -c '{"Args":["query","e"]}'
peer chaincode invoke -o orderer.example.com:7050  --tls --cafile $ORDERER_CA -C mychannel -n mycc -c '{"Args":["invoke","a","b","10"]}'

시스템 체인 코드

시스템 체인 코드는 일반적인 체인 코드와 같은 격리 된 컨테이너가 아닌 피어 프로세스 내에서 실행된다는 점을 제외하고는 동일한 프로그래밍 모델을 사용합니다. 따라서 시스템 체인 코드는 피어 실행 파일에 내장되어 있으며 위에서 설명한 동일한 수명주기를 따르지 않습니다. 특히 설치 , 인스턴스화 및 업그레이드 는 시스템 체인 코드에 적용되지 않습니다.

시스템 체인 코드의 목적은 피어와 체인 코드 간 gRPC 통신 비용을 단축하고 관리 유연성을 절충하는 것입니다. 예를 들어, 시스템 체인 코드는 피어 이진 파일로만 업그레이드 할 수 있습니다. 또한 컴파일 된 매개 변수 의 고정 세트로 등록해야하며 Endorsement Policy 또는 Endorsement Policy 기능이 없습니다.

시스템 체인 코드는 Hyperbridger Fabric에서 시스템 통합 자에 의해 적절하게 대체되거나 수정 될 수 있도록 여러 시스템 동작을 구현하는 데 사용됩니다.

시스템 체인 코드의 현재 목록 :

1. LSCC Lifecycle 시스템 체인 코드는 위에서 설명한 라이프 사이클 요청을 처리합니다.
2. CSCC 구성 시스템 체인 코드는 피어 측의 채널 구성을 처리합니다.
3. QSCC 쿼리 시스템 체인 코드는 블록 및 트랜잭션 가져 오기와 같은 원장 쿼리 API를 제공합니다.
4. ESCC 인증 시스템 체인 코드는 트랜잭션 제안 제안서에 서명함으로써 Endorsement를 처리합니다.
5. VSCC 유효성 검사 시스템 체인 코드는 Endorsement Policy 및 다중 버전 동시성 제어 검사와 같은 트랜잭션 유효성 검사를 처리합니다.

이러한 시스템 체인 코드, 특히 LSCC, ESCC 및 VSCC가 주 트랜잭션 실행 경로에 있으므로 수정 또는 교체 할 때는주의해야합니다. 

VSCC가 장부에 커밋하기 전에 블록의 유효성을 검사 할 때 채널의 모든 피어가 원장 분기 (비 결정 성)를 피하기 위해 동일한 유효성 검사를 계산하는 것이 중요합니다. 

따라서 VSCC가 수정되거나 대체 된 경우 특별한 주의가 필요합니다.

출처 : http://hyperledger-fabric.readthedocs.io/en/release-1.1/chaincode4noah.html