Limits to generality
|
Tamas Blummer <tamas@...>
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? 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. |
|
|
