RFC 1: Smart Contract Plugin System Architecture

[JMKJR]

RFC 1: Smart Contract Plugin System Architecture

@labs3/daoos

Abstract

Decentralized Autonomous Organizations (DAOs) using the daoOS platform will wish to have individualized governance solutions. A one size fits all approach to governance does not embrace the decentralized, organic, and autonomous ethos of web³. Amongst all DAO's there exists common protocols such as proposal voting. This RFC presents a high level Clarity based Smart Contract Plugin System (SCPS) solution to customizing the underlying behaviors of common procedures present in such protocols.

Design Proposal

The core functionality of the SCPS will be delineated through demonstrating a limited feature set of SCPS enabled behaviors for the familiar DAO voting protocol. The proposed SCPS allows us an audited suite of contracts known as plugins obtainable through an in-app marketplace. These plugins are to be injected into the customizable portions of these protocols. The voting protocol we will use as an example is as follows...

1. Proposal - An authorized DAO member whom we shall refer to as the "proposer" brings forth a measure to be voted on in the form of a smart contract. The "proposal" plugin can be any logic cemented in smart contract code that is meant to execute as a result of a passed vote. For example, this logic can be a treasury transaction proposal or a project initiative with ascribed milestones.
2. Voting - A voting procedure follows and if the measure is passed, proposal initiation logic is executed by an authorized DAO member from the frontend. This procedure represents another injection point, in this case, for voting plugin logic. Some DAOs may opt for a simple percentage majority model, while others may opt for more complex approaches such as weighted voting using voter principal ownership of some Fungible Token similar to corporate shares.

Because all DAOs follow the same protocol of proposing and voting, we are presented with customizable injection points for smart contract plugins via our SCPS. Although voting is the protocol in consideration, it is likely there exist other common protocols within the daoOS governance feature set that will also present ripe territory for SCPS facilitated plugins. We will explore the proposed architecture further through a diagram below. In this architecture, we concern ourselves not with how members are authorized, how plugins are obtained from the marketplace, or the intimate logic of the plugins themselves. For brevity, we seek only to demonstrate brief functionality of how the protocol may interact with plugins such that we establish a conceptual understanding of the proposed architecture.

Voter - a DAO member authorized to vote on a proposal.

Proposer - A DAO member authorized to bring forth a proposal to be voted on.

Frontend - This is the UI of the web app our two types of actors are using. In this case, the UI in question is a single page of a voting/proposal flow. You can expect to find, at a minimum, yes/no buttons, a discussion thread, proposal contract source, as well as any various proposal plugin inputs in question that will be voted on and required to send to the proposal plugin contract. Frontend elements such as yes/no buttons will trigger a contract call to a single plugin contract function matching a specific method signature. The desired plugin contract function address (for example cast-vote) is known as a result of installing, configuring, and launching the contract of the desired plugin. Because this plugin contract is known at runtime, it can be statically dispatched.

Voting Plugin - This voting plugin contract may contain just the one function (cast-vote) or more. It may also maintain and mutate voting state in creative and customizable ways (time-to-live of vote, etc.). The voting plugin in this case would of course contain whatever authorization validations that are desired in the cast-vote implementation (voter principal must be in DAO, or have some token, etc.). The contract could also serve as an immutable historical record of a proposal voting outcome with getter methods exposing historically useful pieces of state.

Proposal Plugin - The call to initiate the proposal can be executed at any time from the frontend by an authorized member but it will call the get-verdict getter of the voting plugin from within the initiate function of the proposal plugin to verify that the vote has indeed passed as well as perform necessary tx-sender authorization checks. Malicious attempts to initiate the proposal early would result in wasted STX. Successful initiation of the proposal after a passed vote sends over the agreed upon inputs for the proposal contract to handle according to its measures.

Conclusion

A Smart Contract Plugin System was proposed for injecting customizable behaviors into common protocol procedures. This is architecturally accomplished through frontend initiated contract calls to plugins installed from a marketplace configured for injectable points in the flow of the application (button clicks, etc.). We demonstrated how a few such customizable behaviors/plugins might look in the well known voting/proposal protocol.

Suggested Points of Discussion

• Any general questions.
• Are there any Clarity anti-patterns present?
• Do we agree on the need for a plugin system? Any more optimal solutions?
• How might a plugin marketplace look? How are contracts audited? Should unaudited contracts be allowed and just show the installed plugin source code on the same screen as the voting flow? How should plugins be fetched for display in marketplace; who can add them?
• Have a settings page to specify current plugins and allow ability to modify them from new proposal flow?

Apologies if I've not done the C4 model justice and for using lazy method signature syntax, just trying to visually express the architecture succinctly. I chose an RFC format in lieu of a "feature request" since I felt it was a better fit but let me know if we wish to strictly stick to feature requests per our standards.

[cryptopanter]

Thanks for your contribution...I realize the first paragraphs as two major points we can simply shorten them as: 1-proposal: Something that could be voted on 2- Voting that could be done simply one-to-one with users or as weighted voting biased more into users with special traits.
But didn't realize this part "...Although voting is the protocol in consideration, it is likely there exist other common protocols within the daoOS governance feature set that will also present ripe territory for SCPS facilitated plugins...". Would you elaborate more?

[cryptopanter]

Also if the block containers are parts of software system then i guess they should be included in a dash-line boundary (regarding LS3-02 standard) . what you think @314159265359879 ?

[JMKJR]

But didn't realize this part "...Although voting is the protocol in consideration, it is likely there exist other common protocols within the daoOS governance feature set that will also present ripe territory for SCPS facilitated plugins...". Would you elaborate more?

Sure! Here are two examples of protocols different from voting to consider that may benefit from SCPS:

1. A DAO reputation system. This is one of our user stories in backlog. I am neutral on the concept but my point is that DAOs using such a system may want to customize how reputation works with plugins.
2. Minting your own DAO token from within the platform. I'm not sure if we have a user story for this but I know it came up in conversation at one point. DAOs may wish to have customized behaviors around the token minting protocol.

[JMKJR]

Also if the block containers are parts of software system then i guess they should be included in a dash-line boundary (regarding LS3-02 standard) . what you think @314159265359879 ?

I can update the .png to include the dashed lines. Do they go around all 3 containers? :)

[Zk2u]

I can update the .png to include the dashed lines. Do they go around all 3 containers? :)

Details on containers here.

[friedger]

I like the encoding of proposal in separate smart contracts, together with the role based access control this could work.

To me it is not clear how the proposal "knows" which voting plugin to call. It would be better to have the initiate function in the voting plugin.

Example:
Voting plugin: "simple-majority"
Proposal: "Transfer 10STX to cryptopanter"

How are the funds transferred from the dao's contract? Who has permission to do that?

1. Everybody calls (cast-vote yes/no SP1234.proposal1) on SP5678.simple-majority
2. votes are recorded and verdict is stored in SP5678.simple-majority
3. Somebody calls (initiate SP1234.proposal1) on SP5678.simple-majority
4. if the proposal was accepted the voting plugin
   1. gives permission "stx-transfer" to the proposal
   2. calls initiate on SP1234.proposal1
      1. The proposal contracts can call the stx-transfer function on the dao contract.
      2. The dao contract verifies that the contract-caller has permission to call stx-transfer.
   3. revokes permission "accepted-proposal" from the proposal

[LNow]

We need one central contract (Core-ish/Kernel-ish) in which we could "register" our plugins. It will also provide most basic and crucial functionalities.
Each plugin must keep a reference to this central contract.

If Plugin A wants to call some function in Plugin B, first it has to ask Kernel for its address.

Same approach can be used for checking permissions and other basic functions ie. If Plugin A wants to check if user ABC is allowed to call transfer it asks Kernel, and Kernel as our central point knows exactly how to verify if user is allowed to call this function or not.

Moreover I believe that each plugin must have set of standard plugin functions (preferably defined as trait) such as:

• get-version
• get-name
• setup/initialize/init/initiate

If we'll think about proposals as actions that should execute themselves or become executable after they have been voted on we some sort of register/registries in which we could store all proposals prior execution.
For example:

• TransferActionsRegistry - for all transfer actions
• RBACActionsRegistry - for all RBAC actions
• MintingActionRegistry - for all actions associated with token minting
• etc.

Then we could create a dedicated roles with limited permissions:

• TransferRegistryRole - with permission to execute transfer in vault contract
• RBACRegistryRole - with permission to call functions in RBAC contract
• etc.

To summarize here is oversimplified (without any security checks or calls to Kernel contract) we could handle transfers:

[JMKJR]

To me it is not clear how the proposal "knows" which voting plugin to call. It would be better to have the initiate function in the voting plugin.

We could put initiate in the voting plugin and have that get executed once a verdict has been reached. I like that better. But then we should should have a function initialize to replace the initiate call from frontend to proposal so that way the proposal can be initialized with the agreed upon arguments. These arguments should still be sent/initialized directly to the proposal instead of passing them through the voting plugin so that voting does not have to mantain state belonging to proposal. This makes the plugins more reusable. In this new scenario, the voting plugin knows what proposal contract to call to initiate because these plugins are configured/installed/deployed from the frontend, and these actions could be performed in a UI/UX friendly way such that the proposal plugin is deployed before the voting plugin so that the voting plugin knows the proposal's address and can statically call it to initiate.

How are the funds transferred from the dao's contract? Who has permission to do that?

Assuming you are talking about a DAO treasury proposal, maybe the treasury is its own smart contract principal with public functions for spending and such that can only be called as a result of tx-sender being a DAO approved principal of a passed proposal. Is this what you are describing below here? If so, we are on the same page :)

[JMKJR]

@LNow Nice. I like this solution for maintaining a registry of types of plugins and integrating them with our RBAC. I really like how this is all coming together, great work!

[JMKJR]

Seems like close to 100% of our smart contract logic powering daoOS will be the cooperation between RBAC, SCPS, and Treasury. Do you all see this the same way?

[Zk2u]

Yeah. These will all be in the central contract, right? That's the best way to do it.

[MarianoArg]

Awesome work here! I'm really a noob speaking on blockchain and DAOs, so I will drop some questions and I apologize if they are dumb.

• How do we know if a user is authorized for voting/proposing? Are we creating and storing roles in a DB? It sounds like we need to build a small backend.
• We are talking about plugins, I think plugins are what we call services (or micro-services in this case). Are we building those by ourselves? We might want to have those decentralized.

[LNow]

How do we know if a user is authorized for voting/proposing? Are we creating and storing roles in a DB? It sounds like we need to build a small backend.

We will have a RBAC (Role Bases Access Control) mechanism build with clarity. So it will be a matter of granting someone a specific role ie. VOTING_MEMBER to grant him or her all permissions which are needed to vote, or MINT_OPERATOR if we would like grant someone permission to mint tokens for us.

We are talking about plugins, I think plugins are what we call services (or micro-services in this case). Are we building those by ourselves? We might want to have those decentralized.

Yes we want to build them by ourselves. And once again - we want to keep all logic in clarity contracts.

[JMKJR]

Awesome work here! I'm really a noob speaking on blockchain and DAOs, so I will drop some questions and I apologize if they are dumb.

• How do we know if a user is authorized for voting/proposing? Are we creating and storing roles in a DB? It sounds like we need to build a small backend.
• We are talking about plugins, I think plugins are what we call services (or micro-services in this case). Are we building those by ourselves? We might want to have those decentralized.

You are correct in thinking of our authorization and plugin models as belonging to a conceptual "backend". However, this all needs to be decentralized so this backend logic is powered through smart contracts written in the Clarity language. This is where we differ from traditional centralized microservice solutions.

[JMKJR]

I'm really a noob speaking on blockchain and DAOs, so I will drop some questions and I apologize if they are dumb.

Also, I don't believe there are such things as "dumb questions" :) . These are all good questions and you should never hesitate to ask anything around here; I know I will!

[MarianoArg]

Clear like water, it seems like I need to read more about Clarity. Thank you for taking the time to explain this, it was really helpful