Neo: OnChain Governance on a SmartContract

[igormcoelho]

Governance for network, such as voting, could be made on a SmartContract, instead on hard coded on Neo protocol. This allows migration of this contract if necessary on different scenarios, with different policies than the existing one on Neo.
I propose that we discuss this, to have Neo 3.0 being born like this, giving more flexibility to business applications.

[erikzhang]

Maybe we can create the first native contract about voting on NEO 2.x.

[vncoelho]

Nowwww we fly, Erik. Here we go.

[erikzhang]

After I finish the work of pricing model, I can try to create this native contract.

[igormcoelho]

This is nice Erik. I think we will need an interop on Standard service GetGovernanceScript (or GetGovernanceContract).
The implementation of this GovernanceScript for Neo could be:
SYSCALL Neo.Native.VotingContract
VotingContract could return bool, if succeeded or not. Regarding parameters... I think it should receive an Array of Script (not ScriptHash) as parameters, which are the validators. On Neo, we could take the public key from each Script (21+pubkey+ac) and verify the voting on a native process, returning true if the validators where selected to govern the network. This way, the method would work to "validate" the set of passed validators.

So, the scripthash of the onchain governance on Neo would always be fixed, and on other services, this could be variable (using other scripts).

[erikzhang]

We don't need interop for GetGovernanceScript. The hash native contract is fixed.

[igormcoelho]

In fact, we are talking about two contracts here @erikzhang. Current Neo blockchain uses voting as governance system, and this contract will be native, right?
So, suppose the call for this native voting contract is SYSCALL Neo.Native.VotingContract, we will compute this scripthash and even when this implementation changes on voting, the hash will be the same. So the implementation for GetGovernanceScript could be, for example, APPCALL voting_native_hash.
But suppose someone else wants to have a private network based on Neo, with different governance policy. So it would be nice to have the governance script changed to something else, for example, having fixed nodes and no voting, so it would be APPCALL fixed_node_governance_contract. Or governance could be any other different things. This allows Neo blockchain to be used in many different scenarios, and still keep its format.

[erikzhang]

voting_native_hash will always equal fixed_node_governance_contract. Because both of them are calculated from hash160(SYSCALL Neo.Native.VotingContract).

[igormcoelho]

But you are supposing we will change Neo.Native.VotingContract for the privatenet, but we won't. It could be proof of work, proof of stake, or anything else. This way we can use Neo codebase for industrial privatenets, but changing the logic of the network governance.
And to be honest, I believe Migration would also be more effective if, instead of having it hardcoded on contract, we added it as a complementary contract as a governance policy for the contract. So we could also have GetGovernanceScriptForContract 0xabcd. If no migration is possible, this is a return false contract. If it is an owner-based contract, it will be CheckWitness(owner). If it's a voting based governance, we could have another script too...

[erikzhang]

but changing the logic of the network governance

You can change the logic, but you needn't change the syscall name. If so, the hash will not be changed.

[igormcoelho]

Ok, I get it now. So, a good name for Neo.Native.VotingContract could be Neo.Native.Governance, or something like that, do you agree?
I will open another issue regarding governance for contract migration.

[vncoelho]

@erikzhang, I think that the voting for NEO 2.x is now not considered, right?

But let's keep this idea strong for implementing this onchain governance for NEO 3 as soon as possible.