Does it make sense to deploy reusable library for rendering SVG, etc.?

Code Wizards
1

I was thinking of creating a library that can render art, which could then be called from any other contract, such as an ERC721 smart contract.

The motivation for this is that there are many NFTs that want to render art, such as SVG, and this requires the same (or similar) code to be deployed on-chain repeatedly, which is expensive.

This led me to wonder why there are not already libraries deployed that can render things like SVG, HTML, or other common formats. Is there a fundamental reason why this is not useful or practical? There seems to be a lot of interest in decentralization, and the only reliable way to store certain data is on chain.

2

Why are you putting client side rendering code on Ethereum? Such code should live somewhere like IPFS instead.

1 Like
3

IPFS storage has no guarantee that it’s permanent. Looking at the opposite perspective: Why would I NOT put it on Ethereum, if it’s small enough to be stored there? There are already NFTs that store the art on chain, such as Nouns (see On-Chain Artwork at https://nouns.wtf/). Also generative artwork from Artblocks, I think there are many examples.

4

Storing a seed on-chain but the algorithm off-chain is reasonable. Similarly, storing a hash on-chain and the image itself off-chain is reasonable. The reason “why not” is because on-Ethereum storage is incredibly expensive, while off-chain storage can achieve desired levels of availability at essentially epsilon cost relative to on-chain storage.

5

I personally think central services make A LOT of sense!
It would be the equivalent of npm for NodeJS.
There’s way way too much unnecessary duplicate code on chain.

6

I agree with @MicahZoltu

There’s no reason to hog blockspace with stuff like that, only the minimal amount of data that needs to be verified. Why not create an EIP that lays out standard frontend code for rendering SVG, HTML, etc., and then storing the hash of the code onchain and creating a frontend framework that verifies the components match the onchain hash?

7

I would think such a library would use a great deal of gas. I do like the idea, however, and would like to see more support for such a thing.

8

I also think it would be very expensive. But it looks interesting. When you create this library, open a pull or EIP in git and let us know here so we can review and help.