Good points. Let me give you my opinion to some of them:
We've already discussed potential solution for Hive - financially incentivise custodians to use
decline_voting_rights_operation.
If the tokens are not powered up the exchange could move the tokens to a new account that can vote and power up the tokens there. So, declining voting rights doesn't add much value in my opinion. In the case of Koinos it's true that you can transfer VHP. To perform an attack in the governance system you need at least 60% of the power (or 75% to update the governance contract). In the case there is an attack by someone with a lot of tokens (like an exchange), the honest nodes have 3 weeks to react and burn more tokens. 1 week to check the proposal change, and the voting period starts in the second week (1 block produced = 1 vote). So it is similar to the solution implemented in hive, where there is some time before applying a witness vote.
Also, you still need some form of majority agreement to update core contracts, it is just that nodes don't need to stop and replay using new version of the code, because new code is just a transaction.
Correct. It is necessary to reach a consensus before applying a change in koinos. "upgrade without hardforks" means that it is not mandatory to stop and run a new code on each node. So it's easier to apply changes to thousands of nodes.
First, it doesn't matter how much support you get as a witness, once you hit top20 you are not getting any more influence on the network (you only mine one block per schedule). This is Hive.
I like this design. Maybe something like this could be rethought for koinos in the future. There are some cons btw. For instance, the witnesses with low votes do not have the chance to produce blocks. Maybe a mix between top20 and proportional stake below top20 would be a good solution.
In PoS your influence is proportional to the stake you control. Koinos seems to work that way.
Correct, this is how it works.
In Koinos it seems like it might be dependent on concrete pool contract, which raises question about practical ability of regular users to verify contract code to make sure they are not subscribing to something that limits their control.
Right now there are 2 pool contracts. I created one of them (fogata). Both of them are open source. So they can be verified by the community. It's true that a regular user will not verify it but this is the case of all blockchains. People use bitcoin without reading the code. They trust in the network because others have read the code, which is public. I think we can apply the same logic here. We cannot do more than opening the source code.
Also what ways are there to prevent pool operator from changing the contract later?
The source code of the mining pool also defines what is the procedure to upgrade its own contract. Right now the design taken by the pools is to disable this option, so it's not possible to change the contract. Later on more pools could emerge with a voting system to be able to add features or fix bugs.
The point that @edicted made is that while exchanges ignore it now, because it is not worth the hassle, once adoption kicks in (and token price with it) they will "stake" the tokens of their customers not in order to do something malicious, but in order to gain interest associated with the stake. The fact that they time lock the tokens, and therefore might expose themselves to liquidity problem, won't stop them. They might even do it in legitimate way by asking users for permission, and the experiences of other cryptos tell us, that users will go for it in exchange for some passive income.
The idea behind 30 day delay of stake activation in Hive was that it gives us time to notice a problem and to rally users behind common goal of averting disaster. However if exchanges power up coins for yield, there won't be clear sign of malicious intent. Even if users might be wary at first, there is no way to be in a state of constant high alert. Once everyone sees the exchanges just want to earn money, they will go back to regular business. The 30 days will pass and if at some point an exchange decides to go rogue, we won't have the time buffer anymore.
Even if the exchange never does anything wrong, the fact that its nontrivial stake will be used for automated yield farming is going to be detrimental to the network, in line with any powerful bot. Eventually, as exchanges are regulated entities, they might have no choice but to push for something the rest of us would not want, f.e. promote censorship of certain transactions, or impose strong KYC when creating new accounts etc. It might be easier on Koinos in that aspect because it does not seem to have politics and social agendas embedded in its core functionality.
The proposed solution is to give exchanges a financial reason to use
decline_voting_rights_operation. If the benefits are strong enough and the exchange still moves the coins to other non-locked account and powers them up, we'll have much stronger argument that they do it for something bad, warranting stronger response, and there will be still full 30 day delay ahead of us.There are many things to consider though. Starting from general - how strong the incentives should be: just the passive income from rising price of VESTS, or should we also include part/all income related to curation? We should also consider that stake comes with potential of selling HP and RC delegations. Next technical - the income comes from different sources, depending on answer to first question, so how do we pass correct interest without actually using regular mechanisms? F.e. if we let locked accounts power down instantly (basically turning VESTS into liquid asset), it makes it easy to handle passive income (normal code is used), but it removes safety aspect of time locking stake, which might be a no-no for some. Finally we'd need to predict human behavior - if we give too much incentives, not just the exchanges, but many other users might choose to decline voting for passive income. Which might be good, because such people probably use curation bots at the moment, but if too many do that, it reduces active stake, making it cheaper to do regular money attack. On top of all above considerations I can see some holes in current mechanism, so if we decide to go that path, we'd most likely need to reinvent the operation and reset accounts that used it in the past, so the users can decide if they still want to lock their accounts given new way it's going to work. I'm going to tag @blocktrades and @gtg for some attention, so we can discuss and possibly escalate it further.
That's exactly how it works in Hive. Witnesses outside of top20 are chosen for 21st schedule position with frequency proportional to the power of their backing. I've described the mechanism here when we had to fix a bug introduced to that mechanism.
That's not the point. When dealing with consensus code one can assume someone unrelated actually looked through the changes (it is the job of validators to check that before they vote for new version). Moreover the code is under scrutiny of people that invested a lot of effort (and most likely also money) in the project. That is not true for contracts that anyone can build at any time. Next point is that you don't have to trust compiled version. It is usually very easy to pull source code and run single script to build it (and even if you don't have required compiler installed, Linux is going to tell you what command you have to run in order to install it). Any user can do it. Again, that is not true for contracts. One more thing is that when you build from sources yourself, you know that what you are running is the thing that matches the sources you have. In case of contracts, even if you have the sources and can build them, the build has to be repeatable (exactly the same binary output for each compilation), because you are not going to run it yourself - the nodes are going to run the binaries uploaded to the chain, so all you can do is compare if the uploaded version is the same as what you managed to build (unless of course the contract is uploaded as a source code to be compiled by nodes - that would mean all contracts are open source, enforced by upload mechanism).
Very interesting read. Ok, this is good, I was not aware of this 21 place. But 21 is not enough in my opinion, it should be much more. As I said I prefer this design rather than a pure proportional. It would be good to propose a similar approach in koinos. There is no need to remove the proof of burn mechanism. We just have to limit the effective VHP. The miner can accumulate any amount of VHP, but during the computation of the difficulty their VHP is limited to some value that depends on the total supply. In this way it can reproduce the same strategy used in Hive. But I would like to increase the number of nodes. Let's say the VHP limitation is 1/100 of the total supply, so the top 100 will have the same influence. And change it from time to time depending on the number of miners in the network. @andrarchy
The same logic applies to contracts. If someone is investing a lot of money or efforts in a project, he will make an exhaustive scrutiny whether it is a blockchain or a smart contract. There is no difference because there is money involved.
Correct. This is the process to verify at 100% that the source code matches with the contract in the chain, and in this case there is no doubt of the transparency of the dApp developer. Apart from that, the verifier also has to check if there was a contract in the past for this address, in order to check if the data in the storage was not manipulated. Then it's fine.
For instance, in fogata (the mining pool) we provide a docker to compile the contract. Then the docker will always use the same compiler in order to compile the same binary. Then everyone can verify it matches with the binary in the chain. In the future new services could emerge to simplify this process, like the source code verification used in etherscan.