[Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake


Rao Dronamraju <rao.dronamraju@...>
 

Hi Folks,

 

I am a passive listener at this time of all the interesting conversations on this forum. I enjoy reading about the great work you folks are doing.

 

I have a dumb question. So in Intel’s sawtooth lake architecture if the fundamental idea is to not use compute intensive PoW algorithms, how do you assure the immutability of a transaction? The lower the hash difficulty factor of a block, doesn’t the degree immutability of the transactions in the block also decrease? Which should also mean it is susceptible to mutability and double spend etc. issues? Wondering how this is taken care of in Intel’s sawtooth architecture?

 

Best Regards,

Rao

 

 

From: hyperledger-technical-discuss-bounces@... [mailto:hyperledger-technical-discuss-bounces@...] On Behalf Of Tamas Blummer via hyperledger-technical-discuss
Sent: Friday, November 4, 2016 11:14 AM
To: Middleton, Dan <dan.middleton@...>
Cc: hyperledger-stl@...; hyperledger-technical-discuss@...; hyperledger-tsc@...
Subject: Re: [technical-discuss] [Hyperledger Project TSC] Meet Sawtooth Lake

 

An entertaining yet informative summary that motivates to learn more about Sawtooth Lake esp. PoET. 

 

Thank you and congratulations Dan!

 

TAMAS BLUMMER

 

​CHIEF LEDGER ARCHITECT​

 



+​36 1 883 0300 

​tamas

@digitalasset.com

 



 

On 03 Nov 2016, at 17:55, Middleton, Dan via hyperledger-tsc <hyperledger-tsc@...> wrote:

 

I’ve written an informal piece, “Meet Sawtooth Lake,” discussing our design goals.

 

 

I briefly introduce Consortium Ledgers to motivate scalable consensus (PoET) and safe but powerful smart contracts (Transaction Families).

 

Following POCs across dozens of globally distributed validators, we have some new design elements coming to further address broad scale production deployments.  I alluded to these but plan to describe them more fully in the coming weeks - perhaps verbally at one of our TSC sessions.

 

 

Regards,

 

Dan Middleton
   Intel New Technology Group

 

_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc

 


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.


Arnaud Le Hors
 

Hi Rao,
The whole point of Proof of Work is to take time. This is what makes it hard to rewrite history/rebuild the chain from a point back in time. PoeT achieves the same by forcing a wait time controlled by secure hardware without having the burden of burning CPU to resolve a hash challenge. The result is the same.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM Cloud




From:        Rao Dronamraju via hyperledger-tsc <hyperledger-tsc@...>
To:        "'Tamas Blummer'" <tamas@...>, "'Middleton, Dan'" <dan.middleton@...>
Cc:        hyperledger-stl@..., hyperledger-tsc@...
Date:        11/04/2016 05:47 PM
Subject:        Re: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake
Sent by:        hyperledger-tsc-bounces@...




Hi Folks,
 
I am a passive listener at this time of all the interesting conversations on this forum. I enjoy reading about the great work you folks are doing.
 
I have a dumb question. So in Intel’s sawtooth lake architecture if the fundamental idea is to not use compute intensive PoW algorithms, how do you assure the immutability of a transaction? The lower the hash difficulty factor of a block, doesn’t the degree immutability of the transactions in the block also decrease? Which should also mean it is susceptible to mutability and double spend etc. issues? Wondering how this is taken care of in Intel’s sawtooth architecture?
 
Best Regards,
Rao
 
 

From: hyperledger-technical-discuss-bounces@... [mailto:hyperledger-technical-discuss-bounces@...] On Behalf Of Tamas Blummer via hyperledger-technical-discuss
Sent:
Friday, November 4, 2016 11:14 AM
To:
Middleton, Dan <dan.middleton@...>
Cc:
hyperledger-stl@...; hyperledger-technical-discuss@...; hyperledger-tsc@...
Subject:
Re: [technical-discuss] [Hyperledger Project TSC] Meet Sawtooth Lake

 
An entertaining yet informative summary that motivates to learn more about Sawtooth Lake esp. PoET.
 
Thank you and congratulations Dan!
 
TAMAS BLUMMER
 
​CHIEF LEDGER ARCHITECT​
 


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


 
On 03 Nov 2016, at 17:55, Middleton, Dan via hyperledger-tsc <hyperledger-tsc@...> wrote:
 
I’ve written an informal piece, “Meet Sawtooth Lake,” discussing our design goals.
 
https://www.hyperledger.org/blog/2016/11/02/meet-sawtooth-lake
 
I briefly introduce Consortium Ledgers to motivate scalable consensus (PoET) and safe but powerful smart contracts (Transaction Families).
 
Following POCs across dozens of globally distributed validators, we have some new design elements coming to further address broad scale production deployments.  I alluded to these but plan to describe them more fully in the coming weeks - perhaps verbally at one of our TSC sessions.
 
 
Regards,
 
Dan Middleton
  Intel New Technology Group

 
_______________________________________________
hyperledger-tsc mailing list

hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
 

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-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc




Rao Dronamraju <rao.dronamraju@...>
 

 

Hi Arnaud,

 

Thanks for your reply. Feel free to correct me if I am wrong but my understanding is PoW (Poof of Work) achieves immutability by computing a hash that is below a certain target which takes a lot of computation and consequently time. But the immutability of block hash is the one that makes the transactions immutable for double spend type of fraud that one might perpetrate. The idea behind non-PoW algorithms is to avoid the extensive computation that is needed in PoW for computing the block hash. So in PoET if block hashes are not difficult of break even though one waits a certain time, can’t I go back and change the transactions and the block hash to redo the transactions that have been done? There by breaking the immutability property of block chains? What if I have enough computational power to break the immutability with in the PoET’s wait time? Just curious?

 

Thanks

Rao

 

 

 

From: Arnaud Le Hors [mailto:lehors@...]
Sent: Sunday, November 6, 2016 12:09 PM
To: Rao Dronamraju <rao.dronamraju@...>
Cc: 'Middleton, Dan' <dan.middleton@...>; hyperledger-stl@...; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake

 

Hi Rao,
The whole point of Proof of Work is to take time. This is what makes it hard to rewrite history/rebuild the chain from a point back in time. PoeT achieves the same by forcing a wait time controlled by secure hardware without having the burden of burning CPU to resolve a hash challenge. The result is the same.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM Cloud




From:        Rao Dronamraju via hyperledger-tsc <hyperledger-tsc@...>
To:        "'Tamas Blummer'" <tamas@...>, "'Middleton, Dan'" <dan.middleton@...>
Cc:        hyperledger-stl@..., hyperledger-tsc@...
Date:        11/04/2016 05:47 PM
Subject:        Re: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake
Sent by:        hyperledger-tsc-bounces@...





Hi Folks,
 
I am a passive listener at this time of all the interesting conversations on this forum. I enjoy reading about the great work you folks are doing.
 
I have a dumb question. So in Intel’s sawtooth lake architecture if the fundamental idea is to not use compute intensive PoW algorithms, how do you assure the immutability of a transaction? The lower the hash difficulty factor of a block, doesn’t the degree immutability of the transactions in the block also decrease? Which should also mean it is susceptible to mutability and double spend etc. issues? Wondering how this is taken care of in Intel’s sawtooth architecture?
 
Best Regards,
Rao
 
 
From: hyperledger-technical-discuss-bounces@... [mailto:hyperledger-technical-discuss-bounces@...] On Behalf Of Tamas Blummer via hyperledger-technical-discuss
Sent:
Friday, November 4, 2016 11:14 AM
To:
Middleton, Dan <dan.middleton@...>
Cc:
hyperledger-stl@...; hyperledger-technical-discuss@...; hyperledger-tsc@...
Subject:
Re: [technical-discuss] [Hyperledger Project TSC] Meet Sawtooth Lake

 
An entertaining yet informative summary that motivates to learn more about Sawtooth Lake esp. PoET.
 
Thank you and congratulations Dan!
 
TAMAS BLUMMER
 
​CHIEF LEDGER ARCHITECT​
 


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


 
On 03 Nov 2016, at 17:55, Middleton, Dan via hyperledger-tsc <hyperledger-tsc@...> wrote:
 
I’ve written an informal piece, “Meet Sawtooth Lake,” discussing our design goals.
 
https://www.hyperledger.org/blog/2016/11/02/meet-sawtooth-lake
 
I briefly introduce Consortium Ledgers to motivate scalable consensus (PoET) and safe but powerful smart contracts (Transaction Families).
 
Following POCs across dozens of globally distributed validators, we have some new design elements coming to further address broad scale production deployments.  I alluded to these but plan to describe them more fully in the coming weeks - perhaps verbally at one of our TSC sessions.
 
 
Regards,
 
Dan Middleton
  Intel New Technology Group

 
_______________________________________________
hyperledger-tsc mailing list

hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
 

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-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



Middleton, Dan <dan.middleton@...>
 

Hi Rao,

 

Good question.

 

Rather than computation load, PoET relies on trusted execution. The attack against PoET wouldn’t be compute resources but defeating the trusted execution environment (TEE) and forging cryptographic attestations. If the TEE holds, then the wait time (or inter-block) time is analogous to the inter-block time enforced by POW difficulty.  It would be impossible to create a longer fork without creating time. Like POW, the assumption in PoET is the cost to defeat the security mechanism is in excess of the value of a double-spend opportunity.

 

That said, to provide defense in depth, PoET has various counter measures such as checks on the frequency with which a node can win. Also a cheating validator, once discovered, can have its TEE credentials revoked to prevent further attempts by that system.

 

Depending on the deployment there are other defense layers such as policies that can be set for allowing white-listed nodes (e.g. each participant in a consortium registers n validators). If a business’s machine is found to be attacking the consortium, with a cryptographic audit trail, what would that mean for that business?

 

It’s also worth noting that a rogue validator could only cheat on leader election. It could not publish invalid transactions as its peers will still reject those and the block containing them and no fork will be created.

 

 

Thanks,

Dan 

 

From: Rao Dronamraju [mailto:rao.dronamraju@...]
Sent: Sunday, November 06, 2016 13:54
To: 'Arnaud Le Hors' <lehors@...>
Cc: Middleton, Dan <dan.middleton@...>; hyperledger-stl@...; hyperledger-tsc@...
Subject: RE: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake

 

 

Hi Arnaud,

 

Thanks for your reply. Feel free to correct me if I am wrong but my understanding is PoW (Poof of Work) achieves immutability by computing a hash that is below a certain target which takes a lot of computation and consequently time. But the immutability of block hash is the one that makes the transactions immutable for double spend type of fraud that one might perpetrate. The idea behind non-PoW algorithms is to avoid the extensive computation that is needed in PoW for computing the block hash. So in PoET if block hashes are not difficult of break even though one waits a certain time, can’t I go back and change the transactions and the block hash to redo the transactions that have been done? There by breaking the immutability property of block chains? What if I have enough computational power to break the immutability with in the PoET’s wait time? Just curious?

 

Thanks

Rao

 

 

 

From: Arnaud Le Hors [mailto:lehors@...]
Sent: Sunday, November 6, 2016 12:09 PM
To: Rao Dronamraju <rao.dronamraju@...>
Cc: 'Middleton, Dan' <dan.middleton@...>; hyperledger-stl@...; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake

 

Hi Rao,
The whole point of Proof of Work is to take time. This is what makes it hard to rewrite history/rebuild the chain from a point back in time. PoeT achieves the same by forcing a wait time controlled by secure hardware without having the burden of burning CPU to resolve a hash challenge. The result is the same.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM Cloud




From:        Rao Dronamraju via hyperledger-tsc <hyperledger-tsc@...>
To:        "'Tamas Blummer'" <tamas@...>, "'Middleton, Dan'" <dan.middleton@...>
Cc:        hyperledger-stl@..., hyperledger-tsc@...
Date:        11/04/2016 05:47 PM
Subject:        Re: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake
Sent by:        hyperledger-tsc-bounces@...





Hi Folks,
 
I am a passive listener at this time of all the interesting conversations on this forum. I enjoy reading about the great work you folks are doing.
 
I have a dumb question. So in Intel’s sawtooth lake architecture if the fundamental idea is to not use compute intensive PoW algorithms, how do you assure the immutability of a transaction? The lower the hash difficulty factor of a block, doesn’t the degree immutability of the transactions in the block also decrease? Which should also mean it is susceptible to mutability and double spend etc. issues? Wondering how this is taken care of in Intel’s sawtooth architecture?
 
Best Regards,
Rao
 
 
From: hyperledger-technical-discuss-bounces@... [mailto:hyperledger-technical-discuss-bounces@...] On Behalf Of Tamas Blummer via hyperledger-technical-discuss
Sent:
Friday, November 4, 2016 11:14 AM
To:
Middleton, Dan <dan.middleton@...>
Cc:
hyperledger-stl@...; hyperledger-technical-discuss@...; hyperledger-tsc@...
Subject:
Re: [technical-discuss] [Hyperledger Project TSC] Meet Sawtooth Lake

 
An entertaining yet informative summary that motivates to learn more about Sawtooth Lake esp. PoET.
 
Thank you and congratulations Dan!
 
TAMAS BLUMMER
 
​CHIEF LEDGER ARCHITECT​
 


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


 
On 03 Nov 2016, at 17:55, Middleton, Dan via hyperledger-tsc <hyperledger-tsc@...> wrote:
 
I’ve written an informal piece, “Meet Sawtooth Lake,” discussing our design goals.
 
https://www.hyperledger.org/blog/2016/11/02/meet-sawtooth-lake
 
I briefly introduce Consortium Ledgers to motivate scalable consensus (PoET) and safe but powerful smart contracts (Transaction Families).
 
Following POCs across dozens of globally distributed validators, we have some new design elements coming to further address broad scale production deployments.  I alluded to these but plan to describe them more fully in the coming weeks - perhaps verbally at one of our TSC sessions.
 
 
Regards,
 
Dan Middleton
  Intel New Technology Group

 
_______________________________________________
hyperledger-tsc mailing list

hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
 

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-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


Baohua Yang
 

Thanks Dan for the great post! 

I guess this work is the first well-known hardware-based consensus solution.

I'm not that familiar with STL, while it still triggers several quick thoughts.

1. For consensus, typically there are two basic steps: 1) Select who(s) for the proposal; 2) Solve possible proposal conflicts.
From the blog, PoET is more efficient in energy saving compared with PoW in step 1), but not mentioned too much details in step 2). So does STL utilize the legacy length-first scheme to solve step 2), just like PoW?

