Menu
The Chia Plot
  • Blog
  • How-To
  • About
  • Contact
  • Security
  • Discord
The Chia Plot
art gallery

Why I think on-chain NFTs are simply better

Posted on January 27, 2022 by Chris Dupres

Recently there has been some controversy in the Chia community over the Space Marmots decision to publish their NFTs directly to the blockchain. Bram Cohen himself was asked about it in a Twitter space and said “Just don’t do it”. I think that is a attitude born of not understanding the problem, which I am going to explain here. Buckle up, because this is going to be a long one.

The ‘tl;dr’ of the entire argument is that the only way to prevent coherence issues of the asset – one portion available and the other not – is to keep them in the same place, the blockchain. An NFT is normally consistent of two pieces; the underlying asset (the picture, document, or song being tokenized) and the signed URI on the blockchain – the token itself. For most NFTs the token on the blockchain contains the unique signatures and code that make it an NFT along with a pointer to a file on an external service. That service can range from a web server somewhere, to an IPFS address hosted by multiple nodes (hopefully), to a blockchain storage service like Arweave or Filecoin. These produce different levels of risk that the NFT’s underlying asset will disappear but all of them have a different risk profile than the blockchain hosting the token that gets traded.

Running storage is hard. I have made this point before that running large amounts of storage comes with unique problems that don’t crop up when running a Chia farm the size of mine. But even harder than running lots of storage is running any amount of storage for a LONG time. And keeping storage accessible and available online for a long time is even harder.

Think about how files were stored 50 years ago. In 1971 / 1972 the very first floppy disks hit the market – coincidentally with about 175KB of usable space, exactly the same as we gave ourselves for testing the on-chain Marmots.

So for this thought experiment we put 120KB of Marmot on one of these brand new, cutting edge floppy disks. But this isn’t the kind of floppy disk you are thinking of, the 5 1/4 or 3 1/2 inch varieties. No, this is an 8″ floppy disk that even I have only seen in museums. So if it isn’t moved to a 5 1/4″, and then a few years later a 3.5″ floppy, there will soon be nothing that can read our 1972 Marmot JPG (the JPEG file format would not be invented for 20 more years, but you get my point). Or we can put in on one of the ancient hard drives they had back then. But those weren’t hard drives the way we know them, they were more like fixed reels of magnetic tape. Storage has changed a lot in 50 years.

So because of the rapid nature of technology we would spend the 70s and 80s and 90s moving our Marmot around from storage medium to storage medium until it ended up on an IDE hard drive – something recognizable to computing enthusiasts. But that wouldn’t be final resting place. There are very few IDE spinning hard drives left alive from the early days, and probably none that have been actively in use since the late 80s. So a human person with a paycheck needs to keep moving that file. From storage location to storage location until today it is sitting on cloud storage managed by a huge company.

But even storage managed by huge companies online has to be actively managed. And someone needs to pay for that active management. While there might be 20 year old web sites still around with all the same content they had at the beginning, there aren’t many and almost none of them would be running on the original hardware they started on. They would have required expensive and risky migrations, with teams of people planning and executing. They would be running on entirely new software platforms, and would have needed active human involvement to keep them compatible with the modern web. And hard drives simply do not last that long, so the data on them needs to be kept redundant with backups, and tests of those backups to ensure that it stays viable. More human-hours.

Now, a lot of this process is automated at this point and files stored on cloud storage are a lot easier to keep safe than files stored on an 8″ floppy in 1972 but its not perfect or free. So imagine our Marmot JPG from 1972 that has survived over a dozen medium transfers so far and how it will spend the next 50 years once it ends up in the cloud.

First, someone is paying the bills for that storage account. Almost certainly the original creators of the NFT or a service they paid to do that for them. And that is an active process. No cloud storage provider offers a “pay us X dollars and we will host your files exactly as-is in perpetuity”. You pay by the second, the month, or the year. So the first risk is that someone just stops paying the bills and Amazon or MS or Google just shuts it off. And that assumes that the cloud provider is still even in the same business in 50 years as they are today. None of these companies existed in 1972. Microsoft is the oldest of them and is only 47 years old and certainly did not think they would end up the business of cloud computing when they started. Obviously. So the second risk is that the cloud provider simply stops hosting your data.

And this is not a mitigatable risk once an NFT has been minted using that data as an underlying asset as the pointer in the NFT cannot be changed. Even if that pointer points to a cloud provider simply hosting an IPFS node with multiple nodes on different cloud providers (a very reliable architecture) a human person or system of them will still need to manage that process long term. Keep those IPFS nodes up. Create new ones as necessary. Update them, and move them to more modern platforms ad nauseum. None of this just happens on its own. And even if, somehow, for the next 50 years somebody does do all that work, and pays those bills there is the protocol problem. Does anyone still use IPFS in 50 years? Possibly not. Remember AFS? The Andrew File System? You probably don’t, even though it was a very popular distributed file system in the 80s and 90s. The reason I mention it is I worked somewhere with a very large, old AFS network and keeping old files available and in good condition was hard, and took a lot of work. And it wasn’t perfect, stuff would get lost or damaged over the years and need restoration from backup and truly active management.

This is important because neither cloud providers nor IPFS nodes have a perfect track record for keeping files secure. Good records, sure. But not perfect. And none of them have been around as long as the AFS network I worked on. And good luck plugging into that AFS network now for modern data access. I am sure they have since moved away from it entirely through another costly migration. So the idea that it is certain that currently running storage solution will be exactly as-is and unchanged enough so that the URI in an NFT pointing to it continues to work is a huge stretch. No one can know that, and if anything history leans against it.

All these risks add up and compound over the years. But through all this there is another component that needs to be accessible for any of it to matter – the NFT itself, the string of code written into the blockchain and shared amongst every node and constantly verified. If the blockchain goes away then it doesn’t matter if the underlying file survives, the NFT is gone. So that presents us with a unique opportunity to sidestep the question of coherence entirely and give both parts of the asset the same risk profile – blockchain storage.

Now, blockchains are meant to store data. That’s what they do. Normally this data is long strings of hashes representing chain state, and coins and transactions and wallet addresses. With “smart chains” like Chia, or Ethereum, they also store code that is executed when transactions interact with them. This is all just data storage, so the argument isn’t whether data should be stored on the blockchain, its about which data should be stored there.

To a lot of people NFT assets aren’t valuable enough and that is where the main disagreement comes in, because value is not an objective measurement; value is subjective to the beholder. Clearly people are spending upwards of a million US dollars on these things and so value them greatly. I think to those people, who are equal participants to the public block chain, storing their asset as permanently and securely as possible is worth the block space.

The argument against is that by storing it there you are “forcing” thousands of nodes to store and replicate that image forever. And you are, that is the point. Because without that there is no way to ensure that the image data will last as long as the pointer. This argument can apply to anything, any transaction or smart contract. Everyone is forced to store of all it on full nodes because that’s how a distributed, permissionless database works.

I predict that in the next few decades, if NFTs are not just a passing fad, the 404 error that begins to plague popular NFTs as the underlying images go offline is going to become a gigantic issue. Assets currently worth millions will be instantly worth nothing as there is no value in holding ownership to a dead link. And the fact that the assets are worth millions does nothing to incentivize all the work it is going to take to move around and keep online those images over the decades. Its not the original creators, who will all die at some point, who need the assets to stay online it is the people who eventually own them. For the most popular projects this will take a while, and effort will be put into it. But how many companies are still around and doing the same thing from the 1600s? Meanwhile, we have art from the 1600s still and its VERY valuable. Because it survived.

If NFTs truly are another long term stage of art creation, like many expect them to be, then I think they must be stored together – pointer and asset – otherwise the risk makes them ephemeral data and should not be treated as permanent. But NFTs stored on-chain will last as long as the chain itself. For the Space Marmots stored on Chia those will last, intact, as long as Chia itself does. And Chia plans to be around a long time.

Related

