If I understand your question about “Network Integrity” correctly there are two networks we can talk about.
The integrity of the mesh network itself concerns how we motivate people to run mesh nodes and validate that they are properly relaying data to other nodes.
The other network is the financial blockchain based network where we want to validate peers properly relay transaction state information and broadcast new transactions we create.
I’ll try to address the latter and use bitcoin as an example. I’m not an expert, but this is based on my general understanding of the technologies involved. I’m a bit out of my depth, but I think I know enough to give a rough sketch.
I assume a network where mesh nodes can periodically and indirectly interact with the bitcoin blockchain. The system must work if bitcoin blockchain data does not propagate in real time and updates from nodes connected to the blockchain are infrequent.
There are five basic steps that happen to transfer value and confirm transfers:
- Establish anchor transactions to join bi-directional micropayment channels (eg. Lightning network).
- Update channel balances by sending signatures to update balances between payment channel nodes (who are also mesh network nodes). This happens between nodes with no blockchain involved.
- Sync block headers ( for Simple Payment Verification ). To validate transactions based on block depth.
- Subscribe to full nodes to receive updates about blocks involving relevant payment channel anchor transactions.
- Broadcast payment channel closing or penalty transactions to the global bitcoin blockchain.
A key consideration for this system to work is how the relative time lock windows are initially setup for micro-payment channel closing transactions. If a participant only receives updates from or can broadcast to the global bitcoin blockchain once a week, then the time locks must be set at perhaps a month so they can detect invalid closing transactions and broadcast a penalty transaction before it confirms on the blockchain.
The downside of a large time-lock window is a longer delay when closing a channel. However with relatively small amounts of value locked up it should be possible to trade-off between channel timeout delays and on-grid connectivity frequency. In many cases bi-directional channels will never need to be closed except in the cases of mischief.
Data we receive about the state of the blockchain can be locally validated, but we can’t know if some information was withheld. We can locally validate proof that one of our transactions was broadcast to the network, but if our block headers and/or transaction updates only come from one source, we could miss an invalid closing transaction.
So if we now pay nodes to transmit generic packets of data, how do we validate that when we pay a peer mesh node it doesn’t just take our micro-payment and ditch the data?
If every data packet travels along a payment channel path and uses hash-lock contracts to pay each peer along the path; no one gets paid unless the final recipient reveals a secret value. This value is encrypted specifically for them in the packet they receive. The upstream node that delivered the packet only receives payment once the recipient reveals the unencrypted secret. This secret flows back until the sender receives it and everyone settles their micro-payment balances off blockchain.
I’m not sure if this is totally clear, but the idea of hash-lock-contracts is a powerful one and I think relevant to the problem of mesh-network delivery validation. Perhaps it can be used without involving bitcoin at all, or in a more simplified way.
Comments and questions welcome. I think it’s exciting to think about how this kind of thing could work.