2. The idea of transaction familiar model is cool, just like the classic compile code/lib, with higher-level language. Do we support a upgrade with those domain code? E.g., we want to add more such domain contract or upgrade existing one.

3. I notice that the PoET relies on chipset capability for trustness and consensus. Is it possible to have an open-sourced implementation, with flexibility to allow more types of validator to join besides those having special chipset? If possible, then it will be interesting to make such hardware-based solution more general and standard.

Thanks!

On Mon, Nov 7, 2016 at 9:11 AM, Middleton, Dan via hyperledger-tsc <hyperledger-tsc@...> wrote:

Hi Rao,

 

Good question.

 

Rather than computation load, PoET relies on trusted execution. The attack against PoET wouldn’t be compute resources but defeating the trusted execution environment (TEE) and forging cryptographic attestations. If the TEE holds, then the wait time (or inter-block) time is analogous to the inter-block time enforced by POW difficulty.  It would be impossible to create a longer fork without creating time. Like POW, the assumption in PoET is the cost to defeat the security mechanism is in excess of the value of a double-spend opportunity.

 

That said, to provide defense in depth, PoET has various counter measures such as checks on the frequency with which a node can win. Also a cheating validator, once discovered, can have its TEE credentials revoked to prevent further attempts by that system.

 

Depending on the deployment there are other defense layers such as policies that can be set for allowing white-listed nodes (e.g. each participant in a consortium registers n validators). If a business’s machine is found to be attacking the consortium, with a cryptographic audit trail, what would that mean for that business?

 

It’s also worth noting that a rogue validator could only cheat on leader election. It could not publish invalid transactions as its peers will still reject those and the block containing them and no fork will be created.

 

 

Thanks,

Dan 

 

From: Rao Dronamraju [mailto:rao.dronamraju@sbcglobal.net]
Sent: Sunday, November 06, 2016 13:54
To: 'Arnaud Le Hors' <lehors@...>
Cc: Middleton, Dan <dan.middleton@...>; hyperledger-stl@lists.hyperledger.org; hyperledger-tsc@lists.hyperledger.org
Subject: RE: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake

 

 

Hi Arnaud,

 

Thanks for your reply. Feel free to correct me if I am wrong but my understanding is PoW (Poof of Work) achieves immutability by computing a hash that is below a certain target which takes a lot of computation and consequently time. But the immutability of block hash is the one that makes the transactions immutable for double spend type of fraud that one might perpetrate. The idea behind non-PoW algorithms is to avoid the extensive computation that is needed in PoW for computing the block hash. So in PoET if block hashes are not difficult of break even though one waits a certain time, can’t I go back and change the transactions and the block hash to redo the transactions that have been done? There by breaking the immutability property of block chains? What if I have enough computational power to break the immutability with in the PoET’s wait time? Just curious?

 

Thanks

Rao

 

 

 

From: Arnaud Le Hors [mailto:lehors@...]
Sent: Sunday, November 6, 2016 12:09 PM
To: Rao Dronamraju <rao.dronamraju@...>
Cc: 'Middleton, Dan' <dan.middleton@...>; hyperledger-stl@lists.hyperledger.org; hyperledger-tsc@lists.hyperledger.org


Subject: Re: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake

 

Hi Rao,
The whole point of Proof of Work is to take time. This is what makes it hard to rewrite history/rebuild the chain from a point back in time. PoeT achieves the same by forcing a wait time controlled by secure hardware without having the burden of burning CPU to resolve a hash challenge. The result is the same.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM Cloud




From:        Rao Dronamraju via hyperledger-tsc <hyperledger-tsc@lists.hyperledger.org>
To:        "'Tamas Blummer'" <tamas@...>, "'Middleton, Dan'" <dan.middleton@...>
Cc:        hyperledger-stl@lists.hyperledger.org, hyperledger-tsc@lists.hyperledger.org
Date:        11/04/2016 05:47 PM
Subject:        Re: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake
Sent by:        hyperledger-tsc-bounces@lists.hyperledger.org





Hi Folks,
 
I am a passive listener at this time of all the interesting conversations on this forum. I enjoy reading about the great work you folks are doing.
 
I have a dumb question. So in Intel’s sawtooth lake architecture if the fundamental idea is to not use compute intensive PoW algorithms, how do you assure the immutability of a transaction? The lower the hash difficulty factor of a block, doesn’t the degree immutability of the transactions in the block also decrease? Which should also mean it is susceptible to mutability and double spend etc. issues? Wondering how this is taken care of in Intel’s sawtooth architecture?
 
Best Regards,
Rao
 
 
From: hyperledger-technical-discuss-bounces@... [mailto:hyperledger-technical-discuss-bounces@lists.hyperledger.org] On Behalf Of Tamas Blummer via hyperledger-technical-discuss
Sent:
Friday, November 4, 2016 11:14 AM
To:
Middleton, Dan <dan.middleton@...>
Cc:
hyperledger-stl@lists.hyperledger.org; hyperledger-technical-discuss@lists.hyperledger.org; hyperledger-tsc@lists.hyperledger.org
Subject:
Re: [technical-discuss] [Hyperledger Project TSC] Meet Sawtooth Lake

 
An entertaining yet informative summary that motivates to learn more about Sawtooth Lake esp. PoET.
 
Thank you and congratulations Dan!
 
TAMAS BLUMMER
 
​CHIEF LEDGER ARCHITECT​
 


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


 
On 03 Nov 2016, at 17:55, Middleton, Dan via hyperledger-tsc <hyperledger-tsc@lists.hyperledger.org> wrote:
 
I’ve written an informal piece, “Meet Sawtooth Lake,” discussing our design goals.
 
https://www.hyperledger.org/blog/2016/11/02/meet-sawtooth-lake
 
I briefly introduce Consortium Ledgers to motivate scalable consensus (PoET) and safe but powerful smart contracts (Transaction Families).
 
Following POCs across dozens of globally distributed validators, we have some new design elements coming to further address broad scale production deployments.  I alluded to these but plan to describe them more fully in the coming weeks - perhaps verbally at one of our TSC sessions.
 
 
Regards,
 
Dan Middleton
  Intel New Technology Group

 
_______________________________________________
hyperledger-tsc mailing list

hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
 

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-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc




--
Best wishes!

Baohua Yang


Rao Dronamraju <rao.dronamraju@...>
 

Thanks Dan for that excellent explanation.

 

So it appears to me that in PoET also, just like with PoW, there will be some issues with transaction confirmation times. What I mean by this is, in PoW/bitcoin it takes 10 minutes for a block/transaction to be confirmed. Since in PoET one needs to wait based on the time set in PoET algorithm, it will also have similar transaction time confirmation delays. So it is more suitable for non-real time transaction applications, am I right?

 

