EIP-4973 allows for mutually agreed, peer-to-peer minting - without implicitly determined power distributions
You can make a surprising discovery about EIP-20 and EIP-721’s functioning when you notice that they’re entirely unusable without at least once conceptually invoking a minting functionality. Now, whether a user does it via calling the often provisioned function _mint(...) function or by manually setting account balances via the constructor doesn’t matter. And surprisingly, minting by itself is suspiciously absent from the Ethereum Improvement standardization Process. Isn’t this odd: No EIP-20 token or EIP-721 contract would be functional today hadn’t at least one of their implementers decided to implement and call a non-standardized functionality and minted tokens to some addresses. And sadly, this comes with the obvious consequence of power aggregation and distribution unfairness. However, for the sake of this post and to make it a little more emotional, I want to rather say: leaving the minting function of EIP-20 and EIP-721 non-canonicalized is a failure in implementing a truly peer-to-peer system. What do I mean by that?
Building peer-to-peer systems
If you’ve ever built networked systems, you probably understand an obvious way to encode power into a distributed system: The client-server model. Any frontend+backend app is essentially that: It’s fundamentally not peer-to-peer and instead drastically elevates the server in the power hierarchy over clients. This is not only the case for clients coming into existence by downloading and executing server-feed code .e.g., in a browser (compare to, e.g., a smartphone app), it becomes especially apparent when only a server can decide which users are rightfully logged in and can read certain tables in the database. I say that the hierarchy in a web app is fundamentally not peer-to-peer as in most implementations, the server controls the client entirely, and since we’d even go as far as saying that the client could manage the server, then we’d consider it an attack vector.
Client-server architectures
Now: If you’ve ever played around with peer-to-peer libraries - which I recommend - as a client-and-server developer, you’ll soon realize feeling stuck. A sense of hyper normalization has set in, and you’re staring at the screen: Uhm, how… do I build anything without immediately encoding power?
See, already by implementing a chat client that broadcasts a user’s messages and receives other users’ texts - moderating the network’s state is very different from a single server backing up all chat history.
In the practical case of a user broadcasting messages with unwanted content to others, albeit all users being individually capable of deleting them from their storage, the messages would remain untouched and replicable for any user implementing a non-message-deletion policy in their chat client.
So contrast the above to the traditional client and server model, where the client literally spawns from downloading whatever the server delivers: In that case, it’s rather likely the client didn’t store any chat message history at all. But not only that, additionally, the server could implement privileging certain clients over others. Clearly, it’d then also mean that the server could implement logic that allowed an administrator to act on behalf of the community to delete messages containing unwanted content - and unless client users implemented their own software clients, they’d have to show whatever the server delivered. And generally: They’d probably have a hard time upgrading their authority to that of the server.
Consider this: You could technically build a Twitter client that’d only show you things you explicitly want to see, but your filtered view is ultimately dependent on what Twitter would deliver to you in the first place. And all of this to highlight my initial point: Namely that we rarely “just” build peer-to-peer systems. In fact, when given the opportunity, the anxiety for opportunity makes us want to flee back to more familiar architectures.
EIP-20 and EIP-721’s permissioned minting
At this stage, it is important to highlight again that EIP-20 and EIP-721 have sadly shied away from canonicalizing and mandating the minting function to be publicly accessible - and sadly, this has led to many bad results. Famously in the ICO craze - with the reckless selling of PFPs and with the rise of questionable DeFi Ponzi scheme platforms that likely all implemented some sort of founder’s and early investors privilege to flip the value along the adoption curve. If null is the billion-dollar mistake, then what tragedy is the failure to canonicalize the EIP-20 minting function?
But despite all of the above criticism, I don’t want to purely paint a negative picture as to me this can now also be a moment of opportunity and a chance to course correct.
The Soulbound tokens meme is a chance for a clean-sheet design
With DeSoc and comparable philosophical ideas regarding the implementation of social power in blockchain data structures, I think with the emergence of a new token model like Soulbound tokens, we’re now in a spot where the time and will could be in our favor. And so I want to take this moment to point out interesting directions that peer-to-peer token emission through, e.g., EIP-4973’s function give(...) and function take(...) could go. In fact, a really great example that gets my imagination running wild is the countless examples of Stephen Wolfram’s cellular automata, that from simple rules, can spawn seemingly impossible structures. Convince yourselves:
And so this is where I’d like to propose heading towards the minting functions for EIP-4973. I know: for now, it must seem intimidating and unfamiliar that anyone is capable of minting a new token from an EIP-4973 contract. Anyone and with any tokenURI.
But it is also important to realize that Account-bound tokens in this implementation are hence fundamentally incompatible with the permissioned structure of classic EIP-20 and EIP-721 contracts that often put this functionality into the hands of a few privileged.
I also think that we may not even have many use cases where true p2p minting could make a difference either - but with continuing to develop this standard, I think we could end up in a spot where the implementer is capable of defining a cellular automaton-ish rule set that describes the relationship between a token holder’s social power and their reproducibility in that, e.g., DAO founders can invite new members, but members can’t.
Conclusion
In this post, I’ve highlighted the caveats that come from EIP-20 and EIP-721’s failure to define canonical minting functions with descriptive automata rule sets. I’ve defined peer-to-peer as a power hierarchy between computer systems in the context of distributed execution, and I’ve shown how client-server architectures and the prevalence of the web made us all hypernormalized into writing backend and frontend code. But I’m reflecting my criticism and I’m seeing it as a chance to improve the current systems by experimenting further with flattening the distributed systems architectures, e.g. by building smart contracts that treat all users as equally. My vision: an EIP-4973 standard that allows the implementers to define automata reproduction rules to implement social hierarchies interpretable, simulatable, and predicatable to all.