Dear Members of the FOAM Community,
I am writing with an update on the recent work done by the Foamspace team and plans for the coming year. While we are still formalizing a roadmap for publication, please see the below for an indication of the work being done and planned.
In 2018 we saw the successful launch of FOAMs static proof-of-location application. We have released all of the functionality to the FOAM Map described in our previous roadmap and will continue to support new functionality such as notifications, leaderboards, achievements, bots and DEX integrations. We are listening to your feedback and criticisms and will move to address them in the coming weeks.
The static proof-of-location is a protocol with a curation and verification mechanism as well as an upgrade path to alter the mechanisms. There is much work to be done within the blockchain space on user experience and the ability for those not aquantied with blockchains to interact with the Map. As a protocol, we see applications that we build ourselves or others launch as targeting specific users and market fits.
Our first local mapping event and the second edition of our Curation Markets Meetup. This event is scheduled for February 12th at the New Lab in Brooklyn New York. A formal announcement is forthcoming as well as plans for events in other locations. https://www.meetup.com/Curation-Markets-NYC-Meetup/
FOAM token has been listed on Radar Relay today. This is an exciting development to the FOAM team specifically because it will allow a 0x instant integration directly into the FOAM Map interface. This will allow new users to obtain FOAM tokens directly inside the application.
In addition to the efforts outlined above, we also did make some significant progress on dynamic Proof of Location through last year. Much of this culminated into the technical whitepaper draft, however more unpublished work and research has been completed which are described further down in this post. It is worth restating what the current state of affairs as well as what our future objectives are.
Dynamic Proof of Location can be summarized as follows:
- Consumer hardware (LoRa for example) that can run a byzantine fault tolerant time synchronization protocol in a mesh configuration with cryptographic signatures
- The data produced can be transmitted to and validated on a root blockchain (such as Ethereum) and produce cryptographically proven location-data (Presence-claims)
- Incentivization for producing and validating Presence-claims can be governed using smart-contracts on Ethereum and mining rewards.
The first section of items below is an overview of the recent non-dPoL work done by the Foamspace team with dPoL updates following:
The FOAM Developer Portal (https://f-o-a-m.github.io/foam.developer/) is the site where developers can find information about integrating the FOAM Spatial Index into their applications. Previously the portal contained information related to our Rinkeby-backed, beta application (https://beta.foam.space/), but now that the mainnet application has reached a 1.0 version we are proud to soon replace this with our current documentation. This release is planned for the middle of next week.
The developer portal documents things such as:
- Swagger documentation of our REST API endpoints and their intended uses.
- The ability to test these endpoints in the browser.
- Documentation on all FOAM websocket subscriptions for live notifications.
- Documentation about how the FOAM map works, including information about the smart contracts and the role of the FOAM services.
We also look forward to extending the portal with example integrations as developers begin building on top of the FOAM platform. For instance, we have been partnering with the analytics company Blocklytics (https://blocklytics.org/) to provide our users with email updates relating new POIs, challenges, and global statistics about the foam map.
Recently we upgraded Purescript 0.12 from 0.11 as well as worked on a pull request to the official Purescript spec that was approved as we continue to contribute back the the functional development ecosystem.
“add seq/par and hook #83” This is a substantial Pull Request from Foamapce to prescript which allows multiple tests to run in parallel with independent logging for faster iterations.
Recently we did some bug fixes to the Chanterelle library merged that allows you to generate genesis blocks without having imported libraries
This week we upgraded our internal Ethereum nodes to the latest versions of Parity and Geth in preparation for the (then upcoming) Constantinople fork, and did a secondary upgrade since the fork was delayed again. Further, we wrote several improvements to our internal continuous integration system to allow us to deliver feature releases and updates more rapidly.
The time synchronization protocol aspect of Proof of Location described in the FOAM technical whitepaper draft is based off publications done by Mahyar Malekpour, a researcher at NASA, for example “A Byzantine-Fault Tolerant Self-Stabilizing Protocol for Distributed Clock Synchronization Systems”.
We made significant progress in understanding Malekpour’s many publications and since have moved on to formally verifying the mathematics ourselves and now have a working docker image that formally verifies the claims.
For this we use Symbolic Model Checking (SMV). SMV is a system for formally verifying concurrent systems for correctness. The value of formal methods is that they provide a means to symbolically examine the entire state space of a digital design (whether hardware or software) and establish a correctness or safety property that is true for all possible inputs.
With the understanding that this work can be applied to Proof of Location we have continued to develop and improve our implementations, simulations, and tests of the time synchronization protocol that underpins Dynamic PoL.
This work was written in GO and further utilizes Tendermint consensus and the Cosmos SDK. We are exploring the Substrate sdk by Parity but in any case believe Tendermint to be the optimal Consenus engine for Zones.
We have previously published some previews of this work. As it continues to be developed the Zone Anchor software will be made open source.
It is important to keep in mind the scope of the Proof of Location architecture, beyond hardware work it is also a very large blockchain project and we see the development of FOAM akin to other projects such as Ethereum’s Casper, Cosmos, Filecoin - which unfortunately sometimes do move slowly.
This diagram summarizes the architecture nicely. On the parent chain or root chain participants stake tokens into Service Level Agreements. These bonded tokens are require a smart contract design and can be “slashed” if a user acts maliciously. Also on the root chain will the “Total FOAM Area Reward” or TFAR contract. This smart contract will require complex logic and is responsible for calculating mining rewards based on area covered by a zone, amount of tokens bonded as well as Signal weight.
Off of the parent chain we see Zones. Zones are comprised of at least 4 Zone Anchor Radios. A custom firmware that we are developing is required to run the clock synchronization protocol. A Zone shares a state machine and uses Tendermint consensus. An additional design challenge is how Zones connect and communicate with the parent chain. We are researching a Plasma construction while also waiting for Cosmos to realease their Inter-Blochcain Connection protocol (IBC).
Verifiers check for fraud proof and for this we are building off of the work done by L4 with off chain counterfactual verification. https://www.counterfactual.com/statechannels/
The FOAM Proof of Location protocol is designed to be radio agnostic. However, as a permissionless protocol it is desirable for off the shelf radio equipment to be used. In previously published documents we described why LoRa appeared to be a great choice.
There are many fair critiques of LoRa out there. Yet, these tend to focus on the limitations of LoRaWAN, a free MAC layer that most using the radio rely on. Proof of Location requires nano-second level precision and we set out to test our hypothesis that LoRa could be used for this with a custom firmware.
The firmware developed and used in this experiment is limited to sending ensemble time messages. To be able to fully run the Proof of Location software, additional work is needed in expanding the functionality of the firmware. This work is being done in parallel to the Tendermint based simulations. The next step is to be able to run these simulations on the boards. Following that we will move forward with a reference design for a FOAM Developer board with a means of obtaining them and release the software so all can participate in field testing.
A new blog series on Dynamic Proof of Location will be launching next week. Next week will also start a new bi-weekly community call. In the first of this series we will walkthrough the above LoRa experiment and demonstrate our findings.
Thank you for reading.