Re: [Din] Hyperledger evaluation on a mesh network

[Jon Crowcroft <[e-mail]>]

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 <
[e-mail]> wrote:

> 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, <[e-mail]> 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.
>>
>> 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
>>   [e-mail]
>>
>>
>>
>> On Wed, Apr 4, 2018, at 1:04 AM, Jon Crowcroft wrote:
>>
>> or a much simpler approach:
>> https://hal.inria.fr/inria-00466747/document
>>
>> On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback <[e-mail]>
>> 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
>>   [e-mail]
>>
>>
>>
>> On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote:
>>
>> 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
>> *_______________________________________________*
>> Din mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/din
>>
>>
>>
>> _______________________________________________
>> Din mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/din
>>
>>
>> _______________________________________________
>> Din mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/din
>>
>