
DICG ’22, November 7, 2022, ebec, QC, Canada Leonhard Balduf, Martin Florian, and Björn Scheuermann
smart contract interfaces. These interfaces govern identication and
ownership of
NFT
s, including transfer thereof, as well as association
of storage uniform resource identiers (
URI
s) to tokens, via optional
metadata extensions.
Listing 1 shows an excerpt of the commonly used
ERC721Metadata
extension interface. The interface is used to attach a
URI
for de-
scriptive metadata to tokens. The standard recommends that the
metadata is a
JSON
document with a name, a description, and an
image. Commonly, the per-token metadata
URI
is constructed on-
the-y from a base
URI
and the numerical token ID, in order to save
on-chain storage. Audiovisual content, if any, is referenced via a
URI
within the metadata document. EIP721 provides no guidelines
on how or where to store referenced content. We investigate plausi-
ble techniques and the approaches that popular
NFT
s projects take
in the upcoming Sec. 2.
i n t e r f a c e ERC721Metadata {
...
f u n c t i o n t oken URI ( u i n t 2 5 6 _ t o k e n I d )
[ . . . ] r e t u r n s ( s t r i n g ) ;
}
Listing 1: The ERC721Metadata Interface.
The more recent
ERC1155
interface allows tracking multiple
distinct fungible and non-fungible tokens in one contract. For
NFT
s,
this behaves exactly like
ERC721
by using multiple tokens that each
have a total supply of one. An extension to assign metadata exists
for
ERC1155
as well:
ERC1155Metadata_URI
. Here, the metadata
must be a
JSON
document with a predened set of required keys.
An example is given in Listing 2.
{
" name " : " A s s e t Name " ,
" d e s c r i p t i o n " : " Lorem ipsum . . . " ,
" image " : " h t t p : / / examp le . com / { i d } . png " ,
" p r o p e r t i e s " : { . . . }
}
Listing 2: An example EIP1155 Metadata File.
It is noteworthy that a single contract, regardless of whether it
implements
ERC721
,
ERC1155
, or both, can track multiple collections
of
NFT
s. The notion of grouping multiple tokens into a collection
can exist on a contract-level, but is usually tracked on a higher level,
i. e., on NFT marketplaces.
2.2 Discovering Popular Digital Art NFTs
We obtained a list of the top 1000 most popular
NFT
s on the
OpenSea marketplace. We used “last sale price” as a proxy for
popularity and extracted the ranking from OpenSea on August 1st
2022. OpenSea is the most popular
4NFT
marketplace and thus
well-suited for our initial sample collection.
From our initial list of popular
NFT
s, we proceeded to extract
all
NFT
s associated with digital art. In a classication approach
inspired by previous works such as [7], we label each
NFT
as digital
4by trading volume, according to DAppRadar, see https://dappradar.com
that art that has the primary purpose of referencing one or more
audiovisual assets. We explicitly exclude gaming and metaverse
NFT
s from this class, as well as utility tokens more generally. 786
NFT
s from our sample t this classication
5
. They are managed
by a total of 51 smart contracts, many of which represent
NFT
collections with multiple representatives within our sample. The
subsequent discussion is based on these 786 NFTs.
2.3 Metadata and Asset Storage
We proceed to classify digital art
NFT
s in our sample based on
the storage system they use for storing metadata and assets. We
collected data stored in the
NFT
smart contracts, e. g., data exposed
through the EIP721 or EIP1155 standards, and manually inspected
custom contract implementations for data stored on-chain.
Motivated by the goal of digital art preservation, we rst identify
what data is necessary to reconstruct the artwork. For example,
generative art projects may choose to store source code on-chain,
and provide a pre-rendered version of the artwork on cloud storage
for convenience. We classify this case as being stored on-chain,
since reconstruction from on-chain data is possible. It is potentially
necessary to also preserve a runtime environment for this data, but
this falls outside the scope of this work.
We dierentiate between three main storage approaches: cloud
storage, on-chain storage, and decentralized storage systems —
IPFS
and Arweave. Their properties with regards to integrity and
availability vary greatly:
•Cloud storage
oers no hard guarantees — stored data can
be mutated or (re)moved at any time.
•On-chain storage
guarantees result directly from the secu-
rity properties of the underlying blockchain system. Data
availability and data integrity are among the core features
of permissionless blockchain systems and it is a reasonable
assumption that popular systems like Ethereum will remain
intact — and eective at providing availability and integrity
for stored data — for many years to come.
•Decentralized storage systems
can have varying prop-
erties with regards to integrity and availability. The sys-
tems used by the digital art
NFT
s in our sample rely on
cryptographically-generated content identiers: links into
these storage systems correspond to cryptographic hashes
of the stored content. In eect, changes to the original con-
tent can be detected as long as the integrity of the
URI
of
the asset is maintained. The availability of content stored
in decentralized data storage systems is highly dependent
on system particularities and the popularity of the stored
content. In the upcoming Sec. 4, we report on a deeper in-
vestigation into how the
NFT
s in our sample are inserted
into the popular IPFS network, and to what extent they are
replicated there.
The results of our classication are shown in Table 1. To our
surprise, the metadata and assets of more than half of our sampled
digital art
NFT
s are already stored on-chain. This is partly due
to our manual inspection of contracts, which reveals that various
generative art projects store their source code on-chain in addition
5
In addition, we classify
179 NFT
s as metaverse-related,
19
as game-related,
8
as
collectibles, and 8as utility tokens.