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