Discussions for the future of governance

General
#1

In light of @preston’s RFC-000-009: Verification and Privatization of the Forums, I believe there can be productive discussions about the future of Governance. The comments here would serve as feeder information for potential ideas of how we can align and structure governance in the distant future. I don’t believe decentralized governance is in the short term goals, and I personally hope that the Ren team maintains control over major decisions for the foreseeable future.

Please keep in mind that it appears that the Ren team does not currently prioritize verification or privatization of the forum per @loong’s message below:

Given @loong’s comment, perhaps we can shift the focus, instead of aiming to verify/privatize the forum, we can discuss the factors we’d like to consider for shaping governance in the future. I can start off:

Future governance based on

  • Node count
  • Multiplier for age of node (# of epochs online)
  • $Ren token held (% Discount compared to node as node is more invested in the success of Ren) (with clarification that token must be staked in some fashion such as a potential underwriting pool that takes on risk to support the security of the project per discussions with jhv.st and Loong below)

Perhaps node vote weight can be determined by something like:

image

Where,
Ø(z) = weight in voting

Thus,
Ø(-6) = 0 epochs = 0 weight
Ø(0) = 6 epochs = 0.5 weight
Ø(6) = 12 epochs = 1 weight

This weight would then be multiplied by the # of nodes.

Example: 10 nodes at 6 epochs would be worth 5 votes.

Decisions based on discussions

  • That are open to wider community (including external parties that visit the forum)
  • Collaborative and open discussions that support each others’ arguments, and even if they are against your argument, provide data/analysis/facts/logic to counter the arguments to contribute to greater collective understanding

This is just what I’ve brainstormed with some folks initially. I’d love to get more of the community’s opinions weighed in. Thank you to @fuzzylogic, @mitche50, @Ruzo11, @alexander, @MaxRoszko, @davoice321, @shiny, and @akinsawyerr for the initial discussions; please feel free to add your own thoughts below.

Again - please remember this is for discussions purposes only and will likely not be a short or mid-term focus. The motive for this post is to have community ideas compiled and collaborated upon. :slight_smile: :frog:

1 Like
#2

Seems fine if the developers can come up with a way to rebase back to 0 the token within a wallet depending on if the node goes inactive.

1 Like
#3

What’s the argument for unvested REN tokens having voting power? If the point of running dark nodes is to establish a good trust model, doesn’t passive token holding undermine that goal by increasing the upfront cost? Especially with flash loans it seems like unvested token holders having a vote is an attack vector, see what happened with Maker recently.

1 Like
#4

Sounds like a plan. Let’s not get over eager to build perfect gov out of the gate.

Fees as well will take time to get right. The priority is integrations and getting to a more mature and solidified position as the leader in interoperability.

This is a long game. Folks that want $10 REN tomorrow will have to adjust their time preference.

Buy REN while it’s underpriced. :slightly_smiling_face:

3 Likes
#5

You make a good point, and I think this would depend highly on whether or not an updated version of @loong’s RFC of continuous payments move forwards which would enable partial staking.

Like I mentioned, a discount, potentially significant, should make this better balanced.

#6

It’s good that you mentioned discount. I think that in the worst-case scenario any discount is irrelevant as long as the token holders have any say. To me, a discount seems like cutting corners when it comes to estimating the significance of threat models that flash loans pose: if REN is loanable and REN has voting power, and there exists a token T which has a direct or indirect loan market against REN, then the minter of token T might act maliciously to temporarily mint tokens T such that they can swap the newly minted T against REN to have a way for their say. So, if the swap market exists and token T is mintable, then the discount is irrelevant because the minter can summon enough tokens to off-balance the discount rate.

EDIT: And to not merely bash on the idea, I think that vesting is essential to avoid this from happening, since it allows enough time for the market to react to the malicious attempt.

#7

I think you’ve already hit on the easy solution for mitigating this risk. I understand Maker had this issue recently. Perhaps, we can keep an eye on how LongForWisdom pushes for a solution.

I personally think requiring collateralization for a period of time easily mitigates this risk.

Maybe one clarification I forgot to mention - the discount on Ren token voting power would apply only to Ren tokens that have been staked IF there is ever an option for partial staking at all. Hence my comment:

If there is no partial staking, I see no reason why a Ren token on its own should have voting power at all.

1 Like
#8

It is impossible to avoid the fact the someone’s ability to govern RenVM is directly related to the number of nodes that they operate. Consider:

If you own zero nodes you have zero ability to influence how the nodes behave. If they want to do X, you cannot stop them running upgraded software designed to do X. On the other hand, if you own all nodes then you have all the power. The protocol is whatever you want it to be, because no nodes exist that can behave otherwise.

There are, of course, exceptions. Some rules can be enforced by clients (people interacting with RenVM), and some rules can be enforced on Ethereum proper (for example, this is where REN bonding happens). Nothing can be done to control client-based rules. You run the client that enforces the rules you want, and if others are doing the same, then you’re all good.

The end result is that “who governs” is highly depending on “what” is being governed. If it is a rule defined on Ethereum, then we can design whatever kind of governance system we want. If it is a rule that is enforced by the “honest majority” then it is solely up to node operators and the power to govern is directly proportional to the number of nodes controlled. If it is a rule enforced by clients, then everyone governs independently by running the client they see fit to run.

EDIT: I realise this does not provide any opinions one way or another about the specifics laid out by OP, but it is something that must be considered whenever governance models are discussed.

3 Likes
#9

For rules enforced on Ethereum, REN token holders should be able to participate, but only if their REN is bonded to the system in a way that bears risk. Otherwise, no incentive exists for them to govern in the interest of the system.

An example of this would be underwriting, where REN holders can bond their REN to an underwriting pool (essentially an insurance pool that counts towards TVB without actually running a node). The amount of REN multiplied by the number of epochs the bond has been committed to increases their voting power (in a sub-linear way, to protect against “oligarchs”).

1 Like
#10

Agree with your points and appreciate the elaboration in Eth vs RenVM governance. It helps clarify/structure how we approach governance.

Are you suggesting we consider the graph I posted only from points 0 to 6 on the x axis? I’m open to it, but then the question just becomes at what rate it grows (how much we stretch out the growth curve measured in epochs to the point of plateau)

Edit: FYI @loong and @jhv.st, I edited the original post to include the underwriting pool / requirement for staking to vote clarifications per the discussion above

#11

The general wisdom I’ve seen on sub-linear voting power has been to use a square root decay, not an exponential decay. For example:

Power = Sqrt (Bond * Epochs)
1 Like
#12

So then the other half of the chart… as illustrated on the -6 to 0 of the x axis.