On 06/21/2016 09:01 AM, Christopher B Ferris wrote:
> FWIW, there has been continuing technical discussion in the
context of each PR referenced below.
That's a really good point, Chris - there has been extensive
technical conversation around each, which is great to see and
where you'd expect them. I guess the key question is what the
workflow should be to approve the pull requests.
I respect the Fabric team's desire to do this synchronously on a
regular basis (I think 10am ET Wednesdays) on the
#fabric-pr-review Slack channel, but I'd like to suggest perhaps
we could move to a more asynchronous model, based on some sort of
consensus mechanism of our own. Perhaps this is Apache's "three
+1s and no vetoes" approach, which basically established a low
quorum for making changes but empowered anyone involved to stand
up and stop what they thought would be a bad idea. Test coverage,
regular performance testing, and other tools can help us feel more
confident making significant changes here.
Original message -----
From: Tamas Blummer <tamas@...>
Sent by: hyperledger-fabric-bounces@...
Subject: [Hyperledger-fabric] Pull requests to connect
Date: Mon, Jun 20, 2016 11:47 AM
We at DA raised several
pull requests for fabric, that implement features useful
to connect fabric-api with fabric.
The pull requests are pending and were rebased several
times during last weeks.
I introduce them here and provide context, in hope to
receive feedback or even a decision on the concepts their
1) Optionally generate invoke transaction ID from
transaction content: https://github.com/hyperledger/fabric/pull/1721
If UUID is derived from transaction content, then it is
already known by the ledger client application, that is
able to track it from construction to storage into the
ledger. If UUID was assigned by the ledger (as is now)
then a client would have to find the transaction in the
block chain by comparing its content with content that it
sent in. Deriving transaction id from content with a
cryptographic hash practically ensures that ID will be
unique, no other transaction with any different content
will have the same ID. A limit of the approach is that
identical invoke would receive same ID, which is however
easy to avoid by the creator of the transaction. It is
questionable if identical invokes should be processed at
all since if they are allowed then trivial transaction
replay attack can be executed on the ledger.
2) Do not store failed invoke transactions into the
Chain code will likely implement checks of a transaction.
A transaction that does not pass the checks without error
should not be forwarded to consensus on order. Storing
invalid transactions turns the ledger into an error log
and can hurt performance by a single misbehaving client
that pushes junk.
Note that since 2) does not store error into blockchain we
need a different mechanism reporting error to transaction
originator, which leads us to
3) Add transaction rejection events: https://github.com/hyperledger/fabric/pull/1754
This change adds a new type of events: transaction
rejection. These events are sent out to listeners in case
the corresponding chain code of a transaction exited with
error. A mechanism was needed for the clients to be able
to get the results of their transactions without
constantly querying them (and without receiving all the
completed blocks with all the transactions that had a zero
We tried to put together the pieces by implementing a noop
system chaincode, that is suitable for performance testing
4) Add noop system chain code. https://github.com/hyperledger/fabric/pull/1722
Noop system chain code simply stores invoke transactions
without validation. This chaincode is useful for testing.
The noop system chaincode is prepared to work with
CHIEF LEDGER ARCHITECT
T: +36 1 883 0300
This message, and any attachments, is for the intended
may contain information that is privileged, confidential
and subject to important terms and conditions available at
If you are not the
intended recipient, please delete this message.
Hyperledger-fabric mailing list
Hyperledger-fabric mailing list
Executive Director at the Hyperledger Project