package protos

Get desktop application:
View/edit binary Protocol Buffers messages

Interface exported by the server.

• rpc GetStatus (common.Envelope, ServerStatus)

  admin.proto:20

• rpc StartServer (common.Envelope, ServerStatus)

  admin.proto:21

• rpc GetModuleLogLevel (common.Envelope, LogLevelResponse)

  admin.proto:22

• rpc SetModuleLogLevel (common.Envelope, LogLevelResponse)

  admin.proto:23

• rpc RevertLogLevels (common.Envelope, google.protobuf.Empty)

  admin.proto:24

• rpc GetLogSpec (common.Envelope, LogSpecResponse)

  admin.proto:25

• rpc SetLogSpec (common.Envelope, LogSpecResponse)

  admin.proto:26

Chaincode as a server - peer establishes a connection to the chaincode as a client Currently only supports a stream connection.

• rpc Connect (stream ChaincodeMessage, stream ChaincodeMessage)

  chaincode_shim.proto:184

Interface that provides support to chaincode execution. ChaincodeContext provides the context necessary for the server to respond appropriately.

• rpc Register (stream ChaincodeMessage, stream ChaincodeMessage)

  chaincode_shim.proto:178

• rpc Deliver (stream common.Envelope, stream DeliverResponse)

  events.proto:69

  Deliver first requires an Envelope of type ab.DELIVER_SEEK_INFO with Payload data as a marshaled orderer.SeekInfo message, then a stream of block replies is received

• rpc DeliverFiltered (stream common.Envelope, stream DeliverResponse)

  events.proto:74

  DeliverFiltered first requires an Envelope of type ab.DELIVER_SEEK_INFO with Payload data as a marshaled orderer.SeekInfo message, then a stream of **filtered** block replies is received

• rpc DeliverWithPrivateData (stream common.Envelope, stream DeliverResponse)

  events.proto:79

  DeliverWithPrivateData first requires an Envelope of type ab.DELIVER_SEEK_INFO with Payload data as a marshaled orderer.SeekInfo message, then a stream of block and private data replies is received

• rpc ProcessProposal (SignedProposal, ProposalResponse)

  peer.proto:16

  message ProposalResponse

  proposal_response.proto:23

  A ProposalResponse is returned from an endorser to the proposal submitter. The idea is that this message contains the endorser's response to the request of a client to perform an action over a chaincode (or more generically on the ledger); the response might be success/error (conveyed in the Response field) together with a description of the action and a signature over it by that endorser. If a sufficient number of distinct endorsers agree on the same action and produce signature to that effect, a transaction can be generated and sent for ordering.

  • int32 version = 1

    Version indicates message protocol version

  • optional google.protobuf.Timestamp timestamp = 2

    Timestamp is the time that the message was created as defined by the sender

  • optional Response response = 4

    A response message indicating whether the endorsement of the action was successful

  • bytes payload = 5

    The payload of response. It is the bytes of ProposalResponsePayload

  • optional Endorsement endorsement = 6

    The endorsement of the proposal, basically the endorser's signature over the payload

• rpc Generate (SignedSnapshotRequest, google.protobuf.Empty)

  snapshot.proto:48

  Generate a snapshot reqeust. SignedSnapshotRequest contains marshalled bytes for SnaphostRequest

• rpc Cancel (SignedSnapshotRequest, google.protobuf.Empty)

  snapshot.proto:50

  Cancel a snapshot reqeust. SignedSnapshotRequest contains marshalled bytes for SnaphostRequest

• rpc QueryPendings (SignedSnapshotRequest, QueryPendingSnapshotsResponse)

  snapshot.proto:52

  Query pending snapshots query. SignedSnapshotRequest contains marshalled bytes for SnaphostQuery

  message QueryPendingSnapshotsResponse

  snapshot.proto:42

  QueryPendingSnapshotsResponse specifies the response payload of a query pending snapshots request

  • repeated uint64 block_numbers = 1

ACLs provides mappings for resources in a channel. APIResource encapsulates reference to a policy used to determine ACL for the resource

• map<string, APIResource> acls = 1

APIResource represents an API resource in the peer whose ACL is determined by the policy_ref field

Used in: ACLs

• string policy_ref = 1

  The policy name to use for this API

• oneof content

  • LogLevelRequest logReq = 1

  • LogSpecRequest logSpecReq = 2

AnchorPeer message structure which provides information about anchor peer, it includes host name, port number and peer certificate.

Used in: AnchorPeers

• string host = 1

  DNS host name of the anchor peer

• int32 port = 2

  The port number

AnchorPeers simply represents list of anchor peers which is used in ConfigurationItem

• repeated AnchorPeer anchor_peers = 1

ApplicationPolicy captures the diffenrent policy types that are set and evaluted at the application level.

Used in: StaticCollectionConfig

• oneof Type

  • common.SignaturePolicyEnvelope signature_policy = 1

    SignaturePolicy type is used if the policy is specified as a combination (using threshold gates) of signatures from MSP principals

  • string channel_config_policy_reference = 2

    ChannelConfigPolicyReference is used when the policy is specified as a string that references a policy defined in the configuration of the channel

BlockAndPrivateData contains Block and a map from tx_seq_in_block to rwset.TxPvtReadWriteSet

Used in: DeliverResponse

• optional common.Block block = 1

• map<uint64, rwset.TxPvtReadWriteSet> private_data_map = 2

  map from tx_seq_in_block to rwset.TxPvtReadWriteSet

CDSData is data stored in the LSCC on instantiation of a CC for CDSPackage. This needs to be serialized for ChaincodeData hence the protobuf format

• bytes hash = 1

  hash of ChaincodeDeploymentSpec.code_package

• bytes metadatahash = 2

  hash of ChaincodeID.name + ChaincodeID.version

ChaincodeAction contains the executed chaincode results, response, and event.

• bytes results = 1

  This field contains the read set and the write set produced by the chaincode executing this invocation.

• bytes events = 2

  This field contains the event generated by the chaincode. Only a single marshaled ChaincodeEvent is included.

• optional Response response = 3

  This field contains the result of executing this invocation.

• optional ChaincodeID chaincode_id = 4

  This field contains the ChaincodeID of executing this invocation. Endorser will set it with the ChaincodeID called by endorser while simulating proposal. Committer will validate the version matching with latest chaincode version. Adding ChaincodeID to keep version opens up the possibility of multiple ChaincodeAction per transaction.

ChaincodeActionPayload is the message to be used for the TransactionAction's payload when the Header's type is set to CHAINCODE. It carries the chaincodeProposalPayload and an endorsed action to apply to the ledger.

• bytes chaincode_proposal_payload = 1

  This field contains the bytes of the ChaincodeProposalPayload message from the original invocation (essentially the arguments) after the application of the visibility function. The main visibility modes are "full" (the entire ChaincodeProposalPayload message is included here), "hash" (only the hash of the ChaincodeProposalPayload message is included) or "nothing". This field will be used to check the consistency of ProposalResponsePayload.proposalHash. For the CHAINCODE type, ProposalResponsePayload.proposalHash is supposed to be H(ProposalHeader || f(ChaincodeProposalPayload)) where f is the visibility function.

• optional ChaincodeEndorsedAction action = 2

  The list of actions to apply to the ledger

ChaincodeData defines the datastructure for chaincodes to be serialized by proto Type provides an additional check by directing to use a specific package after instantiation Data is Type specific (see CDSPackage and SignedCDSPackage)

• string name = 1

  Name of the chaincode

• string version = 2

  Version of the chaincode

• string escc = 3

  Escc for the chaincode instance

• string vscc = 4

  Vscc for the chaincode instance

• optional common.SignaturePolicyEnvelope policy = 5

  Policy endorsement policy for the chaincode instance

• bytes data = 6

  Data data specific to the package

• bytes id = 7

  Id of the chaincode that's the unique fingerprint for the CC This is not currently used anywhere but serves as a good eyecatcher

• optional common.SignaturePolicyEnvelope instantiation_policy = 8

  InstantiationPolicy for the chaincode

Specify the deployment of a chaincode. TODO: Define `codePackage`.

• optional ChaincodeSpec chaincode_spec = 1

• bytes code_package = 3

ChaincodeEndorsedAction carries information about the endorsement of a specific proposal

Used in: ChaincodeActionPayload

• bytes proposal_response_payload = 1

  This is the bytes of the ProposalResponsePayload message signed by the endorsers. Recall that for the CHAINCODE type, the ProposalResponsePayload's extenstion field carries a ChaincodeAction

• repeated Endorsement endorsements = 2

  The endorsement of the proposal, basically the endorser's signature over proposalResponsePayload

ChaincodeEndorsement instructs the peer how transactions should be endorsed. The only endorsement mechanism which ships with the fabric today is the standard 'escc' mechanism. This code simply simulates the proposal to generate a RW set, then signs the result using the peer's local signing identity.

• string name = 1

  Specifies what code to run for endorsements, defaults 'escc'

ChaincodeEvent is used for events and registrations that are specific to chaincode string type - "chaincode"

Used in: ChaincodeMessage, FilteredChaincodeAction

• string chaincode_id = 1

• string tx_id = 2

• string event_name = 3

• bytes payload = 4

ChaincodeHeaderExtension is the Header's extentions message to be used when the Header's type is CHAINCODE. This extensions is used to specify which chaincode to invoke and what should appear on the ledger.

• optional ChaincodeID chaincode_id = 2

  The ID of the chaincode to target.

ChaincodeID contains the path as specified by the deploy transaction that created it as well as the hashCode that is generated by the system for the path. From the user level (ie, CLI, REST API and so on) deploy transaction is expected to provide the path and other requests are expected to provide the hashCode. The other value will be ignored. Internally, the structure could contain both values. For instance, the hashCode will be set when first generated using the path

Used in: ChaincodeAction, ChaincodeHeaderExtension, ChaincodeSpec

• string path = 1

  deploy transaction will use the path

• string name = 2

  all other requests will use the name (really a hashcode) generated by the deploy transaction

• string version = 3

  user friendly version name for the chaincode

ChaincodeIdentifier identifies a piece of chaincode. For a peer to accept invocations of this chaincode, the hash of the installed code must match, as must the version string included with the install command.

• bytes hash = 1

  The hash of the chaincode bytes

• string version = 2

  A user friendly human readable name corresponding to the ID

ChaincodeInfo contains general information about an installed/instantiated chaincode

Used in: ChaincodeQueryResponse

• string name = 1

• string version = 2

• string path = 3

  the path as specified by the install/instantiate transaction

• string input = 4

  the chaincode function upon instantiation and its arguments. This will be blank if the query is returning information about installed chaincodes.

• string escc = 5

  the name of the ESCC for this chaincode. This will be blank if the query is returning information about installed chaincodes.

• string vscc = 6

  the name of the VSCC for this chaincode. This will be blank if the query is returning information about installed chaincodes.

• bytes id = 7

  the chaincode unique id. computed as: H( H(name || version) || H(CodePackage) )

Carries the chaincode function and its arguments. UnmarshalJSON in transaction.go converts the string-based REST/JSON input to the []byte-based current ChaincodeInput structure.

Used in: ChaincodeSpec

• repeated bytes args = 1

• map<string, bytes> decorations = 2

• bool is_init = 3

  is_init is used for the application to signal that an invocation is to be routed to the legacy 'Init' function for compatibility with chaincodes which handled Init in the old way. New applications should manage their initialized state themselves.

Carries the chaincode function and its arguments.

• optional ChaincodeSpec chaincode_spec = 1

Used as request type in: Chaincode.Connect, ChaincodeSupport.Register

Used as response type in: Chaincode.Connect, ChaincodeSupport.Register

• ChaincodeMessage.Type type = 1

• optional google.protobuf.Timestamp timestamp = 2

• bytes payload = 3

• string txid = 4

• optional SignedProposal proposal = 5

• optional ChaincodeEvent chaincode_event = 6

  event emitted by chaincode. Used only with Init or Invoke. This event is then stored (currently) with Block.NonHashData.TransactionResult

• string channel_id = 7

  channel id

Used in: ChaincodeMessage

• UNDEFINED = 0

• REGISTER = 1

• REGISTERED = 2

• INIT = 3

• READY = 4

• TRANSACTION = 5

• COMPLETED = 6

• ERROR = 7

• GET_STATE = 8

• PUT_STATE = 9

• DEL_STATE = 10

• INVOKE_CHAINCODE = 11

• RESPONSE = 13

• GET_STATE_BY_RANGE = 14

• GET_QUERY_RESULT = 15

• QUERY_STATE_NEXT = 16

• QUERY_STATE_CLOSE = 17

• KEEPALIVE = 18

• GET_HISTORY_FOR_KEY = 19

• GET_STATE_METADATA = 20

• PUT_STATE_METADATA = 21

• GET_PRIVATE_DATA_HASH = 22

ChaincodeProposalPayload is the Proposal's payload message to be used when the Header's type is CHAINCODE. It contains the arguments for this invocation.

• bytes input = 1

  Input contains the arguments for this invocation. If this invocation deploys a new chaincode, ESCC/VSCC are part of this field. This is usually a marshaled ChaincodeInvocationSpec

• map<string, bytes> TransientMap = 2

  TransientMap contains data (e.g. cryptographic material) that might be used to implement some form of application-level confidentiality. The contents of this field are supposed to always be omitted from the transaction and excluded from the ledger.

ChaincodeQueryResponse returns information about each chaincode that pertains to a query in lscc.go, such as GetChaincodes (returns all chaincodes instantiated on a channel), and GetInstalledChaincodes (returns all chaincodes installed on a peer)

• repeated ChaincodeInfo chaincodes = 1

Carries the chaincode specification. This is the actual metadata required for defining a chaincode.

Used in: ChaincodeDeploymentSpec, ChaincodeInvocationSpec

• ChaincodeSpec.Type type = 1

• optional ChaincodeID chaincode_id = 2

• optional ChaincodeInput input = 3

• int32 timeout = 4

Used in: ChaincodeSpec

• UNDEFINED = 0

• GOLANG = 1

• NODE = 2

• CAR = 3

• JAVA = 4

ChaincodeValidation instructs the peer how transactions for this chaincode should be validated. The only validation mechanism which ships with fabric today is the standard 'vscc' validation mechanism. This built in validation method utilizes an endorsement policy which checks that a sufficient number of signatures have been included. The 'arguement' field encodes any parameters required by the validation implementation.

• string name = 1

  Specifies which code to run to validate transactions, defaults to 'vscc'

• bytes argument = 2

  When 'vscc' a marshaled VSCCArgs

ChannelInfo contains general information about channels

Used in: ChannelQueryResponse

• string channel_id = 1

ChannelQueryResponse returns information about each channel that pertains to a query in lscc.go, such as GetChannels (returns all channels for a given peer)

• repeated ChannelInfo channels = 1

CollectionConfig defines the configuration of a collection object; it currently contains a single, static type. Dynamic collections are deferred.

Used in: CollectionConfigPackage

• oneof payload

  • StaticCollectionConfig static_collection_config = 1

CollectionConfigPackage represents an array of CollectionConfig messages; the extra struct is required because repeated oneof is forbidden by the protobuf syntax

Used in: gossip.PrivatePayload, lifecycle.ApproveChaincodeDefinitionForMyOrgArgs, lifecycle.CheckCommitReadinessArgs, lifecycle.CommitChaincodeDefinitionArgs, lifecycle.QueryApprovedChaincodeDefinitionResult, lifecycle.QueryChaincodeDefinitionResult, lifecycle.QueryChaincodeDefinitionsResult.ChaincodeDefinition, transientstore.TxPvtReadWriteSetWithConfigInfo

• repeated CollectionConfig config = 1

