----- Original message -----
From: Tamas Blummer <tamas@...>
To: Marko Vukolic <MVU@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Limits to generality
Date: Thu, Jun 2, 2016 1:33 PM
 

Dear Marko,

 

NONE of the transactions stored in Bitcoin are invalid in the sense of it chain code (that is its script language). Those in orphan blocks are just not part of the ordering consensus.

 

Similarly I ask that transactions that are not valid with their chain code should not enter the ordering consensus.

 

Yes, I am ready to scarify the possibility of decoupling two algorithm for the sake of creating a practically usable system. I am not even sure that this would be the consequence of my ask.

 

TAMAS BLUMMER

 

​CHIEF LEDGER ARCHITECT​

 

+​36 1 883 0300 

​tamas

@digitalasset.com

digitalasset.com

 

 

On 02 Jun 2016, at 13:29, Marko Vukolic <MVU@...> wrote:

 

Dear Tams,

 

yes - I reflected this in "unlike in Bitcoin or Ethereum, NCAP allows meaningless tx (e.g., garbage tx) to enter the raw ledger"

 

yet, Bitcoin and Ethereum store invalid (in the sense of - unsuccessful) tx (in orphaned blocks)

Cheers,

Marko

 

----- Original message -----
From: Tamas Blummer <tamas@...>
Sent by: hyperledger-fabric-bounces@...
To: Marko Vukolic/Zurich/IBM@IBMCH
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Limits to generality
Date: Thu, Jun 2, 2016 1:25 PM
 
Dear Marko,

 

Your comparison does not hold with Bitcoin and Ethereum. Transactions in orphan blocks are valid with respect to the script rules = chain code in Hyperledger.

 

 

TAMAS BLUMMER

  

​CHIEF LEDGER ARCHITECT​

 

<Image.2C025015-191F-4517-B177-65100A7316BA.png>
+​36 1 883 0300  

​tamas

@digitalasset.com

digitalasset.com

 

 

On 02 Jun 2016, at 13:19, Marko Vukolic <ZRLMVU@...> wrote:

 

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,
Marko




From:        Tamas Blummer <tamas@...>
To:        hyperledger-fabric@...
Date:        06/02/2016 12:07 PM
Subject:        [Hyperledger-fabric] Limits to generality
Sent 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.com
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

 

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

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.

----- Original message -----
From: Tamas Blummer <tamas@...>
To: Marko Vukolic <MVU@...>, hyperledger-fabric@...
Cc:
Subject: Re: [Hyperledger-fabric] Limits to generality
Date: Thu, Jun 2, 2016 1:46 PM
 

I am not sure we should discuss coupling of chain code and consensus as I am not sure this was the consequence of my ask.

Using the terminology of your writeup I ask, that endorsers should not forward transactions to consensus service if the transactions chain code that they execute returns with error.

 

TAMAS BLUMMER
​CHIEF LEDGER ARCHITECT​



+​36 1 883 0300 

​tamas

@digitalasset.com

digitalasset.com

 

 

On 02 Jun 2016, at 13:44, Marko Vukolic <MVU@...> wrote:

Dear Tamas,
 
Re "invalid" in Bitcoin I precisely said "unsuccessful" as in orphaned blocks - not invalid in the sense of chaincode.
 
Anyway, coupling chaincode and consensus is certainly a possibility - and one of the important design decisions the community needs to take.
 
We discussed this choice in length among us when writing the first cons architecture proposal draft and ended up with proposing the decoupled approach. I suggest we take this on again in the HL Arch WG call next Wednesday.
 
Cheers,
Marko
 

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.

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.

On 02 Jun 2016, at 16:46, Binh Q Nguyen <binhn@...> wrote:

For 1, it's could be an option in permissioned blockchain for complete auditability, not debugging.
For 2, it's been implemented in the client SDK

- Binh

<graycol.gif>Tamas Blummer ---06/02/2016 06:07:40 AM---It is an art to create a fabric that is generic enough for anticipated use cases but have limits suc

From: Tamas Blummer <tamas@...>
To: hyperledger-fabric@...
Date: 06/02/2016 06:07 AM
Subject: [Hyperledger-fabric] Limits to generality
Sent 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​


<0F959428.gif>
+​36 1 883 0300
​tamas@digitalasset.com
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

I do not think this addresses the same problem. Generating uuid for queries
is unrelate to the requirement of being able to compute tx id at its
construction for invoke.

We created a noop system chain code that does nothing but store an invoke
transaction. Since it is a system chain code written in go and deployed at
startup, it does not require the grpc-docker roundtrip at invoke.

Nevertheless we were only able to push 400 tx/s (few hundred bytes of random
tx data each) with no consensus module activate on a single node on a
laptop.

Do you have a more promising result or an idea how to reach magnitudes
higher rates?

On 03 Jun 2016, at 18:53, Chet Murthy <chetsky@...> wrote:

Tamas,

Can you elaborate a little on the intended form and usage of this
client-specified tran-id? I'm going to imagine what your requirement
is about, but perhaps I'll get it wrong:

It seems like:

(a) it had better -start- with a randomly (or hash-wise) generated
string, in order to avoid DOS attacks, yes?

(b) so perhaps what you mean is, you'd like a suffix of the tran-id to
be something user-specified?

(c) in wihch case, perhaps what you're looking for, is really a
"secondary key" to the tran? So you can lookup trans by that
secondary key, and vice-versa, use that secondary key to lookup things
in other systems?

If this is what you're looking for, it's a quite reasonable
requirement, but I'd like to note that with a proper "custom events"
facility, this is already possible. Custom events will be protobufs,
and hence can contain well-typed, structured information, specific to
each chaincode (hence, each application). Furthermore

(d) this secondary key might sometimes need to be obscured in the
transaction, since otherwise, it might leak confidential information.
But this would make it unsuitable for inclusion in the tran-id -- the
tran-id is by its nature used in many places where it must be seen
in-the-clear, after all.

Whereas, "custom events" are part of the transaction's body, and hence
can be encrypted, just as the MVCC+postimage information is encrypted
for confidential-data transactions.

Cheers,
--chet--

On Friday, 3 June 2016 11:41:37 PDT Tamas Blummer wrote:

I do not think this addresses the same problem. Generating uuid for queries
is unrelate to the requirement of being able to compute tx id at its
construction for invoke.

On 03 Jun 2016, at 18:55, Chet Murthy <chetsky@...> wrote:

Tamas,

Just for clarity, could you describe how you ran this test? Perhaps,
with details sufficient for reproduction?

--chet--

On Thursday, 2 June 2016 18:10:24 PDT Tamas Blummer wrote:

We created a noop system chain code that does nothing but store an invoke
transaction. Since it is a system chain code written in go and deployed at
startup, it does not require the grpc-docker roundtrip at invoke.

Nevertheless we were only able to push 400 tx/s (few hundred bytes of random
tx data each) with no consensus module activate on a single node on a
laptop.

Do you have a more promising result or an idea how to reach magnitudes
higher rates?

Hi Chet,

the purpose is that constructor of a transaction, the client, knows what id
the tx will have on block chain.

I do not suggest client specified id, but client specified derivation of the
id via a crypto hash of the tx content. This ensures that id will not
collide for tx with different content.