🏗️Upgradeable Architecture

Upgrading to the futures!

While the Web3 landscape holds immense promise, it is not without its challenges, and we are at the forefront of this ongoing battle. Before delving into our architectural solution, let's examine the pressing questions that underlie these challenges.

Upgradability Issue in Ethereum

One drawback of the design of Ethereum is that smart contracts, which are self-executing computer programs on the Ethereum network, became challenging to maintain because it's immutable. It made it difficult to fix bugs or make improvements because all the code had to be completed at once. This made it nearly impossible to create large-scale contracts with tens of thousands of lines of code, unlike simpler contracts with only thousands or hundreds of lines.

As a result, innovation within Ethereum was limited to what could be done with shorter code, and more complex innovations requiring longer code weren't explored.

We need to address the issue at the application level, which is the correct way to think about solving it. Some entities have introduced the proxy model in smart contracts to try and solve the problem. Yet all existing solutions make project owners the focal point, allowing their developers to leave a backdoor, or option, for themselves to replace the original contract if necessary. However, this approach goes against the original intention of Ethereum, which was to be decentralized, and it can be quite risky. We describe it as Centralized Development, which is a side-effect that we need to address.

Centralized Development

Our team thinks the major issue in web3 is having a centralized entity to write and deploy the Dapp and this Dapp logic is immutable. That’s very detrimental if we just think of the possible bad consequences. Below are several of them:

1: A team deployed the buggy smart contract (they were not aware of) and let users loose several million dollars.

2: A team purposely writes malicious code in a smart contract to gain the advantage of users. We see many rugged projects acting this way.

3: A team might write the “good contract” in the beginning, but as time progresses, the existing contract architecture may no longer be suitable for project development. All these issues are the fundamental issues of web3 suggesting we have fake decentralization when we talk about Dapps.

In fact, we are able to solve this problem. We only need to place public power under public supervision.

There are 2 scenarios that could happens in terms of upgrading the smart contract. The first scenario is to change the parameter in smart contract. The second scenario is to change the entire code. these 2 scenarios should be addressed differently.

Full Parameter Automation Architecture

in the case that we just need to upgrade parameter, each party (community, approvers, implementer, topic team) have the right to accept or revert the prior step decision. making the decision making process robust.

Fully Decentralized Scalable Architecture

Two key main properties should be included in the solution:

1: Avoiding to have one centralized entity to write and deploy the contract.

2: A robust mechanism that allows for manageable and traceable modifications to the smart contract to address the code upgradability.

Luckily, the current mainstream has already developed solutions for safely altering smart contracts while preserving transaction data. These solutions include the OpenZeppelin transparent proxy pattern and ERC2535. The primary challenge now is addressing the issue of relying on a single centralized entity for contract creation and deployment. To tackle this, our approach involves the creation of a decentralized role-based DAO (Decentralized Autonomous Organization). This DAO enables collaboration among various developer teams, auditing teams, and the small congress group from the community to collectively participate in the creation and deployment of smart contracts. This DAO also seamlessly integrates with existing ERC2535 Diamonds, Multi-Facet Proxy pattern.

A trustless onchain decentralized Role-based DAO for upgradability

Apart from those two primary attributes, when designing a DAO like this, it's crucial to meet an additional condition: even though we can't guarantee that each role won't act dishonestly or in their own interest while making decisions, it's essential to ensure that every decision made within this decentralized Role-based DAO system is trustworthy. let's look back our architecture to see if it satisfy this condition:

  • The normal community members do evil with proposal topic, let's say they raise toxic proposal-topic: the role based "approve“ group would likely deny such a proposal topic. Even if, by chance, this group were to approve the proposal topic, no immediate harm would take place. This is because at this stage it's just suggesting a proposal topic without a specific proposal instance beneath it wouldn't lead to any changes in the code or system.

  • The normal community members do evil with actual proposal itself: let's say, they raise toxic proposal: the role based "approve“ group would likely deny such a proposal. even if they approved such a proposal, according to our upgradeable architecture, this proposal is raised under the certain proposal topic. The related proposal-topic role-based group would likely deny such a proposal.

  • The normal community members and the role based "approve“ group do evil and collaboratively raise and approve a toxic proposal: according to our upgradeable architecture, this proposal is raised under the certain proposal topic. The related proposal-topic role-based group would likely deny such a proposal. and both role based "approve“ group and The related proposal-topic role-based group are fully decentralized group, not controlled or dominated by a single entity.

  • The onchain developer role do evil and propose a malicious code: first of all, economically speaking, this doesn't make sense at all, as both community and our tokenomics provide economic incentive to reward the developers who provide good code solution. even if they do raise such a proposals, the onchain Auditor would likely to deny the malicious code proposals. since their job is to auditing and reject the bad code and our tokenomics provide incentives for them to do so.

  • The onchain Auditor role "do evil" and approves the malicious code from onchain developer role: first of all, they are unlikely deliberately to approves the bad code as our tokenomics provide economic incentive to reward the auditor who does good auditing work. secondly, even if they neglect some possible loophole in code, The related proposal-topic role-based group can still reject their approvals. in our design of this decentralized Role-based DAO system, we will also minimize the neglect from the onchain auditor. one of the possible reason for neglect is one auditor party receive too many auditor works that they can't handle, our decentralized Role-based DAO system take care of this situation by having a fair random selector algorithm to select the Auditor who work on specific proposals

  • The related proposal-topic role-based group do evil: this is unlikely to happen. This is highly improbable. We've engineered our design to ensure this group remains fully decentralized. Plus, we have thorough procedures in place to guarantee that everything is in order before it reaches their desks.

When we take the actual implementation of this role-based Dao, The infrastructure of this role-based DAO should be fully decentralized. The infrastructure would be applied to the role based "approve“ group, The related proposal-topic role-based group and each member in this role based group has equal right to vote. to achieve this, we have fixed several loopholes and issues from the original openzepplin access control mechanism and brought in this decentralized access control with below repo: https://github.com/SplatterProtocol/decentralized-access-control

also, we should consider to integrate the authentication layer. By incorporating such authentication protocols, we establish a robust system that ensures individuals cannot hold conflicting roles simultaneously. For example, to prevent situations where the same individuals hold both the on-chain developer and on-chain Auditor roles. This authentication layer adds an extra level of security and trust by verifying the distinct identity of participants involved in different roles within the decentralized system.

Implementing authentication measures like Sismo Connect or DID helps maintain the integrity and reliability of our decentralized Role-based DAO system, reinforcing transparency and trust among all participants.

Last updated