Embedded Governance Design

[georgezgeorgez]

But an important discussion nonetheless.
We should be comfortable with just sharing any idea and talking it through.

[sol]

I agree with your suggestions so far.
I wanted to suggest something similar to your transactions idea.

@georgezgeorgez

 "transactions": [
    {
      "address": "z1qxemdeddedxsp0rkxxxxxxxxxxxxxxxx956u48",
      ...
      "data": "SporkCreationDataInBase64"
    },
    {
      "address": "z1qxemdeddedxg0vernancexxxxxxxxxxxvmwpcx",
      ...
      "data": "UpdateVariableDataInBase64"
    }
  ]

@georgezgeorgez

@sol

Seems like we also need to pass the ABI for the specific method we’re calling.
Perhaps we can rely on clients to pre-format these data values?

For simple passthrough voting, the governance contract likely does not even need to interpret the data at all. It will just store the bytes and use it when it makes then downstream tx. It can be interpreted client side for UI purposes.

If I’m reading this correctly, it sounds like you’re expecting clients to format transaction inputs (arbitrary data → specific contract ABI → b64 → gov contract) correctly.
I disagree with this approach – we cannot trust a client to pass valid data to the governance contract.
Imagine completing a poll only to discover that the data wasn’t formatted correctly and the transaction was refused downstream by the next contract.

I was going to propose that the governance contract unpacks these values and does some input validation. If it fails, at least we don’t need to wait duration time to discover a mistake.
Maybe you already accounted for this. Is it a non-issue?

---

I had not considered parallel voting. What if we permitted this but constrained polls to unique transaction types/functions?
Example: cannot submit a poll to create a second spork while one is still being voted on.

[georgezgeorgez]

@sol

If I’m reading this correctly, it sounds like you’re expecting clients to format transaction inputs (arbitrary data → specific contract ABI → b64 → gov contract) correctly.
I disagree with this approach – we cannot trust a client to pass valid data to the governance contract.
Imagine completing a poll only to discover that the data wasn’t formatted correctly and the transaction was refused downstream by the next contract.

I was going to propose that the governance contract unpacks these values and does some input validation. If it fails, at least we don’t need to wait duration time to discover a mistake.
Maybe you already accounted for this. Is it a non-issue?

Seems like client vs server side validation
Where here the client itself is another smart contract.

The ProposeTransaction method I suggested is meant to handle our initial use case but also provide something extremely flexible to handle any possible situation with strict voting. You are right that it doesn’t do any validation, so the data could be bogus. I am relying a bit on off-chain verification before voting. Don’t vote on what you don’t understand (or what your client can’t process).

I remember when we tested sending an htlc to an embedded smart contract, and then proxy unlocking it. It failed and the htlc entry still existed. I’m guessing it would be a similar result if a poll with bogus data succeeded.

In terms of adding verification:
I mainly want to avoid having to modify the governance contract itself every time we have new embedded functionality. Some validation can be done on-chain through a templating system. But I think it would only go so far as ABI validation. I don’t think we want to duplicate logic for constraints on the client side.

I’ll make a post later about what that could look like.

Also need to start digging into the actual voting/update functionality.
I think next few days, will start writing pseudocode for all the methods.

[georgezgeorgez]

@sol

I had not considered parallel voting. What if we permitted this but constrained polls to unique transaction types/functions?

Well I think polls can be voted on independently.
Each will have it’s own ID that will be referenced like with AZ.
I don’t see an issue with multiple sporks being voted on at the same time.

By parallel voting I mean, that for a particular issue, there are parallel paths to resolution.
Basically a logical OR.
But a logical AND could be useful as well.

My governanceChain idea is mostly about what happens if a voteType fails to resolve.
But within a single vote type, maybe we want to say:
“This will pass if 2/3 of pillars AND 2/3 of sentinels vote YES.”
or maybe
“This will pass if either Group A votes for it OR Group B votes for it”
which could model some of the admin vs guardian safety measures where we don’t want to wait for one group to either act or not, before allowing another group to.

Ideally we could have some config that composes together these building blocks.
maybe a future voteType 2, could be a meta vote type where the voteParam takes in a flexible config of building block voteTypes

again my goal is to have something that takes care of us now, while being designed in a way that it doesn’t have to be torn down in the future if we do have more complex needs

[sumamu]

Please wait for me. I’ve been busy with the affiliate program, but I’ve got some ideas to share about the governance module.

A lot of interesting concepts have been shared around, however they are too complex.

The governance module should be a simple AZ fork with some minor changes and that’s it. Easy to implement and already battle-tested.

Any other option will require a ton of unit-tests and manual testing. Not to mention development.

I’m speaking from experience when I say new embedded designs require a LOT of work.

Don’t make that mistake.

[georgezgeorgez]

The purpose right now is to explore the design space as much as we can within our timebox ending July 4.
What are all the different high level approaches and the trade-offs for them?

What actually gets implemented is up to proposers.
Development complexity is certainly a trade-off to consider.

