Subject: [Din] Hyperledger evaluation on a mesh network

From: Arjuna Sathiaseelan <[email-masked]>
Date: Tue, 3 Apr 2018 12:44:35 +0100

we recently did an evaluation of the hyperledger fabric in a community
wireless network within the famous guifi.net..

will be of interest https://arxiv.org/pdf/1804.00561.pdf

Regards

-- 

Arjuna Sathiaseelan
University of Cambridge | Ammbr Research Labs
Personal: http://www.cl.cam.ac.uk/~as2330/
N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d

---

From: Jehan Tremback <[email-masked]>
Date: Tue, 03 Apr 2018 19:09:21 -0700

Why run full nodes on your networking hardware? One could achieve the
same security characteristics (or better) by simply using light clients
of a public blockchain on the networking hardware.
--
  Jehan Tremback
  [email-masked]

On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote:
> wireless network within the famous guifi.net..> 
> _________________________________________________
> Din mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/din

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 4 Apr 2018 09:04:30 +0100

or a much simpler approach:
https://hal.inria.fr/inria-00466747/document

On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback <[email-masked]> wrote:

> Why run full nodes on your networking hardware? One could achieve the same
> security characteristics (or better) by simply using light clients of a
> public blockchain on the networking hardware.
>
> --
>   Jehan Tremback
>   [email-masked]
>
>
>
> *_______________________________________________*
> Din mailing list
> [email-masked]
> _______________________________________________
> Din mailing list
> [email-masked]

---

From: Jehan Tremback <[email-masked]>
Date: Wed, 04 Apr 2018 08:58:22 -0700

Even simpler, by adding a monetary price metric to a distance vector
protocol (we are currently testing this in production). Skimming your
paper, it looks like you are thinking along the same lines.
https://altheamesh.com/documents/whitepaper.pdf

Back to the Arjuna's post, the use of a blockchain implies that there is
some value to having an immutable transaction ordering mechanism. In our
protocol we conceptualize these ordered transactions as "payments",
while in Arjuna's paper the actual use of this transaction ordering is
left unspecified.
Running the  transaction ordering consensus protocol on the network
nodes themselves seems like a bad idea. These nodes have more of an
incentive to mess with the ordering than some faraway validators who
know nothing about the specific application and are only incentivized to
order transactions correctly. Also, the fact that there are always going
to be many fewer validators available on a local network means that the
consensus pool is smaller and more vulnerable to manipulation.
I say, leave the transaction ordering to a global network of validators
who specialize in transaction ordering and leave the networking to
network hardware equipped with light clients. With Althea, we are able
to run everything on commodity routers on OpenWRT.
--
  Jehan Tremback
  [email-masked]

On Wed, Apr 4, 2018, at 1:04 AM, Jon Crowcroft wrote:
> On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback
> <[email-masked]> wrote:>> __
>> same security characteristics (or better) by simply using light
>> clients of a public blockchain on the networking hardware.>> 
>> --
>>   Jehan Tremback
>>   [email-masked]
>> 
>> 
>> 
>>> we recently did an evaluation of the hyperledger fabric in a
>>> community wireless network within the famous guifi.net..>>>

---

From: Arjuna Sathiaseelan <[email-masked]>
Date: Wed, 4 Apr 2018 21:31:31 +0100

Jehan,

Good points. The aim of the paper was to benchmark HL and understand the
painpoints and hardware requirements.

So this is the way I see things from Ammbr's point of view: 1. We are
developing hardware (the Ammbr routers) that would function as part of the
blockchain e.g. act as orderers & any node/hardware can still be a light
node within the network - they just cant participate in the consensus. 2.
Our PoET/PoV consensus + the underlying DAO ensures
fairness/decentralisation + does not allow nodes to mess around - any bad
behaviour will involve revoking the certificates by the certification
authority..

Regards

On Wed, 4 Apr 2018, 16:58 Jehan Tremback, <[email-masked]> wrote:

> protocol we conceptualize these ordered transactions as "payments", while
> in Arjuna's paper the actual use of this transaction ordering is left
> unspecified.
>
> Running the transaction ordering consensus protocol on the network nodes
> themselves seems like a bad idea. These nodes have more of an incentive to
> mess with the ordering than some faraway validators who know nothing about
> the specific application and are only incentivized to order transactions
> correctly. Also, the fact that there are always going to be many fewer
> validators available on a local network means that the consensus pool is
> smaller and more vulnerable to manipulation.
>
> who specialize in transaction ordering and leave the networking to network
> hardware equipped with light clients. With Althea, we are able to run
> everything on commodity routers on OpenWRT.
>
> --
>   Jehan Tremback
>   [email-masked]
>
>
>

---

From: Leandro Navarro <[email-masked]>
Date: Thu, 5 Apr 2018 01:08:49 +0200

The paper that Arjuna shared looks to the general topic of this WG “Decentralized Internet Infrastructure”, with an evaluation of the Hyperledger framework when running on a edge scenario of small Debian servers spread in a mesh network (not in the routers), instead of a typical data center env.

> On 4 Apr 2018, at 17:58, Jehan Tremback <[email-masked]> wrote:
> 
> Even simpler, by adding a monetary price metric to a distance vector protocol (we are currently testing this in production). Skimming your paper, it looks like you are thinking along the same lines.

Simpler but not too simple regarding pricing. Jon’s paper looked in 2010 at pricing related to congestion, fairness, incentives for cooperation, sending rates in flows and overall stability in a local mobile ad-hoc net. Still relevant work 8 years later.

> Back to the Arjuna's post, the use of a blockchain implies that there is some value to having an immutable transaction ordering mechanism. In our protocol we conceptualize these ordered transactions as "payments", while in Arjuna's paper the actual use of this transaction ordering is left unspecified. 

… not an objetive of that research paper (evaluation of Hyperledger) != whitepaper.

> Running the transaction ordering consensus protocol on the network nodes themselves seems like a bad idea.

> These nodes have more of an incentive to mess with the ordering than some faraway validators who know nothing about the specific application and are only incentivized to order transactions correctly. Also, the fact that there are always going to be many fewer validators available on a local network means that the consensus pool is smaller and more vulnerable to manipulation.

Hyperledger has strong limitations when running in small servers, let’s forget about routers, but just relying on remote servers for local transactions can have drawbacks too.

> I say, leave the transaction ordering to a global network of validators who specialize in transaction ordering and leave the networking to network hardware equipped with light clients. With Althea, we are able to run everything on commodity routers on OpenWRT

Thanks for your comments, Leandro.

> .
> 
> --
>   Jehan Tremback
>   [email-masked] <mailto:[email-masked]>
> 
> 
> 
>> https://hal.inria.fr/inria-00466747/document <https://hal.inria.fr/inria-00466747/document>
>> 
>> On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Why run full nodes on your networking hardware? One could achieve the same security characteristics (or better) by simply using light clients of a public blockchain on the networking hardware. 
>> 
>> --
>>   Jehan Tremback
>>   [email-masked] <mailto:[email-masked]>
>> 
>> 
>> 
>>> we recently did an evaluation of the hyperledger fabric in a community wireless network within the famous guifi.net <http://guifi.net/>..
>>> 
>>> will be of interest https://arxiv.org/pdf/1804.00561.pdf <https://arxiv.org/pdf/1804.00561.pdf>
>>> 
>>> Regards
>>> 
>>> -- 
>>> 
>>> Arjuna Sathiaseelan
>>> Personal: http://www.cl.cam.ac.uk/~as2330/ <http://www.cl.cam.ac.uk/~as2330/>
>>> N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d <http://www.cl.cam.ac.uk/~as2330/n4d>
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.irtf.org/mailman/listinfo/din <https://www.irtf.org/mailman/listinfo/din>
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.irtf.org/mailman/listinfo/din <https://www.irtf.org/mailman/listinfo/din>
>> 
> 

--
Leandro Navarro
http://people.ac.upc.edu/leandro	 http://dsg.ac.upc.edu

---

From: Jehan Tremback <[email-masked]>
Date: Wed, 04 Apr 2018 16:43:43 -0700

Thanks Leandro. Our protocol does indeed leave pricing considerations
un-analyzed. This is something we will unfortunately not be testing
in a simulation like Jon, we'll have to see how things evolve in the
real world. Some of the insights gained from that paper may prove to
be useful.
The paper that Arjuna shared does indeed provide interesting and
rigorous experimental results on running a very small consensus
network in some specific network conditions. My criticisms were on the
"why" of doing that and do not detract from the quality of the paper.
Thanks for sharing.
--
  Jehan Tremback
  [email-masked]

On Wed, Apr 4, 2018, at 4:08 PM, Leandro Navarro wrote:
> The paper that Arjuna shared looks to the general topic of this WG
> “Decentralized Internet Infrastructure”, with an evaluation of the
> Hyperledger framework when running on a edge scenario of small Debian
> servers spread in a mesh network (not in the routers), instead of a
> typical data center env.> 
> 
>> On 4 Apr 2018, at 17:58, Jehan Tremback <[email-masked]> wrote:>> 
>> paper, it looks like you are thinking along the same lines.> 
> Simpler but not too simple regarding pricing. Jon’s paper looked in
> 2010 at pricing related to congestion, fairness, incentives for
> cooperation, sending rates in flows and overall stability in a local
> mobile ad-hoc net. Still relevant work 8 years later.> 
>> Back to the Arjuna's post, the use of a blockchain implies that there
>> is some value to having an immutable transaction ordering mechanism.
>> In our protocol we conceptualize these ordered transactions as
>> "payments", while in Arjuna's paper the actual use of this
>> transaction ordering is left unspecified.> 
> … not an objetive of that research paper (evaluation of Hyperledger)
> != whitepaper.> 
>> nodes themselves seems like a bad idea.>> These nodes have more of an incentive to mess with the ordering than
>> some faraway validators who know nothing about the specific
>> application and are only incentivized to order transactions
>> correctly. Also, the fact that there are always going to be many
>> fewer validators available on a local network means that the
>> consensus pool is smaller and more vulnerable to manipulation.> 
> Hyperledger has strong limitations when running in small servers,
> let’s forget about routers, but just relying on remote servers for
> local transactions can have drawbacks too.> 
>> I say, leave the transaction ordering to a global network of
>> validators who specialize in transaction ordering and leave the
>> networking to network hardware equipped with light clients. With
>> Althea, we are able to run everything on commodity routers on OpenWRT> 
>>> <[email-masked]> wrote:>>>> __
>>>> Why run full nodes on your networking hardware? One could achieve
>>>> the same security characteristics (or better) by simply using light
>>>> clients of a public blockchain on the networking hardware.>>>> 
>>>> --
>>>>   Jehan Tremback
>>>>   [email-masked]
>>>> 
>>>> 
>>>> 
>>>>> community wireless network within the famous guifi.net[1]..>>>>> 

Links:

  1. http://guifi.net/

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 5 Apr 2018 08:39:43 +0100

right  - it is worth knowing, for sure, that such a full-on system can work
- lighter alternatives are nice, but compute/storage resources in community
nets' nodes can be significant for little captial outlay too!

On Wed, Apr 4, 2018 at 9:31 PM, Arjuna Sathiaseelan <
[email-masked]> wrote:

>> same security characteristics (or better) by simply using light clients of
>> a public blockchain on the networking hardware.
>>
>> --
>>   Jehan Tremback
>>   [email-masked]
>>
>>
>>