byfn 2.0 시작하기

 

이글은 hyperledger 공식문서를 번역한 문서입니다.
https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#want-to-run-it-now

 

first network 빌드하기

* byfn은 depreated될것입니다. 기본 네트워크 배포를 하려면, test-network부분을 확인하기 바랍니다.

만약 페브릭을 배포할 거라면, Deploying a production network를 참조하세요.

 

BYFN 시나리오 제공합니다. 각각 두개의 피어를 가진 두개의 Org로 구성된 네트워크로 구성됩니다. 이는 기본적으로 Raft 알고리즘 기반 오더링 서비스로 배포될 것입니다.

 

선결요건 설치

시작에 앞서, 기본적인 선결요건이 갖춰져 있는지 확인해야됩니다.

fabric-samples에는 많은 샘플들이 포함되어 있습니다. 우리는 이 디렉토리에서 first-netwrok 샘플을 사용할 것입니다.

 

기본적으로 두 개의 다른 조직을 대표하는 4개의 피어로 구성되어 있는 하이퍼레저 패브릭 네트워크와 Raft 오더러 서비스를 빠르게 부팅하기 위해 이러한 도커 이미지를 활용하는 스크립트 — byfn.sh를 제공합니다. 또 피어를 채널에 가입시키는 스크립트를 실행하는 컨테이너를 가동하고, 체인코드를 배치하고, 배포된 체인코드에 대해 거래 실행을 도와줍니다.

 

네트워크 구성하기

./byfn.sh generate

이 첫 번째 단계는 우리의 다양한 네트워크 실체에 대한 모든 인증서와 키, 오더 서비스를 시작하는 데 사용되는 제네시스 블록, 그리고 채널을 구성하는 데 필요한 구성 트랜잭션의 컬렉션을 생성합니다.

 

네트워크 올리기

./byfn.sh up

위의 명령은 Go 체인코드 이미지를 컴파일하고 해당 컨테이너를 띄웁니다.

Go는 기본 체인코드 언어지만, 아래와 같이 Node.js와 Java 체인코드에 대한 지원도 있습니다.

./byfn.sh up -l javascript

./byfn.sh up -l java

위의 두 명령을 모두 실행하면 안됩니다. 네트워크를 무너뜨리고 재생성하지 않는 한 오직 하나의 언어만이 사용됩니다.

Starting for channel 'mychannel' with CLI timeout of '10' seconds and CLI delay of '3' seconds
Continue? [Y/n]
proceeding ...
Creating network "net_byfn" with the default driver
Creating peer0.org1.example.com
Creating peer1.org1.example.com
Creating peer0.org2.example.com
Creating orderer.example.com
Creating peer1.org2.example.com
Creating cli


 ____    _____      _      ____    _____
/ ___|  |_   _|    / \    |  _ \  |_   _|
\___ \    | |     / _ \   | |_) |   | |
 ___) |   | |    / ___ \  |  _ <    | |
|____/    |_|   /_/   \_\ |_| \_\   |_|

Channel name : mychannel
Creating channel...

여기서부터 로그가 쭈욱 이어지다가 모든 컨테이너가 시작되고, 완전한 엔드 투 엔드 애플리케이션 시나리오가 실행됩니다. 만약, 성공적으로 완료되면 터미널 창에서 다음 사항이 나옵니다.

Query Result: 90
2017-05-16 17:08:15.158 UTC [main] main -> INFO 008 Exiting.....
===================== Query successful on peer1.org2 on channel 'mychannel' =====================

===================== All GOOD, BYFN execution completed =====================


 _____   _   _   ____
| ____| | \ | | |  _ \
|  _|   |  \| | | | | |
| |___  | |\  | | |_| |
|_____| |_| \_| |____/

이 로그를 스크롤하여 다양한 트랜잭션을 볼 수 있습니다. 만약 이 결과를 얻지 못한다면,

Troubleshooting 섹션으로 뛰어 내려가서 무엇이 잘못되었는지 알아내는 데 도움을 줄 수 있는지 알아봅니다.

 

네트워크 내리기

./byfn.sh down

 

Crypto 생성기(Cryptogen)

다양한 네트워크 엔티티를 위한 암호 자료(x509 인증서와 서명키)를 생성하기 위해 암호화 툴을 사용할 것입니다. 이러한 인증서는 ID를 대표하며, 당사 기관이 통신하고 거래할 때 서명/검증 인증이 이루어지도록 합니다.

 

어떻게 동작하는가?

bin폴더 내에 cryptogen

 

crypto-config.yaml

 

 

Cryptogen은 crypto-config.yaml이라는 파일을 사용하는데, 이 파일은 네트워크 위상을 포함하고 Org에 속해있는 컴포넌트와 Org의 모든 인증서와 키의 세트를 생성할 수 있게 해주는 파일입니다. 각 Org에는 고유의 루트 인증서(ca-cert)가 제공되는데, 이것은 특정한 컴포넌트(피어와 오더러)를 해당 Org에 바인딩됩니다. 각 Org에 고유한 CA인증서를 할당함으로써, 우리는 참여 멤버가 자체 인증 기관(CA)을 사용하는 일반적인 네트워크를 모방합니다. 하이퍼레저 패브릭 내의 거래와 통신은 엔티티의 개인 키(키저장소)에 의해 서명된 다음 공개 키(서명)를 통해 검증됩니다.

# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
 
# ---------------------------------------------------------------------------
# "OrdererOrgs" - Definition of organizations managing orderer nodes
# ---------------------------------------------------------------------------
OrdererOrgs:
  # ---------------------------------------------------------------------------
  # Orderer
  # ---------------------------------------------------------------------------
  - Name: Orderer
    Domain: example.com
    # ---------------------------------------------------------------------------
    # "Specs" - See PeerOrgs below for complete description
    # ---------------------------------------------------------------------------
    Specs:
      - Hostname: orderer
      - Hostname: orderer2
      - Hostname: orderer3
      - Hostname: orderer4
      - Hostname: orderer5
 
# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
  # ---------------------------------------------------------------------------
  # Org1
  # ---------------------------------------------------------------------------
  - Name: Org1
    Domain: org1.example.com
    EnableNodeOUs: true
    # ---------------------------------------------------------------------------
    # "Specs"
    # ---------------------------------------------------------------------------
    # Uncomment this section to enable the explicit definition of hosts in your
    # configuration.  Most users will want to use Template, below
    #
    # Specs is an array of Spec entries.  Each Spec entry consists of two fields:
    #   - Hostname:   (Required) The desired hostname, sans the domain.
    #   - CommonName: (Optional) Specifies the template or explicit override for
    #                 the CN.  By default, this is the template:
    #
    #                              "{{.Hostname}}.{{.Domain}}"
    #
    #                 which obtains its values from the Spec.Hostname and
    #                 Org.Domain, respectively.
    # ---------------------------------------------------------------------------
    # Specs:
    #   - Hostname: foo # implicitly "foo.org1.example.com"
    #     CommonName: foo27.org5.example.com # overrides Hostname-based FQDN set above
    #   - Hostname: bar
    #   - Hostname: baz
    # ---------------------------------------------------------------------------
    # "Template"
    # ---------------------------------------------------------------------------
    # Allows for the definition of 1 or more hosts that are created sequentially
    # from a template. By default, this looks like "peer%d" from 0 to Count-1.
    # You may override the number of nodes (Count), the starting index (Start)
    # or the template used to construct the name (Hostname).
    #
    # Note: Template and Specs are not mutually exclusive.  You may define both
    # sections and the aggregate nodes will be created for you.  Take care with
    # name collisions
    # ---------------------------------------------------------------------------
    Template:
      Count: 2
      # Start: 5
      # Hostname: {{.Prefix}}{{.Index}} # default
    # ---------------------------------------------------------------------------
    # "Users"
    # ---------------------------------------------------------------------------
    # Count: The number of user accounts _in addition_ to Admin
    # ---------------------------------------------------------------------------
    Users:
      Count: 1
  # ---------------------------------------------------------------------------
  # Org2: See "Org1" for full specification
  # ---------------------------------------------------------------------------
  - Name: Org2
    Domain: org2.example.com
    EnableNodeOUs: true
    Template:
      Count: 2
    Users:
      Count: 1

이 파일 내에 count 변수가 있음을 알 수 있는데, 이를 통해 Org당 피어 수를 지정하며, 지금의 경우 Org당 피어가 두 개 있게 됩니다. 우리는 "x.509 인증서와 공개키 인프라의 세부 사항"을 지금 당장 보지는 않을 것 입니다.

 

암호화 툴을 실행하면 생성된 인증서와 키는 crypto-config라는 폴더에 저장됩니다. crypto-config.yaml 파일은 오더러 Org에 연결된 오더 5개를 나열한다는 점을 유의해야합니다. cryptogen 툴은 이들 다섯의 오더러 모두를 위한 인증서를 만들 것이다. 이러한 오더러는 등채 오더러 서비스 구현에 사용되며 시스템 채널과 mychannel을 만드는 데도 사용됩니다.

 

구성 트랜잭션 생성기(configtxgen)

configtxgen 도구는 다음과 같은 네 가지 구성 아티팩트를 생성하는 데 사용됩니다.

• 오더러 제네시스 블록
• 채널 구성 트랜잭션
• 두개의 앵커 피어 트랜잭션 - 피어 Org당 1개씩

이 도구의 기능에 대한 자세한 설명은 "configtxgen"을 참조하십시오.

 

상기 오더러 블록은 오더러 서비스를 위한 제네시스 블록이고, 채널 구성 트랜잭션 파일을 채널 생성 시의 오더러에게 브로드캐스트합니다. 이름에서 알 수 있 듯이 앵커 피어 트랜잭션은 이 채널에서 각 Org의 앵커 피어를 지정합니다.

 

어떻게 동작하는가?

Configtxgen은 샘플 네트워크에 대한 정의가 포함된 파일 - configtx.yaml을 사용합니다.

 

# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
---
################################################################################
#
#   Section: Organizations
#
#   - This section defines the different organizational identities which will
#   be referenced later in the configuration.
#
################################################################################
Organizations:
    # SampleOrg defines an MSP using the sampleconfig.  It should never be used
    # in production but may be used as a template for other definitions
    - &OrdererOrg
        # DefaultOrg defines the organization which is used in the sampleconfig
        # of the fabric.git development environment
        Name: OrdererOrg
        # ID to load the MSP definition as
        ID: OrdererMSP
        # MSPDir is the filesystem path which contains the MSP configuration
        MSPDir: crypto-config/ordererOrganizations/example.com/msp
        # Policies defines the set of policies at this level of the config tree
        # For organization policies, their canonical path is usually
        #   /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
        Policies:
            Readers:
                Type: Signature
                Rule: "OR('OrdererMSP.member')"
            Writers:
                Type: Signature
                Rule: "OR('OrdererMSP.member')"
            Admins:
                Type: Signature
                Rule: "OR('OrdererMSP.admin')"
        OrdererEndpoints:
            - orderer.example.com:7050
    - &Org1
        # DefaultOrg defines the organization which is used in the sampleconfig
        # of the fabric.git development environment
        Name: Org1MSP
        # ID to load the MSP definition as
        ID: Org1MSP
        MSPDir: crypto-config/peerOrganizations/org1.example.com/msp
        # Policies defines the set of policies at this level of the config tree
        # For organization policies, their canonical path is usually
        #   /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
        Policies:
            Readers:
                Type: Signature
                Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
            Writers:
                Type: Signature
                Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
            Admins:
                Type: Signature
                Rule: "OR('Org1MSP.admin')"
            Endorsement:
                Type: Signature
                Rule: "OR('Org1MSP.peer')"
        # leave this flag set to true.
        AnchorPeers:
            # AnchorPeers defines the location of peers which can be used
            # for cross org gossip communication.  Note, this value is only
            # encoded in the genesis block in the Application section context
            - Host: peer0.org1.example.com
              Port: 7051
    - &Org2
        # DefaultOrg defines the organization which is used in the sampleconfig
        # of the fabric.git development environment
        Name: Org2MSP
        # ID to load the MSP definition as
        ID: Org2MSP
        MSPDir: crypto-config/peerOrganizations/org2.example.com/msp
        # Policies defines the set of policies at this level of the config tree
        # For organization policies, their canonical path is usually
        #   /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
        Policies:
            Readers:
                Type: Signature
                Rule: "OR('Org2MSP.admin', 'Org2MSP.peer', 'Org2MSP.client')"
            Writers:
                Type: Signature
                Rule: "OR('Org2MSP.admin', 'Org2MSP.client')"
            Admins:
                Type: Signature
                Rule: "OR('Org2MSP.admin')"
            Endorsement:
                Type: Signature
                Rule: "OR('Org2MSP.peer')"
        AnchorPeers:
            # AnchorPeers defines the location of peers which can be used
            # for cross org gossip communication.  Note, this value is only
            # encoded in the genesis block in the Application section context
            - Host: peer0.org2.example.com
              Port: 9051
################################################################################
#
#   SECTION: Capabilities
#
#   - This section defines the capabilities of fabric network. This is a new
#   concept as of v1.1.0 and should not be utilized in mixed networks with
#   v1.0.x peers and orderers.  Capabilities define features which must be
#   present in a fabric binary for that binary to safely participate in the
#   fabric network.  For instance, if a new MSP type is added, newer binaries
#   might recognize and validate the signatures from this type, while older
#   binaries without this support would be unable to validate those
#   transactions.  This could lead to different versions of the fabric binaries
#   having different world states.  Instead, defining a capability for a channel
#   informs those binaries without this capability that they must cease
#   processing transactions until they have been upgraded.  For v1.0.x if any
#   capabilities are defined (including a map with all capabilities turned off)
#   then the v1.0.x peer will deliberately crash.
#
################################################################################
Capabilities:
    # Channel capabilities apply to both the orderers and the peers and must be
    # supported by both.
    # Set the value of the capability to true to require it.
    Channel: &ChannelCapabilities
        # V2_0 capability ensures that orderers and peers behave according
        # to v2.0 channel capabilities. Orderers and peers from
        # prior releases would behave in an incompatible way, and are therefore
        # not able to participate in channels at v2.0 capability.
        # Prior to enabling V2.0 channel capabilities, ensure that all
        # orderers and peers on a channel are at v2.0.0 or later.
        V2_0: true
    # Orderer capabilities apply only to the orderers, and may be safely
    # used with prior release peers.
    # Set the value of the capability to true to require it.
    Orderer: &OrdererCapabilities
        # V2_0 orderer capability ensures that orderers behave according
        # to v2.0 orderer capabilities. Orderers from
        # prior releases would behave in an incompatible way, and are therefore
        # not able to participate in channels at v2.0 orderer capability.
        # Prior to enabling V2.0 orderer capabilities, ensure that all
        # orderers on channel are at v2.0.0 or later.
        V2_0: true
    # Application capabilities apply only to the peer network, and may be safely
    # used with prior release orderers.
    # Set the value of the capability to true to require it.
    Application: &ApplicationCapabilities
        # V2_0 application capability ensures that peers behave according
        # to v2.0 application capabilities. Peers from
        # prior releases would behave in an incompatible way, and are therefore
        # not able to participate in channels at v2.0 application capability.
        # Prior to enabling V2.0 application capabilities, ensure that all
        # peers on channel are at v2.0.0 or later.
        V2_0: true
################################################################################
#
#   SECTION: Application
#
#   - This section defines the values to encode into a config transaction or
#   genesis block for application related parameters
#
################################################################################
Application: &ApplicationDefaults
    # Organizations is the list of orgs which are defined as participants on
    # the application side of the network
    Organizations:
    # Policies defines the set of policies at this level of the config tree
    # For Application policies, their canonical path is
    #   /Channel/Application/<PolicyName>
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
        LifecycleEndorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"
        Endorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"
    Capabilities:
        <<: *ApplicationCapabilities
################################################################################
#
#   SECTION: Orderer
#
#   - This section defines the values to encode into a config transaction or
#   genesis block for orderer related parameters
#
################################################################################
Orderer: &OrdererDefaults
    # Orderer Type: The orderer implementation to start
    OrdererType: etcdraft
    # Batch Timeout: The amount of time to wait before creating a batch
    BatchTimeout: 2s
    # Batch Size: Controls the number of messages batched into a block
    BatchSize:
        # Max Message Count: The maximum number of messages to permit in a batch
        MaxMessageCount: 10
        # Absolute Max Bytes: The absolute maximum number of bytes allowed for
        # the serialized messages in a batch.
        AbsoluteMaxBytes: 99 MB
        # Preferred Max Bytes: The preferred maximum number of bytes allowed for
        # the serialized messages in a batch. A message larger than the preferred
        # max bytes will result in a batch larger than preferred max bytes.
        PreferredMaxBytes: 512 KB
    # Organizations is the list of orgs which are defined as participants on
    # the orderer side of the network
    Organizations:
    # Policies defines the set of policies at this level of the config tree
    # For Orderer policies, their canonical path is
    #   /Channel/Orderer/<PolicyName>
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
        # BlockValidation specifies what signatures must be included in the block
        # from the orderer for the peer to validate it.
        BlockValidation:
            Type: ImplicitMeta
            Rule: "ANY Writers"
################################################################################
#
#   CHANNEL
#
#   This section defines the values to encode into a config transaction or
#   genesis block for channel related parameters.
#
################################################################################
Channel: &ChannelDefaults
    # Policies defines the set of policies at this level of the config tree
    # For Channel policies, their canonical path is
    #   /Channel/<PolicyName>
    Policies:
        # Who may invoke the 'Deliver' API
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        # Who may invoke the 'Broadcast' API
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        # By default, who may modify elements at this config level
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
    # Capabilities describes the channel level capabilities, see the
    # dedicated Capabilities section elsewhere in this file for a full
    # description
    Capabilities:
        <<: *ChannelCapabilities
################################################################################
#
#   Profile
#
#   - Different configuration profiles may be encoded here to be specified
#   as parameters to the configtxgen tool
#
################################################################################
Profiles:
    TwoOrgsChannel:
        Consortium: SampleConsortium
        <<: *ChannelDefaults
        Application:
            <<: *ApplicationDefaults
            Organizations:
                - *Org1
                - *Org2
            Capabilities:
                <<: *ApplicationCapabilities
    SampleMultiNodeEtcdRaft:
        <<: *ChannelDefaults
        Capabilities:
            <<: *ChannelCapabilities
        Orderer:
            <<: *OrdererDefaults
            OrdererType: etcdraft
            EtcdRaft:
                Consenters:
                - Host: orderer.example.com
                  Port: 7050
                  ClientTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
                  ServerTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
                - Host: orderer2.example.com
                  Port: 8050
                  ClientTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
                  ServerTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
                - Host: orderer3.example.com
                  Port: 9050
                  ClientTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt
                  ServerTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt
                - Host: orderer4.example.com
                  Port: 10050
                  ClientTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer4.example.com/tls/server.crt
                  ServerTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer4.example.com/tls/server.crt
                - Host: orderer5.example.com
                  Port: 11050
                  ClientTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer5.example.com/tls/server.crt
                  ServerTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer5.example.com/tls/server.crt
            Addresses:
                - orderer.example.com:7050
                - orderer2.example.com:8050
                - orderer3.example.com:9050
                - orderer4.example.com:10050
                - orderer5.example.com:11050
            Organizations:
            - *OrdererOrg
            Capabilities:
                <<: *OrdererCapabilities
        Application:
            <<: *ApplicationDefaults
            Organizations:
            - <<: *OrdererOrg
        Consortiums:
            SampleConsortium:
                Organizations:
                - *Org1
                - *Org2
 

 

3 명의 멤버가 있습니다 - 하나의 Orderer Org(OrdererOrg)와 2개의 Peer Org(Org1 & Org2)는 각각 2개의 피어 노드를 관리하고 유지합니다. 이 파일은 또한 우리의 두 피어 오르그로 구성된 컨소시엄 - 샘플컨소시엄을 지정합니다. 이 파일의 하단에 있는 "Profiles" 섹션에 대해 자세히 살펴보십시오. 여길 보면 몇 가지 독특한 프로필을 가지고 있다는 것을 알게 될 것입니다. 그리고 몇 가지는 확인해볼 필요가 있습니다.

 

• SampleMultiNodeEtcdRaft: Raft 오더링 서비스를 위한 제네시스 블록을 생성한다.
  -o 플래그를 설정하고 etcdraft를 지정한 경우에만 사용된다. 
• TwoOrgsChannel: 우리의 채널인 mychannel을 위한 제네시스 블록을 생성한다.

이 헤더들이 중요한데, 우리가 아티펙트를 만들 때, 이것들이 논쟁으로 넘길 것이기 때문입니다.

 

SampleConsortium은 시스템 레벨 프로필에서 정의되고 채널 레벨 프로필에서 참조된다는 점을 유념해야됩니다.채널은 컨소시엄의 권한 내에 존재하며, 모든 컨소시엄은 네트워크 범위에서 정의되어야 합니다.

 

이 파일에는 주목할 만한 두 가지 추가 사양도 포함되어 있습니다.

첫째, 각 Peer Org(peer0.org1.example.com & peer0.org2.example.com)의 앵커 피어를 지정합니다.

둘째, 각 구성원의 MSP 디렉토리(MSPDir)의 위치를 가리키며, 각 조직의 루트 인증서를 Order Genesis 블록에 저장할 수 있도록 합니다.

이것은 비판적인 개념이다. 이제 오더러 서비스와 통신하는 모든 네트워크 실체는 디지털 서명을 확인할 수 있다.

 

툴 실행하기

configtxgen과 cryptogen 명령을 사용하여 인증서그리고 키와 다양한 구성 아티팩트를 수동으로 생성할 수 있습니다.

혹은 실행하기 위해 byfn.sh 스크립트를 수정해서 작업할 수도 있습니다.

 

아티팩트를 수동으로 생성

crypto-config.yaml 파일에 정의된 대로 네트워크 구성에 사용할 인증서를 생성하는 데 필요한 명령은 byfn.sh 스크립트의 generateCerts 함수를 참조하십시오. 다만 편의상 이곳에서도 참고자료를 제공하겠습니다.

 

# Generates Org certs using cryptogen tool
function generateCerts() {
  which cryptogen
  if [ "$?" -ne 0 ]; then
    echo "cryptogen tool not found. exiting"
    exit 1
  fi
  echo
  echo "##########################################################"
  echo "##### Generate certificates using cryptogen tool #########"
  echo "##########################################################"
 
  if [ -d "crypto-config" ]; then
    rm -Rf crypto-config
  fi
  set -x
  cryptogen generate --config=./crypto-config.yaml
  res=$?
  set +x
  if [ $res -ne 0 ]; then
    echo "Failed to generate certificates..."
    exit 1
  fi
  echo
  echo "Generate CCP files for Org1 and Org2"
  ./ccp-generate.sh
}

 

먼저 암호화된 도구를 실행합시다. 우리의 바이너리는 bin 디렉토리에 있으므로, 우리는 도구가 있는 곳의 상대적인 경로를 제공해야 합니다.

 

../bin/cryptogen generate --config=./crypto-config.yaml

실행후, 아래의 결과를 터미널에서 확인해야됩니다.

org1.example.com
org2.example.com

first-network 디렉토리의 루트 디렉토리에 있는 crypto-config에 인증서와 키(MSP 구성품)가 저장될 것입니다.

 

다음으로, 우리는 configtxgen 툴이 수집해야 할 configtx.yaml 파일을 어디에서 찾아야 하는지 알려야 합니다. 현재 작업 디렉토리에서 찾아보기를 알려드리겠습니다.

 

function generateChannelArtifacts() {
  which configtxgen
  if [ "$?" -ne 0 ]; then
    echo "configtxgen tool not found. exiting"
    exit 1
  fi
 
  echo "##########################################################"
  echo "#########  Generating Orderer Genesis block ##############"
  echo "##########################################################"
  # Note: For some unknown reason (at least for now) the block file can't be
  # named orderer.genesis.block or the orderer will fail to launch!
  set -x
  configtxgen -profile SampleMultiNodeEtcdRaft -channelID byfn-sys-channel -outputBlock ./channel-artifacts/genesis.block
  res=$?
  set +x
  if [ $res -ne 0 ]; then
    echo "Failed to generate orderer genesis block..."
    exit 1
  fi
  echo
  echo "#################################################################"
  echo "### Generating channel configuration transaction 'channel.tx' ###"
  echo "#################################################################"
  set -x
  configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID $CHANNEL_NAME
  res=$?
  set +x
  if [ $res -ne 0 ]; then
    echo "Failed to generate channel configuration transaction..."
    exit 1
  fi
 
  echo
  echo "#################################################################"
  echo "#######    Generating anchor peer update for Org1MSP   ##########"
  echo "#################################################################"
  set -x
  configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org1MSP
  res=$?
  set +x
  if [ $res -ne 0 ]; then
    echo "Failed to generate anchor peer update for Org1MSP..."
    exit 1
  fi
 
  echo
  echo "#################################################################"
  echo "#######    Generating anchor peer update for Org2MSP   ##########"
  echo "#################################################################"
  set -x
  configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate \
    ./channel-artifacts/Org2MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org2MSP
  res=$?
  set +x
  if [ $res -ne 0 ]; then
    echo "Failed to generate anchor peer update for Org2MSP..."
    exit 1
  fi
  echo
}

 

export FABRIC_CFG_PATH=$PWD

그런 다음 구성 요소 도구를 호출하여 오더러 제네시스 블록을 만들 것입니다.

../bin/configtxgen -profile SampleMultiNodeEtcdRaft -channelID byfn-sys-channel -outputBlock ./channel-artifacts/genesis.block

오더러 제네시스 블록과 우리가 만들려는 후속 아티팩트는 first-network 디렉토리의 루트에 있는 채널 아티팩트 디렉토리로 출력됩니다. 위의 커멘드의 channelID는 시스템 채널의 이름입니다.

 

채널 구성 트랜잭션 생성

다음으로, 우리는 채널 트랜잭션 아티팩트를 만들어야 합니다. $CHANNEL_NAME을 대체하거나 다음 지침에 걸쳐 사용할 수 있는 환경 변수로 CHANNEL_NAME을 설정하십시오.

# channel.tx는 샘플 채널의 정의를 포함합니다.

export CHANNEL_NAME=mychannel  && ../bin/configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID $CHANNEL_NAME

TwoOrgsChannel 프로파일은 네트워크의 생성 블록을 작성할 때 지정한 오더링 서비스 구성을 사용합니다.

터미널에서 다음과 유사한 출력을 봐야 합니다.

2017-10-26 19:24:05.324 EDT [common/tools/configtxgen] main -> INFO 001 Loading configuration
2017-10-26 19:24:05.329 EDT [common/tools/configtxgen] doOutputChannelCreateTx -> INFO 002 Generating new channel configtx
2017-10-26 19:24:05.329 EDT [common/tools/configtxgen] doOutputChannelCreateTx -> INFO 003 Writing new channel tx

다음으로, 우리는 우리가 만들어놓은 채널에 Org1의 앵커 피어를 정의할 것 입니다. 다시 $CHANNEL_NAME을 교체하거나 다음 명령에 대한 환경 변수를 설정하십시오. 터미널 출력은 채널 트랜잭션 아티팩트의 출력을 모방합니다.

