github.com/kchristidis/fabric@v1.0.4-0.20171028114726-837acd08cde1/protos/peer/proposal_response.proto (about) 1 /* 2 Copyright IBM Corp. 2016 All Rights Reserved. 3 4 Licensed under the Apache License, Version 2.0 (the "License"); 5 you may not use this file except in compliance with the License. 6 You may obtain a copy of the License at 7 8 http://www.apache.org/licenses/LICENSE-2.0 9 10 Unless required by applicable law or agreed to in writing, software 11 distributed under the License is distributed on an "AS IS" BASIS, 12 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 13 See the License for the specific language governing permissions and 14 limitations under the License. 15 */ 16 17 syntax = "proto3"; 18 19 option go_package = "github.com/hyperledger/fabric/protos/peer"; 20 option java_package = "org.hyperledger.fabric.protos.peer"; 21 option java_outer_classname = "ProposalResponsePackage"; 22 23 package protos; 24 25 import "google/protobuf/timestamp.proto"; 26 27 // A ProposalResponse is returned from an endorser to the proposal submitter. 28 // The idea is that this message contains the endorser's response to the 29 // request of a client to perform an action over a chaincode (or more 30 // generically on the ledger); the response might be success/error (conveyed in 31 // the Response field) together with a description of the action and a 32 // signature over it by that endorser. If a sufficient number of distinct 33 // endorsers agree on the same action and produce signature to that effect, a 34 // transaction can be generated and sent for ordering. 35 message ProposalResponse { 36 37 // Version indicates message protocol version 38 int32 version = 1; 39 40 // Timestamp is the time that the message 41 // was created as defined by the sender 42 google.protobuf.Timestamp timestamp = 2; 43 44 // A response message indicating whether the 45 // endorsement of the action was successful 46 Response response = 4; 47 48 // The payload of response. It is the bytes of ProposalResponsePayload 49 bytes payload = 5; 50 51 // The endorsement of the proposal, basically 52 // the endorser's signature over the payload 53 Endorsement endorsement = 6; 54 } 55 56 // A response with a representation similar to an HTTP response that can 57 // be used within another message. 58 message Response { 59 60 // A status code that should follow the HTTP status codes. 61 int32 status = 1; 62 63 // A message associated with the response code. 64 string message = 2; 65 66 // A payload that can be used to include metadata with this response. 67 bytes payload = 3; 68 } 69 70 // ProposalResponsePayload is the payload of a proposal response. This message 71 // is the "bridge" between the client's request and the endorser's action in 72 // response to that request. Concretely, for chaincodes, it contains a hashed 73 // representation of the proposal (proposalHash) and a representation of the 74 // chaincode state changes and events inside the extension field. 75 message ProposalResponsePayload { 76 77 // Hash of the proposal that triggered this response. The hash is used to 78 // link a response with its proposal, both for bookeeping purposes on an 79 // asynchronous system and for security reasons (accountability, 80 // non-repudiation). The hash usually covers the entire Proposal message 81 // (byte-by-byte). However this implies that the hash can only be verified 82 // if the entire proposal message is available when ProposalResponsePayload is 83 // included in a transaction or stored in the ledger. For confidentiality 84 // reasons, with chaincodes it might be undesirable to store the proposal 85 // payload in the ledger. If the type is CHAINCODE, this is handled by 86 // separating the proposal's header and 87 // the payload: the header is always hashed in its entirety whereas the 88 // payload can either be hashed fully, or only its hash may be hashed, or 89 // nothing from the payload can be hashed. The PayloadVisibility field in the 90 // Header's extension controls to which extent the proposal payload is 91 // "visible" in the sense that was just explained. 92 bytes proposal_hash = 1; 93 94 // Extension should be unmarshaled to a type-specific message. The type of 95 // the extension in any proposal response depends on the type of the proposal 96 // that the client selected when the proposal was initially sent out. In 97 // particular, this information is stored in the type field of a Header. For 98 // chaincode, it's a ChaincodeAction message 99 bytes extension = 2; 100 } 101 102 // An endorsement is a signature of an endorser over a proposal response. By 103 // producing an endorsement message, an endorser implicitly "approves" that 104 // proposal response and the actions contained therein. When enough 105 // endorsements have been collected, a transaction can be generated out of a 106 // set of proposal responses. Note that this message only contains an identity 107 // and a signature but no signed payload. This is intentional because 108 // endorsements are supposed to be collected in a transaction, and they are all 109 // expected to endorse a single proposal response/action (many endorsements 110 // over a single proposal response) 111 message Endorsement { 112 113 // Identity of the endorser (e.g. its certificate) 114 bytes endorser = 1; 115 116 // Signature of the payload included in ProposalResponse concatenated with 117 // the endorser's certificate; ie, sign(ProposalResponse.payload + endorser) 118 bytes signature = 2; 119 }