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.
At FOAM, we’re building what we call Proof-of-location and are creating an architecture that can be summarized as follows:
( Rootchain ) Incentivization for producing and validating location data (Presence claims) can be governed using smart-contracts on Ethereum
( Sidechain ) The data produced can be transmitted to and validated on local blockchains and produce cryptographically proven Presence claims.
( 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:
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:
( 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
( 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.
( 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 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
- ZoneAnchor or “adversary” is represented by
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.
A recording of this Demo can be Found Here:
The FOAM Location Update and Demo Documentation will also be the topic of the next FOAM Community Call.