16 thoughts on “Why I think on-chain NFTs are simply better”

  1. John says:
    January 27, 2022 at 10:36 am

    I am not sure how most NFTs work currently, but why wouldn’t it be enough to simply store an hash of the file (could be an image/mp3/video, you name it) in the blockchain? The blockchain is not for storing data but for keeping track of who owns what.

    If I buy an NFT, I just need to make sure to store the file as a backup myself somewhere. There could be online hosting services were one could upload the file. NFT galleries will link to one of those services by the file hash specified in the NFT.

    That way it does not matter if the hosting service goes down in a few years. I can simply upload the file to a new hoster. Since the file hash is always the same, the new hoster can quickly verify the NFT. Buyers could download the file and verify the hash themself.

    That way you could make NFTs out of every file, even a 60GB 4K movie. You don’t even need to upload the file, if you don’t care about galleries.

    Reply
    1. Chris Dupres says:
      January 27, 2022 at 10:39 am

      Except no one self stores their NFTs because how would the NFT point to them? An NFT stores a URI for an online location of an NFT. That has to stay the same, unchanging, for the NFT to work. A hash of a file you control is meaningless if you move it around or make it inaccessible. You should just sign the file then.

      Reply
      1. John says:
        January 27, 2022 at 10:46 am

        Like I said, there could be online hosting services which let you request the NFT file by file hash. There could be many of them. If you want to sell or show your NFT, simply make sure to upload the file to one of the providers, which most galleries and marketplaces currently use.

        Reply
        1. Chad says:
          January 27, 2022 at 6:45 pm

          What you’re describing John is IPFS and it’s used widely for NFTs for the exact reason you are describing. The IPFS uri is the hash of the file itself. This means that if your valuable NFT asset is addressed via IPFS you can keep a copy of the file itself and then if the file disappears from the IPFS network you can provide it to the network yourself. If a collection gains value and is appreciated there will be many such copies serving the IPFS network.

          Reply
          1. John says:
            January 28, 2022 at 3:26 pm

            That you can re-upload missing files to IPFS and in that way re-enable the URI is amazing. Thank you for the explanation!

      2. Chad says:
        January 27, 2022 at 8:44 pm

        Chris, just read your IPFS article and I think you may be mis-understanding IPFS CIDs. They are not a hash of the location of the file, they are a hash of the contents of the file itself. (There are some other details.. but for all intents and purposes they are the hash of the file). It’s only when you appreciate this detail, that the uri is content addressing and not location addressing, that you appreciate the value for NFTs. This means that if the file disappears from the IPFS network anyone with that same file can add it back to the network and the old uri will continue to work. What John is describing works right now for any NFTs that have an IPFS cid as the uri.

        Reply
        1. Chad says:
          January 27, 2022 at 10:09 pm

          Take BAYC as an example. The ERC-721 has a baseURI which points to a folder on IPFS that contains a json file for each tokenId. Anyone that has an invested interest insuring that BAYC still exists (the creators, any individual owner, a gallery etc.) can run their own IPFS node and pin that same folder, or just pay a pinning service a small yearly fee to do so, thereby each and every person could provide their own redundancy for everyone else. The same is true for each tokens image. Even if everyone lost interest for a time, if that folder and those images where still stored somewhere as json and jpgs respectively, anyone could re add them to the IPFS network and the URI’s would all begin working again.

          Reply
        2. Chris Dupres says:
          January 28, 2022 at 7:27 am

          You are correct I am going to add a note to the article

          Reply
  2. f00b4r says:
    January 27, 2022 at 11:25 am

    Absolutely, and you should use svg format that scales well in size and is usually much smaller than raster images!

    Reply
  3. nunomiguelluis says:
    January 27, 2022 at 11:47 am

    Your point that putting ALL the data to re-generate entirely a given token on a decentralized blockchain (together with the hash) is the most secure way possible to store something is valid, but it lacks context. This is not possible to be done with larger sets of data, nor it is scalable at all…

    It can be done only in this early state of low (close to zero in USD) transaction fees on Chia, and it surely proves the point that it should not be done at all. It’s totally a vanity project. As such, the amount of talk around it (plus this blog) just attracts more attention to it, and possibly copy-CATS who would want to achieve the same, which is not the way to go… If suddenly the talk around Chia becomes “you can puts the entire NFT on chain, that’s great”, that’s really bad, because the next point to be made is that is not scalable, nor the best way to do something. You end up with a negative perspective on the whole thing by implying that something is possible, to then realise that it isn’t (for others that would follow).

    Let’s be realistic and make the point that yes, if you are purist, NFTs on chain is best of the best possible to store, but there are way better ways to do it, almost nearly as safe regarding storage of the data + hash (not the same, but close enough). I think it is an important caveat to mention.

    By the way, what stops someone that buys an NFT to keep in their possession the corresponding (image) file, whose authenticity with keys of owner, can be proved on chain? If I can trust myself to keep my keys safe, I should be able to save a copy of my precious image file somewhere in case the other copies online disappear at some point, right? (this is an honest question, as it seems there are easier solutions around this…).

    Reply
  4. Ronski says:
    January 28, 2022 at 10:50 am

    Have you taken a look at the size of a decent quality picture, it’s a lot more than 175KB, and if it’s compressed down to that size image quality is poor, unless it’s small to start with. No idea if you can store more, but imagine how the size of the blockchain file would expand if everybody started storing pictures in it, it’s getting pretty big already, not to mention hundreds of thousands of copies of the same picture, that’s hardly environmentally friendly.

    Reply
  5. Andy S. says:
    January 29, 2022 at 10:49 am

    Nobody thought about the way how singleton in Chia mining works?
    You create singleton on chain, you hold private keys, and can update singleton (invalidate the old one and create new, updated one) according your needs (i.e. switching pools.) Why not make URI (of the real NFT storage location) updatable the same way, how am I switching pools in NFT mining?

    Reply
    1. Chris Dupres says:
      January 29, 2022 at 11:00 am

      That would indeed be a better solution that static URLs and would allow for greater asset durability

      Reply
  6. Andy S. says:
    January 29, 2022 at 11:00 am

    In fact, when I heard about NFTs (the artworks with certficates on blockcahain),
    it seemed natural for me, that the whole thing was working exactly that way, like NFT mining, and the pointer to storage was upgradable.
    I am amazed, that this half-baked under-thought solution was used, and what fussing over about the NFT idea was there.

    Reply
  7. Anonymous says:
    January 29, 2022 at 3:20 pm

    Great idea, the blockchain DB isn’t big enough, we all need a bunch of lame meme images permanent taking up more space on every node in the world. You should put up some graphs showing the great efforts of the blueblox compactifyers vs that work being undone for the sake of some novelty spacemarmot BS…

    Reply
  8. Pavel S. says:
    January 30, 2022 at 3:42 am

    maybe just create new blockchain chiaNFT, and save us JPG inwards? and hosters will has rewadrs on uptime?

    Reply

