HackMD
  • Beta
    Beta  Get a sneak peek of HackMD’s new design
    Turn on the feature preview and give us feedback.
    Go → Got it
    • Beta  Get a sneak peek of HackMD’s new design
      Beta  Get a sneak peek of HackMD’s new design
      Turn on the feature preview and give us feedback.
      Go → Got it
      • Sharing Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Note Permission
      • Read
        • Owners
        • Signed-in users
        • Everyone
        Owners Signed-in users Everyone
      • Write
        • Owners
        • Signed-in users
        • Everyone
        Owners Signed-in users Everyone
      • More (Comment, Invitee)
      • Publishing
        Please check the box to agree to the Community Guidelines.
        Everyone on the web can find and read all notes of this public team.
        After the note is published, everyone on the web can find and read this note.
        See all published notes on profile page.
      • Commenting Enable
        Disabled Forbidden Owners Signed-in users Everyone
      • Permission
        • Forbidden
        • Owners
        • Signed-in users
        • Everyone
      • Invitee
      • No invitee
      • Options
      • Versions and GitHub Sync
      • Transfer ownership
      • Delete this note
      • Template
      • Insert from template
      • Export
      • Dropbox
      • Google Drive Export to Google Drive
      • Gist
      • Import
      • Dropbox
      • Google Drive Import from Google Drive
      • Gist
      • Clipboard
      • Download
      • Markdown
      • HTML
      • Raw HTML
    Menu Sharing Help
    Menu
    Options
    Versions and GitHub Sync Transfer ownership Delete this note
    Export
    Dropbox Google Drive Export to Google Drive Gist
    Import
    Dropbox Google Drive Import from Google Drive Gist Clipboard
    Download
    Markdown HTML Raw HTML
    Back
    Sharing
    Sharing Link copied
    /edit
    View mode
    • Edit mode
    • View mode
    • Book mode
    • Slide mode
    Edit mode View mode Book mode Slide mode
    Note Permission
    Read
    Owners
    • Owners
    • Signed-in users
    • Everyone
    Owners Signed-in users Everyone
    Write
    Owners
    • Owners
    • Signed-in users
    • Everyone
    Owners Signed-in users Everyone
    More (Comment, Invitee)
    Publishing
    Please check the box to agree to the Community Guidelines.
    Everyone on the web can find and read all notes of this public team.
    After the note is published, everyone on the web can find and read this note.
    See all published notes on profile page.
    More (Comment, Invitee)
    Commenting Enable
    Disabled Forbidden Owners Signed-in users Everyone
    Permission
    Owners
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Invitee
    No invitee
       owned this note    owned this note      
    Published Linked with GitHub
    Like BookmarkBookmarked
    Subscribed
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    Subscribe
    # Proposed Workplan: the Astral Protocol At Astral we are creating the tools developers will need to build an ecosystem of location-based dApps and composable spatial contracts. We see a vast opportunity space here, with exciting early initiatives from [FOAM](https://foam.space/), [Regen Network](https://www.regen.network/), [Grassroots Economics](https://www.grassrootseconomics.org/), [IoTeX](https://iotex.io/), [IBISA Network](https://ibisa.network/) and others. Our vision at Astral is to build tools and help establish standards that will enable a composable location-based decentralized web. We're quite early in our journey, and have an orienting question prompting these investigations - what if we could use an entity's physical location as a condition in a smart contract? And relatedly, how can we connect verifiable insights about physical reality with smart contract logic? Our investigations into this question has hardened our understanding of the tools and components needed. Our goal here is to share these ideas openly - gather some feedback, and see if you or anyone you know would be interested in supporting one or more of these initiatives with expertise and / or capital. Our strategy is to design a modular architecture of Web3 spatial primitives - each useful in their own right, but designed to function best together. We have built a few Astral dApp prototypes, and have architected a few more. This work has helped us identify versatile tools that would have accelerated development, regardless of the application. Based on these insights we are conceptualizing the design space as a three layer stack. - **Spatial Contracts** - smart contracts that use location or spatial data in some way - **Data** - capture, storage and perhaps processing - **Oracles** - to connect the two Our goal is to produce a suite of tools, libraries and SDKs that would let developers efficiently build location-based dapps without having to deal with the complexities of managing spatial data in the Web3 paradigm. A second order effect is that if the community adopts standards, applications become composable. To achieve this goal, we are currently working on a few initiatives: - Spatial.sol - Verifiable spatial data registries - GeoDIDs - IPLD-encoded raster and vector spatial datasets - Universal location proofs ## Spatial.sol: a Solidity library of topological and geometric functions Many of the applications we envision will require us to perform spatial operations in smart contracts. To this end, a few years ago (at ETHParis) we outlined and experimented with a Solidity library for performing these operations - measuring the length of a linestring, testing to see if lines intersect, checking to see if a point is inside a polygon, etc. We prototyped a location-aware wallet (early experiments that may lead to truly [**local** currencies](https://ethresear.ch/t/how-to-implement-digital-community-currencies-with-ethereum/8801)). At the time we were discouraged due to computational complexity leading to high gas costs, but Layer 2 solutions like Polygon and xDai, alternative lower cost EVM-compatible blockchains like IoTeX or Avalanche and, of course, Eth2 does mean that these kinds of operations will be increasingly viable in smart contracts. We are developing the first version of the `Spatial.sol` library and plan to release it under an open source license. Developing the library entails tackling several technical challenges, and to build a production-quality library will be quite involved. First, `Spatial.sol` has a dependency: `Trigonometry.sol`, developed and open sourced by Sikorka ([docs](https://github.com/Sikorkaio/sikorka#trigonometry), [code](https://github.com/Sikorkaio/sikorka/blob/master/contracts/trigonometry.sol)). This library appears to have been abandoned a few years ago, and lacks a `tangent` method, which is useful in some operations like the [bearing](https://github.com/Turfjs/turf/blob/41a123a0e151be6a7e312dfecb91b69c4ff3f3f2/packages/turf-bearing/index.ts#L53) between two points. `Spatial.sol` will require an audited `Trigonometry.sol` to be secure. `Spatial.sol` is required for many Astral dapps and contracts, including the verifiable spatial data registries described below. We have not decided on the functions the library will include, and will look to [Turf.js]() for inspiration. We anticipate that we'll want to develop a corresponding client library `eth-spatial.js`, to abstract some of the complexities of supplying spatial data to contracts using Spatial.sol. | | | | --- | --- | | Solidity engineers | 3 months (?) | | Typescript engineer | 1-2 months | | Audit | ? | | Target deliverable | `Spatial.sol v0.0`, `Trigonometry.sol v0.0` | ## Verifiable spatial data registries Leveraging Spatial.sol, we are early in the process of developing a standard contract to represent spatial data registries. There is a wide breadth of opportinities in this design space as well. Specifically, we are building on work we've done to let self sovereign users register geographic zones on Ethereum. This capability is required for a number of use cases - a congestion zone system like Hyperaware, sustainability-linked bonds and other spatial DeFi applications, parametric insurance policies like those IBISA provides, location-based Web3 games including AR and [Pebble Go](https://twitter.com/go_pebble?lang=en) and so on. We believe that a smart contract standard would make developer's lives easier, and contribute to composability of these zone registries. Our plan is to extend the ERC721 contracts, and represent geographic zones as NFTs, meaning they can interoperate with ERC721-compatible dapps, be owned and transferred, etc. We'll extend the contract, though, to include geospatial operations - for example, we plan to include a method that checks if a point supplied is contained within the boundaries of a specific zone: `zoneContains(zoneID, coordinates) returns (bool)`. ### Challenges Land registry contracts exist, for both virtual and real-world land parcels - [Decentraland](https://decentraland.org/), [Etherland](https://etherland.world/marketplace/), [Superworld](https://www.superworldapp.com/), [Geo Web](https://www.geoweb.network/), [Cryptovoxels](https://www.cryptovoxels.com/) and others. However, these almost always restrict users to owning grid cells, due to the complexity of representing irregular polygons in a smart contract. A land registry where two users could own the same piece of land would not be realistic - detecting these topological intersections is difficult. It is our belief that for spatial data registries to be useful in real world contexts, they must support irregular polygons. This means that we need to be able to detect zone intersections, which could result in a piece of land being double-insured, or a vehicle being in two congestion zones at once. The spatial data registries standard we are designing aims to achieve the representation of this _physical scarcity_ applied to physical territory within a spatial reference system. These are "non-intersecting" boundaries, defined as Type 1 jurisdictions by [Hooghe and Marks (2003)](https://www.researchgate.net/publication/248233581_Unraveling_the_Central_State_but_How_Types_of_Multilevel_Governance). We intend to achieve this by performing zone intersection checks using `Spatial.sol`. The library will have functions that allow us to check if zones intersect, and adapt contract control flow accordingly. We have been experimenting ([geolocker](https://devpost.com/software/geolocker), [hyperaware jurisdiction registry](https://hyperaware.io/demo/jurisdiction-registration)) with smart contracts that would enable a spatial data registry of polygons representing zones on the Earth's surface (or areas / volumes within any spatial reference system ...). We would like to design this protocol to make polygons composable building blocks to use across the smart contract landscape. Our understanding of the potential of this is quite nascent, but we anticipate these registries will have myriad uses in spatial finance, mobility, gaming and governance. We're researching how to efficiently design a system that would enable this kind of a spatial data registry, along with requirements. We're trying to work out exactly what the needs might be and anticipate that this will emerge as a contract standard. We can imagine many variations of this type of contract deployed, each storing its own registry of polygons - for mobility apps, administrative jurisdictions, maritime governance zones, restricted airspace and so on. The spatial reference system is configurable - so it could define zones in relation to the sun, another planet, a vehicle, and so on. Such a standard would contribute to composability of these spatial dApps. We expect a Typescript client library will be useful to work with verifiable zone registry contracts. | | | | --- | --- | | Protocol engineer | 3 months | | Solidity engineer | 3 months | | Typescript developer | 1 month | | Audit | ? | | Dependencies | | | Target deliverable | EIP? White paper? ERCx standard contract. ERCx.js package. | ## Data ### Origin All data has some origin, a point of capture or creation. Very often spatial data originates at a device that detects some variation in the physical environment contacting its empirical sensor, converts this analogue signal into some digital representation, and stores, processes or transmits that binary information. We see this as the ultimate oracle problem - how can we trust that information is true? We understand that while advancements in positioning, navigation and timing like FOAM's dynamic [Proof of Location](https://foam.space/location) and IoTeX's [Pebble trackers](https://iotex.io/pebble), are developing apace, it is still not possible to completely trust an edge reading, especially a position. This represents a significant attack vector for the systems we are building, and we would like to conduct and support further research into trusted measurements from the edge of the network. ### GeoDIDs: Web3-native spatial data Once these measurements are captured digitally, the information is formatted to be processed by some software. Spatial data comes in many different formats - GeoJSON, KML, shapefiles, GeoTIFFs, cryptospatial coordinates etc etc. Astral endeavors to design an open and agnostic protocol that will gracefully develop and evolve with the state of computing. We also demand full trustlessness, self sovereignty and independent verifiability of all protocols we design. This requires a versatile, Web3-native spatial data identification, encoding and storage scheme. To achieve this, with support from the Filecoin Foundation and London Blockchain Labs, we have drafted a [GeoDID Method Specification](https://docs.astral.global/geodids/geodid-core-specification) and [prototype modules and smart contracts](https://github.com/AstralProtocol/astralprotocol) to create, read, update and deactivate these geographic decentralized identifiers and the data assets they reference. GeoDIDs will identify these files by wrapping the spatial data assets in DID documents, thereby providing a standard schema to grant the user verifiable control and enable trustless interoperability. Different spatial data formats will be supported through GeoDID Extensions - meaning GeoDIDs can support any current or future digital spatial data format. Required member variables will include relevant metadata to enable comprehensive indexing and use of the spatial data a GeoDID identifies. We have designed the initial draft of the spec and would be curious for feedback from you or anyone interested when we release the spec to the community for review. Additionally, we invite anyone interested in using or contributing to the GeoDID project to reach out to us via Twitter @AstralProtocol or on our Discord [here](https://discord.gg/kBu3zSva). GeoDIDs are agnostic to the spatial data assets being identified. However, we are designing the alpha implementation of the GeoDID modules to rely on IPFS by default, so we can cryptographically verify the integrity of the data assets referenced. More on the Web3-native geospatial vision can be found [here](https://hackmd.io/@astral/rkQh4HbEO), and initial prototypes of IPLD-encoded GeoTIFFs [here](https://docs.astral.global/develop/ipld-and-geotiffs). ## Oracles We have done little work on spatial oracles, instead focusing to date on the data storage and spatial contracts layers of the protocol stack. Our early thinking suggests that making a full suite of spatial analytics algorithms (raster and vector) available at the oracle layer would be useful for on-demand processing of geospatial data. For example, one concept protocol we have designed is a parametric insurance system. With this, we trustlessly insure physical assets in space - initially conceived of as static areas or volumes like land parcels or administrative jurisdictions (maritime, terrestrial, airspace etc). Upon purchasing a policy, agents would register their land parcel in an Astral verifiable spatial data registry, possibly represented using a GeoDID identifying a polygon or polyhedron. Additional information like the policy duration, indemnity process and, crucially, insured parameter and data source, would be specified upon policy creation. See this [relatively simple example](https://www.nature.org/en-us/what-we-do/our-insights/perspectives/insuring-nature-to-ensure-a-resilient-future/) deployed by traditional insurers. Asset monitoring could be configured in a few ways. In the example above, periodic checks to the parameterized data feed could be made, and a payout could be triggered automatically if the parameter threshold is exceeded. Alternatively, the insurance contract could be reactive, requiring a policy holder to submit a claim transaction. In this event, the contract would trigger the oracle to fetch both the land parcel information and the relevant parameterized external information. To enable a scalable, fully decentralized system, we suspect the most efficient architecture will require an oracle or some Layer 2 consensus network to apply a spatial analysis algorithm to these inputs to determine if the claim is valid. (This differs to many existing DeFi insurance protocols - these often rely on some entity - a trusted individual or DAO committee - to assess the evidence off chain and submit an attestation to settle a claim or trigger automatic indemnity - see [IBISA](https://ibisa.network/) and certain review strategies employed by Protekt's [Claims Manager](https://docs.protektprotocol.com/#/?id=protekt-contracts). This functionality was also required to detect the amount of time devices spent in policy zones in Hyperaware, and to supply NOx levels to the [sustainability-linked bond dApp](https://github.com/AstralProtocol/sprout) we prototyped during the KERNEL Genesis Block. What is unique about this compared to other oracle systems is that our focus is narrowly on spatial data, that is, information that contains some spatial, or location, dimension. We could argue that _all_ data is spatial data, but here specifically we are looking at data representing physical space - geospatial data, and data positioned within other spatial reference systems. Needless to say, much research into these oracle capabilities - including privacy-preserving techniques - for bringing spatial insights on chain in an efficient way is warranted, as it seems this is an unavoidable layer of the Astral stack. | | | | --- | --- | | Product researcher | 3 months | | Technical researcher | 3 months | | Target deliverable | Research note on spatial data oracles | ## Universal Location Proofs Technically it is extremely difficult (if not impossible) to create a definitive proof that some information was created at a specific physical location. There are technical ways to improve trust in the position - signing position captured by the sensor triangulating with the GPS or FOAM network in a secure enclave, for example. It would require a special app or - eventually - a plugin for mobile crypto wallets that allows users to generate the “universal location check-ins” (credit @jabyl from Distributed Town for his help thinking this through). Additional layers of trust could be built on a location by incorporating other sensor readings (like from a camera or microphone), as could requiring users to scan a cycling QR code only available at the location, form social check-ins in which they verify that the others were present, etc. We’ve been doing some early thinking about zero-knowledge location proofs as well, which prove that a point is inside a polygon without revealing the user’s position. This could then be verified on chain, enabling location-based smart contracts that preserve the user's privacy. Applications include local currencies, intelligent mobility systems, dynamic game preserves, detecting illegal and unregulated fishing in Maritime Protected Areas, location-anchored games and a lot more. We have not looked into what work on this has been done in any meaningful sense - Tux at NuCypher was interested but we're not sure if they’ve looked at it any further. We don’t have any cryptographers working with us so right now. Phase 1: | | | | --- | --- | | Cryptographer | 3 months | | Researcher | 3 months | | Target deliverable | Academic paper. Blog posts. Feasibility study. | --- That's the state of our thinking right now - building tools to make it easy for developers to build location-based dApps. If any of this interests you please reach out.

    Import from clipboard

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lost their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template is not available.


    Upgrade

    All
    • All
    • Team
    No template found.

    Create custom template


    Upgrade

    Delete template

    Do you really want to delete this template?

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password

    or

    By clicking below, you agree to our terms of service.

    Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox

    New to HackMD? Sign up

    Help

    • English
    • 中文
    • Français
    • Deutsch
    • 日本語
    • Español
    • Català
    • Ελληνικά
    • Português
    • italiano
    • Türkçe
    • Русский
    • Nederlands
    • hrvatski jezik
    • język polski
    • Українська
    • हिन्दी
    • svenska
    • Esperanto
    • dansk

    Documents

    Tutorials

    Book Mode Tutorial

    Slide Mode Tutorial

    YAML Metadata

    Contacts

    Facebook

    Twitter

    Feedback

    Send us email

    Resources

    Releases

    Pricing

    Blog

    Policy

    Terms

    Privacy

    Cheatsheet

    Syntax Example Reference
    # Header Header 基本排版
    - Unordered List
    • Unordered List
    1. Ordered List
    1. Ordered List
    - [ ] Todo List
    • Todo List
    > Blockquote
    Blockquote
    **Bold font** Bold font
    *Italics font* Italics font
    ~~Strikethrough~~ Strikethrough
    19^th^ 19th
    H~2~O H2O
    ++Inserted text++ Inserted text
    ==Marked text== Marked text
    [link text](https:// "title") Link
    ![image alt](https:// "title") Image
    `Code` Code 在筆記中貼入程式碼
    ```javascript
    var i = 0;
    ```
    var i = 0;
    :smile: :smile: Emoji list
    {%youtube youtube_id %} Externals
    $L^aT_eX$ LaTeX
    :::info
    This is a alert area.
    :::

    This is a alert area.

    Versions

    Versions and GitHub Sync

    Sign in to link this note to GitHub Learn more
    This note is not linked with GitHub Learn more
     
    Add badge Pull Push GitHub Link Settings
    Upgrade now

    Version named by    

    More Less
    • Edit
    • Delete

    Note content is identical to the latest version.
    Compare with
      Choose a version
      No search result
      Version not found

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub

        Please sign in to GitHub and install the HackMD app on your GitHub repo. Learn more

         Sign in to GitHub

        HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions
        Available push count

        Upgrade

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Upgrade

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully