Dear Tamas,1) I would argue that all blockchains incl. Bitcoin and Ethereum store invalid transactions as well - in case of Bitcoin and Ethereum these are "orphaned blocks" that are still kept around in case their fork (branch), eventually prevails. For me, the question of keeping only the validated ledger (in the parlance of the next consensus architecture proposal - NCAP) is the question of where one decides to make things visible to the "public". For instance, an implementation could wrap consensus service (from NCAP) together with (optimized) checkpoint as described there - and expose only the validated ledger, discarding raw ledger invisibly wrt. "public". Re DoS, it is true that, unlike in Bitcoin or Ethereum, NCAP allows meaningless tx (e.g., garbage tx) to enter the raw ledger. To me, the main tools we would have against this are:a) deployment-specific currency to charge transactions that get submitted to consensus service (ala Bitcoin, Ethereum)b) rate-limiting of individual clients' outstanding requests (needs to be done by the consensus service)c) as tx are signed - hold submitting peers accountable for garbage tx by a separate mechanism. This is certainly a possibility in permissioned implementations. d) have consensus look into a transaction to say if it is a "legitimate" one. This last one goes into direction of having consenters as committers - it is not clear to me that we want this in the generic design - but this is certainly an implementation possibility. I am not sure that we would want to make d) a mandatory approach and sacrifice the possibility of entirely decoupling the consensus service from state/chaincode.2) I agree - In NCAP this UUID roughly corresponds to tid (tx id) - perhaps we can amend that one to fit what you have in mind. Cheers,MarkoFrom: Tamas Blummer <tamas@...>To: hyperledger-fabric@...Date: 06/02/2016 12:07 PMSubject: [Hyperledger-fabric] Limits to generalitySent by: hyperledger-fabric-bounces@...
It is an art to create a fabric that is generic enough for anticipated use cases but have limits such that it remains practical.
I think fabric overshoot on generality on some fronts risking its viability for real world projects.
Two examples:
1. It stores invoke transactions where chain code execution fails together with error report.
While it might appeal for debugging this turns out to be an open door for DoS attacks or simply filling up the blockchain with junk by one misbehaving client.
All network participants suffer severe performance degradation in consequence. The blockchain should not be an error log but only contain transactions that were
accepted syntactically and semantically correct by their chain code.
2. Server assigned UUID of transactions
While it ensures that transactions can be uniquely referenced it disallows tracking of a transaction from its originating process through the block chain.
Transaction ID should instead be set at construction time, best derived with a crypto hash of its content, so it is not feasible to create a different transaction that is valid but has the same ID.
This would disallow submitting identical transactions, which however is either an error or is easy to remediate at the constructing peer.
One could argue for both design choices for the sake of generality and I think both would be ruled out once you would build a practical system.
Do you agree with me and would reduce generality in these cases?
TAMAS BLUMMER
CHIEF LEDGER ARCHITECT
<Mail Attachment.png>+36 1 883 0300
tamas@digitalasset.comdigitalasset.comThis 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 
