- Updated the orderer's file ledger to use it's underlying
  blockstore ledger impl's iterator APIs.
- Blockstore iterators must be explicitly closed to avoid
  leaking resources, so now orderer/ledger.Iterator must
  also be explicitly closed. Added Close() to the
  orderer/ledger.Iterator interface.

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

This patchset also cleans up the test style to use assert,
as well as moving some factory-specific tests to its own
test file from impl test file.

Change-Id: I02e6c5e364b3e5ae254c45853595acd32eabcd7b
Signed-off-by: Jay Guo <guojiannan1101@gmail.com>

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



This changeset:

1. Removes the stuttering that was prevalent in filenames and package
names throughout the package
2. Updates function definitions where appropriate
3. Makes the layout of "ram" and "json" implementation consistent with
the "file" one by moving the relevant functions to `factory.go`
4. Switches all panic calls to their logger-equivalents. (We will be
doing this for all packages inside `orderer`.)
5. Per Binh's request: creates paths via the `filepath.Join` call

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

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



 - orderer "file" ledger renamed to "json".
 - For now, "json" and "file" are synonymous values
   when specifiying LedgerType in orderer.yml.
 - The "json" ledger type re-uses the FileLedger
   configuration section in orderer.yml.

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

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



A few things changed according to FAB-1390 description and the latest NCAP
1. renamed RawLedger interface to OrdererLedger
2. added PeerLedger interface which keeps a bitmask to indicate invalid transactions as described in NCAP
3. changed ledger API description in Next-Ledger-Architecture-Proposal
4. refactored rawledger package to ordererledger in orderer directory

Please notice that with this change set, there'll be cases of inconsistent package names with import path.
This is a tradeoff to avoid stuttering path names
These cases are listed as below.

Package name, import path
(ordererledger, github.com/hyperledger/fabric/orderer/ledger)
(ramledger, github.com/hyperledger/fabric/orderer/ledger/ram)
(fileledger, github.com/hyperledger/fabric/orderer/ledger/file)

Change-Id: Ie9580678ee9012ff865d1dc507066f46e106f250
Signed-off-by: Xi Xue Jia <xixuejia@gmail.com>

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



The rawledger interface was originally implemented as a single chain
initialized with a genesis block. This causes problems on restart
because a newer genesis block may already exist and passing the genesis
block becomes nonsensical.

This changeset changes this behavior to intialize no ledgers on factory
creation, and to allow the use of Append for blocks, rather than
transaction sets.  This satisfies a secondary goal of allowing block
creation without block commit, as is required by the SBFT flow of
consenting on blocks, rather than on transactions.

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

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



The orderer code has taken an ad-hoc approach to logging during
construction.  This changeset unifies the logging across the common
components, solo, and kafka.  It deliberately does not touch the sbft
portion of the package so as not to disrupt its development until it is
ready to move onto the common config and common code.

Note that this moves flogging into the common package, and splits the
LoggingInit into two pieces.  The peer assumes a single global viper and
peer specific config structures.  This dependency leaked into flogging,
but in reality, the spec should probably be passed from the peer to
flogging, rather than having flogging interrogate the configuration
itself.  This would however have balooned the changeset, so it is left
as is for now.

Revision 3: Per feedback from Kostas, fixed the stuttering which was
prevalent in the flogging package.
Revision 4: Fix linting errors
Revision 6: Fix rebasing bugs which balooned the diff

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

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



The deliver API currently works on a windowing concept.  Because of the
HTTP2/gRPC internal windowing, this additional layer of windowing is
unnecessary.

This changeset removes the notion of a Window from Deliver and instead
replaces it with a start and stop position specification.  To receive
blocks indefinitely (replicating the old behavior with ACKs) the end
position may be specified as MAX_UINT64.

This changeset has an unfortunately high amount of ripple, and required
extensive rework in the bdd tests, but the overall changeset is a
simplification.

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

The multichain integration in https://gerrit.hyperledger.org/r/#/c/2721/


hooked the multi-chain manager into the default solo path.  This was
attempted in a way which kept the diff minimal, but correspondingly
produced some unpleasant artifacts in the code.

