Closed Physes closed 2 years ago
Currently GPS is the most ubiquitously used positioning system. However, more secure systems and more accurate systems may arise. With this in mind, would multiple positioning systems be supported? Would this be up to the discretion of Multi Signature Root Authorities and the Sovereign entities in which they reside in?
The advantage of using an XML-based schema standard for metadata is that you can specify a "type" attribute for geolocation. In this case the type would be "GPS", then you could specify all of the relevant points. In the case of mulitiple positioning system you would specify it as "GLONASS". The main point is that once you have a large-scale zone, zones can't overlap. But that's a matter for the governance of the zone creation process.
I like this. It might make sense to chat with FOAM about how they're tackling a similar problem.
re: implementation: I'd recommend extending your DNFT contract from ERC721Token and overriding methods rather than reimplementing it with different storage variable names. Any reason you chose otherwise?
I'm not super jazzed about the name; the token can be delegated, sure, but it's not the delegation that makes it unique, it's the fact that the NFT represents physical space. Any other naming options?
I'd also question the need for an XML-based metadata property. First, the contract should confirm to the ERC721Metadata
interface which means returning json with various properties. You should add a custom type to the JSON Schema like geo
and have that be the geo-specific metadata. My interface that only knows about name/desc/image should still be able to display your NFT tokens "correctly".
There's even an example gps type for JSON schema: http://json-schema.org/example/geo.json
I think FOAM might be dealing with a slightly different problem: namely an alternative coordinate system to GPS. Personally I don't see this as an urgent problem as GPS works pretty well, however I'm certainly open to collaboration. Where something like FOAM could be useful with the Zone Protocol is as the source of coordinates in the deed file- however it would work just as well to use GPS in my opinion.
I agree with extending ERC721, I'd like to take that approach. Basically what DNFTs would do is add extra mappings for the height, quantity and "parent DNFT" aspects while retaining the same lookup process for owner and metadata. I don't see a problem with that.
ZML could be done in JSON, however the reason why I chose that was inspired by Google's KML (Keyhole Markup Language) approach. Also having a "type" attribute for elements allows you to specify the protocols that you're using for things like identity and boundaries. For example:
<boundaries protocol="GPS">
<point>
<latitude>XYZ</latitude>
<longitude>XYZ</longitude>
</point>
<point>
...
</point>
...
</boundaries>
And for the identity component, i.e. <titleholder protocol="PGP"> XYZ</titleholder>
. (with flexibility to allow for varying identity protocols/indicators that might be used within this element).
However it would be good to explore an implementation of ZML in a JSON schema also.
Mirroring what @Shrugs said, I strongly recommend using https://tools.ietf.org/html/rfc7946 instead of inventing your own standard for encoding geographic data structures. I also strongly recommend leveraging OSM and the existing infrastructure around that. Hopefully, @kejace or @awright can chime in with some feedback.
@AFDudley I'll definitely consider that. Deed files are both for the purpose of geographic data structures and identity as well as other relevant factors. I've considered a few OGC (Open Geospatial Consortium) standards also both in XML and JSON but none seemed to have all the necessary requirements. I also considered just using a KML file. But this is a good question that will need further thought.
First, the contract should confirm to the ERC721Metadata interface which means returning json with various properties. You should add a custom type to the JSON Schema like geo and have that be the geo-specific metadata
Agree that JSON and following ERC721Metadata
is the obvious choice. XML overhead made it unsuitable for the task and it really has lost the war.
When dealing with geospatial geometry and coordinate systems another option is GeoJSON:
{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [125.6, 10.1]
},
"properties": {
"name": "Dinagat Islands"
}
}
http://geojson.org/
https://tools.ietf.org/html/rfc7946
edit: Of course all this doesn't matter as you're only putting a uri hash to lookup on IPFS or something.
I just wanted to delve into more detail on the "parent/child" arrangement of DNFTs in the implementation. I'm not sure this is the best way to do it but it seems to make the most sense.
Basically, instead of the parent keeping track of its delegates (children), each DNFT keeps a record of its parent via the parent
mapping, which maps the tokenId of the child to the tokenId of the parent:
// maps child delegate token to parent ID
mapping(uint256 => uint256) private parent;
In the standard interface this is accessed via a public view method isParent
:
function isParent(uint256 _child, uint256 _parent)
public
view
returns (bool)
{
require(parent[_child] == _parent);
return true;
}
I'm not sure whether there should be something mapping in the other direction. The reason I wanted to do that was that normally tokens would be delegated via an intermediate ordinate contract which would manage it on behalf of both the parent and the child externally, laying out various conditions or limitations (such as blocking revoke
for a period of time).
EDIT: Another reason for not needing to keep track of all children is that this information is going to be cached in each Zone's Deed File System (DFS). The plan for the DFS is that deed files (metadata documents in ZML) would be cached in a hosted git repository, so it would be fairly easy to track the chain of ownership up through the tree without having to implement it in the contract. However isParent
is necessary to enforce security requirements for the revoke
function.
The full range of mappings (which includes regular NFT and extends with three extra mappings):
// maps token id to owning address
mapping(uint256 => address) private owner;
// maps token id to string metadata uri
mapping(uint256 => string) private metadata;
// maps token id to fungible quantity units.
mapping(uint256 => uint256) private quantities;
// maps child delegate token to parent ID
mapping(uint256 => uint256) private parent;
// maps token id to height index
mapping(uint256 => uint256) private height;
// maps token id to approved address
mapping(uint256 => address) private approvals;
// maps token id to list of owned tokens
mapping(address => uint256[]) private inventory;
// maps token id to the index of owned tokens
mapping(uint256 => uint256) private index;
Hey everyone, so the white paper for The Zone Protocol has been published, explaining the background of DNFTs:
Hi @Physes I'm working on the LayerOne project (mapping real world space on the blockchain), and we've done a lot of thought in this space as well! Check out our open source repo: https://github.com/OpenLayerOne/LayerOne-Contracts
We should work together on this! We are linking 721's to binary quad keys (another open standard that is in the same family of QuadHashes). Binary quad keys have the advantage of easy storage and processing on chain as they are 64-bit integers. We looked into FOAM's crypto spatial coordinates and it did not offer the same flexibility.
We created the concept of a QuadToken that is a binary quadkey + 192 bits for things like a secondary quad key, altitude, timestamp, or address. It's a generic and compact implementation, and we've already written the QuadKey library to add solidity support. Hope you find it useful, and let me know if I can help think through your particular use cases!
The link mentioned in the Implementation section isn't working, has the repository been moved? "Current working implementation as part of the Zone Protocol: https://github.com/Physes/DNFT"
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
Shush @github-actions!
@mryellow If you want to push this for Ard toward an EIP you are welcome to create a pull request that does so.
If people want to continue discussing this EIP, please continue over at Ethereum Magicians. We no longer are using the EIPs issues section for discussions about standardization ideas.
Delegated Non-Fungible Token Standard
Simple Summary
Delegated Non-Fungible Tokens (DNFTs) are a proposed extension of the ERC721 standard designed with the use case of Ethereum-based registration of land and physical property in mind. NFTs are arranged in a federated, tree-like format (similar to DNS) where NFTs can delegate and sub-contract NFTs within a certain geospace.
Unlike digital assets (like CryptoKitties) physical property requires more than just an accurate identification in a database- it also requires legal validity within the context of physical sovereignty. DNFT zones can established by land registry authorities as a root DNFT encompassing a wide area, and can delegate DNFTs as subdivisions of the root zone to existing property holders as a way to upgrade land registries. This is intended to secure the following essential features:
A non-conflicting geospace
Legal validity and physical sovereignty
Compatibility with financial contracts
Abstract
Non-Fugible Tokens were proposed as a way to give identity to external objects on the blockchain. There have been some speculative use cases for digital assets already created, however NFTs have inherent limitations as a standard to apply to physical property. DNFTs add two basic features- writs, which is a fungible representation of geospace that can be delegated. Writ quantities are recorded as an unsigned integer. In addition, there is height variable (also an uint) which represents the level of delegation (1st, 2nd, 3rd, etc.).
Motivation
To implement Non-Fungible Tokens as part of a comprehensive protocol for land and property registry- extending the functionality to allow root ownership by a zone authority, delegation of "child" NFTs (representing regular property rights) as a subset of a root NFT, as well as to incorporate a fungible quantity variable to provide a delimiter for delegated tokens.
Specification
A DNFT contains five elements:
A token ID. Every DNFT is identified by a unique unsigned 256-bit integer.
An owner address. This can be either an externally owned account or another smart contract (ordinate).
A metadata field. We specify a schema for deed files called ZML- Zone Markup Language.
A height variable. This represents the level of delegation.
A fungible unit of account (writs) which provide a delimiting factor on delegation.
A fungible unit of account is necessary so that zone implementors cannot delegate more land than what is under management.
The following is a diagram of an example DNFT zone implementation, with a delimiting number of writs and delegated from the root zone to four levels of abstraction.
Ordinates
DNFTs can be owned by other contracts, allowing for the creation of complex conditional agreements around property. In the Zone Protocol these are called ordinates. Ordinates can split ownership of a DNFT among multiple stakeholders using ERC20 tokens, and you can also create ordinates for things like lease agreements, rent contracts, property options and more.
Fungible Quantity Units (Writs)
DNFTs have a fungible quantity variable, which represents the amount of base geospace assigned to the property right. Writs are a two-dimensional unit of account (i.e. m^2). Alternatively a zone can opt to implement a three-dimensional unit of account (m^3) if desired. This means that a zone of 10000 m^2 containing 10000 writs at the base level could delegate (for example) 10 land leases, each with 1000 writs. It should be noted that writs are not meant to specify the actual boundaries; i.e. they do not have coordinates and are interchangeable. It is the associated deed file that contains all of the boundary info. Writs or cubits are simply a delimiting mechanism that describes the maximum amount of geospace that can be contained within the deed file.
Delegate and Revoke
There are two basic functional additions to ERC721: the ability to delegate and revoke. "Revoke" can be interceded by an ordinate contract which holds ownership of the DNFT between the leaser. This would prevent arbitrary revocations of property rights unless under pre-agreed terms (i.e. at the end of the term of a rent contract). For a freehold a similar ordinate would also be used on a permanent basis.
Proposed Interface
origin: Checks if the "from" tokenId is the child DNFT of tokenId. Returns bool.
getHeight: Returns the delegation height of tokenId.
quantity: Returns the number of fungible geospace units left to delegate.
delegate: Allows the owner of a tokenId to delegate a new DNFT with a certain amount of geospace to a new owner.
revoke: Allows the owner of a parent DNFT to revoke ownership of a child DNFT. This feature can be overridden by an ordinate contract.
Delegate (event): Emitted for new token delegations.
Revoke (event): Emitted on token revocations.
Rationale
The rationale of DNFTs is to provide object identities for physical property within zones.
Backwards Compatibility
DNFTs are compatible with ERC721 NFTs.
Implementation
Current working implementation as part of the Zone Protocol: https://github.com/Physes/DNFT.