Collection policy configuration. Initially, the configuration can only contain a SignaturePolicy. In the future, the SignaturePolicy may be a more general Policy. Instead of containing the actual policy, the configuration may in the future contain a string reference to a policy.

Used in: StaticCollectionConfig

• oneof payload

  • common.SignaturePolicyEnvelope signature_policy = 1

    Initially, only a signature policy is supported.

    Later, the SignaturePolicy will be replaced by a Policy. Policy policy = 1; A reference to a Policy is planned to be added later. string reference = 2;

ConfigTree encapsulates channel and resources configuration of a channel. Both configurations are represented as common.Config

• optional common.Config channel_config = 1

• optional common.Config resources_config = 2

DelState is the payload of a ChaincodeMessage. It contains a key which needs to be recorded in the transaction's write set as a delete operation. If the collection is specified, the key needs to be recorded in the transaction's private write set as a delete operation.

• string key = 1

• string collection = 2

DeliverResponse

Used as response type in: Deliver.Deliver, Deliver.DeliverFiltered, Deliver.DeliverWithPrivateData

• oneof Type

  • common.Status status = 1

  • common.Block block = 2

  • FilteredBlock filtered_block = 3

  • BlockAndPrivateData block_and_private_data = 4

An endorsement is a signature of an endorser over a proposal response. By producing an endorsement message, an endorser implicitly "approves" that proposal response and the actions contained therein. When enough endorsements have been collected, a transaction can be generated out of a set of proposal responses. Note that this message only contains an identity and a signature but no signed payload. This is intentional because endorsements are supposed to be collected in a transaction, and they are all expected to endorse a single proposal response/action (many endorsements over a single proposal response)

Used in: ChaincodeEndorsedAction, ProposalResponse, SignedChaincodeDeploymentSpec

• bytes endorser = 1

  Identity of the endorser (e.g. its certificate)

• bytes signature = 2

  Signature of the payload included in ProposalResponse concatenated with the endorser's certificate; ie, sign(ProposalResponse.payload + endorser)

FilteredBlock is a minimal set of information about a block

Used in: DeliverResponse

• string channel_id = 1

• uint64 number = 2

  The position in the blockchain

• repeated FilteredTransaction filtered_transactions = 4

FilteredChaincodeAction is a minimal set of information about an action within a transaction

Used in: FilteredTransactionActions

• optional ChaincodeEvent chaincode_event = 1

FilteredTransaction is a minimal set of information about a transaction within a block

Used in: FilteredBlock

• string txid = 1

• common.HeaderType type = 2

• TxValidationCode tx_validation_code = 3

• oneof Data

  • FilteredTransactionActions transaction_actions = 4

FilteredTransactionActions is a wrapper for array of TransactionAction message from regular block

Used in: FilteredTransaction

• repeated FilteredChaincodeAction chaincode_actions = 1

GetHistoryForKey is the payload of a ChaincodeMessage. It contains a key for which the historical values need to be retrieved.

• string key = 1

GetQueryResult is the payload of a ChaincodeMessage. It contains a query string in the form that is supported by the underlying state database. If the collection is specified, the query needs to be executed on the private data. The metadata hold the byte representation of QueryMetadata.

• string query = 1

• string collection = 2

• bytes metadata = 3

GetState is the payload of a ChaincodeMessage. It contains a key which is to be fetched from the ledger. If the collection is specified, the key would be fetched from the collection (i.e., private state)

• string key = 1

• string collection = 2

GetStateByRange is the payload of a ChaincodeMessage. It contains a start key and a end key required to execute range query. If the collection is specified, the range query needs to be executed on the private data. The metadata hold the byte representation of QueryMetadata.

• string startKey = 1

• string endKey = 2

• string collection = 3

• bytes metadata = 4

• string key = 1

• string collection = 2

JoinBySnapshotStatus contains information about whether or a JoinBySnapshot operation is in progress and the related bootstrap dir if it is running.

• bool in_progress = 1

• string bootstrapping_snapshot_dir = 2

LifecycleEvent is used as the payload of the chaincode event emitted by LSCC

• string chaincode_name = 1

Used in: AdminOperation

• string log_module = 1

• string log_level = 2

Used as response type in: Admin.GetModuleLogLevel, Admin.SetModuleLogLevel

• string log_module = 1

• string log_level = 2

Used in: AdminOperation

• string log_spec = 1

Used as response type in: Admin.GetLogSpec, Admin.SetLogSpec

• string log_spec = 1

• string error = 2

Reserved entries in the key-level metadata map

• VALIDATION_PARAMETER = 0

• VALIDATION_PARAMETER_V2 = 1

ProcessedTransaction wraps an Envelope that includes a transaction along with an indication of whether the transaction was validated or invalidated by committing peer. The use case is that GetTransactionByID API needs to retrieve the transaction Envelope from block storage, and return it to a client, and indicate whether the transaction was validated or invalidated by committing peer. So that the originally submitted transaction Envelope is not modified, the ProcessedTransaction wrapper is returned.

• optional common.Envelope transactionEnvelope = 1

  An Envelope which includes a processed transaction

• int32 validationCode = 2

  An indication of whether the transaction was validated or invalidated by committing peer

A Proposal is sent to an endorser for endorsement. The proposal contains: 1. A header which should be unmarshaled to a Header message. Note that Header is both the header of a Proposal and of a Transaction, in that i) both headers should be unmarshaled to this message; and ii) it is used to compute cryptographic hashes and signatures. The header has fields common to all proposals/transactions. In addition it has a type field for additional customization. An example of this is the ChaincodeHeaderExtension message used to extend the Header for type CHAINCODE. 2. A payload whose type depends on the header's type field. 3. An extension whose type depends on the header's type field. Let us see an example. For type CHAINCODE (see the Header message), we have the following: 1. The header is a Header message whose extensions field is a ChaincodeHeaderExtension message. 2. The payload is a ChaincodeProposalPayload message. 3. The extension is a ChaincodeAction that might be used to ask the endorsers to endorse a specific ChaincodeAction, thus emulating the submitting peer model.

• bytes header = 1

  The header of the proposal. It is the bytes of the Header

• bytes payload = 2

  The payload of the proposal as defined by the type in the proposal header.

• bytes extension = 3

  Optional extensions to the proposal. Its content depends on the Header's type field. For the type CHAINCODE, it might be the bytes of a ChaincodeAction message.

ProposalResponsePayload is the payload of a proposal response. This message is the "bridge" between the client's request and the endorser's action in response to that request. Concretely, for chaincodes, it contains a hashed representation of the proposal (proposalHash) and a representation of the chaincode state changes and events inside the extension field.

• bytes proposal_hash = 1

  Hash of the proposal that triggered this response. The hash is used to link a response with its proposal, both for bookeeping purposes on an asynchronous system and for security reasons (accountability, non-repudiation). The hash usually covers the entire Proposal message (byte-by-byte).

• bytes extension = 2

  Extension should be unmarshaled to a type-specific message. The type of the extension in any proposal response depends on the type of the proposal that the client selected when the proposal was initially sent out. In particular, this information is stored in the type field of a Header. For chaincode, it's a ChaincodeAction message

PutState is the payload of a ChaincodeMessage. It contains a key and value which needs to be written to the transaction's write set. If the collection is specified, the key and value would be written to the transaction's private write set.

• string key = 1

• bytes value = 2

• string collection = 3

• string key = 1

• string collection = 3

• optional StateMetadata metadata = 4

QueryMetadata is the metadata of a GetStateByRange and GetQueryResult. It contains a pageSize which denotes the number of records to be fetched and a bookmark.

• int32 pageSize = 1

• string bookmark = 2

QueryResponse is returned by the peer as a result of a GetStateByRange, GetQueryResult, and GetHistoryForKey. It holds a bunch of records in results field, a flag to denote whether more results need to be fetched from the peer in has_more field, transaction id in id field, and a QueryResponseMetadata in metadata field.

• repeated QueryResultBytes results = 1

• bool has_more = 2

• string id = 3

• bytes metadata = 4

QueryResponseMetadata is the metadata of a QueryResponse. It contains a count which denotes the number of records fetched from the ledger and a bookmark.

• int32 fetched_records_count = 1

• string bookmark = 2

QueryResultBytes hold the byte representation of a record returned by the peer.

Used in: QueryResponse

• bytes resultBytes = 1

• string id = 1

• string id = 1

A response with a representation similar to an HTTP response that can be used within another message.

Used in: ChaincodeAction, ProposalResponse

• int32 status = 1

  A status code that should follow the HTTP status codes.

• string message = 2

  A message associated with the response code.

• bytes payload = 3

  A payload that can be used to include metadata with this response.

Used as response type in: Admin.GetStatus, Admin.StartServer

• ServerStatus.StatusCode status = 1

Used in: ServerStatus

• UNDEFINED = 0

• STARTED = 1

• STOPPED = 2

• PAUSED = 3

• ERROR = 4

• UNKNOWN = 5

SignedChaincodeDeploymentSpec carries the CDS along with endorsements

• bytes chaincode_deployment_spec = 1

  This is the bytes of the ChaincodeDeploymentSpec

• bytes instantiation_policy = 2

  This is the instantiation policy which is identical in structure to endorsement policy. This policy is checked by the VSCC at commit time on the instantiation (all peers will get the same policy as it will be part of the LSCC instantation record and will be part of the hash as well)

• repeated Endorsement owner_endorsements = 3

  The endorsements of the above deployment spec, the owner's signature over chaincode_deployment_spec and Endorsement.endorser.

This structure is necessary to sign the proposal which contains the header and the payload. Without this structure, we would have to concatenate the header and the payload to verify the signature, which could be expensive with large payload When an endorser receives a SignedProposal message, it should verify the signature over the proposal bytes. This verification requires the following steps: 1. Verification of the validity of the certificate that was used to produce the signature. The certificate will be available once proposalBytes has been unmarshalled to a Proposal message, and Proposal.header has been unmarshalled to a Header message. While this unmarshalling-before-verifying might not be ideal, it is unavoidable because i) the signature needs to also protect the signing certificate; ii) it is desirable that Header is created once by the client and never changed (for the sake of accountability and non-repudiation). Note also that it is actually impossible to conclusively verify the validity of the certificate included in a Proposal, because the proposal needs to first be endorsed and ordered with respect to certificate expiration transactions. Still, it is useful to pre-filter expired certificates at this stage. 2. Verification that the certificate is trusted (signed by a trusted CA) and that it is allowed to transact with us (with respect to some ACLs); 3. Verification that the signature on proposalBytes is valid; 4. Detect replay attacks;

Used as request type in: Endorser.ProcessProposal

Used as field type in: ChaincodeMessage

• bytes proposal_bytes = 1

  The bytes of Proposal

• bytes signature = 2

  Signaure over proposalBytes; this signature is to be verified against the creator identity contained in the header of the Proposal message marshaled as proposalBytes

SignedSnapshotRequest contains marshalled request bytes and signature

Used as request type in: Snapshot.Cancel, Snapshot.Generate, Snapshot.QueryPendings

• bytes request = 1

  The bytes of SnapshotRequest or SnapshotQuery

• bytes signature = 2

  Signaure over request bytes; this signature is to be verified against the client identity

SnapshotQuery contains information for a query snapshot request

• optional common.SignatureHeader signature_header = 1

  The signature header that contains creator identity and nonce

• string channel_id = 2

  The channel ID

SnapshotRequest contains information for a generate/cancel snapshot request

• optional common.SignatureHeader signature_header = 1

  The signature header that contains creator identity and nonce

• string channel_id = 2

  The channel ID

• uint64 block_number = 3

  The block number to generate a snapshot

Used in: PutStateMetadata, StateMetadataResult

• string metakey = 1

• bytes value = 2

• repeated StateMetadata entries = 1

