fpc-lifecycle-v2.puml

/'
    Copyright 2020 Intel Corporation
    Copyright IBM Corp. All Rights Reserved.

    SPDX-License-Identifier: Apache-2.0
'/

@startuml

!pragma teoz true

hide footbox
title Foot Box removed

title Fabric Private Chaincode - Lifecycle v2

box "Org1"
actor Admin order 10
participant Peer_CLI order 15
participant Peer1 order 20
participant Peer2 order 40
end box

entity Orderer order 80

group inspection
    Admin -> Admin : inspect FPC chaincode,\nbuild enclave binary\nand **mrenclave**
    note right Admin
    By generating **mrenclave** based
    on the inspected FPC chaincode,
    the Org defines the "correct" code
    identity they will approve
    end note
end

note over Peer_CLI
    Admin uses Fabric Peer CLI, which is extended with
    additional functionality to ease FPC specific usability.
end note

group package
    Admin -> Peer_CLI++ : lifecycle\nchaincode package
    note right
    **Chaincode package** as tar.gz with
    metadata.json = <path:(enclaves_path),
        type:(cc_lang),
        label:(cc_label),
        sgx_mode: (sim/hw)>
    and code.tar.gz including enclave binary and **mrenclave**
    end note
return
end

group install
    Admin -> Peer_CLI++ : lifecycle\nchaincode install
    Peer_CLI -> Peer1++ : install chaincode from package
    return packageId

    note right Peer_CLI
    The following bookkeeping operations help remember
    (across lifecycle calls) that a package (id)
    corresponds to a FPC chaincode. Similarly, the
    approve will later store data for an FPC chaincode
    installed locally, and the commit checks for data
    of a locally-approved FPC chaincode.

    Also, it should be noted that
    - the install lifecycle op is peer-specific, while
    - the approveformyorg is org-specific, to be run
    on at most one org's peer
    - the commit op has to be run on a single peer

    The current bookkeeping ops expect the approve and
    commit ops to run on peers where the FPC chaincode
    has been previously installed.
    end note

    Peer_CLI -> Peer_CLI : retrieve cc_language from package
    Peer_CLI -> Peer_CLI : if cc_language==fpc\n\tthen store packageId
    return packageId
end

ref over Admin, Peer_CLI, Peer2
    Admin installs chaincode on Peer2
end ref

group approveformyorg
    Admin -> Peer_CLI++ : lifecycle\nchaincode approveformyorg\n(version=**mrenclave**)
    note right
    **Chaincode Definition for FPC Chaincode** including
    Name: cc_name,
    Version: **mrenclave**,
    Sequence: sequence_number,
    Endorsement Policy: (2of3),
    Plugins: fpc-vscc (FPC validation plugin, absent in FPC Lite (MVP))

    NOTE: the (fabric) endorsement policy has different meanings depending
    on whether FPC runs in FPC Lite (MVP) or "full" FPC mode (post-MVP):
    - in former case it specifies "validation endorsement policy", i.e. 
      how many organization have to be trusted to validate the enclave 
      endorsements in the validation chaincode transaction. For MPV, the 
      "enclave endorsement policy" is implicit and requires an enclave
      signature from a single enclave registered at ERCC and hosted at
      an organization participating in the underlying channel.
    - in the latter case, it specifies the "enclave endorsement policy",
      i.e., how many (and with which proporties) enclaves are expected 
      to endorse FPC chaincode transactions. The "validation endorsement 
      policy" is implicit as each peer will validate transactions (via
      validation plugin extension point.)

    NOTE: FPC does not support custom user plugins.
    end note

    Peer_CLI -> Orderer++ : approve transaction
    return transaction committed /' Peer1_CLI -> Orderer '/

    note right Peer_CLI
    Bookkeeping operations.
    NOTE: packageId is an input parameter of approveformyorg
    end note

    Peer_CLI -> Peer_CLI : if packageId was stored (and hence it is an FPC chaincode)\n\tthen store mapping packageId to <cc_name, cc_version>
    return
end

loop until enough approvals
	Admin -> Peer_CLI++ : lifecycle\nchaincode checkcommitreadiness
    note right
    **Chaincode definition**
    (implemented to match the approved one)
    end note

    note right Peer_CLI
    Other participants must approve the chaincode definition
    by committing the corresponding transaction according to
    the LifecycleEndorsement policy.

    Note that other orgs follow the same lifecycle steps as
    illustrated here, in particular, they inspect the FPC
    chaincode and must approve the same **mrenclave** (and
    hence identical code).  Requiring identical code is a
    departure of the new capability added to Fabric v2 in
    allowing different peers to have different implementations.
    Unfortunately, due to confidentiality requirements, such
    a feature is not possible for FPC.
    end note

    Peer_CLI -> Peer1++ : checkcommitreadiness
    return
    return
end

group commit
    Admin -> Peer_CLI++ : lifecycle\nchaincode commit
    note right
    **Chaincode definition**
    (implemented to match the one that is ready to be committed)
    end note

    Peer_CLI -> Orderer++ : commit transaction
    return transaction committed
    return
end

note right Admin
    To complete setting up an FPC chaincode, enclaves have to be registered and provisioned with keys.
    See the separate UML diagrams `fpc-registration` and `fpc-key-dist`
    for the corresponding admin commands and protocol flows.
end note
@enduml