Hi guys, I’m jetlagged and exhausted from our marathon session today but I wanted to share two things quickly — more tomorrow:
Our new Chief Scientist, Ram, presented these great slides about mesh networks which you might all find interesting since I think everyone here know more about blockchain than about mesh networks (the opposite of me) — nevertheless there was plenty I learned from this!
The idea of creating a minimum viable blockchain protocol that focuses on validating and incentivizing behavior around relay and/or gateway nodes — which we’ve been discussing here — was really appealing to everyone.
The thing I found most fascinating was that the exception to the Gupta-Kumar idea on slide 10 - the idea that mesh networks (and all wireless networks, presumably) cannot scale infinitely - is the fact on slide 11, which is that “The Gupta-Kumar result does not hold if growth is due to pure relay nodes”… sounds like we gotta really incentivize the use of pure relay (and gateway) nodes!!!
(Also is the author of the whitepaper referenced in slide 11 your new Chief Scientist? Looks like it’s the same name. Nice work!!)
So I had some time on the plane to skim these two presentations. Here’s my 2 cents for what it’s worth:
Ammbr - My first attempt to read it ended after all the legal-ish IPO/ICO language, but after wading in and at least scanning the whole thing it sounds like a great project if you want to raise a lot of money and never deliver anything.
Their understanding of blockchains is shallow and they fail to mention layer 2 protocols (eg. lightning). Their idea of creating their own mining system based on some sort of hardware module in their routers is pure fantasy. I didn’t find much value in what they wrote. The only useful thing I got out of it was that we should study what the openWRT community is doing with mesh routing protocols in bmx6 and 7.
MeshRight - This project is a bit more interesting. The appear to have actually implemented some of their idea. I originally didn’t read past the “Mesh ID” portion where they claim it’s hard to create a unique ID without accessing the internet and then seemed to rediscover the 80’s idea of public key encryption and attributed it to Ethereum.
But unlike Ammbr, they are aware of Lightning and the Ethereum equivalent Raiden. They seem to be onto something with their idea of using a side chain that is settled out onto the global blockchain periodically by their superpeer (p38). I don’t have enough understanding of Ethereum to say if it would work but it might be worth some further reading.
The part about “Temporary Storage for Mobility” (p43) is also thought provoking. A system that can accommodate a store-and-forward model I think would be valuable to allow for a “sneakernet” mode of moving information. Layer 2 protocols like Lightning are already considered a caching system for the main blockchain so physically transporting cached data is not crazy.
Agree with you 100% on Ammbr, they seem to have pushed all the hard problems into the hardware. A purely hardware based approach like this does not seem right, most people in the world have not heard of a blockchain, and are definitely not ready to shell out for a fancy custom router to run one. The “proof-of-elapsed-time” consensus mechanism depends on Intel SGX to set timeouts for each device, and I don’t see how it protects against attacks based on varying network latency.
In terms of presentation, it took them until page 16 to get to the technical details, sandwiched between marketing info and patent process description. A red flag for me. They also list several African countries and Spain’s community meshnet Guifi as partners, which is strange. I wonder what that relationship is.
RightMesh looks more interesting. Haha, my eye also caught on that line about how cryptocurrencies pioneered secure key generation, was inclined to stop reading. I tried again on a plane yesterday but realized I hadn’t downloaded their technical whitepaper, only the overview one. Will take a look soon.
Oh and by the way, hi everyone, I’m the blockchain dev who’s been talking through ideas with Daniela. I mainly work on Zcash related things, but really want to see incentivized mesh networks succeed. The problem, as I see it, goes beyond just building meshnets, although that’s a start to support devices communicating p2p locally. The broader question is how do we build networked communications infrastructure that has a more decentralized architecture and ownership structure? It’s an ambitious but important goal to shoot for, and I love the progress goTenna’s made.
@arcalinea (welcome!) @rmyers There’s no way proprietary hardware or protocols are going to scale even if you put an incentivized blockchain protocol atop it.
Anyway, that’s my sideways way of saying that Ammbr is dead-in-the-water, because of proprietary hardware (also have they ever heard of a minimum viable product? wow, that’s a s***load of stuff in one box, as a hardware developer it’s hard to imagine they can do everything well). On MeshRight, same thing because a cursory glance at the paper looks like it all depends on their proprietary protocol. Am I reading these both right?
Part of what is intriguing to me about goTenna’s opportunity - and the approach @danielagotenna seems to be considering or aiming for - is to build a nonproprietary incentive layer that definitionally does NOT require goTenna’s hardware or even mesh protocol.
Haven’t read the RightMesh (MeshRight?) technical paper yet, but agree on the principle of building a non-proprietary incentive layer. The goal of building these kinds of systems is for people to use them, build on them, make them interoperable, and feel free to fork or remix them if necessary. Most cryptocurrencies are completely open source, and have forked, yet live on, growing through a fascinating Darwinian process of software evolution.
A few things I liked in the RightMesh overview paper, from my notes:
Building for developers, as primary target.
App-agnostic meshing protocol layer (for phones)
Thinking of excess capacity in existing devices as frontier for sharing economy (although I’d hope that what emerges does not require a platform middleman)
I agree with @arcalinea that it’s an interesting paper. From my first reading, I’d say the Althea approach is the most promising I’ve read so far. I especially liked the idea separating gateway nodes from exit nodes.
One niggle is how to establish the anchor transaction (blockchain contract) between two nodes when both nodes are ‘off-grid’ and without a connection to the internet and blockchain.
This is also a stumbling block in the lightning network based approaches I’ve mentioned before. This problem doesn’t apply to payment channels involving gateway nodes because it’s assumed they are connected to the blockchain directly via an internet connection.
How do you broadcast to the blockchain the transactions that establishes the payment channels between you and all of the nodes between you and the gateway? Ultimately you need to rely on some amount of free traffic transport, but then you will also need a way to avoid free traffic SPAM attacks.
Yes! And because spectrum and power are a limited resource (in any mesh network whether it’s goTenna Mesh or a community wifi network, etc.), we also need to figure out how to incent fair use of these scarcities. After all, a spammy network or a network where lots of people are routing for only a few will never scale both at the communications/transport protocol layer AND socially.
Oh and here are notes from when our Chief Scientist and I discussed Althea’s whitepaper a few months ago, which he said was one of the better ones he’d seen in this area:
An open source project for last mile connectivity that allows people to set up and participate in a decentralized ISP.
It’s similar to goTenna Mesh in that it uses a mesh BUT it’s different in terms of market and capability/applications, and could be complementary.
Presents a rooftop wifi mesh as the way to do the last mile, which is of course different to goTenna Mesh.
Most important technical difference is that it’s NOT a MANET. Althea addresses a non-mobile (i.e. stationary) network (something MUCH easier to do than mobile ad hoc routing — plus mostly/often off-grid, btw), and in traffic being concentrated to the gateway nodes.
Different mesh solutions are needed. They use modified Babel, which won’t work for us (or any other mobile and/or lower-bandwidth and/or lower-power mesh network systems) as it is too chatty. Traffic congestion at the gateway nodes is an issue not present in goTenna today but will be something to consider when we build gateways beyond today’s SMS network relay feature
Their approach as a starting point for smart contracts and metering (section 3,4 of the whitepaper) are interesting
Althea proposes some reasonable ideas to a hard problem, but has some holes. For e.g., verifying route quality end to end with the required frequency can blow all your bandwidth (and probably power).
I believe starting simple is the right approach when looking at something as complicated as incentives for mesh network nodes. We also need some sort prototype user to help focus the effort.
For a reference user, I propose a person on an off-grid mesh network who wants to send a short message via a messaging app to someone on the global internet.
I propose the following reference protocol to incentivize nodes to transport data for our reference user at node ‘A’:
Node ‘A’ broadcasts request for price to forward data to a gateway
Nearby nodes with a path to gateways respond with price offers
Node ‘A’ selects node ‘B’ and creates a signed transaction to pay ‘B’ for up to ‘x’ bytes per second of data for ‘y’ minutes.
Node ‘B’ forwards the transaction to the next node in the circuit ‘C’, etc until it reaches the gateway
Node ‘B’ … ‘D’ all have negotiated for data transport to a gateway
Once a node has scheduled their available bandwidth/power budget they stop responding to requests for gateway connections
When the transaction from node ‘A’ reaches the gateway, it is broadcast to the blockchain
When the transaction from node ‘A’ is confirmed, the proof of the payment being recorded in a block is returned via nodes ‘D’ … ‘B’ to node ‘A’.
Node ‘A’ may now proceed to send and receive data by broadcasting it to ‘B’
There’s nothing exotic or specific to a particular blockchain about this reference protocol. I would assert that more elaborate workflows simply optimizes some aspect of this basic reference protocol.
My question to the community then is, what optimizations if any do you think are necessary to make this a practical protocol?
There are different axis we could optimize, which would you prioritize?
trust model
bandwidth / power usage
latency
Using the bitcoin blockchain as an example, a transaction is about 600 bytes and takes about 10 minutes to be confirmed once it reaches the blockchain. Block headers are 81 bytes for each block until the last seen block header. A merkle block allows a thin client to use the block headers to do a block depth check to verify a transaction is in a block and require less than 1000 bytes.
Bandwidth for sending and receiving data on the order of 3000 bytes would be required to setup an incentive for each node in the circuit. We can also optimize the return bandwidth by using a single set of block headers and merkle blocks for all nodes in a circuit.
If we assume radios that can transmit at 1920 bytes per second, then the transmissions would take about 6 seconds for four hop to get to the gateway, about 10 min if we waited for a single block confirmation and then another 6 seconds to get the confirmation. After the circuit is setup the latency would be about 12 seconds per round trip.
Was thinking of something similar, but more based on payment for a single message, rather than payment channel for data over time. What you’ve described seems like a design to pay up front for a connection, was thinking more along the lines of a pay-upon-delivery model, where relay nodes get paid upon receipt of delivery for a message.
If users pay up front, it takes a long time to set up a channel, and then reliability depends on the availability of those same relay nodes. This seems better for a scenario where a node needs a constant connection, but if they’re just interested in sending one message, perhaps the focus could be more on eventual delivery.
Also, feasibility of protocols seems to depend on whether the overhead of passing pricing information back and forth be reduced, if nodes are lightweight clients with already spotty connectivity.
Ethereum micro-Raiden network is live on the testnet. This looks promising… I was hoping that this would allow a transaction between two people with goTenna, even if only one of them had an internet connection. This does not appear to be the case, but its still promising for off network micro payments (with no fee’s!):
I would like to expand the thinking from my last post that outlined a simple reference implementation. In particular, iterating the various options/decision points regarding the design of an incentive system.
For example the response from @arcalinea expressed a preference for “payment for a single message, rather than payment channel for data over time”.
I wouldn’t want to commit in advance to one choice, but initially just note the various options: pay for x bytes over y minutes, pay for 1-n messages of x bytes, etc. I think there are probably 5 or 6 really important options and many minor ones. Each option will have trade offs, primarily the protocol overhead in bytes as a % of usable payload data delivered.
In a high bandwidth mesh, protocol overhead of x bytes might be a small percent of the overall channel bandwidth, but be significant for a low bandwidth radio based system. The goal should ultimately be to model scenarios that represent a goTenna or IoT mesh on one end, and a wifi mesh on the other. Perhaps also some mix.
There are also trust options: pay up-front or after delivery? require proof of delivery? granularity of proof?r
Once we have a few promising options we can model the effect these options have on bandwidth, trust, latency and reliability.
I think this kind of approach will help us narrow down the options to the most promising combination.
In particular, HTLC (hashed time lock contracts). For sending short messages, it might be possible to use the message itself as a pre-image for the smart contracts.
I don’t have much to offer. I like the promise of the lightning network, but every time I read about it the details of how it works it sounds like you need to fund it up front and you can end up with your funds locked in limbo for up to several days if the person on the other end of the payment channel doesn’t do what they are supposed to do. I must be getting this wrong because I don’t see how that could be the future but I like the idea. Certainly need to do something off chain to be scalable.
I’m also pretty sure the new chief scientist at goTenna is going to need to figure out how to up data rate and throughput to make goTenna useful for something like this. Hopefully this won’t require v3 hardware, but if it does I’m sure I’ll be buying that too.
