What is MurAll Art?

MurAll is a collaborative canvas allowing artists worldwide to paint onto an ever evolving piece of art. This is a first of its kind project made possible by the use of blockchain technology - the 2048 x 1024 pixel canvas lives on the blockchain, meaning its state can be altered through blockchain-based transactions, and its entire history is recorded, ensuring that you can browse through the state overtime or replay its history to check how it changed over time. In addition, using a proprietary image encoder produced by MurAll, all images and metadata created on it are stored on the blockchain itself, ensuring that it is well distributed. This essentially guarantees that it remains accessible to everyone without being shut down or censored for as long as the blockchain lives. The live state provides all artists, no matter their stature in the art space, with instant representation the moment that their artwork is drawn on MurAll, as everyone who visits the live state will see their artwork featured there; just like a real life graffiti wall the state is self-governing.

Additionally, the blockchain's censorship-resistant nature provides users with a platform to make a statement (to whosoever wants it, no matter how controversial), and its pseudo-anonymous nature means that people can make art or statements on the canvas without worrying about being identified unless they wish to claim ownership by completing a transaction.

How and when did it all start?

The blockchain's invention has rippled throughout the globe, kick-starting a whole new decentralisation era and producing several innovative digital products that have never been possible.

Blockchain technology at its core can be broken down into 3 primitives:

1. Digital Scarcity — the ability to make something scarce in the digital world
2. Trust minimised code/unstoppable code — code that once deployed, even its writer can't alter it or make any update. Therefore, it cannot be stopped, so you can always trust it does what it is coded to do.
3. Immutable, timestamped and validated storage — ample for security and trust. The blockchain is a record that doesn't forget — no matter what, data gets on there, and it forever stays there.

Plenty of dapps and blockchain networks benefit from the first two primitives, but not many explored the possibilities of the third one. This is what initially led to the creation of MurAll.

MurAll started to explore making a digital canvas capable of recording its state changes on the blockchain, and it looked into the blockchain art space. It also noticed current blockchain art offerings, including SuperRare, Known origin, Async Art and Rarible. Though they are innovating while using the blockchain for art ownership, they are just platforms with rules on who can be the system's part and what art is to be displayed. Artists have to apply to be a part of their ecosystem.

While that has its place in ensuring artwork quality, blockchain excludes those who don't meet their standards or create art not falling within their rules. Even artists jumping through the hoops to have their art on those platforms have witnessed their artworks being censored, all going against the blockchains' complete neutrality principle. MurAll wanted to level the playing field with the creation of a place that didn't judge what it is like to be an artist, and where those having a status in the art world would be on the same level as the artists who just began, no application process, no gatekeepers, a permissionless place to express yourself artistically without judgement.

MurAll also noticed that most of these art platforms have off-chain artwork on IPFS due to the higher Ethereum contract storage cost, which although is the cheaper option and works most of the time, it has uptime issues, you have to juggle gateways, it is no way near as decentralised and secure as the Ethereum blockchain itself, so it wanted to find a way to create an on-chain art experience.

How does MurAll protocol work?

The main things to consider in terms of the image data were:

1. Data validity - Keeping in check the data integrity, making sure that only valid data can go into the smart contracts, thus increasing efficiency by lowering or eliminating the work done to validate the data
2. Keeping images rich - Making the right decisions to allow as large/colour-rich images as possible to be placed into the on-chain storage
3. Maintaining the MurAll core functionality - Letting the data follow the main ideas of MurAll, allowing painting over the canvas to replace what is underneath, and enforcing the proper burning of the PAINT used for the transaction. It means only charging for painted pixels and not charging for any transparent pixels sent in the transaction.
4. Keeping things as cheap as possible - Getting the maximum bang for your buck, squeezing in maximum data into every transaction, and reducing or avoiding work done on the smart contract where possible to save gas

The smart contracts for MurAll are highly optimised to strike a balance between cost and features. MurAll made several decisions to ensure that all image data was kept on the blockchain itself because though it is more expensive than IPFS (the standard choice for decentralised file storage at present), MurAll believes that "you get what you pay for", i.e. storing data on the blockchain puts it on a secure, most distributed and highly reliable storage media available.

