Smart Contracts as Apps
EIP-2535 (Diamond Standard) and the feasibility of a DAO Operating System
Today smart contracts are already allowing millions of people to live in a permissionless digital world, but I think this is just the beginning. Blockchain technologies are approachable just by a small niche, just like in the 80s personal computers were doing. The common thought of those who hang out in these circles is that, sooner or later, blockchains will be used on a large scale.
Today's gaps
There are several reasons why web3 is having difficulty getting off the ground, let’s try to wrap our heads around this for a bit. There are technical challenges but also social and economic hard-to-digest innovations: for example, we are used to digital services in which every transaction is free, in fact, we don't even call them transactions. Obviously, these services are not free of charge, we pay for them with our data, but despite the fact that the media have begun to highlight these problems, no one seems to care. Choosing to pay for something when you have it for free is a big step if you are not really aware of the problem.
The same reasoning can be applied to governance, today’s companies don’t have an actual need of being decentralized. The current scheme of boss-employees is consolidated in our social fabric, it’s a hard thing to change, especially when you don’t know about the existence of DAOs.
Unfortunately, the technological problems are no less severe than those listed above. Let’s start with the big problem: fees. Last year was the year of trying to cut down fees, Ethereum shared more information about how sharding and PoS will eventually reduce gas fees but the message was clear: without L2 the initial dream of making transactions for less than a dollar is impossible.
The second major problem, from my point of view, is the difficulty of use for the average user. UIs are being developed by teams around the world but they seem to me like tailor-made solutions for specific applications, and the alternative is to browse etherscan and call the contract directly.
Diamonds (EIP-2535)
Do not expect mystical solutions to the problems listed above, those issues are being tackled by people that from my point of view are like programmers’ demigods. I just want to share with you my vision of a possible future of smart contracts.
In order to understand the following idea you first need to understand what Diamonds are. You can find the official introduction from the EIP author Nick Mudge here.
What is a Diamond
To the outside world (like user interfaces, other smart contracts, and software/scripts) a diamond appears to be a single smart contract with a single Ethereum address. But internally and hidden from the outside it utilizes a set of contracts called facets for its external functions.
When an external software program such as another smart contract or user interface makes a function call on a diamond the diamond checks to see if it has a facet with that function and uses it if it exists.
Know these things to understand diamonds:
A diamond is a smart contract. Its Ethereum address is the single address that outside software uses to interact with it.
Internally a diamond uses a set of contracts called facets for its external functions.
All state variable storage data is stored in a diamond, not in its facets.
The external functions of facets can directly read and write data stored in a diamond. This makes facets easy to write and gas efficient.
A diamond is implemented as a fallback function that uses delegatecall to route external function calls to facets.
A diamond often doesn’t have any external functions of its own — it uses facets for external functions which read/write its data
Composability
My first thought when I learned about diamonds was - “Damn! These Diamonds are cool! They seem like a framework to build smart contracts”. And that led to the development of Gemcutter, a set of hardhat tasks that simplify the development of diamonds. While I was developing the proof of concept I realized that I was creating a system to install and uninstall facets to a diamond, with ease! So my mind flew again exploring a future in which normal users with a nice UI could add and remove functionalities from their DAOs.
All seems pretty cool except that there are huge problems of incompatibilities between the facets. For example, two facets that have functions with the same name cannot coexist in the same diamond, and those are not even the worst conflict issues to solve. Storage in Diamonds is a complicated topic, memory slots must be reserved for each struct and upgradability is a hard thing to achieve (but possible).
Once these problems are solved (and they can be solved), the vision at the beginning of this paragraph becomes feasible, but new problems pop up, like if everyone can cut facets onto their diamond, how can we prevent malicious facets from being added? (remember that we want the average user to be able to cut facets, so security becomes the number one priority)
The Facet Repository
DAOs allow people to make decisions democratically, we could take advantage of this beautiful fact to develop a decentralized repository of certified facets. The task of this hypothetical DAO would be the same thing as what the Apple employees are doing on apps in the review process while publishing an app on the App Store.
Then each time a facet is being cut, the diamond will check if that facet is certified. I imagine that multiple repositories will flourish creating different “facets stores”, this reminds me of the Linux ecosystem in which every distro has its own repository containing the packages available to the users.
Anyone can create a diamond and use the facets already certified by the DAO or propose their own facet to be certified and added to the Facets stores, without worrying about compatibility issues.
I know lots of people are claiming to be building the operative system on the blockchain, so I will not make the same error. But you have to be honest, is it true that it looks a lot like an OS?
Operating Smart-contracts
In order to trick you, I will call the idea Operating Smart-contracts so I’m free to use the word OS even if you don’t like it. Before giving you a nice graphic with all of the ideas above summarized, I want to propose a simple solution to the problem of facet’s functions conflict: Lenses. Instead of calling directly the diamond address I imagine deploying Lens contracts that bind to functions on the diamond. For example, we could have an “ERC20Lens” contract that has all the standard ERC-20 functions but under the hood redirect the requests to the right function in the diamond. I’ll paste here a simple implementation (in this example it’s not an ERC-20 Lens but a custom one).
contract CounterLens {
enum Function { INCREMENT, GET }
address owner;
address diamondAddress;
mapping(Function => string) functions;
constructor(address _owner, address _diamondAddress) {
owner = _owner;
diamondAddress = _diamondAddress;
// TODO: here there should be a third parameter passing all the bindings
functions[Function.INCREMENT] = "setCounter(uint256)";
}
function setFunction(Function fn, string memory diamondFn) external {
require(address(msg.sender) == owner, "Only owner can set functions");
functions[fn] = diamondFn;
}
function increment (uint256 amount) external {
bytes memory test = abi.encodeWithSignature(functions[Function.INCREMENT], amount);
// here there should be some tweaks in order to make it work
// because msg.sender changes, so the function in the diamond has to handle this
diamondAddress.call(test);
}
}Finale
All of these ideas are being developed at Habitat. Utilizing the potential of an Operating System for modular DAO tooling. As a DAO ourselves and with years of self-management experience we know that DAOs need the flexibility to solve their organizational challenges. Come and take a look at our discord and stay tuned for more updates.
 |
|