Re: Pull requests to connect fabric-api

Brian Behlendorf <bbehlendorf@...>

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.


Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
phone: +1 508 667 0402
----- Original message -----
From: Tamas Blummer <tamas@...>
Sent by: hyperledger-fabric-bounces@...
To: hyperledger-fabric <hyperledger-fabric@...>
Subject: [Hyperledger-fabric] Pull requests to connect fabric-api
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 implement

1) Optionally generate invoke transaction ID from transaction content:
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 ledger:
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:
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 exit status).

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.
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 fabric-api

Digital Asset

T: +36 1 883 0300
E: tamas@...

This message, and any attachments, is for the intended recipient(s) only,
may contain information that is privileged, confidential and/or proprietary
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

Brian Behlendorf
Executive Director at the Hyperledger Project
Twitter: @brianbehlendorf

Join to automatically receive all group messages.