At the point when we founded DAOstack at the beginning of 2017, we had two main insights about DAOs. The first was that Decentralized Autonomous Organizations (DAOs) are the most important use case of the blockchain after currency, and the second was that it is impossible to predict what these DAOs will look like, and that there will be a fast evolution of them. As a consequence we decided to build Arc, which is a generic platform for DAOs on the Ethereum network.
The notion of Arc is to be a modular, easily upgradeable platform that allows for a rapid natural selection of governance systems. We are creating an open library of interoperable components that will enable new organizations to be built quickly and easily. This is somewhat like the WordPress model for websites. We chose to name it Arc after the Greek word arche.
Architecture
Architecture is probably the biggest challenge when building infrastructure. We needed to build a platform that would be flexible enough and fit all the different types of organizations and ideas regarding governance. The key word is, again, modularity. After a long and iterative process the current version of the system takes this form:
First notice that every box in the figure is a contract. (To be precise, they could also be proxy+logic contracts.) The three contracts on the left are the token, reputation, and avatar, which we call the actors (or organs). Token probably does not require an explanation, being the most popular use case of the Ethereum network, but reputation and avatar do.
An avatar is the face of an organization on the blockchain, e.g. if the organization is to hold ownership of anything, like ownership over a contract or asset, the address will be that of the avatar.
Reputation requires even more explanation, as different people use the word ‘reputation’ with very different things in mind. In Arc, reputation represents your decision power in a given DAO. It is one-dimensional, which means there is a simple map between addresses and numbers. It is very similar to a token, with two main differences: one, it is non-transferable, and two, it can be granted or taken away by the DAO.
On the right side of the figure we have the schemes. Schemes are simple pieces of logic that comprise the different actions that can be executed within a DAO. One example of a scheme is an ICO scheme, whereby an agent who sends ETH to a DAO receives tokens of the organization in return. Another example is a scheme for funding proposals, in which everyone can suggest and vote on proposals, and if a proposal is approved it is automatically funded.
At the bottom there are the global constraints. The concept of global constraints is almost forced when considering modular logic, as one generally wants to prevent the modules from breaking certain overarching rules. An example is a cap on an organization’s total possible reputation, or a maximum burn rate of an organization’s funds.
Next we have the controller, which is an access control module. It keeps a record of all the registered schemes in a DAO as well as the permissions for each scheme. In addition, it keeps the record of all global constraints and enforces them by reverting transactions that violate any of them.
The last type of components are voting machines, also called governance modules. These components allow for the modularization of the decision-making process, allowing for fast iterations and development of such modules. The main kind of voting machine implemented today is based on the Holographic Consensus protocol, DAOstack’s core model for decentralized governance.
Code recycling and gas efficiency
One of the first questions to consider upon building a smart contracts platform is on the matter of code recycling. Building shared components has many upsides, but it also raises challenges in the areas of added complexity, security, efficiency and ease of use. Two main approaches can be considered.
One is the Contract as a Service (CaaS) approach. In this concept, a single contract is used to serve many organizations/agents. As an example of a CaaS, think of a multi-sig contract that holds balances for any group that wishes to use it, instead of each group deploying its own contract. This saves a lot of gas on deployment, as the contract is only deployed once for everyone to use. There simply needs to be a parameter added to each transaction indicating which wallet is being referred to, which can be done at a very low gas cost. The main downside of the CaaS approach is that it makes the contract a bit more complex, which can have a security cost. In addition, it can create challenges when building interoperability between contracts, as the blockchain standard is that an address represents some “identity”, and here we have a single address representing several identities.
The second approach to code recycling is the proxy approach. In this approach one is deploying a logic contract along with proxy contracts which only make delegateCalls to the logic contract. This approach costs less gas on deployment than keeping a separate contract with all the logic in it for each instance, but it does cost a bit more on each transaction, due to the addition of the delegateCall. The cost of gas of the delegateCall is most problematic in ‘transfer’ calls, which are limited to 2300 gas (an issue for which recently we proposed a fix on Github). Another downside of the proxy approach is the additional complexity in coding, and especially initializing, the contract.
The current Arc release uses the CaaS approach. We are in the process of heavily researching the proxy approach, both for the reasons mentioned above and because this option would also increase upgradability (which by the way has its own pitfalls and complications as well).
Security
The main advantage of a modular system is that it is much easier to audit and make secure, as simple pieces can be examined and tested thoroughly. This is of course not a guarantee, but it is an approach to tackle the problem. This approach was put to the test in an intensive audit by the experts at ChainSecurity which Arc passed.
In any case, our main approach to security in DAOstack is testing by fire, which means putting the code out there in the real world, with real money on it, intending that people will try to break it and thereby help us find bugs. We intend to slowly increase the amount of funds on our contract, as we gain assurance that they are safe.
Roadmap
Arc is still an alpha release, which is under code name Genomics. The next big release, under code name Genuine, contains mostly improvements in the areas of modularity and upgradability. It is aimed for Q2 2019, although at current pace it will probably be released sooner.
