Hi David, it’s great to see some of what you’ve been spending so much time working on. I am excited about increased decentralization, security, and incentives for more people to hold and stake REN tokens. I have a few questions.
-
I saw you mention that Ren Labs helped with a few updates that will make Renbase a bit easier to implement, which is great. Since running a DN is permissionless, would Renbase need any permission or cooperation from Ren Labs or the community to fully implement? My inclination is that it would not since anyone can spin up as many dark nodes as their bond supports.
-
You answered Sabobi’s question that Renbase would have no central components in its final stage. Will the collected Renbase stakers and operators be able to modify the code for further updates/refinements/security-patches once that state is reached through coordinated cooperation or internal Renbase governance?
3.) Will operators be manually registering and deregistering at the epoch changeovers, or will some of this be done via smart contract or some other form of enforcement? I picture their bond/collateralization being tied up in the smart contract, and they would receive an edict or set of requirements to manually execute to remain in good standing. To what degree would their manual intervention be necessary? Could you elaborate on this at all?
4.) In the final state, operators will be able to come and go like stakers according to the constraints of the smart contract and the market forces that rewards participation/etc?
5.) For Renbase’s own decision making and operation, will it have its own treasury or collect a percentage of Renbase rewards to fund it? Do you picture a Renbase token to perform any function of that internal governance or for use in funding the operations?
6.) Related to SeekingKnowledge’s question – I am very interested in how incentives might be created on purpose or accidentally that could lead to the collected Renbase participants acting as a single voting bloc that could hurt the decentralization or security of the Ren network. My concern is how something as seemingly informal as a “Hey fellow Renbase users, can we come to a consensus on how we should vote for RIP #116?” could lead to a sort of Renbase default position rather than each Renbase user coming to their own conclusion about the best decision to make for the health of the overall Ren network. It is natural that a Renbase user might have a particular incentive to vote one way or the other, but have you given any thought to how Renbase could be aligned in way to prevent the coalescing or grouping of such a large number of network participants into one bloc and the perverse incentives that could create for governance or security? Do you have any thoughts in how it could prevent that sort of single-minded-vote-accretion? I ask this in the context that there are of course natural self-interested reasons why group members might be incentivized to speak with a voice that carries the same weight as their collected network participation.
7.) In answering Sabobi’s question #3 – do you mean giving Renbase users voting power in addition to the already-existing permissionless voting power that the Renbase DN operators would already have? Because governance participation is permissionless and available for DNOs to participate in, I don’t see that Renbase stakers or operators acting on their behalf could be prevented from participating in governance (nor would we want them to be since increased participation and decentralization of voting is useful to Ren overall in a similar way node operating and validation will be), or are you suggesting that the ability for Renbase stakers/operators to participate in Ren governance might be contingent on RenDAO’s permission?
8.) Related to shiny’s question – Can you elaborate more on what would be required of operators? You mentioned sufficient collateralization. Do you foersee that being 100% or more than the 100k required for a dark node? It seems important that they are collateralized to the amount that would make the rest of the pool whole in the case of a malfeasant operator. Would their over-collateralization be put to work in the pool and earning rewards so that they remain incentivized to provide the required amount?
9.) Do you see any dynamic changes to the incentives offered to stakers or operators based on the how decentralized the Ren network is? Based on the relative supply/demand of stakers vs operators?
10.) Will operators and the stake they bring to Renbase be subject to similar joining/leaving constraints as stakers’ contributions?
11.) Related to Thomm’s question #3, would Renbase see any value in implementing a limit (dynamic or otherwise) to avoid concentrating too much of the network under one protocol/smart contract and the risks of an unknown catastrophic security flaw or attack that could result? For example: RenBase will refuse new stakers/operators once Renbase represents more than 50% of the total Ren network and will re-enable new stakers/operators once their share of the network falls under 50% again. Or can you elaborate on why this isn’t a concern – e.g.: the operators work independently and manually to spin up and spin down nodes based on the requirements and directions of the protocol/smart contract, and therefore the operation of the dark node is not so directly connected to the smart contract beyond incentive/collateral.
12.) Do you see any incentive for a DNO that has 5 nodes of their own to operate those nodes at Renbase rather than directly themselves? (I’d assume the operator incentives hinted at would might come into play.) Can you describe why a DNO would want to remain their own operator outside of the Renbase system?
13.) Do operators spin up nodes using their own keys/etc?
Thank you for working on such an important piece that seems like it will be getting more, not less, important going forward.
