Raw ledger provides basic functionality for storing and
retrieving blocks. This is intended to be used by an orderer service
https://jira.hyperledger.org/browse/FAB-56



Change-Id: I3fb733f5be53b6f630c20554ba4e362540b8f55a
Signed-off-by: manish <manish.sethi@gmail.com>

This change-set introduces comments to each of the protobuf for the next fabric
architecture (v1).

Change-Id: I36c556fc9feedf5819742eeb0556f786198b2ded
Signed-off-by: Alessandro Sorniotti <ale.linux@sopit.net>

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

This commit adds a transaction manager (state database) based on CouchDB,
and a sample client to demonstrate/test it.

KVLedger will continue to use file based block storage
for the blockchain, but will use CouchDB as the state database for
simulation and commit.

This experimental feature is enabled via a feature toggle switch in
the code (useCouchDB).

CouchDB must be already installed separately.
There is a script to start CouchDB in dev env and download a docker
image of CouchDB if not already downloaded.  Run this command anywhere
inside the dev env /fabric:
"couchdb start"

To switch ledger to use CouchDB,
update kv_ledger_config.go variable useCouchDB to true.
In kv_ledger.go NewKVLedger(), you will also need to set the CouchDB connection
host, port, db name, id, password if using a non-local secured CouchDB.

This initial commit is only a stand alone ledger prototype and not meant
for end-to-end chaincode processing. That will come in a subsequent commit.

To run the sample:
In CouchDB http://localhost:5984/_utils create a db named marbles_app.
You can do this from your host which has port 5984 mapped to guest 5984
(assuming you have done vagrant up after
https://gerrit.hyperledger.org/r/#/c/1935/

 went in Oct 25th, as that
changeset open up vagrant port 5984).
Then run the sample as follows:
/core/ledgernext/kvledger/marble_example/main$ go run marble_example.go

After running the sample, you can view the marble1 document in CouchDB.
Be sure to delete it in CouchDB if you'd like to re-run the sample.

Change-Id: Iea4f6ad498dc0e637f0254b6f749060e0298622c
Signed-off-by: denyeart <enyeart@us.ibm.com>

This changeset takes the existing work of the config manager, policy
manager, and static genesis block creation and hooks them together into
the main execution path.

Note that the configuration manager is not utilized for any
configuration and there is no policy enforcement for chain
modifications, so this is only a half step, and will be followed by
utilization of the config manager and enforcement of policy on new
transactions.

Note also, that this changeset does not include tests by design, as it
is merely referencing existing pieces of tested code and adds no new
function itself.  All errors in this code path result in panic so the
bdd tests cover it as well.

Change-Id: Ie7f67971fee6c223378612af727e8f9aeca0e48e
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

In order to specify genesis configuration, it must be encoded in the
block in a consumable way.  This configuration must then be stored
in a way accessible to any other components which wish to consume this
configuration.  Further, when new configuration is proposed it must be
validated, and applied or rejected depending on its validity.

This changeset creates a configuration manager which handles all these
tasks.  It allows for registering arbitrary configuration handlers for
different configuration types, and has been designed in concert with the
policy manager to allow the policy manager to be plugged in as a
configuration handler so that policy both enforces what configuration
modifications are allowed and is itself a type of configuration.

Because of the complicated nature of verifying that a configuration is
valid (well formed, not forged or replayed, conforms to existing policy,
and satisfies the assorted handlers) this changeset is unfortunately
large, but is needed to achieve complete code and test coverage of
invalid configurations.

This resolves:

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



Change-Id: I44cbc3f2e5850d8c22977c923c044d353a9bc453
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

FAB-853

Ledger is removed from
   . core/peer/peer.go
   . core/rest/api.go

Ledger package itself is removed. "ledgernext" is
replaced with "ledger".

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

This changeset removes a race condition responsible for the ocassional
failures we see in CI in the TestBroadcast* tests that read from "disk",
the construct that represents the broker's disk where all produced
messages are eventually written to.

The TestBroadcast* tests have been executed 10000 times and do not fail.

Change-Id: I5dea63a52d64171bfd703e5cd053437b0d215cf8
Signed-off-by: Kostas Christidis <kostas@christidis.io>

Change-Id: I79e914a63fe0834e165c799bc39065613ea5d729
Signed-off-by: Gabor Hosszu <gabor@digitalasset.com>

The new project 'fabric-sdk-node' replaces the fabric
sdk/node code so there is no need to keep the old code
in fabric.  See FAB-782.

Change-Id: I143035192386e310d53ce90f2a48b0218f3af83d
Signed-off-by: cdaughtr <cdaughtr@us.ibm.com>

This is part of the v1 fixup, removing unnecessary code from peer
package.  Behave test will be reworked next for endorser.feature.

Change-Id: I415d58bce2177379dc54b82c4679a19a1e4810b0
Signed-off-by: jeffgarratt <garratt.jeff@gmail.com>

This change-set contains the protobuf messages for the
next fabric architecture (v1) as decribed here:
https://hyperledgerproject.slack.com/files/adc/F2JKXGXEU/protobufmessagesandflow.pdf
and incoporates the feedback received from the community
in a change-set previously.
This change-set comes in the context of
https://jira.hyperledger.org/browse/FAB-489

.

Change-Id: Ia602a14292696f6295fcd6b70cdafdae54d3606e
Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>

In order to enforce policy for configuration there must be a policy
manager which tracks the policies and evaluates them.

This policy manager is designed to be updated by the config manager,
which itself depends on the policy manager.  This loop is broken because
the policy manager stands on its own, and validates configuration
changes first, and then is atomically updated to the new policy
configuration if the new config (and policy) is admitted by the existing
policy.

Note that the mechanism for updating policy seems somewhat strange,
namely Begin, Propose, ..., Propose, Commit/Rollback, rather than simply
supplying a new set of policy.  This is done in order to accomodate the
design of the configuration manager (which comes next in this patch
series).

This resolves:

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



Change-Id: Ie4b85aed2622d34e9b29d10c46f39b266ac9a936
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

Allows the network to come up and form a simple p2p system.
This is an interim step to refactoring for the v1 network which
will allow for the existing behave test to be executed after
modification in subsequent changeset.

Change-Id: Ibd0403b32f1f4366fae9d84b1db562a1e4a9a86c
Signed-off-by: jeffgarratt <garratt.jeff@gmail.com>

Had a bug in the pull algorithm:
The NONCE set was actually needed to be split into 2 diff sets,
because servicing sync requests has nothing to do with
initiating them, and the cleanup of initiated sync requests
effected sync requets that were serviced.

Added a unit test that successfully reproduced the bug,
and after I fixed it it always succeeds.

Change-Id: Ie99f41485a41ddb46e99d8fa7d8db408f669b20c
Signed-off-by: Yacov Manevich <yacovm@il.ibm.com>

In order to bootstrap a chain, certain configuration must be embedded in
its genesis block.  This configuration needs to be in a well defined
format so that it is easy for consumers to read.  Further, this
configuration must be able to be modified in the future, so must define
policy which dictates how modification is allowed.

This changeset defines a set of protobuf messages in ab.proto which are
designed to satisfy the above requirements.  The configuration is
essentially a list of configuration items, which have a name (string), a
type (enum), a payload (bytes), and a reference to a modification policy
(string).  Additionally a sequence number scheme is included to prevent
replay.

This changeset also defines a wrapper for the policy configuration item
type.  It references the small proto DSL for signature validation, but
embeds this in a one-of concept in case anyone wishes to swap in other
policy validation schemes.

This is related to, but does not completely satisfy:

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



Change-Id: Id1cb73851a426f903455bb5b4eed552a65cc9327
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

As the complexity in the orderer grows, there is an increasing need to
add new component directories, which do not actually correspond to
different ordering services.

This can be seen with the bootstrap, cauthdsl, and broadcastfilter
directories, and more are on the way.

This changeset simply creates a new common directory, and moves the
common components there.  It also makes trivial updates to import paths,
but otherwise introduces no new features, so does not require new tests.

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



Change-Id: I61e803aa4454926b4ad26610680eb543554346b8
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

This changeset attempts to make a first pass at having a generic enough
to be useful, but not so generic as to be impossible to understand
domain specific language (via protobuf) to express cryptographic
validation schemes.

In particular, the two primitives which comprise a policy are:
    NOutOf(n, []policies)
    SignedBy(id)

Please note that this DSL is relying on the structure imposed by
protobuf, and therefore defines the entire grammar of the DSL in 10
lines.  There is an additional envelope message to allow the
specification to be versioned.

This was developed especially for aiding in specifying bootstrap
configuration for signature policies, however, its applicability for
other areas such as endorsement seems likely.

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



Change-Id: I330b0660caf90b09034e5a1c167c08a5c2078e8f
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

The existing rawledger implementations have a hardcoded genesis block
with non-sense data in it.  In order to support bootstrapping in the
future, this genesis block will need to contain meaningful data, and
hardcoding its contents in the rawledgers is not a viable option.

This changeset moves the static definition into a special static
bootstrap helper package, and removes the references to the static
genesis block from the rawledgers.

Because the rawledgers now need an additional argument for construction,
the effects are felt rippling through the tests, but the changes are
fairly straightforward.

This satisfies JIRA issue:

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



Change-Id: I734a3215998c2977dd16e624869ceeb776767331
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

In order to allow reconfiguration messages to be supported by the
orderer as well as to allow authentication of message signatures from
clients, the ordering service will need to support limited filtering of
broadcast messages as they arrive.

This changeset defines a simple interface for doing so as well as a
structure which supports applying many rules at once.  The solo orderer
is hooked into this framework, but for the moment only supports the
existing behavior of 'Accept all non-empty messages', this will change
once other more sophisticated filters are added.

The hope is that this filtering framework can be re-used across ordering
plugins, especially the component for verifying client signatures on
incoming messages.

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



Change-Id: I534330a1cb2b675c6f34e73079654ab3280520c0
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

FAB-729

1. Port 5984 forwarded from VM to host.
2. `couchdb` script added in devenv/tools/bin to start
    and stop couchdb.

Change-Id: I830b6914422bf6e3d7ffbc7b8fffc8ad736d1f7b
Signed-off-by: Luis Sanchez <sanchezl@us.ibm.com>

Following skeletal end to end flow work, this submit
takes the next steps for Endorser/Committer
  . converts chaincode and endorser to ledgernext
  . removes consensus package
  . chaincode unit tests use ledgernext
  . panics if ledger.GetLedger is called so we
    can catch codepaths that still use that. These
    are mainly core/api and core/peer
  . removes unit tests from core/api and core/ledger
    (to avoid GetLedger calls there)
  . created a minimal core/peernext. core/peer is
    still there for comparison but is not used

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

This applies the following updates

golang 1.7.1
nodejs 6.7.0
ubuntu 16.04
protobuf 3.1.0

All users should vagrant destroy+up after this commit

Change-Id: I4ddb17e1a1c6f42e2bba9459e1192be514580db6
Signed-off-by: Gregory Haskins <gregory.haskins@gmail.com>

Change-Id: Ia0dcd58b57be91f6dcd1117de7f903ed57922065
Signed-off-by: Yacov Manevich <yacovm@il.ibm.com>