|
1
|
|
|
<?php |
|
2
|
|
|
# Generated by the protocol buffer compiler. DO NOT EDIT! |
|
3
|
|
|
# source: peer/proposal_response.proto |
|
4
|
|
|
|
|
5
|
|
|
namespace Hyperledger\Fabric\Protos\Peer; |
|
6
|
|
|
|
|
7
|
|
|
use Google\Protobuf\Internal\GPBType; |
|
8
|
|
|
use Google\Protobuf\Internal\RepeatedField; |
|
9
|
|
|
use Google\Protobuf\Internal\GPBUtil; |
|
10
|
|
|
|
|
11
|
|
|
/** |
|
12
|
|
|
* ProposalResponsePayload is the payload of a proposal response. This message |
|
13
|
|
|
* is the "bridge" between the client's request and the endorser's action in |
|
14
|
|
|
* response to that request. Concretely, for chaincodes, it contains a hashed |
|
15
|
|
|
* representation of the proposal (proposalHash) and a representation of the |
|
16
|
|
|
* chaincode state changes and events inside the extension field. |
|
17
|
|
|
* |
|
18
|
|
|
* Generated from protobuf message <code>protos.ProposalResponsePayload</code> |
|
19
|
|
|
*/ |
|
20
|
|
|
class ProposalResponsePayload extends \Google\Protobuf\Internal\Message |
|
21
|
|
|
{ |
|
22
|
|
|
/** |
|
23
|
|
|
* Hash of the proposal that triggered this response. The hash is used to |
|
24
|
|
|
* link a response with its proposal, both for bookeeping purposes on an |
|
25
|
|
|
* asynchronous system and for security reasons (accountability, |
|
26
|
|
|
* non-repudiation). The hash usually covers the entire Proposal message |
|
27
|
|
|
* (byte-by-byte). However this implies that the hash can only be verified |
|
28
|
|
|
* if the entire proposal message is available when ProposalResponsePayload is |
|
29
|
|
|
* included in a transaction or stored in the ledger. For confidentiality |
|
30
|
|
|
* reasons, with chaincodes it might be undesirable to store the proposal |
|
31
|
|
|
* payload in the ledger. If the type is CHAINCODE, this is handled by |
|
32
|
|
|
* separating the proposal's header and |
|
33
|
|
|
* the payload: the header is always hashed in its entirety whereas the |
|
34
|
|
|
* payload can either be hashed fully, or only its hash may be hashed, or |
|
35
|
|
|
* nothing from the payload can be hashed. The PayloadVisibility field in the |
|
36
|
|
|
* Header's extension controls to which extent the proposal payload is |
|
37
|
|
|
* "visible" in the sense that was just explained. |
|
38
|
|
|
* |
|
39
|
|
|
* Generated from protobuf field <code>bytes proposal_hash = 1;</code> |
|
40
|
|
|
*/ |
|
41
|
|
|
private $proposal_hash = ''; |
|
42
|
|
|
/** |
|
43
|
|
|
* Extension should be unmarshaled to a type-specific message. The type of |
|
44
|
|
|
* the extension in any proposal response depends on the type of the proposal |
|
45
|
|
|
* that the client selected when the proposal was initially sent out. In |
|
46
|
|
|
* particular, this information is stored in the type field of a Header. For |
|
47
|
|
|
* chaincode, it's a ChaincodeAction message |
|
48
|
|
|
* |
|
49
|
|
|
* Generated from protobuf field <code>bytes extension = 2;</code> |
|
50
|
|
|
*/ |
|
51
|
|
|
private $extension = ''; |
|
52
|
|
|
|
|
53
|
|
|
public function __construct() { |
|
54
|
|
|
\GPBMetadata\Peer\ProposalResponse::initOnce(); |
|
55
|
|
|
parent::__construct(); |
|
56
|
|
|
} |
|
57
|
|
|
|
|
58
|
|
|
/** |
|
59
|
|
|
* Hash of the proposal that triggered this response. The hash is used to |
|
60
|
|
|
* link a response with its proposal, both for bookeeping purposes on an |
|
61
|
|
|
* asynchronous system and for security reasons (accountability, |
|
62
|
|
|
* non-repudiation). The hash usually covers the entire Proposal message |
|
63
|
|
|
* (byte-by-byte). However this implies that the hash can only be verified |
|
64
|
|
|
* if the entire proposal message is available when ProposalResponsePayload is |
|
65
|
|
|
* included in a transaction or stored in the ledger. For confidentiality |
|
66
|
|
|
* reasons, with chaincodes it might be undesirable to store the proposal |
|
67
|
|
|
* payload in the ledger. If the type is CHAINCODE, this is handled by |
|
68
|
|
|
* separating the proposal's header and |
|
69
|
|
|
* the payload: the header is always hashed in its entirety whereas the |
|
70
|
|
|
* payload can either be hashed fully, or only its hash may be hashed, or |
|
71
|
|
|
* nothing from the payload can be hashed. The PayloadVisibility field in the |
|
72
|
|
|
* Header's extension controls to which extent the proposal payload is |
|
73
|
|
|
* "visible" in the sense that was just explained. |
|
74
|
|
|
* |
|
75
|
|
|
* Generated from protobuf field <code>bytes proposal_hash = 1;</code> |
|
76
|
|
|
* @return string |
|
77
|
|
|
*/ |
|
78
|
|
|
public function getProposalHash() |
|
79
|
|
|
{ |
|
80
|
|
|
return $this->proposal_hash; |
|
81
|
|
|
} |
|
82
|
|
|
|
|
83
|
|
|
/** |
|
84
|
|
|
* Hash of the proposal that triggered this response. The hash is used to |
|
85
|
|
|
* link a response with its proposal, both for bookeeping purposes on an |
|
86
|
|
|
* asynchronous system and for security reasons (accountability, |
|
87
|
|
|
* non-repudiation). The hash usually covers the entire Proposal message |
|
88
|
|
|
* (byte-by-byte). However this implies that the hash can only be verified |
|
89
|
|
|
* if the entire proposal message is available when ProposalResponsePayload is |
|
90
|
|
|
* included in a transaction or stored in the ledger. For confidentiality |
|
91
|
|
|
* reasons, with chaincodes it might be undesirable to store the proposal |
|
92
|
|
|
* payload in the ledger. If the type is CHAINCODE, this is handled by |
|
93
|
|
|
* separating the proposal's header and |
|
94
|
|
|
* the payload: the header is always hashed in its entirety whereas the |
|
95
|
|
|
* payload can either be hashed fully, or only its hash may be hashed, or |
|
96
|
|
|
* nothing from the payload can be hashed. The PayloadVisibility field in the |
|
97
|
|
|
* Header's extension controls to which extent the proposal payload is |
|
98
|
|
|
* "visible" in the sense that was just explained. |
|
99
|
|
|
* |
|
100
|
|
|
* Generated from protobuf field <code>bytes proposal_hash = 1;</code> |
|
101
|
|
|
* @param string $var |
|
102
|
|
|
* @return $this |
|
103
|
|
|
*/ |
|
104
|
|
|
public function setProposalHash($var) |
|
105
|
|
|
{ |
|
106
|
|
|
GPBUtil::checkString($var, False); |
|
107
|
|
|
$this->proposal_hash = $var; |
|
108
|
|
|
|
|
109
|
|
|
return $this; |
|
110
|
|
|
} |
|
111
|
|
|
|
|
112
|
|
|
/** |
|
113
|
|
|
* Extension should be unmarshaled to a type-specific message. The type of |
|
114
|
|
|
* the extension in any proposal response depends on the type of the proposal |
|
115
|
|
|
* that the client selected when the proposal was initially sent out. In |
|
116
|
|
|
* particular, this information is stored in the type field of a Header. For |
|
117
|
|
|
* chaincode, it's a ChaincodeAction message |
|
118
|
|
|
* |
|
119
|
|
|
* Generated from protobuf field <code>bytes extension = 2;</code> |
|
120
|
|
|
* @return string |
|
121
|
|
|
*/ |
|
122
|
|
|
public function getExtension() |
|
123
|
|
|
{ |
|
124
|
|
|
return $this->extension; |
|
125
|
|
|
} |
|
126
|
|
|
|
|
127
|
|
|
/** |
|
128
|
|
|
* Extension should be unmarshaled to a type-specific message. The type of |
|
129
|
|
|
* the extension in any proposal response depends on the type of the proposal |
|
130
|
|
|
* that the client selected when the proposal was initially sent out. In |
|
131
|
|
|
* particular, this information is stored in the type field of a Header. For |
|
132
|
|
|
* chaincode, it's a ChaincodeAction message |
|
133
|
|
|
* |
|
134
|
|
|
* Generated from protobuf field <code>bytes extension = 2;</code> |
|
135
|
|
|
* @param string $var |
|
136
|
|
|
* @return $this |
|
137
|
|
|
*/ |
|
138
|
|
|
public function setExtension($var) |
|
139
|
|
|
{ |
|
140
|
|
|
GPBUtil::checkString($var, False); |
|
141
|
|
|
$this->extension = $var; |
|
142
|
|
|
|
|
143
|
|
|
return $this; |
|
144
|
|
|
} |
|
145
|
|
|
|
|
146
|
|
|
} |
|
147
|
|
|
|
|
148
|
|
|
|
americanexpress /
hyperledger-fabric-sdk-php
