The main purpose of this checking
  . show commit followed by simulation in action
  . users can get a feel for the flow of the protocol across
    the different legs of the end-end path
  . identify key areas for attention (esp. grep for
    "!!IMPORTANT!!")

"deploy and "invoke" Chaincode commands from CLI will also
convert a successful proposal response into a transaction
and send it to the Orderer (if configured in core.yaml).

"query" is removed from CLI. Invoke can also return values
now in ProposalResponse.Response.Payload.

REST calls should not be affected and should work with
old ledger.

See core.yaml for default orderer setup.

This also introduces a stop-gap "committer" whose only
task is to commit blocks from the orderer.

To test :
1. Terminal 1 - run the "solo" orderer
   cd fabric/orderer
   go build
   ./orderer

2. Terminal 2 - run the peer
   peer node start 1>/tmp/peer.out 2>&1

3. Terminal 3 - deploy and invoke take usual params
   peer chaincode deploy ... 1>/tmp/out 2>&1
   peer chaincode invoke ... 1>/tmp/out 2>&1

/tmp/peer.out and /tmp/out will contain tell tale signs
of the round trip in action.

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

The ledgernext and kvledger packages provide APIs to simulate
transactions by collecting read-write sets from invokes of
chaincodes. This change set integrates this for the Endorser
flows.  The main purpose of this code is to enable read write
sets to be propagated so end to end flow ending in a commit to
the ledger can be tested.

The chaincode unit tests continue to use the old ledger. This
allows us to (1) incrementally integrate ledger and (2) show
that the two packages can coexist from a build and runtime
point of view.

It is worth noting that the file kv_ledgers.go hosts a temporary
container for ledgers. This simple approach is expected to be
revised when (sub)ledgers are implemented.

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

This patch is for https://jira.hyperledger.org/browse/FAB-181

,
FAB-182.

The patch is around endorser.go which implements the basic
Endorser service. The "peer deploy ..." and "peer invoke .."
CLI driver commands have been modified to redirected to use
endorser.ProcessProposal instead of the original "devops"
calls.

The deploy, invoke (and query) CLI calls are unchanged in
non-dev mode from user point of view - but for one difference.
The response is a ProposalResponse.

In dev mode (ie, when peer is started with --peer-chaincodedev)
the deploy command would need to set "CORE_CHAINCODE_MODE=dev"
in the "peer chaincode deploy ..." command. This is because, the
command now computes the chaincode code just like the SDK as
opposed to leaving it to be done by devops in the peer. Example
CORE_CHAINCODE_MODE=dev CORE_LOGGING_LEVEL=debug ./peer chaincode
deploy -n mycc -c '{"Args":["init","a","100","b","200"]}'

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