consolidate protos/peer proto files

https://jira.hyperledger.org/browse/FAB-1716

remove "fabric_" from filnames.
consolidate files so we don't have so many.
remove unused entries in "fabric.proto".
remove message.proto
remove properties from core.yaml not in use

Change-Id: I0ee8d1bb87bf5cf3ebf9fb8b5e4c7aa30e8c7dcb
Signed-off-by: Srinivasan Muralidharan <muralisr@us.ibm.com>

Author: Srinivasan Muralidharan

core/peer/config.go

@@ -85,17 +85,11 @@ func CacheConfiguration() (err error) {
 	// getPeerEndpoint returns the PeerEndpoint for this Peer instance.  Affected by env:peer.addressAutoDetect
 	getPeerEndpoint := func() (*pb.PeerEndpoint, error) {
 		var peerAddress string
-		var peerType pb.PeerEndpoint_Type
 		peerAddress, err := getLocalAddress()
 		if err != nil {
 			return nil, err
 		}
-		if viper.GetBool("peer.validator.enabled") {
-			peerType = pb.PeerEndpoint_VALIDATOR
-		} else {
-			peerType = pb.PeerEndpoint_NON_VALIDATOR
-		}
-		return &pb.PeerEndpoint{ID: &pb.PeerID{Name: viper.GetString("peer.id")}, Address: peerAddress, Type: peerType}, nil
+		return &pb.PeerEndpoint{ID: &pb.PeerID{Name: viper.GetString("peer.id")}, Address: peerAddress}, nil
 	}
 
 	localAddress, localAddressError = getLocalAddress()

protos/peer/server_admin.pb.go protos/peer/admin.pb.go

@@ -18,7 +18,7 @@ syntax = "proto3";
 
 import "common/common.proto";
 import "peer/chaincodeevent.proto";
-import "peer/fabric_transaction.proto";
+import "peer/transaction.proto";
 
 option go_package = "github.com/hyperledger/fabric/protos/peer";
 

protos/peer/server_admin.proto protos/peer/admin.proto

@@ -19,10 +19,8 @@ option go_package = "github.com/hyperledger/fabric/protos/peer";
 
 package protos;
 
-message PeerAddress {
-    string host = 1;
-    int32 port = 2;
-}
+import "peer/proposal.proto";
+import "peer/proposal_response.proto";
 
 message PeerID {
     string name = 1;
@@ -31,21 +29,6 @@ message PeerID {
 message PeerEndpoint {
     PeerID ID = 1;
     string address = 2;
-    enum Type {
-      UNDEFINED = 0;
-      VALIDATOR = 1;
-      NON_VALIDATOR = 2;
-    }
-    Type type = 3;
-    bytes pkiID = 4;
-}
-
-message PeersMessage {
-    repeated PeerEndpoint peers = 1;
-}
-
-message PeersAddresses {
-    repeated string addresses = 1;
 }
 
 // Contains information about the blockchain ledger such as height, current
@@ -57,3 +40,9 @@ message BlockchainInfo {
     bytes previousBlockHash = 3;
 
 }
+
+//-------- the Endorser service ------------
+
+service Endorser {
+	rpc ProcessProposal(SignedProposal) returns (ProposalResponse) {}
+}

protos/peer/chaincode.pb.go

@@ -20,6 +20,8 @@ option go_package = "github.com/hyperledger/fabric/protos/peer";
 
 package protos;
 
+import "peer/chaincode.proto";
+
 /*
 The flow to get a generic transaction approved goes as follows:
 
@@ -140,3 +142,119 @@ message Proposal {
 	// ChaincodeAction message.
 	bytes extension = 3;
 }
+
+//-------- the Chaincode Proposal -----------
+
+/*
+The flow to get a CHAINCODE transaction approved goes as follows:
+
+1. client sends proposal to endorser
+====================================
+
+The proposal is basically a request to do something on a chaincode, that will
+result on some action - some change in the state of a chaincode and/or some
+data to be committed to the ledger; a proposal in general contains a header
+(with some metadata describing it, such as the type, the identity of the
+invoker, the time, the ID of the chain, a cryptographic nonce..) and a payload
+(the chaincode ID, invocation arguments..). Optionally, it may contain actions
+that the endorser may be asked to endorse, to emulate a submitting peer. A
+chaincode proposal contains the following messages:
+
+SignedProposal
+|\_ Signature                                    (signature on the Proposal message by the creator specified in the header)
+ \_ Proposal
+    |\_ Header                                   (the header for this proposal)
+    |\_ ChaincodeProposalPayload                 (the payload for this proposal)
+     \_ ChaincodeAction                          (the actions for this proposal - optional for a proposal)
+
+2. endorser sends proposal response back to client
+==================================================
+
+The proposal response contains an endorser's response to a client's proposal. A
+proposal response contains a success/error code, a response payload and a
+signature (also referred to as endorsement) over the response payload. The
+response payload contains a hash of the proposal (to securely link this
+response to the corresponding proposal), a description of the action resulting
+from the proposal and the endorser's signature over its payload. Formally, a
+chaincode proposal response contains the following messages:
+
+ProposalResponse
+|\_ Endorsement                                  (the endorser's signature over the whole response payload)
+ \_ ProposalResponsePayload
+     \_ ChaincodeAction                          (the actions for this proposal)
+
+3. client assembles endorsements into a transaction
+===================================================
+
+A transaction message assembles one or more proposals and corresponding
+responses into a message to be sent to orderers. After ordering, (batches of)
+transactions are delivered to committing peers for validation and final
+delivery into the ledger. A transaction contains one or more actions. Each of
+them contains a header (same as that of the proposal that requested it), a
+proposal payload (same as that of the proposal that requested it), a
+description of the resulting action and signatures from each of the endorsers
+that endorsed the action.
+
+SignedTransaction
+|\_ Signature                                    (signature on the Transaction message by the creator specified in the header)
+ \_ Transaction
+     \_ TransactionAction (1...n)
+        |\_ Header (1)                           (the header of the proposal that requested this action)
+         \_ ChaincodeActionPayload (1)
+            |\_ ChaincodeProposalPayload (1)     (payload of the proposal that requested this action)
+             \_ ChaincodeEndorsedAction (1)
+                |\_ Endorsement (1...n)          (endorsers' signatures over the whole response payload)
+                 \_ ProposalResponsePayload
+                     \_ ChaincodeAction          (the actions for this proposal)
+*/
+
+// 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.
+message ChaincodeHeaderExtension {
+
+	// The PayloadVisibility field controls to what extent the Proposal's payload
+	// (recall that for the type CHAINCODE, it is ChaincodeProposalPayload
+	// message) field will be visible in the final transaction and in the ledger.
+	// Ideally, it would be configurable, supporting at least 3 main “visibility
+	// modes”:
+	// 1. all bytes of the payload are visible;
+	// 2. only a hash of the payload is visible;
+	// 3. nothing is visible.
+	// Notice that the visibility function may be potentially part of the ESCC.
+	// In that case it overrides PayloadVisibility field.  Finally notice that
+	// this field impacts the content of ProposalResponsePayload.proposalHash.
+	bytes payloadVisibility = 1;
+
+	// The ID of the chaincode to target.
+	ChaincodeID chaincodeID = 2;
+}
+
+// ChaincodeProposalPayload is the Proposal's payload message to be used when
+// the Header's type is CHAINCODE.  It contains the arguments for this
+// invocation.
+message ChaincodeProposalPayload {
+
+	// Input contains the arguments for this invocation. If this invocation
+	// deploys a new chaincode, ESCC/VSCC are part of this field.
+	bytes Input  = 1;
+
+	// Transient 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.
+	bytes Transient = 2;
+}
+
+// ChaincodeAction contains the actions the events generated by the execution
+// of the chaincode.
+message ChaincodeAction {
+
+	// This field contains the read set and the write set produced by the
+	// chaincode executing this invocation.
+	bytes results = 1;
+
+	// This field contains the events generated by the chaincode executing this
+	// invocation.
+	bytes events = 2;
+}