StaticCollectionConfig constitutes the configuration parameters of a static collection object. Static collections are collections that are known at chaincode instantiation time, and that cannot be changed. Dynamic collections are deferred.

Used in: CollectionConfig

• string name = 1

  the name of the collection inside the denoted chaincode

• optional CollectionPolicyConfig member_orgs_policy = 2

  a reference to a policy residing / managed in the config block to define which orgs have access to this collection’s private data

• int32 required_peer_count = 3

  The minimum number of peers private data will be sent to upon endorsement. The endorsement would fail if dissemination to at least this number of peers is not achieved.

• int32 maximum_peer_count = 4

  The maximum number of peers that private data will be sent to upon endorsement. This number has to be bigger than required_peer_count.

• uint64 block_to_live = 5

  The number of blocks after which the collection data expires. For instance if the value is set to 10, a key last modified by block number 100 will be purged at block number 111. A zero value is treated same as MaxUint64

• bool member_only_read = 6

  The member only read access denotes whether only collection member clients can read the private data (if set to true), or even non members can read the data (if set to false, for example if you want to implement more granular access logic in the chaincode)

• bool member_only_write = 7

  The member only write access denotes whether only collection member clients can write the private data (if set to true), or even non members can write the data (if set to false, for example if you want to implement more granular access logic in the chaincode)

• optional ApplicationPolicy endorsement_policy = 8

  a reference to a policy residing / managed in the config block to define the endorsement policy for this collection

The transaction to be sent to the ordering service. A transaction contains one or more TransactionAction. Each TransactionAction binds a proposal to potentially multiple actions. The transaction is atomic meaning that either all actions in the transaction will be committed or none will. Note that while a Transaction might include more than one Header, the Header.creator field must be the same in each. A single client is free to issue a number of independent Proposal, each with their header (Header) and request payload (ChaincodeProposalPayload). Each proposal is independently endorsed generating an action (ProposalResponsePayload) with one signature per Endorser. Any number of independent proposals (and their action) might be included in a transaction to ensure that they are treated atomically.

• repeated TransactionAction actions = 1

  The payload is an array of TransactionAction. An array is necessary to accommodate multiple actions per transaction

TransactionAction binds a proposal to its action. The type field in the header dictates the type of action to be applied to the ledger.

Used in: Transaction

• bytes header = 1

  The header of the proposal action, which is the proposal header

• bytes payload = 2

  The payload of the action as defined by the type in the header For chaincode, it's the bytes of ChaincodeActionPayload

Used in: FilteredTransaction

• VALID = 0

• NIL_ENVELOPE = 1

• BAD_PAYLOAD = 2

• BAD_COMMON_HEADER = 3

• BAD_CREATOR_SIGNATURE = 4

• INVALID_ENDORSER_TRANSACTION = 5

• INVALID_CONFIG_TRANSACTION = 6

• UNSUPPORTED_TX_PAYLOAD = 7

• BAD_PROPOSAL_TXID = 8

• DUPLICATE_TXID = 9

• ENDORSEMENT_POLICY_FAILURE = 10

• MVCC_READ_CONFLICT = 11

• PHANTOM_READ_CONFLICT = 12

• UNKNOWN_TX_TYPE = 13

• TARGET_CHAIN_NOT_FOUND = 14

• MARSHAL_TX_ERROR = 15

• NIL_TXACTION = 16

• EXPIRED_CHAINCODE = 17

• CHAINCODE_VERSION_CONFLICT = 18

• BAD_HEADER_EXTENSION = 19

• BAD_CHANNEL_HEADER = 20

• BAD_RESPONSE_PAYLOAD = 21

• BAD_RWSET = 22

• ILLEGAL_WRITESET = 23

• INVALID_WRITESET = 24

• INVALID_CHAINCODE = 25

• NOT_VALIDATED = 254

• INVALID_OTHER_REASON = 255

VSCCArgs is passed (marshaled) as a parameter to the VSCC imlementation via the argument field of the ChaincodeValidation message.

• string endorsement_policy_ref = 1

  A named reference to an endorsement policy,