Inquiry regarding use of Tags vs. Traditional Map Layers


#1

Apologies if I have a misunderstanding of the protocol, but, in terms of storing POI’s and other relatable data, why is it that we use one base map with all related contract POI’s and filter them using tags rather than utilizing a base map with a library of contract Layers corresponding to different location types?

This question assumes that the volume of data on the Blockchain can be minimized by calling only necessary layers onto the Base Map.


#2

Interesting proposal. Definitely worth discussing in our next improvement workshop. Thoughts @nameloceroom?

The next one will be in July, exact date TBD.

You can find notes and recording from the previous one here:


#3

We must ask what is the goal that is sought?

A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.

— Alfred Korzybski, Science and Sanity , p. 58.

“A model which took account of all the variation of reality would be of no more use than a map at the scale of one to one.” – Joan_Robinson

“Everything simple is false. Everything which is complex is unusable.” ( “Ce qui est simple est toujours faux. Ce qui ne l’est pas est inutilisable”. “A simple statement is bound to be untrue. One that is not simple cannot be utilized.”) – Paul Valéry

“Entities are not to be multiplied without necessity” ( Non sunt multiplicanda entia sine necessitate ) – John Punch

Adding complexity must be carefully considered in the protocol. Does this actually make things simpler or introduce complexity that is not justified?

Is the current state of FOAM able to move forward to dPOL with the Zone Anchor’s? If so does this idea of layers help, hinder or provide a neutral contribution to dPOL for the Zone Anchor’s?


#4

@naynaysoosoo Are you proposing that the registry contracts be different for different types of locations? Like there would be a contract specifically for staking a government building vs a business?

I’m curious what advantages you think this might provide to the system. My initial reaction though is that this would add a lot of complexity to the smart contracts, which are already deemed by many community members as being too complex, for what benefit?


#5

I do believe it would add a lot of complexity, especially at this stage, however, I believe that enabling flexibility within contracts based upon use-case will be required if the protocol is to shift from a static state to a Dynamic Proof of Location that incorporates the verification of geo-spatial locations through time.

Of course this would mean that Zone Anchors and Zone Authorities – which will naturally evolve from individual participants to Commercial entities (slowly transitioned away, as IOT infrastructure expands) will soon dominate the landscape – will push Validators to become more optimized for location service responses.

I suppose that my suggestion for creating separate registry contracts based upon location type could enable diversity among Validators, allowing for specific Validators to determine consensus for specific types of contracts (instead of all contracts) based upon the priorities of Zone Authorities and their SLA’s.

Once again, please correct me if my understanding is skewed, but from my perspective the optimization of the protocols vision is necessary and will require streamlined communication not only between contracts and DApps, but also hardware devices, and the validators at its foundation.


#6

The existing FOAM protocol is robust

“In Proof of Location, the goal is to have consensus on whether an event or agent is verifiably at a certain point in time and space. The FOAM token incentivizes users to contribute computation and radio power towards secure location services in a way that aligns with financing alternative means of obtaining secure localization and location verification standards that are suitable for autonomous smart contracts.” Page 20 of FOAM Technical Whitepaper

“A Zone is a set of Authorities with a network configuration as above, whose Authorities agree to participate in a shared state machine. “Zones” run concurrently and each Zone shares a state machine and is financially incentivized to remain in sync.” Page 20 of FOAM Technical Whitepaper

We refer to Zone Anchors and properly they are comprised of:

  • A Zone Anchor is a device with a radio transmitter, a local clock, and a public key. A node is capable of engaging in a clock-synchronization protocol, requires a connection to a gateway .

  • A Zone Authority is a distinguished gateway node with internet access and “sufficient” computational power to maintain a shared State Machine. It has the ability to determine if a the state machine is in sync (see below).

  • A Zone is the quorum that maintains clock sync for a given region. Four or more Zone Authorities form a Zone, the quorum that maintains clock sync for a given region. Once synchronized, the Zone can determine the location of a requesting node by using time of arrival measurements to verifiably triangulate position.

  • A Shared State Machine is maintained by the Zone Authorities in a Zone on the state of synchronicity. A consensus algorithm is used to vote on writing to the shared state machine. Page 4 of FOAM Technical Whitepaper

Because applications (dApps), services, and transactions are built upon settlement at a lower layer, there is room for customizing the feature set of a Zone Anchor, while most importantly not changing the established protocol of FOAM.

Think of how TCP operates:

The TCP/IP model consists of five layers:

  • the application layer,
  • transport layer, (The transport layer is responsible for the reliability, flow control, and correction of data which is being sent over the network.)
  • network layer,
  • data link layer and
  • physical layer.
    tcp-ip-model

Now look at how FOAM is built, of these we can concretely think of them as:

The FOAM Application Layer

  • future dApps
  • A Zone’s Shared State Machine
The FOAM Transport Layer
  • Zone Authority (zone gateway node) ( the validator set is effectively the collection of Zone Authorities that share a “location horizon”) Page 16 of FOAM Technical Whitepaper
  • Zone Anchor is a node is capable of engaging in a clock-synchronization protocol, [and] requires a connection to a gateway .
  • FOAM Signal (ERC-721 Token) (required for A Zone Anchor to operate)
  • FOAM (ERC-20 Token)

The Network Layer

  • Zone (Four or more Zone Authorities form a Zone, the quorum that maintains clock sync for a given region.)
  • Ethereum (only transactions based on FOAM with Ethereum are valid)

FOAM has established a complete ecosystem vision

I don’t see how you have established any rationale for that proposal. Features are properly addressed as applications that settle to the layers below them in the FOAM Layer Model shown above. Flexibility of use is possible through developer creativity in crafting dApps that can capitalize on that ability. Asking for additional contracts, adds undue complexity, it also is a distraction from the Zone hardware. It also doesn’t make sense as it splits the efforts of Zone operators when we should be focused on supporting the FOAM core protocol building on top of that.

Again your request is for extra work from the FOAM team, in an area that if pursued would fragment the ecosystem. It could not be more advantagueos to a competitor of FOAM than for us to pursue such a folly. I don’t think your suggestion is clear enough to invalidate the established whitepaper description of the FOAM Architecture:

“A Root Chain is the blockchain where FOAM token bonds, deposits, rewards and penalties take place. Participants must interact with this chain to be given access to participate as part of the validator set of a Zone. For now, imagine that the root chain is the public Ethereum blockchain.” Page 4 of FOAM Technical Whitepaper

Verifiers in the FOAM Proof of Location protocol are any computational entity that is able to read the blockchain data produced by Zones and check Presence Claims for fraud proof. Similarly to the construction of a Zone, a verifier must make a deposit on the root chain to participate in the protocol. page 23 of FOAM Technical Whitepaper

“The Verifiers are computational engines that incentivized to check the time logs of Zones for fraud and finalize Proofs of Location. The verifiers need to have at least the same computational power as that of an Authority inside a zone. Because Verifiers compute locations from the time stamped data they can be said to be mining triangulations.” Page 4 of FOAM Technical Whitepaper

“The role of the token is to incentivize providers of computation and ultimately offer location services. The token, a scarce resource, can be thought of as a piece of virtualized hardware needed to operate a validator. Each validator of each zone has a deposit; when a validator joins, its deposit is the number of deposited coins. After joining, each validator’s deposit rises and falls with rewards and penalties.” Page 21 of FOAM Technical Whitepaper

side-chain

Figure 11: Relationship between Child Chains containing Zone Data and Unverified Presence Claims, Verifiers checking for Fraud Proof and the Parent Chain where Tokens are Staked” page 25 of FOAM Technical Whitepaper

" The Zone State Machine at the bottom is a child chain to the root chain and contains the data logs of time stamps as well as a source of unverified Presence Claims. At this stage, the Presence Claims constitutes a hypothesis to an entity’s location in a Zone. This data is meant to be referenced by any computational engine capable of verifying that the presence claims are authentic (i.e. the signatures are valid and messages are well formed), as well as the fact that they constitute a valid trilateration for the claim’s location.

"The Verifier circles represents the set of computational engines that have staked on the root chain and are capable of checking the Zone data for fraud. The Verifier posts results to the root chain with a counter-factual verification contract. The purpose of this contract is to establish the validity of the presence-claims and to provide the proof-of-location contract with data and the verification credentials that match it while migrating the computation off of the blockchain. " Page 25 of FOAM Technical Whitepaper

Going forward I will be looking for a rationale from FIP proponents that can articulate why what they are proposing cannot or should not be approached as a dApp leveraging FOAM with the requested feature rather than evaluating changes to the described vision of FOAM.