FOAM Location Update and Demo Documentation


#1

Hello all, this post is to serve as documentation of the demo that took place during ETH New York 2019. ​​We recently demonstrated a major milestone in our Proof of Location technology by processing and validating a Presence Claim over radio.

Introduction

At FOAM, we’re building what we call Proof-of-location and are creating an architecture that can be summarized as follows:

  1. ( Rootchain ) Incentivization for producing and validating location data (Presence claims) can be governed using smart-contracts on Ethereum

  2. ( Sidechain ) The data produced can be transmitted to and validated on local blockchains and produce cryptographically proven Presence claims.

  3. ( Radio ) Consumer radio hardware run a byzantine fault-tolerant time synchronization protocol in a mesh configuration over the air with cryptographic signatures

The reasoning behind this architecture is outside the scope of this article, but suffice to say that Ethereum suffers from what’s called the scaling problem : transactions are costly and slow. Scaling solutions such as Plasma and Tendermint allow workarounds and we have therefore embarked on an architecture that fulfill the needs for FOAMs radios to operate without with fast and low cost transactions within the Zones themselves.

Previously, we have shared information about the GeoPickle test net, which allows us to perform simulations and testing of layers 1 and 2 with a virtual layer 3, in this case represented by a rack of 40 Raspberry PIs. For more on what this test set up allows for research and development see the post below: (note that layers were listed in reverse order in this article)

Additionally, this post serves as a higher level explanation of the protocol:

Demo Architecture

The demo outlined in this post demonstrates the first time we utilized a Layer 3 running over radio and thus replacing the virtual layer 1 of the GeoPickle. We consider this a major milestone for FOAM.

For demo purposes we had decided on a couple of technologies for prototyping the architecture of Proof-of-location:

  1. ( Rootchain )
    We deploy the Plasma contracts to Ethereum. These follow the PlasmaMVP implementation which is a design for an extremely simple UTXO-based Plasma chain. The basic Plasma MVP specification enables high-throughput payment transactions but does not support more complicated constructions like scripts or smart contracts. For more of how Plasma MVP functions as well as how a UTXO model works, see: https://www.learnplasma.org/en/learn/mvp.html

  2. ( Sidechain )
    We use the FourthState PlasmaMVP Tendermint integration for this layer. Simply speaking, Tendermint ensures that the order in which the radios logs get transmitted is agreed upon by all participants. In addition, we foresee that it is important to be able to store logs from the participants. Therefore we need not just a single plasma operator for the participants to reach consensus over the logs but also need them to be accessible for later inspection. A Tendermint sidechain fits the purposes for this demo to allow that. In order for us to work with the FourthState implementation, we forked their repo and added a REST server on top of their API. We anticipate that this is something that they will want to add to their project in the future and in the event this fits our needs, we’ll be happy to switch to their implementation.

  3. ( Radio )
    In this demo we used the LoRa SX1276 mbed Component Shield alongside a STM32 Nucleo-64 development board with STM32F303RE MCU as the micro-controller. We have developed a custom firmware for the transceiver boards which implements packet transmission and reception with relatively high-resolution timestamps, This allows for messages to be precisely timed for inclusion in the blockchain, enabling the necessary information for localization to be communicated to the blockchain aspects of the stack.


A ZoneAnchor prototype

Transceivers can only operate on one channel, so for this demo each Zone Anchor has four transceivers and a Raspberry Pi. Future iterations of the demo and the FOAM developer kit under development will utilize the LoRa SX1301 gateway chip, which can operate on multiple channels at once.

The Demo

The general outline of the demo is the following:

Three radios are consistently engaging in a time synchronization protocol over radio and thus have the ability to locate a user within their reach. They have formed a Zone on a Plasma sidechain and staked token to guarantee their fulfillment of the protocol.

A user enters the Zone and wants to request a Presence claim. The user transfers tokens to the Plasma sidechain and burns their token there. The radios see the request, logs the exact time it was received and validate the Presence claim. For this, they are rewarded with tokens that they can claim on the root chain. In exchange, the user has a Presence claim signed by the radios that is valid with respect to the logs posted to the sidechain.

The complete flow is described by the following diagram:

We built a simple front-end web interface which shows the status of the Plasma child chain as it pertains to the root chain, i.e. Ethereum which is where the FOAM token is staked. The front-end shows the logs from the radios coming in where they can be staked. The front-end utilizes Metamask to interact with Ethereum and the Plasma chain. What we will see in the demo is that a user wants to establish its location, it can talk to the radios (Zone), request a presence claim and see the transactions happen on the front-end.

Demo browser walkthrough

Note in the following that

  • User or “Account 1” is represented by the address 0x3a9bca...
  • ZoneAnchor or “adversary” is represented by 0x1ea6e6...

Moreover, this demo does not focus on localization, which can be derived from the time-stamped logs. The important demonstration here is that the radios commit proof of the time synchronization and that the logs that they commit are compatible with the signatures used for participations on both root and the Plasma chain that the User and the radios communicate over.

1. User registration


1a. The user deposits ETH to the Plasma contract


1b. The deposit is displayed in the Plasma contract


1c. The user now has an unspent UTXO. In place of a more advanced escrow smart contract, for this demo we are simply burning this UTXO.


1d. By signing a message the UTXO gets included on Tendermint. The burn requires signed confirmation because in the event the user tried to re-instantiate their tokens on Ethereum it would be fraudulent.


1e. The user can now request a Presence claim to be validated

2. Zone creation


2a.Simultaneously, a Zone is created


2b. Zone creation is represented through signing of an UTXO on Tendermint


2c. The Zone has been registered

3. Presence claim submission


3a. A Zone anchor can now sign a Presence claim


3b. The logs are submitted form the Radio as proof that the Presence claim is valid

4. Presence claim is valid


4a. The user can now access their Presence claim


4b. The ZoneAnchor has been rewarded an UTXO that can be transferred to the root chain. Once the Tendermint hashes containing these transactions are posted to the root chain and are verified, the user’s burnt UTXO is distributed to the Zone Anchors as payment for the presence claim.

Conclusion and outlook

We are currently wrapping up the demo so that we can host it and have a small test-net running for public inspection. At this point, we aim to put more work into both the hardware design of our next prototype as well as additional work that is warranted on the time synchronization and blockchain software. Subsequent blog posts will focus on those efforts. Once we reach our milestones for that, we will revisit this demo to see if Plasma and Tendermint remain the technologies we chose to build upon. For now, we are happy to have demonstrated the full life cycle of a Presence claim, with both the sidechain machinery, the radio protocol and the connecting of them both to Ethereum. As mentioned above, along with the recent addition of electrical engineers to the team, future iterations of the demo and the FOAM developer kit under development will utilize the LoRa SX1301 gateway chip, which can operate on multiple channels at once. The goal is for this developer kit and beta software to be available to users later this year for testing. In parallel, Foamspace will be working on a pilot project with partners at the New Lab and across the Brooklyn Navy Yard.

Demo Videos

A recording of this Demo can be Found Here:

Part 1

Part 2

The FOAM Location Update and Demo Documentation will also be the topic of the next FOAM Community Call.


#2

Thank you for the very thorough write up. Tech documentation is hard, and I think you captured the excitement of the demo and were able to provide the detail needed for those evaluating this effort.

I look forward to the next iteration; Zone Anchor’s are really key to moving FOAM to the next step of servicing a wider audience!


#3

Just got done reading this. Awesome demonstration. What is the time delta between action 1a and 4a?


#4

What is the time delta between action 1a and 4a?

Great question! Ignoring the time it took us to explain what was going on, you’d need 1 ETH block for the deposit into the sidechain, minimium of 1 ETH block for withdrawing plus a Plasma MVP exit challenge period. In practice, many presence claims can be made from one deposit into a sidechain as well as many exited with one ETH tx. The actual process of putting tokens into escrow (in that particular demo that was represented as burning) and broadcasting/collecting the presence was 3 Plasma blocks (One escrow burn, one presence claim request, and one presence claim grant). Note that this duration can be as little as 2 Plasma blocks. (one for the escrow burn and one for the radios signing the broadcast presence claim). It’s worth noting that within the Plasma sidechain a more sophisticated behavior can be encoded for the escrow burn (e.g. create multiple presence claim requests from a single escrow burn that I can broadcast out over time) as well as automatically filling presence claims with logs as radios post them. Plasma block times can of course be tuned and as low as sub-second depending on the topology of the sidechain operators. In this demo I believe one Plasma block was 3 seconds.