-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AIP: Non-fungible Token Standard #70
Comments
@Nigui Thanks for opening this issue, a maintainer will get back to you shortly! |
@faustbrian @supaiku0 - please review this in the next few days. Be sure to explicitly select labels so I know what's going on. If no reviewer appears after a week, a reminder will be sent out. |
Very nice work @Nigui ! |
Thanks @Nigui for the proposal, with very good content. Just a few remarks as i am reading:
|
Thx @boldninja and @fix. @fix:
Are you talking about AIP-29 ? |
AIP-29 yes but more abstract, AIP-29 is only about the transaction abstraction part. AIP-29 might move to this new AIP |
I like this idea of NFTs with ARK. It will bring more capabilities, powers and use cases to ARK technology, especially in gaming, an important sector. |
I've added Event section to comply with ERC721 proposal and updated token id type |
I've updated the proposal :
|
NEW Proposal update :
|
NEW proposal updates:
|
@Nigui thanks for the updates and good work on the AIP. With v26 on the mainnet horizon and as recently discussed, we can start to turn this into a PR, and add other specifics. The new transaction types will go nicely with the latest updates to v.26 GTI - Custom Transactions. A good example on how to structure the TransactionType specification would our AIP-102 - HTLC Specs where each transaction type has verify, apply and fees sections. |
@kristjank awesome !! 🎉 |
Stale issue message |
AIP: 33
Title: Non fungible token management
Authors: Guillaume Nicolas [email protected]
Status: Draft
Discussions-To: https://github.com/arkecosystem/AIPS/issues
Type: Standards Track
Category: Core
Created: 2019-02-11
Last Update: 2019-09-11
Abstract
While fungible tokens can be exchanged with each other without loss of value, non-fungible tokens are unique pieces with value based on their properties and scarcity.
It's a new way to digitize assets ownership like sports cards, game stuff, art pieces, houses, identities, ...
This AIP proposes to add a new feature for Ark framework: the non-fungible token support.
It leads to create new transaction types for token creation, transfer and properties values updates.
Motivation
This concept is born on Ethereum with the EIP 721 where the discussion was:
How can we standardize smart-contracts implementing non-fungible tokens, from the representation and transfer point of views ?
. The main goal was to ease tool creation (like exchanges) wherein multiple NFT classes could be traded, without the need to adapt to each token specificities.Now NFTs are very popular on blockchain platforms, Ethereum, Qtum, Stellar, Neo, EOS,...
This AIP differs from EIP 721, in the way that we want framework users to be able to configure NFT class, create, update and transfer on their custom chain, without editing core code, but simply with configuration files. It's continuity of
blockchain in one click
baseline.Specifications
Here are the terms used in this document:
non-fungible token
Note: vocabulary is arbitrary and can be updated with discussions
In this part, we focus on specifications for a simple NFT class, allowing mint (first-in-first-served and free), ownership transfer and properties values updates. We assume that NFT class is living alone on a dedicated chain (i.e the chain does not handle multiple ones).
Then, we describe a non-exhaustive list of token features we have to keep in mind during the design process.
Transactions
The advantage of NFTs is that you cryptographically own a token. As a consequence, a transaction is valid only if sender is the token owner.
In order to be able to handle NFTs, at three new transactions must be defined (types
9
and10
and11
).Three distinct transaction types is useful to :
Note: types number are arbitrary choices. They'll be increased to prevent conflicts with future types released before nft transactions.
> Mint (type 11)
The first thing to do to get a NFT is to create and broadcast a
mint
transaction.This transaction is responsible of writing on chain that a given wallet is the first owner of a token identified by a never used value.
Transaction sender will be the first NFT owner.
NFT must not be owned by a wallet before transaction application.
If properties are set, they must comply with their network constraints (More details below)
Transaction dedicated parameters
Transaction payload
Payload size is between 33 and 130 KB (type is a mandatory field of transaction header )
Design choices
token id
size (32 bytes) is an arbitrary choice inherited from ERC721 specifications identifying NFTs as the largest unsigned integer of the EVM:uint256
(256 bits). It also allows a wide variety of applications because UUIDs and sha3 outputs are of this size.mint
thentransfer
). It's a questionable design choice.> Transfer (type 9)
Transfer NFT ownership to another wallet.
Transaction sender must own the identified nft and recipient will be the new owner.
Transaction dedicated parameters
Transaction payload
Payload size is 53 bytes (type is a mandatory field of transaction header )
Design choices
Transfer
type is only used to transfer a token. You can't transfer and update properties with the same transaction.> Update (type 10)
This transaction type is used to add, update and delete properties of a NFT instance.
NFT must be minted and transaction sender must own NFT before application.
Each property must comply with its network constraints (More details below)
Transaction dedicated parameters
Transaction payload
Payload size is between 33 and 130 KB (type is a mandatory field of transaction header )
Design choices
properties length
is the number of updated properties. It must be positive. Size of the payload has been limited to 1 byte. As a consequence, the maximum number of updatable properties in a single transaction is (2^8)-1=255 properties.property key
is encoded in utf8 and can contain a maximum of 255 characters.property value
must be an output of the sha-256 function. It's a design choice used to limit the size of token properties value. We don't want blockchain to store a lot of crappy data, but prints of these crappy data stored elsewhere.Token id
andtoken owners
can't be updated with this transaction type.Token id
can't be updated at all.Token owner
can be updated with atransfer
transaction.Model
A new model must be created to represent an NFT instance:
Existing
Wallet
model must be extended to referenceowned tokens id
:Events
In order to be compatible with existing applications handling NFTs (exchanges, wallets,... ), we must provide a simple way to detect updates on NFTs.
Similarly to ERC721 proposal, we can broadcast events at several steps of NFTs life-cycle:
Core-webhooks
is the module forwarding events to applications.It's listening
event-emitter
events, so new blockchain events must be added:nft.created
nft.transferred
nft.updated
Database
We need to store tokens and their properties values in the database because of scalability. Indeed, store nfts and their properties in memory (like wallets) could cause performance issues and memory bursting.
A new repository and queries in
core-database-postgres
are required.API
We need new routes fetching NFTs from current chain state.
Here are some new routes, depending on your NFT name configuration:
<nft_name>
(see configuration file below)./<nft_name>s/
: to index all sealed NFTs. This route follows the same logic as other root routes (like/transactions
or/blocks
). It's paginated and returns all properties for each of your NFT./<nft_name>s/{id}
: to show NFT instance with given identifier/<nft_name>s/{id}/properties
: to get all properties of a NFT (paginated), a list ofkey-value
/<nft_name>s/{id}/properties/{key}
: to get value of a specific property of a NFT, designated by itskey
/wallets/{wallet_id}/<nft_name>s/
: to index all sealed NFTs for a specific wallet, designated by its public key or address. This route follows the same logic as/<nft_name>s/
.Existing routes:
/transactions/
: is used to submit a new NFT transaction (transfer or update).NFT dedicated plugin
In order to isolate NFT support feature, a new core plugin has been created, dedicated to NFT management.
This plugin has many roles:
NFT configuration file
A NFT must be configurable through
network.json
file because its properties are specific to a network and must be the same for all nodes validating nft transactions.A new property of
network
is created.Here is a configuration sample where chain hosts UNIK NFTs, which can have :
a
with only 2 possible number values (1
and2
).b
Please note the
<nft_name>
will be used to setup the API HTTP routes, sometimes also by adding a trailings
when pluralized.Example, for the UNS network, powering the
UNIK
NFT.NFT genesis property
A genesis property is a NFT property that must be set at NFT creation (in a
mint
transaction).If a NFT property has the (object) property
genesis=true
then, themint
transaction must includenft.properties
asset AND this property must have a value ( compliant with may exist constraints).If it doesn't, then transaction is rejected and NFT is not minted.
By default, a NFT property is not genesis.
NFT constrained property
A NFT property constraint is a set of rules a property value update of a NFT transaction (
mint
orupdate
) must obey in order to be applied and forged.It's composed by:
As an example, we could have an immutability constraint (
immutable
as identifier) which causes a property to not be updatable after being set.As an other example, we could have more abstract constraints like
type
which causes a property value to be of a specific type (number
,string
,... ).In that case, we could add constraints depending property type and value. In the example above, we set that property
a
must be anumber
between1
and2
.Constraint logic is implemented into
core-nft
plugin as a class which must implement theConstraint
interface:Each constraint must set a name and implement a check on nft property update transaction validity.
To check validity, a constraint has several information:
Bellow is an example of how
type
constraint could be implemented (voluntarily simplified):Constraint application must be made inside the
canBeApplied
method of nft-update transaction handler.Current proposal makes nft property constraint relatively easy to customize : register a new custom constraint logic to constraint manager and reference it directly from
network.json
file.Note 1:
network.json
is validated before used using schemes. When adding custom constraints, you must updatenetwork.json
scheme accordingly.Advanced token features
Here is a non-exhaustive list of behaviours and characteristics token class could specify, to keep in mind during the design process. They're inspired by existing ERC721 tokens. Some items could have a dedicated AIP in the future.
Reference Implementation
I'm working on
@unik-name
solution at Spacelephant and our product is based on NFTs.We've developed a proof-of-concept of Ark's NFT in our labs.
Project sources are available on the dedicated repository.
The text was updated successfully, but these errors were encountered: