forked from hyperledger/fabric-private-chaincode
-
Notifications
You must be signed in to change notification settings - Fork 0
/
fpc-lifecycle-v2.puml
170 lines (141 loc) · 5.34 KB
/
fpc-lifecycle-v2.puml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
/'
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