Leave a Reply Cancel reply

Advertisement

Recent Posts

  • Crypto is burning down – Chia seems fine
  • Chia CAT upgrade fiasco part 2 – Was I wrong?
  • WTF just happened?? CAT1 to CAT2 “upgrade”
  • The era of the Chia NFT is upon us
  • Chia Blockchain 1.4.0 released – NFTs and DIDs oh my
  • Discussion
  • Facts About Farmers
  • How-To
  • Information
  • News
  • pools
  • Security
  • Trademark
  • Trading
  • Uncategorized

Dark Mode Switch

©2021 The Chia Plot - Donate XCH / MRMT / SBX @ xch1p4440d6zwu9ryta2vx073lq2ge3s29d37kskz6t34jp085e8srjqnk0gcr
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
Cookie SettingsAccept All
Manage consent

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
CookieDurationDescription
cookielawinfo-checkbox-advertisement1 yearThe cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Advertisement".
cookielawinfo-checkbox-analytics11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional11 monthsThe cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
JSESSIONIDsessionUsed by sites written in JSP. General purpose platform session cookies that are used to maintain users' state across page requests.
viewed_cookie_policy11 monthsThe cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
CookieDurationDescription
na_id1 year 1 monthThis cookie is set by Addthis.com to enable sharing of links on social media platforms like Facebook and Twitter
na_rn1 monthThis cookie is used to recognize the visitor upon re-entry. This cookie allows to collect information on user behaviour and allows sharing function provided by Addthis.com
na_sc_e1 monthThis cookie is used to recognize the visitor upon re-entry. This cookie allows to collect information on user behaviour and allows sharing function provided by Addthis.com
na_sr1 monthThis cookie is set by Addthis.com. This cookie is used for sharing of links on social media platforms.
na_srp1 minuteThis cookie is used to recognize the visitor upon re-entry. This cookie allows to collect information on user behaviour and allows sharing function provided by Addthis.com
na_tc1 year 1 monthThis cookie is set by the provider Addthis. This cookie is used for social media sharing tracking service.
ouid1 year 1 monthThe cookie is set by Addthis which enables the content of the website to be shared across different networking and social sharing websites.
Performance
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
CookieDurationDescription
d3 monthsThis cookie tracks anonymous information on how visitors use the website.
Analytics
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
CookieDurationDescription
__gads1 year 24 daysThis cookie is set by Google and stored under the name dounleclick.com. This cookie is used to track how many times users see a particular advert which helps in measuring the success of the campaign and calculate the revenue generated by the campaign. These cookies can only be read from the domain that it is set on so it will not track any data while browsing through another sites.
_ga2 yearsThis cookie is installed by Google Analytics. The cookie is used to calculate visitor, session, campaign data and keep track of site usage for the site's analytics report. The cookies store information anonymously and assign a randomly generated number to identify unique visitors.
_gat_gtag_UA_199099757_11 minuteThis cookie is set by Google and is used to distinguish users.
_gid1 dayThis cookie is installed by Google Analytics. The cookie is used to store information of how visitors use a website and helps in creating an analytics report of how the website is doing. The data collected including the number visitors, the source where they have come from, and the pages visted in an anonymous form.
CONSENT16 years 4 months 5 daysThese cookies are set via embedded youtube-videos. They register anonymous statistical data on for example how many times the video is displayed and what settings are used for playback.No sensitive data is collected unless you log in to your google account, in that case your choices are linked with your account, for example if you click “like” on a video.
Advertisement
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
CookieDurationDescription
advanced_ads_browser_width1 monthThis cookie is set by Advanced ads plugin.This cookie is used to measure and store the user browser width for adverts.
anj3 monthsNo description available.
CMID1 yearThe cookie is set by CasaleMedia. The cookie is used to collect information about the usage behavior for targeted advertising.
CMPRO3 monthsThis cookie is set by Casalemedia and is used for targeted advertisement purposes.
CMPS3 monthsThis cookie is set by Casalemedia and is used for targeted advertisement purposes.
CMRUM31 yearThis cookie is set by Casalemedia and is used for targeted advertisement purposes.
CMST1 dayThe cookie is set by CasaleMedia. The cookie is used to collect information about the usage behavior for targeted advertising.
DSID1 hourThis cookie is setup by doubleclick.net. This cookie is used by Google to make advertising more engaging to users and are stored under doubleclick.net. It contains an encrypted unique ID.
i1 yearThe purpose of the cookie is not known yet.
IDE1 year 24 daysUsed by Google DoubleClick and stores information about how the user uses the website and any other advertisement before visiting the website. This is used to present users with ads that are relevant to them according to the user profile.
KADUSERCOOKIE3 monthsThe cookie is set by pubmatic.com for identifying the visitors' website or device from which they visit PubMatic's partners' website.
KTPCACOOKIE1 dayThis cookie is set by pubmatic.com for the purpose of checking if third-party cookies are enabled on the user's website.
mc1 year 1 monthThis cookie is associated with Quantserve to track anonymously how a user interact with the website.
test_cookie15 minutesThis cookie is set by doubleclick.net. The purpose of the cookie is to determine if the user's browser supports cookies.
uid1 year 1 monthThis cookie is used to measure the number and behavior of the visitors to the website anonymously. The data includes the number of visits, average duration of the visit on the website, pages visited, etc. for the purpose of better understanding user preferences for targeted advertisments.
uuid3 monthsTo optimize ad relevance by collecting visitor data from multiple websites such as what pages have been loaded.
uuid23 monthsThis cookies is set by AppNexus. The cookies stores information that helps in distinguishing between devices and browsers. This information us used to select advertisements served by the platform and assess the performance of the advertisement and attribute payment for those advertisements.
VISITOR_INFO1_LIVE5 months 27 daysThis cookie is set by Youtube. Used to track the information of the embedded YouTube videos on a website.
YSCsessionThis cookies is set by Youtube and is used to track the views of embedded videos.
yt-remote-connected-devicesneverThese cookies are set via embedded youtube-videos.
yt-remote-device-idneverThese cookies are set via embedded youtube-videos.
Others
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.
CookieDurationDescription
__gpi1 year 24 daysNo description
adImpCountpastNo description
C3UID5 yearsNo description available.
C3UID-9245 yearsNo description
fc5 months 27 daysNo description available.
pfpastNo description
pxs5 months 27 daysNo description available.
SAVE & ACCEPT
Powered by CookieYes Logo