What is a on-chain project ?
It's a project which has its code stored on the blockchain.
How does fxhash handles on-chain code ?
Most Gen Art platforms are uploading the raw code on-chain (sometimes compressed, sometimes not), and usually such code has to be uploaded as a single string.
We built a different system which allows for more sophisticated file structures to be uploaded on-chain, as we aim at offering the least possible friction for artists. The system we have built for such a purpose is called On-Chain for Http File System, ie onchfs.
What is onchfs ?
Onchfs is a file system which is fully stored on-chain in an optimized fashion, providing a set of interfaces and tools for such content to be fetched using the http protocol.
Onchfs provides a drop-n-replace solution for ipfs, in a way that artists can release projects on onchfs just as they used to release projects on ipfs before onchfs support was added.
Anyone can write data, create files & directories, & reference files stored on the file system.
Every byte necessary to fully reconstruct the file system is stored on-chain. Standards provide a way to write & read the file system.
Content created on the file system can never be altered.
The raw bytes of data are stored as chunks in a dumb Content Store contract, only supporting low level operations such as write & read. Because the chunks of data are Content-Addressed, many applications can use the Content Store for various purposes without impacting each other. This protocol provides extra abstraction layers to improve upon just having a Content Store.
Chunks of data, files & directories are hashed and identified by their in the Content Store hash.
An inode can be a file or a directory:
- file: an ordered list of pointers to chunks of bytes in the stored in the Content Store, and some extra data describing the file
- directory: a list of inodes with their assigned names
inodes are also Content-Addressed, the hash of their content is used to identify the inodes on the file system. Such hashes are used as entry points to the file system, and are referred to as Content Identifiers (CID).
Designed for the http protocol
As browsers are the main (if not the unique sensible) gateway to web3 assets, the protocol is designed to easily serve its content through the http protocol, in such a way that assets can easily reference and load other assets stored in the file system, using the native behaviour of modern browsers through the http protocol.
While the http protocol isn’t directly built into the Smart Contracts (yet), the protocol specifies particular guidelines so that consumers of the system provide particular metadata for delivering resources through the http protocol, in an optimised fashion.
However the protocol specifies how proxy servers should be implemented to navigate the file system using the URIs native to the file system.
As the protocol provides very low level primitives, it’s easy to extend it by providing other abstraction layers for navigating the file system.
For instance, we could imagine an “http-like” contract which would take “http-like” requests to return content stored in the file system with http-compliant response messages.
Why is onchfs relevent to Generative Art ?
- anyone can publish any content, which anyone can reuse without paying for upload costs
- content is addressed and because of its design, there doesn't need to be a central entity for managing available libraries; the system is self-optimised and fully opened
- made for modern practices; onchfs doesn't come with a list of strong constraints for artists, they are free to use tools they're used to
- cross-chain: resources uploaded to a blockchain can be referenced on another; while not a standard practice, this opens up the door for new kinds of experiences to be built