Tendermint & FOAM: Achieving Global Scalability Through Local Consensus
FOAM’s dynamic proof of location protocol will enable a permissionless and privacy-preserving network of radio beacons that is independent from external centralized sources such as GPS and capable of providing secure location verification services. See “The World Economy Runs on GPS. It Needs a Backup Plan” for a great primer on this topic:
As dynamic proof of location is built out, FOAM will deploy three flavors of consensus protocols with different states of synchronicity:
a) Asynchronous Root Chain (Ethereum)
b) Semi Synchronous Shared State Machine (Tendermint)
c) Synchronous BFT Time Synchronization Protocol over Radio
In this post we will specifically go through the semi synchronous shared state machine consensus protocol for local zones within the larger context of creating dynamic proof of location.
Semi Synchronous: Tendermint shared state machine for local zone consensus
For dynamic proof of location Tendermint Core is used as the consensus mechanism for child chains, i.e. the shared state machine of Authorities in a Zone.
Tendermint Core is a Byzantine Fault Tolerant consensus algorithm developed in 2014 based on a Proof of Stake design. The main purpose and benefits to Tendermint are speed, consistency, safety and instant finality. These features empower the scale of public Proof of Stake blockchains:
At the core, Tendermint works as a round-based voting mechanism which makes the consensus protocol. A round is broken up into a three-step process through which validators propose blocks, signal commitment intent and then sign to commit new blocks. This mechanism yields a secure state replication machine for atomic broadcast with an added layer of accountability. Safety faults are perfectly attributable in Tendermint.
When addressing the question of how distributed consensus on synchronicity is maintained by the Authorities of a Zone, the incentives of sharing and updating a state machine, as well as the structure of voting rounds are addressed by Tendermint. The ultimate purpose of Authorities being in sync is to provide location services, the accuracy of which is a function of the number of synced entities involved.
While the clock synchronization over radio and localization for nodes is determined with Synchronous consensus, the consensus algorithm for the replication of the shared state machine for a single zone is partially synchronous. The synchronous radio time consensus interacts with Tendermint consensus through the Application Blockchain Interface(ABCI). In Tendermint:
Ultimately, to become a validator in replicating the shared state machine of a Zone, and by extension to become a node running the time synchronization protocol over radio, collateral in the form of FOAM tokens is needed as a safety deposit on a root or parent blockchain. This deposit is needed for the validator to attest they will follow the rules of the protocol without being malicious or faulty. This deposit is subject to being slashed– as in destroyed–if the participant is found to be acting Byzantine. The time log data produced by a Zone is not considered final until it has been verified for fraud by a computation engine running trilateration and other triangulation location algorithms on the Zone’s time data.
In this system, the security and consensus of the root chain is an asynchronous network. This can be the Nakamoto consensus of a Proof of Work chain like Ethereum or an established Proof of Stake blockchain like Casper or for example DFINITY. As such, FOAM employs Synchronous, Partially Synchronous, and Asynchronous consensus for Proof of Location.
Tendermint guarantees that safety will never be violated because a validator will never commit conflicting blocks at the same height. Therefore, a Tendermint-based blockchain never forks. This reflects the FOAM priorities in secure data over the time blocks are committed.
The consensus in a FOAM Zone will be achieved through the Tendermint as well as the incentives of sharing, the structure of voting round and updating a state machine. The ultimate goal of Zones is to provide location services, the accuracy of which depends on of the number of synced entities involved.
This is the first in series of posts that will discuss and dive into how FOAM Dynamic Proof of Location utilizes Tendermint. The next posts will focus on the results of Simulations of the FOAM Time Synchronization Protocol ABCI Tendermint application written in GO and initial work done with Plasma for child chain creation. Future posts will propose an architecture for Zone child chains based off of Cosmos. An additional parallel series on how Verifiers checking for Fraud Proof operates with Counterfactual Verification is also being planned!
Disclaimer: Please note that Dynamic Proof of Location will not be available at the time of sale, and is previewed for information purposes only. The availability of these features in the future will depend on the circumstances described in the Dynamic Proof of Location section of the FOAM product White Paper.
Please note that the verticals and use cases referred to in this post remain potential use cases only, are provided for information and discussion only, and would not reflect the utility or functionality of the FOAM protocol at launch — the success of any use cases will depend on how users and community participants expand and build out the FOAM network, as well as the development of the proof of location protocol (including in particular the establishment of zones, which are not envisaged at the initial launch), before any potential use cases might come to fruition.
Information in this post is provided on a non-promissory basis and should not be relied upon or taken as advice in any form (including any form of investment advice), and may become incorrect or out of date.