Also if wait time is reduced, assuming it is a tunable parameter, then it might introduce immutability problems? Lesser the wait time more the probability of mutability?

 

Thanks

Rao

 

 

From: Middleton, Dan [mailto:dan.middleton@...]
Sent: Sunday, November 6, 2016 7:11 PM
To: Rao Dronamraju <rao.dronamraju@...>; 'Arnaud Le Hors' <lehors@...>
Cc: hyperledger-stl@...; hyperledger-tsc@...
Subject: RE: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake

 

Hi Rao,

 

Good question.

 

Rather than computation load, PoET relies on trusted execution. The attack against PoET wouldn’t be compute resources but defeating the trusted execution environment (TEE) and forging cryptographic attestations. If the TEE holds, then the wait time (or inter-block) time is analogous to the inter-block time enforced by POW difficulty.  It would be impossible to create a longer fork without creating time. Like POW, the assumption in PoET is the cost to defeat the security mechanism is in excess of the value of a double-spend opportunity.

 

That said, to provide defense in depth, PoET has various counter measures such as checks on the frequency with which a node can win. Also a cheating validator, once discovered, can have its TEE credentials revoked to prevent further attempts by that system.

 

Depending on the deployment there are other defense layers such as policies that can be set for allowing white-listed nodes (e.g. each participant in a consortium registers n validators). If a business’s machine is found to be attacking the consortium, with a cryptographic audit trail, what would that mean for that business?

 

It’s also worth noting that a rogue validator could only cheat on leader election. It could not publish invalid transactions as its peers will still reject those and the block containing them and no fork will be created.

 

 

Thanks,

Dan 

 

From: Rao Dronamraju [mailto:rao.dronamraju@...]
Sent: Sunday, November 06, 2016 13:54
To: 'Arnaud Le Hors' <lehors@...>
Cc: Middleton, Dan <dan.middleton@...>; hyperledger-stl@...; hyperledger-tsc@...
Subject: RE: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake

 

 

Hi Arnaud,

 

Thanks for your reply. Feel free to correct me if I am wrong but my understanding is PoW (Poof of Work) achieves immutability by computing a hash that is below a certain target which takes a lot of computation and consequently time. But the immutability of block hash is the one that makes the transactions immutable for double spend type of fraud that one might perpetrate. The idea behind non-PoW algorithms is to avoid the extensive computation that is needed in PoW for computing the block hash. So in PoET if block hashes are not difficult of break even though one waits a certain time, can’t I go back and change the transactions and the block hash to redo the transactions that have been done? There by breaking the immutability property of block chains? What if I have enough computational power to break the immutability with in the PoET’s wait time? Just curious?

 

Thanks

Rao

 

 

 

From: Arnaud Le Hors [mailto:lehors@...]
Sent: Sunday, November 6, 2016 12:09 PM
To: Rao Dronamraju <rao.dronamraju@...>
Cc: 'Middleton, Dan' <dan.middleton@...>; hyperledger-stl@...; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake

 

Hi Rao,
The whole point of Proof of Work is to take time. This is what makes it hard to rewrite history/rebuild the chain from a point back in time. PoeT achieves the same by forcing a wait time controlled by secure hardware without having the burden of burning CPU to resolve a hash challenge. The result is the same.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM Cloud




From:        Rao Dronamraju via hyperledger-tsc <hyperledger-tsc@...>
To:        "'Tamas Blummer'" <tamas@...>, "'Middleton, Dan'" <dan.middleton@...>
Cc:        hyperledger-stl@..., hyperledger-tsc@...
Date:        11/04/2016 05:47 PM
Subject:        Re: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake
Sent by:        hyperledger-tsc-bounces@...





Hi Folks,
 
I am a passive listener at this time of all the interesting conversations on this forum. I enjoy reading about the great work you folks are doing.
 
I have a dumb question. So in Intel’s sawtooth lake architecture if the fundamental idea is to not use compute intensive PoW algorithms, how do you assure the immutability of a transaction? The lower the hash difficulty factor of a block, doesn’t the degree immutability of the transactions in the block also decrease? Which should also mean it is susceptible to mutability and double spend etc. issues? Wondering how this is taken care of in Intel’s sawtooth architecture?
 
