Merge pull request #780 from oceanprotocol/issue-701-create-v4-docs
v4 NFT docs
This commit is contained in:
Akshay
GitHub
commit
cc53a21d3e
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Architecture Overview
|
||||
description: Simplicity and Interoperability via a Datatokens Core
|
||||
description: Data NFTs and Datatokens architecture
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
|
@ -11,21 +11,28 @@ Here is the Ocean architecture.
|
|||
|
||||
Here’s an overview of the figure.
|
||||
|
||||
- The top layer is **applications** like Ocean Market. With these apps, users can onboard data services into crypto (publish and mint datatokens), hold datatokens as assets (data wallets), discover data assets and buy / sell datatokens for fixed or auto-determined price (data marketplaces), and consume data services (consume datatokens).
|
||||
- Below that are **libraries** used by the applications: Ocean React hooks, JavaScript library, and Python library. This also includes middleware to assist discovery: Aquarius and (3rd party tool) TheGraph.
|
||||
- The lowest level has the **smart contracts** used by the libraries. They’re deployed on Ethereum mainnet to start, and other networks later.
|
||||
|
||||
Left to right are groupings of functionality: tools for datatokens, tools for markets (including pools), tools to consume data services and for metadata, and external ERC20 tools.
|
||||
- The top layer is **applications** like Ocean Market. With these apps, users can onboard services like data, alogrithm, compute-to-data into crypto (publish and mint data NFTs and datatokens), hold datatokens as assets (data wallets), discover assets and buy / sell datatokens for fixed or auto-determined price (data marketplaces), and consume data services (consume datatokens).
|
||||
- Below that are **libraries** used by the applications: Ocean.js (JavaScript library) and Ocean.py (Python library). This also includes middleware to assist discovery:
|
||||
- **Aquarius**: Provides metadata cache for faster search by caching on-chain data into elasticsearch
|
||||
- **Provider**: Facilitates downloading assets, DDO encryption and communicating with `operater-service` for Compute-to-Data jobs.
|
||||
- **TheGraph**: 3rd party tool
|
||||
Developers can utilize the libraries to built thier custom applications and marketplaces.
|
||||
- The lowest level has the **smart contracts** used by the libraries. They’re deployed on Ethereum mainnet, and other compatible networks. To see the list of supported networks click [here](/concepts/networks/).
|
||||
|
||||
The rest of this page elaborates.
|
||||
|
||||
## Datatokens & Access Control Tools
|
||||
## Data NFTs, Datatokens and Access Control Tools
|
||||
|
||||
The publisher actor holds the dataset in Google Drive, Dropbox, AWS S3, on their phone, on their home server, etc. The dataset has a URL. The publisher can optionally use IPFS for a content-addressable URL. Or instead of a file, the publisher may run a compute-to-data service.
|
||||
Data NFTs are based on [ERC721](https://eips.ethereum.org/EIPS/eip-721) standard. The publisher can use Marketplace or client libraries to deploy a new data NFT contract. To save gas fees, it uses [ERC1167](https://eips.ethereum.org/EIPS/eip-1167) proxy approach on the **ERC721 template**. Publisher can then assign manager role to other ethereum addresses who can deploy new datatoken contracts and even mint them. Each Datatoken contract is associated with one data NFT contract.
|
||||
Click [here](/concepts/datanft-and-datatoken/) to further read about data NFTs and datatokens.
|
||||
|
||||
ERC721 data NFTs represent holding copyright / base IP of a data asset, and ERC20 datatokens represent licenses to consume the data asset.
|
||||
|
||||
Datatoken represents the asset which the publisher want to monetize. The asset can be a dataset or an algorithm. The publisher actor holds the asset in Google Drive, Dropbox, AWS S3, on their phone, on their home server, etc. The publisher can optionally use IPFS for a content-addressable URL. Or instead of a file, the publisher may run a compute-to-data service.
|
||||
|
||||
In the **publish** step, the publisher invokes **Ocean Datatoken Factory** to deploy a new datatoken to the chain. To save gas fees, it uses [ERC1167](https://eips.ethereum.org/EIPS/eip-1167) proxy approach on the **ERC20 datatoken template**. The publisher then mints datatokens.
|
||||
|
||||
The publisher runs **Ocean Provider**. In the **consume** step, Provider software needs to retrieve the data service URL given a datatoken address. One approach would be for the publisher to run a database; however this adds another dependency. To avoid this, it stores the URL on-chain. So that others don’t see that URL, it encrypts it.
|
||||
The publisher runs their own **Ocean Provider** or can use one deployed by Ocean Protocol. In the **consume** step, Provider software needs to retrieve the data service URL given a datatoken address. One approach would be for the publisher to run a database; however this adds another dependency. To avoid this, Provider encrypts the URL and it URL on-chain.
|
||||
|
||||
To initiate the **consume** step, the data consumer sends 1.0 datatokens to the Provider wallet. Then they make a service request to the Provider. The Provider loads the encrypted URL, decrypts it, and provisions the requested service (send static data, or enable a compute-to-data job).
|
||||
|
||||
|
|
@ -59,9 +66,9 @@ Complementary to Ocean Market, Ocean has reference code to ease building **third
|
|||
Metadata (name of dataset, date created etc.) is used by marketplaces for data asset discovery. Each data asset can have a [decentralized identifier](https://w3c-ccg.github.io/did-spec/) (DID) that resolves to a DID document (DDO) for associated metadata. The DDO is essentially [JSON](https://www.json.org/) filling in metadata fields. For more details on working with OCEAN DIDs check out the [DID concept documentation](https://docs.oceanprotocol.com/concepts/did-ddo/).
|
||||
The [DDO Metadata documentation](https://docs.oceanprotocol.com/concepts/ddo-metadata/) goes into more depth regarding metadata structure.
|
||||
|
||||
[OEP8](https://github.com/oceanprotocol/OEPs/tree/master/8) specifies Ocean metadata schema, including fields that must be filled. It’s based on the public [DataSet schema from schema.org](https://schema.org/Dataset).
|
||||
[OEP8](/concepts/did-ddo/) specifies Ocean metadata schema, including fields that must be filled. It’s based on the public [DataSet schema from schema.org](https://schema.org/Dataset).
|
||||
|
||||
Ocean uses the Ethereum mainnet as an **on-chain metadata store**, i.e. to store both DID and DDO. This means that once the write fee is paid, there are no further expenses or dev-ops work needed to ensure metadata availability into the future, aiding in the discoverability of data assets. It also simplifies integration with the rest of the Ocean system, which is Ethereum-based. Storage cost on Ethereum mainnet is not negligible, but not prohibitive and the other benefits are currently worth the tradeoff compared to alternatives.
|
||||
Ocean uses the Ethereum mainnet and other compatible networks as an **on-chain metadata store**, i.e. to store both DID and DDO. This means that once the write fee is paid, there are no further expenses or dev-ops work needed to ensure metadata availability into the future, aiding in the discoverability of data assets. It also simplifies integration with the rest of the Ocean system, which is Ethereum-based. Storage cost on Ethereum mainnet is not negligible, but not prohibitive and the other benefits are currently worth the tradeoff compared to alternatives.
|
||||
|
||||
Due to the permissionless, decentralized nature of data on Ethereum mainnet, any last-mile tool can access metadata. **Ocean Aquarius** supports different metadata fields for each different Ocean-based marketplace. Developers could also use [TheGraph](https://www.thegraph.com) to see metadata fields that are common across all marketplaces.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,64 @@
|
|||
---
|
||||
title: Data NFTs and Datatokens
|
||||
description: In Ocean Protocol, ERC721 Data NFTs represent holding copyright / base IP of a data asset, and ERC20 datatokens represent licenses to consume the data asset.
|
||||
---
|
||||
|
||||
A non-fungible token stored on the blockchain represents a unique asset. NFTs can represent images, videos, digital art, or any piece of information. NFTs can be traded, and allow transfer of copyright / base IP. [EIP-721](https://eips.ethereum.org/EIPS/eip-721) defines an interface for handling NFTs on EVM-compatible blockchains. The creator of the NFT can deploy a new contract on Ethereum or any Blockchain supporting NFT related interface and also, transfer the ownership of copyright / base IP through transfer transactions.
|
||||
|
||||
Fungible tokens represent fungible assets. If you have 5 ETH and Alice has 5 ETH, you and Alice could swap your ETH and your final holdings remain the same. They're apples-to-apples. Licenses (contracts) to consume a copyrighted asset are naturally fungible - they can be swapped with each other.
|
||||
|
||||
|
||||
|
||||
|
||||
## High-Level Architecture
|
||||
|
||||
The image above describes how ERC721 DataNFTs, ERC20 datatokens, and AMMs relate.
|
||||
|
||||
- Bottom: The publisher deploys an ERC721 dataNFT contract representing base IP for the data asset. They are now the manager of the dataNFT.
|
||||
- Middle: The manager then deploys an ERC20 datatoken contract against the dataNFT. The ERC20 represents a license with specific terms like "can consume for the next 3 days". They could even publish further ERC20 datatoken contracts, to represent different license terms or for compute-to-data.
|
||||
- Top: The manager then deploys a pool of the datatoken and OCEAN (or H2O), adds initial liquidity, and receives ERC20 pool tokens in return. Others may also add liquidity for receive pool tokens, i.e. become liquidity providers (LPs).
|
||||
|
||||
|
||||
## Terminology
|
||||
|
||||
- **Base IP** means the artifact being copyrighted. Represented by the {ERC721 address, tokenId} from the publish transactions.
|
||||
- **Base IP holder** means the holder of the Base IP. Represented as the the actor that did the initial "publish" action.
|
||||
- **Sub-licensee** is the holder of the sub-license. Represented as the entity that controls address ERC721.\_owners[tokenId=x].
|
||||
- **To Publish**: Claim copyright or exclusive base license
|
||||
- **To Sub-license**:Transfer one (of many) sub-licenses to new licensee: ERC20.transfer(to=licensee, value=1.0)
|
||||
|
||||
## Implementation in Ocean Protocol
|
||||
|
||||
Ocean Protocol defines the [ERC721Factory](https://github.com/oceanprotocol/contracts/blob/v4main/contracts/ERC721Factory.sol) contract, allowing **Base IP holders** to create their ERC721 contract instances on any supported networks. The deployed contract stores Metadata, ownership, sub-license information, permissions. The creator of the contract can also create and mint ERC20 token instances for sub-licensing the **Base IP**.
|
||||
|
||||
ERC721 tokens are non-fungible, thus cannot be used for automatic price discovery like ERC20 tokens. ERC721 and ERC20 combined together can be used for sub-licensing. Ocean Protocol's [ERC721Template](https://github.com/oceanprotocol/contracts/blob/v4main/contracts/templates/ERC721Template.sol) solves this problem by using ERC721 for tokenizing the **Base IP** and tokenizing sub-licenses by using ERC20. Thus, sub-licenses can be traded on any AMM as the underlying contract is ERC20 compliant.
|
||||
|
||||
## Roles
|
||||
|
||||
[ERC721Template](https://github.com/oceanprotocol/contracts/blob/v4Hardhat/contracts/templates/ERC721Template.sol) contract defines following roles:
|
||||
|
||||
### NFT Owner
|
||||
|
||||
- NFT Owner is the publisher. I.e. Owner is a public address which transacted with `ERC721Factory` contract and deployed a new `ERC721` contract.
|
||||
- NFT Owner can assign managers while deploying the contract.
|
||||
- NFT Owner is also added to the Managers.
|
||||
- NFT Owner can add/remove Managers.
|
||||
- Clean all permissions
|
||||
|
||||
### Manager
|
||||
|
||||
- A public address with a `Maganer` role can update the metadata
|
||||
- Can deploy new ERC20 contract which is associtated with the `ERC721` contract.
|
||||
|
||||
## High-Level Behavior
|
||||
|
||||
|
||||
|
||||
Here's an example. Alice has created a dataset. In step 1, she publishes her dataset with Ocean: this means deploying an ERC721 data NFT contract (claiming copyright / base IP), then an ERC20 datatoken contract (license against base IP). Then in step 2, she mints some ERC20 datatokens and transfers 1.0 of them to Bob's wallet; now he has a license to be able to consume that dataset.
|
||||
|
||||
## Other References
|
||||
|
||||
- [Data & NFTs 1: Practical Connections of ERC721 with Intellectual Property](https://blog.oceanprotocol.com/nfts-ip-1-practical-connections-of-erc721-with-intellectual-property-dc216aaf005d)
|
||||
- [Data & NFTs 2: Leveraging ERC20 Fungibility](https://blog.oceanprotocol.com/nfts-ip-2-leveraging-erc20-fungibility-bcee162290e3)
|
||||
- [Data & NFTs 3: Combining ERC721 & ERC20](https://blog.oceanprotocol.com/nfts-ip-3-combining-erc721-erc20-b69ea659115e)
|
||||
- [Fungibility sightings in NFTs](https://blog.oceanprotocol.com/on-difficult-to-explain-fungibility-sightings-in-nfts-26bc18620f70)
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 62 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 48 KiB |
|
|
@ -0,0 +1,37 @@
|
|||
---
|
||||
title: Data NFTs and datatoken roles
|
||||
description: The permissions stored on chain in the contracts control the access to the data NFT (ERC721) and datatoken (ERC20) smart contract functions.
|
||||
---
|
||||
|
||||
The permissions are stored in the data NFT (ERC721) smart contract. The data NFT (ERC721) and datatoken (ERC20) smart contracts both use this information to restrict access to the smart contract functions. The tables below list restricted actions that are accessible only to the allowed users.
|
||||
|
||||
## Roles in data NFT (ERC721) smart contract
|
||||
|
||||
| Action ↓ / Role → | NFT Owner | Manager | ERC20 Deployer | Store Updater | Metadata Updater |
|
||||
|-----------------------------------|--------------------|--------------------|--------------------|--------------------|--------------------|
|
||||
| Set token URI | | | | | |
|
||||
| Add manager | <center>🗸</center> | | | | |
|
||||
| Remove manager | <center>🗸</center> | | | | |
|
||||
| Clean permissions | <center>🗸</center> | | | | |
|
||||
| Set base URI | <center>🗸</center> | | | | |
|
||||
| Set MetaData state | | | | | <center>🗸</center> |
|
||||
| Set MetaData | | | | | <center>🗸</center> |
|
||||
| Create new Datatoken | | | <center>🗸</center> | | |
|
||||
| Executes any other smart contract | | <center>🗸</center> | | | |
|
||||
| Set new key-value in store | | | | <center>🗸</center> | |
|
||||
|
||||
## Roles in datatoken (ERC20) smart contract
|
||||
|
||||
| Action ↓ / Role → | ERC20 Deployer | Minter | NFT owner | Fee manager |
|
||||
|--------------------------------|--------------------------|--------------------------|--------------------------|--------------------------|
|
||||
| Deploy pool | <center>🗸</center> | | | |
|
||||
| Create Fixed Rate exchange | <center>🗸</center> | | | |
|
||||
| Create Dispenser | <center>🗸</center> | | | |
|
||||
| Add minter | <center>🗸</center> | | | |
|
||||
| Remove minter | <center>🗸</center> | | | |
|
||||
| Add fee manager | <center>🗸</center> | | | |
|
||||
| Remove fee manager | <center>🗸</center> | | | |
|
||||
| Set data | <center>🗸</center> | | | |
|
||||
| Clean permissions | | | <center>🗸</center> | |
|
||||
| Mint | | <center>🗸</center> | | |
|
||||
| Set fee collector | | | | <center>🗸</center> |
|
||||
|
|
@ -6,6 +6,12 @@
|
|||
link: /concepts/quickstart/
|
||||
- title: Architecture Overview
|
||||
link: /concepts/architecture/
|
||||
- title: Data NFT and Datatoken
|
||||
link: /concepts/datanft-and-datatoken/
|
||||
- title: Roles
|
||||
link: /concepts/roles/
|
||||
- title: DIDs & DDOs
|
||||
link: /concepts/did-ddo/
|
||||
- title: Supported Networks
|
||||
link: /concepts/networks/
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue