In order to properly understand why onchfs improves upon existing solutions, it's worth looking at the state of the space.
Art Blocks
The current solution used by Art Blocks revolves arround storing a raw javascript code on-chain, as well as the script dependency (p5js, etc...). Only the javascript part of the project is stored, so either they have to
Let's look at a practical example, with a the wonderful project Torrent, by Jeres released on Art Blocks. If we query the Smart Contract view projectScriptByIndex(457, 0), a string is returned (note that the string has been truncated for practical purposes):
artists only upload the raw JS portion of their project
they specify a dependency, among those made available by Art Blocks
the string is stored as-is, without compression (using UTF-8 encoding)
the JS part of the project can be retrieved from the contract
It should be known that some Javascript code, especially the one directly returned by Art Blocks contracts, cannot be executed by itself. A web browser needs to see a valid HTML document it can interpret, which references javascript a way or the other. Moreover, there needs to be a mechanic where iteration inputs are injected so that they are accessible via Javascript. There needs to be a process where an HTML string is built from the various inputs: libraries, inputs, and code. We believe Art Blocks is using an off-chain process to compose such a string (which by the way is perfectly fine, as proper specifications will allow such reconstructions to easily happen in the future). The full HTML string for Torrent looks like this:
It's interesting to note a few things with this approach:
the HTML string is built off-chain (it could be built on-chain, as a matter of fact we'll look at such an implementation afterwards)
the template defines strict rules which can interfer with some artistic practices
libraries are handled by an authority, there is no way to ensure a library is actually properly served by the authority
in such a case we trust Art Blocks for delivering p5js properly, however it seems they are using cloudfare cdn for serving it
this opens up a vector for supply chain attacks - what if cloudfare somehow decided to inject a wallet when deliverying p5.min.js ? (this can be mitigated using checksum verification, which in their case was not implemented at the time this document was written)
in any case, there are very few ways for artists to be sure their dependencies are properly delivered (depending on the implementation, there might not be any way), as they need to rely on an authority to do so. Again, mostly fine with Art Blocks as they have a strong incentive to properly maintain that
artists only have access to a subset of libraries; those maintained by the platform. For instance, p5js is now at version 1.7.0, while only version 1.0.0 seems to be available (released 3 years ago)
the JS code a stored as a raw string, without any compression
only the JS code has to be pushed by artists; they don't have to upload the HTML template which saves a few bytes—at the cost of lossing access to html and js directives.
discrepancies between the dev environment of artists & prod; artists have to use some kind of carefully crafted dev environment that mimics prod behavior
As denoted along many of the points, while the Art Blocks approach works for Art Blocks, it unfortunately doesn't translate well at all in open ecosystems.
Scripty & EthFS
While ArtBlocks has pionereed Generative Art code stored on-chain, others have improved upon their solution to address some of what they considered to be issues (or sub-optimal solutions) in the Art Blocks approach. One of these projects is scripty, a set of contracts/tools to handle on-chain code storage and delivery.
While scripty improves upon a few points, it's worth noting it follows similar principles as Art Blocks conceptually. The main differences are:
HTML reconstruction on-chain: no need for an external process; the full HTML script can be exported from the contract directly
data compression (mostly gzip)
better handling of libraries: shared between "scripty apps" (leveraging EthFS under the hood), still provided manually by artists
This is a fair improvement, however it still fails to address what we consider to be important issues, mainly revolving around artistic interference & lack of safety & decentralization in handling libraries (due to the inherant nature of ethfs not being fully content-addressed).