Date   

Re: Limits to generality

Tamas Blummer <tamas@...>
 

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



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


Re: Limits to generality

Marko Vukolic <MVU@...>
 

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
 

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


Re: Limits to generality

Tamas Blummer <tamas@...>
 

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



On 02 Jun 2016, at 13:41, Marko Vukolic <ZRLMVU@...> 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







From:        Tamas Blummer <tamas@...>
To:        Marko Vukolic <MVU@...>
Cc:        hyperledger-fabric@...
Date:        06/02/2016 01:33 PM
Subject:        Re: [Hyperledger-fabric] Limits to generality




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​



<Mail Attachment.png>
+​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.


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.


Re: Limits to generality

Tamas Blummer <tamas@...>
 

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



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.


Re: Limits to generality

Marko Vukolic <MVU@...>
 

For an honest peer - this is trivial to ask for - and we should do it
 
the problem is one cannot ask a malicious peer to comply with this. But one could track his actions via separate mechanism (cf. my proposal a) and c) in the first email)
 
Cheers,
Marko
 

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


Re: Limits to generality

Binh Q Nguyen <binhn@...>
 

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

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​



+​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




Re: Limits to generality

Tamas Blummer <tamas@...>
 

1) storing invalid transactions should certainly not be the default behaviour. I wish options like this would be introduced once there is a use case requesting for it.

2) Please point me to the code and documentation you refer to.

TAMAS BLUMMER

​CHIEF LEDGER ARCHITECT​



+​36 1 883 0300 
​tamas
@digitalasset.com



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





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.


Performance measurements

Tamas Blummer <tamas@...>
 

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?

TAMAS BLUMMER
​CHIEF LEDGER ARCHITECT​



+​36 1 883 0300 
​tamas
@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.


Re: Limits to generality

William Sparks <wsparks@...>
 

Tamas,
 
I am in the learning mode and appreciate your patience
 
1.  I understand and agree with construction time comment as time stamp is not always equal as I understand it (and for lack of a better description).  Example: some Bitcoin transactions included in a block are hashed before some included in a previous block.  They are all time stamped but appear on the blockchain nonetheless as out of sequence.    
 
2.  As in Bitcoin, transactions are "selected" by mining nodes for inclusion in a block.  Would it be practical to allow the network nodes (consensus or otherwise) to detect transactions suspected of "errors" or being invalid and kick them to another type node for further and circuitous evaluation, determination and final disposition?  If the transactions are confirmed by the "special node criteria" (once again, I have no better term) to be invalid, the transaction is not included in the main chain (so to speak)...would it be beneficial to preserve such transactions in a sidechain or similar mechanism?  Would this not help prevent a DoS attack? 

 

3.  Some applications in the future will be viewed by regulators.  What will be the most likely stance of regulators that see invalid transactions successfully hashed with valid transactions?  I don’t know that it matters, I am just asking.  Some chains used now or in the future will also carry personal information so security will be a point of scrutiny by regulators. 

 

Thanks for the good work and best to all involved, 
 
Bill 

 

From: hyperledger-fabric-bounces@... [mailto:hyperledger-fabric-bounces@...] On Behalf Of Tamas Blummer
Sent: Thursday, June 2, 2016 5:07 AM
To: hyperledger-fabric@...
Subject: [Hyperledger-fabric] Limits to generality

 

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​



+​36 1 883 0300 

​tamas

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


Re: Limits to generality

Binh Q Nguyen <binhn@...>
 

Tamas,

the sdk code/doc here: https://github.com/hyperledger/fabric/tree/master/sdk/node
tx id is set in this module https://github.com/hyperledger/fabric/blob/master/sdk/node/src/hlc.ts (search for uuid)
folks are still working to complete the SDK and document.

I created https://github.com/hyperledger/fabric/issues/1687 for #1

- Binh

Tamas Blummer ---06/02/2016 10:50:19 AM---1) storing invalid transactions should certainly not be the default behaviour. I wish options like t

From: Tamas Blummer <tamas@...>
To: Binh Q Nguyen/Raleigh/IBM@IBMUS
Cc: hyperledger-fabric@...
Date: 06/02/2016 10:50 AM
Subject: Re: [Hyperledger-fabric] Limits to generality





1) storing invalid transactions should certainly not be the default behaviour. I wish options like this would be introduced once there is a use case requesting for it.

2) Please point me to the code and documentation you refer to.

TAMAS BLUMMER
​CHIEF LEDGER ARCHITECT​




+​36 1 883 0300
​tamas@
digitalasset.com
digitalasset.com


      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




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.



Improving Transaction Rates

Bishop Brock <bcbrock@...>
 

Tamas,

In my experience maximizing throughput requires running multiple clients. You should be able to at least double if not triple your throughput by running 16 clients - assuming you have the computational capacity on your laptop.
You may also want to try the trick mentioned here to see if it gives you a small boost: https://github.com/hyperledger/fabric/wiki/Go-Performance-Portal#morestack

Bishop Brock : Research Staff Member : IBM Master Inventor
IBM Research : +1 (512) 286-5453 [Office] : +1 (512) 568-9467 [Mobile]
http://researcher.ibm.com/researcher/view.php?person=us-bcbrock

Message: 1
Date: Thu, 2 Jun 2016 18:10:24 +0200
From: Tamas Blummer <tamas@...>
To: hyperledger-fabric@...
Subject: [Hyperledger-fabric] Performance measurements
Message-ID: <EAC6B9D8-293D-4210-91DF-56E24795B0B1@...>
Content-Type: text/plain; charset="utf-8"

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?

TAMAS BLUMMER
?CHIEF LEDGER ARCHITECT?



+?36 1 883 0300
?tamas@... <
http://digitalasset.com/>
digitalasset.com <
http://digitalasset.com/>


Cancelled: Hyperledger Fabric Technical Planning

Binh Q Nguyen <binhn@...>
 

Description


Cancel this repeated meeting to create weekly meeting each week to include newly joined members Cancel this repeated meeting to create weekly meeting each week to include newly joined members


Invitation: Hyperledger Fabric Technical Planning (Jun 6 10:00 AM EDT)

Binh Q Nguyen <binhn@...>
 

Description


https://meetings.webex.com/collabs/meetings/join?uuid=M7ME8OZ0FX8ZY45U79CEWHFSOD-9VIB

Meeting number: 195 533 376
Audio Connection:  +1-415-655-0001 US TOLL
Access code: 195 533 376

Can't access your meeting? Get help:
https://meetings.webex.com/collabs/#/support


Other Hyperledger meetings:
https://github.com/hyperledger/hyperledger/wiki/PublicMeetingCalendar

https://meetings.webex.com/collabs/meetings/join?uuid=M7ME8OZ0FX8ZY45U79CEWHFSOD-9VIB

Meeting number: 195 533 376
Audio Connection:  +1-415-655-0001 US TOLL
Access code: 195 533 376

Can't access your meeting? Get help:
https://meetings.webex.com/collabs/#/support


Other Hyperledger meetings:
https://github.com/hyperledger/hyperledger/wiki/PublicMeetingCalendar


Re: Limits to generality

Tamas Blummer <tamas@...>
 

Hi Binh,

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.

I am surprised to see node.js and typescript in this project. I think id would add value if we'd split out the fabric core that should be lean, highly performant an homogenous.

TAMAS BLUMMER

​CHIEF LEDGER ARCHITECT​



+​36 1 883 0300 
​tamas
@digitalasset.com



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

Tamas, 

the sdk code/doc here: https://github.com/hyperledger/fabric/tree/master/sdk/node
tx id is set in this module https://github.com/hyperledger/fabric/blob/master/sdk/node/src/hlc.ts (search for uuid)
folks are still working to complete the SDK and document.

I created https://github.com/hyperledger/fabric/issues/1687 for #1

- Binh

<graycol.gif>Tamas Blummer ---06/02/2016 10:50:19 AM---1) storing invalid transactions should certainly not be the default behaviour. I wish options like t

From:  Tamas Blummer <tamas@...>
To:  Binh Q Nguyen/Raleigh/IBM@IBMUS
Cc:  hyperledger-fabric@...
Date:  06/02/2016 10:50 AM
Subject:  Re: [Hyperledger-fabric] Limits to generality





1) storing invalid transactions should certainly not be the default behaviour. I wish options like this would be introduced once there is a use case requesting for it.

2) Please point me to the code and documentation you refer to.

TAMAS BLUMMER
​CHIEF LEDGER ARCHITECT​



<41104940.gif>
+​36 1 883 0300 
​tamas@
digitalasset.com
digitalasset.com


      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




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.


Re: Limits to generality

Binh Q Nguyen <binhn@...>
 

Hi Tamas,

We probably should chat on slack as I don't follow your comment
> Generating uuid for queries is unrelate to the requirement of being able to compute tx id at its construction for invoke

The SDK allows the application to generate a UUID for every transaction.

Again this is work in progress and the deploy transaction is not there yet, but invoke and query transactions are there.

Thanks,

- Binh

Tamas Blummer ---06/03/2016 05:41:46 AM---Hi Binh, I do not think this addresses the same problem. Generating uuid for queries is unrelate to

From: Tamas Blummer <tamas@...>
To: Binh Q Nguyen/Raleigh/IBM@IBMUS
Cc: hyperledger-fabric@...
Date: 06/03/2016 05:41 AM
Subject: Re: [Hyperledger-fabric] Limits to generality





Hi Binh,

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.

I am surprised to see node.js and typescript in this project. I think id would add value if we'd split out the fabric core that should be lean, highly performant an homogenous.

TAMAS BLUMMER
​CHIEF LEDGER ARCHITECT​




+​36 1 883 0300
​tamas@
digitalasset.com
digitalasset.com



          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



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.



Re: Limits to generality

Chet Murthy <chetsky@...>
 

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.


Re: Performance measurements

Chet Murthy <chetsky@...>
 

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?


Re: Limits to generality

Tamas Blummer <tamas@...>
 

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.

Tamas Blummer
CHIEF LEDGER ARCHITECT
Digital Asset

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

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


Re: Performance measurements

Tamas Blummer <tamas@...>
 

We will submit a pull request within days, that allows reproduction on its branch.

Tamas Blummer
CHIEF LEDGER ARCHITECT
Digital Asset

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

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


Re: Limits to generality

Chet Murthy <chetsky@...>
 

Tamas,

Oh ... let me say back to you:

(1) you DO NOT mean that the client gets to specify the tran-id
directly (or even any part of it)

(2) you DO mean, that the client can itself compute the tran-id (using
a standard hashing method), based only upon information it has
-before- submitting the tran to HL, yes?

This is true in bitcoin (of course) -- are you just saying "guys, can
you make sure that the tran-id is computed in a manner sufficiently
analogous to what happens in BTC, that people who count on that,
aren't wildly surprised!

??

Thanks,
--chet--

On Friday, 3 June 2016 18:56:47 PDT Tamas Blummer wrote:
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.