On Smart Contracts as a medium (Part 2)

Decentralized Runtime Art* – a materialist approach to the EVM as a medium

“These days, media technologies constructed on the basis of formal languages move the boundary between the possible and the impossible, the thinkable and the unthinkable. Those who have tried to pour the fuzzy logic of their insights and intentions into computer source code know from bitter experience how drastically the formal language of these codes distorts those insights and intentions. And because these feedback loops tend to lead from the machine to the programmer rather than the other way round, computers cannot be classified as tools (…)” [1]

At the heart of the Ethereum blockchain runs the EVM as a stack-based state machine. Working on a word size of 256 bits, the EVM has specific characteristics (permanent storage, immutable program code ROM, volatile memory) to facilitate a valid state transition on the base of transaction data. In a simplified way, one can say that the EVM (in connection with the consensus layer) is a transaction-based virtual machine that is inherently connected to economic resources through the consumption of gas in the execution of smart contracts. The EVM can be thought of as a world computer where every calculation has its costs. Programs that run on this world computer (smart contracts) are limited in the scope of their calculation and memory by the gas costs.

“When a transaction results in smart contract code execution, an EVM is instantiated with all the information required in relation to the current block being created and the specific transaction being processed. (…) A key variable is the gas supply for this execution, which is set to the amount of gas paid for by the sender at the start of the transaction (…). As code execution progresses, the gas supply is reduced according to the gas cost of the operations executed.”[2]

Now, perhaps the focus in the previous section on demoscene art opens up – both blockchain art and demoscene art are fundamentally tied to turing complete systems in which resources such as storage and computation are limited by the underlying technological implementation itself. The proposal of this section is pretty basic: NFTs (and smart contracts) are technologically more akin to code running on distributed computers with limited resources than to images, moving the lineage of references from purely visual mediums like painting and animation to demoscene, home brew computers, software – and netart. If we look for structures to frame NFTs as a computational medium, we can fall back to Kittler to provide a specific characterization of discursive formation:

“[a]rchaeologies of the present must also take into account data storage, transmission and calculation in technological media”[3]

At this point we will, unfortunately, abandon a longer analysis of transmission in the EVM in order to be brief and concise: transmission is, as described before, a transaction whose data changes the global status of the EVM. In the following, we will focus (as various artists working with the medium) on storage and calculation (computation).

NFT art that does not interact intentionally with the EVM is juxtaposed with the evolving movement of onchain art. Since an NFT is a smart contract which is a computational medium itself – the contract can theoretically generate every possible combination of signs – e.g can output any format. Terraform and Brotchain both radically utilize the potential of the EVM to generate their visual components from the code itself, once by creating HTML, Javascript, and CSS – the other through actually generating an image file. The different methods for generating and storing visual output are determined by the architecture of the EVM – data can either be stored temporarily by calldata or loaded into the permanent memory of the contract by the opcode SSTORE(from which they can then be further processed).

One of the first artworks to be attributed as onchain art, Autoglyphs, still used calldata to emit output and needed a corresponding external script to render the artwork. As a counterexample Terraform stores and generates the complete HTML/javascript output onchain via the contract. While these two examples are exceptions, the onchain “label” mostly signifies the storage of the visual medium in the persistent memory of contracts. To the question of how the artist should use a distributed computer, the only answer here seems to be: to store a medium that is generated externally. While the majority of onchain art focuses on using NFTs to store external media, the question remains – which artworks use the “computational” capacities of EVM? The architecture of the EVM distinguishes between two types of computation as Simon de la Rouviere describes:

“Something that’s important to remember with how Ethereum works. You must pay to upload code (in the form of a smart contract) to Ethereum. If you want to execute the code in order to create a change in the data stored in the smart contract, then, it costs you money (with ether). However, you are still able to execute the code without paying for it when the code does not produce a change in the state. To change state, you issue a transaction. To merely execute the code without changing state, it is commonly called, “calling” the smart contract. Examples of the latter include fetching variables, checking if transactions will succeed before they are issued to the network, and doing simple computations based on current state.” [4]

The interactions with the EVM are mediated by two types of computation: One that changes the internal state of the underlying contract, and another that only views a state. The latter interaction is not a real transaction in the classical sense but is executed by the network’s edge nodes. Several onchain NFTs use these “view” functions to generate their output: The most radical example remains Brotchain, in which the resulting image file is generated quasi-procedurally in the contract itself through a view function.

So while the first kind of computation is mainly used for rendering visual content, there are currently only a few NFTs that actually change their state based on a transaction (besides the literal transfer function). This is also connected to the fact that these additional changes can be quite costly as they are dependent on Ether (as currency) for computation. The obvious discussion of the connection between capital and decentralized computation will have to be postponed for now. Nevertheless, within this economical “burden”, a few examples can be located: First is Terraforms, which allows users to “paint” and customize their work and thus change the initial state of the animation. There are Sarah Friend’s “Lifeforms”, where after a certain block time the Lifeforms “die” if the NFT is not transferred to another wallet. And lastly (in this limited list) there is okpc – a small onchain drawing board where users can create images in a finite environment.

While all these examples show interesting ways of limited interaction – the main question remains: How can the computational capacity of the EVM be used as the primary element of an onchain artwork? And how can this be built in a manner that is not purely deterministic – yet remain visually complex while being composed completely onchain? (find out in the next post lol)

[*] Inspired by this Tweet by Simon de la Rouviere

[1] Friedrich Kittler – ‘Thinking Colours and/or Machines

[2] https://github.com/ethereumbook/ethereumbook/blob/develop/13evm.asciidoc

[3] Friedrich Kittler - Aufschreibesysteme-1800-1900

[4] https://blog.simondlr.com/posts/flavours-of-on-chain-svg-nfts-on-ethereum