[Hyperledger Project TSC] Project Proposal: Consensus Platform


Martin Arrivets <martin@...>
 

Dear all,

 

We would like to submit a HIP for a pluggable consensus platform which

could integrate with Fabric and Burrow.

 

Our platform uses the Hashgraph consensus algorithm which has interesting properties:

- BFT tolerating up to 1/3 of faulty nodes

- Very little communication overhead beyond the transactions themselves

- Fully asynchronous with no concept of leaders

- Difficult for attackers to manipulate the place of transactions in the consensus order.

 

Fabric and Burrow are designed for modularity and the interfaces corresponding to

consensus engines are logically compatible with the interface exposed by our platform.

 

The proposal is at

https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing

 

The existing code is at https://github.com/babbleio/babble

 

We look forward to hearing your feedback and working with the community!

 

Best regards,

 

Martin Arrivets, martin@...

Giacomo Puri Purini, giacomo@...



Tracy Kuhrt <tkuhrt@...>
 

Hi, Martin.

Could you enable comments for all on the document that you shared? This will allow the Hyperledger community to provide comments on your proposal.

----

Tracy Kuhrt
Community Architect, Hyperledger
The Linux Foundation
tkuhrt@...
Skype: tracy.kuhrt


On Mon, Jun 19, 2017 at 4:49 AM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:

Dear all,

 

We would like to submit a HIP for a pluggable consensus platform which

could integrate with Fabric and Burrow.

 

Our platform uses the Hashgraph consensus algorithm which has interesting properties:

- BFT tolerating up to 1/3 of faulty nodes

- Very little communication overhead beyond the transactions themselves

- Fully asynchronous with no concept of leaders

- Difficult for attackers to manipulate the place of transactions in the consensus order.

 

Fabric and Burrow are designed for modularity and the interfaces corresponding to

consensus engines are logically compatible with the interface exposed by our platform.

 

The proposal is at

https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing

 

The existing code is at https://github.com/babbleio/babble

 

We look forward to hearing your feedback and working with the community!

 

Best regards,

 

Martin Arrivets, martin@...

Giacomo Puri Purini, giacomo@...



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



Martin Arrivets <martin@...>
 

Done

-----Original message-----
From: Tracy Kuhrt
Sent: Monday, June 19 2017, 8:12 pm
To: Martin Arrivets
Cc: hyperledger-tsc@...; Giacomo Puri Purini
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Hi, Martin.

Could you enable comments for all on the document that you shared? This will allow the Hyperledger community to provide comments on your proposal.

----

Tracy Kuhrt
Community Architect, Hyperledger
The Linux Foundation
tkuhrt@...
Skype: tracy.kuhrt


On Mon, Jun 19, 2017 at 4:49 AM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:

Dear all,

 

We would like to submit a HIP for a pluggable consensus platform which

could integrate with Fabric and Burrow.

 

Our platform uses the Hashgraph consensus algorithm which has interesting properties:

- BFT tolerating up to 1/3 of faulty nodes

- Very little communication overhead beyond the transactions themselves

- Fully asynchronous with no concept of leaders

- Difficult for attackers to manipulate the place of transactions in the consensus order.

 

Fabric and Burrow are designed for modularity and the interfaces corresponding to

consensus engines are logically compatible with the interface exposed by our platform.

 

The proposal is at

https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing

 

The existing code is at https://github.com/babbleio/babble

 

We look forward to hearing your feedback and working with the community!

 

Best regards,

 

Martin Arrivets, martin@...

Giacomo Puri Purini, giacomo@...



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



Christopher Ferris <chris.ferris@...>
 

Thanks for the proposal, and apologies for the delay in responding due to travel. We'll add to this week's TSC agenda.

Chris

On Jun 19, 2017, at 7:49 AM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:

Dear all,

 

We would like to submit a HIP for a pluggable consensus platform which

could integrate with Fabric and Burrow.

 

Our platform uses the Hashgraph consensus algorithm which has interesting properties:

- BFT tolerating up to 1/3 of faulty nodes

- Very little communication overhead beyond the transactions themselves

- Fully asynchronous with no concept of leaders

- Difficult for attackers to manipulate the place of transactions in the consensus order.

 

Fabric and Burrow are designed for modularity and the interfaces corresponding to

consensus engines are logically compatible with the interface exposed by our platform.

 

The proposal is at

https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing

 

The existing code is at https://github.com/babbleio/babble

 

We look forward to hearing your feedback and working with the community!

 

Best regards,

 

Martin Arrivets, martin@...

Giacomo Puri Purini, giacomo@...


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


David Huseby <dhuseby@...>
 

Is this rated at all to the swirlds hashgraph? IIRC that is patent encumbered. 


Dave


On Sun, Jun 25, 2017 at 2:00 PM Christopher Ferris via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thanks for the proposal, and apologies for the delay in responding due to travel. We'll add to this week's TSC agenda.

Chris

On Jun 19, 2017, at 7:49 AM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:

Dear all,

 

We would like to submit a HIP for a pluggable consensus platform which

could integrate with Fabric and Burrow.

 

Our platform uses the Hashgraph consensus algorithm which has interesting properties:

- BFT tolerating up to 1/3 of faulty nodes

- Very little communication overhead beyond the transactions themselves

- Fully asynchronous with no concept of leaders

- Difficult for attackers to manipulate the place of transactions in the consensus order.

 

Fabric and Burrow are designed for modularity and the interfaces corresponding to

consensus engines are logically compatible with the interface exposed by our platform.

 

The proposal is at

https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing

 

The existing code is at https://github.com/babbleio/babble

 

We look forward to hearing your feedback and working with the community!

 

Best regards,

 

Martin Arrivets, martin@...

Giacomo Puri Purini, giacomo@...


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
Skype: dwhuseby


Martin Arrivets <martin@...>
 

Thanks,

It is related in the sense that it uses the same consensus algorithm. 
The algorithm is described in a public whitepaper and this is what we based our work from.  

I believe the patent is for a distributed database COUPLED with an ordering system that uses the Hashgraph algorithm.

Our platform is just an ordering system and is completely decoupled from the application using it.
The ordering system and the app can run on separate machines. 

Hope this clarifies things.

Martin

-----Original message-----
From: David Huseby
Sent: Monday, June 26 2017, 9:06 am
To: Christopher Ferris; Martin Arrivets
Cc: Giacomo Puri Purini; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Is this rated at all to the swirlds hashgraph? IIRC that is patent encumbered. 


Dave

On Sun, Jun 25, 2017 at 2:00 PM Christopher Ferris via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thanks for the proposal, and apologies for the delay in responding due to travel. We'll add to this week's TSC agenda.

Chris

On Jun 19, 2017, at 7:49 AM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:

Dear all,

 

We would like to submit a HIP for a pluggable consensus platform which

could integrate with Fabric and Burrow.

 

Our platform uses the Hashgraph consensus algorithm which has interesting properties:

- BFT tolerating up to 1/3 of faulty nodes

- Very little communication overhead beyond the transactions themselves

- Fully asynchronous with no concept of leaders

- Difficult for attackers to manipulate the place of transactions in the consensus order.

 

Fabric and Burrow are designed for modularity and the interfaces corresponding to

consensus engines are logically compatible with the interface exposed by our platform.

 

The proposal is at

https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing

 

The existing code is at https://github.com/babbleio/babble

 

We look forward to hearing your feedback and working with the community!

 

Best regards,

 

Martin Arrivets, martin@...

Giacomo Puri Purini, giacomo@...


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
Skype: dwhuseby


David Huseby <dhuseby@...>
 

So are you saying that to get around the patent you have to have the ordering done on a separate machine from the app generating the blocks? How does that work? I thought the whole benefit of hashgraph was that it allowed for massive scaling because the app nodes did the ordering locally with virtual voting based on the gossip events between nodes. Wouldn't decoupling of the ordering from the app ruin the scaling because you're centralizing the ordering service?

Dave


On Mon, Jun 26, 2017 at 2:29 AM Martin Arrivets <martin@...> wrote:
Thanks,

It is related in the sense that it uses the same consensus algorithm. 
The algorithm is described in a public whitepaper and this is what we based our work from.  

I believe the patent is for a distributed database COUPLED with an ordering system that uses the Hashgraph algorithm.

Our platform is just an ordering system and is completely decoupled from the application using it.
The ordering system and the app can run on separate machines. 

Hope this clarifies things.

Martin

-----Original message-----
From: David Huseby
Sent: Monday, June 26 2017, 9:06 am
To: Christopher Ferris; Martin Arrivets
Cc: Giacomo Puri Purini; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Is this rated at all to the swirlds hashgraph? IIRC that is patent encumbered. 


Dave

On Sun, Jun 25, 2017 at 2:00 PM Christopher Ferris via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thanks for the proposal, and apologies for the delay in responding due to travel. We'll add to this week's TSC agenda.

Chris

On Jun 19, 2017, at 7:49 AM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:

Dear all,

 

We would like to submit a HIP for a pluggable consensus platform which

could integrate with Fabric and Burrow.

 

Our platform uses the Hashgraph consensus algorithm which has interesting properties:

- BFT tolerating up to 1/3 of faulty nodes

- Very little communication overhead beyond the transactions themselves

- Fully asynchronous with no concept of leaders

- Difficult for attackers to manipulate the place of transactions in the consensus order.

 

Fabric and Burrow are designed for modularity and the interfaces corresponding to

consensus engines are logically compatible with the interface exposed by our platform.

 

The proposal is at

https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing

 

The existing code is at https://github.com/babbleio/babble

 

We look forward to hearing your feedback and working with the community!

 

Best regards,

 

Martin Arrivets, martin@...

Giacomo Puri Purini, giacomo@...


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
Skype: dwhuseby
--
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
Skype: dwhuseby


Martin Arrivets <martin@...>
 

By 'App' I mean the component that consumes transactions (or blocks of transactions) ordered by the Ordering System.
Decoupling the App from the Ordering System has no effect on the scalability of the Ordering System.
As a matter of fact, Fabric and Burrow are designed that way... this is what allows for pluggable consensus.

The important thing is how this decoupling is done. 
In our case, the communication between both components is defined by a TCP interface, allowing them to run on separate machines.
Swirlds and its patent, on the other hand, describe a system where both components run on the same 'compute device':
"[...] and a database convergence module implemented in a memory or a processor of the first compute device, the database convergence module operatively coupled to the instance of the distributed database"
Typically this means that the convergence module and the distributed database are part of one big program.

We are not trying to get around the patent.
It just seems that Swirlds is not patenting a pluggable consensus middleware component but a monolithic framework for database replication.

Martin

-----Original message-----
From: David Huseby
Sent: Monday, June 26 2017, 4:09 pm
To: Christopher Ferris; Martin Arrivets
Cc: Giacomo Puri Purini; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

So are you saying that to get around the patent you have to have the ordering done on a separate machine from the app generating the blocks? How does that work? I thought the whole benefit of hashgraph was that it allowed for massive scaling because the app nodes did the ordering locally with virtual voting based on the gossip events between nodes. Wouldn't decoupling of the ordering from the app ruin the scaling because you're centralizing the ordering service?

Dave

On Mon, Jun 26, 2017 at 2:29 AM Martin Arrivets <martin@...> wrote:
Thanks,

It is related in the sense that it uses the same consensus algorithm. 
The algorithm is described in a public whitepaper and this is what we based our work from.  

I believe the patent is for a distributed database COUPLED with an ordering system that uses the Hashgraph algorithm.

Our platform is just an ordering system and is completely decoupled from the application using it.
The ordering system and the app can run on separate machines. 

Hope this clarifies things.

Martin

-----Original message-----
From: David Huseby
Sent: Monday, June 26 2017, 9:06 am
To: Christopher Ferris; Martin Arrivets
Cc: Giacomo Puri Purini; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Is this rated at all to the swirlds hashgraph? IIRC that is patent encumbered. 


Dave

On Sun, Jun 25, 2017 at 2:00 PM Christopher Ferris via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thanks for the proposal, and apologies for the delay in responding due to travel. We'll add to this week's TSC agenda.

Chris

On Jun 19, 2017, at 7:49 AM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:

Dear all,

 

We would like to submit a HIP for a pluggable consensus platform which

could integrate with Fabric and Burrow.

 

Our platform uses the Hashgraph consensus algorithm which has interesting properties:

- BFT tolerating up to 1/3 of faulty nodes

- Very little communication overhead beyond the transactions themselves

- Fully asynchronous with no concept of leaders

- Difficult for attackers to manipulate the place of transactions in the consensus order.

 

Fabric and Burrow are designed for modularity and the interfaces corresponding to

consensus engines are logically compatible with the interface exposed by our platform.

 

The proposal is at

https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing

 

The existing code is at https://github.com/babbleio/babble

 

We look forward to hearing your feedback and working with the community!

 

Best regards,

 

Martin Arrivets, martin@...

Giacomo Puri Purini, giacomo@...


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
Skype: dwhuseby
--
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
Skype: dwhuseby


Christian Cachin <cca@...>
 

Martin,

Can you point to any independent analysis of the properties achieved by
Swirlds consensus? In which sense does it reach "consensus"? Are there
any peer-reviewed publications or other third-party endorsements available?

In analogy with cryptography, where such issues have been discussed at
large, and over many decades, the security of a system should be based
on well-established and widely agreed-on schemes.

(FYI - I'm a cryptographer and also working on consensus protocols...)

Regards,

Christian


---
Christian Cachin email: cca@...
IBM Research - Zurich tel: +41-44-724-8989
Säumerstrasse 4
CH-8803 Rüschlikon, Switzerland http://www.zurich.ibm.com/~cca

On 26 Jun 2017 09:29:36 +0000, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thanks,

It is related in the sense that it uses the same consensus algorithm. 
The algorithm is described in a public whitepaper <http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>  and this is what we based our work from.  

I believe the patent is for a distributed database COUPLED with an ordering system that uses the Hashgraph algorithm.

Our platform is just an ordering system and is completely decoupled from the application using it.
The ordering system and the app can run on separate machines. 

Hope this clarifies things.

Martin

-----Original message-----
From: David Huseby
Sent: Monday, June 26 2017, 9:06 am
To: Christopher Ferris; Martin Arrivets
Cc: Giacomo Puri Purini; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Is this rated at all to the swirlds hashgraph? IIRC that is patent encumbered. 

http://www.swirlds.com/ip/ <http://www.swirlds.com/ip/>

Dave

On Sun, Jun 25, 2017 at 2:00 PM Christopher Ferris via hyperledger-tsc <hyperledger-tsc@... <mailto:hyperledger-tsc@...> > wrote:
Thanks for the proposal, and apologies for the delay in responding due to travel. We'll add to this week's TSC agenda.

Chris

On Jun 19, 2017, at 7:49 AM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@... <mailto:hyperledger-tsc@...> > wrote:

Dear all,

 
We would like to submit a HIP for a pluggable consensus platform which

could integrate with Fabric and Burrow.

 
Our platform uses the Hashgraph consensus algorithm which has interesting properties:

- BFT tolerating up to 1/3 of faulty nodes

- Very little communication overhead beyond the transactions themselves

- Fully asynchronous with no concept of leaders

- Difficult for attackers to manipulate the place of transactions in the consensus order.

 
Fabric and Burrow are designed for modularity and the interfaces corresponding to

consensus engines are logically compatible with the interface exposed by our platform.

 
The proposal is at

https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing

 
The existing code is at https://github.com/babbleio/babble

 
We look forward to hearing your feedback and working with the community!


 
Best regards,

 
Martin Arrivets, martin@... <mailto:martin@...>

Giacomo Puri Purini, giacomo@... <mailto:giacomo@...>


Martin Arrivets <martin@...>
 

Hi Christian,

The system achieves consensus in the sense that a participant will eventually know the exact location 
of a transaction in history and have a mathematical guarantee of finality (that this is the consensus order). 
The knowledge is not probabilistic but a mathematical guarantee.

The proofs in the whitepaper make the standard assumptions:

More than 2/3 of the computers are "honest", which means they follow the algorithm correctly and are available.
Although an honest computer may go down for a while (and stop communicating) as long as they eventually come
back up.

Nodes can collude and are allowed to mostly control the internet . Their only limit on control on the internet is 
that if Alice repeatedly sends Bob messages they must eventually allow Bob to receive one.

The proofs are for a fully asynchronous system. There is no assumption that an honest node will always respond within
a certain interval. If all the nodes go to sleep, then progress continues as soon as they come back up.
In normal conditions with a small number of nodes, consensus can happen in less than a second.

I am not aware of any third-party reviews of the whitepaper. 

The concepts are very similar to other voting-based BFT algorithms except the voting is "virtual". 
If the security of those systems (like PBFT or Tendermint...) has been vetted by the schemes you 
mention then perhaps they could be applied to Hashgraph as well.

Hope this answers you questions.

Regards,
Martin

-----Original message-----
From: Christian Cachin
Sent: Tuesday, June 27 2017, 11:43 am
To: Martin Arrivets via hyperledger-tsc
Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri Purini
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Martin,

Can you point to any independent analysis of the properties achieved by
Swirlds consensus? In which sense does it reach "consensus"? Are there
any peer-reviewed publications or other third-party endorsements available?

In analogy with cryptography, where such issues have been discussed at
large, and over many decades, the security of a system should be based
on well-established and widely agreed-on schemes.

(FYI - I'm a cryptographer and also working on consensus protocols...)

Regards,

Christian


---
Christian Cachin email: cca@...
IBM Research - Zurich tel: +41-44-724-8989
Säumerstrasse 4
CH-8803 Rüschlikon, Switzerland http://www.zurich.ibm.com/˜cca





On 26 Jun 2017 09:29:36 +0000, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:
> Thanks,
>
> It is related in the sense that it uses the same consensus algorithm. 
> The algorithm is described in a public whitepaper <http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>;  and this is what we based our work from.  
>
> I believe the patent is for a distributed database COUPLED with an ordering system that uses the Hashgraph algorithm.
>
> Our platform is just an ordering system and is completely decoupled from the application using it.
> The ordering system and the app can run on separate machines. 
>
> Hope this clarifies things.
>
> Martin
>
> -----Original message-----
> From: David Huseby
> Sent: Monday, June 26 2017, 9:06 am
> To: Christopher Ferris; Martin Arrivets
> Cc: Giacomo Puri Purini; hyperledger-tsc@...
> Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform
>
> Is this rated at all to the swirlds hashgraph? IIRC that is patent encumbered. 
>
> http://www.swirlds.com/ip/ <http://www.swirlds.com/ip/>;
>
> Dave
>
> On Sun, Jun 25, 2017 at 2:00 PM Christopher Ferris via hyperledger-tsc <hyperledger-tsc@... <mailto:hyperledger-tsc@...> > wrote:
> Thanks for the proposal, and apologies for the delay in responding due to travel. We'll add to this week's TSC agenda.
>
> Chris
>
> On Jun 19, 2017, at 7:49 AM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@... <mailto:hyperledger-tsc@...> > wrote:
>
> Dear all,
>
>  
> We would like to submit a HIP for a pluggable consensus platform which
>
> could integrate with Fabric and Burrow.
>
>  
> Our platform uses the Hashgraph consensus algorithm which has interesting properties:
>
> - BFT tolerating up to 1/3 of faulty nodes
>
> - Very little communication overhead beyond the transactions themselves
>
> - Fully asynchronous with no concept of leaders
>
> - Difficult for attackers to manipulate the place of transactions in the consensus order.
>
>  
> Fabric and Burrow are designed for modularity and the interfaces corresponding to
>
> consensus engines are logically compatible with the interface exposed by our platform.
>
>  
> The proposal is at
>
> https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing
>
>  
> The existing code is at https://github.com/babbleio/babble
>
>  
> We look forward to hearing your feedback and working with the community!
>
>
>  
> Best regards,
>
>  
> Martin Arrivets, martin@... <mailto:martin@...>
>
> Giacomo Puri Purini, giacomo@... <mailto:giacomo@...>
>



Stefan Buhrmester <buhrmi@...>
 

Hi Martin,

thanks for the proposal. Been proposing a hashgraph implementation
into Hyperledger for a long time but I guess it's too difficult for
most people to see the benefits. Happy to finally to see a proposal
from a like-minded person. I'm especially interested in research or
development being done on the "allow adding peers dynamically"
feature. If this can be implemented, it would be a technological
break-through. Do you think it is realistic?

Cheers,
Stefan

On Tue, Jun 27, 2017 at 9:03 PM, Martin Arrivets via hyperledger-tsc
<hyperledger-tsc@...> wrote:
Hi Christian,

The system achieves consensus in the sense that a participant will
eventually know the exact location
of a transaction in history and have a mathematical guarantee of finality
(that this is the consensus order).
The knowledge is not probabilistic but a mathematical guarantee.

The proofs in the whitepaper make the standard assumptions:

More than 2/3 of the computers are "honest", which means they follow the
algorithm correctly and are available.
Although an honest computer may go down for a while (and stop communicating)
as long as they eventually come
back up.

Nodes can collude and are allowed to mostly control the internet . Their
only limit on control on the internet is
that if Alice repeatedly sends Bob messages they must eventually allow Bob
to receive one.

The proofs are for a fully asynchronous system. There is no assumption that
an honest node will always respond within
a certain interval. If all the nodes go to sleep, then progress continues as
soon as they come back up.
In normal conditions with a small number of nodes, consensus can happen in
less than a second.

I am not aware of any third-party reviews of the whitepaper.

The concepts are very similar to other voting-based BFT algorithms except
the voting is "virtual".
If the security of those systems (like PBFT or Tendermint...) has been
vetted by the schemes you
mention then perhaps they could be applied to Hashgraph as well.

Hope this answers you questions.

Regards,
Martin

-----Original message-----
From: Christian Cachin
Sent: Tuesday, June 27 2017, 11:43 am
To: Martin Arrivets via hyperledger-tsc
Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri Purini
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Martin,

Can you point to any independent analysis of the properties achieved by
Swirlds consensus? In which sense does it reach "consensus"? Are there
any peer-reviewed publications or other third-party endorsements available?

In analogy with cryptography, where such issues have been discussed at
large, and over many decades, the security of a system should be based
on well-established and widely agreed-on schemes.

(FYI - I'm a cryptographer and also working on consensus protocols...)

Regards,

Christian


---
Christian Cachin email: cca@...
IBM Research - Zurich tel: +41-44-724-8989
Säumerstrasse 4
CH-8803 Rüschlikon, Switzerland http://www.zurich.ibm.com/˜cca





On 26 Jun 2017 09:29:36 +0000, Martin Arrivets via hyperledger-tsc
<hyperledger-tsc@...> wrote:
Thanks,

It is related in the sense that it uses the same consensus algorithm.
The algorithm is described in a public whitepaper
<http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>; and this is what
we based our work from.

I believe the patent is for a distributed database COUPLED with an
ordering system that uses the Hashgraph algorithm.

Our platform is just an ordering system and is completely decoupled from
the application using it.
The ordering system and the app can run on separate machines.

Hope this clarifies things.

Martin

-----Original message-----
From: David Huseby
Sent: Monday, June 26 2017, 9:06 am
To: Christopher Ferris; Martin Arrivets
Cc: Giacomo Puri Purini; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus
Platform

Is this rated at all to the swirlds hashgraph? IIRC that is patent
encumbered.

http://www.swirlds.com/ip/ <http://www.swirlds.com/ip/>;

Dave

On Sun, Jun 25, 2017 at 2:00 PM Christopher Ferris via hyperledger-tsc
<hyperledger-tsc@...
<mailto:hyperledger-tsc@...> > wrote:
Thanks for the proposal, and apologies for the delay in responding due to
travel. We'll add to this week's TSC agenda.

Chris

On Jun 19, 2017, at 7:49 AM, Martin Arrivets via hyperledger-tsc
<hyperledger-tsc@...
<mailto:hyperledger-tsc@...> > wrote:

Dear all,


We would like to submit a HIP for a pluggable consensus platform which

could integrate with Fabric and Burrow.


Our platform uses the Hashgraph consensus algorithm which has interesting
properties:

- BFT tolerating up to 1/3 of faulty nodes

- Very little communication overhead beyond the transactions themselves

- Fully asynchronous with no concept of leaders

- Difficult for attackers to manipulate the place of transactions in the
consensus order.


Fabric and Burrow are designed for modularity and the interfaces
corresponding to

consensus engines are logically compatible with the interface exposed by
our platform.


The proposal is at


https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing


The existing code is at https://github.com/babbleio/babble


We look forward to hearing your feedback and working with the community!



Best regards,


Martin Arrivets, martin@... <mailto:martin@...>

Giacomo Puri Purini, giacomo@... <mailto:giacomo@...>


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


Martin Arrivets <martin@...>
 

Thanks Stephan,

Yes I am convinced it is totally feasible. There is actually a section about this in the whitepaper.
The idea is to have a special type of transaction that modifies the list of peers. This is a special 
transaction because it updates an object that pertains to the Ordering System, not the App.
When a node sees that such a transaction has reached consensus, it updates its list of peers accordingly
and all subsequent voting uses that new list.

Tendermint already has this feature actually. It is a permissioned blockchain where validators can
be added or removed on the go. It uses the same technique more or less.

Cheers,
Martin


-----Original message-----
From: Stefan Buhrmester
Sent: Tuesday, June 27 2017, 3:13 pm
To: Martin Arrivets
Cc: Christian Cachin; Martin Arrivets via hyperledger-tsc; Giacomo Puri Purini
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Hi Martin,

thanks for the proposal. Been proposing a hashgraph implementation
into Hyperledger for a long time but I guess it's too difficult for
most people to see the benefits. Happy to finally to see a proposal
from a like-minded person. I'm especially interested in research or
development being done on the "allow adding peers dynamically"
feature. If this can be implemented, it would be a technological
break-through. Do you think it is realistic?

Cheers,
Stefan

On Tue, Jun 27, 2017 at 9:03 PM, Martin Arrivets via hyperledger-tsc
<hyperledger-tsc@...> wrote:
> Hi Christian,
>
> The system achieves consensus in the sense that a participant will
> eventually know the exact location
> of a transaction in history and have a mathematical guarantee of finality
> (that this is the consensus order).
> The knowledge is not probabilistic but a mathematical guarantee.
>
> The proofs in the whitepaper make the standard assumptions:
>
> More than 2/3 of the computers are "honest", which means they follow the
> algorithm correctly and are available.
> Although an honest computer may go down for a while (and stop communicating)
> as long as they eventually come
> back up.
>
> Nodes can collude and are allowed to mostly control the internet . Their
> only limit on control on the internet is
> that if Alice repeatedly sends Bob messages they must eventually allow Bob
> to receive one.
>
> The proofs are for a fully asynchronous system. There is no assumption that
> an honest node will always respond within
> a certain interval. If all the nodes go to sleep, then progress continues as
> soon as they come back up.
> In normal conditions with a small number of nodes, consensus can happen in
> less than a second.
>
> I am not aware of any third-party reviews of the whitepaper.
>
> The concepts are very similar to other voting-based BFT algorithms except
> the voting is "virtual".
> If the security of those systems (like PBFT or Tendermint...) has been
> vetted by the schemes you
> mention then perhaps they could be applied to Hashgraph as well.
>
> Hope this answers you questions.
>
> Regards,
> Martin
>
> -----Original message-----
> From: Christian Cachin
> Sent: Tuesday, June 27 2017, 11:43 am
> To: Martin Arrivets via hyperledger-tsc
> Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri Purini
> Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform
>
> Martin,
>
> Can you point to any independent analysis of the properties achieved by
> Swirlds consensus? In which sense does it reach "consensus"? Are there
> any peer-reviewed publications or other third-party endorsements available?
>
> In analogy with cryptography, where such issues have been discussed at
> large, and over many decades, the security of a system should be based
> on well-established and widely agreed-on schemes.
>
> (FYI - I'm a cryptographer and also working on consensus protocols...)
>
> Regards,
>
> Christian
>
>
> ---
> Christian Cachin email: cca@...
> IBM Research - Zurich tel: +41-44-724-8989
> Säumerstrasse 4
> CH-8803 Rüschlikon, Switzerland http://www.zurich.ibm.com/˜cca
>
>
>
>
>
> On 26 Jun 2017 09:29:36 +0000, Martin Arrivets via hyperledger-tsc
> <hyperledger-tsc@...> wrote:
>> Thanks,
>>
>> It is related in the sense that it uses the same consensus algorithm.
>> The algorithm is described in a public whitepaper
>> <http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>;; and this is what
>> we based our work from.
>>
>> I believe the patent is for a distributed database COUPLED with an
>> ordering system that uses the Hashgraph algorithm.
>>
>> Our platform is just an ordering system and is completely decoupled from
>> the application using it.
>> The ordering system and the app can run on separate machines.
>>
>> Hope this clarifies things.
>>
>> Martin
>>
>> -----Original message-----
>> From: David Huseby
>> Sent: Monday, June 26 2017, 9:06 am
>> To: Christopher Ferris; Martin Arrivets
>> Cc: Giacomo Puri Purini; hyperledger-tsc@...
>> Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus
>> Platform
>>
>> Is this rated at all to the swirlds hashgraph? IIRC that is patent
>> encumbered.
>>
>> http://www.swirlds.com/ip/ <http://www.swirlds.com/ip/>;;
>>
>> Dave
>>
>> On Sun, Jun 25, 2017 at 2:00 PM Christopher Ferris via hyperledger-tsc
>> <hyperledger-tsc@...
>> <mailto:hyperledger-tsc@...> > wrote:
>> Thanks for the proposal, and apologies for the delay in responding due to
>> travel. We'll add to this week's TSC agenda.
>>
>> Chris
>>
>> On Jun 19, 2017, at 7:49 AM, Martin Arrivets via hyperledger-tsc
>> <hyperledger-tsc@...
>> <mailto:hyperledger-tsc@...> > wrote:
>>
>> Dear all,
>>
>>
>> We would like to submit a HIP for a pluggable consensus platform which
>>
>> could integrate with Fabric and Burrow.
>>
>>
>> Our platform uses the Hashgraph consensus algorithm which has interesting
>> properties:
>>
>> - BFT tolerating up to 1/3 of faulty nodes
>>
>> - Very little communication overhead beyond the transactions themselves
>>
>> - Fully asynchronous with no concept of leaders
>>
>> - Difficult for attackers to manipulate the place of transactions in the
>> consensus order.
>>
>>
>> Fabric and Burrow are designed for modularity and the interfaces
>> corresponding to
>>
>> consensus engines are logically compatible with the interface exposed by
>> our platform.
>>
>>
>> The proposal is at
>>
>>
>> https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing
>>
>>
>> The existing code is at https://github.com/babbleio/babble
>>
>>
>> We look forward to hearing your feedback and working with the community!
>>
>>
>>
>> Best regards,
>>
>>
>> Martin Arrivets, martin@... <mailto:martin@...>
>>
>> Giacomo Puri Purini, giacomo@... <mailto:giacomo@...>
>>
>
>
>
> _______________________________________________
> hyperledger-tsc mailing list
> hyperledger-tsc@...
> https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
>


Marko Vukolic <mvu@...>
 

Hi all,

(assuming Swirlds actually implements consensus suitable for Hyperledger Fabric - as it is not peer reviewed let's just assume this with all goodwill)

Can someone please summarize briefly what would be the advantage of using Swirlds over other protocols? Other protocols may include but are not limited to (e.g., PBFT, Spinning, BFT-Mencius, Aliph, Aardvark, Algorand, Honeybadger, MinBFT, and other proven protocols) as well as unproven (e.g., Tendermint).

In other words - can you briefly suggest - why Swirlds and not something else?

best,
Marko

Dr. Marko Vukolić                         email: mvu@...
Research Staff Member                              tel: +41-44-724-8434
IBM Research - Zurich                          
Säumerstrasse 4

CH-8803 Rüschlikon, Switzerland
   



From:        Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...>
To:        Stefan Buhrmester <buhrmi@...>
Cc:        Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...>, Giacomo Puri Purini <giacomo@...>
Date:        27.06.2017 16:08
Subject:        Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform
Sent by:        hyperledger-tsc-bounces@...




Thanks Stephan,

Yes I am convinced it is totally feasible. There is actually a section about this in the whitepaper.
The idea is to have a special type of transaction that modifies the list of peers. This is a special
transaction because it updates an object that pertains to the Ordering System, not the App.
When a node sees that such a transaction has reached consensus, it updates its list of peers accordingly
and all subsequent voting uses that new list.

Tendermint already has this feature actually. It is a permissioned blockchain where validators can
be added or removed on the go. It uses the same technique more or less.

Cheers,
Martin


-----Original message-----
From:
Stefan Buhrmester
Sent:
Tuesday, June 27 2017, 3:13 pm
To:
Martin Arrivets
Cc:
Christian Cachin; Martin Arrivets via hyperledger-tsc; Giacomo Puri Purini
Subject:
Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Hi Martin,

thanks for the proposal. Been proposing a hashgraph implementation
into Hyperledger for a long time but I guess it's too difficult for
most people to see the benefits. Happy to finally to see a proposal
from a like-minded person. I'm especially interested in research or
development being done on the "allow adding peers dynamically"
feature. If this can be implemented, it would be a technological
break-through. Do you think it is realistic?

Cheers,
Stefan

On Tue, Jun 27, 2017 at 9:03 PM, Martin Arrivets via hyperledger-tsc
<
hyperledger-tsc@...> wrote:
> Hi Christian,
>
> The system achieves consensus in the sense that a participant will
> eventually know the exact location
> of a transaction in history and have a mathematical guarantee of finality
> (that this is the consensus order).
> The knowledge is not probabilistic but a mathematical guarantee.
>
> The proofs in the whitepaper make the standard assumptions:
>
> More than 2/3 of the computers are "honest", which means they follow the
> algorithm correctly and are available.
> Although an honest computer may go down for a while (and stop communicating)
> as long as they eventually come
> back up.
>
> Nodes can collude and are allowed to mostly control the internet . Their
> only limit on control on the internet is
> that if Alice repeatedly sends Bob messages they must eventually allow Bob
> to receive one.
>
> The proofs are for a fully asynchronous system. There is no assumption that
> an honest node will always respond within
> a certain interval. If all the nodes go to sleep, then progress continues as
> soon as they come back up.
> In normal conditions with a small number of nodes, consensus can happen in
> less than a second.
>
> I am not aware of any third-party reviews of the whitepaper.
>
> The concepts are very similar to other voting-based BFT algorithms except
> the voting is "virtual".
> If the security of those systems (like PBFT or Tendermint...) has been
> vetted by the schemes you
> mention then perhaps they could be applied to Hashgraph as well.
>
> Hope this answers you questions.
>
> Regards,
> Martin
>
> -----Original message-----
> From: Christian Cachin
> Sent: Tuesday, June 27 2017, 11:43 am
> To: Martin Arrivets via hyperledger-tsc
> Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri Purini
> Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform
>
> Martin,
>
> Can you point to any independent analysis of the properties achieved by
> Swirlds consensus?  In which sense does it reach "consensus"?  Are there
> any peer-reviewed publications or other third-party endorsements available?
>
> In analogy with cryptography, where such issues have been discussed at
> large, and over many decades, the security of a system should be based
> on well-established and widely agreed-on schemes.
>
> (FYI - I'm a cryptographer and also working on consensus protocols...)
>
> Regards,
>
>                  Christian
>
>
> ---
> Christian Cachin                           email:
cca@...
> IBM Research - Zurich                           tel: +41-44-724-8989
> Säumerstrasse 4
> CH-8803 Rüschlikon, Switzerland      
http://www.zurich.ibm.com/˜cca
>
>
>
>
>
> On 26 Jun 2017 09:29:36 +0000, Martin Arrivets via hyperledger-tsc
> <
hyperledger-tsc@...> wrote:
>> Thanks,
>>
>> It is related in the sense that it uses the same consensus algorithm.
>> The algorithm is described in a public whitepaper
>> <
http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>;;  and this is what
>> we based our work from.
>>
>> I believe the patent is for a distributed database COUPLED with an
>> ordering system that uses the Hashgraph algorithm.
>>
>> Our platform is just an ordering system and is completely decoupled from
>> the application using it.
>> The ordering system and the app can run on separate machines.
>>
>> Hope this clarifies things.
>>
>> Martin
>>
>> -----Original message-----
>> From: David Huseby
>> Sent: Monday, June 26 2017, 9:06 am
>> To: Christopher Ferris; Martin Arrivets
>> Cc: Giacomo Puri Purini;
hyperledger-tsc@...
>> Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus
>> Platform
>>
>> Is this rated at all to the swirlds hashgraph? IIRC that is patent
>> encumbered.
>>
>>
http://www.swirlds.com/ip/ <http://www.swirlds.com/ip/>;;
>>
>> Dave
>>
>> On Sun, Jun 25, 2017 at 2:00 PM Christopher Ferris via hyperledger-tsc
>> <
hyperledger-tsc@...
>> <mailto:
hyperledger-tsc@...> > wrote:
>> Thanks for the proposal, and apologies for the delay in responding due to
>> travel. We'll add to this week's TSC agenda.
>>
>> Chris
>>
>> On Jun 19, 2017, at 7:49 AM, Martin Arrivets via hyperledger-tsc
>> <
hyperledger-tsc@...
>> <mailto:
hyperledger-tsc@...> > wrote:
>>
>> Dear all,
>>
>>
>> We would like to submit a HIP for a pluggable consensus platform which
>>
>> could integrate with Fabric and Burrow.
>>
>>
>> Our platform uses the Hashgraph consensus algorithm which has interesting
>> properties:
>>
>> - BFT tolerating up to 1/3 of faulty nodes
>>
>> - Very little communication overhead beyond the transactions themselves
>>
>> - Fully asynchronous with no concept of leaders
>>
>> - Difficult for attackers to manipulate the place of transactions in the
>> consensus order.
>>
>>
>> Fabric and Burrow are designed for modularity and the interfaces
>> corresponding to
>>
>> consensus engines are logically compatible with the interface exposed by
>> our platform.
>>
>>
>> The proposal is at
>>
>>
>>
https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing
>>
>>
>> The existing code is at
https://github.com/babbleio/babble
>>
>>
>> We look forward to hearing your feedback and working with the community!
>>
>>
>>
>> Best regards,
>>
>>
>> Martin Arrivets,
martin@...<mailto:martin@...>
>>
>> Giacomo Puri Purini,
giacomo@...<mailto:giacomo@...>
>>
>
>
>
> _______________________________________________
> hyperledger-tsc mailing list
>
hyperledger-tsc@...
>
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
>
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



Martin Arrivets <martin@...>
 

Hi Marko,

As mentionned in the proposal, the Hashgraph algorithm has the following properties:

- the number of messages exchanged to commit a transaction is linear with regards to the 
number of participants. This is better than most other  BFT algorithms which are quadratic at best.

- It achieves a concept of fairness which is not achieved by other leader-based or Nakamoto systems.
 By fairness we mean that it is hard for a node to manipulate which of two transactions is first in the
 consensus order.  This is very important if you are implementing something like a stock exchange or
 anything where it matters who's transaction came first.

What do you mean by proven and unproven?

Also what do you mean by consensus suitable for Hyperledger Fabric? From what I understand, Fabric 
was designed to be consensus agnostic. Some organisations will be happy to use a single server as the 
ordering system. Others might need something that scales massively in which case Algorand would be a good fit. 
Others yet might require a system that is Byzantine Fault Tolerant and achieves fairness in a permissioned network. 
This is the whole idea behind Hyperldedger. The more alternatives to chose from, the better.

Martin

-----Original message-----
From: Marko Vukolic
Sent: Tuesday, June 27 2017, 5:04 pm
To: Martin Arrivets
Cc: Stefan Buhrmester; Martin Arrivets via hyperledger-tsc; Giacomo Puri Purini
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Hi all,

(assuming Swirlds actually implements consensus suitable for Hyperledger Fabric - as it is not peer reviewed let's just assume this with all goodwill)

Can someone please summarize briefly what would be the advantage of using Swirlds over other protocols? Other protocols may include but are not limited to (e.g., PBFT, Spinning, BFT-Mencius, Aliph, Aardvark, Algorand, Honeybadger, MinBFT, and other proven protocols) as well as unproven (e.g., Tendermint).

In other words - can you briefly suggest - why Swirlds and not something else?

best,
Marko

Dr. Marko Vukolić                         email: mvu@...
Research Staff Member                              tel: +41-44-724-8434
IBM Research - Zurich                          
Säumerstrasse 4

CH-8803 Rüschlikon, Switzerland
   



From:        Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...>
To:        Stefan Buhrmester <buhrmi@...>
Cc:        Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...>, Giacomo Puri Purini <giacomo@...>
Date:        27.06.2017 16:08
Subject:        Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform
Sent by:        hyperledger-tsc-bounces@...




Thanks Stephan,

Yes I am convinced it is totally feasible. There is actually a section about this in the whitepaper.
The idea is to have a special type of transaction that modifies the list of peers. This is a special
transaction because it updates an object that pertains to the Ordering System, not the App.
When a node sees that such a transaction has reached consensus, it updates its list of peers accordingly
and all subsequent voting uses that new list.

Tendermint already has this feature actually. It is a permissioned blockchain where validators can
be added or removed on the go. It uses the same technique more or less.

Cheers,
Martin


-----Original message-----
From:
Stefan Buhrmester
Sent:
Tuesday, June 27 2017, 3:13 pm
To:
Martin Arrivets
Cc:
Christian Cachin; Martin Arrivets via hyperledger-tsc; Giacomo Puri Purini
Subject:
Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Hi Martin,

thanks for the proposal. Been proposing a hashgraph implementation
into Hyperledger for a long time but I guess it's too difficult for
most people to see the benefits. Happy to finally to see a proposal
from a like-minded person. I'm especially interested in research or
development being done on the "allow adding peers dynamically"
feature. If this can be implemented, it would be a technological
break-through. Do you think it is realistic?

Cheers,
Stefan

On Tue, Jun 27, 2017 at 9:03 PM, Martin Arrivets via hyperledger-tsc
<
hyperledger-tsc@...> wrote:
> Hi Christian,
>
> The system achieves consensus in the sense that a participant will
> eventually know the exact location
> of a transaction in history and have a mathematical guarantee of finality
> (that this is the consensus order).
> The knowledge is not probabilistic but a mathematical guarantee.
>
> The proofs in the whitepaper make the standard assumptions:
>
> More than 2/3 of the computers are "honest", which means they follow the
> algorithm correctly and are available.
> Although an honest computer may go down for a while (and stop communicating)
> as long as they eventually come
> back up.
>
> Nodes can collude and are allowed to mostly control the internet . Their
> only limit on control on the internet is
> that if Alice repeatedly sends Bob messages they must eventually allow Bob
> to receive one.
>
> The proofs are for a fully asynchronous system. There is no assumption that
> an honest node will always respond within
> a certain interval. If all the nodes go to sleep, then progress continues as
> soon as they come back up.
> In normal conditions with a small number of nodes, consensus can happen in
> less than a second.
>
> I am not aware of any third-party reviews of the whitepaper.
>
> The concepts are very similar to other voting-based BFT algorithms except
> the voting is "virtual".
> If the security of those systems (like PBFT or Tendermint...) has been
> vetted by the schemes you
> mention then perhaps they could be applied to Hashgraph as well.
>
> Hope this answers you questions.
>
> Regards,
> Martin
>
> -----Original message-----
> From: Christian Cachin
> Sent: Tuesday, June 27 2017, 11:43 am
> To: Martin Arrivets via hyperledger-tsc
> Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri Purini
> Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform
>
> Martin,
>
> Can you point to any independent analysis of the properties achieved by
> Swirlds consensus?  In which sense does it reach "consensus"?  Are there
> any peer-reviewed publications or other third-party endorsements available?
>
> In analogy with cryptography, where such issues have been discussed at
> large, and over many decades, the security of a system should be based
> on well-established and widely agreed-on schemes.
>
> (FYI - I'm a cryptographer and also working on consensus protocols...)
>
> Regards,
>
>                  Christian
>
>
> ---
> Christian Cachin                           email:
cca@...
> IBM Research - Zurich                           tel: +41-44-724-8989
> Säumerstrasse 4
> CH-8803 Rüschlikon, Switzerland      
http://www.zurich.ibm.com/˜cca
>
>
>
>
>
> On 26 Jun 2017 09:29:36 +0000, Martin Arrivets via hyperledger-tsc
> <
hyperledger-tsc@...> wrote:
>> Thanks,
>>
>> It is related in the sense that it uses the same consensus algorithm.
>> The algorithm is described in a public whitepaper
>> <
http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>;;  and this is what
>> we based our work from.
>>
>> I believe the patent is for a distributed database COUPLED with an
>> ordering system that uses the Hashgraph algorithm.
>>
>> Our platform is just an ordering system and is completely decoupled from
>> the application using it.
>> The ordering system and the app can run on separate machines.
>>
>> Hope this clarifies things.
>>
>> Martin
>>
>> -----Original message-----
>> From: David Huseby
>> Sent: Monday, June 26 2017, 9:06 am
>> To: Christopher Ferris; Martin Arrivets
>> Cc: Giacomo Puri Purini;
hyperledger-tsc@...
>> Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus
>> Platform
>>
>> Is this rated at all to the swirlds hashgraph? IIRC that is patent
>> encumbered.
>>
>>
http://www.swirlds.com/ip/ <http://www.swirlds.com/ip/>;;
>>
>> Dave
>>
>> On Sun, Jun 25, 2017 at 2:00 PM Christopher Ferris via hyperledger-tsc
>> <
hyperledger-tsc@...
>> <mailto:
hyperledger-tsc@...> > wrote:
>> Thanks for the proposal, and apologies for the delay in responding due to
>> travel. We'll add to this week's TSC agenda.
>>
>> Chris
>>
>> On Jun 19, 2017, at 7:49 AM, Martin Arrivets via hyperledger-tsc
>> <
hyperledger-tsc@...
>> <mailto:
hyperledger-tsc@...> > wrote:
>>
>> Dear all,
>>
>>
>> We would like to submit a HIP for a pluggable consensus platform which
>>
>> could integrate with Fabric and Burrow.
>>
>>
>> Our platform uses the Hashgraph consensus algorithm which has interesting
>> properties:
>>
>> - BFT tolerating up to 1/3 of faulty nodes
>>
>> - Very little communication overhead beyond the transactions themselves
>>
>> - Fully asynchronous with no concept of leaders
>>
>> - Difficult for attackers to manipulate the place of transactions in the
>> consensus order.
>>
>>
>> Fabric and Burrow are designed for modularity and the interfaces
>> corresponding to
>>
>> consensus engines are logically compatible with the interface exposed by
>> our platform.
>>
>>
>> The proposal is at
>>
>>
>>
https://docs.google.com/document/d/1wyYVNPDyJKHhdbznWWC1GrWHxFat7qBcB4laa44_Uis/edit?usp=sharing
>>
>>
>> The existing code is at
https://github.com/babbleio/babble
>>
>>
>> We look forward to hearing your feedback and working with the community!
>>
>>
>>
>> Best regards,
>>
>>
>> Martin Arrivets,
martin@...<mailto:martin@...>
>>
>> Giacomo Puri Purini,
giacomo@...<mailto:giacomo@...>
>>
>
>
>
> _______________________________________________
> hyperledger-tsc mailing list
>
hyperledger-tsc@...
>
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
>
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



Christian Cachin <cca@...>
 

Martin,

I've understood that there exists a white paper, yes.

But perhaps you should be aware that mathematically, in a "fully asynchronous
system" as you describe below, with < 1/3 faulty nodes (that crash or
act maliciously), or even with just one node that may crash, the "consensus
problem" cannot be solved with a deterministic protocol.

This is a famous result in distributed systems:
"Impossibility of Distributed Consensus with One Faulty Process" usually
just called "FLP impossibility".

See more:
https://en.wikipedia.org/wiki/Consensus_(computer_science)
https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
or a textbook I co-authored - www.distributedprogramming.net - although the
FLP result is not explained in there.

What you describe seems equivalent to this well-understood consensus problem.

In contrast to hashgraph, PBFT has been peer-reviewed and widely understood
to achieve consensus in the appropriate model (eventual synchrony, not
asynchrony).

Regards,

Christian

On 27 Jun 2017 12:03:06 +0000, Martin Arrivets <martin@...> wrote:
Hi Christian,

The system achieves consensus in the sense that a participant will
eventually know the exact location of a transaction in history and have
a mathematical guarantee of finality (that this is the consensus order).
The knowledge is not probabilistic but a mathematical guarantee.

The proofs in the whitepaper
<http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf> make the
standard assumptions:

More than 2/3 of the computers are "honest", which means they follow the
algorithm correctly and are available. Although an honest computer may
go down for a while (and stop communicating) as long as they eventually
come back up.

Nodes can collude and are allowed to mostly control the internet . Their
only limit on control on the internet is that if Alice repeatedly sends
Bob messages they must eventually allow Bob to receive one.

The proofs are for a fully asynchronous system. There is no assumption
that an honest node will always respond within a certain interval. If
all the nodes go to sleep, then progress continues as soon as they come
back up. In normal conditions with a small number of nodes, consensus
can happen in less than a second.

I am not aware of any third-party reviews of the whitepaper. 

The concepts are very similar to other voting-based BFT algorithms
except the voting is "virtual". If the security of those systems (like
PBFT or Tendermint...) has been vetted by the schemes you mention then
perhaps they could be applied to Hashgraph as well.

Hope this answers you questions.

Regards,
Martin
-----Original message-----
From: Christian Cachin
Sent: Tuesday, June 27 2017, 11:43 am
To: Martin Arrivets via hyperledger-tsc
Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri
Purini Subject: Re: [Hyperledger Project TSC] Project Proposal:
Consensus Platform


Martin,

Can you point to any independent analysis of the properties achieved by
Swirlds consensus? In which sense does it reach "consensus"? Are there
any peer-reviewed publications or other third-party endorsements
available?

In analogy with cryptography, where such issues have been discussed at
large, and over many decades, the security of a system should be based
on well-established and widely agreed-on schemes.

(FYI - I'm a cryptographer and also working on consensus protocols...)

Regards,

Christian


---
Christian Cachin email: cca@...
<mailto:cca@...> IBM Research -
Zurich tel: +41-44-724-8989 Säumerstrasse 4
CH-8803 Rüschlikon, Switzerland http://www.zurich.ibm.com/˜cca
<http://www.zurich.ibm.com/˜cca>



Martin Arrivets <martin@...>
 

Thanks for the links,

Indeed the problem cannot be solved with a deterministic protocol

But there are ways to circumvent the FLP theorem by sacrificing determinism
cf Rabin, M.O. (1983) ‘Randomized Byzantine generals’ for example.

It is possible for a nondeterministic system to achieve consensus with probability
one.

That is what the Hashgraph does and that is what I meant when I wrote that participants 
will "eventually" (with probability one) know the exact location of a transaction in history.

The Hasgraph algorithm introduces periodic 'coin-rounds' where witnesses vote randomly. This
defends against attackers that control the internet and want to partition the network.

Martin

-----Original message-----
From: Christian Cachin
Sent: Tuesday, June 27 2017, 6:09 pm
To: Martin Arrivets
Cc: Martin Arrivets via hyperledger-tsc; David Huseby; Christopher Ferris; Giacomo Puri Purini
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Martin,

I've understood that there exists a white paper, yes.

But perhaps you should be aware that mathematically, in a "fully asynchronous
system" as you describe below, with < 1/3 faulty nodes (that crash or
act maliciously), or even with just one node that may crash, the "consensus
problem" cannot be solved with a deterministic protocol.

This is a famous result in distributed systems:
"Impossibility of Distributed Consensus with One Faulty Process" usually
just called "FLP impossibility".

See more:
https://en.wikipedia.org/wiki/Consensus_(computer_science)
https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
or a textbook I co-authored - www.distributedprogramming.net - although the
FLP result is not explained in there.

What you describe seems equivalent to this well-understood consensus problem.

In contrast to hashgraph, PBFT has been peer-reviewed and widely understood
to achieve consensus in the appropriate model (eventual synchrony, not
asynchrony).

Regards,

Christian



On 27 Jun 2017 12:03:06 +0000, Martin Arrivets <martin@...> wrote:
> Hi Christian,
>
> The system achieves consensus in the sense that a participant will
> eventually know the exact location of a transaction in history and have
> a mathematical guarantee of finality (that this is the consensus order).
> The knowledge is not probabilistic but a mathematical guarantee.
>
> The proofs in the whitepaper
> <http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>; make the
> standard assumptions:
>
> More than 2/3 of the computers are "honest", which means they follow the
> algorithm correctly and are available. Although an honest computer may
> go down for a while (and stop communicating) as long as they eventually
> come back up.
>
> Nodes can collude and are allowed to mostly control the internet . Their
> only limit on control on the internet is that if Alice repeatedly sends
> Bob messages they must eventually allow Bob to receive one.
>
> The proofs are for a fully asynchronous system. There is no assumption
> that an honest node will always respond within a certain interval. If
> all the nodes go to sleep, then progress continues as soon as they come
> back up. In normal conditions with a small number of nodes, consensus
> can happen in less than a second.
>
> I am not aware of any third-party reviews of the whitepaper. 
>
> The concepts are very similar to other voting-based BFT algorithms
> except the voting is "virtual". If the security of those systems (like
> PBFT or Tendermint...) has been vetted by the schemes you mention then
> perhaps they could be applied to Hashgraph as well.
>
> Hope this answers you questions.
>
> Regards,
> Martin
> -----Original message-----
> From: Christian Cachin
> Sent: Tuesday, June 27 2017, 11:43 am
> To: Martin Arrivets via hyperledger-tsc
> Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri
> Purini Subject: Re: [Hyperledger Project TSC] Project Proposal:
> Consensus Platform
>
>
> Martin,
>
> Can you point to any independent analysis of the properties achieved by
> Swirlds consensus? In which sense does it reach "consensus"? Are there
> any peer-reviewed publications or other third-party endorsements
> available?
>
> In analogy with cryptography, where such issues have been discussed at
> large, and over many decades, the security of a system should be based
> on well-established and widely agreed-on schemes.
>
> (FYI - I'm a cryptographer and also working on consensus protocols...)
>
> Regards,
>
> Christian
>
>
> ---
> Christian Cachin email: cca@...
> <mailto:cca@...> IBM Research -
> Zurich tel: +41-44-724-8989 Säumerstrasse 4
> CH-8803 Rüschlikon, Switzerland http://www.zurich.ibm.com/˜cca
> <http://www.zurich.ibm.com/˜cca>;
>
>
>


Ray Chen
 

Martin Arrivets wrote:

Tendermint already has this feature actually. It is a permissioned blockchain where validators can
be added or removed on the go. It uses the same technique more or less.
FYI, BFT-SMaRt also has this feature (reconfig on-the-fly), although
it's not designed for blockchain originally.

AFAIK IBM is trying to integrate the BFT-SMaRt lib into Fabric's
ordering service.

Ray


Ray Chen
 

Martin Arrivets wrote:

Also what do you mean by consensus suitable for Hyperledger Fabric? From what I understand, Fabric 
was designed to be consensus agnostic. Some organisations will be happy to use a single server as the 
ordering system. Others might need something that scales massively in which case Algorand would be a good fit. 
Others yet might require a system that is Byzantine Fault Tolerant and achieves fairness in a permissioned network. 
This is the whole idea behind Hyperldedger. The more alternatives to chose from, the better.
Just want to point out that Christian and Marko are two of the main
designers of the Fabric v1 architecture AFAIK. So maybe what you
pointed out here is what they are already aware of ;-)

Ray


Hart Montgomery <hmontgomery@...>
 

Hi Martin,

 

Is there a reason this hasn’t been submitted to a conference for peer review?  I’d highly recommend doing so—you’ll have a lot more credibility with regards to people believing the protocol if you can get it published in some conference proceedings.  If you need help, I bet there are people on this list who would be happy to point you in the right direction.

 

As it is, I’d be wary of accepting any new crypto or consensus into Hyperledger that hasn’t been published in a reputable conference or heavily reviewed and documented by outsiders.  It sets the precedent that the TSC or other members of the community would have to be academic-style crypto reviewers in order to properly assess new contributions.  While some of us may be, it puts an impossible burden on those that are not, and the appropriate place for new research to be evaluated (which new crypto or consensus is) is an academic conference anyways.  Additionally, to be truly safe, lots of time and review is needed for protocols that will be critical to systems.  For instance, the SHA-3 competition and review process took five years.  While we don’t need that much time for new consensus algorithms, I think this is still an area where it is much better to be safe than sorry.

 

Thanks for your time, and have a great day.

 

Hart

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Martin Arrivets via hyperledger-tsc
Sent: Tuesday, June 27, 2017 9:55 AM
To: Christian Cachin <cca@...>
Cc: Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...>; Giacomo Puri Purini <giacomo@...>
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

Thanks for the links,

 

Indeed the problem cannot be solved with a deterministic protocol

 

But there are ways to circumvent the FLP theorem by sacrificing determinism

cf Rabin, M.O. (1983) ‘Randomized Byzantine generals’ for example.

 

It is possible for a nondeterministic system to achieve consensus with probability

one.

 

That is what the Hashgraph does and that is what I meant when I wrote that participants 

will "eventually" (with probability one) know the exact location of a transaction in history.

 

The Hasgraph algorithm introduces periodic 'coin-rounds' where witnesses vote randomly. This

defends against attackers that control the internet and want to partition the network.

 

Martin

-----Original message-----
From: Christian Cachin
Sent: Tuesday, June 27 2017, 6:09 pm
To: Martin Arrivets
Cc: Martin Arrivets via hyperledger-tsc; David Huseby; Christopher Ferris; Giacomo Puri Purini
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Martin,

I've understood that there exists a white paper, yes.

But perhaps you should be aware that mathematically, in a "fully asynchronous
system" as you describe below, with < 1/3 faulty nodes (that crash or
act maliciously), or even with just one node that may crash, the "consensus
problem" cannot be solved with a deterministic protocol.

This is a famous result in distributed systems:
"Impossibility of Distributed Consensus with One Faulty Process" usually
just called "FLP impossibility".

See more:
  https://en.wikipedia.org/wiki/Consensus_(computer_science)
  https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
or a textbook I co-authored - www.distributedprogramming.net - although the
FLP result is not explained in there.

What you describe seems equivalent to this well-understood consensus problem.

In contrast to hashgraph, PBFT has been peer-reviewed and widely understood
to achieve consensus in the appropriate model (eventual synchrony, not
asynchrony).

Regards,

      Christian



On 27 Jun 2017 12:03:06 +0000, Martin Arrivets <martin@...> wrote:
> Hi Christian,
>
> The system achieves consensus in the sense that a participant will
> eventually know the exact location of a transaction in history and have
> a mathematical guarantee of finality (that this is the consensus order).
> The knowledge is not probabilistic but a mathematical guarantee.
>
> The proofs in the whitepaper
> <http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>; make the
> standard assumptions:
>
> More than 2/3 of the computers are "honest", which means they follow the
> algorithm correctly and are available. Although an honest computer may
> go down for a while (and stop communicating) as long as they eventually
> come back up.
>
> Nodes can collude and are allowed to mostly control the internet . Their
> only limit on control on the internet is that if Alice repeatedly sends
> Bob messages they must eventually allow Bob to receive one.
>
> The proofs are for a fully asynchronous system. There is no assumption
> that an honest node will always respond within a certain interval. If
> all the nodes go to sleep, then progress continues as soon as they come
> back up. In normal conditions with a small number of nodes, consensus
> can happen in less than a second.
>
> I am not aware of any third-party reviews of the whitepaper. 
>
> The concepts are very similar to other voting-based BFT algorithms
> except the voting is "virtual". If the security of those systems (like
> PBFT or Tendermint...) has been vetted by the schemes you mention then
> perhaps they could be applied to Hashgraph as well.
>
> Hope this answers you questions.
>
> Regards,
> Martin
> -----Original message-----
> From: Christian Cachin
> Sent: Tuesday, June 27 2017, 11:43 am
> To: Martin Arrivets via hyperledger-tsc
> Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri
> Purini Subject: Re: [Hyperledger Project TSC] Project Proposal:
> Consensus Platform
>
>
> Martin,
>
> Can you point to any independent analysis of the properties achieved by
> Swirlds consensus?  In which sense does it reach "consensus"?  Are there
> any peer-reviewed publications or other third-party endorsements
> available?
>
> In analogy with cryptography, where such issues have been discussed at
> large, and over many decades, the security of a system should be based
> on well-established and widely agreed-on schemes.
>
> (FYI - I'm a cryptographer and also working on consensus protocols...)
>
> Regards,
>
>     Christian
>
>
> ---
> Christian Cachin                           email: cca@...
> <mailto:cca@...> IBM Research -
> Zurich                           tel: +41-44-724-8989 Säumerstrasse 4
> CH-8803 Rüschlikon, Switzerland       http://www.zurich.ibm.com/˜cca
> <http://www.zurich.ibm.com/˜cca>;
>
>
>


Ray Chen
 

Hart Montgomery wrote:

Is there a reason this hasn’t been submitted to a conference for peer review? I’d highly recommend doing so—you’ll have a lot more credibility with regards to people believing the protocol if you can get it published in some conference proceedings. If you need help, I bet there are people on this list who would be happy to point you in the right direction.
Babble is one of the implementations based on the original Hashgraph
paper, written in Golang, and licensed under Apache License v2. That's
what Martin try to propose here.

Babble has nothing to do with whether the original paper has been
submitted for peer review or not.

Ray