../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org1MSP

이제 동일한 채널에서 Org2의 앵커 피어를 정의하십시오.

../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org2MSP

 

네트워크 시작하기

 

이제 우리의 네트워크를 활성화 시키기 위해 스크립트를 활용할 것 입니다. 도커 컴포즈 파일은 우리가 이전에 다운로드한 이미지를 참조하고 이전에 생성되었던 genesis.block으로 오더러를 로드(부트스트랩)합니다.

 

각각의 오더러의 기능과 구문을 노출하기 위해 수동으로 커멘드를 실행하겠습니다.

우선 네트워크를 실행합니다.

docker-compose -f docker-compose-cli.yaml -f docker-compose-etcdraft2.yaml up -d

* docker-compose-cli.yaml, docker-compose-base.yaml: 전체 네트워크 노드들의 docker-compose 설정

* docker-compose-etcdraft2.yaml: raft 오더링을 위한 orderer2,3,4,5에 대한 설정

 

네트워크의 실시간 로그를 보려면 -d 플래그를 제공하지 마십시오. 로그가 스트리밍되도록 하면 두 번째 터미널을 열어 CLI 호출을 실행해야 합니다.

 

채널생성과 채널조인하기

위의 채널 구성 트랜잭션 생성 섹션에 있는 configtxgen 도구를 사용하여 채널 구성 트랜잭션을 생성했음을 기억합니다.

configtxgen 도구에 전달하는 configtx.yaml의 동일하거나 다른 프로파일을 사용하여 해당 프로세스를 반복하여 추가 채널 구성 트랜잭션을 작성할 수 있습니다. 그런 다음 이 절에서 정의한 프로세스를 반복하여 네트워크의 다른 채널을 설정할 수 있습니다.

 

docker Exec 명령을 사용하여 CLI 컨테이너에 들어갑니다.

docker exec -it cli bash

peer0.org1.example.com에 대한 다음 CLI 명령이 작동하려면 아래에 제시된 네 가지 환경 변수를 사용하여 명령 서문을 작성해야 한다. peer0.org1.example.com의 이러한 변수들은 CLI 컨테이너에 지정되기 때문에 우리는 그것들을 통과시키지 않고 작동할 수 있다. 그러나 다른 피어 또는 오더러에게 콜을 하려면 peer0.org1.example.com을 대상으로 하는 CLI 컨테이너 기본값을 유지하되 CLI 콜을 할 때 아래 예와 같이 환경 변수를 재정의하십시오.

# Environment variables for PEER0

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
CORE_PEER_ADDRESS=peer0.org1.example.com:7051
CORE_PEER_LOCALMSPID="Org1MSP"
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

다음으로 채널 구성 트랜잭션 생성 섹션에서 생성한 채널 구성 트랜잭션 아티팩트(channel.tx)를 채널 생성 요청의 일부로 오더러에게 전달합니다.

-c 플래그와 -f 플래그와의 채널 구성 트랜잭션으로 채널 이름을 지정합니다. 이 경우 channel.tx이지만 다른 이름으로 자신의 구성 트랜잭션을 마운트할 수 있습니다.

우리는 다시 한번 CLI 컨테이너 내에 CHANNEL_NAME 환경 변수를 설정하여 이 주장을 명시적으로 통과시킬 필요가 없습니다.

채널 이름은 모두 더 낮은 경우, 길이가 250자 미만이고 정규 표현식 [a-z][a-z0-9.-]*과 일치해야 하는 규칙이 있습니다.

export CHANNEL_NAME=mychannel

# the channel.tx file is mounted in the channel-artifacts directory within your CLI container
# as a result, we pass the full path for the file
# we also pass the path for the orderer ca-cert in order to verify the TLS handshake
# be sure to export or replace the $CHANNEL_NAME variable appropriately

peer channel create -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/channel.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

 

 

* 이 명령의 일부로 통과되는 --cafile을 주목하십시오. 이것은 우리가 TLS handshake를 검증할 수 있게 해주는 오더러의 루트 인증서에 대한 로컬 경로입니다.

 

이 명령은 제네시스 블록(<CHANNE_NAME.block>)을 반환하며, 이 블록을 사용하여 채널에 가입합니다. channel.tx에 지정된 구성 정보를 포함함 기본 채널 이름을 수정하지 않은 경우 명령어는 mychannel.block이라는 프로토를 반환합니다.

 

*이러한 수동 명령의 나머지 기간 동안 CLI 컨테이너에 남아 있게 됩니다. 또한 peer0.org1.example.com 이외의 피어를 대상으로 할 때는 해당 환경 변수가 있는 모든 명령의 서문을 반드시 기억해야 합니다.

 

이제 peer0.org1.example.com을 채널에 조인시킵니다.

# By default, this joins ``peer0.org1.example.com`` only
# the <CHANNEL_NAME.block> was returned by the previous command
# if you have not modified the channel name, you will join with mychannel.block
# if you have created a different channel name, then pass in the appropriately named block

 peer channel join -b mychannel.block

 

위의 Create & Join Channel 섹션에서 사용한 네 가지 환경 변수를 적절하게 변경하여 필요에 따라 다른 피어를 채널에 가입시킬 수 있습니다.

 

모든 피어에 가입하기 보다는 peer0.org2.example.com에 가입하여 채널의 앵커 피어 정의를 적절하게 업데이트할 수 있도록 할 것입니다. CLI 컨테이너에 구워진 기본 환경 변수를 재정의하기 때문에 이 전체 명령은 아래와 같습니다.

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp CORE_PEER_ADDRESS=peer0.org2.example.com:9051 CORE_PEER_LOCALMSPID="Org2MSP" CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt peer channel join -b mychannel.block

 

또는 전체 문자열을 통과하기보다는 개별적으로 이러한 환경 변수를 설정하도록 선택할 수 있습니다. 일단 설정되면 피어 채널 결합 명령을 다시 발급하면 CLI 컨테이너가 peer0.org2.example.com.을 대신하여 작동합니다.

 

앵커피어 업데이트하기

다음 명령은 채널 업데이트로 채널 정의에서 전파됩니다. 본질적으로 채널의 제네시스 블록 위에 구성 정보를 추가합니다. 우리는 제네시스 블록을 수정하는 것이 아니라 단지 앵커 피어를 정의할 체인에 델타를 추가하는 것입니다.

 

채널 정의를 업데이트하여 Org1의 앵커 피어를 peer0.org1.example.com으로 정의하십시오.

peer channel update -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/Org1MSPanchors.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

이제 채널 정의를 업데이트하여 Org2의 앵커 피어를 peer0.org2.example.com.으로 정의하십시오. Org2 피어에 대한 피어 채널 결합 명령에 대해 식별적으로 적절한 환경 변수로이 호출을 서문해야 합니다.

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp CORE_PEER_ADDRESS=peer0.org2.example.com:9051 CORE_PEER_LOCALMSPID="Org2MSP" CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt peer channel update -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/Org2MSPanchors.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

 

체인코드 설치 및 정의하기

애플리케이션은 체인코드를 통해 블록체인의 원장과 상호작용을 합니다. 그러므로 우리는 우리의 거래를 실행하고 보증할 모든 피어에 체인코드를 설치할 필요가 있습니다. 그러나, 우리가 우리의 체인코드와 상호작용하기 전에, 채널의 구성원들은 체인코드 거버넌스를 확립하는 체인코드 정의에 동의할 필요가 있습니다. 우리는 피어에게 설치되기 전에 체인코드를 패키징해야 합니다. 생성한 각 패키지에 대해 체인코드에 대한 설명으로 체인코드 패키지 레이블을 제공해야 합니다. 다음 명령을 사용하여 샘플 Go, Node.js, Java 체인 코드를 패키징하십시오.

 

체인코드가 피어에 설치되기 전에 패키지를 해야 합니다. 작성한 각 패키지에 대해 체인 코드 패키지 레이블을 체인 코드에 대한 설명으로 제공해야 합니다. 다음 명령을 사용하여 샘플 Go, Node.js 또는 Java 체인코드를 패키지화하십시오.

(Go, 자바는 제외)

Node.js

 

# this packages a Node.js chaincode
# make note of the --lang flag to indicate "node" chaincode
# for node chaincode --path takes the absolute path to the Node.js chaincode
# The --label flag is used to create the package label
peer lifecycle chaincode package mycc.tar.gz --path /opt/gopath/src/github.com/hyperledger/fabric-samples/chaincode/abstore/javascript/ --lang node --label mycc_1

# this command installs a chaincode package on your peer
peer lifecycle chaincode install mycc.tar.gz

성공적으로 설치 명령을 내리면 체인코드 패키지 식별자가 반환됩니다. 다음과 비슷한 출력을 봐야 합니다.

2019-03-13 13:48:53.691 UTC [cli.lifecycle.chaincode] submitInstallProposal -> INFO 001 Installed remotely: response:<status:200 payload:"\nEmycc_1:3a8c52d70c36313cfebbaf09d8616e7a6318ababa01c7cbe40603c373bcfe173" >
2019-03-13 13:48:53.691 UTC [cli.lifecycle.chaincode] submitInstallProposal -> INFO 002 Chaincode code package identifier: mycc_1:3a8c52d70c36313cfebbaf09d8616e7a6318ababa01c7cbe40603c373bcfe173

또한 설치한 패키지에 대한 정보를 피어에 조회하여 체인코드 패키지 식별자를 찾을 수 있습니다.

# 피어에 설치된 체인코드 패키지의 디테일을 리턴합니다.
peer lifecycle chaincode queryinstalled

위의 명령은 install 명령과 동일한 패키지 식별자를 반환합니다. 다음과 유사한 출력이 표시되어야 합니다.

Get installed chaincodes on peer:
Package ID: mycc_1:3a8c52d70c36313cfebbaf09d8616e7a6318ababa01c7cbe40603c373bcfe173, Label: mycc_1

패키지 ID가 필요할 예정이니, 환경변수로 저장해둡니다. peer lifecycle chaincode queryinstalled에 의해 리턴된 패키지 ID를 커맨드에 붙이세요. 패키지 ID는 아마 모든 유저들과 동일하지 않을 수 있으므로, 콘솔에서 반환된 패키지 ID를 사용하여 이 단계를 완료합니다.

# Save the package ID as an environment variable.
 
CC_PACKAGE_ID=mycc_1:3a8c52d70c36313cfebbaf09d8616e7a6318ababa01c7cbe40603c373bcfe173

mycc의 보증 정책은 Org1과 Org2 둘 다의 피어로부터 승인을 요구하도록 설정될 것입니다. 따라서 Org2의 피어에다가도 체인코드를 설치할 필요가 있습니다.

다음 네 가지 환경 변수를 수정하여 설치 명령을 Org2로 실행하십시오.

# Environment variables for PEER0 in Org2

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
CORE_PEER_ADDRESS=peer0.org2.example.com:9051
CORE_PEER_LOCALMSPID="Org2MSP"
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt

 

이제 Org2의 peer0에 체인코드 패키지를 설치하십시오. 다음 명령은 Chaincode를 설치하고 Org1로 실행한 install 명령과 동일한 식별자를 반환합니다.

# this installs a chaincode package on your peer
peer lifecycle chaincode install mycc.tar.gz

패키지를 설치한 후에는 조직에 대한 체인코드 정의를 승인해야 합니다. 체인코드 정의는 체인코드 이름과 버전을 포함한 체인코드 거버넌스의 중요한 매개변수를 포함합니다. 또한 이 정의에는 피어에 설치된 체인코드 패키지를 조직에서 승인한 체인코드 정의와 연결하는 데 사용되는 패키지 식별자가 포함되어 있습니다.

 

환경 변수를 Org2로 작동하도록 설정했기 때문에, 다음 명령을 사용하여 Org2에 대한 mycc 체인코드의 정의를 승인할 수 있습니다. 승인은 각 조직 내의 피어에 배포되므로 명령어는 Org 내의 모든 피어를 대상으로 할 필요가 없습니다.

# this approves a chaincode definition for your org
# make note of the --package-id flag that provides the package ID
# use the --init-required flag to request the ``Init`` function be invoked to initialize the chaincode
peer lifecycle chaincode approveformyorg --channelID $CHANNEL_NAME --name mycc --version 1.0 --init-required --package-id $CC_PACKAGE_ID --sequence 1 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

 --signature-policy 또는 --channel-config-policy 인수를 위의 명령어에 제공하여 체인코드 승인 정책을 설정할 수 있습니다. 승인 정책은 서로 다른 채널 멤버에 속한 피어들이 주어진 체인코드에 대해 트랜잭션을 검증하기 위해 필요한 피어 수를 지정합니다. 우리는 정책을 설정하지 않았기 때문에, mycc의 정의는 거래가 제출될 때 존재하는 채널 멤버의 과반수가 거래를 승인하도록 요구하는 기본 승인 정책을 사용할 것입니다. 이는 새로운 조직을 채널에 추가하거나 채널에서 제거할 경우, 더 많은 또는 더 적은 승인을 요구하도록 승인 정책이 자동으로 업데이트됨을 의미합니다. 이 튜토리얼에서 기본 정책은 Org1 AND Org2에 속하는 피어의 승인(즉, 두 가지 승인)을 필요로 합니다. 정책 구현에 대한 자세한 내용은 보증 정책 설명서를 참조하십시오.

모든 조직들은 그들이 체인코드를 사용하기 전에 그 정의에 동의할 필요가 있습니다. Org1로 작동하도록 다음 네 가지 환경 변수를 수정하십시오.

# Environment variables for PEER0
 
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
CORE_PEER_ADDRESS=peer0.org1.example.com:7051
CORE_PEER_LOCALMSPID="Org1MSP"
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

이제 mycc 체인코드에 대한 정의를 Org1로 승인할 수 있게 됐습니다.

체인코드는 Org 수준에서 승인이 됩니다. 피어가 여러 개인 경우에도 명령을 한 번만 실행할 수 있습니다.

# this defines a chaincode for your org
# make note of the --package-id flag that provides the package ID
# use the --init-required flag to request the Init function be invoked to initialize the chaincode
peer lifecycle chaincode approveformyorg --channelID $CHANNEL_NAME --name mycc --version 1.0 --init-required --package-id $CC_PACKAGE_ID --sequence 1 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

한번 충분한 수의 채널멤버를 체인코드 정의를 승인했으면, 하나의 멤버는 채널에 정의를 커밋할 수 있습니다. 기본적으로 채널멤버의 대부분은 정의를 승인해야 정의를 실행할 수 있습니다. 체인코드 정의를 커밋할 준비가 되었는지 확인하고, 다음과 같은 쿼리를 발행하여 조직별 현재 승인을 볼 수 있습니다.

# the flags used for this command are identical to those used for approveformyorg
# except for --package-id which is not required since it is not stored as part of
# the definition
peer lifecycle chaincode checkcommitreadiness --channelID $CHANNEL_NAME --name mycc --version 1.0 --init-required --sequence 1 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --output json

이 명령은 채널의 조직이 checkcommitteness 명령에 제공된 체인코드 정의를 승인했는지 여부를 보여주는 JSON 맵을 출력물로 생성합니다. 이 경우, 두 기관이 모두 승인한 경우, 다음을 얻습니다:

{
        "Approvals": {
                "Org1MSP": true,
                "Org2MSP": true
        }
}

두 채널 멤버 모두 정의를 승인했으므로, 우리는 이제 다음 명령을 사용하여 채널에 이를 위임할 수 있습니다. 이 명령은 Org1 혹은 Org2로 실행할 수 있습니다. 트랜잭션은 Org1와 Org2의 동료를 대상으로 하여 승인을 수집한다는 점에 유의하십시오.

# this commits the chaincode definition to the channel
peer lifecycle chaincode commit -o orderer.example.com:7050 --channelID $CHANNEL_NAME --name mycc --version 1.0 --sequence 1 --init-required --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --peerAddresses peer0.org1.example.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses peer0.org2.example.com:9051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt

 

체인코드 호출

Query

# be sure to set the -C and -n flags appropriately

peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

Invoke

# be sure to set the -C and -n flags appropriately
peer chaincode invoke -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n mycc --peerAddresses peer0.org1.example.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses peer0.org2.example.com:9051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"Args":["invoke","a","b","10"]}' --waitForEvent

Install the chaincode on an additional peer

 

Query

What’s happening behind the scenes?