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.

Brian
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402
 
 
----- Original message -----
From: Tamas Blummer <tamas@...>
Sent by: hyperledger-fabric-bounces@...
To: hyperledger-fabric <hyperledger-fabric@...>
Cc:
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: 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 ledger: https://github.com/hyperledger/fabric/pull/1719
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 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. 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 fabric-api



TAMAS BLUMMER
CHIEF LEDGER ARCHITECT
Digital Asset

T: +36 1 883 0300
E: tamas@...
W: digitalasset.com


--
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
http://www.digitalasset.com/emaildisclaimer.html. If you are not the
intended recipient, please delete this message.
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 
 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric


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

Join fabric@lists.hyperledger.org to automatically receive all group messages.