We’ve already considered what a simple pass-through implementation could look like.
The trade-off with that is it means all future admin functionality will require additional work on the governance embedded.
I don’t think it’s going to be as simple as implementing sporks, bridge, and liquidity admin functions and then the problem is solved.

The requirements for governance are also more complex than AZ. What if we have to quickly spork for a critical bug fix? Remember that a spork that gets activated without implementation halts the network.
We also see possible issues with the existing mechanism of AZ. E.g notably that there are incentives to simply not vote at times. And there are some discussion to change how AZ works.

I agree there are more urgent things than accounting for all these nuances right now.
But I think maybe we can create an iterative path or approach that can quickly fit out immediate needs, but that also leaves enough of an interface for us to grow without having to rip out the old system.

My personal goal is to have something shippable by end of July.
But I will consult the pillars about what they want.

My own experience with developing embedded contracts is that once the requirements are clear, implementing them is just busy work and a matter of time spent.

If we take a very simple approach right now and kick a more sophisticated approach down the road, maybe doing them as separate embedded would make sense, if the underlying mechanisms are not compatible.

[georgezgeorgez]

As part of this design phase, I’ll whip up a simple implementation this weekend.
Will be a good exercise for me to better understand the voting / update mechanism.

If people think it’s enough, then anyone can propose to productionalize it.
Or it can serve as a base for something more sophisticated if we want to go that direction.

[georgezgeorgez]

@sol btw

Blaming go-zenon/vm/embedded/definition/common.go at master ·...

There is already a VoteNotValid vote type

edit: oh but it seems just to be used for error handling

[georgezgeorgez]

And also I forgot that we can use stuff like “hash” as the type for ABI
Can use that to limit or eliminate our need for flexible json
better to vaildate with the abi than with json-schema if we can

[sol]

Can we use GetEmbeddedMethod?

[aliencoder]

@sumamu

Please wait for me.

And for me. Been busy with other dev stuff. I will review the discussion on Monday and share my thoughts about the governance embedded.

[georgezgeorgez]

How about we push the discussion timebox out a week ending July 10?

[georgezgeorgez]

Making good progress on the PoC
Will have something to show tomorrow or day after

[sumamu]

@georgezgeorgez

How about we push the discussion timebox out a week ending July 10?

I love this!

[georgezgeorgez]

@georgezgeorgez

Will have something to show tomorrow or day after

Didn’t touch my computer for the last two days (wasn’t feeling great lol) so still need to finish up.

But as I’ve been doing my PoC, I’m thinking about a great point @coinselor brought up:

@coinselor

2. Delay Period: We should consider implementing a delay period between when a proposal is accepted and when the changes are implemented. I think this should be different than the time until the activation height. The benefits of this delay would include:

One design consideration is that different type of governance actions have different delay needs. Spork Creation likely does not need any delay after the voting period. But Spork Activation definitely needs one as people who voted NO have to decide whether to upgrade or fork out.

My PoC uses a similar mechanism to AZ, but one thing that AZ does is during contract updates, it sends transactions without a delay period. To account for this, there needs to be another status type, where the Vote has succeeded, but the transactions still need to be sent.

[sumamu]

I still haven’t gotten to this, yet, so I’m just going to share some thoughts here:

• pillars produce the momentums, so in case of a spork activation, we’d still need most of them to run the new binary
• contrary to the popular belief in the community that pillars are not active, may I point out that pillars have a very high uptime and more than 50% of them managed to run the orchestrator in ~1 week

The governance module should be both simple and versatile

• it’s primary purpose should to activate sporks
• secondary purposes to govern any embeddeds

It can achieve that by simply publishing an AccountTemplate that is included in the proposal.

Changing variables and other values in the network should not be included in the governance embedded, but a separate embedded which is governed by it.

[Bzed]

@sumamu

Changing variables and other values in the network should not be included in the governance embedded, but a separate embedded which is governed by it.

May i ask what is the motivation to add a seperate embedded for changing a constant to a variable?

[sumamu]

The responsibilities of the governance module should be kept to a minimum. Having a separate embedded contract for changing the network settings helps us keep the governance module simple and it also means we can focus on delivering it faster, since we can do the network settings embedded later.

At the moment, the governance module is mainly needed for:

• activating sporks
• governing the Orbital
• governing the Bridge

[coinselor]

I would love for more than one (George) dev to drop their version of the embedded governance contract, especially if it’s only pseudocode. I’m sure we have more than one capable dev, and this is a critical infrastructure for the network.

Sure, we can wait for George to drop his version, and improve upon it together. However, I believe having two or more separate concept versions would make the final results a lot better.

Remember that George is advocating for more flexibility down the line, while others like sumamu prefer a strictly minimal implementation for the first iteration.

[sumamu]

How’s it going so far? I’m willing to follow along if the code’s public on GH.

There are lots of things to do for this ecosystem, so resources should be used efficiently.

Having more devs work on the same thing means they’re not working on other stuff.