IPFS also has the caveat around "pinning", meaning unpinned files are not guaranteed to be available; therefore, to ensure the files are pinned, you have to either maintain an IPFS node with those files pinned or pay for a service to ensure those files continue to be pinned; the blockchain, however, has multiple copies of the state distributed all over the world and has its incentive structure to ensure those copies are available and maintained. This is why MurAll has chosen to store both the image data and metadata on the blockchain.

Ethereum has two main places to store its data: log and contract storage. Contract storage refers to the Ethereum smart contracts storage, holding the blockchain state; the most expensive storage costs 20,000 gas for every 32 bytes and is the most useful among all transactional activity within this storage.

The cost of Log storage is 375 gas for each topic along with 8 gas per byte of the LOG operations data. Thus, to store 32 bytes, the cost would be 375 gas + (8 gas * 32 bytes) = 631 gas,

It is cheaper, but storing on log storage includes a caveat that the log operation is immutable and inaccessible from within contract storage.

Indeed any place able to display the image would have access to the log storage too; thus, MurAll has chosen the log storage to store the image data (even with the caveat that the image data won't be accessed from contract storage) for the given reasons:

• The immutable data - It is perfect for our use case where the image data does not have to be altered.
• Log storage is a part of every node on the network - It is as decentralised secure as any data on the contract storage. Therefore, it will be as accessible as the contract storage is
• It consumes a lot less gas - Not only does this reduce the cost of the transactions, but it also means that more significant amounts of image data can be fitted than what is possible in contract storage because of Ethereum transactions' gas limits.

The Ethereum Virtual Machine (EVM) only works with 32-byte items; objects smaller than 32-bytes are transformed to 32-byte objects first, which costs gas. For example, the integer 1234 only takes 2 bytes and may be represented as an uint16:

0x3039

However, it starts out as an uint256 and would be reduced to uint16 in the EVM by converting it from a 32-byte object:

As a result, the cheapest and most gas-efficient items for transaction data are 32-byte objects. There is a huge amount of wasted space in the full 32-byte object because only a few bytes are used. However, using a technique known as "bit packing," it is possible to pack numerous distinct pieces of data smaller than 32 bytes into a 32-byte object. For example, the number 1234, which is two bytes long, can be repeated 16 times for fitting inside a single 32-byte object:

This approach allows us to get the most data into a single transaction and save gas.

Digital images are collections of pixels, which can be broken down into 2 main components: colour and position. Thus, MurAll's primary approach was to get as much information about the pixels' colour and position into the transaction data.

When dealing with 32-byte objects for Ethereum transaction data, it's also important considering the possibilities of what might be put into each byte: 1 byte can carry up to 256 different values, 2 bytes can hold 65536 different values (256²), 3 bytes can have 16,777,216 different values (256³), and so on.

After investigating existing image compression algorithms and standards, MurAll came upon the GIF standard: Instead of holding the complete colour of each pixel independently, GIF uses a palette of 256 predetermined colours and generates the image using pixels that are merely pointers to each colour's index. The fact that only 1 byte allows 1 pixel referencing, these possible 256 colours grabbed MurAll's attention to this technique; consequently, 32 pixels can fit in a 32-bit object! The only requirements are that the 32-pixel group is appropriately addressed and that the pixels in the group are in the correct order.

In most digital photographs, colour is RGB888, which means 8 bits per colour channel (i.e. 8 bits for red, 8 bits for green, and 8 bits for blue), for a total of 24 bits/3 bytes for a single colour. After looking for ways to decrease that data, MurAll came across the RGB565 standard, a 16 bit/2 byte colour space (i.e. 5 bits for red, 5 bits for blue, and 6 bits for green as human eyes see greens better).

You can still produce a great image with a 16-bit colour palette and only 256 colours per image, allowing you to free up more space for those all-important pixels. We can store 16 colours per 32-byte object and generate the colour index of 256 colours as an array of 8 32-byte objects because RGB565 colours only occupy 2 bytes. If the artist likes, we may additionally allow for transparency by sacrificing the first index's colour to represent the image's alpha channel.

With these considerations in mind, MurAll divided the canvas into 32-pixel groups (ordered top to bottom, left to right) and chose a resolution of 2048 × 1024 pixels, close to the conventional 1920 x 1080 pixel resolution.

Still, more importantly, it would give us 65536 groups of 32 pixels, and the number 65536 is significant. After all, as previously stated, 2 bytes hold 65536 possible values, meaning that not only do each group of indexes take up only 2 bytes but also that no index validation is required on the smart contract because the entire range of all possible values in 2 bytes is covered. There is no need for additional positional information as long as the pixels are in the correct sequence inside their groups!

Thus, for the image's transaction data, we have an array representing any 32-pixel groups with no transparency, twinned with another collection representing the positions of each of these groups on the canvas (each group index is 2 bytes, so 16 indexes can fit into a single 32-byte object), and a separate array representing any 32-pixel groups with transparency (allowing the smart contract to only process these groups looking for transparent pixels for ensuring the proper amount of PAINT is charged while saving as much gas as possible).

Isn't it wasteful if one group only has one pixel, for example? With this in mind, MurAll constructed a separate packed array for individual pixels, which consists of the colour (1 byte), their group locations (2 bytes), and their position in that group (1 byte), allowing for up to 8 colour/position pairs in 32 bytes, for example:

Other data validation is unnecessary because all data sent uses the full range of bytes available for each of their purposes; thus, no checking is required (except for the 1 byte in the individual pixel array representing the position of the pixel in the group of 32; 1 byte has 256 possible values, but the position range is only between 0–31). As a result, we round any figure greater than 31 to 31, reducing the smart contract's work to just one task: ensuring the exact amount of PAINT is used in the transaction. This saves the greatest money on gas.

In summary, the transaction data transmitted to MurAll as part of the drawing consists of:

1. the colour scale (up to 256 RGB565 colours, 2 bytes each, packing up to 16 colours into every 32 bytes)
2. the entire group (32 pixels, 1 byte each, referring colour from 0–255) without transparency
3. the MurAll group indexes where these groups can be found (2 bytes per index, up to 16 indexes packed into 32 bytes)
4. the transparency groups (same as the rest of the groups: 32 pixels, 1 byte each, referencing colour from index 0–255)
5. the MurAll group indexes where these transparent groups can be found (also the same: 2 bytes each index (maximum of 16 indexes in 32 bytes)
6. A name (up to 32 characters, hence 32 bytes), series id, number, and whether the image contains alpha are all part of the image metadata (3 bytes, 3 bytes and 1 bit respectively, packed into a 32-byte object).

This picture metadata is included in the minted MURALL NFT, as well as the keccak256 hash of the image data transmitted in the transaction (i.e. the colour index array plus all other pixel position arrays), ensuring that the metadata can validate the image data when it is retrieved from log storage.

However, we knew that some people might want to push the image data onto smart contract storage no matter the cost. MurAll wished to cater to those artists who do not mind paying the high fees for the storage, so it designed a "write once" mechanism into our NFT to allow it to be "filled" with the image data by pushing the image data from the original transaction onto smart contract storage.

MurAll may evaluate the image data inside the NFT, as previously indicated, to validate the data to ensure it is the original data. The data is entered one by one until the operation runs out of gas. The data from the previous fill transaction will be continued in the next fill transaction. It may take several transactions, depending on the size of the artwork, and hence be expensive. Still, it is achievable if the artist is genuinely committed to doing it regardless of the expense.

However, due to the transaction data limits, large images must be divided into parts and put onto MurAll in several transactions. Thus MurAll constructed a Montage service, allowing the artists to bring all the single NFTs produced on MurAll, which represent the pieces of the artwork and join them together into a single NFT. The individual NFTs are sent to the Montage contract, which mints an NFT representing those unique pieces, and displays all the pieces joined. It also allowed adding some additional features, such as an option to include an unlockable in the NFT, which could be a link to some other content, such as a high-resolution image, video, or a 3d model!

Tokenomics & Its utility

There was a popular story a while back about some divers who went down to the Titanic debris and returned with 6 wine bottles, each worth $1 million, so do you know what those divers did? They only drank one bottle of wine. Then moved to another.

This was surprising to hear: how could they throw away such a valuable item?! However, as the storyteller revealed their reasoning, it became clear: there were no longer six bottles in existence; there were only four. The surviving bottles were considerably rarer than before, and their worth was much more than $1 million per bottle; the process of removing two bottles from "circulation" raised the value of the remaining "circulating" bottles. The PAINT token that MurAll requires is based on this method.

PAINT is similar to real-life paint in that it can't be reused once it's been used. The PAINT spent in the transaction is "burned" during the "painting" process on MurAll, removing it from circulation and reducing the global supply. Reducing the supply raises the rarity of the remaining supply and, as a result, the price of the remaining supply. MurAll uses this mechanism to ensure that high-quality art is drawn to MurAll, as people will think twice about wasting PAINT on something unimportant as it becomes rarer and thus more valuable, and instead sell PAINT to those who are unconcerned about the price of PAINT and instead want to make art on MurAll regardless of cost.

One conceivable scenario is that artists will be less motivated to make high-quality art due to a significant supply of PAINT at the outset because PAINT will be cheap and plentiful, resulting in an initial phase of low-quality art. Furthermore, because the deflationary aspect of PAINT may cause some people to draw solely to reduce the global supply of PAINT (i.e., to increase its rarity and thus its value), those people may not be able to produce high-quality artwork on MurAll because their intentions are not driven by a desire to paint but rather by greed. This is why MurAll has a new incentive system: when you paint on MurAll, an NFT of the artwork you create is created.

Because an NFT of your artwork gets minted during the painting process on MurAll, it is in the artist's best interest to paint something of excellent quality/meaning so that the NFT may be sold afterwards. Low-quality or meaningless artwork will be far more difficult to market if it can be sold at all. Furthermore, because of PAINT's fixed supply and deflationary nature, the number of NFTs that can be produced from MurAll is limited, as NFTs can only be produced while there is PAINT to spend on MurAll; once the global PAINT supply runs out, no more MURALL NFTs may be minted. As a result, they have an additional rarity attribute.

These dual tokenomics are very easy to comprehend as this transformation is something very natural that we see in the traditional art world: you take your raw materials (i.e. some paint and a canvas, and in our case, the Paint token and the MurAll) and you produce something worth more than the sum of those raw materials (i.e. a work of art, and in our case an NFT containing your artwork).

Unlike existing art platforms, where artists have to apply for representation on their site, the moment the artists draw onto MurAll, they gain instant representation with our live state; their work will be visible to everyone visiting the site, and even if others draw over the state their work is forever visual in the history.

As MurAll is an entirely open protocol for anyone to draw on, it also expands the utility for what MurAll can be used for: not only is MurAll being used for producing artwork, we've seen examples of MurAll being used for the promotion of new projects, we've seen examples of free speech, we've seen examples of bringing to light controversial subjects censored by some nations which are now visible to all, we've seen users produce memorials for loved ones as a way to immortalise their memory onto the blockchain, we've witnessed NFT collections take advantage of MurAll's on-chain artwork by creating the artwork there, and no doubt in the future we will see even more examples we have yet to think of!

Conclusion

MurAll is effectively a new art medium, with its features and nuances that artists worldwide can use however they like. It is a unique art protocol that stays true to the ethos of the blockchain being open, permissionless and censorship-resistant, solving controversial issues brought up with other NFT projects by having its artwork on the blockchain itself and being as inclusive as possible. We always believed that the next Picasso or Van Gogh could be turned down by the big art platforms and discouraged from producing art and were driven to create a place where artists could make the art they want and have it seen across the world. We have succeeded in creating that place, and true to life all you need is some Paint to create the art you want.