ARC-0721: Aleo Non-Fungible Token Standard

[fulltimemike]

---

arc: 0721
title: Aleo Non-Fungible Token Standard
authors: fulltimemike, evanmarshall, JohnDonavon, dagarcia7
discussion: ARC-0721 Aleo Non-Fungible Token Standard
topic: Application
status: Draft
created: 2023-7-19

Abstract

NFTs on Aleo are uniquely positioned to provide a private minting experience, the basis for private identity authorization, and allow for unique collectibles where ownership does not have to be publicly broadcasted. Additionally, by having a standard for NFTs on Aleo, wallets in the ecosystem can support all contracts that implement the standard without having to build support for individual NFT collections. NFT contracts on Aleo have been popular so far, and a standard is needed to ensure uniform support across all collections.

The ethereum NFT standard could adopted fairly closely, as we could force all operations to happen in public state, however, we would rather see Aleo NFTs provide extra functionality that only a ZK L1 can provide.

This standard is meant to build on top of the foundation laid by ERC-721.

Specification

Required Architecture:

Required Structs

// NFTs must have a base folder in which their data contained with jsons are stored. The base uri struct contains 8-bit ASCII encoded text. Aleo instructions do not support strings, but NFTs need to have an accessible base uri to fetch information from.
// Different NFT projects may require more text or less text as necessary, so additional data properties can be added to the BaseURI to account for needed character length.
// The data for a base uri should be padded by 0s on the end of the struct, as 0 does not correspond to a valid ASCII character.
// An example of a BaseURI struct that matches google.com/: google.com/ to 8-bit ascii, padded with 0s on the end = 01100111011011110110111101100111011011000110010100101110011000110110111101101101001011110000000000000000000000000000000000000000
// As a u128 would be BaseURI { data1: 137489088058657146712104188238903640064u128 }

BaseURI {
  (required) data1: u128,
  (optional) data2: u128,
  .
  .
  .
  (optional) dataN: u128
}

// The token id struct is used with the base uri to provide a full url to a json representing the nft data. This structure should follow the base uri example as before, with the string text being 8-bit ASCII encoded, and padded with any extra 0s on the end.

TokenId {
  (required) data1: u128,
  (optional) data2: u128,
  .
  .
  .
  (optional) dataN: u128
}

Required Records

// In order to display all NFTs corresponding to this standard across wallets, a standard NFT record has to be adopted. The minimum information needed for an NFT is the owner; the data, which corresponds to the TokenId that uniquely identifies that NFT's information in the base uri folder; and the edition, which is the nth copy of the NFT. For completely unique collections, all the editions should be 0. If collections have duplicates, then the editions should increment by one.

record NFT {
  (required) owner: address,
  (required) private data: TokenId,
  (required) private edition: scalar,
}

Required Mappings

// In order to hold NFTs in public state, we need a mapping between a representation of each unique NFT and the address of the NFT owner. Multiple NFTs can be owned by the same address, so address cannot be the key. The field key must be a bhp:256 commitment to a hash of the TokenId and edition scalar.

mapping nft_owners: field => address;

// In order to hold the base uri in public state, we need a mapping that corresponds to all of the pieces of the base uri. By having the base uri in a publicly accessible mapping, the amount of data required to be held in each individual NFT record is lessened, and the base uri is tied to the program. The base uri can be updated.
mapping base_uri: u8 => u128;

Required Functions

// In order to keep track of a user's public state, there must be a standard function for converting potentially private NFT records to public state. In this way, we can follow the blockchain history to associate a given TokenId and edition that went from private to public. In the following function, the input to the finalize is the owner address of the nft, as well as the unique field that identifies that NFT. This field must be calculated in a standardized way, in order for wallets and rpcs to keep track of which unique field identifier corresponds to which tokenId + edition. In other words, we need a reverse mapping off-chain to associate these fields with NFTs.

transition convert_private_to_public(
  (required) nft: NFT
)
{
  let tokenHash: field = BHP256::hash_to_field(nft.data);
  let tokenEditionHash: field = BHP256::commit_to_field(tokenHash, nft.edition);
  (required) return then finalize((required)nft.owner, (required)tokenEditionHash);
}

// In this finalize block, the owner address and unique identifying NFT field are necessary, and the mapping for nft_owners must be set.

* finalize convert_private_to_public(
  (required) public owner: address,
  (required) public tokenEditionHash: field
)
{
  (required)nft_owners.set(tokenEditionHash, owner);
}

// In order to keep track of which unique NFT belongs to the public state, a standard function for public transference must be adopted. The receiver address and the NFT data (tokenId + edition) are necessary inputs, so that wallets and rpcs can associate a given NFT with the finalized mapping values in nft_owners.