In particular, the integration used one catch-all interface in
multichain.Manager to supply support to the various components, this
meant that components were forced to drag in unnecessary imports and it
complicated mock testing with many panic-ing unimplemented functions.

This changeset breaks this interface into pieces, and pushes the
definition of the interface back into the components which depend on the
definition.

Also included in this changeset is substantial cleanup of the
solo/consenter_test.go file. This set of tests was originally written in
a way which depended on the end to end flow of the system, but as the
common components have been factored out, and as the solo 'consensus'
has been reduced to its simplest component, more targetted tests are now
needed.

Also included are some assorted linting fixes.

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

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



Most of the changes are syntactical and are helped by go's
strict type checking. The changes follow the simple change
of
   bytes chainID
to
   string chainID
in protos/common/common.proto.

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

The orderer components have been being slowly transformed to accomodate
multiple chain IDs.  However, in order to utilize these components in a
true multi-chain system, their external APIs must expose their backing
chain IDs.

This changeset adds simple Getters for the chain ids associated with the
configuration manager and the rawledgers.

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

SBFT needs to persist its own batch headers and signatures on its ledger
(Rawledger, implementations: Fileledger, Ramledger). Rawledger interface
needs to be modified to accept custom metadata where those objects can
be stored.


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

The original rawledger interface only supports a single chain.  However,
to support multiple chains, this interface must be extended to support
multiple chains.  This changeset creates a Factory interface for the
rawledger which supports the method GetOrCreate which will get the
ledger if it already exists, or create a new one if not.

In order to preserve some backwards compatability, and to support the
notion of multi-chain more generally in the future with an ordering
system chain, the factories accept a genesis block to seed the ordering
system chain with.

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

In order to have consistent error reporting across the fabric, it has
been decided to use standard HTTP status codes.  These were defined in
the orderer ab.proto, but have wider applicability.

This changeset removes the Status message from ab.proto and moves it to
common.proto.

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

This commit begins the work of codifying a single set of common protos
which both the orderer and fabric access, plus a specific set of orderer
protos which are necessary to interact with the ordering service.  In
the future, it is expected that the peer protos will go into their own
directory (importing the common protos).

This changeset looks a little scarier than it is, because the effects of
changing these paths are far reaching indeed, but should be relatively
easy to review.

Note that this is the first ever cross-directory-dependent protos
included in the fabric.  This means the generation incantations change a
little.  Instead of importing the directory which contains the protos,
instead, a common root directory must be picked.

The compile_protos.sh has been changed to look for .protoroot files and
if present use this as the proto compilation root, rather than the
directory containing the proto.

Change-Id: I619ea2c50ffd450640dafbddc7d7e5f34f809f3b
Signed-of...

This is the a proposed message format for the ordering service. This
format will be used for all broadcast messages, and all blocks will
consist of marshaled orderer messages of type Envelope.

The fabric will extend these messages by depending on the header for
some information that was previously repeated inside the transaction,
and having a second inner header per proposal.

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

This changeset updates ab.proto to use the block format discussed in
JIRA issue https://jira.hyperledger.org/browse/FAB-384



It more closely mirrors the batch format proposed by Simon in the SBFT
work as well as the time tested bitcoin block structure.

Note that the block is split into three pieces, Header, Data, and
Metadata.  This makes the clear distinction that the Headers chain
together, and the Headers have a reference to the hash of the Data.
Therefore the Metadata section can be used for storage of information
which should not be hashed, such as signature collections.  See the JIRA
issue for more details.

Assuming this block format is accepted, it should be removed from
ab.proto and pushed into the fabric.proto / fabric_next.proto.

Change-Id: I9e9f5afa10e29258ba5ad2a8c536a781e765664f
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>

This addition supplements the existing ramledger rawledger
implementation.  Neither this, nor the ramledger is intended to be
performant, but they are both intended to be extremely simple.

In the case of this added fileledger, it is intended to allow data
persistence between stopping and starting of an orderer.

Ultimately, the expectation would be that for the performant case,
a high performance database of some sort, such as RocksDB or other
would likely be used for persisting data.

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



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