Hello Terra Community, We are Ellipti Labs and currently developing Terra-Oracle for some period.
Problem Status quo
Terra seems to have a large number of validators compared to the development situation, and it seems that each validators doesn’t understand what they contribute on. In the long run, this situation is likely to lead to worse situations in the event of network outliers associated with free riding, depending on interests. Since it wouldn’t be sustainable to have a large number of validators on early stage, We’ve written an potential problems below.
- Terra has a large set of validator set considering the development status quo, We don’t find why Terra requires large set of validator in this current period.
- ‘Santa’ incentivizes Validators to run a Terra node. No offense, but we seem there are validators with less contribution on Terra increasing.
For feasible solution what we thought of is,
- To give a good example of governance, I would like to take Factom as an example. Factom is a project that adds a data layer to the Bitcoin blockchain with a long history, so I assume that Terra can also use as its governance as a reference for validator selection.
- Factom set the initial Validator set conservatively and decided to scale the validator set as the network grew. Initial validator set consisted of: 1. Major investors and major token holders 2. Validators with high development contributions.
- As the network grows, an n number validators are added to the validator set every quarter. With the condition that they show visible and measurable contributions to the network, the foundations guaranteed a certain amount of rewards for each validator.
- Application form is created to determine each validator’s plans and commitments regarding their contributions. On-chain governance decides whether to accept the validator or not.
- Ability to track each contributor’s roles, contributions, and progress.
- Reduce the amount of ‘free-riding’ rewards, Increase incentives for contributors
- Increase responsibility and accountability of each validators as stewards of the network
If you have many respondents who agrees, and willing to contribute Please leave comment below us. We are willing to write an updated draft version of governance proposal further. If you have any questions, please feel free to contact us.
I think generally I prefer a more decentralized / permissionless approach. We have a robust consensus protocol that can handle a large number of validators, and a sybil resistant protocol, so there is no technical reason to start blocking / removing validators (unless there is provable malicious behaviour). It would damage the credibility of the network.
I certainly agree with Terraform Labs wanting to ensure they get value for their delegation, so we are 100% behind the efforts to get validators to raise their game and to commit to do additional tasks on behalf of the network. The rewards should be proportional to the efforts, so I think what Do and team are proposing (validators making commitments to deliver the tasks on the delegation program task list) is the way to go.
The one exception to this is the price oracle - it certainly seems that this can be gamed relatively easily, so continuing to be conservative about who can run the oracle services makes sense. So maybe a governance controlled whitelist would work here.
[Edit: Actually changing oracle to use weighting by voting power is probably cleaner than whitelist.]
@rflxvty - at the moment the oracle votes are already weighted by stake. What do you think about oracle downtime becoming a slashing condition?
OK - great re. voting power. That makes it pretty robust in the short term.
And yes, slashing for oracle outages is a good idea in principle. But it will depend on how oracles get paid, as I know there was a discussion going on about whether oracles being paid from swap fees would create weird incentives to manipulate the Luna price (and it probably would). If it shifts to transaction fees then my concern would be that some would opt-out of running oracles until the fees increase. Of course, you could make it compulsory for all validators to run oracles but not sure if that’s what you intended.
I know there was also concerns that paying the rewards out of seignorage would also create weird incentives to cause more Luna to be burnt (On oracle reliability). This argument isn’t that convincing to me. Validators might be able to increase burn rate temporarily but system should be working against this - looking to mint more Luna to maintain peg. So the attack seems unsustainable. And therefore maybe this is something that we can continue to explore.
So I guess the key point is that slashing makes sense but only if validators can see the business case for investing in this area. Higher risk needs higher rewards.
Another option is to pay for running oracles by providing extra delegations. Then you probably don’t want slashing (as it would be Terraform funds that get slashed!). But you could review the performance of each validator, say once a quarter, and remove the delegation from any validator that is not performing or where there are signs of possible market manipulation. Maybe this can be built into the macroeconomic dashboard / analysis reports i.e. a report on the uptime of oracles + their deviations from consensus.
I think the oracle for terra is good enough because oracle price is calculated by weighted median (like timestamp in tendermint). Attackers can’t manipulate the oracle prices out of range which honest validators votes. In my humble opinion, a more important problem is how to respond to huge fluctuation. I remember that terra foundation turned off oracle due to huge fluctuation when luna listed in Upbit exchange. I think oracle downtime slashing should be fairly generous because it could be the choice for turning off the price oracle to postpone arbitrage trading. So I think the downtime slashing needs wide and generalized approach rather than a reactive approach.
Oracle would be better if the network could provide a fair reward to validator who submits good oracle prices.