transition transfer_public(
  (required) private receiver: address,
  (required) private data: TokenId,
  (required) private edition: scalar
)
{
  let tokenHash: field = BHP256::hash_to_field(data);
  let tokenEditionHash: field = BHP256::commit_to_field(tokenHash, edition);
  let caller: address = self.caller;
  return then finalize(receiver, tokenEditionHash, caller);
}

finalize transfer_public(
  public receiver: address,
  public tokenEditionHash: field,
  public caller: address
)
{
  assert_eq(caller, nft_owners.get(tokenEditionHash));
  nft_owners.set(tokenEditionHash, receiver);
}

// In order to prove that you own an NFT without revealing which NFT, we introduce a novel function + finalize construct. Calling this "burn" function will only work if you indeed own the record, which will allow an inclusion proof to be generated and shared off-chain without actually burning the record, as the finalize body is guaranteed to fail.

transition authorize(
  nft: NFT
)
{
  return then finalize();
}

finalize authorize(
)
{
  // fails on purpose, so that the nft is not burned.
  assert_eq(0u8, 1u8);
}

The ERC-721 standard allows for issuing approvals to addresses to be able to control an NFT. In Aleo, this could be done by maintaining a mapping of approved addresses to the unique identifying field for an NFT. This would allow programs to manage public NFTs, which may be necessary for swaps and escrow type contracts. As a community, we should decide whether or not approval issuance is a requirement for the NFT contract standard. The self.parent ARC (https://github.com/AleoHQ/ARCs/tree/master/arc-0030) has been added, so we should consider that this is an available method to add for this ARC.

Optional:

This section is a collection of ideas and features that NFT contracts meeting the above standard can provide.

NFTs can have a symbol associated with them. The privacy pride symbol is LION.

struct SymbolBits {
  data: u128 // The sybmol's ascii text represented in bits, and the u128 value of the bitstring.
}

Public minting:
NFTs can be publicly minted using the concept of a whitelist that holds addresses in public state, and only allows those addresses to mint the NFT when minting is allowed. link example to privacy pride program

Private minting:
NFTs can be privately minted by issuing minters a claim record which a finalize block associates with a given NFT, thereby taking it out of the mintable NFT set. Then, the claim record owner can spend their claim record to redeem the NFT record that was set aside for them, which allows them to privately mint the NFT without revealing whom they are.

Private whitelist minting:
Whitelist records can be issued to minters, who must spend that whitelist record in order to mint.

Toggleable Settings:
Public mappings that maintain setting values can be a part of the contract, and can allow for unique behavior, such as:

• only allowing minting past a certain block height
• maintaing a set of collection owners, who can control the contract's general settings.
• whitelist: The requirement that only certain addresses can mint.
• freeze: Freezing the contract prevents any further minting, nft-adding, and settings updates.
• turning on the mint: The setting to allow the nft mint to proceed. This is a requirement that can be combined with the mint block requirement.
• sky's the limit -- you can require any number of specific records to be in possession, limit the number of NFTs minted or issued to any given address, and more.

Reference Implementations

Implementation for a public whitelist mint: https://github.com/demox-labs/art-factory/blob/v3/program/src/main.leo
Implementation for a private optional whitelist mint: https://github.com/demox-labs/art-factory/blob/v4/program/src/main.leo

Dependencies

As this is an application ARC, there are no dependencies other than what is currently available in Aleo, as well as ARC-30, if we want to include allowance issuances.

Backwards Compatibility

Not necessary.

Security & Compliance

This is an application ARC standard, so this only affects the security of managing assets on-chain. As the standard NFT contract, i.e. a pseudo-interface that must be implemented, there are not enough requirements to guarantee safety of NFTs for any given asset owner. Safety and compliance will be on a contract-by-contract basis.

References

https://eips.ethereum.org/EIPS/eip-721
https://github.com/AleoHQ/ARCs/tree/master/arc-0030
https://github.com/demox-labs/art-factory

[fulltimemike]

As an aside, if the string literal support is definitely going to be added, then instead of doing ascii encoded u128s, we should definitely change this ARC to use strings.

[kespinola]

I come from Solana and have some recommendations based on my past 2 years of working on NFT infrastructure for that blockchain.

1. In the discussion of private to public can share what are the current methods for "following blockchain history" on Aleo? My team and I built the original NFT indexer for Solana so curious on what tooling exists on Aleo for following transactions in real-time and replaying block history.

In order to keep track of a user's public state, there must be a standard function for converting potentially private NFT records to public state. In this way, we can follow the blockchain history to associate a given TokenId and edition that went from private to public.
In other words, we need a reverse mapping off-chain to associate these fields with NFTs.

2. Like ERC-721 is each deployment of the NFT contract meant to represent the collection? Collections are critical construct IMO and should be included in the NFT standard. If this program is meant to function like the token-metadata program on Solana which means all NFTs for aleo are managed by a single program then I recommend extending this proposal to have public mapping for looking up collection structs. NFT should have a field to associate it to a collection. All nfts belonging to a collection should be easy to discover on chain.

3. Though there are valid use cases for editions I think their usage is niche and should be mimicked by duplicating metadata json instead of a construct in the standard. Folks may disagree which I can respect but again my opinion.

4. Agree. delegation of control over the NFT is critical its been a powerful construct for Solana NFTs where owners can place their NFT for sale without transferring the NFT to an escrow wallet.

The ERC-721 standard allows for issuing approvals to addresses to be able to control an NFT. In Aleo, this could be done by maintaining a mapping of approved addresses to the unique identifying field for an NFT.

5. Thoughts on toggleable settings:
   Freezing the contract is good for signaling to owners/traders that there will be no tampering by the founders of the collection. Any mechanic around control when and how mints are distributed should be handled by another purpose built contract. Instead collections should be able to delegate their distribution to another contract so unique experiences can be composed without needing to be configured in a monolithic contract.

Though I think its good to look at ERC-721 and see if it can if Aleo can implement it. I don't think its what mainstream adoption requires. Instead of thinking in terms of tokens we need to think about assets both digital and real world. How can Aleo be used to represent a verity of asset types and provide a decentralized marketplace for selling, transferring, and governing ownership over such assets.

Appreciate the proposal and looking forward to hearing others thoughts.

[fulltimemike]

Hey @kespinola, thanks for the discussion comments. I'll try to address all your points:

1. In the discussion of private to public can share what are the current methods for "following blockchain history" on Aleo? My team and I built the original NFT indexer for Solana so curious on what tooling exists on Aleo for following transactions in real-time and replaying block history.

I don't believe there are standardized ways of following blockchain history yet. Mappings' histories are not supported via API calls to the Aleo endpoint, but I know Haruka's explorer supports replaying public transactions to simulate history. We are planning on adding full mapping history as an endpoint in the Leo Wallet RPC.

That being said, you can follow public transitions to see blockchain history, which is why the conversion of private NFTs to public NFTs is useful. And for simulated or actual history, some public information will have to be known.

2. Like ERC-721 is each deployment of the NFT contract meant to represent the collection? Collections are critical construct IMO and should be included in the NFT standard. If this program is meant to function like the token-metadata program on Solana which means all NFTs for aleo are managed by a single program then I recommend extending this proposal to have public mapping for looking up collection structs. NFT should have a field to associate it to a collection. All nfts belonging to a collection should be easy to discover on chain.

Each deployment of the contract should represent the collection, and not be a metadata program that all NFTs are deployed through. The self.parent arc has been accepted and should be implemented for composability. This will prevent the necessity of a single mega contract that controls all NFT collections.

3. Though there are valid use cases for editions I think their usage is niche and should be mimicked by duplicating metadata json instead of a construct in the standard. Folks may disagree which I can respect but again my opinion.

I'm also open to opinions on whether edition should be kept or dropped. It might be enough to mark it as optional.

5. Thoughts on toggleable settings:
   Freezing the contract is good for signaling to owners/traders that there will be no tampering by the founders of the collection. Any mechanic around control when and how mints are distributed should be handled by another purpose built contract. Instead collections should be able to delegate their distribution to another contract so unique experiences can be composed without needing to be configured in a monolithic contract.

I like the approach to modularizing and separating responsibilties of the contract. These methods were included to show optional additions to NFT contracts that could be added. The mandatory methods are, from the Leo Wallet perspective, what is critical for us to display and handle NFTs in a standard way. Beyond that, we don't want to limit the uniqueness of functionality that an NFT contract could create.

Though I think its good to look at ERC-721 and see if it can if Aleo can implement it. I don't think its what mainstream adoption requires. Instead of thinking in terms of tokens we need to think about assets both digital and real world. How can Aleo be used to represent a verity of asset types and provide a decentralized marketplace for selling, transferring, and governing ownership over such assets.

ERC-721 has been a popular standard, and is a piece of DeFi that I think the Aleo chain should have. The Aleo spin on these NFTs is that they are zkNFTs, so their ownership is not necessarily public to everyone, unless the holder decides to make that public. What we see as a really unique piece of functionality is being able to prove ownership of a piece of NFT collection without revealing who you are or which NFT you own. With the ZK proof chain, that's now possible.

[pa-long]

Here is an implementation of such a single program NFT standard. As it was necessary to make a functioning NFT marketplace as of right now.