@tre
I believe there is some misunderstanding about how the data is being stored. By using the current method the data is not "permanently stored" on the the blockchain. There is no obligation for archival nodes to keep the data. In fact prunable data can and does get lost. At this moment there is missing pruned data that no node has a copy of (including archival nodes).
The cost for storing data on-chain is significantly higher - this data is stored by all nodes and must be present to rebuilt the blockchain (unlike prunable data).
If the NFT project want to claim that their NFTs are stored "forever on-chain" like the Ethereum NFTs then this on-chain method must be used.
@thewiremaster
But I believe that not all nodes need to store all this data. What matters is that there are enough archive nodes that store the data and that should be not an issue. I mean if I have a NFT business I make sure that I have a few nodes storing everything.
How do you calculate the 4000 ardor for 1MB? Where and how do you store that data?
@tre
For "true" permanent on-chain storage you would, perhaps, store the data as non-prunable message attachments. There could still be a single asset that ties the data together that represents the NFT.
The data is stored by, for example, splitting the data into 160 bytes blocks that also contain meta-data (such as the message hash of the next block) as non-prunable message attachments. The last step is creating the NFT asset that contain the entry to the first 160 byte data entry and follow the links to reassemble.
Ethereum etc. are storing their data on-chain and the NFT will exist long after the original business disappear (assuming that the platform persists). Perhaps part of the value of these assets is that the owners do not have to worry that there NFTs may no longer be accessible if the some nodes go off-line because the data is truly part of the on-chain data.
@bitswiftbro
It's not true, most Etherem NFT are not actually fully on chain.
Most rely on external data source, some centralized services as well to host the images and such.
So in Ardor even the prunable data is stored in the database, any node running a full archival node should have record of all the "archived" data, no?
How can archival node opt out of holding certain data?
@thewiremaster
Letting all nodes store the data would go against the ardor philosophy of defeating blockchain bloat.
I also am not sure about how archive nodes decides what to store. I have a couple of archive nodes and I'm not sure I have any special setting to decide what to store and what not to store. But maybe I didn't check all the settings.
@bitswiftbro
"CryptoKitties operates on Ethereum's underlying blockchain network, as a non-fungible token (NFT), unique to each CryptoKitty. ... Users can interact with their CryptoKitties, having the ability to buy, sell, and sire (breed) them. However, the CryptoKitty art is not on the blockchain and is instead owned by Axiom Zen."
so when axiom zen disappears.... all people on eth will be left with is some ERC token number.
the images will be gone
or possibly claimed by Axiom Zen for no more re-production or use.
My understanding is if there are archival nodes online, hosting the archived data including the prunable nftmagic data, so that data will always be accessible and immutable.
@tre
I believe that the node does not presently have a setting to delete specific prunable data and yet there is data missing form all nodes at present. With a SQL command it is trivial to delete data that a node operator wish to unburden themselves from. I think that even I could release an add-on that does this for any given transaction hash. But this is besides the point - I think that the claim that the data is "permanently stored on-chain" only apply to non-prunable data. I guess that these NFTs may be viewed as more valuable so this on-chain method could be reserved for those NFTs such as the mentioned NFT that sold for a lot.
@martis
Archival nodes store all data, they do not choose what to store or what not.
@bitswiftbro
So if someone wanted to modify the default fuctions so as to exclude archival data from their archival node maybe they could hack away and accomplish that, but by defauly, really, who is going to do that. Even if they do, there will be 1000 other archival nodes hosting that data. (presumably)
@tre
I would agree but if you run an archival node you may notice in your logs that your node is missing data, for several months now. In the past when this happened before I was able to determine the missing data, and perhaps I will look into this case but this is evidence that even for small pieces the platform's archival system has flaws.
@bitswiftbro
So far I have never noticed any missing prunable data.
Mind you I have not really been paying to much attention.
In this way, if a copy of the full blockchain is the inclusion of the full database which includes the prunable information, than it is still "on chain". It's just "on chain" in the prunable data which is not really indexed by each and every node.
@tre
I believe that blockchain developers, perhaps, define on-chain as data that is required to rebuild the platform's blockchain - the chain of trust. The non-prunable data is entirely included in the signed data and is required to rebuild and verify the blockchain.
For prunable data only the data's hash is signed and the data is not required to rebuild or verify the blockchain. I believe that this distinction is only important for making the claim that a NFT is "stored on-chain forever"
@thewiremaster
I think that then it's a matter of wording. But in my opinion, peunable data or ardor is still better than having it on dropbox
The claim on-chain maybe we have to discuss with Jelurida.