Thanks, @SeekingKnowledge.
…how do you envision Renbase’s structure/framework in regards to relying on centralized hosting providers such as AWS or DO to operate nodes, and the possible attack vector posed by any overreliance on those centralized entities?
Ultimately, the goal is to let anyone participate in Renbase as a node operator, so as Ren Labs supports more ways to run a node, the hardware composition of Renbase nodes would be as diverse as operators want them to be.
For Ren governance matters, what type of framework or logistics do you envision to help reach consensus among all stakeholders/participants in Renbase, when issues that requiring voting for node operators come up?
Currently, voting power is measured by the square root of how long a Darknode has been registered in months. For example, if an operator has 2 nodes registered for 9 months each, their voting power would be:
sqrt(9) + sqrt(9) = 6
We can also imagine this as the square root of how long 100k REN has been bonded to a registered node in months. For example:
sqrt(100k / 100k * 9) + sqrt(100k / 100k * 9) = 6
We could do the same in Renbase. If the Ren community agreed to do so, it could recognize Renbase users’ voting power by the square root of how long 100k REN has been deposited in months. For example, if an operator deposits 50k REN in epoch N and 33k REN in epoch N+3, then in epoch N+9, their voting power would be:
sqrt(50k / 100k * 9) + sqrt(33k / 100k * 6) = 3.53553390593
Now let’s say they withdraw 50k REN in epoch N+7. Currently, deregistering a node forfeits the voting power of that node. If we apply the same principle using last-in-first-out (LIFO), they would lose the voting power of their 33k REN deposit as well as 17k REN of their initial 50k REN deposit. In epoch N+9, their voting power would be:
sqrt(33k / 100k * 9) = 1.73205080757
This is just one option, and the voting power logic is flexible. Ultimately, Renbase will support whatever approach the Ren community decides to take.