Best Regards,
Rao
 
 
From: hyperledger-technical-discuss-bounces@... [mailto:hyperledger-technical-discuss-bounces@...] On Behalf Of Tamas Blummer via hyperledger-technical-discuss
Sent:
Friday, November 4, 2016 11:14 AM
To:
Middleton, Dan <dan.middleton@...>
Cc:
hyperledger-stl@...; hyperledger-technical-discuss@...; hyperledger-tsc@...
Subject:
Re: [technical-discuss] [Hyperledger Project TSC] Meet Sawtooth Lake

 
An entertaining yet informative summary that motivates to learn more about Sawtooth Lake esp. PoET.
 
Thank you and congratulations Dan!
 
TAMAS BLUMMER
 
​CHIEF LEDGER ARCHITECT​
 


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


 
On 03 Nov 2016, at 17:55, Middleton, Dan via hyperledger-tsc <hyperledger-tsc@...> wrote:
 
I’ve written an informal piece, “Meet Sawtooth Lake,” discussing our design goals.
 
https://www.hyperledger.org/blog/2016/11/02/meet-sawtooth-lake
 
I briefly introduce Consortium Ledgers to motivate scalable consensus (PoET) and safe but powerful smart contracts (Transaction Families).
 
Following POCs across dozens of globally distributed validators, we have some new design elements coming to further address broad scale production deployments.  I alluded to these but plan to describe them more fully in the coming weeks - perhaps verbally at one of our TSC sessions.
 
 
Regards,
 
Dan Middleton
  Intel New Technology Group

 
_______________________________________________
hyperledger-tsc mailing list

hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
 

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-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


Middleton, Dan <dan.middleton@...>
 

Hi Rao,

Yep that is correct. Commits in I think all the ledgers I’ve seen happen at whatever block frequency you can manage.

In PoET that’s configurable but bounded by the settling time for the protocol.

The default is set to 5 seconds to support the easiest experience for new developers using the tutorial.

 

https://github.com/hyperledger/sawtooth-core/blob/master/validator/etc/txnvalidator.js.example#L21

 

From: Rao Dronamraju [mailto:rao.dronamraju@...]
Sent: Monday, November 07, 2016 09:09
To: Middleton, Dan <dan.middleton@...>; 'Arnaud Le Hors' <lehors@...>
Cc: hyperledger-stl@...; hyperledger-tsc@...
Subject: RE: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake

 

Thanks Dan for that excellent explanation.

 

So it appears to me that in PoET also, just like with PoW, there will be some issues with transaction confirmation times. What I mean by this is, in PoW/bitcoin it takes 10 minutes for a block/transaction to be confirmed. Since in PoET one needs to wait based on the time set in PoET algorithm, it will also have similar transaction time confirmation delays. So it is more suitable for non-real time transaction applications, am I right?

 

Also if wait time is reduced, assuming it is a tunable parameter, then it might introduce immutability problems? Lesser the wait time more the probability of mutability?

 

Thanks

Rao

 

 

From: Middleton, Dan [mailto:dan.middleton@...]
Sent: Sunday, November 6, 2016 7:11 PM
To: Rao Dronamraju <rao.dronamraju@...>; 'Arnaud Le Hors' <lehors@...>
Cc: hyperledger-stl@...; hyperledger-tsc@...
Subject: RE: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake

 

Hi Rao,

 

Good question.

 

Rather than computation load, PoET relies on trusted execution. The attack against PoET wouldn’t be compute resources but defeating the trusted execution environment (TEE) and forging cryptographic attestations. If the TEE holds, then the wait time (or inter-block) time is analogous to the inter-block time enforced by POW difficulty.  It would be impossible to create a longer fork without creating time. Like POW, the assumption in PoET is the cost to defeat the security mechanism is in excess of the value of a double-spend opportunity.

 

That said, to provide defense in depth, PoET has various counter measures such as checks on the frequency with which a node can win. Also a cheating validator, once discovered, can have its TEE credentials revoked to prevent further attempts by that system.

 

Depending on the deployment there are other defense layers such as policies that can be set for allowing white-listed nodes (e.g. each participant in a consortium registers n validators). If a business’s machine is found to be attacking the consortium, with a cryptographic audit trail, what would that mean for that business?

 

It’s also worth noting that a rogue validator could only cheat on leader election. It could not publish invalid transactions as its peers will still reject those and the block containing them and no fork will be created.

 

 

