Rise of the FOAM GeoPickle TestNet

Simulating zone anchors for dynamic Proof of Location

At FOAM, we’re working on the time synchronization protocol for Dynamic Proof of location. It is important to keep as much of this effort agnostic to specific radio technologies. While we see great promise in for example LoRa, the time synchronization and blockchain architecture we are developing isn’t tied to any specifics of that layer.

dPoL can be summarized as follows:

Consumer radio hardware can run a byzantine fault tolerant time synchronization protocol in a mesh configuration over the air with cryptographic signatures The data produced can be transmitted to and validated on local blockchains and produce cryptographically proven location-data (Presence-claims) Incentivization for producing and validating Presence-claims can be governed using smart-contracts on Ethereum

Importantly, we can build the dPoL layers 2 and 3 using a simulated setup alone. The statistics we can infer from the experiments will aid us in understanding the difference in the data generated from a virtual Layer 1 and a real one implemented on radios. This difference will be driving the validator logic in Layer 2.

With this in mind, we have designed and assembled a virtual layer 1, which is called the GeoPickle. The main component of the Geopickle is a rack of 40 Raspberry PIs. We use PIs because it allows us to share as much as possible of the architecture we’re building for testing, and the prototype boards we are using for the radios.

Each PI corresponds to a Zone anchor. The PIs are connected to a dedicated switch with which we can configure different network configurations easily. This switch acts as a virtual transport layer for the PIs. We also separate the PIs into Zones using the switch, since we emulate the transport layer of the anchors using broadcast packets alone. Moreover, we can introduce delays and packet drops, which lets us simulate different spatial configurations of the Zone anchors.

One of the more time consuming part of dealing with Raspberry Pis is their dependency on SD cards; that is, changing settings via SSH or by swapping or flashing the card itself. We’ve gone to lengths set up an easy way of maintaining the PIs in an SD card free way by utilizing network booting (PXE).This way we can not only experiment with different binaries, but wholly differently compiled linux kernels or even bare bone PI firmware for the ARM chip, for example.

We have other peripherals and servers connected to the network. On the server we can do centralized logging, centralized timing measurements and running things like a plasma operator and a counterfactual verifier. As of recent there has been amazing progress in the Ethereum Layer 2 scaling space and we are excited about utilizing these efforts.

Currently we have our time-synchronization protocol implemented in Go, partially because the ease of integration with Tendermint. We are also aiming to produce separate binaries that use Plasma and generalized state channels. In addition to using a blockchain for the aggregated logs, the logs are useful for running statistics. Therefore, the geopickle is like a laboratory of sorts.

By running these zones over the virtual transport layer, we can start producing presence claims. It is important that we’re able to benchmark this part of the stack independent of the radios themselves.

Some example scenarios:

We can run 10 zones simultaneously with different synchronization parameters, reporting to the same blockchain.

We can partially overlap zones by controlling what Anchors can hear each other.

We can introduce errors, packet drops and packet delays. It will be interesting to see to what extent we’ll be able to infer these disruptions from pure inspection of the logs. This will form the basis for our validator logic.

We can benchmark our presence claims, to understand what an initial estimate for what the “presence_claims / second” rate is.

We can run the same “zone_setups” against different Layer 3s, meaning we can benchmark for example Tendermint vs Plasma using a whole suit of scenarios.

In the coming weeks and months we will continue to run the full gamut of simulations mentioned above that the GeoPickle can handle. These test results will provide important insights into how Dynamic Proof of Location will perform with radio beacons out in the real world. Our ultimate goal for the GeoPickle is to sufficiently prep this configuration so that the leap to open air mesh beacons will be as predictable and easy as flipping a switch.Once the GeoPickle test net is sufficiently mature, we’ll expose its dashboard and logs to the internet and we’re looking forward to sharing future progress and visuals with the community!