In Tezos, the voters are stakeholders with skin in the game. This creates a very different dynamic from political democracies where voters have little incentives to educate themselves about their vote.
The value of the Tezos network is entirely subordinate to the quality of its governance. Large holders have a lot more to lose by wrecking the fairness of the network than they could possibly stand to gain.
Pragmatically, there aren’t any good ways to identify people as individuals on decentralized networks yet. From an economic standpoint, stake based voting encourages more rational behavior because the people with the greatest voice are also the ones with the most skin in the game.
What prevents networks with no explicit governance structure from doing the same thing with a hard-fork? There are voices loud enough in those communities to get everyone’s attention and propose such changes, but participants simply wouldn’t go for it. Sometimes, forks must happen. We’re only making sure that when they do, they follow a proper procedure.
Not particularly. What makes Tezos unique is its self-referential governance model. E-voting in government elections is a different problem, and blockchains aren't particularly well suited or even useful to address it.
Other projects are welcome to try and use the Tezos blockchain for that purpose, but this isn’t what we’re after. Our goal is to govern the Tezos blockchain itself and make it the best smart-contract platform there is.
Our initial governance mechanism does involve a vote, but it is a delegated vote. Passive holders are incentivized to delegate their voting power to another party. Since those parties are also responsible for securing the consensus with proof-of-stake, they also typically have put up large bonds on the network. This should greatly increase participation and preserves incentives. However, it is important to keep in mind that Tezos is about governance, not voting. Through the amendment procedure, the system can evolve towards more robust forms of governance which incorporate various counter-powers and even include constitutional principles in the form of formal requirement for future amendments.
For this to happen, you would first need a lot of liquidity in the derivative market, enough to take a significant stake in the network. This is possible, some futures market (like crude oil) do outweigh their spot market, but it would typically come at a time at which the project has matured. We do not think that voting is the be-all-and-end-all of governance but rather a starting point upon which to layer protections. This will likely involve setting up different bodies of power, creating constitutional rules. Last but not least, as a last recourse, a move that would ostensibly and severely harm the network can always be ignored with a hard fork.
A smart-contract language has different requirement. It needs to allow a concise style in order to save storage space on the blockchain, which is why we use a stack-based language. It should also have a full formal specification, few languages currently do. Finally, we need a clear way of tracking the number of execution steps to cap the validation time of blocks. We may develop a higher level language and a verified compiler in the future.
Some early forms of proof-of-stake were susceptible to certain attacks. Tezos’ proof-of-stake at stake is largely different. We rely on stake only as a Sybil prevention mechanism, and use safety bonds in order to avoid double signing. Overall, proof-of-stake and proof-of-work represent different tradeoffs in terms of cost and security. Under some threats, one may be better than the other. We take the view that overall, our implementation of proof-of-stake represents a better tradeoff. Ultimately, this will remain an empirical question, but Tezos’ consensus mechanism can be amended over time in order to address newfound threats.
Unfortunately, at this point there only exists the high-level description given in the white paper and the reference implementation. In most cases best practices dictate to build a specification first and to derive implementation after. Ambiguities and difference in implementations can be progressively resolved. In our case though consensus is absolutely critical. Unless the specification is perfectly unambiguous, different implementations could diverge and spell disaster. A perfectly unambiguous specification is essentially a program. The ideal scenario would be to build a specification of the protocol in Coq and derive a formally verified implementation. This may happen down the line.