Thanks,

Dan 

 

From: Rao Dronamraju [mailto:rao.dronamraju@...]
Sent: Sunday, November 06, 2016 13:54
To: 'Arnaud Le Hors' <lehors@...>
Cc: Middleton, Dan <dan.middleton@...>; hyperledger-stl@...; hyperledger-tsc@...
Subject: RE: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake

 

 

Hi Arnaud,

 

Thanks for your reply. Feel free to correct me if I am wrong but my understanding is PoW (Poof of Work) achieves immutability by computing a hash that is below a certain target which takes a lot of computation and consequently time. But the immutability of block hash is the one that makes the transactions immutable for double spend type of fraud that one might perpetrate. The idea behind non-PoW algorithms is to avoid the extensive computation that is needed in PoW for computing the block hash. So in PoET if block hashes are not difficult of break even though one waits a certain time, can’t I go back and change the transactions and the block hash to redo the transactions that have been done? There by breaking the immutability property of block chains? What if I have enough computational power to break the immutability with in the PoET’s wait time? Just curious?

 

Thanks

Rao

 

 

 

From: Arnaud Le Hors [mailto:lehors@...]
Sent: Sunday, November 6, 2016 12:09 PM
To: Rao Dronamraju <rao.dronamraju@...>
Cc: 'Middleton, Dan' <dan.middleton@...>; hyperledger-stl@...; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake

 

Hi Rao,
The whole point of Proof of Work is to take time. This is what makes it hard to rewrite history/rebuild the chain from a point back in time. PoeT achieves the same by forcing a wait time controlled by secure hardware without having the burden of burning CPU to resolve a hash challenge. The result is the same.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM Cloud




From:        Rao Dronamraju via hyperledger-tsc <hyperledger-tsc@...>
To:        "'Tamas Blummer'" <tamas@...>, "'Middleton, Dan'" <dan.middleton@...>
Cc:        hyperledger-stl@..., hyperledger-tsc@...
Date:        11/04/2016 05:47 PM
Subject:        Re: [Hyperledger Project TSC] [technical-discuss] Meet Sawtooth Lake
Sent by:        hyperledger-tsc-bounces@...





Hi Folks,
 
I am a passive listener at this time of all the interesting conversations on this forum. I enjoy reading about the great work you folks are doing.
 
I have a dumb question. So in Intel’s sawtooth lake architecture if the fundamental idea is to not use compute intensive PoW algorithms, how do you assure the immutability of a transaction? The lower the hash difficulty factor of a block, doesn’t the degree immutability of the transactions in the block also decrease? Which should also mean it is susceptible to mutability and double spend etc. issues? Wondering how this is taken care of in Intel’s sawtooth architecture?
 
Best Regards,
Rao
 
 
From: hyperledger-technical-discuss-bounces@... [mailto:hyperledger-technical-discuss-bounces@...] On Behalf Of Tamas Blummer via hyperledger-technical-discuss
Sent:
Friday, November 4, 2016 11:14 AM
To:
Middleton, Dan <dan.middleton@...>
Cc:
hyperledger-stl@...; hyperledger-technical-discuss@...; hyperledger-tsc@...
Subject:
Re: [technical-discuss] [Hyperledger Project TSC] Meet Sawtooth Lake

 
An entertaining yet informative summary that motivates to learn more about Sawtooth Lake esp. PoET.
 
Thank you and congratulations Dan!
 
TAMAS BLUMMER
 
​CHIEF LEDGER ARCHITECT​
 


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


 
On 03 Nov 2016, at 17:55, Middleton, Dan via hyperledger-tsc <hyperledger-tsc@...> wrote:
 
I’ve written an informal piece, “Meet Sawtooth Lake,” discussing our design goals.
 
https://www.hyperledger.org/blog/2016/11/02/meet-sawtooth-lake
 
I briefly introduce Consortium Ledgers to motivate scalable consensus (PoET) and safe but powerful smart contracts (Transaction Families).
 
Following POCs across dozens of globally distributed validators, we have some new design elements coming to further address broad scale production deployments.  I alluded to these but plan to describe them more fully in the coming weeks - perhaps verbally at one of our TSC sessions.
 
 
Regards,
 
Dan Middleton
  Intel New Technology Group

 
_______________________________________________
hyperledger-tsc mailing list

hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
 

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-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc